다들 궁금하지만 묻기 애매한 질문

"개발사도 AI 쓰면서, 왜 견적은 그대로죠?" 발주자 입장에서 요즘 가장 궁금한 질문일 겁니다. 정당한 질문이고, 답부터 드리면 이렇습니다. 저희는 씁니다. 사전에 AI로 돌려 보고, 나온 결과를 사람이 크로스체크하고, 테스트까지 전부 진행합니다. 아래는 그 과정에서 정리된 기준입니다. 어디에 쓰고, 어디엔 맡기지 않는지.

쓰는 곳

구축된 시스템의 부분 수정. 이미 UI부터 백엔드까지 만들어진 시스템에서 일부를 고치거나 비슷한 기능을 변형해 만드는 일은 AI가 잘합니다. 예를 들어 게시판이 이미 있는 시스템에서 같은 구조의 게시판을 하나 더 만들거나 필드를 바꾸는 작업. 기존 코드의 패턴이 곧 지시서가 되기 때문입니다.

반복과 초안. 보일러플레이트 코드, 반복 패턴, 테스트 코드 초안, 문서 초안. 사람이 하면 지루하고 실수가 나는 영역은 AI가 더 잘합니다.

탐색. 낯선 라이브러리 검토, 레퍼런스 조사, 마이그레이션 같은 대량 단순 변환. 예전엔 하루 걸리던 조사가 한 시간으로 줄었습니다.

두 번째 눈. 작성한 코드의 빈틈을 다른 각도에서 훑는 리뷰 보조. 최종 판단은 아니지만, 놓친 것을 걸러 주는 그물로는 유효합니다.

안 쓰는 곳, 정확히는 맡기지 않는 곳

오해를 막기 위해 덧붙이면, 아래 영역에서도 AI를 안 돌리는 게 아닙니다. 여기서도 AI로 검증을 한 번 더 해 봅니다. 다만 결론을 맡기지 않을 뿐입니다. 마지막에는 반드시 사람이 체크하고, 테스트까지 거칩니다.

아키텍처 판단. 이 사업에 맞는 구조가 무엇인지는 요구사항 문서에 없는 맥락(예산, 팀, 운영 능력, 성장 계획)에서 나옵니다. AI는 맥락을 묻지 않고 그럴듯한 답부터 내놓습니다.

돈이 걸린 로직의 최종 검증. 결제, 정산, 재고. 그럴듯한 코드와 맞는 코드의 차이가 실제 돈으로 청구되는 영역은 사람이 끝까지 봅니다.

성능의 계측과 판단. AI는 일반론으로 최적화하지만, 실제 병목은 계측해야 나옵니다. 150만 명이 쓰는 서비스에서 배운 것은, 최적화는 코드가 아니라 측정에서 시작된다는 것입니다.

요구사항의 해석. 고객이 말한 것과 고객에게 필요한 것의 간극을 좁히는 일. 이게 사실 개발의 절반인데, 여기엔 AI가 낄 자리가 아직 없습니다.

그래서 견적은 싸지나요?

정직하게: 코드를 치는 시간은 분명히 줄었습니다. 그런데 그 시간이 어디로 갔느냐면, 검증과 엣지케이스로 재투자됐습니다. 같은 기간에 더 많은 실패 시나리오를 테스트하고, 더 넓은 범위를 커버합니다. AI의 배당은 할인율이 아니라 품질로 지급되고 있다는 게 저희의 견해입니다.

물론 단순 반복형 작업의 값은 실제로 내려가는 중이고, 내려가야 맞습니다. 그 값이 안 내려간 견적이 있다면 그건 물어봐야 할 항목입니다.

발주자를 위한 확인법

개발사에 이렇게 물어보십시오. "AI를 어디에 쓰시나요?" 구체적으로 답하면 신뢰해도 됩니다. 얼버무리면 의심하십시오. 그리고 "전혀 안 씁니다"라고 답한다면, 2026년에 그건 그것대로 걱정할 일입니다.