LLM 서비스 개발은 장난이 아니다

그럼 수십 억 드는 사업이 장난일까, 라고 생각했다면, 다시 한 번 생각하기 바란다.

그걸 알면서 외주업체에 개발하라 하고 나몰라라 했다? 데이터 만들 내부 인력 배정 안했다? 그럼 수십 억, 수백 억 짜리 장난질 한 거다.

AI 전문가는 도메인 지식이 ㅈ도 없고, 없는 게 당연하다. AI 전문가가 들어와서 완벽하게 만들 수 있다면 당신의 필드는 전문성이 1도 없는 직군이란 의미다. 하다못해 AI 콜센터도 현업이 데이터 만들어주지 않으면 프로젝트가 제대로 될 수가 없다. 그런데 외주 줬으니까 다 해줘?

 

제발 좀 지랄하지 마라.

 

영업하는 사람이 무슨 헛소리를 하든 믿지 마라. AI 서비스 구축은 1년도 쉽지 않은 기간이고 무엇보다 중요한 게 현업 전문가다. 적당히 하루이틀 봐주면 되겠지, 라고 절대로 생각하지 마라. 서비스의 퀄리티는 당신이 들인 돈이 아니라 데이터 깎은 현업 담당자들의 시간의 총량으로 결정된다. 그게 있고 나서야 AI 전문가가 뭘 하든가 말든가 할 수 있다. 심지어, 국내 기업들은 기반이 될 기술들도 ㅈ도 없다. 현재로서는 쌩 노가다밖에 답이 없다.

 

그러니까 단 몇개월 만에 전문 영역에서 답변을 숨풍숨풍 해줄 AI 가 만들어질 거란 환상 좀 제발 좀 집어치워라. AI 에이전트같은 소리는 입 밖에 꺼내지도 마라. 우리나라에 그거 할 기술 없다. 정말로 없다. 지금 국내 수준에서, AI는 사업의 영역이 아니다. 연구의 영역이다. 그러니까 보여주기 식으로 기능만 덕지덕지 붙이지좀 마라. 그거 할 수 있는 기업 없다.

 

심지어 전문 영역은 오픈AI도 쉽게 못한다. 고작 수십 명, 심지어 거기에 AI 전문가는 기껏해야 서너 명 정도가지고 될 리가 없다.

 

당신이 AI 사업 외주 주는 담당자라면, 제발 이 글 보고 시작해라.

 

 

도메인 AI 구축 단계

어느 도메인이든, 거기에서 쓰는 전문 용어들이 있다. 심지어 일상 용어가 그 분야에서는 특별한 의미를 가지거나 비슷한 용어가 구분되기도 한다. 그런 디테일들이 도메인마다 다르다. 아무리 어마어마한 AI 모델이라도 그걸 처음부터 구분할 수 있는 건 존재하지 않는다.

 

존재하지 않는다. 중요해서 두 번 말했다.

 

당연히 도메인에 맞춰 파인튜닝을 해야 한다. 이거 하나하나가 보통 일이 아니다. 그래서 AI 담당자는 둘 중 하나다. 해야 할 게 너무 많거나, 할 수 있는 게 없거나. 개인적인 경험으로서는 현장 나가서 제일 중요한 업무가 고객을 좌절시키는 걸 설득하는 일이었다. 대체 왜 이런 쓸데없는 일을 해야하는지 모르겠다. ㅆㅂ, 그게 고객 가치인가? 차라리 본사에서 기술 개발해서, 더 좋은 기술 고객에 전달해 주는 게 났잖아!

 

지속 사전 학습 (Continual Pre-training)

도메인 용어, 표현방식, 서식 등을 학습시키는 데 무조건 필요한 게 바로 이 CPT이며, 이거 하지 않으면 전문용어의 이해 및 활용은 불가능한 걸로 알아라. 근데 이거 해준다 못한다. 어렵다. 정말 어렵다. 나만 어려운게 아니라 니들도 어렵다. 진짜, 이런 거 한다고 데이터 달라고 하면 대충 내부에 있는 문서 긁어다가 던져주고 끝, 이런 식으로 생각하지 마라. 절대 그딴 식으로 안 된다.

 

지속 사전학습은 간단히 말하면 글을 정독하는 거다. 글에서 한 단어 한 단어 읽어나가며, 앞의 내용을 바탕으로 다음에 어떤 단어가 오면 자연스러운지를 이해한다. 그로부터 단어의 의미, 문장구조, 단어간의 관계 등등을 학습한다. 언어 자체를 이해하려면 CPT가 들어갈 수밖에 없고 다른 학습법으로는 매우 힘들다. 잘 안 된다고 봐야 한다. 아니, 해보지 않아 확신은 없지만 그냥 안 된다고 봐라.

 

문제는, 여기에 최소 순수 텍스트로만 기가 단위로 필요하다는 것이다. 한글 문서, 워드 문서, PPT, 엑셀 등등, 그런 거 기준 말고 진짜로 .txt 문서만으로 1GB 이상이다. 거기에, 보통 서식 있는 문서들, 내용 뽑겠다고 변환하면 html 로 변환한다. 거긴 서식을 나타내는 태그가 엄청나게 달린다. 그거 포함 아니다. 그거 빼고다. 이게 최소다. 여기다 어떤 연구자가 '나는 더 적은 걸로도 되던데?'라고 할지는 모르겠다. 미안하다. 난 그 정도 실력 안 된다.

 

아니, 중요한 건 1GB로도 해본 적이 없다. ㅅㅂ. 그냥 그 정도로 가능하다 듣기만 했다. 말했잖아. 이건 연구의 영역이지 개발의 영역이 아니다. SI 가 아니라 R&D다.

 

그럼 문서 졸라 많이 던져주면 되겠네? 하면, 웃기지 마라, 이다.

 

파싱 (Parsing)

일단 모든 문서는 학습을 하려면 Parsing이란 과정을 거쳐야 한다. 서식 있는 문서를 서식 없는 텍스트로, 의미만 뽑아내는 과정이다. 그리고 이 과정에서 문서의 내용은 100% 깨진다. 특히 대부분, 거의 99.99%의 문서들이 보기 예쁘게 한다고 표준 따윈 개나 줘버려 만들어져 있다. 최악은 엑셀이다. 엑셀로 문서 좀 만들지 마라. 적어도, 엑셀로 된 문서는 그냥 안 된다고 머릿속에 박아둬라.

 

파싱 과정은 가장 간단한 게 문서를 HTML로 변환하는 것이다. HTML은 어지간한 서식을 모두 포괄할 수 있으며 동시에 순수 텍스트로도 해석할 수 있다. 그 다음 HTML 에서 불필요한 서식을 날리는 것이다. 처음부터 서식을 날리지 않는 건, 필요한 서식도 있기 때문이다. 예를 들면 줄바꿈, 문단구분, 표와 같은 것들이다. 하지만 문제는, 수많은 문서들, 특히 공공기관 문서같은 것들은 테이블을 서식으로 쓴다. 그래서 테이블 안에 테이블이 있는 참사가 빈번하게 발생한다. 어떤 테이블이 서식이고 어떤 테이블이 의미있는 내용인지 구분하기가 힘들다. 아니, 사실상 불가능하다.

 

