AI 개발 외주 업체 선정 전, 포트폴리오 실작동 여부와 프로세스 데이터를 먼저 확인하라
AI 개발 외주 업체 선정 전 반드시 확인할 포트폴리오 실작동 검증법과 표준 개발 프로세스 점검 기준을 정리했습니다. 비개발자용 검증 질문 목록, 비용 정산 투명성 체크표, 계약 전 아키텍처 사전 검증 항목까지 일정 지연과 추가 비용을 막는 실전 방법을 지금 확인하세요.
계약서에 도장을 찍기 전에 반드시 확인해야 할 것이 두 가지 있다. 포트폴리오의 실제 작동 여부, 그리고 표준 개발 프로세스 보유 근거다. 이 두 가지를 사전에 검토하지 않으면 착수 이후 일정 지연과 불투명한 비용 정산 문제를 계약 후에야 마주하게 된다. 선정 단계에서 이를 체계적으로 검증하는 방법을 정리한다.
---
검증되지 않은 포트폴리오를 대세 기술로 포장하는 업체의 공통점
짧게 답하면 이렇다. 포트폴리오가 기능보다 기술 스택 목록 중심으로 서술되어 있고, 실 운영 환경에서의 동작 증거가 없는 경우, 해당 업체는 기술 구현 역량이 아니라 기술 용어 숙지도를 보여주고 있을 가능성이 높다.
흔한 패턴은 이렇다. 소개자료에 "RAG 파이프라인 구축", "LLM 파인튜닝", "멀티 에이전트 시스템" 같은 용어가 나열되어 있지만, 어떤 데이터셋으로 어떤 추론 품질을 구현했는지, API 레이턴시나 오류 처리 방식은 어떻게 설계했는지가 전혀 언급되지 않는다. 결과물의 스크린샷은 있으나 실제 배포 URL이나 테스트 계정이 제공되지 않는 경우도 마찬가지다.
주의해야 할 구체적 신호를 정리하면 다음과 같다.
- 포트폴리오 항목에 "AI 챗봇 개발"만 적혀 있고, 사용한 LLM API 버전, 프롬프트 구조, 응답 품질 개선 이력이 없다
- 구현 사례가 PoC(개념 검증) 수준에서 멈춰 있고 실 서비스 배포 이력을 확인할 수 없다
- "GPT-4 기반"이라는 표현만 있고, 어떤 문제를 해결했는지 문제 정의 자체가 빠져 있다
- 레퍼런스 고객사 이름은 있으나 해당 고객과의 직접 확인을 거부하거나 NDA를 포괄적으로 적용한다
레퍼런스 고객과의 확인을 과도한 NDA로 막는 경우는 특히 주의가 필요하다. 정상적인 프로젝트라면 기능 동작 여부와 일정 준수 여부 정도는 고객사 담당자가 간단히 확인해줄 수 있다. AI 개발 특성상 기밀이 필요한 부분과 기본 검증이 가능한 부분은 분리된다.
검증 없이 외주를 진행했을 때 실제로 어떤 문제가 발생하는지 상세히 다룬 글을 함께 보면 이 단계의 중요성이 더 명확해진다.---
표준 AI 개발 도구를 사용하지 않으면 일정이 지연되는 이유는 무엇인가?
일반 소프트웨어 개발과 AI 개발의 가장 큰 차이는 불확실성의 위치다. 일반 개발에서 불확실성은 주로 요구사항 변경에서 온다. AI 개발에서는 모델 동작 자체가 비결정론적이기 때문에, 동일한 입력에 대한 출력 품질을 일관되게 유지하기 위한 체계적 테스트 자동화가 필수다. 이 자동화가 없으면 매 스프린트마다 수동 품질 확인이 반복되고, 일정은 그 누적으로 밀린다.
표준 도구가 없는 팀의 전형적인 일정 지연 경로는 다음 표와 같다.
| 단계 | 표준 도구 없는 팀의 문제 | 결과 |
| 프롬프트 설계 | 버전 관리 없이 수동 수정 반복 | 이전 버전 복구 불가, 품질 퇴보 파악 지연 |
| 모델 평가 | 담당자 주관적 판단에 의존 | 품질 기준 불명확으로 검수 무한 반복 |
| 통합 테스트 | 자동화 없이 수동 E2E 확인 | 회귀 오류 늦게 발견, 수정-재테스트 루프 증가 |
| 배포 파이프라인 | CI/CD 없이 수동 배포 | 핫픽스 대응 지연, 스테이징 환경 부재 |
AI 에이전트 시스템에서는 문제가 더 복잡해진다. 단일 LLM 호출이 아니라 여러 에이전트가 연쇄적으로 동작하는 구조에서는, 각 노드의 출력 품질을 독립적으로 검증하는 테스트 계층이 없으면 어디서 오류가 발생했는지 추적 자체가 어렵다.
DORA(DevOps Research and Assessment) 지표에서도 배포 빈도, 변경 실패율, 복구 시간이 팀의 성숙도를 가늠하는 핵심 지표로 쓰인다. AI 개발 외주를 평가할 때도 동일한 기준을 적용할 수 있다. 업체가 이 지표들을 측정하고 있는지, 아니면 그 개념조차 공유하지 않는지를 확인하면 팀 수준을 빠르게 파악할 수 있다.
전 팀원이 AI 도구를 표준 개발 환경으로 사용하는 AI-Native 방식의 구체적 구조가 궁금하다면 AI-Native 개발 방식 소개 페이지를 참고할 수 있다.
---
착수 단계에서 비용 정산 투명성과 아키텍처 사전 검증을 확인하는 방법
이 두 가지는 별개처럼 보이지만 실제로는 연결되어 있다. 아키텍처가 사전에 명확히 정의되지 않으면 스코프 변경을 이유로 한 추가 비용 청구가 계약 후 언제든 발생할 수 있다. 반대로 아키텍처를 먼저 합의하면 변경 범위와 비용 영향을 사전에 측정 가능한 기준으로 만들 수 있다.
아키텍처 사전 검증에서 확인할 항목
계약 전 단계에서 업체가 제시해야 할 것은 다음과 같다.
- 사용 모델 및 API 버전 명시 (예: GPT-4o, Claude 3.5 Sonnet 등)
- 데이터 흐름 다이어그램 (어떤 데이터가 어떤 순서로 처리되는가)
- 온프레미스 또는 클라우드 배포 방식과 그 이유
- 에이전트 시스템의 경우 각 에이전트 역할 및 오케스트레이션 방식
- 실패 케이스 처리 정책 (LLM 호출 실패, 타임아웃, 응답 오류 등)
이 항목들을 업체가 질문 없이 자발적으로 제시하는가, 아니면 물어봐야 겨우 답하는가를 보면 팀의 설계 사고 수준을 알 수 있다.
비용 정산 투명성 확인 기준
| 확인 항목 | 좋은 신호 | 주의 신호 |
| 견적 산출 근거 | 기능 단위 공수 분리 명시 | "일괄 프로젝트 비용" 단일 항목 |
| 추가 비용 발생 조건 | 계약서에 스코프 변경 기준 명문화 | 구두 합의, 조건 모호 |
| 마일스톤 구조 | 주 단위 또는 기능 완료 단위 | 착수금 + 최종 납품 2단계만 |
| 중간 산출물 | 스프린트별 데모 가능 결과물 | "완성되면 한 번에 보여드림" |
| 정산 방식 | 마일스톤 완료 후 정산 | 선불 비중 과도 |
마일스톤 구조는 비용 정산뿐 아니라 품질 확인 주기와도 직결된다. 1주 단위 마일스톤과 KPI를 계약에 명시하는 방식이 가장 리스크를 낮춘다. 중간에 방향이 잘못되었을 때 조기에 수정할 수 있기 때문이다.
---
외주 업체의 기술 역량을 비개발자가 직접 검증하는 방법
기술 배경이 없는 의사결정자도 외주 업체의 기술 역량을 검증할 수 있다. 핵심은 "결과물을 보여달라"가 아니라 "어떤 방식으로 작업하는지 보여달라"고 요청하는 것이다.
실용적인 검증 질문 목록이다.
- "이 기능에서 가장 까다로운 엣지 케이스가 무엇이었나요?" — 실제 구현 경험이 있는 팀은 구체적인 사례로 답한다
- "LLM 응답 품질을 어떻게 평가하나요? 자동화된 테스트가 있나요?" — 품질 관리 체계가 있는지 확인
- "배포 후 3개월 이내에 발생한 문제와 대응 방식을 알려주세요" — 운영 역량과 문제 대응 방식 확인
- "현재 팀에서 사용하는 AI 보조 개발 도구가 무엇인가요?" — 실제 개발 환경 확인
이 질문들에 대한 답변이 구체적이고 일관성이 있다면, 해당 팀은 실제 프로젝트를 다수 경험했을 가능성이 높다. 반대로 추상적이고 범용적인 답변만 돌아온다면 포트폴리오의 실작동 여부를 다시 확인할 필요가 있다. 기술 검증 절차를 더 깊이 파고들고 싶다면 AI 개발 외주 업체 선정 시 기술 검증 방법을 함께 참고하면 좋다.
---
자주 묻는 질문
포트폴리오에 NDA가 걸려 있다고 하면 어떻게 검증하나요?
NDA 범위를 확인하면 된다. 고객사 이름과 기밀 데이터는 보호해야 하지만, 기능 동작 방식과 기술 스택, 일정 준수 여부는 NDA 대상이 되지 않는 경우가 많다. 업체에 "익명 처리된 기술 문서나 아키텍처 다이어그램"을 요청하거나, 유사 도메인의 공개 가능한 레퍼런스를 별도로 요청하는 것이 현실적인 방법이다.
계약 전 아키텍처 설계 요청이 무리한 요구인가요?
아니다. 오히려 정상적인 절차다. 착수 전 아키텍처 초안을 제시하지 못하는 업체는 스코프 정의가 불명확한 상태로 프로젝트를 시작하겠다는 의미다. 계약 전 단계에서 데이터 흐름 다이어그램과 주요 컴포넌트 구성을 요청하는 것은 발주자의 기본 권리에 해당한다.
AI 개발 외주 비용이 SI 업체보다 낮은 경우 품질을 신뢰할 수 있나요?
비용 규모 자체가 품질 지표는 아니다. AI 개발은 모델 API 비용과 클라우드 인프라 구조에 따라 구축 비용이 크게 달라진다. 중요한 것은 견적 산출 근거가 기능 단위로 분리되어 있는지, 마일스톤별 검수 기준이 명확한지다. 저비용이라도 이 두 조건이 충족된다면 신뢰 가능한 파트너다.
오픈소스 기여 이력이 기술 역량 검증에 도움이 되나요?
도움이 된다. GitHub 저장소의 스타 수보다는 코드 품질, 문서화 수준, 이슈 대응 방식을 보는 것이 더 정확하다. 특히 AI 관련 오픈소스 도구를 직접 제작하고 유지하는 팀은 해당 기술 영역을 단순 사용자가 아닌 구현자 수준으로 이해하고 있다는 근거가 된다.
AI 에이전트 시스템 외주 시 일반 AI 챗봇과 다르게 확인해야 할 점이 있나요?
에이전트 시스템에서는 단일 LLM 호출이 아니라 여러 에이전트가 연쇄 동작한다. 각 에이전트의 역할 분리, 오케스트레이션 방식, 실패 복구 로직이 설계 단계에서 명확히 정의되어 있는지 확인해야 한다. 이 구조가 없으면 통합 이후 오류 추적이 사실상 불가능해진다.
---
계약 전 포트폴리오의 실작동 여부와 표준 AI 개발 프로세스 보유 근거를 확인하는 것, 이것이 일정 지연과 불투명한 비용 문제를 사전에 막는 유일한 방법이다. 화려한 기술 용어 목록이 아니라 실제 배포 이력, 테스트 자동화 체계, 마일스톤 기반 정산 구조를 기준으로 업체를 평가해야 한다. 주식회사 포텐랩(트리숲)은 계약 전 아키텍처 사전 검증과 1주 단위 마일스톤 정산을 표준으로 운영하며, AX 컨설팅 기술 검증 상담을 통해 프로젝트 착수 전 구조 검토를 무료로 제공한다.
---
*글쓴이: 남대현 | TreeSoop CEO, POSTECH 컴퓨터공학 AI/MR/HCI 석사*
AI 관련 프로젝트가 필요하시면 카카오톡으로 문의하세요.