내인생 최고의 멘토를 만나다.

소프트웨어를 개발하면서 또, 컨설팅을 하면서 하고 싶었던 얘기를 해보자고 블로그를 시작한지가 벌써 4년이 되었다. 3천명이 넘는 구독자와 많은 분들이 글을 읽어 주셨다. 최근에는 Tech it에 칼럼을 기고하기 시작해서 좀더 많은 분들이 글을 읽게 되었다. 

내 글을 읽는 분들의 반응은 무척 다양하다. 꾸준히 읽고 호응하는 댓글을 계속 남기시는 분들 중에는 기억에 남는 분도 많다. 댓글은 없어도 꾸준히 읽고 계신 분들도 있고 물론 호응하지 않는 분들도 있을 것이다. 가끔은 반대의견을 제시하는 분들도 있다. 그런 모든 분들이 소중하지만 가끔은 제 글에 대해 "컨설턴트의 말빨이다.", "현실을 모른다", "실제 개발 경험은 있는 것일까?"라는 종류의 의구심을 가진 분들이 있다. 내 글들이 워낙 직설적이라서 가끔은 오해와 충돌을 불러 일으킨다. 물론 어느 누구도 모든 사람을 이해시킬 수는 없지만 오늘은 나에 대해서 조금 설명해보고자 한다. 나에 대한 이해가 내 글을 약간이나마 더 이해하는데 도움이 되길 바란다.

나는 여러분들과 같은 대한민국 개발자이다. 블로그에서 하지 말라고 하는 거의 모든 것을 다 해봤고 문제점도 직접 다 겪어본 개발자다. 대한민국 보통의 개발자와 크게 다르지 않았다. 

18년 전 첫직장은 운좋게 그당시 우리나라 최고의 Software회사였던 한글과컴퓨터였다. 우리나라에서 둘째가라면 서러워할 최고의 개발자들과 같이 일했고, 나또한 코딩을 정말 잘했다. 그때 Daily build라는 것도 배우고 소스코드관리 등 소프트웨어 회사가 기본적으로 갖춰야 할 것을 잘 배웠다. 이런 좋은 환경에서 최고의 개발자들과 같이 일할 수 있었던 것은 내게 큰 행운이었다.

그리고 스타트업컴퍼니에서 일해도 보고 직접 회사도 해보면서 내 블로그에서 문제점이라고 지적하고 있는 것의 대부분은 해본 것 같다. 그래서 많은 개발자들이 왜 그런 문제점에 빠져드는지 정말 잘 알고 있다. 그당시도 나름대로 기반시스템이나 스펙, 설계 등에 노력을 했지만 항상 풀리지 않은 수수께끼와 같았다. 인터넷을 뒤지고 책을 봐도 해결되지 않았다.

그러다가 안철수연구소에 입사하고 그당시 CTO로 계시던 김익환 부사장님을 만나면서 나의 개발자로서의 인생이 바뀌었다고 볼 수 있다. 김익환 부사장님은 미국 스탠포드에서 소프트웨어를 공부하고 20년간 GE, 선마이크로시스템즈 등에서 소프트웨어를 개발하셨다. 그래서 오랫동안 해결되지 않았던 수수께끼들이 해결되기 시작했다. 안철수연구소의 동료 개발자들과 같이 실리콘밸리의 개발문화도 배우고, 스펙/설계 작성하는 방법도 배우고 개발 프로세스도 제대로 배워 나갔다. 

지금 생각해보면 내가 그때 안철수연구소를 가지 않았더라면 대부분의 개발자들과 같이 지금도 수많은 문제를 안고 비효율적으로 힘들게 개발을 하고 있을 것이다. 지금도 김익환 사장님(현재)과 10년째 같이 일하면서 계속 배우고 어제와 또 다른 내가 되어가고 있다.

나는 현재 컨설턴트이지만 지금도 개발을 계속 하고 있는 실전 소프트웨어 개발자이다. 내 글들의 대부분은 나의 개발과 컨설팅 경험에서 나오는 것이고 또 상당분분은 김익환사장님의 말씀에서 영감을 얻어서 작성한다. 그냥 말만 앞세운 공허한 소리는 아니다.

