프로그래머 죽이기 Chapter 2 프로젝트 시간 단축과 업무 과부하

우리나라 IT 산업의 미래는 프로그래머에게 달려 있다.
최근 출시 한 iPhone은 강력한 S/W의 매력으로 소비자에게 어필하는 제품이라고 평가해본다. iPhone에 올라간 OS X같은 S/W 개발의 중심이 바로 프로그래머이다.
좋은 S/W를 만들고, S/W 산업 발전의 기본은 프로그래머를 잘 키워야 한다는 것이다.
IT업계를 떠나 다른 직업을 택하거나 해외 취업을 하는 것이 우리나라 프로그래머들의 현실이다. 과연 프로그래머들은 왜 우리나라 IT업계를 떠나는가?

프로그래머를 죽이는 것들, 하지만 아무도 생각 하지 않는 것에 대한 이야기다.

순서

프로그래머 죽이기 Chapter 1 프로그래머는 슈퍼맨이 아니다.
  - 명확한 업무 구분 없음 (프로그래머는 슈퍼맨이 아니다.)

프로그래머 죽이기 Chapter 2 프로젝트 시간 단축과 업무 과부하
  - 프로젝트 시간 단축과 업무 과부하 (테스트도 개발기간이다.)

프로그래머 죽이기 Chapter 3 잦은 스팩 수정
  - 잦은 스팩 수정 (기획서 한 줄 수정이 개발에 미치는 나비 효과를 이해하지 못한다.)

프로젝트 시간 단축과 업무 과부하 (테스트도 개발기간이다.)

프로젝트를 크게 5 단계로 나눠보면 다음과 같다.
파트1. 요구사항 파악 및 기획
파트2. 설계
파트3. 개발
파트4. 테스트
파트5. 유지보수

프로젝트 진행에서 가장 중요한 것은 아마도 프로젝트 기간문제 일 것이다. 클라이언트나 프로젝트 최고 책임자 입장은 기간 단축이 이익과 직결되고, 가장 큰 성과로 평가 되기 때문이다. 그래서 항상 프로젝트 기간을 단축시키려고 하고, 이로 인해 개발자의 업무에는 항상 과부하가 걸리게 된다. 줄어드는 기간이 프로그래머에게 미치는 압박을 단계별로 보자.

준비 단계
프로젝트 완료는 계약 사항에 언제나 언제까지 완료 한다 라고 명시되어 있지만, 기간을 얼마나 보장하는지는 잘 명시 하지 않고, 준비 단계에서 시간을 아무리 소비해도 프로젝트 완료 시간은 변경되지 않는 것이 업계에서 관행처럼 이루어진다.

실제 작업이 시작되는 시점은 계약의 세부사항 조절 등과 같은 협상 때문에 늦어진다.
부족한 인력은 프로젝트 계약 완료 후에 구하기 시작한다. (요즘 좋은 인력 구하는 것은 쉽지 않다.)
프로젝트를 위한 작업 환경 구축 등도 이때부터 이루어진다.
프로젝트 일정 이런 사항들을 포함하지 않고 있기 때문에 시작부터 이미 계획보다 늦어진 상황이다.

이렇게 프로젝트의 시작이 늦어지고, 총 작업 기간이 줄었어도, 완료 시점은 변경 불가다.
그럼 정확한 완료를 위해 각 단계별 기간을 조정해야 하는 상황이 되어 버린 것 이다.

설계단계
가장 심하게 기간이 줄어드는 부분이다. 설계는 중요하지 않기 때문에 파트1과 파트3에 조금씩 걸쳐서 진행하면 된다고 판단 후 과감하게 기간을 줄이는 경우가 많다.
관리자 입장에서 보면 설계 과정은 눈에 보이는 성과물이 없이 그저 산출물 몇 장 적어내면 된다고 생각하는 경향이 있다. 이것은 설계가 얼마나 중요한지 이해하고 있는 관리자가 거의 없기 때문이다.
실제 형식적인 산출물 제공에 대한 관행 또한 크게 한 몫하고 있다. 제대로 이해하고 설계문서를 작성하는 사람도 없고, 이걸 받아 활용하는 담당 개발자도 없기 때문이 아닐까? (여기에서 우리나라 개발 능력의 빈약함이 여지없이 들어난다.)

! 개인적 생각.
과연 왜 UML을 사용하고, 왜 CBD 방법론을 사용하는지도 모르면서 산출물은 CBD 방법론에 따른 산출물을 제출하라고 강요한다. 왜일까? 그렇게 해야 체계적으로 만들어진 프로젝트처럼 보이기 때문이다.

자기가 이해하지 못하고 만든 문서는 다른 누구도 이해하지 못하고, 혼란만 가중시키는 쓰레기일 뿐이다. 이런 쓰레기 문서는 프로젝트 시간만 잡아먹는 애물단지인 것이다. 바로 개발 산출물이 그렇다. 차라리 운영지침서, 혹은 간단한 실무 개발 설명서가 더 유용한 자료가 되는 것이 현실이다.

이렇게 설계단계가 부실하면 기획자도 개발자도 시간만 버리고, 프로젝트의 내용도 부실해질 수 밖에 없다.

개발단계
보통 개발 시간을 설계단계부터라고 생각한다. 프로젝트 상에 분명히 설계기간과 개발기간이 구분되어 있지만, 대부분 관리자는 개발은 설계기간부터 진행된 것으로 생각한다. (그만큼 설계기간에 대한 중요성을 인지 하지 못하고 있고, 명확히 구분하지 않기 때문이다.)

