우분투(Ubuntu)를 아는가?
아마도 리눅스 운영체제 배포판이 제일 먼저 떠오를 텐데 지금 말하고 싶은 것은 운영체제가 아니라 이 우분투의 뜻이다. 우분투는 아프리카에서 가장 널리 쓰이는 말 중 하나인 반투어에서 유래된 말인데, 그 의미가 참 좋다.
"우분투! 당신이 있으니 제가 있습니다"
'당신이 있으니 제가 있습니다!'라는 뜻을 가진 우분투를 조금 더 들여다보면, 보다 다양한 의미를 만나게 된다. 우분투는 인간은 혼자서는 살아갈 수 없는 존재라는 것을 강조하거나, 마음을 열고 다른 사람을 기꺼이 도우며 다른 사람의 생각을 인정할 줄 아는 정신을 추구한다.
개발자도 이 우분투 정신이 필요하다. 동료를 믿고 의지하고 인정할 때 우리는 건강하게 성장할 수 있다.
개발은 거의 대부분이 팀플레이다. 작은 팀 안에서도 동료와 협업하며 사회생활을 하게 된다. 그러다 보면 실수하거나 사고 치면 안 될 것 같다는 생각에, 가만히 있으면 중간이라도 간다는 생각에, 괜히 긁어 부스럼 만들지 말자는 생각에, 새로운 시도를 하거나 문제를 해결하거나 용기 내어 의견 내는 것을 하지 않을 때가 있다.
나도 그랬다. 그래서 움츠려들고 묻어두려는 그 심리가 이해가 가지만 성장의 관점에서는 고쳐야 할 자세다. 우리는 동료를 믿고 의지해야 한다. 어쩌면 내 동료는 나의 도전을 응원해 줄지도 모른다. 내가 당면한 문제를 해결하는 데 도움을 줄지도 모른다. 용기 내어 말한 의견을 매우 고마워할지도 모른다. 모른다고 말했을 때 아무렇지 않게 친절히 알려줄지도 모른다. 물론 아주 간혹 빌런스러운 동료를 만나기도 하지만... 그런 빌런이 싫어서 말을 아끼고 있기엔 훌륭한 동료들이 곳곳에 많이 있다.
의견을 내는 것에 주저하지 말자. 사람은 누구나 유한하다. 동료가 보지 못하고 있는 것을 내가 보고 있을 수 있다. 그 반대의 경우도 마찬가지다. 그러므로 문제를 발견했을 때, 혹은 더 좋은 아이디어가 있을 때, 우리는 동료를 믿고 용기 내어 말하자. 동료의 마음을 상하지 않게 하는 젠틀한 표현으로 말이다. 그리고 행여 내 의견이 반영되지 않는다 할지라도, 그것이 나의 정체성을 부정하는 것은 아님을 기억하자. 중요한 것은 의견을 주고받는 과정을 통해 더 나은 선택을 할 수 있게 된다는 점이고, 생각지도 못했던 부분까지 시야가 확장된다는 점이며, 우리가 함께 성장할 수 있다는 점이다.
의견 내는 것을 장려하고 환영하는 분위기가 되어야 대화를 통해 더 좋은 방향과 더 좋은 방법을 모색할 수 있고, 그 속에서 함께 성장할 수 있다. 그러므로 누군가 나에게 다른 의견을 낸다면, 그것은 나에게 태클을 거는 것이 아니라, 내가 보지 못하고 있는 부분을 볼 수 있도록 도와주는 것이다. (물론 태클 빌런은 조심해야 한다.) 인간은 유한하기에 서로가 서로를 필요로 한다. 누군가 용기 내어 나에게 의견을 냈는데 내가 방어적이거나 공격적으로 반응한다면, 상대는 더 이상 나에게 의견을 내지 않을 것이고 그렇게 성장판 하나가 닫히게 될 것이다. 성장은 글이나 영상이나 삽질을 통해서만 얻어지는 것이 아니다.
만약 의견을 내는 사람도 의견을 받는 사람도 편하게 자신의 의견을 젠틀하게 주고받고 있다면 이는 성장하기에 매우 좋은 팀 문화를 향유하고 있는 것이다.
개발자가 대화 중에 잘 모르는 내용을 들었을 때, 특히 대화 상대가 나보다 연차나 직급이 낮은 사람이라면, 모르는 내용임에도 이미 알고 있었던 것 마냥 고개를 끄덕이며 대충 지나가기도 한다. 회의 중에 동료 개발자가 내 주장이 잘못됐다고 의견을 냈는데 듣고 보니 그 말이 맞는 것 같은데도 내가 틀리지 않았다고 온갖 논리를 끌어와서 맞받아치기도 한다.
아마도 나에게 실망하거나 나를 무시할까봐 모르는 것을 모른다고 말 못 하고 나보다 나은 의견을 인정하지 못하는 걸 거다. 쪽팔리고 싶지 않거나 지고 싶지 않아서 그런 걸 수도 있겠다. 나도 그랬던 순간들이 있었다. 하지만 이후로 이런 부분을 고치기 위해 용기 내어 모르는 부분은 모른다고 말하고 더 나은 의견을 순수히 인정했을 때, 동료가 이것도 몰랐냐는 듯이 나에게 실망하거나 나를 깔보는 것을 본 적이 없다. 오히려 모른다고 하면 더 자세히 설명해 줬고, 동료의 의견을 인정했을 땐 순탄하게 다음 대화로 넘어갈 수 있었다. 나만의 특별한 경험이었을까? 그렇지 않다고 본다. 이 바닥에는 좋은 사람들이 많이 있다. 행여 나의 부족함으로 나를 무시하는 일이 있을 수 있다고 할지라도, 그게 두려워서 애써 나를 감추거나 고집을 부리는 것이 더 손해다.
모르는 것을 아는 척하며 넘어갈 때의 문제점은, 동료들이 내가 안다고 생각하고는 거기에 맞춰서 일정을 짜거나 얘기를 이어가게 된다. 몰랐던 것은 빨리 공부하면 해결될 문제 아니냐고 생각할 수도 있지만, 이따금 나비효과가 되어 문제가 커지기도 한다. 일이 커진 뒤에, 실제로는 내가 몰랐다는 것을 동료들이 알게 됐을 때의 그 부끄러움은 복리로 쌓인 부끄러움일 것이다. 그로 인한 피해를 팀이 입었다면 말할 것도 없고 말이다.
동료의 더 나은 의견을 인정하지 않고 내 의견을 고집할 때의 문제점은, 동료들이 더 이상 나와 대화하고 싶어 하지 않는다. 자기 고집이 너무 강한 사람으로 이미지가 박혔기 때문이다. 당장은 내 앞에서는 내 의견에 동의하는 것처럼 말하겠지만 속 마음은 그렇지 않다. 단지 충돌을 피하고 싶어서 동의하는 척하는 것이다. 그렇게 점점 고립되어 동료로부터 좋은 의견을 얻기란 요원해진다.
그러니 동료의 선한 마음을 믿고, 모르는 것은 모른다고, 동료의 의견이 더 좋다고 인정할 것은 인정하자. 동료 또한 언젠가 나와 비슷한 입장이 됐을 때, 그때 나도 동료의 나를 향한 믿음에 부응하면 되니까 말이다.
동료를 배려하는 마음은 함께 일하고 싶은 개발자로 성장하는데 큰 도움을 준다고 생각한다. 나 혼자 신나게 개발하면서 말도 없이 이 기술 저 기술 썼다가, 나만 아는 기술 스택에서 문제가 터져서 팀 전체가 고생을 했다면 과연 동료를 배려하는 개발자라고 할 수 있을까? 열심히 하는 것은 좋은데 나 혼자 야근하면서 공유 없이 이런저런 변경 작업을 하다가 실 서비스에 장애를 일으켜서 꿀 같은 저녁 시간을 보내던 동료들이 갑자기 소환되는 일을 만들었다면 동료를 배려하는 개발자라고 할 수 있을까? 파일 체인지 수가 스무 개, 서른 개를 넘어가고 라인 체인지 수가 수 천 개를 넘어가는 어마어마한 양의 PR(pull request)을 짧은 몇 줄의 글과 함께 퇴근 직전에 주면서 내일까지 리뷰 해달라고 요청하는 것, 이게 정말 최선일까? 동료가 특히 주니어 동료가 기술적으로 잘 못 따라오는 게 보이는데도 무언가에 홀린 듯 뽕에 취해 어려운 전문 용어를 써가며 쏟아내듯 얘기하고 있다면, 동료를 배려하며 말하고 있다고 할 수 있을까?
반대로 생각해 보자. 새로운 기술을 쓰고 싶을 때 동료의 의견을 먼저 묻고 팀 내에서 함께 결정한 후 진행을 한다면, 팀은 같은 선상에서 혼란 없이 새로운 기술을 소화할 수 있을 것이다. 문제가 생겨도 대응할 수 있는 사람이 여럿이니 위기관리에도 좋다. 변경 작업을 해야 하는 경우에 팀에 미리 공유를 한 후 진행을 하거나 아니면 팀 내에서 일정을 조정하여 다음날로 미루든지 해야 한다. 변경 작업에 대한 인지를 팀원이 모두 하고 있기 때문에 문제가 생길 여지도, 문제가 생겨도 당황하지 않고 신속하게 대응할 수 있다. PR의 양이 너무 많으면 리뷰하는 사람도 부담스럽다. 꼼꼼히 봐주기도 어려워 리뷰의 의미가 퇴색될 수도 있다. 보다 작은 단위로 쪼개서 만들고 리뷰어가 잘 리뷰할 수 있게끔 충분한 설명과 시간을 준다면, 리뷰어도 본인의 일정 안에서 유연하고 보다 더 꼼꼼하게 봐줄 수 있다. 동료가 못 따라오는 것 같을 때 서두르지 않고 차근차근 설명해 간다면, 동료의 지식도 늘어나고 무엇보다도 팀이 나를 혼자 두고 가지 않는다는 전우애적(?) 소속감으로 인해 훨씬 좋은 시너지 효과를 낼 수 있다.
배려한다는 것은 동료를 위하는 마음이다. '어떻게 하면 조금 더 내 동료를 편안하게 해줄까?' 이 고민을 해보자. 처음엔 낯설 수도 귀찮을 수도 번거로울 수도 있지만, 그렇게 했을 때 팀 내부적으로 케미가 좋아지고 더 즐겁게 성장할 수 있다.
첫 직장에서 내가 4년 반 가까이 다닐 수 있었던 것은 사수님의 영향이 컸다. 특히 초반에 열등감에 찌들어 힘든 시절을 보내고 있을 때, 만약 성격이 거칠거나 강하게 푸시하는 사수님을 만났다면, 아마 나는 버티지 못하고 그만뒀을 것이다. 그 당시 사수님은 매우 격무에 시달리고 계셔서 일과 중에는 각종 문의 대응과 회의 참석에 거의 모든 시간을 사용하셨고, 다들 퇴근한 후에야 비로소 개발을 시작하실 정도였다. 매일 12시 퇴근이었다. 그런 상황에서 아무것도 모르는 햇병아리까지 챙기셔야 하니 스트레스가 이만저만이 아니셨을 텐데 바쁜 중에도 짬을 내주셔서 아주 쉬운 기능부터 차근차근 개발할 수 있도록 가이드해 주셨다. 내가 처리해야 할 티켓에 뭘 확인해야 하는지 친절히 써주셨고 오프라인으로도 다시 잘 설명해 주셨다. 어느 정도 궤도에 오르자 조금 더 난이도 있는 기능 개발도 주셨고, 나중에는 큰 프로젝트도 믿고 맡겨주셨다. (물론 사수님은 그때 할 사람이 없어서 나에게 맡겼다고 하시지만ㅎㅎ 그때 기회를 주셔서 나의 성장과 경력에 큰 도움이 됐다.)
그때 그렇게 배려해 주신 그 기억이 참 좋아서 나도 누군가를 케어해야 하는 위치가 되면 처음엔 작은 기능부터 시작해서 나중엔 보다 큰 과제로 도전할 수 있는 기회를 만들어 드려야겠다고 생각했다. 내가 입사하고 딱 1년 뒤에 신입 한 분이 들어오셨고 난 그분의 사수가 됐다. 그분은 성격이 참 좋았고 분위기 메이커였다. 새로운 것을 잘 수용하고, 변화를 두려워하지 않고 도전하는 모습에 귀감이 많이 되는 분이었다. 나는 고작 2년차 였지만 1년 동안 고생하면서 느낀 여러 것들이 있어서 나보다는 덜 힘들게 적응할 수 있길 바라는 마음으로 이런저런 조언들과 대화를 많이 했던 것 같다.
우리 셋은 매우 친해졌다. 모두 미혼이었고, 개그 코드도 비슷했고, 다 같이 늘 야근하면서 전우애가 생겼다. 우리는 성격이 다들 조금씩 달랐지만, 각자가 각자의 위치에서 최선을 다하며 서로 배려하고 챙기며 지냈다. 어느 날 전체 회식 자리에서 우리는 한 테이블에 앉아 돼지고기를 구워 먹다가 삼국지처럼 도원결의(?)를 했다. 누군가 한 명이 나가더라도 그 사람을 응원해 주자고. 그러면서 자연스럽게 사수님이 유비, 내가 관우, 신입 분이 장비가 됐다. 내가 있는 팀은 계속해서 격무 부서였다. 한동안 인원 충원 없이 세 명이서 쏟아지는 티켓들을 쳐내던 시절도 있었다. 매일매일이 야근이었지만 서로 잘 맞으니까 일이 힘들어도 그렇게 힘들다고 느껴지지가 않았다.
우리 세 사람은 지금도 연락하며 지낸다. 함께 한다는 것. 좋은 사람들과 서로 돕고 챙겨가며 성장한다는 것. 이분들과의 같이 일하고 동고동락하면서 얻은 매우 소중한 경험이다. 결국 개발자도 사람이다. 서로가 서로를 필요로 하는 사람 말이다.
널리 알려진, 처음 출처는 어딘지는 알 수 없는 이야기를 공유하며 이 글을 그리고 '개발자로 성장하기' 시리즈를 마치고자 한다.
아프리카 부족에 대해 연구 중이던 어느 인류학자가 한 부족 아이들을 모아놓고 게임 하나를 제안했습니다.
나무 옆에 싱싱하고 달콤한 아프리카에선 보기 드문 딸기가 가득 찬 바구니를 놓고 누구든 먼저 바구니까지 뛰어간 아이에게 과일을 모두 주겠노라 한 것이지요.
인류학자의 말이 통역되어 아이들에게 전달되자마자 그 아이들은 마치 미리 약속이라도 한 듯 서로의 손을 잡았습니다. 그리고 손에 손을 잡은 채 함께 달리기 시작했습니다.
아이들은 바구니에 다다르자 모두 함께 둘러앉아 입안 가득 과일을 베어 물고 키득거리며 재미나게 나누어 먹었습니다.
인류학자는 아이들에게
"누구든 일등으로 간 사람에게 모든 과일을 주려 했는데 왜 손을 잡고 같이 달렸니?"
라고 묻자 아이들의 입에선
"우분투!"
라는 단어가 합창하듯 쏟아졌습니다.
그리고 한 아이가 이렇게 덧붙였습니다.
"나머지 다른 아이들이 다 슬픈데 어떻게 나만 기분 좋을 수 있는 거죠?"
