프로그래머 그 다음, 아키텍트?

아키텍처, 아키텍트에 대한 관심이 조금씩 높아지는 것 같다. 여러 가지 이유가 있겠지만 아무래도 소프트웨어의 복잡성이 높아져가고 각각 분해해서 개발하다보니 통합해야 하는 상황도 늘어나 자연스럽게 관심이 늘어는 탓인 듯.

비즈니스의 밸류와 사이즈가 다르기는 하지만, 소프트웨어 개발과 책을 만드는 과정은 참 비슷한 것 같다.

독자의 요구사항 분석 - 고객의 요구사항 분석
전체적인 얼개 설계    - 아키텍처 설계
원고 개발                 - 코딩
원고 피드백              - 테스트와 디버깅
교열/교정                 - QA
하판                         - 출시

책을 만들 때도 설계 단계에서 너무 세밀하게 한다고 해서 반드시 좋은 책이 나오는 것은 아니다. 소프트웨어 개발에서도 마찬가지인 것 같다. 그래서 애자일이니 XP니 TDD니 하는 방법론이 나오게 된 것 같다.

오늘 훈스닷넷에서 주최한 아키텍처 세미나에 참석했다.
약 50여 명 정도 참석하였는데 여성 참석자도 4명 정도 보였던 것 같다. 비율이 너무 적나? ^^ 

두 강사님의 강의 스타일이 많이 달랐다. 한분은 경험적인 내용을 프리하게 소개한 반면, 다른 한분은 정교하게 다듬어진 아키텍처 이론에 대한 강의를 하여 적절하게 밸런싱이 맞은 좋은 강의였다.
물론, 듣는 청중의 입장에서는 약간은 지루한 이론 강의보다는 실제 경험담 얘기가 더 듣기 좋은 것은 사실이다. 하지만, 용어를 정확하게 정의하고 아키텍처의 히스토리, 먼저 고민했던 사람들의 일반화한 경험 등도 그못지 않게 중요한 것 또한 사실이다. 아무튼 하나의 강의는 애자일 스타일인 것 같았고 다른 강의는 정교한 프레임웤 기반의 개발 스타일을 보는 듯 했다.

나는 개발자 출신도 아닌데, 아키텍처나 아키텍트라는 주제의 강의가 머리에 와닿는 이유는 뭘까? 오히려 그곳에 있는 개발자 출신들보다 내가 더 집중했던 것 같고 요목조목 필요한 내용을 들을 빼곡히 메모했던 것 같다.
이유를 생각해보니 아키텍트에게는 사람과의 커뮤니케이션, 리더십, 관리 능력, 큰그림을 그릴 줄 아는 능력, 비전메이킹 능력 등등이 요구되는데, 이것은 시간이 지나면서 생겨나는 게 아니라 조직을 구성해서 이끌어보고 문제도 경험해보고 실패와 성공도 해보는 데서 자연스럽게 나오기 때문인 것 같다.
내 자랑? ^^

아키텍트는 "고수"임에 틀림없다. 예전 무술영화에서 보면 고수가 제자를 들여 물긷는 것부터 시키고 이유도 가르쳐주지 않고 열나 필요없는 것 같은 것들을 반복해서 시키는 신이 많이 나온다. 그러다, 어느 순간부터 고수가 아는 내용을 순식간에 전해주고 "하산하라"라는 식상한 말을 하고 제자는 중원으로 나간다는...^^ 오늘 강의를 통해 얻은 것은 아키텍트가 되는 것도 그런 비슷한 과정인 것 같다는 생각. 개발할 때 열심히 역량을 쌓고 열나 깨져보기도 해야 비로소 깨달음이 오는 순간이 올거라는....

아무래도 오늘 청중의 분위기는 "아키텍트가 되려면 어떻게 해야 하지?" 하는 구체적인 답, 아니 어떻게 보면 나도 저렇게 해볼 만하다는 롤모델을 찾는, 그런 분위기였던 것 같다.

두 시간의 강의가 아키텍처가 무엇인지, 아키텍트가 되기 위해서는 어떻게 해야 하는지를 얻기에는 당연히 턱없이 부족한 시간이다. 그러나, 현업에 돌아가서 오늘 들었던 얘기를 곱씹어보면서 스스로 깨달음을 위한 좋은 재료가 될 만한 것들을 많이 얻었을 시간임엔 틀림없었던 것 같다.

---------------"말, 말, 말"--------------

"아키텍트가 되는 길은 도제제도와 비슷하다"
"십수권의 디자인패턴 책을 읽고도 이해가 안갔는데, 스프링 라이브러를 보고 코드가 아름답게 느꼈고 그제야 디자인패턴이 무엇인지 이해가 되었다. 그 뒤로 난 스프링빠가 되었다"
- 안영회강사님

"최초로 아키텍트라는 직함을 가진 분은 빌게이츠. 정확한 직함은 Chief Software Architect."
"아키텍트가 하는 일은 항상 새로운 일이다"
"아키텍트는 인사이트가 있어야 한다"
- 이충헌 강사님