123.456이 무엇으로 보이는가? (10)

123.456 숫자를 보면 우리나라 사람들은 대부분은 123에 소수점을 찍은 후 0.456이 추가된 것으로 생각을 할 것이다. 하지만 독일사람에게 123.456을 보여주면 뭐라고 생각할까? 독일에서 ‘.’은 천단위 구분자다. 그래서 123.456은 123456과 같은 숫자다. 만약에 123.456톤 원자재를 주문하면 어떻게 될까? 원래 의도보다 1000배많은 물량을 주문한 결과가 된다. 이런 것이 처리가 안된 소프트웨어를 과연 독일에 팔 수 있을까?

그럼 독일이 이런 것을 알았으니 독일에 맞춰서 소프트웨어를 개발한다고 하면 매번 새로운 나라가 나올 때마다 조사하고 연구해서 지원을 해줘야 한다. 그런 식으로는 끝이 없다. 나라별로 소숫점과 천단위 구분자는 천차만별이다. 게다가 아랍은 아라비아 숫자가 아닌 별도의 숫자를 사용하고 있고, 중국과 일본은 과거 천이 아닌 만단위 구분자를 사용했었다. 

Application 개발자가 매번 숫자를 출력할 때마다 이런 고민을 할 수는 없다. 국제화 라이브러리를 만드는 개발자가 이를 고민해야 하고 Application 개발자는 숫자를 출력하기 위해서 마음대로 개발을 하면 안되고 꼭 국제화 라이브러리를 사용해야 한다. 국제화 라이브러리 개발자는 내용은 나중에 채우더라도 Application 개발자가 쓸 수 있는 함수 정의를 먼저 제공해야 한다. 처음에는 한국의 숫자 형식으로 출력이 되겠지만 국제화 라이브러리 개발자가 로케일별 숫자 형식을 지원하는 라이브러리를 완성하면 숫자가 로케일별로 다른 형식으로 출력되게 된다. 

(소수점 사용 지도)

그럼 나라별로 어떤 형식의 숫자를 사용하는지 먼저 좀 알아야 한다. 또한 자신이 개발하고 있는 OS와 사용하고 있는 개발툴, 프레임워크가 어떤 국제화 함수들을 지원하는지도 잘 알아야 한다. 먼저 나라별 숫자 형식을 살펴보자.

1,234,567.89와 같은 숫자를 쓰는 나라는 한국, 미국, 캐나다, 중국, 일본, 영국, 호주 등이 있다. 물론 소프트웨어 내에서는 국가가 아니고 로케일로 지정을 해야 한다.

이와 반대로 1.234.567,89 형식의 숫자를 쓰는 나라는 독일, 그리스, 덴마크, 이탈리아, 인도네시아, 러시아 등이 있다. 네덜란드는 통화표시 때는 이 형식을 사용한다. 인도네시아는 과거 네덜란드의 식민지여서 이 숫자 형식을 쓰게 된 것으로 보인다. 아시아 나라들의 국제화 표준은 식민지 역사와 관련이 있는 것이 씁쓸하다.

특이하게 스위스에서는 1'234'567.89 형식으로 숫자를 사용한다. 

1 234 567,89와 같이 천단위 구분자로 띄어쓰기를 하고 소수점으로 콤마를 쓰는 나라로는 벨기에, 프랑스, 네덜란드(비 통화표시) 등이 있다.

사우디아라비아에서는 ١٬٢٣٤٬٥٦٧٫٨٩와 같이 표기한다. 천단위 구분자도 다르고 소수점도 다르다. 아리비아숫자도 쓰지만 아랍어의 숫자도 쓴다. 아랍권도 로케일마다 숫자표기가 다르다. 천단위 구분자는 뒤집힌 콤마인데 폰트 때문인지 제대로 안나온다. 특이한 점은 아랍어는 오른쪽에서 왼쪽으로 쓰지만 숫자는 왼쪽에서 오른쪽으로 쓴다는 점이다.

아라비아숫자는 최초에 인도에서 만들어졌다는데 대다수 역사가들이 동의를 하다. 하지만 인도숫자가 아니고 아라비아숫자라는 명칭을 얻게 된 이유는 인도에서 만들어졌지만 이슬람세계를 거쳐 점점 변형이 되면서 유럽으로 전파가 되었기 때문에 유럽 사람들은 아랍에서 온 숫자로생각했다. 

이외에도 여러가지 숫자 표기 형식이 더 있다. 하지만 개발자가 이 모든 것을 다 알 필요는 없다.  이렇게 다양하다는 것 정도와 나중에 버그가 보고 될 때 버그를 고치기 위해서 필요한 정도만 알면 된다.

우리나라 및 한자권의 나라들은 숫자가 만 단위로 되어 있어서 만단위구분자를 찍는것이 읽기는 더 편하다. 하지만 숫자표기 표준화에 따라서 우리나라에서도 천단위 구분자를 사용하는데 불편하다. 또한 관습적으로 백단위와 천단위 구분자를 섞어서 쓰는 나라도 있지만 지금은 거의 천단위 구분자를 사용하는 것으로 통일되고 있다.

숫자를 위한 국제화 라이브러리를 설계할 때는 다음 순서를 따르면 된다.

첫째, 지원 범위를 결정한다.

얼마나 많은 로케일을 지원해야 하나? 현재는? 미래에는?

지원할 숫자의 종류는? 정수? 실수? 숫자의 길이는?

천단위 구분자를 지원할 것인가?

출력만 지원할 것인가? 입력, 출력 모두를 지원할 것인가? 입출력별 지원할 숫자 형식은?

Application 종류마다 지원 범위가 다르므로 미래 요구사항까지 고려하여 스펙을 정해야 한다.

둘째, 함수 프로토타입을 정의한다.

함수가 정의되어야 국제화 라이브러리가 완성되지 않아도 Application 개발자가 사용할 수 있으므로 프로젝트 초기에 정해야 하며 나중에 바뀌지 않도록 신중하게 결정해야 한다.

보통 정수를 문자열로, 문자열을 정수로 바꿔주는 함수와 실수를 문자열로, 문자열을 실수로 변환하는 함수를 정의한다. 천단위 구분자를 옵션으로 주기도 하고 로케일에 영향을 받지 않는 옵션을 제공하기도 한다.

셋째, 함수 내부를 구현한다.

