고객이 AI 코딩 도구로 하루 만에 예약 관리 화면을 만들었습니다. 목록이 보이고 등록 버튼도 작동합니다. 이 정도 속도라면 개발사 견적도 이전의 절반이나 10분의 1까지 내려가야 할 것처럼 보입니다.

정형화된 화면과 반복 코드를 만드는 비용은 실제로 내려갔습니다. 개발사가 AI를 사용해 줄인 시간을 모두 예전 공수로 청구한다면 고객이 가격을 의심하는 것이 당연합니다.

다만 하루 만에 나온 것은 대개 방향을 확인하는 데모입니다. 누가 어떤 데이터를 볼 수 있는지, 기존 회원과 결제를 어떻게 연결할지, 잘못 저장된 값을 어떻게 복구할지는 아직 결정되지 않았습니다. 외주 개발비가 얼마나 내려가야 하는지는 코딩 속도가 아니라 이 남은 작업의 비중에서 결정됩니다.

견적에서 코딩은 한 줄입니다

운영할 제품의 견적을 나누면 대체로 다음 작업이 들어갑니다.

  • 발견: 사용자, 업무 흐름, 완료 조건과 제외 범위 합의
  • 설계: 화면, 권한, 데이터 구조와 외부 시스템 경계 결정
  • 구현: 화면과 API, 반복 로직 작성
  • 통합: 결제, 인증, ERP와 기존 데이터 연결
  • 검증: 정상·오류·권한·모바일·성능·보안 확인
  • 운영: 배포, 모니터링, 백업, 복구와 인수인계

AI가 가장 직접적으로 줄이는 곳은 구현의 첫 초안과 기술 탐색입니다. 나머지 단계도 문서 정리와 테스트 초안에서 도움을 받을 수 있지만, 고객의 업무 규칙을 확정하고 실제 시스템에서 결과를 승인하는 책임까지 대신하지는 않습니다.

저는 견적서에 AI 개발이라는 할인 항목을 하나 넣지 않습니다. 작업을 여섯 단계로 나누고, 재사용과 자동화로 줄어든 구현 시간을 실제로 제거합니다. 대신 통합·검증·운영을 코드 작성에 숨기지 않고 별도 항목으로 보여줍니다.

데모는 성공 경로 하나를 보여줍니다

예약을 등록하고 목록에서 확인하는 데모는 제품의 중요한 시작점입니다. 하지만 운영 환경에서는 같은 기능에 더 많은 질문이 붙습니다.

  • 이미 예약된 시간에 동시에 두 사람이 신청하면 어떻게 되는가
  • 관리자와 일반 사용자가 볼 수 있는 정보는 어디까지인가
  • 결제는 성공했는데 예약 저장이 실패하면 어떻게 복구하는가
  • 휴대전화와 오래된 브라우저에서도 같은 흐름이 가능한가
  • 기존 고객과 예약 이력은 어떤 규칙으로 옮기는가

데모는 이 질문을 발견하는 비용을 크게 줄여줍니다. 고객이 화면을 직접 보면서 필요 없는 기능을 빼고 빠진 흐름을 찾을 수 있기 때문입니다. 그러나 발견한 질문에 답하고 실제 데이터로 검증하는 일은 제품 단계의 비용으로 남습니다.

싸져야 하는 프로젝트는 분명히 있습니다

AI 도입 뒤에도 모든 견적이 그대로라면 설명이 부족합니다. 다음 조건이 많을수록 실제 가격은 내려갈 여지가 큽니다.

  • 신규 시스템이라 오래된 데이터와 복잡한 연동이 없음
  • 로그인, 목록, 등록처럼 표준 패턴의 비중이 큼
  • 완료 조건과 디자인이 이미 확정됨
  • 자동 테스트로 성공과 실패를 분명히 판정할 수 있음
  • 비슷한 구성 요소를 재사용할 수 있음

반대로 레거시 ERP 연동, 서로 다른 엑셀 데이터 이전, 복잡한 권한과 결제·정산처럼 실패 비용이 큰 기능은 첫 코드가 빨리 나와도 확인할 일이 많습니다. AI 할인율을 프로젝트 전체에 똑같이 적용하면 쉬운 작업은 여전히 비싸지고, 어려운 작업은 검증 예산이 부족해집니다.

저는 표준화된 관리 화면과 단순 자동화에서 생긴 절감분은 견적에서 빼는 편이 맞다고 봅니다. 고객이 같은 예산을 유지하려면 그 절감분을 모바일 대응, 자동 테스트, 데이터 정리나 운영 문서처럼 원래 빠지기 쉬운 품질 항목으로 돌릴 수 있습니다.

