솔루션의 우아함

IT 분야에서 일하다 보면 크고 복잡한 솔루션에 집중하게 되기 쉽습니다. 좋은 솔루션은 바로 그런 곳에 있을 것처럼 보입니다. 큰 솔루션, 많은 소프트웨어, 최신 가젯들. 우리가 하는 일은 흥미롭고 그 흐름에 휩쓸리기 매우 쉽습니다. 도전적이고 규모 있는 프로젝트를 하는 것은 재미있습니다. 다른 IT 전문가들이 무엇을 하고 있는지, 다른 기업들이 어떻게 문제를 해결하는지 듣고, 대형 시스템을 판매하려는 벤더들과 대화하다 보면 흥분감이 더해지고, 범위와 목표 의식을 잃기 쉬우며, 단순한 문제에 과도하고 복잡한 솔루션을 적용하는 사례를 너무 자주 보다 보면 이것이 바로 IT의 방식인 것처럼 느껴집니다.

하지만 꼭 그럴 필요는 없습니다. 복잡성은 신뢰성과 보안 모두의 적입니다. 불필요하게 복잡한 솔루션은 도입 및 구현 비용과 유지보수 비용을 높이고, 일반적으로 더 느리고 더 취약하며, 이해하고 보호하기 어려운 넓은 공격 표면을 가지고 있습니다. 단순한, 혹은 더 적절하게 표현하자면 우아한 솔루션이 최선의 접근법입니다. 이것이 모든 설계가 단순해야 한다는 의미는 아닙니다. 전혀 그렇지 않습니다. 복잡한 설계가 필요한 경우도 많습니다. IT는 복잡성이 부족한 분야가 결코 아닙니다. 실제로 소프트웨어 개발이 인간의 모든 활동 중 가장 복잡한 분야일 수 있다고 여겨지기도 합니다. 적어도 어느 정도 규모로 수행되는 것들 중에서는요. 일반적인 IT 환경에는 수백만 줄의 코드, 수백에서 수천 가지의 프로토콜, 수많은 상호 연결된 시스템, 고유한 소프트웨어 구성의 여러 계층, 어떤 팀도 모두 알 수 없는 설정들이 포함되어 있으며, 그 위에 수백, 수천, 수십만 명의 예측 불가능하고 비합리적인 사람들이 각자 고유한 방식으로 이 시스템을 사용하려는 복잡성이 더해집니다. IT는 의심할 여지 없이 복잡합니다.

중요한 것은 IT가 복잡하다는 사실을 인식하고, 이것이 완전히 피할 수 없는 일이지만, 솔루션을 가능한 한 단순하고, 우아하게 설계하고 엔지니어링하는 데 집중하는 것입니다. 이 설계 철학은 적어도 제 생각에는 소프트웨어 엔지니어링에서 비롯된 것입니다. 복잡한 코드는 실수로 여겨지고, 읽기 쉽고 이해하기 쉬운 단순하고 아름다운 코드가 성공적인 것으로 간주됩니다. 소프트웨어 엔지니어에게 주어질 수 있는 가장 높은 찬사 중 하나는 그녀의 코드가 우아하다고 평가받는 것입니다. 1970년대와 1980년대에 가장 인기 있는 프로그래밍 언어 중 하나가 그의 이름을 따서 명명된 블레즈 파스칼에게 귀속되는 이 유명한 인용구(프랑스어에서 다소 어색하게 번역된)가 얼마나 적절한지요: “이렇게 긴 편지를 써서 죄송합니다만, 짧게 쓸 시간이 없었습니다.”

복잡하고 난해한 솔루션을 설계하는 것이 어떤 단순한 접근법이 충분한지를 파악하는 것보다 훨씬 쉬운 경우가 많습니다. 우리가 서두르거나 어디서부터 시작해야 할지 모를 때도 우아함은 항상 도전과제입니다. 업계의 흐름은 더 어려운 길을 지향합니다. 벤더들에게는 더 많은 장비를 판매하는 것이 이익이 되는데, 이는 초기 판매뿐만 아니라 더 많은 장비가 있을수록 더 많은 지원 수입이 따라오기 때문입니다. 충분히 많고 복잡한 새 장비가 판매되면 지원 필요성이 선형이 아닌 기하급수적으로 증가하기 시작합니다. 장비나 소프트웨어 자체뿐만 아니라 시스템 상호 작용의 구성 및 지원이나 추가적인 사용자 정의를 위한 지원도 필요해지기 때문입니다. 복잡성의 뒤에 있는 재정적 동기는 크며, 벤더들에게만 해당되지 않습니다. IT 전문가들도 전환하기 어려운 대규모 하드웨어와 소프트웨어 세트를 관리함으로써 많은 고용 안정성, 혹은 그 환상을 얻습니다.

