닮고 싶은 개발자의 초상

내가 닮고 싶은 사람은 어떤 모습일까?

최근 내 머릿속은 온통 물음표로 가득했다. 새로 들어간 회사에서 코드는 어떻게든 돌아가게 만들고 있지만, 그 너머 ‘왜’에 대한 갈증은 좀처럼 해소되지 않았다. 팀의 시스템을 살피다 보면 수많은 질문이 꼬리에 꼬리를 물었다.

우리는 왜 마이크로서비스 아키텍처(MSA)와 쿠버네티스(k8s)를 사용하고 있을까? MSA의 장점을 얻으려는 과정에서 k8s라는 훌륭한 도구를 찾게 된 것일까, 아니면 k8s의 강력한 기능들을 활용하기 위해 MSA를 도입한 것일까? 마치 ‘닭이 먼저냐, 달걀이 먼저냐’와 같은 이 질문의 근본적인 출발점은 우리 아키텍처의 시작을 향한 궁금함이었다.

궁금증은 여기서 그치지 않았다. k8s가 애플리케이션 레벨의 장애를 감지하고 복구하는 데 뛰어나다는 것은 알고 있었다. 하지만 데이터베이스 연결이 끊기거나, 메시지 큐가 과부하에 걸리는 등 외부 시스템에서 문제가 발생했을 때, 우리의 시스템은 어떻게 안정성을 보장할까? 애플리케이션을 넘어 전체 서비스의 복원력에 대한 고민의 흔적을 찾고 싶어졌다.

더 나아가, 우리가 사용하는 이벤트 기반 아키텍처(EDA)가 사용자에게 과연 정말로 ‘빠른’ 서비스를 제공하고 있는지도 의문이었다. 이벤트 브로커를 거치는 이벤트 호출 방식은 모놀리식 아키텍처의 인메모리 통신에 비해 필연적으로 응답 시간의 오버헤드가 발생할 텐데, 그럼에도 우리는 ‘빠름’이란 것을 얻었을까? 여기에 단순 응답 속도 외에 다른 가치가 있는 것일까? 그렇게 우리 팀이 성능 최적화를 위해 해온 고민들이 어떻게 프로젝트에 녹아 있는지도 알고 싶었다.

기술 블로그를 찾아보고, 관련 서적을 뒤적여 봐도 이런 질문들에 대한 명쾌한 답을 찾을 수 없었다. 내게 필요했던 것은 인터넷에 떠도는 일반적인 지식이 아니었기 때문이다. 바로 이 코드 베이스에 깃든, 우리 팀만의 구체적인 ‘역사’와 ‘맥락’이었다.

‘너무 기초적인 질문이라 귀찮게 하는 건 아닐까?’, ‘이런 것도 모른다고 생각하면 어떡하지?’. 싹튼 질문들을 바쁜 선배에게 던져도 될지 하루에도 수십 번 망설였다. 분주하게 키보드를 두드리는 뒷모습을 보며, 내 질문이 그의 중요한 업무 흐름을 방해하지 않을까 싶은 생각에 쉽사리 연락할 수 없었다. 질문을 담은 DM을 쓰고도 보낼까 말까 한참을 고민했다.

하지만 성장에 대한 갈망이 결국 두려움을 이겼다. 어쩌면 이는 단순히 기술적 궁금증을 해소하기 위함만은 아니었다. 나는 무의식적으로 묻고 있었는지도 모른다. ‘이곳에 내가 궁금한 것을 편하게 물어볼 수 있는 동료가 있을까?’, ‘내가 닮고 싶은 사람은 어떤 모습일까?’ 하고 말이다.

‘보내기’ 버튼을 누르고 얼마 지나지 않아 그의 답변이 도착했다. “이따가 커피 한잔하면서 이야기할까요?” 짧은 문장이었지만, 그 안에는 존중이 담겨 있었다. 안도감을 넘어, 내 호기심이 가치 있는 것으로 인정받았다는 느낌에 가슴이 벅찼다. 그날의 커피 한 잔은 내게 많은 것을 생각하게 했고, 나는 비로소 어떤 사람으로 성장하고 싶은지에 대한 희미한 그림을 선명하게 만들 수 있었다.

현실을 외면하지 않는 정직함

내가 닮고 싶은 사람은 현실을 직시하고, 주어진 조건 속에서 길을 찾는 정직함을 가진 사람이다.

음료를 앞에 두고 마주 앉아, 나는 조심스럽게 준비한 질문들을 꺼내 놓았다. 그중에서 가장 궁금했던 “닭이 먼저냐, 달걀이 먼저냐” 식의 질문, 즉 MSA와 k8s의 도입 배경에 대해 그는 기술 선택 과정을 미화하거나 포장하지 않았다. “주어진 기술 요구사항에 따라 MSA와 k8s 환경을 기반으로 프로젝트가 기획되었어요.”

