한 SI회사의 프로세스에 대한 오해

필자는 업계의 여러 사람과 얘기할 기회가 많다.

최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다.

SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.

"공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.

"공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다.

최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.

그래서 진행한 것이 해외에서 "분석/설계"를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 "구현"만 하면 되도록 하는 프로세스를 만든 것이다.

실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 "구현"은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다.

이렇게 공정을 분리하려면 "분석/설계" vs "구현" 보다는 "분석" vs "설계/구현"이 더 낫다.

설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 "설계/구현"을 할 수 있기 때문이다.

여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.

더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다. 

이렇게 제대로 "공정분리"를 하기 위해서 대전제가 하나 있다. 

바로 "분석"역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다.

현재의 분석역량은 기껏해야 "기능"분석과 약간의 "비기능"을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다. 

필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다.

시행착오를 겪는 시간은 짧을수록 좋다.

무늬만 개발자

우리나라에서 소프트웨어를 개발한지 10년이 넘은 개발자 중에서 진짜 개발자는 생각보다 적다. 15년쯤 지나면 자신은 스스로를 개발자라고 생각할지 몰라도 진짜 개발자인 경우는 급격히 줄어든다. 대부분은 개발과 관리의 경계에서 애매한 포지셔닝을 하다가 다시는 개발로 돌아오지 못하곤 한다.

그럼에도 자신은 개발자라고 착각을 하는 경우가 많다. 또는 자신을 Architect라고 우기기도 한다.

선임급 개발자를 채용하기 위해서 인터뷰를 하면 이런 "개발자가 아닌 무늬만 개발자"를 자주 볼 수 있다.

매일 수많은 회의에 쫓겨 다니고, 온갖 보고서를 만들고, 수시로 경영진에게 보고하고, 팀원들 관리하고 평가하느라고 시간을 다 보내면서, 스스로는 개발에 관해서 아는 것은 많다고 생각해서 개발할 때마다 간섭하고 스스로 뛰어난 Architect라고 생각한다.

이런 사람들은 개발을 좀 안다고 해도 절대로 개발자가 아니다. 개발과 관리의 차이에 대한 개념도 희미한 상태이다. 대부분은 개발자로 다시 돌아갈 수 없는 상태이다.

절대로 "개발"과 "관리" 둘 다 잘할 수는 없다.

우리나라 대부분의 기업에서 본부장, 부문장, 부서장쯤 되면 이러한 상태에 이르게 된다.  그래도 팀장급에서는 개발자의 모습을 아직도 간직하고 있는 경우가 종종 있다.

하지만 팀장급 이상으로 올라가게 되면 개발자이고 싶은 관리자가 되게 된다. 물론 외형적으로도 완전히 관리자를 선언한 사람도 있겠지만, 여전히 개발자이고 싶은 사람들도 매우 많다.

이렇게 되는 결정적인 이유는 경영자의 개발조직 관리에 대한 오해에서 비롯된다. 경영자는 개발조직을 관리하는 관리자는 개발을 매우 잘 알아야 하기 때문에 가장 뛰어난 개발자들이 관리를 하는 것이 옳다고 생각한다. 그래서 경험 많은 선임 개발자들에게 본부장, 부문장, 부서장을 맡기곤 한다.

개발조직을 관리하는 관리자는 개발에 대해서 개발자만큼 잘 알 필요가 없다. 개발자가 개발에 대해서 아는 정도와 관리자가 알아야 하는 정도는 엄청나게 다르다. 그런데 경영자는 이 둘을 같은 것으로 착각하곤 한다.

개발을 잘하는 개발자는 관리는 전혀 하지 않고 개발에 몰두할 때 가장 높은 가치를 창출한다. 경영자의 착각 속에 개발자는 점점 잘 하지도 못하는 관리 일에 치중하게 된다. 자연스럽게 회사는 개발 파워를 잃게 된다. 그럼 남는 것은 정치적인 경쟁밖에 없게 된다. 불쌍한 개발자들이다.

이렇게 관리자화 된 개발자들은 이직도 곤란하게 된다. 동일한 분야가 아니라면 이직을 해도 회사에 도움이 별로 안된다. 다른 분야로 이직을 한다면 관리 능력이 중요한데 사실 관리는 전문 관리자보다 훨씬 못하기 때문이다. 이미 전문 개발자는 아니기 때문에 다른 분야에서 개발자로서 활약하기도 어렵다. 정말 어중간한 위치기 된다.

