사용자 문제를
제품으로 해결합니다

문제한국항공대의 공지는 학과⁠·⁠부서별로 약 70개 웹사이트에 흩어져 있고, 매년 2,000건 넘게 올라옵니다. 장학금⁠·⁠행사 공지를 놓치는 일이 잦아, 전부 모아서 한곳에서 찾을 수 있게 만들었습니다.

구현Python 크롤러가 약 70개 사이트를 수집해 FastAPI⁠·⁠SQLite에 적재하고, Next.js에서 출처⁠·⁠카테고리로 탐색합니다. 질문하면 관련 공지를 근거로 답하는 챗봇은 GrepRag로 만들었습니다. 벡터 임베딩 대신 LLM이 고른 키워드로 공지 본문을 직접 검색(grep)해 후보를 걸러내고 재정렬하는 방식입니다. AWS Lightsail에 Docker로 배포해 운영하고 있습니다.

1. 70개 교내 사이트Python crawler
2. FastAPI · SQLiteingest · search API
3. Next.jsbrowse UI
4. GrepRag 챗봇keyword grep → rerank
5. RAGASanswer eval

설계 결정과 운영만들고 끝이 아니라, 운영하며 생긴 문제를 계측으로 확인하고 고쳤습니다.

• 단순 키워드 매칭의 한계를 확인하고 LLM 키워드 선택 → grep 필터링 → reranking의 GrepRag 구조로 재설계했습니다. 글: RAG 고찰
• "좋아진 것 같다"로 끝내지 않기 위해 RAGAS 평가 파이프라인을 만들어 근거 충실성⁠·⁠관련성⁠·⁠정확성을 수치로 봅니다. 글: RAG 평가 도입
• 공지 데이터를 메모리에 전부 올리던 초기 구조에서 OOM이 발생했습니다. dmesg로 원인을 확인하고 SQLite 기반으로 바꾼 뒤 부하 테스트로 검증했습니다. 글: 인프라 점검
• 공개 서비스의 비용⁠·⁠어뷰징 리스크에 대비해 rate limit⁠·⁠요청 크기⁠·⁠출력 토큰 상한을 걸고, Vercel Analytics로 사용 흐름을 보며 개선 방향을 정합니다. 글: 운영 리스크 글: 모니터링

현재월 방문자가 1,000명을 넘습니다(Vercel Analytics). 유입 대부분이 교내 커뮤니티(에브리타임)를 통해 들어오며, AWS Lightsail 단일 서버에서 운영 중입니다. 위 결정들의 과정은 모두 블로그에 기록해 두었습니다.

월 방문자

1,000+

수집 사이트

약 70

수집 공지

2,400+

담당

End-to-End

서비스 열어보기 GitHub

문제팀 일정 조율은 모두의 가능 시간을 모으는 반복 작업인데, 기존 도구는 가입과 서버를 요구합니다. 밴드 합주 일정을 잡던 경험에서 출발해, 링크만 공유하면 되는 도구를 만들었습니다.

핵심 결정첫 버전 WeBand-Light는 백엔드 없이, 일정 상태 전체를 URL에 인코딩했습니다. 슬롯 비트셋 인코딩과 구간 기반 압축을 모두 구현해 더 짧은 쪽을 자동 선택하는 하이브리드 구조로, 예시 기준 공유 URL을 30자에서 9자까지 줄였습니다. 슬롯을 하나씩 찍는 입력은 터치 친화적인 구간 선택으로 바꿨습니다.

결과출시 한 달 만에 사용자 600명, 이후 2025년 3~9월 누적 방문자 1,220명⁠·⁠페이지뷰 6,055회를 기록했습니다(Vercel Analytics). 참여자가 늘며 URL 방식의 한계가 보여, 고정 공유 링크를 쓰는 DB 기반 WeBand-Together로 확장했습니다. 디자이너⁠·⁠백엔드 개발자와 3인으로 만들었고, 저는 기획⁠·⁠UX에 참여하며 프론트엔드를 전담했습니다.

서비스 열어보기 GitHub

지표를 먼저 해석했습니다Brier Score는 누가 더 잘 맞히는지(순위)가 아니라 예측 확률이 실제 빈도와 얼마나 맞는지(보정)를 채점합니다. 실제로 모델들의 판별력(AUC)은 0.53 수준이었고, 점수 차이의 대부분이 보정에서 나온다는 것을 초기에 측정으로 확인했습니다. 그래서 "더 강한 모델 찾기"가 아니라 "여러 모델을 어떻게 결합하고 확률을 어떻게 보정할 것인가"에 4주를 썼습니다.

접근

