06. 하네스 엔지니어링 실전 — OpenAI와 Anthropic은 어떻게 에이전트를 통제했나

🏗️ “에이전트가 어려움을 겪으면 더 열심히 하라고 말하지 말라. 무엇이 누락되었는지 파악하고 도구를 보충하라.”

2026년 초, AI 업계 리더 두 곳이 같은 문제를 다른 방식으로 풀었다. 에이전트를 어떻게 통제할 것인가. OpenAI는 대규모 제품 개발에서, Anthropic은 장시간 실행 에이전트에서 각자의 하네스를 실험하고 공유했다.

개념은 이전 글에서 다뤘다. 이 글에서는 두 회사가 실제로 무엇을 했는지, 그리고 무엇을 배웠는지를 비교한다.

flowchart TB
    subgraph "OpenAI: Codex 실험"
        A1["엔지니어 3명"] --> A2["~100줄 AGENTS.md<br/>(목차)"]
        A2 --> A3["docs/ 분산 문서"]
        A3 --> A4["커스텀 린터"]
        A4 --> A5["백만 줄 코드<br/>1,500 PR"]
    end

    subgraph "Anthropic: 장시간 에이전트"
        B1["초기화 에이전트"] --> B2["JSON 기능 목록<br/>200+ 항목"]
        B2 --> B3["코딩 에이전트<br/>1기능/세션"]
        B3 --> B4["progress.txt<br/>git log"]
        B4 --> B5["완전한 웹앱<br/>클론"]
    end

OpenAI: 코드 한 줄도 직접 안 쓴 5개월

실험 개요

2025년 8월, OpenAI의 한 팀이 빈 리포지터리에 첫 커밋을 올렸다. 이후 5개월간 사람이 수동으로 작성한 코드는 0줄. 모든 코드 — 애플리케이션 로직, 테스트, CI 구성, 문서화, 관측 가능성, 내부 툴링 — 이 Codex에 의해 작성됐다.

팀: 엔지니어 3명 → 후에 7명
산출물: 약 백만 줄 코드
PR: 약 1,500개 (인당 하루 3.5개)
사용자: 내부 일일 사용자 + 외부 알파 테스터

핵심 교훈 5가지

① 목차를 주고, 백과사전은 주지 마라

초기에 하나의 거대한 AGENTS.md에 모든 지침을 몰아넣었다. 결과는 처참했다. 에이전트가 핵심 제약조건을 놓치고, 잘못된 제약조건에 최적화했다. “모든 게 중요하면 중요한 건 아무것도 없다.”

해결책: AGENTS.md를 약 100줄의 목차로 줄이고, 상세 문서는 docs/ 디렉토리에 분산 배치했다. 에이전트는 작은 진입점에서 시작해 필요할 때만 깊이 들어간다.

② 린터 에러 메시지에 수정 지침을 넣어라

에이전트가 아키텍처 규칙을 어기면, 일반적인 린트 에러가 아니라 에이전트가 바로 수정할 수 있는 지침이 포함된 에러 메시지가 나온다. 사람이 리뷰 코멘트를 다는 대신, 린터가 대신하는 것이다.

아키텍처도 엄격하게 고정했다:

Types → Config → Repo → Service → Runtime → UI

각 레이어는 한 방향으로만 의존하고, 교차 관심사(인증, 커넥터 등)는 Providers라는 명시적 인터페이스로만 유입된다.

③ 에이전트가 직접 볼 수 있게 만들어라

에이전트가 접근할 수 없는 것은 사실상 존재하지 않는다. Google Docs, Slack 스레드, 사람 머릿속의 지식은 에이전트에게 접근 불가능하다. 그래서 로그·메트릭·UI를 에이전트가 직접 읽을 수 있게 만들었다.

git worktree별 독립 앱 인스턴스
Chrome DevTools Protocol → DOM 스냅샷, 스크린샷
LogQL/PromQL로 로그·메트릭 쿼리
“서비스 시작 800ms 이내” 같은 구체적 목표를 프롬프트로 지시

④ “지루한” 기술이 에이전트에게 더 쉽다

놀랍게도, 공개 라이브러리의 불투명한 동작에 맞추는 것보다 에이전트가 직접 기능을 재구현하는 게 더 저렴한 경우가 있었다. 예를 들어 범용 p-limit 패키지 대신 자체 map-with-concurrency 헬퍼를 만들었다. OpenTelemetry 계층과 긴밀하게 통합되고, 테스트 커버리지가 100%이고, 런타임이 기대하는 방식대로 정확히 동작한다.

⑤ 사람은 금요일마다 “AI 쓰레기”를 치웠다 — 자동화하기 전까지

에이전트는 이미 존재하는 패턴을 복제한다. 좋은 패턴이든 나쁜 패턴이든. 초기에는 매주 금요일 하루 종일 AI가 만든 코드를 정리했다. 확장 불가능한 방식이었다.

