3개의 집중형 부트캠프와 10개 이상의 팀 프로젝트를 거치며, 단순 구현을 넘어 서비스 구조를 설계하고 문제를 수치로 해결하는 개발자로 성장했습니다. 프론트엔드 감각 위에 백엔드·인프라 경험을 더해, 기획부터 배포까지 서비스 전 사이클을 혼자서도 완성할 수 있습니다.

대학생활

핵심 강점

숙련도 기준

기술을 다루는 방식

• 새로운 도구를 빠르게 익히되, 사용 이유와 제약을 먼저 파악합니다.
• 기능 구현보다 데이터 흐름과 상태 정합성을 먼저 설계합니다.
• 문제 해결 시 원인→선택지→결정 근거를 남기는 습관이 있습니다.
• FE·BE·인프라 사이의 번역자 역할을 자주 맡았습니다.

이달의 동료상은 팀원들이 직접 선정한 수상으로, 협업 방식을 가장 잘 보여주는 증거입니다. 학습 결과를 대회·발표·문서화로 마무리해 성과로 연결해왔습니다.

• V1 (수동 좌표): 8개 구역 꼭짓점을 직접 입력. 빠른 프로토타입이었지만 정확도 낮음.
• V2 (공유 꼭짓점): 인접 구역이 경계를 공유하도록 개선. 틈새·겹침 해결.
• V3 (공공 GeoJSON): 서울시 공공 GeoJSON 직접 가공. Douglas-Peucker로 좌표 포인트 60% 감소. 한강 메시 별도 생성.

• 레이어 구조: Unity 3D 배경 위에 React bg-transparent 오버레이. z-index 충돌 문제 직접 해결.
• 5개 액션 모달: 발주·가격·홍보·인플루언서·이벤트. ModalWrapper 공통화로 일관된 진입/퇴장 애니메이션.

• 401 응답 시 failedQueue 패턴으로 동시 갱신 요청 처리. 토큰 갱신 도중 들어온 요청을 큐에 보관, 갱신 완료 후 일괄 재전송. 무한루프 방지 로직 별도 구현.

팀이 직면한 3가지 구조적 문제

• 시즌 로그 과부하: 게임 1회당 1만+ 건 이상 로그 → RDB 직접 저장 시 부하
• FE-BE 동기화 불일치: 일정 주기 동기화 사이 발생한 상태 변화를 어떻게 반영할 것인가
• 클라이언트 위변조: localStorage 재고·잔액 → 개발자 도구로 수정 가능 → 공정성 붕괴

방안 2 — 5가지 서버 개입 타이밍

시드(Seed) 방식 — 재현 가능한 랜덤성

손님 구매량(0~3개)을 그때그때 Math.random()으로 결정하면 서버 검증 불가 + 재접속 복원 불가. 시즌 시작 전 서버가 유저별 시드 배정. 서버·FE가 같은 시드를 순서대로 소모 → 어느 쪽에서 계산해도 동일한 결과. SSE 없이도 클라이언트가 이벤트 스케줄을 들고 있다가 시각이 되면 서버에 직접 요청.

① 스케줄러 기능 분리

• GameTickScheduler (10초): 실시간 상태 조회·브로드캐스트만 담당. 계산 로직 없음.
• SeasonDayClosingScheduler: 하루 마감 처리 전담 — 최종 구간 계산, MySQL 정산 저장, Kafka 발행. 관심사를 명확히 분리해 유지보수성 향상.

② Redis 이력 구조 (구간 스냅샷)

유입률·판매가·유동인구배수가 바뀌는 순간마다 스냅샷을 Redis에 누적. 이 이력만 있으면 어느 시점에서든 잔액·재고를 독립 재계산 가능.

③ 외부 API 배치 + 캐시 + fallback

• 뉴스·유동인구 외부 API 호출은 배치로 처리해 부하 분산.
• Redis 캐시로 중복 호출 방지. fallback: API 실패 시 이전 캐시 데이터 사용.

트러블슈팅 — Spark ETL 스케일 불일치

① N+1 해결 — Bulk Fetch + Memory Mapping

챕터별 진행 내역 조회 시 JPA N+1 발생. 전체 진행 내역을 한 번에 조회 후 Map 변환, 루프에서 O(1) 조회.

② 복합키 + 순차 잠금 알고리즘

user_id + chapter_id 복합키. 소규모에서 가시성 우선 → 내부 static class 선택. prevCompleted 플래그 기반 순차 잠금 해제 — 파생 상태를 저장하지 않고 매 요청마다 실시간 계산. "파생 데이터는 계산이 정합성에 유리하다" 체득.

③ 업적 시스템 — Redis + 상수 클래스

빈번한 카운터 → Redis. 영구 기록 → DB. AchievementIdCode 상수 클래스로 하드코딩 제거. 행동 시점에만 체크하는 이벤트 기반 설계.

④ FastAPI 프록시 구조

Python 기반 AI를 독립 서비스로 운영. Spring Boot BE를 경유하는 프록시 구조 → 아키텍처 일관성 유지.

① HP 비례 XP 공식 — 게임 루프 설계

식단 등록 안 하면 HP가 줄고, HP가 낮을수록 XP도 줄어드는 구조. 학습보다 식단 등록을 먼저 유도하는 게임 루프.

② gainedHp rollback — source of truth 설계

식단 삭제 시 HP를 얼마나 되돌릴 것인가. 등록 당시 실제로 회복된 양을 저장해야 정합성 보장.

"source of truth를 동작 시점의 실제값으로 채워야 한다" — 이 설계에서 체득한 원칙.

③ FoodSearch UX 최적화 3가지

• 디바운싱(300ms): 타이핑마다 API 호출 방지.
• 한글 IME 처리: compositionstart/end 이벤트로 조합 중인 글자를 검색어로 전송 방지.
• 스켈레톤 최소 노출: 결과가 빠르면 스켈레톤 깜빡임 없이 바로 렌더.

트러블슈팅 — HTTPS 전환 후 세션 쿠키 차단