서론

제가 미국에 파견을 온 지 얼마 지나지 않아서의 일입니다. 이쪽 사람들하고 이야기하다가 제가 옛날에는 일주일에 100시간씩 일하던 시절이 있었음을 고백한 적이 있었는데, 여기 사람들은 그 사실에 적지 않은 충격을 받았던 것 같았습니다. 사실 미국 개발자들은 워라밸이 황금 밸런스라던지, 신입사원도 억대 연봉을 받는다던지, 자율성을 충분히 보장받고 커리어 패스도 완벽하게 만들어나가고 등등의 모든 선진적인 문화를 다 가지고 있다는 환상이 있을 수도 있지만, 그러기에는 너티독의 끔찍한 크런치 문화에 대한 비판이라든지 아마존의 살인적인 업무 강도라든지 자기 몫만큼 일하면 해고당하는 넷플릭스에 대한 소문 등을 너무 많이 들었던 저는 이쪽 사람들이 충격을 받았다는 사실에 충격을 받았습니다. 그래서 사실은 120시간씩 일했는데 반올림해서 100시간이라고 말했다는 사실이나, 반년동안 하루도 쉬지 못하고 출근했던 시절도 있었다든지 하는 이야기는 마음속에 묻어 둘 수밖에 없었습니다.

사실 어느 정도는 이해할 수 있었던 것이, 이쪽 팀은 자율근무제로 일하는 것이 익숙했던 것입니다. 아직도 세상에는 자율출퇴근제가 급진적이고 조직 전복의 씨앗이 될 수 있는 위험한 제도라고 생각하는 사람들이 있기도 하고, 전사적인 자율출퇴근제의 시행을 방어하기 위해서 그라운드 룰이나 아침 조회, 집중 근무시간 등을 도입했다는 소문이 들리기도 하는 등 자율출퇴근제의 정착이 완전히 이루어지지 않은 느낌이지만, 사실 자율출퇴근제 보다도 더 진보된 자율성을 보장하는 근무 제도가 자율근무제도입니다. 우리 회사의 근무 제도의 경우 출퇴근 시간이 전사적으로 고정되는 일반적인 근무제에서 출근 시간을 개인이 정할 수 있는 선택권을 주었던 자율출근제, 그리고 일 4시간, 주 40시간의 제한이 있던 제한적 자율출퇴근제를 거쳐서 일 4시간 근무와 월 근무시간만 챙기면 되는 현재의 자율출퇴근제에 이르기까지 회사의 근무 제도는 근무 시간에 대한 개인의 자율성을 점점 더 보장해주는 방향으로 발전했습니다. 이 정도만 해도 평범한 직장인들(과 그라운드 룰에 지배당하는 일부 부서에 속하신 분들)은 충분히 부러워할 제도이지만 일부 기업들은 여기에서 더 나아가서 일 4시간이나 월 근무시간의 제한까지 삭제해버리고 근무 시간을 완전히 개인의 재량에 맡기는 자율출근제를 시행하고 있습니다. 그리고 이쪽 팀 역시 하루에 1시간만 일해도 상관없고, 일주일이나 한 달에 몇 시간을 일했느냐는 아무도 카운트하지 않고, 설령 출근을 안 하고 집에서 일해도 상관없는 형태로 완전히 자율적인 근무 제도로 일하고 있었습니다.

실제로 사무실에서 체류하는 시간이 한 달에 100시간을 넘길까 말까한 사람들에게 주 100시간 이야기를 했으니 그 ‘옛날이야기’가 여기 사람들에게는 생소하게 느껴질 수도 있을 것 같습니다. 물론 저도 반대로 내킬 때 일하고 내키지 않으면 일하지 않는 것처럼 보이는 이 팀의 ‘요즘 문화’가 생소하게 느껴지기도 했습니다. 사실 가장 의문이었던 것은 ‘그렇게 해도 일이 돌아가고 팀이 유지가 되나?‘라는 점이었습니다. 자신이 맡은 일에 대해서 책임을 가지고 일하며, 그 책임 아래에서 스스로의 업무 일정을 자율적으로 조정하는 문화에 대해서는 어렴풋이 이해할 수 있었지만 일을 하면서 매우 활발하게 소통이 일어나고 코드 하나를 반영하려고 해도 리뷰를 거쳐야 하는 매우 타이트한 협업 문화에서 정말로 같이 일하는 사람들이 옆에 없어도 상관이 없는지 궁금해졌습니다.

