AI 파트너와 일하는 법 — 외주를 줘도 실패하지 않는 구조

AI 외주는 "맡기는 것"이 아닙니다. "함께 만들면서, 우리 것으로 가져오는 것"입니다.

외주를 줬는데 왜 실패할까

앞선 글에서 내제화와 외주의 경계를 긋는 방법을 이야기했습니다. 경계를 잘 그어서 외주를 결정했다고 칩시다. 그런데 외주를 줬는데도 실패하는 경우가 많습니다.

왜일까요?

대부분은 "맡기는 방식"의 문제입니다.

"이거 만들어주세요" 하고 넘기고, 몇 달 뒤에 결과물을 받는 구조. 이 구조는 건축이나 제조에서는 작동하지만, AI에서는 작동하지 않습니다.

AI 프로젝트는 만들면서 방향이 바뀝니다. 데이터를 열어보니 예상과 다르고, 모델을 돌려보니 기대한 정확도가 안 나오고, 현업이 써보니 다른 게 필요합니다. 이 변화에 빠르게 대응하려면, 발주자와 수행자가 계속 대화해야 합니다.

"맡기고 기다리는" 외주는 AI에서 실패 확률이 가장 높은 구조입니다.

좋은 파트너를 고르는 법

기술력보다 먼저 볼 것

AI 외주 파트너를 고를 때, 기술력은 당연히 중요합니다. 하지만 기술력만 보면 판단을 그르칩니다. 기술적으로 뛰어나지만 우리 문제를 이해하지 못하는 파트너보다, 기술은 80점이지만 우리 상황을 깊이 이해하는 파트너가 더 좋은 결과를 냅니다.

세 가지 신호를 보세요.

우리 문제에 먼저 관심을 가지는가. 첫 미팅에서 자기 기술 스택을 30분 설명하는 파트너 vs "지금 가장 급한 문제가 뭔가요?"라고 묻는 파트너. 후자가 낫습니다.

한계를 솔직히 말하는가. "다 됩니다"라고 하는 파트너는 경계하세요. "이 부분은 잘하지만, 저 부분은 우리 전문이 아닙니다"라고 말할 수 있는 파트너가 자기 역량을 정확히 아는 겁니다.

작게 시작하자고 제안하는가. 바로 연간 계약을 밀어붙이는 대신, "4주 파일럿을 먼저 해보시죠"라고 제안하는 파트너는 자기 결과물에 자신이 있는 겁니다.

레퍼런스 확인법

"A사, B사에서 성공적으로 수행했습니다." 이 말만으로는 부족합니다.

물어야 할 것:

• 그 프로젝트의 규모와 범위가 우리와 비슷한가?
• 프로젝트 완료 후 지금도 운영되고 있는가?
• 해당 고객사에 직접 레퍼런스 체크를 할 수 있는가?

세 번째 질문에 "네"라고 답하면 신뢰할 수 있습니다. 자기 고객이 좋은 이야기를 해줄 거라는 확신이 있다는 뜻이니까요.

실패하지 않는 계약 구조

프로젝트형 vs 자문형

AI 외주 계약은 크게 두 가지입니다.

프로젝트형: "이 시스템을 만들어서 납품하세요." 범위, 일정, 비용이 고정됩니다. 명확한 결과물이 있을 때 적합합니다.

자문형: "우리와 함께 만들어주세요." 시간 단위 또는 월 단위로 계약합니다. 방향이 바뀔 수 있는 탐색 단계에 적합합니다.

AI 프로젝트의 현실적 권장 순서:

1단계 — 자문형으로 시작. 파일럿 단계에서는 방향이 자주 바뀝니다. 자문형으로 유연하게 탐색하세요.

2단계 — 검증된 범위를 프로젝트형으로 전환. 파일럿에서 확인된 것을 본격 구축할 때는 프로젝트형이 효율적입니다.

계약에 반드시 넣어야 할 것

