위즈군의 라이프로그
Reboot... Search /

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

2007.07.16 11:21
최근에 [집중] '월화수목금금금' 프로그래머의 현실 라는 뉴스를 보고, 글을 쓰다 보니 부족한 필력으로 인해 지저분해서 몇 개의 포스트로 나눠 쓰기로 했다.
프로그래밍을 시작한지 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의 현실과 제도에 대한 것입니다.
크짱 2007.07.16 12:27 신고 E / R
제가 보기엔 지금도 IT강국은 아닙니다, 지들 말로만 강국이지..
그리고 국내에 제대로된 기획자 거의 없습니다.
게다가 개발자가 뭘 해야 하는지 제대로 알고 있는 개발자도 드믈죠
위즈 2007.07.16 13:33 신고 E
제일 중요한 사람을 중요하게 생각 하지 않으면 앞으로의 IT 미래는 없을 거라고 생각 되네요.
진짜 개발자, 진짜 기획자를 키우기위한 제도적 보안이 필요 합니다.
프로채터 2007.07.16 12:56 신고 E / R
맞습니다... 10년전만해도 신랑감 후보 1위직업이었는데...
지금은 결혼정보회사 DB에 분류가 없어진걸로 알고있습니다.
프로그래머라고 하면 거절당한다고 하여... 사무직으로 되어있다고 하더군요...
참 비정한 현실입니다.. 반면 미국에서는 아직까지 5위건안에 계속 머물러있다고 하지요...
과연 대학에서 붕어빵처럼 졸업만 시킨다고 될일인지... 좀더 고민해야 할거 같습니다...
덕분에... 덩달아서 몸값은 떨어지고.. 사람은 오히려 구하기가 더 힘들고... 취업난은 더 심각해지고...
그나마 잘나갔던 모바일 분야도 최근들어서... 위축되고 있으니... 정말 심각현 현실이라고 밖에 생각되지 않네요...
제 후배들도... 보면 졸업하고 무조건 유학가라고 합니다... 아니면 휴학하고 어학연수 갔다오라고 버럭 우깁니다...
저도 영어를 더럽게 못하는데... 영어는 필수 인거 같군요... ㅠㅠ
위즈 2007.07.16 13:36 신고 E
요즘은 취업하기 힘들다고들 아우성이지만 정작 개발자 구하기는 하늘에 별따기 입니다.
개발자가 새로운 기피 1순위 직업이 될줄은 몰랐습니다.
비치 2007.07.16 16:39 신고 E / R
"설계" 부분을 기획자가할일 / 개발자가할일 을 명확하게 구분하여..
개발자에게 "개발자가 해야할 설계" 의 일정을 줘야 하는데..
이런케이스.. 보기 힘들죠..

+ 스킨 저랑 같은거네요 ^_^;
위즈 2007.07.16 18:16 신고 E
그렇죠. 명확하게 구분하기 힘들죠. 그렇게 해주지도 않고요.
제가 제작한 스킨입니다. 깔끔하게 사용하시네요.
비치님의 감각이 부럽습니다.
스킨을 이용해주셔서 감사합니다.^^
BKLove 2007.07.23 15:08 신고 E / R
반성과 생각을 많이 하게 하는 글이군요.
현실이 참...

저는 학교에서 전산학을 전공해서,
아주 협소하지만 약간의 개발 지식을 가지고 있으면서..
현실에서는 (초보) 기획자라는 직업을 가지고 있는데요.

신기한게, 내 상황이 '기획자'의 입장에 서게 되니까..
'개발'을 했을 때 그렇게 하지 말았으면 하는 일들을 제가 하게 되더군요.

지적해주신대로 현실이 가지고 있는 불합리한 상황의 문제이기도 하지만..
한편으로 더 꼼꼼하지 못한 제 잘못이기도 하고..

좋은 글 잘 읽었습니다.
위즈 2007.07.23 15:21 신고 E
형식에 매달리는 분위기 때문이 아닐까요?
앞으로 발전 할거라고 생각 합니다.^^
kaleidosco 2007.12.26 17:03 신고 E / R
좋은 글 잘 읽었습니다.
항상 개발자와 디자이너 분들의 현실에 대한 글은 주의깊게 읽고 있습니다.
저도 기획자이지만 지적해주신 오류에서 자유로울 수가 없다는 점이 부족한 저를 다시 일깨워줍니다.
앞으로 더 많이 노력해야겠습니다...

개발자/디자이너/기획자 이 3주체가 모두 기쁜 마음으로 일할 수 있도록 힘내야겠습니다...

아.. 그리고 "따뜻한 한 마디보다는 클릭 한 번이 더 도움이 된다."라는 말 주의깊게 새기도록 하겠습니다.
위즈 2007.12.28 00:25 신고 E
좋은 환경에서 모두가 윈윈 할 수 있는 날도 오겠죠!
님이 말하는건 2008.03.27 10:37 신고 E / R
코더 같습니다. 화면설계 아키텍팅 데이터베이스 스키마 설계
클래스 구조 설계
등은 좀더 숙력된 개발자가 진행하는 겁니다.
어려움은 그들의 능력에 있는게 아니라.. 사업주의 저속한 욕심과 그에 부합하지 않는
영업및 로비 이외의 다른 능력때문입니다.
위즈 2008.03.27 11:30 신고 E
색칠까지 해가면서 적어둔 내용을 안보셨군요.^^
그리고 아키텍쳐 설계나 DB 설계 등은 개발자가 하는게 아니예요. 국내에서는 아키텍쳐나 DBO등의 전문 직군을 인정하지 않아서 누군가해야 하는거구요.
또한 이 부분은 개발자 혼자하는 것은 더더욱 아닙니다. 기본은 비즈니스 로직에서 부터 같이 하는거지요.
2011.03.20 19:55 신고 E / R
대부분 공감이 갑니다.


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

이 부분에 대해서는..
기획자도 개발에 대해서 약간의 지식을 보유하고 있어야하고.. 완전 불가능한 기술이 아닐때, 분업이 확실히 된다는 가정하에!
조금 어려운 코딩이라도 가능하게 만드는게 프로그래머가 할 일이 아닌가 싶네요.

몇 천, 몇 만줄에 시간이 없을 수도 있지만 분업으로 조금 더 본업에 충실 할 수 있다면 어려운 기능 구현 또한 프로그래머의 사명인거 같습니다.
위즈 2011.04.10 03:10 신고 E
기획자와 개발자가 서로를 배려하는 아름다운 세상을 기대해 봅니다.^^
Name : Password : Blog : ( )

위즈군의 라이프로그

Category

전체 (569)
개발 (0)
정보 (0)
일상 (0)
정리중 (569)
Total:2,179,954
Today:69 / Yesterday:127
Daum 코드
Powered by Tistory / Skin by 위즈 / Copyright Click Here 라이센스정책 rss 2.0