안재관
Frontend Developer
GitHubjaekwanAHN
Portfolioahnjaekwanportfolio
Blogajkblog
Emailggstork@gmail.com

자기소개

2년간 가구 물류·배송 도메인의 B2B/Admin 및 B2C 웹 서비스를 개발·운영했습니다. JSP/jQuery 레거시와 Next.js/React 환경에서 기획·디자인·백엔드와 협업하며 서버 상태 관리, SSR, 공통 UI와 운영 흐름을 개선했습니다.

현업의 사용 흐름과 변경 영향 범위를 먼저 파악하고, 로그·E2E 테스트·성능 측정으로 문제를 재현하고 결과를 검증합니다.

핵심 역량

TanStack Query · 서버 상태 정합성
  • Query Key Factory — 도메인·scope·date 단위의 queryKey 계층을 factory 패턴으로 관리하고, mutation 영향 범위에 해당하는 캐시만 선택적으로 무효화
  • 캐시 동기화 전략 — 변경 결과의 완결성과 사용자 피드백 요구에 따라 invalidateQueries, setQueryData, 낙관적 업데이트·롤백을 구분 적용
Next.js · SSR / Hydration
  • 서버 데이터 전달 — 서버에서 pending query를 prefetch하고 HydrationBoundary로 스트리밍해 셸 렌더링을 막지 않으면서 클라이언트 캐시로 전달
  • Hydration 정합성 — 쿠키·고정 seed·mount gate를 상황별로 적용해 서버와 브라우저의 첫 렌더 입력을 맞추고, Playwright 실행당 hydration 경고 18건을 0건으로 제거
품질 자동화 · 회귀 방지
  • E2E 시나리오 — Playwright로 핵심 사용자 흐름과 오류·경합 경로를 자동화해 동작 변경의 회귀 여부를 검증
  • 결정적 검증 — 네트워크 응답 시점을 제어하고 테스트 계정·포트를 격리해 비동기 경합을 반복 가능한 조건에서 확인

경력 (2년)

하우저
프론트엔드 개발자 / 팀원(정규직)
2023.11 - 2025.10
문의 서비스(B2C·Admin) 및 배송 설정(B2B Admin) 고도화
Next.jsReactTanStack Querystyled-componentsReduxCypressDatadogGit
Query Key 재설계로 문의게시판 API 호출 약 50% 감소
  • 게시글·댓글 등록/수정 등의 mutation 이후 상위 queryKey를 기준으로 쿼리를 일괄 무효화하고 있어, 실제 변경과 관계없는 데이터까지 refetch되는 문제가 있었습니다.
  • mutation 전후의 API 요청 흐름을 추적해 기존 queryKey 구조를 파악하고, 갱신이 필요한 데이터만 refetch되도록 queryKey를 도메인/상세 단위로 재설계했습니다. mutation 응답만으로는 서버에서 결정되는 최종 상태를 정확히 구성하기 어렵다고 판단해 setQueryData 대신 invalidateQueries를 유지했습니다.
  • 서버와 클라이언트 상태의 정합성은 유지하면서 Datadog 기준 문의게시판 API 호출을 약 50% 줄였습니다.
제네릭 기반 다형성 Button으로 요소별 중복 제거
  • button, a 등 렌더링 요소마다 유효한 네이티브 props가 다르지만, 기존 Button은 as를 바꿔도 href, target 등을 정확히 추론하지 못했습니다. 요소별 컴포넌트를 따로 만들면서 스타일과 동작도 중복됐습니다.
  • as로 전달한 요소 타입을 제네릭으로 추론하고, 공통 props와 해당 요소의 네이티브 props를 결합하되 이름이 충돌하는 속성은 Omit으로 제외하는 다형성 타입을 설계했습니다.
  • 하나의 Button에서 렌더링 요소에 맞는 props와 자동완성을 제공하고 호환되지 않는 속성은 컴파일 단계에서 차단해, 스타일과 컴포넌트 인터페이스를 일관되게 유지했습니다.
