훌륭한 동료 개발자들에게 배운 것

 나는 꽤 오랜 기간 C++ 개발자였다. C++로 안정적인 어플리케이션을 만들기 위해서는, 다른 언어보다 조금 더 어려운 문제가 많다. 이는 단순한 자부심이 아니고 C++라는 언어 자체가 가진 장점과 단점을 이해해야 되는 부분이 있다. 메모리를 직접 다루고, 네이티브 환경으로 동작하는 언어이다 보니 덤프를 남기지 못하고 크래시가 발생하거나, 메모리 오염이 일어나 즉시 크래시가 나는게 아니라 n차 전파에서 증상이 나는 경우도 있다. 현재의 웹 서버 개발 트렌드에서 장애의 대부분은 DB나 트래픽 소화 이슈인 경우가 더 많다. 

프레임워크를 쓰면서, 프레임워크 자체에서 크래시가 나는 경우는 흔치 않다. 하지만 나는 프레임워크를 만들어 쓰던 시대의 개발자이고, 그렇다보니 프레임워크를 잘 만드는 능력이 아주 중요했다. 회사마다 팀마다 프레임워크를 만들어 썼고, 이 퀄리티에 따라 프로젝트의 장애 확률과 장애도가 달랐다. 

이러한 시기에 만난 훌륭한 개발자들 다수는 나에게 큰 자극과 괴리감, 또 한편으로는 긍정적인 자극이 되었는데 이에 대해서 소개하고자 한다. 아마도 여러분도 같이 프로젝트를 하는 팀원, 회사의 동료, 스터디에서 만난 지인들 중에서 자신보다 똑똑하다고 생각하는 분들이나 천재라고 느끼는 분들이 있을 것이다. 이러한 능력자를 만났던 이야기를 해보고자 한다.
 

학습, 업무 태도가 좋았던 동료 개발자

 온라인 게임을 만들던 시절 N사에서 만나게 됐다. 옆팀 동료였다. 내가 만들던 TCP 소켓 프레임워크(Netty 같은 것이라고 봐도 무방하지만, 프레임워크 성향도 띄고 있었던)가 멀티스레드 환경에서 특정 상황에 지연이 발생했다. 동일한 세션의 버퍼로 동시에 접근(access) 할 때 급격히 느려지는 로그를 발견했고, 성능 로그를 봤는데 이해가 되지 않았다. 

이에 대해서 한참 머리 아파 싸매고 있었더니, 옆팀 프로그래머 분이 괴로워하는 나를 보고 질문을 던진 동료였다. 상황과 코드를 같이 리뷰한지 얼마 지나지 않아 '거짓 공유(False Sharing)' 아니냐며 링크를 던져주셨다.
 

요약하자면, 실제로는 스레드 간 공유되지 않은 데이터 임에도 캐시의 특성상 마치 공유된 것으로 판별해 성능 저하가 일어나는 현상이다. 일반 변수와 다르게 volatile 처리할 수 없었던 이유는 byte array버퍼였기 때문이다. 멀티스레드 간 인접 메모리 접근이 안되게 메모리 영역을 크게 잡으니 해결됐다. 해결되고 나서 어떻게 이 것을 알았느냐고 물어보았더니, ‘프로그래머가 몰랐던 멀티코어 CPU 이야기’ 라는 책을 읽고 어떠한 상황인지 인지하고 있었다고 알려주었다. 

책을 흘려 보내듯 읽지 않았으며, 책을 통해서 충분히 직접 경험하지 않은 문제도 직접 경험한 것과 같은 경험치로 승화시킬 수 있는 능력을 지녔다고 볼 수 있었다. 그래서 이 동료에 대해 관심이 생겼고, 이 동료가 구현한 프레임워크를 살펴보게 됐고, 해당 프레임워크로 다수의 사용자가 들어오는 서비스 개시일, 아주 소소한 버그 말고는 발생하지 않았다. 어떻게 그렇게 안정적으로 동작하게 만들었느냐고 물어봤더니 돌아오는 답변이 인상적이었다. 

