Bluetape Skills Part 2: bluetape-workflow로 작업을 시작하는 방법

하나의 요청을 먼저 분류하고, 승인과 검증 관문을 통과한 작업만 다음 단계로 보낸다.

2026-07-11 · Bluetape Skills Part 2

이 글은 「AI와 일하는 환경을 인프라로 만들기」에서 설명한 스킬 계층과 Part 1의 공유·설치 구조를 실제 작업 절차로 연결한 글이다. 협업 환경을 구성하는 요소를 갖추는 데서 한 걸음 더 나아가, 요청 하나가 어떤 순서로 분류되고 승인·실행·검증되는지 살펴본다.

스킬을 설치했다고 모든 이름을 외울 필요는 없다. Bluetape 생태계 작업은 $bluetape-workflow 하나로 시작하면 된다. 이 스킬은 코드를 대신 작성해 주는 만능 프롬프트가 아니다. 요청의 성격을 먼저 파악하고, 그에 맞는 세부 스킬과 검증 수준을 고르는 작업 경로 분류기다.

지금의 분류기가 이런 구조를 갖게 된 데에는 이유가 있다. 이전에는 작업 절차가 있어도 일부 검증 관문을 건너뛰고, 뒤 단계의 성공을 앞 단계의 증거로 갈음하거나, “작은 변경”이라는 이유로 확인 항목을 줄이는 일이 반복됐다. 반대로 안전한 로컬 작업인데도 단계마다 진행 여부를 다시 물어 작업 흐름이 자주 끊기기도 했다.

그래서 첫 계획에서 범위와 결과물을 한 번 승인받고, 승인 뒤에는 안전하고 되돌릴 수 있는 작업을 끊지 않고 이어 가도록 했다. 대신 한 번 열린 검증 관문은 완료 보고만으로 넘기지 않고, 새로 확인한 증거로 통과해야 한다.

$bluetape-workflow

bluetape4k-exposed의 README에 새 캐시 사용 예제를 추가해 줘.

이 요청은 실제 동작을 바꾸지 않는 문서 작업이므로 Type E Maintenance로 분류한다. 반대로 재현 가능한 실패가 있으면 Type C Bug Fix, 새 모듈이나 넓은 API 설계가 필요하면 Type A Full Feature가 된다. 분류에 따라 첫 계획과 필요한 증거, 테스트 범위, PR을 열기 전에 통과해야 할 검증 관문이 달라진다.

첫 단계는 구현이 아니라 분류다

사용자가 작업 유형을 명시했다면 bluetape-workflow는 그 분류를 우선한다. 별도 분류가 없다면 다음 표에서 가장 가벼우면서도 안전한 유형을 고른다.

유형	이런 작업에 사용한다	연결되는 실행 스킬
A · Full Feature	새 모듈·서비스·의존성, 넓은 공개 API, 여러 계층에 걸친 변경	$bluetape-full-feature
B · Fast Track	영향 범위가 좁은 작은 기능이나 확장	$bluetape-fast-track
C · Bug Fix	재현 가능한 결함, 회귀, 잘못된 출력, 실패 테스트	$bluetape-bugfix
D · Code Review	구현 요청이 없는 검토·감사·조사	코드 검토와 언어별 패턴 스킬
E · Maintenance	README, KDoc, 문서, AGENTS, 스킬, 설정, CI 정비	$bluetape-maintenance
P · Publish	스냅숏, 릴리스, BOM·카탈로그 배포 묶음, 태그, Maven Central	$bluetape-publish-jvm 또는 $bluetape-publish-go
F · Self Improve	기준값과 종료 조건이 있는 벤치마크 개선 반복	$bluetape-self-improve

사용자가 작은 작업이라고 불러도 곧바로 Type B가 되는 것은 아니다. 새 dependency나 새 모듈은 변경량이 작아도 Type A다. 검토 요청은 사용자가 구현까지 명시하지 않는 한 Type D에서 멈춘다. 결함 수정과 무관한 기능 추가가 섞였다면 작업 흐름을 둘로 나눈다. 작업에 붙인 이름이 아니라 위험도와 검증 범위가 분류 기준이다.

