오빗(Orbit): 오토파일럿이 아닌 워크플로우로 만드는 기업용 AI 자동화

URL: https://www.youtube.com/watch?v=rAUyRDOFyHU
날짜: 2026-10-13
원본 업로드일: 2026-10-12
채널: aiDotEngineer
원문 제목: Agents in Orbit: Workflows, Not Autopilot — Eduardo Simon & Javier Casal, Flywire

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==기업 환경에서 AI 에이전트를 자유롭게 풀어놓는 오토파일럿(Autopilot)으로 만들지 않고, 결정론적 코드와 제한된 LLM 호출을 결합한 검토 가능한 워크플로우(Workflow)로 만들려면 어떻게 해야 하는가?==

• 반복적이고 예측 가능한 부분은 코드로 고정하고, 판단이 필요한 순간에만 작은 LLM 단계를 호출해야 한다.
• 금융 결제 기업의 PCI DSS, SOC 2, PII·PHI, 고객 데이터 경계를 지키려면 실행 환경과 에이전트 권한을 인프라 수준에서 통제해야 한다.
• YAML로 정의한 워크플로우를 일반 코드와 같은 Merge Request(MR) 리뷰에 넣고, 결과 역시 사람이 검토·승인하는 MR로 남겨야 한다.
• 신뢰성은 구조화된 JSON 출력, 타임아웃·Rate Limit·동시성 제어, OpenTelemetry 추적, 실제 실행에서 만든 Golden Dataset 평가로 확보한다.

Orbit의 주장은 “더 자율적인 에이전트”가 곧 “더 좋은 자동화”라는 전제를 뒤집는다. Flywire는 예측 가능한 작업을 결정론적 활동(Deterministic Activity)으로 구성하고 모델은 필요한 곳에만 배치한다. 그 결과 에이전트는 통제된 기업 인프라 안에서 대규모로 실행되면서도, 비용·보안·감사 가능성·인간의 책임성을 동시에 유지한다.

1. Flywire의 사업 환경과 AI 플랫폼을 만든 이유

Flywire의 에이전트 설계는 일반적인 개발 도구 실험이 아니라, 고액 국제 결제를 처리하는 규제 산업의 운영 조건에서 출발한다.

1.1. 고액 국제 결제 기업이 AI에 요구하는 조건

1. Flywire가 해결하는 문제의 범위

   1. Flywire는 교육(Education), 헬스케어(Healthcare), 여행(Travel), 비즈니스 서비스(Business Services) 같은 글로벌 산업에서 복잡한 결제를 처리한다.
   2. 5,000곳이 넘는 고객을 240개 이상의 국가와 지역에서 지원한다.
   3. 국제 결제 금액이 크고 고객 데이터의 민감도가 높기 때문에 규제 준수(Compliance), 프라이버시(Privacy), 보안(Security)은 나중에 붙이는 부가 기능이 아니라 사업의 핵심 요구사항이다.

2. 데이터를 외부 AI 서비스로 무심코 보낼 수 없는 이유

   1. 조직은 PCI DSS와 SOC 2 같은 엄격한 준수 프레임워크 아래에서 운영된다.
   2. 고객 데이터, 개인식별정보(PII, Personally Identifiable Information), 결제 정보는 안전하게 보존되어야 한다.
   3. 의료·헬스케어 맥락의 보호 건강정보(PHI, Protected Health Information)까지 다루므로, 민감한 컨텍스트를 아무런 거버넌스나 아키텍처 경계 없이 제3자 서비스에 전달할 수 없다.
   4. 따라서 AI가 무엇을 읽고 어디에 연결하며 어떤 데이터를 남기는지가 모델 선택만큼 중요하다.

1.2. 엔지니어링 조직의 다양성과 공통 기반

1. 약 400명의 글로벌 엔지니어

   1. Flywire에는 여러 팀에 분산된 약 400명의 소프트웨어 엔지니어가 있다.
   2. Java, Ruby, Go, Python, .NET, PHP 등 서로 다른 기술 스택이 공존한다.
   3. 한 가지 언어나 빌드 방식만 가정하는 자동화는 조직 전체에 적용하기 어렵다.

2. Victoria를 통한 표준화

   1. 거의 모든 시스템은 GitLab과 AWS 위에서 동작하는 내부 Platform as a Service인 Victoria에 배포된다.
   2. Victoria는 표준화된 빌드 파이프라인과 일관된 배포 방식을 제공한다.
   3. Orbit은 새로운 외부 실행 환경을 별도로 만들기보다, 이미 조직이 신뢰하고 운영하는 Victoria 안에 배치함으로써 보안 경계와 운영 방식을 이어받는다.

1.3. 자발적 실험에서 전담 AI 플랫폼 팀으로

1. 팀이 정식으로 만들어진 계기

   1. 영상 시점 기준 약 6개월 전인 4월, Flywire는 AI Platform Experience Team을 정식으로 만들었다.
   2. 전담 팀이 생기기 전부터 열정적인 엔지니어들이 AI 도구를 실험하고, Skill을 만들고, MCP 서버를 구축하고, 초기 코드 리뷰 봇을 조립하고 있었다.
   3. 이 자발적 활동은 엔지니어들이 AI 자동화를 원한다는 사실을 증명했지만, 동시에 안전하고 신뢰할 수 있는 Agentic Solution을 위한 공용 인프라가 필요하다는 사실도 드러냈다.

