Book

시스템 관리자를 위한 시간관리전략 – 토머스 리먼첼리

December 23, 2015

author:

시스템 관리자를 위한 시간관리전략 – 토머스 리먼첼리

내 기억으로는 리디북스가 서비스하고 처음으로 산 책이었던 것으로 기억한다. 물론 무료책을 구입하긴했었다만…

그리고 이책은 절판되어 더이상 구하기가 어려웠던 책이라서 읽었던듯.

2년전의 책을 리디북스 독서노트에 내가 줄쳐둔 글을 보면서 정리를 한번 해볼까 하여 작성중…

그런대 줄을 많이 그어서 그런가… 새록새록 그때의 느낌이 올라온다…


 

실제로 내가 프로젝트 A를 수행하고 있는데 프로젝트 B에 대한 걱정이 된다면, 내가 할 수 있는 일은 프로젝트 B를 나으 할 일 목록에 적어둠으로써 내 머릿속에서 그 걱정을 제거하는 것이다. 그러면 난 프로젝트 A에 몰두할 수 있다. 나는 할 일 목록이 나를 대신해서 프로젝트 B를 “기억”해 주리라고 신뢰하므로, 거기에 슬데없이 정신력을 낭비하지 않아도 된다.

실제로 한번에 여러가지의 일이 들어오면 정신이 없다. 이때는 하나를 중지하고 하는것이 가장 좋은 방법중 하나이며, 그것을 진행하는데 있어서 필요한 내용들을 확인할 수 있도록 하는 것을 의미하기도 한다. 그럴때마다 Todo에 넣어두고 진행사항과 어디까지 했다는 표시를 남기는 것이 필요하다.

한 번에 여러 가지 일을 엉터리로 하는 것보다는, 차라리 한 번에 하나의 일을 제대로 처리하자. 전념하고 있는 일에 최고의 우선순위를 부여하자. 다른 작업으로 돌아가서 확인하는 것을 절대로 잊지 않도록 하려면, 할 일 목록에 그 작업들을 기록해 두자.

항상 고민인 부분. 어떻게 최고순위를 정해서 작업을 진행할 것인가…

매번 같은 방식으로 창들을 구조화하자. 여러 개의 창들을 몇 개의 가상화면에 동일한 방식으로 정돈하면, 작업할 창을 제대로 찾는 데 시간이 덜 들고 잘못된 창에 명령을 입력해 넣는 위험도 줄어들게 된다.

창들을 이용해서 괜찮은 작업 공간을 만들자. 명령(쉘) 창을 띄운다고 돈드는 것도 아닌데 아끼지 말고 활용하자.

너무 많은 창을 띄우면 그것도 문제지만, 작업하는 내용들에대해서 어느정도 확인이 가능하다면 창을 나눠 작업하는 것도 또 하나의 방법이라는…

가장 집중이 잘되는 시간. 즉, 초점을 유지하는데 노력이 최소로 드는 시간대를 알아내는 것도 집중력을 높여주는 환경을 만드는 작업의 일부다. 가장 집중이 잘 되는 시간에 정신활동을 계획할 때면 마치 “커다란 두뇌”로 탈바꿈한 기분이 든다.

언젤까 나는…

작업물을 항상 테스트하자. 어떤 사람들은 절대로 실수를 하지 않는 것처럼 보인다. 하지만 그건 우리가 보지 못해서일 뿐, 알고 보면 그 사람들은 엄청난 양의 테스트를 수행한다.

어떻게보면 많은 테스트가 필요함에도 그들은 그것이 굳이… 라는 생각을 가지고 있을 수 밖에는 없다고 본다.

무엇을 이루고 싶은가?
언제 그것을 달성하고 싶은가?

이루고 싶은것. 5년. 나는 뭘 이루고 싶은가…

좋은 시스템 관리자들은 자신이 교통사고를 당해서 회사에 못나와도 회사는 계속 잘 돌아가리라 생각한다. 교통사고를 당해보는 방법 이외에, 다치지 않고 업무 인계 계획과 시스템 문서화를 시험해 볼 수 있는 방법은 휴일 낀 주말로 휴가를 대체해보는 것이다. 휴가로 1~2주간 자신이 업무에서 손을 떼면 인계한 업무에 어떠한 격차가 생기는지를 미리 알아내야한다. 그래야 휴가를 마치고 돌아왔을때 그 격차를 바로잡을 수 있다.

내가 없어도 회사는 돌아가야한다. 그것이 회사에 해줄 수 있는 것중 하나이며, 내가 그것을 두고 떠날 수 있는 조건이된다.

