프로그래머 죽이기 Chapter 1 프로그래머는 슈퍼맨이 아니다.

최근에 [집중] '월화수목금금금' 프로그래머의 현실 라는 뉴스를 보고, 글을 쓰다 보니 부족한 필력으로 인해 지저분해서 몇 개의 포스트로 나눠 쓰기로 했다.
프로그래밍을 시작한지 20년, 프로그래머라는 직업을 가지고 프로그래밍을 한지 7년, 그 시간만큼 쌓인 것도 느낀 것도 많기에 글을 써보기로 했다.

우리나라 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, 파트2는 기획자가 파트3는 개발자가 파트4은 테스터가 해야 하는 업무다. 각자 주어진 파트의 업무만 하면 좋겠지만 현실은 그렇지 않기에 이런 글을 쓰는 것이다. 개발자가 기획, 설계, 개발 및 테스트까지 참여하는 것이 국내 IT 업계의 실정이다.

수퍼맨 리턴즈 (Superman Returns, 2006) 영화정보 더보기미국 액션/SF/모험 전체 관람가 153분 개봉 2006.06.28 감독 :브라이언 싱어출연 :브랜던 라우스, 케이트 보스워스, 제임스 마스던, 프랭크 란젤라, 에바 마리 세인트

파트 1 기획 단계에서는 고객과 상담을 통한 문제점 파악도 있지만, 현 시스템의 문제점 파악, 기존 데이터의 구조 분석, 구현 가능 범위 및 현 장비 상황 등을 파악 하는 일도 있다. 해당 부분의 전문가가 없고, 기획자가 이런 내용을 모른다면(사실 대부분의 기획자에게 생소한 부분이다.) 슬쩍 개발자의 업무 목록에 추가된다.
심한 경우 개발 전에는 일이 없으니 기획자를 도와주라는 명목으로 참여하기도 한다.
이런 상황으로 개발자가 대부분의 기획 회의에 참가여하고, 시스템 파악 등의 업무를 전담 하게 된다.

관리자의 입장에서는 고객을 만나는 일이 중요하다.
많은 사람이 회의에 들어가는 것이 고객에게 전폭적인 지원을 하는 것으로 보이는 것도 인정한다.
초기단계에 힘들어지지 않고자 한다는 것은 알고 있다.

하지만 그 일은 관리자와 기획자의 일이지 개발자의 업무는 아니다. 이기적이라고 욕 할 수도 있지만 현실이 그렇다는 것이다. 개발 기간에 기획자, 관리자 누구도 도와 주지 못한다.
모듈 테스트 정도도 해주지 않는 것이 현실이다. 아주 나쁜 케이스는 이 기간에 놀지 않는 다는 것을 보여야 하는 다른 사람들은 개발자를 데리고 계속 회의 하고, 기획을 변경한다.

파트2 설계 단계에서는 명확하게 기획자의 역할이다. 사용자 UI 설계하고, 데이터 구조 설계, 클래스 설계, 아키텍처 구성, 비즈니스 프로세스의 구체화 등의 사항들을 구성하는 것이다.
DB 스키마 설계, 클래스 설계, 아키텍처를 구성해주는, 아니 할 줄 아는 기획자가 얼마나 될까? 그리고 이런 내용을 받아서 개발에 들어가는 개발자가 얼마나 될지 질문하고 싶다.
물론 문제가 있다. DB 설계, 클래스 설계 등등 개발자가 해야 할 일이다. 하지만 이 부분을 기획 및 설계라 하고, 개발자의 작업 시간으로 잡지 않는 다는 것이 중요하다. 대형 SI 프로젝트 등에서는 이 기간을 상당히 많이 잡아주고 있지만, 작은 프로젝트나 내부 프로젝트 등에서는 이런 기간이 개발 기간에 포함되는 것이 대부분이다.

파트3 개발 기간에는 위에서도 말한 것처럼 회의에 불려 다니느라, 낮에는 회의 저녁에 코딩 하는 것이 일상화 되어 버린다. 이렇게 일정이 늦어지면 주말에도 역시 홀로 나와 일하고, 밤샘작업을 하게 되는 것이다.

