아우터 루프(outer loop)는 에이전트가 코드를 만들고 테스트를 돌리는 내부 실행 루프 바깥에서, 사람이 결과를 승인하고 책임지는 경계다. 에이전트가 더 많은 일을 할수록 엔지니어의 핵심 역할은 직접 타이핑보다 “무엇을 통과시킬 수 있는가”를 판단하는 일로 이동한다.
세 가지 핵심 단어
| 개념 | 의미 |
|---|---|
| Quality | 에이전트를 풀어놓기 전에 설치한 테스트, 리뷰, 정책, 관찰성 같은 증거 생성 장치 |
| Verdict | 결과를 ship, block, redirect, narrow, reject 중 무엇으로 처리할지 결정하는 생산 판단 |
| Answerability | 나중에 질문을 받았을 때 무엇이 바뀌었고 왜 안전했는지 설명할 수 있는 능력 |
에이전트는 capability를 제공한다. 조사하고, 구현하고, 테스트하고, 보고한다. 하지만 agency는 바깥에 남아야 한다. 승인, 책임, 리스크 수용은 모델이나 하네스가 아니라 시스템 소유자가 해야 한다.
왜 지금 중요한가
AI가 만든 코드 비중이 늘수록 생성은 싸지고 검증은 병목이 된다. 속도만 올리면 “코드는 많아졌는데 통제는 느린” 신뢰-검증 격차가 생긴다. 아우터 루프는 이 격차를 줄이는 운영 구조다.
실무에서 아우터 루프는 다음 질문으로 드러난다.
- 이 변경이 어떤 요구사항을 만족하는가?
- 어떤 테스트와 관찰 결과가 안전성을 뒷받침하는가?
- 실패하면 어느 범위까지 피해가 번지는가?
- 누가 최종 verdict를 내렸고, 그 근거는 어디에 남아 있는가?
하네스·루프·팩토리와의 관계
agent-harness는 모델을 파일, 도구, 메모리, 권한, sandbox, 복구 메커니즘으로 감싼 실행 구조다. ai-agent-tips-loop-engineering은 이 하네스를 조사→구현→검증→반복 사이클로 만든다. 여러 루프가 동시에 돌아가면 소프트웨어 팩토리가 된다.
아우터 루프는 이 팩토리의 출구다. 내부에서는 에이전트가 능력을 발휘하지만, 외부 시스템으로 결과가 들어가기 전에는 사람이 증거를 보고 verdict를 내려야 한다.
적용 체크리스트
- 완료 조건을 프롬프트가 아니라 검증 가능한 수용 기준으로 쓴다.
- 에이전트가 생성한 diff와 테스트 결과를 별도 검증자나 CI가 확인하게 한다.
- 승인 로그에 “왜 ship/hold/reject 했는가”를 남긴다.
- 자동 머지는 낮은 위험·높은 증거 작업부터 제한적으로 켠다.
- 사고가 나면 프롬프트가 아니라 하네스, 권한, 테스트, 관찰성까지 같이 고친다.
아우터 루프를 소유한다는 것은 에이전트를 못 믿는다는 뜻이 아니다. 에이전트가 낸 결과를 조직이 설명 가능한 방식으로 받아들이는 구조를 만든다는 뜻이다.
참고 자료
- Own the Outer Loop — Addy Osmani (2026-07)