'손맛'으로 풀어보는 아키텍처의 세계

개발자들에게 있어서 아키텍트(Architect)는 어떤 모습으로 그려지고 있는가? 과연 그들이 대다수의 프로그래머와 구별되는 속성은 무엇인가? 매뉴얼적인 접근으로는 결코 규정할 수 없는 이른바 ‘손맛’의 힘을 통해 아키텍트와 아키텍처의 세계를 바라보고, 이어서 프로그래머가 아키텍트로 거듭날 수 있는 구체적인 방법론을 제시해 본다. 

『조엘 온 소프트웨어』의 ‘빅맥 VS. 제이미는 요리사’ 챕터에서 일류 요리사와 맥도날드 주방장에 대한 이야기가 소개된다. 맥도날드는 어느 나라에서도 같은 맛(품질)의 햄버거를 제공하기 위해 두꺼운 매뉴얼을 제작했다. 이 매뉴얼대로만 만든다면 누구나 똑 같은 맛의 햄버거를 만들 수 있다. 이 말은 곧 개인의 능력이나 IQ에 의해 햄버거 맛이 달라지지 않는다는 의미다. 즉, 누구도 만들 수 있는 매뉴얼에 의해 맛은 하향 평준화된다. 반면 제이미라는 일류 요리사는 듬성듬성, 대충대충 요리하는 듯하다. 소금이 더 들어가면 다른 재료로 맛을 상쇄시키기도 하고, 굳이 초 단위의 정확한 시간에 맞춰 오븐을 열지도 않는다. 보통 우리는 이런 기술을 ‘손맛’이라고 표현한다.

책의 주제와 다른 얘기지만 요리사가 가지고 있는 ‘손맛’과 주방장이 가지고 있는 ‘매뉴얼’의 차이에서 삼천 원짜리 햄버거가 만들어지기도 하고, 몇 만 원짜리 햄버거가 만들어지기도 한다. 사실 일류 요리사는 자신이 가지고 있는 노하우를 널리 알려 맥도날드와 같은 신화를 만들고 싶었을 것이다. 하지만 요리사가 그렇게 하지 못하는 이유는 그런 ‘손맛’을 매뉴얼화할 수 없기 때문이다. 즉 매뉴얼화할 수 있는 ‘손맛’이라면 이미 ‘비법’으로서의 신비함을 잃어 결국 ‘손맛’이 아니게 된다(아마 맥도날드처럼 될 것이다). 다시 말해 이 ‘손맛’의 비결은 지난하고 치열한 트레이닝과 연구를 통해 얻어진 결과인 셈이다. 그래서 ‘손맛’은 같은 과정을 겪지 않으면 설명할 수조차 없는 궁극의 ‘비법’이 된다.

마이클 폴라니는 이 ‘손맛’을 ‘암묵지(暗默知)’로 규정했다. 그는 암묵지를 “언어, 문장으로 표현하기 어려운 주관적이고 개인적인 지(知), 반복된 경험을 통해 체화된 사고 스킬(생각, 정신, 모델)과 행동 스킬(숙련, 노하우)”이라고 설명한다.

이 글에서는 아키텍트에 대한 언어 및 문장으로 표현하기 어려운 주관적이고 개인적인, 그리고 경험을 통해 체화된 ‘손맛’에 대해 얘기해 보려고 한다. 물론 필자의 능력은 이런 글을 쓰기에는 턱 없이 부족하지만, 그 동안 고민하고 느꼈던 부분 가운데 상식적인 일부를 당돌하게 다뤄 보려고 한다(필자는 옛날부터 공부는 못했지만 공부 잘 하는 방법은 알고 있었다).

