결국 해를 넘겨서야 잠깐이나마 회고글을 쓸 수 있을 만한 시간이 났다. 내 삶의 가장 큰 부분을 차지하고 있는 래블업은 많은 사람들의 도움과 노력으로 고속성장을 지속 중이다. 코로나19가 잦아든 이후 올해는 태어나서 가장 많은 비행기를 탄 해가 되었다.

CTO = Tech Lead + PM + HR + ?

올해를 돌아보며 가장 큰 고민이면서 가장 큰 어려움이 된 부분은 이제 곧 30명을 넘어가리라 예상되는 조직에서 CTO로서 나의 역할이 무엇인가 하는 점이다.

우선은 제품에 뭔가 변화를 가하기 위한 기술적 난이도가 시간이 갈수록 점점 높아진다는 것이 1차적으로 느껴지는 어려움이다. 당장 고객사에서 요청한 요구사항은 아니지만, 그러한 요구사항들을 적기에 빠르게 개발하고 안정화하고 고객의 손에 쥐어주기 위해서 필요한 기술부채 해결을 위한 시간과 리소스를 확보하는 것이 쉽지 않다. 흔히 말하는, 이미 날아가고 있는 비행기를 조립하고 부품을 바꿔끼우는 기분이랄까.

주력 제품인 Backend.AI의 주요 코드를 대부분 내 손을 거쳐 작성하였지만, 이제는 내가 손대지 못하는 영역도 점점 많아지고 있고 add-on 성격으로 붙는 추가 컴포넌트들은 아예 내가 코드리뷰조차 일일이 하지 못하는 경우도 있다. 단일 코드베이스를 9년째 유지보수하다보니 오는 어려움까지 겹쳐져 대환장 파티를 벌일 때도 종종 생긴다. ㅋㅋ (과거의 나야, 대체 왜 그랬니....ㅠㅠ) 몇몇 데이터베이스 테이블이나 객체 구조 설계를 살짝만 비틀어서 했더라도 리팩토링에 수 개월 이상 걸리는 대형 기술부채를 거의 만들지 않을 수 있었을 텐데 하는 생각이 드는 부분도 있다. 물론 그러한 경험들 자체가 훌륭한 학습과 회고의 재료가 되기도 하지만, 당장 고객사 요구사항들 쳐내느라 터져나가는 상황에서는 하나하나가 아쉬움이 크게 다가온다.

게다가 점점 새로운 설계나 아이디어를 적용하기 위해서 "그냥 해보자~" 가 안 되는 상황이 많아진다. Python 언어나 관련 프레임워크 커뮤니티에서 '아, 이런 문제는 이런 패턴과 이런 조합으로 해결하면 됩니다'라는 best practice가 제시되지 않는 경우는 특히 그렇다. 2~3가지 이상의 아이디어를 놓고 각각을 실험적으로 작게 구현해보고 비교분석해야 하고, 그 과정에서 기존 코드베이스에 가장 빠르고 쉽게 적용할 수 있는 방향이 무엇인가(이것은 처음 새로 짤 때와 다른 선택을 요구할 때가 많다) 고민해야 한다. 즉, 점점 역사를 알아야 제대로 평가와 분석이 가능한 경우가 많아지고 있다는 뜻이기도 하다. 게다가, 지금도 만들어지고 있는 이 역사를 일일이 찾아보기 어려울 미래의 팀원들을 위해서는, 가장 빠르고 쉽게 변경을 가하면서도 동시에 미래에도 계속 변화를 수용할 수 있는 구조를 함께 고민해야 한다. 이게 무슨 대단한 디자인 패턴이나 거창한 설계를 하는 게 아니라, 아주 사소하지만 코드 변경의 고통을 줄여줄 수 있도록 당장의 개발 비용 차이가 크게 나지 않는 작은 선택들을 5분씩만 더 고민해도 매우 많은 개선을 기대할 수 있다는 것을 최근에 깨닫게 되었다.

