AI로 개발비가 싸지면, 만들기 전에 물을 4가지
미국 CIO 기고(10월 7일)는 엔지니어 2명이 AI 에이전트와 약 2개월 만에 4만 줄 규모의 저장소를 만든 사례를 들며, 싸게 만든 소프트웨어일수록 주인과 끝나는 날을 먼저 정하라고 해요. 기업 AI 도입 사례 3건과 만들기 전 질문 4가지를 정리했어요.

📰 2026년 10월 12일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.
짧게 먼저 정리할게요. 미국 IT 매체 CIO가 10월 7일 실은 기고는 AI 덕분에 소프트웨어를 만드는 값이 내려가면서 고민의 자리가 바뀌었다고 봐요. 예전에는 개발자를 구하는 게 문제였다면 이제는 만들어진 것을 누가 관리하느냐가 문제라는 거예요. 기고자가 권하는 건 단순해요. 만들기 전에 주인과 끝나는 날부터 정하라는 거예요.
“요즘은 AI로 금방 만든다던데, 굳이 사서 쓰거나 외주를 줄 필요가 있나요.”
발주를 준비하는 분들이 요즘 많이 하는 질문이에요. 틀린 말은 아니에요. 만드는 속도는 실제로 빨라졌어요. 다만 이번 기고는 그다음 장면을 물어요. 그렇게 만든 프로그램이 열 개, 백 개가 되면 누가 지키나요.
1. 기고는 무엇이 달라졌다고 봤나요

기고자 앨런 다브레는 14년 넘게 대기업의 위험 관리와 통제 업무를 해 온 사람이에요. 그래서 시선이 개발 속도보다 관리 쪽에 가 있어요.
핵심 문장은 이거예요. 회사의 IT를 책임지는 임원(CIO)의 문제가 “개발자를 찾는 일에서, 만들어지는 것을 통제하는 일로” 옮겨 간다고요.
지금까지 회사에 프로그램이 새로 들어오려면 문을 거쳐야 했어요. 구매 요청을 올리고, 보안 검토를 받고, 예산 승인을 받았죠. 통제 절차는 이 문을 전제로 짜여 있어요. 그런데 직원이 AI로 직접 만든 프로그램에는 그 문이 없어요. 기고자의 표현으로는 “AI가 만든 소프트웨어에는 접수 창구가 없다”예요.
2. 실제로 얼마나 싸고 빨라졌나요

기고에는 사례 세 건이 나와요. 모두 다른 매체 보도를 인용한 거예요.
| 회사 | 무슨 일이 있었나요 | 기고가 인용한 출처 |
|---|---|---|
| Perplexity | 엔지니어 2명이 AI 코딩 에이전트 수백 개와 약 2개월 만에 약 4만 줄 규모의 데이터 저장소를 만들어 검색 트래픽 일부를 처리해요. 읽기 지연 중간값이 80% 넘게 줄었고, 기존 클라우드 서비스보다 비용이 최소 20% 줄 걸로 예상한대요 | The New Stack |
| Payhawk | 연 7만 달러짜리 상용 성과 관리 제품을 AI로 직접 만든 프로그램으로 바꿨어요 | Computerworld |
| Starbucks | 소프트웨어에 연 약 4억 달러를 쓰는데, 일부를 자체 시스템으로 바꾸는 걸 시험 중이고 2027년 말까지 내놓을 수 있대요 | Fortune(Bloomberg 인용) |
(출처: CIO, 2026년 10월 7일 기고. 수치는 기고가 인용한 각 매체 보도 기준이에요.)
숫자만 보면 “사서 쓸 이유가 없네”라는 결론이 나오기 쉬워요. 그런데 기고자는 첫 사례에 단서를 달았어요. 지연 시간 비교는 조건을 맞춘 실험이 아니었고, 직접 만든 저장소를 유지하는 비용은 계산에서 빠졌다는 거예요. 그리고 이렇게 적어요. 에이전트는 일을 빠르게 했을 뿐 그 뒤의 판단을 대신하지는 않았다고요.
기업 AI 도입 사례를 읽을 때 저희가 늘 먼저 찾는 줄도 이 대목이에요. 만든 값 옆에 지키는 값이 적혀 있는지요.
3. 싸게 만들면 왜 문제가 생기나요

