루프엔 판정자가 필요하다

7월에 오케스트라 구성을 정리했다. 이름 붙은 에이전트 다섯, CLAUDE.md 하나, QA를 강제하는 hook. 그 뒤로 디자인 시스템 스펙(마크다운 파일 31개)에 루프와 서브에이전트를 돌려 왔는데, 같은 질문이 자꾸 떠올랐다. 모델은 계속 좋아진다. 그러면 내 작업 방식도 따라 바뀌어야 할까, 아니면 지금 이대로 괜찮을까.

그래서 감으로 넘기지 않고 제대로 조사했다. 네 갈래로 나눠 보고, 모든 주장에 날짜를 붙이고, 가능한 한 1차 출처를 확인했다. 이전 글은 손대지 않는다. 날짜를 붙여 둔 데는 이유가 있다. 이 글은 정정이 아니라 다음 기록이다.

찾은 것을 한 줄로 요약하면

모델이 좋아질수록 그 주변에 써 둔 단계별 절차는 지워진다. 끝까지 남고 오히려 가치가 커지는 건, 작업이 정말 끝났는지 판단하는 독립된 검사다.

시작은 거의 농담 같은 루프였다. 2025년 7월 Geoffrey Huntley가 "Ralph"를 공개했다. 같은 프롬프트 파일을 코딩 에이전트에 끝없이 다시 넣는 bash while 루프이고, 매 회차 새 컨텍스트로 시작한다. 루프 한 번에 작업 하나, 테스트는 "backpressure"로 쓴다. 그는 단점도 숨기지 않았다. 결과가 비결정적이고, 코드베이스가 가끔 "깨진 채로 깨어난다." 그래서 그린필드 작업에만 쓴다고 했다.

15개월 뒤 이 루프는 기본 기능이 됐다. Claude Code의 /goal은 Stop hook이다. 매 턴이 끝날 때마다 별도의 작은 모델이 조건을 충족했는지 판정한다. 문서는 측정 가능한 종료 상태 하나, 제약 하나, 상한 하나를 정하라고 한다. "npm test exits 0, 다른 테스트 파일은 건드리지 않음, 아니면 20턴 후 중단" 같은 식이다. /loop는 다른 축을 맡는다. 고정 간격으로 돌거나, 에이전트가 1분에서 1시간 사이에서 다음 대기 시간을 스스로 정한다. 반복 루프는 7일 뒤 만료되니, 잊어버린 루프가 영원히 도는 일은 없다.

Ralph에서 /goal로 오면서 실제로 바뀐 건 "끝"을 누가 선언하느냐다. 일하는 에이전트가 아니라 다른 무언가가 판정한다.

내 스펙 루프에 적용하면

전에는 결과가 그럴듯해 보이면 멈췄다. 지금은 drift와 coverage 스크립트의 exit code를 보고 멈춘다. 에이전트는 자기가 고칠 수 있는 검사를 조작하기 때문에, 루프는 이 스크립트를 읽기만 할 수 있다.

2025년 6월, 하루 간격으로 글 두 편이 나왔는데 서로 반대 진영처럼 보였다. Cognition은 멀티에이전트를 만들지 말라고 했다. 모든 행동에는 암묵적인 결정이 담겨 있고, 병렬 에이전트들은 서로 어긋나는 결정을 내린다는 이유였다. 예로 든 장면은 한 서브에이전트가 마리오풍 배경을 그리는 동안 다른 서브에이전트가 그 배경과 어울리지 않는 새를 그리는 것이다. 디자인 시스템에서 늘 보는 버그다. Anthropic은 자사 멀티에이전트 리서치 시스템이 단일 에이전트보다 90.2% 높은 성능을 냈다고 했는데, 같은 글에서 대부분의 코딩 작업에는 잘 맞지 않는다고도 했다.

알고 보면 두 글은 조건에 대해 같은 말을 하고 있었다. 읽는 일은 병렬로 하면 도움이 된다. 공유 산출물을 병렬로 쓰면 문제가 생긴다.

2026년 문서는 이걸 분명히 적어 둔다. Claude Code의 agent teams 문서는 팀원을 3~5명으로 두라고 권하고, 흩어진 5명보다 집중한 3명이 낫다고 하며, 두 팀원이 같은 파일을 편집하면 서로 덮어쓴다고 경고한다. Anthropic이 에이전트 16개로 만든 C 컴파일러에는 오케스트레이터 에이전트가 아예 없었다. 락 파일과 git, 그리고 작업을 나누는 기준(오라클)으로 쓴 GCC가 전부였다.

내가 바꾼 것

7월의 오케스트라는 디자이너, 카피라이터, 개발자, QA처럼 직함으로 짜여 있었다. 근거를 보면 소유권으로 짜는 게 맞다. 리서치와 감사는 넓게 병렬로 돌린다. 스펙 파일 하나에는 작성자를 딱 한 명만 둔다. 파일 간 일관성은 에이전트끼리 회의할 일이 아니라 스크립트가 맡을 일이다. 접근성, 토큰 사용, 구현 가능성 같은 병렬 리뷰 관점은 여전히 쓸모가 있다.

