[카테고리:] AI·데이터 활용

AI Agent 개발 비용 견적을 여러 곳에서 받아 본 기업이라면 대부분 같은 경험을 합니다. 동일한 요구사항 — 예컨대 “고객 문의에 답하는 챗봇” — 을 설명했는데, 한 곳은 수천만 원, 다른 곳은 수억 원을 제시하는 일이 드물지 않습니다. 열 배 차이입니다. 이 정도 편차가 나면 발주사 입장에서는 어느 쪽이 정상 가격인지 판단할 근거가 없고, 결국 “제일 싼 곳” 또는 “제일 비싼 곳이 제일 잘하겠지”라는 감으로 결정하게 됩니다. 둘 다 위험한 선택입니다.

결론부터 말씀드리면, 견적이 열 배씩 벌어지는 이유는 업체들이 폭리를 취해서가 아니라 각 업체가 상상하는 프로젝트의 범위가 서로 다르기 때문입니다. 그리고 그 범위를 정의하고 관리하는 책임을 누가 지느냐가, 최종적으로 지불하게 되는 총비용을 결정합니다.

디비컨설팅은 100건 이상의 프로젝트를 수행하며 이 문제를 반복적으로 다뤄 왔습니다. 삼성물산, GS건설, 하나투어, 직방, LS일렉트릭 등과의 프로젝트에서 검증된 것은 기술력만이 아니라 “요구사항을 정확히 정의하고 범위를 통제하는 관리 구조”였습니다. 이 글에서는 AI Agent 개발 비용을 실제로 움직이는 5가지 변수를 정리하고, 그 변수를 발주사가 직접 감당할 것인지, 관리 구조에 맡길 것인지를 판단할 수 있게 돕겠습니다.

견적 편차를 만드는 5가지 변수

범위: PoC인가, 실제 운영 시스템인가

가장 큰 편차는 여기서 발생합니다. 데모 환경에서 그럴듯하게 답하는 개념 검증(PoC) 챗봇과, 실제 고객 응대를 처리하는 운영 시스템은 다른 물건입니다. 후자는 오답 처리, 상담원 연결(에스컬레이션), 보안·개인정보 처리, 장애 대응, 응답 품질 모니터링까지 포함해야 합니다. 어떤 업체는 전자를, 어떤 업체는 후자를 견적한 것이라면 열 배 차이는 오히려 자연스럽습니다. 문제는 발주사가 자신이 어느 쪽을 원하는지 문서로 정의하지 않으면, 이 차이가 계약 후에야 드러난다는 점입니다.

데이터: 사내 데이터 정리·연동 비용

AI Agent는 회사의 데이터를 근거로 답할 때만 가치가 있습니다. 그런데 많은 기업의 사내 데이터는 흩어져 있고, 형식이 제각각이며, 최신본과 구버전이 섞여 있습니다. 이를 정리하고 검색 가능한 형태로 가공하는 작업이 AI 모델 자체보다 더 큰 비용이 되는 경우가 많습니다. 이 항목을 견적에 포함한 업체와 “데이터는 정리된 상태로 주시는 것”을 전제한 업체의 금액은 크게 다를 수밖에 없습니다.

연동 범위: 기존 시스템과 몇 개나 연결하는가

단독으로 동작하는 챗봇과, CRM에서 고객 정보를 조회하고 ERP에 주문을 기록하며 사내 메신저로 알림을 보내는 Agent는 개발 난이도가 전혀 다릅니다. 연동 대상 시스템이 하나 늘어날 때마다 인증, 권한, 예외 처리, 테스트 범위가 함께 늘어납니다. 견적 요청 시 연동 대상을 명시하지 않으면, 업체마다 다른 가정을 하고 다른 금액을 제시하게 됩니다.

모델 전략: 상용 LLM API 활용 vs 파인튜닝·자체 구축

상용 LLM API를 활용하면 초기 개발 비용은 낮지만 사용량에 비례하는 운영 비용이 계속 발생합니다. 반대로 파인튜닝이나 자체 구축은 초기 비용이 크지만 특정 조건에서는 운영 비용을 낮출 수 있습니다. 어느 쪽이 유리한지는 예상 사용량, 데이터 민감도, 응답 품질 요구 수준에 따라 달라지는 트레이드오프이며, 이 판단 없이 받은 견적은 서로 비교 자체가 불가능합니다.

운영 단계 비용: 견적서에서 가장 자주 빠지는 항목

AI Agent는 출시가 끝이 아닙니다. 응답 품질 모니터링, 프롬프트와 모델 업데이트, API 토큰 비용은 출시 후에도 계속 발생합니다. 낮은 초기 견적이 이 항목을 통째로 뺀 결과인 경우가 적지 않습니다. AI Agent 개발 비용을 비교할 때는 반드시 “출시 후 1년 운영 비용 구조”까지 묻고 비교해야 합니다.

발주 전에 확정해 두어야 할 항목 전체는 AI Agent 개발 외주, 발주 전에 반드시 정해야 하는 5가지에서, 요구사항을 어디까지 문서화해야 하는지는 요구사항 정의서 정리 가이드에서 자세히 다뤘습니다.

진짜 선택지는 세 가지입니다

위 5가지 변수를 보면 공통점이 보입니다. 전부 요구사항 정의의 문제라는 점입니다. 그리고 AI Agent는 일반 시스템 개발보다 요구사항 정의가 더 어렵습니다. “로그인 기능이 동작한다”는 검증이 명확하지만, “챗봇이 잘 답한다”는 성공 기준 자체가 모호하기 때문입니다. 성공 기준을 정의하고, 범위를 확정하고, 개발 과정에서 그것이 지켜지는지 검수하는 책임을 누가 지느냐 — 이것이 AI Agent 개발 비용의 실질적 결정 변수입니다.

