이우소프트에서 개발자의 경력을 보장하는 방법

현재 필자가 CEO로 있는 이우소프트에서는 2015년 여름까지 K수석연구원이 개발실장 역할을 맡고 있었다. K수석은 경력이 20년이 넘고 개발은 매우 잘 하지만 관리는 싫어하는 천상 개발자다. 하지만 회사에서 개발실 관리를 맡기니 어쩔 수 없이 관리를 해야 했고 보고서 작성, 회의 등으로 거의 모든 시간을 보내고 정작 자신이 잘하고 좋아하는 개발 일은 거의 못했다. 그래서 스트레스도 매우 심했다. 

우리나라 대부분의 소프트웨어 회사에서 비슷한 일이 벌어진다. 개발자 경력이 10년쯤 되면 팀장, 실장 등 여러 가지 타이틀로 관리에 발을 들인다. 개발자가 일단 “장” 타이틀을 달기 시작하면 커리어가 꼬이기 시작한다. 그럴듯한 보고서도 만들어서 경영진에게 보고도 해야 하고 회의도 많아져서 개발을 할 시간이 점점 줄어든다. 일단 관리에 발을 들이게 되면 관리에 많은 시간을 쏟아야 하고 기술과는 점점 멀어지고 어정쩡한 관리자로 자리를 잡게 된다. 그런데 전문성이 별로 없는 일반 관리자가 될 뿐이다. 다시 개발자로 돌아오지도 못한다. 그러다가 못 버티는 개발자들은 업계를 떠나 치킨집을 차리기도 한다.

이렇게 고참 개발자에게 본인의 의사에 반해서 관리를 맡기면 회사는 무엇을 얻게 되는가? 

회사에서 가장 뛰어났던 SW 개발자들이 잘 하지도 못하고 전문성도 없는 관리 일을 기웃거리다가 대부분 밀려나게 된다. 그럼 개발자는 10년을 넘어가면 더 이상 개발을 못하는 것인가? 전혀 그렇지 않다. 계속 개발에만 매진한다면 10년, 20년, 30년 경력이 쌓일수록 실력이 향상된다. 단지 회사에서 개발자 경력을 보장하지 않기 때문에 개발자의 경력을 지키지 못할 뿐이다.

개발자는 여러 종류가 있다. 어플리케이션 개발자, 알고리즘 개발자, 이미지 프로세싱 전문가, 커널 개발자 등 다양한데 이들에게 고참이 되었다고 관리, 사업, 경영을 하라고 회사에서 압박을 하는 것이다. 이들의 대부분은 관리자로서 실패한다. 원래부터 그쪽으로는 영 소질이 없는 경우가 대부분이다. 하지만 조직에서 힘있는 위치이기 때문에 관리도 잘 못하고 망치고 있어도 팀원들은 불만을 얘기하지 못하고 경영자는 이들이 회사를 망치고 있다는 것을 잘 알아차리지 못한다. 이들은 조직문화의 피해자이며 가해자가 된다. 

이렇게 뛰어난 고참 개발자들이 사라지는 회사는 개발 생산성이 낮아 질 수 밖에서 없다. 어떤 경영자는 밤을 새워 가며 일할 수 있는 젊은 개발자를 더 선호하지만 SW는 작업시간이 생산성과 비례하지는 않는다. 창의적 지식산업인 SW개발에서는 시니어 개발자가 주니어 개발자보다 몇 배 더 뛰어난 것이 일반적이다. 시니어 개발자일수록 회사에서 잘 지켜내야 한다. 그래서 실리콘밸리에서는 60세가 넘는 개발자를 보는 것이 그렇게 어렵지 않다. 

그럼 우리나라에서는 개발자 경력 보장이 왜 잘 안될까? 뿌리깊은 상하관계 위주의 조직문화가 중요한 이유다. 관리자가 윗사람으로서 팀원에게 지시를 하고 팀원은 이를 따라야 한다. 그런 조직에서 일하다 보면 왠지 팀장 등 관리자가 되어야 승진을 한 것 같고 힘도 생기며, 팀원으로 계속 남아 있으면 피곤해진다. 이런 상하관계 조직문화가 계속 남아있는 회사에서는 개발자의 경력을 보장하기는 어렵다. 

우리나라에서는 개발자의 분포가 나이 들수록 개발자의 인원수가 급격히 줄어드는 위가 뾰족한 삼각형 모양이다. 하지만 구글 등의 글로벌 회사들은 나이에 따른 개발자 인원수가 사다리꼴에 가까운 네모 모양이다. 즉 개발자들은 꾸준히 자신의 경력을 보장 받으며 실력을 키워간다는 것이다. 그런 회사와 어떻게 개발 실력으로 경쟁이 되겠는가? 

그럼, 과거 이우소프트는 어떤 상황이었을까? 

개발실의 고참들은 실장, 팀장의 이름으로 관리에 바빴고 개발과는 점점 멀어지고 있었다. 또한 회의와 보고에 불려 다니느라고 정신 없는 나날을 보내고 있었다. 그래도 다시 팀원이 되라고 하면 좋아하지 않을 상황이었다. 팀장이 되어야 연봉도 더 오르고 행정적인 파워도 생기기 때문이다. 

그래서 나는 먼저 개발실 내에서 “상하 관계 철폐”를 강력하게 추진했다. 제도를 바꾸고 마인드를 바꾸기 위해 노력했다.

개발팀장의 인원수도 대폭 줄이고 팀장의 역할도 최소한의 결재로 축소를 했다. “직급”도 거의 통일해서 대부분의 개발자가 “책임연구원”이 되어 호칭도 수평적으로 바뀌었다. 개발팀장도 95%의 시간을 순수 개발에 투입하도록 했다. 개발자들에 대한 개별 관리는 완전히 제거를 하고 스스로 일하게 했다. 

PM조직을 신설하고 전문PM을 영입했고 전문PM이 프로젝트 관리를 전담하게 했다. PM과 개발자는 완전히 수평적인 관계를 형성했고, 개발팀 내에서도 누가 윗사람이라는 의식은 거의 없어졌다. 각자 전문분야가 다른 전문 개발자들일 뿐이다. 직급통일로 위아래 구분도 어려워졌다. 어린 PM과 나이 많은 개발자가 같이 일하는데 거북함은 없는 분위기다.

이제 개발도 하고 관리도 하는 어정쩡한 개발자는 없으며 채용도 하지 않는다. 20년 경력의 개발자를 채용할 때도 코딩테스트는 필수다. 날고 긴다는 개발자도 코딩테스트를 통과하지 못하면 입사를 할 수 없다. 그리고 개발자들도 원한다면 평생 개발을 할 수 있다는 확신을 가지게 되었고, 관리자가 되고 싶어하는 개발자는 이제 거의 없다. 

물론 단 몇 개월 만에 조직 문화와 모든 직원들의 마인드까지 완전히 바꾸는 것은 쉽지 않고 끊임없이 과거의 습관들이 튀어나올 수 있다. 스스로 일하는 문화는 적응이 어렵고 윗사람이라는 권위의식도 한번에 없어지지 않는다. 그래서 수많은 기업들이 개발자 경력보장을 제도로 만들어도 고착된 문화에 가로막혀 정착이 잘 안 된다. 필자의 회사 내에서도 수평적인 조직과 전문가 중심의 조직을 유지 발전 시키기 위해서 끊임 없이 노력하고 있으며 그런 노력이 소홀해지면 순식간에 과거로 회귀할 수 있다는 것을 잘 알고 있다. 공든 탑을 쌓는 것은 어렵지만 무너지는 것은 순식간이다.

