아키텍처는 무엇인가 정의에 대해서 살펴본다. 아키텍처에 대해서 먼저 살펴보자! Let’s get started with the concept with Architecture!

1

2

자연, 수학, 음악, 건축에 일관성이 있다는 것에서 참 경이로운 생각이 든다. 1, 1로 시작해서 전항을 더해서 다음 항을 만들어가면 1, 1, 2, 3, 5, 8, 13, … 피보나치 수열이 되는데, 이는 황금비율에 근접한다. 자연에 많은 것이 이 피보나치 수열을 따르고 사람은 아름다움을 느낀다. 이 중에서 2, 3의 비율에 대해서 소리로 만들어도 아름답게 들리는데, 이의 중간 비율 2, 2.5, 3도 잘 어울린다. 4, 5, 6. 이 비율로 만들 수 있는 비가 *4를 하면 16, 20, 24이고 *6을 하면 24, 30, 36이다. *9를 하면 36, 45, 54이다. 24와 이의 두 배인 28 사이에 오도록 이들 숫자를 2를 곱하거나 나누면 24, 27, 30, 32, 26, 40, 45, 48이 나오는데, 이를 비율로 맞추면 도, 레, 미, 파, 솔, 라, 시, 도의 음계가 나온다. 건축에도 아름다운 건물을 보면 황금비가 들어있는 게 있는데, 참 아름답게 느껴진다. 자연, 수학, 음악, 건축에서 이런 아름다운 비율을 봤고, 그래서 예전의 철학자들은 건축은 얼은 음악이다는 말을 한 것일지도 모르겠다. 음악이 여러 음표와 화음이 어우러져 아름다운 소리를 내듯이, 건축 또한 개개의 요소들이 복잡한 관계를 통해서 아름다운 앙상블을 만들어낸다. 시스템 또한 건축과도 같다. 그리고 소프트웨어는 시스템을 담당하는 요소이면서도 디자이너가 좀더 유동적이고flexible, 유능하고capable, 지능적인intelligent 시스템을 만들 수 있도록 한다.

3

기원전 1세기 당시 로마에서 유명한 건축가였던 비트루비우스가 한 말이다. 건축으로 세운 구조는 의도했던 용도를 만족해야 하고, 물리적으로 튼튼해야 하며, 보기에 아름다워야 한다고 말했다. 또 비트루비우스는 최고의 아키텍처 디자인은 원래 용도를 넘어서는 것이라고도 말했다. 여러 작은 부분들을 세워 하나의 큰 건축물을 만들었을 때, 제 각각의 특성을 넘어서는, 원래의 용도를 넘어서는 질서, 배치, 조화, 대칭, 적절성, 경제성, 미학까지 갖추게 될지도 모른다. 이를 두고 최고의 아키텍처 디자인이라고 했겠지.

4

옥스포드 영어 사전에서 Architecture를 찾아보면 여러 가지 정의들이 나온다. - 일단 짓는 행위들이 있고, - 이 행위들의 결과로 디자인, 구조, 건물이 있다. - 눈에 보이는 건물 뿐만 아니라 개념적인 구조나 논리적인 조직에도 쓰이는데, 특히 컴퓨터나 컴퓨터 기반 시스템에서 언급된다.

5

아키텍트가 아키텍처를 만들 때 고려하는 두 가지 축. 먼저, 복잡한 시스템을 작은 요소로 분해한다. 이 때, 아키텍트는 자신의 경험과 직관을 활용한다. 그러면 복잡한 시스템을 이해하기가 쉬워지는데, - 이 시스템이 어떤 요소로 구성되어 있는지, - 이 시스템을 구성하는 요소의 특성은 무엇인지, - 이 요소는 서로 어떻게 상호작용하는지를 쉽게 파악할 수 있게 된다. 또, 아키텍트는 아키텍처를 만들 때, 복잡한 시스템 전체를 표현하는 것이 아니라 세부적인 사항이나 군더더기는 생략한다. 이는 시스템의 핵심, 골격만 뽑아내는 것과 같고, 일단 시스템의 핵심사항이 아키텍처에 담아냈으면, 이후 세부적인 사항들을 채우는 일은 다음 단계에서 일하는 디자이너들에게 맡겨진다.