블로그의 글들이 한번 생각해보는 계기를 만들 수는 있다. 하지만 글만 보고 배울 수는 없다. 문제를 인식할 수는 있지만 방법을 알수는 없다는 얘기이다. 내가 최고의 멘토를 만났듯이 여러분들도 좋은 멘토를 만나기를 바란다. 결코 혼자서는 제대로 배울 수가 없다. 물론 내가 여러분들의 멘토가 될 수 있다면 정말 기쁜일일 것이다. 그것이 블로그의 가장 중요한 목적이다. 주변에 멘토가 없다면 찾아 나서야 한다.

블로그에 댓글로 독자들과 약간의 소통을 하지만 나에게 직접 메일을 보내도 언제든지 환영한다. 블로그 글을 읽는 것만으로 해결되지 않는 궁금증은 블로그 상단에 메일보내기 버튼을 눌러서 내게 메일을 보내면 된다. ^^

7명이 할 수 있는 일을 70명이 하고 있는 이유

최근에 한 글로벌 소프트웨어 회사(Y사, 가칭)의 한국 지사 관계자에게 들은 이야기이다.

비단 Y사 얘기만은 아니다. 세계적인 소프트웨어 회사의 한국지사에서 종종 벌이지는 일이다.

Y사의 본사에서는 처음에 한국지사를 만들었을 때 한국에서도 미국의 개발 프로세스를 따를 것을 종용했다고 한다. 하지만 한국에서 채용된 개발자들은 미국의 개발 프로세스는 너무 무겁다고 한국 방식으로 개발했다고 주장을 했다. 그리고는 미국의 개발 주문에 대해서 믿을 수 없는 속도로 해결을 해나가기 시작했고, 미국 본사는 이런 경이로운 결과를 보고는 한국식 개발을 묵인할 수 밖에 없었다.

그뒤 몇 년이 지난 지금은 어떻게 되었을까? 미국 본사의 개발 프로세스를 착실히 따른 호주 지사와 엄청난 차이를 보이고 있다고 한다. 똑같은 일을 호주 지사에서는 7명이 처리를 하고 있고 한국 지사에서는 70명이 야근까지 해야 간신히 처리를 하고 있다고 한다. 

그렇게 된 이유가 분석/설계도 없이 빨리빨리 개발을 하다보니 아키텍처가 엉망이고 개발자들이 많이 바뀌었는데 내용을 아는 사람도 별로 없다고 한다. 뭐 하나 고치려고 해도 보통 어려운 것이 아니라고 한다.

전해 들은 얘기라서 과장이 있다고 해도 문제가 심각하고 이미 많이 망쳐 놓은 것은 사실이다.

글로벌 소프트웨어 회사라고 하더라도 한국에 와서 착각하는 것들이 있다. 놀라운 속도를 보여주는 한국식 개발방식을 신기해 하지만 그 문제점을 피부로 심각하게 알지 못한다.  스펙도 제대로 작성하지 않고 분석/설계/구현을 섞어서 빠르게 개발하는 것이 신기해 하지만 얼마나 큰 문제가 있는지 실리콘밸리 회사들도 잘 모른다. 그런 식으로 개발해 본적이 없기 때문이다.

그렇다고 글로벌 소프트웨어 회사가 본사의 개발 프로세스를 강제화 한다고 잘 적용되는 것은 아니다. 한국에서 잔뼈가 굵은 개발자들은 몸에 밴 개발 방식 때문에 적응하기가 매우 어렵다. 차라리 신입사원들을 뽑아서 교육시키면서 개발을 하는 것이 더 빠를지도 모른다.

이는 한국의 소프트웨어 회사 내부에서도 그대로 적용된다. 글로벌 소프트웨어 회사의 개발 프로세스가 아무리 좋다고 하더라도 한국의 소프트웨어 회사에는 바로 적용이 안된다. 대부분은 무리한 시도이고 실패한다.

변화를 감당할 수 있을만큼씩 조금씩 바꿔나가야 한다.

일을 잘하는 조직 vs. 못하는 조직

