아키텍처를 이해한다는 것.

소프트웨어 개발자들 간의 시각 차이를 이해한다는 것입니다.

대규모이건 중규모이건, 소규모이건 혼자서 소프트웨어를 만들지 않습니다.

개발자, 기획자, 디자이너들이 서로 모여서 하나의 작품을 만들기 위해서 모두 공을 들이죠.

아키텍처는 그들 간의 시각과 각자의 작업방법, 작업순서, 우선순위, 결과물들에 대한 공통된 흐름을 모두 담고 있습니다.

개발자 간에도 만들어지는 속도가 다르고, 변경되고 테스트되는 절차와 환경이 다릅니다.

기획자나 디자이너의 작업 속도와 결과물의 상태도 다르고요.

아키텍트는 그러한 '차이'를 최대한 하나의 결과물로 완성할 수 있도록 공을 들입니다.

초기에 작은 결과물부터, 최종 완성 형태가 

사용자의 가치에 부합하도록 하게 합니다.

전체 그림을 모든 사람들이 이해하고 있지 못하다면,

구체화된 완성 그림을 최대한 팀원들에게 이해시키고, 목표에 가깝게 만들도록 노력해야 합니다.

아키텍처를 모두 이해하는 팀원들이 모여있는 구조의 팀빌딩이 가능하다면...

아키텍트는 필요 없어도 되겠지요.

하지만.

대부분 속도들이 다르고, 우선순위와 절차가 다르기 때문에

이에 대한 불협화음과 회의시간들이 늘어나고

상대방을 설득하는데 어려움을 겪게 됩니다.

더군다나..

실제 개발환경에서는

리소스의 부족, 일정의 뒤틀림, 우선순위의 변동 등과

고객의 변덕에 의한 요구사항 변경까지...

매우 이상적인 조직은 아키텍처를 모두 이해하는 팀원들이 되면 좋겠지만.

실제 그런 환경은 꿈에서나 만날 수 있을 것입니다.

대부분은 조율과 관리, 고민과 걱정을 누군가 안아야 하니까요.

그것을 아키텍트가 하게 됩니다.

그뿐이죠.