아키텍처, 왜 어려울까?오브젝트월드(Objectworld.org)의 신입회원 가입인사를 보면 아키텍트를 목표로 하는 분들이 많다. 필자의 목표도 아키텍트지만 아키텍트가 될 수 있는 길은 막연하기만 하다. 아키텍트 고시나 아키텍트 자격증과 같은 아키텍트 인증 절차가 있는 것도 아니고, 그렇다고 아키텍트를 양성하는 코스가 따로 존재하지도 않는다(많은 아키텍처 강의들이 있지만 그 강의를 수강했다고 해서 아키텍트가 되는 것도 아니다). 아키텍트로 승인될 수 있는 기준도 마땅히 없거니와 아키텍트가 될 수 있는 방법 역시 마땅히 정해지지 않았다. 아키텍트의 능력은 체계적인 트레이닝을 통해 만들어지는 것이 아니라, 다양한 경험과 지식, 그리고 통찰력이 필요한 ‘암묵지’의 영역이기 때문이다. 그래서 이런 요소들은 아직까지는 공학적으로 정리되어 학습할 수 없고 단지 ‘체득’을 통해서만 얻을 뿐이다.

더욱이 여러 아키텍처 관련 책들은 우리를 좌절하게 한다. 아키텍처 책에 담긴 많은 내용들은 우수하고 풍부한 인력으로 어려운 난이도의 대규모 프로젝트를 통해 연구 실험한 결과를 이론으로 정리하는 경우가 많다. 또한 ‘핵 에너지 관리/통제 시스템’, ‘운영체제 커널’, ‘항공관제 시스템’, ‘엔터프라이즈 서버’, ‘군사 방어 시스템’ 등과 같이 NASA, 국방부, 항공사, 대기업 벤더 등에서나 가능할 이론을 설명하고 있는 탓에 이 이론을 배운다 하더라도 적용할 대상을 찾기 힘들다(그래서 기술하는 문장과 용어도 매우 추상적이다).

항공관제 시스템 아키텍처는 웹사이트를 구축하는 우리에게 현실적이지 않으며 실시간 운영체제, 애플리케이션 서버, DB는 우리에게 이용 대상일 뿐이지 구현 대상이 아니다. 마치 ‘성서’와 같은 아키텍처 이론서의 내용과 실세계에서 우리가 다루는 시스템 사이에는 이처럼 큰 간극이 있다.

따라서 그 책의 이론들은 대단하고 우수한 내용임에는 틀림없지만 우리가 직면한 아키텍처적인 문제와는 성격 자체가 다를 수밖에 없다. 결론적으로 국내 대부분의 프로젝트 팀은 그다지 우수하고 풍부한 인력으로 구성되어 있지는 않고, 시스템의 성격 또한 난이도가 낮고 소규모 프로젝트인 경우가 대부분이다. 오히려 현업이 요구하는 지저분한 비즈니스 로직을 단순화시키는 방법이 디자인 결정의 큰 변수로 고민될 뿐이다.

그렇다면 우리에게 있어서 이러한 아키텍처 이론은 무엇일까? 우리에게 이 이론들은 어떤 의미가 있으며 어떤 가치를 가지는가? 이런 질문의 연쇄 작용 탓에 아키텍처 책을 읽다 보면 필자는 참담한 기분에 빠져든다(그렇다고 필자는 이런 책들을 무용한 것으로 여기진 않는다. 이는 아키텍트가 되려면 반드시 넘어야 할 산이지만, 그 전에 넘어야 할 산이 있다고 생각하고 있으므로 이 글을 쓰는 것이다).

결론부터 말하면, 이런 고민의 원인은 우리의 대부분이 아키텍처의 생산자가 아니고 아키텍처를 적용한 완성품의 소비자 입장이라는 데 있다. 가령 우리는 자바 EE 아키텍처를 공부해 자바 EE 아키텍처와 유사한 것을 만드는 것이 아니라 자바 EE 제품을 그냥 사용한다. 즉, 자바 EE를 잘 사용하기 위해, 또는 내부 구조를 이해하기 위해 우리는 자바 EE 아키텍처를 공부하고 있었던 것이다. 그래서인지 우리나라의 많은 자바 엔터프라이즈 아키텍트의 역할 범위가 상당히 축소되어 있다. 이미 채택된 엔터프라이즈 플랫폼의 기능과 품질을 잘 파악해 시스템 목적에 충실하도록 베스트 프랙티스와 사용 가이드라인을 제시할 뿐이다. 따라서 제공하는 플랫폼의 종류(성격)에 따라 아키텍처가 결정되고 모양이 달라진다. 오히려 그들은 그 플랫폼의 장단점을 면밀히 파악해 잘 사용할 방법을 고민하거나, 도메인 로직을 분석하고 정의하는 데 더 많은 시간을 할애한다.

