복지드림 - RAG 구현 하네스 엔지니어링 기반 다지기

이번 프로젝트의 목표: 직접 코딩하지 않고 하네스 엔지니어링을 통해 바이브 코딩, 자동 검증을 통해 RAG를 구현하며 그 과정에서 얻은 AI 사용 스킬 및 기본 개념 정리

 

이번 종프에서 급하게 주제를 바꾸게 되었다.(Surfit은 다음에 따로 하는 걸로 ㅎ)

 

멘토님과 미팅을 해본 결과 이전 주제 기술적 깊이가 지금 AI 시대에 아쉬운 기술 스택이었다는 것이다. 우리가 그저 기본기를 배우기 위해 고안안 주제여서 맞는 말이었다. 멘토님은 지금 클로드 코드를 사용하여 최고의 아웃풋을 뽑는 것이 중요하다고 하셨다. 또한 여러 AI 기술들을 프로젝트에 넣는 것도(멀티 에이전트, 로컬 LLM, 하네스 엔지니어링 등) 그래서 멘토님의 말씀에 따라서 프로젝트의 수준을 올리기 위해 주제를 재선정하였다.

 

우리가 재선정한 주제는 취약 계층을 위한 복지 서비스 자가진단 AI 에이전트였다. 기본적으로 취약 계층이 자신이 어떤 혜택을 받을 수 있는지 조차 모른 채 그냥 지내는 분들이 많다고 생각했기 때문이다. 그래서 간단한 채팅 형태를 통해(나중에 음성 기능 추가?) 자신이 받을 수 있는 복지 서비스를 정리해주고, 이를 신청하기 쉽도록 가이드를 제공해주는 에이전트를 고안하였다. 이 과정에서 사용자에게 맞는 복지 서비스 안내, 가이드, 초안 작성, 리포트 작성 등 서비스를 멀티 에이전트를 도입하여 제공해줄 계획이다. 추가로 사용자의 개인정보 보호를 위한 로컬 LLM, 정확한 복지 서비스 제공을 위한 RAG 등을 사용할 계획을 구상하였다.

 

또한 멘토님의 말씀이 지금 기본기는 당연한 가져야하고, 이제부터는 AI를 최대한 활용해보는 경험과 능력이 중요하다고 하셨다. 바이브 코딩을 이번 프로젝트에 적극 활용하고 하네스 엔지니어링도 적용해보라고 하셨다. 원래 종프에서 기본기를 쌓을 생각이었는데 주제를 변경하면서 최대한 바이브 코딩으로 좋은 산출물을 내는데 힘 써봐야겠다고 생각했다. 기본기는 따로 공부하는 걸로!!

 

나도 느끼는게 AI를 잘 활용하려면 기본기는 뒷받쳐져야 하는 거 같다. 약간 군대에서 소대장이라고 주특기 못 하면 안 되는 그런 느낌? AI가 뭘 하는지 파악을 할 수 있고, 또한 어떤 부분을 잘못 진행하고 있는지 파악 할 수 있는 능력은 여전히 필요할 거 같다. 그러나 이 기본기와 AI 활용 능력이 양자택일의 문제가 아니고 둘다 함유하는 것이 앞으로의 개발자가 가져야할 방향인 듯하다. 

 

그래서 이왕 바이브 코딩으로 진행할 거면 시대의 흐름에 맞는 방식으로 해보고 싶다.

 

하네스 엔지니어링

 

멘토님에게 하네스 엔지니어링을 사용해서 해보라는 말씀을 듣고 저번에 유튜브에서 그냥 넘겼던 하네스 엔지니어링 영상이 생각나서 봐보았다. 이젠 그저 프롬프팅으로 AI에게 명령하는 것이 아니라 AI가 안 지키면 안 되는 법규들을 만들어 AI가 해당 제약 조건 안에서 움직이도록 하는 것이다. 하네스 엔지니어링은 이처럼 AI에게 하네스(마구)를 달아 통제한다는 말이다. 우리가 개입 안 하고 알아서 조절하게 해서 인간 병목 없애는 게 포인트 ㅎ

 

