2016년 4월 22일 금요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2015년 12월 8일 화요일

이우소프트에는 이것이 있다 vs. 없다


개발자 캐리어 보장이 있다.

  • 개발자가 원하면 영원히 개발자로서의 경력을 보장해준다.
  • 개발자에게 나이가 많다고 관리를 강요하거나 권유하지 않고 본인의 적성과 역량에 따라서 진로를 결정하면 된다.

남녀 차별이 없다.

  • 남여에 따른 역할,대우의 차이가 전혀 없다.
  • 100% 역량에 따른 차이 밖에 없다.
  • 결혼, 육아에 따른 차별이 없다.

아키텍트가 있다.

  • SW아키텍트가 있고 스펙, 설계와 기술적인 이슈 해결을 담당한다. 코딩도 한다.
  • 무조건 고참이라고 아키텍트가 되는 것은 아니다.
  • 아키텍트가 되기 위한 까다로운 자격을 충족해야 한다.
  • 아키텍트는 사원부터 수석 연구원까지 있다.
  • 여자 아키텍트도 있다.

개발팀장이 없다.

  • 개발팀장이 있기는 한데 휴가 결재가 하는 일의 대부분이다.
  • 개발팀장은 Technical leader로서 개발만 잘하면 된다.

전문가가 있다.

  • 자신의 일에 전문가가 되지 않으면 살아남을 수 없다.
  • 하지만 전문가라면 의견이 존중되는 수평적인 조직이다.
  • 비전문가가 감놔라 대추놔라 하지 못한다.

직급에 따른 서열이 없다.

  • 개발자들은 직급이 아무것도 말해주지 않는다.
  • 역량에 맞게 일을 분배하고 개발을 할 뿐이다.
  • 아키텍트가 따로 있고 PM이 일을 분배할 뿐이다.

잔디밭이 있다.

  • 8층 사무실 문을 열고 나가면 하늘 정원의 잔디밭이다.  
  • 잔디밭에 누워서 햇볕을 쐬면서 머리를 식히자.


파티션이 없다.

  • 파티션이 전혀 없이 책상들끼리 붙이 있다. 
  • 모든 직원이 한눈에 보인다.

회의록이 있다.

  • 모든 회의가 하나도 빠짐없이 기록이 된다.
  • 회의록은 거의 실시간으로 기록되고 모든 직원에게 공유된다.
  • 회의에 참석하지 않은 사람도 언제든지 모든 회의록을 볼 수 있다.
  • 그리고 결정된 사항은 모두 철저히 추적 관리가 된다.

코리안 타임이 없다.

  • 회의시간이 1초도 늦는 직원은 없다.
  • 1초라도 늦은 직원은 회의 참석자 전원에게 커피를 사야하고 2번째 늦을 때는 전직원에게 피자를 사야 한다.
  • 커피는 얻어 먹었지만 아직 피자는 못얻어 먹었다. 언제 피자를 먹을 수 있을지 기다리고 있다.

전문 PM이 있다.

  • 전문PM이 합리적으로 일정,리스크 등 프로젝트 관리를 한다.
  • 억지를 부리지 않는다.
  • 그렇게 해서 최단 시간에 프로젝트를 끝내고 있다.

일정 강요가 없다.

  • 경영진이 말도 안되는 일정을 억지로 밀어붙이지 않는다.
  • 1,2일 단위로 개발자가 산정하며 개발자가 예측한 일정을 다른 사람이 무시하지 않는다.
  • 그래도 일정이 부족하면 PM은 온갖 방법을 동원해서 일정 단축 전술을 구사하고 그래도 부족하면 일정을 연기한다.
  • 필요 시 일정은 구현 시작 전에 연기하므로 비즈니스 부서에서는 일정을 조율하는데 큰 문제가 없다.

몰입이 있다.

  • 하루 8시간 무섭게 몰입해야 한다.

