아키텍트의 역할과 자질에 대한 고찰

- 1년쯤 전에 써본 아티클인데... 부끄러운 글이지만,,, 그리고 꽤 짜집기를 했지만, 

이 짧을 글을 쓴다고 안돌아가는 머리 고생하고 고민을 꽤 한 시간이 아까워서 이렇게 블로그에 기록으로 남깁니다. 

다시 읽어보니까,,,너무 나열식이다. ㅎㅎㅎㅎ. 

 

왜 아키텍트일까? 

흔히 IT 아키텍처를 말할 때 비교하는 건축 도메인과의 비교를 해 보면 고객의 요구사항을 받고 뼈대를 잡고 그 뼈대에 필요한 것들을 쌓아서 고객의 요구사항을 구현한다. 몇 천년 동안 지어진 건축물을 보면서 노하우가 쌓이고 시행착오를 극복해온 건축쪽 도메인과 달리 소프트웨어 분야는 역사도 짧을 뿐더러 아키텍처 자체가 기업의 자산과 보안이 되는 관계로 공유가 그다지 많지 않다. 그나마 인터넷의 발달과 오픈소스의 발전 그리고 블로그의 기술 포스팅을 통해서 발전해 가는 것이 겨우 가능해 졌지만, 그 역시도 충분하지는 않다. 소프트웨어의 비가시적인 특성상 기 구축 사례를 보고 얻어내기가 쉽지만은 않다. 

갈수록 소프트웨어가 거대해지고 기술의 복잡도가 증가하며 난이도도 증가하고 있다.

거기에 근래의 환경은 클라우드 기반으로 모든 인프라가 돌진하고 있고 모바일,웹,하이브리드웹,RIA 등의 각종 환경적인 변화까지 가속도를 더해가고 있다. 

개발 패러다임으로 보자면 절차지향적인 패러다임에서 객체지향 패러다임 그리고 함수기반 언어들까지 맹위를 떨치고 있다.

UI의 기능은 날이 갈수록 강력해지고 사용하는 Device 의 종류도 너무 많아져서 모든 경우의 수를 다 대비해야 하는 현실이다. 

이런 기술의 홍수들 속에서 새로운 기술 패러다임의 본질을 꿰뚫고 복잡하고 다양하게 등장하고 있는 여러 기술 및 솔루션들의 특성과 장단점을 구체적으로 파악하여 IT 시스템 구축 프로젝트에 올바르게 적용함으로써 프로젝트의 성공과 수익성 제고에 기여할 수 있는 능력을 갖춘 소프트웨어 기술 전문가들이 필요하다. 이제는 아키텍트라는 역할이 어느 정도 보편화 되어 있고 아키텍처 팀을 만들어서 운영하는 기업들도 많아 졌다. 

아키텍트의 역할

그렇다면 아키텍트는 프로젝트에서 어떤 역할을 가져야 할까? 

일반적으로 아키텍트는 기술적인 문제에 대한 해결사의 역할을 요구 받는다.

개발 시스템의 전체 아키텍처를 수립하고 수립된 아키텍처를 중심으로 소프트웨어 시스템의 설계 및 구현과정을 선도하는 역할까지 담당한다. 

『Applied Software Architecture 』 에서 소개하는 소프트웨어 아키텍트의 역할에 대한 7가지 정의를 보면

비전제시자

IT 기술의 트렌드와 전망으로 토대로 고객의 요구를 만족하는 솔루션을 만들어내고 시스템의 명확한 모습을 그려냄을 통해 프로젝트 구성원에게 확신을 심어주는 역할을 할 수 있어야 한다. 

핵심기술조언자

프로젝트에서 수없이 맞닥뜨리는 이슈들과 위험, 문제들에 대해서 기술적인 조언을 하는 역할을 할 수 있는 역량을 갖추어야 할 것이다. 

의사결정자

기술 조언과 더불어 문제 해결에 대한 중요한 사안에 대한 의사 결정을 할 수 있어야 한다.

코치

수립된 아키텍처를 프로젝트 조직원 들에게 전파하고 정확하고 일관된 코칭을 통해 프로젝트 조직원들이 시스템을 구축 할 때 아키텍처와 일치할 수 있도록 해야 한다. 

조정자

프로젝트에서 일어나는 다양한 형태의 대립을 조정하는 조정자 역할을 할 수 있어야 한다. 

이때 기술적인 판단력과 더불어 커뮤니케이션 능력 역시 요구되게 된다. 

구현능력

아키텍트는 ‘한 줄의 코드로도 시스템의 성능을 높일 수 있는 자’ 혹은 ‘선도 구현을 통해 개발자를 리드하는 자’ 여야 한다. 