이를 보고 유명하다던 하네스 엔지니어링 ECC(everything-claude-code) 레포를 봐보았다. 그런데 요건 엄청난 거 같긴 하지만 에이전트가 뭐 몇 개라 했더라? 36개인가? 엄청 많고 기능이 많아서 내 프로젝트에 적용하기엔 배보다 배꼽이 더 커지는 거 같았다(오버 엔지니어링). 그래서 저 ECC를 들고 바로 내 프로젝트에 적용하기보다, 내 프로젝트 규모에 맞게 적용하며 이해할 수 있는 좀 더 간단한 하네스 엔지니어링을 구성해볼 수 있도록 다른 것을 찾아보았다.

 

그래서 유튜브 하네스 엔지니어링 영상을 하나 보고 하네스를 만들어서 시작해보았다.

https://youtu.be/AQOvNx87Urs?si=Xbmpx-XYagi2bb9x

 

보니까 하네스 엔지어링 자체가 지금 내 역할 부분에 쓰기에 살짝 오바인 거 같기는 한데 공부할 겸 해보는 것도 좋겠죠^^ 그리고 이 영상에서 wispr flow라고 음성 -> 텍스트 변환 쓰는 거 보고 써봤는데 리얼 맛도리더라구요^^ 다들 써보세요

 

핵심은 프로젝트 개발을 step 별로 분류해서 먼저 문서화를 해놓고 이를 클로드가 하나씩 실행하며 도메인 개발을 진행하는 것이다. 클로드가 진행할 step을 정의, 다른 규칙들 또한 문서화해놓고 실행을 하면 클로드가 정의된 규칙들을 지켜가며 코드 작성 및 자가 수정을 통해 개발이 진행된다는 것이다.

 

암튼 프로젝트 내용으로 먼저 가봅시다.

클로드가 만들어준 초기 아키택쳐 구조

 

위의 아키택쳐 구조를 만들기 위해서 역할 분담을 진행하였고, 나는 RAG 구축을 담당하기로 하였다. 랭그래프와의 API 통신을 통해서 사용자에게 적절한 복지 서비스를 검색해서 반환해주어야 할 듯하다.

 

RAG(Retrieval-Augmented Generation)

 

뭔지 간단하게 비유를 하자면?

사람(LLM)이 시험을 치르는데 시험지(사용자의 요청)에 있는 답란에 자기가 생각해서 맞다고 하는 걸 그냥 적는 것이 아니라 옆에 있는 오픈북(RAG)를 참고하여 정확한 답을 시험지에 적는 것이라고 보면 될 거 같다.

 

최신 정보를 학습하지 못하였을 때 RAG를 가지고 최신성을 확보하는 것도 많지만 우리 프로젝트에서는 정확성 확보에 좀 더 중점을 뒀다고 볼 수 있겠다. 구체적인 문서 내용까지 LLM이 확실하게 아는 것이 아닐 수 있으니 말이다. 따라서 나는 이 정확한 오픈북 RAG를 만드는 것이 이번 프로젝트에서의 역할이다. 

 

바이브 코딩으로 구현한다고 해도 내가 신경써야할 요소들이 몇 가지 있다.

 

1. 청킹

 

데이터를 자르는 단위.

ChromaDB에 저장을 하는 단위인데 이를 적절한 단위로 선정해야 정확하면서 효율적으로 답변을 할 수 있는 거 같다. 너무 크면 비효율적이고 너무 작으면 맥락 손실(오버헤드 발생 같은 느낌? 오버랩 있잖아). 운영체제 프로세스 스케줄링에서 타임 슬라이스를 적절히 정하는 것처럼 여기서도 청크의 크기를 적절히 정해야하는 듯하다.

초기 청크 크기