리모트 개발을 위한 협업 환경

기본적으로 이쪽 팀의 협업을 위한 도구는 Jira, Confluence, GitHub, Slack, Zoom으로 정리할 수 있습니다. 사실 이런 도구들은 이미 한국에서도 많은 회사들이 개발환경으로 쓰고 있거나 필요하면 쓸 수 있는 도구들이기 때문에 뭔가 실리콘 밸리에서나 쓸 것 같은 대단한 협업 툴을 통해서 사무실 내에 있는 사람과 밖에 있는 사람이 소통을 하거나 협업을 하는 것은 아니었습니다.

슬랙(Slack)은 메신저를 기반으로 한 기업용 협업 도구 입니다. 기본적으로 슬랙의 활용은 일반적인 메신저와 마찬가지로 서로 대화를 하고 의사소통을 하는 것에 기반을 두고 있습니다. 이 메시지의 전달이라는 측면에서는 저희가 사용하는 수많은 메신저 프로그램들과 크게 다르지 않습니다. 예를 들어서 아직 회사에 오지 않은 사람에게 너 언제 도착할 예정이냐 라고 물어보는 목적이라면 그 도구가 슬랙이거나, 카카오톡이거나, 심지어 SMS여도 아무 상관이 없을 겁니다. 다만 슬랙이 협업용 도구로 많은 포지션을 - 물론 최근에는 Microsoft Teams에 포지션을 많이 빼앗겼지만 - 차지하고 있는 이유는 멀티 플랫폼 지원이 확실하기도 하고, 워크스페이스 단위로 공간을 분리하는 기능과 그 공간에서도 주제에 따라 채널을 자유롭게 만들어서 대화 내용을 분리하는 개념, 여러 환경에 걸쳐서 매우 자연스럽게 전달되는 푸시 메시지, 그리고 무엇보다도 Git이나 Jira 같은 다른 개발도구들과 매우 자연스럽게 연계되는 강력한 확장성에서 그 이유를 찾을 수 있을 것입니다.

이 강력한 연계기능은 슬랙을 모든 협업 환경의 중심으로 만들어줍니다. 예를 들어서 어떤 개발자가 자신이 작성한 코드를 반영하기 위해서는 GitHub에서 PR(Pull Request)를 생성하고, 이에 대해서 누군가에게 리뷰를 요청하고, 해당 리뷰를 통과하면 반영 버튼을 눌러서 CI/CD 도구에 의해서 작성한 코드가 반영되도록 만드는 과정을 거칩니다. 만약 단순히 GitHub만 쓰는 상황이라면 리뷰를 해줘야 할 사람이 GitHub을 계속 리프래시 하거나 메일을 계속 체크하지 않는 이상은 자신이 리뷰를 해야 한다는 사실을 인지하기 어려워집니다. 만약 반영이 급한 상황이라면 메신저를 통해서 ‘리뷰를 해달라’라고 수동으로 요청을 하거나 근처에 있을 경우 직접 말을 걸어서 리뷰를 요청할 수 있을 겁니다. 하지만 슬랙과 GitHub을 연동시킬 경우 PR이 생성되는 순간 Bot이 해당 PR을 설정된 채널에 올려주고, 리뷰를 해야 할 사람에게 멘션을 주게 됩니다. 리뷰어는 자신의 업무를 진행하던 도중 푸시 메시지 등에 의해서 자신이 해야 할 리뷰가 있음을 인지하게 됩니다.

슬랙이 인기를 끌었던 것은 이러한 ‘업무 협업’의 관점에서 포지셔닝이 기존의 메신저들과 메일 사이의 중간지점 정도를 잘 찔렀다는 점이고, 실제로 협업 환경이 자동화 되고 고도화되면서 이 포지션의 도구, 그러니까 메일은 너무 번거롭고 메신저는 너무 기능이 없음에 대한 불만들을 슬랙이 잘 파고들었다고 볼 수도 있습니다. 그리고 강력한 연계 API와 봇(Bot) 개발 환경은 업무 환경이 계속 바뀌더라도 슬랙이 협업 메신저의 위치를 놓치지 않게 만들어주었습니다. 만약에 슬랙으로 연동하지 않았더라면 개발환경에 관련된 푸시 메시지를 받기 위해서 별도의 Jira 앱, 별도의 GitHub 앱 같은 것을 받아야 했겠지만 의사소통의 채널이 갈라지는 것도 좋은 모습은 아니고 심지어 GitHub 같은 경우에는 공식 모바일 앱도 아직 베타 상태로 사용하기 어려운 상태입니다.

