일하지 않는 사람은 가라
이 글은 적당히 갖춰나간 운영 환경의 후속 글이다. 이전 글에서는 서비스의 외형적인 모습을 소개했다면, 이번 글에서는 그것을 가능하게 했던 내부의 문화를 소개한다.
MSAMicro Service Architecture
이 삽질을 3년이나 하고 나서야 뼛속까지 알게 되었다. 이건 기술의 문제가 아니었다. 문화였고 일하는 방식이었다. 익스트림 프로그래밍Extreme Programming, 이하 XP이 소개된 지는 이미 20년이 넘었지만, 계속해서 XP를 얘기하는 이유는 MSAMicro Service Architecture는 일하는 방식과 떼어서 얘기할 수 없기 때문이다. 아주 많은 작은 서비스들에게 역할과 책임을 부여하고, 그 서비스들이 상호 작용하며 만들어낸 서로 공존하는 상태. 그것이 바로 MSA 아니던가? 마이크로 서비스를 만드는 사람들이 이렇게 일을 하고 있지 않으면, 그건 거추장스러운 기술 셋으로 덧씌워진 또 다른 형태의 어렵기만 한 따분한 개발 규칙일 뿐이다.
우리는 소통 도구로 두레이(Dooray)를 사용한다. 사실 두레이(Dooray)라는 툴을 도입한 것이 핵심은 아니다. 3년 정도에 걸쳐 짧은 스프린트 단위로 점진적으로 개선해가며 일하는 방식이 꽤 익숙해져 있었고, 이젠 진짜로 개발팀에서 중간관리자를 없앤다는 선포가 있었다. 단순히 선포만 했던 게 아니라, 실제 직급/직책을 없앴고, 직급/직책별로 다르게 책정되어 있던 휴가 일수도 동일하게 조정했다. 처음에는 의도적으로 중요한 논의 자리에 기존까지 중간관리자 역할을 해 왔던 사람들을 제외하기도 했다. 불편해도 직접 소통하자는 것이다. 거기에 하나 더해서, “두레이(Dooray)에 적힌 것만 일로 간주한다”라는 꽤 공격적인 방식도 사용했다. 우리 회사에 두레이를 도입한 이야기는 아래 두 편에 흥미진진하게 적혀 있다.
변화를 원하는 조직이라면, 흔히 이런 생각을 한다.
- 중간 관리자를 없애자
- 불필요한 회의를 없애자
- 보고서를 없애자
- 직접 소통하게 하자
“권위주의와 관료주의”를 뿌리 뽑겠다는 최고 경영자의 결심과 실제적인 행동이 있지 않으면 불가능한 일이다. 하지만, 이렇게 문화를 바꿨다는 전제하에, 두레이(Dooray)는 정말 멋진 도구이다!
팀장은 필요 없다
현재 우리 회사에는 50여 명의 개발자가 있다. 개발팀장은 나 한 명이고 모두가 개발자이다. 당연히 그전에는 중간중간 소규모 영역을 이끄는 팀장들이 포진하고 있었다. 그들을 “관리”라는 쓸데없는 업무에서 해방시키고, 다시 코드를 짜는 원래의 자리로 돌려보냈다. 그 과정을 소개한다.
‘소규모 개발팀장’의 문제점
이들의 주 업무는 업무 배분, 설계, 소통, 일정 관리, 팀원 관리, 정서(?) 관리 등이다. MSA과 관련된 기술을 사용하고는 있었지만, 개발팀장 중심으로 팀의 경계는 엄격하게 유지되어 있었다. 여전히 팀장이 팀의 일감을 정하고 팀원들에게 배분하는 형태. 다른 팀과 소통할 일이 있으면 팀장이 주도적으로 소통을 하고 팀원들에게 전달해주는 방식이었다.
이 방식의 문제점은,
- 팀장은 개발 이외에 해야 할 일이 많아진다
➠ 개발을 적게 하게 된다
➠ 개발을 안 하게 된다
➠ (개발을 안 하기 때문에) 판단력이 흐려지게 된다
➠ 말을 전달하는 역할만 하게 된다
➠ 사실상 리더십을 잃게 된다.
바지 팀장(?)으로 전락. - 유사한 기능이 각 팀에 중복으로 존재하게 된다. 실제로 상품, 점포, 주문, 등의 모듈이 2개 이상 존재했었다. ➠ 낭비
이미 시작된 변화
MSA는 하나의 큰 비즈니스가 여러 개의 작은 서비스(micro service)로 쪼개져서 상호 작용 하며 큰 비즈니스를 만들어가는 방식이다. 각 서비스는 자신의 책임을 다하면 되고, 필요한 서비스끼리 서로 소통하면 된다. 즉, 한 서비스 한 서비스가 자신의 책임에 맞는 일을 다 하면 된다. 여기에 다른 뭔가가 끼어들면 혼선이 생긴다. 원래의 의도가 변질될 수 있다. 그래서 우리 개발팀에서는 각 서비스 개발자가 직접 소통을 시작했다.
그래도 개발 리더는 필요하다
여전히 개발자들 사이에서 리더는 필요하다. 그 리더는 기존처럼 의사소통 담당자가 아니라, 여전히 개발자여야 한다. 개발자로서 리더십을 발휘해야 한다. (다른 모듈과의 연결 측면에서) 복잡도가 높은 모듈이 존재하는데, 선임개발자는 그러한 모듈을 맡아서 주위 연관된 모듈 사이에서 리더십을 발휘해야 한다. 여러 모듈이 상호작용 하는 그 중심에서
- 이슈를 드러내고,
- API 형태 또는 json format을 결정하고,
- 정책을 정하고,
- 모듈의 경계에서 발생하는 문제의 원인과 해결책을 찾아내고,
- 코드를 리뷰해주는 일
여전히 개발자로서 이런 역할을 하면서 리더십을 발휘해야 한다.
이렇게 개발 리더에 대해 새로운 정의를 내리고 나니, 누가 실제로 리더인지가 보였다. 회사가 임명해준 직위로서의 리더가 아니라, 실제 일터에서 리더십을 발휘하고 있는 사람이 누구인지가 보였다. (두레이의 도움으로!) 그 리더십에 힘을 실어줌으로써 개발팀 전체의 수준을 끌어올릴 수 있었다.
하지만 그 반대로, 기존에 해 오던 역할이 없어져 버린 사람들도 있었다. 앞에 말했던 바지 팀장으로 전락해버린 이들…
이미 그들에게 닥친 변화.
누군가는 성공적으로 변화의 문턱을 넘어섰지만, 누군가는 여전히 이전의 입장을 고수하고 있다. 이런 문화 속에서는 바지 팀장의 영향력이 미치는 곳은 없다. 자연스럽게 물러나게 된다.
micro 소통
어떤 형태의 보고서든 그것이 가진 문제는, 거기엔 ‘사실’ 빠져있다는 것이다. 제아무리 상세하게 작성된 보고서라 해도 그것은 사실을 그대로 반영하지 않는다. 쓰는 사람의 관점으로 재해석된 이야기일 뿐이다. 실제로 일어난 일련의 사건 중에, 보고서 작성자는 자신의 주관적 판단에 의해 보고서에 담을 내용과 무시할 내용을 결정한다. 그렇게 작성자에 의해 선택된 정보들이 모여 한편의 보고서가 만들어지는 것이다. 보고서는 보고되는 맥락 안에서만 의미를 갖는다. (세상 모든 이야기가 이렇지 않나? ‘역사는 사실인가?‘라는 질문에, ‘역사는 특정 관점으로 해석된 이야기일 뿐이다’라고 대답하는 것과 비슷한 듯) 이렇게 작성한 사람의 관점으로 해석된 보고서는 2~3단계만 거처도 심한 왜곡이 일어난다.
그럼 보고서를 없애면 방법이 있나? 중간관리자를 뺀다면, “중간”이 아닌, 단 한 명 남은 그 관리자는 어떻게 상황을 파악하지?
어떻게 하긴!
보고서가 없다는 말은, 전부 다 본다는 말이다.
모든 직원이 하는 일을 전부 다?
“Yes! 전부 다!”
그걸 가능하게 해 주는 게 두레이다. 페이스북의 타임라인을 보듯이, 그렇게 쭉쭉 보면서 각자 자신의 입장에서 생각을 보탠다. 개발 팀장인 나도 그렇게 한 줄의 생각을 보탤 뿐이다. 그렇게 생각이 모여지면 거기서 끝. 모여진 생각으로 코드로 구현하고 배포를 해서 출시하면 끝이다.
빠른 의사결정
두레이에서 생각이 모여지지 않으면 관련자들만 모여 합의점을 찾으면 된다. “관련자들만” 모이려면 그들이 누군지 알아야 하는데, 댓글로 생각을 보태가는 과정을 통해 이미 각자의 생각은 드러났고, 논의의 필수 참석자들은 가려진다. 이미 두레이에서 충분한 대화를 나누고 왔기 때문에 사전 설명 같은 건 필요 없다. 바로 핵심으로 들어가서, 화이트보드에 쓱쓱 그리며 논의를 하면 된다.
이렇게 일하다 보면 개개인 간의 연결은 점차 탄탄해지고, 문제 해결 속도도 점점 빨라진다. 정말 짜릿할 때는, 대면 미팅을 한 번도 하지 않고, 중요한 논의/결정을 두레이상에서 진행하고 개발/출시까지 끝냈을 때다. 당연히 큰 기능은 이렇게 못한다. 아주 작은 단위로 쪼개졌을 때 가능한 일이다. 결국 큰 시스템도, 이런 자잘한 기능이 모여서 만들어지는 거잖아? 보고서 같은 게 다 없어지고 나면, 이런 자잘한 기능을 만들어가는 과정을 지속해서 하는 것만 남는다.
어떤 회사에서는 프로젝트/운영을 선 긋듯 싹둑 나눠버린다. 날짜를 박아놓고, 그 날짜 전후로 프로젝트와 운영을 나눈다. 프로젝트 기간에는 빡쎄게 개발하다가 그 날짜가 다가오면 오픈을 한다. 그리고 오픈 후에는 더 빡쎈 운영이 기다리고 있다. ‘운영 안정화’라고 이름 붙인 그 시간이 지나면, 지금까지 만들어온 것을 최대한 손대지 않고 조심조심 다루어야 한다. 그때부터는 software가 아니다. 더이상 손댈 수 없는 hardware가 된다.
하지만 이렇게 두레이를 사용하며 micro 소통방식으로 일하다 보면 프로젝트/운영의 경계가 모호해진다. 그냥 일상적인 일이 되어버리지.
글 앞에 평등
또 한 가지.
사실 토론은 몹시 어려운 행위다. 그 누구보다도 토론을 잘해야 할 것 같은 정치가들의 토론 장면을 봐도 싸움으로 치닫는 경우를 많이 봐왔고, 권위에 의해 결정이 되는 경우도 많다. 그 권위는 경력, 직책이 될 수도 있고, 말빨일 수도 있고, 목소리 크기일 수도 있고, 평소의 인맥일 수도 있고, 그 사람이 갖춘 지식에서 올 수도 있다. 경력이 많다고, 아는 것이 많다고, 그 사람의 생각이 맞는 건 아니잖아? 물론 그런 권위가 주는 힘을 아예 0으로 만들 순 없겠지만, “말” 보다는 “글”이 그런 권위를 줄여준다.
한 번에 확정하지 않고 지속하기
소프트웨어 개발 과정에서 다루는 문제는 대부분이 모호한 문제다. 모호하지 않은 문제라면 이미 해결책이 나와 있고, 그 해결책은 이미 제품에 가까운 모양까지 갖추고 있다. 즉, 분명한 문제는 문제가 아니라는 얘기. 그 정해진 해결책을 하는 것은 그냥 하면 될 일이다. 개발과정에서 만나는 대부분의 일은 해결책이 정해지지 않은 문제들, 즉 한 발 한 발 나가보면서 다시 확인하고 궤도를 수정하며 가야 한다.
“정할 수 없는 것은 정하지 말자”
어찌 보면 당연한 말 같은데, 그전에는 “정할 수 없어도 정해야 한다”라는 미신을 가지고 있었다. “정할 수 없어도 정한다”라… 이 얼마나 바보 같은 말인가? 실패가 보장된 길이다. 드러난 부분까지 가보고, 거기서 또 들춰보고 또 한발 나가보고,, 이렇게 점진적으로 개선 해가며 가야 한다. 이렇게 두레이에서 소통을 하며 진행해왔다면, 다음 스텝을 나갈 때 그 전의 기록들을 들춰보면 된다. 머릿속의 기억은 시간이 가면 흐릿해지거나 왜곡되지만(각자 자신에게 인상적이었던 것을 더 잘 기억하므로) 두레이의 소통 기록을 보면 과거의 상태가 머릿속에 복원되어, 그 시점에서 다음 스텝을 이어갈 수 있다.
코드 리뷰
실제 개발을 해 보면 어떤 방식(web-api? grpc?)으로 communication을 하느냐보다 더 중요한 게 있다. ‘적절한 상황에 적절한 API를 사용하는가?‘이다. 물론, 중요한 스펙을 정할 때는 관련자들이 함께 모여 논의를 하며 정한다. 하지만, 어떤 결정 사항이든 “확정”이란 건 없다. “오늘”이라는 특수한 상황 속에서만 적용되는 결정이었고, 내일이 되면 그것은 또 어떻게 변할지 모른다. 개발하다 보면 새로운 파라미터가 추가되기도 하고, 결과 포맷이 변경되기도 한다. 그럴 때마다 두레이에 변경 상황을 알리기도 하고, wiki에 기록한 API 스펙 문서도 수정을 한다. 이런 일은 일상이다. 너무 자주 일어난다는 것이다. 변경사항에 대한 notify는 어느 누군가에겐 중요한 정보겠지만 또 누군가에겐 소음이다. 그냥 씹어버린다.
처음에는 이 문제를 개발자 개개인의 문제라 생각했다. 내가 어떻게 해 줄 수 있는 게 아니라, 그들이 더 잘해야 할 문제라는 생각. 하지만 그렇게 시간이 가도 바뀌지 않을 때는, 그 상황을 인정해야 한다. 그게 우리의 수준이라고 받아들이고, ‘그러면 어떻게 더 개선할 수 있을까?‘라고 생각하기로 했다.
“내가 전체 코드를 다 보자!”
예전에는 코드리뷰의 중요성을 잘 몰랐다. 개발자 개개인이 잘 짜야 하는 문제라 생각했다. 하지만 MSA처럼 여러 마이크로서비스가 얽혀서 동작할 때는 서로 확인해주는 것이 중요하다. 개개인이 잘 짜야 하는 문제라고 정의했을 때는, 사고가 나도 개인의 책임으로 돌리게 되고, 그 개인은 감추려고 한다. 즉, 서로 감추고 헐뜯고 책임을 전가하는 문화가 만들어져버린다. 서로가 함께 책임을 떠안아야 하는 문제라고 정의했을 때는, 문제를 드러내고 서로 확인해주는 문화가 생긴다. 일단은 나 혼자서라도 코드를 다 보자. 물론 남이 짠 코드는 내 눈에 잘 들어오지 않는다. 업무 지식이 부족할 때는 더더욱 그렇다. 그래도 안 하는 것보다는, 내가 할 수 있는 만큼만 하더라도, 안 하는 것보다는 효과가 훨씬 높다.
처음에는 그냥 코드 스타일만 확인했다.
좋은 코드 스타일, 쓸데없는 주석처리 없애기, 더 나은 표현식… 이렇게 시작하는 것은 2가지 효과를 가져오는데
- 코드를 작성자의 입장에서:
다른 누군가와 함께 코드를 보고 있다는 사실만으로도 잘 짜야 한다는 동기 부여가 생긴다.
- 코드를 리뷰어의 입장에서:
차츰 변경되는 코드를 보며 점점 그 부분에 대한 업무 지식이 생긴다.
이런 과정을 통해 코드 작성자와 리뷰어의 눈높이는 점차 맞아진다. 그리고 리뷰어를 통해 서로의 코드는 연결된다. 코드 리뷰하다가 짜릿할 때는, A가 작성한 API가 변경되었는데, B는 여전히 이전의 방식대로 사용하고 있는 것을 발견하고, A와 B을 연결시켜 줄 때이다. 현장에서 어떤 순간에 드러날지 모를 미래의 bug를 오늘 해결한 것이다.
코드가 가장 좋은 문서라고 얘기하곤 한다. 문서를 작성한 후로 코드의 변경사항을 지속해서 문서에 반영해주는 것은 너무 어렵고, 문서는 만들어진 그 순간 과거 어느 시점의 상태를 드러낸 것일 뿐이다. 그래서 코드를 봐야 한다고 한다. 하지만, 그것은 모든 코드를 볼 수 있을 때의 얘기지, 전체 코드를 머릿속에 다 꿰고 있기가 가능한 일인가? 이 부분에 대해 “코드리뷰”가 현실적인 방법이라 생각한다. 완벽할 순 없지만, 모두의 이해도를 차츰차츰 높여가는 것, 서로의 연결고리를 차츰차츰 조밀하게 맺어 나가는 것. 앞에서 얘기한 두레이를 통한 협업과 더불어, 코드 리뷰로 생각이 공유되도록 하는 것이 XP에서 얘기하는 “아기 발걸음”, “오늘 할 수 있는 최선을 다하기”의 원칙을 잘 반영한 실천 방법이라 생각한다.
마무리
우리의 결과물은 기술과 사람이 만났을 때 비로소 만들어진다. 물론 한두 명의 고오오오오급 개발자가 대부분 기능을 만들어내는 서비스도 있다. 하지만 적어도 MSA를 지향하고 있다면, 그것을 만들어내는 개발자 한 사람 한 사람도 MSA처럼 움직여야 할 것이다.
서두에서도 말했듯이, 작은 많은 서비스들에게 작은 역할과 책임을 부여하고, 그 서비스들이 상호 작용하며 만들어낸 서로 공존하는 상태. 그것이 바로 MSA다. 우리도 그렇게 일해야 한다.