AI 개발 하네스

AI로 일하는 순서

코드를 짜기 전에 지형을 훑고, 계획을 문서로 남기고, 구현한 뒤에는 그 코드를 쓰지 않은 컨텍스트가 리뷰합니다. 각 단계는 스킬로 고정돼 있고 단계마다 산출물이 파일로 남습니다. 사내 4개 저장소와 오픈소스 2개에서 이 방식으로 일하고 있습니다.

계획

기반

무엇을 건드릴지 정하고, 위험하면 승인을 받는다

처리

고정된 결정 규칙으로 코드를 쓴다

확인

코드를 쓰지 않은 컨텍스트가 리뷰한다

축 스킬 8종

단계	하는 일	남는 산출물	사람 개입
탐색explore-workflow	영향 범위와 기존 패턴, 최근 이력을 모아 지도로 만든다	.explore-notes/	자동 진행
계획plan-workflow · spec-workflow-global	범위·접근·완료 기준을 정하고 위험도를 매긴다	.plan-drafts/ (상세 + 공유용 요약)	위험도 HIGH·CRITICAL만 사람 승인
작업coding-conventions-js · -swift	테스트 여부·파일 위치·검증 명령을 같은 기준으로 판단해 구현한다	코드 + 완료 보고	자동 진행
검증review-mr (GitHub은 review-pr 어댑터)	diff를 확신도로 걸러 초안을 만든다	.glb-reviews/ · .gh-reviews/	게시 전 사람 승인
반영apply-review	받은 코멘트를 하나씩 판정해 맞는 것만 고친다	코드 + 판정 근거	자동 진행

코드를 작성한 컨텍스트가 그대로 리뷰하면 작성할 때의 가정이 판정에 섞여 대부분 통과시킵니다. 그래서 리뷰는 diff와 SPEC, 계획 초안만 입력으로 받는 새 에이전트가 맡습니다.

모든 계획에 승인을 걸면 내용을 안 보고 승인하기 시작합니다. 레이어를 교차하거나 되돌리기 어려운 변경처럼 신호가 잡힌 계획만 사람에게 올리고, 나머지는 그대로 진행합니다.

발견한 것을 다 올리면 리뷰가 노이즈가 되고, 노이즈가 쌓이면 리뷰 자체를 안 읽게 됩니다. 기준 미만은 초안 단계에서 떨어뜨립니다.

세션이 끊기면 그때까지의 맥락이 통째로 사라집니다. 탐색 노트·계획·리뷰를 저장소 안 고정 경로에 같은 이름으로 남겨서, 다음 세션이 그 파일부터 읽고 이어갑니다.

저장소 6곳 집계

마지막 항목이 나머지 셋보다 중요하다고 봅니다. 스킬을 만든 것보다, 쓰다 걸린 마찰을 기록해 두고 스킬을 고쳐 온 기록이 남아 있다는 쪽이 확인 가능한 사실이라서 그렇습니다.

하네스 스킬 22종 중 축을 이루는 8종

explore-workflow직접 제작탐색 깊이와 fan-out 판정을 담당
plan-workflow직접 제작위험도 분류와 조건부 승인 게이트
coding-conventions-js직접 제작팀 저장소의 프론트 컨벤션 스킬을 만들었다. 개인판은 vue·react 판을 프레임워크 무관으로 통합한 것
apply-review직접 제작받은 코멘트를 판정해 맞는 것만 반영
review-mr사내 원작 기반사내 동료가 만든 484줄 스킬에서 시작해 2,548줄로
spec-workflow-global사내 원작 기반Vue 전용이던 것을 프레임워크 무관으로 재설계
humanizer오픈소스 적응blader/humanizer (MIT) 한국어 적응판
task-observer오픈소스 적응Eoghan Henn (CC BY 4.0) 한국어 적응판

오픈소스를 옮긴 두 종은 원저작자와 라이선스를 스킬 문서에 적고, 별도 동기화 파일로 upstream 변경을 추적합니다. 사내 원작에서 출발한 두 종은 원본이 사내 저장소에 있어 링크를 걸 수 없습니다.