느린 화면과 복잡한 구조를
측정 가능한 개선으로 바꿉니다

대표 사례 01 · Performance

선물찬스 — RN 웹뷰 기반 사내 기념일 복지 상품 구매 서비스

웹뷰 초기 로딩 5초 문제 개선

앱 진입 시 약 5초간 흰 화면이 노출됐습니다. 처음 적용한 스플래시 화면은 대기 시간을 가릴 뿐 실제 첫 로딩 시간을 줄이지 못했습니다. 그래서 화면 처리가 아니라 초기 다운로드에 포함된 JavaScript의 구성과 크기를 원인으로 보고 빌드 산출물을 분석했습니다.

빌드 산출물을 확인해 보니 초기 청크에 첫 화면과 무관한 라이브러리까지 전부 들어 있었습니다. 라이브러리별 실제 사용 시점을 조사해 Vite manualChunks로 xlsx(엑셀 다운로드), Lottie(탭바), framer-motion(모달), GSAP(가입 페이지), react-table(테이블 페이지)을 지연 로딩 청크로 분리했습니다. 진입점 root.tsx의 GSAP import를 제거해 무조건 초기 번들에 포함되던 것을 사용처로 옮겼습니다.

대표 사례 02 · Performance

이미지 전송 최적화 — CloudFront + Lambda 자동 WebP

이미지 전송 병목 진단

메인 페이지가 느리다는 체감 이슈가 있어 리소스별 응답 시간을 실측했습니다.

파이프라인 구축

4번 이슈는 코드가 아니라 캐싱과 포맷 문제였습니다. 이미지를 S3에서 직접 받아오는 구조였습니다. CDN이 없어 캐싱이 되지 않으니 같은 이미지를 n번 요청하면 서울 리전 버킷에서 n번 그대로 나갔고, 포맷도 PNG/JPEG 원본이었습니다.

문제를 둘로 나눴습니다. 반복 호출은 CloudFront를 앞에 두면 코드 변경 없이 줄어듭니다. 포맷은 어드민이 이미지를 올릴 때마다 사람이 변환할 수 없으므로 자동화가 필요했고, 업로드 이벤트에 반응하는 Lambda를 골랐습니다. 변환을 백엔드 업로드 API에 넣으면 업로드 응답에 변환 시간이 붙고 변환 실패가 업로드 실패가 되는데, S3 트리거는 그 둘을 떼어놓습니다. 새로 올라오는 이미지부터 적용하고, 이미 쌓여 있던 기존 이미지는 다음 단계로 미뤘습니다.

결정 1 — 순서. “전부 WebP로 바꿔달라”고 백엔드에 요청하는 게 직관적이지만, S3 직접 URL에 확장자만 바꾸면 CDN 이득이 없고 나중에 CloudFront를 붙일 때 URL을 또 바꿔야 합니다. CloudFront를 먼저 붙이고, 백엔드 변경은 설정 1줄 + 코드 1줄로 최소화했습니다.

결정 2 — 변환 시점. S3 트리거(업로드할 때 미리 변환)와 Lambda@Edge(요청할 때 실시간 변환)를 비교했습니다. Lambda@Edge는 Accept 헤더로 브라우저의 WebP 지원 여부를 판별해 자동 분기하므로 구형 브라우저까지 대응됩니다. 선물찬스는 자사 앱 웹뷰가 주 환경이라 그 대응이 필요하지 않았습니다. 원본과 WebP를 둘 다 저장해 S3 비용이 2배가 되지만, 구현과 운영이 단순한 S3 트리거를 선택했습니다.

기존 이미지 무중단 배치 마이그레이션

파이프라인은 신규 업로드에만 동작했고 기존 이미지 전량은 원본 포맷으로 남아 있었습니다. Lambda 하나로 버킷 전체를 순회하는 방식은 15분 실행 제한에 걸릴 것이 명확했고, 대상 개수를 미리 알 수 없어 “돌려보고 실패하면 재시도”는 위험했습니다.

• 배치용 코드를 새로 만들지 않음. 기존 Processor가 eventSource로 S3 이벤트와 SQS 메시지를 판별해 함께 처리
• 멱등성 — 변환 전 HeadObject로 대상 존재를 확인하고 이미 변환된 건은 스킵 → 재실행해도 안전

대표 사례 03 · Architecture

통합관리 백오피스 — 어드민 3종 모노레포

시스템·셀러 어드민을 새로 구축하면서, 두 개의 화면을 각각 만드는 것이 아니라 앞으로 추가될 운영 주체까지 수용할 수 있는 통합 어드민의 기반을 먼저 설계해야 했습니다. 당시에는 확립된 디자인 시스템도, 추가될 어드민의 개수도 정해져 있지 않았습니다.

