찐 개발자의 퍼실리테이션 도전기 #2

in Culture on Agile


회의 전 배경

서버를 Ruby로 Renewal 할 것에 대해서는 모두에게 공유가 되었다. 어느 날 개발팀장님이 나를 불러서는 MSA로 진행을 했으면 한다라고 이야기를 했다. 나는 Monolithic으로 하는게 더 우리 상황에 맞지 않냐면서 반대 의견을 내었다. 참고로 팀장님은 Monolithic을 더 좋아하고 나는 MSA를 더 좋아하는데 지금 주장하는 것은 오히려 반대라니 참 아이러니한 일이다. 이 자리에서 여러가지 의견도 나오고 논의가 있었지만 결론이 나지는 않았다. 그래서 개발팀 사람들에게도 의견을 한번 물어보고 결정하자고 하고 그 회의는 마쳤다. 다음주에 Sprint Meeting이 있긴한데 아직까지 기획자가 전담으로 붙어있는 구조가 아니다보니 Evaluation해야 할 티켓들도 없는 상태라서 조금 곤란한 상황이다. 그래서 그 회의에서 지난 Sprint에 대한 회고와 그때까지 파악되는 일에 대한 인차지 결정만 하고 Monolithic vs MSA , REST vs GraphQL 에 대해서 개발팀원들과 논의를 해서 결정하기로 했다.

회의 당일 아침

회의 시간은 90분이다. 다들 하고 있는 기존 업무들도 있고, 회의실 예약도 치열해서 더 이상 시간을 내기는 힘들다. Daily sync 시간과 겹치게 sprint meeting을 잡아서 앞에 sync 10분, 회고 10분을 잡더라도 70분만에 2가지 결정을 해야 한다. 그럼 한 개의 결정을 35분의 시간 안에 끝내야 한다. 짧은 시간에 급하게 결론을 내린다고 하더라도 결국 그 결정이 마음에 안드는 사람들은 협조적이지 않을 것이다. 난 그렇게 생각안하는데… 거봐 내가 뭐랬어. 저건 안된다니깐 왜 저렇게 결정을 내서… 등등으로 생각하기 쉽다. 그리고 대부분의 결정에서 깊이 생각하지 않고 그냥 기존에 본인이 알고 있는 것에 기반한다던지 아니면 본인이 더 선호하는 쪽으로만 의견을 내기 쉽다고 생각했다. 그래서 그들에게 판단을 할 수 있는 기준을 제시해주고 싶었다. 그래서 70분에 2개의 결정도 빠듯하다 싶었지만, 한 가지 결정을 더 추가해서 총 3개의 결정을 내리도록 설계했다. 먼저 어떤 기준으로 가지고 결정할 것인지에 대한 지표에 대해서 정하고, 정말로 결정해야 할 2가지 항목에 대해서는 앞서 정한 지표를 기준으로 판단하도록 하는게 더 적절할 것이다라고 판단했다. 개발팀에 미리 비전과 미션 같은게 정해져 있는 상황이라면 이런 과정이 필요 없을 것이지만, 그것이 없는 상황에서는 그것과 같은 역할을 할 수 있는 판단기준을 만들어 주는 것이 더 좋을 것이다 라고 판단했다. 결국 70분에 3가지 결정을 해야하니 1가지 결정당 사용할 수 있는 시간은 20분 정도가 된다. 그래서 5분 동안은 브레인스토밍(발산)의 시간을 가지고, 그걸 짧은 시간안에 그루핑(비슷한 의견들을 하나로 모으기)하고, 평가(가중치 점수를 둔 중복투표)로 진행을 하고자 설계를 했다. 그래서 결정해야 할 3가지에 대해서 주제를 적어둔 노션 페이지를 미리 만들어 두었다.

  • 개발팀에서의 중요한 가치 : Top3 를 뽑아서 아래 결정에서 이것을 기준으로 평가
  • Monolithic Architecture vs Micro Service Architecture
  • Restful API vs GraphQL

회의 시작

먼저 Daily sync를 진행했다. 15분 걸렸다. 예상 시간보다 5분 늘었다. 지난 sprint 회고를 하고 sprint 종료를 선언했다. 그리고 티켓 evaluation과정 없이 각자 작업하면서 티켓을 만들어서 진행중인 sprint에 추가하도록 하고 새로운 sprint를 진행했다. 이 과정에서 파악된 해야할 일에 대해서는 개발팀장님이 인차지를 각각 임명하였다. 이렇게하니 이미 시간은 31분이 지났다. 59분 남았다. 이걸 정해진 시간내에 결정할 수 있을까 라는 걱정이 들기 시작했다. 그리고 Renewal관련 백엔드 개발자들과 이야기한 내용에 대해서 정리해서 개발팀 모두와 공유했다. 미리 노션에 이야기 할 거리를 적어두어서 그걸 보면서 진행해서 3분 정도안에 끝냈다. 이제 34분이 지났다. 남은 시간은 56분이다. 이렇게 앞의 과정에서의 시간이 얼마나 걸릴지 몰라서 3가지 주제에 대해서 얼마의 시간을 사용할지를 미리 구체적으로 계획하지는 않았다.

