진단 도메인 설계 구현 및 운영

기존 직거래 서비스 운영 중에 낮은 평균 거래 가격 등 구매자와 판매자간의 정보 비대칭 등 다양한 문제와 현상을 발견했어요. 수익화 또한 고려하게 됨으로써 진단을 솔루션으로 정했고 1차적으로 관련 정비 업체와의 협업을 통해 사전 진단 실험이 워킹함을 증명했어요. 다음 스텝으로 당근 내부에 진단 내재화를 통해 차량 정보를 수집하고 시장의 이해도를 높이며 도메인을 확장할 수 있는 무기를 만들었어요.

진단 프로세스 구축

• 진단 서비스는 단순한 온라인 피처가 아니라 진단사와 고객간의 시간 조율 및 예약 관리, 진단사가 실제로 차량 진단 도중 모바일 진단표를 통해 차량 정보를 기록하며 40분 안의 객관적인 차량의 상태를 168여가지가 넘는 항목으로 입력받아 차량 정보를 표준화해요. 진단사의 정산과 대조 그리고 거래 성사율과 비례한 동기부여를 위한 베네핏 시스템, 관리자가 개별 진단사의 진단 결과까지 검수 및 피드백 할 수 있어야하는 대작업이었어요.
• 진단사 가입 / 진단 가이드 / 차량 데이터 기반 문진표 / 예약 관리 / 진단 체크리스트 / 정산 관리 / 진단 검수 등 당근 내의 하나의 버티컬 서비스의 사이즈를 넘는 양을 모두 전담해 만들었어요.
• 168여 가지가 넘는 항목 / 타입들을 코드 스키마로 만든 이후 타이핑을 역연산하여 테스트 개념으로 타입 컴파일 타임에 안정성을 확보했어요.
• 대표적 예시로 중간중간 진단 항목 수정 같은 잦은 스펙 변화 속에서 주도적 협업으로 커뮤니케이션 갭을 최소화 했어요.

진단 비즈니스 실험

• 구매자가 차량정보를 알 수 없어 차량 전문가에게 요청하는 대신 봐주기 / 구매자가 판매하기 전 차량의 정보를 객관적으로 고지하기 위한 사전 진단 등 C2C 직거래에서 구매자와 판매자가 서로 진단을 통해 정보비대칭을 해결할 용의가 있는지 그리고 진단 정보로 인해 실제로 거래 경험이 더 만족스러운지에 대한 실험을 다수 진행했어요.
• 차량조회 및 진단으로 이어지는 예약 퍼널을 1-pager로 만드는 등 파격적인 퍼널 개선 실험을 다수 진행했어요.
• 전문가간 거래가 아닌 직거래에서도 보증이 구매자에게 유효하게 작동하는지에 대한 실험을 다수 진행했어요.

진단 품질 개선

• 진단사 과진단 해결

  • 진단사가 진단한 정보가 실구매자(딜러)가 보기에 다르면 진단사가 일부 책임을 보상하는 클레임이 진행돼요.
  • 당근 진단은 타사 대비 진단에서 요구하는 정보의 양과 퀄리티가 매우 높은 수준으로 진단사들이 지레 겁먹어 단순 미세누유도 심각한 문제로 고지하는 과진단 현상이 발견됐어요.
  • 업계에서 흔한 레퍼런스이기에 어떻게 해결했는지에 대한 현상-솔루션을 분석해 정리했어요.
  • 진단에서 수집하는 정보 단위를 조정하고, 딜러와 유저에게 고지되는 위계를 수정해 적절한 정보로 전달되게끔 변환하고 중개했어요.

• 진단사 수정요청 자동화

  • 진단사의 역량 부족으로 진단을 완료한 후에도 밴드/문자/전화 등 다양한 채널로 수정을 요청했어요. → 이는 일일이 사람이 보아야하고 경매가 진행돼 입찰이 있다면 일일이 수정이 필요하기에 오퍼레이션 코스트가 매우 큰 작업이에요.
  • Json Diff를 통해 적절한 정보를 보정해 변화된 정보만 노출하고 시스템화해 오퍼레이션 코스트를 줄였어요.

진단 시스템 기술적 고도화

• 진단리포트의 Graphql Schema가 지나치게 복잡해 Schema 상에서 Record로 느슨하게 수정했어요.
  • 168여 개 항목의 잦은 변경으로 스키마의 변화에 따라 애플리케이션 타입이 매번 깨졌어요.
    • 본래 설계에 의도에 맞고, 변화에 따른 결과를 정확하게 예상할 수 있었지만 변화가 너무 잦아 변경에 맞춰 코드를 수정하지 않으면 알파 환경의 빌드 프리뷰가 자주 업데이트 되지 않았어요.
    • GraphQL schema에서는 Object로 느슨하게 관리하도록 수정하고 별도 type + validation 라이브러리를 모노레포에서 관리하고 퍼블리싱하며 서버에서도 함께 사용했어요.
    • 프론트엔드-백엔드 로직 통일로 스키마 불일치에 따른 고통을 해소하고, 의도할 때 버전을 업데이트해 진단 리포트를 관리할 수 있었어요.
• 진단사 웹뷰 분리
  • 앱이 커짐에 따라서 컴파일 속도, 복잡도 등 다양한 문제들이 발견됐어요.
    • 독립 프로젝트로 분리하여 컴파일 시간을 단축하고 배포 안정성 및 독립성을 확보했어요.
    • Typescript 성능 측정을 통해 오랜 시간이 걸리는 구문을 짚어내고 캐싱하도록 수정했어요.
• 릴레이 Fragment 기반으로 비즈니스 로직 집중 관리
  • 진단 정보는 매우 민감한 정보로 딜러 / 진단사 / 판구매자 들 중 누구 하나에게라도 잘못 노출되거나 노출하지 않으면 클레임으로 이어지고 오퍼레이션과 높은 전적 비용을 소모하게 돼요.
  • 릴레이(Graphql)에서 모노레포 설정을 통해 공통 데이터의 프레그먼트, 패칭 로직을 중앙집중화했어요.
    • 그 어디서도 워킹하는 예시도 없고 사례도 없었지만 Relay Discord, Github를 디버깅하고 수많은 기술적 현상 / 솔루션을 시도하며 성공했어요.
  • 다수 프로젝트에서 발생할 수 있는 데이터 위계 불일치 문제를 해소하고 클레임 여지를 사전에 제거했어요.