AI가 개발비를 낮춘 시대, 다시 보는 Build vs Buy

Kevin Goldsmith의 「Build vs Buy When Building Just Got Cheap」(2026)을 바탕으로 핵심 논지를 한국의 기술 조직 관점에서 재구성한 해설입니다. 원문의 전체 번역이 아니라 주요 주장과 사례를 요약·의역한 기술 블로그입니다.

한 줄 요약

생성형 AI와 코딩 에이전트는 소프트웨어를 처음 만드는 비용을 크게 낮췄습니다. 그러나 보안 패치, 장애 대응, 규제 준수, 담당자 교체, 기능 확장과 같은 한번 만든 소프트웨어를 계속 소유하는 비용까지 없애지는 못했습니다. 따라서 Build vs Buy의 핵심 질문은 "어느 쪽이 지금 더 싼가?"가 아니라 **"우리가 앞으로 무엇을 계속 책임질 것인가?"**가 되어야 합니다.

1. AI가 바꾼 것은 '제작비'다

과거에는 CRM, 프로젝트 관리 도구, 내부 관리자 화면, 리포팅 시스템 등을 직접 만드는 일이 일정 규모 이하의 기업에서는 경제적으로 성립하기 어려웠습니다. SaaS 라이선스를 구매하는 편이 개발자를 장기간 투입하는 것보다 합리적이었기 때문입니다.

AI 코딩 도구의 확산은 이 계산식을 바꾸고 있습니다. 예전에는 수개월이 걸리던 내부 도구의 프로토타입을 며칠 또는 몇 주 안에 구현할 수 있고, 소수 개발자가 더 넓은 범위의 기능을 만들 수 있습니다. 따라서 과거보다 Build가 실제 선택지가 되는 영역은 분명히 넓어졌습니다.

하지만 Goldsmith가 강조하는 것은 이 변화의 범위입니다. AI가 크게 낮춘 것은 초기 구현 비용이지, 운영 책임 전체가 아닙니다. [1]

2. "만드는 비용"과 "만들어 놓은 뒤의 비용"을 분리해야 한다

직접 구축의 경제성을 판단할 때 흔히 다음과 같이 비교합니다.

• SaaS: 연간 라이선스 비용
• 자체 구축: 개발자 몇 명 × 몇 주 + AI 토큰 비용

이 비교는 자체 구축을 지나치게 유리하게 보이게 만들 수 있습니다. 실제 총소유비용(TCO)에는 초기 개발 외에도 유지보수, 보안 업데이트, CVE 대응, 온콜, 장애 처리, 컴플라이언스 증빙, 담당자 퇴사 후 인수인계, 재개발 등이 포함됩니다. [1]

따라서 비교 단위는 초기 구축비 vs 연간 구독료가 아니라 3~5년 총소유비용 vs 3~5년 구매·통합비용이어야 합니다.

간단한 TCO 사고방식

Build TCO
= 초기 구축 + 연간 유지보수 + 보안/패치 + 장애대응 + 규제준수 + 인수인계/재개발 비용

Buy TCO
= 라이선스 + 도입/설정 + 통합 + 벤더 관리 + 전환 비용

특히 보안이나 규제 대응이 중요한 시스템에서는 라이선스 비용의 일부가 사실상 위험과 운영 책임을 전문 벤더에게 이전하는 비용이라고 볼 수 있습니다.

3. 인증 시스템 사례가 보여주는 함정

Goldsmith는 초기 B2B 스타트업에서 인증 기능을 상용 솔루션 대신 오픈소스 기반으로 구축했던 경험을 소개합니다. 초기 확장 개발은 예상한 일정에 거의 맞았지만, 이후 지속적인 보안 업데이트와 고객 요구 기능 추가, 엔터프라이즈 고객의 보안 검토 대응이 뒤따랐습니다. 결국 절감한 라이선스 비용은 개발 시간과 기회비용으로 되돌아왔고, 회사는 이후 상용 솔루션으로 이전했습니다. [1]

