다시 개발자로 돌아가기

팀을 이끌어야하는 역할을 명시적으로 부여 받았을때 실무의 비중을 얼마나 두어야할까? 과연 실무를 내려놓고 개발자가 매니징만 할 수 있을까? 한동안 답을 찾지 못했다. 선배들에게 조언을 구하면 늘 그 자리는 코드의 욕심을 내려놓아야한다는 이야기를 주로 들었다. 하지만 난 그때 실무를 내려놓지 못했다. 누군가를 믿지 못해서가 아니다. 실무는 내게 수많은 맥락을 제공한다. 그리고 그 맥락을 놓치면 나는 그 어떤 의사결정도 제대로 못할 것만 같은 두려움이 있었다.

그래서 실무를 모두 내려놓은 매니저의 삶도 살아봐야겠다는 생각도 했다. 물론 1년을 채 버티지 못하고 스스로 물러났지만 짧은 시간동안 큰 깨달음 얻고 내려왔으니 운이 좋았다. 이 과정에서 내가 배운건 개발자나 매니저나 본질은 똑같다는 거다. 결국 다 회사가 성공하기 위해 필요한 역할에 지나지 않는다. 그동안 조직장을 마치 상위 포지션이라고 생각했던게 나의 큰 착각이었다. 조직 구조도 결국 회사의 성공 확률을 높이기 위해 펼치는 여러 전략중에 하나일 뿐이다. 그러니 회사가 성장할때마다 조직개편을 하는거 아니겠는가?

아무튼 다시 개발자로 돌아왔다. 매니저에서 다시 개발자로 돌아갈땐 아무런 직책도 맡고 싶지 않았다. 그저 방망이 깎는 노인이고 싶었다. 하지만 현실은 나를 그렇게 쉽게 내버려두지 않는다. 이미 내 커리어에 조직장 경력이 있으니 회사는 나에게 리더의 역할도 은근히 기대한다. 나 또한 눈치가 있으니 그걸 모르진 않는다. 하지만 나도 다 계획이 있다.

팀빌딩의 시작

이번 스테이지는 순수하게 개발자로 다시 평가받고 싶었다. 그리고 조직장과 같은 직책 없이 열정 많은 한 개발자가 다른 팀원들에게 어떤 영향을 주는지 테스트해보고 싶었다. 그래서 오로지 개발만 할꺼라고 선을 긋고 입사했다. 어마어마한 코드베이스가 입사 첫날부터 나를 억누른다. 오래된 코드베이스는 전혀 트랜디하지 않았다. 코드를 수정하면 결과를 확인하는데까지 대략 30초. UI 개발에 코드 한줄 고치고 맞는지 확인하는데 30초는 어마어마한 시간이다. 결국 머리로 컴파일 하거나 개발자 도구를 열어서 직접 스타일을 바꾸고 확인한 후에 코드를 수정하고 다시 30초. 몇번을 반복하면 수많은 생각이 떠오른다. 아.. 이래서 다 그만 둔건가? 왜 이걸 아직까지 안고치고 있었던거지? 하아… 한숨이 절로 새어나오고 지금 생각해도 가슴이 턱턱 막힌다. 개발 환경을 트랜디하게 바꾸지 못하면 결국 아무것도 하지 못한다는 각오을 몇번이나 되새기며 시도하고 실패하고 롤백을 두번이나 했다. 그렇게 두번 연습하니 세번짼 성공 하더라. 진짜 혼자였으면 못했다.

개발 환경이 좀 개선됐다고 갑자기 개발속도가 빨라지진 않는다. 거대한 코드베이스 그 자체가 발목을 잡는다. 때론 폴더 구조 개선만으로 리팩토링이 쉬워질수도 있다. 하지만 변경된 파일만 1200개… ㄷㄷㄷ

거대한 코드베이스를 이해하려면 때론 화가가 되어야한다. 그림을 그리고 나면 비로서 맥락이 보이기 시작한다. 하지만 이 변경도 파일 90개, 추가된 코드 천줄, 빠진 코드 천줄!

초반에 이런 작업이 많으면 비동기 코드 리뷰 자체가 불가능하다. 그리고 모두 신규 입사자. 거대 코드 베이스를 연구하는 유적 발굴단처럼 뭔가 발견하면 같이 공유하고 연구해야하는 운명공동체! 그렇게 매일 아침 팀원들과 화이팅 넘치는 수다로 시작해서 PR 리뷰받고 바로 수정해서 병합하기를 반복했다. 그렇게 몇달을 하다보니 자연스레 오전 일과는 팀원들과 함께 보내는 날들이 쌓이고 팀 문화가 되어 버렸다.

