염승준
Frontend Developer
브라우저 동작과 빌드 파이프라인을 직접 측정해 개발 환경과 사용자 경험을 함께 개선해 왔습니다.
- CI/CD 배포 시간
- 15~20분
- 7~9분대
- LCP (데스크톱)
- 5.24s
- 0.4s
- _app 청크 (Parsed)
- 1.25MB
- 207KB
- 전체 인증 프로세스
- 1,508ms
- 601ms
- Docker 이미지
- 2GB
- 115.9MB
- 주간 고착도
- 20%
- 40%
- 대회 개최
- 12개
- 70개
- 대회 참가 연인원
- 363명
- 5,040명
- 기록된 대회 경기
- 245건
- 6,272건
- 대회 재참가율
- 6.7%
- 28.6%
카메라파이 스튜디오 · 스포츠 대회 티켓 커머스. 2025년 4월 오픈 이후 누적 결제 약 2억 원, 2,944건(2026.11.06 기준). 최근 MAU 약 5만. 대회 운영 지표는 2026.01.01~11.04 누적과 전년 동기 비교이며, 운영 DB·GA4 기준입니다. 순거래액은 환불·취소를 제외한 결제 규모로, 회사 매출이 아닙니다. CI/CD 배포 시간은 GitHub Actions 프로덕션 배포 워크플로우 기준, 2026년 9월 이후 값입니다.
여기 있는 글은 서로 다른 프로젝트의 나열이 아닙니다. 하나의 프로덕션 서비스를 2년간 만들고 운영하면서 마주친 문제들을, 각각 다른 각도에서 파고든 기록입니다.
대부분의 작업은 같은 자리에서 시작했습니다. “지금 무엇이 느린지 모르겠다.” 배포가 왜 15분인지, 콘텐츠가 왜 5초 뒤에 보이는지, 답을 알아야 고칠 수 있는데 그 답이 안 보이는 상태였습니다. 그래서 매번 측정을 먼저 넣고, 그다음에 손을 댔습니다.
지금은 (주)볼트마이크로 카메라파이 스튜디오에서 스페셜리스트로 스포츠 대회 티켓 커머스와 운영 어드민을 개발·운영합니다. 2024년 7월 프론트엔드 인턴으로 합류해 실시간 중계 오버레이를 만들며 장시간 송출 시 타이머 누적 오차를 절대 시각 기준으로 바꿔 해결했고, 2025년 1월부터는 배포 파이프라인부터 결제 정합성까지 맡고 있습니다. 여러 입구의 QR 스캔이 주최자 화면에 실시간으로 모이는 현장 체크인도 설계해, 도입 5개월간 12개 대회에서 누적 2,038명을 처리했습니다. 2026년 하반기에는 결제가 끝난 뒤의 영역으로 범위가 넓어졌습니다. 참가자끼리 팀을 맺고 각자 결제하는 파트너 찾기, 그 협상이 오가는 1:1 채팅, 대회가 없는 날의 오픈플레이까지, 모두 같은 사람이 다시 오게 만드는 쪽입니다. 그사이 대회 재참가율은 6.7%에서 28.6%가 됐습니다.
글
이 문제들이 나온 순서
목표는 처음부터 하나였습니다. 고치고 확인하는 데 걸리는 시간을 줄이는 것. 그 시간이 짧아질수록 다음 문제가 보였고, 매번 병목의 성격이 달랐습니다.
| 순서 | 그때의 병목 | 무엇을 했나 | 글 |
|---|---|---|---|
| 1 | 배포가 15~20분이라 실험 자체가 부담 | 이미지 경량화, 레이어 캐시 재평가 | 1 |
| 2 | 실험이 가능해지자 드러난 직렬 호출 | 페이지 성격별 렌더링 재배분 | 8 |
| 3 | 번들이 무거워 좋은 기기에서만 빠름 | 동적 로딩 → 청크 분리 → 인증 설정 | 2 |
| 4 | 속도가 아니라 어긋남 | 앱 뒤로가기 이상 동작 원인 분해 | 5 |
| 5 | 빨라진 뒤에도 대회가 끝나면 접점이 끊김 | 결과를 안에서 기록하게 만들어 랭킹·DUPR로 연결 | 13 |
| 6 | 짝이 없어 신청 자체를 못 하는 사람들 | 파트너 찾기·분할 결제 화면, 역할 × 상태로 버튼 결정 | 12 |
| 7 | 협상이 플랫폼 밖(단톡방)에서 일어남 | 채팅을 붙이되 실시간의 경계를 다시 그음 | 11 |
앞을 끝냈기 때문에 다음이 보였습니다. 배포가 빨라지자 실험이 가능해졌고, 번들을 줄이고 나서야 인증이 병목이라는 게 드러났습니다.
여기까지가 “빠르게 만드는” 문제였습니다. 그다음에 남은 건 성격이 달랐습니다. 화면이 빨라져도 대회가 끝나면 접점이 끊긴다는 것. 그래서 5번부터는 속도가 아니라 연결에 관한 기록입니다.