「인간은 코드를 작성하지 않고 리뷰도 하지 않는다」를 5개월간 실행한 이야기──OpenAI Frontier의 극한 harness

지금까지의 기사(L0–L7 래더, OSS 선택 방법, Cloudflare의 다중 에이전트 취약점 헌팅)에서 반복해 온 「주역은 모델이 아니라 harness」라는 이야기. 그 극한이 바로 이것입니다.

OpenAI Frontier의 Ryan Lopopolo가 3인 팀으로 5개월 동안 어떤 내부 프로덕트를 만들었습니다. 조건은 「인간은 코드를 작성하지 않는다. 코드 리뷰도 하지 않는다」였습니다. 결과는 100만 행 초과, 약 1500개의 PR, 하루 약 10억 토큰(시장 가격으로 일 $2~3k)이었습니다. 보통이라면 붕괴했을 상황입니다. 왜 붕괴하지 않았을까요──답은 전부 harness에 있습니다.

「인간이 작성하지 않고 리뷰하지 않는다」는 실제로 어떤 의미인가

먼저 정확히 짚고 넘어갑시다. Ryan이 스스로 코드를 작성하는 것을 의도적으로 거부한 이유는, 「엔터프라이즈에 배포할 수 있는 에이전트를 만든다면, 내가 하는 모든 일을 해낼 수 있어야 하기」 때문입니다. 6~8개월의 harness 반복을 통해, 모델은 개별 엔지니어와 동등한 능력에 도달했다고 보고 있습니다.

단, 「0% 리뷰」라는 말을 그대로 믿지는 마십시오. 정확히는──머지(merge) 전에 리뷰로 막는 것을 그만두었다는 뜻입니다 ("Most of the human review is post merge at this point"). 인간은 기술적인 게이트키퍼(gatekeeper)에서 벗어나, 동기적인 주의(attention)라는 희소 자원이 되었습니다. 게다가 배포 전에는 「인간이 승인하는 smoke test」를 남겨두고 있습니다. 완전한 무인은 아니며, 「사전 차단용 인력 리뷰를 harness로 대체했다」가 실체입니다.

리뷰를 그만두고, 무엇이 오류를 막는가

이 부분이 시리즈의 핵심입니다. 인간이 사전에 확인하지 않는다면, 대신 무엇이 막아주는가. 그들은 다층적인 자동화를 쌓았습니다.

메커니즘	내용
CI가 벽	"CI가 통과해야 한다(CI has to pass)"를 평문(plain text)으로 방침화. flake(린트 오류)나 머지 충돌도 에이전트가 스스로 수정함
관측 우선(Observability First)	발상을 전환: 「환경에 에이전트를 spawn(생성)한다」가 아니라 「에이전트를 spawn한다, 그것이 입구다". Jaeger/Prometheus 등의 트레이스(trace)를 에이전트가 직접 쿼리하여 장애를 스스로 알림
리뷰용 에이전트 + 합의	별도의 프롬프트를 가진 PR 리뷰 에이전트 ("P2 이상만 지적, 머지 지향적"). 작성 에이전트와 리뷰 에이전트가 인간의 판결 없이 협상하여 합의함
품질 점수 + markdown 가드레일	tech tracker(markdown 표)에 업무 로직의 가드레일을 열거. 에이전트가 자기 감사(self-audit)
실패는 능력 분해로 해결	에이전트가 실패했을 때 프롬프트를 수정하는 것이 아니라 「어떤 능력·문맥·구조가 결여되었는가」를 묻고, 작고 관측 가능한 부품으로 나눔

ClickHouse의 「판정의 벽」과 Glasswing의 적대적 검증이 여기서 합류합니다. 「CI가 벽」 = 판정의 벽, 「리뷰 에이전트의 합의」 = 두 개체를 대립시키는 적대적 검증입니다. L0–L7로 말하자면, L6(hook/CI를 통한 강제)와 리뷰 합의라는 거버넌스(governance) 계층을 극한까지 구축한 모습입니다.

코드베이스를 「에이전트가 읽을 수 있는」 형태로

또 다른 핵심은 조직과 코드를 "에이전트가 읽을 수 있고 자치할 수 있는" 형태로 재구축한 것입니다.

• 500개의 NPM 패키지: 7인 팀에게는 과할 정도로 엄격한 아키텍처. 이유는 「각 인간이 10~50체의 에이전트로서 행동하기」 때문에, 서로 충돌하지 않도록 하기 위함입니다.
• 문서 = 실행 가능한 문맥: spec.md (구현을 제외한 고수준 PRD), agent.md (에이전트가 읽는 짧은 가이드), core_beliefs.md

