개발자간 공유 문화 정착이 힘든 이유

소프트웨어를 개발하는데 있어서 가장 중요한 문화 중 하나는 '공유’ 문화라고 할 수 있다. 소프트웨어개발 속도를 향상하고 비용을 절감하며 프로젝트 성공 확률을 높이는 중요 요소다. 뿐만 아니라 개발자들의 실력을 향상하고 개발자가 20년, 30년 계속 개발자로 일할 수 있도록 하는 기초 체력이기도 하다. 

하지만 우리나라에서 공유 문화를 제대로 갖추고 있는 회사를 찾아보기란 그리 쉽지 않다. 내 주변에는 소프트웨어 개발 문화에 관심을 가지고 있는 개발자가 많다. 특히 공유문화에 관심이 많아서 실천을 하려고 노력하는 경우도 많다. 하지만 그런 노력의 결과로 성공적으로 개발문화를 정착했다고 하는 소식은 잘 들려오지 않는다. 그 이유는 무엇일까?

여러 가지 이유가 있겠지만 그 첫 번째는 아직 공유에 노력을 하는 개발자들이 소수이기 때문이다. 

‘죄수 딜레마’라고 들어본 적이 있는가? 

상황은 다음과 같다. 두 명의 사건 용의자가 체포되어 서로 다른 취조실에서 격리되어 심문을 받고 있다. 이들에게 자백여부에 따라 다음의 선택이 가능하다.

•    둘 중 하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지 한 명이 10년을 복역해야 한다.

•    둘 모두 서로를 배신하여 죄를 자백하면 둘 모두 5년을 복역한다.

•    둘 모두 죄를 자백하지 않으면 둘 모두 6개월을 복역한다.

죄수A는 죄수B가 침묵할 것으로 생각되는 경우 자백을 하는 것이 유리하다. 죄수B가 자백할 것으로 되는 경우 자백이 유리하다. 따라서 죄수A는 죄수B가 어떤 선택을 하든지 자백을 선택한다.

죄수B도 죄수A와 동일한 상황이므로, 마찬가지로 죄수A가 어떤 선택을 하든지 자백이 유리하다.

따라서 둘 모두 자백을 하지 않는 것이 최선의 결과이지만 죄수 A, B 는 모두 자백을 선택하고 각각 5년씩 복역한다는 것이다.

이런 죄수딜레마를 게임으로 시뮬레이션을 해보면 죄수 둘이 서로 의논을 하게 하건, 죄수가 2명이 아니라 여러 명이건 상관없이 비슷한 결과가 나온다고 한다.

도로로 나가보자. 조금 막히는 교차로에서는 교차로 꼬리 물기가 아주 흔하다. 아무리 막히는 교차로라고 하더라도 꼬리물기를 하지 않으면 다같이 평균적으로 더 빨리 교차로를 빠져나갈 수 있다. 하지만 대중은 그런 선택을 하지 않는다. 다들 꼬리 물기를 하는 상황에서 나만 교통법규를 지키고 가만히있으면 교차로를 가장 늦게 통과하게 될 것이다. 심지어는 주변의 차들에게 욕먹을 각오도 해야 한다.꼬리 물기를 하는 차가 다수인 상황에서는 교통법규를 지키는 소수가 몇 배 더 손해를 보게 되어 있다. 그래서 어쩔 수 없이 다같이 손해를 보는 경우를 선택하게 된다.

몇 년 전 가족과 함께 괌의 한 리조트를 방문한 적이 있었다. 하지만 여기서 부끄러운 일을 목격했다. 수영장에는 충분한 선배드가 있는데 아침 9시쯤 수영장에 가보니 모든 선배드가 이미 임자가 있었다. 선배드에 타올을 하나씩 걸쳐 놓았지만 선배드에서 쉬고 있는 사람은 하나도 없었다. 몇 시간 후나타난 선배드의 주인을 보니 모두 한국사람들이었다. 아침 일찍 일어나서 일단 선배드를 찜 해놓고아침식사를 하러 간 것이었다. 사실 선배드는 모든 사람이 충분히 쉴 만큼 많았다. 하지만 이용도 하지않으면서 먼저 찜을 해놓으니 다른 사람들은 전혀 쉴 곳이 없게 된 것이었다. 한국에서는 이런 현상이후로 수영장의 선배드 이용이 유료로 바뀐 것으로 알고 있다. 외국에서는 이로 인해 어떻게 바뀔지,바뀌었는지 알 수 없다. 어쨌든 낯부끄러운 일이었지만 다음날 아침에는 아침식사를 하기 전에 선배드 몇 개를 찜 해 놓는 일에 동참하는 우리를 발견하게 되었다.

이렇듯 죄수딜레마는 어디에서나 나타난다. 약속을 지키면 다같이 이익이 되고 모두 약속을 지킨다는확신이 없다면 약속은 순식간에 무너진다.

