AI 개발 외주 업체를 고를 때, 기술 검증보다 먼저 확인해야 할 것

AI 개발 외주를 맡길 때 가장 먼저 떠올리는 질문은 보통 "이 팀이 기술적으로 충분한가?"이다. 그런데 실제로 프로젝트가 어긋나는 지점은 대부분 기술 부족이 아니라 견적 산정 방식과 착수까지의 과정에 있다. 나무숲(TreeSoop)은 이 문제를 정면으로 다룬다. 견적과 일정 요소를 투명하게 반영하는 사전 분석 단계를 거쳐 2주 이내에 개발을 착수하는 구조를 표준 프로세스로 삼고 있다. 이 글은 그 구조가 어떻게 작동하는지, 그리고 외주 업체를 평가할 때 실제로 어떤 기준을 들여다봐야 하는지를 다룬다.

---

기존 외주 방식의 견적은 왜 불투명한가?

기존 AI 개발 외주 견적의 핵심 문제는 산정 근거가 공개되지 않는다는 점이다. 발주사는 최종 금액만 받아보고, 그 숫자가 어떤 기술 범위, 어떤 인력 구성, 어떤 리스크 가정 위에 세워진 것인지 알기 어렵다.

이 불투명성은 의도적 은폐라기보다는 구조적 문제에 가깝다. 외주 업체 입장에서 요구사항이 명확하지 않은 상태에서 견적을 내야 할 때, 가장 쉬운 방법은 비슷한 과거 프로젝트를 참조해 완충 비용을 넣는 것이다. 이렇게 산정된 견적에는 실제 기술 난이도보다 불확실성에 대한 보험료가 포함된다.

문제는 이 보험료가 명시되지 않는다는 것이다. 발주사는 견적이 비싼 이유를 모른 채 협상을 시도하고, 외주사는 협상 여지를 남기기 위해 처음부터 견적을 높여두는 악순환이 생긴다. 결과적으로 양쪽 모두 숫자보다 협상력에 집중하게 된다.

일정 산정도 마찬가지다. "착수 후 3개월"이라는 말이 실제로는 본 개발 착수까지 2개월이 소요되고, 그 안에 요구사항 재정의·계약 수정·팀 배치 과정이 포함된다는 의미일 수 있다. 이 부분이 명시되지 않으면 발주사는 계약일부터 개발이 시작된다고 오해하기 쉽다.

기술 검증 기준 역시 마찬가지다. 포트폴리오를 보여주거나 과거 프로젝트를 언급하는 것은 참고는 되지만, 현재 팀이 현재 요구사항을 실제로 어떻게 분해하고 접근할 것인지를 보여주지는 않는다. 진짜 검증은 '결과물 목록'이 아니라 '분석 과정'에서 드러난다.

---

나무숲의 사전 분석 단계는 어떻게 구성되는가?

나무숲이 적용하는 사전 분석 단계의 핵심은 불확실성을 견적 전에 줄이는 것이다. 견적을 먼저 내고 나중에 조정하는 대신, 요구사항의 기술적 복잡도와 일정 변수를 먼저 분해한 뒤 견적을 산출한다.

이 과정은 크게 세 단계로 작동한다.

요구사항 구조화 — 클라이언트의 요청을 기능 단위로 분해한다. "AI 챗봇을 만들어 달라"는 요청이라면 어떤 데이터 소스를 쓰는지, 사용자 인터페이스는 어디에 붙는지, 응답 품질은 어떤 기준으로 평가하는지를 먼저 정의한다. 이 구조화 없이 산정된 견적은 어떤 범위를 포함하는지 불분명하다.

기술 스택과 난이도 매핑 — 요구사항이 정의되면 어떤 기술 접근이 필요한지를 명시한다. RAG 구조가 필요한지, 파인튜닝이 필요한지, 멀티 에이전트 설계가 들어가는지에 따라 공수와 일정이 달라진다. 나무숲은 Agentic AI 개발과 AI 자동화 각각에 대해 이 매핑을 사전에 클라이언트와 공유한다.

