Project Case Studies

실제 서비스를 개발하고 운영하며 경험한 프로젝트들입니다.

Projects from building and running real services.

각 프로젝트에서 맡았던 역할과 해결했던 문제들을 담았습니다.

Each one covers the role I took and the problems I solved.

01

Tosel Lab Platform

학습 콘텐츠 플랫폼Learning content platform

02

Business Model Refactoring

서비스 구조 개선Service architecture improvement

03

Tosel SSO

통합 유저 관리Integrated user management

04

Tosel 교재몰Tosel Book Mall

SCM / 쇼핑몰SCM / Commerce

05

CARD 24

카드 추천 서비스Card recommendation service

06

넥셀시스템 웹사이트 리뉴얼Nexel System Website Renewal

외주 / 웹 리뉴얼Outsourced / Web renewal

07

RAISE Lab Research

의료·환경 데이터 분석Medical & environmental data analysis

08

연세 사랑모아Yonsei SarangMoa

기부·나눔 플랫폼Donation & sharing platform

09

Adaptive LLM Router

LLM 하네스 비용 최적화LLM harness cost optimization

10

TalkieBridge

지식 공백 vs 추론 능력 실험Knowledge gap vs. reasoning

Tosel Lab Platform

20여년간 영어인증능력 시험제도를 통해 입지를 다진 TOSEL의 신규 학습컨텐츠 플랫폼입니다. 전국 학원들을 대상으로 심사과정을 거쳐 TOSEL Lab 지정교육기관을 선별하고, 선별된 지정교육기관과 해당 기관의 원생들을 대상으로 맞춤식 진단 데이터 공유 및 처방과 컨텐츠 제공을 통하여 해당 지정교육 기관의 원생들의 영어능력 성장을 돕도록 기획되었습니다.

2022년 8월 정식 출시된 서비스로, 개발부터 배포 및 운영까지 참여했습니다.
전국 교육기관과 학생들을 대상으로 제공된 실제 상용 서비스입니다.


서비스 초기 기획부터 개발, 소통 및 런칭까지 모든 프로세스에 주도적인 역할로 참여하였고 기존에 Monolothic한 시험 웹사이트에 모든 기능이 몰려있던 TOSEL 사이트 리뉴얼까지 고려하여 TOSEL Lab Main Web Site 및 4개의 Digital Contents가 포함된 Microservices Architecture 방식의 플랫폼으로 설계하였습니다.  

그럼 지금부터 제가 참여했던 TOSEL Lab Platform의 프로젝트들을 소개해드리겠습니다.

This is TOSEL's new learning content platform, built on 20 years of experience running an English proficiency test. Academies nationwide go through a screening process to become designated TOSEL Lab institutions, and the platform was designed to help their students grow by sharing personalized diagnostic data, prescriptions, and learning content.

It officially launched in August 2022, and I was involved from development through deployment and operations.
It was a real commercial service offered to educational institutions and students nationwide.


I took a leading role in every stage, from initial planning through development, communication, and launch. Considering the renewal of the existing monolithic TOSEL test website, where every feature was concentrated, I designed the platform with a Microservices Architecture made up of the TOSEL Lab main website and four digital contents.

Below are the TOSEL Lab Platform projects I worked on.

Sub Projects

TOSEL Lab Main website

  • TOSEL Lab 공식 홈페이지 — 지정교육기관과 원생들이 학습 콘텐츠를 이용하는 웹사이트.
  • 프론트엔드 서버 및 API 서버가 서로 다른 서브도메인에서 운영되는 환경에서, Cross-Origin 요청을 처리하기 위한 CORS 허용 정책 설정 및 API 연동.
  • 심사를 통과한 지정교육기관만 서비스를 이용할 수 있도록 구성하고, 14종의 사용자 유형에 따른 DB 설계 및 권한 관리 API 개발.
  • The official TOSEL Lab website — where designated institutions and their students use learning content.
  • Configured a CORS allow policy and API integration to handle cross-origin requests, as the frontend and API servers run on different subdomains.
  • Restricted the service to screened, designated institutions; designed the DB and built permission management APIs for 14 user types.
