neozest : neo+zest

 책은 다른 사람의 사고나 경험을 간접 체험할 수 있는 매우 저렴한 수단이다. AI에 대한 감각을 계속 갱신하기 위해 여러 가지 책을 읽어보는 중이다. 하지만 여전히 눈에 거슬리는 몇몇 단어들이 전면에 있는 책 표지는 불편하다. 나에게는 하네스와 AI 루프, ○ ○ ○ 엔지니어링이 그러하다. 이 책은 그중 두 개를 제목에 내세웠다. 하네스, AI 루프.

처음에는 그냥 트렌드 추적용으로 생각하고 별 기대없이 책을 펼쳤는데, 다른 책들에서는 접하기 어려운 저자 자신만의 소프트웨어 개발 하네스와 루프에 대한 경험과 생각이 잘 정리되어 있어서 좋았다. 대부분의 책이 루프는 이런 것이야, 하네스는 이런 것이야에 머물러 있다면 현업에서 적극적으로 도입해 보면서 실제로 겪은 일을 기반으로 생각을 정리했다는 점에서 이 책은 가치가 있다고 생각한다. 저자의 생각에 100%까지는 동의하지 못하지만, 고민의 방향은 100% 동의한다. 저자분은 게임 개발을 근 20년 가까이하신 개발자. 나의 생각과 같든 다르든, 자신의 경험을 용기 있게(?) 공개하고 의견을 나누는 책들이 많이 출간되면 좋겠다.

이 책은 켄트백이었나 엉클밥이었나, 여튼 두 사람 중 한 명이 소개했던 Cucumber를 살펴보면서 스쳐지나갔던 Gherkin을  소개한다. 잘 사용하시는 분인 것 같다. 사고의 프레임워크로도 괜찮아 보이는데, 다시 한번 신규 서비스 개발 과정에 적극적으로 시도해 봐야겠다.  As.... I want to... So that.....처럼 Given... When.. Then..으로 요구사항을 검토하는 것도 왠지 전체적인 명세를 명확히 만들어가는데 도움이 될 것 같다.

책 읽으면서 밑줄친 부분...

• 우리의 의도가 AI라는 컴파일러를 거쳐 기계가 실행할 수 있는 형태로 바꾸니 산출물에 가깝다.... 무엇을 만들 것인가에 대한 인간의 명확한 의도인 명세(Spec)와, 그 의도를 논리적으로 구조화한 설계(Design)가 본체이다.... 코드는 원본은 아니지만, 여전히 우리가 책임져야 할 결과물이다... 원본을  쥐고 있는 자가 시스템을 통제한다... 개발의 중심은 문법(syntax)에서 의도(Intent)로 이동했다.
• 설계하려는 기능의 동작 의도를 Context, Trigger, Reaction으로 나누어 구조화된 명세에 담아야 한다.... 우리가 무심코 생략한 빈칸은 소프트웨어 결함의 서식지이자 AI의 추정이 시작되는 자리이다.... 빈칸은 엔지니어 먼저 채워야 한다. 그래야 AI도 우리가 정한 경계 안에서 코드를 만든다... AI는 인간이 정한 WHAT을 바탕으로 HOW의 실행(execution)을 맡는다.
• Gherkin: Given/When/Then의 3단 구조는 기능의 동작을 조건, 행위, 결과로 나누어 작성하게 한다... 자연어 명세를 Gherkin 시나리오로 바꾸는 변환과정에서 작성자 스스로도 미처 인지하지 못했던 논리의 구멍을 발견할 수 있기 때문,.
• 엔지니어의 실력은 AI가 추론해야 할 작업과 기계적으로 검증해야 할 작업을 명확히 분리하여 루프를 배치하는데에서 드러난다... 엔지니어는 흩어진 단서를 연결해 문제를 정의하는 지능이었고, 이슈 시스템과 터미널, IDE사이에서 데이터를 옮기는 하네스였으며, 가설을 세우고 검증을 반복하는 루프 그 자체였다... 흔적을 남기지 않는 루프는 같은 실수를 반복한다.
• 하나의 태스크가 끝나면 세 종류의 기억이 남는다. 제품 코드가 어떤 경로로 실행되었는지, 에이전트가 어떤 과정을 거쳐 작업했는지, 다음 태스크가 무엇을 믿고 이어갈지를 각각 기록한다.
• AI는 전달받은 코드와 문맥 안에서 논리적으로 타당한 결과를 만들었을 뿐이다. 문제는 제품의 역사적 배경과 암묵적인 비즈니스 규칙을 전송하지 않은 채 결과를 운영에 반영한 데 있다.... 아무리 부조리해 보이는 코드라도 운영 환경에서 실제로 어떻게 동작하는지 증거를 확보하기 전까지는 손대지 않아야 한다.
• Mock을 많이 만든다고 해서 테스트하기 쉬운 구조가 되는 것은 아니다. 중요한 것은 외부 시스템과의 경계를 얼마나 작고 명확하게 통제하느냐다.... 절개선은 코드를 예쁘게 다듬기 위한 추상화가 아니다. 기존 동작을 검증하기 위해 테스트가 개입할 최소한의 통로이다.
• 사람의 기억 속에 잠들어 있는 비즈니스 규칙을 기계가 넘지 못할 가드레일로 바꾸려면 누구나 읽을 수 있는 명확한 문장으로 선언해야 한다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.

