편한 개발환경이 가져온 부작용

필자는 개발자를 채용할 때 인터뷰 시 칠판을 이용한 코딩 테스트를 꼭 실시한다. 아무리 화려한 이력을 가지고 있다고 하더라도 코딩 테스트를 통과하지 못하면 채용하지 않는다. 코딩 테스트 문제는 정말 간단하다. 

숫자를 문자로 변환한다든지, 숫자 몇 개를 정렬하는 등 아주 단순한 문제다. 코딩 테스트에서 확인하는 것은 개발자의 논리적인 사고, 창의력, 문제 해결 능력이다. 그리고 문제를 해결하기 위해서 면접관과 어떻게 커뮤니케이션을 해나가는지 보는 것도 중요한 요소다. 문법은 중요하게 보지 않고 개발언어는 아무거나 선택해도 된다. 

실제로 여러 지원자에게 코딩 테스트를 실시하면 안타깝게도 코딩 테스트를 통과하는 비율은 매우 낮다. 경력은 화려하게 잘 얘기하는데 코딩 및 논리적인 사고는 어처구니 없이 형편없는 경우가 많다. 그래서 서류 심사를 통과한 지원자를 대상으로 온라인 코딩 테스트를 먼저 실시하곤 한다.

온라인 코딩 테스트는 약간 난이도가 있는 문제를 주고 24시간 안에 코딩을 해서 제출하게 하는 것이다. 컴파일이 되어야 하고 실행이 되어야 하며 알고리즘의 효율성을 보기 위해서 실행 제한 시간도 있다. 이런 온라인 코딩 테스트는 어차피 인터뷰에서 탈락할 지원자를 걸러줌으로써 인터뷰 시간과 비용을 절약하는데 도움이 된다. 

얼마 전 온라인 코딩 테스트를 실시하는데 어처구니 없는 일이 발생했다. 온라인 코딩 테스트는 꼭 본인이 작성해야 한다는 규칙이 있다. 하지만 온라인의 특성상 주변 지인들에게 약간의 힌트성 도움을 받는 것은 어쩔 수 없다고 생각하고 있다. 출제한 문제는 유명한 코딩 테스트 사이트에서 가져온 문제다. 

하지만 지원자는 문제를 받자마자 본인이 풀 생각을 하지 않고 바로 인터넷을 검색하여 해당 사이트를 찾아냈다. 그리고 해당 문제를 푼 사람을 찾아서 소스코드를 보내달라는 이메일을 보낸 것이다. 그런데 이메일을 받은 사람은 프로 개발자가 아니라 초등학생이었던 것이다. 전문 개발자를 채용하려고 실시하는 코딩 테스트에서 자신이 못 풀겠다고 초등학생에게 소스코드를 요청하는 일이 발생한 것이다. 

인터넷을 검색해서 알고리즘을 참고한다 던지 아이디어를 구하는 것은 가능하지만 소스코드를 달라고 하는 것은 명백한 속임수(Cheating)이라고 생각한다. 이런 개발자는 실력을 떠나서 채용할 수가 없다. 

다른 사례다. 온라인 코딩 테스트를 훌륭하게 통과해서 인터뷰를 진행한 개발자 얘기다. 그런데 칠판 코딩 테스트에서 이상한 일이 발생했다. 온라인 코딩 테스트 문제는 개발자의 논리력, 창의력이 없으면 풀기 어렵기 때문에 칠판 코딩 테스트에서 좋은 결과를 보여줄 것으로 예상했는데 인터뷰 현장에서 형편 없는 결과를 보여줬다. 

혹시 긴장해서 원래 실력을 보여주지 못하는 것이 아닐까 생각해서 여러가지 질문을 해봐도 원래 실력이 없었다는 것이 확인이 되었다. 그렇게 탈락을 한 후 이상한 생각이 들어서 온라인 코딩 테스트에서 제출한 답안을 인터넷에 검색을 해보니, 해당 문제를 미국에서 자바로 풀어 놓은 답안과 한 글자도 틀리지 않고 동일한 것을 확인했다. 

그 뒤 온라인 코딩 테스트를 세상에 없는 문제로 새로 만들어야 고민을 했지만 지원자가 속임수를 쓰는지 확인할 수도 있으므로 그냥 진행하기로 했다. 단, 지원자에게는 본인이 직접 풀어야 한다고 꼭 당부를 하고 있다. 

이런 일이 발생하는 이유는 무엇일까? 요즘 개발자들은 과거에 비해서 훨씬 개발하기 편한 환경에 있다. 개발하다가 필요한 모듈이나 알고리즘은 인터넷을 검색해보면 다 찾을 수 있다. 그러다 보니 원리는 생각하지도 않고 본인이 이해도 하지 않고 그냥 인터넷에서 소스코드를 가져다가 사용하는 경우가 매우 많다.

과거에 인터넷(웹)이 없을 때나 초창기 까지는 소스코드를 구할 곳은 책을 제외하고는 별로 없었다. 그래서 개발자들이 책을 많이 보고 본인이 이해를 해서 직접 구현을 해야 했고, 그러다 보니 소프트웨어 이론에 대해서 속속들이 잘 알아야 했다. 과거에 뛰어난 개발자가 더 많았던 이유는 이런 환경에 기인한 것이 아닌가 생각된다. 

요즘은 쉽게 소스코드를 구할 수 있다 보니 깊게 생각하는 습관을 가지기는 어렵다. 개발자들의 고충을 이해하지 못하는 것도 아니다. 촉박한 시간 안에 빨리 구현을 해내야 하고 누가 설계를 잘 해주는 것도 아니고 서로 리뷰를 통해서 내가 작성한 코드를 누가 잘 봐주는 경우도 흔치 않다. 

그러다 보니 부랴부랴 인터넷에서 구한 소스코드를 이해도 못하고 그대로 사용하기 일쑤다. 요즘 개발자들을 만나보면 소프트웨어 이론을 속속들이 잘 모르는 경우가 많다. 메모리의 기본 구조도 잘 모르고 기본적인 자료구조와 알고리즘도 잘 모르곤 한다. 대학에서 이런 기본 이론을 철저히 가르쳐야 하는데 이런 이론보다 실무를 가르치는 것이 아닌가 의구심이 들기도 한다. 모든 대학이 그런 것은 아니지만 이론보다 실무를 가르친다면 학원과 다를 것이 없다. 그래서 실무 중심 사관학교라는 대학의 광고를 듣다 보면 안타까운 생각이 든다. 

