AI Agent 개발 외주, 발주 전에 반드시 정해야 하는 5가지

AI Agent 개발 외주가 실패하는 가장 흔한 형태는 개발이 끝나지 않는 것이 아니라, 개발이 끝났는데 아무도 쓰지 않는 것입니다. 시연 자리에서는 잘 돌아갑니다. 들어온 문의를 읽고 분류하고 답변 초안까지 만들어 냅니다. 그런데 실제 업무에 넣는 단계에서 현업 담당자가 이렇게 묻습니다. “이 답변, 확인 없이 그냥 나가는 겁니까?” 그 자리에서 대답할 수 있는 사람이 없습니다.

그날부터 그 에이전트는 담당자가 결과를 전부 다시 확인하는 도구가 됩니다. 두 번 확인하는 일이 처음부터 직접 하는 일보다 번거로워지는 순간 사용은 멈추고, 반년 뒤 그 프로젝트는 “우리도 해 봤는데 잘 안 됐다”로 정리됩니다. 문제는 모델의 성능이 아니었고, 개발사의 실력도 아니었습니다. 착수 전에 정해야 했던 한 가지, 어디까지 에이전트가 스스로 판단하고 실행하며 어디부터 사람이 승인하는가를 아무도 문서로 정하지 않았을 뿐입니다.

디비컨설팅은 시원스쿨(Siwon School)의 자회사로, 한국인 PM이 검증된 글로벌 개발팀을 직접 관리하는 구조로 IT 아웃소싱을 수행하고 있습니다. 지금까지 100건 이상의 프로젝트를 진행했고, 50개 이상의 글로벌 파트너사와 협업 체계를 갖추고 있으며, 고객 만족도는 98%입니다. 삼성물산 홈닉, GS건설 엘리시안 리조트, 하나투어 하나오픈챗, 직방 호갱노노, LS일렉트릭 테크스퀘어, 교보생명 사내벤처 글펍이 그 결과물입니다(전체 포트폴리오). 이 글에서 말씀드리는 내용은 방법론에서 나온 것이 아니라, 요구사항이 비어 있는 상태로 시작된 프로젝트가 어디서 어떻게 무너지는지를 반복해서 본 경험에서 나온 것입니다.

왜 AI Agent 외주는 일반 개발 외주와 다르게 실패하는가

요구사항이 화면이 아니라 판단 기준입니다

일반적인 앱이나 웹 개발에서 요구사항은 화면 단위로 확정됩니다. 이 화면에서 이 버튼을 누르면 이 데이터가 저장되고 다음 화면으로 넘어간다. 문장으로 쓸 수 있고, 쓰인 대로 만들어졌는지 눈으로 검수할 수 있습니다. 발주사와 개발사의 인식 차이가 있어도 화면을 열어 보면 드러납니다.

AI Agent 개발은 다릅니다. 에이전트에게 지시하는 것은 화면이 아니라 판단 기준입니다. 어떤 문의를 자동으로 처리하고 어떤 문의를 사람에게 넘길지, 재고가 기준 이하로 떨어졌을 때 발주를 올릴지 담당자에게 알림만 보낼지, 계약서에서 이상 조항을 발견했을 때 경고만 표시할지 승인 절차를 막을지. 이런 기준은 화면 설계서에 들어가지 않습니다. 그리고 개발사가 대신 정할 수 없습니다. 그 업무를 매일 하는 사람만 정할 수 있는 내용이기 때문입니다.

정답이 하나가 아닙니다

일반 개발에서 버그는 명확합니다. 합계 금액이 틀렸으면 틀린 것이고, 고치면 끝납니다. AI Agent에서는 “틀렸다”의 기준부터 합의해야 합니다. 요약이 너무 짧은 것은 오류입니까, 취향입니까. 애매한 문의를 사람에게 넘긴 것은 안전한 판단입니까, 자동화 실패입니까. 이 기준이 문서에 없으면 검수 회의는 매번 인상 비평으로 흐릅니다. 개발팀은 무엇을 어느 방향으로 고쳐야 하는지 알 수 없는 상태에서 수정 요청을 받고, 고친 결과가 다시 다른 사람의 기준에 걸립니다. 일정이 늘어나는 구간은 대부분 여기입니다. 견적의 1.5배가 되는 일은 드물지 않습니다. 이 구조는 AI 프로젝트에 국한된 것이 아니며, IT 외주개발 비용이 견적보다 항상 더 나오는 구조와 원인이 같습니다.

틀렸을 때의 처리를 아무도 정의하지 않습니다

