오늘도 밤을 세워야 하는 개발자 (야근 탈출)

옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다.

"개발자의 Output은 근무시간의 양에 비례한다."

말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다.

실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요.

이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다.

이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠.

이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일을 할 수는 없겠죠.

나는 "개발은 창의적인 작업으로 그 성과는 충분한 재충전에 나온다"고 믿고 있습니다.

그렇게 합리적인 시간에 개발을 하려면 소프트웨어 개발은 좀더 체계적이고 효과적으로 진행해야 합니다.

지금의 일반적인 경우처럼 일단 프로젝트를 시작해서 개발자들이 능력껏 그럭저럭 진행하는 방법으로는 또 개발자의 야근은 피할 수 없고, 별로 빠르게 끝나지도 제품의 품질이 좋지도 않게 됩니다.

그래서 소프트웨어 개발에 소프트웨어 공학을 적용하는 것이지요.

말은 거창한 것 같지만, 소프트웨어 공학이라는 것이 소프트웨어를 최소비용으로 최단기간에 개발하기 위한 온갖 방법들을 말하는 겁니다. 결코 교과서의 내용이 아니고 현실에서 수많은 회사들이 경험을 통해서 내려오는 방법이고 여러분들도 상당부분은 익히 알고 있는 방법들입니다. 이 블로그의 주제이기도 하고요.

다시 개발자들이 밤을 세지 않기 위한 방법으로 되돌아 와서 그 방법을 알아봅시다.

일단, 경영자의 인식이 바뀌어야 하는 것은 당연한 일인데, 어떻게 손을 델 수가 없는 일입니다.

그리고 나면 아래와 같이 개발자들과 프로젝트팀이 행할 수 있는 3가지 방법이 남습니다.

• 정확한 일정 예측
• 체계적인 개발 방법 
• 합리적인 일정 복구 

첫째, 정확한 일정 예측입니다. 이는 모순된 문장입니다. 어떻게 예측을 정확하게 하나요? 하지만 예측이란 그때 상황에서 최선을 다해 정확하게 예측을 해야지요. 

당연히 프로젝트가 시작하자마자 정확한 예측은 불가능합니다. 아직 스펙이 정해지지 않았거든요.

그래서 프로젝트가 시작할 때는 대충을 일정을 가지고 시작을 하다가 스펙 작성이 완료되면 스펙을 근거로 1,2일 단위의 정확한 WBS를 작성하여 소요일정과 투입인력을 따져서 프로젝트 일정을 작성해야 합니다.

회사의 모든 관련자들은 프로젝트가 시작할 때 정해진 일정을 진짜 일정으로 봐서는 안됩니다. 스펙 완료 후 작성된 일정을 진짜 일정으로 봐야지요. 이것을 당연히 이해 할 수 있어야 얘기가 되지요.

그리고도 일정은 개발중간에 지속적으로 점검하며 일정이 틀어지면 대응을 해야 합니다. 1,2일 단위로 작성된 일정은 조금만 늦어져도 금방 문제를 파악할 수 있습니다.

둘째, 체계적인 개발 방법입니다. 

이 부분은 책 한 권을 써도 될 만큼 많은 양이고 앞으로 블로그에서 지속적으로 다룰 내용이니 간단히 소개만 하겠습니다. Stage를 따라서 개발을 하거나, Daily Build를 하고, 소스코드관리/버그관리시스템을 사용하고, 피어리뷰/코드리뷰를 하고, 모든 이슈를 투명하게 Open하고, Build를 자동화하는 등 수많은 방법들을 당연히 사용해야 할 것 입니다.

셋째, 합리적인 일정 복구입니다.

프로젝트는 어쨌든 늦어지게 마련입니다.  

다음 그림을 보면 현재 프로젝트 진척이 계획보다 늦어지고 있습니다. 이럴 때 다음 4가지의 방법이 있습니다.

A. 더 낮은 우선순위의 요구사항은 다음 버전으로 연기한다. 

B. 개발자를 추가로 투입한다. 

C. 시간외 근무를 단기간 동안 강제로 시킨다. 

D. 일정을 연기하여 추가된 기능을 수용한다. 

여기서 대부분의 회사가 C를 주로 선택하고 가끔 B를 선택합니다.

C는 단기적으로는 효과가 있지만, 이 기간이 길어지면 별로 효과도 없을 뿐더러 개발자 사기만 떨어지고 회사의 경쟁력도 잃고 개발자도 잃게 되는 방법입니다. 

B는 효과가 거의 없는 것으로 익히 잘 알려져 있습니다. 프로젝트 후반에 개발자를 투입하는 것은 기존에 열심히 개발하고 있는 다른 개발자들에게 방해만 되는 경우가 허다합니다. 기존 개발자들은 이들을 가르치느라고 시간을 허비해야 하고, 새로 투입된 개발자는 별로 성능을 발휘하지 못하며 버그도 많이 만들어내는 경우가 허다합니다.

프로젝트가 늦어지고 있는지 전혀 신경을 쓰지 않다가 프로젝트 막바지에 가서야 한참 늦어지고 있다는 보고를 받고 부랴부랴 대책을 세울 때 선택하는 방법이죠.

