Geongyu

현재 개발팀은 FE / BE가 분리되어 각자의 팀으로서 운영중에 있다. 개발팀 자체를 운영하는 사람이 없다보니, 필요시에만 간단히 논의하고 각자의 일을 하는 형태로 운영되었다.

이러한 절차는 여러 비효율을 낳았는데, 예를 들면 아래와 같았다.

개발팀에서는 문서화를 점차적으로 진행해 나가는 시기였고, 이와 관련하여서 FE/BE팀과의 소통 과정에서 문제가 발생한 경우이다. 제대로된 용어 정리가 되지 않아 한가지 대상을 여러 용어들로 혼용하여 부르기 시작하였고, 이에 따라서 제차 물어보는 비효율이 발생하였다.

이처럼 서로가 서비스의 일부를 이해하는 언어, 동작이 다름으로 인해 모두가 한 곳을 바라보는데 어려움이 존재하였다. 신입모집 플랫폼을 개발하는 개발팀에서 어느정도 신입모집이 종료된 이후, 전체적으로 개발적인 여유가 있을 시점에 이해관계자들과 다같이 서비스에 대한 도메인 정리를 해야하겠다는 생각이 들게 되었다.

최대한 다양한 이해관계자들이 모일수록 좋기 때문에 리크루트 사이트를 사용한 사람들(TF팀, 회장단, 지원자)과 개발자들을 모두 모집하였다

이벤트스토밍이란?

❗️

들어가기 전! 해당 내용은 우아콘 2023에 나온 이벤트 스토밍 인 액션: 이벤트 스토밍 소개와 적용 방법 을 참고하였다

이벤트 스토밍이란, 프로젝트에 참여하는 모든 이해관계가작 한 자리에 모여 도메인 지식을 교환하고 용어를 통일하고 현재 프로젝트 내 회색지대를 파악하여 향후 의사소통 비용을 절감하는 워크숍을 말한다.

이벤트 스토밍을 하는 이유를 정리하면 아래와 같다

• 이해 관계자마다 동일한 대상을 다르게 불러서 의사소통이 어려운 경우
• 정책회의에 참석하여 서로 다른 대상을 생각하고 이야기 하는 경우
• 도메인 이해가 어려워서 특정 기능 수정에 대해 차이점을 설명하기 어려웠던 경우
• 특정 내용을 수정해달라고 요청 받았었는데, 다른 것을 변경해서 급하게 핫픽스를 해야했던 경우

위의 경우들은 결국 유사한 용어가 혼용되어 사용되었고, 도메인 요소간의 관계나 흐름을 정확하게 파악하지 못했거나, 정확한 도메인 용어에 대한 이해가 부족했기 때문이다.

이와 같은 다른 관점들은 결국 비효율을 낳고, 이를 해결하기 위해서 복잡한 비즈니스 도메인을 빠르게 탐색하고 학습할 수 있도록 해 모두가 바라보는 시각과 관점을 통일시키는 작업이라고 생각하면 될 것 같다.

1단계: 혼란스러운 탐험

우선 모두의 각자가 생각하는 리크루트 서비스의 도메인을 주황색 메모지에 작성해보았다.

💡

1단계 : 혼란스러운 탐험 각자가 알고 있는 도메인 이벤트를 작성한다. 각자가 작성한 이벤트는 볼 수 있지만, 토론을 하면 안된다. 스스로 옳다고 생각하는 방식으로 기록한다. 피자 두판 규모의 팀이라면 50분 정도 걸린다 40~50 분 정도 진행하면 15분 정도 휴식이 적절하다

1단계를 하면서 느낀점은 생각보다 도메인이라는 개념이 어렵다는 것이었다. 결국 어떠한 문제점을 해결하기 위한 부분으로 인식을 하고 적어내려갔다.

2단계: 타임라인 적용

2단계에서는 1단계에서 작성한 도메인 이벤트를 왼쪽에서 오른쪽으로 시간 순서대로 정렬해서 나열한다.

이 과정에서 중복되는 이벤트를 제거하고, 동시간대에 일어나는 도메인 이벤트는 상하에 배치하도록 한다.

💡

