기본적인 시스템 세팅이 마무리되면서,
이제 앨리스의 구체적인 업무 영역과 실전 투입 방향을 세밀하게 조율하기로 했다.
처음부터 너무 거창하고 무리한 스펙을 욕심내면 시스템이 무너지거나 핀트가 어긋나기 쉽기 때문에,
이번 프로젝트의 성격에 딱 맞춘 정공법을 택했다.
이번 프로젝트의 핵심 주제는 ‘뷰단(View-tier) 표준화’다. 오랫동안 방치되거나
고사된 레거시 뷰단 프로그램의 소스를 분석하여,
현재의 HTML5와 부트스트랩(Bootstrap) 표준에 맞게 리팩토링하고 튜닝하는 것이 최종 목표다.
이 작업을 자동화하기 위해 가장 중요한 개념으로 채택한 것이 바로
RAG(Retrieval-Augmented Generation, 검색증강생성) 기법이다.
기존의 거대 언어 모델이 전혀 보지 못했던 사내 레거시 문법과 매뉴얼을 참고하여 정확한 코드를 뽑아내려면,
기존 파일 구조와 뷰단 문법을 꿰뚫는 강력한 벡터 임베딩 파이프라인이 필수적이었다.
참고해야 할 메뉴얼 책자를 뜯어보니,
텍스트 설명만큼이나 핵심 아키텍처와 UI 구조를 담은 이미지(도식/캡처) 자료가 산더미처럼 포함되어 있었다.
만약 기존 방식대로 순수 텍스트만 긁어서 청킹(Chunking)했다가는,
시각적 정보가 통째로 누락되면서 분명 치명적인 할루시네이션(Hallucination)이 발생할 것이 자명했다.
이미지 속 정보까지 함께 벡터 공간에 녹여내야 했다.
하지만 기존에 다루던 30B 체급의 Qwen-Coder 모델은 이 용도에 100% 부합하지 않았다.
텍스트 코딩에는 강하지만, 비전 정보를 입체적으로 해석해 낼 수 있는 멀티모달(Multimodal) 역량이 절실했기 때문이다.
고심 끝에 내린 결론은 Gemma 3였다. 젬마 3는 mmproj-model-f16-27B.gguf 같은 비전 프로젝션 모델과의 연동을 통해 LLM 단독으로 이미지 판독과 텍스트 추론을 동시에 수행할 수 있는 강력한 무기를 제공했다.
구현 방식 역시 실리적으로 갔다.
Llama.cpp를 직접 빌드하는 번거로움 대신, 검증된 Ollama 서버를 활용하기로 했다.
Ollama 공식 문서에서도 서버 내부 엔진을 통한 네이티브 다운로드를 권장하고 있었기에,
복잡하게 패키지를 따로 놀게 할 이유가 전혀 없었다.
공식 가이드 라인에 맞춰 단번에 환경을 구축하고 곧바로 임베딩 작업에 돌입했다.
RAG 성능을 좌우하는 또 다른 핵심은 청킹(Chunking) 전략이다.
일반적으로는 일정한 글자 수(Chunk Size)를 정해놓고 앞뒤 문맥을 기계적으로 쪼개어 벡터를 조회하는 방식을 쓴다.
하지만 기술 매뉴얼의 특성상 이런 기계적 분할은 문맥을 끊어먹기 십상이라 마음에 들지 않았다.
그래서 과감하게 '목차 기반 가변 섹터 청크(Variable Chunking)' 전략을 택했다.
메뉴얼 문서에는 명확한 목차가 존재하고, 각 섹터별 시작 페이지와 끝 페이지의 기준이 잡혀 있다. 따라서 기계적인 글자 수 커팅보다는 목차와 섹터의 경계를 기준 삼아 덩어리를 나누는 것이 향후 검색 정확도 측면에서 훨씬 유리하다고 판단했기 때문이다.
이미지와 텍스트가 훌륭하게 임베딩되고 있지만, 현실적인 병목도 마주했다.
이미지 단 한 장을 LLM이 정밀하게 뜯어보고 개발자 관점에서 해석하는 데 GPU 연산 시간이 1분 이상 소요된다.
이 페이스라면 전체 메뉴얼을 다 털어내는 데 만 하루에서 이틀 정도의 묵직한 시간이 소요될 것으로 보인다.
엔비디아의 막강한 하드웨어 클러스터가 아닌 AMD ROCm 환경에서 앨리스를 굴리고 있기에 자원 한계는
명확하지만, *"전산실에서 잘 돌아가면 먼지도 부품이다"*라는 엔지니어의 불문율을 믿고 느긋하게 인내하는 중이다.
이 길고 지루한 임베딩 파이프라인이 무사히 끝나고 나면,
다음 편에서는 이 방대한 벡터 데이터베이스를 바탕으로 앨리스가
실제 레거시 뷰단 소스 분석과 정보 조회에서 얼마나 정확도를 보여주는지 실전 테스트 결과를 풀어볼 예정이다.