본문으로 바로가기
리옵트 핸드북
리옵트 핸드북
하네스 엔지니어링

문제 설정·구조

하네스 엔지니어링의 기초Repo-readable 시스템하네스의 5요소하네스의 기술 메커니즘

검증·해석

검증 루프 설계외부 사례 비교

사례별 도입

사례: OpenAI사례: Anthropic사례: Toss사례: gstack사례: revfactory/harness

도메인별 적용

도메인별 적용 지도시나리오: 프론트엔드 팀시나리오: 플랫폼 팀시나리오: 결제·정산 팀시나리오: AI 제품 팀왜 결국 자기 하네스로 가는가

도입·운영

팀 하네스 배포 전략팀 하네스 설계 체크리스트운영: 엔트로피와 가비지 컬렉션

부록

검증 리포트업데이트 내역
핸드북›하네스 엔지니어링›시나리오: 결제·정산 팀
한국어English

시나리오: 결제·정산 팀

결제·정산 도메인에서 하네스가 승인, 정합성 검증, 감사 추적, rollback 시스템으로 작동하는 방식을 설명합니다.

핵심 요약

  • 결제·정산 하네스는 생산성 도구가 아니라 사고 확률과 손실 반경을 줄이는 financial correctness 통제 시스템입니다.
  • approval policy, reconciliation check, audit trail, rollback plan이 load-bearing 요소입니다.
  • reconciliation은 "실행됨"으로 끝나지 않고, input fixture·expected ledger·actual result를 비교해 단위·세금 반올림·환불 상태 불일치를 잡아냅니다.
  • 가격·정산 규칙·환불 처리·회계 필드 변경은 human_gate로 분리하고 risk-classification.yaml을 강제합니다.
  • 30일 도입은 가격·환불·정산 변경에 risk-classification을 붙이고 reconciliation-report 없이는 merge를 막는 것입니다.

결제·정산 팀은 하네스가 없으면 가장 위험해지는 팀에 속합니다. 이 도메인에서 "대충 맞는 것 같다"는 곧장 사고로 이어집니다.

문제 구조

  • 금전 처리 로직의 작은 오류가 직접 손실로 이어짐
  • 변경 후 즉시 눈에 안 보여도 정산 시점에 사고가 드러날 수 있음
  • 감사 로그와 승인 근거가 사후에 필요함
  • 배포 전에 사람이 봐야 할 변경이 명확해야 함

load-bearing 하네스 요소

요소왜 중요한가
approval policy위험 변경을 자동화 범위에서 분리
reconciliation check"실행됨"이 아니라 "맞게 반영됨"을 확인
audit trail나중에 누가 어떤 판단을 했는지 복원 가능
rollback plan실수했을 때 빠르게 되돌릴 수 있어야 함

권장 루프

아티팩트 구조 예시

pricing-rules.md
ledger-invariants.md
approval-policy.md
risk-classification.yaml
reconciliation-report.md
audit-log.md
rollback-plan.md

approval policy 예시

payments_change:
  auto:
    - "운영 문서 수정"
  review_required:
    - "테스트/fixture 변경"
    - "정산 화면 UI 변경"
  human_gate:
    - "가격 로직 변경"
    - "정산 규칙 변경"
    - "환불/취소 처리 변경"
    - "회계/세무 관련 필드 변경"

reconciliation check 예시

reconciliation:
  compare:
    - "input fixture"
    - "expected ledger output"
    - "actual persisted result"
  fail_if:
    - "minor unit mismatch"
    - "tax rounding mismatch"
    - "refund state transition mismatch"

왜 이게 엔지니어링인가

결제 하네스는 사실상 financial correctness engineering입니다.

  • 구현 결과를 fixture와 ledger invariant로 검증합니다.
  • 승인을 human gate로 분리합니다.
  • audit trail을 남겨 나중에 검증할 수 있게 합니다.
  • rollback을 설계에 포함합니다.

이 도메인에서 하네스는 생산성 보조도구가 아니라 사고 확률과 손실 반경을 줄이는 통제 시스템입니다.

자주 망하는 패턴

실패 패턴하네스로 막는 방식
금액 계산 변경을 일반 코드 수정처럼 취급risk classification으로 고위험 분리
테스트는 통과했지만 정산 결과가 틀림reconciliation report 필수화
나중에 왜 승인했는지 모름audit log와 approval note 남김
rollback이 배포 후에야 논의됨작업 시작 시 rollback plan 작성

30일 도입 순서

  1. 가격/환불/정산 변경은 모두 risk-classification.yaml을 붙인다.
  2. reconciliation-report.md 없이는 merge하지 않도록 고정한다.
  3. human gate가 필요한 변경 범위를 문서가 아니라 workflow로 연결한다.

먼저 연결해서 볼 장

  • /books/harness-engineering/case-toss
  • /books/harness-engineering/case-anthropic
  • /books/harness-engineering/operations

관련 문서

시나리오: 플랫폼 팀

플랫폼 팀에서 하네스가 아키텍처 불변식, 릴리즈 게이트, 영향 반경 관리 시스템으로 작동하는 방식을 설명합니다.

도메인별 적용 지도

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

정산·재무 마감

iOS 앱 엔터프라이즈 운영 · Sales and Trends, Payments and Financial Reports를 월마감 기준으로 맞추는 방법

거버넌스와 소유권

에이전틱 테스트 환경 엔지니어링 · DevEx, SRE, 제품팀, QA 플랫폼, AI 플랫폼 사이의 owner와 승인 경계를 정하는 기준

승인형 백오피스 자동화

Vercel 엔터프라이즈 AI 플랫폼 · approval event, operator identity, side effect 통제를 포함한 백오피스 자동화 패턴을 정리합니다.

시나리오: 플랫폼 팀

플랫폼 팀에서 하네스가 아키텍처 불변식, 릴리즈 게이트, 영향 반경 관리 시스템으로 작동하는 방식을 설명합니다.

시나리오: AI 제품 팀

AI 제품 팀에서 하네스가 eval set, safety policy, online telemetry, model rollout 시스템으로 작동하는 방식을 설명합니다.

On this page

문제 구조load-bearing 하네스 요소권장 루프아티팩트 구조 예시approval policy 예시reconciliation check 예시왜 이게 엔지니어링인가자주 망하는 패턴30일 도입 순서먼저 연결해서 볼 장