PDF같은 걸 드래그해서 긁어 붙여보면 쉽게 알 수 있는 사실이 있다. 그렇다. 줄바꿈이다. 줄이 문서 폭을 넘어가 자동으로 바뀌는게 아니라 그 사이에 이 새끼들은 줄바꿈을 넣어버린다. 그럼 문장이 잘린다. 그걸 다시 이어붙이려면? 그걸 대체 무슨 기준으로 이어붙이나. 하다못해 줄바꿈이 있어야 하는 데에 없어지면, 문장부호로 구분이라도 한다. 하지만 반대 경우? 케이스가 너무 많다. 의미적으로 다 해석해야 한다. 일반 줄글이면 마침표가 없는데 끊어지면 붙일 수 있다. 하지만 그러면 그 사이에 띄어쓰기가 있는지 없는지 단어 보고 해석해야 한다. 심지어 줄글이 아닌 다른 서식에서 그런 식으로 잘리면? 케이스가 너무 많다.

 

전부 정크다.

 

그거 제대로 정리 안 된 채로 학습에 넣으면? 모델 박살난다. 왜냐하면, 그 모델은 이 글 중간에 갑자기 줄바꿈이 들어가야 한다고 배워버리기 때문이다. 줄바꿈도 문자다. 사람은 그걸 의미가 없다고 생각하지만, 사실 사람도 무의식중에 줄바꿈의 의미를 이해하고 있다. 지금 당장, 이 글에서 줄바꿈 다 없애버리고 읽어봐라. 끔찍할 것이다. 그래서 그런 줄바꿈이 들어가는 문맥도 모델이 파악해야 하는데 그걸 전부 잘못 배우는 거다.

 

그것만이 있는 게 아니다. 문제있는 요소가 너무도 많다. 이미 나와있는 모델은, 그런 거 하나하나 다 맞추기 위해 데이터를 어마어마하게 정제해서 만드는 거다. 그거 현장에서 뚝딱 해서 만들 수 있다? 그런 간단한 걸 위해 오픈 AI가 12조를 태웠겠나.

 

가장 간단한 건 룰 베이스로 최대한 잡아내 정제하고, 특히 그 도메인의 고유 문서 서식이 있다면 그것에 맞춘 전용 파서 만들어 처리하고, 그 다음 혹시나 또 문제 있는 거 있을지 LLM, 예를 들어 GPT같은 걸로 재생성 하게 하는 방법이 있다. 근데 재생성 과정에서 도메인의 고유 언어가 깨질 수도 있고, 이걸 수백 메가에서 기가 단위까지 하려면 비용과 시간이 폭발한다.

 

그럼 그걸 어떻게 하냐고?

 

그러니까, 못한다.

 

어휘 확장 (Vocab Expansion)

내가 전에 들었던 거 하나는, 정말 어이가 없었는데, 조합어가 의미가 완전히 달라 구별이 되어야 한다고 한다. A라는 단어 앞에 B라는 단어가 붙으면 완전히 의미가 달라진다고. 사실 일상에도 있다. 예를 들어 '계약'과 '가계약'은 다르다.

 

그런 것 까지 정밀하게 학습되려면 어휘확장 (VE) 까지 학습되어야 맞다. 여기서 어휘라는 건, LLM 모델이 인식하는 단어를 의미한다. 여기에 들어가는 문자열이 하나의 의미단어로 인식되며 의미가 서로 구분될 수 있다. 일반적으로 LLM모델은 모르는 단어가 나와도 그걸 아는 단어들의 조합으로 하여 이해할 수 있다. 하지만 정확도를 높이려면 그 단어가 어휘집에 들어가 있어야 한다. 특히 위와 같은 경우, 보통 '가계약'은 '계약' 앞에 '가' 가 붙은 걸로 이해한다. 그럼 기본적으로 LLM은 둘이 유사한 어휘로 볼 수밖에 없다.

 

뭐, 유사하다면 유사하지. 하지만 '계약'을 물었는데 '가계약'에 대해 나와버리면 애매해지잖아.

 

보통은 그게 문제가 안 된다. 하지만 도메인 영역에서는 저런 조합어가, 초보자가 보기에 뭐가 다른지 모르는 경우가 나타나는게 문제다. 그래서 잘못 대답해버리면 오해할 수 있기 때문에 문제다. 그런데...

 

사실 거기까지 LLM이 해결해 줘야 하는 게 맞는지 모르겠다... 애초에 지금의 LLM은 당연히 할루시네이션이 많이 발생하며, 특히 도메인 영역에서는 엄청나게 발생할 수밖에 없다.

 

또한 VE는 보통 어휘의 출현 빈도에 따라 이루어지지 사전에 의미 차이까지 구분해서 학습되지 않는다. 왜냐하면 어휘집을 만들어야 어휘의 의미 차이를 구분할 수 있기 때문이다. 그러니까, '계약'과 '가계약'이 문서에 졸라 많이 나오지 않으면 어차피 구분이 안 된다.

 

그러니까, 못한다.

 

데이터 정제 (Data Refinement)

LLM은 학습한 패턴을 문장의 자연스러운 구조로 이해한다. 따라서 이상한 글들이 들어가면 이상한 결과가 나올 수 밖에 없다. 예를 들어, 웹 크롤링을 하면 보통 HTML 문서에서 웹페이지의 메뉴 항목들이 나열식으로 뽑혀나오곤 한다. 전부 정크다. 그걸 그대로 학습하면 LLM은 그게 정상적인 문장인줄 안다.

 

보통 그런 문제로 많이 발생하는 게 반복문을 끊임없이 생성하는 것이다.

 

사람들은 LLM에 환상을 가지고 있는데, 많은 데이터를 보면 그것을 이해해서 말을 할 수 있는 게 아니다. 정말 극단적으로 말하자면, 기존의 데이터를 죄다 커다란 데이터베이스에 넣고, 상황에 따라 가장 적당한 문장을 그대로 읊는 것에 불과하다. 옛날 챗봇들이 그런 식이었다. 그거보다 좀 더 자연스럽게 짜맞춰 읊기 때문에 그럴싸해 보이는 거고, 언어 자체의 추상능력과 논리력이 탁월하기 때문에 생각을 하는 것 처럼 보이는 거지 전혀 생각을 하는 게 아니다.

 

즉, 거대한 LLM의 정보 공간 속에, 학습된 데이터들이 죄다 박혀있다. 그 중에 어떤 지점에 무진장 이상한 말이 들어가있다? 그게 나올 상황이 닥치면 그게 나오는거다.

 