우리나라도 개발자가 선택에 의해서 안심하고 평생 개발자로 일할 수 있는 환경이 되어야만 한다. 여러 기업 문화가 서로 얽혀 있어서 하나만 바뀐다고 이 문제가 해결이 되지 않는다. 앞으로 글로벌 기업들과 경쟁하기 위한 최소한으로 바뀌어야 하는 기업문화를 실제 사례 중심으로 계속 이야기 해보고자 한다. 

이글은 ZDNet Korea에 기고한 글입니다.

소프트웨어 번역 프로세스의 절대 원칙 (19)

소프트웨어를 국제화하려면 수많은 요소를 국제화해야 하지만 그 중에서 절대 빠지지 않는 부분이 번역이다. 또한 가장 중요하면서 어렵다. 필자가 얘기하는 주제는 번역 그 자체를 제외한 번역을 위한 모든 활동을 말한다. 소스코드에서는 어떠한 함수를 사용하고, 메시지는 어떻게 추출해서 어디에 저장하고 번역가에게는 어떻게 보내고, 번역된 메시지는 소프트웨어에서 어떻게 읽어 들여서 출력할 것인지에 대한 아키텍처와 프로세스 전반을 말하는 것이다. 

소프트웨어를 어느 정도 개발해 본 경험이 있는 개발자라면 소프트웨어를 번역해서 해외에 출시해 본 경험을 누구나 가지고 있다. 또한 별 문제를 겪지 않아서 소프트웨어 번역이 별거 아니라고 생각하는 개발자도 많다.

그럼에도 불구하고 필자는 왜 자꾸 어렵다고 얘기를 하는 것일까? 과장을 하는 것은 아닐까? 아니다. 소프트웨어 번역에서 별 문제를 겪어보지 못한 개발자들은 아직 심각한 상황을 경험해보지 못해서 어려움을 모르는 것일 가능성이 높다다. 아래 5가지 상황 중에서 2가지 정도만 닥쳐도 소프트웨어 번역은 심각한 문제가 된다.

10개 이상의 언어(로케일)을 지원

100명 이상의 개발자가 공동 개발

10000개 이상의 메시지를 번역

100,000명 이상의 고객이 사용한다.

적어도 한 달에 2번 이상 업데이트

한두 명의 개발자가 몇 백 개의 메시지를 번역해야 하는 상황이라면 어떤 메시징 아키텍처를 사용하던지 완전 수동화된 프로세스를 사용해도 거의 문제가 안 된다. 그래서 거의 모든 개발자들이 큰 고민 없이 여러 개발툴들이 제공하는 메시징 함수를 그냥 사용하고 수동에 의존한 프로세스에 익숙해져 있다.

그렇게 성장을 하다가 큰 제품을 만들 기회가 생기고 큰 조직에서 수십 명의 개발자와 같이 개발을 하게 되면 번역은 10배, 100배 비용이 들게 된다. 

예를 들어 전세계 백만 명이 사용하는 제품을 20개 언어(로케일)로 번역을 해야 하는 거대 프로젝트에 참여를 했다고 생각하자. 소프트웨어에 추가할 메시지들을 RC에 추가한다던지 별도의 파일에 추가하는 것은 쉽지가 없다. 메시지도 수만 개에 이를 뿐만 아니라 수십 명의 개발자들이 동시에 RC파일을 고쳐댄다. 똑 같은 메시지가 서로 다른 심볼로 중복 저장되기도 하고 반대로 의미가 다른 동일한 메시지를 사용하기도 한다. 더 이상 사용하지 않는 메시지를 삭제 했더니 다른 개발자는 사용하고 있는 경우도 있다. 그래서 메시지를 삭제 않다 보니 사용하지 않는 메시지가 넘치게 된다.

번역가에게 번역을 의뢰할 때도 처음에는 문제가 안되는데 두 번째 버전부터는 바뀐 메시지만 의뢰를 해야 한다. 번역된 결과물을 첫 번째 번역과 합치는 것도 문제다. 이렇게 복잡한 수동 프로세스에 의존하다 보니 누락된 메시지가 생긴다. 이를 개선하고자 자동화툴을 만들어보지만 깔끔하게 해결하는 것이 쉽지는 않다.

이런 거대 프로젝트에 참여를 해서 소프트웨어 국제화의 어려움을 실제로 겪어본 개발자는 그렇게 많지 않다. 하지만 모든 개발자는 언제든지 이런 상황을 겪게 될 것이고 지금의 국제화 지식만 가지고는 남들이 겪은 국제화 실패를 고스란히 다시 겪게 될 것이다.

그럼 소프트웨어 번역은 어떻게 해야 할까? 앞으로 여러 차례에 걸쳐서 설명을 하게 될 것이고 오늘은 대원칙 2가지를 알아보자.

첫째, 메시지의 키는 영어 자체를 사용해야 한다.

둘째, 번역 자체를 제외한 모든 프로세스는 완전 자동화 되어야 한다.

위 두 원칙에는 많은 의미를 포함하고 있고 적용하기 쉽지도 않다. 또한 기존에 수많은 개발자들이 소프트웨어 번역을 위해서 사용하고 있는 방법의 대부분의 뒤 두가지 원칙에 위배되고 있다.

다음 시간에는 왜 메시지의 키가 영어가 되어야 하는지 설명을 시작으로 소프트웨어 번역에 대해서 좀더 깊이 들어가보자.

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있다. 이런 얘기를 들어보면 우리나라에서 개발자는 나이를 먹을수록 할만한 직업이 아니라는 생각이 든다.

필자는 이런 현상이 벌어지는 이유 중 하나로 리뷰를 잘 안 하는 문화를 꼽고 싶다. 개발자라면 각자 생각해보자. 지금까지 얼마나 많은 리뷰를 해왔던가? 자신이 작성한 문서, 소스코드를 다른 사람이 얼마나 리뷰를 해줬고, 나는 또 다른 사람이 만든 문서와 소스코드를 얼마나 많이 리뷰를 해줬던가? 잘 생각해보자. 개발자가 10년 정도 일을 했으면 수백 건의 문서와 수만에서 수십만 라인의 코딩을 해왔을 것이다. 그 중에서 리뷰를 받은 경우는 몇 %나 될까?

개발자를 성장하게 해주는 가장 효율적인 수단은 “리뷰”다. 물론 책을 보거나 인터넷을 통해서 지식을 익히는 것도 하나의 수단이다. 하지만 리뷰를 통해서는 훨씬 더 효율적으로 배우고 책을 통해서는 도저히 알 수 없는 수많은 것을 배운다. 물론 본인도 리뷰를 통해서 다른 사람에게 나의 경험과 지식을 전달해줘야 한다.

리뷰는 요구사항을 확인하고 문제점을 찾아내고 바로 잡는 역할도 하지만 자연스럽게 개발자들의 성장을 돕는다. 물론 리뷰를 제대로 해야 한다. 수박 겉핥기 식으로 훑어보는 것은 제대로 된 리뷰가 아니다. 문서든 소스코드든 본인의 전문적인 관점으로 철저하게 수행해야 하면 여기에 많은 시간과 노력을 투자해야 한다. 리뷰를 귀찮은 절차로만 생각하고 바쁘면 생략하거나 흐지부지 사라지는 경우가 많다. 하지만 생략되거나 엉터리 리뷰 때문에 제품이 잘못되기도 하지만 장기적으로는 개발자들이 성장을 하지 못한다.

