아실 분은 아시겠지만, 저랑 저희 스터디에 김지원 군이 PLoP을 이끄는 Hillside Group의 이사회 위원으로 2012년 부터 합류하게 되었습니다.
Hillside-logo

PLoP을 다닌지 5년만에 되었네요.  아시아 학회의 공동 의장이기도 하지만, 이로서 더 넓은 영향력을 얻게 되었습니다.

계속 읽기

여러분과 함께 소프트웨어 아키텍트가 알아야 할 97가지의 역자로써 만남을 가지고자 합니다. 시간: 2월 28일 수요일 오후 9시 부터 ~ 10시(?) 이구요  준비물 : 마이크랑 화상 캠이 필요합니다.  등록하는 곳 : 지앤선 이벤트 페이지   이 행사는 위 책의 출판사인 지앤선에서 야심차게 준비하는 프로젝트입니다. 가능한 지방에 있는 분들과 좀더 소통을 하고, 추후 고등학생들과 같이 꿈나무들과 이야기를 나누는 […]

2012 sw 아키텍트 컨퍼런스

12월 14일 소프트웨어 아키텍트 컨퍼런스에 발표를 합니다.

저를 포함해 알람몬의 개발을 지휘하는 CTO 강진석 님, 그리고 요즘 이슈가 되는 BaaS의 전문가 진성주 PD 님과 함께 80분간 재미난 이야기들을 전달해 드릴 겁니다.  저보다 훨씬 대단한 2분이랑 같이 해서 마음이 무겁네요. 재미난 쇼가 되어야 할거 같아요.

주제는 Android OpenSource Application Block  입니다.  안드로이드 개발시 필요한 여러 에셋들을 소개하는 세션이 될거 같습니다. 슬라이드 쉐어에서 많은 트래픽을 받았던  안드로이드를 개발자를 위한 오픈소스 이야기 보다 더 풍성한 내용으로 설명을 드릴겁니다.

상세한 주제는 아래와 같습니다.

계속 읽기

지난 토요일 (2012/10/28) 애자일과 패턴의 대가인 Linda Rising(린다 라이징)과  만남을 가졌습니다. 저희가 출간이 눈앞에 있는 Fearless Change의 저자이시구요. Agile 진영에서 이분이 미치는 영향력을 실로 거대하며, 간단히 Infoq에서 찾아보시면 그 해답을 얻으 실수 있습니다. 전세계 열리는  왠만한 agile 컨퍼런스에 메인 speaker로 참여하시고, 많은 agile 서적이 linda rising에게 감사를 하고 있거든요.

만난지 2년 만이였어요. SPLASH와  Agile 컨퍼런스가 겹치면서, PLoP에 못 나오셨거든요. 정말 반가웠습니다.  하루 내내 우리 나라의 문화를 알기위해서 창덕궁 , 전쟁 기념관 등을 돌아다니며, 관심있게 보셨구요.  특히 거북선에 관심을 보이셨답니다.

저녁에 NHN  그린 팩토리 앞 나루 라는 퓨전 레스토랑에서 인터뷰를 하며 저희 EVA 식구들의 궁금중을 푸는 시간을 가졌습니다.  여러분에게 어떠한 이야기가 오고 갔는지 전달해 드리고자 합니다.   사실 모임전에 저희끼리  Google Drive를 통해 저희들의 질문들을 모아 놓았고,  다양한 사람들의 의견을 물을 수 있도록 안배를 해, 각자 우선 순위 높은  자시만의 고민에 대해  물어 볼수 있었습니다

이 질문을 통해 책에서나 세미나에서 듣지 못했던 사람 Linda에 대해서 많은 것을 깨달을수 있었으며, 70세의 나이에도 불구하고 정말 철저한 자기 관리에 놀랐습니다. 특히 롤 모델이 없는 여성 개발자들에겐 Linda Rising이 좋은 롤 모델이 될거라고 믿습니다.

이 글 정리에 큰 도움을 주신 김동현님, 유성우님 에게 깊은 감사를 드립니다. 

인터뷰..

계속 읽기

7월 7일 있었던 제2회 대한민국 커뮤니티 데이에 발표한 동영상 강좌가 올라왔습니다.

안드로이드, 오픈소스  그리고 패턴에 대한 강좌입니다.

 