밑에 청크 오버랩은 뭐 종이를 붙인다고 하면, 두 종이를 이으려고 풀을 바르는데 풀 바르는 겹치는 부위를 몇 퍼센트로 할지 같은 느낌? 일반적으로 20%정도가 권장 사항이라고 해서, 우리 프로젝트에서 20%로 진행할 것이다. 

 

2. 임베딩 모델

 

자른 청크를 유사도 검색이 가능하도록 백터 변환. 의미가 비슷한 문장이 비슷한 백터 공간에 위치하도록 하는 것이다.

우선 우리 프로젝트에서는 한국어에 특화된 소버린 AI [jhgan/ko-sroberta-multitask] 모델이 있다고 해서 우선 이 모델을 사용해볼 예정이다. 높은 한국어 정확도와 보안상 우리 로컬에서 독립적으로 구동할 수 있기에. 청크 크기를 클로드가 1000으로 설정 해놓았던데, 이 모델의 최대 청크 크기가 512 토큰이라고 해서 한국어 기준으로 우선 250자 정도로 수정하였다. 최악의 경우(들어오는 한글이 다 2.5 토큰)를 고려하면 180자 정도가 맞지만, 너무 청크가 작으면 맥락이 줄어들어 답변 품질이 떨어질 수 있으니 우선 250자로 설정을 했다. 이 부분에서는 worst case를 너무 고려하기보다는 해보고 문제가 생기면 조정하는 방식이 더 합리적일 거 같다는 생각이다. 오버랩도 있고 하니까 문제가 없지 않을까 싶다.

 

3. 검색(Retrieval)

 

ChromaDB에 저장되는 형식은 아래와 같다.

구성요소	설명
id	청크 고유 식별자
document	임베딩 대상 텍스트(청크값, 250자, 후에 디버깅 용 등)
embedding	document를 백터화한 숫자 배열(검색에 사용)
metadata	해당하는 복지 서비스의 원본 데이터(응답용)

 

검색을 할 때 사용자의 쿼리 텍스트와 embedding에 대한 유사도 검색을 통해 해당하는 청크를 찾고 metadata를 반환하는 것이다. 메타데이터는 한 복지 서비스에 해당하는 여러 청크들이 있어도 한 메타데이터를 참조하는 것(JOIN 해서)은 아니고 성능을 위해 각 청크마다 복사된 메타데이터를 가지고 있는게 권장된다고. 성능 위해 반정규화 같은 느낌

 

띠리사 위의 것들을 고려하며 내가 해야할 것들이

 

1. 랭그래프 쪽에서 JSON으로 사용자 데이터 받기

2. 쿼리 텍스트로 변환

3. 임베딩 모델로 쿼리를 백터 변환(임베딩)

4. 해당 백터를 ChromaDB에 검색(Retrieval), 유사도 검색

5. 가장 가까운 청크 k개 반환

6. metadata를 랭그래프에 JSON으로 반환

 

그래서 지금까지는 하네스 엔지니어링 구조 확립을 위해 step 설계 및 문서화를 하였는데, 어떻게 정의하였는지 봐봅시다.

Step	내용
0-project-setup	프로젝트 뼈대 구성(디렉토리, 패키지, 설정 파일 등)
1-models	복지 서비스 데이터 모델 정의(WelfareRaw, SearchResult 등)
2-db-layer	ChromaDB 클라이언트 초기화 및 컬렉션 관리
3-embedding-layer	한국어 임베딩 모델 연동
4-crawler	공공데이터 API로 복지 서비스 데이터 수집
5-pipeline	수집 데이터 청킹 -> 임베딩 -> ChromaDB 저장
6-retriever	사용자 쿼리 백터화 -> ChromaDB 유사도 검색 -> 결과 반환
7-api-layer	랭그래프와 통신하는 FastAPI 엔드포인트 구성

 

현재 위처럼 스탭 설계 및 문서화를 완료하였다. 다음 글에서는 하네스 엔지니어링 자동화를 실행하고 클로드가 각 스탭을 구현하고 자가 검증하는 과정을 공유해보겠습니다 + API 협의 내용