brunch

매거진 인문학도 개발자되다

라이킷 177 댓글 7

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 마르코 Apr 23. 2019

나는 왜 회사를 즐겁게 다니고 있나?

평생 한 회사만 다녀야 한다면 이 회사를 택하리

싱가폴에서 데이터 엔지니어로 미국계 회사에서 일하면서 인생에서 가장 만족스럽게 회사를 다니고 있다. 평생 동안 단 한 회사에만 다녀야 된다고 하면 단연코 지금 회사를 고르겠다고 말할 수 있을 정도로, 이렇게 회사 생활이 만족스러울 수 있다고 상상도 해 본 적이 없다. 나는 머릿속이 복잡하고 삶의 방향이 분명하지 않을 때 자주 글을 쓰게 되는데, 싱가폴에서의 회사 생활과 일상생활의 만족도가 너무 높다 보니 글을 잘 안 쓰게 돼서 걱정이 될 정도다. 왜 대문호들이 어려운 환경 속에서 그런 대작을 써 내려갔는지 조금이나마 이해할 수 있을 거 같다. 한국에서는 그토록 회사 생활이 고통스러웠는데, 왜 싱가폴에서는 회사를 다니는 게 힘들지 않은지 한 번 생각해보기로 했다. 이 과정을 통해서 조금 더 나를 이해하는 시간이 되기를 기대하며.

개발팀장은 관리하지 않는다

매니저와 팀장은 다르다

지금 회사에서 개발자로 일하면서 가장 신기했던 부분은 매니저와 개발팀장이 동일한 사람이 아니라는 점이었다. 보통 팀장이 매니저의 역할을 동시에 수행하는 것이 내 경험에 비추어봤을 때 일반적인데, 이번에는 달랐다. 매니저는 프로젝트의 방향과 우선순위를 정하고 팀원들의 인사고과 기준을 논의하고 평가한다. 반면 팀장은 평가하지 않고, 개발 프로젝트가 제대로 진행될 수 있도록 개발만 책임지고 팀원들이 만들어내는 코드의 최종 수문장 같은 역할을 한다. 이렇게 매니저와 팀장이 분리되었을 때 장점은 팀원에 대한 객관적인 평가가 가능하다는 것이다.

사람들은 자신이 다른 사람을 ‘객관적’으로 평가할 수 있다고 생각하는데, 대게 자신이 높게 평가하는 가치를 가진 사람을 높게 평가하게 마련이다. 예를 들어, 일중독인 팀장이 있다고 가정해보자. 이 사람이 평가권을 가지게 된다면 팀원들에게 다 함께 장기간의 노동시간을 강요하게 될 가능성이 많다. 하지만 평가권을 팀장이 아닌 매니저가 가지게 된다면, 팀장으로부터 팀원의 업무 결과에 대해 이야기는 듣되 다른 팀원들의 이야기도 함께 들을 수 있는 기회가 생긴다. 그리고 팀장도 팀원을 ‘관리’하는 업무에서 벗어나 본인의 핵심 업무인 개발에만 집중할 수 있다. 다만 팀장은 개인의 업무 시간 대부분을 코딩에 할애하는 것이 아니라, 다른 팀원들이 제대로 일할 수 있도록 최종 리뷰를 하거나 문제 상황을 해결해주는 역할을 한다. 조금만 생각해보면 업무 능력과 팀을 이끄는 능력은 전혀 다른 능력이라는 사실을 깨달을 수 있다.

업무 계획, 이 작업은 얼마나 시간이 걸릴까?

보통 회사에서 업무 계획은 상명하복의 형태로 진행이 된다. 경영진이 마감일을 정하고 그걸 개발팀이 따르게 되는 것이 일반적이다. "이 업무는 이 정도 시간이면 충분하지 않아?"라는 명대사를 날리며 개발자들 뒷목을 잡게 만든다. 그런데 경영진이 업무에 필요한 시간을 제대로 예측할 수 있나? 실제 업무를 하는 개발자들도 정확한 소요 시간을 예측하는데 종종 실패하는 마당에 이렇게 내려온 마감기간이 제대로 지켜질 리가 없다. 지킬 수 없는 마감기간을 따르느라 개발자들은 죽어가고, 경영진은 지켜지지 않는 마감에 매번 빡치고, 회사는 불확실성의 소용돌이로 빠져든다.

이곳에서는 개발자가 업무의 예상 소요시간을 정한다. 물론 팀 전체가 각 업무의 예상 소요시간을 함께 예측하는 과정을 통해서 객관성을 더한다. 경영진은 전체적인 프로젝트 전체의 시간 계획을 세우고, 프로젝트 진행 과정에서 시간이 부족할 경우 우선순위를 정해서 덜 중요한 기능을 다음 마감 기한으로 넘긴다. 이렇게 일해도 마감기한 전에는 바쁜 것이 사실이지만, 불가능한 마감기한을 먼저 정해놓고 일을 하라고 재촉하지 않는다. 이 과정을 통해서 ‘제대로 돌아가는 제품’을 만들어 낸다.