* 작업 내용* Work
프로젝트 기획,유저 플로우 설계, DB설계, 기능 API 개발, S2S 통신 Restful API 구축, 유저 권한관리(jwt 기반 토큰을 통한 유저접근권한 설정) Project planning, user flow design, DB design, feature APIs, S2S RESTful API, user permission management (JWT token-based access control)
* 사용 기술* Tech Stack
Frontend - HTML/ CSS/ JavaScript/ Jinja2/ jQuery Backend - Python, Flask Database – MariaDB
* 개발 기간* Period
2022.03-2022.06(3개월) 2022.03-2022.06 (3 months)
* 담당 인원* Team
Backend 2, Frontend 1, Designer 1

Monthly Test

  • 지정교육기관 원생이 매월 응시하는 월별고사 콘텐츠.
  • 시험 프로세스 기획, 다양한 형태·리소스에 대응하는 문항 DB 설계, 문항 레이아웃 및 타이머 설계.
  • Online/Offline 응시에 따라 이원화된 성적 처리·데이터 누적 과정을 업무 자동화 script로 해결.
  • A monthly exam taken by students of designated institutions.
  • Planned the exam process, designed a question DB for various formats and resources, and built question layouts and the timer.
  • Solved the split online/offline score processing and data accumulation with automation scripts.
* 작업 내용* Work
시험 프로세스 기획, 문항 DB설계, S2S 통신 Restful API 구축, 타이머 설계 Exam process planning, question DB design, S2S RESTful API, timer design
* 사용 기술* Tech Stack
Frontend - HTML/ CSS/ JavaScript/ Jinja2/ jQuery Backend - Python, Flask Database – MariaDB
* 개발 기간* Period
2022.05-2022.06.01(약 1개월) 2022.05-2022.06.01 (about 1 month)
* 담당 인원* Team
Backend 2, Frontend 1, Designer 1

Monthly Test - 성적처리 프로젝트

Monthly Test - Score Processing

  • Monthly Test 성적 처리 프로젝트.
  • 학교·지역·학원별 평균과 응시자 선택 답안을 추적하기 쉽도록 성적 DB 기획 및 설계.
  • Offline 응시 대응을 위해 여러 업체와 협의해 자체 프로그램에 맞는 OMR 제작.
  • OCR로 OMR 데이터 로딩 → 오답 정정 → 엑셀 변환 → 자동화 script로 성적 DB 적재.
  • Score processing for Monthly Test.
  • Designed the score DB to easily track school, region, and academy averages and each taker's chosen answers.
  • Worked with vendors to produce OMR sheets that fit our program for offline test takers.
  • Read OMR data with OCR → correct errors → convert to Excel → load into the score DB via automation script.
* 작업 내용* Work
OCR을 이용한 오답정정 프로그램 구현 ,OCR을 이용한 Offline OMR 데이터 로딩 및 엑셀파일화 프로세스 정립,엑셀파일의 DB 삽입 자동화 script 구현, 성적처리 프로세스 정립 및 알고리즘 구현 OCR-based error-correction program, process for loading offline OMR data via OCR into Excel files, automation script for inserting Excel files into the DB, score processing workflow and algorithm
* 사용 기술* Tech Stack
Backend - Python, Flask,openCV,pymySQL,pytesseract Database – MariaDB
* 개발 기간* Period
2022.05-2022.06.01(약 1개월) 2022.05-2022.06.01 (about 1 month)
* 담당 인원* Team
Backend 2

Monthly Test - 성적자료 프로젝트

Monthly Test - Score Report

  • Monthly Test 성적표 프로젝트.
  • 진단·처방을 위해 지역·학교·학원별 평균과 미국 학생 독서 지수(AR/Lexile) 비교표를 포함하도록 기획.
  • 평균 비교·AR/Lexile 산출 알고리즘, 개인/전체 평균 성적 DB 및 데이터 로딩 알고리즘 구현.
  • 짧은 일정으로 Publishing/Frontend까지 담당하며 chart.js 등 시각화 경험 확보.
  • Score report for Monthly Test.
  • Included region, school, and academy averages plus an AR/Lexile comparison for diagnosis and prescription.
  • Built the average comparison and AR/Lexile algorithms, the individual/overall score DB, and data loading.
  • Tight deadline, so I also handled publishing/frontend and gained charting experience with chart.js.
* 작업 내용* Work
성적 DB설계, S2S 통신 Restful API 구축, 성적데이터 로딩 알고리즘 구현, 일부 프론트 화면 구현 Score DB design, S2S RESTful API, score data loading algorithm, part of the frontend screens
* 사용 기술* Tech Stack
Frontend - HTML/ CSS/ JavaScript/ Jinja2/ jQuery Backend - Python, Flask Database – MariaDB
* 개발 기간* Period
2022.05.23-2022.06.01(약 7일) 2022.05.23-2022.06.01 (about 7 days)
* 담당 인원* Team
Backend1, Frontend 1