아키텍트는 자신이 수립한 아키텍처가 실제로 어떤 모습으로 구현될 것인지를 보여줄 수 있어야 한다. 이를 위해서 프로토타이핑을 통한 아키텍처의 검증 수행, 그 결과를 기반으로 아키텍처를 정제해야 한다. 

또한, 개발조직이 참조할 수 있는 표준, 샘플 소스 등을 통해서 개발자에게 가이드 역할을 해주어야 한다. 

대변자 

아키텍처가 소프트웨어 개발 프로젝트에서 차지하는 비중과 중요성을 지속적으로 전파하는 것을 말한다.

시스템에 질서를 부여하고 복잡함을 제어하기 위해서 아키텍트는 위의 일곱 가지 역할에 대한 역량을 가지고 일관된 비전과 의사결정을 통해 시스템이 아키텍처와 같은 모습으로 구현될 수 있도록 끊임없이 의사소통하고 가이드 해야 할 것이다. 

즉, 시스템의 아키텍처를 설계하고 설계 결과를 다양한 방식으로 검증하며 설계자/개발자들의 아키텍처 준수여부의 모니터링, sw 엔지니어를 리드하고 시스템 설계 의사 결정을 지속적으로 수행하며 기술에 꾸준한 관심을 가지고 해결능력을 배양하며 비즈니스와 개발팀간의 중재자 역할을 하는 사람을 아키텍트라고 할 수 있다. 

아키텍트의 자질과 역량

그래서 아키텍트에게 요구되는 자질은 

프로젝트의 목표를 명확하게 정의하고 이를 달성할 수 있는 방법을 정확하게 파악할 수 있는 통찰력,논리성,창의성 과 더불어 리더쉽, 의사소통 능력 , 기술력, 경험등이라고 생각을 하는데 이런 자질과 역량들을 갖추기 위해서 해야 할 것들은 무수히 많다.

기술적으로는 설계, 프로그래밍, 인프라구축, 명세수립, 테스트 방법, 요구사항정의, 품질관리, 비즈니스 이해

기술 외적으로는 인문학에 대한 이해와 커뮤니케이션 능력, 군림하는 것이 아닌 섬기는 리더쉽, 공감능력 등 이런 것들을 키우기 위해서 노력을 해야 할 것이다. 

그렇다면 프로젝트에서 아키텍트가 어떤 일을 해 줘야 할까? 

답은 없을 것이고 여러 책들에서도 소개가 이미 된 부분이고 필자가 이런 정의를 하는 것 자체가 어불성설 이긴 하지만, 아래의 기술된 Activity 정도는 해야 하지 않을까 한다. 

모든 사람이 아키텍처를 정확하게 활용할 수 있도록 아키텍처를 정의하고 문서화 및 배포하라.

아키텍처는 소프트웨어 프로젝트의 모든 시점에서 의사결정의 기준이 되고 방향 결정의 방향타 역할을 한다. 

모든 상황에서의 레퍼런스 역할을 하므로 아키텍처를 정확하게 활용가능한 수준으로 정의하여 배포해야 한다.

소프트웨어와 하드웨어가 조화를 이루도록 설계하라.

소프트웨어를 개발하는 것이 하드웨어를 배제하고는 이루어질 수 없다. 하드웨어 인프라 기반에서 소프트웨어가 동작하므로 하드웨어와 조화를 잘 이룰 수 있도록 하는 것이 필요하다. 특히 근래의 hadoop 으로 대표되는 클라우드 개발 쪽으로 가면 더더욱 필요하게 될 것이다.

개인적으로도 Computer Architecture 를 깊게 학습해야 하는 도전꺼리를 안고 있다. 기존에 소프트웨어만 알아도 되던 시대는 지나가고 하드웨어( CPU, Memory, Cache, N/W 등) 에 대한 지식이 아키텍트에게 요구되고 있다. 

아키텍처 전도사가 되라. 관리조직에게 아키텍처를 이해시켜라

아키텍처를 널리 알리고 구성원들이 동의할 수 있도록 전도하는 역할을 적극적으로 수행해야 한다. 또한, 관리조직부터 아키텍처를 이해하게 될 때 아키텍처를 통한 개발자의 구현이 아키텍처의 사상과 아키텍처의 제한사항을 충족 시킬 수 있도록 아키텍처에 대해서 구성원들에게 이해 시키고 공감대를 가지기 위해서 노력해야 한다. 

아키텍처와 일관되게 설계/구현 하는지 확인해라.;

아키텍처의 일관성에 대한 아키텍트의 노력은 절대로 과다함이 없다. 물론 융통성을 가지고 접근해야 하나 항상 아키텍처를 전파함을 통해서 아키텍처와 일관된 설계/구현이 될 수 있도록 리뷰하고 공감대를 가지려는 노력을 기울여야 할 것이다. 

시스템 환경이나 개발 툴 배포 등과 같은 문제를 제기하라