2. 빠른 내부 개발과 바깥 생태계의 속도

   1. 전담 팀은 약 6개월 동안 내부 도구에 거의 1,000개의 커밋을 쌓을 정도로 빠르게 움직였다.
   2. 그러나 AI 생태계도 멈추지 않았다. 같은 기간 Claude Code만 160개가 넘는 릴리스를 내놓아 거의 하루 한 번꼴로 업데이트된 셈이다.
   3. 주요 AI 연구소들도 20개가 넘는 새 모델을 출시했다.
   4. 매주 새 모델, 새 도구, 새 작업 방식이 등장하므로 문제는 단순히 빨리 만드는 데 있지 않고 변화 속도를 따라가면서도 기업 수준의 통제를 유지하는 데 있다.

2. Orbit의 핵심 철학: 워크플로우, 오토파일럿이 아니다

Orbit은 매일 반복되는 엔지니어링 작업을 줄이는 내부 플랫폼이지만, AI 에이전트를 열린 루프에 맡기는 방식과는 다르다.

2.1. 결정론적 코드와 작은 LLM 단계의 결합

1. “Toil Killer”로서의 Orbit

   1. Orbit은 반복적인 엔지니어링 작업(Toil)을 없애기 위해 LLM을 구조화된 워크플로우 안에 직접 포함한다.
   2. 에이전트가 열린 공간에서 목표를 향해 계속 행동하도록 허용하지 않고, 전체 실행을 명확한 활동들의 순서로 정의한다.
   3. 반복되는 절차적 로직은 코드로 굳히고, 실제 추론(Reasoning)이 필요한 순간에만 모델을 호출한다.

2. 오토파일럿과 워크플로우의 차이

   1. 오토파일럿 방식은 에이전트에게 넓은 권한을 주고, 중간 상태와 다음 행동을 모델이 계속 결정하게 한다.
   2. Orbit 방식은 코드가 입력을 가져오고, 위험도를 분류하고, 권한을 제한하고, 결과를 게시한다.
   3. LLM은 코드나 상황을 해석해야 하는 좁은 지점에서만 호출되며, 정해진 출력 스키마를 따라야 한다.
   4. 따라서 전체 시스템은 모델의 예측 불가능한 문자열이 아니라 검토 가능한 제어 흐름(Control Flow)을 중심으로 움직인다.

2.2. 직접 구축(Build)하기로 한 이유

1. 프론티어 모델이 낮춘 내부 구축 비용

   1. Flywire는 Orbit을 사지 않고 직접 구축하기로 했다.
   2. 프론티어 모델 덕분에 기능 개발 속도가 매우 빨라졌고, 맞춤형 플랫폼을 만드는 비용이 크게 낮아졌다.
   3. 내부 팀이 업무에 맞는 실행 제어와 데이터 경계를 직접 설계할 수 있다는 점이 범용 외부 제품보다 중요했다.

2. 보안·준수·데이터 통제

   1. PCI, PII, PHI 데이터를 다루는 금융 기업에게 민감한 정보가 통제 환경 밖으로 나가지 않는 것이 결정적이다.
   2. Victoria 인프라 안에서 실행하면 기존 네트워크·권한·감사 경계를 활용할 수 있다.
   3. 외부 벤더를 도입할 때 필요한 긴 보안 검토와 추가 준수 작업도 줄일 수 있다.
   4. 직접 구축은 단순히 비용을 아끼는 선택이 아니라, 실행 환경과 데이터 흐름을 기업의 책임 범위 안에 두는 아키텍처 선택이다.

3. 워크플로우 정의와 실행 진입점

Orbit의 워크플로우는 모델 프롬프트 하나가 아니라, 저장소에서 버전 관리되는 실행 프로그램이다.

3.1. YAML과 Merge Request를 이용한 에이전트 정의

1. 한 개의 YAML 파일이 에이전트의 계약이 된다

   1. Orbit의 각 에이전트는 저장소 안의 단일 YAML 파일로 정의된다.
   2. 이 파일은 일반 코드와 마찬가지로 Merge Request를 거쳐 리뷰된다.
   3. 어떤 트리거가 실행을 시작하는지, 어떤 결정론적 활동을 수행하는지, LLM 단계에 어떤 도구·Skill·MCP 권한이 있는지가 파일에 드러난다.

2. YAML을 선택한 이유

   1. 엔지니어들이 이미 알고 있고 매일 사용하는 포맷이므로 새로운 DSL을 배울 필요가 없다.
   2. 기존 코드 리뷰 프로세스와 같은 방식으로 변경을 검토할 수 있다.
   3. 코드베이스가 AI 친화적으로 유지된다. 코딩 에이전트도 사람이 하는 것처럼 워크플로우 정의를 읽고, 쓰고, 리뷰할 수 있다.

