Java 아키텍트 역할

 

소프트웨어 아키텍트

1. 왜 아키텍트인가?

근래 들어 IT 프로젝트 수행과정에서 소프트웨어 아키텍트 업무에 대한 관심과 요구가 커지고 있다.
이러한 현상은 소프트웨어 아키텍트의 역할에 대한 명확한 정의 조차 합의하지 못하고 있는 국내 IT 업계의 현실을 감안하면 다소 의외이다.
그러나 기술 복잡도와 난이도 증가에 따른 프로젝트 리스크의 지속적인 확대 및 이로 인한 수익성 악화의 현안을 감안하면 아키텍트에 대한 수요증대는 당연한 현상이다.
즉, 프로젝트 리스크의 예방과 해결을 위한 유력한 대응방안 중의 하나가 바로 올바른 아키텍처의 수립이라는 점을 프로젝트 수행 과정에서 경험적으로 깨닫기 시작했다는 말이 된다.

불과 몇 년 전까지 IT 시스템의 구축은 단순한 구조의 양적 확대가 주종이었다.
가장 가까운 과거의 IT 시스템 기반 구조는 클라이언트-서버 구조였다. 클라이언트-서버 구조의 핵심은 클라이언트 시스템의 컴퓨팅 파워의 증가에 따라 그 이전까지 서버(메인 프레임)에서 처리하던 비즈니스 연산 처리의 클라이언트로의 이전이었다.
사용자화면에서 발생한 이벤트를 비즈니스 요건에 따라 해석한 뒤 정해진 데이터를 처리하는 대다수의 애플리케이션에서 복잡도와 난이도는 별반 크지 않았고 시스템 구축의 규모는 유사한 구조의 양적인 차이에 의해 좌우되었다.

전통적인 클라이언트-서버 구조가 새로운 단계로 발전하게 되는 과정은 객체 기반 기술의 진화, 성장에 의해 이루어졌다.
주지하는 바와 같이 IT 시스템이 다루는 단위 구성요소를 컴퓨터 중심에서 인간 중심으로 옮겨온 패러다임이 곧 객체 중심 기술이며 객체는 컴퓨팅 세상의 총아가 되었다.
데이터, 컨트롤, 비즈니스 로직이 객체로 정의되고 이들 객체가 단일시스템의 영역을 넘어 하드웨어와 네트워크를 넘나들기 시작하면서 이를 둘러싼 다양한 신개념과 신기술이 속출하게 되였다 게다가 개인 컴퓨팅 파워의 획기적인 증가와 네트워크의 광대역화에 의한 가용성 증대, 여기에 인터넷 산업의 폭발적인 성장까지 더해지면서 객체 중심의 컴퓨팅 환경으로의 패러다임 전환이 점차 가속화되었다.

IT시스템의 기반이 객체 기반 분산 시스템 구조로 진화하면서 시스템 구조를 이루는 요소들의 특성과 상호 연동에 따른 복잡도가 커지고 난이도가 높아졌다.
특히 분산 시스템 간의 연동 범위가 데이터의 참조 수준을 넘어 객체의 이동과 참조가 일반화되면서 이를 처리하기 위한 분산 객체간 통신을 위한 국제 표준 규격(Global Standard Specification) 과 프로토콜들이 속속 등장하기 시작했다.
여기에는 보안, 트랜잭션, 이 기종 시스템 연동 등과 같은 소프트웨어 품질 관련 요구가 포함되어 있으며 이들 표준 규격과 품질요구를 만족시키는 새로운 기술과 다양한 솔루션이 시장에 출시되어 IT 시스템의 구성요소로 적용되기 시작했다.
이렇듯 객체 기술에 기반한 분산 시스템 구조는 이제 기술 트랜드의 주류(Main Stream)를 형성하였고 IT 시스템의 구축 프로젝트의 대세가 되어가고 있다.

2. 아키텍트의 역할

소프트웨어 아키텍트의 필요성이 대두되는 가장 큰 이유는 이러한 IT 컴퓨팅 환경의 변화에서 찾을 수 있다.
객체 기반 분산 시스템이 대세가 된 상황에서 새삼스럽게 특정 엔터프라이즈 환경에서만 사용 가능한 전용 클라이언트 프로그램과 메시지 처리, 요건 중심의 기능 구현은 더 이상 시장에서의 경쟁력을 상실했다.
범용 웹 브라우저가 클라이언트 프로그램의 핵심이 되었고 서버 사이드의 변화도 객체에서 컴포넌트로, 라이브러리에서 비즈니스 프레임워크로, 데이터베이스 쿼리 맵핑에서 객체와 관계형 데이터 간 객체 맵핑으로 진화하고 있다.

