프로젝트 개요
2022.11 — 2022.12
BE 2 / FE 2 / UI·UX 1 / QA 1
백엔드 설계 · 개발
Situation — 탐색 단계부터 트렌비 안으로
명품 패션을 구매하려는 고객은 실제 착용 정보를 얻기 위해 인스타그램, 핀터레스트 등 외부 서비스를 먼저 탐색하고 트렌비로 유입되는 패턴을 보이고 있었습니다. 탐색 단계에서 트렌비가 빠져 있다는 것은 곧 잠재 고객을 경쟁사에 빼앗길 수 있다는 의미였습니다. 이에 트렌비는 흩어져 있던 스타일 착용 정보를 자체 서비스로 내재화하여 세 가지 목표를 달성하고자 했습니다.
- 고객 퍼널 확대: 상품 탐색 단계부터 트렌비로 유입 경로를 확장
- 고객 편의성 증대: 흩어진 스타일 정보를 내재화하여 타 서비스로의 이탈 방지
- 패션 라이프 필수 앱 포지셔닝: 스타일 탐색과 쇼핑 영감을 한 곳에서 제공
2개월이라는 빠듯한 일정 안에 백엔드 2명이 20여 개의 API를 설계하고 개발해야 했으며, 처음부터 안정적으로 확장 가능한 구조를 만들어야 했습니다.
Behavior — 설계부터 런칭, 그리고 데이터 분석까지
1. 서비스 아키텍처 설계
스타일 서비스를 안정적으로 제공하기 위해 관심사에 따라 세 개의 컴포넌트로 분리했습니다.
- style-service: 스타일 관련 비즈니스 로직을 수행하는 핵심 서비스
- display-gateway: 각 스타일을 Redis에 캐싱하여 style-service를 매번 호출하지 않도록 하는 캐시 레이어
- style-admin: 트렌비 사이트에 노출될 스타일을 관리하는 백오피스
2. 멀티 모듈 + 클린 아키텍처 기반 프로젝트 구성 (100%)
장기적으로 유지보수 가능한 코드베이스를 만들기 위해 Kotlin + Spring Boot 2 환경에서 멀티 모듈과 클린 아키텍처를 결합한 구조를 직접 설계하고 구성했습니다.
app-api: 외부에 노출되는 RESTful API 및 앱 동작 진입점application: 도메인 엔티티와 비즈니스 로직, 입출력 포트 정의adapter-http: 외부 서비스 호출을 위한 HTTP 클라이언트adapter-persistence: DB와 통신하는 영속성 레이어
의존성 방향을 안쪽(도메인)으로만 향하도록 강제함으로써 비즈니스 로직이 인프라 변경에 영향받지 않는 구조를 만들었습니다.
3. 핵심 기술 의사결정 — 해시태그 ERD 설계
서비스의 핵심 기능 두 가지는 연관 검색어 추천과 해시태그 기반 스타일 검색이었습니다. 이를 구현하기 위한 테이블 구조로 두 가지 방안을 제안하고 팀 회의를 통해 결정했습니다.
| 구분 | 제안 1 — 비정규화 | 제안 2 — 정규화 (채택) |
|---|---|---|
| 구조 | style 테이블에 해시태그를 문자열로 저장#메종#샤넬#캐쥬얼 |
style / hashtag / 관계 테이블 분리 |
| 장점 | 테이블 수 적음, 관리 포인트 감소 | Fulltext search MATCH...AGAINST 적용 용이, 중복 데이터 없음 |
| 단점 | 한 컬럼에 다중 해시태그 → 검색 알고리즘 튜닝 복잡 | 테이블 3개 조인 필요, 관리 포인트 증가 |
| 결정 근거 | — | 초기 데이터량이 적어 조인 비용 감당 가능, 검색 품질 우선 |
해시태그 검색 엔진으로는 Elasticsearch 도입도 검토했으나, 초기 셋업 및 운영 비용 대비 효과를 고려해 기존 MySQL의 Fulltext Search를 활용하는 방향으로 결정했습니다.
4. 백엔드 API 개발 (60%)
20여 개의 RESTful API 중 절반 이상을 직접 개발했습니다. 주요 기술 결정 사항은 다음과 같습니다.
- JPA + QueryDSL: 타입 세이프한 쿼리 생성 및 CRUD 구현.
@EnableJpaAuditing과 프로그래밍적 트랜잭션 관리 적용 - Flyway: DB 테이블 변경 이력을 코드로 관리하여 환경 간 스키마 일관성 확보
- MapStruct: 계층 간 객체 변환(DTO ↔ 도메인 ↔ 엔티티)을 컴파일 타임에 처리
- 테스트: 통합 테스트는 Testcontainers로 실제 DB 환경에서 검증, 단위 테스트는 JUnit5 + Mockito 활용
설계 과정에서 하나의 의미 있는 의사결정을 했습니다. "좋아요" 기능은 초기 설계 시 스프링 배치를 통해 주기적으로 집계하는 방식이 논의되었습니다. 하지만 "좋아요를 눌렀는데 숫자가 즉시 반응하지 않으면 사용자가 어색하게 느낄 것"이라는 의견을 제시했고, 초기 트래픽 수준에서는 배치 없이 즉시 반영하는 구조로 변경했습니다. 사용자 경험과 시스템 복잡도 사이의 트레이드오프를 현 서비스 단계에 맞게 판단한 결정이었습니다.
5. 런칭 1개월 후 데이터 분석 및 UX 개선 제안 (90%)
서비스 런칭 약 한 달 후, 쌓인 사용자 행동 데이터를 직접 분석했습니다. 2~3시간 분석 끝에 발견한 핵심 인사이트는 다음과 같았습니다.
"대부분의 사용자가 '인기' 탭에 접근한 뒤 상세 화면이나 상품 화면으로 넘어가지 않고 이탈합니다. 상품 상세 화면까지 도달하는 비율이 8% 미만입니다."
운영팀의 목표는 스타일 탐색에서 상품 구매까지의 전환율을 높이는 것이었으나, 실제 동선이 그것을 지원하지 못하고 있었습니다. 이에 "인스타그램처럼 스타일 상세 화면을 첫 화면으로 노출하는 구조로 변경하자"는 의견을 데이터와 함께 제안했고, 해당 의견이 채택되어 개발로 이어졌습니다.
Impact — 무장애 운영과 2배 높은 재방문율
- 무장애 운영: 서비스 런칭 이후 관련 장애 또는 SUS가 단 한 건도 발생하지 않았습니다. 멀티 모듈 + 클린 아키텍처 기반으로 구성된 구조가 안정적인 운영 기반이 되었습니다.
- 예상 밖의 주 사용자층 발견: SNS를 활발하게 사용하는 20~30대보다 40대 여성이 주 사용자임을 확인했습니다. 데이터 기반의 페르소나 업데이트가 이후 서비스 방향에 반영되었습니다.
- 높은 재방문율: 트렌비 내 타 서비스(10~20%) 대비 스타일 서비스의 재방문율(30~40%)이 약 2배 높았습니다. 패션 콘텐츠 탐색이라는 반복적 사용자 행동이 재방문을 만들어내고 있었습니다.
- UX 개선 제안 채택: 데이터 분석에서 발견한 낮은 상세 화면 전환율(8% 미만) 문제를 인스타그램식 상세 화면 우선 노출로 개선하자는 제안이 운영팀에 채택되어 개발로 이어졌습니다.
아쉬운 점
스타일 어드민에서 콘텐츠가 업데이트될 때 Redis 캐시를 즉시 무효화하는 메시지 시스템(Kafka 기반)을 구현하지 못한 점이 아쉬움으로 남습니다. 서비스 규모가 크지 않아 실시간 갱신의 우선순위가 낮아졌고, 관련 요구사항 발생 시 개발하기로 일정이 미뤄졌습니다. 이후 유사한 구조를 설계할 때는 초기부터 캐시 무효화 전략을 함께 정의해두는 것이 중요하다는 교훈을 얻었습니다.
정리하며
이 프로젝트는 2개월이라는 짧은 기간 안에 설계 결정, API 개발, 런칭, 데이터 분석까지 전 사이클을 경험한 프로젝트였습니다. 기술 선택에서 "지금 이 단계에서 필요한 복잡도는 어디까지인가"를 지속적으로 물었고, 그 결과 과도한 설계 없이 안정적으로 런칭하고 운영할 수 있었습니다. 또한 코드를 짜는 것에서 멈추지 않고 데이터로 사용자를 이해하고 서비스 방향에 기여한 경험은, 개발자가 비즈니스 관점을 함께 가져야 한다는 것을 실감하게 해 주었습니다.