계속 읽기

제 2회 대한민국 커뮤니티 데이에 meetup 세션으로 “아키텍트” 선배 분들을 만나실 수 있습니다.
많은 아키텍트들 중에, 제가 믿고 신뢰할 수 있는 아키텍트 4분을 모시고 토크쇼를 7월 7일 엽니다.

신현묵 이사님, 김동열 소장님, 강승준 책임님, 문용준 아키텍트님.

 

“아키텍트를  말하다” 가 토크쇼의 주제이며, 선배 아키텍트들의 여러가지 고충과 경험을 들어볼 생각입니다.

7월 7일 나눌 토크쇼의 주제

  • 아키텍트의 길을 선택한 이유
  • “자신의 도메인 영역 소개 ( 재미난 에피소드, 도메인 진입의 고통들)”
  • 프로젝트시 겪었던 에피소드
  • “개발자와 아키텍트가 된 후의 차이점 (지식 체계, 만나는 사람들, 하는 일등..)”
  • 아키텍트로 성장하기 위한 패스
  • 아키텍트로써 겪는 고충들
  • 가장 실패한 프로젝트에 대해서
  • 아키텍트가 생각하는 소프트웨어 개발자의 미래
  • 이해 당사자 (고객, 운영, 개발팀 등)와이 에피소드
  • 아키텍트가 되고 싶은 후배들에게 해주고 싶은 이야기들

정말 현업의 아키텍트들에게 이러한 이야기를 들을 경험이 얼마나 있을까요? 많은 참여 바랍니다.

스터디 그룹을 위한 패턴 언어에는 총 4개의 파트로 구성되어 있으며, 정신(Spirit), 분위기(Atmosphere), 역할 (Roles), 관습(Customs) 으로 나뉜다 .

스터디 그룹을 위한 패턴 언어 – Sprit 편

‘Spirit(정신)’ 부분에서는 1. (숫자는 해당 패턴 번호를 의미한다.) 스터디를 왜 해야 하는지, 2. 토론의 중요성에 관해, 3. 집중할 수 있는 분위기에서 진행하기, 4. 꾸준히 하기, 5. 인맥형성 부분이 있다.

스터디 그룹을 위한 패턴 언어 – Atmosphere 편

‘분위기’ 부분에서는 큰 부분에서부터 점차 세부적으로 기술하고 있으며, 6. 스터디의 지역적 장소 설정, 7. 장소의 분위기 설정, 8. 자리배열 방법, 9. 웹 페이지 의 순으로 기술하고 있다.

이 자료에 대한 모든 권한은 1차적으로 Joshua Kerievsky에게 있으며, 편역된 이 post의 권한은 소프트웨어 마에스트로 멘티였던 김민수, 장성환, 이원희, 채경훈 님에게 있습니다. 사용하실 분이 있으면, 위 네 분에게 문의해서 답신을 드리겠습니다.

역할  (Roles) 편

앞서 두  파트를 통해  스터디를 유지시키는 마음가짐, 여러 가지 분위기 조성에 대해서 알아보았다면, 이제는 스터디 팀원들 개 개인의  역할에 대해 설명하는 패턴언어이다.

‘역할’ 부분에서는 각 구성원의 역할에 대해 기술하고 있는데 10. 리더는 열정적으로, 11. 사회자는 의욕적으로, 12. 참가자는 적극적으로 임하고, 13. 참가자는 또한 준비를 해 와야 한다. 마지막으로 14. 잘하는 사람을 적극 영입해야 한다는 것으로 설명되고 있다.

계속 읽기

드디어 또 하나의 작품이 출간되었습니다.

아키텍트가 가 알아야 할 97가지에 이어 프로그래머가 알아야 할 97가지가 드디어 출간되었습니다.

여러 지인들이 의기투합해서 만든 작품으로, 오랜 시간이 걸려 드디어 빛을 보게 되었습니다. 정말 많은 분들이 고생을 해주셨구요.  10명이 넘게 번역 작업을 하느라 정말 고생이 많았습니다. :

특히 일정한 퀄리티가 나오도록 어려번 검수를 해주시느라 고생해 주신, 김수현 , 최현미 두 역자님에게 정말 감사드립니다.