일 잘하는 조직	일을 잘 못하는 조직
겉에서 보기에 여유있게 일한다.	항상 부산하고 바쁘다.
위임이 잘 되어 있어서 알아서 처리하는 업무가 많다.	사소한 이슈도 모두 보고하고 처리를 해야 한다.
효과적인 업무 프로세스가 있다.	프로세스가 없거나 비효율적이다.
꼭 필요한 이슈만 모여서 회의를 한다.	모든 결정을 회의를 통해서 결정해야 한다.
회의 시간이 짧고 회의도 적다.	회의가 너무 많아서 일할 시간이 없다.
회의 Agenda에 집중하여 효율적으로 결정한다.	회의 시간은 길지만 결론이 없다.
회의 후 항상 회의록을 기록하고 후속처리가 잘된다.	회의 후에도 후속처리에 대한 관리가 잘 안된다.
커뮤니케이션 시스템이 잘 구축되어 있다.	구두와 메일에 의존한 커뮤니케이션으로 관리가 안된다.
시스템을 통해서 누가 무슨 일을 하는지 다 알 수 있다.	누가 무슨 일을 하는지 파악이 잘 안된다.
필요한 정보에 신속하게 접근할 수 있다.	어디에 무슨 정보가 있는지 파악이 잘 안된다.
업무가 효율적으로 분배되어 있다.	바쁜 사람만 바쁘고 노는 사람은 논다.
꼭 필요한 문서를 효율적으로 만들어서 공유한다.	문서가 없는 경우 많고, 있어도 잘 안본다.

일 잘하는 조직의 특징을 요약하면, 합리적이고 명시적인 프로세스가 있고 적절한 시스템을 도입하고 있으며 회의를 효과적으로 진행하고 적절한 문서를 통해서 업무를 진행한다. 이렇듯 효과적으로 일하는 조직은 의욕만으로 되는 것은 아니고 회사에서 제공해야 할 것이 상당히 많다. 즉, 투자가 필요하다.

해외 진출하는 족족 실패하는 이유

대한민국 이름을 걸고 해외에서 크게 성공한 Software가 없는 것은 안타까운 일이 아닐 수 없다. 내가 아는 한 그런 Software가 없다. 그런 Software가 있다면 알려주기 바란다.

게임 등 일부 분야에서는 성공 사례가 있지만 일부 특수 분야의 일이다.

그렇게 실패하는 이유는 여러가지가 있겠지만 내가 보는 가장 큰 이유는 소프트웨어를 개발하는 기초 역량이 부족해서이다.

누구는 해외 문화를 이해하지 못했다고 하기도 하고, 영업을 잘 못했다고도 하지만 가장 큰 이유는 개발 역량의 차이이다.

국내에서 개발했던 주먹구구의 방식이 해외에서도 그대로 먹힐 것이라고 생각하는 것은 큰 착각이다.

국내에서 성공했던 대부분의 회사들의 성공요인은 국내에서만 먹히는 서비스 전략 때문이었다. 대충 만들어 놓고 고객이 불만을 표시하면 무한 감동 서비스를 제공하는 것이 그것이다. 많은 회사들이 이 전략을 사용해서 국내에서는 성공을 했다.

작은 땅덩어리에서는 고객이 부르면 언제든지 달려갈 수 있지만, 시장이 세계로 넓어지면 그런 고객 감동 서비스는 꿈도 꿀 수 없는 일이 된다. 고객이 부르면 비행기 타고 날아가고 호텔에서 숙박을 해야 하기 때문에 비용과 시간이 너무 많이 들어간다.

해외에서 성공하려면 진짜로 제대로 개발을 해야 한다. 고객이 해달라는대로 개발하는 것이 아니고 제대로 전략을 세워서 제품 기획을 하고 분석/설계를 해서 개발을 해야 한다. 또, i18n Technology(국제화 기술)도 제대로 적용해야 하는데 99%의 회사는 나름대로 방식으로 또 엉터리를 만들어서 적용하기 때문에 해외에서 대패를 하게 된다.

이런 것을 모두 갖추어야 비로소 비슷한 출발선상에서 경쟁을 시작하는 것인데, 국내에서 하던 방법대로 해외서 성공하려고 하는 것은 100m 달리기에서 20~30m 뒤에서 출발하는 것과 다를 바가 없다.

근본적인 역량을 되돌아볼 때이다.

소프트웨어 개발자의 나아갈 길