숫자 함수는 보통 L10n 라이브러리를 로케일별로 각각 개발하지 않고 시스템에서 제공하는 국제화 함수들을 사용한다. 그만큼 숫자는 일반적인 국제화 항목이라서 대부분의 시스템에서 제공한다. C언어를 사용한다면 atof(), atoi(), atoll(), strtod(), strtol(), printf(), sprintf() 등의 함수가 로케일을 바꿔주면 로케일에 따라서 다르게 동작한다. 물론 각 함수들은 와이드캐릭터(wchar_t) 버전이 따로 있으니 사용하는 문자의 데이터형에 따라서 알맞은 함수를 사용해야 한다. printf() 함수의 국제화 버전을 사용하려면 libintl라이브러리를 포함해야 한다.위 함수들이 로케일에 따라 다르게 동작하게 하려면 setlocale(LC_NUMERIC, "ko_KR")과 같이 숫자형식의 로케일을 바꿔줘야 한다. LC_ALL을 이용해서 모든 카테고리를 다 바꿔도 동작한다.

그 외에 어떤 개발언어, 라이브러리, 프레임워크를 사용하냐에 따라서 숫자함수들의 사용법이 다르니 환경에 알맞게 구현을 해야 한다. 

자세한 시스템 국제화 숫자 관련 함수의 사용법은 환경에 따라서 매우 다양하여 이 글에서 다 소개하기는 어렵다. 추가로 궁금한 것은 스스로 조사를 하던가 필자에게 직접 문의를 하는 것이 좋겠다. 

입력함수는 출력함수와는 다르게 엄격하지 않게 구현하는 것이 일반적이다. 천단위 구분자를 포함해서 입력하는 함수라도 천단위 구분자가 입력되지 않은 경우에도 처리를 하는 등 유연성을 발휘하는 것이다.

추가로 35%, 10mm 등 뒤에 단위가 붙은 숫자들도 국제화 함수로 미리 정의를 해 놓는 것이 좋다. 이또한 나라별로 국가별로 어떤 표기법으로 바꿔야 할지 알 수 없기 때문이다.

이렇게 숫자를 나라별, 로케일별로 제대로 표현하는 것은 소프트웨어 국제화의 시작이다.

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

야근, “악의 균형”

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

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

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

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

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

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

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

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

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

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

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

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

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

개발자에게 필요한 중요한 습관, “중복 없애기”

대기업이나 중견 기업들은 소프트웨어 개발 문제를 해결하기 위해서 복잡한 프로세스를 도입하곤 한다. 이 때 “중복”의 함정에 쉽게 빠진다. 문서를 비롯해서 소스코드까지 동일하거나 비슷한 내용이 여기저기 중복해서 작성되게 된다. 처음에는 이런 중복이 별 문제 없어 보이지만 시간이 흐를수록 생산성은 기하급수적으로 떨어지게 된다.

비효율적임에도 중복이 필요한 곳은 원자력 발전소나 우주선을 개발할 때다. 나사 하나만 바뀌어도 여러 문서를 확인하고 문제가 없는지 완벽하게 교체해야 하기 때문이다.  하지만 대부분의 소프트웨어는 적은 비용으로 빨리 개발하는 것이 목적이다.

그러기 위해서 소프트웨어 개발자가 가져야 할 중요한 습관 중 하나는 “중복 없애기”다. 이는 개발자뿐만 아니라 다른 직종에서도 필요하지만 소프트웨어 개발에서는 더욱 더 필요하다. 무분별한 중복이 가져오는 비효율성은 업무 생산성을 2배, 3배, 심지어는 10배이상 떨어뜨린다. 10배가 과장은 아니다.

필자는 과거 글로벌 기업의 호주 지사는 7명이 할 수 있는 일을 한국지사에서는 70명이 야근을 하면 힘겹게 일을 하는 사례를 소개한 적이 있다. 초기에는 한국지사가 세계에서 가장 빠른 개발 속도를 보였지만, 몇 년 만에 속도가 10배로 느려진 사례였다. 그 이유에는 여러 가지가 있지만 “중복의 지옥”도 중요한 이유 중 하나다.

“중복 없애기”는 소프트웨어 개발의 생산성을 높이는 매우 중요한 습관이며 그냥 개발자 각자의 습관에 맡겨 놓을 수는 없는 중요한 활동이다. 회사 차원으로 관심과 의지를 가지고 정착을 해나가야 하는 중요한 문화다.

그럼 소프트웨어를 개발할 때 어떠한 중복이 있는지 알아보자.

첫째, 소스코드 내의 중복이다.

적게는 한 단어, 한 줄부터 또는 몇 줄을 복사해서 반복적으로 사용하거나 많게는 함수 하나를 통째로 복사해서 조금 고쳐서 쓰는 경우다. 누구나 그렇게 하면 안된다고 알고 있지만 가장 흔히 벌어지는 현상이다.

비슷비슷한 내용을 개발할 때는 비슷한 코드들이 반복되는데 이를 추상화해서 별도의 모듈로 만들면 좋지만 시간과 노력이 들어간다. 당장 시간에 쫓기는 개발자들은 가장 빠른 방법인 Copy & Paste를 선택하곤 한다. Copy & Paste의 남발은 지옥문으로 스스로 걸어 들어가는 꼴이다. 당장은 개발이 빠르지만 시간이 흐를수록 기하급수적으로 생산성이 떨어진다.

소스코드에 의미를 알기 힘든 숫자들이 가득한 경우도 마찬가지다. 그 숫자의 의미는 개발자가 코딩할 당시는 정확하게 알고 있었어도 시간이 흐르면 본인도 남도 의미를 모르게 되는 경우가 많다. 게다가 해당 값을 일괄 변경해야 할 경우에는 불가능해지기 도 한다. 소스코드에는 숫자가 0 또는 1을 제외하고는 보여서는 안된다. 알아보기 쉬운 이름으로 정의를 해서 사용해야 한다.

소스코드 중복을 최소화하는 좋은 방법은 코드 리뷰다. 이미 호떡집에 불 난 것 같은 상황에서 매일 바쁘게 개발을 하고 있다면 무슨 방법도 소용이 없지만 코드 리뷰를 통해서 코드의 중복을 찾아내고 바로 고치는 것이 좋다. 물론 리뷰 전 코딩 시에 개발자 모두가 중복의 폐해를 명심하고 중복을 없애기 위해서 노력하는 것이 가장 좋은 방법이다.

둘째, 소스코드 파일의 중복이다.

과거 하루가 멀다하고 피쳐폰이 쏟어져 나올 때 피쳐폰을 가장 빠르게 개발하는 방법은 가장 비슷한 피쳐폰의 소스코드를 통째로 가져다가 조금 고쳐서 개발하는 것이었다. 그런 전략으로 피쳐폰 하나의 모델을 3개월만에 만들어내는 기적을 행하였었다. 물론 복사된 소스코드가 넘쳐나면 버그가 하나 발견되면 수십, 수백개의 모델에서 동시에 고쳐야 하지만 해당 모델을 빨리 단종시켜버리는 전략으로 대응이 가능했다. 고객의 불만은 친절한 서비스로 보답하면 된다.

