솔직히 고백하겠습니다.
저는 지난 7년 동안 작은 스타트업에서 '야생형 개발자'로 살았습니다.
기능이 동작하면 장땡이었고, 새벽 2시에 터진 서버를 다시 띄우는 게 훈장인 줄 알았죠.
그러다 최근 체계가 잡힌 대기업으로 이직하고 나서야 깨달았습니다.
제가 그동안 '나침반 없이 망망대해를 항해했다'는 사실을요.
오늘은 제가 뼈저리게 느낀 '개발자의 나침반' 이야기를 해보려 합니다.
얼마 전, 유튜브 알고리즘이 뜬금없이 나침반 영상을 추천해주더군요.
"1936년 이후 최초의 새로운 나침반"이라는 제목이었습니다.
처음엔 "무슨 2024년에 나침반이야?" 하며 코웃음 쳤습니다.
우리에겐 GPS가 있고, 구글 지도가 있으니까요.
그런데 내용을 들여다보다가 뒤통수를 한 대 맞은 기분이었습니다.
이 새로운 나침반은 단순히 '북쪽'만 가리키는 게 아니었습니다.
기존 나침반은 자북(Magnetic North)을 가리키지만, 우리가 진짜 가야 할 곳은 진북(True North)이잖아요?
그 미세한 오차를 보정하고, 사용자가 걷는 속도와 지형까지 계산해서 '진짜 가야 할 방향'을 직관적으로 보여준다는 겁니다.
문득 제 주니어 시절이 떠올랐습니다.
스타트업 초기, 트래픽이 갑자기 튀었을 때였어요.
급하게 MSA(Microservices Architecture)를 도입하자고 팀원들을 설득했죠.
"넷플릭스도 한다더라", "이게 요즘 트렌드다"라면서요.
팀장님은 인프라 리소스도 부족하고 운영 인력도 없다고 말렸지만, 저는 '기술적 힙함'에 취해 있었습니다.
결과는 어땠을까요?
처참했습니다.
분리된 서비스 간 통신 장애가 빈번했고, 로그 트레이싱은 악몽이었습니다.
간단한 배포 하나 하려고 해도 파이프라인이 꼬여서 밤을 새웠죠.
저는 '북쪽(기술 트렌드)'만 보고 달렸던 겁니다.
우리 팀이 지금 어디에 서 있는지, 비즈니스 속도는 어떤지 전혀 고려하지 않았던 거죠.
대기업에 와서 가장 먼저 배운 건 코드를 잘 짜는 법이 아니었습니다.
바로 '맥락(Context)'을 읽는 법이었습니다.
여기 시니어 분들은 무조건 최신 스택을 고집하지 않더군요.
오히려 10년 된 레거시 코드를 존중합니다.
"이 코드가 왜 여기서 이렇게 돌고 있는지" 그 히스토리를 먼저 파악하죠.
최근 저희 팀에서 사내 검색 엔진을 개편할 때였습니다.
저는 당장이라도 ElasticSearch 최신 버전으로 올리고, RAG(검색 증강 생성)를 붙여서 AI 기능을 넣자고 제안하고 싶어 입이 근질거렸습니다.
하지만 팀 리드님은 달랐습니다.
"지금 고객들이 검색에서 가장 불만인 게 정확도일까, 아니면 속도일까?"
로그를 뜯어보니 문제는 검색 결과가 늦게 뜨는 '레이턴시'였습니다.
화려한 AI 기능보다 당장 쿼리 튜닝과 캐싱 전략을 수정하는 게 급선무였죠.
그게 바로 우리 팀의 '진북(True North)'이었던 겁니다.
요즘 개발자 커뮤니티를 보면 다들 불안해합니다.
"AI가 코딩 다 해준다는데 우린 뭐 먹고 사냐"
"Cursor나 Claude 같은 도구 안 쓰면 도태된다는데..."
저도 처음엔 겁이 났습니다.
실제로 Copilot이 제 코드의 40% 이상을 작성해주고 있으니까요.
하지만 나침반 이야기를 다시 곱씹어 봅니다.
기술은 계속 변합니다. 나침반의 바늘처럼 끊임없이 흔들리겠죠.
하지만 '우리가 어디로 가야 하는지' 결정하는 건 결국 사람입니다.
AI는 기가 막히게 코드를 짜주지만, "이 기능을 지금 개발하는 게 비즈니스에 도움이 될까?"라는 질문에는 답하지 못합니다.
그 판단은 '야생에서 구르고, 레거시와 싸워본' 우리만이 할 수 있습니다.
8년 차가 된 지금, 저는 더 이상 기술 스택 자체에 집착하지 않습니다.
대신 이런 질문들을 던집니다.
"이 코드가 동료들의 퇴근 시간을 지켜줄 수 있는가?"
"이 아키텍처가 1년 뒤에도 유지보수 가능한가?"
"우리가 만드는 기능이 고객의 지갑을 열게 하는가?"
이것이 제 새로운 나침반입니다.
여러분은 지금 어디를 보고 계신가요?
혹시 무작정 남들이 좋다는 '북쪽'만 보고 달리고 있진 않으신가요?
잠시 멈춰서, 내 발밑과 동료들의 얼굴을 한번 둘러보세요.
진짜 방향은 그곳에 있을지도 모릅니다.
