[용병] 가장 기억에 남았던 질문 BEST ⑤

Posted at 2010.09.28 10:49 // in Project Life // by MOOVA 무바㏇
4. 나도 형처럼 용병이 되고  싶어요.

현재 Si에 만 2년차로 근무중에 있습니다. 2년동안 열심히 한 탓에 일에 대한 자신감이 붙어서 프리랜서로 전향하려고 합니다. 어떤 프로젝트부터 시작해야할지..조금 막막합니다. 프리랜서를 하려면 어떤 자질과 능력을 키워야 하는지 궁금합니다. 그리고 프리랜서를 하게되면 파견업무를 주로할텐데, 파견업무가 많이 힘드나요? 프리랜서를 선언하려면 어떻게 해야하나요?

2010:09:25 08:51:27


LG프로젝트를 진행하면서 아끼던 후배가 했던 질문이다. "프리랜서를 선언한다"라.. 참으로 멋진 말이다. 방송국이나 TV프로의 연애인처럼 그 후배는 개발자들도 프리랜서를 공개적으로 선언해서 활동할 수 있다는 인식을 갖고 있었던 것이다.
개발자가 프리랜서를 굳이 선언할 필요는 없다. 자신이 충분히 프리랜서의 자질을 갖고 있다고 생각하면 하면 되는 것이다. 단 자금의 유통이 그렇게 잘 돌아가지 않았다는것만 유념할 필요가 있다. 본인은 프리랜서를 시작할 때 어떤 프로젝트에서 3개월 이상 월급을 못 받은 적도 있었다. 이런 경우 노동부에 알리고 자신의 권익을 보호해야 했지만, 초보 프리랜서 시절 그러지 못했다는 안타까움이 있다. 프리랜서를 지향하는 사람이 가져야 할 좋은 자세 몇개를 추려봤다.

  1. 각종 세미나를 수시로 활용해서 학습의 연결선을 유지하도록 하자.

  2. 현 프로젝트가 끝났다면 추가로 계약할지 아니면 다른 프로젝트를 찾아야 할지 결정해야 한다. 다른 프로젝트를 결정되지 못하고 현 프로젝트를 마무리 했다면 그대로 2개월 이상 놀 수 있다는 것을 염두해야 한다.

  3. 각종 세금명세서와 명함을 정리하는 습관을 들이자.

  4. 계약 진행 과정중 생기게 되는 문서나 프로젝트에서 얻게 되는 문서들을 잘 보관하자. 꼭 나중에 활용할 수 있을 때가 올 것이다.

  5. 자신이 프로젝트에서 했던 일에 대해 근거를 남기자. 본인은 구글캘린더를 종종 사용한다.

  6. 주변 프리랜서들이 최근 관심있어 하는 사항에 귀를 귀울이자. 

  7. 인맥네트워크를 형성하자. 정직이든 계약직이든 프리랜서든 사장이든 어떤 인맥이라도 Winwin할 수 있는 수준이라면 인관관계를 유지하도록 하자. 단! 자신에게 도움은 커녕 피해만 주는 사람들은 멀리하자.

  8. 배풀자. 프리랜서는 가만히 있어도 더 높은 월급을 받고 있기 때문에 주변 무리의 입방아에 자주 오르락 내리락한다. 10년전이나 지금이나 똑같다. 그럼으로 주변 사람들에게 온정을 배푸는 습관을 가지도록 한다. 단 허용범위를 초과해서는 안 된다. 나중에 개털될 수도 있다는 의미

  9. 프로젝트의 인사급들과 친분을 쌓자.

  10. 계약 후 너무 무리한 요구사항이 빈번히 발생된다면 계약서상에 추가 요구사항에 관련된 란을 기입하도록 한다.

  11. 일이 끝나면 공부하자. 공부하고 신기술 익히고 다듬고 노력하자. 본인은 프리랜서라면 실력이 좋아야 한다고 믿는 사람중에 하나다. 눈에 보이지 않게 노력하자.

  12. 소스코드관리를 잘 하자. 한 곳에서 사용했던 노하우나 코드들은 반드시 재사용할 날이 종종 찾아온다. ( 필자는 삼성프로젝트를 나올 때 가지고 있던 소스와 문서들을 몽땅날린 기억이 있다. ㅠㅠ)

  13. 메모하는 습관을 기르자. 개인일정 관리 노트를 관리하는 것도 좋은 방법이고 Sticky pad와 같은 유틸을 쓰는 것도 좋은 방법이다.

  14. 노동법 관련된 법률적 상식을 익혀두는 것이 좋다. 이것을 잘 모르면 악덕사장에게 당할 수 있다. 본인도 당해본 기억이 있다.:) 아웃소싱 근로법이나 노동법 책자를 구매해서 읽어보도록 하자.

  15.  계약서를 쓸 때 초반에 바로 싸인하지 말자. 먼저 계약서를 이메일로 보내달라고 요청하여 계약서에 불공정거래에 관련된 사항은 없는지 미리 파악하자. ( 이거 정말 중요하다.). 실제로 계약서를 쓰는 당일이 오면 어떤 요소들을 수정해 달라고 요청하자.

  16. 계약서를 쓸 때 업체 사장으로부터 날조된 계약서를 쓴적 있다. 그 사장을 믿었던 내가 바보였다. 몇 달 뒤에 집에서 계약서를 유심히 살펴보니 계약기간이 2년이나 더 추가되어 있었다. 아주 작은 글씨로 써져 있었던 것이다. 보이지 않은 계약 노예화가 된 것이다. 이 사건이후 계약서는 꼼꼼히 훑어보는 습관을 지니고 있다.

  17. IT 노동처를 자주 이용하자. 프리랜서는 개인대 기업과의 거래이기 때문에 상당한 불이익을 받을 수 있다. 이것을 보호하기 위해선 공익단체를 활용하는 것도 좋은 방법이다.

  18. 투입전에 미리 프로젝트에 대해 상세히 알아본다. ( 업체들, 인력들, 기술들, 메니저들, 평판들 )

  19. 가능한 한 을 이상의 업체나 이름값을 하는 업체와 계약을 하도록 한다.

  20. 업체가 불공정거래나 인권유린과 같은 행위를 한다면 만천하에 공개한다. 개발자 커뮤니티를 이용하자.:), 녹취를 하고 자료를 보관하자.

더 기억나는 게 있다면 수시로 업데이트 하겠습니다.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[패턴] 가장 기억에 남았던 질문 BEST ④

Posted at 2010.09.27 18:07 // in Project Life // by MOOVA 무바㏇
4. 디자인 패턴을 사용하면 좋나요?

디자인패턴을 동료와 학습해서 제가 맡은 모듈에 적용해 보고 있습니다. 하지만, 아직 감이 잘 오지 않아요. Strategy 패턴을 적용해서 활용하고 있긴 한데, 대체 어떤 점이 좋은지 모르겠습니다. 그냥 사용하는 것보다 적절하게 응용할 수 있는 능력이 필요한데, 아직 수준 미달이라 그냥 학습한 것을 적용하는 수준밖에는 안 돼요. 모든 프로그램에 디자인 패턴을 사용하면 좋나요?

이 질문은 다음의 책자로 대신한다. 패턴과 리펙터링에 대한 좋은 로드맵을 받을 수 있다.
필자는 이 책을 사서 지나가는 후배를 빌려주는 바람에 얼마전 다시 한번 구입하기도 했다.
오늘 RSS를 확인해 보니 이 서적으로 스터디를 시작한 곳이 있다. 파이팅하길.~

패턴을활용한리팩터링
카테고리 컴퓨터/IT > 컴퓨터공학 > 디자인패턴
지은이 조슈아 케리에브스키 (인사이트, 2006년)
상세보기


디자인 패턴을 학습해서 사용하는 것은 좋은데 패턴자체를 무조건 맹신하는 태도는 좋지 못하다.
필자도 예전엔 프로그램에 디자인 패턴을 도입하면 그 자체로 개인이나 팀의 가치를 올릴 수 있다고 생각했다. 그래서 디자인패턴을 수시로 난발했다. 이 관점을 버리기까지 많은 시간이 필요했는데 실제로 쓰지 말아야 할 곳에 디자인패턴을 적용하여 오히려 시간과 노력 그리고 복잡성만을 증가시켰던 경험을 해 보았기 때문에 패턴사용의 무조건적 맹신에 대해 그다지 찬성하지 않는다.

"따라서 Refactoring to Patterns을 읽을 때 상당히 공감된 부분이 많았고, 깊은 감명을 받았다."

한번은 팀 내에서 PDF를 출력하는 개발을 하고 있었다. 이때 사용했던 라이브러리는 Apache iText였는데 다단계 계층의 컨덴츠를 손쉽게 산출하기에 좋은 API로 구성되어 있었다. 난 이 라이브러리를 가지고 같은 팀 내의 개발자와 짝 프로그래밍과 리팩터링(SS의 wonbo님^^)을 하면서 지속적으로 유틸리티 모듈을 만들어내고 개정하고 있었다. 결국, 공통의 슈퍼클래스와 여러 개의 서브클래스로 구성된 하나의 모듈이 완성되었다. 서브클래스로 구성된 것들은 객체의 생성은 각각 달랐지만 엘리먼트를 생성하는 알고리즘은 비슷했기 때문에, 객체를 생성하는 createObject(Object... object) 메소드를 move method로 슈퍼클래스로 이관시켰다. 그리고 그것을 abstract로 변형시켰고 슈퍼클래스는 자동으로 추상클래스가 되었다. 이것을 상속한 서브클래스는 createObject만 제정의 하면 나머지는 알아서 처리해주는 소위 Factory Method 패턴으로 승화시켰다. 다시 생각해보면 그 모듈은 더 이상의 서브클래스는 필요 없었을뿐더러 추가로 발생하는 요구사항도 없었던 것이다. 오히려 Factory Method를 사용해서 시간과 노력을 낭비한 사례라고 볼 수 있다.

실제로 위와 같은 실수는 정말 많았다. 적절하게 사용했다고 자부했던 코드들도 나중엔 분명히 수정을 가해야 했으니, 제3자의 평가가 없는 곳에선 그것들 적절하게 사용했다고 볼 수는 없다.