“공식 문서에 있는 내용을 철저히 지키려고 했고, 공식 문서에 나와있는 레퍼런스를 철저히 따라서 가능한 모든 예외처리를 하려고 했을 뿐이에요.”

그렇다. 나는 그때까지 겉멋이 들어있었고 5년차의 패기로 무장한 뒤 거만한 태도를 가지고 있었던 것이다. 기본은 지키지 않고 더 큰 것, 더 먼 것을 바라봤다. 그러나, 동료의 태도를 통해 훌륭한 기량은 기본에 충실하고 좋은 태도를 가지는 것임을 깨닫게 되었다.

프로덕트의 발전에 도움이 되는 노력을 기울였던 개발자

 개발자의 업무를 빽빽하게 채워서 하루 8시간 치를 매일 만들어 전달하기란 관리자 입장에서 쉽지 않다. 나 역시 관리자일 때 마다 퍼포먼스에 대한 압박을 받지만, 개발자의 업무를 시간 단위로, 그것도 하루 마다 적정한 주제와 적정한 분량을 던져주기란 쉽지 않았다. 나의 관리자들도 비슷했을 것이고, 그렇다보니 일이 들쭉 날쭉하기 쉽다. 

예를 들어 어떠한 시기에는 협업하는 동료들의 마무리가 몰려, 갑작스레 그에 대한 보강 및 QA 등으로 인한 철야를 해야 될 때도 있는 반면, 어떠한 시기에는 일이 붕 떠서 할 일이 애매할 때가 존재했다. 사실 이러한 시간은 개발이라는 업무를 일정으로 관제하면서 일정 수준 생길 수 밖에 없는 필연적인 요소라고 생각한다. 

주니어 때의 나는 그러한 시기를 책을 읽거나, 만들어둔 코드에 대한 기능 테스트를 한다거나, 하고 싶었던 주제에 대한 공부를 하는 편이었는데, 당시 옆에 있던 동료는 프로젝트에 도움이 될 주제를 파고 드는 것을 볼 수 있었다. 그리고 그 것을 팀에 전파하며, 팀의 에너지를 프로덕트의 발전과 미래에 대한 대비에 쏟는 것을 느끼고, 반성했다. 한참의 시간이 지난 지금도, 프로덕트의 발전만을 위해서 코스트를 쏟는 것이 효율적이라고 생각하진 않지만, 적어도 업무 시간 중 남는 시간은 프로덕트의 발전에 노력을 쏟아야하고, 이를 가능하면 팀의 공통의 주제로 만들어서 최선의 프로덕트를 지향해야 되는 것에 크게 공감하고 나 역시 이후에 실천하고 있다.

역량 집중이 좋았던 개발자

 장애가 생길 때 마다 회사 내부의 오래된 프로젝트의 결함이나 오픈 소스를 보자마자 분석해서 해결책을 가져오던 동료가 있었다. 중요한 점은 원인 파악 속도가 워낙 빨라서, 대부분의 이슈에 대해서 1시간 내에 해결책을 가져왔다. 복잡한 이슈는 시간이 좀 더 걸리긴 했지만, 팀 내 군계일학이었고 잘못 짚을 때도 있었지만 빠르게 실패를 인정하고 다른 문제점을 찾는 이터레이션이 빨랐기에 자연스레 팀의 에이스가 되었다. 원래 분석했거나, 사용해 본 프로젝트인가 물어봤지만, 진짜 분석 속도가 빠른 거였다. 

특히, 위에서 언급한 프레임워크를 만들어 쓰던 시기에 만난 동료로, 프레임워크는 오픈소스 화 되어 이미 사용해 본 그런, 프레임워크가 아니었다. 2007년이었음에도 친구는 시대를 앞서, 다양한 오픈소스를 최대한 많이 살펴보려 했고, 중요한 역량이 코드 읽기, 코드 분석임을 직감했다고 했다. 그래서 다양한 프로젝트를 분석하고, 이해하는 역량을 키우기 위해 집중해왔다고 했다. 그렇다보니 상향식 분석, 하향식 분석, 코드 읽기 자체의 역량이 계속 올라왔고, 문제 해결 능력이 쌓일 수 있는 근간인 빠른 이터레이션과 코드 읽는 속도를 통해서 다른 동료보다 높은 역량을 빠르게 확보 할 수 있어 여러가지 측면에서 앞서 갈 수 있었다. 

