Missions의 작동 방식 (5분 읽기)

Missions는 넓고 복잡한 작업을 한 컨텍스트에 욱여넣지 않고, 새 에이전트가 좁은 목표만 맡도록 쪼개는 방식으로 장기 자율 작업을 안정화한다. 핵심 전제는 에이전트가 자신의 context에 매우 민감하다는 점이다.

컨텍스트가 길어질수록 두 가지 문제가 커진다.

• Irrelevant context accumulation: 현재 목표와 무관한 정보가 쌓여 신호대잡음비가 떨어진다.
• Adversarial context accumulation: 구현한 당사자가 자기 작업을 평가하면 기존 판단에 끌려 객관성이 무너진다.

그래서 시스템은 역할을 분리한다. Orchestrator는 계획과 분해, 진행 관리와 최종 완료를 담당하고, Workers는 명세가 분명한 기능을 구현하며, Validators는 별도의 fresh context로 완성도를 검증한다. 구현과 평가를 같은 에이전트가 함께 끌고 가는 구조를 피하고, 검증은 반드시 독립된 주체가 맡는다.

이 철학은 test-driven development를 두 수준에서 적용하는 설계로 이어진다.

• worker는 코드보다 먼저 테스트를 작성한다.
• mission 수준에서는 기능 정의보다 먼저 validation contract를 만든다.

이 순서가 중요한 이유는, 먼저 구현을 만들면 검증 기준이 그 구현에 끌려가 버리기 때문이다. 검증 계약은 실제 사용자가 쓰는 방식의 black-box 기준으로 검사되며, 코드 내부를 보는 평가가 아니다.

상태도 한 에이전트에 몰아넣지 않는다. feature list, research notes, 운영 규칙, 지식 베이스처럼 공유 아티팩트로 분산하고, 각 에이전트는 지금 필요한 것만 읽는다. 여기에 모델 특성까지 맞춘다. 계획과 판단은 강한 모델, 실행은 비용 효율적인 모델, 검증은 신중하고 비판적인 모델을 쓰는 식이다.

실행 흐름은 비교적 명확하다. 사용자 요구를 정리한 뒤 validation contract를 만들고, 기능을 milestone 단위로 쪼갠다. runner가 feature별 worker를 순차 실행하고, milestone이 끝나면 fresh validator가 검증한다. 문제가 나오면 orchestrator가 fix feature를 만들어 다시 돌리고, 통과할 때까지 반복한다.

실제 사례로는 Slack 클론을 만든 mission이 있었다. 총 16.5시간 동안 진행됐고, orchestration은 0.38시간(2.3%), implementation은 9.98시간(60.5%), validation은 **6.14시간(37.2%)**를 차지했다. 전체 185개 runs, 778.5M tokens, 38.8k lines of code가 생성됐고, 이 중 **52.5%**가 테스트였으며 statement coverage는 **89.25%**였다.

검증 루프도 지속적으로 작동했다. 6개 milestone이 2~4회의 validation round 안에서 수렴했고, validator가 발견한 81개 issue 중 21개 fix features가 생성됐다. 그 비율은 구현 feature 61개 대비 **34.4%**로, 단순 구현보다 검증과 수정을 상당히 많이 돌린 구조였다.

결국 Missions는 소프트웨어 개발의 루프를 닫는 첫 버전이다. 모델이 더 좋아질수록 더 정교한 spec, 더 적은 실수, 더 신뢰할 수 있는 validation이 가능해지고, 모델이 더 빠르고 저렴해질수록 더 많은 validation round를 돌릴 수 있다. 현재는 /missions를 Droid 세션에서 실행해 시작할 수 있다.