그렇게 해서 비즈니스는 성공했을지 몰라도 개발문화에는 엄청난 폐해를 가져왔다. 그런 식으로 개발하는 것이 몸에 익어서 한번 익숙해진 습관은 쉽게 바꾸기 어려워지게 되었다.

나중에 스마트폰을 개발하는 과정에서도 그러한 습관은 불쑥 불쑥 튀어나오게 되었다. 이러한 습관이 팽배한 상황에서는 전사적으로 같이 사용할 공통 프레임워크를 만드는 일은 쉬운 일이 아니다. 

CTO나 Chief Architect가 이끄는 그룹에서 회사의 현재의 기술적인 요구뿐만 아니라 미래의 비즈니스 전략을 고려하려 향후 몇 년을 사용할 수 있는 공통 프레임워크를 설계하고 만들고 유지시켜 나가야 한다. 이런 와중에도 성질 급한 영업 위주의 경영자들의 수많은 방해와 도전을 막아 낸다는 것도 쉽지 않다. 전사적으로 몸에 베어버린 습관은 버리기 어렵기 때문이다.

셋째, 개발의 중복이다.

다른 팀에서 서로 비슷한 것들 개발하는 것이다. 두 번째와 비슷하지만 이번에는 각 팀에서 서로 모르고 개발을 하는 것이다. 그러다 보면 비슷한 것들을 여러 팀에서 개발하게 된다. 이는 회사차원에서 대단히 낭비 일뿐만 아니라 부서간에 개발 정보나 노하우가 공유되지 않는다는 증거이다. 

고급개발자가 될수록 자신의 팀의 개발뿐만 아니라 다른 팀의 개발 프로젝트도 두루 두루 관여를 해야 한다. 설계 리뷰에도 참여를 하고 코드리뷰에도 참여를 해야 한다. 이러한 문화는 중복을 줄여줄 뿐만 아니라 개발자의 개발 역량을 향상하는데도 도움이 된다.

넷째, 문서의 중복이다.

흔히 하는 착각 중에 개발 문서를 정말 많이 꼼꼼하게 적으면 개발이 잘 될 것으로 생각하는 것이 있다. 개발문서가 아예 없는 것도 문제지만 문서가 정말 많은 것은 더 문제가 된다. 

웬만한 규모의 소프트웨어를 개발할 때 문서는 SRS(Software Requirements Specification)를 포함해서 한두 개면 된다. 이것도 딱 필요한 만큼 가능하면 적게 적어야 한다. 그런데 프로세스를 강화한 회사들은 개발문서만 수십 개를 적는 경우가 있다. 이러면 필수적으로 같은 내용이 여러 문서에 적히게 된다. 처음 작성할 때는 복사를 해서 작성을 하면 되지만 프로젝트의 내용은 계속 바뀌게 되어 있다. 그런데 이렇게 여러 문서에 많이 적어 놓게 되면 나중에 고칠 때 어렵거나 불가능하게 된다. 결국 쓰레기만 쌓이게 된다.

이런 문서들에는 서로 다른 내용이 남아 있게 되고 나중에는 어느 것이 맞는 내용인지 알 수 없게 된다. 이런 경험을 가진 개발자들은 개발 프로세스, 방법론 다 필요 없다고 생각하게 된다. 나쁜 경험이 가져오는 폐해다. 

제일 나쁜 것은 미련한데 부지런 한 것이다. 부지런하게 잔뜩 중복 소스코드, 문서를 만들어 놓은 상황이라면 어찌할 도리가 없다. 처음부터 중복을 없애는 노력을 문화적으로 프로세스적으로 실천해야 한다. 어려운 것은 가장 알맞은 정도의 수준으로 정하는 것이다. 교과서에서 필요한 만큼이 이만큼이라고 설명할 수는 없다. 경험을 통해서 배워야 한다.

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

개발 경쟁력과 실속없는 화려한 보고서

몇 년 전 A사에서 있었던 일이다. 

A사가 그동안 진행했던 프로젝트를 경영진에게 보고하기 위해서 직원들이 보고서를 만들 때였다. 그런데 직원들 보고서가 최소 1주일 전에 완성 되어야 한다는 것이다.  경영진이 보고서를 매우 까다롭게 보기 때문에 보고서의 품질이 완벽해야 하기 때문이라고 한다. 나는 그럴 수 있다고 생각했다. 

하지만 남은 1주일 동안 진행되는 일은 매우 실망스러웠다. 경영진이 까다롭게 보는 보고서의 품질은 보고의 내용이 아니었다. 문서의 외형적인 모습이었던 것이다. 물론 내용도 중요하게 보겠지만 직원들이 특히 신경을 썼던 부분은 문서의 형식이었다. 

일단 보고서가 화려해야 하고 폰트, 정렬, 이미지, 도표 등 한눈에 딱 봐도 멋지게 보이지 않으면 안된다는 것이었다. 이런 모습을 보면서 문서의 외형적인 품질을 높이기 위해서 여러 명의 고급 인력이 허비하는 1주일이 참 아깝다는 생각이 들었다. 잠깐 동안 경영진의 눈을 만족 시키기 위해서 지불하는 비용 치고는 참 비싸다고 생각했다. 어쨌든 A사는 느린 전략 결정과 시대 흐름에 뒤쳐져서 현재 어려운 길을 걷고 있다. 

이에 비해서 내가 만난 G사는 사뭇 다른 문화를 가지고 있다. 

G사는 보고서를 작성하기 위해서 시간을 허비하는 것이 용납되지 않는다. 여기서는 좋은게 좋은게 아니다. 내부 보고 문건이 너무 화려하고 깔끔하게 작성되면 여지없이 질책이 쏟아진다. 간단한 보고를 파워포인트로 만드는 것도 용납이 되지 않는다. 대부분은 이메일 본문에 보고 내용을 간단 명료하게 작성하고 이메일로 검토 및 승인도 받는다. 

전화로 승인을 받기도 한다. 파일을 만들어도 텍스트 파일이나 워드로 핵심만 적어서 간단하게 만든다. 종이나 칠판에 작성한 내용을 사진찍어서 보고를 하기도 한다. 회의시간에 칠판에 그린 그림을 다시 문서로 만드는데 드는 시간을 아까워하는 것이다. 가끔 신입사원이 이런 문화를 모르고 예쁜 문서를 만들기도 하지만 여지없이 질책을 당하기 때문에 금방 적응한다. 

물론 외부로 나가는 문서는 형식도 신경을 쓰지만 내부 문서는 내용에 충실하고 외형을 꾸미는데는 10원도 투자를 하지 않는다. G사는 빠르고 능동적인 결정이 장점이며 시장 점유율을 점점 확대해 나가고 있다. 