어느새 RAG는 손쉽게 구현할 수 있는 것처럼 여겨지지만, 기반 지식없이는 효율적으로 원하는 바를 구현하기가 쉽지 않다고 생각한다. 물론 RAG를 보다 쉽고 효과적으로 구축할 수 있는 다양한 오픈소스 프레임워크들이 나오고 있지만, 그래도 기반 동작을 익히는 데에는 이유가 있다. 이번에 읽은 책 <벡터 데이터베이스(한빛미디어, 니틴 보르완카르 저) >는 RAG의 핵심 구성요소인 임베딩과 벡터DB의 기본을 다져주는 책이다.

한빛에서 번역서가 나오기 전에 원서로 앞부분을 읽었던 터라, 2장 임베딩과, 5장 PGVector 이용한 논문 검색 시스템 구축, 6장 Ollama로 RAG 시스템 구축하기 관련 내용을 중점적으로 읽었다. 역시 한글이 쏙쏙 쉽고 빠르게 읽힌다.

먼저 임베딩부터 이야기해보자면, 문장을 구성하는 토큰을 다차원 공간에 매핑함으로써 유사한 어휘(토큰)들이 비슷한 공간에 위치하게 만드는 것이다. 좀 더 정확히 기술하자면 비정형 데이터를 고차원 벡터 공간의 숫자 표현으로 변환하는 것이다.  의미나 맥락이 비슷한 데이터는 이 벡터 공간에서도 상대적으로 가까운 위치에 배치된다. 가장 유명한 그림이 아래 그림이다. Word2Vec이 보여준 흥미로운 결과중 하나가 단어 사이의 의미 관계를 벡터 연산으로 어느정도 드러난다는 점이다. 인간이 사용하는 언어의 관계가 군집으로 표현되고, 그 군집간 벡터를 상징하는 단어가 있다는 사실이 놀랍다. 이걸 처음 발견한 초기 연구자들은 어떤 감정이었을까?

예전에 검색엔진 개발 팀에서 형태소 분석 결과를 바탕으로 역색인 파일을 만들고, 동의어 검색을 구현하기 위해 사전을 만들고, 사용자 질의를 어떻게 확장할 것인지를 정의하기 위해 온갖 짓들을 다했는데, 그때와 비교하면 요즘 임베딩과 벡터DB로 구현된 시맨틱 검색은 정말 엄청난 상전벽해의 느낌을 준다.

