클라우드·AI 전환, 직접 할까 외주를 맡길까 — SMB 의사결정 기준

“저희가 직접 해볼 수 있을까요, 아니면 업체를 불러야 할까요?”

얼마 전 상담했던 30인 규모 물류 스타트업 대표님이 던진 질문이다. 클라우드로 옮기고 AI도 업무에 붙여봐야 한다는 건 이미 다들 안다. 문제는 그 다음이다. 내부에 전담 IT 인력이 없는데 직접 해도 괜찮은 건지, 외주를 맡기면 바가지를 쓰는 건 아닌지, 맡긴 뒤에 문제가 생기면 누구한테 책임을 물어야 하는지 — 이 질문들 앞에서 결정은 계속 미뤄지고, 미뤄지는 동안 경쟁사는 벌써 한 발 앞서 움직인다.

이 글에서는 전담 IT 인력이 없는 10~50인 규모 기업이 클라우드·AI 전환을 “직접 할지, 맡길지” 결정할 때 실제로 따져봐야 할 기준을 정리한다. 정답은 하나가 아니다. 하지만 기준은 명확하게 세울 수 있고, 그 기준만 분명해지면 결정은 생각보다 빨리 끝난다.

왜 이 질문에 답하기가 유독 어려운가

이 질문이 어려운 이유는 정보가 부족해서가 아니다. 오히려 정보는 넘친다. 문제는 그 정보 대부분이 한쪽에 치우쳐 있다는 점이다.

클라우드 벤더와 MSP(관리형 서비스 제공업체)의 영업 자료는 한결같이 “지금 당장, 전문가에게 맡기세요”라고 말한다. 반대로 “클라우드 셀프 마이그레이션 성공기” 같은 콘텐츠는 “개발자 한 명이면 충분하다”고 말한다. 둘 다 완전히 틀린 말은 아니지만, 둘 다 당신 회사의 구체적인 상황은 전혀 모르고 하는 말이다.

실제로 상담 현장에서 자주 보는 장면은 이렇다. 한 업체는 “풀 마이그레이션에 8천만 원, 3개월”이라는 견적을 내밀고, 다른 업체는 “2천만 원, 한 달이면 됩니다”라고 말한다. 둘 다 같은 범위의 일을 두고 낸 견적인데도 4배 차이가 난다. 의사결정권자 입장에서는 이 차이가 “실력 차이”인지 “바가지”인지 “숨겨진 범위 차이”인지 구분할 방법이 거의 없다. 기술적 디테일을 검증할 근거가 없기 때문이다.

그렇다고 직접 하자니, 주변에서 “시작은 거창했지만 끝을 못 보고 흐지부지된” 프로젝트들을 너무 많이 봤다. 담당자가 퇴사하면서 문서도 없이 프로젝트가 중단되거나, 처음 계획한 범위의 절반도 못 끝낸 채 “일단 되는 것만 쓰자”로 흘러가는 경우가 흔하다. 그래서 많은 대표님들이 결정을 미루다가, 결국 사고가 터지고 나서야 움직이게 된다 — 지난 글(전담 IT 인력 없는 기업의 구조적 문제)에서 다뤘던, SMB IT 관리의 가장 전형적인 실패 패턴이다.

중요한 건, 이 문제가 “의지”나 “똑똑함”의 문제가 아니라는 사실이다. 정보 구조 자체가 기울어져 있기 때문에, 비전문가가 혼자서 합리적인 판단을 내리기 어렵게 설계되어 있다. 그렇다면 필요한 건 더 많은 정보가 아니라, 더 명확한 판단 기준이다.

“직접 vs 외주”는 사실 하나의 질문이 아니다

경영진 회의에서 이 주제가 올라오면 보통 “전부 직접 할지, 전부 맡길지”라는 양자택일로 흘러간다. 하지만 이건 처음부터 잘못된 프레임이다. 실제로는 최소 다섯 가지 서로 다른 질문이 하나로 뭉쳐 있고, 이 다섯 가지를 뭉쳐서 한 번에 답하려고 하니 결정이 늘어지는 것이다.