이렇게 개발하기 좋은 환경이 오히려 개발자들의 실력을 떨어뜨리고 있는 것이 아닌가 걱정이 되고 있는 사례들이다. 현재 소프트웨어 공부를 하고 있는 학생이라면 실전 코딩보다도 소프트웨어 기초 이론을 철저히 익히라는 얘기를 하고 싶다. 실전 경험도 중요하지만 기초가 약하다면 언제든지 문제가 될 수 있다. 

회사에서는 개발자에게 이론, 경험을 전파하는 수단은 코드리뷰, 설계리뷰다. 선배 또는 동료가 소스코드나 설계서를 보고 리뷰를 하면서 서로의 경험과 이론, 노하우를 전달하는 것이다. 서로 리뷰를 통해서 개발자는 같이 성장해나가는 것이다. 피어리뷰(동료검토)를 하지 않거나 형식적으로 하지 않는 회사에서는 개발자들의 성장이 몇 배 느릴 수 밖에 없다. 

개발자는 구글을 믿고 개발을 할 것이 아니고 믿어야 할 것은 자신의 두뇌와 동료들이다. 구글은 단지 거들뿐이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

개발자에게 재택 근무가 필요한 이유

과거 서울 남부의 경기도에서 소프트웨어 개발자를 채용할 때였다. 서울에서 별로 멀리 떨어져 있지 않은 경기도에 있는 곳인데도 많은 지원자들이 거리상의 문제로 지원을 포기 했고, 특히 서울 북부에 사는 사람들은 인터뷰 시에도 출퇴근의 어려움에 대한 걱정을 토로했다. 

얼마 전 한 소프트웨어 회사는 서울에서 판교로 사옥을 이전했다. 그런데 서울 북부나 일산 등지에 사는 직원들을 주축으로 많은 개발자들이 회사 이전과 동시에 퇴사를 했다. 특히 몇몇 핵심 개발자들의 퇴사는 회사의 큰 손해가 아닐 수 없었다. 

아직도 우리나라 소프트웨어 회사의 근무형태는 농업사회에서 보여주는 전통적인 근면 성실을 강조하는 근무 시스템에서 크게 벗어나지 못하고 있다. 시간에 맞춰서 출퇴근을 하고 야근까지 하면서 상사에게 오랜 시간 열심히 땅을 파는 모습을 보여줘야 ‘열심히 일을 하고 있구나’ 하며 안심을 한다. 이런 현상을 보면 소프트웨어 개발이 지식 산업이 아닌 노동집약적 산업이라고 오해하고 있다는 생각이 든다. 

이렇게 시간 딱딱 맞춰서 사무실 자리에 앉아서 일을 해야 하는 시스템은 많은 한계를 가지고 있다. 대한민국이 아니라 미국이라면 어떨까? 거리의 제약은 수십배로 커진다. 많은 개발자들은 회사 근처로 이사를 하기도 하지만 재택 근무 형태로 일하는 개발자도 많다. 

재택 근무가 가능하면 회사에 꼭 필요한 개발자를 거리의 제약 없이 채용 할 수 있다. 같은 재택근무라도 상황에 따라서 근무 조건은 매우 다양하다. 일주일에 한번씩 출근을 하기도 하고 아예 원격으로 일하는 개발자들도 있다.

우리나라에서는 직장이 너무 멀어서 출퇴근에 2, 3시간씩 걸려도 아이들 학교 문제도 있고 직장을 옮길 때마다 이사를 하기는 쉽지가 않다. 그래서 개발자 채용에 거리 제약이 있고 회사에 꼭 필요한 개발자인데도 채용하기 어려운 경우도 많다. 

재택근무가 일반적이지 않은 이유는 옆에 앉아 같이 일하지 않으면 일이 제대로 진행되지도 않고 어떻게 일을 하고 있는지 알 수도 믿을 수도 없기 때문이다. 같이 모여서 일하지 않으면 일이 제대로 진행되지 않는다. 

필자는 여러 회사에서 강연이나 세미나를 할 때 종종 “여러분이 모두 회사에 나오지 않고 집에서 원격으로 일하면 어떻게 됩니까?”라는 질문을 한다. 100%의 회사들이 일이 전혀 제대로 진행되지 않을 것이라고 얘기를 한다. 개발자들은 허무맹랑한 질문이라는 표현을 하기도 한다. 이는 단지 재택근무가 가능한지 불가능한지 문제는 아니다. 

재택근무가 불가능한 회사는 문화적으로 프로세스적으로 개선할 점이 많은 회사다. 회사가 개발에 필요한 시스템을 잘 갖추고 있고 공유와 문서화가 잘 되어 있으면 재택근무는 그렇게 어려운 일이 아니다. 오히려 집에서 일하는 것이 더 효율적인 경우가 많다. 

재택근무가 불가능한 회사에서는 개발자들이 수시로 물어보고 의논을 하고 회의도 해야 한다고 한다. 이런 환경을 보면 회의가 너무 많고 공유와 문서화가 잘 안되어 있다는 것을 단적으로 알 수 있다. 문서나 시스템으로 대부분의 내용은 공유하고 대부분의 커뮤니케이션은 시스템을 통해서 해야 한다. 회의도 스카이프등을 이용해서 원격으로 할 수 있다. 

꼭 대면회의가 필요한 경우에 회사를 나오면 된다. 이런 환경이 갖춰지면 재택근무가 가능하다.

재택근무를 하면 개발자들이 열심히 일하는지 알 수 없어서 그렇게 할 수 없다는 회사 관계자도 만난 적이 있다. 하지만 회사에 있으면 열심히 일하는지 알 수 있는가? 시스템, 문화와 프로세스가 제대로 되어 있으면 개발 성과와 결과물이 시스템에 제대로 남고 동료 검토를 통해서 동료들이 서로 누가 어떻게 일하는지 다 알고 있다. 

옆에서 일하나 멀리서 일하나 다 알 수 있다. 하지만 그렇지 않으면 옆에서 일해도 커뮤니케이션이 어렵고 누가 열심히 일하고 누가 놀고 있는지 잘 알지 못하는 경우가 많다. 

