먼저 역할을 간단하게 정리해보죠.
개발자: 실무자로서 구현을 함
아키텍트: 개발의 큰 그림을 그림
프로젝트 매니저: 일정, 예산, 범위 등을 관리함
커리어패스상으로 볼 때 개발자의 다음 단계가 아키텍트인 것은 확실합니다. 아키텍트는 SW의 전체 모습을 조망할 수 있는 능력과 경륜이 있어야만 가능한 역할이기 때문입니다.
다만 아키텍트는 실제 구현보다는 요구사항 파악, 기술의 선정, 설계에 치중하는 역할이기 때문에, 해외를 보면 10년 이상의 경력자 중에서도 개인적으로 구현(코딩)쪽을 계속 하고 싶은 사람들이 아키텍트로 포지셔닝을 하지 않고 개발자로 남는 경우가 많습니다.
개발자의 경우 자신이 맡은 특정 영역에 대해 실무적으로 구현을 하는 것이 주역할인데 반하여, 아키텍트는 디자인 능력 및 이해관계자와의 커뮤니케이션, 기술 리더십을 통해 개발의 전체 방향성을 결정하고 영향력을 행사합니다.
[추가글] 하지만 국내 현실을 보면, 아키텍트로서의 자격이 없는 사람(SW 개발 경력이 별로 없고 디자인 능력이 부족한 사람)이 어설프게 일을 함으로써 문제가 생기는 경우가 많습니다. 특히 개발 경력이 부족한 박사급 인력, SW 공학 전공자에게 맡기는 경우가 그렇습니다. 이에 대해서는 추후에 추가적으로 글을 쓰겠습니다.
실무적인 개발에 깊은 관심이 있어 계속 개발자로서 머무르는 것 또한 개인이 원한다면 좋은 선택이라고 생각합니다. 다만 개발자로 계속 머문다는 것은 자신이 터치할 수 있는 영역 및 영향력의 한계를 가질 수 밖에 없습니다.
보다 상위의 기술 리더십을 발휘하라고 아키텍트라는 역할이 있고, 개발자들을 관리하라고 매니저 역할이 있는데, 그런 역할들을 맡지 않고 스스로 개발자로 머무는 것이기 때문에 그로 인한 권한과 영향력의 한계는 감수할 수 밖에 없습니다. 그 대신 고급기술자로서 일을 하는 것이니까요.
그런 실무적인 일을 하는 상황에서 제가 말한 요소들은 상대적으로 중요하지 않을 것입니다. 그 점은 맞습니다. 기술자는 기술로 인정받는 것이 옳습니다.
하지만 제가 말한 포인트는 사회/조직 내에서 높은 대우를 받는 방법, 그리고 권한 및 영향력의 획득에 관한 사항입니다.
지위가 상승할수록 좁은 문이 기다리고 있습니다. TO도 적습니다. 그래서 권한을 부여하는 사람들은 기술 외적인 요소들을 중요하게 봅니다. 기술만 가지고 분별하기에는, 아무래도 기술만 있는 사람들이 많으니까요. (물론 기술도 없는 사람들은 더 많습니다만)
결론적으로,
특정 영역에서 자신이 하는 일에 대한 자부심을 갖고 일하는 것과, 보다 많은 권한을 획득하고 조직 최상층으로부터 인정을 받는 것은 거의 별개의 문제라고 생각합니다. 저는 후자를 중심으로 말씀 드린 것입니다. 그래야 업계에서 기회를 얻고 올바른 영향력을 발휘할 수 있지 않겠습니까?
올바른 영향력을 발휘할 수 있는 그런 분들이 많이 출현하고, 또한 사회/조직의 상층부에 많이 진출해야 한다고 생각합니다. 그래야 좀 더 개발자 중심의 체계 구현도 가능할 테지요.
제 글 중에서 일부 거부감이 드는 부분은 이해합니다. 제가 너무 현실적인 측면에서 적나라하게 말씀을 드려서 죄송한 느낌을 갖고 있습니다.
피드백 고맙습니다.
댓글 8개:
푸른하늘 은하수 님의 생각은 모든 개발자들이 꿈꾸는 일이라고 생각합니다. 하지만 현실은 그렇지 못하고, 그나마 현실에서 좀 인정받고 성공하기 위한 길을 류한석님이 제시해 준 것 같습니다. 푸른하늘 은하수님 바램대로 될려면 몇 가지 조건이 선행되어야 할 것 같습니다.
1. 사회적으로 엔지니어를 인정해 주는 풍토 -- 인정이란 의미는 그에 따른 보수가 따라야 겠죠. 삼성전자가 큰 성공을 거두고 세계적인 기업이 된 데에는 제가 생각하기엔 실제 반도체를 개발한 엔지니어들의 역할이 제일 크다고 생각합니다. 그렇게 대단한 결과를 내고도 우리는 핵심 엔지니어 이름하나 알지 못합니다. 기껏해야 삼성전자나 반도체 사장(이분 역할도 크긴 했습니다)이나 이모 회장을 알뿐이지요.
2. sw분야의 다변화
현실적으로 SW분야는 SI가 대부분을 차지합니다. SI에서 꽤 좋은 능력을 발휘한 개발자가 있고, 그 사람으로 인해 프로젝트가 성공하더라도 실제 프로젝트 성공에 대한 보상은 PM이나 금전적으로는 영업분야 종사자에게 많이 돌아갑니다. 물론 좋은 PM이나 회사를 만난다면 공을 인정받아 적절한 보상이 따를 수는 있겠지만, 실제로 이런일이 발생하는지는 잘 모르겠습니다.
결국 솔루션을 개발하고 성공하는 형태로 나아가야 그나마 개발자들의 역할이 크게 알려질텐데, 솔루션이란게 중소업체에서 감당하기에는 자금문제가 있고, 대기업은 투자를 잘 않하고...
일단 생각나는 것 2가지를 적어봤습니다..
필자님이 쓰시는 글은 경험에서 우러나와 쓰시는 글이지만 좀 정치적인 얘기인지라 아직 제대로 이해하기가 쉽지 않은거 같습니다...
저도 능력과 경륜이 아직 많이 부족한가 봅니다...
To charlie님/ 와우, 긴 덧글 감사합니다.
좋은 글입니다.
실제 반도체를 개발한 핵심 엔지니어의 이름 하나 제대로 알려지지 않은 것은 참으로 안타까운 일이라고 생각합니다.
성공 모델이 많이 나와야 엔지니어를 지망하는 사람들이 많을텐데, 워낙 성공 모델이 없으니까요.
개발자의 대한 보상 문제는 무엇보다 중요하다고 생각합니다.
To 독자님/ 아름답고 낭만적인 얘기만 적을 수 없는 현실. 왠지 제가 송구스럽습니다.
말씀하신대로 아키텍트의 역량을 갖고 있으면서도 개발자로 남아 있는 분들이 있습니다. 문제는 이러한 개발자들보다 경험이 부족한, 또는 비슷한 아키텍트가 팀을 이끌고 있을 때 입니다. 아키텍트가 그린 큰 그림에 대해서 개발자는 자기 자신의 경험에 비추어 판단할 것이고, 부족하다고 생각되는 점들에 대해서는 코멘트를 할 것입니다. 이러한 상황이 자주 반복될 경우 이 팀이 효율적으로 돌아가지 못할 수 있습니다. 식상한 속담이지만, 사공이 많은 배는 산으로 가게 되듯이 말이죠.
팀을 위해서 자신이 보기에는 결점이 있는 큰 그림일지라도 (치명적인 것이 아니라면) 현재의 아키텍트의 의견을 최대한 존중하고 자신의 아키텍트적 능력의 표출을 조절해야 하는 것 아닐까 하는 생각이 듭니다.
To 김세권님/ 고급기술자로서 너무 까칠하게 행동하는 것이 역효과를 내는 경우가 많습니다.
고급인력이라면 전체 큰 그림을 보면서 자신의 판단 수위를 조절하는 스킬이 필히 있어야 한다고 생각합니다.
전혀 적나라하지 않은데요.. ^^
To 민재님/ 그렇다면 제 글이 Fake라는 뜻이신지.. 흑흑 T.T
To 한석님/ 그렇게 되나요? ^^
좋은 글 많이 보고 있답니다. 근사한 모임도 추진하시고,, 배울 점이 많네요.
댓글 쓰기
댓글을 환영합니다.
스팸으로 인해 모든 댓글은 운영자의 승인 후 등록됩니다. 스팸, 욕설은 등록이 거부됩니다. 구글의 블로그 시스템은 트랙백을 지원하지 않습니다.