[낙후된 관리방법] 개발자 이간질시키기

Posted at 2010.09.12 12:14 // in Associate // by MOOVA 무바㏇
대기업의 아주 오래된 관리방법 중에서 이간질하기라는 낙후된 관리방법이 있습니다. 이 방법은 개발자들을 대상으로 서로 먹고 먹히게끔 하어, 새로운 생산력을 끌어올리거나, 보이지 않았던 부분까지 끌어올려 경쟁하게 만드는 것입니다. 이 방법의 궁극적인 목표는 팀내또는 자사의 이익을 최대로 끌어올리자는데 그 목적을 두고 있습니다.  최근에 애자일, XP, 스크럼등의 관리방법이 급상승하면서 이런 낙후된 관리방법이 계속 실효를 거둘 수 있을지 의문이지만, 아직도 많은 대기업이 개발자를 다룰 때 이 관리방법을 사용하고 있습니다.

본인은 대기업의 프로젝트를 진행하면서 이것과 관련해서 경쟁심리를 부추기는 관리자들을 자주 봐 왔습니다. 처음 몇 번은 넘어가 줬고 당해주기도 해봤었죠. 지금은 머리가 굵어진 탓인지 이러한 관리방법에 전 별로 요동하지 않습니다. 오히려 이런 방법을 쓰는 관리자들에게 조언까지 해주고 있습니다. 아마도 전, 개인적인 만족감이나 성취감이 나이를 먹을수록 외부적인 요인이 아니라 내부적인 요인으로 채워져 있기 때문일 것입니다. 

한번은 어떤 프로젝트에서 한 개발자와 정말 친했던 적이 있습니다. 개인적인 이야기나 고민을 서로 채워줄 수 있는 사이까지 발전했다고 생각했는데, 어느 날 이 친구가 한 관리자의 이야기를 듣고 오더니 행동을 달리하더군요. 그때도 저 친구 당했구나~라고 생각했죠. 전 그전에도 여러 번씩 경쟁심리를 부추기거나 이간질을 당해봤기 때문에 저는 그 관리자가 그런 이간질을 했구나~ 금세 눈치를 챘습니다. 나중에 이 친구랑 다시한번 술자리가 있어서 이야기해 보니 그 관리자가 확실히 이간질한 게 맞더군요. 

또 한번은 SS에서 관리자가 같이 일하고 있는 개발자한테 가서 "너 그 사람 이길 수 있는가? 네가 걔한테 되겠어?" 하는 말로 경쟁심리를 부추겼다고 하더군요. 다음날 관련된 다른 개발자에게 가서 같은 이야길 합니다. "너 그런 줄 알았더니, 그 사람보다 안되네. 걔는 그러저러한데.. 넌..." 이때 저한테 딱 걸린 게 바로 전날 해당 개발자들과 따로 회식자리를 마련해서, 관계를 돈독히 한 적이 있기 때문에 이 관리자의 계략은 좀처럼 먹혀들지가 않았습니다.

2010:09:12 11:39:39


어디 이것뿐이겠습니까? 개발자끼리 먹고 먹히게 만드는 연출은 대기업이 하청업체 다룰때도 자주 볼 수 있는 모습입니다. 주로 하는 행태중에 하나가 하청업체들끼리 경쟁하게 하여 자사의 이익을 창출하는 고전적인 방법이 바로 이것입니다. 하나의 하청업체를 계속 쪼면서 피를 빨아먹으면서도, 다른 하청경쟁업체들까지 그 경쟁의 소용돌이 속에 포함해 자신의 손아귀에 넣으려는 방법말입니다. 하청업체가 힘이 있겠습니까? 만약 대기업의 관점으로 그런 방법을 하청업체들이 받아들이지 않는다면 계약을 파기하거나 단가를 깍으면 되는 간단한 일이 되기 때문에, 이들의 이간질방법이나 개발자들끼리 무덤만드는 횡포는 날이 갈수록 더 포악해져 가는 것입니다.

이런 낙후된 관리방법이 오늘날 한국식 대기업을 지탱하게 해주는데 큰 도움이 된 것은 사실입니다. 하지만, 이것은 어디까지나 낙후된 관리방법에서 흘러나온 편향된 방법에 지나지 않습니다. 우리는 린이나 XP,애자일과 같은 더 효율적이고 더 실용적인 관리방법을 충분히 사용할 수 있습니다. 개발자들끼리, 혹은 경쟁업체들끼리 이간질하거나 경쟁심리를 부추기는 대신 , 더 나은 프로세스안에서 기존의 방법보다 몇 배나 되는 생산성을 유지하면서 기타 업체들과 상생하는 방법이 얼마든지 있습니다. 

하지만 오늘날 우리의 대기업들은 아직 이런 프로세스를 받아들이기 좋아하지 않습니다. 기존의 엄격한 자사의 문화때문에도 그렇고 낙후된 관리자들이 이미 그들 문화속에서 윗사람으로써 자리하고 있기 때문에 이러한 폐해는 쉽게 고쳐지지 않겠죠.  하지만 윗물이 맑아야 아랫물이 맑다고 하듯이, 윗물의 낙후되고 도퇴된 마인드를 개선해 고인 아랫물까지 깨끗하게 만들어야 할 때는 바로 지금이 아닌가 싶습니다. 개발자들의 무덤이 되고 있는 대기업의 관리행태. 이 속에서 꾸준히 일하고 행복하게 일하려하는 사람들에게 그 열정을 지속적으로 유지해줄 수 있는것은 이간질도 아니고, 경쟁심리도 아닌 그들의 마음을 더 이해하고 그들의 아우성에 귀를 기울이는 것입니다. 정부에서 상생에 대한 발언과 함께 요즘 대기업들이 바짝 긴장하고 있다고 하는데.. 제가 봤을 때는 긴장하는 척으로 밖에 보이지 않습니다. 어디 콧방귀나 뀌겠습니까? 우물안에 살면 우물안에 것들이 최고로 보이는 법이죠. 뭔가 홀린 그들이 움직일꺼라는 생각은 만무하지만, '척'이아닌 진실에서 나오는 행동을 보여줘야 할 때가 아닌가 합니다.

2010:09:12 11:42:08

싸우지말자 개발자끼리!!

개발자끼리 먹고 먹히는 경쟁심리에 빠져들지 마십시오. 자신들의 살만 깍아먹고 있을 뿐입니다. 같은 밥을 먹고 같은 일을 하고 있으면 오히려 서로 위안을 주고, 토닥여주는 게 더 나은 개발자의 삶일 수도 있습니다. 때로는 어쩔 수 없이 관리자들이 하는 이긴질을 받아주세요. 하지만, 받아주는 척만 하면 됩니다. 정말로 상대 개발자나 타인에게 열이 받아 있다면 다른 방법으로 회포를 푸세요. 개발자들의 적은 절대로 개발자가 아닙니다. 갑에 딱 붙어서 책 두어권 써서 유명한 K팀장이 되었다고 우쭐되는 사람이 되지 않으려면 근본적인 본질을 보고, 우리가 과연 어떻게 행동해야만 이 낙후된 체제를 고칠 수 있는 것인지 불철주야 고민하는 방법밖엔 없는 것 같습니다. 개발자들끼리 상생하고 힘을 합한다면 아마도 노동자 피 빨아먹는 행태는 줄어들지 않을까요? 그때가 되면 갑에 딱 붙어 글 질이나 하는 사람,관리자의 횡포, 그와 비슷하게 그 대기업밑에 성인사업이나 차리려하는 뒷 거래도 잠잠해 지지 않을까합니다. 10년이 되건 20년이 되건 변화될 수 있는 것은 꾸준히 점진적으로 고쳐나야가만 합니다. 우리 자리는 우리가 지켜나갈 때 참다운 꽃자리가 되는것입니다.


Need to Awasome : 

얼마전부터 병원치료를 하는 와중에 저에게 전화 온 대기업 사람들은 몇 명 되지 않더군요. 
그렇게 인간적으로 사람불러들이고, 일 떠넘기려하고, 사적인것까지 포함해서 몇 번 희생까지 해 주었는데. 그들에게 만큼은 연락자체도 오지 않았습니다. 

뭐..예상은 했지만. 이거 좀 너무 하는 거 아닌가라는 생각도 들더군요. 되려 연락이 왔었던 것은 같이 일했던 개발자와 동료 후배들이었습니다.  대기업의 친분있던 관리자들은 연락조차 오지도 않고 안부전화도 오지 않았습니다. 물론 뒤에서 제 이야기를 들었다는 소식통에 의하면, 그 사람들 제가 병상에 있는지 다 알고 있답니다. 그러면서 모른척하는것이죠. 혹여나 노동착취나 고발성이야기를 할까 봐 겁먹고 있어서 그러지 않을까요? 

