Step 01. “아키텍처”라는 단어의 탄생

만화로 보는 요약 — 먼저 읽어보세요

건축의 은유에서 출발해, 아키텍처는 그림 자체가 아니라 바꾸기 비싼 중요한 결정과 그 근거라는 결론에 도달한다.

면접 실전 질문: ① 아키텍처와 다이어그램은 어떻게 다른가? ② 중요한 결정은 무엇으로 구분하는가? ③ 왜 근거(rationale)를 남겨야 하는가?

이 장의 질문: 우리는 왜 소프트웨어를 이야기하면서 “건축”이라는 단어를 쓰게 되었는가? 그리고 그 단어가 학문이 되기까지 왜 한 세대 — 첫 등장(1964)에서 교과서(1996)까지 30여 년 — 가 걸렸는가?

1. 은유의 수입 — 왜 하필 건축이었나

“아키텍처(architecture)“는 소프트웨어가 만든 말이 아니다. 빌려온 말이다. 그런데 흥미롭게도, 소프트웨어가 이 단어를 빌려온 곳은 건축 현장이 아니라 하드웨어였다.

1964년, IBM은 System/360이라는 메인프레임을 발표하면서 「Architecture of the IBM System/360」이라는 논문을 낸다. 저자는 Gene Amdahl, Gerrit Blaauw, 그리고 훗날 『맨먼스 미신(The Mythical Man-Month)』을 쓰는 Fred Brooks. 이들이 “컴퓨터 아키텍처”라는 말로 가리킨 것은 회로도가 아니었다.

“아키텍처란 프로그래머의 관점에서 본 시스템의 속성, 즉 개념적 구조와 기능적 동작이며, 데이터 흐름과 제어의 조직, 논리 설계, 물리적 구현과는 구별된다.” — Amdahl, Blaauw & Brooks (1964)

여기에 이미 이 책 전체를 관통할 통찰이 들어 있다. 아키텍처는 “어떻게 만들어졌는가”가 아니라 “사용자(프로그래머)가 무엇을 알아야 하는가”, 즉 인터페이스와 개념 구조에 관한 것이라는 관점이다. System/360의 목표는 단일 기계가 아니라 제품군이었다 — 저가 모델부터 고가 모델까지 내부 구현은 완전히 다르지만, 같은 프로그램이 돌아가야 했다. 구현으로부터 분리된 “지켜야 할 약속”이 필요했고, 그 약속에 붙인 이름이 아키텍처였다. 제품군 전체가 하나의 개념 구조를 지켜야 한다는 이 사상을 Brooks는 훗날 『맨먼스 미신』에서 **개념적 무결성(conceptual integrity)**이라 부르며 “시스템 설계에서 가장 중요한 고려사항”으로 격상시킨다.

왜 건축이라는 은유가 통했나

건축이라는 은유가 매력적이었던 이유는 세 가지다.

1. 설계와 시공의 분리. 건축가는 벽돌을 쌓지 않는다. 도면이라는 추상이 시공이라는 구현에 선행한다. “생각하는 일”과 “만드는 일”을 분리하고 싶었던 초기 컴퓨터 산업에 이 그림은 잘 맞았다.
2. 구조가 하중을 견딘다. 건물에서 기둥과 보는 아무렇게나 놓을 수 없다. 잘못 놓으면 무너진다. “바꿀 수 없는 결정”과 “나중에 바꿔도 되는 결정”의 구분이 건축에는 이미 있었다.
3. 완성물의 규모. 한 사람의 손을 벗어난, 여러 사람이 수년에 걸쳐 만드는 인공물이라는 스케일 감각.

그러나 은유에는 유통기한이 있다

미리 경고해두자. 이 은유는 유용했지만 완벽하지 않고, 이 책 후반의 진화적 아키텍처 장에서 우리는 이 은유의 한계와 다시 만난다. 건물은 완공되는 순간이 있지만, 소프트웨어는 완공이 없다. 건물의 하중은 물리 법칙이라 변하지 않지만, 소프트웨어를 누르는 하중 — 요구사항 — 은 매주 바뀐다. “설계 후 시공”이라는 건축의 순서가 소프트웨어에서는 자주 배신당한다. 은유는 출발점이지 정의가 아니다.