그리고 대부분의 발주 문서에서 빠져 있는 항목이 있습니다. 에이전트가 잘못 판단했을 때 무슨 일이 일어나는가입니다. 누구에게 알림이 가는지, 판단 근거가 어디에 기록되는지, 잘못 나간 처리를 되돌릴 수 있는지, 그 결과에 대한 책임을 사내에서 누가 지는지.

이것이 정의되지 않으면 결과는 정해져 있습니다. 현업 부서가 에이전트에 실제 권한을 주지 않습니다. 권한이 없는 에이전트는 업무 흐름 안에 들어가지 못하고, 기술적으로는 동작하지만 아무도 의지하지 않는 데모로 남습니다. 실패의 원인은 모델도 개발사도 아니고, 발주 단계에서 비어 있던 이 한 줄입니다. IT 외주 프로젝트의 절반 이상이 납기 후 분쟁으로 끝나는 이유도 결국 같은 공백에서 출발합니다.

발주 전에 정해야 하는 5가지

AI Agent 개발 외주를 준비하면서 착수 전에 정해 두어야 하는 항목은 다섯 가지입니다. 다섯 가지 모두 기술 문서가 아니라 업무 결정이며, 정하지 않은 항목은 개발사가 추측으로 메우게 됩니다.

1. 자동 실행 범위와 사람 승인 지점

가장 먼저 정해야 하고 가장 자주 비어 있는 항목입니다. 에이전트가 다루는 업무를 세 칸으로 나누시기 바랍니다. 사람 확인 없이 실행해도 되는 일, 사람이 승인한 뒤에만 실행하는 일, 에이전트가 아예 손대지 않는 일입니다.

이 구분의 기준은 기술이 아닙니다. 금액 규모, 고객 등급, 계약 유형, 대외로 나가는 문서인지 여부처럼 회사가 감당할 수 있는 위험의 크기로 정해집니다. 즉 경영 판단입니다. 발주사가 정하지 않으면 개발사는 가장 안전한 쪽을 택합니다. 모든 처리를 사람 승인 대기로 설계하는 것입니다. 그러면 시스템은 오류 없이 동작하지만 업무 시간은 줄지 않고, 프로젝트의 목적 자체가 사라집니다. 이 구분을 먼저 잡기 위해 업무를 반복 구간과 판단 구간으로 나누는 진단부터 진행하는 경우가 많습니다.

2. 사용할 사내 데이터의 범위와 접근 권한

에이전트가 무엇을 볼 수 있는지를 목록으로 확정해야 합니다. 어느 시스템의 어느 테이블까지 접근하는지, 개인정보가 포함된 항목은 마스킹할지 아예 제외할지, 사내 시스템 접근은 읽기 전용인지 쓰기까지 허용하는지, 접근 이력을 어디에 남길지가 여기에 포함됩니다.

이 결정이 늦어지면 개발은 임시 데이터로 진행됩니다. 그리고 실제 데이터를 연결하는 단계에서 데이터 구조와 권한 처리를 다시 만들게 됩니다. 재작업 규모가 가장 크게 발생하는 지점이며, 보안 검토가 필요한 기업이라면 검토 일정 자체가 개발 일정보다 길어질 수 있습니다. 착수 시점에 정보보안 담당자를 넣어 두시는 편이 낫습니다.

3. 오답·실패 시의 처리 절차

에스컬레이션, 로그, 책임 세 가지를 문서로 남기시기 바랍니다. 에이전트가 판단을 유보했을 때 누구에게 넘어가는지, 근무 시간 외에는 어떻게 처리되는지, 입력과 판단 근거와 출력을 어느 수준까지 얼마나 보관할지, 잘못 나간 처리를 되돌리는 절차가 있는지, 그리고 최종 책임이 어느 부서에 있는지입니다.

로그는 개발팀의 디버깅 자료가 아니라 발주사의 업무 자료입니다. 고객 불만 대응, 내부 감사, 규제 대응이 필요한 순간에 “왜 이렇게 처리되었는가”를 설명할 수 있어야 합니다. 이 요구사항은 나중에 추가하기 어렵습니다. 설계 단계에서 들어가야 합니다.

4. 성능을 무엇으로 판정할지

정확도만으로 검수 기준을 잡으면 프로젝트는 끝나지 않습니다. 정확도는 올리면 또 올릴 수 있는 지표이고, 어느 수치에서 멈춰야 하는지를 알려 주지 않습니다. 업무 지표를 함께 정해야 합니다.

건당 처리 시간이 몇 분에서 몇 분으로 줄면 성공인지, 사람에게 넘어가는 비율이 어느 선 이하면 수용하는지, 담당자가 결과를 수정 없이 그대로 사용하는 비율이 어느 정도면 되는지, 월 처리 건수 기준으로 몇 사람 몫의 시간이 회수되면 되는지를 숫자로 적어 두시는 것이 좋습니다. 이 기준은 착수 전에 계약 문서에 들어가야 합니다. 결과물을 받은 뒤에 정하면 그것은 검수가 아니라 협상이 됩니다.