인증·레이아웃·권한별 메뉴·검색 폼·데이터 테이블처럼 모든 어드민이 반복해서 사용하는 영역과, 시스템·셀러처럼 업무별로 달라지는 영역을 나눴습니다. 프로젝트를 각각 만들면 공통 기능을 여러 저장소에서 중복 관리해야 하고, 새 어드민이 추가될 때마다 기반 구조부터 다시 구성해야 한다고 판단했습니다.

그래서 각 어드민은 독립적으로 개발·배포하되 공통 UI와 유틸리티는 패키지로 공유하는 pnpm workspace 기반 모노레포를 선택했습니다. 디자인을 동일하게 보이게 하는 것을 넘어, 공통 기능의 변경을 한 곳에서 관리하고 새로운 어드민을 기존 구조 위에 추가할 수 있게 하는 것이 목적이었습니다. 이후 영업대행 어드민을 추가하면서 구조를 바꾸지 않고 확장할 수 있음을 확인했습니다.

admin-monorepo/
├── apps/
│   ├── system-admin      ─┐
│   ├── seller-admin       │  workspace:* 로 참조
│   └── agency-admin       │
└── packages/             │
    ├── ui-components  ◄──┘  Atomic Design
    │   ├── atoms            Button · Select · RadioGroup
    │   ├── molecules        FormTextField · FileUploader
    │   └── organisms        DataTable · SearchFiltersTable
    ├── utils                공통 유틸
    └── mocks                MSW

모노레포의 공통화 범위는 UI에만 한정하지 않았습니다. 여러 어드민에서 반복되는 인증, 권한별 메뉴 구성, 검색 상태 관리도 공통 기반으로 설계했습니다. 인증은 localStorage 토큰 방식에서 HttpOnly Cookie + Silent Refresh 방식으로 전환해 XSS 발생 시 토큰이 직접 노출될 위험을 낮췄습니다. 메뉴 API를 기준으로 라우트를 동적으로 구성해 권한이나 메뉴가 변경돼도 프론트엔드를 다시 배포하지 않도록 했고, useParameterQuery<T>로 URL과 검색 조건을 동기화해 새로고침과 뒤로가기 이후에도 조회 상태가 유지되도록 했습니다.

• SSE 스트리밍 안정화 — 간헐적 요청 실패로 데이터가 불안정했습니다. 실패 요청이 한꺼번에 재시도되지 않도록 Promise 기반 지수 백오프를 적용하고 최대 3회로 제한해 연결 안정성을 높였습니다.
• 채팅 서비스 레이어 분리 — 로직이 컴포넌트에 흩어져 중복과 테스트 난이도 문제가 있었습니다. 싱글톤과 커스텀 이벤트 이미터로 상태 관리·이벤트 전파를 UI 바깥으로 분리해 코드 중복 40% 감소.
• 클라이언트 보안의 한계 인식 — 비회원 PDF 노출 제한에 CSS 블러를 썼는데 개발자 도구로 우회 가능한 취약점을 발견했습니다. 클라이언트에서의 제한은 근본적으로 우회 가능하다는 점을 인정하고, 라우터 기반 인증 미들웨어로 서버에서 콘텐츠를 동적 제어하도록 전환해 회원가입 유도율 10% 증가.
• 모바일·리소스 최적화 — safe-area-inset으로 노치 영역에서 주요 UI가 가려지는 문제를 해결하고, SVG 스프라이트로 반복 아이콘의 HTTP 요청 수를 줄였습니다.

직무명은 퍼블리셔였으나 반응형 설계, 크로스브라우징, 웹 접근성, Core Web Vitals 개선 등 프론트엔드 실무 전반을 수행했습니다.

• 반응형 웹 — Mobile First 기준 320px ~ 1920px 대응. Flexbox/Grid 유동 재배치, srcset/sizes 해상도별 이미지. 좌석 선택 UI처럼 인터랙션이 복잡한 컴포넌트도 화면 크기별 조작 방식을 설계.
• Core Web Vitals / SEO — Lighthouse 분석으로 이미지 용량과 렌더 블로킹을 원인으로 특정. WebP + <picture>, loading="lazy", LCP 대상 preload, minify, font-display: swap을 적용해 LCP를 4초대에서 2초대로 개선하고 검색 엔진이 페이지를 안정적으로 수집할 수 있도록 기술적 SEO 기반을 정비했습니다.
• 웹 접근성 — 시맨틱 마크업, 대체 텍스트, 키보드 내비게이션, 색상 대비 4.5:1 이상. NVDA·VoiceOver로 실제 검증. Lighthouse 접근성 60점대 → 90점대 (WCAG 2.1 AA).
• 크로스브라우징 — PostCSS/Autoprefixer, core-js 폴리필, Can I Use 사전 확인 프로세스. BrowserStack으로 IE11 포함 실기 테스트.