며칠 전에 한 온라인 지인분이 소개해주신 Wiring Winning Organization: Liberating Our Collective Greatness through Slowification, Simplification, and Amplification이라는 책이 기억에 남는다. 아직 책을 읽어보지는 못했지만, 인용해주신 "slowification" 대목이 딱 지금 상황에 필요한 것이 아닌가 싶었다. "감속화는 문제해결을 급박하고 무자비한 영역에서 벗어나게 함으로써 문제를 해결하기 쉽게 만듭니다." 고객에게 바로 짠 하고 최종 결과물을 제공하기 전에, 먼저 MVP를 만들어보고, staging area를 통해 QA 과정에서 미리 문제를 걸러낼 수 있게 하고 이런 것들도 감속화의 일종으로 볼 수 있을 것이다. 또한 개발 과정에서 다양한 선택들을 보다 쉽게 시도해볼 수 있도록 적절한 리팩토링과 추상화, 테스트 작성을 통해 심리적 안전감을 향상시키는 것도 포함될 것이며, 업무 프로세스 중 고객과 요구사항에 관해 커뮤니케이션하는 방법을 개선함으로써 개발팀에게 시간을 벌어주는 것도 포함할 수 있을 것이다.

이러한 기술적 영역을 관리함과 동시에, 아직 조직이 성장 중이라는 점에서 나오는 PM이나 HR의 부재도 메꿔야 한다. 특히 코로나 기간 팀원 수와 고객사 수가 동시에 크게 증가하였고 그와 함께 커버해야 하는 프로젝트의 전선(frontline)도 매우 넓어졌다. 따라서 아무리 내가 이 모든 일을 시작한 사람 중 하나라고는 해도 모든 맥락을 머릿속의 hot cache에 항상 넣어둘 수는 없게 되었다. 거기에 올해는 후술하듯 굉장히 많은 출장(거의 매달 해외를 나갔다고 봐도 될 정도)을 다녔기 때문에 중간중간 내가 백로그 관리를 챙기지 못하는 공백 기간들이 계속 발생했다. 큰 그림을 그리고 잠재적 투자자나 고객, 파트너를 만나 설명하는 일과, 일상적인 코드 리뷰에서 디테일한 변수 이름 하나까지 챙기는 일을 지속적으로 맥락 전환하면서 줌인/줌아웃을 하는 것이 때로는 재미있을 때도 있지만 때로는 굉장히 정신적으로 지치기도 한다.

요즘 고민하고 있는 것은 (회사에 따라 명칭과 의미를 다르게 보기도 하지만) 대체로 PM 내지 Engineering Manager라 불리는 역할을 조직에 어떻게 충원할 것인가 하는 부분이다. 한국어로 표현한다면... '조율자'가 가장 어울리는 이름이 아닐까 한다.

내가 조율자에게 기대하는 것을 풀어서 설명하면 이렇다. 고객이 요청해서 만들어지는 백로그와 개발팀 백로그 사이를 끊임없이 연결시켜주고 상기시켜주면서 전체적인 일의 진행상황을 파악하고 필드옵스에 피드백함과 동시에, 개발팀의 각 구성원들이 들고 있는 일의 양과 난이도를 지속적으로 추적하여 부하분산을 시켜주는 역할을 말하는 것이다. 그냥 놔두면 개발팀 또는 필드옵스팀 자체적으로는 GitHub에 이슈나 PR을 만드는 과정에서 왜 이러한 이슈가 나오게 되었는지 그 맥락을 잘 상호 링크하고 본문/코멘트로 정리하는 일이 잘 되지 않는다. 이걸 누군가 끊임없이 챙겨줘야, 중복으로 일하는 것도 막을 수 있고 때로는 특정 이슈에 불필요하게 많은 노력을 들이는 일도 막을 수 있다. 또한 내가 만든 변경사항이 궁극적으로 어떻게 회사에 도움이 되고 있는지 느낄 수 있게 된다. 그냥 놔두면, 한 이슈를 조금 보다가 리뷰가 조금 지연되면 자꾸 다른 이슈에 뛰어들어서, 굉장히 많은 이슈를 "active" 상태로 들고 있는데 완료되는 개수는 적은 상태에 빠지는 경우도 생긴다. 일을 시작하는 것보다 마무리하는 것이 중요한데, 코드를 직접 손으로 만지는 입장에서는 코드를 바꿔보는 것 자체가 재미있기도 하기 때문에 이런 함정에 쉽게 빠질 수 있다. 적절한 타이밍에 리뷰를 진행하려면 조율자의 역할이 중요해진다. 이슈를 발행한 사람과 이슈를 코드로 구현하는 사람과 이것을 리뷰하는 사람이 모두 달라질 때 특히 이런 문제가 많이 생기는 것 같다. 코로나 이전에는 사실상 3~4명의 핵심 구성원이 이 과정을 모두 셀프로 혼자, 직접 수행했기 때문에 조율자라는 역할이 필요 없었지만, 이제는 필요해진 것이다.

