OpenAI, Anthropic, Stripe는 어떻게 하네스를 구축했는가
하네스 엔지니어링의 이론, 기술, 구축 방법, 실패 패턴까지 다뤘다. 이 편에서는 실제로 대규모 에이전트 운영을 하고 있는 세 조직의 사례를 비교한다. 같은 문제에 부딪혔지만, 각자의 맥락에서 다른 해법을 선택했다. 그 차이와 공통점에서 실전적인 교훈을 뽑아낸다.
OpenAI: “인간 코드 0줄”이라는 극단적 제약
맥락
2025년 8월, OpenAI 내부 팀이 새 제품을 만들기 시작했다. 스스로에게 건 제약은 극단적이었다. 인간이 코드를 직접 작성하지 않는다. 애플리케이션 로직, 테스트, CI 설정, 문서, 모니터링까지 전부 Codex 에이전트가 작성하도록 했다. 초기 스캐폴드(저장소 구조, 포매팅 규칙, AGENTS.md)까지도 에이전트가 생성했다.
하네스 구조
OpenAI 하네스의 핵심 구성:
1. 컨텍스트
- AGENTS.md: 계층적 구조, 작업 범위별 선별 제공
- ARCHITECTURE.md: matklad 스타일의 프로젝트 지도
- docs/ 디렉토리: 설계 명세, 실행 계획, 크로스링크된 문서
2. 아키텍처 제약
- Types → Config → Repository → Service → Runtime → UI 의존성 계층
- Codex가 생성한 커스텀 린터로 경계 강제
- 구조적 테스트로 레이어 위반 자동 차단
- 데이터 경계에서의 파싱 필수화
3. 관찰 가능성
- Chrome DevTools Protocol 연결 (DOM, 스크린샷, 내비게이션)
- git worktree별 임시 관찰 스택 (Victoria Logs + Victoria Metrics)
- 에이전트가 LogQL/PromQL로 직접 쿼리
4. 엔트로피 관리
- 문서와 코드의 기계적 일관성 검증 (린터 + CI)
- 크로스링크 문서의 유효성 자동 검사
핵심 수치
기간: 5개월
팀 규모: 3명 → 7명
총 PR: 약 1,500개
엔지니어당 일 PR: 평균 3.5개
코드 규모: 약 100만 줄
수작업 코드: 0줄
추산 시간 절감: 수작업 대비 약 1/10
고유한 교훈
“지루한 기술이 에이전트에게 유리하다.” 팀은 외부 라이브러리 대신 커스텀 동시성 헬퍼를 직접 구축했다. 이유는 두 가지다. 외부 라이브러리는 버전이 바뀌면 API가 달라져서 에이전트가 잘못된 코드를 생성할 수 있다. 그리고 널리 사용되는 표준 기능은 모델의 훈련 데이터에 풍부하게 포함되어 있어 에이전트의 정확도가 높다. 최신 프레임워크보다 오래되고 안정적인 기술이 에이전트에게 유리하다.
“팀이 커져도 1인당 처리량이 감소하지 않았다.” 전통적 개발에서는 팀 규모가 커지면 커뮤니케이션 오버헤드로 1인당 생산성이 떨어진다. 이 실험에서는 하네스가 에이전트 간 조정을 대신하면서 규모의 경제가 가능했다.
Anthropic: 장기 실행 에이전트의 “기억” 문제
맥락
Anthropic의 문제 정의는 OpenAI와 달랐다. “에이전트만으로 제품을 만들 수 있는가”가 아니라, **”에이전트가 여러 세션에 걸쳐 일관된 진행을 만들 수 있는가”**였다. Claude Agent SDK를 사용해 장기간 복잡한 작업을 수행하는 상황에서, 세션이 끝나면 기억이 사라지는 문제를 해결하려 했다.
하네스 구조
Anthropic 하네스의 핵심 구성:
1. 2단계 에이전트 구조
- 초기화 에이전트: 최초 1회 실행, 환경 설정
└ init.sh 생성
└ feature-list.json 생성 (200+ 기능, 모두 passes: false)
└ progress.md 초기화
└ 첫 git 커밋
- 코딩 에이전트: 이후 매 세션
└ progress.md 읽기 → 이전 상태 파악
└ git log 확인 → 최근 변경 확인
└ feature-list.json에서 다음 작업 선택
└ 한 번에 하나의 기능만 구현
└ 브라우저 테스트로 검증
└ 상태 업데이트 후 커밋
2. 기능 추적
- JSON 형식 (Markdown보다 에이전트의 부적절한 수정이 적음)
- passes 필드만 변경 가능
- 기능 삭제/편집 명시적 금지
3. 세션 간 기억 전달
- progress.md: 완료 항목, 발견된 이슈, 아키텍처 결정 기록
- git history: 변경 이력 추적
- init.sh: 매 세션 시작 시 환경 복원
4. 테스트
- Puppeteer MCP로 브라우저 자동화
- 인간 사용자처럼 엔드투엔드 검증
- 기능 완료 전 반드시 E2E 테스트 통과 필수
핵심 실패 모드와 해결
실패 모드 1: 한꺼번에 너무 많은 것을 시도
원인: 에이전트가 전체 앱을 한 번에 구현하려 함
결과: 컨텍스트 소진, 반쯤 구현된 상태로 세션 종료
해결: "한 번에 하나의 기능만" 규칙 강제
실패 모드 2: 조기 완료 선언
원인: 일부 기능이 작동하는 것을 보고 "다 됐다"고 판단
결과: 누락된 기능 다수
해결: feature-list.json으로 완료 기준 명시화
실패 모드 3: 테스트 없이 완료 표시
원인: 코드 수준에서만 확인, 실행 수준 검증 부재
결과: 코드는 맞지만 실제로 동작하지 않음
해결: Puppeteer MCP로 브라우저 테스트 강제
실패 모드 4: 불완전한 상태로 세션 종료
원인: 세션이 끝날 때 정리하지 않음
결과: 다음 에이전트가 깨진 상태에서 시작
해결: 매 세션 종료 시 git 커밋 + progress.md 업데이트 강제
고유한 교훈
“Compaction만으로는 부족하다.” Claude Agent SDK는 컨텍스트 윈도우가 꽉 차면 자동으로 압축(compaction)하는 기능이 있다. 이론적으로는 이것만으로 무한히 작업할 수 있어야 한다. 하지만 실제로는 압축 과정에서 중요한 맥락이 손실되어, 다음 세션에서 에이전트가 이전 작업을 제대로 이어가지 못했다. 파일시스템 기반의 명시적 상태 기록이 필요한 이유다.
“JSON이 Markdown보다 낫다.” 기능 목록을 Markdown으로 관리했을 때, 에이전트가 항목을 자의적으로 수정하거나 삭제하는 문제가 있었다. JSON의 구조화된 형식이 이런 부적절한 변경을 줄이는 데 효과적이었다.
Stripe: 대규모 에이전트를 기존 품질 기준으로 운영하기
맥락
Stripe의 과제는 또 달랐다. 이미 수천 명의 엔지니어가 일하는 대규모 코드베이스에서, 에이전트를 기존 개발 프로세스에 통합하는 것이었다. 새로운 제품을 에이전트만으로 만드는 실험이 아니라, 기존 프로덕션 시스템에 에이전트가 기여하는 형태다.
하네스 구조
Stripe "Minions" 하네스의 핵심 구성:
1. 워크플로우
Slack에서 작업 요청
→ 에이전트가 코드 작성
→ CI 파이프라인 통과 확인
→ PR 자동 생성
→ 인간 엔지니어 최종 리뷰
→ 머지
2. 도구 통합
- 400+ 내부 도구에 연결 (Toolshed: 중앙 집중식 MCP 통합)
- 에이전트가 인간 엔지니어와 동일한 개발 환경에서 작업
- 같은 도구, 같은 컨텍스트, 같은 접근 권한
3. 품질 게이트
- 에이전트 생성 코드도 인간 코드와 동일한 품질 기준 적용
- 기존 CI/CD 파이프라인을 그대로 사용
- 추가적인 에이전트 전용 검증 레이어 없음
4. 규모
- 주당 1,000개 이상의 PR이 이 파이프라인을 통해 머지
고유한 교훈
“도구에 접근할 수 있게 하는 것은 시작일 뿐이다.” Stripe는 400개 이상의 내부 도구를 에이전트에 연결했다. 하지만 도구에 접근할 수 있다는 것과 도구를 올바르게 사용한다는 것은 다른 문제다. 올바른 도구가 에이전트의 능력을 확장할 뿐 아니라, 기존의 모든 작업의 신뢰성도 높인다. 린터와 테스트 스위트를 실행할 수 있는 에이전트는, 수동 리뷰에 의존하는 에이전트보다 모든 작업에서 더 신뢰할 수 있다.
“별도의 품질 기준을 만들지 않는다.” 많은 팀이 “에이전트가 만든 코드”와 “인간이 만든 코드”에 다른 리뷰 기준을 적용하려 한다. Stripe는 이를 거부했다. 에이전트의 PR이든 인간의 PR이든 동일한 CI 파이프라인, 동일한 리뷰 프로세스, 동일한 머지 기준을 적용한다. 이 원칙이 에이전트 생성 코드의 품질을 자연스럽게 보장한다.
세 접근법 비교
OpenAI Anthropic Stripe
─────────────────────────────────────────────────────────────────────
핵심 질문 인간 코드 없이 세션 간 기억을 기존 시스템에
프로덕션 가능한가? 유지할 수 있는가? 에이전트를 통합할 수 있는가?
규모 100만 줄 / 신규 단일 프로젝트 / 대규모 기존 코드베이스 /
제품 구축 장기 실행 실험 프로덕션 운영
팀 구성 3~7명 엔지니어 + 연구팀 + 수천 명 엔지니어 +
Codex 에이전트 Claude Agent SDK Minions 에이전트
컨텍스트 관리 AGENTS.md 계층화 + feature-list.json + 400+ 내부 도구 연결
ARCHITECTURE.md progress.md (Toolshed MCP)
아키텍처 강제 커스텀 린터 + 초기화 에이전트가 기존 CI/CD 파이프라인
구조적 테스트 환경 설정 그대로 활용
피드백 루프 Chrome DevTools + Puppeteer MCP + 기존 품질 게이트 +
관찰 스택 브라우저 E2E 테스트 인간 최종 리뷰
엔트로피 관리 문서-코드 일관성 JSON 기반 상태 추적 기존 코드 품질 도구
기계적 검증 + git 히스토리 활용
─────────────────────────────────────────────────────────────────────
공통점: 모두가 동의하는 것
세 조직의 접근 방식은 다르지만, 공통적으로 수렴하는 원칙이 있다.
첫째, 실패를 환경의 문제로 본다. 에이전트가 잘못된 결과를 만들면, “모델이 부족하다”가 아니라 “환경에서 무엇이 빠져있는가”를 묻는다. OpenAI는 이를 명시적으로 규칙화했고, Anthropic은 실패 모드별 해결 구조를 만들었고, Stripe는 기존 품질 게이트를 그대로 적용함으로써 환경이 품질을 보장하게 했다.
둘째, 점진적으로 작업한다. OpenAI의 depth-first 접근, Anthropic의 “한 번에 하나의 기능만” 규칙, Stripe의 PR 단위 작업. 모두 에이전트가 한꺼번에 큰 작업을 하는 대신 작은 단위로 나눠서 검증하며 진행하는 구조를 택했다.
셋째, 기계적으로 강제한다. 문서에 규칙을 적어두는 것과 린터/테스트/CI로 강제하는 것은 차원이 다르다. 세 조직 모두 핵심 규칙은 기계적으로 집행하는 방식을 선택했다.
넷째, 에이전트에게 피드백 채널을 제공한다. 코드만 보고 “됐다”고 판단하게 하지 않는다. 브라우저 테스트, 로그 쿼리, 메트릭 확인 등 에이전트가 자신의 작업 결과를 직접 확인할 수 있는 채널을 만들어준다.
차이점: 맥락이 결정하는 것
차이는 “어느 것이 더 나은가”의 문제가 아니라, 각 조직의 맥락에 맞는 선택이다.
새 프로젝트를 시작하는 팀이라면 OpenAI의 접근이 참고 가치가 높다. 처음부터 에이전트 중심으로 설계할 수 있고, 아키텍처 제약을 깨끗하게 잡을 수 있다.
기존 프로젝트에 에이전트를 도입하는 팀이라면 Stripe의 접근이 현실적이다. 기존 CI/CD와 품질 기준을 유지하면서 에이전트를 통합하는 방식이 마찰이 적다.
장기간 복잡한 작업을 에이전트에게 맡기는 경우라면 Anthropic의 초기화-코딩 2단계 구조와 파일시스템 기반 상태 관리가 핵심 참고 자료다.
물론 이 셋은 배타적이지 않다. OpenAI의 계층적 AGENTS.md + Anthropic의 feature-list.json + Stripe의 기존 CI 활용을 조합하는 것이 실제로 가장 효과적인 하네스가 될 수 있다.
어떤 사례를 따를 것인가
조직의 상황에 따른 실용적 가이드:
"우리 팀은..."
처음부터 에이전트 중심으로 새 프로젝트를 시작한다
→ OpenAI 모델: 엄격한 아키텍처 제약 + 관찰 가능성 스택
→ 핵심 도입: AGENTS.md 계층화, 의존성 방향 테스트, 커스텀 린터
기존 코드베이스에 에이전트를 도입한다
→ Stripe 모델: 기존 CI/CD 활용 + 동일한 품질 기준
→ 핵심 도입: 기존 린터/테스트를 에이전트 파이프라인에 연결
에이전트에게 며칠~몇 주 걸리는 복잡한 작업을 맡긴다
→ Anthropic 모델: 2단계 에이전트 + 파일시스템 기반 상태 관리
→ 핵심 도입: feature-list.json, progress.md, 세션 시작 루틴
위의 모든 상황이 해당된다
→ 세 모델을 조합: 계층적 컨텍스트(OpenAI) + 상태 추적(Anthropic) + 기존 CI 활용(Stripe)
어떤 사례를 따르든, 핵심 원칙은 같다. 에이전트를 바꾸는 것이 아니라 환경을 바꾼다. 그리고 그 환경은 한 번에 완성하는 것이 아니라, 실패를 연료로 삼아 점진적으로 진화시킨다.