3. 코드 리뷰 에이전트의 실제 흐름

   1. 엔지니어가 Merge Request에서 리뷰 봇을 언급하면 GitLab Webhook이 트리거된다.
   2. 결정론적 단계가 Merge Request 메타데이터를 가져오고, 변경의 위험 등급(Risk Tier)을 분류하고, 과거 발견 사항을 불러오고, 저장소를 Clone한다.
   3. LLM 단계는 코드를 읽을 수 있지만 수정할 권한은 없다. 모델 응답도 엄격한 출력 스키마를 따라야 한다.
   4. 마지막 결정론적 단계가 리뷰 결과를 Merge Request에 게시한다.
   5. 코드가 예측 가능한 부분을 담당하고 모델은 추론이 필요한 부분만 담당한다는 “Workflows, Not Autopilot” 원칙이 한 번의 리뷰 안에 그대로 드러난다.

3.2. 세 가지 기본 진입점과 MCP 확장

1. API와 내부 CLI

   1. 엔지니어나 다른 시스템은 Orbit 내부 API를 직접 호출할 수 있다.
   2. 내부 CLI를 통해서도 같은 워크플로우를 시작할 수 있다.

2. 이벤트 기반 Webhook

   1. GitLab, Jira, Sentry, AWS에서 발생한 이벤트가 워크플로우를 시작할 수 있다.
   2. 예를 들어 새 Merge Request가 생겼거나 운영 환경에서 새 오류가 발생한 순간에 자동 실행할 수 있다.

3. 예약 작업(Scheduled Job)

   1. 고정된 주기로 워크플로우를 실행할 수 있다.
   2. 실제 예로 매일 수행하는 번역 동기화, Feature Flag 정리, 지식 베이스 갱신이 있다.

4. Orbit용 MCP 서버

   1. 팀은 Orbit을 MCP 서버로 노출해 Flywire 내부의 다른 AI 서비스와 도구가 직접 워크플로우를 시작하도록 만드는 중이다.
   2. 장기적으로는 엔지니어가 대화를 나가서 별도 UI를 열지 않고 Slack 안에서 Claude 같은 내부 AI 서비스에 요청해 Orbit 워크플로우를 실행할 수 있다.
   3. MCP는 모델이 모든 작업을 직접 수행하게 만드는 수단이 아니라, 이미 통제된 워크플로우를 필요한 대화형 도구에서 호출하는 연결 계층으로 사용된다.

3.3. 비엔지니어를 위한 저작 방식

1. YAML만으로 충분하지 않은 사용자

   1. 모든 자동화 요구가 엔지니어링 팀에서 나오는 것은 아니다.
   2. 기업 운영 부서가 직접 워크플로우를 만들 때는 YAML을 작성하는 진입 장벽이 문제가 될 수 있다.

2. Orbit UI의 드래그 앤 드롭 저작 도구

   1. 팀은 Orbit UI에서 사전 정의된 활동을 드래그 앤 드롭해 워크플로우를 구성하는 저작 도구를 고려하고 있다.
   2. 이 방식도 자유로운 에이전트 루프를 허용하는 것이 아니라, 승인된 활동 집합 안에서 비엔지니어가 안전하게 조합하도록 하는 방식이다.

4. 작게 시작해 큰 범위로 확장한 사용 사례

Flywire는 “AI가 무엇이든 하게 하자”가 아니라, 반복적이고 영향이 큰 작업을 골라 자동화했다.

4.1. 엔지니어링·번역·운영 자동화

1. 일상 엔지니어링 업무

   1. Merge Request 자동 코드 리뷰가 첫 번째 핵심 사용 사례다.
   2. Victoria 업그레이드 에이전트는 Victoria 관련 발견 사항을 자동으로 고친다.
   3. Audit Fixer는 취약한 의존성을 고치는 Merge Request를 연다.
   4. Merge Conflict Resolver는 충돌 해결을 반복 실행한다.

2. 번역 전체 주기 자동화

   1. 하나의 워크플로우가 새 문자열을 가져온다.
   2. 문자열을 번역하고 파일을 업데이트한다.
   3. 갱신된 문서를 팀에 알린다.
   4. 번역처럼 입력·변환·파일 변경·알림 순서가 뚜렷한 작업은 Orbit의 구조화된 접근과 잘 맞는다.

3. 운영 오류 조사

   1. Sentry Webhook이 Sentry Investigator를 시작한다.
   2. 에이전트가 이슈를 평가하고 결과를 Slack에 게시한다.
   3. 수정 사항이 담긴 Merge Request도 같은 장소에서 공유한다.
   4. 조사·공유·수정 제안은 자동화하지만 실제 코드 반영과 승인 책임은 Merge Request와 사람에게 남긴다.

4.2. 지원·AI 준비도·티켓 구현

1. 지원 티켓 분류

   1. 새로 들어온 티켓을 분류하고 적절한 엔지니어링 영역으로 라우팅한다.
   2. 반복적인 초동 분류를 자동화해 사람이 더 복잡한 지원과 해결에 집중하도록 한다.