또한, 우리나라에 존재하는 항공관제 시스템이나 국방 시스템 등의 프로젝트를 구축할 때도 똑같은 상황이 발생한다. 미션 크리티컬한 시스템을 구축하기 위해 미션 크리티컬한 솔루션을 그냥 구매해 사용할 뿐이다. 이미 시스템의 아키텍처적인 결정은 그 솔루션에 의해 이뤄졌으며 따라서 아키텍처적인 결정 사항도 많은 부분 끝났다고 봐야 한다.

자바 EE 플랫폼을 사용하는 시스템의 아키텍처는 자바 EE 아키텍처이고, IBM SOA 솔루션 패밀리를 사용하는 시스템 아키텍처는 IBM SOA 아키텍처가 된다는 것이다. 상황이 이러하니 아키텍트가 고민하고 정의해야 할 범위와 깊이는 상당 부분 축소되고 제약되어 있다(아키텍트로서 아키텍처 작업을 수행할 만한 것이 많지 않으니 딱한 노릇이다).

이와 같은 생각은 패턴을 좋아하는 필자가 우리나라에서 패턴이 유행하지 않은 원인을 찾던 중 발견한 사실과 일치한다. 패턴은 시스템의 디자인 문제에 대한 대안을 제시한다. 프레임워크나 플랫폼은 시스템이 요구하는 디자인 문제들을 많이 해결해 주는데 내부적으로 패턴을 많이 사용한다. 패턴은 설계이지만 프레임워크는 설계가 실현된 구현물이다. 따라서 우리가 해결해야 하는 디자인의 문제들은 프레임워크나 플랫폼을 사용함으로써 많은 부분 해결된다. 결론적으로 우리가 패턴을 사용할 기회를 잃게 되는 것이다.

이상에서 설명한 바와 같이 ‘이상과 실제의 간극’, 그리고 그 실제의 영역 중에서도 상당 부분 상용 제품이 선점해 버린 ‘아키텍처 대상 범위의 축소’가 아키텍트의 결정 범위를 더욱 협소하게 만든다. 이런 상황에서 필자는 ‘우리나라에서 아키텍트 되기’를 제안해 본다. 우리 현실에 맞게 다시 아키텍처를 논하자는 것이다. 물론 우리나라에는 복잡하고 거대한 프로젝트도 많고, 패키지 소프트웨어 업체들도 많다. 하지만 아키텍처를 다루고 있는 사람은 미미할 뿐이다.

이 논의를 진행하기 전에 먼저 아키텍처와 디자인의 차이를 구분할 필요가 있다. 아키텍처의 정의는 여러 거장들이 다소 다른 표현으로 정의하고 있기에 한 문장으로 표현하기는 어렵다. 하지만 필자는 나름대로 관련 정의들을 참고해서 아키텍처를 ‘시스템의 전반적이고 근본적인 설계안’으로 정의했다. ‘전반적’이 함축하는 것은 아키텍처적 결정 사항이 시스템 전체를 아울러 적용된다는 의미이고, ‘근본적’이 함축하는 것은 시스템 설계를 관통하는 컨셉과 철학, 스타일을 의미한다.

그렇다면 디자인은 아키텍처와 무엇이 다른가? 디자인과 아키텍처를 구분하는 특징은 ‘근본적’이고 ‘전반적’인 속성의 유무에 있다. Scope에 의해 분류하면 디자인은 아키텍처의 서브시스템을 다루고 있다. 아키텍처는 전체를 다루고 있고, 디자인은 부분을 다루고 있다. ‘근본적인 차이’로 디자인 결정에서는 전체를 관통하는 일관성을 가질 필요가 없다. 다루는 영역이 지역적이니 지역적인 문제만 신경 쓰면 되기 때문이다.

