[아티클 스터디] 배달의 민족 아티클로 1-pager 작성 훈련

 

https://techblog.woowahan.com/18254/

 

1. 상황

• 배달 상황 운영자가 배달 상황을 모니터링 해야 하는 상황
  • 모니터링 할 지표가 많음
    • 주문 건수, 배차대기 건수, 평균 배달 소요시간, 평균 배차 소요시간, 운행 라이더 수 , 주문 취소율, 배달 취소율, 고객 안내시간 준수율
  • 지표를 보고 경험적 판단을 주로 함
  • 실시간으로 변하는 상황과 이에 따른 지속적인 모니터링 필요
    • 반복 업무 및 업무 시간 증가

2. 목표

• 운영자가 배달 상황이 안정적이도록 유지를 하여 빠른 배달 서비스를 유지하자.

3. Target

• 배달 상황 운영자

4. 표면적 문제

• 운영자가 배달 상황이 안정적이도록 운영하는데 어떤 문제가 있을까?
  • 모니터링 지표 많음
    • 한번에 모든 지표를 판단할 수 없으므로 판단 오류가 날 가능성이 높음.
  • 지표를 판단할 명확한 기준 없음
    • 경험적 판단엔 휴먼에러가 발생할 확률이 언제나 존재함
  • 실시간으로 변하는 상황과 이에 따른 지속적인 모니터링 필요
    • 업무 시간의 증가
    • 항상 모니터링하는데 집중해야 하므로 다른 업무에 지장

5. 깊은 문제(표면적 문제의 이유)

• 지표가 왜 많이 필요할까?
  • 몇 개의 지표만으로는 현재 배달 상황을 판단하기 어려움
    • 배달 상황이라는 것 자체가 이미 복잡한 현상
      • 따라서 몇 개의 지표만으로 단순화하는게 불가능
• 지표 기준이 왜 없을까?
  • 기준 값을 세우기가 애매함. 어느정도의 값을 기준으로 잡을지에 대한 어려움
  • 여러 개의 지표가 동시에 움직임
    • 따라서 특정 몇 개의 지표가 기준을 넘겼다고 해서 섣불리 판단하는게 쉽지 않을 수 있음.
• 왜 지속적인 모니터링이 필요할까?
  • 상황이 시시각각으로 변하기 때문.

6. 가설(깊은 문제를 고려한 해결방안)

1. 모든 지표를 input으로 하고 현재 배달 상황에 대한 값을 output으로 하는 상황측정 모델을 만들되
2. 실시간으로 데이터를 받아와서 output을 내놓도록 하고 특정 기준을 세워서 위험 알림 기능을 추가한다.
3. 이를 바탕으로 실시간 대시보드를 만들어서 배달 운영 담당자에게 배포하면
4. 하나의 지표를 통해 실시간 모니터링할 수 있으며, 알림 설정을 통해 필요한 경우에만 효율적으로 작업이 가능하므로
5. 운영자의 업무효율이 증가할 것이다.

→ 키워드 정리 : 실시간, 대시보드, output 1개, 상황 측정 모델, 알림설정

 

 

7. 다른 비슷한 상황의 경우, 어떤 서비스가 있는가?

비슷한 예로 실시간 수위 모니터링 및 주식 관련 서비스들이 있을 것이다.

HTS에서 사용하는 알람 설정

실시간 수위 대시보드

8. 결과물

배달 인프라 레벨을 모델을 통해 산출하고 그에 따라 레벨 그룹을 부여.

실시간 대시보드를 만들어 지역마다의 배달 현황을 한눈에 볼 수 있게 만듦

 

그라파나 + slack을 이용한 위험 알림 시스템

 

9. Test 및 지표설정

1. 실시간 시스템의 정확성 : 사용자 피드백을 통해 진행

• 특별히 A/B 테스트를 기획하진 않았다.
• 위와 같은 시스템이 도입된 후의 사용자 피드백을 통해 테스트를 대신.
• 가장 중요한 점은, 이렇게 만든 실시간 자동화 시스템이 얼마나 에러율 낮게 배달 상황을 잘 포착하느냐가 관건.

b. 실시간 시스템의 성과 : 지표를 통해 진행

• 전/후 운영인원
• 전/후 모니터링 소요 시간
• 전/후 운영 설정 소요 시간
• 전/후 운영 설정 주기

 

10. 비즈니스 관점

• 업무 효율성을 위한 회사 내부 프로덕트 개발이었으므로 비즈니스 관점에서 손해에 대한 리스크를 고려할 필요는 없을 것으로 생각.
  • 업무 프로세스 개선의 의도가 브랜드 이미지, 매출등에 영향을 미친다고 보긴 어렵다.
  • 오히려 업무 효율성 증대(배달 상황 최적화)를 통해 고객에게 더 나은 서비스를 제공할 수 있다.
  • 만약 리스크를 생각한다면, 위와 같은 실시간 모델의 성능이 부족하여 오히려 배달 최적화가 나빠지는 경우가 있을 수 있지만, 이는 테스트 과정에서 검사 가능하다.
• 리소스적 관점
  • 실시간으로 약 15만건에 대한 데이터를 실시간으로 받아오고 모델에 넘겨야 하므로 서버에서 어느정도의 데이터 처리량을 처리해야하나 그 크기에 대한 평가는 회사 사정마다 다를 수 있다.

11. 유관부서(협의를 통해 세부사항 결정)

• 데이터 : 지표 및 모델 개발 필요
• 개발 : 실시간 데이터 처리 관련 구조 설계 및 API 설계

12. 생각해볼법한 내용

• 비즈니스적 관점
  • 내부 프로덕트의 경우, 어떤 리스크가 있을까?
    • 백엔드 관리자 리소스 필요. 백엔드 관리자가 할 일이 늘어남.
• 좋은 가설의 조건 : 지표설계
  • 하나인 “테스트 가능한 가설” 즉, 측정 가능해야 하는데, 측정 지표를 설계하는 게 어려울 수 있다.
• 피상적인 문제정의에서 깊은 문제로 넘어가더라도 더 근본적인 문제의 이유가 도출되지 않을 수도 있다.

 

---

13. 1-Pager 추가 제안/보완점

1. 지표 우선순위: 모든 지표를 통합한 모델을 만든다는 것이 이상적이긴 하지만, 우선순위가 높은 핵심 지표 2~3개를 먼저 추려내고 가중치를 설정하는 접근도 제안해볼 수 있다.
2. 유관 부서/담당자: 대시보드가 제공되면, 운영자 외에도 마케팅, 고객센터, 라이더 관리 부서 등이 어떻게 협업하고 활용할 수 있을지 간단한 시나리오 추가도 좋다.
3. 정량적 목표 제시: “평균 배달 소요시간을 X분으로 유지”나 “배차 대기 건수를 2분 안에 해결” 등 목표 수치가 들어가면 더욱 명확해지고, 이후 솔루션 효과를 평가하기 쉬워진다.