지금 당장 이런 성숙된 문화와 효율적인 프로세스와 시스템을 갖추지 않고 재택근무를 추진한다면 어떻게 될까? 우려하고 있는 모든 문제가 드러날 것이다. 재택근무는 거리의 제약을 뛰어넘어 뛰어난 개발자를 채용할 수 있게도 할 뿐만 아니라 가정에 사정이 있는 개발자도 회사를 그만두지 않아도 된다. 

가정 사정상 아이를 돌보기 위해서 회사에 10시부터 3시까지 밖에 있지 못하는 뛰어난 개발자가 있다고 하자. 이렇게 일하는 것을 어떻게 허용할 것인가? 누구는 일주일에 이틀밖에 회사에 나올 수 없다고 하자. 이런 개발자가 회사에 꼭 필요한 사람이라면 채용해서 활용할 수 있을 것인가? 

재택근무는 그 자체로도 필요하고 회사의 문화나 프로세스의 성숙도를 가늠할 수 있는 지표로 볼 수도 있다. 필자는 회사에서는 야근을 별로 하지 않고 야간과 주말을 가리지 않고 회사의 시스템에 붙어서 이슈를 확인하고 의논을 하며 코드리뷰를 하는 등스스로 찾아서 일을 하는 것이 일상화 되어 있다. 가족이 나를 필요로 할 때 가족과 지낼 수 있으며 언제 어디서나 일할 준비가 되어 있고 일을 할 수 있다. 주말에도 굳이 회사에 나가지 않아도 원격으로 쉽게 일할 수 있다. 시간, 공간적인 제약은 별 문제가 되지 않는다. 

우리 회사는 개발자들의 재택근무가 가능하지 생각해보자. 현재는 어렵다는 생각이 든다면 그 이유가 회사에서 모여서 일할 때도 비슷한 문제를 가지고 있을 가능성이 높다. 어떻게 고쳐나가야 하는지 생각해보자. 재택근무가 가능한 시스템이 회사의 개발 문화 성숙도를 한층 높여줄 것이다.

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

SW업계에는 망치를 만드는 사람이 많다

누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서 쓰는 사람들이 매우 많다. 소프트웨어 업계에도 망치와 못을 전문적으로 만드는 회사가 꽤 많지만 우리나라에서는 장사가 잘 안 되는 것이 현실이다. 

이같은 상황은 흔히 NIH(Not Invented Here) 신드롬이라고 불리기도 한다. 우리나라의 경우 더 심한 경향을 보이고 있고 이유도 매우 다양하다. 기업간에 협업이 잘되어야 망치회사도 흥하고 망치를 사다 쓰는 회사도 직접 만들어 쓰는 것보다 훨씬 효과적으로 소프트웨어를 개발할 수 있다. 망치 회사가 흥해야 망치를 만드는데 필요한 툴을 만드는 회사도 흥해서 덩달아 여러 회사가 잘되게 된다. 그런데 왜 우리나라에서는 이렇게 기업간의 협업이 잘 안 되는 것일까?

나는 여러 소프트웨어 관계자를 만나는데 엔진, 라이브러리 류의 소프트웨어를 개발하는 회사들은 국내 시장의 특수성에 대해서 하소연을 한다. 자신들의 솔루션이 국내 소프트웨어 회사들에게는 별로 인기가 없고 해외에서는 찾는 사람이 많다고 한다. 국내에서는 특히 조심을 하는 것이 기업들은 가격을 후려치려고 하고 데모를 보여주면 그대로 흉내 내서 만들기도 한다는 것이다. 물론 엉터리로 흉내는 내는 것이지만 이런 식으로 국내에서는 별로 비전이 없다고 한다. 

기업들은 자신들의 전문 분야에 집중하고 전문 분야를 개발하는데 필요한 툴이나 시스템은 다른 기업과 협력을 하는 것이 좋은데 이런 협력이 잘 안 되는 이유를 한번 살펴보자. 

첫째, NIH(Not Invented Here)신드롬이다. 

자신들이 최고라고 생각하면서 자신들이 직접 개발하지 않은 것은 배척하는 현상이다. 이런 개발자들을 인터뷰해보면 자신들이 개발하는 것은 너무 어려워서 자신들, 자신의 회사에서 밖에 개발하지 못한다는 얘기를 한다. 이와 똑같은 현상이 여러 기업에서 벌어지고 있으므로 똑똑한 사람들은 여기 저기 많이 있으며 외부의 창의력과 좋은 아이디어도 받아들일 마음가짐이 되어야 한다. 

세계적인 3D 설계 소프트웨어를 개발하는 오토데스크(Autodesk) 사는 진작부터 3D그래픽엔진은 테크소프트3D(TechSoft3D)사 엔진을 사용하고 있다. 그래픽관련 부분은 전문업체에 맡기고 자신들은 설계 애플리케이션에 집중하기 위해서다. 

둘째, 근시안적으로 비용을 절약하려는 경우다. 

요즘은 오픈소스 소프트웨어가 넘쳐나서 외부의 도움을 받을 수 있는 라이브러리, 툴, 컴포넌트 등이 많지만 여전히 상용 소프트웨어의 도움이 필요한 분야도 많다. 때로는 오픈소스와 상용 소프트웨어 사이에서 저울질을 해야할 때도 있다. 라이선스 계약에 따라서 제품을 팔 때마다 몇 % 또는 얼마의 비용이 계속 발생하기 때문에 커다란 결정이 아닐 수 없다. 

상용 소프트웨어를 활용하면 라이선스 비용 외에는 커다란 추가 비용이 없이 본연의 개발에 집중할 수 있다. 하지만 라이브러리, 툴, 엔진류를 직접 개발하면 개발 비용이 꾸준히 들어가게 된다. 오픈소스를 이용할 경우에도 이를 학습하고 유지하기 위해서 상당한 비용이 들어간다. 소프트웨어는 아기처럼 한번 탄생하고 나면 먹여주고 재워주고 비용이 계속 들어간다. 

