2010년 출간된 "Just Enough Software Architecture"

• George Fairbanks의 Just Enough Software Architecture는 언어 문법이나 UML 지식만으로는 좋은 객체지향 시스템과 아키텍처를 설계하기 어렵다는 문제의식에서 출발함
• 핵심은 위험 기반 아키텍팅으로, 위험이 작을 때는 과도한 설계를 피하고 성공을 위협하는 위험에는 더 엄밀한 기법을 적용함
• 아키텍처를 일부 전문가의 전유물이 아니라 모든 개발자가 이해해야 할 역량으로 다루며, 제약과 작은 변경이 시스템 속성에 미치는 영향을 설명함
• 개발 프로세스나 조직 운영보다 엔지니어링 기법에 집중해, 모델링과 아키텍처 분석으로 중대형 문제의 설계 트레이드오프를 다루게 함
• 구성은 위험 기반 소프트웨어 아키텍처와 아키텍처 모델링의 두 부분이며, 도메인 모델·설계 모델·코드 모델, 캡슐화, 컴포넌트와 커넥터 같은 추상화를 다룸

---

언어·UML 지식만으로는 부족한 설계 역량

• 저자는 소프트웨어 개발을 시작할 때 자신에게 필요했던 책을 만들겠다는 문제의식에서 출발함
• 당시에는 프로그래밍 언어나 객체지향 프로그래밍 책은 있었지만, 설계를 다루는 책은 적었음
• C++ 언어 기능을 아는 것만으로 좋은 객체지향 시스템을 설계할 수 없고, UML을 아는 것만으로 좋은 시스템 아키텍처를 설계할 수도 없음

위험에 맞춰 조절하는 아키텍팅

• 책의 핵심은 risk-driven architecting임
• 위험이 작을 때는 세밀한 설계가 필요 없고, 성공을 위협하는 위험이 있을 때는 엉성한 설계로 충분하지 않음
• 여러 Agile 지지자들은 일부 선행 설계가 도움이 될 수 있다고 보며, 이 책은 “충분한 만큼의 아키텍처”를 수행하는 방법을 다룸
• “one size fits all”식 프로세스를 피하고, 직면한 위험에 따라 아키텍처와 설계 노력을 조정하도록 안내함
• 대부분의 기법은 quick-and-dirty 수준부터 매우 엄밀한 수준까지 강도를 조절할 수 있음

아키텍처를 모든 개발자의 언어로 만들기

• 책은 아키텍처를 민주화하려는 목표를 가짐
• 조직에 소프트웨어 아키텍트가 있을 수 있고, 독자 자신이 아키텍트일 수도 있음
• 많은 아키텍트는 모든 개발자가 아키텍처를 이해하기를 원함
• 개발자가 제약의 이유와 작은 변경이 시스템 속성에 미치는 영향을 이해하지 못하면 설계 판단이 흔들릴 수 있음
• 아키텍처는 아키텍트만의 주제가 아니라 모든 소프트웨어 개발자에게 관련 있는 주제임

절차적 지식과 선언적 지식

• 책은 선언적 지식을 기르는 데 초점을 둠
• 테니스 공을 칠 수 있는 능력과 왜 칠 수 있는지 아는 것은 다르며, 이는 절차적 지식과 선언적 지식의 차이에 해당함
• 이미 시스템을 설계하고 구축하는 전문가라면 책의 여러 기법을 사용해 왔을 수 있음
• 책은 그동안 해온 일을 더 잘 인식하게 하고 개념에 이름을 붙여 줌
• 이런 선언적 지식은 초보 개발자를 멘토링하는 능력을 높이는 데 도움이 됨

프로세스보다 엔지니어링에 집중

• 소프트웨어 시스템을 설계하고 구축하는 사람은 일정, 자원 약속, 이해관계자 요구 등 여러 문제를 함께 다뤄야 함
• 많은 소프트웨어 아키텍처 책은 개발 프로세스와 조직 구조를 이미 다룸
• 이 책은 그와 달리 소프트웨어 개발의 기술적 부분과 시스템이 작동하도록 만드는 엔지니어링에 집중함
• 모델을 만들고 아키텍처를 분석해 원칙 있는 설계 트레이드오프를 할 수 있게 함
• 중대형 문제를 추론하는 데 쓰이는 기법을 설명하고, 전문 기법을 더 자세히 배울 수 있는 위치도 가리킴

