진짜 비대면 업무 방식 vs 가짜 비대면 업무 방식

 최근 코로나 19 때문에 비대면 업무 방식으로 전환이 강하게 요구되고 있다. 그러면서 비대면 업무 방식을 많이 추진하고 있는데, 가짜 비대면 업무를 하고 있는 회사도 많다.

비대면 업무 방식은 생산성이 높기 때문에 코로나 19가 아니더라도 도입이 권장된다. 그러면 진짜 비대면 방식으로 일하고 있는지, 가짜 비대면 방식으로 일하고 있는지 9가지 지표로 알아보자. 

툴, 시스템

재택근무를 도와주는 솔루션만 도입했다고 진짜 비대면 업무를 하는 것이 아니다. 

가짜 비대면 업무를 하는 회사는 몇 가지 특징이 있다. 완전한 비대면 업무 방식으로 일하기 위해서 필요한 시스템과 툴을 충분히 도입하지 않아서 여기 저기 구멍이 있는 경우다. 그래서 수시로 메신저나 이메일로 업무를 물어봐 가면서 처리하고 시스템을 따라 업무가 유기적으로 진행되지 않는다. 

또, 부서마다 사용하는 툴이 다른 경우도 있다. 진짜 비대면 업무를 하기 위해서 가장 중요한 시스템이 이슈 관리 시스템인데, 이것을 부서마다 다른 것을 쓰거나 일부 부서만 사용하는 경우다. 그러면 업무 협조 시 상황에 따라서 써야 하는 시스템이 달라서 매우 번거롭고 업무가 물 흐르듯 흐르지 않는다.

하지만 진짜 비대면 업무를 하는 회사는 필요한 시스템과 툴이 촘촘히 잘 구축되어 있고, 서로 연동이 잘 되어 있고, 모든 직원이 동일한 시스템을 쓰며, 내재화가 잘 되어 있다. 그래서 업무가 매끄럽게 흘러가고 한 두개의 대시보드에서 자신의 업무가 다 모니터링 되고, 관리자는 부서의 업무를 한눈에 파악할 수 있도록 되어 있다.

대부분 들어본 시스템과 툴이지만 전사적으로 제대로 구축하여 잘 쓰는 것은 매우 어렵다.

문서 관리

비대면 업무 방식을 주장하면서 문서를 개별 PC에서 작성해서 이메일이나 메신저로 서로 주고받으면서 공유하고, 관리를 하고 있다면 가짜 비대면 업무를 하고 있을 가능성이 높다.

또는 문서 공유 시스템을 쓰기는 하는데, 부서별로 서로 다른 시스템을 사용해서 타부서와 문서를 공유할 때는 이메일이나 메신저 등으로 파일을 전달하는 경우도 있다.

진짜 비대면 업무를 하려면 전사의 모든 문서를 하나의 문서 관리시스템에서 체계적으로 관리하고 있어야 한다. 물론 부서별 업무별로 권한 관리를 잘하여 보안 상으로도 문제가 없어야 한다.

문서의 작성, 협업, 리뷰, 관리, 공유 등 모든 작업이 하나의 시스템으로 관리가 되어야 효율적인 비대면 업무를 할 수 있다. 

문서 작성 역량

비대면 업무를 제대로 하기 위해서는 문서 작성 역량도 매우 중요하다.

문서를 많이 작성해야 한다는 의미는 아니다. 대면 업무 방식에서는 문서의 내용이 부족하면 수시로 옆에서 물어가며 일할 수 있지만 비대면 방식에서는 그렇게 하기 곤란하다.

기획 문서, 스펙 문서, 설계 문서 등 여러 종류의 문서들이 문서만 가지고 충분히 내용을 파악할 수 있어야 한다. 100%는 불가능하지만, 80~90% 문서로 충분히 내용을 전달할 수 있는 역량을 가지고 있어야 한다. 물론 이런 문서도 문서 관리시스템에서 협업과 리뷰를 통해서 만들어지므로 잘 작성될 가능성도 높아진다.

가짜 비대면 업무를 하는 회사는 문서를 가지고 일하기 어려워 일할 때 커뮤니케이션이 너무 많이 필요하다. 그래서 옆에 앉아서 같이 일하기를 원한다. 예를 들어 소프트웨어 회사에서 외주를 줄 때 스펙 문서를 기반으로 외주를 주지 못한다. 대략의 기획 문서를 기반으로 외주를 준 후에 요구대로 소프트웨어가 개발이 잘 안되니 옆에 끼고 설명을 해주거나 나중에 프로젝트 일정이나 품질에 문제가 생기는 것이 다반사다.

진짜 비대면 업무를 하기 위해서는 직원들이 모두 말보다는 문서 위주로 일하기 때문에 문서를 제대로 작성할 수 있는 역량이 필요하다. 그래서 채용 시 글을 잘 쓰는 사람을 뽑기도 하고, 직원들에게 글을 잘 쓰고 문서를 잘 작성하도록 교육할 필요가 있다.

물론, 비대면 업무를 계속 하면서 문서 작성을 계속 하고 리뷰를 거쳐 피드백을 많이 받게 되면 누구나 문서 작성 역량이 조금씩은 향상된다.

보고

진짜 비대면 업무를 하는 회사는 별도의 보고가 많이 줄어든다. 또한 보고를 위한 보고는 보기 어렵다.

별도의 보고가 따로 필요하지 않은 이유는 촘촘하게 커버되는 시스템에서 업무의 진행 상황을 훨씬 더 자세히 파악할 수 있기 때문이다.

직원들도 별도의 시간을 들여서 보고서를 작성하지 않고 본연의 업무에 더 많은 시간을 쏟을 수 있다. 

하지만, 가짜 비대면 업무를 하는 회사는 업무는 업무대로 다하고, 일일보고, 주간보고 등 여러 형태로 보고서를 작성해서 보고를 해야 한다. 보고 방식은 온라인이라 할지라도 낭비요소가 아닐 수 없다. 

관리자는 또 상위 관리자에게 보고를 하기 위해서 직원들의 보고를 취합하여 또 보고를 한다.

보고를 줄이는 것은 진짜 비대면 업무 방식의 증거이자 혜택이다.

화상 회의 빈도

가짜 비대면 업무를 하는 회사는 형식만 비대면이지, 수시로 화상 회의를 실시하여 대면 업무 방식과 별 차이 없이 일한다.

화상 회의는 실제 만나서 얘기하는 것보다는 전달성이 떨어지지만 이동하지 않고 커뮤니케이션을 할 수 있는 장점이 있는 것이다.

하지만 화상 회의를 너무 자주 한다면 차라리 모여서 일하는 것이 더 효율적이다.

회상 회의를 해야 하는 안건이 대부분 이슈 관리 시스템이나 여러 시스템에 온라인으로 등록되고 프로세스를 따라서 처리되며 화상 회의는 꼭 필요할 때 최소화해서 해야 한다. 그래야 진짜 비대면 업무 방식으로 일한다고 할 수 있다.