초기 개발 비용의 수십배, 수백배가 들기도 한다. 상용 소프트웨어를 구매하는 비용은 명확하게 비용으로 보이지만 직접 개발하는데 들어가는 비용은 초기 개발비용만 고려해서 우습게 보는 경향이 있다. 하지만 대부분의 경우 직접 개발하는데 드는 비용이 상용 소프트웨어를 사다 쓰는 비용보다 훨씬 많이 들어간다. 게다가 더 큰 문제는 회사에서 본연의 제품에 집중하지 못하고 망치 만들고 못 만드는데 노력이 분산 된다는 것이다. 심지어는 망치를 잘못 만들어서 집을 제대로 만들지 못하기도 한다. 

물론 무조건 상용 소프트웨어를 써야 한다는 것은 아니다. 직접 개발을 하거나 오픈소스를 활용하는 것이 좋은 경우도 아주 많다. 여기에 들어가는 비용을 절대로 사소하게 생각하면 안된다는 것이다. 상용 소프트웨어라 하더라도 협력하기에 따라서 표준 제시 가격보다 획기적인 라이선스 조건으로 계약을 하는 것은 아주 흔한 일이다. 서로 윈윈할 수 있는 조건만 잘 맞는다면 가격은 그렇게 큰 장애물이 아니다.

셋째, 우리는 다르다고 생각하는 것이다. 

개발에 필요한 기반시스템을 구축해야 하는데 회사의 프로세스가 다른 회사들과 달라서 사다 쓰지 못하고 직접 개발을 해야 한다고 주장하는 경우를 많이 보았다. 한 예가 이슈관리시스템이다. 버그추적시스템이라고도 한다. 자신들의 회사는 개발 프로세스가 일반적인 경우와 달라서 거기에 맞추느라고 직접 개발을 해서 쓴다고 한다. 

하지만 대부분의 경우 우물 안의 개구리 같은 생각이다. 예외적인 몇 가지 경우를 제외하고는 자신들의 프로세스 자체가 잘못되거나 비효율적인 경우다. 그런데 그런 프로세스가 옳고 이에 맞는 시스템이 없다고 착각을 하고 있는 것이다. 시중에는 Mantis, Redmine, Jira 등 좋은 이슈관리, 버그추적 시스템이 많이 있고 이런 툴을 제대로만 사용한다면 좋은 개발 문화도 덤으로 얻을 수 있다. 자신들의 프로세스가 이런 툴과 맞지 않는다면 툴을 직접 개발하기 보다는 프로세스를 툴에 맞추는 것이 나을 가능성이 훨씬 높다. 

넷째, 상용 소프트웨어에는 없는 기능이라서 직접 개발해야 한다고 주장하는 경우다. 

여러 상용 소프트웨어 또는 오픈 소스를 조사해봐도 99%는 만족하는데 1% 기능이 부족해서 사용하지 못하는 경우도 많다. 그런데 예상외로 상용 소프트웨어를 만드는 회사들은 추가 기능 개발 요청에 상당히 적극적인 경우가 많다. 그런데 그런 시도를 해보지도 않고 그냥 포기를 하고 직접 만든다고 하곤 한다. 

당장 오늘 내일 필요한 것이 아니고 기획단계에서부터 검토를 할 경우 수개월의 여유기간이 있고 이 기간 동안에 추가 기능을 개발할 회사는 얼마든지 찾을 수가 있다. 하지만 이렇게 계획적으로 개발을 하지 않고 당장 필요하다고 하면 외부 업체와 협력할 시간적인 여유는 없게 된다. 급하다고 직접 만들기도 하는데 이는 새로운 문제의 시작일 가능성이 높다. 

영어 또한 상당히 큰 장벽이다. 이런 것을 조사하고 추가 개발을 요청하고 협력 방안을 조율하려면 어설픈 영어 가지고는 부족하다. 영어도 잘하고 소프트웨어 업계가 어떻게 돌아가는지도 잘 알아야 하기 때문에 그냥 영어만 잘하는 사람 가지고도 안 된다. 그래서 영어 실력이 부족하다 보니 시도도 못해보거나 시도를 해보다가도 매끄럽게 협력이 잘 안되는 경우가 많다.

소프트웨어 회사들이 다양한 소프트웨어를 개발하고 서로 협력해서 서로 키워가는 것은 전체 소프트웨어 생태계의 성장에 중요한 역할을 한다. 그런데 빌딩을 만드는데 집중할 업체에서 망치를 만드는데 신경을 쓰고 망치 업체는 망하고 이런 일이 반복되면 소프트웨어 생태계는 점점 쪼그라들고 만다. 

개발자들도 문제다. 기술을 잘 모르는 경영자들은 이런 판단을 직접 할 수는 없다. 개발자들에게 망치를 만드는 것이 좋은가, 사다 쓰는 것이 좋은가 물어볼 때 위에 제시한 이유들을 들어서 직접 개발해야 한다는 주장을 하는 경우가 압도적으로 많다. 잘못된 판단으로 빌딩을 만드는 회사는 망해도 개발자에게는 망치를 만드는 기술이 남았다고 생각할지는 몰라도 망치 전문업체의 기술에 비하면 “새발의 피”에 불과한 기술일 뿐이다. 

각 기업에서 이런 잘못된 판단이 이루어지는 이유 중 하나는 CTO의 부재 때문이다. 이런 결정은 회사의 미래에 매우 중요한 결정이기 때문에 개발자 한 명의 의견을 들어서 결정하는 것도 위험하고 회사의 기술을 책임지는 CTO가 결정을 해야 한다. 

소프트웨어 개발은 개인간의 협업도 중요하지만 기업간의 협업도 매우 중요하다. 내 것이 최고라는 생각을 버리고 서로 협력을 할 때 전체 소프트웨어 생태계가 좀더 나아질 것이다.

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

평등한 토론이 SW혁신 만든다

소프트웨어에서 창의적인 혁신은 천재 한 사람의 머리에서 나오는 것이 아니다. 여러 직원들의 격 없는 평등한 토론에서 탄생하는 것이다. 이런 토론 문화 없이 혁신적인 소프트웨어가 탄생하기는 어렵다. 이는 비단 소프트웨어만의 문제는 아니다. 

