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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 

1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코드로 통일되는 시기가 올 수도 있겠지만 아직까지는 한국어만 해도 여러 문자세트와 인코딩이 공존을 하고 있고 소프트웨어 개발자에게는 여간 귀찮은 일이 아닐 수 없다. 이에 대해서 잘 알고 있고 경험이 많은 개발자라면 별 문제가 없지만 한국어 문자세트와 인코딩에 대해서 조금 헷갈리는 경우라면 소프트웨어를 개발하면서 수많은 지뢰를 만나게 된다. 그나마 한국어는 중국이나 일본에 비해서는 문자세트와 인코딩의 표준화가 잘되어 있어서 훨씬 수월한 편이라고 할 수 있다.

이제 유니코드가 대세라고 Application을 유니코드를 지원하도록 만든다고 다 해결되는 것은 아니다. 네트워크를 통해서 다른 시스템과 통신을 할 때 다른 인코딩을 사용할 수도 있고, 파일로 저장할 때 다른 형식을 써야 할 때도 많다. 왜냐하면 아직도 수많은 시스템이 유니코드를 지원하지 않고 있고, 우리는 그런 시스템과도 연동을 해야 하기 때문이다.

데이터베이스의 인코딩을 어떤 것을 선택할지도 큰 이슈다. 지금은 누구나 유니코드의 인코딩을 선택하지만 몇 년 전까지만 해도 EUC-KR이나 다른 인코딩을 선택하기도 했다. 이런 경우 시스템의 국제화를 추진하게 되면 심각한 문제에 봉착하게 된다. 데이터베이스 이슈는 추후 별도로 다루도록 하겠다.

우리는 Application을 개발하면서 외부 라이브러리를 사용하기도 한다. 그런데 외부 라이브러리가 유니코드 기반이 아닌 경우도 많다. 그럴 때는 라이브러리를 사용하기 위해서 문자열을 변환해야 하는 복잡한 문제에 봉착하기도 한다. 상황에 따라 다르지만 유니코드와 여러 가지 인코딩이 공존하는 세상에서 개발해야 하는 개발자들은 이런 문제를 겪기도 하고 해결해야 한다는 것을 알아야 한다.

그래서 현재 한국어를 표현하기 위해서 사용되고 있는 문자세트와 인코딩에 대해서 간단하게 집고 가려고 한다. 물론 문자가 깨지는 경우에 이를 해결하는 데는 경험이 훨씬 중요하다. 하지만 문자세트와 인코딩의 지식은 기본으로 필요하다.

(한국어 문자세트와 인코딩 포함 관계)

1. KSC 5601 (문자세트)

한국산업규격 한국어문자집합이다. 공식 명칭은 KS X 1001이다. 1974년 처음 제정되었고 2004년에 마지막 개정이 있었다. 2바이트 부호체계이며 8,836문자를 규정하고 있다. 한글, 숫자, 특수문자, 한자, 로마자, 그리스문자, 키릴문자 등으로 구성되어 있다. 

한글 2,350자와 한자 4,888자를 정의하고 있는데 실제 사용하는 한글과 한자에 비해서는 턱없이 부족한 문제가 있다.

2. EUC-KR (인코딩)

문자세트는 실제 컴퓨터에서 사용하는 코드는 아니다. 컴퓨터에서는 인코딩을 사용하며 EUC-KR은 널리 사용되는 한국어 인코딩 중 하나다. KSC 5601을 그대로 포함하고 있으며 영어 영역은 ASCII를 사용한다. 정확하게는 KS X 1003인데 ASCII라고 알고 있어도 무방하다. EUC-KR은 KSC 5601이 가지고 있는 문제를 그대로 가지고 있다.

3. ISO-2022-KR (인코딩)

지금은 쓸 이유도 없는 인코딩이지만 하위 호환 때문에 가끔 만나게 된다. ISO2022는 원래 둘 이상의 문자집합을 한꺼번에 표현하기 위한 국제 규약이었는데 여기에 한국어를 추가했다. 지금은 상상이 잘 안되지만 과거에는 Email을 전송할 때 7bit로만 전송하던 시절이 있었다. ISO-2022-KR은 8bit를 사용하는 KSC 5601 문자를 7bit로 전환해서 Email를 전송할 수 있게 하였다. 그럼으로써 ISO-2022-KR을 지원하는 Email 클라이언트에서 한국어 Email을 볼 수 있게 되었다. 코드 중간에 0x0e 문자를 만나면 이제부터 한국어라는 뜻이고 0x0f를 만나면 영어로 간주를 한다. 

지금은 Email을 8bit로 전송할 수도 있고, Base64로 인코딩해서 보내는 방법도 있어서 ISO-2022-KR은 쓸 이유가 점점 없어지고 있다. 또한, Email을 아예 유니코드(UTF-8)로 보내는 비율이 점점 늘고 있다. 유니코드로 Email을 보낸다는 의미는 내가 보낸 Email이 전세계 어디서나 문제없이 볼 수 있다는 의미다. 물론 Email 클라이언트가 유니코드를 지원해야 하며 유니코드 폰트가 존재해야 한다. 아직은 모든 시스템이 유니코드의 모든 문자의 폰트를 포함하고 있지 못하다. 이 이슈는 추후 폰트 관련 글에서 따로 다루겠다.