소프트웨어 아키텍트는 이러한 새로운 기술 패러다임의 본질을 꿰뚫고 복잡하고 다양하게 등장하고 있는 여러 기술 및 솔루션들의 특성과 장단점을 구체적으로 파악하여 IT 시스템 구축 프로젝트에 올바르게 적용함으로써 프로젝트의 성공과 수익성 제고에 기여할 수 있는 능력을 갖춘 소프트웨어 기술 전문가이다.
아키텍트가 갖춰야 할 자질과 역량은 여러 영역에서 높은 수준의 성취를 필요로 하는 한편 IT 프로젝트에서 담당하게 되는 아키텍트의 역할에 의해 정해진다.

서두에서 언급한 바와 같이 국내 IT 프로젝트에서 아키텍트의 역할에 대한 명확한 정의는 내려져 있지 않다. 새로운 기술 조류에 의해 부각되기 시작한 업무영역인 까닭에 대개 프로젝트의 경우 이전까지의 프로젝트에서 경험하지 못한 기술적인 문제에 대한 전 방위적인 해결사의 역할을 요구 받는다.
즉, 개발 시스템의 전체 아키텍처를 수립하는 것은 기본이고 수립된 아키텍처를 중심으로 소프트웨어 시스템의 설계 및 구현과정을 선도하는 역할까지도 담당한다.
프로젝트 수행과정에서 발생하는 모든 기술적인 문제를 해결하는 이슈 해결사의 역할은 당연히 아키텍트의 몫이 된다.

지멘스 연구소 아키텍트의 경험을 토대로 소프트웨어 아키텍팅에 대한 견해를 담은『Applied Software Architecture 』에는 소프트웨어 아키텍트의 역할 에 대한 포괄적이면서 흥미로운 7가지의 정의가 제시되어 있다.

첫 번째 소프트웨어 아키텍트의 가장 중요한 역할로 프로젝트의 비전을 제시하는 역할을 들고 있다.
IT 기술의 흐름과 향후 전망을 토대로 고객이 원하는 요구를 실현할 수 있는 방안을 마련하여 고객의 동의를 얻어내고 고객과 합의된 목표 시스템의 명확한 모습을 전체 프로젝트 구성원에게 제시하고 이해시킬 수 있는 능력이 이 역할의 수행을 위해 필요하다.

두 번째는 핵심 기술에 대한 조언을 할 수 있는 컨설턴트의 역할을, 세 번째로는 프로젝트가 부닥치는 중요한 사안에 대한 의사 결정을 할 수 있는 의사 결정자의 역할을 제시하고 있다.
기술 컨설팅과 주요 의사 결정은 프로젝트에서 맞닥뜨리게 되는 수많은 문제와 이슈들에 대한 올바른 판단과 결정을 할 수 있는 능력과 이를 전체 프로젝트 수행 조직에 전달하고 설득할 수 있는 능력을 필요로 한다.

네 번째는 수립된 아키텍처에 대한 코치 역할이다.
장기적인 비전과 기술적 이슈에 대한 올바른 의사결정을 통해 수립된 아키텍처를 전체 프로젝트 조직원들에게 정확하고 일관되게 전달하여 실재로 구현되는 시스템이 아키텍처와 일치되도록 하는 능력은 중요하다.

다섯 번째는 프로젝트에서 발생하는 다양한 형태의 대립을 해소하는 조정자의 역할이다.
프로젝트 수행과정에는 고객과 프로젝트 수행 조직간의 관계나 개발조직간, 개발자 개개인 간에 기술적인 문제로부터 비롯한 다양한 충돌이나 대립이 발생하는데 이때 이를 적절히 조정하고 올바른 결론으로 문제를 풀어갈 수 있는 역할이 요구된다.
이를 위해서는 기술력과 함께 대인관계를 원만하게 풀어갈 수 있는 설득력과 대화능력(Communication Skills)이 필요하다.

