프로그래머 죽이기 Chapter 3 잦은 스팩 수정

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

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

순서

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

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

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

잦은 스팩 수정 (기획서 한 줄 수정이 개발에 미치는 나비 효과를 이해하지 못한다.)

프로젝트 초기에는 모든 사람이 의욕적으로 많은 기능을 넣으려고 한다.
새로운 기술과 기능 그리고 최근 동향을 반영한 것들이 많을 수록 좋아 보이기 때문에 필요 없는 기능까지 모두 넣는다.
그러다 보니 각각의 모든 기능에 대한 이해도 없이, 포털 서비스를 변형해 스토리보드를 만들고 넘어간다.
요구사항 정의문서에 "XX기능(네이버 XX서비스 참조)" 라고 한 줄 들어가면 끝이지만, 설계와 개발에서는 그 기능을 개발하기 위해서 몇 일 혹은 몇 달을 고생해야 한다.

실제로 RFP에 들어간 1줄 "블로그 서비스" 라는 것 때문에 6개월 이상 프로젝트에 참여한 경우도 있다.

RFP (Request For Proposal [제안 의뢰서 提案依賴書])
하드웨어 및 소프트웨어를 취득할 때, 제조사에 제안서의 제출을 의뢰하기 위해 작성하는 서류, 또는 그 의뢰를 하는 것. -네이버 사전-

화성에서 온 기획자, 금성에서 온 개발자에서 빌려온 이미지 입니다.

기획과 설계단계에서는 실체가 잘 보이지 않기 때문에 "나중에 문제되면 수정하지" 하고 넘어가는 경우가 많지만, 그 때문에 고생하는 사람은 항상 프로그래머다. 이보다 더 중요한 것은 만약 문제가 될 것 같다면 초기에 문제를 해결하는 것이 맞는 것이다.
 
책을 쓰다가 목차를 정할 때 수정하는 것이 간단하지 본문을 열심히 쓰다가 문제가 발생하면 목차를 수정하는 것이 어려운 것과 같다.

개발자에게 기능을 수정해달라고 했을 경우 개발자가 까칠하다고 생각되고, 이를 이해할 수 없다고 생각되는 분은 아래 예를 주의 깊게 읽어보기 바란다.

만약 A와 B 그리고 이를 보조하는 기능 C를 만드는 경우, C에 대한 수정을 요구하면 당연히 A와 B에도 영향을 주게 된다. 단순하게 C 수정이 간단하다고 생각하기 쉽다. 하지만 구체적으로 들어가면 A의 서브기능, B의 서브기능 등이 한번에 변경되는 경우가 발생하기 때문에 변경의 양이 생각 보다 많다는 것이다. C의 기능 변경으로 인해서 개발자는 수십 가지를 수정하고, 테스트해야 하는 일이 발생하는 것이다.
일의 양도 문제지만, 더 큰 문제는 이로 인해 발생할 수 있는 오류와 버그를 한번에 찾아내기란 불가능하기 때문이다. 그리고 이 책임은 완벽하게 개발자의 개발오류라고 여겨지기 때문에 개발자들은 쉽게 고쳐준다고 말하지 못하는 것이다.

개발자가 까칠하다고들 말하지만 정말 심각한 문제가 발생했을 때 제일 먼저 불려가는 사람이 누구인지 살펴 보기 바란다. 가장먼저 개발담당자 일 것이다.

여기에 사용자 데이터까지 손을 대야 하는 상황이라면 문제는 더 심각하다. 이 경우 개발자들은 항상 공포로 떠는 것이 당연하다. 국내 기업 중에 별도로 DBA를 가진 기업도 없고, 개발자가 대부분 데이터를 관리하는 현실에서 “사용자 데이터를 날리지나 않을까?” 고민하고, 이에 대한 심리적 압박감은 상당하다는 것을 알고 있는지 모르겠다. 그리고 이는 완전히 프로그래머의 실수로 날아간 것이지만 사실 따지고 보면 이는 프로그래머의 일이 아닌 것 이다. 데이터가 중요한 서비스의 경우 DBA가 별도로 있는 것만 봐도 알 수 있는 것처럼 사용자 데이터를 건드리는 것은 심리적 부담감이 상당한 것이다. 그러니 프로그래머는 이처럼 정말 수정해야 하는 것인지 재차 확인 하려고 하는 것이다.

DBA (database administrator [데이터베이스 관리 책임자])
데이터베이스를 가장 좋은 상태로 관리하는 책임을 지는 개인 또는 집단. 데이터베이스 정보 내용의 정확성이나 통합성을 결정하고 데이터베이스의 내부 저장 구조와 접근 관리 대책을 결정하며, 데이터의 보안 대책을 수립하고 점검하는 등 데이터베이스의 성능을 감시하여 변화하는 요구에 대응하는 책임을 진다.

프로젝트에서 단계가 뒤로 갈 수록 언제나 관리해야 하는 양은 많아지게 되는 것이 당연하다. 각 단계의 모든 산출물은 앞 단계의 결과물을 기반으로 하고 있기 때문에 앞 단계가 변화되면 그에 연결된 모든 하위 단계가 변경되어야 한다.

영화 "나비효과"에서처럼 간단한 한가지를 바꾼 것으로 뒤에서는 많은 것이 변경되어야 한다는 것을 기억해줬으면 좋겠다.

그리고 해보고 안되면 말지 하는 생각은 정말 버려라. 그건 개발자를 정말 죽일 수도 있다.