네 번째 글입니다. 이번에는 6개월 동안 일한 스타트업 이야기입니다.
5월부터 10월까지 비건 밀키트 스타트업 슬런치팩토리에서 자사몰 프론트엔드를 맡았고, 이번 달로 계약이 끝났습니다. 초기 구축부터 토스페이먼츠 결제 연동, 런칭과 운영까지 했는데, 프론트엔드는 사실상 저 혼자였습니다. 실제 돈이 오가는 서비스를 처음부터 만들어 본 건 이번이 처음이었습니다.
6개월 동안 커밋 623개, PR 245개를 남겼습니다. 그중 가장 기억에 남는 건 이 장면입니다.
결제창을 닫았을 뿐인데 쿠폰이 사라졌습니다. 정확히는 묶였습니다. 결제창을 띄우려면 주문이 먼저 있어야 해서 결제 전에 주문을 만들었는데, 서버가 이 시점에 쿠폰을 잡아 두고 있었던 겁니다. 사용자가 나가 버리면 되돌릴 방법이 없었고, 쿠폰 목록엔 '사용 가능'으로 뜨는데 고르면 에러가 났습니다.
자사몰 전반: 스토어, 장바구니, 토스 결제, 정기구독, 마이페이지, 리뷰, 레시피 235종
결제 흐름 설계: 금액은 서버만 정하고, 프론트는 받은 값을 그리기만 하도록 정리
결제가 끊기는 8가지 상황(창 닫기, 새로고침, 재시도, 토큰 만료 등)을 체크리스트로 만들고 하나씩 처리
CI가 전혀 없던 레포에 PR 게이트와 Playwright E2E 두 트랙(PR마다 19개 / 야간 118개)을 붙임
성능 측정: 홈 Speed Index 11.5초 → 3.0초, 하단 이미지 16.8MB → 296KB
어드민: 상품·재고·출고·환불 관리 화면 초기 구축
안전망을 늦게 깔았습니다. 쿠폰 사고는 8월 초였고, E2E가 붙은 건 8월 중순이었습니다. 순서가 반대였다면 같은 사고를 운영이 아니라 PR에서 만났을 겁니다.
그리고 성능은 아직 사람이 지킵니다. Lighthouse를 CI에 붙이지 못해서, 성능 회귀는 여전히 제가 직접 재야 알 수 있습니다.
결제를 처음 붙이시는 분이라면 이것만 가져가셔도 됩니다.
결제에서
프론트는 돈을 계산하지 않습니다. 배송비가 프론트 상수(3,500원), API 문서, 실제 서버 응답(0원) 세 군데에서 다 달랐습니다. 정책을 프론트가 알고 있으면, 정책이 바뀌는 순간 화면은 거짓말을 합니다.
결제는 반드시 중간에 끊깁니다. 성공 경로는 한 줄이고 실패 경로는 여러 갈래입니다. 프론트가 설계해야 하는 건 대부분 실패 쪽이었습니다.
같은 요청이 두 번 와도 결과는 한 번이어야 합니다. 새로고침, 자동 재시도 같은 끊김은 전부 이 원칙(멱등성)으로 막았습니다. 결제 요청은 자동 재시도하지 않습니다.
품질에서
결제를 부르지 않고 결제를 검증하세요. 토스 SDK를 스텁으로 바꾸고, "결제 서버 요청 0건"을 확인하는 테스트를 따로 뒀습니다.
측정은 한 번의 숫자를 믿지 않습니다. 같은 화면도 잴 때마다 값이 널뛰어서, 5번 재서 중앙값을 썼습니다.
일하는 방식에서
AI는 맥락을 모릅니다. "금액은 서버가 정한다"를 문서에 적어 두지 않으면, AI는 친절하게 프론트에서 합계를 계산해 줍니다. 코드는 AI와 짰지만, 원칙은 직접 md 문서로 남겼습니다.
기능보다 도메인을 먼저 이해해야 합니다. 마일리지, 쿠폰, 구독, 환불이 늘어날수록 화면을 만드는 시간보다 정책을 이해하는 시간이 더 길어졌습니다.
결제가 끊기는 8가지 상황 체크리스트 전체, 배송비·마일리지 금액 문제를 고친 과정, 이미지 캐시 때문에 홈이 21.5MB를 받던 사건, 스켈레톤 전후 비교, 그리고 추천하는 책 세 권까지 자세한 이야기는 velog에 정리했습니다.
👉 전체 글 보러 가기 (velog) https://velog.io/@kdy9883/slunch-factory-retrospective
