ye.A PERSONAL WORKSPACE

KIM YECHAN / AI SERVICE BACKEND

서비스를 만들고,
그 다음을 생각합니다.

AI 기능을 실제 서비스로 연결하는
Python 백엔드 개발자입니다.

김예찬 Python · FastAPI · Azure

ye. / PERSONAL TERMINAL

yechan@workspace:~$ ls projects/

장부미

PaddleOCR 영수증 인식과 Azure 배포·운영을 연결했습니다.

프로젝트 열기 ↵
MODEL / YE—01
SCROLL TO EXPLORE프로젝트 영역으로 이동

SELECTED WORK / 2026

만들고, 연결하고,
다시 살펴본 일들.

어떤 기능을 만들었는지보다
왜 그렇게 만들었는지까지 담았습니다.

01 / BUILD & DEPLOY
FastAPI 백엔드 전환과 앱·OCR 분리 배포 구성

장부미AI 필요경비 사전진단 서비스

PaddleOCR 기능 개발 · Azure 배포 자동화 · FastAPI 전환

상세 보기
PythonFastAPIPostgreSQLDockerGitHub ActionsAzure

발견한 문제

기존 팀에 합류해 보니 코드의 역할을 파악하기 어렵고, 서로 다른 구조로 개발한 결과를 합치는 데 부담이 있었습니다. 팀이 유지보수할 수 있는 기준이 필요했습니다.

제가 한 선택

팀이 익숙한 Python·FastAPI로 백엔드를 전환했습니다. 폴더 구조와 브랜치·PR 규칙을 정리하고, Pydantic·OpenAPI 기반 타입 검증과 CI/CD를 구성했습니다.

확인한 결과

기능 담당자와 함께 배포된 서비스에서 여러 영수증과 기능을 시험했습니다. 팀원들로부터 병합 부담이 줄고 맡은 부분을 더 안심하고 개발할 수 있다는 피드백을 받았습니다.

팀이 이해할 수 있는 기술을 선택했습니다.

Node.js 자체의 한계보다는 팀의 숙련도에 주목했습니다. 모두 Python을 학습했고 FastAPI에 익숙했으며, 팀원이 개발 중인 PaddleOCR도 Python 기반이었습니다. 기존 화면과 API 동작, PostgreSQL 데이터의 호환성을 유지하는 조건으로 전환했습니다.

배포 성공 이후의 동작까지 확인했습니다.

인증·환경변수·워크플로 오류를 하나씩 이해하며 수정했습니다. Docker·GHCR 기반 OCR 사이드카를 별도로 배포하고, GitHub Actions의 테스트·빌드·배포 후 상태 확인을 연결했습니다. 최종적으로 직접 서비스를 사용하며 담당 개발자와 동작 의도와 응답 속도를 확인했습니다.

기존 팀 프로젝트에 합류해 수행한 구조 개선·배포 작업입니다. 서비스 전체 기능을 단독 개발한 것은 아닙니다.

03 / DATA & MODEL
사용자 입력이 FastAPI, Azure ML, 요금 계산을 거쳐 리포트로 돌아오는 찌릿 서비스 전체 구조01 팀 서비스 전체 구조데이터 한계 파악부터 입력 설계, 피처 엔지니어링, 알고리즘 선정, 평가와 범위 조정까지 이어지는 김예찬의 머신러닝 설계 과정02 김예찬 · Machine Learning 기여

찌릿1인 가구 전력 사용량 예측

데이터 분석부터 입력 피처·회귀 모델 설계까지

상세 보기
NumPypandasAzure ML DesignerFeature EngineeringBoosted Decision Tree

데이터의 한계에서 시작

월별 전력 데이터에는 에어컨·집 구조·생활패턴 정보가 없었습니다. 월별 분포를 분석해 냉난방 영향이 적은 5월의 중앙값 115kWh를 기본 사용량의 대리값으로 정했습니다.

서비스 입력을 피처로 변환

에어컨 사용시간을 ‘115 + 사용시간 × 0.65kW × 30일 × 0.60’으로 변환해 전년 사용량 입력을 대신할 추정값을 구성했습니다. 월은 sin·cos로 변환하고 온도·습도로 불쾌지수 THI를 만들었습니다.

비선형 회귀 모델 선택

온도와 습도 조건이 겹칠 때 전력 사용량이 급격히 달라지는 특성을 고려해 Azure ML Designer의 Boosted Decision Tree Regression을 선택했습니다. 현재 사용량은 입력 피처가 아니라 모델의 예측 대상입니다.

낮은 오차와 서비스 대상 범위를 함께 검토했습니다.

300kWh 초과 데이터를 제외한 모델은 MAE와 RMSE가 낮아졌지만, 고사용량 1인 가구를 학습 대상에서 빼게 됩니다. 해당 사용자도 서비스 대상이라고 판단해 상한을 500kWh까지 확대하고 세 평가 지표를 함께 확인했습니다.

최종 발표자료의 단계별 평가 결과
단계MAERMSE
THI 포함 기준 모델31.38645.2830.7130
300kWh 초과 제외 · 팀원30.38542.6570.7086
500kWh까지 확대 · 본인32.79648.2770.7424

각 단계는 학습 데이터 범위가 다르므로 동일 조건의 성능 개선으로 단정하지 않습니다. 최종 R²는 0.7424이며, 500kWh 구간의 예측 정확도를 별도로 입증한 수치는 아닙니다.

THE PERSON BEHIND THE WORK

만드는 이유까지
이해하고 싶습니다.

응용소프트웨어를 전공하며 Python 백엔드와 클라우드 배포를 경험하고 있습니다. 주어진 기능을 구현하면서도 실제로 사용할 사람과 다음에 코드를 읽을 동료의 입장을 함께 생각합니다.

모르는 문제는 질문하고, 처리 흐름을 이해하고, 직접 결과를 확인합니다. 데이터의 기준을 바꾸거나 협업 절차를 만드는 일도 개발의 일부라고 생각합니다.

한양사이버대학교 응용소프트웨어공학과 재학
청년취업사관학교 AI+ 새싹 · AI Engineer 교육