[개발자 원칙]을 읽고
첫 월급을 받던 기억은 누구에게나 생생합니다. 저도 마찬가지였습니다. 직장에 채 적응하기도 전에 맞이한 첫 월급날, 통장에 꽂히던 낯선 입금액은 단기 알바나 근로장학생으로 받던 급여보다 몇 배는 많았는데다가 부모님께 눈치 보며 손을 벌리지 않아도 되는 ‘직장인’의 뿌듯함을 실감케 했습니다. ‘내가 정말 이 돈을 받아도 되나?’라는 자조적인 질문이 나올 정도로 어안이 벙벙했지만, 세상에 내 쓸모를 인정받았다는 사실만으로도 감격했었죠.
8년이 지난 지금, 그때와는 비교할 수 없을 만큼 연봉이 올랐음에도 마음은 덤덤하기만 합니다. 아니, 솔직히 말하면 덤덤함을 넘어 툴툴댈 때도 많습니다. 나보다 여건이 좋거나 더 많은 보상을 받는 사람들과 끊임없이 비교하며 ‘내가 이 고생을 하는데 이것밖에 못 받나’라며 투덜대기도 하죠.
직장인의 중요한 성적표인 연봉은 이렇게나 좋아졌는데, 왜 제 태도는 8년 전보다 후퇴한 것일까요? 어쩌면 일에 몰입하고 효능감을 느끼기 위해서는 돈이 아닌 다른 가치가 필요했는지도 모릅니다. 사회초년생 시절에는 모든 게 새로운 경험이라 익히는 것 자체가 즐거웠다면, 지금은 매일 비슷한 업무 패턴이 반복되어 권태에 잠식된 것이겠죠.
결국 저는 다시 “나는 진짜로 무엇을 할 수 있는 사람인가?”라는 질문을 스스로에게 묻습니다. 8년 전의 제가 ‘내가 무엇을 할 수 있길래 이 월급을 받는 걸까’라며 감격 섞인 의문을 던졌다면, 지금의 저는 ‘이곳에서 내가 대체 무엇을 더 할 수 있을 까‘ 라는 존재론적인 질문을 던지고 있습니다.
이 지루한 관성을 깨뜨릴 정직한 자극이 필요했습니다. 외부 네트워킹 데이에 참여하여 짧은 인사이트를 얻기도 하고, 퇴근 후 온라인 강의를 듣거나 개발 서적을 뒤적이며 부족한 부분을 채우려 애써보기도 했습니다. 그러다 추천을 통해 알게 된 책 <개발자 원칙>을 펴 들었습니다. 저보다 앞서 걸어간 시니어 개발자들은 이 권태와 질문 앞에 어떤 대답을 내놓았을지 궁금했기 때문입니다.
어느새 ChatGPT를 필두로 제미나이, 클로드가 등장하며 개발자를 대체할지도 모른다는 AI 시대가 도래했습니다. 불과 1년 전만 해도 AI가 짜주는 코드는 개발 언어를 배운 지 얼마 안된 학생 수준이라 대수롭지 않게 생각했었는데, 이제는 다릅니다. 에이전트 AI는 지침에 따라 훌륭한 코드와 아키텍쳐를 쏟아내며, 인간 개발자와 관리자만이 할 수 있다고 믿었던 영역까지 넘보고 있습니다.
문득 이러다가 희망퇴직을 걱정해야 하는 건 아닌지 두려워지기까지 했습니다. 이제 “나는 무엇을 할 수 있는가”라는 질문은 조금 더 생존의 영역에 가까워졌습니다. 단순한 코더로서의 역량만으로는 이 시대를 버틸 수 없다는 사실이 명확해졌기 때문입니다.
AI가 할 수 없는, 오직 나만이 할 수 있는 역량은 무엇일까 고민하던 중 이 책에서 한 단어를 발견했습니다. 바로 ‘암묵지’입니다.
암묵지: 오랜 경험, 학습, 노하우를 통해 개인에게 체화되어 말이나 글로 표현하기 어려운 주관적인 지식
아직 어떤 코드나 위키 문서에 정리되어 있지 않은 이 지식은 당분간 AI가 학습할 수 없는 영역일 것입니다. 그렇다면 이 암묵지는 AI의 공세에 대항하는 ‘버티기 위한 방편’에 머물 수도, 아니면 AI를 발판 삼아 더 크게 나아가기 위한 ‘지렛대’가 될 수도 있습니다.
만약 암묵지를 그저 버티기용으로만 쓴다면, 자칫 고인물의 권위로 작동할 수 있습니다. 본인만 아는 맥락을 상대방도 당연히 알 거라 착각하며 소통하기 시작하면, AI는 물론이고 옆 자리 동료조차 내 말을 알아듣지 못하게 됩니다. 그 고립 속에서 ‘나는 여전히 이대로도 충분히 잘하고 있다‘라는 위안에 빠져 관성적으로 살다 보면, 역량은 박제되고 저는 시대 뒤편으로 밀려나게 될겁니다.
암묵지는 무의식적인 숙련의 영역이지만, 그것을 왜 아는지 설명하기 시작할 때 비로소 내가 진짜 아는지 아니면 아는 척하는지가 판가름 납니다. 저자 중 한 명은 ‘낯선 방법으로 문제에 다가가 보라’고 조언합니다. 저는 이를 익숙한 도메인을 역설계(Reverse Engineering)하는 관점으로 받아들였습니다. 늘 당연하게 여겼던 프로세스를 해제하여 그 속에 숨은 ’왜‘를 찾아내는 것. 그렇게 내 머릿속 암묵지를 형식지로 끌어올려 동료와 나눌 수 있는 지식으로 재구성할 때, 역설적으로 AI가 흉내낼 수 없는 나만의 ‘진짜 지분’이 생겨날 것입니다.
이 책에는 ‘제어할 수 없는 것에 의존하지 않기’라는 원칙이 나옵니다. 저의 코드나 아키텍쳐, 프로젝트 일정 등은 어느 정도 제어할 수 있지만, 갑작스러운 조직 개편이나 경영진들의 결정들은 명백히 제 권한 밖의 일입니다. 문제는 제가 여전히 이런 외부 변수에 기분이 좌지우지 된다는 사실입니다. 이런 상황을 무방비하게 맞닥뜨릴때면 허탈해지면서 무력함과 회의감마저 드니까요.
조직의 의사결정이 항상 제가 바라는 방향과 일치하기는 어렵다는 걸 머리로는 알지만, 마음은 여전히 흔들립니다. 코드를 짤 때는 특정 요인에 의존하지 않는 독립적인 아키텍쳐를 추구하면서, 정작 제 삶에는 이 원칙이 적용되지 않는 게 아이러니 합니다.
잠시 멍하니 있다가 한숨을 내쉬고, 제가 ‘진짜’ 제어할 수 있는 영역으로 시선을 돌려봅니다. 나에게 할당된 업무의 완성도, 팀의 기술 부채를 해결하는 과정, 그리고 나만의 일상 루틴들. 이것들이야말로 제가 오롯이 효능감을 느낄 수 있는 것들입니다. 이는 무력감에서의 도피가 아닙니다. 외부 변수가 내 삶으로 전파되지 않도록 하는 시스템적인 격리에 가깝습니다.
개발자라는 직업의 장점은 ‘절이 싫으면 중이 떠나면 된다’는 속담을 실현하기 쉽다는 겁니다. 물론 지금의 채용 시장은 얼어붙어 있지만, 내가 제어할 수 있는 영역에 집중하며 자기 경영에 능숙해진다면 언제나 다른 선택지는 찾을 수 있지 않을까라는 희망이 여전히 있습니다.
다시 처음 질문으로 되돌아가봅니다. ’나는 무엇을 할 수 있는 사람인가?‘
이 책에서 그 정답을 찾을 수 있지 않을까 기대를 했었지만, 새롭고 흥미진진한 은탄환*같은 정답은 없었습니다. 각자 다른 직장에서, 다른 패러다임을 느끼며 살고 있으니 어쩌면 당연한 결과일지도 모르겠습니다.
그래도 한 가지 위안이 남기는 했습니다. 저보다 경력이 오래된 개발자들이 쓴 각자의 원칙이 어떤 화려한 해피엔딩으로 귀결되지는 않더군요. 오히려 저와 똑같은 고민을 하고 있었고, 나름의 해답을 내리며 살고 있다는 사실 자체가 위안이 되었습니다. 환경이 어떠하든 결국 개발자에게, 한 명의 직업인에게 남는 것은 나만의 ‘태도’였습니다.
마지막으로 마음에 새긴 원칙은 ’보이스카우트 원칙‘입니다. “떠날 때는 처음 왔을 때보다 조금 더 깨끗하게”. 거창한 성공이나 혁신을 꿈꾸기보다, 오늘 내가 만진 코드 한 줄, 내가 속한 이 팀의 업무 프로세스를 단 1%라도 낫게 만들고 하루를 마감하는 것. 그 사소하고 정직한 노력이 지금 제가 보여줄 수 있는 최선의 태도가 아닐까 싶습니다.
은탄환(Silver Bullet): 복잡한 문제를 단번에 해결할 수 있는 마법 같은 해결책. 소프트웨어 분야에서는 “모든 상황에 통하는 완벽한 해결책은 없다(No Silver Bullet)”라는 표현이 자주 쓰입니다.