최근 개발자 커뮤니티에서 화제가 된 한 풍자 사이트를 보며 쓴웃음을 지었습니다. 'Worst of Breed'라는 이름의 이 페이지는 우리가 흔히 저지르는 기술적 허영심을 아주 적나라하게 비꼬고 있었기 때문입니다. "500줄짜리 PHP 스크립트를 12개의 마이크로서비스로 쪼개 쿠버네티스에 올렸더니 대기 시간은 4000% 늘었지만, 이력서 가치는 폭등했다"거나, "사용자 세션 데이터를 블록체인에 저장하는 것이야말로 진정한 탈중앙화"라는 식의 조롱 섞인 문구들이 나열되어 있었습니다. 솔직히 말해, 웃어넘기기엔 등골이 서늘했습니다. 10년 차 개발자로 일하며 제가 수습해야 했던 수많은 장애 상황들이 주마등처럼 스쳐 지나갔기 때문입니다. 우리는 종종 문제 해결이라는 본질을 망각하고, 그저 최신 기술을 써보고 싶다는 욕망, 혹은 내 이력서에 'MSA 경험 있음', 'Rust 사용 가능'이라는 한 줄을 추가하고 싶은 욕망에 사로잡혀 괴물 같은 소프트웨어를 만들어내곤 합니다. 이것이 바로 우리가 경계해야 할 '이력서 주도 개발(Resume-Driven Development, RDD)'의 실체입니다.
과거 금융권 차세대 프로젝트를 수행할 때의 일입니다. 당시 팀 내에는 '분산 시스템'에 대한 막연한 환상을 가진 주니어 개발자들이 많았습니다. 그들은 단순한 관리자 페이지조차 마이크로서비스로 분리하고, 불필요한 메시지 큐(Kafka)를 도입해 비동기 처리를 하겠다고 고집했습니다. 결과는 참혹했습니다. 데이터 정합성을 맞추기 위해 트랜잭션 관리는 기하급수적으로 복잡해졌고, 서비스 간 통신으로 인한 네트워크 레이턴시는 사용자 경험을 바닥으로 끌어내렸습니다. 소위 '분산 모놀리스(Distributed Monolith)'가 탄생한 것입니다. 단순히 함수 호출 한 번이면 끝날 일을 HTTP 요청으로 처리하다 보니, 장애 포인트는 늘어나고 디버깅은 미궁 속으로 빠져들었습니다. 코드는 자산이 아닙니다. 코드는 작성되는 순간부터 관리해야 할 '부채(Liability)'가 됩니다. 그런데 RDD에 빠진 개발자들은 이 부채를 자산이라 착각하고, 복잡도를 높이는 것을 자신의 실력이라고 믿는 오류를 범합니다.
주니어 개발자 여러분이 가장 먼저 갖춰야 할 태도는 '기술적 겸손'입니다. 트위터나 기술 블로그에서 유행하는 'Hot'한 기술 스택을 맹목적으로 좇지 마십시오. 투두(Todo) 앱을 만드는 데 블록체인이 필요하지 않고, 간단한 랜딩 페이지를 만드는 데 컴파일 시간이 40분이나 걸리는 Rust나 14MB짜리 번들을 만드는 마이크로 프론트엔드가 필요하지 않습니다. 여러분의 몸값은 얼마나 화려한 기술을 써봤느냐가 아니라, 비즈니스 요구사항을 얼마나 '적절한 비용'과 '안정적인 구조'로 해결했느냐에 따라 결정됩니다. 제가 신입 사원들의 코드를 리뷰할 때 가장 눈여겨보는 것은 그들이 사용한 라이브러리의 최신성이 아닙니다. "왜 이 기술을 선택했는가?"라는 질문에 대해 "남들이 다 쓰니까요"가 아닌, "현재 트래픽과 데이터 구조상 이 방식이 가장 유지보수 비용이 적기 때문입니다"라고 대답할 수 있는 논리적 근거입니다.
복잡성은 제품이 아닙니다. 복잡성은 우리가 피해야 할 악(Evil)입니다. 풍자 사이트에서 말하는 "단순함보다 복잡함(COMPLEXITY over Simplicity)"이라는 반어적 선언을 반면교사 삼아야 합니다. 당장 여러분의 프로젝트를 점검해 보십시오. YAML 설정 파일이 실제 비즈니스 로직 코드보다 더 길지 않습니까? 인프라를 구축하는 시간이 기능을 개발하는 시간보다 더 오래 걸리고 있지는 않습니까? 만약 그렇다면 여러분은 이미 'Worst of Breed'의 길을 걷고 있는 것입니다. 훌륭한 아키텍처는 이력서에 쓸 말이 많은 아키텍처가 아니라, 내가 회사를 떠난 뒤에도 후임자가 욕하지 않고 운영할 수 있는 아키텍처입니다. '지루한 기술'을 두려워하지 마십시오. 안정적으로 돌아가는 레거시 코드를 이해하고, 그것을 점진적으로 개선해 나가는 과정에서 진짜 실력은 쌓입니다. 부디 화려한 겉치레보다는 단단한 기본기를 무기 삼아, 이 험난한 IT 정글에서 '생존'하는 개발자가 되시길 바랍니다.