그럼, 규칙을 엄하게 적용하면 해결될 수 있지 않을까? 공유를 하지 않으면 벌칙을 주고 필요한 문서를 모두 만들지 않으면 승인을 하지 않아서 프로젝트의 다음 단계로 넘어가지 못하게 하면 해결할 수있지 않을까? 이런 식으로 해결이 될 수 있었다면 우리나라의 대부분의 회사가 이미 공유문화가 잘 정착되었을 것이다. 안타깝게도 엄격한 규칙적용은 그렇게 효과적이지 못하다.

첫째 만들어 놓은 규칙이 엄격하기만 할 뿐 공유 문화 정착에 효과적인 경우가 별로 없다. 왜냐면 그엄격한 규칙을 만든 사람들이 대부분 공유문화를 체험해 본 적도 없는 사람들이기 때문이다. 대부분은 방법론에서 필요한 문서를 따와서 만들라고 하는데 대부분의 방법론은 공유문화와는 별로 상관이없다. 게다가 방법론을 오해해서 오히려 복잡하게 적용하는 경우도 허다하다.

둘째 아무리 복잡한 규칙을 만들어도 개발자들은 요령껏 적응하고 피해 다니게 된다. 문서를 만들라고 하면 형식 면에서는 규칙을 충족하게 만들 수 있지만 진짜 필요한 내용이 다 들어 있는지 확인할방법은 없다. 공유가 습관화되지 않은 대부분의 개발자들은 어쨌든 규칙만 준수하는 방법으로 진짜공유는 피해 다니게 되어 있다.

셋째 나만 공유를 제대로 하게 될 경우 나만 손해를 볼 수 있다는 생각을 의식적으로 또는 무의식적으로 하게 된다. 나중에 내가 없으면 유지보수가 어려워야 나의 가치가 올라간다고 생각한다. 전혀 틀린얘기도 아니지만 다들 이렇게 생각하니 다같이 손해를 보는 것이다.

규칙을 통해서 공유문화를 만들어가는 것에는 찬성한다. 하지만 오히려 공유문화에 역행하는 규칙을만드는 것이 일반적인 상황이라서 안타깝다. 개발자들이 공유에 익숙하지 않은 상황에서 너무 욕심을내는 것도 안 된다. 현재 상황을 잘 파악해서 공유문화를 만들어 갈 수 있는 단계적인 접근이 필요하다. 개발자들이 소화할 수 있는 만큼의 규칙을 만들고 이것이 익숙해지는 것이 공유문화 발전 방향과일치를 해야 한다. 이렇게 점점 규칙을 업그레이드 시켜나가면서 회사를 조금씩 바꿔나가야 한다. 물론 이런 과정을 통해서 다같이 이익이 될 것이라는 확신을 직원들에게 심어주어야 한다.

처음부터 과욕을 부리다가는 영원히 공유문화와는 멀어지게 된다. 그럼 비효율이 정착된 회사가 될것이다.

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

야근, “악의 균형”

어떤 경영자는 “우리 회사 개발실은 밤이나 주말이나 불이 켜져 있다”고 자랑을 한다. 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에 기고한 칼럼입니다.

혼자만 알고 있는 개발자들

많은 회사 개발자를 만나면서 느끼는 우리나라 소프트웨어 회사들의 가장 큰 문제 중 하나는 개발자간에 정보와 지식의 공유가 잘 안 되는 것이다. 회사가 크던 작던 거의 모든 회사가 동맥경화에 걸린 것처럼 정보와 지식이 공유되고 유통되지 않고 몇 사람만 알고 있다. 회사가 크면 클수록 이런 현상은 더욱 심해진다. 

 
꽤 오래 전 어떤 개발자가 개발을 하면서 특정 라이브러리의 호환성 때문에 한 일주일 고생을 한 적이 있다. 인터넷도 검색하고 여러 시도를 해 보았지만 잘 해결이 안돼 여러 개발자가 고생을 하고 있었다. 수시로 사무실 통로에 서로 모여서 이와 관련된 짧은 토론을 여러차례 하면서 회사 내의 이슈가 되고 있었다. 
 
그렇게 며칠이 지날 때쯤 한 개발자가 말하길 이것은 자신이 수개월전에 이미 시도를 해보고 다 조사를 해본 것이라고 한다. 그리고 이것은 불가능하다는 것의 증거를 가지고 있다고 했다. 진작에 이것 때문에 고생하고 있다는 것을 알았지만 개발자들이 일주일이 지나도 해결을 못하자 자랑스럽게 얘기를 해주는 것이었다. 회사가 크고 서로 사무실이 달랐다면 이 조차도 전달이 안되었을 것이다. 그나마 회사가 작으니까 나중에라도 얘기를 해줄 수 있었다. 
 
이런 얘기를 들을 경우 개발자들은 그 개발자를 어떻게 생각할까? 남들이 모르는 것을 알고 있다고 존경심을 가질까? 아니면 왜 미리 알려주지 않았나 서운해할까? 아니면 이런 정보가 공유가 잘 안 되는 회사의 문화, 프로세스와 시스템을 탓할까? 
 
