프로젝트 개요
2023.01 — 2023.03
BE 1 / FE 1
프로젝트 매니징 병행
들어가며
기획자가 기획전 하나를 열기 위해 개발자에게 요청해야 한다면, 운영 속도는 항상 개발 일정의 한계를 넘지 못합니다. 이 글은 트렌비의 기획전 시스템을 하드코딩 방식에서 기획자가 직접 운영할 수 있는 동적 시스템으로 전환하고, PM 없는 환경에서 프로젝트를 이끈 과정을 SBI(Situation → Behavior → Impact) 구조로 기록합니다.
Situation — 기획전마다 개발자가 코드를 열어야 했다
기존 트렌비의 기획전 페이지는 하드코딩 방식으로 관리되고 있었습니다. 새로운 기획전이 열릴 때마다 개발자가 직접 코드를 수정하고 배포해야 했으며, 이로 인해 기획팀의 운영 속도가 개발 일정에 종속되는 비효율이 반복됐습니다. 시즌 프로모션이나 긴급 기획전을 열고 싶어도 개발 일정이 없으면 실행 자체가 불가능한 구조였습니다.
Behavior — 서비스 아키텍처 설계, 전략 패턴 도입, PM 역할 병행
1단계: 아키텍처 설계 — display-gateway + plan-service 분리
기획전 데이터를 서빙하는 display-gateway와 관리하는 plan-service로
역할을 분리했습니다. display-gateway는 Redis 캐싱으로 빠른 응답 속도를 보장하고, 기획전 변경 시 Kafka 이벤트를 통해
캐시를 실시간으로 갱신하는 구조를 설계했습니다. 서빙과 관리 책임을 분리함으로써 각 컴포넌트가 자신의 목적에 집중할 수 있게 했습니다.
2단계: 전략 패턴 도입으로 유연한 모듈 시스템 구축
이미지형·상품 리스트형·텍스트형 등 다양한 기획전 모듈 타입을 하나의 코드 구조로 처리하기 위해 전략 패턴(Strategy Pattern)을 도입했습니다. 모듈 타입별 처리 로직을 인터페이스로 추상화하고, 각 타입이 독립적으로 확장 가능하도록 설계했습니다. 새로운 모듈 타입이 추가될 때 기존 로직을 건드리지 않아도 되는 개방-폐쇄 원칙이 자연스럽게 구현되었습니다.
3단계: PM 역할 병행과 프론트엔드 협업
API 스펙 설계 단계부터 프론트엔드와 긴밀히 논의하여 복잡한 모듈 데이터 구조를 합의했습니다. 개발 중간 단계에서 비즈니스 부서에 수시로 데모를 진행해 피드백을 즉각 반영했으며, 매주 진행 상황을 Follow-up하여 잠재적 리스크를 점검했습니다. 막바지에 프론트엔드 구현 난이도로 일정 지연 위험을 조기에 파악해 이해관계자와 협의하여 일정을 조정했습니다.
Impact — 기획자 자율 운영 실현과 개발 병목 제거
기획자가 직접 모듈을 조합하여 기획전을 생성·운영할 수 있는 Back-office 시스템을 구축 완료했습니다. 기획전 변경마다 필요했던 개발자 개입이 사라져 기획팀 운영 속도가 대폭 향상되었습니다. 일정 조정 협의를 통해 3개월 내 안정적으로 배포를 완료했습니다.
핵심 교훈
- 전략 패턴은 확장 가능성을 코드 구조로 표현합니다. 새 모듈 타입이 추가될 때마다 기존 로직을 수정하지 않아도 되는 구조는 장기적으로 유지보수 비용을 낮춥니다.
- 캐시 갱신 전략은 처음부터 설계해야 합니다. display-gateway의 Redis 캐시를 Kafka 이벤트로 무효화하는 흐름은 초기 설계에 포함되었기 때문에 런칭 후 데이터 불일치 문제를 방지할 수 있었습니다.
- PM 없는 환경에서 개발자가 프로젝트를 리딩할 수 있습니다. 일정·리스크·이해관계자 소통을 개발자가 주도하는 경험은 기술 너머의 역량을 키우는 기회였습니다.
정리하며
이 프로젝트는 좋은 아키텍처 설계가 기획팀의 자율성을 어떻게 높일 수 있는지를 직접 확인한 경험이었습니다. 기술 결정 하나하나가 운영팀이 일하는 방식에 영향을 준다는 것을, 시스템이 실제로 돌아가는 것을 보면서 실감했습니다.