사례: Toss
Toss의 frictionless harness와 executable SSOT를 global·domain·local 레이어 관점에서 정리합니다.
핵심 요약
- Toss 사례는 하네스를 개인 생산성 비법이 아니라 팀 생산성의 저점을 올리는 distribution problem으로 다룹니다.
- Global(공통 기준)·Domain(팀별 위험·승인 규칙)·Local(개인 선호·작업 맥락) 세 레이어로 나눠 편차의 바닥을 올리면서 도메인 특화 성능을 확보합니다.
- executable SSOT는 문서가 실제 command·workflow로 이어지거나 승인·검증 기준으로 직접 참조될 때 성립합니다.
- domain별 HITL을 둬서 결제·growth·support처럼 팀마다 다른 고위험 변경에 서로 다른 human gate를 적용합니다.
- workflow가 frictionless하지 않으면 사람들이 우회하고 결국 구전으로 돌아가므로, 마찰 측정 자체가 운영 신호가 됩니다.
Toss 사례가 중요한 건 하네스를 개인 생산성 비법이 아니라 팀 생산성의 저점을 올리는 시스템으로 읽기 때문입니다.
이렇게 보면 하네스는 "잘하는 몇 명의 루틴"이 아니라 조직 전체에 배포해야 하는 운영 자산이 됩니다.
해결하려는 문제
- 같은 모델을 써도 팀원마다 산출물 편차가 큼
- 문서가 있어도 실제 실행 경로가 제각각임
- 팀 규칙이 구전으로만 전달됨
- 인간 승인 지점이 암묵적이라 사고가 사람 역량에 의존함
기술적 메커니즘
Toss식 하네스는 보통 세 레이어로 나눠 봅니다.
| 레이어 | 담는 것 | 엔지니어링 의미 |
|---|---|---|
| Global | 공통 명령, 공통 원칙, 공통 검증 | 편차의 바닥을 올림 |
| Domain | 제품/팀별 규칙, 승인 조건, 위험 패턴 | 도메인 특화 성능을 만듦 |
| Local | 개인 선호, 임시 실험, 작업 컨텍스트 | 빠른 적응과 탐색 |
executable SSOT가 중요한 이유
Toss 관점에서 문서는 "좋은 설명"만으로는 부족합니다. 실행 가능한 SSOT가 되려면 아래 둘 중 하나는 만족해야 합니다.
- 실제 커맨드나 workflow로 이어진다.
- 승인/검증 기준으로 직접 참조된다.
예를 들면:
workflow:
name: ui-change
steps:
- read: AGENTS.md
- read: docs/design-rules.md
- implement: app/**
- verify:
- lint
- browser
- a11y-check
- request_approval_if:
- "payment screen changed"
- "legal copy changed"이건 단순 문서가 아니라 누가 어떤 순서로 무엇을 검증해야 하는지를 실행 경로로 내려놓은 형태입니다.
왜 이게 엔지니어링인가
Toss 사례는 하네스를 distribution problem으로 다룹니다.
좋은 루틴 하나를 만드는 게 아니라 그 루틴이 조직 전체에서 frictionless하게 재현되게 만드는 문제입니다.
| 설계 대상 | 바꾸는 것 |
|---|---|
| workflow 표준화 | 개인별 절차 편차 |
| executable SSOT | 읽고 끝나는 문서 문제 |
| domain HITL | 위험 작업 승인 누락 |
| global/domain/local layering | 과도한 중앙집중 또는 과도한 개인화 |
domain별 HITL이 필요한 이유
모든 팀이 같은 승인 정책을 쓰면 비효율적입니다. 반대로 승인 기준이 팀마다 완전히 다르면 위험합니다.
그래서 domain layer가 필요합니다.
domains:
payments:
human_gate:
- "가격 변경"
- "결제 플로우 UI 변경"
growth:
human_gate:
- "실험군 배분 로직 변경"
support:
human_gate:
- "보상/환불 정책 변경"이렇게 해야 글로벌 규칙을 유지하면서도 도메인별 위험 특성을 반영합니다.
실제 도입 장면으로 번역하면
모든 팀이 최소한 동일하게 읽는 AGENTS.md, 검증 명령, 승인 규칙을 만든다.
결제, 데이터, 권한, 정책처럼 팀별로 다른 위험 기준을 domain layer에 둔다.
문서에 써두는 대신 실제 command, CI, check script, bot workflow로 연결한다.
사람들이 우회하거나 안 쓰는 단계가 있으면 frictionless하지 않다는 뜻이다.
우리 팀으로 옮길 것
- 공통
checklist와approval policy를 global layer로 분리 - 제품별
runbooks/와risk-rules/를 domain layer로 분리 - 개인 프롬프트/메모는 local layer로 제한
- 문서는 가능한 한 명령, bot, CI gate와 연결
그대로 복제하면 안 되는 점
- 모든 규칙을 중앙에 몰아넣으면 domain 감각이 사라집니다.
- workflow가 frictionless하지 않으면 결국 구전과 우회가 생깁니다.
- 문서가 길기만 하고 실행으로 안 이어지면 SSOT가 아닙니다.
결국 Toss 사례가 말하는 건 "팀 전체가 일정 수준 이하로 무너지지 않게 만드는 배포형 하네스"입니다.
참고
- Toss,
Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기, 2026-02-26