가장 좋은 방법은 A입니다.

여기서 중요한 점은 모든 프로젝트를 시작할 때 프로젝트가 늦어질 수 있다는 것을 미리 생각해야 한다는 것입니다.

그래서 스펙의 각 기능은 Priority(우선순위)를 정해줘야 합니다. 그래서 일정이 늦어지면 우순선위가 낮은 기능을 연기하고 프로젝트를 종료하는 것입니다. 그러기 위해서는 개발 순서도 우선순위가 높은 기능부터 개발이 진행되어야 합니다.

이러한 모든 것들이 체계적으로 합리적으로 진행이 되어야 중요한 프로젝트를 하더라도 퇴근 후에 가족과 식사를 하고 아이들과 놀 수 있는 시간이 생깁니다.

위와 같이 합리적이고 체계적인 절차에 의한 데이터를 근거로 경영층에 보고가 되고 투명한 개발진행이 경영층에 신뢰를 준다면 하루 8시간 근무하는 날이 점점 늘어 날 수 있을 것입니다.

개발자 혼자서 할 수 있는 일은 결코 아니고, 회사가 조직, 프로세스, 시스템등 모든 것이 바뀌어 나가야 가능한 일입니다.

이미지출처 : Microsoft Office Online

[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

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

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

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

툴, 시스템

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

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

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

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

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

문서 관리

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

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

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

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

문서 작성 역량

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

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

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

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

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

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

보고

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

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

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

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

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

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

화상 회의 빈도

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

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

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

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

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

회의 결과 관리

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

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

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

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

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

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

메신저 사용

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

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

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

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

업무 만족도

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

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

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

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

재택근무 가능 여부

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

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

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

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

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

Hotfix에서의 소스코드관리

아래 글에 차우차우님께서 Hotfix에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다.

2010/05/03 - [기반시스템/소스코드관리] - 혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까?

차우차우

2010/05/03 22:49

좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.

우선 Hotfix의 정의부터 알아봅시다. 회사마다 용어는 조금씩 다르게 쓰고 있으니 절대적인 정의는 아닙니다.

Hotfix란 "미리 계획되지 않은 긴급한 패치"를 말합니다.

계획된 일정이라는 것이 1년전부터 계획된 것인지 1주일된 계획인지는 회사마다 상황마다 다르고 Hotfix의 긴급도도 10분안에 해결을 해야 하는지 1주일 안에 해결해야 하는지 또 다릅니다. 하지만 이렇게 계획되지 않았지만 긴급하게 수정을 해야 하는 것을 hotfix라고 합니다.

일반적으로 Crash, Block, Security 이슈등으로 긴급하게 Hotfix를 내보냅니다.

Crash란 프로세스가 멈추거나 Database를 망가뜨려 시스템에 더이상 동작되지 않거나 데이터가 파손되는 상태를 말합니다.

Block은 설치가 안되거나 로그인이 안되는 등의 장애로 아무런 일도 못하는 상황을 말합니다. 

Security이슈는 보안에 문제가 생겨서 외부의 침입이 발생하고 있거나 위험한 상황을 말합니다.

여기서 Hotfix의 긴급성에 대해서 얘기를 하는 이유는 수많은 회사들이 긴급하지도 않은 버그(이슈, 기능)을 해결하고 Hotfix 형태로 릴리즈하는 것이 관행화되어 있기 때문입니다. 즉, Patch 일정을 계획하여 진행하지고 않고 그날 그날 개발자가 버그 수정해서 빌드한 후 그냥 고객에게 전달하거나 업데이트 서버에 올리는 것이지요.

그럼 Hotfix와 정식 패치의 차이점은 무엇인지 알아보죠.

Hotfix	정식 Patch
계획되지 않은 긴급한 패치 보통 충분히 테스트 되지 않고 릴리즈 또다른 문제를 일으킬 가능성이 매우 높음 다른 개발일정에 영향을 줌 고객은 수정된 버전을 바로 받아볼 수 있음	미리 계획됨 계획된 테스트를 수행하고 릴리즈 일상적인 수준의 리스크를 가지고 있음 계획된 일정대로 개발이 가능 고객은 개발사의 일정을 기다려야 함

즉 Hotfix 상황이 아닌데 Hotfix처럼 릴리즈를 하는 것은 정식 Patch의 장점은 모두 버리고 단점만 취하게 되는 겁니다. 유일한 장점은 고객이 개발사에 오전에 전화를 하면 오후에 새로운 버전을 보내준다는 것인데, 이것이 고객에게 장점일지는 생각해 봐야 합니다.

매일 정식 Patch를 내거나 하루에 몇차례 정식패치를 내는 회사도 있습니다. 대표적인 예가 Anti-virus 회사입니다. 이렇게 매일 릴리즈를 해도 정식 계획을 가지고 테스트를 수행하면서 릴리즈를 합니다. 따라서 매일 패치를 내보낸다고 Hotfix는 아닙니다.

개발사는 소프트웨어의 릴리즈 일정을 계획하여 진행을 해야 개발 일정을 안정적으로 가져갈 수 있으며 소프트웨어의 품질 수준을 일정하게 유지할 수 있습니다. 그렇지 않고 호떡집에 불난 모양으로 문제가 생기면 언제나 Fire fighting mode로 개발자가 알아서 불끄고 배포하고 하면 일정도 계획하기 어렵고 개발자들은 항상 야근에 시달리면서도 항상 품질 리스크를 안고 있으며 툭하면 더 큰 폭탄이 터지곤 합니다.

정식 패치 일정은 회사마다 다르므로 성격에 맞게 정의를 해야 합니다. 정식 패치 일정을 계획하여 실천하는데 최대의 "적"은 영업부서입니다. 영업부서에서는 이러한 Hotfix의 위험성을 잘 모르기 때문에 고객의 요구는 바로 들어주기를 원합니다. 따라서 정식 패치 일정은 회사의 규정으로써 정의를 해 놔서 무조건 따르게 하는 것이 좋습니다.

또한, Hotfix를 결정하는 위원회를 두는 것이 좋습니다. 위원회라고 하니까 거창하지만 개발의 대표들과 영업의 대표가 참석을 하면 됩니다. 거기서 영업은 Hotfix의 필요성을 주장하고 개발은 Hotifx의 문제점을 주장합니다. 그래도 Hotfix가 무리하게 나가게 될 경우 나중에 생기는 문제점의 상당부분 영업에게 도의적인 책임이 돌아가게 됩니다. 하지만 이러한 논의도 없이 그냥 Hotifx가 나가고 문제가 생기면 항상 모든 것은 개발자들이 독박을 쓰게 되어 있습니다.

Hotfix 소스코드관리

일단 Hotfix에 대해서 설명을 하느라고 사설이 길었습니다. 이제부터 Hotfix를 내보낼 때 소스코드 관리를 어떻게 하는 것이 좋을지 설명하도록 하겠습니다.

질문은 크게 두가지입니다.

1. 새 Hotfix에 기존 Hotfix를 포함해야 하는지?

2. Hotfix도 태깅을 해야 하는지?

정답을 먼저 말씀드리면 

1. 그때 그때 다르다.

2. Absolutely - 절대적으로

일단 2번이 답이 간단하므로 먼저 설명을 드리겠습니다. Tagging은 Baseline설정의 한 방법인데, 개발팀 바깥으로 나가는 모든 릴리즈는 Baseline이 설정되어야 합니다. 즉, 태깅이 되어야 합니다.

Baseline은 모든 변경의 기준선으로서 모든 릴리즈는 Baseline(태깅)으로 통제가 되어야 합니다.

그럼 개발팀 바깥이란 무엇일까요? 

테스트팀에게 테스트를 부탁하기 위해서 만들어 내는 빌드도 태깅을 해야 한다는 의미입니다.

이렇게 만들어진 버전은 버그 관리시스템에 등록이 되며 모든 버그, 이슈의 발생지의 이름이 되며 버그 수정의 기준이 됩니다. 

과거 CVS나 VSS등 1세대 소스코드 관리시스템은 Tagging(Label등)이 상당히 부담스러운 작업이었습니다. Tagging을 하면 소스코드를 그대로 복사를 하기 때문에 소스코드가 수백MB짜리 프로젝트를 할 때는 Tagging하는데 시간도 오래 걸렸고, 오래 쓰다보면 디스크 용량도 엄청나게 차지하곤 했습니다. 지금이야 Tera바이트 디스크를 쓰지만 과거에는 수백MB짜리 소스코드를 자주 태깅하는 것이 쉬운 일은 아니었습니다.

하지만 Subversion은 Tagging을 하는데 HDD 용량을 거의 쓰지 않습니다. 시간도 아무리 커다란 소스코드도 몇초면 끝납니다. 그래서 Tagging하는데 아무런 부담을 느낄 필요가 없습니다. 모든 정식빌드에 대해서 태그를 남길 수 있습니다. 여기서 말하는 정식 빌드란 개발자가 개발하면서 테스트를 하기 위해서 IDE(통합개발환경)에서 빌드하는 것을 제외한 공식적인 빌드를 말합니다. 엄밀히 말하면 공식빌드는 개발자의 일이 아니며 빌드팀의 업무입니다. 또한 별도의 빌드장비에서 이루어 집니다. 하지만 작은 회사라면 개발자가 겸업을 할 수는 있습니다. 그렇다고 하더라도 빌드장비는 필요합니다. 개발자 시스템은 더러운 환경(Dirty environment)이기 때문에 항상 일정한 빌드를 만들어 낼 수 있다는 보장이 없기 때문입니다. 개발자에게 이러한 일에 신경을 쓰게 하는 것보다 시스템을 하나 사주는 것이 훨씬 비용이 싸게 먹힙니다.

그럼 두번째 Hotfix간의 포함관계입니다.

Hotfix를 해야할만한 심각한 버그가 발생하면 Hotfix를 평가해야 합니다. 평가 항목은 다음과 같습니다.

1. 상세한 버그 내용
2. 버그에 영향을 받는 고객의 범위. 한 고객에게서만 발생한 것인지? 모든 고객에서 발생하는지?
3. 버그로 인해서 발생하는 고객의 예상 피해
4. 버그를 얼마나 빨리 해결해야 하는지
5. 고객의 피해로 인해서 발생하는 회사의 비즈니스적인 손해
6. 버그 수정에 투입해야 하는 인력 및 자원
7. 기존 개발일정에 미치는 영향

여기서 기술적으로 가장 신속하고 심각하게 고민해야 하는 것이 빨리 버그를 분석하여 광범위한 버그인지 특정 상황에서만 발생하는 버그인지 판단을 해야 합니다. 

Hotfix라는 것은 태생적으로 또다른 문제를 발생시킬 가능성이 대단히 높기 때문에 한 사이트에서만 발생하는 버그를 고치기 위해서 모든 고객에게 Risk가 있는 Hotfix를 배포하는 것은 좋지 않습니다. Hotfix가 미치는 범위는 가능하면 좁게 가져가는 것이 좋습니다.

이렇게 되면 결론은 나왔습니다. 

Hotfix들이 모든 고객이나 특정 고객 집단에서 광범위하게 발생한 것이라면 합쳐지는 것이 좋겠습니다.

그렇지 않고 소수의 고객에게만 서로 다르게 발생하는 문제라면 별도의 Hotfix를 만들어서 각각 배포를 하는 것이 좋겠습니다. 

또한 Hotfix를 배포한 후에 정식버전에 앞서 배포한 Hotfix를 모두 포함해야 하는지도 판단해봐야 합니다. 이또한 회사마다 상황이 다르기 때문에 입니다. 따라서 Hotfix를 일으킨 버그의 성격과 제품의 상황을 보고 판단해야 합니다.

소스코드관리시스템을 제대로 쓰지 않으면 이러한 여러 Hotfix의 관리도 불가능합니다. 하지만 소스코드관리시스템을 제대로만 사용한다면 매우 쉬운 일입니다.

Hotfix를 작성할 때 Branch및 Tag를 어떻게 만드는지 간단한 예입니다. Hotfix를 만들기 전에 Hotfix용 브랜치를 만든 후에 작업 완료후 Release할 때는 꼭 Tag를 만듭니다. 그리고 Hotfix간의 Merge는 Hotfix와 Trunk간의 Merge는 3Way Merge를 이용해서 거의 자동으로 할 수가 있습니다.

여기서는 소스코드관리시스템 관점으로만 설명을 했는 위의 모든 활동들이 버그관리시스템(이슈관리시스템)과 긴밀하게 연동이 되어서 진행이 되게 됩니다.

마무리

오늘 얘기 중에서 가장 중요한 메시지는 Hotfix는 함부로 남발하지 말자는 겁니다.

지금 모든 릴리즈를 Hotfix처럼 하고 있다면 Release 정책을 세워야 합니다. 

Hotfix남발은 비용이 더 많이 들뿐만 아니라 제품의 품질을 떨어뜨리고 개발자를 혹사하고 회사의 이미지도 깍아먹습니다. 영업이나 고객이 Hotfix에 너무 길들여져 있어서 바꾸기 어렵다면 정식 릴리즈 일정을 현재의 Hotfix일정과 비슷하게 가져가고 그 간격을 차차 정당한 수준으로 늘려가는 것이 좋습니다. 그래야 일주일에 몇번이라도 집에가서 식구들과 식사를 할 수 있지 않겠습니까?

소프트웨어공학은 실전이다.

이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다.

2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요.

알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스러웠다. 독자들은 알아서 판단하겠지만 혼란이 있을 수도 있어서 다시 한번 내 의견을 밝힌다.

나는 20년간 한국, 미국, 대기업, 벤처기업을 다 경험하고 이론과 실전을 다 경험하고 온 국민이 쓰는 소프트웨어 개발에도 다수 참여하고 수많은 소프트웨어 프로젝트를 성공시켰고 여러 소프트웨어의 회사의 역량 개선을 시키고 있고 이런 경험을 책(소프트웨어 개발의 모든 것)으로 쓰고 블로그를 통해서 공유하고 있다. 

소프트웨어 공학은 실전이다. 이론적으로 먼저 정립된 것이 아니라 실전적인 발전을 거듭해오다가 이론적인 정리가 된 것이다. 따라서 보편적인 이론과 원리가 있고 주장이 있으며 회사마다 그 응용이 있다. 물론 모든 회사의 응용이 효율적인 것은 아니다. 대부분의 우리나라 소프트웨어 회사들의 응용이 비 효율적인 이유는 그 원리를 모르고 응용만 해왔거나 스스로 방법을 생각해 냈기 때문에 한계가 있는 경우가 많다.

세상에는 수만가지 종류의 소프트웨어가 있고 그에 알맞는 라이프사이클도 약간씩 다르다. 다른 것이 잘못된 것은 아니다. 따라서 하나의 프로세스나 이론만 들이대고 이대로 따라하면 모든 소프트웨어에 알맞다고 주장하는 것은 틀릴 가능성이 매우 높다. 

이론서를 보거나 Wikipedia를 보더라도 "generally"라는 용어를 주로 사용하는 이유가 그것이다. 

알파, 베타라는 용어도 최초에 한사람이 이를 정의하고 모든 사람들이 이것을 따르라고 한 것이 아니다. IBM에서 최초로 A, B버전을 사용하였고 수많은 회사가 이런 용어를 따라했으며 Microsoft가 이후에 많은 영향을 미쳤으며 수많은 회사들이 이와 유사한 용어를 따라서 써오다보니 어느 정도 정립이 되었을 뿐이다. 각 회사의 프로세스 정의서에 알파, 베타에 대한 정의가 서로 다르며 이것이 틀린 것은 아니다.

제가 컨설팅했던 수많은 회사에서도 알파, 베타 버전의 용어가 비슷은 하지만 미묘하게 약간씩은 다르다. 회사마다 천차만별로 다른 것이 아니고 핵심적인 것은 비슷하지만 약간씩 다른 것이다. 이것이 틀린 것은 아니다. 회사마다 소프트웨어의 성격에 따라서 강조해야 하는 것이 다르고 프로세스가 다르다. 그렇다고 회사에서 개인마다 다르게 사용해서는 안된다. 회사내에서는 동일한 절차와 정의를 사용해야 한다. 회사마다 코딩컨벤션이 다른 것도 그 하나이다.

회사를 옮기면 그 회사의 조직, 프로세스, 규칙을 익혀야 한다. 대부분의 회사가 비슷한 프로세스와 정의를 사용하기 때문에 이를 익히는데 며칠도 걸리지 않는다. 대부분은 그냥 적응한다.

회사마다 다른 극단적인 예를 들면 5년이 걸리는 화상탐사선을 개발할 때와 간단한 Web application은 알파, 베타, RC를 다루는 방법이 다르다. 화성탐사선은 스펙이 완벽하게 정해지고 수정되는 법이 없고 스펙이 바뀐다면 엄청난 크로스체크와 절차가 필요하다. 하지만 간단한 Web application은 많이 다를 것이다.

모든 것은 어떻게 하면 소프트웨어를 가장 효율적으로 개발하느냐에 집중되어 있다. 소프트웨어의 성격에 따라서 회사의 조직, 프로세스, 시스템, 문화등이 비슷은 하지만 조금씩 달라진다. 어떻게 하면 효율적으로 개발할지 고민을 하다보니 여러 라이프사이클이 나오고 방법론도 매우 많다. 그 중에서 개발하는 소프트웨어에 가장 알맞는 방법을 선택해야 한다. 여기서 한가지만 옳다고 주장하는 것도 잘못된 것이지만 비효율적인 방법을 선택하는 것도 안좋다.

우리가 주의할 것은 하나의 경험이나 학습으로 세상의 모든 진리로 착각하면 안되겠다는 것이다. 그래서 나도 글을 쓸때 항상 조심하는 편이다. 또한 다른 사람의견에 빈정대거나 공격하지 않고 건설적인 토론을 하려고 노력한다. 하지만 대중을 상대로 하는 일이라 힘들때가 많다. 교양있는 여러분의 많은 경험을 같이 나누고 싶다.

외주 SW 개발의 비극

열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다. 

'갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한 댓가와 무리한 일정 그리고 부정확한 요구사항은 외주 개발을 점점 구렁텅이로 내몰고 있다.
소프트웨어 외주 개발 문제를 얘기하면 할 말이 많은 사람들이 꽤 있을 것이다. 필자는 그 중에서 접해 본 사례를 중심으로 소프트웨어 공학과개발 문화적으로 문제점을 지적해보고자 한다.

A사는 새로운 서비스를 시작하면서 서비스 개발을 야심차게 인도에 외주를 줬다가 큰 낭패를 봤다. 

지금도 왜 인도에 외주를 줬는지 궁금하지만 추측컨데 실리콘밸리 외주 형태를 흉내를 낸 것이 아닌가 생각한다. 그런데 인도 개발사는 개발 완료 후 L사에서 기대한 것과 전혀 다른 것을 전달해왔다. 프로토콜도 완전히 다른 것이고 도저히 서비스에 사용할 수 있는 상황이 아니었다. 

이런 일이 벌어진 가장 큰 이유는 스펙을 제대로 전달하지 않았기 때문이다. 인도 개발사에 전달된 스펙은 간단한 기획서 수준이었고 프로토콜도 제대로 언급하지 않았다. 게다가 인도 개발사가 소프트웨어를 완성해서 전달할 때까지 중간에 제대로 점검을 하지 않았다. 

한국 업체 같으면 억지를 부려서 잔금을 안주면서 다시 개발을 강요 했겠지만 인도 개발사는 계약대로 개발을 했고 억지는 통하지 않았다. 잔금을 안줄 수는 없었다. 결국 인도 개발사가 개발한 소프트웨어는 모두 버리고 다급하게 한국업체를 통해서 다시 개발을 했다. 돈은 돈대로 더 들고 서비스도 뒤죽박죽이 되었다. 

B사는 1년이 넘는 꽤 긴 프로젝트를 제대로 된 스펙도 없이 외주를 주고 고치기를 반복한다. 

외주 개발사에는 핵심 기능을 정리한 한 두 페이지 정도의 요구 사항 문서가 전달된다. 외주 개발사는 전체 프로젝트 기간 중 20~30% 정도 기간 안에 소프트웨어를 만들어 보여줘야 한다. 남은 70~80% 기간은 B사의 요구대로 거의 매일 소프트웨어를 수정하고 보여주기를 반복해야 한다.

외주 개발사는 해당 분야의 전문 회사라 이런 부정확한 요구사항으로도 대충 B사가 원하는 것을 이해해 개발할 수 있었다. 개발사의 PM은 수시로 고객사에 불려가 요구사항 변경 회의를 해야 했고 소프트웨어를 계속 고쳐나가기 때문에 아키텍처를 제대로 유지하기가 어려웠다. 

심지어 막판에 요구사항이 크게 바뀌어서 다 버리고 다시 만드는 일도 발생했다. 외주 개발사는 비용도 과도하게 투입해야 하고 프로젝트 관리를 제대로 하기도 어렵다. 하지만 B사가 가장 큰 고객이므로 시키는 대로 할 수 밖에 없었다. B사는 이런 식으로 프로젝트를 진행하는 것을 아직도 당연하게 생각한다.

C사와 D사는 소프트웨어 개발 외주가 제대로 진행이 안돼 외주사 개발자를 회사 내부에 앉혀 놓고 같이 개발하는 형태로 개발을 한다. 

외주 프로젝트지만 옆에서 같이 개발하지 않으면 제대로 개발이 안되기 때문에 같이 일해야 한다. 옆에 앉혀 놓고 개발한다 뿐이지 개발 방식은 다른 외주와 별반 다를 바가 없다. 요구사항은 계속 변하고 애써 작성한 코드를 버리고 고치기를 반복해야 한다. 

외주사도 이런 방식이 비효율적이라서 원하지 않지만 고객사의 우월한 지위를 꺽을 수가 없고 이렇게 일하다 보니 외주 개발 내용 외에 그냥 직원처럼 부림을 당하는 경우가 많이 발생한다. 

D사는 외주를 줬다가 소스코드가 없어져서 소프트웨어를 버려야 했다. 

D사는 소스코드를 받을 수 없는 외주 계약으로 개발을 했다. 처음 몇 년은 유지보수를 잘 했지만 몇 년 후 외주 개발사는 망해서 없어졌다. 그 과정에서 소스코드가 D사로 제대로 전달되지 않아서 최신 소스코드를 찾을 수 없는 상황이 되었다. 결국 외주 개발한 소프트웨어는 모두 버리고 다시 개발해야 하는 상황이 되었다.

E사는 개발자가 해야 할 개발자 테스트를 외주업체에 맡긴다.

개발자는 열심히 코딩만 하고 옆에 앉아서 외주개발자가 기본적인 개발자 테스트를 해준다. 속된 말로 '따까리'라는 말이 적합하다. 비싼 자사 개발자가 너무 바쁘기 때문에 그렇게 한다고는 하지만 자칫하면 잘못된 개발 습관이 쌓일 수 있다. 

또한 이렇게 해서는 코드 품질을 보장하기 어렵다. 완벽한 로직의 코드인지는 개발자 본인이 가장 잘 확인 할 수 있는데 대충 만들고 발견된 문제만 해결하는 방식이 습관화 될 수도 있다. 개발자는 완벽한 소스코드를 적는데 최선을 다해야 하는데 이런 개발자의 의무를 망각하면 프로그래밍은 기초부터 흔들리게 된다. 

위에서 살펴 볼 수 있듯 외주 문제의 주된 원인은 부실한 스펙이다. 모호한 요구사항 정도로 계약을 하게 되니 중간에 요구사항이 계속 바뀌어도 어쩔 수 없고 프로젝트 종료 기준도 모호하여 담당자 맘에 안들면 잔금을 받기도 어렵다. 소송도 종종 일어나지만 시간도 오래 걸리고 소송을 해도 해결하기 쉽지 않다. 고객이 대기업인 경우 소송을 하기도 쉽지 않다. 스펙을 제대로 적는 것은 소프트웨어를 개발하는데 있어서 가장 어려운 일이기 때문에 한마디로 설명할 수는 없다. 

소프트웨어를 직접 개발하지 않고 외주 개발을 하는 주된 이유는 다음과 같다. 직접 개발할 수는 있는데 내부 인력이 부족할 때와 특정 요소기술을 내부에서 보유하고 있지 않을 경우다. 내부에서 개발할 수 없을 만큼 잘 모를 때는 외주를 주기도 어렵다. 모르는 상태에서 대충 외주를 주면 원하는 결과를 얻기도 어렵고 분쟁이 일어나기 쉽다. 

기술력이 뛰어나거나 전문 기술을 가지고 있는 외주 개발사와 협업을 잘하는 것은 소프트웨어 생태계를 만드는데 아주 중요하다. 제대로 외주를 주기 위해서는 고객도 스펙을 제대로 적을 수 있을 만큼 잘 알아야 한다. 

부품 업체 다 망하고 나면 자동차 회사도 망하듯이 수많은 전문 소프트웨어 회사들이 망하고 나면 우리나라 소프트웨어 업계도 망하는 것이당연한 수순이다. 대만이 자전거 산업에서 세계를 호령하는 이유는 자전거 부품회사와 꾸준히 상생을 해와서 대만에는 뛰어난 자전거 부품회사가 많기 때문이다. 그에 비해서 생산비 절감에만 몰두한 우리나라 자전거 산업은 전세계 자전거 산업에서 명함도 못 내밀고 있다. 이미 많은 중소 소프트웨어 회사들이 사라졌거나 고사 상태인 지금 자전거 산업과 비슷한 미래가 예상되는 것은 안타까운 일이 아닐 수 없다. 

이제 와서 말로만 베풀듯이 상생이라고 외치는 것은 들을 때마다 거북하고 막상 그 내용도 해결책의 핵심은 아니다. 우리나라에서 소프트웨어 개발이 3D라는 인식에서 벗어나라면 이런 열악한 외주 환경이 바뀌지 않으면 안된다. 

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

비대면 소프트웨어 개발에 가장 중요한 문서는?

 코로나19로 인해 전세계적으로 비대면 업무 방식이 확대되고 있고 소프트웨어 개발도 비대면 개발 방식이 크게 요구되고 있다. 비대면 업무 방식은 업무 효율성 증대와 생산성 향상에 기여를 하기 때문에 코로나19가 아니라도 도입이 필요하다.

글로벌 소프트웨어 회사인 깃랩은 코로나 이전에도 1300명 전직원이 재택근무를 했고, 구글이나 페이스북 같은 글로벌 소프트웨어 회사도 코로나19 이전부터 상당수의 직원이 풀타임 재택 근무를 수행했고, 현재는 재택 근무를 대대적으로 확대하고 있으며 앞으로 전면 재택 근무로 전환하겠다고 하는 회사도 많다. 이렇게 할 수 있는 이유는 이전부터 비대면 개발이 가능한 형태로 일을 해왔기 때문이다.

비대면 소프트웨어 개발을 위해서는 시스템, 프로세스, 문서, 문화 등 여러가지를 갖추고 있어야 한다. 이중에서 문서는 얘기를 해보려고 한다. 소프트웨어를 개발할 때 프로젝트에 따라서 다르지만 여러가지 문서를 작성한다. 이중에서 비대면 개발을 위해서 가장 필요한 문서는 무엇일까?

비대면 개발에 가장 중요한 문서는 스펙

필자가 생각하는 가장 중요한 문서는 “스펙”이다.

“스펙”은 비대면 개발을 위해서만 필요한 것이 아니고 소프트웨어 개발 전체에 가장 핵심적인 문서이다.

과거 80년대 전세계적인 소프트웨어 위기를 극복하기 위해 소프트웨어 공학이 급속히 발전하면서 소프트웨어 프로젝트 성공을 위해서 가장 중요한 요소로 “스펙”을 꼽았다.

2000년 이후 우리나라의 수많은 대기업들이 글로벌 회사로 성장하면서도 소프트웨어 개발의 문제를 겪으면서, 방법론, 프로세스, 고가의 툴 등을 도입하면서 문제를 해결하려고 했으나, 기대만큼 문제를 해결하지 못했고, 몇몇 회사들은 “스펙”의 중요성을 인식하고 “스펙” 작성 역량에 투자를 하고 있다.

많은 회사들이 소프트웨어를 개발할 때 대략의 요구사항을 가지고 개발자들이 밀접히 접촉하여 의논하면서 소프트웨어를 개발한다. “스펙” 문서를 주고, 자신이 담당한 부분을 나눠서 멀리 떨어진 장소에서 일할 수 있는 회사는 그렇게 많지 않다. 이유는 “스펙” 문서를 제대로 작성하지 못하기 때문이다.

애자일이나 스크럼 방식으로 개발을 하는 경우 과거처럼 “스펙” 문서는 필요 없다고도 하는데, 그렇지 않다. 방식만 다를 뿐이지 “스펙”은 필요하다.

다같이 모여서 개발을 한다면 수시로 의논하며, 조율하여 개발을 해나갈 수 있지만, 비대면 개발을 한다면 그렇게 할 수 없다. 자신이 개발할 부분이 명확하게 정의가 되어 있어야 서로 떨어져서 개발을 할 수 있다. 하지만 스펙 문서가 없이 개발하거나 대략의 요구사항을 가지고 서로 모여서 조율해가면서 개발하는 방식에 익숙한 대부분의 회사들은 비대면 개발을 할 수가 없다.

그럼 코로나 이전에도 1300명의 전직원이 재택근무를 하고 있는 깃랩이나, 수많은 직원이 집에서 일하고 있었던 구글이나 페이스북은 어떻게 진작에 비대면 개발을 광범위하게 수행하고 있었을까?

시스템, 프로세스, 문화, 문서 등 여러가지 요소가 있지만, 잘 작성한 스펙이 그중에서 중요한 역할을 한다. 코딩은 개발 단계에서 가장 많은 인원이 참여하는 단계다. 많은 개발자가 서로 떨어져서 일할 수 있도록 스펙을 잘 작성해서 공유하기 때문이다.

여기서 문제는 스펙을 잘 작성하는 것이 소프웨어 개발에서 가장 어려운 주제라는 것이다. 국내 많은 기업들이 소프트웨어 개발 역량을 글로벌 수준으로 끌어 올리는데 여전히 어려움을 겪고 있는 이유도 스펙 작성의 어려움이 한 요소로 작용하고 있다.

스펙 문서는 꼼꼼하게 모든 것을 방대하게 작성하는 것이 잘 작성하는 것도 아니고, 간단하게 작은 문서로 작성하는 것이 잘 작성하는 것도 아니다. 방대한 템플릿을 꼼꼼하게 채우는 것이 올바른 방법도 아니다.

스펙의 역할은 여러가지가 있지만, 개발자 관점에서는 스펙 문서를 보고 자신이 개발한 부분을 충분히 구현할 수 있을 정도가 되어야 한다.

잘 작성한 스펙 문서가 어떤 것인지는 칼럼에서 짧게 다룰 수 있는 주제는 아니다. 그래서 여기서 스펙 문서에 대해서는 구체적으로 자세히 설명하지는 않겠다.

거대한 방법론이나 소프트웨어 공학 이론에서도 소프트웨어 스펙을 작성하는 방법을 이론적으로 다루고 있고, 이를 따라하면 방대하고 복잡한 스펙을 작성해야 한다. 하지만 깃랩, 구글, 페이스북이 이런 방식을 따르고 있지 않다. 이론은 이론일뿐, 실전적인 방법으로 스펙을 작성하고 있다. 대부분의 회사는 이런 이론을 따라하다가는 백이면 백 실패한다.

스펙을 작성하는 방법은 피아노와 골프를 배우듯 실전적인 방법을 배워나가야 한다.

10배의 비용과 시간을 들여서 완벽하게 자세한 스펙문서를 작성할 수 있을지는 몰라도 대부분의 실제 프로젝트에서 그런 방법은 쓸모가 없다.

최소 비용으로 효과적으로 스펙을 작성하는 것이 실전적인 방법이다. 

스펙은 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위한 것

소프트웨어 프로젝트에서 스펙을 잘 작성하는 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위함이다.

그래서 거대 방법론에서 제안하는 수십가지의 문서를 작성하는 방법은 실전적인 프로젝트에서 효용성이 떨어진다. 많은 회사가 이 방법을 시도했다가 포기하거나 프로세스는 따르지만 정작 소프트웨어 문제를 해결하지 못한 상태가 계속 되곤 한다.

아직도 많은 회사들이 소프트웨어 개발에 문제를 가지고 있다. 대부분의 프로젝트는 계획된 일정에 끝내지 못한다. 그래서 계획된 사업 로드맵에 맞춰 제때 소프트웨어가 출시되지 못해서 많은 사업이 차질을 빚고 있다. 또한 출시된 소프트웨어는 여러가지 문제가 발생하고 유지보수에 어려움을 겪고 있다. 소프트웨어 회사의 사업을 영위하는데 큰 어려움을 주고 있는 것이다.

이러한 소프트웨어 문제를 해결하기 위해서는 소프트웨어 공학에서 언급하는 프로세스, 툴, 품질, 설계, 형상관리 등 여러가지가 다 필요하고 이러한 것들은 충분히 확보가 가능하다.

하지만 가장 근본적이고 어려운 “스펙"을 작성하는 역량을 확보하지만 않으면 넘을 수 없는 벽에 부딪히게 된다. 소프트웨어에 있어서 2류까지는 가능할지 몰라도 1류가 되기는 어렵다.

그래서 나는 기업들이 소프트웨어 문제를 해결하고 구글이나 페이스북과 같은 글로벌 수준의 소프트웨어 개발 역량을 확보하고 싶다면 개발자들이 스펙을 제대로 작성할 수 있는 역량을 확보할 수 있도록 해야 한다고 주장한다. 

스펙은 분석 아키텍트가 혼자서 스펙이라는 문서를 달랑 작성하면 되는 것이 아니다. 스펙을 제대로 작성한다는 것은 회사 전체가 같이 움직이는 것을 말한다. 모든 관련자가 요구사항을 충분히 수집에 협조하고, 여러 전문가가 참여를 하며 작성된 스펙 문서에 대해서 관련자들이 철저히 리뷰를 하고 변경관리도 제대로 해야 한다. 모든 직원들은 스펙 문서를 이해하고 읽고 이에 따라서 일할 수 있어야 하고, 개발자는 스펙 문서를 파악하고 떨어져서 개발을 할 수 있어야 한다. 이러한 관행을 갖추려면 많은 노력과 오랜 시간이 걸린다.

여기서 중요한 것은 방법론, 툴이 아니고 문화, 습관, 인식의 변화다. 또한 이런 것을 이끌려면 경영자의 강력한 의지도 중요하다. 몇년전 국내 S사에서 소프트웨어 역량의 근본적인 해결을 위해 내부에서 분석아키텍트를 양성하기 위한 노력을 시작했는데 이런 활동을 매우 긍정적으로 생각한다. 시간이 오래 걸리겠지만, 꾸준히 노력하면 글로벌 수준의 소프트웨어 역량을 갖추는데 중요한 발판이 될 것으로 생각한다.

대기업보다 움직이기 수월한 스타트업이나 중소기업은 노력여하에 따라서 스펙 작성 역량을 확보하기 더 용이하다. 소프트웨어 1류가 되고 싶다면 스펙에 관심을 가지고 스펙 역량을 확보해야 한다.