우리는 흔히 회의를 하면 침묵을 지키는 사람들이 많다. 좋은 아이디어를 얘기하면 “그래, 네가 꺼낸 아이디어니까 네가 책임지고 완료해봐”라고 시키기 일쑤다. 꺼낸 얘기에 대해서 상사에게 면박을 당하기도 하고 교장님 훈시처럼 얘기를 듣고 있어야 하기도 한다. 이런 일이 반복되다 보니 좋은 아이디어가 있어도 얘기를 안하고 점차 시키는 일만 하게 된다. 

옛말에 “가만히 있으면 중간이라도 간다”는 말이 있지만 회의 분위기를 이렇게 만드는 회사에서는 혁신과 발전을 기대하기는 어렵다. 상사의 문제도 있지만 우리나라에서는 어려서부터 토론 훈련이 안되어 있어서 회사에서도 토론이 어렵다. 나도 마찬가지로 그런 환경에서 자라왔다. 그런 토론 훈련 없이 직장에서 동료들과 토론을 하다 보면 권위의식을 내세워서 토론을 망치곤 한다. 

우리나라가 원래 이렇게 토론에 관심이 없었던 것은 아니다. 고대 그리스 때도 교육의 기본은 토론이었듯이 공자도 제자들과 열띤 토론을 했듯이 우리나라도 조선시대에는 토론이 중요한 교육의 중심이었다. 우리나라에 토론이 사라지고 “상명하복”만 남게 된 결정적인 이유가 전쟁과 군사정권을 거치며 군대식 문화가 교육에도 적용된 것이 아닌가 생각한다. 내가 고등학교를 다닐 때도 열심히 외워서 시험을 잘 보면 되지 논리적으로 얘기를 해서 누구를 설득할 필요가 없었다. 

지금이라도 마음먹고 평등하고 자유롭게 토론을 하면 된다고 생각하지만 그렇게 쉬운 일은 아니다. 훈련이 안되어 있으면 몸에 벤 습관이 툭 튀어나오게 되어 있다. 문화라는 것이 누구 하나 바뀐다고 해결되는 것이 아니라서 토론 문화도 마찬가지로 한사람이 아무리 평등하고 자유로운 토론을 하자고 부르짖어도 상사 한사람이 분위기를 망칠 수 있다. 평등한 토론을 하려면 모두가 바뀌어야 한다. 

좋은 토론 문화는 다음과 같은 것들이 있다. 

남의 얘기 경청하기, 논리적으로 설득하기, 적극적으로 참여하기, 주제에 집중하기, 좋은 남의 의견을 받아들이기, 창의적이고 자유롭게 얘기하기, 서열과 관계없이 어떠한 얘기라도 하기 등이다.

반대로 나쁜 토론 문화에는 다음과 같은 것들이 있다. 

권위 내세우기, 비 논리적으로 얘기하기, 과장해서 판단을 흐리기, 잘못된 정보를 얘기하기, 남의 얘기 끊고 끼어들기, 면박주기, 무조건 딴지 걸기, 침묵하기, 화내기, 우기기, 때쓰기, 남의 얘기를 전혀 받아들이지 않기, 인식공격하기, 비방하기, 주제에서 벗어난 딴 얘기 하기, 떠넘기기다.

나쁜 토론 문화는 나도 수많은 회의에서 실제로 경험한 것들을 적은 것이며 이런 곳에서는 교장선생님 훈시 수준을 못넘는 회의를 하며 혁신은 꿈도 꾸지 못하는 회사 분위기를 만든다. 

사장과 말단 개발자가 격이 없이 자유롭게 토론하고 그 속에서 혁신이 튀어 나오는 외국 소프트웨어 회사를 어떻게 따라 할 수 있을까? 어려서부터 토론을 훈련 받은 그들을 어떻게 따라 할 수 있을까? 서열과 권위의식이 별로 없는 환경에서 평등하게 하는 토론을 어떻게 따라 할 수 있을까? 

뾰족한 수는 없고 권위의식을 버리고 서열문화를 버리고 평등한 토론을 훈련하는 수 밖에 없다고 생각한다. 이런 평등한 토론 문화를 위해서 모든 직원의 직급을 없애고 영어 이름을 부르는 회사가 있다. 사장이 스스로 나서서 권위의식을 없애고 평등한 토론문화를 만들어 가는 회사도 있다. 이런 회사의 토론 분위기는 사뭇 다르다. 반말하는 사람 없이 서로 존칭을 하며 직급 없이 이름을 부른다. 일단 외형적으로 평등한 분위기를 조성하며 내용적으로도 자유로운 토론이 이어지며 좋은 토론 문화를 만들어나가기 위해서 노력한다. 나쁜 토론 문화는 보이는대로 제거하기 위해서 애쓴다. 

이는 평등한 토론 문화가 중요하다는 회사의 경영자들의 생각과 의지에서 비롯된다. 소프트웨어 회사는 혁신 없이는 도태된다. 모든 직원들의 창의력을 밑바닥에서부터 끌어낼 때 혁신이 나올 수 있다. 토론 문화는 상명하복이 완전히 고착된 우리나라 큰 기업들이 외국의 소프트웨어 회사들을 이기기 어려운 결정적인 이유 중 하나다. 반짝 이길 수는 있어도 직원들이 불행하게 일하면 지속적으로 이기기는 어렵다. 직원들이 행복하게 일하면서도 혁신과 성장을 하려면 평등한 토론 문화가 꼭 필요하다. 

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

美 SW 힘은 평등한 호칭 문화에서 생겼다

필자는 지금까지 소프트웨어 조직에는 수평적이고 자율적인 문화가 필요하다고 했다. 하지만 수직적이고 상명하복 식 조직문화를 없애고 평등한 토론에서 오는 창의적이고 효율적인 개발문화를 만들고 싶어도 넘기 힘든 큰 장애물이 있다. 

바로 '직급'을 부르는 호칭이다. 

한국은 아주 옛날부터 이름 대신 직급을 부르는 것이 전통이다. 부장님, 과장님이라고 불러야지 이름을 부르는 행위는 아주 무례한 것이고 조직문화에서는 용납이 안 되는 행위다. 호칭은 오래 이어져 온 전통이며 쉽게 바꾸지 못하는 고착된 문화다. 