회상 회의도 비싼 수단이다. 하루의 10~20% 넘는 시간을 화상 회의에 사용하고 있다면 일단 의심을 해보자.

회의 결과 관리

가짜 비대면 업무를 하는 회사는 회의도 자주 하지만 회의 기록이 없거나 회의 결과 해야 할 업무의 추적이 잘 안된다.

그러고는 한참 있다가 “지난 번에 내가 시킨 일 어떻게 되고 있지?”하고 묻는다. 전형적인 대면 업무 방식과 다를 바가 없다.

회의를 자주하는 것과도 관련이 있다. 회의를 계획하에 하지 않고 수시로 소집하기 때문에 회의록도 제대로 남기지 않고 후속 관리도 잘 안된다.

진짜 비대면 업무를 하는 회사에서는 회의 빈도도 적을 뿐만 아니라, 필요한 회의는 미리 계획이 되어 있고 회의 결과가 제대로 정리, 공유되어 있다. 또한 회의 결과로 인해서 해야 할 일은 회사의 온라인 시스템에 등록되어 실시간으로 추적이 된다. 

회의록만 보아도 후속 업무의 처리 현황을 실시간으로 볼 수 있도록 시스템이 구축되어 있기도 하다.

예를 들어 소프트웨어 회사의 경우 유지보수를 위해서 소스코드를 볼 때 특정 소스코드의 한 줄만 보아도 해당 줄을 누가 언제 작성해서 관련된 요청은 언제 누가 했으며, 이와 관련된 회의는 언제 누가 진행했고, 결론은 어떻게 나왔는지 줄줄이 모두 몇번의 클릭으로 추적이 된다. 그래서 누가 와서 유지보수를 해도 소스코드의 역사를 훤히 볼 수가 있다.

메신저 사용

가짜 비대면 업무를 하는 회사는 메신저를 끼고 업무를 한다. 회상 회의까지는 아니지만, 수시로 여러 사람에게 메시지를 날리고 이거 저거를 물어본다. 회상 회의보다는 작지만 비용이 많이 들어가는 일이다. 답변을 하기 위해서는 하던 일을 중단해야 한다. 만약에 집중 업무를 하고 있던 경우라면 다시 집중하는데 필요한 시간까지 최소 30분은 그냥 날아간다. 이런 일이 한 두 건이면 모르겠지만, 메신저를 통해서 메시지가 여기저기서 수시로 쏟아지면, 정작 집중해서 본연의 업무를 할 시간이 부족하다.

메신저의 문제점 중 하나가 기록이 체계적으로 남지 않아서 회사의 정보 자산으로 축적되지 않는 다는 것이다. 

그래서 메신저는 정보 자산과 관련 업무를 위해서 가벼운 용도로만 최소화해서 사용해야 한다.

편리하다고 수시로 메시지를 날리는 것은 대면 업무 방식과 크게 다를 바가 없다. 

업무 만족도

가짜 비대면 업무를 하는 회사는 현재 회사에서 진행하는 비대면 업무 방식에 불만이 많다. 아무래도 과거 대면 방식보다 불편하고 업무 효율성이 떨어지기 때문이다. 원인은 여러가지가 있을 수 있다. 시스템이 충분히 구축되어 있지 않은 채로 강제로 몰아붙일 수도 있고, 역량은 안되는데 과도하게 시스템을 도입한 경우도 있다. 

직원들이 충분히 시스템에 적응하지 못한 경우도 있다.

진짜 비대면 업무를 하려면 추가로 시스템이 필요한지, 직원들의 문서 작성 역량 향상이 필요한지, 시스템 사용 교육이 더 필요한지 회사에 따라서 다를 것이다.

대면 업무 방식으로 오랫동안 일하던 회사가 하루 아침에 완전 비대면 방식으로 전환하기는 어렵다. 인식의 전화, 시스템 사용 적응, 문서 작성 역량 등 필요한 것이 한두개가 아니고 수년 걸리는 일도 있다. 전문가의 도움을 받아서 하나씩 하나씩 꾸준히 추진하는 수밖에 없다.

재택근무 가능 여부

가짜 비대면 업무를 하는 회사는 100% 재택 근무를 하지 못한다. 최근 뉴스에 100% 재택 근무를 하고 있는 미국의 많은 회사를 접한다. 1200명 전원이 회사 사무실 하나 없이 100% 재택 근무를 하는 깃랩도 있고, 구글, 페이스북도 100% 재택근무를 하는 직원이 꽤 많다.

하지만 가짜 비대면 업무를 하는 회사는 일주일에 1~3일 정도 재택근무를 하고 나머지는 회사에 나와서 일해야 한다. 또는 재택근무가 가능한 특수한 직군만 100% 재택 근무가 가능하다. 최근 코로나 때문에 이런 식으로 일부 재택근무를 하는 회사가 있다.

물론 재택근무가 100% 우월한 것은 아니다. 대면 업무 방식은 얼굴 보고 일하면서 팀워크가 증가하는 것도 있고, 생활 리듬에 안정을 주는 것도 있다. 하지만 여기서 얘기하는 것은 필요할 때 재택근무를 할 수 있냐는 것이다.

100% 재택근무가 가능해야 진짜 비대면 업무를 하고 있다고 볼 수 있다. 그런 역량을 가지고 모여서 일하는 것은 회사의 선택이다.

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

[Software Spec Series 8] 어떻게 소프트웨어를 빠르게 개발하는가?

소프트웨어는 빠르게 개발하는 것이 매우 중요하다. 소프트웨어 개발 기간이 오래 걸린다면 적절한 시장 진입 시기를 놓칠 수 있다. 소프트웨어 시장 변화는 매우 빨라서 너무 오래 개발을 하면 그동안 시장의 상황이 바뀐다. 경쟁자들은 새로운 제품을 출시하여 우리 회사에서 지금 개발하고 있는 제품이 뒤쳐지곤 한다. 또한 오랜 프로젝트는 개발자와 프로젝트 참여 인원들을 지치게 만든다. 이런 현상이 프로젝트를 더욱 더디게 한다. 프로젝트가 기간이 길어지면 그동안 새로운 요구사항이 추가될 가능성이 높다. 기획자는 변화하는 시장의 상황을 무시할 수가 없기 때문이다. 그래서 프로젝트는 더욱 늘어지고 품질은 떨어진다.

최근의 대부분의 개발 방법론들은 소프트웨어를 빠르게 개발하는 것을 중요시하고 있으며 회사에서도 소프트웨어를 빠르게 개발하기 위한 많은 노력을 들이고 있다. 그럼 어떻게 해야 소프트웨어를 빠르게 개발할 수 있을까? 소프트웨어를 빠르게 개발하기 위해서 고려해야 할 것은 매우 많지만, 여기서는 스펙 관점으로 살펴보려고 한다.

(느린 순차적 개발)

