Offcanvas

개발자 / 리더십|조직관리

기고 | '아키텍처' 작업이 유의미할 때

2019.06.26 존 맥도웰  |  CIO KR
기업이나 시스템에 대한 이야기를 할 때 ‘아키텍처’(architecture)라는 것을 이야기하곤 한다. 이 때 모델, 다이어그램, 스프레드시트 등 해당 기업이나 시스템을 설명하는 일종의 산출물을 말하는 경우가 대부분이다. 그 산출물은 사용 중인 아키텍처 프레임워크에 의해 정의된다. 

그러나 아키텍처가 무엇인지 가장 기본적이고 근본적인 수준에서 곰곰이 생각해 본 적이 있는가? 아키텍처는 산출물 자체가 아니다. 산출물은 아키텍처에 대한 문서 작성 수단일 뿐이다. 복잡한 아키텍처를 이해 가능한 수준으로 만들어 활용하려면, 산출물을 만드는 진정한 목적에 집중해야 한다. 그래야만 아키텍처 활동을 통해 뭔가 가치 있는 것을 만들어 낼 수 있다.
 
ⓒ Image Credit : Getty Images Bank

아키텍처의 복잡성
특정한 아키텍처 프레임워크에 의해 정의된 공정이나 산출물 자체는 아키텍처가 아니다. 아키텍처를 충분히 검토하고 문서화하기 위한 수단일 뿐이다. 대부분의 아키텍처 프레임워크는 비교적 복잡하다. 설계자가 고려해야 할 측면도 많고 개발 과정 동안에 만들어야 할 산출물도 많다. 

예컨대, 자크만 프레임워크(Zachman Framework)에는 행과 열이 있고, 오픈 그룹 아키텍처 프레임워크(The Open Group Architecture Framework)에는 필라(pillar)가 있으며, 미국 국방부 아키텍처 프레임워크에는 뷰(view)가 있다. 어떤 프레임워크를 선택하든 해당 프레임워크의 확립된 방법론을 따른다면 상호 관련된 산출물을 십 수개 이상 생산해야 하는 상황에 놓이게 된다.

이 과정의 결과가 바로 산출물이고 산출물 간의 연결고리인데 프로젝트에 새로 온 사람에게는 이해하기 어려울 수 있다. 적절한 크기의 시스템이라도 세부적인 아키텍처는 복잡하다. 이러한 복잡함의 결과가 아키텍처 ‘사제단’(priesthood)이다. 설계자들은 담당 작업 영역에서 산출물과 그 관계들을 만들어 내지만 결과물은 심한 경우 질려버리거나 아니면 아예 이해를 못할 정도로 복잡하다. 

결국 아키텍처는 사 놓고 쓰지 않는 셰프웨어(shelfware)로 전락하고 별 이득도 없이 자원만 잡아먹게 되는 결과를 예상할 수 있다. 혹시 아키텍처를 활용하고 싶어하는 사람이 있다면 설계자 ‘사제단’과 상담해야 한다. 아키텍처를 이해할 수 있는 사람은 그것을 만든 사람 외에는 없기 때문이다.

설계자들만 사용할 수 있는 아키텍처는 마치 스스로를 핥아먹는 아이스크림 콘이나 마찬가지이다. 학문적인 관점으로는 흥미로운 업적이지만 실용성은 없다. 아키텍처를 쓸모 있고 실용적인 것으로 만들고 싶다면 처음으로 돌아가서 아키텍처가 가장 기본적인 수준에서 어떤 일을 해야 하는지 생각해 봐야 한다.

단순화된 아키텍처
필자는 최근 개발자 친구와 함께 이 주제를 놓고 토론했다. 아키텍처에 다소 회의적이지만 관심은 갖고 있는 친구다. 그 친구와 나는 어떻게 하면 아키텍처를 유용하게 만들 수 있을지 오랜 시간에 걸쳐 토론을 했다.

논의에서 합의된 결론은 아키텍처를 단순화하려면 아키텍처가 무엇인지 가장 기본적인 수준에서 정의할 필요가 있다는 것이다. 즉, 아키텍처의 본질과, 원하는 용도를 정의해야 한다.