이 관계를 Word2Vec, Doc2Vec, 트랜스포머 모델까지  설명하면서 벡터데이터베이스의 등장 배경을 설명하는 것이 1장과 2장의 주요 내용이다. RDB나 NoSQL로도 벡터를 저장할 수 있지만, 코사인 유사도나 최근접 이웃검색을 효과적으로 수행하기엔 역부족이다. 그래서 결국 HNSW나 ANN 인덱스 등으로 벡터 검색에 특화된 벡터DB 사용을 고려할 수 밖에 없다.  개인적으로는 별도의 벡터DB를 도입하기 전에 일단 pgvector를 검토한다. FAISS, SQLite3-VSS,Chroma 등이 있지만, 메타 데이터와 벡터를 하나의 트랜잭션 경계 내에서 관리한다는 장점도 크고, 별도의 운영 시스템을 추가하기 않아도 되므로 pgvector를 사용하는 것이 정답이라 생각한다.

책의 전체적인 얼개는 벡터DB의 필요성 -> 개인이 사용하는 RAG 유틸 -> 서비스로 구축하기 -> 앞으로의 개선점(벡터 질의 언어)로 구성된다. 1,2장은 벡터DB의 등장 배경, 필요성을 언급했다면 3장에서는 벡터DB의 유사도 검색을 위한 색인(인덱싱) 기법을 설명한다. 정확도를 약간 희생하더라도 검색속도를 높이기 위한 인덱싱 기법을 살펴보면 벡터DB가 단순히 벡터 데이터를 저장하는 것이 아니라는 점을 알 수 있다. 5장에서는 arXiv 논문을 다운로드 받아서 텍스트를 추출하고, 이를 청크로 나눠서 벡터화한 다음, 조회하는 시스템을 Pgvector를 기반으로 구현한다. 6장은 Sqlite3를 사용하지만 Ollama를 통한 로컬 임베딩 API를 사용하는 것에 대한 내용이 주다. 임베딩 모델은 대체로 크기가 작은 편이므로 충분히 로컬 검색 환경을 구성하기가 쉽다. 이후 장에서 다루는 내용은 개인이 사용하는 것이 아니라 서비스로 구축하기 위한 스키마 설계부터 데이터 처리 파이프라인을 다룬다.

따라서 RAG를 한번이상 고민해 봤다면 1장부터 3장까지는 상식 측면에서 쉽게 읽을 수 있고, 4장부터는 서비스를 구축하는 과정으로 이해해서 8장까지 파이썬 코드와 함께 책을 읽으면 된다. 전체적으로 벡터DB와 RAG에 대하여 좀 더 자세히 이해하는데 도움이 되는 책이다. 다시 한번 RAG에서 어려운 부분은 벡터 검색 구현이 아니라, 어떤 데이터를 수집하여 청크를 어떻게 나누고, 어떻게 임베딩하며, 메타 데이터를 관리할 것이며, 검색 결과를 평가하는 것이  더 중요하다는 점을 느낀다. 결국 RAG도 데이터 엔지니어링의 도메인에 속하는 것 같다.

파이썬 코드를 사용하지만, 그렇게 난이도가 있는 코드를 사용하지 않으므로(또한 파이썬도 직관적인 언어이므로) 개발자 뿐만 아니라 AI 서비스 기획자도 앞부분부터 차례대로 읽어나가면서 개념을 이해할 수 있는 책이라 생각된다. RAG 시스템을 구축하겠다 이런 의도를 가진 팀이라면 반드시 학습해야 장점과 단점, 한계점을 공유할 수 있을 것이다.

단점은..결국 원서인 까닭에 한글 처리에 대한 내용이 부족하다. 책에서는 all-MiniLM-L6-v2 모델을 주로 사용하는데, 이 모델은 한국어 처리가 부실한 것으로 알려져 있다. 따라서 다중언어 버전인 paraphrase-multilingual-MiniLM-L12-v2이나 한국어에 특화된 KURE모델, Ko-SBERT 모델 등으로 예제가 보완되었으면 어떨까 하는 아쉬움이 있다. LLM이 등장하면서 한국어 처리의 벽이 많이 무너지긴 했지만, 그래도 벽은 여전히 벽이다.

9월 벡터DB와 함께 떠난 여행은 재미있었다.