사실 슬랙을 이용한 협업이야 워크스페이스를 만들고, GitHub 등 팀에서 사용하는 개발 도구들과 연동만 해주면 되는 것이므로 딱히 선진문물이라고 보기도 어렵고 구성하기 어려운 것도 아닙니다. 문제는 슬랙과 연동을 위한 모든 개발 도구들, 그러니까 GitHub이나 Jira 같은 도구들이 모두 사내망에 설치된다면, 슬랙은 인터넷망에서만 돌아가기 때문에 서로 연동이 안 되었다는 것이고, 개발환경과 연동되지 않는 슬랙은 딱히 쓸 이유가 없었기 때문에 별로 인기가 없었습니다. 그러니까 슬랙은 사내망에 들어갈 수 없었고, 사내망의 소스코드들은 인터넷망에 나갈 수 없었으니 이는 개발 문화의 선진화와는 별로 상관없는 그냥 정책의 문제였습니다.

이쪽 팀은 모든 개발도구를 서비스형, 그러니까 github.com이나 atlassian.com 등에서 클라우드로 제공하는 환경을 그대로 사용하였기 때문에 슬랙과의 연동에 아무런 어려움이 없었습니다. 그리고 모든 개발환경이 인터넷망에 위치한다는 사실은 자율근무를 위한 환경에도 매우 중요한 의미를 가지게 되는데, 인터넷 망에 있는 Jira, Confluence, Github, Slack, CircleCI 등을 사용하고 있으니 그 사람이 일하는 위치가 꼭 사무실일 필요가 없어지는 것입니다.

슬랙, 그리고 이와 연동되는 개발환경들이 일상적인 업무, 그러니까 개발에 필요한 지리적 경계를 허물어준다고 보면 Zoom은 회의 환경의 경계를 허물어주는 역할을 합니다. Zoom은 화상회의를 위한 솔루션이고, 생각보다 특별한 기능을 가지고 있지는 않습니다. 다만 그 화상회의가 비교적 높은 품질로 안정적으로 이루어질 수 있도록 하고 있고, 모바일 환경의 지원이 잘 되어 있고, 링크만 전송하여 누구나 바로 회의에 참석할 수 있도록 하고 있으며, 무료 버전도 충분히 쓸만한 등의 요즘 뜨는 프로그램들이 가지는 속성을 충실히 지원하고 있었습니다. 실제로 Zoom은 화상회의 솔루션 시장에서 엄청 높은 마켓셰어를 가지고 있는 것은 아니지만, 인하우스 환경에 종속될 필요가 없는 조금 더 캐주얼한 환경에서는 인기가 매우 좋은 제품이기 때문에 체감하는 점유율은 상당한 수준입니다.

하지만 멀티 플랫폼을 지원해야 하고, 화면 공유가 잘 되어야 한다는 정도의 요구사항을 빼면 온라인 회의를 위한 솔루션에 대한 요구사항이 엄청 크지는 않고, 그렇기 때문에 사용하는 솔루션이 Zooom 이거나, 행아웃이거나, Skype 이거나, 기타 등등 어떤 솔루션이어도 크게 상관없었을 겁니다. 즉 Zoom이 뭔가 특별한 기능이 있어서 기존에는 불가능했던 원격 회의를 가능하게 했던 것은 아닙니다. 그저 원격으로 일하는 문화가 이미 있었고, Zoom은 Slack인 GitHub등과 마찬가지로 그 문화를 위해 선택된 도구 중 하나라고 생각할 수도 있을 겁니다. 그렇다면 원격으로 일하는 문화는 도대체 무엇일까요?

재택 근무를 위한 문화와 가치관

