블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (45)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (2)
Total166,348
Today13
Yesterday8
지난주에 현업과는 관련이 없어 보이는 NHN에서 주관하는 개발자 컨퍼런스에 참석하였습니다.
업무에 직접적인 관련이 없다보니 영감이 늦게 밀려드는가 봅니다. 이제서야 회고를 해봅니다. (발표 내용에 대한 후기는 없답니다.ㅋ)

NHN은 어디로 가고 있나?

Deview가 끝나고 난 느낌은 "NHN은 이렇게 잘 하고 있구나" 정도였습니다. 솔직히 그 이상도 이하도 아니었습니다.
후기 경품이 탐이 났지만 딱히 쓸말이 없었습니다. 싸이트 가면 동영상이 모두 공개 되어있는데 후기를 쓰자니 거시기 했습니다.
그러던중 문득 이런 생각이 들었습니다. 왜 키노트 스피치를 좀 지루할 정도로 구구절절히 길게 하였을까? 
제가 추측한 이유는 NHN이 가고 있는 목표에 대해서 진심으로 구구절절히 공유하고 싶었기 때문입니다.
키노트 스피치가 끝난 후에 지인중 한분이 그러더군요. "그냥 애자일 한다고 하면 되지 않나?"
분명 NHN에서 하고 있는 활동들은 애자일스러웠습니다. 하지만 애자일이 NHN의 목표가 아니기 때문에 궂이 애자일을 한다고 할 필요가 없었던 것이라고 생각합니다.
이러한 관점으로 Deview의 강연들을 생각해보니 NHN이 가고자 하는 곳이 어디인지가 보이더군요.^^ 
그곳이 어디인지 제가 자세히 기술할수는 없지만 분명한건 NHN 내부 개발자만을 위한 천국은 아닐겁니다.

궂이 애자일 조직이라고 표현할 필요가 없다.

가끔 애자일을 짝 프로그래밍이나 테스트 주도개발, 스크럼등의 Best Practice로 여기시는 분들이 많습니다.
혹은 갓 입사한 회사나 팀에서 애자일을 모른다고, 애자일 팀이 아니라고 실망하는 신입 개발자분들도 있습니다.
수단과 목표가 약간 혼동되는 부분이라고 생각합니다. 애자일도 목표는 아니라고 생각합니다.
꼭 개발조직에 애자일이나 RUP, Waterfall, CMMI 등의 정체성이 명시적으로 존재해야 할까요? 그런건 정치판에서도 지겨운데...
우리가 원하는건 애자일 조직이 아니라 행복하게 개발할 수 있는 매우 효율적인 개발 조직일겁니다. (정확히 말하면 제가 원하는 것입니다^^)
물론 조직에 맞는 애자일스런 Practice를 만들어나가면 좀더 빠르게 그런 조직을 만들수 있을것입니다.
제가 말하고 싶은건 뭘 하면 애자일이고 안하면 애자일이 아니다 이런게 중요한게 아니다라는 것입니다.^^;;
개인적으로 '애자일'이란 표현보다 '실용적인'이란 표현이 더 좋습니다.ㅋ
이런 점에서 NHN의 발표에서 '애자일'이란 용어를 쓰지 않은 것은 현명한 선택이었다고 생각합니다.

기대되는 NHN의 행보

얼마전까지만 해도 NHN은 뒤뚱거리는 거대한 한국의 포털 기업으로만 생각했었습니다. 개발에 열정을 가졌던 친구가 NHN의 신입사원으로 입사한 후에 개발의 열정이 식어버린... 그냥 포털 대기업으로만 생각했었습니다.
하지만 Deview를 보면서 생각이 조금 바뀌었습니다. 열악한 한국의 개발 환경을 불평, 불만만 하는 사람들이 변화될 수 있도록 기여하는 기업이 되고 있다고 생각합니다. (우리 회사도 그런 기업이 될겁니다!^^)

스스로 바뀌어야 환경도 바뀝니다.^^

이상 짧은 회고였습니다;... 회고라기 보다는 주저리주저리 떠든;;ㅋ



NHN Deview 2010 동영상 다시 보기 및 자료 : http://deview.naver.com/2010/courses.nhn
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.12.13 11:32 신고 ryuhayoung  댓글주소  수정/삭제  댓글쓰기

    청하 안녕~ ㅎㅎㅎ

  2. 2011.02.16 17:01 신고 arload  댓글주소  수정/삭제  댓글쓰기

    모든 일원이 만족하면서, 개선해 나가고 있따. 나아지고 있다는 느낌. 성장하고 있다는 느낌을 주기는 정말 어려운거 같아요.
    이러한 시도는 정말 감탄할만 하죠. 애자일이 만능이 아니라. 조직도 만족하고, 조직 구성원도 만족하는 것.. 그게 정말 이상인거 같습니다. 다른이의 이상과 저희들의 이상은 다르니깐요.. :)

  3. 2011.02.18 20:21 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    스스로의 자세를 바꾸면 그 다른 이상들이 하나로 모여질수 있다고 생각해요^^

  4. 2011.11.24 21:44 신고 뇨릉  댓글주소  수정/삭제  댓글쓰기

    "행복하게 개발할 수 있는 매우 효율적인 조직".. 저도 그런 조직을 꿈꾸는 1인입니다...^^;
    하지만 노력하는 만큼 잘 안되서 요즘은 지처가고 있는 중이랍니다...
    사람들의 마인드를 바꾸기가 쉽지 않더군요.. 제가 괜히 엄한데와서 하소연하는군요 >.<

    • 2011.11.25 15:51 신고 윤청하  댓글주소  수정/삭제

      반갑습니다! 윤청하입니다.^^
      저도 한때 지쳐있었는데, 요즘은 200%이상 활력소를 찾았습니다.
      제 경우엔 남을 보다가 제 자신에게 포커스를 바꿔보니 즐거워지고 생산성도 매우 높아졌습니다.
      그렇게 지내다 보면 남들이 호기심을 갖게 되더라구요. 어떻게 하면 저렇게 즐겁게 하나...
      이제 시작인거죠!

      고민은 나눌수록 잘 풀리는거 같습니다. 잘부탁드려요~