여러 추상화 수준을 오가는 실용적 설계

• 책은 아키텍처를 실용적인 설계 활동으로 다룸
• 소프트웨어 아키텍처는 소프트웨어 설계의 한 종류이며, 설계 결정은 아키텍처에 영향을 주고 아키텍처도 설계에 영향을 줌
• 뛰어난 개발자는 장애물을 자세히 파고들어 이해한 뒤, 그 장애물의 성격을 전체 아키텍처와 연결함
• 이런 drill-down/pop-up 행동을 반영해 아키텍처부터 데이터 구조 설계까지 여러 추상화 수준의 모델을 다룸

구성과 제공 형식

• 책은 두 부분으로 구성됨
  • Part I: Risk-Driven Software Architecture
  • Part II: Architecture Modeling
• 일부 샘플 챕터를 하나의 PDF로 내려받을 수 있음
  • all the sample chapters in one file
  • ePub e-book
• 전자책은 Google Play에서 판매되며, DRM 없는 ePub, Mobi, PDF 세 가지 형식이 포함되고 가격은 $9.99임
• 하드백은 Amazon에서 제공됨
• Google Books와 Amazon Search Inside는 전체 텍스트 검색 가능한 버전을 제공함

다루는 범위와 제외하는 범위

• 책은 소프트웨어 구축과 관련된 소프트웨어 아키텍처에 집중함
• 소프트웨어가 엔지니어링 요구를 만족하도록 하는 기법을 설명함
• 엔지니어링 기법 자체가 대체로 프로세스에 독립적이기 때문에, 책도 대부분 프로세스에 구애받지 않음
• 다음과 같은 관리 활동 조언은 다루지 않음
  • 아키텍트의 정치적 책임
  • 특정 종류의 회의를 언제 열어야 하는지
  • 이해관계자로부터 요구사항을 수집하는 방법

Part I: 위험 기반 소프트웨어 아키텍처

• 소프트웨어 아키텍처를 정확히 정의하기는 어렵지만, 몇 가지 성격은 분명함
• 소프트웨어 개발자는 다른 공학 분야의 엔지니어처럼 추상화와 모델을 사용해 크고 복잡한 문제를 해결함
• 소프트웨어 아키텍처는 시스템의 골격처럼 작동하고 품질 속성에 영향을 주며, 기능과는 직교하고 제약을 통해 시스템 속성에 영향을 줌
• 아키텍처는 다음 상황에서 특히 중요함
  • 해법 공간이 작을 때
  • 실패 위험이 높을 때
  • 어려운 품질 속성 요구를 마주할 때
• 설계 방식은 architecture-indifferent design, architecture-focused design, architecture hoisting 중에서 선택할 수 있음
• 위험 기반 모델의 핵심 절차는 단순함
  • 위험을 식별하고 우선순위를 매김
  • 기법 집합을 선택해 적용함
  • 위험 감소를 평가함
• 4장은 Home Media Player 시스템 예제로 위험 기반 모델 적용을 보여줌
  • 팀 커뮤니케이션
  • COTS 컴포넌트 통합
  • 메타데이터 일관성 보장
• Part I은 모델과 소프트웨어 아키텍처 사용 조언으로 마무리됨
  • 문제 해결에 모델을 사용함
  • 제약을 신중하게 추가함
  • 위험에 집중함
  • 아키텍처 역량을 팀 전체에 분산함

Part II: 아키텍처 모델링

• Part II는 소프트웨어 아키텍처의 개념 모델을 형성하도록 돕는 데 초점을 둠
• 기본 모델 구조는 세 가지임
  • 도메인 모델: 현실 세계의 사물에 대응함
  • 설계 모델: 구축 중인 소프트웨어의 설계를 나타냄
  • 코드 모델: 소스 코드에 대응함
