»
S
I
D
E
B
A
R
«
[광고] 파이썬 웹 프로그래밍 – 목차로 만든 태그 클라우드
Apr 7th, 2015 by Wegra Lee

<파이썬 웹 프로그래밍: Django(장고)로 배우는 쉽고 빠른 웹 개발>

책 반응도 좋고, 마침 깔끔한 Word Cloud Generator라는 태그 클라우드 생성 사이트를 알게 되어 테스트 겸 만들어 보았다.

책의 목차를 긁어 조사 빼고 살짝 더 다듬으니 제법 괜찮게 나온다.

그나저나 내 파이썬 책 역자께서는 원고를 안 주신다. ㅠㅠ

파이썬 웹 프로그래밍_태그 클라우드

책 리뷰 <프로젝트 관리자를 위한 프로젝트 관리 이야기>
Mar 18th, 2015 by Wegra Lee

어느날 갑자기 관리가자 된 개발자를 위한 프로젝트 관리 이야기! 지금 하고 있는 책과 관련이 있어서 급히 읽어보았다. 스티브 멕코넬 책들과 <피플웨어>의 글귀를 많이 인용해서 관심도 살짝 생겼다.
FullSizeRender-2

이 책은 애자일 책은 아니다. 그렇다고 고리타분한 구식 소프트웨어 방법론 책도 아니다.저자의 자세한 경력이야 잘 모르겠지만, 다소 SI성 프로젝트들을 많이 이끌면서 얻은 현장 노하우를 정리한 듯하다.

나야 애자일을 추구했지만, 큰 기업이나 경영진 등 일을 문서로 진행하는 게 익숙한 사람들이 끼어 있다면 제대로 된 애자일을 하기 쉽지 않다. 이런 조건이 아니더라도, 동양적(수직적) 사고에 익숙해진 개발자들을 데리고 수평적 문화를 가정한 애자일 방법론을 따르는 데에도 어려움이 많다.

설령 애자일을 하기에 이상적인 환경이더라도, 소프트웨어 공학 지식이 너무 없이 무턱대고 애자일만 고집하는 것도 좋아 보이지 않는다. 애자일 코치 중에도 이런 사람들이 종종 있는 것 같은데.. 위험해 보인다.

‘필요 없는 일에 힘쓰지 말라’와 ‘하지 말라’는 많이 다르다. 후자에만 집중하다 보면 새로운(하지만 업계에서는 흔히 발생하는) 상황에 임기응변으로 대응하는 경우가 자주 발생한다. 어떠한 상황이 발생할 수 있고 이를 헤쳐나가는 방법에는 무엇무엇이 있으며 그 방법들 각각의 장단점을 알아 두면
어쩔 수 없는 경우라도 ‘가장 효율적인 방법’을 찾는데 큰 도움이 된다.

그런 면에서 200 페이지 분량의 요 책은 ‘현장에 필요한 정도의 소프트웨어 공학’을 부담 없이 익혀보기에 나쁘지 않아 보인다.

이 책은 유능한 개발자에게 어느날 갑자기 초보 관리자가 된 주인공과 그 멘토를 등장인물로 내세워
프로젝트 관리에 필요한 여러 이야기들을 풀어간다. 프로젝트를 크게 계획, 설계, 개발, 운영 단계로 나누고, 그중 계획과 설계 쪽을 집중해서 살펴본다.

이야기했다시피, 애자일 방식은 아니지만 실제 우리 환경에는 더 적합할 수 있다.

조직 문화 바꾸기
Aug 28th, 2014 by Wegra Lee

