에이치티비욘드
커뮤니티 서비스 운영툴 / 파트너스 플랫폼
전국 500개 단지·MAU 10만 규모의 아파트 커뮤니티 플랫폼. 5종 예약·결제·이용권이 커뮤니티·파트너스 두 프로덕트에 걸쳐 운영되는 환경에서 기능 개발과 아키텍처 개선을 병행 수행
주요 성과
- 시간·공간·강좌·숙박·레슨 등 5종 예약 도메인과 PG·관리비 결제, 이용권 관리가 커뮤니티·파트너스 두 프로덕트에 걸쳐 운영되는 환경에서 기능 개발과 아키텍처 개선 병행
- JS→TS 마이그레이션을 핵심 메뉴 4개 영역에서 단계적 진행. 도메인 간 결합이 강한 부분은 인터페이스 우선 정의 후 구현체 이관하여 운영 중단 없이 완료
- 서버 상태를 Redux→React Query로 분리. 도메인별 queryKey 컨벤션·invalidation 규칙 문서화 후 팀 전파
- Axios interceptor 공통 에러 처리로 외부 연동(PG/관리비) 실패 메시지를 도메인 단위로 일관화
- 팀 내 첫 프론트엔드 테스트 체계(Jest+MSW) 도입 주도. 핵심 결제·예약 플로우부터 적용하여 배포 후 핫픽스 월 평균 5건 → 1건 감소
- 기획·디자인 협업: 예약 창구 중복 검증 결과를 단일 에러가 아닌 충돌 자원 목록 모달로 보여주도록 역제안 → 운영팀이 충돌 자원을 즉시 식별·재배정 가능하도록 개선
- 기획·디자인 협업: 예약 시간 설정 화면 복잡도가 높아 고객사가 직접 설정에 어려움을 겪던 상황. 정보 그룹 단위 박스 처리·배치 재구성을 역제안하여 진입 장벽 완화
운영하며 바꾼 것들
3년 4개월간 굴러가는 제품 위에서 진행한 작업이라, 모든 변경의 전제가 “멈추지 않는다”였다. 상태 소유자를 나누고, 타입을 입히고, 테스트를 처음 들이고, 화면 설계를 역제안하기까지 — 각각을 어떤 순서로 했는지.
3년 4개월
재직 기간 중 가장 오래 맡은 제품
500개 단지
MAU 10만 규모
5종
예약 도메인 (시간·공간·강좌·숙박·레슨)
2프로덕트
커뮤니티 운영툴 · 파트너스
1. 상태의 소유자를 나눈다
서버에서 받아온 데이터와 화면 안에서만 쓰는 UI 상태가 하나의 Redux store에 함께 있었다. 문제는 불편함이 아니라 갱신 시점을 정할 수 없다는 것이었다. 캐시 정책이라는 개념 자체가 없으니 “언제 다시 받아오는가”가 화면마다 제각각이었고, 예약이나 결제처럼 여러 화면이 같은 데이터를 보는 도메인에서 stale 데이터 노출이 계속 쌓였다.
분리 자체보다 오래 걸린 건 그다음이었다. 도메인별 queryKey 컨벤션과 invalidation 규칙을 문서로 정리해 팀에 전파했다. 규칙이 없으면 같은 문제가 React Query 안에서 다시 생긴다 — 라이브러리는 캐시를 제공할 뿐 갱신 시점을 대신 정해주지 않는다.
2. 멈추지 않고 타입을 입힌다
파트너스 핵심 메뉴 4개 영역을 JS에서 TS로 옮기는 작업이었다. 운영 중이라 “전부 바꾸고 한 번에 배포”는 선택지가 아니었고, 도메인 간 결합이 강한 구간일수록 파일 하나를 건드리면 연쇄로 깨졌다. 그래서 순서를 뒤집었다 — 인터페이스를 먼저 세운다.
3. 팀의 첫 테스트 체계
팀에 프론트엔드 테스트가 한 줄도 없던 상태에서 Jest + MSW 도입을 주도했다. 커버리지를 목표로 잡는 대신 깨지면 가장 아픈 곳부터 — 결제와 예약 플로우에 먼저 적용했다. 테스트가 없던 팀에서 전면 도입을 선언하면 대개 아무도 쓰지 않게 되고, 효용이 즉시 보이는 지점에서 시작해야 다음 사람이 따라 쓴다.
stale 데이터 노출 이슈
약 90% 감소
← 상태 소유자 분리
배포 후 핫픽스
월 5건 → 1건
← Jest + MSW 도입
타입 관련 런타임 에러
약 70% 감소
← JS → TS 이관
창구 생성 포기 사례
약 90% 감소
← 충돌 자원 모달 역제안
4. 에러를 띄우는 대신 다음 행동을 준다
예약 창구를 만들 때 이미 잡힌 자원과 겹치면 “중복된 예약이 있습니다” 한 줄만 떴다. 운영팀 입장에서는 무엇과 겹쳤는지 모르니 하나씩 지워보다 포기하는 일이 잦았다. 검증 로직은 이미 충돌한 자원을 알고 있는데 화면이 그걸 버리고 있던 셈이다.
그래서 단일 에러 대신 충돌 자원 목록을 띄우는 모달을 기획·디자인에 역제안해 반영했다. 운영팀이 무엇과 겹쳤는지 즉시 보고 바로 재배정할 수 있게 되면서 창구 생성 포기 사례가 약 90% 줄었다.
→ 같은 맥락에서 예약 시간 설정 화면도 정보 그룹 단위 박스 처리와 배치 재구성을 역제안했다. 고객사가 직접 설정하다 막히던 화면이라, 기능을 더하는 것보다 이미 있는 정보를 다시 묶는 편이 빨랐다.