빌딩을 쌓을 때는 1층을 쌓고 2층을 쌓아야 한다. 1층을 쌓기 전에 2층을 쌓는 것은 불가능하다. 조립식 빌딩이라면 얘기가 다르지만 대부분의 빌딩은 순차적으로 쌓아 나간다. 소프트웨어도 이런 방식으로 순차적으로 개발을 해야 한다면 매우 오랜 시간이 걸릴 것이다. 거대한 소프트웨어는 수십년이 걸릴 수도 있다.

하지만 소프트웨어는 빌딩과 같이 1층이 완성되기를 기다렸다가 2층을 만들 필요가 없다. 1층과 2층의 인터페이스만 잘 정하면 따로 만들어서 합치면 된다. 다 만들어서 나중에 합치는 방법도 있지만, 1층과 2층의 뼈대만 만들어 놓고 동시에 만드는 방법을 더 많이 사용한다. 나중에 합치게 되면 합치는 과정에서 문제가 발생하기도 하지만, 처음부터 합쳐 놓고 동시에 만들면 합치는 과정에서 생기는 문제가 줄어든다.

(빠른 병행 개발 - 개발 후 통합)

(빠른 병행 개발 - 통합 후 개발)

이렇게 소프트웨어를 동시에 개발하여 프로젝트 기간을 단축하려면 분석, 설계가 잘 되어 있어야 한다. 특히 컴포넌트를 잘 나누고 인터페이스를 견고하게 정의해야 한다. 인터페이스는 간결하게 정의를 해야 각 모듈 간의 연동이 쉬워진다. 인터페이스는 확고하게 정의를 해야 하며 나중에 함부로 바꾸면 안된다. 물론 한번 정의한 인터페이스가 프로젝트 종료 시까지 변경되지 않으면 가장 좋겠지만 쉬운 일이 아니다. 개발 도중에 인터페이스를 변경하면 처음에 잘 정의한 경우보다 수십배의 변경 비용이 들어간다. 따라서 분석, 설계 시 최대한 노력을 하여 인터페이스가 가능하면 변경되지 않도록 정의를 해야 한다.

프로젝트가 크고 참여 인원이 많을수록 순차적인 개발보다 병렬 개발이 훨씬 좋다. 수십명의 개발자가 참여하는 프로젝트에서 순차적인 개발이란 거의 불가능하다. 수십명의 개발자가 처음부터 잘 통합된 소스코드를 기반으로 병렬로 개발을 해야 프로젝트를 빨리 끝낼 수 있다.

(순차개발과 병행개발의 개발 속도 차이 비교)

인터페이스는 상호간의 약속이다. 클라이언트와 서버 모듈을 병렬 개발할 때 인터페이스는 클라이언트 개발팀과 서버 개발팀의 약속이다. 인터페이스를 확정하면 서로 약속을 한 것이고 서로 헤어져서 따로 개발을 해도 문제가 없을 정도로 신뢰를 할 수 있어야 한다.

프로젝트 기간 내내 인터페이스를 잘 유지하기 위해서는 지속적인 통합이 필요하며 유닛 테스트, 테스트 자동화도 유용하다. 개발자는 자신이 작성한 모듈을 완성한 후에 소스코드관리시스템에 등록하는 것이 아니라 좀더 잦은 주기로 등록을 하여 프로젝트 주기 내내 소스코드가 정상적으로 빌드가 되도록 유지해야 한다. 너무 늦게 통합을 할 경우 많은 문제를 발생시키는 “통합의 지옥”을 맛보게 된다.

커밋은 하나의 기능이 완성이 되었을 때, 전체 클래스 또는 전체 컴포넌트를 모두 구현할 때까지 기다릴 필요가 없다. 하지만 항상 빌드는 되어야 한다. 또한 내가 소스코드를 수정하는 동안 다른 곳을 수정한 동료들의 소스코드와 머지(Merge)가 잘 되어서 제대로 빌드가 되는지 확인을 해야 한다. 보통은 적어도 하루에 한두 번 이상 커밋을 한다. 며칠씩 커밋을 하지 않고 지나가지는 않는다.

지속적인 통합을 위해서는 툴을 사용해도 되고, 직접 스크립트를 작성해서 구축을 해도 된다. 지속적인 통합을 도와주는 툴을 CI툴이라고 하며 Jenkins, Bamboo 등이 있다. CI툴 자체가 중요한 것은 아니지만 CI툴은 지속적인 통합을 조금 쉽게 해준다. 중요한 것은 지속적인 통합 활동을 성실히 하는 것이다.

지속적인 통합을 위해서는 주기적인 빌드가 필수다. Build on commit을 하기도 하고 Daily build를 하기도 한다. 밤에 빌드를 한다고 해서 Nightly build라고 하기도 한다. 프로젝트 기간 내내 Daily build는 실패가 없어야 한다. Daily build가 실패하면 인터페이스가 깨졌거나, 어떤 개발자가 깨진 소스코드를 올렸을 수 있다. 빌드가 깨지면 여러 개발자들이 개발에 차질을 빚게 된다. Daily build가 깨진 것을 브로큰 트리(Broken tree)라고 부르며 즉각 해결을 해야 한다.

거대한 시스템일수록 병렬 개발은 꼭 필요하다. 거대한 시스템의 구조를 얼마나 간결하게 하는지가 설계의 중요 요소다. Architect는 복잡한 시스템을 최대한 간결하고 복잡도를 줄여서 시스템의 개발, 유지보수 효율을 높여야 한다. 병렬 개발을 할 때 어려운 점은 내가 필요로 하는 컴포넌트가 아직 구현이 안되어 있어서 기능을 확인할 수 없다는 것이다.

예를 들어보자. 나는 사용자 관리 화면을 개발하고 있고 getUserList()라는 함수가 필요하다. 나는 사용자 목록을 출력하는 화면을 만들고 있는데 getUserList()를 개발하는 개발자는 아직 이 함수를 구현하지 않은 상태다. 그럼 나는 getUserList() 함수가 개발되기 전까지는 내가 만든 사용자 목록 화면을 테스트 해볼 수가 없다. 그럴 때는 getUserList() 함수에 가짜 코드를 추가하면 된다. 실제로는 DB에 쿼리를 해서 사용자 목록을 가져와야 하지만, 가짜로 Hard coding을 해서 사용자 목록을 넘겨주는 것이다. 물론 이런 가짜코드는 필요에 따라서 언제든지 넣고 뺄 수가 있어야 한다.

C언어로 개발을 한다면 다음과 같은 형태가 될 것이다. 아주 간단한 예를 든다.

#define USE_FAKE
RET getUserList(userdata *pData[], int &num)
{
#ifdef USEFAKE
  // make fake data
  num = 2;
  pData[0]->userid = 1;
  pData[0]->username = “John”;
  pData[1]->userid = 2;
  pData[1]->username = “Tom”;
#else
  // get data from database
#endif
  return RET_SUCCESS;
}

