[Software Spec Series 4] 스펙의 역할

소프트웨어 프로젝트에서 스펙의 역할을 알아보자.

모든 프로젝트 이해관계자가 사용, 프로젝트의 중심

스펙은 프로젝트의 모든 요구사항이 모이며 프로젝트의 중심이 되는 문서다. 프로젝트의 모든 이해관계자가 스펙을 참조하거나 작성에 참여한다. 스펙은 다시 여러 프로젝트 이해관계자들이 받아서 자신의 역할을 수행한다. 프로젝트에서 가장 중요한 문서 하나를 꼽으라고 하면 스펙이다.

(프로젝트의 모든 이해관계자가 참조해야 하는 SRS)

고객, 마케팅 부서, 영업 부서는 어떠한 제품이 만들어지는지 알 수 있다.

스펙이 없거나 부실한 상태로 진행하는 프로젝트는 프로젝트가 완료되기 전까지 어떠한 소프트웨어가 개발될지 알기가 어렵다. 그러면 영업부서는 소프트웨어 개발이 완료되기 이전에 판매 준비를 하거나 계약을 할 수가 없다. 스펙이 잘 작성된 프로젝트인 경우 스펙만 보고도 최종적으로 개발될 소프트웨어가 무엇인지 정확하게 알 수 있다. 영업부서에서는 이를 보고 판매에 필요한 준비를 할 수 있다. 영업망을 확충하거나 세일즈 자료를 준비할 수 있다. 또한 고객을 만나서 개발도 완료되지 않은 소프트웨어를 미리 팔 수도 있다. 소프트웨어 개발이 완료된 후에 부랴부랴 판매를 시작한다면 이미 상당한 판매 기회를 놓치게 된 것이다. 그 외에 안전, 의료, 보안 등의 인증이 필요한 경우도 스펙이 잘 작성되어 있다면 소프트웨어 개발이 완료되지 않았음에도 인증을 신청해서 인증을 미리 획득할 수 있다. 인증은 종류에 따라서 1년 넘게 또는 수년이 걸리기도 한다. 소프트웨어 개발이 완료된 후에서야 인증을 진행하면 수년의 영업 기회를 날려버릴 수도 있다.

프로젝트관리자(PM)에게는 스펙이 프로젝트 관리의 기준이 된다. 일정산정, 인력 배분, 리스크 분석 등을 할 수 있다.

스펙이 제대로 작성되지 않는 프로젝트에서 프로젝트 관리자는 별로 할 일이 없다. 일정을 제대로 예측하기도 어렵고, 리스크 파악도 어렵다. 적정한 리소스 계획을 세우지 못한다. 프로젝트가 진행이 되도 정확하게 진척률을 파악할 수가 없다. 그래서 1년짜리 프로젝트가 8개월쯤 지나도 정확하게 1년 안에 프로젝트가 종료될지 예측이 안된다. 그러면 프로젝트 관리자는 프로젝트 성공을 위해서 무엇을 더 해야 하는지 알 수 없다. 그저 운에 맡기는 수밖에 없다. 프로젝트의 성격에 따라서는 단계별로 진행을 하여 짧은 주기로 여러 차례 업그레이드를 하면서 진행하는 경우도 있다. 이 경우도 주기만 짧을 뿐이지 짧은 주기에 해당하는 스펙을 적절히 작성하는 것도 똑같이 필요하다.

개발팀은 스펙을 통해서 개발팀이 개발해야 할 제품이 무엇인지 정확하게 알 수 있다.

스펙을 제대로 작성하지 않았다면 개발팀은 정확하게 무엇을 개발해야 하는지 파악하기 어렵다. 기획자나 분석 아키텍트에게 너무 많은 것을 수시로 물어봐야 해서 시간을 매우 낭비해야 한다. 개발자가 임의대로 생각해서 기능을 구현하게 되면 기획의 의도와는 완전히 다르게 되기도 한다. 개발자에게 주어진 너무 높은 자유도가 소프트웨어 아키텍처를 부실하게 만들기도 한다. 개발자에게 자유도는 필요하지만 소프트웨어 전체 아키텍처는 분석, 설계 시에 정해져서 개발자에게는 한정된 자유도만 주어야 한다. 그래야 기획 시 의도된 소프트웨어가 제대로 개발될 수 있다.