（팀 구성·제품 비전·12개월 로드맵）, tech tracker (신뢰성·관측 요구사항). "비기능 요구사항을 agent에게 prompt-inject 하는 공간". -
스킬은 단 6개. 새로운 필요가 생기면 신규 제어 흐름을 만드는 대신, 기존 스킬을 확장.
inner-loop 빌드는 반드시 1분 이내. 이를 지키기 위해 끊임없이 리팩터링 (Make → Bazel → Turbo → NX). "토큰이 매우 저렴하기 때문에, 상시 이 시스템을 정원 가꾸듯 다룰 수 있다".
CLI 퍼스트 (GUI가 아닌 구조화된 CLI). UI는 텍스트로 래스터화(rasterize)하며, 불필요하게 긴 출력(테스트 스위트 등)은 실패 여부만 보이도록 wrap.
ghost 라이브러리 / spec 주도: Symphony를 구현이 아닌 사양(specification)으로서 배포하여, agent가 사양으로부터 재생성하도록 함.
MCP에는 회의적: 그는 MCP에 대해 bearish(약세론적)하다. harness가 MCP의 토큰을 전부 강제로 문맥(context)에 주입해 버려, auto-compaction을 방해하고 agent가 도구 사용법조차 잊어버리는 경우가 있기 때문이다. 실제로 사용하는 호출은 몇 개뿐인데, 그 전체 비용을 지불하게 된다. 그래서 팀은 Playwright를 직접 연결하는 대신, 몇 줄의 얇은 shim CLI를 세워 호출한다. (OSS 회차에서 "MCP는 표준으로 정착할 것"이라고 썼지만, 현장에서는 "얇은 CLI"가 선택되는 상황도 있다는 생생한 목소리이다.)
의존성은 "내부로 흡수": 코드가 거의 공짜나 다름없기(토큰이 매우 저렴함) 때문에, 수천 행 규모의 의존성이라면 그 자리에서 in-house화하여 사용하지 않는 범용 부분은 깎아내고 필요한 부분만 남긴다. "쓸데없는 플러그인의 종말". 다만 이면도 솔직히 말하자면──오픈 소스의 "many eyes(많은 눈)"에 의한 보안 점검을 잃게 되며, 타인이 이미 겪었던 실패를 스스로 다시 겪게 된다.
Symphony의 "rework" 상태: PR이 "머지 가능하지 않음"이라고 판단되면, Elixir 서비스가 work tree와 PR을 통째로 버리고 처음부터 다시 시작한다. "코드는 일회용"이라는 원칙을 철저히 따르는 메커니즘으로, 버리기 전에 반드시 "왜 안 됐는가"를 묻고 그 배움을 다음 단계에 각인시킨다.

harness가 자신을 개선한다──「L7」의 그림자

이 부분이 시리즈의 ①과 가장 깔끔하게 연결되는 지점입니다. 이 harness는 돌리면 돌릴수록 스스로 좋아지도록 설계되어 있습니다.

먼저 개인 레벨. Codex에게 자신의 session 로그를 읽게 하여, "어떻게 하면 이 도구를 더 잘 사용할 수 있을까"를 묻습니다──에이전트의 자기 성찰입니다.

그리고 팀 레벨. 팀원 전체의 agent 궤적을 blob storage에 수집하고, 매일 그 위에서 agent 루프를 돌리며 "팀으로서 어디를 개선할 수 있는가"를 추출하여 리포지토리에 환원합니다. PR 코멘트도, 실패한 빌드도, "그 시점에 agent에게 문맥이 부족했다"는 signal로 취급하여 수집한 뒤 repo로 되돌립니다. 이렇게 해서 모두가 다른 모든 사람의 행동으로부터 무료로 배웁니다.

이는 L0–L7에서 말하는 L7(에이전트가 촉구받지 않고 스스로 지시를 작성함)의 조직 규모에서의 구현에 가깝습니다. 인간이 "이것을 기억해 둬"라고 손으로 쓰는 것이 아니라, 궤적으로부터 자동으로 "좋은 것이란 무엇인가"를 추출하여 문서·스킬·테스트로 다시 구워냅니다. ①에서 "L7은 아직 최전선이다"라고 썼지만, Frontier는 그것을 팀의 일과로 돌리고 있습니다──이 점이 저에게는 가장 큰 울림을 주었습니다.

