명세 스킬과 구현 스킬은 반대로 자랐다

화면 하나를 옮기는 일을 명세 스킬과 구현 스킬로 갈라 놓고도, 그 둘을 넉 달 반 동안 열여덟 번 고쳤다.

두 스킬은 반대로 자랐다. 명세 쪽은 갈수록 짧아졌고 구현 쪽은 두 배로 불었다. 열여덟 번 동안 무엇을 고쳤는지 종류별로 적어 둔다.

앱 이름을 지우는 것으로 시작했다

2월 상순에 만든 첫 스킬은 앱 하나만 보고 썼다. 앱 이름을 스킬 이름에도 경로에도 박아 놨으니, 다른 앱에 쓰려면 복사부터 해야 했다.

2월 하순에 그 이름을 뗐다. 워크스페이스명은 입력값으로 받고, 레거시 경로는 스킬이 알아서 찾게 했다.

먼저 기본값을 본다
없으면 디렉터리를 훑는다
후보가 둘이면 묻는다

확인 게이트도 이때 처음 넣었다. 어느 화면을 옮기라는 건지 프롬프트에서 못 읽으면, 분석에 손대지 않고 한 줄로 되묻는다. 스킬이 떴다고 일할 준비가 된 건 아니다.

두 스킬은 반대 방향으로 자랐다

숫자를 어디서 셌는지 먼저 밝힌다. “입구”는 스킬이 뜰 때마다 무조건 읽는 SKILL.md 한 장이고, 줄 수는 프론트매터까지 넣어 wc -l로 셌다.

	명세 스킬	구현 스킬
탄생	입구 238줄 · 전체 458줄 · 5파일	입구 160줄 · 전체 280줄 · 5파일
입구 최대	281줄	350줄 (현재)
현재	입구 180줄 · 전체 751줄 · 8파일	입구 350줄 · 전체 821줄 · 9파일
고친 횟수	7	15

명세 쪽은 3월 중순에 입구를 281줄에서 146줄로 반 토막 냈다. 그런데 같은 커밋에서 전체 줄 수는 608에서 694로 늘었다.

규칙을 버린 게 아니다. 매번 읽는 자리에서 필요할 때만 읽는 자리로 옮겼다.

구현 쪽은 이 옮기기를 끝까지 못 했고, 그래서 입구가 두 배로 늘었다.

서술로 적으면 안 하고, 절차로 적으면 한다

“팀 모드로 병렬 분석한다.” 이렇게 한 줄 적어 놓으니 리더가 혼자 다 해버리는 걸 못 막았다. 어떤 세션은 팀을 띄웠고 어떤 세션은 그냥 혼자 끝냈다.

3월 말에 그 한 줄을 절차로 바꿨다.

팀을 만든다
팀메이트를 한꺼번에 띄운다
전원이 끝날 때까지 기다린다
팀을 종료한다

리더가 혼자 처리하는 건 아예 금지했다. 밖을 가리키는 문서 링크도 같이 지웠다. 링크만 걸어 두면 안 읽는다. 절차로 적어야 따라간다.

구현 쪽에서는 거꾸로 하나를 뺐다. 준비 단계를 맡던 서브에이전트를 없애고 리더가 직접 하게 했다. 이 하나가 순서대로만 돌아서, 뒤에 붙은 병렬을 앞에서 막고 있었다.

막는 것이 설명하는 것보다 잘 먹혔다

게이트는 “이렇게 하라”고 설명하지 않는다. “이걸 먼저 안 하면 다음으로 못 간다”고 막는다. 막아 놓으면 먹혔다.

게이트	그 앞에서 무너진 것
기존 API 조사	이미 있는 엔드포인트를 다시 만들고, 없는 컬럼명을 지어냈다
컨벤션 선로드	컨벤션을 안 읽고 코드를 썼다
기존 컴포넌트 조사	API에서 겪은 중복을 컴포넌트에서 또 겪었다
리뷰 진행 여부 확인	비싸고 워킹트리를 고치는 작업을 묻지 않고 돌렸다

6월에는 컴포넌트 조사 범위를 넓혔다. 레거시를 전수로 훑어서 어느 화면이 그 팝업을 쓰는지, 그 팝업이 또 팝업을 여는지까지 보게 했다.

명세는 후보만 내고 확정은 구현이 한다. 5월 말에 이렇게 경계를 그었다. 공통으로 쓸 컴포넌트를 찾아내는 건 명세가 하고, 그걸 어느 레이어에 넣을지는 구현이 정한다.

레이어는 레거시를 봐서는 못 정한다. 지금 코드베이스에 뭐가 이미 있는지를 봐야 정한다. 이때는 입구를 한 줄도 건드리지 않고 참조 문서만 고쳤다.