더 놀라운 측면은, 속도만 추구하느라 원리를 이해하지 못한 것은 절대 아니였다. 나는 오히려 바퀴를 재발명하고, 내가 작성한 코드에 대한 이해도와 컴퓨터 과학, OS 이해도, 컴파일러 이해도, 해킹 등에 관심이 더 많았는데, 동료를 보고 코드 읽기의 중요성과 원리 파악의 중요성을 깨닫고 크게 자극을 받았다. 계속 노력하다보니 나도 이 역량이 그 동료보다는 많이 부족했지만 어느정도 올라왔고, 실제로 많은 오픈소스 프로젝트의 동작 원리나 이슈를 파악하고, 핵심을 짚어내는 역량을 키우는 계기가 되었다. 이는 이후에 내가 많은 회사에서 장애 상황에 대처하거나 기술을 도입하는데에 큰 장점으로 작용했다.

논리력을 키워준 리더

버그나 장애가 있을 때 나도 빠르게 문제를 찾고 싶었다. 그게 내가 능력있고 머리가 좋다는 것을 증명하는 것만 같았다. 그래서 여러가지 가설을 들고가서, 리드 개발자 분들을 설득하곤 했다. 이러한 과정을 유심히 지켜보시던 백엔드 테크 리더께서, 나에게 역질문을 던지기 시작하셨다. 

• 가설에 빈틈은 없나요? 
• 가설의 상황이 발생했는지 로그로 확인해보았을까요? 
• 시퀀스 다이어그램으로 제안하신 해결책을 그려서 보여주실 수 있나요?
• 제안하신 해결책으로는 이 이슈(특정 지점을 가리키며)가 해소되지 않을 것 같습니다. 어떻게 생각하시나요? 

이렇게 매번 되물어보시는 리더와 함께하며 논리력이 자연스레 키워졌다. 이 분이 하신 말씀 중에 “엔지니어는 증명을 해야해요.” 라는 말이 가장 기억에 남는다. 

“가정을 하고, 가설을 세우기만 하는게 아니라, 최대한 많은 근거 자료로 이를 증명해야 합니다. 로그가 덜 남았다던지, 유실됐다던지해서 이를 확인하기 어렵다면, 스테이지 환경이나 로컬에서 재현해서 증명하셔야해요."

 

"문제가 있는 것도 당연히 문제지만, 문제를 해결하려하다가 다른 문제를 만드는 것은 더 큰 문제가 되기 쉬워요. 잊지마세요. 엔지니어는 증명할 수 있어야 합니다.”

그리고 이후 회사 생활에서 내가 리드하거나, 동료와 협업을 하는 단계에서 자연스레 이러한 것들을 실천하게 됐고, 멘토링 과정에서도 효과적으로 멘티 분들의 성장을 돕는 데에 쓰고 있는 방식이다.
 

나보다 훌륭한 동료를 만난다는 것은 순간적으로는 괴로워질 수 있다. 나는 직접 언급하거나 표출하지 않을 뿐, 동료와 나를 비교하곤 했고, 그 과정에서 자괴감도 들었고, 넓은 세상엔 얼마나 더 훌륭한 사람들이 많을까 하는 좌절감이 들기도 했다. 하지만 잘 생각해보면, 그러한 동료들의 마인드, 성향, 역량 중 많은 것들은 나 또한 노력으로 커버할 수 있는 부분이고 따라 갈 수 있는 부분이었다. 이를 배우면서 더 좋은 개발자로서, 롱런할 수 있는 자질을 키울 수 있는 계기이자, 방법이었다. 여러분도 훌륭한 동료를 만날 때 좌절하기 보다는, 체감하며 배울 수 있는 계기로 삼으면 어떨까?