본문으로 건너뛰기
블로그로 돌아가기
OpenAI Harness Engineering: 수동 코드 0줄로 제품을 만든 에이전트 퍼스트 개발 실험
튜토리얼

OpenAI Harness Engineering: 수동 코드 0줄로 제품을 만든 에이전트 퍼스트 개발 실험

9분 읽기0

OpenAI Harness Engineering: 수동 코드 0줄로 제품을 만든 에이전트 퍼스트 개발 실험

사람이 직접 작성한 코드가 단 한 줄도 없는데 제품이 출시되었습니다. 100만 줄의 코드, 1,500개의 Pull Request, 수백 명이 매일 사용하는 내부 소프트웨어. 이것이 OpenAI의 "Harness Engineering" 프로젝트가 5개월 만에 달성한 결과입니다.

Harness Engineering이란 OpenAI 팀이 Codex(AI 코딩 에이전트)만으로 제품을 구축하고 출시한 실험 프로젝트입니다. 핵심 철학은 "Humans steer. Agents execute."(사람은 방향을 잡고, 에이전트가 실행한다)입니다.

2026년 2월 11일, OpenAI 엔지니어 Ryan Lopopolo가 공개한 이 사례는 에이전트 퍼스트 개발(Agent-First Development)의 가장 구체적인 실전 보고서입니다. 단순한 데모가 아닌 실제 운영 제품의 이야기이기 때문에 개발자와 기술 리더 모두에게 시사점이 큽니다.

빈 저장소에서 100만 줄까지: 5개월의 기록

2025년 8월 말, 첫 커밋이 올라갔습니다. GPT-5 기반 Codex CLI가 저장소 구조, CI 설정, 포매팅 규칙, 패키지 매니저, 앱 프레임워크까지 초기 스캐폴드 전체를 생성했습니다. 심지어 AGENTS.md 파일 자체도 Codex가 작성했습니다.

핵심 수치를 정리하면 다음과 같습니다:

항목수치
수동 작성 코드0줄
프로젝트 기간5개월 (2025.08~)
코드 규모약 100만 줄
머지된 PR약 1,500개
팀 규모3명 → 7명
엔지니어당 일일 PR3.5개 (증가 추세)
속도 향상수동 대비 약 10배

주목할 점은 팀이 3명에서 7명으로 확대된 이후에도 엔지니어당 PR 처리량이 오히려 증가했다는 것입니다. 일반적으로 팀 확대는 커뮤니케이션 오버헤드를 늘리지만, 에이전트가 실행을 담당하는 구조에서는 사람이 늘어날수록 더 많은 방향을 동시에 조율할 수 있기 때문입니다.

엔지니어 역할의 근본적 변화

이 프로젝트에서 가장 중요한 발견은 "엔지니어가 무엇을 하는가"에 대한 답이 바뀌었다는 점입니다.

코드 작성자에서 환경 설계자로

초기에 진행이 예상보다 느렸던 이유가 흥미롭습니다. Codex의 능력이 부족해서가 아니라 환경이 충분히 명세되어 있지 않았기 때문이었습니다. 엔지니어의 주된 업무는 에이전트가 유용한 작업을 할 수 있도록 환경을 구축하는 것으로 변화했습니다.

실패를 다루는 방식도 달라졌습니다. 에이전트가 실패하면 "더 열심히 시도해"라고 재촉하는 것이 아니라 "어떤 역량이 누락되어 있고, 에이전트가 읽고 강제할 수 있는 형태로 만들려면 어떻게 해야 하는가?"를 질문합니다.

Ralph Wiggum Loop: 에이전트 간 PR 리뷰

PR 완성 과정은 다음과 같은 루프로 동작합니다:

  1. Codex가 코드를 작성하고 자체 로컬 리뷰를 수행합니다
  2. 추가 에이전트에게 로컬 및 클라우드 리뷰를 요청합니다
  3. 피드백을 반영하고 수정합니다
  4. 모든 에이전트 리뷰어가 만족할 때까지 반복합니다