2025년 중반 "context engineering"이 prompt engineering의 자리를 넘겨받았다. 다음 단계에 꼭 필요한 정보를 정확히 컨텍스트 창에 넣는 일이다. Anthropic은 그 한계를 분명히 적었다. 컨텍스트는 넣을수록 효용이 줄어드는 유한한 자원이고, 커질수록 품질이 떨어진다.

형식은 마크다운으로 굳어졌다. AGENTS.md는 2025년 12월 Linux Foundation 산하 Agentic AI Foundation으로 옮겨 갔다. Agent Skills는 progressive disclosure 방식으로 필요할 때만 로드된다. 2026년 4월에는 Google Labs가 DESIGN.md 초안을 공개했다. 위쪽에 디자인 토큰을, 아래쪽에 그 토큰을 정한 이유를 산문으로 적어서 에이전트가 색의 용도를 추측하지 않아도 되게 한 형식이다.

내 구성을 설명할 말은 Thoughtworks의 Birgitta Böckeler에게서 얻었다. Guide는 에이전트가 행동하기 전에 방향을 잡아 준다. 스펙, 규칙, AGENTS.md가 여기 속한다. Sensor는 행동한 뒤에 확인한다. 테스트, 린터, 리뷰가 그렇다. 내 스펙은 guide이고, drift와 coverage 스크립트는 sensor다.

김빠지는 결과도 있다

ICLR 2026 연구에 따르면 컨텍스트 파일은 과제 성공률을 오히려 조금 낮추는 경향이 있었고, 비용은 20% 넘게 올렸다. 에이전트는 지시를 따르느라 일을 더 했을 뿐, 더 잘하지는 않았다. 기계가 읽을 수 있는 디자인 시스템이 생성 UI의 품질을 높인다는 통제 연구도 아직 없다. DESIGN.md도, 내 스펙도 마찬가지다. 그래서 항상 로드되는 규칙은 짧고 명시적으로 쓴다. 정확한 값을 적고, "대체 금지"를 분명히 써 둔다. 컴포넌트 세부 사항은 필요할 때만 로드되게 둔다.

생성은 싸졌지만 확인은 그렇지 않다. 전혀 다른 각도의 데이터가 같은 방향을 가리킨다. METR의 2025년 실험에서 숙련된 개발자들은 AI를 쓸 때 19% 느려졌는데, 본인들은 더 빨라졌다고 믿었다. Stack Overflow의 2026년 5월 펄스 설문에서는 업무 중 에이전트 사용이 31%에서 59%로 늘었고, 응답자의 63%는 에이전트를 감독 없이 돌리는 일이 거의 없거나 전혀 없다고 답했다. Anthropic이 2026년 3월 Code Review를 내놓으면서 밝힌 이유도 같은 맥락이다. 엔지니어 한 명이 만드는 산출물이 늘면서 리뷰가 병목이 됐다는 것이다.

게다가 검사는 조작당한다. 테스트를 통과하는 것 자체가 부정행위인 ImpossibleBench에서도 프런티어 모델들은 자주 부정을 저질렀다. 유망한 해법은 테스트를 읽기 전용으로 만드는 것이었다.

내 콜드스타트 테스트가 하는 역할

새 에이전트에게 스펙 파일 31개만 주고 컴포넌트 네 개를 만들게 한다. 첫 실행에서는 스펙이 부족해 추측해야 했던 곳이 약 120군데 나왔고, 파일 세 개에서 radius가 6px인지 pill인지 서로 충돌했다. 처음엔 일회성 감사로 여겼다. 그런데 이게 업계가 없다고 말하는 그 평가였다. 이 스펙으로 실제로 무언가를 만들 수 있는가? 그래서 회귀 테스트로 만든다. 과제는 고정하고, 스펙이 바뀔 때마다, 새 모델이 나올 때마다 다시 돌리고, 채점은 스크립트가 한다. 만든 에이전트가 스스로 채점하는 일은 없다. 새 모델이 나오면 규칙을 걷어 내 보고, 빼면 콜드스타트가 다시 실패하는 규칙만 남긴다.

정직하게 말하면

"이 방법이 효과가 있다고 증명됐다"는 주장이 아니다. 효과가 있는지 잴 수 있는 방법이라는 주장이다. Figma의 2026 리포트에 따르면 개발 업무를 하는 디자이너는 1년 만에 21%에서 41%로 두 배가 됐다. 더 귀한 역량은 코드를 쓰는 능력이 아니라, 무엇이 맞는 결과인지 정의해서 기계가 확인할 수 있게 만드는 능력이다. 디자인 리뷰가 늘 해 온 일이다.