저보다 더 많은 노력을 해주셔서, 최종 검수때  많이 편했습니다. 정말 두 분에게 고개 숙여 감사드립니다. 어떻게 보면 두 분의 이름이 1,2 역자로 먼저 나와야 하는데, 겸손하게 저에게 1역자를 주셔셔, 책임감이 크게 느껴집니다.

또한 베타리더 분들에게도 정말 감사드립니다.  오역을 많이 다듬어 주시고, 좀더 쉬운 용어로 바꾸는 작업을 해주셔서 이 분들이 아니였으면 정말 더 오래 걸렸을거 같습니다.

이전 소프트웨어 아키텍트가 알아야 할 97가지 보다 좀더 개발자에게 와 닿고 가슴을 적실 선배들의 조언들이 듬뿍 담겨 있습니다.  업계 최고의 아키텍트, 프로그래머, Agile 전문가들이 경험에 기반한 조언들입니다.

또한 특별 부록으로, 원서에는 없는 한국의 유명한 프로그래머들의 추가 에피소드가 실려 있습니다.

계속 읽기

여러분이 프로그래머라면, 여러분의 관리자나 동료 또는 사용자에게 지금 하고 있는 업무의 예측 결과를 알려 주어야 합니다. 그렇게 해야 그들이 목적을 달성하는 데 필요한 시간, 비용, 기술 등을 정확하게 이해할 것입니다.
정확히 예측하려면 예측에 대한 기술을 배우는 것이 가장 중요합니다. 첫째로, 예측이란 무엇이고, 그것이 어떻게 사용되는지 배워야 합니다. 이상하게 들릴 수 있겠지만,  많은 프로그래머와 프로젝트 관리자들이 예측이 무엇인지 정확히 알고 있지 못합니다.

다음에 나오는 프로그래머와 프로젝트 관리자의 대화는 전혀 이상한 것이 아닙니다.

  • 프로젝트 관리자: 이 기능을 개발하는 데 얼마나 걸릴까요?
  • 프로그래머: 한 달이면 됩니다.
  • 프로젝트 관리자: 너무 길어요. 일주일 안에 완료해야 합니다.
  • 프로그래머: 적어도 3주는 필요할 것 같은데요.
  • 프로젝트 관리자: 2주까지는 시간을 드릴 수 있을 것 같습니다.
  • 프로그래머: 네, 좋습니다. 2주로 하죠.

프로그래머는 결국 프로젝트 관리자가 만족하는 선에 맞춰 예측하고 있습니다. 하지만 이것은 프로그래머가 예측치를 제공한 것이기 때문에 프로젝트 관리자는 프로그래머
에게 책임을 전가할 것입니다. 이 대화에서 무엇이 잘못되었는지 파악하려면 예측, 목표, 커밋먼트라는 세 단어를 정의해야 합니다.

계속 읽기

저는 원하는 것을 말하지 않아도 될만큼 만족하고 있는 고객을 만나본 적이 없습니다.   대부분 그들은 엄청나게 세세한 부분까지 이야기 합니다.  문제는 고객들이 항상 모든 진실을 이야기하지 않는다는 것입니다. 그들은 보통 거짓말을 하지 않습니다만,  고객의 관점에서 말할 뿐 개발자의 관점으로는 이야기 하지 않습니다.  그들은 그들만의 용어를 사용합니다. 그들은 중요한 세부사항들은 생략합니다.  그들은 마치 여러분도 그들처럼 그 회사에서 20년동안 근무했다고 생각하는 것 같습니다.

거기에다가 많은 고객들이 처음에는 정말로 원하는 것이 무엇인지 모른다는 사실까지 더해집니다!   고객들중 일부는 ” 큰 그림”을 파악하고 있을 수도 있겠지만, 그들이 보고 있는 “큰 그림”에 대한 세부사항을 효과적으로 전달할 수 있는 경우는 흔치 않습니다. 다른 사람들은 전체그림에 대해서는 얕은 지식을 가졌을 수도 있지만, 그들이 원하지 않는 것이 무엇인지를 알고 있습니다.

그러므로, 무엇을 원하는지에 대한 전체의 진실을 여러분에게 말해주지 않는 누군가에게 어떻게 소프트웨어 프로젝트를 제공할 수 있겠습니까?  그것은 매우 간단합니다. 그들과 더 많이 접촉해야 합니다.

계속 읽기