조직을 바꾸려면..
오늘 관련 이야기가 나와서 내 생각을 떠오르는대로 정리해봤다.
나름 ‘너무’ 거대한 조직을 바꿔보려 수 년간 시행착오를 거쳐 쌓아온 노하우(?)다.

  • 같은 편이 되어라.
    • 같은 말이라도 이쁜 사람이 해야 먹힌다. 때론 논리적 설득도 필요 없다.
    • 아무리 옳은 이야길 해도 자기편이 아닌 사람의 말은 잘 듣지 않는다. 설혹 머리로 이해해도 몸은 따라주지 않는다.
    • 겉으로만 말고 진심으로 같은 편이 되어야 한다. 적을 속이려면 우리 편부터, 우리 편을 속이려면 나부터 속여야…
  • 일을 잘해라.
    • 인정받아라. 일 잘하는 사람의 의견에 귀담아 들을 수밖에 없다.
    • 내가 인정 못 받겠으면 인정받는 사람을 적극적인 지지자 혹은 주도자로 끌어들여라.
    • 기본적인 일은 하면서 변화를 요구해야 한다.
  • 주제는 분위기 파악해서 꺼내라.
    • 평소 준비해두었다가 적당한 시점에 이야길 꺼내라.
    • 다른 일로 바빠 죽겠는데 당장 급하지 않은 주제로 시간 뺏지 마라.
  • 솔선수범하라.
    • 필요하다면 기꺼이 나서서 하라.
    • 직접 해보고 이야기해야 신뢰도 얻고, 최소한 노력이라도 인정받는다.
  • 너무 대놓고 바꾸려 하지 마라.
    • 다른 사람들은 거부감을 가질 수 있다.
  • 윗사람 이전에 동료들의 의견을 듣고 공감을 얻어라.
    • 위로부터의 개혁은 왜곡되기 쉽고, 자생력이 약하다.
  • 욕심부리지 말고, 너무 기대하지도 마라.
    • 자신의 위치와 영향력에 맞는 것부터 서서히 바꿔라.
    • 그 이상을 원한다면, 더 윗사람 혹은 더 영향력 있는 사람을 끌어들여 그 사람이 주도하게 하라.
    • 욕심과 기대가 크면 결국 제풀에 지쳐 포기하기 쉽다.
  • 쉽게 포기하지 마라.
    • 실패하더라도, 계속 준비하고 때를 기다려라.
    • 사람은 원래 잘 안 바뀌고, 조직은 더 안 바뀐다.
    • 조직은 구성원이 바뀌고 시간이 지나고 경험과 견문이 쌓이며 드러나지 않게 변해간다. 예전에 실패한 변화가 말 한마디에 어이없게 성공하기도 한다.
  • 변화를 요구하는 동료에게 희망을 남겨줘라.
    • 때론 내가 변화를 막는 벽이 되기도 한다.
    • 혹은 동조해주지 못할 때도 잦다.
    • 잘 듣고 이해하고 설득하여 그들 마음속 변화의 불씨가 꺼지지 않게 하라.
구글 코리아 채용 정보
Aug 27th, 2014 by Wegra Lee

요즘 구글 코리아에서 소프트웨어 엔지니어를 잔뜩 뽑고 있단다.

당장도 그렇지만.. 후에 구글 지원을 고민하는 사람에게도 도움이 될테니 따로 포스팅해놓았다.

[회사 미션]

  • 세계의 모든 정보를 조직해서 모두에게 뿌린다. (organize the world’s information and make it universal.)

[조직 구성]

  • 구성도: http://bit.ly/1lekD9q
    • ‘다른 회사는 모르겠지만, 구글 그림은 와 닿는다.’ by 구글 엔지니어
  • 팀 크기 평균: 3.5명
    • 프로덕트 매니저 등 비 개발 인원도 거의 다 백그라운드 Computer Science다.

[문화]

  • 데이터 기반 수평적 토론
  • 핵심 가치(사용자에게 어떤 가치를 주는가?)는 협상 대상이 아니다.
    • 특정 이해관계자, 일정 등 때문에 꼭 필요한 기능이 빠지거나 엉뚱한 기능이 들어가지 않는다.
  • 구글 내의 모든 인프라 소스는 오픈되어 있다. (설계 문서도 마찬가지)
  • 필요하면 직접 고치고 기능도 추가할 수 있다.
  • 강력한 리뷰 문화.
    • 디자인, 코드, 배포 프로세스 등 모두 관련자들이 리뷰한다.
    • 리뷰어가 동의하지 않으면 런칭 불가.
  • 테스트에서 프로덕션 배포까지 소프트웨어 엔지니어가 수행한다.
  • 개발 인프라 거의 무제한
    • 테스트에 컴퓨터 10,000대가 필요하다? 그냥 쓰면 된다.
  • 시간 관리는 본인이 알아서..
  • 개발자가 꿈꾸는 회사지만, 절대 널널하진 않다.