2. AI Readiness Scorecard와 Fixer

   1. AI Readiness Scorecard는 저장소가 AI 보조 개발을 얼마나 준비했는지 측정한다.
   2. Fixer는 점수와 발견 사항을 바탕으로 실제 저장소를 개선한다.
   3. 평가만 남기는 것이 아니라 평가 결과를 대규모 저장소 변경으로 연결한다.

3. Jira Implement

   1. Jira 티켓을 받아 Merge Request로 전환한다.
   2. 작은 Ticket-to-Code Factory처럼 작동해 티켓에서 구현 제안까지의 반복 절차를 줄인다.
   3. 그래도 최종 산출물은 사람이 리뷰할 수 있는 Merge Request이며, 자율 배포로 끝나지 않는다.

4.3. 여러 저장소에 대한 대량 변경과 인간 개입

1. 소프트웨어 엔지니어링을 규모 있게 수행

   1. Orbit은 여러 저장소에 같은 변경을 일괄 적용할 수 있다.
   2. 마이그레이션, 라이브러리 업데이트, 사용 중단(Deprecation) 처리처럼 반복 범위가 큰 작업에서 특히 편리하다.
   3. Cloud Doctor를 실행하거나 자체 AI Readiness Scorecard를 여러 저장소에 적용하는 데에도 사용한다.

2. Merge Request가 여전히 업무의 단위다

   1. 자동화가 많아져도 Flywire에서 업무의 단위는 Merge Request로 남는다.
   2. 규제 환경에서는 사람이 변경을 리뷰하고 승인해야 한다.
   3. Orbit은 인간을 제거하는 시스템이 아니라, 사람이 책임 있게 검토할 수 있는 형태로 자동화 결과를 전달하는 시스템이다.

5. Orbit의 런타임 아키텍처와 규모 제어

Orbit은 처음부터 완성된 분산 시스템이 아니었다. 실행 수요가 커지면서 오케스트레이션, 에이전트 런타임, 세션 상태를 분리했다.

5.1. 단일 컨테이너에서 컴포넌트 분리로

1. 초기 ECS Fargate 구조

   1. 시작 시점에는 AWS ECS Fargate의 단순한 컨테이너 구성을 사용했다.
   2. 오케스트레이션 계층과 하네스, 런타임 환경이 같은 컨테이너 안에 함께 있었다.

2. 세 가지 컴포넌트로 진화

   1. 오케스트레이션 계층(Orchestration Layer), 에이전트 런타임 환경(Agent Runtime Environment), 세션 상태(Session State)를 별도 컴포넌트로 분리했다.
   2. 분리는 격리(Isolation), 유지보수성(Maintainability), 리소스 할당(Resource Allocation)을 개선한다.
   3. 오케스트레이터의 오류가 샌드박스를 함께 죽이지 않으며, 각 컴포넌트를 독립적으로 확장할 수 있다.
   4. 에이전트 요구사항이 바뀌어도 한 부분을 교체·확장해 대응할 수 있다.

3. Fargate를 선택한 운영상의 이점

   1. Fargate Task를 탄력적으로 확장해 많은 에이전트를 병렬로 실행할 수 있다.
   2. Victoria가 이미 애플리케이션을 쉽게 확장·배포하는 기반이었기 때문에 Orbit을 배포하기도 쉬웠다.
   3. 다만 큰 병렬성은 잘못된 통합 하나가 거대한 비용과 실행량으로 번질 수 있으므로 강한 가드레일이 필요하다.

5.2. 시간·속도·동시성 가드레일

1. Timeout

   1. 모든 에이전트는 설정 가능한 시간 제한을 넘으면 중지된다.
   2. 멈추지 않는 모델 루프나 외부 API 대기를 무한 실행으로 방치하지 않는다.

2. Rate Limit

   1. 기본값부터 공격적으로 설정한 Rate Limit이 있다.
   2. 고장 난 API 통합이 수천 개의 에이전트를 연쇄적으로 생성해 빌드 규모와 비용을 폭증시키는 상황을 막는다.

3. Concurrency Control

   1. Control Plane은 Lock을 사용해 같은 작업의 중복 실행을 방지한다.
   2. 예를 들어 코드 리뷰가 이미 실행 중이면 동일한 요청을 버린다.
   3. 이 제어는 모델 품질과 별개로, 이벤트 중복·재전송·Webhook 재시도로부터 시스템을 보호한다.

5.3. 컨테이너 한계와 프로젝트별 실행 환경

1. 가벼운 기본 에이전트 컨테이너

   1. Victoria는 표준 Fargate Task Definition을 사용하므로 컨테이너는 가볍고 엄격하게 제한된다.
   2. 기본 에이전트 컨테이너에는 공통 언어 런타임을 포함한다.
   3. 반면 Bundler, Maven, Composer 같은 패키지 매니저는 의도적으로 제외했다.
   4. 그래서 무거운 Jira Implement 같은 에이전트는 컨테이너 안에서 네이티브 빌드나 유닛 테스트를 쉽게 실행할 수 없다.