결국 그 회사에서 관리자의 길을 걷거나 선택할 옵션이 별로 없게 된다.

물론 개발자 본인이 스스로 이런 선택을 하지 않았지만 결국 이런 결과에 이르는 것이 우리나라 개발자들의 안타까운 현실이다.

개발자가 원하고 실력이 된다면 은퇴할 때까지 개발자의 경력이 보장되는 외국의 상황은 부러울 따름이다.

2008/12/03 - [개발조직] - 우리나라 소프트웨어 회사에는 Technical career path가 없다.

주변의 환경을 무시하고 스스로 개발자로 계속 살아남는 다면 대단한 결심이 필요할 것이다.

하지만 결국 이런 개발자들이 언젠가는 대우를 받을 수 있을 것이다. (당장은 글쎄 …)

그런 환경을 만들고 싶다.

이글은 Tech it!에 기고한 글입니다.

공유와 강제

소프트웨어 회사에서 꼭 필요한 개발문화 한가지를 꼽으라면 주저없이 "공유" 문화를 꼽는다.

"공유"의 문화야 말로 소프트웨어 회사를 가장 효율적으로 만들고 프로젝트를 효과적으로 진행할 수 있도록 하며 개발자들의 역량을 향상시키는 결정적인 문화이다.

"공유"의 문화가 잘 정착된 회사에서는 자연스럽게 문서화를 하며 시스템에 기록을 하고 소스코드에 주석을 남기고 필요한 리뷰를 진행한다.

하지만 공유의 문화가 부족한 회사에서는 자발적으로 공유의 활동이 잘 이루어지지 않는다.

물론 공유의 문화가 부족한 곳에서도 선도적인 개발자들이 공유의 문화를 정착하기 위해서 노력하고 있지만 역부족인 경우가 많다.

그 이유는 다른 개발자들의 협조를 이끌어내기가 어렵기 때문이다.

모든 사람이 다 공유를 하고 있는 상황이 아니라면 공유하는 사람만 손해를 보게 된다.

공유를 위해서 시간과 노력을 조금이라도 더 들였다. 하지만 공유를 하지 않는 사람들은 다른 사람이 공유한 결실은 얻으면서 자신의 것은 공유를 하지 않는다.

바빠서 그러기도 하고,

아직 습관이 안되서 그렇기도 하고,

귀찮아서 그러기도 하고,

공유하면 손해라고 생각하는 경우도 있다.

공유의 문화가 팽배한 회사는 서로 공유하는 것이 서로 이익이라고 몸으로 느끼고 있어서 자발적으로 자연스럽게 공유를 한다.

그럼 어떻게 공유의 문화를 정착할 수 있을까?

공유의 문화가 정착되기 전에는 회사의 규칙으로 강제화 해야 한다.

물론 너무 심하게 강제를 하면 반발하여 실패하기 쉽다.

너무 목표를 높게 잡아도 대부분 실패한다.

장기적인 계획을 하지고 단계적으로 시행해 나가야 한다.

첫번째가 이슈(버그)관리시스템을 적극적으로 사용하는 것이다. 모든 이슈와 버그는 시스템으로 모으고 최대한 메일과 전화를 줄이는 것이 그 시작이다.

두번째는 스펙을 작성하는 것이다. 스펙을 처음부터 제대로 쓰기는 어렵지만, 일단 프로젝트를 시작할 때 스펙문서를 작성하는 것을 규칙으로 두고 써보는 것이 좋다. 차츰 나아질 것이다.

세번쨰는 스펙을 리뷰하는 것이다. 스펙을 적고 리뷰를 해보면 그동안 얼마나 서로 모르고 프로젝트를 했다는 것이 조금씩 드러날 것이다.

이렇게 단계적으로 공유를 위한 제도를 강제로 적용하면 어느새 공유가 당연한 것으로 받아들여지는 때가 올것이다.

한국의 경영자들은 가짜 영웅을 원한다.

개발자들의 고충 중에는 다음과 같은 것이 이다.

"제대로 하고 싶은데 그러면 경영자의 눈에 들지 않는다"는 것이다.

스펙도 제대로 작성하고 리뷰도 하고 싶은데 경영자는 문서를 작성하고 있으면 노는 줄 알고 제대로 하는 것보다는 빨리하기를 원한다고 한다.