6

아키텍처는 단순한 그림일까? 그렇지 않다!

7

아키텍처를 이루는 두 가지 큰 요소. 진짜 아키텍처는 단순한 그림이 아니라 - 요소와, - 요소 사이의 관계로 이루어진다. 그리고 요소와 이들 사이의 관계로 이루어진 아키텍처는 한 차원이 아니라 다차원이다. 지도를 예로 들면, 3차원의 실공간을 지도라는 2차원에 모두 표현할 수 없기 때문에 무엇을 표현하고 무엇을 생략할지 선택이 필요하다. 기상 상황을 알고자 할 때는 한 시점의 기상만 나타낸 기상도가 쓰일 테도, 운전할 때는 도로를 잘 표현한 도로도, 바다에서 배로 항해할 때는 해도, 비행기로 하늘을 날 때는 항공도 등이 쓰인다. 아키텍처는 복잡한 시스템을 분해하고 세부적인 부분을 생략하여 만들어진 것이기에, 시스템의 다양한 구조를 표현하기 위해서는 다차원이어야 한다.

8

집을 예로 들어보면 보다 명확해진다. 집을 짓기 위해서는 순서에 따라서 여러 가지 도면이 필요한데, - 기초 공사 부분은 어떻게 할지에 대한 도면이 필요하고, - 기둥과 천장 등 뼈대 부분에 대한 도면이 필요하다 - 뼈대가 갖추어졌으면 냉난방과 전기, 수도, 전화 등의 설비를 하기 위한 도

면이 필요하고, - 벽과 천장 등을 마감하기 위한 도면도 필요하다.

집 한 채를 짓기 위해서도 다양한 도면이 필요한데, 복잡한 컴퓨터 시스템을 구축하기 위해서는 다양한 각도에서 살펴봐야 한다는 것을 당연하다.

9

또, 집을 구조적인 측면에서 뿐만 아니라 우리가 집에서 생활하면서 느낄 수 있는 사항들, 예로 들면 - 우리가 편안함을 느낄 만큼 충분히 큰지 - 낮에 불을 켜지 않고도 생활할 만큼 빛을 충분히 들어보고 밝은지 - 겨울철 난방과 여름철 냉방을 할 때 적은 돈으로도 충분한 효과를 볼 수 있

도록 단열 단풍은 얼마나 잘 되며, 통풍은 얼마나 잘 되는지 - 사람들이 방과 방 사이를 이동하는데, 얼마나 효과적인지, 문을 열고 닫는데

불편함은 없는지 - 차후에 집을 고치는 데는 불편함은 없는지 에 대한 사항들도 아키텍처에서 고려해야 할 중요한 영역이다. 집 1번에서 짚어본 집의 구조와 기능에 대한 사항들은 같은 장의 뒷부분에서 나오는 기능성 Functionality와 맥을 같이 하고 있으며, 집 2번에서 언급한 사용하며 얻게 될 사항들은 마찬가지로 같은 장 뒷부분에 언급되는 질적 속성 요구사항 Quality attribute requirements와 맥을 같이 한다.

10

행동적 속성 Behavioral properties은 - 기능성 Functionality - 기능적 요구사항 Functional requirements라는 말로도 쓰인다.

11

이 비행동 속성 Nonbehavioral properties - 질적 속성 요구사항 Quality attribute requirements (Bass et al., 2002) - 비기능적 요구사항 Non-functional requirements라는 말로도 이른다. - 성능performance, 변경가능성modifiability, 상호운용성interoperability, 보

안security 등의 속성을 포함한다. 뒷부분에 비행기에 대해서도 나온다. 하늘을 나는 것이 비행기의 핵심 기능이라면, 연료 효율이라든지, 탑승객 수라든지, 승객석의 아름다움과 같은 사항들은 질적 속성에 대한 요구사항이다.