내가 경험하기로는 중소기업이나 대기업이나 리뷰를 하고 있다고 한 회사치고 진짜 리뷰를 제대로 하고 있는 회사는 매우 드물다. 대부분은 정형화된 프로세스를 따르기 위해서 형식적으로 수행하거나 리뷰를 위한 시간을 주지 않아서 개발자들이 어쩔 수 없이 리뷰를 대충하는 경우가 많다.

그럼 이렇게 꼭 필요한 리뷰가 우리나라에서 리뷰가 잘 안 되는 이유가 무엇일까?

첫 번째 이유는 바쁘다는 이유다. 바빠서 리뷰를 할 시간이 없다는 것이다. 하지만 바빠서 리뷰를 하지 않거나 소홀히 하면 점점 더 바빠질 것이다. 문제가 조금씩 더 쌓이고 개발자들이 실력이 정체되어서 개발 효율이 점점 더 떨어지기 때문이다.

두 번째 이유는 리뷰에 익숙하지 않기 때문이다. 그래서 리뷰를 거북해하는 개발자가 많다. 리뷰를 하면 지휘고하를 막론하고 자식이 작성한 스펙, 설계, 소스코드를 철저히 검토 받는다. 리뷰를 진행하면 지적을 당하기도 하고 다양한 의견 충돌이 있어서 협의, 조율해야 할 때도 있다. 물론 도움을 받는 경우도 많다. 하지만 나이별, 직급별 상하관계가 굳건한 조직이라면 아랫사람은 쉽게 반대 의견을 제시하기 어렵다. 자존심이 상하기도 하고 관계가 틀어지기도 한다. 또, 윗사람의 의견은 지시처럼 들리기 일쑤다. 이런 딱딱한 조직에서 리뷰는 쉽지 않다.

그럼 우리나라 대기업들은 어떨까? 회사마다 다르지만 보통 개발자들은 자기 분야의 보직을 바꾸지 않고 오랫동안 일을 한다. 그러다 보니 그 개발자가 일하는 것을 봐줄 사람도 별로 없고 리뷰를 하지 않아도 별 문제 없이 일이 진행되는 것처럼 보인다. 회사에서 리뷰를 강제화해도 진짜 리뷰가 잘 되는지 파악하기는 쉽지 않다. 이런 문제를 보완하고자 자꾸 프로세스와 절차를 만들어도 개발 효율만 떨어지지 리뷰가 잘 되는 것은 아니다. 이런 문제를 가지고 있는 회사가 리뷰를 잘하고 있는 회사보다 훨씬 많다.

리뷰를 제대로 안 하면 버그도 많아지고 이를 고치기 위해서 비용이 더 많이 든다. 테스트를 강화해서 해결을 하려는 노력도 많이 하지만 리뷰를 잘하는 것보다는 장기적으로 더 비싼 방법이다. 

결정적인 문제는 개발자가 성장하기 어렵다는 것이고 한가지 일에 매몰돼서 빠져 나오지 못하는 경우가 많다. 리뷰를 잘 하고 있다는 얘기는 자연스럽게 공유가 잘된다는 의미와도 같다. 말로만 공유한다고 떠들어도 리뷰를 안 하면 문서가 제대로 작성된 것인지 알 수가 없다. 하지만 리뷰를 제대로 하면 문서가 조금만 부실해도 바로 발견이 된다. 리뷰를 제대로 하면 문서가 충실하게 작성될 뿐만 아니라 그 내용이 리뷰를 통해서 동료들에게 전달된다.

리뷰를 제대로 안 하는 현상이 지속되면 특정 지식을 특정 개발자만 알고 있게 되고 이런 개발자가 많아질수록 조직의 유연성은 대단히 떨어진다. 소수의 개발자만 퇴사를 해도 회사가 휘청거리고 개발자들이 정말 바쁠 때 다른 개발자가 도와주기 어렵게 된다. 바쁜 사람은 항상 바쁘고 노는 사람은 노는 회사가 된다.

리뷰는 치열하게 해야 한다. 리뷰에 참여를 했다는 의미는 공동책임을 진다는 의미다. 고참 개발자가 될수록 다른 사람의 문서나 소스코드 리뷰를 더 많이 해줘야 한다. 그런 과정을 통해서 개발자는 계속 성장할 것이고 개발자 본인을 자유롭게 한다. 언제든지 현재 업무를 다른 사람에게 넘기고 새로운 일을 할 수 있도록 해준다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

Image by http://www.lab-initio.com

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든 서비스든 국제화, 지역화에 실패하여 해외 시장에서 실패하는 경우가 매우 많다. 그럼 소프트웨어 회사들, 개발자들이 흔히 하는 실수에는 어떤 것이 있는지 알아보자. 실수를 알아보는 것은 같은 실수를 하지 않도록 교훈을 준다.

먼저 소프트웨어 국제화, 지역화를 하는데 있어서 기술적인 목표를 알아보자. 비즈니스적인 목표는 개발자들이 크게 상관할 바는 아니지만 기술적인 목표는 잘 알아야 흔들림 없이 개발을 할 수 있다.

첫 번째 목표는 국제화, 지역화 품질이다. 해당 지역, 국가에서 받아들여 질만해야 한다. 어색한 번역 외에도 날짜, 숫자, 화폐, 단수/복수, 어순, 쓰기 방향, 키보드배치, 폰트, 띄어쓰기 여부, 쉼표, 온도, 문장정렬, 이름, 주소, 색깔의 의미, 섬머타임, 종이 크기 등 지역, 언어별로 신경을 써야 한다. 소프트웨어마다 신경을 써야 하는 범위가 다르고 나라마다 받아들이는 정도도 다르다. 첫술에 이 모든 것을 다 처리하기는 어렵고 앞으로 중요한 순서대로 자세히 알아보려고 한다.

두 번째 목표는 생산성이다. 국제화, 지역화를 위해서 너무 많은 시간과 비용이 들어간다거나 이를 유지하기 위해서 많은 부담이 되면 실패다. 특히, 번역은 소프트웨어가 업그레이드 될 때마다 계속 변하는데 번거로운 수동 프로세스로 진행을 하면 비용도 많이 들뿐더러 실수로 인한 버그가 발생하게 된다. 또한 국제화, 지역화 아키텍처를 잘못 만들면 돌이킬 수 없는 비효율의 구렁텅이로 빠지게 된다. 아키텍처와 프로세스에 대해서도 앞으로 다루겠다.

그럼 많은 소프트웨어 회사들이 흔히 빠지는 실수는 어떤 것이 있나 알아보자. 우리는 이런 함정을 피해 다녀야 한다.

첫째, 일단 한국어 버전을 먼저 만들고 나중에 국제화, 지역화를 적용한다.

의도했던 의도하지 않았던 이런 회사는 매우 많다. 혼자서 만드는 아주 작은 소프트웨어라면 어떻게 해도 다 되지만 중간 규모 이상의 소프트웨어를 나중에 국제화하는 것은 다 지어서 아파트에 주민들이 살고 있는 상황에서 리모델링을 하는 격이다. 제대로 국제화가 되지도 않고 비용도 10배 이상 많이 들어간다.

둘째, 번역이 전부인줄 알고 번역만 한다.

경영자들은 아주 쉽게 개발자에게 “영어 버전 만들어”, “독일어 버전 만들어” 이렇게 얘기를 한다. 물론 이 말은 정확한 표현도 아니다. 이 시리즈를 계속 읽다 보면 왜 이렇게 말하면 안 되는지 알게 된다. 번역은 소프트웨어 국제화 시 고려해야 할 200가지 중에서 한가지일 뿐이다. 200가지 전부를 완벽하게 지원하는 것은 어떠한 소프트웨어라도 불가능하지만 그중 몇 가지는 꼭 신경을 써야 한다.

