기술 역량 유지하며 엔지니어링 관리자 되기: 폴 윌리엄스의 여정

폴 윌리엄스(Paul Williams)는 자신이 코딩을 매우 좋아한다고 밝히며, 이번 강연이 코딩을 진정으로 사랑하는 사람의 리더십 여정에 관한 것임을 강조했다. 그는 기술 전문가로서의 역할과 리더로서의 역할을 어떻게 조화시킬 수 있는지에 대한 질문에 답하고자 했다.

이 강연은 개발자들이 흔히 겪는 딜레마, 즉 팀 리더나 관리자가 되면 기술적 업무에서 멀어질 것이라는 우려에 초점을 맞추고, 두 가지 역할을 모두 성공적으로 수행할 수 있음을 보여주려 한다.

폴 윌리엄스는 15세 때 신문 배달보다 코모도어 베이식(Commodore Basic) 프로그램을 잡지에 출판하는 것이 더 많은 수입을 가져다준다는 사실을 깨달았다고 회고했다. 이 경험은 그에게 있어 15세에 진로를 변경하게 된 결정적인 계기가 되었다.

이 초기 경험은 그가 기술적인 재능을 일찍이 발견하고, 이를 통해 경제적인 가치를 창출할 수 있음을 체감하게 해주었으며, 평생의 직업 선택에 영향을 미쳤다.

윌리엄스는 약 10년간 로봇 공학의 머신 비전(Machine Vision)을 위한 고성능 컴퓨팅 커스텀 하드웨어 병렬 시스템을 프로그래밍하는 데 주력했다고 밝혔다. 그는 당시 인공지능(AI)이 주로 수많은 'if 문'으로 구성된 전문가 시스템으로 불렸다고 설명했다.

이 시기의 경험은 그에게 복잡한 시스템 아키텍처와 성능 최적화에 대한 깊은 이해를 제공했으며, 이는 훗날 다양한 기술적 문제 해결에 중요한 기반이 되었다.

윌리엄스는 블룸버그에서 겪었던 흥미로운 난제에 대해 이야기했다. 당시 블룸버그 제품을 사용하는 고객들이 특정 환경에서 데이터 업데이트를 볼 수 없는 문제가 발생했다. 이 문제는 고객사 시스템의 라이브 데이터가 실제로 업데이트되지 않는 현상으로 나타났으며, 재부팅 후에는 일시적으로 해결되는 것처럼 보였으나 다시 동일한 문제가 반복되었다.

문제의 원인을 파악하기 위해 블룸버그 엔지니어링 팀은 고객사 환경에 접속하여 다양한 진단을 시도했다. 그들은 시스템에 영향을 줄 수 있는 모든 요소를 점검했지만, 초기에는 명확한 원인을 찾기 어려웠다. 이는 단순한 버그를 넘어선 복합적인 문제임을 시사했다.

더욱 복잡했던 점은 이 문제가 특정 고객 환경에서만 발생하고 재현이 쉽지 않았다는 것이다. 따라서 문제 해결을 위해서는 심층적인 분석과 함께 기존의 접근 방식으로는 파악하기 어려운 부분까지 들여다봐야 했다.

이 사례는 복잡한 분산 시스템 환경에서 발생하는 예측 불가능한 문제에 대한 깊이 있는 기술적 분석의 중요성을 부각시켰다.

폴 윌리엄스는 실시간 데이터 업데이트 문제가 특히 기억에 남는 이유로, 블룸버그 조직 내 수많은 사람이 이 문제의 원인을 파악하기 위해 참여했던 점을 꼽았다. 팀은 로그를 확인하고, 심지어 동료 중 한 명을 고객사의 은행 기술 팀에 보내 프로세스 덤프를 캡처하고 실시간 데이터가 업데이트되지 않는 이유를 파악하도록 했다. 이 과정은 문제 해결을 위한 전사적인 노력을 보여준다.

초기에는 네트워크 문제, 방화벽 문제, 심지어 CPU 스케줄러 문제까지 다양한 가설이 제기되었다. 블룸버그 팀은 고객이 겪는 문제를 해결하기 위해 시스템의 모든 구성 요소를 면밀히 검토했으며, 이는 엔지니어링 팀의 깊은 기술적 이해와 헌신을 요구했다.

이처럼 광범위한 진단과 협업에도 불구하고, 문제의 근본 원인을 즉각적으로 찾아내기는 쉽지 않았다. 여러 전문가들이 각자의 지식을 동원하여 퍼즐 조각을 맞추려 했고, 이는 기술적 리더십과 팀워크의 중요성을 재확인하는 계기가 되었다.

