Agents in Orbit: Workflows, Not Autopilot — Eduardo Simon & Javier Casal, Flywire

한 줄 핵심

Flywire는 규제·보안 제약이 큰 결제 환경에서 LLM을 자율 비서처럼 풀어두기보다, 코드 중심의 워크플로로 감싸서 안전하고 재현 가능한 업무 자동화를 만드는 방법을 보여준다.

시간별 요약

1. 0:00
   Flywire 플랫폼 팀과 결제 맥락 Flywire는 교육·의료·여행 등에서 복잡한 국제 결제를 처리하므로 PCI, DSS, PII, PHI 수준의 보안과 규제가 핵심 요구사항이다. 내부 플랫폼 Victoria 위에서 400명 규모의 엔지니어링 조직이 다양한 스택을 운영하며, 민감한 데이터를 외부로 넘기지 않는 구조가 전제된다.
2. 1:58
   자발적 실험에서 Orbit으로 초기에는 엔지니어들이 skills, MCP servers, 코드 리뷰 봇을 각자 실험했지만, 이를 안전하고 신뢰할 수 있는 인프라로 묶기 위해 전담 팀과 Orbit이 생겼다. Orbit은 반복적인 작업은 결정적 코드로 고정하고, 추론이 필요한 순간에만 LLM을 호출하는 내부 toil killer다.
3. 3:35
   기존 인프라에서 직접 만들기와 구매 비교 금융·개인정보 환경에서는 실행이 Victoria 안에 머무는 자체 구축이 더 합리적이며, 민감 데이터 통제와 보안 심사 부담을 줄일 수 있다. Orbit의 워크플로는 기존 인프라와 규제 경계를 그대로 활용하는 방향으로 설계된다.
4. 4:17
   YAML 워크플로와 제한된 코드 리뷰 각 에이전트는 저장소에 있는 하나의 YAML 파일로 정의되고 일반 코드와 같은 merge request 리뷰를 거친다. 코드 리뷰 에이전트는 트리거, 메타데이터 수집, 위험도 분류, 코드 읽기 전용 LLM 단계, 결과 게시로 이어지며, 모델은 수정 권한 없이 정해진 출력 형식만 반환한다.
5. 5:46
   트리거와 엔지니어링 사용 사례 워크플로는 API, CLI, GitLab·Jira·Sentry·AWS webhook, 스케줄 작업으로 시작할 수 있고, 앞으로는 MCP server를 통해 다른 AI 도구에서도 직접 호출될 수 있다. 실제 활용은 코드 리뷰, Victoria 업그레이드 수정, 번역 동기화, 장애 분석, 티켓 분류, AI readiness 점검, merge request 생성처럼 반복성이 높은 엔지니어링 업무에 집중된다.
6. 8:29
   런타임과 오케스트레이션 분리 초기에는 orchestration과 runtime이 한 컨테이너에 있었지만, 규모가 커지면서 오케스트레이션·런타임·세션 상태를 분리해 격리성과 유지보수성을 높였다. 이 구조는 오류 전파를 줄이고, 각 구성요소를 독립적으로 확장할 수 있게 해 대량 병렬 실행에 유리하다.
7. 9:21
   제한, 잠금, 실행 환경 무제한 실행을 막기 위해 시간 제한, 레이트 제한, 중복 실행 방지를 위한 lock을 둔다. Victoria의 컨테이너는 가볍고 제한적이며, 기본 에이전트 이미지는 공통 런타임만 포함하고 Bundler, Maven, Composer 같은 패키지 매니저는 제외해 고위험 작업을 쉽게 못 하게 한다.
8. 11:04
   단계별 접근 권한과 공유 스킬 각 LLM 단계는 cloud code의 하네스를 재사용하되, 네트워크·도구·skills·MCP server 접근을 YAML에서 세밀하게 제한한다. 동시에 skills는 중앙 저장소를 통해 cloud code와 Orbit에서 공용으로 쓰며, 먼저 skill로 가치를 증명한 뒤 자동화가 확실한 작업만 workflow로 승격시키는 전략을 택한다.
9. 13:10
   구조화된 출력과 평가의 빈틈 모든 LLM 단계는 strict JSON schema를 요구해 후속 분기와 오류 처리가 문자열 파싱이 아니라 결정적 제어 흐름으로 이어지게 한다. 평가는 전체 워크플로를 한 번에 재현하기보다 개별 LLM step을 분리해 historical state를 주입하고, 실제 실행 trace와 golden dataset으로 품질과 회귀를 점검한다.
10. 15:40
    보고된 실행 수, 도입, 그리고 로드맵 코드 리뷰, 취약 dependency 수정, readiness 점검, lint, merge conflict 해결 같은 워크플로가 수만 건 규모로 운영되며 높은 성공률을 보였다. 다음 단계는 더 강한 sandboxing, resumable sessions, 내장 평가 도구, 모델 중립적 오케스트레이션, 자동 model router로 확장해 비용과 유연성을 함께 개선하는 것이다.

실무 인사이트

• 반복 업무를 LLM에게 직접 맡기기보다, 결정적인 절차를 코드로 고정하고 추론이 필요한 지점만 모델에 맡기면 안정성과 비용 통제를 동시에 잡을 수 있다.
• 민감한 기업 환경에서는 모델 성능보다 실행 경계, 권한, 감사 가능성이 더 중요하므로, 워크플로 정의 자체를 코드처럼 리뷰 가능하게 만드는 접근이 실무적이다.
• 워크플로 자동화는 한 번에 큰 범위를 바꾸기보다, merge request 리뷰나 번역 동기화처럼 빈도가 높고 명확한 작업부터 시작해야 조직 전체로 확산되기 쉽다.