저는 여러 회사에서 일해본 적이 없어서 다른 회사의 문화나 분위기를 잘 모르겠는데, 제가 일하는 회사는 모여서 일하는 것을 좋아합니다. 뭔가 자리가 애매해서 같이 일하는 사람이 책상 2~3칸 정도만 떨어져 있어도 불안해하는 분들이 있고, 주기적인 자리 이동을 통해서 같은 팀과 같은 그룹을 한 곳에 모아 두고, 최대한 같이 일하는 사람들이 물리적으로 가까이 위치할 수 있도록 건물에 최대한 많은 사람들을 빽빽하게 몰아넣고 테트리스 하듯이 자리를 최적화합니다. 뭔가 여러 명이 각 잡고 집중해서 일해야 할 때는, 어김없이 회의실에 A4 용지를 붙이고 프로젝트 룸에서 다닥다닥 붙어서 일을 합니다. 그 정도는 아니지만 뭔가 여러 사람이 집중해야 할 일이 있다면 회의실을 예약하고 회의를 만들고, 자리에 없는 사람을 찾습니다. 필요한 누군가가 자리에 없으면 기다리고, 전화하고, 어디냐고 물어보기도 합니다.

이러한 근거리 협업 문화는 일종의 습관이 되었습니다. 이러한 전통을 지키기 위한 노력으로 공간적 거리감을 열심히 줄여놨더니 자율출퇴근제가 도입되어 시간적인 거리감이 생기기 시작한 것이 어떤 사람들에게는 전통을 해치는 불편함으로 찾아왔고, 이를 방지하기 위해서 출근시간 단속이나 집중근무시간 같은 것이 도입된 부서도 있다는 소문도 있었는데 사실인지는 모르겠습니다. 만약에 그런 부서가 있다면 그것은 ‘관측되지 않는 위치에 떨어져서는 절대 같이 일할 수 없다’라는 확고한 양자물리학적 믿음이 바탕에 깔려있었을 겁니다.

반대로 ‘떨어져서 일해도 아무 문제 없다’라는 믿음이 생기려면 이는 그 조직이 스스로 관리되는 팀이라는 전제조건이 필요할겁니다. 최적화된 프로세스와 잘 구성된 개발환경, 잘 쌓여온 문화와 관습이 깔려있는 팀은 잘 짜인 스크립트나 정교한 오토마타 기계처럼 별다른 외부의 개입 없이도 원하는 목적을 훌륭하게 수행해냅니다. 스스로 관리되는 팀은 팀에 소속된 사람들이 자신이 해야 할 일이 무엇인지 다른 팀원들과의 충분한 의사소통을 통해 결정할 수 있는 조직을 말합니다. 업무를 수행할 때 포커스를 두는 단위가 하나하나의 단위 업무가 되기 때문에 이런 팀에게 시간적이거나 공간적인 가까움은 크게 중요하지 않게 됩니다.

반대로 업무의 중심이 업무가 아닌 일정이 되어버리면 이야기가 달라집니다. 가끔 어떤 프로젝트는 일을 잘하는 것보다는 일정 내에 맞추는 것이 훨씬 더 중요한 것처럼 보일 때가 있는데, 이는 바꿔 말하면 어떤 업무를 일정 내에 끝내지 못하는 것을 리스크로 상정한다는 말입니다. 특히나 업무 간의 의존성이 강하게 엮일 수밖에 없는 개발 프로젝트의 경우 이러한 리스크는 다른 업무의 지연이라는 연쇄적인 리스크를 불러오기 때문에, 프로젝트를 어떻게든 기간 내에 끝내야 하는 사람의 입장에서는 리스크를 줄이기 위해서 스스로 관리되는 팀을 믿기보다는 강한 권한으로 팀을 관리하기를 원할 수 있습니다. 아무리 사소한 것이라도 관리하고자 하는 습성이 있는 우리는 주로 일을 ‘어떻게든 끝내는’ 것을 미덕으로 삼았고, 잘 안 끝나는 프로젝트를 끝내버린 사람에게 큰 보상이 주어지는 경우가 많았습니다. 물론 일정이 지연되어서 잘 안 풀리던 프로젝트에 새롭게 투입된 관리자는 보통 팀원들의 자율성을 보장하기보다는 강한 권한으로 강제성을 주는 선택을 하는 경우가 많습니다. 그래야 깨진 유리창을 방치할 수 없다고 주장하는 사람들에게 멀쩡한 유리창을 깨서라도 일을 진행시키라고 강제할 수 있으니까요.

