업무 자동화를 외주로 맡기는 회사가 빠르게 늘고 있습니다. 반복 수작업을 줄이고 싶다는 목표는 명확한데, 막상 업체를 고르고 계약서에 사인하는 과정에서 중요한 것을 놓치는 경우가 많습니다. 납품 후에야 "이건 우리가 원하던 것과 다릅니다"가 나오거나, 아무도 건드릴 수 없는 시스템이 됐다는 걸 알게 됩니다.
상담을 하다 보면 "이전에 다른 업체에 맡겼다가 낭패를 봤습니다"라는 이야기를 자주 듣습니다. 들어보면 대부분 같은 패턴입니다. 요구사항이 모호한 상태로 시작했거나, 코드 소유권이 업체에 남아 있거나, 유지보수 비용이 납품 후 갑자기 청구됐거나, 시스템이 블랙박스가 됐거나. 계약서에 항목 하나가 빠졌을 뿐인데 이후가 완전히 달라집니다.
아래 7가지는 외주 계약 도장을 찍기 전에 반드시 확인해야 할 항목입니다. 기술에 익숙하지 않은 분도 체크리스트로 바로 쓸 수 있도록 풀어서 썼습니다.
1. 요구사항이 문서로 정리되어 있는가
가장 흔하고 가장 치명적인 문제입니다. "보고서를 자동으로 만들어 달라"는 말은 개발사 입장에서 아무 정보도 없는 말과 같습니다. 어떤 데이터를, 어떤 형식으로, 어느 타이밍에, 어떤 사람에게, 어떤 형태로 전달하는 보고서인지를 알아야 만들 수 있습니다.
IT 프로젝트가 실패하는 첫 번째 공통 패턴은 사업 요구사항을 명확히 정의하지 않은 경우입니다. 발주사가 "이런 기능이요"라고 두루뭉술하게 설명하면, 개발사는 자신이 이해한 방식대로 만들어 납품합니다. 완성된 결과물을 받고 나서야 서로 전혀 다른 것을 생각하고 있었다는 걸 알게 됩니다. 이 해석 차이가 납품 이후 분쟁의 씨앗이 됩니다.
견적서와 계약서에는 기능 목록뿐 아니라 제외 항목도 반드시 명시해야 합니다. "챗봇 기능 포함"이라고만 적고 정확도 기준, 응답 속도 기준, 동시 접속 수용 범위를 쓰지 않으면, 나중에 "이건 우리가 원한 수준이 아닙니다"라고 말해도 계약서에 근거가 없습니다. 개발사는 계약서에 적힌 내용을 기준으로 판단하고, 발주사는 머릿속 기대를 기준으로 판단합니다.
요구사항 문서는 화려할 필요가 없습니다. "어떤 형태의 입력 파일이 들어오면, 어떤 결과가 어떤 형태로 나와야 한다"는 것을 글과 실제 파일 예시로 설명한 것이면 충분합니다. 이 문서가 없으면 견적도 정확하게 나오지 않고, 완성 여부를 판단하는 기준도 없어집니다. 시작 전에 요구사항 문서를 만드는 데 시간을 쓰는 것이 이후 분쟁을 줄이는 데 훨씬 효과적입니다.
특히 AI 자동화에서는 "어떤 예외 케이스가 있는가"를 미리 정리하는 것이 중요합니다. 처리해야 할 파일 형식이 한 가지만 있는지, 여러 회사에서 다른 양식으로 오는 서류도 있는지, 오류가 나면 어떻게 표시해줘야 하는지. 이 예외 상황들이 문서로 정리되어 있어야 개발사도 처음부터 그 경우를 고려해서 만들 수 있습니다.
2. 코드와 계정의 소유권이 발주사에게 이전되는가
완성된 자동화 시스템은 코드로 이루어져 있습니다. 그 코드가 누구 소유인지에 따라, 납품 이후 수정이 가능한지, 다른 업체로 이전이 가능한지가 완전히 달라집니다.
코드 오너십이 업체 명의로 남아버리는 사고는 2026년 현재에도 여전히 자주 발생하는 문제입니다. 소스 코드뿐 아니라 API 키, 클라우드 서버 계정, 데이터베이스 접근 권한이 모두 업체 명의로 설정된 채로 계약이 끝나면, 그 시스템은 사실상 업체가 열쇠를 쥐고 있는 것과 같습니다. 계약이 종료되거나 업체가 갑자기 문을 닫으면 시스템을 아무도 건드릴 수 없게 됩니다.
계약서에 "소스 코드와 관련 계정의 소유권은 발주사에 귀속된다"는 조항을 명시하고, 납품 시점에 모든 코드와 접근 권한을 직접 이전받도록 요청해야 합니다. 이 소유권 이전을 꺼리는 업체가 있다면, 그 자체가 하나의 판단 기준이 됩니다. 명확하게 답하지 못하거나 "나중에 정리해드릴게요"라는 말로 넘어가는 경우는 주의가 필요합니다.
단순히 코드 파일만 받는 것으로는 충분하지 않은 경우도 있습니다. 어떤 서버에서 작동하는지, 어떤 외부 서비스에 연결되어 있는지, 환경 설정 파일은 어디에 있는지, 실행에 필요한 패키지나 라이브러리는 어떻게 구성되어 있는지도 함께 이전받아야 실제로 운영이 가능합니다. 코드 자체만 받고 실행 환경에 대한 정보가 없으면, 받은 코드를 아무도 실행할 수 없는 상황이 생깁니다.
3. 납품 기준이 미리 합의되어 있는가
"완성"의 기준이 없으면 납품 시점도 없고, 수락 여부를 두고 갈등이 생깁니다. 개발사 입장에서는 기본 기능이 돌아가면 완성이지만, 발주사 입장에서는 오류율이나 처리 속도, 예외 상황 처리 방식까지 기대하는 수준이 있습니다.
계약 전에 아래 항목을 구체적인 기준으로 합의해 두는 것이 좋습니다.
| 항목 | 합의해야 할 내용 |
|---|---|
| 오류율 | 100건 처리 시 허용 오류 건수 |
| 처리 속도 | 건당 처리 완료까지 허용 시간 |
| 예외 처리 | 처리 불가 케이스 발생 시 대응 방식 |
특히 AI 기반 자동화는 입력 데이터의 형태가 조금만 달라도 정확도가 떨어질 수 있습니다. 100% 정확도가 기술적으로 보장되지 않는 경우가 많기 때문에, 사전에 "허용 가능한 오류율"을 합의하는 것이 현실적인 기대치를 맞추는 방법입니다. 이 기준이 없으면 "잘 됩니다"와 "이건 부족합니다"가 끝없이 평행선을 달립니다.
납품 전 테스트를 어떤 데이터로 진행할지도 미리 정해두는 것이 좋습니다. 실제 업무에서 나오는 데이터 샘플을 미리 제공하면, 개발사도 현실에 맞게 테스트할 수 있고 발주사도 실제 조건에서 작동 여부를 눈으로 확인할 수 있습니다. 합성 데이터나 테스트 데이터로만 검증했던 시스템이 실제 업무에서 처음 보는 파일을 만나 멈추는 경우가 있습니다. 실제 데이터로 납품 전 테스트를 진행하는 것을 계약에 포함시켜 두세요.
4. 유지보수 조건이 계약서에 명시되어 있는가
자동화 시스템은 한 번 만들고 영원히 작동하지 않습니다. 연동된 외부 서비스가 업데이트되거나, 처리해야 하는 서류 양식이 바뀌거나, 시스템에 연결된 도구가 교체되면 자동화가 멈추거나 결과가 달라질 수 있습니다. 이런 상황이 생겼을 때 누가, 어떤 비용으로 수정해 주는지가 미리 정해져 있어야 합니다.
업계에서 통용되는 기준으로, 유지보수 비용은 보통 개발 완료 비용의 연간 10~20% 수준입니다. 무상 유지보수 기간이 끝난 뒤 발생하는 버그 수정이나 기능 변경은 이 기준으로 처리되는 경우가 많습니다. 이 내용이 계약서에 없으면, 작은 수정 하나에도 별도 협의가 필요해지고, "이건 하자인지 추가 요청인지"를 두고 갈등이 생깁니다.
계약서에 반드시 포함해야 할 유지보수 관련 조항이 있습니다. 무상 유지보수 기간이 몇 개월인지, 그 기간 이후 유상 처리의 단가 기준이 어떻게 되는지, 문제가 생겼을 때 대응 시간 기준은 어떻게 되는지, 하자보수와 추가 요청을 어떻게 구분하는지를 계약서에 명확히 적어두어야 합니다. 납품 시점 이후 외부 서비스 정책 변경으로 생기는 수정 비용은 누가 부담하는지도 미리 정해두는 것이 좋습니다.
5. AI 모델 변경 시 처리 조항이 있는가
AI 자동화 외주에서 2026년부터 새로 챙겨야 하는 항목입니다. AI 서비스는 버전 업데이트가 잦고, 요금 정책이나 무료 제공 범위가 자주 바뀝니다. 2026년 이후 AI 프로젝트에서는 "사용하는 AI 모델이 계속 바뀐다"는 전제를 계약서에 반영하는 것이 업계에서 기본이 되고 있습니다.
구체적인 상황이 있습니다. 외주 업체가 특정 AI 서비스의 무료 API를 활용해 시스템을 구축했는데, 이후 해당 API가 유료로 전환되거나 제공 방식이 변경되면 시스템 전체를 수정해야 할 수 있습니다. 또는 사용하던 AI 모델 버전이 서비스 종료되어 다른 버전으로 교체해야 하는 경우도 생깁니다. 이 수정 비용을 발주사가 부담하는지, 개발사가 부담하는지를 계약서에 정해두지 않으면, 이 상황이 생겼을 때 양쪽이 상대가 부담해야 한다고 주장하게 됩니다.
계약서에 "AI 서비스의 정책 변경으로 인한 수정 작업의 비용 부담 주체"를 조항으로 명시하는 것이 현실적인 대비책입니다. 이 조항을 포함시키자고 제안했을 때 개발사가 어떤 반응을 보이는지도 판단 기준이 됩니다. 이 주제를 모호하게 넘기거나 논의를 꺼리는 업체라면, 다른 불명확한 부분에서도 비슷한 태도를 보일 가능성이 높습니다.
6. 소규모 파일럿으로 먼저 검증할 수 있는가
처음부터 모든 범위를 한 번에 외주로 맡기는 것은 리스크가 큽니다. 개발사와 처음 일하는 경우에는 기술적 역량뿐 아니라 소통 방식, 문제 발생 시 대응 태도, 진행 과정의 투명성을 미리 확인할 방법이 없습니다. 계약이 끝나고 납품을 받은 뒤에야 "이 업체와는 맞지 않았다"는 것을 알게 되는 경우가 많습니다.
업계에서는 본 계약 전에 2~4주의 소규모 검증 프로젝트(PoC)로 실제 작동을 먼저 확인하는 방식을 권장합니다. 이 과정에서 기술이 실제 업무 환경에서 작동하는지 확인하고, 동시에 업체와의 협업 방식이 맞는지도 파악할 수 있습니다. 소규모 검증에서 문제가 발견되면 큰 비용을 쓰기 전에 방향을 바꿀 수 있습니다.
파일럿을 통해 확인해야 할 것은 기술 검증만이 아닙니다. 요청한 내용을 어떻게 이해하고 결과로 내오는지, 중간 진행 상황을 어떻게 공유하는지, 피드백에 어떻게 반응하는지를 파일럿 기간에 함께 볼 수 있습니다. 이 과정이 있어야 "이 업체와 같이 계속 일해도 되겠다"는 판단의 근거가 생깁니다. 처음부터 전체 범위를 계약하는 것을 권유하는 업체에 대해서는, 왜 작게 먼저 시작하지 않는지를 물어보는 것이 좋습니다.
2주 파일럿 방식이 실제로 어떻게 작동하고 무엇을 확인할 수 있는지는 왜 2주 파일럿으로 시작하는가에서 더 자세히 확인하실 수 있습니다.
7. 납품 후 스스로 운영할 수 있는가
외주로 만든 시스템이 납품 이후 블랙박스가 되어버리는 일이 자주 있습니다. 담당자가 바뀌거나, 개발사와 연락이 끊기는 상황이 오면, 멀쩡히 작동하는 시스템인데도 아무도 건드릴 수 없게 됩니다. 처리해야 할 서류 양식이 조금 달라지거나, 연결된 서비스가 업데이트될 때마다 개발사를 불러야 하는 구조가 됩니다.
납품 전에 반드시 확인해야 할 세 가지가 있습니다.
첫째, 시스템 사용 방법이 문서로 제공되는가. 이 문서가 있어야 새 담당자가 생겨도 이어서 쓸 수 있고, 시간이 지난 뒤에도 어떻게 작동하는지 파악할 수 있습니다. 화면 캡처와 단계별 설명으로 만들어진 문서가 가장 실용적입니다.
둘째, 기본적인 설정 변경을 직접 할 수 있도록 교육이 포함되는가. 처리해야 할 파일 형식이 조금 달라지거나, 결과물의 항목을 추가해야 하는 상황이 생겼을 때 개발사를 거치지 않고 직접 대응할 수 있어야 합니다. 납품과 함께 담당자 대상 교육이 이루어져야 이것이 가능합니다.
셋째, 시스템이 어떤 구조로 동작하는지를 비개발자도 이해할 수 있는 수준으로 설명받을 수 있는가. 어떤 파일이 어디 들어가면 어떤 처리를 거쳐 어디로 나오는지, 이상이 생겼을 때 어디를 확인해야 하는지를 알아야 합니다. 전체 구조를 이해하지 못하면 작은 변경 하나도 개발사에 의뢰해야 합니다.
"인수인계는 포함됩니다"라는 구두 약속보다, "인수인계 문서 제공 및 담당자 교육 N회 포함"이라고 계약서에 쓰여 있는 것이 나중에 분쟁이 생겼을 때 근거가 됩니다. 인수인계를 납품의 한 부분으로 처음부터 범위에 포함시키는 것이 안전합니다.
7가지 체크리스트 한눈에 보기
| 항목 | 확인 내용 |
|---|---|
| 요구사항 문서화 | 기능·제외 항목·품질 기준이 문서로 정리되어 있는가 |
| 코드·계정 소유권 | 납품 시 발주사 명의로 이전되는가 |
| 납품 기준 | 오류율·속도·예외 처리 기준이 사전에 합의되어 있는가 |
| 유지보수 조건 | 무상 기간·유상 단가·대응 시간이 계약서에 명시되어 있는가 |
| AI 모델 변경 조항 | 정책 변경 시 수정 비용 부담 주체가 정해져 있는가 |
| 파일럿 가능 여부 | 소규모 검증 이후 본 계약 여부를 결정할 수 있는가 |
| 자립 운영 | 사용 문서와 담당자 교육이 납품에 포함되어 있는가 |
자동화 외주를 결정하기 전에 판단해야 할 것
7가지 체크리스트 외에, 계약에 앞서 판단해야 할 더 기본적인 질문이 있습니다. 지금 자동화가 우선인지, 아니면 업무 정리가 먼저인지입니다.
자동화 외주를 맡기기 전에 자동화할 업무가 명확히 정의되어 있지 않으면, 개발사에게 "어떻게 만들지"를 구체적으로 요청하기 어렵습니다. 어떤 파일이 어떤 방식으로 처리되어야 하는지, 예외 상황이 얼마나 되는지, 결과물이 어떤 형태여야 하는지를 발주사가 먼저 정리해두어야 합니다. 이것이 정리되지 않은 상태에서 외주를 맡기면, 개발사도 정확하게 만들기 어렵고 발주사도 원하는 것을 정확하게 요청하기 어렵습니다.
업무 파악부터 시작해야 하는 경우에는, 자동화 외주를 맡기기 전에 현재 업무 흐름을 먼저 그려보는 것이 선행되어야 합니다. "지금 어떤 파일이 들어오고, 어떤 순서로 처리해서, 어떤 결과를 어디에 내보내는가"를 한 장으로 정리할 수 있는 수준이 되어야 정확한 요구사항 문서를 만들 수 있습니다. 처음부터 이 정리를 함께 해주는 업체인지를 확인하는 것도 하나의 기준이 됩니다.
자주 묻는 질문
Q. 체크리스트 항목을 업체에게 직접 물어봐도 되나요?
당연히 됩니다. 오히려 이 항목들을 물어봤을 때 업체가 어떻게 반응하는지를 보는 것이 업체를 판단하는 좋은 방법입니다. 명확하게 답하는 업체와 모호하게 넘기는 업체의 차이가 계약서에도 그대로 나타납니다. "코드 소유권은 어떻게 되나요", "유지보수 기간이 끝나면 어떻게 처리되나요", "납품 기준을 미리 정할 수 있나요"라는 질문에 대한 답변을 비교해보면, 어떤 업체가 투명하게 운영하는지 파악할 수 있습니다.
Q. 파일럿 없이 처음부터 큰 범위로 시작하면 안 되나요?
안 된다기보다, 리스크가 높습니다. 처음 일하는 업체와 큰 범위를 한 번에 계약하면, 납품 이후에야 방향이 잘못됐다는 것을 알게 되는 경우가 생깁니다. 작은 범위로 먼저 검증하면 "이 방향이 맞다"는 확인을 하고 나서 규모를 키울 수 있습니다. 단, 파일럿이 본 계약과 완전히 독립된 별도 과정인지, 아니면 본 계약의 일부로 묶여 있는 것인지를 처음에 확인해두는 것이 좋습니다.
Q. 계약서에 이 항목들이 없으면 어떻게 되나요?
명시되어 있지 않은 부분은 대부분 "업체 관행"이나 "구두 약속"에 의존하게 됩니다. 문제가 생겼을 때 계약서에 근거가 없으면, 발주사와 개발사 중 어느 쪽도 명확한 권리를 주장하기 어렵습니다. 분쟁이 생겨도 해결하기 어렵고, 분쟁 없이 끝나더라도 양쪽 모두 불편한 경험이 남습니다. 처음에 명확하게 해두는 것이 양쪽 모두에게 낫습니다.
마무리 — 계약서 한 장이 이후를 결정한다
자동화 외주에서 낮은 가격이 가장 중요한 기준이 되는 경우가 많습니다. 그런데 초기 가격이 낮더라도 유지보수 비용이 별도로 청구되거나, 코드 소유권이 업체에 남아 있거나, 납품 후 아무도 수정할 수 없게 되면 결국 더 많은 비용과 시간이 들게 됩니다. "납품 이후에도 안정적으로 운영되는가"를 기준으로 삼는 것이 장기적으로 더 나은 선택을 만듭니다.
외주를 결정하기 전에 자동화가 실제로 가능한지부터 확인해보는 것도 방법입니다. 가능한지 아닌지, 가능하다면 어떤 방식이 현실적인지를 먼저 파악하고 업체를 비교해도 늦지 않습니다. 실제 구축이 어떻게 진행됐는지 궁금하다면 사례 페이지에서 먼저 확인해보세요.
옥수에서는 30분 무료 진단을 통해 가능한 것과 어려운 것을 솔직하게 말씀드립니다. 영업 전화 없이, 판단은 보내시는 분이 합니다. 진단에서 "안 됩니다"가 나오는 경우에도 왜 안 되는지, 어떻게 하면 가능해지는지를 함께 정리해드립니다.