개발기간이라고 개발만 하는 것이 아니다. 개발자는 개발기간 동안에도 보고서 작성과 설계문서 수정 등의 작업이 동반된다. 개발하면서 설계를 개발에 맞춰 재구성 하는 것이다. 완벽하지 않은 설계를 가지고 개발을 진행하니 당연히 생기는 문제다.
(과연 설계문서는 왜 만드는 건지. 앞에서도 이야기 했지만 설계문서는 개발을 위한 도면이다. 설계단계에서 수정하면 종이에 몇 자 고치면 되지만, 개발에서 바뀌는 도면은 몇 배 이상의 노력이 드는 것이다.

테스트 단계
아직까지 처음에 잡아놓은 기간 동안 테스트를 진행해 본 기억이 없다.
처음부터 잘 만들면 테스트는 금방 끝낼 수 있다고 생각하지만, 부실한 설계와 개발에 맞춰 짜깁기 설계문서, 그때그때 바뀌는 요구사항에 따라 만들어진 프로그램이 개발 기간 안에 만들어지기는 불가능하다. 역시 테스트 기간에도 계속 개발은 진행되고, 아직 개발중인 부분을 해보고 "이거 안돼요!", "이건 이렇게 바꿔주세요!" 하루 종일 이런 말을 들으며 덜된 부분 진행하고, 수정사항까지 진행한다.

이쯤 되면 설계문서는 더 이상 업데이트 되지 않고, 개발과 수정이 병행해 진행된다.
 
이 기간 역시 개발자가 항상 일해야 하는 파트다. 개발자도 테스트를 하고, 늦어진 작업진행, 수정사항 변경, 버그 테스트 등 거의 죽음의 경지에 이른다.
개발자에게 가장 많은 과부하가 걸리는 파트다.

유지보수 기간
프로젝트가 끝났으니 쉰다고? 천만에 말씀.. 개발자는 이제부터 또 다른 레벨의 시작이다.
다들 맘 편히 프로젝트 끝냈다고 술 한잔 기울일 때 개발자는 노심초사 유지보수 인원으로 남겨지지 않을까 고민하고, 걱정한다.
유지보수는 언제나 개발자의 몫이다. 이제부터 기획 단계에서 잘못된 부분까지 욕먹고, 수정해야 하는 고난의 단계인 것이다. 어찌된 일인지 프로젝트의 결과물이 나오면 그때부터는 기획부터 개발, 운영까지 개발자의 책임이 되어버린다. 개발자는 정상적으로 운영될 때까지 혹은 유지보수 기간이 끝날 때까지 계속 모든 책임을 짊어지고, 욕먹고 일해야 하는 상황에 빠지게 된다. 심지어는 이 기간 후에도 항상 전화가 온다. 프로그래머들은 프로젝트 완료 후에도 전화벨소리 두려워하면서 지낸다. (대인기피증 생길 만 하다.)

프로젝트에서 개발자의 업무는 항상 후반부 작업이 될 수 밖에 없다.
기획 단계에서 조율에 문제가 있어도 뒤로 늘릴 수 있지만, 개발은 프로젝트 종료와 맞물려 있기 때문에 뒤로 늘릴 수 있는 여유가 없다. 벼랑 끝에서 일하는 기분이다. 그리고 너무 쉽게 책임을 뒤집어쓸 수 있는 부분이기도 하다.
군대에서 행군 할 때 앞에서 조금만 보폭을 바꿔도 가장 뒤에서는 죽을 힘을 다해 뛰어야 하는 상황과 같다.
항상 행군의 최후미에서 걷는 개발자는 이런 상황에서 지칠 수밖에 없다.

이렇게 개발자들을 끌고 간다면 10년 후에는 경력 개발자도 지쳐 떠나고, 상황을 파악한 신입 개발자도 없어질 것이다.
요즘 근무 시간이 명확하고, 안정적인 공무원이 가장 인기 직종이 된 것과 반대로 수당 없는 야근과 주말근무, 오래해 봐야 30대 중반이면 끝나는 프로그래머는 가장 기피하는 직종이 될 것이 뻔하다.

앞으로 10년 후 우리나라에 S/W 산업이 존재 할 수 있도록 지금부터 업계와 정부 차원의 준비가 필요 할 것이다.
과연 세계최고의 H/W 만들어 놓고, S/W 외국 개발자 불러다 개발해야 하는 상황이 올지도 모른다.

(H/W 개발자든 S/W 개발자든 현재 IT 업계의 모든 엔지니어에 해당하는 상황인 것 같다.)

이런 상황을 극복하기 위해서 가장 중요한 것을 정리해보면 아래와 같다.
- 형식적이고 불필요한 문서작업을 가능한 줄여라.
- 효과적이고 상세한 프로젝트 설계를 진행하라.
- 기획, 설계, 개발 업무의 범위를 명확히 하라.
- 책임소지에 대한 부분을 명확히 하라.
- 설계 완료 후 기능 추가 및 변경을 최소화 할 것.
- 사후관리에 대한 담당자 및 체계를 명확히 할 것.
- 충분한 테스트 기간을 가질 것
- 개발기간에 개발에 집중 할 수 있는 환경을 만들 것.