마감기한뿐만 아니라 기능의 세부 구현도 개발자들이 모여서 정한다. 물론 PM 역할을 하는 매니저와 디자이너가 시안을 먼저 작업하지만, 개발자들이 반론을 제기할 경우 기능은 언제든지 바뀌고 더 나은 방향으로 개선된다. 매니저는 개발자들의 제안이 자신의 일을 미루기 위한 것이 아니라 더 나은 제품을 만들기 위한 것임을 믿는다.

우리는 모두 5년 차 이상 개발자

단순히 싸다는 이유로 신입 개발자를 뽑지 않는다. 대신 자신의 전문성을 가진 사람들을 뽑아서, 믿고 맡긴다. 자신의 업무뿐만 아니라 삶을 책임질 수 있는 ‘어른’을 뽑는다. 이렇게 각자의 전문성을 가진 사람들이기 때문에, 함께 일하는 것만으로도 어깨너머로 다른 사람들의 전문 지식을 쉽게 배울 수 있다.

그리고 개발이라는 분야에서 새로운 기술은 매년 쏟아져 나온다. 그러면 새롭게 학습해야 하는 기술들이 있는데 이런 기술들은 함께 학습한다. 다들 자기 전문 분야가 있는 사람들이라 새로운 기술이 나와도 워낙 금방 배운다. 같은 카테고리 내에 비슷한 기술들을 조사해서, 팀을 나눠서 각각 벤치마크를 하고 회사의 제품에 사용하기에 가장 적합한 기술을 선택한다. 이 과정에서 각 기술의 코드와 특이점을 나누기 때문에 동일한 시간 대비 몇 배의 학습 효과를 누릴 수 있다.

평가 기준이 명확하다

개인의 업무 평가는 매니저가 자기 기분대로 정할 수 없다. 우선 매 사이클마다 매니저와 팀원 개개인이 그 기간 동안 진행할 목표를 정한다. 이 목표는 가급적이면 회사와 직간접적으로 관련된 것을 정한다. 하지만 꼭 회사 일과 관련이 있지 않더라도, 관심 분야의 기술 갈고닦는 기회로 사용할 수 있다. 그리고 세부적인 실천 계획이나 목표가 이뤄졌는지 알 수 있는 수치를 정한다.

그리고 그 기간이 지나면 같은 테이블에 앉아서 목표가 기간 동안 어떻게 달성되었는지 함께 확인한다. 모든 평가는 이 목표 대비 달성량을 바탕으로 정해진다. 그런데 만약 특정 항목의 평가 결과가 마음에 들지 않는다면 어떻게 할까? 매니저한테 이의를 제기한다. 물론 당연히 밑도 끝도 없이 "저는 이거 못 받아들이겠는데요."라고 하는 것이 아니라, 목표를 달성하지 못했다면 그에 대한 합리적인 이유를 제시하고 결과를 조정한다. 이를 통해서 모든 사람이 납득할 수 있는 평가를 만든다.

이렇게 목표를 정하고 그 결과를 측정하면, "열정이 부족”하다거나 "회사에 충성심"이 부족하다는 헛소리를 할 가능성은 현저히 줄어든다. 덕분에 회사에서 원하는 것에 집중할 수 있었고 작년 연말 인사고과에서 최고점을 받을 수 있었다.

당신의 작업물은 당신의 소유가 아니다

제품에 반영된 코드는 더 이상 당신의 책임이 아니다

우리는 팀으로 일한다. 팀이란 무엇인가? 같은 목표를 향해서 함께 나아간다는 뜻이다. 개발자는 업무 특성상 개발자 개개인이 코드를 짜게 되지만, 그 작성된 코드의 리뷰는 팀 전체가 한다. 그렇다면 코드 리뷰라는 것은 무엇인가? 그냥 다른 사람이 짠 코드를 훑어보고 ‘잘 돌아가겠네’라고 생각하는 것이 아니다. 코드 리뷰란 실제로 코드가 돌아가는지 개인의 컴퓨터에서 그 기능을 직접 테스트하고, 코드 각각의 라인이 무엇을 의미하는지 충분히 이해하고 그 코드를 팀 차원에서 승인하는 것을 말한다. 최소한 코드가 실제 제품에 반영되려면 2명 이상의 인원이 승인을 해야 하는데, 5인 팀이라면 팀의 과반수가 그 코드에 대해서 이해하게 된다는 의미다. 이렇게 일하면 누구도 휴가를 떠나거나 몸이 아플 때 회사 걱정을 하지 않아도 된다. 회사에서 일하다 보면 갑자기 팀원이 아프거나, 휴가 전에 기능 개발을 마무리하지 못하는 경우가 있는데, 다들 너무나도 쉽게 인수인계를 받는다. 팀원이 무엇을 하고 있는지 다 알고, 그 기능의 배경을 이해하고 있기 때문이다. 이렇게 내가 아프거나 휴가 받을 때도 배려받는다.