절감된 시간은 검증으로 이동하기도 합니다

AI는 작업을 시작하는 마찰을 줄이고 첫 코드를 빠르게 만듭니다. 다만 그렇게 아낀 시간은 결과를 감사하고 검증하는 쪽으로 다시 흘러갑니다. 2026년 공개된 사전 공개 연구에서 참가자의 82%가 코드 작성 시간이 줄었다고 답했지만, 업무의 중심은 AI 결과를 지시·평가·수정하는 감독 작업으로 이동했습니다.[1][2] 코딩 시간이 줄었다는 사실과 프로젝트 전체 시간이 같은 비율로 줄었다는 결론은 다릅니다.

보편적인 AI 생산성 향상률을 견적 공식으로 쓰기 어려운 이유도 여기에 있습니다. 최신 도구가 개발을 더 빠르게 할 가능성은 커졌지만, 2026년 측정 업데이트는 표본 선택과 측정 문제 때문에 신뢰할 만한 하나의 속도 향상률을 제시하지 못했습니다.[3]

그래서 저는 도구의 홍보 수치 대신 이 프로젝트에서 실제로 없어진 작업을 봅니다. 화면 초안이 사라졌는지, 테스트 작성 시간이 줄었는지, 아니면 생성한 후보를 다시 고르는 시간이 늘었는지를 작업별로 확인합니다.

AI 기능을 넣으면 새로운 운영비가 생깁니다

AI로 개발하는 프로젝트와 제품 안에 AI 기능을 넣는 프로젝트는 구분해야 합니다. 후자는 다음 비용이 추가될 수 있습니다.

  • 모델 API와 검색·저장 인프라 사용료
  • 정답 사례와 평가 세트 작성
  • 잘못된 답변과 실행을 막는 규칙
  • 모델·프롬프트 변경 때의 회귀 테스트
  • 장애나 한도 초과 때 사용할 대체 흐름
  • 입력·출력 기록과 개인정보 관리

챗봇 화면을 만드는 일은 빨라져도 답변 품질을 계속 측정하고 운영하는 비용은 새로 생깁니다. 초기 구축비만 낮추고 월 사용료와 평가·관리 비용을 빼면 고객은 출시 뒤에 실제 가격을 알게 됩니다.

견적에는 구축비와 월 운영비를 분리하고, 사용량이 늘 때 어떤 비용이 함께 커지는지 적어야 합니다. AI 기능을 쓰지 못하는 상황에서도 핵심 업무가 계속되는지도 범위에 포함합니다.

고객은 할인율보다 작업표를 확인할 수 있습니다

개발사가 AI를 쓴다는 이유만으로 무조건 싼 업체를 고르기는 어렵습니다. 반대로 AI를 쓰면서 가격은 그대로라는 설명만 받아들일 필요도 없습니다. 고객은 견적서에서 다음 내용을 확인할 수 있습니다.

  • 자동화와 재사용으로 빠진 작업은 무엇인가
  • 데모 이후 새로 확인할 데이터와 연동은 무엇인가
  • 검수할 정상·오류·권한 시나리오는 무엇인가
  • 구축비와 외부 서비스·월 운영비가 분리됐는가
  • 같은 예산이라면 절감 시간을 어떤 품질 항목에 썼는가

비교할 때는 개발사가 사용하는 AI 제품명보다 동일한 완료 조건을 기준으로 봅니다. 한 업체는 화면만, 다른 업체는 데이터 이전과 복구까지 포함했다면 금액 차이를 AI 실력으로만 설명할 수 없습니다.

개발비는 내려갈 수 있지만 책임까지 할인되지는 않습니다

AI 덕분에 첫 화면과 반복 구현은 분명히 싸지고 빨라졌습니다. 이 절감분은 고객에게 가격, 범위 또는 품질 개선의 형태로 돌아가야 합니다.

제가 견적에서 끝까지 남기는 것은 예전 방식의 코딩 공수가 아닙니다. 고객과 완료 조건을 합의하고, 실제 데이터와 외부 시스템에서 검증하고, 문제가 생겼을 때 복구할 수 있게 만드는 작업입니다. 이 항목도 자동화해 실제로 줄었다면 다음 견적에서 빼야 합니다.

하루 만에 나온 데모는 개발비가 곧 10분의 1이 된다는 증거가 아닙니다. 대신 어떤 구현이 이미 싸졌고, 제품으로 만들기 위해 무엇이 남았는지 대화할 수 있는 가장 좋은 시작점입니다.

출처