산출물 소유권. 코드, 모델, 데이터, 문서 — 누구 것인가. "우리가 비용을 지불한 산출물은 모두 우리 것"이어야 합니다. 이게 없으면 파트너를 바꿀 때 처음부터 다시 만들어야 합니다.

지식 이전 조항. 프로젝트 종료 시 내부 담당자에게 시스템 운영 방법을 교육하는 것을 계약에 포함하세요. "인수인계 교육 N시간"을 명시하세요.

소스코드 및 문서 접근. 프로젝트 진행 중에도 코드 저장소와 문서에 우리가 접근할 수 있어야 합니다. 프로젝트가 끝난 뒤에야 결과물을 받는 구조는 중간 검증이 불가능합니다.

유지보수 조건. 납품 후 버그 수정, 성능 이슈 대응의 기간과 범위를 정하세요. "3개월 무상 유지보수, 이후 월 N만 원" 같은 식으로 명확히.

해지 조건. 파트너를 바꾸고 싶을 때 데이터와 시스템을 온전히 돌려받을 수 있는지. 이게 없으면 종속에 빠집니다.

지식을 내부에 남기는 법

외주의 최대 리스크는 파트너가 떠나면 지식도 떠나는 것입니다. 이걸 막는 구체적인 방법이 있습니다.

내부 담당자를 프로젝트에 처음부터 참여시키세요. 관찰자가 아니라 참여자로. 파트너와 함께 회의하고, 의사결정 과정을 공유받고, 가능하면 간단한 작업을 직접 수행합니다.

주간 리뷰를 하세요. "이번 주에 무엇을 했고, 왜 그렇게 결정했고, 다음 주에 무엇을 할 것인가." 이 세 가지를 매주 공유받으면, 프로젝트가 끝났을 때 내부 담당자가 전체 맥락을 이해하고 있습니다.

문서화를 요구하세요. 코드만 납품받으면 안 됩니다. "이 시스템은 이렇게 작동하고, 이런 구조이고, 문제가 생기면 여기를 확인하세요"라는 운영 가이드를 함께 받으세요.

"우리가 혼자 수정할 수 있는가" 테스트를 하세요. 프로젝트 종료 전에, 파트너의 도움 없이 내부 담당자가 간단한 수정을 해보는 시간을 가지세요. 여기서 막히는 부분이 있으면 추가 교육을 요청하세요.

의존에서 벗어나는 전략

아무리 좋은 파트너라도, 영원히 의존하면 안 됩니다. 관계를 유지하되, 점진적으로 자립도를 높여가는 전략이 필요합니다.

1년 차: 파트너가 70%, 내부가 30%. 파트너가 주도하고 내부가 배웁니다.

2년 차: 파트너가 40%, 내부가 60%. 내부가 운영하고 파트너는 고도화와 자문을 합니다.

3년 차: 파트너가 10%, 내부가 90%. 내부가 거의 독립적으로 운영하고, 파트너는 필요할 때만 참여합니다.

이 비율은 상황에 따라 다르지만, 방향은 같습니다. 시간이 갈수록 내부 비중이 늘어나야 합니다. 2년이 지났는데 파트너 의존도가 여전히 70%라면, 뭔가 잘못되고 있는 겁니다.

좋은 파트너 관계의 본질

최고의 AI 파트너는 자신이 점점 필요 없어지게 만드는 파트너입니다.

역설적으로 들리지만, 이것이 진짜 파트너십입니다. 우리가 성장해서 독립할 수 있게 도와주는 관계. 그런 파트너는 단기 매출보다 장기 신뢰를 선택하고, 결과적으로 더 오래 함께 합니다. 우리가 성장하면 더 고도화된 영역에서 다시 협력할 수 있으니까요.

"이 파트너 없이는 안 된다"가 아니라, "이 파트너 덕분에 우리도 할 수 있게 되었다." 이것이 AI 외주의 올바른 결말입니다.

안에서 할 것과 밖에 맡길 것의 경계를 긋고, 밖에 맡긴 것에서 지식을 안으로 가져오는 것. 이 두 가지가 함께 작동할 때, AI는 비용이 아니라 역량이 됩니다.