Placement Test

  • 학원 신규 원생의 학습 레벨을 평가하는 반 배치고사 콘텐츠.
  • 응시자의 답변에 따라 다음 문항의 난이도가 달라지는 Adaptive-Test 형태로 기획.
  • Classification 알고리즘을 통해 유기적으로 출제된 다양한 문항의 정답 여부를 통계화하고 분야별 레벨 설정 구현.
  • A placement test that finds the right level for new academy students.
  • Planned as an adaptive test: the next question's difficulty changes with the taker's answers.
  • Built a classification algorithm that turns served questions and results into statistics and sets a level per skill area.
* 작업 내용* Work
프로젝트 기획 참여, 문항 DB설계, S2S 통신 API 구축, 문항출제 알고리즘 구현 Project planning, question DB design, S2S API, question selection algorithm
* 사용 기술* Tech Stack
Frontend - HTML/ CSS/ JavaScript/ Jinja2/ jQuery Backend - Python, Flask Database – MariaDB
* 개발 기간* Period
2022.04-2022.05(1개월) 2022.04-2022.05 (1 month)
* 담당 인원* Team
Backend 2, Frontend 1, Designer 1

Daily Study (Self Study)

  • 매일 문제풀이로 자기주도 학습 습관을 기르는 일일 학습 콘텐츠.
  • 주 단위 문제 제공, 풀이 중 중간 저장, 풀이 후 원장·학생 양측 오답 확인 기능 구현.
  • 레벨·카테고리별 문항 DB 설계, 문제 레이아웃, 오답 확인 API 구축.
  • 원장이 원생의 학습 현황을 확인하는 S2S API 구축.
  • A daily study content that builds self-directed study habits.
  • Weekly question sets, mid-session save, and wrong-answer review for both students and directors.
  • Designed question DBs by level and category, built question layouts and the wrong-answer review API.
  • Built the S2S API that lets directors check their students' progress.
* 작업 내용* Work
프로젝트 기획, DB설계(문항DB, 학생 로그 DB),문제 레이아웃 작업, 오답확인 API구축, S2S 통신 API 구축 Project planning, DB design (question DB, student log DB), question layouts, wrong-answer review API, S2S API
* 사용 기술* Tech Stack
Frontend - HTML/ CSS/ JavaScript/ Jinja2/ jQuery Backend - Python, Flask Database – MariaDB
* 개발 기간* Period
2022.05-2022.06(1개월) 2022.05-2022.06 (1 month)
* 담당 인원* Team
Backend 2 , Frontend 1, Designer 1

Voca Quiz

  • 원생의 단어 학습을 위한 단어 퀴즈 콘텐츠.
  • 랜덤 문항 출제 알고리즘 설계·개발, 문항 및 풀이 DB 설계.
  • 본인 정답률과 전체 정답률 기반의 개인 맞춤 오답노트 알고리즘 설계.
  • 단어 길이에 따라 달라지는 레이아웃 설계로 프론트엔드 협업 경험.
  • A vocabulary quiz content for students.
  • Designed and built the random question algorithm and the question/quiz DB.
  • Designed a personalized wrong-answer note algorithm based on personal and overall accuracy.
  • Designed layouts that adapt to word length, collaborating closely with frontend.
* 작업 내용* Work
프로젝트 기획, DB설계 및 수정, S2S 통신 Restful API 구축, 랜덤 글자길이 레이아웃 배치 설계, 문항 및 오답노트 API 알고리즘 설계, API구축 Project planning, DB design and revision, S2S RESTful API, layouts for random word lengths, question and wrong-answer note API algorithms, API development
* 사용 기술* Tech Stack
Frontend - HTML/ CSS/ JavaScript/ Jinja2/ jQuery Backend - Python, Flask Database – MariaDB
* 개발 기간* Period
2022.05.23-2022.06.01(약 2주) 2022.05.23-2022.06.01 (about 2 weeks)
* 담당 인원* Team
Backend2, Frontend 1, Designer 1

Business Model Refactoring

TOSEL Business Process Model을 Microservices Architecture 기반으로 재설계한 프로젝트입니다.