셋째, 해외 버전을 별도로 만드는 것이다.

현재 한국어버전 소프트웨어 밖에 없는 경영자가 어느 날 갑자기 “한달 안에 일본어 버전을 만들어”라고 강요를 하면 개발자들이 흔히 하는 선택은 소스코드를 그대로 복사해서 소스코드의 한국어 부분을 전부 일본어로 바꾸는 것이다. 이 방법은 가장 빠른 방법이지만 가장 느리다. 첫 버전은 가장 빠르지만 점점 느려진다. 소스코드를 수정할 때마다 두 소스코드를 모두 고쳐야 한다. 이 와중에 “독일어 버전도 만들어”라고 하면 개발자는 앞이 캄캄해진다. 첫번째 소스코드가 복사된 순간 “지옥문”을 연 것이다. 무식한 경영진을 탓해야 하지만 그렇다고 소스코드를 복사한 개발자도 똑 같은 책임이 있다.

이런 실수는 거대기업을 무너뜨리는 결과를 낳기도 한다.

넷째, 국제화, 지역화 기능을 모두 직접 구현하는 것이다.

이는 자동차를 만들라고 했더니 타이어도 직접 제작하고 유리를 녹여서 유리창도 만들고 에어백도 직접 생산하는 꼴이다. 자동차를 제대로 만드는 방법은 설계를 잘하고 핵심 부품만 우리가 만들고 수많은 부품은 사다가 조립하고 것이다. 그런데 많은 개발자들은 그런 부품이 시장에 있는지도 모르고 직접 만들곤 한다. 물론 엉터리다. 수십 년간 진화해온 전문 부품을 개발자가 며칠 동안 흉내 낼 수 있겠는가? 특히 메시지 번역관련 라이브러리는 많이들 직접 만들어 쓰는데 필자가 수십 가지 사례를 봐왔지만 제대로 만들어서 쓰고 있는 사례는 0 건이었다. 그 외에도 날짜함수, 숫자함수를 직접 만들어서 낑낑대며 고생하는 개발자들도 많이 봐왔다. 국제화, 지역화 기능은 표준이 있으며 직접 구현해야 하는 것도 있지만 상당수는 라이브러리를 이용하거나 OS에 이미 포함된 기능을 써야 한다.

다섯째, 한국어 코드체계를 기반으로 개발을 한다.

한국어 버전을 먼저 만든 경우 흔히 저지르는 실수인데 한국어 인코딩인 “EUC-KR”로 DB나 파일을 저장할 경우 중국어, 일본어나 다른 언어를 저장하려고 할 경우 글자들이 깨지게 된다. 영어까지는 저장하는데 문제가 없어서 무신경하게 지나가곤 한다. “EUC-KR”은 전세계 모든 글자를 담을 수가 없다. 제품이든 서비스든 일단 “EUC-KR”기반으로 소프트웨어를 개발하면 나중에 유니코드 기반으로 소프트웨어를 변경하기는 매우 어렵다. 데이터를 변환해야 하며 모든 기능을 다시 다 테스트 해야 한다. 엄두가 나지 않는 일인 경우가 많다.

여섯째, 우리의 기준으로 외국을 이해하는 것이다.

우리나라가 이러하니 다른 나라도 이럴 것이다라고 착각을 하는 경우다. 우리가 “.”을 소수점으로 사용하니 다른 나라도 그럴 것이다. 단어 사이에는 띄어쓰기를 할 것이다. 종이는 다 A4용지를 사용할 것이다. 하지만 전세계에는 수많은 다른 문화가 있다. 물론 완벽하게 이 모든 문화를 지원할 수는 없지만 일단 다르다는 의심을 가지고 시작해야 한다. 그 중에서 중요한 것들은 지원을 해야 한다.

그럼 어떻게 해야 할까? 반대로 하면 된다. 처음부터 국제화, 지역화 전략을 가지고 아키텍처를 구성해야 하며 하나의 소스코드를 유지해야 하고 잘 개발된 표준과 라이브러리를 이용해서 유니코드를 기반으로 만들어야 한다. 

혹시 경영자가 당장 외국 버전을 턱도 없이 짧은 시간 내에 만들어 내라고 한다면 “그 시간 안에는 안됩니다. 아키텍처를 제대로 구성해서 제대로 만들려면 시간이 더 필요합니다.”라고 주장할 용기가 있어야한다. 이런 것이 씨도 안 먹히는 조직문화를 가진 회사도 많지만 이는 경영자가 시켰다고 6개월 후면 무너질 것을 알면서도 다리를 만드는 것도 같다. 누구의 책임이 더 클까? 생각해볼 문제다. 모든 것을 경영자 등 외부의 탓으로 돌리는 것은 경계해야 할 자세다.

필자는 수십개의 회사를 직접적으로 또 간접적으로는 더 많은 회사의 상황을 직접 봐왔고 이런 어설픈 국제화 적용으로 망해가는 회사를 봐왔기 때문에 이 시리즈를 시작하게 된 것이다. 나는 지식과 정보, 경험, 노하우을 전하겠지만 이것이 얼마나 도움이 될지는 독자의 몫이다.

이 글은 네이버포스트에 게재한 글입니다.

나쁜 프로그래머가 되는 18가지 방법

소프트웨어 개발자는 끊임없이 변화하면서 성장한다. 스스로 길을 잘 찾아서 성장하는 경우도 있고, 좋은 환경에서 개발을 하다 보니 자연스럽게 실력이 향상되기도 한다. 하지만 열악한 환경에서 열심히 일만하다가 개발자로서의 실력은 점점 잃어가는 경우도 있다. 아무리 사회가 어떻고, 회사가 열악하다고 불평을 해봤자 남는 것은 자신의 개발자로서의 실력밖에 없다. 

이번 글에서 나쁜 프로그래머가되는 18가지 방법을 소개한다. 물론 본의 아니게 주변의 환경이 나를 이렇게내모는 경우도 있지만 이를 반대로 해보는 노력을 해보자. 내가 대단한 사람이라서 이런 얘기를 하는 것은 결코 아니다. 나도 독자들과 똑같은 개발자로서 18가지 중에서 잘 안되는 항목도 있다. 단지 20년 넘게 개발을 하면서 느끼는 바를 공유하고자 함이다. 

1. 익숙한 기술만 고집한다
대부분의 사람들은 변화를 싫어한다. 익숙한 것을 사용할 때 업무의 효율도 높다. 하지만 지식노동자인 개발자는 익숙한 기술만 고집한다면 한계에 다다른다. 물론 환경이 그렇게 만들기도 하고, 다른 분야의 기술을 익힐 만한 시간과 여유가 없는 경우도 많다. 그러다 보면 새로운 기술이 필요한 상황에서도 익숙한 기술을 고집하는 고집쟁이가 되기도한다. 

2. 공유를위해 노력하지 않는다
현재 내가 하고 있는 일은 나만 안다. 내가 퇴사하면 당장 이 일은 마비된다. 지금은 내가 하는 일에 다들 관심들이 별로 없지만 내가 없는 빈자리는 매우 클 것이다. 내 업무에 관련된 지식의 90%는 내 머리속에 있다. 주변의 다른 개발자들도 비슷한 상황인데 굳이 내가 깃발들고 공유를 위해 나설 필요가 있을까?  

3. 후배에게 시키지 않고 직접 처리하는 것이 속편하다
후배들이 많이 있지만 실력도 부족하고 일을 시키면 답답하다. 내가 하면 한시간이면 할 수 있는 일을 신입사원을 시키면 하루종일해도 못끝낼 뿐만 아니라 신입사원이 해놓은 것을 검토하고 고치고 가르치는데 몇시간이 소모된다. 그러니 차라리 내가 빨리 끝내버리는 것이 낫다. 그래서 우리 회사는 신입 개발자보다 고참 개발자가 훨씬 바쁘다. 

4. 후배나 동료들이 작성한 소스코드를 봐주지 않는다
회사에서 코드리뷰를 하라고는 하는데, 내 할 일이 바빠서 다른 사람 코드를 봐줄 시간이 없다. 나 뿐만 아니라 다들 이런 상황이다 보니 코드리뷰는 유야무야되었다. 과거에도 코드리뷰를 몇번해 봤지만 바쁜 와중에 잠깐시간내서 봐주기는 했는데 제대로 봐주지도 못했다. 그냥 코딩 스타일을 가지고 트집을 잡는 정도다. 그러다보니 이제 코드리뷰는 모두들 꺼려 한다. 

5. 남이 내 코드를 보는 것을 꺼려 한다 리뷰가 활성화된 조직에서는 지위고하를 막론하고 소스코드를 리뷰한다. 고참의 소스코드를 신입사원이 리뷰하고 지적할 수도 있다. 이런 거북함이 싫고, 귀찮고, 바쁘다. 내가 작성한 코드는 충분히 정상동작하는데굳이 다른 사람이 내 코드를 보고 지적을할 필요가 있을까? 개발할 시간도 부족하다. 

6. 문서화를 꺼려한다
문서작성은 무조건 싫다. 귀찮기도하고 잘 작성하지도 못한다. 하지만 회사에서 꼭 문서를 만들고 개발을 하라고는 한다. 그러면서 개발시간은 턱없이 부족하게 준다. 그래서 문서는 개발 다 끝나고 형식적으로 문서를 만든다. 한달동안 개발하고 나면 문서는 하룻밤 세워서 대충 문서를 만든다. 물론 이렇게 만든 문서를 나중에는 보지도 않는다. 

7. 커뮤니케이션 스킬 향상에 관심이 없다 
개발자는 프로그래밍을 잘하면 되지 커뮤니케이션 스킬은 별로 중요하지 않다고 생각한다. 개발자가 아닌 다른 사람들은 기술에 대해 잘 이해하지 못해서 기술에 대한 대화를 하기가 어렵다. 설명을 해도 잘 이해 하지 못한다. 난 컴퓨터와의 커뮤니케이션은 잘 되는 것 같다.

8. 책임지고 자신의 일을 마무리하지 않는다. 벌려만 놓는다
나는 개발을 엄청나게 빠르게 한다. 남들이 일주일 걸려서 하는 일도 나는 하루, 이틀이면 해치운다. 대신 완성도는 좀 떨어진다. 동작하도록 만드는 것은 나의 일이지만 귀찮은 버그를 잡는 일은 후배들을 시킨다.나는 새로운 일을 좋아하지 버그 잡는 것은 싫다. 

9. 소스코드가 주석 하나 없이 깨끗하다
항상 주석 같이 읽기 쉬운 소스코드를 주장하면 주석 하나 없이 깨끗하게 코딩을 한다. 하지만 후배들은 주석이 없으면 이해하기 어렵다고 불평이다. 하지만 프로젝트 일정이 항상 너무 촉박해서 소스코드에 주석을적을 시간이 없다. 

10. 소스코드가 읽기 난해하다
내 소스코드는 정상동작하지만 읽기는 어렵다. 워낙 바빠서 소스코드를 읽기 쉽게 정리할 수가 없다. 한 파일이 너무 크기도 하고 함수 이름도 난해하다. 내 소스코드는 최적화가 많이 되어서 짧은 코드로 어려운 로직을 기가 막히게 처리한다. 내 소스코드를 분석해 본 사람은 감탄을 할 것이다. 

11. 낮에는 집중해서 일하지 않고 주로 밤에만 일한다
회사가 낮에는 집중해서 개발할 수 없는 환경이다. 회의도 많고 시끄럽다. 그래서 밤에만 일을 하다 보니, 낮에는 여건이 되도 개발이 잘 안 된다. 밤에만 일하는 것이 완전히 습관이 되었다. 밤에 개발하는 것이 썩나쁘지는 않지만 나이를 먹어 갈수록 내 생활이 없어지는 것 같아서 걱정이다. 

12. 소프트웨어 공학에는 관심이 없다 
오로지 코딩, 코딩, 코딩만 잘하면 된다. 알고리즘, 알고리즘, 알고리즘은 관심이 많다. 소프트웨어공학이란말은 많이 들어 봤지만 이게 뭔지 설명하라고 하면 애매하다. 

13. 영어는 잘못하지만 공부할 시간은 없다 
원래 영어는 잘못했고 당장 영어공부를 따로 하지 않아도 개발을 하는데 큰 문제는 없다. 가끔 인터넷에서개발 관련 검색을 할 때는 주로 한글사이트만 검색한다. 스택오버플로우(Stack overflow)도 영어로 되어 있어서 잘 안 본다. 외국 소프트웨어 회사에 취업을 하고 싶어도 영어 때문에 포기했다. 

14. 기초, 원리는 잘 모르고 응용만 하려고 한다
시스템의 원리나 깊은 지식은 잘 모른다. 필요한 알고리즘이 있어도 원리는 잘 모르지만 인터넷에서 다운받아 그냥 사용하는 데는 큰 지장이 없다. 바빠서 따로 공부할 시간은 없다. 학교 다닐 때 전공수업 공부 열심히 할 걸 그랬다. 

15. 카피&패이스트(Copy & Paste)는 나의 무기 
소스코드 복사하는 것이 일상이다. 다른 프로젝트에 비슷한 기능이 있으면 복사해서 사용한다. 공통모듈을만들려면 여러 사람하고 얘기하고 조율을 해야 하는데 시간도 없고 내가 깃발들고 나서기는 싫다. 복사가 훨씬 빠르다. 소스코드를 복사해서 써도 지적하는 사람이 없다. 

16. 수학을 못한다. 관심도 별로 없다 
학교다닐 때부터 수학은 관심이 없었다. 잘 하지도 못한다. 소프트웨어를 개발하는데 수학이 왜 필요한가? 코딩만 잘하면 되지. 어려운 알고리즘은 인터넷을 조금만 뒤지면 라이브러리가 다 있다. 

17. 변변한 취미가 하나도 없다 
지난번 건강검진에서 의사가 술을 줄이고 운동을 하라고 했지만 매일 야근에 운동은 꿈도 못꾼다. 그나마 가끔 시간이 날 때 친구, 동료들과 술을 마시는 것이 유일한 낙이다. 숙취 때문에 다음날 일은 망친다. 

18. 개발밖에 모른다
회사가 어떻게 돌아가는지 잘모른다. 회사의 전략이나 경영 상황은 잘 모른다. 그런데 관심을 가질 시간이 별로 없다. 나는 회사일 신경 안 쓰고 내가 좋아하는 개발이나 평생하면 좋겠다. 

나는 소프트웨어 개발자는 참 좋은 직업이라고 생각한다. 물론 본인이 일 자체를 즐긴다면 정말 좋다. 말들도 많지만 대우도 그리 나쁘지 않고 성취도도 높다. 하지만 열악한 환경에서 일하는 수많은 개발자들은 그렇게 느끼지 못하고 있다. 물론 좋은 환경에서 일한다면 만족도도 높아지겠지만 개발자가 오랫동안 즐겁게일하는데 제일 중요한 것은 본인 스스로의 실력이다. 나쁜 개발자가 되는 방법을 한가지씩 지워가면서 좋은 개발자가 되는 노력을 해보자.

이 글은 ZDNet Korea에 기고한 글입니다.

야근, “악의 균형”

어떤 경영자는 “우리 회사 개발실은 밤이나 주말이나 불이 켜져 있다”고 자랑을 한다. 6개월간 개발자들이 집에도 못 들어가면서 프로젝트를 하고 있는 것을 자랑스럽게 얘기하기도 한다. 오랜 야근으로 이혼에 이르게 된 개발자를 에피소드로 소개하기도 한다. 많은 경영자들은 야근이 개발자들의 열정을 대변해준다고 생각한다.

나도 수년간 자발적으로 하루에 14시간 이상 개발을 한 적이 있다. 단기간이거나 자발적이 초과근무는 효과가 있지만 장기적이거나 강요된 야근은 효과가 점점 떨어져서 마이너스 효과가 난다. 경영자들은 야근은 곧 열정의 결과라고 생각하곤 하지만 강요된 열정은 오래가지 못한다. 경영자의 희망사항일 뿐이다.

개발자의 야근은 우리나라 소프트웨어 산업의 큰 이슈다. 과도한 야근은 직업의 질을 떨어뜨리고 뛰어난 인재들을 소프트웨어 업계로 들어오는 것을 가로막고 있다. 또한 이미 소프트웨어 업계에서 일하는 인재들도 다른 업계로 떠나게 만들거나 개발 일을 때려 치우고 관리자나 다른 일을 찾게 만든다.

그럼 소프트웨어 업계에서도 유난히 더 야근이 많은 이유는 무엇일까? 일반적으로 다른 산업계의 야근의 첫 번째 이유는 “생산성”이 낮기 때문이다. 생산성이 낮기 때문에 임금이 낮다. 경영자는 부족한 생산성을 채우기 위해서 야근을 드라이브가 하고 근로자는 야근 수당을 받아 낮은 임금을 보충하기 위해서 야근을 한다. 자동차 공장에서는 야근을 하면 야근 수당이 나온다. 낮은 생산성에 따른 저임금은 야근과 주말근무를 통해서 보충한다. 이를 통해서 선진국과의 임금의 차이를 좁히는 “악의 균형”이다.

하지만 소프트웨어 업계에서는 야근을 한다고 야근 수당을 더 주는 경우는 드물다. 보통 개발자는 야근을 통해서 임금을 더 받는 것도 아니고 그냥 야간을 강요 받는 경우가 많다. 그래서 경영자는 야근을 통해 부족한 생산성을 야근을 통해서 보충했다고 생각할지 몰라도 개발자 입장에서는 아무런 이익도 없다. 소프트웨어는 자동차 공장과 달라서 야근에 따른 생산성 향상을 측정하기가 매우 어렵기 때문에 시간대로 야근 수당을 지급하기도 어렵다. 그래서 대부분은 야근 수당을 주지 않는다. 이러니 경영자 입장에서는 개발자의 야근을 아주 손쉬운 수단으로 생각한다.

이는 육체노동 산업과 지식 노동 산업의 차이 때문에 발생한다. 특히 소프트웨어는 창의적인 지식 산업이기 때문에 야근이 결정적으로 생산성을 올려 주지는 않는다. 그 이유는 여러 가지가 있다. 한 시간에 자동차를 한대 만들면 두 시간이면 두대를 만든다. 천재가 와서 열대는 못 만든다. 하지만 소프트웨어는 개발자에 따라서 수십배 이상의 차이를 보인다. 창의적인 아이디어와 예술적인 생각이 중요한 경우에는 수백배 차이가 날 수도 있다. 이렇게 소프트웨어는 뛰어난 인재가 더욱 높은 생산성을 발휘하는데 낮은 임금을 선호하는 많은 경영진 때문에 뛰어난 인재는 오히려 제대로 대접을 못 받는다. 

그럼 생산성이 낮은 이유는 무엇일까? 물론 생산성이 높은 회사도 있다. 평균적인 수치를 말하는 것이다.

무엇이 원인이고 무엇이 결과인지 알 수 없이 이미 악순환의 고리에 들어가 있는 회사가 많다. 경영진들이 소프트웨어에 대한 이해가 부족한 상태에서 단기적인 영업 드라이브 정책으로 촉박한 프로젝트에만 매달리면 장기적인 기술 로드맵이나 기술공유는 어려워지고 호떡집에 불 끄듯이 일단 개발을 해 놓으면 이렇게 뱉어 놓은 코드들은 회사의 미래를 더욱 복잡하게 만들고 생산성은 더욱 떨어지게 만든다. 그러면 또 야근에 매달리고, 우수한 인재는 회사를 떠나고 낮은 임금의 개발자들이 투입되면 생산성은 더욱 떨어지게 된다. 그러면 더욱 야근에 내몰리게 된다. 

경영진들의 근거 없는 야근에 대한 믿음도 한몫 한다. 밤이나 주말에 사무실 순찰을 돌아서 개발자들이 자리에 없고 텅 비어 있으면 낮은 평가를 주거나 팀장을 문책하기도 한다. 이런 분위기를 만들면 개발자들은 어차피 야근을 해야 하는 상황이라면 낮에는 설렁설렁 체력을 비축하고 밤에 집중해서 일하기도 한다. 이렇게 개발자들을 평가하는 잘못된 잣대는 개발 문화를 더욱 꼬이게 만든다.

해결책은 악순환을 선순환으로 바꾸는 것이다. 이미 악순환의 고리에 깊숙이 빠진 회사는 빠져 나오기가 쉽지는 않다. 하지만 악순환의 결말은 뻔하기 때문에 빠져 나와야 살 수 있다. 악순환을 선순환으로 바꾸는 방법은 소프트웨어 문화를 바꾸고 소프트웨어 공학을 도입하는 것이다. 소프트웨어 문화나 소프트웨어 공학은 모두 소프트웨어를 빨리 개발하고 생산성을 높이는데 집중되어 있기 때문이다. 스펙을 제대로 쓰고, 설계를 하고, 소스코드 관리를 제대로 하고, 이슈관리를 하는 이유는 오직 하나, 소프트웨어를 빨리 개발하기 위한 것이다. 효과적인 개발 프로세스를 만들고 소스코드를 리뷰하는 목적도 생산성 증가다. 직원들간에 정보를 공유하고 전문적인 조직, 수평적인 조직을 만드는 이유도 생산성을 증가하기 위한 것이다.

생산성이 증가해야 임금도 오르고 야근도 줄어들고 신기술도 익히고 창의력을 발휘할 여가 생긴다. 그러면 우수한 인재가 더 많이 유입되고 생산성은 더욱 오르는 선순환이 될 것이다. 여기서 전제조건은 경영진이 소프트웨어를 이해하려고 노력하고 소프트웨어 문화와 소프트웨어 공학에 투자를 해야 한다는 것이다.

물론 현재 회사의 수행 능력을 고려하여 적절한 변화와 혁신을 꾸준히 추진해도 수년이 걸리는 일다. 그래도 포기를 할 수는 없다. 포기는 곧 미래를 포기하는 것과 같기 때문이다. 

이글은 ZDNet Korea에 기고한 칼럼입니다. 

외국 개발자들이 보기에 군대 같은 한국 회사

“A기업은 좀비월드 같다. 직원들이 아무 생각 없이 회사를 떠돈다.”

“B기업 직원들은 불만을 말하지 않는다. 근무 내내 감옥에 있는 느낌이다.”

“C기업은 군대다. 상사가 말하면 무조건 따라야 한다. 이유를 묻거나 질문할 수도 없다.”

얼마 전 모 신문 기사에 나온 외국인들이 한국의 기업들에 대해 느낀 점을 얘기한 것이다.

국내에서 소프트웨어 개발에 한계를 느낀 대기업들은 해외에 여러 형태의 소프트웨어 조직을 설립하고 현지의 외국인 개발자를 채용하고 있다. 국내 개발자들의 소프트웨어 개발 실력이 떨어져서 소프트웨어를 제대로 개발하지 못했다고 착각하고 있는 것이 아닌가 생각된다.

그런데 우리나라 회사들의 조직 문화와 분위기는 외국에도 이미 소문이 많이 났다. 우리나라 기업문화 자체가 나쁘다고 볼 수는 없으나 소프트웨어 개발자들이 선호하는 문화는 아니다. 소프트웨어 전문가라고 하더라도 이런 조직 문화와 개발 환경에서 소프트웨어를 제대로 개발하기는 어렵다. 그래서 우리나라 회사에서 설립한 외국의 현지 소프트웨어 개발 센터에 들어가기를 꺼려하는 현상이 일어나는 것이다.

이렇게 소프트웨어 개발에 불리한 기업문화를 가지게 된 이유는 여러 가지가 있지만 중요한 이유 중 하나가 우리나라 회사의 경영진들은 소프트웨어 대한 개념이 없기 때문이다. 여기에 상명하복의 “까라면 깐다”는 조직 문화가 더해져서 소프트웨어 산업을 망치는 주범의 역할을 하고 있다.

A사의 사례다. 회사의 사활이 걸리는 매우 중요한 프로젝트가 있었다. 개발자들이 대충 예상을 해도1년반 이상 걸리는 프로젝트였다. 하지만 소프트웨어에 대한 개념이 없는 경영진들은 자신의 재임기간에 성과를 내기 위해서 6개월안에 완성하라고 했다. 기업의 분위기가 까라면 까야 하기 때문에 아키텍처가 완전히 망가지는 것을 감수하고 6개월 안에 완수를 했다. 하지만 그로 인한 피해는 심각했다. 제대로 아키텍처를 완전히 수정해서 개발을 했으면 기간과 비용이 2배 이상 들었지만, 급하게 6개월 안에 완성함으로써 미래에 드는 비용은 수십 배가 증가 했으며 이로 인해서 회사는 망하는 길로 들어섰다.

프로젝트를 완료했을 당시에는 경영진은 1년이 넘게 걸릴 프로젝트를 자신의 리더쉽과 독려로 6개월안에 완성했다는 것을 자랑하지만 이로 인해서 회사가 망하는 길로 들어섰다는 것은 전혀 몰랐다.

개발팀의 아키텍처에 대한 의견은 치기 어린 엄살로 간주하고 탱크같이 밀어붙이는 경영진을 능력 있는 경영진으로 간주하는 것이 현실이다. 이런 무모한 독선은 단기적인 효과는 거둘 수 있어도 미래에는 그로 인해 얻은 이익의 몇 배의 비용을 지불하게 되어 있다.

B사의 경영진은 개발자들이 6개월째 집에도 못 들어가고 프로젝트를 하고 있는 것을 자랑스럽게 얘기한다. 야근을 하면 야근 한 시간만큼 생산성이 비례해서 늘어난다는 착각에 빠져 있는 경영진은 정말로 많다. 야근 강요는 소프트웨어 개발을 지식 산업이 아닌 육체 노동 산업으로 내모는 결과를 가져온다. 야근은 대출과 같아서 단기적인 효과는 있어도 장기적으로는 생산성이 더 떨어진다. 자발적인 야근은 효과가 크지만 강압적인 야근은 생산성과 창의력을 점점 낮추게 된다. 지금도 암암리에 야근을 많이 해야지만 인정 받는 분위기 때문에 어쩔 수 없이 경영진의 기대에 맞추기 위해서 수많은 개발자들이 야근을 하고 있다.

야근은 생산성 저하 외에도 개인 생활과 가족과의 시간을 희생해야 하기 때문에 일을 위해 가족과의 시간을 희생을 감수하는 우리나라 개발자에 비해서 외국인 개발자들에게는 꺼려지는 문화가 아닐 수 없다.

국내의 한 회사에서는 간부들에게는 제품의 아키텍처와 디자인에 절대로 간섭하지 못하도록 최고 경영자의 지시가 있었다. 회사 초창기에는 간부들의 통찰력이 어느 정도 통했지만 회사가 커지고 제품이 복잡해지면서 더 이상 간부들의 간섭은 통하지 않고 오히려 망치는 길이라는 것을 경험적으로 깨달은 것이다.

우리나라 대기업의 경영진들은 자신들이 척박한 환경에서 그 짧은 시간에 기적적으로 회사를 성장 시켰듯이 소프트웨어 역량도 순식간에 따라 잡을 수 있다고 생각한다. 하지만 이는 대단한 착각이다.언뜻 보기에는 간단해 보이는 소프트웨어가 인류가 만들어낸 지식 산업 중에서 가장 복잡하고 어렵다는 것이다.

그 동안 기존 산업에서 익혀온 성공 방정식을 소프트웨어에도 적용하다 보니 잠깐의 반짝 성공은 있었을지 몰라도 급한 한발 내딪음으로 인해서 두발 더 뒤쳐지게 되었다.

외국인 개발자들이 꺼려하는 이러한 환경은 국내 개발자들도 똑같이 꺼려하는 환경이다. 단지 국내에 태어났기 때문에 다른 선택이 어려워 그런 환경이라도 꾹 참고 일을 하고 있는 것이다. 그래서 요즘은 처음부터 외국 기업을 찾는 개발자자도 많다.

외국인들을 위해서 외국인에게 인기가 있는 회사를 무조건 만들라는 것은 아니다. 외국인 개발자에게 인기가 없는 회사가 소프트웨어 개발에 불리한 환경이라는 것이다. 외국인 개발자들에게 인기가 있는 회사가 된다면 국내 개발자들도 일하기 좋은 환경이 될 뿐만 아니라 소프트웨어 산업 전체의 경쟁력도 증가할 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

나는 한달 동안 휴가를 갈 수 있을까?

내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까? 각자 한번 상상을 해보자.

내가 있던 없던 상관없이 회사는 잘 돌아갈까? 아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까? 내가 없으면 회사가 잘 안 돌아가도 문제지만 내가 있으나 없으나 회사가 아무 일 없이 잘돌아가도 불안하다. 혹시 내가 없어도 되는 사람이 아닌가 걱정이 되기도 한다.

“유지보수가 어렵게 코딩하는 방법” 이란 책도 있다. 원제는 “How to write unmaintainable code : Ensure a job for life ;-) This essay is a joke!”이다. 이 책은 조크이지만 내가 없으면 유지보수가 몇배, 몇십배 어려워지는 온갖 다양한 방법을 소개하고 있다. 사실 본인도 유지보수가 어려워지는 방법들이다.

몇 년에 한번씩 강제로 한달 동안 휴가를 가야 하는 회사가 있다. 휴가기간 한달 동안 원격지에서 일을할 수 있다는 것이 아니다. 진짜 휴가를 가야 한다. 이런 강제 휴가제도를 만든 이유는 어느 직원이던지 그 직원이 없어도 회사가 잘 돌아가야 하기 때문이다. 업무의 특수성 때문에 한달 동안 자리를 비울수 없는 직원이 있다면 회사의 조직을 바꾸던지 프로세스를 바꿔서 다른 사람으로 대체가 가능하거나보완이 가능하도록 한다. 누구든지 한달간 휴가를 떠나도 아무런 문제가 없이 해놔야 한다.

이런 회사에서는 직원들이 언제든지 짤릴 수 있다는 불안감을 가져야 할까?

가상의 이야기가 있다. 원자력 발전소에서 일하는 홍길동은 절대로 3일 이상 휴가를 갈 수 없다. 홍길동은 오랜 노하우로 적절하게 원자로의 온도를 조절하는 특수한 능력을 가지고 있고 홍길동 외에는 그런 기술이 없다고 하자. 홍길동은 수동으로 온도 제어장치 조절이 가능한데 자동 처리 시스템을 갖추려면 엄청난 비용과 많은 추가 인력이 필요하다고 한다. 회사 입장에서는 큰 비용을 투자 하는 것보다홍길동만 잘 유지하면 적은 비용으로 발전소 운영이 가능하고 홍길동은 자신이 없으면 발전소가 돌아가지 않는 상황에 자부심을 가지고 있다. 하지만 홍길동은 격무에 시달려서 회사를 그만두거나 불의의교통사고를 당할 수도 있다. 옆 나라의 발전소에서 더 높은 연봉으로 데려갈 수도 있다.

나는 강연이나 세미나를 할 때 자주 묻는다. “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”. 그러면 거의 대부분 손을 드는 사람이 없다. 실제로 퇴사를 해도 문제가 없는 사람이 없을 수도 있고 다른 사람들 눈치를 보기도 한다.

반대로 “그럼 당장 퇴사하면 회사가 안 돌아가는 사람” 손을 들라고 하면 몇 사람들이 당당하게 손을번쩍 든다. 몇 사람은 떠밀려서 손을 든다. 그러면서 주변에서는 웅성웅성 말들이 많아진다. 약간의 빈소적인 말도 들려온다. 대부분의 회사에서 공통적인 현상이다.

우리 주변의 소프트웨어 회사들 중에는 개발자 한두명만 퇴사를 해도 큰 영향을 받는 회사가 많다. 회사의 경영진은 문서화도 잘되어 있고 공유도 잘 되어 있어서 문제 없다고 하는 경우도 있지만 속을 들여다 보면 유지보수에 별 쓸모도 없는 문서에 공유는 형식적으로 되어 있어서 실제로는 큰 문제지만“쉬쉬” 하는 경우가 많다. 개발자들도 자신이 없을 때 회사가 잘 안 돌아가는 상황을 그렇게 나쁘게만보지 않기 때문에 별 이슈로 생각하지 않는다.

이러한 현상 때문에 아버지가 돌아가셨는데 상중에도 회사를 나와서 일을 했다는 경우를 들기도 하고신혼여행도 제대로 못가는 경우도 발생한다.

그럼 이런 현상이 회사에는 불리하지만 개발자에게는 유리한 현상일까? 단기적으로는 그렇게 생각할수 있지만 장기적으로는 얘기가 완전히 달라진다.

나는 “당장 퇴사하면 회사가 안 돌아가는 사람”은 하루 빨리 정리를 해야 하고, “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”은 회사에 꼭 필요한 사람이라고 얘기한다. “당장 퇴사하면 회사가 안돌아가는 사람”이 많다면 회사가 갑자기 망해도 이상하지 않은 상황이다. 이렇게 망한 회사들은 이런이유 때문에 망한 것이라는 것을 알아채기는 쉽지 않다.

“지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람” 중에는 정말로 하는 일이 없어서 있으나 마나 한사람이 있을 수도 있지만 그건 주제에서 벗어난 얘기고 대부분 그 동안 해왔던 일들이 문서화가 잘 되어 있고, 공유가 잘되어 있으며 다른 사람이 이어 받아서 처리하는데 문제가 없는 경우다. 이런 사람은회사의 미래의 프로젝트를 위해서 꼭 필요한 사람이다.

반대의 경우는 그 동안 저질러 놓은 일이 많고 자신이 아니면 유지가 안 된다. 뭘 하나 해결하려고 해도 원 개발자에게 물어봐야 하고, 다른 사람들은 시스템에 대해서 이해하기도 어렵고 원 개발자가 한두 시간이면 뚝딱 해결할 수 있는 것을 유지보수 개발자에게 시키면 며칠이 걸려도 해결이 어렵고, 해결을 했다고 해도 또 다른 문제를 만들어 냈을까봐 두렵다. 회사입장에서는 큰 리스크가 아닐 수 없없다. 하지만 회사에서는 이런 개발자를 핵심 개발자라고 착각하고 질질 끌려 다닌다.

물론 개발자가 일부러 이런 경우는 흔치 않다. 회사의 문화, 프로세스가 엉망이니 그냥 열심히 하던대로 개발을 하다 보면 이런 현상은 십중팔구 일어난다. 특히나 개발 능력이 뛰어난 개발자들에게서이런 현상이 더 잘 일어난다. 혼자서 많은 양의 코딩을 해내지만 같이 공유하고 리뷰를 해줄 개발자가없고, 혼자서 제품 하나를 뚝딱 만들어도 유지보수에서 발을 빼기 어렵게 된다. 일부러 유지보수가 어렵게 코딩하는 사람은 없겠지만 작성해놓은 코드를 보면 “유지보수가 어렵게 코딩하는 방법” 이란 책을 공부한 사람처럼 코딩하는 경우도 있다.

이렇게 자신의 과거 업무에 발목이 잡혀있는 개발자들은 앞으로 나아가면서 성장하기 어렵다. 회사의미래 프로젝트, 좀더 어렵고 재미있는 일을 못하게 된다. 새로운 기술이나 지식을 익힐 기회는 점점 줄어들고 매일 하던 반복적인 유지보수에 매달리거나 과거에 해놓은 일의 기억을 헤집는 일을 주로 하게된다. 자신의 과거의 업무에서 자유로워지는 일은 자신의 가치를 좀더 높이는 일이다.

물론 우리나라 회사에서는 이런 것이 통하지 않는다고 주장하는 사람도 있을 것이다. 개발자를 부품으로만 생각하는 회사는 개발자가 없어도 문제없게 만들어 놓은 개발자는 언제든지 자를 수 있다. 실제이런 회사도 많이 있고 이런 회사에서 일하는 개발자라면 “유지보수가 어렵게 코딩하는 방법”을 잘 공부하기를 바란다.

개발자가 자신이 없어도 회사가 문제 없이 돌아가게 하려면 공유를 잘 해야 한다. 문화적으로 성숙되고 프로세스를 잘 갖춘 회사라면 모든 개발업무가 진행되면서 자연스럽게 공유가 되는 시스템을 갖추고 있다. 중간 중간 리뷰 과정을 다 거치고 문서화가 되며 지식과 경험이 자연스럽게 여러 사람과 공유가 된다. 이런 프로세스를 뒷받침할 기반시스템도 적절히 갖추고 있다. 공유를 위한 공유가 아니기 때문에 훨씬 자연스럽고 부담도 없다.

자신은 어떤가 생각을 해보자. 한달간 휴가를 갈 수 있을까? 회사의 모든 직원이 각자 한달간 휴가를갈 수 있을까? 그렇지 않다면 무엇을 바꿔야 할지 생각해보자.