난 현재 개발 생활만 10년 물론 내세울만한 기술은 없다.

그러나 누구나 느끼듯 현실은 10년차 개발자가 되어 가다보면 개발 보다는 다른 것을 원한다.
현재 회사에서 요즘 주로 하게 되는것이 고객과 기술 미팅을 하고 필요한 설계 그리고 개발을 한다. 요즘 외부에 업무 미팅을 많이 하다 보니 스스로 한계점을 느낄때가 있다. 기술적인 한계점이야 검색하면서 책을 뒤지면서 공부를 하면 풀리는 부분들이 대부분이지만 설계에 있어 어떤것이 더 나은 방법인지 내가 접하지 않은 환경이면 어떻게 풀어야 할지 한참 고민 할때가 많다. 그리고 이것을 어떻게 정리하여 개발팀에 같이 공유를 해야 하는지..

정리한 문서를 던져 주었을때 그 문서만으로 대부분 이해 할 수 있게 할 수 없을까 하는 부분들이 가장 큰 어려움이다. 그러다가 우연히 접하게된 '아키텍트 이야기'(저자 : 야마모토 게이지)

이책을 읽으면서 내가 생각했던 단순한 아키텍트(즉 고객의 요구 사항을 듣고 전체적인 그림을 그리고 프로세스 설계를 하는)가 아니란 것을 알게 되었다.

이 책에서 아키텍트의 정의를 다음과 같이 내린다.

아키텍트는 '어떻게 만드는것이 올바른가'를 결정하는 결정권 자이다. 그리고 설계와 구현에 대한 스페셜리스트이고 동시에 시스템에 대한 다각적인 관점을 겸비한 제너럴리스트이다.

초기 이부분에 대한 정의를 보고 나를 되돌아 보게 되었다. 난 설계와 구현에 대한 스페셜 리스트이지도 않고 많은 시스템을 접해 보지 않았기에 다각적인 관점을 가지고 있지 않다.
여기서 한번의 좌절을 느낀다... 이후 아키텍트의 일을 예를 들어 아주 쉽게 설명 되어 있었다. 그리고 느끼는 부분은 아키텍트의 일이 정말 재미 있다 라는 것과 프로젝트에서만큼은 중추적 역활을 하는 사람이라는 것을 느끼게 된다.

즉 아키텍트는 단순히 다양한 지식만이 아닌 프로젝트 구성원에 대한 성격 및 스킬 레벨등 다양하게 파악하여 아키텍쳐를 구성 하여야 하며 또한 이 구성원들 사이에 중심축 역활이 필요 하다는 것이다.(솔직히 현재 나로선 정말 힘든 부분들이다..)

현재 IT 개발자들의 현실을 보면(저자가 일본사람인데 내용을 보면 일본이나 우리나라나 딱히 차이는 없다.) 어느정도 개발 년차가 되면 회사내에서 개발자가 아닌 다른 것을 원한다. 그것이 영업이던 PM이던 관리자던... 또한 현실적으로 어떤 회사던 아키텍트만 하는 사람을 원하진 않는다. 아키텍트 + PM등 슈퍼맨을 원한다. 그렇지 않으면 도태가 되는 것이 현실이다.

이 글을 보는 개발자 분들도 한번 이책을 보라고 권하고 싶다. 아키텍트에 대한 설명을 재미있게 쉽게 설명을 했지만 그외에 프로젝트 진행에 대하 세분화하게 분업화 시켜 놓은 부분에 다른 무언가를 느낄 수 있지 않을까 한다.