(병행 개발을 위한 소스코드 예)

이와 비슷하게 개발 언어에 따라서 적절한 방법으로 병렬 개발하는 아이디어를 적용하면 된다. 병렬 개발을 위와 같이 각자 서로 다른 모듈을 개발하는 경우도 있고 하나의 모듈을 여러 개발자가 개발하는 경우도 있다.

잘 분석, 설계된 소프트웨어는 이와 같은 방법을 사용하여 병렬 개발을 진행하여 소프트웨어를 빨리 개발할 수 있다.

share with abctech.software

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SW개발의 8:2 법칙, 그리고 불편한 진실 (개발문화 시리즈4)

이번 개발문화 이야기는 '가내 수공업식 개발문화'다. 즉, 8:2 법칙에 관한 이야기다.  소프트웨어 개발에 있어 시스템과 개발자에 의존하는 비율이 8:2정도가 되어야 한다는 것이다. 

그럼 다른 분야는 어떨까? 예술적일수록 시스템에 의존하는 비율이 낮고, 체계화되고 규모가 클수록 시스템 비율이 높아져서 인력에 대한 유연성은 증가한다. 

소프트웨어 개발에 있어 가장 중요한 요소는 사람이다. 즉, 개발자이다. 그런데 전적으로 개발자에게 의존하는 개발방식은 효율도 떨어지고 리스크도 높다. 특히 소수 인력에 의존하는 방식은 가내수공업 형태를 벗어나지 못한다.

비단 소프트웨어 분야 뿐만이 아니다. 전통 도자기 등 시스템화로 인해 산업화를 못 이루고 맥이 끊겨 사라져버린 분야가 얼마나 많은가? 임진왜란 때 수많은 도공을 납치해간 일본은 도자기 생산을 체계화해서 산업화에 성공했다. 유럽 수출을 시작으로 부를 쌓아서 선진국이 되는 발판을 마련했다. 

회사 규모가 크나 작으나 회사 시스템에 대한 의존도가 매우 낮고 개별 개발자에 의존하는 회사는 개발자들을 효율적으로 활용하지도 못한다. 개발자들이 퇴사하면 큰 타격을 입고 새로운 개발자가 들어와도 효율적으로 일하는데 많은 노력과 시간이 필요하다. 

개발자들이 실력에 맞는 일을 적절하게 골고루 나눠 하지 못하고 한쪽으로 치우치기 일쑤고 고급 개발자들이 소방수역할을 하는 경우가 많다. 회사 규모는 큰데 여전히 가내수공업 형태를 못 벗어난 결과다. 

이런 현상은 회사가 시스템을 효율적으로 갖추지 못해서 벌어진다. 회사 시스템이란 개별 직원과 대비되는 회사의 전반적인 체계를 말한다.소프트웨어 회사 또는 소프트웨어를 개발하고 있는 모든 회사라면 갖춰야 할 시스템은 다음의 4가지가 있다. 

조직, 프로세스, 문화, 기반시스템이다. 

4가지를 잘 갖추고 있다면 특정 개발자에게 의존하는 리스크는 줄고, 개발자들도 더 효율적으로 일할 수 있다. 개발자가 이직을 해도 빠른 시간 안에 적응이 가능한다. 이것은 개발자와 회사 모두에게 이익이 된다. 

이렇게 되려면 소프트웨어 개발이 시스템에 의존하는 비율이 80%정도는 되어야 한다. 나머지 20%는 도저히 시스템으로 커버가 어려운 부분이다. 하지만 대부분의 회사는 8:2가 아니라 2:8 또는 1:9이기 때문에 문제다.

개인 회사이거나 아주 작은 회사도 지속적으로 성장하려면 시스템에 의존하는 비율을 0%에서 시작하여 20%, 50%, 80%로 차츰 높여가야 한다. 

특정 개발자가 빠져 나가면 대부분의 개발 경험과 지식도 함께 빠져나가게 되는 경우 회사는 매우 불안한 상황에 놓인다. 이런 상황을 개발자가 의도적으로 만든 것은 아니다. 회사의 시스템이 워낙 부실하기 때문이다. 

이런 상황이라면 개발자도 워낙 바빠서 그런 상황에 신경 쓸 겨를이 없다보니, 상황은 더욱 악화된다. 단기적으로는 개발자 가치가 올라가서 더 좋을 것 같다. 하지만 장기적으로 보면 이런 환경에서 개발자는 적절한 성장 기회를 얻지 못한다. 아키텍처는 신경 쓰지도 못하고 여기저기 불려다니면서 재미없고 힘든 문제 해결에 주로 투입된다. 개발자 본인에게도 장기적으로는 손해다. 

여기에는 몇 가지 논란이 있을 수 있다. 

첫째, 그럼 개발자는 교체 가능해야 하는 부품인가? 

회사가 시스템을 갖춰야 하는 이유는 개발자를 교체 가능하도록 하기 위한 것이 아니다. 리스크를 줄이고 좀더 효율적으로 개발하기 위해서이다. 개발 중에는 교체가 쉽게 되는 일이 있고, 어려운 일이 있다. 교체가 쉽게 되는 일까지 회사 핵심개발자들의 시간을 많이 빼앗으면 안된다. 회사 핵심 개발자들은 좀더 중요한 일을 해야 한다. 

그러려면 쉬운 일들, 과거에 해놓은 일들을 다른 사람이 할 수 있는 시스템이 필요하다. 이런 상황에서는 핵심 개발자가 퇴사해도 유지보수에 큰 문제가 없다. 하지만 미래의 중요한 프로젝트에 타격을 입기 때문에 개발자들의 가치는 결국 커진다. 물론 아주 작은 회사는 상황이 다르다. 

둘째, 시스템을 아주 잘 갖추고 있는 대기업이 소프트웨어 개발을 더 잘해야 하는 것 아닌가? 

시스템은 회사의 상황과 역량에 알맞게 적절히 갖춰야 한다. 하지만 큰 회사들은 여기서 큰 불균형을 이루는 경우가 많다. 프로세스를 과도하게 복잡하게 하고 사용하기도 힘든 비싼 시스템들을 구축해 사용을 하기는 하지만 효율성 측면에서의 개발문화는 한참 뒤쳐져 있다. 

이런 상황에서 프로세스는 형식적으로 흐르고 비싼 시스템은 장식물에 그치는 경우가 많다. 개발효율로 따지만 주먹구구보다 더 못한 경우도 있지만, 보험의 성격이 있어서 쉽게 포기하지도 못한다. 

소프트웨어 회사가 갖추어야 할 시스템, 즉, 조직, 프로세스, 문화, 기반시스템은 교과서에 딱 정해져 있는 것은 아니다. 회사 규모, 성격 등에 따라서 계속 바뀌어 나가야 한다. 부족해도 문제고 과도해도 안된다. 

