기획서와 코드 사이를 잇고, AI가 얼마나 썼는지 숫자로 답하기까지

AI 코딩 도구를 도입하는 건 어렵지 않았다. 어려운 건 기획이 PRD·아키텍처·스펙·테스트 케이스로 번역되는 동안 결정이 유실되지 않게 만드는 일이었다.

얼마 전 한 릴리즈의 이슈를 전수 분류했다. 순수 구현 버그와 “무엇을 만들지가 흔들려서 생긴 이슈”가 각각 약 38%로 비슷한 규모였다. 코드 구현만큼이나, 무엇을 만들지 확정하고 변경을 추적하는 과정이 주요 실패 지점이었다.

내가 만든 것은 SDD 자체가 아니다. 문서 안에 머물던 결정을 Jira 완료 조건과 Figma 화면, 그리고 구현까지 밀어 넣는 연결 계층이었다. 같은 결정이 도구마다 다르게 남아 있을 때, 사람이 QA에서 뒤늦게 발견하기 전에 Jira·Figma·테스트 케이스 단계에서 먼저 드러내는 장치다.

지난 분기 한 부동산 플랫폼의 신규 결제·계약 도메인을 만들면서, 이미 운영 중이던 SDD 워크플로우 위에 두 가지 연결을 추가했다. PRD의 결정 사항을 Jira 티켓에 동기화하고, Figma 화면을 찾아 간격·색·문구 같은 디자인 기준을 구현·테스트 조건과 대조하는 스킬이었다. 목표는 잘 만든 프롬프트 하나가 아니었다. 기획·디자인·개발 도구 사이에서 같은 결정이 반복 가능하게 전달되고, 변경 이력이 남는 시스템을 만드는 것이었다.

기존 4단계 사이의 연결을 자동화했다

기반이 된 워크플로우는 이미 다음 네 단계로 구성돼 있었다.

PRD → Architecture → Spec → Test-Case

각 단계는 앞 문서를 입력으로 받아 다음 산출물을 만든다. 상위 문서가 바뀌면 하위 문서를 stale 상태로 표시하고, 문서 본문의 tree hash를 비교해 변경을 추적하는 구조였다.

내가 집중한 것은 이 문서 트리와 실제 협업 도구 사이의 간극이었다. PRD가 갱신돼도 Jira 티켓의 설명과 완료 조건이 예전 상태로 남거나, Figma 화면과 구현 결과가 서로 다른 기준을 따르는 문제는 별도로 확인해야 했다.

이를 줄이기 위해 두 가지 스킬을 만들었다. 하나는 PRD를 기준으로 관련 Jira 티켓의 내용을 동기화하고 누락된 요구사항을 확인한다. 다른 하나는 Figma에서 대응하는 화면을 찾아 간격·색·문구 같은 디자인 기준을 구현 결과·테스트 조건과 대조한다. AI가 Jira나 디자인의 결정을 대신하는 것이 아니라, 서로 다른 도구에 흩어진 기준을 비교하고 차이를 드러내는 역할이다.

이 4단계는 내가 설계한 것이 아니다. 그 위에서 팀은 이미 14개 이상의 에픽을 진행하고 있었다. 내가 더한 것은 이 문서 트리를 Jira 완료 조건·Figma 화면·구현까지 잇는 두 개의 검증 스킬이었고, 이번 결제·계약 도메인 전반에 본격적으로 적용했다.

연결 계층이 배포 전에 잡아낸 것들

효과는 잔존률 숫자보다 “무엇을 미리 잡았는가”에서 먼저 드러났다.

Jira 쪽. 한 릴리즈에서 내가 담당한 프런트엔드 티켓 수십 건을 스펙과 하나씩 대조했다. 그중 10건은 이미 폐기된 옛 설계를 완료 조건에 그대로 두고 있거나, 완료 조건 자체가 비어 있었다. 내가 맡은 화면 기준으로 보면 약 38%였다. 대표적으로 멀티예약 딥링크 화면은 PRD와 스펙에는 상태 전이가 정의돼 있었지만 Jira 티켓의 완료 조건은 0개였다 — 구현에 들어가기 전에 검출해 조건을 새로 작성했다. 취소 가능 여부처럼 버튼 노출을 좌우하는 조건이 네 개 문서에서 서로 다르게 적혀 있던 것도, 타이머 만료 시 자동으로 일어나는 상태 전이가 어느 완료 조건에도 없던 것도 같은 방식으로 드러났다. 근본 원인은 하나였다. 스펙과 코드는 최신인데, Jira 완료 조건만 예전 모델에 고착돼 있었다.

Figma 쪽. 그 릴리즈에서 보고된 전체 이슈를 원인별로 나눴더니, 가장 큰 단일 원인이 특정 기능의 버그가 아니라 디자인과 구현의 불일치였다 — 릴리즈 이슈 전체를 100으로 봤을 때 16.3%다. 그래서 화면별로 Figma 링크와 베이스라인이 대조 가능한 상태인지부터 판정하고, “정확히 표시된다” 같은 검증 불가능한 완료 조건을 Figma 노드와 관측 가능한 조건으로 바꿔 테스트 케이스에 반영했다.

이 검출들은 잔존률처럼 하나의 수치로 요약되지 않는다. 하지만 “AI가 코드를 얼마나 짰나”보다 먼저 답해야 할 질문 — 무엇을 만들지가 도구 사이에서 어긋나지 않았나 — 에 대한 답이었다.

처음에는 AI 기여도를 측정할 수 없었다

워크플로우의 효과를 설명하다 보니 자연스럽게 질문이 생겼다.