아키텍처의 정의
가장 기본적인 수준에서 말하자면 아키텍처란 복잡한 공학 설계를 추상적으로 설명한 것이다. 분야와 상관없이 그렇다. 건물 설계자는 구조물의 설명서를 만들지만 구조물 부품은 어떻게 결합하고 현장은 어떻게 준비해야 하는지는 명시되어 있지 않다. 건물의 모습을 정의해 주는 것에 불과하다. 기술자들에게는 구조물을 상세하게 설계할 수 있게 해 주고 건물주는 건물이 어떤 모습일지 짐작할 수 있게 해 주는 등의 역할만 하는 것이다. 

이와 마찬가지로 정보 시스템이나 기업의 아키텍처는 특정 사용자에게 중요한 것을 설명해 주기만 하면 된다.

요컨대 아키텍처는 설계를 설명한다.

아키텍처의 목적
아키텍처가 무엇인지 안다고 해서 아키텍처의 사용 목적이 꼭 설명되는 것은 아니다. 여러 아키텍처 활동의 한 가지 문제점은 전혀 사용되지 않는 산출물이 많이 생성된다는 것이다. 이는 엄청난 자원 낭비이다. 아키텍처 활동을 한 곳에 집중시키려면 아키텍처 구축 목표를 명확히 정의할 필요가 있다. ‘아키텍처를 만드는 것이 정책이니까’라는 것은 식의 목적은 타당하지 않다.

아키텍처의 목적은 시스템이나 기업에 관한 구체적인 질문에 답하는 것이다. 공학 설계를 이해할 만한 기술적 지식이 부족한 사람이거나 기한 내에 해야 할 일 때문에 공학 설계를 이해할 시간이 없는 사람이 이러한 질문을 하는 경우가 대부분이다. 

예를 들면, 프로그램 관리자는 어떤 상업 제품이 최종 설계의 일부가 되어야 되는지, 그것이 어떤 기능을 수행해야 하는지 알아야 하겠지만, 그렇다고 해서 인증 모듈과 데이터베이스 관리 시스템의 토큰 교환 방식을 자세히 알고 싶어하는 것은 아니다. 

보다 기술적인 질문을 하는 경우도 있다. 이 때 해답을 필요로 하는 것은 개발 팀이다. 개발 중인 시스템에서 뭔가 새로운 일을 하고 있고 일반적으로 이해할 수 있는 패턴이 존재하지 않을 때 질문을 하는 경우 대부분이다. 해당 기능이 흔한 것이 아니기 때문에 기술적인 위험이 존재한다. 아키텍처 제품의 개발과 분석을 통해 해당 작업의 근본적인 기술적 위험을 완화시킬 수 있다. 

근본적으로 아키텍처는 ‘이 문제를 어떻게 해결할 것인가’라는 개발자의 질문 해결에 도움을 준다. 다시 말하면 아키텍처란 기술적 위험 완화를 위한 수단인 것이다. 그러나, 이러한 질문은 연구 개발의 맥락에서만 발생하는 것이 대부분이라는 점을 명심해야 한다. 평범한 시스템에서는 참고할 만한 여러 가지 구현 방식이 있을 것이고 기술적인 위험은 없다. 또한 제대로 이해되어 있고 종전에 다룬 작업에 대해서는 아키텍처 뷰를 만들 필요가 없다.

아키텍처 뷰에 대한 중요한 점은 관련 이해 관계자가 제기하는 구체적인 문제를 해결하기 위해서만 만들어져야 한다는 것이다. 해결하려는 문제를 분명하게 설명할 수 없거나 해당 질문을 요청하는 구체적인 사람을 확인할 수 없다면 아키텍처 뷰를 만들어서는 안된다.

이 개념을 요약하자면 아키텍처의 목적은 특정 이해관계자의 필요를 충족시킨다는 특정 목적에 맞게 공학 설계를 설명해 주는 것이라고 할 수 있다. 아키텍처 뷰는 한 명 이상의 이해관계자를 위해 구체적으로 명시된 필요를 해결하기 위해서만 만들어져야 한다.

아키텍처 작업을 해야 할 때
이 장황한 이야기의 결론은 아키텍처 산출물을 만들 이유는 공학자가 아닌 일반인에게 공학 설계를 설명하거나 기술적 위험을 완화하는 것 두 가지 중 하나뿐이라는 것이다. 이 두 가지 목적에 부합하지 않는 아키텍처 산출물을 만든다면 자원 낭비이다.

* 존 맥도웰은 엔터프라이즈 아키텍트이자 시스템 엔지니어다. ciokr@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.