앞의 파싱 문제와 함께, 데이터 정제 문제는 엄청나게 크리티컬하다. 그런데 그걸 일일히 다 보기엔, 1GB라는 텍스트의 양은 500KB 단행본 책 2000권에 해당한다. 심지어 그걸 비전공자가 봐서 정제, 할 수 있겠나?

 

물론 실제로 그걸 사람이 다 정제하는 건 말이 안 된다. 보통은 문서를 유형별로 정리해 거기에 맞는 정제 룰을 만들어 돌린다. 하지만 애초에, 하나의 룰로 다 퉁칠 수 있으면 어려운 일이 아니겠지? 당신이 업무 중에 만든 문서들도 같은 서식이 오히려 드물 거다. 같아 보이지만 내부적으로 다른 부분이 수도 없이 많다.

 

최대한 잡아야 성능이 오른다. 못 잡으면, 언제든 복병이 튀어나올 수 있다.

 

그게 끝이 아니다. 데이터 편향의 문제도 심각하다. 데이터가 한쪽으로 편중되어 있으면 모델은 그 이야기만 뱉어낼 수도 있다. 이건 더 심각한 문제인게, 자연어 데이터는 분류를 할 수 없다. 분류를, 어떻게 해? 문서 종류별로? 주제별로? 그럼 그것들의 중요도는? 그거에 따라 비중도 정해야 할텐데?

 

일반적인 LLM 연구에서 이에 대한 해법은.

 

닥치고 해보는 거다. 어마어마한 리소스와 시간이 걸린다.

 

그러니까, 못한다.

 

지시학습 (Instruction Tuning)

여태까지 다 못한다고 해서 서운했을 거다. 드디어 할 수 있고, 해야 하고, 메인이 되는 파트다. 지시학습은 모델이 사용자가 요청한 작업을 수행하는 법을 가르쳐주는 부분이다. 간단히 말하면, 사용자 질의가 들어오면 거기 맞는 답을 내주는 심플한 구조다.

 

그 심플한 것을, 실제로 하는 건 졸라 어렵다. 왜냐하면.

 

고객이 데이터를 안 주기 때문이다. 아니 ㅅㅂ, 어쩌라고.

 

시나리오 설계

지시 학습의 가장 최우선이 되는 작업은 시나리오를 설계하는 것이다. 그러니까, 고객이 AI로 어떤 작업을 하고싶은가가 메인이다. 당연히 미리 정의되어 있어야 하는 거다. 그런데 그게, 정의가 안 되어 있다.

 

일단 전문가가 아니면, LLM이, 그리고 요즘 나오는 AI 시스템이 뭘 할 수 있는지 모른다. 그래서 SI 업체들의 사업 담당들과 이를 미리 논의하지만... 아니, 그 사람들도 몰라. 젠장.

 

그건 그럴 수 있다. 그렇다고 치자. 하지만 그 다음이 문제다. 왜냐하면.

 

시나리오라는 건, 어떤 종류의 질문들을 해서, 어떤 식의 답변을 원하는지를 정의하는 것이다. 그게 한 턴이 될 수도 있고 여러 턴에 걸쳐야 할 수도 있다. 하지만 중요한 건, 사용자가, 어떤 식으로 작업에 필요한 정보들을 AI 모델에 줄 것이며, 그것이 어떤 식으로 답변이 나와야 하는지, 거기에 어떤 데이터들을 참고해야 하는지가 필요한데.

 

그걸 모른다.

 

... 현업 전문가 아니었어?

 

사람한테 물어보려 해도 그게 필요하잖아. 사람한테 일 시키려고 해도 이 일이 어떤 일이고, 어떻게 시킬거고, 어떤 자료들 참고해야 하고 어떤 결과 가져와야 할지 말하잖아. 근데 왜 그게 안 돼? 예를 들어.

 

주소를 물어보려고 하면, 주소에 대한 데이터베이스가 필요하다. 당연하다. 그리고 내가 원하는 장소를 뭐 어떻게 물어볼지가 필요하다. 예를 드면 '스타벅스 위치 알려줘'라고 물어보면 'XX구 XX동의 스타벅스 주소는 XXXX에요'라고 나왔으면 좋겠다, 라도 정의가 되어야 한다. 그리고 저걸 검색해야 하니, 데이터베이스는 '스타벅스'라는 말 만으로도 주소를 줄 수 있어야 한다.

 

이게 AI 전문성이 필요한 일인가?

 

데이터베이스가 어떻게 돌아가는지는 모를 수 있다. 그런데 그러면, 전산 담당자한테 물어볼 수 있잖아. 의미 기반으로 검색하는 RAG가 어떻게 돌아가는지 모를 수 있다. 그러니까 그건 AI 전문가가 설명해준다. 그렇게 설명 듣고 나면,

 

질문, 참조문서, 답변 셋이 나와야 한다. 그건 AI 전문가가 못해준다. 왜냐하면, 그건 '당신의 일'을 정의하는 내용이지 AI를 정의하는 게 아니기 때문이다.

 

시나리오에 대해서, 하나의 안을 제안할 수는 있다. 하지만 저걸 만드는 건 고객이어야 한다. 나중에 가서 '그거 원하는 답이 아니야'라든가, '우린 그런 식으로 안 쓰는데?' 하면 무슨 의미가 있는가. 이미 시간은 다 갔는데.

 

그러니까, 해주는 만큼은 해주지만 우리는 정답을 줄 수가 없다.

 

QA 데이터 생성

모든 지시학습은 결국 QA의 형태로 만들어진다. 실제로 QA가 아니라도 말이다. 예를 들면 끝말잇기 하자. 내가 먼저 시작할게. 사과 이렇게 말했다고 해도 이건 일종의 질의이고, 여기에 대응되는 답변은 예를 들면 과일 이 되어야 할 것이다. 그런 쌍들을 학습 시켜, 이렇게 물으면 어떻게 답해야 할지를 가르쳐주는 게 지시학습이다.

 

위의 연장이다. 애초에 질의, 참조문서, 답변의 구조를 이해하지 못하고, 그것에 대해 제시하지 못하는데, 실제 어떤 질문이 들어오고 답변이 나와야 할지 데이터를 만들어 줄 수 있을 리가 없다.

 

데이터는 보통 수 천 건에서 수 만 건 까지도 필요하다. 그걸 다 만들어달라곤 안 한다. 하지만 고객이, 현업 담당자가 만들어 준 개수만큼, 하다못해 검수해 준 개수만큼 결과의 퀄리티도 달라진다. 이상하게 데이터를 만들었는데, 그거 모르고 넘어가 오케이 해버리면, 나중에 그걸로 학습한다. 그때 가서 답변이 이상해 해봐야 아무 의미 없다.

 

수 천 건에서 수 만 건이다. 중요해서 두 번 말했다.

 