실제로 많은 경영자들이 Software 개발에 대한 이해 부족으로 회사에 진정으로 필요한 개발자가 어떠한 사람인지 잘 모른다. 그래서 진짜 영웅들이 가짜 영웅에 밀려서 대우를 못받는 경우가 많다.

그럼 회사에서 꼭 지켜야 하는 가짜 영웅과 회사를 좀먹는 가짜 영웅은 어떻게 다른지 알아보자.

가짜 영웅	진짜 영웅
말이 많고 잘 떠버린다.  자신만 믿으라고 한다.	묵묵히 일한다. 잘하는 것이 눈에 잘 안띈다.
첫번째 버전을 엄청나게 빨리 만들어 낸다.	합리적인 일정을 제시하고 차근차근 개발한다.
프로젝트 마무리를 잘 못한다. 다른 사람들이 마무리를 해준다.  잽싸게 다른 프로젝트로 넘어간다.	자신이 맡은 프로젝트는 책임감을 가지고 끝까지 마무리를 잘 한다.
회사의 규정을 잘 안지킨다. 자신은 특별대우를 받아야 한다고 주장한다. 회사의 규정외로 높은 대우를 받기를 원한다.	회사의 정책과 규칙을 잘 따른다.
자신이 그만두면 회사가 망하는 줄 안다.  또 그렇게 주장한다.  실제로 회사를 그만두면 회사가 휘청한다.	당장 퇴사를 해도 아무 문제가 없을 만큼 문서화도 잘하고 후배들도 잘 양성해 놓았다. 실제로 퇴사를 해도 회사가 문제 없이 돌아간다.
자신의 지식이나 자신이 개발한 제품의 정보에 대해서 타인과 공유를 잘 안한다.	공유를 잘 한다.  스펙 등 문서를 잘 작성하고 다른 개발자와 업무를 잘 나눠서 일한다. 타인, 특히 후배들이 작성한 문서나 코드 리뷰를 잘 한다.
유지보수 비용이 점점 더 많이 들어가는데 이는 유지보수 인력이 개발을 잘 못해서 그런 것이라고 주장한다.	유지보수에 비용과 시간이 별로 많이 안들어가도록 제품의 Architecture를 잘 만들어 놓았다.
회사의 미래를 위해서 이런 사람은 최대한 빨리 짤라 버려야 한다.  하지만 기존에 벌려 놓은 것이 많아서 당장 짜르기도 어렵다.	회사의 미래를 위해서 이런 사람은 높은 연봉을 주고라도 꼭 잡아야 한다.

회사에서 어떤 사람을 지킬 것인지 잘 생각해야 한다.

SW업계의 잘못된 통념 5가지

소프트웨어 업계에는 정말 깨기 어려운 잘못된 통념이 몇가지 있다.

많은 이들이 이러한 잘못된 고정관념과 오해에 사로 잡혀서 쉽게 변화하지 못하고 계속 잘못된 길을 걸어가고 있다.

어떠한 잘못된 통념이 있는지 알아보자.

잘못된 통념 1 : 문서(스펙)를 작성하느라고 일정을 못 맞추는 것이 아닌가? (경영자)

많은 경영자들은 문서 작성 때문에 프로젝트가 더 오래 걸리는 것으로 생각하고 있다. 그래서 개발자들이 문서를 쓰고 개발하겠다고 하면 오히려 문서를 쓰지 말고 빨리 개발해 달라고 은근히 요구하는 경영자가 의외로 많다. 

이러한 경우 경험에 의해서 문서란 개발과는 상관없이 추가적으로 시간을 잡아먹는 작업이라는 것을 학습했기 때문이다.

스펙을 써보지도 않고 일정이 모자르다는 것을 아는 것이 모순이다. 스펙이 부정확한 상황에서는 일정을 산정하는 것이 의미가 없기 때문이다. 하지만 대충 짐작으로도 턱없이 기간이 모자른 프로젝트도 있다.

진짜 스펙을 쓸 시간조차 없는 프로젝트라면 애초에 시작을 하지 않는 것이 좋다.

개발문서는 일정을 단축하기 위해서 작성하는 것이고, 그렇지 않은 목적을 가지고 있는 문서는 작성하지 않는 것이 좋다. 예외적으로 생명을 다루거나 우주선을 띄울 목적이라면 개발시간 단축외에 더 많은 것을 요구하기 때문에 시간이 더 오래 걸리는 문서도 작성하곤 한다.