2. AWS Lambda MicroVM 도입

   1. Orbit을 시작한 4월에는 AWS Lambda MicroVM이 아직 존재하지 않았고, AWS가 6월에 이를 출시했다.
   2. 초기 버전은 Fargate에서만 실행했지만 이후 관리형 MicroVM을 도입했다.
   3. MicroVM은 Lambda 함수와 비슷한 재개 가능한 프로세스처럼 동작해 중지한 지점에서 일시 정지했다가 이어갈 수 있다.
   4. 작업을 중단하고 계속할 수 있는 특성은 다단계 Agentic Execution과 잘 맞는다.

3. 프로젝트 유형별 Toolchain과 향후 샌드박싱

   1. 현재는 프로젝트 유형에 따라 런타임과 Toolchain을 선택해 격리된 환경에서 실행한다.
   2. 아직 완전한 샌드박싱(Full Sandboxing)은 아니며, 팀은 그 방향으로 이동 중이다.
   3. 장기적으로 Docker-in-Docker 또는 여러 MicroVM을 지원해 모든 저장소에서 테스트와 복잡한 검증을 수행하려 한다.

6. LLM 단계의 권한 통제와 Skill 재사용

Orbit은 자체 에이전트 하네스를 새로 만들기보다 검증된 하네스를 재사용하고, 그 위에 실행 제어를 덧댄다.

6.1. Claude Agent SDK와 네 가지 권한 경계

1. 검증된 하네스 재사용

   1. Flywire는 LLM 단계의 하네스를 직접 만들지 않았다.
   2. Claude Agent SDK, 즉 Claude Code를 구동하는 동일한 하네스를 재사용한다.
   3. 이 하네스는 Tool Use, Subagent, Skill을 기본 제공하는 성숙하고 테스트된 기반이다.
   4. Flywire는 에이전트 배관(Plumbing)을 다시 만드는 대신 워크플로우 설계와 통제에 집중할 수 있다.

2. 각 LLM 단계에 필요한 것만 허용

   1. 네트워크(Network): 에이전트가 접근할 수 있는 네트워크 범위를 제한한다.
   2. 도구(Tools): 호출할 수 있는 도구를 제한한다.
   3. Skill: 로드할 수 있는 Skill만 선택한다.
   4. MCP 서버와 서버별 도구: MCP 서버 자체뿐 아니라 각 서버에서 허용할 구체적 도구 목록까지 제한한다.
   5. 네 가지 경계는 YAML 파일에 선언되므로 코드 리뷰에서 사람이 읽고 검토할 수 있다.

3. 구체적인 권한 예시

   1. 코드 리뷰 단계는 코드를 읽고 검색할 수 있지만 파일을 수정하거나 Push할 수 없다.
   2. Sentry Investigator는 MCP 서버를 통해 트레이스를 조회할 수 있지만, 짧은 목록의 Read-only 도구만 사용할 수 있다.
   3. 각 LLM 단계는 필요한 접근권한만 갖고, 그 권한은 숨겨진 런타임 상태가 아니라 일반 코드처럼 보이고 리뷰된다.

6.2. 중앙 Skill 저장소와 “Skill 먼저, Workflow 다음”

1. 한 곳에서 Skill을 배포

   1. Flywire는 중앙 Skill 저장소를 관리한다.
   2. 저장소의 Skill은 내부 Claude Code Plugin Marketplace로 게시된다.
   3. Orbit은 빌드 시점에 이 Marketplace에 연결한다.

2. 대화형 개발과 자동화 실행의 공통 기반

   1. 엔지니어는 노트북의 Claude Code에서 Skill을 실행할 수 있다.
   2. Orbit은 같은 Skill을 자동화된 백그라운드 워크플로우 안에서 실행할 수 있다.
   3. 동일한 Skill을 대화형 환경과 운영 자동화에서 공유하면 실험에서 프로덕션으로 옮길 때 의미 차이가 줄어든다.

3. 권장 도입 순서

   1. 먼저 Skill부터 만든다. Skill은 작성 비용이 낮고 반복 개선이 쉬우며 첫날부터 사람이 직접 쓸 수 있다.
   2. 어떤 작업이 실제로 자동화할 가치가 있는지 확인한다.
   3. 가치가 검증되면 Orbit 워크플로우로 옮긴다.
   4. 예측 가능한 부분은 결정론적 코드로 바꾸고, 모델은 가치가 생기는 부분에서만 호출한다.
   5. 이렇게 하면 열린 세션보다 실행이 안정적이고 저렴하며 백그라운드로 수행할 수 있어 엔지니어가 세션을 붙잡고 단계별로 안내할 필요가 없다.
   6. 결과적으로 컨텍스트 스위칭이 줄고, 사람이 정말 필요한 일에 더 많은 시간을 쓸 수 있다.

7. 구조화된 출력과 컴포넌트 단위 평가

실행 환경을 격리하는 것만으로는 충분하지 않다. 모델 출력과 평가 방식도 결정론적 흐름에 맞춰야 한다.

7.1. JSON Schema가 만드는 제어 가능한 실행

