🔗 전체 프로젝트 wiki

목차

1. 운세 기능
2. 댓글 기능
3. 뱃지 기능
4. 챗봇 기능

기능 별 상세 설명

💫 운세 기능

1. 개발 목적

• 가벼운 진입 장벽: 누구나 즐길 수 있는 가벼운 콘텐츠로 가볍게 터치 하고 자연스럽게 서비스를 탐색하도록 돕습니다.
• 공감대 형성 : 단순한 운세가 아닌, 각 과정별 맞춤 운세를 제공하여 사용자에게 더욱 친근한 느낌으로 다가오도록 합니다.
• 재방문 유도 : 매일 바뀌는 운세를 통해 사용자의 재방문을 유도할 수 있습니다.

2. 모델 선정

평가 기준

중요 순위	평가 항목	설명
1	⚡ 응답 속도(시간)	특히 운세는 실시간성이 중요 → 빠르게 응답되는지
2	🧠 성능	문장 품질, 감성 표현력, 문맥 이해력
3	🎯 목적 적합성	- 한글 잘 되는지 + 운세의 텍스트 길이가 잘 맞는지
4	💸 경량화	Colab, CPU 환경에서 잘 돌아가는지 / API 비용은 적은지
5	🔥 트렌드 성	현재 많이 사용되고, 커뮤니티/지원이 활발한 모델인지
6	🛠 파인튜닝 용이성	LoRA, Unsloth, PEFT 등으로 커스터마이징 가능 여부

모델 선정 과정

모델명	출력 문장 품질	실질 조언력 🎯	표현 오류 ⚠️	응답 속도 ⏱️	GPU 사용량 (GB)	운세 생성 적합성
Mistral-7B-Instruct-v0.3	✅ 매우 좋음	✅ 학습/문제 해결 균형 있게 제시	❌ 없음	7초	14.0	🟢 매우 적합
KORani-v3-13B	✅ 좋음	✅ 실제 업무 상황을 반영한 현실적 조언	❌ 없음	46초	39.9	🟡 적합 (자원 많이 씀)
Gukbap-Mistral-7B	❌ 중복/불완전	⚠️ 표현 반복과 일관성 부족	✅ 있음	40초	27.9	🔴 부적합
Eximius_Persona_5B-GGUF	✅ 감성 우수	✅ 감정 표현 풍부, 창의적 조언 제공	⚠️ 영어 혼용	38초	39.3	🟢 감성 운세에 적합
Meta-LLaMA-3-8B-Instruct	✅ 구조 매우 좋음	✅ 형식화된 JSON 운세, 명확한 어투	❌ 없음	1분	39.3	🟢 영어 운세에 최적
Gemma 3 1B Instruct	✅ 매우 좋음	✅ 코드/배포/협업 항목별 구체적 조언 제시	❌ 없음	9초	2.2	🟢 매우 적합
TinyLlama-1.1B-Chat	✅ 짧고 명확함	⚠️ 입력된 프롬프트의 예시를 그대로 출력함	❌ 없음	5초	7.4	🟢 적합 (가볍고 빠름)
HyperCLOVAX-SEED-Text-Instruct-1.5B	✅ 문장 구성 매우 안정적	✅ 운세 출력 + 공손한 표현 훌륭	❌ 없음	6초	8	🟢 매우 적합

최종 모델: 빠른 응답속도와 안정적인 출력을 고려하여 HyperCLOVAX로 선정됨.

3. 주요 이슈

• 사용자 요구 사항: 최대한 빠른 응답 요구

