'시간관리'에 해당되는 글 2건

  1. 2006.12.20 시계부가 꽤 쌓였네요 (2)
  2. 2006.11.20 관측이 현상을 교란한다 (2)

시계부가 꽤 쌓였네요

오늘 시계부 적은 것을 세어보니 벌써 열 여섯장이 되었네요. 스무장을 채워서 한 번 정리를 해볼까 싶습니다. 그래프를 그려보면 뭔가 경향이 보일까요? 궁금하고 기대됩니다. :]

SeeAlso, 관측이 현상을 교란한다

신고
Trackback 0 Comment 2

관측이 현상을 교란한다

제 직장에는 꽤 큰 카페가 있습니다. 생과일 주스를 제외하면 모든 음료가 오백원이고, 천오백원짜리 아침 샌드위치 세트를 사러 가면 줄을 서고 있는 이사님들을 만나며, 항시 근무중인 직원들만 해도 서너 명은 될 만큼 카페 사용이 일상적입니다. 간단한 회의는 카페에서 하기도 하고 외부 손님이 왔을 때도 카페로 직행합니다. 하루 중 세 번 있는 집중 근무 시간을 제외하면 카페는 사람들로 가득합니다. 하루에 한 번쯤 카페에 죽치고 앉아서 노닥거리는 것도 일상적인 일이죠.

저는 회의를 좋아합니다. 회의라면 치를 떠는 사람들도 있고, 일반적으로 프로그래머는 회의를 싫어한다고 알려져 있기는 하지만요. (일반적인 프로그래머라는게 뭔지 도대체 모르겠지만, 스콧 버쿤쯤 되는 사람도 일반적인 프로그래머에 대해 TAPM에서 이렇게 말했죠? '프로그래머는 컴파일 안 되는 무언가를 작성하는 일에는 별로 관심을 기울이지 않기 때문입니다' - p. 195) 직접 회의를 요청하는 경우는 아직 별로 없지만, 일단 회의를 시작하면 즐거워서, 내가 회의를 자꾸 길게 만드는 것이 아닌가 하는 생각마저 들 정도입니다.

그런데 말입니다,

어느날 카페를 다녀오고, 정기적이거나 비정기적인 회의를 하고, 통로에 서서 몇몇 사람들과 의논을 하고, 자리를 돌아다니며 svn 클라이언트(TortoiseSVN)를 손봐주고, 그리고 보금자리에 돌아와서 코딩을 하는데 문득 내가 하루에 몇 시간이나 코딩을 하는가 하는 의문이 들었습니다. 물론 코딩만이 개발자의 유일한 소명은 아닙니다. 회의하는 것이나 안건을 놓고 잠시 잠깐 의논을 하는 것도 엉뚱한 프로그램을 짜지 않도록 하기 위해 하는 일이라고 할 수 있습니다.

공정을 개선하고, 언제나 가장 적절하고 유용한 도구를 사용하는지 팀을 지켜보고, 팀원들의 문제를 해결하려고 노력하는 것은 '프로그래머이냐'를 떠나서 모든 개발자가 신경써야 할 일이죠. 적절한 휴식을 취하는 것도 정말 중요한 일입니다. 하루에 몇 십분쯤 카페에서 휴식을 취하고 나머지 시간을 유용하게 쓸 수 있다면, 또는 거기에서 건설적인 이야기를 나눌 수 있다면 한 시간도 아깝지 않습니다.

그런데 말입니다, 그 모든 일이 하루에 일어난다면 어떨까요? 온갖 부업무 때문에 주업무 시간이 두 시간이 채 안 된다면 어떨까요? 나머지 시간을 기운 내서 일하기 위해 카페에 다녀왔는데, 그 나머지 시간이 전혀 남아있지 않다면 어떨까요? 내가 시간을 어떻게 쓰고 있는지 전혀 알 수 없다면 어떨까요?

시계부

최근 인생통계를 작성하는데 재미를 들이고 있습니다. 그 일환으로 가계부, 기상 시각, 이상 신호 로그(입안 염증이나 코피)를 적은 데 이어 이제는 시계부를 작성하기 시작했습니다. 기상 시각과 시계부 모두 제용님의 위키에서 구조를 가져온 것입니다. (기상 시각에서 사용하고 있는 그래프도 제용님의 사이트에서 얻었음)

원래 이 시계부의 목적은 하루에 어떤 일을 얼만큼 하고 있는지를 파악하는 것이지만 저는 인터럽트 로그의 형태로 적었습니다. 어차피 현재 하루 일과의 대부분을 업무에 사용하고 있는데다 그 정도면 충분하다고 생각했거든요. 시계부를 그리기 위해 세 가지 형광펜을 사용했습니다. 연두색은 인터럽트가 없었던 시간을 그었고, 주황색과 녹색은 인터럽트가 연속해서 나타날 경우 그 각각을 구분하기 위해 사용했습니다. 화장실 - 전화통화 - 회의, 이런 식이죠. 스캔을 했더니 색깔이 잘 보이지 않아서 그 위에 덧칠했습니다. 그림을 보시죠.




그러나 관측이 현상을 교란한다

하이젠베르크의 이론 중에 불확정성 원리라는 것이 있습니다. 관찰이라는 행위 자체가 대상물을 교란시키기 때문에 정확도에 한계가 있다는 것입니다. 비슷한 것으로 업계에는 하이젠버그가 있지요. 문제를 해결하려는 디버깅 행위 자체가 대상에 영향을 미치기 때문에 다시 문제가 나타나지 않는다는 것입니다. (때문에 잘 지은 이름이죠.) 네트워크 프로그래밍에서는 하이젠버그가 종종 일어나기 때문에 디버거 대신 printf를 많이 사용하기도 합니다.

처음에 이 시계부를 작성하기 시작한 것은 업무 중 웹 서핑이나 휴식, 업무 지원 등으로 인터럽트가 걸리는 패턴을 분석하려고 시작해서 긍정적인 피드백을 얻으려는 시도였습니다. 그러나 그 즉시 관측이 현상을 교란하기 시작했습니다. 그러니까 풀어서 이야기 하자면, 업무 중 딴짓을 하거나 카페에 가 있는 시간 등을 잡아내려는 의도로 관측을 시작했지만, 실험 대상(나)이 관측 사실을 필연적으로 알게 되기 때문에 현상이 왜곡된 것입다. 결론적으로 딴짓이 줄어들었다는 이야기입니다. 최초 목표는 이루지 못하고 있지만 긍정적인 변화가 있어서 시계부 작성을 계속 하기로 했습니다.

신고
Trackback 0 Comment 2

prev 1 next


티스토리 툴바