프롤로그어느 날 밤의 피로퇴근길에 새 모델 소식을 훑다가 갑자기 피로해진 날이 있었다. 반년 전 며칠을 붙잡고 겨우 이해한 기법 아래 "이제 이 방식은 끝났다"는 문장이 달려 있었다.그날 든 감정은 놀라움이 아니라 이거였다.나는 계속 따라가기만 하는구나. 뭘 해도 흉내내는 것 같다. 하네스 엔지니어링, 루프 엔지니어링, Hermes Agent...이걸 또 공부해야 하나...공부는 계속했다. 강의도 듣고 프로젝트도 굴려봤다. 그런데 양은 늘어나는데 밀도가 안 느껴졌다. ' 나는 계속 따라가기만 하고 있구나. 뭘 해도 흉내내는 것 같다.' 실무자로서 AI를 활용해서 무엇인가 시도하는 사람이라면 나와 같은 사람이 꽤나 될 것 같다. 1. AI 활용에 대한 프로젝트 경험의 축적이 필요하다생각해보면 실력이 부족한..

AI로 뭔가를 만들어 본 사람이라면 하네스(harness)를 안 만들 수 없다. 모델 혼자 두면 엉뚱한 데로 새니까, 앞뒤로 뭔가를 덧대게 된다. 출력 포맷을 강제하고, 단계를 쪼개고, 검증을 붙이고, 실패하면 다시 부른다. 그렇게 덧댄 것들이 쌓여서 하나의 구조물이 된다.문제는 이 구조물이 영원히 자산으로 남지 않는다는 점이다. 어떤 하네스는 6개월 뒤에 짐이 되고, 어떤 하네스는 5년 뒤에도 필요하다. 이 둘을 구분하지 못하면, 없어져도 되는 걸 붙들고 유지보수하면서 정작 필요한 건 아무도 안 적어두는 상태가 된다.구분선은 의외로 단순하다. 모델이 못해서 만든 하네스인가, 우리가 안 정해서 만든 하네스인가. 실행 하네스: 모델의 부족함을 메우는 것실행 하네스는 모델의 능력 부족을 보완하려고 만든 것들..

RAG(Retrieval-Augmented Generation) 시스템을 실제로 구축하다 보면, 튜토리얼에서는 절대 알려주지 않는 결정의 순간들이 찾아옵니다. "벡터DB에 다 넣으면 되는 거 아냐?"라고 생각하며 시작했다가, 문서를 어디에 어떻게 저장할지부터 사용자의 질의를 어떻게 해석할지까지, 매 단계가 선택의 연속이었습니다.이 글은 여러 종류의 전문 문서를 다루는 검색 시스템을 설계하면서 실제로 부딪혔던 네 개의 갈림길과, 각 지점에서 내린 판단의 근거를 정리한 기록입니다. 완성된 정답을 나열하기보다, "왜 그렇게 결정했는가"의 사고 과정을 담으려 했습니다.시작점: 왜 저장소를 세 개로 나누는가가장 먼저 정리해야 할 것은 데이터가 어디에 사는가입니다. 처음에는 벡터DB 하나면 충분해 보였지만, 실제로..