그래서 최종 결과물에서 AI가 작성한 부분은 얼마나 남았을까?

1차 MVP에서는 답할 수 없었다. 작업 당시 작성 주체를 기록하지 않았기 때문이다. 사후에 커밋 기록을 분석해도 어떤 라인을 AI가 작성했고 사람이 어떻게 보정했는지 신뢰할 만한 수준으로 복원할 수 없었다. 해당 PR들은 결국 측정 표본에서 제외했다.

2차부터는 작성 시점의 attribution을 git notes에 남기고 푸시하는 과정을 워크플로우에 포함했다. 최종 커밋의 각 라인을 이 기록과 비교하면서, AI가 작성한 라인이 최종 결과물에 얼마나 유지됐는지를 계산할 수 있게 됐다.

이 글에서 말하는 잔존률은 생산성이나 코드 품질 점수가 아니다. AI가 작성한 결과물이 사람의 보정을 거쳐 최종 산출물에 얼마나 유지됐는지를 보여주는 운영 지표다.

두 에픽에서 처음 숫자가 나왔다

측정 가능한 상태로 진행한 두 에픽의 결과는 다음과 같았다.

임대인 계약관리: 코드 잔존률 99.7%
임대인 정산: PRD 86.4%, 디자인 문서 89.4%

계약관리 에픽에서는 AI가 작성한 코드가 대부분 유지됐다. 다만 테스트 코드 비중이 높았기 때문에, 99.7%만 떼어 “AI가 구현을 거의 전부 했다”고 해석하면 과장이다.

정산 에픽에서는 코드뿐 아니라 PRD와 디자인 문서까지 같은 흐름으로 측정했다. SDD 네 단계를 모두 거치며, AI가 만든 기획·설계 초안을 사람이 어느 정도 보정했는지 처음으로 확인할 수 있었다.

정산 에픽은 PRD 첫 커밋부터 마지막 코드 머지까지 20일이 걸렸다. 아직 비교 표본이 부족하므로 이를 생산성 개선의 증거로 보지는 않는다. 이후 에픽과 비교하기 위한 첫 기준선에 가깝다.

잔존률은 높을수록 좋은 점수가 아니다

다른 결제 에픽의 코드 잔존률은 약 58%였다. AI가 작성한 초안의 절반 남짓이 최종 코드까지 남았고, 나머지는 리뷰 반영과 사람의 추가 작업으로 대체·보강됐다는 뜻이다.

이 수치는 “AI가 잘못했다”는 평가가 아니다. 리뷰 반영과 사람의 개입이 더 많았다는 협업 양상을 보여준다. 반대로 99.7% 역시 난이도나 품질을 보장하지 않는다.

잔존률이 설명하지 못하는 것도 많다.

생성한 뒤 삭제된 코드의 가치
구현 난이도와 품질
리뷰와 검증에 들어간 시간
실제 비즈니스 성과

따라서 잔존률은 단독 KPI가 아니라, 산출물 종류·테스트 비중·사람의 개입 이유와 함께 봐야 한다.

측정은 다음 실패 모드도 드러냈다

이 워크플로우는 상위 문서의 변경을 감지하지만, 변경의 성격까지 구분하지는 않는다.

미정이었던 내용을 채운 보강인지, 이미 합의한 결정을 뒤집은 번복인지 구분하지 못했다. 변경이 일어났다는 신호는 주지만, 그 변경이 정상적인 완성 과정인지 되돌린 결정인지는 알려주지 않았다.

실제 회고에서도 개발 이후 스펙이 확정되거나 변경된 이슈가 5건 중 1건을 넘었지만, 각각의 변경 이유는 사람이 수작업으로 역추적해야 했다. AT와 QA가 검증뿐 아니라 스펙을 확정하는 단계로 쓰이고 있었던 것이다.

AI attribution은 워크플로우 안에 넣어 측정할 수 있게 했지만, “무엇을 만들지가 흔들리는 문제”는 여전히 밖에 남아 있었다.

다음 사이클에는 세 가지를 추가한다.

기준선을 남기고 이후 변경을 [보강]과 [번복]으로 분류한다.
상태 조합과 전이별 부수효과를 PRD의 필수 표로 만들고 테스트 케이스까지 연결한다.
에픽 용어사전을 SSOT로 관리한다.

목적은 변경을 막는 것이 아니다. 보강은 끝까지 허용하되, 이미 내린 결정을 뒤집은 번복은 눈에 보이게 만드는 것이다. 다음 회고에서는 이슈를 하나씩 역추적하는 대신 변경 태그를 집계할 수 있어야 한다.

남은 생각

AI를 사용했는지는 이제 중요한 질문이 아니다. 중요한 것은 그 결과물이 실제 업무에 어떻게 반영됐고, 사람이 어디에서 판단하고 수정했는지를 설명할 수 있느냐다. 측정을 워크플로우 밖 숙제로 두었던 1차 MVP에서는 그걸 설명하지 못했고, 기록을 기본 동작으로 만든 뒤에야 숫자가 나오기 시작했다.

결국 이 작업은 “AI를 도입했다”를 “어디에, 어느 정도, 어떤 한계와 함께 반영됐다”로 바꾸는 일이었다. 연결 계층은 PRD·Jira·Figma·구현 사이의 결정을 흐르게 했고, attribution은 그 흐름을 숫자로 남겼다. 다음 기준선은 단순한 도입 여부가 아니라 설명 가능성이다.

다음 글에서는 git notes를 이용한 라인 단위 attribution 파이프라인과 잔존률 계산 방식을 구체적으로 다뤄보려 한다.