나는 소프트웨어 개발 시 스펙을 작성할 때 화려한 문서는 지향하지 않는다. 대부분은 MS-워드로 작성하지만 간단한 프로젝트는 노트패드로 작성한다. 요즘은 간단한 스펙은 에버노트로 바로 작성해서 동료와 공유하기도 한다. 

MS-워드로 작성할 때도 칠판에 그린 다이어그램을 사진 찍어서 첨부하기도 한다. 특별한 규칙이 있는 것은 아니고 가장 효율적으로 작성할 수 있는 방법을 찾아서 시간을 최대한 절약하려고 한다. 규칙은 단순하다. “어떻게 하면 작성된 스펙을 가지고 개발자들이 구현을 할 수 있는가”만 생각하면 된다. 

반면 S사는 스펙, 설계의 규칙이 매우 엄격하다. 템플릿(Template)도 다양하고 UML의 여러 다이어그램을 모두 작성해야 한다. 그 이유는 UML의 표준 표기법을 잘 지켜야 서로 의사 소통이 정확하게 된다는 믿음을 가지고 있기 때문이다. 이러다보니 굳이 개발하는데 불필요한 문서와 다이어그램도 작성해야 하고 비효율적인 방법인지 뻔히 아닌 문서도 형식에 맞춰서 적어야 한다. 그렇게 해도 S사에서도 소프트웨어가 잘 개발되는 것은 아니다. 지금도 문제는 매우 많고 그럴 수록 더 많은 문서와 엄격한 규칙이 추가되곤 한다. 

많은 회사들이 비단 화려한 문서만 추구하는 것이 아니다. 화려한 시스템과 툴에도 많이 현혹된다. 유독 우리나라에서 비싸고 화려한 툴이 잘 팔리는 것을 보면 화려한 문서와 보고서를 요구하는 문화와 관계가 있을 것이다. 

소프트웨어를 가장 효율적으로 잘 개발하려면 실용주의를 추구해야 한다. 겉치레는 버리고 내용에 충실해야 한다. 경영자들이 보고서 내용보다 먼저 형식을 보고 지적한다면 직원들에게 겉치레를 중요시하라는 신호를 보내는 것이다. 

우리나라에서는 담당자들이 여러 경영진을 앉혀 놓고 브리핑하듯이 보고를 하는 모습을 종종 본다. 이런 권위적인 보고 자리에서는 당연히 경영자들이 듣고 싶어하는 얘기로 채워지고 내용도 예쁘게 포장이 된다. 보고를 한 이상 보고를 받은 사람도 결과에 대해서 책임을 지는 것이 당연하지만 이런 보고 자리에서는 결과에 대해서 보고자가 책임을 져야 한다. 

이런 틀에 박힌 보고 방법은 탈피해야 한다. 이런 보고서를 만드느라고 시간 낭비를 해서는 안된다. 이런 브리핑은 보고서를 따로 작성하지 않아도 시스템을 통해서 경영자가 직접 확인할 수 있어야 한다. 게으른 경영자를 위한 브리핑을 제외하고 나면 보고의 자리는 대폭 줄어든다. 

효율적인 보고는 진짜 중요한 내용을 경영진 또는 의사결정자에게 직접 빠르게 얘기하고 결정해야 한다. 내용은 메일이나 시스템으로 먼저 공유하고 얼굴을 보고는 핵심을 빠르게 전달하고 의논하면 된다. 굳이 회의실도 필요 없다. 정보는 이미 공유를 했으므로 최종 의논은 걸어가면서 할 수도 있고 전화로도 가능하다. 시간과 장소는 구애 받지 않는다. 

직원들은 어차피 경영진이 요구하는 보고 방식을 따를 수 밖에 없다. 매 보고 시마다 의자에 앉아서 직원들의 브리핑을 듣고 싶으면 직원들은 몇 배의 시간 낭비를 하고 있다는 것을 기억하자. 직원들이 어떻게 일했고 일하고 있는지 궁금한 것은 시스템을 통해서 모니터링을 해야 하며 직원들과는 진짜 중요한 얘기를 하자.

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

똑똑한 개발자를 찾기 위한 인터뷰 전략

나는 오랫동안 많은 개발자 인터뷰에 참석했다. 여러 소프트웨어 회사에서 개발자 인터뷰를 어떻게 진행하는지 들을 수 있는 기회가 있었고 회사의 관계자 대신 면접관으로서 기술 인터뷰를 진행한 경험도 많다. 그래서 소프트웨어 업계에서 개발자 인터뷰를 어떻게 하고 있는지 알 수 있는 기회가 있었다. 

우리나라에서 개발자 인터뷰를 어떻게 진행하는지 보면 해당회사와 직접적으로 관련된 경력을 집중적으로물어본다. 구체적으로 무슨 프로젝트를 어떻게 진행했느냐? 무슨 기술을 다뤄 봤느냐? 이런걸 아느냐? 우연히 면접관이 아는 지식과 유사한 경험을 한 개발자는 재수좋게 시원하게 답변을 할 수있다. 또한 개발자는 경력에 대해서는 자신이 한 것이나 동료가 한 것이나 구분하지 않고 과장되게 설명하곤 한다. 

개발자의 역량보다 동일하거나 유사한 분야의 경험을 더 중시하여 개발자를 채용하는 것은 초단기적으로는회사에 급한 불을 끄는데는 도움이 되지만 중장기적으로는 좋은 전략이 아니다. 이는 마치 부품이 고장나서똑같거나 호환되는 부품을 갈아 끼우겠다는 전략과 별반 다를 바가 없다. 

이렇게 동일 경험 개발자를 선호하다보니 경쟁사 개발자를 데려오기도 하고 동종업계 이직금지 서약을 더욱 중요시 하게 되고 논란도 많다.이러다 보니 여러 분야에 손을 대고 있는 대기업은 어느 중소기업에서 개발자가 오더라도 동일 분야라고 주장을 하면 송사에 휘말릴 우려가 있고 개발자의 이직 자유권을 제한하기도 한다. 동일 분야 개발자를 특히 선호하는 이유는 회사의 개발 문화가 낙후되어 있기 때문이다. 

공유가 안되고 협업이 힘들어서 어느 개발자가 오더라도 능력을 발휘하는데 오래 걸린다. 이런 이유로 동일 경험 개발자 위주로 채용하는 현상은 개발자에게 이직의 범위를 축소시키고 기회를 박탈하게 된다. 소프트웨어 개발자는 자신이 일해왔던 분야 뿐만 아니라 거의 모든 분야에서 일할수 있다. 또 그렇게 일해야한다. 

물론 개발자 스스로가 다른 분야에 거부감이 있는 경우도 있지만 이 또한 환경이 그렇게 만든 측면이 크다. 문제는 회사가 문화적으로 프로세스적으로 준비가 되어 있는가이다. 여러 분야의 개발자가 섞이는 것은 개발자에게 기회의 확대외에도 다양한 경험이 창의적인 아이디어와 혁신에 도움이되어 소프트웨어 산업 전반적으로 꼭 필요하다. 

