개발 외주 검수 방법, 완료 보고를 받은 날 확인할 다섯 가지

[✓] migrations applied successfully!

배포 화면에 이 줄이 두 번 찍혔습니다. 데이터베이스 변경이 잘 들어갔다고 읽히는 문장입니다.

실제로는 하나가 빠져 있었습니다. 기록된 변경은 43개, 적용된 변경은 42개였습니다.

보험대리점(GA) 지사의 고객관리 시스템을 배포하던 날입니다. 저는 그 시스템을 만든 개발자입니다.

제가 제 작업을 검수할 때 쓰는 질문을 발주하는 쪽에 그대로 넘겨 드리려 합니다. 외주 개발사에게서 "배포 완료했습니다"를 받은 날 무엇을 눌러 봐야 할지 막막한 분을 생각했습니다.

성공 문구가 찍힌 날

그날은 새 코드의 빌드가 실패했습니다. 그런데 배포 절차는 멈추지 않았습니다.

서버에 남아 있던 옛 이미지로 DB 변경 단계가 돌았습니다. 옛 이미지 안에는 새 변경 파일이 없었습니다.

도구는 할 일을 다 했다고 보고 성공을 찍었습니다. 로그 어디에도 "새 변경이 없다"는 말은 나오지 않습니다.

막은 것은 배포 스크립트에 넣어 둔 한 줄이었습니다. 변경 기록의 개수와 DB에 실제로 적용된 개수를 세어 보고, 다르면 배포를 멈춥니다.

43과 42가 달랐고 배포는 멈췄습니다. 이 한 줄이 없었다면 저는 그날 "배포 완료했습니다"라고 보고했을 겁니다.

실행했다와 적용됐다

그 한 줄을 넣게 된 사고는 2주쯤 앞서 있었습니다. 같은 시스템에서 같은 성공 문구가 떴는데, 변경 하나가 조용히 건너뛰어졌습니다.

도구는 정상 종료 신호를 돌려줬습니다. 서버 상태 점검(헬스 체크)도 통과했습니다.

헬스 체크가 보던 것이 DB에 연결되는지 하나뿐이었기 때문입니다. 배포 스크립트는 그대로 "완료"를 출력했습니다.

문제는 첫 화면 요청에서 드러났습니다. 앱이 아직 만들어지지 않은 칸을 찾다가 오류 화면을 띄웠습니다.

성공 로그는 대개 "명령이 끝까지 실행됐다"까지만 증명합니다. 변경이 실제로 들어갔는지, 새 버전이 실제로 떠 있는지는 따로 확인해야 합니다.

그 뒤로 저는 배포 절차에 변경 순서 검사, 개수 대조, 떠 있는 버전 번호 대조를 붙였습니다. 이번 43과 42를 잡은 것이 그중 개수 대조입니다.

발주하는 분이 로그를 직접 읽을 필요는 없습니다. 대신 이렇게 물어보세요.

"이 성공 메시지는 실행을 확인한 건가요, 적용을 확인한 건가요?"

답이 바로 나오면 그 개발사는 이미 대조를 하고 있을 가능성이 큽니다. 머뭇거린다면 그 배포는 아직 확인 대기로 두세요.

우리 파일로 한 번 더

급식 납품업체의 한 지점에서 판매 엑셀을 올렸더니 269행이 전부 실패했습니다. 신규 0건, 갱신 0건이었습니다.

원인은 날짜였습니다. 판매 프로그램이 일자를 20260814처럼 구분자 없이 내보냈고, 제 코드는 2026/08/14 같은 모양만 받고 있었습니다.

직전 패치가 막은 게 아니냐는 의심이 먼저 나왔습니다. 변경 이력을 거슬러 보니 이 모양은 처음부터 한 번도 통과한 적이 없었습니다. 판매 프로그램 쪽 내보내기 형식이 바뀌면서 새 모양이 들어온 것이었습니다.

고친 코드는 한 줄이었고 확인에는 더 품을 들였습니다.

서버와 같은 파서로 그 지점이 올린 실제 파일을 그대로 돌렸습니다. 수정 전 유효 0행·실패 269행이 수정 후 유효 269행·실패 0행으로 바뀌었습니다.

서버에 올라간 빌드 결과물 안에서도 고친 코드를 찾았습니다. 소스를 고쳤다고 그 코드가 서버에 실렸다는 보장은 없어서입니다.

그다음 실제 운영 화면에서 같은 파일을 다시 올려 반영되는 것을 확인했습니다. 저는 이 장면을 보고 나서 완료라고 적었습니다.

그래서 발주자에게 드리는 첫 부탁은 이것입니다. 검수에 쓸 파일은 직원이 실제로 최근에 올린 원본 파일이어야 합니다.

개발 단계에서 본 파일에는 그때까지의 모양만 들어 있습니다. 바깥 프로그램이 형식을 바꾸면 새 모양은 운영 파일에서 처음 나타납니다.

가장 낮은 권한의 계정

권한 기능은 개발자 계정으로 보면 검수가 되지 않습니다. 개발자 계정은 전체 열람이라 필터가 걸릴 자리가 없습니다.

보험대리점 고객관리 시스템에서 "설계사는 자기 담당만 본다"는 규칙을 확인할 때, 저는 실제 설계사 역할 계정을 하나 만들었습니다. 그 계정으로 담당자가 여럿인 고객과 남의 고객 주소를 열어 본 뒤 계정을 지웠습니다.