내부 역량: 지금 조직에 이 일을 맡길 사람이 있는가, 아니면 전혀 없는가
전환 범위: 이메일·문서 공유 같은 단순 SaaS 전환인가, 핵심 업무 시스템의 마이그레이션인가
리스크 수준: 개인정보·금융정보·고객 핵심 데이터를 다루는가, 아니면 상대적으로 가벼운 데이터인가
시간 지평: 3개월 안에 끝내야 하는 급한 사안인가, 1년에 걸쳐 천천히 해도 되는가
예산 구조: 초기 비용을 한 번에 감당할 수 있는가, 매달 나눠서 부담해야 하는가

이 다섯 축을 하나씩 따로 답해보면, “직접 vs 외주”라는 이분법 자체가 무너진다. 어떤 영역은 직접 하고 어떤 영역은 맡기는 게 정답인 경우가, 실제로는 훨씬 많다.

내부 역량 — 가장 먼저 확인해야 할 축

“누군가는 할 수 있겠지”라는 막연한 기대가 아니라, 구체적으로 이름을 댈 수 있는 담당자가 있는가를 물어야 한다. 이름이 바로 떠오르지 않는다면, 그건 이미 “내부 역량이 없다”는 답이다. 여기서 흔히 하는 실수는 “우리 개발자가 서버도 좀 아니까 되지 않을까”라는 판단이다. 애플리케이션 개발 역량과 인프라·클라우드 운영 역량은 겹치는 부분도 있지만 완전히 다른 전문 영역이다.

전환 범위 — 복잡도가 결정의 절반을 차지한다

이메일을 구글 워크스페이스로 옮기는 일과, 20년 된 ERP를 클라우드 네이티브로 재설계하는 일은 난이도가 전혀 다른 작업이다. 전환 범위가 단순할수록 직접 해볼 여지가 커지고, 복잡할수록 전문성의 비중이 커진다. 범위를 가늠하는 간단한 질문은 “이 시스템이 멈추면 회사 업무가 몇 시간 안에 멈추는가”다. 답이 “거의 즉시”라면 범위가 생각보다 크다는 신호다.

리스크 수준 — 실패했을 때 잃는 것의 크기

고객 결제정보나 의료정보처럼 법적 책임이 따르는 데이터를 다룬다면, 비용을 아끼려다 보안 사고로 훨씬 큰 비용을 치르는 역설이 벌어진다. 개인정보 유출 사고 하나가 과징금, 고객 이탈, 평판 손상까지 합치면 전환 비용의 수십 배에 이르는 경우도 드물지 않다. 리스크가 높을수록 전문가 개입의 가치가 커진다.

시간 지평 — 급할수록 직접 하기 어렵다

내부 담당자는 본업이 있다. “급하게, 직접”은 거의 양립하지 않는 조합이다. 시한이 촉박할수록 외주의 속도가 필요해진다. 반대로 급할 이유가 없다면, 서두르지 않고 내부 역량을 천천히 쌓아가는 선택도 충분히 합리적이다.

예산 구조 — 목돈이냐 월정액이냐

초기 목돈 지출이 부담스럽다면, 프로젝트성 외주보다 구독형으로 나눠 내는 관리 서비스 쪽이 현금흐름 관리에 유리하다. 특히 올해처럼 자금 운용에 여유가 없는 시기에는, 한 번에 수천만 원을 지출하는 결정 자체가 다른 의사결정 전체를 경직시킬 수 있다는 점도 고려해야 한다.

직접 하는 경우 — 장점과 함정

직접 하는 쪽을 선택하는 이유는 대개 두 가지다. 비용을 아끼고 싶거나, 통제권을 놓고 싶지 않아서다. 둘 다 합리적인 이유다.

