팀 하네스 배포 전략
Toss, gstack, revfactory/harness 사례를 바탕으로 개인 루틴을 팀의 실행 시스템으로 확장하는 방법을 설명합니다.
좋은 하네스를 혼자 쓰는 것과, 팀 전체가 비슷한 기본 품질로 쓰게 만드는 것은 전혀 다른 문제입니다.
Toss는 이를 조직 생산성 저점 높이기의 문제로 보고,
gstack과 revfactory는 각각 opinionated workflow와 generated harness라는 방식으로 접근합니다.
배포의 단위는 문서가 아니라 workflow다
문서를 잘 써 두는 것만으로는 팀 전체 사용성을 높이기 어렵습니다. 배포 단위가 아래처럼 더 실행 친화적이어야 합니다.
| 배포 단위 | 역할 |
|---|---|
| Command | 자주 반복하는 작업 순서를 캡슐화 |
| Skill | 역할별 전문 지식을 묶음 |
| Template | plan, runbook, updates, release note의 형식 통일 |
| Hook / Script | 검증과 차단을 자동화 |
| Doc | 왜 그런지 설명하고 기준일을 남김 |
frictionless harness가 중요한 이유
좋은 하네스라도 쓰기 어렵고 귀찮으면 팀은 다시 구전과 개인 감각으로 돌아갑니다.
배포 원칙
팀 하네스는 "잘 만든 것"보다 "기본 루틴에 자연스럽게 녹아드는 것"이 먼저입니다.
팀 확장의 기본 구조
어떤 팀부터 어디까지 해야 하는가
우선 필요한 것:
- 짧은
AGENTS.md - review / browser QA 같은 핵심 command 2~3개
- updates 로그
목표:
- 특정 고수의 감각을 최소한의 공통 루틴으로 바꾸기
우선 필요한 것:
- global / domain / local 레이어 분리
- 공통 release gate
- 도메인별 skill / template
목표:
- 팀원별 편차를 줄이고, 신규 구성원 ramp-up 속도를 높이기
우선 필요한 것:
- 하네스 표준 레지스트리
- 제품군별 domain harness
- telemetry, stale detection, lifecycle 관리
목표:
- 여러 팀에 걸쳐 하네스를 재사용 가능하게 배포하고 운영하기
Toss에서 배울 rollout 포인트
- Global / Domain / Local 레이어를 분리할 것
- workflow와 plugin이 executable SSOT 역할을 하게 할 것
- 개인이 잘 쓰는 패턴을 팀 workflow로 내려야 할 것
- frictionless가 아니면 adoption이 무너진다는 점을 기억할 것
gstack에서 배울 rollout 포인트
- 역할별로 강한 opinion이 담긴 command 세트를 제공할 것
- review, test, ship, reflect가 실제 작업 흐름으로 연결되게 할 것
- 브라우저 QA와 릴리즈 문서 업데이트를 별도 단계로 둘 것
revfactory/harness에서 배울 rollout 포인트
revfactory/harness는 rollout을 "생성 가능한 하네스"로 봅니다.
기본 아이디어:
- 도메인을 분석한다
- 아키텍처 패턴을 고른다
- agent team과 skill을 생성한다
- validation으로 튜닝한다
이 방식의 장점은, 하네스 설계를 템플릿화할 수 있다는 점입니다. 하지만 단점도 분명합니다.
- 도메인 해석을 잘못하면 generated harness도 어긋난다
- 검증 기준이 약하면 그럴듯한 scaffolding만 많아진다
30 / 60 / 90일 rollout
30일: 반복 실패가 많은 작업 2~3개를 골라 command와 checklist로 외재화합니다.
60일: domain layer를 분리하고 review / browser QA / release gate를 연결합니다.
90일: telemetry, updates, garbage collection cadence를 넣어 lifecycle을 운영합니다.
팀에 배포할 최소 패키지
| 구성 | 최소 포함물 |
|---|---|
| 진입 문서 | AGENTS.md, 읽기 경로, 필수 검증 명령 |
| domain docs | 아키텍처, 불변식, release gate |
| workflow | review, QA, ship, updates |
| 운영 로그 | updates, stale cleanup 기록 |
rollout이 잘 되고 있다는 신호
- 신규 팀원이 기존 고수와 비슷한 수준으로 첫 작업을 끝낸다
- 리뷰 코멘트가 "같은 문제 반복"에서 "의사결정 개선"으로 바뀐다
- 특정 사람만 알고 있던 명령과 루틴이 command / skill로 정착한다
- 모델이 바뀌어도 기본 작업 품질이 덜 흔들린다
결론
하네스를 팀에 배포한다는 것은 문서를 나눠주는 일이 아니라, 좋은 작업 방식을 시스템 형태로 배포하는 일입니다.