Remodeling TOSEL's Business Process Model on a Microservices Architecture.

배경

Background

  • 기존 TOSEL 웹사이트는 시험 접수·변경·성적 확인을 제공하는 응시자 중심 서비스 플랫폼.
  • 포스트 코로나 시대에 영어 학습 콘텐츠 사업(TOSEL Lab)을 새로 런칭하며 서비스 확장이 필요.
  • 하지만 기존 사이트에 확장 서비스를 붙이기엔 구조적 문제가 많았음.
  • The existing TOSEL website was a test-taker platform for registration, changes, and score checks.
  • Post-COVID, TOSEL launched a learning content business (TOSEL Lab) and needed to expand its services.
  • But the existing site had too many structural problems to extend.

문제점

Problems

  • 노후화된 코드 — 10년간 유지보수만 진행, 낮은 JDK 버전으로 https 기반 API 호출 불가.
  • 정규화되지 않은 DB — 임시로 덧붙인 구조로 중복·쓰레기 데이터가 쌓여 무결성 미보장.
  • 서비스 혼재 — 타깃 유저가 다른 서비스가 Monolithic 구조에 섞여 사용·관리(Admin/ERP)가 어려움.
  • Outdated code — only maintained for 10 years; an old JDK blocked HTTPS-based API calls.
  • Unnormalized DB — ad-hoc structures piled up duplicate and garbage data, breaking integrity.
  • Mixed services — services for different users were tangled in a monolith, hard to use and manage (Admin/ERP).

해결 및 역할

Solution & Role

  • 기존 시험 사이트 전면 리뉴얼 + 신규 학습 콘텐츠 사이트를 Microservices Architecture로 설계.
  • TOSEL Lab과 같은 기간에 진행하며 모든 기획·리팩토링 계획에 참여.
  • 기존 구조의 한계를 분석하고 효율적인 아키텍처를 설계하는 경험 확보.
  • Fully renewed the test site and designed the new learning sites on a Microservices Architecture.
  • Ran alongside TOSEL Lab; took part in all planning and refactoring decisions.
  • Learned to analyze structural limits and design a more efficient architecture.

기간: 2022.03 ~ 2022.06 · 인원: Backend 2, Frontend 1, Designer 1Period: 2022.03 ~ 2022.06 · Team: Backend 2, Frontend 1, Designer 1

Tosel SSO

# Tosel SSO project

  • 서비스 간 학습-평가-분석 사이클을 연결하고 데이터를 공유하기 위한 통합 유저 관리 서비스.
  • SSO에서 JWT 쿠키를 발급해 로그인 여부와 데이터 접근 권한 관리, 타 도메인 연계를 위해 CORS 기반으로 개발.
  • refresh-token — 로그인 상태 유지, 만료 전 주기적으로 갱신.
  • access-token — refresh-token으로 발급, 지정 권한 내 데이터 요청, 연장 불가.
  • 서비스 간 정보를 제공하는 S2S Restful API 구축 담당.
  • 모든 서비스의 공통 회원 정보를 먼저 파악한 뒤 통합 회원 DB를 설계해야 함을 체감.
  • An integrated user management service that links the learn-assess-analyze cycle and shares data across services.
  • SSO issues JWT cookies to manage login and data access; built on CORS to connect with other domains.
  • refresh-token — keeps the login alive, renewed periodically before expiry.
  • access-token — issued via the refresh-token, grants scoped data access, cannot be extended.
  • Built the S2S RESTful APIs that serve information between services.
  • Learned that the integrated member DB must start from the shared member data every service needs.

기간: 2022.04 ~ 2022.05 · 인원: Backend 2Period: 2022.04 ~ 2022.05 · Team: Backend 2

Tosel 교재몰 (SCM)

Tosel Book Mall (SCM)

공급망관리시스템(SCM)과 쇼핑몰 역할을 함께 하는 TOSEL 교재몰입니다.

TOSEL Book Mall, working as both a Supply Chain Management system (SCM) and an online shop.

왜 SCM으로 기획했나