이런 개발자는 회사의 중요한 사람일까? 없어야 하는 사람일까? 내 생각은 이렇게 중요한 정보를 본인만 알고 있고 고의로 공유를 안하는 개발자는 해고감이다. 개발자는 개발에 관련된 내용을 적절히 충분히 기록하고 공유를 해야 한다. 이것은 말은 쉽지만 매우 어려운 일이다. 개발 과정에서 효율적이고 자연스럽게 정보와 기록을 남기고 공유를 해야 한다. 
 
이런 현상이 비단 개발자 탓만은 아니다. 공유가 잘 안되는 문화를 가진 회사에 입사를 해서 다른 사람과 자연스럽게 동화된 것 뿐이다. 공유를 할 마땅한 방법이 없기도 하고, 혼자서 열심히 공유를 하려고 해도 대부분의 개발자들이 자신의 업무에 바빠서 공유된 정보에는 관심도 없는 경우가 많다. 국내 많은 소프트웨어 회사들이 이와 비슷하다. 공유를 위해서 애쓰지만 대부분 성공적이지 않다. 공유에 실패하는 회사는 다음과 같은 특징이 있다. 
 
첫째, 소수의 인원만 정보 공유에 애쓴다. 경영진을 비롯해서 대부분의 개발자는 공유에 별로 관심이 없다. 공유가 왜 중요한지 인식을 못하기도 한다. 개발자 혼자 공유 문화의 전도사처럼 나서지만 누구 하나 인정해주지도 않고 본인도 금방 지치게 된다. 
 
둘째, 공유를 위한 시스템이 없거나 부족하다. 공유를 한다고 문서를 만들어도 문서가 버전관리도 안되고 여기저기 굴러다니고 정보를 찾기도 어렵다. 좋고 비싼 시스템이 있어도 제대로 사용하지 않는다. 이럴 때 비싼 시스템은 오히려 적절한 공유에 방해가 되기도 한다. 
 
셋째, 개발과는 별도로 문서를 따로 만든다. 문서를 만들어도 많이 만든다. 게다가 문서를 만드는데 엄격한 규칙이 있다. 대부분의 대기업이 여기에 해당한다. 경영진이 공유의 의지를 가지고 밀어붙이는 경우도 대부분 이렇게 된다. 하지만 이렇게 별도로 문서를 많이 만든다고 공유가 잘되는 것은 아니다. 엄격한 프로세스로 비효율적으로 많은 문서를 만들기도 하고 이를 형식적으로 지키기도 하지만 이것으로 공유에 성공했다고 볼 수는 없다. 
 
정작 중요한 정보는 공유가 안된다. 이런 회사의 특징은 대부분의 문서가 서로 정보가 안맞고 계속 업데이트가 안되서 쓸모가 없다. 게다가 쓸모 없는 문서와 쓸모 있는 문서가 섞여 있어서 올바른 정보를 구분하기 어렵다. 
 
넷째, 기존의 지식을 문서로 만들려고 애쓰다가 실패한다. 기존의 지식과 정보를 모두 끄집어내서 문서화 하는 일은 거의 불가능한 일이다. 일할 당시 그때가 아니면 문서화는 어렵다. 하루가 지나면 기억 속의 정보는 50%가 사라지고 일주일이 지나면 90%가 사라진다. 지금이 아니면 나중에는 문서화 할 수 없다. 밀린 일기는 포기하고 오늘 일기부터라도 쓰는 것이 좋다. 
 
다섯째, 항상 너무 바쁘다. 특히 고참일수록 더 바쁘다. 신입사원은 제대로 일하려면 수개월이 걸린다. 그러다 보니 고참이 더 바빠서 공유에는 신경 쓸 시간이 없는 악순환이 계속된다. 
 
반대로 공유에 성공한 회사는 다음과 같은 특징이 있다. 
 
첫째, 경영진을 비롯한 모든 개발자가 공유에 힘쓴다. 공유가 얼마나 중요한지 모두 잘 알고 있고 공유에 문화적으로 시스템적으로 투자를 한다. 
 
둘째, 적절한 시스템이 구축되어 있다. 대부분 이슈관리시스템, Wiki등의 시스템이 잘 구축되어 있고 회사의 거의 모든 정보와 지식이 잘 저장되어 있다. 뿐만 아니라 휘발성 커뮤니케이션 수단인 전화, 메신저, 이메일 등은 보조수단으로 사용되며 중요 정보는 대부분 시스템을 통해서 전달되고 공유된다. 
 
셋째, 문서는 최소로 만든다. 불필요한 문서를 만들지 않고, 꼭 필요한 문서 몇 개만 만든다. 문서의 형식도 꽤 자유롭다. 개발자들이 토론하면서 노트에 그린 그림을 사진을 찍어서 올리기도 하고, 온라인 그리기 도구를 쓰기도 하고 상황에 맞게 자유로운 도구를 활용한다. 
 
넷째, 공유가 습관화 되어있다. 항상 일하는 과정에서 자연스럽게 공유를 한다. 별도로 문서를 만든다고 많은 시간을 소비하지 않는다. 자유롭게 필요한 만큼 알아서 효율적으로 공유를 한다. 항상 노트를 하고 즉각 정리해서 이슈관리시스템이나 Wiki에 등록하는 것이 일상화 되어 있다. 개발자가 수시로 하는 작은 조사, 개발도 모두 문서화되고 공식적으로 진행된다. 
 