이슈	설명	해결 방법	결과
JSON 형식 반환 실패	모델이 JSON 형식이 아닌 일반 문장, 마크다운, 스키마 설명 등을 반환함	정규표현식 ({[\s\S]*?})으로 마지막 JSON 블록만 추출 후 json.loads() 파싱. 예외 발생 시 HTTPException으로 안전 처리. JsonOutputParser로 구조 강제화	구조 일치 실패 문제 해결, fallback 로직으로 JSON 파싱 성공률 증가
성능(속도) 관련	사용자가 최대한 빠른 응답을 요구했으나, 초기 GPU 환경에서도 응답 시간이 9초 이상 발생	- max_new_tokens 축소- 프롬프트 최소화- sampling 파라미터 튜닝 (temperature, top_p)- FP16 추론 적용 (torch_dtype=torch.float16)- 프롬프트 제외 디코딩 (gen_ids 추출)- torch.inference_mode()로 gradient 계산 제거- 토크나이저/모델 캐시 재사용- 랜덤 노이즈 삽입으로 응답 다양성 확보	평균 응답 시간 9초 → 1.3초로 약 85.6% 속도 개선
프롬프트 생성 + 노이즈 추가	nickname, course, date를 기반으로 생성한 프롬프트로 인해 응답이 지나치게 동일하거나 반복되는 현상 발생	프롬프트 생성 후 <--retry_seed=...--> 형식의 난수 기반 노이즈를 프롬프트에 삽입하여 모델 응답 다양성 확보	모델의 반복 응답 현상 감소, 사용자 맞춤 응답 다양화 달성

4. 결과 및 회고

a. 결과

L4 GPU 기준 평균 추론 속도 1.2~1.3초	실제 화면

b. 회고

회고

KPT 분류	설명
Keep (유지할 항목)	• 기능별 책임 구분이 잘 되어 있어 병렬 작업과 코드 정리가 수월했음. • 빠르게 MVP를 완성하고, 이후 모델 속도 및 응답 품질 개선을 지속한 점이 좋았음.
Problem (문제점)	• 모델이 간헐적으로 JSON 형식으로 응답하지 않는 이슈가 있어, 기능 테스트를 반복적으로 수동으로 수행해야 했던 점이 번거로웠음. • 초기 파일 구조는 설정했지만, 각 파일에 어떤 내용을 작성해야 하는지 명확한 가이드가 없어 코드가 특정 파일에 몰리거나 일관성이 떨어졌고, 이후 리팩토링에 시간이 소요됨. • 기능이 잘 작동하는지에 대한 직관은 있었지만, 객관적으로 성능을 판단할 수 있는 명확한 기준이나 지표가 부족했음.
Try (시도할 것)	• 자동 테스트 기능을 도입하여, 주요 API에 대해 FastAPI 기반 자동화 테스트 코드 작성하기. • 작업 기록, 에러 대응법, 디렉터리 구조, API 명세 등을 문서화하여 팀원 온보딩과 리뷰를 원활하게 하기. • 정답이 포함된 Top-5 기준 평가 방식 도입: 사전 정의된 질문 세트와 정답 리스트를 기반으로, 정답이 Top-5 안에 포함되면 100점, 없으면 0점 → 평균 점수로 성능 측정. • (향후) 성능 로그를 MongoDB에 자동 기록하고, 대시보드로 시각화하여 성능 비교 가능하도록 개선하기.

🗣️ 댓글 기능

1. 개발 목적

• 사용자간 교류 유도 : 서로의 프로젝트에 반응하고 관심을 주는 문화를 만듭니다.
• 댓글 작성의 예시 제공 : AI가 각 프로젝트 마다 댓글을 달아주어 각 프로젝트에 대한 댓글 예시를 제공하게 되며, 댓글 작성에 부담을 낮춰줍니다.
• 피드백 기반의 성장 유도 : 각 팀의 아이디어, 기능을 기반으로한 댓글을 통해 개발자가 성장할 수 있는 환경을 제공합니다.

2. 모델 선정

평가 기준

중요 순위	평가 항목	설명
1	🧠 성능	문장 품질, 감성 표현력, 문맥 이해력
2	🎯 목적 적합성	- 한글 잘 되는지 + 각 팀의 정보를 보고 알맞은 댓글을 생성할 수 있는지의 여부
3	💸 경량화	Colab, CPU 환경에서 잘 돌아가는지 / API 비용은 적은지
4	🔥 트렌드 성	현재 많이 사용되고, 커뮤니티/지원이 활발한 모델인지
5	⚡ 응답 속도(시간)	댓글 기능은 최대한 느리게 달릴 수록 좋음.

모델 선정 과정