그러한 강제성을 위해서는 시간과 공간적인 거리감이 방해가 됩니다. 업무의 분배와 완료는 팀원들에 의해서 이루어지는 것이 아니라 관리자에 의해서 이루어져야 하기 때문에 팀원들은 식량을 배급받듯이 정해진 장소와 정해진 시간에 업무를 분배받아야 합니다. 업무의 완료가 정해진 일정에 이루어지도록 하기 위해서는 직접 얼굴을 보고 푸시하는 쪽이 훨씬 효과가 좋다고 생각하는 사람들은 모든 팀원이 자신이 부르면 3분 내에 달려오기를 원할 수도 있습니다. 이렇게 업무를 ‘밀어넣는(Push)‘의 문화는 각각의 구성원이 자신의 업무를 ‘가져오는(Pull)‘하는 문화와 정면으로 대치되기 때문에 팀의 구성원들이 느슨하게 연결되는 것을 방해합니다.

문제는 이러한 방식으로 너무나 오랫동안 일하게 되면 이런 문화가 일종의 인습처럼 박혀서 일정이 지연되거나, 망하기 직전이거나, 너무나 중요한 프로젝트가 아니더라도 모든 프로젝트와 업무를 시작하기 전에 시간과 공간의 거리감으로 인해 벌어지는 변수를 차단하고자 하려는 버릇이 생길 수 있다는 것입니다. 조금만 중요하다고 생각하는 업무가 생기면 - 그리고 보통 모든 업무는 시작하는 시점에선 다 중요하다고 주장합니다 - TF를 만들고, 회의실을 점유하고, 사람들을 몰아넣고, 출근 시간을 정하는 과정이 필연적으로 따라옵니다.

아마도 어떤 분들은 가깝게 일하는 것에 대해서 부정적으로 묘사하는 것에 거북함을 느끼고 계실지도 모르겠습니다. 그리고 아마 그런 분들은 팀원들에게 더 자율성을 부여하여 근무제도를 더욱더 유연하게 바꾸고 원격으로도 일할 수 있게 바꿔나가는 방향에 대해서도 거부감을 느끼실 것 같습니다. 다른 모든 문화와 마찬가지로 개발 문화도 상대성을 지니기 때문에, 우리 팀, 우리 프로젝트가 가지는 특수성 때문에 팀원들의 자율성을 박탈할 수밖에 없음을 호소하는 분들이 있을 수도 있을 겁니다. 이는 자율성이 절대적으로 지켜져야 할 가치가 아니라 상대적으로 무시될 수 있는 가치임을 내포하고 있을 것이고요.

이러한 가치관의 차이는 어떤 가치가 더 중요하냐에 대한 차이까지 더해져서 어떤 확고한 방향, 그러니까 전체의 기조가 더 자유로운 문화로 나아가야 하느냐 더 통제된 문화로 나아가야 하느냐에 대한 합의가 이루어지기 어렵게 만듭니다. 예를 들어서 주 52시간 미만으로 일해야 한다는 규정은 어떤 사람에게는 개인의 휴식권을 최소한으로는 보장해야 한다는 말로 들리지만 어떤 사람에게는 주 52시간을 넘어가는 근무시간은 모두 예외 시간으로 처리해야 한다는 말로 들립니다. 개인의 가치를 중시 여기는 사람은 후자를 끔찍하게 생각할 것이고, 팀의 가치를 개인보다 우선시하는 사람은 후자가 어쩔 수 없는 선택임을 설득하려고 할 겁니다.

제가 미국에 와서 이쪽 팀과 같이 일을 해보니, 이 사람들은 집에서 일하는 것에도 별다른 거리낌이 없었고 다른 사람들이 오늘 출근을 안 하더라도 불편함을 느끼지 않는 것처럼 보였습니다. 그래서 처음 생각한 것은 끝내주는 개발 환경과 협업 도구들이 있어서 업무가 경계 없이 이루어질 수 있는 것인가 생각했었는데, 별로 특별한 도구들의 특별한 기능들을 사용하지도 않았습니다. 결국 원격으로 일하는 것이 자연스러운 문화는 그 팀원들에게 자율과 책임이 자연스럽게 깔려 있기 때문이라는 결론을 내릴 수밖에 없었습니다. 그러니까 그냥 알아서 잘하는 것이 아닐까 하는 생각을 말입니다.

자율과 책임에 대해

몇 년 전에 넷플릭스에서 작성해서 배포한 문서인 ‘자유와 책임’을 읽어보면, 넷플릭스는 각자의 창의성과 전문성을 확보하기 위하여 가급적이면 관리를 매우 높은 레벨로 추상화하여 최소화시키고, 각자의 자율성과 책임감을 중요한 가치로 내세웠다는 것을 볼 수 있습니다. 그리고 이를 위해서 능력이 있고 가치관을 지키는 직원들에게 높은 임금을 주고, 능력이 없거나 가치관에 동의하지 않는 직원들에게는 높은 퇴직금을 주고 있음을 알 수 있습니다.

