아키텍트 이야기 독서 후기

아키텍트 이야기 - 야마모토 케이지 지음, 이지연 옮김, 이용원 외 감수/인사이트

 이 책을 읽으면서도 아키텍트의 역할이 무엇인지 잘 납득이 가지 않았다. 그만큼 우리네 IT 프로젝트에서 PM(프로젝트 관리자)이 중구난방으로 하는 일이 많다고 본다. 3장을 넘겨 보면서도 '이런 거 PM 단에서 다했는데.'라는 생각이 머릿속에서 떠나질 않았다.

 그러다 SAP의 BC를 떠올려 보니 아키텍트가 어떤 존재인지 대략 감이 잡혔다. SAP의  BC(Basis Component)라는 직무(모듈)는 SAP ERP, BI 등의 서버와 DB 등의 기반 구축을 담당한다. SAP 프로젝트만큼은 우리나라의 다른 프로젝트와는 달리 PM이 아닌 BC가 기술 환경, 그러니까 아키텍처 구축을 주도하는 편이다. 그렇다 하더라도 SAP 환경에 국한되는 만큼 일반적인 SI 프로젝트에 비해 변경할 수 없는 게 워낙 많아 '아키텍트 이야기'에서 이야기하는 아키텍트보다는 책임이나 역할의 폭이 좁다.

 어떻게 생각하면 PM이 아키텍처에 통달하는 게 정말 유리하긴 하겠다. 지도자가 인적, 물적, 기술적 지식에 도통했다면 그 프로젝트는 98% 성공한다고 봐도 좋겠다. 그런데 그게 가능한가? 마음이 여전히 젊은 60세 PM이라면 모를까? 산전수전 다 겪으며 최신 기술 조류까지 꿰어 차는 사람은 없다고 봐야 맞겠다.^[각주:1] 게다가 우리나라나 외국이나 PM에게 시키는 건 좀 많은가? PM은 말 그대로 관리자이지 기술자의 반열에서는 발을 반쯤 뺐다고 봐도 무방하다.

 때문에 아키텍트가 필요하다다. 아키텍트가 아니라면 프로젝트에서 기술에 대한 책임을 질 만한 직책은 없을 것이고 이제까지 명확하게 책임을 지는 사람이 없다시피 했기에^[각주:2] 프로젝트의 방향이 시작하기도 전에 미적미적 산을 향해 놓인 사례가 많을 것이다.

 '아키텍트 이야기'를 읽다 보면 아키텍처가 구성되어 가는 단계를 알게 된다. 보너스로 잘못된 아키텍터를 수정해 나가는 과정도 볼 수 있다. 그런데 인적자원을 구성하는 것을 비롯해서 아키텍트와 PM과의 역할 차이를 명확히 설명해 주지는 않는다. 서너 차례 되풀이하여 읽으면서도 PM과 아키텍츠의 차이가 마음에 와닿지 않았다.^[각주:3] 이 책에는 PM이 거의 언급되지 않아서일 것이다.^[각주:4]

 그러한 아쉬움이 있더라도 이 책은 대한민국이라는 다소 기형적인 IT 시장에서 일하는 개발자들이 읽을 가치가 충분하다. '아키텍트 이야기'를 시작(!)으로 아키텍트의 자질을 키워 나가며 중고급 인력으로 성장하길 바란다.

더불어 도움 되는 블로그입니다.
arload - load to architect (http://arload.wordpress.com/)

1. 고객이나 현업이나 관리자는 이런 걸 바라겠지만. [본문으로]
2. 프로젝트에서 독박 쓰는 사람들이 있지요. 마음이 약하다든가 일복이 많다든가 하는 사람들이 본 업무 외에 부가적으로 총대를 맸습니다. [본문으로]
3. PM이 하는 일이 워낙 많으니까요. [본문으로]
4. 글을 뻘로 읽어서 그런 것일 수도 있겠지요. [본문으로]