QA다. 질문과 답변이 있어야 한다. 문서 던져주고 끝이 아니다.

 

내가 이걸 어떤 식으로 쓸지를 정의해야 한다. 하지만 안 써봐서 모른댄다. 그럼 뭘 어떻게 하나. AI 전문가는 그럼 표준적인 대로, 일반적인 대로 만들 수 밖에 없다. 그러면 자기들과 안 맞는다 그런다. 안 맞겠지. 맞춰주질 않았잖아.

 

그러니까, 해주는 만큼 해주지만, 성능은 당신이 노력한 만큼이다.

 

파인튜닝

과제 하면 PEFT 되냐 LoRA는 되냐 Full Fine Tuning이냐 물어보는게 많은데, 그거 다 의미없는 말이다. 위에 꺼가 안 되면 다 무슨 소용인가. 애초에 과녁이 어디있는지 모르는데 국궁이든 양궁이든 컴파운드 보우든 맞출 수 있겠나?

 

위의 CPT와 똑같다. 이것도 정크 데이터 들어오면 모델 순식간에 깨진다. 이상한 헛소리 주절대는 앵무새가 된다. AI 전문가는 그렇게 되는 원인 파악해서 그거 맞춰 데이터 정제하고 바꿔보고 그런 거 하는 거다. 앞에 꺼가 이미 전부 되어있어야 뭘 할 수가 있다. 그게 안 되어 있으면 앞서 말했듯이 할 수 있는 게 없다. 몇 달 동안 위에 있는 걸 AI 담당자 서너 명이서 전부 다 한다? 그런 건 '판타지'라고 하고 그런 걸 시키는 놈을 '도둑놈'이라고 한다.

 

모델 깨지는 거 잡는 것도 쉬운 일 아니다. 모델 튜닝 한 번 해보는 데 일단 5천만원짜리 GPU가 필요하다. 그걸 수십 번 해 봐야 '아, 이게 어떻게 돌아가는구나'를 깨닫는다. 그것도 지금은 코드가 다 있으니까 하는 거다. 안 그러면 그거 돌리는 코드 짜니라 몇달씩 삽퍼야 한다.

 

왜 AI 전문가가 비쌀까? 그 AI 돌려보는데 수십억이 들기 때문이다. 10명 팀이 100억 써서 AI 모델 학습해봤다 치자. 그런 사람 하나 만드려면 최소 10억 드는 거다. 그런 사람을 1억에 고용할 수 있으면? 졸라 싼거 아닌가? 그러니까 해외에서 빅테크들이 어마어마한 돈을 들여 전문가 채용하는 거다.

 

오픈AI가 처음 챗GPT 출시할 때 12조 썼다. 당시 초기 멤버들은 12조짜리 멤버들인 것이다. 걸어다니는 12조들인 것이다. 수십억이 아까울까?

 

걱정마라. 국내의 전문가들 다 그만큼 돌려볼 기회도 못 받은 경우가 태반이다. 아직 저렴할때다. 어차피 국내 기업들 그렇게 투자 안하잖아.

 

... 울고싶다.

 

검색증강생성 (Retrieval Augmented Generation)

사실 지금의 AI 서비스 구축의 A-to-Z는 바로 이거다. RAG. 왜냐하면, 파인튜닝은 그만큼 불안정하고 어렵다. 위에 한 바닥 써재낄 만큼. 그에 비해, 이건 훨씬 더 간단하게 고객 도메인에 맞는 답변을 낼 수 있다. 왜냐하면, 고객의 데이터를 그대로 검색해 그걸로 답변하니까.

 

근데 이거도 쉽지 않다. 2가지 측면이 있다.

 

하나는, 정확한 문서를 검색해 오는 것 부터 힘들다는 것.

 

또 하나는, 정확히 검색해와도 상용 LLM이 그걸로 답변하는 능력이 떨어진다는 것이다.

 

RAG가 안되면 위에 꺼가 전부 완벽하게 잘 되도 만들어진 서비스는 망한다. 왜냐하면, LLM은 그냥 문장 완성하는 장치일 뿐이고, 답변이 올바르게 되려면 그 기반이 되는 '레퍼런스'가 올바르게 들어와야 하기 때문이다. Garbage In, Garbage Out 이다. LLM이 모든 질문에 모든 답변을 완벽하게 학습하더라도, 어떤 시스템이든 필요한 정보는 매번 바뀐다. 그걸 매번 새로 학습할수는 없다. 그래서 RAG를 쓰고, 그래서 RAG에 기반해서만 답을 하지 자의적으로 답하지 못하게 하는 게 기본이다. 그런데 RAG가 정상작동 안한다? 망하는거다.

 

따라서 쓸데없는 것들에 집착하지 말고 이 RAG에 집중해야 한다. RAG로 해결 안 되는 건 그냥 해결 못하는 거다. RAG가 충분히 잘 되고 나서 고도화해도 된다. RAG가 되어야 그나마 써보기라도 할 수 있고, 그래야 고객도 대충 이렇게 쓰는 거구나 감을 잡을 수 있으니 시나리오도 정의하고 데이터도 만들 수 있다.

 

그러니까 닥치고 RAG부터나 잘해라.

 

임베딩 모델 (Embedding Model)

임베딩 모델이란 건 자연어 텍스트를 어떤 수치적인 표현으로 변환해주는 모델을 의미한다. 간단히 말하면 벡터다. 주저리 주저리 나열되어 있는 문자열을 하나의 벡터로 변환해주는 것이다.

 

RAG를 구성할 때 사용하는 데이터베이스를 벡터 DB (Vector Database)라고 한다. 간단히 말하면, 정보를 벡터로 검색한다는 의미다. 기존의 DB는 데이터 레코드에서 어떠한 값이 사용자가 요청한 특정 값과 일치하면 그걸 찾아서 내뱉는 구조로 되어있다. 예를 들어, '이름이 김남수인 사람을 찾아와' 하면 이름이 정확히 맞는 사람을 찾아오는 것이다. 그런데, DB에 이름이 '김 남수' 로 저장되어 있으면 못 찾아온다. 하물며, 이름 정도가 아니라 긴 텍스트 본문을, 정확히 맞춰서 찾는 건 더욱 힘든 일이다. 그래서 벡터를 쓴다.

 

기존의 '검색엔진'은 '키워드'로 찾는다. 이것들은 1차로는 해당 키워드가 본문에 있는지를 찾는다. 그러니까 위의 '김 남수' 같은 일이 발생한다. 그래서 유의어 패턴과 표를 이용해 추가로 매칭할수도 있다. 예를 들어, '이름에서 띄어쓰기는 없애고 매칭시켜봐' 같은 룰을 적용한다거나 하는 것이다. 하지만 결국 검색한 키워드나, 사전 등록된 유의어라도 있지 않고서는 검색이 안 된다. 또한 맥락도 못 맞춘다. 예를 들어, '사형제'에 대한 관련 문서는 찾을 수 있다. 하지만 '사형제에 찬성하는 문서'는 못 찾는다.

 