숫자와, 고장 난 부분

과장 없이, 긍정과 부정 양쪽을 모두 다룹니다.

• 속도: Codex Mini의 첫 달은 인간보다 10배 느렸다. 인프라를 정비한 후에는 1인당 하루 5~10 PR (모델 업데이트 전에는 3.5). Symphony 투입으로 생산성 5배 향상.
• 모델 업데이트의 충격: Codex 5.2→5.3으로 가면서 background shell이 사라졌고, 빌드 계통을 다시 만들어 1분 이내를 사수함. 5.4에서 100만 토큰 문맥이 해금됨.
• 잘 되지 않았던 부분: greenfield(백지 상태)에서만 성립한다고 본인이 명시함. 0에서 1을 만드는 신규 프로토타입은 아직 인간의 조종이 필요함 (agent는 기존 계통의 확장은 잘하지만, 백지 상태에서의 발명은 서툶). 가장 어려운 것은 "인터페이스의 형태가 미지의 구조 리팩터링". 그리고 의외의 세금──팀의 agent들끼리 서로 밟지 않도록 매일 45분의 스탠드업 미팅이 필요함.

harness에 걸 것인가, 훈련에 걸 것인가

사실, 이 실험의 가장 깊은 논점은 바로 이 지점이라고 생각합니다. Ryan은 "harness를 더욱 정교하게 만들 것인가, 아니면 훈련 (training) 프로세스에 투자할 것인가──그 사이에는 근본적인 긴장이 존재한다"라고 말합니다. 모델을 똑똑하게 만드는 것(훈련)과 모델의 외부를 구축하는 것(harness)은 리소스 확보를 위한 경쟁 관계에 있습니다.

그의 해답은 on-policy 방식의 harness 설계입니다. 가드레일 (guardrail)을 특수한 발판이나 프롬프트 기술 (prompt engineering)로 외부에 덧붙이는 것이 아니라, "모델이 이미 내뱉고 있는 출력물(=코드)에 네이티브한 형태로" 통합하는 것입니다. 이렇게 하면 모델이 아무리 진화하더라도 harness와 충돌하지 않습니다. 그의 말을 빌리자면 다음과 같습니다.

만약 모든 가드레일을 Codex가 이미 생성하고 있는 출력물(=코드)에 네이티브한 형태로 만들 수 있다면, 모델이 계속 진보하더라도 마찰이 일어나지 않을 것이라고 생각합니다.

이를 뒤집어 말하면, 프롬프트 기술이나 특수한 scaffold (비계)로 "모델을 상자 안에 가두는" 방식은 모델이 똑똑해질수록 그 효력이 떨어지게 됩니다. 그래서 그는 이렇게 말합니다. "모델이 (스스로) 생각할 수 없었을 때는 상자에 가둘 수밖에 없었다. 이제는 모델과 harness가 상자 그 자체가 되어, 충분한 문맥과 선택지를 제공하며 똑똑하게 나아가게 한다."

이 부분이 제가 이 시리즈를 통해 가장 전달하고 싶었던 핵심입니다. harness 투자가 "일회용이 되지 않는" 이유는 그것이 모델의 출력물 그 자체(코드, 테스트, spec) 위에 구축되기 때문입니다. 프롬프트의 잔기술은 다음 모델에서 구식이 되겠지만, "CI가 통과된다", "테스트가 늘어난다", "spec으로부터 재생성할 수 있다"라는 구조는 모델이 강해질수록 그 효과가 커집니다. 베팅을 한다면

마지막으로 하나 더. 그조차도 "Spark를 어떻게 사용해야 할지 아직 모르겠다"라고 인정하고 있습니다. 최전선에서도 더듬거리며 길을 찾고 있습니다. 그렇기에 모델의 똑똑함에 베팅하기보다, 외부(outside) 즉, harness에 베팅하는 것이 아마 더 오래 효과가 지속될 것입니다. 시리즈를 통해 저는 그 판단에 베팅하고자 합니다.

참고

• 1차 (인터뷰): Extreme Harness Engineering for Token Billionaires — Ryan Lopopolo, OpenAI Frontier (Latent Space)
• 시리즈 관련:

이 기사는 「AI Watch」에도 게재되었습니다. 최첨단 AI를 기술적인 내용까지 일본어로 풀이하고 있습니다.

Discussion