🔗 전체 프로젝트 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. 주요 이슈

이슈	설명	해결 방법	결과
할루시네이션	아래와 "환자 데이터"와 같이 프로젝트와 전혀 무관한 기능에 대해 언급하거나, "큰 성과를 거두고 있어요"와 같이 허위 사실을 댓글로 언급함.	검열 모델로 임베딩 모델을 추가하여 입력데이터와의 유사도가 0.6 이상인 댓글만 출력함.	할루시네이션비율이 기존 약 60%에서 20%로 하락함.
프롬프트 수정 필요	사용자 입력으로 받은 데이터 중, 500자 이상의 긴 입력이 있을 시 AI가 이해하지 못함.	TF-IDF 기반 요약 라이브러리를 사용하여 글자수를 줄인 후에 프롬프트에 반영	500자 이상의 입력에 대해 댓글이 생성됨.
파라미터 수정 필요	댓글이 모두 동일한 주제에 대해서 얘기함	model 로드시, temperature, top_p등의 다양성과 관련된 파라미터를 수정함.	한번에 생성된 댓글이 모두 다른 주제로 생성됨.
배포 환경 구축	Docker 파일 작성, Cloud RUN 오류 해결 등 기타 배포에 필요한 라이브러리 버전 오류를 수정함.	pip show '라이브러리' 명령어로 더 명확한 버전을 requriements.txt에 기재. Cloud RUN 실행 제한 수정	멈춤 없이 동작하도록 수정.

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. 주요 이슈

이슈	설명	해결 방법	결과
입력 데이터 크롤링	각 팀의 정체성을 담은 뱃지를 생성해달라는 사용자 요구사항에 따라 팀별 이미지 크롤링 진행.	각 팀의 프로젝트 URL을 통해 파비콘을 크롤링 해온 후 Controlnet을 통해 팀 이미지 구현.	정적 크롤링 -> 동적 크롤링 -> 디스콰이엇 크롤링 -> 로고 크롤링 -> fallback로직을 통해 각 팀의 대표 이미지를 확보
입력 데이터 전처리	크롤링 해온 이미지를 새롭게 인공지능으로 색칠하기 위해 Canny 이미지로 전처리 필요. 각 팀 파비콘의 해상도가 달라, 512x512로 업스케일링 진행이 필요.	upscailing 모델 및 고해상도 보간을 통해 업스케일링 진행.	사용자 만족도가 상승되었다는 피드백을 받음.
성능 향상 필요	Stable diffusion 1.5모델은 프롬프트를 잘 이해하지 못하여, 원하는 스타일을 출력하는 데 어려움이 있음.	각 스타일에 해당되는 LoRA파일을 1개 이상 모델 파이프라인에 추가.	뱃지 수정 기능 구현 가능해짐.
배포 환경 구축	이미지 생성모델의 특성상, garbage data가 생성되어, RAM내부에 쌓이게 됨. 16GB T4환경에서 동작 필요.	메모리 관리 로직 도입.	OOM 없이 동작 됨을 확인함.

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팀