아키텍트가 수행해야 할 역할 중 여섯 번째는 소프트웨어 구현이다.
아키텍트는 자신이 수립한 아키텍처가 실재로 어떤 모습으로 구현될 것인지를 보여줄 수 있어야 한다.
프로토타이핑을 통한 아키텍처의 검증을 수행하고 그 결과를 기반으로 아키텍처를 정제하는 한편 개발조직이 참조할 수 있는 표준 설계, 샘플 소스 등을 생산할 수 있는 능력은 프로젝트 조직, 특히 개발조직을 아키텍처 중심으로 이끌 수 있는 가장 유력한 무기가 된다.

끝으로 아키텍트의 역할 중 일곱 번째는 아키텍처의 중요성에 대한 대변자의 역할이다.
이 역할은 지금까지 살펴 본 여타의 역할과는 달리 단일 프로젝트 내에서의 역할을 넘어서는 영역을 제시한다.
아키텍처 가치에 대한 대변자 역할은 아키텍처가 소프트웨어 개발 프로젝트에서 차지하는 비중과 중요성을 지속적으로 전파하는 것을 말한다.
올바른 아키텍처의 수립을 위해서는 꾸준한 투자가 필수적이란 것 그리고 새로운 아키텍처의 도입과 검증이 궁극적으로 IT 프로젝트의 개발 생산성을 높이고 수익률을 높이는 지름길임을 설파하는 것이 필요하다.

이상의 아키텍트 역할에 대한 정의는 대단히 포괄적인 내용을 담고 있어서 과연 이런 수준의 역할을 수행할 수 있는 아키텍트가 현실에서 존재할 수 있는가에 대한 의구심을 들게 한다.
한 사람의 아키텍트가 수행하기에는 감당해야 할 영역이 지나치게 넓고 그 깊이 역시 일반적인 수준을 넘어서기 때문이다.
예컨데 프로젝트의 비전을 제시하는 역할과 구현 단계의 표준을 제시하는 역할을 동시에 담당할 수 있는 능력은 쉽게 길러지지 않는다.
아울러 한 사람의 아키텍트가 수행하기 곤란할 정도의 과도한 역할 요구는 아키텍트의 업무 수행 품질을 저하시키고 결과적으로 프로젝트의 생산성과 수익성을 악화시키는 요인이 될 수 있다.
그러나 프로젝트의 난이도, 위험도의 증가로 인한 수익률의 감소를 해소하기 위해서 이상 7가지 역할은 반드시 필요하다.
따라서 7가지 역할에 대한 기술적인 편차는 인정한다 해도 소프트웨어 아키텍트란 직책을 가진 사람은 이들 7가지 역할 모두에 대해 나름의 능력과 경험을 갖추어야 하며 그런 사람들이 곧 진정한 소프트웨어 아키텍트라 할 것이다.

3. 소프트웨어 설계와 아키텍트

한편 앞서 살펴본 지멘스 연구소의 접근방식이 소프트웨어 개발 전체 공정상에서 필요한 포괄적인 영역에서의 자질과 능력을 다룬 것이라면 소프트웨어 아키텍트의 역할 영역을 소프트웨어 설계 분야로 집중하여 이 때 필요한 기술 지식을 세부영역 별로 제시한 의견도 있다.
IEEE Computer Society가 소프트웨어 설계 업무에 필요한 기술지식을 정리한 견해에 따르면 설계 영역에서 필요한 업무 지식을 6가지 대 분류와 29가지 소분류로 나누어 정의하고 있는데 설계 기본개념, 설계 전략과 같은 이론적 영역과 설계 중요 이슈, 설계 표기법과 같은 요소 기술적 영역 그리고 소프트웨어 구조, 품질 평가와 같은 실무 영역이 있다.
이들 29가지 분류 영역 중에서 소프트웨어 설계 공정, 아키텍처적 구조와 관점, 소프트웨어 품질 분석 및 평가 등 아키텍트 역할, 특히 실재 업무수행과 밀접한 관련이 있는 핵심적인 영역 몇 가지를 살펴보자.