장점은 분명하다. 외주 비용이 들지 않고, 의사결정이 빠르다. 외부 업체와의 커뮤니케이션 비용, 계약·검수 절차 없이 바로 실행에 들어갈 수 있다. 그리고 가장 중요한 건, 그 과정에서 조직 내부에 역량이 쌓인다는 점이다. 한 번 클라우드 전환을 직접 겪어본 조직은 다음 전환에서 훨씬 수월하게 움직인다. 작은 조직일수록 이 역량 축적의 가치는 더 크다 — 외부에 의존하지 않고 스스로 판단할 수 있는 조직이 된다는 뜻이기 때문이다.

하지만 함정도 분명하다. 가장 흔한 실패 원인은 “일단 개발팀 리드한테 맡겨두면 알아서 하겠지”라는 생각이다. 그 개발 리드는 지금도 제품 개발만으로 하루 14시간이 부족하다. 클라우드 전환은 “짬 나는 시간에” 처리하는 부업이 아니라, 전담해서 매달려야 하는 프로젝트다. 전담할 사람 없이 “직접 하기로” 결정하는 건, 사실상 “아무도 책임지지 않기로” 결정하는 것과 다르지 않다.

또 하나, 직접 할 때 가장 과소평가되는 건 숨은 시간 비용이다. 외주라면 계약서에 기간과 비용이 명시된다. 직접 하면 그런 제약이 없어서 프로젝트가 끝없이 늘어지는 경우가 많다. 6개월이면 될 거라 생각했던 전환이 1년 반이 걸리는 식이다. 그 1년 반 동안 담당자의 다른 업무는 전부 뒤로 밀린다 — 눈에 보이지 않지만, 사실은 가장 비싼 비용이다. 여기에 더해, 담당자가 시행착오를 겪으며 “배우는 비용”도 무시할 수 없다. 처음 해보는 일이기 때문에 돌아가거나 다시 하는 구간이 반드시 생기고, 그 구간만큼 일정과 비용은 늘어난다.

외주를 맡기는 경우 — 장점과 함정

외주의 장점도 분명하다. 전문성과 속도다. 매일 이 일만 하는 사람들은 당신 회사가 처음 겪을 함정들을 이미 수십 번 겪어봤다. 그만큼 실패 확률이 줄어든다. 계약서에 기간과 범위가 명시되기 때문에, 책임 소재도 비교적 분명해진다. 내부 인력을 다른 핵심 업무에 계속 집중시킬 수 있다는 것도 간과하기 쉬운 장점이다.

하지만 외주에도 함정이 있다. 가장 큰 함정은 “맡겼으니 끝났다”는 착각이다. 클라우드·AI 전환은 한 번 짓고 떠나는 공사가 아니다. 구축 이후의 운영, 비용 관리, 보안 패치는 계속 남는 일이다. 외주업체가 구축만 해주고 떠나버리면, 그 다음부터는 다시 “담당자가 없는” 원래 문제로 돌아간다. 실제로 “구축은 잘 끝났는데, 그 다음부터는 손을 못 대고 있다”는 상담이 생각보다 많다.

두 번째 함정은 벤더 종속이다. 특정 업체의 방식과 도구로 구축해두면, 나중에 다른 업체로 바꾸거나 내부로 가져오기가 어려워진다. 계약 전에 “나중에 우리가 직접 운영하거나 다른 업체로 옮기려면 어떻게 해야 하는가”를 반드시 물어봐야 한다. 이 질문에 명확히 답하지 못하거나, 문서화·인수인계 조항을 계약에 넣기 꺼리는 업체는 피하는 게 좋다.

세 번째 함정은 커뮤니케이션 비용이다. IT를 잘 모르는 담당자가 전문 업체와 대화하면, 업체가 하는 말을 검증할 방법이 없다. “이 작업은 꼭 필요합니다”라는 말을 들으면 그대로 받아들일 수밖에 없는 구조다. 중간에서 통역해줄 사람 — 사내 담당자든, 중립적인 자문이든 — 이 없으면, 결국 업체가 하자는 대로 끌려가게 되고, 비용은 당초 견적보다 계속 불어난다.

