AI 코딩 외주, 견적 요청부터 소스 인수까지 밟는 순서

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

“AI를 쓰면 개발비가 크게 줄어든다”는 설명만 믿고 계약했다가, 결과물이 기대와 다르거나 유지보수 비용이 더 커지는 사례가 적지 않습니다. AI 코딩 외주의 성패는 어떤 모델을 쓰느냐보다 발주 범위, 검수 기준, 계정 소유권을 얼마나 구체적으로 정했느냐에 달려 있습니다.

특히 짧은 일정과 낮은 견적만 비교하면 화면은 빠르게 나와도 실제 운영에 필요한 보안, 데이터 이전, 장애 대응이 빠질 수 있습니다. 견적 요청부터 소스 인수까지 아래 순서대로 확인하면 개발 지식이 많지 않아도 위험한 계약을 상당 부분 걸러낼 수 있습니다.

1. 견적을 받기 전에 만들 범위부터 한 장으로 고정합니다

아이디어가 아니라 사용자의 행동을 적습니다

“예약 앱을 만들어 주세요”처럼 결과물의 이름만 전달하면 업체마다 전혀 다른 범위로 견적을 냅니다. 첫 문서에는 서비스 설명보다 사용자가 가입하고, 검색하고, 결제하고, 알림을 받는 흐름을 순서대로 적는 편이 좋습니다. 관리자에게 필요한 승인·환불·통계 기능도 별도 사용자 행동으로 다뤄야 누락을 줄일 수 있습니다.

처음부터 모든 기능을 넣기보다 출시 필수 기능과 이후 추가 기능을 나누세요. 예를 들어 결제 기능이라도 카드 결제만 필요한지, 정기 결제와 부분 환불까지 필요한지에 따라 개발량이 달라집니다. 외부 API나 지도, 문자, 본인인증을 사용한다면 이용료를 누가 부담하는지도 이 단계에서 표시해야 합니다.

발주 문서는 길 필요가 없지만 판단 가능한 수준으로 구체적이어야 합니다. 아래 항목을 한 장에 채운 뒤 동일한 문서를 여러 업체에 전달해야 견적을 제대로 비교할 수 있습니다.

• 목표: 출시 후 사용자가 완료해야 할 핵심 행동 한 가지
• 사용자 유형: 일반 회원, 관리자, 판매자처럼 권한이 다른 주체
• 필수 화면: 로그인, 목록, 상세, 결제, 관리자 화면 등
• 연동 대상: 결제·지도·메일·문자·사내 시스템과 예상 호출량
• 제외 범위: 이번 계약에서 만들지 않을 기능과 지원하지 않을 환경
• 완료 기준: 배포 주소, 테스트 결과, 소스 저장소, 운영 문서의 제공 여부

견적서의 금액보다 먼저 볼 것은 “무엇을 만들지 않는다”는 문장입니다. 제외 범위가 비어 있으면 계약 후 추가 비용을 두고 해석이 엇갈릴 가능성이 큽니다.

2. 업체가 AI를 어디에 쓰는지 견적서에서 분리해 봅니다

생성 속도와 납품 품질을 같은 말로 받아들이지 않습니다

AI 코딩 도구는 화면 초안, 반복 코드, 테스트 데이터, 문서 작성 시간을 줄이는 데 유용합니다. 그러나 요구사항 판단, 아키텍처 선택, 보안 검토, 실제 장애 대응까지 자동으로 보장하지는 않습니다. “AI로 빠르게 개발한다”는 설명을 들었다면 어떤 작업을 자동화하고 어떤 작업을 사람이 검토하는지 물어보세요.

견적은 기획·디자인·개발·검수·배포·유지보수 항목으로 나눠 받아야 합니다. 소규모 웹 서비스는 기능 수와 품질 수준에 따라 수백만 원부터 수천만 원까지 차이가 날 수 있으므로, 단일 총액만으로 비싸고 저렴함을 판단하기 어렵습니다. 지나치게 낮은 금액에는 관리자 기능, 모바일 대응, 테스트, 클라우드 설정 또는 하자 보수가 빠져 있을 수 있습니다.