먼저 개발팀에서의 중요한 가치에 대해서 각자 의견을 내달라고 했다. 이렇게 말만하면 무슨 말인지 이해하기 힘들 수 있으므로 내가 미리 몇가지를 적어두었다. 빠른 개발, 쉬운 코드, 채용 등… 여기에서 최상위 3가지를 결정해서 앞으로 할 두 가지 결정에서는 이걸 기반으로 판단하고자 한다라고 참석자들에게 이야기했다.이렇게 의견을 내는데 6분의 시간을 주고, 결정하는데 까지는 10분을 사용하기로 정했다. 그렇게 하니 여기까지 50분의 시간을 사용하며, 남은 2가지 결정에는 각각 20분씩 사용할 수 있게 된다. 그 2가지에 대해서 각각 5분 발산, 15분 평가를 하면 될 것이다라고 나름 생각했다.

사용할 수 있는 도구는 신호등카드이다. 얼마전 마님에게 4세트를 받아서 회사 회의실 4곳에 한 세트 씩 두었다. 시간도 많이 없고, 나도 이 도구 사용에 숙련자가 아니라 판단이 힘들어지는 방법을 선택하지는 않았다. 나도 제대로 이해못하는 방법을 사용하면서 참석자들에게 왜 이렇게 결정을 했는지에 대해서 이해시키는건 힘들거라 생각했다. 그래서 그냥 단순히 빨간색 0점, 노란색 1점, 녹색 2점의 점수를 부여하는 식으로 각각 항목에 대해서 다중투표를 하도록 해야겠다라고 정했다.

발산이 끝난 다음 여러 항목들을 보호 이해가 힘든 것들에 대해서는 그 항목을 작성한 사람에게 설명을 부탁하고, 이미 나온 의견과 비슷한 것에 대해서는 양해를 구한 다음 하나로 합쳤다. 그런 다음 위에서 부터 하나씩 신호등 카드를 이용해서 투표를 해달라고 했다. 이 과정이 모두 마친 후 Top3를 정했다.

  • 업무 프로세스 개선 / 업무 자동화: 14
  • 개발자의 성장: 13
  • 쉬운 코드: 13

이렇게 Top 3였고, 12점이 2개 더 있었다. 그래서 Top5를 하는게 어떻겠냐는 의견이 나왔다. 순간 당황스러웠으나 그냥 빠르게 그러자고 했다. 원래는 앞으로 평가할 각 항목에 대해서 여기서 정한 Top3 를 기준으로 각각 평가를 할 계획이었으나 한 가지당 15분의 평가시간안에 발산된 의견수 x 택일할 안건 2개 x Top3 라고 한다면 의견이 5가지만 나와도 5 x 2 x 3 = 30번의 투표, 안건이 10가지면 60번의 투표. 남은 시간을 생각하면 이건 원활하지 않을 것 같다고 빠르게 판단하고 그냥 Top 5를 위에 선언을 하고 아래에는 위 5가지를 염두해두고 각 항목별로 1번씩만 평가하는 방법으로 진행 하기로 결정했다. 그래서 12점인 2개를 더 포함하여 아래 5가지로 판단하기로 결정했다.

  • 업무 프로세스 개선 / 업무 자동화
  • 개발자의 성장
  • 쉬운 코드
  • 빠른 개발
  • 채용

여기까지 하니 전체 회의 시간의 46분이 지났다. 예상보다 4분 일찍 끝나서 다행이라는 생각이 들었다.

이제 본 주제 첫 번째인 Monolithic Architecture vs Micro Service Architecture 에 대해서 진행했다. Web, Mobile 등은 당연히 프로젝트 별로 나뉘는데, 서버 구성을 어떻게 할 것인지에 대한 결정이며, 우리가 개발해야할 서비스 중 현재 확정된 것들이 뭐뭐가 있다 라고 팀장님이 미리 정리해 놓은 것을 참석자들에게 전달하고, 각각의 장단점에 대해서 55분까지 의견을 내고, 70분까지 평가하겠다라고 이야기를 하면서 노션 페이지에 기록했다. 53분쯤 되었을때부터 의견이 거의 안나오기 시작했는데, 일단 55분까지 기다린 다음 하나씩 이야기를 들어보면서 그루핑을 했다. 그러고 신호등 카드로 평가를 했다. 평가 결과는 다음과 같이 나왔다.

누적점수

  • Monolithic: 69
  • MSA 68

이긴 항목

  • Monolithic : 3
  • MSA : 2
  • 동점 : 2

애매하다. 이걸 가지고 바로 Monolithic으로 결정하는건 뭔가 좀 찝찝하다. 그래서 이 현황을 보고 다시한번 최종 투표를 해달라고 했다. 순간적으로 원래 설계했던 의사결정 방법을 바꾼것이긴 하지만 그 당시에는 과연 그들이 우리가 첫번째로 정한 5가지 판단기준을 가지고 평가했을까에 대한 의구심이 들었다. 그래서 그걸 한 번 더 강조해주고 다시 투표를 하게 하는게 더 좋을것 같다고 판단했다. 녹색은 Mono에 1표, 노란색은 MSA에 1표, 빨간색은 기권으로 해서 최종 투표를 해달라고 했다. 그러면서 다시한번 우리의 판단 기준은 위에서 정한 5가지 항목이다 라고 이야기 하였고 그 항목들을 읽어주었다. 잠깐 (5초정도?)의 생각할 시간을 준 다음 다시 투표를 하였고, 그 결과 MSA로 진행하기로 결정했다. 평가결과가 뒤집혔다.