또한 아키텍처는 시스템의 복잡도와 볼륨에 의해 존재 유무가 결정된다. 웹 페이지에서 사용자의 입력을 받아 해당 DB 테이블을 검색해 결과를 보여주는 단순한 로직을 갖고 있다고 하자. 이 시스템의 페이지가 아무리 많아도 거기에선 아키텍처를 찾아보기 어렵다. 복잡도가 낮기 때문이다. 또한 상당히 복잡하지만 클래스 6개로 해결되는(볼륨이 적은) 시스템에서도 아키텍처를 찾아보기 어렵다. 보통 이런 경우에는 디자인적인 결정으로도 충분한 설계를 할 수 있다. 하지만 정량적으로 아키텍처냐 아니냐를 결정할 기준도 딱히 없다. 단지 조직에서 암묵적이고 사회적인 합의에 따라 아키텍처로 인정하느냐 그렇지 않느냐가 결정되는 것 같다.

우리나라에서 아키텍트가 되는 방법이제 필자가 그 동안 설계하면서 애용했던 방법을 소개하고자 한다. 필자 스스로 다른 사람을 가르칠 정도로 성숙하지 않음을 알지만, 어차피 필자보다 경험과 지식이 적은 독자들을 대상으로 설명하는 글이니만큼 조심스러우면서도 과감하게 설명하려 한다.

하나, 시스템 품질요소 제대로 정하기
아키텍처는 기능적 요구사항과 품질적 요구사항, 시스템 제약사항을 기초로 설계된다. 기능적 요구사항과 시스템 제약사항은 고객에 의해 명백히 정의될 수 있다. 사실 프로젝트 제안시 대부분의 고객이 시스템의 목적을 제대로 이해하지 못하므로 ‘명백히’ 정의되기는 쉽지 않다. 하지만 유즈케이스나 프로토타이핑 등의 공학적인 방법으로 고객의 요구사항을 구체화할 수는 있다. 또한 시스템 제약사항도 고객과의 커뮤니케이션을 통해 결정을 유도할 수 있다. 하지만 품질적 요구사항은 위 두 가지 사항들을 토대로 아키텍트가 결정해야 하므로 고객이 도와줄 수 없으며 공학적이지도 않고 방법을 일반화할 수도 없다(서두에서 아키텍트의 기술을 ‘손맛’으로 표현한 것도 이런 이유에서다).

똑같은 기능과 제약사항을 갖는 시스템이지만 용도에 의해 품질이 달라진다. 예를 들면 필자는 미들웨어 개발을 주로 해서 시스템 퍼포먼스나 scalability, 가용성 등을 중요한 품질요소로 생각한다. 하지만 대용량 데이터를 다루지만 트랜잭션 양이 적은(하루에 50건도 안 되는) 시스템을 작업하는 친구와 그 시스템의 문제를 얘기하면서 전혀 다른 시스템 구조를 생각했었다(물론 트랜잭션 양이 그렇게 적을 줄 몰랐다). 이는 시스템이 어떤 기능을 하느냐가 아니라 어떻게 쓰이느냐에 의해 아키텍처가 달라지는 경우이다.

따라서 현재 시스템을 분석해 시스템의 기술적 포커스를 잘 정의하고, 거기에 상응하는 품질 요소를 선택할 수 있는 ‘아키텍트의 통찰력’이 필요하다. 그렇다면 그 통찰력은 어떻게 만들어지는가? 우선 시스템이 어떻게 동작하는지와 더불어 어떻게 쓰이는지도 알아야 한다. 또한 시스템이 어떻게 발전될지도 알아야 한다. 물론 시스템의 기술적 요구사항과 제약사항을 정확히 정의하는 것은 기본이다. 결론적으로 시스템의 기능과 더불어 시스템의 목적과 용도, 발전방향, 리스크 등을 정확히 이해해야 한다. 이런 시스템에 대한 입체적 이해가 바탕이 된다면, 이를 위한 해결방안은 저절로 도출된다. 이것이 통찰력의 본질이다.