팀은 이 과정을 "Ralph Wiggum Loop"라고 부릅니다. 심슨 가족의 캐릭터처럼 계속 실패하면서도 끈질기게 시도하는 모습에서 이름을 따왔습니다. 사람의 PR 리뷰는 선택 사항이 되었고, 시간이 지나면서 거의 모든 리뷰가 에이전트 간 처리로 전환되었습니다.

코드 가독성이 아닌 애플리케이션 가독성

코드 처리량이 급증하면서 병목이 이동했습니다. 코드 생산 속도가 아니라 인간의 QA 역량이 병목이 된 것입니다. 이 문제를 해결하기 위해 두 가지 통합이 이루어졌습니다.

Chrome DevTools Protocol 통합

앱을 git worktree별로 독립적으로 부팅할 수 있게 만들었습니다. 이를 통해 모든 변경사항마다 별도의 인스턴스를 실행할 수 있게 되었고, Codex가 DOM 스냅샷, 스크린샷, 내비게이션용 스킬을 활용하여 직접 버그를 재현하고 수정을 검증할 수 있게 되었습니다.

옵저버빌리티 스택 통합

로그, 메트릭, 트레이스를 worktree별 임시 로컬 스택으로 노출했습니다. LogQL과 PromQL로 에이전트가 직접 쿼리를 수행하며, "서비스 시작을 800ms 이내로 보장하라"와 같은 성능 요구사항을 프롬프트로 전달하면 에이전트가 자체적으로 해결합니다. 단일 Codex 실행이 6시간 이상 작업을 수행하는 경우도 있으며, 종종 엔지니어가 자는 동안 작업이 완료됩니다.

AGENTS.md의 올바른 사용법: 백과사전이 아닌 목차

이 프로젝트에서 얻은 가장 실용적인 교훈은 에이전트 지시 문서 관리입니다. 처음에 "거대한 AGENTS.md 하나"를 만들었지만 실패했습니다. 그 이유는 네 가지입니다:

  1. 컨텍스트는 희소 자원입니다. 거대한 지시 파일이 실제 작업, 코드, 관련 문서를 컨텍스트 윈도우 밖으로 밀어냅니다.
  2. 과도한 가이드는 비가이드가 됩니다. 모든 것이 "중요"하면 아무것도 중요하지 않습니다.
  3. 단일 매뉴얼은 즉시 부패합니다. 낡은 규칙들의 묘지가 됩니다.
  4. 기계적으로 검증할 수 없습니다. 커버리지, 신선도, 소유권을 자동으로 확인할 수 없습니다.

해결책은 AGENTS.md를 약 100줄의 목차로 만드는 것이었습니다. 짧은 진입점이 구조화된 docs/ 디렉토리의 더 깊은 문서로 안내하는 방식입니다. 이를 Progressive Disclosure라고 합니다. 에이전트가 작고 안정적인 진입점에서 시작해 필요할 때만 더 깊은 정보를 탐색합니다.

추가로 전용 린터와 CI 작업이 지식 베이스의 최신성과 구조 정확성을 검증하며, "doc-gardening" 에이전트가 주기적으로 낡은 문서를 스캔하여 수정 PR을 자동으로 생성합니다.

에이전트 가독성 최적화: 보이지 않으면 존재하지 않는다

저장소 전체가 에이전트가 생성한 코드이므로, 사람의 가독성보다 에이전트의 가독성에 최적화합니다.

핵심 원칙은 명확합니다: "에이전트가 컨텍스트에서 접근할 수 없는 것은 존재하지 않는다." Google Docs의 메모, 슬랙에서의 아키텍처 합의, 사람 머릿속의 암묵적 지식은 에이전트에게 보이지 않습니다. 저장소에 인코딩하지 않으면 없는 것과 같습니다.

기술 선택 원칙

"지루한(boring) 기술"을 선호합니다. 조합성이 높고, API가 안정적이며, 훈련 데이터가 풍부한 기술을 선택합니다. 외부 라이브러리의 동작이 불투명한 경우 자체 재구현이 더 저렴할 수 있습니다. 실제로 p-limit 라이브러리 대신 자체 동시성 헬퍼를 구현했는데, OpenTelemetry 통합과 100% 테스트 커버리지를 확보할 수 있었습니다.

