(🔔당근!) 반가운 중고거래 키워드 알림 만들기

안녕하세요. 중고거래실에서 iOS 엔지니어로 일하고 있는 Lychee예요.

당근 중고거래, 다양한 물건을 사고팔 때 자주 이용하실 텐데요. 찾고 있는 물품이 올라왔을 때 바로 알림을 받을 수 있는 키워드 알림 기능을 아시나요?

작년 가을 쯤 노트북이 필요해서 키워드 알림으로 노트북 기종을 등록해두었던 적이 있어요. 제가 찾던 기종의 글이 올라올 때 바로 알림을 받을 수 있어서 좋았죠. 그런데 종종 노트북 케이스, 노트북 충전기와 같이 등록한 키워드가 포함된 다른 물건의 알림을 받기도 했어요. 이럴 때는 기다리던 알림이 아니라서 실망하기도 했었어요.

그 즈음 저희 팀은 중고거래 리텐션에 중요한 역할을 하는 키워드 알림을 자세히 들여다보기 시작했어요. 키워드 알림을 등록하는 지표는 꾸준히 성장하고 있으나, 발송된 키워드 알림 푸시의 양에 비해 낮은 오픈율을 보았을 때 사용자들이 원하는 알림을 받지 못하고 있다는 걸 알 수 있었죠. 그렇게 원치 않는 알림으로 피로가 쌓이는 것을 방지하기 위해 이 문제를 해결하기로 했어요.

Before > 기존 키워드 알림 등록 화면

키워드 알림의 문제를 더 자세히 들여다보기 위해 사용자의 목소리를 들어보았어요.

🗣️ “제가 찾는 물건이 아니에요. 등록한 키워드와 정확하게 일치하는 알림만 받고 싶어요”

🗣️ “제가 찾는 물건이라도, 너무 먼 동네의 알림은 받고 싶지 않아요”

🗣️ “내가 원하는 물품의 키워드 알림을 받으려면 어떤 키워드를 등록해야할지 모르겠어요”

다양한 사례를 생생하게 들으며, 키워드 알림의 문제를 더 뾰족하게 정의했어요. 그리고 문제에 대한 개선점을 발굴해나갔고 그렇게 키워드 알림 개선 프로젝트를 시작했어요. 클라이언트 릴리즈 로그를 돌아보니 지난 5개월 동안 아주 긴밀하고 치열하게 몰입할 수 있는 시간을 보낸 것 같아요 😄

5개월 간의 클라이언트 Release Log

개선 프로젝트는 크고 작은 여러 개의 실험과 기능 개선을 반복하는 사이클로 진행되었어요. 키워드 알림 등록 및 관리에 대한 전반적인 기능 개편과 함께 더 적절한 키워드를 등록하도록 돕는 여러 추천 실험 등을 반복했죠. 그 결과 키워드 알림 오픈율이 2배 가까이 상승하며, 키워드 알림에서 구매를 위한 채팅으로 전환하는 수도 함께 증가하는 것을 볼 수 있었어요. 👏🏻

이렇게 제품의 성장을 위해 빠르게 개선을 반복하는 과정에서, 저에게 큰 도움이 되었던 유연한 모바일 설계에 대한 이야기를 나눠보려고 해요!

독립적인 환경, Feature Module 기반으로

키워드 알림 Feature Module

당근 iOS 앱은 Feature, UI, Domain, Core, Shared의 5가지 계층을 가진 모듈로 구성되어있는데요. 새 기능을 추가할 때마다 Feature Module을 추가하지는 않지만, 분리될 수 있는 맥락의 기능이라면 별도의 Feature Module을 생성하는 것을 권장하고 있어요. (당근 iOS챕터의 모듈화에 대한 자세한 내용은 이 글을 참고해주셔도 좋아요.)

“새 술은 새 부대에” 라는 격언에 따라 새로 개선되는 키워드 알림 기능을 담을 별도의 Feature Module을 생성했어요. 그리고 새 모듈 위에 키워드 알림에서 사용할 소스코드들을 설계해 쌓아올렸어요.