• 라벨이 성공 + 반대방향 + 한복판 ≈ 0.90으로 분해된다는 관찰에서 출발해, 실패 유형별로 부스터를 따로 학습하고 그 출력을 스태커가 다시 결합하는 구조를 설계했습니다(CatBoost, 63피처).
• 팀에서 함께 운용한 LightGBM⁠·⁠신경망⁠·⁠EBM 등을 더해 총 5개 모델을 로짓 공간에서 가중 결합하고, 다항식 보정과 상황별 오프셋 보정을 얹었습니다.
• 평가 대상이 2025 시즌이라 모든 누적 통계가 해당 시즌 이전만 참조하도록 만들었습니다. 랜덤 K-Fold 대신 "2023년까지 학습 → 2024년 검증"이라는 시간 분할 하나를 비교 기준으로 고정했습니다.
• 하루 5회 제출 제한이라 제출 하나를 측정 1회로 취급했습니다. 리더보드 점수에서 보정 상수의 최적값을 역산하되, 추정에 계통 오차가 있는 것을 확인한 뒤로는 오차가 2배여도 손해가 안 나는 보수적 지점에 섰습니다. 실패한 제출도 직전과의 차이를 계산해 원인을 특정하는 식으로 정보를 회수했습니다.

담당3인 팀에서 모델 구조 설계와 학습⁠·⁠앙상블⁠·⁠검증⁠·⁠제출 전략을 맡았습니다. 야구 도메인 지식이 있는 팀원이 피처 발굴을 담당해, 도메인에서 나온 가설을 제가 모델 구조와 검증 설계로 옮기는 분업이었습니다. 팀원이 도메인 관점에서 낸 피처 후보는 기존 피처와 통계적으로 겹치는지 직교성 분석으로 걸러 채택했습니다.

4주 동안의 제출 138회는 근거와 결과를 전부 원장으로 남겼고, 채택 기준은 결과를 보기 전에 미리 등록해 두는 규율로 운영했습니다. 배포 모델은 학습 코드로 재학습했을 때 트리 잎값까지 동일하게 재현되는 것을 확인했습니다.

모델을 하나 더 얹는 것보다 무엇을 기준으로 결합하고 무엇으로 검증할지를 정하는 편이 점수를 갈랐습니다. 도메인을 아는 팀원이 낸 피처는 혼자였다면 나오지 않았을 것이라, 역할을 어떻게 나누느냐가 결과의 일부라는 것도 이 대회에서 확인했습니다.

1,082팀 중

49위

백분위

상위 약 4.5%

참가

2,403명

제출

138회

리더보드

문제 재정의같은 요청이라도 파일을 읽었는지, 테스트가 통과했는지에 따라 다음 행동이 달라집니다. 단순 문장 분류가 아니라 대화와 도구 사용으로 누적된 작업 상태를 추론하는 문제로 정의하고, 현재 요청과 과거 행동을 잇는 관계형 피처를 설계했습니다. 고전 ML과 Transformer 3종을 확률 블렌드로 앙상블했는데, 개별 점수보다 오류를 보완하는 조합이 성능을 갈랐습니다.

AI Agent 운영 하네스실험 실행은 Claude 에이전트에 맡기고 저는 전략⁠·⁠승인⁠·⁠제출을 맡았습니다. 하나의 에이전트에 전부 맡기자 단계 누락과 정보 혼선이 반복돼, 원인을 모델의 능력이 아니라 한 에이전트가 지는 책임과 컨텍스트가 너무 넓어진 작업 구조로 보고 다시 설계했습니다.

• 역할을 17개 서브에이전트로 분리하고(전략 수립 / 데이터⁠·⁠누수 감사 / 학습 설정 검증 / 실행 / 제출물 검증 / 기록), 각 에이전트에는 맡은 역할에 필요한 최소 정보만 넘겼습니다.
• 자연어 보고 대신 산출물로 검증했습니다. 실제 적용된 설정을 남기는 effective_config, 코드⁠·⁠데이터 SHA 대조, 제출물 자동 검사를 붙였고 실제로 학습 시작 전 결함을 2회 사전 차단했습니다.

한 에이전트의 실수가 전체 과정을 그대로 통과하기 어려운 구조가 됐습니다. AI Agent의 성능은 모델만이 아니라 역할⁠·⁠컨텍스트⁠·⁠권한⁠·⁠검증 구조를 어떻게 설계하느냐에도 달려 있다는 것을 배웠습니다.

베이스라인

0.43

최종 Macro-F1

0.7867

269팀 중

59위

참가

868명

회고 연구 일지 GitHub 리더보드

분업4인이 경량화 기법을 나눠 맡아 각자 연구했습니다. 팀원들이 프루닝과 디스틸레이션을 맡았고, 저는 양자화를 담당했습니다.

점수가 성능 50% + 속도 50%로 매겨져서 "어디까지 줄여도 성능이 버티는가"를 찾는 문제였습니다. GPTQ(llmcompressor)로 W4A16 양자화를 적용하고, 결과를 좌우하는 캘리브레이션 데이터 구성을 다섯 가지로 바꿔가며 비교했습니다. 같은 제출물인데도 점수가 0.1점 이상 흔들리는 것을 관측했고, 모델 개선과 별개로 측정 자체를 믿을 수 있는지 먼저 따져야 한다는 것을 이 대회에서 처음 겪었습니다.

GitHub 리더보드