첫 커밋부터 1,036개 센터까지, 측정하고 검증하는 프론트엔드
<aside>
💡
피트니스 센터 CRM·ERP SaaS 어시스트핏에서 웹 프론트엔드 개발자로 3년 5개월째 일하고 있습니다.
초기 멤버로 입사했을 당시 개발자는 백엔드·앱 각 1명뿐이어서 웹 프론트엔드는 혼자 맡았고, 출시 이후 프론트엔드 동료들이 합류했습니다.
본사 운영 어드민과 센터용 CRM 웹을 저장소 생성부터 맡아 출시했고, 지금까지 운영하고 있습니다.
GitHub · 기술 블로그
</aside>
💼 실무 프로젝트
어시스트핏 CRM 웹
주식회사 에이피티플레이
웹 프론트엔드 개발자
23.05 ~ 재직 중
(CRM 웹은 23.08부터)
전국 피트니스 센터가 쓰는 CRM·ERP SaaS 어시스트핏의 센터용 웹입니다
센터 직원이 종일 켜 두고 회원, 이용권, 결제, 수업 일정을 관리합니다
개발자 3명(백엔드·앱·웹)으로 시작, 웹 프론트엔드 담당 (출시 후 프론트엔드 동료 합류)
누적 1,036개 센터 가입(2026년 10월 기준)
사용 기술 스택
- Next.js, TypeScript, TanStack Query, Jotai, Tailwind CSS, Jest, React Testing Library, Sentry, Storybook, pnpm·Turborepo
What did I do
- 저장소 생성부터 11개월 만에 정식 출시 (2023.08.28 → 2024.08.09)
WHY? SPOEX 박람회 시연판(2024.02), 데모 운영 배포(2024.04), 오픈 베타(2024.06)를 거쳐 출시했고, 출시까지 PR 264건 중 257건을 작성했습니다.
- Next.js 마이그레이션 성능 저하 측정과 SSR → TanStack Query 전환 (2026.06 배포)
WHY? 팀의 Next.js 14 → 16 마이그레이션에 합류해, 16 빌드에서 첫 응답(TTFB)이 392ms에서 2,813ms로 느려지는 것을 배포 전에 측정했습니다. 16을 유지하며 고치는 안과 15 기반으로 SSR 데이터 요청을 TanStack Query로 옮기는 안을 각각 프리뷰 URL에 배포해 실측했고, AWS Amplify의 공식 지원 범위(Next.js 15까지)도 근거로 삼아 15 기반 전환을 제안했고, 측정 결과를 팀에 공유해 합의한 뒤 업무 영역별로 옮겼습니다(React 19·Tailwind v4·Recoil → Jotai 포함). 회원 상세 파일럿에서 TTFB 407ms로 기존(14: 392ms) 수준을 지켰습니다. 캐시 무효화 매핑을 전수 대조해 저장 후 화면 반영 누락 7건을 고쳤습니다.
- 사내 디자인 시스템 모노레포 유지보수 (2025.07 ~ 2026.08)
WHY? CRM 화면이 쓰는 공통 컴포넌트는 사내 디자인 시스템(@aptplayinc/ui)으로 함께 관리합니다. pnpm workspace·Turborepo 모노레포(primitives·ui·icons·storybook)에 Chip 컴포넌트와 Storybook 스토리를 추가하고, UI 패키지 exports와 GitHub Packages npm 배포, 배포 알림을 설정했습니다(2025.07). CRM을 Tailwind v4로 옮길 때는 디자인 시스템에도 tailwindcss peerDependency, tailwind-merge 설정·v4 유틸 export, Jest용 CJS export를 추가해 0.1.22-beta.0·beta.1로 배포하고 CRM에 적용했습니다(2026.05). 기존 플러그인 경로에는 deprecate 경고를 넣고 Storybook 설정 가이드를 남겼으며, 저장소에 커밋돼 있던 npm 토큰은 CI 환경 변수로 옮겼습니다.
- 협업 기반 구축: 브랜치 전략, 커밋 규칙, PR 템플릿 (2024.04)
WHY? 브랜치 전략(develop → QA → 운영), 커밋 규칙, PR 템플릿을 만들고 Sentry 연동과 GitHub Actions로 QA·운영 배포 시 lint·빌드 검사, Slack 알림을 추가했습니다. 이후 합류한 동료들도 같은 흐름으로 작업하고 있고, PR은 CodeRabbit AI 리뷰와 CTO·팀장·팀원 코드 리뷰를 거쳐 머지합니다. 출시 후에는 동료 PR 352건을 리뷰하고 QA 이슈 646건 대응에 참여했습니다. 기획·디자인 리뷰에도 참여하고, Java 백엔드의 Swagger 문서를 기준으로 REST API를 연동하면서 응답 구조(interface)는 클라이언트에서 쓰기 편한 형태로 제안해 왔습니다.
- 운영자 요청을 기능과 정책으로
WHY? 매년 박람회 현장에서 만난 센터 운영자와, 센터를 직접 운영하는 회사 대표(주 1~2회 면담)에게 들은 불편을 주간 회의에 올렸습니다. 여러 회원의 이용권을 한 번에 연장하는 단체 연장을 건의해 개발하고 연장 수정 정책을 정했으며(2024.09 릴리스), 메시지 머니 충전 문자와 무료 앱 알림(2025.10 ~ 2026.02 개발)으로 2026년 문자 9,050건과 앱 알림 19,620건이 발송됐습니다.
- 정기 배포 운영과 오류 대응
WHY? 출시 후 수요일 정기 배포와 hotfix로 태그 142개를 릴리스했습니다. 2,000행 목록의 Chrome 멈춤을 가상 스크롤로 고치고(2025.11), Sentry에서 찾은 로그인 만료 무한 로딩(2026.07)과 30일간 3,867회 발생하던 계약 관리 화면 진입 오류(2026.09) 등을 수정했습니다. 이 수정을 배포한 직후부터 해당 오류는 0건이고, CRM 운영 환경의 주간 오류 이벤트는 평균 약 930건에서 약 110건으로 줄었습니다.
본사 운영 어드민
23.05 ~ 재직 중
본사 직원이 앱 회원, 이벤트, 영업 기록을 관리하는 내부 도구입니다
What did I do
- 첫 커밋부터 첫 QA 배포(v0.0.1)까지 57일
- 2025.11부터 문자 충전·환불, 발신번호 심사, 수신거부 번호 관리 화면 담당
밀크티 하루하나
뉴클 주식회사
퍼블리셔
22.07 ~ 22.10
천재교육 초등 교육 서비스 "밀크티 하루하나" React 웹앱 (사용자 화면·어드민)
What did I do
- 퍼블리싱과 고객사 담당자 소통 담당, 결함 약 210건 처리
🤖 AI 활용 경험
반복되는 일은 AI 스킬로 만들어 팀이 함께 쓰게 하고, AI 결과물은 검증을 거쳐 받아들입니다
- 반복 작업을 팀 공유 스킬로 (2026.01 ~ 10)
WHY? 같은 설명과 같은 작업을 매번 반복하지 않도록, CRM 웹 팀이 함께 쓰는 Claude 저장소에 팀 개발 가이드 스킬(assistfit-crm)을 정리했습니다. endpoint 하나를 주면 Swagger에서 요청·응답 인터페이스를 확인하고 MSW 목, API 함수, React Query 훅까지 팀 규칙대로 만드는 api-from-swagger(2026.07), Sentry 미해결 오류를 한 번에 분류하는 sentry-triage와 Jira QA 티켓으로 등록하는 sentry-to-jira(2026.10)를 추가했습니다. 코드를 근거로 화면 설명서를 만드는 스킬(page-guide)로는 화면 가이드 20개를 작성했습니다.
- 리뷰 자동화: 3개 모델 교차 리뷰 스킬 (2026.09)
WHY? 모델 하나의 리뷰는 놓치는 것이 있어, 같은 diff를 3개 모델이 따로 리뷰한 뒤 서로 반박하게 하는 교차 리뷰 스킬(orca-cross-review)을 만들어 PR로 팀에 공유했습니다. Orca 다중 에이전트 리뷰로 로그아웃 설계 결함 3건을 사전에 찾았습니다.
- AI가 작성한 코드도 다른 코드와 같이 PR로 올려 CodeRabbit AI 리뷰와 CTO·팀장·팀원 코드 리뷰를 거칩니다
- API 인증 공통화 리팩터링을 AI 워커 7개로 병렬 분업 (2026.09)
WHY? 티켓 15개를 순서대로 처리하면 오래 걸려 병렬 진행을 제안했고, 워커가 늘면 범위 이탈과 검증 누락이 생기기 쉬워 작업 범위·티켓별 검증 5종·보고 형식을 공통 작업 지침으로 정했습니다. 워커는 커밋만 하고, 합치기와 Jira 전환은 통합 단계에서 tsc·eslint·jest로 다시 검증한 뒤 진행했습니다. AI가 범위 밖 티켓까지 손대자 바로잡아 지침에 범위를 명시했고, 토큰 낭비를 보고 워커 모델을 바꿨습니다. 하루 만에 티켓 15개를 통합 브랜치에 합치고 tsc·eslint 오류 0, 테스트 536개 통과를 확인했습니다(현재 QA 단계).
- 테스트를 통과한 AI 구현을 배포 환경에서 다시 검증 (2026.09)
WHY? 로컬 테스트 통과와 배포 환경 동작은 다른 문제라고 봤습니다. 서버가 토큰을 붙여 API를 대신 호출하는 프록시를 AI 리뷰 단계에서 다시 보며, 배포했다면 전체 조회 403과 삭제 API 502가 났을 결함 2건을 고쳤습니다. 이어서 코드를 고치지 않는 관찰 전용 브라우저 에이전트로 프리뷰 환경을 실측해 업로드 5MB부터 413, 장시간 연결 약 30초 끊김이라는 호스팅 한계를 찾았고, 이 수치를 근거로 백엔드와 협의해 업로드·엑셀 등 15곳을 프록시 대상에서 뺐습니다.
- 구현 AI와 검증 AI 분리 (2026.09 ~ 10)
WHY? 구현 AI의 "일치함" 보고는 검증되지 않은 주장이라 판정은 읽기 전용 리뷰 AI에게 맡겼습니다. 어드민 예약 내역 모달은 아직 운영에 배포되지 않은 백엔드 API의 ID와 응답 형태를 구현 전에 백엔드 PR 소스로 먼저 확정했고, 회귀 검사 스크립트에 결함을 일부러 넣어 FAIL이 나는지 확인한 뒤 13/13 통과로 머지했습니다. 랜딩 리뉴얼(80파일)은 섹션·폭별 합성 이미지와 file:line 근거로만 판정하게 했고, 검증이 놓친 중간 폭 사진 깨짐과 콘텐츠가 사라진 회귀, 이미지 화질 저하는 직접 찾아 검증 폭을 6개에서 12개로 늘리고 피그마 원본 이미지로 바꾼 뒤 배포했습니다.