소프트웨어 회사에서 경영자가 하면 안되는 것들

필자는 23년 경력의 개발자이며 이우소프트의 CEO다. 과거 8년 동안 소프트웨어 공학 컨설턴트로서 소프트웨어 개발에 관한 글을 써왔다. 우리나라의 열악한 소프트웨어 개발 환경의 핵심이 개발문화 때문이라고 생각해서 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례 소개하고 있다.

오늘은 소프트웨어 회사에서 경영자가 하면 안 되는 것들을 소개하려고 한다. 물론, 회사마다 기업문화가 달라서 사람에 따라서는 괴리감을 있을 수 있다. 문화란 원래 경험하지 않은 사람은 괴상하다고 생각할 수도 있고 현실성이 없다고 느낄 수도 있다. 하지만 우리 회사에서는 당연하게 생각되는 것들이고 이런 문화가 글로벌 소프트웨어 기업들과 경쟁하기 위해서 필요하고 생각하기 때문에 소개를 한다. 

첫째, 개발자들의 개발 기간 예측(Estimation)을 무시하기

많은 회사에서 벌어지고 있는 일이고 일방적으로 경영자의 잘못으로 치부하기도 힘들다.

사례는 워낙 많지만 개발자들이 1년 이하로는 도저히 개발할 수 없다고 주장하는 프로젝트를 경영자가 6개월안에 무조건 끝내라고 하는 경우는 매우 흔하다. 이유도 여러 가지다. 개발자의 주장을 믿지 않기도 하고, 프로젝트가 늦어질 것을 감안하여 필요 일정보다 무조건 당겨서 끝내라고 하기도 한다. 또한, 이렇게 개발자를 강하게 압박하지 않으면 개발자들이 야근도 안하고 열심히 일을 안 한다고 생각하는 경영자도 많다. 

당장은 이렇게 해서 몇몇 프로젝트가 성공할 수도 있고 개발 일정도 당겨지고 이익을 보기한다. 하지만, 이런 행위가 관행처럼 굳어지면 결국에는 개발자, 경영자 모두가 손해를 본다. 또한 회사의 개발 문화도 한참 후퇴한다. 경영자가 일정을 무조건 줄이면 개발자는 다음부터 어쩔 수 없이 예상보다 조금씩 늘려서 얘기를 하곤 한다.

개발자도 경영자가 납득할만한 근거를 가지고 적절한 개발 기간을 제시하지 못하는 문제도 벌어진다. 그래서 경영자는 개발자가 제시한 일정을 납득하지 못하고 무조건 일정을 줄이고 본다. 이 싸움은 누구도 승자가 될 수 없는 싸움이다. 개발자는 아키텍처가 망가지는 고통 속에서 야근을 거듭하고 경영자는 프로젝트의 예측 가능성이 낮아져서 비즈니스를 수시로 그르치게 된다.

먼저, 개발자는 잘 분석된 스펙을 바탕으로 납득할 수 있는 일정을 제시해야 한다. 그리고 경영자는 개발자가 예측한 일정을 믿어주는 신뢰관계가 필요하다. 그래야 개발자는 항상 최선을 다해서 정확한 일정을 산정하려고 노력한다. 개발자가 제시한 일정을 단축해야 하는 경우에는 합리적인 수단을 사용해야 한다. 야근도 하나의 방법이기는 하지만 습관적인 야근은 이익보다 손실이 큰 방법이다. 합리적인 수단이란 기능 축소, 핵심 기능에 집중, 단계별 개발, 전문 컨설턴트 투입, 일부 상용 모듈 구매 등 여러 가지가 있다. 

이런 개발자와 경영자 간의 신뢰 관계는 개발 방법론과 상관없이 필요하며 정착하는데 상당한 기간이 필요하다. 그리고 이렇게 개발하는 방법이 소프트웨어를 가장 빨리 개발하는 방법이라는 것을 깨달아야 한다.

둘째, 합의된 요구사항을 경영자의 취향대로 바꾸기

우리나라 회사들은 경영자가 무엇이든지 뒤집을 수 있는 막강한 권력을 가진 경우가 많다. 출시 임박한 제품의 모양을 경영자가 갑자기 바꾸거나, 취향대로 색깔을 바꾸기도 한다. 소프트웨어 분야에서도 흔히 벌어진다.

