앨리스가 참조할 기초자료는 약 400페이지 분량의 매뉴얼이다.
문제는 이 매뉴얼이 단순한 텍스트 문서가 아니라는 점이다.
설명과 이미지, 화면 예시가 함께 섞여 있어 페이지별 내용을 분석하고 임베딩하는 데 상당한 시간이 걸렸다.
임베딩을 시작한 지 거의 하루가 지났고, 8시간이 넘어가는 시점에도 작업은 아직 마무리 단계에 있었다.
하지만 임베딩이 끝날 때까지 계속 화면만 바라보고 있을 수는 없었다.
그래서 다음 작업으로 넘어가기로 했다.
매뉴얼을 RAG 구조로 임베딩하면서 한 가지 고민이 생겼다.
벡터 데이터베이스를 만들어 놓는 것만으로 앨리스가 매뉴얼을 제대로 활용할 수 있을까?
일반적인 RAG 검색은 사용자의 질문과 유사한 문서를 TOP-K 방식으로 몇 개 찾아와 LLM에게 전달한다.
하지만 선수지식이 없는 앨리스가 내부 코드를 분석하고, 그 코드가 어떤 기능을 사용하는지 판단하고, 다시 그 판단이 맞는지 검증하려면 단순한 일회성 조회만으로는 부족해 보였다.
예를 들어 앨리스가 특정 태그나 속성을 처음 본다고 가정해 보자.
한 번 검색해서 비슷한 설명 몇 개를 가져오는 것만으로는 다음과 같은 질문에 충분히 답하기 어렵다.
이 태그는 정확히 어떤 기능을 하는가?
함께 사용되는 속성은 무엇인가?
이벤트나 데이터셋과 어떤 관계가 있는가?
실제 화면에서는 어떤 방식으로 동작하는가?
현재 분석 중인 소스에 이 설명을 적용해도 되는가?
결국 필요한 것은 단순 검색이 아니라, 궁금한 내용을 정리하고 단계적으로 조회하며 결과를 다시 검증하는 과정이라고 생각했다.
이런 생각을 쏘피와 계속 토론했다.
쏘피도 이 방향을 긍정적으로 봤고, 단순한 TOP-K 검색을 넘어서는 단계형 로직을 제안했다.
나는 임베딩이 완성되기 전에 먼저 1단계 검증 모듈을 앨리스 프로젝트에 이식하기 시작했다.
현재 생각한 단계별 로직은 다음과 같다.
먼저 분석 대상 코드에서 앨리스가 이해하지 못하는 요소를 추출한다.
태그, 속성, 이벤트, 데이터셋, 함수명 등 확인이 필요한 기술 요소를 구분하고, 각각에 맞는 검색어를 만든다.
단순히 사용자의 질문 전체를 그대로 검색하는 것이 아니라, 질문을 여러 개의 작은 기술적 문제로 나누는 과정이다.
검색 결과가 나왔다고 해서 바로 답변을 만들지는 않는다.
현재 확보한 매뉴얼 내용이 실제 질문에 답할 만큼 충분한지 다시 판단해야 한다.
설명이 일부만 존재하거나, 서로 다른 기능이 섞여 있거나, 현재 코드에 적용하기에 근거가 부족하다면 그대로 종료하지 않는다.
근거가 부족하다면 부족한 부분을 기준으로 다음 검색어를 만든다.
예를 들어 특정 컴포넌트의 기능 설명은 찾았지만 이벤트 처리 방식이 부족하다면, 다음 검색에서는 이벤트와 동작 방식에 집중한다.
즉, 같은 질문을 반복하는 것이 아니라 이전 검색 결과를 바탕으로 더 구체적인 다음 질문을 생성한다.
검색, 평가, 재검색 과정을 무한정 반복할 수는 없다.
따라서 근거가 충분해졌는지, 더 이상 새로운 정보가 나오지 않는지, 반복 횟수가 기준을 넘었는지 등을 판단해 종료 조건을 정해야 한다.
결국 전체 흐름은 다음과 같은 형태가 된다.
분석 대상 확인 → 궁금한 기술 요소 추출 → 매뉴얼 검색 → 근거 충분성 평가 → 부족한 내용으로 재검색 → 최종 근거 정리 → 결과 출력
이 구조가 완성되면 앨리스는 단순히 매뉴얼 내용을 한 번 찾아오는 것이 아니라, 모르는 것을 스스로 구분하고 필요한 정보가 충분해질 때까지 참고서를 다시 펼쳐보는 방식으로 동작하게 된다.
현재는 임베딩 작업이 끝나기를 기다리고 있다.
아직 실제 질의를 넣어보지 않았기 때문에 결과가 얼마나 잘 나올지는 알 수 없다.
검색 결과가 엉뚱할 수도 있고, 필요한 근거를 충분히 찾지 못할 수도 있다.
재검색어가 제대로 만들어지지 않거나, 판단 과정이 생각보다 단순하게 끝날 가능성도 있다.
그래도 일단 부족한 형태라도 결과가 출력되면 조금 뿌듯할 것 같다.
그 결과는 단순히 LLM이 만들어 낸 답변이 아니라, 앨리스가 처음으로 매뉴얼을 찾아보고 부족한 내용을 다시 확인한 뒤 만들어 낸 결과이기 때문이다.
완벽한 결과가 아니어도 괜찮다.
첫 결과를 보고 부족한 부분을 찾고, 그다음 로직을 다시 고치면 된다.
나는 단순히 “AI에게 일을 시키는 사람”이 되고 싶지는 않다.
질문을 던지고 결과만 받아보는 방식보다는, 앨리스가 어떤 자료를 보고 어떤 근거로 판단했는지 함께 이해하고 싶다.
그리고 부족한 부분이 있다면 왜 부족한지 확인하고, 그 구조를 함께 고쳐가고 싶다.
결국 내가 만들고 싶은 것은 명령을 받아 코드를 출력하는 도구가 아니다.
업무의 구조를 이해하고, 모르는 것은 참고서를 찾아보며, 판단 근거를 설명할 수 있는 실무 보조 AI에 가깝다.
아직 앨리스는 훈련생이다.
하지만 이번 단계가 제대로 동작한다면, 단순히 대화를 잘하는 AI를 넘어 실제 업무를 함께 수행하는 존재로 한 단계 성장할 수 있을 것 같다.
그리고 그 과정에서 내 생각을 확장해 주고, 막연한 아이디어를 실제 구조와 로직으로 구체화해 주는 쏘피가 곁에 있다는 것이 감사하다.
혼자였다면 “이런 기능이 있으면 좋겠다” 정도에서 끝났을 생각이, 대화를 통해 검색·평가·재검색이라는 구조로 발전했다.
다음 편에서는 실제 질의 결과를 확인하고, 출력된 답변의 품질을 더 세련되게 다듬는 과정을 기록하게 될 것 같다.
앨리스가 매뉴얼을 제대로 찾아보는지, 충분한 근거를 수집하는지, 그리고 그 근거를 실제 코드 분석과 결과물에 얼마나 잘 연결하는지가 다음 시험이다.
이제 참고서는 거의 준비되었다.
다음은 앨리스가 그 참고서를 제대로 읽는지 확인할 차례다.