패턴 사용의 노하우를 키우기 위해선 실무에 활용했던 경험이 필수다. 그래야만 적절한 곳에 적당한 패턴을 도입할 수 있게 된다. 물론 나조차도 아직까지 이런실수를 하고 있고 앞으로도 그럴것이다. 하지만 예전 패턴을 맹신했던 어릴적 시절보다 지금은 더 현명하게 패턴을 사용하고 있다고 생각한다. 패턴의 진정한 승부는 실수를 통해 시기적절하게 사용했을 때 그 빛을 달한다. 어떤 무술의 고수가 정권찌르기를 하루에 만번이상 연습하는 것처럼 패턴사용도 수십 번 혹은 수천 번 사용해서 실수를 경험해 봐야 진정한 설계/개발자로서 거듭날 수 있지 않을까?



1. 디자인패턴은 습관적인 리펙터링을 통해 점진적으로 개선 / 발전할 수 있다.
2. 리펙터링과 디자인패턴은 상호보완 관계
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[학습] 가장 기억에 남았던 질문 BEST ③

Posted at 2010.09.27 17:50 // in Project Life // by MOOVA 무바㏇
3. 개발공부를 어떻게 해야하나요?

여러 선배의 코드를 보면 제각각입니다. 그냥 복사해서 붙여 넣은 사람들이 대부분이고, 프레임웍을 사용한 프로젝트에서는 개발자 개개인의 코딩 특색은 점점 사라지는 것 같아요. 프로젝트에 코딩 규칙이라고 정해놓았지만, 그것도 자신의 코딩 실력을 키우는 데는 별로 도움을 못 주는 것 같아요. 정교한 코드를 만들어서 남들이 볼 때 참 잘 만들었다는 느낌이 들 수 있도록 실력을 키우고 싶은데, 어떤 노력을 해야 하는지 궁금합니다.

그동안 수십번씩이나 개발자로부터 받았던 질문 중 하나에 속한다. 사실 이 질문을 접했을 때 본인은 얼굴이 붉어졌다. 개인적으로 생각할 때 그렇게 최고급 수준의 질 좋은 코드작성 능력은 모두 국외 오픈소스로부터 배운게 전부이다. 그래서 남들보다 월등한 코딩 실력을 갖고 있다고 생각지는 않다.한국개발자들의 코드의 수준은 잘 모르겠지만, 매번 연습했던 해외 오픈소스에서 쏟아져 나오는 질 좋은 코드들을 보고 항상 고개를 숙였던 그런 나였기 때문이다. 하지만, 주변사람들과 선배들이 오승택이는 개발하나는 딱 부러지게 했었다는 평들이 많았기 때문에 그 힘을 빌려서 몇 자 적어보고자 한다.

본인이 생각할 때 개발자들은 코드를 작성 하는것에 너무 집중한다고 생각한다. 창조적으로 코딩하든, 복사해서 붙여넣기로 코딩하든, 분기문이나 루프문 메소드 생성규칙만 알면 누구나 쉽게 개발을 할 수 있다. 하지만, 저 사람이 '개발을 잘 한다'는 타이틀은 얻기 어렵다. 왜 그럴까? 코드를 작성하려는 노력만 기울이다 보면 어느새 자기만의 세계에 빠지기 십상이다. 내가 잘하는지 못하는지도 모른 채 평생을 그 자리에서 맴돌 뿐이다. 운이좋아 코드리뷰나 짝 프로그래밍을 할 때는 쉽사리 동조하거나 함께 가려는 사람은 매우 드물다. 왜 그럴까?

본인이 신입 개발자나 이 일을 막 시작한 이들에게 강조하는 것은 코드를 작성하는 노력보다 코드를 분석하는 것에 더 많은 시간을 투자하라고 한다. 국외 오픈소스를 분석하면 단기간에 자신의 코드의 질을 향상할 수 있다고 장담하기 때문이다. 사실 국외 오픈소스의 코드의 품질은 세계적인 명석들이 작성한 것도 많으므로 그것을 눈앞에서 볼 수 있다는 것을 영광으로 생각해야 한다.그래서 최근엔 주변개발자들이나 후배들에게 국외 오픈소스코드를 다운로드 받아 실제로 그 짜임새가 어떻게 구성되어 있는지 분석하라고 당부한다.

두 번째 해야 할 일은 리팩터링의 연습이다. 코드에서 냄새가 날 때 바로 리팩터링할 수 있는 습관을 들여야 한다. 너무 잦은 코드의 수정은 별로 좋지 않은 습관이지만 주기적으로 적당한 리팩터링을 해 나가면 개인의 깨달음 수준에서도 그렇고 제품의 품질면에서도 보장할 수 있는 수준의 코드를 생성해 낼 수 있다. 

세 번째는 주변 실력있는 개발자들의 코드를 분석하는 일이다. 가끔 주화입마에 빠진 개발자들을 만나면 꼭 그들의 코드부터 살피자. 분명히 값어치 있는 코드 기법들이 쏟아져 나올 것이다.

네 번째는 코드의 품질을 높일 수 있는 서적을 참고한다. 본인이 가장 기억에 남았던 관련된 책으로는 Code Complete, Refactoring, Pattern and Refactoring, Design Pattern(GOF)을 꼽는다. 원리와 기초 사상이 중요하다는 것은 아무리 이야길 해도 지나치지 않다. 리팩터링 관련된 서적은 몽땅 읽어보는 것이 좋다.:)

다섯 번째는 자신의 코드를 주변개발자들과 검증을 통해 개선하는 일이다. 완벽할 수 없는 게 사람이다. 아무리 명석한 두뇌를 가진 사람이라도 실수는 하게 마련이다. 피로와 멍한 상태의 잔존기운이 남아 있을 때 주변 개발자들에게 요청하자. "내 코드 좀 봐 주시겠습니까?"하고 말이다. 절대로 창피한 일이 아니다. 오히려 멋진 일이고 회사의 입장과 개발자끼리의 입장까지 고려한 아주 용기있고 지혜있는 일이라 생각한다.

2010:09:25 07:00:07
그림출처 : 구글

아래의 추천서적은 필자가 적극 추천하는 책이다. 필자도 가끔씩 기억이 가물가물할때 찾아 빼서 읽어보는 소중한 책들이기 때문에 개발에 종사하는 사람이라면 꼭 한번 필독하길 바란다.

리팩토링
카테고리 컴퓨터/IT > 프로그래밍/언어 > 어셈블러/컴파일러/포트란
지은이 마틴 파울러 (대청미디어, 2002년)
상세보기

CodeComplete
카테고리 과학/기술 > 컴퓨터 > 소프트웨어
지은이 McConnell, Steve (Microsoft, 1970년)
상세보기

실용주의프로그래머
카테고리 컴퓨터/IT > 프로그래밍/언어 > 프로그래밍일반
지은이 앤드류 헌트 (인사이트, 2007년)
상세보기

ASPECTJINACTION(엑스퍼터J)
카테고리 미분류
지은이 RANNIVAS LADDAD (그린(윤덕우), 2005년)
상세보기

패턴을활용한리팩터링
카테고리 컴퓨터/IT > 컴퓨터공학 > 디자인패턴
지은이 조슈아 케리에브스키 (인사이트, 2006년)
상세보기

PragmaticUnitTestingInJavaWithJunit
카테고리 과학/기술 > 컴퓨터 > 프로그래밍
지은이 Hunt, Andy/ Thomas, Dave (O'Reilly, 2004년)
상세보기

GOF의디자인패턴
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 ERICH GAMMA 외 (피어슨에듀케이션코리아, 2002년)
상세보기

자바디자인패턴과리팩토링
카테고리 컴퓨터/IT > 컴퓨터공학 > 디자인패턴
지은이 박지훈 (한빛미디어, 2003년)
상세보기

소프트웨어개발의지혜(AGILESOFTWAREDEVELOPMENT)
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 로버트 C.마틴 (야스미디어, 2004년)
상세보기



기타 해드 퍼스트 시리즈와 The Pragmatic Programmers시리즈를 적극 추천한다.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[상세함] 가장 기억에 남았던 질문 BEST ②

Posted at 2010.09.27 13:34 // in Project Life // by MOOVA 무바㏇
2. 빠르게? VS 상세하게?

우리팀은 소스관리를 하지 않습니다. FTP에서 소스를 내려받아 수정하고 컴파일해서 올리는 수준이라, 다른사람과의 마찰이 상당히 많습니다. 그런데도 불구하고 이 체계를 고치려하지 않습니다. 심지어는 자신이 해야할 코드조차도 남에게 보여주기 싫어 개발자 개별마다 눈치를 보며 코드를 올리지 않습니다. 이런분위기에서 상세하게 설계를 하고 구현작업까지 잘 할 수 있을지 의문입니다. 기간은 촉박한데, 상세하게 해야할 설계도 덕지덕지 붙여서 작업하고 있습니다. 점점 팀이 막장을 향해가고 있습니다. 어떻게 해야 할까요?

2010:09:24 20:20:59

프리랜서 친구가 질문했던 내용이다.
위와 같은 분위기는 본인도 수차례 경험해 본적 이 있기 때문에 그 속에서 일한다는 것이 얼마나 비생산적인지 글을 읽는 사람도 공감할 수 있을 것이다. 만약 저런 상황에 자신이 프로젝트리더라면 어떻게 해야 할까? 본인이라면 문제점을 정리하고 우선순위를 부여해서 이슈들을 하나하나 제거해 나갈 것이다. 단 일정이 촉박하지 않다면 말이다. 일정이라는 것은 정말 중요하다. 일을 빠르게 해야하는 것과 상세하게 해야하는 결정도 이 일정이라는 것이 항상 연루되어 있기 때문이다.

기간은 3개월인데 고객이 요구했던 기능은 너무 벅차다. 그래서 상세하게 해야하는 일엔 소홀해지고 오로지 빠른 속도로 일을 마무리 해야할때가 바로 이런때다. 차 후 유지보수나 확장성, 재사용성과 관련된 부분은 나중 이야기다. 일정이 촉박하니까 상세한것 보다 빠른 것에 집중한다. 대부분 이런 환경속에선 우리의 고객은 빠른 결과물을 보기 원한다. 이런 경우 일정을 조율할 시간도 없다. 때론 O군이라는 엔지니어는 이런 환경속에서도 제대로 틀을 잡고 진행하려고 애를 쓴다. 아무리 기간이 짧아도 더욱 상세하게 설계작업을 했을 때 나중에 퍼포먼스가 몇 배나 나온다는 경험때문이다. 하지만, 이것은 어디까지나 이례적인 일이다. 컨설턴트나 SE가 아닌 개발자들은 이렇게 미련한 시도는 하지 말자.|=)