먼저 소프트웨어 설계 공정은 프로젝트에서 개발하고자 하는 목표 시스템의 구조를 큰 그림에서 정립하는 아키텍처 설계 공정과 도출된 아키텍처를 기반으로 비즈니스 요구를 반영한 소프트웨어를 구현하기 위한 상세 설계 공정으로 구분할 수 있다.
아키텍처 설계 공정은 목표 시스템의 논리적, 물리적 구조를 다양한 관점에 따라 표현하는 과정이며 이를 위해 전략, 기술 이슈, 설게 표기법 등의 지식을 활용하게 된다. 아키텍처 설계의 세분화(Beak-down)는 프로젝트 이해 당사자들의 이해도, 특히 개발조직의 기술 이해도에 따라 수준이 정해진다.
상세 설계는 아키텍처 설계의 종료 지점에서 출발하여 보다 상세한 소프트웨어 구조를 표현하는 공정이며 구현 직전 단계까지 구체화해야 한다.

다음으로 아키텍처 구조, 관점은 목표시스템을 표현하기 위한 기법으로서의 아키텍처를 다루게 된다.
아키텍처는 프로젝트 구성원 간의 의사 소통을 위한 설계도가 되어야 한다.
또한 고객의 의사를 확인하고 반영하기 위한 게시판의 역할을 해야 한다.
이러한 목적을 위해 아키텍처가 어떻게 수립되어야 하는지를 아키텍트가 아는 것이 필요하다.
RUP에서 이야기하는 4+1 View , 지멘스의 4가지 View, CMU의 3가지 View 등은 모두 이를 위해 고민한 결과물이다.
이들 각각의 뷰는 완결적이면서 상호 보완적이어야 한다.
따라서 아키텍트는 시스템에 대한 서로 다른 관점을 다이어그램으로 표현할 수 있어야 할 뿐 아니라 이들 각각의 다이어그램의 구성 요소들이 추적 가능한 일관성을 갖도록 정립할 수 있어야 한다.

마지막으로 소프트웨어 품질 분석 및 평가는 목표 시스템을 설계하고 구현하여 업무에 적용하기까지의 전체 프로젝트 과정에서 발생할 수 있는 위험요소를 식별하고 이를 해소하기 위한 방법을 모색하는 과정이다.
엔터프라이즈용 소프트웨어를 개발하는 과정은 비즈니스 요구사항을 구현하는 과정이며 이때 비즈니스 기능에 감춰진 품질관련 요구가 필연적으로 제기된다.
이를 해결할 수 있는 최적의 방안을 도출하는 것이 곧 아키텍트의 핵심적인 역할이다.

4. 아키텍트의 자질과 역량

이제 아키텍트가 갖추어야 할 자질과 역량을 살펴 볼 시점이 되었다.
아키텍트가 가져야 할 3가지 자질은 통찰력, 창의성 (창조력), 논리성 (합리성)이며 3가지 역량은 기술력, 리더십, 의사소통 능력이다.
그림 2는 이들 핵심 자질과 역량을 지멘스 연구소의 아키텍트 역할 모델에 연관시켜 정리한 것이다.
각각의 자질과 역량이 아키텍트 역할 수행에 어떻게 연관되는지 하나하나 살펴보도록 하자.

4.1. 통찰력 (Insight)

아키텍트가 갖추어야 할 자질 중 으뜸은 통찰력이다.
통찰력은 아키텍트가 고유의 역할을 수행함에 있어 등대와 같은 역할을 한다.
통찰력은 사물의 본질을 꿰뚫어 볼 수 있는 능력을 말하는데 아키텍트에게 있어서는 IT산업과 기술 전반에서 단위 프로젝트까지가 통찰의 대상이 된다.
통찰의 대상이 단위 프로젝트일 경우에는 프로젝트의 목표를 명확하게 정의하고 이를 달성할 수 있는 경로를 정확하게 파악할 수 있는 능력이 아키텍트의 통찰력이다.
IT전반에 대해 판단을 하는 경우의 통찰력은 현재의 소프트웨어 산업, IT 산업의 메인 스트림을 관통하여 발전할 미래와 트랜드를 정확하게 읽고 이를 주도할 수 있는 능력이며 IT 산업과 기술의 방향에 대한 올바른 예측을 기반으로 이를 대비하기 위한 당장의 과제를 도출할 수 있는 능력이다.