1. 모든 LLM 단계의 엄격한 JSON 출력

   1. Orbit의 모든 LLM 단계는 모델 응답에 Strict JSON Schema를 적용한다.
   2. 다음 실행 분기, 오류 처리, 상태 전이가 예측 불가능한 문자열 파싱에 의존하지 않게 된다.
   3. 모델이 정해진 스키마를 만족하지 못하면 Orbit은 다음 단계로 곧바로 넘어가지 않는다.

2. 검증 실패에 대한 표적 재시도와 Fallback

   1. JSON 검증에 실패하면 자동으로 Targeted Retry 또는 Fallback Pass를 실행한다.
   2. 전체 에이전트를 처음부터 무작정 다시 돌리는 것이 아니라 실패한 출력 계약에 맞춰 보정한다.
   3. 모델의 자유로운 생성 능력은 필요한 지점에서 활용하되, 시스템 경계에서는 기계적으로 검증 가능한 형식으로 바꾼다.

7.2. 전체 E2E 벤치마크 대신 LLM 단계 격리 평가

1. 종단간 평가의 문제

   1. 복잡한 E2E Agentic Workflow를 합성 벤치마크 환경에서 통째로 평가하면 잡음이 많다.
   2. 비용이 크고 재현이 어렵기 때문에, 작은 프롬프트나 모델 변경이 실제 품질에 미친 영향을 빨리 파악하기 힘들다.

2. 특정 노드에 과거 상태를 주입

   1. Flywire의 평가 하네스는 전체 워크플로우 대신 개별 LLM 단계를 격리한다.
   2. 정확한 과거 상태와 컨텍스트를 특정 워크플로우 노드에 직접 주입한다.
   3. 그 노드의 모델 출력 품질과 Prompt 조정을 측정하고, 성능 회귀(Regression)를 빠르고 저렴하게 포착한다.

7.3. 프로덕션 트레이스에서 Golden Dataset으로

1. 새 에이전트의 초기 검증

   1. 현재 새 에이전트는 몇 가지 실제 사례에 먼저 적용해 기대한 대로 동작하는지 확인하는 간단한 실사 검사를 거친다.
   2. 완벽한 합성 테스트만 기다리지 않고 실제 업무 사례로 유효성을 확인한다.

2. OpenTelemetry 기반 실행 추적

   1. 프로덕션에 배포된 뒤에는 OpenTelemetry로 각 실행을 처음부터 끝까지 추적한다.
   2. 개별 Activity, Model Call, Tool Call을 모두 기록한다.
   3. 실제 실행에서 얻은 트레이스를 추출해 Golden Dataset에 추가한다.

3. 버전 관리와 반복 개선

   1. 현재 Golden Dataset은 코드 옆 저장소에 버전 관리되고 필요할 때 실행된다.
   2. 결과를 바탕으로 프롬프트를 개선하거나 모델을 바꾼다.
   3. 같은 데이터셋을 다시 실행해 이전 결과와 비교한다.
   4. 아직 Online Evaluation은 없지만 내부에서 구축 중이다.

4. Orbit 안에서 완성하려는 평가 루프

   1. 목표는 UI나 MCP 서버를 통해 Orbit 안에서 전체 평가 루프를 실행하는 것이다.
   2. 에이전트를 배포하고, 프로덕션 실행을 모니터링하고 평가하고, 그 평가를 바탕으로 개선한다.
   3. 궁극적으로는 개선할 때마다 별도로 재배포하지 않아도 된다.
   4. Orbit을 모든 워크플로우를 Ship·Measure·Improve하는 한 곳으로 만드는 것이 평가 로드맵이다.

8. 30일간의 운영 성과

Orbit은 개념 증명에 머물지 않고 수천 건의 실제 엔지니어링 실행을 처리하고 있다.

8.1. 개별 자동화의 실적

1. 자동 코드 리뷰

   1. 최근 30일 동안 자동 코드 리뷰 에이전트가 9,700회 넘게 실행됐다.
   2. Merge Request 한 건당 평균 처리 시간은 3분 미만이다.

2. 취약성·준비도·인프라 수정

   1. Audit Fixer가 취약한 의존성을 수정하기 위한 Merge Request 159개를 열었다.
   2. AI Readiness Fixer가 약 80개 저장소를 개선했다.
   3. Victoria Linter Fixer가 413개 프로젝트를 수정했다.
   4. Merge Conflict Resolver가 921회 실행됐다.

3. 통합 결과

   1. 이들 워크플로우를 합치면 11,000회가 넘는 실행을 처리했다.
   2. 전체 성공률은 99%다.
   3. 구조화된 워크플로우, 제한된 LLM 권한, 자동 재시도, 사람의 MR 검토가 함께 작동한 결과다.

9. 운영에서 얻은 교훈: 셀프서비스·비용·데이터 분리

9.1. 표준화된 가드레일 위의 셀프서비스

1. 셀프서비스가 중요한 이유

   1. 엔지니어링 팀만 중앙 AI 팀에 요청하는 모델은 자동화 수요를 감당하기 어렵다.
   2. Flywire는 표준화된 가드레일을 제공하고, 각 팀이 그 범위 안에서 자신만의 워크플로우 단계를 만들도록 했다.