파트4 테스트 단계, 개발이 완료된 후 대부분의 프로젝트에 전문 테스트 담당이 없기 때문에 기획자와 프로그래머가 테스트를 하게 된다. 다른 사람들은 오류 보고만 하면 끝날지 모르지만, 개발자에게는 버그 수정이라는 추가적인 일이 있다. 이 오류보고서는 대부분 퇴근시간 2~30분전 혹은 금요일 오후에 도착하는 경우가 많다. 이로서 또 야근과 주말 근무다.

파트5 유지 보수, 이 역시 대부분 개발자의 일이다. 프로그램 오류와 기획 오류 모두 버그라는 이름으로 개발자에 수정을 요구한다. 기획의 실수 역시 개발자의 일이 되어 버리는 기간이다.

이렇게 명확하지 않은 업무 구분 때문에 낮에는 회의, 저녁에는 코딩 하는 식의 일과가 프로젝트 동안 계속 이어지게 되는 것이다. 프로그래머들 허리 안 아픈 사람 없고, 만성 피로에 지쳐있는 것이 사실일 것이다.

프로젝트 완료 후 휴가 준다고 하지만.. 과연 유지보수 라는 업무를 가지고 휴가를 갈 수 있을까? 유지보수 완료될 쯤이면 프로젝트 동안 힘들었던 기억은 이미 사라지고, 이미 다음 프로젝트가 눈앞에 기다리고 있다.

독일 수도 베를린에 위치한 안드레아스 벤트 미술관 앞에 독일 조각가 마커스 비트머스가 슈퍼맨을 희화해 만든 조형물

여기까지가 상황 설명 끝.
프로그래머 일 많이 한다. 하지만 하나하나 보면 기획서의 별첨자료, 일했다고 업무보고에 적기도 뭐한 작은 일들 단순 헬퍼의 역할 뿐이다. 나중에 이야기 하겠지만 이런 잡다한 일들을 많이 하면서도 인정받지 못하는 것이다.

기획자들과 이야기하다 보면 이런 말들을 많이 한다. "전에 일했던 개발자는 매일 놀면서 뭐 해달라고 하면 정말 안 해줘요.", "어떤 제안을 하면 전부 부정적이에요."
변명을 하자면 프로그램이란 몇 천에서부터 몇 십만 줄의 코드가 실수 없이 돌아가야 한다.
"몇 마디로 해주세요"에 연결되는 모든 부분을 생각하고, 테스트 해야 한다. 또한 뒤에 보이지 않는 일도 많기 때문이다. 그들이 놀고 싶어 그러는 것이 아니다.

프로그래머는 슈퍼맨이 아니다. 이렇게 몇 년 보내면 건강도 상하고, 가능 하면 일을 만들지 않으려는 것이다.
언제든 그만두고 떠날 준비를 하고, 사고만 없으면 그냥 버티려는 사람으로 변한다.
이렇게 몇 년 들어와 일하고, 떠나는 사람들로 부품 바꾸는 것처럼 프로그래머를 관리하면 단기간은 버텨도 앞으로의 IT 강국은 더 이상 없을 것이다.
구글, 마이크로소프트, 애플에서 대부분의 IT 분야에 뛰어들고 있는 상황이다. 언제 당신의 회사와 경쟁 상대가 될지 모르는 것이 현재 IT 업계라고 생각된다.

구글이 강한 이유 프로그래머의 천국이라 불릴 정도로 프로그래머에 대한 관리와 지원 때문이라고 생각 한다.

우리나라 IT 미래를 위한 간단한 실천항목
- 버그 리포트 등은 일찍 보내주세요. 개발자도 처리하고 퇴근해야죠.
- 개발기간에 모듈 테스트라도 해주세요. 따뜻한 한마디 보다 마우스 클릭 한번이 더큰 힘이 됩니다.
- 개발 기간 혹은 그 후에 기능 변경은 최소화 해주세요. 일이 커져요.
- 회의는 최대한 효율적으로, 업무 요청은 최대한 구체적으로 해주세요.

중요한 꼬리. 포스트를 쓰다 보니 개발자의 모든 어려움이 기획자 때문이고, 대한민국 기획자는 무능하다라고 말하는 것 처럼 흘렀습니다. 개발자의 어려움을 이야기 하다보니 자연스럽게 기획자랑 엮이네요. 대한민국에 훌륭한 기획자도 많고, 저도 때로는 기획자 롤을 가지고 일하는 입장입니다. 기획자분들 오해 하지 마세요.
제가 이야기 하고 싶은 것은 이런 상황을 만드는 대한민국 IT의 현실과 제도에 대한 것입니다.