소프트웨어 국제화 전략 (25)

소프트웨어를 이미 개발해 놓고 비즈니스가 잘되면 나중에 국제화를 적용하려고 하면 늦다는 것을 이전 글에서 살펴 보았다.

소프트웨어를 기획할 때부터 향후 1%라도 국제화 가능성이 있다면 계획에 따라서 적절한 국제화 기술을 미리 적용하는 것이 좋다. 

그럼 어떠한 경우 국제화가 필요한가?

• 국내 외에 해외에 소프트웨어를 판매하거나 서비스할 수 있다.
• 국내에서만 판매할 계획이지만, 국내의 외국인 고객이 사용할 수 있다.

그럼 소프트웨어 국제화가 필요한 경우 어떠한 국제화 전략을 어떻게 수립해야 하는지 알아보자.

국제화 적용 수준을 결정한다.

당장은 아니고 미래에 해외에 팔 계획이 있는 소프트웨어라면 초기부터 국제화 기능을 모두 적용하면 기간, 비용이 많이 든다. 이러다가 해외 판매 계획을 취소하면 국제화 투자 비용은 매몰 비용이 된다. 

따라서 판매 계획에 따라서 국제화 적용 정도를 달리하는 것이 좋다.

소프트웨어에 국제화 기능을 구현하기 위해서는 크게 2가지 모듈이 필요하다.

• 국제화 모듈 (i18n module or library)
• 지역화 모듈 (L10n module or library)

국제화 모듈은 국제화 아키텍처 전체를 다루는 모듈이고, 지역화 모듈은 하나의 국가 또는 언어 기능을 지원하는 모듈이다. (아래 그림 참조)

당장 해외 판매 계획이 있다면 위 그림 처럼 여러 지역화 모듈을 모두 만들어야 하지만, 당장은 국내에서만 판매를 하고 추후에 해외에 판매를 하려면 아래와 같이 필요한 국제화 기능만 개발을 하면 된다.

이렇게 개발을 하면 한국어 전용으로 개발하는 것보다 1~2%의 개발 비용이 더 들지만, 나중에 국제화 기능을 새로 추가하는 것보다는 10배 이상 비용을 절약할 수 있다.

국제화를 적용할 범위 결정

국제화는 매우 광범위하다.

아래는 국제화 시 고려해야할 49가지라는 지난 글이다.

https://www.allofsoftware.net/2012/09/49.html

물론 이 모두를 적용할 필요는 없다. 내용을 읽어보고 현실적으로 우리 소프트웨어에 적용해야 할 범위를 결정한다. 국제화에 대한 지식, 경험이 없다면 무엇이 필요한지 결정이 어려울 수가 있으므로 국제화 전문가나 경험자의 도움을 받는 것이 좋다.

보통 필수적으로는 아래와 같은 것들을 적용한다.

• 문자열 (번역)
• 날짜/시간
• 숫자
• 쓰기 방향 (좌우, 우좌)
• 대소문자
• 문자 정렬

시스템적으로 필수적으로 결정해야 할 기술적인 요소는 다음과 같다.

• 문자 인코딩 방법 및 변환
• Database, File, Network communication 시 사용할 문자 Encoding
• 지금은 UTF-8이 대세지만 아닌 경우도 있어서 주의해야 한다.
• 국제화에 유리한 UI 배치
• 타임존 처리

선택적으로는 소프트웨어의 종류나 특성에 따라서 추가 결정을 한다. 

• 폰트의 종류와 크기
• 화폐 단위
• 주소
• 전화번호
• 이름 표기
• 아이콘

처음에는 어려운 일이지만, 국제화 모듈을 한번 잘 만들어 놓으면 회사의 여러 소프트웨어에 재사용이 가능하다. 

국제화 조직 구성

큰 소프트웨어 조직은 국제화 팀이 별도로 있지만, 작은 조직은 별도의 팀을 갖추기가 어렵다. 그렇다면 일반 SW팀에 국제화 담당자를 별도로 지정하여 국제화 아키텍처를 설계하고, 국제화, 지역화 모듈을 개발하게 하면 된다.

모든 개발자가 국제화 기술을 다 알 필요는 없다. 국제화 담당자가 잘 만들어 놓은 기능을 그냥 써서 개발을 하면 된다.

시간을 표시하는 함수 하나도 그냥 쓰지말고 또는 본인이 직접 국제화를 적용하지 말고 국제화 담당자가 잘 만들어 놓은 국제화 시간 함수를 사용하면 되는 것이다.

국제화 담당자도 개발 초기 부터 국제화 모듈을 모두 완성해 놓을 필요는 없다. 그렇게 한다면 국제화 담당자가 국제화 모듈을 완성할 때까지 일반 개발자들은 개발을 시작할 필요가 없다.

국제화 담당자는 국제화 범위를 정하고 Interface만 정해 놓으면 된다. 즉 국제화 모듈의 Interface만 정하고 지역화 모듈은 제대로 개발할 필요가 없다.

시간 함수를 예로 들면 시간 함수의 Interface를 잘 정하고 나면 그 내용은 그냥 시간을 출력하는 함수를 최대한 간단히 구현해 놓으면 되고, 국가별 언어별로 다른 표시법은 적용할 필요가 없다.

이렇게 인터페이스를 만드는 데는 며칠 걸리지 않는다.

나중에 개발을 진행하면서 지역화 모듈의 내용을 하나씩 채워가면 지연 없이 개발이 진행된다.

국제화 마인드

국제화가 잘 된 소프트웨어를 개발하는 것은 매우 어렵다. 경험이 적으면 국제화가 누락된 소프트웨어를 개발하기 쉽다.

예를 들어보자.

사용자가 입력한 문자열을 단어별로 쪼개서 처리하려고 한다. 그래서 띄어쓰기로 token을 구분하여 처리를 했다고 하자. 하지만 띄어쓰기를 사용하지 않는 언어는 의외로 많다. 이런 곳에서는 이 기능은 제대로 동작하지 않을 것이다. 이처럼 예상치 못하게 국가별 언어별로 다른 것들이 꽤 많다.  다음과 같은 것들이 있다.

• 띄어쓰기
• 단수, 복수 처리
• 좌우 쓰기 방향
• 문장 순서
• 달력

이외에 매우 많다. 어떤 것은 해당 국가에서 이상하게 보여도 나름 용인이 되는 것도 있고, 용인이 되지 않는 것도 있고, 명백히 버그가 되는 것도 많다.

예를 들어 숫자의 소숫점은 국가별로 다르다. 숫자의 소숫점을 잘못 처리하면 명백한 버그가 되고 큰 사고가 될 수도 있다.

그래서 우리가 이러니 전세계 모든 국가에서도 이럴 것이라면 생각을 버려야 한다. 어려운 일이다. 그래서 국제화 전문가가 회사에 적어도 한명은 있으면 좋다. 그렇지 않으면 국제화 전문가의 컨설팅을 받으면 적은 비용으로 큰 문제를 해결할 수 있다.

국제화 프로세스

국제화 조직 또는 담당자는 국제화 모듈만 개발하는 것이 아니고 국제화 프로세스를 잘 정해야 한다. 국제화 초보자에게는 매우 어려운 일이지만 필요한 것이 프로세스다.

예를 들어 문자열을 번역하기 위해서는 여러 단계가 필요하다.

• 소스코드에 국제화 문자열 함수를 작성한다.
• 문자열을 추출한다.
• 추출한 문자열을 각 언어로 번역한다.
• 소프트웨어에 번역된 문자열을 적용한다.
• 검수를 한다.

국제화 프로세스는 최대한 자동화가 되어야 한다.

국제화가 누락되는 부분을 찾기 위해서는 코드 리뷰 절차에 국제화 관련 부분이 추가 되어야 한다.

그리고 테스트 프로세스에서도 국제화 부분이 추가되어야 한다.

결론

우리나라에는 수많은 회사가 소프트웨어 국제화에 실패한 역사가 있다. 초기에 소프트웨어 인코딩 결정의 실수로 대규모 서비스가 글로벌 서비스에 실패하기도 한다. 

소프트웨어 국제화의 실패로 좌초된 경우조차 그 원인을 국제화에서 찾지 못하는 경우가 대부분이다. 그래서 매우 중요하지만 아주 소홀히 하는 분야이기도 하다.

국제화는 결코 소홀히 하면 안되고, 소프트웨어 개발 초기부터 심각하게 고민하지 않으면 안된다.

[Software Spec Series 2] 소프트웨어 프로젝트 실패의 원인

