Do not index
Do not index
안녕하세요. 오토피디아의 서비스개발팀장을 맡고 있는 김승수입니다. 오토피디아 서비스개발팀에서는 타이어 커머스라는 신규 서비스 출시에 앞서 이벤트 스토밍을 시도해 보았습니다. 이벤트 스토밍을 적용해 보고자 하는 다른 팀에게 도움이 됐으면 하는 마음으로 저희의 이벤트 스토밍 적용기를 공유하려고 합니다.
0. 들어가며1. 이벤트 스토밍이란?2. 이벤트 스토밍 진행 과정타이어 커머스 도메인이벤트(Event)커맨드(Command)와 액터(Actor)리드 모델(Read Model)외부 시스템(External System)정책(Policy)애그리게잇(Aggregate)바운디드 컨텍스트(Bounded Context)3. 이벤트 스토밍 결과핵심 바운디드 컨텍스트DDD 구현의 첫걸음보편 언어 구축 및 비즈니스 플로우 이해 강화를 통한 커뮤니케이션 비용 감소기획 빈틈 발견4. 이벤트 스토밍 팁단계별 참여 인원좁은 타겟 도메인DDD의 전략 측면에 대한 이해마치며 — 다음엔 같이해요
0. 들어가며
오토피디아 서비스개발팀에서는 지난 6월 타이어 노면 사진을 통해 타이어 교체 필요 여부를 확인할 수 있는 AI 모델과, 타이어 구매 커머스를 결합한 서비스, 닥터트레드를 MVP 형태로 런칭하였습니다. 약 한달 간의 운영 결과, 닥터트레드의 사용자들은 타이어 교체가 필요한지를 확인하기 보다는 타이어 구매를 더 원한다는 사실을 확인할 수 있었고, 이에 따라 닥터트레드의 타이어 커머스 기능을 더 강화하기로 결정하였습니다.
기존의 닥터트레드의 백엔드 서버는 MVP인만큼 빠른 개발을 위해 express 기반으로 제작되었습니다. 그러나 기존의 타이어 판매처에 한국타이어, 금호타이어를 추가해야했고 이 두 판매처는 기존의 판매처와 다르게 상품 목록, 주문, 주문 취소, 예약 등을 연동할 수 있는 API를 제공했습니다. 판매처가 한곳에서 세곳으로 증가하고, 세 판매처의 비즈니스 플로우도 조금씩 다른 상황이므로 높은 구현 복잡도가 예상되었습니다. 또한 기존 닥터차 서비스의 백엔드 서버에서 사용한 3-layered architecture는 단순 CRUD 기능 개발에는 적합하지만, 모든 의존성이 데이터베이스로 향한다는 한계가 있었고, 이로 인한 문제점들을 겪고 있는 상황이었습니다.
이 문제를 해결하기 위해 타이어 커머스 백엔드에는 도메인 주도 설계(DDD, Domain Driven Design)를 적용하기로 결정하였습니다. 세 판매처의 서로 다른 비즈니스 플로우와, 향후 구현되어야할 복잡한 정산 로직을 포함하는 비즈니스 로직의 외부 의존성을 분리하여 테스트를 통한 비즈니스 로직 검증이 수월할 것이라고 판단했기 때문이었습니다. 그러나 구성원 중 한명도 DDD에 대한 경험이 없는 상황에서 첫 단계인 바운디드 컨텍스트와 애그리게잇 설정부터 명확한 답을 찾지 못 했습니다. 이를 해결하고자 이벤트 스토밍을 진행하게 되었고, 그 과정과 결과에 대해 공유하고자 합니다.
1. 이벤트 스토밍이란?
이벤트 스토밍이란, 소프트웨어를 개발하고자하는 도메인에서 어떤 일들이 이뤄지고 있는지 빠르게 파악할 수 있는 워크샵 형태의 방법입니다. 개발자 뿐만 아니라, 도메인 전문가, 기획자, 디자이너, 테스터 등 해당 소프트웨어 개발의 모든 이해관계자들이 참여합니다. 참여자들은 이벤트, 커맨드, 리드 모델, 애그리게잇, 외부 시스템 등을 나타내는 서로 다른 색깔의 포스트잇들을 벽에 붙여가며 이벤트 스토밍을 진행하게 됩니다. 이렇게만 들으면 상당히 모호한데요, 정확한 진행 방식에 대해 더 자세히 알아봅시다.
2. 이벤트 스토밍 진행 과정
이벤트 스토밍을 모두 진행하고 나면 다음과 같은 결과를 얻게 됩니다.
타이어 커머스 도메인
이벤트 스토밍 진행 과정을 설명하기 전에, 타이어 커머스가 개발하고자하는 도메인(문제 영역)에 대해 간단히 설명하고, 타이어 커머스 도메인을 예시로 이벤트 스토밍 진행 과정을 설명드리도록 하겠습니다. 실제 이벤트 스토밍 진행 시에는 사내 타이어 판매 담당자 등, 도메인에 대해 가장 자세히 알고 있는 사람이 참여하여 도메인에 대해 설명하고, 다른 참여자들에 도메인에 대한 질문에 답변하는 역할을 합니다. 이러한 역할을 도메인 전문가라고 부릅니다.
타이어는 노면에 새겨진 패턴의 종류에 따라 타이어 제품군이 달라집니다. 예를 들어, 미쉐린 크로스 클라이밋 II라는 타이어 제품군은 다양한 사이즈의 타이어로 출시되지만, 노면에 새겨진 패턴은 동일합니다. 이 패턴에 따라 썸머/윈터 타이어, 승차감 등, 타이어의 특성이 정해지게 됩니다. 한 타이어 제품군 안에서도 다양한 사이즈의 타이어가 존재합니다. 또한, 같은 제품군의 같은 사이즈의 타이어도 판매처(벤더)에 따라 공급/판매 가격이 달라집니다. 예를 들어, 245/80R17 사이즈의 미쉐린 크로스 클라이밋 II 제품군의 타이어도 한국타이어라는 판매처에서 공급되어 판매되는지, 금호타이어라는 판매처에서 공급되어 판매되는지에 따라 공급/판매 가격이 달라집니다. 판매처는 크게 온라인 판매처와 오프라인 판매처, 두 가지 유형으로 나뉩니다. 온라인 판매처는 판매 가능한 타이어 제품군 목록 및 타이어 별 가격 조회, 장착점 목록, 특정 타이어를 특정 일자에 장착 가능한 장착점 목록과 해당 일자에 예약 가능 시간 목록, 주문 및 예약 생성, 주문 취소 등의 기능을 API 형태로 제공하는 판매처를 말합니다. 오프라인 판매처는 앞서 말한 기능들을 API 형태로 제공할 수 있는 시스템이 없고, 우리가 제공하는 관리자 콘솔에서 해당 정보들을 직접 입력하는 판매처를 말합니다.
지금은 이벤트 스토밍이 완료된 후이기 때문에 도메인에 대한 설명을 간단히 마칠 수 있었지만, 이벤트 스토밍이 시작되는 시점에서는 보통 도메인에 대한 정보가 명확하게 정리되어 있지 않습니다. 도메인 전문가는 대부분의 경우 개발자가 아니기 때문에, 개발자가 사용하는 용어들을 사용하지 않고, 현장에서만 사용되는 은어들을 사용하기도 하며, 중간에 앞서 설명하지 않은 새로운 내용을 제시하는 등 개발자 간의 의사소통 방식과는 다른 의사소통 방식을 사용합니다. 또한 도메인 전문가, 기획자, 개발자 등 다양한 직군의 사람들이 사용하는 용어가 다르고, 서로 다른 직군의 용어를 이해하기 어려울 수도 있습니다.
이벤트(Event)
이벤트 스토밍은 이벤트 포스트잇을 붙이는 것으로 시작합니다. 도메인 이벤트라고도 부르는 이벤트란, 도메인에서 발생할 수 있는 모든 사건들을 과거형으로 작성한 것을 말합니다. 예를 들어, 장바구니에 타이어가 담김, 주문이 생성됨, 주문의 상태가 확정으로 변경됨, 주문에 대한 결제가 완료됨, 결제 취소 실패함 등이 있을 수 있습니다. 처음에는 모든 참여자들이 각자 생각하는 이벤트를 자유롭게 작성하여 붙입니다. 어느 정도 이벤트들이 작성 됐다면, 이벤트를 시간 순서대로 배열합니다. 그 과정에서 더 논의가 필요한 내용이 있다면 논의하고, 논의가 길어진다면 핫스팟 포스트잇에 논의 내용을 작성하여 붙입니다. 이를 통해 향후에 이 논의를 다시 이어갈 수 있도록합니다.
대표적으로 이뤄지는 논의 주제는 용어 정의가 있습니다. 예를 들면, “타이어”는 노면 패턴, 노면 패턴과 사이즈, 노면 패턴과 사이즈와 판매처 중 어떤 것에 의해 유일하게 특정되는가? 와 같은 논의들입니다. 도메인에 대한 서로 다른 이해도를 가진, 서로 다른 직군의 사람들이 모여 있으니 당연히 사용하는 용어들이 다르고, 같은 용어라도 다르게 이해하고 있을 수 있습니다. 이러한 논의 과정을 통해 참여자 모두가 같은 용어를 사용하게 되고, 도메인에 대한 이해도도 깊어집니다.
이러한 과정을 통해 참여자들이 공통적으로 사용하는 용어집이 생깁니다. 이러한 용어들을 모아 보편 언어(Ubiquitous Language)라고 부릅니다. 보편 언어가 없으면, 구성원마다 서로 다른 용어를 사용하고, 같은 용어라도 사람마다 다른 의미를 가지게 되면서 커뮤니케이션에 혼선이 생깁니다. 이러한 혼선은 완성도가 낮고, 유지 보수가 어려운 결과물을 만들어내기 쉽습니다. 이벤트 스토밍을 진행하면 구성원 모두가 동일하게 사용하는 보편 언어를 구축할 수 있습니다.
커맨드(Command)와 액터(Actor)
이벤트를 붙이고 나면 커맨드 포스트잇을 붙입니다. 커맨드는 이벤트를 발생시키는 명령어를 말합니다. 예를 들어, 장바구니에 타이어 추가 요청, 주문 생성 요청, 주문 상태를 확정으로 변경 요청 등이 있을 수 있습니다. 액터는 커맨드를 내리는 주체를 말합니다. 장바구니에 타이어 추가 요청과 같은 커맨드는 구매자가, 타이어 가격 정책 생성 요청은 관리자가 내리는 명령입니다. 어떤 명령들은 시스템이나 정책 등에 의해 자동으로 내려지기도 하므로, 모든 커맨드에 액터가 필요하지는 않습니다.
리드 모델(Read Model)
리드 모델은 사용자가 보는 화면이라고 생각하면 이해하기 쉽습니다. 사용자는 특정 이벤트로 인해 변경된 데이터에 대한 화면을 보거나, 특정 커맨드를 내리기 위해 입력값을 선택하는 화면을 보게됩니다. 예를 들어, 주문이 생성되고 난 뒤, 주문 정보가 포함된 주문 완료 화면을 보거나, 장바구니에 구매하고자하는 타이어를 담기 위해 사이즈로 필터링 된 타이어 제품군 목록 화면을 보게됩니다.
리드 모델은 다른 포스트잇들만큼 중요하진 않지만, 어떤 이벤트가 발생하거나, 커맨드를 내리기 위해 사용자에게 보여줘야하는 화면 목록을 기록하여 비즈니스 플로우를 더 쉽게 이해하는데 도움을 줄 수 있습니다. 관계된 이벤트나 커맨드 포스트잇 근처에 붙이면 됩니다.
외부 시스템(External System)
액터가 내린 커맨드가 처리되면 이벤트가 발생합니다. 커맨드를 처리하여 이벤트를 발생시키는 일은 우리가 개발할 시스템이 될 수도 있고, 외부 시스템을 가져다 쓸 수도 있습니다. 특정 커맨드를 처리하기 위해 가져다 사용하는 시스템을 외부 시스템이라고합니다. 예를 들어, 주문 취소 완료 알림톡 전송 요청 커맨드를 처리하여 주문 취소 완료 알림톡 전송됨 이벤트를 발생시키는 알림 시스템(알림톡) 외부 시스템이나, 주문에 대한 결제 요청 커맨드를 처리하여 결제 완료 또는 결제 실패 이벤트를 발생시키는 결제 시스템(아임포트) 등이 있을 수 있습니다.
시스템에 필요한 기능이지만 개발이 어렵거나, 핵심 비즈니스 로직과는 관계가 먼 커맨드들은 직접 개발하지 않고 외부 시스템을 사용하는 것이 좋습니다. 외부 시스템 포스트잇은 커맨드와 이벤트 포스트잇 사이에 붙이면 됩니다.
정책(Policy)
어떤 이벤트가 발생하면, 다른 커맨드가 연달아 발생해야하는 경우가 있습니다. 이벤트로부터 새로운 커맨드를 생성하는 것을 정책이라고합니다. 보통 ~A하면 ~B한다의 형태로 작성됩니다. 예를 들어, “주문 상태가 확정으로 변경되면 주문 확정 알림톡을 전송 요청한다”, “결제 취소가 실패하면 관라자에게 슬랙 알림을 전송 요청한다” 등이 있을 수 있습니다. 또한 정책은 “주문에 대한 결제가 완료되면, 온라인 판매처에 대한 주문일 경우 온라인 벤더 시스템에 주문 생성을 요청하고, 오프라인 판매처에 대한 주문일 경우 주문의 상태를 접수로 변경 요청한다”와 같이 분기 조건을 포함할 수도 있습니다.
실제 구현 시에는 정책이 도메인 이벤트 핸들러가 됩니다. 도메인 이벤트가 발생하면 핸들러에 의해 정책이 실행되고, 정책은 새로운 요청을 실행시킵니다.
애그리게잇(Aggregate)
커맨드를 처리하여 이벤트를 발생시키는 일은 우리가 개발할 시스템이거나 외부 시스템이 될 수 있습니다. 이 중 우리가 개발할 시스템을 애그리게잇이라고합니다. 애그리게잇은 “무엇”이 커맨드를 처리하고 이벤트를 발생시키는지, 더 자세하게는 시스템의 가해진 변경 사항이 하나의 트랜잭션을 통해 데이터베이스에 커밋되어야 하는 범위를 말합니다. 예를 들어, “주문 상태를 확정으로 변경 요청” 커맨드를 처리해 “주문 상태가 확정으로 변경됨” 이벤트를 발생시키는 “주문” 애그리게잇, “가격 정책 생성 요청”을 처리해 “가격 정책 생성됨” 이벤트를 발생시키는 “가격 정책” 애그리게잇이 있을 수 있습니다.
애그리게잇은 구현에 관계가 깊은 개념이고, 정의 자체도 개발 지식이 없는 인원은 이해하기 힘듭니다. 따라서 애그리게잇 단계는 개발자들로만 진행해도 좋습니다.
지금까지 나온 포스트잇들의 관계는 다음과 같습니다.
바운디드 컨텍스트(Bounded Context)
마지막 단계는 바운디드 컨텍스트를 구분하는 단계입니다. 바운디드 컨텍스트의 의미를 이해하기 위해서는 먼저 도메인과 서브도메인의 개념을 이해해야합니다. 도메인은 소프트웨어 개발을 통해 해결하고자하는 전체 문제 영역을 의미합니다. 서브도메인은 전체 도메인을 풀고자하는 문제의 특성에 따라 나눈 것입니다. 예를 들어, 병원전자의무기록 시스템을 개발한다면, 병원전자의무기록 도메인은 환자 기록 관리, 진료 예약 스케쥴링, 회원 정보 관리, 파일 저장 등의 서브 도메인으로 나눠질 수 있습니다.
각 서브도메인은 다른 서브도메인과 구분되는 맥락을 가집니다. 예를 들어, 환자 기록 관리 서브도메인에서 환자는 병력, 진료 기록 등을 가지지만, 진료 예약 스케쥴링 서브도메인에서의 환자는 예약 일자, 예약 시간, 담당의 등을 가지게 됩니다. 실제로 두 환자가 같은 환자일지라도, 어떤 서브도메인의 맥락으로 바라보느냐에 따라 다른 개념을 포함합니다.
바운디드 컨텍스트는 서브도메인의 문제를 해결하기 위한 해결책의 범위입니다. 해결책의 범위이기 때문에 구현 측면에서는 모듈(컴포넌트)에 대응되고, 조직 측면에서는 해결책 시스템을 개발하고 관리하는 하나의 팀에 대응됩니다. 이상적인 경우 하나의 바운디드 컨텍스트가 한 서브도메인에 대응되지만, 하나의 바운디드 컨텍스트가 여러 서브도메인을 포함하는 경우도 있습니다. 바운디드 컨텍스트는 보편 언어가 통용되는 범위이기도합니다. 위 예시에서 환자가 서브도메인에 따라 다른 개념을 가졌듯이, 바운디드 컨텍스트마다 동일한 용어라도 다른 의미를 가질 수 있습니다. 또한 같은 개념이라도 바운디드 컨텍스트마다 다른 용어로 표현될 수도 있습니다. 타이어라는 개념이 타이어 바운디드 컨텍스트에서는 타이어라고 불리지만, 주문 바운디드 컨텍스트에서는 상품이라고 불릴 수 있습니다.
정의한 보편 언어가 통용되는 경계를 포스트잇 사이에 선으로 그어 바운디드 컨텍스트를 구분하므로서 이벤트 스토밍은 종료됩니다.
3. 이벤트 스토밍 결과
이번 이벤트 스토밍을 통해 다음과 같은 결과를 얻을 수 있었습니다.
핵심 바운디드 컨텍스트
이벤트 스토밍을 진행하기 전, 명확한 전략적 설계 과정 없이 개발부터 진행하려고 하였습니다. 그때 구성하려고 했던 모듈(바운디드 컨텍스트)들은 타이어, 주문, 예약, 결제 등이었습니다. 그러나 이벤트 스토밍을 진행 결과 도출된 바운디드 컨텍스트는 주문과 상품 가격 정책 뿐이었습니다. 타이어는 포함조차 되지 않았습니다. 결국 저희 서비스는 다양한 판매처로부터의 상품을 판매처 별 가격을 비교하며 보여주는 것이 핵심 해결책이었던 것입니다. 판매하고자 하는 것이 타이어인지, 다른 상품인지는 별로 중요하지 않았습니다. 특히 그 중에서도 다양한 판매처의 비즈니스 플로우를 포함하는 주문 바운디드 컨텍스트가 가장 핵심적인 바운디드 컨텍스트였습니다. 개발에 가장 공을 들이고 집중해야할 부분은 타이어 정보 관리가 아닌 주문 관리라는 점을 알 수 있었습니다.
DDD 구현의 첫걸음
이벤트 스토밍을 진행하니 DDD 구현을 막막하게 하던 고민들이 대부분 해결되었습니다. 어떤 도메인 이벤트들이 있고, 어떤 애그리게잇들이 존재하며, 어떤 모듈(바운디드 컨텍스트)이 존재하는지 한눈에 볼 수 있게 되니 대부분의 설계 관련 문제들이 바로 개발에 들어가면 될 정도로 해결되었습니다. 구성원 모두를 위한 도메인 지식 공유와 비즈니스 플로우 이해, 보편 언어 구축이라는 결과부터 개발팀을 위한 구현의 발판까지 얻어갈 수 있었습니다.
보편 언어 구축 및 비즈니스 플로우 이해 강화를 통한 커뮤니케이션 비용 감소
이벤트 스토밍 도입 전에는 기획자가 도메인에 대한 해결책을 기획하고, 디자이너가 기획 내용을 디자인하며, 개발팀이 개발하고, 모두가 QA하는 단계로 개발이 진행되었습니다. 그러나 직군마다 서로 사용하는 언어가 다르고, 비즈니스 플로우에 대한 이해도도 각기 달라서 기획 내용이 비어 있거나 특정 상황에 대한 화면이 디자인 되어 있지 않거나 기획 내용을 잘못 이해해 개발이 진행된 뒤에 수정해야하는 상황들이 발생했습니다. 이 문제를 해결하기 위해 기획이 완료되면 개발자들의 리뷰를 받는 등, 단계들마다 중간 점검을 시도해보았으나 근본적인 해결책이 되지는 못했습니다.
그러나 이벤트 스토밍을 모든 직군이 참여해 진행하면서 비즈니스 플로우를 한 눈에 볼 수 있게 되었고, 보편 언어를 구축해 서로 동일한 언어로 소통하게 됨으로서 커뮤니케이션 비용이 매우 줄어 들었습니다.
기획 빈틈 발견
이번 이벤트 스토밍은 기획과 대략적인 디자인이 진행된 이후에 진행하였습니다. 기획 내용을 기반으로 이벤트 스토밍을 진행하면서 기획의 빈틈을 발견하고 메꿀 수 있었습니다. 도메인에서 발생할 수 있는 모든 이벤트들을 시간 순서대로 나열하다보면, 특정 이벤트들에 대한 기획이 빠져 있는 것을 발견하기 쉽습니다. 예를 들어, 타이어 커머스에서는 선택한 장착 예약 시점이 결제 완료 이후에 이미 다른 고객에 의해 점유 되었을 때 어떻게 해야하는지에 대한 기획이 빠져 있었습니다.
4. 이벤트 스토밍 팁
사실 이벤트 스토밍을 진행한 건 이번이 처음이 아니었습니다. 올해 초에도 기존의 닥터차 시스템에 대한 모두의 이해도를 높이고자 이벤트 스토밍을 진행했었는데요, 해당 이벤트 스토밍은 실패 했었습니다. 실패한 이벤트 스토밍과 성공한 이번 이벤트 스토밍을 진행하면서, 이벤트 스토밍을 도입 하시려는 분들께 도움이 될 만한 팁을 드리고자 합니다.
단계별 참여 인원
꼭 이벤트 스토밍의 처음부터 끝까지 모든 인원이 참여할 필요는 없습니다. 이벤트 스토밍은 아래와 같이 크게 빅픽쳐, 프로세스 모델링, 소프트웨어 디자인 세 단계로 나눌 수 있습니다. 각각의 단계에서 필요한 지식 수준과 얻고자하는 목표가 다릅니다. 빅픽쳐 단계에서는 모든 인원이 참여하는 것을 적극 권장합니다. 보편 언어를 구축하고 비즈니스 플로우에 대한 공통의 이해를 가져야하기 때문입니다. 프로세스 모델링 단계에서도 모든 인원의 참여를 권장합니다. 저희의 경우 이 단계에서 장착 예약 프로세스와 타이어를 지정한 주소로 직접 배송 받는 프로세스를 동시에 개발하는 것이 구현에 상당한 복잡도를 야기한다는 사실을 알게 되었고, 이때 모든 의사결정자가 이벤트 스토밍에 참여 중이었기 때문에 그 자리에서 빠르게 직접 배송 프로세스는 이후 구현으로 넘긴다는 결정을 내릴 수 있었습니다. 소프트웨어 디자인 단계는 구현에 대한 지식이 필수적이므로 개발자만으로 진행해도 충분합니다. 비개발 직군 구성원들에게 하나의 트랜잭션으로 변경 사항이 커밋되어야하는 범위라는 개념을 이해시키기는 상당히 어렵습니다.
좁은 타겟 도메인
해결하려는 문제 영역을 최대한 작게 좁히는 것을 추천 드립니다. 도메인이 너무 크면 이벤트 스토밍에 너무 많은 시간이 소요되고, 시간이 많이 소요될 수록 구성원들의 참여도와 집중력은 떨어집니다. 그렇게 되면 시간은 시간대로 소모하고, 원하는 결과는 얻지 못하는 결과가 발생할 수도 있습니다. 저희는 이번 타이어 커머스 이벤트 스토밍에 4일에 걸쳐 5~6 시간 정도를 사용했는데요, 이마저도 후반에 가면 집중도가 살짝 떨어지는 느낌을 받았습니다. 향후 이벤트 스토밍들은 구성원들의 이해도가 더 높아짐에 따라 소요 시간을 더 줄일 수도 있을 것 같습니다.
DDD의 전략 측면에 대한 이해
DDD의 개념들은 크게 큰 관점에서의 설계에 관련된 전략적 측면과, 세부적인 구현에 관련된 전술적 측면으로 나눌 수 있습니다. 전술적 측면의 개념들은 애그리게잇, 엔티티, 값 객체(Value Object) 등이 있고, 전략적 측면에 대한 개념들은 바운디드 컨텍스트, 서브도메인, 컨택스트 매핑 등이 있습니다. 저희는 전술적인 측면에서 DDD를 시작하였기 때문에 전략적 측면에 대한 이해가 부족했습니다. 그 상태로 이벤트 스토밍을 진행하면서 후반 단계에서는 계속해서 혼란이 발생했고, 이에 대한 해결책은 전략적 개념들에 대한 깊은 이해임을 알 수 있었습니다.
마치며 — 다음엔 같이해요
긴 글을 시간 내어 읽어주셔서 감사합니다.
기술 블로그의 끝은 아시다시피 채용 어필로 이어집니다. 타이어 커머스 영역에서 이벤트 스토밍을 적용함으로써 이전보다 효과적으로 문제의 본질을 바라볼 수 있었는데요. 국내 2500만 대의 차량 운전자 분들이 오늘날 겪고 있는 다양한 차량 증상, 사고들이 손쉽게 해결되기 위해서는 찬찬히 본질을 파악하며 풀어야 할 문제가 아직 산더미 처럼 쌓여있습니다. 우리 같이 자동차, 정비 도메인에 딥다이브하며 운전자들이 겪는 다양한 차량 문제들을 함께, 하나씩, 쉽게 해결해 줄 수 있는 플랫폼을 만들어가보아요. 공식 채용 페이지를 통해 오토피디아, 일하는 방식, 조직 문화, 채용 중인 포지션에 대해 더 자세한 정보를 확인하실 수 있습니다.
그럼, 다음 글에서 다시 만나요!
글쓴이
.png&optimizer=image&quality=80&width=280)
.png&optimizer=image&quality=80&width=280)
