본문 바로가기
Knowledge Base/소프트웨어 공학

우리나라 IT에서는 왜 공학적인 생각을 못할까?

by 코드네임피터 2017. 2. 15.
반응형

개발로만 20년씩 근무하던 사람이 책이나 SNS, Blog 내용을 보고 이렇게 이야기 한다.


"우리는 Agile 사상에 따라 수평한 구조에서 일해야 한다. 그러니 내말을 들어라."


무언가 이상하지 않은가? 

수평구조인데 별다른 챌린지도 없이 수직적으로 의사를 전달하다니...

그런 도전적인 의사 표현에 대해서는 철저히 눌러 버린다. 맞던지 틀리던지.



관리하던 프로젝트에서 성능에 대한 이슈가 생겼다. 많은 개발자를 투입했으나 별다른 성과 없이 고객으로 부터 욕을 먹고 있다.

당초 계획했던 종료 일자는 몇달이 지났으나 끝날 조짐이 보이지 않는다. 나름의 튜닝을 했으나 성과가 없다.


"우리는 TDD를 지향해야 한다. 개발 방법론이 틀리면 그것도 바꾸어야 한다."


무언가 이상하지 않은가?

TDD가 성능에 포커싱된 내용인가? 물론 성과가 전혀 없진 않을 것이다.

하지만, 개발 프로세스를 손봐가면서 까지 반영해야할 요구는 누가 어떻게 진행할 것인가?

닥쳐야 하는 성향에 TDD 준비는 말이나 되는 상황인가?



제안서를 보다보면 무식이 절로 탈로 나는 경우가 있다.


"CMMi lv3 기반 개발 프로세스를 가지고 있기 때문에 완성도 높은 시스템을 만들 수 있다."


시스템 개발에 CMMi Lv3을 언급한다. 물론 조직 성숙도가 높으면 효율을 가질 수 있다.

그런 식으로 담보할 수는 없는 것이다. 전략이나 정책이 없는데 어찌 성숙도를 측정할 수 있다는 말인가?



그 뿐만 아니다. 프로젝트에서 존재하는 슈퍼맨은 어떤 조직이든 존재하는 모양이다.


"우리는 프로젝트 외의 멤버가 프로젝트를 보증하고 있다."

품질 보증 인력이 프로젝트 외에 존재하는 것... 안된다고 하진 않겠지만... 어렵다.

객으로 프로젝트의 품질 관리는 어불성설이다. 반대로 프로젝트 내에서 테스트를 했다손 치더라도...

전문가가 진행했는가? 



아직도 미개한 문화와 미진한 정신세계로 건전한 도전 문화에 찬물을 뿌리는 이런 상황...

충만한 의욕과 자기 계발 의지는 자연스럽게~ 시든다.


고민에 고민을 해야 하는 것이 프로세스이다. 프로세스를 수행하는 주체는 정해져야 한다.

프로세는 회사의 문화와 정책, 전략을 수반한다. 어느정도 기반이 마련되어야 그 위에 기둥을 세워 집을 만드는 것이다.

몇년전과 같은 고민에 빠진 나는 오늘도 영원한 친구 소주와 함께 하련다. ㅎㅎㅎ


이미지 출처 모음

Written by 밤의카사노바


반응형

댓글