안녕하세요. 빠르고 안정적인 앱 배포를 위해 엔라이즈 제품 팀이 중요한 요소라고 생각하는 것들을 공유하는 세 번째 글입니다. 아마도 이번 글이 본 연재의 마지막이 될 것 같습니다. :)

모든 팀의 구성원은 다른 구성원들과 다양한 방법으로 정보를 교환하게 됩니다. 우리는 이 정보 교환의 효율성과 속도가 좋은 제품을 빠르게 배포할 수 있는 아주 중요한 요인이라 판단합니다. 이번 글에서는 엔라이즈 제품 팀의 의사 소통 방법들에 대해 공유해 보겠습니다.

1. 수평적 의사 소통

많은 팀들이 수평적 의사 소통을 위해 많은 노력을 기울이는 것으로 알고 있습니다. 수평적 의사 소통을 이야기 하기에 앞서 위대한 철학자 루트비히 비트겐슈타인은 1921년에 저서 “논리철학 논고” 에서 다음과 같이 말하였습니다.

The limits of my language mean the limits of my world. ¹

내 언어의 한계는 내 세계의 한계를 의미한다.

저는 한국어를 제 1 언어로 사용하는 사람이라면 위계질서가 있는 문화에 익숙한 만큼 수평적 의사 소통 역시 의식적인 노력을 통해서만 성취할 수 있으며, 단순히 호칭을 바꾸거나 닉네임으로 서로를 호칭하는 것 만으로는 이 현실적인 문제를 해결하기 어렵다고 생각합니다. 조금 단순하게 말해 보자면 근무 시간에만 사용하는 새로운 호칭 체계로는 그 사람의 의식을 변화시키는 것에 한계가 있다고 생각합니다.

엔라이즈는 표면적인 변화보다 현실적인 해결 방법을 찾기 위해 고민합니다. 그리고 현재까지의 결론은 팀의 일하는 분위기나 의사 소통할 때의 심리적 안정감, 그리고 수평적인 문화를 평가할 수 있는 지표에 집중하는 것이 수평적 의사 소통에 도움이 된다고 판단 하였습니다.

이쯤 오면 ‘수평적인 의사 소통’ 문화라는 것에 대해 정확한 정의를 할 필요가 있다고 생각합니다. 엔라이즈가 생각하는 수평적인 의사 소통의 필요 조건은 다음과 같습니다.

• 서열 상 윗 사람의 의견에 서열 상 아랫 사람이 반대 의견을 제시 하였을 때, 반대 의견을 제시했다는 이유로 인사 상의 불이익이 없을 것
• 서열 상 아랫 사람이 심리적 안정감을 잃지 않을 것
• 서열과 관계 없이 양 방향으로 정보 전달과 교류가 잘 이루어 질 것
• 쓸데없는 의전 행위가 없을 것(예: 상사 퇴근 전에는 눈치를 보며 퇴근을 못한다던지 등)

우리는 위 조건들이 수평적 의사 소통 문화를 형성하기 위해 추구해야 할 가치라고 생각합니다. 그리고 현재까지 우리는 수평적 의사 소통 문화를 잘 유지하고 있습니다. 특기할 만한 것은 엔라이즈에는 ~님 호칭이나 영문 이름 사용하기 같은 룰이 없다는 점입니다.

2. 주도적인 소통

별 다른 명칭을 생각하지 못하여 주도적 소통이라고 이름 지었습니다. 예를 들어 팀원 A 가 팀원 B 에게 업무적인 요청이 있어 B 에게 말을 걸려 하지만, 팀원 B 는 여러 상황으로 인하여(이어폰을 끼우고 업무 중인 상황이라던지, 다른 팀원과 토론 중이라던지 등) A 입장에서는 답변을 받을 수 없을 것 같은 상황을 생각해 봅시다. B 에게 요청을 하지 못하는 A 에게 ‘왜 B 에게 요청을 하지 않았나요?’ 라고 하였을 때 우리는 ‘B 님이 집중하고 계신 것 같아서요’, ‘B 님이 바쁘신 것 같아서요’, ‘B 님이 지금 중요한 일을 하고 계신 것 같아서요’ 등의 답변들을 흔하게 접합니다.

우리는 이런 상황에서 A 에게 절대로 수동적으로 행동해서는 안된다 고 이야기 합니다. 팀원 A 가 입사한 지 하루밖에 되지 않은 분이라 하더라도 팀원 A 에게 ‘자신이 현재 해야 할 일은 우주에서 가장 중요한 일 로 생각해야 한다’고 말합니다.

