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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

일단 용어부터 알아보자.

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

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

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

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

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

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

나쁜 프로그래머가 되는 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에 기고한 글입니다.

빈 줄도 지워서는 안된다.

SVN을 쓸까? Git를 쓸까? 주제로 얘기를 하면 논쟁이 심하다. 하지만 이보다 더 중요한 것은 SVN이나Git와 상관없이 어떻게 하면 여러 개발자들과 협업이 잘 되도록 코딩을 하느냐다.

많은 개발자들은 혼자서 또는 소수의 인원과 개발을 한다. 또는 여러 명이 개발을 하더라도 자신의 소스코드가 딱 정해져 있어서 혼자 개발하는 경우가 많다. 이러다 보니 협업을 위한 개발에는 별로 관심이 없다. 하지만 협업은 혼자서 할 때도 필요한 것이고 여러 명이 개발할 때는 더욱더 필요하다. 방법을 모르거나 문제를 피해 다니면 개발 효율이 떨어지고 한계를 넘지 못한다.

혼자서 개발을 하더라도 수많은 브랜치가 발생할 수 있고 한두 명끼리는 그럭저럭 개발을 하더라도개발팀이 조금만 커져서 뒤죽박죽이 되곤 한다.

그럼 어떻게 코딩을 하는 것이 좋을까?

첫째, 빈 줄도 고쳐서는 안 된다.

내가 고치고 있는 모든 소스코드는 다른 개발자들도 지금 고치고 있다고 생각해야 한다. 설사 혼자서고치는 소스코드라고 하더라도 습관이 된다. 협업을 하고 있다는 마인드는 꾸준히 유지를 해야 한다. 

빈 줄 뿐만 아니다. Indentation이 맞지 않는다고 고치는 것도 좋지 않다. 괜히 연산자 사이에 보기 좋으라고 빈칸을 추가하는 것도 나쁘다. 무조건 처음에 잘해야 하고 나중에는 그냥 놔두는 것이 낫다.

둘째, 파일 이름을 바꾸지 말아야 한다.

처음에 대충 파일을 만들다 보면 파일이름이 마음에 안 드는 경우가 있다. 그렇다고 파일을 이름 바꾸면 수많은 사람들에게 영향을 준다. Git에서는 파일을 이름 변경을 추적해주는 기능이 있지만 혼란을피할 길을 없다. 처음에 잘 정해야 한다. 

셋째, 함수 이름과 정의를 바꾸지 않아야 한다.

대충 만들어 놓고 자꾸 바꾸는 것은 협업 습관이 없기 때문이다. 그리고 대충 만들고 나중에 수정하는것은 비용이 더 많이 든다. 아주 작은 시스템만 경험해 본 개발자는 이런 방법이 더 빠르다고 주장할지몰라도 큰 시스템에 개발자가 수십 명이라면 얘기가 달라진다. 대충하고 바꾸는 습관이 들어서는 안된다.

넷째, 소스코드를 재배치하지 말아야 한다.

파일의 아래쪽에 있는 함수를 위로 올리고 정리를 하면 소스코드 Merge가 어려워진다. 처음에 잘 생각해서 정하고 나중에는 고치지 말아야 한다. 여러 사람이 동시 소스코드를 정리하면 소스트리는 완전히 뒤죽박죽이 된다.

이미 문제가 발생한 경우 리팩토링이 필요하게 되고 계획을 잘 세워서 시행해야 하고 상당한 비용을 치뤄야 하는 경우도 있다. 이런 경우는 최소화하고 처음부터 제대로 하는 것이 훨씬 낫다.

이 외에도 변수를 어떻게 선언하느냐는 등 협업을 위한 수많은 코딩 노하우들이 있다. 항상 개발은혼자 하는 것이 아니다라는 것을 염두해 두고 개발하는 자세가 필요하다.

물론 위 내용들은 개발자 본인이 처한 환경에 따라서 천차만별로 생각할 수 있다. 혼자 개발하는 사람도 있고 수백명이 개발을 해도 혼자 일하는 것처럼 개발하는 경우도 많다. 수천명이 동시에 개발하는 환경에 있는 개발자도 있다. 

필자는 원칙과 원리에 대해서 얘기를 하는 것이니 원리에 대해서 이해를 해보는 노력을 해보자. 일하는 환경은 언제든지 바뀔 수 있지만 습관은 쉽게 바뀌지 않는다. 좋은 습관을 만들어가는 것은 본인의 몫이다.

55세 개발자가 막내인 개발팀

얼마전 미국 소프트웨어 회사인 P사의 호주 지사에서 일하고 있는 엔지니어를 만나서 얘기를 나눴다. P사는 본사가 캘리포니아에 있고 전체 개발자 수는100여명이다. 그리 크지 않은 회사지만 20년동안 꾸준히 성장을 해왔고, 소프트웨어 개발자라면 알만한 시스템을 개발하는 회사다. 
 
그 회사의 제품군을 알고 있는 사람들은 100여명 밖에 안되는 개발자들이 일하고 있다는 것에 놀랄것이다. 우리나라 소프트웨어 회사라면 20년간 커왔고 전 세계 많은 나라 기업들에서 사용하고 있는 시스템을 만든다면 개발자가 수백명에 육박할 것이다. 하지만 매우 적은 인원으로 효율적으로 개발하고 있다는 것은 놀라운일이다. 그런데 이렇게 효율적인 소프트웨어 회사가 우리나라 밖에는 엄청나게 많다. 
 