[원하는 인재상]

  • 지식과 경험 (주로 컴퓨터 과학과 구글 인프라)
  • 수행력
  • 기술 리더십/영향력
  • 조직 영향력

[이력서]

  • 잘하는 분야 중심으로..
  • 과제 기간/수 보다는 무엇을 배웠는지..
  • 학력, 영어 점수, 경력 기간 따위.. ㅎ
  • 최소 10번은 사람들의 리뷰를 거쳐 다듬어라.
  • 제출
    • 소프트웨어 엔지니어는 아마 여기인듯..
    • 그 외에는 여기서 알아서 찾으면 될듯..

[면접]

  • 전화 인터뷰에서 구글 닥스로 실제로 코딩한다.
  • 온사이트 인터뷰
    • 면접 절차 중 가장 많이 떨어지는 곳 (남 앞에서 칠판에 코딩하는 게 쉽지 않다)
    • 모의 인터뷰 영상
  • 영어 점수는 안 보지만, 실제 커뮤니케이션 가능해야..
    • 온사이트 인터뷰시 외국인이 인터뷰어로 들어갈 수 있다.
    • 당분간 구글 코리아의 모든 프로젝트는 글로벌 프로젝트다.
  • 2010년인가.. 지원에서 입사까지 평균 51일 걸렸음
    • [팁] 인터뷰 날짜 잡을 때, 자신이 준비할 기간을 고려해 잡아라.

[재지원]

  • 1년 이후에 하는 게 좋다.
    • 1년 전에는 기존 (떨어졌던) 면접 점수가 함께 고려된다.
    • 1년이 지나면 기존 점수는 사라진다.
  • 기 제출한 이력서를 갱신하려면 무시하고 새로 지원한다.

대강 이 정도로 정리해봤습니다.

일정 수립 주체에 따른 개발 생산성
Aug 7th, 2014 by Wegra Lee

<피플웨어 3판> 초반에 일정 예측 주체와 생산성을 정리한 아래 표가 나온다.

사진

그런데 여기에 ‘경영진과 관리자 함께’가 빠져서 좀 아쉬워
모 기업에서 (마치 표준 프로세스인듯) 자주 겪은 경험담을 남겨본다.

경영진: 일정 내놔.
관리자: 여기..
경영진: 땡겨.
관리자: 그럼 기능을 빼야..
경영진: 확~!
관리자: 그럼 일정을 늘려야..
경영진: 우쒸!
.. (반복) ..
관리자: 해볼게요. 하지만 전 분명 안 된다고 말했어요.
경영진: 한다고 했으니 너가 책임져!

관리자: 자! 야근이다! 어차피 안 될 거지만 하는 척이라도 하자!
개발자: 뭐래.. (관심 없음)

결과야.. 얘기하지 않아도 ㅜㅜ

책리뷰 <한상기의 소셜미디어 특강>
Aug 5th, 2014 by Wegra Lee

<한상기의 소셜미디어 특강>사진

우선.. 이 방대한 정보를 모아 책으로 엮어낸 저자께 경외감을 표한다. 이 책은 제목에서처럼 한 편의 특강을 듣는 기분으로 읽었다. 아! 한 편이 아니라 한 학기 정도 되겠다! ^^

1부는 간단한 도입부..

2부인 소셜미디어 발전사는 소셜미디어 춘추전국시대의 흥망성쇠의 역사를 외적 관점에서 서술하고 있다. 나름 소셜미디어 쪽 업무를 제법 했던 터라 ‘아! 그랬었지!!’하며 기억을 상기시켜주는 내용이 많았다. 그래서 빨리빨리 넘어갈 수 있었지만, 영화 소셜 네트워크처럼 극적인 전개나 소셜미디어의 심연을 느낄만한 내용은 없으니 아주 빠져드는 부분은 아니었다. 하지만 국내 소셜미디어 중심으로 활동해온 사람에게는 지구 규모의 역사를 간략히 훑어볼 수 있는 좋은 내용일지 모르겠다.

