POOOLING FOREST
운 좋은 개발자가 되는 알고리즘: 단순히 코딩만 잘해서는 부족한 이유 - 단순히 코딩만 잘해서는 부족한 이유를 '행운의 표면적' 이론으로 설명합니다. 공유를 통해 커리어의 기회를 넓
Culture & Philosophy

운 좋은 개발자가 되는 알고리즘: 단순히 코딩만 잘해서는 부족한 이유

단순히 코딩만 잘해서는 부족한 이유를 '행운의 표면적' 이론으로 설명합니다. 공유를 통해 커리어의 기회를 넓히고 운을 끌어당기는 구체적인 방법을 제안합니다.

김테크

8년차 개발자

안녕하세요. 풀링포레스트 풀스택 개발자 김테크입니다.

솔직히 고백하자면, 저는 오랫동안 다른 개발자들의 성공을 보며 막연한 질투를 느낀 적이 많습니다. 별로 대단해 보이지 않는 기술 블로그 글 하나로 유명한 컨퍼런스 연사가 되거나, 오픈 소스 기여 몇 번으로 빅테크 기업의 오퍼를 받는 동료들을 보면서 말이죠. 그때마다 저는 이렇게 생각했습니다. "저 사람은 참 운이 좋구나." 나는 밤새워 복잡한 레거시 코드를 리팩토링하고, 트래픽 폭주를 막기 위해 아키텍처를 뜯어고치느라 바쁜데, 세상은 알아주지 않는 것 같아 억울하기도 했습니다.

하지만 최근 읽게 된 한 아티클을 통해 머리를 한 대 얻어맞은 듯한 충격을 받았습니다. 제가 '운(Luck)'이라고 치부했던 그것이 사실은 철저한 '확률 게임'이었다는 사실을 깨달았기 때문입니다. 오늘은 저처럼 묵묵히 코만 박고 일하는 개발자들에게, 왜 우리가 작업물을 세상에 공개해야 하는지, 그리고 그것이 어떻게 우리에게 기회를 가져다주는지에 대해 이야기해보려 합니다.

우리는 흔히 실력만이 정답이라고 생각합니다. 저 역시 주니어 시절에는 "좋은 코드는 언젠가 빛을 발한다"라고 믿었습니다. 하지만 현실은 냉정했습니다. 아무리 훌륭한 기능을 구현하고, 우아한 코드를 작성해도, 그것이 회사 내부의 비공개 리포지토리에만 머물러 있다면 외부 세계에서 저의 가치는 '0'입니다.

여기서 흥미로운 개념이 하나 등장합니다. 바로 '행운의 표면적(Luck Surface Area)'이라는 이론입니다.

Jason Roberts라는 사람이 정의한 공식인데, 아주 단순합니다.
운 = [당신이 하는 일(Doing)] * [사람들에게 알리는 것(Telling)]

개발자로 치면 이렇게 해석할 수 있겠죠.
커리어의 기회 = [코드 품질/구현 능력] * [블로그/발표/오픈소스 활동]

저는 지난 8년 동안 [Doing] 변수만 미친 듯이 키워왔던 겁니다. 아무리 [Doing]이 100점이어도, [Telling]이 0점이면 결과값은 0이 됩니다. 반면, 실력이 조금 부족해 50점이라 하더라도, 꾸준히 공유하여 [Telling]을 2점으로 만들면 결과는 100이 됩니다. 우리가 흔히 "운 좋다"고 말하는 개발자들은 사실 이 '알리는 행위'를 통해 행운이 착륙할 수 있는 활주로를 넓게 닦아놓은 사람들이었습니다.

그렇다면 왜 우리는 공유를 주저할까요? 저의 경우를 돌아보면 두 가지 이유가 있었습니다.

첫째, "이건 너무 당연한 거 아냐?"라는 생각입니다.
연차가 쌓일수록 자신이 아는 지식이 상식처럼 느껴집니다. 예를 들어, 쿠버네티스에서 파드(Pod)의 생명주기를 관리하는 팁을 알게 되었다고 칩시다. "공식 문서에 다 있는데 굳이?"라고 생각하며 넘어갑니다. 하지만 세상에는 이제 막 도커를 배우기 시작한 주니어부터, 다른 분야의 시니어까지 그 정보가 절실한 사람이 수없이 많습니다. 내가 겪은 '삽질'의 과정은 누군가에게는 귀중한 트러블슈팅 가이드가 됩니다.

둘째, "틀리면 어떡하지?"라는 두려움입니다.
공개된 코드나 글에 비판적인 댓글이 달릴까 무서웠습니다. 하지만 실제로 세상에 작업물을 내놓아보면, 냉소적인 댓글 하나보다 고마움을 표하는 사람이 열 배는 더 많습니다. 설령 틀린 내용을 공유했다 하더라도, 그것을 정정해주는 피드백을 통해 우리는 더 빠르게 성장할 수 있습니다. 이것이야말로 진정한 의미의 코드 리뷰 아닐까요?

그래서 저는 전략을 바꾸기로 했습니다. 거창한 기술 논문을 쓰자는 게 아닙니다. 풀링포레스트에서 일하며 겪는 소소한 문제 해결 과정, 새로 도입한 라이브러리에 대한 짧은 감상, 심지어는 바보 같은 실수담이라도 기록으로 남기는 것입니다.

예를 들어, 단순히 "버그 수정"이라는 커밋 메시지 대신, 어떤 원인으로 메모리 누수가 발생했고 힙 덤프를 어떻게 분석했는지 짧게라도 정리해서 블로그에 올리는 식입니다. 혹은 사내에서만 쓰던 유틸리티 함수를 다듬어 작은 오픈 소스 라이브러리로 배포해볼 수도 있겠죠.

기술적인 비유를 들자면, 이것은 마치 도커 컨테이너의 포트를 외부로 노출(Expose)하는 것과 같습니다. 내부에서 아무리 멋진 웹 애플리케이션이 돌아가고 있어도, 포트를 열어주지 않으면 트래픽은 들어올 수 없습니다. 여러분의 작업물을 공개하는 것, 그것이 바로 여러분의 커리어 포트를 여는 행위입니다.

지금 당장 완벽할 필요는 없습니다. 그저 무언가를 만들고, 그것을 어딘가에 올리세요. 깃허브 리드미(README) 한 줄을 고치는 것부터 시작해도 좋습니다. 우리가 만든 작은 파동이 지구 반대편의 누군가에게 닿아, 예상치 못한 채용 제안이나 협업 기회라는 '행운'으로 되돌아올지 아무도 모르는 일이니까요.

여러분의 행운의 표면적은 지금 얼마나 넓습니까? 오늘 퇴근길에는 머릿속에만 있던 아이디어를 세상 밖으로 꺼내보는 건 어떨까요. 저도 오늘 이 글을 발행함으로써 제 운을 조금 더 늘려보려 합니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.