AI 개발 업체를 선정할 때 확인해야 할 10가지

제안서를 서너 장 받아 놓고 나면 대부분 같은 자리에서 막힙니다. 기술 내용은 검증할 방법이 없고, 결국 눈에 보이는 것은 금액과 포트폴리오뿐입니다. 그런데 프로젝트가 어그러지는 지점은 거기가 아닙니다. 아래 열 가지는 실력을 평가하는 항목이 아니라, 계약 전에 서면으로 답을 받아 둘 수 있는 항목입니다. 그래서 기술을 아는 사람이 아니어도 판단하실 수 있습니다. 답이 맞는지 틀렸는지를 가리는 것이 아니라, 문서에 있는지 없는지만 보면 되기 때문입니다. 각 항목마다 무엇을 묻고, 좋은 답변은 어떤 모습이며, 어떤 대답이 위험 신호인지 함께 정리했습니다.

견적과 포트폴리오만으로는 비교가 되지 않습니다

같은 요구사항을 주어도 제안서마다 금액이 크게 갈리는 이유는 실력 차이가 아니라 범위를 서로 다르게 잡았기 때문인 경우가 많습니다. 어떤 제안은 화면 개발만 계산하고, 어떤 제안은 외부 시스템 연동과 출시 후 운영까지 포함합니다. 범위가 다른 두 금액을 나란히 놓는 것은 비교가 아닙니다.

포트폴리오도 마찬가지입니다. 완성된 화면은 그 프로젝트가 일정 안에 끝났는지, 요구사항이 중간에 바뀌었을 때 어떻게 처리됐는지, 출시 후 누가 운영하고 있는지를 말해 주지 않습니다. 발주처가 실제로 부담하게 될 위험은 전부 그 뒤에 있습니다.

기준 1~3 — 범위: 무엇을 직접 하고 무엇을 넘기는가

범위 항목은 “무엇을 하는가”가 아니라 “무엇을 하지 않는가”를 문서로 받을 수 있는지로 갈립니다. 직접 수행하는 일, 외부와 함께하는 일, 아예 포함되지 않는 일이 세 칸으로 나뉘어 있으면 계약 후에 생길 다툼의 상당 부분이 미리 정리됩니다.

기준 1. 직접 수행하는 범위를 문서로 구분하는가

• 무엇을 묻는가 — “이번 범위 중 귀사가 직접 수행하는 항목과, 외부와 함께 수행하는 항목을 나눠서 표시해 주실 수 있습니까?”
• 좋은 답변 — 두 목록이 분리된 문서가 나옵니다. 경계가 애매한 항목은 애매하다고 적혀 있습니다.
• 위험 신호 — “저희가 다 합니다”로 끝나거나, 구분을 요청했는데 구두 설명으로 대체하는 경우입니다. 계약 후에 “그건 저희 영역이 아닙니다”가 나오는 지점이 대개 여기입니다.

기준 2. 외부와 함께 수행하는 부분의 책임은 누가 지는가

범위를 나눠 밝히는 것만으로는 충분하지 않습니다. 그 부분에서 문제가 생겼을 때 발주처가 누구와 이야기하는지가 계약서에 있어야 합니다.

• 무엇을 묻는가 — “외부 협력이 들어가는 항목에서 일정이 밀리거나 품질 문제가 생기면, 계약상 책임 주체는 누구입니까?”
• 좋은 답변 — 원청이 단일 창구로 책임진다는 조항을 보여 주거나, 별도 계약이 필요하다면 그 사실을 먼저 말합니다.
• 위험 신호 — 협력사 이름조차 계약 전에 밝히지 못하는 경우입니다.

이 기준은 저희에게도 그대로 적용됩니다. 빌드업웍스가 직접 수행하는 것은 웹·앱 개발과 AI 기능의 제품 통합, 그리고 AWS 기반 환경 구축입니다.

