'속도'에 해당되는 글 2건

  1. 2013.06.14 속도의 차이
  2. 2013.05.27 속도와 방향

속도의 차이

Gos&Op 2013.06.14 09:08 |
Share           Pin It

어제는 늦은 시간까지 잠이 오지 않아서 고생했습니다. 그래서 준비중인 서비스를 위한 분석프로그램에 새로운 기능도 추가하느라 미명이 밝을 때까지 또 잠들지 못했습니다. 그래서 지금 피곤하고 몽롱한 상태입니다. 잠이 오지 않으면 많은 생각이 떠오릅니다. 프로젝트나 논문과 관련된 것일 때도 있고 (보통 이럴 때는 빨리 구현해서 결과를 얻고 싶어져서 점점더 정신이 또렷해져서 잠을 들 수가 없습니다. 어제도 그랬습니다.), 주변에서 일어나는 사건들이나 인물들을 곱씹어보기도 하고, 지난 추억이 떠오르기도 하고,... 많은 생각들이 잠들기 전에 스쳐갑니다. 개인적으로 잠들기 전이 가장 창의적인 시간입니다.

어제는 프로젝트에 대한 아이디어도 떠올랐지만 지난 그리고 최근의 몇 가지 일들이 떠올랐습니다. 좋았던 기억보다는 조금 힘겹고 씁쓸한 기억입니다. 모든 씁쓸한 기억에서 51%는 제 잘못이고, 49%는 누구의 잘못인지 알 수 없습니다. 지난 기억들을 복기해보니 공통점이 발견되었습니다. 바로 나와 주변과의 속도의 차이가 공통적으로 존재했습니다. 보통 소통의 부재나 진의의 여부를 표면적으로 내세우는 경우가 많지만, 제 경우에는 속도의 문제였습니다. 한명은 빠르고 다른 이는 느리기 때문에 발생하는 문제입니다. 이인삼각과 같이 같은 곳을 향해서 둘이 합심해서 같은 속도로 달려야되는데, 보통의 경우 저는 빠르게 치고 나가려고 하고 주변에는 아직 준비가 덜 된 상태였습니다. 물론 그 반대도 존재할 것입니다. 그러나 자기 방어를 위해서는 저는 빨랐는데, 주변이 제 속도를 맞춰주지 못했다고 핑계를 대기 위해서 제가 일방적으로 빨랐던 기억만, 그래서 결국 제가 잘못했던 기억만 떠오릅니다.

연초에도 인식의 차이가 아니라 속도의 차이였다는 글을 적었습니다. 그 글의 이면에 있었던 사건, 아니 일방적인 저의 삐침이 그랬습니다. 더 오래 전에 프로젝트를 하면서 기획자분과 트러블이 발생했던 적도 그랬습니다. 비슷한 시기에 기획자도 바뀌고 분석가도 바뀐 상황이었는데, 저는 이만치 앞서 나가 있으면서 아직 기획자가 준비가 덜 된 상황을 이해하지 못했던 사건이 있었습니다. 최근에도 흥미와 의욕이 꺾이는 일이 있었습니다. 카운트파트도 나름의 사정이 있었지만 기획이 빨리 확정되지도 않고 개발자도 중간에 변경되면서 종합적인 피드백을 제때 받지 못하고 서비스 리드타임만 길어졌습니다. 그러는 사이에 관심과 의욕이 식는 지경에 이르렀습니다. 나름 복잡한 프로그램을 한 번 구현해서 방치해두면, 몇 달 후에 피드백이 왔을 때 해당 프로그램에 대한 기억을 잃어버려 제때 대응을 해주지 못하는 경우가 많습니다.

제가 뜨거울 때 상대는 아직 시작도 하지 않았다면, 나중에 상대가 뜨거워졌을 때는 저는 이미 식어버린 후입니다. 그렇게 속도의 차이로 인해서 눈에 띄지 않는 많은 비용이 발생합니다. 그리고 제가 주변과 겪었던 많은 트러블들이 그런 속도차에서 오는 것이 많다는 것도 어제의 결론입니다. 조금 더 신중히 한 템포 느리게 움직여도 되는데 뭐가 그리 급하다고 그렇게 날뛰는지 모르겠습니다. 천천히 더 생각해서 견고한 알고리즘을 만든 후에 적용해봐도 되는데, 뭐가 그리 급하다고 (장애 상황도 아닌데) 주말에 사무실에 나와서 프로그램을 수정하고 있는지, 그리고 새벽 늦게까지 새로운 코드를 작성하고 있는지 제가 생각해서 참 피곤합니다. 그런데 저는 그렇게 바쁘게 움직이고 해야할 일이 있을 때 행복을 느끼는 것같습니다. 최근의 일도 제가 집중할 다른 일이 있었더라면 어땠을까?라는 아쉬움이 남습니다. 결국은 내 속도를 내가 조정해야 하는데...