직급을 부르는 호칭은 조직에서 상하관계를 명확하게 하고 상명하복 문화에서 쉽게 벗어나지 못하게 하는 강력한 수단이다. 차장과 부장은 권위의 수준이 다르고 차장에서 부장으로 진급했는데 이를 모르고 차장이라고 부르면 기분 나빠하는 사람도 있고 부르는 사람도 민망해진다. 가끔은 오랜만에 만난 옛날 동료의 직급을 몰라서 뭐라고 불러야 할지 애매한 경우도 많다. 

이런 수직적인 조직문화에서는 '대리'와 '부장'이 어떻게 똑같은 관계에서 평등하게 토론을 할 수 있겠는가? 호칭은 사람에 대한 인식과 사고를 지배하고 알게 모르게 행동과 말하는 것을 통제한다. 

부장의 얘기가 틀렸어도 눈치를 보며 쉽게 지적하기 어렵다. 설령 자신의 생각이 맞는다고 확신해도 위계질서를 무시할 수 없고 괜히 얘기했다가 나중에 불이익을 당하지 않을까 걱정하여 자연스럽게 자기 검열을 하게 된다. 그러다 보니 좋은 아이디어가 있어도 괜히 얘기했다가 일만 많아지고 면박이나 받지 않을까 걱정해서 가만히 있게 된다. 그래서 '가만히 있으면 중간이라도 간다'라는 생각이 지배를 하게 된다. 

복잡도가 소프트웨어보다 낮은 산업들, 특히 전통적인 굴뚝산업에서는 상명하복과 위계질서가 더 효율적인 경우도 많다. 하지만 인류 역사상 가장 복잡한 지식산업이라는 소프트웨어 산업에서는 상명하복으로는 효율적인 개발을 하기 어렵다. 자유로운 사고와 창의력과 혁신이 없이는 살아남기 힘든 소프트웨어 산업에서는 무엇보다도 평등한 토론 문화가 필수적이다. 

전통적으로 직급보다 이름을 부르는 미국이 소프트웨어 강국이 되는데 이런 호칭 문화가 일조를 했다고 생각한다. 신입사원이 사장의 이름을 부를 수 있고 자유롭게 의견을 얘기할 수 있는 토론 문화는 어릴 때부터 훈련이 되어 있다. 물론 모든 회사가 다 그렇다는 것은 아니고 사회 전반적인 문화가 그렇다는 것이다. 

필자는 수평조직 문화를 정착하기 위해서 호칭 문화를 획기적으로 바꾼 몇몇 우리나라 회사를 알고 있다. 

A사는 모든 직원이 서로 '영어이름'을 부른다. 서로 존칭은 하지만 극존칭은 사용하지 않는다. 말단 사원이 최고 경영자인 사장에게 그냥 '빌(Bill)' 또는 '스티브(steve)' 이렇게 부른다. 

문서나 회의록을 작성할 때도 "Bill이 이렇게 말했다"라고 작성을 한다.

수직적인 조직 문화에서 문서에 사장님을 언급할 때 이름을 그냥 쓰기가 몹시 꺼려진다. '사장님'이라고 써야 할지, '홍길동 사장님'이라고 써야 할지 고민이 된다. 이렇게 주제에 집중하지 못하고 신경을 쓰는 것 자체가 호칭에 지배를 받고 영향을 받고 있다는 증거다. 많은 기업은 문서나 대화에서 최고 경영자의 호칭을 CM 등 직급의 약자나 이름의 이니셜을 쓰기도 한다. 여기에는 최고위층 이름은 직접 언급할 수 없다는 금기도 작용하기도 한다. 조선시대에는 왕의 이름에 들어간 한자는 민간에서는 절대로 쓸 수가 없다. 이만큼 우리는 옛날부터 호칭에 민감하다. 

직원들끼리 영어 이름을 부르는 A사는 조직문화가 사뭇 다르다. 호칭 자체가 모든 것을 평등하게 바꾸는 것은 아니지만 평등한 조직문화를 만드는데 일조한다. 

회의나 토론 시간에 위계질서는 없고 자유롭게 발언하며 면박을 주지 않는다. 사장이나 말단 개발자나 똑같은 위치에서 의견을 얘기한다. 제3자가 이 광경을 보고 있으면 누가 사원이고 과장, 부장인지 알 수가 없다. 각자 자신의 전문성과 경험에 기반 하에 자유롭게 의견을 얘기한다. 이런 환경에서 창의적이고 혁신적인 아이디어가 나온다. 

빠른 의사 결정도 장점이다. 회사가 직급에 의해서 돌아가는 것이 아니라 각자의 역할이 있을 뿐이다. 팀장이 있기는 하지만 모든 사람들이 다 평등하다. 자신이 맡은 일이 있을 뿐이다. 결재도 한 두 단계로 끝난다. 길어야 팀장, 사장, 이렇게 두 단계다. 결재판을 들고 돌아다니면서 결재를 받는 경우도 일부 있지만 많은 경우 구두나 이메일로 승인이 떨어진다. 사전에 시스템이나 이메일로 내용이 충분히 공유가 되어 있어서 최종 결정은 신속하다. 

이런 환경에서는 위에서 시키는 일만 하는 수동적인 직원은 매우 적고 능동적이고 자율적인 문화가 퍼져나간다. 나의 위에 줄줄이 상사들이 있어서 시키는 일을 잘하고 눈치를 봐야 하는 상황이 아니고 자신이 알아서 일해야 하는 분위기가 자리를 잡는다. 성과가 안 좋은 것은 자신의 책임이다. 

물론 호칭만 바꾼다고 이런 문화가 저절로 정착되는 것은 아니다. 경영진의 의지가 가장 중요하다. 호칭을 바꾸려는 목적이 무엇인가? 수평적인 문화를 만들기 위한 것이다. 영어이름을 사용하는 호칭 문화는 수평적인 문화를 만들기 위한 강력한 수단 중 하나다. 

하지만 호칭만 바꾸고 권위의식이 여전하다면 별 효과가 없을 것이다. 권위 의식을 타파하고 상명하복 전통을 없애고 자율적이고 수평적인 문화를 만들기 위해서 다각적으로 노력해야 한다. 호칭문화는 그 시작이 될 수 있다.

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

실리콘밸리 개발자 눈에 비친 한국 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에 기고한 칼럼입니다.