종종 복잡성은 너무나 당연하게 여겨져서, 더 단순한 솔루션이 충분할 수 있다거나 복잡성과 비용 문제를 넘어서 오히려 우수할 수 있다는 가능성에 대한 어떠한 고려도 없이 솔루션 선택 과정 자체가 대단한 복잡성을 기정사실로 놓고 시작됩니다. 때로는 복잡성이 특정 개념과 너무나 깊이 연결되어 있어서, 저는 단순한 솔루션이 복잡한 솔루션보다 가격, 성능, 신뢰성 면에서 더 뛰어날 수 있다는 생각에 실제로 믿을 수 없다는 반응을 직면한 적도 있습니다.

수사는 쉽지만, 실제 사례는 무엇일까요? 제가 오늘날 보는 가장 좋은 예들은 대부분 스토리지, 클라우드 관리 레이어, 소프트웨어, 혹은 가상화 자체와 관련된 가상화에 관한 것입니다. 단지 한 사람을 위한 가상화에 관한 대화가 네트워크 공유 블록 스토리지, 고가의 가상화 관리 소프트웨어, 다수의 중복 가상화 노드, 복잡한 고가용성 소프트웨어를 즉각적으로 연상시키는 경우를 자주 봅니다. 이 중 어느 것도 가상화 자체의 본질이 아니며, 대부분은 구현될 사업체의 지원이나 이익을 위한 것도 아닙니다. 비즈니스 요구사항에서 출발하는 것이 아니라, 이러한 개념들은 주로 기술적 선입견에서 비롯됩니다. 복잡성을 지적하며 문제를 해결하는 것처럼 보이는 것은 쉽습니다. 복잡성은 안도감을 주기 때문입니다. 많은 주장들을 걸러내다 보면 "그렇게 복잡한데 어떻게 작동하지 않을 수 있겠어요?"라는 말을 듣게 됩니다. 복잡성은 완전성의 환상을 제공하고, 문제를 해결했다는 느낌을 주지만, 이것이 솔루션이 실제로 완전하지 않거나 심지어 작동하지 않는다는 사실을 가릴 수 있습니다. 복잡성의 정도 때문에 이를 파악하기 어렵습니다. 그리고 복잡한 솔루션이 작동하지 않을 때 더 단순한 접근법이 더 완전하고 문제를 해결한다는 것을 우리 마음이 쉽게 받아들이지 못하는 이유는 그것이 너무 반직관적으로 느껴지기 때문입니다.

이에 대한 좋은 예시는 신뢰성보다 중복성에 대해 이야기하게 되는 것입니다. 신뢰성은 측정하기 어렵지만, 중복성은 수치화하기 쉽습니다. 벽돌은 하나만 있어도 높은 신뢰성을 가집니다. 벽돌이 안정적이고 튼튼하기 위해 중복성이 필요하지 않습니다. 설계가 단순합니다. 많은 중복된 막대기들로 지지 구조물을 만들 수 있지만, 그것은 벽돌 하나만큼 신뢰할 수 없을 것입니다. 신뢰성, 즉 구조물이 무너지지 않을 가능성으로 이야기한다면, 벽돌이 여러 막대기보다 우월한 선택임이 명확합니다. 하지만 "하지만 중복성이 없잖아요. 벽돌이 실패하면 대체할 것이 없잖아요"라고 말하면 우스꽝스럽게 들립니다. 그러나 컴퓨터와 컴퓨터 시스템에 대해 이야기할 때, 우리는 시스템이 너무 복잡해서 사람들이 언제 벽돌을 쥐고 있는지 막대기를 쥐고 있는지 거의 알지 못하는 상황을 만납니다. 그래서 그들은 중요한 신뢰성을 파악할 수 없기 때문에, 중요하지 않은 수치화하기 쉬운 중복성에 집중합니다. 시스템 전체가 너무 복잡합니다. 하지만 해결해야 할 문제의 핵심을 직접적으로 다루는 단순한 솔루션을 찾는 것이 복잡성을 줄이고 결국에는 훨씬 더 나은 답을 제공할 수 있습니다.