기고가 짚은 문제는 세 가지예요.
- 끝내는 사람이 없어요. 만든 사람은 있는데 “이제 그만 쓰자”고 정할 사람이 없어요. 만든 직원이 부서를 옮기면 프로그램은 그대로 돌아가요
- 이미 있는 걸 또 만들어요. 옆 팀이 만든 도구를 찾는 것보다 새로 만드는 게 빨라졌어요. 같은 일을 하는 도구가 여러 개 생겨요
- 검토가 못 따라가요. 검토받지 않은 프로그램이 느는 속도가 통제 절차의 처리 속도보다 빨라요
기고자는 이걸 저장 장치와 클라우드가 싸졌을 때와 견줘요. 값이 내려가니 누구나 서버를 띄웠고, 몇 년 뒤 회사들은 누가 띄웠는지 모르는 서버 요금을 내고 있었죠. 소프트웨어도 같은 길을 갈 수 있다는 거예요.
용어 정리 — 섀도 IT는 IT 부서의 승인 없이 현업이 따로 들여와 쓰는 프로그램이나 서비스를 말해요. 예전에는 몰래 가입한 외부 서비스가 주였는데, 이제는 직원이 AI로 직접 만든 도구까지 포함해요. 실무에선 “누가 만들었고 어떤 데이터를 쓰는지 아무도 모르는 프로그램”을 통틀어 이렇게 불러요.
4. 만들기 전에 무엇을 물어야 하나요

기고 본문에는 새로 만들기 전에 던질 질문이 네 개 나와요.
- 꼭 만들어야 하나요
- 이미 있는 건 아닌가요
- 누가 주인인가요
- 만든 사람이 떠나면 어떻게 되나요
여기에 기고자가 붙인 실행 방법이 하나 있어요. 프로그램을 만드는 그 시점에 관리 담당자와 만료일을 같이 적으라는 거예요. 만료일이 되면 계속 쓸지 끌지를 다시 정해요.
이 질문은 사내 도구에만 해당하지 않아요. 외주로 만드는 프로그램에도 그대로 쓸 수 있어요. 3번과 4번을 계약 전에 확인하는 방법은 지금 개발사와 헤어져도 서비스가 돌까요 | 계약 전 확인할 6가지에 정리해 뒀어요.
5. 사서 쓸지 만들지는 어떻게 다시 따져야 하나요

만드는 값이 내려가면 “사서 쓸까, 만들까”의 저울이 만드는 쪽으로 기울어요. 다만 저울에 올릴 추가 하나 더 있어요.
| 예전에 비교하던 것 | 이제 같이 비교할 것 |
|---|---|
| 구독료 대 개발비 | 구독료 대 개발비 + 몇 년치 관리 인력 |
| 기능이 맞는가 | 고장 났을 때 누가 몇 시간 안에 고치나 |
| 도입 기간 | 보안 패치와 외부 서비스 변경을 누가 따라가나 |
| 초기 비용 | 끝낼 때 데이터를 어떻게 옮기나 |
(자사 실무 기준이에요.)
AI 에이전트 도입을 검토하는 회사에도 같은 표를 권해요. 에이전트가 프로그램을 만들어 주는 시대라고 해도, 운영 환경에 올라간 뒤의 책임은 사람에게 남아요. 기고자도 핵심 시스템은 숙련된 엔지니어가 구조와 운영 책임을 쥐어야 한다고 적었어요. 고객 관리 프로그램을 예로 든 비교는 CRM, 직접 만들까 솔루션을 쓸까를 참고하세요.
6. 외주를 맡길 때는 무엇이 달라지나요