4. CP949 (인코딩)

마이크로소프트에서 사용하는 한국어 코드페이지다. 원래는 KSC5601을 표현하는 코드페이지였으나 KSC5601에 없는 한글 문자가 많아서 8822자의 현대한글을 추가하였다. 이렇게 문자를 새로 추가하다 보니 한국어 코드의 순서가 가나다 순서와는 다르게 뒤죽박죽이 되는 문제가 있다. 하지만 EUC-KR에서는 표현할 수 없는 많은 문자를 표현 할 수 있다. Windows에서 파일로 “똠방각하”를 저장할 때 ANSI 형식 선택해도 KSC5601에 없는 “똠”라를 저장할 수 있는 이유는 Windows는 EUC-KR 대신 CP949를 선택하기 때문이다. 따라서 CP949의 모든 문자를 EUC-KR 인코딩으로 변환할 수는 없다. 이런 변환 과정을 거치면 몇몇 글자는 깨질 수가 있다. OS에 따라서 한국어 문자가 깨지는 상황이 발생했을 때 OS가 어떠한 인코딩을 사용하는지 살펴볼 필요가 있다.

지금은 위 4가지가 아니라면 거의 유니코드일 것이다. 유니코드에 대해서는 추후 자세히 다룰 것이다.

외국에서 팔리는 소프트웨어 만들기 위한 소프트웨어 국제화 (1)

가장 먼저 소프트웨어 국제화에 대한 이야기로 글을 시작하려고 한다.

오래 전부터 소프트웨어 세계에는 국경이 없었다. 거의 모든 사람들은 수십 나라에서 개발된 다국적 소프트웨어를 사용하고 있다. 앱을 하나 개발해서 앱스토어에 올리면 바로 다음날부터 전세계 수십, 수백 나라에서 즉시 사용된다.

이제 소프트웨어 국제화는 소프트웨어 개발자라면 필수적으로 알아야 할 지식이다. 소프트웨어 국제화 전문가가 되기 위해서는 십 수년의 공부와 경험이 필요하지만 최소한의 기본 지식은 갖추도록 하자.

기본적으로 영어권 개발자들이 만든 소프트웨어는 국제화에 대해서 별로 신경을 안 써도 큰 문제 없이 전세계에서 사용되는 경우가 많다. 우리도 영어만 지원하는 소프트웨어를 얼마나 많이 써왔던가? 비단 메시지만 영어로 나오는 것뿐만 아니라 날짜 표기, 이름 표기 등도 우리 문화와는 다르지만 소프트웨어를 사용하는 데는 큰 문제가 없다. 물론 한국어 폰트가 깨지는 등 문제가 있는 경우도 많지만 개발자들은 이런 것은 신경도 안 쓰는 경우가 많다. 우리는 소수 사용자이기 때문이다.

하지만 비 영어권 개발자들이 만든 소프트웨어는 상황이 전혀 다르다. 기본적으로 우리 문화에 맞춰서 개발한 소프트웨어는 영어권뿐만 아니라 우리나라를 제외한 대부분의 나라에서 거부감을 갖게 된다. 그만큼 우리나라 개발자들이 만든 소프트웨어가 전세계로 확산되기는 쉽지 않다. 그러다 보면 전세계 1% 시장이라는 우리나라 소프트웨어 시장만을 대상으로 소프트웨어를 만들게 된다.

100배 큰 시장으로 나가기 위해서는 소프트웨어 국제화를 잘 알아야 한다.

일단 용어부터 알아보자.

첫 번째 용어는 국제화, 영어로는 Internationalization이다. 이 용어는 1985년에 Apple에서 사용하기 시작하였다. 오랫동안 이렇게 긴 영어 단어로 사용되다가 유니코드 컨소시엄에서 i18n이라는 줄임말을 사용하기 시작했다. 사실 정확하게 누가 먼저 사용했는지는 알기 어렵다. "인터네셔널라이제이션"이라는 긴 단어를 발음하다보면 혀가 꼬이기 일쑤다. 그래서 i와 n 사이에 18글자의 알파벳이 있다는 의미로 i18n을 사용하기 시작했다.

i18n은 소프트웨어를 여러 나라 언어와 문화를 지원하기 쉬운 구조로 만드는 것이다. 국제화가 잘된 소프트웨어는 쉽게 여러 나라 언어를 지원할 수 있다. i를 소문자로 쓰는 이유는 대문자로 쓸 경우 L의 소문자와 헷갈리기 때문이다.

두 번째 용어는 지역화, 영어로는 Localization이다. 이 또한 줄여서 L10n이라고 한다. L를 흔히 대문자로 쓰는 이유도 역시 헷갈리지 않게 하기 위함이다. 

L10n은 소프트웨어를 특정 지역의 언어와 문화를 지원하도록 만드는 것이다. 예를 들면 중국어나 일본어를 지원하는 것이다.

전세계 개발자와 회사들은 1980년대부터 본격적으로 소프트웨어 국제화와 지역화에 대해서 연구를 해왔고 그 결과 1991년 유니코드가 탄생을 하였고 수많은 표준이 제정되었다. 그 지식과 정보는 너무나 방대해서 어느 개발자도 모두 알기는 어렵다. 따라서 앞으로 이 중에서 소프트웨어 개발자가 알아야 할 필수적인 내용을 연재하겠다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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