모델명	출력 문장 품질	실질 조언력 🎯	표현 오류 ⚠️	응답 속도 ⏱️	GPU 사용량 (GB)	댓글 생성 적합성
Mistral-7B-Instruct-v0.3	⚠️ 반복 있음	칭찬 + 기술 언급 그러나 감성 부족	✅ 반복 표현 있음	10초	27.8	🟡 중간
Gukbap-Mistral-7B	⚠️ 반복 있음	✅ 진심 어린 칭찬 + 기술 언급 자연스러움	✅ 반복 표현 있음	10초	28.1	🟢 매우 적합
TinyLlama-1.1B-Chat-v1.0	❌ 템플릿 출력	⚠️ 새 유형 요청만 반복 출력됨	❌ 없음	6초	7.4	🔴 부적합
Meta-LLaMA-3-8B-Instruct (GGUF)	✅ 매우 좋음	✅ 진정성 + 구조적 설명 잘 어울림	❌ 없음	46초	0.0 (CPU 위주)	🟡 적합 (느림)
KORani-v3-13B	✅ 좋음	✅ 채용담당자 관점 강조, 실용적 접근	❌ 없음	11초	39.3	🟡 적합 (VRAM↑)
Gemma 3 1B Instruct	✅ 매우 좋음	✅ 기술 요약 + 문장 정돈 잘됨	❌ 없음	2초	4.9	🟢 매우 적합
Eximius_Persona_5B-GGUF	✅ 감성 표현 우수	✅ 사용자 입장 묘사 탁월	⚠️ 영어/한글 혼용 있음	37초	0.0 (CPU 위주)	🟢 감성 댓글 적합
Meta-LLaMA-3-8B-Instruct.Q4_K_M	✅ 영어 표현 좋음	✅ 개발자 대상 영문 리뷰에 적합	❌ 없음	46초	0.0	🟡 영어 리뷰용
HyperCLOVAX-SEED-Text-Instruct-1.5B	✅ 문장 구성 매우 안정적	✅ 기술 요약 + 공손한 표현 훌륭	❌ 없음	10초	8	🟢 가장 균형 잡힌 성능