• 선택된 세부사항을 보여주는 추가 모델인 뷰(view) 를 만들 수 있고, 이런 뷰는 viewtype으로 묶일 수 있음
• 캡슐화 경계를 만드는 것은 소프트웨어 아키텍처의 중요한 기술임
  • 컴포넌트나 모듈 사용자는 내부 동작을 무시하고 다른 어려운 문제에 집중할 수 있음
  • 캡슐화된 컴포넌트나 모듈의 작성자는 사용자를 흔들지 않고 구현을 변경할 자유를 얻음
  • 이런 자유는 캡슐화가 효과적일 때만 가능하므로, 책은 이를 보장하는 기법을 다룸
• 여러 출처의 소프트웨어 아키텍처 기법을 통합함
  • 품질 속성을 강조하는 기법
  • 기능을 강조하는 기법
  • 효과적인 모델을 만드는 실용적 방법
  • 모델을 디버깅하는 방법
• Part II는 모델을 효과적으로 사용하는 조언과 함께, 해당 기술에서 마주칠 수 있는 함정도 다룸
• 마지막 목표는 추상화와 관계에 대한 풍부한 개념 모델을 갖추고, 코치가 경기를 보듯 소프트웨어 시스템을 볼 수 있게 하는 것임

[GN⁺]

Hacker News 의견들

• 프로젝트 관리 리스크가 “주요 개발자가 버스에 치임”이고 소프트웨어 공학 리스크가 “서버가 사용자 1000명까지 확장되지 않을 수 있음”이라면 둘을 구분해야 한다는 말이 있지만, 내 경험상 그렇게 드물게 분리되지는 않음
  코드 품질과 구조, 테스트와 문서, 표준적이고 잘 알려진 도구 사용은 양쪽 모두에 도움이 됨
  그래서 동료나 상사에게 “버스에 치이면?”이라는 가정을 여러 번 꺼냈고, 이는 재현 가능하고 이해 가능한 소프트웨어를 만들게 하는 압박 장치가 됨
  부상이나 죽음의 부정적 뉘앙스를 피하려면 “복권에 당첨되면?”을 쓰는 게 좋음

  • 긍정적으로 바꾸려는 시도는 좋지만, 개인적으로는 복권에 당첨돼도 인수인계는 할 것 같음
    “버스에 치임”의 핵심은 성격과 무관하게 준비할 시간이 전혀 없다는 데 있고, 그래서 정보를 오늘 공유해야 한다는 압박이 생김
    아쉽게도 같은 함의를 가진 긍정적 표현은 아직 찾지 못했음
  • 중요한 동료가 실제로 버스에 치인 일이 커리어 중 두 번 있었음
    둘 다 일주일쯤 뒤에 복귀했으니, 다른 표준 재난 예시가 필요해짐
  • “복권 당첨”은 더 흔한 결과인 해고를 돌려 말하는 표현이기도 함
    요점을 전달할 때는 “다음 사람”이라는 표현을 더 자주 씀
    더 나쁜 상황은 번아웃이라서, 인원수는 그대로지만 정신적으로는 이미 떠난 상태가 됨
  • “3주 휴가를 간다”는 표현은 어떨까 싶음
    영구 퇴사가 아니라 그 정도도 버티지 못하는 회사를 많이 봤음
    또는 “버스 계수 늘리기”처럼 단일 장애 지점을 제거한다는 동기에 초점을 맞추는 표현도 가능함
    근본 원인 분석을 한다면 “Larry가 버스에 치여서 / 복권에 당첨돼서”에서 멈추면 안 되고, 그건 진짜 문제가 아님
  • 그 긍정적 표현에 대해 “이 회사가 내 가장 큰 투자처라서, 난 안 떠난다”는 답도 들어봄

