Frontend · Creative · Engineer
다양한 도메인에서 협업 경험을 쌓으며
AI 자동화로 팀 생산성을 높이고
Monorepo · 디자인 시스템으로 개발 인프라를 표준화하며
GSAP · Framer Motion으로 인터랙션을 설계하는 프론트엔드 개발자입니다.
메인 웹사이트 & 마이페이지
App Router 전환 · Docker 79% 경량화 · SEO 44 → 98점 · 아이콘 번들 95% 감소 레거시 현대화부터 서비스 성장까지 글로벌 E-Wallet 프론트엔드 전반을 주도
글로벌 E-Wallet 서비스 STICPAY의 메인 페이지, 마이페이지(입금/출금/프로모션/선불카드 발급 · 충전 · 이용내역), C2M 결제, Payment Gateway 등 서비스 전반의 프론트엔드를 설계 및 개발했습니다.

webpack 기반 레거시 환경에서 번들 1.2GB, Docker 이미지 1.32GB로 CI/CD 전체가 병목이었습니다. 미사용 정적 파일과 node_modules(1.04GB)가 이미지에 포함되어 배포 시간과 비용이 과도하게 소모되었습니다.
Vite 마이그레이션으로 ESM 기반 개발 서버와 Rollup 빌드를 도입하고, Tree-shaking 최적화로 번들을 250MB로 감소시켰습니다. Next.js standalone 모드 기반으로 Docker 빌드를 재설계하여 불필요한 node_modules를 제거하고, .dockerignore 재구성과 미사용 정적 파일 · UI 컴포넌트 정리를 병행하여 이미지를 272MB로 경량화했습니다.
App Router 전환 후, RSC payload가 text/x-component Content-Type으로 내려오는데, CloudFront가 Vary: Accept-Encoding으로만 캐시 키를 구성하여 HTML 응답과 RSC payload가 동일 캐시로 처리되었습니다. 이로 인해 사용자에게 잘못된 응답 유형이 반환되는 문제가 발생했으며, 금융 서비스 특성상 데이터 정합성 문제는 사용자 신뢰에 직접적인 영향을 미쳤습니다.
Next.js가 사용하는 Vary 헤더(RSC, Next-Router-State-Tree, Next-URL)를 CloudFront Cache Key에 추가하여 응답 유형별 캐시를 세분화했습니다. 이를 통해 HTML과 RSC payload가 별도의 캐시 엔트리로 관리되어 정합성을 확보하고, 정적 자산은 장기 캐싱, 동적 페이지는 적절한 revalidate 값을 적용하여 성능과 데이터 정합성의 균형을 확보했습니다.
12개 이상 언어를 지원하는 글로벌 서비스에서, 번역 리소스가 빌드 시점에 고정되어 긴급 번역 수정에도 전체 재배포가 필요했습니다. 마케팅팀의 번역 수정 반영까지 개발팀 리소스가 소모되어 양쪽 모두 비효율적이었습니다.
next-i18next에서 next-intl로 마이그레이션한 뒤, 2단계에 걸쳐 실시간 번역 시스템을 자체 설계했습니다.
v1.0에서는 next-i18next 라이브러리를 사용하며 API Route 기반으로 원격 번역 데이터를 fetch하고, cookie에 fetchTime을 저장하여 서버 · 클라이언트 간 최신 번역 여부를 판단하는 구조를 구축했습니다.
이후 App Router 전환 시 Server Component에서 cookie가 read-only인 제약에 부딪혀, next-intl 라이브러리 사용과 동시에 아키텍쳐를 변경했습니다. 파일의 last modified 시간을 비교하여 갱신 조건을 판단하고, 어드민에서 번역을 수정 · publish하면 revalidate API가 호출되어 프론트엔드 번역 파일이 즉시 갱신되는 구조입니다.
@sticpay/i18n 패키지로 분리하여 모노레포 내 다른 서비스에서도 재사용 가능하게 만들었습니다.
여러 프론트엔드 프로젝트(메인, 마이페이지, 어드민, 결제)에서 동일한 유틸리티, 컴포넌트, 타입, 다국어 로직을 각각 중복 구현하고 있었습니다. 아이콘만 해도 단일 번들로 묶여 있어 사용하지 않는 아이콘까지 로드되는 비효율이 있었습니다.
직접 제안하고 주도하여 Turborepo + Yarn 4 Workspaces 기반 공통 라이브러리 모노레포를 구축했습니다.
@utils(쿠키 · 암호화 · 포맷팅), @design-system(공통 UI), @i18n(실시간 번역), @icons 등 6개 패키지를 개발하고, 아이콘 패키지는 독립 엔트리 포인트로 분리하여 번들 64% 감소(tree shaking 후 95% 감소)를 달성했습니다.
블로그 · 프로모션 페이지 제작, Jira 티켓 처리, 커밋 메시지 작성, MR 생성 등 반복 업무가 수작업으로 진행되어 핵심 UI/UX 고도화에 집중하기 어려웠습니다.
Figma MCP를 도입하여 디자인→코드 변환을 반자동화하고, Jira · Claude Code MCP를 연동하여 티켓 분석→브랜치 생성→코드 작성→MR 업로드까지 자동화하는 커맨드를 개발했습니다. Git Hook과 AI를 활용한 자동 커밋 메시지 작성, MR 자동 생성, 배포 자동화 파이프라인도 구축하여 단순 반복 업무를 줄이고 핵심 개발에 리소스를 집중할 수 있게 되었습니다.
C2M 결제 & Payment Gateway
Strategy Pattern 기반 결제 아키텍처로 신규 PG사 연동을 구조화하고, CRA→Vite 전환으로 빌드 91% 경량화(772MB→67MB), 배포 시간 1분 43초→29초로 단축한 글로벌 결제 인프라
마이페이지에 종속되어 있던 Payment를 독립 서비스로 분리 · 재설계하고, dev/staging/production 환경을 직접 구축했습니다. C2M · PG · P2P 등 다양한 결제 방식과 SSO · 2FA · QR · 다국어 · 실시간 환율 등 복합 금융 플로우를 안정적으로 운영할 수 있는 구조를 만들었습니다.


