도메인별 적용 지도

프론트엔드 팀, 플랫폼 팀, 결제·정산 팀, AI 제품 팀이 하네스를 어떻게 다르게 설계해야 하는지 안내합니다.

외부 사례를 공부한 뒤 바로 부딪히는 질문은 이것입니다.

그래서 우리 팀은 무엇을 어떻게 다르게 설계해야 하는가?

이 장은 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 설계가 중요합니다.

팀별로 먼저 정해야 할 질문

질문	프론트엔드	플랫폼	결제·정산	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

무엇을 공통으로 유지하고 무엇을 갈라야 하는가

공통으로 유지할 것:

AGENTS.md 같은 진입 문서
기본 검증 명령
updates와 verification 로그
공통 approval vocabulary

도메인별로 갈라야 할 것:

완료 정의
evaluator와 QA 구성
human gate 조건
운영 중 보는 지표

결론

하네스는 회사별로만 다른 것이 아니라 도메인별로도 다르게 load-bearing합니다. 그래서 좋은 팀 하네스는 하나의 범용 템플릿이 아니라, 공통 바닥 위에 도메인별 플레이북이 얹힌 형태로 발전합니다.

외부 사례를 공부한 뒤 바로 부딪히는 질문은 이것입니다.

그래서 우리 팀은 무엇을 어떻게 다르게 설계해야 하는가?

이 장은 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 설계가 중요합니다.

팀별로 먼저 정해야 할 질문

질문	프론트엔드	플랫폼	결제·정산	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

무엇을 공통으로 유지하고 무엇을 갈라야 하는가

공통으로 유지할 것:

AGENTS.md 같은 진입 문서
기본 검증 명령
updates와 verification 로그
공통 approval vocabulary

도메인별로 갈라야 할 것:

완료 정의
evaluator와 QA 구성
human gate 조건
운영 중 보는 지표

도메인별 적용 지도

한눈에 보는 도메인별 차이

어떤 사례에서 무엇을 주로 가져오는가

팀별로 먼저 정해야 할 질문

추천 읽기 순서

시나리오: 프론트엔드 팀

시나리오: 플랫폼 팀

시나리오: 결제·정산 팀

시나리오: AI 제품 팀

무엇을 공통으로 유지하고 무엇을 갈라야 하는가

결론

목차

도메인별 적용 지도

한눈에 보는 도메인별 차이

어떤 사례에서 무엇을 주로 가져오는가

팀별로 먼저 정해야 할 질문

추천 읽기 순서

시나리오: 프론트엔드 팀

시나리오: 플랫폼 팀

시나리오: 결제·정산 팀

시나리오: AI 제품 팀

무엇을 공통으로 유지하고 무엇을 갈라야 하는가

결론

목차