Thoughts2009.12.07 13:34
지금까지 내가 생각하는 시간 관리의 기본 법칙에 대해 살펴보았다. 간단히 요약하면 다음과 같다.

1. 성취 목표를 뚜렷이 하라
2. 목표를 달성하기 위해 필요한 활동을 식별하라
3. 활동간 우선 순위를 정하고, 엄한 활동은 제거하라
4. 활동 간 결합 가능성을 평가하고, 결합 가능한 것은 결합하라
5. 결합한 활동을 수행하라

요약하고보니 단순해 졌지만, 실제로는 이렇게 단순하지는 않다. 성취하고자 하는 목표가 뚜렷하지 않은 사람이 의외로 많고 (그냥 먹고 살기 위해 프로그래밍 한다는 식) 목표를 달성하기 위해 어떤 일을 해야 하는지 잘 모르는 경우도 많기 때문이다.

거기다 결정적으로, 모든 사람은 환경적 요인에서 자유로울 수 없다. 우리가 일하는 환경은 우리에게 수시로 컨텍스트 스위칭을 강요한다. 스위칭이 빈번하면 할 수록, 일의 효율은 저하된다. 컨텍스트 스위칭 비용을 낮추기 위해 '결합 법칙'을 강조하긴 했지만, 그렇다고 전부를 제거할 수는 없는 노릇이다.

자. 그러면 실전에서는 대체 어떻게 해야 하나? 구보씨라는 프로그래머의 사례를 들어, 그의 인생이 '훌륭한 프로그래머가 된다'는 목적 아래에 어떻게 움직이는지를 살펴보자.

구보씨는 만 십년차의 프로그래머이다. 프로그래밍을 하다 보니, 그는 어느 새 '언어는 그저 도구일 뿐'이라는 인식을 가지게 되었다. 어떤 상황에 어떤 언어가 적합한 지는 상황에 따라 달라진다. 그는 필요한 순간에 필요한 언어를 배운다. 필요하지 않으면 굳이 새로운 언어를 배우기 위해 시간을 내지 않는다.

새로운 프로젝트가 주어지면, 그는 그 프로젝트에 맞는 최선의 언어를 고르는 일에 시간을 투자한다. 그런 작업에 드는 시간을 줄이기 위해, 그는 IEEE Software 잡지를 구독하고 있다. 어차피 직업상 많은 사람과 기술적인 내용에 대해 이야기해야 하고, 그 중에는 외국인도 있다. 영어 실력을 늘리는 것도 그가 해야 할 일 중 하나인데, 그럴 거라면 묻이 National Geographic 영문판이나 Time또는 Newsweek 영문판을 구독하는 대신 Software 분야에서 가장 저명한 잡지를 구독하는 것이 나으리라는 생각을 갖고 있다. 이 잡지에는 Software 업계에서 이름이 널리 알려진 사람들의 글이 자주 올라온다. 새로운 언어에 대한 소개도 자주 올라오므로, 그는 이 잡지를 꼼꼼히 읽으면서 가급적 언어 선정에 드는 비용을 줄이고자 한다. 국내 동향을 파악하는 것도 중요하므로, 국내 잡지도 하나 정기구독을 하고 있다. 돈이 좀 드는 일이긴 하지만, 장기적인 투자라고 생각하고 아깝게 여기지는 않는다.

잡지가 배달될 때 마다, 목차를 훑고, 읽어볼만한 기사를 체크해 둔다. 아침이나 저녁, 혹은 점심 먹은 후에 피곤함, 귀찮음, 무력감 등이 몰려올 때 마다 그는 기사들을 훑어본다. 모르는 단어가 나오면 메모해 두고, Oxford Advanced Learners' Dictionary를 참고해 예문들을 발췌해 놓는 것도 잊지 않는다. 발췌한 예문은 그 자리에서 읽어보는 경우도 있지만, 대부분은 다음에 예문을 발췌할 때 다시 한 번 읽어본다. 그것만으로도 몇 번이고 같은 예문을 읽어볼 수 있으리라는 계산이다.

프로젝트를 진행하다보면 보다 나은 프리젠테이션을 할 수는 없을까라는 고민에 빠지게 되는 일이 잦다. 그래서 아이들과 서점을 들렀다가, "SHOW"라는 제목의 책을 한 권 구입했다. 아이디어를 어떻게 하면 시각적인 표현으로 효과적으로 변환할 수 있을까 하는  것이 책의 주된 내용이다. 아이들이 플레이타임에서 시간을 보내고 아내가 장을 보는 사이, 그는 책의 전반적인 내용을 재빨리 훑어본다. 한글로 된 책이므로, 한 시간 정도 집중하면 대략적인 내용은 개괄할 수 있다. 그는 자세히 읽어봐야 할 만한 내용이 들어있는 장을 만나면 잭장을 접어 표시를 해 둔다. 나중에 읽어보기 위해서이다. (구보씨가 가장 선호하는 장소는 화장실이다.)