그래서 임베딩 모델을 통해 의미를 수치화하고, 수치화된 의미가 유사한 걸 찾아내는 방법을 쓴다. 그런데 중요한건.

 

이 수치화는 '학습'에 기반해 만들어진다는 것이다. 따라서 학습되지 않은 도메인 영역의 데이터는 정확도가 떨어질 수 있다.

 

이건 필요하면 추가로 학습해 줄 수 있다. 하지만 보통은 이걸 하는 걸 전제로 하지 않는다. 위와 동일, 데이터 품질과 편향의 문제, 그로인한 모델 붕괴의 문제가 있기 때문이다. 어지간하면 얼추 다 맞춰주긴 한다. 그리고 대개의 경우, 검색이 안 되는 건 임베딩 모델의 문제가 아니라, 검색해야 할 대상 문서 데이터들의 문제다.

 

나는 못해준다. 이쪽은 안 해봐서. 하지만 필요하면 담당자 부르면 할 수 있다.

 

벡터 DB (Vector DB)

위에서 말한 벡터 DB. 보통 의미 기반의 벡터 검색과, 기존의 키워드 검색을 모두 지원하는 걸로 알고 있다.

 

여기서 제일 중요한 건 '메타데이터'다. 벡터가 의미를 구분해주지만 정확하지 않다. 보통 도메인의 문서들은 사람이 정독해도 의미가 가물가물한 것들이다. 그걸 초 단위로, 혹은 그 미만으로, 수십만 건 이상을 검색하는 시스템이 무슨 수로 정확할 수가 있나. 결국 미리 카테고리를 나눠 찾아들어갈 수 있도록 메타데이터를 통해 잘 구분해 들어간 후, 그 안에서 검색해야 정확해진다.

 

당연히 해준다. 근데 그래서 문제는 이 다음이다.

 

파싱 & 청킹 (Parsing & Chunking)

벡터 DB에 들어가는 데이터는 파싱과 청킹이란 작업을 통해 이루어진다. 파싱은 위에서 설명했듯 문서 데이터를 텍스트화 하는 것이다. 청킹은 그렇게 텍스트화 된 데이터를 의미 단위로 잘라놓는 것이다. 무언가 질문에 답해야 할 때, 두꺼운 관련 도서를 통으로 다 읽고 답할 수는 없다. 필요한 부분만 발췌해서 답해야 한다. 그 발췌할 수 있는 단위를 '청크 (Chunk)' 라고 하고, 그 단위로 문서를 쪼개는 걸 '청킹 (Chunking)'이라 한다.

 

이거 자체는 AI 전문가가 다 해줄 수 있고 해줘야 하는 영역이다. 근데 문제가 있다. 이들이 할 수 있는 건, 문서의 의미나 구조 따윈 모르겠고, 그냥 다 썰어줄게, 이다. 중복 문서, 답변에 방해가 되는 문서, 버전 등의 문제들은 전부 별개다.

 

보통 LLM과 RAG 기술을 이용한 챗봇을 구축할 때, RAG에서는 의미 기반으로 유사한 것들 순서로 가져와 참고한다. 그런데 전체 데이터셋에 똑같은 문서가 수십개씩 있다? 그 주제에 대해서는 그 똑같은 문서를 똑같이 가져다 답변할 것이다. 그 말은, 그 주제에 대해 다른 내용이 있더라도 참고되지 않을 거라는 의미다. 혹은, 같은 문서지만 버전이 다르다? 규정이 바뀌거나 어떤 주제에 대해 주기적으로 나오는 보고서라든가 그런 것들. 과거 버전의 내용이 답변에 참조될 위험이 매우 크다.

 

이건 고객만 어떻게 해서 될 일도 아니고 AI 전문가가 할 수 있는 일도 아니다. 별건 프로젝트로 진행되어야 한다. 사실 가장 중요한 게 바로 이거다.

 

그러니까, 미안하지만 제대로 된 솔루션, 국내는 커녕 외국에도 없을거다. 이거 제대로 하는 사업부터 해라.

 

RAG를 위한 LLM 파인튜닝

처음 말했던 것 중, 1. 정확한 문서를 검색해 오는 것, 2. 문서로부터 정확한 답변을 하는 것 중 위의 것들이 전부 1번에 관련된 내용이고 이건 2번에 관련된 내용이다. 그리고.

 

미안하지만, 상용 LLM들, 이거 제대로 튜닝 안 되어 있다. 사실 이게 되어있으면, 참조 문서 안 붙어있으면 답변을 거부해야 한다. 하지만 답변 하잖아? 안 되어 있는거다.

 

그리고 이거 제대로 하는 기술, 일단 국내에는 없는 걸로 알고 있다.

 

그리고 이게 제대로 안 되어 있으면? 일단 참조문서에 없는 말을 막 지어낸다. 전부 할루시네이션이다. 참조문서의 말을 왜곡해서 가져온다. 역시 할루시네이션이다. 내용을 가져와 설명하는데 쓸데없이 부가적인 내용을 붙인다. 참조 문서가 얼마나 주제에 관련이 있는지, 그에 따라서 주의 문구를 어떻게 표기할지, 그런 거 전부 제멋대로가 된다. 그런거 규제하려고 프롬프트 덕지덕지 붙이면 또 엉뚱한 데서 잘못 대답한다. 전부 할루시네이션이다.

 

근데 이걸 하는 게 쉬운 일이 아니다. 애초에 LLM의 목적 자체가 '말을 만들어내는 일'이다. 그러니까, 얘는 그게 진실이든 거짓이든 문법적으로 의미적으로 '그럴싸한' 말을 만들어내는 것 자체가 목적이다. 그래서 오픈AI나 엔쓰로픽 같은 선두 기업들도 할루시네이션을 못 잡는거다. 왜냐하면, 할루시네이션이 얘들 본업이니까. 어떻게 할루시네이션을 잡을까 이전에, 그게 할루시네이션인지 아닌지 구분하는 것 자체가 난제다.

 

이거 R&D 주제다. 대단히 어려운 내용이고 빅테크들도 못 풀고 있는 문제이며, 할루시네이션 자체는 절대로 해결될 수 없는 문제라는 게 대부분 전문가의 의견이다. 그런데 그거 연구는 커녕 이제야 LLM 가져다 쓰는 법 좀 배운 국내 기업들이 이걸 해결한다?

 

판타지의 영역이다.

 

미안하지만 못해준다. 나도 이거 좀 해보고 싶다. 그런데 이거 할 GPU 태울 기회 줄 기업이, 국내에 얼마나 있나.

 

정렬학습 (Alignment Tuning)