결과적으로 이 경험은 복잡한 문제에 직면했을 때 기술적 깊이를 가진 여러 전문가의 협력이 얼마나 중요한지를 윌리엄스에게 각인시켰다.

강연자는 RFC(Request for Comments)와 SSH(Secure Shell)에 대해 간략히 소개했다. RFC는 인터넷 표준과 프로토콜을 정의하는 문서 시리즈이며, SSH는 불안전한 네트워크에서 안전한 로그인 세션을 위해 사용되는 프로토콜이다. 강연에서는 SSH 전송 계층 프로토콜을 위한 RFC 문서를 예시로 들었다.

그는 이 특정 RFC 문서가 실시간 데이터 업데이트 문제의 원인과는 직접적인 관련이 없음을 명확히 했다. 다만, 기술적 문제 해결 과정에서 다양한 프로토콜과 표준에 대한 이해가 필요함을 시사했다.

강연 도중 비상 경보가 발령되는 예기치 않은 상황이 발생했다. 강연자는 참석자들에게 당황하지 말 것을 요청하며, 이는 온타리오 주에 대한 테스트 알림일 뿐이며, 보안 침해와는 전혀 관련이 없다고 설명했다. 잠시 혼란이 있었지만, 상황은 빠르게 진정되었다.

실시간 데이터 업데이트 문제의 원인은 다름 아닌 클라이언트 데스크톱 PC에 설치된 특정 안티-맬웨어 프로그램의 잘못된 작동 때문이었다. 클라이언트 기술팀과의 협력 끝에, 모든 문제가 발생하는 PC들이 최근 업데이트된 동일한 안티-맬웨어 프로그램을 실행하고 있음이 밝혀졌다. 이 안티-맬웨어 회사는 TCP/IP 트래픽에서 악성 SSH 트래픽을 탐지하려는 새로운 기능을 도입했으나, 이 기능이 블룸버그 제품의 정상적인 통신을 방해하고 있었다.

이 문제는 예측하기 매우 어려웠는데, 일반적인 애플리케이션 버그나 네트워크 장애가 아닌, 보안 소프트웨어의 오작동이라는 외부 요인이었기 때문이다. 블룸버그 팀은 해당 안티-맬웨어 회사와 긴밀히 협력하여 문제를 분석했고, 결국 안티-맬웨어 프로그램의 업데이트를 통해 이 문제를 해결할 수 있었다.

이 경험은 시스템 문제를 진단할 때 단순히 자사 코드나 인프라뿐만 아니라, 고객 환경에 설치된 서드파티 소프트웨어의 영향까지 고려해야 한다는 중요한 교훈을 주었다.

폴 윌리엄스는 블룸버그와 같이 약 9,000명의 개발자가 있는 대규모 조직에서 기술적 깊이가 다양한 직급과 역할에서 얼마나 중요한지 깨달았다고 말했다. 개인 기여자부터 팀 리더, 관리자, 부서장, 엔지니어링 책임자에 이르기까지, 모든 수준의 사람들이 디버거에서 무엇이 잘못되었는지 이해하려 노력하는 모습을 보았다는 점이 그에게 깊은 인상을 주었다.

그는 실제 문제가 발생하여 해결책을 찾아야 할 때, 사람들이 평소에는 사용하지 않을 수도 있는 기술적 능력이 되살아나서 문제 해결에 결정적인 역할을 하는 것을 목격했다. 이는 엔지니어링 관리자로서도 기술적 이해를 꾸준히 유지하고 발전시켜야 하는 이유를 분명히 보여주었다.

윌리엄스는 엔지니어링 관리자가 제공하는 진정한 가치에 대해 설명했다. 그는 관리자의 역할이 단순히 기술적인 업무를 수행하는 것을 넘어, 프로젝트 관리, 우선순위 설정, 보고, 합의 도출과 같은 중요한 책임을 포함한다고 강조했다. 또한, 인력 관리, 특히 멘토링은 다른 사람의 성장에 기여하는 보람 있는 일이라고 언급했다.

그는 팀 빌딩 기회가 있다면 채용도 매우 중요한 관리자의 역할이라고 덧붙였다. 이러한 역할들은 팀의 생산성을 극대화하고, 팀원들의 성장을 돕는 데 필수적이며, 기술적 역량만큼이나 중요한 리더십 기술을 요구한다.

폴 윌리엄스는 과거 상사로부터 "더 이상 혼자서 일을 할 수 없다"는 말을 들었던 경험을 회고했다. 그는 개인 기여자로서 밤낮없이 일하며 생산성을 높이려 했지만, 상사는 그의 생산성을 확장할 수 있는 유일한 방법은 다른 사람들의 도움을 받는 것이라고 설명했다. 이는 그에게 팀워크와 레버리지의 중요성을 깨닫게 한 계기가 되었다.

