Thoughts2015. 8. 1. 19:56

2015년 회고: 너무 이른 실패담

안녕하세요?


원 글이 예상치 않게 퍼져나가면서 당초 의도와는 다른 뜻으로 해석되기 시작하고 있는 것 같아서, 글을 내립니다. 


그래도 원 글의 내용이 궁금하신 분들 위해 두 줄 요약:


"나이먹고 능력 없어서 망했어요"


"그래도 많은 교훈을 얻었으니 담에는 더 잘 해 보렵니다"


저 그리고.. 이 블로그에 올라간 글 가운데 상당수는 늙고 능력없는 개발자가 삽질하다 정리한 내용을 적은 거에 불과하니, 너무 심각하게 받아들이시면 곤란합니다.


그리고 원 글이 이곳 저곳에 퍼지다보니, 블로그 곳곳에 이상한 덧글이 달리기 시작했는데요. (뭐 대부분 인신공격성...) 그런 덧글 작성자 분들께는 영화 "굿모닝 베트남"을 추천드립니다. 그 영화 말미에, 로빈 윌리엄스가 연기하는 주인공 DJ를 죽자고 따라다니면서 괴롭히는 장교를 같은 군 장성이 한직으로 좌천시키면서, 이런 말을 하죠.


"첨에는 니가 그 친구를 왜 그렇게 못살게 구는지 이해해보려고 했는데... 다른 이유가 없었어. 너는 그냥 못돼먹은거야. 그게 네 본성인거지."


감사합니다. 



저작자표시비영리변경금지
Posted by 이병준
TAG 실패, 회고, 희망
Trackback 0 Comment 15

소중한 의견, 감사합니다. ^^

  1. 허니몬

    ^^ 언제나!! 응원합니다.

    2015.08.01 20:51 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. MoMo

    오르막길있고
    내리막길 있잖아요 ^^
    힘 내세요 ~ !

    2015.08.03 15:17 [ ADDR : EDIT/ DEL : REPLY ]
  3. archmond

    응원합니다.

    2015.08.03 22:05 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. it나그네

    Etri 다니셨던게 문제네요 ㅋㅋ...공무원 같은 엔지니어에서 세상에 변화를 줄 수 있는 엔지니어로 거듭나시는 상황이니 축하드립니다....그리고 1주에 술 한번 먹는거기자고 건강 잃었다고 하시면 술을 아예 드시드지 마시던지....더 열심히 드셔서 1주에 3,4번 먹고도 괜찮게 "개발"시키세요

    2015.08.03 23:24 [ ADDR : EDIT/ DEL : REPLY ]
    • 이병준

      감사합니다. 그나저나 죄송한데 술주정은 딴데 가셔서 좀...

      2015.08.03 23:53 [ ADDR : EDIT/ DEL ]
  5. 공감이

    우연찮게 블로그에 담겨진 글들을 읽게 되었는데, 연배도 그렇고 같은 엔지니어로서 공감되는 점이 많았습니다. 멀리가셔서도 꼭 건승하시고, 몸건강하세요. 사실 OLYMPUS는 오늘 읽으려고 남겨두었는데.. 삭제되서 아쉬웠어요. 글 너무 잘쓰시네요 재미있게 읽었습니다. 감사합니다.

    2015.08.04 16:57 [ ADDR : EDIT/ DEL : REPLY ]

  6. 비밀댓글입니다

    2015.08.06 14:45 [ ADDR : EDIT/ DEL : REPLY ]
    • 이병준

      글쎄요 퍼가실만한 글이 있으실지 모르겠으나.. ㅎㅎ 그러고 싶으시다면 상관 없습니다. 감사합니다.

      2015.08.06 21:43 신고 [ ADDR : EDIT/ DEL ]

    • 비밀댓글입니다

      2015.08.07 14:21 [ ADDR : EDIT/ DEL ]

  7. 비밀댓글입니다

    2015.08.15 09:33 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2010. 10. 14. 07:51

추정이 실패하는 이유

소프트웨어 프로젝트를 진행할 때 여러가지 이유로 추정을 하게 됩니다. "이 일을 하는 데 시간이 얼마나 걸릴까요?" 이 질문에 답을 하는 행위를 추정(estimation)이라고 합니다. 보통 계획은 추정 결과로 나온 추정치를 보고 잡습니다.

추정이 실패하는 데에는 여러가지 이유가 있습니다. 가장 최근의 사례를 예로 들어볼까요? 어떤 작업을 하는데 A라는 사람이 한 달이 필요할 거라고 추산했습니다. A는 해당 팀에서 소프트웨어 개발에 가장 정통한 사람이라고 부를 만한 능력을 가진 사람이었습니다. 그런데 막상 뚜껑을 열고 보니,그 일은 네 시간 만에 끝났습니다. 이런 경우, 추정은 실패했다고 보아야 합니다. 하지만 실제 업무 시간이 단축된 경우이니, 정말로 부정적인 효과로 이어진 추정이라고 보긴 힘듭니다. 만일 추정 대상이 된 업무가 프로젝트의 critical chain에 물려 있는 업무였다면, 이 실패한 추정은 프로젝트 기간 단축으로 이어졌을 것이고, 아무도 피를 보지 않았을 겁니다. 하지만 반대였다면?

위에서 예로 든 업무의 경우, 추정 실패 원인으로는 다음과 같은 것들을 들 수 있었습니다.

  • cross-compiling에 대한 이해 부족
  • autoconf와 같은 툴에 대한 이해 부족

따라서, 지식(knowledge)또는 노하우(know-how)가 부족했던 것을 추정 실패의 원인으로 추상화해 볼 수 있습니다. 대부분의 프로젝트가 그렇습니다. 추정은 '잘 모르기 때문에 하는' 행위라고 생각할 수 있습니다. 잘 알고 있다면, 추정할 필요가 없습니다.