Why SCM

  • 초판/증쇄/개정/재고 상태 등 교재 특성상 현황 관리와 트래킹 필요.
  • 일반회원·지역본부·총판 등 4종 유저별로 기능과 화면이 달라야 함.
  • 총판·지역본부는 주문 규모가 커서 증쇄 여부 판단이 필요.
  • 전화·팩스·이메일·메신저로 제각각이던 주문 방식을 통합할 필요.
  • 엑셀 수기 관리로 금액·재고 불일치가 잦아 자동화 시스템이 절실.
  • Textbooks need tracking of editions, reprints, revisions, and stock status.
  • Four user types (general members, regional offices, distributors, etc.) need different features and views.
  • Distributors and regional offices order in bulk, so reprint decisions are needed.
  • Orders came in by phone, fax, email, and messenger and needed one system.
  • Manual Excel management caused price and stock mismatches; automation was essential.

역할

Role

  • 웹/모바일 대응, 프로젝트 기획·유저 플로우·와이어프레임 설계.
  • 교재 DB 설계, 유저별 권한 관리 시스템, S2S API, 메인·상세 페이지 구축.
  • 기존 사업 구조를 빠르게 파악해 필요한 기능을 정의하고 개발하는 역량 향상.
  • Web and mobile support; project planning, user flows, and wireframes.
  • Book DB design, per-user permission system, S2S APIs, main and detail pages.
  • Improved at quickly learning an existing business and defining the features it needs.

기간: 2022.01 ~ 2022.04 · 인원: Backend 2, Frontend 1, Designer 1Period: 2022.01 ~ 2022.04 · Team: Backend 2, Frontend 1, Designer 1

CARD 24 : 카드/카드사 추천 웹사이트

CARD 24 : Card / Card Issuer Recommendation Website

유저 조건에 맞는 카드와 카드사를 추천하는 웹사이트입니다.

A website that recommends cards and card issuers that fit each user's conditions.

구현

Implementation

  • 웹 개발 학습 후 처음 진행한 팀 프로젝트 (Monolithic Architecture).
  • Spring Boot MVC 2 패턴, Spring Security로 http 보안, OAuth2 로그인.
  • Metadata 기반 사용자 조건별 카드·카드사 추천 알고리즘, 혜택별 비교, 문의 게시판.
  • AWS EC2 배포 (RDS-MariaDB).
  • My first team project after learning web development (Monolithic Architecture).
  • Spring Boot MVC 2 pattern, HTTP security with Spring Security, OAuth2 login.
  • Metadata-based card/issuer recommendation algorithm, benefit comparison, inquiry board.
  • Deployed on AWS EC2 (RDS-MariaDB).

극복한 점

What I overcame

  • MVC 2 패턴과 어노테이션 개념이 낯설어 협업 인계에 큰 부담.
  • 콘솔 CRUD 게시판, JavaFX 키오스크 등 MVC 미니 프로젝트로 따로 연습해 극복하고 프로젝트 완수.
  • The MVC 2 pattern and annotations were new, and handing my part off to a teammate felt like heavy pressure.
  • Practiced with MVC mini projects (console CRUD board, JavaFX kiosk) on my own time and finished the project.

시연 영상Demo: YouTube · GitHub: lkh599810/CARD24_Project

기간: 2021.05 ~ 2021.06 · 인원: 2Period: 2021.05 ~ 2021.06 · Team: 2

넥셀시스템 웹사이트 리뉴얼 (외주)

Nexel System Website Renewal (Outsourced)

노후화된 기업 웹사이트를 전면 리뉴얼한 외주 프로젝트입니다.

An outsourced project to fully renew an aging corporate website.

주요 업무

Key Work

  • 기존 웹사이트 전체 레이아웃 재정비 및 신규 페이지 구축.
  • 디자인 요소 및 인터랙션 개선을 통한 UI/UX 고도화.
  • 기존 노후 DB 분석 및 Front-end 기반 정적 데이터 처리 구조로 재설계.
  • PHP 기반 레거시 서버 코드 리팩토링 — 불필요한 의존성 제거, 코드 모듈화, 로직 재구성.
  • 경량화 및 최적화를 통한 웹사이트 응답 속도 개선.
  • Reorganized the entire site layout and built new pages.
  • Enhanced UI/UX by improving design elements and interactions.
  • Analyzed the aging DB and redesigned it as a front-end based static data structure.
  • Refactored legacy PHP server code — removed unneeded dependencies, modularized code, restructured logic.
  • Improved response speed through lightweighting and optimization.

기간: 2025.02 ~ 2025.06 · 이미지: 리뉴얼 전 / 후Period: 2025.02 ~ 2025.06 · Images: before / after renewal