FleaMarketKeywordNotificationFeature 모듈은 다른 Feature 모듈과 앱 타겟과는 독립적으로 분리가 되어있어서, 새 기능을 끼워넣을 때 발생할 수 있는 사이드 이펙트로부터 비교적 안전한 환경이었어요. 덕분에 적은 부담감으로 빠르게 작업을 해나갈 수가 있었지요. 또 전체 모듈을 빌드하지 않고도 단독 모듈에서 빌드와 테스트를 수행할 수 있기에 이전보다 시간을 단축할 수 있어서 생산성도 끌어올릴 수 있었어요.

초기부터 변화에 유연하게 대응할 수 있도록 구성

키워드 알림 개선의 첫 과제로, 가장 많은 불편사항으로 꼽혔던 “불필요한 키워드 알림”을 줄이기 위한 키워드의 조건을 설정할 수 있는 기능을 추가하게 되었어요. 기존에는 키워드만을 등록할 수 있었는데요, 이제 등록한 키워드의 카테고리, 가격 범위, 제외하고 싶은 키워드와 같은 조건을 설정해서 필요한 알림만 필터링해서 받을 수 있도록 한 것이죠.

After > 키워드의 조건을 설정할 수 있는 기능이 추가된 새 키워드 알림 설정화면

새 키워드 알림 설정화면 UI의 초기 스펙은 단일 세로형 목록으로 구성되었어요. (왼쪽 이미지 참고) 하지만 키워드 알림에 대한 여러 불편함을 해결하기 위해서는 리스트의 구조가 여러 가지 형태로 변화될 가능성을 열어두어야 했죠. 그래서 처음엔 비록 Verticle List의 단순한 형태이지만 enum으로 Section 타입을 정의했고, 이에 따라 리스트를 구성하도록 했어요.

리스트 UI는 KarrotListKit을 사용하여 구성했는데요. List, Section, Cell을 직관적으로 구성하기 때문에 컴포넌트 단위로 관리하기가 용이했어요. 또 각 컴포넌트에 modifier를 붙여 간단하게 레이아웃 속성을 지정하거나 컴포넌트에 발생하는 액션을 받도록 연결할 수 있어서 UI 구성 단계의 생산성을 올려주었어요.

enum Section: Equatable, Identifiable {
  case registeredUserKeywordList([ItemViewModel])
}

func updateSection(section: Section) {
 collectionViewAdapter.apply(
   List {
     sections.map { section -> Section in
       switch section {
         case .registeredUserKeywordList(let viewModels):
         return Section(
            id: id,
            cells: makeRegisteredKeywordSectionItems(
              viewModels: viewModels
            )
          )
          .withSectionLayout(.vertical(spacing: 0.0))
       }
     }
   }
 )
}

리뉴얼된 세로형 리스트의 키워드 알림 설정화면을 배포 후, 다음 작업으로 키워드 등록을 제안하는 실험을 하기로 했어요. 키워드 알림 설정 화면에 방문했을 때 어떤 키워드를 등록해야할 지 어려움을 겪고 있을 것이라는 가설이었죠. 그렇게 최근 본 게시글을 토대로 추천된 키워드 칩 목록을 기존 리스트 하단에 보여주는 작업을 시작했어요.

최근 본 게시글을 토대로 키워드 등록을 제안하는 실험 UI

지난 작업에서 리스트에 어떤 섹션이 추가되어도 대응할 수 있도록 구성한 덕분에 새 case를 정의하고, 연결하는 작은 변경만으로 실험을 준비할 수 있었어요. Section 에 recommendedKeywordList의 case를 추가하고 해당 섹션에 들어갈 컴포넌트를 구성해 연결해주었어요.

enum Section: Equatable, Identifiable {
  case registeredUserKeywordList([ItemViewModel])
  case recommendedKeywordList(RecommendedViewModel)
}

미래에 대해 100% 예측할 수는 없겠지만, 팀원들과 해결해야 할 문제에 대해 이야기를 나누었던 것을 토대로 예상되는 변경점을 유연하게 설계해 둔 것이 도움이 되었어요.

