1. 구조적인 문제

IT업계는 건축업계와 비슷한 업계구조를 가지고 있다한다.

갑에서 을로, 을에서 병으로

하위로 수주가 넘어갈수록 가격과 기간은 줄어든다.

따라서 프로젝트는 적은 인원으로 빠른시간내에 완료해야하고

결국 그 피해는 고스란히 개발자에게 떨어진다.



2. 미완성된 설계

업무의 파악도 제대로 이루어지지 않은채,

현업의 요구정의도 이해 못한채

설계가 되어지고 개발을 한다.

그리고 다시 수정하고 다시 개발을 한다.

코딩은 6개월만 공부해도 누구나 충분히 할 수 있다.

하지만 설계는 정말 어려운 작업이다.

설계가 잘못될 경우 그 프로젝트는 실패 할 수도 있다.

개발자가 야근하면 대부분 개발자 잘못은 없다.

설계를 수정하고 추가하는 이런 작업으로

1차 작업 후 2차 작업은 기본. 3차, 4차까지 줄줄이 이어진다.

이것은 설계자가 현업과의 소통이 원활히 이루어지지 않은 탓이다.

더군다나 설계자들은 일반적으로 개발자보다 더 높은 직급을

가지고 있으며, 우리나라 특유의 사회관습인 상명하복의 풍조

덕분에 개발자들은 쓴소리도 못 뱉고 이제는 점점 노예근성으로

변질되어 가는 것 같다.

야근은 거의 당연시 되고 있으니 말이다.

뛰어난 설계자들의 부재가 문제일 수도 있고

설계단계의 시간부족이 문제일 수도 있으며

금전적인 고용주의 판단에 의한 문제일 수도 있다.

근본적으로 1번과 연관되어 있다고 볼 수 있다.



3. 문제가 발생될 경우 그 충격을 흡수할만한 개발자의 부족

사람은 컴퓨터와 달리 실수를 할 수 있는 동물이다.

수정사항은 나올 수 있는 것이며, 현업의 요구가 변심 할 수도 있는 것이다.

물론 후자의 경우, 기간 혹은 금전적인 보상을 받아야하겠지만

그런 것을 기대하기란 힘들다. 기업간에도 상명하복이 존재하는

좋은 말로 서비스 마인드를 가지고 있기 때문이다.

물론 그런것도 여유가 있을때 해줘야겠지만..

글의 본질로 다시 돌아가

프로젝트 인원의 실수로 인한 수정사항이 나올 경우

그것을 수정하는것은 기존 작업을 어떻게 하였느냐에 따라

손쉬운 일이 될수도 있고

어마어마한 분량의 작업이 될수도있다.

일례로 하드코딩을 들 수 있다.

겉으로 보기엔 아무 문제가 없지만 속을 들여다보고

수정해야하는 입장에서는 정말 골치 아픈 작업이고

노가다성향의 작업이 아닐 수 없다.

일례로 든것일뿐 대부분의 개발자들은 이러하지 않을 것이라 믿는다.

그만큼 개발자의 역량도 중요하다는 뜻이다.

수정사항이 나왔을때 다른사람의 코딩을 이해하고 분석하는 것과

자신이 개발 하였을 경우 일관성있는 코딩으로 손쉽게 문제를 해결 할 수 있는 개발자들이 있어야 어느정도의 수정사항이 나와도

개발자 역량에 따라 그 문제를 충분히 흡수해낼 수 있다.



고급개발자 및 고급설계자 들은

다 어디 간것인지 궁금하다.

금전적인 문제로 사직한것일까

아니면 정말 닭집사장님으로 이직 하신 것일까

정말 미스테리한 일이다..