프로젝트에서 경영자의 역할은 프로젝트마다 다르다. 하지만 경영자가 프로젝트에서 절대 권력자는 아니다. 한 명의 Stakeholder일 뿐이다. 대부분의 프로젝트에서 경영자의 역할은 비전과 전략을 담당한다. 빌게이츠는 초창기 프로젝트의 기술적인 내용까지 깊숙이 간섭을 했는데 이는 경영자로서가 아니고 Chief Architect로서의 역할을 한 것이다.

프로젝트에서 경영자는 경영자 관점에서 비전과 전략 요구사항을 전달해야 한다. 그것도 초기에 제시해야 한다. 전략이 바뀌면 프로젝트는 엄청나게 바뀌는 것이므로 가능하면 초기의 전략이 유지되는 것이 좋다. 전략이 바뀌더라도 합리적인 변경을 해야 한다.

경영자가 프로젝트 막바지에 뒤늦게 관여를 해서 감 놔라 대추 놔라 하는 것은 금기사항이다. 이런 일이 벌어지면 아키텍처는 완전히 엉망이 되고 개발자들의 사기는 땅에 떨어지면 신뢰관계는 금이 간다. 우리 회사에서는 스펙이 Close 된 후에는 경영자가 요구사항을 바꾸려고 해도 Change Control Process를 통과해야 한다. Change Control Board에서 변경이 거부되면 아무리 경영자가 요구한 내용이라고 변경이 불가능하다. 

이래야 경영자도 프로젝트에서 자신의 역할을 제대로 수행하기 위해서 최선을 다한다. 뒤늦게 아무 때나 간섭할 수 있다는 생각은 하지 않게 된다.

셋째, 개발자에게 아무 때나 가서 말을 시키거나 지시하기

우리 회사에서는 경영자뿐만 아니라 누구도 개발자에게 아무 때나 말을 걸고 개발을 방해하지 않는다. 개발자가 개발에 집중을 하고 있는 경우에 중간에 방해를 하면 엄청난 손해가 발생한다. 피플웨어에서는 30분 정도의 손실이 발생한다고 한다. 이런 방해가 하루에 3,4번 벌어지면 하루를 망친다.

개발자와 면담을 할 것이 있으면 몇 시간 전이나 하루 전에 미리 시간을 Arrange해야 한다. 급하게 할 얘기가 있으면 개발자가 집중을 하고 있는지 조심스럽게 살핀다.

그래서 우리 회사에는 메신저도 금지되어 있고 근무 중에는 카카오톡도 무음 설정을 해야 한다. 개발자가 집중해서 일을 하고 있는데 메신저가 부르거나 "까똑" 거리면 집중해서 일할 수가 없다. 개발자에게 전화를 거는 일도 거의 없다. 대신에 근무 시간에 최대한 집중을 하고 야근은 되도록 하지 않는다. 

넷째, 수시로 보고서를 요구하기

공유 문화가 잘 정착되어 있는 회사에서는 진행되는 거의 모든 일이 온라인 시스템에 잘 기록되어 있다. 그래서 별도의 보고서가 없어도 경영자는 거의 모든 내용을 실시간으로 모니터링이 가능하다. 그래서 특수한 경우가 아니면 시스템에 있는 정보를 다시 정리해서 보고하라고 하지 않아야 한다. 보고서는 경영자의 시간을 약간 절약해 주지만 직원들은 수십, 수백 배의 시간을 소모해야 한다. 일보다 보고서 작성에 더 많은 시간을 쏟기도 한다. 또한 보고서만으로 업무를 파악하면 가공과정을 거치면서 내용이 왜곡되곤 한다. 시간이 허용하는 한 최대한 많은 정보를 직접 보는 것이 좋다. 보고서는 꼭 필요한 경우에만 작성해야 한다. 이것이 가능 하려면 공유 문화가 완전히 정착되어 있어야 한다. 

