AI가 도메인을 이해한다는 말을 들으면 자연스럽게 따라 나오는 생각이 있습니다.
“그러면 그 도메인을 아는 사람이 굳이 필요 없지 않나.”
회사 입장에서는 꽤 끌리는 얘기일 겁니다. 연봉 높은 도메인 전문가를 계속 두는 대신 AI를 쓰면 된다는 거니까요. 법무팀, 의료 자문, 금융 분석가, 20년 차 시니어 개발자까지, AI가 그 지식을 다 빨아들였다면 그 사람들 일자리가 위험해집니다.
그런데 저는 이 얘기에 하나가 빠져 있다고 생각합니다. AI가 도메인을 이해하려면 누군가 그 도메인을 AI한테 먹여야 합니다. 그리고 먹이는 동안 무슨 일이 생기는지를 제대로 따져보는 사람은 별로 못 봤습니다.
왜 빠지는지를 생각해 보면 이해한다는 단어 탓도 있는 것 같습니다. AI가 도메인을 이해한다고 하면 AI가 알아서 배우는 것처럼 들립니다. 문장의 주어가 AI가 되니까요. 실제로는 누군가 가르쳐야 하고, 가르치는 쪽은 회사이고, 가르치는 재료는 회사 안의 정보입니다. 말 한마디에서 주어가 바뀌니 그 뒤에 따라오는 위험도 같이 안 보이게 되는 것 같습니다.
AI는 혼자 배우지 않습니다
ChatGPT나 Claude가 법도 알고 의학도 알고 금융도 아는 건, 사전 학습 단계에서 인터넷에 공개된 글을 엄청나게 많이 읽었기 때문입니다. 공개된 법률 문서, 의학 논문, 금융 보고서가 학습 데이터에 들어가 있으니 그 정도 지식은 갖고 있습니다.
회사 안의 도메인은 얘기가 다릅니다. 키움증권의 반대매매 발동 기준은 인터넷에 안 올라와 있습니다. 어느 병원의 원무 처리 절차가 GitHub에 있지도 않고, 어느 제조사의 불량 판정 기준이 논문으로 나온 적도 없습니다. AI가 사전 학습으로 가져갈 수 있는 건 공개된 데까지이고, 조직마다 수십 년 쌓아 온 안쪽 지식은 처음부터 AI 바깥에 있습니다.
공개된 데까지라는 말을 곱씹어 보면, AI가 잘 아는 분야일수록 이미 남들도 다 아는 분야라는 뜻이기도 합니다. 회사가 AI한테 기대하는 건 대개 남들이 모르는 부분에서의 판단일 텐데, 그 부분이 바로 AI가 처음부터 모르는 부분입니다. 그래서 AI가 다 안다는 인상은 공개된 지식 쪽에서 생기고, 회사가 실제로 쓰고 싶은 건 비공개 쪽에 있는 묘한 어긋남이 생기는 것 같습니다.
그리고 그 안쪽 지식이라는 게 대부분 문서로도 안 남아 있다는 생각이 같이 듭니다. 규정집에 적힌 건 일부이고, 나머지는 이 예외는 왜 이렇게 처리하는지, 이 거래처는 왜 따로 챙기는지 같은 것들이라 오래 일한 사람 머릿속에 있습니다. AI한테 먹이려면 그것부터 꺼내서 글로 만들어야 합니다. 먹이는 일 앞에 적는 일이 하나 더 붙는 셈인데, 적는 순간 그 지식은 사람 머리를 떠나서 파일이 됩니다. 파일은 복사가 됩니다. 저는 보안 얘기가 AI 서버로 가기 전부터, 그러니까 사내 공유 폴더에 처음 한 군데로 모이는 순간부터 시작된다고 보고 있습니다. 나중에 AI agent가 못 보는 건 코드가 아니라 코드 바깥의 context라는 글을 쓰면서 이 얘기를 반대쪽에서 한 번 더 했습니다. 거기서는 그 바깥이 AI한테 안 보여서 곤란하다고 했고, 여기서는 그걸 보여주려고 꺼내는 순간을 보고 있습니다. 같은 지식을 두고 한쪽에서는 안 보여서 문제고 한쪽에서는 보여줘서 문제인 셈입니다.
그러니 우리 도메인을 AI한테 이해시키겠다는 말에는 반드시 이 일이 따라옵니다. 내부 문서, 정책, 절차, 규칙을 AI한테 넣는 일이요. RAG 파이프라인을 만들어서 내부 데이터를 검색 소스로 붙이든, 파인튜닝으로 모델에 조직 지식을 녹여 넣든, 매번 프롬프트마다 관련 문서를 컨텍스트로 붙여 보내든, 어느 쪽이든 내부 정보가 바깥 시스템을 지나갑니다. 저는 문제가 거기서부터 시작된다고 봅니다.
세 방법이 기술로는 꽤 다른데, 보안 쪽에서 보면 차이가 생각보다 작은 것 같습니다. 파인튜닝은 지식이 가중치 안에 녹아 들어가니까 나중에 그 부분만 꺼내서 지울 방법이 마땅치 않고, RAG는 원문이 검색 저장소에 그대로 남고, 프롬프트에 붙이는 방식은 보낼 때마다 원문이 밖으로 나갑니다. 어느 쪽이든 한 번 들어간 걸 되돌리는 게 들어가게 하는 것보다 훨씬 어렵습니다. 만약 몇 달 뒤에 이 문서는 넣지 말았어야 했다는 걸 알게 되면, 그때 할 수 있는 게 뭔지 저는 잘 모르겠습니다. 아마 그냥 넣은 걸로 치고 넘어가는 경우가 제일 많을 것 같습니다. 넣는 방법은 다들 열심히 설계하는데, 빼는 방법을 같이 설계하는 경우는 별로 못 본 것 같습니다.
삼성이 먼저 겪었습니다
2023년 4월에 삼성전자에서 사내 기밀이 ChatGPT로 새어 나간 일이 알려졌습니다. 직원이 반도체 설비 관련 소스코드를 ChatGPT에 붙여 넣고 고쳐 달라고 한 일, 회의 녹취를 넣고 요약해 달라고 한 일까지, 몇 주 사이에 세 건이 연달아 있었습니다. 삼성은 그 뒤로 사내 AI 사용을 막고 자체 AI를 만드는 쪽으로 갔습니다. 삼성만 그랬던 것도 아니어서, 비슷한 때에 여러 회사에서 비슷한 일이 있었고 골드만삭스, JP모건, 애플 같은 곳은 사내 ChatGPT 사용을 공식적으로 막았습니다.
세 건이 몇 주 사이에 연달아 났다는 게 저한테는 제일 오래 남았습니다. 한 번이면 실수라고 할 수 있는데, 세 번이면 그냥 그때 그 회사에서 일하는 방식이 그랬던 겁니다. 그리고 알려진 건 들킨 것뿐입니다. 같은 무렵 같은 방식으로 일하던 회사 중에 아무도 몰랐던 곳이 훨씬 많았을 것 같고, 그쪽은 지금도 모르고 있을 수도 있습니다. 들키지 않은 유출은 사고 목록에 안 올라가니까요.
저는 이게 직원 한두 명의 실수 문제가 아니라고 생각합니다. 직원이 AI를 쓸 때마다 여기까지는 넣어도 되고 여기부터는 안 된다는 선을 매번 스스로 판단하게 하는 구조 자체가 약합니다. 게다가 AI가 쓸모 있을수록, 그러니까 구체적인 걸 넣을수록 답이 좋아진다는 걸 직원들이 알수록 그 선을 넘고 싶어집니다. 코드 리뷰를 잘 받으려면 코드를 더 넣어야 하고, 회의록 요약을 잘 받으려면 내용을 더 자세히 넣어야 하니까요. 일을 잘하고 싶은 직원일수록 더 많이 넣게 되는 셈이라, 성실한 사람이 오히려 사고를 낼 가능성이 높은 구조입니다. 저는 이게 제일 고약하다고 느꼈습니다.
붙여 넣고 엔터를 누르는 건 되돌릴 수 없는 일인데 화면에서는 아주 가벼운 일처럼 보입니다. 메일은 그래도 보내기 전에 받는 사람 이름이라도 한 번 보게 되는데, 채팅창에는 그런 멈춤이 없습니다. 쓰고, 보내고, 답이 옵니다. 저는 지우거나 밖으로 내보내는 일은 사람이 한 번 더 보고 하는 게 맞다고 보는 편인데, AI 채팅창은 그 확인이 제일 필요한 동작을 제일 쉬운 동작으로 만들어 놨습니다. 편하라고 그렇게 만든 거겠지만, 편한 만큼 멈출 틈도 없습니다. 보낸 다음에 아차 싶어도 할 수 있는 건 대화를 지우는 것 정도인데, 그게 정말 지워지는지는 또 앞의 약속 얘기로 돌아갑니다.
보안 정책이 있어도 막기 어렵습니다. 복사해서 붙여넣기 한 번이면 끝나는 일을 기술로 다 막는 건 거의 불가능합니다. DLP 솔루션을 들여놔도 사람이 직접 텍스트를 쳐서 넣는 걸 다 잡아내기는 어렵습니다.
만약 회사가 아예 다 막는다고 해 보면 그림이 더 이상해집니다. 사내 PC에서 AI 사이트를 차단하면, 일을 잘하고 싶은 그 직원은 아마 자기 폰을 꺼낼 겁니다. 막은 쪽 화면에는 사용량이 0으로 찍히니까 문제가 없어진 것처럼 보이는데, 실제로는 회사가 못 보는 곳으로 간 것뿐일 수 있습니다. 차단이 사람의 동기까지 없애주지는 않으니까요. 더 넣고 싶게 만드는 힘이 AI가 쓸모 있다는 데서 나오는 거라면, 그 쓸모가 커질수록 막는 쪽이 이기기는 더 어려워질 것 같습니다. 그렇게 보면 삼성이 자체 AI 쪽으로 간 것도 막으려는 것보다는, 어차피 쓸 거면 회사가 볼 수 있는 데서 쓰게 하려는 쪽에 가까웠던 게 아닌가 싶습니다. 실제로 그런 계산이었는지는 모르지만 저라면 그렇게 생각했을 것 같습니다.
클라우드 LLM은 제 데이터로 뭘 하는지
프롬프트를 보내면 그 데이터는 어디로 가는 걸까요.
평소에는 이 질문을 거의 안 하게 됩니다. 답이 너무 빨리 오니까요. 보낸 게 어딘가 먼 서버를 거쳐서 돌아왔다는 느낌보다 화면 안에서 바로 생겨난 것 같은 느낌이 더 큽니다. 데이터가 회사 밖으로 나갔다는 감각이 없으면 조심할 이유도 잘 안 떠오릅니다. 저도 쓰다 보면 그걸 자주 잊습니다.
서비스들은 대개 엔터프라이즈 계약을 맺으면 학습에 안 쓴다고 합니다. OpenAI도 Anthropic도 Google도 비슷한 정책이고, 기업용 API로 들어온 데이터는 모델 학습에 안 쓴다고 적혀 있습니다.
그런데 그걸 어떻게 확인할 수 있을까요. 밖에서는 확인할 방법이 없습니다. 안 쓴다고 말하는 회사를 그냥 믿어야 합니다. 빅테크가 거짓말을 한다는 게 아닙니다. 확인할 수 없는 약속에 회사 기밀을 맡기는 구조가 원래 약하다는 얘기입니다. 계약서에 적혀 있어도 데이터가 서버를 지나가면서 로그에 남는 것, 추론하면서 캐시되는 것, 모니터링 시스템에 기록되는 것까지 다 통제된다고 장담하기는 어렵습니다.
이걸 쓰다가 메일도 문서도 소스코드도 이미 다 남의 서버에 올라가 있다는 게 생각났습니다. 회사들은 원래 안 본다는 약속을 꽤 많이 믿고 삽니다. 같은 약속인데 AI 쪽이 유독 더 불편하게 느껴지는 건 올리는 이유가 달라서인 것 같습니다. 메일이나 문서는 보관하려고 올리고, AI한테는 이해시키려고 올립니다. 보관하는 쪽은 내용을 몰라도 일이 되는데, 이해시키는 쪽은 상대가 내용을 알아야 쓸모가 생깁니다. 상대가 알아야 의미가 있는 구조에서 상대가 아무것도 안 남긴다는 약속은, 문장은 똑같아도 무게가 좀 다르게 들립니다.
사고가 날 수도 있습니다. 큰 AI 서비스도 공격을 받습니다. 2023년 3월에 OpenAI에서 ChatGPT Plus 사용자 일부의 결제 정보와 대화 일부가 보인 일이 있었습니다. 규모는 크지 않았지만, 클라우드에 올라간 데이터가 사고가 나면 드러날 수 있다는 건 그대로입니다.
규모가 작았다는 게 저는 오히려 더 신경 쓰였습니다. 크게 터지면 다들 알게 되고 대책도 나오는데, 작게 새는 건 자기 데이터가 그 안에 있었는지도 모르고 지나갑니다. 회사 쪽에서는 우리 대화가 그 일부에 들어 있었는지 알아낼 길이 마땅치 않을 것 같습니다. 사고가 났다는 걸 아는 것과 우리가 피해를 봤는지 아는 건 꽤 다른 문제인 것 같습니다. 작은 사고는 뉴스에서도 금방 사라지니까, 나중에는 그런 일이 있었다는 것조차 잘 기억이 안 납니다.
그러니까 AI한테 도메인을 이해시키겠다는 결정은 동시에 우리 도메인 정보를 남의 서버에 올리겠다는 결정입니다. 저는 그 위험을 감수하겠다고 분명하게 정하지 않은 채, 생산성이 오른다는 이유만으로 그냥 진행되는 경우가 너무 많은 것 같습니다.
그 결정을 누가 내리느냐도 좀 이상하게 흘러가는 것 같습니다. 보안팀이 정하는 것도 아니고 경영진이 정하는 것도 아니고, 실제로는 오늘 이 문서를 붙여 넣을지 말지 고민하는 실무자가 하루에도 몇 번씩 정합니다. 회사 전체로 보면 그런 작은 결정 수천 개가 쌓여서 하나의 큰 결정이 되는데, 그 큰 결정을 내렸다고 생각하는 사람은 아무도 없습니다. 나중에 뭔가 터지면 다들 자기는 그런 결정을 한 적이 없다고 느낄 것 같습니다. 틀린 말도 아니고요. 보안팀은 정책을 만들어 뒀으니 할 일을 한 거고, 실무자는 일을 잘하려고 했을 뿐이고, 위에서는 생산성이 올랐다는 보고를 받았습니다. 각자 자기 몫은 다 했는데, 전체로 보면 아무도 정하지 않은 일이 벌어진 셈입니다.
로컬로 돌리면 될까
클라우드가 문제면 로컬 LLM을 쓰면 된다는 말도 자주 듣습니다. 온프레미스로 깔면 데이터가 밖으로 안 나간다고요. 맞는 말이고, 실제로 보안이 중요한 금융권, 병원, 공공기관에서는 이걸 진지하게 보고 있거나 이미 들여놓았습니다.
그런 곳은 오히려 고민이 덜할 것 같다는 생각도 듭니다. 바깥으로 내보내기 어려운 데이터가 처음부터 정해져 있으니 선택지가 좁습니다. 애매한 건 그 중간에 있는 회사들입니다. 법으로 막혀 있지는 않은데 기밀은 있는 회사, 클라우드를 써도 되긴 하는데 쓰기엔 찜찜한 회사요. 대부분 회사가 여기 있을 텐데, 이 회사들은 아무도 대신 정해주지 않으니까 결국 스스로 정해야 합니다. 그리고 스스로 정해야 하는 일은 대개 미뤄집니다. 미뤄지는 동안에도 직원들은 계속 쓰고 있으니, 정하지 않았다는 것 자체가 사실상 하나의 결정이 됩니다.
그런데 현실이 좀 다릅니다. 클라우드만큼 성능을 내는 로컬 모델을 돌리려면 장비가 있어야 합니다. 지금 GPT-4급에 가까운 오픈소스 모델을 제대로 돌리려면 고성능 GPU 서버가 필요하고, 그건 수천만 원에서 수억 원짜리 투자입니다. 작은 회사는 감당하기 어렵고, 큰 회사도 그 돈을 쓰려면 충분히 많이 쓰고 그만큼 남는다는 게 보여야 합니다.
성능도 걸립니다. 로컬에서 돌릴 수 있는 모델 크기에는 한계가 있고, 지금은 온프레미스 모델이 클라우드 최신 모델보다 뒤처집니다. 복잡한 도메인 추론이나 긴 컨텍스트를 다룰 때 특히 차이가 납니다. 보안을 지키려다 성능을 내주는 셈입니다.
보안과 성능을 맞바꾼다는 게 말로는 간단한데, 그걸 정하는 사람 입장에서는 꽤 애매할 것 같습니다. 성능이 떨어지면 직원들이 답답해하고, 답답하면 다시 바깥 서비스를 몰래 쓰고 싶어집니다. 앞에서 얘기한 그 성실한 직원이 여기서 또 나옵니다. 로컬 모델을 들여놓고도 그 모델이 충분히 좋지 않으면, 보안 때문에 산 장비가 보안을 못 지키는 일이 생길 수 있습니다. 저는 로컬로 가는 결정이 장비 값보다 이쪽에서 더 어렵다고 느낍니다.
이 글을 쓰고 한 달쯤 지나서 사내 GPU 워크스테이션 한 대에 직접 올려서 재봤습니다. 혼자 쓸 때는 5~7배 빨라졌는데, 팀 다섯 명을 같이 붙이자 평균 응답이 다시 한 자릿수로 돌아왔습니다. 장비 한 대로 끝나는 계산이 아니었습니다. 사람이 늘수록 장비도 늘어야 하고, 장비가 늘수록 그걸 돌볼 사람도 늘어야 합니다.
그러니까 로컬로 가는 결정은 한 번 사고 끝나는 결정이 아닌 것 같습니다. AI를 잘 쓰는 팀일수록 더 많이 쓰고, 더 많이 쓰면 장비가 모자랍니다. 클라우드는 많이 쓰면 청구서가 늘고, 로컬은 많이 쓰면 줄이 길어집니다. 어느 쪽이든 쓰는 만큼 뭔가가 늘어나는 건 같은데, 돈이 느는 쪽과 기다림이 느는 쪽 중에 뭐가 더 견딜 만한지는 회사마다 다를 것 같습니다.
유지보수도 있습니다. 클라우드는 모델 업데이트, 인프라 관리, 보안 패치를 서비스 회사가 해줍니다. 로컬로 가면 그게 다 회사 안으로 들어옵니다. ML 엔지니어가 있어야 하고, GPU 인프라를 관리할 사람이 있어야 하고, 모델도 때마다 바꿔줘야 합니다. 도메인 전문가를 AI로 바꾸려다가 AI 인프라를 관리할 새 전문가가 필요해지는 겁니다.
여기서 좀 웃긴 생각이 들었습니다. 도메인 전문가를 줄이자고 시작한 일인데, 로컬로 가면 ML 엔지니어와 인프라 담당이 새로 생기고, 그 사람들도 결국 이 회사 도메인을 어느 정도는 알아야 일을 할 수 있습니다. 무슨 문서를 넣어야 하는지, 나온 답이 맞는지 틀린지를 알려면요. 그러면 도메인을 아는 사람이 줄어드는 게 아니라 도메인을 아는 사람의 종류가 하나 더 늘어나는 셈입니다. 이게 비용 계산표에 어떻게 들어가는지는 저도 잘 모르겠는데, 처음에 그렸던 그림하고는 꽤 다를 것 같습니다.
그 사람이 필요 없다는 말
처음 얘기로 돌아가 보면, 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가 이해하게 만드는 일, 그동안 위험을 관리하는 일, 이해한 상태를 유지하는 일, 결과를 확인하는 일, 어느 단계에서든 사람이 필요하고, 그 사람은 도메인을 알아야 합니다.
기술을 알면서 도메인도 아는 사람이 생각보다 드물다는 게 또 걸립니다. 보통은 둘 중 하나를 잘 압니다. 그래서 실제로는 두 사람이 같이 정하게 될 텐데, 둘이 서로의 말을 알아듣는 데까지 시간이 꽤 걸릴 것 같습니다. 기술 쪽은 이 정도는 위험하지 않다고 하고 도메인 쪽은 이건 넣으면 안 된다고 하는데, 둘 다 자기 쪽에서는 맞는 말이라 어디서 멈춰야 할지가 잘 안 정해집니다. 그 사이를 이어줄 사람이 필요하다는 얘기를 하다 보면, 또 앞에서 말한 통역 얘기로 돌아오게 됩니다.
AI는 회사 기밀을 먹고 큽니다
이 구조를 거꾸로 놓고 보면 좀 불편한 그림이 나옵니다.
AI 서비스 회사한테 제일 값진 게 뭘까요. 더 많은 회사가 더 많은 내부 데이터를 넣을수록, 그게 학습에 직접 안 쓰이더라도 어떤 식으로든 서비스를 낫게 만드는 데 보탬이 될 겁니다. 어떤 질문이 들어오는지, 어떤 맥락에서 어떤 답이 쓸모 있었는지, 어떤 도메인 쪽 사용이 늘어나는지, 이런 겉 정보만으로도 모델과 서비스 방향을 꽤 정교하게 맞출 수 있습니다. 학습에 안 쓴다는 약속이 진심이라고 해도, 회사들이 알아서 자기 도메인을 AI한테 먹이는 구조가 누구한테 이득인지는 한 번 생각해 볼 만합니다.
제가 원래 공짜이거나 싼 서비스는 그 값을 다른 데서 받는다는 말을 오래 들어온 편이라, AI를 볼 때도 자꾸 그쪽이 먼저 눈에 들어옵니다. 돈을 내고 쓰는 기업용이라고 해도, 어떤 질문이 많이 들어오는지 같은 건 계약서가 다루는 범위 바깥에 있을 것 같다는 생각이 듭니다. 데이터 자체는 안 쓴다고 해도 데이터가 들어오는 모양은 남으니까요.
회사가 AI한테 도메인을 이해시키겠다고 정하는 순간, 자기 경쟁력을 남의 플랫폼 위에 올려놓는 셈입니다. 그 플랫폼은 언제든 정책을 바꿀 수 있고, 값을 올릴 수 있고, 서비스를 접을 수 있습니다. 도메인 지식이 사람 머릿속에 있을 때는 그 사람이 회사를 안 떠나는 한 남아 있습니다. AI 파이프라인 안에 있을 때는 그 파이프라인이 기대고 있는 바깥 서비스가 얼마나 오래가느냐에 묶입니다.
사람 머릿속에 있는 게 더 안전하다는 말이 좀 이상하게 들릴 수도 있겠습니다. 사람은 이직도 하고 경쟁사로 가기도 하니까요. 그런데 사람이 가져가는 건 그 사람이 기억하는 만큼이고, 한 사람이 한 번에 들고 나갈 수 있는 양에는 한계가 있습니다. 파이프라인에 정리돼 들어간 지식은 그런 한계가 없습니다. 모아둔 건 통째로 나갈 수 있습니다. 예전에는 지식이 여기저기 흩어져 있다는 게 비효율이었는데, 보안 쪽에서 보면 그게 일종의 방어였던 것 같다는 생각이 듭니다. AI를 들이는 목표가 그 비효율을 없애는 거였으니, 방어도 같이 없어지는 건 어쩌면 당연한 일인지도 모르겠습니다.
이게 위험이 아닌 회사는 없을 것 같습니다. 그걸 알고 감수하는 것과, 모르는 채로 생산성이 오른다는 말에 묻혀 넘어가는 건 다른 얘기입니다. 이 복잡한 걸 AI가 알아서 해줄 거라고 넘기는 곳은 결국 나중에 그걸 마주하게 될 것 같습니다. 대개는 사고가 난 다음에요.
그 다음이 실제로 얼마나 긴지는 한참 뒤에 다른 사건을 세다가 알게 됐습니다. 침해를 알아챈 실무자는 이틀 만에 위에 보고했는데, 규제기관에 닿기까지는 40개월이 걸린 회사가 있었습니다. 데이터가 나간 순간보다 그 뒤에 보고가 올라가는 길에서 시간이 훨씬 오래 걸렸습니다.
댓글
댓글 쓰기