AI 개발팀의 교차 검증: 개별 테스트가 놓친 연결 오류

각자 검사한 코드의 연결 오류

상품 등록 화면을 개발하던 중, 별도 검토를 맡은 AI가 배포를 멈춰야 한다고 보고했다. 상품 분류를 조회하는 서비스와 그 결과를 받는 웹앱이 서로 다른 이름으로 데이터를 주고받고 있었다. 개별 기능 검사와 화면 검사에는 통과 기록이 있었지만, 두 프로그램을 연결한 검사에서는 분류 조회가 실패했다.

이 오류를 찾은 방식은 한쪽 프로그램의 출력을 다른 쪽에 직접 넣어 보는 것이었다. 여러 AI에게 나눠 맡긴 개발에서, 각 담당자가 확인한 범위 사이에 빠진 검사가 있었다.

나는 앞서 AI 팀 운영을 요청하면서 각자 의견을 내고 서로 검토한 뒤 실행하도록 요구했다. 이번 작업의 세부 배분과 검사 지시는 총괄 AI가 맡았다. 연결 오류를 재현한 방법도 검토 AI가 정했다. 여기서는 그 검토가 실제로 어떤 문제를 발견하고 배포 결정을 바꿨는지 다룬다.

검토 담당에게 준 자료와 범위

총괄 AI는 구현 담당 외에 검토 AI를 두었다. 검토자는 코드를 직접 수정하지 않고, 별도 복사본에서 검사했다. 구현 담당의 보고를 읽는 데서 끝내지 않도록 최종 소스와 배포할 파일 목록도 전달했다.

작업 중에는 코드가 계속 바뀌었다. 중간에 검사한 버전이 통과했더라도 그대로 배포할 수는 없었다. 총괄 AI는 최종 검사 대상을 확정한 뒤 다시 검토를 요청했고, 통과 전에는 운영에 반영하지 않도록 했다.

검토 AI에 맡긴 일	확인할 대상
구현 규칙 대조	서비스가 보내는 데이터와 웹앱이 요구하는 형식
별도 검사 실행	가격 입력·분류 선택·늦게 도착한 응답 등 실제 동작
최종 파일 대조	검사한 코드와 배포할 코드의 일치 여부
반영 가능 여부 보고	막힌 문제, 수정 필요 사항, 재검사 결과

외부 판매처에 실제 상품을 등록하거나 운영 데이터를 바꾸는 일은 검토 범위에서 제외했다. 별도 AI가 검사하되, 무엇을 읽고 어디까지 실행할 수 있는지 정해 둔 것이다.

같은 값을 다른 이름으로 주고받던 두 프로그램

분류 조회에는 Python 서비스와 JavaScript 웹앱이 연결되어 있었다. 조회 방식은 하위 분류 조회, 이름 검색, 특정 분류 확인의 세 가지였다.

문제는 응답에 담긴 항목 이름이었다. Python 쪽은 조회에 사용한 값을 모두 selector라는 이름으로 돌려줬다. 웹앱은 조회 방식에 따라 다른 이름을 요구했다.

조회 방식	서비스가 돌려준 항목	웹앱이 요구한 항목
하위 분류 조회	selector	parentId
이름 검색	selector	query
특정 분류 확인	selector	categoryId

검토 AI는 두 프로그램 사이에서 이 이름을 바꿔 주는 코드가 없다는 점도 확인했다. 값이 들어 있어도 웹앱은 예상한 항목을 찾지 못해 응답을 오류로 처리했다.

각 프로그램의 테스트가 사용한 가짜 응답도 서로 달랐다. 한쪽에서 준비한 응답으로 그쪽 코드만 검사하면 상대 프로그램과의 차이가 드러나지 않았다.

검토 AI는 실제 Python 서비스 코드가 만든 응답을 JavaScript의 응답 검사 코드에 전달했다. 세 조회 방식 모두 실패했다. 외부 판매처를 호출한 검사는 아니었다. 격리된 입력을 사용해 두 프로그램이 실제로 연결되는지 확인한 결과다.

검토 결과로 바뀐 배포 결정

검토 AI는 오류를 재현한 결과와 함께 배포 보류를 보고했다. 총괄 AI가 이를 받아들여 첫 빌드의 운영 반영을 멈추고, 서비스 구현 담당에게 수정을 맡겼다.

수정은 서비스가 조회 방식에 맞는 항목 이름을 돌려주도록 바꾸는 것이었다. 웹앱이 잘못된 응답도 받아들이도록 검사 조건을 완화하지는 않았다.

수정 뒤에는 세 판매처와 세 조회 방식의 조합, 총 아홉 경우를 다시 연결해 검사했다. 모두 통과했고, 이전의 잘못된 형식과 불완전한 응답은 계속 거부되는지도 확인했다. 검토자는 배포할 파일이 검사한 파일과 같은지 대조한 뒤 반영 가능하다고 보고했다.

당시 기록에서 확인되는 결과는 이 연결 오류가 있는 첫 빌드를 운영에 반영하지 않았다는 것이다. 검토 보고가 구현 담당의 수정과 재검사까지 이어졌다.

다른 작업에 적용할 검토 요청

이 사례에서 응용할 만한 지시는 “한 번 더 확인해”보다 구체적이다. 나눠 만든 기능 사이에서 무엇을 검사할지 정하고, 실패했을 때 어떤 결정을 멈출지도 함께 알려 준다.

아래는 당시 작업 방식을 다른 개발에 쓸 수 있도록 정리한 요청 예시다. 실제 대화의 인용문은 아니다.

구현 담당과 별도로 검토해 줘. 코드는 직접 수정하지 말고, 확정된 소스의 복사본에서 검사해.

A가 실제로 내보내는 데이터를 B에 넣어 확인해 줘. 양쪽 테스트가 따로 만든 가짜 응답에만 의존하지 말고, 서로 주고받는 항목과 오류 처리 조건을 비교해.

문제가 있으면 재현 방법과 함께 배포 보류를 보고해. 담당자가 수정한 뒤 같은 검사를 다시 하고, 검사한 파일과 배포할 파일이 같은지도 확인해 줘.

이 방법으로 AI 팀 전체의 성능이 더 좋아졌다고 단정할 수는 없다. 한 AI로 같은 일을 했을 때와 비교하지 않았고, 이후에는 화면 배치에 대한 불만도 나왔다. 이번 연결 검사가 화면 품질까지 보장한 것은 아니다.

다만 이 작업에서는 별도 검토자가 두 프로그램을 직접 연결해 검사한 덕분에, 개별 검사로 놓친 오류를 배포 전에 발견했다. 검토를 맡길 때 확인할 범위와 반영 조건을 함께 정한 사례로 남길 수 있다.

2026년 9월 16일 밤의 개발 세션과 당시 검토·배포 보고를 바탕으로 작성했다. 이 글을 쓰면서 운영 서버를 다시 검사한 것은 아니다.