자칫하면 그 한마디로 모든 설명이 끝날 수도 있었다. 하지만 그는 거기서 멈추지 않고, 주어진 요구사항을 ‘어떻게 우리 기술로 만들었는가’에 대한 이야기로 대화를 이끌었다. 이상적인 아키텍처를 그리는 것과 정해진 조건 속에서 현실적으로 동작하는 시스템을 만들어 내는 것 사이의 거대한 틈. 그는 그 틈을 메우기 위해 팀이 어떤 노력을 했는지, 이를테면 복잡한 k8s 환경을 기존 환경에 재현하기 위해 어떤 시행착오를 겪었는지, k8s의 문제를 해결하기 위해 며칠 밤을 새워가며 디버그했는지, 그 과정을 마치 한 편의 서사시처럼 생생하게 들려주었다.

이는 단순한 변명이 아니었다. 주어진 제약 속에서 최선의 길을 찾아내고, 기술적 주도권을 가지고 문제를 해결해 나간 엔지니어의 정직한 회고였다. 나는 그의 이야기로 뛰어난 엔지니어란 이상적인 환경에서 완벽한 결과물을 만드는 사람이 아닌 불완전한 현실 속에서 최적의 해답을 찾아내는 사람이라는 것을 깨달았다. 그의 정직함은 기술적 선택에 대한 불만을 늘어놓는 것보다는 그 제약 안에서 우리가 무엇을 배우고 성취했는지를 담담하게 공유하는 성숙한 태도로 다가왔다.

경험에서 우러나오는 깊이

내가 닮고 싶은 사람은 경험으로 얻은 살아있는 통찰을 가진 사람이다.

대화는 자연스럽게 더 깊은 곳으로 흘러갔다. 그는 MSA와 k8s를 직접 구축하고 운영하며 느꼈던 점들을 상세히 이야기해 주었다. 특히 우리의 대화는 “추상화 수준이 높으면 높을수록, 그 복잡성은 사라지는 게 아니라 단지 보이지 않는 곳으로 숨겨질 뿐이다”라는 지점에서 큰 공감대를 형성했다. k8s와 같은 높은 수준의 추상화는 분명 개발자에게 많은 편리함을 주지만, 그 이면에서는 무슨 일이 일어나는지 파악하기 어렵게 만들고, 문제가 발생했을 때 근본 원인을 찾는 일을 더 복잡하게 만든다는 것이었다.

나 역시 간단한 버그 하나를 잡기 위해 여러 서비스에 흩어진 로그를 뒤지며 하루를 꼬박 보낸 막막한 경험이 있었다. 그의 말은 당시 느낀 내 답답함의 이유를 명확하게 찾아주었다. 막연히 ‘편리하다’고만 생각했던 기술의 이면에는 그만큼의 책임과 관리 비용이 따른다는 사실을 그의 경험으로 절감했다.

이것은 책이나 문서에서는 결코 배울 수 없는, 실제 시스템의 장애와 함께 밤을 새워 본 사람만이 건넬 수 있는 살아 있는 지식으로 느껴졌다. 나아가 그는 단순히 기술의 단점을 나열하는 데 그치지 않았다. 그럼에도 우리가 왜 이 기술을 선택해야 했는지, 그 트레이드오프를 감수하면서 얻는 이점은 무엇인지에 대한 균형 잡힌 시각을 제시했다. 그의 이야기는 내게 기술을 바라보는 새로운 시각, 즉 빛과 그림자를 함께 볼 수 있는 깊이를 선물해 주었다.

앎을 뽐내지 않는 겸손함

내가 닮고 싶은 사람은 끊임없이 배우고, 자신의 앎을 뽐내지 않는 겸손함을 가진 사람이다.

도메인 주도 설계(DDD)와 MSA 이야기로 이어졌을 때, 나는 그의 또 다른 모습을 발견했다. 그는 결코 모든 것을 아는 전문가처럼 행세하지 않았다. 오히려 “저도 DDD는 계속 공부하고 있어요”라거나 “MSA를 제대로 구현하는 방법은 정말 다양해서 늘 새로운 접근법을 찾아보고 있습니다”와 같이 솔직한 모습을 보여주었다.

나는 연차와 실력이 쌓일수록 자신의 지식을 과시하고 싶어지기 마련이라고 생각했다. 하지만 그는 자신의 지식에 경계선을 긋지 않았고, 언제나 배울 것이 남아 있다는 열린 자세를 보여주었다. 그에게 기술은 정복해야 할 대상이 아니라 끝없이 탐구해야 할 거대한 바다 같아 보였다.

