Harness Engineering — 6장: 코드를 쓰지 않은 백만 줄

먼저 숫자를 탁자 위에 놓는다

원문은 2026년 2월 13일 OpenAI가 공개한 Ryan Lopopolo의 글을 출발점으로 삼는다. 5개월의 실험, 3명에서 7명으로 늘어난 팀, 약 100만 줄, 약 1,500개의 병합 PR, 1인당 하루 3.5개의 PR, 그리고 사람의 직접 수기 코딩 0줄이라는 수치가 제시된다.

5 개월 실험 기간

3 명 초기 엔지니어

7 명 후기 엔지니어

≈1M 코드 라인 앱·인프라·도구·문서·내부 개발도구 포함

≈1.5K 병합 PR 원문 수치

0 수기 코드 사람이 직접 작성한 코드

전통적 개발의 직관 사람이 늘면 소통·조정 비용도 늘어 프로젝트가 느려질 수 있다.

≠

Codex 팀에서 관찰된 결과 3명에서 7명으로 늘어난 뒤 오히려 1인당 처리량이 증가했다고 원문은 설명한다.

초기

≈0.25×

원문은 초기 1인당 산출이 전통적 엔지니어 약 0.25명 수준에 해당했다고 서술한다.

후기

3–10×

Harness가 성숙하면서 후반 1인당 처리량이 전통 방식의 3~10배까지 상승했다고 설명한다.

원문이 제시하는 이유는 사람 수가 늘어도 모두가 같은 코드를 직접 손으로 맞추는 구조가 아니었기 때문이다. 사람은 코드의 조정 비용보다 Harness의 완성도를 높였고, Harness가 좋아질수록 한 사람이 동시에 다룰 수 있는 Agent의 수가 늘었다.

다섯 원칙 — Agent를 잘 쓰는 법보다 Agent가 잘 일할 조건을 만든다

OpenAI Codex 팀의 다섯 원칙은 Prompt 작성법이 아니다. Agent에게 무엇이 보이는지, 무엇이 부족한지, 무엇을 강제로 지켜야 하는지, 무엇을 스스로 검증할 수 있는지, 그리고 문서를 어떤 두께로 제공할지를 설계한다.

01 Visibility

Agent가 볼 수 없는 것은 존재하지 않는 것과 같다

원문은 런타임 컨텍스트에서 접근할 수 없는 정보는 Agent 관점에서 사실상 존재하지 않는다고 설명한다. 이 원칙 때문에 팀은 Google Docs의 계획 문서와 Slack의 의사결정 기록을 코드 저장소로 옮겼다. 사람에게만 보이는 문서는 AI에게는 지식이 아니다.

Repo 안으로 이동

계획, 결정, 규칙을 Agent가 실제로 읽을 수 있는 장소에 둔다.

ExecPlans

초급 엔지니어도 끝까지 구현할 수 있을 정도로 자급적인 실행 문서 형식을 만든다.

핵심 → 인간에게 있는 지식이 아니라, 실행 중 Agent가 접근 가능한 지식이 실제 지식이다.

02 Capability Gap

왜 실패했는지 묻기 전에 무엇이 부족한지 묻는다

Agent가 막혔을 때 모델을 탓하거나 파라미터를 만지는 대신, 필요한 도구·guardrail·문서가 빠졌는지 확인한다. 느려졌다면 모델이 갑자기 나빠진 것이 아니라 새로운 상황에 맞는 검증 수단이 없을 수 있다는 관점이다.

도구를 새로 만든다

기존 라이브러리가 Agent 친화적이지 않으면 OpenTelemetry를 통합한 병행 도구까지 직접 만든다.

‘지루한 기술’을 우선한다

API가 안정적이고 학습 데이터에 많이 나타난 기술 스택을 선호해 Agent의 낯섦을 줄인다.

관점 전환 → 실패를 모델의 결함이 아니라 환경이 보내는 결손 신호로 읽는다.

03 Mechanical Enforcement

문서로 부탁하기보다 코드로 강제한다