얼마전에 "창의적인 아이디어는 어디에서 오는가?" 라는 주제로 강연을 들은적이 있습니다.
강연자분의 결론은 다음과 같았습니다.
창의적인 아이디어는 새로운 것이 아니라 기존에 있던 것을 새롭게 보는 것이다.
창의적인 아이디어를 얻기 위해서는 내가 보고 경험한 것들을 새롭게 볼줄 알아야 하며, 
다른 사람의 말과 행동을 새롭게 볼줄 알아야 한다.
강연을 듣고 저는 다음과 같은 생각을 했습니다. 
항상 주위의 모든것에 호기심을 갖고 관찰하여 필요한 경우 내것으로 만들수 있어야 창조적인 인재가 될수 있다
결국 매우 상투적인(cliche) 결론이었습니다. 하지만 다시 생각해보니 개발자들에게 매우 필요한 능력일것 같다는 생각을 했습니다.

창의적인 개발자는 어떤 능력이 필요한가?

저는 다른 개발자들이 만들어 놓은 결과물을 분석하고 이해할줄 알며, 가져다 사용할 수도 있고 필요한 경우 개선될 수 있도록 기여할 수 있는 개발자가 창의적인 개발자라고 생각합니다.  혼자 모든 것을 만들어 내는 것 보다는 다수의 사람이 같이 만들어 내는 것이 더 창의적인 결과물이 될수 있기 때문입니다.
세계적인 오픈소스에 기여하지 않더라도 같은 회사내, 같은 연구소내, 같은 팀내의 다른 개발자들의 결과물들이 같이 공유하며 개선되고 성장 할 수 있다면 그 조직은 창의적인 개발 조직이라고 할수 있을 것입니다.
이러한 것들이 가능하려면 조직 내에 소스코드 오픈 문화, 개발자간의 신뢰 문화등이 밑바닥에 깔려 있어야 할 것입니다.
어렵지만 할 수 있지 않을까요? 전 애자일이 창조적인 조직을 위한 은탄환이라고 생각하지 않습니다. 
하지만 시도해볼만한 것임은 확실하다고 생각합니다.^^

Two Heads Are Better Than One.
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.09.13 09:43 신고 noforest  댓글주소  수정/삭제  댓글쓰기

    공감~

  2. 2011.02.25 10:36 신고 이장석  댓글주소  수정/삭제  댓글쓰기

    글 잘 보았습니다.
    좋은 하루 되십시오.

현재 제가 속한 팀은 아직 애자일 프랙티스를 전파하기에는 이른 시기입니다. 
고민 끝에 (사실 실제 고민은 몇초?;) 점진적 설계와 구현을 해보는것은 어떻겠냐고 같이 일하시는 윗분께 건의했습니다.
길지않은 토론 끝에 UML로 설계를 하고 이터레이션은 고정시키지 않는다는 전제하에 점진적 설계와 구현을 해보기로 했습니다.
제가 정한 한 이터레이션에서 해야할 일들은 다음과 같았습니다.
  1. 해당 이터레이션에서의 요구사항을 Use-case Diagram으로 작성 및 리뷰 (mandatory)
  2. Activity Diagram 및 Collaboration Diagram은 개인적으로 작성 (optional)
  3. 섬광탄 구현 (optional)
  4. Class Diagram 및 Sequence Diagram 작성 및 리뷰 (mandatory)
  5. 설계에 맞게 구현 (mandatory)
  6. 구현에 대한 짧은 회고 및 피드백으로 설계 수정후 구현 수정 - 반복 (mandatory)
  7. 데모 후 다음 이터레이션 (mandatory)

결과물은?
  • 프로젝트 기한 : 예상보다 1주일 정도 먼저 끝났음
  • 결과 바이너리 데모 : 원했던 기능 완료, 어느정도 안정화 됨
  • 설계 문서 : Use-case Diagram 1장, Class Diagram 3장, Sequence Diagram 3장 - 소스코드와 99% 일치

회고
  • 기존의 관행을 깨보았음 (사실 작은 프로젝트라 큰 의미는 없음)
  • UML 설계를 통한 설계 리뷰 및 공유는 정말 괜찮았음
  • 이터레이션을 고정시키는 것에 대해서 반감이 있는 경우에는 살짝 빼도 무리가 없어보임
  • 기존의 관행과의 협상에서 줄건 주고 얻어올건 얻어와야 함 (이렇게 안하면 애자일이 아니다 라는 고정관념을 버려야함
  • 섬광탄 구현이 UML 설계에 많은 도움이 되었음

결론 : 
나는야 행복한 개발자~
Posted by 윤청하

댓글을 달아 주세요