12

이 행동 속성과 비행동 속성은 서로 연결되는 경우가 있는 반면에 상충하는 경우가 있다. 가령 집을 크게 하면 널찍하고 좋지만 에너지 효율이 떨어진다. 그래서 둘 다를 만족할 수 없는 상황, 어느 하나의 이점을 취하면 다른 하나의 단점을 감수해야 하는 상황이 발생한다. 이렇게 서로 상충할 수 있는 행동 속성과 비행동 속성에서 균형balance을 맞추어야 하는 것이 중요하고, 더욱이 이해당사자들이 수용하는지가 핵심 판단 기준이다! 집에 문을 문을 여러 개를 두면 드나들기가 편리하지만, 도둑질 당하기 쉽듯이 시스템에서 성능을 높이려다가 보안이 취약해지는 경우가 생길 수 있다. 한 속성의 이점을 올리는 대신에 상충되는 다른 속성의 단점을 감내하는지 판단하기 위해서는 언급했듯이 우선 이해당사자들이 충분히 수용할 수 있는지를 봐야 하고, 아키텍처를 통해서 얼마나 상충하는 속성들의 주고 받는 점tradeoffs가 생기는지를 판단하여 결정한다.

13

14

시스템이라는 용어부터 역사적인 맥락에서 살펴보자. 맥락에 따라서 “잘한다”는 말이 정말 잘해서 잘한다는 말이 될 수도 있고, “잘~한다”고 비꼬는 말이 될 수도 있듯이, 역사를 되짚어보면 시스템의 의미를 훨씬 더 잘 이해할 수 있을 것이다. 이 용어는 한 세기 이상, 다양한 분야에서 점점 더 복잡한 것을 다루면서 진화해왔다.

15

먼저 19세기 이전을 살펴보자. 19세기 이전에는 시스템이 기술적인 용어로는 쓰이지 않았다. 단지 - 생체 시스템 - 사회 시스템 (법률, 정치, 종교 등) - 생태 시스템 - 행성 시스템 에서만 쓰였다.

16

1830년경에 미국 대륙 철도 시스템이 개발되었는데, 시스템이라는 용어가 기술적으로 쓰인 최초다. 당시 철도는 미로와도 같이 굉장히 복잡하게 얽혀 있었다. 철도 시스템은 기본적인 - 기차와 철로 외에도 - 물과 석탄을 공급하는 역과 - 유지 보수를 담당하는 시설과 인력 - 경로를 설정하는 나들목 등 여러 가지 인력과 설비가 있는 복잡한 시스템이었다. 이러한 시스템의 복잡함 외에도 여러 가지 문제들이 속속 나타나기 시작했는데, - 서로 호환되도록 표준에 맞는 부품들을 디자인은 어떻게 할 것이며 - 기차의 시간 배분 등의 일정 관리는 어떻게 할 것인지, - 다양한 인력의 배치는 어떻게 할 것인지 등에 관한 문제들은 그 당시 공학 지식으로는 해결하기 힘든 부분이었다.

17

1880년경에는 전력과 통신시스템이 발명되었다. 이 시스템은 초기에 여러 지역에서 따로 따로 작은 단위로 개발이 되어서, 서로 멀리 떨어져 있고, 서로 달랐다. 그래서 분산되어 있고, 서로 호환이 되지 않는 시스템을 서로 연결하는 것이 상당히 복잡하여, 어려웠을 뿐만 아니라 비용도 많이 들었다. - 전체를 아우르는 시스템을 디자인하고 high-level systemic design - 인터페이스 표준화 에 대한 필요성이 생기기 시작했다.

18

이러한 시대적 필요성에 의해서 1920년경에 AT&T에서는 시스템을 디자인할 때 - 일정의 형식과 - 규칙을 집어넣으려는 시도가 있었고, 실제로 시스템 개발부systems development department라는 부서도 두었다.

