“의미 없는 자동화는 사람을 바쁘게 만든다.
의미 있는 자동화는 팀의 판단 비용을 줄인다.”

이번 글은 도구 홍보가 아니라, 내가 실제로 구성한 운영 레이어를 풀어쓴 기록이다.
핵심 질문은 하나다.

“어떤 구조를 만들면 하루 업무가 덜 흔들리고, 장애가 나도 복구가 빨라지는가?”

TL;DR

  • 내 구성의 목적은 “자동화 많이 하기”가 아니라 판단 비용 줄이기다.
  • 핵심은 기능 수가 아니라 호출 순서와 종료 조건을 고정하는 것이다.
  • 실제 효과는 “체감”이 아니라, 맥락 전환·리뷰 편차·복구 지연이 줄었는지로 본다.

이 글이 특히 유용한 사람

  • 개인 자동화를 하고 있지만, 점점 규칙이 늘어 통제가 어려워진 사람
  • 팀에서 리뷰 품질 편차와 맥락 전환 비용을 줄이고 싶은 사람
  • “도구 소개”가 아니라 “운영 가능한 구조”를 보고 싶은 사람

내가 실제로 구성한 전체 구조

내 구성은 7개 레이어로 나뉜다.

  1. 진입 레이어: 시작점 고정 (/cb:guide)
  2. 실행 레이어: 요구 -> 구현 -> 마감
  3. 리뷰 레이어: 품질 관점 분리
  4. 장애 레이어: 장애 시 공용 언어
  5. 연동 레이어: Slack/PR 연결
  6. 경계 레이어: 시크릿·권한 경계
  7. 지식 레이어: 회고/블로그 루틴

이걸 “구조도”로 그리면 복잡해 보이지만, 실제 사용은 단순하다.
매일 반복되는 경로를 정해두고, 예외 상황(장애/긴급 리뷰)만 분기한다.

1) Entry layer: /cb:guide 하나로 시작

작업이 꼬일 때 가장 먼저 생기는 문제는 “지금 뭘 호출해야 하지?”다.
그래서 시작점은 무조건 하나로 고정했다.

  • /cb:guide workflow
  • /cb:guide review

이 두 개만 보면 다음 액션이 정해진다.
도구가 많아도 시작점이 하나면 인지 부하가 급격히 줄어든다.

2) Workflow layer: 요구를 작업 단위로 바꾸는 계층

이 계층은 “코드를 잘 짜는 법”이 아니라 “덜 놓치는 법”에 가깝다.

intake: 모호한 요청을 실행 문장으로 변환

실제 입력은 대부분 이런 식이다.

  • Slack 링크 1개
  • “이거 급해요” 한 줄
  • 문서 링크 + 짧은 코멘트

/cb:intake의 역할은 이걸 Jira/작업 문장으로 바꾸는 것이다.

work-triage: 유형 분류 + 분할 전략

이게 실제로 가장 자주 쓰는 커맨드다.

/cb:work-triage TASK-1754

work-triage는 작업을 A/B/C/F 같은 유형으로 분류하고, 아래를 강제로 만든다.

  • 베이스 브랜치
  • 커밋 단위
  • 최소 AC
  • QA 스팟

예를 들어 API 마이그레이션이면 “범위 내 import 0건” 같은 종료 조건을 미리 넣는다.

실제로 내가 자주 보는 triage 출력은 이런 형태다.

분류 결과
- Primary: A (API migration)
- 근거: legacy import 잔존 + 공통 fetch 분산

실행 전략
- base: feat/epic-api-cleanup
- branch: feat/TASK-1754-legacy-api-cleanup
- AC: import 0건, throw 경로 통일, QA 스팟 4개

work-start: 시작 루틴 표준화

/cb:work-start TASK-1754 legacy-api-cleanup

여기서 자동화하는 건 화려한 게 아니다.

  • 브랜치명 규칙 고정
  • 베이스 확인
  • 범위 grep 카운트 기록

즉, “잘 시작하기”를 루틴으로 만든다.

work-closeout: 마감 루틴 표준화

/cb:work-closeout TASK-1754 1234

종료 시점에 꼭 확인하는 것:

  • 브랜치 상태
  • PR 상태
  • AC 충족 여부
  • 다음 티켓 연결

코드가 끝났다고 작업이 끝난 게 아니라, 다음 사람이 이어받을 수 있어야 완료다.

3) Review layer: 리뷰 편차를 줄이는 계층

리뷰를 한 번에 하려고 하면 항상 빠지는 관점이 생긴다.
그래서 순서를 고정했다.

/cb:prd-review -> /cb:pr-checklist -> /cb:typescript-review
-> /cb:nextjs-review -> /cb:react-review -> /cb:hygiene-review
-> /cb:critical-review