업체의 답변은 아래 질문으로 구체화할 수 있습니다. 모델 이름만 강조하고 검토 절차를 설명하지 못한다면 납품 후 수정 부담이 발주자에게 넘어올 가능성을 살펴야 합니다.

1. AI가 생성한 코드를 누가 리뷰하며 리뷰 기록을 남기는가?
2. 외부 코드와 오픈소스 패키지의 라이선스를 어떻게 확인하는가?
3. 고객 데이터와 비공개 요구사항을 AI 서비스에 입력하는가?
4. 자동 테스트와 사람이 수행하는 인수 테스트는 각각 무엇인가?
5. AI 도구 구독료와 API 사용료가 견적에 포함되어 있는가?
6. 특정 AI 모델을 사용할 수 없게 되면 대체 절차가 있는가?

보안 용어가 낯설다면 코드 보안의 기본 개념을 먼저 확인한 뒤 업체의 설명과 대조해도 좋습니다. 질문에 대한 답은 구두 약속으로 끝내지 말고 제안서나 계약 부속 문서에 기록해야 효력이 분명해집니다.

3. 계약서에는 결과물보다 소유권과 변경 규칙을 먼저 적습니다

계정·소스·데이터의 주인을 구분합니다

서비스가 정상적으로 열렸더라도 도메인, 클라우드, 앱스토어, 데이터베이스 계정이 개발사 명의라면 업체를 바꿀 때 문제가 생깁니다. 원칙적으로 운영에 필요한 주요 계정은 발주자 명의로 만들고, 개발사에는 작업 기간에 필요한 권한만 부여하는 방식이 안전합니다. 공동 계정을 쓰기보다 개인별 계정과 역할 기반 권한을 사용하는 편이 퇴사나 계약 종료에도 대응하기 쉽습니다.

소스코드의 저작재산권과 이용 범위도 확인해야 합니다. 기존에 업체가 보유한 공통 모듈, 새로 제작한 맞춤 코드, 오픈소스 패키지는 권리 관계가 서로 다를 수 있습니다. AI가 생성한 코드라고 해서 권리와 라이선스 문제가 자동으로 사라지는 것은 아니므로 사용한 주요 패키지 목록과 라이선스 고지를 납품물에 포함시키세요.

계약 중 기능이 바뀌는 상황을 대비해 변경 요청 절차도 적어야 합니다. 요청 한 건마다 일정과 비용 영향을 먼저 산정하고 승인 후 작업하도록 하면 “간단한 수정”을 둘러싼 분쟁을 줄일 수 있습니다.

• 명의 확인: 도메인, 호스팅, 클라우드, 결제대행, 이메일 발송 계정
• 권리 확인: 소스코드·디자인 원본·문서의 소유권과 재사용 가능 범위
• 비밀정보: AI 입력이 금지되는 자료와 로그 보관 기간
• 변경 관리: 추가 요청의 접수 방식, 사전 견적, 승인 책임자
• 중도 종료: 진행분 정산 기준과 소스·데이터를 돌려받는 방법
• 재위탁: 제3자 개발자나 해외 인력이 참여할 때의 통지 조건

발주자가 직접 로그인할 수 없는 운영 계정은 사실상 인수하지 못한 자산과 같습니다. 계약금 지급 전 계정 생성 주체부터 확정하세요.

4. 납품일이 오기 전에 테스트와 보안 통과선을 세웁니다

“작동한다”를 재현 가능한 문장으로 바꿉니다

검수 기준이 “요청한 기능이 정상 동작할 것”으로만 적혀 있으면 완료 여부를 객관적으로 판단하기 어렵습니다. 회원가입이라면 중복 이메일, 잘못된 인증번호, 비밀번호 재설정까지 시험해야 하고, 결제라면 성공뿐 아니라 실패·취소·중복 요청도 확인해야 합니다. 각 기능에 입력 조건, 수행 절차, 기대 결과를 붙이면 비개발자도 같은 테스트를 반복할 수 있습니다.

성능과 호환성 역시 수치로 정하세요. 지원할 브라우저와 모바일 화면 크기, 예상 동시 사용자 수, 주요 페이지의 목표 응답 시간, 장애 시 복구 목표를 합의할 수 있습니다. 실제 이용자가 100명인 서비스에 대규모 인프라를 요구할 필요는 없지만, 측정 기준 자체가 없다면 느린 화면이나 잦은 오류를 하자로 판정하기 어렵습니다.