소프트웨어 개발자의 경력이 제대로 보장 받지 못하는 가장 큰 이유는 회사, 사회, 문화의 문제 때문이다. 그렇다고 개발자 된 입장에서 회사가 바뀌고 사회가 바뀌기만을 기다릴 수는 없다. 이는 마치 닭과 달걀의 관계처럼 누가 먼저인지 알기 어렵다. 어느 한쪽이 먼저 깨끗하게 해결되면 자연스럽게 전체가 해결되지만 그걸 기대하기는 현실적으로 어렵다. 경영자도 회사가 살아남고 경쟁력을 키우기 위해서는 바뀌어야 하지만 개발자도 뭔가 대책을 수립해야 한다.

주변에 좋은 롤모델이 없는 개발자들은 자신의 개발자로서의 경력을 보장 받고 더 뛰어난 개발자가 되기 위해서 어떻게 해야 하는지 알아내기가 정말 어렵다. 그냥 상황이 주어진 대로 열심히 할 뿐이다. 그러다 보면 정치적으로 밀리고 실력에서도 뒤쳐져서 최악의 상황이 되곤 한다. 단지 열심히 밤새워 일했을 뿐이데 결과는 그리 좋지 않고 미래는 더움 암울하다.

그렇다면 쉽지 않은 일이지만 개발자가 어떻게 해야 하는지 알아보자. 물론, 소프트웨어 개발자의 종류가 너무 많고 OS Kernel 개발자 등 특수분야의 개발자들은 특성이 매우 독특해서 여기에 해당이 되지 않을 수도 있지만, 대부분의 개발자에게는 해당하는 얘기일 것이다.

첫째, 관리와 개발 일을 분리하라.

관리자가 될 것이 아니라면 관리 일은 아무리 열심히 해도 개발자 경력에 별 도움이 안된다. 하지만 회사의 사정상 싫어도 관리 일을 떠맡을 수 밖에 없는 경우가 있다. 그런 경우에도 본인의 정체성을 명확히 해야 한다. 개발과 관리 일을 섞어서 하지 말고 구분해야 한다. 즉, 자신이 하고 있는 일 중에서 어떤 일이 관리고 어떤 일이 개발인지를 구분해야 한다. 물론 모호한 경우도 있다. 여기서 개발이 주업이고 관리는 부업임을 명확히 해야 하고, 언제든지 관리 일은 버릴 수 있도록 준비를 해야 한다.

경영자에게도 개발자가 관리일 때문에 부담이 되고 효과적이지 않다는 것을 알려라. 많은 경영자들이 그 사실을 잘 모르고 있기 때문에 자주 세뇌를 시켜야 한다. 그럼으로써 관리 일은 점점 최소화를 시켜나가야 한다.

보고서 작성, 경영회의 참석, 팀원 관리, 일정관리, 고객 접점 업무 등은 거의 관리 일이므로 최소화 노력을 해야 한다.

둘째, 경력과 수준에 맞는 일을 해라.

경력이 많아지면 그게 걸맞는 수준의 일들을 해야 한다. 경력이 늘어가도 똑같은 일을 그저 더 빠르고 능숙하게 하고 있다면 밥값을 못하고 있을 가능성이 높다. 그런 상태라면 개발자 경력을 오래 보장 받기는 어렵다. 결국 도태될 것이다.

경력이 늘어갈수록 누구나 할 수 있는 일들은 후배에게 물려 주어야 한다. 그리고는 설계, 분석 업무의 비중을 높이고 회사의 기술 전략에 신경을 써야 한다. 경력이 더욱 늘어갈수록 자신의 팀 뿐만 아니라 타팀, 더 나아가서 회사 전체의 프로젝트에 기여를 해야 한다.

그러기 위해서 문서화는 필수다. 개발 내용이 문서로 적혀 있어야 서로 리뷰가 가능하고 타팀의 프로젝트도 검토를 해서 나의 전문지식을 불어 넣을 수가 있다. 물론 내 프로젝트도 문서화를 해야 다른 사람들의 도움을 받을 수 있다. 문서화 되지 않은 내용은 뇌를 꺼내서 리뷰할 수는 없다. 아무리 빨리 개발한다고 해도 리뷰 없이 개발되는 프로젝트는 주먹구구로 개발이 되는 것이고 아주 작은 프로젝트이거나 아주 재수가 좋은 경우를 빼고는 폭탄을 안고 있는 것과 같다. 이런 주먹구구식 개발은 대부분 첫번째 프로젝트부터 더 오래 걸리고, 시간이 지날수록 점점 비효율적으로 된다.