연세대학교 미래캠퍼스 RAISE Lab (학부연구생)

RAISE Lab, Yonsei University Mirae Campus (Undergraduate Researcher)

의료·환경 데이터 기반 통계 분석 및 머신러닝 연구를 진행하고 있습니다.

Statistical analysis and machine learning research on medical and environmental data.

남성 생식건강–환경인자 연관성 분석

Male Reproductive Health vs. Environmental Factors

  • 2018~2024 정액검사 데이터와 대기오염·기상요인 연관성 분석, 데이터셋 구축.
  • OLS, Ridge, Lasso, Decision Tree, Random Forest, XGBoost, GPBoost 모델 비교, 교차검증, Optuna 하이퍼파라미터 최적화, SHAP 변수 중요도 분석.
  • 반복측정 의료데이터 모델링: GEE, GLMM, LMM 및 GPBoost, BiMM 기반 예측 성능 비교, 환자 ID 랜덤효과·나이·계절·COVID-19 교란변수 보정 (R, Python).
  • Analyzed links between 2018–2024 semen test data and air pollution / weather factors, and built the dataset.
  • Compared OLS, Ridge, Lasso, Decision Tree, Random Forest, XGBoost, and GPBoost with cross-validation, Optuna hyperparameter tuning, and SHAP feature importance.
  • Repeated-measures modeling: compared GEE, GLMM, LMM, GPBoost, and BiMM, adjusting for patient ID random effects, age, season, and COVID-19 (R, Python).

부인과질환–환경인자 연관성 분석

Gynecologic Disease vs. Environmental Factors

  • HIRA 건강보험 데이터 전처리 및 통합.
  • Negative Binomial Regression 발생률 모델링 (연도 고정효과, 인구수 Offset, Cluster-Robust SE).
  • Preprocessed and merged HIRA national health insurance data.
  • Modeled incidence with Negative Binomial Regression (year fixed effects, population offset, cluster-robust SE).

기간: 2025.09 ~ 현재Period: 2025.09 ~ Present

연세 사랑모아 : 교내 기부·나눔 플랫폼

Yonsei SarangMoa : Campus Donation & Sharing Platform

연세대학교 구성원이 안 쓰는 물품을 기부하고, 판매 수익금으로 나눔을 실천하는 웹 플랫폼입니다.

A web platform where Yonsei members donate unused items, and sales proceeds fund campus and community causes.

서비스

Service

  • 학생·교직원이 물품을 기부하면 저렴하게 판매하고, 수익금은 교내외 봉사단체 및 프로젝트 지원에 사용.
  • 기부자에게 마일리지를 적립해 이벤트 상품으로 교환.
  • 자원봉사자 모집 및 봉사점수·봉사활동 확인서 발급.
  • Items donated by students and staff are sold at low prices; proceeds support volunteer groups and projects.
  • Donors earn mileage to exchange for event rewards.
  • Recruits volunteers and issues volunteer points and certificates.

주요 구현

Key Features

  • 세션 기반 로그인·회원가입, 재학증명서 이미지 업로드를 통한 가입 인증.
  • 권한 등급별 접근 제어 — 미승인·승인 회원·관리자 3단계 권한을 설계해, 재학증명서 검증 후 관리자 승인을 받은 회원만 구매 가능하고 관리자 메뉴는 관리자 등급에만 노출.
  • 기부 물품 상태 관리 워크플로우 — 신청 → 승인/반려 → 판매 완료 → 삭제로 이어지는 상태 전이를 설계하고, 승인·반려 취소 시 신청 상태로 되돌리는 관리자 검수 프로세스 구현.
  • 공지사항·이벤트·좋은 사례 게시물 CRUD 관리 기능.
  • 카테고리별 상품 조회 및 페이지네이션 JSON API (AJAX 연동).
  • 결제 처리 — 구매 내역 저장 및 판매 완료 상태 변경, 마일리지 잔액 검증 후 차감하는 이벤트 응모.
  • 기부 신청(물품 이미지 업로드), 마이페이지 구매·기부 내역, 봉사활동 확인서 발급 페이지.
  • Session-based login and sign-up, verified with an uploaded enrollment certificate image.
  • Role-based access control — designed three permission levels (pending, approved member, admin); only members verified by enrollment certificate and approved by an admin can purchase, and admin menus are shown to admins only.
  • Donated item status workflow — designed the state flow (requested → approved/rejected → sold → deleted) with an admin review process that can roll approvals or rejections back to requested.
  • CRUD management for notices, events, and good-example posts.
  • JSON API for category-filtered, paginated item listing (used via AJAX).
  • Payment handling — saves purchases and marks items sold; event entry that checks and deducts mileage.
  • Donation form with item image upload, my page with purchase/donation history, and volunteer certificate page.