이것은 RAID에서도 볼 수 있습니다. 미러링 RAID는 단순합니다. 한 디스크 또는 디스크 세트가 다른 세트의 정확한 복사본이 되는 것입니다. 정말 단순합니다. 패리티 RAID는 여러 장치에 걸쳐 가변 스트라이프에 대한 계산이 쓸 때 인코딩되고 장치가 실패하면 디코딩되어야 하는 복잡한 방식입니다. 미러링 RAID는 이러한 복잡성이 없으며, 신뢰성이 높고 잘 이해된 단순하고 우아한 복사 작업을 통해 디스크 신뢰성 문제를 해결합니다. 패리티 RAID는 불필요하게 복잡하여 취약합니다. 그런데도 그렇게 함으로써, 설계된 문제를 해결하는 자체 능력을 약화시키면서도, 동시에 복잡성 외에 다른 어떤 요인도 없이 더 신뢰할 수 있는 것처럼 보입니다. 인간의 마음은 즉각적으로 "복잡하다, 따라서 더 발전되었다, 따라서 더 신뢰할 수 있다"고 판단하지만, 어느 쪽 연결도 논리적이지 않습니다. 복잡성이 더 발전되었음을 시사하지 않으며, 발전되었다고 해서 신뢰할 수 있다는 것도 아닙니다. 하지만 인간의 마음 자체도 복잡하고 쉽게 오도됩니다.

단순성을 찾는 데 단순한 답은 없습니다. 복잡성이 본질적으로 나쁘지만 때로는 피할 수 없다는 것을 아는 것은 우리에게 주의를 기울이도록 가르치지만, 과도한 복잡성을 의심해야 할 때를 가르쳐주지는 않습니다. 우리는 경계를 늦추지 않고, 항상 더 우아한 답이 있는지 파악하려 하고, 단지 복잡하다는 이유만으로 복잡성을 올바른 답으로 받아들이지 않아야 합니다. 우리는 제안된 솔루션에 의문을 제기하고 스스로에게도 의문을 제기해야 합니다. "이 솔루션이 정말로 그래야 하는 만큼 단순한가?" "이 복잡성이 필요한가?" "내가 가정했던 복잡성이 정말 필요한가?"

제가 제공하는 대부분의 시스템 설계 권고에서, 비즈니스 요구사항을 파악하는 단계 다음으로 일반적으로 취하는 첫 번째 기술적 결정 단계는 복잡성에 의문을 제기하는 것입니다. 복잡성이 정당화될 수 없다면, 그것은 아마도 불필요하며 선택된 목적을 적극적으로 저해하는 것입니다.

“드라이브를 여러 별도 배열로 분할하는 것이 정말 필요한가? 그렇다면 그렇게 하는 기술적 정당성은 무엇인가?”

“공유 스토리지가 제안하는 작업에 정말 필요한가?”

“비즈니스가 분산 고가용성 기술 사용을 정말 정당화하는가?”

“어제 충분했던 단순한 시스템을 왜 내일은 훨씬 더 복잡한 시스템으로 교체하는가? 이전에는 정당화되지 않았던 몇 배나 더 많은 복잡성과 지출을 요구하는 대신, 단순함을 유지하면서 크게 개선하는 것만으로는 충분하지 않다고 만드는 변화가 무엇인가?”

이것들은 흔한 예시일 뿐이며, 복잡성은 우리 업계의 모든 측면에 존재합니다. 단순성을 찾으세요. 우아함을 추구하세요. 엄격하게 검증하지 않고 복잡성을 받아들이지 마세요. 비유적으로 압박을 가해보세요. 정당화되지 않는 곳에 복잡성이 스며들도록 허용하지 마세요. 복잡성의 편에 서지 마세요. 의심스러울 때는 단순하게 실패하세요. 솔루션을 지나치게 단순화하면 일반적으로 사소한 실패로 이어지는 반면, 지나치게 복잡하게 만들면 훨씬 더 큰 실패의 가능성이 생깁니다. 더 안전한 선택은 더 단순한 솔루션입니다. 그리고 단순한 솔루션이 선택되어 부적절한 것으로 판명된다면, 복잡성을 추가하는 것이 그것을 제거하는 것보다 훨씬 쉽습니다.