인간, 조직, 권력 그리고 어느 SW 엔지니어의 변
국내도서>컴퓨터/인터넷
저자 : 이종국
출판 : 인사이트 2011.03.11
상세보기



 

 적나라한 대한민국 S/W의 현실  

 


● 그동안 S/W 관련된 에세이 혹은 소설 종류는 거의 다 읽은 것 같다. 안철수 교수의 "지금 우리에게 필요한 것은" 부터 임백준 님의 "나는 프로그래머다", "행복한 프로그래밍", "뉴욕의 프로그래머" 같은 에세이, 소설들, 조엘 스폴스키의 그 유명한 Joel on Software 와 그의 책에서 소개하던 다른 S/W 엔지니어링 관련된 책들, "해커와 화가", "데드라인", "프로젝트가 서쪽으로 간 까닭은" 같은 또 다른 저명한 외국인들의 관련 책들까지. 프로그래밍으로 밥을 벌어먹으면서 관련된 책들은 약간의 의무감까지 느끼며 모두 읽었다. 


● 앞에서 든 책들은 모두 외국의, 특히 미국의 S/W 업계의 현실을 반영한 경우가 많다. 심지어 임백준 님의 책들 조차도 뉴욕의 S/W 회사에서 벌어지는 일이다. 내가 매일 겪는 불합리한 상황들과는 - 지금은 많이 지나갔지만, 옜날에 야근이 극심할 때는, "아 이래서 회사에 창문이 안열리는구나" 란 생각 까지 했었다. - 기본적인 전제 자체가 다르다. 아무리 바쁘고 시간에 쫒기면서 돌아가는 곳이 이 S/W 업계라 하여도 대한민국 SI 업계에서 들려오는 소문들과, 내 사촌 누님이 실제로 겪은 일들과,제조업에 기반을 둔 무늬만 IT회사에서 나와 내 동기들과 동창들이 겪는 일들은 앞서 말한 책들의 저자들은 상상조차 하지 못한 일들이다. 


● 이 책, 대한민국의 SW 현실을 다룬 진짜 첫번째 책인 아닌가 싶다. 이전에 "대한민국에는 S/W가 없다" 가 그나마 대한민국의 현실을 다루려고 했었으나, 역시나 저 높은 곳에서 책상물림이 쓴 느낌이었다면, 이 책은 진짜 PM이 수십년간 프로젝트를 진행하면 겪었던 일들이 정말, 적나라하게 적혀 있다. 


● 예를 들면 이런식이다. 어떤 방법론이나 S/W 엔지니어링 이론에 따른 산출물을 만들어 달라고 요구하면 대충그럴듯하게 만들어주면 된다. 어차피 요구한 사람도 그 자세한 내용은 보지도 않을 뿐 아니라 자기 상사에게 그럴듯 하게 보고하기 위한 용도에 지나지 않기 때문이다. 이런 식으로 신랄하게 깐다. 저자와 같이 프로젝트를 진행했던 몇몇 분들은 책을 읽으면서 자기얘기가 나와서 얼굴이 붉어질지도 모른다. 



 

 대한민국 S/W 업계가 개판인 이유 - 결국 조직내 정치싸움 

 

● SI 업계의 권력 피라미드를 그리면 대충 다음과 같다. 정점에 발주사의 CEO가 있고, 그 밑에 경영진 - IT실무부서(감리부서) - 하청업체 경영진(영업부서) - 하청업체 개발팀 순서다. 일은 하청업체 개발팀이 다 하지만, 생색은 발주사의 경영진이 낸다. 중간에 껴있는 모든 사람들은 어떻게든 자기 때문에 프로젝트가 잘 돌아간 것처럼 보이기 위해서 애를 쓰고, 파워게임을 하고, 쓸데없는 문서를 요구하고, 프로젝트 일정을 압박하고, 결국 개발팀의 누군가를 희생양으로 삼으려고 한다. 이 결과, 개발자와 그 가족들의 삶은 피폐해지고, 프리랜서들은 개발 중간에 회사를 떠나고, 심지어 프로젝트가 일정에 맞춰 성공적으로 끝나는 것을 싫어하는 사람들까지 나타난다. 자신의 공적을 내세울 곳이 없기 때문이다. 