N개의 국가, 하나의 화면

키워드 알림 기능은 국내를 비롯해 북미, 일본, 영국에서도 동일하게 제공되고 있어요. 중고거래를 이용할 때 필요한 물건에 대한 알림을 받고 싶은 니즈는 어디서나 동일했기에 전 국가를 함께 개선하고자 했어요.

전 국가에 제공되는 기능일 때는 비슷한 UI를 보여주는 상황에도 국가별 UX의 유연함을 위해 View를 따로 가져가거나, ViewModelFactory 구현체를 따로 만들기도 했었는데요. 저희 팀은 이에 대해 국가 분기를 최소화하고 공통화하자는 의견이었어요.

국가별로 특수성을 가져가면 관리가 복잡해지고 히스토리를 잘 알지 못하는 작업자가 추가 작업을 할 때 사이드 이펙트의 위험도가 높아지기 때문이에요. 저희 팀 프로덕트 디자이너 Bada가 머리를 싸매시며 국가별로 최대한 동일한 UI/UX를 설계해주신 덕에 클라이언트에서도 국가분기 없이 하나의 Presentation Layer로 화면을 보여줄 수 있었어요.

단순해진 Presentation Layer

하지만, 키워드 알림을 받을 동네 범위를 설정할 수 있도록 개선하는 작업을 하며 문제가 발생했어요. 국가별로 적용되는 지역 시스템이 달랐고, 이에 따라서 각각 다른 UI를 보여줄 수 밖에 없었어요.

• 한국 : 반경에 있는 동네의 개수를 표시하며 4단계의 Step Slider UI 제공
• 캐나다 : 반경 km 범위를 표시하며 5단계의 Slider UI 제공
• 미국 : 반경 mi 범위를 표시하며 5단계의 Slider UI 제공
• 일본 : 반경에 있는 동네의 개수를 표시하며 4단계의 Slider UI 제공

한국, 북미, 일본의 키워드 알림을 받을 동네범위 설정 UI

지역 시스템에 따라 서버의 EndPoint와 Response DTO는 다르지만, 화면에서 다뤄지는 요소는 다르지 않았어요. 각 국가에서 사용하는 동네 범위와, 각 동네 범위가 어느 정도의 범위인지 표현(동네의 개수 OR 범위의 크기)하는 것은 동일하다는 점을 추상화하여 하나의 KeywordNotificationTownData 를 설계했어요.

struct KeywordNotificationTownData {
  let town: KeywordNotificationTown
  var metadata: KeywordNotificationTown.Metadata
}

enum KeywordNotificationTown {
  case fooLocationSystem(FooLocation)
  case barLocationSystem(BarLocation)
  
  public var id: Int {
    switch self {
    case .fooLocationSystem(let fooLocation):
      return fooLocation.id
    case .barLocationSystem(let barLocation):
      return barLocation.h3Index
    }
  }

  public var name: String {
    switch self {
    case .fooLocationSystem(let fooLocation):
      return fooLocation.name
    case .barLocationSystem(let barLocation):
      return barLocation.name
    }
  }

  public var coordinate: KarrotLocationCoordinate? {
    switch self {
    case .fooLocationSystem(let fooLocation):
      return fooLocation.coordinate
    case .barLocationSystem(let barLocation):
      return barLocation.coordinate
    }
  }
  
  struct Metadata: Then {
    var currentRange: KeywordNotificationTown.Range
    var defaultRange: KeywordNotificationTown.Range
    var rangeInfos: [KeywordNotificationTown.RangeInfo]
  }
}

그리고 비즈니스 로직을 처리하는 Interactor에 국가에 따라 각 지역 시스템의 EndPoint에서 지역 데이터를 받아와 KeywordNotificationTown로 맵핑해 내려주는 Broker를 두었어요. Broker에게 fetch를 요청하면, Interactor에서는 어느 국가인지 알 필요 없이, KeywordNotificationTownData 타입으로 응답을 받아 화면을 구성할 데이터를 Presenter에 전달해요.

