12조 · 캡스톤프로젝트 · 2026-1
| 이름 | 역할 |
|---|---|
| 강현모 | 백엔드 |
| 양병현 | 프론트엔드 |
| 권오규 | QA |
- GitHub Pages:
https://khmo31.github.io/ppt-html-capstone/ - 로컬:
index.html을 브라우저로 열기 - 키보드:
↑↓또는←→로 슬라이드 이동 - 마우스: 하단 도트 클릭 또는 스크롤
🔗 카테고리로 이동: 📌 프로젝트 개요 · ⚙️ 기술 스택 및 아키텍처 · 🧠 임베딩 → Wiki 전환 · 🔄 CrewAI → 경량화 · 📊 구현 및 성능 · 👥 역할 및 협업 · 🚀 확장 및 향후 계획 · 📝 평가 및 회고 🏗️ 시스템 설계 결정
Q. 이 프로젝트가 해결하려는 문제는 무엇인가요?
공공기관 채용 공고는 ALIO에 게시되지만, 지원자의 역량(NCS CODE 기반)과 채용 공고의 요구사항을 정확히 매칭해주는 시스템이 부재합니다. 단순 키워드 검색만으로는 사용자가 자신에게 적합한 공고를 찾기 어렵고, NCS 분류 체계를 모르는 지원자는 더더욱 탐색이 어렵습니다. 이 프로젝트는 채용 공고 원문 데이터를 NCS 기반 Facet Wiki로 구조화하여 정확하고 투명한 매칭을 제공하는 데 목적이 있습니다.
Q. 기존 채용 플랫폼(사람인, 잡코리아)과의 차별점은?
단순 키워드 검색이 아닌, ALIO API 원문 데이터를 NCS 기반 Facet Wiki로 구조화하여 공고 간 관계까지 분석합니다. Facet Wiki를 통한 지식 그래프 연결이 핵심입니다. 사용자에게 "왜 이 공고가 매칭되었는지"를 설명 가능한 형태로 제공할 수 있으며, 이는 기존 플랫폼이 제공하지 못하는 가치입니다.
Q. 타겟 사용자는 누구인가요?
공공기관 취업을 준비하는 취업 준비생과 NCS 기반 채용 정보가 필요한 모든 지원자입니다. 특히 NCS 분류 체계에 익숙하지 않은 사용자도 쉽게 사용할 수 있는 UI/UX를 목표로 했습니다.
Q. ALIO API만 사용하는 이유는?
ALIO는 공공기관 채용정보를 표준화된 API로 제공하는 유일한 플랫폼입니다. 데이터가 정형화되어 있어 NCS 기반 Facet Wiki 구축에 적합합니다. 향후 사람인·잡코리아 API를 추가 연동하면 공공+민간 통합 매칭으로 확장 가능합니다.
Q. 기술 스택 선정 기준은?
- LLM API — OpenCode Go (Deepseek 기반): 한국어 능력 우수, 비용 효율적
- 파이프라인 — Python + 커스텀 LLM 클라이언트: CrewAI 대비 가벼움
- 매칭 엔진 — NCS Wiki 기반 룩업: 설명 가능한 결과 제공
- 데이터 저장 — JSON + 로컬 파일: MVP 단계에서는 DB 오버헤드 불필요
- 프론트엔드 — GitHub Pages + 정적 HTML: 배포 단순화
Q. 단일 LLM만 사용하는 이유는? 위험 부담은?
OpenCode Go API를 주력으로 사용하고, 장애 상황에서만 Groq로 폴백합니다. 단일 모델 사용 시:
- 장점: 응답 일관성 유지, API 비용 예측 가능
- 단점: 단일 장애점(SPOF)
Groq는 무료이므로 폴백 시에도 비용 부담이 없습니다. 향후 Anthropic/OpenAI 등 여러 provider로 확장할 수 있는 추상화 계층을 염두에 두고 설계되었습니다.
Q. 매칭 엔진의 동작 방식은?
- 수집: ALIO API → 공고 원문 수집
- 파싱: NCS CODE, 자격요건, 우대사항 추출
- 매칭: NCS Wiki에서 사용자 역량 ↔ 공고 요구사항 매핑
- 랭킹: 매칭 스코어 기반 정렬
- 설명: "왜 매칭되었는지"에 대한 근거 생성 (LLM + Wiki 기반)
Q. 데이터 파이프라인 구조를 설명해주세요.
ALIO API → Step 1: 공고 수집기 → Step 2: NCS 파서
→ Step 3: Wiki 매처 → Step 4: 랭커
→ Step 5: 설명 생성기 (LLM) → 최종 결과
각 Step은 독립적인 모듈로 설계되어, 개별 교체 및 테스트가 용이합니다. Step 2-3이 핵심 로직이며, 여기서 임베딩 방식에서 Wiki 방식으로의 전환이 이루어졌습니다.
Q. 프로젝트 전체 코드 라인 수와 구성 비율은?
약 1,100줄의 Python 코드로 구성되어 있으며, 대부분이 매칭 엔진과 파이프라인 로직입니다. 이는 CrewAI 기반이었다면 3배 이상 늘어났을 규모로, 경량화 설계의 효과를 보여줍니다. (구체적인 모듈별 라인 수는 GitHub Insights 참고)
Q. 왜 임베딩(Vector DB)을 포기하고 Wiki 방식으로 전환했나요? ⭐
가장 중요한 기술적 의사결정입니다. 임베딩은 유사도는 측정할 수 있지만, 관계를 설명하지 못합니다.
예를 들어:
- "의료기기 연구개발" (NCS: 08030201, 대분류: 08. 기계)
- "의공학" (전공명, 대분류: 09. 정보통신 또는 별도)
임베딩(OpenAI text-embedding-3-small)은 두 개념에 의학 + 공학 + 기술 관련 단어가 많이 포함되어 있어 벡터 유사도를 높게 평가합니다 (0.85+). 따라서 "같은 분류"라고 잘못 판단할 위험이 있습니다.
하지만 NCS 분류 체계로 보면:
| 개념 | NCS CODE | 대분류 | 직무 영역 |
|---|---|---|---|
| 의료기기 연구개발 | 08030201 | 08. 기계 | 기계설계, 의료기기 |
| 의공학 | — | 정보통신 등 | 생체신호, 의료AI |
임베딩은 이 계층적 분류 구조를 전혀 반영하지 못합니다. 반면 NCS Wiki는:
"보건의료"라는 NCS 분류로 명확히 구분
즉, Wiki 방식은 **"유사도로 찾지 말고, 분류 체계로 정확히 찾자"**는 접근법입니다. 결과적으로 더 투명하고 정확한 매칭 결과를 제공할 수 있습니다.
Q. 임베딩 방식의 구체적인 한계는 무엇이었나요? ⭐
- 설명 불가능성(Black Box): "이 두 공고가 유사합니다"까지만 알려줄 뿐, 왜 유사한지 설명 불가
- False Positive: 의미는 다르지만 단어 분포가 비슷한 경우 오매칭 발생
- 도메인 특화성 부족: 일반 도메인 임베딩 모델은 NCS 분류 체계를 학습하지 않음
- 업데이트 비용: 새 NCS CODE가 추가되면 전체 임베딩 재생성 필요
Q. Wiki 방식이 임베딩보다 좋은 점 3가지는?
- 설명 가능성: "NCS CODE 08030201이므로 기계설계 분야입니다"라고 명확히 설명 가능
- 정확도: 분류 체계 기반 매칭으로 False Positive 최소화
- 유지보수 용이성: Wiki 페이지 추가/수정만으로 시스템 업데이트 완료 (재임베딩 불필요)
Q. 하이브리드(임베딩 + Wiki)는 고려하지 않았나요?
고려했습니다. MVP 단계에서는 Wiki 방식이 더 나은 선택이었습니다. 하지만 향후에는 Vector DB로 유사 공고 추천 + Wiki로 정확 매칭을 결합한 하이브리드 검색을 도입할 계획입니다. 예를 들어, 사용자가 본 공고와 유사한 공고는 임베딩으로 찾고, 정확한 NCS 매칭은 Wiki로 수행하는 식입니다.
Q. CrewAI를 왜 도입했다가 버렸나요? ⭐⭐
초기 설계에서 "Multi-Agent가 더 좋은 결과를 낼 것"이라는 막연한 기대에 CrewAI를 도입했습니다. 하지만 실제로는:
- 단순한 파이프라인에 Multi-Agent 프레임워크는 불필요한 복잡성을 추가
- 각 Agent 간 통신 오버헤드
- 디버깅이 매우 어려움 (Agent 내부 상태 추적 곤란)
- 의존성 증가 (CrewAI 버전, LangChain 호환성 등)
결론적으로 Over-engineering이었습니다. 이 경험을 통해 "문제에 가장 적합한 도구"를 선택하는 공학적 안목을 키울 수 있었습니다.
Q. 경량화 후 구체적인 개선 효과는?
| 지표 | CrewAI | 경량화 | 개선율 |
|---|---|---|---|
| Token 사용량 | 100% | 40% | 60% 절감 |
| 코드 라인 수 | 약 3,500줄 | 약 1,100줄 | 69% 감소 |
| 디버깅 시간 | 30분↑ | 5분↓ | 83% 단축 |
| 실행 시간 | 15초 | 5초 | 67% 단축 |
특히 Token 60% 절감은 API 비용과 직결되는 요소로, 장기 운영 시 큰 차이를 만듭니다.
Q. 경량화하면서 어떤 아키텍처로 변경했나요?
Multi-Agent → 단일 LLM 클라이언트 + 모듈형 Step 파이프라인
[Before] CrewAI Agent A → Agent B → Agent C (각 Agent가 LLM 호출)
[After] Loader → Parser → Matcher → Ranker (단일 LLM은 설명 생성에만 사용)
LLM이 모든 단계를 담당하지 않고, LLM이 필요한 곳(설명 생성)에만 집중하도록 역할을 축소했습니다. 나머지 로직은 전통적인 알고리즘으로 처리합니다. 이 접근법이 Token을 60%나 절감한 핵심입니다.
Q. 이 결정에서 배운 공학적 교훈은?
- "일단 동작하는 최소 버전(MVP)" 을 먼저 만들고 점진적으로 개선하라
- 기술 선택은 문제의 복잡도에 비례해야 한다 (단순한 문제에 복잡한 도구는 금물)
- 의존성 최소화는 유지보수성의 핵심
- 완벽한 아키텍처보다 동작하는 코드가 먼저다
Q. 수집한 공고 데이터 규모는?
ALIO API를 통해 444개 이상의 공공기관 채용 공고를 수집 및 분석했습니다. 각 공고는 NCS CODE, 자격요건, 우대사항, 근무조건 등 구조화된 필드로 파싱됩니다.
Q. 매칭 정확도는 어떻게 측정하나요?
QA 담당자(권오규)가 수동 레이블링한 테스트 셋을 기준으로 Precision/Recall을 측정합니다. 현재 Wiki 기반 매칭은 임베딩 방식 대비 False Positive가 현저히 감소하여 Precision이 개선되었습니다. 구체적인 수치는 데모 페이지에서 확인 가능합니다.
Q. Groq Rate Limit은 어떻게 대응했나요?
Groq의 무료 티어에는 분당 요청 제한이 있습니다. 다음과 같이 대응했습니다:
- 지수 백오프(Exponential Backoff) 알고리즘 도입
- 요청 간 쿨다운(Cool-down) 적용
- 장애 시 OpenCode Go로 자동 폴백
- 각 요청의 재시도 횟수와 상태를 로깅하여 모니터링
Q. Token 사용량을 구체적으로 어떻게 절감했나요? ⭐
CrewAI 방식의 문제는 매 Step마다 프롬프트 컨텍스트를 반복 전송한다는 점이었습니다:
- Agent 1이 처리한 결과를 Agent 2에 전달할 때 전체 컨텍스트 재전송
- Agent 2의 시스템 프롬프트 + Agent 1 결과 + 새로운 입력 = 중복 토큰
경량화 후:
- LLM 호출 횟수: 3회 → 1회 (설명 생성 전용)
- 프롬프트 크기: 이전 맥락 불필요
- 결과: Token 사용량 60% 절감
즉, "LLM을 모든 곳에 쓰지 말고, 필요한 곳에만 쓰자"는 원칙이 Token 절감의 핵심입니다.
Q. 캐싱 전략이 있나요?
매칭 결과는 JSON 파일로 캐싱됩니다. 동일한 공고에 대한 재요청 시:
- 캐시 Hit → 즉시 결과 반환 (LLM 호출 없음)
- 캐시 Miss → 파이프라인 실행 후 캐시 저장
이를 통해 반복 요청 시 응답 시간을 대폭 단축합니다.
Q. 3인 팀의 역할 분담은?
| 역할 | 담당자 | 주요 업무 |
|---|---|---|
| 백엔드 | 강현모 | 전체 파이프라인, 매칭 엔진, LLM 연동, 기술 설계 |
| 프론트엔드 | 양병현 | 웹 UI/UX, GitHub Pages 배포, PPT HTML |
| QA | 권오규 | 테스트, 데이터 품질 관리, 오류 분석 |
Q. 백엔드 역할의 구체적인 기여는?
- 전체 파이프라인 아키텍처 설계 및 구현
- NCS Wiki 매칭 엔진 개발 (임베딩→Wiki 전환)
- CrewAI → 경량화 리팩토링 주도 (Token 60% 절감)
- Groq Rate Limit 대응 전략 구현
- 444개 공고 데이터 수집 및 구조화
- LLM 클라이언트 추상화 계층 설계
Q. 협업 시 가장 효과적이었던 방식은?
각 모듈을 독립적으로 설계하여 역할 간 의존성을 최소화한 것이 가장 효과적이었습니다. 예를 들어 백엔드의 파이프라인 출력이 JSON 형식으로 정의되어 있으면, 프론트엔드는 이 형식만 알면 독립적으로 UI를 개발할 수 있었습니다. 명확한 인터페이스 정의가 병목을 줄였습니다.
Q. 팀 내 의사결충돌 해결 방식은?
기술적 결정은 데이터와 실험을 근거로 삼았습니다. 예를 들어 CrewAI 유지 vs 경량화 논쟁에서, 실제 Token 사용량과 실행 시간을 측정하여 데이터로 설득했습니다. 의견 충돌이 있을 때는 각자의 접근법을 소규모로 프로토타이핑하고 결과를 비교하는 방식을 사용했습니다.
Q. 왜 데이터베이스 대신 JSON 파일을 사용하나요?
MVP 단계에서는 데이터베이스 도입이 오버엔지니어링이라고 판단했습니다. JSON 파일은:
- 별도 인프라 불필요 (Git에 바로 커밋 가능)
- 데이터 구조 변경이 자유로움 (Schema Migration 불필요)
- 소규모 데이터(444개 공고)에서는 성능 차이가 미미
단, 데이터가 1,000건 이상이 되면 SQLite나 MongoDB 도입을 고려해야 합니다.
Q. LLM 클라이언트는 어떻게 추상화했나요?
class LLMClient:
def generate(self, prompt: str, model: str = "default") -> str:
...인터페이스를 단순하게 유지하여, OpenCode Go → Groq → (향후) Anthropic으로 provider 교체가 자유롭도록 설계했습니다. 설정 파일만 변경하면 provider를 바꿀 수 있습니다.
Q. 어떤 디자인 패턴을 적용했나요?
- Strategy Pattern — 매칭 방식 (임베딩 vs Wiki) 교체 가능
- Chain of Responsibility — Step별 파이프라인
- Factory Pattern — LLM Client provider 생성
- Singleton — 캐시 매니저
복잡한 패턴보다는 "단순함이 최고" 라는 원칙 아래 필수적인 패턴만 적용했습니다.
Q. 에러 처리 전략은?
- 각 Step별 try-catch로 격리 → 한 Step 실패 시 전체 중단 방지
- LLM 호출: 재시도(최대 3회) + 지수 백오프
- API 호출: 폴백 체인 (OpenCode Go → Groq → 에러 반환)
- 모든 에러는 구조화된 로그로 기록 → 추적 가능
Q. 향후 확장 계획은?
- 사람인·잡코리아 API 연동 → 공공+민간 통합 채용 매칭 플랫폼
- Vector DB + Wiki 하이브리드 검색 → 유사도 + 정확도 동시 확보
- 사용자 프로필 기반 맞춤 추천 → 개인화된 공고 추천
- 실시간 알림 → 새로운 공고 등록 시 사용자에게 푸시
- API 서버화 → 다른 서비스에서 활용 가능한 REST API 제공
Q. 하이브리드 검색의 구체적인 계획은?
두 가지 검색을 결합합니다:
- Wiki Search (정확도 우선): NCS CODE 기반 정확 매칭
- Vector Search (유사도 우선): 공고 내용 임베딩 기반 유사 공고 추천
사용자에게 "이 공고와 정확히 매칭됩니다" + "이런 유사 공고도 있어요"를 동시에 제공하는 방식입니다.
Q. 실제 서비스 운영을 위해 필요한 개선점은?
- 데이터베이스 도입 — PostgreSQL (사용자 계정, 기록 저장)
- 인증 시스템 — OAuth2 (Google, Kakao)
- 스케줄링 — 주기적 ALIO API 크롤링 (Airflow or cron)
- 모니터링 — API 사용량, 에러율 대시보드
- 비용 최적화 — LLM 캐싱 고도화, Batch 처리
Q. 지식 그래프 연결을 어떤 방식으로 확장할 계획인가요?
현재는 NCS CODE → Wiki 단방향 연결입니다. 향후에는:
- NCS CODE 간 선수/후수 관계 그래프 구축
- 공고 간 연관성 그래프 ("이 공고를 본 사람은 이 공고도 봤습니다")
- 직무 경로 추천 (A NCS → B NCS로 커리어 전환)
이를 통해 사용자에게 커리어 패스까지 추천할 수 있는 시스템으로 발전시킬 계획입니다.
Q. 이 프로젝트가 성공적이었다고 평가하는 기준은?
- 444개 이상 공고에 대해 정확한 NCS 매칭 수행
- Token 사용량 60% 절감으로 운영 효율성 입증
- 설명 가능한 AI 구현 → 단순 블랙박스 매칭 탈피
- MVP → 개선 사이클 증명: 잘못된 결정(CrewAI)을 인지하고 빠르게 전환
Q. 가장 아쉬웠던 점은?
- 초기 설계에서 완벽을 추구하다 시간 낭비 → 더 빨리 MVP를 만들 걸
- 실사용자 테스트 부족 → 실제 취업 준비생의 피드백을 받지 못함
- 자동화된 테스트 미흡 → QA 담당자가 수동으로 테스트해야 했음
Q. 프로젝트를 통해 배운 점 3가지는?
1. 공학 설계 측면 "문제를 정확히 정의하는 것(5Whys)"이 가장 중요합니다. 문제 정의가 잘못되면 아무리 좋은 기술도 의미가 없습니다.
2. 기술 측면 "단순함이 최고"입니다. CrewAI 실패에서 배운 가장 큰 교훈으로, 필요한 만큼의 복잡성만 유지해야 합니다.
3. 협업 측면 명확한 인터페이스 정의가 병목을 줄입니다. 각 모듈이 독립적으로 동작할 수 있도록 설계하는 것이 팀 생산성의 핵심입니다.
Q. 이 프로젝트를 포트폴리오에 활용하려면 어떻게 강조해야 할까요?
기술 블로그나 포트폴리오에서 다음을 강조하세요:
- 문제 해결 과정: "CrewAI 도입 실패 → 빠른 전환 → Token 60% 절감" (실패와 학습)
- 기술적 의사결정: "임베딩 → Wiki 전환 이유와 효과" (깊이 있는 고민)
- 수치화된 성과: 444개+ 공고, 60% Token 절감, 69% 코드 감소
- 협업: 3인 팀에서의 역할 분담과 독립적 모듈 설계
특히 "왜 임베딩을 버렸나"는 기술적으로 깊이 있는 질문으로, 면접에서 좋은 소재가 됩니다.
Q. 비전공자에게 이 프로젝트를 어떻게 설명하나요?
"채용 공고를 내 능력에 맞게 자동으로 분류해주는 스마트 매칭 시스템" 입니다.
예를 들어, 기계공학을 전공한 사람이 "의료기기 연구개발" 공고를 볼 때, 단순히 키워드만 찾는 게 아니라 NCS라는 국가 직무 분류 체계를 이용해 정확히 어떤 역량이 필요한지, 내 전공과 어떻게 연결되는지를 설명해줍니다.
처음에는 인공지능(CrewAI)으로 모든 걸 처리하려 했지만, 오히려 너무 복잡해져서 단순하고 정확한 방식(Wiki) 으로 바꿨고, 그 결과 더 빠르고 정확한 서비스를 만들 수 있었습니다.