개발자 혼자 회사를 하면 혼자서 모든 것을 다해야 하지만, 10명, 30명, 100명으로 늘 때마다 조직 구성이 달라져야 한다. 하지만 많은 회사들이 큰 규모에 비해서 이런 구분 없이 개발자에게 너무 많은 일을 맡기고 있는 경우가 많다. 

보통은 회사가 커지면서, 테스트, 빌드, 시스템관리, 기술지원, 고객지원, 영업지원 등과 같은 일들은 전문조직으로 분리해야 한다. 어려운 점은 적절한 시점에 적절한 규모로 조직을 변화시켜야 한다는 것이다. 

그럼, 프로세스는 어떤가? 여기에도 극과 극이 있다. 명시적인 프로세스가 아예 없거나 너무 복잡한 경우도 많다. 프로세스는 최대한 단순하고 자유도를 높이면서도 핵심적인 요소들은 빠지지 않도록 해야 한다. 이 또한 회사의 역량이 높아감에 따라서 계속 바뀌게 된다. 

많은 회사들이 열악한 개발 문화와 낮은 역량을 비싼 기반시스템이 해결해 줄 것으로 착각한다. 꼭 필요한 기반시스템도 있지만 오히려 해가 되는 경우가 훨씬 더 많다. 소수의 필수 시스템을 제외하고는 적절한 시점에 필요하면 사용하면 된다. 꼭 비싼 시스템이 아니라도 상관없다. 개발자당 연 사용료가 수백, 수천만원하는 종합선물세트 시스템을 구축해 놓고 극히 일부 기능만 쓰는 경우도 많다. 툴로는 결코 문화나 역량을 극복할 수 없다. 

반대 경우도 문제인건  마찬가지다. 필수 기반시스템 하나 없이 주먹구구로 개발하는 회사라면 좋은 오픈소스 기반시스템들이 있으므로 잘 선택한뒤 제대로 가이드를 받아 사용하면 된다. 과도한 경우보다는 개선하기가 쉽다. 

회사 규모에 맞게 안정적이며 꾸준히 역량을 향상하면서 개발을 하려면 개발자에게만 책임을 지울 것이 아니라 회사가 더 많은 것을 갖추고 있어야 한다. 그러기 위해서 꾸준한 투자와 변화는 필수다. 작년과 올해 조직, 프로세스가 똑같고 변화를 위해 투자를 한 것이 하나도 없다면 회사는 책임을 회피하고 있는 것이다.

리스크를 줄이고 개발자가 보다 효율적으로 일할 수 있는 환경을 만들려면 회사가 80%를 갖출 수 있도록 노력해야 한다.

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

대한민국 개발자가 불행한 이유

미국에서 과거 10년 넘게 최고의 직업에 항상 소프트웨어 개발자와 아키텍트가 자리하고 있고 미래 성장 가능성도 상당히 높게 평가하고 있는 것을 보면 격세지감을 느낀다. 10개나 100개 직업 중에 1위가 아니고 몇 만개의 직업 중에 1위라는 것은 대단한 것이다. 그러나 우리나라에서 소프트웨어 개발자는 그렇게 인기가 있는 직종이 아니다. 의사, 변호사와 비교는 고사하고 3D 직업이라는 인식도 팽배하다.

이는 단순히 소득의 차이 때문은 아닌 것 같다.

우리나라에서 소프트웨어 개발자로 일하게 되면 10년, 20년 그리고 30년 이상 소프트웨어 개발자로 계속 일할 수 있다는 희망이 잘 보이지 않는다. 왜 그럴까? 이런 환경에서 태어난 대한민국의 소프트웨어 개발자는 불행하다고 할 수 있다. 미국이라고 무조건 개발자로서 성공적인 삶을 사는 것은 아니지만 같은 조건이라면 개발자로 잘 성장할 확률이 더 높고 여건도 좋다.

이런 차이가 발생하는 이유는 타고난 재능의 차이도 아니다. 개발자들의 기술력의 차이도 아니다. 바로 환경의 차이 때문이다. 소프트웨어 산업 생태계의 차이도 크지만 각 회사, 개발팀의 개발 문화 차이가 가장 크다. 이런 개발 환경을 만든 것은 개발자 여러분은 아니고 여러분의 선배들과 회사이다.

지금 이 글을 읽고 있는 소프트웨어 개발자가 만약에 미국에서 태어나 소프트웨어 개발자로 일하고 있다면 상당히 다른 환경에서 다른 경험을 하면서 성장할 것이다.

물론 우리나라가 더 좋은 환경을 가지고 있는 것도 있고, 내세울 수 있는 것도 있지만 소프트웨어 환경에 대해서는 이 땅에서 태어나 영어 때문에 고생하는 것처럼 핸디캡이 되는 것은 사실이다.

소프트웨어 선진국은 개발 프로세스, 기반 시스템, 조직 문화, 개발 문화 측면에서 큰 차이가 있고 성장을 도와줄 선배 개발자들이 많고 롤모델(Role model)도  있다. 우리나라에도 선배 개발자들이 많이 있지만 경험의 전수가 잘 안되는 구조가 문제다. 여기서 선순환과 악순환의 차이가 발생한다.

소프트웨어 선진국에선 입사를 하면 대부분 바로  업무에 투입된다. 문서, 시스템이 잘 갖춰져 있어서 버그를 수정하는 일을 하는데 큰 어려움이 없다. 버그추적시스템을 통해서도 버그를 할당 받고, 많은 정보를 얻을 수 있다. 소스코드는 시스템을 통해서 바로 한줄 한줄의 수정된 역사를 볼 수 있고 내용을 물어보러 다니지 않아도 웬만한 버그는 수정이 가능하다. 빌드도 자동화 되어 있어서 내용을 몰라도 누구에게 물어보지 않고도 한번에 빌드가 된다. 또한 내가 고친 코드는 피어 리뷰(Peer review)를 통해서 코딩 컨벤션 준수 여부뿐만 아니라 더 좋은 기법 등을 배운다. 분석, 설계 등에도 참여하고 지속적인 피어 리뷰를 거치면서 경험이 점점 깊어지고 후배나 동료들에게 내 지식과 경험도 공유하게 된다.

이렇게 할 수 있는 핵심은 적절한 피어리뷰다. 피어리뷰가 가능한건 기반시스템이 잘 갖춰져 있기 때문이다. 또 개발에 집중할 수 있고 다른 일은 신경쓰지 않아도 되는 프로세스와 조직문화 때문이다. 10년, 20년이 되면 시니어 엔지니어가 되거나 아키텍트가 될 수 있다. 회사 내에서 다른 프로젝트로 옮겨 다니거나 이직을 해도 후배들이 이어 받아서 아무 문제없이 개발이 지속된다. 15년이 되었는데 연봉도 다른 직업의 친구들보다 훨씬 높고 만족감이 높다.  과거 같이 일하던 동료가 차린 유망한 스타트업에 스톡옵션을 받고 참여하는 기회도 잡을 수 있다.