반면 기간이 1년이상이라고 해보자. 제대로 된 회의를 통해서 요구사항을 정제할 수 있다. 특징을 분석하는 일, 기능요구사항과 비기능요구사항을 사전에 정의하는 일, 테스팅과 테스트 시나리오, 용어사전, 개발환경의 선택, 콘텍스트 맵 정의, 공통규격과 표준정의. 교육, 설계리뷰,코드리뷰, 팀 미팅, 분할된 아키텍쳐 정의등등등.. 소프트웨어와 관련된 수많은 단계와 프로세스를 채택할 수 있다. 이런 환경은 정말 행복한 환경이다. 굳이 구현작업을 빠르게 해야 할 필요도 없고 각 단계별로 해야 할 일을 종종 찾아오는 병목현상을 제거하면서 적당히 끝내두면 그만이기 때문이다. 이런곳은 배울점도 많을뿐더러 자신의 캐리어를 상승시킬 수 있는 아주 행복한 곳이다. 한가지 강조하고 싶은것은 큰 프로젝트같은 경우 콘텍스트 맵을 제대로 개선해야 할 필요가 있다는 것인데, 적당한 문맥툴을 도입하면 프로젝트의 문맥을 손상하지 않는 범위내에서 점진적으로 확장 또는 개선해 나갈 수 있다.

빠르게 해야 할지 상세하게 해야 할지는 주변의 상황을 고려한 본인의 선택에 달려있다.
두  가지를 선택하는 갈림길에 앞서 가장 신경 써야 할 부분은 일정이라는 점을 기억하자. 저질 같은 일정이라도 일정은 일정이다.


"가끔씩 두마리의 토끼를 잡으려 하던 미련한 소프트웨어 엔지니어가 한 명 있기도 하지만.."


참고 : 프로젝트에 콘택스트 맵 개선에 효과를 볼 수 있는 툴

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[프레임웍] 가장 기억에 남았던 질문 BEST ①

Posted at 2010.09.27 13:34 // in Project Life // by MOOVA 무바㏇
1. 프레임웍을 사용하고 있지만....

최신 웹 프레임웍을 쓰고 있긴 하지만, 어느정도 시간이 지나면 기술에 대한 흥미가 줄어듭니다. 프로그램 성격상 데이터베이스에 넣고 빼는 것이 전부이기 때문에 반복되는 업무가 지겨워진 것도 한 몫합니다. 웹프로그램에 MVC패턴을 쓰긴 쓰고는 있는데, 그것도 '요청>결과확인'이 전부아닌가요? 요청과 결과확인 x3 ;;;; 항상 똑같습니다. ㅠㅠ

2010:09:24 20:24:45

프로젝트 진행중 친한 후배가 진심이 담긴 표정으로 던졌던 질문이다. (이 질문은 프로젝트에서 수 차례 접했던 질문중 하나에 속한다.) 최신 기술을 쓰고 있긴 한데 디비에 인풋하고 아웃풋하는 반복되는 업무때문에 좀처럼 일의 능률을 올릴 수 없다는 것이었다. 하지만 이 정도 질문을 하는 사람이라면 충분히 생각을 하고 일을 하고 있다는 반증이기도 한데, 역시나 나 조차도 그런 반복되는 일상을 잘 알고 있기 때문에 동질감을 느끼면서 소프트웨어 구조에 대한 이야기를 잠깐 해 주었다.


2010:09:23 22:58:45

그림1. 정형화된 웹MVC

그는 술자리에서 푸념을 늘어놓으면서 벽에 가상의 그림을 그렸다. 일반적인 요청에 결과값을 리턴받는 구조이다. 어떤 요청이라도 콘트롤러를 거쳐야 하며 디비조회 후 생성된 모델을 뷰영역까지 운반하는 정형화된 패턴이다. 이 때 차용했던 이 패턴은 오픈소스의 Best Practice에서 그대로 배껴 가져왔다고 한다.  바로 위와 같이 구축해 놓은 정형화된 패턴 때문에 일이 너무 반복적이고 배울게 없다는 그의 한탄이었다. 어떻게 설명하려 고민하다가 위와같이 정말 재미없는 구조에 넌지시 한가지 도형을 추가했다.

2010:09:23 23:21:50

그림2. 웹MVC에 추상 컴포넌트를 추가한 모습

그가 알고 있는 웹개발영역(티어를 나누어 놓은 개념)위에 좀 더 크게 시야를 확보할 수 있는 추상 기능단위인 콤포넌트를 손으로 그려주면서 웹애플리케이션은 잘만 설계된다면 단순히 요청에 값을 확인하는 일뿐만이 아니라는 것을 지적했다. 사용자가 요청을 하면 매번 디비에서 조회해 오는 단순한 그림을 지우고 애플리케이션 영역에서 작은 기능들을 합치고 분류하면 좀 더 크게 생각의 영역을 그룹지을 수 있는 중요함을 설명했다. 그러자 그 친구의 얼굴에 화색이 돌았다.( 그때 이 후배는 다른이보다 좀 더 이해도가 높은 모습을 보여주었다. 항상 생각하고 일을 하는 그의 근성때문이리라 )

그 친구는 이 하나의 그림으로 설계와 개발이란것이 단순히 요청에 대한 값 확인이 아니라, 보다 응집된 애플리케이션의 모습으로 구축될 수 있다는 희망을 얻었다.  그가 경험하고 있었던 반복되는 일상의 지루함에서 좀 더 가치있는 영역을 탐독할 수 있는 탈출구가 되었으리라 본다. 본인이 의도했던 것은 OOAD의 자세한 단계와 리펙터링 또는 패턴의 발판단계를  설명하려 했지만 이 질문에 포괄적인 답변을 몇마디로 압축하기가 매우 곤란했다.

아마도 이 친구는 그 때 추천해 주었던 서적과 관련된 사상(OOAD,패턴,소프트웨어정제기법)으로 몇 년간 바른 로드맵[각주:1]을 걷고 있었을 지도 모로겠다.

2010:09:24 20:36:50


사실 위의 개념을 제대로 알기 위해선, 소프트웨어 아키텍쳐와 방법론에 대한 지식, 디자인패턴과 프레임웍,OOAD에 대한 충분한 학습이 필요하다. 하지만 위의 추상컴포넌트 그림으로 앞으로 무엇을 해야할지 발판을 마련해 주었다고 본다. 우리가 일하는 영역은 단순노무가 아니란 점, 그리고 시야를 점점 확장하면서 점진적으로 커 나갈 수 있는 정말 값진 일을 하고 있다는 것을 깨달았으면 좋겠다. 단, 개개인의 발전을 수용할만한 곳이 별로 없다는 것이 흠이긴 하다.




그림3. OOAD
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

데이터메니저에 대한 고찰

Posted at 2010.09.09 10:39 // in Project Life // by MOOVA 무바㏇
때로는 유용하고 확실한 솔루션일지라도 켜켜히 조성되고 있는 주변의 분위기를 파악하여 공개되지 말아야 할 때가 있는 법이다. 아무리 그 솔루션이 확실할지라도 말이다.

보통 X-Internet기반의 프로젝트에선 클라이언트 환경의 컴포넌트를 따로 제작하여 개발자들에게 
 API를 제공해주는 모습을 종종 보게 된다. 가우스나 마이플렛폼이나 그것을 사용하는 개발자들은 사용하는 기능들을 몇 개의 패턴으로 분류해서 Copy&Paste를 하는 것이 보통이다. 하지만, 개발자들이 코딩하는 방식은 제 각각이라 프로젝트의 업무규모가 클 때는 해당 벤더사의 컴포넌트를 은폐하여 새로운 라이브러리를 제공해 줘야 할 때가 있다.

LG OSS에서 제공했던 클라이언트 컴포넌트는 데이터메니저(DataManager)라고 하는 일종의 객체화된 자바스크립트 라이브러리였다. (Figure1)

2010:09:09 00:05:09
Figure1. 모든 요청을 처리하려 하는 DataManager의 모습.

처음 이것이 공통팀에 의해 나에게 넘어왔을 때는 색다르게 제작한 그 스타일이 마음에 들었다. 하지만, 그 겉모습에 매료된 나의 기대감은 곧 사라졌다. 객체 라이브러리 안에 중복된 코드와 파라미터들이 난무하는 로직을 보았고, 주요 흐름에 대해서 전역변수를 마구잡이 식으로 가져다 쓰고 있었다. 군데군데 땡빵처리를 한 라인이 수없이 확인됐다. 해당 컴포넌트를 제작한 아키텍트는 이미 공통 대부분의 기능을 나에게 싸인으로 떠맡긴 채 어느새 사라지고 없다. 해당업무를 인수인계 받은 아키도 나름대로 경력은 되었지만, 프로젝트의 수행능력조차도 프리랜서 엔지니어들에게 의존하고 있었으므로, 고스란히 이 업무는 나에게 떠 넘겨져 왔다. (이 업무이외에 이 프로젝트에서는 대부분의 기능을 필자의 손을 거쳐야만했다. 자의인지 타의인지 모르겠으나, 문어발솔루션이 거대해 지기전에 누군가는 그 값을 지불하고 하나하나 막아야 할 판국이었다. 이렇게 외부 SE에게 떠넘기는 행위는 이제 정말 진절머리가 난다.)

지속적으로 각 파트에서 이 데이터메니저에 대한 수정요청과 변경요청들이 들어왔다. 해당 아키도 이 일만큼은 차일 피일로 미루고 있었다. 아마도 그는 자바스크립트의 객체 프로그래밍에 대해서 생소해서 진행을 못 한 탓이 컷다. 개발자들의 요청은 끊임없었고, 고객의 요구도 너무 다양해서 이 하나의 데이터메니저로 프로젝트의 데이터를 운반하기엔 초반 설계가 너무 미진했다는 것을 깨달았다.

헤당 컴포넌트를 사용하는 방법은 다음과 같았다.(포스팅을 위해 간략화하였다.)

var dataManager = new DataManager(GridName, COMMON_CODE, Action_Url);
....
dataManager .fire();

참으로 직관적이고 이해하기 쉬운 코드다. 하지만, GridName에서 유추해 보건데 위와같은 스타일은 단지 그리드를 위한 데이터연동일 뿐이다. 다른 UI 컴포넌트에 대해 방어적으로 프로그래밍되어 있는 모습을 보자.