하지만 대부분의 프로젝트에서는 개발 일정을 단축하는 문서만 작성해야 한다.

잘못된 통념 2 : 일정이 부족하니 당장 코딩부터 시작하자. (개발자)

진짜 개발자들 사이에서 만연해 있는 생각이다. 

개발자들은 위에서 촉박한 일정을 정해주기 때문에 무조건 일정을 맞춰야 하고 그러기 빨리 코딩을 시작해야 한다고 한다.

제대로된 스펙과 설계없이 코딩부터 시작한 프로젝트는 백이면 백 중간에 엄청난 재작업이 기다리고 있다. 통합에 막대한 시간이 소요되고 많은 버그를 생산하면 이를 고치는데 더 많은 시간이 소요된다.

코딩은 늦게 시작할수록 프로젝트가 빨리 끝나는 것이 맞다. 스펙과 설계가 충분할 수록 코딩 기간은 단축되고 일정이 부족하면 더 많은 개발자를 투입할 수도 있고 일부 기능을 미루는 것도 가능해진다.

잘못된 통념 3 : 지금은 잘 모르니 일단 개발해주면 보고나서 요구사항을 알려주겠다. (고객)

고객은 일단 개발해서 보여주면 아이디어가 마구 떠오르고 말만 하면 개발자가 바로바로 쉽게 고칠 수 있는 것으로 착각한다.

아키텍처에 영향을 주지 않는 사소한 것은 그럭저럭 바꿀 수 있어도 대부분의 기능은 고치거나 새로 추가하려면 처음부터 계획한 경우보다 몇배에서 몇십배의 비용과 시간이 들어간다.

하지만 고객이 스스로 원하는 것이 뭔지 잘 모르는 경우 개발자들은 상당한 어려움에 처하게 된다. 개발자들도 워낙 일상적으로 벌어지는 일이기에 불충분한 고객의 요구에도 자신이 아는 한도에서 대충 개발해주고 고치기를 반복하는 일을 정상적으로 받아들이곤 한다.

이렇게 개발이 이루어지만 아키텍처가 엉망이 되기가 일쑤이고, 개발자들은 재미 있는 개발을 하는 것이 아니라 회의만 들게 된다.

잘못된 통념 4 : 일정이 정해져 있어서 어쩔 수 없다. (개발자)

개발자들은 경영자들이 무리한 일정을 일방적으로 강요한다고 한다. 물론 그런 경우도 있지만 많은 경우 위에서 일방적으로 일정을 지시하지 않는다. 

표면적으로 드러난 결과가 일정 지시지만 그 과정을 살펴보면 합리적인 일정 산정과 조정이 이루어 지지 않는 경향이 있다.

개발자들이 제대로 스펙을 적어서 합리적인 일정을 제시하지 못하니 경영자도 일방적으로 도전적인 일정을 밀어 붙이고, 거꾸로 경영자가 그러하니 개발자들은 어쩔 수 없이 따르게 된다.

이는 어느 한쪽의 책임은 아니라고 볼 수 있다.

합리적으로 일정 산정을 하고 정확한 데이터를 제시할 때 경영자에게 일정에 대해서 어필할 수 있게 된다.

잘못된 통념 5 : 우리 회사는 달라서 일반적인 원칙이 적용되지 않는다. (경영자)

고객이 요구사항을 너무 자주 바꾼다. 

고객이 요청하면 당장 들어 줘야 한다. 

개발일정은 상상할 수 없을만큼 짧다.

고객이 요청하면 무조건 달려가야 한다. 

그래서 일방적인 소프트웨어 공학이 적용되지 않는다고 한다. 이것도 명백한 오해이다. 고객은 원래 그렇기 때문에 이러한 환경에서 빠른 시간에 적은 비용으로 개발하기 위해서 소프트웨어 공학이 존재하는 것이다.

우리만 그렇다고 생각하는 것도 오해이다. 많은 회사들이 정도는 다르지만 이러한 상황에 놓여 있고 많은 부분은 영업 전략으로 선택을 한 것 뿐이다.

이러한 잘못된 통념은 회사가 한단계 앞으로 나아가기 위한 변화를 방해하고 점점 열악하게 만드는데 일조한다.

