Don’t Let Architecture Astronauts Scare You (2001)
추상화와 아키텍처를 지나치게 높은 수준에서 논하는 ‘Architecture Astronauts’가 실제 사용자의 문제와 소프트웨어의 목적을 놓치는 현상을 비판합니다. Napster, SOAP, XML, .NET, Jini 등의 사례를 통해 기술 유행보다 사용자가 새롭게 할 수 있는 일이 중요한 이유를 설명합니다.
AI 요약
Joel Spolsky는 소프트웨어 설계에서 추상화가 유용한 도구이지만, 지나치게 높은 수준으로 올라가면 실제 문제와 연결되지 않는 공허한 논의가 될 수 있다고 지적합니다. 그는 이런 사람들을 ‘Architecture Astronauts’라고 부릅니다. 이들은 코드를 작성하거나 프로그램을 설계하는 구체적인 작업보다 아키텍처 자체에 대해 계속 생각하며, 현실의 산소가 희박한 고도에 올라가 있는 우주비행사처럼 행동한다고 설명합니다.
글은 파일 전송이라는 구체적인 문제에서 출발합니다. 사람들이 워드프로세서 파일을 서로 보내는 상황과 스프레드시트를 보내는 상황을 보고, 이를 일반화해 ‘파일 보내기’라는 패턴을 만들 수 있습니다. 여기서 한 단계 더 올라가면 웹 브라우저가 웹 페이지 요청을 보내는 일도 같은 범주로 볼 수 있고, 객체의 메서드를 호출하는 일도 객체에 메시지를 보내는 것으로 해석할 수 있습니다. 이렇게 여러 현상을 모두 묶어 ‘messaging’이라는 더 넓은 추상화를 만들 수 있지만, 추상화가 계속 넓어질수록 정작 무엇을 의미하는지 불분명해집니다.
Spolsky가 비판하는 지점은 추상화 자체가 아닙니다. 문제를 해결하는 데 필요한 수준을 넘어선 뒤에도 멈추지 않고, 모든 것을 설명하는 거대한 개념을 만들어내는 태도입니다. 이런 개념은 우주 전체를 설명하는 그림처럼 보일 수 있지만, 실제로는 아무 의미도 전달하지 못할 수 있습니다. Architecture Astronauts는 프로그램을 구현하거나 유지보수하는 구체적인 맥락에서 멀어지면서, 코드와 사용자가 겪는 문제를 판단하는 능력도 잃게 된다고 설명합니다.
당시의 대표 사례로는 Napster를 듭니다. Napster를 두고 Architecture Astronaut는 먼저 peer-to-peer 서비스라는 구조적 특성에 주목합니다. 그 결과 peer-to-peer 콘퍼런스, peer-to-peer 벤처 캐피털 펀드, peer-to-peer에 대한 반발처럼 아키텍처 이름을 중심으로 한 담론이 확산됩니다. 그러나 사용자가 Napster를 흥미롭게 여긴 핵심은 구조가 아니라, 노래 제목을 입력하고 곧바로 음악을 들을 수 있다는 경험에 있습니다.
Spolsky는 Napster가 peer-to-peer가 아니었더라도 노래 이름을 입력해 바로 들을 수 있었다면 같은 인기를 얻었을 것이라고 말합니다. 반대로 Groove처럼 Napster보다 더 일반적인 애플리케이션을 만들려는 시도는 peer-to-peer라는 아키텍처적 일반성을 얻는 대신, 사용자가 처음부터 원했던 작고 구체적인 기능을 놓칠 수 있습니다. 더 일반적인 시스템을 만드는 일이 언제나 더 유용한 제품을 만드는 일과 같지는 않다는 주장입니다.
글은 당시 새롭게 등장한 Java, XML, SOAP, XML-RPC, Hailstorm, .NET, Jini를 나열합니다. Spolsky는 이 기술들이 나쁜 아키텍처라고 말하지 않습니다. 오히려 개발자에게 이익을 줄 수 있는 좋은 아키텍처일 수 있다고 인정합니다. 그가 문제 삼는 것은 기술 자체를 넘어선 과도한 미래주의적 홍보입니다.
Microsoft .NET 백서의 다음과 같은 표현을 예로 듭니다. .NET이 사용자의 디지털 생활을 통제할 수 있도록 해준다는 설명입니다. 이어 Microsoft Hailstorm 백서의 기술이 주변의 기술을 사용자를 대신해, 그리고 사용자의 통제 아래에서 작동하게 만든다는 표현도 소개합니다. Spolsky는 이런 거창한 문구를 아파트의 첨단 할로겐 조명이 무작위로 깜빡이는 문제까지 이제 해결해줄 것처럼 들린다고 비꼽니다.
Sun의 Jini 백서도 비슷한 방식으로 인용합니다. 컴퓨터의 경계가 사라지고, 컴퓨터가 어디에나 존재하며, 컴퓨터 사용의 세부사항이 홈시어터에 DVD를 넣는 것만큼 단순해질 것이라는 설명입니다. Java에 대해 George Gilder가 ‘기술 역사에서의 근본적인 단절’이라고 표현한 사례도 언급합니다. Spolsky는 이런 영웅적이고 유토피아적인 문장, 현실과 동떨어진 자신감, 사업 언론의 열광이 Architecture Astronaut를 알아보게 하는 신호라고 말합니다.
Spolsky는 아키텍처 담당자들이 유용하게 해결할 문제보다 자신들이 해결할 수 있다고 생각하는 문제를 선택한다고 지적합니다. SOAP과 WSDL은 당시 새로운 흐름이었지만, 기존 기술을 사용하면 할 수 있었던 일을 다른 방식으로 제공할 뿐, 사용자가 이전에는 할 수 없었던 일을 반드시 가능하게 만드는 것은 아니라고 설명합니다. 분산 서비스의 이상은 과거에도 DCOM, JavaBeans, OSF DCE, CORBA를 통해 약속된 적이 있습니다.
XML을 네트워크상에서 데이터를 표현하는 형식으로 사용할 수 있게 된 점도 인정하지만, 그것만으로 새로운 사용자 경험이나 새로운 능력이 생기는 것은 아니라고 선을 긋습니다. 그는 이를 슈퍼마켓이 창고에서 물건을 운반하기 위해 트럭을 사용한다는 사실에 비유합니다. 트럭이라는 운송 수단은 물류에 필요할 수 있지만, 소비자에게 중요한 것은 트럭 자체가 아니라 새로 살 수 있게 된 망고와 같은 결과입니다.
따라서 글의 결론은 아키텍처를 무시하라는 뜻이 아닙니다. 좋은 아키텍처는 개발자와 시스템에 분명한 이익을 줄 수 있지만, 그것을 세계 평화나 기술적 구원처럼 포장해서는 안 된다는 주장입니다. 아키텍처를 설명하는 대신 사용자가 이전에는 할 수 없었던 일을 무엇을 할 수 있게 되는지 말해야 하며, 그렇지 못하다면 추상화의 높은 곳에 머물러 개발자의 시간을 낭비하지 말아야 한다고 강조합니다.
• @koala — 이 글은 《추상화에 대해 너무 많이 생각하다 보면 소프트웨어의 실제 목적에 대한 생각을 멈추게 된다》는 방향으로 더 나아가며, 이는 훌륭한 지적입니다. 하지만 제 머릿속에서는 늘 다른 점, 어쩌면 덜 중요한 점에 초점을 맞춰왔습니다. 아키텍트가 되어 코드를 작성하고 유지보수하는 일상에서 단절되면, 소프트웨어 개발에 대해 효과적으로 추론하는 능력을 잃게 됩니다.
• @jrwren — 제 생각에는 그보다 훨씬 심각합니다. 대기업에서는 복잡한 문제를 해결하는 일이 높은 보상을 받습니다. 그러면 가장 좋고 단순하며 우아한 해법을 작성하는 대신, 가장 복잡한 해법을 만드는 쪽으로 보상이 바뀝니다. 대기업에서 직함에 Architect가 들어간 사람을 볼 때마다, 저는 그들이 범용 소프트웨어 구성요소로 거대한 Rube Goldberg 기계를 조립하는 일을 좋아한다고 생각합니다. 그들에게는 인기 있는 기술 목록이 있고 모든 체크박스를 채워야 합니다. 어떤 해법이 Kafka를 사용하지 않는다는 사실을 알아차리면 큰일입니다. Kafka를 넣어야 합니다. 워크플로 시스템도 마찬가지입니다. Temporal을 넣어야 합니다. 이들은 모든 기술 유행을 잡아야 하는 포켓몬 게임을 하고 있습니다.
• @hjvt — 비슷한 생각을 표현한 블로그 글에 대한 최근 논의가 있습니다. 그리고 훌륭한 결과를 반드시 내놓지는 않는 ‘어려운 문제’에 컴퓨터과학 분야가 집착하는 현상을 다룬 발표에 대해서는 논의가 거의 이루어지지 않았습니다.
• @koala — 8년 전의 이전 논의도 있습니다. 현재의 또 다른 유행에 관한 에세이를 읽다가 ‘architecture astronaut’라는 표현이 떠올랐습니다. 이 표현이 여러 번 사용되는 것을 보았고 유용한 용어라고 생각했지만, Joel이 만든 말이라는 사실은 놓치고 있었습니다. 다만 Joel이 요즘 무엇을 하는지 조금 찾아본 것은 약간 아이러니하고 실망스러웠습니다.
• @lightandlight — 이 댓글의 링크는 이전 논의가 아니라 해당 글로 연결됩니다.
원문: Joel on Software / 번역·요약: Trawling