RLHF니 DPO니, 한창 떠들어대서 주워들어본 사람도 있을 것이다. 챗GPT 쓸 때 답변이 2개로 나오며 좋은 거 고르라고 할 때, 이걸 체험해본다. 둘 중 뭐가 더 좋은지를 학습하는 것. 그게 이거다. 더 자세히는 알 필요 없다.

 

다만, '둘 중 뭐가 더 좋은지 학습'이란 게 무슨 의미인지는 알아둘 필요가 있다. 이건.

 

생각보다 무시할 수 없는 문제다.

 

데이터셋

데이터셋은 위에 지시학습이 잘 준비되어 있다면 오케이다.

 

정렬학습의 데이터셋은 보통 지시학습에서와 같이 입력 (질의, 참조문서)와 출력으로는 원하는 답변(Chosen), 원하지 않는 답변(Rejected)이 필요하다. 그러니까 위의 지시학습에서 준비한 질의, 참조문서, 답변에 추가로 원하지 않는 답변이 추가되면 된다.

 

원하지 않는 답변은 모델이 해서는 안 될 말이 있다면 그걸 넣지만, 경우에 따라서는 현재 나오는 답변을 넣을 수도 있다.

 

유해성 규제

정렬학습이 나온 1차적인 목적은, 모델이 할 말 못할 말 구분 못하고 마구잡이로 내뱉는 문제를 해결하기 위해서다. 욕설, 비속어, 성적인 대화, 개인정보 등등 위험성이 있는 말들을 못 하게 막는 게 핵심이다. 이런 건 보통 퍼블릭 데이터셋이 있어 별도로 준비할 필요가 없으며, 보통 이런 건 상용 모델이라면 애초에 모델이 튜닝 되서 나온다.

 

개인적으론 이 문제에 대해 다소 회의감이 있다. 왜냐하면 LLM은 거대한 확률 모델이기 때문이다. 따라서, 어떤 데이터에서 욕설을 하는 답변을 거부하도록 학습을 시켜도, 입력값을 다르게 주면 그때는 그 욕설을 할 수도 있다.

 

이건 빅테크의 대표 모델들도 문제가 있고, 아무리 막아도 그걸 우회해서 답변을 끌어내는 탈옥 사례가 빈번하다. 이걸 자꾸 규제에 넣으려고 하는데 나는 그게 매우 짜증난다. 우리나라는 안 그래도 기술이 없는데, 저런 것까지 완벽하게 규제하지 않으면 책임을 물리려 하기 때문이다. 근데, 빅테크들도 차단에 실패한다. 어쩌라고. 하지 말라고?

 

https://www.aitimes.com/news/articleView.html?idxno=202047&utm_source=chatgpt.com

"AI 안전 정렬, 처음 몇단어에만 영향 미쳐...탈옥 쉬워" - AI타임스

 

봐봐. 안 됀다니까.

 

적어도 국내 기업들이 서비스를 낼 수는 있어야, 그 다음 고객 데이터 가지고 이걸 테스트라도 해 보지. 이거 지금은 아무도 못하는 거라고.

 

그러니까, 해줄 순 있다, 랄까, 이미 했다. 하지만 완벽한 건 없다.

 

스타일 정렬

사실 실제로 가장 필요한 건 이 부분이다. 대부분 실제로 서비스에 필요한 답변 스타일, 문서를 작성해야 하면 문서 양식, 표현방식, 주로 사용하는 용어 등등... 이걸로 못할거면 CPT로 해야하는데, CPT로 얼마나 될지도 미지수다.

 

스타일 문제는 정렬 학습 문제다.

 

근데...

 

일단 다음 넘어간다.

 

방법론 : RLHF, DPO...

장담하건데, 우리나라에서 RLHF (Reinforcement Learning with Human Feedback)을 제대로 해 본 업체는 하나도 없을거다. 그걸 할 수 있는 체계를 갖춘 업체는 그러니까 당연히 없다. 해본 업체도 손에 꼽을거다. 그냥 오픈소스 코드 갖다가 돌려보기도 쉽지 않다. 불안정하기 때문이다.

 

툭하면 모델이 터진다. 강화학습의 특징이다. 랜덤으로 탐색해 나가기 때문에 모델이 발산할 위험이 크다. 리소스도 많이 든다. 하물며 제대로 하려면, 진짜 제대로 된 Human Feedback이 필요하다. 근데 서비스 하는 기업이 얼마나 되지? 그리고 그 기업들이 서비스 시작한지는? 해본 기업들도, 퍼블릭 데이터로 공개된 거 가져다 돌려봤을 정도 뿐일 것이다.

 

DPO (Direct Preference Optimization) 은 훨씬 쉽다. 튜닝할 때 다른 학습과 비교하면 메모리를 따불로 먹지만 우리나라도 그 정도 GPU 는 이미 갖췄다. 충분히 돌려볼 수는 있다. 다만 솔루션은 없을 것이다.

 

과제에 필요해서 즉각적으로 돌려볼 수 있는 기업, 얼마나 있을까?

 

미안하지만 난 못한다.

 

AI 에이전트

이야기를 안 할 수가 없다.

 

당신이 원하는 서비스가, 단순 QA 챗봇이 아니라면, 당신이 원하는 건 에이전트다. 그리고 에이전트라도 필요한 기술 수준이 다르긴 하지만, 에이전트 말 나오기 전에 나왔던 거 말고 제대로 된 에이전트, 국내에 그거 해줄 수 있는 기업 없다.

 

"어? 여기는 그거 할 수 있다는데요?"

 

글쎄. 도메인 기업이면 할 수 있겠지. 위에서 누누히 말했지만, AI 사업은 도메인 전문가가 필수다. 오히려 도메인 전문가의 역할이 더 큰 경우도 허다하다. 고도화할 수록 더 그렇다. AI전문가 불러다 띡 던져주고 시켜서 되는 거? 외국도 못할걸...

 

나 : 국내의 도메인 AI 에이전트 사례를 조사해줘

 

네, 국내에서도 통신·공공안전·금융·제조·보안·여행·의료 등에서 도메인 AI 에이전트가 이미 상용화·시범 운영 중입니다. 아래 대표 사례들을 빠르게 훑어드립니다. 필요하시면 특정 분야만 묶어 더 깊게 정리해드리겠습니다.

