비개발자를 위한 외주 코드 검증: 코드를 못 읽어도 품질을 판단하는 법
외주로 받은 코드가 잘 만들어졌는지, 코드를 못 읽는 사람은 어떻게 판단할까요. 문서·파일 구조·테스트·커밋·의존성 다섯 신호, 개발사에 던질 질문 네 가지, 제3자 감리 활용법, 출시 후 품질이 드러나는 지표까지 비개발자를 위한 코드 검증법을 정리했습니다.
Jul 03, 2026
외주 개발을 맡긴 회사의 대표, 혹은 커뮤니케이션을 담당하는 담당자라 할지라도 대부분은 소스코드를 읽지 못합니다. 그러나 그 코드의 품질을 판단해야 하는 순간은 반드시 옵니다. 완성된 결과물을 인수할 때나, 여러 개발사 중 한 곳을 고를 때, 그리고 외주 개발사를 옮길 때가 바로 그때죠. 그러나 코드를 한 줄도 못 읽는 사람이 "이 코드가 잘 만들어졌는가"를 어떻게 판단할 수 있을까요.
방법이 있습니다. 코드 품질은 코드 안에만 있지 않고, 그 코드를 둘러싼 여러 곳에 흔적을 남깁니다. 문서에, 파일 구조에, 개발사의 답변에, 그리고 출시 후의 운영 숫자에 남습니다. 이 글은 비개발자가 그 흔적을 읽어 품질을 가늠하는 다섯 가지 신호, 개발사에게 던질 질문, 제3자 검증을 쓰는 법, 그리고 출시 후 숫자로 품질을 역추적하는 방법을 정리합니다.
코드를 읽지 않아도 품질의 흔적은 여러 곳에 남습니다. 비개발자라도, 어디를 봐야 하는지만 알면 됩니다. 이번 아티클에서는 그 이야기를 해보려 합니다.
비즈니스 비용으로 돌아오는 ‘품질 나쁜 코드’
코드 품질은 개발자만의 관심사처럼 보이지만, 그 결과는 경영진과 기업 전체의 비용으로 돌아옵니다. 품질이 낮은 코드는 새 기능을 추가할 때마다 시간을 더 잡아먹고, 장애를 더 자주 일으키며, 다음 개발자가 손대기 어렵게 만듭니다.
이 문제를 보통 기술 부채라고 부릅니다. 1992년 소프트웨어 개발자 워드 커닝햄(Ward Cunningham)이 제시한 개념으로, 지금 당장은 작동하지만 나중에 재작업이 필요한 코드가 쌓이는 상태를 가리킵니다. 이 부채가 커지면 개발 속도가 느려집니다. 결제 서비스 회사 스트라이프(Stripe)와 컨설팅사 맥킨지(McKinsey)의 글로벌 조사에 따르면, 개발자가 업무 시간의 약 3분의 1을 기존 코드 문제를 다루는 데 쓰고, 기술 부채가 IT 예산의 20~40%를 차지하는 것으로 나타납니다.
이 비율을 실제 금액으로 환산하면 품질 문제가 눈에 보입니다. 원래 1주면 끝날 기능 추가가 나쁜 코드 위에서는 3주가 걸린다고 해봅시다. 추가된 2주가 곧 비용입니다. 과학기술정보통신부 산하 정보통신산업진흥원(NIPA)의 SW 기술자 노임단가 기준 중급 개발자 월 단가가 약 460만 원이므로, 2주 지연은 200만 원이 넘는 인건비로 환산됩니다. 기능 하나에 이 정도이니, 시스템 수명 전체로 누적되면 규모가 커집니다. 출시 이후 발생하는 유지보수 비용이 시스템 생애비용의 60~80%를 차지한다는 사실은 「외주 개발 끝나고 나면? 유지보수 비용의 진실」에서 다뤘는데, 그 비용의 상당 부분이 코드 품질에서 갈립니다.
새 기능 하나를 추가하는 데 3주가 걸린다는 답을 들었을 때, 한 이커머스 회사의 대표는 처음으로 코드 품질을 의심했다고 합니다. 출시 당시에는 잘 돌아가던 쇼핑몰이었는데, 1년이 지나자 간단한 배너 하나를 바꾸는 데도 며칠이 걸린다는 개발사의 회신이 반복됐습니다. 나중에 외부 개발자에게 코드를 보여주니, 화면 하나의 로직이 3,000줄짜리 파일 한 개에 몰려 있었고 테스트 코드는 한 줄도 없었다는 점을 발견할 수 있었습니다. 기능을 하나 고치면 어디가 깨질지 아무도 예측할 수 없는 구조였습니다. 출시 견적은 저렴했지만, 그 저렴함의 대가를 운영 단계에서 시간으로 치르고 있었습니다.
코드를 읽지 않고도 보이는 다섯 가지 신호
소프트웨어 품질은 국제 표준으로 정의되어 있습니다. ISO/IEC 25010은 소프트웨어 품질을 기능적합성, 성능효율성, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성의 여덟 가지로 나눕니다. 이 가운데 비개발자가 외주 결과물을 볼 때 가장 중요한 것은 유지보수성입니다. 나중에 고치기 쉬운 코드인가를 보는 기준이고, 다음 다섯 가지 신호로 코드를 읽지 않고도 가늠할 수 있습니다.
문서화 수준
외주 개발사에 "다른 개발자가 이 코드를 이어받으려면 필요한 문서를 보여달라"고 요청합니다. README, API 문서, 주요 로직의 주석이 정리되어 있으면, 새 사람이 코드를 이해하는 시간이 짧아집니다. ISO 25010은 이것을 ‘분석성’이라고 부릅니다. 문서가 없다면, 이 코드를 아는 사람은 만든 개발자 한 명뿐이라는 뜻입니다.
폴더와 파일 구조의 일관성
파일과 폴더가 어떤 규칙으로 정리되어 있는지는 비개발자도 눈으로 확인할 수 있습니다. 비슷한 기능이 비슷한 위치에 모여 있고 이름에 규칙이 있으면, 관리가 되고 있는 코드입니다. 파일 수백 개가 규칙 없이 한 폴더에 쌓여 있거나 이름이 제각각이면 주의 신호입니다. ISO 25010의 ‘모듈성’에 해당합니다.
테스트 코드의 유무
테스트 코드는 "고친 부분이 제대로 작동하는지 자동으로 확인하는 코드"입니다. 개발사에 테스트 코드가 있는지, 전체 코드의 어느 정도를 덮는지 물어봅니다. 업계에서는 커버리지 70~80%를 권장 수준으로 보지만, 이것이 절대 기준은 아닙니다. 초기 MVP나 소규모 프로젝트는 이보다 낮아도 정상일 수 있습니다. 다만 규모가 있는 서비스인데 테스트가 전혀 없다면, 기능을 고칠 때마다 사람이 일일이 손으로 확인해야 한다는 뜻이라 위험 신호입니다.
커밋 기록
개발사에 코드 변경 이력(Git 로그)을 보여달라고 요청합니다. 작은 변경을 자주 기록한 이력은 관리가 잘 된 신호입니다. 문제가 생겼을 때 어느 변경에서 비롯됐는지 추적하기 쉽기 때문입니다. 반대로 한 번에 수천 줄을 몰아서 기록한 커밋이 많으면, 변경 검토가 형식적으로 이뤄졌을 가능성이 있습니다.
의존성 관리
대부분의 소프트웨어는 외부에서 만든 오픈소스 라이브러리를 가져다 씁니다. 이 라이브러리가 오래된 버전으로 방치되면 알려진 보안 취약점에 노출됩니다. 소프트웨어 보안 조사기관 시놉시스(Synopsys)의 오픈소스 보안 연례 조사에서는 감사한 코드베이스의 대다수에서 취약점이 있는 오픈소스 컴포넌트가 발견됐습니다. 개발사에 사용한 라이브러리 목록과 마지막 업데이트 시점을 물어보면, 보안 관리 수준이 드러납니다.
제3자 코드 리뷰를 활용하는 법
앞서 언급한 다섯 가지의 신호를 확인해도 판단이 서지 않거나, 규모가 큰 인수를 앞두고 있다면 외부 전문가에게 검증을 맡길 수 있습니다. 회사 안에 기술을 아는 사람이 없을 때 특히 유용합니다.
기술 실사(technical due diligence)라 부르는 이 검증은 통상 다섯 가지로 구성됩니다. 코드의 구조와 복잡도를 자동으로 분석하고, 전체 아키텍처를 검토하고, 보안 취약점을 스캔하고, 테스트와 문서 수준을 점검하고, 개발팀을 인터뷰해 개발 프로세스를 확인합니다. 회사를 인수하거나 투자를 받는 상황이라면 여기에 소스코드의 소유권과 오픈소스 라이선스 준수 여부 확인이 더해집니다.
비용은 정해진 정찰가가 없습니다. NIPA 노임단가를 기준으로 "시니어 개발자 몇 사람이 며칠 투입되는가"로 견적하는 것이 실무 관행입니다. 코드 규모가 1만~5만 줄 정도인 중소 규모 프로젝트라면 시니어 개발자 한 명이 3~5일 정도 투입되는 수준에서 이뤄지는 경우가 많습니다.
제3자 감리가 모든 상황에 필요한 것은 아닙니다. 코드 규모가 작거나 특정 우려 사항 한 가지만 확인하면 되는 경우에는, 시니어 개발자 한 명에게 몇 시간에서 하루짜리 단기 리뷰를 요청하는 것으로 충분합니다. 정식 실사는 회사 인수나 대규모 시스템 이관처럼 법적, 재무적 판단이 걸린 경우에 값어치를 합니다. 규모에 맞는 검증을 고르는 것이 비용을 아끼는 길입니다.
질문으로 품질을 가늠하는 방법
코드를 직접 보지 않아도, 개발사에 던지는 질문의 답에서 품질 문화가 드러납니다. 좋은 개발사는 이런 질문에 구체적이고 일관되게 답합니다. 네 가지 질문이 특히 유효합니다.
"테스트는 어떻게 하십니까"라고 물으면, "핵심 기능에는 자동화 테스트가 있고 나머지는 QA 절차로 확인합니다"라는 답과 "테스트는 따로 없고 개발하면서 직접 확인합니다"라는 답으로 갈립니다. "코드 리뷰 절차가 있습니까"라는 질문도 중요합니다. 다른 개발자가 코드를 확인하고 승인하는 절차가 있으면 결함이 배포 전에 걸러질 확률이 높습니다. 코드 리뷰 연구(스마트베어·구글)에서도 리뷰를 거친 코드의 결함 발견율이 테스트만 거쳤을 때보다 높았습니다. "장애가 발생하면 어떻게 대응하십니까"라는 질문은 운영 성숙도를 드러냅니다. "사용자 신고로 압니다"라는 답과 "모니터링 알림이 몇 분 안에 옵니다"라는 답은 수준이 다릅니다. 마지막으로 "인수인계 자료로 무엇을 제공하십니까"라고 물으면, 소스코드와 문서, 접근 권한을 체계적으로 넘길 수 있는 개발사인지가 드러납니다.
다만 답을 해석할 때 규모를 함께 봐야 합니다. 1인 개발 체제의 소규모 프로젝트라면 코드 리뷰 절차가 없는 것이 불가피할 수 있습니다. 답 자체보다 그 답이 프로젝트 규모에 맞는지가 판단 기준입니다.
같은 질문에 두 개발사가 내놓은 답은 달랐습니다. 한 중견 교육기업이 학습 플랫폼 개발사를 고르며 두 후보에게 똑같이 "장애가 나면 어떻게 대응하느냐"고 물었습니다. 한 곳은 "문제가 생기면 바로 조치하겠다"는 다짐으로 답했고, 다른 곳은 "모니터링 도구로 오류를 실시간 감지하고, 장애 등급별로 대응 시간을 정해 두었다"며 실제 대응 절차 문서를 보여줬습니다. 두 회사의 견적 차이는 15%였지만, 답변이 드러낸 운영 성숙도의 차이는 그보다 컸습니다. 이 회사는 후자를 선택했고, 출시 후 1년간 장애 대응으로 겪은 손실이 견적 차이를 메우고도 남았습니다. 이런 질문을 체계적으로 정리한 목록은 「외주 개발사 비교할 때 반드시 물어봐야 할 10가지 체크리스트」에 있습니다.
출시 후 품질이 드러나는 지표
계약 전에 품질을 다 확인하지 못했다면, 출시 후의 숫자가 대신 말해줍니다. 구글의 데브옵스 연구팀(DORA)이 정리한 네 가지 지표가 소프트웨어 운영 품질을 가늠하는 국제 기준으로 널리 쓰입니다.
첫째는 배포 빈도입니다. 얼마나 자주 새 버전을 안정적으로 내놓는가입니다. 둘째는 변경 리드타임으로, 코드를 수정하고 실제 서비스에 반영되기까지 걸리는 시간입니다. 셋째는 변경 실패율입니다. 배포한 변경 가운데 장애를 일으키는 비율이고, 이 숫자가 높으면 코드가 불안정하다는 신호입니다. 넷째는 복구 시간으로, 장애가 난 뒤 정상으로 돌아오기까지 걸리는 시간입니다. 성과가 높은 조직은 자주 배포하면서도 실패율이 낮고 복구가 빠른 반면, 성과가 낮은 조직은 배포 주기가 길고 한 번 장애가 나면 복구에 며칠이 걸립니다.
여기에 버그 재발률을 함께 보면 됩니다. 같은 장애가 짧은 간격으로 반복된다면, 근본 원인을 고치지 않고 임시 조치만 반복하고 있다는 신호입니다. 출시 3개월간 같은 버그가 다섯 번 재발한 시스템에서, 한 물류 스타트업은 개발사가 매번 "이번엔 완전히 고쳤다"고 했지만 결제 오류가 2주 간격으로 되돌아왔습니다. 외부 검토 결과, 개발사는 오류가 난 화면만 그때그때 막고 있었을 뿐 오류를 만드는 공통 로직은 손대지 않고 있었습니다. 재발하는 버그는 코드베이스가 근본적으로 취약하다는 지표였습니다.
이 지표들을 보려면 한 가지 전제가 필요합니다. 시스템의 운영 데이터에 접근할 수 있어야 한다는 것입니다. 코드와 운영 환경을 인수받을 수 있는 계약 구조가 되어 있어야 이 숫자들을 직접 확인할 수 있습니다. 외주 프로젝트가 어디에서 무너지는지는 「외주 개발 실패하는 7가지 이유와 예방법」에서 다뤘는데, 운영 데이터 단절도 그중 하나입니다.
인수인계에서 증명되는 ‘품질 좋은 코드’
지금까지의 신호와 질문과 지표는 한 곳으로 모입니다. 코드 품질의 최종 증거는 "다른 사람이 이어받을 수 있는가"입니다. 소스코드, 문서, 서버 접근 권한, 라이브러리 목록을 정리해서 넘길 수 있는 개발사는 코드를 체계적으로 관리해 왔다는 뜻입니다. 인수인계가 수월한 코드는 문서화가 되어 있고, 구조가 일관되며, 테스트로 검증되어 있습니다. 인수인계를 못 하는 코드는 그 반대의 상태를 숨기고 있는 경우가 많습니다.
스파르타빌더스는 소스코드와 인수인계 패키지를 표준으로 제공합니다. 개발이 끝나면 아키텍처 문서, 운영 매뉴얼, 접근 권한을 함께 넘겨, 발주사가 코드를 인수받아 직접 운영하거나 다른 팀에 이어줄 수 있는 상태로 마무리합니다. 이 인수인계 가능성 자체가 코드 품질의 증거입니다. 직계약 개발사가 왜 이 부분에서 유리한지는 「직계약 개발이 중개 플랫폼보다 안전한 3가지 이유」에서 다룹니다. 외주 결과물의 품질을 검증하고 있다면, 프로젝트에 맞는 확인 항목을 함께 정리해 드립니다.
자주 묻는 질문
Q1. 코드를 못 읽는데 품질을 어떻게 확인하나요?
세 가지를 조합하면 됩니다. 코드를 읽지 않고도 볼 수 있는 다섯 신호(문서화, 파일 구조, 테스트 유무, 커밋 기록, 의존성 관리)를 개발사에 요청해서 확인하고, 개발사에 품질 관련 질문을 던져 답을 비교하고, 판단이 서지 않으면 제3자 전문가에게 검증을 맡깁니다. 이 세 가지는 코드 한 줄을 읽지 않아도 실행할 수 있습니다.
Q2. 테스트 코드가 없으면 나쁜 개발사인가요?
규모에 따라 다릅니다. 업계에서는 테스트 커버리지 70~80%를 권장하지만, 이것은 목표치이지 절대 기준이 아닙니다. 빠르게 검증해야 하는 초기 MVP나 소규모 프로젝트는 테스트가 적거나 없어도 합리적인 선택일 수 있습니다. 다만 사용자가 많고 오래 운영할 서비스인데 테스트가 전혀 없다면, 기능을 고칠 때마다 사람이 손으로 확인해야 하므로 유지보수 비용과 장애 위험이 커집니다.
Q4. 기술 부채가 정확히 어떤 상태를 의미하나요?
지금 당장은 작동하지만 나중에 재작업이 필요한 코드가 쌓이는 상태입니다. 1992년 개발자 워드 커닝햄이 제시한 개념으로, 이것이 커지면 새 기능을 추가할 때마다 시간이 더 걸리고 장애가 늘어납니다. 글로벌 조사에서 개발자가 업무 시간의 약 3분의 1을 기존 코드 문제에 쓰고 기술 부채가 IT 예산의 20~40%를 차지한다고 나타나, 규모가 작지 않은 비용입니다.
Q5. 이미 받은 코드의 품질이 의심되면 어떻게 대응해야 하나요?
먼저 제3자 감리로 현재 상태를 진단합니다. 그다음 인수인계 자료(소스코드, 문서, 접근 권한)가 갖춰져 있는지 확인합니다. 이 자료가 있으면 다른 개발사로 유지보수를 옮기거나 내부에서 운영할 수 있고, 없으면 원개발사에 종속됩니다. 진단 결과와 인수인계 가능 여부를 함께 놓고, 지금 개발사와 계속할지 다른 곳으로 옮길지를 판단하면 됩니다.
Share article