Django, SQLite, jQuery

기간: 2024.11 ~ 2024.12 · 학교 프로젝트Period: 2024.11 ~ 2024.12 · University project

Adaptive LLM Router : Laya 기반 LLM 하네스 비용 최적화

Adaptive LLM Router : Cutting LLM Harness Cost with Laya

LLM 코드 리뷰 하네스에 Laya decision model을 라우터로 붙여, 필요한 검사만 호출했을 때 API 비용이 얼마나 줄어드는지 측정한 프로젝트입니다.

I added the Laya decision model as a router in front of an LLM code review harness and measured how much API cost drops when only the needed checks are called.

배경

Background

  • 기존 하네스는 커밋마다 일관성(CA)·보안(VA)·형식(FA) 세 가지 LLM 검사를 항상 고성능 모델로 전부 호출해 비용과 시간이 큼.
  • 하네스 앞단에 의사결정 단계를 두어 커밋별로 필요한 검사와 모델 크기만 고르도록 설계.
  • The original harness always ran all three LLM checks (consistency CA, security VA, format FA) on a strong model for every commit, which was costly and slow.
  • Added a decision step in front of the harness to pick only the checks and model size each commit needs.

구현

Implementation

  • Laya decision model을 하네스의 라우터로 통합 — 로컬 CPU에서 보안·형식 검토 필요 여부를 판단해 라우터 자체의 API 비용은 0.
  • 확신도 0.7 미만이면 검사를 실행하는 보수적 규칙과, 변경 줄 수 기반 모델 선택(5줄 이하 small / 6줄 이상 strong).
  • 라우터 칸만 교체되는 구조로 설계해 기존 하네스 · 규칙 기반 · Laya 2종 · 소형 LLM 라우터 5개 조건을 같은 조건에서 비교.
  • LLM 출력 비결정성에 대응해 리뷰 결과 240개와 라우터 판단을 캐시, 재실행 시 동일 결과 보장.
  • 공개 커밋 40건을 직접 라벨링해 정답률 · F1 · 보안 검토 누락으로 채점.
  • Integrated the Laya decision model as the harness router — it runs on local CPU to decide if security/format checks are needed, so the router itself adds no API cost.
  • Conservative rule (run the check when confidence is below 0.7) and model tier by lines changed (≤5 small / ≥6 strong).
  • Designed a swappable router slot to compare five conditions under the same setup: original harness, rule-based, two Laya variants, small LLM router.
  • Cached 240 review results and router decisions to handle LLM non-determinism, so reruns give identical results.
  • Hand-labeled 40 public commits to score accuracy, F1, and missed security reviews.

결과

Results

  • 기존 하네스 대비 API 비용 40.4~42.1% 절감, 리뷰어 호출 14.2~18.3% 감소 (v1 기준 $0.5534 → $0.3203).
  • 보안 검토 대상 9건은 모두 보안 검토 배정 유지.
  • CA 정답률 97.5% → 92.5%, 처리 시간 증가 등 비용과 성능 사이의 교환관계를 정량화.
  • Cut API cost by 40.4–42.1% and reviewer calls by 14.2–18.3% vs. the original harness (v1: $0.5534 → $0.3203).
  • All 9 security-relevant commits still got a security review.
  • Quantified the trade-off: CA accuracy 97.5% → 92.5% and longer processing time.

Python, Claude API, Laya

TalkieBridge : 1930년의 언어 모델은 몰라서 틀릴까, 못 해서 틀릴까

TalkieBridge : Does a 1930 Language Model Fail Because It Can't Reason, or Because It Doesn't Know?

사전 학습 지식의 시대적 한계가 LLM의 응답 성능에 미치는 영향을 탐구한 프로젝트입니다. 1930년 이전 텍스트로만 학습된 Talkie-1930에게 현대 개념을 과거에도 이해 가능한 기능적 표현으로 바꿔 물었을 때, 응답 정확도와 품질이 어떻게 달라지는지 실험했습니다.

