AI 개발 외주를 결정할 때 가장 먼저 흔들리는 건 기술 신뢰다. "혁신적인 AI 솔루션"이라는 말은 영업 자료마다 가득하지만, 실제로 논문 속 모델을 운영 환경에 올려본 팀인지, 아닌지는 몇 가지 질문만으로 드러난다. 이 글은 그 질문을 어떻게 던지고 무엇을 확인해야 하는지를 다룬다.
CTO가 가장 먼저 보는 것 — 과장 탐지
기술 담당자가 영업 미팅에서 제일 먼저 하는 일은 과장 탐지다. "AI 기반", "딥러닝 활용", "최첨단 아키텍처" 같은 표현은 실질적 정보가 없다. 실제로 물어볼 수 있는 건 이렇다.
- 어떤 모델을 썼는가? Fine-tuning인가, RAG인가, 프롬프트 엔지니어링인가?
- 그 선택의 근거는 무엇인가?
- 운영 환경에서 레이턴시와 비용을 어떻게 측정했는가?
이 세 가지에 바로 답하는 팀과 그렇지 못한 팀은 다르다. 구현 경험 없이 외주를 받은 팀은 대개 두 번째 질문에서 막힌다. 선택의 근거가 있으려면 다른 선택지를 직접 시도해봤어야 하기 때문이다.
오픈소스 기여 이력은 좋은 신호다. 공개된 코드는 숨길 수 없다. GitHub에서 해당 팀의 레포지토리를 보면 실제로 어떤 수준에서 작업했는지 금방 확인된다. 커밋 히스토리, 이슈 논의 방식, 테스트 커버리지—이것들이 포트폴리오 PDF보다 훨씬 솔직하다.
구현 능력은 어떻게 검증할 수 있을까?
기술 신뢰를 말이 아니라 코드로 확인하는 방법이 있다. 계약 전 기술 검증 세션을 요청하는 것이다. 30~60분짜리 기술 미팅에서 다음 두 가지를 해달라고 하면 된다.
첫째, 최근 완료한 프로젝트의 아키텍처 다이어그램을 화이트보드에서 설명해달라. 실제 구현한 팀이라면 왜 그 구조를 선택했는지, 어떤 트레이드오프가 있었는지를 즉석에서 말한다. 외주를 다시 재외주한 팀이라면 설명에 빈틈이 생긴다.
둘째, 비슷한 문제를 어떻게 접근할지 라이브로 보여달라. 예를 들어 문서에서 특정 정보를 추출하는 파이프라인을 짧게 스케치해달라고 하면 된다. 의사코드 수준이라도 상관없다. 여기서 LangChain을 쓸지 직접 구현할지, 왜 그런 선택을 하는지를 들으면 충분하다.
아래는 실제 검증 과정에서 AI 문서 추출 파이프라인의 접근 방식을 확인할 때 쓸 수 있는 의사코드 예시다. 업체에게 이 정도 수준의 설명을 요구하는 것 자체가 이미 필터 역할을 한다.
# 문서 추출 파이프라인 — 접근 방식 확인용 예시
# 외주 업체가 이 구조의 선택 이유를 설명할 수 있는지 보는 것이 목적
def extract_from_document(document: bytes, extraction_schema: dict) -> dict:
"""
접근 방식 1: LLM 직접 호출 (비용 높음, 유연성 높음)
접근 방식 2: 구조화된 파서 + LLM fallback (비용 낮음, 정형 문서에 적합)
접근 방식 3: Fine-tuned 모델 (초기 비용 높음, 반복 비용 낮음)
선택 기준: 문서 다양성, 처리 볼륨, 정확도 요구 수준
"""
parsed_text = parse_pdf(document) # pdfplumber 또는 pymupdf
# 구조화된 필드는 규칙 기반으로 먼저 처리
structured_fields = rule_based_extract(parsed_text, extraction_schema)
# 비정형 필드만 LLM에 위임
unstructured_fields = llm_extract(
text=parsed_text,
fields=[f for f in extraction_schema if f not in structured_fields],
model="claude-3-5-sonnet" # 또는 비용에 맞는 모델 선택
)
return {**structured_fields, **unstructured_fields}
이 코드를 외주 업체에게 보여주고 "우리 요구사항에는 어떤 접근 방식이 맞나요?"라고 물어보면 된다. 트레이드오프를 설명하는 팀과 "다 됩니다"라고 답하는 팀을 바로 구분할 수 있다.
연구에서 운영까지 한 팀이 책임지는 구조가 왜 중요한가?
AI 개발에서 가장 흔한 실패 패턴 중 하나는 R&D팀과 개발팀이 분리된 구조다. 연구팀이 PoC를 만들고 개발팀에 넘기는 순간, 두 가지가 사라진다. 맥락과 책임이다.
맥락이 사라지면 모델 선택의 이유, 데이터 전처리 결정, 성능 트레이드오프 같은 암묵지가 전달되지 않는다. 개발팀은 코드를 받아 운영하지만 왜 그렇게 짰는지를 모른다. 장애가 나면 원인을 찾는 데 시간이 두 배 걸린다.
책임이 사라지면 품질 기준이 낮아진다. "PoC에서는 됐는데 운영에서 왜 안 되나요?"라는 상황이 만들어진다. 이건 구조 문제다. 운영 환경의 노이즈, 실제 데이터 분포, 엣지 케이스는 PoC 단계에서 경험한 팀만 대비할 수 있다.
한 팀이 연구부터 운영까지 책임지는 구조는 이 두 가지 손실을 막는다. 아젠틱 AI 시스템 구축처럼 여러 에이전트가 협업하는 복잡한 구조일수록 이 연속성이 더 중요해진다. 연구자가 설계한 에이전트 간 인터페이스를 개발자가 직접 구현해야 실제 병목이 어디서 발생하는지 알 수 있다.
DORA(DevOps Research and Assessment) 메트릭에서 배포 빈도와 장애 복구 시간이 팀 구조와 강하게 연관된다는 점은 잘 알려져 있다. AI 시스템도 다르지 않다. 연구-개발-운영 사이클이 한 팀 안에 있을수록 피드백 루프가 짧아진다.
공개 검증 가능한 기술 자산 — 오픈소스와 팀 구성
나무숲은 GitHub에 오픈소스 자산 ★120+ 를 공개하고 있다. 이건 자랑이 아니라 검증 가능한 사실이다. 계약 전에 직접 확인할 수 있다.
팀 구성도 확인 가능하다. POSTECH·KAIST·서울대 출신 개발 인력이 팀 안에 있다는 건, 논문 수준의 기술을 제품으로 옮기는 능력이 내부에 있다는 의미다. 이를테면 컴퓨터 비전 모델을 실제 제조 공정에 붙이거나, 자연어 처리 기술을 도면 부품 추출에 적용하는 작업이다.
누적 41건 프로젝트(R&D 12건 + AX 10건 + 외주 19건)와 위시켓 평점 4.92는 공개 플랫폼에서 확인할 수 있다. 숫자 자체보다 중요한 건 R&D와 AX(AI 전환) 프로젝트가 외주 건수만큼 쌓여 있다는 점이다. 단순 개발 외주와 AI 연구개발을 같은 팀이 처리해온 이력이다.
감정 AI 구현 사례나 AI 스타트업 챗봇 사례에서 실제 구현 방식을 확인할 수 있다. 포트폴리오를 볼 때 결과 수치보다 아키텍처 선택과 트레이드오프 설명이 있는지를 먼저 본다.
계약 전 반드시 던져야 할 기술 질문 5가지
이 질문들을 계약 전에 던지고, 답변의 구체성을 기준으로 업체를 평가한다.
| 번호 | 질문 | 좋은 답변의 특징 | 경계 신호 |
|---|---|---|---|
| 1 | 이 문제에 어떤 모델 아키텍처를 쓸 것이며, 왜 그 선택인가? | 구체적 모델명 + 선택 근거 + 대안 비교 | "최신 AI 기술을 활용합니다" |
| 2 | 운영 환경에서 레이턴시와 비용을 어떻게 모니터링할 계획인가? | 구체적 툴(Prometheus, CloudWatch 등) + 임계값 설정 방식 | "운영 후 확인하겠습니다" |
| 3 | 데이터가 부족하거나 레이블이 없는 경우 어떻게 접근하는가? | 약지도 학습, 데이터 증강, 사전학습 모델 활용 전략 언급 | "데이터를 더 모아야 합니다"만 반복 |
| 4 | 이 팀에서 R&D와 개발을 모두 담당한 경험이 있는가? | 구체적 프로젝트 예시 + 담당자 이름 | 포트폴리오 PDF만 전달 |
| 5 | 장애 발생 시 대응 프로세스와 SLA는 어떻게 정의하는가? | 장애 등급 + 대응 시간 + 에스컬레이션 절차 | "최선을 다하겠습니다" |
다섯 번째 질문은 기술 역량과 직접 관계없어 보이지만, AI 시스템은 결정론적이지 않다. 같은 입력에 다른 출력이 나올 수 있고, 모델 드리프트가 서서히 발생한다. 이걸 운영 관점에서 설명하는 팀이 실제로 AI를 운영해본 팀이다.
자주 묻는 질문
포트폴리오만 봐도 기술 수준을 판단할 수 있을까?
포트폴리오만으로는 부족하다. 결과 화면과 기능 목록은 외부 라이브러리 조합으로도 만들 수 있다. 아키텍처 설계 이유, 모델 선택 근거, 실패 사례와 대응 방식을 직접 물어봐야 실제 구현 역량이 드러난다.
오픈소스 기여 이력이 없는 팀은 배제해야 할까?
반드시 그렇지는 않다. 단, 공개 검증 수단이 없다면 다른 방식으로 확인해야 한다. 기술 미팅에서 실시간 아키텍처 설명, 코드 리뷰 샘플 요청, 레퍼런스 체크가 대안이 된다.
R&D 역량과 제품 개발 역량은 다른 팀에서 받으면 안 되나?
불가능하진 않다. 다만 두 팀 사이의 인터페이스 설계와 맥락 전달을 누가 책임지는지를 명확히 해야 한다. 이 연결이 흐릿한 구조에서 AI 프로젝트 지연이 가장 자주 발생한다.
AI 개발 외주와 일반 소프트웨어 외주의 검증 방식이 다른가?
다르다. 일반 소프트웨어는 스펙 충족 여부로 검증하지만, AI 시스템은 성능 분포, 엣지 케이스 처리, 모델 드리프트 대응까지 확인해야 한다. 계약서에 이 항목들을 어떻게 정의했는지가 핵심이다.
착수 속도와 기술 깊이는 트레이드오프인가?
팀 구조에 달려 있다. 전원이 같은 AI 개발 환경을 표준으로 사용하는 팀이라면 착수를 빠르게 시작하면서도 기술 깊이를 유지할 수 있다. 이 두 가지가 트레이드오프로 느껴진다면, 그 팀은 AI 개발 환경이 아직 통일되지 않은 곳일 가능성이 높다.
기술 담당자로서 AI 개발 외주를 고를 때 가장 피해야 할 건 "됩니다"라는 답변에 안심하는 것이다. 구체적인 트레이드오프를 설명하고, 공개 검증 가능한 기술 자산이 있으며, 연구부터 운영까지 같은 팀이 책임지는 구조인지를 확인하는 것—이 세 기준이 계약 후 후회를 막는 실질적인 필터다. 구체적인 기술 검증을 원한다면 나무숲 기술 상담에서 직접 확인할 수 있다.
더 보기: treesoop.com
Top comments (0)