결과적으로 엔라이즈에는 각 팀원 스스로가 ‘자신이 필요한 일을 주도적으로 처리하기 위해 다른 팀원들의 업무를 중단시키는 행동(interrupt)’ 을 단순히 허용하는 차원을 넘어 권장하고 있습니다. ‘다른 사람이 바빠서 내 업무를 완료하지 못했다’ 라는 말은 지양되어야 할 행동입니다. 그 결과 엔라이즈는 메신저 기반 의사 소통은 꼭 필요한 경우가 아니라면 거의 하지 않습니다. Slack 등의 메신저 기반 의사 소통의 경우 많은 장점도 있겠습니다만 대화 흐름의 주도권을 요청자가 아닌 응답자가 가지게 되는 큰 문제점이 존재하기 때문입니다. 아무리 요청자가 급하더라도 응답자가 놓치게 되면 일이 진행되지 않게 되며 우리는 이런 문제를 가능한 만들지 않으려 노력합니다.

물론 필요하다면 얼마든지 Slack 등의 메신저 서비스를 사용합니다. 그러나 대부분의 경우 엔라이즈의 Slack 은 bot 들의 메시지로 채워집니다. 이런 식으로 말이지요.

3. 협력적인 소통

엔라이즈 개발 팀은 코드 리뷰와, Pull Request 의 자율적 시행입니다. 우리는 코드 리뷰나 Pull Request 등의 절차가 개발 과정의 필수 요소로 도입될 경우 결과적으로 팀을 더 기민하게 만드는 데에 효율보다는 저항으로 다가올 수 있다고 생각합니다. 그래서 모든 개발과 관련된 협업 작업은 개인의 판단 하에 이루어집니다. 스스로 생각하기에 코드 리뷰가 필요하면 그 즉시 코드 리뷰가 이루어집니다. 그렇지 않다면, 굳이 코드 리뷰는 진행하지 않습니다. 다른 모든 것들도 마찬가지입니다. 본인이 원한다면 짝 프로그래밍(Pair Programming) 을 주위에 요청합니다. 그 즉시 그 팀원은 짝 프로그래밍을 시작할 수 있습니다. 개발 팀만을 예로 들었습니다만 기획, 디자인 등 모든 부분에서 우리는 필요하다면 그 즉시 서로 리뷰를 해 주고, 짝으로 작업합니다.

물론 이것은 우리가 기획/디자인 팀 3명, 개발 팀 4명, 데이터 분석 팀 2명, 운영 팀 2명으로 구성된 작은 팀이기에 가능할 것이라 생각합니다. 팀원이 많아지고 그로 인하여 빠른 개발과 안정적인 배포가 흔들리게 된다면 우리는 더 나은 개발 절차를 찾기 위해 노력하고 변화할 것입니다. 그리고 이는 체계화된 조직론 하에 이루어지는 설계 변경이기보다 생명체가 자신을 유지하기 위한 항상성(Homeostasis) 에 더 가까울 것입니다. 단순히 팀원이 늘어난다고 하여 이유 없이 불필요한 절차가 추가되거나 하는 일은 없을 것입니다. 우리는 가능한 한 단순하고 빠른 소통을 할 수 있는 환경을 제공하기 위해 노력합니다.

4. 공동 코드 소유권(Collective Code Ownership)

우리는 공동 코드 소유권 이라는 개념을 개발 팀 뿐 아니라 모든 팀원들이 숙지하고 있습니다. 예를 들어 모든 코드는 모든 개발 팀원에게 공개되어 있기 때문에 누구나 열람하고, 수정하고, 배포할 수 있는 권한이 있습니다. 비단 코드 뿐 아니라, 기획 문서, 디자인 파일, 데이터 분석, 운영 등 제품 팀의 모든 분야에서 공동 소유권을 가지고 있습니다. 이를 통하여 특정 팀원에 종속적이 아닌 팀 전체가 유기적으로 제품 개발에 집중할 수 있는 환경을 만들고자 노력 합니다.

마치며

지난 글 과 지지난 글, 그리고 이번 글을 통해 엔라이즈 제품 팀이 어떤 개발 문화를 가지고 있는지, 그리고 어떤 가치를 추구하는지 알리고자 하였습니다. 글 말미에 늘 강조하지만 우리가 항상 옳은 선택을 하는 것도 아니며, 어떤 부분은 큰 잘못을 하고 있을지도 모릅니다. 하지만 저는 엔라이즈 제품 팀이 가지는 가장 강력한 장점은 바로 ‘변화할 수 있는’ 팀이라는 것을 말하고 싶습니다.

만일 이 연재 글이 도움이 될 수 있다면 그보다 뿌듯한 일은 없을 것 같습니다. 연재 글을 읽어 주신 분들께 감사의 말을 전합니다.

우리 팀에 흥미를 가진 개발자를 찾고 있습니다! 관심 있는 분들의 지원을 기다립니다. :)