당시에 꽤 유명했던 이 문서는 몇 년이 지난 지금은 이미 미국 IT기업들의 일반적인 문화로 자리 잡은 것처럼 보입니다. 물론 모든 회사들의 문화가 비슷할리는 없지만 이쪽 사람들의 이야기를 들어보면 각 회사들의 업무량이나 환경 같은 것은 조금씩 차이가 있더라도 자율성을 보장해주고 책임을 가지게 하는 문화는 큰 차이가 없는 것 처럼 보입니다. 실제로 출근이 필수적이지 않고 출퇴근이 비교적 자유로운 근무제도도 일반적이라고 들었습니다.

자율적으로 업무를 수행할 때 그 도구가 크게 중요하지 않음을 느꼈었는데, 이는 그 도구를 활용하는 방식이 훨씬 더 중요하기 때문입니다. 예를 들어서 같은 Jira를 쓰더라도 어떤 팀은 이를 백로그에 업무를 쌓아두고 팀원들이 스스로 일감을 가져가고 스스로 진척을 관리할 수 있도록 사용하고, 어떤 팀은 대시보드를 만들고 지연된 일감과 그 담당자를 표시하도록 만들기도 합니다. 스탠드업 미팅이 이슈와 진행사항에 대한 간단한 커뮤니케이션 목적이냐, 최소한 언제까지는 출근해야 하는 아침 조회의 의미이냐에 대한 해석의 차이도 존재합니다.

물론 각각의 도구에 대한 최소한의 요구사항은 존재할 수 있습니다. 관리 도구는 업무를 개인에게 할당할 수 있어야 하고, 업무 단위로 의사소통이 가능해야 하며, 다른 개발 도구와 연동될 수 있다면 좋다든지, 화상 회의 시스템은 스크린 캐스팅이 가능해야 하고, 이동 중에 사용할 수 있을 정도로 낮은 대역폭을 사용해야 한다든지, 전자 칠판이 연동되면 좋다든지 하는 등등의 필수적이거나 있으면 좋을 요구사항들이 원격 업무를 더욱더 효율적으로 만들어주고, 이러한 효율성이 일정한 수준 이상이 되면 팀의 모든 구성원들에게 내 옆자리의 동료가 당장 퇴근하거나 내일 출근을 하지 않더라도 아무 상관없도록 만들어줍니다.

제가 일했던 사무실에는 10명 정도가 일하고 있었는데, 보통 6~7명 정도만 출근했습니다. 출근을 하지 않고 집에서 일한다는 사실이 ‘집에서 쉰다’와는 조금 다른 의미인데 여기에서는 재택근무(Work from home)와 휴가(Off)의 의미를 확실히 분리해서 사용하고 있었습니다. 집에서 일하는 것은 위치의 차이만 있을 뿐 사무실에서 일하는 것과 같은 책임을 가지게 됩니다. 오전 10시의 스탠드업 미팅에 참석하고, 회의가 잡히면 회의에도 접속하고, 슬랙에서 누군가가 질문을 하면 답변을 하고, 코딩도 하고 코드 리뷰도 합니다. 반대로 휴가는 이러한 업무에서 완전히 벗어나는 것으로 당연하지만 휴가를 간 사람에게 질문을 하거나 리뷰를 요청하거나 하는 일은 없습니다. 집에서 일하더라도 잠시 자리를 비울 때는 자리를 비울 것이고 언제까지 돌아올 것이다라고 남겨놓는 것을 볼 수 있었는데, 이를 통해 원격지에서의 근무와 사무실에서의 근무에 별다른 차이를 두지 않고 있음을 알 수 있었습니다.

가끔은 스탠드업 미팅 등 팀 전체가 참석하는 회의에 불참하는 사람들도 있습니다. 운전 중이거나, 깜빡했거나, 잠시 다른 일을 하고 있었거나 하는 식인데 이럴 때는 보통 그 사람을 빼고 회의를 진행하고 별로 찾지 않는 경우가 보통이었습니다. 제 개인적인 해석으로는, 집에서 일하거나 사무실에서 일하거나 언제 출근하거나 퇴근하거나 상관하지 않는 문화는 일종의 ‘자율성’에 기반한 문화였다면 꼭 모든 사람이 반드시 무언가를 할 필요는 없는 문화는 ‘책임감’에 기반한 문화가 아닐까 생각했습니다. 회의에 불참하는 것이 무책임한 행동이라고 해석할 수도 있겠지만, 오히려 그 사람이 자기 일은 책임지고 할 것이다 라는 의식이 팀 전반에 공유되어 있다면 굳이 불러서 ‘어디까지 했냐’라든지 ‘이슈는 없냐’라고 물어볼 필요가 없기 때문입니다.

