우리는 세상을 너무 복잡하게 만들어 버렸다 - 개발자가 한번쯤 멈춰서 생각해볼 것들

왜 이 글이 마음에 남을까요?

개발 일을 하다 보면 가끔 이런 생각이 들 때가 있어요. "내가 지금 만들고 있는 이거, 정말 필요한 걸까?" 화면 하나 만드는 데 React, Next.js, TypeScript, Tailwind, ESLint, Prettier, Vite, pnpm, 그리고 수십 개의 라이브러리가 얽혀 들어가고, 백엔드는 Kubernetes 위에 마이크로서비스가 십수 개씩 떠 있고, 이걸 모니터링하려고 Datadog, Sentry, Grafana, Prometheus가 또 붙어 있죠. 글쓴이는 바로 이 지점에서 출발해요. "우리는 세상을 너무 복잡하게 만들어 버렸다" 고요.

이 글이 신선한 건 단순히 "옛날이 좋았다"는 감상이 아니라는 점이에요. 글쓴이는 우리가 왜 이렇게 복잡한 시스템을 만들게 됐는지, 그리고 그 복잡함이 정말 가치를 만들어 내고 있는지 차분하게 짚어 가거든요.

복잡함은 어떻게 쌓이는가

글의 핵심 통찰은 복잡함이 의도적으로 만들어진 게 아니라 "우연히 누적된다" 는 거예요. 처음에는 단순한 정적 HTML 페이지였던 게, 검색 기능을 추가하면서 자바스크립트가 들어오고, 사용자 로그인이 필요해지면서 데이터베이스가 붙고, 트래픽이 늘면서 캐시 레이어가 생기고, 모바일 대응 때문에 API 분리가 일어나죠. 각 단계는 다 합리적인 결정이었어요. 하지만 10년 뒤에 전체를 보면 누구도 이해할 수 없는 미궁이 되어 있어요.

글쓴이는 이걸 "누구도 책임지지 않는 복잡함" 이라고 불러요. 이게 뭐냐면, 어떤 한 사람이 "이거 너무 복잡한데?"라고 말할 수 있는 시점이 영원히 안 오는 거예요. 왜냐하면 매 순간의 결정은 다 합리적이었거든요. 새 라이브러리 하나 도입하는 건 그 자체로는 작은 결정이에요. 그런데 그런 작은 결정 수백 개가 모이면 거대한 늪이 되죠.

추상화의 역설

흥미로운 건 우리가 복잡함을 줄이려고 만든 도구들이 오히려 복잡함을 늘리는 경우가 많다는 거예요. 예를 들어 Kubernetes는 서버 관리의 복잡함을 추상화해서 단순하게 만들어 주려고 나왔어요. 그런데 실제로 Kubernetes를 도입하면 YAML 파일 수십 개, Helm 차트, Operator, Ingress 컨트롤러, CNI 플러그인, RBAC 정책 같은 새로운 복잡함이 생겨나죠.

이걸 "leaky abstraction" 이라고 불러요. 한국말로 하면 "새는 추상화" 정도가 되는데, 추상화는 본래 아래쪽의 복잡한 디테일을 가려주는 역할을 해야 하지만 실제로는 그 디테일이 위로 새어 나와서 사용자가 결국 둘 다 알아야 하는 상황이 벌어진다는 의미예요. ORM을 쓰지만 결국 SQL을 알아야 하고, Docker를 쓰지만 리눅스 네임스페이스도 알아야 하는 식이죠.

그럼 단순함은 어떻게 회복하나요?

글쓴이가 제안하는 건 거창한 게 아니에요. 일단 "이게 정말 필요한가" 라고 매번 물어보는 습관이에요. 새 라이브러리를 추가하기 전에, 새 마이크로서비스를 분리하기 전에, 새 추상화 레이어를 만들기 전에 한번씩 멈춰서 생각해 보자는 거죠. 그 결정이 미래에 누군가에게 부담이 될 거라는 걸 인식하면서요.

그리고 "빼는 것도 일" 이라는 인식이에요. 우리는 보통 코드를 추가하거나 기능을 더하는 걸 일이라고 생각하지, 빼거나 단순화하는 걸 일로 인정해주지 않잖아요. JIRA에 "이번 스프린트에 라이브러리 3개 제거함"이라고 적으면 매니저가 좀 갸우뚱할 수도 있고요. 하지만 빼는 작업이야말로 진짜 가치를 만든다는 거예요.

업계 흐름에서 보면

이런 목소리가 최근 들어 부쩍 늘었어요. DHH(Ruby on Rails 창시자)는 'Once' 시리즈로 SaaS 시대의 거품을 빼자고 외치고 있고, Pieter Levels 같은 인디 해커들은 PHP와 SQLite로 수십만 달러 매출을 내는 단순한 서비스를 만들어서 보여주고 있죠. "Stop using Kubernetes", "You don't need microservices" 같은 글들도 꾸준히 화제예요.

Go 언어의 단순함 철학, Hotwire나 HTMX 같은 "자바스크립트 줄이기" 라이브러리의 부상, 그리고 SQLite 같은 임베디드 DB의 재평가 모두 같은 흐름이에요. 우리가 한동안 "더 분산된, 더 추상화된, 더 확장 가능한" 쪽으로만 달려왔다면, 이제는 "정말 그게 다 필요했나?"를 묻는 반작용이 일어나고 있는 거죠.

한국 개발자에게 주는 시사점

국내 개발 문화도 이 부분에서 자유롭지 못해요. 신입 채용 공고에 "K8s, Kafka, MSA, ELK, Redis 클러스터 경험자 우대"라고 적혀 있는 걸 보면, 정작 그 회사의 일일 활성 사용자가 만 명도 안 되는 경우가 흔하거든요. 트래픽 100 RPS도 안 되는 서비스에 마이크로서비스 10개를 띄워놓고 운영 인력은 셋이 전부인 상황도 자주 봐요.

주니어 분들에게 드리고 싶은 말씀은 화려한 스택을 좇기 전에 "왜 이 도구가 필요한가" 를 먼저 묻는 습관을 들이라는 거예요. 시니어가 되는 길은 새 기술을 빨리 익히는 것도 있지만, 언제 새 기술을 안 써야 하는지를 아는 것이 더 결정적이거든요. 그리고 사이드 프로젝트를 할 때 일부러 최소한의 도구만 써보는 경험도 강력 추천해요. SQLite와 단일 서버, 그리고 서버사이드 렌더링만으로 얼마나 많은 걸 할 수 있는지 직접 체감해 보면 관점이 완전히 바뀌어요.

마무리

복잡함은 적이 아니라 "필요할 때만 쓰는 도구" 가 되어야 해요. 트래픽이 정말 많아지면 분산 시스템을 도입하는 게 맞고, 팀이 정말 커지면 마이크로서비스로 나누는 게 맞아요. 하지만 그 시점이 오기 전에 미리 복잡함을 끌어안는 건 자기 발에 족쇄를 채우는 일과 같아요.

여러분이 지금 쓰고 있는 스택 중에 "사실 이거 없어도 되는데"라고 느끼는 게 있나요? 혹은 반대로, 단순한 구조로 시작했다가 정말 필요해서 복잡한 시스템으로 옮겨간 경험이 있나요? 단순함과 복잡함 사이의 균형, 여러분은 어떻게 잡고 계세요?