둘, 레퍼런스 아키텍처 참고하기
아무도 시도해 보지 않은 전인미답(前人未踏)의 시스템을 구축하지 않는 한, 아키텍처의 힌트는 이미 구축된 유사 아키텍처를 통해 얻을 수 있다. 이는 시스템의 문제영역이 유사하면 거기에 대한 아키텍처도 비슷하다는 의미다. 필자는 CORBA ORB 작업을 수행하면서 여러 개의 오픈소스 CORBA의 소스 코드를 해킹한 적이 있었다. 개개의 제품마다 다른 디자인 전략을 갖고 있지만 근본적인 아키텍처의 틀은 비슷했다. 같은 문제영역을 다루고 있었기 때문이다.

이 문제영역은 동종의 시스템을 구축할 때 가장 쉽게 찾아볼 수 있지만, 이종의 시스템에서도 간간이 찾아볼 수 있다. 대표적인 예가 GUI 프레임워크 아키텍처인 MVC를 웹 애플리케이션 아키텍처에서 차용하는 것이다(JSP의 Model-2 아키텍처). 전혀 다른 기능을 하는 두 프레임워크가 어떻게 유사한 아키텍처를 채택할 수 있었을까? 어떻게 그래픽 유저 인터페이스를 위해 제안된 아키텍처가 웹 애플리케이션 프레임워크의 기반 아키텍처로 채택될 수 있었을까? 이유는 두 프레임워크의 역할이 유사했기 때문이다. 이 둘은 사용자에게 명령과 정보를 입력 받아 명령에 해당하는 비즈니스 로직을 실행한 다음, 결과를 사용자에게 보여주는 구조가 일치한다. 그래서 JSP 아키텍트는 GUI 프레임워크의 MVC 아키텍처를 차용했다.

아키텍처 레퍼런스를 잘 활용하기 위해서는 다양한 아키텍처 모델을 알고 있어야 한다. 아키텍처 모델을 많이 알수록 아키텍처 설계에 참고할 만한 무기를 많이 확보할 수 있다. 우선 동일한 비즈니스 도메인의 아키텍처 모델을 많이 알아야 한다. 금융이나 통신, 제조, 유통 등 해당하는 비즈니스 도메인의 표준이나 제품 아키텍처, 오픈소스 설계 문서, 논문, 책 등은 좋은 참고(레퍼런스)가 된다. 무엇보다도 자신이 다뤄 보지 않거나 접할 기회가 없는 제3의 아키텍처 모델들을 학습하길 권한다.

다음으로 요구되는 것은 응용력이다. 어떠한 참조 모델도 그대로 현 시스템에 적용하기엔 부적합한 부분이 있다. JSP는 최초에 MVC(Model-1)를 그대로 차용했지만, 웹 애플리케이션에 적합하도록 Model-2로 아키텍처를 진화시켰다. 이렇듯 응용력이 없으면 아키텍처의 완성도가 낮아지며, 역으로 응용력은 레퍼런스 아키텍처를 현 시스템의 아키텍처로 적응시키는 역할을 한다. 따라서 응용력의 토대는 이렇게 적합성 검토를 통해 마련된다. 결과적으로 응용력은 레퍼런스 모델을 적용하는 데 발생하는 부적합한 부분을 다듬는 기술인 셈이다.

셋, 패턴 학습하기레퍼런스 모델 중 가장 매력 있는 참조 대상이 바로 패턴이다. 패턴이야말로 반복적으로 발생하는 설계 문제에 대한 명쾌한 모델을 제시하기 때문이다. 또한 근래에는 도메인 한정적인 패턴 언어(language)들이 많이 등장하고 있어 그 매력은 더욱 증가한다. 현재 통신 패턴, 워크플로우 패턴, EAI 패턴, 네트워크와 동시성 패턴, Core J2EE 패턴 등 다양한 패턴 언어들이 발표되어 있다.

패턴 언어의 이점은 해당 도메인의 문제영역을 잘 분류해 설명하고 있다는 것이다. 따라서 어떤 시스템을 구축할 때 그 시스템의 문제영역을 체계적으로 분석하기 위해 그 패턴 언어를 이용하면 상당히 좋은 정보를 얻을 수 있다. 또한 패턴은 아키텍처에서 구현 단계에 이르기까지 설계와 구현 전반에 걸쳐 적용하기 가장 유익한 도구이다.