반면 AI/ML 모델 개발과 학습, 데이터 사이언스 컨설팅, 커스텀 알고리즘 개발은 직접 하지 않고 전문 파트너를 연결합니다. 이 구분은 AI · 앱 개발 지면에 두 칸으로 나누어 적어 두었습니다.

검토하시는 곳마다 같은 형식의 문서를 요청해 보시면 비교가 훨씬 쉬워집니다.

기준 3. 계약 범위 밖 항목을 먼저 말하는가

• 무엇을 묻는가 — “이번 계약에 포함되지 않는 항목을 목록으로 받을 수 있습니까?”
• 좋은 답변 — 제외 항목이 처음부터 제안서에 있습니다. 좋은 제안서는 포함 목록보다 제외 목록이 더 구체적인 경우가 많습니다.
• 위험 신호 — 제외 항목이 한 줄도 없는 제안서입니다. 범위를 한정하지 않은 제안은 싸 보이지만, 한정되지 않은 것은 나중에 전부 추가 비용으로 돌아옵니다.

기준 4~5 — 소유권: 코드와 데이터는 누구 것인가

소유권 항목이 판정하는 것은 계약이 끝나거나 업체를 바꿀 때 무엇이 발주처에 남는가입니다. 프로젝트가 순조로울 때는 한 번도 문제가 되지 않다가, 관계가 정리되는 시점에만 드러나는 항목이라 계약 전에 확인하지 않으면 확인할 기회가 다시 오지 않습니다.

기준 4. 코드와 산출물의 소유권이 계약서에 있는가

• 무엇을 묻는가 — “완성된 소스 코드, 설계 문서, 배포 설정(만든 프로그램을 실제 서버에 올리고 동작시키는 데 필요한 설정)의 소유권은 누구에게 있습니까? 계약 종료 시 무엇을 어떤 형식으로 인계받습니까?”
• 좋은 답변 — 소유권 주체, 인계 대상 목록, 인계 형식이 조항으로 적혀 있습니다.
• 위험 신호 — “당연히 고객님 것입니다”라는 구두 답변만 있고 계약서에는 언급이 없는 경우입니다. 명시되지 않은 권리는 이관 시점에 힘이 없습니다.

기준 5. 데이터는 어디에 저장되고 누가 접근하는가

• 무엇을 묻는가 — “운영 데이터가 국내에 저장됩니까, 해외에 저장됩니까? 어느 계정에 저장되며 접근 권한을 가진 사람은 누구입니까? 계약 종료 후 그 권한은 어떻게 회수됩니까?”
• 좋은 답변 — 저장 위치가 발주처 명의 계정인지 수행사 계정인지 명확히 답하고, 권한 회수 절차를 함께 설명합니다.
• 위험 신호 — 저장 위치를 즉답하지 못하거나, 개인정보가 포함된 데이터인데 처리 위탁(우리 회사의 개인정보를 다른 회사가 대신 다루도록 맡기는 관계) 관계에 대한 서면이 준비돼 있지 않은 경우입니다.

기준 6 — AI 출력: 근거를 확인할 수 있는가

AI 기능이 얹히면 확인할 것이 둘 늘어납니다. 모델이 낸 답의 근거를 사람이 되짚어 확인할 수 있는지, 그리고 넣은 데이터가 외부 모델의 학습에 쓰이는지입니다. 결과가 그럴듯해 보인다는 것과 결과가 맞다는 것은 다른 문제이기 때문입니다.

기준 6. 답의 근거와 데이터 활용 범위가 문서에 있는가

• 무엇을 묻는가 — 첫째, “모델이 낸 답의 근거를 사람이 되짚어 확인할 수 있는 구조입니까?” 둘째, “저희가 넣는 데이터가 외부 모델의 학습에 사용됩니까?”
• 좋은 답변 — 답변에 원문 출처나 참조 근거가 함께 남는 구조를 설명하고, 검수와 예외 처리를 누가 맡는지 정합니다. 학습 활용 여부는 사용하는 모델 제공사의 공식 정책 문서를 제시합니다.
• 위험 신호 — 정확도를 숫자로 약속하거나, 학습에 쓰이지 않는다고 구두로만 단언하는 경우입니다. 이 답은 개발을 맡은 곳이 대신 보증할 수 있는 성격이 아니므로, 정책 문서 자체를 요청하시는 편이 확실합니다.