그러던 어느날 폴이 말했다. 매일 출근했던 전직장보다 이상하게 더 많이 대화하고 친밀감도 높고 매일 보는것 같다고.. 리모트 환경에서 매일 오전을 함께 코드 리뷰하면서 보낸 시간이 팀워크를 다지는 시간이 됐다. 리모트로 일했던 이전 회사에서도 친밀감을 위해 오전에 의도적인 티타임을 했는데 친밀감을 높이진 못했던거 같다. 그보다 어느 순간엔 시간 낭비라는 생각도들고 티타임은 흐지부지 사라졌다. 그런데 이번엔 좀 달랐다. 어떤 차이가 있는 것일까? 아마도 공통의 목적을 가진 목적 조직이라서 가능한게 아닐까? 서로 다른 프로젝트를 하는 기능조직에선 내 PR을 들고와서 같이 고민한다는게 쉽지는 않은 것 같다.

다시 심겨지는 잔디

매니저로 있었던 시기나 보안에 민감했던 회사에선 보통 엔터프라이즈 깃헙을 사용하기 때문에 개인 계정에 잔디 심기가 쉽지 않다. 퇴직하고 구직자로 전환되는 순간 이 잔디 심기가 마음에 좀 걸리는데 왜냐면 내가 누군가를 채용하는 면접관이었을 때 나는 항상 지원자의 블로그와 깃헙을 찾아보곤했다. 좋은 사람을 채용하려면 그만한 노력이 수반된다. 짧은 면접에 이사람의 장단점을 극적으로 뽑아내려면 면접관은 FBI가 되어야한다. 사전에 알수있는 정보가 많다면 미리 알고 들어가는게 좋다. 그래야 양질의 질문을 할수있기 때문이다. 지피지기면 백전 백승!

여하튼 이런 이유로 나는 이력서에 블로그와 깃헙 계정이 없는 지원자는 대부분 서류에서 탈락시켰다. 이제 그 화살이 내게 다시 돌아왔다. ㅎㅎㅎ 구직자는 열심히 블로깅하고 깃헙에 액티비티가 없는 이유를 방어해야한다. 내가 이런 글을 쓰고 있는 것도 다 이런 이유가 있는거다!

아무튼 나는 지난 2년 5개월을 충실히 개발자로 살았다. 빼곡한 잔디가 농부의 마음처럼 뿌듯하다. 심지어 이 잔디는 스쿼시 PR 로만 쌓은 커밋이라 자부심 하나를 더 한다.

그리고 나는 한 아이의 아빠로 충실한 삶을 살았다. 결혼하고 아이가 생기면 개발자에겐 큰 시련이 온다. 공부할 시간이 절대적으로 부족하기 때문이다. 재택으로 일 하다 보면 퇴근보다 아이의 하원이 빨라서 강제 육아 모드로 전환된다. 부모로부터 물려받은 성격이 있어서 직업윤리를 벗어나는 행동을 잘 하지 못한다. 그러다보니 하던일을 마무리하지 못하면 육퇴한 밤 11시에 업무로 다시 돌아가곤했다. 그러니까 잔디가 저렇게 금요일에서 토요일로 넘어가는 경계에도 심겨버린다. 특히 디버깅 중에 육아로 강제 전환되면 헤어나오질 못한다. 아이를 씻기면서도 머릿속에선 컴파일 중이다.

하루는 아이가 미열이 있어 어린이집을 보내지 않았다. 엄마도 5일간 자리를 비운 탓에 온전히 육아와 일을 병행해야하는 상황에 놓였다. 아빠와 노는게 좋은 우리 아이는 늘 그렇듯 아빠 책상 옆에 긴 의자를 하나 대놓고 종이 접기에 한창이다. 만 4살은 종이 접기를 잘 할 수 없는 나이다. 그러니 간간히 놀아달라 접어달라 인터럽트가 꾀나 집요하다. 회의하다말고 마이크를 끄고 버럭 화를 냈다. “기다려! 아빠 회의 좀 하자!” 시무룩해진 아이는 어느새 조용해진다. 그리고 나는 다시 돌아가 30분을 더 떠들고나서야 아이 생각에 옆을 본다. 세상 곤히 잠든 아이… ‘아!… 내가 무슨 부귀 영화를 누리겠다고 이 지랄을 하고 있나..’ 싶은 생각이 들 정도로 기다리다 지쳐 쭈구려 자고 있는 아이를 보면 명치 한구석에서 짠~~ 함이 몰려온다.

