이 세상에 간단한 프로젝트는 없다.


제가 개발자이기 때문에 프로그램 개발쪽 상황을 비유로 이야기를 하겠습니다.

한 프로젝트가 끝나고 새 프로젝트를 시작할때 회사에선 가끔씩 저한테 인심 쓰듯이 간단한 프로젝트를 맡길때가 있습니다. 이전 프로젝트 때문에 고생했으니깐 간단한거 하나 하면서 쉬엄쉬엄 하라는 식으로 간단한 프로젝트를 시작할때가 있습니다.

하지만 이게 프로젝트 내용을 말만 들으면 제가 생각해도 간단한 프로젝트 입니다. 하지만 막상 프로젝트에 들어 가면 그렇지가 않습니다. 프로젝트 중반쯤 되면 슬슬 말이 바뀝니다. 팀장이나 그 이상에서 요구 사항이 하나씩 하나씩 늘어 납니다. 힘없는 직원이 어쩌겠습니까? 해야지...


그리고 다 하고 나서 고객과 만나서 필드 테스트를 하면 또 요구 사항이 생깁니다. 그러다 보면 처음 시작할땐 간단하던 프로젝트가 마지막이 되면 정말 복잡한 프로젝트가 됩니다. 어렵게 시작한 프로젝트 보다 더 스트레스가 쌓이고 코드도 엉망으로 짜집니다.

처음에 설계를 할때 간단한 내용에 맞추어 짰었는데 나중에 내용이 자꾸 늘어 나면 거기에 끼워 마추다 보니 프로젝트가 이상하게 되더군요. 스트레스도 훨씬 많이 받고 말이죠.

또 개발일정을 못맟추면 간단한 프로젝트인데 왜 일정을 못맟추냐고 한소리 듣습니다. 당연하지 않습니까? 개발일정 잡을때 간단하다고 생각했으니 짦게 잡은 것인데 중간에 자꾸 내용이 늘어 나면 그 개발일정을 지킬수가 있습니까. 그러니 또 밤을 새는 것입니다.

지금은 어느정도 개발 경력이 생겨 위에서 아무리 간단한 프로젝트라 해도 나중을 생각해서 일정도 잡고 설계도 하고 제가 알아서 기능도 넣고 그러는데 개발 초반때는 경험이 없으니 상사 말만 듣고 프로젝트를 진행하다 보니 이런 부분에서도 많으 스트레스를 받았습니다.

실예로 제가 모바일 게임 개발을 할때 외국 게임을 우리나라 폰에 맞게끔 포팅하는 작업을 했었는데 이게 은근히 손이 많이 가는 작업입니다. 하지만 위에서 간단하게 우리나라 폰에 설정값만 맞게끔 바꿔서 출시하자고 합니다. 그래서 그 말만 믿고 시작하면 말이 바뀝니다. 

우리나라 실정에 이런 저런 요소는 맞지 않으니 게임 내용을 좀 바꾸자고 말합니다. 그러다 몇가지 바꾸다 보면 프로젝트가 갑자기 중형 프로젝트로 바뀝니다. 일정이 계속 늘어 나면서 밤새는 날도 늘어 나더군요. 이런 경험을 몇번 했을때도 모바일게임 쪽에서만 이런 경우가 있는줄 알았는데 일반 웹이나 윈폼 개발쪽으로 넘어 와도 마찬가지더군요. 간단한게 간단하게 되는게 없었습니다.

그래서 몇번 이런일을 겪다 보니 "이 세상에 간단한 프로젝트는 없다." 라고 뼈져리게 느꼈습니다. 회사에서나 외부 업체 사람과 업무 얘기를 할때 간단한 프로젝트라고 얘기 하면 절대 믿지 않습니다. 그리고 그 회의 자리의 사람들과 좀 친하면 그 자리에서 간단한 프로젝트는 없다고 바로 얘기 하는 경우도 있습니다. 그러면 그 분들도 어느정도 수긍을 합니다.