상사는 윌리엄스의 기여도를 인정하면서도, 그의 역량을 더 큰 규모로 확장하기 위해 팀을 만들어야 한다고 제안했다. 그리고 윌리엄스가 그 팀의 리더가 되어야 한다고 강조하며, 필요한 리더십 기술을 가르쳐주겠다고 약속했다. 이 조언은 그가 기술자에서 관리자로 전환하는 중요한 전환점이 되었다.

이 경험은 한 개인이 아무리 뛰어나도 조직 전체의 목표를 달성하기 위해서는 다른 사람들과 협력하고 그들의 역량을 이끌어내는 리더십이 필수적임을 보여준다. 윌리엄스는 이러한 전환을 통해 자신의 영향력을 확장하는 방법을 배웠다.

결과적으로 그는 혼자서 모든 것을 해결하려던 방식에서 벗어나, 팀을 통해 더 큰 성과를 창출하는 관리자의 역할에 눈뜨게 되었다.

윌리엄스는 파인아트 전공자로 온라인 해커톤과 코딩 대회 경험만 있는 직원의 사례를 공유했다. 그에게 UI 개선 작업에 일주일 또는 이주일이 걸릴 것이라고 예상하며 자신의 게임 프로그래밍 배경에서 얻은 힌트를 주었지만, 다음 날 그 직원은 작업을 모두 끝냈다고 보고했다.

놀랍게도 그 직원은 윌리엄스가 제시한 방법 대신, 화면 업데이트 방식의 특성을 이용해 마우스 위치를 확인할 수 있는 훨씬 간단한 방법을 찾아냈다. 그녀는 문자 그대로 2주간의 업무를 하루 만에 끝냈으며, 이는 윌리엄스 자신의 깊이 있는 배경으로는 생각하기 어려운 접근 방식이었다.

이 경험은 팀 내에 다양한 의견과 경험을 가진 인재가 있는 것이 얼마나 중요한지를 윌리엄스에게 가르쳐주었다. 기존의 사고방식에 갇히지 않은 새로운 관점이 때로는 훨씬 효율적이고 혁신적인 해결책을 제시할 수 있음을 입증한 사례다.

폴 윌리엄스는 엔지니어링 리더가 팀에 대한 깊은 이해와 기술적 통찰력을 바탕으로 팀의 역량을 다른 부서에 효과적으로 알리는 것이 중요하다고 강조했다. 또한, 상부에서 내려오는 지시를 팀이 이해하고 받아들일 수 있도록 재구성하는 역할 또한 리더의 핵심 책무라고 설명했다.

리더는 팀의 기술적 강점과 한계를 명확히 파악하고, 이를 바탕으로 다른 부서와의 협업을 원활하게 이끌어야 한다. 동시에, 전략적 방향성을 팀의 언어로 번역하고, 목표 달성을 위한 구체적인 실행 계획을 수립하여 팀원들이 동기를 가지고 업무에 임할 수 있도록 해야 한다.

윌리엄스는 Zapier의 엔지니어링 매니저인 켈리 본(Kelly Bourne)의 블로그 'The Modern Leader'를 적극 추천하며, 그녀가 엔지니어링 리더십에 대해 가장 사려 깊고 통찰력 있는 목소리를 가지고 있다고 평가했다. 그는 본의 글들이 엔지니어링 관리자로서의 역할과 도전에 대한 깊이 있는 이해를 제공한다고 언급했다.

윌리엄스는 시스템 운영의 원활함을 위한 측정 지표(텔레메트리)가 유용하고 도움이 되며 실행 가능해야 한다고 강조했다. 이는 단순히 데이터를 수집하는 것을 넘어, 실제로 작업에 활용할 수 있는 통찰력을 제공해야 한다는 의미이다. 수집된 데이터는 문제를 진단하고, 성능을 최적화하며, 미래의 결정을 내리는 데 실질적인 도움을 줄 수 있어야 한다.

그는 텔레메트리가 '측정' 자체를 위한 것이 아니라, 시스템의 건강 상태를 파악하고 개선하기 위한 도구여야 한다고 설명했다. 이를 위해서는 어떤 지표를 측정할지 신중하게 선택하고, 그 지표들이 실제 비즈니스 목표나 사용자 경험과 어떻게 연결되는지 이해하는 것이 중요하다. 단순한 데이터의 나열이 아닌, 의미 있는 정보의 흐름이 필요하다.

