LLM 개발 외주의 검수 기준: LLM 기반 소프트웨어 발주 가이드
입력이 같아도 답이 다른 생성형 AI, 어떻게 검수해야 할까요? 잦은 분쟁을 막기 위한 골든 데이터셋과 평가 합의 기준부터 현실적인 3구간 견적과 운영비까지, 발주자가 꼭 알아야 할 LLM 외주 가이드를 핵심만 담았습니다.
Sep 18, 2026
외주개발에서 검수는 보통 마지막 관문입니다. 요구사항 문서를 펼쳐 놓고 기능이 하나씩 동작하는지 확인하고 나름의 내부 기준을 통과하면 기업은 계약서에 따라 잔금을 치릅니다. 그러나 LLM 개발 프로젝트에서는 이 과정 자체가 성립하지 않습니다. LLM 개발 환경에서는 같은 질문을 두 번 던지면 다른 답을 내놓고 백 번 잘 답하던 챗봇이 백한 번째에 잘못된 답변을 지어낼 수 있습니다. 이런 환경에서 기업은 완벽히 동작하는 게 맞는지, 확인할 방법이 없는 소프트웨어를 발주하고 검수해야 합니다.
2026년 현재 LLM 기반의 외주 개발 프로젝트가 급증하면서 이 문제는 잔금 분쟁의 형태로 현실에 나타납니다. 본 아티클은 이 검수 문제가 왜 보통의 발주자에게까지 확산됐는지, 검수 분쟁이 어떤 구조로 생기는지, 계약 전에 무엇을 숫자로 합의해야 하는지, 견적과 운영비는 어떻게 읽어야 하는지를 발주자 관점에서 정리합니다. 개발사 평가의 일반 기준은 「SI개발과 외주개발의 기준」에서 다뤘고, 이 글은 그중 LLM 프로젝트에서만 나타나는 문제에 집중합니다.
LLM 기능은 이미 보통의 외주 개발 내에 들어와 있습니다
이 문제를 LLM 전문 프로젝트만의 일로 독해한다면 사안의 명확한 범위를 놓칠 수밖에 없습니다. 2026년의 외주개발 견적서에는 상담 챗봇, 문서 요약, 사내 검색 같은 LLM 기능이 기본 항목처럼 들어옵니다. 교육기업 캐럿글로벌이 약 300개 기업을 조사한 결과 국내 기업의 생성형 AI 도입률은 61.1%에 이르렀습니다. 도입의 상당수는 신규 시스템 구축이 아니라 기존 서비스에 기능 하나를 얹는 방식입니다. 쇼핑몰 앱에 상담 챗봇 버튼, 그룹웨어에 회의록 요약 버튼 하나가 들어가는 식입니다.
발주하는 기업 입장에서는 여전히 앱 개발을 발주했다고 생각하지만 그 순간부터 프로젝트의 검수는 LLM 검수가 됩니다. 기능 아흔아홉 개가 정해진 대로 동작해도 챗봇 하나가 확률적으로 동작하면 오픈 직전의 문제 제기는 그 하나에서 시작되기 때문입니다. LLM 개발 외주의 검수 문제는 전문 AI 프로젝트를 발주하는 소수의 문제였다가 기능 단위로 확산되면서 보통 발주하는 기업의 문제가 됐습니다.
산출물의 구조가 달라진다는 점도 함께 봐야 합니다. LLM 기능이 들어간 결과물은 코드 한 덩어리로 끝나지 않고 세 층위로 구성됩니다. 시스템을 움직이는 코드, 모델에게 일을 시키는 프롬프트, 문서를 검색 가능하게 가공하는 데이터 처리 층입니다. 이상한 답변이 나왔을 때 원인이 어느 층에 있는지는 열어 보기 전까지 알 수 없고 기업이 스스로 열어 볼 방법은 사실상 없습니다. 오류의 재현 경로를 제시하며 수정을 요구하던 기존 검수 방식이 통하지 않는 구조입니다.
그런데 계약서의 언어는 아직 기능 목록의 시대에 머물러 있습니다. 요구사항 정의서에 "AI 챗봇 기능"이라고 적고 구현 여부만 확인하는 관행이 그대로입니다. 확률적으로 동작하는 부분이 하나라도 있으면 그 부분의 품질 기준을 숫자로 적어야 하는데 이 전환이 시장 전반에서 아직 일어나지 않았습니다.
발주 실무로 옮기면 이렇게 됩니다. RFP나 요구사항 정의서를 쓸 때 기능 목록에서 LLM이 개입하는 항목을 따로 표시해야 합니다. 챗봇, 요약, 검색, 분류처럼 답이 매번 달라질 수 있는 기능이 대상입니다. 표시된 항목에는 구현 여부 대신 품질 기준을 적을 자리를 만들어 두고 그 자리를 어떻게 채울지는 뒤에서 다룰 검수 기준 세 가지로 정하면 됩니다. 전체 프로젝트의 검수 방식을 바꾸는 일은 아닙니다. 확률적으로 동작하는 항목에만 다른 잣대를 붙이는 것뿐입니다. 다음 장에서 보듯 검수 분쟁은 이 잣대의 부재에서 생깁니다.
검수 분쟁은 어떤 구조로 생깁니까: 평가 부재가 실패의 첫째 원인입니다
분쟁은 대체로 비슷한 각본대로 흘러갑니다. 계약서에는 "LLM 기반 챗봇 구축"이라고 적혀 있고 품질 기준은 없습니다. 개발은 순조롭게 끝나고 MVP, 데모까지도 문제 없었습니다. 그러나 오픈을 앞두고 현업 직원들이 테스트를 시작하면서 상황이 바뀝니다. 누군가 이상한 답변을 캡처해 공유합니다. 비슷한 사례가 이어지고 "이 상태로 오픈은 못 한다"는 의견이 힘을 얻습니다. 발주사는 하자 보수를 요구합니다. 개발사는 계약 범위의 기능이 모두 구현됐다고 답합니다. 양쪽 모두 자기 기준으로는 맞는 말을 합니다. 발주사는 품질을 기준으로, 개발사는 기능 목록을 기준으로 말하고 있을 뿐 판정할 공동의 기준이 계약에 없었습니다. 잔금은 묶이고 프로젝트는 누구의 잘못도 확정되지 않은 채 표류합니다.
이 시점에 하자 보수 조항이 있지 않느냐는 질문이 나오지만 조항이 있어도 잘 작동하지 않습니다. 하자 보수는 하자의 정의가 성립할 때 힘을 갖습니다. 로그인이 안 되는 것은 하자입니다. 그러나 챗봇이 가끔 이상한 답을 하는 것은 하자일까요, 확률적 소프트웨어의 정상 범위에 있다고 할 수 있을까요. 기준 없이 이 질문에 답할 방법이 없기 때문에, 보수 요구와 범위 산정이 모두 협상의 영역으로 밀려납니다. 오픈은 미뤄지고 재작업의 범위는 정해지지 않은 채 양쪽의 신뢰만 소모됩니다.
해외 실무 담론은 최근 이 각본을 표준 사례로 다룹니다. 2026년 LLM 평가 실무 가이드들은 생성형 AI 앱의 프로덕션 실패 최대 단일 원인으로 평가 체계의 부재를 공통으로 지목합니다. 모델 성능도 데이터 부족도 아닙니다. 평가 장치 없이 출시한 팀은 모델을 바꿨을 때 나아졌는지 나빠졌는지 비교할 수 없습니다. 업데이트가 품질을 후퇴시켜도 감지하지 못하고 경영진에게 답변 품질을 방어할 근거도 없습니다. 병목은 판정 체계 쪽에 있었습니다.
국내 외주 개발 시장에서는 이 문제가 한층 커집니다. LLM 기능의 견적 폭이 유난히 넓다는 점부터 그렇습니다. 프리랜서 마켓에서는 프롬프트 설계에 API 연동을 얹은 기본형 챗봇이 20만 원대에 올라와 있고 상용 수준의 구축은 수천만 원에서 억 단위로 넘어갑니다. 같은 "챗봇 구축"이라는 이름 아래 품질 기준이 전혀 다른 물건들이 거래되는데 정작 그 품질을 계약서에 적는 언어는 시장에 자리 잡지 못했습니다. 발주하는 기업 입장에서는 저렴한 견적과 지나친 견적의 차이를 물으면 기술 스택 이야기가 돌아옵니다. 오류율 기준 이야기가 돌아오는 경우는 드뭅니다.
성실하게 만드는 개발사도 기준이 없으면 손해를 봅니다. 품질 기준이 없는 계약은 "어디까지 하면 끝인지"가 없는 계약이기 때문입니다. 오픈 직전에 무한정 이어지는 수정 요청을 막을 근거가 없고 평가 체계를 포함한 정직한 견적은 그 항목을 뺀 싼 견적에 밀립니다. 검수 기준을 합의하면 발주자를 보호하는 동시에 좋은 개발사를 나쁜 경쟁에서 건져낼 수 있습니다.
이 문제는 발주 규모와 무관하게 발생합니다. 수백만 원짜리 소형 프로젝트든 억 단위 구축이든 확률적 출력을 확률의 언어로 검수하지 않으면 같은 분쟁 구조에 도달합니다. 오히려 소형 프로젝트가 더 취약한 면도 있습니다. 20만 원대 견적에 평가 체계가 포함되어 있을 리 없고 발주자도 그 금액에 검수 기준을 요구할 생각을 하지 않기 때문입니다. 작게 시작한 챗봇이 사내에서 쓸 만하다는 평을 얻어 고객 대면 채널로 승격되는 순간, 기준 없이 만들어진 물건이 기준이 필요한 자리에 서게 됩니다. 승격을 결정하기 전에 검수 기준부터 세우는 것이 순서입니다.
다행히 해외 실무는 이 해법을 이미 표준화했습니다. 거기서 쓰는 평가 방법은 절차의 문제이고 발주자가 요구하면 계약서에 담을 수 있는 수준까지 정리해 두었습니다. 다음 장에서 그 절차를 발주자의 언어로 옮깁니다.
계약 전에 합의할 LLM 검수 기준 세 가지
검수 기준은 세 가지 합의로 구성됩니다. 무엇으로 시험할지, 무엇을 잴지, 어떻게 판정할지입니다.
첫째, 시험 문제지를 함께 만듭니다. 실무에서는 골든 데이터셋이라고 부릅니다. 실제 업무에서 나올 법한 질문과 그에 대한 모범 답안을 100건에서 500건 사이로 모은 목록입니다. 해외 가이드의 권고는 구체적입니다. 시작은 100건이면 충분하고 500건을 넘기면 들이는 품 대비 얻는 것이 급격히 줄어듭니다. 이 문제지를 누가 만드느냐가 중요합니다. 질문은 발주사의 현업에서 나와야 합니다. 우리 고객이 실제로 묻는 것, 우리 직원이 실제로 검색하는 것이 문제지에 담겨야 시험이 실전을 대표합니다. 발주 전에 현업 담당자들에게 실제 질문 100개를 모아 달라고 요청하십시오. LLM 프로젝트 준비물 중 가장 값싸고 가장 중요한 항목입니다.
둘째, 평가할 항목을 서너 개로 정합니다. 권고는 과제 특화 지표 3개에서 5개입니다. 문서 기반 질의응답이라면 답이 근거 문서에 충실한지, 질문과 관련 있는 답인지, 필요한 문서를 제대로 찾아왔는지를 잽니다. 분류나 정보 추출이라면 정확 일치율 같은 고전적 지표가 통하고 요약이라면 원문에 없는 내용을 지어내지 않았는지를 봅니다. 항목의 이름을 발주자가 외울 필요는 없습니다. 두 가지만 기억하면 됩니다. 지표는 우리 업무에 맞게 골라야 합니다. 그리고 "정확도 몇 % 이상, 환각률 몇 % 이하"처럼 합격선이 숫자로 계약서에 적혀야 합니다. 합격선을 어디에 둘지는 업무의 성격이 정합니다. 사내 문서 검색이라면 다소 여유 있는 기준으로 시작해 운영하며 조일 수 있습니다. 환불 규정이나 계약 조건을 안내하는 시스템이라면 훨씬 엄격한 기준이 필요합니다. "답을 모르면 모른다고 말하고 상담사로 넘긴다"는 동작 규칙까지 합격 조건에 넣어야 합니다. 숫자를 어디에 둘지 막막하다면 그것 자체가 개발사에 던질 좋은 질문입니다. 비슷한 프로젝트에서 어떤 합격선을 썼는지 물어보면 경험 있는 개발사와 그렇지 않은 개발사의 답이 갈립니다.
셋째, 판정 절차를 정합니다. 500건의 답안을 사람이 전부 채점하는 것은 비용이 크므로 실무에서는 더 강한 모델에게 채점을 시키고 사람이 그중 10%를 표본 검수하는 방식이 정착돼 있습니다. 채점 모델과 사람 판단의 상관은 0.6에서 0.85 수준으로 보고됩니다. 표본 검수를 생략할 만큼 완벽하지는 않지만 전수 채점의 현실적 대안으로는 충분합니다. 판정은 오픈 전 한 번으로 끝나지 않습니다. 모델이 업데이트되거나 문서가 추가될 때마다 같은 문제지로 재시험을 치러 점수가 5% 넘게 떨어지면 배포를 멈추는 것이 해외 실무의 표준 규칙입니다. 오픈 이후에도 매주 실제 사용 기록 스무 건 정도를 뽑아 사람이 확인하는 절차가 권장됩니다. 「중견기업 AX전환 로드맵」에서 성과 기준을 실측하라고 했던 원칙의 LLM 버전인 셈입니다.
비용 걱정은 크지 않습니다. 채점은 한 번 절차를 만들어 두면 스크립트로 자동 실행되므로 재시험을 매번 사람 손으로 치르는 구조와는 비용 규모가 다릅니다. 문서 형태도 간단합니다. 골든 데이터셋의 관리 주체, 지표와 합격선, 재검증 규칙을 한 장으로 정리해 요구사항 정의서에 별첨하면 그것이 곧 검수 조항이 됩니다.
이 세 가지 합의가 계약서에 들어가면 검수 과정이 확연히 달라집니다. "이상한 답이 나왔다"는 캡처 공방 대신 합의된 문제지에서 합의된 지표가 합격선을 넘었는지를 확인하면 됩니다. 그리고 이 기준은 개발사 선별 도구로도 작동합니다. 견적 요청 단계에서 골든 데이터셋과 평가 절차 이야기를 먼저 꺼내는 개발사가 있고 그런 것 없이도 잘 만들 수 있다는 개발사가 있습니다. 어느 쪽이 확률적 소프트웨어를 다뤄 본 쪽인지는 답이 나와 있습니다.
RAG의 실패 지점과 견적·운영비 구조 읽는 법
검수 기준 다음으로 발주자가 알아 둘 것은 돈의 구조입니다. 그 전에 기술 이야기 하나만 짚겠습니다. 기업 LLM 프로젝트의 다수는 RAG 방식으로 만들어집니다. 회사 문서를 검색해 관련 내용을 찾아온 뒤 그것을 근거로 답을 만드는 구조입니다. 모델이 아는 척하는 대신 우리 문서를 인용하게 만들어 환각을 누르는 방식인데 여기에는 발주자가 알아 둘 함정이 있습니다. RAG의 실패는 대부분 생성이 아니라 검색에서 시작됩니다. 답을 만드는 단계가 아무리 좋아도 엉뚱한 문서를 찾아오면 결과는 틀립니다. 검색 품질을 끌어올리는 장치 없이 기본 구성으로만 만들면 검색 실패가 40% 늘어난다는 비교 결과도 있습니다. 그래서 견적 검토 때 "검색이 실패하면 어떻게 처리하는지, 검색 품질은 무엇으로 측정하는지"를 물어야 합니다. 문서를 통째로 학습시키는 파인튜닝과의 선택 문제, 사내 구축과 보안 문제는 「폐쇄형 LLM과 사내 LLM 구축 가이드」에서 다뤘습니다.
견적 구간은 2026년 기준으로 대략 세 층입니다. 검증용 MVP가 3,000만 원에서 7,000만 원에 4주에서 8주, 실사용 수준이 7,000만 원에서 1억 5,000만 원에 8주에서 16주, 전사 구축이 1억 5,000만 원 이상에 16주 이상입니다. 그 아래에 프리랜서 마켓의 20만 원대에서 200만 원대 소형 구간이 따로 있습니다. 소형 구간이 나쁜 선택이라는 뜻은 아닙니다. 아이디어가 성립하는지 내부에서 만져 보는 용도로는 합리적인 층입니다. 그 물건을 검증 없이 고객 앞에 세우는 일이 위험합니다. 실제 사고는 대부분 이 승격 과정에서 납니다. 어느 층이든 쓰는 모델은 비슷합니다. 층과 층의 가격 차이는 연동할 시스템의 수, 데이터 정비의 깊이, 그리고 위에서 말한 평가·운영 체계가 포함되어 있는지에서 나옵니다. 견적서에서 "평가 체계 구축" 항목을 찾아보십시오. 만약 별도의 체계까 없다면 그 견적은 검수할 수 없는 제품의 가격일 수 있습니다.
운영비는 LLM 프로젝트에서 특히 가볍지 않은 사안입니다. 실무 분석 기준으로 전체 비용에서 개발비가 60에서 70%, 운영 단계 비용이 30에서 40%를 차지합니다. 이 운영비가 첫 12개월 안에 개발비를 역전하는 경우가 적지 않다고 보고됩니다. 토큰 단위로 과금되는 모델 API 비용과 벡터 데이터베이스 비용이 사용량을 따라 매달 나가고 모델 제공사가 구형 모델을 종료하면 원치 않아도 교체 작업이 발생하기 때문입니다. 교체에는 재검증이 따라붙습니다. 새 모델에서 같은 품질이 나오는지 골든 데이터셋으로 재시험을 치러야 하므로 평가 체계가 없으면 업데이트 때마다 품질이 복불복이 됩니다. 그래서 앞 장에서 만든 검수 기준은 오픈 이후에도 운영 도구로 계속 쓰입니다. 검수와 운영이 같은 도구를 쓰니 초기 합의의 값어치는 그만큼 큽니다.
그래서 계약서에는 기능 목록 외에 다섯 가지가 들어가야 합니다. 모델 업데이트의 책임과 비용을 누가 지는지, 월 API·데이터베이스 비용의 상한을 어떻게 관리하는지, 응답 지연과 정확도 같은 서비스 수준을 수치로 정의하고 미달 시 어떻게 하는지, 학습 데이터와 프롬프트와 모델 산출물의 소유권이 각각 누구에게 귀속되는지, 재학습이 필요해질 때 비용을 어떻게 나누는지입니다. 다섯 항목 모두 프로젝트가 끝난 뒤에 문제가 되는 것들이라 계약 전에 묻지 않으면 물을 기회가 오지 않습니다. 특히 프롬프트와 골든 데이터셋의 귀속은 개발사 교체 상황에서 결정적입니다. 이 두 가지를 넘겨받지 못하면 다음 개발사와 처음부터 다시 시작해야 하기 때문입니다.
평가를 함께 설계하는 개발사가 LLM 외주의 기준이 되어야 합니다
결국 LLM 개발 외주가 일반 외주개발과 갈라지는 지점은 검수의 성립 조건입니다. 확률적으로 동작하는 소프트웨어는 "동작하는가"로 판정할 수 없으므로 무엇으로 시험하고 무엇을 재고 어떻게 판정할지를 계약 전에 숫자로 합의해야 합니다. 골든 데이터셋 100건, 과제 지표 서너 개, 합격선과 재검증 규칙. 준비물은 이것이 전부이고 가장 중요한 재료인 실제 질문 목록은 발주사만 만들 수 있습니다.
개발사를 고르는 기준도 여기서 나옵니다. 데모의 화려함이나 모델 이름보다 평가 이야기를 먼저 꺼내는지를 보십시오. 검수 기준을 함께 설계하자고 제안하는 개발사는 자기 결과물이 측정당하는 것을 두려워하지 않는 개발사입니다.
자주 묻는 질문
Q. LLM 개발 외주 검수는 무엇으로 합격을 판정합니까?
스파르타빌더스 계약 전에 합의한 골든 데이터셋(실제 질문·모범 답안 100~500건)으로 시험을 치르고 과제 특화 지표 3~5개가 합의된 합격선(정확도 몇 % 이상, 환각률 몇 % 이하)을 넘는지로 판정합니다. 기능 구현 여부 체크리스트만으로는 판정이 성립하지 않습니다.
Q. 골든 데이터셋은 누가 만들어야 합니까?
스파르타빌더스 질문은 발주사 현업에서 나와야 합니다. 실제 고객 문의와 직원 질문 100건을 모으는 것이 시작이며 모범 답안 정리와 평가 절차 설계는 개발사와 함께 진행합니다.
Q. RAG 방식이면 환각(할루시네이션) 걱정은 없습니까?
스파르타빌더스 줄어들지만 사라지지 않습니다. RAG의 실패는 대부분 검색 단계에서 시작되므로 검색 실패 시 처리 방식과 검색 품질 측정 방법을 견적 단계에서 확인해야 합니다.
Q. 운영비는 왜 미리 따져야 합니까?
스파르타빌더스 LLM 프로젝트는 운영비가 전체 비용의 30~40%를 차지하고 첫 12개월 안에 개발비를 역전하는 경우도 보고됩니다. 모델 API·벡터 DB 비용 상한, 모델 업데이트 책임, 재학습 비용 분담을 계약서에 명시해 두어야 합니다.
Share article