2. 1968년, 가르미슈 — 위기의 인식 (그러나 아키텍처의 탄생은 아니다)

1968년 10월, 독일 가르미슈(Garmisch)에 약 50명의 학자와 실무자가 모였다. NATO가 후원한 이 회의의 이름은 NATO Software Engineering Conference. Edsger Dijkstra를 포함한 당대의 거물들이 참석했다.

여기서 사실관계를 정확히 하자. 흔히 “1968년 NATO 회의에서 소프트웨어 아키텍처가 태어났다”고 서술하는 글이 있는데, 이 회의가 만든 말은 “소프트웨어 아키텍처”가 아니라 “소프트웨어 공학(software engineering)“이다. 이 이름 자체가 도발이었다. 주최 측(F.L. Bauer 등)은 당시 소프트웨어 제작이 공학이라 부를 수 없을 만큼 주먹구구라는 문제의식을 담아, 아직 존재하지 않는 학문의 이름을 회의 제목으로 걸었다.

회의를 지배한 단어는 **“소프트웨어 위기(software crisis)“**였다. 하드웨어는 해마다 빨라지고 싸지는데, 소프트웨어는 일정이 밀리고, 예산이 터지고, 배포 후에 무너졌다. OS/360 개발에서 Brooks가 겪은 대혼돈이 상징적 사례다. 참석자들은 진단에 합의했다: 우리는 우리가 만드는 것의 복잡성을 다루는 방법을 모른다.

1969년 로마에서 후속 회의가 열렸고, 이후 1970년대에 이 위기에 대한 응답들이 쏟아진다 — 구조적 프로그래밍(Dijkstra), 모듈 분해와 정보 은닉(Parnas, 1972), 결합도와 응집도(Constantine). 이것들은 Step 02에서 자세히 다룬다. 여기서 기억할 것은 하나다. 1968년은 “질문”이 태어난 해이지, “아키텍처”라는 답이 태어난 해가 아니다.

3. 1992년, 단어가 학문이 되다 — Perry & Wolf

그 질문에서 “아키텍처”라는 학문적 답이 나오기까지 24년이 걸렸다.

1970~80년대에도 실무에서는 “시스템 아키텍처”, “아키텍트” 같은 말이 느슨하게 쓰였다. 그러나 이 단어에 정의를 부여하고 연구 대상으로 선언한 것은 1992년, Dewayne Perry와 Alexander Wolf의 논문 **「Foundations for the Study of Software Architecture」**다. 이 논문이 한 일은 세 가지다.

첫째, 정의를 제시했다. 그들의 공식은 이렇다.

Software Architecture = { Elements, Form, Rationale }
                          (요소)     (형상)   (근거)

• 요소(elements): 처리 요소, 데이터 요소, 연결 요소 — 시스템을 이루는 부품들
• 형상(form): 그 요소들을 배치하는 규칙과 제약 — 무엇이 무엇과 어떻게 연결되는가
• 근거(rationale): 왜 그렇게 배치했는가

셋 중 가장 급진적인 것은 세 번째다. 구조물만이 아니라 결정의 이유가 아키텍처의 일부라고 선언한 것이다. 코드를 아무리 읽어도 rationale은 보이지 않는다 — 이 통찰은 실전 파트의 아키텍처 결정 기록(ADR) 장에서 실천 도구로 되돌아온다.

둘째, 건축 은유를 정면으로 검토했다. 건축양식(style)이라는 개념을 소프트웨어에 이식해 “아키텍처 스타일”이라는 용어를 정착시켰다. 단어 자체는 하드웨어를 경유해 들어왔지만(1절), “양식”이라는 은유의 본체는 이때 건축에서 곧장 수입된 것이다.

셋째, 병리학을 만들었다. 이 논문은 아키텍처 침식(erosion) — 구현이 아키텍처의 의도를 조금씩 위반하며 무너지는 현상 — 과 표류(drift) — 위반은 아니지만 의도가 흐려지는 현상 — 를 명명했다. 아키텍처가 “그리는 것”만이 아니라 “지키는 것”이라는 문제의식이 여기서 시작된다.

