프로젝트 개요
2022.06 — 2022.07
BE 2 / FE 2 / UI·UX 1 / QA 1
시스템 설계 (100%)
들어가며
콘텐츠 관리 방식이 하드코딩에 묶여 있다면, 서비스 확장에는 항상 개발자가 필요합니다. 이 글은 트렌비에서 진행한 두 가지 연속된 프로젝트를 기록합니다. 첫 번째는 홈 화면을 CMS 기반으로 전환하여 기획팀이 콘텐츠를 직접 관리할 수 있도록 한 작업이고, 두 번째는 같은 철학 위에서 기획전 시스템 전체를 동적 플랫폼으로 재설계한 작업입니다. 두 프로젝트 모두 "개발자 없이 기획자가 운영할 수 있는 시스템"을 목표로 했으며, SBI(Situation → Behavior → Impact) 구조로 정리합니다.
Situation — 확장할 때마다 개발자가 코드를 고쳐야 했다
트렌비 홈 화면과 기획전 페이지는 모두 하드코딩 방식으로 관리되고 있었습니다. 새로운 콘텐츠 유형(타임딜, 이미지 배너 등)을 추가하거나 노출 순서를 변경하려면 매번 개발자가 직접 코드를 수정하고 배포해야 했습니다. 기획전 페이지도 마찬가지였습니다. 새로운 기획전이 열릴 때마다 개발자가 코드를 열어야 했으며, 시즌 프로모션이나 긴급 캠페인을 실행하고 싶어도 개발 일정이 없으면 불가능한 구조였습니다.
"새로운 배너를 넣으려면 개발팀에 요청해서 코드를 수정하고 배포해야 합니다. 그 사이에 시즌이 지나가는 일도 있었습니다."
확장성과 유지보수성이 모두 낮은 상태에서, 기획팀의 운영 속도는 항상 개발 일정의 한계를 넘지 못했습니다.
Behavior — 두 시스템의 설계와 실행
프로젝트 1. 홈 화면 CMS — JSON 타입 기반 유연한 콘텐츠 설계 (2022)
상품·이미지·타임딜 등 다양한 콘텐츠 유형을 단일 구조로 처리하기 위해, 콘텐츠 데이터를 MySQL JSON 타입으로 저장하고
@JsonType으로 역직렬화하는 방식을 설계했습니다. 이 접근 덕분에 새로운 콘텐츠 유형 추가 시 테이블 스키마를 변경하지 않아도 됩니다. 기획팀이 원하는 콘텐츠 유형을 어드민에서 직접 조합하고 순서를 조정할 수 있는 기반이 마련되었습니다.
개발 중반에는 협업 백엔드 개발자가 자리를 비워 공백이 생겼습니다. 제한된 시간 안에 소통과 개발을 모두 소화하기 위해 오전 소통·협의, 오후 집중 개발이라는 루틴을 세웠고, 프론트엔드 팀과는 전용 슬랙 채널을 별도 운영하여 대기 시간을 최소화했습니다.
프로젝트 2. 기획전 시스템 — 서비스 분리 · 전략 패턴 · PM 역할 병행 (2023)
홈 CMS에서 얻은 경험을 바탕으로, 기획전 시스템을 더 본격적인 플랫폼 구조로 재설계했습니다. 기획전 데이터를 서빙하는 display-gateway와 관리하는 plan-service로 역할을 분리했습니다. display-gateway는 Redis 캐싱으로 빠른 응답을 보장하고, 기획전 변경 시 Kafka 이벤트를 통해 캐시를 실시간으로 갱신하는 구조로 설계했습니다.
이미지형·상품 리스트형·텍스트형 등 다양한 기획전 모듈 타입을 하나의 코드 구조로 처리하기 위해 전략 패턴(Strategy Pattern)을 도입했습니다. 모듈 타입별 처리 로직을 인터페이스로 추상화하고, 새로운 모듈 타입이 추가될 때 기존 로직을 건드리지 않아도 되는 구조(개방-폐쇄 원칙)를 구현했습니다.
PM 없는 환경에서 API 스펙 설계 단계부터 프론트엔드와 긴밀히 논의하고, 개발 중간 단계마다 비즈니스 부서에 데모를 진행해 피드백을 즉각 반영했습니다. 막바지에 프론트엔드 구현 난이도로 인한 일정 지연 위험을 조기에 파악해 이해관계자와 협의하여 일정을 조정했습니다.
Impact — 기획자 자율 운영 실현과 개발 병목 제거
홈 CMS 도입 이후 처리 가능한 콘텐츠 유형이 2개에서 6개로 확장되었습니다. 렌더링 성능도 함께 개선되어 Speed Index는 5.0s에서 3.5s로 30% 단축되었으며, Total Blocking Time은 0.8s에서 0.6s로 줄었습니다.
기획전 시스템 재설계 이후에는 기획자가 직접 모듈을 조합하여 기획전을 생성·운영할 수 있는 Back-office 시스템이 완성되었습니다. 기획전 변경마다 필요했던 개발자 개입이 사라져 기획팀 운영 속도가 대폭 향상되었고, 3개월 내 안정적으로 배포를 완료했습니다.
핵심 교훈
- 스키마 유연성은 초기 설계에서 결정됩니다. JSON 타입 선택 덕분에 새 콘텐츠 유형이 스키마 변경 없이 추가될 수 있었습니다. 이 결정이 이후 확장의 속도를 결정했습니다.
- 전략 패턴은 확장 가능성을 코드 구조로 표현합니다. 새 모듈 타입이 추가될 때마다 기존 로직을 수정하지 않아도 되는 구조는 장기적으로 유지보수 비용을 낮춥니다.
- 캐시 갱신 전략은 처음부터 설계해야 합니다. Redis 캐시를 Kafka 이벤트로 무효화하는 흐름을 초기 설계에 포함했기 때문에 런칭 후 데이터 불일치 문제를 방지할 수 있었습니다.
- 인력 공백과 PM 없는 환경은 루틴과 주도성으로 극복할 수 있습니다. 소통 시간과 개발 집중 시간을 명확히 분리하고, 리스크를 사전에 이해관계자에게 공유하는 것이 일정을 지키는 핵심이었습니다.
정리하며
두 프로젝트를 통해 얻은 가장 큰 교훈은 좋은 아키텍처 설계가 기획팀의 자율성을 어떻게 높일 수 있는지를 직접 확인한 것입니다. 기술 결정 하나하나가 운영팀이 일하는 방식에 영향을 주고, 그 효과가 다음 프로젝트로 이어진다는 것을 실감했습니다. 유연한 데이터 모델, 서비스 분리, 전략 패턴 — 어느 것도 단독으로는 완성되지 않았고, 두 프로젝트에 걸쳐 점진적으로 완성된 결과였습니다.