우리 주변에서 실패한 소프트웨어 프로젝트를 보는 것은 어려운 일이 아니다. 프로젝트를 성공하는 방법을 배우기 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패하는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시하지 못했다.
• 소프트웨어가 요구되는 품질을 충족하지 못했다. (기능 요구사항, 성능, 안정성, 사용성, 확장성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자.

• 고객의 요구사항을 충분히 파악하지 못했다.
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당히 많은 시간을 소모하여 정작 개발 기간이 부족하게 되었다.
• 스펙과 설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 하였다.
• 작성된 스펙을 프로젝트 이해관계자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발하였다.
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어졌다.
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 하였다.
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작했다. 나중에 잘못된 코드를 고치느라고 시간이 더 소요되었다.
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕하느라고 시간을 많이 지체했다.
• 일정관리를 대충해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못했다.
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패했다.
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 했다.
• 프로젝트 팀원들의 팀워크에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트가 산으로 갔다.
• 도입한 외부 필수 기술이 기대처럼 동작하지 않았다. 이것을 프로젝트 막바지에 알게 되었다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못했다.
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해졌다.

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인은 “스펙”이다. 가장 많은 원인이 스펙과 관련이 있다. 또한 소프트웨어 버그의 절반 이상은 스펙으로부터 발생한다고 알려져 있다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가도 소프트웨어를 무사히 완성하기도 한다. 소수의 경험 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 찰떡 같이 알아듣고 개발을 잘하기도 한다. 하지만, 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 인수 테스트 계획이 필요하다.

소규모 프로젝트에서의 성공 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 반대로 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사에서는 이런 함정에 종종 빠진다. 개발은 문서대로 진행되지 않을 뿐만 아니라 문서가 너무 많아서 수시로 바뀌는 요구사항을 문서에 제대로 반영하지 못한다.

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 이해관계자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 소프트웨어 프로젝트 성공은 어렵다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다. 꾸준히 투자하는 방법 외에 기가 막힌 방법은 없다.

share with abctech.software

프로세스가 개발 문화를 이기기 어려운 이유

우리나라의 많은 기업들은 글로벌 수준의 소프트웨어 개발 역량 확보에 실패했다. 10년 전쯤부터는 막대한 자본을 투입해서 개발자 확보 및 소프트웨어 개발에 투자를 하더니 이제는 소프트웨어는 실패했다는 자성을 하고 있다. 돈과 사람을 아무리 투자해도 10년이라는 단기간(?) 내에는 글로벌 수준의 소프트웨어 개발 역량 확보는 쉽지 않다.

많은 기업들이 소프트웨어 개발 역량 확보를 위해서 주로 선택한 방법은 세계적인 방법론과 프로세스의 도입, 직원들에 대한 교육이다. 글로벌 소프트웨어 회사들이 하는 방식과 비슷하게 프로세스를 따르고 문서를 만들고 개발 환경도 비슷하게 갖추었다. 카페 같은 환경도 만들어서 자유롭게 일할 수 있도록 한 회사도 있다. 하지만 그 결과 그럭저럭 소프트웨어 프로젝트의 결과는 나왔으나 소프트웨어 개발은 더 비효율적으로 바뀌었다. 이유는 무엇일까?

감당할 수 없는 수준의 프로세스는 오히려 독이 된다. 10년이라는 짧은 시간에 아직 역량이나 문화가 성숙되지 않은 상황에서 도입한 과도한 프로세스는 소프트웨어를 효율적으로 개발하게 하기 보다는 프로세스가 주인이 되어서 효율성은 되려 떨어지게 되었다. 이런 과정에서 문제가 생기면 이를 해결하기 위해서 프로세스는 더욱 복잡해져만 갔다. 모든 회사가 그런 것은 아니지만 많은 회사가 걸어온 길이다.

소프트웨어를 가장 효율적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 그냥 개발하는 것이다. 그 적절한 과정이라는 것은 성숙된 개발 문화 속에서는 자연스럽게 선택이 된다. 하지만 회사들은 이런 애매모호한 방법을 선택할 수는 없다.  이런 방법은 이미 개발자들의 역량이 충분히 확보가 되고 성숙된 개발 문화를 갖췄을 때만 가능하다. 그래서 많은 회사들은 이런 애매하고 어려운 개발 문화 발전 보다는 명백하고 따라하기 쉬워 보이는 개발 프로세스 정교화에 집중해왔다. 그결과 큰 사고는 줄어들었지만 과거에 주먹구구식으로 개발을 할 때보다 오히려 개발 효율성은 훨씬 떨어졌다. 가끔은 프로세스의 구멍 때문에 큰 사고가 나기도 한다.

프로세스를 아무리 잘 정해도 효율적인 개발 과정을 정의하기 어려운 이유는 뭘까? 아래 대화를 보자. 수십년간 소프트웨어 실전적으로 개발을 해온 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.

Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?

A. 아니요, 그때 그때 달라요.

Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?

A. 그때 그때 달라요.

Q. 스펙은 꼭 작성해야 합니까?

A. 그때 그때 달라요.

Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?

A. 그때 그때 달라요.

Q. 설계서는 꼭 작성해야 하나요?

A. 그때 그때 달라요.

Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?

A. 그때 그때 달라요?

Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?

A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단을 믿어야 합니다.

Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.

A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발을 잘 모르는 사람들이 테일러링하기도 합니다.

Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?

A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

일반적으로 프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 개발 문화의 성숙도가 높을수록 프로세스는 간단하다. 

하지만 왜 이렇게 프로세스에 목을 맬까? 프로세스 도입은 쉽고, 개발문화 변화는 어렵기 때문이다. 골프채를 바꾸는 것은 쉬워도, 몸에 완전히 베어버린 골프 스윙을 바꾸는 것은 엄청나게 어렵다. 한사람의 생각과 행동을 바꾸기도 어려운데 전직원을 바꾸는 것은 정말 어렵다.

프로세스는 최소화로 정의하고 성숙된 개발문화를 만들어 가는데 집중하는 것이 좋다. 둘은 보완 관계이기도 하지만, 앙숙관계이기도 해서 프로세스를 너무 강조하는 환경에서는 개발문화를 발전시키기가 어렵다.

개발 문화에는 정보/지식 공유, 스펙 작성, 수평적인 조직, 전문가주의, 경력 보장, 상호 리뷰, 자율, 문서 작성 등 수많은 것들이 있다. 일일이 나열할 수는 없지만 일하는 속에서 이런 것들이 구성원들에게 자연스럽게 스며들도록 제도, 프로세스를 정의하고 독하게 추진을 해야 한다. 그래야 개발문화가 조금씩 바뀌어 나간다.

이렇게 개발문화와 프로세스가 잘 조화를 이룰 때 소프트웨어 개발 역량이 세계적인 수준이 될 수 있다. 개발에 문제가 있다고 복잡한 프로세스를 도입해서 단기적으로 해결해보려는 시도는 장기적으로는 대부분 실패할 것이다. 

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

소프트웨어 스펙은 왜 쓰기 어려운가?

스펙을 잘 쓰는 것은 소프트웨어 프로젝트를 성공하기 위한 가장 중요한 요소중 하나라는 것은 이미 수차례 강조한 얘기다.

스펙을 적절히 제대로 작성하지 않았다는 얘기는 건설에서 설계도를 제대로 만들지 않고 건설을 하는 것과 같이 소프트웨어 프로젝트에서도 여러가지 문제를 야기시킨다.

• 프로젝트가 종료 일정을 지키지 못할 가능성이 높다.
• 소프트웨어 아키텍쳐가 엉망이 될 가능성이 높다.
• 소프트웨어 품질을 보장하기 어렵다.
• 개발자들이 야근에 내몰려 혹사를 당하기 쉽다.
• 개발에 관련된 지식 축적이 어렵다.
• 추후 요구사항이 변경되어도 소프트웨어에 어떠한 파급효과가 있는지 예측하기 어렵다.
• 업그레이드 프로젝트를 효과적으로 진행하기 어렵다.

실제로 많은 회사들에서는 소프트웨어 스펙을 잘 쓰기 위해서 많은 투자를 한다. 그럼에도 왜 스펙을 잘 쓰기 어려운가? 또한 개발자들이 분석 설계를 잘 할 수 있는 뛰어난 아키텍트로 성장이 잘 안되는가?

많은 개발자들은 독학을 통해서 뛰어난 프로그래머가 되기도 한다. 하지만 왜 스펙 작성은 독학으로 잘 안되는가? 스펙은 프로그래밍보다 훨씬 많은 측면으로 분석을 해야 하고 복잡하기 때문이다. 스펙 작성은 골프와 피아노에 비견되곤 한다. 그래서 스펙 작성을 골프와 피아노에 비교를 해보았다.

소프트웨어 스펙 작성	골프	피아노	효과
책을 보고 스스로 공부해서 스펙을 적는다.	골프 잘치는 책을 보고 혼자서 연습한다.	피아노 교본을 보고 혼자서 연습한다.	역효과
강연을 듣고 필요성을 절감해서 스펙을 적는다.	타이거 우즈 특강 모임에서 깨달은 바가 있다.	피아노 잘치는 법이라는 강연을 듣는다.	미미한 효과
인터넷에서 좋다는 Template을 구해서 각 항목을 채운다.	좋다는 골프채를 구매해서 골프를 친다.	좋은 피아노를 사서 열심히 연습한다.	미미한 효과 또는 역효과
일하면서 뛰어난 선배들이 작성한 스펙을 본다.	골프 연습장에 골프를 잘치는 프로가 많아서 수시로 골프 치는 것을 볼 수 있다.	피아노 교습소에 뛰어난 피아니스트가 있어서 연주를 수시로 볼 수 있다.	좋은 환경
스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.	골프 코치에게 골프를 배우고 연습을 반복한다.	피아노 선생님에게 피아노 치는 것을 배우고 연습을 반복한다.	발전 가능성이 높은 환경
수년간 지속적으로 스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.	수년간 실전 골프를 치면서 지속적으로 골프 코치에게 스윙을 교정받고 배운다.	수년간 피아노를 치면서 지속적으로 선생님에게 피아노 치는 것을 배운다.	발전 가능성이 가장 높은 방법
본인 스스로도 타 프로젝트의 수많은 스펙의 리뷰에 참여한다.	후배들의 골프 스윙도 봐주면서 이론적으로도 지식을 쌓는다.	후배들이 피아노를 치는 것을 봐주면서 조언을 해준다.	발전 가능성이 가장 높은 방법

이쯤 설명하면 많은 회사들이 왜 스펙을 잘 작성하기 어려운지 이해가 될 것이다.

개인관점으로 보면 좋은 환경을 갖춘 곳에서 일하는 것이 가장 좋다고 할 수 있다. 회사입장에서는 회사를 좋은 환경으로 만들고 좋은 관행을 만들어야 한다. 그럼 회사가 가져야 할 좋은 관행이란 무엇이 있을까?

• 뛰어난 아키텍트를 여러명 보유한다.
• 작은 프로젝트라도 스펙을 제대로 작성하고 개발하는 문화를 만든다.
• 철저한 정보 공유, 투명한 개발 환경
• 경영진을 비롯하여 많은 프로젝트 관련자들이 스펙을 충분히 리뷰한다.

그럼 반대로 이를 저해하는 나쁜 관행들은 무엇이 있을까?

• 빠르게 개발한다는 명목하게 주먹구구식 개발을 신봉한다.
• 원칙보다 기법에 현혹되어 여러 방법론을 기웃거린다.
• 복잡한 프로세스가 문제를 해결해 줄것으로 맹신하고 강요한다.
• 코딩이 가장 중요하다고 생각한다.
• 작성된 스펙에 관심들이 없어서 리뷰에 소홀하다가 개발 후에 부담없이 변경을 요구한다.
• 상명하복의 조직문화

이런 문화에서는 뛰어난 아키텍트가 있다고 하더라도 무용지물일 뿐이다. 회사는 좋은 관행을 만들어가고 개인들은 좋은 습관을 가지도록 노력할 때 수년 후에는 스펙을 제대로 작성할 수 있는 역량을 갖추고 소프트웨어 개발 역량이 글로벌 회사들과 경쟁할 중요한 기초 역량을 갖추어 가고 있다고 할 수 있다.

share with abctech.software

핵심은 아키텍트다

우리나라에는 뛰어난 프로그래머가 참 많다. 우리나라에서 연봉 4천만원 받는 개발자의 능력과 하는 일을 보고 외국의 억대 연봉 개발자가 입이 떡 벌어졌다는 우스개 소리가 인터넷에 떠돌고 있다. 전혀 근거가 없는 얘기는 아니다. 우리나라에서는 개발자가 많은 분야의 일을 해야 하고 밤을 지새면서 엄청난 양의 일을 소화하곤 하기 때문에 일단 많이 배우고 매우 빠르고 숙달되어 있다.

​

하지만 이것도 잠깐이다. 세월이 흘러 10년차, 20년차 개발자가 되고 나면 외국의 억대 연봉을 받았던 개발자와 비교해서 분석, 설계 역량에서 많이 뒤떨어지게 된다. 결국 연봉 값을 하게 된다. 이는 개발자들의 기본적인 재능이 아니라 환경차이 때문에 벌어지는 일이다.

​

우리나라에서는 빨리빨리 문화, 상명하복 문화를 비롯해서 여러가지 환경 때문에 아무리 좋은 프로세스를 도입한다고 해도 개발자들에게 분석, 설계 역량이 차근차근 축적이 되어서 10년, 20년 후에 뛰어난 아키텍트로 성장하기가 매우 어렵다.

[사진=Pixabay]

그럼에도 불구하고 우리나라에서는 아키텍트라는 단어에 많이 집착한다. 소프트웨어업계에 아키텍트가 부족하여 발전이 안된다고 하기도 하고, 너도나도 회사에서 아키텍트라는 타이틀을 만들어 남발하기도 한다. 이렇게 아키텍트에 집착하는 것은 여전히 뛰어난 아키텍트가 많이 없어 그에 따른 갈증이 있기 때문으로 해석된다.

​

이런 현상은 비단 소프트웨어 업계만의 문제는 아니다. 우리나라는 여러 산업분야에서 선진국을 빠르게 따라 잡으면서 실행력은 앞서기도 한다. 하지만 시스템 설계 능력은 겉모습을 보고 따라잡을 수 있는 것이 아니다. 선배에서 후배로 여러 세대를 거치면서 축적된 경험과 노하우가 전승되어 와야 하는 것이라서 우리끼리 독학으로 따라잡을 수는 없는 것이 당연하다.

​

■ 비즈니스 이해해야 좋은 아키텍처 나와

​

소프트웨어 아키텍트는 어떤 사람을 말하는 것인가?

​

한마디로 정의하면 소프트웨어 시스템을 설계하는 사람이다. 소프트웨어 시스템을 작은 모듈까지 축소하면 대부분의 개발자들은 아키텍트이기도 하지만 이슈가 되는 것은 상당히 커다란 시스템을 설계할 수 있는 능력을 가진 사람이 아키텍트다.

​

누구나 하기도 하고 누구나 잘할 수 있을 것 같은 소프트웨어 분석 설계가 어려운 이유는 아키텍트는 일반 개발자 또는 프로그래머와는 완전히 다른 역량을 요구하기 때문이다.

​

좋은 아키텍처는 비즈니스에 대한 이해에서 나온다. 대부분은 현재뿐만 아니라 미래 비즈니스 전략도 잘 알아야 한다. 또한 기술적으로도 상당 수준이어야 한다. 업무에 빠삭한 도메인전문가(업무전문가)와는 또 다르다. 문서로 소프트웨어 스펙이나 설계서를 작성할 수 있어야 하고 다른 사람이 이 문서를 보고 소프트웨어를 개발 할 수 있어야 한다. 의외로 이런 역량을 고루 갖추고 있는 뛰어난 소프트웨어 아키텍트는 흔하지 않다.

​

우리나라는 도메인 전문가가 나름 그 역할을 하고 있다. 업무는 모르는 것이 없이 잘 알지만 분석, 설계 역량은 떨어지고 문서로 스펙과 설계를 작성해서 다른 사람에게 일을 시키지 못하기 때문에 옆에 붙어서 설명을 너무 많이 해줘야 하고, 개발 도중 문제가 생길 때마다 해박한 업무 지식으로 문제를 해결해 나간다. 물론 개발 효율성은 떨어질 수 밖에서 없다.

​

왜 소프트웨어 회사에 뛰어난 아키텍트가 필요한가?

​

개발자 3~4명이 진행하는 소규모 프로젝트는 어떻게 개발을 하든지 소프트웨어 개발이 가능하다. 각 개발자들의 프로그래밍 역량이 뛰어나다면 매우 훌륭한 소프트웨어도 만들 수 있다. 하지만 규모가 점점 커지면 개별 프로그래머들의 역량이 뛰어나다고 성공적으로 소프트웨어를 만들기는 어렵다.

​

개발 복잡도는 소프트웨어 규모에 기하급수로 비례해서 복잡해진다. 또한, 어찌어찌 소프트웨어 개발에 성공을 했다고 하더라도 몇 년 안에 더 큰 문제가 나타난다.

​

설계가 제대로 되지 않은 소프트웨어는 업그레이드를 할수록 아키텍처가 복잡해지고 곧 유지보수가 새로 개발하는 것보다 어려운 시점이 오게 된다. 물론 회사에 뛰어난 아키텍트가 있는 경우에도 프로젝트

일정이나 복잡한 프로세스에 밀려서 아키텍처를 소홀히 하곤 한다. 그 대가는 미래에 꼭 몇배로 치르게 되어 있다.

​

■ "국내엔 축적된 노하우 계승해줄 선배들 부족"

​

그럼, 왜 우리나라에는 소프트웨어 아키텍트가 부족한가?

​

빨리 빨리 개발 문화부터 상명하복 조직 문화 등 간접적인 원인도 너무나 많지만 가장 큰 원인은 축적된 아키텍처링 노하우를 계승 시켜줄 선배들이 부족하기 때문이다. 그러다 보니 개발 기술은 발달을 하는데 커다란 소프트웨어 시스템을 설계해서 수십, 수백명이 체계적으로 일을 나눠서 문서를 보고 개발을 하는 경험을 해볼 환경이 거의 없다.

​

소프트웨어 설계에 관련된 좋은 책은 많지만 골프 책이 아무리 많다고 골프 코치가 없으면 소용이 없다. 프로그래밍은 코치가 없어도 책을 보고 배울 수 있는 분야다. 하지만 분석과 설계는 코치 없이 배우는 것이 불가능하다. 또한, 몇 개월 가지고는 부족하다. 수년간 같이 일하면서 노하우를 전승 받아야 한다.

​

아키텍트를 양성하기 위해서 회사들은 어떤 노력들을 하고 있는가?

​

대학에서 요구공학이나 소프트웨어 아키텍처 디자인 관련된 강좌 코스에 직원들을 보내기도 하고, 강사를 초빙해서 강의를 듣기도 한다. 물론 다 도움이 되는 일이지만 기대만큼 빠른 성과가 나지는 않는다. 시험을 통해서 아키텍트 양성 후보를 선발하기도 한다. 알고리즘 시험을 보기도 하는데 그런 방법은 고참 개발자는 아키텍트 후보가 된다는 이상한 공식이 성립하기도 한다.

​

이렇게 자생적으로 소프트웨어 아키텍트를 양성하기 위해서 피나는 노력을 하지만 기대만큼 단기간에 성과가 나고 있지 않다. 물론

수십년 동안 노력을 한다면 분명히 성과가 있겠지만, 수십년을 기다릴 만큼 인내심을 가진 회사는 거의 없다. 결국 제도와 프로세스로 강제화를 하지만 이 문제는 그렇게 해결이 되지 않는다. 오히려 방해가 된다.

​

그럼 아키텍트는 어떻게 양성해야 하는가?

​

교육도 좋고 뛰어난 아키텍트를 영입하는 것도 좋은 방법이다. 하지만 가장 좋은 것은 좋은 관행들을 지속적으로 유지하는 것이다.

■ 아키텍트를 양성하는 세 가지 방법

​

첫째, 소프트웨어를 개발할 때 분석, 설계를 제대로 해서 진행하는 것이다. 물론 문서로 제대로 작성하고 서로 리뷰하고 진행해야 한다. 이런 경험들이 축적되어야 한다. 급하다고 빨리 코딩부터 시작하는 경우가 있는데 그러면 프로젝트는 더 오래 걸리고 노하우가 축적되지 않는다. 물론 학습비용이 필요하기 때문에 처음에는 코딩부터 빨리 시작하는 것이 더 빨리 개발하는 방법일 수도 있다. 하지만 시간이 흐를수록 프로젝트는 더 오래 걸릴 것이다.

​

둘째, 아키텍트 그룹을 운영하는 것이다. 보통은 가상 조직으로서 Technical Steering Committee나 Architect Group과 같은 이름을 가진다. 회사의 중요한 기술적인 이슈를 논의하고 결정하는 위원회이며 분석, 설계 문서를 집중적으로 리뷰하기도 한다. 아키텍트 후보로 선발된 인원은 이 조직에 참여하여 수년간의 훈련을 받으면 자연스럽게 아키텍트로 성장하게 된다.

​

셋째, 아키텍트 후보를 선발하는 것이다. 앞으로 아키텍트로 성장할 가능성이 높은 개발자를 후보로 선발하여 수년간 훈련을 시켜야 한다. 물론, 아키텍트는 우수하고 일반 프로그래머는 우수하지 않다는 것이 아니다. 성향이 다를 뿐이다. 그리고 성향에 따라서 적합한 일이 좀 다를 뿐이다. 아키텍트로 성장하려면 다음과 같은 성향이나 소질이 있어야 한다. 글을 잘 쓰고, 다른 사람의 얘기를 잘 들어주고, 창의력이 좋고, 분석적으로 사고를 하고, 정보를 잘 조직화하고, 꼼꼼하며, 논리적인 사고를 하고, 문제의 핵심을 잘 찾고, 인내심이 좋아야 한다. 이를 모두 만족하는 사람은 없지만 몇가지가 일치하면 후보로 선발하여 키워야 한다.

​

막상 얘기를 해보면 회사에 꼭 필요한 아키텍트를 키우는 데는 기가 막힌 방법이 없다. 골프를 잘 배워서 잘 치는데 기가 막힌 방법이 없는 것과 같다. 물론 잘못 배워서 잘못치는 방법은 부지기수로 많다. 좋은 환경에서 뛰어난 선배들이 좋은 관행을 유지하며 꾸준히 후배들을 가르쳐 주는 것이 가장 보편적인 방법이다. 이렇게 실무를 통해서 배우는 것이 학교에서 수업을 배우는 것보다 몇십배 더 많은 것을 배울 수 있다.

​

조급하다고 되는 것도 아니고, 프로세스로 강제화 한다고 되는 것도 아니다. 뛰어난 소프트웨어 아키텍트를 여러 명 보유하는 것은 회사의 미래를 결정짓는 결정적인 요소이기 때문에 무시할 수도 없다. 꾸준한 투자를 해야 한다.

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

소프트웨어 프로젝트는 왜 실패하는가?

우리는 주변에서 실패한 소프트웨어 프로젝트를 보는 것이 그리 어려운 일은 아니다. 프로젝트의 규모가 커지고 기간이 길어지며 많은 인원이 투입될수록 프로젝트 실패 확률은 증가한다. 

프로젝트 성공을 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패했는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시 못했다.
• 소프트웨어가 시장에서 요구되는 품질을 충족하지 못했다. (요구사항, 성능, 안정성, 사용성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자. 

• 고객의 요구사항을 충분히 파악하지 못함
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당부분의 시간을 소모하여 개발 기간이 부족하게 됨
• 스펙/설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 함
• 작성된 스펙을 관련자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발함
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어짐
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 함
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작함. 나중에 잘못된 코드를 고치느라고 시간이 더 소요됨
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕함
• 일정관리를 대충 해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못함
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패함
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 함
• 프로젝트 팀원들의 팀웍에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트는 산으로 감
• 도입한 외부 필수 기술이 기대처럼 동작하지 않는다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못함
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해짐

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 간단히 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인을 “스펙"이라고 생각한다. 

다른 영역도 중요한 것이 사실이지만 스펙을 적는 것은 소프트웨어를 개발하는데 가장 중요하면서 가장 어렵다. 스펙을 적는 것을 “분석” 또는 “분석/설계”라고 한다. 설계가 여기에 왜 포함되었는지 의아한 사람도 있을 텐데, 분석 시에 상위 설계의 상당부분이 포함이 되는 경우가 많고 프로젝트에 따라서 다르지만 분석과 설계는 그 경계가 모호하기 때문에 같이 다루는 경우가 많다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가면서 소프트웨어가 무사히 완성을 하기도 한다. 소수의 경험이 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 개발을 잘하기도 한다. 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 테스트 문서도 전달하기도 한다.

소규모 프로젝트에서의 성공의 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사들에서는 이런 함정에 종종 빠진다. 개발은 문서대로 되지도 않을 뿐만 아니라 수시로 바뀌는 요구사항을 문서가 너무 많아서 문서에 반영도 제대로 못한다.

 

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 관련자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 말짱 공염불일 뿐이다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다.

이 방대한 얘기를 짧은 글로 어떻게 소개할 수 있을지 걱정은 되지만, 개발자가 어떻게 하면 소프트웨어 분석, 설계 역량을 가질 수 있으며 회사는 어떻게 그런 역량을 축적할 수 있는지 다음에 몇 개의 글을 통해서 조금 더 자세히 얘기를 해보고자 한다.

share with abctech.software

소프트웨어 회사에서 '공유'가 진짜 어려운 이유

많은 사람들이 소프트웨어 회사에서 가장 중요한 기업 문화 중 하나로 '공유 문화'를 꼽는다. 비단 소프트웨어 회사만의 이슈는 아닐 것이다.

​

공유에 문화라는 이름이 붙으려면 구성원 대부분이 자연스럽고 일상적으로 정보를 공유해야 한다. 공유가 중요한 이유는 소프트웨어 개발은 집단지성이 작동해야 하는 대규모 지식 산업이기 때문이다. 정보와 지식이 한사람의 머리 속에 머무르지 않고 시스템에 저장되고 효율적으로 관리되어야 비로소 경쟁력을 가질 수 있다.

​

소수의 슈퍼 개발자가 주도해서 성공한 소프트웨어 회사들이 벽을 못 넘는 이유 중 하나도 '공유문화' 부족이라고 볼 수 있다.

​

많은 회사들이 “공유문화”를 정착시키기 위해서 당근과 채찍을 동원하지만 제대로 된 '공유문화'를 가지고 있는 회사가 그렇게 많지는 않다. 필자가 경영을 하고 있는 이우소프트도 아직 완벽하지는 않지만 '공유문화' 정착을 위해서 5~6년간 치열한 노력을 해오고 있다.

​

직원들에게 “공유를 잘하자”라고 말하는 것은 “착하게 살자”라는 정도밖에 들리지 않는다. '공유 문화'가 정착되지 않은 회사에서는 직원들 자율에 맡겨 놔도 '공유 문화'가 정착되기는 어렵고, 프로세스로 강제화해서는 더욱 어렵다.

​

'공유 문화' 정착이 어려운 이유는 '죄수 딜레마'와 같다. 또한 '교차로 꼬리 물기'와 비슷하다. 교차로에서 신호가 끊겼는데도 바짝 따라붙으면 이로 인해서 다른 방향의 차들은 소통이 안되고 연속으로 차들이 꼬리 물기를 해서 교차로가 꽉 막힌다. 교차로 꼬리 물기를 해결하고 교차로에서 가장 많은 차들이 통과되는 비법은 모든 차들이 꼬리 물기를 하지 않는 것이다.

하지만, 아무리 캠페인을 해도 '교차로 꼬리 물기'가 사라지지 않는 이유는 모두다 규칙을 잘 지키면 서로 혜택을 누릴 수 있지만 누구는 지키고 누구는 지키지 않는 상황에서는 규칙을 지키는 사람이 더 손해를 보기 때문이다. 규칙을 지키지 않아서 이익을 보는 사람은 계속 이익을 보고 규칙을 지켜서 손해를 보는 사람은 계속 손해를 본다면 사람들은 자연스럽게 규칙을 지키지 않는 쪽으로 넘어온다.

​

게다가 '공유를 하지 않는 행동'은 '교차로 꼬리 물기'처럼 눈에 잘 보이지는 않는다. 제대로 공유를 안해도 공유를 안하고 있다는 사실을 완전히 눈치채기는 쉽지 않다.

​

또한, 자신이 알고 있는 정보를 모두에게 공유하는 것은 자신이 없어도 회사가 돌아간다는 의미로 해석이 되어 매우 불안한 일이 아닐 수 없다. 그래서 어쩔 수 없이 꼭 공유해야 하는 소량의 정보만 공유를 하고 핵심 지식 정보는 공유를 안하기도 한다.

​

'공유 문화'에 대해서 서로 얘기를 해도 생각하는 정도가 달라서 잘하고 있는 것인지 개선할 것이 많이 필요한지 판단하기는 매우 어렵다. 그래서 필자가 간단한 평가표를 만들었다. 10점 만점에 8점이상이면 공유 문화가 매우 잘 정착된 회사라고 생각된다. 그 이하라면 심각하게 '공유 문화' 개선에 대해서 생각해봐야겠다. 평가방법은 아래 각 항목당 1점으로 계산하면 된다.

​

1. 내가 지금 이 순간 회사에서 없어져도 내가 하던 일은 즉시 누군가가 이어받아서 문제없이 진행된다.
2. 어제 회사에 있었던 크고 작은 모든 회의의 회의록이 시스템에 등록되어 있고 누구나 열람이 가능하다.
3. 모든 개발자들(직원)이 서로 다른 나라에서 뿔뿔이 흩어져 있어도 지장없이 일할 수 있다.
4. 나는 회사 Email 시스템에 저장된 모든 Email이 지금 즉시 사라져도 일하는데 전혀 지장이 없다.
5. 나는 지금 이 순간 시스템을 열어서 나의 팀, 부서 모든 인원이 하고 있는 일과 그 통계를 1분안에 알 수 있다.
6. 나는 공유를 위해서 별도로 문서를 작성하지는 않는다. 일을 하다 보면 필요한 문서는 자연스럽게 생성된다.
7. 나를 비롯한 모든 직원에게 회사의 99% 이상의 정보가 실시간으로 공유된다. 공유가 안되는 정보는 극소수에 불과하다.
8. 내가 지금 하고 있는 모든 일은 시스템에 등록되어 있고 계획, 진행상황, 결과가 실시간으로 기록된다.
9. 필요한 정보를 찾기 위해서 이 파일, 저 파일 뒤질 필요 없어 몇개의 검색어로 몇 분 안에 원하는 정보를 찾을 수 있다.
10. 상급관리자나 경영진에게 보고를 하기 위해서 일을 하는 것과는 별도로 PPT를 이용해서 보고서를 만드는 일은 거의 없다.

​

필자의 회사도 5~6년 전에는 0점에 가까웠지만 꾸준한 노력 끝에 지금은 8~9점으로 평가할 수 있다. 증상에 따라서 처방이 다르기는 하지만 필자가 경험한 몇가지 공유 문화 개선 방법을 제시하고자 한다.

​

• 이슈관리시스템, Wiki 등 공유와 협업을 위한 최소한의 시스템을 구축하고 내제화해야 한다. 수단 없이 문화를 이룩하기는 매우 어렵다.
• 전화나 구두로 논의하고 지시하는 것은 가급적 삼가해야 한다. 메신저도 마찬가지다. 그런 방식은 공유도 안되고 추적도 안된다. 구두로 지시한 것도 시스템에 등록하고 업무를 진행해야 한다. 예외가 있어서는 안된다.
• 이메일은 안쓰는 것이 좋다. 과거에는 이메일이 업무 혁신의 선두에 있었다면 이제는 골치 덩어리다. 이메일을 정보 보관 수단으로 사용하기 때문에 문제인 것이다. 이메일을 금지하면 자연스럽게 정보는 공유 시스템에 저장된다. 파격적이지만 이우소프트에서는 직원간 이메일이 금지되어 있다. 이메일은 외부용이다.
• 회의는 10%로 축소해야 한다. 회의가 많은 것은 공유가 잘 안되고 있다는 증거다. 회의를 통제하면 어쩔 수 없이 시스템을 통해서 의논을 하게 된다. 회의는 꼭 필요할 때만 해야 한다.
• 보고서는 최소화 해야 한다. 지금의 90%는 폐지한다는 생각을 해보자. 보고서가 많다는 것은 공유가 잘 안되고 있다는 증거다. 경영진도 모든 구성원과 동일한 입장에서 시스템을 통해서 공유를 받고 꼭 필요한 경우에만 보고를 받는 것이 좋다.
• 수평적 사고가 필요하다. 상하 조직 구조에 따른 정보 쏠림 현상을 방지해야 한다. 경영자라고 정보 특별 대우가 없다. 누구에게나 모든 정보가 공유되어야 하며, 의견도 마음껏 개진할 수 있어야 한다.
• “공유”를 위해 프로세스를 강제화하기 보다는 인식 전환을 위해서 더 힘써야 한다. 강제적인 추진은 부작용만 부른다. 적절한 강제 조치도 필요하지만 마인드를 바꾸는데 더 힘써야 한다.
• 정보의 홍수를 경계해야 한다. 정보가 너무 많으면 방관자가 될 수도 있으므로 필수 관련자를 잘 구분하여 필수 인원이 방관자가 되지 않도록 해야 한다. 너무 많은 정보가 쏟아지만 정보는 쓰레기가 된다. 수많은 정보 중에서 자신이 추적, 관여할 정보들을 추리고 체계적으로 볼 수 있는 시스템이 필요하다.
• 공유를 위해서 정보를 생성하는 것도 중요하지만 내용이 바뀌면 업데이트하고 자연스럽게 흩어진 정보를 모으고 정리하며, 적절히 삭제하는 것도 중요하다. 이런 노력을 들여야 공유의 효율성이 올라가고 잘못된 정보로 인한 문제를 방지한다. 이런 활동을 조직내에 심기 위해서는 끊임없는 코칭이 필요하다.
• 공유 문화가 어느 정도 수준에 오르면 효율적인 글쓰기가 얼마나 중요한지 알게 될 것이다. 직원들을 뽑을 때 지식이 많은 직원도 좋지만 글도 잘 쓰는 직원을 뽑아야 한다. 개발자도 예외는 아니다. 감동을 주는 글을 적어야 한다는 것이 아니고 자신의 생각을 정확하게 전달할 수 있도록 짧고 명료하게 글을 쓸 수 있는 능력이 필요하다.

​

이 글을 보면 비법을 공개했다고 회사 관계자들은 걱정할지 모르겠지만 비법은 별것이 없다. 골프를 잘 치는 방법은 책에 모두 나와 있지만 끊임없이 제대로 노력을 해야 골프를 잘 칠 수 있다. 다같이 노력해서 대한민국에 좋은 공유문화를 가진 회사가 많아지면 좋겠다.

​

문화는 '집단의 습관'이다. 구성원들끼리 더이상 공유하라는 얘기를 안할 때 “문화”가 된 것이다. 한번 자유를 맛 본 사람들은 자유를 박탈당한 환경에서 살기 어렵듯이 진정한 공유 문화를 맛보고 나면 과거로 돌아가는 것은 거의 불가능하다. “공유”가 숨쉬는 것처럼 자연스러워질 때 비로서 글로벌 회사들과 경쟁을 한다고 명함을 내밀 수 있을 것이다.

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

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

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

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

남녀 차별이 없다.

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

아키텍트가 있다.

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

관리만 하는 개발팀장이 없다.

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

전문가가 있다.

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

영어 이름이 있다.

• 모든 직원이 서로 영어 이름을 부르고 한국 이름은 사용이 금지되어 있다.
• 팀장님과 같은 직책으로 부르는 것도 금지되어 있다.
• 수평적인 생각을 정착하기 위해서 영어 이름을 사용하며 모두 동일한 존칭을 사용한다.

직급에 따른 서열이 없다.

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

잔디밭이 있다.

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

운동 시설이 있다.

• 체육관, GX, 웨이트 트레이닝, 골프 등의 시설이 직원들에게 제공된다.
• 건강관리를 위해서 꾸준히 운동을 할 것을 권장하며 여러 종목의 코치를 채용하여 운동을 지도하고 있다. 물론, 자기 계발과 운동을 할 수 있는 시간을 보장한다.

파티션이 없다.

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

어린이집이 있다.

• 직원에게는 무료로 제공되는 어린이집이 있다.
• 출생 6개월부터 초등학교 입학 전까지 보육을 할 수 있다.
• 자녀와 같이 출퇴근을 할 수 있다.

회의록이 있다.

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

코리안 타임이 없다.

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

전문 PM이 있다.

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

일정 강요가 없다.

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

몰입이 있다.

• 하루 8시간 업무에 완전히 몰입해야 한다.

야근이 없다.

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

스펙이 있다.

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

일정이 지연되는 프로젝트가 없다.

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

60세 개발자가 있다.

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

보고서가 없다.

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

재택근무가 있다.

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

서울에도 스마트워크 센터가 있다.

• 본사에 동탄에 있는만큼 서울 북부 거주자 등 지역적인 어려움이 있는 직원들은 서울에 있는 스마트워크 센터에서 일할 수 있다.

E-mail이 없다.

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

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

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

피어 리뷰가 있다.

• 개발자가 작성하는 코드 대부분을 리뷰한다. 리뷰를 통해서 버그를 찾고 공유, 학습을 한다.
• 더 중요한 것은 스펙, 설계 리뷰다.
• 개발자는 자신의 업무시간의 20%는 동료를 위한 리뷰에 사용해야 한다.
• 시니어 개발자는 20% 이상을 리뷰에 할애한다.

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

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

즉석 라면이 있다.

• 회사 식당에서 제공하는 아침 메뉴 중에는 즉석 라면이 있다.
• 요리사가 별도로 맛을 낸 해장 라면을 즉석에서 끓여주고 충무김밥이 제공된다.

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

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

SW회사에는 왜 수평적인 조직문화가 필요한가?

한국 소프트웨어 개발 환경이 이렇게 열악하고 기업의 소프트웨어 경쟁력이 미천한 이유의 핵심은 글로벌 소프트웨어 회사와는 엄청나게 다른 개발문화, 기업문화 때문이라고 생각한다. 그래서 필자는 지속적으로 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례도 공유하고 있다.

​

이번에는 소프트웨어 회사에 왜 수평적인 조직문화가 꼭 필요한지 설명하려고 한다.

​

한국 대기업을 다니는 외국인 직원이나 외국에 있는 한국 회사에 다니는 외국인들의 한국 회사에 대한 평가는 인터넷에 많이 올라온다. '글래스도어'도 그 중에 하나고 필자는 대기업에서 일하고 있는 외국인 개발자들을 인터뷰하기도 했었다.

​

좋은 얘기도 많지만, 문제를 찾아야 하는 입장에서 문제점으로 지적된 것을 봐야 한다. 그 중에 대표적인 것은 한국 기업은 '군대'와 비슷하다는 것이다. 군대식 상하 조직이 한국 사람들에게는 상당히 자연스러운데 이런 조직 문화는 소프트웨어를 개발하는데 있어서는 심각한 걸림돌이 된다. '까라면 까라'로 대표되는 군대식 상명하복 문화를 가지고는 글로벌 회사들과 경쟁하기 어렵다. 어렵사리 글로벌 시장에 진출하여 세계 상위권에 올라섰다고 하더라도 곪은 문제는 언젠간 터지게 마련이고 나락으로 떨어지는 것은 한 순간이다.

​

소프트웨어는 인류가 만들어 낸 가장 복잡한 지식 산업이다. 물론 상명하복식 조직 문화가 매우 효과적인 산업 분야도 있다. 하지만 창의적인 지식 산업인 소프트웨어 분야에서는 상명하복식으로 성장할 수 있는 데는 한계가 있다.

​

상급자가 모든 것을 알 수는 없다. 경영자도 소프트웨어 개발에 대한 모든 것을 알 수가 없다. 그런데도 경영이나 영업 관점으로 목표를 제시하고 '까라면 까라는 식'으로 일을 추진하면 시한폭탄을 계속 심는 것과 다를 바가 없다. 개발에 1년이 걸릴 프로젝트를 시장 상황 때문에 6개월안에 개발을 하려면 전문가들이 머리를 맞대고 합리적인 단축 방법을 찾을 수도 있다. 하지만 합리적인 해결책은 무시하고 명령식으로 압박을 하면 프로젝트는 어찌어찌 진행이 되지만 중요한 핵심 프로세스들이 생략될 수밖에 없다.

​

코딩은 빼먹을 수가 없으니, 스펙을 대충 정하거나 분석도 하지 않고 코딩을 시작해야 하며, 설계도 없거나 부실하고, QA도 대충할 수 밖에 없다. 어떻게든 결과가 나왔다고 하더라도 출시 후에 더 큰 비용을 치르거나 또 하나의 시한폭탄을 심어 놓은 상황이 된다.

​

이런 일이 벌어지는 이유는 상하관계가 확실하고 윗사람이 거의 생사여탈권에 가까운 평가권과 인사권을 가지고 있고 아랫사람은 윗사람과 특히 최고 경영자의 눈치를 심하게 봐야 하는 기업 문화 때문이다. 이런 조직에서 성장해온 관리자들은 어렵게 획득한 막강한 권한을 내려 놓기는 쉽지 않다. 자신 혼자 내려 놓을 수 있는 것도 아니다. 그래서 기존 조직, 특히 대기업이나 중견기업이 수평적인 조직으로 바뀌는 것은 거의 불가능하다.

​

수평적인 조직이란 모든 직원이 평등하다는 것을 말하는 것이 아니다. 각자 전문가로서 역할을 할 수 있어야 하며, 전문가로서 목소리를 낼 수 있어야 하며, 전문가로서 제시한 의견을 존중 받아야 한다는 의미다. 이때 직급, 나이, 경력은 의미가 없다. 상하 관계가 아닌 전문가로서의 의견이 잘 조율돼서 조직이 할 수 있는 최선의 결정을 내릴 수 있어야 경쟁력을 갖출 수 있다.

​

그럼 필자가 CEO로 있는 이우소프트의 수평적인 조직문화에 대해서 소개를 하겠다.

​

수평적인 조직문화는 다른 모든 조직 문화를 떠받치는 기초와 같다. 자율, 토론, 차근차근, 전문가 존중 등 이우소프트가 지향하는 기업 문화는 상명하복 문화가 철저한 조직에서는 잘 작동하지 않는다. 그래서 수평적인 조직 문화를 정착하기 위해서 많은 노력을 했다.

​

첫째, 모두 영어 이름을 부른다.

​

영어 이름을 부르는 것은 단순히 유행을 따르는 것은 아니다. 호칭은 사람의 생각을 지배하고 존칭과 하대가 섞인 대화에서는 상하 관계가 떠오를 수밖에 없다. 그래서 많은 회사들이 호칭 개혁을 하려고 '~님', '~프로' 등 다양한 시도를 하지만 제대로 정착된 곳이 많지는 않다. 하지만 영어 이름을 부르는 것은 이미 검증된 방법이다. 영어이름을 부르면 직급을 부르지 않아도 되고, 제3자가 보더라도 상하 관계를 읽을 수가 없다.

​

그래서 이우소프트에서는 서로 영어 이름을 부르고 있고 영어 이름을 부를 때 존칭을 사용하는 것은 금지되어 있다. 모든 사람이 서로 존대를 하되 '~께서'라고 부르는 것도 금지되어 있다. 내 영어 이름은 레이몬드(Raymond)인데, "레이몬드께서 그렇게 말씀 하셨습니다."는 금지된 표현이고 "레이몬드가 그렇게 말했습니다."가 허용된 표현이다.

​

직책을 부르는 것도 금지되어 있다. 팀장님, 대표님과 같은 호칭도 부르지 못하도록 되어 있다. 적응하는데 시간이 꽤 걸렸고, 한국 이름을 부르거나 직책을 부르면 1,000원씩 벌금을 내야 하고, 이제는 완전히 정착이 되었다. 그렇게 모인 벌금은 연말에 불우이웃 돕기를 하기로 되어 있다.

​

특히, 신입 사원들은 가장 빨리 적응을 했다. 각자 직급은 나눠져 있기는 하지만 부르지 않기 때문에 서로의 그레이드(Grade)를 잘 모르고 있다. 회사에 외국인 개발자는 점점 늘고 있고, 영어 사용이 늘고 있어서 영어 호칭이 도움이 되고 있다.

​

둘째, 상하 관계로 의사 결정을 하지 않는다.

​

즉, 전문가를 존중한다. 수평적으로 나뉜 역할에 의해서 대부분의 결정을 한다. 소프트웨어 회사에는 수많은 전문 역할이 있다. 소프트웨어 엔지니어(Software Engineer), 소프트웨어 아키텍트(Software Architect), CTO, 프로젝트 매니저(Project Manager), 프로덕트 매니저(Product Manager), 리스크 매니저(Risk Manager), 빌드 엔지니어(Build Engineer), 테크니컬 라이터(Technical writer), 마케터(Marketer), UI 디자이너, QA 엔지니어, 형상 관리자(Configuration Manager) 등 여러 역할이 있다.

​

물론 작은 회사는 한 사람이 여러 역할을 하며 이 모두를 다하기도 한다. 하지만, 회사가 조금만 커져도 역할을 나누며 각각 전문성을 높여 나간다. 그리고 전문가의 의견을 최대한 존중하고 상하 관계로 의사결정의 뒤엎지 않는다. 자신의 전문 역할이 아니라도 의견을 제시할 수는 있고 토론을 할 수는 있지만 무리하게 남의 전문영역에 침범을 하면 안 된다.

​

"전권을 주면 내가 프로젝트를 성공시켜보겠다"라고 말하는 사람들이 있다. 이우소프트에서는 이런 말은 통하지 않는다.

​

제품의 기능을 결정할 때는 세일즈, 마케팅, 개발팀, 경영진의 의견은 대부분 상충된다. 이때 직급의 힘으로 의사 결정을 하지 않는다. 각자 전문가로 역할을 수행하며 논쟁을 하고 경영진은 회사의 비전과 프로젝트의 목표에 알맞게 균형을 맞추고 조율하는 일을 주로 한다. 직원을 채용할 때도 신입이나 주니어 급 직원은 상관없지만 경험이 많은 직원을 채용할 때는 권위의식이 있는지 상명하복에 익숙한지 잘 살핀다.

​

셋째, 허락 받고 일하기 보다는 자율적으로 일한다.

​

상사가 일을 시키고 하급자는 시키는 일을 하는 구조가 아니다. 대부분은 스스로 일을 찾고, 스스로 할 일을 정해서 한다. 물론 시켜서 하는 일도 있다. 하지만 능동적으로 스스로 일을 찾아서 하는 것을 권장하고 있고, 하는 일은 모두 시스템에 등록을 하기 때문에 팀장이나 동료들이 모두 모니터링을 할 수 있다. 가끔 일이 잘못 진행되거나 우선순위 조절에 문제가 생기기도 하지만 모니터링을 하다가 바로 잡아주면 된다.

​

업무의 자율성을 높이기 위해서는 뭔가 잘못되었을 때 처벌을 강조하면 안 된다. 처벌이 강할수록 수동적으로 바뀐다. 그리고 문제가 생겼을 때는 여러 사람의 공동책임이다. 시스템에 일을 너무 늦게 공유를 했거나, 모니터링을 소홀히 했을 수가 있다. 프로세스를 잘못 이해하고 있을 수도 있다. 처벌보다는 원인을 찾아서 개선을 해야 한다. 고의로 잘못을 한 것이 아니라면 직원의 일방적인 책임은 아니다.

​

이런 방식이 허락 받고 일하거나 시키는 것 위주로 일하는 것보다는 훨씬 생산성이 높다. 기본적으로 시키는 일보다는 자신이 선택한 일이 더 재미있고 집중도도 높다. 또한 자율성, 창의성이 향상되므로 업무 효율성은 훨씬 높아진다. 물론 모든 직원이 다 적극적이고 능동적인 것은 아니다. 여러 성격의 직원들이 섞여 있지만, 능동적인 직원들의 발전이 더 빠르다. 시키는 일만을 위주로 회사가 돌아간다면 창의적인 지식산업이 소프트웨어가 노동 산업으로 전락할 수가 있다.

​

이우소프트가 이렇게 수평적인 조직문화를 잘 정착한 데는 이유가 있다. 실리콘밸리에서 20년동안 개발을 한 CTO와 수평적인 문화를 당연하게 받아들이는 경영진이 있어서 가능했다. 오히려 직원들이 수평적인 조직문화에 적응하는데 시간이 걸렸다. 한국 대기업들이 수평적이고 자율적인 문화로 조직문화를 탈바꿈하는 것이 쉽지 않은 이유다. 마음만 먹는다고 바뀌는 것도 아니고 경영진은 여전히 무소불위의 권력을 행사하면서 직원들끼리 수평적인 조직문화를 만들 수는 없다. 문화란 대물림이 되고 바뀌기 매우 어렵기 때문에 외국인을 채용하거나 외국 회사를 흡수 합병해도 그들의 문화는 사라지고 기존의 상명하복 문화에 억지로 적응해야 하는 상황이 벌어진다.

​

수평적인 조직문화는 다른 문화의 기반이 되기 때문에 특히 더 중요하다. 수평적인 조직문화 하에서 공유와 협업이 더 잘되며 전문가로서 캐리어를 꾸준히 유지하기도 쉽다. 사규를 만든다고 되는 것도 아니다. 모두의 생각이 바뀌어야 한다. 경영진들이 먼저 수평적인 조직문화에 완전히 적응을 해야 직원들이 따라 올 수 있다.

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

이우소프트에서 개발자를 채용하는 방법

최고의 개발자들이 최고의 소프트웨어를 만든다.

그래서 뛰어난 개발자를 채용하는 것은 소프트웨어 회사에서 가장 중요한 일이다. 그럼, 뛰어난 개발자의 정의는 무엇일까?

필자는 대한민국의 여러 벤처기업, 대기업, 중소기업, 실리콘밸리의 회사들에 대한 기업 문화를 두루 경험하고 봐왔기 때문에 나름 노하우가 생겨서 이를 공유하고자 하는 것이다. 물론 독자들이 처한 환경과 완전히 배치되는 의견이 될 수도 있음을 밝혀둔다. 인재는 1년에서 3년 이상 장기적인 관점으로 투자를 해야 하는 것이기 때문에 그 정도의 여유도 없다면 공염불인 이야기다.

필자가 채용한 개발자 중에서 최고의 개발자들은 이전 회사에서 뛰어난 개발자로 인정을 받지 못하고 연봉도 낮은 경우가 많았다. 흔히 얘기하는 중위권 대학 출신이거나 개발 환경이 안 좋아서 능력을 발휘하지 못한 경우들이다. 실리콘밸리에 있는 좋은 환경의 회사에 입사를 했다면 몇 년 안에 뛰어난 개발자라는 평가를 들을 사람들도 좋지 않은 개발 환경에서는 실력 발휘도 못하고 인정도 못 받는다. 잠재력은 프리미어리그 급인데 조기축구에서 볼보이하는 격인데, 사실 축구에서 이런 일이 벌어지지는 않을 것이다. 하지만 소프트웨어 필드에서는 이런 일이 종종 벌어진다.

반대의 경우도 있다. 우리 주변에는 흔히 뛰어나 개발자라고 일컫는 사람들이 있다. 이렇게 뛰어난 개발자라고 칭송 받는 개발자들 중에는 형편 없는 개발자들이 매우 많다. 이러한 개발자들을 “헛똑똑이”라고 부른다. 똑똑하기는 한데 다 헛것이라는 의미다. 지식과 경험은 뛰어나지만 논리적인 사고, 협동심, 인내심, 겸손함 등이 부족하고 오만함과 아집으로 자신만이 옳다고 생각하고 바뀌지 않으려고 하기 때문이다. 이러한 “헛똑똑이” 개발자들은 회사에서 “영웅”으로 불리면서 동료들을 이끌고 구렁텅이로 들어가곤 한다. 이러한 문제 개발자와 진짜 뛰어난 개발자를 잘 구분할 필요가 있다.

개발자의 역량은 크게 세가지로 나뉜다.

- 시간이 흐르면 향상되는 것 : SW 지식, 기술, 경험, 도메인 지식
- 좋은 환경에서 향상되는 것 : 협동심, 커뮤니케이션 능력, 문서 작성 능력, 공유
- 노력해도 크게 바뀌지 않는 것 : 수학적이고 논리적인 사고력, Top-down 사고, 창의력, 겸손함 (인내심, 오만함, 아집)

세가지 모두 뛰어난 역량을 가진 개발자라면 정말 좋겠지만, 그런 사람을 찾기란 쉽지가 않다. 신입이나 쥬니어와 경력이 많은 시니어 개발자를 채용할 때 기준이 다르다.

신입 개발자는 “노력해도 크게 바뀌지 않는 것”을 위주로 판단한다. 특히 수학적, 논리적 사고력을 가장 높게 본다. 나머지는 좋은 환경에서 개발을 하면 자연스럽게 향상되는 것들이다.

경력 개발자는 세가지를 모두 봐야 한다. 경력에 걸맞은 지식과 경험도 본다. 여기서도  “노력해도 거의 바뀌지 않는 것”은 중요하다. 게다가 협업, 커뮤니케이션, 문서 작성 등과 관련하여 나쁜 습관이 있는지도 본다.

그럼 좀더 구체적으로 개발자를 채용하는 방법을 얘기해보자.

필자가 가장 선호하는 채용 방식은 직원 또는 지인에게 소개를 받는 것이다. 일단 직원이나 지인은 문제가 되는 사람은 소개를 하지 않고 역량도 꽤 뛰어난 사람을 소개하곤 해서 경험적으로 성공 확률이 매우 높다.

하지만 소개만으로 모든 개발자를 채용하기는 매우 어렵다. 그래서 채용공고, 홈페이지, SNS, 헤드헌터나 서치펌 등 다양한 경로를 이용해서 개발자를 채용할 수 밖에 없다. 하지만 이렇게 공개적으로 채용을 할 경우 짧은 시간에 개발자의 실력을 측정하고 회사에 적합한 사람인지 알아내기가 쉽지는 않다. 특히 경험이 많은 개발자들의 화려한 언변에 현혹이 되면 실체를 파악하지 못하는 경우도 많다.

그래서 필자가 개발자를 어떻게 채용하는지 설명하려고 한다. 물론 일반적인 관점과 좀 다를 수는 있다. 필자의 회사에서는 개발과 관리가 완벽히 분리되어 있고 개발 체계와 문화도 실리콘밸리의 소프트웨어 회사들과 비슷하다.  채용에 있어서 특이한 것이 2가지가 있다.

첫째, 동일 도메인 경험이 풍부한 개발자를 특별히 선호하지 않는다.

금융회사는 금융회사 출신의 개발자를 선호하고 보안, 게임 등 여러 분야에서 도메인 경험은 상당한 우대 요소로 작용을 한다. 그 이유는 도메인 지식을 익히는데 시간이 오래 걸리고 그때까지는 역량을 제대로 발휘하지 못하기 때문이다. 물론 도메인 경험이 도움이 안되는 것이 아니다. 하지만 도메인 경험보다 개발자 본연의 역량이 훨씬 중요하고 도메인 지식은 시간이 흐르면 익혀지지만 원초적인 개발 역량은 쉽게 바뀌지 않는다. 게다가 도메인 지식으로 개발 후보를 제한하면 좋은 개발자를 채용할 수 있는 범위가 좁아진다. 이렇게 도메인 지식보다 기초 역량을 중요시 하는 것이 중장기적으로 좋다.

둘째, 관리 능력이 뛰어난 개발자를 별로 선호하지 않는다. 오히려 꺼려한다.

우리나라에서 개발자들은 경력이 5년~10년 정도 되면 조금씩 관리 요구를 받게 되고 관리를 하면 할수록 개발에 매진할 시간은 줄어든다. 소프트웨어 개발이 관리도 하면서 짬짬이 해서 실력을 꾸준히 유지하고 발전시킬 만큼 쉽지가 않다. 관리 능력도 뛰어난 개발자를 선호하는 회사도 있지만 우리 회사에서는 개발과 관리가 철저히 분리되어 있기 때문에 개발자는 순수 개발 능력만을 본다. 관리 능력도 있는 개발자라면 관리 능력은 쏙 빼고 개발 능력만 보기 때문에 관리 능력이 뛰어난 개발자가 관리자가 아닌 개발자로 채용되는 경우는 흔치 않다. 축구선수를 뽑는데 농구도 잘하는 경우는 축구선수로 채용되기 어려운 경우와 비슷하다고 할까? 물론 어쩔 수 없이 관리도 했지만 개발역량이 뛰어난 개발자도 있다. 이런 개발자라면 채용에 문제가 없다.

우리 회사도 타사와 채용 절차는 크게 다르지 않다. 서류심사, 온라인 코딩테스트, 전화 인터뷰, 대면 인터뷰 이런 순서대로 진행이 된다. 대면 인터뷰에서는 즉석에서 칠판에 쓰는 코딩테스트를 진행한다. 20년차 개발자를 채용할 때도 코딩테스트는 필수다. 그럼 채용 시 중점을 두는 것에는 어떤 것들이 있는지 알아보자.

첫째, 출신 대학과 전공은 별로 중요하지 않다. 남녀, 국적도 따지지 않는다.

실제로 출신 대학과 무관하게 코딩테스트에서는 매우 뛰어난 결과를 보였고 천재적인 역량을 발휘한 사례도 있다. 학교 성적과 상관없이 논리적인 사고력이나 수학적인 능력이 뛰어난 사람이 소프트웨어 개발에 탁월한 경우도 드물지 않게 있다. 전공도 마찬가지다. 소프트웨어 전공이 아닌 경우에도 뛰어난 개발자를 자주 발견하고 한다. 최근에는 수학, 통계학 등의 전공자를 일부러 찾기도 한다. 야근이 수월한 체력이 좋은 남자를 선호하는 회사도 있지만 성별을 전혀 따지지 않는다. 또한 국적도 따지지 않고 한국어를 못해도 실력만 좋거나 잠재력만 뛰어나도 채용을 한다.

둘째, 온라인 코딩 테스트를 통해서 개발자 기초 역량을 확인한다.

온라인 코딩 테스트는 보통 3문제를 제출하고 24시간 안에 풀도록 한다. 내가 풀었을 때 2시간 정도 소요가 되기 때문에 24시간은 충분한 시간이다. 경시대회 수준의 어려운 문제와 쉽지만 창의력이 필요한 문제를 출제한다. 적어도 하루를 투자해야 하기 때문에 후보자가 얼마나 진지하게 우리회사에 지원한 것인지 확인할 수도 있다. A~F 등급으로 평가를 하며 B 등급 이상이 되어야 통과된다. 온라인 코딩 테스트 서비스 회사는 많이 있지만 우리 회사에서는 손으로 직접 채점을 한다. 정답 도출 여부는 자동 테스트를 하고 코딩 내용은 직접 눈으로 확인한다. 정답을 도출하지 못해도 창의력과 프로그래밍 방식을 평가하여 높은 등급을 주기도 한다. 온라인 코딩 테스트는 다른 사람이 도와줄 가능성도 일부 있기 때문에 100% 신뢰를 하지는 않고 일정 수준으로 거르는 용도로 사용을 한다.

셋째, 인터뷰 시 진행하는 칠판에 하는 코딩 테스트는 개발의 축소판이다.

개발자 채용에서 가장 중요한 절차다. 온라인 코딩 테스트를 통과한 개발자도 인터뷰 시 꼭 코딩 테스트를 또 진행한다. 문제는 매우 쉽지만 제대로 하기는 만만치 않는 문제를 출제한다. 시간은 10~20분 정도 소요가 되며 이 과정에서 개발자의 두뇌, 논리적인 사고력, 문제 해결 능력을 본다. 알고리즘을 1초 안에 머리 속으로 빈틈없이 시뮬레이션 할 수 있는 사람과 수분에 걸쳐서 숫자를 대입해가면서 검증을 해야 로직이 확인되는 사람은 하늘과 땅 차이다. 칠판에 하는 코딩테스트에서는 이 차이가 적나라하게 드러난다. 물론 후자는 탈락한다는 것은 아니다. 물론 전자의 후보가 월등히 높은 평가를 받는다. 또한 진행하는 과정을 보면서 향후 개발자가 어떻게 개발을 할지 추측할 수 있다. 평소에 개발을 하던 습관이 이 짧은 시간에 다 나온다. 또한 말만 번지르르하고 실제로 코딩을 잘 못하는 고참 개발자들도 여기서 걸러진다. 실제 수백 번의 코딩테스트를 통계 내보면 경력에 따른 큰 차이가 없다. 이런 코딩 테스트를 평가하기 위해서는 매우 뛰어난 개발자가 직접 평가를 해야 한다. 그렇지 않고는 후보자의 논리적인 사고력, 두뇌 회전 속도 등을 판단하기 어렵다.

넷째, 개발언어, 도메인은 별로 중요하게 생각 안 한다.

C, C++, Java, C#, Objective C 등 개발 언어 하나는 완전히 마스터한 개발자를 채용하며 우리가 사용하는 개발 언어를 사용해보지 않은 개발자도 채용을 한다. 다른 개발 언어는 필요하면 익히면 된다. 빨리 익힐 수 있는 잠재력을 가지고 있는지가 더 중요하다. 특이한 경우지만 코딩 경험은 거의 없지만 잠재력이 무한한 사람이라면 개발 언어를 잘 몰라도 채용이 될 수도 있다. 보통 뭘 해봤고 무슨 툴, 라이브러리를 써봤는지 보다는 잠재력 확인에 주력한다. 그래서 가장 자신 있는 개발 언어에 대해서 그 특성을 제대로 이해하고 있는지 질문을 하고 OOP의 개념을 얼마나 잘 이해하고 있는지도 질문을 한다. 우리 회사와 동일한 도메인 지식 경험이 있다면 당연히 좋겠지만 그렇지 않더라도 상관하지 않는다. 우리는 Dental 분야지만 보안, 레저, 게임 등 분야를 가리지 않고 채용을 하며 입사 후 능력과 성과는 도메인과 별로 상관이 없다.

다섯째, 좋은 개발 습관을 가진 개발자를 선호한다.

경력이 많은 개발자일수록 자신의 습관을 바꾸기가 어렵다. 그래서 경력이 많을수록 습관을 주의 깊게 파악한다. 신입이라면 백지와 다름이 없기 때문에 거의 잠재 능력 위주로만 평가를 한다. 소프트웨어 공학에 관심이 많은 것은 긍정적인 요소이며 권위 의식이 있는지 협업과 커뮤니케이션에 능숙한지 공유하는 습관이 있고 문서 작성을 제대로 하는지 확인한다. 꾸준히 새로운 기술을 거부감 없이 익히고 공부하는 것을 즐기는 타입이면 좋다. 인터뷰에서는 보통 좋은 모습만 보여주려고 하기 때문에 습관을 숨길 수 없는 핵심적인 질문을 통해서 진짜 습관을 알아내려고 노력한다. 습관은 바뀌기 어렵기 때문에 인재에 투자할 여력이 된다면 잠재력이 뛰어난 신입개발자를 채용하여 좋은 환경에서 훈련시키고 회사의 문화를 습관화 시키는 것이 좋다.

우수한 개발자가 뛰어난 개발자로 성장하고 뛰어난 성과를 내려면 거기에 걸맞은 환경이 필요하다. 그 중에서 가장 중요한 것이 협업이다. 분석, 설계를 제대로 하고 공유를 하며 개발자의 경력을 보장하고 수평적인 조직 문화를 갖추는 등 개발자가 실력을 발휘하고 성장할 수 있는 환경이 필수적이다. 이건 워낙 광범위한 주제이기 때문에 이 글에서는 논외로 하자.

지금까지 회사 관점에서 어떻게 뛰어난 개발자를 채용하는지 알아봤는데 거꾸로 개발자 관점으로 보자. 필자가 걸어온 길이기도 한다.

개발 언어 하나는 일단 도사급이 되어야 한다. 그리고 다양한 개발 언어를 거부감 없이 수시로 익히고 특히 스크립트 언어 한두개도 능숙해져야 한다. 새로 나온 기술도 관심을 꾸준히 가지고 필요한 만큼 익혀 놓아야 한다. 영어는 끝이 없으므로 꾸준히 공부를 해야 한다. 수학과 논리적인 사고를 꾸준히 단련해야 하며 수시로 글을 쓰고 개발 문서를 써야 한다. 소프트웨어 공학이 몸에 익어야 하며 커뮤니케이션, 협업 역량 향상을 위해 노력하고 겸손함과 인내심을 갖추려고 노력한다. 이렇게 좋은 습관과 뛰어난 지식과 경험을 쌓은 개발자라면 대부분의 SW 회사에서 채용하고 싶을 것이다.

이렇게 준비하며 습관을 만들어가기 어려운 환경에서 일하고 있는 개발자도 매우 많다. 그래도 언제든지 이직의 기회는 발생하는 것이고 현재 환경에서 할 수 있는 최선을 다해서 자신을 만들어가면 좋겠다.

이글은 ZDNet Korea와 기업블로그에 기고한 글입니다.

기업문화를 바꾸기 어려운 이유

요즘 테슬라도 GE도 너도 나도 소프트웨어 회사라고 선언을 하고 소프트웨어에 엄청난 투자를 하고 있다.

그 와중에 우리나라 회사들은 소프트웨어에 실패했다고 자성을 하고 있다. Google의 1/100 실력이라고 자수를 하기도 한다. 최근에 대기업들의 대대적인 구조조정으로 수많은 소프트웨어 개발자들이 노동시장으로 쏟아져나 왔다.

우리나라 기업들도 소프트웨어만이 살길이고 소프트웨어 엄청나게 투자를 한다고 한 것이 불과 10여전 밖에 안되었다. 그 동안 수많은 소프트웨어 개발자를 채용하고 교육하고, 기업문화를 바꾸기 위해서 엄청나게 애를 썼다.

그런데 왜 결과가 이런가? 필자는 소프트웨어 개발에 있어서 기업에게 가장 중요한 것은 천재적인 개발자도 아니고, 엄청나게 많은 돈을 투자해야 하는 것도 아니고 바로 "기업문화"라고 생각한다.

물론 우리나라 대기업들이 "기업문화" 개혁에 투자를 하지 않은 것이 아니다. 엄청나게 투자를 했다. 그런데 왜 과거와 별반 다른 것이 없을까? 물론 조직이 너무 크고 기득권 세력이 강해서 쉽게 바뀌지 못하는 한계도 있다.

필자는 여러 기업에서 기업문화를 바꾸겠다고 얘기를 할 때 실패를 할 것이 뻔히 예상된다. "기업문화"를 넘어서 "문화"란 남들이 하는 것을 보고 흉내를 내기는 어렵다. 기껏해야 공짜 점심 같은 것을 흉내낼 뿐이다.

여기에 개들이 다니는 "D"사가 있다. "D"사의 개들은 모두 네발로 걸어 다닌다. 그런데 그들이 배우고 싶은 "H"사의 개들은 두발로 다니고 SW 개발 역량이 D사의 100배이다. 그럼 어떻게 해야 D사는 H사의 문화를 배울 수 있을까? D사의 경영진들은 H사의 개들이 두발로 걸어 다니고 두발로 걷는 것은 SW 개발 역량 향상에 필수적이라는 것은 이미 알려진 사실이므로 D사 직원 모두에게 이제부터 모두 두발로 걷게 한다. 하지만 두발로 걷는 것은 보통 어려운 것이 아니다. D사의 직원들은 남들이 볼 때는 두발로 걷고 안볼 때는 네발로 걷게 된다. 또한 이런 어려움을 아는 관리자들은 형식적으로 점검을 하게 된다. 네발로 걷는 것이 익숙한 관리자들은 말로는 "두발로 걸어야 한다"고 하면서도 어떻게 해야 하는지 잘 모른다. 형식적으로 흉내를 낼 뿐이다.

이 과정에서 D사의 직원들은 죽을 맛이다. 두발로 걷는 방법을 제대로 알려주지도 않고 겉모습만 잔뜩 알려주니 따라할 수가 없다. 겉으로는 두발로 걷는 척해야 하고 실제 일은 네발로 해야 진행이 되므로 일은 두배로 힘들어진다.

D사의 경영진들은 직원들이 모두 두발로 걷는데 왜 여전히 SW 개발 역량이 향상되지 못하는지 한탄을 하게 된다.

내가 생각하는 D사가 바뀌는 방법은 이렇다. 먼저 두발로 걷는 것이 당연한 H사나 비슷한 회사의 전문가들이 D사의 중요 직책으로 들어온다. 이들은 D사의 직원들을 두발로 걷게 하고 같이 일하면서 수백 가지의 노하우를 직원들에게 전수한다. 직원들이 수시로 네발로 걸으려고 할 때마다 그 상황에 맞게 코칭을 계속한다. 이러면서 새로 D사에 입사한 직원들은 두발로 걷는 것이 당연한 환경에서 생활을 하게 된다. 이렇게 10년쯤 일을 하면 D사에서도 개들은 두발로 걷는 것이 당연한 문화가 된다.

그래서 문화가 바뀌려면 적어도 10년은 각고의 노력을 해야 한다고 생각한다. 완전히 정착하려면 세대가 바뀌어야 한다. 기업에서 세대가 바뀌는데는 10년이 걸린다.

SW를 개발하는데 핵심 문화인 "수평적인 조직", "공유", "문서", "리뷰", "토론" 등 여러 문화는 남들이 하는 것을 보고 흉내를 낼 수 없다. Template과 Process를 흉내내면 더 망가질 뿐이다. 또한 전문가를 영입해도 힘이 없으면 고군분투하다가 포기할 뿐이다.

Google의 1/100 실력이라고 하면서 또, 과거와 비슷하게 스스로 열심히 뭔가 개혁을 해보려고 하고 단기간에 성과를 내보려고 한다면 매번 반복되는 현상이 이번에도 반복될 것이다. 

share with abctech.software

보고서를 효율적으로 줄이는 방법

필자가 그 동안 수많은 회사의 컨설팅을 하면서 경험한 바에 의하면 대부분의 회사가 일하는 방식에 있어서 “모 아니면 도”를 선택한다. 작은 회사는 서로 무슨 일을 하는지 속속들이 알기 때문에 프로세스가 없거나 단순하고 문서도 거의 없는 경우가 많다. 하지만 많은 대기업들은 과도하게 절차가 복잡하고 문서를 많이 작성해야 한다. 적절한 중간 정도의 프로세스를 유지하는 회사는 별로 없다. 그래서 작은 회사는 관리가 잘 안돼서 문제, 큰 회사는 형식으로 흐르고 비효율적이어서 문제다. 모두 그런 것은 아니지만 대부분의 회사가 여기에 해당한다.

웬만한 규모를 가진 회사의 관리자들은 보고서를 작성하는데 꽤 많은 시간을 소비한다. 보고서의 종류도 여러 가지고 보고서의 질에 따라서 업무의 성과에 대한 평가가 좌우되기도 한다. 개발자라고 예외는 아니다. 개발은 개발대로 하고 개발 후에 보고서 형태로 여러 문서를 별도로 작성하는 회사가 많다. 이런 보고서를 작성하는데 들어가는 노력과 시간은 낭비인 경우가 많다. 

관리자나 경영자는 직원들이 작성한 보고서를 통해서 업무 내용을 파악하곤 하는데 여기에는 문제점이 있다. 보고서는 요약을 할 수 밖에 없다. 그 과정에서 중요한 정보들은 사라지고 문제점들이 숨겨지곤 한다. 보고자들은 대부분은 잘한 내용, 좋은 결과만 예쁘게 포장해서 보고를 하곤 한다. 이런 보고가 여러 단계를 거치다 보면 최고 경영자는 좋게 포장된 낙관적인 정보를 접하게 되는 경우가 많다. 

까다로운 경영자와 일하는 직원들은 본연의 일보다도 보고서 작성에 과도하게 노력을 들이기도 한다. 일이야 어떻게 진행되었던 간에 보고서를 잘 작성해서 보고만 잘 넘기면 된다고 생각하기도 한다. 그리고 실제로 문제가 많은 상황에서도 보고서를 잘 작성해서 위기를 넘기기도 한다. 물론 이런 문제가 꾸준히 쌓이면 언젠간 폭발하기 마련이다. 

보고서의 종류는 여러 가지가 있다. 먼저 업무 관리를 위해서 관리자에게 주기적으로 제출하는 보고서가 있다. 회사마다 형태는 다르지만 일일보고, 주간보고, 월간보고 형태로 업무 진행 내용을 요약해서 작성하고 보고하는 것이다. 이런 보고서는 일은 일대로 다 하고 별도로 작성하는 경우가 많다. 보고자는 별도의 보고서를 작성하기 위해서 시간을 낭비하지만 관리자도 이런 보고서를 보고 판단할 수 있는 것은 많지 않다. 피상적인 파악 밖에는 못한다. 하지만 이 정도의 보고도 안하면 관리자가 업무 파악이 어려워서 어쩔 수 없이 이런 보고라도 받는다. 

주기적인 보고서 외에 단발성 보고서가 있다. 단발성 업무를 수행하고 그 결과를 보고서로 작성하는 것이다. 이 경우에도 보고를 위한 보고서를 작성한 후에 책꽂이에 꽂혀서 방치되는 경우가 종종 있다. 

그럼 “모 아니면 도”가 아닌 “걸” 쯤 되는 방법은 없을까? 보고서를 최소화하고 업무의 효율성을 높이는 방법을 알아보자. 

필자는 이우소프트에서 보고서 제로화를 추진하고 있다. 보고를 위한 보고서 작성을 모두 없애고 업무에 집중하려고 하는 것이다.  

가장 먼저 관리를 위한 주기적인 보고서인 일일보고, 주간보고를 모두 폐지했다. 

이렇게 하기 위해서 선행되어야 할 중요한 전제 조건이 있다. 바로 모든 업무의 정보가 Online system에 기록되어야 한다는 것이다. 이우소프트에는 중요한 업무 규칙 한가지가 있다. "No issue, no work"가 바로 그것이다. 이슈관리시스템에 기록되지 않는 업무는 할 수 없고, 이슈를 생성하지 않고 업무를 진행하는 것도 금지되어 있다. 업무를 요청할 때도 오직 이슈관리시스템만을 이용해야 한다. 말로 요청할 수도 없고 Email로도 요청할 수 없다. 내부에서 직원끼리의 Email은 금지되어 있다. 공식 커뮤니케이션 수단은 오직 이슈관리시스템 밖에 없으므로 나머지 어떠한 수단도 공식 수단은 아니다. 

이러다 보니 모든 정보는 이슈관리시스템으로 모이고 시간과 장소를 구애 받지 않고 커뮤니케이션이 가능하며 업무를 할 수 있다. Email은 당사자끼리만 정보를 아는 폐쇄적인 시스템이고 추적도 관리도 안된다. 따라서 Email을 통한 업무 처리는 철저히 금지되어 있다. Email은 외부인과만 주고 받을 수 있다. 

이렇게 이슈관리시스템을 통해서 업무를 하다 보면 일일이 승인을 받고 일을 할 필요도 없다. 스스로 해야 할 일이라고 생각하면 이슈를 등록하고 일을 하면 되고 관리자는 모니터링을 할 뿐이다. 물론 지시를 하는 경우도 있다. 이런 자율적인 분위기가 자연스럽게 자리를 잡기 위해서는 수평적인 조직문화가 필수적이다. 시키는 일만 하는 것이 아니라 스스로 일을 찾아서 하고 정보는 공유되고 서로 모니터링을 하면서 문제를 해결해 나간다. 

관리자나 경영자는 요약된 보고서를 보는 것이 아니라 이슈관리시스템을 통해서 모든 업무 진행 내용을 모조리 다 보는 것이다. 그래서 별도의 보고가 따로 필요 없다. 모든 내용을 다 보는데 시간이 엄청나게 많이 소요될 것 같지만 막상 해보면 그렇지 않다. 이 직원 저 직원 불러다가 보고 받는 것보다는 시간이 적게 걸린다. 그리고 업무를 마친 후에 보고를 받으면 일이 잘못 되었을 경우 이미 늦어 버린 것이다. 질책 밖에 할 것이 없다. 하지만 일이 진행되는 처음부터 계속 모니터링을 하면 중간 중간에 계속 의견을 제시할 수 있고 일이 잘못 진행되는 경우는 많이 줄어들게 된다. 

처음에는 직원들이 모든 커뮤니케이션을 이슈관리시스템을 통해서 해야 하고 모든 정보를 다 남겨야 하는 것을 힘들어 했지만 별도의 보고서를 작성해야 할 필요가 없고 업무도 더 원활하게 진행이 되므로 이제는 이런 환경에 적응했다. 이제는 과거로 돌아가자고 해도 모두 반대를 할 것이다. 과거에 Email과 대화 위주로 일하면서 정보도 제대로 남기지 않았던 때를 생각하면 끔찍하게 생각된다. 그때 그렇게 하고도 어떻게 일을 했는지 신기하게 생각될 정도다. 누구나 이런 문화를 1년 정도만 경험하게 되면 그렇게 생각될 것이다. 

물론 보고서가 아예 없는 것이 아니다. 단발성 업무를 진행할 때는 보고서를 작성하지만 보고를 위한 보고서가 아니다. 예쁘게 꾸미기 위한 PPT(Power Point)는 금지되어 있고, 대부분은 Word로 작성을 한다. 보고는 별도로 하지 않고 시스템에 등록하며 경영자도 똑같이 시스템에 등록된 보고서를 리뷰 한다. 보고보다는 리뷰를 한다고 보면 된다. 추가 논의가 필요할 때만 만나서 얘기를 한다. 물론 추가 논의한 내용도 시스템에 기록된다.  

대기업을 비롯한 많은 회사들은 KMS, Wiki 등 지식과 정보를 온라인으로 구축하는데 실패했다. 성공적인 회사도 있지만 그리 많지는 않다. 아무리 강제화를 해도 형식적인 정보만 쌓이고 직원들은 프로세스를 요리조리 피해 다닌다. 이런 환경에서 자신이 가지고 있는 정보를 혼자서 시스템에 고스란히 남기면 자신만 손해를 보는 환경인 것이다. 모든 직원이 정보를 공유하는 것이 습관화되지 않은 곳에서는 지식과 정보가 온라인에 쌓이지가 않는다. 이것이 많은 회사들이 지식과 정보를 시스템에 모으고 공유하는데 실패하는 이유다. 

기업문화는 바꾸기 어렵다. 프로세스로 강제화 해도 어렵다. 프로세스가 오히려 방해가 되는 경우도 많다. 여기서 가장 중요한 것은 경영자의 의지와 직원들의 참여다. 경영자가 바뀔 기업문화의 핵심을 제대로 이해하고 강력한 의지를 가지고 추진한다면 시간은 걸리겠지만 기업문화 정착에 성공할 것이다. 이우소프트에서도 이러한 도전은 계속 되고 있다.

이 글은 ZDNet Korea와 바텍블로그에 게재되었습니다.