우당탕탕 beauty 풀한, 컬리 앱 서비스 런칭기

iOS 개발자 관점에서 뷰티 컬리를 어떻게 오픈했을까?

이규현 게시 날짜: 2023.04.11.

우당탕탕 일정

안녕하세요. 저는 미소가 아름다운 ~~(그래서 조커리라 불렸던🤡)~~
적극적인 오지라퍼 앱 개발자 이규현입니다.

일 년 동안 컬리를 다니면서 샛별 배송 확장, 연관 추천상품, 상품 개편, 뷰티 컬 리, 필터 등
크고 작은 프로젝트를 진행하였는데요, 그중에 뷰티 컬리를 개발하면서 제가 어떻게 마켓 컬리에 뷰티를 채웠는지
우당탕탕 뷰티 풀한, 컬리 앱 서비스 론칭기를 소개하려 합니다.

22년 컬리에는 커다란 산이 두 개 있었습니다. 상품 개편과 뷰티컬리…
8월이 오기 전에 배포가 되어야 한다!!!

이미 저는 상품 개편에서 장바구니 영역을 처리하고 있었고 개발은 완료되었지만,
QA 기간이 겹치는 부분이 있었습니다.

상품 개편의 경우 코어시스템이 변경되면서 정책 미스나, 예상치 못한 사이드 이펙트가 발생할 수 있기 때문에
두 가지를 안고 가져가야 하는 상황이었습니다.

일정이 촉박하지만
회사 입장에서는 소량 취급하던 뷰티 제품을 본격적으로 판매하여 next generation을 준비하고 있었고,
사업전략, 마케팅 등 비즈니스 요구사항에 의해 배포 시점이 타켓팅 되어 있었습니다.
다음을 향한 시발점이기에 열정을 들이붓기로 하였습니다.

이를 위해서는 선택과 집중이 필요한 상황!!!
그래서 저는 초기 일정에는 상품 개편 QA에 집중하고,
뷰티 컬리에 대해서는 빠르게 개념과 정책을 이해하고,
언제든지 개발에 착수할 수 있는 환경을 만들기로 했습니다.

환경을 만들기 위해 다음과 같은 일련의 작업을 시작하였습니다.

놓치지 않을 거예요 - 사이트, 그게 뭔가요?

뷰티 컬리 개발하면서 site라는 개념이 생겼습니다.
특정한 상품, 사업에 집중하는 버티컬 서비스는 상품이 카테고리의 하위 개념인데.
컬리에서 말하는 site는 앱 상위의 개념으로 기존의 버티컬 서비스와 방향성이 다르다고 해석하였습니다.
그 이유는
site가 변화하면 API path가 변경됩니다. 이에 따라 홈, 카테고리, 검색은 site에 종속되어 상품의 노출이 달라집니다!

이를 반영하기 위해서는 레거시 코드의 이해가 필요했습니다.
레거시 코드를 보면 하나의 클래스에서 앱 전체에 대한 의존성을 생성하고 주입하는 구조를 가지고 있었습니다.
그래서 site가 변경되면 기존 의존성 주입을 유지하고
추가로 site를 주입하여 단방향으로 흐름이 생성되도록 수정하였습니다.
이를 통해 site에 대한 상태 불일치 현상을 방지하여
팀원들에게 데이터 및 뷰 흐름을 쉽게 파악하여 사이드이펙트 발생을 최소화하고 싶었습니다.

타 플랫폼과의 협업은?

또한, 기존 API에서 site 구분을 위한 path가 추가되었기에

이를 안드로이드 개발자와 중복되는 일,
그리고 응답 데이터 정합성을 위해 site path를 적용한 포스트맨을 구성하여
공유하는 방법을 채택하였습니다.

Recycle, 재활용!

사이트 전환 시 구좌의 변화가 가장 컸습니다.
구좌란 컬리 앱을 실행하게 되면, 홈 - 컬리 추천에서 상품정보를 볼 수 있습니다.
해당 화면의 요소들을 구좌라 하는데,
구좌는 템플릿 화하여 백오피스를 통해 동적으로 받아 처리할 수 있는 구조를 가지고 있습니다.
짧은 개발 일정 속에 빠른 판단이 필요했습니다.
레거시 코드를 분석해서 개선하면서 처리할지 아니면 새롭게 만들어서 교체할지!

다행히도 마켓 또는 뷰티로 나뉘긴 했지만 노출하는 상품 내용이 다르지 않고 구좌 형태는 동일하였습니다.
마켓/뷰티 컬리 추천 페이지가 유사한 UI를 채택한 덕분에 공통된 성질 기준으로
모델링 하는 것만으로도 코드의 많은 부분을 재사용할 수 있게 되었습니다.