기준 7~8 — 출시 이후: 운영 주체와 변경 처리

이 두 항목은 완성된 뒤에 무슨 일이 벌어지는가를 판정합니다. 제안서는 대부분 출시일까지만 이야기하지만, 발주처가 실제로 오래 부담하는 비용은 출시 이후에 발생합니다.

기준 7. 만든 팀과 운영하는 팀이 같은가

• 무엇을 묻는가 — “출시 후 장애가 발생하면 누가 대응합니까? 구축 담당자와 같은 사람입니까?”
• 좋은 답변 — 운영 주체와 대응 절차, 지원이 가능한 시간대와 범위를 계약 문서로 제시합니다.
• 위험 신호 — 운영 이야기가 계약서에 전혀 없는 경우입니다. 만든 팀이 떠나고 인수인계 공백만 남으면, 그 비용은 대개 다음 업체를 찾는 비용으로 다시 나타납니다.

운영 주체를 물으실 때 “24시간 관제”라는 표현도 함께 확인하셔야 합니다. 이 말은 서로 다른 두 가지를 가리킬 수 있습니다. 자동 감시와 알림이 24시간 동작하는 것과, 사람이 24시간 대기해 실제로 분석하고 대응하는 것은 다릅니다. 감시와 대응을 나눠서 물어보시면 같은 문구를 쓰는 제안들 사이의 실제 차이가 드러납니다.

이 기준도 저희에게 그대로 적용됩니다. 빌드업웍스는 만든 팀이 운영까지 이어받지만, 지원 시간과 범위에는 정해진 경계가 있고 야간·주말 대응은 기본 범위에 들어 있지 않습니다. 어느 곳을 검토하시든 “몇 시부터 몇 시까지, 무엇을”을 문서로 받아 두시는 편이 좋습니다.

기준 8. 요구사항 변경을 어떤 절차로 처리하는가

• 무엇을 묻는가 — “진행 중에 요구사항이 바뀌면 어떤 절차로 처리됩니까? 일정과 금액에는 어떻게 반영됩니까?”
• 좋은 답변 — 변경 요청서 양식, 검토 주체, 승인 후 반영 방식이 정해져 있습니다.
• 위험 신호 — “웬만한 건 그냥 해 드립니다”라는 답입니다. 기준이 없다는 뜻이고, 기준이 없으면 대개 갈등으로 이어집니다.

기준 9~10 — 책임 소재와 한계 고지

마지막 두 항목은 문제가 생겼을 때 판단할 사람이 정해져 있는지, 그리고 상대가 자기 한계를 먼저 말하는지를 봅니다. 앞의 여덟 항목이 계약 문서의 내용을 보는 것이라면, 이 둘은 계약 상대가 어떻게 답하는지 그 태도를 보는 항목에 가깝습니다.

기준 9. 담당이 여러 회사로 나뉠 때 책임 소재가 정해져 있는가

인프라, 보안, 개발을 각각 다른 곳에 맡기는 구조 자체가 문제는 아닙니다. 문제는 경계에서 생긴 사고를 판단할 주체가 비어 있을 때 발생합니다.

• 무엇을 묻는가 — “장애 원인이 애플리케이션인지 인프라인지 불분명할 때, 원인을 판단하는 역할은 누구에게 있습니까?”
• 좋은 답변 — 판단 주체가 지정돼 있거나, 지정돼 있지 않다면 그 사실을 먼저 알려 줍니다.
• 위험 신호 — “저희 쪽 문제는 아닐 겁니다”라는 형태의 답입니다. 계약을 나눠 맺으실 계획이라면 조율 역할이 어느 계약에 포함되는지를 발주 전에 정해 두시는 것이 좋습니다.