• 아키텍처를 위한 아키텍처는 불필요하게 복잡도를 키우기 때문에 최악임
  좋은 아키텍처의 궁극적 목표는 비용 절감임
  아키텍처 때문에 코드를 개발하고 유지보수하는 데 시간이 더 든다면 그 아키텍처는 실패한 것임

  • 어떤 아키텍처는 처음 구현 비용은 매우 낮지만 유지보수와 발전 비용이 더 비싸고, 어떤 것은 초기 비용이 높지만 제품 운영과 발전을 더 쉽게 해줌
    항상 균형 잡기의 문제임
    따라서 하나의 정답 아키텍처는 없고, 선택은 상황에 따라 달라지며 때로는 재평가해야 함
    유연성은 변화하는 상황에서도 아키텍처를 어느 정도 조정하고 효율을 유지하게 해주므로 특히 유용함
  • 소프트웨어 아키텍처의 궁극적 목표는 품질 목표를 충족하는 것임
    비용 절감은 그중 하나일 수 있음
  • 아키텍처는 얼마나 있으면 충분한가? 3장 리스크 주도 모델은 가능한 한 적게 아키텍처를 하도록 안내함
    “리스크 주도 모델은 개발자가 가장 시급한 리스크를 줄이기 위해 최소한의 아키텍처 기법을 적용하도록 이끈다. ‘내 리스크는 무엇인가? 이를 줄이는 최선의 기법은 무엇인가? 리스크가 완화됐고 이제 코딩을 시작하거나 재개할 수 있는가?’를 끈질기게 묻는 과정이다. 리스크 주도 모델은 세 단계로 요약할 수 있다: 1. 리스크를 식별하고 우선순위를 매긴다 2. 기법 묶음을 선택해 적용한다 3. 리스크 감소를 평가한다”
    영향이 낮은 기법에 시간을 낭비하고 싶지도 않고, 프로젝트를 위협하는 리스크를 무시하고 싶지도 않음
    성공적인 시스템을 만들려면 시간을 가장 효과적으로 쓰는 경로를 택해야 하며, 이는 리스크가 동기가 될 때만 아키텍처와 설계 기법을 적용해 리스크를 다루는 것을 뜻함
    예를 들어 “아키텍처”에는 서버가 먼저 행동하지 않고 클라이언트 요청에 응답만 하는 클라이언트-서버 스타일을 쓰는 것도 포함됨
    이 방식은 문제에 잘 맞을 수도 있고 아닐 수도 있음
    https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
  • 거대한 아키텍처는 거의 항상 엘리트주의 문화로 이어짐
    많은 돈을 받는 기술 아키텍트들이 별일은 안 하면서, 마감 같은 불합리한 제약 속에서 소프트웨어 엔지니어들이 해결해야 할 끔찍한 패턴을 강요하게 됨
  • 비용 절감뿐 아니라 투자를 더 가능하게 하는 것도 중요함
    좋은 아키텍처는 더 많은 사람이 제품에 참여할 수 있게 해줌

