저는 스타트업에서 팀 내 유일한 프론트엔드 개발자이자 PM 역할까지 맡고 있습니다. 그러다 보니 코드를 짜는 것만으로는 해결되지 않는 고민과 문제들을 자주 마주하게 됩니다.
이번 요금제 개편 프로젝트는 그 중에서도 정말 해결하기 어려운 문제였습니다. 단순한 UI 개선이나 기능 추가가 아니라, 서비스의 핵심적인 비즈니스 모델을 다시 설계해야 했기 때문입니다. 그리고 프로젝트를 리딩해야 한다는 부담감과 책임감도 그만큼 컸습니다.
이 글은 그 과정에서 제가 겪었던 고민과 배운점을 기록하고, 비슷한 상황에 계신 분들과 나누고 싶은 마음에 쓰여졌습니다.
🔍 프로젝트 개요: 왜 요금제를 전면 개편했는가?
이번 프로젝트의 출발점은 명확했습니다.
- 기존 시스템은 결제 관련 주요 키 정보를 프론트와 백엔드에서 직접 주고받는 구조였고, 보안 이슈와 결제 실패 시 대응의 한계가 있었습니다.
- 새롭게 B2B 고객을 대상으로 한 단체 구독권 기능을 요청받았지만, 기존 요금제 구조로는 이를 지원하기 어려웠습니다.
- 또한 유료 전환율을 높이기 위한 전략으로 ‘결제 시 1개월 추가 제공’ 이벤트도 함께 기획했습니다. 운영팀과 논의하여 요금제 정책과 연결된 이벤트로 설계했고, 사용자 전환 흐름을 만드는 데 중요한 시도였습니다.
이 모든 문제를 풀기 위해서는 요금제 자체를 다시 정의하고, 그에 맞는 시스템과 정책을 전면 재설계하는 것이 필수적이었습니다.
🛠 내가 맡은 역할: 기획부터 구조 설계, 프론트 개발까지
이번 프로젝트에서 저는 PM과 프론트엔드 개발을 동시에 맡아 전 과정을 리딩했습니다.
먼저 운영팀과 함께 요금제 조건과 가격 정책을 하나씩 정리하며 프로젝트를 시작했습니다. 이 과정에서 기존에 모호하게 정의돼 있던 “검사 수에 포함되는 곡의 조건”, “결제 실패 시 재처리는 어떻게 할지”, “구독권 변경 시 환불 기준은 무엇인지” 같은 부분을 모두 명확히 규정했습니다. 그리고 이렇게 정리한 내용을 정책 정의서와 서비스 기획서로 나누어 체계적으로 문서화했습니다.
기획이 어느 정도 정리된 뒤에는 백엔드에서 기존 API 리스트를 전달받아 누락된 기능을 도출하고, 필요한 신규 API 설계를 제안했습니다. 동시에 디자이너와 함께 변경 범위를 사전에 정리하고, 작업 과정에서 반복적으로 발생하는 수정 사항들을 빠르게 조율했습니다.
마지막으로 프론트엔드 코드 구현에 들어가서는 테스트 시나리오를 직접 작성해 다양한 케이스를 검증했고, QA까지 직접 진행하며 모든 흐름이 안정적으로 동작하는지 확인했습니다.
이번 프로젝트는 기획부터 개발, QA까지 전체 흐름을 처음부터 끝까지 책임져야 하는 만큼 많은 과제가 있었고, 과정에서 예상치 못한 어려움도 많이 마주하게 되었습니다.
🧩 어려웠던 점들: 일정, 협업, 그리고 무수히 많은 엣지 케이스
이번 프로젝트는 단순히 기능을 구현하는 수준을 넘어, 서비스 구조 전체를 재설계하는 일이었기에 예상보다 훨씬 많은 난관과 마주해야 했습니다. 특히 일정, 상태 분기, 그리고 협업 측면에서 복합적인 어려움이 있었습니다.
1. 일정 압박
8월에 예정된 대형 마케팅 일정에 맞춰 반드시 7월 내에 배포가 완료되어야 했습니다. 마감일은 조정 가능한 것이 아니라 고정값이었고, 동시에 1:N 검사 리포트 개편 프로젝트도 병행하고 있어 리소스와 집중력이 분산될 수밖에 없는 상황이었습니다.
두 프로젝트 모두 놓칠 수 없는 우선순위였기에, 병렬적으로 끌고 가는 데서 오는 체력적·정신적 부담이 상당했습니다.
2. 복잡한 상태 분기
요금제 조건, 구독 상태, 결제 실패와 환불 처리까지 고려해야 할 분기 조건이 매우 복잡했습니다. 디자이너와 함께 수많은 케이스를 일일이 분류해 UI를 정리하고, 테스트 과정에서 발견된 누락 케이스는 빠르게 공유해 수정하는 루틴을 반복해야 했습니다.
또한 국제화(i18n)까지 함께 고려해야 했기 때문에, 작은 문구 하나도 놓치지 않고 세심하게 다뤄야 했습니다.
3. 협업에서의 감정적 피로
이번 프로젝트 기간 동안 야근, 주말 근무를 하며 몰입했지만, 일부 일정이 반복적으로 지연되면서 심리적인 피로도 함께 누적되었습니다.
물론 모든 팀원이 같은 속도와 방식으로 일할 수는 없다는 것을 이해하고자 했지만, 속도차로 인해 일정 부담이 한쪽에 몰릴 경우 자연스레 감정적 노동까지 동반된다는 사실을 실감하게 되었습니다.
그럼에도 불구하고 전체 일정을 지키기 위해, 디자인이나 API가 완전히 준비되지 않은 상황에서도 레이아웃 구성이나 예상 mock data 작성 등 선행할 수 있는 작업들을 먼저 진행하며 흐름을 유지하고자 했습니다.
🧠 성장 포인트: 나는 시스템을 리딩할 수 있는 사람일까?
이번 프로젝트에서 가장 큰 성장은 단순한 개발 경험을 넘어 서비스의 핵심 영역을 스스로 리딩해 마무리했다는 자신감이 생겼다는 점입니다.
특히 협업과 일정 관리 측면에서 큰 변화를 느꼈습니다. 이전까지는 ‘할 일’을 나열하는 수준이었다면, 이번에는 예상되는 작업을 기획서를 기반으로 분류하고 체크리스트로 정리, 흐름을 도식화하면서 누락을 방지하는 루틴을 새로 실험해봤습니다.
그 결과 일정 예측이 훨씬 수월해졌고, 효율적인 커뮤니케이션에도 도움이 되었습니다.
그리고 무엇보다도, 완벽하게 준비된 상태가 아니더라도 지금 통제할 수 있는 부분부터 정리해나가는 것이 빠듯한 일정 속에서는 가장 효과적인 대응 전략이라는 걸 몸으로 체득했습니다.
🎯 다음을 위한 과제: 테스트 구조와 협업 구조의 성숙
이번 프로젝트에서는 빠르게 기능을 구현하느라 간단히 테스트 데이터를 return 값으로 넣어 단순하게 mocking을 진행했지만, 다음부터는 MSW나 mock 서버를 도입해 실제 흐름에 가까운 테스트 환경을 만들어보고 싶습니다.
또한 현재는 UI 기반의 수동 확인에 의존하는 부분이 많은데, 앞으로는 테스트 코드 기반의 검증 루틴을 적극 도입할 계획입니다. 특히 요금제 로직처럼 예외 케이스가 많은 민감한 영역에서는 필수라고 느꼈습니다.
협업에 있어서도, 모든 사람이 같은 열정을 가질 수는 없다는 현실을 받아들이는 동시에, 그로 인한 감정적 피로를 스스로 감당하지 않도록 건강한 경계와 구조를 설계하는 연습 역시 필요하다는 걸 절감했습니다.
🧭 이 프로젝트는 내게 어떤 의미였을까?
- 처음으로 비즈니스 모델의 근간을 리딩해본 경험이었고,
- 혼자서 기획, 개발, 테스트, 커뮤니케이션을 모두 이끌며 조직 내 리더십이란 무엇인지를 직접 부딪히며 배운 시간이었습니다.
- 끝없이 나오는 예외 상황들과 책임의 무게 속에서도, 시스템을 바라보는 시야와 자신감이 생겼다는 점에서 아주 의미 있는 성장의 기회였습니다.
이제는 단순히 “코드를 잘 짜는 사람”이 아니라,
“비즈니스를 기술로 연결해내는 사람”으로 조금씩 자라가고 있다고 느낍니다.
같은 고민을 하고 있는 다른 스타트업 개발자분들, 혹은 PM 역할까지 병행하고 있는 분들이 있다면,
이 긴 회고가 작은 공감이나 참고가 되었으면 좋겠습니다.
읽어주셔서 감사합니다 🙏