육아와 일을 병행하는 부모라면 엄마 아빠 할 것 없이 모두 이와 비슷한 경험을 했을 것이다. 그래서 나는 당분간 시대가 필요로 하는 개발자이길 포기했다. 육아와 업무만으로도 벅찬데, AI 시대에 LLM 공부를 어떻게 하나? 물론 나도 책은 사뒀지만 읽기가 참 어렵더라. 지속적인 학습이 되지 않는 상황이라면 도로묵이다. 과감히 투자를 포기한다. 한때 기업 강의를 꾸준히했던 덕에 여기 저기서 들어오던 강의 요청도 모두 거절했다. 나는 아이가 10살이 되기 전까진 뛰어난 개발자보다는 그냥 좀 더 성숙한 아빠가 되고자 한다.

개발자도 사람이다.

일정 수준에 도달한 이후 공부를 하지 않는 개발자에 대한 이야기가 한동안 돌았다. 내심 찔리긴 했지만 몰라! 나는 지금 그게 중요하지 않다. 아이가 지금 짠 한데 무슨 천자문 공부냐? 나는 그럴수록 더 다짐한다. 개발자이기 전에 성숙한 더 나은 사람이 되자.

그런데 재밌는건 시니어 개발자의 기준을 어떻게 가르나요? 라고 동료 개발자들에게 물어보면 코딩을 잘 한다거나 지속적인 학습을 하는 개발자라고 딱히 시니어라고 평가하지는 않았다. 오히려 그 외적인 모든 것을 기준삼는 경우가 많았다. 예를 들면 그 중 하나가 소통 능력인데 아이러니하게 아이와 대화하다보면 소통 능력과 인내심이 발달한다.

아이는 모든 것에 서툴고 실수 투성이다. 인내심도 어른 같지 않아서 징징대고 떼쓰기 일쑤다. 그런 아이를 보고 있노라면 나도 모르게 버럭 할때가 있다. 그럼 또 미안해서 사과하면 괜찮다며 이해한다고 나를 위로해준다. 이게 어른인지 애인지 가끔 헷갈린다. 한번은 어린이집에서 길을 건널때 손들고 건너야 한다고 배웠나보다. 나와 건널목을 걷는데 나에게 왜 손을 들지 않냐며 아빠도 어서 손을 들라고 성화를 내 길래… 일단은 손을 들어 건넌 후에 차분히 아이에게 설명했다.

“라일아, 길 건널때 왜 손 들고 가야하는지 알아?” / 쭈볏쭈볏 (내심 그 이유는 모르는것 같다) / “아빠가 설명 해줄께. 잘 들어봐! 라일이는 키가 작아서 운전하는 사람이 잘 못 봐. 그래서 키 작은 사람은 손을 들어줘야 운전자가 보고 멈출수있어. 그래서 아빠 어릴땐 큰 노란색 카드를 들고 다녔거든. 그런데 지금은 아빠가 키가 커서 노란색 카드도 필요 없고, 굳이 손들고 걷지 않아도 돼”

이날 이후 우리 아이는 내가 손을 들지 않아도 뭐라고하지 않는다. 하루는 아이에게 다시 질문했다.

“라일아, 길 건널때 왜 손들고 걸어야해?” / “어..왜냐면 내가 키가 작아서 운전하는 사람이 날 잘 못봐 그래서 손을 안들면 나를 쾅~하고 치고 갈수있어. 그래서 손드는 거야” / 덜덜덜… 물어본 내가 바보다. 이미 한방에 이해하고 있었다.

여하튼 나와 아내의 육아관은 아이에게 ‘너 자꾸 떼쓰면 망태기 할머니가 너 잡아간다’ 라는 과장된 이야기를 하지 않고, 정확한 이유를 설명하고 있는데 이게 습관이 되다보니 직장 생활에서도 이어진다. 평소에도 되짚는 질문을 많이 하는데 다행히 동료들도 내 질문을 공격적으로 받아들이진 않는것 같다. 되려 본질을 다시 고민해서 좋다고 피드백받아서 안심했다.

팀워크의 본질