var dataManager = new DataManager(GridName, COMMON_CODE, Action_Url);
....분기로직,반복구절,액션타입등의 조각 코드들 추가...

var dataManager = new DataManager(ComboBox, COMMON_CODE, Action_Url);
....분기로직,반복구절,액션타입등의 조각 코드들 추가...

var dataManager = new DataManager(Radio, COMMON_CODE, Action_Url);
....분기로직,반복구절,액션타입등의 조각 코드들 추가...

var dataManager = new DataManager(CheckBox, COMMON_CODE, Action_Url);
....분기로직,반복구절,액션타입등의 조각 코드들 추가...

var dataManager = new DataManager(CustomUIRequest, COMMON_CODE, Action_Url);
... 사용자 요청에 대한 수없이 변형된 컴포넌트

그 쉬운 코드속에 보이지 않은 냄새가 발견됐다. 아마도 저 데이터메이저속엔 사용자들이 원할 때마다 추가된 분기로직이 있을 것이다.

if(objectType == 'Grid')
...
else if(objectType == 'CheckBox')
..
else if(objectType == 'Radio')
..
else if(objectType == 'ComboBox')
..
else if(objectType == 'Text')

else
....
....
....
if ( Grid || CheckBox && Radio || ComboBox && Text )
else if( Grid && CheckBox && Radio || ComboBox && Text )
else if( Grid && CheckBox && Radio || ComboBox || Text )
else
...
if ( Grid || CheckBox && Radio || ComboBox && Text )
else if( Grid && CheckBox && Radio || ComboBox && Text )
else if( Grid && CheckBox && Radio || ComboBox || Text )
else
..
obj.fire();

UI가 바라보는 관점에서 DataManager는 충분히 제 할 일을 하는 것 처럼 보였다. 하지만, 평화로운 호수에 오리의 빠른 헤엄을 기억나는가? (Figure2) 저것뿐만이 아니다. 분기로직이 하나 추가되면 그에 따른 잔상효과때문에 여러군데를 더 뜯어고쳐야 하는 병목현상도 발생했다. 이 공통 표준 라이브러리를 고치면 이를 사용하던 모든 개발자가 또다시 자신이 개발한 업무를 다시 한번 수정해야했다. 고객의 요청이 들어오면 이 데이터메이저를 수정해야 했고, 다시 한번 개발자들은 모든 화면을 뜯어고쳐야만 했다.

2010:09:09 00:18:32
Figure2. 엄청나게 헤엄치고 있는거다.

 
2010:09:09 07:36:30
Figure3. 문어발식 솔루션의 코어를 수정하면, 관련된 모든 사람들에게 고통이 돌아간다. 

그것뿐만이겠는가? 난 이를 설계한 아키가 동기통신과 비동기통신에 대한 인기때문에 그냥 해당 라이브러리를 채용하고 사용하기에 급급했다는 마지막 결론을 내렸다.X-Internet기반의 컴포넌트는 기본적으로 XMLHttpRequest객체를 빌려쓴다. 해당 프로젝트의 아키텍트는 가우스에서 사용했던 UI 컴포넌트들은 모두 내부적으로 XMLHttpRequest를 쓰고 있다는 사실을 간과시했다. 그 후, 사용자의 요청때문에 가우스를 쓰지 않았던 화면에서도 잦은 오류가 검출됐다. 개발자들은 그 이유를 찾지 못하고 있었다. 실제로 요청된 Header를 검사해 보니 일반화면에서 쓰고 있는 비 동기방식의 처리가 DataManager에서 쓰고 있는 어떤 변수와 충돌이 되고 있다는 사실을 발견했다. 바로 XMLHttpRequest를 공유하고 있었던 것이다.!! (Figure4)

2010:09:09 07:46:24
Figure4. X-Internet 콤포넌트와 일반 Ajax을 사용하는 Js가 공유하는 XMLHttpRequest객체

필자는 수차례 웹2.0기반의 프로젝트를 경험했던 터라, 차후에 나타나게 될 안티패턴에 대해 고려하지 못 했던 아키가 그냥 그 사용방법의 인기에 의존한 채 그것을 여과없이 채용했었다는 것으로 일단락 마무리했다. XMLHttpRequest의 충돌현상은 이것으로 그치지 않았다. 이쪽 개발자에 오류화면이 검출되면 바로 여러군데에서 오류화면이 검출되었다. 상당한 문어발솔루션이라 단정지어도 될 듯하다.

필자는 XMLHttpRequest 객체가 여러군데에서 단일한 인스턴스를 사용하는 것을 확인했고 , 그것을 골라 충돌을 제거하기 위해 해당 컴포넌트를 수정했다. 또한, 비동기방식과 동기방식의 차이점을 주변 개발자들에게 설명을 해주었고 주의를 주었다. ( 이때 리팩터링한 방법은 XMLHttpRequest를 생성할 때 클로저를 사용했다. 클로저형태로 객체를 생성하게 되면 해당 블록안에서 인스턴스는 운명을 다한다. 따라서 인스턴스가 중복될 수 없다.)

그렇게 충돌되는 부분을 리팩터링하고 다시한번 데이터메니저를 리팩터링하기로 마음을 먹었다.
2010:09:09 00:45:56
Figure3. DataManager를 Refactoring의 Replace Confitional Logic with Strategy을 사용한 모습

모든 기능을 한곳에서 처리하는 것은 정말 무식한 일이었다. 따라서 리팩토링기법중에 하나인 조건문증가에 대한 제거방법을 사용했다. 메서드내에 조건문을 통해 여러 개의 서로 다른 로직 가운데 어떤 것을 실행할지 선택하고 있다면, 각 계산법에 대응하는 스트레티지(Strategy) 클래스를 만들고, 해당 스트래티지 인스턴스에 계산을 위임하도록 메서드를 수정하는것이다.( Replace Conditional Logic with Strategy )
또한 적당하게 수없이 늘어난 파라미터를 제거하기 위해 Introduce Parameter Object 리팩터링을 군데군데 추가하여 파라미터들을 제거해 나갔다. 또한, 추가적으로 Rename Method,Extract Method와 Extract SuperClass기법을 기본으로 사용했다.


Figure4. Introduce Parameter Object

간혹 어떤이는 자바스크립트에 왠 리팩토링기법을 쓰느냐 반문할 수도 있다. 리팩터링이란 코드에 냄새가 보일 때 습관적으로 행해야 하는 것이다. 특정 언어와는 아무런 상관이 없다는 뜻이기도 하다.


이렇게 중복을 제거하고 여러개 클래스로 나뉘어진 데이터메니저를 이제 개발자에게 공표하는 일만 남았다. 사용자들이 추가로 요구를 할 때 다른 타입의 UI가 발견되면 분기로직을 건드리지 않고 문어발식 수정을 하지 않아도 된다. 새로운 타입을 추가할 땐 다음과 같이 그냥 상속만 하면 그만이기 때문이다.(Figure5) - ( Javascript의 객체 상속 방법은 다양한 활용법이 있겠지만, 필자는 Prototype.js의 Object.extends나 JQuery의 Object.extend()를 주로 사용한다.)

2010:09:09 00:58:18
Figure5. Pluggable Pattern의 재현

이때 당시 개발자들은 너나 할 것 없이 체력이 형편없어졌고, 매일 야근을 해도 사용자들의 끝없는 요구사항때문에 대부분 녹초가 된 상태였다. 이미 사전에 문어발식의 행태를 일으킨 이 데이터메니저는 필자가 새로운 리팩터링을 하고 제작했던 공통 라이브러리를 공표할 여건도 없이 그렇게 계속 오염되고 있었다.

해당 컴포넌트는 프로젝트 아키에게 공표를 해 놓은 상태였지만 이것을 모든 개발자에게 공표한다면 개발자들은 아마 일주일간 또 한번 밤을 새가면서 전 화면에 걸쳐 데이터를 사용하는 곳곳 마다 모두 수정을 해야 했을 것이다. 장기적인 관점으로 상당한 이득을 볼 수 있는 리팩터링이었으나, 단기적으로 볼 때 개발자의 수명만 축소시키는 역할을 할 뿐이었다. 그래서 리팩터링된 해당 컴포넌트는 재야에 묻히고 말았다. 만일 이 컴포넌트를 제대로 공표했다면 지금도 발생하고 있는 수많은 병목현상에 대해서 커버를 했으리라 장담한다. 하지만, 필자는 그때 떨어져나가고 있는 개발자들을 보았고, 새벽까지 야근하는 작업자들을 보았다. 그래서 이것을 쉽게 공표할 수 없었다. 그들의 건강이 매우 우려되었기 때문이다. 기술보다는 사람이 우선이니까...

그래서 이 이야기는 무척이나 아쉬웠던 리팩터링 중 하나의 애피소드로 기억하고 있다.

참고 도서 :
패턴을활용한리팩터링
카테고리 컴퓨터/IT > 컴퓨터공학 > 디자인패턴
지은이 조슈아 케리에브스키 (인사이트, 2006년)
상세보기

Refactoring:ImprovingtheDesignofExistingCode
카테고리 과학/기술 > 컴퓨터 > 프로그래밍
지은이 Fowler, Martin/ Beck, Kent/ Brant, John/ Opdyke, W (Addison-Wesley, 1999년)
상세보기

실용주의프로그래머
카테고리 컴퓨터/IT > 프로그래밍/언어 > 프로그래밍일반
지은이 앤드류 헌트 (인사이트, 2007년)
상세보기

애자일프랙티스빠르고유연한개발자의실천가이드
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 벤캣 수브라마니암 (인사이트, 2007년)
상세보기

소프트웨어개발의지혜(AGILESOFTWAREDEVELOPMENT)
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 로버트 C.마틴 (야스미디어, 2004년)
상세보기

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://architect.tistory.com BlogIcon 짱가

    2010.09.30 15:42 신고 [수정/삭제] [답글]

    햐~~ 문서 정말 잘 만드십니다~ ^^

댓글을 남겨주세요.

인터넷 비방건에 대해.

Posted at 2010.09.09 00:03 // in Project Life // by MOOVA 무바㏇
간혹 프로젝트를 하면서 적잖게 막막한 기분이 들 때가 있다. 이런 기분이 들 때면 주위분위기를 환기시키고자 팀원들과 맛집을 찾아가거나 스트래스를 풀 다른 방법을 궁리한다. 그런 자리를 통해서 다시한번 막혀있었던 문제점들을 풀 때가 많다.