화면에는 본인 담당 1건만 보였고, 남의 고객 주소는 찾을 수 없는 페이지로 막혔습니다. 같은 장면이 외주를 맡기기 전 준비를 다룬 글에서는 권한 표를 세우는 쪽으로 다시 나옵니다.

발주자 쪽에서 할 일은 짧습니다. 가장 권한이 낮은 실제 직원 계정으로 들어가, 그 사람이 보면 안 되는 화면 주소를 붙여 넣어 보세요.

역할마다 보이는 범위가 어떻게 갈리는지 미리 감을 잡고 싶다면 보험대리점 고객관리 데모에서 역할을 바꿔 가며 같은 화면을 열어 보세요. 관리자와 설계사가 보는 계약 목록이 다르게 나옵니다.

넣은 건수와 들어간 건수

맨 앞의 43과 42가 이 질문의 예입니다. 두 숫자를 나란히 놓으면 빠진 1건이 바로 보입니다.

데이터를 옮겼다면 원본 행 수와 새 시스템의 건수를 맞춰 보세요. 업로드 기능이라면 파일의 행 수와 반영 건수를 봅니다.

269행 파일이 269건으로 들어갔는지가 첫 질문입니다. 화면에 "업로드 완료"가 떠도 이 숫자를 따로 확인해야 합니다.

무엇을 셀지는 요구사항 문장 그대로 정해야 합니다. 저는 여기서 한 번 틀렸습니다.

설계사를 해촉하면 그 사람에게 연결된 로그인 계정을 모두 막는 기능이었습니다. 저는 검증식을 "연결 계정 1개가 비활성"으로 세웠습니다.

결과는 실패로 떴습니다. 그 설계사에게 실제 연결 계정이 이미 있어서, 시험용 계정까지 2개가 함께 막혔기 때문입니다.

기능은 요구대로 돌았습니다. 요구가 "연결 계정 전부 차단"이었으니 검증도 "활성으로 남은 계정 0개"로 세워야 했습니다.

숫자를 셀 때는 남아서는 안 되는 것이 몇 개 남았는지를 물어보세요. 기대값이 0이면 예상 밖의 데이터가 섞여 있어도 기준이 흔들리지 않습니다.

화면과 안내문까지

판매 엑셀 문제를 고친 날 저는 서버 쪽만 다시 배포했습니다. 고객이 보는 업데이트 안내는 웹 화면 쪽 코드에 들어 있어서 함께 올라가지 않았습니다.

웹 화면을 따로 한 번 더 배포해 "판매 파일 업로드 오류 수정"이라는 안내를 걸었습니다. 이 단계를 빼먹으면 쓰는 사람 입장에서는 고쳐졌는지 알 길이 없습니다.

고객에게 보이는 수정이라면 화면 쪽 배포를 따로 챙겨야 합니다. 완료 보고를 받으면 화면 문구, 안내문, 사용 설명서처럼 사람이 읽는 쪽도 바뀌었는지 보세요.

당일 검수표

완료 보고를 받은 날 아래 표를 개발사에 그대로 보내도 됩니다. 오른쪽 칸이 비어 있으면 그 칸을 채울 증거를 요청하세요.

확인할 질문	'예'라고 하려면 필요한 것
실제로 쓰는 파일·데이터로 다시 해봤나	직원이 최근에 올린 원본 파일로 돌린 결과
가장 권한이 낮은 실제 역할 계정으로 들어가 봤나	그 계정으로 남의 화면 주소를 열었을 때 막힌 화면
성공 로그가 실행을 증명하는지 적용을 증명하는지 물었나	개발사의 한 줄 답과 그 근거
넣은 건수와 들어간 건수를 맞춰 봤나	두 숫자, 그리고 남으면 안 되는 것의 건수
화면·안내문까지 바뀌었나	사용자가 보는 화면에서 바뀐 문구

하나라도 '모름'이면 그 항목은 확인 대기로 두세요. 대기 항목이 있는 채로 잔금을 치르면 나중에 고칠 근거가 약해집니다.

이 표를 회사 안의 검수 기준으로 굳히고 싶다면 순서가 있습니다. 어떤 업무를 시스템으로 옮길지, 무엇을 '완료'로 볼지를 먼저 적어 두는 일입니다.

그 작업을 직원들과 같이 해 보는 과정이 업무 시스템 도입 교육입니다. 지금 받은 결과물을 이 표로 함께 점검해 보고 싶다면 상담 요청으로 상황을 적어 주셔도 됩니다.

지금 받은 보고에 답해 보면

가장 최근에 받은 '완료' 메시지를 하나 떠올리고 아래 질문에 답해 보세요.

• 그 메시지에 우리 직원 파일로 돌린 결과가 붙어 있었나요?
• 그 시스템에서 가장 권한이 낮은 사람의 계정으로 직접 들어가 본 사람이 우리 쪽에 있나요?
• 개발사가 말한 '성공'이 실행인지 적용인지 지금 대답할 수 있나요?
• 넣은 건수와 들어간 건수를 한 번이라도 나란히 놓고 본 적이 있나요?
• 바뀐 내용을 쓰는 사람이 어디서 알 수 있나요?

막히는 질문이 남아 있다면 잔금 날짜보다 검수 날짜를 먼저 정해 두세요.