5. 소스코드·프롬프트·학습 데이터의 소유권

소스코드, 프롬프트, 학습이나 튜닝에 사용한 데이터와 그 산출물, 검색용 인덱스, 배포 스크립트 가운데 무엇이 발주사에 귀속되는지 계약서에 명시되어 있어야 합니다.

AI Agent에서는 코드만큼 프롬프트와 평가 데이터가 자산입니다. 코드는 받았지만 프롬프트와 평가 기준을 받지 못하면, 다음 개선을 같은 개발사에만 맡길 수 있는 상태가 됩니다. 디비컨설팅은 결과물 일체를 발주사 귀속으로 진행하며, API 명세와 DB 스키마, 배포 절차 문서까지 함께 인계합니다.

세 가지 발주 방식의 비교

AI Agent 개발 외주를 검토하는 기업이 실제로 놓고 고민하는 선택지는 보통 세 가지입니다.

구분	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

눈여겨보실 칸은 “요구사항 정의 책임”과 “발주사 담당자 투입 시간”입니다. 해외에 직접 발주하면 개발 단가가 낮아지는 것은 사실입니다. 그러나 낮아지는 것은 단가뿐이고, 이 글에서 계속 말씀드린 가장 어려운 일, 즉 판단 범위를 정의하고 영어로 전달하고 산출물을 검수하는 일은 발주사 담당자에게 그대로 넘어옵니다. 사내에 AI나 개발 조직이 없는 기업이라면 그 일을 할 사람이 없습니다. 요구사항을 영어 문서로 옮길 사람, 시차를 두고 올라온 질문에 그날 답할 사람, 받은 산출물이 요구사항과 다르다는 것을 알아볼 사람이 각각 필요합니다. 이 역할이 비면 개발팀은 스스로 판단해서 만들고, 그 판단이 업무와 맞지 않으면 재작업이 발생합니다. 초기 단가에서 30%를 아끼고 2차 개발에서 그보다 많은 비용을 쓰는 구조가 여기서 생깁니다.

디비컨설팅이 이 리스크를 통제하는 방식

디비컨설팅은 AI Agent 개발 외주에서 발생하는 리스크를 한국인 PM이 요구사항 정의와 검수를 책임지는 구조로 통제합니다. 발주사는 영어로 소통하지 않고, 개발팀을 직접 관리하지 않습니다. 진행은 다섯 단계입니다.

1단계 · 상담 및 요구 분석

비즈니스 목표와 기술 요구사항을 한국인 PM이 한국어로 문서화합니다. 앞에서 말씀드린 다섯 가지 항목, 특히 자동 실행 범위와 사람 승인 지점, 오답 처리 절차, 검수 기준을 이 단계에서 확정합니다. 재작업의 대부분이 이 단계에서 제거됩니다. 발주사가 하는 일은 업무를 아는 담당자를 회의에 앉히는 것이고, 그 내용을 개발 가능한 요구사항으로 바꾸는 일은 PM이 합니다.

2단계 · 개발팀 구성

확정된 요구사항에 맞춰 전담팀을 2~4주 내에 구성합니다. 검증된 글로벌 개발 인력으로 구성하며, 국내 채용 대비 평균 40~60%의 비용 절감이 발생합니다. 필요한 역할만 투입하므로 프로젝트 성격에 따라 구성이 달라집니다.

3단계 · 프로젝트 개발

애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 일정, 이슈, 결정 대기 항목을 정리해 전달하므로 발주사 담당자가 개발팀 조율에 하루를 쓰는 일이 없습니다. 발주사가 판단해야 하는 사항만 정리된 형태로 올라갑니다.

4단계 · 테스트 및 배포

1단계에서 확정한 검수 기준으로 QA를 수행한 뒤 릴리스합니다. 기준이 착수 전에 문서화되어 있으므로, 검수는 합격 여부 확인이 되고 재협상이 되지 않습니다.

5단계 · 운영 및 유지보수

소스코드와 함께 API 명세, DB 스키마, 배포 절차 문서를 인계하고 장기 지원을 제공합니다. 운영 중 확인된 판단 오류를 기준에 반영하는 개선 작업도 여기에 포함됩니다.

실제 구축 사례