회의 일정이 잡히면 Outlook에 일정 알림을 걸어 두고, 회의 전에 생각해 봐야 할 내용을 메모해 둔다. 적어도 알람은 한 시간 전에는 뜨도록 해 둔다. 알람이 뜨면, 회의 때 토의될 내용에 대해 미리 아이디어를 생각해 본다. 회의 시간은 프로그래머에게는 지겨운 시간이다. 가끔은 "나중에 어차피 변경될 요구사항"에 대해서 지겨울 정도로 장황한 토의가 이어질 때도 있다. 그 시간을 최대한 줄이기 위해, 그는 미리 아이디어를 생각하고, 예상되는 질문들을 훑어본다. 그는 브레인스토밍이 반드시 생산적인 결과를 내어 놓으리라는 것을 전적으로 신뢰하지는 않는다. (이에 대해서는 "59초: 순식간에 원하는 결과를 풀어내는 결정적 행동의 비밀" 91페이지를 참조하기 바란다.) 따라서 최대한 남들보다 앞서 "생산적"이 되고자 한다.

프로그래밍 시간이 주어지면 그는 가장 열정적으로 일한다. 프로그래밍은 그가 평생을 걸쳐 수련해야 하는 어떤 것이다. 10여년 간의 경험을 통해, 그는 "제때, 그리고 올바르게 리팩터링(refactoring)되지 않은 코드는 나중에 문제를 일으키게 된다"는 결론을 얻었다. 그는 코드를 작성할 때, 언제나 세심하게 코드의 리팩터링 정도를 살핀다. 그리고 수시로 테스트 케이스를 점검하고, 커맨트를 살펴본다. 중요한 함수에 주석이 달리지 않은 것을 발견하면, 해당 함수를 작성한 사람과 상의하여 코드를 상호 검토(peer review)한다. 코드를 상호검토하는 도구를 도입하여 사용하고 있는 것은 아니지만, 주석을 만들어 나가는 과정에서 상호 검토가 자연스럽게 이루어 질 수도 있다고 생각하는 편이다.

그가 프로그래밍을 할 때에는 항상 화면에 두 개의 윈도우가 기본적으로 열린다. 하나는 코드를 편집하고 실행하고 테스트하기 위한 IDE의 화면이고, 다른 하나는 프로그램의 상세 설계서 파일이다. 코드를 편집하고 중요 설계사항이 변경되면, 그는 상세 설계서도 업데이트 한다. 상세 설계서를 업데이트하고 시퀀스 다이어그램을 갱신하는 동안 중요한 버그를 발견하는 경우가 있었기 때문에, 그는 "문서를 통한 코드 점검" 또한 중요하다는 원칙, 그리고 "문서를 제때 업데이트 하는 것"이 중요하다는 원칙을 가능한 한 지키려고 한다.

모든 업무를 마치고 퇴근하는 시간에, 그는 다음날 처리해야 할 중요한 이슈를 포스트 잇에 메모한 다음에 모니터에 붙여놓고 퇴근한다. 가장 믿는 것은 Outlook이지만, 그도 인간인지라 가끔은 Outlook에 일정을 입력하는 것을 잊거나 플래그 표시를 해 둔 메일을 무시하는 일이 생긴다. 실수를 줄이기 위해, 그는 최선을 다한다.

매일 매일 이런 나날들이 반복된다. 가끔은 지겹다는 생각도 든다. 그럴 때면, 그는 뭔가 새로운 시도가 필요한 것은 아닐까 하고 생각하고, 그간 읽었던 책 사이사이에 붙여놓은 포스트 잇 책갈피를 임의로 골라 펼쳐, 그 때 그가 왜 그 부분이 중요하다고 생각했는지를 떠올려 보려고 애쓴다.

어떤 날, 그는 코칭에 관한 책 한 권을 골라 펼쳤다. 그 곳에는 "질문의 중요성"과 "질문을 통한 능동적인 해법 발견"에 대한 밑그림이 그려져 있었다. 문득, 후배 한 명이 구현에 대한 쓸만한 해법을 두고 몇날 며칠을 고민하고 있었다는 사실이 떠올랐다. 그는 그 후배에게 질문 몇 가지를 던져보기로 결심하고, 후배에게 십분간의 커피 타임을 청한다.

[다음에 계속...]
신고
Posted by 이병준

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