그럼 우리나라에서 소프트웨어 개발을 시작한다면 어떨까? 좋은 회사, 나쁜 회사, 여러 가지 경우가 있지만, 그 중 일반적인 예를 하나 보자.

대학에서 소프트웨어 전공을 하고 입사를 했다. 회사에서 개발하고 있는 소프트웨어에 대한 도메인 지식이 없으면 개발에 참여 하기가 어렵다. 관련 서적을 받아서 몇 달간 공부를 하고 회사에 대한 여러 가지 교육을 받는다. 제대로 개발에 참여하려면 최소 6개월이 걸린다고 하니, 일단 바로 유지보수에 투입된다. 소프트웨어를 파악할 수 있는 자료는 소스코드 밖에 없다. 선배들에게 물어물어 소스코드를 내려 받았고 개발환경을 구축하는데도 하루가 걸렸다.

빌드가 쉽지 않아서 여러 번의 실패와 우여곡절 끝에 빌드에 성공했다. 소스코드를 보고 분석을 하다가 도저히 몰라서 선배에게 물어보려니 개발한 선배가 퇴사를 했단다. 밤을 세서 수정을 했는데 제대로 동작하고 부작용(Side effect)은  없는지 확신은 없다. 누구도 내가 작성한 코드를 리뷰해주지 않는다. 그러다가 개발한지 얼마 되지도 않았는데 실전 사이트에 투입됐다. 선배와 같이 고객을 만나서 요구사항을 듣고 커스트마이징 작업을 진행했다. 워낙 바빠서 문서작성은 꿈도 못 꾸고 코딩만 했다.

선배와 내가 아니면 회사의 누구도 우리가 한 작업의 내용을 모른다. 경험이 쌓이면서 좀더 어려운 일을 맡고 바쁜 개발일정을 소화한다. 문서도 없고, 시스템에도 정보도 없고, 피어 리뷰도 없는 것은 여전하다. 회사에서 강제로 문서를 만들라고 해서 만들기는 하지만 쓸모 없는 문서일 뿐이다.

7년쯤 일하니 회사에서 제일 개발을 잘하는 개발자가 되었다. 경영진이 능력을 인정해서 팀장도 되었다. 팀장이 되니 회의도 많고 보고서도 많이 써야 한다. 낮에는 일할 시간이 거의 없어서 직원들 퇴근 후에 개발을 하게 되었다. 그러나 보니 차츰 개발에서 손을 떼게 되었다. 다시 개발로 돌아 가려고 하지만 여건이 안 된다. 팀장을 몇 년 하다 보니 정체성이 없어지고 앞길이 막막해졌다. 이제 치킨집을 차릴 때가 되었나 보다.

이러한 선순환과 악순환의 차이를 극복하려면 개발 환경을 바꿔야 한다. 개발프로세스, 기반시스템, 개발문화, 조직문화가 바뀌어야 한다. 우리가 이를 바꿔나가지 않으면 우리 후배들도 10년, 20년 후에 똑같은 얘기를 하면서 한숨을 쉬고 있을 것이다. 이는 비단 후배들만을 위한 일은 아닐 것이다. 우리가 일할 10년, 20년 후의 소프트웨어 환경을 바꾸는 일이다.

환경을 바꾸려고 하니 무엇부터 바꾸어야 할지 막막한 경우가 많다. 물론 회사마다 다르기는 하지만 쉬운 것부터 하는 것이 좋겠다. 우선 효율적인 기반시스템을 갖추는 것이 좋다. 성숙도에는 차이가 크겠지만, 소스코드관리, 버그관리, 빌드 자동화를 갖추고 서로 연동을 시킨 뒤  소스코드를 보면 버그나 이슈가 연결되고 반대로 버그가 소스코드와도 쉽게 연결될 수 있는 환경을 만들어야 한다.  그리고 나면 피어 리뷰를 할 수 있는 환경이 조금씩 되어 간다.

거의 모든 것을 완벽하게 자동화하는 것이 바람직하다. 자질구레하게 중간중간 수동 작업이 많이 들어가면 회사가 커갈수록 비용은 점점 올라가고 비생산적인 일에 많은 노력을 들여야 한다. 또 완전 자동화된 시스템 환경이어야 공유와 효율적인 협업이 가능하다. 인터넷에서 정보를 얻어서 좋을 툴을 설치하는 것은 어렵지 않지만 제대로 구축해서 잘 사용하는 것은 몇 백배 더 어렵다. 경험을 많이 해본 선배들의 도움을 받는 것은 필수적이다.

이 정도 되어야 환경을 바꾸기 위한 마라톤의 한 발을 내디딘 것이라고 보면 된다. 그래도 시작이 반이다. 의미 있는 한발이 될 것이다.

