잔존률은 높은데, 절반이 뒤집혔다 — 스펙 번복률을 재보기까지

1편("기획서와 코드 사이를 잇고, AI가 얼마나 썼는지 숫자로 답하기까지")의 후속입니다.

번복률의 정의와 분류 기준은 팀에서 잡은 것을 따랐다. 이 글은 그 기준으로 실제 커밋을 분류해 숫자를 낸 기록이다.

1편 마지막에 스스로에게 숙제를 하나 남겼다. 우리 워크플로우는 상위 문서가 바뀐 건 감지하지만, 그 변경이 미정이던 걸 채운 보강인지 이미 합의한 결정을 뒤집은 번복인지는 구분하지 못한다고. 다음 사이클에는 기준선을 남기고 변경을 두 종류로 분류하겠다고 적었다.

이번에 그 숙제를 실제로 해봤다. 결과를 먼저 말하면, 예상보다 불편한 숫자가 나왔다.

잔존률만 보면 "기획이 안정적이었다"로 읽힌다

앞 글에서 신규 결제·계약 도메인의 두 에픽에서 AI 잔존률을 처음 측정했다고 했다. 계약 관리 에픽의 코드 잔존률은 99.7%, 정산 에픽의 PRD·디자인 문서 잔존률은 각각 86.4%·89.4%였다.

이 숫자만 늘어놓으면 자연스럽게 이런 이야기가 된다. "AI가 만든 초안이 사람의 큰 수정 없이 거의 그대로 최종 산출물에 남았다." 틀린 말은 아니다. 하지만 이 문장에는 함정이 있다. 잔존률은 '최종본에 AI 라인이 얼마나 남았나'를 볼 뿐, 그 최종본에 도달하기까지 결정이 몇 번 뒤집혔는지는 전혀 보지 않는다.

같은 문서가 여러 번 갈아엎어진 끝에 마지막 판본만 AI가 썼어도 잔존률은 높게 나온다. 잔존률이 높다는 건 "AI 산출물이 채택됐다"는 뜻이지, "기획이 처음부터 안정적이었다"는 뜻이 아니다. 두 가지는 별개인데, 잔존률 하나만 보면 뒤엣것까지 성립한 것처럼 착시가 생긴다.

그래서 번복률을 직접 셌다

방법은 단순하게 잡았다. 각 문서의 초안 커밋을 기준선으로 두고, 그 이후의 모든 문서 변경 커밋을 세 가지로 분류했다.

보강 — 이전 판본의 방향을 유지하면서 상세·예외·필드를 채운 변경
번복 — 이전 판본에서 정해둔 요구·정책·설계·스펙 값을 바꾸거나 철회하거나 되돌린 변경
노이즈 — 파일 이동, 오타, 형식 정리처럼 결정과 무관한 변경 (분모에서 제외)

번복률 = 번복 / (보강 + 번복) 으로 정의했다.

기준선을 무엇으로 잡느냐가 이 수치를 좌우한다. 여기서는 각 문서의 초안 커밋을 기준선으로 삼았다. 리뷰를 거쳐 '구현 기준'으로 확정된 시점을 자동으로 표시한 기록이 없었기 때문이다. 그래서 이 글의 번복은 엄밀한 의미의 '합의 번복'이라기보다, 초안 이후 문서가 이전 방향을 되돌린 변경에 가깝다. 초안 단계의 탐색이나 리뷰 반영 일부도 포함됐을 수 있으므로 이 수치는 상한에 가깝다. 절대값보다 두 에픽을 같은 기준으로 비교했을 때의 차이와, 번복이 몰린 지점을 더 중요하게 봤다.

한 가지 배운 게 있다. 커밋 메시지만 보고 분류하면 안 된다는 것. "스펙 sync", "반영" 같은 무난한 제목을 달고 있어도, 실제 diff를 열어보면 상태 값을 통째로 갈아치운 번복인 경우가 많았다. 메시지 기반 예비 집계와 diff를 일일이 읽은 확정 집계 사이에서 번복률이 눈에 띄게 올라갔다. 번복은 자주 '동기화'라는 이름으로 위장한다.

결과: 46.5% 와 61.0%

diff를 정독해 확정한 수치는 이렇다.

지표	계약 관리	정산
AI 잔존률	코드 99.7%	PRD 86.4% / 디자인 89.4%
스펙 번복률	46.5%	61.0%

계약 관리는 초안 이후 문서 변경의 절반 가까이가, 정산은 절반을 넘는 변경이 이전 방향을 되돌린 것이었다.

단, 잔존률은 에픽마다 측정한 산출물 범위가 다르다. 계약 관리는 코드 기준, 정산은 PRD·디자인 문서 기준이다. 번복률은 두 에픽 모두 문서 변경 커밋을 기준으로 계산했다. 즉 잔존률과 번복률은 같은 대상을 잰 지표가 아니므로, 한 표에 있다고 해서 직접 나눠 보거나 빼서 볼 수 있는 값은 아니다 — 각각 다른 질문에 대한 답으로 읽어야 한다.