변경의 위험과 필요한 증거를 기준으로 가장 가벼우면서도 안전한 실행 경로를 고른다.

첫 계획 승인 전에는 읽기만 한다

분류가 끝나면 바로 파일을 고치지 않는다. 먼저 구체적인 계획을 보여 주고 승인을 받는다.

Work type: Type E - Maintenance
Basis: README와 예제 문구만 변경하며 운영 환경의 동작은 그대로다.

1. Action: 현재 README의 언어별 내용과 실제 API 사용법을 확인한다.
   Expected DoD: 소스 코드와 문서의 식별자가 일치한다.
2. Action: README.md와 README.ko.md를 같은 범위로 수정한다.
   Expected DoD: 두 언어 문서의 예제와 링크가 대응한다.
3. Action: 변경 사항 검사와 문서 빌드를 실행한다.
   Expected DoD: 변경한 경로와 링크가 정상적으로 렌더링된다.

이 시점까지는 읽기 전용 조사만 한다. AGENTS.md, 스킬, 소스 코드, Git 상태, 이슈와 PR 메타데이터, 과거 회고 문서는 읽을 수 있다. 하지만 파일 수정, 저장소에 남길 계획 작성, 커밋, PR 생성, 작업 흐름 실행, 병합은 첫 계획을 승인받은 뒤에 한다.

이 검증 관문은 에이전트의 자율성을 줄이려고 만든 것이 아니다. 요청을 잘못 분류한 채 빠르게 구현하면 나중에 되돌려야 할 범위만 커진다. 사용자는 첫 계획에서 범위와 결과물을 확인하고, 에이전트는 승인된 범위 안에서 중간 허가를 반복해서 묻지 않고 끝까지 진행한다.

반복된 실패를 겪으며 승인 경계를 다듬었다

과거에는 “자율적으로 진행”하라는 지침과 “계획을 먼저 승인”받으라는 지침이 서로 다른 문서에 흩어져 있었다. 어떤 작업에서는 에이전트가 계획을 보여 주지도 않고 수정부터 시작했고, 다른 작업에서는 이미 승인된 로컬 수정 하나하나에 다시 허가를 물었다.

이를 다음 경계로 정리했다.

상황	현재 동작
상태, 소스 코드, 스킬, 이슈·PR 메타데이터 확인	승인 전에도 읽기 전용으로 조사한다
첫 번째 구체적인 계획	행동과 예상 완료 조건을 적어 사용자 승인을 받는다
승인된 로컬 수정·테스트·검증	중간 승인을 다시 묻지 않고 계속 진행한다
범위가 크게 달라지는 새 작업	변경된 계획을 다시 보여 주고 승인받는다
병합, 태그, 배포, 릴리스, 파괴적 정리	승인받은 외부 변경의 범위인지 다시 확인한다

승인 관문은 에이전트를 단계마다 멈춰 세우는 장치가 아니다. 사용자가 방향을 결정해야 하는 지점과 에이전트가 책임지고 실행해야 하는 지점을 분리하는 장치다.

체크리스트 한 줄에는 세 가지가 들어간다

승인을 받으면 작업 경로 분류기, 공통 검증 관문, 선택한 세부 스킬의 체크리스트를 만든다. 실행 항목은 다음 형식으로 적는다.

- [ ] **CG-07 — Lock behavior and run targeted proof**
  - **Action:** 변경 계약을 증명하는 가장 작은 테스트와 빌드를 실행한다.
  - **Evidence:** 실제 명령, 결과, 대상 모듈 또는 경로를 기록한다.
  - **Failure:** 실패하면 다음 단계로 가지 않고 구현으로 돌아간다.

Action은 지금 할 일, Evidence는 완료를 증명할 결과, Failure는 증거를 얻지 못했을 때 취할 조치다. 이 세 가지가 있어야 확인란이 단순한 할 일 목록을 넘어 다음 단계를 통제하는 검증 관문이 된다.

상태 규칙도 엄격하다.