결제 수단(QR, URL redirect, 글로벌 PG사 등)이 추가될 때마다 if-else 분기와 코드 중복이 증가하여, 신규 연동 시 수정 범위가 넓고 결제 장애 위험이 높았습니다. 글로벌 확장에 따라 PG사 연동 빈도가 늘어나면서 개발 병목이 심화되는 구조였습니다.
전략 패턴(Strategy Pattern)을 적용하여 각 결제 수단의 응답 타입을 TypeScript Union Type으로 추상화하고, 수단별 실행 로직을 독립된 컴포넌트(Concrete Strategy)로 분리했습니다. 서버 응답의 구조적 특성(Duck-Typing)을 기반으로 런타임에 전략을 자동 선택하는 Dispatcher를 구현하여, 신규 결제 수단 추가 시 기존 전략 코드를 수정하지 않고 타입 정의와 컴포넌트만 추가하면 되는 구조를 확보했습니다.
// 1. Strategy Contract — 응답 구조가 곧 전략의 식별자
type PaymentResponse =
| { redirect: true; redirectLink: string }
| { redirect: false; qrcodeSrc: string };
...
// 2. Strategy Selector — Duck-Typing으로 전략 결정
const resolveStrategy = (res: PaymentResponse) => {
if (res.redirect) return 'REDIRECT';
if ('qrcodeSrc' in res) return 'QR';
...
return; // no strategy found
};
// 3. Dispatcher — 전략별 독립 컴포넌트로 위임
const PaymentResult = ({ res }: { res: PaymentResponse }) => {
switch (resolveStrategy(res)) {
case 'REDIRECT': return <RedirectStrategy data={res} />;
case 'QR': return <QrStrategy data={res} />;
...
default: return </>
}
};동시 다발 API 호출 시 access token이 동시에 만료되면, 각 요청이 독립적으로 refresh token을 요청하여 충돌이 발생했습니다. 일부 API 재호출이 누락되어 사용자에게 흰 화면이 노출되는 서비스 장애가 반복되었습니다.
Axios interceptor에서 refresh 요청 중 실패한 요청을 큐에 저장하고, refresh 완료 후 큐의 요청을 순차 재호출하는 패턴을 설계 · 적용했습니다. iframe 환경에서 브라우저 쿠키 정책으로 인한 인증 토큰 유실 문제는 URL 기반 토큰 관리 아키텍처로 전환하여 해결하고, User 인증 여부와 페이먼츠 정보 여부를 최상위에서 선확인하여 불필요한 re-render를 방지하고 서비스 안정성을 확보했습니다.
CRA(Webpack) 기반 레거시 환경에서 빌드 시간 15.6초, 빌드 아티팩트 772MB로 배포 파이프라인이 비효율적이었습니다. 배포 한 사이클에 1분 43초가 소요되어 핫픽스 대응 속도가 느렸습니다.
CRA에서 Vite로 전환하고 불필요한 모듈 제거 및 Tree-shaking을 최적화했습니다. 빌드 아티팩트를 67MB(91% 감소)로 축소하고, 빌드 시간 15.6s→4.4s, 배포 시간 1분 43초→29초로 단축하여 CI/CD 효율을 확보했습니다.
핀테크/크립토 웹 서비스
(주)아데나소프트웨어 · 페이먼츠개발팀
Braze SDK 통합, 프로모션 시스템 설계, Meta Pixel 연동, CI/CD 파이프라인 개선
Braze 통합과 프로모션 시스템 구조 개선으로 마케팅 캠페인 운영 기반을 확보하고, CI/CD 파이프라인 자동화로 배포 효율을 높인 핀테크/크립토 서비스
Next.js 기반 핀테크/크립토 웹 서비스에 빠르게 온보딩하여, 마케팅 자동화(Braze) · 프로모션 시스템 · 외부 트래킹(Meta Pixel) · CI/CD 개선 등 비즈니스 핵심 기능을 구현하고 서비스 성장 기반을 확보했습니다.
Cashback Web · 파트너 리뉴얼
(주)아데나소프트웨어 · 페이먼츠개발팀
파트너 목록 · 상세 페이지 전면 리뉴얼, 수수료 상세 페이지 신규 개발, UID 등록 가이드 시스템
1.5개월 만에 파트너 · 수수료 · 가이드 4개 페이지를 리뉴얼 · 신규 개발하여, 사용자의 브로커 비교 · 가입 전환율 개선 기반을 마련
STICPLAY Cashback 서비스의 파트너 목록 · 상세 페이지를 전면 리뉴얼하고, 10,401줄 규모의 CSV 수수료 데이터를 비교할 수 있는 페이지를 신규 개발했습니다. 16개 브로커별 UID 등록 가이드를 구축하여 사용자의 서비스 온보딩 허들을 낮추었습니다.


