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

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

구현Python 크롤러가 70개 사이트를 수집해 FastAPI·SQLite에 적재하고, Next.js에서 출처·카테고리로 탐색합니다. 질문하면 관련 공지를 근거로 답하는 RAG 챗봇을 붙였고, AWS Lightsail에 Docker로 배포해 운영하고 있습니다.

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

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

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

현재교내 구성원이 활발히 사용하고 있습니다. 최근 30일 방문자 782명, 페이지뷰 2,019회(Vercel Analytics, 2026.07). 유입 대부분이 교내 커뮤니티(에브리타임)를 통해 들어오며, AWS Lightsail 단일 서버에서 운영 중입니다. 위 결정들의 과정은 모두 블로그에 기록해 두었습니다.

최근 30일 방문자

782

수집 사이트

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로 확장했습니다. 프로젝트 전 과정을 디자이너·백엔드 개발자와 협업하며 기획·UX·프론트엔드 구현을 주도했습니다.

서비스 열어보기 GitHub

문제 재정의같은 요청이라도 파일을 읽었는지, 테스트가 통과했는지에 따라 에이전트의 다음 행동이 달라집니다. 단순 문장 분류가 아니라 대화와 도구 사용으로 누적된 작업 상태를 추론하는 문제로 정의하고, 현재 요청과 과거 행동을 잇는 관계형 피처를 설계했습니다.

• 고전 ML(TF-IDF → HGB·LR·ComplementNB)과 Transformer 3종을 확률 블렌드로 앙상블했습니다. 개별 점수보다 오류를 보완하는 조합이 성능을 갈랐습니다.
• history 복원 증강에서 시점 정합성·중복 문제를 검증하고, 신뢰 가능한 데이터만 2단계 학습(사전학습 → fine-tuning)에 사용했습니다.

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

• 역할을 17개 서브에이전트로 분리했습니다. 전략 수립, 데이터·누수 감사, 학습 설정 검증, 승인된 작업 실행, 제출물 검증, 기록으로 나눴고, 각 에이전트에는 프로젝트 전체가 아니라 맡은 역할에 필요한 최소 정보만 넘겼습니다.
• 자연어 보고 대신 산출물로 검증했습니다. 실행에 실제로 적용된 설정을 남기는 effective_config, 코드·데이터 SHA 대조, 제출 ZIP 구조 자동 검사, 5행 end-to-end 추론 테스트를 붙였습니다.
• 검증 통과와 실행 권한을 분리했습니다. 감사 통과는 '진행 자격'일 뿐이고, 실제 실행 권한은 사전 승인된 캠페인 범위 안에서만 나오도록 상태기계로 고정했습니다.
• 사고가 날 때마다 규칙으로 편입하는 루프로 운영했고, 실제로 학습 시작 전 결함을 2회 사전 차단했습니다. 다른 모델(Codex)로 교차 감사한 건은 내부 검증을 4회 통과한 결함을 잡아내기도 했습니다.

모든 실수가 사라지진 않았지만 한 에이전트의 실수가 전체 과정을 그대로 통과하기 어려운 구조가 됐고, 문제가 생겼을 때 어느 단계에서 어긋났는지 찾기 쉬워졌습니다. AI Agent의 성능은 모델만이 아니라 역할·컨텍스트·권한·검증 구조를 어떻게 설계하느냐에도 달려 있다는 걸 배웠습니다.

Baseline

0.43

최종 Macro-F1

0.7867

예선

상위 10%

회고 연구 일지 GitHub 리더보드