P사 제품의 코어엔진을 만드는 팀에는 7명의 개발자가 일하고 있다. 그중 제일 고참이 60세라고 한다. 막내는 55세다. 또 관리자의 나이가 가장 어리다. 60세 개발자는 회사 초창기부터 20년간 근무했다. 대충 짐작해도 35년은 엔지니어로 일하고 있는 것으로 보인다. 비단이 회사에만 이런 할아버지 개발자들이 있는 것은아니다. 개발자 본인이 원하고 실력이 된다면 20년, 30년 원하는 만큼 개발자로 일을할 수 있다. 
 
우리나라에서는 한 분야에서 오랫동안 한가지 제품만 개발하고 있는 개발자들의 걱정이 있다. 다양한 분야를 접하지 못하다 보니 경험이 제한되고 시야가 좁아지고 엔지니어로서의 가치가 떨어지는 것이 아닌가 하는 우려를 한다. 실제로 금융분야에서 10여년 일한 개발자를 보면 사용하고 있는 프레임워크만 알고 기계적인 코딩밖에 하지 못하는 경우를 종종 본다. 다른 분야도 마찬가지다. 그럼 한 분야에서만 일한 미국의 30년차 개발자도 그럴까? 물론 개인차가 있겠지만 개발하는 문화나 방식이 좀 다르기 때문에 상황은 다르다.
 
P사에서 개발하는 방식을 보자. 눈에 띄는 것은 개발 방법론이 어찌됐건간에 제품을 꾸준히 업그레이드하면서 코딩을 하기 전에 스펙 문서를 자세히 작성해서 전세계 많은 관련자와 세밀하게 리뷰를 한다. 스펙에는 아키텍처도 포함되어있다.  스펙은 개발자끼리만 리뷰를 하는 것이 아니다. 애플리케이션 개발자와 리뷰도하지만 QA엔지어와도 리뷰를하고 기술 지원 엔지니어 등 거의 모든 분야 관련자들과 리뷰를한다. 
 
리뷰는 그냥 훑어보는 것이 아니다. 자신이 담당하거나 전문인 분야의 지식을 총동원한 후 검토를 해서 향후 발생할 문제 등을 면밀히 분석하는 것이다. 이 과정에서 아주 기술적인 세밀한 부분까지 토론하고 논쟁한다.
 
이런 과정을 거치면 제품의 완성도는 훨씬 올라가고 아키텍트는 튼튼해진다. 이런 얘기를 들으면 우리도 시간이 충분하면 이렇게할 수 있다고 한다. 하지만 이런 생각은 착각이다. 이렇게 개발을 하기 때문에 적은 인원으로 더 빨리 개발을 하는 것이다. 논어에는 세명이 길을가면 그중에는 반드시 내 스승이 있다고 했다. 철저한 리뷰는 더 좋은 제품을 만들기도 하지만 리뷰를 통해서 많은것을 배운다. 개발자는 본인의 직접적인 경험과 책만으로 배우는 것은 한계가 있다. 여러 개발자와 또 개발자가 아니라도 여러분야의 전문가와 토론하면서 많은것을 배우게 된다.
 
우리나라 개발자들은 흔히 토론, 리뷰에 약하다. 토론의 경험도 적고 막상 토론을 하면 직급으로 누르거나상대방을 공격해서 상처를 주거나 논리적으로 진행되지 않는 경우가 많다. 한두번 이런 일을 겪고 나면 이런 자리는 자연스럽게 피하게 된다. 결국 혼자서 땅굴을 파는 것에 편하게 되고 그렇게 오랜시간 개발을 하다 보면 한 분야의 전문가는 될 수 있어도 다양한 경험과 통찰력을 가진 개발자로 발전하기는 힘들게 된다.
 
또, 주목할만한 것은  소프트웨어 선진국에서는 아주 흔한 근무형태지만 재택근무가 아주흔하다는 것이다. 위에 언급한 모든것의 진행이 온라인 시스템과 화상회의로 이루어진다. 장소에 구애 받지 않고 일하고 회의도 화상회의 시스템을 많이 이용하고 꼭 필요할 때만 회사에 나가도 된다. 이런 재택근무 문화는 개발자에게 일할 기회를 제공한다기보다는 장소에 구애받지 않고 회사가 뛰어난 엔지니어의 도움을 받을 수 있다고해석하는 것이 좋겠다. 
 
리뷰도 어차피 대양을 건너 세계 각국 많은전문가와 진행하는 것이기 때문에 한자리에서 같이 일할 필요는없다. 이렇게 뛰어난 엔지니어들이 모이면 서로의 성장에 도움이 된다. 온라인이 아니면 이런 엔지니어들이이렇게 같이 일을할 수 있겠는가?
 
이글을 읽는개발자라면 우리도 환경이 되면 이렇게할 수 있다고 생각할 수 있겠지만 막상 쉽지는 않다. 대부분의 엔지니어가 문서 작성을 코딩하는 것처럼 익숙해져 있고 잘 작성해야 한다. 이런 온라인 협업은 시스템과 문서로 진행이 되기 때문에 문서작성역량은 매우 중요하다. 많이 자세히 작성하는 것이 잘하는 것은아니다. 효율적으로 필요한 핵심 내용을 적절히 작성해야 한다. 고참 엔지니어가 될수록 문서작성능력은 더욱더 중요하다. 나뿐만 아니라 내 주변의 수많은 개발자들 이렇게 일을 할때 30년 이상 개발자로 즐겁게 일할 수 있을 것이다.