그런 주먹구구 환경에서는 개발자가 경력에 맞는 수준의 일을 할 수 없다.

셋째, 권력욕을 버려라.

상황에 따라서 매우 어려울 수 있다. 특히 대기업인 경우 더욱 그렇다. 조직에서 권력을 얻어야 제대로 대우를 받을 수 있다면 이를 뿌리치기는 어렵다. 이런 경우는 차라리 개발자로서의 경력은 포기하는 것이 나은 판단일지도 모른다. 개발자로서 계속 나아가겠다고 결심을 했다면 어쨌든 권력욕은 버려야 한다. 권력을 얻기 위한 거의 모든 행동은 개발 일과는 거의 관계가 없다. 방해만 될 뿐이다.

개발자는 권력보다는 뛰어난 기술력에서 자연스럽게 나오는 파워를 가져야 한다. 물론 조직 문화가 이를 받아들이지 않는 경우도 많이 봐왔기 때문에 쉽지 않은 일임을 잘 알고 있다. 그렇다고 권력을 쫓아서는 개발자의 길과는 멀어질 것이다.

넷째, 끊임 없이 코딩하라.

개발자는 30년을 일해도 감독, 코치가 아니라 선수다. 코딩에서 손을 놓으면 급속도로 개발자의 길과 멀어진다. 주변을 보면 관리나 좀 하고 코딩은 전혀 안하면서 여기저기 감 놔라 대추 놔라 훈수를 두는 무늬만 개발자가 매우 많다. 이들은 개발자가 아니고 개발자였을 때 쌓아 놓은 지식의 약발도 별로 오래 가지 않는다.

물론 경력이 늘어 갈수록 코딩 시간은 줄어들 것이다. 하지만 여전히 코딩은 계속 해야 한다.

다섯째, 새로운 기술을 익혀라.

개발자라면 좋아하는 기술 몇 가지만 평생 써먹기 어렵다. 꾸준히 새로운 기술을 익혀야 한다. 시간이 흐를수록 점점 더 많은 새로운 기술들이 나오고 있다. 이를 따라잡기는 보통 어려운 일이 아니다. 그래서 개발자들이 다른데 신경 쓸 시간이 어디 있겠는가? 그렇다고 모든 새로운 기술을 익히는 것은 불가능하다.

어떤 기술은 용어 정도만 익히기 위해서 10분 정도 투자를 하고, 어떤 기술은 1시간 정도 투자를 해서 뭔지 돌려봐야 하는 것도 있다. 또 어떤 기술은 하루를 투자해서 샘플을 만들어 봐야 하는 기술도 있다. 이를 잘 구분해서 적절하게 시간 투자를 해야 한다. 모든 기술을 다 마스터 할 필요는 없다. 나중에 필요할 때 언제든지 생각이 나게 하면 된다. 필요할 때 필요한 만큼 더 익히면 된다.

오랫동안 써왔던 기술만 고집하면 한계에 다다른다.

여섯째, 소프트웨어 개발 전문가로 포지셔닝을 하라.

본인의 정체성을 명확히 하라. 경영자가 본인을 소프트웨어 전문가로 믿도록 하라. 경영자가 기술 전략을 같이 의논하게 하고 기술 관련된 정책을 제대로 수립할 수 있도록 보좌하라. 만능인 것처럼 행세하는 것은 효과적이지도 않고 신뢰도 떨어진다. 개발이 아닌 일은 다른 사람들이 더 잘할 수 있다. 고객도 잘 알고, 영업도 알고, 전략도 잘 안다고 아무리 아는척 해봤자 밑천이 금방 드러난다. 제일 잘하는 개발로 승부를 하라. 이는 회사 내에서 누구도 넘보지 못한다.

애매한 만능맨보다는 개발 전문가의 위치가 회사 내에서 더욱 확고할 것이다. 구조 조정 시에도 관리자나 애매한 위치의 사람들은 자를 수 있어도 개발 전문가로 잘 포지셔닝하면 쉽게 자를 수 없다. 물론 제대로 생각이 박힌 경영자가 있는 경우에 그렇다.

일곱째, 후배들의 롤모델이 되어라.