● 돈은 개발부서가 번다. 좀 더 정확히 얘기하면, 위에 권력 피라미드에서 구체적인 부가가치를 창출하는 곳은 제일 밑바닥에 있는 개발부서이다. 그런데, 실제로는 경영, 영업부서다 계약을 통해서 매출을 창출하고, 그 이후 개발부서는 이윤을 까먹는 곳으로 여겨진다. 여기서 현시로가 괴리가 생기고, 문제가 발생하다. 


● 역시, 책상물림들이 S/W 엔지니어링이라는 학문을 만들면서 불필요한 문서들이 엄청나게 늘어났다. 문제는 이 문서 산출물들이 본래의 의도는 잃어버린채, 관리부서의 실적을 입증하는 용도로 전락해 버린다. 문서는 만들어지지만, 누구 하나 내용에는 관심도 없다는 얘기다. 실제 프로젝트와 문서와의 상관관계도 큰 관심이 없다. 결국 개발자들에게 일만 많아지고, 일의 집중력만 흐트러뜨리며, 프로젝트 일정만 늦출 뿐이다. 



 

 프로젝트의 진짜 목적은 무엇인가?

 

● 소프트웨어 개발이나 운영, 유지보수의 최종 목적은 그 안에서 일하는 우리의 행복이어야 한다. 

Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. ee
    2012.06.26 02:08
    댓글 주소 수정/삭제 댓글
    사실 맞는듯요 개발이 제일천대받고무시하고 빨리하라고 야근하고 주말출근에 위에선 저렇게갈구죠