지금까지 네 가지 경영자가 하면 안 되는 일을 소개했다. 그럼 경영자는 별로 할 일이 없는가? 경영자는 회사의 비전, 전략을 정하고 목표를 설정해야 한다. 인재를 채용하고 직원을 코칭, 육성해야 하며 회사의 규칙을 만들고 문화를 만들어가야 한다. 이외에도 경영자가 해야 할 일은 수없이 많다. 

필자는 CEO일 뿐만 아니라 아키텍트의 역할도 일부 수행하며 또한 소프트웨어 국제화 전문가이다. 그래서 소프트웨어 공학, 아키텍처, 국제화 관련 이슈에도 전문가로서 직접 관여를 한다. 하지만 그 외의 것은 위에서 얘기한 것처럼 Stakeholder로서 의논에 참여를 하고 의견을 제시하지만 결정에 과도한 압력을 가하거나 합의된 결정을 뒤집지는 않는다. 합의를 바꾸려면 정해진 절차를 따른다. 

글로벌 수준의 개발 문화 속에서 경영자와 개발자가 각자의 전문 역할을 충실히 수행할 때 글로벌 소프트웨어 회사들과 비로소 경쟁을 시작할 수 있을 것이다.

개발 문화는 후진적인데 개발자 하나하나가 선진적이고 뛰어나다고 해서 소프트웨어가 경쟁력을 갖출 수 없다. 개발 문화라는 것이 반바지를 입는다고 공짜 점심을 준다고 좋은 공학툴이나 방법론을 도입한다고 해서 제대로 정착되는 것은 아니다. 모든 구성원의 마음과 습관을 바꾸는 것이 핵심인데 매우 어려운 과정이며 경영자부터 바뀌지 않으면 안 된다. 

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

소프트웨어 번역 프로세스의 절대 원칙 (19)

소프트웨어를 국제화하려면 수많은 요소를 국제화해야 하지만 그 중에서 절대 빠지지 않는 부분이 번역이다. 또한 가장 중요하면서 어렵다. 필자가 얘기하는 주제는 번역 그 자체를 제외한 번역을 위한 모든 활동을 말한다. 소스코드에서는 어떠한 함수를 사용하고, 메시지는 어떻게 추출해서 어디에 저장하고 번역가에게는 어떻게 보내고, 번역된 메시지는 소프트웨어에서 어떻게 읽어 들여서 출력할 것인지에 대한 아키텍처와 프로세스 전반을 말하는 것이다. 

소프트웨어를 어느 정도 개발해 본 경험이 있는 개발자라면 소프트웨어를 번역해서 해외에 출시해 본 경험을 누구나 가지고 있다. 또한 별 문제를 겪지 않아서 소프트웨어 번역이 별거 아니라고 생각하는 개발자도 많다.

그럼에도 불구하고 필자는 왜 자꾸 어렵다고 얘기를 하는 것일까? 과장을 하는 것은 아닐까? 아니다. 소프트웨어 번역에서 별 문제를 겪어보지 못한 개발자들은 아직 심각한 상황을 경험해보지 못해서 어려움을 모르는 것일 가능성이 높다다. 아래 5가지 상황 중에서 2가지 정도만 닥쳐도 소프트웨어 번역은 심각한 문제가 된다.

10개 이상의 언어(로케일)을 지원

100명 이상의 개발자가 공동 개발

10000개 이상의 메시지를 번역

100,000명 이상의 고객이 사용한다.

적어도 한 달에 2번 이상 업데이트

한두 명의 개발자가 몇 백 개의 메시지를 번역해야 하는 상황이라면 어떤 메시징 아키텍처를 사용하던지 완전 수동화된 프로세스를 사용해도 거의 문제가 안 된다. 그래서 거의 모든 개발자들이 큰 고민 없이 여러 개발툴들이 제공하는 메시징 함수를 그냥 사용하고 수동에 의존한 프로세스에 익숙해져 있다.

그렇게 성장을 하다가 큰 제품을 만들 기회가 생기고 큰 조직에서 수십 명의 개발자와 같이 개발을 하게 되면 번역은 10배, 100배 비용이 들게 된다. 