대신 “문서 가드닝” 에이전트를 만들어 정기적으로 오래된 문서를 발견하고 수정 PR을 자동 생성하게 했다. “황금 원칙”을 리포지터리에 직접 인코딩해서 에이전트가 스스로 일관성을 유지하게 만들었다.

랄프 위검 루프

OpenAI의 가장 독특한 발견. Codex가 코드를 작성하면:

자체적으로 변경사항을 검토
에이전트 검토를 추가로 요청
피드백에 응답하고 수정
모든 에이전트 검토자가 만족할 때까지 반복

사람은 꼭 필요한 경우에만 개입한다. 시간이 지나면서 거의 모든 검토 작업이 에이전트 간에 처리됐다.

Anthropic: 장시간 에이전트가 길을 잃지 않게

문제: 컨텍스트가 바닥나면 에이전트가 망가진다

Claude Opus 4.5에게 “claude.ai 클론을 만들어라”라고만 지시하면 어떻게 될까? Anthropic이 실험해봤다.

에이전트는 두 가지 패턴으로 실패했다:

One-shotting: 한 번에 모든 걸 구현하려다 컨텍스트가 바닥. 다음 세션은 앞뒤가 안 맞는 코드를 물려받아 삽질 반복
조기 완료 선언: 어느 정도 진행되면 “다 됐다”고 선언. 실제로는 많은 기능이 미구현

이건 compaction(컨텍스트 압축)만으로는 해결 안 되는 근본적인 문제였다.

해결: 2-파트 에이전트 구조

초기화 에이전트 (첫 세션만 실행):

init.sh 개발 서버 스크립트 생성
claude-progress.txt 진행 로그 파일 생성
기능 목록을 JSON으로 200+ 항목 작성
초기 git commit

{
  "category": "functional",
  "description": "New chat button creates a fresh conversation",
  "steps": ["Navigate to main interface", "Click 'New Chat'", "Verify conversation created"],
  "passes": false
}

코딩 에이전트 (이후 매 세션):

pwd로 작업 디렉토리 확인
git log + progress 파일 읽어 최근 작업 파악
기능 목록에서 우선순위 가장 높은 미완료 기능 1개 선택
구현 → git commit (서술적 메시지) → progress 업데이트

왜 JSON인가

Markdown으로 기능 목록을 작성하니 에이전트가 기능을 삭제하거나 수정해버렸다. JSON으로 바꾸니 이 문제가 사라졌다. “기능을 삭제하거나 테스트를 수정하는 것은 용납할 수 없다”는 강력한 지시어와 함께.

브라우저로 직접 확인

코드만으로는 보이지 않는 버그가 있다. Anthropic은 Puppeteer MCP Server로 에이전트가 직접 브라우저를 열어 화면을 확인하게 했다. 에이전트가 스크린샷을 찍고, 버튼이 제대로 보이는지, 대화가 정상적으로 생성되는지 확인한다.

한계도 있었다. 브라우저 네이티브 alert 모달은 Puppeteer로 감지하기 어려워서, 이런 기능이 의존하는 부분이 더 버그가 많았다.

두 접근 비교

항목	OpenAI (Codex)	Anthropic (Claude SDK)
규모	백만 줄, 5개월	단일 웹앱 클론
사람 역할	환경 설계, 의도 명시	초기화, 목표 설정
문서 전략	목차(~100줄) + 분산 docs	JSON 기능 목록 + progress.txt
강제 방식	커스텀 린터, 구조적 테스트	JSON 스키마, 강력한 지시어
관측	DevTools, LogQL, PromQL	Puppeteer MCP, 스크린샷
리뷰	에이전트 간 (랄프 위검 루프)	에이전트 자체 테스트
핵심 통찰	”에이전트가 접근 못하면 없는 거다"	"한 번에 한 기능씩만”

공통 분모

두 접근이 다르게 보이지만, 뿌리는 같다.

컨텍스트는 희소 리소스다. 아껴 쓰고, 핵심만 남기고, 점진적으로 공개한다
“더 열심히 해”는 소용없다. 에이전트가 실수할 수 없는 구조를 만들어야 한다
에이전트가 직접 확인하게 만들어야 한다. 코드만 보지 말고, 화면도 보고, 로그도 읽고
사람은 판단에만 개입한다. 구현·검증·리뷰의 반복은 에이전트에게 맡긴다

우리가 배울 것

OpenAI와 Anthropic의 실험은 같은 결론에 도달한다. 에이전트의 성능 병목은 모델이 아니라 하네스 세팅이다. 좋은 하네스가 있으면 일반 모델도 훌륭한 결과를 내고, 나쁜 하네스면 최고 모델도 삽질한다.

이 원칙은 대규모 제품 개발뿐 아니라, 일상적인 코딩 에이전트 사용에도 적용된다. AGENTS.md를 목차로 쓰고, 한 번에 한 기능씩만 작업하고, 에이전트가 스스로 결과를 확인하게 만들면, 어떤 에이전트든 더 나은 결과를 낸다.

하네스의 실전 도구가 궁금하다면 → 다음 글: 스킬·서브에이전트·포크 활용법

참고

일하는 ai

탐색기