세상은 결국 돌고 도는 것이다. 본인에게는 롤모델이 없어서 고생을 많이 했을 것이다. 하지만 후배들에게는 롤모델이 되어서 후배들이 그 고생을 하지 않도록 하라. 더 많은 시행착오를 겪겠지만 이는 선구자이기 때문이다. 선임 개발자가 어떤 식으로 일하는지 보여주고 기술력에서 오는 파워를 보여줘라. 이는 본인을 위해서도 더 일하기 좋은 개발환경을 만드는데 도움이 되는 일이다.

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

개발자의 취향

소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다.

이 경우 Architecture상의 심각한 문제점을 내포하게 된다.

제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다.

Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 

이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.

그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에 심각한 문제를 초래하기도 한다.

그럼 어떻게 하면 이런 잘못된 결정을 막을 수 있을까? 답은 의외로 간단하다. 분석을 제대로 하는 것이다. 제대로된 스펙문서에는 최종 결론 뿐만 아니라 그런 결정에 이르게 된 근거와 의논 과정도 적어야 한다. 그래야 스펙을 읽는 사람들이 의문가 이의를 제기하지 않는다.

예를 들면 다음과 같은 것들이 있다.

• 현재는 Windows만 지원하지만 3년안에 Mac을 지원할 가능성이 90%라서 엔진은 ANSI-C로 개발을 하고 UI를 QT Framework를 이용한다.
• Java와 C로 모두 개발이 가능하고, 프로젝트 리더가 C언어를 더 좋아하지만, 기존 제품들이  Java로 되어 있고 회사에 Java개발자가 대부분이므로 Java를 선택한다.
• 회사에 자연어 처리 전문가가 있지만 자연어 처리 엔진의 직접 개발 비용과 상용라이브러리를 구매했을 때를 비교했다. 10년 후까지의 유지보수 비용을 고려하여 자체 개발보다는 상용라이브러리 구매를 선택했다.
• 현재 프로젝트는 아이폰/아이패드 용으로만 계획을 세웠지만, 영업부서와 논의결과 안드로이드를 지원할 가능성이 있어서 제품의 난이도가 그렇게 높지 않아서 Adobe Air를 사용하기로 했다.

이러한 결정 과정은 프로젝트를 진행하면 수십가지 또는 수백 번 진행이 된다. 스펙문서에는 이러한 결정과정까지 적어야 정확한 내용이 된다. 또한 중간에 상황이 변경되면 신속하게 영향평가를 할 수 있고 스펙을 변경할 수 있다.

소프트웨어 프로젝트는 개발자의 취향대로 진행되는 것이고 합리적인 근거를 바탕으로한 Architecture 결정에 따라 진행되어야 한다.

허울뿐인 소프트웨어 개발자 경력 보장

과거 필자가 근무했던 회사에서는 “백발을 휘날리며 개발을 할 수 있는 개발자”를 공개 채용한 적이 있다. 그 당시 수많은 경력직 개발자들이 지원을 했고 개발자로서 경력을 보장받고자 하는 열망을 충분히 알 수 있었다. 필자의 회사는 Technical career path를 확실하게 보장을 하고 있었다. 따라서 관리를 하지 않고 개발자로서 꾸준히 성장할 수 있고 그렇게 성장할 수 있도록 기업 문화와 제도가 뒷받침이 되어 있었다. 또한 대우도 관리자에 절대 뒤지지 않았다.

하지만 필자가 컨설팅을 시작한 이후 접한 수많은 회사들 중에서 제대로 개발자 경력을 보장해주는 곳은 없었다. 가장 큰 이유는 경영자의 이해 부족을 꼽을 수 있다. 개발자 경력 보장에 대한 각 기업들의 현황을 먼저 살펴보면 해결책도 보일 것이다.

우선 대기업 쪽을 살펴보자.

성공한 국내 유수의 대기업들은 HR에 대해서 많은 투자가 이루어지고 있다. 따라서 Career path에 대한 명확한 정책이 존재한다. 하지만 그 속을 들여다보면 문제가 매우 많다.

문제 사례 중 가장 흔한 것이 가장 뛰어난 고참 개발자가 관리자가 될 수 밖에 없는 상황이다. 그냥 오래 개발하다 보면 팀장, 부서장, 본부장이 되어서 조직을 관리하게 되는 것이다.

