빨리 만든 코드가 남기는 청구서: 외주 납품물의 유지보수성을 검수·계약 단계에서 걸러내는 발주사 PM 기준

납품 시점에는 대체로 화면이 다 돌아가고 데모도 매끄럽습니다. 요구한 기능이 목록대로 체크되면 발주사 PM은 인수 서명을 하게 됩니다. 문제는 인수 몇 달 뒤에 드러납니다. 작은 기능 하나를 고치는데 예상보다 오래 걸리고, 한 곳을 고치면 다른 곳이 깨지고, 유지보수를 넘겨받은 팀은 '차라리 다시 짜자'는 말을 꺼냅니다. 빨리 만든 코드가 뒤늦게 청구서를 내미는 순간입니다.

이 글은 프로젝트 중반의 진행률 문제가 아니라, 납품·인수 시점의 품질 부채를 다룹니다. FIRSTPIP은 외주 개발을 맡는 SI 파트너로서, 발주사가 검수를 느슨하게 하는 것보다 기준을 명확히 세우고 들어오는 편이 양쪽 모두에게 이롭다고 봅니다. 아래 기준은 그 검수 게이트를 세우는 실무 재료입니다.

'빨리 = 잘 만든 것'이 아니라는 원 데이터

속도와 품질을 같은 것으로 보면 인수 판단이 흔들립니다. 최근 코드 계측 데이터는 둘이 오히려 반대로 움직일 수 있음을 보여줍니다.

• 중복은 늘고 정리는 줄었습니다. GitClear의 AI Copilot Code Quality 2025 연구(코드 변경 2억 1,100만 라인 분석)에 따르면 2024년 한 해 동안 중복 코드 블록 발생 빈도가 여덟 배로 늘었고, 변경 라인 중 리팩터링이 차지하는 비중은 2021년 25%에서 2024년 10% 미만으로 떨어졌습니다. 복사·붙여넣기로 분류된 라인 비중은 8.3%에서 12.3%로 올랐습니다.
• 유지보수를 떠받치는 지표가 함께 내려갔습니다. GitClear의 The Maintainability Gap(2026)은 2022년 수준 대비 리팩터링 목적의 코드 이동이 약 70%, 1년 넘은 코드에 대한 장기 유지보수 작업이 약 74%, 재사용을 뜻하는 파일 간 함수 호출이 약 35% 줄었다고 보고합니다. 같은 기간 복사·붙여넣기는 41%, 코드 블록 중복은 81%, 오류를 가리는 구문은 47% 늘었습니다.
• 빨라 보이는 것과 실제로 빨라진 것은 다릅니다. METR이 2025년 7월 발표한 무작위 대조시험에서는 평균 5년간 다뤄 온 성숙한 리포지토리에서 숙련 개발자 16명이 246개 작업을 수행했는데, AI 도구 사용을 허용했을 때 완료 시간이 오히려 약 19% 늘었습니다. 정작 개발자들은 사전에 24% 단축을 예측했고 실험 후에도 20% 단축됐다고 체감했습니다. 체감과 실측이 정반대로 벌어진 것입니다.

정리하면, 데모가 잘 돌아간다는 사실은 유지보수 비용에 대해 아무것도 보증하지 않습니다. 발주사 PM이 인수 전에 확인해야 할 것은 '동작 여부'가 아니라 '앞으로 고쳐 쓸 수 있는 구조인가'입니다.

검수 게이트: 인수 전에 정량적으로 거르는 항목

기능 테스트만으로는 위 부채가 보이지 않습니다. 유지보수성을 계측 가능한 항목으로 바꿔 검수 게이트에 넣어야 합니다.

코드 구조 지표

• 중복률: 정적 분석 도구로 중복 코드 블록 비율을 측정하고, 상한선을 넘으면 인수 보류 사유로 명시합니다. 같은 로직이 여러 파일에 복사돼 있으면 한 곳을 고쳐도 나머지가 그대로 남습니다.
• 재사용 구조: 공통 로직이 함수·모듈로 분리돼 호출되는지, 아니면 화면마다 붙여넣기로 흩어졌는지 확인합니다. 파일 간 호출이 거의 없는 코드는 나중에 손댈 곳이 많다는 신호입니다.
• 오류 처리: 예외를 삼켜 로그만 남기고 넘어가는 구문이 얼마나 되는지 봅니다. 오류를 가리는 코드는 데모를 매끄럽게 만들지만 운영에서 원인 추적을 어렵게 합니다.

이관 가능성 지표

• 테스트와 문서: 핵심 로직에 자동화 테스트가 붙어 있는지, 실행·배포·환경 설정 문서로 다른 팀이 그대로 띄울 수 있는지 확인합니다.
• 재수정 이력: 짧은 기간 안에 같은 파일이 반복해 뜯어고쳐진 흔적(churn)이 많다면 설계가 자리 잡지 못했다는 뜻입니다.
• 이관 리허설: 인수 전에 발주사 또는 유지보수 담당이 실제로 사소한 기능 하나를 직접 수정해 보게 합니다. 걸리는 시간과 막히는 지점이 유지보수성의 가장 정직한 지표입니다.

계약 조항으로 유지보수성을 명문화하기

검수 기준이 계약서에 없으면 인수 단계의 협상력이 사라집니다. 국내 SI 계약은 기능 목록과 일정 위주로 쓰이는 경우가 많은데, 유지보수 부채는 여기에 잡히지 않습니다. 다음을 조항으로 넣어 두는 편이 분쟁을 줄입니다.

• 품질 기준의 수치화: 중복률 상한, 정적 분석 경고 허용치, 핵심 로직 테스트 커버리지 하한을 계약 부속서에 적고, 미달 시 인수 보류·보완 의무를 연결합니다.
• 산출물 범위 명시: 실행되는 코드뿐 아니라 설계 문서, 실행·배포 절차, 환경 변수 목록, 외부 연동 계정 정보를 납품물에 포함시킵니다.
• 하자 보수 기간과 이관 책임: 인수 후 일정 기간의 하자 보수 범위와, 유지보수 팀 교체 시 인수인계 세션 제공 의무를 분리해 규정합니다.
• 변경 이력 접근권: 저장소 커밋 이력과 이슈 기록을 발주사가 넘겨받도록 해, 왜 그렇게 짰는지 맥락이 함께 이관되게 합니다.

이런 조항은 개발사를 옥죄기 위한 것이 아닙니다. 오히려 기준이 명확할수록 개발 단계에서 무엇을 지켜야 하는지 서로 합의한 상태로 일하게 되고, 인수 시점의 감정 싸움이 줄어듭니다.

마무리

AI 도구가 코드 생산 속도를 끌어올리는 흐름은 되돌릴 수 없습니다. 그러나 위 데이터가 보여주듯, 빠르게 쌓인 코드일수록 중복과 미정리 부채가 함께 늘어날 수 있다는 점을 발주사 PM은 인수 판단에 반영해야 합니다. 핵심은 '누가 만들었나'를 따지는 것이 아니라, '넘겨받은 뒤 우리가 고쳐 쓸 수 있는가'를 계측 가능한 기준으로 확인하는 것입니다. 검수 게이트와 계약 조항을 함께 설계해 두면, 데모의 매끄러움과 유지보수의 실체를 분리해 볼 수 있습니다. FIRSTPIP은 이런 기준 위에서 납품하고 이관하는 방식을 선호하며, 프로젝트 초기에 검수 항목을 함께 정의하는 것부터 시작하기를 권합니다.