• 2010년에 출간됐다면 그 이후 얼마나 살아남았는지 궁금함
  “Design It”은 이해관계자나 고객과 상호작용해야 하는 기술자에게 좋은 워크숍과 활동이 있어서 마음에 듦
  컨설팅 역할이라 더 관련이 크고, 자주 바뀌는 특정 기술 아키텍처 스타일에 너무 기대지 않는 점도 좋음

  • 2010년 이후 아키텍처에서 바뀐 것이 많다고는 생각나지 않음
    유행이 아니라 실제 원칙 기준으로 말하는 것임
  • 우리 회사의 프로세스는 이 책의 영향을 많이 받았고, 아키텍처와 개발 프로세스에 대해 꽤 좋은 개요를 준다고 봄
    저자는 마음가짐에 대한 산문에 많은 시간을 쓰고 구체적 기술은 가볍게 다루지만, 더 읽을 자료는 제공함
  • Keeling의 Design It은 훌륭함 [1]
    팀이 구체적 활동을 통해 아키텍처 아이디어를 다루게 하고, 결국 무엇이 중요한지 드러나게 해줌
    내 책은 그런 큰 아이디어를 정면으로 다루려 했는데, 주제가 워낙 추상적이라 교육적으로는 어렵다는 게 드러남
    2010년 이후 어떤 아이디어가 살아남았나? 어떤 운영체제는 마이크로커널이고, 어떤 운영체제는 모놀리식임
    어떤 데이터베이스는 관계형이고, 어떤 것은 문서 중심임
    어떤 애플리케이션은 클라이언트-서버이고, 어떤 것은 피어 투 피어임
    이런 구분은 아마 영속적이며, 100년 뒤에 돌아와도 Windows, Oracle, Salesforce 같은 예시는 사라졌더라도 그런 설계를 가진 시스템은 볼 수 있을 것임
    그리고 수정 용이성이나 지연 시간 같은 품질에 대해서도 여전히 이야기할 것임
    소프트웨어 아키텍처 분야는 이런 영속적 추상화를 식별하는 일임
    [2]에 간결한 설명이 있음
    “초록: 소프트웨어 아키텍처는 만들 계획이거나 이미 만든 소프트웨어를 추론하도록 돕는 추상화의 집합이다. 우리 분야에는 오래전부터 작은 추상화가 있었지만, 품질 속성, 정보 은닉, 구성요소와 연결자, 여러 관점, 아키텍처 스타일 같은 더 큰 추상화가 축적되기까지는 수십 년이 걸렸다. 시스템을 설계할 때 우리는 이런 추상화를 엮어 의도성의 사슬을 보존하고, 설계한 시스템이 원하는 일을 하게 한다. 20년 전 이 잡지에 Martin Fowler가 영향력 있는 글 ‘Who Needs an Architect?’를 발표했다. 이제 개발자들이 소프트웨어 아키텍처를 다시 보고, 소프트웨어를 추론하게 해주는 추상화의 집합으로 볼 때다”
    [1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
    [2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...

• John Ousterhout의 A Philosophy of Software Design이 유용했음
  이해하기 쉬운 탄탄한 조언이 많고 예시도 많음

• 이 책 자체는 모르지만, 저자가 쓴 Intellectual Control 관련 글은 알고 있고 매우 통찰력 있음
  https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...

  • 이 글과 함께 읽기 좋은 글이라고 느낌
    https://johnwhiles.com/posts/programming-as-theory

• 이전 회사에서 Simon Brown의 Software Architecture for Developers 책을 돌려봤음: https://leanpub.com/b/software-architecture
  아직 읽을 목록에만 있고 그 회사에서는 옮겼지만, 강력 추천을 받았음
  그 회사는 C4 모델로 아키텍처도 문서화했음
  여기서 읽어본 사람이 있는지 궁금함

  • Simon Brown은 개발자를 위해 소프트웨어 아키텍처를 민주화하는 일을 나보다 훨씬 잘해온 사람임
    그의 아키텍처 강연 [1]과 워크숍은 특히 효과적이고, C4 아키텍처 모델링 언어 [2]도 실제로 탄력을 받고 있음
    내 YouTube 영상도 있지만 [3] 그만큼 효과적이지는 않음
    [1] https://www.youtube.com/results?search_query=simon+brown+arc...
    [2] https://c4model.com/
    [3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...

• 이 방법론에는 “리스크 의존”이라는 이름이 훨씬 나았을 것 같음
  프로그래머들은 왜 그렇게 “[X]-주도”라는 표현을 좋아하는 걸까?

  • 개인적으로 “X-주도”는 기계적으로 파생된 은유라고 봐왔음
    이 축이 저 톱니를 구동하고, 그 톱니가 바퀴를 구동하는 식임
    “이 복잡한 사고 기계에서 가장 강력한 메커니즘이 무엇인가”를 줄여 말한 표현임

• 몇 년 전 회사에서 이 책으로 독서 모임을 했는데, 매우 반복적이라고 느꼈음

• 사소하지 않은 오픈소스 프로젝트를 시작하는 사람에게 이 책이 좋은 자료인지 궁금함
  또는 1인 창업자가 얻을 가치가 있는지, 솔로 개발자에게 유용한 책이나 다른 자료를 추천받고 싶음

• 소프트웨어 아키텍처는 일반 건축과 비슷하지만, 소프트웨어에는 아직 Isaac Newton 같은 인물이 없어서 토목공학이 존재하지 않는 상태 같음
  지금까지 가장 가까운 인물은 Claude Shannon이라고 봄

  • 어떤 소프트웨어 공학 실천, 아키텍처, 언어, 도구가 더 효과적인지 알 수 없음
    측정 단위조차 없기 때문임
    우리는 아직 소프트웨어 공학에서 “무너지지 않길 바라는” 단계에 있음
    이는 자가 보고 생산성에 깊은 영향을 줌
    예를 들어 창문을 올린 채 시속 30마일로 정지 표지판이 많은 작은 교외 도로를 운전하는 것보다 자전거가 더 빠르게 느껴질 수 있음
    하지만 보통 운전자가 20블록 떨어진 곳에 훨씬 더 빨리 도착함
    측정 단위가 없다면 모두가 자전거가 더 빠르다고 다투고 있을 것임
    소프트웨어 공학이 지금 그런 상태임
  • 이게 바로 소프트웨어 아키텍처와 설계라는 개념 밑에 깔린 잘못된 전제임
    소프트웨어를 만드는 일은 다리나 고층 빌딩을 짓는 일과 전혀 같지 않고, 오히려 그것들을 설계하는 일에 더 가까움
    큰 건축 프로젝트에서는 먼저 설계하고 그다음에 짓는데, 이 설계는 엄청난 작업임
    모든 것을 생각하고, 시뮬레이션을 돌리고, 이해관계자와 협의하고, 요구사항과 제약을 파악하고, 재료비와 무게 등을 고려해야 함
    대형 건설 프로젝트에서는 실제로 설계를 만드는 데만 몇 달이나 몇 년이 사라질 수 있고, 결과물은 거의 모든 건설 측면을 포괄하는 매우 상세한 청사진임
    사실 이는 소프트웨어 만들기와 꽤 비슷함
    이런 설계 프로젝트에는 높은 불확실성과 리스크가 있음
    그래도 많은 인력, 콘크리트, 철강 같은 비싼 자원을 쓰기 시작하기 전에 전부 틀렸다는 것을 알아내는 편이 낫음
    하지만 건축가가 이를 완화하려고 설계를 위한 설계를 만든다고 말하는 걸 들어본 적이 있는가? 그런 건 없음
    기껏해야 어느 시점에 스케치나 냅킨 그림이 있었을 수 있음
    SpaceX는 공학에 애자일 요소를 일부 도입했는데, 이는 소프트웨어 개발에서 배운 것임
    소프트웨어에서는 완성된 청사진이 실행 가능함
    청사진을 만드는 과정은 수작업이지만, 그 청사진에서 소프트웨어를 만드는 과정은 보통 컴파일러와 다른 도구로 자동화되어 매우 싸기 때문에 개발자들이 항상 함
    물론 예전에는 항상 그렇지는 않았음
    실행 가능한 청사진을 만드는 과정에는 당연히 많은 리스크가 있고, 곳곳에 냅킨이나 화이트보드 설계가 있을 수 있음
    하지만 먼저 완전한 설계를 하고 그다음 완전한 구현을 한다는 개념, 즉 폭포수 방식은 소프트웨어에서도 제대로 작동한 적이 없음
    몇몇 예외를 빼면 보통 청사진을 위한 청사진은 없음
    Royce의 폭포수 원 논문을 읽어보면 실제로 폭포수라는 말은 전혀 나오지 않고, 반복이 좋은 생각일 수 있다고 어렴풋이 제안함
    최소한 한 번 이상 해보라는 식임
    그는 첫 설계가 틀릴 가능성이 크다는 걸 완전히 이해하고 있었음
    애자일은 반복을 많이 할 때 분명해지는, 청사진을 위한 설계를 만드는 낮은 가치의 단계를 최적화해 없앤 것임
  • 데이터와 지표는 있거나 적어도 가질 수 있음
    다만 특정 영역 바깥에서는 우리가 대체로 무시할 뿐임
    예를 들어 이 요약과 목차를 대충 보면 성능 지표에 대한 언급이 거의 없거나 아예 없어 보임
    컴퓨터가 실제로 무엇을 하는지 고려하지 않는다면 아키텍처가 무슨 쓸모가 있나?
    개발 생산성이나 사용자 인터페이스 측면에서도, 소프트웨어를 개발하고 바꾸고 확장하고 더 중요하게는 사용하기 위해 필요한 정신적 스택을 설명하는 수학적 모델이 왜 없을까?
    인간이든 기계든 계산 자원은 개발자나 사용자로서 소프트웨어와 상호작용하는 데 실제적이고 측정 가능한 영향을 주는데, 왜 드물게만 고려될까?
  • 비교의 전반적 취지에는 동의하지만, 전통적 건축도 공식으로 정해지지 않는 숙고와 선택이 많이 들어간다는 점은 짚어야 함
    예를 들어 Westminster Palace에는 분명 토목공학적 요소가 있지만, 화려한 질감, 상징적인 시계탑, 내부 배치 같은 결정적 특징은 대부분 기능적·미학적 선택이 좌우함
    소프트웨어의 많은 부분도 마찬가지임