지멘스의 아키텍트 역할 모델 중에서 가장 중요하고 포괄적인 것이 프로젝트의 비전을 제시하는 역할과 아키텍처의 가치를 널리 전파하는 역할이며 이를 위해 반드시 갖추어야 할 자질이 통찰력이다.
또한 프로젝트에서 맞닥뜨리게 되는 문제를 해결하고 조정하는 역할과 올바른 의사결정을 하기 위해서도 통찰력은 필요하다.
아키텍트의 통찰력은 제한된 자원으로 주어진 시간 내에 최적의 결과물을 만들어내기 위해서는 목표 시스템이 요구하는 다양한 기능, 품질요소들의 중요도와 난이도를 꿰뚫어보고 가장 좋은 조합을 이루어낼 수 있도록 해준다.

한편 구현과정에 통찰력이 요구되는 이유는 조금 다른 측면이다.
소프트웨어 구현 공정은 무에서 유를 창조하는 생산활동이며 한 줄 한 줄의 소스는 독창적인 창조물이다.
따라서 동일한 기능을 처리하는 소스라 해도 내부적인 연산 처리는 모두 다르며 최상의 로직을 구현한 소스는 드물다.
아키텍트는 구현할 소프트웨어가 처리하고자 하는 기능에 가장 적합한 소스를 생산할 수 있는 능력을 갖추어야 하며 그 적합성을 판단할 수 있게 해주는 것이 바로 구현에서의 통찰력이다.
OOP에 대한 체계적이고 실무적인 이해와 경험, 국제표준과 Framework에 대한 폭넓은 지식 등이 구현에서의 통찰력을 높여주는 요소가 된다.

4.2. 창의성(Originality)

아키텍트의 창의성은 새로운 비전을 만들고 올바른 문제해결 경로를 탐색하기 위해 필요한 자질이다.
통찰력이 비전 형성의 원천이라면 창의성은 통찰의 결과로 얻어진 결론을 기반으로 실재 비전을 만들기 위한 능력이다.
한번 정해진 비전을 현실에 맞도록 수정하고 개선하는 과정 역시 창의성에 의해 성패가 결정된다.
또한 창의성은 구현과정에서 부닥치는 복잡한 비즈니스 연산을 효과적으로 처리하기 위한 로직을 만들 수 있는 능력을 제공한다.
구현의 효율성과 완성도가 목표 시스템의 품질과 성능을 좌우하는 경우는 무수하며 창의성이 이를 뒷받침해준다.
한편 창의성을 통해 구상한 생각은 창조력(Creativity)을 통해 현실화된다.
따라서 창의성과 창조력은 동전의 양면과도 같은 것이며 아키텍트는 경험과 학습을 통해 이를 키워 나가야 한다.

4.3. 논리성 (Logicality)

아키텍트는 논리적이어야 한다.
모든 아키텍트의 결정은 단위 프로젝트에서든 IT 전반에 대해서든 해당 사업의 성패에 결정적인 영향을 미치게 된다.
따라서 논리적으로 타당한 명제 만으로 문제를 파악하고 필요한 결정을 내리는 것은 아키텍트에게 필수적인 자질이다.
논리적인 타당성을 갖춘 결론은 그 자체로서 중요할 뿐 만 아니라 결론에 대한 조직적 합의를 이끌어내는 핵심적인 요소로도 작용한다.
또한 논리성은 아키텍트가 갖고 있는 생각을 정확하게 묘사할 수 있게 해준다.
이를 통해 어렵고 복잡한 기술에 대한 컨설팅이 가능해지고 수립된 아키텍처에 대해 설명하고 전파하는 것이 가능해진다.
모두에게 당연한 것으로 여겨지는 문제에 대해 끊임없이 문제를 제기하고 올바른 해답을 찾기 위한 노력을 게을리하지 않음으로써 아키텍트의 논리력은 성장한다.

4.4. 기술력 (Technique Skill)