이 사례의 핵심은 "오픈소스가 나쁘다"가 아닙니다. 보안 핵심 기능을 직접 소유하는 순간 코드뿐 아니라 지속적인 책임도 함께 소유하게 된다는 점입니다.

4. Build 전에 반드시 물어야 할 네 가지 질문

Goldsmith는 비용 중심 논의에서 벗어나기 위해 네 가지 판단 기준을 제시합니다. [1]

① Blast Radius --- 실패 영향범위

이 시스템이 중단되거나 침해되면 무엇이 멈추는가?

내부 대시보드 장애와 인증 시스템 침해는 같은 수준의 문제가 아닙니다. 영향범위가 크고 사업의 핵심 경로에 가까울수록 검증된 외부 솔루션을 선택할 이유가 커집니다.

② Ownership Cost --- 소유 비용

앞으로 몇 년간 누가 모니터링하고, 패치하고, 보안을 책임지고, 새벽 장애에 대응할 것인가?

중요한 것은 "개발팀이 합니다"가 아니라 책임자의 이름과 운영 프로세스를 구체적으로 말할 수 있는가입니다.

③ Differentiation --- 차별성

직접 구축함으로써 고객이나 사업이 체감할 수 있는 경쟁우위가 생기는가?

단지 내부 개발자가 선호하는 구조이거나 기존 제품보다 약간 편리한 정도라면 장기 유지보수 의무를 감수할 이유가 약합니다. 반대로 회사 고유의 업무방식이 생산성이나 고객가치에 직접 연결된다면 AI 시대에는 맞춤형 구축의 경제성이 과거보다 높아질 수 있습니다.

④ Exit Path --- 탈출경로

1년 뒤 더 좋은 상용 제품이나 공식 연동 기능이 등장했을 때 쉽게 버릴 수 있는가?

직접 구축을 **영구 시스템이 아니라 임시 다리(bridge)**로 설계하는 전략은 충분히 합리적입니다. 단, 시장에 적절한 대안이 나타났을 때 실제로 교체할 수 있도록 결합도를 낮춰야 합니다.

5. 직접 구축이 더 합리적이 된 영역

AI 시대에는 다음과 같은 영역에서 Build의 타당성이 이전보다 높아졌습니다.

• 규모가 작고 실패 영향범위가 제한된 내부 서비스
• 회사 고유 업무 프로세스에 맞춤화할수록 생산성이 크게 향상되는 도구
• 기존 시스템 사이를 연결하는 사내용 Glue/Integration 계층
• 아직 적절한 상용 제품이 없는 기능의 임시 Bridge
• 외부 라이브러리 하나를 추가하는 것보다 직접 구현이 더 단순한 소규모 기능

특히 공급망 보안 관점에서는 "외부 의존성을 추가하면 항상 더 안전하다"는 전제도 재검토할 필요가 있습니다. 작은 기능이라면 외부 패키지를 추가하지 않고 직접 구현하는 것이 공격 표면을 줄이는 선택이 될 수도 있습니다. 다만 이 경우에도 취약점 파악과 유지보수 책임은 내부에 남습니다. [1]

6. 여전히 Buy가 강한 영역

Goldsmith는 다음 영역의 판단 기준은 AI 이후에도 크게 달라지지 않았다고 봅니다. [1]

• 인증과 Identity
• 결제
• 고객 데이터의 핵심 저장·처리
• 서비스의 Critical Path
• 장애나 침해가 기업 존속 수준의 위험으로 이어지는 기능

이 영역에는 전문 업체가 수십~수백 명 규모의 조직으로 지속적인 보안·규제·운영 투자를 하고 있습니다. 몇 명의 개발자와 AI 도구만으로 동일한 책임 수준을 장기간 유지할 수 있다고 가정하는 것은 위험합니다.

7. MCP 사례: 잘 설계된 Build는 '버릴 수 있어야' 한다

