“AI에게 도메인을 이해시킨다 — 그 순간 기업 비밀은 어디로 가나”
AI가 도메인을 이해한다는 말에서 자연스럽게 따라오는 결론이 있다.
“그러면 그 도메인을 아는 사람이 굳이 필요 없지 않나.”
기업 입장에서 이 논리는 꽤 매력적으로 들린다. 고액 연봉의 도메인 전문가를 유지하는 대신 AI를 쓰면 된다는 말이니까. 법률팀, 의료 자문, 금융 분석가, 20년 경력의 시니어 개발자 — AI가 그 지식을 흡수했다면 그 사람들의 자리가 흔들린다.
근데 이 논리엔 전제가 하나 빠져 있다.
AI가 도메인을 이해하려면, 누군가 그 도메인을 AI에게 먹여야 한다.
그 먹이는 과정에서 무슨 일이 생기는지를 제대로 따져본 사람이 별로 없다.
AI는 스스로 배우지 않는다
오해가 많은 부분이다.
ChatGPT나 Claude 같은 모델이 법률을 안다, 의학을 안다, 금융을 안다 — 이건 사전 학습(pre-training) 단계에서 인터넷에 공개된 텍스트를 대규모로 학습한 결과다. 공개된 법률 문서, 의학 논문, 금융 보고서들이 학습 데이터에 들어가 있으니까 그 수준의 지식은 갖고 있다.
근데 회사 내부 도메인은 다르다.
키움증권의 반대매매 발동 기준이 인터넷에 공개돼 있지 않다. 특정 병원의 원무 처리 프로세스가 GitHub에 올라가 있지 않다. 어느 제조업체의 불량품 판정 기준이 논문으로 나온 적 없다. AI가 사전 학습으로 흡수할 수 있는 도메인은 공개된 것까지다. 각 조직이 수십 년 동안 쌓아온 내부 지식은 AI의 기본 장착 범위 밖이다.
그러니까 “AI에게 우리 도메인을 이해시키겠다”는 말은 반드시 이 작업을 수반한다. 내부 문서, 정책, 프로세스, 규칙을 AI에게 입력해야 한다. RAG(Retrieval-Augmented Generation) 파이프라인을 구축해서 내부 데이터를 검색 소스로 연결하거나, 파인튜닝을 통해 모델 자체에 조직 특화 지식을 녹여넣거나, 아니면 매 프롬프트마다 관련 내부 문서를 컨텍스트로 붙여서 보내거나.
어떤 방식이든 내부 정보가 외부 시스템을 거친다.
거기서부터 리스크가 시작된다.
삼성이 먼저 당했다
2023년 4월, 삼성전자에서 사내 기밀이 ChatGPT를 통해 유출됐다는 사실이 알려졌다. 반도체 설비 관련 소스코드를 직원이 ChatGPT에 붙여넣고 코드 개선을 요청한 것, 회의 내용을 녹취해서 요약을 요청한 것 등 세 건의 사고가 약 20일 사이에 연달아 발생했다.
삼성은 이후 사내 AI 사용을 제한하고 자체 AI 개발로 방향을 틀었다. 그리고 삼성만의 이야기가 아니었다. 같은 시기 여러 기업에서 비슷한 사고가 보고됐고, 골드만삭스, JP모건, 애플 등은 사내에서 ChatGPT 사용을 공식적으로 금지했다.
이 사건들이 보여주는 건 단순한 실수의 문제가 아니다. 구조적인 문제다.
직원이 AI를 쓰는 상황에서 “여기까지는 넣어도 되고 저기부터는 안 된다”는 경계를 매번 판단하게 만드는 구조 자체가 취약하다. 특히 AI가 유용할수록 — 더 구체적인 컨텍스트를 넣을수록 더 좋은 답이 나온다는 걸 직원들이 알수록 — 그 경계를 넘으려는 유인이 강해진다. 코드를 더 잘 리뷰받으려면 더 많은 코드를 넣어야 하고, 회의록을 더 잘 요약받으려면 더 상세한 내용을 넣어야 한다.
보안 정책이 있어도 막기 어렵다. 복붙(ctrl+c, ctrl+v) 한 번이면 끝나는 일을 기술적으로 차단하는 건 현실적으로 불가능에 가깝다. DLP(Data Loss Prevention) 솔루션을 도입해도, 텍스트를 직접 입력하는 행위를 완벽하게 잡아내는 건 여전히 어렵다.
클라우드 LLM이 내 데이터로 무엇을 하는가
프롬프트를 보내는 순간 그 데이터는 어디로 가는가.
각 서비스의 공식 입장은 “엔터프라이즈 계약을 맺으면 학습에 쓰지 않는다”는 거다. OpenAI, Anthropic, Google 모두 비슷한 정책을 갖고 있다. 기업용 API를 쓰면 입력 데이터가 모델 학습에 활용되지 않는다고 명시돼 있다.
근데 이걸 어떻게 검증하냐.
외부에서 확인할 방법이 없다. “우리는 안 쓴다”고 말하는 회사를 믿어야 하는 구조다. 빅테크가 거짓말을 한다는 게 아니다. 검증 불가능한 약속에 기업 비밀을 맡기는 구조가 원래부터 취약하다는 얘기다. 계약서에 명시됐다고 해도, 데이터가 서버를 지나가는 동안 로그에 남는 것, 추론 과정에서 캐싱되는 것, 모니터링 시스템에 기록되는 것을 모두 통제할 수 있다고 보장하기는 어렵다.
여기에 더해 보안 사고 가능성이 있다. 대형 AI 서비스도 해킹의 대상이 된다. 2023년 3월 OpenAI에서 ChatGPT Plus 사용자 일부의 결제 정보와 대화 내용 일부가 노출된 사고가 있었다. 규모는 제한적이었지만, 클라우드 서비스에 올라간 데이터가 사고 시 노출될 수 있다는 사실 자체는 변하지 않는다.
결국 “AI에게 도메인을 이해시키겠다”는 결정은 동시에 “우리 도메인 정보를 외부 서버에 올리겠다”는 결정이다. 그 리스크를 감수하겠다는 명시적인 판단 없이, 생산성 향상이라는 이유만으로 진행되는 경우가 너무 많다.
그러면 로컬로 돌리면 되지 않나
여기서 나오는 반론이 있다.
“클라우드가 문제면 로컬 LLM을 쓰면 된다. 온프레미스로 구축하면 데이터가 외부로 나가지 않는다.”
맞는 말이다. 그리고 실제로 보안이 중요한 금융권, 의료기관, 공공기관에서는 이 방향을 진지하게 검토하거나 이미 도입하고 있다.
근데 여기서 현실이 끼어든다.
클라우드 수준의 성능을 내는 로컬 모델을 돌리려면 하드웨어가 필요하다. 지금 시점에서 GPT-4급 성능에 근접하는 오픈소스 모델을 제대로 돌리려면 고성능 GPU 서버가 필요하고, 그게 수천만 원에서 수억 원 규모의 인프라 투자다. 중소기업이 감당하기 어렵고, 대기업이라도 이 투자를 정당화하려면 충분한 사용 빈도와 명확한 ROI가 있어야 한다.
성능도 문제다. 로컬에서 돌릴 수 있는 모델 크기에는 한계가 있고, 현재 시점에서 온프레미스 모델의 성능은 클라우드 최신 모델 대비 격차가 있다. 특히 복잡한 도메인 추론이나 긴 컨텍스트 처리에서 차이가 두드러진다. 보안을 지키려다 성능을 포기하는 트레이드오프가 생긴다.
그리고 유지보수 문제가 있다. 클라우드 서비스는 모델 업데이트, 인프라 관리, 보안 패치를 서비스 제공사가 처리한다. 로컬로 구축하면 그 부담이 전부 내부로 들어온다. ML 엔지니어가 필요하고, GPU 인프라를 관리할 인력이 필요하고, 모델을 주기적으로 업데이트해야 한다. 도메인 전문가를 AI로 대체하려다가 AI 인프라를 관리하는 새로운 전문가가 필요해지는 구조가 된다.
“그 사람 필요 없다”는 논리의 모순
이제 처음 전제로 돌아온다.
“AI가 도메인을 이해하면 그 도메인 전문가가 필요 없다.”
이 논리가 작동하려면 세 가지가 전제돼야 한다.
AI가 그 도메인을 실제로 이해해야 한다. AI에게 도메인을 이해시키는 과정에서 보안 리스크가 없어야 한다. AI가 도메인을 이해한 상태를 유지 관리하는 데 추가 인력이 필요 없어야 한다.
셋 다 지금 시점에서 성립하지 않는다.
AI가 범용 도메인은 알지만 조직 특화 도메인은 모른다는 건 앞서 얘기했다. 이해시키는 과정에서 보안 리스크가 발생한다는 것도 방금 짚었다. 그리고 세 번째 — AI가 도메인을 이해한 상태를 유지하는 것도 공짜가 아니다.
RAG 파이프라인을 구축했다고 치자. 처음엔 잘 작동한다. 근데 내부 정책이 바뀌면? 새로운 규제가 생기면? 레거시 시스템이 교체되면? 그때마다 파이프라인을 업데이트하고, 벡터 데이터베이스를 다시 인덱싱하고, 프롬프트를 조정하고, 출력 품질을 검증해야 한다. 이 작업을 누가 하냐. 그 도메인을 이해하는 사람이 한다. AI 시스템을 유지하는 과정에서 도메인 전문가의 역할이 사라지지 않고 오히려 AI와 도메인 사이의 번역자로 변형된다.
그러니까 “그 사람 필요 없다”는 말은 맞는 것처럼 보이지만 실제론 틀리다. 필요한 역할의 형태가 바뀌는 거지, 사라지는 게 아니다. 예전엔 그 사람이 직접 분석하고 판단했다면, 이제는 AI가 제대로 분석하고 판단하도록 시스템을 설계하고 관리한다. 일의 성격이 바뀌었지, 일 자체가 없어지지 않았다.
도메인 전문가가 게이트키퍼가 된다
AI 도입이 성숙한 조직에서 실제로 벌어지는 일을 보면 흥미로운 패턴이 있다.
AI가 들어오면서 특정 직군이 사라지는 게 아니라, 그 직군 중 AI를 다룰 줄 아는 사람과 그렇지 않은 사람으로 갈린다. 법무팀에서 AI 법률 검토 툴을 도입하면, 법률 지식이 없는 사람이 그 툴을 쓰는 게 아니라 법률 지식이 있는 사람이 AI 출력을 검토하고 판단한다. 의료 AI를 도입한 병원에서 의사가 사라지지 않고, 의사가 AI 진단을 참고 자료로 활용하면서 최종 판단을 내린다.
이 패턴이 반복되는 이유가 있다. AI 출력의 신뢰도를 판단하는 능력 자체가 도메인 지식을 요구하기 때문이다.
AI가 계약서를 검토하고 “이 조항은 리스크가 있다”고 출력했다. 그게 맞는 말인지 아닌지를 판단하려면 계약법을 알아야 한다. AI가 환자 증상을 분석하고 “이 질환 가능성이 높다”고 출력했다. 그게 맞는지 확인하려면 의학 지식이 있어야 한다. AI가 코드를 리뷰하고 “이 부분은 성능 문제가 생길 수 있다”고 했다. 그 판단이 이 시스템의 실제 사용 패턴에서 의미 있는 문제인지 알려면 그 서비스의 도메인을 알아야 한다.
AI 출력을 검증하는 역할이 새로운 병목이 됐다. 그리고 그 병목을 해소할 수 있는 사람이 도메인 전문가다.
역설적으로 AI 도입이 도메인 전문가의 권한을 오히려 강화하는 방향으로 작동하는 경우가 많다. AI가 초안을 만들어주니까 더 많은 양의 검토 요청이 들어온다. 전에는 비용 때문에 법률 검토를 안 하던 계약서도 AI가 싸게 초안을 뽑아주니까 검토 요청이 늘어난다. 결국 도메인 전문가가 처리해야 하는 물량이 늘어나는 구조가 된다.
기업이 진짜 고민해야 할 것
AI 도입을 검토하는 기업이 실제로 따져야 할 질문들은 이런 것들이다.
우리 도메인 정보를 외부 AI 서비스에 입력할 때 어디까지 허용하고 어디서부터 차단할 것인가. 그 기준을 직원들이 실무에서 판단할 수 있도록 어떻게 교육하고, 어떻게 기술적으로 통제할 것인가. 온프레미스 구축이 필요한 영역은 어디이고, 그 비용과 성능 트레이드오프를 감수할 수 있는가. AI 시스템이 내부 도메인을 반영한 상태를 유지하려면 누가 어떤 역할로 관여해야 하는가.
이 질문들 중 하나도 AI가 대답해주지 않는다. 조직이 직접 결정해야 하는 것들이다. 그리고 이 결정을 잘 내리려면 기술을 이해하면서 동시에 도메인을 아는 사람이 의사결정 과정에 있어야 한다.
“AI가 도메인을 이해하면 사람이 필요 없다”는 말은 이 과정을 통째로 생략한 결론이다. AI가 이해하게 만드는 과정, 그 과정의 리스크 관리, 이해한 상태의 유지보수, 출력의 검증 — 이 모든 단계에서 사람이 필요하고, 그 사람은 도메인을 알아야 한다.
AI는 기업 비밀을 먹고 자란다
마지막으로 이 구조를 뒤집어보면 불편한 그림이 나온다.
AI 서비스 회사들에게 가장 가치 있는 것이 뭘까. 더 많은 기업이 더 많은 내부 데이터를 AI에 입력할수록, 그 데이터들이 — 직접 학습에 쓰이지 않더라도 — 어떤 형태로든 서비스 개선에 기여한다. 어떤 종류의 질문이 들어오는지, 어떤 컨텍스트에서 어떤 출력이 유용했는지, 어떤 도메인의 사용이 증가하는지 — 이 메타 정보만으로도 모델과 서비스 방향을 정교하게 조율할 수 있다.
“학습에 쓰지 않는다”는 약속이 진심이라도, 기업들이 자발적으로 내부 도메인을 AI에 먹이는 구조가 누구에게 이득인지 생각해볼 필요는 있다.
기업이 AI에게 도메인을 이해시키겠다고 결정하는 순간, 그 기업은 자신의 경쟁 우위를 외부 플랫폼 위에 올리는 거다. 그 플랫폼이 언제든 정책을 바꿀 수 있고, 요금을 올릴 수 있고, 서비스를 중단할 수 있다. 도메인 지식이 내부 인력의 머릿속에 있을 때는 그 인력이 회사를 떠나지 않는 한 유지된다. AI 파이프라인 안에 있을 때는 그 파이프라인이 의존하는 외부 서비스의 지속성에 묶인다.
이게 리스크가 아닌 기업은 없다. 그 리스크를 알고 감수하는 것과, 모르고 생산성 향상의 이면으로 넘어가는 것은 다른 얘기다.
AI에게 도메인을 이해시키겠다는 말은 생각보다 많은 것을 수반한다.
내부 정보를 외부에 노출하는 결정, 그 노출의 범위를 통제하는 구조, 유출 사고의 가능성, 로컬 구축의 비용과 한계, 도메인 전문가의 역할 변화, 외부 플랫폼 의존의 리스크 — 이 모든 것이 “AI 도입”이라는 단어 하나 안에 들어 있다.
그 복잡함을 “AI가 알아서 해결해준다”고 넘기는 곳은, 결국 그 복잡함에 나중에 맞닥뜨린다. 대개는 사고가 터진 다음에.
댓글
댓글 쓰기