이 글은 제가 CNet Korea에 기고한 칼럼입니다. (http://www.cnet.co.kr)

전지전능한 슈퍼 개발자의 역설

필자는 여러 소프트웨어 회사에서 많은 개발자를 만난다. 그러면 보통 회사에 한두명씩 전지전능한 슈퍼 개발자가 있는 것을 보게 된다.

이들은 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반관리, 전략 수립 등 엄청나게 많은 일을 한다. 직책은 대부분 팀장이다.

여러분의 회사에도 이런 개발자가 한두명씩은 있을 것이다. 이들이 여러분의 롤모델인가? “나도 그런 전지전능한 개발자가 되어야지”라는 다짐을 하는가? 아니면 혹시 여러분이 이런 전지전능한 개발자인가?

이렇게 많은 일을 하는 개발자가 One man company에만 있는 것이 아니다. 개발자가 수백명이 넘는 회사에서도 드물지 않게 만날 수 있다.

이런 회사에서는 모든 길이 로마로 통하듯이 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결이 된다. 이 전지전능한 개발자가 모든 기술과 정보를 꽤 뚫고 있어서 문제가 발생하면 즉시 해결해주고 회사는 그럭저럭 굴러간다. 이 개발자가 나가면 회사는 망할 것만 같다.

이런 현상이 좋아보이는 사람도 있을지 몰라도 회사는 인력적으로 큰 리스크를 안고 있는 것이고 뛰어난 개발자를 가장 가치 있는 일에 제대로 사용하지 못하는 손해를 입고 있는 것이다. 전지전능한 개발자는 본인이 선택을 해서 그런 위치가 된 것은 아니다.

회사가 성장과정에서 적당한 때 조직을 전문화하고 변화를 꾀했어야 하는데 그냥 달려만 오다보니 능력이 좋은 개발자가 이거 저거 다 떠 안게 되면서 이런 현상이 벌어지게 되었다. 좀더 잘할 수 있는 분야에 집중했다면 본인 역량 면으로도, 미래 가치면으로도 훨씬 좋은 결과를 가져왔겠지만, 지금은 회사의 맥가이버가 된 상황에 만족할 수 밖에 없다.

다른 회사로 가면 지금의 가치는 대부분 사라지고 만다. 개발자 본인에게도 안타까운 상황이다.

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능하다. 아주 작은 회사에서나 그렇게 하는 것이다. 이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 한다. 모든 일을 잘한다는 것은 애초에 불가능하다. 특히 중요한 일은 주 업무인 개발을 할 시간이 확 줄어 든다는 것이다.

대부분의 이들은 예전에는 뛰어난 개발자였다. 하지만, 개발 이외 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됐다. 그리고 각 일의 Switching cost가 만만치가 않다. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거다.

심지어는 그런 개발자에게 테스트, 고객 응대, 기술 지원까지 하라는 것은 100원주고 20원짜리 일을 시키는 것과 같다. 비효율적일 뿐만 아니라 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못한다.

이런 슈퍼 개발자는 다른 소프트웨어 회사에 가면 가치가 확 떨어진다. 분야가 달라지면 Domain Knowledge 관련 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 된다. 관리자가 되어야 하나 고민이 많다. 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되는 경우도 있다.

회사는 이들에 대한 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 된다. 이들이 등돌리면 회사는 휘청거린다.

이것이 개발자 탓일까? 아니면 회사 탓일까? 회사 탓이다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야한다. 그런데 개발자가 맨땅에서 북치고 장구치고 다 하고, 회사에서는 이를 방치하다보니 이렇게 되는 것이다. 하지만 많은 경영자들은 개발자가 잘 하니 그냥 그렇게 개발자가 다 해야 하는 것으로 아는 경우가 매우 많다.

그럼 어떻게 해야 할까?

개발자가 개발에 전념할 수 있도록 항상 여건을 조성해줘야 한다. 회사가 아주 작아서 어쩔 수 없이 개발자가 여러가지 일을 겸해서 하고 있다고 하더라도 회사가 조금만 커져도 개발자의 일에서 개발업무가 아닌 일을 떼어낼 수 있도록 준비를 해야 한다.

조직이 조금 커지면 테스터를 뽑고, 기술지원인력을 보강하는 것이 좋다.

개발자 10명이 이거 저거 모든 일을 다하는 것보다. 개발자 7명에 테스터2명, 기술지원 인력 1명인 조직이 더 낫다. 개발자가 개발에 더 집중할 수 있고 개발자 10명이서 하는 일보다 더 많은 일을 할 수 있다. 물론 조직과 더불어 프로세스, 기반시스템, 개발문화도 뒷받침이 되어야 하지만 이는 기본으로 생각하자.

이렇게 조직이 분리되고 개발자가 개발에 전념을 할 수 있어야 개발이 좀더 체계적으로 진행된다. 다른 조직의 인력과 협업을 하기 위해 필요한 최소한의 문서도 만들어야 하고 프로세스도 자연스럽게 필요하게 된다. 커뮤니케이션을 위한 기반시스템도 잘 활용하게 된다.

조직이 더 커지면 분리해야 하는 역할이 점점 많아진다. 즉 조직이 세분화 된다. 이는 회사 규모에 따라서 다르니 이 일이 개발자가 해야 하는 일인지 잘 생각해보고 결정하면 된다.

여기서 개발자의 업무를 모두 나열할 수는 없지만 회사에서 개발자가 개발에 집중할 수 있도록 노력하는 일은 대단히 중요하다. 개발자가 잘 해낸다고 그냥 방치하면 안된다. 개발자는 개발을 잘할 때 회사의 보물이 되는 것이다. 다른 일들은 여건이 되는 대로 다른 전문가에게 맡기도록 하자.

이 글은 Tech it에 기고한 글입니다.

스타트업에서 SW 개발에 꼭 필요한 시스템

소프트웨어를 개발하는데 꼭 필요한 시스템들이 있다. 이것을 기반시스템, 영어로는 Infrastructure system이라고 한다. 기반 시스템은 수십 가지 종류가 있지만 회사 규모나 성격에 따라 꼭 필요한 것이 다르다. 꼭 필요한 기반시스템을 사용하지 않거나 규모에 맞지 않게 많이 사용하는 것 모두 문제다. 그리고 제대로 사용해야 효과를 극대화할 수 있다.

회사 규모가 크면 좀더 많은 기반시스템을 사용할 필요가 있지만 스타트업에서는 꼭 필요한 몇 가지만 있으면 된다. 그럼 스타트업에서 꼭 사용해야할 기반 시스템에는 어떠한 것들이 있는지 알아보자.

1. 소스코드관리시스템

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Bitbucket, Github

추천 시스템: Git, SVN

소스코드관리시스템이 없이 소프트웨어를 개발한다는 것은 상식적으로는 도저히 불가능하다. 자체적으로 구축하는 것도 가능하지만 호스팅을 권장한다. 소스코드관리시스템을 직접 구축하여 운영하려면 하드웨어 구매 비용, 관리 비용 등 만만치 않은 비용이 들어간다. 하지만 호스팅을 이용할 경우 그 수십 분의 일의 비용으로 해결할 수 있다.

호스팅으로 SVN을 이용할 경우 네트워크 속도가 느릴 경우 불편함이 있지만 DVCS(분산버전관리시스템)인 Git를 사용할 경우 문제가 많이 해결된다. Git는 SVN 사용자가 쉽게 사용할 수 있도록 거의 비슷한 명령어 체계도 갖고 있다. 요즘은 Git도 편리한 GUI Client가 많아 SVN만큼 편하게 쓸 수 있다.Git는 기능이 너무 많아 어려워하는 개발자들도 있는데 SVN을 사용하던 방식과 거의 유사하게 사용할 수도 있으므로 시도해보기 바란다.

Git 호스팅 서비스인 Bitbucket.org를 이용하면 5명까지는 무료로 10명은 월 $10, 100명은 월 $100를 내면 된다. 100명 정도까지는 호스팅을 이용하는 것이 훨씬 비용적으로 유리하다고 할 수 있다.

2. 이슈관리시스템 (버그추적시스템)

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Atlassian Jira OnDemand

추천 시스템: Jira, Redmine

요즘은 소스코드관리시스템을 아예 사용하지 않는 소프트웨어 회사가 거의 없지만 의외로 아직 이슈관리시스템을 사용하지 않는 회사는 많다. 엑셀이나 위키를 이용하거나 Email로 처리하는 회사도 있다. 그렇게 해서는 방대한 소프트웨어 개발 이슈를 효과적으로 처리할 수도 없고 많은 커뮤니케이션 비용이 들어간다. 수십 년 동안 진화를 거듭해온 이슈관리시스템들은 제대로 사용하기만 해도 회사 개발문화가 상당히 성숙하게 바뀔 수 있다. 아직 이슈관리시스템을 사용하고 있지 않다면 당장 도입하기 바란다.

과거에는 Trac, Mantis 등이 많이 사용되었다. 여전히 좋은 시스템들이지만 모든 것을 비교해보면 요즘은 Jira와 Redmine을 추천한다. 이슈관리시스템도 비용적인 측면에서 호스팅을 권장하고 Atlassian의 Jira OnDemand을 추천한다. 10명까지는 월 $10, 25명은 월 $100면 된다. OnDemand 스타트업을 위한 저렴한 비용을 제시하고 있다. 회사가 커지면 나중에 직접 구축하고 그 동안 쌓아 놓은 데이터는 마이그레이션이 가능하다.

3. 빌드시스템

필요성: ★★★☆☆

추천 형태: 자체 구축

추천 시스템: 자동화된 빌드 스크립트 자체 제작, Jenkins (구 Hudson)

위에서부터 점점 내려올수록 사용하고 있는 비율이 줄어든다. 빌드시스템은 소프트웨어 개발에 꼭 필요한 시스템이다. 많은 회사가 개발자 PC에서 Eclipse나 Visual Studio의 IDE창에서 버튼을 눌러 빌드한 소프트웨어를 그냥 출시하곤 한다. 소프트웨어 개발에서 개발자 PC는 “더러운 환경”이라고 지칭한다. 테스트를 하거나 출시를 위한 소프트웨어는 깨끗한 빌드 전용 “빌드시스템”에서 빌드해야 한다. 또 자동화된 빌드 스크립트를 제작해서 One-step으로 모든 빌드가 끝나야 한다.

적어도 하루에 한번은 자동으로 빌드를 실행하여 소스코드가 항상 빌드가 가능한 상태로도 유지해야 한다. 이를 Daily Build라고 부른다. 소수가 개발하면 이런 것 신경 안 써도 어쨌든 개발이 되기 때문에 소홀하기 쉽다. 하지만 “더러운 환경”에서 대충 개발하는 것은 대단히 위험한 일이고 Daily Build를 하지 않는 것은 협업의 기본을 모르는 행위다. 빌드시스템은 자체적으로 구축해야 한다면 Daily build나 CI(지속적인 통합)을 위해 Jenkins등의 CI툴을 이용하면 좋다.

4. Wiki

필요성: ★★☆☆☆

추천 형태: 호스팅

추천 시스템: Confluence OnDemand

꼭 사용해야 하는 시스템도 아니고 특별히 추천을 하고 싶은 서비스도 없지만 Atlassian의 호스팅 서비스를 이용하면 연동이 쉬운 같은 서비스를 이용하는 것이 좋겠다. 비용도 Jira OnDemand와 같다.

Jira를 이용해도 상당히 많은 정보가 공유되지만, Wiki는 흩어져 있는 지식과 정보를 한군데로 모으는데 효과적이다. 하지만 Wiki는 결국 Tool이기 때문에 문서를 대신 작성해주지는 않는다. 그렇다고 Wiki를 사용하기 위해서 강제로 문서화를 시도하다가는 Wiki가 방치되기 십상이다.

스펙도 작성할 능력이 좀 되고 문서화에 거부감이 없다면 Wiki를 도입하는 것도 괜찮다. 모든 문서를 Wiki가 대신할 수 없지만 많은 지식을 체계적으로 정리할 수 있는데는 유용하다. 훌륭한 회사 자산도 될 수 있고 효율적인 소프트웨어 개발에 많은 도움을 준다.

5. 프로젝트관리시스템

필요성: ☆☆☆☆☆

추천 시스템: 시스템보다는 엑셀 파일 이용

시스템을 잘못 사용하면 배보다 배꼽이 더 큰 경우다. 좋은 프로젝트관리시스템이 많기는 하지만 대부분 스타트업이 사용하기 무거운 제품들이다. 프로젝트가 지연되는 것은 프로젝트관리시스템을 사용하지 않아서가 아니다. 스펙을 제대로 작성하지 않아서 지연되는 경우가 대부분이다. 스펙이 잘 작성되어야 개발범위가 명확해지고 상세한 개발일정 수립이 가능하다.

일 단위의 개발일정이 수립되면 엑셀에 작성을 해서 관리해도 충분하다. 오히려 웬만한 프로젝트관리시스템들보다 엑셀이 더 편리하다. 회사가 좀더 커져서 수많은 프로젝트와 인력을 동시에 관리해야 할 때 프로젝트관리시스템 도입을 검토해보는 것이 좋겠다.

기반시스템은 도입하는 것보다 제대로 사용하는 것이 더 중요하다. 각 기반시스템을 사용하는데 꼭 지켜야 할 규칙을 몇 가지 제시한다.

소스코드관리시스템

1. 회사의 모든 소스코드 및 개발문서는 빠짐없이 등록해야 한다.

2. 커밋 메시지 규칙, 리뷰 규칙 등 회사의 규칙을 모든 직원이 철저히 따라야 한다.

3. 공식적인 빌드는 항상 Tag(베이스라인)를 남겨야 한다.

4. 협업을 위한 코딩 습관을 가져야 한다. 즉, 머지(Merge)가 원활하게 되게 해야 한다. 소스트리를 견고하게 가져가야 하며 개발자가 함부로 파일의 이름을 바꾸거나 이동하면 안 된다. 소스코드 내에서도 함수를 이리 저리 옮기면 안 된다. 이외에도 지켜야 할 수많은 습관들이 있는데 협업을 하면서 차츰 익히면 된다.

이슈관리시스템

1. 전 직원이 모든 이슈를 이슈관리시스템에 직접 등록해야 한다. 대리 등록은 사양한다.

2. Email, 구두, 전화, 메신저 등 다른 경로를 통한 요청은 없애나가야 한다.

3. 스스로 능동적으로 이슈관리시스템을 모니터링 해야 한다. 사장이라도 필요한 정보는 보고를 요청하지 말고 이슈관리시스템을 통해서 확인하면 된다.

4. 모든 이슈는 전 직원에 오픈한다.

지금까지 스타트업에 필요한 기반시스템과 기본적인 사용규칙에 대해서 설명했다. 기반시스템을 사용하는 것만으로 회사 역량이 세계적인 수준이 되는 것은 아니다. 그야말로 기초 중에 기초일 뿐이다. 하지만 그러한 기초도 안되어 있다면 엄청나게 비효율적으로 개발을 하고 있는 것이다.

기반시스템은 일단 경험을 해보고 제대로 사용하기 시작하면 절대로 과거로 돌아가지 못한다. 때때로 과거에는 이런 좋은 시스템도 없이 왜 그렇게 고생을 했을까 회상하기도 한다. 물론 그때는 비효율적이라는 것을 몰랐었다.

소프트웨어 회사라면 이런 기본적인 것을 잘 갖춰야 진정한 역량인 분석, 설계 등의 역량을 향상시킬 수 있다. 아직 기반시스템을 제대로 갖추고 있지 않은 회사는 저렴한 호스팅 서비스부터 당장 갖추기 바란다. 시작이 반이다. 제대로 사용하기는 어렵지만 차츰 실력이 붙을 것이다. 혹시 어려움이 있거나 궁금한 것이 있다면 나에게 문의하기 바란다.

이글은 Techit에 기고한 글입니다.