경력
Selected Work휴브알엔씨
Backend Engineer · 백엔드·인프라 1인 담당
전국 250여 개 병원·센터가 사용하는 의료 진단 플랫폼 — 신경심리검사(SNSB-3) 채점·리포트와 아동말소리장애 검사(APAC-R) 발성 분석. 지연·오류가 즉각 의료 현장 VOC로 이어지는 고신뢰성 환경에서 백엔드·인프라를 혼자 담당.
검사 이용권 코인 정합성 확보 — 상태 기반 최종 일관성 설계
코인 차감 후 외부 분석 서버를 호출하는 구조라, 외부 장애·타임아웃 시 코인만 차감되고 결과는 없는 정합성 붕괴 VOC가 발생했습니다. 코인을 즉시 차감하지 않고 요청·사용 내역을 PENDING으로 DB에 먼저 기록한 뒤 외부를 호출하고, 완료 이벤트에 COMPLETE로 확정하며 잔여 코인은 COMPLETE 건만 집계하도록 바꿨습니다. 일정 시간이 지나도록 확정되지 않은 PENDING은 배치가 FAIL로 전이해, 타임아웃·서버 다운 등 어느 지점에서 장애가 나도 코인이 유실된 채 남지 않고 자동 복구됩니다. 전이는 현재 상태를 조건으로 하는 UPDATE(멱등)라 완료 이벤트와 배치가 경합해도 같은 건이 두 번 바뀌는 일이 없습니다.
→ 결제 정합성 불일치 VOC 해결, 장애 시에도 최종 일관성으로 자동 수렴
리포트 렌더 9초 → 1.5초 — 렌더 워커 분리 + 이벤트 드리븐 후처리
일 평균 1,500건의 CPU 집약 PDF 렌더가 API 서버 내부에서 앱 트래픽과 자원을 경합해 건당 9초가 걸렸고, 피크마다 요청 스레드를 점유해 서버가 다운됐습니다. 렌더를 SQS + 전용 ECS 워커로 격리해 API는 즉시 응답하고 워커 수로 동시 렌더를 통제해 OOM을 차단했으며, 완료 이벤트는 EventBridge 룰로 분기해 SNS 푸시(FCM/APNS)·Lambda 정리로 확장하고 실패는 DLQ로 격리했습니다.
→ 렌더 9초 → 1.5초 (83%↓, OTel·Prometheus·Grafana로 측정), 피크 서버 다운·관련 VOC 0
자세한 내용 →상세 화면 진입 2초 → 0.3초 — 불필요한 선로딩 제거 + 커서 페이징
진입 시 DB 조회와 함께, 사용자가 리포트를 눌러야 비로소 쓰이는 외부 리포트 HTML까지 미리 선로딩해 진입 응답이 당장 필요 없는 외부 호출에 종속돼 있었습니다. 외부 HTML 선로딩을 폐기하고 리포트를 여는 렌더 시점에만 lazy 로딩하도록 바꿨으며, 목록 페이징은 Offset에서 커서(No-Offset)로 전환해 깊은 페이지의 불필요한 스캔을 제거했습니다.
→ 진입 2초 → 0.3초 (85%↓), 저사양 병원 PC 타임아웃 소멸
자세한 내용 →배포 15분 → 3분 — 컨테이너 기반 배포 체계 0→1 구축
자동화·코드화가 전무한 수동 EC2 배포 환경에서 매 배포마다 npm·라이브러리 버전 불일치 장애가 반복됐습니다. 비용·복잡도를 고려해 블루/그린 대신 ECS Fargate + ALB 롤링 배포를 직접 설계·도입하고 Docker로 실행 환경을 고정했습니다. Terraform으로 인프라 전체를 코드화하고 검증/운영 서버를 분리해, 신규 합류자가 구두 설명 없이 환경을 재현하고 운영 배포 전 사전 검증이 가능한 구조를 만들었습니다.
→ 배포 시간 80% 단축 (15분 → 3분), 환경 불일치 장애 재발 0
배포 후 버그 월 10건 → 1건 — E2E 자동화 + TC 이력 대시보드 단독 구축
검증 환경도 자동화도 없이 수동 QA에만 의존해 운영에 직접 배포하는 구조라 배포 후 오류가 반복됐습니다. QA 외주가 작성한 TC 문서를 AI로 E2E 스크립트로 변환·축적하고(웹 Playwright · 모바일 Maestro), TC 이력·실행 관리 대시보드를 직접 설계·개발해 결과를 Discord로 실시간 공유했습니다. 검증 환경 게이트로 운영 직배포를 차단했습니다.
→ 배포 후 버그 90% 감소 (월 10건 → 1건), 수동 QA 시간(일 1시간) 제거
스윗코리아
Backend Engineer · 백엔드·서드파티 연동
B2B 업무 협업툴 SaaS — 기업 고객 대상 Slack 대체 플랫폼. 외부 개발자용 오픈 API와 타사 서비스를 Swit 안에서 쓰는 App Store 운영. 엄격한 보안 규정(Compliance)이 핵심 경쟁력인 환경.
외부 API 응답 10초 → 1.8초 — 동시성 제한 + 부분 실패 격리
Jira 이슈 목록을 Promise.all로 10건을 한 번에 호출하다 Jira rate limit(429)에 걸려, 재시도가 누적되며 오히려 10초씩 걸렸습니다. 지연의 원인이 처리량 부족이 아니라 429 재시도 증폭임을 특정하고, 5개씩 배치로 동시 요청 수를 제한해 재시도 폭주를 차단했습니다. Promise.all은 하나만 실패해도 전체가 죽는 구조라 allSettled로 부분 실패를 격리하고 수신 후 정렬로 순서를 보장했습니다.
→ 응답 10초 → 1.8초 (82%↓), 429 재시도 없이 안정 운영
서드파티 토큰 연쇄 접근 취약점 선제 발견 — step-up 재인증
인앱 플러그인 인증 구조를 분석하던 중, Swit 토큰이 무효화되지 않고 남으면 연결된 모든 서드파티 앱 토큰에 연쇄 접근이 가능한 경로를 발견했습니다. B2B 환경에서 편의성보다 보안을 우선해야 한다고 판단해 팀과 협의했고, 민감 작업 구간에 재인증(step-up authentication)을 강제해 연쇄 접근 경로를 차단했습니다.
→ 취약점 선제 차단, 인앱 플러그인 보안 요건 충족 후 정식 출시
폐쇄망 고객사 보안 감사 대응 — 마스킹 배치 + Splunk 전송 파이프라인
연간 보안 감사 의무가 있는 고객사가 액션 로그를 요구했으나, 개인정보 원본 반출이 불가하고 고객사 환경이 폐쇄망이라는 이중 제약이 있었습니다. 5분 주기 배치로 이름·이메일을 마스킹하고 IP는 고객사 제공 솔트 키로 해시 처리해 동일 사용자 행위 추적은 가능하되 원본 유추는 불가능하게 만들었으며, 고객사 DMZ 역방향 프록시 경유에 상호 인증서 + API 토큰 + IP 화이트리스트 3중 통제를 적용했습니다. 전송 실패 로그는 상태·재시도 횟수와 함께 DB에 영속화해 실패가 조용히 사라지는 경로를 차단했습니다.
→ 연간 감사 요건 충족, 전송 실패 전량 추적·복구 체계 확보
웅진씽크빅
Backend Engineer · 성능 개선·인프라 안정화
10년간 운영된 차세대 통합 LMS 백엔드 — 히스토리 누적 100억 건+, 피크 수천 RPS. 데이터가 방대해지면서 성능 문제가 곳곳에서 터지기 시작한 레거시 환경에서 성능 개선·인프라 안정화를 담당.
결제-등록 정합성 사고(6천 명) 해소 — Redis 분산 락 + 멱등 처리
SAP 회원권 등록 배치가 SELECT FOR UPDATE 락 대기로 스레드 풀·커넥션을 고갈시켰고, 수신과 처리 사이에 영속 지점이 없어 요청이 흔적 없이 유실 — 약 6,000명이 결제 완료 후 등록되지 않는 사고가 났습니다. 배치가 2중화돼 JVM 락으로는 인스턴스 간 상호배제가 불가능해 동시성 제어를 Redis 분산 락(Redisson, 오더 단위)으로 이전했고, 락 만료·재시도로 인한 이중 실행은 등록 상태값 조건부 체크로 멱등을 보장했습니다.
→ 누락 6,000명 수동 복구, 재발 0
자세한 내용 →대용량 히스토리(100억 건+) 조회 20초 → 1초 — 생성시간 Range 파티셔닝
100억 건이 넘는 히스토리 테이블을 조회할 때마다 전체를 스캔하면서 DB 버퍼풀이 히스토리 데이터로 가득 차, 시스템 전체가 멈추는 프리징 장애가 발생했습니다. 조회 키가 흩어지고 신규 데이터 위주라 캐싱은 부적합해, 테이블을 생성시간(연/월) 기준 Range 파티셔닝으로 분할했습니다. 조회 쿼리가 항상 기간 조건을 포함하므로 필요한 날짜 범위 파티션만 읽도록(range pruning) 개선해 버퍼풀 과부하를 차단했습니다.
→ 조회 20초 → 1초 이하 (95%↓), 프리징·관련 VOC 0
회원·과목 조회 쿼리 3초 → 1.4초 — 복합 인덱스
회원 수가 급증하면서 회원·과목·시간 조건 조회 쿼리가 3초 이상 지연되기 시작했습니다. 과목 인덱스가 없어 매 조회마다 Full Scan이 발생하는 구조였고, EXPLAIN 분석으로 원인을 확인해 WHERE 절 선두 조건인 과목 기준 복합 인덱스(과목-회원-시간, leftmost prefix)를 설계해 필요한 구간만 읽도록 개선했습니다.
→ 쿼리 3초 → 1.4초 (53%↓), Full Scan 제거
자세한 내용 →개인 프로젝트
Ticketing MSA — 선착순 예매 시스템 (학습 프로젝트)
2026.05 – 진행 중고동시성·읽기쓰기 비대칭 도메인을 MSA(게이트웨이 · 대기열 · command/query 분리, CQRS)로 설계하고, Kafka·Redis를 매니지드에 의존하지 않고 직접 구현(MyKafka·MyRedis)해 '왜 이 구조인가'를 코드로 검증했습니다. 대기열 3대 다중화 시 초과 입장 race는 리더 선출(SET NX)로 해결해 activeCount ≤ slot을 보장했습니다.
→ k6 동시 100요청에서 정확히 좌석 수만큼 성공(중복·초과 0) — 정합성을 측정으로 검증
GitHub →기술 스택
능숙
실서비스에서 설계·운영한 핵심 스택언어 · 프레임워크
데이터베이스 · 캐시
인프라 · DevOps
사용 경험
프로젝트·과제에서 다뤄본 도구프론트엔드
DevOps · 관측 · 테스트
데이터 · 기타
학력 및 수료
삼성 청년 소프트웨어 아카데미 (SSAFY) · 수료 · 우수상
비전공자 팀에서 캘린더 서비스 팀장으로 프론트·백엔드·인프라 전담, Jenkins CI/CD 첫 구축 경험.
충북대학교 정보통신공학과 · 학사 졸업