오늘날 대기업에 팀장이나 관리자가 되는 것은 쉽지 않습니다. 왜냐하면, 하청업체나 개발자들을 닦달해서 뽑을 만큼 뽑아야 하거든요. 이런자리에 올라가려면 절대로 인간적이 되어서는 안 됩니다. 냉혈인이 되어야 하는 것이죠. 아마도 이런 부류는 책 몇 개 썼다고 세상최고의 팀장이 되었다고 착각하는 비운의 K팀장과 비교될 수 있을 것 같습니다. 인권유린하는 관리자와 굉장히 친하다고 하죠. 세상은 정말 복잡하고 다단한 구조로 되어있습니다. 우리는 눈 가리고 이들을 허용하고 있습니다. 사실 그들이 개발자의 피를 빨아먹고 있는 펌프질을 하는 장본인들인데도 말이죠. 우리는 이렇게 현혹속에서 살아가고 있습것입니다.:)


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[회고] SI에서 TDD를? (2)

Posted at 2010.09.01 09:19 // in Project Life // by MOOVA 무바㏇
그동안 SI 프로젝트에서 웹애플리케이션에 관련된 일을 할 때, 그들과 같이 비공식적으로 TDD나 짝프로그래밍을 시도했던 적이 있다. 그리고 그것과 관련되서 구축해 줬던 라이브러리도 좀 된다. 그 중 몇가지 추려서 설명하고자 한다.

2010:08:31 20:53:04
그림1. 웹 MVC영역의 TDD작성 포인트

그림1은 일반적인 웹MVC의 아키텍쳐중 일부이다. 위에서 빨간색 점으로 표현한 지점이 TDD작성 포인트이다. 사실 위의 TDD작성 포인트가 MVC 웹-영역에서 사용할 수 있는 TDD의 전부라고 해도 과언이 아니다. 그에 맞는 라이브러리는 알려진게 워낙 많아서 번외로 하고 실제 프로젝트에서 직접 구성했었던 TDD작성 사례를 설명할까 한다.

"테스트데이터셋, Mock 객체, 테스트 Dao..테스트 서블릿등등등"

LG에서 시도했던 TDD의 실제 사례이다.
데이터베이스 테이블의 설계가 충분히 고려되지 못한 채 수시로 변경이 되었고 며칠 뒤로 고객에게 시연을 해야만 했다.( 또 어디서 나타났는지 우리의 관리자는 자신의 직원들은 안 쪼고 프리랜서만 닦달하고 있었다.) 고객이 원하는 UI(유저인터페이스)는 fix가 되어 있었다는 게 다행이었다. 뒷단은 수시로 변경되고 있었던 반면, 앞단은 고정되어 있었던 것이다. 여기서 선택할 수 있는 것이 가상의 Dao를 작성해서 가상의 데이터를 원하는 UI에 뿌려주는 것이다. 설계가 미진한 불안정한 데이터셋도 가상의 데이터셋을 만들어서 축출하면 그만이었다.


2010:08:31 21:04:58
이때 사용했던 가상의 데이터셋은 DBUnit에서 쓰는 기본포멧이 아닌 엑셀파일이다. 굳이 엑셀파일을 선택한 이유는, DBMS가 오라클이었고 오라클에서 제공하는 엑셀 익스포터를 사용하면 빠르게 해당 포멧으로 엑셀을 생성할 수 있었기 때문이다. 이렇게 생성한 데이터셋과 가상의 Mock Object를 사용하여 테스트케이스를 완료할 수 있었고, IDao를 구현한 Real Dao를 잠시 뒤로 놓고, 새롭게 작성한 TestDao를 메모리에 올려두었다. 이렇게 해서 고객이 원하는 뷰를 빠르게 작성할 수 있게 되었다. 이 당시는 뒷단의 디비설계가 수시로 변경이 되었었는데 가상의 DataSet을 사용하려 했던 아이디어가 크게 빛을 발휘했던 것이다. 결국, 나중에 디비 설계가 완료되면 그때 TestDao에서 RealDao로 교체만 하면 그만이다.
만약 데이터셋을 갖출 때 아래 그림과 같이 수많은 테이블에서 조인된 결과물이라면 토드와 같은 툴을 사용해서 쿼리를 수행한 뒤 얻은 결과로 엑셀파일을 생성하면 된다.

2010:08:31 21:18:20
그림2, 많은 테이블에서 조인된 결과물을 엑셀로 뽑을 경우 토드와 같은 툴을 사용하면 편리하다.

위와 같은 방법을 사용해야하는 시기와 장점에 대해서 정리해 본다.

1. 앞단의 개발자(UI개발자)와 뒷단의 개발자(서버개발자)가 분리되어 있을 경우, 간섭현상을 줄일 수 있다.
2. 데이터베이스 설계가 미진하지만 UI는 고정된 상태에서 제법 유용한게 쓸 수 있다. (Mock Object)
3. 테스트데이터를 쉽게 구비하지 못할 때 엑셀과 같은 가상의 데이터셋을 사용하면 알맞은 테스트데이터를 마련할 수 있다.
4. 모두 TDD에 용이하다.



2010:08:31 21:19:15
그림3. UI 테스트를 하기위한 컬럼 매핑예제


"직접 고안해낸 UI의 테스트 방법론"


그림3은 직접 삼성에서 프레임웍으로 구축해줬던 실제사례 일부분을 발췌한 것이다. ibatis를 사용하고 있었는데 뷰는 그리드컴퍼넌트를 사용하고 있어서 테스트 하기에 무척이나 까다로웠다. 이때 생각한 것 중에 하나가 UI단의 그리드 컬럼과 쿼리단에 각 컬럼명을 매핑시켜주면 그리드 테스트케이스는 작성할 수 있지 않을까하는 아이디어였다.
기존에는 컬럼 네이밍 규칙도 없었고 개발자들 제각각 컬럼명을 생성했기 때문에 통일성없는 흐름을 관찰했다. 통일성이 없으면 의존성이 증가되어 당연히 테스트도 어렵게 된다.

이렇게 쿼리단의 컬럼명과 그리고 혹은 UI단의 해더부분을 매핑시켜주면 UI의 TDD는 완료할 수 있다.


"분산처리 환경에서의 CRUD TDD"

2010:09:01 09:12:33
그림4. 분산처리 환경에서의 CRUD 테스트

필자는 오픈소스이외에 블랙박스 소프트웨어를 경험했었기 때문에 오픈소스로 알려져 있던, TDD관련 라이브러리들을 블랙박스와 접목해서 사용한적이 많다. 물론 해당 블랙박스 패키지속에 제공해주는 TDD관련 라이브러리들이 많이 있었지만 다루기 까다로울 때는 직접 라이브러리를 등록해서 블랙박스+오픈소스환경을 융화시키야만했다. 보통 데이터베이스를 테스트하는 용도로 CRUD의 반복되는 코드를 테스트하곤 했는데, 이때는 집적 데이터베이스와 붙지 않고 분산환경에서 가상의 프록시를 만들어 테스트를 진행해야했다.
이렇게 분산환경속에서 그것들 모두를 한곳의 테스트로 집중하기엔 의존성이라는 문제가 따라붙었다. 따라서 의존성을 제거하기위해 머신마다 단일책임원칙을 따르는 코드를 작성해야했으며 따라서 개별의 단위테스트를 진행할 수 있었다.

본인은 TDD와 관련된 라이브러리에대해 지식이 없었을 땐, 직접 테스트케이스를 위한 별도의 라이브러리를 구축해서 테스트를 진행하기도 했다. 정 여력이 없을 땐 main 메소드에 테스트를 했다.