소프트웨어 개발에서, 추정의 정확도를 높이는 가장 좋은 방법은 실험(experiment)입니다. 제 경험상, 실험은 다음과 같은 범주로 나누어볼 수 있었습니다.

  • 구조 실험 (experiment on architecture)
  • 성능 실험 (experiment on performance)

구조를 실험하는 것은 소프트웨어의 구조의 정당성을 확인하는 행위이고, 성능 실험은 어떤 소프트웨어가 실제 쓰이기에 합당한 성능을 보여주는지 알아보는 행위입니다. 이런 실험은 종종 테스트(test)와 혼동되기도 합니다만, 실험이 포괄하는 범위가 좀 더 넓기 때문에, 테스트는 그 하위 개념인 것으로 보는 것이 타당합니다.

에자일 세계에서는 실험을 종종 spike라고 부릅니다. 스파이크는 뭔가 잘 모를 때, 뭘 모르는지, 그리고 무엇을 몰랐는지 알아내기 위한 유용한 도구입니다. 소프트웨어 프로젝트를 진행하는 데 있어 가장 문제가 되는 지식의 불확정성(uncertainty)을 해결하는 가장 좋은 방법 중에 하나입니다.

스파이크를 진행하고 추정을 하면 추정의 정확도를 높일 수 있지만, 불확실성이 극도로 높을 때에는 스파이크를 진행하는 데 얼마나 걸릴 지 아는 것도 어렵다는 것이 문제가 되곤 합니다. 따라서 스파이크는 굉장히 숙련도가 높고 경험이 많은 사람들 한 두 명 정도가 모여 진행하는, 굉장히 집중적인 활동이 되어야 합니다. 아니면 프로젝트 후반부에 들어가는 시간과 맞먹을 정도의 오버헤드를 낳을 수도 있습니다.

추정이 보통 프로젝트나 스프린트 초반에 일어나는 행위라는 점을 감안하면, 스파이크도 가급적이면 사전적인 활동이 되어야 합니다. 그래야 추정치의 정확도를 높일 수 있고, 추정이 실패할 확률을 낮출 수 있습니다.

그러니, 무언가를 추정해야 하는데 그 무언가가 굉장히 중요하다면, 가급적 빨리 실험을 진행하는 것이 좋습니다. 회의를 해서 해결되는 문제라면 모두 모여서 머리 싸매고 해결책을 논하는 것이 좋겠습니다만, 회의를 해서 해결될 문제가 아니라면 무작정 비관적인 추산을 하는 것 보다는 하루라도 빨리 컴퓨터 앞에 앉아서 여러가지 대안들을 검증해 보는 것이 전체 프로젝트 진행을 위해서도 바람직합니다.

Posted by 이병준
TAG 실패, 추정, 프로젝트
Trackback 1 Comment 1

소중한 의견, 감사합니다. ^^

  1. 기억상실

    동감합니다.
    추정을 하기위한 실험을 완료하면 연달아 프로그램도 완성되곤 합니다.
    결국 실험하는데 몇 일이 걸리고 공식적인 일하는데는 하루 이틀 밖에 안걸리는 셈이죠.
    이런 과정을 거치면 대부분의 경우 결과가 매우 만족스럽습니다.

    문제는 주위에서 바라보는 눈길이 곱지 못합니다.
    금새 될 일을 분석한답시고 몇일씩 끼고 앉아서 놀았다는 오해를 받지요.

    2010.10.14 10:45 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2009. 9. 24. 13:42

프로젝트가 서쪽으로 가는 까닭은 (1)


오늘 또 재미있는 이야기를 하나 들었습니다.

이 프로젝트는 국내 굴지의 D모 그룹과 관계된 이야기인데요.

제가 아는 회사 한군데에 프로젝트를 줬답니다. 이 회사에서는 그 회사가 원하는 스팩 대로 성실하게 소프트웨어를 만들어서 납품하였는데... (통신 관련 소프트웨어였습니다.)

나중에 현장에 설치되고 보니 소프트웨어가 통신을 못하고 쩔쩔매는 현상이 발생하더라는 겁니다.

결국 소프트웨어 개발자가 심하게 족쳐지는 상황이 발생하였는데...

나중에 알고보니 원인은 하드웨어 때문이었습니다. 당시 관계된 회사가 하드웨어 개발사, 소프트웨어 개발사 이렇게 두 군데였는데, 하드웨어 개발사가 현장에서 자사 하드웨어로 통신 테스트를 할 때 달랑 몇 군데에서만 테스트를 해보고는 위에 "통신 잘 됩니다"라고 보고를 해 버린 겁니다.

하지만 최종 솔루션이 설치될 장소는 그렇게 만만한 장소가 아니었으니...

무선 신호가 흘러다닐 경로 곳곳마다 장애물과 전파 방해물이 존재하는, 최악의 장소였던 겁니다.

결국 장기간 수행된 프로젝트 결과물은 갈곳을 잃어버렸죠. 설계(6개월)와 개발(6개월)에 장장 1년이 걸린 프로젝트가 말입니다.

처음에 통신 테스트만 제대로 했어도 일년을 허송하지는 않았을텐데 말이에요...


Posted by 이병준
TAG 실패, 원인, 프로젝트
Trackback 0 Comment 1

소중한 의견, 감사합니다. ^^

  1. 기억상실

    대부분의 경우 소프트웨어의 결함은 용납치 않으면서 하드웨어의 결함은 쉽게 용서하곤 합니다.

    2009.09.24 15:25 [ ADDR : EDIT/ DEL : REPLY ]