우리는 이어 MSA 환경에서 하나의 큰 도메인을 작은 단위인 마이크로서비스로 쪼갤 때, 어떻게 도메인을 분해할 것인지에 대해 깊이 있는 이야기를 나누었다. 그 대화는 일방적인 가르침이 아닌 같은 주제에 대해 고민하는 두 명의 엔지니어가 서로의 생각을 나누는 편안한 토론의 장이었다. 주니어인 나의 앞에서도 모르는 것을 모른다고 말할 용기, 그리고 끊임없이 배우려는 그 겸손한 자세야말로 그의 깊이를 더욱 단단하게 만드는 진정한 힘이었다.

성장을 이끄는 단단한 울타리

내가 닮고 싶은 사람은 주니어가 두려움 없이 질문하고 성장할 단단한 울타리, 즉 ‘심리적 안정감’을 만들어 주는 사람이다.

돌이켜보면 내가 유독 그에게 그토록 길고 어려운 질문을 던질 수 있었던 이유는, 그가 내 질문의 수준을 평가하거나 비난하지 않을 것이라는 막연한 믿음이 있었기 때문이다. 만약 내 질문에 조금이라도 귀찮아하는 기색을 보이거나 가볍게 여겼다면 나는 다시는 용기를 내지 못했을 것이다.

“커피 한잔하자”는 그의 말은 내게는 단순한 친절 이상의 의미였다. 그것은 ‘당신의 질문은 충분히 가치가 있고, 나는 당신의 성장에 관심이 있다’는 존중의 표현으로 다가왔다. 그렇게 만난 그는 정답을 가르쳐주는 사람이 아니라, 질문으로 가는 길을 함께 걸어주는 사람이었다. 그는 내 질문에 답하면서도 늘 “이에 대해 어떻게 생각하세요?”라며 나의 의견을 되물어 주었다.

이런 상호작용은 나를 단순한 지식을 수용해야 하는 사람이 아닌 대화의 주체로 만들어 주었다. 그가 만들어준 것과 같은 심리적 안정감이라는 울타리 안에서야 주니어는 비로소 마음껏 헤매고, 실패하고, 질문하며 성장할 수 있다. 기술적인 지식보다 더 중요한 것은 어쩌면 함께 일하는 동료에게 이런 믿음을 주는 일일지도 모른다.

좋은 질문을 품게 만드는 힘

그와 나눈 대화 이후 나는 세상을 조금 다르게 보기 시작했다. 무엇보다 더는 코드의 작동 여부에만 매달리지 않게 되었다. 그전까지 나의 목표는 ‘주어진 기능을 문제없이 구현하는 것’이었다. 하지만 이제는 ‘이 기능이 해결하려는 진짜 문제는 무엇일까?’, ‘이 아키텍처가 만들어진 배경에는 어떤 비즈니스 요구사항이 있었을까?’와 같은 근본적인 질문을 스스로에게 던지기 시작했다. 단순히 지식의 전달을 넘어 문제를 바라보는 관점 자체가 바뀐 것이다.

이처럼 내가 닮고 싶은 사람과의 대화는 정답을 알려주는 것이 아니라 좋은 질문을 품게 만들었다. 그 좋은 질문이야말로 개발자를 성장시키는 가장 강력한 동력이다. 그는 내게 물고기를 잡아준 것이 아니라 좋은 낚싯대를 고르는 법과 깊은 바다를 두려워하지 않는 법을 알려주었다.

나도 그런 ‘시니어’가 되고 싶다

한 번의 대화였지만, 그날의 경험은 나를 조금 바꿔놓았다.

나는 이제 기술 자체에 매몰되기보다, 그 기술이 무슨 문제를 해결하기 위해, 어떤 현실적인 제약과 맥락 속에서 선택되었는지 먼저 생각하는 습관을 가져보기로 했다. 또, 지식은 문서로 전수될 수 있지만, 지혜와 태도는 사람을 통해서만 전해진다는 것을 깨달았다.

무엇보다 나는 그에게서 기술과 사람을 함께 아우르는 ‘시니어’의 모습을 보았다. 현실을 정직하게 마주하고, 경험에서 얻은 통찰을 겸손하게 나누며, 동료가 성장할 수 있는 안전한 환경을 만들어주는 모습. 그것은 내가 닮고 싶은 사람의 모습이었다.

언젠가 경력이 쌓여 누군가의 선배가 되었을 때를 생각해 본다. 나도 지금의 나처럼 수많은 물음표 속에서 용기를 낸 동료에게 “커피 한잔할까요?”라고 먼저 손 내밀 수 있는 사람이 되고 싶다. 그 짧은 시간이 누군가의 인생에 잊지 못할 이정표가 될 수 있다는 것을 이제는 알기 때문이다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.