개발자 100명을 더 투입한다면?

소프트웨어 회사에서 프로젝트를 진행할 때 흔히 벌어지는 문제가 "개발자가 부족해서 프로젝트가 늦어진다"는 것이다.

그럼 거꾸로 애플에서 날고 기는 개발자 100명을 투입시켜 줄테니 프로젝트를 제대로 끝낼 수 있냐고 물어보면 대부분 대답은 "글쎄요"다.

벽돌을 쌓거나 땅을 팔때는 사람을 2배 투입하면 대부분 시간이 반으로 줄어든다.

그런데 소프트웨어를 개발하는 프로젝트에서는 왜 그렇게 잘 안될까?

그 이유는 "스펙과 설계"에 있다.
빌딩을 세울 때는 설계가 명확하게 있다. 이 세상에 설계 없이 만드는 빌딩은 없을 것이다. 그리고 협업이 가능하도록 일이 세분화 되어 있고 전문화 되어 있다.

그런데 유독 소프트웨어(특히 우리나라)에서는 스펙과 설계가 땅파고 벽돌 쌓는 것보다 시원찮다. 그런 상태에서 개발을 하다보니 건설현장에서 빌딩 올라가듯이 개발이 되는 것이 아니고 뒤죽박죽이 된다. 이런 환경에 익숙해진 개발자는 뭐가 문제인지 인지하지 못하는 경우가 대부분이다.

스펙과 설계가 제대로 작성되어야 협업이 가능하다. 

여기서 핵심은 컴포넌트다. 컴포넌트가 일을 깔끔하게 나눠서 일할 수 있을 만큼 깨끗하게 나눠져 있어야 한다. 그래서 부서별, 개발자별로 일을 나눠서 할 수 있고 서로 인터페이스 맞추느라고 시간을 허비하지 않는다. 


스펙과 설계가 제대로 되지 않은 상태에서 개발을 하면 컴포넌트 단위로 일을 나눠서 할 수 없기 때문에 "화면"단위로 일을 나눠서 하기도 하고, 적당히 일을 나눠서 하다가 서로 겹치기도 하고 나중에 통합에 엄청난 시간이 걸리게 된다. 또한 어떻게 소프트웨어가 동작은 한다고 하더라도 그 아키텍처는 뒤죽박죽이 되어서 나중에 유지보수도 엄청나게 어렵게 된다.

그럼 스펙/설계 단계에서 어느 정도까지 설계가 이루어져야 할까?

대답은 의외로 간단하다.  스펙/설계의 결과를 가지고 소프트웨어 개발자들이 충분히 구현을 할 수 있을 정도면 된다. 여기서 "충분히"라는 단어는 몹시 애매하다.

문서만 보고 서로 전혀 대화를 하지 않고도 구현을 할 수 있으면 너무 자세히 적은 것이다. 이렇게 자세히 적으면 시간 낭비이고, 개발자에게 너무 자유도를 없앤 것이다. 

그럼 "충분히"는 어느 정도 일까?  개발자가 설계대로 구현을 하면서 약 5% 정도의 내용은 설계자나 관련된 컴포넌트 개발자와 서로 의논하면서 개발할 수 있을 정도면 적당하다고 할 수 있다. 너무 많은 내용을 의논하면서 구현시 결정해야 한다면 적은 내용이 너무 부족한 것이다. 따라서 "충분히"는 상황에 따라 다른 것이다.

설계가 부족하다면 프로젝트리더(테크니컬리더)는 여러 개발자에게 설명하느라고 시간을 보내고 자신이 담당한 개발을 할 시간이 부족해지고, 개발자들에게 설명을 소홀히 하면 개발자들이 제 멋대로 개발을 해와서 문제가 생기곤 한다. 나중에 이를 고치느라고 시간이 몇배로 낭비된다.

설계는 스펙을 작성할 때부터 시작이 되고 설계 단계에서는 컴포넌트가 다 구분되고 인터페이스가 정의가 되어서 소스코드 상에 모두 적히고 컴파일이 가능하도록 해야 한다.

그러기 위해서는 파일이름, Class이름, Public 함수 이름과 parameter, return값이 모두 정해져야 한다. 그리고 그 설명을 문서에 다는 것은 중복이기 때문에 Doxygen이나 Javadoc을 이용해서 소스코드에 주석으로 설명을 하면 효율적으로 설계 정보를 관리할 수 있다.