야근이 없다.

  • 강요된 야근이 없다.
  • 일정을 합리적으로 결정하고 몰입해서 일해야 하기 때문에 야근이 필요 없다.
  • 가끔 스스로 선택해서 야근을 하는 사람들이 있기는 하지만 강요는 없고 본인이 선택하는 것이다.
  • 강요된 야근은 장기적으로 SW의 품질을 떨어뜨리고 기업 문화를 퇴보 시킨다.
  • PM이 야근 카드를 꺼내는 경우는 정말 피치 못할 때이고 단기적으로 사용해야 한다.

스펙이 있다.

  • 소프트웨어를 개발할 때는 항상 스펙을 작성한다.
  • 큰 프로젝트는 SRS를 작성하고 작은 프로젝트나 프로토타입 개발 시에는 One-pager를 작성하다.
  • 프로젝트 계획은 스펙을 기초로 합리적으로 수립한다.
  • 스펙은 변경되면 문서를 업데이트해서 최신 버전을 유지한다.

일정 지연이 없다.

  • 지연되는 프로젝트가 하나도 없다.
  • 합리적인 일정 수립과 철저한 프로젝트 관리를 통해서 일정은 무조건 지킨다.
  • 일정은 협력사와의 약속이므로 목숨처럼 지킨다.
  • 출시 일정은 SRS가 끝날 때 확정한다.

60세 개발자가 있다.

  • 나이는 개발자인지를 결정하는데 아무런 영향을 주지 않는다.

보고서가 없다.

  • 개발자에게 보고서 강요가 없다. 주간보고도 없다.
  • 개발자는 개발만 하면 된다.
  • 문서는 개발문서만 쓰면 된다.

재택근무가 있다.

  • 회사에서 자격을 부여한 개발자는 재택근무를 선택할 수 있다.
  • 가끔 회사에 나와서 회의를 하고 커뮤니케이션은 거의 이슈관리시스템을 이용한다.

E-mail이 없다.

  • 모든 커뮤니케이션은 이슈관리시스템을 이용한다.
  • E-mail은 주로 외부인과만 주고 받는다.
  • 내부 모든 커뮤니케이션은 기록이 되고 공유가 되며 추적이 된다.

개발자에게는 가장 빠른 PC가 있다.

  • 회사가 감당할 수 있는 한도 내에서 개발자에게 가장 빠른 PC를 지급한다.
  • 빠른 CPU와 SSD를 장착하여 빌드 속도를 2배 빠르게 한다.
  • 그만큼 개발자는 일을 더 많이 해야 한다. 그리고 정시 퇴근해라.

피어 리뷰가 있다.

  • 개발자가 작성하는 코드 대부분을 리뷰한다. 리뷰를 통해서 버그를 찾고 공유, 학습을 한다.
  • 더 중요한 것은 스펙, 설계 리뷰다.

마시고 죽자는 회식이 없다.

  • 원치 않는 음주 회식에 참여해서 끌려 다닐 필요가 없다.

꼭 지켜야 하는 문화가 있다.

  • 공유, 협업, 커뮤니케이션이 꼭 지켜야 하는 문화다.
  • 공유와 협업을 철저히 하지 않으면 같이 일을 할 수 없다.




2015년 10월 26일 월요일

이우소프트에서 Software Engineer와 Data Scientist를 채용합니다.

저와 같이 글로벌 소프트웨어를 개발할 Software Engineer와 Data Scientist를 채용합니다. 기간에 제한없이 지속적으로 채용합니다.


Software Engineer
  • 학력, 경험 분야와 무관하게 뛰어난 개발자를 선발합니다.
  • 다음의 개발언어 중 최소 하나 이상에서 전문가적인 실력을 갖춰야 합니다. : C/C++, C#, Java, Objective C, Python
  • 공유, 협업, 커뮤니케이션에 능숙한 개발자를 선호합니다.
  • 새로운 기술 및 아이디어에 관심이 많은 개발자를 선호합니다.
  • 문제해결 능력이 뛰어난 개발자를 선호합니다.
Data Scientist
  • 다음의 학문적인 Background를 가진 사람
    • Mathematical Background
      • Statistics
      • Multivariable Calculus
      • Linear Algebra
      • Numerical Analysis
    • Machine Learning
    • Data Visualization
    • Digital Image Processing
  • Data Scientist 경험
  • 통계학 경험
  • Machine Learning 응용 경험
  • Matlab, Octive, R, 등 Machine learning tool 사용 경험
  • 창의력이 뛰어난 사람