드디어!!!
7월 29일 새벽 3시 앱스토어에서 심사 승인가 완료되었고 오전 11시에 배포를 할 수 있었습니다.

이는 서두에 말씀드린 대로 미리 개념과 방향성을 정하고
상품 개편 QA에 집중 후 뷰티 컬리를 작업해서 할 수 있었던 부분도 있지만
먼저 개발을 하고 있던 안드로이드 개발자가 선행하면서 이슈 등을 공유하고 가이드를 해주었고
기획자의 MVP 조율 등을 통해 타 플랫폼 보다 늦게 개발이 들어가면서
개인적으로 우당탕탕 걸렸지만,
뷰티 컬리 프로젝트 협업하는 동료분들이 미리 길을 닦아놔서 잘 따라가며 완료할 수 있는 프로젝트였습니다.

FIXME: 내(우리)가 고쳐야 해!

aka (구좌)로딩속도

서두에 말한 마켓/뷰티 site 전환 시 의존성 주입을 통해 서비스를 새로 만드는데
이는 곧 RootViewController를 새로 만드는 구조였습니다.

오픈 이후 위와 같은 형태에서 기본 앱 구성과 컬리 추천의 구좌를 불러오는 API 호출의 낭비
그리고 API 응답이 늦는 경우, 화면 로딩 속도가 느리다는 내부적인 피드백을 받았습니다.
이를 개선하기 위하여 site 주입의 구조가 변경되는 조금 크리티컬 한 구조적인 이슈가 발생하였습니다…….

기존에는 하위 계층으로 site 프로퍼티를 계속 주입하고 있었지만,
site 프로퍼티 대신 site 서비스 클래스를 주입하고
내부에서 site 프로퍼티를 관리함으로써 항상 같은 값을 갖도록 유지하였으며
필요한 부분에서만 subscribe를 하여 사용하는 방식으로 채택하였습니다.

이를 통해 사이트 전환 시 매번 새로 생성하지 않고 서비스 레이어에서
이벤트 처리 방식으로 처리하여 루트 뷰 컨트롤러를 생성하기 위한 API 호출을 줄여,
로딩되는 시간을 줄일 수 있었습니다.

해당 작업은 다른 팀원이 작업을 하게 되었는데요.
제가 어떤 콘셉트를 가지고 이를 개발하였는지 다른 팀원에게 설명을 해주고
이를 다른 팀원이 효율적인 방안을 제안하고
같이 코드 리뷰하면서 최대한 사이드 이펙트를 줄일 수 있도록 진행되었습니다.

이처럼, 제가 개발한 작업이라도 같은 플랫폼의 다른 팀원들을 통해
고도화, 의견 교류, 간접적인 페어 프로그래밍 등을 통해 기술적 업그레이드를 경험할 수 있었습니다.

개인적인 회고를 해보자면 뷰티 컬리를 오픈하고 전환 속도에 대해서는 개인적으로는 불편함을 느끼지 못하였지만
다양한 사용자의 시각, UX 개념이 다르기에 주관적인 느낌보다는
데이터 기준 또는 협업하는 다양한 직군들의 시각을 참고하며 개발을 임해야겠다는 점을 배웠습니다.

둥둥이는 귀여워

뷰티 컬리 오픈 이후 예측보다 상단 스위칭 버튼의 전환율이 낮아,
이를 개선하고자 뷰티 컬리 유입을 위한 플로팅 버튼 개발 프로젝트에 참여하게 되었습니다.
처음 노출되는 컬리 추천 탭에 플로팅 버튼을 노출시키고,
이를 클릭을 유도하는 UI을 통해 뷰티 컬리의 전환율 높이자!
가칭 둥둥이는 시선 강탈자..라는 콘셉트를 가지게 되었습니다.

심플하기에! 실험적인 프로젝트이기에!
디자인과 개발이 병행되어야 했습니다.
먼저 UI가 나오기 전에 목업 기준으로 정책을 코드에 녹여놨습니다.
그리고 기획/디자이너와 상호 피드백을 통해 인터렉션을 확인하고 애니메이션을 추가하는 등
면밀한 소통을 통해 만족하는 결과물이 나올 수 있었습니다.

심플하고 명확한 목표인 “뷰티 컬 리 유입을 늘리자”라는 공통된 목표가 있었기에
출시 이후 데이터 기반으로 검증하는 시간을 가졌습니다.
정확히는 데이터 분석 결과물을 공유 받았고, 내가 개발한 프로젝트가 유의미한 수치를 발생하고 있다는 걸 인지함으로써
소소하지만 나의 가치를 확인할 수 있는 프로젝트였습니다.

이것으로 저의 뷰티 컬 리 론칭기를 마치겠습니다.