약 4년 경력 · Java/Kotlin·Spring Backend Engineer
백엔드 개발자
홍철민
- 경력
- 약 4년의 백엔드 개발 경험
- 기반
- Java/Kotlin·Spring
- 핵심 문제
- 상태 관리·중복·재실행·외부 연동 실패
- 확장
- Python·RAG·MCP 기반 AI 서비스 백엔드
대표 작업
대표 사례
결제 상태 처리, JVM 라이브러리 성능 측정, AI 출력 검증에서 직접 맡은 구현과 결과를 보여주는 세 사례입니다.
- 01
경력
호두랩스
- 맥락·문제
- PG와 Google Play·Apple 인앱 결제를 하나의 서비스 흐름으로 연결한 운영 결제 시스템입니다.외부 결제 승인과 내부 재화 제공이 한 번에 끝나지 않을 수 있어, 승인 이후 내부 처리가 완료되지 않은 주문을 구분할 필요가 있었습니다.
- 내 역할
- PG·인앱 결제 API와 상태 흐름, 복구 배치를 구현했고 Stored Procedure와 DB 처리 구조는 DBA와 협업했습니다.
- 결과
- 미완료 PURCHASED 주문을 Redis TTL 안에서 식별·재처리하고, 여러 WAS에서 복구 스케줄러가 동시에 실행되는 것을 ShedLock으로 제한했습니다.
- 판단
- 주문을 REQUESTED·PURCHASED·COMPLETED로 나누고, PURCHASED 상태와 Redis 정보가 남은 주문만 복구 배치가 재처리하도록 했습니다.
- 검증
- 주문 상태, Redis TTL과 DB 제약이 담당하는 범위를 대조해 정상 처리와 재처리 조건, 처리하지 못하는 실패를 구분했습니다.
- 증명하는 역량
- 외부 승인과 내부 완료를 상태로 분리하고, 복구 가능한 실패와 남는 복구 공백을 함께 설명하는 역량을 보여줍니다.
- 02
프로젝트
KExcel — Kotlin DSL 기반 대용량 엑셀 생성 라이브러리
- 맥락·문제
- 엑셀 보고서를 만드는 개발자가 저수준 객체와 좌표·스타일 수명주기를 반복 관리해야 하는 문제를 개인 오픈소스 라이브러리로 일반화했습니다.Apache POI의 저수준 API를 직접 사용하면 객체와 좌표, 스타일 생명주기를 반복해서 관리해야 했고, 엔진을 바꾸면 보고서 코드도 함께 변경해야 했습니다.
- 내 역할
- 개인 프로젝트로 API와 Scope 계층 설계, POI·FastExcel 드라이버 구현, 벤치마크와 배포를 수행했습니다.
- 결과
- FastExcel DSL 오버헤드를 16.3%에서 3.1%로 줄이고 512MB heap에서 100만 행 생성을 완료했으며, JitPack 0.1.0으로 공개했습니다.
- 판단
- 사용자 DSL과 실제 엑셀 엔진을 ExcelDriver 인터페이스로 분리하고, 스트리밍 제약과 동일 시트 동시 쓰기 오용은 즉시 실패하도록 했습니다.
- 검증
- OpenJDK 21, 512MB heap, G1GC 환경에서 JMH로 DSL 오버헤드와 병합 처리량을 측정했습니다.
- 증명하는 역량
- API 추상화의 편의뿐 아니라 오용 정책과 런타임 비용을 벤치마크로 함께 검증하는 역량을 보여줍니다.
- 03
프로젝트
WorkShield Web — 실패 경계를 설계한 AI 서비스 백엔드
- 맥락·문제
- 사용자가 계약서를 올리고 오래 걸리는 검토의 진행과 근거를 확인할 수 있도록 선행 비교 엔진을 웹 서비스 흐름에 연결한 출시 전 5인 팀 프로젝트입니다.외부 서비스를 거치는 검토에서 같은 요청의 반복, 취소와 완료의 경쟁, 서버 중단과 부분 응답 실패를 상태로 다뤄야 했습니다.
- 내 역할
- 5인 팀에서 백엔드 API와 AI 서비스 경계, AWS 인프라와 배포 자동화를 담당했습니다.
- 결과
- 검증된 근거의 실제 ID를 백엔드가 결합하도록 바꾸고, 고정 합성 fixture 16회 최종 gate를 통과한 모델을 답변·Suggestions 후보로 선정했습니다.
- 판단
- 백엔드가 검토 상태를 관리하고, 질문 대상과 실제 출처를 모델 응답에 맡기지 않도록 했습니다. 중복 요청과 동시 변경은 서로 다른 저장 규칙으로 방어했습니다.
- 검증
- API와 연동 테스트, 화면 빌드, 컨테이너 이미지 빌드와 배포 설정 검사를 자동화했습니다.
- 증명하는 역량
- 오래 걸리는 AI 작업의 상태와 모델·배포 영역의 책임을 백엔드에서 구분한 역량을 보여줍니다.
경력
경력 타임라인
2022.11–2023.08
2021.09–2022.10
2021.02–2021.08
2020.02–2021.02
추가 프로젝트
추가 프로젝트
프로토타입
WorkShield — 표준계약서 비교 MCP
표준계약서와 비교해 사람이 확인할 조항 후보를 좁히는 5인 팀 프로젝트입니다. AI 제안으로 기능 범위가 검증하기 어려운 상세 비교까지 커졌고, 실제 검색 점수와 판정 기준이 맞지 않는 문제도 확인했습니다. 상세 비교를 제외한 뒤 실제 실행 기록과 분리된 평가 데이터로 기준선을 관리했습니다. 법률 판단을 대신하지 않으며, 문제 정의와 중단 기준을 사람이 소유한 사례입니다.
프로토타입
영화 흥행 예측 및 배급 시뮬레이터
5인 팀의 영화 흥행 예측 프로토타입에서 스크린 수와 콘텐츠 잠재력의 상호 의존성을 한 모델에 섞지 않아야 했습니다. 콘텐츠 잠재력과 배급 변수를 나눈 2-Stage 구조를 선택했습니다. PM으로 구조·데이터 수집·모델 비교를 담당해 2,489편을 개봉일 기준으로 시간 분할해 평가했습니다. 인과 효과나 실제 배급 성과를 뜻하지 않는 한계를 명시해 예측 구조와 인과 해석을 구분한 사례입니다.
프로토타입
전기차 충전 인프라 SOS 대시보드
5인 팀의 공공데이터 프로토타입에서 전기차 등록 대수와 충전기 수를 같은 흐름으로 검증·적재해야 했습니다. Pandera·MySQL 처리와 domain·web·config 레이어 분리를 선택했습니다. ERD·적재·대시보드를 담당해 17개 시·도 결과를 지도와 차트로 확인했습니다. 팀 정의 불편지수가 실제 대기 시간이나 공식 지표가 아님을 명시해 데이터 흐름과 해석 범위를 함께 관리한 사례입니다.
개발 원칙
개발 원칙
- 문제를 먼저 정의합니다.기능을 추가하기 전에 사용자 맥락, 바꿀 수 없는 제약과 시스템이 답해야 할 질문을 구분합니다.
- 결과를 검증합니다.테스트, 벤치마크와 실제 실행 기록으로 변경을 확인하고 채택·보류·중단 기준을 기록합니다.
- 책임 범위를 설명합니다.애플리케이션, 데이터베이스, 외부 서비스와 팀 구성원이 보장하는 범위와 남은 실패를 나눕니다.