🚀 1차 스프린트: FastAPI 서버 구축부터 LLM 연결까지

🔥 1차 스프린트 시작: AI 서비스의 심장을 만들다

대망의 첫 번째 스프린트. 이번 목표는 AI 상담 분석 시스템의 핵심, LLM을 품은 FastAPI 서버를 구축하는 것이었다. 모든 것이 처음이라 설레면서도 막막했지만, 일단 부딪혀보기로 했다. 과연 첫 단추를 잘 꿰었을까? 🤔

---

🦴 뼈대부터 세우기: LLM 서버 디렉토리 구조

가장 먼저 한 일은 프로젝트의 뼈대를 잡는 것이었다. 기능별로 역할을 명확히 나누어 관리하기 쉽게 디렉토리 구조를 설계했다.

LLM_server/
├── app/
│   ├── main.py         # FastAPI 앱 초기화 및 라우터 설정
│   ├── schemas.py      # 데이터 유효성 검증 (Pydantic)
│   ├── services.py     # 핵심 비즈니스 로직 (LLM 호출)
│   └── api/
│       └── endpoints/
│           ├── summary.py    # 상담 요약 API
│           └── tagging.py    # 키워드 태깅 API
├── core/
│   └── config.py       # 설정 관리 (API 키 등)
├── tests/
│   └── test_api.py     # API 테스트 코드
├── .env                # 환경 변수 파일 (민감 정보)
├── requirements.txt    # 프로젝트 의존성
└── README.md           # 프로젝트 설명서

• app/: FastAPI 애플리케이션의 핵심 코드가 들어있다.
• core/: 프로젝트의 핵심 설정을 관리한다.
• tests/: 테스트 코드를 저장한다.

이렇게 구조를 잡아두니 앞으로 어떤 코드를 어디에 작성해야 할지 명확해졌다.

---

🛠️ 로컬 LLM, 어떻게 연동할까?: 기술 스택 결정

로컬에서 LLM을 어떻게 연동할지 깊이 고민했다. transformers 라이브러리를 직접 쓰는 방법과 Ollama 같은 추론 서버를 이용하는 방법, 두 가지 선택지가 있었다.

⚖️ transformers vs. Ollama (추론 서버)

항목	transformers 라이브러리	Ollama (추론 서버)
개념	Python 코드에서 직접 모델을 불러와 실행하는 라이브러리 방식	모델을 별도 서버로 실행하고, 내 앱은 API로 요청하는 방식
사용 편의성	- 보통: 직접 할 게 많다.	- 매우 쉬움: 명령어로 모델 다운로드와 서버 실행이 끝난다. ✨
자원 관리	- FastAPI 앱과 LLM이 자원을 공유한다.	- FastAPI 앱과 LLM 서버가 독립적으로 실행된다.
확장성	- 현재 앱에 종속적이다.	- 여러 서비스에서 하나의 LLM 서버에 동시 요청할 수 있어 MSA에 딱 맞는다.

🚀 최종 선택: Ollama!

결국 이 프로젝트에서는 Ollama를 쓰기로 결정했다.

• 압도적인 편의성: 몇 개 명령어로 바로 로컬 LLM API 서버를 만들 수 있었다.
• 관심사 분리: FastAPI 서버는 비즈니스 로직에만 집중하고, 무거운 LLM 실행은 Ollama가 전담하니 구조가 아주 깔끔해졌다.
• 아키텍처의 일관성: 전체 시스템이 지향하는 MSA와 방향이 딱 맞았다.

---

🧠 어떤 모델을 쓸까?: gemma:2b로 시작하기

서버는 정해졌고, 이제 어떤 LLM을 올릴지 정할 차례였다. 초기 단계인 만큼, 가볍고 빠른 모델이 필요했다.

📈 gemma:2b vs. 다른 모델들

• gemma:2b: 요약 성능은 좋지만, 키워드 추출처럼 정해진 형식의 출력을 잘 따르지 못하는 경향이 있었다.
• Phi-3-mini: gemma:2b와 비슷한 체급에서 성능이 아주 좋다고 알려진 모델.
• Llama-3-8B: 더 크고 강력하지만, 높은 하드웨어 사양을 요구했다.

🎯 우리의 전략

결론: gemma:2b로 시작하는 게 지금 가장 효율적인 전략이었다.

1. 신속한 개발: gemma:2b는 가볍고 빨라서, 전체 API 흐름을 빠르게 개발하고 테스트하는 데 최적이었다.
2. 점진적 개선: 먼저 gemma:2b로 프로토타입을 완성하고, 성능이 부족하면 phi-3-mini 같은 더 좋은 모델로 쉽게 업그레이드하기로 했다. Ollama를 쓰니 모델 교체 비용이 매우 낮다는 게 큰 장점이었다.

---

💻 Sprint Log: 삽질과 성장의 기록

날짜: 2025년 8월 30일

1. FastAPI 프로젝트 구조 설정 ✅

• main.py, schemas.py, endpoints 등 기본 구조를 잡고 Pydantic 모델로 데이터 형식을 정의했다.

2. LLM 연동 서비스 구현 ✅

• httpx.AsyncClient로 Ollama API에 비동기 요청을 보내는 서비스를 구현했다.
• 요약과 키워드 태깅을 위한 기본 프롬프트를 작성했다.

3. 트러블슈팅: 역시 순탄치 않았다 😭

• ModuleNotFoundError: requirements.txt에 pydantic-settings 추가를 깜빡했다. (기본적인 실수!)
• 422 Unprocessable Content 오류: FastAPI의 /docs UI가 긴 텍스트의 줄바꿈 처리를 못해서 생긴 문제였다. curl로 직접 테스트하니 해결됐다.
• gemma:2b의 배신(!): “키워드만 줘”라고 아무리 말해도 말을 듣지 않고 자꾸 줄글로 답했다. 모델의 지시 사항 준수 능력에 명확한 한계가 있음을 확인했다.

🎉 첫 API 호출 성공의 순간!

수많은 오류를 거쳐, 터미널에서 curl로 보낸 요청에 gemma:2b가 요약한 결과가 딱! 하고 찍혔을 때. 그 짜릿함은 정말 잊을 수가 없다. 드디어 AI 서비스의 심장이 뛰기 시작한 순간이었다.

---

다음 스프린트를 향해

첫 스프린트는 성공적이었다. 서버를 구축하고, LLM을 연동했으며, 심지어 모델의 한계까지 파악했다. 다음 스프린트 목표는 명확해졌다.

• 모델 교체 및 성능 테스트: gemma:2b 대신, 지시를 더 잘 따르는 phi-3-mini 모델로 교체하고 요약 및 키워드 추출 성능을 다시 평가할 것이다.

첫술에 배부를 순 없지만, 방향을 잘 잡았다는 확신이 든다. 다음 스프린트가 더 기대된다. 🔥