단기적인 부품교체를 하겠다는 생각이 아니라면 개발자를 채용할때 가장 중요한 것은 회사의 미래 개발에필요한 똑똑한 개발자를 뽑는 것이다. 고급 개발자에게 필요한 것은 3가지가있다. 첫째, 소프트웨어 이론 지식이다. 둘째, 공학적인 경험과 개발 문화적인 소양이다. 고참 개발자에게는 중요한 요소다. 셋째, 가장 중요한 논리적인 두뇌와 수학적인 능력, 그리고창의력이다. 

신입 개발자를 채용하는 경우라면 이중에서 세번째만 집중적으로 봐도 된다. 세번째를 확인할 수 있는 방법은 문제해결(Problem solving)능력을 확인할 수 있는 창의적인 질문과 코딩 테스트(Coding Test)다. 이 두가지로 개발자가 얼마나 논리적이고 수학적인 사고를 하는지, 또 창의적인지 확인할 수 있다. 

동일 분야 경험이 전혀 없더라도 회사가 문화적으로 프로세스적으로 준비가 되어 있다면 1, 2개월후에는 동일 경력만 있는 개발자보다 우수한 능력을 보여줄 수 있고 그 성과의 차이는 시간이 흐를수록 점점 벌어지게된다. 이중에서 코딩 테스트에 대해 좀 더 알아보자. 코딩테스트를 하는 회사가 과거보다 많이 늘었다. 하지만 코딩 테스트의 방향을 못잡고 엉뚱하게 진행하는 회사도 있고 코딩 테스트에 거부감을 가지고 있는 개발자들도 있다. 

사실 코딩 테스트를 한다는 것은 개발자에게 긍정적인 신호일 가능성이 더 높다. 개발자의 역량을 제대로 평가할 줄 알고 그 만큼의 대우가 있을 가능성이 더 높다. 가끔 소프트웨어 회사의 코딩 테스트를 보면 나도 통과하기 힘든 것 같은 문제들이 나오기도 한다. 동일분야의 상세한 경험이 없으면 풀 수 없는 문제가 대표적이다. 동일 분야 동일 경력 개발자를 채용하기 위한 방법으로 코딩 테스트를 사용할 뿐이다. 

이런 회사는 단기적으로 부품을 교체하겠다는 생각이라면 상관이 없지만 그렇지 않고 좋은 개발자를 뽑기 위한 목적이라면 잘못된 방법을 사용하고 있는 것이다. 역사를 배운다고 연도나 줄줄이 외워야 하는 것처럼 이런 것을 물어보는 쪽지 시험과 같은 코딩 테스트는 뛰어난 개발자를 놓치기 쉬운, 좋지 않은 방법이다. 

그런데 지금도 이런 문제들을 갖고 개발자를 채용하고 있는 회사들이 꽤 있다. 이런 현상이 벌어지는 이유는 회사에서 고참 개발자들에게 코딩테스트 준비를 하라고 하면 그 동안 암기식 교육에 익숙해서 이런 문제 밖에 못 내고 인사 담당자는 이를 평가할 능력이 없기 때문이다. 코딩 테스트시 집중적으로 봐야하는 것은 개발자의 논리적인 사고 능력과 문제해결 능력, 창의성이다. 

그러기 위해서 특정분야의 지식을 필요로 하는 문제는 삼가는 것이 좋다. 코딩 테스트에는 대략 5가지 방법이 있다. 아래 방법 중 한 두가지를 선택해서 코딩테스트를 진행한다. 

첫째, 온라인 사이트 코딩 테스트다. 지원자가 너무 많은 경우 정말 자격이 안되는 개발자를 거르기 위한 용도로 사용한다. 인터넷을 검색해 보면 이런 서비스를 제공하는 회사가 많이 있다. 지원한 회사에서 지정한사이트에 등록을 하고 자신이 선호하는 개발언어로 주어진 시간동안 코딩을 하면 된다. 

둘째, 24시간에서 며칠이 소요되는 프로젝트 테스트다. 좀더 가능성이 있는 개발자에게는 첫 번째 온라인 사이트를 이용한 코딩 테스트보다 몇 시간 또는 하루 이틀 걸릴 간단한 코딩 숙제를 주고 1~3일안에 온라인으로 제출을 하게 한다. 

이때는 개발자의 논리적인 사고와 창의력도 보고 코딩 스타일도 보게 된다. C사의 경우 이 코딩 테스트에서 95% 이상의 개발자가 탈락을 한다고 한다. 개발자들이 정말로 가고 싶어하는 유명한 회사가 아니고 이름이 잘 알려지지 않은 중소 소프트웨어 회사라 면이 방법을 사용하기 힘들다. 개발자들이 그냥 귀찮아서 포기할 가능성이 높다. 

셋째, 전화 코딩 테스트다. 전화를 이용해서 코딩 테스트를 하는 방법인데 위 방법보다 좀더 많은 것을 볼 수가 있다. 전화를 통해서 지원자와 대화를 하면서 화면을 공유할 수 있는 방법을 통해서 직접 코딩하는 것을 보면서 코딩 테스트를 진행한다. 

구글 드라이브 문서를 통해서 공유하기도 하고 이와 비슷한 공유가 가능한 온라인 편집기를 사용하기도 한다. 또는 스카이프 등 화면을 공유하는 소프트웨어를 이용하기도 한다. 이런 협업 도구를 통해서 코딩하는것을 직접보면서 면접관은 이런 저런 질문을 하고 개발자는 코딩하는 것을 설명하면서 진행한다. 토론식으로 진행도 가능함으로써 코딩 결과만 보는 것보다는 훨씬 많은 것을 파악할 수가 있다. 지역적으로먼거리에 있는 개발자를 검증하기 위해서 사용할 수 있다. 

넷째, 1~3시간 온사이트 테스트다. 지금까지의 방법은 다른 사람의 도움을 일부 받을 수가 있다. 하지만 온사이트 테스트는 확실히 본인만의 실력으로만 진행해야 한다. 이 방법은 인터뷰전에 혼자서 노트북에 직접코딩을 하는 것이다. 1~3시간안에 풀 수 있는 문제를 주고 컴파일 및 실행이 되도록 직접 코딩을 하는 것이다. 인터뷰시에는 코딩한 결과를 설명할 수 있어야 한다. 이런 테스트는 면접자에게 많은 시간과 부담을 주기 때문에 이에 합당하는 면접 비용을 지불하는 것이 좋다. 