2010:09:08 21:58:21


그동안 내가 받았던 스트래스는 프로젝트에서 받았던 스트래스라던지 팀원들에 대한 스트래스가 아닌 외부로부터 들어온 스트래스가 대부분이었다. 사실 지금의 수술건도 외부로부터 들어온 인터넷 폭력때문이라는 결과를 내 본다. 그동안 어떤 일에 대해서 추진하려 하거나 내 업에 대해서 의식을 갖고 진행하려 할 때, 인터넷에 주기적으로 비방의 글을 올린 장본인들이 몇 명 있다다시 말하지만 물론 난 그들과 아무런 관련이 없다.
앞으로 프로젝트를 진행할 때, 또는 적잖게 내 인생에 대해서 방해를 하려 할 때, 나는 그들에게 마지막 히든 카드를 내려한다. 인터넷을 통한 개인의 비방이나 뒷이야기들을 뒤에서 아무렇지 않게 하는 이들. 그것은 한 사람을 궁지에 몰아넣어 죽이는 꼴이다. 이것은 현대판 살인과도 다름없다. 다시 한번 이런 일이 일어날 경우 그동안의 캡처자료와 우연이 아닌(20번 넘게 연속되었다면 그것은 결코 우연이 아니다.) 증거자료법적인 조치를 확실하게 진행하려고 한다.

내가 받았던 수술도 그들이 했었던 인터넷 비방의 결론이라 잠당한다.

난 누구의 노에도 아니다. 그리고 누구도 내 주인이 아니다. 누군가가 내 일이나 지나왔던 업무에 대해서 어부지리를 한다고 하면 그것은 사기꾼이라고 생각하면 된다. 다시한번 말하지만 난 그들과 아무런 상관이 없다. 개구리가 황새의 마음을 어찌 알겠느뇨!!

ps :

1. 인터넷에서 소극적/간접적으로 그런 비방의 행위를 하는 사람의 뒷면엔 변태성 기질이 있다는 통계적 연구도 나와 있는 상태다. 난 인터넷 워리어들을 실제 프로젝트에서 만나길 희망한다. 그 잘난 뚫린 입으로 실제 업무는 어떻게 처리하는지 내 두 눈으로 직접보고싶다는 말이다.

2. 현재 최근 병원치료를 받으면서 한 업체에게 주기적인 ISP정보를 제공하고 있다. 병상중이라 너무 무리하는 것이 아닌가라는 주위의 걱정도 있지만, 경력을 유지하기 위해선 이런 활동도 나에겐 도움이 된다.

3. 난 그들이 인터넷에 배부르게 글질이나 하고 앉아 있을 때 잘려 나가는 내 후배들을 봐야했다. 인터넷에 개인적인 상처와 욕설을 허용했던 이른바 지식인들의 무뇌함을 보았다. 이 세상은 지식만 굴릴줄 안다고 세상을 움직일 수는 없는것이다. 때로는 주변의 상황을 바라보면서 행동을 해야할때가 있다. 이런면에서 융통성이나, 눈치가 없다는 것을 확인할 필요가 있다.


저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. 2010.09.08 22:13 [수정/삭제] [답글]

    비밀댓글입니다

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

      2010.09.08 23:37 신고 [수정/삭제]

      그러게요. 인터넷 워리어들..별로 파워는 없어요. ;;
      단지 끼리끼리 붙어서 그게 전부라고 보이는 착각때문일껍니다. 인터넷에 3명이상이 서로서로 동조하고 자화자찬하고 있으면 사람들은 저게 뭐하는것인지 관심을 끈다는 심리자료도 있더군요.실제로는 그러지 못한 경우가 태반이라는 소리입니다.^^

  2. 2010.09.09 00:30 [수정/삭제] [답글]

    비밀댓글입니다

댓글을 남겨주세요.

[공과 사] 폭언과 폭행의 단계.

Posted at 2010.09.07 08:55 // in Project Life // by MOOVA 무바㏇
간혹 공적인 자리에서 사적인 부분을 캐려하는 이를 보게 된다. 물론 어느 정도 친해진다면야 공석에서 사적인부분까지 공개하는 모습도 바람직한 모습이지만, 그런 자리가 아니라면 사회생활에서 어느정도 선을 긋고 행동하는것이 더 보기좋은 모습일 것이다.

"공과 사를 넘으려 했던 내 기억속에 파렴치인"

얼마 전 사람들과 트러블이 많기로 소문난 양은냄비에게서 심각한 폭언을 들었던 적이 있다. 상대적으로 생각해보면 왜 그가 나에게 그런 폭언을 했는지 이해할 만도 했다. 왜 자신한테는 관심이 없느냐? 왜 나를 안 도와주는 것이냐? 란 이유때문일까?

"씨발 니 친구들 다 데려와 봐. 니가 뭐하는 놈인지 알아야겠어, 니가 살아온것을 다 나한테 말해봐!!"

스토커도 저런 스토커가 있을까?  욕설에 대한 고소를 하기로 했으나 그들의 빈곤한 상황을 참작하여 참기로 하고 넘어갔다. 예전 이의 동생도 나한테 한 소인배적 행위를 한 기억에 덧붙여서 말한다면, 그리 놀랄 일도 아니지만. 그 형에 그 아우라는 결론을 내게 된 것도 당연한 일이다.

이 형제는 내 절친인 친구까지 끌어들여 자신의 성인패티쉬 사업에 동참하고 투자하라고 한 양반들이다. 사람 소개해주는 것도 고마워서 인사는 못할망정 그런 폭언을 일삼다니. 상식적으로 이해할 수 있겠는가? 어떻게 공적인자리에서 그런 변태사업을 하자며 손을 내미는지 난 잘 이해가 되질 않았다. 그러면서 자신들이 논리적인 사람들이라고 자부하고 다녔다. 감정이 이성을 가리고 폭언을 일삼으면서 어떤 논리를 따지는지 잘 모르겠다. ㅡ,. ㅡ

이들에 대한 기억때문에 그동안 만났던 내 동료와 후배들에게 한가지 충고를 하곤 한다.
"만약 누군가가 너희에게 아무런 조건없이 친근하게 다가오거나 거짓된 웃음으로 다가온다면 분명히 그 뒷일을 생각하기 바란다, 분명히 따로 원하는것이 있거나 , 숨기고 있는 꿍꿍이가 있을것이다"
하고 말이다.

후배들과 이 형제에 대한 기억을 이야기 하다보면 결과적으로 "상 또라이"라고 모두 함구하고 인정했다. 제발 자신이 하는 일이 잘 안된다고 남에게 화풀이 하거나 화를 떠넘기는 생각은 추호도 하지 말자. 

차 후에 발생하게 될 사태에 대해 좀 생각하고 말을 하란 소리다.


"갑과 을의 관계를 뛰어넘은 계약노예"

이 형제와 관련된 삼성SDS에 있는 자칭 '멘토' 도 내 인생을 정말 괴롭힌 사람중에 한 명이다. 삼성 SDS의 대부분의 상급자가 나에게 지대한 관심을 보이며 칭찬과 배려를 아끼지 않았던 무렵, 중간에서 이 자칭 멘토라는 사람은 그게 싫어서 꾸준히 갑의 힘으로 나에게 수 없는 일을 시킨 장본인이다.
진행하고 있던 모듈을 포함하여 이 사람이 강제적으로 시켰던 일까지 포함한다면 정말 팔이 10개라도 모자랄 판이었다. 그러면서 한다는 이야기가 "또라이새끼, 또는 미친놈" 이라는 폭언을 일삼았다.
끼리끼리 잘하는 짓들이다. 난 이때 2주간 팬티도 못 갈아 입고 이 자칭 '멘토'에게 그런식의 노예부림을 당해야만 했다. (실제로 주업무가 있었는데도 말이다.!!!) 그렇게 부려먹고 나에게 한다는 소리가 "너 정신삼당소좀 가봐라" 라는 말이였다.

남들도 옆에서 놀고 있는데 나에게만 그런 폭언을 하면서, 폭발적인 일을 시켰다. 분명 자신보다 윗 사람들이 나에 대해 지극한 관심을 보여서, 중간에서 시기심에 이런짓을 했다는걸 난 다 안다. 3개월 동안 찜질방에서 자고 출근했던 내 성실함은 인정도 안 하고, 결국 몸과 마음이 허약해지니 이제와서 정신삼당소에 가보라니!!!

2010:09:07 08:03:12

순진했던 일만했던 유진박, 그 화려함뒤에 당했던 사장의 폭언과 폭행



누가 누구의 멘토라는건지 원. 정말 이해를 못 하겠다. 정당함을 상실한 갑의 횡포에 중독된 사람과 일만하는 노예의 관계가 멘토와 민티의 관계가 될 수 있다고 생각하는가? 콧방귀나 껴주자.
요즘은 이제와서 좀 내가 이름이 알려지고 잘한다는 평가들이 있으니 그때 했던 행위에 대해서 감추려고 하는 티켓을 나에게 발행하고 앉아 있다.  "난 너의 멘토"다 하면서 이제와서 어부지리하려는 속셈일까?자신이 했던 사람 괴롭힌 범죄적인 행동을 묻어두고 싶어서 그러는 거 난 다 안다.

2010:09:07 08:04:24

이중성격을 쓰는 사람을 조심하자.


공과 사를 잘 구분하자.

나는 그들에게 되려 해주고 싶은 말이 있다. 이 두 형제와 삼성SDS의 자칭 '맨토'들..
"난 이 두 가지 사건을 기억할 때, 정말 내 기억에서 지우고 싶은 카테고리로 분류하고 있다."
이때 겪었던 마음의 상처와 혼돈.. 그들은 어떤 부채를 나에게 발행했는지도 모른다.


