얼마전에 트윗에 올라온 '개발자라고 착각하는 무늬만 개발자?'http://techit.co.kr/6551 글을 읽었다. 이 글이 한국의 많은 개발자들에게 생각할 거리를 던져주었다고 생각한다. 이 글에 대한 답글은 아니지만 필자가 개발자인가라는 질문을 하고 싶어져서 썰을 좀 풀어보조자 한다. 참고로 필자는 월급을 받고서 일하기 시작한지는 12년째로 접어들고 있다.
현재 내가 하는 역할
필자는 현재 개발 팀장을 하고 있다. 3년전부터 개발 팀장이라는 직책을 맡고 있고, 지금 하고 있는 일은 다음과 같다.
- 아키텍처 설계하기, 기술 선택하기
- 프로젝트 초반에 개발환경 구축하기
- 주요 도메인 모델 설계 또는 팀원이 설계한 것 리뷰하기
- 프로젝트 일정 계획 세우기/체크하기
- 외부 인력 수급 관리하기
- 난이도 높은 모듈/기능에 대한 구현하기
- 여러 프로젝트에 동시에 참여하기
- 회사 외적으로는 기술 관련 글 쓰는 사람
하고 있는 일을 주요 역할로 나눠보면 다음과 같다.
필자는 (초보이긴 하지만) 아키텍트의 역할을 하고 있다. 만들어야 할 소프트웨어의 전체 구조를 설계하고 구현 기술을 선택하고 밀고 나간다. 이 외에 성능, 보안, 확장성 등 여러 가지 구현과 직결되는 내용을 챙긴다.
주요 도메인에 대한 모델을 설계하거나 팀원이 설계한 모델을 리뷰하는 선임 개발자의 역할도 수행한다. 경우에 따라 코드 중에 마음에 안 드는 부분을 변경하도록 지시도 한다. 팀이 규모가 크다면 이 역할을 다른 사람에게 주겠지만 아직 규모가 작기 때문에 필자가 하고 있다. 물론, 필자가 다 하는 것은 아니며 일부는 중간에 위치한 팀원이 초급 팀원을 가이드하고 있다.
때로는 직접 구현에 참여하기도 한다. 난이도가 다소 높거나 일정을 단축시켜야 할 때가 그런 경우다. 물론, 아직까지 제일 잘 하는 것 중의 하나가 코딩이기도 하다. 하지만, 코딩하는 비중은 높지 않다. 1주일에 2일 이상을 코딩에 투자하지는 않는다. 코딩에 많은 시간을 투자했다간 다음에 언급할 프로젝트 관리자로서의 역할을 제대로 수행할 수 없게 된다.
필자는 근무시간의 40~60% 정도를 프로젝트 관리에 사용한다. 큰 수준에서의 일정 계획을 수립하고, 진행 상황을 확인하고, 위험 요소를 해소하는 데 많은 시간을 소요한다. 예를 들어, 필요한 인력을 수급하기 위해 외부 업체와 미팅을 하며, 매일 오전마다 미팅을 통해 진척상황을 관리한다. 아직까지 프로젝트 관리는 잘 하는 분야가 아니기에 위기의 순간에는 윗사람의 힘을 많이 빌리곤 한다.
이 외에 회사의 소프트웨어 분야의 기술쪽 팀장으로서 몇 가지 업무에 프로젝트 코디네이터나 실행자로 참여하고 있다.
그리고, 남은 한 가지 역할은 기술 관련 글을 쓰는 작가이다. 작가는 필자가 오래도록 갖고 싶은 역할로서 블로그나 책을 통해서 기술 관련 내용을 글로 남기고 있다.
포기 또는 일부러 하지 않는 것
현재의 역할을 '잘' 해야 하기 때문에, 아래의 것들은 일부 포기하고 있다.
이제 모든 신기술을 익힐 수는 없다. 요점 정도만 알고 넘어가거나 호기심에 책을 읽어보는 정도이다. 예를 들어, 최근에 읽은 책 중의 하나는 node.js와 하둡에 대한 책이었는데, 이 책들을 읽은 이유는 node.js나 하둡 자체를 익히기 위해서가 아니라 node.js나 하둡이 무엇인지 알기 위함이었다.
하루 종일 코딩을 하는 것도 하지 않는다. 그랬다간 다른 역할에 구멍이 난다. 순간적으로 프로젝트의 진척도는 올라갈 지 몰라도 여러 곳에서 구멍이 나면서 프로젝트 들이 엉망이 될 수 있다.
역할을 잘 수행하기 위해 하는 것들
아키텍트나 구현자로서의 역할을 잘 수행해내기 위해 하는 일은 지속적으로 기술 흐름을 파악하는 것이다. 최근의 빅 데이터, node.js, HTML 5 등이 각광받는 이유 등에 대해 공부한다. 일단, 큰 그림 수준에서 이해하고 필요하면 한 놈씩 골라서 본격적으로 판다.
프로젝트 관리자는 필자가 잘 하고 싶은 분야는 아니다. 프로젝트 관리 자체가 아주 재미없는 건 아니지만 필자는 구현에 참여할 때가 더 즐겁다. 하지만, 구현이 재미있다고 구현만 하면 큰 그림을 볼 수 없고, 프로젝트 관리 능력이 없다면 사실상 괜찮은 아키텍트나 선임 개발자가 될 수 없음을 알고 있기에 어느 정도의 프로젝트 관리 능력을 보유하기 위해 노력하고 있다. 프로젝트 관리와 관련된 책이나 글을 읽고 따라해 보는 것이 주된 노력이다.
필자의 오랜 목표 중의 하나는 기본기와 관련된 책을 쓴 작가가 되는 것이다. 이를 위해 설계와 관련된 내용을 지속적으로 학습하고 있고, 틈틈히 글로 배운 지식을 정리해 보고 있고 언젠가 이를 바탕으로 좋은 책을 쓸 것이다. 더불어, 입문자를 위한 책을 쓰는 것도 중요하게 생각하고 있기 때문에 JSP나 Java 언어와 관련된 책도 꾸준히 개정해 나갈 것이다.
그래서 난 개발자인가? 앞으로도 개발자일 것인가?
그럼, 이제 본론으로 돌아가 '난 개발자인가?'라는 질문에 답을 해 보자. 프로젝트 관리도 넓은 의미에서 보면 개발의 범주에 속하지만, 아키텍트까지가 개발자가 아닌가 하는 생각이 든다. 그런 의미에서 필자는 현재 절반은 개발자로서 일을 하고 있고, 나머지 절반은 관리자로서 일을 하고 있다. 물론, 사생활에서는 작가로서 반, 개발자로서 반 정도의 시간을 보내고 있다. 이런 점에서 아직은 개발자라고 불려도 손색은 없을 것 같다.
요즘 내가 하는 고민은 이 비율을 앞으로 어떻게 조정할 것인가에 대한 것이다. 올해 이 고민을 시작했고, 올 해 안에 답을 내려고 한다. 참고로 필자는 올해 36세이며, 결정에 따라 앞으로 5년 동안 무슨 일을 할 지가 결정될 것이다. 이 결정에는 여러 가지 고려할 것들이 있는데, 이는 다음과 같다.
필자는 가장이고, 아이가 있기도 하다. 앞으로 가정에 돈이 많이 들어갈 예정이기에, 연봉은 중요한 고려 사항이다. 한국에서 평균적으로 팀원보다 프로젝트 관리자가 연봉이 높은 점을 감안하면 고민이 더 커진다. 프로젝트 관리자나 기술쪽의 더 높은 지위(본부장, CTO 등)로 경로를 잡아서 향후 5년간 연봉을 더 높여갈 것이냐 아니면 적당한 연봉에 만족하면서 구현자로서의 즐거움을 좀 더 만끽할 것이냐? 이것이 큰 고민거리다.
한국에서 구현자로서 15년 이상의 경력을 가진 고급 개발자는 (연봉으로서) 인정해주는 곳이 별로 없기에 구현자로서 즐거움을 계속해서 누리고 싶다면 프리랜서로 경력에 비해 더 낮은 돈을 받고 계속 일을 해야 할 지도 모른다. 아니면 단가를 그나마 잘 받기 위해 외주로 일을 받아 전문적으로 구현을 해 주는 업체를 차려야 할 지도 모른다. 하지만, 필자가 일을 계속 따 올 수 있는 영업력이 있는가에 대해서는 상당한 의구심이 든다.
프로젝트 관리자 경로를 잡든 구현자의 기간을 연장하든 둘 다 국내에서는 쉽지 않아 보인다. 필자의 역량은 구현자로서 역할을 수행할 때 더 잘 발휘되지만 40살 넘은 구현자가 존재하는 경우가 흔치 않을 뿐더러, 개발 팀에서 40이 넘은 팀원을 구현자로 두고 있는 회사가 얼마나 있을까 하는 의구심도 든다. 물론, 관리자로서 본부장/CTO 등으로 승진하는 것은 더 어려운 일이다. 필자는 구현자로서의 역할을 잘 한다고 해서 관리자로서의 역할도 잘 할거라는 보장이 없음을 알고 있고, 그런 의미에서 피터의 법칙(승진할수록 일을 못 한다는)에 어느 정도 동의한다.
내 위에 직접적으로 연결된 40대 초/중반의 선배님들 중에 구현자로서 역할을 하는 분은 정말 소수에 불과하고 대부분은 관리자로서 일을 하고 계신다. 이런 모습을 보면 내가 앞으로 얼마나 구현자로서 한국에서 버틸 수 있을까 하는 고민에 빠져든다.
필자가 하고 싶은 것은 켄트 벡이나 밥 아저씨처럼 IT의 개발자로서 계속해서 일을 하면서 기본기를 닦아 줄 수 있는 지식을 전파하는 것이다. 언젠가 실력을 더 쌓아 객체 지향과 패턴에 대한 기초 서적을 쓰고 싶고, 그러면서 개발자로서 능력에 알맞은 대우를 받으면서 일을 하고 싶다. 이게 가능하지 않다면, 본업을 바꾸고 취미로 개발을 해야 할까?
한 동안은 하고 싶은 것과 먹고 살 거리를 함께 고민하는 시간이 될 것 같다. 고민해 보자.
댓글을 달아 주세요
비밀댓글입니다