2. 참여하는 조직

   1. 엔지니어링뿐 아니라 Security, IT, Support 팀도 커스텀 워크플로우 단계를 안전하게 만들 수 있다.
   2. 공통 실행 제어와 권한 경계가 있으므로 각 팀의 자율성이 보안 기준을 무너뜨리지 않는다.

9.2. 모델 선택에 따른 비용 통제

1. 모든 단계에 가장 강한 모델이 필요하지 않다

   1. 비용 통제는 모델 선택에서 시작한다.
   2. 각 LLM 단계가 자신의 모델을 선언하도록 설계했다.
   3. 계획(Planning) 단계와 구현(Implementation) 단계가 서로 다른 모델을 사용할 수 있다.

2. 작업에 맞는 모델과 라우터 로드맵

   1. 단순한 분류나 포맷 변환에 최고 성능 모델을 쓰지 않고, 필요한 능력에 맞춰 모델을 선택한다.
   2. 이런 단계별 선택이 현재 비용을 통제한다.
   3. 향후에는 작업에 가장 비용 효율적인 모델을 자동 선택하는 Cost-Aware Model Router를 도입하려 한다.

9.3. 엄격한 데이터 영역 분리

1. 세 데이터 영역

   1. 엔지니어링 SDLC 데이터와 기업 운영 데이터, 민감한 결제 프로덕션 데이터를 엄격하게 분리한다.
   2. 한 영역의 편의성을 위해 다른 영역의 민감한 컨텍스트를 무심코 노출하지 않는다.

2. 수요가 클수록 우선순위가 필요하다

   1. 자동화 수요가 높다는 사실 자체가 모든 요청을 동시에 처리해야 한다는 뜻은 아니다.
   2. 높은 영향(High Impact)을 만드는 작업에 집중하고 우선순위를 관리하는 일이 플랫폼 운영의 핵심 책임으로 남는다.

10. 향후 로드맵

Orbit의 다음 단계는 더 많은 자율성을 주는 것이 아니라, 더 복잡한 작업도 통제된 구조 안에서 수행할 수 있게 만드는 것이다.

10.1. 샌드박싱과 재개 가능한 세션

1. 완전한 샌드박싱

   1. 모든 프로젝트 유형에서 복잡한 빌드, 로컬 환경, 테스트 스위트를 원활히 실행할 수 있도록 완전한 샌드박싱으로 이동한다.
   2. 현재 Fargate의 가벼운 컨테이너 한계를 넘어 프로젝트별 Toolchain을 안전하게 제공하는 것이 목표다.

2. Resumable Session

   1. 복잡한 다단계 작업을 위해 재개 가능한 세션을 도입한다.
   2. 장시간 작업을 하나의 무한 루프로 실행하는 대신 중간 상태를 보존하고 필요할 때 이어갈 수 있게 한다.

10.2. 플랫폼 안으로 들어오는 평가와 모델 라우팅

1. 내장 평가 도구

   1. 팀이 Orbit 자체에서 워크플로우 품질을 측정할 수 있도록 평가 도구를 확장한다.
   2. UI 또는 MCP 서버에서 배포·관찰·평가·개선을 연결한다.

2. Model-Agnostic Orchestration

   1. 여러 모델 벤더를 유연하게 라우팅할 수 있도록 오케스트레이션 계층을 Model-Agnostic하게 리팩터링한다.
   2. 자동 Model Router가 각 작업에 가장 비용 효율적인 모델을 선택하도록 한다.

3. Harness-Agnostic Platform

   1. 특정 에이전트 하네스 하나에 종속되지 않도록 플랫폼을 Harness-Agnostic하게 만든다.
   2. 현재는 Claude Agent SDK를 재사용하지만, 장기적으로 하네스 선택권을 넓혀 변화하는 생태계에 대응한다.

결론 및 시사점

1. 작게 시작한다: 반복적이고 정의가 분명한 작업 하나를 골라 실제로 작동하는지 증명한 뒤 규모를 키운다.
2. 모델은 가치가 생기는 곳에만 쓴다: 예측 가능한 작업은 코드로 유지하고, 추론이 필요한 지점에만 LLM을 호출해야 신뢰성과 비용 효율을 얻는다.
3. 가드레일과 사람을 계속 둔다: 소유권, Timeout, Rate Limit, 동시성 제어, 권한 제한, Merge Request 리뷰가 AI 실험을 일상 업무용 시스템으로 바꾼다.
4. 기업 AI의 목표는 에이전트가 모든 결정을 대신하는 것이 아니라, 사람이 책임 있게 검토할 수 있는 결과를 더 빠르고 반복 가능하게 만드는 것이다.
5. Skill로 먼저 가치를 검증하고 Orbit 워크플로우로 승격하면 대화형 실험과 운영 자동화 사이의 간극을 줄일 수 있다.
6. 구조화된 JSON, 단계별 평가, 실제 실행에서 만든 Golden Dataset은 모델이 바뀌어도 품질을 추적할 수 있는 운영 기반이 된다.