아키텍처 불변조건 강제

문서만으로는 코드베이스의 일관성을 유지할 수 없습니다. 불변조건(invariant)을 강제하되 구현을 미시관리하지 않는 접근법을 사용합니다. 예를 들어, "경계에서 데이터 형태를 파싱하라"는 원칙을 세우되 구체적인 라이브러리는 지정하지 않습니다. Codex는 자연스럽게 Zod를 선택했습니다.

엄격한 계층형 도메인 아키텍처(Types - Config - Repo - Service - Runtime - UI)를 적용하고, 커스텀 린터와 구조 테스트로 기계적으로 강제합니다. 보통 엔지니어 수백 명 규모에서 도입하는 아키텍처 거버넌스를 초기부터 전제조건으로 설정한 것입니다.

실무에 적용할 수 있는 핵심 교훈

이 실험에서 당장 적용 가능한 인사이트를 정리합니다:

  • 환경을 명세하라. 에이전트가 실패하면 에이전트를 탓하지 말고 환경의 빈틈을 찾으세요.
  • AGENTS.md는 짧게 유지하라. 100줄 이내의 목차 역할로 한정하고, 상세 내용은 구조화된 문서 디렉토리에 분산하세요.
  • 불변조건을 강제하라. 원칙은 세우되 방법은 열어두고, 린터와 CI로 기계적 검증을 하세요.
  • 에이전트 가독성을 우선하라. 슬랙 메모, 구두 합의 대신 저장소에 인코딩하세요.
  • 지루한 기술을 선택하라. 새로운 프레임워크보다 학습 데이터가 풍부한 안정적 기술이 에이전트에게 유리합니다.

결론: 에이전트 퍼스트 시대의 시작

OpenAI Harness Engineering 실험은 AI 코딩 에이전트의 가능성을 보여주는 동시에, 개발자 역할의 근본적 변화를 예고합니다. 코드를 작성하는 사람에서 에이전트가 일할 수 있는 환경을 설계하는 사람으로의 전환입니다.

수동 코드 0줄, 속도 10배, 품질 유지. 이 숫자들이 과장이 아닌 실제 운영 제품의 결과라는 점이 이 실험의 무게감입니다. 에이전트 퍼스트 개발은 더 이상 미래의 이야기가 아니라 지금 벌어지고 있는 현실입니다.

FAQ

Q: Harness Engineering에서 사람이 정말 코드를 한 줄도 안 썼나요?

네, OpenAI의 공식 발표에 따르면 앱 로직, 테스트, CI 설정, 문서, 옵저버빌리티, 내부 툴링까지 모든 코드를 Codex가 작성했습니다. 사람은 방향 설정과 환경 구축에 집중했습니다.

Q: AGENTS.md를 짧게 유지하라는 건 구체적으로 어떤 의미인가요?

약 100줄 이내로 유지하며, 세부 규칙과 가이드는 docs/ 디렉토리에 분산시키는 것입니다. AGENTS.md는 "백과사전"이 아니라 "목차" 역할을 합니다. 에이전트가 필요한 정보를 Progressive Disclosure 방식으로 탐색할 수 있게 됩니다.

Q: 이 방식을 소규모 팀에서도 적용할 수 있나요?

핵심 원칙인 "환경 명세 → 에이전트 실행 → 기계적 검증"은 팀 규모와 무관하게 적용할 수 있습니다. 실제로 이 프로젝트도 3명으로 시작했습니다. 다만 Codex 수준의 에이전트 도구가 필요하며, 명확한 테스트 기준과 아키텍처 규칙이 전제되어야 합니다.

Q: 에이전트 간 코드 리뷰(Ralph Wiggum Loop)는 사람 리뷰보다 품질이 높은가요?

OpenAI 팀에 따르면 시간이 지나면서 에이전트 리뷰의 품질이 충분히 높아져 사람의 리뷰가 선택 사항이 되었습니다. 다만 아키텍처적 의사결정이나 제품 방향성 판단은 여전히 사람의 영역입니다.


참고 자료: