생각의 폭을 넓혀야 한다.

우리나라에서 Global Software가 많이 탄생하지 않는 이유 중 하나는 개발자의 생각의 넓이가 좁기 때문이다. 물론 우리나라에도 뛰어난 아키텍트들도 있지만 생각이 넓이가 좁고 단편적이고 지엽적인 생각에 갇힌 개발자들도 매우 많다.

뛰어난 아키텍트라면 소프트웨어의 Scalability를 항상 생각한다. 물론 모든 상황에서 모든 Scalabiltity를 생각하는 것은 아니다. 비즈니스 계획 및 전략을 고려하여 가능성을 모두 검토한다.

지금보다 고객이 100배로 늘어난다면?

지원하는 국가 및 언어가 100배로 늘어난다면?

다뤄야할 데이터가 100배, 10,000배로 늘어난다면?

소스코드의 크기가 100배로 늘어난다면?

개발자가 100배로 늘어난다면?

고객과의 거리가 100배, 10,000배로 늘어난다며?

아키텍처는 이런 Scalability를 충분히 고려해서 설계를 해야 한다. 또한 프로세스를 자동화 해야 한다. 이렇게 여러분야에서 100배씩 늘어간다면 복잡도는 수천, 수만배 복잡해지는데 자동화를 하지 않으면 그 배수만큼 고스란히 비용이 발생한다.

여기서 국내 소프트웨어 회사와 글로벌 소프트웨어 회사의 차이가 많이 발생한다. 여러분도 다 아시는 국내 포탈회사는 아직도 많은 부분을 수동에 의존하고 있고 물론 고객도 그렇게 수동으로 관리된 컨텐츠를 좋아하고 있다. 그러다 보니 글로벌 시장에서 경쟁은 점점 어려워지고 있다. 로컬 1등 기업을 될 수 있어도 글로벌 유망 기업은 되기 어려운 이유 중 하나이다. 

많은 개발자들은 제품 초기에 아무런 비즈니스 전략 없이 대충 만들어 놓았다가 비즈니스가 잘되면 더 어려워지는 경우가 흔다. 개발자들이 생각의 폭을 좀더 넓혀야 한다.

image by ASA Goddard Photo and Video

소스코드가 없어졌다.

필자는 소스코드가 없어진 Software 회사를 여러번 보았다. 물론 회사의 전체 소스코드가 없어진 것은 아니다. 일부 소스코드가 없어져서 낭패를 보는 경우는 매우 흔하다. 소스코드는 어떻게 없어지게 될까? 물론 아래 모든 경우는 전사적인 소스코드 관리 및 백업을 받지 않은 경우에서 발생한다.

1. 하드디스크가 망가졌다.

하드디스크는 그렇게 믿을 만한 미디어가 아니다. 어느날 갑자기 망가져 버릴 수도 있고 복구가 안되는 경우도 종종 있다. 10년간 잘 돌던 하드디스크가 PC를 옮겼더니 갑자기 먹통이 되는 경우도 있다. 이런 경우 백업이 없다면 소스코드를 잃어버리는 것이다. 각 개발자의 PC에 사본이라도 있다면 History는 없어져도 최신 소스코드는 건질 수 있지만 그렇지 않아서 소스코드르 잃어버리는 경우를 종종 보았다.

2. 외주를 주고 소스코드를 받지 않은 경우

이 경우도 의외로 많다. 개념이 없이 소스코드를 받지 않은 경우도 있고, 계약상 소스코드는 제공하지 않는 경우도 있다. 두경우 문제가 되기는 마찬가지다. 개발툴을 업그레이드하려면 소스코드가 필요한데 그럴때 외주사가 망해 버리면 영영 발목이 잡혀버린다. 이럴 때는 소프트웨어진흥원에 소스코드 에스크로를 하면 회사가 망했을 때 소스코드를 가져올 수 있다. 외주사가 망해서 소스코드가 없어지는 경우은 의외로 흔하다.

3. 개발자가 소스코드를 관리하다가 퇴사를 한 경우

회사의 중요 제품이라면 소스코드를 잃어버리는 일이 흔하지 않지만 오래된 제품이나 툴등의 소스코드라면 개발자가 대충 소스코드를 보관하고 있다가 퇴사를 해버려서 언제 어떻게 잃어버렸는지도 모르게 소스코드가 없어지는 일이 발생한다. 수년 후 나중에 소스코드가 필요할 때 없어졌다는 사실을 알게 된다.

4. 회사의 소스코드관리시스템(SCM)을 백업받지 않은 경우

소스코드관리시스템을 도입하고 백업을 받지 않는 회사는 엄청나게 많다. 놀랄 일이다. Git등의 분산SCM을 쓴다면 어딘가에 백업이 있지만 SVN을 쓰다가 서버가 날아가면 간신히 부분적인 최신 소스코드만 건지게 된다. History가 사라진 최신소스코드는 그 가치가 몇분의 일로 줄어든다. 물론 많은 회사가 소스코드관리를 제대로 하지 않아서 History가 거의 가치없는 경우가 많다. 하지만 소스코드관리를 제대로 한 경우라면 History는 꼭 필요하다. SCM의 백업은 선택이 아닌 필수다.

이를 방지하는 방법은 전사적으로 소스코드관리를 철저히 하는 것이다. 하나의 통일된 소스코드관리시스템을 사용해야 한다. 회사 몰래 개발자가 숨겨 놓은 소스코드가 존재하면 안된다. 아무리 그렇게 관리를 해도 개발자들이 개인적으로 가지고 있는 소스코드가 존재할 수 있다. 스크립트라고 등록하지 않고, Install shield 프로젝트는 등록하지 않기도 한다. 이런 문제가 발생하는 또다른 이유는 개발자가 개발자PC에서 빌드를 하기 때문이다. 빌드를 빌드 전용서버에서 빌드 담당자가 하게 될 경우 숨어 있는 소스코드를 모두 끄집어 낼 수 있다. 빌드 전용서버는 오로진 SCM에서 소스코드를 가져다가 빌드를 하기 때문에 개발자PC에 숨겨진 소스코드가 있다면 빌드가 되지 않게 된다. 개발자를 못 믿어서가 아니고 빌드는 개발자PC에서 하면 안되는 것이다.

그리고 백업을 제대로 받아야 한다. 백업은 제3의 장소에 보관해서 회사가 완전히 불타 없어져도 소스코드를 바로 복구할 수 있어야 한다는 생각으로 백업을 해야 한다.

이런 환경을 구축하는 것은 비용이 더 많이 드는 일이 아니다. 제대로 관리를 하지 않고 소스코드를 엉망으로 관리하면서 오는 비효율과 비용 및 손실과 비교하면 훨씬 이익이다.

대한민국 개발자가 불행한 이유

미국에서 과거 10년 넘게 최고의 직업에 항상 소프트웨어 개발자와 아키텍트가 자리하고 있고 미래 성장 가능성도 상당히 높게 평가하고 있는 것을 보면 격세지감을 느낀다. 10개나 100개 직업 중에 1위가 아니고 몇 만개의 직업 중에 1위라는 것은 대단한 것이다. 그러나 우리나라에서 소프트웨어 개발자는 그렇게 인기가 있는 직종이 아니다. 의사, 변호사와 비교는 고사하고 3D 직업이라는 인식도 팽배하다.

이는 단순히 소득의 차이 때문은 아닌 것 같다.

우리나라에서 소프트웨어 개발자로 일하게 되면 10년, 20년 그리고 30년 이상 소프트웨어 개발자로 계속 일할 수 있다는 희망이 잘 보이지 않는다. 왜 그럴까? 이런 환경에서 태어난 대한민국의 소프트웨어 개발자는 불행하다고 할 수 있다. 미국이라고 무조건 개발자로서 성공적인 삶을 사는 것은 아니지만 같은 조건이라면 개발자로 잘 성장할 확률이 더 높고 여건도 좋다.

이런 차이가 발생하는 이유는 타고난 재능의 차이도 아니다. 개발자들의 기술력의 차이도 아니다. 바로 환경의 차이 때문이다. 소프트웨어 산업 생태계의 차이도 크지만 각 회사, 개발팀의 개발 문화 차이가 가장 크다. 이런 개발 환경을 만든 것은 개발자 여러분은 아니고 여러분의 선배들과 회사이다.

지금 이 글을 읽고 있는 소프트웨어 개발자가 만약에 미국에서 태어나 소프트웨어 개발자로 일하고 있다면 상당히 다른 환경에서 다른 경험을 하면서 성장할 것이다.

물론 우리나라가 더 좋은 환경을 가지고 있는 것도 있고, 내세울 수 있는 것도 있지만 소프트웨어 환경에 대해서는 이 땅에서 태어나 영어 때문에 고생하는 것처럼 핸디캡이 되는 것은 사실이다.

소프트웨어 선진국은 개발 프로세스, 기반 시스템, 조직 문화, 개발 문화 측면에서 큰 차이가 있고 성장을 도와줄 선배 개발자들이 많고 롤모델(Role model)도  있다. 우리나라에도 선배 개발자들이 많이 있지만 경험의 전수가 잘 안되는 구조가 문제다. 여기서 선순환과 악순환의 차이가 발생한다.

소프트웨어 선진국에선 입사를 하면 대부분 바로  업무에 투입된다. 문서, 시스템이 잘 갖춰져 있어서 버그를 수정하는 일을 하는데 큰 어려움이 없다. 버그추적시스템을 통해서도 버그를 할당 받고, 많은 정보를 얻을 수 있다. 소스코드는 시스템을 통해서 바로 한줄 한줄의 수정된 역사를 볼 수 있고 내용을 물어보러 다니지 않아도 웬만한 버그는 수정이 가능하다. 빌드도 자동화 되어 있어서 내용을 몰라도 누구에게 물어보지 않고도 한번에 빌드가 된다. 또한 내가 고친 코드는 피어 리뷰(Peer review)를 통해서 코딩 컨벤션 준수 여부뿐만 아니라 더 좋은 기법 등을 배운다. 분석, 설계 등에도 참여하고 지속적인 피어 리뷰를 거치면서 경험이 점점 깊어지고 후배나 동료들에게 내 지식과 경험도 공유하게 된다.

이렇게 할 수 있는 핵심은 적절한 피어리뷰다. 피어리뷰가 가능한건 기반시스템이 잘 갖춰져 있기 때문이다. 또 개발에 집중할 수 있고 다른 일은 신경쓰지 않아도 되는 프로세스와 조직문화 때문이다. 10년, 20년이 되면 시니어 엔지니어가 되거나 아키텍트가 될 수 있다. 회사 내에서 다른 프로젝트로 옮겨 다니거나 이직을 해도 후배들이 이어 받아서 아무 문제없이 개발이 지속된다. 15년이 되었는데 연봉도 다른 직업의 친구들보다 훨씬 높고 만족감이 높다.  과거 같이 일하던 동료가 차린 유망한 스타트업에 스톡옵션을 받고 참여하는 기회도 잡을 수 있다.

그럼 우리나라에서 소프트웨어 개발을 시작한다면 어떨까? 좋은 회사, 나쁜 회사, 여러 가지 경우가 있지만, 그 중 일반적인 예를 하나 보자.

대학에서 소프트웨어 전공을 하고 입사를 했다. 회사에서 개발하고 있는 소프트웨어에 대한 도메인 지식이 없으면 개발에 참여 하기가 어렵다. 관련 서적을 받아서 몇 달간 공부를 하고 회사에 대한 여러 가지 교육을 받는다. 제대로 개발에 참여하려면 최소 6개월이 걸린다고 하니, 일단 바로 유지보수에 투입된다. 소프트웨어를 파악할 수 있는 자료는 소스코드 밖에 없다. 선배들에게 물어물어 소스코드를 내려 받았고 개발환경을 구축하는데도 하루가 걸렸다.

빌드가 쉽지 않아서 여러 번의 실패와 우여곡절 끝에 빌드에 성공했다. 소스코드를 보고 분석을 하다가 도저히 몰라서 선배에게 물어보려니 개발한 선배가 퇴사를 했단다. 밤을 세서 수정을 했는데 제대로 동작하고 부작용(Side effect)은  없는지 확신은 없다. 누구도 내가 작성한 코드를 리뷰해주지 않는다. 그러다가 개발한지 얼마 되지도 않았는데 실전 사이트에 투입됐다. 선배와 같이 고객을 만나서 요구사항을 듣고 커스트마이징 작업을 진행했다. 워낙 바빠서 문서작성은 꿈도 못 꾸고 코딩만 했다.

선배와 내가 아니면 회사의 누구도 우리가 한 작업의 내용을 모른다. 경험이 쌓이면서 좀더 어려운 일을 맡고 바쁜 개발일정을 소화한다. 문서도 없고, 시스템에도 정보도 없고, 피어 리뷰도 없는 것은 여전하다. 회사에서 강제로 문서를 만들라고 해서 만들기는 하지만 쓸모 없는 문서일 뿐이다.

7년쯤 일하니 회사에서 제일 개발을 잘하는 개발자가 되었다. 경영진이 능력을 인정해서 팀장도 되었다. 팀장이 되니 회의도 많고 보고서도 많이 써야 한다. 낮에는 일할 시간이 거의 없어서 직원들 퇴근 후에 개발을 하게 되었다. 그러나 보니 차츰 개발에서 손을 떼게 되었다. 다시 개발로 돌아 가려고 하지만 여건이 안 된다. 팀장을 몇 년 하다 보니 정체성이 없어지고 앞길이 막막해졌다. 이제 치킨집을 차릴 때가 되었나 보다.

이러한 선순환과 악순환의 차이를 극복하려면 개발 환경을 바꿔야 한다. 개발프로세스, 기반시스템, 개발문화, 조직문화가 바뀌어야 한다. 우리가 이를 바꿔나가지 않으면 우리 후배들도 10년, 20년 후에 똑같은 얘기를 하면서 한숨을 쉬고 있을 것이다. 이는 비단 후배들만을 위한 일은 아닐 것이다. 우리가 일할 10년, 20년 후의 소프트웨어 환경을 바꾸는 일이다.

환경을 바꾸려고 하니 무엇부터 바꾸어야 할지 막막한 경우가 많다. 물론 회사마다 다르기는 하지만 쉬운 것부터 하는 것이 좋겠다. 우선 효율적인 기반시스템을 갖추는 것이 좋다. 성숙도에는 차이가 크겠지만, 소스코드관리, 버그관리, 빌드 자동화를 갖추고 서로 연동을 시킨 뒤  소스코드를 보면 버그나 이슈가 연결되고 반대로 버그가 소스코드와도 쉽게 연결될 수 있는 환경을 만들어야 한다.  그리고 나면 피어 리뷰를 할 수 있는 환경이 조금씩 되어 간다.

거의 모든 것을 완벽하게 자동화하는 것이 바람직하다. 자질구레하게 중간중간 수동 작업이 많이 들어가면 회사가 커갈수록 비용은 점점 올라가고 비생산적인 일에 많은 노력을 들여야 한다. 또 완전 자동화된 시스템 환경이어야 공유와 효율적인 협업이 가능하다. 인터넷에서 정보를 얻어서 좋을 툴을 설치하는 것은 어렵지 않지만 제대로 구축해서 잘 사용하는 것은 몇 백배 더 어렵다. 경험을 많이 해본 선배들의 도움을 받는 것은 필수적이다.