개발사도 AI로 코드를 써요. 그래서 발주자가 물어야 할 질문이 조금 바뀌었어요.
- 견적이 내려갔다면 무엇이 빠져서 내려갔는지 물어보세요. 코드를 쓰는 시간은 줄어도 검증, 문서, 인수인계에 드는 시간은 그만큼 줄지 않아요
- AI가 쓴 코드를 누가 읽고 확인했는지 산출물에 남는지 확인하세요
- 납품 뒤 고칠 수 있는 사람이 누구인지 계약서에 적으세요
흔한 실수 만드는 값만 비교하는 거예요. AI로 싸게 만든 견적과 예전 방식의 견적을 총액으로만 놓으면 싼 쪽이 이겨요. 검증과 인수인계가 포함됐는지까지 맞춰 놓아야 같은 물건을 비교하는 게 돼요.
AI가 쓴 코드의 확인 책임을 계약서에 적는 방법은 AI가 보낸 코드, 누가 확인하나요 | 계약서 6가지에, 개발비 뒤에 나가는 돈은 개발 외주 3년 총비용에 있어요.
7. 직접 만들고 운영해 본 쪽에서 보면요

저희는 자체 SaaS 4종을 직접 운영해요. 운영하면서 배운 건 만드는 날보다 그다음 날들이 훨씬 길다는 거예요. 기능 하나를 붙이는 데 며칠이 걸렸다면, 그 기능을 지키는 일은 서비스가 살아 있는 내내 이어져요.
그래서 이번 기고의 네 질문 가운데 저희 눈에 가장 크게 들어온 건 4번이에요. 만든 사람이 떠나면 어떻게 되나요. AI 덕분에 혼자서도 프로그램을 만들 수 있게 됐다는 건, 혼자만 아는 프로그램이 그만큼 늘어난다는 뜻이기도 해요.
사내에서 AI로 도구를 만들기 시작한 회사라면 이번 주에 해 볼 만한 일이 있어요.
- 지금 돌아가는 사내 도구를 목록으로 적어요. 정식 시스템 말고 엑셀 매크로, 자동화 흐름, 직원이 만든 스크립트까지요
- 줄마다 담당자와 다시 볼 날짜를 적어요
- 담당자 칸이 비는 줄부터 끌지, 맡길지 정해요
8. 자주 묻는 질문 (FAQ)
AI로 직접 만들면 외주보다 싸게 끝나나요?
만드는 값은 내려가는 추세예요. 다만 기고의 사례도 유지 비용은 계산에서 빠져 있었어요. 만드는 값과 몇 년치 관리 인력을 같이 놓아야 실제 차이가 보여요. 단계별 예산은 AI 도입 비용 가이드를 참고하세요.
AI 플랫폼 도입 전에 PoC에서 뭘 확인해야 하나요?
기능과 함께 그 결과물을 누가 맡는지 확인하세요. 관리 담당자와 중단 기준을 PoC 계획서에 함께 적어 두면 안전해요. PoC 예산은 AI PoC 비용 가이드에 있어요.
직원이 AI로 만든 사내 도구는 어떻게 관리하나요?
막기보다 등록하게 하세요. 무엇을 하는지, 어떤 데이터를 쓰는지, 담당자, 다시 볼 날짜 네 줄이면 목록이 생겨요.
9. 마무리
기고의 결론은 이래요. 소프트웨어가 싸고 흔해지는 시대에는 얼마나 빨리 만드느냐보다 무엇을 남기고 무엇을 끌지 정하는 힘이 회사의 실력이 된다고요. 예산과 인력, 관리 책임을 묶어서 경영진이 다룰 주제라는 말도 덧붙였어요.
저희는 10년 넘게 50개 이상의 프로젝트를 만들었고, 롯데·캐논 같은 곳과도 함께해 왔어요. 만드는 일보다 넘겨받고 지키는 일이 더 오래 걸린다는 걸 그 과정에서 배웠어요. 직접 만들지, 사서 쓸지, 맡길지 갈림길에 서 있다면 3년 뒤에 누가 관리할지부터 같이 따져 볼까요 →