저는 개발사를 운영합니다. AI로 화면 초안과 반복 코드를 만드는 시간이 줄었다면, 그 일을 예전과 같은 공수로 견적 내는 건 맞지 않다고 봅니다. 개발사가 얻은 효율은 고객이 받는 가격에도 반영돼야 합니다.

제 견적서는 만들 기능을 작업 단위로 나누고, 지금 필요한 시간을 처음부터 다시 계산해 만듭니다. 예전에는 며칠로 잡던 구현이 AI 덕분에 빨라졌다면 다음 견적부터 예상 공수가 작아지는 방식입니다.

고객이 AI로 만든 데모나 소스코드를 가져오면 화면과 코드를 실제 제품에 얼마나 활용할 수 있는지 확인합니다. 그대로 쓸 부분, 손봐서 쓸 부분과 새로 만들 부분을 나누면 남은 작업만 다시 계산할 수 있습니다.

예전 공수표부터 바꿔야 합니다

외주 견적은 보통 요구사항을 기능과 작업으로 나눈 뒤 예상 시간, 참여 인력, 외부 비용과 위험을 더해 만듭니다. AI를 쓰기 시작하면 이 계산의 기준도 달라집니다.

로그인 화면, 관리자 목록, 데이터 변환 코드처럼 반복해서 만들어 온 작업은 전보다 빨리 끝낼 수 있습니다. 테스트 초안과 배포 문서도 AI가 상당 부분 도울 수 있습니다. 실제로 줄어든 시간을 예전 공수표에 그대로 남겨 둔다면 AI 활용으로 생긴 효율이 고객에게 전달되지 않습니다.

한국인공지능·소프트웨어산업협회가 공개한 2026년 사업대가 산정 템플릿은 예시 값을 그대로 쓰지 말고 사업 환경, 세부 내용과 외부 변수에 맞게 현행화하라고 안내합니다.[1] 이 자료가 모든 민간 외주 견적의 공식은 아니지만, 과거 기준을 현재 프로젝트에 그대로 대입해서는 안 된다는 점은 같습니다.

견적 단계에서 같은 범위와 납기, 검수 조건을 놓고 비교했는데 필요한 시간이 줄었다면 가격도 내려가는 것이 자연스럽습니다. 개발사가 AI를 얼마나 능숙하게 쓰는지도 결국 가격과 일정 경쟁에 반영됩니다.

고객이 가져온 데모는 먼저 실행해 봅니다

예약 등록과 목록 조회가 되는 데모를 고객이 가져왔다고 해보겠습니다. 개발사는 소스코드부터 확인합니다. 개발 환경에서 실행되는지, 실제 제품의 기술 구조에 넣어 쓸 수 있는지를 봅니다.

화면 링크만 있어도 입력 항목과 업무 흐름을 확정하는 시간은 줄어듭니다. 소스코드가 실제 저장소에서 빌드되고 기존 구조와도 맞는다면 화면 구현 공수까지 줄일 수 있습니다. 구조는 맞지만 손볼 부분이 있다면 처음부터 다시 만드는 대신 수정 시간만 계산합니다.

재사용 여부는 기능과 프로젝트 맥락, 코드 품질과 의존성을 확인한 뒤 결정합니다. GitHub의 현행 가이드는 AI 생성 코드에 자동 테스트와 정적 분석을 먼저 실행하도록 안내합니다.[2] 이 검토를 마치면 그대로 사용, 손봐서 사용, 새로 개발을 나눌 수 있습니다.

예약 화면을 견적 항목으로 풀어보면

같은 예약 데모라도 견적서에서는 다음처럼 나뉩니다.

견적 항목데모에서 확인할 내용견적에 반영하는 방법
화면 구성과 입력 항목실제 업무 흐름이 맞는가확정됐다면 기획·화면 설계 시간을 줄임
화면 코드제품 저장소에서 빌드되고 구조가 맞는가그대로 쓰거나 수정 시간만 반영
회원과 권한지점별로 볼 수 있는 정보가 구분되는가없으면 새로 개발
동시 예약마지막 한 자리를 두 명이 누르면 한 건만 확정되는가시험하지 않았다면 구현·검증 시간 반영
결제 실패결제 뒤 예약 저장이 실패하면 어떻게 처리하는가업무 규칙부터 정하고 개발
기존 데이터변환, 대조와 재실행 방법이 있는가준비되지 않았다면 이관 작업 반영
배포와 복구운영 환경 배포와 이전 버전 복구가 되는가확인하지 않았다면 작업에 포함