19

2차 세계대전과 이후에는 엄청나게 기술이 발달하면서 시스템도 고도로 복잡해졌다. 이런 기술 발달의 선봉에는 미국 공군 아래 새롭게 만들어진 RAND와 같은 미국의 군사 산업이 있었다.

- 트라이던트 잠수함 시스템, - 현대의 공군 수송기 시스템, - 대륙간 탄도 미사일 시스템, - 우주 위성 시스템 과 같이 고도의 기술이 집약된 아주 방대하고 복잡한 시스템을 구축하고, 작동시키고, 유지보수하기 위해서 표준화되고 형식적인 시스템 공학이 나타나기 시작했다. 그래서 Rear Admiral Grace Hopper라는 사람은 “~~~~~~~~“ 이와 같은 말도 했다.

20

이 책에서 원하는 시스템에 대한 정의다. 시스템에는 다양한 요소도 있지만 이들이 밀접하게 연결되어 특정한 기능을 구현한다. - 여러가지 요소elements와 - 이들 사이의 관계relationships까지를 아우른다.

21

22

여기까지 아키텍처와 시스템의 역사적인 맥락에 대해서 살펴보았다. 이제는 좀더 구체적으로 - 시스템 아키텍처 - 엔터프라이즈 아키텍처 - 소프트웨어 아키텍처에 대해서도 살펴보자

이 세 가지는 아래 같은 맥락을 통해 다음과 같이 정의할 수 있다 (다음장) 이 정의를 통해서 아키텍처가 어떤 특성이 있는지 파악해보자.

23

24

구조 엔터프라이즈 아키텍처, 시스템 아키텍처, 소프트웨어 아키텍처는 모두 다수의 구조를 지닌다. 구조는 시스템 상에서 구현되어implemented 있는 부분이다. 집에 비유하면 기초 구조, 기둥 구조, 지붕 구조와 같이 여러 개의 구조로 구성되어 있다.

25

요소 코끼리를 먹으려면 한입한입 베어 먹으라는 말이 있다. 시스템이라는 엄청나게 덩치 큰 코끼리를 먹을 때도 마찬가지 방법이 쓰여진다. 복잡한 시스템을 통째로 다루기에는 불가능해, 다룰 수 있는 작은 단위로 분해하는데, 이게 바로 요소이다. 소프트웨어 요소로는 - 코드 유닛 - 데이터 스토어 - 클래스 - 오브젝트 - 프로세스 - 쓰레드 - 태스크 와 같은 것들이 있다.

26

속성에는 기능적 속성functional responsibility과 질적 속성quality attribute properties이 있는데, 먼저 기능적 속성에 대해서 살펴보자. 아키텍처를 구성하려면 여러 가지 기능이 필요한데, 어떤 요소가 어떤 기능을 맡을지 정하는 것이 우선 필요하다. 집을 예로 들면, 부모님이 사용하시는 방과 손님이 머무는 기능이 필요한데, 안방에서 부모님이 머물고, 사랑방에서 손님이 머물도록 하는 형식이다. 실제 아키텍처에서도 서비스나 데이터를 제공하는 요소가 필요하고 또, 제공받는 요소도 필요한데, 이런 기능적 속성을 어떤 요소에 할당하는지 정해야 한다. - 제공하는 요소를 제공 어썸션 provides assumptions이라 하고, - 제공 받는 측의 요소를 요청 어썸션 requires assumptions이라 한다.

다음으로 질적 속성quality attribute properties에는 성능, 안정성reliability, 유효성availability, 보안이 있는데, 이를 맡는 요소도 정해야 한다. 집을 예로 들면 눈이 편안함이 드는 속성을 추가하기 위해서 녹색벽지를 바른다.

27

관계relationships 관계는 요소들 사이에서 일어나는 상호작용이다. 집에서는 싱크대라는 요소에 물을 내리면 싱크대 밑에 있는 배관이라는 요소를 통해 물이 빠진다.

28