패턴이야말로 ‘반복된 경험을 통해 체화된’ 결정체이므로 패턴에 대한 폭 넓은 이해는 레퍼런스 아키텍처 못지않게 아키텍트의 무기가 된다.

넷, 외부 세상에 대한 감시아키텍처가 비록 설계의 문제를 다룬다고 하더라도 설계의 구성 요소에는 박스와 라인 이외에 다른 것들도 등장한다. 기술이나 프로그래밍 언어, 솔루션들이 바로 그것이다. 따라서 항상 새로운 기술이나 제품, 패러다임에 대해 감시하고 학습해야 한다. 

아키텍트에 대한 몇 가지 생각
간혹 잘못된 그림을 그려놓고 도망간 아키텍트의 얘기를 들을 때가 있다. 그 아키텍트가 무책임하다는 생각도 들지만, 한편으로 비싼 아키텍트를 오래 둘 수 없는 프로젝트 구조에도 문제가 있다는 생각이 든다. 아키텍트라면 자신의 그림을 완성시켜야 하는 책임이 있다고 필자는 생각한다. 다시 말하면, 아키텍트는 자신의 아키텍처가 옳다는 것을 프로젝트 전 기간을 통해 증명할 의무가 있다. 프로젝트가 진행되다 보면 요구사항도 변하고, 제약 사항도 변한다. 또한 아키텍처의 모순이나 잘못된 판단이 드러나기도 한다. 따라서 아키텍트는 프로젝트 종료 때까지 아키텍처를 다듬어 가면서 아키텍처를 완성해야 한다. 즉, 아키텍처는 초기에 일필휘지(一筆揮之)할 수 있는 것이 아니라 지속적으로 다듬어 완성해 가는 것이다. 따라서 아키텍트 투입은 프로젝트 전반에 걸쳐 아키텍처 수립 이후에도 적은 인력과 기간(Man/ Month)을 들여서라도 배치할 필요가 있다.

필자가 경험한 아키텍트 중 많은 분들은 도메인 익스퍼드들이었다. 그들은 오랜 시간을 통해 자신의 도메인을 경험했기 때문에 문제영역이나 제약사항도 잘 이해하고 있다. 아마도 도메인 아키텍트가 되는 방법 중 하나는 도메인 익스퍼트가 되는 것 아닐까 생각된다. 하지만 ‘익스퍼트=아키텍트’라는 공식은 적합하지 않다. 익스퍼트가 아키텍트가 되기 위해 아키텍트로서의 소양이나 지식을 가져야 하기 때문이다. 이 지식이 부족한 익스퍼트들은 새로운 것에 대한 적응력이 약한 경향이 있다.

끝으로 모범적인 아키텍처는 현란하지 않다. 좋은 아키텍처일수록 오히려 심플하다. 시스템의 전반적이고 근본적인 설계안을 제시해야 하기 때문이다. 아키텍처가 복잡할수록 아키텍처가 영향을 미치는 하부 요소(디자인 영역)들의 설계는 어려워진다. 하부 디자인들도 그들만의 복잡한 설계문제를 갖고 있기 때문이다. 자신의 설계적 복잡도에 더해 아키텍처로부터 전달된 복잡도를 추가해 감당하기란 여간 어려운 일이 아니다. 이런 여러 가지 내부의 복잡한 설계들을 끌어안기 위해서라도 아키텍처는 심플해야 한다.

우리나라에서 아키텍트가 되는 것은 쉽지 않은 과정이다. 경우에 따라서는 학력을 업그레이드시켜야 할 필요도 있다. 하지만 현실적인 아키텍처적 담론을 많이 교환하고 이론이 아닌 ‘실체’를 더 많이 공론화한다면 ‘우리나라에서 아키텍트 되기’가 유의미한 시도가 되리라 생각한다.

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

• 종이 규격사이즈 by Hiyen