• [ ]은 아직 증명되지 않았다는 뜻이며 뒤따르는 단계를 막는다.
• UNKNOWN, 오래된 결과, 에이전트의 말뿐인 완료 보고는 FAIL로 취급한다.
• SKIPPED는 없다. 적용되지 않는 항목은 왜 N/A인지 구체적인 범위 증거를 남긴다.
• 뒤 단계가 성공해도 앞 단계의 누락을 대신 증명하지 못한다.

예를 들어 사이트 빌드가 성공했다고 첫 계획 승인이나 언어별 문서 대응 검토까지 자동으로 통과하는 것은 아니다. 반대로 README만 바꿨다면 Kotlin 컴파일러 진단은 N/A가 될 수 있지만, “.kt 변경 0개”처럼 확인할 수 있는 근거가 필요하다.

이 규칙도 실제 누락을 겪으며 생겼다. 선택 항목을 확인하지 않은 채 N/A로 닫고, CI PASS를 보고 앞선 검증 관문도 통과했다고 간주하거나, 도구의 출력을 읽기도 전에 확인란부터 표시하는 문제가 있었다. 그래서 다음 제약을 추가했다.

• 체크리스트는 파일을 수정하기 전에 만든다.
• 필수, 조건부, N/A 항목을 실행 전에 분류한다.
• 증거를 읽은 직후 해당 항목에 기록한다.
• 실패한 항목은 체크하지 않은 상태로 두고 후속 작업을 막는다.
• 순서를 어겼다면 누락된 항목과 그 영향을 받은 후속 검증을 모두 다시 실행한다.
• 완료 전에는 Required checks: X/Y; N/A: N; Blocked: N 합계가 실제 체크리스트와 맞는지 센다.

그래야 “증거는 나중에 채우겠다”는 방식이 정상 작업 흐름처럼 굳지 않는다. 뒤늦게 확보한 증거는 복구 내역으로 기록하고, 그 증거에 의존한 후속 검증이 여전히 유효한지도 다시 확인한다.

작업 경로 분류기는 여섯 단계를 차례로 연다

bluetape-workflow의 핵심 흐름은 다음과 같다.

WF-01 Classify
  -> WF-02 Write the first concrete plan
  -> WF-03 Obtain first-plan approval
  -> WF-04 Load execution contracts
  -> WF-05 Execute gates in dependency order
  -> WF-06 Repair skipped or weak gates

WF-04에서는 모든 스킬을 한꺼번에 읽지 않는다. Type E라면 $bluetape-maintenance, 공통 검증 관문, 현재 작업에 필요한 참고 자료만 읽는다. Kotlin 구현이면 $bluetape-kotlin-patterns, Go라면 $bluetape-go-patterns, 글이라면 $bluetape-writer를 추가한다. 필요한 지침만 골라 문맥 사용량을 줄이되, 한 번 선택한 지침은 끝까지 읽는다.

WF-05는 단계 사이의 의존 순서를 지킨다. 테스트보다 먼저 코드를 고쳤다는 이유만으로 검증 관문이 실패하는 것은 아니다. 하지만 결함 수정에서 재현과 회귀 테스트를 건너뛰고 구현부터 했다면 순서가 깨진다. 이때 WF-06에서 누락된 관문을 복구하고, 그 영향을 받은 검증도 다시 실행한다.

WF-06을 별도 단계로 둔 이유도 “이미 여기까지 왔으니 계속하자”는 관성을 막기 위해서다. 검증 관문 누락을 발견하면 후속 작업을 멈춘다. 빠진 단계의 행동과 완료 조건을 다시 세우고 PASS 증거를 얻은 뒤에만 작업을 잇는다.

공통 검증 관문은 작업 전후의 안전선을 맡는다

세부 스킬이 유형별 실행 절차를 맡는다면 공통 검증 관문은 저장소 전체에 적용할 안전선을 맡는다. 항목은 모두 18개이며, 작업의 성격에 따라 적용 여부가 달라진다.

