01 배경
MSA 전환을 일주일 안에 마쳐야 일정대로 배포하고 새 구조에 대한 피드백도 받을 수 있었습니다. 기능이 이미 다 만들어져 있어 옮기며 고칠 곳이 많았고, 작업도 여러 갈래라 사람이 직접 하기엔 시간이 부족했습니다. 그래서 제가 쉬거나 자는 동안에도 작업이 이어지도록 코딩 에이전트 루프를 만들기로 했습니다. 다만 한 세션에서 오래 작업하면 맥락이 요약되면서 앞서 정한 계획을 놓치는 문제가 있었습니다.
전환이 늦어지면 배포와 피드백 일정이 함께 밀리고, 계획을 벗어난 코드를 고치는 재작업 비용도 늘어날 것이라고 판단했습니다. 그래서 같은 인원으로 일정을 지키는 것을 목표로 잡았습니다.
02 루프 설계와 판단 과정
역할을 나눈 에이전트 루프 구성
문제 상황 한 세션에 모든 작업을 맡기면 맥락이 요약되며 계획이 흐려졌습니다. 그래서 계획을 지키지 않은 코드나 행위가 발생해, 누락된 커밋이 생기거나, 계획과 다른 코드를 생성하는 경우가 있었습니다. 이를 수정하는데 또 비용이 들기 때문에, 이러한 낭비를 줄이고자 했습니다.
시도와 결과 작업 계획과 기준을 문서로 고정하고, 구현, 검토, 통합 리뷰로 역할을 나눴습니다. 브랜치마다 작업 공간을 따로 두고 에이전트 2개를 병렬로 돌렸고, 작업 간 의존성과 우선순위는 조정 에이전트가 판단하게 했습니다.
판단 세션이 바뀌어도 같은 문서를 기준으로 이어갈 수 있어, 긴 작업을 여러 에이전트에 나눠도 방향이 흩어지지 않았습니다.
PR 진행 기간: 8/9 → 8/13
문제 상황 작업들이 얽혀 있어, 한꺼번에 열면 충돌과 재작업이 생길 수 있었습니다.
시도와 결과 8/9에 #156–#159를 만들어 8/10에 병합하고, 8/11에 #167, #169, #170 등을 병렬로 진행한 뒤, 8/13 #175에서 통합 결함을 고쳤습니다. 5일 동안 PR 16개를 병합했습니다.
판단 선행 작업이 병합된 뒤에 다음 묶음을 열어, 병렬로 진행하면서도 충돌을 줄였습니다.
병합 전 리뷰와 병합 판단
문제 상황 에이전트가 만든 변경을 그대로 병합하면 결함까지 함께 배포될 수 있었습니다.
시도와 결과 리뷰에서 나온 필수 수정 13건을 반영하고 회귀를 확인한 뒤에만 병합했습니다. 문서를 복구한 뒤 이전 본문이 반환되던 결함도 병합 전에 고쳤습니다.
판단 코드를 직접 쓰지 않는 대신, 통과 기준을 정하고 그 기준으로 병합을 판단하는 것을 제 역할로 삼았습니다.
03 개선한 처리 흐름
flowchart TD P[작업 계획, 기준 문서 작성, 본인] --> C[조정 에이전트, 의존성과 우선순위 판단] C --> W1[브랜치 작업 공간, 구현 에이전트 + 검토 에이전트] C --> W2[다른 브랜치 작업 공간, 병렬 실행] W1 --> R[PR 생성, 통합 리뷰] W2 --> R R --> F[필수 수정 반영, 회귀 확인] F --> J[병합 판단, 본인]
계획과 기준은 제가 정하고, 구현과 검토는 역할을 나눈 에이전트가 브랜치별로 병렬 수행한 구조입니다.
Mermaid 원문 보기
flowchart TD P[작업 계획, 기준 문서 작성, 본인] --> C[조정 에이전트, 의존성과 우선순위 판단] C --> W1[브랜치 작업 공간, 구현 에이전트 + 검토 에이전트] C --> W2[다른 브랜치 작업 공간, 병렬 실행] W1 --> R[PR 생성, 통합 리뷰] W2 --> R R --> F[필수 수정 반영, 회귀 확인] F --> J[병합 판단, 본인]
04 결과와 배운 점
5일 동안 PR 16개 병합, 병합 전 필수 수정 13건 반영
8월 9일부터 13일까지 5일 동안 12시간씩 루프를 돌려 PR 16개를 병합했습니다. 병합 전 리뷰에서 나온 필수 수정 13건을 반영하고 회귀를 확인했습니다. 그중에는 문서를 복구한 뒤 이전 본문이 반환되던 결함도 있었습니다. 구현은 코딩 에이전트가 맡았고, 저는 루프 구성, 작업 계획과 기준 문서 작성, 결과 검토와 병합 판단을 맡았습니다.
코드를 직접 쓰지 않고 기준 문서와 리뷰 결과로 병합을 판단했습니다. 그래서 리뷰 기준에 없는 결함은 놓칠 수 있고, 기준 문서를 계속 보완하는 것이 과제로 남았습니다.