예를 들어, 시스템의 응답 시간, 오류율, 리소스 사용량 등은 모두 중요한 측정 지표가 될 수 있다. 하지만 이러한 지표들이 왜 중요한지, 그리고 어떤 조치를 취할 수 있는지 명확하게 파악할 수 없다면 그 가치는 떨어진다. 따라서 텔레메트리 시스템은 이러한 정보들을 명확하게 시각화하고 분석할 수 있는 기능을 제공해야 한다.

궁극적으로 유용한 측정 지표와 데이터는 팀이 시스템의 문제를 예측하고 선제적으로 대응하며, 지속적인 개선을 이끌어내는 데 필수적인 역할을 한다. 이는 엔지니어링 관리자가 기술적 깊이를 유지하면서도 팀의 전반적인 성과를 향상시키는 데 기여할 수 있는 핵심 영역이다.

윌리엄스는 경량 측정 지표를 활용하여 모든 사용자를 대상으로 실시간 UI 응답성을 모니터링했던 사례를 소개했다. 이 "항상 켜져 있는" 측정 지표는 모든 사용자로부터 데이터를 집계하고 샘플링할 수 있게 했다. 예를 들어, 블룸버그의 인스턴트 메시지 애플리케이션인 '인스턴트 블룸버그'의 UI 스레드 응답성을 측정한 결과, 90%의 사용자에게서 34~35밀리초 내에 응답이 이루어졌다.

이 측정 지표는 매우 가볍게 설계되어 시스템에 부하를 주지 않으면서도 상시 작동할 수 있었다. 덕분에 블룸버그 팀은 모든 사용자를 대상으로 정밀한 측정 데이터를 지속적으로 수집할 수 있었고, 이를 통해 시스템의 성능 저하 여부를 신속하게 확인할 수 있었다.

이러한 방식은 대규모 시스템에서 사용자 경험을 면밀히 추적하고, 잠재적인 성능 문제를 조기에 감지하여 선제적으로 대응하는 데 매우 효과적이었다. 경량 지표의 활용은 기술적 깊이를 유지하면서도 실제 사용자에게 미치는 영향을 측정하고 개선하는 중요한 방법론을 보여주었다.

윌리엄스는 64비트 시스템에서 효율적인 메모리 추적을 위한 기술적 도전과 해결책을 공유했다. 크로미움 레이어에는 자체적인 커스텀 힙 엔진이 있었는데, 32비트 시스템에서는 전체 주소 공간을 커버하는 큰 비트 마스크로 메모리 사용량을 추적하는 것이 가능했다. 하지만 64비트 시스템에서는 16기가바이트 크기의 비트 마스크가 필요해져 비효율적이었다.

이러한 문제를 해결하기 위해 그는 런 길이 인코딩(Run-Length Encoding) 버전의 맵을 고안했다. 이 기법은 데이터 범위를 저장함으로써 겉보기에는 큰 비트 마스크처럼 보이지만 실제 저장 공간은 280바이트 정도에 불과하게 만들었다. 이로써 64비트 환경에서도 메모리 오버헤드 없이 효율적인 메모리 추적이 가능해졌다.

윌리엄스는 블룸버그에서 채용 면접과 경력 성장 면접을 진행하며 "조직도가 당신의 영향력을 정의하지 않는다"는 말을 자주 했다고 밝혔다. 그는 굳이 우두머리가 되거나 천 명 규모의 조직을 이끌지 않아도 회사 내에서 상당한 영향력을 가질 수 있다고 강조했다. 이는 영향력이 단순히 직급이나 직책에서 오는 것이 아님을 시사한다.

그는 영향력이 단순히 제품을 만드는 것을 넘어, 회사를 옮겨 다니면서 형성하는 관계에서도 나온다고 설명했다. 신뢰를 구축하고, 다른 팀 및 부서와 효과적으로 소통하며 협력하는 능력은 공식적인 조직도를 넘어서는 실질적인 영향력을 창출한다. 이러한 관계는 정보의 흐름을 원활하게 하고, 문제 해결을 위한 협업을 촉진하며, 궁극적으로 조직 전체의 성공에 기여한다.

개인의 성장 또한 이러한 관계망 속에서 이루어진다고 그는 믿었다. 다양한 배경과 전문성을 가진 동료들과의 상호작용은 새로운 아이디어를 얻고, 시야를 넓히며, 개인의 기술적 및 리더십 역량을 발전시키는 중요한 기회가 된다.

따라서 엔지니어링 관리자는 기술적 전문성뿐만 아니라, 강력한 관계를 구축하고 유지하는 데도 노력을 기울여야 한다. 이는 팀의 성공뿐만 아니라, 개인의 경력 성장과 조직 내 영향력 확대를 위한 핵심 요소이다.