개발 프로세스 관료화의 함정

소프트웨어를 효율적으로 개발하는 비법 아닌 비법은 개발 프로세스와 개발 문화의 적절한 균형에 있다. 김치를 담그는 레시피처럼 확실한 비율을 정하기는 어렵다. 개발 프로세스는 양날의 칼이다. 적절히 사용하면 개발 효율은 올라가지만 조금만 잘못 써도 개발 생산성이 떨어질 뿐만 아니라 개발자 성장까지 저해하여 회사와 개발자 모두의 미래를 어둡게 만든다.

다른 산업 분야에서는 외국에서 몇백년동안 쌓아온 것을 우리는 몇십년만에 따라 잡은 분야가 꽤 있다. 하지만 소프트웨어는 기껏해야 60년 역사인데 따라잡기가 훨씬 어렵다. 개별 개발자들의 프로그래밍 실력은 결코 뒤진다고 볼 수는 없다. 하지만 전반적인 개발문화의 차이가 격차를 좁히지 못하는 원인 중 하나다. 

소프트웨어 분야에 대한 투자는 개발자 인원수 늘리기와 프로세스 강화에 많이 치우친 경향이 있다. 소프트웨어도 시그마6 등과 같은 기법을 따와서 프로세스를 강화하면 좋은 성과를 낼 수 있을 것으로 착각했기 때문이다.

이렇게 프로세스에 집중하면 '파킨슨의 법칙'처럼 프로세스 관료화의 함정에 빠지기 쉽다. 프로세스는 회사의 변화에 따라 끊임없이 효율적으로 개선이 되어야 하는데 관료화된 조직은 프로세스가 점점 복잡해지지 단순해지지는 않는다. 프로세스가 단순해지고 효율적으로 바뀌면 일이 없어지는 사람이 있기 때문에 점점 복잡하게 만들려는 경향이 있다. 

물론 모든 기업이 그런 것은 아니다. 이런 함정에 빠지지 않은 기업도 있고, 이 단계를 극복해 나가는 기업이 있다는 것을 알고 있다. 하지만 많은 기업들이 이미 프로세스 관료화의 함정에 빠져서 허우적대거나 관료화의 길로 달려가고 있다. 이를 경계하자는 것이다.

그럼 개발 프로세스가 빠지기 쉬운 함정에는 어떤 것이 있는지 알아보자. 

첫째, 현실성이 부족한 프로세스다. 

실제 개발 현장에서는 벌어지지 않는 교과서에나 나오는 것을 실제 개발에 적용하려는 것이다. 가장 광범위하게 벌어지고 있는 현상 중 하나다. 인터넷에서 돌아다니는 지식이나 책을 보고 따라 하거나 소프트웨어 공학을 전공했지만 실전 경험이 부족한 경우 자주 벌어진다. 개발 단계별로 너무 많은 문서를 요구하거나 승인을 필요로 하는 프로세스가 있다. 

원자력 발전소를 만들 때나 필요함직한 문서들을 일반 소프트웨어에서 요구하기도 한다. 이런 문서는 개발할 때도 도움이 안되고 개발 후 유지보수 때도 별로 쓸모가 없게 된다. 마켓요구사항과 기능, 모듈을 추적하기 위해서 추적 매트릭스를 의무적으로 요구하는 프로세스도 있다. 

교과서에서 본적이 있을지는 몰라도 대부분의 소프트웨어에서는 필요도 없고 오히려 방해만 되는 프로세스다. 이렇듯 현실성이 부족한 프로세스는 너무나 흔하다. 개발자들은 어쩔 수 없이 따르는 척은 하지만 대부분 피해가는 요령만 늘게 되고 개발 경험이 쌓이면서 자연스럽게 역량이 성장하는 것을 방해하게 된다. 

개발 프로세스는 성숙된 개발환경에서 수십년 실전 경험이 풍부한 CTO급 개발자가 이끌어야 현실성 있고 효율적으로 만들 수 있다. 

둘째, 너무 상세하고 획일화된 프로세스다. 

프로세스팀이 너무 일을 열심히 하려고 할 때 발생한다. 프로세스는 모든 개발절차를 상세히 정의하기 보다 문제가 될 수 있는 핵심적인 요소를 잘 집어내는 것이 중요하다. 법률에도 비슷한 현상이 있다. 할 수 있는 것을 정의해서 법에 정한 것만 할 수 있게 하거나 하면 안되는 것을 정의해서 그 외에는 모두 할 수 있게 하는 방법이 있다.

모든 절차를 너무 상세하게 정의하면 개발자의 창의성을 저해하고 비효율적으로 흐를 수 있다. 오타 하나를 수정한 경우에도 작성해야 할 문서가 몇 개나 되고 절차도 일주일 이상 걸린다는 하소연을 들은 적이 있다. 개발자에게 자유도가 없이 몇 가지 경우로 획일화된 프로세스에서는 효율적으로 개발을 하기가 어렵다. 

개발자를 믿지 못하기 때문에 개발자에게 자유도를 주지 않는 경우이다. 

최근에 한 기업의 프로세스팀 리더를 만난 적이 있는데 설계문서를 매우 상세하게 작성을 해야 하며 꼭 UML로 작성을 해야 한다고 했다. UML을 이용하지 않고 개발자가 제각각 작성하면 서로 의미가 통하지 않을 수 있다고 한다. 나는 그럴 필요가 없고 개발자가 가장 편하게 작성할 수 있는 방법이면 되고 꼭 UML을 쓸 필요도 없다고 했다. 

화이트보드나 종이에 끄적거리고 토론하다가 사진을 찍어서 문서에 첨부해도 된다고 했다. 물론 이 부분은 논란이 있을 수 있다. 스펙과 설계의 경계에 대한 생각이 다르고 설계를 상세하게 작성해야 개발자들이 코딩을 잘 할 수 있다고 획일적으로 생각하는 것도 문제다. 

설계란 상황에 따라서 필요한 만큼 자유롭게 적절히 하는 것이 중요하고 형식보다는 창의력이 더 필요하다. 
셋째, 잘못된 관행을 그대로 담은 프로세스다.

