먼저 역할을 간단하게 정리해보죠.
개발자: 실무자로서 구현을 함
아키텍트: 개발의 큰 그림을 그림
프로젝트 매니저: 일정, 예산, 범위 등을 관리함
커리어패스상으로 볼 때 개발자의 다음 단계가 아키텍트인 것은 확실합니다. 아키텍트는 SW의 전체 모습을 조망할 수 있는 능력과 경륜이 있어야만 가능한 역할이기 때문입니다.
다만 아키텍트는 실제 구현보다는 요구사항 파악, 기술의 선정, 설계에 치중하는 역할이기 때문에, 해외를 보면 10년 이상의 경력자 중에서도 개인적으로 구현(코딩)쪽을 계속 하고 싶은 사람들이 아키텍트로 포지셔닝을 하지 않고 개발자로 남는 경우가 많습니다.
개발자의 경우 자신이 맡은 특정 영역에 대해 실무적으로 구현을 하는 것이 주역할인데 반하여, 아키텍트는 디자인 능력 및 이해관계자와의 커뮤니케이션, 기술 리더십을 통해 개발의 전체 방향성을 결정하고 영향력을 행사합니다.
[추가글] 하지만 국내 현실을 보면, 아키텍트로서의 자격이 없는 사람(SW 개발 경력이 별로 없고 디자인 능력이 부족한 사람)이 어설프게 일을 함으로써 문제가 생기는 경우가 많습니다. 특히 개발 경력이 부족한 박사급 인력, SW 공학 전공자에게 맡기는 경우가 그렇습니다. 이에 대해서는 추후에 추가적으로 글을 쓰겠습니다.
실무적인 개발에 깊은 관심이 있어 계속 개발자로서 머무르는 것 또한 개인이 원한다면 좋은 선택이라고 생각합니다. 다만 개발자로 계속 머문다는 것은 자신이 터치할 수 있는 영역 및 영향력의 한계를 가질 수 밖에 없습니다.
보다 상위의 기술 리더십을 발휘하라고 아키텍트라는 역할이 있고, 개발자들을 관리하라고 매니저 역할이 있는데, 그런 역할들을 맡지 않고 스스로 개발자로 머무는 것이기 때문에 그로 인한 권한과 영향력의 한계는 감수할 수 밖에 없습니다. 그 대신 고급기술자로서 일을 하는 것이니까요.
그런 실무적인 일을 하는 상황에서 제가 말한 요소들은 상대적으로 중요하지 않을 것입니다. 그 점은 맞습니다. 기술자는 기술로 인정받는 것이 옳습니다.
하지만 제가 말한 포인트는 사회/조직 내에서 높은 대우를 받는 방법, 그리고 권한 및 영향력의 획득에 관한 사항입니다.
지위가 상승할수록 좁은 문이 기다리고 있습니다. TO도 적습니다. 그래서 권한을 부여하는 사람들은 기술 외적인 요소들을 중요하게 봅니다. 기술만 가지고 분별하기에는, 아무래도 기술만 있는 사람들이 많으니까요. (물론 기술도 없는 사람들은 더 많습니다만)
결론적으로,
특정 영역에서 자신이 하는 일에 대한 자부심을 갖고 일하는 것과, 보다 많은 권한을 획득하고 조직 최상층으로부터 인정을 받는 것은 거의 별개의 문제라고 생각합니다. 저는 후자를 중심으로 말씀 드린 것입니다. 그래야 업계에서 기회를 얻고 올바른 영향력을 발휘할 수 있지 않겠습니까?
올바른 영향력을 발휘할 수 있는 그런 분들이 많이 출현하고, 또한 사회/조직의 상층부에 많이 진출해야 한다고 생각합니다. 그래야 좀 더 개발자 중심의 체계 구현도 가능할 테지요.
제 글 중에서 일부 거부감이 드는 부분은 이해합니다. 제가 너무 현실적인 측면에서 적나라하게 말씀을 드려서 죄송한 느낌을 갖고 있습니다.
피드백 고맙습니다.