구간	확인하는 내용
CG-01~03	적용할 지침과 과거·현재 증거, 사용자 작업과 작업 트리 경계
CG-04~06	정책·독자·언어 경계, 기존 생태계 패턴 재사용, 공개 계약 문서화
CG-07~10	범위를 좁힌 검증, 무거운 테스트의 직렬 실행, 회고 판단, PR 전 증거 수렴
CG-11~14	PR 생성 권한, 정확한 브랜치 푸시, 실제 PR 검증, CI와 검토 의견 반영
CG-15~18	병합 준비 보고, 새 병합 승인, 병합 검증, 로컬 동기화와 정리

모든 작업에서 18개 항목을 똑같이 실행하는 것은 아니다. 블로그 글에서는 공개 API KDoc과 Testcontainers가 N/A다. 반면 언어별 문서 대응, 사이트 빌드, PR 본문, 병합 뒤 로컬 동기화는 적용된다. 사용자 범위의 스킬을 수정할 때는 별도의 chezmoi 영속화 검증도 적용된다. 실제 파일만 고쳐서는 통과하지 못한다. chezmoi 원본을 먼저 고친 뒤 적용, 원본·실제 파일 일치, 자체 점검, 커밋과 푸시까지 확인해야 한다.

공통 검증 관문도 작업을 마무리할 때 반복해서 생긴 문제를 흡수하며 보강됐다. 이슈와 PR을 만들고도 담당자·마일스톤·레이블을 확인하지 않은 채 끝내거나, CI가 성공한 뒤 새 검토 의견을 다시 읽지 않거나, 원격 병합만 마친 채 로컬 develop을 뒤처진 상태로 남기는 일이 있었다. 지금은 GitHub의 실제 메타데이터 확인과 병합 뒤 로컬 동기화가 각각 별도 관문이다. PR 본문도 댓글이나 에이전트의 보고로 대신하지 않는다. 실제 본문을 다시 읽고 마지막 ## 제목이 ## DoD Status인지 확인한다.

코딩보다 먼저 내리는 결정이 훨씬 중요하다

개인적으로는 Superpowers의 요구사항 탐색, 명세, 계획 단계를 실제 코딩보다 훨씬 중요하게 본다. 코딩은 이미 선택한 방향을 파일과 테스트로 옮기는 일이다. 목표와 경계, API 계약, 실패 모드를 잘못 정했다면 코드를 빠르고 깔끔하게 작성할수록 엉뚱한 구현만 더 빨리 완성된다. 반대로 앞 단계가 충분히 구체적이면 구현은 검증 가능한 작은 작업의 연속으로 바뀐다.

그래서 Type A에서는 곧바로 편집기부터 열지 않는다.

단계	코딩 전에 확정하는 내용	이 단계가 없을 때 생기는 문제
요구사항 탐색	실제 사용자 문제, 범위와 제외 항목, 2~3개 접근법, 선택 이유, 아키텍처와 실패 처리	첫 아이디어를 요구사항으로 착각해 불필요한 기능이나 잘못된 경계를 구현한다
설계 명세	승인된 동작과 API 계약, 대안과 기각 이유, 호환성, 실패 모드, 인수 기준과 완료 조건	구현자마다 요구사항을 다르게 해석하고, 테스트가 무엇을 증명해야 하는지 정할 수 없다
구현 계획	명세와 작업의 대응 관계, 의존 순서, 정확한 파일, TDD 단계, 검증 명령, 문서·복구·위험 요소	구현 중에 설계를 다시 시작하고, 테스트·README·CI·Nightly·BOM 같은 후속 작업을 빠뜨린다
구현	승인된 명세와 계획에 따라 실패 테스트와 최소 구현을 반복한다	앞선 결정이 약하면 코드가 암묵적인 설계 문서가 되어 검토 비용이 커진다

요구사항 탐색은 아이디어를 많이 쏟아내는 회의가 아니다. 선택할 수 있는 접근법을 비교하고, YAGNI 기준으로 범위를 덜어 낸 뒤, 사용자가 설계 방향을 승인하는 과정이다. 그 결과를 설계 명세로 고정한다. 명세는 “대략 이런 기능”을 적은 메모가 아니라 구현과 테스트에서 같은 뜻으로 해석할 수 있는 계약이다.