다섯째, 리뷰가 활성화 되어 있다. 모든 정보는 문서로 공유하기는 어렵다. 토론도 많이 하고 리뷰도 자주 있다. 리뷰과정을 거쳐서 문서는 꼼꼼히 검토가 되고 여러 직원들의 전문적인 의견이 반영된다. 고참일수록 리뷰에 많이 참석하며 자신의 경험과 지식을 리뷰를 통해서 전수한다. 
 
공유는 소프트웨어에서는 가장 중요한 기업 문화이다. 소프트웨어가 창의적인 지식산업이기 때문에 더욱 그렇다. 하지만 대부분의 회사는 위에서 언급한 공유에 실패하는 증상들이 보이고 있다. 그렇다고 이제부터 공유를 열심히 하자고 마음만 먹는다고 공유가 잘되는 것은 아니다. 복잡한 프로세스를 도입하는 것보다 공유 문화 정착이 열 배는 어려운 일이다. 
 
경영진의 의지가 가장 중요하지만 의지만 가지고 밀어붙이다가는 프로세스만 복잡해지는 함정에 빠지기가 매우 쉽다. 문화란 그만큼 바뀌거나 도입하기 어려운 것이다.

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

21C 韓 SW개발자는 16C 조선 陶工 처지

나의 취미 중 하나는 도예 즉, 도자기 만들기다. 우연한 기회에 시작해서 10년을 넘게 도자기를 만들었으며 도자기 역사나 도자기 기술에 대해서도 많은 공부를 하게 되었다. 그런데 요즘 우리나라의 소프트웨어 산업 환경이 조선 시대 임진왜란 때 일본으로 납치되어 간 도공들이 다시 조선으로 돌아오기를 거부하고 일본에서 뿌리를 내린 것과 비슷하다. 

임진왜란 당시 어떠한 일이 일어났는지 간단히 알아보자. 그리고 역사는 되풀이 된다는데 현재 우리는 무슨 문제를 가지고 있는지도 생각해보자. 

16세기까지 전세계에서 1천300도 이상에서 구워내야 하는 도자기를 만들어 낼 수 있는 나라는 중국, 한국, 베트남 정도였고 그 중에서 도자기의 최고봉인 백자는 중국과 조선만 만들어 낼 수 있었다. 지금은 도자기가 별 것 아니라고 생각할 수 있었지만  당시에는 최고로 돈이 되는 물건이었다. 유럽의 귀족들은 중국의 도자기에 열광해서 금, 은 그릇보다 비싼 가격에 도자기가 거래되고 있었고 세계 도자기 시장은 거의 중국이 석권하고 있었다. 

임진왜란이 왜 일어 났는지는 여러가지 의견이 있지만 도자기 때문에 일본이 일부러 일으켰다는 주장도 있다. 임진왜란의 근본 목적은 조선의 도자기 제작 기술을 비롯한 여러 가지 공예 기술을 훔쳐오기 위한 것이라는 주장이다. 일찌감치 네덜란드 등과 교역에 눈을 뜬 일본은 유럽에서의 도자기 인기를 알게 되었고 자신들의 도자기 제작 기술보다 월등히 높은 조선의 도자기 제조 기술을 가지고 싶어 했다. 그래서 임진왜란 전에 미리 첩자를 조선에 보내 조선의 도공들의 신상과 소재를 모두 파악한 후 임진왜란, 정유재란 중에 조선의 도공 거의 전부인 약 900명을 납치해 갔다는 것이다.물론 도공들만 납치해 간 것은 아니고 다른 수많은 분야의 장인들을 같이 납치해 갔지만 도자기 장인들이 핵심이었다. 

그렇게 납치해 간 도공들은 일본에서 도자기를 만들 수 있는 흙을 찾아냈고 20년만에 일본도 완벽한 도자기 제작 기술을 보유하게 되었다. 마침 중국의 내부 정세 혼란을 틈타 유럽의 도자기 시장을 석권하고 막대한 자금을 바탕으로 아시아 최대 강대국으로 발돋움 했다는 학설이다. 

그런데 임진왜란 후에는 조선은 도공들을 다시 돌려 받으려고 했지만 많은 도공들은 조선으로 돌아오기를 거부했다고 한다. 일본으로 끌려간 도공들은 조선에서보다 훨씬 나은 대접을 받았다고 한다. 조선에서는 기술은 천시하고 도공뿐만 아니라 대부분의 장인들은 하층민 대접을 받았지만 일본에서는 이들을 극진히 대우를 해줬다고 한다. 땅도 주고 집도 주고 결혼도 시켜주고 마음껏 도자기를 만들 수 있도록 지원을 아끼지 않았다고 한다. 옛날부터 일본은 장인을 존경하는 전통이 있었고 자신들이 가장 높게 사는 최고의 도자기 제작 기술을 가지고 있는 사람들을 존경하고 대우해주는 것은 어쩌면 당연했을지도 모른다. 