• 통신(개인 비서/통화 에이전트): LG유플러스 ‘익시오(ixi-O)’—통화 요약·후속 할 일 제안·보이스피싱 실시간 탐지·대신 받기 등 기능, 최근 국제행사 전시. (구글 플레이)
• 공공안전(재난 신고 에이전트): 서울시 119 ‘AI 콜봇’—사고 유형·위치 파악, 긴급도 분류·우선연결, 시범 4개월 1만1천여 건 접수. (서울시 뉴스)
• 사회복지(돌봄 콜 에이전트): SKT ‘NUGU 돌봄 케어콜’—독거 어르신 안부 확인, 상담 내용 자동 분류·전달. (SK텔레콤 뉴스룸)
• 금융(지점·앱·직원 지원 에이전트): 신한은행 ‘슈퍼쏠’·‘AI ONE’(계좌/증명 발급, 지식 Q&A, 투자메이트) 시범·도입 소식, KB국민은행 직원용 생성형 AI 상담 챗봇과 AI 학습관리 플랫폼 구축 발표(챗봇·콜봇 학습 통합). (한국경제)
• 엔터프라이즈 업무(코파일럿/업무 에이전트): 삼성SDS ‘Brity Copilot/Automation’—회의 요약·메신저/메일 지원·권한 기반 데이터 연동, 인천국제공항공사 적용 및 다수 산업 도입(18만+ 사용자 보도). (Samsung SDS)
• 제조(산업 특화 에이전트): 마키나락스—현장용 도메인 특화 에이전트 구축/운영 플랫폼 ‘Runway’ 공개(거버넌스·폐쇄망 지원·GPU 효율화). (CIO)
• 보안(SOC/대응 에이전트): 국내 기업들의 ‘사이버 보안 에이전트’ 전방 배치 트렌드, 이글루시큐리티 보안 특화 생성형 AI 에이전트(AiR) 공개. (ZDNet Korea)
• 컨택센터(AICC 에이전트): 통신 3사·BPO 중심으로 상담 요약·지식검색·라우팅봇 등 확산(국내 시장 성장 기사), KT의 지자체 연계 ‘AI 복지사 돌봄’ 시범. (조선일보)
• 여행/OTA(여행 비서 에이전트): 야놀자—OpenAI ‘Operator’ 협력으로 계획~예약 자동화 에이전트 고도화, 최근 챗GPT 엔터프라이즈 도입 발표. (Chosunbiz)
• 의료(임상의사결정/방사선치료 에이전트): 온코소프트 ‘AI 주치의’—의료진이 채팅/음성 지시로 치료 부위 생성·자동 수정 등 다단계 명령 수행을 표방. (히트뉴스)

원하시면 위 사례 중 관심 분야를 골라 “도입 목적→아키텍처(모델·RAG·툴 연동)→거버넌스/보안→성과 지표(KPI)” 순으로 더 깊게 분석해 드리겠습니다.

- 통신(개인 비서/통화 에이전트): LG유플러스 : IT를 하는 도메인 기업이다. 파인튜닝 인력을 이미 고용했다. 이야기가 다르다.

- 공공안전(재난 신고 에이전트): 서울시 119 ‘AI 콜봇’ : LLM 기반 챗봇이 아니라 음성 -> STT -> 분류기다. 이것도 에이전트이긴 하다. 지금 주제는 아니다.

- 사회복지(돌봄 콜 에이전트): SKT ‘NUGU 돌봄 케어콜 : 역시 도메인 기업이 직접 한거

- 금융(지점·앱·직원 지원 에이전트): 신한은행 ‘슈퍼쏠’·‘AI ONE’ : 기본적으로 챗봇 서비스에 부가적인 분석 기능 개발 중. 이제 해보는 단계.

- 엔터프라이즈 업무(코파일럿/업무 에이전트): 삼성SDS ‘Brity Copilot/Automation’ : STT -> 회의록 기능은 이미 이전에 개발된 기술이다.

- 제조(산업 특화 에이전트): 마키나락스: 에이전트 이름 그냥 가져다 쓴 거다. 딱 봐도 최적화 기술이다. 
- 보안(SOC/대응 에이전트): 이글루시큐리티 : 도메인 기업이 직접 한거다. 내용 보니까 로그 자동 분석 같은 기술인 듯 한데, 그래서 에이전트 나오면서 가장 먼저 도입되는게 괜히 코딩 영역이 아니다. IT 도 AI 도 전산쟁이들 하는 일이니까...

- 컨택센터(AICC 에이전트) : 역시 도메인 기업이 직접에, LLM에 STT, TTS 접목한 것으로 보인다. 이걸... 에이전트 정의에는 맞는데 에이전트라 해야 하나? ㅡ.ㅡ;;

- 여행/OTA(여행 비서 에이전트): 야놀자 : 야놀자는 국내의 AI 대표적인 선두 기업 중 하나다. 역시 도메인 기업이 직접. 심지어 기사 보니 Open AI 참여해 '하겠다'고 한 거다.

- 의료(임상의사결정/방사선치료 에이전트): 온코소프트 ‘AI 주치의’ : 이거 하려고 만들어진 스타트업이며 이거 연구하던 연구팀이 만든거다. 역시 도메인 직접의 사례고, 연구에서 제품화로 가고 있는 단계다.

 

대부분 도메인 기업이 직접 하는 영역이고, 제품화가 아직 안 된 것들도 많다. AI 에이전트가 이슈화 되기 전에 이미 나온 기술과 파이프라인을 그대로 가져다 'AI 에이전트'란 타이틀을 붙인 경우들도 있다. 현재 기술 수준이 이 정도다. 

 

현재 LLM을 구축해주는 기업들, RAG 파이프라인 정도만 기술검증 끝난 상태다. 그마저 못하고 있는 기업들 낑겨서 하는 것도 허다할거다. 거기서 한 발 더 나아가 에이전트 구축해줘? 못한다.

 

아, TTS, STT정도는 붙여줄 수 있다.

 

에이전트 자체가 그냥 갖다 붙이면 다 되는 마케팅 키워드이긴 하다. 하지만 제대로 된 의미의 에이전트라는 건 '실제 업무 수행자'가 '한가지라도 업무를 대체할 수 있는 것'을 의미한다. 사실 그 의미에서, 단순히 STT, TTS 붙여놓은 서비스 역시 에이전트가 맞다. 그러니까 그건 할 수 있다니까? 하지만 다른 건?

 

신한, "투자메이트"를 한다고? 그거 감당 가능해?

 

내가 왜 이렇게 물고 늘어지는가 하면, 아래와 같은 이유가 있다.

 

- LLM 기반 AI 기술은 그나마 RAG 파이프라인만 검증되었고, 그게 실제 도메인 챗봇에서는 이제 구축단계다. 제대로 검증되지 않았다.

- LLM 기반 AI 기술은 빅테크마저 지속적으로 할루시네이션 현상을 보이고 있으며, 따라서 이를 업무에 제대로 적용하려면 아직 사용자의 숙련도가 필요하다. 그걸 기반으로 업무를 대체하는데까지 확장하는 데에는 리스크 요인이 크다.

- 하물며 업무를 대체하려면 업무 프로세스에 대한 이해가 필요하다. 이건 AI 전문가가 절대로 할 수 없으며 당연히 도메인 전문가가 필요하다. 이걸 AI 전문가가 할 수 있다고 하는 건 당신의 일이 전문성이 없다는 이야기와 동의어다.

