안녕하세요!
패스트캠퍼스 Upstage AI Lab 5기 수강생 ‘예스잇(YES-IT)’입니다. 😊
이번 Upstage AI 부트캠프에서는 'LangChain과 RAG(Retrieval-Augmented Generation)'을 활용하여 IT 문서 기반 QA 시스템을 구축하는 프로젝트를 진행했습니다.
단순한 질의응답이 아니라, 문서 검색, 임베딩 변환, 벡터 검색, LLM 기반 응답 생성까지 전 과정을 직접 구현하며 RAG 파이프라인을 깊이 이해하는 것이 목표였어요. 특히, BM25 + FAISS 하이브리드 검색, 효율적인 문서 전처리, 프롬프트 최적화 등을 고민하며 성능 개선에 집중했습니다.
데이터를 어떻게 구조화하고 검색 성능을 높일지 여러 시행착오를 거치면서, 단순한 모델 성능 향상을 넘어 딥러닝 기반의 실제 사용자에게 도움이 되는 QA 시스템을 만드는 경험을 할 수 있었습니다.
이 과정에서 데이터 전처리의 중요성을 다시 한번 깨닫게 되었고, 검색 로직과 모델 연결 방식에 따라 답변의 정확도와 자연스러움이 크게 달라진다는 사실을 배울 수 있었습니다.
또한, 프로젝트 팀원들과 협업하며 문제 해결 방안을 모색하고 서로의 아이디어를 공유하면서, 실전 개발에서의 협업의 중요성도 깊이 느낄 수 있었습니다.
이 글에서는 프로젝트 진행 과정과 주요 기술 스택, 성과 및 인사이트를 단계별로 정리해 보겠습니다.
그럼, 저와 함께 프로젝트의 시작부터 끝까지 함께 살펴볼까요? 🚀
1. 왜 LangChain과 RAG인가? 프로젝트 개요와 목표
이번 AI 부트캠프 프로젝트를 시작할 때, 가장 먼저 고민했던 것은 "어떻게 하면 사용자 질문에 빠르고 정확하게 답변할 수 있을까?"였습니다. 기존의 단순한 키워드 검색 시스템은 검색 결과의 정확성이 떨어지고, 사용자가 원하는 맥락을 충분히 반영하지 못하는 한계가 있었습니다. 이러한 문제를 해결하기 위해, 검색과 생성의 강점을 결합한 RAG(Retrieval-Augmented Generation) 방식을 적용하는 것이었습니다.
RAG는 사용자 질문과 관련된 문서를 먼저 검색한 후, 검색된 문서를 기반으로 언어 모델이 답변을 생성합니다. 덕분에 단순한 키워드 매칭에 그치지 않고, 더 자연스럽고 정확한 답변을 얻을 수 있죠. 이러한 RAG 구조를 빠르고 효율적으로 구축하기 위해 LangChain 프레임워크를 선택했습니다. LangChain은 문서 검색, 임베딩, 벡터화, LLM 연동 등 RAG 파이프라인의 각 단계를 쉽게 연결할 수 있도록 도와줍니다. 실제로 프로젝트를 진행하면서 LangChain의 모듈화된 구조 덕분에 검색 성능 개선, 프롬프트 최적화, 웹 앱 배포 등 다양한 기능을 효율적으로 구현할 수 있었습니다.
프로젝트 주제를 선택할 때는 어떤 데이터를 사용할지에 대한 고민이 가장 컸습니다. 다양한 데이터 소스를 고려했지만, 최종적으로 IT 기술 문서를 활용하기로 결정한 이유는 몇 가지가 있습니다.
먼저, 위키독스(Wikidocs)와 같은 플랫폼은 공개된 IT 기술 문서가 잘 정리되어 있어 데이터 수집과 전처리 과정이 수월했습니다. 문서들이 챕터, 섹션, 토픽으로 구성되어 있어 문서 계층 구조를 유지하며 데이터를 수집할 수 있었던 점이 큰 장점이었습니다. 또, IT 분야에서는 사용자들이 기술 문서를 빠르게 참고하려는 수요가 높다는 점도 선택에 큰 영향을 주었습니다. 실제 사용자들이 필요로 하는 정보를 빠르게 찾을 수 있는 시스템을 만들고 싶다는 생각이 있었기 때문입니다.
프로젝트 기간과 난이도도 중요한 요소였습니다. 제한된 시간 내에 현실적인 완성도를 달성하기 위해서는 데이터의 접근성, 난이도, 그리고 구현 가능성을 고려해야 했는데, IT 기술 문서는 이러한 조건을 충족했습니다. 무엇보다, 기술 문서는 사실 기반의 정확한 정보를 담고 있기 때문에 LLM이 생성한 답변을 검증하기에도 유리하다는 점에서 최종 선택을 확정할 수 있었습니다.
특히, 검색 정확성을 높이기 위해 BM25 기반 키워드 검색과 FAISS 기반 벡터 검색을 결합한 하이브리드 검색을 도입했습니다. 키워드 중심 검색의 빠른 탐색과 벡터 검색의 문맥 이해 능력을 동시에 활용하면서, 사용자 질문에 더 적합한 문서를 찾을 수 있었어요.
이번 프로젝트의 세부 목표는 다음과 같습니다:
- IT 문서 기반 질의응답 시스템 구축: 사용자 질문에 대해 문서 검색과 언어 모델 기반 답변 생성을 결합하여 빠르고 정확한 응답을 제공
- 하이브리드 검색 시스템 구현: BM25와 FAISS를 결합해, 키워드 매칭과 문맥 기반 검색을 동시에 수행
- 효율적인 데이터 파이프라인 설계: 문서 수집 → 전처리 → 벡터화 → 검색 → 답변 생성의 흐름을 체계적으로 구축
- 사용자 친화적인 웹 인터페이스 제공: Streamlit을 이용한 웹 앱을 통해 누구나 쉽게 질의응답을 사용할 수 있도록 개발
이 프로젝트를 통해 단순히 모델을 사용하는 것을 넘어서, 검색과 생성의 유기적인 연결과 사용자 경험을 고려한 시스템 설계의 중요성을 배울 수 있었습니다.
2. 프로젝트 수행 과정: 데이터 수집부터 RAG 파이프라인 구축까지
이번 프로젝트 수행 과정은 문서 수집 → 데이터 전처리 및 벡터화 → 검색 시스템 구축 → 답변 생성 → 웹 서비스 배포의 총 5단계로 구성되었습니다. 각 단계는 사용자 질문에 대해 빠르고 정확한 답변을 제공하기 위해 체계적으로 설계되었으며, RAG 파이프라인의 전체 흐름을 이해하고 구현하는 데 중점을 두었습니다.
특히, 문서 수집 후 데이터의 청크 분할과 임베딩 생성, 하이브리드 검색 시스템 구현, 그리고 LLM을 활용한 답변 생성까지의 모든 과정이 유기적으로 연결되어야 질의응답 시스템의 품질을 높일 수 있었습니다.
이번 장에서는 다음과 같은 세 가지 주요 단계에 대해 다룹니다:
- 데이터 수집 및 저장: 신뢰할 수 있는 문서 수집과 효율적인 메타데이터 관리
- 데이터 전처리 및 벡터화: 문서 청크 분할과 임베딩 생성으로 검색 최적화
- 검색 및 RAG 파이프라인 구축: 하이브리드 검색 구현 및 LLM 기반 답변 생성
각 단계에서 어떤 고민을 했고, 어떻게 문제를 해결했는지 함께 살펴보겠습니다. 🚀
📌 데이터 수집 및 저장
질의응답 시스템을 구축하는 첫 번째 단계는 정확하고 신뢰할 수 있는 데이터를 확보하는 것이었습니다. 검색과 답변의 품질은 데이터의 질에 크게 의존하기 때문에, 저희는 프로젝트 초기 단계에서 적절한 데이터 소스 선정에 많은 시간을 투자했습니다. 다양한 옵션을 검토한 결과, IT 기술 문서가 가장 적합하다고 판단했습니다. 특히, 위키독스(Wikidocs)는 IT 관련 문서가 풍부할 뿐만 아니라, 챕터와 섹션, 토픽 등 계층 구조가 잘 정리되어 있어 데이터 수집과 전처리 과정이 용이했습니다. 이러한 구조는 문서의 맥락을 유지하는 데 매우 중요하며, 이는 이후 검색 정확도와 답변 품질을 향상시키는 데 큰 역할을 했습니다.
데이터 수집 과정에서 저희는 먼저 위키독스 웹페이지의 HTML 구조를 분석하여 콘텐츠, 코드 블록, 표 등 필요한 정보만 추출했습니다. 초기에는 크롤링 속도가 느려 상당한 시간이 소요되었지만, 불필요한 태그와 광고성 콘텐츠 제거, 요청 최적화, 병렬 처리 등을 적용하면서 속도를 개선할 수 있었습니다. 크롤링된 데이터는 JSON 형식으로 저장했으며, 각 문서는 계층적 구조를 유지하도록 설계했습니다.
수집된 데이터를 효과적으로 관리하고 빠르게 검색할 수 있도록 메타데이터 관리 시스템도 함께 구축했습니다. 데이터가 단순히 파일로만 저장되면 검색 시 시간이 오래 걸리고 문서 탐색이 어렵기 때문입니다. 이를 해결하기 위해 저희는 관계형 데이터베이스를 도입하여 문서의 구조와 내용을 체계적으로 관리했습니다. 메타데이터 관리의 주요 목적은 문서 탐색을 빠르게 하고, 검색된 콘텐츠의 출처를 명확히 하며, 문서 간의 관계를 유지하는 것이었습니다. 이를 위해 문서, 챕터, 섹션, 토픽별로 고유 식별자(ID)를 부여하고, 각 콘텐츠의 위치 정보와 내용을 함께 저장했습니다.
저희가 설계한 문서 계층 구조는 아래와 같아요. 문서(Document)가 최상위에 위치하고, 그 아래에 챕터(Chapter), 섹션(Section), 토픽(Topic), 그리고 콘텐츠(Content)가 계층적으로 연결되어 있습니다. 이러한 구조는 사용자가 특정 질문을 했을 때 관련 문맥을 빠르게 찾을 수 있도록 도와주며, 답변 생성 시 더 풍부한 정보를 제공할 수 있도록 문서 계층을 세분화 했습니다.
🗂️ 문서 계층 구조
📄 문서 (Document)
└─ 📑 챕터 (Chapter)
└─ 📂 섹션 (Section)
└─ 📋 토픽 (Topic)
└─ 📝 콘텐츠 (Content)
이 구조를 통해 해당 토픽뿐만 아니라 그와 관련된 챕터나 섹션의 정보를 함께 제공할 수 있어 더 정확한 답변을 생성할 수 있었습니다. 데이터베이스 테이블은 문서별 제목, 챕터 번호, 섹션 제목, 토픽 이름, 콘텐츠 내용을 포함하며, 각 계층 간 연결 고리를 유지했습니다. 이를 통해 문서 탐색 속도와 검색 정확도가 개선되었습니다.
이번 단계에서 중요한 교훈은 계층적 데이터 구조의 중요성이었습니다. 계층 구조가 잘 설계되어 있으면 검색 결과의 정확도와 답변의 자연스러움이 크게 향상됩니다. 또한, 메타데이터를 효율적으로 관리하면 대규모 문서에서도 빠른 검색이 가능하다는 점을 직접 경험할 수 있었습니다. 초기 크롤링 속도 문제와 불필요한 정보 제거 등 데이터 전처리 과정에서 많은 시행착오가 있었지만, 이를 통해 정제된 데이터가 얼마나 중요한지 다시 한번 깨달을 수 있었습니다.
📌 데이터 전처리 및 벡터화
데이터 수집이 완료된 후, 두 번째 단계에서는 수집한 데이터를 전처리하고 벡터화하는 작업을 진행했습니다.
이 단계는 검색의 정확도와 처리 속도에 직접적인 영향을 미치기 때문에 매우 중요한 과정입니다. 사용자 질문에 대해 관련성이 높은 문서를 빠르게 찾아내기 위해 데이터를 어떻게 처리할지에 대한 고민이 많았습니다.
📑 문서 청크 분할
먼저, 문서 청크 분할(Chunking) 작업을 수행했습니다. 일반적으로 대규모 문서를 한 번에 처리하면 임베딩 과정에서 효율성이 떨어지고, LLM이 긴 입력을 잘 처리하지 못하는 문제가 발생할 수 있습니다. 이를 해결하기 위해 문서를 일정 길이로 나누어 청크(chunk)로 만들었습니다.
저희는 다음과 같은 기준을 적용했습니다:
- 청크 크기: 1000자 단위
- 중복 길이: 200자 (문맥 유지를 위해 앞부분을 겹치게 분할)
이 방식은 문맥을 유지하면서도 모델의 입력 길이 제한을 효과적으로 관리할 수 있었습니다. 예를 들어, 한 청크의 끝부분 내용이 다음 청크의 시작 부분에 포함되도록 하여, 질문 시 모델이 문서 흐름을 자연스럽게 이해할 수 있도록 했습니다. 또한, 청크 분할 시 코드 블록이나 표 형식의 내용은 가능한 한 하나의 청크에 보존되도록 처리했습니다. 이는 코드나 표가 잘려나가면 LLM이 내용을 이해하는 데 혼란을 겪을 수 있기 때문입니다. 이 과정을 통해 LLM이 더 안정적이고 자연스러운 답변을 생성할 수 있었습니다.
📊 임베딩 생성
청크 분할이 완료된 후, 각 청크를 벡터로 변환하는 임베딩(Embedding) 작업을 진행했습니다.
벡터화된 데이터는 나중에 사용자 질문과의 유사도 계산에 사용되며, 검색 성능에 직접적인 영향을 미칩니다.
저희는 BAAI의 bge-m3 모델을 임베딩 생성에 사용했습니다. 해당 모델을 선택한 이유는:
- 다국어 지원으로 한국어 IT 문서 처리에 적합
- 문맥 파악 능력이 우수해 검색 정확도를 높이는 데 도움이 됨
- GPU 환경에서 빠른 처리 속도를 제공해 대규모 데이터 처리에 유리
임베딩 생성 과정에서 다음 사항을 고려했습니다:
- 배치 처리를 적용하여 대량의 데이터를 빠르게 처리
- 임베딩 캐싱 기능을 통해 동일한 텍스트의 중복 계산 방지
- GPU와 CPU 사용 환경에 따라 메모리 최적화 처리
처음에는 임베딩 생성 시간이 오래 걸려 고민이 많았지만, 배치 크기를 조절하고 캐시 기능을 도입하면서 처리 시간이 크게 단축되었습니다.
💡 이 단계를 통해 데이터 전처리와 벡터화 과정의 중요성을 깊이 느낄 수 있었습니다. 청크 분할 시 중복 설정은 LLM 답변의 자연스러움에 큰 영향을 미쳤으며, 코드 블록이나 표 같은 요소를 보존하니 기술 문서 기반 질의응답의 정확도와 실용성이 크게 개선되었습니다. 초기에는 청크가 잘려 모델이 내용을 잘못 이해하는 문제가 있었지만, 보존 방식을 개선한 후 더 명확하고 정확한 답변을 얻을 수 있었습니다.
또한, 임베딩 과정에서 캐시 활용과 배치 크기 조정만으로도 처리 시간과 자원 소모를 크게 줄일 수 있었습니다. 초기에는 모든 청크를 개별 임베딩해 시간이 오래 걸렸지만, 최적화 후 속도가 눈에 띄게 개선되었습니다. 특히, 임베딩 모델 선택이 검색 정확도에 큰 영향을 준다는 사실을 직접 경험하면서, 적절한 모델 선택의 중요성과 잘못된 선택 시 발생할 수 있는 재작업의 비효율성을 다시금 깨달았습니다.
📌 검색 및 RAG 파이프라인 구축
세 번째 단계는 검색 시스템 구축과 RAG 파이프라인 연결입니다. 이 단계에서는 사용자 질문을 입력받아 관련 문서를 검색하고, LLM을 통해 답변을 생성할 수 있도록 시스템을 통합했습니다.
🔎 하이브리드 검색 시스템 구현
처음에는 단순히 벡터 기반 검색만 적용했지만, 문서 내 특정 키워드가 포함되지 않으면 관련성 높은 문서가 누락되는 문제가 있었습니다. 반대로 키워드 기반 검색만 사용할 경우 문맥을 이해하지 못한 검색 결과가 출력되기도 했습니다. 이 문제를 해결하기 위해 저희는 하이브리드 검색 시스템을 구축했습니다.
- BM25 기반 키워드 검색:
- 빠른 속도로 정확한 키워드 매칭이 가능
- 사용자가 입력한 질문과 동일한 단어가 포함된 문서를 빠르게 찾을 수 있음
- FAISS 기반 벡터 검색:
- 문맥 이해와 의미 기반 검색에 강점
- 단어가 정확히 일치하지 않아도 의미가 비슷한 문서를 찾을 수 있음
두 검색 결과를 통합한 후, 가중치를 조정하여 최종 문서 목록을 생성했습니다. 이를 통해 키워드 기반의 빠른 검색과 벡터 기반의 문맥 이해라는 두 가지 장점을 동시에 활용할 수 있었습니다. 예를 들어, 사용자가 "데이터프레임 병합 방법"을 검색하면:
- BM25 검색: "병합"이라는 키워드를 포함한 문서를 빠르게 반환
- FAISS 검색: "합치기", "연결" 등 유사 의미를 포함한 문서까지 추가로 찾아줌
- 최종 결과: 두 검색 결과를 결합하여 가장 관련성이 높은 문서를 상위에 배치
🤖 LLM 기반 답변 생성 및 프롬프트 설계
검색된 문서 청크는 LLM에 전달되어 최종 답변을 생성합니다. 이때 단순히 문서를 입력하는 것만으로는 좋은 답변을 얻기 어려웠기 때문에, 프롬프트 최적화에 많은 시간을 투자했습니다. 프롬프트 구성 시 고려한 요소:
- 사용자 질문을 명확히 전달
- 검색된 문서 내용을 요약 및 강조
- 모델이 불필요한 정보를 혼동하지 않도록 지시문 추가
저희는 Solar API 기반의 KULLM-5.8B 모델을 메인 LLM으로 사용했으며,
- 일반 질의응답에는 KULLM-5.8B를 사용
- 코드나 수식 관련 질문에는 보조 모델인 polyglot-ko-1.3b를 활용
또한, 멀티턴 대화 기능을 추가해 사용자와의 대화 맥락을 유지할 수 있도록 했습니다. 사용자가 연속된 질문을 할 때, 이전 질문과 답변을 참조하여 더 자연스러운 응답을 생성할 수 있었습니다.
💡 이 단계를 통해 검색 시스템과 답변 생성 과정에서 다양한 인사이트를 얻을 수 있었습니다. 먼저, 하이브리드 검색 시스템(BM25 + FAISS)을 도입하면서 검색 정확도와 문맥 이해도가 눈에 띄게 향상되었습니다. 단순히 키워드 기반이나 벡터 기반 검색만 사용했을 때보다, 두 방식을 결합했을 때 사용자 질문에 더 적합한 문서를 빠르고 정확하게 찾을 수 있었던 것이 인상적이었습니다.
또한, 프롬프트 설계의 중요성을 다시 한번 깨달았습니다. 아무리 강력한 언어 모델을 사용하더라도, 프롬프트가 잘못 구성되면 모델의 성능을 제대로 끌어내지 못한다는 점을 경험했습니다. 여러 차례 실험을 통해 질문 전달 방식, 문맥 강조 방법, 지시문의 구체성 등이 답변 품질에 큰 영향을 미친다는 사실을 확인할 수 있었습니다.
마지막으로, 대화 컨텍스트 유지 기능이 사용자 경험(UX)을 크게 개선한다는 점도 배울 수 있었습니다. 사용자가 연속적인 질문을 할 때, 이전 대화 내용을 기억하고 답변하니 질의응답의 흐름이 자연스러워지고, 사용자 만족도가 높아졌습니다. 이러한 기능은 특히 실전에서 사용될 때 더 자연스럽고 몰입감 있는 대화형 시스템 구현에 필수적임을 깨달았습니다.
3. 최종 QA 시스템 구현 및 Streamlit 웹 서비스 배포
이번 단계에서는 모듈을 통합하여 QA 시스템을 완성하고, Streamlit을 활용해 사용자 인터페이스(UI)를 구축했습니다. 목표는 사용자가 질의를 입력하면 검색 → 답변 생성 → 출력까지의 흐름을 원활하게 만드는 것이었으며, 로컬 환경에서 시스템 검증을 통해 실제 사용자 경험을 확인했습니다.
프로젝트 일정이 약 3.5일로 매우 촉박했기 때문에, 응답의 정확성과 자연스러움을 충분히 개선할 시간은 부족했습니다. 배포까지 진행하는 것이 목표였으나, 시간 제약으로 인해 로컬에서 확인과 검증 단계까지만 완료할 수 있었습니다.
📌 QA 시스템 구축: 모듈 통합과 질의응답 구현
검색, LLM 응답 생성, 메모리 모듈을 통합하여 최종 질의응답 시스템을 완성했습니다. 사용자 입력을 받아 하이브리드 검색 시스템을 통해 관련 문서를 찾고, 프롬프트를 구성해 LLM에 전달한 후 답변을 생성하는 과정입니다.
처음에는 모듈 간 데이터 전달 문제와 대화 컨텍스트 미반영 문제가 발생했지만, 검색 결과 예외 처리와 메모리 참조 로직 수정으로 해결할 수 있었습니다. 다만, 응답의 자연스러움과 정확도를 높이기 위한 추가적인 프롬프트 최적화와 모델 튜닝을 적용할 시간은 부족했습니다. 짧은 기간 동안 최대한 빠르게 동작하는 시스템을 구현하는 데 집중했으며, 연속 질의 시 대화 맥락 유지 기능이 기본적으로 잘 작동하는 것을 확인할 수 있었습니다.
📌 Streamlit을 이용한 웹 UI 구현 및 로컬 검증
사용자 친화적인 인터페이스 제공을 위해 Streamlit으로 웹 UI를 구성했습니다. 인터페이스는 질문 입력창, 로딩 상태 표시, 답변 출력 영역으로 구성되었으며, 사용자가 질문하면 검색 및 답변 생성 과정을 실시간으로 확인할 수 있었습니다.
시간 제약으로 인해 실제 웹 배포는 진행하지 못했고, 로컬 환경에서 시스템 검증과 사용자 흐름 테스트만 완료할 수 있었습니다. 로컬에서 테스트한 결과, 질문에 대한 응답이 빠르게 생성되며 기본적인 기능은 정상 작동했습니다. 다만, 모델 출력의 품질을 더 개선할 필요성은 확인할 수 있었습니다.
4. 프로젝트 수행 중 트러블슈팅
AI 부트캠프 프로젝트를 진행하면서 여러 문제와 예상치 못한 상황들을 마주했지만, 짧은 일정 속에서도 문제 해결에 집중하며 최종 시스템을 완성할 수 있었습니다. 각 단계에서 발생한 문제들은 검색 속도 저하, 데이터 전달 오류, 메모리 과부하 등이 있었으며, 시간 부족으로 인한 일부 기능 최적화 미완성 문제도 있었습니다.
먼저, 검색 속도 문제는 프로젝트 초기부터 가장 큰 과제 중 하나였습니다. 벡터 검색 시 시간이 오래 걸려 사용자 질의 후 응답 지연 현상이 발생했습니다. 이를 해결하기 위해 임베딩 캐시를 적용하고 검색 결과 필터링 로직을 최적화하여 속도를 개선할 수 있었습니다. 캐시 도입 전에는 동일한 쿼리 실행 시 매번 임베딩을 새로 계산해야 했지만, 이후에는 반복 쿼리에서 즉각적인 결과를 얻을 수 있었습니다.
또한, 모듈 통합 과정에서 데이터 전달 오류가 발생해 검색 결과가 LLM에 정상적으로 전달되지 않는 문제가 있었습니다. 이는 모듈 간 데이터 포맷 불일치가 원인이었고, 데이터 구조를 일관되게 유지하고 예외 처리를 추가하여 해결했습니다.
Streamlit을 통한 로컬 검증 단계에서는 대규모 문서 처리 시 메모리 과부하 문제가 나타나 실행이 중단되는 경우가 있었습니다. 이를 완화하기 위해 청크 크기를 조정하고 모델 호출을 최소화하는 방식으로 메모리 사용을 최적화했습니다.
가장 큰 아쉬움은 응답의 자연스러움과 정확성을 충분히 개선할 시간적 여유가 없었다는 점입니다. 프로젝트 기간이 약 3.5일로 매우 촉박했기 때문에 프롬프트 최적화나 모델 파인튜닝과 같은 세부 조정에는 충분한 시간을 할애하지 못했습니다.
이러한 문제 해결 과정에서 빠르게 우선순위를 설정하고 현실적인 해결책을 적용하는 것이 중요하다는 점을 배울 수 있었습니다. 시간이 한정된 상황에서도 기본 기능이 안정적으로 작동하는 시스템 구축을 우선시했던 결정이 프로젝트 완성할 수 있었던 것 같아요. 이를 통해, 딥러닝 기반의 시스템을 통합하는 과정에서 발생할 수 있는 실전 문제 해결 능력을 키울 수 있었습니다.
5. 결과 및 향후 개선 방향
✅ 프로젝트 성과 및 주요 인사이트
AI 부트캠프 프로젝트의 일환으로 진행된 이번 Langchain 프로젝트에서 약 3.5일이라는 짧은 기간 동안 IT 문서 기반의 RAG 시스템을 직접 구현할 수 있었습니다. 제한된 시간과 자원 속에서도 문서 검색, 임베딩, 벡터 검색, LLM 기반 응답 생성까지의 전체 파이프라인을 완성하고, Streamlit을 이용한 웹 인터페이스로 로컬 검증까지 진행할 수 있었던 점은 큰 성과였습니다.
가장 인상 깊었던 부분은 검색과 생성의 결합(RAG) 구조를 직접 구현하면서 데이터 처리와 모델 연동의 중요성을 몸소 체감할 수 있었다는 점입니다. 특히, 청크 분할 방식과 검색 성능 개선이 답변의 질에 얼마나 큰 영향을 미치는지 실험을 통해 확인할 수 있었습니다. 또한, 대화 컨텍스트 유지 기능을 적용하면서 멀티턴 대화의 자연스러움과 사용자 경험이 크게 향상될 수 있음을 경험했습니다.
🚀 한계점 및 향후 개선 사항
짧은 프로젝트 기간으로 인해 모델 성능 개선과 세부 기능 최적화에는 충분한 시간이 부족했던 것이 가장 큰 한계였습니다. 특히, 응답의 자연스러움과 정확도를 높이기 위한 프롬프트 최적화와 모델 튜닝을 충분히 진행하지 못했습니다. 이 부분은 향후 시간을 확보해 우선적으로 개선해야 할 과제입니다.
또한, 웹 배포까지 완료하지 못한 점도 아쉬움으로 남습니다. 로컬 환경에서만 검증이 가능했기 때문에 실제 사용자 피드백을 받아 시스템을 개선할 기회가 제한적이었습니다. 향후에는 Streamlit을 통한 배포를 완료하고, 실사용자 피드백을 통해 응답 품질과 UX를 지속적으로 개선할 예정입니다.
멀티턴 대화 기능 강화도 중요한 개선 사항 중 하나입니다. 현재는 기본적인 대화 흐름 유지만 가능하지만, 더 자연스러운 대화 전환과 긴 대화 시에도 안정적인 컨텍스트 유지 기능을 추가로 구현할 필요가 있습니다.
마지막으로, 이번 시스템을 다양한 문서 도메인으로 확장해 다양한 분야의 질의응답 시스템으로 활용할 수 있는 가능성도 모색할 계획입니다.
🏆 최종 마무리
짧은 시간 동안 RAG 기반의 질의응답 시스템을 직접 구축하며 데이터 처리, 검색 최적화, 모델 연동 등 전반적인 과정을 경험할 수 있었던 점이 큰 수확이었습니다. 시간 부족과 배포 미완성이라는 아쉬움은 있었지만, 로컬 환경에서 동작하는 시스템을 완성하고 검증한 것만으로도 의미 있는 결과였습니다.
향후에는 모델 성능 개선, 웹 배포, 사용자 피드백 반영을 통해 더 완성도 높은 시스템으로 발전시킬 계획입니다. 이 경험을 통해 현실적인 일정 속에서 핵심 기능을 빠르게 구현하는 중요성과 딥러닝 기반 시스템 통합 과정에서의 문제 해결 능력을 크게 향상시킬 수 있었습니다. 🚀
'YES - 개발일지' 카테고리의 다른 글
| [Upstage AI Lab 5기 부트캠프] Information Retrieval 경진대회 ─ 정보 검색부터 RAG까지의 실전 경험기 (0) | 2025.03.14 |
|---|---|
| Data-Centric AI란? ─ Upstage AI Lab 22주차 (1) | 2025.02.28 |
| [Upstage AI Lab 5기 부트캠프] NLP 경진대회 (1) | 2025.02.02 |
| [Upstage AI Lab 5기 부트캠프] 문서 타입 분류 CV 경진대회에서 1위 도전 (1) | 2025.01.02 |
| 딥러닝과 파이토치: 기초부터 실전까지 ─ Upstage AI Lab 12주차 (2) | 2024.12.18 |
댓글