문서를 올리면 요약하고 질문에 답하는 서비스를 만들었는데, 모델 제공사가 비슷한 기능을 내놓았습니다.
우리 고객도 그 모델을 직접 쓸 수 있다면 서비스에 계속 돈을 낼 이유는 무엇일까요?
모델을 더 좋은 것으로 바꾸는 일과 제품의 경쟁력을 만드는 일은 같은 질문이 아닙니다.
이번 편에서는
모델을 바꿔도 고객에게 남는 업무 가치
를 점검합니다.
공통 예제는 앞선 글의 가상 문서 서비스이며, 아래 실험 결과도 설명용 가정입니다.
특정 모델의 실제 성능을 측정하거나 특정 제품의 우월함을 주장하는 글은 아닙니다.
기술 자료 확인일은 2026년 10월 16일입니다.
고객의 목적을 “좋은 요약을 받는다”로만 적으면 차별성을 비교하기 어렵습니다.
예제 고객은 팀의 최신 업무 규정을 찾아 답을 받고, 근거를 확인한 뒤 동료에게 전달하려고 합니다.
이 흐름에서는 문장 표현보다 문서 버전, 열람 권한, 인용 위치와 공유 방식이 중요할 수 있습니다.
제품의 완료 조건은 모델 응답이 아니라 고객의 다음 행동까지 포함합니다.
가령 요약은 자연스럽지만 폐기된 규정을 인용했다면 업무가 끝나지 않습니다.
답이 맞더라도 사용자가 문서를 다시 찾아야 한다면 검토 시간이 남습니다.
따라서 모델 응답 품질, 제품의 작업 완료율, 고객의 실제 성과를 서로 다른 항목으로 기록합니다.
셋이 함께 좋아질 수는 있어도 하나의 점수로 같은 사실처럼 표현하지 않습니다.