몇몇 기업은 개발자들이 관리에서 벗어나 꾸준히 개발자로 일할 수 있도록 하고 있지만, 이 또한 문제가 많다. 우선 회사에서 그렇게 개발자로서 성장하여 최고 개발자 위치까지 이른 사례를 찾아보기 어렵기 때문에 개발자들이 따를 Role model이 없다. 따라서 개발자들 스스로도 성장 단계별로 어떤 일을 해야 하는지 알지 못하고 우왕좌왕 하게 된다.

대기업 A사는 개발자의 직군에 Architect라는 직군을 만들고 이를 10여개로 세분화하고 각 직군마다의 R&R을 정하고 있다. Data Architect, System Architect, Application Architect 등 여러가지가 있다. 하지만 R&R이 소프트웨어 개발 현실과는 거리가 멀고 Role도 명확하지 않다. 결국 타이틀에 불과하고 일하는 방식은 주먹구구 방식과 큰 차이가 없다.

소프트웨어를 잘 모르는 HR 전문가나 관리자들이 만든 개발자 Career path는 현실성이 떨어져서 실제 적용이 잘 안된다.

개발자로 꾸준히 일을 하려고 해도 조직의 문화상 너무 많은 보고서 작성, 보고, 회의를 해야 하는 경우도 많다. 개발 일은 장시간 집중을 해서 성과를 낼 수 있는 일이라서 중간에 다른 일이 자주 끼어들면 제대로 일하기 어렵다. 보고를 이렇게 많이 해야 하고 보고서를 만드는데 오랜 시간을 투자해야 하는 이유는 기업의 기반시스템이 부족하여 경영자가 수시로 보고를 받아야 현황을 파악할 수 있기 때문이다.

또한 보고서의 내용보다 형식에 민감한 경영자가 많고 편하게 앉아서 자신이 필요할 때마다 아랫사람이 자세히 보고를 해주기를 원하는 경영자가 많다. 따라서 개발자라고 하더라도 이런 잡무가 많아질 수 밖에 없다.

이런 귀찮은 일들을 대신해줄 중간 관리자를 채용해도 전문성이 부족한 관리자들은 결국 일들을 개발자에게 토스하는데 그친다. 또한 중간 관리자가 일을 더 많이 만들어서 시키기 때문에 더 귀찮게 하는 경우도 있다.

대기업 개발자들과 인터뷰를 해보면 개발을 좋아해서 개발을 꾸준히 하고 싶은 개발자들도 개발 환경의 열악함, 개발자의 낮은 대우 등으로 인해서 현실적으로 관리자의 경력을 택하고 있었다.

중소기업도 크게 다르지는 않다. 개발을 아주 잘 이해하고 있는 경영자가 있는 회사가 아니라면 중소기업도 개발자 경력이 잘 보장 되지 않는다. 중소기업은 인력이 부족하다 보니 직종을 상세히 구분하지 못하고 개발자에게 팀장 또는 PM(Project Manager)일을 맡기게 된다. 그러다 보면 자연스럽게 개발과 관리의 경계가 무너지게 된다.

많은 회사들이 개발자 경력을 보장해야 한다는 사실 자체는 인지를 하고 있는 것 같다. 하지만 이를 문자 그대로 받아 들일 뿐, 진정으로 깨닫고 있지는 않은 것 같다. 현재의 기업문화와 개발 환경을 그대로 두고 개발자 경력 보장이 되기는 어렵다.

개발에 꼭 필요한 기반시스템들이 잘 구축되어서 제대로 쓰여야 한다. 그래서 투명한 개발 환경이 되어야 불필요한 보고와 회의가 대폭 줄어들게 된다. 경영자들도 매번 보고를 받지 말고 대부분의 정보는 시스템을 통해서 확인 할 수 있어야 한다. 기업 문화도 전문성을 존중하는 방향으로 바뀌어야 한다. 또한 관리자는 윗사람이라 상명하복 관계라는 생각도 바뀌어야 한다. 관리면 관리, 개발이면 개발 각각 전문성 있는 일을 하는 것일 뿐이다.

물론 개발자도 바뀌어야 하지만 경영자와 기업이 먼저 바뀌어야 할 것이다. 그래야 개발자 경력 보장이 제대로 정착이 될 수 있을 것이다.

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