프로세스팀의 힘이 약한 경우에 발생한다. 개발 프로세스를 정의할 때는 현재의 문제점을 고치고 개발역량을 미래지향적으로 향상시킬 수 있는 방법을 녹여내야 한다. 하지만 현재의 관행적인 절차를 체계화하고 문서화해서 기존의 문제점을 그대로 유지한다면 그야말로 최악이다. 

절차화 되면서 기존에 개발자들이 자유도를 가지고 적절하게 판단하던 효율성도 사라졌고, 미래지향적이지도 않다. 기존의 문제가 점점 고착화 되어 갈 뿐이다. 

개발자들의 의견을 너무 존중해서 민주적인 다수결로 프로세스를 결정하는 것도 문제다. 변화를 싫어하는 것은 동서고금 똑같아서 대중의 의견을 따르면 프로세스는 대부분 실패한다. 

넷째, 벌칙만 잔뜩 담은 프로세스다.

프로세스는 잘못하면 벌을 주려는 형법과는 다른 것이다. 목적 자체가 다르다. 프로세스는 효율적인 개발을 하기 위한 최소한의 절차다. 그리고 프로세스를 따라서 꾸준히 개발을 하면 개발팀의 역량도 향상 되어야 한다. 따라서 적절한 독려와 벌칙이 있을 수는 있다. 하지만 벌칙만 잔뜩 존재한다면 벌칙을 피해 다니는데 집중하게 된다. 물론 치명적인 잘못에 대해서는 벌칙이 있을 수 있다. 치명적인 잘못에는 다음과 같은 것들이 있다. 

-소스코드를 빌드가안되는브로큰 트리(Broken tree)를 만든 경우 
-백업 담당자가 백업을 소홀히 한 경우 
-소스코드를 소스코드관리시스템에 등록하지 않은 경우 
-핵심 프로세스를 따르지 않아서 큰 장애를 만들어 낸 경우 

여기서 버그를 만든 경우는 벌을 받아야 할 만큼 큰 잘못은 아니다. 그런데 버그를 카운트해서 불이익을 주거나 프로세스의 모든 사소한 사항까지 벌칙과 연계를 하면 숨막혀서 개발하기가 쉽지 않다. 

다섯째, 점점 복잡해지는 프로세스다. 

회사는 계속 바뀌고 제품 및 개발팀도 계속 성장한다. 그러면서 프로세스도 계속 진화를 한다. 그런데 매번 프로세스가 점점 복잡해지는 회사들이 많다. 무슨 문제가 있을 때마다 원인을 분석하고 대책을 수립한다고 하면서 확인 절차를 더 추가하고 문서를 더 만들어 내는 것이다. 

이렇게 문제가 있을 때마다 대책을 수립한다고 하면 초 단기적인 대책밖에는 만들어 낼 수 없다. 예를 들어서 근본 원인이 '공유의 문화'가 부족해서라고 해도 수년 걸리는 '공유의 문화' 개선보다는 당장 눈에 보이는 형식적인 절차를 끼워 넣을 수 밖에 없다. 

냄비 안의 개구리는 점점 따뜻해져 오는 물을 느끼지 못하지만 나중에 밖에서 프로세스를 보게 되면 괴상망측하게 변화된 것을 알 수 있다. 프로세스는 역량과 문화 수준이 향상됨에 따라서 점차 간소하게 바뀌어야 한다. 기존에는 프로세스로 강제화하던 것이 몸에 베이게 되면 간단하게 바꿔야 더 효율적이다. 

여섯째, 관료화된 프로세스다.

관료화된 조직에서 흔히 벌어지는 일이다. 개발 문제를 해결하기 위해서 프로세스를 강조하다 보면 프로세스 자체가 목적이 되기도 한다. 효율적인 방법이 눈에 뻔히 보이는 경우에도 프로세스가 그러하니 따라야 한다고 하게 된다. 개발 생산성 향상이라는 목표는 저 멀리 떠나 보내고 각자 팀의 이익을 쫓다 보면 프로세스가 점점 관료화로 치닫게 된다. 

가끔은 없어도 되는 절차를 일부러 만들기도 한다. 개발자들은 이를 피해가는 요령만 늘게 된다. 

물론 열심히 노력하고 잘하는 프로세스팀이 더 많지만 그 중에는 개발 효율성보다는 스스로의 일거리를 늘리고 힘을 키우기 위해서 프로세스를 더 복잡하게 만들고 개발에 끼어드는 경우가 있다. 프로세스팀이 모든 개발 절차를 감시하고 산출물을 검토하고 승인에 끼어드는 경우 관료화게 빠지기 쉽다. 도와주는 역할을 넘어서 스스로 권력화가 되는 것이다. 

결론은 개발 프로세스는 현실적이며 자율적이어야 하고 개발 문화와 균형을 이뤄야 한다. 아직 자율에 맡기기에는 불안하다고 하면 프로세스를 너무 복잡하게 하지 말고 핵심적인 것부터 조금씩 적용하는 것이 좋다. 
개발자가 즐겁게 일할 수 있는 환경이 가장 생산성이 높은 환경이다. 개발 프로세스를 엄격하게 강화하여 소프트웨어 개발 문제를 해결 할 수 있다는 생각부터 잘못된 것이다. 적절한 개발 문화가 뒷받침되지 않는 프로세스는 오히려 짐이 될 뿐이다. 

눈에 보이는 프로세스에는 투자를 하기가 쉬워도 눈에 잘 안 보이는 개발문화는 어떻게 투자를 해야 할지 막막하다. 자칫 잘못하면 사무실 환경이나 슬로건만 흉내를 내는 꼴이 될 수도 있다. 

문화가 바뀌려면 생각이 먼저 바뀌어야 행동이 바뀐다. 하지만 생각은 그렇게 쉽게 바뀌지 않는다. 힘이 있는 선구자가 끊임없이 생각의 변화를 이끌어야 한다. 프로세스가 관료화에 빠지지 않으려면 CTO급의 특급 개발자가 실전 개발 기법을 프로세스에 적용하고 개발문화 향상을 꾸준히 이끌 수 있도록 해야 한다. 

미신과 같은 이론 전문가들의 말과 인터넷에 떠도는 소문에 현혹되지 말고 진짜 전문가인 개발 전문가들을 보호하고 힘을 실어줄 때가 변화의 시작 시점일 것이다.

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