얼마전에 나온 "테스트주도개발 TDD실천법과 도구" 를 통해서 본인이 생각하고 구축해 주었던 부분이 상당수 책에 실려었었던 것을 확인했다. 물론 본인도 TDD는 해외사이트나 기사를 통해서 학습을 했었고 unitils와 같은 라이브러리는 그동안 수차례 공부를 해왔던 경험이 있기 때문에 본인이 아는 내용과 책 내용이 상당수 중복되는 부분이 많았다.
그리고 위의 컬럼명 매핑에대한 부분은 순전히 개인적인 생각으로 삼성에 제공한 라이브러리였는데, 그것과 비슷한 방법이 이 책에 실려있어 깜짝 놀랐다.! 세상엔 참으로 비슷한 생각을 하고 실천하는 사람이 많다는 것을 새삼 깨닫게 해주었다. ( 실제 프로젝트에서 만나볼 수 없었던 비슷한 가치를 지닌분들 ).

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기
  1. Favicon of http://moonlgt2.tistory.com BlogIcon 소박한 독서가

    2010.09.01 09:49 신고 [수정/삭제] [답글]

    노..전문적인 프로의 포스가 팍팍 느껴지는군요.
    인사만 드리고 갑니다~ㅎ

  2. 2010.09.01 13:55 [수정/삭제] [답글]

    비밀댓글입니다

  3. Favicon of http://blog.doortts.com BlogIcon doortts

    2010.09.03 09:43 신고 [수정/삭제] [답글]

    최근에 저희 회사에서 일하셨었다는걸 알고는 깜짝! 놀랬습니다. 프로젝트룸 근처에 왔다갔다 한 적 많았었거든요. :D 어려가지로 신기한것 같아요.
    UI - SQL 접점에 대한 TDD는 효과는 어느정도 있긴 했었는데요, 아쉬웠던 점은 개발자들이 그다지 '재미'를 느끼지 못했다는 점이었습니다. 과정 자체가 성공의 기쁨을 느낄만큼 도전적이지 않았었던것이 원인이 아니었나 하고 스스로 회고해 봅니다.

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.09.04 17:10 신고 [수정/삭제]

      홋 그랬었군요. 프로젝트 단위로 움직이다 보니..지나치면서 만났을 수도 있었겠군요 :)

      맞습니다. 개발자가 생각할 때 그 일을 어떻게 생각하느냐, 재미있어하느냐 재미없어하느냐가 매우 중요한 것 같습니다. 그전에 그분들에게 동기부여를 해 줘야 하는데 어려운 상황이 많은지라 그러기가 매우 힘이든 것 같습니다. 또한, 저도 그렇구요^^. 취미로 하기엔 재미있는데 실무에서 하기엔 충분한 동기부여가 매번 모자라곤 하더군요.

      그래도 재미를 느끼는 열정 있는 사람들이 꾸준히 노력한다면 그 재미가 전염되지 않을까 합니다. ㅎ

댓글을 남겨주세요.

[회고] SI에서 TDD를 - 번외적인 모습들 (1)

Posted at 2010.09.01 09:00 // in Project Life // by MOOVA 무바㏇
2010:09:01 01:37:27
으핵!! 일단 생각난 김에 뭔가를 끄적이고 싶어서 끄적였는데 글이 길어졌습니다.O.Oㅋ.
회고식으로 작성된 글이라서 수필식의 글이 되어버렸네요. 쿄쿄쿄 ㅎㅎ

기술은 사람의 요구를 충족하기 위해 존재한다.


"TDD를 알게 되고나서.."

웹 스크립트 일을 할 적엔 TDD라는 단어조차 모르고 지냈다.
왜냐하면, 스크립트류의 개발이란, 소스 컴파일을 안 해도 바로바로 결과를 확인할 수 있었고(인터프리터), 디비연동이나 모델적용 조차도 페이지를 분할해서 하는 것이 전부였으니까 말이다. 처음엔 자바쪽의 프레임웍이나 보안 체계를 보고 자바진영은 왜 저렇게 비대한 것에만 관심을 쏟아부을까?라고 혼자서 궁금해 했었고 자바에서 구현한 것들을 다른 스크립트류의 언어로(php,cgi..) 구현하더라도 충분히 똑같이 할 수가 있었기 때문에 자바에 대한 약간의 불신이 없지 않아 있었다. 그 후 실제 자바 프로젝트를 하면서 자바의 구조론을 보았고, 객체설계나 OOAD를 차차 알아가게 되었을 무렵, 여러 오픈소스들을 열어서 소스를 분석하면서 참 놀라운 신세계를 발견하곤, 또 동경의 대상이 되기도 했다. 본격적으로 TDD를 처음 알게 된 것은 해외 오픈소스를 까보기 시작하면서부터이다. 이때는 R&D로 근무했었는데 TDD가 무엇인지 그 본질을 찾기 위해 개인시간을 들여가며 여러 세미나에 참석을 하곤했다. 직장은 연구소였지만 회사경영사정이 매우 어려워 책이나 세미나 활동조차도 여력이 안 되었었던 매우 힘든시기였다. 책도 구입할 돈이 없어 무척 가난했던 시기였다. (지금에와서 그때를 회상하면 참 유익했던 시절이었던 것도 같다.) 이때 같이 근무했던 선배들은 CS프로그램이나 VB와 같은 객체디자인원리나 패턴지향, 아키텍처 지향과는 거리가 먼 사람들이 대다수여서, 디자인 패턴이라든지, 객체지향 기술이라든지, 방법론이라든지 전혀 관심들이 없었다. 아니다 관심조차 두려 하지 않았다는 게 맞는 말일 것이다.

"TDD와 짝프로그래밍을 하기 어려운 SI의 문화와 최초 짝 프로그래밍 시도"

그 후 R&D팀을 나와서 여러 SI 프로젝트를 경험하면서 매우 불합리한 SI현실을 체험하기 시작했다. 그 안에서도 사기꾼 같은 사람, 학자 같은 사람, 이간질을 하는사람, 임기응변에 능한 사람, 매우 소극적인 사람, 매우 호탕한 사람, 매우 유쾌한 사람, 매우 우유부단한 사람, 매우 논리적인 사람, 매우 가난한 사람, 매우 부자인 사람, 묻어가는 사람, 책임감 있는 사람. 등등을 다양하게 겪어 가면서 우리 SI바닥엔 참으로 다양한 인종(?)들이 같은밥을 먹으면서 살고 있구나~하고 매번 놀랄때가 많았다.
그렇게 사람을 겪어 보면서 어떻게 하면 저들이 잘하는 것, 좋아하는 것을 하게 만들어 너도 좋고 나도 좋은(win-win) 그런 팀을 만들지 또는 회사나 프로젝트 환경을 만들지.. 개인적인 목표와 고민이 항상 나를 괴롭혔다. 고작 개발자인 주제에 관리자가 생각하는 그런 생각들을 아주 오래전부터 생각해 왔던 것이다.

내가 겪었던 SI의 70%가 그냥 주먹구구식의 운영과 프로젝트 진행으로 막장의 막장을 달리는 곳이 태반이였고, 체계나 방법론등을 도입할 수도 또는 도입하려 하지도 않았다..(물론 제대로 도입해서 성공한 케이스의 프로젝트들도 있다.)
그냥 고객이 요구하니 넌 맨땅에 해딩해라~ 뭐..이런식이었을까?
그렇게 저렇게 프로젝트를 지내고 다음 프로젝트를 기다리면서 막간의 텀을 이용해서 책과 씨름하며 학습도 하며 여행도 다니며 그런식의 삶을 살고 있었다. 한번은 SS의 프로젝트에서 나와 뜻이 맞았던 어떤 개발자가 TDD와 DDD에 관한 이야기를 했었는데 '어라? 나와 같은 동족이 있네~'하면서 그와 많은 소통을 했다.
이때 처음으로 그와 짝 프로그래밍이란 것을 해봤다. 처음 하는 짝프로그래밍. 처음엔 서로 궁합이 맞아 잘 진행한 듯 보였으나 개인적인 서로의 자존심때문에 묘한 느낌을 서로 받아야 했다. 짝 프로그래밍을 하기 전에 먼저 서로의 마음이 열려있어야 하는데, 인력이동이 잦은 프로젝트에선 실제로 짝프로그래밍을 한다는 게 여간 이상한 것 같았고, 쓸데없이 그런걸 왜 하냐? 라는 주위의 눈총도 받아야 했다. 또 다음에 만날 수도 없는 사람이라는 느낌때문에, 내가 겪었던 최초의 짝프로그래밍은 그렇게 흐지부지하게 지나갔다.
사실 짝 프로그래밍을 제대로 하려면 다음과 같은 적절한 도구와 환경이 받춰줘야 한다.