코드에 대한 피드백은 개인의 인격에 대한 평가가 아니다

대신 피드백은 짧고 간결하다. 상대방을 공격하지는 않지만 그렇다고 에둘러 표현하지 않는다. 잘못된 부분에 대해서 명확하게 이야기하고, 코드가 제품에 반영되는 걸 숱하게 승인 거절한다. 처음에는 수많은 피드백을 받는 것이 마음이 썩 편하지 않았는데, 이제는 거의 다른 사람이 작성한 모든 코드에 변경사항을 찾아서 승인 거절을 할 수 있게 되었다.

이게 가능한 이유는 개인이 만들어낸 결과물과 그에 대한 피드백이 그 사람을 향하고 있지 않다는 것을 알고 있기 때문이다. 우리는 팀으로 일한다. 팀으로 일하기 때문에 다른 동료가 만들어낸 결과물은 그 사람만의 것이 아니다. 우리 모두가 책임져야 하는 결과물이기 때문에 더 나은 제품을 위해서 간결하고 직설적으로 피드백을 남긴다. 물론 모든 피드백을 동의할 필요가 있는 건 아니라서, 필요에 따라서 관계자들의 논의를 거쳐서 최종 코드가 결정된다.

업무를 개인에게 분배하는 것이 아니라 팀에게 분배한다

팀은 매 업무 사이클에 앞서 그 기간 동안 해야 할 일을 정한다. 하지만 이 업무는 개인에게 할당되는 것이 아니라 팀에게 할당된다. 업무는 우선 순서에 따라서 배치되고, 한 업무를 끝낸 사람은 그다음 업무를 가져간다. 이러면 한국 사람들은 이렇게 묻는다. "그러면 일을 적게 가져가는 사람들이 있으니 불공평하지 않나?" 이런 생각이 먼저 떠오른다면, 당신은 팀으로 일하고 있는 것이 아닐지도 모른다. 위에서도 언급했지만, 개발자에게 중요한 것은 자신의 코드를 작성하는 것뿐만 아니라 다른 사람의 코드를 리뷰하는 것이다. 그런데 업무가 개개인에게 배분되면 사람들은 자신의 업무를 끝내는 것에만 집중하게 된다. 다른 사람의 코드를 리뷰하거나 다른 사람과 함께하는 짝 코딩 등은 개인에게 할당된 업무에 가려 잊히게 된다.

업무가 팀에게 분배되면 팀은 자연스레 팀으로서 주어진 업무를 수행하는데 집중한다. 문제가 생겨 좀처럼 업무가 진행이 되지 않고 있는 동료가 있으면 누가 시키지 않아도 그 동료를 돕는다. 왜냐면 팀으로 일하고, 팀이 주어진 기간 동안 업무를 끝내는 것이 중요하기 때문이다. 무임승차자가 생길 거라고 크게 고민할 필요 없다. 팀원들은 누가 일을 하고, 누가 누구를 돕고 있는지 누구보다 더 잘 알고 있다. 평가 기간에 각자는 합당한 평가를 가져가게 될 것이다.

사람이 중요하다

당신이 오래 다녔으면 좋겠다

이 회사에서 가장 높은 상사와 이야기하면서 정말 감동을 받았던 적이 있다. 그는 이렇게 말했다. "개인의 삶이 안정되지 못하면 회사에서 제대로 일하기 힘들다. 우리는 직원들이 자신의 일에만 집중할 수 있도록, 그 외에 많은 문제들을 해결하는 일을 하고 있다. 언제든지 어려움이 있으면 찾아와서 이야기해주면, 같이 해결할 수 있는 방법을 찾아보도록 하자."

정말 회사에서 듣기 힘든 말이 아닌가? 싱가폴에서 개발자는 1~3년 정도마다 이직을 한다. 1년 정도만 다녀도 이직할 때 흠이 안되고, 3년 정도 다니면 이제는 옮겨야 할 때라고 생각하는 것 같다. 그 이상 다니면 실력이 없어서 못 옮기는 사람 취급을 받기도 쉽고. 그런데 지금 회사에는 3~7년을 다닌 사람들이 제법 많다. 이곳에서는 충성심을 강요하거나, 오래 다녀달라고 구걸하지 않는다. 대신 사람들이 머물고 싶은 문화를 만든다. 매니저는 자신의 가장 중요한 업무가 "사람들이 일하고 싶게 만드는 지금의 문화를 지키고 발전시키는 것"이라고 말한다.