전 국가에 한 벌로 제공되는 View와 ViewModelFactory

하나의 타입이다 보니 자연스럽게 하나의 View와 ViewModel, ViewModelFactory로 화면을 구성할 수 있었어요. 덕분에 Presentation Layer에서의 보일러 플레이트 코드를 줄일 수 있게 되었죠. (이 과정에서 함께 고민해주신 Elon.park에게 감사인사를 전해요.)

밀도있는 테스트

빠르게 사이클을 돌며 테스트 코드에 대한 고민도 생겼어요. 저는 이제까지 비즈니스 로직부터 프레젠테이션 로직, 라우팅 로직, 행동 데이터 전송 로직까지 대부분의 로직에 대해 유닛테스트를 작성해왔어요. 단순 by-pass 되는 값을 mock 객체에 전달해 호출 횟수를 테스트를 하는 불필요한 테스트도 많았다고 생각해요.

더 효율적으로 테스트코드를 작성하고 싶었던 저는 이런 고민들을 하기 시작했어요.

• 주요 유즈케이스만 검증하는 것은 어떨까
• 비즈니스 로직은 얼마나 촘촘하게 검증해야할까
• 단순한 라우팅, 로깅 로직은 유닛테스트를 작성하기 보다 구동 테스트를 하는게 어떨까
• … 등등

여러 고민 끝에, 주요 유즈케이스에 대한 액션과 비즈니스 로직 위주로 밀도있게 유닛테스트를 구성해보기로 했어요. 유닛 테스트 작성에 대한 부담감을 낮추되, 필요한 부분을 제대로 검증하려면 어떻게 테스트를 구성해야할지 고민하며 작성했어요. 그리고 구동 테스트를 하는 시간을 더 늘리며 제품을 많이 써볼 수 있었는데요. 그 과정에서 경험적인 부분에 대한 어색함을 발견해 출시 전에 개선할 수 있었던 점도 기억에 남아요.

검색 결과 화면에서 현재 검색한 키워드를 키워드 알림으로 등록하면, 키워드 알림 조건 설정을 해볼 수 있도록 안내를 해주는 온보딩 기능이 있었어요.

이를 통해 키워드 알림 조건 설정 화면에 진입하여 카테고리, 가격 등의 조건 설정을 완료하고 나온 경우에 바로 이전에 있던 검색화면으로 돌아오게 되는데요. 조건을 수정하고 싶거나 다시 조건을 보고 싶을 때는 맥락이 이어질 경로가 부재하다는 것이 아쉬웠어요. 그래서 완료 후 스낵바에 보러가기 버튼을 넣어 키워드 알림 조건 설정 화면으로 다시 진입할 수 있는 입구를 추가하게 되었어요.

유닛 테스트도 물론 중요하지만, 클라이언트 개발자라면 개발한 기능을 직접 많이 써보면서 화면 너머의 부분까지 검증해보는 것도 중요하다는 걸 배웠어요.

그렇게 5개월 간 개선을 반복한 끝에 우리 키알이가 달라졌어요! 아직 당근에서 키워드 알림을 써보신 적이 없다면 필요한 물품이 있을 때 한 번 써보시길 자신있게 추천드려요 😁

개선 이후 키워드 알림의 등록 수가 증가하며 알림 오픈율도 함께 늘어났고, 이전에 비해 불필요한 알림에 대한 문의도 눈에 띄게 줄었어요. 키워드 알림에서 이어지는 중고거래 채팅 전환율 상승까지 건강하게 잘 이어져서 더 의미있는 결과였던 것 같아요 👏🏻

이 글을 통해 함께 치열하게 달렸던 우리 팀원들.. 정리천재에 데이터까지 잘 보는 PM Suzy, 차분하게 우리 팀의 넘치는 아이디어와 열정을 정리해 멋지게 담아주는 프로덕트 디자이너 Bada, 우주를 사랑하는 건강한 Rails 서버 엔지니어 Astro, 말은 많지만 필요한 말만 하는 안드로이드 엔지니어 Reddy에게 감사의 인사를 전해요🧡