요구사항부터 솔루션 구현까지 책임집니다
클라이언트와 직접 만나 요구사항을 파악하고, 다양한 프로젝트의 솔루션 개발 전반을 맡고 있습니다. 고객이 필요로 하는 기능을 이해하는 일부터 이를 실제 서비스로 구현하는 과정까지 책임지고 연결합니다.
백엔드 개발자
김성민Theo
서비스를 출시하고 운영하며, 사용자 경험과 시스템의 병목을 개선하는 백엔드 개발자입니다.
현재 세종AI연구센터에서 다양한 솔루션의 설계와 개발을 맡고 있습니다.
About
AI 모델을 사용자에게 닿는 서비스로 만듭니다
담당한 솔루션 중 하나인 축구 AI 프로젝트에서는 Hugging Face의 여러 모델을 학습시키고 경기 분석 파이프라인을 구축했습니다. 분석 결과를 사용자 피드백으로 제공하는 서비스까지 맡으며, 모델 학습과 서비스 구현을 함께 경험했습니다.
제한된 자원에서 구현할 방법을 찾습니다
인력·시간·장비가 한정된 환경에서 필요한 성능과 결과를 만들어내는 일이 실무의 중요한 과제입니다. 주어진 조건에서 어디에 집중해야 할지 고민하며, 솔루션 개발 과정에서 마주하는 문제를 해결해 왔습니다.
Experience
Skills
Backend
- Java
- Spring Boot
- Python
- FastAPI
- Spring AI
Data
- MySQL
- PostgreSQL
- Redis
- Redisson
- NotionDB
Infrastructure
- Docker
- Docker Compose
- AWS (EC2, S3, RDS, ALB)
- Oracle Cloud
- Cloudflare
- Kubernetes
AI
- PyTorch
- Hugging Face
- YOLO
- VLM
- U-Net
Client
- TypeScript
- React Native
- Next.js
Certificates
- 정보처리기사2024.12
- SQLD2024.09
Projects
픽플로우
운영 중사진 스팟을 탐색하고 날씨·혼잡도 등 촬영에 필요한 정보를 확인하는 사진 출사 서비스
주요 성과
- DDD 13기 전체 1등 팀 선정
- iOS·Android 출시 후 운영 지속 · 공공데이터 공모전 참여 및 V2 개발
개발 과정 보기
해결하려던 문제
사진을 찍을 장소와 촬영 조건을 여러 곳에서 찾아야 하는 불편을 줄이고자 했습니다. 큐레이션한 사진 스팟에 날씨·혼잡도·일출몰 정보를 연결하고, 출시 이후에는 고해상도 이미지 업로드와 제한된 서버 자원 안에서의 안정적인 운영을 개선했습니다.
어떻게 해결했는가
격자별 데이터 공유와 등록 후 초기 수집으로 정보 공백 개선
날씨·혼잡도는 주기적으로 수집해 DB에 저장하고, 스팟 상세 API는 저장된 정보를 조회하도록 분리했습니다. 날씨는 동일한 기상청 격자의 스팟을 묶어 격자당 한 번의 호출 결과를 공유했습니다. 신규 스팟이 다음 수집까지 기다리지 않도록 등록 트랜잭션 커밋 후 날씨·천문 정보를 비동기로 초기 수집했습니다. 날씨 수집 실패가 등록 결과나 천문 정보 수집에 영향을 주지 않게 분리해, 중복 호출을 줄이면서 신규 스팟의 촬영 정보 공백을 개선했습니다.
파일 기반 업로드로 힙 적재를 제거하고 재시도 지원
기존 S3 업로드는 파일 전체를 바이트 배열로 힙에 적재해, 고해상도 사진을 동시에 올릴수록 메모리 부담이 커질 수 있었습니다. 임시파일과 RequestBody.fromFile()을 사용하는 방식으로 바꿔 SDK 재시도 시 파일을 다시 읽을 수 있게 했습니다. 성공·실패와 관계없이 임시파일을 정리하고, 애플리케이션·서블릿·Nginx의 용량 제한도 조정했습니다. 원본 업로드의 전체 파일 힙 적재를 제거하고 재시도와 자원 정리를 보완했습니다.
배포 복구 자동화와 환경 분리로 운영 안정성 개선
GitHub Actions·GHCR로 커밋별 이미지를 배포하고, 헬스체크 실패 시 이전 이미지로 복구하도록 자동화했습니다. 예외 로그만으로 놓칠 수 있는 장애를 감지하기 위해 앱 가용성·HTTP 5xx·로그 수집 중단·JVM 힙·DB 커넥션 대기를 모니터링했습니다. 같은 EC2에 테스트 환경을 마련하면서 DB·Redis 논리 DB·S3 경로·모니터링 라벨을 분리하고, 테스트 환경의 정기 수집을 꺼 운영 API 호출 한도를 소모하지 않게 했습니다. EC2 증설 없이 앱 팀의 검증 환경을 제공하고 운영 영향을 줄였습니다.
ReadIt (리드잇)
운영 중학습 수준과 목표 단어에 맞는 영어 이야기를 생성하고, 학습 결과를 다음 복습으로 연결하는 AI 영어 학습 서비스
주요 성과
- 2주 만에 MVP 배포 후 App Store·Play Store 출시
- 영어 학습자 10명의 1주간 테스트를 바탕으로 사전 생성·복습 기능 개선
- 대학 창업지원금 선정
사용 기술
- Spring Boot
- Spring AI
- Redisson
- Redis
- MySQL
개발 과정 보기
해결하려던 문제
학습자가 자신의 수준과 학습할 단어에 맞는 영어 읽기 자료를 찾기 어렵다는 문제에서 출발했습니다. AI로 맞춤형 콘텐츠를 생성하면서도 긴 생성 대기와 불규칙한 출력 형식을 다루고, 학습 결과가 다음 복습으로 이어지도록 백엔드를 설계했습니다.
어떻게 해결했는가
학습 시작과 AI 생성의 시간을 분리
사용자가 학습을 시작할 때마다 AI 응답을 기다리는 흐름을 개선하기 위해, 최초 학습에는 난이도별 시드 콘텐츠를 제공하고 후속 콘텐츠는 비동기로 미리 생성하도록 구성했습니다. 조회 시 준비된 콘텐츠를 우선 제공하고, 준비된 콘텐츠가 없는 사용자·단어장 조합을 주기적으로 탐색해 보충했습니다. 준비된 콘텐츠가 이미 있으면 추가 생성을 제한해 불필요한 AI 호출을 줄였습니다. 준비된 콘텐츠 조회 응답 시간을 p95 500ms 이하로 유지하고, 전체 새 콘텐츠 조회 요청의 95% 이상에 준비된 콘텐츠를 즉시 제공했습니다.
중복 생성 제어와 실패 복구
동일한 사용자·단어장에 여러 생성 트리거가 겹칠 때 중복 콘텐츠와 불필요한 AI 호출이 발생하지 않도록 Redisson 분산 락을 적용했습니다. 락 획득 후 준비된 콘텐츠의 존재 여부를 다시 확인하고, 작업 종료 시 예외 발생 여부와 관계없이 락 해제를 시도하도록 구성했습니다. 생성 상태와 실패 원인을 저장하고, 동일 작업을 재처리해도 결과가 중복 저장되지 않도록 처리했습니다. 단어장 학습 범위의 예약과 확정을 분리해 생성 실패로 학습할 단어가 건너뛰어지는 문제를 방지하고, 본문·단어 분석·퀴즈의 부분 실패에 대한 복구 흐름을 구성했습니다. 동일 작업에 대한 동시 요청 100개에서 중복 결과 저장 0건을 확인했으며, 생성 중 프로세스를 강제 종료한 뒤 재처리해 학습 범위 누락 없이 복구했습니다.
AI 생성 결과를 복습 가능한 학습 데이터로 변환
AI가 생성한 문장에 포함된 단어의 활용형을 학습 원형 및 원형의 뜻과 연결했습니다. 저장 전 강조 기호를 정리해 앱의 하이라이트 좌표가 실제 문장을 기준으로 계산되도록 했습니다. 학습 완료 시 모르는 단어의 복습 단계를 초기화하고, 다시 모르는 단어로 표시되지 않은 복습 단어는 다음 단계로 진행하도록 구성했습니다. 복습 시점이 된 단어는 후속 콘텐츠 생성 입력에 반영해 학습과 복습이 이어지도록 했습니다. 고정 평가셋 200건을 기준으로 목표 단어 포함률 98% 이상, 학습 원형 매핑 정확도 95% 이상을 확보했습니다.
출시 및 사용자 검증
백엔드와 Docker Compose 기반 배포 환경을 구성해 2주 만에 MVP를 배포했습니다. 팀이 영어 학습자 10명을 대상으로 진행한 1주간의 테스트에서 긴 생성 대기를 개선 과제로 확인했고, 이를 바탕으로 사전 생성과 복습 기능을 개선했습니다.
사용 기술
- Spring Boot
- Spring AI
- Redisson
- Redis
- MySQL
- Docker Compose
- Gemini API
- AWS (EC2, RDS, ALB)
CheerLot (쳐랏)
운영 중선수 정보·선발 라인업·응원가·경기 일정을 제공하는 야구 직관 도우미 서비스
주요 성과
- 2025년 7월 출시 후 운영 지속 · 서비스에서 DAU 300, MAU 1만 기록
- 출시 이후 확인한 Android 수요에 대응해 앱 개발·Play Store 출시
사용 기술
- Spring Boot
- FastAPI
- Redis
- NotionDB
- React Native
개발 과정 보기
해결하려던 문제
6인 팀에서 백엔드와 데이터 파이프라인을 담당했습니다. 출시 이후 외부 데이터 조회 지연과 갱신 실패가 서비스에 미치는 영향을 줄이기 위해 API 응답 성능과 데이터 갱신 안정성을 개선했습니다.
어떻게 해결했는가
Redis 기반 조회 전환으로 평균 응답시간 92% 단축
사용자 요청마다 Notion API를 호출해 외부 API의 응답 지연이 사용자 요청에 영향을 주었습니다. Notion을 통한 콘텐츠 관리 방식은 유지하되, 데이터를 Redis에 적재하고 사용자 요청은 Redis에서 조회하도록 변경했습니다. 데이터 수집·갱신과 사용자 조회 경로를 분리했습니다. 결과: 평균 응답시간 850ms → 65ms, 약 92% 단축. 측정 조건: 동일 환경·데이터에서 curl 순차 요청 각 30회, 사전 요청 5회 제외. 클라이언트에서 측정한 전체 응답시간 기준.
선수 정보·라인업 버전 분리로 전송량 98% 감소
선수 프로필과 선발 라인업은 변경 항목과 시점이 달라, 클라이언트가 데이터별 갱신 필요 여부를 판단할 기준이 필요했습니다. playersVersion과 lineupVersion을 분리해 선수 구성·프로필 변경과 선발·타순 변경을 각각 감지했습니다. 팀별 버전 API를 제공해 클라이언트가 필요한 데이터만 재조회하도록 했습니다. 결과: 데이터 변경이 없는 조회에서 응답 본문 전송량 12KB → 0.2KB, 약 98% 감소. 비교 기준: 동일한 사용자 동작에서 전체 데이터 조회와 버전 확인 방식의 응답 본문 전송량 비교.
외부 데이터 조회 실패 시 기존 캐시 보존
기존 캐시를 먼저 삭제한 뒤 최신 데이터를 조회하면, 외부 조회 실패 시 기존 데이터까지 유실될 수 있었습니다. 최신 데이터를 모두 조회한 후 캐시를 교체하도록 처리 순서를 변경했습니다. 경기 일정 수집에서도 크롤러 응답 실패 시 기존 캐시를 유지하도록 처리했습니다. 검증 결과: 외부 조회 실패 시나리오 20회 재현, 기존 캐시 보존 20/20회 확인.
사용 기술
- Spring Boot
- FastAPI
- Redis
- NotionDB
- React Native
- Oracle Cloud (OCI)
- Cloudflare R2
Contact
백엔드 개발과 AI 서비스 구현에 기여할 기회를 찾고 있습니다. 프로젝트나 협업에 관해 편하게 연락 주세요.
0411tjdals34@gmail.com