도메인별 적용 지도
프론트엔드 팀, 플랫폼 팀, 결제·정산 팀, AI 제품 팀이 하네스를 어떻게 다르게 설계해야 하는지 안내합니다.
핵심 요약
- 이 장은 OpenAI·Anthropic·Toss·gstack·revfactory의 원리를 프론트엔드·플랫폼·결제정산·AI 제품 네 팀 유형별 하네스 설계로 옮깁니다.
- 팀마다 가장 큰 위험과 load-bearing 요소가 다릅니다. 프론트엔드는 browser QA·a11y gate, 플랫폼은 invariants·release gate, 결제는 approval·audit trail, AI 제품은 eval set·canary loop가 핵심입니다.
- "완료"의 정의도 도메인별로 갈립니다. 화면 상호작용, 공유 규칙 불변성, 정합성 통과, offline+online eval 통과로 서로 다릅니다.
- Anthropic의 financial agent template처럼, 도메인 플레이북은 프롬프트 묶음이 아니라 skills·connectors·credential vault·audit log·approval flow를 포함한 실행 경계 패키지로 읽어야 합니다.
- AGENTS.md, 기본 검증 명령, approval vocabulary는 공통으로 두고, 완료 정의·evaluator 구성·human gate·관측 지표·MCP credential 경계는 도메인별로 갈라야 합니다.
외부 사례를 공부한 뒤 바로 부딪히는 질문은 이것입니다.
그래서 우리 팀은 무엇을 어떻게 다르게 설계해야 하는가?
이 장은 OpenAI, Anthropic, Toss, gstack, revfactory/harness에서 뽑은 원리를 실제 팀 유형별 하네스 설계로 옮깁니다.
관찰 기반 모델
아래 시나리오는 특정 한 회사 문서를 그대로 옮긴 것이 아니라, 앞선 다섯 사례를 각 도메인의 실패 모드에 맞게 다시 짠 적용 모델입니다.
한눈에 보는 도메인별 차이
| 팀 유형 | 가장 큰 위험 | load-bearing 하네스 요소 | 먼저 볼 페이지 |
|---|---|---|---|
| 프론트엔드 팀 | "코드는 맞는데 화면이 깨짐" | browser QA, design rules, a11y gate | scenario-frontend-team |
| 플랫폼 팀 | 공통 모듈/릴리즈 규칙 위반 | invariants, impact analysis, release gate | scenario-platform-team |
| 결제·정산 팀 | 금전/정합성/감사 사고 | approval, reconciliation, audit trail | scenario-payments-team |
| AI 제품 팀 | 모델 드리프트와 평가 부재 | eval set, safety policy, canary loop | scenario-ai-product-team |
어떤 사례에서 무엇을 주로 가져오는가
이 다이어그램의 의미는 단순합니다.
- 프론트엔드 팀은 OpenAI식 observability와 Anthropic식 QA 분리가 특히 중요합니다.
- 플랫폼 팀은 OpenAI식 repo-readable 구조와 Toss식 global/domain layering이 핵심입니다.
- 결제 팀은 Toss식 HITL과 운영 게이트가 load-bearing이 됩니다.
- AI 제품 팀은 Anthropic식 evaluation과 revfactory식 domain-first 설계가 중요합니다.
Anthropic이 2026년에 발표한 financial agent template은 이 도메인 관점을 제품 패키지 형태로도 보여줍니다. 금융 agent template은 단순한 프롬프트 묶음이 아니라 skills, connectors, subagents, per-tool permission, credential vault, audit log, approval flow를 함께 묶습니다. 그래서 이 책의 도메인 플레이북도 "업무별 프롬프트 예시"가 아니라 도메인별 실행 경계와 감사 가능성을 포함한 하네스 패키지로 읽어야 합니다.
팀별로 먼저 정해야 할 질문
| 질문 | 프론트엔드 | 플랫폼 | 결제·정산 | AI 제품 |
|---|---|---|---|---|
| 무엇이 "완료"인가 | 화면과 상호작용 | 공유 규칙 불변성 | 정합성/감사 통과 | offline+online eval 통과 |
| 가장 중요한 검증 | 브라우저, a11y | contract, release gate | reconciliation, approval | eval suite, telemetry |
| 사람 승인은 어디서 필요한가 | 사용자 영향 큰 UI | 공통 모듈/배포 규칙 | 거의 항상 고위험 변경 | 모델/정책/툴 권한 변경 |
| 오래 남겨야 할 아티팩트 | QA report, screenshots | ADR, invariants, release notes | audit log, rollback plan | eval report, prompt spec |
추천 읽기 순서
시나리오: 프론트엔드 팀
UI 상태, 브라우저 QA, 접근성, 디자인 시스템 규칙이 중심인 팀
시나리오: 플랫폼 팀
공통 모듈, 모노레포, 릴리즈 게이트, 아키텍처 불변식이 중심인 팀
시나리오: 결제·정산 팀
승인, 정합성, 감사 추적, 금전 사고 방지가 핵심인 팀
시나리오: AI 제품 팀
평가셋, 모델 교체, 안전 정책, online telemetry가 핵심인 팀
무엇을 공통으로 유지하고 무엇을 갈라야 하는가
공통으로 유지할 것:
AGENTS.md같은 진입 문서- 기본 검증 명령
- updates와 verification 로그
- 공통 approval vocabulary
도메인별로 갈라야 할 것:
- 완료 정의
- evaluator와 QA 구성
- human gate 조건
- 운영 중 보는 지표
- connector / MCP / credential vault 경계
- 도메인 template을 plugin, skill, cookbook 중 무엇으로 배포할지
결론
하네스는 회사마다 다른 데 그치지 않고 도메인마다 다르게 load-bearing합니다. 그래서 좋은 팀 하네스는 하나의 범용 템플릿이 아니라, 공통 바닥 위에 도메인별 플레이북을 얹는 형태로 자랍니다.