각 커맨드가 보는 축은 다르다.

  • PRD: “이 변경이 요구사항과 맞는가”
  • Checklist: “기본 게이트를 통과했는가”
  • TS/Next/React: “스택 리스크가 없는가”
  • Hygiene: “유지보수 부채를 키우지 않았는가”
  • Critical: “지금 막아야 할 릴리즈 리스크가 있는가”

핵심은 엄격함이 아니라 재현성이다.
리뷰어가 바뀌어도 큰 기준이 흔들리지 않게 만든다.

그리고 마지막 critical 단계에서는 일부러 질문을 좁힌다.

  • “좋아 보이나?”를 묻지 않는다.
  • “지금 머지하면 위험한가?”만 묻는다.

4) Incident layer: 망한 날에 쓰는 계층

평소엔 잘 안 쓰지만, 필요할 때 ROI가 제일 크다.

  • /cb:incident-declare
  • /cb:incident-response
  • /cb:incident-postmortem
  • /cb:incident-guide

이 계층의 목표는 “빨리 고쳤다”가 아니다.

  • 상태를 한 문장으로 공유
  • 업데이트 포맷 통일
  • 사후 기록을 다음 대응의 시작점으로 저장

즉, 장애 때 감정이 아니라 문장으로 움직이게 한다.

5) Integration layer: Slack/PR 사이를 잇는 계층

사례 A — 리뷰 요청 자동화 (/cb:slack-review-request)

실제 쓰는 패턴:

/cb:slack-review-request 1234

이 커맨드가 하는 핵심은 “메시지 예쁘게 쓰기”가 아니다.

  • draft PR 차단
  • 이미 승인 완료 PR 차단
  • 리뷰 요청 대상 멘션 정리
  • 최종 메시지 초안 생성 후 사용자 확인

즉, 요청 품질 게이트를 한 번 더 친다.

실제 전송 전 초안은 대략 이런 톤으로 만든다(익명화):

@reviewer-a @reviewer-b

리뷰 부탁드려요 🙏

[TASK-1754] checkout copy 정합성 수정
- 영향: checkout/mypage
- 비목표: native 경로

<PR 링크>

사례 B — 반대 방향 리뷰 (/cb:slack-pr-review)

실제 패턴:

/cb:slack-pr-review <slack-permalink> 1234

이 흐름은 Slack 맥락 -> PR diff 리뷰로 이어진다.

  • 스레드 읽기
  • PR 상태 확인 (이미 머지면 철수)
  • 리뷰 시작/완료 신호(eyes/check)
  • 요약 코멘트 정리

이걸 붙여놓으면 “리뷰 요청 맥락”과 “코드 사실”이 분리되지 않는다.

6) Boundary layer: 경계 없는 자동화는 오래 못 간다

내가 실제로 고정한 경계:

  • mcp.json, .env, 토큰은 공유 자산에서 제외
  • 실험 로그/개인 대화 로그는 운영 자산에서 제외
  • 위험 액션은 자동 승인하지 않고 확인 지점 유지

편의성보다 경계를 먼저 잡아야 하는 이유는 단순하다.
자동화 실패는 보통 “기능 부족”보다 “경계 부재”에서 터진다.

7) Knowledge layer: 블로그도 운영 루틴으로 관리

이번에 블로그 흐름도 규칙으로 고정했다.

  • 초안 위치: blog-drafts
  • 본문 SSOT: 블로그 _posts
  • 발행 후: 초안 삭제 (중복 보관 금지)

이건 글쓰기 습관 문제가 아니다.
출처가 두 군데면 결국 충돌한다는 운영 원칙이다.

실제 하루 시나리오 1개 (익명화)

아래는 최근 자주 반복되는 하루 흐름을 익명화한 예시다.

오전 10:15 — Slack 요청 수신

  • “결제 화면 특정 경로에서 문구 불일치”
  • 링크 2개(스레드 + 기존 티켓)

오전 10:20 — 작업 정의

/cb:intake <slack-link>
/cb:work-triage TASK-1754

결과:

  • 유형: 작은 동작 변경 + 일부 리그레션 점검
  • 베이스: feature 브랜치
  • AC: 문구 정합 + 회귀 경로 3개

오전 10:30 — 착수

/cb:work-start TASK-1754 checkout-copy-fix

결과:

  • 브랜치 생성
  • 영향 파일 범위 확인
  • 시작 체크리스트 확정

오후 12:10 — PR 생성

/cb:pr-body 1234
/cb:slack-review-request 1234

결과:

  • 본문 구조 통일
  • 리뷰 요청 메시지 초안 생성
  • 승인 완료 PR/드래프트 PR 차단 규칙 적용

오후 2:40 — 리뷰 반영 후 마감

/cb:critical-review 1234
/cb:work-closeout TASK-1754 1234

결과:

  • 릴리즈 블로커 확인
  • 완료 조건 체크 + 다음 티켓 연결

핵심은 “대단한 자동화”가 아니다.
각 단계에서 놓치기 쉬운 판단을 문장으로 강제하는 것이다.