둘 다에서 반복되는 진짜 실패 패턴

직접이든 외주든, 실제로 실패하는 회사들을 보면 패턴이 놀랍도록 비슷하다. “누가 책임지는지가 불분명하다”는 것이다.

직접 하기로 했는데 전담 인력을 지정하지 않으면, 모두의 일이면서 아무도의 일도 아니게 된다. 회의에서는 “그건 저희 쪽에서 챙기겠습니다”라는 말이 나오지만, 막상 다음 회의에서 진척이 없는 경우가 대부분이다. 외주를 맡겼는데 내부에 이를 관리·검증할 담당자를 지정하지 않으면, 외주업체가 뭘 하는지 아무도 모르는 상태로 프로젝트가 흘러간다. 몇 달 뒤 “그래서 지금 어디까지 된 겁니까”라는 질문에 누구도 명확히 답하지 못하는 회의를 하게 된다면, 이미 그 신호가 나타난 것이다.

그래서 “직접이냐 외주냐”보다 먼저 답해야 할 질문은 이거다. “이 일의 결과를 누가 책임지는가?” 이 질문에 명확한 답이 나오지 않으면, 직접 해도 외주를 맡겨도 똑같이 실패한다. 반대로 이 질문에 명확한 답이 있다면, 직접이든 외주든 성공할 확률이 훨씬 높아진다.

결정 체크리스트 — 7개 질문

아래 7개 질문에 솔직하게 답해보면, 지금 우리 회사가 어느 쪽에 더 가까운지 감이 잡힌다. 회의 시작 전에 각 질문에 “직접” 또는 “외주” 중 하나를 체크해보는 것만으로도, 막연했던 논쟁이 구체적인 숫자로 바뀐다.

이 전환의 결과를 책임질 담당자를 한 명 지정할 수 있는가? — 못 지정한다면, 직접도 외주도 모두 실패할 가능성이 높다.
그 담당자가 이 일에 쓸 수 있는 시간이 주당 몇 시간인가? — 주 5시간 미만이면 직접 추진은 현실적으로 어렵다.
다루는 데이터에 개인정보·금융정보·고객 핵심정보가 포함되는가? — 포함된다면 보안 전문성이 필요해 외주 비중을 높이는 게 안전하다.
전환 대상이 단순 SaaS 도구인가, 핵심 업무 시스템인가? — 단순 도구는 직접, 핵심 시스템은 외주 비중을 높이는 쪽이 합리적이다.
예산을 한 번에 지출할 수 있는가, 매달 나눠 내야 하는가? — 후자라면 구독형 관리 서비스가 프로젝트성 외주보다 부담이 적다.
구축 이후 운영·유지보수까지 책임질 사람이 있는가? — 없다면 ‘구축’만 맡기는 외주는 반쪽짜리 해법이다.
지금 당장이 아니라 1년 뒤에도 이 결정을 다시 설명할 수 있는가? — 설명할 수 없다면, 그 결정은 근거 없이 급하게 내려진 것일 가능성이 크다.

7개 중 “직접” 쪽 답이 많이 나왔다면 내부 역량을 키우는 방향으로, “외주” 쪽 답이 많이 나왔다면 전문가 도움을 받는 방향으로 무게를 두면 된다. 4대 3처럼 팽팽하게 갈리는 경우도 많은데, 그럴 때가 바로 다음 섹션에서 다룰 “혼합형”이 필요한 경우다.

축별로 보면: 어느 쪽이 유리한가

판단 축	직접이 유리한 경우	외주가 유리한 경우
내부 역량	담당자를 구체적으로 지정할 수 있다	이름을 댈 사람이 없다
전환 범위	단순 SaaS 도구 수준	핵심 업무 시스템 마이그레이션
리스크 수준	가벼운 데이터 위주	개인정보·금융정보 포함
시간 지평	1년 이상 여유가 있다	3개월 내 끝내야 한다
예산 구조	목돈 지출이 부담 없다	월정액 분할이 필요하다