이우소프트는 앞으로 새로운 영역의 소프트웨어 개발에 적극적으로 나설 계획이며 다양한 분야의 뛰어난 Software Engineer와 Data Scientist를 적극적으로 영입하려고 합니다. 많은 지원 부탁합니다. 


지원방법 : 이력서자기소개서를 gracegyu@gmail.com 보내주세요.

글로벌 소프트웨어 회사를 저와 같이 키워 볼 기획자를 채용하려고 합니다.

대한민국에서 글로벌 소프트웨어 회사를 탄생시키기 위해서 젊은 소프트웨어 창업자를 위한 비영리 교육사업을 시작합니다.

사업을 기획하고 같이 글로벌 소프트웨어 회사를 키워 기획자를 채용하려고 합니다.

사업의 개요

  • 아이디어와 열정만 있으면 됩니다. 나머지는 모두 이우소프트에서 제공합니다.
  • 일할 있는 공간, 시스템, 급여, 회사설립, 특허, 휴식공간, 식사 모두 무상으로 제공합니다.
  • 실리콘밸리의 소프트웨어 개발 문화를 공유하고 코칭을 제공합니다.
    • 김익환, 전규현 코치가 실질적인 소프트웨어 공학과 문화를 가르쳐 줍니다.
    • 여러 전문가가 마케팅부터 개발 등 여러 분야에서 지원을 해줍니다.
  • 가능성 있는 창업자에게 Seed funding 제공합니다.
  • 추가적인 투자 및 투자 연결을 제공합니다.
  • 글로벌 시장에서 통할 아이템을 선발하며 글로벌 시장 진출을 지원합니다.


채용하려는 사람
  •  사업을 기획할 사람
  • 소프트웨어 회사를 키우고 싶은 열정과 실력을 갖춘 사람

지원방법 : 이력서, 자기소개서를 gracegyu@gmail.com 보내면 됩니다.




2015년 10월 7일 수요일

리뷰! not 설명회

소프트웨어를 개발할 가장 중요한 활동 하나가 리뷰다. 특히 Peer review.

리뷰가 중요하다는 것은 소프트웨어 개발에 종사하는 사람들은 거의 것이다. 하지만 막상 리뷰를 어떻게 하고 있나 살펴보면 제대로 하고 있는 경우는 별로 없다.

우리나라에서 흔히 있는 리뷰의 형태는 설명회 방식이다. Reviewee(리뷰를 받는 사람) 내용을 하나씩 설명하면 Reviewer(리뷰를 하는 사람)들이 설명을 듣고 있다가 의견을 얘기하는 방식으로 진행하는 경우가 많다.

많은 Reviewer들은 사전에 리뷰자료를 읽지 않거나 훑어만 보고 참석해서 설명을 들으면서 의견을 얘기하곤 한다. 이런 형태의 리뷰는 문제가 많다.

일단 시간이 오래 걸린다. 웬만한 프로젝트의 스펙문서는 수백페이지에서 천페이지를 넘곤한다. 그런데 이런 설명회 방식의 리뷰로는 며칠이 걸릴지 짐작도 안된다. 모든 내용을 꼼꼼하게 훑으면서 리뷰를 하기도 어렵고 나중에는 시간에 쫓겨서 대충 끝내버리기도 한다.

또한 난상토론 방식으로 진행을 하다가 마무리를 못하기도 한다. 그렇게 다시 수정된 문서를 리뷰하게 되면 첫번째 리뷰보다 충실하게 진행되기 어렵다. Reviewer들도 이미 봤던 내용을 보기 때문에 대충 검토를 하게 된다.

이런 부실한 리뷰를 통해서 진행되는 소프트웨어 프로젝트는 수많은 난관을 만나기 마련이다.

설명회 방식의 리뷰는 지양해야 한다.