그러다보니 임진왜란 후 거의 도자기의 명맥이 끊기고 세계 예술사에서 거의 흔적을 남기지 못한 한국과는 대비되게 일본은 최고의 도자기 명문 국가가 되었고 선진국의 발판이 되었다. 역사에 만약은 없지만 도자기를 기반으로 우리나라가 18,19세기 강대국으로 발돋움 했다면 어떻게 되었을까? 

이 얘기를 하는 이유는 임진왜란 당시의 상황이 지금과 별반 다르지 않기 때문이다. 여전히 기술자는 존경과 대우를 못 받고 그나마 대우를 받으려면 관리자가 되어야 한다. 공부를 잘하는 학생들은 대부분 의사, 공무원이 되려고 한다. 소프트웨어 개발자들은 기회만 되면 외국으로 나가려고 한다. 개인 입장에서는 축하해줄 일이지만 그렇게 고급인력이 다 빠져나가면 우리나라는 어떻게 될까? 

하지만 지금 소프트웨어를 전공하는 대학생이 진로를 문의하면 나도 외국으로 나가라고 충고를 한다. 미래의 먹거리가 소프트웨어에만 있는 것은 아니지만 소프트웨어가 가장 중요한 기술 중 하나인데 개발자에 대한 인식이나 대우, 환경은 너무 열악하다. 드라마에서 잘나가는 사람들은 거의 의사, 경영자, 변호사, 검사다. 엔지니어나 소프트웨어 개발자가 주인공은 경우는 거의 없다. 사회적으로 인식이 매우 낮다는 반증이다. 

제2의 도자기 전쟁은 이미 시작되었고 핵심은 우수 두뇌 확보다. 구글이 3조원이 넘는 금액을 지불하고 네스트를 인수한 주 목적도 인재 확보다. 구글이 네스트에 지불한 금액은 1인당 100억원이 넘는다. 국가나 기업 모두 인재를 확보하기 위해서 혈안이 되어 있지만 우리나라 인재들은 외국으로 나가고 있다. 또는 기회만 되면 외국으로 가고 싶은 엔지니어도 상당 수다. 

외국의 인재도 모셔와야 하는 마당에 우리나라의 인재들이 일하기 힘든 환경을 그대로 놔두고 있는 것은 오랫동안 뿌리깊게 자리잡은 기술자 천시와 관료 우대 인식 때문이 아닐까 생각한다. 이런 기술자를 낮게 보는 인식을 없애지 않으면 구한말에 우리나라가 겪었던 고통을 또 겪어야 할지도 모른다. 나라를 좌지우지 하는 사람들은 국내 상황에 정신을 팔려서 세계의 흐름을 놓치고 있다. 나중에 애국심에 호소해서 외국에서 일하는 우리나라의 인재들에게 들어와서 나라를 다시 일으켜 달라고 해도 돌아오는 사람이 몇 명이나 될까? 

개발자들이 우리나라를 떠나고 싶어하는 가장 중요한 이유가 연봉의 차이는 아니라고 생각한다. 연봉이 높은 나라는 생활비 지출도 많고 세금도 많다. 더 중요한 것은 엔지니어에 대한 전문성의 인정과 사회적인 존경심이라고 생각한다. 창의적 지식 노동에 대한 이해와 좋은 개발환경도 필요하다. 개발자로 30년을 일해도 어린 관리자와 같이 일을 해도 전혀 어색하지 않고 어린 관리자도 늙은 개발자를 어려워하지 않는 문화가 필요하다. 생산성을 높이는 방법을 오직 야근밖에 모르는 회사가 워낙 많다. 이런 회사는 사채를 끌어 쓰는 것과 같아서 갈수록 어려워진다. 이런 환경이 계속 만연한다면 우수한 개발자 인력들은 외국으로 떠나던지 소프트웨어 업계를 떠날 것이다. 이런 환경을 수수방관하면 역사는 되풀이 될 것이다.

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

외국 개발자들이 보기에 군대 같은 한국 회사

“A기업은 좀비월드 같다. 직원들이 아무 생각 없이 회사를 떠돈다.”

“B기업 직원들은 불만을 말하지 않는다. 근무 내내 감옥에 있는 느낌이다.”

“C기업은 군대다. 상사가 말하면 무조건 따라야 한다. 이유를 묻거나 질문할 수도 없다.”

얼마 전 모 신문 기사에 나온 외국인들이 한국의 기업들에 대해 느낀 점을 얘기한 것이다.

국내에서 소프트웨어 개발에 한계를 느낀 대기업들은 해외에 여러 형태의 소프트웨어 조직을 설립하고 현지의 외국인 개발자를 채용하고 있다. 국내 개발자들의 소프트웨어 개발 실력이 떨어져서 소프트웨어를 제대로 개발하지 못했다고 착각하고 있는 것이 아닌가 생각된다.

그런데 우리나라 회사들의 조직 문화와 분위기는 외국에도 이미 소문이 많이 났다. 우리나라 기업문화 자체가 나쁘다고 볼 수는 없으나 소프트웨어 개발자들이 선호하는 문화는 아니다. 소프트웨어 전문가라고 하더라도 이런 조직 문화와 개발 환경에서 소프트웨어를 제대로 개발하기는 어렵다. 그래서 우리나라 회사에서 설립한 외국의 현지 소프트웨어 개발 센터에 들어가기를 꺼려하는 현상이 일어나는 것이다.