제가 다닌 회사들이 그렇게 크지 않은 회사이다 보니 회사 업무 프로세스가 견고하지 않아 생기는 문제 인거 같기도 합니다. 제 글을 보시는 분중에 개발자분이 있으시다면 누가 간단한 프로젝트가 있다고 하면 일단 의심해보고 프로젝트 마지막 단계까지 상황을 생각해보고 결정을 내리시기 바랍니다.


PS. 이미지출처는 모르겠습니다. 제 글내용과 어울리는거 같아 가져 왔는데 문제가 되면 바로 삭제 하도록 하겠습니다.



신고
  1. xefiroth
    너무나 동감입니다. 요구사항은 언제나 추가되고 수정될 뿐이지요.
  2. 글을 읽고 그림을 보니 딱! 이해됩니다. 정말 간단한 프로젝트는 없는거 같아요. 저야 재주가 없어서 개발자의 입장이 되진 못하지만.. 좋은글 읽고 갑니다 :)
    • 2010.01.04 18:31 신고 [Edit/Del]
      감사합니다. ^^
      개발뿐만이 아니고 다른 종류의 프로젝트도 똑같을거라 생각합니다. 세상에 무슨 일이든 간단한건 없는거 같습니다.
  3. 저도 저 이미지 봤던거네요.. ^^
    그리고 MastmanBAN님의 글도 공감 100% 이고요..
    정말 간단한 프로젝트는 없습니다.

    심지어 남이 하다가 마무리 안하고 나간 프로젝트의 경우..
    "거의 다 된거라 이부분만 수정하면 된다." 고 하면서 맡기는 프로젝트도 최악입니다. --;;

    어떤 프로그램인지도 모르는 상태에서 심지어는 개발환경도 모르는 상황에서
    받아서 처리하는 경우..

    정말.. 때리고 싶어요.. --;;
    • 2010.01.04 18:28 신고 [Edit/Del]
      크... 맞습니다. 뒤치닥거리 하는것도 무지하게 짜증나죠. 상사의 말도 공감합니다. 거의 다된거라 이부분만 수정하면 되... 크... 이말에 여럿 죽어 나죠. ㅋㅋㅋ
      정말 정말 때리고 싶습니다. ^^
  4. 잘봤습니다.
    프로젝트가 쉽게 끝나지 않는 이유중에 발주처의 무개념 말바꾸기도 무시 못하죠.
    분명 a로 하라고 해놓고 준공일 다되서

    "어.. 이거 아닌데.."
    "그때 a로하라고 해서 요렇게 저렇게 했는데요."
    "얼마전에 b로 바꼈는데 얘기 안해줬나?"
    또는
    "내가 도출한 결과값이 다른데..a말고 c로 해보세요"
    한참 원시데이터 분석해서 보니 지가 틀렸음.. 열받아서 따지면
    왜 그때 데이터 틀린거 몰랐냐고 되물음.. 어이상실 ㅎㅎ

    하루하루 도딲는 기분으로 코딩할때가 많죠 ㅎ
    • 2010.01.04 22:16 신고 [Edit/Del]
      그런 경우도 허다하죠. 그렇다고 우리가 을인데 꼬치꼬치 원리 원칙대로 할수도 없고...
      정말 개발일 오래 하면 산에 들어 가서 수양 안해도 도가 저절로 쌓이는거 같습니다. ^^
  5. 맞아요. 주는 입장에서만 쉬운 프로젝트지요
  6. 항상 단계별로 인수자(최총사용자)하고 애기하는게 바람직하죠..~
    • 2010.01.05 14:01 신고 [Edit/Del]
      그렇긴 합니다만 작업을 하다 보면 그렇게 하기가 쉽지 않더군요. 일진행도 느려지고...
      그리고 자꾸 물어보면 사용자가 짜증 내는 경우도 있죠. ^^
  7. 음...저도...-_-;
    Shot counter라고 해서, 버튼 누르면 숫자가 1씩 올라가서 표시되는, 그저 그런 프로그램을 만들어 달래서 개발해줬더니 Set, reset, +1, -1, 자동 count까지 기능이 확장되고 있습니다. -_-;
    • 2010.01.07 17:24 신고 [Edit/Del]
      ㅋㅋㅋ... 늘 그런거 같습니다. 처음과 자꾸 말이 바뀌죠.
      저도 메신저를 만들때 처음에는 채팅만 되면 된다고 하길래 만들어 줬더니 자꾸 기능추가를 요구해서 만들다 보니 거의 네이트온과 같은 완제품이 되어 버렸습니다. ㅠ.ㅠ
  8. 나도참
    잘 보고갑니다.
    글/그림 정말 1000% 공감입니다.
  9. 바로 지금 제 상황이랑 딱 맞는 글이라서 전에 본 글이지만 다시와서 흔적을 남깁니다.
    의뢰주는 그 프로젝트가 대강 어땠으면 좋겠다...잘해야 이정도의 생각만 있지 디테일한 것은 전혀 생각도 안하고 있다가 막상 구현해 놓으면 그제서야 이거는 이래서 안되니 이렇게 이렇게...수정해 달라고 합니다. 당연히 일단 구현된 마당에 그런 수정은 대부분 가장 처음부터 뜯어고쳐야 가능한 부분들이 포함되구요.

    간단한 프로젝트 = 전혀 그 프로젝트에 대해 모르고 있다

    이런 것 같습니다.
    개발자가 간단하다고 하는 것은...
    그 개발자도 역시 그 프로젝트의 디테일한 부분은 전혀 모르고 있다(아니면 진짜 대단한 개발자로 이미 쌓아둔 라이브러리가 출중하다 라든가)...그렇다고 볼 수 있는 것 같습니다.

    그래서 프로젝트는 예외적인 구현이 점점 많아져 아무도 이해할 수 없게 복잡해 져서 차라리 처음부터 다시 하는 것이 나을 상황이 오고...유지보수는 대략 5배는 힘들어지(거나 불가능해 지)고...

    지금은 리포트 작성하는 부분을 만들어라...라고 하면서 딸랑 엑셀 파일 한개 던져줬길래, 그대로 해줬더니 열/행을 반대로 하고 이렇게 저렇게 등등 갑갑하게 만들고 있네요.

    덕분에 점점더 엉터리 구현이 되어가고 있지요.
    • 2010.10.14 12:53 신고 [Edit/Del]
      그렇죠. 처음에 간단하다 하고 만들다가 점점 커지면 코드가 산으로 가고 있고 지저분해지기 일쑤죠.
      이런일은 없었으면 좋겠는데 어쩔수 없나봐요 ㅜ.ㅜ
  10. 트랙백 해 갑니다.

    차라리 초반부터 복잡한 것을 알았으면 덜 고생하지요.
  11. 댓글나그네
    1990년대 부터 SI PJT를 해왔고, 국내외 서적들을 본 바에 의하면 정말 기가 막히게 위의 사진이 모든 상황을 설명하고 있음을 절실하게 느낍니다. 우리만 그런 게 아니라 어느 나라든 똑 같은 거 같더군요!
    제 경우 그나마 성공했다고 할 수 있었던 PJT들을 돌이켜 본다면 한가지가 요건이 있었습니다.
    - 하고자 하는 일(PJT)의 본질을 알고 있는 책임감 있고 힘있는 고객을 끌어드리고, 그 사람 자기자신도 한 배를 탄 일원으로서 PJT 깊숙이 참여하여 같이 만들어 가야한다는 걸 인식하게 만들면 성공확률은 엄청 높아진다
    • 2015.11.20 08:09 신고 [Edit/Del]
      크... 맞는 말인거 같습니다.
      힘있는 사람이 있어야 하고 프로젝트를 같이 하고 있다는 생각이 들게 해야 일이 그나마 쉽게 풀릴수 있겠더군요. ^^

Name __

Password __

Link (Your Website)

Comment

SECRET | 비밀글로 남기기