아키텍트의 자질에서 가장 중요한 것이 통찰력이라면 아키텍트의 역량 중에서 가장 중요한 것이 기술력이다.
기술력은 아키텍트를 아키텍트일 수 있도록 하는 핵심중의 핵심이라 할 것이다.
제아무리 통찰력을 갖추고 창의적이고 논리적인 사고를 한다 해도 그 밑바탕에 기술에 대한 올바른 이해가 깔려 있지 않다면 아무런 소용이 없다.
여기서 문제는 기술력에 해당하는 영역이 너무도 방대하고 깊어서 한 개인이 이를 모두 자신의 것으로 만들어 갖는다는 것이 불가능하다는 사실이다.
소프트웨어 기술력과 관련된 영역 가운데는 소프트웨어 개발 공정의 집대성이라 할 각종 표준 규격과 이를 구현한 소프트웨어 솔루션, 프로그래밍과 관련되는 개발 언어, 개발 도구, 개발환경 그리고 방법론, 아키텍처/디자인 패턴, 이디엄 , 다이어그램 등의 아키텍팅 및 개발 기법들 등등 많은 영역이 존재한다.
가히 아키텍트가 기술력으로 갖춰야 할 분야는 현존하는 소프트웨어 산업이 이룩한 모든 성과물들이라고 할 만 하다.

지나치게 넓고 깊은 기술력의 영역을 감안하면 이를 공통의 영역과 선택과 집중의 영역으로 나눠서 역량을 갖추는 노력을 기울여야 할 것이다.
표 1은 아키텍트가 갖춰야 할 필수 기술력을 아키텍트가 수행할 역할 영역을 기준으로 구분하여 아키텍처 수립에 필요한 영역, 소프트웨어 설계에 필요한 영역, 구현에 필요한 영역 각각에 대해서 정리한 것이다.
특히 구현에 필요한 프로그래밍 언어를 적어도 1가지 이상 능숙하게 다룰 수 있어야 한다는 점은 앞서 살펴본 아키텍트의 7가지 역할에서도 강조한 사항이며 반드시 갖추어야 할 필수 역량이다.

표 1 아키텍트 기술 영역

기술 영역	필수 기술 요소	비고 (관련 자료)
아키텍처 수립	아키텍처 패턴 수립 방법론 (프로세스)	SA in Practice 1 POSA 1 2
설계	디자인 패턴 설계 표기법 / 설계 언어 설계 도구 (1가지)	Design Pattern [3] UML Distilled [4]
구현	프로그래밍 언어 (1가지) 개발 도구

1 Software Architecture in Practice, CMU SEI에서 출간한 아키텍처 수립 가이드 북
2 Pattern Oriented Software Architecture 1, Layer, MVC, Reflection 등의 Classical Architecture Pattern 수록
[3] Design Patterns: Elements of Reusable Object-Oriented Software, GoF (Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)가 저술한 디자인 패턴의 고전
[4] UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3^rd Edition, Martin Fowler저술, UML에 대해 간략하고 체계적인 정리를 제공

다음으로 소프트웨어 솔루션에 대해 살펴보자.
소프트웨어 솔루션은 하드웨어 및 OS에 의해 영향을 받으며 개발 환경 및 개발 언어와도 밀접한 연관을 갖는다.
또한 목표 시스템의 활용범위나 데이터의 유형 나아가 목표 시스템이 적용될 산업 영역의 영향까지 받게 된다.
포털 기능이 필요하거나 비즈니스 프로세스를 관리할 필요가 있는 경우에, 대용량 데이터베이스 운용이 필요한 경우나 비즈니스적으로 독립된 분산 서비스의 연동이 필요한 경우 등과 같은 다양한 IT 환경에 의해서도 활용 가능한 솔루션이 정해진다.
상용제품 형태의 솔루션(각종 서버 제품들)에서 개발 Framework이나 오픈 소스 라이브러리와 같은 반제품 형태의 솔루션에 이르기까지 소프트웨어 솔루션의 유형도 다양하다.
어떤 솔루션을 어떻게 활용할 것인지의 문제는 아키텍트 본인의 경험과 아울러 앞서 본 바와 같은 IT 환경에 의해 결정되는 것이다.
따라서 아키텍트는 소프트웨어 솔루션 전반에 대한 이해를 기반으로 프로젝트의 특성과 목표 시스템의 성격을 감안하여 필요한 솔루션에 대한 결정을 할 수 있어야 한다.
이때 개개 솔루션에 대한 검토와 판단의 근거는 관련 전문가의 조언과 유사 프로젝트에서의 사례, 아키텍트 본인의 경험 등이 된다. 아울러 소프트웨어 솔루션에 대한 기술력은 범용성이 크고 국제 표준이면서 대부분의 프로젝트에서 적용되는 솔루션에 대해서는 필수적으로 기술력을 갖추어야 한다.
예컨데 자바 프로젝트를 수행할 경우 J2EE 기반 애플리케이션 서버와 비즈니스 프레임워크에 대한 기술력은 필수라 할 것 이다.