- 일반적으로 LLM, 임베딩 모델을 포함한 언어모델 기반 AI 기술들은 모두 정확도가 떨어진다. 왜냐하면 이것이 다루는 영역 자체가 대단히 추상적이고 변화범위가 넓은 자연어를 기반으로 하고 있기 때문이다.

- 일반적으로 AI 에이전트는 여러 단계의 스텝들로 이루어져 있고, 위 정확도 문제와 엮여, 각 스텝마다 오류가 증폭된다.

 

위 이유들로 인해 LLM 기반 AI 에이전트는 대단히 까다로운 문제다. 이건 절대 개발단계가 아니라 연구단계임을 인식해야 시도를 해볼 수 있다. 물론, 연구단계임을 전제로는 시도해 보는 게 긍정적이다. 진짜로. 성능이 엉망이라도 일단 적용은 해봐라. 그거 자체는 매우 긍정적이다. 하지만.

 

제발 좀 거기에 정확도 따지지 마라. 높은 분이 와서 감시하려고 하지 마라. 이런 거 몇 달 만에 완성도 높일 생각 죽었다 깨나도 하지 마라. 진짜로, 기껏 기술확보 할 수 있는 기회를 다 망치는 짓이다. 정말 보고 싶으면 담당자한테 성능 안나와도 되니까 그냥 보여만 달라고 귀에 못이 박히도록 말해라. 높은 사람이 보겠다 하는 순간 성능 나와야하고, 말도 안되는 기준들이 생겨나며, 보고를 위해 가라로 평가지표 만들어서 90% 이상 찍어야 하고, 쓸데없는 일이 무수히 많이 늘어나는데, 정작 데모 때 엉뚱한 답변 하나 나오면 프로젝트 폭망한다. 그리고 개발팀 사기는 밑바닥까지 떨어진다. 아니, 당신이 오기 전에 이미 사기 개박살난다.

 

우리나라의 기업의 가장 큰 문제는, 고위 임원들이 해결사가 아니라 평가자가 되려 한다는 것이다. 그러면 그럴수록 기술자들은 거짓말쟁이가 된다.

 

 

이제 뒤집어 생각하자. 안 되는 건 다 말했다.

 

그럼 되는건?

 

AI 사업이 성공하려면?

1. 사업 공고 내기 전에 문제 정의를 명확히 해라. 그리고 해결될 수 있는 문제부터 골라서 풀어라. 원래 문제 정의는 그 분야의 최고 전문가가 하는 거고, 그걸 풀 수 있는지, 어떻게 푸는지를 기술자가 하는거다.

2. LLM 챗봇을 도입하려 한다면 그냥 일단 챗봇만 도입해라. 튜닝이고 뭐고 따지지좀 말고 그냥 챗봇 도입하는 걸로 1차사업 하고, 실제 써보면서 문제파악하고, 그거 정리해서 2차사업 해라. 대체 써보지도 않은 기술을 니들이 어떻게 정의할 생각이냐. 그러니까 사업 들어가도 아무도 데이터 만들어주지도, 검수해주지도, 시나리오 정의해주지도 않고 프로젝트 공회전하다가, 막판 가서 뭐가 안되니 답변이 어떻느니 말이 나온다. 

3. 챗봇 도입할 때 가장 중요한 건 RAG를 위한 데이터 설계고, 니들 있는 거 그대로 쓸 생각 말고 AI 에 맞춰서 데이터 축적하는 방법론부터 설계해라. 사실 모든 AI 사업의 근원적인 문제다. AI는 데이터가 A-to-Z다. 데이터가 없는데 뭘 어떻게 해보고 자시고 하나. LLM 말고 다른 AI PoC도, 들어가서 '이런이런 문제 풀어주세요' 해서 가봤더니, '그래서 데이터는요?' 하면 '데이터 그게 뭐죠? 먹는건가요?' 하지좀 마라.

4. 진짜 진짜 진짜로, 데이터가 뭔지는 알아보고 시작해라. 어렵지 않다. 입력(Input)과 결과(Output)이다. 이게 끝이다. 당신들이 어떤 상황에서 (입력:Input), 어떤 결과가 나오길 원하는지 (결과: Output) 를 정의해서, 거기에 대해서 데이터를 모으란 거다. 그걸 모아놔도, 실제로 해보려고 하면 못 할 때 많다. 그거조차 없으면 뭘 하질 못한다. 그래도 모르면, 사업 하기 전에 물어보면 되자나...

 

결론

상식적으로 생각하자.

있는 기술 제품화, 솔루션화 하려면 얼마나 걸릴까? 기술 수준과 제품 규모에 따라 다르지만, 보통 6개월에서 1년 걸릴거다. 거기에 들어가는 기술이 완벽하게 기술검증이 되어있을 때 이야기다. 보통의 SI 사업이다. 물론 SI사업 대규모가 되면 몇년 걸리는거 일도 아니다.

그런데 현재 검증되지 않은 첨단 기술은? 당연히 완벽한 결과를 보장할 수 없다. 안 되는 거 당연하고, 그거 되게 하는 데도 몇 년이 걸릴 수도 있다.

OpenAI 가 챗GPT 처음 낸 것이 22년 말이다. 23년으로 쳐도, 지금 벌써 2년 반에서 3년을 바라보고 있다. 그리고 거기 들어간 개발 비용은? 수십 조다. 그런데 고작 몇 백억 가지고 수십 조의 퀄리티를 원한다? 그걸 우리는 '도둑놈'이라고 말한다. 물론 그거 가능하다고 하는 사람은 '사기꾼'이라 부른다.

우리 진짜 사기꾼과 도둑놈이 되지 않고 현실적인 일을 하자. 그건 길게 보는 것이다. 기술을 도입하고 차근차근 고도화 해 나가는 것이다. 처음부터 단기 프로젝트로 끝낼 생각 하지 말고 고도화를 위한 단계적인 설계를 하자는 거다. 뭐가 되니 안되니 따지는 게 아니라, 어떻게 하면 되게 할 수 있을까, 뭐부터 되게 해야 할까를 논의하자는 거다.

물론 대부분의 기업들이 돌아가는 구조 자체가 그렇게 안 되는 거 안다. 하지만.

그러니까 경영자들이, 리더들이 바꿔야 한다. 실무자가 무슨 힘이 있겠나.

 

AI 뿐만이 아니다. 경영자들이 기술을 대하는 자세가 모두 이런 식이면, 우리나라는 망하는 거 확정이다. 지금 우리나라의 모든 기술들, 전부 다 중국에게 잡아먹히고 있다. 그 와중에 미국은 지 살겠다고 동맹들까지 다 후려패고 있고. 이미 중국의 기술력은 우리나라를 넘어섰는데, Fast Follower의 이점조차 이미 중국에게 넘어갔다. 어쩔건가.

우리에겐 기술밖에 답이 없다.