1편. 프로젝트 소개 - 왜 AI 추천이 필요했나

 

프로젝트 배경

대학에는 수많은 교과와 비교과가 있다. 매 학기 수강신청 때마다 학생들은 뭘 들어야 할지 몰라 선배들이 추천하는 강의에 몰리고, 막상 수강한 강의에 대한 만족도는 낮은 경우가 많다.

학생들이 자신에게 맞는 교과를 찾을 수 있도록 AI 기반 추천 시스템을 만들어달라는 의뢰를 받았다.

이후 비슷한 요청이 이어져, 현재 몇몇 교육기관에서 이 솔루션을 사용 중이다.

---

해결하고자 한 것

대학에서는 이 문제를 AI 기반 개인화 추천 시스템으로 해결하고자 했다.

목표

1. 학과 기반 추천: 학생의 전공/학과에 적합한 강좌 우선 추천
2. 관심사 반영: 학생이 선택한 관심 분야를 추천에 반영
3. 자동화: 매 학기 새로운 강좌가 개설되어도 자동으로 추천 갱신
4. 설명 가능성: 왜 이 강좌를 추천하는지 근거 제공

---

기술적 도전 과제

이 프로젝트에서 내가 마주한 기술적 도전은 다음과 같았다.

도전 과제 설명

텍스트 유사도 계산	강좌 설명과 학생 프로필을 어떻게 비교할 것인가?
한국어 처리	강좌명, 설명이 모두 한국어. 영어 모델로는 한계
불충분한 설명	강좌 설명이 너무 짧거나 없는 경우 많음
가중치 설계	학과 vs 관심사, 어떤 비율로 반영할 것인가?
성능	5,000명 학생 × 2,000개 강좌 매칭을 합리적 시간 내에
운영 환경	GPU 없는 서버에서도 동작해야 함

---

설계한 시스템 아키텍처

전체 시스템을 다음과 같이 설계했다.

┌───────────────────┐
│   외부 학사 API     │  ← 학생, 강좌, 학과, 관심사 데이터
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│  데이터 파이프라인    │  ← 주기적 동기화, 정제, 저장
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│    PostgreSQL     │  ← 원천 데이터 + 추천 결과 저장
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│   AI 추천 엔진      │  ← XLM-R 임베딩 + 가중치 계산
│                   │
│  • 학과 기반 (70%)  │
│  • 관심사 (30%)     │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│   LLM 설명 보강     │  ← 부족한 강좌 설명을 LLM으로 확장
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│   FastAPI 서버     │  ← REST API로 추천 결과 제공
└───────────────────┘

---

기술 스택 선정 근거

기술을 선택할 때는 항상 "왜 이것인가?"를 고민했다.

1. 임베딩 모델: XLM-R

고려한 옵션 선택 여부 이유

OpenAI Embedding	❌	API 비용, 외부 의존성, 데이터 유출 우려
KoBERT	❌	한국어 전용이지만 영어 섞인 설명 처리 한계
XLM-R	✅	100개 언어 지원, 한국어 성능 우수, 로컬 실행 가능

결정 근거: 강좌 설명에 영어 용어가 섞여 있고, 외부 API 없이 서버에서 직접 실행해야 했다.

2. LLM: 경량 모델 (1.2B 파라미터)

고려한 옵션 선택 여부 이유

GPT-4 API	❌	비용, 외부 의존성
Llama 70B	❌	GPU 필수, 운영 서버에 GPU 없음
경량 LLM (1.2B)	✅	CPU에서 실행 가능, 충분한 품질

결정 근거: 운영 서버에 GPU가 없었고, 설명 보강 작업은 배치로 처리하면 속도가 크리티컬하지 않았다.

3. 백엔드: FastAPI + SQLAlchemy

고려한 옵션 선택 여부 이유

Django	❌	이 프로젝트에는 과한 기능
Flask	❌	비동기 지원 미흡
FastAPI	✅	비동기, 자동 문서화, 타입 힌트

결정 근거: AI 추론이 느릴 수 있으므로 비동기 처리가 필요했고, Pydantic 기반 타입 검증이 ML 파이프라인과 잘 맞았다.

---

추천 알고리즘 설계 철학

추천 시스템을 설계할 때 가장 많이 고민한 부분은 가중치였다.

문제: 학과 vs 관심사, 어떤 것이 더 중요한가?

• 학과 중심 (100%): 전공 관련 강좌만 추천 → 학생의 관심사 무시
• 관심사 중심 (100%): 관심사 기반만 추천 → 전공 학점 취득 어려움

해결: 하이브리드 가중치

최종 점수 = (학과 일치 점수 × 0.7) + (관심사 유사도 × 0.3)

가중치 비율 근거

학과 기반	70%	학생은 우선 자기 학과 강좌를 들어야 함
관심사	30%	개인화 요소로 차별화된 추천 제공

 

이 비율은 담당자와 협의하여 결정했고, 설정으로 조정 가능하게 구현했다.

---

프로젝트 범위

내가 직접 구현한 것

1. 데이터 파이프라인: 외부 API → PostgreSQL 마이그레이션
2. AI 추천 엔진: XLM-R 임베딩 + 가중치 계산
3. LLM 설명 보강: 부족한 강좌 설명 자동 확장
4. 성능 최적화: CPU 환경에서 27배 속도 향상
5. API 서버: FastAPI 기반 REST API
6. 배포: Nuitka 바이너리 빌드, Docker 환경

성과

항목 수치

대상 학생	5,000명+
추천 강좌	2,000개+
추천 비교과 활동	500개+
학생당 추천	강좌 5개 + 활동 5개

---

다음 편 예고

다음 편에서는 데이터 파이프라인 설계를 다룬다.

• 외부 API에서 데이터를 어떻게 가져오는가?
• 재시도 로직과 페이징 처리
• PostgreSQL upsert로 중복 데이터 처리
• 증분 동기화 전략

---

시리즈 목차

1. 프로젝트 소개 - 왜 AI 추천이 필요했나 ← 현재 글
2. 추천을 위한 데이터 파이프라인 설계
3. XLM-R로 강좌 임베딩 구축하기
4. 추천 알고리즘 설계 - 가중치 기반 개인화
5. LLM으로 강좌 설명 보강하기
6. 성능 최적화 - CPU에서 27배 빠르게
7. API 서버 구축과 배포