예를 들어 전세계 백만 명이 사용하는 제품을 20개 언어(로케일)로 번역을 해야 하는 거대 프로젝트에 참여를 했다고 생각하자. 소프트웨어에 추가할 메시지들을 RC에 추가한다던지 별도의 파일에 추가하는 것은 쉽지가 없다. 메시지도 수만 개에 이를 뿐만 아니라 수십 명의 개발자들이 동시에 RC파일을 고쳐댄다. 똑 같은 메시지가 서로 다른 심볼로 중복 저장되기도 하고 반대로 의미가 다른 동일한 메시지를 사용하기도 한다. 더 이상 사용하지 않는 메시지를 삭제 했더니 다른 개발자는 사용하고 있는 경우도 있다. 그래서 메시지를 삭제 않다 보니 사용하지 않는 메시지가 넘치게 된다.

번역가에게 번역을 의뢰할 때도 처음에는 문제가 안되는데 두 번째 버전부터는 바뀐 메시지만 의뢰를 해야 한다. 번역된 결과물을 첫 번째 번역과 합치는 것도 문제다. 이렇게 복잡한 수동 프로세스에 의존하다 보니 누락된 메시지가 생긴다. 이를 개선하고자 자동화툴을 만들어보지만 깔끔하게 해결하는 것이 쉽지는 않다.

이런 거대 프로젝트에 참여를 해서 소프트웨어 국제화의 어려움을 실제로 겪어본 개발자는 그렇게 많지 않다. 하지만 모든 개발자는 언제든지 이런 상황을 겪게 될 것이고 지금의 국제화 지식만 가지고는 남들이 겪은 국제화 실패를 고스란히 다시 겪게 될 것이다.

그럼 소프트웨어 번역은 어떻게 해야 할까? 앞으로 여러 차례에 걸쳐서 설명을 하게 될 것이고 오늘은 대원칙 2가지를 알아보자.

첫째, 메시지의 키는 영어 자체를 사용해야 한다.

둘째, 번역 자체를 제외한 모든 프로세스는 완전 자동화 되어야 한다.

위 두 원칙에는 많은 의미를 포함하고 있고 적용하기 쉽지도 않다. 또한 기존에 수많은 개발자들이 소프트웨어 번역을 위해서 사용하고 있는 방법의 대부분의 뒤 두가지 원칙에 위배되고 있다.

다음 시간에는 왜 메시지의 키가 영어가 되어야 하는지 설명을 시작으로 소프트웨어 번역에 대해서 좀더 깊이 들어가보자.

SW개발, 맥가이버식 전문가가 위험한 이유(개발문화 시리즈8)

이번 개발문화 이야기는 '전문가문화'다. 

어떤 개발자가 국내 유수의 소프트웨어 기업에 취업하려고 한다고 가정 해보자. 개발자가 수백명에 달하는 이 회사에 지원을 하면서 본인을 다음과 같이 소개한다고 보자. 

“저는 빌드 전문가입니다. 빌드 기술 연구와 실무 경험이 5년이나 됩니다.” 

그럼 이 개발자는 취업에 성공할 수 있을까? 모든 회사가 상황은 아니지만 이 개발자가 주장하는 “빌드 전문가”라는 것에 대해서 제대로 이해하고 그 가치를 높게 평가할 회사가 그렇게 많지는 않을 것이다. 오히려 이렇게 생각하는 개발자도 있을 수도 있다. 

“빌드 전문가? 그게 그렇게 어려운 건가? 나는 비주얼스튜디오나 이클립스에서 버튼하나 누르면 그냥 빌드가 다 되는데 전문가가 필요한가? 그냥 프로젝트에 투입할 수 있는 프로그래머나 뽑아주면 좋겠네” 

그럼 소프트웨어가 아닌 다른 분야는 어떨까? 

여기 집을 만들고 있다. 그런데 어떤 사람이 “저는 설계도 할 줄 알고 목수, 미장에 벽돌도 잘 쌓아요. 제게 맡겨주면 제가 다할 수 있습니다”고 얘기한다고 하자. 