마지막으로 방법론과 기법은 프로젝트 수행에 많이 적용되는 주류 방법론을 중심으로 프로젝트 조직 전체를 리딩할 수 있는 전문적인 지식과 경험을 갖추는 것이 필요하다.
다만 이 영역은 필수적인 분야는 아니며 방법론 전문가와의 협업을 통해 이를 수행하는 것도 가능하다.

4.5. 의사소통 능력 (Communication Skill)

의사소통 능력은 아키텍트의 역량 중에서 실재 프로젝트를 성공으로 이끄는데 가장 큰 영향을 미치는 요소이다.
높은 기술력과 탁월한 통찰력이 프로젝트의 성공을 위한 근간이라면 의사소통 능력은 그 근간을 전체 프로젝트에 전파하여 아키텍트의 지향점과 판단에 모든 구성원을 복속하게 만드는 무기가 된다.
아키텍트는 수립한 아키텍처를 적절한 표현을 통해 문서화하고 이를 정확하게 설명하고 전달함으로써 목표 시스템의 구현과정에 아키텍처가 중심이 되도록 해야 한다.
또한 설계 및 구현과정에서의 기술적인 문제에 대한 조정과 의사 결정이 원활하게 조직적인 합의에 이르도록 하기 위해서도 의사소통 능력은 필요하다.
아키텍처 수립이 프로젝트 성공에 미치는 영향과 이로부터 확인되는 올바른 아키텍처의 가치를 전파하는데 있어서도 의사소통 능력은 중요한 역할을 한다.
결론적으로 아키텍트의 의사소통 능력은 아키텍트의 내재한 기술력과 통찰력을 대외적으로 보여주는 수단이자 궁극적으로 실재 프로젝트의 성공을 보장하는 핵심적인 능력이다.

4.6. 리더십 (Leadership)

아키텍트에게 있어서 리더십은 기술력이나 의사소통 능력에 비해 상대적으로 부차적인 요소이다.
그러나 기술적인 이슈에 대한 의사결정을 조직적으로 관철하고 개성 강한 개발자들의 다양성을 생산적으로 이끌 수 있는 능력은 대단히 중요하다.
아키텍처 중심의 시스템 개발을 이끌기 위해서도 리더십은 필요하다.
전체 프로젝트의 중심을 유지하고 수많은 위험요소들과의 싸움에서 이기기 위한 일사불란한 조직운용은 단지 프로젝트관리자 만의 몫은 아니다.
특히 기술적인 중심으로써 프로젝트 개발 조직을 이끄는 리더십은 아키텍트의 몫이다.

5. 결론

지금까지 살펴 본 아키텍트의 3대 자질과 역량은 하루아침에 얻어질 수 없으며 특히 이론 학습이나 탐구 만으로는 결코 얻을 수 없다.
지속적인 학습과 실재 프로젝트에서의 경험이 순환 구조를 이루어야 진정한 아키텍트의 역량이 갖추어진다.
한 사람의 아키텍트가 거대한 프로젝트의 성패에 결정적인 영향을 미칠 수 있는 이유는 바로 이점 때문이며 아키텍트의 가치를 인정하고 육성하기 위한 인내와 배려와 투자가 요구되는 이유도 바로 이 점 때문이다.

진정한 아키텍트는 태어나는 것이 아니라 만들어지는 것이다.

 

[출처:javajigi]

 

=================================================================================================

나의 개인적 사견이지만, 윗글을 모두 읽고 난 후의 전공자이며, 현재 개발자로서, PM,PL 역할을 수행하면서 느낀 나의 느낌은 그냥 말장난 같다. 새로운 용어를 만들어 내고 그 용어를 학습하게 만들고 결국은 그 역할이 이전의 다른 어떤 역할과 상충한다는 사실.... 참 불편한 진실인듯 하다.

 

결론은 이미 나와있는데.. 어떤 도구와 어떤 사람들로 그 결론을 이끌어 낼 것인가를 고민하자는것 아닌가...

쩝~~~ 얼렁 이 바닥을 떠나야지 원~~~~ 이제 못 해먹겠다 ㅋ