그래도 빨리 가서 기다리는 게 낫지, 늦게 가서 민폐 끼치며 살지는 않으렵니다.

(2013.06.04 작성 / 2013.06.14 공개)

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

속도와 방향

Gos&Op 2013.05.27 09:43 |
Share           Pin It

간혹 TV강연이나 블로그 등에 좋은 글이라고 소개된 것들을 보면 성공하기 위해서는 속도보다는 방향이 더 중요하다고 말한다. 목표한 바가 확고하다면 믿고 느리더라도 묵묵히 가라는 메시지다. 틀린 말은 아니다. 그러나 속도보다 방향이 중요하다고 말하는 것은 그저 이미 성공했던 사람들의 자기 방어에 불과하다. 요즘과 같은 불확실한 시대에는 방향보다 속도가 더 중요하다. 특수한 경우가 아닌 이상은 올바른 방향을 처음부터 알 수가 없다. 재벌가의 자녀로 태어나거나 어릴 적부터 악기나 운동에 천재적인 재능을 보이지 않는 이상 사람이 성공하는 방향을 절대 알 수가 없다. 어느 게 맞는 방향인지 알 수 없는 상황에서 방향이 중요하다고 말하는 것은 공허한 울림에 불과하다.

방향을 알 수 없기 때문에 속도가 중요하다. 느림의 미학도 존재하고 완급의 묘미도 있지만, 일반적으로 빠를수록 좋다. 처음부터 올바른 방향을 잡았다면 빠르면 빠를수록 빨리 목표지점에 도착할 수 있고, 방향을 잘못 잡았다면 빠르면 빨리 방향이 잘못되었다는 것을 파악하고 방향을 바로 수정할 수가 있다. 그런데 방향이 중요하니 그곳을 향해서 느리더라도 지치지 말고 나아가라라고 말한다면 그 방향이 맞을 때는 괜찮지만, 만약 방향이 조금이라도 잘못 되었다면 온갖 수고를 다 하고 나서 결국 잘못된 곳에 도착할 수 밖에 없다. 그리고 방향이 맞더라도 속도가 느리면 의미가 퇴색되는 경우가 많다. 올림픽 100m 달리기에서 메달을 따지 못한 선수들은 방향이 틀려서가 아니라 속도가 느려서이다. 목표를 완성하기 위해서 방향이 시작이라면 속도는 끝이다. 시작이 반이다라는 말이 의미가 있지만, 끝이 없으면 시작의 반은 헛수고에 불과하다.

서비스나 제품의 개발 방법론도 방향과 속도에 대비해서 생각해볼 수 있다. 기획 중심의 개발은 방향을 중시하는 방법론이고, 실행 중심의 개발은 속도를 중시하는 방법론이다. 이전 글들에서도 밝혔지만, 개인적으론 (일반적으론) 실행 중심의 개발 방법론이 맞는 것같다. 적은 초기 리소스를 들여서 실험하고 검증해보고 더 큰 리소스를 들려 완성하면 된다. 초기 실패가 전체 실패로 이어지지 않는다. 그러나 잘못된 기획은 자칫 많은 리소스만 허비하고 결국 전체 실패로 귀결될 수가 있다. 물론 잡스와 같이 천재적 기획자가 있다면 얘기는 달라진다. 스스로 나는 또는 우리 팀은 천재적인가?를 자문하고, 조금이라도 의심이 든다면 개발, 속도 중심의 접근법을 택할 것을 권한다.

빨리 실패하고 작게 실패하고 많이 실패하는 것이 성공의 밑걸음이 된다. 단, 실패에 익숙해지면 안 된다.

(2013.05.24 작성 / 2013.05.27 공개)

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요