시스템 관리자에게 있어 궁극적인 시간낭비 요인은 애초에 시간을 내서 그런 바쁘기만 하고 성과는 없는 업무가 발생하지 않도록 해주는 기반구조를 구축했더라면 없었을 수도 있는 작업이다. 즉, 시스템 관리자를 위한 궁극적인 시간관리 기법은 우수한 IT 기반구조다.

CI, CD 자동화된 것들을 구축하는 것에 있어서 사람들은 중요성을 못느낀다. 왜 그것을 해야되며 그것을 하는데 있어서 필요한 것이 무엇인지도 모른다. 그리고 그것을 하기위한 밑거름이 어떤것이 되어야되는지도 모른다.
무작정 CI, CD 가 좋다고 해서 따라가는 것도 문제가 있지만 어느정도 작업이 안된 상태에서 CI, CD를 진행하는 것도 좋은 방법은 아니다.

시스템 관리자들 중에는 완벽주의자가 많다. 우리는 절대로 모든 것을 문서로 기록할 수는 없다. 마무리 될 수 없는 계획을 대체 왜 시작할까? 기록을 하는 데는 시간이 걸리므로, 문서는 기록하는 도중에 이미 시대에 뒤떨어진 종이조각이 되어버린다. 문서화가 끝났을 때 쓸모가 없어질 것을 뭣 하러 기록하는걸까?

하지만 필요하다. 나중에 그것을 다시 한다고 했을때, 변화되었겠지만 그대로 구성하여 나가는 모습을 보아왔다. 그리고 그때 결정을 하였던 것을 모두 기억할 수 없기에 기록으로 남겨 어떤 결정으로 그 것을 정하였다는 것을 남길 수 있는 방법이 필요하다.

수행하는 모든 것을 기록한다면야 좋겠지만 누군들 그럴 시간이 있겠는가? 전부를 기록할 것이 아니라, 하기 싫은 절차만 문서화하자. 그 이유는, 수행 방법을 교육하는데 필요한 자료들을 만들어야 그런 하기 싫은 절차를 다른 사람에게 위임할 수 있기 때문이다.

넘기기위한 문서화라..

어떤 절차를 문서화함으로써 얻을 수 있는 이점들 중 하나는 그 절차를 기록함으로써 어떤 일을 자동화할 수 있다는 것이다. 이것은 진실이다. 난 사실 어떤 작업을 자동화할 시간이 없을 경우에는 그 작업 수행 방법을 다른 이에게 설명하면서 내 위키에 단계별로 그 절차를 기록한다. 그렇게 하면 두 마리 토끼를 잡게된다. 첫째는 시스템이 돌아가는 원리를 문서화하는데 기여하게 된다는 점이고, 둘째는 그 절차를 자동화하는 첫 단계를 실제로 수행하게 된다는 점이다.

(작업하는) 단계들을 문서로 기록하고 나서 자동화하자. 만약 그 단계들을 기록할 수 없다면 그것을 자동화하기란 불가능 할 것이다.

단계를 명령줄이나 단순한 프로그램에서 실행 가능한 것으로 변형하자. 각 단계를 개별적으로 테스트하자. 즉, 각 특정 단계를 자동화한 코드가 올바른지를 확인하는 일련의 작은 스크립트들을 작성하는 것이다.

일단 각 단계별로 코드가 제대로 작동한다면, 각 단계별 코드를 합쳐서 하나의 큰 스크립트로 만들 수 있다. 코드를 합칠 때에도 한 번에 한 단계씩 추가하는 것이 최상의 방법이다. 각 새 단계가 추가될 때마다 이를 테스트하자. 이런 방식을 점진적 개발이라고 하며, 자동화 결과를 테스트하기에 가장 좋은 방법이다. 작은 변화가 생길때마다 테스트하면, 완료했을 때 전체가 제대로 작동하리라는 것을 보다 확신하게 된다.

마지막으로 전체 과정을 테스트한다. 그 프로그램에 각 단계들이 추가될 때마다 테스트를 했다면, 사실상 지금 수행할 테스트가 거의 없다.

자동화에 대한 이야기를 작성한 것인데 많은 것을 생각하게 해준다. 자신들이 하는 일을 어떻게 자동화할 것인가… 누군가는 일을 하면서 보이는 것들을 잡아내어 하겠지만…


 

그렇게 많은 글은 아니고, 일부만 작성했다. 그 이유는 딱히 나머지는 뭐때문에 줄을 그어놨는지 기억이 안나서… 기본적인 시간계념을 어떻게 잡을 것인가에 대한 것과 내가 얼마나 많은 자동화를 하여 시간을 줄일 수 있는 방법에 대해서 많은 생각을 하게만드는 그런 책이. 이책이다.