사리넨이 한 이 말은 일리 있다. 책장이 필요해서 사들일 때는 반드시 방의 크기를 감안해야 하고, 집을 지을 때, 각 방의 크기는 집 전체 평수를 고려해서 정해야 한다. 그리고 집의 양식을 정할 때는 주변 집이나 분위기를 고려해서 양옥이든 한옥이든 맞추어야 한다. (작년에 집을 지을 때 문화재 주변에 있어서 한옥 양식으로 지어야만 했다) 복잡한 시스템을 아키텍트 한 명이 모두 설계하는 것은 불가능하여, 다수의 아키텍트가 힘을 합쳐서 구축하기 마련이다. 그래서 아키텍트는 설계할 때, 맥락을 고려해야 하고, 다른 아키텍트의 디자인이 자신의 디자인에 주는 영향과 반대로 자신의 디자인이 다른 아키텍트에게 미칠 영향을 고려해야 한다. 이를 디자인 계층Design hierarchy이라고 이른다.

29

서로 다른 층위의 아키텍트가 설계한 디자인이 다른 아키텍트에게 영향을 주는 예다. 엔터프라이즈 아키텍트가 디자인한 엔터프라이즈 디자인은 시스템 아키텍트에게 영향을 준다. 시스템 아키텍트는 이 영향 아래, 자신이 좀더 구체적인 사항을 디자인에 반영하는데, 이는 또 아래 소프트웨어 아키텍트에게 영향을 주는 식으로 주게 된다. 이렇게 서로 다른 디자인 계층에서 여러 아키텍트들이 디자인한 것을 통합하여, 시스템에 기능적인 속성과 질적 속성이 띄도록 해야 하는데, 과연 가능할까?

30

이쯤에서 개념적 무결성에 대해서 짚고 넘어가보자. 한 시스템이 하나의 동작에서는 언제나 같은 방법으로 동작한다면, 많은 이점이 생기는데 - 아키텍처를 이해하기가 쉬워지고, - 개발 시간이 단축되고, - 신뢰성reliability이 높어지며, - 변경가능성modifiability 등을 강화할 수 있다. 하지만, 시스템의 아키텍처를 만드는 데만 해도 수많은 - 엔터프라이즈 아키텍트 - 시스템 아키텍트 - 소프트웨어 아키텍트 가 관여하는데, 과연 이 개념적 무결성이 가능한 일일까? 아키텍트들은 결정을 해야하는 상황을 자주 마주하는데, 이 많은 아키텍트들이 같은 방법으로 같이 동작이 동작하겠금 결정을 일관적으로 내릴 수 있을까? - 특히, 이 결정은 한번 내려지면 그 잠재적인 영향력이 아주 커서, 전체 시스

템, 엔터프라이즈, 소프트웨어, 하드웨어 뿐만 아니라 이해당사자들에게까지 영향력이 미친다.

31

(다음장: 그래서 지역적으로건 광역적으로건 중간에서 균형을 맞춰주고 조율해주는 리더 아키텍트에 대한 필요성이 생기게 된 것이다. )

31

그래서 지역적으로건 광역적으로건 중간에서 균형을 맞춰주고 조율해주는 선임 아키텍트에 대한 필요성이 생기게 된 것이다.

32

33

34

35

36

예로, 보잉사는 앞으로 국내선이 더 활발해질 것이라고 보고, 규모가 작은 B787기를 만든 반면에, 에어버스사는 앞으로 국제선이 더 활발해질 것이라고 보고, 규모가 큰 A380기를 만드는데 전력을 다한다. 서로 상대방의 기종을 만들 수 있는 기술이 충분히 있음에도 불구하고, 시장을 보는 눈과 비즈니스 목표가 달랐기 때문에 서로 다른 판단을 했다. 이렇든 아키텍트는 반드시 기술적인 성취 뿐만 아니라 비즈니스를 바라보는 눈과 흐름(문맥)을 보는 눈이 반드시 필요하다.

37

38

39