이렇게 설계가 완료되면 바로 Daily Build가 가능하며 구현 첫날부터 개발자들은 빌드가 가능한 소스코드에 자신이 맡은 컴포넌트의 내용을 채워나가면 되는 것이다. 즉, 첫날부터 이미 통합이 된 상태에서 개발을 하는 것이다.

이렇게 스펙과 설계를 작성하면 일정 산정의 정확도도 훨씬 올라가고 개발자를 더 투입하더라도 도움이 된다. 또한 외주로 개발하는 것도 가능하다.

물론 외주를 줄 경우에는 "설계"도 외주를 주는 경우가 많으므로 이런 경우는 "스펙"까지를 제대로 작성하면 된다.

이렇게 일을 효과적으로 나눠서 할 수 없다면 스펙/설계를 제대로 작성한 것이 아니다. 개발 시간과 비용도 줄일 수 있다. 가장 중요한 것은 프로젝트가 관리 가능한 상태가 된다는 것이다. 일정과 비용이 상당히 정확하게 예측 가능해지고 일정이 지연 상태를 빠르게 파악할 수 있고 대처를 할 수 있다.  스펙과 설계를 제대로 작성할 수 없다면 온갖 프로젝트 관리 기법은 다 소용없다. 결국 야근 밖에 남지 않는다.

"일을 나눠서 할 수 있다."는 것은 결국 개발자가 행복하게 일할 수 있도록 해준다.

SW개발자의 미래

개발이 좋아서 SW개발자가 된 사람들이 한 5~7년 개발을 하다보면 흔히 미래에 대해서 생각하게 되고 불확실한 미래를 불안해하곤 한다.

특히 대부분의 회사에서 개발자의 Career를 보장해주지 않기 때문에 막연히 팀장이 되기도 하고 다른 직종으로 옮기기도 한다.

그러다보니 전문성있고 가치가 높은 개발자의 경험과 지식이 묻혀버리기 일쑤이고 회사는 기술력이 축적되지 못하게 된다.

개발자의 Career Path 상에는 어떠한 직종들이 있는지 알아보자. 자신의 역량과 성향에 따라서 Path를 정하면 좋을 것이다. 물론 회사에서 그리고 사회 전체적으로 개발자의 Career Path를 보장해 주는 방향으로 변하면 좋겠다.

Senior Engineer, Chief Scientist

한마디로 고참개발자이다. 신참때는 주로 코딩을 많이 하고 버그를 잡았으면 이제는 분석, 설계에 더 많은 시간을 소비하고 Peer Review에 많이 참석한다. 

자신의 팀의 프로젝트만 관심을 가지는 것이 아니고 다른 팀의 프로젝트 리뷰에도 참석하여 기여를 한다.

흔히 Architect라고 불리기도 하고 여전히 코딩도 한다. 

외국에서는 60세가 넘는 Software엔지니어를 볼 수 있기도 하다. 

제대로 된 엔지니어라면 Domain과 상관없이 어느 분야로든지 이직이 가능하다.

CTO

회사의 최고 기술 책임자이며 많은 개발자들의 Role model이다.

회사의 경영에 관여를 하지만 관리는 하지 않는다.

장기기술전략, 실행전략, 아키텍처, 구현, 인프라구조 정립, 프로세스 등 개발에 관하여 기술적인 것이라면 모두 책임진다.

왕년에 코딩을 했다는 것으로는 CTO가 될 수 없다. CTO라면 현재도 코딩을 할 수 있어야 한다. 바쁘고 코딩의 Value가 낮기 때문에 안하는 것 뿐이지 분석/설계/코딩을 현재도 모두 할 수 있어야 한다.

소프트웨어 회사의 최고봉이라고 할 수 있다.

SCM, Build and Release Engineer

소프트웨어 회사에는 몇가지 전문적인 분야가 있다. 형상관리, 빌드, 릴리즈, 팩키징 등이 그것이다. 처음에는 개발자들이 개발과 더불어 이런 업무도 같이 수행하지만 회사가 커지면 전문적인 업무로 떨어져 나온다. 몇명이 전담을 해도 될만큼 충분히 일이 많고 취미로 해도 될만큼 일이 쉬운 것이 안다. 또한 개발 능력도 필요하다.

