고객이 안 사고 직접 만든다면?

최근 공개된 맥킨지의 2026년 'State of AI' 조사에서 눈에 걸린 숫자가 하나 있습니다.
응답 조직의 32%가 “에이전틱 코딩 도구로 직접 만들 수 있어서” 소프트웨어 제품이나 기능을 사지 않기로 했다는 것입니다.
이 흐름은 기술·헬스케어에서 특히 두드러졌고 전문 서비스, 에너지·소재가 뒤를 이었습니다.
소프트웨어를 파는 쪽이든 쓰는 쪽이든, 작은 팀이라면 그냥 지나치기 어려운 신호입니다.

왜 갑자기 '사지 말고 만들자'가 늘었을까?

코딩 에이전트가 '내부에서 그럭저럭 쓸 만한 것을 만드는' 비용을 크게 낮췄기 때문입니다.
예전에는 사내 도구 하나에 개발자 여러 명의 몇 달이 필요했지만, 지금은 실무자가 초안을 뽑고 개발자가 다듬는 방식이 가능해졌습니다.
그래서 구매 품의서가 올라가기 전에 “이거 우리가 만들면 안 되나?”라는 질문이 먼저 나옵니다.

같은 조사에서 하나 이상의 업무 영역에 에이전트를 확장 적용 중인 대형 조직 비중은 27%에서 40%로 올랐습니다.
반면 소규모 조직의 도입률은 22% 수준에서 사실상 제자리였습니다.
두 숫자를 나란히 놓으면 그림이 선명해집니다.
사람과 예산이 있는 쪽은 이미 '만들기'로 이동했고, 작은 조직은 아직 출발선에 서 있습니다.
격차가 벌어지는 구간이지만, 뒤집어 보면 아직 따라붙을 여지가 남아 있는 구간이기도 합니다.

또 하나 눈여겨볼 대목은, 같은 조사에서 전사 차원으로 가장 널리 확산된 AI 도구는 여전히 챗봇(47%)이고, AI 에이전트나 코딩 에이전트를 전사 규모로 확장한 곳은 열에 두 곳 남짓이라는 점입니다.
다시 말해 지금 벌어지는 일은 '모든 소프트웨어가 사라진다'가 아니라, 사내에서 급히 만든 도구가 구매 목록의 아랫단부터 잘라내고 있다는 쪽에 가깝습니다.
잘리는 건 대체로 단순 입력 폼, 리포트 자동 생성, 가벼운 알림 도구처럼 '기능 한 개짜리' 제품입니다.

고객이 직접 만들어버린다면, 우리는 무엇을 팔아야 할까?

화면과 기능만 묶어 파는 상품이 가장 먼저 대체됩니다.
반대로 고객이 혼자 감당하기 싫어하는 것, 즉 책임·운영·연결·검증은 오히려 값이 올라갑니다.
판매 단위를 '기능'에서 '결과와 유지'로 옮기는 것이 핵심입니다.

• 내재화 속도: “우리가 직접 만들겠다”는 고객에게 2주 스프린트로 첫 버전과 사내 작성 규칙 문서를 넘기고, 그 뒤 운영은 월정액으로 받는 구조.
• 책임과 운영: 장애 대응 시간, 로그 보관, 개인정보 처리 절차처럼 사내 초안 도구에는 대개 빠져 있는 부분.
• 연결: 결제·배송·세금계산서·예약 시스템처럼 고객이 직접 붙이기 번거로운 연동.
• 도메인 데이터: 업종별 문서 양식, 과거 상담 기록, 현장 용어집처럼 코딩 에이전트가 복제할 수 없는 자산.
• 검증: 배포 전 답변 품질 테스트셋과 결과 리포트. “만들 수 있다”와 “믿고 쓸 수 있다” 사이의 간격을 메우는 상품.

예를 들어 병원 예약 챗봇을 '챗봇 기능'으로 팔면 고객사 실무자가 주말에 비슷한 걸 만들어 옵니다.
대신 '노쇼 감소와 전화 응대 시간'을 매달 측정해 보고하는 계약으로 팔면, 고객이 스스로 만든 버전과 비교할 기준 자체가 우리 쪽에 남습니다.

실제로 제안 자리에서 “저희도 커서나 클로드 코드로 비슷한 걸 만들어 봤어요”라는 말을 듣는 빈도가 늘었다면, 그건 거절 신호가 아니라 대화의 출발점입니다.
그때 물어볼 질문은 세 가지입니다.
만든 걸 지금도 매일 쓰고 있는지, 고장 났을 때 누가 고쳤는지, 그리고 그 도구의 결과를 외부에 보여준 적이 있는지. 세 질문 모두에서 막히는 지점이 바로 우리가 팔 자리입니다.

그럼 우리 팀은 직접 만들까, 사서 쓸까?

기준은 '만들 수 있는가'가 아니라 '3년 동안 책임질 수 있는가'입니다.
코딩 에이전트 덕분에 첫 버전 제작비는 내려갔지만, 유지비와 사고 책임은 그대로 우리에게 남습니다.
다음 순서로 점검하면 대부분 답이 나옵니다.

1. 이 기능이 우리 차별화의 핵심인가?
   핵심이면 직접, 아니면 구매 쪽으로 기웁니다.
2. 틀렸을 때 손해가 돈·법으로 바로 이어지는가?
   결제, 세금, 개인정보는 검증된 제품을 쓰는 편이 쌉니다.
3. 한 달 안에 실제 업무에 투입할 수준이 되는가?
   안 되면 지금은 사고 나중에 다시 판단합니다.
4. 만든 사람이 팀을 떠나면 누가 고치는가?
   답이 없으면 만들지 않습니다.
5. 되돌릴 수 있는가?
   데이터 내보내기와 소스 보관을 먼저 확인합니다.

예를 들어 고객 문의를 우리 기준으로 분류하는 일은 맥락이 강해 직접 만들기 좋고, 전자세금계산서 발행은 규정이 촘촘해 사는 편이 낫습니다.
판단이 반반이면 “2주 안에 쓸 만한 게 나오면 직접, 아니면 산다”고 기한을 먼저 정해두세요.

사는 쪽이라면 체크리스트에 한 줄을 더 붙이세요.
직접 만든 도구에는 청구서가 안 오는 대신 시간 청구서가 옵니다.
매달 누가 몇 시간을 여기에 쓰는지 3개월만 기록해 보면, 구독료와 비교할 수 있는 숫자가 생깁니다.
이 기록이 없으면 '우리가 만들면 공짜'라는 착각에서 빠져나오기 어렵습니다.

정리하면 이번 조사의 메시지는 '개발이 공짜가 됐다'가 아니라 구매 결정의 기준선이 옮겨갔다는 쪽에 가깝습니다.
파는 팀은 기능 대신 결과와 유지를 팔고, 쓰는 팀은 제작비 대신 3년 유지비로 계산하면 됩니다.
이번 주에 진행 중인 구매 건 하나, 그리고 판매 제안서 하나를 이 기준으로 다시 읽어보는 것만으로 충분한 시작입니다.