※ 짝 프로그래밍의 환경

  • 둘이 함께 편안하게 앉을 수 있도록 평평한 책상. 일반적으로 개발자 쪽으로 곡선하는 책상은 쾌적한 작업 조건을 제공하지 못하기 때문에 피해야햔다.
  • 저렴하게 구매할 수있는 가장 빠른 개발을 위한 컴퓨터. 짝 프로그래밍을 위한 컴퓨터
  • 듀얼 DVI 출력 을 갖춘 비디오 카드.
  • 24 인치 또는 30 인치 모니터를 2 개. 2 대의 대형 모니터를 데스크탑 클로닝 (또는 미러링) 이 우수 합니다.
  • 2 개의 키보드와 2 개의 마우스 .

  • "여전히 빨리빨리 SI, 하지만 애자일은 건재했다."

    그 후 여러 프로젝트를 전전긍긍하면서도 RSS 정보와 개인적인 학습, 그리고 별도의 애자일 서적을 통한 지식의 도움을 추가해 TDD와 짝프로그래밍 방법, 그리고 애자일을 익혀가면서 프로젝트에 도입하려고 무척 애를 먹었다.
    하지만, 짧은 일정에 덧붙여 내가 관리자가 아닌 이상 그것들의 장점을 주변사람들에게 쉽게 설득하기가 매우 어려웠다.  항상 일정은 촉박했고 누구하나 그런체계에 관심을 두려하지 않았다.
    출근하면 해외 RSS에서 쏟아지는 애자일 관련 기사들을 보고 "외국엔 저렇게 변화되어 가는데, 왜 한국은 항상 빨리빨리만 외쳐댈까?"라는 자괴감이 들었던 것이 한두번이 아니다. 같이 짝프로그래밍을 하자고 요청했던 지나가는 개발자들은 굳이 그런걸 왜 해야 하느냐며, 일만 많아질 뿐이라는 생각에 회피를 하는 게 대부분이었다. 물론 이런 사람들도 자신이 추구하는 가치가 있기 마련이기 때문에, 나와 다르단것을 인정했고, 이런 류의 개발자들에게도 짝프로그래밍과 TDD의 사상을 알려주면서 많이 전파하려고 애를 썻다. (물론 TDD는 개인적으로 깨작거렸던 것이 전부였지만 말이다.) 우리 SI바닥에도 좋은 것들만 골라서 도입을 한다면 충분히 빨리 퇴근할 수도 있고, 더 나은 소프트웨어를 생산해 낼 수 있다는 헛된 꿈이 있었기 때문일까? 왜 SI엔 민첩한 방법론이나 TDD를 할 수 없는지 항상 안타까워했다. 분명히 도입하면 차 후 성과를 볼텐데..왜 그렇게 관심이 없는지.. 점점 개인적인 지식은 늘어만가는데 이것에 대해 서로 이야기할 수 있는 사람 조차도 없었다. 솔루션 엔지니어로 일할때도 일반 범용적인 지식과함께 도메인 특화된 특수기술을 강조하면서 애자일사상을 도입하려고 많이 애를 써봤다. 하지만 OOTB기반의 프로젝트에선 애자일은 전혀 어울리지 않은 프레임웍이었다.(성격이 다른 탓이다. 좋지 않다는게 아니라.) 그래서 늘 하는일에 만족을 하면서도 애자일과 관련된 일에 대해서는 답답함만 늘어갔다. 그래서 TDD는 스프링이나 오픈소스를 학습하면서 개인적으로 시도한 적이 많이 있었다. 또는, 프로젝트 이외의 별도의 제작의뢰건들의 소프트웨어만 개인적으로 사용하곤 했다.(본인는 프로젝트 이외에 제작의뢰건도 종종 맡아서 진행했었으므로 1년에 5개월정도는 투잡을 한 셈이다. 공식적인 프로젝트 이외에 TDD나 새로운 기술을 그런 소일거리를 통해서 적용해 볼 수 있으니 일석이조가 아닌가?)

    "후배들이 생겼고, 진정한 선배란 무엇인가에 대해 고민을 많이 했다."

    그 후 나도 머리가 굵어졌는지 동료와 후배가 생겼다.
     
    솔루션 엔지니어에서 컨설턴트와 아키텍트에 관심을 두고 학습하기 시작할 때가 바로 이 시점이다.
    이때는 주변 저명하신 블로거분들이나 실무에서 나이가 들었어도 꾸준히 연마하시는 재야의 고수들에게 책 추천을 많이 받아서 상당한 도움을 받았다.
    이 당시도 대부분의 선배들이 관심조차 갖지 않았던 민첩한 그것들을 알리려고 매우 노력했다.
    한번은 짝프로그래밍을 몇 번 같이 했던 어떤 선배의 집에 찾아갔는데 책이 한 30권정도 있어서, 관심을 보여하는 나에게 그는 "내 책에 눈독들이지마라!"라는 소리를 들었던 적이 있다. 나 원참~ 책좀 같이 공유하고 보자는 말도 절색을 하며 싫어했다. 우리주변엔 이렇게 소통을 싫어하는 개발자분들도 꽤 된다. 이때 당시는 프로젝트를 한 뒤 남는 여력으로 책을 하나하나 사놓고 공부하고 있었던 터였고, 출근해서 일하고 퇴근해서 공부하는 그런 반복되는 일상에 쪄들어 살고 있었다.
    그 후 SI를 하면서 나보다 나이많은 선배들은 대부분 책이나 스터디보다는 그냥 현실에 안주하며 살아가는 사람들이 다수였다는 것을 확인했고, 개발자들에겐 책추천이나 기술을 배워본 적도 없고, 들어본 적도 없다. 오히려 내가 그들에게 퍼주거나 알려주는쪽이었으니 말을 해서 뭐 하랴..
    ( 물론 책을 추천해주거나 사줬던 선배들에겐 아직도 감사함을 느낀다. 온라인에서 책을 추천해 주신 몇 분에게도 감사함을 느낀다 하지만 나머지는 글쎄다.... )

    그래서 매번 대체 선배라는 게 무엇인가에 대한..회의감에 휩싸였다.

    한가지 다짐한다. 경력이 더 쌓이면 텅빈 그릇이 아니라 꽉찬 그릇이 되고싶었다. 후배들 보기에 쪽팔리지 않는 그런 선배가 되리라 굳게 마음을 다졌다.  개인적인 세미프로젝트를 세워가며 학습을 했고, 퇴근 후에도 다른 언어를 익히려고 참 노력도 많이 했다. 리펙토링도 수시로 열어서 연습했고, 각종패턴도 열어서 연습했다. 일부러 짝프로그래밍도 해보려고 후배의 TASK를 대신 해 줘가면서, 애자일스러운 경험을 쌓으려고 노력을 했다. 누구 하나 알아주는 사람도 없었고, 왜 그런것을 해야 하는지 의아해하던 사람들도 있었다. 하도 답답해서 이때부터 행동을 달리했다. 이때 선택한 행동이란 후배들에게 내가 아는 지식을 먼저 알려주고, 그들이 발전하면 같은 관심사에대해 터놓고 소통할 수 있는 사람을 찾는 기대감을 현실화 하는 것이었다, 그래서 개인적으로 봐왔던 책들을 후배들에게 주거나 사주었다. 물론 직장이 안정되있고 탄탄한 회사에 다녔던 사람들은 제외다. 그들이 그렇게 지식체계를 쌓으면 나중에 나와 대화를 할 수 있는 포인트에 도달할 것 같아서이다. 하지만, 아직까지 TDD와 애자일에 대해서 누구와 시원하게 탁 터놓고 대화를 할 수 있는 사람은 별로 없었다.

    "TDD와 짝프로그래밍은 아직도 나에겐 먼 섬, 그러나 시도의 즐거움"

    개인적으로 오픈소스를 공부할 때 그리고 프로젝트를 하면서 짬이 날 때만 TDD를 시도했다. 운이 좋을때는 Eclipse의 Community Framework와 같은 플러그인을 써서 짝 프로그래밍을 도입했다. 그리고 또 잊혀만 갔다. 본인은 프로젝트에서 얻은 지식보다는 개인적인 독학으로 공부한 지식과 경험을 굉장히 중요시하고 있다. 왜냐하면, 프로젝트라는게 항상 반복되는 일상과 똑같은 업무, 그리고 똑같은 규칙으로만 살면 그럭저럭 할 수 있는 게 프로젝트였고, 뭔가 새로운 시도를 좋아하는 나에게 또 다른 나만의 연구와 학습이 필요했던 것이다. 다른사람에게 거저 들어서 안 지식과, 자신이 노력해서 일군 지식은 그 가치정도가 상당히 크다고본다. 그리고.. 그런 연구적인 취미가 아직도 나에게 남아있다.

    "후배들에게 강조하는 것"

    나는 후배들에게 개인적인 학습을 지속적으로 하라한다. 이 말은 더 강조해도 지나치지 않는다.
    물론 가치관이 다른 사람들에게는 이런 말 조차도 꺼내지 않지만 말이다.
    남들이 한 것을 그냥 배껴서 살면 항상 그 자리에 맴돈다고 설명한다.
    일은 일이고 학습은 학습이라고 이야기한다.
    그리고 지식적인 소통을 하라고 강조한다. 귀찮을때까지 말한다.
    한가지 아쉬웠던 것은 개인의 능력이란 게 모두 달라서 똑같은 패턴의 학습을 강요할 수는 없다. 이 사람의 자질과 능력에 맞게 책을 추천해주고 소통할 수 있게 하는게 나의 취미이자 목표가 되어버렸다.
    (이즈음 되면 나도 어느정도 교육자의 피가 흐르는 것 같다. 현업에게 기술적인 교육을 하거나 후배들에게 무언가를 가르칠때 많은 보람을 느낄때가 많다.)
    한번은 그런 강조와 설명이 지나쳤던 적도 있다. 그래서 도망다닌 후배도 있다. (ㅋ)
    후배가 생겼을때부터 그들에게 IT에 관련된 이야기할 때는 그 사람의 레벨에 맞추어서 이야기해야 한다는 것을 깨닫는다. 몇 번 이야기를 해보면 이 사람이 어떤곳에 위치해 있는지 대강 알 수 있는 수준이 되었다. 막 입사한 사람들에겐 쉬운단어로 소통을 해야하고 그들이 바라보는 시각으로 설명을 해주어야 한다. 또한, 그 보다 상위 레벨에 있는 사람들에겐 또 그에 맞게 낮춰서 이야기를 해야한다. 때로는 이러한 레벨의 높낮이를 잘못 판단해 실수한 적도 있지만, 최근엔 거희 실수하지 않고 적당한 수준에서 조절한다.

    "좋은 선배가 되는것은 무척이나 어려운일이다. 하지만 노력할만한 값어치는 있다"

    더 보기 좋은 선배가 되기 위해서 노력한다는것은 꽤 어려운 일이다.

    그냥 일만 시키는 선배가 될지, 아니면 일만 떠넘기는 선배가 될지, 또는 실력도 좋고 인간성도 좋고 그들에게 뭔가 더 보탬이 될수있는 선배가 될지는 개인의 노력여하에 달린 것 같다. 이런 내 마음을 아는지 모르는지 어떤 프로젝트에서는 무슨 선동을 한다고 오해를 받을적도 있다. 가끔씩하는 회식자리나 술자리에 참여하더라도 나는 "우리의 본질에 대해서 잊지말자"라는 말을 항상 동료와 후배들에게 각인시킨다. (그런 나를 선동자로 몰아붙였던 어떤 PM에게 참으로 억울하다는 이야길 하고 싶다.) 그리고 그들에게 놀 때는 놀고 확실하게 일할때는 일하고 공부할때는 공부하자는 마인드를 심어주려 노력한다.
    개인적인 모임을 통해서 스터디를 꾸미려고 노력도 많이 해 보았다. 하지만, 나처럼 지식적인 갈구를 하는 사람은 별로 없었다.
    스터디에 대해서 크게 기대하던 후배들도 몇 명 있었지만, 그들도 하는 일이 SI라서 일회성 결심에 지나지 않았다. 그들을 끌어주기 위해서 한번 제대로 된 스터디 그룹을 갖고 싶어했다. 그리고 내 지식을 물려주고 소통하고 같이 공유하고 싶었다. 그리고 또 다른 차원에 있는 사람들에게 배우고 또 공유하고 소통하고 싶었다. 배우고 공유하고 소통하고, 배우고 공유하고 소통하고, 배우고 공유하고 소통하고 그것이 그때는 전부였다.

    "만나면 헤어지고 헤어지면 만나는게 인간사,
    기술보다.사람..그것부터 모든것이 시작이다."


    하는 일이 프리랜서라 잦은 프로젝트 이동때문에 또 이들과 헤어졌고, 다시 새로운 사람을 만나야만 했다.  만남이 있으면 헤어짐이 있고, 헤어짐이 있으면 만남이 있는 것이다.
    그리고 또 새로운 사람들에게 그러한 것들을 물려주고 또한 그들에게서 영감을 얻는다.
    한번은 내 직업자체가 잦은 이동과 출장을 나가야 하는 직업이라서 신세한탄이나 푸념을 늘어놓기도 했다. 어떤 새로운 조직에서는 그런 새로운 만남도 무뎌질대로 무뎌져서 더이상 새로운 만남을 원하지도 않았다.
    프로젝트가 장기라면 좋겠지만, 단기 프로젝트가 종종 있어서 진득하니 사람들을 사귈 기회가 좀처럼 주어지지 않았지만, 쭈욱 연락하고 지내는 동료와 후배가 있어서 참으로 다행인 것 같다.
    그들은 나에게 많은 관심을 두려한다. 그리고 나도 그들에게 많은 관심이 있다.
    서로에 대해 관심이 있을때 소통할 수 있으며 결국 같이 지향하는 그곳에 다다를 수 있다고 생각한다. 비록 일터에서 만났지만 난 그들을 신뢰하고 서로간에 도움을 줄 수 있는 사람이란것에 만족한다.
    하지만 아직 이들과 같이 애자일이나 XP, 또는 짝프로그래밍이나 TDD를 이야기할만한 수준의 동료는 나에겐 없다. 하지만 기술이 전부는 아니니 인간적인 형으로써 또는 친구로써 이들을 대하고 있다. 그들도 곧 터닝포인트를 갖고 순회하리라 난 믿어 의심치 않는다. 그들이 그 쟁점에 다다랐을때 나는 또 서포트를 해줄 것이고 또 새로운 장르에 대해서 이야기 할 것이다.
    그리고 제발 퇴색되어 가는 한국의 IT현실에서 그러한 열정과 도전들이 암흑의 나락으로 내동댕이 쳐지는 일은 없을것이라고 확신한다.
     

    글이 좀 많이 길어졌다. 아..진짜 길어졌다.
    깨작거리고 싶어서 쓴글이 무척이나 길어졌고 건조해졌다는 것을 지금 깨달았다. 
    이어서 다음 포스팅에 진짜 하고 싶은 말을 할 것이다.

     


     

    저작자 표시 비영리 변경 금지
    신고
    크리에이티브 커먼즈 라이선스
    Creative Commons License
    블로그코리아에 블UP하기
    1. Favicon of http://blog.doortts.com BlogIcon doortts

      2010.09.03 09:38 신고 [수정/삭제] [답글]

      쉽지 않은 환경에서도 노력하셨던 모습이 상상이 갑니다.:) "좋은 선배가 되는것은 무척이나 어려운일이다. 하지만 노력할만한 값어치는 있다"는 말씀도 인상깊었습니다. 기다림의 미학을 가지신것도 배울점이라 생각했습니다. 좋은글 감사합니다.

      • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

        2010.09.03 20:14 신고 [수정/삭제]

        그동안 매 프로젝트에서 가치를 가지고 일하려고 애를 많이 썻었었요. 알아주는 사람 한명도 없었지만..ㅋ
        문득 생각이 나서 글을 쭈욱 적어 내려갔는데, 읽어 주셨다니 정말 감사합니다.^^

    2. Favicon of http://kimkoon.tistory.com BlogIcon 김꾼

      2012.01.10 14:56 [수정/삭제] [답글]

      관리자의 승인을 기다리고 있는 댓글입니다

    댓글을 남겨주세요.

    소프트웨어 관리자가 봐야할 필독서와 URL

    Posted at 2010.08.21 15:13 // in Project Life // by MOOVA 무바㏇
    때로는 관리자들과 실무에 대해 이런저런 이야기를 하면서 소프트웨어 방법론뿐만이 아닌, 도메인 특화된 관리방법을 발굴시키고자 고심을 할 때가 많습니다. 상생을 위해서 더 좋은 방법이 없을까? 그러기 위해서 개발자가 관리자를 바라보는 시각과 관리자가 개발자들을 바라보는 시각에 대해서 많은 개선점이 필요하다는 것을 느꼈고,
    그동안 관리자가 갖고 있어야 할 역량이나 개발자의 역량등을 개선하기 위해 지속적으로 관련된 사항을 살펴보고, 조금씩 팀 내에 적용해 보고 싶었습니다. 또한 관리자가 개발자에게 편견이 있는 평가를 하는 곳을 많이 보았습니다. 객관적인 평가가 아닌 상당히 주관적인 평가겠지요, 이것을 방지하기 위해선 관리자도 관리자 역량을 자체적으로 평가할 수 있는 시스템을 도입해서 관리자에게 필요한 역량과 자질, 스킬을 되 묻는 시스템을 마련해야 할 것입니다.

    소프트웨어 관리자들에게 그동안 눈여겨 봤었던 사이트와 책자 몇 가지를 소개할까 합니다.


    1. 12Manage.com

    2010:08:21 11:05:49

    자주들어가는 사이트입니다. 12가지 관리자가 갖추어야 할 역량에 대해서 카테고리별로 잘 정리해 놓고 있습니다.
    주 정보는 있지만, 세부정보는 없는 게 단점이긴 하지만 팀내에서 활동하고 있는 관리자나 팀장이라면 한번쯤 숙지해야 할 내용이 잔뜩들어 있습니다. 실무 관리자라면 카테고리별로 어떤 역량을 키울지 또는 어떤 서적이나 프로젝트를 참고해야 할지 감을 잡게 해주는 사이트입니다.

    2. scrumalliance.org

    2010:08:21 11:14:17

    Scrum과 관련된 기사가 기재되고 있습니다.  http://www.scrumalliance.org/articles
    북마크 해두면 좋을 듯

    3. 그밖에 북마크하고 있는 사이트

        http://www.PMPCafe.com 
        http://www.epmforum.com
        http://www.agilealliance.org/
        http://www.agile-online.org/
        http://www.agilemodeling.com/
        http://www.scrum.org/scrumguides/
        http://xprogramming.com/index.php

    LG CYON | KU9100 | Normal program | Unknown | 2010:08:21 11:41:30

    4. 2007년도에 탐독했던 책입니다.
    프로젝트관리의해법
    카테고리 경제/경영 > 경영전략 > R&D경영/CFO
    지은이 J 데이빗슨 프레임 (한언, 2007년)
    상세보기


    이 책이 강조하는 것은 새로움입니다. 즉, 복잡한 비즈니스 환경에서 성공적으로 업무를 수행하려면 프로젝트 관리자는 새로운 기술을 습득해야 한다는 것입니다. 과거의 프로젝트 관리자는 일정관리,예산,인적/물적자원의 배분 들의 영역에 관한 기술을 가지면 되었습니다. 따라서 프로젝트 관리자는 간트차트, PERT/CPM 네트워크, 누적비용곡석, 책임 매트릭스들을 이해하고 활용한다면, 프로젝트 수행에 필요한 충분한 지식을 가진 것으로 간주되었습니다. 그러나 그것은 단순한 수행자로서의 역할에 따른 지식이었습니다. 프로젝트관리자들이 새로운 기술들을 배우고 익히는 데 투자한다면, 이러한 능력을 발달 시킬 수 있을 것입니다. 결과지향적인 태도보다 융화지향적인 태도로 변모해야만 합니다. 프로젝트에서는 기법과 기술들을 터득하는 것만으로 성공하는 것이 아니란 것을 잘 아시죠?
    이제 관리자도 선의의 관리를 배울 때라는 거~

    5. 2004년에 탐독했던 책입니다. 
    논리의기술(바바라민토)
    카테고리 자기계발 > 자기능력계발 > 창의적문제해결
    지은이 바바라 민토 (더난출판사, 2004년)
    상세보기

    "왜 말을 안 들어?" , "왜 내 말을 안 듣지?" 툴툴거리는 양은냄비같은 관리자를 상당히 많이 봐왔습니다. 왜 사람들이 따라오지 않는지, 또는 왜 말을 듣지 않는지. 당장의 현실만 바라보고 답답해하는 관리자들이 봐야 할 책입니다. 현실을 인정하고 무엇이 잘못되었는지 분석할 수 있는 역량이 갖추어져 있다면 실제로 문제가 무엇인지 그리고 어떻게 해답을 찾을 수 있는지 실마리를 제시하고 정리해 줄 수 있는 책이라고 생각합니다. 일정은 촉박하고 기간은 짧은데 위에서는 닦달하지, 개발자들은 말을 안듣지.. 답답하시죠?
    개발자의 시각을 이해하고, 경영자의 시각을 이해하는 길은 현실을 주관적이고 감정적인 태도가 아닌, 객관적이고 논리적으로 판단할 수 있는 역량입니다.

    6. 2009년에 탐독한 책입니다. 
    소프트웨어공학의사실과오해
    카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
    지은이 로버트 L. 글래스 (인사이트, 2004년)
    상세보기

    100% 공감된 책입니다. 이론적인 방법론이나 규칙보다 실무에서 얻었던 경험으로 공학에 대해서 설명한 책입니다. 상당히 고급스러운 지혜가 들어 있습니다. 소프트웨어 공학의 탈무드라고 해도 과언이 아닙니다. 아직도 많은 관리자가 전통적인 방법에서 사용하던 것을 개발자들을 통제하고 관리하려 합니다. 하지만 이것은 현실에 전혀 맞지 않고 딱딱한 것만을 강조하는 병폐입니다. 이러한 상황이 개선될 조짐은 전혀 보이지 않죠? 프로젝트를 발주하는 회사와 프로젝트를 수주해 시행하는 회사의 입장, 경영진과 팀의 입장,관리자의 입장에 따라 각기 생각하고 주장하는 바가 다릅니다. 프로젝트의 성공이란 스킬과 기술을 익히는 것 이외에도 공통 목표를 가지고 각 이해당사자를 더 포괄적으로 이해시키고 융화시킬 때 정말 잘했다는 칭찬을 들을 수 있지 않을까요?

    7. 2006년에 탐독한 책입니다. 
    사용자스토리
    카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
    지은이 마이크 콘 (인사이트, 2006년)
    상세보기

    많은 프로젝트에선 일하는 방식에 문제가 있습니다. 공식만을 가지고 팀을 관리하려 합니다. 공식적인 프레임웍이 있으니 그 프레임웍을 팀 내에 도입해서 성과를 달성해보자는 팀들이 꽤 많은 것 같습니다. 하지만 이것은 상당히 잘못된 방식입니다. 공식보단 원리를 깨우쳐 원리를 통해 응용할 수 있을 때 그것이 진정한 지혜라고 할 수 있습니다. 무턱대고 스크럼이니, 애자일이니, 버그트래킹 시스템이 좋아보여 프로세스도 정비되어 있지 않은 곳에 부랴부랴 도입하는 것보다 왜 그러한 방법들이 나왔고, 왜 그런 방법들을 터득해야만 하는지, 또는 그런 방법들이 우리가 사용하면 어떤 이점을 얻을 수 있을지, 딱 맞는 방법론은 없겠지만 우리 조직에 필요한 것은 진짜 무엇인지 과감하게 버려고 시도해야 하는 자세가 필요하다고 생각합니다. 이 책도 공식보단 원리에 초점을 맞추었습니다. 사용자의 시각으로, 또는 고객의 시각으로 보여주는 것이 다가 아닌 진짜 알짜배기 소프트웨어를 건네줄 수 있는 로드맵을 제공해 주는 귀한 책입니다.

    8. 2008년에 탐독한 책입니다. 
    THEARTOFPROJECTMANAGEMENT마음을움직이는프로젝트관리
    카테고리 컴퓨터/IT > OA/사무자동화 > 오피스 > 프로젝트관리
    지은이 스콧 버쿤 (한빛미디어, 2006년)
    상세보기

    2006년에 Jolt Award를 수상한 책입니다. 수상한 네임밸류답게 관리자들에게 꼭 필요한 지식과 지혜를 일깨워주는 값진 책입니다.
    경험있는 팀 리더와 관리자, 초보 팀 리더와 관리자,프로그래머/테스터, 비즈니스 경영관리 제품 설계, 소프트웨어를 공부하는 학생 모두 참고했으면 합니다. 프로젝트 내 존재하는 모든 상황과 기술적인 문제, 정치적인 문제, 위험요소,변화관리등 프로젝트를 악용하려 하는 분들에게 진짜 마음을 움직이는 프로젝트란 무엇인지 깨닫게 해주는 책입니다.

    9. 2007년에 탐독한 책입니다. 
    소프트웨어프로젝트생존전략
    카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
    지은이 스티브 맥코넬 (인사이트, 2003년)
    상세보기

    이 책은 소프트웨어 프로젝트와 관련이 있는 모든 사람을 위한 책입니다. 소프트웨어 프로젝트에서 성공하기 위한 첫걸음은 성공이냐 실패냐의 문제가 아닙니다. 그것보다 더 근본적인 생존의 필요성을 인식하는 것이 중요합니다. 개발자들에게 자아의식을 부여해주고, 관리자들에게 활력 있는 팀의 역동성을 부여해주고, 생존 욕구로부터 더 고급단게인 자아실현을 할 수 있게 감을 주는 책입니다. 프로젝트 전 공정에서 나타날 수 있는 이해당사자들의 충돌을 예방하고 더 나은 결과를 내고 싶으신가요? 이 책으로 감을 잡으세요:)

    10. 2008년부터 프로젝트를 할 때마다 들고 다녔던 책입니다. 거의 애장일의 바이블이라고 해도 과언이 아니죠^^
    불확실성과화해하는프로젝트추정과계획규모추정,우선순위,일정배치
    카테고리 컴퓨터/IT > OA/사무자동화 > 오피스 > 프로젝트관리
    지은이 마이크 콘 (인사이트, 2008년)
    상세보기

    소프트웨어 관리의 지혜를 얻을 수 있는 제가 가장 강력히 추천하는 책입니다. 소프트웨어 계획부터 추정, 우선순위 결정, 스토리 분할, 일정의 배치와 이터레이션 계획, 의사소통과 커뮤니티의 역할, 애자일에 대한 인식을 고취할 수 있는 지혜가 담겨 있습니다. 항상 변화되고 미래를 예측할 수 없는 프로젝트에서 관리자들이 불확실성을 제어하고 화해할 줄 아는 스킬을 가지고 있다면 경영자나 개발자나 공통의 선의의 목표로 한 걸음 더 나아갈 수 있지 않을까요?(물론 그것이 쉬운일은 아닙니다.)
     애자일 방법론이 궁극적으로 지향하는 바가, 고객에게 최선의 가치를 전달하는 것입니다. 프로젝트의 프로세스도 정리되지 않은 상태에서 무턱대고 스크럼을 배껴와서 시행하고, 무턱대고 애자일 툴하나 사서 도입하고 하는 것보다, 진짜 고객이 원하는 가치(알짜배기 소프트웨어)를 전달해 주어야 하지 않을까요? 우리회사에 스크럼이 좋을지 워터풀이 좋을지 먼저 회사의 문화를 분석하는 자세부터 키워야 할 것입니다. (워터풀도 때로는 좋은 방법론이 될 수도 있기때문입니다.)
     

    저는 소프트웨어가 굉장히 광범위한 분야이고 또한 정해진것이 없다고 생각합니다. "일정이 촉박해서", "요구사항이 바뀌니까.." 등등 이러한 이유로 소프트웨어를 못하겠다는 기사를 본 적이 있습니다. 하지만 그들은 진짜 변경되어야 할 것에 대해서는 언급하지 않더군요. 누군가 때문에 소프트웨어가 변경되었다고 툴툴대는 것 이외에 진짜로 변경되어야 할 부분들 까지 비관적인 태도를 고취한다면 별로 좋아보이지 않습니다. 이 책을 읽음으로써 관리자와 개발자 사이의 오해를 줄이고 그 갭을 더 좁혀나갈 수 있으리라 봅니다.

    저작자 표시 비영리 변경 금지
    신고
    크리에이티브 커먼즈 라이선스
    Creative Commons License
    블로그코리아에 블UP하기
    1. Favicon of http://minimonk.net BlogIcon 구차니

      2010.08.21 20:28 신고 [수정/삭제] [답글]

      저는 개발자의 입장에서
      프로젝트가 원활하게 돌아가고, 안정적으로 유지가 되며,
      개발자가 편한 개발환경을 위한 프로젝트 관리에 관심이 있어서 요즘 책을 찾고 있었는데
      위에있는 녀석들을 한번 후다닥 읽어봐야겠어요 ㅎ

      • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

        2010.08.28 08:15 신고 [수정/삭제]

        모든 사람들이 관점의 차이가 있듯, 저 마다 자신의 관점이 있는것 같군요. 꼭 개발자들에게 좋은 환경을 줄 수 있는 세상이 올 수 있었으면 좋겠습니다. 저 택들이 후다닥 읽을 종류의 것은 아니지만 ㅋㅋㅋㅋ. 저 책들이 구차니님에게 도움되리라 믿습니다.^^

    2. Favicon of http://kindtis.tistory.com BlogIcon 친절한티스

      2010.08.26 09:01 신고 [수정/삭제] [답글]

      저희 팀 PD님께서 좀 읽어봐주셨으면 하는 책들이네요.
      첫 PD 직에 그래픽 출신이라서 그러신지 이런거에 너무 문외한...
      버전관리 프로그램 조차 쓰자고 쓰자고 해도 귀찮고/몰라서 안쓴다고 할 정도니...
      (최근에야 기획팀에 버전관리 프로그램 억지로 도입시켰다고 말하면 믿는 사람이 없다는... 게임 어떻게 나왔냐며 놀라더군요)

      • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

        2010.08.27 08:28 신고 [수정/삭제]

        그 답답함 이해합니다.
        그냥, 현실에 안주하는 스타일의 팀장이 위에 앉아 있을 경우 그 답답함은 이루말할 수 없을 정도지요.. 쩝..
        그런것들은 하지 않는것보다 하는게 더 이득인데 말이예요(일찍퇴근,마찰저하 등등). 전 티스님같이 깨어있는 사람덜이 잔뜩 나왔으면 좋겠다는~

    3. Favicon of http://ecogeo.tistory.com BlogIcon 에코지오

      2010.08.27 15:29 신고 [수정/삭제] [답글]

      헉, "논리의 기술"책 오래전에 사뒀다가 결국 한장도 못읽고 얼마전에 중고로 팔아버렸는뎅... 한번은 읽고 팔걸 그랬네요.. ㅠ.ㅠ
      그외 좋은책 소개 감사합니다. 마지막에 소개하신 "불확실성과..." 요책이 땡기네요. ^^;

      • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

        2010.08.28 15:36 신고 [수정/삭제]

        안녕하세요.~ 블로그 잘 보고 있구요.서영아빠님께서 제공해주신 서비스 아주 잘 이용하고 있습니다. ㅎ
        진정한 아키텍트의 길이란 진정 어렵고 험난한것 같아요. 쩝..

    댓글을 남겨주세요.

    어설픈 관리와 갑이 되고 싶은 마음.

    Posted at 2010.08.20 11:14 // in Project Life // by MOOVA 무바㏇
    2010:08:21 06:28:14


    사이버XX텍X이라는 피시방이름의 어설픈 솔루션 회사에 투입되었을 때의 일이다.

    이곳은 프리랜서나 외부 협력업체에 대한 관리를 처음 해 보는지라 관리적인 방법과 개발자를 다루는 스킬이 다른 대기업에 비해서 매우 부족했다. 관리자가 해야할 역할중에서 꼭 해야 할만한 일은 하지 않고, 이른바 "나도 드디어 갑이 되었다"라고 신이난 탓인지, 외부 프리랜서들과 협력업체들에게 별안간 찾아온 왕의 기쁨을 사방에 뿌리고 있었다.

    또 이 관리자들은 어찌나 부패한지 프리랜서들에게 선물을 요구하는 간접적인 행위도 일삼았다.


    개발자들이 어떻게 작업을 하는지 감시가 매우 강했던 곳이여서, 개발자 피시까지도 매번 감시를 당하고 있었다. (이 모니터링의 대한 확실한 증거가 있으므로 다른 토는 달지 말도록 하자 )
    무늬만 관리자였던 그들은 2~3개월에 끝낼 수 있는 Task를 2주안에 해결하라는 강압적인 요구를 하고 있었으며, 심지어는 Task를 끝낸 직후마다, 실시간으로 모니터링을 해 개발자가 어떻게 작업을 끝냈는지, 또는 어떤 경과로 마무리를 하고 있는지 모니터링을 통해서 모든 것을 몰래 훔치고 있었다. 


    "알 수 없는 조직문화, 부패한 조직문화"

    2010:08:20 08:54:29

    중간에 빨간색 개발자들은 프리랜서 또는 협력업체 직원들이었다.

    이 회사는 외부의 엔지니어들과 함께 일하는 방법을 익힌지 1년도 채 안된다고 했다. 프로젝트에 대한 경험이 매우 적어서 대부분의 피시방 개발자들은 그동안 자신이 겪었던 개발자의 증오를 외부의 개발자들에게 마치 한풀이라도 하는 듯, 일거리를 떠넘기고 있었다. 까만색부분의 개발자들은 빨간색부분의 개발자들을 심리적으로 압박하고 있었고,빨간색 개발자들이 Task를 받아 일을 진행하고 마무리할 때마다 사방에서 "손가락을 딱딱 거리는 신경전"을 벌이고 있었다. 매우 보기 흉했던 모습이었다.

    하루는 이들의 일일 보고서를 살펴보았다.
    빨간색 개발자(외부인력)나 검정색개발자(정직원)들은 각기 맡은 Task가 있었음에도 불구하고 항상 업데이트를 하는 것은 외부 개발자들 뿐이었다.  (아마 간만에 검정개발자가 '을'행세를 하려하다보니 90%가 개발자에서 PM이 되고자 했던 것일까?)
    피시방 개발자들의 일일보고서는 바로 어제것을 복사해서 오늘 일일보고서로 붙여넣기한 흔적이 다분했고, 윗선에 보여주기 위해 스토리 카드라는 포스트잇을 벽면에 붙이어 실제로 애자일스럽게 프로젝트를 진행하는 것처럼 위장하기도 했다.  외부개발자들의 일일보고서는 항상 업데이트가 되어 있었던 반면, 검정개발자들은 1달 전이나 2달전이에 항상 똑같은 Task만 채워져있었다.윗선에 보여주기 위한 그런 일일보고서였다. 


    "갑이 되고 싶었던 마음"

    자신들의 회사가 어떻게 저떻게 갑이되어 프로젝트를 진행했다고 치자!, 결국, 민심을 잃으면 프로젝트는 산으로가기 마련이란것을 왜 깨닫지 못할까?. 매우 불법적이고, 노동법에도 위반되는 사항을 스스럽없이 한 문화..
    외부개발자들에게 감시와 모니터링을 통해서 자신의 코딩스킬이나 작업방법을 몰래 훔치면서 스스럼없이 하면서도 아무런 죄의식을 느끼지 않고 있었다.

    이 검정 개발자들이 하는 일이라곤 외부개발자들이 신나게 개발을 하는 와중에도 옆에서 히히덕덕거리면서 말만 정말 많았고, 지금 프로젝트를 하고 있는 것인지 아니면 외부개발자들을 사방에서 쪼면서 자신들이 해야 하는 일은 하지 않아도 된다는 심리인지, 정말 하류급의 관리방법과 하류급의 팀웍을 보여줬던 케이스였다.
    ( 이 프로젝트는 지금 내 이력에도 완전히 없앴다. 너무 창피한 프로젝트였기 때문이다. )
    뽑아먹을것은 다 뽑아먹는 전형적인 부패한 소프트웨어 회사라는 점은 확실했다. 

    "그래도 컨설팅을 해 주다".

    대게 이런 파국 직전의 문화가 있는 소프트웨어기업은 제 아무리 컨설팅을 해 주려해도 바뀌지 않는다는 진리가 있다.
    AA나 TA는 큰 숲보다는 여전히 코드만을 볼 줄 아는 사람들로 채워져 있었고, 소프트웨어 목적을 상실한 눈에 보여주기식의 Task들만 3배로 늘어나고 있었다. 공학적인 방법과 경험을 이야기하려해도 이해하는 사람이 없었으며, 항상 말만 많았던 그들의 소프트웨어를 유심히 관찰해 보면 기본적인 CRUD중에 C조차도 제대로 구현하지 못한 사람이 허다했다. 대학원을 나왔다고 하는 어떤 개발자는 POJO에 대해 이야기 하려 했으나 우린 그런 단어 몰라요. 우린 그런 단어 안써요..라고 정색을 했다. (범용과 도메인특화조차 이해하려 하지도, 이해할 수도 없는 벽에 둘러쌓인 대학원생이었다.) 프로젝트 패턴, 방법론을 이야기해도 전혀 먹혀들지 않았다. 갑인 한진해운, 을인 사이X로지X. 갑은 을에게 무엇을 믿고 소프트웨어를 맏겼는지 의아해 할 정도였다. 그러면서 모든 소프트웨어 영역을 프리랜서에게만 의지하니 문제는 심각해도 정말 심각했다.TA가 만든 문서를 보고 실망했던 것은 프로젝트와 관련된 공통 로직이나 API,또한 애플리케이션 아키텍트가 당연히 해야할 기본적인 소양조차 꾸며놓고 있지 않았다. 이들이 얼마나 내실보다는 외실을 따졌는지 이해할만 하겠는가?
    결국 난, 이곳에서 확장된 애플리케이션 아키텍쳐를 건설해 주었고, 그에 맞는 문서까지 제작해 줬으며 신입 몇명에게 컨설팅을 해 준 상태였다. 하지만 이 조차도 이해할 수 없었던 2년차 PM은 아직도 물과 불을 구별할 수 없었으리라 본다.




    "잊지말자. 프로젝트란 결국 사람을 위한 것이다".

    갑이 되고 싶었던 마음은 이해한다. 관리자는 관리적인 방법을 좀 배우고, 개발자들은 상생이란 무엇인지 다시한번 깨달아봤으면 하는 바람이다. 아마 이들은 아직까지 한진해운에 보여주기 위한 스토리카드로 벽을 도배질 하고 있을 것이며, 애자일한다고 외치고 앉아 있을것이다. 이클립스 기술을 쓰고 인젝션을 쓰고, 또는 버그/이슈 트래킹 시스템을 도입했다고 해서 그게 정말 잘 하고 있는 행동들이었을까?

    결국, 프로젝트란 사람을 위한것이어야 하고 개발자 한 명마다 자신의 위치를 소중히 느낄 수 있게끔 자아의식을 부여해 주어야 한다.

    90%의 개발자가 갑자기 찾아온 을의 기쁨때문에 놀고 먹고 흥청 망청, 나머지 프리랜서나 외부 인력들은 하루하루를 그렇게 열심히 일을 하고 있었던 곳이었으므로, 외부개발자들을 우대해주는 문화도 자리잡혀야 한다. 사방에서 손가락이나 딱딱거리는 행위를 일삼고, 사방의 검정 개발자들이 몇 명 안되는 프리랜서를 닥달하면서, 옆에서 배나 두드리는 행위, 또는 1달에 해야 할 일을 2주만에 끝내라고 하는 강압적인 스타일은 결코 프로젝트를 성공으로 이끌 수 없다. 하나를 보면 열을 안다고, 기에 차지도 않았던 이곳의 관리자는 처음보는 프리랜서들에게도 반말을 찍찍 싸대는 무식한 행동을 일삼았다.

    갑이 되고 싶었던 마음은 충분히 이해한다. 하지만, 제발 본질을 보자.


    2010:08:20 09:35:10
    설령 농담이라도 이따위 사진을 보고 웃지 말자.
    요즘 한창뜨는 이슈중에 개발자들의 면역력저하, 건강 약화, 그리고 인권유린에 대해서 기사가 줄줄이 기재되고 있다.
    좀 상황 파악좀 하고 살자.


    PS1 : 결국 그 피시방 개발자들도 개발자이다. 갑자기 찾앙온 을의 위치때문에 이들 대부분은 개발자에서 PM으로 전향한 듯 보였다. 편히 앉아서 놀고 먹고 일은 프리랜서가 다 해준다. 라는 식이었을까? 갑이 프로젝트를 성실히 하라고 내려줫던 돈을, 을의 인력들은 놀고먹으면서 돈을 갉아 먹고 있었고, 정작 해야할 소프트웨어 보다는 자신의 명줄만 유지하기를 원했다.거짓문서나 포스트잇으로 벽에 떡칠을 하는 이른바 윗선에 보여주기만을 일삼으면 결국 위에서도 욕먹고 외부 개발자들에게도 욕을 먹을 뿐이다. 자신들이 해야 할 일과 외부가 해야 할 일을 정확하게 진단해서 외부개발자나 내부개발자들이 서로 상생할 수 있도록 일의 분량을 공평하게 나누어 주어야 한다.

    PS2 : 아직 저곳은 외부 프리랜서나 소수의 협렵업체만을 쪼는 행위를 일삼고 있다고 있다고 한다. 정작 자신들은 배나 두드리고 옆에서 히히덕덕거리면서 아직도 정신을 차리고 있지 못하고 한다. 거의 막장의 말세다. 난 내 후배들이 저런곳에서 똥만 처들은 소프트웨어를 배울까 걱정이다. 그냥 소프트웨어한다고 하지마라. 한국의 아이티를 좀먹고 있는 정말 창피한  프로젝트중에 하나였다.

    PS3: 해외에서의 전문성이란? 얼마전 우리나라에서 시행된 비정규직관련법과 달리 호주에선 5년~10년동안 계속 기간을 연장하며 비정규직으로 살아가는 사람들도 많다. 또한, 한국과 가장 다른 점이라하면, 비정규직의 연봉이라 하겠다. 호주에서는 비정규직이 정규직보다 20%~50%정도 더 많은 연봉을 받는다. 이는 정규직만이 가질수 있는 1년중 4주 휴가와 병가 및 각종 혜택을 연봉에 포함시켜주는 것이라 생각하면 된다. 많은 젊은이들이 많은 연봉과 쉽게 옮겨다닐수 있다는 이유로 정규직보다는 비정규직을 선호하는 경우도 쉽게 찾아볼수 있다. 그만큼 더 전문적인 영역을 더 원한다는 이야기다. 한 예로, 호주에 어떤 회사에서는 비용절감을 위해 비정규직 7명에게 정규직 PO를 주었지만, 정규직으로 전환한 사람은 단 한명뿐이었으며 다른 6명은 모두 거부했다.
    이것이 본질과 전문성을 더 원하는 해외 IT전문인들의 풍도이다. 이만하면 우리나라 풍토와 많이 다르다는 이야기다.

    저작자 표시 비영리 변경 금지
    신고
    크리에이티브 커먼즈 라이선스
    Creative Commons License
    블로그코리아에 블UP하기
    1. Favicon of http://minimonk.net BlogIcon 구차니

      2010.08.21 20:31 신고 [수정/삭제] [답글]

      쩝.... (무슨 긴 댓글이 필요하려나요 ^^;)

    댓글을 남겨주세요.

    티스토리 툴바