구현 계획도 작업 목록 몇 줄로 끝나지 않는다. 명세의 모든 인수 기준이 어느 파일과 테스트, 명령에서 증명되는지 연결해야 한다. 앞선 작업이 뒤 작업에서 만들 산출물에 의존한다면 순서를 바로잡는다. 공개 동작이 바뀌면 언어별 README와 KDoc 작업을 배정하고, 새 모듈이면 CI, Nightly, 테스트 범위, BOM 등록까지 작업으로 고정한다. 구현 도중에 기억해 내기를 기대하지 않고, 빠뜨리기 쉬운 일을 코딩 전에 드러내는 것이다.

이 세 단계에 시간을 쓴다고 코드 작성량이 반드시 줄어드는 것은 아니다. 대신 잘못된 방향으로 코드를 만들었다가 버리는 비용, 검토에서 아키텍처를 다시 논의하는 비용, PR을 연 뒤 빠진 계약과 운영 항목을 찾는 비용이 줄어든다. 그래서 작업 속도는 코드 생성 속도가 아니라, 승인된 요구사항이 검증된 결과로 수렴하기까지 걸린 전체 시간으로 판단한다.

문서를 만들었다고 저절로 안전해지는 것도 아니다. 요구사항 탐색 결과와 명세, 계획은 서로 다른 관점에서 다시 읽어야 한다. 작성자는 자신이 의도한 맥락을 이미 알고 있어서 빠진 전제까지 무의식적으로 보완해 읽는다. 다관점 검토는 이런 암묵적인 보완을 걷어 내고 성능, 안정성, 보안, 운영, API, 호출자 관점의 빈틈을 찾는다.

2-R, 3-R, 6-R은 P0/P1=0까지 반복하는 7단계 검토다

Type A Full Feature에서 특히 중요한 지점은 2-R, 3-R, 6-R이다. 검토하는 산출물만 다를 뿐 세 단계 모두 같은 7단계 검토와 수렴 조건을 적용한다. 검토를 한 번 실행했다는 사실만으로는 통과할 수 없다. 최신 통합 결과가 P0=0, P1=0이 될 때까지 수정과 재검토를 반복한다.

검증 관문	검토 대상	다음 단계가 열리는 조건
2-R · 명세 검토	승인된 설계 명세, 조사 근거, 경계, 실패 모드, 호환성, 인수 기준	설계의 최신 통합 검토가 P0=0, P1=0
3-R · 계획 검토	명세와 작업의 대응 관계, 의존 순서, 테스트·문서·복구·저장소 위험 요소	계획의 최신 통합 검토가 P0=0, P1=0
6-R · PR 전 검토	현재 브랜치 변경 사항, 테스트와 진단 결과, 문서, 모듈별 변경과 PR 증거	현재 변경 사항의 최신 통합 검토가 P0=0, P1=0

2-R, 3-R, 6-R은 같은 7단계 검토 구조를 사용한다. 주 세션의 최신 통합 결과가 P0=0, P1=0일 때만 다음 검증 관문이 열린다.

여기서 7단계란 비슷한 코드 검토를 일곱 번 한다는 뜻이 아니다. 여섯 개의 독립 관점과 주 세션의 통합 검토로 구성된다. 독립 검토 관점은 성능, 안정성, 보안, 운영, 개발자와 API, 사용자와 호출자다.

앞의 여섯 관점은 서로 다른 실패를 찾는다. 마지막 통합 검토에서는 결과를 모아 중복과 충돌을 정리하고, 심각도를 P0/P1/P2/P3로 통일해 최종 관문을 판정한다. 이 단계는 별도의 일곱 번째 에이전트에게 넘기지 않는다. 현재 작업의 범위와 변경을 책임지는 주 세션이 최종 판단을 맡는다.

그림의 붉은 반복 경로는 이 수렴 조건을 나타낸다. 차단 문제를 수정하고 관련 검증을 다시 실행한 뒤, 전제가 바뀐 검토 관점을 다시 열어 주 세션에서 재통합한다. 검증 관문의 통과 기준은 검토를 한 번 실행했는지가 아니라, 최신 산출물이 차단 문제 없는 상태로 수렴했는지다.