이러한 근무 형태는 기술적으로 비유하자면 비동기화된 업무 처리가 일반적이다라고 할 수 있습니다. 예를 들어서 회식 메뉴를 정하고자 했을 때, 모든 사람을 불러놓고 한 명 한 명에게 무엇이 먹고 싶냐고 물어보고 그 대답을 바로 기록해서 취합한 뒤 결정하는 것이 동기화된 업무 처리라면, 회식 메뉴를 건의해달라고 공지하고 일정 시간이 지난 뒤 돌아온 답들을 취합해서 메뉴를 결정한다면 비동기화된 업무 처리라고 생각할 수 있는데 전반적으로 개인의 결정권과 자유를 중시하는 이쪽의 문화는 후자에 훨씬 가까운 느낌이 들었습니다. 업무가 누군가에게 강한 의존성을 가지게 만들지도 않았고, 모든 사람이 의사 결정에 참여할 필요도 없었습니다. 아시겠지만 컴포넌트 간의 연결이 비동기적으로 이루어질 경우 각각의 컴포넌트들이 자신의 역할을 수행하면서 블록이 걸리지 않기 때문에 전반적으로 성능이 높아지는 효과가 꽤 극적으로 나타나는데, 이렇게 본인의 업무에 책임감을 가지고 집중할 수 있게 만들어주는 것이 ‘그렇게 마음대로 일해도 업무가 제대로 돌아가?‘에 대해 그래도 잘 돌아간다라고 답할 수 있는 근거가 되지 않을까 생각했습니다.

팀을 위해 일하는 것과 팀으로 일하는 것

누가 저에게 ‘미국은 어떻게 일하냐’라고 물어본다면 엔지니어적인 관점에서 Slack, GitHub, Jira, Confluence, Zoom 등을 이야기할 수 있을 것이고, 이를 통해 ‘우리랑 별로 다르지 않다’라는 결론을 이끌어낼 수도 있습니다. 실제로 처음에 느낀 것들은 업무 방식이나 프로세스가 한국 개발팀이나 미국 개발팀이나 크게 다르지 않다는 사실이었습니다. 하지만 몇 주 정도 지나고 나서 생각보다 많은 부분에서 다른 점을 찾을 수 있었습니다. 그리고 이 다른 점들은 대부분 개개인의 차이가 아닌 팀이 합의하고 공유하는 의식의 차이였기 때문에 미국 사람들이 한국 문화에, 한국 사람들이 미국 문화에 적응하는 것은 모두 쉽지 않겠구나 하는 생각도 들었습니다. 즉, 팀을 위해 일하는 것과 팀으로 일하는 것 사이에는 쉽게 건너기 어려운 간격이 존재하는 것처럼 보였습니다.

하지만 보통 창의성은 강요에서 나오기 어렵기 때문에 점점 더 높은 수준의 창의성이 필요한 개발 결과물을 요구하는 지금의 흐름에서, 팀을 위해서 기계적으로 일하는 것이 오랫동안 미덕으로 남기는 어려울 것입니다. 물론 팀을 위해 일하지 말아야 한다는 말이 협업을 거부하자는 말로 이어지는 것은 아닙니다. 오히려 협업을 위한 문화와 방법론, 제도, 프로세스, 도구는 계속 발전했습니다. 이러한 환경의 발전을 올바른 방향으로 활용할 수 있다면 하나의 제품이나 어떤 문제 해결을 위해서 구성원들이 팀으로 일하는 이상적인 모습을 볼 수 있을 겁니다. 물론 이상향이라는 것은 언제나 도달하기 어려운 것이고 풀어야 할 숙제가 굉장히 많지만, ‘개인’에 대한 강조가 어떻게 ‘팀’으로 이어질 수 있는지에 대해 깊이 고민하는 것도 그 숙제를 풀어나가는 과정 중 하나가 아닐까 생각합니다.