어떤 생각이 드는가? “정글의 법칙”에서 집을 잘 지을 수는 있어도 내가 사는 집을 맡기기에는 불안하다. 하나 하나가 얼마나 전문성이 있고 어려운 일인지 일반인도 잘 알기 때문이다. 설령 다 할 줄 아는 사람이 있어도 설계를 잘하는 사람에게 벽돌도 쌓으라고 하면 비용도 더 많이 들고 비효율적이라는 것은 쉽게 이해한다. 

여기 운동선수를 뽑으려고 한다.

한 지원자가 “저는 농구, 축구, 야구 모두 잘합니다”고 주장한다. 프로선수를 뽑는데 이 선수를 채용하겠는가? 초등학교에는 이런 천재가 존재한다. 하지만 프로세계에서는 어림도 없다. '농구의 신' 마이클 조던도 야구선수로는 별볼일 없다는 것을 잘 알 것이다.

좀더 범위를 좁혀서 프로 축구선수를 뽑는다고 하자. 지원자가 공격, 수비, 골키퍼를 모두 잘한다고 주장하거나 프로 야구선수가 투수, 포수, 1루수, 유격수, 외야수, 지명타자까지 다할 수 있다고 하면 최고라고 생각하지는 않을 것이다.

그런데 소프트웨어 현장에서는 모든 것을 다 잘하는 만능선수를 선호하고 한 분야의 전문가에 대해서는 이해도 낮고 인기도 없다. 

소프트웨어는 앞에서 언급한 다른 분야에 비해서 덜 복잡하고 쉬운 분야가 아니다. 인류가 만든 가장 복잡한 지식산업이라고 하는 것이 소프트웨어다. 영화를 만들어도 카메라, 조명, 작가 등 전문가로 나뉘어져 있지만 소프트웨어는 이에 못지 않은 전문분야가 있다. 

다시 빌드로 돌아가보자. 빌드는 생각보다 전문성이 필요한 분야다. 빌드 전문가가 개발자가 아닌 것은 아니다. 보통 개발자로 성장하다가 빌드 분야에서 더욱 연구를 많이 하고 실무를 통해서 전문가가 된 개발자이다. 

작은 규모의 회사에서는 개발자가 짬짬히 해볼 수 있는 일이지만 규모가 커질수록 일은 점점 기하급수로 늘어가며 비용도 많이 들어가고 사고의 위험도 커진다. 

큰 회사에는 빌드팀이 별도로 있을 뿐만 아니라 여러 빌드 전문가들이 빌드 자동화와 효율을 높이기 위해서 노력한다. 빌드가 자동화되면 개발팀이 얻는 혜택은 대단히 크다. 빌드 전문가가 없다면 개발팀은 이런 혜택을 누릴 수 없고 비용은 더 많이 들어간다.

소프트웨어에서 이렇게 전문성이 필요한 분야가 매우 많다. 대부분 잘 알고 있는 QA분야를 비롯해서 테크니컬 라이팅, DB관리자, 데이터분석가, 테크니컬 마케팅, 국제화 전문가, UX전문가, 번역가, 아키텍트 등 다양하며 도메인 및 특정 기술 분야마다 매우 다양한 전문가가 있다. 회사마다 필요한 전문분야도 다르다. 

물론 뛰어난 소프트웨어 개발자는 여러 분야에 대해서 두루 잘 알지만 하나하나의 전문가가 되기는 어렵다. 그 중에서 한 두가지 분야의 전문가는 될 수가 있다. 

그럼 왜 이렇게 전문가에 대한 인식이 낮고 전문가가 제대로 대접을 받지 못할까? 

주된 이유는 우리나라에서는 프로젝트 규모가 크나 작으나 가내수공업식으로 개발을 하는 곳이 많기 때문이다. 물론 잘하고 있는 회사도 많으므로 모든 회사가 그렇다는 것은 아니다. 그런데 의외로 개발자는 수천명인데 속을 보면 수많은 가내수공업팀이 있는 경우도 있다.

장인정신하면 도자기가 떠오르기도 하지만 수백년전 우리나라 전통도자기는 전문가를 키우지 않아서 산업화에 실패했다. 한명의 도공이 도자기 생산 프로세스 모든 것을 담당했다. 예술성은 뛰었났을지언정 효율적인 생산은 하지 못했다. 