육아 하면서 아이에게 배우는게 참 많다보니 사회생활에서 주니어와 시니어를 나누는 것 자체가 모순이라는 생각이든다. 시니어라고 항상 완벽하고 누군가를 이끌어야하는 존재도 아니고 주니어라고 항상 배워야하는 존재도 아니다. 우리는 모두 불완전한 존재다. 그러니까 팀으로 일한다.

7년전이었나? 넷플릭스 인재상이 한때 유행한적이 있었다. 모든 것에 유능한 만랩 개발자! 나 또한 이 인재상을 차용해 팀원들과 일대일 면담을 할 때 나만의 원통형 개발자 이론을 열심히 설파했던 적이 있었다. 원통형 개발자는 이런거다. 마치 축구 게임의 레이더 그래프처럼 슈팅, 스태미너, 패싱, 롱킥, 태클, 수비 등등 능력을 표현하는 요소들이 무수히 많고, 그 능력치가 만랩인 사람이 최고의 개발자라는 지론 그리고 그런 사람하고 일할때 나는 너무 좋았다. 그러니 너희들도 만랩이 되어라… 라고 설파한건 아니다.

원통형 인재의 핵심은 “너만의 핵심 팩터를 스스로 결정하고 그 파이의 크기를 키워라” 라는게 나의 핵심 골자다. 왜냐면 축구팀에 메시만 존재하는건 아니니까. 위치에 따라 혹은 대항하는 팀에따라 다양한 능력의 선수들이 기용되기 때문이다. 다 각자 개성대로 쓸모가 있다.

어쨌든 이런 사고의 시작은 넷플릭스 만랩 개발자에서 영향을 받은건 사실이다. 그래서 팀을 상상할때도 만랩 개발자들이 있는 팀에서 일하고 싶은 욕망이 강했다. 이상적인 팀이란 그런 만랩 개발자가 모인 팀이라 생각했다. 그리고 그런 팀이라고 생각했던 회사를 다녔던 적도 있다.

그런데 이번 스테이지에서 생각이 바꼈다. 현실에서 팀원 개개인은 만랩일수없다. 그리고 생각해보니 만랩이라고 생각했던 팀에서 나는 혼자 일한 경험이 더 많다. 만랩 개발자는 굳이 팀으로 일할 필요가 없다. 오히려 만랩 개발자들이 모여서 불협화음을 낸 팀도 봤다.

팀을 만드는 이유는 개인이 불완전하기 때문이다. 불완전한 개인을 보완하는 수단으로 현실에선 팀으로 일한다. 나는 팀안에서 나의 부족함을 수혈받는 경험을 지난 2년 동안 무수히 많이했다. 대표적인 예시는 이런거다. 하루종일 혹은 밤새며 몇일간 버그와 씨름하고 있다. 그러다가 도저히 머리가 안돌아가서 다음날 아침에 팀원들에게 가져가면 여지없이 5분만에 해결되는 경험을 하게 된다. 또 이런 경험들이 쌓이면 팀안에서 안정감마저든다.

하루는 팀원들에게 이런 고백을 했다. “나는 시니어지만 시니어라고 모든걸 다 잘하진 않는다. 그래서 때론 불안한데, 우리 팀에서 나는 그 불안함이 없다. 내가 못풀면 내일 아침, 알란이나 폴이 분명 이 문제를 풀어줄꺼란 확신이든다.” 이런 안정감을 주는 팀은 내 커리어 안에서 없었던것 같다. 우리팀이 최고다! 작개는 3명인 개발팀이지만 크게는 목적 조직으로 7명인 팀 안에서 나의 이런 불완전함을 심심치 않게 고백한다. 언제 어디서 이런 팀원을 또 만날수있을까? 감사하고 또 감사한 일이다. 퇴직함으로써 이런 팀원들과 헤어지는건 분명 아쉬운 일이다. 그런데 뭐 헤어짐의 이유가 나의 퇴직은 아니니까. 아쉬워도 어쩔수없다.

내가 2년전 팀에 합류할때 왜 무너진 팀에 합류하냐면 나를 만류하던 지인들에게 무너진 팀을 재건하는게 내 전문이라고 호기롭게 얘기했던거 같다. 그런데 정작 팀 회고에선 어떻게 이런 팀원들을 만났는지 이건 운빨이라고… ㅎㅎㅎ

그래서 다음 스테이지에선 이게 운빨이 아님을 증명하고 싶다. 좋은 팀은 운빨일 수 없다. 좋은 팀은 의식을 가지고 만들어지는거다. 다시 한번 주문을 외울때가 되었다.