4. 1996년, 교과서의 등장 — Shaw & Garlan

1996년 Mary Shaw와 David Garlan(카네기멜론)이 『Software Architecture: Perspectives on an Emerging Discipline』을 출간한다. 부제가 정직하다 — “떠오르는(emerging) 분야에 대한 관점”. 이 책이 한 결정적 기여는 스타일의 카탈로그화다. 파이프-필터, 레이어드, 블랙보드, 이벤트 기반, 클라이언트-서버… 실무에 흩어져 있던 구조 관행들을 수집하고, 이름 붙이고, 각각의 제약과 트레이드오프를 비교 가능하게 만들었다.

이름이 생기면 비로소 비교할 수 있고, 비교할 수 있으면 선택할 수 있다. “우리 시스템은 레이어드로 간다”라는 문장이 공학적 결정이 된 것은 이 카탈로그 덕분이다. 우리가 Part 2에서 하려는 일 — 스타일들을 계기와 트레이드오프로 비교하는 것 — 의 원형이 바로 이 책이다.

이후 정의는 표준으로 제도화된다. 2000년 IEEE 1471은 아키텍처를 “컴포넌트들과 그 관계, 그리고 설계와 진화를 이끄는 원칙에 구현된, 시스템의 근본적 조직(fundamental organization)“으로 정의했고, 2011년 국제 표준 ISO/IEC/IEEE 42010으로 개정되면서 이렇게 다듬어진다:

“아키텍처란 환경 속 시스템의 근본적 개념 또는 속성으로, 요소들과 그 관계, 그리고 설계와 진화의 원칙에 구현되어 있는 것이다.” — ISO/IEC/IEEE 42010:2011

두 판본 모두에 들어 있는 “설계와 진화의 원칙”이라는 구절에 주목하라. 표준조차 아키텍처를 정적 구조로만 보지 않는다.

5. 정의 경쟁 — 구조인가, 결정인가, 비용인가

여기까지 오면 “아키텍처의 정의”가 하나가 아니라는 것이 보인다. 크게 세 진영이 있고, 셋 다 옳으며, 각각 다른 순간에 유용하다.

진영 1: 아키텍처 = 구조 (structure)

가장 고전적인 답. 요소와 관계, 컴포넌트와 커넥터. Perry & Wolf의 {elements, form}, Shaw & Garlan의 스타일 카탈로그가 이 계열이다. 유용한 순간: 시스템을 처음 파악할 때, 스타일을 선택할 때.

진영 2: 아키텍처 = 중요한 결정 (decisions)

Grady Booch의 정의가 대표적이다.

“아키텍처는 중요한(significant) 설계 결정들의 집합이다. 여기서 ‘중요함’은 변경 비용으로 측정된다.”

이 관점에서 아키텍처 문서란 다이어그램 모음이 아니라 **결정 대장(臺帳)**이다. Perry & Wolf의 rationale이 이 진영의 뿌리다. 유용한 순간: 설계를 진행하며 무엇을 먼저 확정하고 무엇을 미룰지 정할 때.

진영 3: 아키텍처 = 바꾸기 비싼 것 (hard to change)

2003년 Martin Fowler는 「Who Needs an Architect?」라는 짧은 글에서 Ralph Johnson의 메일링 리스트 발언을 인용한다. Johnson의 정의는 두 개인데 둘 다 도발적이다.

“아키텍처란 전문 개발자들이 시스템 설계에 대해 공유하는 이해다.”

“아키텍처란 중요한 것에 관한 것이다. 그게 무엇이든(whatever that is).”

문서도 다이어그램도 아니고, 팀의 머릿속에 있는 공유된 그림이 진짜 아키텍처라는 것. 그리고 Fowler 자신의 실용적 결론:

“아키텍처란 바꾸기 어려운 결정들, 그리고 우리가 처음부터 잘 결정하기를 바라는 것들이다.”