하지만 임진왜란때 수백명의 도공을 납치해간 일본은 도자기 생산과정을 수십가지로 나눠서 각각의 전문가를 키워서 산업화에 성공했다. 도자기 성형만 하는 사람, 유약만 만드는 사람, 색을 내는 염료만 연구하고 만드는 사람 등 수십가지의 전문가가 있다. 

현대의 도자기 산업과 별반 다를 것이 없다.

이렇게 전문가를 키우지 않는 문화는 현대까지 이어진 것일까? 회사가 작을 때는 한 개발자가 많은 일을 해야 하므로 만능 개발자를 선호하고 그런 개발자가 회사를 키우는데 원동력이 됐다. 

그런데 회사 규모가 엄청나게 커졌는데도 여전히 그런 만능 개발자만 선호하고 개발자가 똑같이 개발 과정의 모든 일을 해야 하는 경우가 많다. 

물론 개발자는 여러 분야의 일을 다 할 수는 있지만 전문가보다 잘할 수는 없다. 개발자는 자신이 전문가인 분야가 따로 있다. 대충 할 줄 아는 사람과 전문가는 하늘과 땅 차이다. 개발하는 제품의 품질에서도 차이가 발생한다. 

이런 일이 발생하는 이유는 소프트웨어 전 개발과정의 전문성을 제대로 이해하는 사람이 회사에 없기 때문이다. 그래서 전문가라고 하더라도 막상 취업을 해서는 자신의 전문성과는 전혀 관계가 없는 일을 하게 될 가능성이 매우 높다. 

주변에서 이런 경우는 매우 많이 본다. 이미지 프로세싱을 10년 가까이 해서 한국으로 채용되어 온 인도 개발자를 만난 적이 있다. 한국회사는 자신의 전문분야의 일을 할 수 있게 해주겠다고 약속을 했지만 현재 일반 UI개발을 몇 년째 하고 있다고 한다. 이번 계약이 끝나면 바로 인도로 돌아가고 싶다고 한다. 

만능개발자만 100명있는 개발조직보다는 개발자는 80명만 있고 20명은 각 분야의 전문가로 구성한 조직이 훨씬 개발 효율이 높고 제품의 품질도 올라갈 것이다. 

회사의 규모에 맞게 적절한 전문가를 채용하고 키워야 한다. 작은 규모에서 시작해서 성장하는 회사라면 회사가 커가는 적절한 시점에 전문분야로 분리해야 한다. 

우리가 흔히 알고 있는 전문분야도 있고 소프트웨어 전문가가 아니면 모르는 전문분야도 있다. 필요한 전문분야도 회사마다 다를 수도 있다. 영업만 이해하는 경영자가 개발팀을 구성하면 만능개발자가 바글바글한 조직이 될 가능성이 높다. 

조직을 전문화하고 효율적으로 만들려면 이를 이해하고 이끌 수 있는 CTO급의 개발자가 꼭 있어야 한다. 

여러 전문가가 효율적으로 협업하려면 프로세스도 중요하고 무엇보다 성숙한 개발문화가 필요하다. 성숙한 개발문화를 이 글에서 다 설명할 수는 없다.

현재 필자가 개발문화에 대해서 컬럼을 두달 넘게 쓰고 있지만 화두만 던지는 것이지 배울 수는 없다. 화두를 가지고 깨닫고 적용하여 경험을 통해서 전진해야 한다. 

CTO급 개발자가 필요하다고 했지만 가내수공업식 개발환경에서 성장한 개발자는 아무리 오래 개발을 했고 뛰어나다고 하더라도 소프트웨어 전문성에 대해서 다 알기는 어렵다. 성숙한 개발문화와 전문화된 조직에서 다양한 경험을 한 개발자가 도움이 될 것이다. 

당장은 개발자가 한 분야의 전문가가 되었다고 하더라도 회사에 어필하기 쉽지는 않을 수 있다. 소프트웨어 문화가 점점 성숙되고 전문가에 대한 이해도가 증가할수록 전문가에 대한 대우는 좋아질 것이고 맥가이버식 만능개발자보다 더 인기가 많아지는 때가 올 것으로 생각한다.

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