전 포스팅에서 언급했듯이 스킬트리의 준비와 매크로 생성은 HP, MP 를 덜 쓰고도 원하는 바를 달성할 수 있게 해준다. 매크로 역시 시스템에 등록될 때까지 반복 실행을 해가며 익혀야 한다. 하지만 이렇게 준비된 매크로로 routine 을 만들어내도 결국 사람이 직접 실행해야 한다. 그런데, 인간이 만든 도구 중에는 한정된 몇몇 조건이 만족되면 일상의 매크로 생성 및 실행을 대신 해 줄 수 있는 것들이 있다. 이런 도구를 이용해서 routine 의 일부를 automation 으로 업그레이드 할 수 있다. 핵심은 실행까지 위임할 수 있는가 이다. 공부라던가, 글쓰기 같은 내가 해야만 하는 핵심 작업들은 안되겠지만, 결과를 생성해내는 것만으로 충분한 작업들이라면 자동화 시스템에 투척하는 것을 고려해볼 수 있다.
이를테면, 내가 매일 글을 쓰고 다른 사람이 볼 수 있게 블로그에 올리고, 페이스북/트위터 등에 링크를 투척한다고 해 보자. 그 안에는 사소하지만 손으로 하기엔 귀찮은 여러가지 동작들이 연결되어 있다.
- 문서 작성
- 리소스(이미지라던가…) 업로드
- 작성된 문서를 블로그가 운영되는 서버로 동기화
- Ipynb | markdown -> publishing format(html) 변환
- Publish to blog
- Post to facebook/twitter
BEFORE: 블로그 초창기에는 호스팅 서버에 터미널로 들어가 vim 으로 markdown 을 직접 때려넣으면서 글을 작성하고, 중간중간 fab build 를 해가며 렌더링을 확인하고, 그래프나 그림이라도 하나 넣으려면 다른데서 그려서 저장하고 호스팅할 곳에 올리고 손으로 태그를 넣어야 했고, 준비가 되면 fab pub 으로 퍼블리시한 후에 손으로 링크를 복사해서 다른 곳에 넣어야 했다. 호스팅 백업도 귀찮은 일이었다.
AFTER(NOW): 지금은 1번만 하면, 즉 python notebook 웹에서 적당히 노트북을 - 그래프, 동영상 임베딩, tikz, 코드 실행이나 기타 cell magic 등 다 쓸 수 있다 - 만들고 메타데이터에 적당한 값을 넣으면 2, 3, 4, 5, 6 은 자동으로 진행된다. 여기에 사용된 도구래봐야 별 것 없지만 이걸로 얻는 편리함은 꽤 크다. 이 삽질을 먼저 해 두지 않았다면 지금처럼 자주 포스팅을 하지 못했겠지.
- ipython notebook server in docker
- cron
- git / bitbucket
- pelican + plugins(ipynb, rss and so on)
- python coding to customize pelican and plugins
- IFTTT
이런 파이프라인에서 글쓰기 자체를 제외하고 수작업이 필요한 엔트리의 개수를 M 이라고 해 보자. 포스팅의 성가심(?)은 X 라고 하자. X는 M=0 일 때 가장 낮다(지만 0.0 보단 크겠지). 그리고 X 는 M 이 늘어나면서 함게 커진다. 어떤 스케일로 증가할까? 정확히 측정하긴 힘드니 대강의 모양만을 상상해보자. 100개의 수작업을 해야 하는데 99개가 자동화된 상태가 100개 모두다 된 상태에 비해 단지 1% 부족한 상태인가? 100 vs 99 의 차이와 99 vs 98 의 차이는 같은가? 그럴리 없다. 아마도 M=0 에서 1 로 올라갈 때부터 급격히 증가하고, 그 이후로 단위 M 에 따른 X 의 증가량은 점점 줄어들 것이다.
그래서 자동화를 하려면 빈틈없이 꼼꼼하게 하는 것이 좋다. 불완전한 자동화는 안하는 것 보다야 낫겠지만, 투입 대비 결과가 썩 좋지 않을 수 있다. 거꾸로 말하자면, 자동화 작업을 하면서 별로 나아지는 것이 없어 보이다가 어느 순간 갑자기 신세계가 펼쳐지는 순간이 온다. 갈 수 있다면 거기까지 가자.
xkcd 1205를 참조로 자동화에 들이는 시간 대비 효율 이야기가 종종 나오는데, 저 표에 있는 숫자들을 그대로 생산성에 반영하는 것은 M-X 관계가 Linear라는 틀린 가정을 하기 때문에 문제가 있다. 문맥 전환 오버헤드, 캐시 효율, 집중-몰입과 방해의 관계 등을 고려할 때 작업 외 신경써야 하는 것이 0 에 근접할수록 우리의 업무 효율은 비약적으로 높아질 수 있다.
물론 이런걸로 자동화 만능론을 내세우는 것은 아니다. 우리가 지닌 스킬과 도구를 총동원해도 자동화를 잘 하기 어려운 부류의 일들이 아직 있다. 파이프라인 중간에 그런 일들이 끼어있다면? 제거할 수 없는 수작업이 어딘가에 있다면 그 주변의 자동화 노력은 가성비가 좋지 않을 가능성이 높으니 우선순위를 낮추는 전략을 택할 수도 있다. 다만 시간이 지날수록 비교적 적은 노력을 들여서 자동화시킬 수 있는 것들이 늘어난다는 것은 확실하다. 발전이란 좋은 추상화 레이어가 쌓여가는 것이니까.
나는 IFTTT 같은 도구를 통해서 자료 정리에 쓰이는 시간을 많이 줄였다. 위에도 말했지만, 자동화 도구들은 실행 까지 담당해주기 때문에 잘 만들어 두면 머리속에 유지해야 하는 문맥의 수 자체를 줄일 수 있다. 비싼 캐시메모리를 아끼고, 전체적인 캐시히트율을 높일 수 있다는 이야기. 그 외에도 여러가지 자동화와 관련된 도구와 이를 다루는 스킬들이 있는데, 업무에 직접적으로 도움이 되지는 않더라도 활용도가 높아서 찍어두면 장기적으로 득이 될 수 있다. 주변 누구는 이런 것들을 잡기술이라고 부르기도 하는데, 잡스(Jobs)럽지만 확실히 유용하다.
결론: 복잡한 일련의 작업을 자동화 도구에 위임할 수 있다면 그렇게 하자. 전체 자동화가 힘들다면 작은 작업들로 분해하고 각각을 공략해서 routine 에 하나씩 끼워 넣어보자.
Comments