3부가 재밌었다. 제목은 ‘소셜미디어의 사회적 가치와 의의’라지만 나는 가상 세계에서의 ‘인간 심리’, ‘정체성’, ‘행복’, ‘집단 사고’ 등 심리학적 혹은 철학적 관점에서 해석하며 읽어나갔다. 매트릭스에 지배되는 세계를 꿈꿔서 그런지, 먼 미래에는 가상 세계가 적어도 현실과 동등하거나 그 이상의 영향력을 가진 제2의 세상으로 커지는 것도 가능할 듯하다. 우주 정복을 위해 다투는 것보다 가상 세계를 정복하기 위해 다투는 날이 더 빨리 올지도 모르겠다.

4부.. 나는 3부를 읽으며 온갖 상상을 해댔지만, 사실 책에서는 4부가 미래를 이야기한다. 여기에선 15장이 관심을 끌었다. 15장은 소셜 데이터를 활용해 국가 질병 관리 센터보다 2주나 빨리 질병 확산을 예측하고 위치 정보로 세계 지도를 다시 그리고 사람의 감정 변화까지 읽는 이야기가 나온다. 데이터가 쌓이면서 좀 더 나아가면 전 세계를 하나로 묶어 실시간으로 상호작용할 수 있게 되는 것이다. 우리는 하나의 세포가 되고 인류가 하나의 생명체가 되는.. 그보다는 개미 군집과 같은 모습이랄까? 인류를 지금까지는 없던 방식으로 묶어 주는 매개가 될 것은 확실해 보이니, 흥미진진한 구경거리가 될 것이다.

다시 현실로 돌아와서.. 이 책의 내용을 제대로 공부하려면 마음먹고 몇 주를 붙들고 있어야 할지도 모르겠다. 광범위한 주제를 다루며 많은 자료를 인용하고 있어서, 조금만 깊게 들어가려 하면 봐야 할 자료가 산더미처럼 늘어난다. 다행히(?) 나는 그렇게까지 알고 싶은 마음은 없으니 이쯤에서 마무리하겠다.

스크럼 요약 정리
Jul 24th, 2014 by Wegra Lee

4~5년 전 스크럼 공부하며 정리해 놓은 마인드맵이다.

대부분 <스크럼: 팀의 생산성을 극대화시키는 애자일 방법론>의 내용이라 보면 된다.

이미지가 엄청 크니 확대해서 보시길..

Scrum

스크럼 주의점 몇 개
Jul 23rd, 2014 by Wegra Lee
최근 팀에서 태스크보드를 쓰기 시작하면서 스크럼 용어가 언급되어
몇 가지 중요한 것 당부한 글…
스크럼에서는 기본적으로 ‘개인’은 별 의미가 없습니다. ‘팀’만 생각합니다.
누구 한 사람이 특정 작업을 완료하지 못했어도 결국 팀의 책임입니다.
누군가에게 잡무가 너무 많다면 이를 막거나 줄여주거나 대신 해주어야 하며, 방도가 없다면 어쩔 수 없는 거죠.
기술 문제에 봉착해 있다면 해법이나 길을 알려줘야 합니다.
팀은 공동 운명체..!!
이를 위해선
누가 뭘 하고 있는지, 어떤 문제가 있는지 활발히 공유하고 서로 도와야 합니다.
그 방법으로 태스크보드, 일일 스크럼 회의, 회고 같은 도구 쓰게 됩니다.
태스크보드는 팀의 목표와 진척 현황을 상시로 한 눈에 살펴보고, 목표를 상기하기 위한 도구입니다. 무언가 제대로 안되고 있다면 표가 나겠죠. 일일 스크럼 때 활용하기도 하고요.

보드에 붙이는 업무는 가능하면 (집중했을 때) 4시간 안에 끝낼 수 있는 단위로 나누는 게 좋습니다. 하루하루 지날 때 Done으로 옮기는 포스트잇이 있고 없고가 성취감에 큰 영향을 주기도 하고, 며칠이 지나도 계속 Doing 상태면 다른 이뿐 아니라 자신도 현황 파악이 안되고 목표도 불분명해져 관리가 안 됩니다.

일일 스크럼은 보다 적극적인 상황 공유 수단입니다.
매일 ‘같은 시간’에 ‘모든 팀원’이 모여 각자 다음 ‘세 가지’를 이야기합니다.
  • 어제 한 일
  • 오늘 할 일
  • 봉착한 문제
이중 가장 중요한 것이 봉착한 문제입니다. 모든 팀원은 이 문제를 해결할 방법을 고민하고 알려줘야 합니다. ‘고민, 잘 모르겠는 것, 실수 등을 편하게 털어 놓으면 누군가가 노하우를 알려준다’는 분위기가 형성되지 않으면 서로 벽이 생기고 사람들이 위축됩니다.
회의 시간은 최대 15분으로 제한합니다. 길어질 이슈는 일일 스크럼 후에 담당자만 따로 모여 이야기합니다.
<같은 시간, 15분 이내, 상황 공유>를 통해 다른 회의를 최소화하고 각자 일에 집중할 수 있게 합니다. 따라서 시작 시간이 들쑥날쑥 하거나 회의가 길어지면 효과가 반감됩니다.
회고는 주로 더 큰 관점의 노하우 공유나 제도 개선 방안 등을 논하는 자리입니다. 자아 비판이 아닙니다. 주로 이런 논의가 이루어집니다.
  • 평소 이런 게 좀 잘 안된다고 생각했는데, 이렇게 하면 나아질 것 같다
  • 이번에 이렇게 해봤는데 괜찮았으니 계속 해보자.
  • 이 아이디어는 막상 해보니 처음 생각같은 효과가 없었다. 취소하거나 방식을 바꿔서 다음엔 이렇게 해보자.
[업데이트] 책리뷰 <개발자 영어, 코드로 감 잡다>
Jul 2nd, 2014 by Wegra Lee

<개발자 영어, 코드로 감 잡다>

IMG_4587수년 전부터 ‘개발자를 위한 영어’라는 주제에 관심이 있었고, 책을 써볼까 하는 생각도 했던 터라 이 책이 나온다는 소식에 반갑고도 한편으론 아쉬웠다. 어떤 책인지, 내 생각과는 무엇이 비슷하고 다른지 무척 궁금하여 저자에게 연락도 해보고 출간과 거의 동시에 주문했다. 정작 그래놓고 이런저런 핑계로 이제서야 읽게 되었다.

하지만 아쉬움이 많이 남는다.
적어도 내게는 잘 와 닿지 않고, 다른 이에게 권해볼 마음도 솔직히 들지 않는다.
이 책의 콘셉트는 개발자에게 익숙한 프로그래밍 언어 소스 코드의 구조를 빌려 영어를 가르친다는 것이다. 재미난 접근이지만 문제가 있다. 프로그래밍 언어란 컴퓨터에 로직을 가르친다는 제한된 목적만으로 만들어진 절제된 언어다. 사람끼리의 원활한 의사소통을 위해 수천 년을 진화해온 영어와는 비교할 수 없다. 작은 것으로 더 큰 것을 설명하려다 보니 여러 가지로 한계가 있지 않았나 짐작된다.

기본 개념은 문장을 하나의 완제품이라 보고, 완제품을 만들기 위해 여러 부품(문장 구성 요소)을 조립해가며 영어를 익힌다는 것이다. 그 부품들을 뭐는부품(주어), 뭐한다부품(동사), 뭐를부품(목적어), 어떤부품(형용사), 어케부품(부사) 등으로 부른다. 여기서의 문제는 십수 년간 영어를 공부한 사람이든 십수 년간 개발을 해온 사람이든 가리지 않고 너무 생소한 용어를 사용한다는 점이다. 도서관에서 맘 잡고 공부한 건 아니지만, 책 읽는 내내 이 용어들에 익숙해지지 못했다.

다양한 예외가 등장한다. 수식하는 위치(앞/뒤) 과거형, 과거분사형, 관사, 복수형, 절과 구, 의문문 등 영어를 배우기 위해선 꼭 필요하지만 위와 같은 간단한 구조에서는 표현할 수 없는 특성이 많아, 결국은 ‘이럴 땐 이렇게’, ‘요럴 땐 요렇게’가 될 수밖에 없다. ‘코드로 감 잡다’는 부제를 가지고 있지만, 코드의 범위를 벗어나 원래 영어를 배우기 위해 필요한 모든 요소를 잘 맞지 않는 틀과 익숙하지 않은 용어로 배우려 하는 것 같다.

너무 신랄한데ㅡㅡ 아무튼 그렇다. ;;

저자께는 죄송하지만, ‘영어를 더 쉽게 배워보겠다’라는 진지한 생각보다는 ‘영어를 이렇게도 설명할 수 있구나?’가 궁금한 사람에게 추천함직하다는 게 솔직한 총평이다.

[업데이트]

저자인 나솔님과 나눈 이야기 요약..

나: 작은 걸로 큰 걸 설명하려니 또 하나의 낯선 문법이 만들어진 거 같아요. 우리 나라 개발자는 다들 영어를 배웠으니, 낯선 문법보단 익숙한 영어 문법이 나을 지도..

나솔님: 어떤 말씀인지 알겠어요.

나: 색다르고 체게를 완성도 있게 구축한 건 높이 평가해요. 그리고 영어를 갈구하는 개발자들이란 시장의 존재를 입증한 선구자시기도 하고요. 그래서 앞으로 경쟁작 많이 나올 겁니다.

나솔님: 시장 드러나게 하기가 바로 원하는 거였어요. 혼자선 한계가 있죠.

나: 새로운 방식이 시선 끌기는 좋지만, 실효성은 아직 물음표네요. 실효성을 높이려면 추가적인 노력이 필요할 거에요.

나솔님: 물론이죠. 책 한 권으로 끝낼 생각은 아닙니다.

나: 솔직히 물음표지만 여기서 끝내긴 아까우니 열심히 부탁합니다. 시장 드러내줘서 고마워요.

[저자 특강]

곧 8월 1일에 저자 특강도 있으니 관심 있는 분은 서둘러 등록~

책리뷰 <월스트리트저널 인포그래픽 가이드>
Jul 1st, 2014 by Wegra Lee

올만에 책 리뷰를 간략히 적어본다.

IMG_4568

<월스트리트저널 인포그래픽 가이드>
도나 웡 지음 | 이현경 옮김 | 인사이트

책 표지부터 내용, 편집까지 정말 군더더기 없이 깔끔한 책이다!!
직장인이라면 누구나 항상 책꽂이에 꽂아두고 도표를 그릴 때마다 한 번씩 뒤적여봐야 할 책이다.

몇 달 전 한 UX 강사로부터 최고의 인포그래픽 책이라는 극찬을 듣고 구입하게 되었지만,
인포그래픽 전반을 다루지는 않기 때문에, 다소 논란의 여지는 있을듯하다.
이 책의 주 대상은 차트와 표(table), 그중에서도 ‘월스트리트 저널’이라는 이름에서 알 수 있듯 경제/금융 쪽에 사용되는 것에 초점을 맞춘다.
그렇다고 이게 큰 단점이 되진 않는다. 막대 차트, 선 차트, 파이 차트, 표. 실상 우리는 이것 외에는 쓸 일이 평생 몇 번 없기 때문이다. (책에서는 픽토그램과 표도 살짝 다룬다.^^)
오히려 우리에게 꼭 필요한 핵심만을 간추려 알기 쉽게 설명한 액기스다.

1장 ‘기본 원칙’은 데이터 선정부터 글꼴, 색상, 숫자 사용 시 주의점 등 말 그대로 어느 경우에나 주의해야 할 원칙들을 설명한다.
2장 ‘똑똑하게 차트 그리기’는 본격적으로 선/막대/파이 차트, 표, 픽토그램, 지도 그리기를 다룬다. 항시 나쁜 예와 좋은 예를 함께 보여주어 짧은 설명만으로도 이야기의 핵심을 쉽게 파악할 수 있도록 구성했다.
3장 ‘차트 편람’은 차트를 그릴 때 많이 사용하는 기초적인 수학/통계 지식과 시장 지식을 설명하며 올바른 사용법을 알려준다.
4장 ‘난감한 상황’은 일부 데이터가 누락된 경우처럼 망설여지는 상황에서의 원칙과 대처법을 알려준다.
5장 ‘차트로 계획 세우기’는 팀 구성, 일정, 진척 보고 등 프로젝트 관리 정보를 차트로 표현하는 효과적인 방법을 소개한다.

»  Substance: WordPress   »  Style: Ahren Ahimsa