리뷰는 진짜 리뷰여야 한다. 리뷰의 목적은 여러 가지가 있지만 가장 중요한 목적은 여러 관점에서 전문가들이 검토를 해서 문제점을 찾아내서 고치는 것이다. 리뷰를 진행하다고 하면 Reviewer 사전에 문서를 한글자, 한글자 빠짐없이 꼼꼼히 검토해서 의견을 제시해야 한다. 그래서 오프라인 리뷰 없이 온라인으로 진행하기도 한다.

하지만 오프라인 리뷰가 같이 의논을 있어서 효율적이다. 그렇게 여러 Reviewer들은 미리 완벽하게 검토를 해서 리뷰 자리에서는 문서를 한줄 한줄 같이 보는 것이 아니라 검토할 내용들만 빠르게 의논하고 결론을 내고 끝내는 것이다. 천페이지짜리 스펙문서가 2시간에 리뷰를 마치기도 한다.

이렇게 하기 위해서는 일단 문서가 적혀야 한다. 웬만한 이슈들은 사전에 개별 담당자와 검토가 완료되었고 오프라인 리뷰를 요청할 때는 98% 정도 완성이 되었을 가능한 것이다.

그리고 리뷰는 한번에 끝내야 한다. 이렇게 Reviewer들이 많은 노력을 들여서 검토를 했는데 이런 리뷰를 여러 해야 한다고 하면 2, 3번째 리뷰는 제대로 진행이 되지 않는다.

리뷰를 한다는 의미는 공동 책임을 진다는 의미다. 그런데 설명회에 구경와서 한마디씩 던지고 책임은 지지 않는 사람이 너무 많은 같다.

전문가도 아니면 윗사람이라고 툭툭 던지는 얘기가 프로젝트를 망치게 수도 있다. 경영자라면 스펙을 리뷰할 Product scope 부분의 Business Strategy, Corporate Goal 등의 내용을 심도 있게 검토하면 된다. 각자 전문분야가 있다.

하지만 노력이 많이 드는 리뷰는 원하지 않고 편하게 앉아서 설명해 주는 것을 듣기나 하겠다고 설명회를 원하는 경영진들은 권위의식과 귀차니즘에 빠져 있는 것이다.

MS에서 초기에 엑셀을 개발에서 스펙을 리뷰할 빌게이츠가 스펙 문서를 모두 읽고 와서 윤년 계산에 버그를 발견하여 리뷰 얘기를 했다는 일화는 유명하다. 빌게이츠는 당시 CEO였지만 Chief Architect 역할로서 스펙을 모두 검토했던 것이다.

소프트웨어를 제대로 개발하고 싶다면 권위의식은 버리고 리뷰를 제대로 진행해야 한다. 개발자들도 건성건성 구경하러 가는 리뷰는 지양해야 한다. 리뷰에 참석했다는 의미는 공동으로 책임을 진다는 생각을 하고 철저히 검토를 해야 한다.

2015년 6월 28일 일요일

[공지] 티스토리에서 Google Blogger로 이사왔습니다.

그동안 티스토리에서 블로그를 운영하다가 최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이사왔습니다.

기존에 http://allofsoftware.net 과 http://www.allofsoftware.net 로 접속을 했던 독자들은 바로 Google Blogger로 접속이 가능합니다.

단, http://softwaredev.tistory.com 을 이용하던 독자들은 http://allofsoftware.net 나 http://www.allofsoftware.net 을 이용하시면 됩니다.

기존 글의 ULR과 Tag URL을 거의 다 Redirection을 통해서 Google Blogger로 연결을 해 놓았기 때문에 다른 Page에 걸려 있는 Link나 Bookmark, 그리고 검색 사이트에 걸려 있는 Link도 거의 다 제대로 동작됩니다.

RSS Feed도 Google Blogger로 연결되도록 설정했습니다.


당분간 Tistory와 Google Blogger 양쪽의 접속 통계를 보다가 Tistory에 더이상 접속이 없으면 폐쇄를 할 예정입니다.

감사합니다.

2015년 6월 27일 토요일

소프트웨어 번역을 효율적으로 하는 방법 (23)