주요 발언 모음

“워크플로우는 오토파일럿이 아니다. 코드는 예측 가능한 부분을 처리하고, 모델은 실제 추론이 필요한 곳에서만 호출한다.”

“Skill로 시작하라. Skill은 작성 비용이 낮고 쉽게 반복 개선할 수 있으며 첫날부터 유용하다.”

“예측 가능한 부분은 결정론적 코드가 담당하고, 모델은 가치를 더하는 곳에서만 호출한다.”

“우리의 단위 업무는 여전히 Merge Request이며, 사람은 그 안에 남아 변경을 리뷰하고 승인한다.”

“Orbit은 모든 워크플로우를 배포하고, 측정하고, 개선하는 하나의 장소가 되는 것이 목표다.”

핵심 데이터 & 수치

• 사업 범위: 5,000곳 이상 고객, 240개 이상 국가·지역, 교육·헬스케어·여행·비즈니스 서비스 결제 처리
• 엔지니어링 조직: 약 400명, Java·Ruby·Go·Python·.NET·PHP 기술 스택
• AI 플랫폼 팀: 영상 시점 기준 약 6개월 전 4월에 정식 출범
• 내부 개발 속도: 약 1,000개의 커밋
• 외부 변화 속도: Claude Code 160개 이상 릴리스, 주요 AI 연구소 20개 이상 새 모델 출시
• 최근 30일 자동 코드 리뷰: 9,700회 이상, Merge Request당 평균 3분 미만
• Audit Fixer: 취약 의존성 수정을 위한 Merge Request 159개
• AI Readiness Fixer: 약 80개 저장소 개선
• Victoria Linter Fixer: 413개 프로젝트 수정
• Merge Conflict Resolver: 921회 실행
• 전체 운영 성과: 11,000회 이상 실행, 성공률 99%
• 보호 대상: PCI DSS·SOC 2 준수, PII·PHI·결제 데이터 분리와 통제

핵심 요약 (20줄)

1. Orbit: 오토파일럿이 아닌 워크플로우로 만드는 기업용 AI 자동화

2. URL: https://www.youtube.com/watch?v=rAUyRDOFyHU

3. 📁 Obsidian: /Users/flowkater/Obsidian/flowkater/flowkater/Study/YouTube다이제스트/2026-10-13-aiDotEngineer-Agents-in-Orbit-워크플로우는-오토파일럿이-아니다.md

4. Flywire는 5,000곳 이상 고객과 240개 이상 국가·지역의 고액 국제 결제를 처리해 AI에도 금융 수준의 보안을 요구한다.

5. 약 400명의 엔지니어가 Java, Ruby, Go, Python, .NET, PHP를 사용하며 공통 실행 기반으로 Victoria를 운영한다.

6. AI Platform Experience Team은 4월에 출범했고 약 6개월 만에 내부 도구에 거의 1,000개의 커밋을 쌓았다.

7. Orbit은 반복 작업을 없애지만 AI 에이전트를 열린 루프에 풀어놓는 오토파일럿이 아니다.

8. 예측 가능한 절차는 결정론적 코드로 고정하고 추론이 필요한 순간에만 작은 LLM 단계를 호출한다.

9. 각 에이전트는 저장소의 YAML 한 파일로 정의되며 일반 코드와 동일한 Merge Request 리뷰를 통과한다.

10. 코드 리뷰 에이전트는 GitLab 이벤트에서 시작해 메타데이터, 위험도, 과거 발견, 저장소를 준비한다.

11. 코드 리뷰 LLM은 코드를 읽고 정해진 JSON을 반환하지만 파일 수정이나 Push 권한은 갖지 않는다.

12. API·CLI, GitLab·Jira·Sentry·AWS Webhook, 예약 작업이 Orbit 워크플로우의 진입점이 된다.

13. 번역 동기화, Sentry 조사, 티켓 분류, AI Readiness 개선, 의존성 감사 수정도 워크플로우로 실행된다.

14. 여러 저장소의 마이그레이션과 라이브러리 업데이트를 대량 처리해 엔지니어링 규모를 확장한다.

15. Fargate에서 시작한 아키텍처는 오케스트레이션, 런타임, 세션 상태를 분리해 격리성과 확장성을 높였다.

16. Timeout, 공격적인 Rate Limit, 중복 실행을 막는 Lock이 대규모 에이전트 실행의 안전장치가 된다.

17. 네트워크, 도구, Skill, MCP별 허용 도구를 YAML에 선언해 각 LLM 단계의 권한을 최소화한다.

18. 엄격한 JSON Schema와 표적 재시도, OpenTelemetry 트레이스, Golden Dataset이 신뢰성을 측정한다.

19. 최근 30일 11,000회 이상의 실행에서 99% 성공률을 기록했고 코드 리뷰만 9,700회 넘게 수행했다.

20. 작은 작업부터 시작하고 모델은 가치가 있는 곳에만 쓰며 가드레일과 인간의 Merge Request 승인을 유지해야 한다.