태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

잔말 말고 시키는 대로 해

2009/01/13 15:37 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

소프트웨어를 개발하는 현장에서는 매우 합리적인 척하는 가면을 쓰고 벌어지는 수많은 비 논리적인 판단과 결정을 자주 보게 됩니다.

약장사처럼 "이 약만 먹어봐 끝내줘!"부터 아주 사소한 이슈까지 정말 다양한 문제들이 비효율적으로 의논되고 합리적이지 않은 결정이 이루어 집니다.

물론 PI(Process Innovation)을 하다 보면 "잔말 말고 시키는 대로 해!"라고 하고 싶은 때가 종종 있습니다. 모든 이슈를 모두에게 합리적으로 납득시키고 이끌어가는 것이 오히려 비효율적이고 또는 거의 불가능할 때 이런 생각이 듭니다. 소프트웨어 개발에 관련된 이슈는 상대방과 반대의 생각을 가지고 끝까지 반박을 하면 끝도 없는 논쟁으로 빠뜨리는 것이 그리 어려운 일이 아닙니다. 물론 득도 없죠.

C가 좋나? C++이 좋나? 
CBD방법론이 좋나? OO방법론이 좋나?
Java냐? .NET이냐?
무슨 프레임웍을 써야 하나?
스펙을 자세히 적어야 하나? TDD를 사용해야 하나?
설계는 UML를 써야 한다. Use case를 그려야 하다.

이 중에 쉽게 결정할 수 있는 이슈는 하나도 없습니다. 
회사마다 비즈니스 상황이 다 다르고 고려해야 할 환경이 제각각이기 때문입니다.
암에 걸린 사람에게 내가 침 맞아서 나았다고 다른 암환자에게 침만 맞으면 낳는다고 하는 것처럼 위험합니다.

하지만 자신이 아는 것이 침술 밖에 없다면 또 침술로 먹고 살아야 하는 사람이라면 그렇게 침이 최고라고 주장을 하겠지요.

.NET위주로 개발을 한 개발자가 사내의 모든 개발이슈에서 자신이 아는 것이 .NET이라는 이유로 모든 관련 의사 결정에서 .NET으로 개발하도록 관철하는 것과 비슷합니다. 물론 그 이유로는 "내가 아는 것은 .NET밖에 없다"라고 하지는 않고 온갖 그럴듯한 이유를 대지만, 이미 마음을 정해 놓은 마당에 합리적인 결정은 물 건너 간 것이지요. 그로 인한 손해는 회사와 개발자들이 몇 년 후에 고스란히 감수를 하게 됩니다. 코딩 망쳐서 버그 잔뜩 만들어 낸것과는 비교과 안되는 막대한 비용을 치뤄야 합니다.

또 회사의 역량이나 환경이 다른데 특정 방법론을 무조건적으로 기계적으로 적용하는 것 또한 비슷한 경우입니다. 이 경우 과거처럼 주먹구구식으로 개발하는 것이 오히려 나은 경우도 많습니다.

본인이 뛰어난 개발자라고 생각한다면 또는 뛰어난 엔지니어가 되고 싶다면 고집은 필요하겠지만 아집은 버려야겠습니다. 그리고 합리적인 결정을 하는 훈련이 필요합니다. 이것이 개발자가 성장해나가는 필수 단계입니다.

이미지출처 : Microsoft Office Online

저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/51 관련글 쓰기
  1. 공감합니다.
    개발을 하면 할수록 느끼는 점은 "Balance"가 중요하다는 점이지요.

  2. 헝그리맨님 안녕하세요.
    "균형"은 소프트웨어 뿐만 아니라 인생의 원리 아닐까요?

  3. 저는 윗 분들께 "믿어 보시라니깐요?"라는 말을 많이하는 것 같습니다. 올해는 좀 더 균형?있게 윗 분들과 균형있는 대화를 할 수 있도록 노력해야 겠습니다. 혼자 막~ 달려가고 넘어지고... 욕하고... 후회한... 작년... 그것이 문제였습니다. 이제 윗 분들도 손잡고 함께 달려갈 수 있도록 균형있는 설득을 해 봐야겠습니다. ^^;

  4. 정의의소님 안녕하세요.
    "믿어 보시라니깐요?"방법이 좋다 나쁘다 말하기 어렵네요. 가장 좋은 방법일 수도 있습니다. 신뢰관계가 있다면요. 사실 모든 일을 설득하고 납득시켜서 하기는 어려운 것 같습니다. 윗분들이 아랫사람의 전문성을 어느 정도 믿어 주는 것이 가장 좋죠. 그만큼 전문성을 갖추고 있어야 할듯.

  5. 맨 마지막의 글귀인
    '합리적인 결정' , 이 내용이 귀에 들어 오네요
    동료의 의사는 무시한 채 일방적인 생각은
    성장에 저해되는 요소가 아닌가 싶습니다.

  6. 마음의꿀단지님 안녕하세요.
    말은 쉽지만 참 어려운 일인 것 같습니다.

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..