국제화 개발팀에서 근사한 번역함수를 만들어 준다고 해도 번역이 잘 되도록 번역함수를 사용하는 것이 쉬운 것은 아니다. 특히 주니어 개발자들이 소프트웨어 번역의 원리를 이해하지 못하고 번역함수를 잘못 사용해서 번역가가 아무리 번역을 잘해도 이상하게 되는 경우가 있다. 

그래서 번역이 효율적으로 되도록 하고 번역함수가 제대로 동작하게 하려면 어떻게 해야 하는지 알아보자.


1. 용어 사전을 만든다.

번역에 있어서 용어사전(Dictionary)를 만드는 것은 매우 중요한 활동이다. 잘 정리된 용어사전은 번역이 일관되게 하며 여러 번역가가 협업을 할 때 같은 용어를 사용할 수 있도록 한다. 

영어에는 같은 뜻이지만 다른 단어가 엄청나게 많다. 따라서 용어사전에는 해당 뜻일 경우 어떤 단어를 사용하라는 지침이 포함된다. 이렇게 영어를 기준으로 용어사전을 만들면 번역가들은 각 로케일별로 각각 용어 사전을 만들어 달라고 요청을 하는 것이 좋다. 여기서 언어별이 아니고 로케일별인 이유는 스페인의 스페인어와 멕시코의 스페인어의 용어사전이 다를 수 있기 때문이다.
이렇게 용어 사전을 만들어 놓으면 나중에 번역회사를 교체해도 일관된 번역을 유지하기 좋다. 

2. 번역의 기준이 되는 영어 문장은 최대한 간결하고 번역이 쉬운 용어를 사용한다.

소프트웨어는 문학작품이 아니고 문법 시험이 아니다. 소프트웨어에서 사용하는 용어는 소프트웨어를 이해할 수 있는 정도로 최대한 간결하고 번역이 쉬워야 한다. 올바른 문법을 주장하다가 문어체 문장으로 도배를 하면 오히려 어색한 경우도 많다. 

용어 선택도 주의를 해야 한다. "Hard"라는 단어보다는 "Difficult"가 좋다. 예를 들어 실생활에서는 "Hard"를 더 많이 쓴다고 하는 경우라도 번역에 오해가 없는 "Difficult"를 쓰는 것이 더 좋다. 

3. 대소문자 번역을 효율적으로 한다.

Open, OPEN, open을 각각 번역하면 3번 번역을 해야 하고 비용도 3배 더 나간다. 한국어로는 모두 "열기"다. 이런 경우 "open"하나만 번역을 하고 대소문자 변환 함수를 이용해서 변환하여 사용하는 것이 효율적이다. 대소문자를 처리하는 로케일 카테고리 표준은 LC_CTYP이다. LC_CTYPE의 영향을 받는 대소문자 변환 함수를 사용하면 로케일에 따라서 적절히 대소문자를 변환해준다.

C언어에서는 strlwr, strupr, wcslwr, wcsupr, stricmp, wcsicmp 등이 있다. 내가 바퀴를 다시 만들 필요는 없고 있는 함수를 쓰면 된다.

4. Broken sentence를 피한다.

대표적인 Broken sentence는 한 문장을 통째로 번역하지 않고 단어들을 쪼개서 합치는 것이다. 이렇게 쪼개진 단어들을 번역하기도 어려울 뿐만 아니라 어쨌든 번역을 해도 언어별로 어순이 달라서 이상한 문장이 되게 된다. "Leg of dog"을 쪼개서 번역하면 "다리의 개"가 될 수도 있다.

문장은 온전한 문장을 통째로 번역해야 하며 문장을 분리하는 기준은 각 언어의 특성을 어느 정도 알아야 효과적으로 정할 수 있다.

반대로 쪼개야할 문장을 하나로 연결해서 번역을 할 경우 번역해야 할메시지가 엄청나게 늘어나는 경우가 있다. 번역가는 이렇게 반복되는 패턴을 발견해도 이상 여부를 알리지 않고 기계적으로 번역하는 경우가 많다. 번역가는 오히려 이런 현상을 환영한다. 번역은 쉽고 수입은늘기 때문이다. 번역할 문장을 적당히 짤르는 것은 개발자의 몫이다.