(프로젝트에서 SRS의 위치)

테스트팀은 스펙을 통해서 테스트 계획 및 테스트 케이스를 작성할 수 있다.

보통은 스펙 작성 후에 개발자들이 구현을 하는 동안 테스트팀은 테스트 준비를 한다. 테스트 계획을 세우고 테스트 설계를 해야 한다. 하지만 스펙이 없거나 부실하다면 테스트팀은 테스트 준비를 제대로 할 수가 없다. 소프트웨어가 개발된 후에 소프트웨어를 보면서 테스트 준비를 해야 하는데 이 방법으로는 테스트 일정도 예측할 수 없고 부실한 테스트를 할 수 밖에 없다. 소프트웨어 품질이 나빠지는 것은 당연한 결과다.

기술문서팀은 스펙을 통해서 매뉴얼과 도움말을 작성할 수 있다.

소프트웨어 스펙이 완성된 후에는 많은 일들이 벌어진다. 기술문서팀은 소프트웨어를 동작시켜 보지도 않고 매뉴얼을 미리 작성한다. 단지 화면 캡쳐만 소프트웨어 개발 후 추가할 뿐이다. 이뿐만 아니다. 고객지원 부서는 고객 지원에 필요한 준비를 해 놓고 교육팀은 교육 준비를 한다. 이처럼 소프트웨어 스펙을 보고 많은 사람들이 자신의 일을 수행해야 하는데 바쁘다고 스펙 없이 개발을 하는 것은 개발자 중심의 사고방식이며 프로젝트가 효율적으로 진행되지도 않는다.

외주 업체는 스펙을 통해서 외주 업무를 정확하게 파악하고 SRS를 기준으로 계약을 할 수 있다.

우리나라에서는 많은 소프트웨어 프로젝트가 스펙도 없이 진행이 된다. 대략의 요구사항을 기반으로 계약하고 진행되는 프로젝트는 정상적으로 진행되기 어렵다. 고객이 수시로 요구사항을 무리하게 바꿔도 하소연하기 어렵다. 또한, 분석을 제대로 하지 않고 진행을 하므로 요구사항만으로는 프로젝트의 규모를 제대로 산정하기 어렵다. 그래서 계약 시는 성공적인 계약으로 생각되지만 프로젝트를 진행할수록 손해를 보는 경우도 허다하다. 우리나라도 스펙을 기준으로 계약을 하는 관행이 자리잡아야 한다.

share with abctech.software

[Software Spec Series 2] 소프트웨어 프로젝트 실패의 원인