기존 파트너 목록 페이지가 677줄짜리 단일 파일로 구성되어, 데이터 fetch · UI 렌더링 · 필터 로직 · 이벤트 핸들링이 모두 한 곳에 얽혀 있었습니다. 새 기능 추가나 버그 수정 시 영향 범위 파악이 어렵고, 수정 한 곳이 다른 곳을 깨뜨리는 문제가 반복되었습니다.
단순히 파일을 쪼개는 것이 아니라, 기능 응집도(functional cohesion)를 기준으로 모듈 경계를 설계했습니다. 파트너 카드 · 필터 패널 · 정렬 컨트롤 · 브로커 상세 등 사용자 관점의 기능 단위로 7개+ 모듈을 분리하고, 각 모듈이 자신의 상태 · UI · 로직을 캡슐화하도록 구성했습니다. 모듈 간 의존은 props와 공통 타입으로만 연결하여 결합도를 낮추고, 반응형 디자인을 전면 적용하여 이후 기능 추가 시 수정 범위가 명확해져 개발 속도와 안정성이 향상되었습니다.
12개 브로커의 캐시백 수수료 데이터(10,401줄)를 효율적으로 파싱하고 필터링하여 사용자에게 비교 가능한 형태로 제공해야 했습니다.
CSV 파싱 유틸리티를 구현하고, 브로커별 개별 CSV 파일과 통합 수수료 테이블을 분리 관리했습니다. 반응형 필터 UI와 7개 언어 다국어를 적용하여, 글로벌 사용자가 브로커별 수수료를 직관적으로 비교하고 최적의 선택을 할 수 있는 환경을 구축했습니다.
CT 이미지 뷰어 · 11개 병원 협업
서울대학교병원 · 영상의학과
서비스 기획 · UI/UX 설계 · 풀스택 개발 · 배포
CD/USB 택배 기반이던 11개 병원 간 CT 이미지 공유를 웹으로 전환하여, 미국 MD.ai · Gradient Health의 협업 제안으로 이어진 의료 영상 뷰어를 기획부터 배포까지 단독 구축
11개 병원의 의료진이 CD/USB를 택배로 주고받던 CT 이미지 공유 방식을 웹 기반으로 전환했습니다. 의료진의 실제 워크플로우를 관찰하고 UX를 최우선으로 설계한 결과, 11개 병원이 동시 사용하고 미국 헬스테크 기업으로부터 협업 제안을 받는 성과로 이어졌습니다.



의료진은 기존에 데스크톱 소프트웨어(ITK-SNAP 등)로 CT 이미지를 열람해왔기 때문에, 웹 기반 뷰어만으로는 설치 경험과 오프라인 접근성 면에서 기존 워크플로우를 대체하기 어려웠습니다.
PWA(Progressive Web App)를 도입하여 홈 화면 추가, 오프라인 캐싱, 네이티브 앱과 유사한 UX를 제공했습니다. 의료진이 여러 병원을 오가며 기존 소프트웨어 없이도 CT 이미지에 접근할 수 있게 되어, 서비스 채택률을 높이는 핵심 요인이 되었습니다.
CT 이미지 뷰잉, 레이어 제어, annotation, 사용자 설정 등 상태가 복잡하게 얽혀 있어, 의료진의 조작이 예상과 다른 결과를 내는 버그가 발생하기 쉬운 구조였습니다.
Redux Toolkit을 도입하여 보일러플레이트를 줄이고, Flux 패턴 기반의 예측 가능한 단방향 데이터 흐름을 구축했습니다. slice 단위로 상태를 분리하여 기능 추가 시 영향 범위를 명확히 하고, 의료 데이터의 정확성을 보장했습니다.