다섯째, 면접관과 함께 하는 칠판 코딩 테스트다. 내가 가장 선호하는 방법은 짧은 시간에 진행하는 칠판 코딩 테스트다. 가장 많은 것을 볼 수 있다. 칠판이라는 특성 때문에 문법은 보지 않는다. Pseudo Code(실행되지 않고 로직만 표현한 소스코드)로 작성을 해도 된다. 코딩결과만 보는 것이 아니라 어떻게 진행하는지더 눈여겨 본다. 

개발자가 문제를 정확하게 이해했는지 면접관에게 물어보는 자세도 중요하게 본다. 일부러 질문을 유도하기 위해서 문제에 질문이 필요한 함정을 넣기도 한다. 이를 질문도 없이 일사천리로 코딩을 해나가면 의심을 해봐야 한다. 

코딩을 하면서 중간 중간에 적절하게 설명하는 자세도 아주 중요하다. 그런데 우리나라 개발자들은 설명없이 그냥 써내려가는 경우가 많다. 평상시에 개발하는 방식이 그대로 반영된다. 이때 면접관이 지적하는 것에 대해서 어떻게 대응하는지도 중요하다. 코딩을 다하고 나면 개선점을 가지고 간단한 토론을 하는 것이 좋다. 이렇게 면접관과 상호작용이 잘 되는 개발자는 나중에 개발시에도 공유 및 커뮤니케이션이 잘될 수 있다. 

이렇게 10~30분동안 진행하는 코딩 테스트는 평소 개발의 축소판이고 창의력, 문제 해결 능력, 커뮤니케이션 능력까지도 볼 수 있는 좋은 수단이다. 실제 인터뷰에서 경력은 화려한데 칠판 코딩 테스트에서 탈락하는 경우가 부지기수다. 기본적인 논리적 사고와 수학적인 능력도 없이 본인이 설명하는 수 많은 프로젝트를 수행했고 높은 연봉을 받은 고참 개발자들을 보면 안타깝기 그지 없다. 

누가 설계를 해야하고 누가 프로그래밍을 해야하는지 구체적인 구분도 없이 고참이고 경력이 많다는 이유로 프로젝트의 설계를 주도하고 망쳐와서 정작 경력이 적더라도 똑똑하고 뛰어난 개발자들이 성장의 기회를 놓치게 된다. 개발자에게 진짜로 필요한것이 무엇인지 생각해보자. 

회사에서 진짜 뛰어난 개발자를 구분할 수 있고 그에합당한 대우를 할 수 있을때 우리 주변에 연봉 수억의 개발자들이 바글바글하게 될 것이다. 그래야 뛰어난두뇌를 가진 사람에게 소프트웨어 개발자는 충분히 매력적인 직업이 될 수 있을 것이다. 그쯤되면 소프트웨어 생태계가 더욱 좋아지고 개발자에게는 롤모델도 생기고 개발자에 대한 전반적인 인식과 대우도 더 좋아질 것으로 확신한다.

자신의 코드에 발목 잡힌 개발자들

필자는 국내외 다양한 소프트웨어 회사에 다니는 여러 개발자를 만날 기회가 자주 있고 각 회사의 개발 이야기를 종종 듣는다. 

그 중에서 3가지를 소개할까 한다. 우리나라 개발자들이 다양한 일을 하지 못하고 하던 일만 계속하게 되는 현상에 관한 것으로, 이것이 왜 문제가 되는지 생각해 볼 수 있는 사례이지 싶다.
 
국내 A사는 소프트웨어 개발자만 100명이 넘는 업계 1위 중견기업이다. 이 회사 개발자들은 철저히 자신의 소스코드가 있어서 몇 개 프로젝트를 제외하고는 서로 공동으로 개발하는 경우가 거의 없다. 프로젝트도 거의 혼자서 담당하며 한 사람이 여러 프로젝트를 맡는 경우도 있다. 

이러다 보니 다른 사람의 소스코드를 볼 일이 거의 없다. 소스코드 뿐만 아니라 프로젝트간 정보 교류도 매우 적다. 이슈관리시스템을 사용하지 않고 공유 문화도 매우 취약한 회사다. 

그래서 개발자가 한 명만 아파서 못나와도 프로젝트에 큰 타격이 생기며 다른 개발자가 도와주기도 쉽지 않다. 개발 일이 한쪽으로 몰려도 어차피 소스코드별로 개발자가 정해져 있어 놀고 있는 개발자가 있어도 도와주지 못한다. 

부서마다 조금씩 다르지만 신입 개발자가 입사해 제대로 일하려면 수개월 정도는 공부를 해야 한다고 한다. 기존의 소스코드를 익히고 기반 지식을 공부하는데 수개월이 걸린다. 개발자가 퇴사할 때마다 개발팀은 큰 곤욕을 치르지만 경영진은 개발자를 아끼지 않는 것 같다는 하소연을 한다. 잦은 릴리즈와 고객 밀착형 유지보수 서비스로 개발자들은 이미 지쳐있다. 

우리는 이런 현상을 속된말로 '몸빵'이라고 한다. 개발사가 개발을 주도를 하지 못하고 고객에 끌려 다니면서 그때 그때 대응에 집중하는 것이다. 이런 환경에서는 계획으로 개발을 하지 못하고 격무를 피하기 어렵다. 아키텍처도 깔끔하게 유지하기 쉽지 않다. 

한편으로는 '컴포넌트 오너'라고 하는 현상인데 컴포넌트(Component)별로 주인이 정해져 있어서 다른 사람은 못 건드는 것이다. 이것은 비단 A사만의 얘기가 아니다. 국내 많은 개발자들이 자신이 작성한 소스코드에서 벗어나지 못하고 한 분야에서 계속 땅굴을 파 내려가 경험의 폭이 좁아지고 고급 개발자로 성장하기 어려운 환경에 처해 있다. 한쪽 분야의 숙련공이 될 수 있어도 고급 개발자가 되기는 쉽지 않다. 

국내 B사는 개발자만 수백명에 달하는 누구나 아는 회사다. B사는 이미 이런 문제를 겪었고 이를 타개하고자 개발자풀 제도를 시도했다. 과거에는 개발자를 팀별로 나눠서 팀내에서 주어진 일을 했는데 개발자 풀 제도를 통해 비효율적인 인력운영을 효율적인 체계로 바꾸고자 했다.

팀구분 없이 개발자를 한군데 모아 놓고 프로젝트 관리자가 프로젝트마다 필요한 개발자를 선별해서 개발을 진행하고 프로젝트가 끝나면 개발자는 다시 개발자풀로 돌아가는 방식이다. 잘 활용하면 팀의 구분 없이 최적의 개발자를 투입할 수 있고 한쪽 프로젝트에 일이 쏠려도 개발자들이 도와주기 용이하다. 개발자들은 회사의 여러 프로젝트에 투입되기 때문에 자연스럽게 지식을 공유하게 된다. 