“좋은 코드를 써라”는 조언보다 잘못된 패턴이 통과하지 못하게 만드는 것이 더 강하다. 원문은 취향과 품질 기준을 코드베이스에 직접 인코딩하는 방법을 핵심 원칙으로 제시한다.

Custom ESLint / Linter

나쁜 패턴을 정적 분석 단계에서 통과하지 못하게 한다.

Data Boundary Parsing

경계에서 파싱을 강제하고 Agent가 선택할 수 있는 라이브러리를 제한한다.

구조화된 CI 테스트

아키텍처 계층 위반 PR을 자동으로 차단한다.

자가 수정 가능한 오류 메시지

오류 메시지에 수정 안내와 문서 링크를 넣어 Agent가 스스로 고치게 한다.

Types→Config→Repo→ Service→Runtime→UI

역설 → 제약은 속도를 늦추는 벽이 아니라 Agent-first 개발에서는 오히려 속도의 원천이 된다.

04 Observability

Agent에게 눈을 달아준다

Agent가 결과를 읽기만 하는 것이 아니라 실제 실행 상태를 보게 한다. Chrome DevTools Protocol을 통해 DOM 스냅샷, 스크린샷, 탐색을 사용하고, 수정 후 격리된 앱 인스턴스를 띄워 전후 화면과 런타임 로그를 비교한다.

DOM구조를 직접 본다

Screenshot수정 전후를 비교한다

LogQL로그를 직접 질의한다

PromQL지표를 직접 검증한다

Worktree별 임시 관측성 스택

Victoria Logs + Victoria Metrics를 붙여 각 작업 공간이 독립적으로 관측 가능하게 한다.

문장을 실행 가능한 기준으로

“시작 시간 800ms 미만” 같은 요구가 문서의 희망이 아니라 Agent가 직접 확인하는 지표가 된다.

결과 → 원문은 이 피드백 구조가 단일 Codex 작업을 6시간 이상 사람 개입 없이 지속하게 했다고 설명한다.

05 Map, Not Manual

설명서를 주지 말고 지도를 준다

약 100줄의 짧은 AGENTS.md를 전체 구조의 입구로 두고, 깊은 전문 문서로 가는 포인터만 남긴다. 1000줄짜리 단일 지시 파일은 실제 작업에 필요한 컨텍스트를 잠식한다는 판단이다.

≈100 AGENTS.md lines

입구에는 오래 변하지 않는 조감도만 둔다. 상세 API 규칙, 테스트 전략, 구현 설명은 별도 문서로 분리하고 필요할 때 찾아가게 한다.

ORM 없음 GraphQL 없음 배제 규칙으로 선택지 축소

반직관적 기법 → “무엇을 쓰라”는 목록보다 “무엇은 존재하지 않는다”는 부정형 불변식이 컨텍스트를 더 아낄 수 있다.

Garbage Collection — 만드는 AI 옆에 치우는 AI를 둔다

원문은 Context Engineering과 Architecture Constraint에 더해 코드베이스의 엔트로피를 관리하는 세 번째 축으로 Garbage Collection을 제시한다. 이 Agent는 기능을 만들지 않는다. 모순과 위반을 찾고 정리한다.

Dedicated Cleanup Agent

만들지 않고, 어긋난 것을 찾는다

주기적으로 문서의 모순과 아키텍처 위반을 스캔하고, 문제를 발견하면 표적화된 리팩터링 PR을 자동 생성한다.

기능 구현 안 함
문서 모순 탐색
아키텍처 위반 탐색
수정 PR 자동 생성

생산량이 늘수록 불일치도 자란다

Agent가 많은 코드를 빠르게 만들수록 작은 불일치와 오래된 문서, 계층 위반이 누적될 가능성도 커진다. 그래서 원문은 “다른 AI가 남긴 혼란을 치우는 AI”를 별도 역할로 둔다.

낮은 엔트로피 코드 증가와 함께 불일치 누적

원문은 Garbage Collection Agent가 만든 표적 리팩터링 PR을 사람이 약 1분 안에 검토할 수 있다고 설명한다.