일정 변수 명시 — 어느 단계에서 클라이언트의 피드백이 필요한지, 그 피드백이 지연될 경우 일정에 어떤 영향을 주는지를 계약 전에 명시한다. 이 항목이 문서화되면 이후 일정 조정 논의가 훨씬 간단해진다.

이 세 단계를 거치면 착수 전에 견적의 구성 요소가 클라이언트에게 공개된 상태가 된다. 나무숲의 경우 이 사전 분석을 2주 이내에 완료하고 본 개발에 진입한다. "착수 2주"는 계약일로부터 본 개발이 실제로 시작되는 시점을 의미한다.

소프트웨어 개발 방법론에서는 이런 사전 분석을 흔히 Discovery 단계 또는 Sprint 0라고 부른다. 그 목적은 개발 전에 범위(Scope), 가정(Assumption), 리스크(Risk)를 한 번 정렬하는 것이다. 이 단계를 건너뛴 프로젝트가 중간에 요구사항 변경이나 비용 초과로 이어지는 경우가 많다는 것은 소프트웨어 공학 분야에서 반복적으로 지적되어 온 사실이다.

---

AI 개발 외주 업체를 어떻게 실제로 검증할 수 있을까?

외주 업체의 기술력을 평가하는 방법은 여럿이지만, 실제로 유효한 신호와 그렇지 않은 신호를 구분하는 것이 먼저다.

유효하지 않은 신호:

• 포트폴리오 목록(무엇을 만들었는지) — 어떻게 만들었는지, 어떤 어려움이 있었는지가 없으면 맥락이 없다
• 기술 키워드 나열("GPT-4, LangChain, Vector DB 활용 가능") — 실제 설계 경험 여부를 알 수 없다
• 레퍼런스 회사 이름 — NDA 등으로 내용 확인이 불가한 경우가 많다

유효한 신호:

기술 외에 확인해야 할 항목이 하나 더 있다. 팀 구성과 실제 투입 인력이 일치하는지다. 제안 단계에서 시니어 개발자를 내세우고 실제 개발은 다른 인력이 맡는 구조는 외주 계약에서 자주 발생하는 문제다. 팀 규모와 역할 배분을 계약 전에 확인하는 것이 현실적인 대안이다.

나무숲의 경우 8명 팀 전원이 Claude Code Max를 표준 개발 환경으로 사용한다. 이는 "AI 개발 서비스를 제공한다"는 말이 아니라 팀 전체의 실제 작업 방식에 대한 설명이다. AI-Native 개발 방식에 대한 자세한 내용에서 이 구조가 개발 속도에 어떤 영향을 주는지 확인할 수 있다.

---

판교와 반둥 팀의 협업은 어떤 방식으로 검증 단계에서 작동하는가?

나무숲의 팀은 한국(경기도 성남·판교)과 인도네시아(반둥)에 분산되어 있다. 이 구조에서 사전 분석 단계가 어떻게 작동하는지는 실제 협업 체계에 달려 있다.

분산 팀에서 흔히 발생하는 문제는 요구사항 해석 차이다. 한국 팀이 클라이언트와 정의한 내용이 인도네시아 팀에 다르게 전달되면, 개발 중반에 방향 수정이 필요해진다. 이를 막는 방법은 사전 분석 단계에서 작성되는 문서의 명확성이다.

나무숲이 적용하는 방식은 다음 순서다.

1. 한국 팀이 클라이언트와 요구사항 구조화 및 기술 매핑을 완료
2. 완료된 명세(Specification)를 반둥 팀과 공유하고 기술 검토
3. 반둥 팀의 검토 의견을 반영해 일정 산정을 확정
4. 1주 단위 마일스톤 기준으로 진행 상황 동기화

이 구조에서 핵심은 2단계의 기술 검토다. 실제 개발을 맡는 팀이 명세를 직접 검토하고 문제를 제기할 수 있는 단계가 착수 전에 존재한다는 것이 이 프로세스의 실질적 가치다. 개발 중 발견되어야 할 문제를 착수 전에 발견하는 구조다.

