AI 코딩 외주, 무엇을 양도 받아야 할까?

인수물은 “소스코드 ZIP 파일” 한 개가 아닙니다. 다음 담당자가 프로젝트를 내려받아 실행하고, 필요한 설정을 연결하고, 같은 서비스를 다시 배포할 수 있는 묶음이어야 합니다.

비밀키 값을 문서에 그대로 적을 필요는 없습니다. 중요한 것은 어떤 키가 필요한지, 어느 발주사 계정에서 관리하는지, 계약 종료 시 누가 교체할 수 있는지입니다.

특히 저장소, 클라우드, 도메인, 데이터베이스가 개발사 개인 계정에만 연결되어 있으면 계약이 끝난 뒤 작은 수정도 다시 개발사를 찾아야 할 수 있습니다.

인수의 기준은 파일을 받았는지가 아니라 발주사 또는 다음 담당자가 서비스를 재현할 수 있는가입니다.

AI가 생성한 코드도 일반적인 소프트웨어와 같은 기준으로 검수해야 합니다. 화면이 보이는 것만 확인하지 말고 회원가입, 로그인, 결제, 주문 수정, 권한 변경처럼 실제 데이터를 바꾸는 사용자 흐름을 끝까지 실행해야 합니다.

AI가 작성했다는 이유만으로 특별한 검수 기준을 낮추거나 높일 필요는 없습니다. 대신 생성 속도가 빨라진 만큼 연결 누락, 예외 처리, 권한 오류를 사용자 시나리오로 확인하는 것이 중요합니다.

검수는 새 기능이 동작하는지만 보는 것으로 끝내지 않는 편이 좋습니다. 새 기능 때문에 기존 기능이 깨지지 않았는지도 함께 확인해야 합니다.

LINE Engineering이 공개한 QA 사례에서도 Beta 환경에서는 새 기능 테스트를, RC 환경에서는 기존 기능까지 포함한 간단한 회귀 테스트를 수행했다고 설명합니다.

새로 만든 기능이 동작하는가? 그리고 그 기능 때문에 기존 로그인·검색·결제는 깨지지 않았는가?

외주 납품에서도 이 두 질문을 분리하면 인수 테스트와 회귀 테스트의 역할을 명확하게 나눌 수 있습니다.

챗봇, 분류, 추천, 문서 요약처럼 AI 기능이 포함된 서비스는 “답변이 그럴듯하다”만으로 검수하기 어렵습니다. 대표 입력과 기대 결과를 함께 정리해 두어야 모델이나 프롬프트를 바꾼 뒤에도 같은 기준으로 확인할 수 있습니다.

예를 들어 고객 문의 챗봇이라면 정상 질문, 애매한 질문, 답변하면 안 되는 질문, 외부 데이터가 없는 질문을 각각 준비할 수 있습니다.

최소한 다음 항목을 남겨두면 다음 모델 변경이나 프롬프트 수정 때 같은 조건으로 비교하기 쉽습니다.

정답이 하나로 정해져 있지는 않습니다. 중요한 것은 누가 배포할 수 있고, 누가 비밀키를 교체하며, 계약 종료 후에도 발주사가 통제권을 유지할 수 있는지를 계약에서 명확히 하는 것입니다.

OpenAI가 공개한 Codex 운영 사례도 접근 범위, 승인 정책, 자격 증명 관리, 작업 로그와 감사 기록을 중요한 통제 수단으로 설명합니다. 대규모 조직의 운영 방식이지만, 외주 프로젝트에서도 “누가 무엇을 할 수 있는지”와 “무엇을 했는지 기록이 남는지”를 확인하는 기준으로 참고할 수 있습니다.

개발사가 운영을 계속 맡더라도 발주사는 계정 소유권, 접근 권한, 종료 시 이전 절차를 알고 있나요?

관리형 운영을 맡기는 것과 운영 통제권을 완전히 넘기는 것은 다른 문제입니다.

서비스를 출시하면 버그, 정책 변경, 외부 API 변경과 운영 이슈가 계속 발생합니다. 그래서 인수 단계에서는 “누가 코드를 갖는가”뿐 아니라 문제가 생겼을 때 어떤 경로로 수정할지를 정해야 합니다.

아래 항목을 운영 규칙으로 남겨두면 유지보수 요청이 사람의 기억에만 의존하는 것을 줄일 수 있습니다.

유지보수 성과는 수정 건수보다 문제를 발견하고 원인을 찾고 안전하게 복구하는 과정이 반복 가능해졌는지로 보는 편이 실무적입니다.