시스템은 만드는 힘만으로 유지되지 않는다. 생성의 속도가 빨라질수록 정리의 리듬도 빨라져야 한다. Harness는 생산을 가속하는 장치이면서 동시에 생산이 남기는 혼란을 회수하는 장치다.

속도의 증거는 있다. 장기 품질의 답은 아직 없다

이 장은 성공담으로 끝나지 않는다. 원문은 백만 줄과 빠른 PR 처리량을 인정하면서도, 그 숫자가 유지보수성과 기능 정확성을 자동으로 증명하지는 않는다고 선을 긋는다.

증명된 것 — 속도

5개월 동안 약 100만 줄, 약 1,500개 PR, 사람의 수기 코딩 0줄이라는 실험은 Agent-first 개발이 높은 처리량을 만들 수 있음을 보여준다.

Harness가 성숙할수록 Agent 병렬 운용 능력이 커질 수 있다.

제약과 관측성이 자동화된 실행 시간을 길게 만들 수 있다.

아직 남은 것 — 유지보수와 기능 정확성

원문은 빠르게 만든 코드가 여섯 달 뒤에도 쉽게 고쳐질지, 사람의 코드처럼 미래의 유지보수자를 위한 구조적 단서를 충분히 남길지 질문한다.

하루 3.5 PR을 충분히 리뷰할 수 있는가?

100만 줄은 요구 변경 시 얼마나 잘 움직이는가?

내부 품질과 실제 사용자 기능의 정확성을 모두 검증하고 있는가?

원문이 지적하는 맹점

Martin Fowler 팀의 Birgitta Böckeler 분석을 인용해, OpenAI의 프레임워크가 내부 품질과 유지보수성에는 강하지만 기능·행동의 정확성을 충분히 검증하는 장치는 부족하다고 지적한다.

빠르게 만든다는 것과 오래 살아남게 만든다는 것은 다른 공학이다. Harness가 속도를 만들었다면, 다음 질문은 그 속도가 남긴 코드를 누가 미래까지 책임질 것인가다.

같은 모델, 다른 Harness — 더 깨끗한 비교

원문은 OpenAI 사례의 장기 품질 문제가 아직 열려 있다는 점을 인정한 뒤, LangChain의 Terminal Bench 2.0 결과를 더 직접적인 비교로 제시한다. 모델을 바꾸지 않고 Harness만 바꿔 성능이 달라졌다는 사례다.

52.8% Top 30 변경 전

→

66.5% Top 5 변경 후

Model 동일 System Prompt 변경 Tool Configuration 변경 Middleware Hooks 변경

같은 두뇌에 다른 손과 발, 다른 눈과 브레이크를 붙이면 결과가 달라진다. 이 장이 끝내 말하는 것은 모델의 크기가 아니다. 지능이 실제 일로 변환되는 과정에는 반드시 구조가 필요하다.

백만 줄은 숫자다.
그러나 숫자가 가리키는 것은 코드의 양보다 사람의 자리다.

사람은 한 줄 한 줄을 쓰는 자리에서 물러나
무엇을 보게 할지, 무엇을 못 하게 할지,
무엇으로 확인하게 할지를 설계하는 자리로 옮겨갔다.

그 이동이 커질수록 한 가지 질문은 더 중요해진다.
빠르게 만든 것을 오래 믿을 수 있는가.

Harness Engineering은 그 질문까지 포함할 때 비로소 공학이 된다.

이 웹페이지는 첨부 문서 《Harness Engineering》의 §06 「OpenAI Codex团队：零行手写代码的百万行产品 / OpenAI Codex Team: One Million Lines, Zero Handwritten」 (PDF 29–32쪽)에만 근거해 재구성했다. 원문의 날짜, 인물, 수치, 다섯 원칙, 구현 예, Garbage Collection, 품질에 대한 문제 제기, LangChain 비교를 원문 맥락 안에서 보존했으며 외부 자료를 이용한 검증·교정·추가는 수행하지 않았다.