이제 두번째 주제인 Restful API vs GraphQL 에 대해서 정해야 한다. 이미 70분이 흘렀다. 20분이 남았다. 20분 뒤에는 점심시간이다. 회사가 점심시간에 대해서 엄격한 편이어서 조금 늦게 먹고 늦게 들어오는 것이 힘들다. 개발팀장님에게 혹시 개발팀은 30분 늦게 식사하는 것으로 가능하냐고 물었고, 팀장님은 경관팀과 그렇게 이야기해보겠다라고 대답해 주셨다. 그래서 일단 발산의 시간을 10분을 줘서 80분까지로 하고, 평가에 대해서는 따로 시간언급을 하지 않았다.

이 시점에 갑자기 아차 싶은 생각이 들었다. 미리 확인하고 넘어갔어야 하는게 있는데 그게 이제서야 생각이 났다. 그래서 팀장님에게 여기서 나는 결정이 최종결정이냐 아니면 이건 개발팀원들의 의견이고 이걸 참고해서 최종결정은 팀장님이 내는 것이냐라고 물었다. 개발팀장님은 최종결정은 본인이 내는 것이다라고 대답을 했다. 그래서 이 사실을 참석자들에게 다시 한번 이야기해 줬으며, 그래도 이게 헛된 시간은 아니고 개발팀 전체의 의견을 팀장님에게 전달하는 의미있는 시간이다라고 이야기 주었다.

여기서도 위와 똑같은 과정을 거쳤으며 평가결과는 아래와 같이 나왔다.

누적점수

  • Restful: 59
  • GraphQL: 66

이긴 항목

  • Restful: 2
  • GraphQL: 4
  • 동점 : 1

이번에도 위와 같은 방법으로 최종투표를 한번 더 진행, 그 결과 GraphQL 로 결정되었다. MSA로 하기로 이미 결정이 난 상태이니 internal API도 당연히 필요할 것인데, 그건 Restful로 하기로 팀장님이 의견을 냈고, 거기에는 모두 동의를 하였다.

시간은 거의 정확하게 90분이 되었다. 다행히 점심시간을 정시에 시작할 수 있게 되었다. 그리고 개발팀장님은 여기에서 나온 의견대로 진행하기로 그 자리에서 바로 최종결정을 내렸다.

회고

어쨌든 주어진 시간 안에 3가지 항목에 대해서 모두 결정을 할 수 있어서 다행이라는 생각이 든다. 과연 각각 항목에 대해서 처음 정한 5가지 기준으로 모두들 평가했을까에 대해서는 그렇지 않을 가능성이 높을거라 생각들지만, 앞으로 뭔가 결정할 일이 있을때 이런 과정을 반복한다면 조금씩 더 개선되지 않을까 생각된다.

회의를 설계하는 과정을 가지는 것과 가지지 않는 것의 차이는 크다. 회의 시작 전 이번 회의에서 꼭 결정해야 할 것에 대해서 미리 생각을 하고, 앞에서 이야기 할 것들에는 얼마의 시간을 사용할 것이며, 결정을 하는데는 얼마의 시간을 사용할 것인지를 미리 설계해 놓는다면, 회의 중 다른 돌발사항으로 인해 시간이 예상치 않게 흘러가더라도 남은 안건들의 시간을 조금씩 조정해서 정작 중요한 안건에 대해서 시간이 턱없이 부족해 지는 것을 막을 수 있다.

결정해야 할 안건의 성격별로 다른 결정방법이 필요하다. 결정하는 것을 어떻게 할 것인지에 대한 결정(Meta Decision Making)이 없다면 해당 주제에 대해서 최적의 결정을 했는지에 대한 의문이 결정 이후에도 계속 남아서 결국 제대로 실행되지 않을 위험성을 안고 있게 된다.

이 자리에서 내려질 결정의 범위에 대해서도 구성원들에게 미리 이야기를 해줘야 나중에 오해가 없다. 여기서 정하는게 최종 결정인지, 이걸 가지고 결정권자에게 결제를 받아야 하는지, 아니면 상급 회의에서 사용될 여러 선택 사항중에 하나인건지에 대해서 구성원들에게 미리 말해주지 않는다면, 이렇게 이야기해봤자 어차피 지들 맘대로 결정할껀데 라고 생각할 수 있다. 그러므로, 이 결정은 어떻게 사용 될 거에요. 이 결정이 최종 결정으로 채택 안될 수도 있지만, 우리는 개발팀의 의견을 모아서 이렇게 전달하는 것이고, 그 자체만으로도 우리가 할 수 있는 최선을 다 한거에요. 라고 구성원들에게 미리 이야기를 해주면 앞에서 이야기한 오해를 미리 방지 할 수 있다.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)