A project exploring how the time-bound limits of pre-trained knowledge affect LLM answers. I asked Talkie-1930, a model trained only on pre-1931 text, about modern concepts rewritten as functional descriptions it could understand, and measured how answer accuracy and quality changed.

문제의식

Question

  • Talkie에게 GPS의 쓸모를 물으면 GPS를 눈으로 보는 방향 계기처럼 설명함. 질문은 이해했지만 단어를 모르는 상황.
  • 모르는 현대 개념을 이미 아는 기초 개념으로 분해해 주면(GPS → "멀리 있는 송신기의 신호 시간을 비교해 위치를 추정하는 방법"), 모델이 과거에 학습한 전기 · 통신 · 기계 지식을 조합해 추론할 수 있는지 확인하고자 함.
  • Asked what GPS is useful for, Talkie describes a direction instrument you look at. It understood the question but not the word.
  • If an unknown modern concept is broken down into basic ones it already knows (GPS → "compares timed signals from distant transmitters to estimate position"), can the model combine its older knowledge of electricity, communication and machinery to reason?

실험

Experiment

  • 모델은 그대로 두고 질문만 바꾸는 전처리 계층 구현 — 용어 탐지 → 기능 설명 연결 → 문장 재작성 → 검증.
  • 6개 분야 100문항, 현대 용어 사전 141개 · 기능 설명 사전 100개 구축.
  • 효과의 원인을 가리기 위해 원문 · 사전 치환 · 길이만 맞춘 대조군 · 전체 파이프라인 · 검증 생략 5개 조건을 같은 문항으로 비교.
  • 객관식 정확도와, 조건명을 숨기고 A/B 순서를 섞은 서술형 블라인드 비교(LLM Judge) 두 가지로 평가.
  • Talkie 웹 API가 부하 시 응답을 거부해 정확도가 0으로 나오던 문제 — 수집 실패와 무효 응답을 분리 기록하고 재시도 · 응답 캐시 · 프롬프트 해시 검증 추가.
  • Built a preprocessing layer that changes only the question, not the model — term detection → description mapping → rewrite → validation.
  • 100 questions across 6 domains, a 141-entry modern term dictionary and 100 functional descriptions.
  • Compared five conditions on the same questions to isolate the cause: raw, dictionary only, length-matched control, full pipeline, no validator.
  • Evaluated with multiple-choice accuracy and blind open-ended comparison by an LLM judge (condition names hidden, A/B order shuffled).
  • The Talkie web API rejected requests under load and accuracy came out as 0 — logged collection failures apart from invalid answers and added retries, a response cache and prompt hash checks.

결과

Results

  • 객관식 정확도 개선은 확인되지 않았지만, 서술형 응답에서는 원본 질문보다 높은 품질 평가를 받음.
  • 객관식 100문항에서는 변환해도 정확도 개선 없음 (원문 21%, 변환 19%, 모든 조건이 무작위 기준 25% 아래).
  • 서술형에서는 변환한 질문이 원문에 79승 18패 3무, 길이만 맞춘 대조군에도 88승 11패로 앞섬 (p<0.001).
  • 단순 사전 치환보다 낫지는 않았음 (45승 51패) — 효과는 용어를 기능으로 풀어 쓰는 것 자체에서 나옴.
  • No multiple-choice accuracy gain, but open-ended answers were rated higher than for the original questions.
  • Multiple choice: no accuracy gain from rewriting (raw 21%, rewritten 19%; every condition below the 25% random baseline).
  • Open-ended: rewritten questions beat raw 79–18 (3 ties) and the length control 88–11 (p<0.001).
  • No better than plain dictionary substitution (45–51) — the gain comes from spelling out the function itself.

결론

Takeaway

  • 이를 통해 모델 자체를 재학습하지 않고도 입력 표현을 재구성하여 지식 격차의 일부를 완화할 가능성을 관찰.
  • 다만 순수 추론 능력이 입증되거나 지식 부족과 추론 부족이 완전히 분리됐다고는 볼 수 없으며, 서술형 평가가 LLM Judge에 의존한다는 한계가 있음.
  • Observed that restructuring only the input, with no retraining, can partly close the knowledge gap of a knowledge-limited LLM.
  • This does not prove pure reasoning ability or fully separate missing knowledge from missing reasoning, and the open-ended scores rely on an LLM judge.

Python, OpenAI API, Talkie-1930

학교 프로젝트 · 기계학습개론University project · Intro to Machine Learning