KMS 프로젝트가 '실사 이후'로 밀리는 이유 — 레거시 데이터 마이그레이션의 구조적 리스크

왜 KMS(지식관리시스템) 도입 프로젝트는 유독 킥오프 때는 모든 게 명확해 보이다가, 계약 직전 기술협상 테이블에만 앉으면 갑자기 대답이 흐려지는 걸까요. 기능 하나하나를 짚어 물어봐도 돌아오는 답은 비슷합니다. "그건 실제 데이터를 열어봐야 확정할 수 있습니다." 처음 한두 번은 신중한 답변으로 들리지만, 협상 테이블 전체가 이런 조건부 답변으로 채워지는 걸 보면 이건 특정 담당자의 소극적 태도가 아니라 KMS 프로젝트 자체의 구조적인 현상이라는 생각이 듭니다. 이번 편에서는 그 구조가 왜 생기고, 어떤 식으로 일정 전체를 밀어내는지를 정리해 보려 합니다.

이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 2026년 9월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 등장하지 않습니다.

[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 11-1편

← 이전: 10-8 혼자 쓰는 챗봇의 현실 / 다음 → 11-2 비정형 이력 데이터 지식화의 함정

전체 목차 펼치기 (63편)

Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)

Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)

Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)

Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)

Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)

Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)

Part 7 — S2S 도입 전략·구매 의사결정 (4편)

Part 8 — LLM 콜봇 PoC 현장 (6편)

Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)

Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)

Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)

기술협상 테이블에서 반복되는 대답: "열어봐야 압니다"

KMS 도입을 검토하는 조직과 벤더가 마주 앉는 기술협상 자리에서는 보통 기능 목록을 하나씩 짚어 가며 확인합니다. 검색은 어떤 방식으로 동작하는지, 권한 체계는 기존 조직도와 맞물릴 수 있는지, 첨부파일이나 이미지가 섞인 문서도 처리 가능한지. 그런데 실무에서 여러 차례 이런 자리를 지켜보면, 이 질문들에 대한 답변 상당수가 "가능은 합니다만, 실제 데이터를 열어봐야 확정할 수 있습니다"라는 조건부로 수렴하는 패턴이 공통적으로 확인됩니다.

이건 벤더가 자신 없어서 그런 게 아닙니다. 기존 KMS나 협업툴에 몇 년간 쌓인 데이터는 문서마다 형식이 다르고, 같은 카테고리 안에서도 작성 규칙이 시기별로 바뀌어 있고, 첨부와 본문이 뒤섞여 있는 경우가 흔합니다. 이런 데이터를 실제로 열어보지 않은 상태에서 이관 난이도나 정제 공수를 확정하는 건, 사실상 추측에 가깝습니다. 그래서 견적서에 적히는 숫자도, 일정표에 적히는 기간도 상당 부분이 "실사 결과에 따라 조정될 수 있음"이라는 단서를 달고 나옵니다.

실사 지연이 곧 프로젝트 지연으로 이어지는 구조

문제는 이 단서가 단순한 면책 조항이 아니라 실제 일정에 직결된다는 점입니다. 견적과 일정 산정 자체가 실사 결과를 전제로 짜여 있기 때문에, 실사 착수가 늦어지면 그 뒤에 있는 설계·개발·이관·검수 단계가 도미노처럼 함께 밀립니다. 실사는 계약 이후 첫 단계로 배치되는 경우가 많은데, 여기서 며칠만 늦어져도 후속 일정 전체가 그만큼 뒤로 이동하는 식입니다.

더 까다로운 건 실사가 끝난 뒤에 나오는 결과가 애초 가정과 다를 수 있다는 점입니다. 데이터 양이 예상보다 많거나, 정제가 필요한 비정형 문서 비중이 높거나, 권한 체계가 시스템별로 제각각이었다는 사실이 실사 이후에야 드러나면, 그 시점부터 일정과 범위를 다시 조정하는 협상이 시작됩니다. 여러 KMS 프로젝트 사례에서 공통적으로 확인되는 패턴은, 결국 실사 지연이 곧 프로젝트 전체 지연으로 이어진다는 것입니다. 그래서 실무에서는 "실사 전에는 아무것도 확정되지 않는다"는 말이 냉소가 아니라 그냥 사실에 가깝게 통용됩니다.

"이관 자체를 포기한다"는 선택지

이런 구조적 리스크를 마주한 조직 중 일부는 아예 다른 길을 택합니다. 기존 KMS나 협업툴에 쌓인 데이터의 신뢰도가 낮다고 판단해, 기계적으로 옮기는 이관 작업 자체를 포기하는 것입니다. 대신 현업 구성원들이 필요한 콘텐츠를 처음부터 다시 정리해서 새 시스템에 직접 올리는 방식을 택합니다.

겉보기엔 소극적인 선택처럼 보이지만, 나름의 합리성이 있습니다. 신뢰도가 낮은 데이터를 그대로 옮기면 새 시스템도 결국 같은 문제를 이어받습니다. 형식이 뒤섞이고, 오래된 정보가 최신 정보처럼 섞여 있고, 중복된 문서가 여러 벌 존재하는 상태를 그대로 이관하면, 마이그레이션 공수만 들이고 품질은 개선되지 않는 결과로 이어지기 쉽습니다. 그럴 바에야 이관 공수를 아예 콘텐츠 재작성에 투입하는 편이 낫다고 판단하는 것입니다.

전담 조직 없는 재가공이 만드는 초기 데이터 공백

다만 이 선택지에는 눈에 잘 안 띄는 전제 조건이 하나 있습니다. 현업이 콘텐츠를 처음부터 재가공해서 올리려면, 그 일을 실제로 해낼 전담 인력이나 조직이 있어야 한다는 점입니다. 이 전제가 빠지면 흔히 벌어지는 실패 패턴이 있습니다. 시스템은 예정대로 오픈됐는데, 정작 그 안에 채워져야 할 콘텐츠는 텅 비어 있는 상태로 서비스가 시작되는 경우입니다.

현업 구성원들은 이미 각자의 본업이 있고, 콘텐츠 재작성은 그 위에 얹히는 추가 업무입니다. 명확한 담당과 마감이 없는 상태에서 "각자 알아서 올려 달라"는 식으로만 안내되면, 우선순위에서 계속 밀리다가 오픈 시점까지 손대지 못한 콘텐츠가 쌓입니다. 결국 이관을 포기하고 재가공을 택한 조직일수록, 그 재가공 작업을 누가·언제까지·어떤 기준으로 책임지고 끝낼지를 이관 계획 못지않게 구체적으로 정해 둘 필요가 있습니다. 그렇지 않으면 데이터 신뢰도 문제를 피하려던 선택이, 오히려 초기 데이터 공백이라는 또 다른 문제로 이어지게 됩니다.

여러 KMS 프로젝트를 옆에서 지켜보면서 남는 인상은, 실사와 마이그레이션은 프로젝트의 부속 단계가 아니라 전체 일정과 품질을 좌우하는 축이라는 것입니다. 견적서의 숫자도, 이관이냐 재가공이냐의 선택도, 결국 이 축이 얼마나 이른 시점에 얼마나 정확하게 그려지느냐에 달려 있었습니다.

AI 보이스봇이 답답한 이유: Cascaded 구조 레이턴시 완전 분석

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링