나쁜 코드보다 무서운 것: 복잡성을 당연하게 여기는 개발 문화

소프트웨어가 느려지고 불안정해지면 대개 코드부터 탓합니다. 하지만 Casey Muratori가 BSC 2026에서 던진 화두는 한 걸음 더 들어갑니다. 문제의 뿌리가 복잡성을 당연하게 여기는 문화에 있을 수 있다는 겁니다.

복잡한 소프트웨어는 하루아침에 만들어지지 않습니다

“섣부른 최적화는 모든 악의 근원”이라는 유명한 문장이 있습니다. ‘Root of the Root of All Evil’은 그보다 더 앞에 있는 원인을 묻는 제목으로 읽힙니다.

복잡성은 대개 나름대로 합리적인 결정에서 출발합니다. 중복을 줄이려고 추상화 계층을 더하고, 확장에 대비해 인터페이스를 만듭니다. 협업을 수월하게 하려고 프레임워크와 도구를 들이기도 합니다.

하나하나 떼어놓고 보면 잘못된 선택은 아닙니다. 다만 이런 결정이 겹겹이 쌓이면서 문제가 생깁니다.

버튼 하나의 동작을 바꾸는 데 5개 계층과 12개 파일을 열어봐야 한다고 해봅시다. 코드 한 줄 한 줄은 단순할 수 있어도 전체 동작을 이해하는 일은 전혀 간단하지 않습니다.

복잡성을 좌우하는 건 코드 줄 수가 아닙니다. 개발자가 머릿속에 한꺼번에 담아두어야 할 관계의 수입니다.

추상화는 개발자가 자주 꺼내 드는 해법입니다. 복잡한 내부 구조는 감추고 간단한 인터페이스만 드러내는 방식입니다.

하지만 가려둔다고 복잡성까지 없어지는 건 아닙니다. 평소에 눈에 띄지 않을 뿐, 오류가 나면 개발자는 결국 감춰둔 계층을 하나씩 거슬러 내려가야 합니다.

화면의 체크박스 하나가 작동하지 않는다고 해봅시다. 원인은 UI 코드가 아니라 상태 관리 도구나 데이터 변환 계층에 있을 수 있습니다. 네트워크 캐시 또는 자동 생성 코드가 문제일 가능성도 있습니다.

이런 순간 추상화는 지름길이 아니라 미로가 됩니다. 스택 트레이스가 30단계를 넘어가면 “어디서 실패했는가”를 찾기 전에 “실제로 무엇이 실행됐는가”부터 조사해야 합니다.

그렇다고 추상화를 모조리 버리자는 뜻은 아닙니다. 따져봐야 할 것은 분명합니다. 이 계층이 덜어내는 복잡성이 새로 보태는 복잡성보다 정말 큰가 하는 점입니다.

개발 문화에서는 복잡한 설계를 전문성으로 착각하기 쉽습니다. 단순한 함수보다 범용 프레임워크가 더 대단해 보입니다. 의존성 하나를 걷어낸 사람보다 새로운 시스템을 들여온 사람이 더 많은 주목을 받기도 합니다.

조직의 평가 방식도 한몫합니다. 새 기능은 쉽게 성과로 기록됩니다. 반면 빌드 시간을 10분에서 3분으로 줄이거나 불필요한 계층을 없앤 일은 좀처럼 눈에 띄지 않습니다.

이런 환경에서는 복잡성을 더할 동기는 강하고, 덜어낼 동기는 약합니다.

결국 팀은 당장의 편의를 얻는 대신 미래에 치를 이해 비용을 끌어다 씁니다. 처음에는 개발 속도가 빨라진 듯 보입니다. 하지만 몇 년이 지나면 작은 변경 하나에도 회의와 문서, 테스트, 배포 조율이 따라붙습니다.

이 현상은 기술 부채라는 말만으로 충분히 설명하기 어렵습니다. 빚이라기보다 복잡성에 대한 집단적 무감각에 더 가깝기 때문입니다.

복잡성을 줄이려면 “코드를 깔끔하게 쓰자”는 구호만 외쳐서는 안 됩니다. 팀이 실제로 겪는 비용부터 측정해야 합니다.

새 개발자가 첫 수정 사항을 배포하기까지 며칠이 걸리는지 살펴볼 수 있습니다. 함수 하나를 바꿀 때 영향을 받는 모듈은 몇 개인지, 장애 원인을 찾는 데 얼마나 걸렸는지도 확인해볼 만합니다. 빌드 시간과 의존성 수도 빼놓을 수 없습니다.

특히 변경 증폭을 눈여겨봐야 합니다. 요구사항 하나를 바꿨을 뿐인데 테스트와 설정을 포함해 20곳을 손봐야 한다면 구조에 문제가 있다는 신호입니다.

좋은 설계는 모든 미래를 내다보려 하지 않습니다. 우선 오늘의 요구사항을 분명하게 해결하고, 내일의 개발자가 코드를 읽고 고칠 수 있는 여지를 남깁니다.

필요해졌을 때 계층을 더하는 건 어렵지 않습니다. 반면 이미 곳곳에 퍼진 계층을 걷어내는 일은 훨씬 어렵습니다.

이 주제를 둘러싼 최근 커뮤니티의 열기를 숫자로 부풀려 말해서는 안 됩니다. 2026년 8월 최근 30일 동안 확인된 Reddit 논의는 0건이었습니다. 추천 수나 댓글을 근거로 대세 의견을 만들어낼 수 없는 이유입니다.

그래도 개발 현장에서 되풀이되는 반론은 익숙합니다. “현실의 문제 자체가 복잡한데 어떻게 단순하게 만드느냐”는 주장입니다. 일리 있는 지적입니다.

다만 구분할 것은 있습니다. 문제의 본질적 복잡성과 도구·관습·조직이 보탠 복잡성은 같은 것이 아닙니다. 전자는 피하기 어렵지만 후자는 여러 선택이 쌓인 결과입니다.

Casey Muratori의 도발이 여전히 유효한 이유도 여기에 있습니다. 나쁜 코드는 고칠 수 있지만, 복잡성을 전문성으로 인정하는 문화는 좀처럼 바뀌지 않습니다.

새로운 기술을 도입하기 전에는 한 번쯤 물어봐야 합니다. 이 선택이 문제를 단순하게 만드는지, 아니면 복잡성을 그저 익숙한 모습으로 포장하는지. 여러분의 팀은 복잡한 시스템을 잘 다루는 사람과 불필요한 복잡성을 없애는 사람 중 누구를 더 높이 평가하고 있습니까?