P0/P1은 발견 목록에 적어 두고 나중에 처리할 할 일이 아니라, 즉시 진행을 막는 차단 문제다. 2-R에 남아 있으면 계획을 작성하지 않고, 3-R에 남아 있으면 구현하지 않으며, 6-R에 남아 있으면 PR을 만들지 않는다. 수정 뒤에는 전체 검토를 형식적으로 되풀이하지 않고 영향을 받은 관점과 통합 검토를 다시 실행한다. 수정이 여러 관점의 전제를 바꿨다면 관련 관점을 모두 다시 연다.

P2/P3도 조용히 버리지 않는다. 현재 범위에서 고치거나, 미루는 이유를 기록하거나, 후속 issue로 남긴다. 다만 검증 관문의 절대 종료 조건은 최신 검토표의 P0=0, P1=0이다. 이전 반복에서 차단 문제가 0이었다는 기록이나 이후의 CI 성공은 현재 산출물에 차단 문제가 없다는 증거가 될 수 없다.

세부 스킬마다 실패를 다루는 방식이 다르다

작업 경로 분류기가 작업 유형을 골랐다고 실행 방법까지 같아지는 것은 아니다.

같은 작업 경로 분류기에서 시작해도 유형마다 단계 순서, 강조하는 증거, 실패했을 때 되돌아가는 지점이 다르다.

Bug Fix

Type C는 결함 재현부터 시작한다. 근본 원인을 찾고 같은 문제가 다시 생기면 실패할 회귀 테스트를 만든 뒤, 가장 작은 수정을 적용한다. 재현하지 못했다면 추측으로 파일부터 고치지 않는다.

Fast Track

Type B는 변경 범위를 좁히고 대상별 테스트로 증명하는 데 집중한다. 영향 범위가 작다는 근거가 있어야 하며, 검토에서 P0/P1이 남아 있으면 다음 단계로 가지 않는다. 기능이 작다는 이유로 문서나 API 계약 검증을 생략하지 않는다.

Full Feature

Type A는 명세, 계획, 독립 검토, 구현, 검증, 코드 검토로 이어지는 절차가 더 길다. 새 모듈이면 settings.gradle.kts, 언어별 README, 저장소 내부 모듈 목록, CI, Nightly, 테스트 범위, BOM·카탈로그까지 등록 사슬을 확인한다. 파일 몇 개를 만들었다고 모듈 추가가 끝나는 것은 아니다. 특히 2-R, 3-R, 6-R은 각각 명세, 계획, 현재 변경 사항을 독립적으로 검토하며, 어느 단계든 P0/P1=0이 아니면 다음 단계가 열리지 않는다.

Maintenance

Type E는 실제 동작을 바꾸지 않는다. README, 블로그, AGENTS, 스킬, 설정 같은 운영 표면을 다룬다. 특히 Codex 지침은 실제 파일이 아니라 관리 원본부터 고쳐야 다음 chezmoi apply 뒤에도 변경이 남는다.

Publish와 Self Improve

Type P는 릴리스 체크리스트에 대상 버전, 현재 외부 버전, 배포 권한, 소비자 범위와 실행 보류 근거를 명시한다. 계획을 승인받았더라도 태그, 안정 버전 배포, 릴리스 생성처럼 되돌리기 어려운 동작은 별도 권한을 다시 확인한다.

Type F를 시작하려면 목표, 주요 지표, 벤치마크 명령, 새 기준값, 임계값, 종료 조건이 있어야 한다. 한 번에 하나의 가설만 시험하고 테스트, 봉인 파일 검증, 벤치마크 인수 기준을 모두 통과한 후보만 반영한다.

진행 상황도 DoD를 중심으로 보고한다

작업 중에는 “계속 진행 중”이라고만 말하기보다 현재 검증 관문과 증거를 짧게 보여 주는 편이 낫다.

Type E · BLOG-04 PASS
Action: 한국어 기본 경로를 작성했다.
Evidence: /ko/blog/... 경로와 소스 링크 확인.
Next: 한국어 자연스러움 검토와 사이트 빌드.