이렇게 소프트웨어 개발에 불리한 기업문화를 가지게 된 이유는 여러 가지가 있지만 중요한 이유 중 하나가 우리나라 회사의 경영진들은 소프트웨어 대한 개념이 없기 때문이다. 여기에 상명하복의 “까라면 깐다”는 조직 문화가 더해져서 소프트웨어 산업을 망치는 주범의 역할을 하고 있다.

A사의 사례다. 회사의 사활이 걸리는 매우 중요한 프로젝트가 있었다. 개발자들이 대충 예상을 해도1년반 이상 걸리는 프로젝트였다. 하지만 소프트웨어에 대한 개념이 없는 경영진들은 자신의 재임기간에 성과를 내기 위해서 6개월안에 완성하라고 했다. 기업의 분위기가 까라면 까야 하기 때문에 아키텍처가 완전히 망가지는 것을 감수하고 6개월 안에 완수를 했다. 하지만 그로 인한 피해는 심각했다. 제대로 아키텍처를 완전히 수정해서 개발을 했으면 기간과 비용이 2배 이상 들었지만, 급하게 6개월 안에 완성함으로써 미래에 드는 비용은 수십 배가 증가 했으며 이로 인해서 회사는 망하는 길로 들어섰다.

프로젝트를 완료했을 당시에는 경영진은 1년이 넘게 걸릴 프로젝트를 자신의 리더쉽과 독려로 6개월안에 완성했다는 것을 자랑하지만 이로 인해서 회사가 망하는 길로 들어섰다는 것은 전혀 몰랐다.

개발팀의 아키텍처에 대한 의견은 치기 어린 엄살로 간주하고 탱크같이 밀어붙이는 경영진을 능력 있는 경영진으로 간주하는 것이 현실이다. 이런 무모한 독선은 단기적인 효과는 거둘 수 있어도 미래에는 그로 인해 얻은 이익의 몇 배의 비용을 지불하게 되어 있다.

B사의 경영진은 개발자들이 6개월째 집에도 못 들어가고 프로젝트를 하고 있는 것을 자랑스럽게 얘기한다. 야근을 하면 야근 한 시간만큼 생산성이 비례해서 늘어난다는 착각에 빠져 있는 경영진은 정말로 많다. 야근 강요는 소프트웨어 개발을 지식 산업이 아닌 육체 노동 산업으로 내모는 결과를 가져온다. 야근은 대출과 같아서 단기적인 효과는 있어도 장기적으로는 생산성이 더 떨어진다. 자발적인 야근은 효과가 크지만 강압적인 야근은 생산성과 창의력을 점점 낮추게 된다. 지금도 암암리에 야근을 많이 해야지만 인정 받는 분위기 때문에 어쩔 수 없이 경영진의 기대에 맞추기 위해서 수많은 개발자들이 야근을 하고 있다.

야근은 생산성 저하 외에도 개인 생활과 가족과의 시간을 희생해야 하기 때문에 일을 위해 가족과의 시간을 희생을 감수하는 우리나라 개발자에 비해서 외국인 개발자들에게는 꺼려지는 문화가 아닐 수 없다.

국내의 한 회사에서는 간부들에게는 제품의 아키텍처와 디자인에 절대로 간섭하지 못하도록 최고 경영자의 지시가 있었다. 회사 초창기에는 간부들의 통찰력이 어느 정도 통했지만 회사가 커지고 제품이 복잡해지면서 더 이상 간부들의 간섭은 통하지 않고 오히려 망치는 길이라는 것을 경험적으로 깨달은 것이다.

우리나라 대기업의 경영진들은 자신들이 척박한 환경에서 그 짧은 시간에 기적적으로 회사를 성장 시켰듯이 소프트웨어 역량도 순식간에 따라 잡을 수 있다고 생각한다. 하지만 이는 대단한 착각이다.언뜻 보기에는 간단해 보이는 소프트웨어가 인류가 만들어낸 지식 산업 중에서 가장 복잡하고 어렵다는 것이다.

그 동안 기존 산업에서 익혀온 성공 방정식을 소프트웨어에도 적용하다 보니 잠깐의 반짝 성공은 있었을지 몰라도 급한 한발 내딪음으로 인해서 두발 더 뒤쳐지게 되었다.

외국인 개발자들이 꺼려하는 이러한 환경은 국내 개발자들도 똑같이 꺼려하는 환경이다. 단지 국내에 태어났기 때문에 다른 선택이 어려워 그런 환경이라도 꾹 참고 일을 하고 있는 것이다. 그래서 요즘은 처음부터 외국 기업을 찾는 개발자자도 많다.