5. 메시지 표준을 정한다. 

보통 여러 개발자가 함께 소프트웨어를 개발하기 때문에 개발자들이 작성한 영어 문장이 서로 상당히 다른 경우가 있다. 용어사전이 있다고 하더라도 일관되게 사용하기는 쉽지 않다. 몇몇 회사는 소프트웨어에서 사용하는 모든 메시지를 전문팀에서 정해주곤 하는데 100% 커버하기는 쉽지 않다. 개발자가 문장을 결정해야 하는 경우도 많다. 이럴 때 지켜야 할 규칙을 정해야 한다.

예를 들어 문장의 끝에는 마침표를 찍을지 말지, Cannot을 쓸지 can’t를 쓸지? 등과 같은 사소한 규칙들의 집합일 수도 있다. 이런 표준은 발견될 때마다 조금씩 보강해나가면 된다.

6. 번역 제외 메시지 표시 함수를 정한다. 

가끔은 번역을 하면 안되는 메시지들이 있을 수 있다. 그런 메시지는 번역을 하지 않아도 되니 번역함수를 사용하지 않고 그냥 놔두는 경우가 있다. 이렇게 해도 소프트웨어는 문제없이 동작한다. 하지만 이 소스코드를 본 어떤 개발자가 번역함수가 누락된 것으로 착각을 하고 번역함수로 메시지를 감싸는 경우가 발생한다.

예를 들어 "IT"라는 단어가 소프트웨어에 있고 절대 번역을 하면 안되는데 이를 본 개발자가 번역함수("IT")로 바꿔놨다고 하자. 그러면 또 이 단어를 수십개의 언어로 번역을 해야 한다. 비용은 비용대로 들고 이 단어가 번역이 돼서 문제가 발생하기도 한다.

번역을 하면 안되는 단어는 화면에는 출력이 되지만 번역을 하면 안되는 경우와 화면에는 출력이 안되고 소프트웨어 내부적으로만 사용을 하는 경우가 있다. 소프트웨어 내부적으로 사용하는 단어를 번역해버리면 소프트웨어가 동작하지 않기도 한다. 또한 로그 등 번역을 할 필요가 없는 경우도 있다.

이런 일을 방지하기 위해서는 번역 제외 표시 함수를 사용하는 것이 좋다. 번역제외("IT") 이렇게 해놓으면 어느 누구도 실로 번역을 하게 만들지는 않는다. 물론 번역제외 함수는 아무 일도 하지 않고 원래 메시지 그대로 넘겨줄 뿐이다.

번역 제외 함수는 번역 라이브러리나 프레임워크에 따라서 다르며 지원하지 않는 경우도 있다. 이런 경우는 번역제외함수를 직접 만들어서사용하면 된다.

7. 번역가에게 번역가이드를 전달한다.

지난번에 얘기를 했듯이 메시지 별로 번역가에게 어떻게 번역을 해야 하는지 번역 가이드를 전달해야 한다.

8. 메시지 파일은 UTF-8으로 인코딩한다.

국제화가 잘된 소프트웨어는 멀티바이트보다 유니코드를 지원하도록 개발하는 것이 여러모로 편리하고 자잘한 문제도 적다. 번역가에게 메시지 파일을 보내서 번역을 요청할 때 최초의 파일은 ASCII 인코딩일 가능성이 높다. 메시지키가 영어이기 때문이다. 이때 번역가들은 자국의 인코딩을 이용해서 번역을 해 오는 경우가 종종 있다. 이때 UTF-8으로 인코딩을 해달라고 요청하는 것이 좋다. 이때 지난번에 언급했듯이 Windows의 Notepad를 이용하면 BOM이 따라 붙어서 낭패를 보는 경우가 가끔 있다. BOM이 없는 UTF-8 파일이 필요한 번역 함수를 사용하고 있다면 Notepad는 사용하지 말라고 가이드를 해야 한다.

소프트웨어 국제화를 오래 하다 보면 이런 여러가지 노하우가 쌓이게 된다. 이런 노하우를 꾸준히 쌓아가면서 회사의 자산이 되도록 해야 한다.