모든 코드가 엉망이고 배포마저 실패했을 때, 맨땅에서 비즈니스를 살려내는 3가지 생존 법칙

솔직히 말해서, 저는 '우아한 코드'나 '완벽한 아키텍처'라는 말을 들으면 아직도 속이 뒤틀립니다. 청주에서 대학을 나오고 국비 지원 학원을 수료한 뒤, 제 첫 직장은 월급이 세 달이나 밀린 웹 에이전시였습니다. 그곳은 전쟁터였습니다. 사수는 도망갔고, 남겨진 건 스파게티처럼 엉킨 레거시 코드와 독촉 전화뿐이었습니다. 그때 저는 깨달았습니다. 개발자의 본질은 코드를 예쁘게 짜는 예술가가 아니라, 어떻게든 시스템을 굴러가게 만드는 생존 전문가여야 한다는 것을 말입니다. 오늘 해드릴 이야기는 1979년 동독에서 일어난 한 사건입니다. 컴컴한 밤, 두 가족이 직접 만든 열기구를 타고 목숨을 걸고 국경을 넘은 이 이야기는, 막막한 레거시 시스템 앞에서 절망하는 우리들에게 가장 확실한 엔지니어링 교훈을 줍니다.

1979년 동독의 피터 스트렐지크와 귄터 베첼은 낭만적인 모험가가 아니었습니다. 그들은 전기 기술자와 벽돌공이었고, 그저 감옥 같은 현실을 탈출하고 싶었던 평범한 가장들이었습니다. 그들이 처한 상황은 우리가 마주하는 최악의 프로젝트와 닮아 있었습니다. 리소스는 턱없이 부족했고(엔진을 구할 수 없음), 관리 감독은 살벌했으며(슈타지의 감시), 실패의 대가는 해고가 아니라 죽음이었습니다. 그들은 처음에 헬리콥터를 만들려다 포기하고 열기구로 방향을 틀었습니다. 여기서 첫 번째 교훈이 나옵니다. 그들은 이상적인 기술 스택(헬리콥터)에 집착하지 않고, 당장 구현 가능한 솔루션(열기구)으로 피벗했습니다. 우리가 현업에서 화려한 MSA(Microservices Architecture)나 최신 라이브러리를 고집하다가 프로젝트를 망치는 것과 대조적입니다. 생존을 위해서는 기술적 허영심을 버리고, 지금 당장 작동하는 '더러운 방법'을 택할 용기가 필요합니다.

하지만 그들의 첫 시도는 처참하게 실패했습니다. 15미터가 넘는 천을 꿰매어 풍선을 만들었지만, 공기가 너무 많이 샜습니다. 우리가 흔히 겪는 '메모리 누수'나 '트래픽 과부하로 인한 서버 다운' 같은 상황이었습니다. 850미터나 되는 천을 샀는데, 그게 다 쓸모없어진 겁니다. 보통의 주니어라면 여기서 포기하거나 "애초에 기획이 잘못됐다"며 남 탓을 했을 겁니다. 하지만 이들은 그 실패한 코드를—아니, 그 천을—모두 불태워 증거를 인멸하고 처음부터 다시 시작했습니다. 이것이 바로 '리팩토링'의 진정한 의미입니다. 단순히 변수명을 바꾸는 게 아니라, 근본적인 설계 결함을 인정하고 뼈를 깎는 고통을 감수하며 시스템을 갈아엎는 것입니다. 그들은 실패를 데이터로 받아들였고, 감정적으로 무너지지 않았습니다.

두 번째 시도에서 그들이 보여준 문제 해결 방식은 그야말로 '그로스 엔지니어링'의 정수입니다. 그들은 값비싼 장비 대신, 가정용 진공청소기와 물이 담긴 유리관을 이용해 천의 통기성을 테스트하는 장비를 직접 만들었습니다. 우산 천, 타프타, 나일론 등 온갖 샘플을 구해다가 일일이 A/B 테스트를 돌린 셈입니다. 또한 풍선을 부풀리기 위해 오토바이 엔진과 자동차 스타터, 그리고 난로 연통을 결합해 송풍기를 만들었습니다. 이건 교과서에 나오는 '클린 코드'가 아닙니다. 서로 다른 기종의 부품을 억지로 연결한, 전형적인 '덕트 테이프 엔지니어링'입니다. 하지만 그 조잡해 보이는 기계가 결국 2,000입방미터의 공기를 데워 8명의 목숨을 살렸습니다. 명문대 출신들이 이론적인 완벽함을 따질 때, 현장 출신들은 이렇게 있는 자원을 쥐어짜 내서 비즈니스 임팩트를 만들어냅니다.

마지막으로 그들이 보여준 것은 치밀한 리스크 관리와 실행력입니다. 슈타지의 의심을 피하기 위해 그들은 한곳에서 천을 사지 않고, 160km 떨어진 도시까지 이동해 분산 구매를 했습니다. 이는 트래픽이 몰릴 때를 대비해 로드 밸런싱을 하고, 단일 실패 지점(SPOF)을 없애는 분산 시스템 설계와 같습니다. 그리고 마침내 1979년 9월 16일 새벽 2시, 그들은 두려움을 억누르고 이륙했습니다. 비행시간은 고작 25분이었지만, 그 25분을 위해 1년 반을 준비했습니다. 개발자로서 우리는 종종 '배포' 버튼을 누르는 순간만을 기억하지만, 진짜 실력은 그 버튼을 누르기 전까지의 지루하고 고통스러운 디버깅 과정에서 나옵니다.

저도 에이전시 시절, 납기일 아침까지 버그를 잡지 못해 식은땀을 흘리던 밤이 있었습니다. 그때 저를 구원한 건 세련된 디자인 패턴이 아니라, 로그를 한 줄 한 줄 뜯어보며 하드코딩으로 막아낸 투박한 수정이었습니다. 여러분이 지금 다루는 레거시 코드가 혐오스러울 수 있습니다. 사수가 없어서 막막할 수도 있습니다. 하지만 기억하십시오. 피터와 귄터에게는 매뉴얼도, 스택오버플로우도 없었습니다. 그저 살아야겠다는 의지와 끊임없는 실험만이 있었을 뿐입니다. 지금 당신의 모니터 앞에 있는 그 '더러운 코드'가, 어쩌면 당신과 회사를 다음 단계로 데려다줄 열기구일지도 모릅니다. 불평을 멈추고, 일단 꿰매십시오. 그리고 불을 붙이십시오. 그게 우리가 살아남는 유일한 방법입니다.