시스템 개발을 할 때 개발자가 환경셋팅이나 개발 툴에 대해서는 자유도를 가지고 개발자가 그 정도는 해야 하지 않겠느냐 라고 이야기 할수 있다. 그러나 시스템 개발이 팀 단위로 이뤄지고 팀간의 커뮤니케이션 까지 고려했을 때는 그에 대한 표준이 없다면 곤란할 것이다. 

개발자에게 배포하여 주어진 순서대로 실행하면 로컬에서 배포 테스트 가능할 정도의 환경을 미리 셋업해주려는 노력을 해야 한다. 

선도 개발 및 검증을 통해서 배포하는 역할을 직접 해야 한다. 

이해관계자를 찾아서 상호작용하고 요구를 만족시켜 주어라

아키텍처에 관련된 수많은 이해관계자들을 식별하고 그들과 상호작용해라.

그들 각자가 가진 요구사항들에 대해서 적극적으로 대처하고 솔루션을 제공하려고 노력해야 한다.

아키텍처를 만들 때 배치와 유지보수에도 적합하게 만들어라

아키텍처를 만든다는 것은 항상 해당 시스템을 생성시에 만들게 된다. 해당 작업의 특성상 아키텍트는 생성에 대한 경험만을 보유하고 있을 수도 있다.

그러나 아키텍처가 부여하는 효과가 유지보수 및 배치에도 있다는 것에 동의 한다면 유지보수가 가능하고 손쉬운 배포가 가능한 아키텍처를 만들려는 노력을 게을리 해선 안된다. 

기술문제를 해결하고 해당 논쟁과 상충하는 문제점들을 조율하라.

소프트웨어 아키텍트가 직면한 문제들은 비즈니스 적인 문제일 수도 있지만 가장 가까운 것은 기술문제이다.

해당 기술 문제를 해결하고 상충하는 문제들에 대한 논쟁에 대해서 조율하고 해결해라.

훌륭한 설계나 인상 깊은 발표를 통해 조직의 사기를 높여라.

훌륭한 설계를 하여 이해관계자들을 감동 시키고 개발자의 자기 계발 욕구를 만족시킨다면 이보다 좋을 순 없겠다. 

결과물이 좋은 것에 못지 않게 중요한 것은 훌륭한 발표이다. 이해관계자들에게 인상 깊은 발표를 통해서 감동을 주어라.

새로운 기술을 도입 시 시스템이 나아가야 할 방향을 이해하고 제시해라.

새로운 문제가 대두되면 새로운 기술들을 찾게 될 때가 있다. 

기술적인 트렌드는 계속 등장하고 그에 따른 변화의 흐름을 놓치지 않을 필요가 있다.

평소의 리서치와 리포트를 통해서 솔루션을 가질 수 있는 준비를 갖출 필요가 있다.

시스템의 기본 사상과 방향을 이해하고 조율하면서 새로운 기술들을 도입해야 한다. 

아키텍처와 관련된 위험을 찾아 대비하라.

아키텍처 설계자는 자신의 사상에 깊은 이해를 가지고 있으므로 시스템의 아키텍처로 인하여 발생되는 문제들에 대해서는 모를 가능성이 있다.

아키텍처 대안을 검토할 때 객관적인 입장에서 검토하고, 특정한 검증 프로세스를 통해서 아키텍처와 관련된 위험을 도출할 필요가 있다.

맺음말 

아키텍트들은 항상 아래와 같은 사항에 관심을 가진다. 

소프트웨어 품질 속성, 개발 프레임워크, 시스템 요소의 구성/관계, 공통기능과 개발 지원에 필요한 것들, 기술자와 비즈니스 관계자 사이의 조정자 역할, 기술자의 의견을 적절히 전달할 수 있는 쉬운 용어의 사용, 개발팀에의 리더쉽, 선 하나의 결정이 시스템 전체에 미치는 영향 등등. 

이런 모든 역할을 아키텍트 한 두명이 모두 할 수는 없다. 그리고 한 사람이 위의 능력들을 모두 가지기도 힘들 뿐더러 모두 갖추고 있다고 해도 프로젝트에서 주어지는 시간으로 따져보면 모든 역할을 해내기는 불가능하다. 언젠가 주변의 지인이 말한 것 처럼 ‘저 많은 것을 다 해야 해?’ 라는 생각으로 ‘현실적이지 않다’ 라고 말할 수도 있다. 

그러나 아키텍트가 프로젝트에서 해야 할 수많은 역할에 대한 이해를 가지고 노력을 해야 할 것이다. 

모두 다 할 순 없다. 모두 다 하는 것은 자연인 한 사람의 영역이 아닌 조직의 영역이라 할수 있을 것이다. 

다만, 역할에 따른 자질과 역량을 키우는 데 노력하다보면 언젠간 쓸만한 아키텍트가 되어 있지 않을까?