실제 상황은 이 다섯 축에서 전부 같은 방향을 가리키지 않는 경우가 대부분이다. 예를 들어 내부 역량은 있는데 리스크 수준이 높은 경우, 또는 예산은 충분한데 시간이 급한 경우처럼 축마다 답이 엇갈린다. 그래서 다음 단계가 필요하다.

현실적인 중간 지대 — 진단은 전문가, 운영은 내부, 또는 그 반대

실제로는 “전부 직접” 또는 “전부 외주”보다, 영역을 나눠서 혼합하는 쪽이 가장 현실적이고 비용 효율적이다.

한 가지 방식은 처음 현황 진단과 전환 설계는 외부 전문가의 눈을 짧은 기간, 명확한 산출물로 빌리고, 실제 운영과 유지보수는 내부 담당자가 맡는 것이다. 이렇게 하면 외주 비용은 최소화하면서, 가장 위험한 “눈 감고 시작하는” 상황은 피할 수 있다. 진단 단계에서 받은 산출물(현황 진단서, 전환 로드맵, 리스크 목록)은 그 자체로 내부 담당자가 참고할 수 있는 지도가 되어준다.

반대 방식도 가능하다. 진단은 내부에서 직접 해보고(어차피 비용이 들지 않으니), 실제 구축·마이그레이션처럼 전문성이 꼭 필요한 구간만 외주를 맡기는 것이다. 이 방식은 내부에서 이미 문제를 어느 정도 파악하고 있을 때, 외주업체와의 협상력을 높이는 데도 도움이 된다.

세 번째 방식은 ‘구독형 파트너’를 두는 것이다. 한 번의 프로젝트성 계약 대신, 매달 정해진 범위 내에서 모니터링·점검·대응을 받는 구조다. 전담 IT 인력을 채용하는 것보다 비용이 낮고, 한 번 맡기고 끝나는 프로젝트성 외주보다 지속성이 있다. 특히 “구축은 끝났는데 그 다음을 아무도 못 챙기는” 앞서 언급한 함정을 구조적으로 막아준다는 점에서, 전담 인력도 없고 매번 새 업체를 찾기도 부담스러운 10~50인 규모 기업에는 현실적인 선택지가 된다.

핵심은 “전부 맡기거나 전부 떠안는” 극단을 피하고, 구간별로 누가 가장 잘할 수 있는지를 따로 판단하는 것이다. 많은 중소기업이 이 중간 지대를 몰라서, 결정을 미루다가 둘 중 하나를 급하게 전부 선택하고 후회한다.

세 가지 경로의 비용과 시간을 가늠해보면

구체적인 숫자 없이는 논쟁이 끝나지 않는다. 물론 회사마다 상황이 다르지만, 10~50인 규모 기업이 중간 규모의 클라우드·AI 전환을 진행할 때 대략적인 그림은 다음과 같이 그려볼 수 있다.

전부 직접 하는 경로는 초기 현금 지출이 거의 없다는 게 가장 큰 매력이다. 하지만 담당자의 시간이라는 보이지 않는 비용이 그 자리를 대신 채운다. 본업과 병행하다 보니 당초 3개월로 예상한 일정이 6개월, 8개월로 늘어지는 경우가 흔하고, 그 기간 동안 담당자의 다른 업무 생산성도 함께 떨어진다. 전부 외주를 맡기는 경로는 초기 비용은 가장 크지만 일정은 가장 예측 가능하다. 다만 앞서 설명한 것처럼 구축이 끝난 뒤의 운영 공백이라는 숨은 리스크가 남는다. 혼합형(진단은 외부, 운영은 내부, 또는 구독형 관리 서비스를 더하는 방식)은 초기 비용과 일정 모두 중간 수준으로 수렴하면서, 운영 공백 리스크를 가장 효과적으로 줄여준다. 그래서 다섯 축 중 서너 개가 팽팽하게 엇갈리는 전형적인 10~50인 기업에는, 혼합형이 통계적으로도 가장 안전한 선택지인 경우가 많다.

