대부분의 기술적 문제는 사실 사람 문제다

예전에 나는 엄청난 기술 부채를 안고 있던 회사에서 일한 적이 있다. 수백만 줄의 코드, 단 하나의 유닛 테스트도 없고, 이미 한참 전에 시대에 뒤처진 프레임워크들 위에 쌓여 있었다. 특히 어떤 프로젝트에서는, Windows 전용 모듈들을 Linux에서 돌아가게 만들어야 하는 시장 요구가 있었는데, 크로스 컴파일을 하는 대신 다른 팀에서 아예 몇십만 줄의 코드를 복사·붙여넣기 해서 Windows 전용 컴포넌트를 Linux 전용 컴포넌트로 바꿔 끼우는 식으로 처리해 버렸다.

비전공자·비개발자에게 설명하자면, 이건 엄청난 문제다. 이제 코드의 두 버전이 존재하기 때문이다. 따라서 앞으로 모든 기능 추가와 버그 수정은 시간이 지날수록 서로 달라지기만 할 두 개의 코드베이스에 각각 따로 해줘야 한다. 이 얘기를 들었을 때, 어리고 순진하던 나는 이 상황을 해결해 보겠다고 나섰다....

기술 부채만 정리하는 프로젝트는, 설령 모든 게 완벽하게 흘러간다 해도 결과적으로 “원래 하던 것과 별로 달라 보이지 않는” 코드를 만들 뿐이라서, 경영진을 설득하기가 항상 어렵다. 이 프로젝트도 예외는 아니었고, 겉으로 보이는 인상도 좋지 않았다. 나는 많은 엔지니어들이 그렇듯, “정치적인 건 무시하고”, 머리를 숙인 채 묵묵히 일만 했다. 하지만 프로젝트는 예정보다 길어졌고, 그 과정에서 나는 조직 내 신뢰·영향력을 꽤 잃었다.

그제야 나는, 본질적으로 사람 문제를 기술적인 해법으로 풀려고 하고 있었다는 걸 깨달았다. 이 회사의 대부분의 개발자들은 오늘 하는 일을 어제 하던 그대로, ... 그리고 5년 전과 다를 바 없이 하는 것에 만족하고 있었다. Andrew Harmel-Law가 지적하듯이, 코드는 그것을 작성한 사람들의 성향을 그대로 따라간다. 코드가 석회화되어 굳어 버린 건, 개발자들 또한 그렇게 굳어 있었기 때문이었다. 변화를 싫어하는 성향을 가진 사람들은, 대개 앞으로의 변화를 염두에 두고 코드를 설계하지 않는다.

대부분의 기술적 문제는 사실 사람 문제다. 곰곰이 생각해 보자. 기술 부채는 왜 생기는가? 작업을 시작하기 전에 요구사항을 제대로 명확히 하지 않았기 때문이다. 세일즈 담당자가 고객에게 비현실적인 마감일을 약속했기 때문이다. 개발자가 익숙해서 편하다는 이유로 이미 한참 지난 옛 기술을 골랐기 때문이다. 경영진이 너무 반응적이라 프로젝트를 진행 중간에 취소해 버렸기 때문이다. 누군가의 자존심 때문에 더 나은 방식을 보지 못했기 때문이다.

이 프로젝트의 핵심 문제는, 리팩터링이 필요하다고 인정하는 순간, 회사가 소프트웨어를 만드는 방식이 망가져 있고, 개개인의 역량 또한 한참 뒤처져 있다는 사실을 함께 인정해야 한다는 데 있었다. 내 소규모 팀은 여러 모듈 중 단 하나만 고치려 애쓰고 있었고, 다른 개발자들은 수십 년째 해오던 방식 그대로 코드를 쓰고 있었다. 어떤 개발자는 나에게 대놓고 이렇게 말했다. “나는 새로운 건 하나도 배우고 싶지 않아요.” 그때 깨달았다. 다른 사람들이 새로 쌓아 올리는 기술 부채의 속도보다 빨리 그 부채를 정리할 수는 절대 없다는 것을. 응급실에서 환자를 분류하는 상황과도 같다. 먼저 피부터 멎게 해야 한다. 그다음에야 부러진 걸 고치든, 수술을 하든 할 수 있다.

이상적인 세계

이 프로젝트는 또, 엔지니어들이 이상적으로 꿈꾸는 세계—엔지니어링 문제를 진공 상태에서만 다룰 수 있고, "정치"는 피하고, 결과물이 스스로 말하게 내버려 둘 수 있는 세계, 마감일도 없고... 솔직히 말해 고객도 존재하지 않는 세계—가 현실에는 거의 존재하지 않는다는 사실을 내게 일깨워 주었다. 실제로는 거의 모든 프로젝트에 비기술적인 이해관계자들이 얽혀 있고, 그들에게 “그냥 믿어 주세요, 열심히 하고 있어요”라고 말하는 것만으로는 부족하다. 나는 당신의 팀이 정말 많은 일을 해내고 있다는 ‘인지된 인상(perception)’이, 실제로 많이 해내는 것만큼이나 중요하다는 걸 깨달았다.

비기술자들은, 어떤 일이 어느 정도의 노력이 드는지, 그리고 왜 기술 부채를 정리해야 하는지 직관적으로 이해하지 못한다. 이는 초기 일정 산정과 프로젝트 진행 상황 공유에서, 엔지니어링 쪽이 효과적으로 커뮤니케이션해야 한다. 리더십이 엔지니어링 배경을 갖고 있지 않다면, 기술 부채 정리의 가치는 수치화해서, 비즈니스 가치로 보여줘야 할 가능성이 크다.

고개를 드는 법(Heads Up)

아마 이런 깨달음들이 더 높은 직책을 준비하게 해 주는 교훈일 것이다. 내 생각에, 시니어 엔지니어 이상의 위치에 있는 사람이라면, 기술 트랙이든 관리 트랙이든 상관없이, 반드시 여러 조직·기능과 협업하는 법을 알아야 한다. 학교에서는 컴퓨터 과학을 가르치지, 사람 성향, 자존심, 각자의 블라인드 스폿을 어떻게 다룰지를 가르치지 않는다.

나는 정말 대단한 엔지니어들과 함께 일해 왔다. 나보다 훨씬 뛰어난 사람들로, 어떤 기술을 꺼내 들어도 깊이 있게 알고 있는 타입이다. 어렸을 때 나는 그런 엔지니어가 되고 싶었다. “엔지니어들이 인정하는 엔지니어” 말이다. 하지만 이제는, 그게 내 성향과는 맞지 않는다는 걸 안다. 나는 그럴 만큼 한 가지에 깊게 파고들 집중력이 없다. :)

그들의 (상당한) 강점에도 불구하고, 그런 타입의 엔지니어들은 대개 사람과 관련된 일은 피하려 든다. 비극적인 점은, 그들은 믿을 수 없을 정도로 생산적인 개인 기여자(IC)이지만, 더 큰 이니셔티브에서는 실패할 수 있다는 것이다. 어쨌든 그들은 한 사람일 뿐이고, 단일 CPU 코어가 낼 수 있는 속도에는 한계가 있기 때문이다. 그에 못지않게 가치 있을 수 있는 존재가 바로 **“고개를 드는(heads up) 코더”**다. 깊은 기술 역량을 갖추었으면서도, 고개를 들어 프로젝트 상의 리스크(기술적인 것이든 아니든)를 미리 보고, 팀이 그 리스크를 피해 가도록 이끌 수 있는 사람 말이다.