이 정의의 힘은 역방향 추론을 가능하게 한다는 데 있다. “무엇이 아키텍처인가?”라고 묻는 대신 “무엇이 바꾸기 비싼가?”라고 물어라. 언어 선택, DB 선택, 서비스 경계, 데이터 모델 — 바꾸기 비싼 것이 곧 그 시스템의 아키텍처다. 그리고 한 발 더: 바꾸기 비싼 것을 줄일 수 있다면, 아키텍처라는 짐 자체를 줄일 수 있다. 이 반전이 Part 2 후반(진화적 아키텍처)의 복선이다.

세 정의를 하나로

세 진영을 겹쳐 보면 이 책에서 쓸 작업 정의가 나온다.

아키텍처란, 시스템에 대한 결정 중 되돌리기 비싼 것들과 그 근거이며, 구조는 그 결정이 남긴 흔적이다.

다이어그램은 흔적의 스냅샷일 뿐이다. 이 문장을 기억하면 Part 2의 모든 장이 같은 질문으로 읽힌다 — “이 스타일은 어떤 결정을 되돌리기 쉽게 만들기 위해, 어떤 결정을 먼저 고정했는가?“

6. 흔한 오해 바로잡기

오해 1: “아키텍처 = 다이어그램이다.” 다이어그램은 아키텍처의 표현 중 하나이고, 그나마 rationale(근거)은 담지 못한다. 박스와 화살표가 같아도 “왜”가 다르면 다른 아키텍처다. 다이어그램이 최신 코드와 다른 순간부터는 표현조차 아니다 — 그냥 낡은 그림이다.

오해 2: “아키텍처는 프로젝트 초기에 하는 일이다.” Perry & Wolf가 침식과 표류를 명명한 순간부터, 아키텍처는 “초기 산출물”이 아니라 “지속적으로 지켜야 하는 것”이었다. 42010 표준의 “진화의 원칙”도 같은 말을 한다.

오해 3: “아키텍트라는 직함이 아키텍처를 만든다.” Ralph Johnson의 정의(“전문 개발자들이 공유하는 이해”)를 뒤집으면: 팀이 공유하지 않는 아키텍처는, 아키텍트가 그렸어도 존재하지 않는 것이다. Fowler의 원글 제목이 “누가 아키텍트를 필요로 하는가?”인 것 자체가 이 반문이다 — 그 글의 본론은 정의가 아니라 아키텍트라는 역할에 대한 재검토다.

오해 4: “1968년 NATO 회의에서 소프트웨어 아키텍처가 탄생했다.” 그 회의가 만든 것은 “소프트웨어 공학”이라는 말과 “위기”라는 문제의식이다. 아키텍처의 학문화는 1992년 Perry & Wolf부터다. 24년의 간격 — 질문과 답 사이의 거리 — 자체가 이 분야의 난이도를 말해준다.

7. 요약, 그리고 다음 장으로

• “아키텍처”는 건축에서 빌린 은유이며, 소프트웨어에는 하드웨어(IBM System/360, 1964)를 경유해 들어왔다. 처음부터 “구현이 아니라 지켜야 할 약속(개념 구조와 인터페이스)“이라는 의미였다.
• 1968년 NATO 회의는 소프트웨어 공학과 소프트웨어 위기의 출발점이다. 아키텍처의 학문화는 Perry & Wolf(1992) — {요소, 형상, 근거} — 와 Shaw & Garlan(1996) — 스타일 카탈로그 — 가 만들었다.
• 정의는 경쟁한다: 구조 / 중요한 결정 / 바꾸기 비싼 것. 이 책의 작업 정의: 아키텍처란 되돌리기 비싼 결정들과 그 근거이며, 구조는 그 흔적이다.
• 아키텍처는 다이어그램이 아니고, 초기 단계 산출물도 아니며, 직함의 산물도 아니다.

다음 장 예고 (Step 02): 단어의 역사를 알았으니, 이제 이 단어가 풀려는 문제를 정면으로 본다. 소프트웨어는 왜 본질적으로 어려운가(Brooks), 복잡성 앞에서 인류가 찾아낸 무기 — 관심사의 분리(Dijkstra), 정보 은닉(Parnas), 결합도와 응집도(Constantine) — 는 무엇이었는가. 1968년의 “위기”에 1970년대가 내놓은 답들이다.

원전