중요한 건 어느 경로를 고르든 “예상 비용”과 “예상 일정”을 숫자로 먼저 써보는 것이다. 숫자 없이 “일단 해보고 판단하자”로 시작한 프로젝트는, 끝날 때쯔음 처음 예상과 전혀 다른 숫자를 마주하게 되는 경우가 대부분이다.

자주 받는 질문

“일단 직접 해보고, 막히면 외주로 넘겨도 되나요?” — 가능하다. 다만 “막혔다”는 판단을 내릴 기준을 미리 정해두는 게 좋다. 예를 들어 “2주 안에 진전이 없으면 외부 의견을 구한다”처럼 구체적인 기한을 정해두지 않으면, 막힌 상태로 몇 달이 흘러가는 경우가 많다.

“견적이 업체마다 너무 달라서 비교가 안 됩니다.” — 견적 차이가 크다면 범위 정의가 서로 다른 것일 가능성이 높다. 견적을 받을 때는 “어디서부터 어디까지가 포함되는가”를 표 형태로 정리해달라고 요청하는 것만으로도 비교가 훨씬 쉬워진다. 구축만 포함되는지, 3개월 운영 지원까지 포함되는지에 따라 가격은 당연히 달라진다.

“내부 직원이 반대합니다. 외주를 맡기면 자기 일이 없어질까 걱정하는 것 같습니다.” — 흔한 반응이다. 이럴 때는 역할을 “대체”가 아니라 “분담”으로 설명하는 게 중요하다. 전문가는 설계와 구축을, 내부 직원은 운영과 현업 요구사항 전달을 맡는 구조로 설명하면 저항이 훨씬 줄어든다.

“외주업체가 정말 믿을 만한지 어떻게 판단하나요?” — 계약 전에 과거 비슷한 규모 고객의 사례와 구체적인 산출물(설계 문서, 인수인계 문서 샘플)을 요청해보는 것이 가장 확실하다. “영업 비밀이라 못 보여드립니다”라는 답이 돌아온다면, 그 자체가 하나의 판단 근거다. 또한 계약서에 문서화·인수인계 조항이 명시되어 있는지를 반드시 확인해야 한다.

마무리 — 미루는 것만이 유일하게 나쁜 선택이다

클라우드·AI 전환을 “직접 할지, 맡길지”는 옳고 그른 답이 정해진 질문이 아니다. 지금 우리 회사의 내부 역량, 다루는 데이터의 민감도, 시간과 예산의 여유에 따라 답은 달라진다.

다만 분명한 게 하나 있다. “일단 미뤄두자”는 선택지는 없다. 결정을 미루는 동안에도 리스크는 그대로 쌓이고, 경쟁사는 이미 움직이고 있다. 위 7개 질문에 솔직하게 답해보는 것 — 그게 가장 빠르고 돈 안 드는 첫 번째 진단이다. 답을 적어보는 데 30분이면 충분하다. 그 30분이, 몇 달을 허비하는 것과 몇천만 원을 잘못 쓰는 것, 둘 다를 막아줄 수 있다.

앞서 언급한 물류 스타트업 대표님은 결국 7개 질문에 하나씩 답을 적어보는 것부터 시작했다. 결과는 “전부 직접”도 “전부 외주”도 아니었다. 고객 배송 데이터가 걸린 핵심 시스템 전환은 짧은 기간 전문가의 진단을 받아 설계만 맡기고, 상대적으로 가벼운 사무 도구 전환은 내부 직원이 그 설계를 참고해 직접 진행하는 혼합형으로 결론이 났다. 중요한 건 정답을 미리 알고 시작한 게 아니라, 질문을 하나씩 분리해서 답해봤기 때문에 결론에 도달할 수 있었다는 점이다. 막연하게 “직접이냐 외주냐”를 고민하던 몇 주보다, 체크리스트를 채우는 30분이 훨씬 빠르게 답을 가져다줬다.