외국인들을 위해서 외국인에게 인기가 있는 회사를 무조건 만들라는 것은 아니다. 외국인 개발자에게 인기가 없는 회사가 소프트웨어 개발에 불리한 환경이라는 것이다. 외국인 개발자들에게 인기가 있는 회사가 된다면 국내 개발자들도 일하기 좋은 환경이 될 뿐만 아니라 소프트웨어 산업 전체의 경쟁력도 증가할 것이다.

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

쓸데없는 회의를 줄이는 방법

'회의가 많은 회사는 곧 망한다'는 속설이 있다. 다른 분야에서도 마찬가지지만 개발자도 회의에 많은 시간을 빼앗기면 개발에 집중하기 어렵고 이는 개발 생산성 저하로 이어진다. 꼭 필요한 회의는 해야 하지만 과도한 회의는 줄여야 한다. 그럼 어떻게 회의를 줄일 수 있을까? 
 
물론 개인 혼자서 회의를 줄이려고 노력한다고 해서 되는 것은 아니다. 직원들이 회의를 줄이는 것이 왜 중요하고 어떻게 줄여야겠다는 방법도 서로 공유를 하고 노력을 해야 한다. 일단 회의가 얼마나 비싼 활동인지 생각해보자. 
 
10명이 1시간동안 회의를 하면 얼마의 비용을 쓴 것일까? 회사마다 다르겠지만 적게 잡아도 100만원쯤 쓴 것으로 생각하면 된다. 개발자는 1인당 회사에서 사용하는 비용은 급여와 부대비용을 계산하면 알 수 있다. 여기에 개발자가 그 시간 동안 다른 일을 했을 때의 기회비용까지 계산하면 최소한 한 시간에 10만원은 생각해야 한다. 이보다 낮다고 주장하는 개발자가 있을 수도 있지만 평균 이 정도는 생각해야 한다. 
 
30명이 참석하는 회의에 몇 사람이 늦게 와서 10분 늦게 시작하면 50만원은 그냥 손해를 본 것이다. 이렇게 회의에 직접적으로 소모하는 비용과 회의에 참석하기 위해서 준비를 하거나 자료를 읽는 시간, 회의 참석에 이동하는 시간, 앞뒤로 어영부영 지나가는 시간을 합치면 훨씬 많은 시간을 소모하게 되고 그 비용은 상당하다. 
 
이렇게 비싼 회의는 꼭 필요한 경우에만 효율적으로 해야 한다. 그렇지 않고 회사의 생산성을 높일 수는 없다. 그럼 어떻게 회의를 줄일 수 있는지 알아보자. 회의를 줄이기 위해서는 아래 3가지 원칙을 지키면 된다. 
1. 회의를 하지 않는 것이다. 
2. 회의에 참석하지 않는 것이다. 
3. 회의 시간을 줄이는 것이다. 
 
첫째, 안해도 되는 회의는 하지 않는다. 회의를 전혀 안할 수는 없다. 특히 의사결정은 문서나 시스템으로 하기 어렵고 대부분은 회의를 통해야 한다. 하지만 회의를 하지 않거나 대규모 회의로 하지 않아도 되는데 무신경하게 또는 일상적으로 회의를 하는 경우가 많다. 
 
정보를 단순 공유하거나 브리핑을 위한 회의는 줄일 수가 있다. 일상적으로 시스템을 통해서 공유가 잘 되는 회사는 이런 단순 공유 회의는 거의 하지 않는다. 단, 시스템을 잘 쓴다는 전제하에 이런 회의는 거의 하지 않아도 되는 것이다. 이를 위한 가장 중요하고 유용한 시스템은 이슈관리시스템이다. 이슈관리시스템은 소프트웨어 회사에서는 없어서는 안될 중요한 시스템이다. Trac, Jira, Mantis, Redmine과 같은 시스템이다. 
 
하지만 필자의 블로그에서 시행하고 있는 수년간의 설문 통계를 보면 약 40%의 회사는 아직도 이슈관리시스템을 사용하고 있지 않다. 이메일과 엑셀 등으로 이슈를 주고 받거나 관리를 하는데 그렇게는 효율적인 소통이 어렵다. 게다가 이슈관리시스템을 사용하고 있는 회사도 정말 효율적으로 잘 쓰고 있는 회사는 10%가 안된다. 
 
회의를 줄일 수 있을 정도로 이슈관리시스템을 잘 쓰는 방법은 책 한권으로 설명해도 부족하겠지만 요약하면 다음과 같다.
 
모든 공식적인 요청은 이메일, 전화, 말로 하지 않고 이슈관리시스템에 등록해야 한다. 나머지는 보조수단이다. 전 임직원이 예외 없이 규칙을 따라야 한다. 이슈관리시스템에 대시보드를 자신에게 맞게 잘 만들어서 적어도 하루에 한번 이상 대시보드를 확인하고 처리를 해야 한다. 이슈관리시스템에 이슈를 등록하고 상태를 변경하며 댓글을 다는 등의 행동은 성의껏 해야 한다. 
 
내가 남긴 한 줄의 문장을 수많은 사람이 읽고 공유가 되며 대화와 회의를 대신하고 오랫동안 남아서 여러 사람에게 정보를 제공할 것이기 때문에 엉터리 문장으로 적으면 안된다. 10년 후에 후배가 봤을 때 알아 볼 수 있도록 잘 적어야 한다. 물론 이렇게 사용하려면 무신경하게 엉터리로 사용하는 것보다 약간의 노력이 더 필요하지만 충분히 그럴 가치가 있다. 
 
