Cavin님의 글 의 ps 이후 부분이 너무 공감되어 관련된 글을 다시 남겨봅니다.
p.s 한마디 하는데 본인포함 블로그에는 거품이 많다는거..
조낸 무식한 본인이 보기에도 열에 아홉은 설계와 쥐뿔 관계없는
상상의 나라 얘기, 개발의 일부 얘기, 아니면 무슨책 몇페이지 얘기;;
블로그 이미지 뻥튀기 마케팅이 참 대단하다고 해야할 지 뭐라 해야 할 지;;
그리고 툴, 코드, 프레임워크 등으로 운좋게 권력을 획득해서
잘 모르고, 확신없이 책과 여기저기서 주워들은 것으로도
설계에 대한 가이드가 종종 먹혀 들어가는 경우도 꽤 많은데..
줏어들은 설계로 개발자에게 완전 헛삽질시키는거 자주 봄.. 블로그에서도 자주 봄;;
똘똘한 고객에 걸려서 줏어들은거로 응대하려다가 논리부족에 피보거나,
신경질적 대응으로 압도하려다가 잘 안통해서 개피보는 경우도 보고;; 애도;;
아아..이거 완전 제 이야기입니다. 깊이 반성합니다. 실패한 이야기야 여기저기 수백개 올라와 있으니 검색엔진 한번만 돌리셔도..(아니 조금만 여기저기 신경써서 찾으셔도..) 나올 듯 하네요.
줏어들은 설계로 개발자 헛삽질 시킨 것도 해봤고…(몇번씩이나..ㅠ_ㅠ), 똘똘한 고객에 걸려서 줏어들은거로 응대하려다 피본것도 해봤습니다.(먼산..), 신경질적인 대응은 아직 안해봤습니다만.. 어째든 이런 현실을 경험하게 되는 이유가 뭘까요?(물론 제가 능력이 부족해서 그런 것 일수도 있습니다만..)
생각해보면 방법론을 선택하는 것, Process를 정리하는 업무 자체가 인정받지 못하는 Software 업체의 풍토(아 또 남탓하기 시작..)가 문제인 것 같습니다. 인정받지 못함으로 가치 없는 으로 보이고 자연스러 그런 것들에 집중하지 못하는 분위기를 만드는 것 같습니다.
먼저 관리자 분들의 문제. 관리자급이신 분들의 인식. Process, 방법론, 설계, 요구사항분석등등… 이런 것들이 왜 필요한지 전혀 인식을 못하고 계십니다. 그분들에게 필요한건 성과, 멋진 결과물, 실적 이런 것들이 필요하시죠. 그런 성과, 멋진 결과물, 실적같은 것들을 지속적으로 내기 위해선 잘 구성된 Process, 방법론 같은 것들이 필요하다고는 생각하시질 않습니다. 사실 이건 Software 업계 뿐 아니라 IT라는 것을 도입하려는 곳 모두의 문제가 아닐까 합니다. 아직 인식과 저변이 확대되어 있지 못하죠.
그리고 실제 업무에 종사하시는 분(개발자)들 마저 그런 필요에 대해 인지를 하지만 실제 누군가가 ‘이런 것들이 있다’라고 보여주면, ‘그런거 실제론 필요없어요’라는 반응을 보인다는 것입니다. 형상관리를 도입(해서 제대로 활용하면)하면 좀 더 제대로 소스코드를 관리할 수 있고, 백업도 덜 귀찮죠, 일한 티도 더 낼 수 있고..(노는 티도 더 나고..) 라고 해봐야 실제로 도입해서는 그냥 백업, 최신 버젼 공유 정도의 역활 밖에 못하는 때가 많습니다. 왜 그런걸까요?
ORM이다, Framework다 설계가 중요하다~ 떠들어봐야 그런 것들에 도전해보고 경험해 볼 용기와 열정 그리고 희생(그렇습니다. 희생입니다. 현실적인 표현이겠죠.)없이는 좀 더 멋진(?) 개발자의 일상, 즐거운 관리업무~ 같은건 현실로 다가 오지 않을겁니다.
결론적으로 하고 싶은 말은…정말 늘 듣던 그런 말들입니다. 넓게 보고, 실패를 두려워 하지말고 도전해보자! 입니다. 콜롬부스는 서쪽으로 가기만 했고(고생 무지 했지만..), 돈 키호테는 풍차를 향해 돌진 한 것 밖에 없지만 그 둘(응?)은 이름을 얻고 두고두고 회자되는 인물입니다. 용기있는 자가 미인을 얻습니다.