이 시나리오에서 내가 실제로 얻는 건 속도 자체보다 다음 두 가지다.

  • PR 본문 품질의 하한선이 일정해짐
  • 리뷰 요청 커뮤니케이션의 편차가 줄어듦

실제 장애 시나리오 (익명화)

장애는 대부분 “정보 불일치”에서 커진다.
그래서 incident 계층은 아래만 강제한다.

  1. 선언 문장 (declare)
  2. 진행 문장 (response)
  3. 사후 문장 (postmortem)

이 세 개가 있으면 다음이 바뀐다.

  • 누가 뭘 하는지 즉시 보임
  • 중복 대응이 줄어듦
  • 복구 뒤에 같은 사고 반복이 줄어듦

실패 사례 1: 자동화가 오히려 범위를 키운 날

한 번은 작은 문구 수정 이슈를 너무 빨리 “개선 패키지”로 키운 적이 있다.

상황

  • 원래 목표: 특정 화면 문구 정합성 1건 수정
  • 실제 결과: 문구 수정 + 구조 정리 + 공통 유틸 손보기까지 한 PR에 포함

당시 내가 한 행동 (문제 지점)

  1. work-triage에서 “작은 동작 변경”으로 분류했지만
  2. 구현 중에 “이참에 같이 고치자”를 반복했고
  3. work-closeout에서 범위 재확인 없이 바로 리뷰 요청으로 넘어갔다

겉으로는 속도가 빨랐지만, 실제론 검증면적이 커져서 리뷰 왕복이 늘었다.
결과적으로 머지까지 더 오래 걸렸다.

무엇을 바꿨나

  • work-triage 결과에 비목표(Non-goal)를 명시
  • work-closeout에서 “최초 목표 대비 추가 범위” 체크를 강제
  • 추가 범위가 생기면 PR 분리 또는 follow-up 티켓 생성

이 실패에서 얻은 교훈

자동화가 빠르게 도와줄수록, 사람이 범위를 더 엄격히 닫아야 한다.
속도는 도구가 만들지만, 경계는 사람이 만든다.

예외 처리 사례 1: 릴리즈 직전 핫픽스라 정규 순서를 못 탄 날

모든 작업이 정규 파이프라인을 탈 수는 없다.
릴리즈 직전 핫픽스는 시간을 줄여야 하는 순간이 있다.

상황

  • 증상: 특정 경로에서 즉시 복구가 필요한 이슈 발생
  • 제약: 배포 시간 창이 짧아서 리뷰 체인을 전부 돌리기 어려움

정규 순서 대신 최소 경로로 우회

원래는: intake -> triage -> start -> pr-body -> review-chain -> closeout

핫픽스에서는:

  1. work-start로 브랜치/범위만 빠르게 고정
  2. 최소 수정 후 critical-review 우선
  3. work-closeout에서 예외 사유와 후속 작업 기록

즉, 절차를 생략한 게 아니라 핵심 안전 단계만 남겼다.

예외를 기록하는 방식

핫픽스에서 내가 남기는 문장 템플릿은 짧다.

[Exception]
- reason: release-window hotfix
- skipped: full review-chain
- applied: critical-review + manual smoke
- follow-up: next business day checklist/hygiene backfill

이 기록이 있으면 다음날 보완 작업이 “기억”이 아니라 “할 일”이 된다.

이 예외에서 얻은 교훈

좋은 프로세스는 예외를 금지하지 않는다.
대신 예외를 추적 가능하게 남기는 방법을 포함한다.

내가 실제로 버린 것들

오래 써본 뒤 삭제한 것들:

  • 만능 프롬프트 하나로 모든 상황 커버하려는 시도
  • 팀 합의 없는 개인 규칙 자동 강제
  • 지표 없이 “좋아 보이는” 커맨드 추가

남긴 기준은 3개뿐이다.

  1. 호출 경로가 명확한가
  2. 출력 포맷이 재현 가능한가
  3. 실패 시 다음 행동이 보이는가

다음 보완 계획

  1. /cb:* 사용률 낮은 항목 정리 (삭제 후보 공개)
  2. 온보딩 10분 버전 문서 분리
  3. 실패/예외 사례를 분기별로 1개씩 추가 기록

오늘 바로 적용 3단계

  1. 시작점을 하나로 고정한다 (guide 역할 문서/커맨드 만들기)
  2. 작업 마감 체크리스트에 범위 확장 여부 한 줄을 추가한다
  3. 예외 처리 시 반드시 이유/생략/후속 3줄을 남긴다

마치며

내가 구성한 건 도구 모음이 아니다.
실무에서 흔들리는 지점을 줄이기 위한 운영 레이어다.

그래서 이 구성이 의미 있는지는 저장소 크기로 판단하지 않는다.
맥락 전환 비용, 리뷰 편차, 복구 지연이 실제로 줄었는지로 판단한다.

한 줄 결: 개인 자동화의 완성도는 기능 수가 아니라, 팀의 판단 비용을 얼마나 줄였는지로 측정된다.