둘째, 내가 참석하지 않아도 되는 회의는 참석하지 않는다. 
 
회의는 참석자가 적을수록 효율적이다. 내가 참석하지 않아도 되는 회의는 참석하지 않아야 한다. 그리고 회의에 똑 필요한 인원만 초청을 해야 한다. 
 
회의 참석의 목적은 여러가지가 있지만 의사결정을 하기 위한 것이거나, 전문가로서 의견 제시하거나 정보를 습득하려는 등의 목적이 있다. 
 
가끔 회의 요청을 받으면 이런 단순 정보 공유 회의에 내가 왜 참석해야 하는지 의문이 들 때가 있다. 특히 내게 당장 필요하지는 않지만 알면 좋은 정도로 애매한 경우도 있다. 이런 때는 내가 지금 이 시간을 투자해서 참석할 필요가 있는 회의인지를 판단해야 한다. 물론 이런 회의에 무조건적으로 참석하라고 하면 안된다. 누구나 들으면 좋은 회의라고 참석자를 잔뜩 늘려서 초청을 하면 수백만원의 비용을 지불하는 것이라는 생각을 잊으면 안된다. 
 
내가 전문가로서 의견을 제시해야 하는 경우라면 회의 내용을 사전에 꼭 숙지를 하고 참석해야 한다. 이런 회의에 전문가가 아닌 사람을 여러명 불러 놓고 난상토론을 하는 것은 정말로 시간 낭비다. 회의 때마다 잘 알지도 못하지만 그냥 이슈를 마구 던지거나 자신의 취향이 전문적인 의견인양 얘기하는 사람들이 있다. 이런 회의의 참석자는 꼭 필요한 사람으로 잘 꾸려야 한다.
 
리뷰 회의가 대표적이다. 교육적인 목적으로 내용을 익히려고 참석하는 경우도 있지만 각 분야의 가장 전문가가 미리 내용을 한 글자, 한 글자 꼼꼼히 읽어보고 빠르게 의견을 제시해야 한다. 그래서 고참이 될수록 이런 리뷰 회의에 참석하는 일이 많아지게 된다. 
 
셋째, 회의 시간은 최소화 해야 한다. 
 
회의 시작 전에 회의 아젠다를 미리 공유하고 회의 자료나 문서를 미리 배포해야 한다. 회의는 시작 시간과 종료 시간을 미리 정해야 하며 무작정 길게 시간을 잡는 것은 삼가야 한다. 회의에 따라서 다르지만 대부분의 배포된 문서를 꼼꼼히 읽고 와야 한다. 경영진이라고 하더라도 미리 꼼꼼히 읽어야 한다. 회의시간에 자료를 다시 브리핑하는 것은 여간 낭비가 아니다. 
 
따라서 회의 공지는 자료를 충분히 검토할 시간이 필요하므로 충분히 미리 해야 한다. 회의 1,2시간 전에 갑자기 공지를 하면 준비할 시간이 부족하게 된다. 
 
회의시간에는 회의에 집중해서 계획한 시간 안에 꼭 내도록 노력해야 한다. 쓸데 없이 경영진이 교장선생님처럼 이런 저런 얘기를 하는 것은 좋지 않다. 회의 주제에 집중해야 한다. 
 
개발자들과 아침에 하는 5분 회의는 효율적인 회의의 대표적인 예다. 자료는 이슈관리시스템에 있고 대시보드를 확인하며 주요 이슈만 확인을 하고 꼭 공유해야 할 내용을 얘기하면 개발팀 일일회의는 5분에서 10분안에 끝나게 된다. 
 
그 외에 스카이프나 구글행아웃을 이용한 원격회의도 회의를 효율적으로 하게 해준다. 회의를 위해서 먼거리를 이동하지 않고 원격으로 회의를 할 수 있고 요즘은 스마트폰으로 회의를 하기도 한다. 코드리뷰시스템을 사용하는 것도 좋은 방법이다. 온라인으로 코드리뷰를 할 수 있도록 하여 코드리뷰 자체의 효율성도 높아지고 코드리뷰 때문에 모여야 하는 시간을 줄여주고, 코드리뷰 내용을 모든 사람과 공유할 수 있어서 좋은 정보가 된다. 
 
마지막으로 회의를 했다면 가능하면 빠른 시간에 회의록을 정리하여 회의 참석자와 참석하지는 않았지만 관련된 모든 사람에게 회의록을 배포해야 한다. 이슈관리시스템 등의 시스템을 활용해서 회의록을 배포, 관리하는 방법도 좋다. 
 
다시 한번 회의가 얼마나 비싼 활동인지 명심하자. 하루에 회의 3,4번이면 개발자는 다른 일은 거의 못한다. 개발자뿐만이 아닐 것이다. 회의는 지금의 10분의 1로 줄인다는 마음으로 회의를 줄여보자.

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