[Architect] "아키텍트"의 역할

"아키텍트"의 정의와 역할에 대하여 세 차례에 걸쳐 포스팅 됩니다. 

[Architect] '아키텍트'란?

[Architect] '아키텍트'의 역할

[Architect] '아키텍트'가 갖추어야 할 자질

이번에는 "아키텍트"의 역할에 대해서 알아보고자 한다. 지난 포스팅에서 "아키텍트"의 정의를 다음과 같이 했다.

 아키텍트는 기술 패러다임의 본질을 알고, 복잡하고 다양하게 등장하는 여러 기술 및 솔루션의 특성과 장단점을 구체적으로 파악하여 구축하고자 하는 시스템에 올바르게 적용함으로써 프로젝트의 성공과 수익성 제고에 기여할 수 있는 능력을 갖춘 기술 전문가이다.

그렇다면 이런 아키텍트가 해야할 직무와 역할이 무엇인지를 좀더 자세히 알아본다.

국내의 IT 실상에서 아키텍트의 역할에 대한 명확한 정의와 그에 맞는 사례를 찾아보기는 매우 힘들다. 이에 해외에서 제시하는 사례를 토대로 아키텍트의 역할을 정의해본다.

1. 프로젝트의 비전 제시

비전을 제시한다는 것이 제목만큼 거창한 의미는 아니다. IT 기술의 흐름과 향후 전망을 토대로 고객이 원하는 요구를 실현할 수 있는 방안을 마련하고 고객의 동의를 얻어내는 것을 기본으로 하여, 합의된 목표 시스템의 명확한 구조(모습)을 프로젝트의 구성원에게 제시하고 이해시킬 수 있는 능력을 의미한다.

Product Manager의 역할과 혼동이 될 수 있지만, 위에서 언급한 아키텍트의 정의를 토대로 PM과의 역할은 기술집약적 이라는 단어로 엄연히 구분될 수 있다. 

2. 기술 컨설턴트

아키텍트의 정의에서도 알 수 있듯이, High-Level Engineer이다. 무엇을 구축하는 지에 대한 기술적 Leader 역할을 할 수 있어야 한다.

3. 의사 결정자

의사 결정자라는 표현은 좀 과장된 듯 하지만, 의사결정을 위한 기술 책임자라는 의미가 좀더 명확할 듯 하다.

프로젝트를 진행함에 있어서, 프로젝트 착수 이전에 아무리 요구사항에 대한 정리가 깔끔하게 되었다고 하더라도 진행 중 발생하는 이슈가 없을 수는 없다. (없다면 오히려 이상한 것이다.) 이때, 고객의 요구사항과 충돌이 발생하는 이슈와 문제에 대하여 올바른 판단과 결정을 할 수 있는 능력과 이를 전체 프로젝트 수행 조직에 전달하고 설득하는 능력이 필요하다.

4. 개발 코칭

장기적인 비전과 기술적 이슈에 대한 올바른 의사결정을 통해 수립된 아키텍쳐를 전체 프로젝트 구성원들에게 정확하고 일관되게 전달하여 실재로 구현되는 시스템이 설계된 모습과 일치되도록 하는 능력을 이야기 한다. 이때, 일관된 규약이 지속적으로 유지될 수 있도록 여러 방면에서 검토되어야 한다.

5. 조정자

3번 항목과 동일한 내용일 수 있으나 3번 항목이 프로젝트 요구사항에 대한 기술적 이슈를 해결하는 것이라면, 이는  프로젝트 수행과정에서 발생하는 예기치 못한 대립에 대하여 원만하게 해결을 할 수 있는 Communication Skill이라 할 수 있다.

6. 소프트웨어 개발 전문가

아키텍트는 자신이 설계한 아키텍쳐가 실재로 어떻게 동작을 하고, 어떤 모습으로 구현될 것인지에 대해 보여줄 수 있어야 한다. Prototyping을 통하여 아키텍쳐의 검증을 수행하고 그 결과를 기반으로 아키텍쳐를 정제하는 과정이 필요하며, 특히 개발 조직이 참조할 수 있는 표준 설계, 샘플 코드 등을 생산할 수 있는 능력은 개발조직을 아키텍쳐 중심으로 이끌 수 있는 중요한 능력이다.

7. 대변자

현재까지 프로젝트 조직 내부에 영향을 미치는 역할이었다면, 대변자로서의 역할은 프로젝트 조직 외부에 영향을 미치는 역할이다. 이는 현재 구성된 아키텍쳐가 프로젝트에서 차지하는 비중과 중요성을 지속적으로 전파(보고)함으로 올바른 아키텍쳐의 수립과 유지에 대한 꾸준한 투자가 필수적이라는 것과 좋은 아키텍쳐의 도입과 검증이 IT 프로젝트, 시스템에서 생산성과 수익률을 높이는 것임은 인지시킬 수 있어야 한다.

종합적으로 아키텍트의 역할은 진행하고자 하는 프로젝트에 대한 내적으로는 What, How, Why를 명확하게 정의하고 프로젝트 참여 구성원에게 이해시키는 것이다. 이때, Why 보다는 What, How에 조금 더 집중되어 있다고 생각된다. 이와 함께 프로젝트 외적으로는 지금의 아키텍쳐가 조직의 자산으로서의 가치를 가진다는 것을 입증하여, 지속적으로 관심을 받을 수 있게끔 하는 것이라 생각한다.

아키텍트는 하나의 시스템에 대하여 개발, 마케팅 등 다양한 관점에서도 동일한 이해를 도울 수 있도록 Diagram으로 표현할 수 있어야 하며, 시스템을 구성하는 각각의 컴포넌트를 표현한 Diagram 사이에서 추적이 가능하도록 일관성을 유지할 수 있는 기준을 정립할 수 있어야 하기 때문에, 아키텍트의 영역을 기술 지식에 국한지어 정의하기 보다는 기술적인 지식을 기반으로 사업의 전략과 조직의 운영 등 전반적인 영역을 포함하여 그 역할을 정의하여야 한다.

SW Visualization을 통한 품질의 가시성 확보, 형상관리를 이용한 프로젝트 진행에 대한 가시성 확보라는 말과 같이 SW는 완제품을 보기 전까지 그 진행 상태에 따른 모습을 보는 것이 어렵다. 그렇기 때문에 목표 시스템을 설계, 구현하여 제품이 완성되기까지 전체 과정에서 발생할 수 있는 Risk(위험요소)를 식별하고 이를 최대한 해소할 수 있는 기술전문가가 필요한 것이며, 그 역할을 아키텍트가 해야 하는 것이다.

다음에는 이러한 아키텍트의 역할을 원만하게 수행하기 위하여 필요한 자질에는 어떤 것이 있는지 알아보도록 한다.