문제는 문서 양식이 아니라 이해관계의 구조였습니다.
템플릿·교육·Jira·코드주석을 반복해도 누락이 사라지지 않았습니다. 개발자가 자세히 쓰면 QA 범위와 고객 질문이 늘어났고, 최소한만 쓰는 편이 단기적으로 유리했습니다. 고객사 특수 패치는 Main과 장기간 분리돼 담당자 외에는 의도를 알기 어려웠고, 릴리즈 직전 3일에 모든 문서화 부담이 집중됐습니다.
Agent가 Commit, Jira, C++ 심볼, 기존 릴리즈 문서와 호출 영향 범위를 분석했습니다.
Custom MCP가 화면 상태를 읽고 버튼 클릭, TextBox 수정, 검사 Window 설정과 검사 흐름을 실행했습니다.
변경 의도, 목적, 영향 범위, 제약을 기록하고 실제 Screenshot을 PR에 연결했습니다. 이미지가 없으면 Mock 상태가 남아 누락을 드러냈습니다.
기능이 재현되지 않으면 NEED CHECK, 문서와 실제 동작이 다르거나 Smoke가 실패하면 Fail로 처리했습니다.
초기 자동화가 만든 새 문제
- Agent가 수기 문서보다 약 4배 많은 내용을 만들어 검토 부담이 증가했습니다.
- 내부 함수명을 그대로 사용해 QA와 고객이 이해하기 어려운 설명이 나왔습니다.
- 초기부터 Merge를 막으면 오탐 하나가 전체 일정 지연으로 이어질 수 있었습니다.
작성 방식과 품질 통제를 분리
“코드를 본 개발자가 직접 써야 정확하다”는 의견을 논파하지 않았습니다. AI 작성을 원하지 않으면 같은 양식에 수기로 작성할 수 있게 했습니다. 대신 실제 Screenshot, 실행 재현, Smoke와 최종 QA 승인은 누구에게나 동일하게 적용했습니다.
로컬 성공을 완료로 인정하지 않음
Agent가 로컬에서 빌드와 실행이 된다고 푸시했지만 GitLab Clean Runner에서 필요한 DLL이 누락돼 실패한 사례가 있었습니다. 로컬 bin에 과거 DLL이 남아 있어 성공한 착시였습니다.
이후 완료 정의를 “코드가 돌아간다”에서 “깨끗한 환경에서 재현되고 필요한 산출물이 실제 패키지에 포함된다”로 바꿨습니다.
고객지원 감소 수치의 한계도 공개
개발팀 동분기 설문에서는 개인전화·카카오톡 기반 고객지원 문의가 약 75% 감소했다고 체감했습니다. 그러나 공식 메신저와 통화 로그가 없어 객관적으로 재검증할 수 없으므로 Hero KPI에서는 제외하고, 정성적 변화관리 결과로만 사용합니다.
검증할 수 없는 범위를 남김
회귀 전용 장비가 없고 기존 Simulator가 CUDA 기반 3D Image Draw 경로를 재현하지 못해 CPU 기반 기능과 안정적인 UI 경로만 자동화했습니다. GPU·광학·실장비 영역은 수동 QA로 명시했습니다.
완료조건
개발자가 변경 의도를 승인하고, 실제 앱에서 재현되며, Screenshot과 문서가 일치하고, Smoke와 GitLab Clean Runner가 통과한 뒤 QA가 릴리즈 착수를 승인해야 완료입니다.