우리 주변에서 실패한 소프트웨어 프로젝트를 보는 것은 어려운 일이 아니다. 프로젝트를 성공하는 방법을 배우기 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패하는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시하지 못했다.
• 소프트웨어가 요구되는 품질을 충족하지 못했다. (기능 요구사항, 성능, 안정성, 사용성, 확장성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자.

• 고객의 요구사항을 충분히 파악하지 못했다.
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당히 많은 시간을 소모하여 정작 개발 기간이 부족하게 되었다.
• 스펙과 설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 하였다.
• 작성된 스펙을 프로젝트 이해관계자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발하였다.
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어졌다.
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 하였다.
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작했다. 나중에 잘못된 코드를 고치느라고 시간이 더 소요되었다.
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕하느라고 시간을 많이 지체했다.
• 일정관리를 대충해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못했다.
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패했다.
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 했다.
• 프로젝트 팀원들의 팀워크에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트가 산으로 갔다.
• 도입한 외부 필수 기술이 기대처럼 동작하지 않았다. 이것을 프로젝트 막바지에 알게 되었다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못했다.
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해졌다.

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인은 “스펙”이다. 가장 많은 원인이 스펙과 관련이 있다. 또한 소프트웨어 버그의 절반 이상은 스펙으로부터 발생한다고 알려져 있다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가도 소프트웨어를 무사히 완성하기도 한다. 소수의 경험 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 찰떡 같이 알아듣고 개발을 잘하기도 한다. 하지만, 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 인수 테스트 계획이 필요하다.

소규모 프로젝트에서의 성공 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 반대로 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사에서는 이런 함정에 종종 빠진다. 개발은 문서대로 진행되지 않을 뿐만 아니라 문서가 너무 많아서 수시로 바뀌는 요구사항을 문서에 제대로 반영하지 못한다.

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 이해관계자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 소프트웨어 프로젝트 성공은 어렵다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다. 꾸준히 투자하는 방법 외에 기가 막힌 방법은 없다.

share with abctech.software

소프트웨어 프로젝트는 왜 실패하는가?

우리는 주변에서 실패한 소프트웨어 프로젝트를 보는 것이 그리 어려운 일은 아니다. 프로젝트의 규모가 커지고 기간이 길어지며 많은 인원이 투입될수록 프로젝트 실패 확률은 증가한다. 

프로젝트 성공을 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패했는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시 못했다.
• 소프트웨어가 시장에서 요구되는 품질을 충족하지 못했다. (요구사항, 성능, 안정성, 사용성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자. 

• 고객의 요구사항을 충분히 파악하지 못함
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당부분의 시간을 소모하여 개발 기간이 부족하게 됨
• 스펙/설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 함
• 작성된 스펙을 관련자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발함
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어짐
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 함
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작함. 나중에 잘못된 코드를 고치느라고 시간이 더 소요됨
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕함
• 일정관리를 대충 해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못함
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패함
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 함
• 프로젝트 팀원들의 팀웍에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트는 산으로 감
• 도입한 외부 필수 기술이 기대처럼 동작하지 않는다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못함
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해짐

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 간단히 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인을 “스펙"이라고 생각한다. 

다른 영역도 중요한 것이 사실이지만 스펙을 적는 것은 소프트웨어를 개발하는데 가장 중요하면서 가장 어렵다. 스펙을 적는 것을 “분석” 또는 “분석/설계”라고 한다. 설계가 여기에 왜 포함되었는지 의아한 사람도 있을 텐데, 분석 시에 상위 설계의 상당부분이 포함이 되는 경우가 많고 프로젝트에 따라서 다르지만 분석과 설계는 그 경계가 모호하기 때문에 같이 다루는 경우가 많다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가면서 소프트웨어가 무사히 완성을 하기도 한다. 소수의 경험이 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 개발을 잘하기도 한다. 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 테스트 문서도 전달하기도 한다.

소규모 프로젝트에서의 성공의 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사들에서는 이런 함정에 종종 빠진다. 개발은 문서대로 되지도 않을 뿐만 아니라 수시로 바뀌는 요구사항을 문서가 너무 많아서 문서에 반영도 제대로 못한다.

 

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 관련자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 말짱 공염불일 뿐이다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다.

이 방대한 얘기를 짧은 글로 어떻게 소개할 수 있을지 걱정은 되지만, 개발자가 어떻게 하면 소프트웨어 분석, 설계 역량을 가질 수 있으며 회사는 어떻게 그런 역량을 축적할 수 있는지 다음에 몇 개의 글을 통해서 조금 더 자세히 얘기를 해보고자 한다.

share with abctech.software

이우소프트에는 이것이 있다 vs. 없다

개발자 캐리어 보장이 있다.

• 개발자가 원하면 영원히 개발자로서의 경력을 보장해준다.
• 개발자에게 나이가 많다고 관리를 강요하거나 권유하지 않고 본인의 적성과 역량에 따라서 진로를 결정하면 된다.

남녀 차별이 없다.

• 남여에 따른 역할,대우의 차이가 전혀 없다.
• 100% 역량에 따른 차이 밖에 없다.
• 결혼, 육아에 따른 차별이 없다.

아키텍트가 있다.

• SW아키텍트가 있고 스펙, 설계와 기술적인 이슈 해결을 담당한다. 코딩도 한다.
• 무조건 고참이라고 아키텍트가 되는 것은 아니다.
• 아키텍트가 되기 위한 까다로운 자격을 충족해야 한다.
• 아키텍트는 사원부터 수석 연구원까지 있다.
• 여자 아키텍트도 있다.

관리만 하는 개발팀장이 없다.

• 개발팀장이 있기는 한데 휴가 결재가 하는 일의 대부분이다.
• 개발팀장은 Technical leader로서 개발만 잘하면 된다.

전문가가 있다.

• 자신의 일에 전문가가 되지 않으면 살아남을 수 없다.
• 하지만 전문가라면 의견이 존중되는 수평적인 조직이다.
• 비전문가가 감놔라 대추놔라 하지 못한다.

영어 이름이 있다.

• 모든 직원이 서로 영어 이름을 부르고 한국 이름은 사용이 금지되어 있다.
• 팀장님과 같은 직책으로 부르는 것도 금지되어 있다.
• 수평적인 생각을 정착하기 위해서 영어 이름을 사용하며 모두 동일한 존칭을 사용한다.

직급에 따른 서열이 없다.

• 개발자들은 직급이 아무것도 말해주지 않는다.
• 역량에 맞게 일을 분배하고 개발을 할 뿐이다.
• 아키텍트가 따로 있고 PM이 일을 분배할 뿐이다.

잔디밭이 있다.

• 8층 사무실 문을 열고 나가면 하늘 정원의 잔디밭이다.  
• 잔디밭에 누워서 햇볕을 쐬면서 머리를 식히자.

운동 시설이 있다.

• 체육관, GX, 웨이트 트레이닝, 골프 등의 시설이 직원들에게 제공된다.
• 건강관리를 위해서 꾸준히 운동을 할 것을 권장하며 여러 종목의 코치를 채용하여 운동을 지도하고 있다. 물론, 자기 계발과 운동을 할 수 있는 시간을 보장한다.

파티션이 없다.

• 파티션이 전혀 없이 책상들끼리 붙이 있다. 
• 모든 직원이 한눈에 보인다.

어린이집이 있다.

• 직원에게는 무료로 제공되는 어린이집이 있다.
• 출생 6개월부터 초등학교 입학 전까지 보육을 할 수 있다.
• 자녀와 같이 출퇴근을 할 수 있다.

회의록이 있다.

• 모든 회의가 하나도 빠짐없이 기록이 된다.
• 회의록은 거의 실시간으로 기록되고 모든 직원에게 공유된다.
• 회의에 참석하지 않은 사람도 언제든지 모든 회의록을 볼 수 있다.
• 그리고 결정된 사항은 모두 철저히 추적 관리가 된다.

코리안 타임이 없다.

• 회의시간이 1초도 늦는 직원은 없다.
• 1초라도 늦은 직원은 회의 참석자 전원에게 커피를 사야하고 2번째 늦을 때는 전직원에게 피자를 사야 한다.
• 커피는 얻어 먹었지만 아직 피자는 못얻어 먹었다. 언제 피자를 먹을 수 있을지 기다리고 있다.

전문 PM이 있다.

• 전문PM이 합리적으로 일정,리스크 등 프로젝트 관리를 한다.
• 억지를 부리지 않는다.
• 그렇게 해서 최단 시간에 프로젝트를 끝내고 있다.

일정 강요가 없다.

• 경영진이 말도 안되는 일정을 억지로 밀어붙이지 않는다.
• 1,2일 단위로 개발자가 산정하며 개발자가 예측한 일정을 다른 사람이 무시하지 않는다.
• 그래도 일정이 부족하면 PM은 온갖 방법을 동원해서 일정 단축 전술을 구사하고 그래도 부족하면 일정을 연기한다.
• 필요 시 일정은 구현 시작 전에 연기하므로 비즈니스 부서에서는 일정을 조율하는데 큰 문제가 없다.

몰입이 있다.

• 하루 8시간 업무에 완전히 몰입해야 한다.

야근이 없다.

• 강요된 야근이 없다.
• 일정을 합리적으로 결정하고 몰입해서 일해야 하기 때문에 야근이 필요 없다.
• 가끔 스스로 선택해서 야근을 하는 사람들이 있기는 하지만 강요는 없고 본인이 선택하는 것이다.
• 강요된 야근은 장기적으로 SW의 품질을 떨어뜨리고 기업 문화를 퇴보 시킨다.
• PM이 야근 카드를 꺼내는 경우는 정말 피치 못할 때이고 단기적으로 사용해야 한다.

스펙이 있다.

• 소프트웨어를 개발할 때는 항상 스펙을 작성한다.
• 큰 프로젝트는 SRS를 작성하고 작은 프로젝트나 프로토타입 개발 시에는 One-pager를 작성하다.
• SRS가 완료되면 모든 Stakeholder의 대표들이 서명을 한다.
• 프로젝트 계획은 스펙을 기초로 합리적으로 수립한다.
• 스펙은 변경되면 문서를 업데이트해서 최신 버전을 유지한다.

일정이 지연되는 프로젝트가 없다.

• 지연되는 프로젝트가 하나도 없다.
• 합리적인 일정 수립과 철저한 프로젝트 관리를 통해서 일정은 무조건 지킨다.
• 일정은 협력사와의 약속이므로 목숨처럼 지킨다.
• 출시 일정은 SRS가 끝날 때 확정한다.

60세 개발자가 있다.

• 나이는 개발자인지를 결정하는데 아무런 영향을 주지 않는다.

보고서가 없다.

• 개발자에게 보고서 강요가 없다. 주간보고도 없다.
• 개발자는 개발만 하면 된다.
• 문서는 개발문서만 쓰면 된다.

재택근무가 있다.

• 회사에서 자격을 부여한 개발자는 재택근무를 선택할 수 있다.
• 가끔 회사에 나와서 회의를 하고 커뮤니케이션은 거의 이슈관리시스템을 이용한다.

서울에도 스마트워크 센터가 있다.

• 본사에 동탄에 있는만큼 서울 북부 거주자 등 지역적인 어려움이 있는 직원들은 서울에 있는 스마트워크 센터에서 일할 수 있다.

E-mail이 없다.

• 모든 커뮤니케이션은 이슈관리시스템을 이용한다.
• E-mail은 주로 외부인과만 주고 받는다.
• 내부 모든 커뮤니케이션은 기록이 되고 공유가 되며 추적이 된다.

개발자에게는 가장 빠른 PC가 있다.

• 회사가 감당할 수 있는 한도 내에서 개발자에게 가장 빠른 PC를 지급한다.
• 빠른 CPU와 SSD를 장착하여 빌드 속도를 2배 빠르게 한다.
• 그만큼 개발자는 일을 더 많이 해야 한다. 그리고 정시 퇴근해라.

피어 리뷰가 있다.

• 개발자가 작성하는 코드 대부분을 리뷰한다. 리뷰를 통해서 버그를 찾고 공유, 학습을 한다.
• 더 중요한 것은 스펙, 설계 리뷰다.
• 개발자는 자신의 업무시간의 20%는 동료를 위한 리뷰에 사용해야 한다.
• 시니어 개발자는 20% 이상을 리뷰에 할애한다.

마시고 죽자는 회식이 없다.

• 원치 않는 음주 회식에 참여해서 끌려 다닐 필요가 없다.

즉석 라면이 있다.

• 회사 식당에서 제공하는 아침 메뉴 중에는 즉석 라면이 있다.
• 요리사가 별도로 맛을 낸 해장 라면을 즉석에서 끓여주고 충무김밥이 제공된다.

꼭 지켜야 하는 문화가 있다.

• 공유, 협업, 커뮤니케이션이 꼭 지켜야 하는 문화다.
• 공유와 협업을 철저히 하지 않으면 같이 일을 할 수 없다.

개발자 야근문화를 고쳐야 하는 이유

“월화수목금금금”은 지금도 회자되는 유명한 이야기다. 그리고 모 회사 대표는 신제품 발표회에서 개발기간 동안 개발자가 집에 못 들어가서 이혼을 했다고 자랑 아닌 자랑을 한적도 있다. 개발자들을 연구소에 가둬놓고 밖에서 자물쇠로 잠궈 놓고 주말에도 집에 못가게 했으며 기혼자만 일주일에 하루씩 집에 보내 줬다고 자랑을 하는 경영자도 있다.

자신이 직원들을 얼마나 혹사시켰는지 그렇게 자랑을 하는 이유를 모르겠다. 그래서 한국에서 개발자라는 직업이 유난히 인기가 없고 3D 직종으로 폄하를 하는 모양이다.

많은 경영진이 야근의 효과를 맹신하고 자랑하는 이유는 몇몇 전설적인 성과들이 실제로 있었기 때문이다. 또한 자신들도 초기에 그런 경험을 하기도 했다.

스타트업 초기에 모험심과 열정으로 빠른 시제품 제작과 시장 진입을 위해서 잠도 안자고 일을 하기도 하고 명확한 목표를 가진 어려운 프로젝트를 전직원이 끊임없는 도전을 통해서 결국에 성공을 해내는 기적적인 멋진 성공 스토리가 종종 있다. 여기서 공통점은 명확한 목표와 열정, 자발적인 노력이 있었다는 것이다. 물론 이렇게 해서 성공한 회사도 계속 그렇게는 못한다. 전력질주를 계속하며 마라톤을 할 수는 없다.

그럼에도 많은 경영자들이 야근의 효과를 맹신하는 이유는 야근 말고는 뚜렷한 성과측정 방법이나 생산성 향상 방법을 잘 모르기 때문이다. 세일즈는 숫자로 평가를 하기 때문에 쉽다. 하지만 개발조직은 개발자들이 노는지 열심히 하는지 알기가 어렵다. 개발자들의 프로젝트가 6개월 걸린다는 말도 믿기가 어렵다. 좀더 열심히 하면 4개월이면 끝낼 수 있을 것 같고 과거에도 그렇게 밀어 붙이니 개발 기간을 단축한 적이 있었기 때문에 무조건 압박을 하게 된다. 개발자들도 6개월 걸린다고 주장은 하는데 근거를 가지고 주장을 하지 못하기 때문에 경영자의 신뢰를 얻지는 못한다.

결국 경영자의 유일한 수단은 무조건 일정을 줄이고 직원들을 압박하는 것이다. 물론 압박이 단기적인 효과가 있는 것은 확실하다. 하지만 회사는 100m 달리기를 하고 있는 것이 아니고 마라톤을 하고 있는 것이다. 이를 아는 개발자는 일정을 미리 늘려서 말하곤 한다. 절대로 경영자가 이길 수 없는 싸움이다. 기업문화만 망가진다.

이런 야근 압박의 부작용은 매우 크다. 장기적으로 제품의 품질은 떨어지고 아키텍처는 엉망이 된다. 직원들의 창의력은 사라지고 사기는 저하되며 로열티는 없어진다. 직원들은 사생활을 포기해야 하며 자기계발을 못하고 소모품으로 전락하게 된다. 직원들이 현재 가지고 있는 것을 한 5년 뽑아먹다 보면 그냥 부품이 되어서 직원도 발전이 없고 회사의 미래도 불투명해진다.

소프트웨어는 '창의적인 지식 산업'이며 개발 조직은 '지식공동체'이다. 생산성이 근무시간에 비례를 하는 것도 아니다. 적정 근무 시간이 넘어 가면 생산성은 떨어진다. 공유와 협업에 신경 쓸 겨를이 없어지고 '지식공동체'가 무너져서 각자 따로 노는 조직이 되기 때문이다. 프로세스로 강제해서 '지식공동체'를 만들기는 어렵다. 그렇게 할수록 효율은 더 떨어진다.

SI나 용역을 주로 하는 회사나 재정이 악화되어서 억지로 버티는 회사는 지식 산업에서 점점 멀어지고 있고 단기 수익이 너무 중요하기 때문에 이런 얘기는 모두 공염불일 뿐이다.

야근을 줄이는 가장 좋은 방법은 업무를 계획적으로 하는 것이다. 필자가 CEO로 있는 이우소프트에서는 개발 계획을 세울 때 개발자는 하루에 6시간을 기준으로 계획을 세우며 매우 정확하게 일정을 수립하려고 노력한다. 고참 개발자는 하루 4시간을 기준으로 한다. 나머지 시간은 동료를 위한 시간이다. 스펙, 코드 리뷰도 하고 물어보면 답변도 해준다. 하루에 두뇌를 6시간 풀가동하는 것도 쉬운 일은 아니다. 설렁설렁 일하면 12시간도 가능하다. 물론 너무 재미있는 일이라면 18시간도 몰입할 수 있다. 필자도 어렸을 때는 프로그래밍 재미에 빠져서 하루 18시간씩 개발을 한 적도 있다. 하지만 보통의 경우는 하루 6시간 몰입도 쉽지 않다.

그리고 프로젝트 관리도 제대로 해야 한다. 프로젝트는 리스크(Risk)로 가득 찬 가시밭길이다. 수시로 터지는 리스크는 일정을 꼬이게 만들고 아키텍처를 엉망으로 만들기도 한다. 프로젝트 관리를 제대로 해서 프로젝트가 항상 통제 범위 안에 있어야 한다. 그래야 돌발적인 야근이 줄어 들며 프로젝트 성공 확률도 높아진다. 그리고 이 방법이 프로젝트를 가장 빨리 끝내는 방법이다. 그럼 직원들은 거의 매일 저녁 6시에 퇴근할 수 있다. 그럼 6시 이후에는 무엇을 해야 하나? 물론 6시 이후 시간은 직원의 자유지만 이우소프트에서는 6시 이후에 해야 할 것에 대해서 가이드를 하고 있다.

첫째는 자기계발이다. 영어공부, 운동 등을 규칙적으로 자기 발전을 위해 노력하기를 권장하며 미래의 업무에 필요한 지식 및 기술을 익혀야 한다. 학원을 등록했다가 수시로 발생하는 야근 때문에 포기하는 경우가 많다. 야근이 많은 회사에서는 무엇 하나 계획적으로 할 수가 없다. 무엇을 공부할지는 자율에 맡기기는 하지만 회사에서는 그 내용을 파악하고 상담, 관리, 지원하고 있다. 이것이 직원이 부품이 안되고 5년 후, 10년 후 더 발전된 모습이 되는 방법이다. 그래야 회사도 직원과 같이 발전할 수 있다. 건강을 유지하기 위한 운동은 회사에 피트니스 시설을 만들고 뛰어난 코치를 정직원으로 채용하여 골프, 요가/필라테스, 웨이트 트레이닝을 지원하고 있다.

둘째는 가능하면 가족과 시간을 보내기를 권장한다. 야근을 안했다고 친구들과 술 마시는데 시간을 보내는 것은 가급적 줄이고 가족과 시간을 많이 보내야 한다. 열심히 일하는 목적이 여기에 있기 때문에 굳이 이유가 무엇인지 설명할 필요가 없을 것이다. 회사에서 '이우아이'라는 어린이집을 운영하고 있어서 초등학교 이전까지는 회사에서 보육을 최대한 도와준다.

회사에서 철저히 관리를 하는 것은 프로젝트다. 정해진 시간 안에 프로젝트 목표는 꼭 달성을 해야 한다. 그 외 개발자들의 활동은 회사에서 거의 통제하지 않는다. 스스로 일을 찾고, 만들고, 준비도 한다. 시키는 일만 하는 소수의 직원도 있지만 대부분은 시간과 장소를 가리지 않고 스스로 뭔가를 찾아서 한다. 물론 그 내용은 대부분 공유가 된다. 야근의 유무는 무의미하고 직원의 자율성과 로열티를 높이는데 집중해야 한다.

야근을 100% 없애는 것은 불가능하며 그런 노력을 할 필요도 없다. 강요 없이 자율에 맡겨 놓으면 된다. 업무 절대 시간이 평가에 어떠한 영향도 주지 않는다는 확신을 직원들에게 심어 줘야 한다. 야근 자체가 나쁘다, 좋다 말할 수 없다. 경영진의 야근에 대한 잘못된 맹신이 문제일 뿐이다. 야근을 없애야 하는 이유는 "우리 회사는 야근이 없는 멋진 회사에요"라는 우스운 얘기를 하기 위해서가 아니다. 습관적이고 강압적인 야근 문화의 부작용은 상상 외로 크며 회사의 경쟁력을 서서히 좀먹기 때문이다. 야근 자체가 화제도 문제도 안되는 자율적인 문화가 필요하다.

이 글은 ZDNet Korea와 바텍블로그에 게재되었습니다.