요즘 업계 지인들을 만날 때마다 이러한 관점에서 개발팀 운영이나 PM/Engineering Manager의 채용·승진 과정에 대해 물어보곤 했다. 아쉬운 점은, 국내 회사들은 대부분 팀원들 중 누군가를 시켜보고 잘 하면 그 역할을 주고 안 맞는 것 같으면 다른 사람에게 역할을 주는 정도에 머물고, "IC (individual contributor) track"과 대비하여 체계적으로 "manager track"을 관리하는 경우가 거의 보이지 않는다는 점이다. 그나마 실리콘밸리로 flip한 곳이거나 외국계 회사이거나 이런 경우에 TL (tech lead) + PM (project manager)를 명시적으로 구분하여 운영하고 있는 정도였다. 지식노동의 특성 상 하나의 단일한 방법론이 모든 경우에 적용될 수는 없겠으나, 그것은 managing이라는 행위의 구체적 구현이 조직마다 매우 다른 양상을 띨 수 있다는 점에서는 맞는 말이겠고, 조율 혹은 manging이라는 행위 자체가 필요하고 그 역할을 명시적으로 조직 차원에서 구성해야 한다는 점은 기본으로 깔고 가야 하는 게 아닌가 싶다. 회사 차원에서의 '경영'이 art의 영역인지 method의 영역인지도 사람마다 의견이 다를 수 있겠지만, 그래도 동종업계에서 가장 잘 나가는 회사들이 어떤 방법들을 시도하고 있는지는 한번 벤치마킹하고 배워볼 필요가 있지 않나 싶기도 하듯, 개발팀의 매니징과 조율자라는 역할도 마찬가지가 아닐까 한다. 특히 개발자 지인들을 만나면서 느낀 것은, 자신이 새로운 조직에 합류하였을 때 managing에 대한 일정 수준의 기대치가 있기 때문에, 보다 큰 규모의 조직을 운영하는 입장에서는 일정 수준 그 기대치를 맞춰주는 것도 필요할 수 있겠다는 것이었다.

여튼, 이래저래 고민이 많다. 이제는 기술적인 것뿐만 아니라 개발조직이라는 차원에서의 고민이 한 켜 더 쌓인 느낌이다.

북아메리카 대륙과 친해지고 세계 일주까지

올해는 정말 출장과 여행을 많이 다녔다. 1월 CES부터 시작해서(당장 이번 토요일에도 또...) 4월 PyCon US, 6월 OpenInfra Summit + CVPR, 9월 IFA, 10월 PyCon APAC, 11월 SC23 + 런던 파트너사 이벤트. 마지막 출장은 한국-미국(덴버)-영국(런던)-한국으로 돌아오는 세계일주이기도 했다. 여기에 개인적으로는 9월 추석연휴를 끼고 인도네시아 발리에 휴가를 다녀오기도 했다.

아직까지 미국 동부를 못 가봤는데, 이제 다녀온 주요 지역들을 꼽아보자면, 하와이, 샌프란시스코+산호세를 포함한 실리콘밸리, 시카고, 덴버, 솔트레이크시티, 라스베가스, 댈러스 이렇게 된다. 시애틀은 시내에 들어가보지는 못했지만 올해만 3번이나 공항 환승했더니 이제 왠지 가본 도시인 것만 같다(...). 여기에 출장 일정 중간에 쉬어가는 주말이나 업무가 비는 날짜를 이용해 그랜드캐년 핼리콥터 투어도 나녀왔고, 캘거리와 밴프를 거쳐 캐나디안 로키 산맥에 있는 레이크 루이즈(맞다, 유키구라모토의 그 레이크 루이즈!)도 가봤고, 콜로라도 스프링스 근처의 아메리칸 로키 산맥에서 해발 2800m 지역까지 올라가보기도 했다.

