사례: Toss

Toss 사례가 중요한 이유는, 하네스를 개인 생산성 비법이 아니라 팀 생산성의 저점을 올리는 시스템으로 읽기 때문입니다.

이 관점이 들어오면 하네스는 더 이상 "잘하는 몇 명의 루틴"이 아니라 조직 전체에 배포해야 하는 운영 자산이 됩니다.

해결하려는 문제

• 같은 모델을 써도 팀원마다 산출물 편차가 큼
• 문서가 있어도 실제 실행 경로가 제각각임
• 팀 규칙이 구전으로만 전달됨
• 인간 승인 지점이 암묵적이라 사고가 사람 역량에 의존함

기술적 메커니즘

Toss식 하네스는 보통 세 레이어로 읽을 수 있습니다.

executable SSOT가 중요한 이유

Toss 관점에서 문서는 "좋은 설명"만으로는 부족합니다. 실행 가능한 SSOT가 되려면 아래 둘 중 하나 이상을 만족해야 합니다.

1. 실제 커맨드나 workflow로 이어져야 합니다.
2. 승인/검증 기준으로 직접 참조되어야 합니다.

예를 들면:

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하게 재현되게 만드는 문제입니다.

domain별 HITL이 필요한 이유

모든 팀이 같은 승인 정책을 쓰면 비효율적입니다. 반대로 승인 기준이 팀마다 완전히 다르면 위험합니다.

그래서 domain layer가 필요합니다.

domains:
  payments:
    human_gate:
      - "가격 변경"
      - "결제 플로우 UI 변경"
  growth:
    human_gate:
      - "실험군 배분 로직 변경"
  support:
    human_gate:
      - "보상/환불 정책 변경"

이렇게 해야 글로벌 규칙은 유지하면서도, 도메인별 위험 특성을 반영할 수 있습니다.

실제 도입 장면으로 번역하면

우리 팀으로 옮길 것

• 공통 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