취지는 좋으나 철저한 준비과정 없이 조직만 그렇게 바꿔 놓으니 일이 제대로 진행되지 않았다. 각자 전문분야가 다르니 다른 개발자를 투입해서는 일이 안됐고 결국 해당 일을 하던 개발자를 투입해야 했다. 매트릭스 조직이라 프로젝트 관리자와는 별도로 팀장이 따로 있으니 프로젝트에 특정 개발자가 필요해도 팀에서 개발자를 내놓지 않으면 프로젝트는 진행하기가 어려웠다. 

사람을 아무리 많이 투입해도 원래 개발자의 직접적인 도움 없이는 프로젝트를 수행할 수 없었다. 계속되는 혼란을 한참 겪은 B사는 결국 개발자 풀 제도를 포기하고 말았다. 

조직이나 프로세스만 바꿔서 역량을 향상하거나 효율적인 개발을 기대하기는 어렵다는 것을 경영진이 이해하지 못한 사례라고 할 수 있다. 

미국 F사의 경우는 개발자가 수천명에 달하는 글로벌회사다. 개발자가 새로 입사를 하면 오리엔테이션 기간에 실제 서비스가 되고 있는 시스템 버그를 고쳐야 한다. 입사 첫날부터 개발에 직접 투입되는 것이다. 신규 입사자 중에는 해당 개발언어로 개발을 해본 적이 없는 사람도 있다. 

하지만 버그를 고치는데 문제가 없다. 어차피 경험한 개발언어를 보고 개발자를 뽑은 것이 아니고 기초가 튼튼하고 문제 해결 능력이 뛰어난 개발자들을 채용했기 때문이다. 멘토가 있기는 하지만 옆에 끼고 계속 가르쳐 주는 것은 아니다. 

F사 신규 입사자에게는 소스코드가 저장된 SVN(Subversion) 주소와 버그관리시스템인 Bugzilla 주소를 통해  처리할 버그가 할당된다.  아무도 버그를 고치는 방법과 알아야 할 지식을 가르쳐 주지 않는다. 하지만 시스템 스펙과 설계문서에 접근할 수 있고, Bugzilla를 통해서 기존 개발자에게 도움도 받을 수 있다. 

신규 입사자는 소스코드를 분석해 버그 원인을 찾을 수 있다. 소스코드의 각 라인 별로 언제 누가 수정을 한 코드인줄 즉시 알 수 있고 소스코드를 수정할 당시의 관련된 이슈도 확인이 가능하다.

이후 신규 입사자는 SVN에 고친 소스코드를 등록하기 전에 코드리뷰시스템에 등록을 해서 리뷰를 받아야 한다. 간단한 버그 수정은 아무 문제 없이 코드리뷰를 통과하겠지만 몇몇 이슈는 온라인으로 진행된 코드리뷰의 도움을 받아 수정하기도 한다.

이렇게 버그를 고치거나 작은 기능을 구현하는 일은 신규 개발자들이 처리한다. 실력을 인정 받으면 점점 어려운 일을 할당 받는다. 고참 개발자들은 어려운 일이나 스펙과 설계 작업을 주로 진행한다. 개발자는 언제든지 새로운 프로젝트에 투입되고 물론 자신이 관심 있는 프로젝트에 지원할 수도 있다. 많은 개발자가 퇴사해도 서비스에 별 문제가 없고 대부분 즐겁게 일한다. 

우리가 가야 할 길은 명확하다. 구멍가게를 할 것이 아니라면 컴포넌트 오너식 개발은 금방 한계에 다다른다. 혼자서 시작하는 스타트업도 F사처럼 개발을 하는 것이 더 빠르고 효율적이다. 과거의 나와 현재의 나도 공유를 해야 할 필요가 있다. 

혼자 개발해도 적절한 공유와 문서화를 했을 때 개발이 더 빠른 이유다. 어찌 보면 한 우물을 파는 것이 전문성 향상에 도움이 될 것 같지만 다양한 경험 없이 한 우물만 파내려가면 우물 속 개구리가 되고 말 것이다. 

소프트웨어 회사 개발팀의 꽃은 아키텍트다. 개발자들이 다같이 각자의 우물을 파내려 가는 환경에서는 뛰어난 아키텍트가 나오기 어렵다. 뛰어난 아키텍트가 없는 회사의 미래는 뻔하다. 2층짜리 집은 근근히 만들 수 있어도 100층짜리 빌딩을 어찌 아키텍트 없이 만들 수 있을까? 

그래서 국내 1등은 가능해도 딱 거기까지가 한계다. 더 심각한 문제는 이런 식의 개발 환경에서는 개발자가 행복하지 않다는 것이다. 야근을 반복해야 하며 고참이 되도 계속 과거의 코드에 발목을 잡혀서 앞으로 나아가기가 어렵다. 

고참이 더 바쁜 회사는 이런 함정에 빠진 경우다. 이직을 하면 고리가 끊어지지만 새로운 회사에서 똑 같은 일이 반복된다. 

이를 해결하는 기가 막힌 한가지 묘수가 있는 것은 아니다. 가장 중요한 공유문화를 비롯해서 성숙된 개발문화가 정착되면 자연스럽게 해결 된다. 개발문화를 소홀히 생각하고 프로세스만 강화해서는 절대로 F사와 같은 상황이 벌어지지 않는다. 이것이 다같이 성숙한 개발문화에 정착에 힘을 써야 하는 이유다. 

실리콘밸리 개발자 눈에 비친 한국 SW회사

얼마 전 실리콘밸리의 한 개발자 B씨를 만나서 소프트웨어 개발에 대해 많은 얘기를 나눴다. 과거에 같이 일했던 친구인데 미국에서 태어난 중국인으로 미국 대학을 나와 실리콘밸리에서 20여년간 개발자로 일을 했으며 10여년간은 몇몇 회사에서 CTO로 있었던 친구다. 

B씨는 최근에 한국 소프트웨어 회사(가칭 A사)와 많은 교류를 한 모양이다. 한국 회사에 자사 기술을 전수하기 위해서 실리콘밸리와 한국을 오가며 수개월간 한국 개발자들과 같이 개발을 해왔다고 한다. 그 과정에서 A사에 대해서 느낀 점을 필자에게 얘기를 해줬는데 A사 뿐만 아니라 우리나라 여러 회사에 공통적으로 해당하는 내용이 있어 소개할까 한다. 

B씨는 일단 처음에 A사가 어떻게 돌아가는지 파악했다.  그런데 이상한 생각이 들었다고 한다. 규모가 꽤 큰 서비스인데 시스템에 버그가 너무 많고 문제가 자주 발생한 것이다.

직원들의 야근도 너무 잦았다. 또 스크럼을 도입해 개발한다고 하는데 제대로 효과를 보는 것 같지는 않아 보였다. 그런만큼 B씨는 A사가 스크럼이든 설계든 개발 절차에 담긴 진의를 파악하지 못하고 형식만 흉내를 내는 것이 아닌가 생각이 들었다고 한다. 