온라인에서 흔히 나오는 밈들 중에 '미국이 괜히 천조국이 아니다'라거나 '이건 방장 사기맵이야!' 이런 게 있는데, 과연 그 말이 맞는 것 같다. 미국이 세계를 제패할 수 있었던 것은 군사적·정치적으로 여러 요인이 있겠으나, 경제적으로 본다면 미친 듯한 생산력을 자랑하는 대규모 토지를 갖고있는 하나의 대륙을 대부분 차지하고 앉아 양쪽 대양을 모두 접하면서 사실상 2개의 대양을 지배함에서 나오는 엄청난 물류 파워가 아닐까. 대항해시대 이후 해상물류를 장악하는 집단이 당대 최강대국이었던 것은 부정할 수 없는 역사적 사실이다. 미국에서 또 한 가지 기억에 남았던 장면은 콜로라도 스프링스 근처를 지나가다 본 미국의 공군사관학교였다. 구름 한점 없이 푸른 하늘 아래 병풍처럼 둘러진 로키 산맥을 배경으로 해발 2000m에 펼쳐진 드넓은 대지 위에 떡하니 지어둔 비행장 위로 수많은 경비행기들이 날아다니며 비행교육을 하고 있었다. 내가 잘 모르는 분야이긴 하지만, 비행기 조종 면허를 따는 과정에서 미국 유학을 선택할 경우 많이들 거쳐가는 곳이라 한다. 우리나라에서는 볼 수 없는 스케일의 땅에서 자유롭게 날아다니는 비행기들을 보니 한없이 부러웠다. 컴퓨터공학을 하는 입장에서 컴퓨터의 종주국이 미국이기도 하지만, 비행술의 종주국 또한 미국이기도 하다.

체력적으로는 정말 힘들었지만(북미나 유럽 출장 후 한국에 돌아오면 그 여파가 일주일은 간다), 그나마 이러한 짤막짤막한 여행들이 버텨내는 데 도움이 되기도 한 것 같다. (사실 레이크루이즈 투어 때는 감기몸살이 된통 걸려서 완전 앓아누웠는데 레이크루이즈를 보겠다는 의지 하나로 버티면서 여행한 거라... 그 감동이 좀 줄어든 감이 있다... ㅠㅠ) 올해는 전체적으로 컨퍼런스 출장은 좀 줄이되 핵심적으로 가야 하는 곳에 집중하는 방향으로 할 것이라 약간 변화가 있을 수는 있겠다.

중간에 휴가로 다녀온 발리 여행은 바삐 뭔가를 구경하러 돌아다니던 여행 패턴을 벗어나 한 장소에서 정말 놀고 먹고 쉬는 것을 컨셉으로 간 '휴양'이었다. 코로나 이후 여러 이유로 급등한 항공권 가격 때문에 돈이 좀 많이 깨지긴 했지만, 기회가 된다면 (발리 내의 다른 지역들로) 또 가보고 싶은 생각이 든다. 비상용으로 랩탑을 가지고 갔지만, 중간에 정부과제 책임자로서 과제관리 시스템 권한 승인을 해야 하는 일 때문에 30분 정도 펼친 것 말고는, 랩탑을 펼치지 않기로 한 목표는 나름 선방했다. 한국과 거의 같은 시간대라서 시차적응이 필요 없고, 남반구라 계절도 반대라서 나름 좋은 선택지인 듯.

마무리하며

회사가 성장하는 것과 내가 성장하는 것이 일치하는 부분도 있지만 동시에 점점 더 새로운 도전을 요구하는 부분도 있다. 내가 완전히 지쳐 나가떨어지지 않도록, 작은 갈등과 실수에도 평정과 여유를 유지할 수 있도록 몸과 마음의 건강을 잘 챙겨야겠다는 생각이 많이 든다. 연말 스팍스 모임에서도 올해의 화두는 '건강'이었다.

내가 이루어낸 많은 것들은 주변 사람들의 도움이 없었으면 어려웠을 것들이 많다. 모두들 건강한 한 해가 되었으면 좋겠다.