최종 모델 (Gemma 3 1B vs HyperCLOVAX-SEED 1.5B)
-> Gemma 3 1B Instruct로 선정됨.
-> 이유: 개발 과정에서 유사도 모델(sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2")로 입력 데이터와의 유사도를 측정하였으며, 평균적으로 0.4 ~ 0.8를 도출함. 0.3 ~ 0.7사이였던 HyperCLOVAX보다 할루시네이션이 적게 일어남. 더 긴 입력 프롬프트에 대해서도 댓글처럼 문장을 구성함.

3. 주요 이슈

이슈	설명	해결 방법	결과
서버리스 환경 내 모델 서빙	Google Cloud Run 환경은 서버리스 아키텍처 특성상 요청당 최대 500초의 응답 제한이 존재함. 비동기 I/O 요청이 누적되며 500초 내에 일부 댓글이 누락되는 문제가 발생함.	Cloud Tasks 기반 비동기 큐(Task Queue)를 도입하고, 각 요청을 개별 스케줄링하여 500초에 댓글이 하나씩 처리되도록 구조를 개선.	요청당 3개의 댓글이 모두 안정적으로 생성 및 반환됨. 서버 타임아웃 오류가 제거됨.
모델 구축	프롬프트 엔지니어링 및 파라미터 튜닝을 통해 출력 다양성과 안정성을 개선함. 초기 설정에서는 동일한 맥락의 댓글이 반복되는 문제가 발생함.	Temperature, Top-p, Repetition Penalty 등 생성 관련 하이퍼파라미터를 조정하고, prompt template을 구조화하여 주제 일관성과 표현 다양성을 동시에 확보함.	모델이 동일 입력에 대해 문맥적으로 상이한 3개의 댓글을 안정적으로 생성.
할루시네이션 제어	약 40% 비율로 입력과 무관한 허위 또는 과장된 내용이 출력됨. 예: “환자 데이터”, “큰 성과를 거두고 있어요” 등 비관련 정보.	입력 전처리 시 summary 라이브러리를 이용해 문장을 요약하고, cosine similarity(임베딩 기반)를 계산하여 입력-출력 간 유사도가 0.7 이상인 경우에만 유효 응답으로 채택. retry 로직을 추가해 저유사도 응답은 재생성함.	할루시네이션 비율이 기존 약 60% → 15~20% 수준으로 감소. 모델의 맥락 일관성이 강화됨.
JSON 응답비율 함양	모델이 비정형 문자열 또는 중복 문장을 출력하여 JSON 파싱 오류 발생률이 높았음(50% 이하).	Fine-tuning을 통해 JSON Schema를 명시적으로 학습시키고, 파서 단계에서 JSON 형식 내 유효한 댓글만 검증하도록 로직 개선. 다양한 이모지 및 감성 어휘를 함께 학습시켜 표현 폭을 확장함.	JSON 형식 출력 비율이 약 95%까지 상승. 검열 모델 통과율이 향상되고, 감정 표현 다양성이 확보되며, LLM-based 평가모델 기준 semantic coherence score가 향상됨.

4. 결과 및 회고

a. 결과

"품앗이" 프로젝트 댓글	"튜닝"프로젝트 댓글	"미야옹즈"프로젝트 댓글

b. 회고

회고

KPT 분류	설명
Keep (유지할 항목)	[팀] • 적극적인 커뮤니케이션과 협업 분위기: 각자의 의견을 자유롭게 말할 수 있었음. 논의가 필요한 사항에 대해 타운홀에서 대화할 것을 요청하면 흔쾌히 수락해주는 분위기가 좋았음. • 역할 분담과 책임감 있는 태도: 각자 맡은 파트를 책임감 있게 끝까지 마무리해주는 모습이 좋았음. • 빠른 피드백: 특히 평일 퇴근 후, 주말에 보내는 요청사항에 대해 빠르게 대응해주는 점이 좋았음. [개인] • 기획부터 배포까지 전체 흐름을 경험: 단순히 기능 구현에 그치지 않고, 아이디어 발굴 → 기획 설계 → 모델 선택 → API 구성 → 배포까지 End-to-End 전체 개발 프로세스를 경험함. 이를 통해 전체 그림을 보는 시야가 생김. • 모델의 전체 프로세스에 대한 고민: 성능을 고려하여 모델을 고르고, 프롬프팅 및 파라미터 튜닝을 하며 AI 코드를 직접 설계함. 특히 비동기 작업을 위한 큐 생성 과정은 실전에서 도움이 될 것임. • 문제 해결: 배포 과정에서 생긴 오류를 해결하며 로그 추적 및 디버깅 경험을 쌓음.
Problem (문제점)	[팀] • 정보 공유의 부족: API 명세서 수정, UI 변경 등의 주요 변경사항이 사전에 공유되지 않아 다른 파트에 영향을 주었음. 작업을 번복하며 디버깅에 하루 이상이 소요됨. [개인] • 완성 댓글 퀄리티의 불명확성: 처음부터 어떤 댓글이 ‘좋은 댓글’인지 명확한 기준이 없어 딜레마에 빠졌고, 방향성 정립이 어려웠음.
Try (시도할 것)	[팀] • 주요 변경사항 공유를 위한 기본 프로세스 마련: API 명세 변경, UI 수정, DB 스키마 변경 등 타인에게 영향을 줄 수 있는 변경사항은 사전 공유가 필요함. [개인] • 기획 초기 단계에서 '완성 기준'을 명확히 설정하고, 순서도를 그려 개발 중간의 혼란을 줄일 계획.

🌟 뱃지 기능

1. 개발 목적

• 품앗이 참여 유도 : 뱃지를 주고받는 경험 자체가 소소한 보상처럼 작용해, 팀들이 자발적으로 품앗이에 참여하도록 유도합니다.
  

• 디자인 적 통일감 : 팀의 정체성을 담은 이미지를 동일한 구조의 동그란 뱃지로 만들어, UI에 통일감을 줍니다.

• 기여 인식 시각화 : 내가 어떤 팀에게 방문하고, 어떤 팀에게 받았는지를 뱃지로 눈에 보이게 해줌으로써, 나의 활동이 기록되고 인정받는 경험을 제공합니다.

2. 모델 선정

평가 기준

중요 순위	평가 항목	설명
1	🧠 성능	생성된 이미지가 선명한지, Controlnet의 Canny 이미지에 얼마나 잘 따르는지 등을 평가
2	💸 경량화	Google Colab 또는 일반 16GB T4 환경에서 원활히 작동하는지, 실행 중 과도한 RAM/VRAM을 요구하지 않는지, API 호출 시 비용 부담이 적은지를 포함
3	🔥 트렌드 성	현재 커뮤니티에서 얼마나 활발하게 사용되고 있는지, 문서화/예제/튜토리얼/LoRA 등 서드파티 자원이 풍부한지 여부. 유지보수성도 평가 대상
4	⚡ 응답 속도(시간)	이미지 생성은 빠른 응답속도를 기대함. 30초 이내에 이미지 생성이 완료되는지 판단.

모델 선정 과정

모델명	이미지 품질 🎨	프롬프트 반영력 🎯	생성 속도 ⏱	GPU 사용량 (GB)	뱃지 생성 적합성
stable-diffusion-v1-5	✅ 매우 우수	✅ 구도/오브젝트 충실	7초	10	🟢 (매우 적합)
stable-diffusion-xl-base-1.0 (SDXL)	✅ 매우 우수	✅ 구도/오브젝트 충실	10초	14.8	🟡 (중간)
kandinsky-2-2-decoder	단순하지만 임팩트 있음	추상적 반영	✅ 2초	14.8	🟡 (중간)
DeepFloyd IF-I-XL-v1.0	테스트 불가	확인 불가	인증 문제로 제외	-	🔴 (부적합)
Playground v2	실행 불가	API 전용	코드 불가	-	🔴 (부적합)
FLUX (flux-diffusion)	⚠️ 약간 흐릿하지만 매끄러움	🎯 텍스트/형태 반영 적당	6초	8.5~9	🟡 (중간)

최종 모델 (stable-diffusion-v1-5 vs stable-diffusion-xl-base-1.0)
-> stable-diffusion-v1-5로 선정됨.
-> 이유: 개발 과정에서 배포 환경이 22GB L4에서 16GB T4로 변경되면서 리소스를 더 적게 사용하는 모델을 사용함.

3. 주요 이슈

이슈	설명	해결 방법	결과
사용자 요구 구체화	‘각 팀에 맞는 뱃지 생성’이라는 사용자 요구사항에 따라, 팀별 파비콘 및 로고 데이터를 수집하고 이를 ControlNet + Stable Diffusion 1.5 기반의 생성 파이프라인으로 통합함.	Selenium 기반 비동기 크롤러로 정적 → 동적 → 디스콰이엇 → 로고 → fallback 순의 다단계 탐색 로직을 구현.	팀별 도메인 아이덴티티가 반영된 이미지를 안정적으로 확보함.
RAM 16GB, GPU T4환경 내 서빙	ControlNet(large) + SDXL + Refiner 조합(≈22GB VRAM) 구조는 GPU 자원 제약으로 인한 병목을 초래함.	경량화된 ControlNet(small)과 SD1.5, LoRA 기반의 모듈러 아키텍처로 전환하여, 파라미터 효율을 극대화함. 모델 offloading, VAE slicing, mixed precision(fp16) 추론을 병행하여 VRAM footprint를 16GB 이하로 최적화함.	-
이미지 퀄리티 고도화	일부 팀 로고의 해상도가 100×100 이하로, edge feature가 손실되어 ControlNet 입력으로 부적합한 문제가 발생함.	업스케일링 파이프라인에 Real-ESRGAN(x2, ONNX 버전) 모델을 적용하고, bicubic interpolation과 Laplacian sharpening을 병행하여 512×512 해상도로 리샘플링.	-
메모리 누수	이미지 생성 반복 시, PyTorch 텐서 및 GPU 캐시가 해제되지 않아 누적되는 현상이 발생함.	torch.cuda.empty_cache(), gc.collect() 호출과 세션 기반 메모리 해제 로직을 삽입. 또한, context manager(with torch.no_grad():)를 통해 불필요한 그래프 생성 차단.	장기 구동 시에도 안정적인 RAM 사용률 유지 및 OOM(Out Of Memory) 오류 완전 제거.

4. 모델 평가 및 결과

a. 결과

<1team ~ 8team>

TEAM	1	2	3	4
Badge

TEAM	5	6	7	8
Badge

b. 회고

회고

KPT 분류	설명
Keep (유지할 항목)	• 사용자 요구에 모델 접목: 팀의 아이덴티티를 반영해달라는 사용자 요구에, 직접 아키텍처를 설계하고 전략을 세우는 과정에서 성장할 수 있어서 좋았음. • Spot instance환경 사용: Cloud RUN환경이었던 댓글기능과 다르게, spot-instance 환경에서 운영해 본 경험을 얻었음. 다양한 배포 환경에 맞춰 전략을 변경해봄. • LoRA파일 적용: 크기가 큰 모델을 사용하는 대신, LoRA파일을 통해 리소스를 절약하며 원하는 결과를 내는 경험을 해봄. • 긍정적인 피드백: 초기 배포시엔, 뱃지 디자인이 마음에 들지 않는다는 피드백을 받았음. 이후 뱃지 디자인을 수정하고, 해상도를 높여 뱃지에 대한 긍정적인 피드백을 받게 되었음. • 꼼꼼한 설계 및 문서화: 로직을 구축하기 전에 입력데이터를 직접 크롤링 후 다운받아 SD1.5와 SDXL모델을 비교하며 성능비교를 진행하였음. 해당 내용을 문서화 하여 기록으로 남겨두었음.
Problem (문제점)	• 해상도가 매우 낮은팀에 대한 대응: 해상도가 48x48인 팀은 512x512로 해상도를 높이는 과정에서 심한 이미지의 손상이 발생함. 해당 팀들은 따로 이미지를 받아 예외처리를 통해 해결하였으나, 자동화가 아니었다는 부분에서 아쉬웠음. • Fallback로직: 사용할 이미지가 없을 경우, fallback로직으로 각팀의 첫글자를 이미지로 사용함. 디자인 적인 측면에서 아쉬웠음.
Try (시도할 것)	• 직접 이미지를 입력받을 수 있도록 로직 수정: 사용자가 원하는 이미지를 직접 입력할 수 있도록 추가로 로직을 구성한다면 사용자 경험에 긍정적인 영향을 미칠것이다.

💬 챗봇 기능

1. 개발 목적

• 팀 프로젝트의 맥락 이해를 돕기 위해 각 팀의 GitHub 레포에서 수집한 커밋, PR, 이슈, README, Wiki 등을 기반으로 프로젝트 소개, 최근 변경사항, 기술 스택 등 맥락적인 질문에 답할 수 있도록 챗봇 기능을 설계했습니다.
• 자기 팀 외 다른 팀에 대한 이해 촉진 같은 부트캠프 내 다른 팀들이 무슨 기능을 만들고 있는지, 어떤 아이디어를 구현했는지를 빠르게 파악할 수 있도록 하여 팀 간 품앗이 참여를 자연스럽게 유도합니다.
• 실제 서비스에 적용 가능한 RAG 구조 Retrieval-Augmented Generation 구조를 기반으로 팀별 개인화된 챗봇을 구현하며, LLM과 벡터DB를 연결하는 인프라 구성을 목표로 했습니다.

2. 모델 선정

임베딩 모델 선정

GitHub 문서는 영어/한글/코드 주석이 혼합되어 있고, 사용자 질문은 대부분 한국어 자연어 질문이 들어옵니다. BAAI/bge-m3는 이러한 언어 불일치 상황에 최적화된 다국어 모델로, 언어 간 의미 연결을 정확하게 처리할 수 있기 때문에 본 프로젝트에 가장 적합합니다.

다국어 성능에 최적화로 유명한 e5모델도 초기에는 고려해보았지만, 아래 표와 같은 평가 기준으로 모델을 최종 선정하였습니다.

항목	BAAI/bge-m3	intfloat/multilingual-e5-base	📝 평가
🔤 지원 언어	100개+ 다국어 지원 (한국어 포함)	40개 이상 다국어	✅ BAAI 더 풍부함
🧠 학습 목적	Multitask RAG 최적화(Query → Document 구조)	문장 의미 유사도 (대칭 구조)	✅ BAAI가 질문→문서 검색에 최적화
💡 구조 특징	Query-Document 비대칭(검색 방향성 고려)	Query ~ Document 대칭 구조	✅ RAG용은 비대칭이 유리
🧪 검색 성능 (MTEB 기준)	문서 검색/QA SOTA급 성능	전체적으로 우수하나 BGE에 약간 밀림	✅ 실전 정확도에서 BAAI 우세
⚡ 추론 속도	약 60~80ms/문장 (GPU)약 300MB 모델 크기	약 100~140ms/문장 (GPU)약 440MB 모델 크기	✅ BAAI가 더 빠름 + 더 작음
🖥️ 리소스 효율	✅ CPU/GPU OKColab에서도 원활	✅ 동일	✅ 둘 다 우수
🧰 사용 호환성	✅ LangChain 완전 호환Chroma, Qdrant 등 지원	✅ 동일	⚖️ 동일

기준	일반 Sentence Similarity 모델 (e5-base)	Multitask RAG 최적화 모델 (bge-m3)
학습 목적	문장 간 의미 유사도 측정	질문 → 정답 문서 매칭
구조	쌍방향 대칭 구조예: A ~ B	단방향 비대칭 구조예: Query → Document
학습 데이터	STS (Semantic Textual Similarity)	OpenQA, Web Search, FAQ, Retrieval 등
성능 특화	문장 유사도, 분류	RAG 검색 정확도, FAQ 매칭, QA 검색

추가 모델 실험 결과:

기준	설명
✅ 정확도	질문이 문서 본문과 직접 유사하지 않아도 정확히 검색 가능
✅ 실시간 응답	SSE 기반 챗봇에서 빠른 추론을 보장 (60ms대)
✅ 방향성 최적화	“이 팀은 어떤 기능 했어?” 같은 Query → 문서 검색에 구조적으로 최적
✅ 운영 효율	GPU 메모리 사용량 낮고, Colab에서도 추론 병목 없음

llm 모델 선정

사용 모델: naver-hyperclovax/HyperCLOVAX-SEED-Text-Instruct-1.5B

기준	설명
✅ 한국어 친화성	질문/응답 모두 한국어 기반인 품앗이 챗봇에 최적
✅ 지시 이행 정확도	운세, 댓글, 요약 등 다양한 지시문 응답 성능 우수
✅ 실시간 대응성	vLLM + 양자화 환경에서 초 단위 응답 가능
✅ 구조 호환성	LangChain + PromptTemplate + MCP 구조와 완벽 통합 가능

모델	한국어 응답 정확도	문장 구성	비용/제약	첫 응답 속도	전체 생성 시간(초)	응답 품질 요약
HyperCLOVA 1.5B	✅ 매우 높음	✅ 완결성 좋음	✅ 무료, 로컬 추론	1.3초	2.8	🟢 매우 우수
Gemma 3 1B Instruct	✅ 깔끔함	✅ 문장 구성 매우 안정적	❌ 없음	9초	17.6	🟡 중간
GPT-3.5-turbo	⚠️ 낮음 (의역 많음)	✅ 자연스러움	❌ 유료 API	1.2초	3.4	🟡 제한적
Mistral 7B	⚠️ 중간	✅ 강함	⚠️ 메모리 요구 큼	4.8초	8.2	🟢 안정적
Phi-2	❌ 낮음	⚠️ 단조로움	✅ 경량	3.5초	5.6	🔴 불안정

품앗이 프로젝트에서는 한국어 기반 질문에 정확하고 빠르게 응답하기 위해 HyperCLOVA-SEED-Text-Instruct-1.5B 모델을 선택했습니다. 해당 모델은 한국어 특화 성능, 빠른 추론 속도, 다양한 프롬프트 대응력에서 우수하며, vLLM + LangChain 기반 구조에 최적화되어 실시간 RAG 챗봇 운영에 매우 적합합니다.

3. 주요 이슈

이슈	설명	해결 방법	결과
1. 유사도 검색 결과가 얕고 반복적임	초기에는 커밋 메시지 위주의 단조로운 문서만 저장되어 챗봇 응답이 반복되고 얕았음	- 커밋 필터링 로직 적용- PR/이슈/README/Wiki 별도 전처리 및 요약- 중간에 LLM 삽입하여 요약 후 저장- LangChain Retriever 커스터마이징 (weight 기반 정렬)	검색 정확도 향상 및 응답 품질 개선
2. 프로젝트 무관 질문에도 응답 생성	GPT처럼 프로젝트 외 질문에도 문서를 검색해 잘못된 응답 생성	- LLM 분류기 도입- 프로젝트 관련 질문만 RAG 수행- 무관 질문은 안내 메시지로 대체	챗봇 응답 신뢰도 및 일관성 향상
3. 멀티 프롬프트 미적용으로 응답 일관성 부족	모든 질문에 동일한 프롬프트 사용 → 톤, 포맷, 맥락 일치도 낮음	- 질문 분류기 도입- 질문 유형별 멀티 프롬프트 적용 (개요, 기능, 기술 등)	응답의 문맥 적합도 및 사용자 이해도 향상
4. 응답에 프롬프트 문장이 섞여 나옴	HyperCLOVA 응답에 시스템 프롬프트/지시어가 함께 출력됨	- 정규식 기반 후처리 로직 도입 (re.findall())- 프롬프트/지시어 제거 후 사용자에게 전달	깔끔하고 자연스러운 응답 제공, UX 개선
5. 서버 리소스 과부하 및 GPU 부족	vLLM 서버에 동시 요청 시 지연 발생, GPU 메모리 초과 가능성	- HyperCLOVA 모델에 AWQ 양자화(4bit) 적용- (예정) Redis 캐시 + 비동기 처리- (예정) CPU 백업 모델 분리 구성	추론 속도 개선, 서버 안정성 향상

4. 평가 및 결과

a. 기술 고도화 및 최적화 전략

• 모델 파인튜닝 (Fine-tuning): 챗봇의 응답 품질을 높이기 위해, 실제 팀 프로젝트 질문-응답 데이터를 기반으로 HyperCLOVA 모델을 파인튜닝하여 팀 활동 요약 및 기술 맥락에 특화된 응답을 생성할 수 있도록 했습니다.
• vLLM 기반 고속 추론 서버 구성: OpenAI API 형태로 배포 가능한 vLLM 엔진을 도입하여, 대규모 LLM도 실시간 스트리밍 응답이 가능하도록 구성했습니다. 특히 SSE(Streamed Server Events) 방식과 결합해 응답 대기 시간을 줄이고 사용자 경험을 개선했습니다.
• 모델 양자화 (Quantization): 추론 속도와 GPU 메모리 효율을 극대화하기 위해 **AWQ 방식 양자화(4-bit)**를 적용했습니다. 이를 통해 응답 시간은 약 15% 개선되고, GPU 사용량은 약 5~10% 절감되었습니다.
• MCP (Modular Context Pipeline) 구조 도입: 질문 분류 → 문서 검색 → 프롬프트 구성 → 응답 생성을 단계별 모듈로 분리하여 유지보수성과 확장성을 확보했습니다. MCP 구조를 통해 모델 라우팅, 프롬프트 멀티 구성, 벡터 필터링 등의 로직을 독립적으로 관리할 수 있도록 설계했습니다.

b. 성능 비교

항목	기본 모델 (FT only)	✅ vLLM 도입	✅ + AWQ 양자화
첫 응답 토큰 시간	5.3초	3.1초	1.4초
전체 응답 완료 시간	9.4초	6.2초	2.8초
의미 있는 문서 참조율 (Top-3)	72%	78%	81%
누락된 기능 설명 비율	28%	22%	13%
GPU 메모리 사용량 (VRAM)	8.1GB	8.2GB	5.3GB

평가방법

**응답 품질을 검증**하기 위해, LLM의 응답을 다음 기준으로 자동 평가했습니다.

평가 항목	설명	평가 방식
🍒 정확성	답변이 GitHub 문서에 명시된 정보에 근거한 사실인가?	✅ True / ⚠️ False
✂️ 간결성	응답이 불필요한 반복 없이 핵심만 요약되어 있는가?	📊 1~5점 척도
🧠 문맥 적합성	질문의 의도에 맞는 정보를 제공했는가?	✅ True / ⚠️ False
🧷 정보 누락 여부	문서에 중요한 정보가 있는데 빠지지 않았는가?	📊 1~5점 척도
📄 형식 일관성	프롬프트에 명시된 형식(문장 수, 말투 등)을 지켰는가?	✅ True / ⚠️ False

• 입력 값:
  • 질문(question)
  • 챗봇 응답(answer)
  • 문서 기준(context)
• 출력 값:
  • 정확성 / 문맥 적합성 / 형식 일관성: True / False
  • 간결성 / 정보 누락 여부: 1~5점

c. 실제 챗봇 질문 예시

ex) 8팀	ex) 6팀