AI로 개발해 준다는 업체와 상담하다 보면 한 번쯤 이런 생각이 듭니다. "AI가 짰다는데, 그 결과는 누가 확인하는 걸까." "저희가 검토합니다"라는 답을 듣더라도, 그 말만으로는 무엇을 어떻게 검토하는지 알 수 없습니다.
이 연재의 1편에서는 AI에게 코드보다 설계 절차를 먼저 가르친 이야기를, 2편에서는 외주 전에 받아야 할 설계 문서 7가지를 다뤘습니다. 이번 3편은 그다음 단계입니다. 설계가 끝나고 실제로 만드는 동안, 결과를 누가 어떻게 검사하는가에 대한 이야기입니다. 이전에 다른 AI의 검토로 홈페이지 문제를 찾은 이야기를 쓴 적이 있는데, 이번 글은 찾은 문제 목록이 아니라 검사를 나누는 구조를 다룹니다.
저희는 통신 서비스 회사의 구매·자산 관리 시스템을 AI와 함께 만들고 있습니다. 2026년 8월 21일에 시작해 10월 1일 기준으로 213번째 작업 묶음을 마쳤습니다. 그 과정에서 사고가 날 때마다 검사 한 겹씩을 붙여 가며 만든 체계가 이 글의 재료입니다.
만든 쪽이 자기 결과를 검사하면 통과만 남습니다
한 사람 또는 AI 하나가 요구를 읽고 방법을 정하고 코드를 만들고 스스로 확인까지 하면 "확인했습니다"라는 말은 늘 나오지만 그 확인이 무엇을 봤는지는 남지 않습니다. 만든 쪽이 자기 결과를 검사하면 통과시키고 싶은 쪽으로 기울기 쉽습니다. 사람이든 AI든 다르지 않습니다.
그래서 역할을 여섯으로 나누고 각 역할이 할 수 없는 일을 정했습니다.
- 분석가는 요구를 읽고 선택지 2~3안을 냅니다. 결정하지 않습니다.
- 결정자는 기준에 따라 고르고 나중에 되돌릴 수 있게 이유를 기록합니다. 코드를 고치지 않습니다.
- 구현자는 결정된 것을 만듭니다. 설계하지 않습니다.
- 검수자는 작업 묶음을 닫기 전에 살펴보고 반려합니다. 고치지 않습니다. 고치는 순간 만드는 쪽이 되기 때문입니다.
- 실측자는 화면을 직접 눌러 보고 화면에서 본 것만 사실로 보고합니다.
- 기록자는 숫자를 계산하지 않고 받은 것을 그대로 적습니다.
한 문장으로 줄이면 이렇습니다. 분석가는 결정하지 않고, 결정자는 손대지 않고, 구현자는 설계하지 않고, 검수자는 고치지 않는다. 핵심은 역할 이름이 아니라 권한을 쪼갠 데 있습니다. 검수자가 고칠 수 있으면 "이 정도는 내가 고치고 통과시키자"가 되고 그 순간 검사는 사라집니다.
검사를 다섯 층으로 쌓은 이유
역할만 나눈다고 결함이 다 잡히지는 않아서 검사도 다섯 층으로 나눴습니다.
- 자동 점검 — 프로그램이 매번 자동으로 실행하는 검사입니다. 사람이 잊어도 실행됩니다.
- 시험 코드 — 정해진 입력에 정해진 결과가 나오는지 코드로 확인합니다.
- 문서와 숫자 대조 — 문서에 적힌 수치가 실제와 맞는지 봅니다. 코드가 바뀌어도 문서의 숫자는 저절로 바뀌지 않기 때문입니다.
- 화면 실측 — 사람처럼 화면을 직접 눌러 보는 것입니다. 앞의 세 층이 모두 통과해도 남는 결함을 잡는 층입니다.
- 역할을 나눈 검수 — 만들지 않은 쪽이 작업 묶음을 닫기 전에 살펴봅니다.
네 번째 층이 왜 필요한지 보여 준 일이 있습니다. 기능 시연 영상을 실제로 조작하며 녹화하던 중, 앞의 층이 모두 통과한 상태에서 결함 3건이 나왔습니다. 자동 점검과 시험 코드는 "정해진 대로 동작하는가"를 보지만 사람이 화면에서 순서대로 눌러 볼 때 생기는 일은 보지 못합니다.
첫 번째 층을 매 작업의 시작에 두게 된 데에도 사고가 있었습니다. 작업 폴더가 클라우드 동기화 폴더라서 자매 프로젝트에서 이미 게시한 결과물이 동기화 때문에 예전 상태로 되돌아간 일이 세 번 있었습니다. 그 뒤로는 무엇을 만들기 전에 자동 점검을 한 번 먼저 돌려 "지금 결과물이 맞는지"부터 확인합니다. 지금은 자동 점검 17종이 모두 통과 상태입니다.
검수자가 실제로 잡은 것
검수자가 작업 묶음을 닫기 전에 실제로 잡은 결함 하나를 적습니다.
장비를 폐기할 때 쓰는 품의 문서가 있습니다. 이 문서는 장비 줄이 하나라도 있으면, 머리 칸만 고쳐도 [저장]이 항상 실패했습니다. 원인은 문서 안에 들어 있는 자기 장비를 "이미 다른 문서에 들어간 장비"로 막고 있던 검사였습니다. 그 작업 묶음이 만든 결함이 아니라 이미 있던 결함이었는데, 검수자가 묶음을 닫기 전에 찾아냈습니다. 고친 것은 한 줄을 지운 것이고 같은 순서로 다시 해 보며 저장이 되는 것을 확인한 뒤에 닫았습니다.
눈여겨볼 점은 결함의 크기가 아니라 잡힌 자리입니다. 만든 쪽은 자기가 만든 부분만 보지만 검수자는 묶음 전체를 보기 때문에 그 묶음이 만들지 않은 결함도 걸립니다.
반대로 검수자에게 세 번 반려된 일도 있습니다. 검사 규칙 하나를 만들면서 몇 개 사례로만 확인하고 검수에 넘겼더니, 검수자는 대상 문서 전체를 세어 표본이 못 본 약 25%를 찾아냈습니다. 잘못 잡은 것이 47건 중 12건, 놓친 것이 53건 중 18건이었습니다. 검수 한 번에 5~10분이 걸려서 그 작업 묶음 하나에 30분 넘게 들었습니다. 그 뒤로 규칙을 하나 더 세웠습니다. 검사 규칙을 만들면 넘기기 전에 대상 전체에 돌려 "걸려야 할 것"과 "걸리면 안 되는 것" 양쪽을 손으로 대조한다. 몇 초면 끝나는 확인이 검수를 주고받는 것보다 시간이 훨씬 적게 듭니다.
비슷한 일이 숫자에서도 있었습니다. 작업 범위를 정하려고 급히 만든 계산으로 "37칸"이라 셌는데, 정식 검사로 세니 33~34칸이었습니다. 더 큰 문제는 숫자가 아니라 그 숫자로 내린 판단이었습니다. 지금은 범위를 정하는 숫자는 정식 검사를 통과한 것만 쓰고 정식 검사를 거치기 전의 값으로는 "열어 볼 가치가 있나"만 판단합니다.
반려는 사고가 아니라 기록입니다
작업 묶음 하나는 점검을 통과해야 닫힙니다. 검수자가 반려를 내면 그 묶음은 닫히지 않습니다.
반려가 많으면 나쁜 것처럼 보이지만 저희 기록은 그렇지 않았습니다. 어떤 작업 묶음은 검수 반려 21건을 모두 반영하고 닫혔습니다. 어떤 묶음은 반려 9건에서 재검수 2건, 3차에 0건으로 닫혔습니다. 반려 0건으로 한 번에 통과한 묶음도 여럿 있습니다. 반려 건수보다 몇 건이 나왔고 어떻게 줄었는지가 기록으로 남는다는 점이 중요합니다. 업체가 "다 검토했습니다"라고 말할 때, 이 기록이 있으면 보여 줄 수 있고 없으면 보여 줄 수 없습니다.
검사를 이렇게 쌓다 보면 부작용이 생깁니다. 문서 맞추기가 매번 통과 조건이면, 만드는 일만 하고 멈출 수가 없습니다. 그래서 개발과 마감을 나눴습니다. 평소에는 만드는 일에 집중하고 "마감"할 때만 문서와 숫자를 맞추고 전량 검사와 독립 검수를 둡니다. 검사를 없앤 것이 아니라 실행하는 시점을 옮긴 것입니다.
결함이 나올 때마다 검사 목록이 하나씩 늘어납니다
이 체계는 처음부터 설계한 것이 아닙니다. 결함이 하나 나오면 고치는 데서 끝내지 않고 같은 종류가 다시 나오지 않도록 검사를 하나 더했습니다. 이 글에 적은 일들도 그렇게 검사 목록에 들어갔습니다. 몇 개 사례만 보고 넘겼다가 반려된 뒤에는 "대상 전체에 돌려 양쪽을 대조한다"가, 급하게 센 숫자로 판단을 그르친 뒤에는 "정식 검사를 통과한 숫자만 쓴다"가, 결과물이 되돌아간 사고 뒤에는 "작업 시작 때 점검부터 한다"가 더해졌습니다. 지금 자동 점검은 17종이고 모두 통과 상태입니다.
검사 목록이 늘수록 같은 결함이 두 번 나오기 어려워집니다. 예전에는 이런 검사 목록을 따로 만들고 실제 개발에 붙이는 일 자체가 큰 작업이어서 전용 도구를 갖춘 곳이 아니면 하기 어려웠습니다. 지금은 AI가 검사를 빠르게 만들어 붙일 수 있어서 프로젝트에 맞는 검사를 필요할 때마다 늘릴 수 있습니다. 이렇게 검사를 늘려 가는 체계를 갖추면, 개발할수록 완성도가 높아집니다.
업체에 "누가 검사하나요?"를 구체적으로 묻는 법
"검사하시나요?"라고 물으면 모두 "네"라고 답합니다. 쪼개서 물으면 답이 달라집니다.
- 만든 사람과 검사하는 사람이 다른가요? 같은 사람 또는 같은 AI가 만들고 검사한다면, 검사는 형식에 가까워지기 쉽습니다.
- 검사하는 쪽이 코드를 고칠 수 있나요? 고칠 수 있으면 "고치고 통과"가 됩니다. 반려만 할 수 있는 역할이 있는지 묻습니다.
- 프로그램이 매번 자동으로 실행하는 검사가 있나요? 몇 종인가요? 사람이 잊어도 실행되는 검사가 있어야 합니다.
- 사람이 화면을 직접 눌러 보는 검사가 있나요? 자동 검사가 전부 통과해도 화면에서는 다른 일이 생깁니다.
- 문서에 적힌 숫자가 실제와 맞는지 확인하는 단계가 있나요? 코드가 바뀌어도 문서의 숫자는 저절로 따라오지 않습니다.
- 반려 기록을 보여 줄 수 있나요? 어떤 작업에서 몇 건이 반려됐고 어떻게 줄었는지, 기록이 있으면 보여 줄 수 있습니다.
- 작업 시작 전에 "지금 결과물이 맞는지"부터 확인하나요? 결과물이 되돌아가는 사고는 만들기 전에 잡아야 합니다.
모두 "예"여야 좋은 업체라는 뜻은 아닙니다. 다만 "누가 검사하나요?"에 역할과 기록으로 답할 수 있는지는 프로젝트 크기와 무관하게 볼 수 있는 지점입니다.
다음 4편에서는 업무 흐름이 끊긴 곳을 반복 점검으로 찾아낸 이야기를 다룹니다.