아픈 사람은 쉬어야 한다

한국에서는 아프면 연차를 쓴다. 그나마도 눈치를 써야 한다. 여기서는 병가를 쓴다. 연차와는 별개다. 회사마다 다르긴 하지만, 지금 회사에서는 진단서도 제출할 필요가 없다. 그냥 아침에 메신저에 "나 오늘 아파서 회사에 못가"라고 한 줄 적으면 끝이다. 아무도 확인하려 들지 않는다.

아픈 사람이 회사에 나오는 것만큼 미련한 것이 없다. 아픈 사람의 업무 생산성이 기대에 못 미칠 것도 너무 뻔하고, 병원균을 옮겨 회사 전체를 병원으로 만든다. 하루 이틀 바짝 쉬면 나을 걸 굳이 회사에 나와서 일주일 씩 보름 씩 병을 키운다. 요즘은 집에서 키우는 강아지나 고양이가 아파도 병원에 입원시키지 않나?

다양한 경험을 할 수 있는 기회를 제공한다

이 회사에 데이터 엔지니어로 입사했다. 이전까지 데이터 엔지니어링 업무 경험이 하나도 없었는데, 관련 경험을 바탕으로 일을 시작할 수 있었다. 그리고 배경지식이 없는 사람이 적응할 수 있도록 시간적, 정신적인 배려도 잊지 않았다. 팀 차원에서 관련 경험이 부족한 사람이 들어오면, 이 사람이 짧은 기간에 최대한 효과적으로 팀의 제품에 적응할 수 있는 업무를 미리 준비한다. 그리고 필요하다면 짝 코딩을 하는 것도 있지 않는다.

새로운 프로젝트를 시작하게 되면서, 하나의 제품 전체를 아우를 수 있는 시야를 가지면 좋겠다고 생각했다. 그래서 매니저와 상의했고, 그러한 기회를 얻을 수 있도록 최대한 배려하겠다는 약속을 받았다. 하고 싶은 게 없는 게 문제지, 자기가 하고 싶은 게 있다면 그걸 할 때 제일 신나게 할 수 있지 않냐고 답했다. 그 과정을 통해서 데이터 엔지니어링 업무뿐만 아니라, 실제 고객과 접하는 제품 쪽의 웹 개발과 서비스 전체를 관리하는 DevOps 쪽 기술도 배울 수 있게 되었다.

1년 정도 지금 회사를 다녔는데, 그 전의 어떤 기간보다도 빠르게 성장했다고 느낀다. 6년 차에 접어드는 개발자 생활 중에 어느 정도 궤도에 오른 이후에 이렇게 많은 것을 배우고 있다고 느낄 수 있는 건 정말 감사한 일이다.

더 나은 회사는 있다

한국에서는 흔히들 말한다. 다른 곳으로 옮겨도 비슷하다고. 그런데 정말 그런가? 지금껏 제법 많은 회사를 다녔는데, 항상 더 나은 회사는 있었다.

한국은 참 사업하기 좋은 나라라고 생각한다. 국민 대부분이 고학력에 똑똑하고 근면하다. 매니저와 신입 연봉이 5~6배씩 차이나는 이곳과 비교하면, 한국은 어느 포지션을 보더라도 어지간한 시니어와 주니어와 크게 연봉 차이가 나지 않는다. 숙련된 노동자를 비교적 저렴하게 고용할 수 있다는 말이다. 제법 강한 노동법을 가지고 있지만, 노동법에 대한 교육이 제대로 이뤄지지 않아서 적당히 겁을 주면 알아서 퇴사한다. 다른 나라와 시장이 비교적 작을 수는 있겠으나, 비교적 손쉽게 싼 맛에 양질의 노동력을 구할 수 있으니 얼마나 좋은가.

하지만 노동자에게 좋은 나라인지는 잘 모르겠다. 어째서 한국에서 태어나서, 한국에서 교육을 받고, 한국에서 회사 생활을 한다는 이유 만으로 수많은 불합리한 일을 감내해야 하는지 나는 잘 모르겠다.

외국에서 회사 생활하는 것이 정답이라는 이야기는 아니다. 회사 문화는 개인 선호의 문제이기도 하다. 그리고 외국에도 이상한 회사와 이상한 상사는 존재한다. 다만 비율과 확률의 문제일 따름이다. 부디 "다른 곳도 다 비슷할 테니까"를 주문처럼 외우며 버티는 삶에서 지인들이 더 많이 벗어날 수 있기를 기원한다.

keyword