이 표에서 화면 설계는 끝났지만 코드는 다시 만들어야 할 수도 있습니다. 반대로 화면은 다듬어야 해도 예약 처리 코드는 재사용할 수 있습니다. 데모 전체를 한 덩어리로 평가하지 않고 항목마다 남은 시간만 계산하는 이유입니다.

재사용 여부가 애매하면 짧게 확인하고 견적을 냅니다

소스코드를 실제 제품에 쓸 수 있을지 모르는 상태에서 바로 정액 견적을 내면 개발사는 실패 가능성까지 넉넉하게 잡게 됩니다. 고객은 이미 만든 결과가 왜 가격에 반영되지 않았는지 알기 어렵습니다.

이럴 때는 본계약 전에 짧은 기술 검증을 따로 진행할 수 있습니다. 개발사 환경에서 코드를 빌드하고, 실제 인증이나 데이터 API 하나를 연결하고, 동시 예약이나 결제 실패처럼 위험한 조건을 시험합니다. 그 결과로 파일과 기능을 그대로 사용, 손봐서 사용, 새로 개발로 구분합니다.

기술 검증을 마치면 어떤 부분을 다시 쓸 수 있는지 적은 판정표와 그 내용을 반영한 본계약 견적이 남아야 합니다.

계약 전과 계약 후는 계산이 다릅니다

여기서 다루는 대상은 계약 전 견적과 범위가 바뀌어 다시 내는 견적입니다. 이미 체결된 정액 계약은 합의한 범위와 금액을 따릅니다. 납기를 앞당기거나 범위를 넓히려면 양쪽이 변경 내용을 다시 합의합니다.

시간제로 실제 투입 시간을 청구하는 계약이라면 AI로 줄어든 구현 시간은 청구 시간에서도 빠집니다. 생성 결과를 검토하고 수정한 시간은 실제 투입분으로 기록하면 됩니다.

정액 계약은 계약 전에 합의한 범위와 금액을 기준으로 납품합니다. Microsoft Project Operations는 시간제 견적을 실제 사용량에 따라 청구하고, 정액 견적은 약정 금액으로 청구하는 방식으로 구분합니다.[3] 따라서 개발사가 견적 단계부터 AI 활용을 전제했다면 그 생산성은 계약 전 가격이나 납기에 미리 반영돼야 합니다.

같은 조건이라면 더 낮은 견적이 나와야 합니다

AI를 쓰고도 범위, 납기, 검수와 보증 조건이 모두 같은데 예전 견적을 그대로 제시한다면 개발사는 줄어든 시간이 어디에 반영됐는지 설명해야 합니다. 그 효율을 짧은 납기나 추가 기능으로 돌리기로 합의하지 않았다면, 작아진 공수만큼 가격을 다시 계산하는 편이 맞습니다.

고객은 총액만 보고 막연히 깎아 달라고 할 필요가 없습니다. 다음 내용을 견적서에서 확인하면 됩니다.

  • 데모에서 그대로 쓰는 화면과 코드는 무엇인가
  • 손봐서 쓸 부분에는 얼마나 시간이 필요한가
  • 다시 만드는 부분은 왜 재사용할 수 없는가
  • 재사용에 실패하면 어느 항목이 어떻게 바뀌는가
  • 납품 완료를 어떤 테스트와 산출물로 확인하는가

개발사도 AI를 사용했습니다라고만 적는 대신 그대로 사용, 손봐서 사용, 새로 개발을 구분해 보여 주는 편이 낫습니다. 그래야 고객은 낮아진 가격의 근거를 이해하고, 개발사는 남은 작업을 빠뜨리지 않고 설명할 수 있습니다.

AI가 개발 단가를 낮추는 일은 자연스럽습니다. 개발사는 줄어든 시간을 숨기기보다 더 낮은 견적과 빠른 납기로 경쟁해야 합니다. 이미 끝난 일은 빼고 남은 일만 계산하는 것. 앞으로의 외주 견적은 이 변화부터 반영해야 합니다.

출처