최종 보고에서는 적용한 체크리스트를 다시 세고, 누락된 ID를 숨기지 않는다.

Required checks: 18/18
N/A: 4
Blocked: 0
P0/P1: 0

PR을 만들었다면 담당자, 마일스톤과 레이블, CI, 검토 스레드를 GitHub의 실제 메타데이터에서 다시 읽는다. PR 본문의 마지막 ## 제목은 ## DoD Status여야 한다. 병합까지 승인받은 작업은 병합 뒤 실제 로컬 작업 사본을 상위 원격 브랜치와 맞춘 뒤에야 끝난다.

실제 작업 만족도는 어디까지 올라왔나

여기까지 오는 동안 시행착오가 많았다. 지침을 늘려도 일부 단계를 건너뛰고, 체크리스트를 만들고도 증거 없이 완료로 표시했으며, 실제 설정과 관리 원본이 어긋나 개선 내용이 사라지기도 했다. 이런 문제를 하나씩 작업 흐름과 검증 관문에 반영한 뒤에는 체감 결과가 크게 달라졌다.

개인적인 작업 만족도는 gpt-5.5의 high reasoning부터 약 90%였고, 현재 gpt-5.6-sol의 high reasoning은 약 98%다. 정해진 벤치마크 모음으로 측정한 성공률이 아니라, 실제 Bluetape 작업 결과를 검토하며 느낀 주관적인 만족도다. 모델 자체의 향상과 스킬 개선 효과를 따로 떼어 계산한 값도 아니다. 같은 저장소 규칙과 작업 흐름을 반복해서 적용했을 때, 결과를 되돌려 고치거나 누락된 절차를 다시 지시하는 빈도가 눈에 띄게 줄었다는 운영 경험을 숫자로 표현한 것이다.

특히 만족도가 높아진 이유는 첫 답변의 문장 품질보다 작업의 연속성이 좋아졌기 때문이다. 승인된 범위에서는 멈추지 않고 진행하고, 단계마다 필요한 증거를 남기며, 실패한 검증 관문을 뒤 단계의 성공으로 덮지 않는 경우가 늘었다. Full Feature에서는 2-R, 3-R, 6-R의 7단계 검토를 차단 문제가 없어질 때까지 반복하는 구조가 설계와 계획, 구현 사이의 누락을 크게 줄였다. 좋은 모델은 스킬을 더 잘 따르고, 잘 정리된 스킬은 좋은 모델이 저장소 안에서 일관된 결과를 내도록 돕는다.

직접 사용할 때 기억할 점

첫 요청에 $bluetape-workflow를 붙인다. 작업 경로 분류기가 제시한 분류와 첫 계획을 확인한다. 승인한 뒤에는 각 단계의 설명보다 증거가 실제 명령, 파일, URL, 테스트 결과로 채워지는지 본다.

$bluetape-workflow

이 실패를 재현하고 근본 원인을 고친 뒤 회귀 테스트로 증명해 줘.

$bluetape-workflow

새 모듈을 추가하되 언어별 README, CI, Nightly, BOM 등록까지 확인해 줘.

$bluetape-workflow

이 PR은 수정하지 말고 P0/P1 우선으로 검토해 줘.

작업 흐름을 쓴다고 긴 절차를 무조건 실행하는 것은 아니다. 작업을 정확히 분류하고 필요한 절차만 열되, 한 번 열린 검증 관문은 증거 없이 지나가지 않는다는 뜻이다. 이 기준이 있으면 작은 문서 수정은 가볍게 끝내고, 릴리스나 새 모듈처럼 위험한 작업은 필요한 만큼 엄격하게 다룰 수 있다.

시리즈 글

• 먼저 읽기: AI와 일하는 환경을 인프라로 만들기
• Bluetape Skills Part 1: 팀과 공유하고 설치하는 방법
• Bluetape Skills Part 2: bluetape-workflow로 작업을 시작하는 방법
• Bluetape Skills Part 3: 중단된 작업 흐름을 안전하게 복구하는 방법

저장소

• bluetape4k/bluetape-skills