공적인 자리에서 사적인것까지 침범하려 하면 저들처럼 파렴치한 사람이 되고 마는것이다. 난 이들의 이중성격! 정말 기가 찬다.  어쩌면 그들은 스토커같은 사람이 아니라 이미 스토커가 되었을 수도 있다.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블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와 같은 라이브러리는 그동안 수차례 공부를 해왔던 경험이 있기 때문에 본인이 아는 내용과 책 내용이 상당수 중복되는 부분이 많았다.
그리고 위의 컬럼명 매핑에대한 부분은 순전히 개인적인 생각으로 삼성에 제공한 라이브러리였는데, 그것과 비슷한 방법이 이 책에 실려있어 깜짝 놀랐다.! 세상엔 참으로 비슷한 생각을 하고 실천하는 사람이 많다는 것을 새삼 깨닫게 해주었다. ( 실제 프로젝트에서 만나볼 수 없었던 비슷한 가치를 지닌분들 ).

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블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현실에서 그러한 열정과 도전들이 암흑의 나락으로 내동댕이 쳐지는 일은 없을것이라고 확신한다.
     

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

     


     

    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블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년)
    상세보기

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

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

    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블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전문인들의 풍도이다. 이만하면 우리나라 풍토와 많이 다르다는 이야기다.

    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블UP하기
    1. Favicon of http://minimonk.net BlogIcon 구차니

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

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

    댓글을 남겨주세요.

    누가 프로젝트를 이끄나?

    Posted at 2010.08.03 17:34 // in Project Life // by MOOVA 무바㏇
    가끔  롤을 정해 투입하면 적막한 환경에서 프로세스도 없고, 정리도 안 되어 있는 곳이 너무 많아 안타까움을 수 없이 경험하게 된다.
    상대적으로 지식인들이나 일반인들의 프로젝트가 실패와 성공유무를 확연히 결정지을 수 없는 것을 난 경험에 의해서 잘 알고 있다.
     
    대 다수의 프로젝트가 명목만 성공일뿐 실제 70%이상은 실패라고 한다. 왜 그럴까?

    어떤 프로젝트는 대 다수가 대학원 이상의 학력을 가지고 있었다. 하지만, 그 프로젝트를 시니어로 투입하게 될 때, 난 프로젝트의 심각한 공팡이 냄새를 맡아볼 수 있었다. 소스코드 관리는 형편없었으며 누구하나 코드를 공개하려 하지 않았다. 관리자가 적당한 일을 시켜도 누구하나 맡아서 하는 사람이 없었다. 비록 솔루션 회사라고 하지만 지켜야 할 프로세스는 전혀 찾아볼 수도 없었고, 문서도 적당한 포멧이 아닌 윗선에 보여주기 위한 문서들만 1000장 이상이 넘쳐날 정도로 소프트웨어와는 담을 쌓고 있었다.
    무엇이 문제일까? 문제점을 파악해보니 실제로 프로젝트를 리딩할 수 있는 인물이 없었다. 아니다. 프로젝트에 관련된 PMO가 너무도 많아 배가 산으로 간 것이다. 누구하나 소스코드를 관리하려 하지도 않았고, 누구하나 팀웍을 발휘할 생각조차도 없었다. 
    모두가 고학력이고 고 지식을 갖고 있으면  아마 프로젝트의 배는 산으로 갈 것이다. 뱃사공이 너무 많아 목표를 뚫고 해쳐나가기가 곤란한 것이다. 이런 상황에 나는 어떤 입장을 취해야 할까? 분위기에 묻어가는게 현명할까 하니면, 엔지니어의 입장을 고수하기 위해 재정리를 하는 게 올바른 선택이었을까?

    어떤 프로젝트는 대 다수가 고졸 내지 전졸이상의 학력을 가지고 있었다. 사람들은 새로운 프로젝트 기술에 목말라 했으며, 선배 알기를 매우 중요하게 생각했다. 시니어가 목적을 설명하면 따라오는 사람들이 많았고 삼각형 모양의 프로젝트 팀원이 구성되었다. 하나의 기능을 완성하기 위해 모두 같은 관심사를 보여주었으며 놀 때는 놀고 일할 때는 일하는 이른바 파워풀한 구도가 갖추어져 있었다.
    모든 것은 사람에 의해 진행되니 다른 부서로 뿔뿔히 흩어진 기존 맴버들은 주기적인 회의나 입담을 통해서 서로의 정보교환을 했고, 그 정보로 각 부서의 흐름을 캐치할 수 있는 큰 그림을 완성할 수 있었다. 소스코드도 굉장히 잘 정리가 되어 있었으며 시니어 개발자, 중간, 초급 개발자들 사이의 괴리도 일사분란하게 움직이는 덕분에 실수를 줄일 수 있었다. 다른 팀과는 달리 ROI측면에서 이 팀은 x5의 생산성을 보여주었다. 무엇이 이들을 성공으로 이끈 것일까?

    위의 경험으로 비추어 볼 때 , 학력과 프로젝트의 실력과는 전혀 관계가 없다.
    (이번 병상으로 병원을 자주 이용하다 보니 의술을 업으로 가지고 있는 사람들에게 간접적인 영향을 많이 받고 있다. 그들은 학력과 실력을 동시에 갖추고 있었다. 병원 시스템을 보더라도 교수급만 부릴 수 있는 의술이 있었으며, 년차가 쌓이고 쌓이면 그 만큼 실전 경력도 쌓이게 되어 있었다. 시스템이 받쳐주니 그만큼 인재들이 나오는 것이다.......) 프로젝트는 사람들과의 상생에 있으며, 타인을 이해하는 것부터 시작이다. 많은 지식을 갖고 있으면 그만큼 움직임이 곤란해지는 것을 잘 알고 있다. 결국 프로젝트는 사람들의 상생을 이해하고 있는 리더의 몫이 대단히 중요한 역할을 하게 해준다.

    동탁이 한의 왕을 배척하고 중국 왕실을 점령했을 때 각 성의 태수나 현령들은 타도 동탁을 외치며 봉기를 했다. 하지만, 목적과 뜻이 같다고 성공할 수는 없는 노릇이다. 한 명의 리더를 세워야 했으며 그 명령에 따라 움직였을 때 일사불란하게 군기를 확립할 수 있었던 사례를 생각해 보면 프로젝트내 리더의 위치는 꼭 필요한 필수조건이라 생각한다. 리더밑에 저마다 특색있는 인재들이 배치되고 리더의 목적에 따라서 사람들은 움직여야 한다. 그래서 프로젝트는 지식인과 중간인, 초급사이의 괴리를 없애주는 노력을 해야한다. 좋은 리더를 팀에 세워 조직을 하나의 동반자인 문화로써 가꾸어 나가야 한다. 모두가 자기 자신이 리더라고 한다면 당연히 사공이 많으니 배는 산으로 갈것이니까..그 전에 조직의 시스템을 잘 정비해야 한다.

    결론적으로 팀웍과 프로젝트 실행 능력은 학력과 아무런 상관이 없다고 볼 수 있다. 또한 탁월한 리더의 선출도 조직과 팀을 발전시키는데 큰 역할을 하게 만들어 준다. 그런 리더의 선출은 당연히 조직원들이나 같은 집단의 여론에 의해 형성되어야 한다. 그래야만 여론을 통솔할 수 있는 여건이 생기니까 말이다. 위의 동탁타도의 예에서 볼 수 있듯이 원소같은 바보리더도 조직의 리더이다. 리더는 조직을 통일시키지는 못할 지언정 조직을 하나의 목표로 이끌어주는 중요한 역할을 한다.

    우리는 무언가에 홀리지 않았을까? 증과 학력..그리고 눈을 가리고 있는 그 수많은 아우성들을 한번 생각해 보자.
    본질을 버리고 계속 거짓으로 달려나가는 이유는 무엇인가?  이것이 눈가리고 아웅하는 것이 아닌가 생각해 본다.

    2010:08:03 16:06:04
    People...
    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블UP하기
    1. 2010.08.04 02:27 [수정/삭제] [답글]

      비밀댓글입니다

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

        2010.08.04 09:58 신고 [수정/삭제]

        동탁의 예를 보았듯이 각 태수들과 형관들이 동탁을 없애려고, 맹주한명을 추대해 대업을 이룬 예를 한번 보기로 하죠. 아무리 목적이 같은 사람끼리 모였어도 맹주가 없으면 그 무리를 이끌 수는 없다는 것이죠... 당연히 조직원이 있어야 하겠지만 조직원들을 통솔 할 수 있는 맹주 같은 사람이 앞에 서야한다는 것이죠. 조직이란 평등의 관계가 아닙니다. 바보 리더라도 조직원을 이끌 수 있는자라면 리더는 세우는 것이 더 바람직하다는 내용입니다.

        읽는 이로 하여금 더 많은 생각을 하게 만들어 주는게 제 글의 비결입니다. 제 글을 읽어주시는 1000명의 독자들에게도 비평과 호평을 얼마든지 받길 희망합니다.

        제 블로그를 꾸준히 읽고 계시는 분이신것 같은데 귀중한 참견 감사드립니다. 님의 조언은 참고하겠습니다.

    2. Favicon of http://minimonk.net BlogIcon 구차니

      2010.08.05 14:26 신고 [수정/삭제] [답글]

      어쩌면 애플이 핸드폰에 뛰어들떄를 보는 것 같네요.
      '핸드폰도 안 만들어 본놈들이 어떻게 핸드폰을 알겠어' 라는 비판과 함께
      '핸드폰을 안 만들어 봤기에 오히려 더 편한 핸드폰을 만들수 있어' 라는 지지도 있었겠죠

      아무튼 안다라고 자부하는 것 자체가 스스로에게 독이 되고
      그러한 자부는 자만으로 바뀌는 것을 종종 보기에, 학력이나 실력에 자신이 있어 하는 사람을 보면 매번 불안하더라구요. 혹시 포장을 실력이라고 착각하는건 아닐까.. 하고 말이죠

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

        2010.08.09 09:08 신고 [수정/삭제]

        사람은 항상 배워야 한다고 생각합니다. 못 해 본 영역이 있고 그 영역은 이미 다른 사람들이 선배로 자리하고 있으니까요. 그리고 어떤 종목을 시작하든 그 일을 하게 만들어주는 동기와 열정이 가장 중요하다고 봐요. 말씀하신대로 자긍심이 자만심이 되지 않도록 우리 잘 조율해 봅시다.~

    3. epr

      2010.08.09 01:31 신고 [수정/삭제] [답글]

      '성공을 위해서는 리더가 필요하다' 이 단순한 사실은 거의 공리에 가까운 진리입니다. 하지만 모두가 다 아는 그 진리를 위해 사용한 근거가 겨우 삼국지 조연에 불과한 동탁의 예, 그리고 님께서 경험하신 두 팀의 이야기를 하셨습니다.
      저는 이 글을 제목을 읽으면서 제가 예상했었던 글의 방향은 단지 리더가 필요하다가 아닌 어떤 리더, 어떻게 리더가 만들어졌는지에 대한 이야기를 기대했습니다. 하지만 겨우 리더의 필요성을 설명하기 위해서 장황하게 적은 것은 보고 제가 느끼는 것은 님의 글은 굉장히 현학적입니다.
      님이 이 글을 쓰는 목적은 님의 주장을 전달하는 바를 납득시키고 싶은것이 아니라 님의 유식함을 자랑하고 싶어서 쓴 것 같습니다.
      저는 개인적으로 탁월함의 기준을 그 지식에 대해 어린이도 잘 알 수 있을만큼 쉽게 설명해주는 사람이 정말 뛰어나고 똑똑한 사람이라고 생각합니다.
      앞으로 님의 글에서 현학적인 모습이아닌 진솔한 탁월함을 기대합니다.
      그런 글을 볼 날이 곧 오리라 생각합니다.

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

        2010.08.10 08:48 신고 [수정/삭제]

        음... 글쎄요 위에 글이 누군가를 납득 시킬려고 쓴 글은 아니였기 때문에, 그렇게 민감해 할 필요는 없다고 봅니다. (사실 위에 글은 생각나서 5분만에 적을 글이거든요. ㅎㅎㅎ ) 왜 그렇게 민감해 하셨나~~ㅎ
        왜 제 글이 저의 주장을 꼭 어필해야 한다고 생각하시는지?? 그럴 당위성이라도 있는지, 한번 역으로 물어보고 싶네요. ( 겨우, 고작, 똑똑함, 뛰어남이라는 단어를 많이 사용하는 것으로 보아..그냥 글 때문이 아니라 어떤 다른 연유때문에 이렇게 들어와서 댓글 아닌 댓글을 달아주는 것 같거든요. 마치.. 누군가에게 얻은은 피해감 때문에...)

        위의 글은 제 똑똑한 것을 과시하고 싶은 종류의 것으로 쓴게 아닙니다. 뭐 말씀하신 것처럼 알기 쉽게 설명하는 것도 어느정도 재주에 속하죠 ( 아인슈타인이 상대성이론을 일반인들에게 설명하기까지 10년이 걸렸으니까요^^. 머 제가 아인슈타인이 아니기 때문에 별 말씀은 못 드리겠습니다.:) ). 제 블로그에 모든 글들이 그렇게 타당하고 설득위주의 글이 되기를 바라시는것 같은데.. 꼭 그래야 할 이유라도 있나요? 제 블로그의 모든 글들이 강하게 저의 주장을 어필하기 위해 썻었더라면 아마 블로그는 이미 예전에 접었을 겁니다. 재미있게 블로그해야지 재미없게 하긴 싫거든요.

        ( 딱딱하고 명확한 글들은 정보전달의 목적은 있겠지만 사람들로 하여금 생각할 수 있는 여지를 만들지는 못합니다. )

        ps : 님의 블로그. 잠깐 들어가 봤는데..님께서 말하는 진솔함, 탁월함은 어디 있나요? @.@ ( 자신이 하는 말은 자신의 거울입니다.: 남을 비평하기 전에 자기 자신부터 보라는 이야기입니다.) 님께서는 제 블로그를 계속 보시는 분인것 같은데, 간단한 통성명도 하지 않은 채 이렇게 익명으로 몰상식한 행동을 하는것도 예의가 이니라고 생각합니다. 예의부터 배우고 오시죠.

    댓글을 남겨주세요.

    [Project] 근본도 없는 놈의 공명선생에게서 얻는 가치

    Posted at 2010.07.12 09:42 // in Project Life // by MOOVA 무바㏇

    삼국지에서는 설전이라는 것이 있습니다. 문파끼리의 설전, 개인의 설전을 통해서 자신의 논지를 명확하게 굳히고, 때로는 설전을 통하여 더 의미있는 가치를 얻어내거나 중요한 소통을 일깨우는 것이 바로 설전입니다.

    오늘날 종종 배움의 가치가 전혀없는 일방적인 종류의 설전을 보게 됩니다.
    그 설전을 통해서 더 중요한 가치를 찾지는 못할망정 설전 하나로 오해를 하거나 상처를 받아 마음속에 꾹 담아두는 행위말입니다. 설전으로 소통만 해도 어딥니까? 설전은 자신이 생각하고 있었던 편협한 잦대를 허물어 버릴 수 있는 유용한 수단이 아닐까요?

    저 또한 이런 설전으로 저의 낮았던 잦대를 좀 더 다듬거나, 또 다른면으로 생각할 수 있어서 좋습니다. 매번 허공에 대고 헛질이나 하고 앉아 있지 않으려면, 상대방의 의견과 생각을 받아줄때도 있어야 합니다. 이런 부류는 설전에 대한 응어리가 있어서 결국 니 편이냐 내 편이냐를 따지게 됩니다. 이런 행동은 매우 편협한 행동이라 할 수 있습니다. 이런 주장도 있고 저런 주장도 있는데, 다른 사람이 다른 주장을 한다고 해서 무조건 반목하는거 보면 참.. 나이가 많아도 다 성인은 되지 못하는 구나..라고 깨우칠때가 많습니다. 그것이 바로 흑백논리로 가는 지름길이 아닐까합니다.

    저는 되도록 이런 설전을 통해서 더 나은 가치와 배움을 얻으려고 노력을 하고 있습니다( 모르는 사람이 보면 싸우려고 하는 것처럼 착각할 수도 있습니다.) 만 저도 사람인지라 줄 곳 지켜 지지 않는데 흠입니다. 공명선생이 강동유파들과 설전을 벌인 일화중에 이런 말을 합니다.

    강동유파中 1人 : 유비는 중산정왕의 후예라고 하지만 등과를 안했고 돗자리나 짜던 자였는데 조조와 상대가 되겠소?

    인격모독조로 공명선생에게 유비에 대한 흠을 잡습니다. 그러자 공명선생은 이런말을 합니다.

    공명선생 : 그대는 혹시 원술밑에서 도라지를 훔친 육공기 아니오? 앉아서 내 말을 들어보오. 조조가 조상국의 후예면 이 나라의 신하인데 조조는 권세를 남용하여 폐하와 자기 조상을 능멸해서 황실과 조씨 가문의 역적이오. 유황숙은 천자께서 족보를 보시고 황숙이라 칭했는데 등과를 못한거요? 고조역시 정장출신으로 천하를 얻었는데 그것이 치욕이오 ? 공의 소견은 어린애 같소 

    그러자 욱하던 강동유파는 다른 강동유파에게 바톤을 넘깁니다. 

    강동유파 B : 공은 어떤 경전을 읽었소?

     

    공명선생 : 난 불필요한 경전따윈 읽지 않소. 그건 우매한 책벌레의 일이지 대업과는 상관이 없소. 자고로 성현들도 경전은 안 읽었소.  상탕의 재상 이윤은 농사짓는 노예였고 홍주의 강자아도 낚시하는 어부였고 장량 진평역시 우주를 다루는 인재였으나 경전은 안읽었소. 요즘 서생들은 경전이나 읽고 먹물이나 만지니 항상 원탁회의에서 별볼 것도 없는 발전없은 싸움에 힘만 빼는게요. 

     

    2010:07:12 09:27:21

    공명선생

    참으로 실무와 실학을 중요시 하는 공명선생의 가르침을 엿볼 수 있습니다. 그는 근본에 잦대를 두지 않고 실리를 추구합니다. 사람의 귀천에 대해서도 아무렇지 않은 듯 생각합니다. 저도 사람인지라, 때론 인격을 모독하는 언행으로 일격을 받게 되면 고스란히 그것을 돌려줄 때가 있습니다. 어떤 프로젝트에서 한 관리자 왈 저에게 이런 막말을 한 적이 있습니다.


    "무슨 근본도 없는 놈이 들어와서 활개를 펴고 앉아 있다. "

    고 말을 합니다. 참 기가 차서 이런 이야기를 했죠..( 아마 그가 저 말을 하지 않았다면 전 이런 내용도 말을 하지 않았을 것입니다. 아마도 그쪽 프로젝트 솔루션에 처음으로 ROI를 3배정도 올려줬던 계기가 그로 하여금 저에게 저런말을 하게 만든 것 같습니다. 뭐 아니면 말고요.)

    "항상 열심히 살려하고 책도 꾸준히 읽고 경험도 꾸준히 쌓고 있고, 어렸을적부터 대가족 제도에 자라서 예와 근본은 있습니다. 무슨 근본도 없다는 말을 하는지..."


    참 프리랜서를 하면서 이런 저런 경험은 다 해 봤지만 저런 막말은 난 또 처음 들었습니다. 저런 인격모독은 같은 인격모독으로써 값아 줍니다.

    "프로젝트에서 여자손이나 만지고, 여자한테 스킨쉽하는게 매우 부자연스러우면서 그런 행동을 여자들이 좋아한다고 생각하시는것은 아닌지... 그런 행동들이 여자들이 좋아하는 것 같나요? 아마 여자들은 정말 싫어할 것입니다. 당신이 말하는 근본도 없는 놈은 이런 예의를 지켰던 반면, 근본이 있는 그대는 이런 사소한 애티켓정도도 지킬 수 없으니 차라리 근본이 없는 놈이 될렵니다."

    하고 말이죠.:)


    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블UP하기
    1. Favicon of http://minimonk.net BlogIcon 구차니

      2010.07.12 16:13 신고 [수정/삭제] [답글]

      가끔은 이런것들이 대한민국을 발전하지 못하게 하는것 같다는 생각이 들어요.

      원래 자기가 하던 일이 아닌것에 대해서는 신입으로 취급해버릴 정도의 기형적인 구조.
      어쩌면 그 일을 안했기에 오히려 더 사람들이 쓰기 편하고 더욱 좋게 만들수도 있는데 그러한
      기회조차도 주지 않은채 "넌 이쪽일을 몰라서 그래" 라는 말로 기를 죽여 놓죠.

      그렇다고 경험을 무시할건 없지만
      오래했다는 것이 업적이나 훈장이 되어버리는 현세태에서 새로운 혁명에 가까운 일들은 벌어질수가 없겠죠.

      머.. 그래도 안해본 사람이 와서 깝죽대기만 하지 제대로 하지도 못하면서 ㅉㅉㅉ 이런 케이스가 더 많은것 봐서는.. 어떤 적정선이 있는지 어떻게 대처를 해야할지 항상 모르겠습니다 ㅎ

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

        2010.07.12 22:50 신고 [수정/삭제]

        젊었을땐 활기찬 행동들이 그 자체가 힘이라고 봅니다. 그게 너무 틔었거나 오바했다면 질책을 받아 마땅하지만요. 자신의 경험도 중요하지만, 새롭게 경험을 쌓으려 들어오는 사람들에게 한쪽의 시각만이 아닌 그들세대를 인정할 만한 시각도 때론 필요한것 같습니다.
        위와 같은 경우 다시한번 생각해 볼 수 있었던 상황이 어떤 한 프로젝트에 들어갔었는데 아이디어 하나로 좀 유난히 스포트라이트를 받았던 것입니다. 그런 스포트라이트가 그에겐 아마 그의 경험에 비추어 보아 인정할 수 없었겠죠..모..이해합니다.^^

        그가 말했던 경험담도 그떼 당시 제 경험으로 견주어 봤을 땐 좀 많이 이해가 가지 않았습니다.

        남들은 인정을 모두 했던 반면 유독 그사람은 저렇게 나오더군요.. 왜인지는 모르겠으나.. 아마 그의 경험적 시각이 그쪽 조직과도 많이 달라서 그랬을 수도 있구요.

        갑자기 체케바라가 생각나는군요.

    2. Favicon of http://moonlgt2.tistory.com BlogIcon 소박한 독서가

      2010.07.13 01:07 신고 [수정/삭제] [답글]

      너무 약하게 말씀하셨네요..저 같으면 훨씬 강하게 치받았을 것 같습니다..워낙에 욱하는 성격이라서요...그리고 그 관리자는 교양이 얼마나 있길래 그런 근본없는 말을 하는지 모르겠네요..제가 다 짜증이 납니다.

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

        2010.07.14 16:18 신고 [수정/삭제]

        좀 더 강하게 어필했었으면 하는 후회가 가끔되요.ㅎㅎ
        그래서 사람관계란 모르는 것 같습니다. 미래가 어떻게 될 지, 또 내가 생각지도 못한 사람들에게서 도움을 받을 수 있고, 또는 내가 도움을 줄 지도 모르는 일입니다. 그래서 다른 사람에게 상처가 받는 말은 되도록 하지 않은게 좋은 것 같아요. 또 들려주셔서 감사합니다.

    3. Favicon of http://jc9988.co1.kr BlogIcon 기적의 치료★자연이 준 보배

      2010.10.09 01:07 신고 [수정/삭제] [답글]

      사ª랑해㏏요↗ <좋은 글 감사합니다.<늘! 건강하시고 행복하시기를 기원합니다.<평생 건강정보 : 내 병은 내가 고친다.>

    댓글을 남겨주세요.

    인도가면 고담을 볼 수 있을까?

    Posted at 2010.07.09 19:43 // in Project Life // by MOOVA 무바㏇
    부제 : 제 삼세계 사람들 차별하지 말자.

    왼 : 고담, 중간 : 사힐, 오른 : 메하르

    STX에서 만난 인도사람들입니다.
    고담에게 도움을 얻어 인도다신교정보에 대해 한번 글을 올렸었으나 큰 도움을 받은 이들의 이야기를 몇 가지 공개하려 합니다.
    왼쪽은 제일 친했던 고담, 중간은 아키텍트였던 사힐 ( 굉장한 테키였던 것으로 기억함 ), 오른쪽은 메하르 ( 카스트제도때문에 콧수염을 기름 )

    STX프로젝트는 일요일날 서울에서부터 장장 5시간 여행을 했어야 했었다. 처음 이들이 자리에 있었을 때는 정말 깜짝 놀랐다.
    외국인과 대화를 한건 전화영어 3개월 정도 한게 전부였고, 이들과 같이 프로젝트를 진행하려 하니 꽤나 두려움이 앞섰다.

    한국 최초로 Windchill 9.0을 도입한 프로젝트였는데 기술적으로는 구글의 기술과 흡사해서 그렇게 문제될게 없었다.
    문제는 소통의 문제. 바로 옆에서 이들이 물어보는데 얼마나 부담이 되는지.. 하지만 이들이 사용했던 영어도 뭔가 약간 달랐었음이 분명했다. 이들은 태어나서 3가지의 언어를 익힌다고 한다. 하나는 지방 인도어, 하나는 글로벌 인도어, 하나는 영어이다.

    그렇게 소극적으로 프로젝트를 진행하고 있던 도중 고담(제일왼쪽)이란 친구가 줄기차게 이야기를 걸어왔다.
    처음엔 매우 두려웠지만 1개월~2개월 지나고 나니 어느 정도 소통이 된 것일까? 퇴근을 하면 고담에게 샌드위치를 사주기 위해
    같이 샌드위치 바에 가거나 피자가게를 들려야만 했다. 한국에서 이들이 먹는 것은 고추장밖에 없었으니.. 얼마나 식생활이 안 좋았을까 하는... 이들은 고기를 먹지 못하니 계란도 먹지 못하고 매운 음식을 좋아하니 고추장에 밥을 비벼 말아먹을 수 밖에 없는 노릇이었다. 이 친구는 그 때 당시 24살이었다. 말을 하는게 상당히 불교적이여서 정신문화에 대해 고견을 들을 수도 있었다. 우주와 인간과 종교에 대한 그의 이야기는 듣고만 있어도 매우 평안해졌다. 그 때 나는 크리스찬이었고 이와 이런 종교적인 이야기로 소통할 수 있었다는 것으로도 큰 기쁨이라고 할 수 있었다.

    인도인들은 고기를 먹지 않는다. 흰두교 전통 때문이다.
    이들이 인도에서 싸 가지고 온 카레가 있긴 했지만, 그것도 떨어지고 나면 이들은 대형마트에서 다시 한번 카레를 사서 먹어야 했다. 이런 이유때문에 고담과 퇴근을 하면 같이 샌드위치 바에 가거나 커피숍에서 빵을 시켜 먹는다든지, 또는 피자집에 가서 피자를 먹던지 해야했다. 이런 친근한 분위기속에 대화를 하니 나중에는 전혀 거리낌이 없어졌다. 물론 나도 그런류의 음식들을 좋아했었고, 서로서로 좋은게 좋은거 아니겟는가? 하지만 내가 어떤 목적때문에 이에게 그런것들을 사준것은 아니다. 그냥 인도사람과 친구를 하고 싶어서였다.
    그동안 한국 교욕 실정상 문법이나 어법은 대체로 알고 있었다고 생각했는데, 이들이 사용하는 것은 정말 간단한 단어라도 그것을 적절히 조합해 업무 협의라든지, 기술적 소통이라든지, 간단한 소통을 통해서 진행하는 것을 보고 ㅇ ㅏ~ 저렇게 하는 것이구나` 라는 감각을 익힌 것 같다.

    난 이 고담이란 친구에게 정말 감사함을 느낀다. 실제 외국인 두려움증을 없애줬기 때문이다. 내가 만약 이들에게 다가가서 처음으로 어떤 기술에 대해 물어보았다면 그렇게 친근해질 수 있었을까? 절대로 그럴 수 없었을 것이다.
    사람이 사람과 처음 친해지려거든 기술적이어서는 절대로 안 된다. 기술은 나중문제다. 이것은 세계 어디를 가건 똑같지 않을까?
    이 친구에게 명함을 한 장 받았는데 그것이 없어졌다. 언제한번 인도여행을 가게 되면 꼭 한번 전화를 한다고 했는데 지금은 어떻게 잘 살고 있나 모르겠다. 나에게 한국에 일자리를 알아봐 달라고 부탁도 했었는데.. 워낙 한국에 인간팔아먹는 사람들이 많아서 걱정되어 하지 말라고 충고도 해주었었다. 인도를 한번 찾아갈 때 내 꼭 고담에게 연락하리라.

    화들짝 펼치기



    하지만 인종차별적인 문제는 정말 심각한 문제이다.
    지금 우리나라 산업전선에 제삼세계 사람들이 없다면 산업전반에 심각한 지장을 초래할 수도 있는 문제다.





    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블UP하기
    1. Favicon of http://minimonk.net BlogIcon 구차니

      2010.07.10 00:40 신고 [수정/삭제] [답글]

      저도 중국에 프로젝트 차로 갔었는데
      거기도 사람들이 사는곳이고, 결국에는 한 2주 있다 보니 같은 사람이 사는 곳인걸 확실히 알겠더라구요.
      제가 한자를 잘 모르는 편이고, 그렇다고 영어 듣기/말하기가 잘되는것도 아니라서 고생을 했지만
      정안되면 필담으로(쓰기/읽기는 됩니다 OTL) 서로 기술적으로 이야기 하고
      마지막에는 고국으로 돌아간다 건강하게 잘 지내라고 하고는 돌아왔죠 ^^;

      아무튼, 피부색에 대한 편견이나 능력에 대한 오해는
      아무래도 직접적으로 겪어 보기전에는 해결하기 힘든 문제인것 같아요.
      어쩌면 서구적인 판타지로 인해서 유색인종들이 미개하다고 세뇌를 당하는 느낌이기도 하구요.

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

        2010.07.10 05:00 신고 [수정/삭제]

        구차니님과는 생각이 저랑 많이 비슷한것 같습니다.^^
        인도인들 저들 나름대로 문명의 발생지로써 자국을 대단히 존경하는 것 같더라구요. 암튼 피부색에 따른 인종차별문제 이거 심각하게 우리 뇌구조에 박혀있는 것 같습니다. 사람은 누구나 똑같은데 말입니다. 지금 하시는 공부 열심히 하셔서 다시 좋은 기회를 찾을 수 있길 희망합니다.~**

    2. Favicon of http://giznote.tistory.com BlogIcon 사라뽀

      2010.07.12 11:58 신고 [수정/삭제] [답글]

      제가 쓰려는 말을 구차니님이 써버려서...
      급, 할 말이 없어졌네요.. ㅡㅡ;;
      너무, 서구적 시각으로 유색인종, 특히나 동아시아 사람들을 보고, 판단하는 것 같다는 생각이 들어요.
      그쪽 동네 가면, 우리도 똑같은 취급 받는 건데 말입니다. ㅡㅡ;;

    댓글을 남겨주세요.

    티스토리 툴바