*이 장을 다 읽고 나면 알게 될 것: Enterprise AI Agent 도입에서 Build와 Buy 사이의 판단을 좌우하는 7가지 변수가 무엇인지, 각 변수가 어떤 방향을 가리키는지, 그리고 실제 기업들이 이 판단을 어떻게 내렸고 어디서 실패했는지*
도입: 회의실의 90분
2024년 가을, 한 중견 제조기업의 회의실에 열두 명이 앉았다. CTO, CDO, 사업부장 세 명, IT팀장, 외부 컨설턴트 두 명, 그리고 나. 안건은 하나였다. 공정 품질 예측 AI를 직접 만들 것인가, SaaS 솔루션을 살 것인가.
90분 동안 회의가 진행되었다. CTO는 직접 만들자고 했다. 우리 데이터는 밖에 줄 수 없다. 사업부장 한 명은 사자고 했다. 6개월 안에 필요하다. CDO는 중간을 잡았다. 핵심은 만들고, 나머지는 사자. IT팀장은 조용했다. 현재 인력으로는 둘 다 어렵다는 표정이었다.
결론이 나지 않았다. 다음 주에 다시 모이기로 했다. 다음 주에도 결론이 나지 않았다. 한 달이 지났다. 그 사이 경쟁사가 비슷한 시스템을 먼저 도입했다는 소식이 들려왔다.
이것은 한 회사의 이야기가 아니다. 내가 데이터 분석 기반 컨설팅을 하면서 본 가장 흔한 장면이다. Build vs Buy는 기업 AI의 가장 중요한 첫 번째 결정이다. 그런데 대부분의 기업이 이 결정을 체계 없이 내린다. 감에 의존하거나, 목소리 큰 사람의 의견이 이기거나, 결정을 미루다가 시기를 놓친다.
체계가 필요하다. 이 장에서 나는 Build vs Buy를 판단하는 7가지 결정 변수를 제시한다. 이 프레임워크는 완벽하지 않다. 그러나 체계 없는 90분짜리 회의보다는 낫다.
15.1 첫 번째 Use Case는 학습 장치다
7가지 변수를 보기 전에, 한 가지 먼저 짚어야 할 것이 있다. 첫 번째 Use Case의 목적은 성과가 아니라 학습이다.
많은 기업이 AI Agent 도입의 첫 번째 프로젝트에서 큰 성과를 기대한다. ROI를 먼저 계산한다. 매출 증가, 비용 절감, 효율 향상. 숫자를 먼저 그린다. 그리고 그 숫자가 충분히 크지 않으면 프로젝트를 시작하지 않는다.
나는 이것이 틀렸다고 본다.
첫 번째 Use Case는 조직 전체가 AI Agent를 경험하는 학습 장치다. 개발팀은 기술을 배운다. 사업부는 가능성과 한계를 배운다. 경영진은 의사결정의 감각을 배운다. 이 학습이 없으면 두 번째, 세 번째 프로젝트에서 같은 실수를 반복한다.
그래서 좋은 첫 번째 Use Case의 조건은 이렇다.
범위가 작아야 한다. 3개월 안에 결과를 볼 수 있어야 한다. 실패해도 회사가 흔들리지 않아야 한다.
실패해도 배울 수 있어야 한다. 성공하면 좋다. 그러나 실패해도 조직이 무엇을 배웠는지 명확해야 한다. 데이터의 품질이 부족했는지, 내부 역량이 모자랐는지, 사용자 저항이 컸는지. 이런 것을 배우는 것 자체가 성과다.
관련 부서가 많아야 한다. 개발팀만의 프로젝트가 아니라, 사업부와 현장이 함께 참여해야 한다. 그래야 조직 전체가 배운다.
이 조건을 만족하는 Use Case를 찾았다면, 그다음이 Build vs Buy 결정이다. 그리고 이 결정을 체계적으로 하기 위해 7가지 변수를 본다.
잠시 멈추고 생각해보자
당신의 조직에서 AI 프로젝트를 처음 시작한다면, 가장 먼저 떠오르는 Use Case는 무엇인가? 그것은 학습 장치로서의 조건을 만족하는가, 아니면 너무 큰 것을 노리고 있는가?
15.2 변수 1 — 데이터 주권
7가지 변수 중 가장 먼저 봐야 할 것은 데이터 주권이다.
질문은 단순하다. 이 시스템이 다루는 데이터를 외부에 줄 수 있는가.
한국의 금융 회사를 보자. 고객의 거래 내역, 행동 데이터, 대출 이력. 이런 데이터를 외부 SaaS에 올릴 수 있는가. 대부분의 경우 불가능하다. 금융위원회 규정이 있다. 개인정보보호법이 있다. 그리고 무엇보다 고객의 신뢰가 있다.
반대로, 사내 회의록을 요약하는 시스템은 어떤가. 회의 내용이 민감할 수 있지만, 데이터 주권의 강도가 다르다. 외부 서비스를 쓸 수 있는 여지가 있다.
데이터 주권의 스펙트럼은 이렇다.
Build이 유리한 쪽. 고객 개인정보, 금융 데이터, 의료 데이터, 국방 데이터, 핵심 영업 비밀. 이런 데이터는 외부로 나가면 안 된다. 자체 인프라에서 처리해야 한다. 그러면 Build이다.
Buy가 유리한 쪽. 공개 데이터 기반 분석, 일반 업무 자동화, 마케팅 콘텐츠 생성, 고객 문의 응대. 민감도가 상대적으로 낮다. 외부 SaaS로 충분하다.
중간 지대. 데이터를 익명화하거나 집계해서 쓸 수 있는 경우. 원본은 내부에 두고, 가공된 데이터만 외부로 보내는 하이브리드 구조가 가능하다.
2025년 기준, 한국의 대기업 중 상당수가 데이터 주권을 이유로 Build을 선택한다. 그런데 여기서 흔한 실수가 있다. 데이터 주권을 핑계로 모든 것을 Build하려 한다. 사내 식당 메뉴 추천까지 자체 구축할 필요는 없다. 데이터 주권은 정밀하게 평가해야 한다. 과도하면 속도를 잃는다.
15.3 변수 2 — 차별화
두 번째 변수는 차별화다. 질문은 이것이다. 이 기능이 우리 회사의 경쟁 우위의 원천인가.
모든 기업에는 두 종류의 기능이 있다. 경쟁 우위를 만드는 핵심 기능과, 필요하지만 차별화와 무관한 범용 기능이다.
예를 들어보자. 한 물류 회사가 배송 경로 최적화 AI를 도입하려 한다. 배송 경로 최적화는 이 회사의 핵심 역량이다. 경쟁사보다 빠르고 정확하게 배송하는 것이 사업의 본질이다. 이런 기능은 Build이 맞다. 외부 솔루션을 쓰면 경쟁사도 같은 솔루션을 쓸 수 있다. 차별화가 사라진다.
반면, 같은 물류 회사의 HR 부서가 직원 면접 일정을 자동으로 잡는 AI를 도입하려 한다. 이것은 범용 기능이다. 차별화와 무관하다. 시장에 좋은 솔루션이 이미 있다. Buy가 맞다.
아마존의 사례가 좋은 참조점이다. 아마존은 물류와 추천 시스템에 천문학적 투자를 한다. 핵심 차별화 영역이기 때문이다. 그러나 사내 이메일은 자체 구축하지 않는다. 범용 기능이니까.
차별화 변수의 판단 기준은 이렇다.
Build이 유리한 쪽. 이 기능으로 고객이 우리를 선택한다. 경쟁사가 따라하기 어렵다. 이 기능의 성능이 1% 좋아지면 매출에 직접 영향을 준다.
Buy가 유리한 쪽. 모든 회사에 필요한 기능이다. 이 기능이 탁월해도 고객은 그것을 인지하지 못한다. 시장에 검증된 솔루션이 이미 있다.
한국의 한 대형 유통사가 고객 추천 시스템을 외부 솔루션으로 도입했다. 3년 후 경쟁사도 같은 솔루션을 도입했다. 추천의 품질이 같아졌다. 차별화가 사라졌다. 결국 자체 구축으로 전환했다. 3년의 시간과 이중 비용을 낭비한 셈이다.
잠시 멈추고 생각해보자
당신의 회사에서 AI를 도입하려는 기능이 핵심 차별화 영역인지, 범용 영역인지 구분할 수 있는가? 그 구분이 명확하지 않다면, 그것 자체가 전략의 부재를 의미하는 것은 아닌가?
15.4 변수 3 — 기술 역량
세 번째 변수는 기술 역량이다. 내부에 이것을 만들고 운영할 사람이 있는가.
이것은 단순히 개발자가 있느냐의 문제가 아니다. AI Agent를 만들고 운영하려면 최소한 세 가지 역할이 필요하다.
설계하는 사람. 비즈니스 문제를 AI 아키텍처로 번역할 수 있는 사람이다. 이 역할이 가장 희소하다. 코드를 짤 수 있는 사람은 많다. 그러나 비즈니스 맥락을 이해하면서 기술 설계를 할 수 있는 사람은 드물다.
만드는 사람. LLM, RAG, 벡터 DB, 오케스트레이션 프레임워크를 다룰 수 있는 엔지니어다. LangChain이나 LangGraph를 쓸 줄 아는 사람, pgvector나 ArangoDB를 다룰 줄 아는 사람. 2025년 기준으로 이런 인력의 시장 단가는 높다.
운영하는 사람. AI 시스템은 만드는 것보다 운영이 어렵다. 모델이 오래되면 성능이 떨어진다. 데이터 분포가 바뀌면 재학습이 필요하다. 장애가 나면 빠르게 복구해야 한다. MLOps 역량이 필요하다.
이 세 역할이 내부에 있으면 Build이 가능하다. 하나라도 없으면 위험하다.
Build이 유리한 쪽. 세 역할이 모두 있거나, 최소 설계와 운영 역량이 있고 개발은 외주 가능한 경우.
Buy가 유리한 쪽. 세 역할 중 하나도 내부에 없는 경우. 또는 있지만 다른 프로젝트에 묶여 있어 가용하지 않은 경우.
여기서 흔한 실수가 하나 있다. "지금은 없지만 뽑으면 된다"는 낙관이다. AI 인력을 뽑는 데는 시간이 걸린다. 좋은 사람일수록 오래 걸린다. 3개월 안에 시스템이 필요한데 6개월 뒤에 사람이 오면 의미가 없다. 그리고 한두 명을 뽑는다고 조직 역량이 되는 것도 아니다. 새로 온 사람이 기존 조직과 협업하는 데 또 시간이 걸린다.
글로벌에서도 같은 현상이 반복된다. 맥킨지의 2025년 조사에 따르면, AI 프로젝트 실패의 약 40%가 기술 인력 부족과 관련이 있다. Build을 선택했지만 인력이 따라오지 못해 프로젝트가 중단되는 경우다.
15.5 변수 4 — 속도
네 번째 변수는 속도다. 언제까지 필요한가.
이것은 단순하지만 강력한 변수다.
Build은 시간이 걸린다. 설계, 개발, 테스트, 배포, 안정화. 아무리 빨라도 3개월이다. 복잡한 시스템은 6개월에서 1년이다. 그 사이에 시장이 움직인다. 경쟁사가 먼저 도입한다. 고객의 기대가 바뀐다.
Buy는 빠르다. SaaS 솔루션은 계약하면 바로 쓸 수 있다. 커스터마이징이 필요해도 2~4주면 된다. 물론 조직에 안착시키는 데는 더 걸리지만, 최소한 시스템은 돌아간다.
Build이 유리한 쪽. 시간이 충분하다. 6개월~1년의 여유가 있다. 빠른 출시보다 장기적 품질이 중요하다.
Buy가 유리한 쪽. 지금 당장 필요하다. 경쟁사가 이미 도입했다. 3개월 안에 성과를 보여야 한다. 시장 기회의 창이 닫히고 있다.
여기서 주의할 점이 있다. 속도만 보고 Buy를 선택하면, 나중에 전환 비용이 크다. 급하게 도입한 외부 솔루션에 업무가 의존하게 되면, 나중에 자체 구축으로 바꾸고 싶어도 바꾸기 어렵다. 데이터가 외부에 쌓이고, 워크플로우가 그 솔루션에 맞춰지고, 사용자가 익숙해진다. 이것이 Lock-in이다. 7번째 변수에서 다시 다룬다.
잠시 멈추고 생각해보자
당신의 조직에서 "빨리 해야 한다"는 말이 나올 때, 그것은 진짜 시장의 압박인가, 아니면 내부 정치의 산물인가? 속도의 진짜 이유를 구분하지 못하면 잘못된 선택을 한다.
15.6 변수 5 — 비용
다섯 번째 변수는 비용이다. 그런데 비용은 단순하지 않다. 초기 비용과 장기 비용이 전혀 다른 방향을 가리키기 때문이다.
Build의 비용 구조는 이렇다. 초기에 크다. 인력 채용, 인프라 구축, 개발 기간의 인건비. 수억 원이 든다. 그러나 한번 만들면 추가 사용자당 비용이 거의 없다. 그리고 시간이 갈수록 총소유비용(TCO)이 낮아진다.
Buy의 비용 구조는 반대다. 초기에 작다. 월 구독료, 사용자당 요금. 시작은 가볍다. 그러나 사용자가 늘고 사용량이 늘면 비용이 선형으로 증가한다. 3년, 5년 단위로 보면 Build보다 비쌀 수 있다.
이것을 그래프로 그리면 X자 모양이 된다. 초기에는 Buy가 싸다. 어느 시점을 넘기면 Build이 싸진다. 그 교차점이 어디인가가 핵심이다.
교차점은 사용자 수, 사용량, 운영 기간에 따라 다르다. 일반적으로 이렇다.
사용자가 50명 이하이고 1~2년만 쓸 거라면, Buy가 거의 항상 싸다. 사용자가 500명 이상이고 3년 이상 쓸 거라면, Build이 싸질 가능성이 높다. 그 사이는 정밀한 계산이 필요하다.
Build이 유리한 쪽. 대규모 사용자, 장기 운영, 사용량이 많은 경우. 그리고 인프라가 이미 있어 추가 투자가 적은 경우.
Buy가 유리한 쪽. 소규모 사용자, 단기 또는 불확실한 운영 기간, 인프라가 없는 경우.
내가 본 실패 사례 중 하나가 여기에 해당한다. 한 중견기업이 AI 챗봇을 자체 구축했다. 사용자는 고객센터 상담원 30명이었다. 개발에 8억 원이 들었다. 3년간 운영 비용이 추가로 들어갔다. 같은 기간 동안 외부 SaaS를 썼으면 연간 1억 원 남짓이었다. 3년이면 3억 원. 차이가 컸다. 사용자 규모를 무시하고 Build을 선택한 대가였다.
15.7 변수 6 — 통합 복잡도
여섯 번째 변수는 통합 복잡도다. 기존 시스템과 얼마나 깊이 연결해야 하는가.
기업의 IT 환경은 레고 블록이 아니다. 오래된 ERP, 커스터마이즈된 CRM, 자체 개발한 생산관리 시스템, 10년 된 데이터베이스. 이것들이 복잡하게 얽혀 있다. 새 AI 시스템은 이 기존 환경과 대화해야 한다.
통합 복잡도가 낮으면 Buy가 쉽다. 독립적으로 작동하는 시스템, 표준 API로 연결되는 시스템, 기존 환경과 거의 무관한 시스템. 이런 경우 외부 솔루션을 붙이기 쉽다.
통합 복잡도가 높으면 Build이 유리하다. 기존 데이터베이스의 깊숙한 곳에서 실시간 데이터를 가져와야 하는 경우. 여러 시스템의 데이터를 조합해야 하는 경우. 기존 워크플로우의 중간에 AI를 끼워 넣어야 하는 경우. 이런 상황에서 외부 솔루션은 한계가 있다. 커스터마이징 비용이 Build 비용을 초과하는 경우도 있다.
한국의 대기업 중 제조업에서 이 문제가 특히 심하다. 공장의 MES(제조실행시스템)는 20년 전에 구축된 것이 많다. API가 없다. 데이터 형식이 표준화되지 않았다. 이런 환경에 외부 AI 솔루션을 붙이려면 중간에 데이터 변환 레이어를 만들어야 한다. 그 레이어를 만드는 비용이 솔루션 자체보다 클 수 있다.
Build이 유리한 쪽. 기존 시스템과의 깊은 통합이 필요하다. 레거시 시스템이 많다. 표준 API가 부족하다. 실시간 데이터 연동이 핵심이다.
Buy가 유리한 쪽. 독립 실행형 시스템이다. 기존 환경과의 연결이 단순하다. 표준 API나 웹훅으로 충분하다.
삼성SDS, LG CNS 같은 IT 서비스 회사들이 존재하는 이유가 여기에 있다. 통합의 복잡도를 해결하는 것 자체가 하나의 사업이다.
잠시 멈추고 생각해보자
당신의 회사에서 새로운 시스템을 도입할 때마다 가장 오래 걸리는 단계는 무엇인가? 그것이 통합이라면, 그 원인은 기존 시스템의 노후화인가, 표준화의 부재인가, 조직 간 협업의 부재인가?
15.8 변수 7 — 진화 속도와 Lock-in 리스크
마지막 변수는 기술의 진화 속도다. AI 기술은 빠르게 변한다. 2023년에 최선이었던 모델이 2024년에는 구식이 되었다. 2024년에 최고였던 프레임워크가 2025년에는 대체되었다. 이 속도에서 어떤 선택을 하느냐가 Lock-in 리스크를 결정한다.
Build의 리스크. 자체 구축 시스템은 특정 기술에 묶인다. LangChain으로 만들었는데 더 나은 프레임워크가 나왔다. GPT-4 기반으로 설계했는데 GPT-5가 아키텍처 자체를 바꿨다. 전환하려면 상당 부분을 다시 만들어야 한다.
Buy의 리스크. 외부 솔루션에 의존하면 해당 벤더에 묶인다. 데이터가 그 플랫폼에 쌓인다. 워크플로우가 그 솔루션에 맞춰진다. 나중에 바꾸고 싶어도 전환 비용이 크다. 그리고 벤더가 가격을 올리면 선택의 여지가 없다.
어느 쪽이 더 위험한가. 이것은 기술의 성숙도에 달려 있다.
기술이 빠르게 변하는 영역은 Buy가 유리하다. LLM 모델, 프롬프트 엔지니어링, 생성형 AI 응용. 이런 영역은 1년 안에 최선의 선택이 바뀐다. 자체 구축하면 금방 구식이 된다. SaaS 벤더는 자동으로 업그레이드해 준다. 최신 기술을 벤더가 추적해 주는 셈이다.
기술이 상대적으로 안정적인 영역은 Build이 유리하다. 데이터 파이프라인, 사내 지식 그래프, 특정 산업의 전문 모델. 이런 영역은 기반 기술이 크게 바뀌지 않는다. 한번 잘 만들면 오래 쓸 수 있다.
마이크로소프트의 Copilot을 도입한 글로벌 기업들이 이 리스크를 체감하고 있다. 편리하다. 그러나 마이크로소프트 생태계에 깊이 묶인다. 구글이나 다른 대안으로 전환하려면 비용이 크다. 이것이 Buy의 대가다.
반대로, 자체 구축한 시스템이 기술 변화를 따라가지 못하는 사례도 있다. 한 금융사가 2022년에 자체 NLP 모델을 만들었다. 수십억 원을 들였다. 2023년에 GPT-4가 나왔다. 자체 모델의 성능이 한참 뒤처졌다. 그러나 이미 투자한 비용 때문에 쉽게 버리지 못했다. 매몰비용의 함정이다.
15.9 7가지 변수 매트릭스
지금까지 본 7가지 변수를 정리하면 이렇다.
| 변수 | Build이 유리한 경우 | Buy가 유리한 경우 |
|---|---|---|
| 1. 데이터 주권 | 민감 데이터, 규제 산업 | 공개/일반 데이터, 비규제 영역 |
| 2. 차별화 | 핵심 경쟁 우위 기능 | 범용 기능, 비핵심 영역 |
| 3. 기술 역량 | 설계·개발·운영 인력 보유 | 내부 AI 인력 부재 |
| 4. 속도 | 6개월 이상 여유 | 3개월 내 필요 |
| 5. 비용 | 대규모·장기 운영 | 소규모·단기·불확실 |
| 6. 통합 복잡도 | 레거시와 깊은 연동 필요 | 독립 실행 또는 표준 API 연결 |
| 7. 진화 속도 | 기술이 안정적인 영역 | 기술이 빠르게 변하는 영역 |
이 표를 기계적으로 쓰면 안 된다. 7가지 변수 중 4개가 Build을 가리킨다고 해서 Build이 답인 것은 아니다. 변수마다 가중치가 다르다. 데이터 주권이 결정적인 산업이 있고, 속도가 결정적인 시장이 있다. 그 가중치는 회사의 상황이 결정한다.
그래서 이 매트릭스는 답을 주는 도구가 아니라 대화를 구조화하는 도구다. 회의실에서 감으로 싸우는 대신, 이 7가지 변수를 하나씩 짚으면 최소한 같은 언어로 이야기할 수 있다.
잠시 멈추고 생각해보자
7가지 변수 중에서 당신의 조직에 가장 무거운 변수는 무엇인가? 그 변수가 무거운 이유는 산업 특성인가, 조직 문화인가, 아니면 특정 임원의 성향인가?
15.10 실패에서 배운 것
Build vs Buy 결정의 실패를 수없이 봤다. 패턴이 있다.
가장 흔한 실패 유형 1: 자존심 Build. 기술 역량이 부족한데 "우리가 직접 만들어야 한다"고 고집하는 경우다. 대개 CTO나 개발 리더의 자존심이 원인이다. 결과는 일정 지연, 품질 미달, 조직 피로다. 어느 중견 화학 회사에서 본 사례가 그랬다. AI 기반 수요 예측을 자체 구축하겠다며 2년을 끌었다. 결국 외부 솔루션으로 전환했다. 2년의 시간과 개발팀의 사기를 잃었다.
가장 흔한 실패 유형 2: 성급한 Buy. 속도만 보고 외부 솔루션을 급하게 도입한 경우다. 현장의 요구 사항을 충분히 파악하지 않았다. 커스터마이징이 안 된다. 기존 시스템과의 연동이 안 된다. 결국 쓰지 않는 시스템이 된다. Pilot purgatory라고 부르는 현상이다. 파일럿은 했는데 실제 운영으로 넘어가지 못한다.
가장 흔한 실패 유형 3: 결정 지연. 이 장 도입부의 회의실처럼, Build과 Buy 사이에서 몇 달을 결정하지 못하는 경우다. 완벽한 판단을 하려다가 아무것도 하지 않는 것이다. 그 사이에 시장이 움직인다. 기회가 사라진다. 때로는 틀린 결정이라도 빨리 하고 빨리 수정하는 것이 결정하지 않는 것보다 낫다.
세 유형 모두에서 공통된 원인은 하나다. 7가지 변수를 체계적으로 보지 않고 1~2가지 변수만 보고 결정한다는 것이다. 자존심 Build은 차별화만 본다. 성급한 Buy는 속도만 본다. 결정 지연은 모든 변수를 완벽하게 보려다가 멈춘다.
체계가 있으면 다르다. 7가지 변수를 30분 안에 훑고, 가장 무거운 2~3가지를 식별하고, 그것에 집중해서 결정한다. 완벽한 결정은 없다. 그러나 구조화된 결정은 수정이 가능하다. 감에 의존한 결정은 수정 자체가 어렵다. 왜 그 결정을 했는지 아무도 기억하지 못하니까.
15.11 Hybrid라는 현실적 답
현실에서 Build과 Buy는 양자택일이 아닌 경우가 많다. 대부분의 성공 사례는 Hybrid 전략이다.
핵심 로직은 Build한다. 데이터 파이프라인, 사내 지식 그래프, 도메인 특화 모델. 이것은 자체 구축한다. 범용 기능은 Buy한다. LLM API, 문서 OCR, 음성 인식, 이메일 자동화. 이런 것은 외부 서비스를 쓴다. 그리고 둘을 연결하는 통합 레이어를 만든다.
마이크로소프트, 세일즈포스, 서비스나우 같은 플랫폼이 이 Hybrid 구조를 지원한다. 그들의 플랫폼 위에서 커스텀 로직을 만들 수 있다. 한국에서는 삼성SDS의 Brity, LG CNS의 DAP 같은 플랫폼이 비슷한 역할을 한다.
Hybrid 전략의 핵심은 무엇을 안쪽에 두고 무엇을 바깥에 둘 것인가의 경계 설정이다. 이 경계가 바로 데이터 주권과 차별화 변수가 만나는 지점이다. 민감하고 차별적인 것은 안쪽에. 범용적이고 빠르게 변하는 것은 바깥에. 이것이 원칙이다.
다음 장에서 Hybrid 전략과 데이터 주권의 구체적 설계를 더 깊이 다룬다.
핵심 정리
Build vs Buy는 기업 AI 도입의 가장 중요한 첫 번째 결정이다. 그러나 대부분의 기업이 이 결정을 체계 없이 내린다. 감에 의존하거나, 한두 가지 변수만 보거나, 결정을 미룬다.
7가지 결정 변수가 이 판단을 구조화한다. 데이터 주권, 차별화, 기술 역량, 속도, 비용, 통합 복잡도, 진화 속도. 각 변수는 Build 또는 Buy 방향을 가리킨다. 그러나 변수마다 가중치가 다르고, 그 가중치는 회사의 상황이 결정한다.
첫 번째 Use Case는 성과가 아니라 학습이 목적이다. 범위가 작고, 실패해도 배울 수 있고, 조직 전체가 참여하는 프로젝트여야 한다. 이 학습이 없으면 두 번째, 세 번째 프로젝트에서 같은 실수를 반복한다.
실패의 세 가지 패턴이 있다. 자존심 Build, 성급한 Buy, 결정 지연. 모두 변수를 체계적으로 보지 않은 결과다. 그리고 현실의 답은 대부분 Hybrid다. 핵심은 안쪽에, 범용은 바깥에. 이 경계를 잘 긋는 것이 전략이다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신의 조직에서 AI 도입의 첫 번째 프로젝트는 무엇이었는가(또는 무엇이 될 것인가)? 그것은 학습 장치로서의 조건을 만족하는가?
질문 2. 7가지 변수 중에서 당신의 조직에 가장 무거운 변수는 무엇인가? 그 변수가 무거운 이유는 산업 특성인가, 조직 문화인가, 특정 인물의 영향인가?
질문 3. 당신의 조직이 자체 구축한 AI 시스템이 있다면, 그것은 지금도 최신 기술을 따라가고 있는가? 기술 변화에 뒤처졌다면 그 원인은 무엇인가?
질문 4. 당신의 조직이 도입한 외부 AI 솔루션이 있다면, 그것에 얼마나 의존하고 있는가? 다른 솔루션으로 바꾸려면 얼마나 걸릴 것 같은가? 그 전환 비용을 계산해본 적이 있는가?
질문 5. Build vs Buy를 넘어, 당신의 조직이 진짜 결정해야 할 것은 무엇인가? 기술 선택인가, 조직 역량인가, 전략적 방향인가?
더 깊이 탐구하기
마틴 파울러(Martin Fowler), martinfowler.com 블로그. 소프트웨어 아키텍처와 Build vs Buy 판단에 관한 에세이 다수.
맥킨지, 「The State of AI in 2025」 (2025). 글로벌 기업의 AI 도입 현황과 실패 패턴에 대한 데이터 기반 보고서.
앤드루 응(Andrew Ng), 「AI Transformation Playbook」. 기업 AI 도입의 단계적 접근법. 첫 번째 Use Case 선정의 원칙을 다룬다.
가트너, 「Enterprise AI Platform Market Guide」 (2025). Buy 옵션의 시장 지형과 주요 벤더 비교.
나의 시스템 Composite AI Framework 백서 (2025). Build과 Buy의 경계를 설계하는 Hybrid 아키텍처의 실무 사례.
다음 장에서는 Hybrid 전략을 더 깊이 들어간다. Build과 Buy의 경계를 어디에 그을 것인가, 데이터 주권을 어떻게 확보하면서도 외부 서비스의 장점을 취할 것인가. 16장은 이 질문에 답한다.