정의를 분명히 해둘 필요가 있다. 1편에서 "개발 이후 스펙이 확정·변경된 이슈가 5건 중 1건을 넘었다"고 했는데, 그건 이슈 단위로, 개발 이후에 한정한 수치였다. 이번 번복률은 문서 커밋 단위로, 초안부터 배포까지 전 구간을 본 것이다. 분모가 다르므로 두 숫자를 같은 선상에서 비교하면 안 된다. 앞엣것은 "개발까지 끝났는데도 스펙이 흔들린 비율", 이번 것은 "기획하는 내내 결정이 얼마나 되돌려졌는지"에 가깝다.

잔존률과 번복률을 겹쳐 보면

두 지표를 같이 놓으면 하나로는 안 보이던 그림이 나온다.

잔존률 높음 + 번복률 낮음 — AI 산출물이 채택됐고, 기획도 안정적이었다. 이상적.
잔존률 높음 + 번복률 높음 — AI가 쓴 마지막 판본은 그대로 남았지만, 거기 도달하기까지 결정이 계속 뒤집혔다. 이번 두 에픽이 여기 있다.
잔존률 낮음 — 리뷰와 사람 개입이 많았다는 협업 양상 (1편에서 다룬 약 58% 사례).

잔존률만 봤다면 이번 두 에픽은 "AI를 잘 활용한 성공 사례"로만 기록됐을 것이다. 번복률을 겹쳐야 "산출물은 잘 채택됐지만 무엇을 만들지가 오래 흔들렸다"는, 더 정직한 문장이 나온다. 번복률은 잔존률의 착시를 깨는 짝 지표다.

번복의 진앙은 대부분 '상태 모델'이었다

번복으로 분류한 커밋들을 모아 보니 한 곳에 몰려 있었다. 두 에픽 모두 상태 모델이었다.

계약 관리에서는 계약을 몇 개의 상태로 나눌지가 여러 차례 오갔다. 상태 단계 수가 늘었다 줄었다를 반복했고, 그때마다 외부로 노출되는 상태 값과 화면 분기, 목록 구조가 연쇄로 따라 바뀌었다. 취소 가능 조건, 결제 요청 방식, 캘린더 응답 스키마도 앞뒤로 뒤집혔다.

정산에서는 더 컸다. 정산의 상태와 유형 체계 자체가 통째로 재설계됐고, 관리자 승인을 거치던 흐름이 자동 처리로 바뀌었으며, 보류 기한 같은 정책 값도 되돌려졌다. 잔존률이 높았던 그 문서들이, 사실은 가장 많이 갈아엎어진 문서들이었다.

교훈은 조심스럽게 말할 수 있다. 초기에 필요한 것은 상태 머신을 얼리는 게 아니라, 어떤 상태와 전이를 기준으로 구현을 시작했는지 명시하고 그것이 바뀔 때마다 영향 범위를 추적하는 일이다. 도메인의 상태를 몇 개로 나누고 어떤 전이를 허용할지가 흔들리는 동안, 스펙·화면·구현이 전부 그 위에 얹혀 함께 흔들리기 때문이다. 그래서 상태 모델의 번복은 리드타임을 흔드는 주요 선행 지표일 가능성이 크다. 지금 데이터는 번복률과 잔존률을 각각 측정한 것이지 번복 감소가 리드타임을 줄였다는 비교 실험이 아니므로, 인과가 아니라 가설로 두는 것이 정확하다.

무엇을 하려는 게 아닌가

번복률을 재는 목적은 변경을 막는 게 아니다. 보강은 끝까지 허용돼야 한다. 미정이던 걸 채우는 건 기획의 정상적인 완성 과정이다. 문제는 이미 내린 결정을 되돌리는 번복이 '동기화' 같은 이름에 섞여 보이지 않는 것이다. 그걸 눈에 보이게 만들어, 다음 회고 때 이슈를 하나씩 손으로 역추적하는 대신 태그를 집계할 수 있게 하려는 것이다.

이 지표도 한계가 뚜렷하다. 커밋 단위라 큰 변경과 사소한 변경이 같은 1건으로 세어진다. 보강과 번복의 경계에는 사람의 판단이 들어간다. 생성됐다 삭제된 결정은 최종 문서에 안 남아 잡히지 않는다. 그러니 번복률도 잔존률과 마찬가지로 단독 KPI가 아니라, 변경의 성격·진앙과 함께 읽어야 하는 운영 지표다.

그래도 방향은 얻었다. AI가 얼마나 썼는지(잔존률)에 더해, 무엇을 만들지가 얼마나 흔들렸는지(번복률)를 같은 워크플로우 안에서 숫자로 남길 수 있게 됐다. 다음 기준선은 "AI를 썼는가"도 "AI 산출물이 남았는가"도 아니고, 결정이 어디서 얼마나 자주 뒤집혔는지를 설명할 수 있는가가 될 것이다.