아키텍쳐란 무엇인가?
"비유라는 것이 늘 그렇듯이 아키텍쳐라는 랜드를 통해 소프트웨어를 살펴보면 알 수 있는 것 만큼이나 숨겨진 것도 있게 마련이다. 그래서 아키텍쳐가 실제로 제공할 수 있는 것 이상을 약속하기도 하지만 약속한 것보다 많은 것을 제공할 때도 있다."
"큰 소프트웨어 구조물은 작은 소프트웨어 컴포넌트로 만들어지며, 이 컴포넌트는 더 작은 컴포넌트로 만들어지고 계속 이런식이다. 마치 코딩하는 거북이들이 연쇄적으로 서로를 떠받치고 있는 형태다. 우리가 이야기하는 소프트웨어 아키텍쳐에서 소프트웨어는 본질적으로 재귀적이고 프랙털 구조로 되어있으며..."
"건축에는 명확한 물리적 구조가 있다... 이런 구조에는 선택권이 별로 없는데 중력과 건축 자재의 물리적 특성에 크게 좌우되기 때문에이다. 반명에 소프트웨어는 중력과는 상관이 없다... 소프트웨어는 마치 꿈을 구성하는 재료와 같지만 실행되는 곳은 물리적인 세계다."
"소프트웨어 아키텍처의 규칙이란 프로그램의 구성요소를 정렬하고 조립하는 방법에 관한 규칙이다. 그리고 이 구성요소가 보편적이고 변하지 않았으므로 이들을 정렬하는 규칙역시도 보편적이며 변한 것이 없다."
아키텍쳐와 설계의 차이는 무엇인가?
"아키텍쳐는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되는 반면 설계는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. 하지만 아키텍트가 실제로 하는 일을 살펴보면 이러한 구분은 무의미하다. 새로운 집을 설계하는 아키텍트가 있다고 하자. 이 집은 아키텍쳐를 가지고 있는가? 당연히 있다. 그렇다면 그 집의 아키텍쳐는 무엇인가? 아마 집의 형태 외관 입면도 공간이나 방의 배치 등이 여기에 포함된다. 하지만 아키텍트가 만든 도면을 살펴보면 무수히 많은 저수준의 세부사항도 확인할 수 있다. 콘센트 전등 스위치 전등이 모두 어디에 위치하는지를 도면에서 알 수 있다. 보일러는 어디에 놓이고 온수기와 배출 펌프의 크기와 위치는 어떻게 되는지 역시 볼 수 있다. 벽 지붕 그리고 기초공사가 어떻게 진해될지도 상세히 확인할 수 있다... 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다. 이 둘은 단절 없이 이어진 직물과 같으며 이를 통해 대상 시스템의 구조를 정의한다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분짓는 경계는 뚜렷하지 않다. 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐이다."
좋은 아키텍쳐란 무엇인가?
"아키텍쳐는 시스템을 구체화하는 중요한 설계결정을 표현하며, 그 결정의 중요도는 변경에 드는 비용으로 측정된다. -그래디 부치"
"좋은 아키텍쳐는 사용자 개발자 소유자의 요구를 특정시점에도 반드시 충족시켜줄뿐만 아니라 시간이 흐르더라도 계속 충족시켜준다."
"나는 수많은 앱을 만들었다. 수많은 시스템을 구축했다. 그리고 이 모두를 경험하고 고민한 끝에 놀라운 무언가를 깨달았다. 아키텍쳐 규칙은 동일하다!.. 1960년대나 1950년대와 마찬가지로 코드는 여전히 순차 분기 반복의 집합체일 뿐이다. 컴퓨터 프로그래밍을 하는 관행을 정말 유심히 관찰해보면 지난 50년 동안 변한게 거의 없다는 사실을 깨달을 것이다. 언어는 조금 발전했다. 도구는 환상적으로 좋아졌다. 하지만 컴퓨터 프로그래밍을 이루는 기본 구성요소는 조금도 바뀌지 않았다."
좋은 아키텍쳐를 만드는 것의 어려움
"아키텍쳐란 프로젝트 초기에 제대로 정할 수 있기를 바라는 결정사항이지만 제대로 정할 가능성이 그 외사항들보다 반드시 더 높지는 않다."
"아키텍쳐는 구현과 측정을 통해 증명해야하는 가설이다. -톰 길브"
"우리가 가장 관심있는 길은 바로 가장 깔끔한 길이다. 이 길은 소프트웨어가 지닌 부드러움을 인지하고 이 부드러움을 시스템에서 최우선으로 보존하는 것을 목표로 한다. 이 길은 우리가 불완전한 지식에 기초해 행동한다는 사실을 인정할 뿐만 아니라 불완전한 지식으로 행동하는 것이야 말로 인간으로서 우리가 무엇인가를 하는 방식이며 우리의 뛰어난 부분임을 이해한다. 이 길은 우리의 약점보다는 강점을 활용한다. 우리는 무언가를 만들고 또 발견한다. 질문을 던지고 실험을 한다. 아키텍쳐는 종착지가 아니라 여정에 더 가까우며 고정된 산출물이 아니라 계속된 탐구과정에 더 가까움을 이해해야 좋은 아키텍쳐가 만들어진다."
좋은 아키텍쳐의 효과는 무엇인가?
"빨리 가는 유일한 방법은 제대로 가는 것이다. -로버트C마틴"
"소프트웨어를 제대로 만들게 되면 마법과 같은 일이 벌어진다. 소수의 프로그래머만으로 프로그램이 지속적으로 동작하도록 만들 수 있다. 거대한 요구사항 문서와 이슈가 수없이 등록된 이슈 추적 시스템도 필요가 없다. 전 세계의 칸막이로 나뉜 작은 사무실에서 휴일도 없이 일해야 하는 프로그래머가 없어도 된다. 제대로 된 소프트웨어를 만들면 아주 적은 인력만으로도 새로운 기능을 추가하거나 유지보수할 수 있다. 변경은 단순해지고 빠르게 반영할 수 있다. 결함은 적어지고 잦아든다. 최소한의 노력으로 기능과 유연성을 최대화할 수 있다... 휼륭한 소프트웨어 아키텍쳐가 시스템 프로젝트 팀에 놀라운 효과를 가져오는 것을 확인했다. 나는 천국에 가 보았다."
"소프트웨어 아키텍쳐의 목표는 필요한 시스템을 만들고 유지보수하는데 투입되는 인력을 최소화하는데 있다. 설계품질을 재는 척도는 고객의 요구를 만족시키는데 드는 비용을 재는 척도와 다름없다. 이 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계라고 말할 수 있다. 새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계다. 좋은 설계라 이처럼 단순명료하다."
아키텍쳐는 어떻게 간과되는가?
"대다수 개발자는 뼈 빠지게 일한다. 하지만 그들의 뇌는 잠에 취해있다. 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 바로 그 뇌가 잠자고 있다. 이들 개발자는 코드는 나중에 정리하면 되. 당장은 시장에 출시하는게 먼저야라는 흔해빠진 거짓말에 속는다. 이렇게 속아 넘어간 개발자라면 나중에 코드를 정리하는 경우는 한번도 없는데 시장의 압박은 절대로 수그러들지 않기 때문이다... 이는 그저 진실을 오인할 것뿐이다. 진실은 다음과 같다. 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다. 시간척도를 어떻게 보든지 관계없이 말이다... 빨리가는 유일한 방법은 제대로 가는 것이다."
나쁜 아키텍쳐의 부작용은 무엇인가?
"변경비용이 크면 변경 자체를 제거한다. 변경의 원인이 묵살되거나 관료적인 이유로 잘려나간다. 아케텍트의 권한은 전면적이고 전체주의적이며 아키텍쳐는 개발자에게 암울한 미래를 비추며 모두에게 끝없이 좌절감을 안겨주는 원천이 된다."
"팀 부서 심지어 회사 전체가 형편없는 소프트웨어 구조로 인해 실패한 적은 없었나? 프로그래밍 지옥을 경험하지 않았나? 나를 포함해서 우리 대다수는 대체로 이러한 경험을 했다. 훌륭한 소프트웨어 설계를 바탕으로 작업하면서 즐거움을 느끼기보다는 형편없는 소프트웨어 설계와 맞서 싸우는 일을 훨씬 더 자주 맞닥뜨린다."
"개발자의 노력은 기능개발보다는 엉망이 된 상황에 대처하는데 소모되기 시작한다. 심지어 사소한 기능을 추가하는 일도 그저 엉망이 된 코드를 이곳에서 저곳으로 다시 다음곳으로 이동하는 반복작업으로 변질된다. 개발자들이 쏟은 노력의 가치가 결국 보잘것없게 된다."
"개발자는 처음부터 다시 시작하여 전체 시스템을 재설계하는 것이 해답이라고 생각할지도 모른다. 하지만 이 또한 토끼의 말과 다름없다. 엉망으로 내몰았던 바로 그 과신이 경주를 다시 시작한다면 더 나은 코드를 만들 수 있다고 말하고 있는 것이다. 현실은 장밋빛 기대와는 거리가 멀다. 자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰인다."
뛰어난 아키텍트가 되기 위해 무엇을 해야하는가?
"프로그램이 동작하도록 만드는데 엄청난 수준의 지식과 기술이 필요하지는 않다... 하지만 프로그램을 제대로 만드는 일을 다르다. 소프트웨어를 올바르게 만드는 일은 어렵다... 소프트웨어를 올바르게 만들려면 무엇보다도 기술을 향한 열정과 전문가가되려는 열망이 필수다."
"소프트웨어 아키텍쳐를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍쳐가 무엇인지 이해해야 한다. 비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍쳐를 가진 시스템을 만들려면 이러한 결과로 이끌어줄 시스템 아키텍쳐가 지닌 속성을 알고 있어야 한다."
