병렬 개발 계획 스킬 — 스킬 프로젝트 소개

에이전트 수보다 먼저 정한 것은 작업 경계였습니다

병렬 개발 계획 스킬을 만들면서 제가 기준으로 삼은 것은 작업을 많이 나누는 일이 아니었습니다. 하나의 작업을 빼도 목표를 달성할 수 있다면 그 작업은 독립된 담당을 만들 이유가 없습니다. 서로 다른 파일을 수정하더라도 같은 상태 모델이나 API를 함께 결정해야 한다면 동시에 진행하기 어렵습니다.

그래서 먼저 최소한의 직렬 구현 경로를 잡고, 필요한 책임이 무엇인지 정하도록 했습니다. 그다음 각 책임이 다른 작업의 설계 결과를 기다리지 않고 구현될 수 있는지 봅니다. 공통 계약 하나를 먼저 정해야 독립성이 생긴다면 그 계약을 직렬로 확정한 뒤 나머지를 나눕니다.

동시 실행이 가능한 것과 동시 실행이 유리한 것도 구분했습니다. 분담, 작업 공간, 통합, 재수정에 드는 비용이 있기 때문입니다. 이득이 작거나 불분명하면 직렬 진행을 권장하도록 했습니다. 병렬 요청을 받았다는 이유만으로 반드시 병렬 계획 파일을 만들지는 않습니다.

작은 저장소에서 두 작업을 끝까지 연결해 보기

2026년 8월 13일에는 임시 Python 저장소에서 API와 Web 두 작업으로 제한적인 파일럿을 진행했습니다. 제품 저장소를 바꾸는 대신 작은 예제에서 경로 격리와 증거 기록, 통합 절차가 이어지는지 확인했습니다.

두 작업은 같은 Git 기준점에서 별도의 작업 공간으로 시작했습니다. 각 담당은 자신의 경로만 바꾸고 독립 테스트를 수행했습니다. 실제 변경 범위가 계획의 쓰기 경로 안에 있는지 확인한 뒤, 결과를 실행 기록에 남겼습니다. 통합에서는 두 변경을 순서대로 합치고 전체 테스트 두 개를 확인했습니다.

마지막에는 실행 기록을 Git 상태와 대조해 완료 판정을 확인했습니다. 의미적으로 서로 얽힌 입력을 넣으면 직렬 진행을 권장하는 조건도 별도로 살폈습니다. 이 파일럿은 작은 smoke 검수였습니다. 작업이 빨라졌다는 비교 측정이 아니라, 서로 나눈 작업이 같은 완료 기준으로 돌아오는지를 확인한 경험입니다.

담당이 작성한 파일 목록만 믿지 않기

병렬 작업에서 완료 보고는 필요하지만 그것만으로 변경 범위를 판단하지 않도록 했습니다. 담당자가 적은 목록에는 삭제하거나 이름을 바꾼 파일, 새로 만든 파일이 빠질 수 있습니다. 저는 실제 Git 변경에서 추적 파일과 미추적 파일, 삭제, 이름 변경 전후 경로를 확인하는 방식으로 범위 검사를 만들었습니다.

검사 결과도 한 가지 성공 표시로 뭉치지 않았습니다. 허용 범위 안의 변경, 변경 없음, 범위 밖 수정, 판단 근거 부족을 구분합니다. 변경이 없는데 구현을 마쳤다고 보고하면 다음 단계에서 문제가 드러납니다. 반대로 통합 담당이 코드를 추가로 고칠 필요 없이 변경을 합친 경우에는 그 역할에서 변경 없음이 자연스러울 수 있습니다.

파일럿에서도 통합 단계의 코드 수정 없는 상태를 따로 다뤘습니다. 작업마다 같은 파일 수나 같은 형태의 결과를 강제하는 대신, 각 역할이 맡은 목표와 확인 조건으로 판단하도록 한 것입니다. 쓰기 경로는 한 담당이 소유하되 읽어야 할 맥락은 함께 공유할 수 있게 했습니다.

계획과 실행 기록의 역할을 나눴습니다

계획에는 목적, 범위, 의존성, 테스트와 공유 계약을 남깁니다. 내용을 JSON에 담고, 같은 데이터로 사람이 읽을 문서를 생성했습니다. 문서를 따로 손으로 바꿔 JSON과 다른 계획이 되지 않도록 한 구성입니다.

실행 사실은 계획의 체크 표시 대신 별도의 실행 기록에 남깁니다. 어떤 기준점에서 시작했고 어떤 변경과 검사 결과를 얻었는지 확인할 수 있어야 하기 때문입니다. 테스트 명령과 종료 코드가 없는 상태를 통과했다고 추정하지 않습니다.

작업을 다시 이어 갈 때는 기록의 계획 해시와 Git 커밋 존재, 범위와 검사 상태를 대조합니다. 문서에 완료라고 적혀 있어도 실제 변경을 찾을 수 없거나 근거가 어긋나면 재개를 막고 확인합니다. 계획을 세운 사실과 구현을 끝낸 사실을 다른 자료로 다루는 선택입니다.

공통 작업이 있으면 출발점도 바꿔야 합니다

공유 계약을 먼저 확정하는 경우, 후속 담당들이 최초 기준점에서 그대로 시작하면 이미 정한 계약을 포함하지 못합니다. 저는 공통 작업이 끝나고 검증된 변경을 새 출발점으로 사용하도록 했습니다. 각 담당이 같은 전제를 가지고 시작해야 독립 작업의 의미가 유지됩니다.

통합은 각 작업의 범위와 독립 검사가 끝난 뒤 직렬로 진행합니다. 결함이 발견되면 해당 담당의 범위로 되돌리고 같은 검사를 다시 적용합니다. 여러 담당이 공유 교훈 문서를 동시에 수정하는 것도 피하도록 했습니다. 담당은 발생 조건과 변경, 검사 근거를 전달하고 최종 조율 담당이 합쳐 정리합니다.

위험이 큰 작업일수록 다른 맥락의 검토와 전체 회귀 검사를 추가합니다. 담당의 자기평가만으로 완료를 결정하지 않는 이유도 같습니다. 병렬로 실행한 숫자가 아니라 최종 결과가 목표와 경계를 충족했는지 확인해야 합니다.

일반 계획과 병렬 계획의 진입점을 분리하기

8월 20일에는 일반적인 “개발 계획” 요청과 명시적인 병렬 요청의 분기를 더 분명히 했습니다. 일반 계획은 별도 개발 계획 스킬로, 병렬 가능성 판단이나 병렬 계획 요청은 이 스킬의 사전 판단으로 이어지도록 했습니다. 요청 문장이 넓다는 이유로 실행 방식까지 확대하지 않도록 한 수정입니다.

두 스킬은 별도 패키지이므로 병렬 계획 스킬만 설치했다고 일반 계획 기능까지 있다고 설명하지 않게 했습니다. 교훈 도구가 없다면 없는 상태를 남기고, 필요한 설치 위치와 범위를 확인합니다. 준비가 안 된 환경에서 기능이 있다고 가장하면 실행의 출발점부터 흔들릴 수 있습니다.

작은 파일럿 뒤에 남긴 기준은 분명합니다. 필요한 작업만 나누고, 공유 계약은 먼저 정하며, 실제 변경과 검사 결과를 모아 직렬로 통합합니다. 이 조건을 만족하지 않으면 에이전트를 더 늘리기보다 책임 경계를 다시 정하는 것이 다음 개발의 출발점입니다.