머지된 코드와 끝난 작업을 따로 봅니다
PR은 머지됐는데 작업 보드에는 여전히 검토 중으로 남아 있습니다. 코드는 들어갔으니 완료로 옮겨도 될 것 같지만, 머지 기록만으로는 요청한 일이 모두 끝났는지 알 수 없습니다.
마블로는 코드 반영과 작업 완료를 구분합니다. 머지는 코드가 합쳐졌다는 사실을 남깁니다. 요구사항이 충족됐다는 판단에는 합친 결과를 검증한 증거와 남은 작업에 대한 확인이 더 필요합니다.
완료로 넘기기 전에는 머지 후 결과를 다시 검증하고 서명된 기록을 남깁니다. 후속 작업이 남아 있는 티켓은 머지됐어도 검토 상태로 둡니다. 다만 이 게이트가 보수적으로 멈추면서, 실제 할 일이 없어도 사람이 다시 확인해야 했던 경우가 있습니다.
합친 결과를 다시 검증합니다
개별 변경이 검증을 통과했어도, 다른 변경과 합쳐진 결과가 요구사항을 충족하는지는 다시 살펴야 합니다. 머지 전 검증과 머지 후 결과 확인은 서로 다른 시점의 판단입니다.
머지 트레인을 다룬 6편에서는 검증된 여러 PR을 묶어 CI를 실행하고 반영하는 흐름을 소개했습니다. 그 반영이 끝나면, 합친 결과에 대한 검증과 완료 판단이 이어집니다.
마블로는 이 검증에 대한 서명된 기록을 남긴 뒤에야 완료로 넘기는 게이트를 둡니다. 코드가 들어갔다는 기록과 결과를 확인했다는 기록을 함께 살피는 원칙입니다.
후속 작업이 남으면 검토 상태를 유지합니다
코드 반영 뒤에도 티켓에서 요구한 확인이나 후속 작업이 남아 있다면, 그 티켓은 검토 상태인 REVIEW에 머뭅니다. 완료 상태인 DONE으로 옮기려면 남은 요구사항까지 확인해야 합니다.
| 확인한 사실 | 완료 판단에서의 의미 |
|---|---|
| PR이 머지됨 | 코드가 반영됐습니다. 요구사항 충족 여부는 더 확인해야 합니다. |
| 합친 결과를 검증하고 서명된 기록을 남김 | 반영된 결과에 대한 검증 근거가 마련됐습니다. 남은 작업도 확인합니다. |
| 후속 작업이 남아 있음 | 머지 여부와 관계없이 검토 상태를 유지합니다. |
위험도 기반 독립 테스터를 다룬 8편처럼 중요한 변경에는 별도 검증 주체가 붙습니다. 변경의 위험도에 맞춰 검증을 나누더라도, 완료 여부는 요구사항과 결과를 보고 판단해야 합니다.
한계: 할 일이 없어도 완료가 막힐 수 있습니다
이 게이트는 보수적입니다. 실제로는 더 할 일이 없는데도 이전 상태가 남아 있어 완료로 넘어가지 못하는 경우를 겪었습니다. 이 문제는 아직 고치는 중입니다. 검토 상태에 남아 있다는 사실만으로 구현이 덜 됐다고 단정할 수도 없습니다.
안전 쪽으로 멈추는 선택에는 비용이 있습니다. 사람이 남은 일이 있는지, 이미 끝난 일의 상태가 뒤따라오지 못한 것인지 다시 확인해야 합니다. 완료 표시를 보류하는 동안 보드를 정리하고 판단하는 부담도 늘어납니다.
코드 반영과 완료를 나누는 원칙을 지키면서, 오래된 상태 때문에 불필요하게 멈추는 경우를 줄이는 것이 남은 과제입니다. 지금의 게이트가 그 구분을 항상 정확하게 한다고 말할 수는 없습니다.
보드를 볼 때 함께 확인할 것
머지된 티켓이 검토 중이라면, 합친 결과의 검증이 끝났는지와 요구사항에 남은 일이 있는지를 함께 살펴보세요. 검증이나 후속 작업이 남은 경우와 이전 상태가 남은 경우를 구분해야 다음 행동을 정할 수 있습니다.
1편의 클로즈드 루프는 배정·검증·리뷰·머지를 연결했습니다. 그 흐름의 끝에서 완료라는 표시는 결과를 확인했다는 뜻이어야 합니다. 보드를 빨리 비우는 것과 맡긴 일이 끝났음을 확인하는 것 사이에서, 저희는 이 확인에 드는 비용도 함께 살피고 있습니다.
같은 시리즈
마치며
하이프마크 빌더 커뮤니티는 AI 에이전트를 만들고 운영하며 얻은 경험과 참고할 자료를 꾸준히 공유하려고 합니다. 빌더 여러분께 도움이 될 좋은 자료들을 계속 모아 나누겠습니다.