업무 데이터·워크플로·신뢰와 권한·완료 품질을 모델과 구분한 AI 제품 가치 구성도
업무 문서가 많다는 사실만으로 경쟁력이 생기지는 않습니다.
문서의 사용 권리, 갱신 주기와 책임자가 정해져 있어야 지속해서 사용할 수 있습니다.
오래된 문서가 새 문서와 섞이거나 고객별 자료가 같은 검색 결과에 나타나면 데이터가 오히려 위험이 됩니다.
검색 품질도 모델과 분리해서 확인합니다.
Anthropic은 문서 조각만 저장할 때 원래 문맥이 사라질 수 있음을 설명하고, 검색에 문맥을 보강하는 접근을 제시합니다.
Anthropic Contextual Retrieval↗
예제에서는 규정의 시행일·문서 제목·적용 팀을 함께 관리하는 방식으로 적용할 수 있습니다.
다만 그 회사의 검색 실험에서 얻은 개선율을 우리 서비스의 정확도나 매출 개선율로 옮겨 쓰지는 않습니다.
검색 결과에 필요한 근거가 있었는지 먼저 검사하면, 답변 실패가 검색 때문인지 생성 때문인지 나눌 수 있습니다.
검색 실패를 모두 비싼 모델로 해결하려 하면 비용만 늘고 원인은 남을 수 있습니다.
데이터 정리와 재색인에 드는 사람의 시간도 운영 원가에 포함해야 합니다.
고객이 매번 파일을 내려받아 업로드하고 답을 복사해야 한다면, 모델 호출 앞뒤의 수고가 큽니다.
문서 저장소와 연결하고 근거를 눌러 원문으로 이동하며 검토 후 공유할 수 있다면 반복 작업이 줄어듭니다.
이때의 가치는 연결 기능 수가 아니라 고객이 실제로 줄인 단계와 재작업 시간으로 확인합니다.
권한은 검색 요청부터 적용해야 합니다.
OWASP는 벡터·임베딩 계층의 부적절한 접근 제어와 사용자 간 정보 유출을 위험으로 다루며, 권한을 반영한 검색과 데이터 분리·로그를 권고합니다.
OWASP 벡터·임베딩 취약점↗
사용자가 원문을 볼 수 있는지, 인용 링크와 캐시에서도 같은 권한이 유지되는지 확인해야 합니다.
🖐️
“다른 팀의 문서는 보여주지 마”라는 프롬프트만으로 접근 권한을 구현하지 않습니다.
권한 없는 자료가 모델 입력에 들어간 뒤 답변에서 숨기기를 기대하는 방식은 신뢰 경계를 뒤집습니다.
감사 기록에는 누가 어떤 문서 버전을 조회했는지, 어떤 모델과 검증 규칙을 사용했는지 남깁니다.
문서 원문을 필요 이상으로 로그에 복제하지 않고 보관 기간과 열람 범위도 정합니다.
장애 때 다시 시도할 수 있고 잘못된 공유를 중지할 수 있는 운영 절차까지 있어야 기능이 업무에 들어갈 수 있습니다.
모델에 종속된 부분을 확인하려면 같은 입력과 완료 기준으로 후보를 바꿔 봅니다.
예제 평가 묶음은 답변 가능 요청 80건과 접근을 거절해야 하는 요청 20건으로 나눕니다.
아래 값은 실험 기록의 형식을 보여주는 가정이며 실제 벤치마크가 아닙니다.
| 평가 항목 | 후보 A | 후보 B |
|---|
| 답변 가능 80건의 품질 통과 | 70건 | 74건 |
|---|
| 접근 금지 20건의 올바른 거절 | 20건 | 19건 |
|---|
| 답변 가능 작업의 사람 수정 시간 | 합계 40분 | 합계 25분 |
|---|
| 전체 평가 실행 비용 | 별도 기록 | 별도 기록 |
|---|
후보 B는 답변 품질이 높아 보이지만 권한 검사 한 건을 통과하지 못했습니다.
좋은 평균 점수가 금지된 정보 노출을 상쇄하지는 않습니다.
필수 보안 조건을 먼저 통과시킨 다음
완료율·응답 지연·사람 수정 시간과 비용을 비교해야 합니다.
안전한 거절은 답변 완료와 다른 성공 유형으로 남기고, 두 수치를 섞어 서비스 원가의 분모로 사용하지 않습니다.
모델 교체에는 프롬프트 조정, 출력 형식과 도구 호출 검증, 운영 복구 비용도 듭니다.
기존 검증 루프 글의 방식처럼 변경 후 같은 기준을 다시 실행하고 실패 사례를 남깁니다.
이 과정에서 유지되는 검색·권한·업무 연결이 제품의 자산이고, 모델에 맞춰 바뀌는 부분은 교체 비용입니다.
차별성을 “우리도 AI를 쓴다” 대신 확인 가능한 질문으로 바꿉니다.
| 영역 | 확인할 질문 | 남길 근거 |
|---|
| 데이터 | 최신·정당한 자료를 찾는가? | 버전·갱신 책임·검색 실패 |
|---|
| 업무 연결 | 고객의 단계를 줄였는가? | 완료 시간·재입력 횟수 |
|---|
| 신뢰 | 권한과 실패 처리가 유지되는가? | 거절 테스트·감사 기록 |
|---|
| 교체 가능성 | 다른 모델에서도 업무가 끝나는가? | 같은 평가 묶음의 결과 |
|---|
한 번의 데모만으로 고객이 계속 지불할 이유를 확정할 수는 없습니다.
반복 사용, 유료 갱신, 지원 요청과 실제 완료 업무를 함께 관찰해야 합니다.
반대로 업무 연결이 복잡하다는 이유만으로 고객 가치를 가정해서도 안 됩니다.
별도 시스템을 유지하는 수고보다 줄어드는 업무 비용이 작다면 구매 이유가 약할 수 있습니다.
👨💻
가장 자주 쓰는 고객 업무 하나를 골라 수동 방식·모델 직접 사용·우리 제품의 완료 과정을 나란히 적어 보시기 바랍니다.
응답 문장보다 남은 검토와 공유 단계에서 차이가 드러날 수 있습니다.
AI 제품의 경쟁력은
고객의 업무를 안전하고 반복 가능하게 끝내는 구조
에서 찾을 수 있습니다.
모델이 더 좋아질 때 사라지는 기능과, 그 위에서도 계속 필요한 데이터·권한·업무 연결을 구분해 보시기 바랍니다.
그 가치를 직접 유지하는 비용이 타당한지는 별도 질문입니다.
다음 편에서는 같은 요구사항을 기준으로 직접 개발과 SaaS 구매의 12개월 비용을 비교합니다.