기준 10. 못 하는 것을 먼저 말하는가

• 무엇을 묻는가 — “이번 프로젝트에서 귀사가 자신 없는 부분이나, 다른 곳이 더 잘할 만한 부분이 있습니까?”
• 좋은 답변 — 구체적인 항목이 하나 이상 나옵니다. 그리고 그 부분을 어떻게 보완할지 함께 말합니다.
• 위험 신호 — 전부 가능하다는 답, 그리고 결과를 보장하겠다는 약속입니다.

결과를 보장하겠다는 약속이 특히 중요합니다. 운영이나 개선 활동을 정해진 범위에서 수행하겠다는 약속과, 특정 성과를 보장하겠다는 약속은 성격이 완전히 다릅니다. 앞의 것은 지킬 수 있고 문서로 검증되지만, 뒤의 것은 지켜지지 않았을 때 확인할 방법이 없습니다. 약속 문구를 예로 들면, “월 1회 점검과 리포트 제공”은 지켜졌는지 확인할 수 있지만 “문의 30% 감소”는 안 지켜져도 확인할 방법이 없습니다. 저희가 약속하는 것과 약속하지 않는 것을 나누어 적어 둔 것도 같은 이유입니다.

계약 전 서면으로 받아 둘 것

계약 전 서면으로 받아 둘 항목은 일곱 가지이며, 기술 지식 없이도 있는지 없는지만으로 판단할 수 있습니다. 검토하시는 곳 전체에 같은 목록을 보내고, 회신 형태를 비교해 보시는 것만으로도 상당한 정보가 모입니다.

자주 발생하는 실수

금액부터 비교하는 것이 가장 흔합니다. 범위를 같은 선에 맞추기 전의 금액 비교는 순서가 뒤바뀐 것입니다. 범위에 따라 금액이 어떻게 달라지는지는 요금 지면의 신규 구축 트랙에서 확인하실 수 있습니다.

구두 약속을 기록하지 않는 것도 자주 일어납니다. 미팅에서 들은 답변은 회의록에 남기고, 중요한 항목은 계약서나 별첨으로 옮겨 두셔야 합니다.

만들 것을 정하지 않은 채 견적을 요청하는 것은 앞의 두 가지를 동시에 일으킵니다. 요구사항이 흐릴수록 제안 범위는 각자 다르게 좁혀지고, 그 차이가 그대로 금액 차이로 보입니다.

이 글이 필요 없는 경우

발주 자체를 다시 볼 때도 있습니다. 필요한 기능이 기성 SaaS로 대부분 덮이거나 사내 인력으로 가능한 범위라면, 외부에 맡기는 것 자체가 답이 아닐 수 있습니다. 이 판단이 견적 비교보다 먼저입니다. 업체 선정 기준은 맡기기로 결정한 다음에 필요한 것입니다.

빌드업웍스는 어떻게 지원하는가

저희도 발주하시는 분들께는 검토 대상 중 하나입니다. 그래서 이 열 가지를 저희에게도 그대로 물어보시기를 권합니다. 직접 하는 일과 파트너와 함께하는 일은 AI · 앱 개발 지면에 나누어 적어 두었고, 약속의 범위와 그 한계는 약속 지면에 있습니다.

무엇을 만들지부터 정리가 필요하시다면 1분 업무 시스템 진단으로 시작하실 수 있습니다. 저희도 검토 대상 중 하나이므로 경쟁 제안에 대한 판단은 참고로만 받으시고, 저희 제안에 이 열 가지를 대입해 보시는 용도로 상담 신청으로 연락 주십시오.

참고 자료

• 개인정보보호위원회 — 개인정보 처리 위탁 관련 안내
• AWS Well-Architected Framework — 운영 우수성 관점