ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 자전거 배우기와 소프트웨어 개발
    PM & Agile 2011. 7. 5. 19:37

    자전거

     창피한 이야기를 하나 고백해야겠다. 뭐냐 하면 나는 자전거 타는 법을 한 번에 배우지 못했다는 것이다. 나는 또래 친구들 보다 상당히 늦게 자전거를 배웠는데, 그 때가 중학교 1학년 때쯤인 것 같다. 그 때는 벌써 자전거를 타고 학교에 등교 하는 친구들이 많이 있었는데도 나는 자전거를 탈 줄 모르는 상태였다.

    느날 친구들과 이야기 중에 화제가 자전거로 옮겨졌고 내가 자전거를 탈 줄 모른다는 사실을 안 친구들은 날신기하게 쳐다 봤다. 그리고 한 친구가 주말에 자전거 타는 법을 알려주겠다고 제안했는데 그 당시 어떻게든 자전거를 배워야 한다고 생각하고 있던 난 그 기회를 놓칠 수가 없었다.

    때부터 두려움 반 설렘 반으로 주말을 기다리며 난 머리 속으로 수 없이 자전거 타는 법을 연습했다. ‘왼쪽으로 넘어질 것 같으면 핸들을 오른쪽으로 틀어라.’ 던가 몸에 중심을 이동할 줄 알아야 한다던가.’ 하는 친구들로부터 얻은 몇 가지 짧은 지식을 바탕으로 난 주말이 올 때까지 계속 이미지 트레이닝에 열중했다. 그리고 드디어 기다리던 주말이 왔고, 난 친구와 친구의 자전거를 끌고 학교 운동장으로 향했다. 광할한 운동장 한 구석에서 친구 자전거 안장에 앉아 두근 거리는 마음으로 힘차게 페달을 밟았다. 그리고 난! 한번에!!! 자전거 타기에 실패했다.

     사실, 한 번에 성공하리라는 기대는 애초부터 하지 않았다. 그저 내 이미지 트레이닝이 좀 도움이 됐으면 하고 생각했을 뿐이다. 하지만 한 번도 타보지 않은 자전거에 대한 이미지 트레이닝은 별 소용이 없었다. 안장에 앉아서 페달을 밟으며, 넘어지지 않기 위해 발버둥 치며 알아가는 배움만이 자전가 타는 법을 배우는 일에 보탬이 됐을 뿐이다. 넘어지고 또 넘어지며, 넘어지지 않는 법을 배웠다.

    사실 세상을 살아가며 마주치는 소소한 일들 중에 처음 시도해서 성공하는 일은 별로 없다. 대부분 실패를 통해 배우고, 그런 배움을 통해 숙련되어 간다. 물론, 가끔은 운 좋은 성공을 거두고 기뻐하지만 운 좋은 성공을 통한 배움은 웬일인지 금방 잊혀질 때가 많다.

    소프트웨어 개발 

    런 간단한 이치가 내가 일하는 소프트웨어 개발 분야에서는 잘 통하지 않는다. 이 분야에 종사하는 많은 사람들이 완벽주의자여서 모든 걸 한번에 완벽하게 해야 직성이 풀리는 듯하다. 한 번에 완벽하게 요구사항을 내고, 완벽하게 분석하고, 완벽하게 설계하고, 마지막으로 완벽하게 구현한 후... 실패한다. 문제는 실패를 통해 배울 생각도 별로 없어 보인다는 것이다. 다시 똑같이 실패로 가는 특급열차에 올라타곤 한다.

     ! 배울 생각이 있긴 하다. 가끔, 누가 성공했다는 소문이 들리면 전문가들이 나서서 성공의 이유를 분석하고, 이를 정리해서 깔끔한 문서를 만들어 내고, 이를 다른 프로젝트에서 따라 하라고 권장한다. 하지만 이마저도 웬일인지 제대로 동작하지 않는다. 분명히 성공한 프로젝트에서 한 것처럼 똑같이 따라 했는데도 불구하고 말이다. 성공의 이면에 감춰진 원인을 보지 않고 성공한 프로젝트의 결과만을 보고 따라하기 때문이다.

    이런 류의 개발 프로세스가 갖는 가장 큰 문제는 프로세스가 성공을 잘 정리하고 기록할 수는 있어도 성공을 이끌수는 없다는 것이다. 훌륭한 개발 프로세스를 적용해서 프로젝트가 성공한 경우가 있기는 한가?

    리가 만드는 소프트웨어 시스템도 자전거 타기와 마찬가지로 지속적인 노력을 통해 개선해 나가야 한다. 한 번에 완벽한 시스템을 만드는 것은 사실상 불가능하다는 사실이 점차 인정 받고 있고, 기존의 모든 걸 한번에 완벽하게 하려는 시도의 대표 주자인 순차적인 개발 방식을 개선하기 위한 다각적인 시도들이 이루어지고 있다대표적인 방법이 XP나 스크럼, 린 개발과 같은 애자일 방법을 적용하여, 반복적이고 점진적인 개발을 통해, 변경요구에 잘 대처할 수 있는 시스템을 만들며, 리팩토링, TDD와같은 방법들을 적용하여 소프트웨어의 설계와 품질을 개선해 나가는 방식이다.

    나는 이런 개발 방법이 기존에 순차적인 개발 방식보다 훨씬 성공에 가까워 질 수 있는 방식이라고 믿고 있다. 그리고 점차 이런 방식이 일반화 될 것이다. 하지만 유념해야 할 것은 이런 방식의 외형을 보고 따라 하는 것이 아닌이런 방식의 근저에 깔려있는 가치에 대한 이해가 선행돼야 한다는 것이다.

    'PM & Agile' 카테고리의 다른 글

    정확한 일정과 정밀한 일정  (0) 2011.08.12
    소통과 신뢰의 구축  (0) 2011.08.10
    딸과의 애자일 놀이  (5) 2011.07.11
    슈퍼 개발자와 제약이론(TOC)  (1) 2011.07.08
    프로젝트 성공의 열쇠  (0) 2011.06.22
Designed by Tistory.