이 관점에서 발주사의 선택지는 세 가지입니다.

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

국내 개발사는 안전하지만 단가가 높습니다. 해외 직접 발주는 단가는 낮지만, 성공 기준이 모호한 AI 프로젝트의 요구사항 정의와 검수를 발주사 담당자가 영어로 직접 수행해야 합니다. 사내에 AI 엔지니어링 조직이 없는 회사가 이를 감당하면, 재작업과 담당자 인건비가 단가 절감분을 잠식합니다. 기대만큼 싸지 않은 이유입니다.

세 번째 구조 — 한국인 PM이 검증된 글로벌 개발팀을 관리하는 방식 — 는 낮은 개발 단가를 유지하면서, 가장 어려운 요구사항 정의와 검수 책임을 한국어로 소통하는 PM이 대신 집니다. 총비용 관점에서 실질 절감이 가능한 유일한 조합입니다.

디비컨설팅은 이렇게 비용을 통제합니다

디비컨설팅의 AI Agent 개발 5단계 프로세스는 각 단계가 위의 비용 변수 하나씩을 통제하도록 설계되어 있습니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. PoC인지 운영 시스템인지, 성공 기준이 무엇인지를 개발 착수 전에 확정하므로, 비용 편차의 가장 큰 원인인 범위 불일치와 재작업이 이 단계에서 제거됩니다.
2. 개발팀 구성 — 전담팀을 2–4주 안에 구성합니다. 국내에서 AI 개발 인력을 직접 채용·유지하는 것과 비교해 평균 40–60%의 비용 절감 효과가 있으며, 채용 실패 리스크를 지지 않습니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자가 하루 종일 개발팀을 조율하는 데 시간을 쓰지 않아도 되므로, 견적서에 찍히지 않는 내부 인건비가 절약됩니다.
4. 테스트 및 배포 — 체계적인 QA를 거쳐 출시합니다. 출시 후 발견되는 결함은 가장 비싼 결함입니다. 이 단계가 재작업 리스크를 낮춥니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 지원합니다. 운영 단계 비용이 견적에서 누락되지 않도록 처음부터 구조화합니다.

실제 수행 프로젝트

아래는 이 팀과 프로세스가 실제로 납품해 온 프로젝트들입니다. 대기업 발주 기준의 요구사항 정의·품질 관리·일정 관리를 통과한 실적이며, 지금 AI Agent 시스템을 구축하는 것도 동일한 팀과 동일한 관리 구조입니다.

• 삼성물산 홈닉 — 주거 플랫폼 앱
• GS건설 엘리시안 리조트 — 웹·앱 통합
• 하나투어 하나오픈챗 — 여행 상담 채팅 서비스
• 직방 호갱노노 — 부동산 데이터 서비스
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 교보생명 사내벤처 글펍 — 커뮤니티 서비스

업종 경험은 교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT에 걸쳐 있습니다.

이런 기업에 적합합니다 / 이런 경우는 권하지 않습니다

적합한 경우

• AI Agent로 해결하려는 업무 문제는 분명하지만, 사내에 AI 개발 조직이 없는 기업
• 국내 개발사 견적이 예산을 초과했고, 해외 직접 발주를 직접 관리할 인력은 없는 기업
• PoC를 넘어 실제 운영까지 책임질 파트너를 찾는 기업

권하지 않는 경우

• 이미 사내 AI 엔지니어링 조직이 갖춰져 있고, 직접 통제를 원하는 경우 — 내재화가 맞는 선택일 수 있습니다.
• 성공 기준을 정의할 의사 없이 “일단 챗봇”을 원하는 경우 — 개발보다 업무 구조 진단이 먼저입니다.
• 최저가만이 유일한 기준인 경우 — 저희보다 싼 견적은 항상 존재하며, 그 견적이 빼놓은 항목의 비용은 결국 발주사가 지불하게 됩니다.

자주 묻는 질문

Q. 해외 개발팀인데 의사소통은 어떻게 하나요?
발주사는 한국인 PM하고만, 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 모두 PM의 책임입니다. 발주사가 영어로 개발자와 직접 소통할 일은 없습니다.

Q. 비용은 어떻게 산정되나요?
등급별 단가 × 투입 기간으로 산정하며, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. 무엇에 얼마가 드는지 보이지 않는 뭉뚱그린 총액 견적은 드리지 않습니다.

Q. 기획서가 없는데 견적을 받을 수 있나요?
가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3–5개, 대략의 일정·예산 범위만 있으면 개략 견적을 드릴 수 있습니다. 상세 범위는 상담 및 요구 분석 단계에서 함께 확정합니다.

Q. 소스코드 소유권은 누구에게 있나요?
발주사에 귀속됩니다. 소스코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 인계하므로, 이후 다른 팀이 이어받아도 문제가 없습니다.

Q. 출시 후 LLM 운영 비용은 어떻게 되나요?
견적 단계에서 개발 비용과 운영 비용 구조(API 사용량 기반 비용 등)를 분리해 제시합니다. 출시 후에 예상하지 못한 청구서를 받는 일이 없도록, 숨은 비용 없이 구조를 먼저 보여 드리는 것이 원칙입니다.

정리

AI Agent 개발 비용은 기술이 결정하지 않습니다. 범위를 얼마나 정확히 정의하는가, 그리고 그 정의와 검수의 책임을 누가 지는가 — 즉 관리 구조가 결정합니다. 열 배 차이 나는 견적서 앞에서 필요한 것은 더 많은 견적이 아니라, 범위 정의부터 운영까지를 한국어로 책임지는 구조입니다. 그 구조를 갖춘 파트너를 고르는 것이 가장 확실한 비용 통제입니다.

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 전환이 조직에서 멈추는 구조를 함께 보시면 도움이 됩니다.