원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  - 이전글 보기 : 개발자 생태보고서 1
  - 이전글 보기 : 개발자 생태 보고서 2
  - 이전글 보기 : 개발자 생태 보고서 3
  - 이전글 보기 : 개발자 생태 보고서 4

  ●  독립과 자치

         제가 1999년 Fog Creek Software를 시작하기 전에, Juno에서 그만 두고려할 때 인사과에서 일반적인 퇴직 면접을 가졌습니다. 그리고 어쩐지, 뭔가에 홀린듯이 인사부서 사람에게 회사의 모든 경영이 잘못되었다고 말하게 되었습니다. 어떤 부분들은 저한테 전혀 이득될 것이 없고, 분명히 손해만 될것임에도 불구하고 저는 말해버렸습니다. 제가 불만을 표햇던 가장 큰 부분은 Juno 사의 히트 앤 런 방식의 경영 스타일이었습니다. 대개의 경우,  여러분도 아시다시피, 경영자는 사람들이 혼자서 조용히 그들이 업무를 완수할 수 있도록 내버려둬야 합니다. 하지만 때때로, 그들은 어떤 일의 아주 세세한 부분에 관여하여 그 일이 자신들이 원하는 방법 그대로 수행되어야 한다고 주장합니다. 이유도 없이 말이죠. 그리고는 그들은 또 다른 업무의 세세한 부분을 관리하여 합니다. 결과가 나타날 때 까지 충분히 기다리지도 않습니다. 예를 들면, Juno에 가입하는 입력창에 날짜가 어떻게 입력되야 하는지에 관해서 CEO부터 제 직속 상관까지 모든 사람들이 떠들고 다녔던 2~3일간의 짜증났던 기간을 기억합니다. 그들은 UI 디자이너로 훈련된 적도 없으며, 제게 이 이슈에 대하여 특정한 경우에 대하여 이해할 수 있도도록 설명할 시간도 없었습니다. 그렇지만, 그건 아무래도 좋습니다. 경영진은 이 이슈에 대하여 그들의 주장을 굽히려 하지 않았고, 제 반론을 들을 생각조차 안했습니다.

        기본적으로 여러분이 똑똑한 사람을 고용하고 싶으시다면 그들이 그들의 기술을 업무에 적용할 수 있도록 하셔야 합니다. 그들이 원한다면 경영진이 조언을 할 수도 있지만, "조언"이 명령으로 통역되는 일이 없도록 대단히 신중하셔야 합니다. 여러분이 좋은 사람들을 고용하셨다면, 기술적 이슈에 관하여 경영진은 최전선의 기술자들보다 아는 것이 적을 것입니다.

        개발자들은 그들의 기술 때문에 고용되기를 원하며, 전문가로 대접받고 그들의 전문분야에서 결정권을 갖기를 원합니다. 

  ●  정치는 안됨

        실제로, 정치는 두 명 이상의 사람이 모인 곳에서는 어디에서나 일어납니다. 자연스러운 일입니다. 제가 말하는 "정치는 안됨" 의 진짜 의미는 "역기능하는 정치는 안됨" 입니다. 프로그래머들은 매우 예민한 정의감을 갖고 있습니다. 코드는 동작할 수도 있고, 그렇지 않을 수도 있습니다. 코드를 테스트해서 버그를 찾으면 되기 때문에, 버그가 있는가 없는가에 대해서는 논쟁이 필요 없습니다. 프로그래밍의 세계는 매우 정확하고 엄격하게 질서가 잡혀 있습니다. 그리고, 수없이 많은 사람들이 프로그래밍의 세계로 발을 들여놓는 첫번째 이유는 정확하고, 순위가 분명하고, 실력위주의 사회에서 다른 논쟁없이 단지 '옳기" (Being right) 만 하면 승자가 될 수 있기 때문입니다.

       이것이 프로그래머들을 끌어들이기 위해 여러분이 만드셔야하는 환경중 한가지 입니다. 한 프로그래머가 "정치"에 관하여 불만을 이야기 한다면, 그것은 아주 정확하게 말해서, 기술적인 문제보다 더 심각한 문제란 뜻입니다. 단지 사장님이 좋아하기 때문에 업무를 수행하기 위한 최선의 언어가 아닌 특정 프로그래밍 언어를 사용하라는 말 보다 개발자를더 화나게 하는 것은 없습니다. 어떤 사람을 승진 시킴으로써 얻을 수 있는 분명한 이점보다 인간관계 능력에 의해 사람들이 승진하는 것보다 개발자들을 미치게 만드는 것은 없습니다.  조직에 높은 자리에 있는 분이나, 높은 분과 친한 사람에 의해서 기술적으로 떨어지는 일을 하도록 지시를 받는 것보다 개발자들에게 더 적대적인 것은 없습니다. 

     
       정치적인 이점을 잃어버릴지라도 기술적인 이점을들어 논쟁에서 승리하는 것 보다 더 개발자들을 만족시키는 것은 없습니다. 제가 Microsoft에서 일하기 시작했을 때, MacroMan이라는 그래픽 매크로 프로그램을 위한 프로그래밍 언어 프로젝트가 있었습니다. 이 프로젝트는 메이져급 프로젝트였지만 방향을 잘못 잡은 프로젝트 였습니다. 이 프로그래밍 언어는 진짜 프로그래머들을 좌절시켰는데, 그래픽 환경이 실제로 반복문이나 조건문을 구현할 수 있는 방법을 제공하지 못했습니다. 뿐만아니라, 프로그래머가 아닌 사람들이 알고리즘을 만드는데도 도움이 되지 못했습니다. 제가 MacroMan에 관하여 이의를 제기했을 때, 제 보스는 "누구도 열차를 탈선시킬 수는 없다네. 포기하게" 라고 말했습니다. 하지만 저는 계속해서 논쟁하고 논쟁하고 논쟁해서  - 저는 당시 대학을 갓 졸업했을 대였고, Microsoft의 누구와도 인맥이 없는 상태였습니다 - 마침내 사람들이 제 이야기를 듣게 되었고 MacroMan 프로젝트는 종료되었습니다. 제가 어떤 사람이었느냐가 문제가 아니라, 제가 옳았다는 것이 중요합니다. 이것이 프로그래머들에게 기쁨이 되는 비정치적인 조직입니다. 


  대체로, 여러분의 조직의 사회적 역동성에 초점을 맞추는 것은 건강하고 즐거운 직장을 만드는데 핵심 입니다. 그리고 이러한 직장이 프로그래머들을 유지하고, 끌어들일 것입니다.  (역자주 : 미국에서는 이직이 매우 흔한 일로, 현재 일하고 있는 개발자들을 유지(Retain)하는 것이 새로운 프로그래머를 뽑는 것 만큼이나 중요한 일입니다.)


(6부에서 계속)

PS. 이번 글은 엄청나게 길군요.

저자에 관하여
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


BLOG main image
일상, 프로그래밍, IT 그리고 직장생활, Dive, 여행 by 지그프리드

카테고리

Class List (402)
Studies (30)
Exercise & Quizz (10)
Term Project (0)
ECIM list (Help!) (10)
Issues & News (0)
Gossip about IT & Job (22)
Tools (2)
Think about the Justice (23)
Book Review (170)
조엘 온 소프트웨어(번역) (28)
Diary (87)
Vacations (9)
Clash of clans 클래시 오브.. (11)

글 보관함

달력

«   2020/02   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
Total : 316,428
Today : 11 Yesterday : 13