보안 검수에서는 관리자 권한 분리, 비밀번호와 API 키 저장 방식, 개인정보 암호화, 의존성 취약점, 로그의 민감정보 노출을 확인하세요. 관련 개념은 코드 보안 요약 자료와 함께 살펴보면 질문을 만들기 쉽습니다. 단, 자동 진단 결과가 곧 안전을 의미하지는 않으므로 위험도가 높은 기능은 사람이 재검토해야 합니다.

• 핵심 사용자 흐름별 정상·실패·권한 없음 시나리오가 준비됐는가?
• 실제 운영과 분리된 검수 환경에서 테스트할 수 있는가?
• 오류가 발생했을 때 사용자 안내와 관리자 로그가 남는가?
• 비밀키가 소스 저장소나 브라우저 코드에 포함되지 않았는가?
• 백업을 실제로 복원해 보고 소요 시간을 기록했는가?
• 치명적·중요·경미 오류의 판정 기준과 수정 기한이 정해졌는가?

최종 검수만 기다리지 말고 기획 확정, 핵심 기능 완성, 운영 배포 전으로 나눠 중간 검수를 진행하세요. 중간 결과를 직접 눌러 보면 잘못 이해된 기능을 일찍 발견할 수 있고, 이미 완성된 구조를 뒤집는 비용도 줄어듭니다.

5. 소스 인수 전 30분짜리 운영 리허설을 실행합니다

개발사 없이 다시 배포할 수 있어야 인수가 끝납니다

압축 파일 하나를 받았다고 소스 인수가 완료되는 것은 아닙니다. 저장소의 최신 코드가 실제 운영 버전과 같은지, 새 환경에서 설치와 빌드가 되는지, 데이터베이스 구조 변경 방법이 문서화됐는지 확인해야 합니다. README에는 필요한 실행 환경, 환경변수 이름, 설치 명령, 테스트와 배포 절차가 포함되어야 합니다.

운영비도 인수 시점에 다시 계산하세요. 클라우드 서버, 데이터베이스, 파일 저장소, 문자·메일·지도·AI API는 사용량에 따라 매달 비용이 달라질 수 있습니다. 무료 체험이나 개발사 크레딧으로 가려진 비용이 없는지 확인하고, 평상시·사용량 3배·사용량 10배일 때의 월 예상액을 받아두면 예산 급증에 대비할 수 있습니다.

하자 보수와 유지보수는 같은 개념이 아닙니다. 계약한 기능이 기준대로 작동하지 않는 것은 하자에 가깝고, 운영 중 새 기능을 넣거나 외부 API 변경에 대응하는 작업은 유지보수로 분류될 수 있습니다. 무상 보수 기간, 접수 채널, 첫 응답 시간, 긴급 장애 기준, 시간당 또는 월정액 비용을 각각 적어 두세요.

1. 발주자 계정으로 저장소와 클라우드 관리 화면에 로그인합니다.
2. 최신 소스를 별도 환경에 내려받아 문서만 보고 실행합니다.
3. 테스트를 실행하고 실패 항목과 예외 처리 여부를 확인합니다.
4. 샘플 데이터를 백업한 뒤 복원하여 데이터가 유지되는지 봅니다.
5. 배포를 한 번 수행하고 이전 버전으로 되돌리는 절차도 시험합니다.
6. 개발사 권한을 제거해도 서비스 운영과 결제가 가능한지 점검합니다.

지금 바로 할 행동은 간단합니다. 빈 문서를 열어 ‘내가 반드시 소유해야 할 계정’이라는 제목을 쓰고 도메인, 클라우드, 소스 저장소, 데이터베이스, 결제대행, 외부 API 여섯 줄을 채워 보세요. 각 항목의 현재 명의와 로그인 가능 여부를 표시하는 30분 점검만으로도 AI 코딩 외주가 끝난 뒤 서비스 통제권을 잃는 가장 큰 위험을 먼저 발견할 수 있습니다.