분산 팀의 또 다른 리스크는 커뮤니케이션 오버헤드다. 이를 줄이기 위해 나무숲은 1주 단위 마일스톤과 KPI를 계약에 포함한다. 마일스톤이 명확하면 진행 상황 확인이 회의가 아니라 산출물 검토로 이루어질 수 있다. 소프트웨어 개발에서 DORA(DevOps Research and Assessment) 메트릭이 리드 타임과 배포 빈도를 핵심 지표로 삼는 이유도 이와 같다. 진행 상황은 말이 아니라 실제로 동작하는 코드로 측정된다.

---

외주 업체 선정 기준을 어떻게 비교 정리할 수 있을까?

외주 업체를 비교할 때 일반적으로 가격, 기술력, 속도 세 가지를 본다. 하지만 이 세 가지는 서로 독립적이지 않다. 아래 표는 외주 유형별로 이 요소들이 실제로 어떻게 다르게 작동하는지를 정리한 것이다.

이 비교에서 한 가지 주의할 점이 있다. "착수 속도"는 계약일로부터 코드가 실제로 쓰이기 시작하는 시점까지의 시간이다. 계약 체결을 착수로 보는 업체와 본 개발 진입을 착수로 보는 업체의 숫자는 같아도 실제 의미가 다르다. 비교할 때 같은 마일스톤을 기준으로 삼아야 한다.

AI 챗봇 개발 같은 비교적 명확한 범위의 프로젝트에서도 이 차이는 실제 납기에 영향을 준다.

---

자주 묻는 질문

사전 분석 단계에서 비용이 추가로 발생하는가?

나무숲의 초기 AX 컨설팅 상담은 무료로 제공된다. 사전 분석 단계의 범위와 비용 처리 방식은 프로젝트 규모에 따라 다르며, 상담 시 명확하게 안내된다. 이 단계의 비용 구조 자체가 투명성의 일부다.

2주 착수 기준이 모든 프로젝트에 적용되는가?

프로젝트의 복잡도에 따라 사전 분석에 필요한 시간이 달라질 수 있다. 2주는 요구사항이 어느 정도 정의된 상태를 전제로 한다. 요구사항 자체가 모호한 경우 이 단계를 거치는 데 시간이 더 걸릴 수 있으며, 그 경우 일정을 명시적으로 조정한다.

온프레미스 환경에서도 동일한 프로세스가 작동하는가?

나무숲은 클라우드와 온프레미스 환경 모두에서 개발 경험이 있다. 온프레미스의 경우 보안 요건과 인프라 접근 방식이 사전 분석 단계에서 추가 항목으로 포함된다. 기본 프로세스 구조는 동일하게 적용된다.

KPI 기반 마일스톤 계약이란 구체적으로 무엇을 의미하는가?

1주 단위로 달성해야 할 산출물과 기준을 계약에 명시하는 방식이다. 예를 들어 "3주차에 RAG 파이프라인 초안 동작 확인"처럼 추상적인 진행률이 아닌 실제 확인 가능한 결과물로 진행 상황을 측정한다. 마일스톤 미달 시 처리 방법도 계약에 포함된다.

AI-Native 팀과 일반 AI 개발 외주의 실질적 차이는 무엇인가?

핵심 차이는 AI가 개발 결과물인지, 개발 도구인지에 있다. 일반 외주는 AI를 납품하는 대상으로 다루고, AI-Native 팀은 전 팀원이 AI를 기본 작업 도구로 사용한다. 이 차이는 코드 작성 속도와 품질 검토 방식에 직접 영향을 준다.

---

AI 개발 외주 업체를 고를 때 기술력은 필요조건이지 충분조건이 아니다. 견적이 어떻게 산정되었는지, 착수가 실제로 언제 일어나는지, 분산 팀 내에서 요구사항이 어떻게 전달되는지가 프로젝트 성패를 가르는 경우가 많다. 나무숲은 이 세 가지를 사전 분석 단계에서 명문화한 뒤 2주 이내 본 개발에 진입하는 구조를 표준으로 삼고 있다. 구체적인 프로젝트 범위 검토와 착수 조건 확인은 나무숲 공식 채널에서 무료 초기 상담으로 시작할 수 있다.