의뢰 관리 백오피스 고도화 (B2B / Admin)
Next.jsReactTanStack Querystyled-componentsReduxJSPjQueryGit
서버 Prefetch·Query Hydration으로 설정 폼 초기값 안정화
  • 설정값을 클라이언트에서만 조회하면 로딩 뒤 입력값이 바뀌어 보일 수 있었습니다. 주요 데이터를 서버에서 prefetch한 뒤 TanStack Query의 dehydrate·hydrate로 전달해 첫 렌더부터 저장된 설정값을 노출했습니다.
  • 서버 상태의 조회·변경은 도메인별 커스텀 훅으로 분리하고, API 응답을 화면 모델로 변환하는 로직은 별도 함수로 두어 설정 항목 추가 시 데이터 처리와 UI의 변경 범위를 분리했습니다.
  • 서버에서 조회한 값을 기준 상태로 두고 사용자의 미저장 편집 상태를 분리해, 여러 설정을 검토한 뒤 명시적으로 일괄 저장하는 흐름을 구현했습니다.
URL 기반 검색 상태와 역할별 UI 노출 조건을 적용한 문의 게시판 개발
  • 검색 조건을 개별 상태로 관리해 필터 조합과 초기화 로직이 분산되고, 새로고침이나 URL 공유 시 조건이 유지되지 않았습니다. 여러 검색 조건을 하나의 필터 상태로 통합하고 URL 쿼리와 양방향 동기화해 같은 URL에서 동일한 검색 조건으로 조회를 다시 실행하도록 했습니다.
  • 사용자·회사 유형에 따른 버튼·필터·옵션의 노출 조건을 커스텀 훅에 모으고, UI 컴포넌트는 계산된 결과만 사용하도록 분리해 역할 추가 시 수정 지점과 조건 누락 가능성을 줄였습니다.

프로젝트

취성 (chuksung) (개인 프로젝트)
2026.03 -

취업 준비생의 목표 설정·실행·기록을 일간/주간/월간 단위로 관리하는 웹 애플리케이션.

배포chuksung.vercel.app
GitHubgithub.com/jaekwanAHN/chuksung
Next.jsReactTypeScriptZodTailwind CSSTanStack QueryPlaywrightLighthouse
데이터 규모를 통제한 재측정과 렌더 범위 축소로 TBT 611ms → 171ms 개선
  • 취업공고 페이지의 Lighthouse Performance가 81점, TBT가 611ms까지 저하됐지만 원인이 된 코드 변경을 찾지 못했습니다. 측정 조건을 다시 확인해 보니 테스트 데이터가 태스크 약 120건에서 9,100건, 취업공고가 0건에서 200건으로 늘었는데도 기록에 데이터 규모가 빠져 있어 서로 다른 조건을 비교하고 있었습니다.
  • 측정 결과에 데이터 행 수를 함께 기록하고, 규모가 5%이면서 10건 이상 달라지면 비교 조건 불일치 경고를 표시했습니다. 프로덕션 빌드에서 5회 측정한 중앙값을 사용해 실행 편차도 줄였습니다.
  • Lighthouse audit와 메인 스레드 지표를 함께 분석해 DOM 증가에 따른 Style & Layout 비용을 병목으로 특정하고, 한 번에 렌더링하는 공고를 20개로 제한했습니다. 동일 조건에서 Performance 81→95점, TBT 611→171ms, DOM 노드 5,995→778개, Style & Layout 1,257→418ms로 개선했습니다.
AI 에이전트 작업 절차와 검증 기준 문서화
  • 작업마다 같은 절차를 다시 설명하고 이슈 종류와 무관하게 동일한 검증을 반복하는 문제를 줄이기 위해, 이슈 선정 → 워크트리 생성 → 증거 선택 → 계획 승인 → 구현 → 검증 → PR 절차와 금지 규칙을 저장소 문서로 정리했습니다.
  • 성공 기준에 따라 행동 재현·구조 확인·정량 기준선·외부 관측 중 필요한 증거를 선택하고, 변경 범위에 맞는 검증만 실행하도록 기준을 구분했습니다.
  • 경합 가드·하이드레이션·성능 측정의 설계 근거와 한계를 문서화하고 코드에는 참조 경로를 남겼습니다. 병렬 작업은 포트와 테스트 계정을 슬롯별로 격리해 다른 브랜치의 서버나 데이터를 재사용해 발생하는 테스트 오탐을 막았습니다.

학력

국민대학교 컴퓨터공학과 학사 졸업

2021.02

자격증

정보처리기사

2020.12