원문에는 반대 방향의 성공 사례도 등장합니다. 회사에서 여러 업무를 자동화하기 위해 MCP 서버가 필요했지만 일부 벤더가 공식 서버를 제공하지 않아 내부적으로 API 기반 MCP 서버를 만들었습니다. 이후 공식 MCP 서버가 출시되자 내부 구현을 폐기하고 벤더 솔루션으로 이전했습니다. [1]

이 사례는 AI 시대 Build 전략의 중요한 원칙을 보여줍니다.

"필요해서 지금 만들되, 영원히 소유할 필요는 없다."

따라서 아키텍처 단계부터 API 경계, 데이터 포맷, 인증 계층, 교체 가능한 어댑터 구조 등을 고려해 Exit Cost를 낮추는 것이 중요합니다.

8. 실무 의사결정 매트릭스

판단 항목 Build 쪽 신호 Buy 쪽 신호

---

사업 차별성 고객가치·핵심 프로세스와 직접 연결 범용 기능 실패 영향범위 제한적 전사·고객 서비스에 치명적 보안/규제 낮거나 통제 가능 높은 규제·민감정보 내부 역량 장기 소유자와 운영체계 존재 특정 개발자 개인에게 의존 시장 성숙도 적합한 제품이 없음 검증된 전문 솔루션 다수 교체 가능성 쉽게 폐기·전환 가능 높은 결합도와 데이터 종속 3~5년 TCO 유지비 포함해도 우위 라이선스가 더 경제적

9. 기술 리더가 예산회의에서 바꿔야 할 질문

"우리가 직접 만들면 라이선스 비용을 얼마나 아낄 수 있는가?"보다 다음 질문이 유용합니다.

3년 뒤 취약점이 발견됐을 때 누가 이것을 패치할 것인가?

이 질문에 명확한 답이 없다면 아직 Build 결정을 내릴 준비가 되지 않은 것입니다.

또한 내부 도구를 분기별로 점검하면서 각 시스템에 대해 담당자, 취약점 탐지 방법, 패치 절차, 폐기 가능성을 확인하는 운영 프로세스를 두는 것이 좋습니다. [1]

10. 결론: 차별화해야 하는 것은 만들고, 작동하기만 하면 되는 것은 산다

AI는 Build vs Buy의 경계를 이동시켰습니다. 맞춤형 소프트웨어의 초기 개발비가 충분히 낮아지면서 과거에는 구매가 당연했던 일부 내부 도구와 통합 계층을 직접 만드는 것이 현실적인 전략이 되었습니다.

그러나 경계가 사라진 것은 아닙니다.

Build의 가격은 코드를 만드는 비용이 아니라 그 코드를 계속 책임지는 비용까지 포함해야 합니다.

따라서 AI 시대의 실무 원칙은 다음처럼 정리할 수 있습니다.

사업이 반드시 달라야 하는 영역은 Build하고, 사업이 안정적으로 작동하기만 하면 되는 영역은 Buy한다.
그리고 Build를 선택한다면 처음부터 소유자, 3~5년 TCO, 실패 영향범위, 탈출경로를 함께 설계해야 합니다.

---

참고문헌

1. Kevin Goldsmith, "Build vs Buy When Building Just Got Cheap: Ask Who Patches It in Year Three," It Depends: Lessons in Technology Leadership, 2026-08-23. https://kevingoldsmith.substack.com/p/build-vs-buy-when-building-just-got-cheap
2. Kevin Goldsmith, "Build vs Buy When Building Got Cheap," It Depends Podcast. 원문에서 확장 논의 자료로 소개됨.

작성 주

본 문서는 위 원문의 논지와 사례를 바탕으로 한국어 기술 블로그 형식으로 요약·의역하고, 실무 적용을 위한 TCO 및 의사결정 구조를 재구성한 글입니다. 원문의 문장 전체를 순차 번역한 자료가 아닙니다.