이 정도 되어야 환경을 바꾸기 위한 마라톤의 한 발을 내디딘 것이라고 보면 된다. 그래도 시작이 반이다. 의미 있는 한발이 될 것이다.

이 글은 제가 CNet Korea에 기고한 칼럼입니다. (http://www.cnet.co.kr)

QA팀이 필요없다고?

최근에 평가 자리에서 만난 유망하다는 스타트업의 대표의 이야기이다.

회사의 조직구조를 보니 테스트를 하는 팀이 보이지 않았다. 그래서 "QA팀이 없는냐"고 물어보니 "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"라는 답변을 들었다. 그리고 본인(CEO)은 개발자들을 믿는다고 한다. (다른 회사는 믿음이 부족해서 버그가 생기나? ^^)

좀더 자세히 물어보니 내부에는 테스트인력이 없고 테스트를 고객이 해주는 것이었다. 삼성등의 대기업이 주 고객인데 패치도 자주 나갈뿐더러 고객이 테스트담당자가 있어서 패치가 나올때마다 꼼꼼하게 테스트를 해준다는 것이다.

사실 이런 얘기 하나만 들어도 회사가 얼마나 형편없는지 알 수 있다. 당장은 동작하는 소프트웨어를 만들어 낼 수는 있지만 그 이상은 택도 없을 것이다.

겉으로는 유망한 스타트업이고 Global Service를 준비중이며, 대규모 IR을 진행하고 있다고 한다. 그래도 꽤 유망하다는 스타트업이 이런 정도의 수준이라니 실망스럽기 짝이 없다.

회사의 품질관리를 고객에게 맡긴다는 것도 우습고 고객이 비용을 들여서 테스트를 해준다는 것도 우습다. 고객은 확인하는 정도의 Acceptance Test라면 말이 되지만 이렇게 같이 개발하는 형태의 개발은 세계적으로 유래를 찾아보기 어려울 것 같다.

이런 형태가 가능한 것이 스펙도 불확실한 상태에서 개발을 하다보니 고객과 개발사가 같이 으쌰으쌰하면서 개발을 한다. 주먹구구의 대표적인 행태이다. 이러다 보니 제대로 기획된 제품이 만들어지기 보다는 고객 담당자 취향대로 개발이 되곤 한다.

필자의 경험에 의하면 많은 회사들이 이 회사와 크게 다르지 않다. 또한번 갈길이 멀고 넘어야 할 산이 많다는 것을 느낀다.

초등학생 코딩 교육을 보는 기대와 불안

“초등학교 4학년부터 재미있고 쉬운 컴퓨터 코딩 교육을 받는다면 청년이 되어 코딩에 능숙한 전문가들이 늘어날 것이고, 그 중에는 스티브잡스와 같은 인재들이 나타날 수 있을 것이다.”

미래창조과학부에서 나온 말이다. 여기에 대해 “소프트웨어 개발에 대해서 알고나 하는 소리냐?”, “스트브잡스가 코딩 잘해서 성공했냐?”라고 따지고 싶은 생각은 없다. 예들 들다 보니 스티브잡스를 그냥 갖다 붙인 것이 아닌가 생각된다. 많은 사람들이 이 정책을 비난하고 있지만 나는 기본적으로 초등학생에게 코딩 교육의 기회를 주는 것을 찬성을 한다. 하지만 찬성하는 마음 못지 않게  어떤 식으로 왜곡돼서 진행될지 매우 걱정스럽다.

나는 초등학생 코딩 교육이 코딩 전문가를 늘리기 위한 것이 아니어야 한다고 생각한다. 선천적으로 뛰어난 논리력을 타고난 아이들을 찾아내고 컴퓨터와 소프트웨어에 대한 흥미를 유발하고 아이들의 창의력을 더욱 향상 시키는 것이 목적이 아닌가 생각한다. 김연아가 어렸을 때 스케이트를 타보지 않았다면 지금의 김연아가 없듯이 코딩 교육의 기회는 소질을 타고난 아이들을 찾는데 도움이 될 것이다.

정부에서 새로운 교육정책을 들고 나오면 먼저 불안감이 든다. 그 동안 신중하지 못하고 준비가 덜 된 교육 정책으로 여러 부작용을 야기해 왔기 때문에 이번에도 또 많은 문제가 생기지 않을까 우려하는 목소리가 크다.  이 정책을 통해서 아이들에게 컴퓨터와 소프트웨어에 대한 흥미를 유발하고 창의력이나 논리력을 키우는데 집중해야 하는데, 또 시험을 통과해야 하고 목표 점수를 얻고 등급을 높이는 방법으로 빠져들어 사교육만 배를 불리고 선행교육이 판을 칠 수 있다.

충분한 시간을 두고 우리나라 초등학생에게 알맞은 교육 도구가 개발된 후에 진행해야 하는데 또 날림공사 식으로 진행될까 걱정된다.

그럼 초등학생 코딩교육의 목적에 대해서 생각해보자.

초등학교 교육은 미래에 전문적인 교육을 받기 위한 기초가 된다. 그리고 기본적으로 사회를 건강하게 만드는 기반이기도 하다. 많은 사람들이 학교 다닐 때 과학과 수학을 어렵게 공부했는데 사회에 나와서는 하나도 써먹지 않아 시간 낭비 했다고 하는데 사실은 그렇지 않다. 어렸을 때의 교육은 지식을 익히는 것뿐만 아니라 논리적인 사고와 합리적인 생각을 하게 해준다.

미분, 적분은 직접 써먹을 기회가 없을 수도 있지만 자신에게 닥친 문제를 합리적이고 논리적으로 해결할 수 있도록 해준다. 비과학과 비논리의 오류에 빠져서 돈과 시간을 낭비하는 일을 줄여준다. 우리가 지금 너무 자연스럽게 생각하고 있는 것은 어렸을 때부터 받았던 교육과 경험의 결과이다.그럼 코딩교육은 어떨까?

100년 전에는 수학, 과학 교육이 거의 필요 없이 살 수 있는 세상이었다. 그럼 30년 후에는 어떨까? SF영화에도 종종 나오기도 하지만 상상하기는 쉽지 않다. 확실한 것은 컴퓨터가 지금보다 10배, 100배는 많이 쓰이는 세상이 될 것이다. 그런 세상에 합리적으로 살아가기 위해서 기본적으로 컴퓨터에 대한 이해와 논리력이 더 필요할 것이다. 교육은 시대의 흐름을 예측하고 대비해야 한다.

많은 초등학생이 잘 준비된 코딩 교육 기회를 접한다면 미래에 많은 소프트웨어 개발자가 생겨날 수도 있을 것이다. 그런데 그렇게 쉽게 기대하기에는 현재 우리나라 소프트웨어 업계는 너무나 매력이 없다. 소프트웨어 업계는 3D 취급을 받고 있고, Dreamless를 포함해서 4D라고 하기도 한다. 이런 바닥에 뛰어난 인재가 더 많이 지원할 리가 없다. 최근 10~20년간 소프트웨어 업계의 인기는 계속 추락해왔다. 대학의 소프트웨어 관련학과도 마찬가지이다.

소프트웨어 개발 일은 툭하면 야근에 부당한 대우에 사회적 인식은 바닥을 유지하고 있다. 좀 똑똑하다는 학생 중에서 미래에 개발자가 되고 싶다는 학생은 그리 많지 않다. 대부분 의사, 변호사가 되고 싶어한다. 코딩 선행 교육이 이런 문제를 해결해주지 않는다. 이런 와중에 소프트웨어 개발의 소질을 발견한들 소프트웨어 업계로 오겠는가? 근본적인 문제는 심하게 왜곡되고 뒤틀어진 소프트웨어 개발 환경이고 이를 개선해야 한다. 소프트웨어 업계가 일할만한 곳이란 비전이 보인다면 많은 인재가 지원을 할 것이다.

스티브잡스와 같은 인재가 탄생하기를 원하고 미래에 소프트웨어 인력이 많이 필요하다면 초등학생 코딩 교육보다 먼저 소프트웨어 업계를 정상화하기 위한 제도와 지원이 필요하다.

초등학교 코딩 교육은 어른들이 배우는 것을 흉내 낼 것이 아니라 논리력과 창의력을 키우는데 집중하고 재미있게 배울 수 있는 교육 도구들을 꾸준히 개발해야 할 것이다. 섣불리 어른이 배우는 것을 비슷하게 배운다면 흥미는커녕 오히려 지겨워할지도 모른다.

초등학교 코딩 교육 정책은 제대로 준비되고 꾸준히 투자가 이루어 진다면 30년 후에 우리나라의 중요한 국가 동력의 핵심이 될 수도 있을 것이다.

이 글은 제가 CNet Korea에 기고한 칼럼입니다. (http://www.cnet.co.kr)

인기없는 10년차 개발자

우리나라에서는 나이 많은 개발자가 별로 인기가 없다. 10년~20년차 개발자들은 그들을 찾아주는 회사가 그렇게 많지 않아서 이직이나 진로에 대해서 항상 고민이 아닐 수 없다.

아직 경험이 적은 개발자들이 불만도 적고, 시키면 시키는대로 일하고, 매일 야근을 해도 버틸 수 있는 체력이 남아 있고, 돌봐야 할 가정을 아직 꾸리지 않은 개발자들이 인기가 많다. 이 개발자들도 곧 체력이 바닥나겠지만, 아직 남아 있는 체력을 쥐어짤 것은 남아 있다.

필자는 개발자가 제대로 아키텍트가 되고 제대로 실력을 발휘하려면 10년 이상은 개발을 해야 한다고 생각한다. 그래서 기술도 두루 셥렵하고 소프트웨어 공학에 대한 경험도 꽤 쌓고, 비즈니스와 경영도 이해하게 된다. 이렇게 제대로 성장한 10년차 개발자라면 일반 프로그래며 10명 이상의 가치가 있다.

하지만 우리나라의 많은 회사에서는 그런 아키텍트가 제대로 일할 수 없는 환경이거나 그들의 가치를 알아보지 못한다. 물론 좋은 회사도 있지만 그리 많지는 않다.

제대로 성장했을 경우 10년차 정도면 실력도 뛰어나고 체력도 남아있고, 아직 꿈도 있고 스타트업에 참여하여 모험을 해볼만하고, 큰 조직에서는 개발 조직의 중추적인 역할을 할 수 있다.

문제 중 하나는 이런 10년차 개발자 중에서 아키텍트라고 부를 수 있는 개발자도 현실적으로 그렇게 많지 않다는 것이다. 또한 그들이 아키텍트로 성장할 수 있는 환경이 아니라는 것이 더 문제다.

매일 불끄기와 야근에 시달리다보면 성장은 커녕 일에 치이고 해놓은 일들이 자신을 발목을 잡고 바쁘기는 하지만 매일 가치없는 일에 매달리고 앞으로 나아가기가 어렵다. 이런 챗바퀴가 우리나라 많은 고참 개발자들의 생활이다.

그 악순환의 고리를 하나씩 끊어가야 한다.

성숙한 개발문화 정착이 어려운 이유

우리나라가 소프트웨어 개발을 잘하기 위해서 꼭 필요한 것 중에서 가장 먼저 성숙한 개발문화를 꼽는다. 그런데 간단해 보이는 것 하나도 정착하기가 보통 어려운 것이 아니다. 도대체, 개발문화가 왜 그렇게 정착하기 어려운지 그 이유를 생각해보자.

첫째, 문화란 혼자 바뀐다고 전체가 따라서 바뀌는 것이 아니다. 

문화란 집단의 공통된 행동 양식인데, 혼자서 전체를 바꾸기란 거의 불가능하다. 서로 이익이 된다면 자연스럽게 바뀌어 나가겠지만 대부분의 성숙한 개발 문화라는 것이 다같이 따를 때는 모두에게 이익을 가져다 주지만 혼자 제대로 하면 혼자 손해를 보기 마련이다. 정보를 공유하자고 해서 혼자 열심히 공유를 하고 다른 사람은 꼼짝을 안하면 혼자서 손해를 보는 것이다. 따라서 모두에게 이익이 되며 현재 수준에서 할 수 있는 것들로 조금씩 바꿔가지 않으면 거의 바뀌지 않는다.

둘째, 문화는 책으로 배우기 어렵다.

우리는 흔히 실리콘밸리의 개발문화를 전해 듣는다. 나이에 상관없이 소프트웨어 개발을 계속 할 수 있고, 나이 어린 팀장과 일할 수 있고, 공유와 리뷰가 활발하며, 이직이 활발하며 그래도 회사는 문제 없이 돌아가며, 개발팀의 기술적인 결정을 영업에서 함부로 뒤집지 않는다. 아키텍처를 고려한 장기적인 시간에서의 결정을 근시안적으로 뒤집지 않고 CTO가 CEO만큼 힘이 있다. 이런 얘기를 맨날 들어봐도 어떻게 해야 그렇게 되는지 알기는 어렵다. 결과만 보이지 상세한 행동 양식은 잘 보이지 않는다. 그래서 따라하려고 해도 따라하기 힘들다. 또한 쫓아 한다고 우리 의식 속에 깊이 자리잡은 우리의 문화를 무시하기도 어렵다.

셋째, 문화란 바뀌는데 오랜 시간이 걸린다.

문화는 짧게는 5년, 10년 이상 걸려야 바뀌는 것이 눈에 보인다. 그런데 우리나라에서는 아직 그정도의 인내심을 가지고 꾸준히 성숙한 문화를 정착하려고 노력해서 성공한 회사가 그렇게 많지는 않다. 중간 중간에 수많은 시행착오로 인해서 옆길로 빠지거나 포기하기 일쑤이다.

넷째, 단독으로 문화만 배울 수는 없다.

각 나라의 문화는 기후, 자원, 자연 등과 깊이 관련이 있다. 소프트웨어 개발 문화도 여러가지와 연관이 있다. 제도, 교육 상황, 산업 규모 등 수많은 것과 연관이 있다. 달랑 한 문화의 단면만 따라한다고 쉽게 되지는 않는다. 항상 기록을 남기는 방식으로 개발문화를 바꾸고 싶어도 기록을 남기는 것에 대해서 너무 훈련이 안된 개발자가 많다. 아키텍처를 중요시 하고 싶어도 뿌리깊은 영업 드라이브 문화는 쉽게 바뀌지 않는다. 따라서 우리의 현실을 무시한 성숙한 문화란 공염불에 그치곤 한다.

결론은 간단하지만 쉽지는 않다. 우리에게 알맞는 개발 문화를 찾아야 한다. 원칙을 거의 같지만 모습은 약간씩 다를 것이다. 그리고 혼자, 한 회사만 바뀌어서 될 일은 아니다. 업계 전체적으로 바뀌도록 노력해야 한다. 또한 5,년, 10년이상 꾸준히 노력해야 한다. 그래서 노력하는 사람이 대다수가 되면 이미 우리도 우리에게 알맞는 성숙한 개발문화를 가지게 될 것이다. 물론 10년안에 그렇게 바뀐다면 행운이고 30년이 걸릴지도 모르겠다.