대단히 전문적인 업무이고 이러한 개발외의 환경이 잘 되어 있어야 개발자들이 개발에 집중할 수 있고 업무 효율이 오르게 된다.

개발자 중에는 프로젝트보다 이러한 전문적이고 SW공학적인 업무에 관심을 가지는 사람들이 있다. 이 영역에서 실력을 닦으면 이직시에도 이 전문성을 활용할 수가 있다.

Technical Marketer

제품을 기획할때는 비즈니스적인 요소, 기술적인 요소가 모두 고려된다. 그중에서 기술적인 부분은 일반 기획자들이 속속들이 알기가 어렵다. 따라서 기술을 아주 잘아는 테크니컬 마케터가 기술적인 부분을 담당하게 된다. 경쟁사의 제품을 분석할 때도 단순히 기능이 되는지 O, X만 체크 하는 것이 아니고 기술적인 부분까지 검토를 해서 적용된 기술도 파악할 수 있다. 

새로 기획하는 제품의 기술적인 비전을 수립하고 마케팅과 개발자의 연결고리 역할도 수행한다.

Technical Supporter

개발자 중에는 진득히 않아서 개발하는 것을 좀 쑤셔하고 싫어하는 사람들이 있다. 여러 경쟁 제품을 써보기를 좋아하고 새로운 제품이 나오면 먼저 써보려고 하고 동료들의 시스템에 문제가 생기면 누구보다 빠르게 해결해 주는 능력을 가지고 있다.

이런 경우 개발 경력과 지식을 활용하여 기술지원업무를 수행할 수 있다. 회사의 제품에 대해서 기술적으로는 누구보다 속속들이 잘 알기 때문에 수준 높은 지원도 가능하다.

외향적인 사람들에게 어울리는 직종이다.

QA Engineer/Manager

개발자 출신으로 QA 엔지니어나 관리자가 될 수 있고 개발 능력을 활용하여 테스트 관련 툴을 개발할 수 있다. 

개발 경험이 있는 것은 장점으로 작용하면 계획적인 삶을 살 수 있는 장점도 있다. 물론 우리나라에서는 똑같이 무지막지한 야근을 해야 하는 경우가 많다.

Project Manager

기술자 트랙과 관리자 트랙의 중간쯤 되는 포지션이다. 프로젝트를 책임지고 맡아서 관리하는 역할로서 General Manager가 되는 중간 과정이 될 수도 있다. 

General Manager

기술과는 관련이 없는 일반 관리자다. 기술에서는 손을 떼는 것이다. 우리나라의 개발팀장과는 또 다르다. 개발팀장이 오래되서 더이상 개발을 하지 않고 관리를 하면 General Manager라고 볼 수 있다.

기술적인 결정은 하지 않는다. 하지만 과거에 개발 좀 해 봤다고 기술적인 결정을 자기가 해버리면 월권이라고 할 수 있다.

일단 일반 관리자로 넘어오면 다시 엔지니어로 돌아가는 것은 불가능 하다. VP Engineering으로 성장하는 Track이다.

VP Engineering

우리말로는 "기술부사장", "연구소장" 정도가 되겠다. CTO와는 완전히 다르다. CTO는 관리를 하지 않지만 VP Engineering은 관리자다. 개발관리 총책임자 쯤 된다. 개발자나 CTO가 하는 기술적인 얘기의 용어들을 거의 알고 있고 개발프로세스가 어떻게 돌아가는지도 잘 안다.

하지만 기술적인 결정을 하지는 않고 관리만 한다.

우리나라에서는 흔히 VP Engineering을 CTO라고 불러서 오해를 하는 경우가 많다.

Domain Expert

소프트웨어 개발 역량보다는 업무 지식에 치중하는 사람들이다. 증권사, 은행, 회계, 토목, 건설, 기계, 예술 분야의 소프트웨어를 개발하려면 해당 영역의 지식과 경험이 많이 필요하고 소프트웨어 기술도 어느 정도 알아야 한다. 개발 경험을 가지고 해당 산업 지식을 쌓으면 도메인 전문가가 될 수 있고, 이 경우 해당 분야로만 이직이 가능하다.

Restaurant Owner

소프트웨어 개발에 염증을 느끼거나 비전을 찾지 못하면 소프트웨어 업계를 완전히 떠나는 것도 한 방법이다.