최근 흥미로운 기사 하나를 읽었습니다. 영하 50도의 극한 추위로 유명한 시베리아 야쿠츠크에서, 강 위에 떠 있는 선박의 밑바닥을 수리하는 방식에 대한 이야기였습니다. 변변한 드라이독(Dry-dock, 선박을 물에서 끌어올려 수리하는 시설)이 없는 탓에, 작업자들은 얼어붙은 강 표면의 얼음을 전기톱으로 썰어냅니다. 얼음을 걷어내고, 물이 다시 얼기를 기다렸다가, 또 한 겹을 썰어내는 방식을 반복하여 마치 계단식 참호를 파듯 선박의 프로펠러에 접근합니다. 이 과정은 몇 주가 걸리며, 자칫 얼음이 깨지거나 계산이 틀리면 영하의 강물에 빠질 수 있는 목숨을 건 작업입니다. 이 장면을 보며 저는 문득 제 스타트업 시절의 모습이 떠올라 등골이 서늘해졌습니다.
솔직히 고백하자면, 저도 한때는 '야생'에서 코드를 짰습니다. 갓 3년 차였던 시절, 트래픽은 폭주하는데 배포 파이프라인은 툭하면 터졌고, 급한 마음에 운영 서버(Production)에 SSH로 직접 접속했습니다. Vim을 열어 실시간으로 코드를 수정하고 :wq를 누르던 그 순간의 짜릿함을 실력이라 착각했습니다. 마치 야쿠츠크의 작업자들처럼, 시스템이라는 안전한 드라이독 없이 맨몸으로 문제라는 얼음을 깨부수며 전진했던 셈입니다. 당시에는 그게 '민첩함(Agility)'인 줄 알았고, 남들이 못 하는 핫픽스를 해내는 제가 꽤 멋있다고 생각했습니다. 하지만 지금 대규모 트래픽을 다루는 조직에 와서 보니, 그것은 용기가 아니라 '만용'이었고, 시스템의 부재를 개인의 희생으로 때우는 가장 미련한 방식이었음을 뼈저리게 느낍니다.
야쿠츠크의 방식은 '생존'을 위해서는 훌륭할지 몰라도 '성장'과 '확장'을 위해서는 최악의 선택입니다. 얼음을 깨서 수리하는 방식은 확장 불가능(Non-scalable)합니다. 배가 100척으로 늘어나면 작업자들은 모두 동상에 걸리거나 과로로 쓰러질 것입니다. 소프트웨어 개발도 마찬가지입니다. MSA(마이크로서비스 아키텍처)로 서비스가 파편화되고 컨테이너가 수백 개로 늘어나는 상황에서, 문제가 생길 때마다 개발자가 직접 로그를 뒤지거나 라이브 패치를 감행하는 것은 불가능합니다. 그런데도 여전히 많은 주니어, 심지어 미들급 개발자들조차 "일단 되게 하는 것"에만 매몰되어 테스트 코드 작성이나 CI/CD 파이프라인 구축 같은 '드라이독 건설'을 등한시합니다.
지금 당장 당신의 팀이 체계가 없어서, 혹은 레거시 코드가 너무 방대해서 어쩔 수 없이 수동 배포와 핫픽스를 반복하고 있을 수도 있습니다. 이해합니다. 저도 그랬으니까요. 하지만 명심해야 할 것은, 그 방식에 익숙해져서는 안 된다는 점입니다. 최근 Cursor나 Claude 같은 AI 코딩 도구들이 비약적으로 발전하고 있습니다. 이제 단순한 코드 작성이나 버그 픽스는 AI가 인간보다 더 빠르고 정확하게 해내는 시대가 오고 있습니다. 이런 상황에서 시스템을 설계하고 자동화된 안전장치를 만드는 능력이 없다면, 단순히 '손이 빠른 코더'는 설 자리가 없어질 것입니다. AI는 영하 50도의 얼음판 위에서도 지치지 않고 얼음을 깰 수 있거든요. 인간 개발자인 우리가 가져야 할 경쟁력은 얼음을 잘 깨는 기술이 아니라, 날씨와 상관없이 배를 수리할 수 있는 '드라이독'을 설계하는 능력입니다.
결국 '야생형 개발자'에서 '엔지니어'로 성장한다는 것은, 리스크를 몸으로 때우는 단계에서 시스템으로 제어하는 단계로 넘어가는 과정을 의미합니다. 오늘 내가 작성한 코드가 운영 서버에 올라가기까지, 나의 개입 없이도 수십 개의 테스트 케이스를 통과하고 자동으로 배포되는지 점검해보시기 바랍니다. 만약 아직도 터미널 창을 열어놓고 식은땀을 흘리며 수동으로 명령어를 입력하고 있다면, 지금이 바로 멈춰야 할 때입니다. 극한의 환경에서 살아남은 경험은 무용담이 될 수 있지만, 그것이 당신의 작업 표준이 되어서는 안 됩니다. 우리는 얼음 깨는 인부가 아니라, 시스템을 짓는 건축가가 되어야 하니까요.