2단계: 타임라인 적용 모든 도메인 이벤트를 올바른 타임라인으로 정렬하고 실제로 중복되는 이벤트를 제거한다. 시간은 왼쪽에서 오른쪽으로 흐르고, 위에서 아래로 평행한 시간을 표현할 수 있다.

2단계는 드라이버 1명과 내비게이터를 정하여 진행된다. 드라이버는 포스트잇을 옮기고 붙이는 역할이며, 내비게이터는 드라이버에게 어디로 옮기라는 지시를 뒤에서 지시한다.

안티 패턴: 스포트카 & 자율 주행 혼자 많은 것을 알고 있다고 드라이버가 아닌데 혼자서 빠르게 진행하는 경우 혹은 내비게이터에게 묻지 않고 혼자서 진행하는 경우

안티패턴: 스포일러 본인 생각에는 자신의 머릿속에 분명한 것이 있으므로 함께 이야기하는게 무슨 의미가 있느냐는 생각으로 참여. 이미 문서를 잘 작성했는데 그걸 읽어라 하는 사람… 잘 독려하자

2단계에서 이벤트 스토밍의 대부분의 시간을 보내게 된다. 우리의 경우 2단계에만 거희 4~5시간이 걸리는 논의를 진행하였다.

도메인 이벤트별로 정렬하기 전, 내비게이터끼리 논의를 진행하는데, 해당 도메인 이벤트가 도메인이 맞는 것인지, 용어가 정확히 어떤 것을 가리키는지, 이런 이벤트가 존재했는지 등등 정말 다양하고 많은 말이 오가게 되었다. 이 과정에서 충돌되는 용어, 발생하는 질문들이나 갈등 등을 핫스폿으로 표시하게 되었다.

💡

핫 스폿 - 자주색 2단계에서 발생한 질문, 갈등 불평, 불만 사항을 시각화하고 캡처한다. "이건 왜 만든거냐..? 나는 이렇게 부르는데 너는 왜 이렇게 부르느냐?!" 와 같은 질문이나 갈등이 발생하면 핫 스폿으로 표시할 수 있다. 다만 이 워크숍은 정말 비싼 자리이므로 발생한 갈등에 대해서 당장 토론하지 않는다.(그 자리에서 바로 해결하지 않는다) 나중에 문제가 해결되면 핫 스폿 포스트잇을 제거한다. 핫 스폿을 파악하기만 하여도 의미 있는 워크숍이 된다!

서로간 도메인을 어디까지 보아야 하는지, 무엇이 도메인인지를 정의하는 것 또한 정말 유의미했다고 느껴진다. 해당 기능 혹은 절차에서 시스템이 해결하고자 하는 문제가 무엇이고, 이를 어떻게 해결하는지에 대해서 참여자 모두에게 유사한 관점을 심어준 것 같다.

또한 생각보다 작생됐던 도메인 이벤트들이 구체적이지 않아서 해당 내용을 이해하고 또 추측하는데 많은 시간이 걸린 것 같았다. 꼭 작성할 때는 오래 걸리더라도 최대한 명확하게 작성하는 것이 결국 시간을 단축시키는 방법임을 깨달은 것 같다.

느낀점

리크루트 개발팀 초창기 맴버로서 많은 시간을 해당 서비스 개발에 몸담고 있었다보니 내가 해당 서비스의 모든 부분을 알고 있다는 착각을 하고 있었던 것 같다. 나도 결국에는 내가 맡은 도메인 부분을 제외하고는 생각보다 정확하게 알고있는 것들이 많지만은 않구나를 깨닫고, 내가 모르던 리크루트 서비스의 도메인을 알아갈 수 있었던 것 같다.

내가 알고 있는 부분또한 누군가에게 설명하기 위해서 다시 한번 더 생각을 정리할 수 있는 기회가 되었던 것 같다.

이러한 점은 나 뿐만 아니라 같이 개발했던 개발팀들, 그리고 이를 사용했던 사용자들(TF, 회장단, 지원자) 모두가 유사한 말을 남겼었다.

단순히 이번 워크숍에서는 핫스폿을 찾는 과정까지만 해보았지만, 액터와 시스템, 액션, 정책과 같은 부분도 함께 찾아보는 과정도 기회가 된다면 해보고 싶다.