반복 횟수보다 종료 조건이 문제였다

자동 보완 루프의 상한을 3회에서 10회로 올렸다. 하지만 정작 손봐야 했던 건 상한이 아니라 종료 조건이었다.

원래는 “갭이 0이면 종료”였다. 이걸 “갭이 0이고 직전 반복에서 고친 게 없을 때만 종료”로 바꿨다.

그전까지는 명세를 고친 바로 그 반복에서 갭 0을 선언하고 끝냈다. 방금 고친 걸 다시 안 보고 넘어간 셈이다.

제목에 [실험]을 붙인 건 이 일감이 처음이다. 열여덟 번 중 일곱 번째였다. 그 앞의 여섯 번은 전부 “작업”으로 올려서, 실패한 시도가 하나도 안 남았다.

자작 에이전트를 버리는 데 넉 달이 걸렸다

리뷰 단계 하나만 여섯 번을 갈아탔다. 한 단계를 이만큼 붙들고 고친 건 여기뿐이다.

무엇으로	왜
직접 만든 정리 에이전트	구현 직후 컨벤션·품질을 보게 함
기성 명령 직접 호출	자작 프롬프트보다 나았다
이름이 바뀐 기성 명령	도구 쪽에서 명령 이름이 바뀌었다
한 번의 호출로 통합	두 명령의 역할이 겹쳤다
진행 여부를 묻는 게이트	비용이 크고 워킹트리를 고친다
값싼 모델을 지정한 서브에이전트	리뷰에 큰 모델이 필요 없었다

7월에는 손으로 쓴 UI 컴포넌트 가이드도 공식 스킬에 넘겼다. 같은 길을 또 걸었다. 여기서 배운 게 둘이다.

기성이 생기면 자작은 짐이 된다
리더는 자기 모델을 바꿀 수 없다. 값싼 모델로 돌리려면 그 일을 서브에이전트로 떼어내야 한다

팀메이트가 조용히 죽는다

멈춘 팀메이트는 완료도 에러도 보내지 않는다. 리더는 그걸 모르고 영영 기다린다. 대개 띄운 직후에 아무것도 시작하지 못한 채 죽었다.

6월 중순에 심박 감시를 붙였다. 진척이 없고 핑에도 답이 없으면 죽었다고 본다. 그러면 같은 범위로 새로 띄우고, 두 번까지만 그렇게 하고 그다음엔 사람을 부른다.

언제 죽었는지에 따라 대응도 갈랐다. 띄운 직후면 바로 교체하고, 일하다 멈춘 거면 한 틱 기다려 본다.

정리 순서도 정해 뒀다. 감시를 먼저 끄고 팀을 내려야 한다. 거꾸로 하면 잘 끝난 팀메이트를 죽은 것으로 본다.

마지막 변경은 자율성을 되돌린 것이었다

7월 초에는 구현을 끝내고 리뷰로 넘어가기 전에 사람에게 묻는 단계를 넣었다. 그대로 갈지, 컨벤션 리뷰만 할지, 아예 건너뛸지.

리뷰는 비싸고 워킹트리를 직접 고친다. 그래서 리더가 알아서 진행하지 않게 했다. 어느 쪽을 골라도 산출물은 넘기고, 건너뛴 단계는 요약에 적어 둔다.

넉 달 반 내내 “더 자동으로”만 밀었다. 그런데 마지막 두 번은 결정을 사람에게 돌려주고, 모델을 값싼 쪽으로 내린 것이었다.

아쉬운 것

문서가 스킬을 못 따라갔다. 3월 하순에 두 스킬의 설계를 위키 문서로 옮겼다. 구현 스킬 문서는 7월 초 변경까지 따라왔지만, 명세 스킬 문서는 옮긴 날에 멈췄다. 그 뒤 두 번의 변경이 문서에 없다. 스킬이 곧 문서라고 여겼으니, 위키를 다시 열 이유를 만들지 못했다.

같은 것을 두 번 확인한다. 명세가 공통 컴포넌트 후보를 찾고, 구현이 레거시를 다시 전수로 훑어 확정한다. 경계는 맞게 그었는데, 같은 조회를 파이프라인에서 두 번 돈다. 명세가 근거를 넘겨주기만 하면 될 일이었다.

입구를 줄인 건 한 번뿐이다. 명세 쪽에서 반 토막이 통했는데 구현 쪽엔 끝까지 못 옮겼다. 게이트를 붙이는 건 쉽고 참조로 내리는 건 어렵다. 그걸 알면서도 열다섯 번 중 한 번도 안 했다.