• 삼성물산 홈닉 — 주거 플랫폼 앱
• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합
• 하나투어 하나오픈챗 — 여행 상담 채팅 서비스
• 직방 호갱노노 — 부동산 데이터 서비스
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼(B2B 플랫폼에 AI Agent를 적용한 매칭 구조)
• 교보생명 사내벤처 글펍 — 커뮤니티 서비스
• 가천대학교 — 학사관리 시스템
• 센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 와디즈 — 글로벌 플랫폼

구축 경험이 있는 산업은 교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT입니다.

이런 기업에 적합합니다 / 반대로 권하지 않습니다

적합합니다

• 자동화하려는 업무는 명확하지만, 그 업무를 요구사항 문서로 바꿀 인력이 사내에 없는 기업
• 사내에 개발 조직이 없거나 소수여서, 해외 개발팀을 직접 관리할 여력이 없는 기업
• 데모가 아니라 실제 업무 흐름에 들어가는 시스템이 필요한 기업
• 국내 채용이나 국내 개발사 단가로는 예산이 맞지 않는 기업
• 소스코드와 문서를 자사 자산으로 확보해 두어야 하는 기업

반대로 권하지 않습니다

• 사내에 이미 AI 조직과 MLOps 체계가 갖춰져 있는 기업입니다. 요구사항 정의와 개발팀 관리를 직접 하실 수 있다면, 저희가 담당하는 영역의 값을 지불하실 이유가 없습니다.
• 판단 범위를 정할 업무 담당자를 프로젝트에 붙일 수 없는 기업입니다. 자동 실행 범위와 승인 지점은 저희가 대신 정할 수 없습니다. 그 결정을 내릴 사람이 없다면 어느 개발사와 하셔도 결과는 같습니다.
• 3주 안에 투자 심사나 내부 보고용 데모만 필요한 경우입니다. 요구사항을 문서로 확정하는 저희 방식은 그 일정에 맞지 않고, 그 목적이라면 더 빠른 방법이 있습니다.
• 예산 규모가 아직 검토 단계이고 착수 시점도 미정인 경우입니다. 개략 견적은 도움이 되지만, 팀 구성까지 진행하기에는 이릅니다.

자주 묻는 질문

개발팀이 해외에 있으면 의사소통은 어떻게 됩니까.
발주사는 한국인 PM과만 한국어로 소통하십니다. 요구사항 정의, 일정 관리, 산출물 검수가 모두 PM의 책임이며, 개발팀과의 영어 커뮤니케이션은 PM이 처리합니다. 발주사 담당자가 영어로 회의에 참여하거나 개발자에게 직접 지시하는 구조가 아닙니다.

비용은 어떻게 산정됩니까.
투입 인력의 등급별 단가에 투입 기간을 곱하는 방식으로 산정하며, 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시합니다. 총액만 적힌 견적서는 드리지 않습니다. 어느 항목에 얼마가 들어가는지 보이지 않으면 범위를 조정할 수 없기 때문입니다. 국내 채용 대비로는 평균 40~60% 수준의 비용 절감이 발생합니다.

기획서가 없는 상태에서도 견적을 받을 수 있습니까.
가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 희망 일정과 예산 범위만 정리해 주시면 개략 견적을 드립니다. 상세 견적은 상담과 요구 분석을 거쳐 요구사항이 확정된 뒤에 나옵니다. 기획서 작성 자체를 저희가 함께 진행하는 경우도 많습니다.

진행 중에 팀 규모를 조정할 수 있습니까.
전담팀, 장기 협업, 인력 단위, 프로젝트 단위 가운데 선택하실 수 있고, 진행 중 조정이 가능합니다. 초기 개발 구간에는 인력을 늘리고 안정화 이후 축소하는 형태가 일반적입니다.

소스코드는 누구 소유가 됩니까.
발주사에 귀속됩니다. 소스코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 인계하므로, 이후 유지보수를 다른 조직에 맡기시더라도 인수가 가능합니다.

정리

AI Agent 개발 외주의 성패는 개발 실력보다 요구사항을 한국어로 정의하고 그 정의에 책임지는 주체가 있는지에서 갈립니다. 에이전트가 어디까지 스스로 판단하고 어디부터 사람이 승인하는지, 틀렸을 때 무엇이 어떻게 처리되는지, 성공을 어떤 업무 지표로 판정할지는 개발사가 대신 정해 줄 수 없는 경영 판단입니다. 그러나 사내에 AI나 개발 조직이 없는 기업이 이 판단을 문서로 만들어 해외 개발팀에 영어로 전달하고 결과를 검수하는 일까지 직접 감당하기는 어렵습니다. 그래서 필요한 것이 단가 낮은 개발팀이 아니라, 그 개발팀 앞에서 요구사항을 확정하고 책임지는 한국인 PM입니다. AI 전환이 조직에서 멈추는 구조를 함께 보시면 도움이 됩니다.