3D (Dirty, Dangerous, Difficult)

작성날짜 : 2011-05-11

출처 : GIS 프로그래밍 연구소 | http://cafe.naver.com/gisdev | 홍성락(srhong007)
원문 : http://cafe.naver.com/gisdev/1753

주제 3D는 3차원(Three Dimensions, Three Dimensional)가 아니라 Dirty, Dangerous, Difficult를 말하려합니다.

본래 제조업, 광업, 건축업 등 더럽고 위험하며 어려운 분야의 산업을 말하나, 요즘은 힘들거나 대접받지 못하는 분야도 포함해서 말하곤합니다.

특히, 우리가 일하는 소프트웨어 분야도 3D업종이라 합니다, 그런데 이런말은 바로 소프트웨어에 종사하는 우리가 만든 말이고 우스갯 소리로 말하곤합니다, 그리고 좀더 생각하면 우울해지곤 합니다.

 

지난번 영업과 개발의 근본 생각은 어쩔수없이 다르고, 균형을 맞춰야하는 것이 종을거 같다고 생각했습니다.

마찬가지로 이번엔 왜? '개발자나 소프트웨어 종사자들은 스스로를 3D라 할까!', 생각을 해 보았습니다.

[참조] 글로벌 소프트웨어를 꿈꾸다 / 김익환 / 한빛미디어 / 2010.11.30 2쇄 

 

- 콜라나 담배, 술 같은것을 쩔어가며 밤샘 코딩 또는 문서 작성을 한다 - 코딩은 아르바이트 시킬 수도 있고, 문서쓸 사람만 있으면 작성할 수 있다 - 비싼 사람(슈퍼맨) 하나면 다되고, 나머진 아무나 있으면 된다 - 발주자나 고객의 요구사항이 개판이니 이걸 들어 줄려니 힘든 직업중 하나 아닌가? - 개발한거나 문서나 개판인데 뭘 더 잘해주냐!, 대접받기 힘들다 등등등....

이러니 서로를 위로 삼아 농담조로 "소프트웨어 분야도 3D업종이다" 라고 합니다.

그리고 기회가 다으면 다른 업종으로 바꿔보려 합니다.

 

그럼 이런 말의 원인을 좀더 생각해보려합니다

- 발주자나 고객이 정해지지 않은 상태로 발주하고 수주하면서, 나중에 적당히 만병통치의 영업력으로 마무리합니다. - 이러한 발주와 수주 덕에 개발자는 시간에 쫒겨 부실한 소프트웨어를 양상하고 밤새워 일해도 대접받기 어려운 상황이 일어납니다. - 연봉만 높은 개발자를 무능력과 능력자로 평가를 투입된 프로그램 결과나 주변의 평으로만 하니, 초급이나 고급 프로그래머의 가치를 절상/절하합니다 - 이미 많은 인력이 IT를 벗어나는 현실이 되었다 등등등...

 

그럼 위의 원인을 좀더 깊이 따져보고 해결 비슷한것도 생각해봅니다

- 불명확하고 불분명한 발주와 수주.....   우리는 중소기업을 보호한다는 정책인 분리발주를 잘안다, 그러나 분석/설계/개발을 별도로 발주하여 양질의 소프트웨어를 생산하려는 분할발주는 잘 모르고 있다. 대개 분석과 설계/개발로 2단계 나누는게 통상적이다. 미래 정보화전략까지 세우려는 윗단계인 ISP는 알면서 말이다.   - 분할발주의 의미나 장점등은 너무 길거 같고 자세한건 찾아보세요.   (일명, 찰떡 같이 붙어있는 분석/설계/코딩을 떼어내라~)   제가 말하고 싶은건 분할발주의 행위자를 구분하자는겁니다   "백발이 성성한 프로그래머는 없다" 와 "백발이 성성한 개발자가 되길 원하는 사람을 채용합니다"   즉, 개발자와 프로그래머가 다르다는거와 구별되어야한다는것입니다.   개발자가 프로그래머를 한다면 장기적으론 자기의 가치를 떨어뜨릴 수도 있다는겁니다.   물론 개발자가 코딩을 해선 안된다는 말이 절대 아닙니다.    개발자는 분석/설계의 시간을 충분히 가져야합니다.   이것은 고달픈 현실을 극복하는것이지만, 장기적으로 회사, 그 이상의 피해를 줄일 수 있습니다.

 

그럼 개발자란 또 어떤 부류로 봐야하는지~

  전번 영업과 개발을 비교해보았습니다,

  영업도 기술영업, 비지니스 영업, 컨설트 영업 등으로 나눠볼 수 있지만,

  제가 영업은 아직 초보적인 습득밖에는 없어서 너무 깊이 논하긴 어렵구요...

  일단 개발자는..약 3가지 정도로 보여집니다( 겉으로 하는 짓? 성향을 봐서~).

- 원론적으로 잘 치우치는 Scientist형 : 현실에서 좀, 그런데 알고리즘 사랑은 크고..박식하죠 다방면으로... - 기법을 좋아하는 Technician형 : 개발방법론과 UML등 여러 지식의 소유와 주변 평이 높다(편한생활 영유) - 개발, 제품, 현실적인걸 좋아하는 Engineer형 : 사용자가 원하는것 만들려고 제품을 빨리 만들고 싶어하는..   대부분 Engineer형은 위 2가지 형보다 인정을 못받는게 현실입니다. 그런데 이게 맞느냐를 말하기전 쉽게 예를 들겠습니다.   문학쪽으로요, 세계제일의 평론가가 있구요 세계 초 문학박사가 있구요, 소설을 직접쓴 소설자가 있습니다.   즉, 직접 만들수 있고, 말로는 표현을 못해도 실행할줄아는 "암묵적 지식을 지니게 Engineer형인데, 노력대비 위 2가지형보다 어렵고 자기 과시가 어려우니 대부분의 개발자는 Engineer형보다는 위 2가지형으로 빠지기 쉬운 지식과 기법 위주로 하려고 합니다. 마찬가지로 이 3종류는 다 있어야 하는겁니다.   대기업에서는 개발자를 지식과 기법 위주로 투자하느라 실행하는 개발자 능력을 못 키우는 우를 범했고. 중소 기업은 바로 분석/설계/개발을 원하니 말로는 표현 못하여 대접을 잘 받지는 못하나 실행자를 키운것입니다, 그러나 좋은 조건이 생기면 바로 빼았기는 악순환이 되어 갑니다   그래서 지식과 기법을 주로하는 개발자형와 실행하는 개발자형을 균형있게 평가하는 것이 중요합니다, 어느 한가지가 파워가 세져도...보이시죠. 그 꼴이... 솔직히 기법이나 지식 10년한사람이나 1달한 사람이나 짧은 미팅시 짧은 대화나 제안서는 쓰겠죠. 그러나 프로젝트 수행시 10년한 사람과 1년 하는 사람은 첫 단추 부터 못찾는 일이 생깁니다.