이에 나는 B씨에게 “설계에서 제일 중요한 것이 무엇인가?”라고 질문했다. B씨는 “설계에서 제일 중요한 것은 콤포넌트를 잘 나누는 것”이라는 당연한 얘기를 했다.

B씨는 계속 얘기를 했다. 설계에 UML을 사용했는데 보통 UML은 필요가 없다. 우리는 대부분 칠판에 설계를 하다가 고치기를 반복한 후 사진을 찍어서 문서에 포함한다. 툴을 이용해서 다시 그리는 것은 시간 낭비다. 마지막 버전을 툴로 그리기도 하는데 정해진 툴도 없다. UML을 이용해서 쓸모도 없는 다이어그램을 잔뜩 만든 문서는 개발에 도움이 안되고 오히려 방해가 된다. 툴을 이용하면 칠판보다 고치기가 어렵고 다이어그램을 많이 그릴수록 고치는데 시간이 많이 들어가 바로 고칠 수가 없다. 또 A사 설계는 콤포넌트가 명확히 구분되어 있지 않아서 나눠서 협업하기 어려웠고 반대로 설계 내용은 너무 상세해서 오히려 비효율적이었다. 

나도 동감을 했다. 개발자가 알아서 할 부분까지 설계를 할 필요는 없다. 겉보기에는 A사의 설계서가 실리콘밸리의 한 개발자가 칠판에 끄적거린 설계서보다 멋져 보이고 전문적인 것 같지만 실전에선 훨씬 비효율적이다.  

설계를 어떻게 해야 하는지는 소프트웨어 성격에 따라 다르지만 설계 원리와 진의를 모르고 많은 다이어그램과 상세한 설계서는 식제 개발을 할때는 별로 도움이 되지 않는다. 많은 회사들이 UML 등을 이용해 완벽한 설계서를 만들려고 하는 경우가  많은데 그런 시도가 성공적이었는지 생각해볼 필요가 있다. 

B씨가 A사에 대해 또 이상하게 생각한 것은 애자일(Agile)을 적용한 방식이다. 실리콘밸리 스타트업은 거의 대부분 애자일 개발 방법론을 적용하고 있다고 보면 된다. 애자일은 특별한 것이 아니다. 과거부터 해오던 방식과 비슷하다. XP를 도입한 회사도 있고 스크럼을 쓰는 회사도 있는데 회사마다 필요한 것을 활용하고 있다. B씨 회사는 XP의 페어 프로그래밍(Pair programming)과 TDD를 사용중이다. 

과거 프로젝트에서는SRS를 썼는데 지금은 TDD로 바꿨다. 테스트는 거의 자동화 되어 있고 별도 테스터가 없어도 시스템에 버그는 거의 없다. A사의 경우 컨설팅을 받아 애자일을 적용했는데 들어보면 별로 애자일스럽지 않아 보인다. 마케팅적으로 요구사항이 신속히 바뀔 뿐인 것 같다. 

시스템이 복잡하여 야근도 잦은 것 같다. 또 개발자의 자유도도 낮아 보인다. 쓸데없는 문서도 많이 만들어야 하고 테스트도 오래 걸린다. 그러다 보니 시스템에는 항상 버그가 잔뜩 있다. 

이상한 점은 또 있다. 비싼 툴을 너무 많이 쓴다는 것이다. 그 친구는 실리콘밸리에서 주로 스타트업 에 많이 다녔는데, 한국 회사처럼 툴을 그렇게 많이 사용하지는 않았다고 한다. 지금 다니는 회사는 서브버전(Subversion)과 트랙(Trac)만 쓰고 있는데 회사를 지금 시작했다면 Git를 선택했을 것이라고 한다. 그렇다고 굳이 지금 서브버전을 Git로 바꿀 생각은 없다. 

나머지 필요한 툴은 간단한 스크립트로 만들어서 쓰고 있다. 그에 비해 A사를 비롯해서 많은 한국 회사들은 일단 툴을 많이 사용한다.  비싼 툴을 사는 경우도 상당히 많다. 회사 역량에 비해서 툴을 과도하게 사용하는 것은 그렇게 효율적이지 않다. 툴은 하나를 쓰더라도 제대로 사용해야 한다. 

그리고 A사는 직원들에게 노트북을 지급했다고 하는데 직원들이 노트북을 집에 가져가서 일을 하지 않는 점이 이상하다. 실리콘밸리에서 스타트업에 다니는 개발자들은 거의 노트북을 집에 가져가서 장소를 구분하지 않고 일을 한다. 개발자마다 다르지만 그 친구는 늦게 출근하고 일찍 퇴근하지만 노트북을 가지고 다니면서 장소에 구애 받지 않고 하루에 10시간 이상 일을 한다고 한다. 

A사는 야근도 꽤 많이 하지만 집에 가서는 일을 하지 않는 것이 이상해 보였다. 한국의 모든 개발자가 그런 것은 아니지만 재택근무가 일상화된 실리콘밸리와 한국은 좀 다른 것 같다. 

물론 한 개인이 한 회사를 보고 느낀 점을 얘기한 것이기 때문에 우리나라의 모든 회사가 그렇다는 것은 아니다. 그렇지만 B씨와 나눈 얘기들에서 생각해 볼 요소는 많다. 국내 여러 기업이 실리콘밸리의 개발문화와 개발방식을 적용하려고 노력하고 있지만 대부분 원리와 의미는 파악하지 못하고 수박 겉핧기 식으로 형식만 흉내를 내고 있다. 

설계는 하지만 설계를 왜 하는지를 잘 모르고 애자일을 적용하면서 그 원리를 모르고 남들은 어떻게 하는지 보고 흉내를 내는 것이다. 원리는 같지만 회사마다 적용하는 방식이 다르기 때문에 남들을 보고 흉내 내거나 인터넷이나 책을 보고 적용하면 이런 현상이 벌어진다. 

단순 흉내에서 벗어나려면 무엇을 하나 하더라도 그 진의를 파악하는데 노력해야 한다. 주변에서 흔히 "남들은 어떻게 하나요?", "템플릿(Template)을 가져다 주면 해볼께요.", "샘플을 보여주세요."와 같은 얘기를 한다. 남들이 만들어 놓은 설계서 샘플을 가져다가 흉내를 내면 자칫 아니 한만 못한 경우도 많다. 샘플이 득보다는 독이 되는 경우가 많다. 

샘플보다는 이걸 왜 하는지 원리를 파악하려고 노력해야 한다. 스스로 진의를 파악하기 어렵다면 주변에 멘토가 될만한 사람에게 물어보고 도움을 받는 것이 좋다.

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