외부 사례 비교
OpenAI, Anthropic, Toss, gstack, revfactory/harness를 입력·상태·검증·배포 기준으로 비교합니다.
하네스 엔지니어링을 이해할 때 중요한 것은 "누가 맞는가"보다 "각 사례가 어떤 문제를 해결하려고 했는가"를 보는 것입니다.
이 장은 비교 허브입니다. 각 사례를 한 화면에서 비교한 뒤, 상세한 기술 메커니즘은 사례별 페이지로 내려가서 봅니다.
사례: OpenAI
repo-readable 시스템, observability, cleanup 중심
사례: Anthropic
planner/evaluator, retry budget, handoff 중심
사례: Toss
executable SSOT, domain layer, frictionless 배포 중심
사례: gstack
sprint, command surface, release gate 중심
사례: revfactory/harness
domain-first 설계, agent/skill generation, validation 중심
한눈에 비교
| 사례 | 핵심 입력 | 상태 외재화 | 검증 인터페이스 | 승인/배포 | 가장 강한 메시지 |
|---|---|---|---|---|---|
| OpenAI | AGENTS.md, docs/, repo 구조 | 문서·코드·관측 데이터 | 브라우저/로그/메트릭 | cleanup 포함 운영 | repo 자체가 harness |
| Anthropic | task/sprint contract | planner/builder/evaluator handoff | evaluator + QA | retry budget + handoff | load-bearing scaffolding만 남겨라 |
| Toss | global/domain/local 규칙 | workflow와 SSOT | 실행 가능한 문서/절차 | domain HITL | 실행 가능한 SSOT로 내려라 |
| gstack | sprint phase, command | 단계별 산출물 | review/test/ship | opinionated release gate | software factory처럼 굴려라 |
| revfactory/harness | domain analysis | agent/skill files | validation & testing | generated harness refinement | harness를 만드는 harness |
어떤 기술 문제를 풀고 있는가
| 사례 | 실제로 푸는 문제 | 기술적으로 읽으면 |
|---|---|---|
| OpenAI | 탐색 비용과 문서 엔트로피 | knowledge architecture |
| Anthropic | 장시간 작업의 자기평가 편향 | control-loop engineering |
| Toss | 팀 전체로의 배포와 재현성 | workflow distribution |
| gstack | 병렬 작업을 chaos 없이 굴리기 | production pipeline design |
| revfactory/harness | 하네스 설계 자체의 반복성 | meta-architecture generation |
자료별 상세 해석
사례를 읽는 추천 순서
| 지금 필요한 감각 | 먼저 볼 사례 |
|---|---|
| 리포와 문서 구조를 손보고 싶음 | OpenAI |
| 평가 루프와 retry budget이 궁금함 | Anthropic |
| 팀 배포와 문서-실행 연결이 궁금함 | Toss |
| 병렬 작업과 release gate를 보고 싶음 | gstack |
| 하네스 자체를 생성 가능한 자산으로 만들고 싶음 | revfactory/harness |
무엇을 먼저 훔칠 것인가
| 지금 당장 필요한 것 | 먼저 볼 사례 |
|---|---|
| 리포와 문서 구조 | OpenAI |
| planner / evaluator 판단 | Anthropic |
| 팀 배포와 workflow | Toss |
| opinionated sprint | gstack |
| 하네스 생성 템플릿 | revfactory/harness |
사례들은 표현은 다르지만 같은 결론으로 수렴합니다.
- 더 좋은 단일 프롬프트보다 더 좋은 작업 환경이 중요하다.
- 긴 작업일수록 상태 외재화와 평가 루프가 중요하다.
- 팀에 배포되려면 workflow, command, approval이 실행 가능한 형태여야 한다.
- 범용 템플릿은 시작점일 뿐, 도메인 특화가 성능을 만든다.
- 하네스는 만들고 끝나는 것이 아니라 운영하며 정리해야 한다.
참고 링크
- OpenAI, "Harness Engineering", 2026-02-11 https://openai.com/ko-KR/index/harness-engineering/
- Anthropic, "Harness design for long-running application development", 2026-03-24 https://www.anthropic.com/engineering/harness-design-long-running-apps
- Toss, "Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기", 2026-02-26 https://toss.tech/article/harness-for-team-productivity
- gstack README https://github.com/garrytan/gstack
- revfactory/harness README https://github.com/revfactory/harness