'생산성'에 해당되는 글 3건

연구에 대한 실험 코드를 고쳐 가며 새로 데이터를 뽑고, 또 문제가 있거나 개선할 부분이 보이면 다시 고치기를 반복하고 있다. 이 과정에서 내가 개인적으로 유난히 시간을 많이 소비하는 단계가 있음을 알게 되었는데, 바로 어떤 설계(design)으로 개선해서 목적을 달성할 것인지 결정하는 단계이다.

예를 들어, 라우팅 프로토콜을 고치는 과정에서, source node가 자신이 트래픽을 보내기 위해서 먼저 경로를 탐색(route discovery)하고 선택해야 하는데, 이러한 과정을 자주 하게 되면 그만큼 네트워크 전체에 부정적인 영향을 끼치게 된다. 이러한 route discovery 자체를 줄이기 위해서 먼저 실제로 route discovery를 몇 번씩 했는지 파악을 할 필요가 생겼다. 이것을 어떻게 기록할 것인지 생각을 해 보았는데,

1. 그냥 각 source node의 ID로 된 텍스트 파일을 만들고, 매 초마다 route discovery를 몇 번 했는지 숫자를 텍스트 파일에 시간 순서대로 한 줄씩 기록하는 방법
2. Route discovery 전체를 기록하는 텍스트 파일 한 개를 만들고, 모든 source node가 같은 파일 포인터에 접근해서 시간, 노드ID, route discovery를 수행했다는 flag를 한 줄로 기록하는 방법

위의 두 가지 외에도 다양한 방법들로 기록할 수 있어 보였다.

그런데 나중에 통계를 내고 엑셀 파일 같은 곳에 가져다 쓸 것까지 생각을 해 봤을 때 어느 방법이 가장 좋은지 쉽게 판단이 잘 안 되는 것이었다. 이게 깔끔하게 마음 편한 방법으로 잘 정리가 되지 않자, 이것 때문에 하루 종일 다른 작업을 못하고 그냥 고민만 하고 딴짓만 하다가 시간을 보내고 말았다.

사실은 내가 연구 측면에서 정의한 문제를 해결하는 방법이 아니고, 라우팅프로토콜의 성능을 측정하는 데 필요한 작은 통계 생성 방법일 뿐이고 어떤 설계를 따르던지 어차피 시뮬레이션 성능에 큰 영향을 주지는 않기 때문에 무시하고 한 가지를 얼른 정해서 진행을 해도 되는 것이었는데, 어느 한 가지를 고르는 것이 속 시원하지 못하다는 이유로 연구 전체를 진행하지 못하고 마치 트랩에 걸리듯이 꼼짝하지 못했다.

결국 지금 밤이 되어서 그냥 첫 번째 방법으로 진행해서 얼른 경로 탐색에 대한 기록부터 만들어내고, 그렇게 각 source node별로 만들어진 기록을 합산하는 스크립트를 파이썬으로 빨리 만들어서 붙이기로 했다. 사실 이미 각 노드마다 flow 트래픽 사용량에 대한 통계를 똑같은 방식으로 만들어 내고 똑같이 파이썬 코드로 후처리(post-processing)를 하고 있었기 때문에 기존의 코드를 재활용해서 가장 적은 시간을 들여서 통계를 만들어낼 수 있는 것이기도 했다. (지저분하게 파일 개수가 많아지는 것, ns-3 코드 상에서 파일 포인터가 많아지는 것 외에는 그 어떤 문제도 없기도 하고...)

나는 지나치게 조심스러운 것이 단점이므로, 그냥 가급적이면 조금 더 빨리 결정한 다음, 뒤도 돌아보지 말고 밀어붙인 뒤에 나중에 문제가 터지면 그것을 그 시점에서 재빨리 고쳐 나가서 목적부터 달성하기 위해 노력해야겠다.

그러므로 내일 일을 걱정하지 말아라. 내일 일은 내일 걱정할 것이오. 한 날의 괴로움은 그 날의 것으로 충분하다 (마태복음 6:34)

대학원생, 특히 이공계 대학원생에게 연구노트는 정말 중요하다. 연구노트를 그 목적대로 작성을 했을 경우, 연구의 진행 상황에 대한 기록이 모두 되어 있기 때문에 이를 기반으로 매일매일 연구를 올바른 방향으로 진전시켜 나갈 수 있다. 그리고, 실험 같은 것이 실패를 하더라도 그 기록이 모두 남으니까 어떤 형태로든 자산이 될 수 있다.

거의 대부분은 종이로 된 연구노트 책자를 쓰겠지만, 하고 있는 모든 일을 오직 PC 화면만 쳐다보면서 하는 입장에서 전자연구노트도 쓸만하다. 하지만 학교에서 제공하는 전자연구노트는 파일을 직접 업로드하는 방식이라서 내가 다른 프로그램 (워드, 엑셀, 파워포인트, 아니면 그냥 메모장, 또는 이미지 등)을 사용해서 일단 만들어야 한다.

연구를 진행하는 과정에서 실험 통계는 엑셀 파일, 랩세미나 발표를 하거나 교수님과의 의견 교환을 위해서 만든 슬라이드는 파워포인트 파일, 문서는 워드를 쓰는 것이 일반적이긴 하다.

그런데 요즘 들어서는 내가 점점 MS 오피스 프로그램을 써서 직접 파일을 만드는 경우는 줄어들고, 그냥 웹 브라우저에서 구글 드라이브에 접속해서 문서/스프레드시트/프레젠테이션을 바로 만드는 경우가 많아졌다. 워드/엑셀/파워포인트만 가지고 논문 한 편을 만드는 것이 일반적이던 시절이 있었지만, 최근에는 이게 옛날처럼 느껴질 정도로 많은 작업을 웹 기반으로 하게 되었다.

무엇보다도, 평소에 각종 개발이나 실험을 리눅스 환경에서만 하다 보니 그냥 아예 main PC를 리눅스로 쓰다 보니, 윈도우에 대한 접근성이 조금 떨어져서 더더욱 MS 오피스를 쓰지 않게 된 측면도 있다.

논문 작성은 Overleaf를 써서 tex를 웹 상에서 직접 고치고, 공동저자들에게 링크를 줘서 바로 확인하거나 서로 동시에 고치면 된다. 예전에는 tex를 쓰려면 프로그램을 별도로 써야 했지만, 웹 기반으로 하면서 훨씬 편해졌다. 게다가 MS 워드를 가지고 논문을 작성하면 예기치 않게 문서 레이아웃이 망가지거나 그림이 서로 겹치는 등 온갖 불편한 일이 생기는 데 비해, tex는 문법만 잘 알고 있으면 문서 레이아웃 망가질 걱정은 전혀 할 필요가 없으니 훨씬 좋다.

기본 아이디어에 대한 brainstorming 같은 일도 구글 문서나 구글 프레젠테이션에서 간단하게 만들어서 이것을 또한 링크로 공유해서 수정하면 된다. 이 단계에서는 MS 오피스가 제공하는 강력한 기능들까지 굳이 필요하지도 않고, 흰 바탕에 꾸밀 필요가 없는 검정색 텍스트와 간단한 도형 그림 정도로 일을 할 수 있기 때문이다. 다만 구글 스프레드시트는 아직까지는 MS 엑셀에 비해 기능과 편의성이 많이 부족해서 이 부분은 아쉽다.

그리고 기존에 PC에서 MS 오피스를 써서 작업할 때에는 항상 예상치 못한 PC의 다운이나 하드디스크 고장으로 인해 파일이 망가지고 사라지는 등의 위험 요소를 안고 가야 했는데, 요즘은 웹 기반으로 하다 보니 그런 걱정이 거의 사라졌다.

물론 순수하게 개인 PC에서만 모든 작업을 다 하던 시절과 지금의 완전한 웹 기반 환경 사이에 드롭박스(dropbox)를 활용해서 과거 저장 내역을 기억하고 만약의 사태에 파일을 복구하던 시절도 있었다. 그리고 dropbox는 여러 학생들이 참여하는 연구과제에서 만들어지는 수많은 문서들을 관리하는 측면에서는 지금도 도움이 많이 되고 있다. 특히나 우리나라에서 결코 없어지지 않을 hwp 파일들을 관리하려면 뭐.. 다른 방법이 없으니까. hwp 파일만큼은 아직도 구글문서처럼 웹 기반으로 협업이 불가능하니 어쩔 수 없다.

하지만 적어도 나 혼자 또는 나와 지도교수, 공동저자 학생 한두 명이 같이 연구를 진행하면서 논문을 쓰는 상황에서는 굳이 dropbox도 별 필요가 없다. 그리고 실험이나 시뮬레이션을 하다 보면 결국 윈도우보다는 리눅스/맥이 더 편할 수밖에 없고, 윈도우 PC보다 리눅스/맥을 더 자주 활용하는 입장에서 구글 드라이브의 접근성이 MS 오피스에 비하면 훨씬 좋기도 하다.

------------------------------------

아무튼 위와 같은 여러 가지 이유를 종합해서, 서면연구노트는 거의 쓰지 않고, 전자연구노트는 연구과제를 진행하는 과정에서 정기적으로 만들어지는 회의록, 발표자료, 보고서 파일들을 업로드하는 요도로만 사용하게 되었다.

그런데 이렇게 전자연구노트를 개인연구에 잘 쓰지 않다 보니까 내 개인연구의 모든 과정을 자세하게 기록하고, 이를 기반으로 연구를 차분하게 진행시켜 나가기 위한 기록 매체가 마땅치 않게 되었다.

순수하게 내 개인연구 진행 상황을 매일매일 잘 기록하고, 이를 기반으로 중간에 다른 일을 하다가 돌아오거나, 그 다음날에 다시 시작하더라도 기억을 더듬는 시간을 최소화시킬 만한 환경이 필요했다. 사실 이런 목적을 충족해 주는 도구는 이미 널리고 널렸지만, 왠지 모르게 내 손에 잘 잡히지 않는 것이 문제였다.

이 분야에서 단연 에버노트가 막강하겠지만 이상하게 손이 잘 가지 않았다. 논문들을 잘 관리하는 측면에서는 멘델레이(Mendeley)가 좋은 도구가 되겠지만 논문 이외의 문서들 관리하기는 힘들다. 트렐로(tello)는 내가 무엇을 해야 하는지 task를 분류하고 todo list를 관리하기에 좋아 보였지만, 여기에 코딩하면서 발생한 버그, 해결 방법, 논문 아이디어, 시뮬레이션 환경 등등 이것저것 다 기록하다 보니 오히려 너무 기록할 수 있는 영역이 많아서(카드의 제목, 카드의 description, 카드 내부의 댓글, 카드에 추가할 수 있는 checklist, 거기에 카드 종류를 구분할 수 있는 custom label 등등...) 나만의 기준을 일일이 만들지 않으면 너무 중구난방으로 기록되는 바람에 나중에 오히려 찾아보기가 불편한 지경이 되었다. 게다가 일처리를 끝내면 보관(archive) 처리를 해서 사라지게 되는데, 그렇게 화면에서 완전히 사라져야 할 때도 있지만 어떨 때는 남아 있기도 해야 하고, 그렇게 카드 수와 카테고리가 점점 늘어나기 시작하자 오히려 관리하기 어려웠다. 트렐로가 이 모양이니 이와 유사한 Todo 관련 앱들 모두가 마찬가지였다.

슬랙(slack)은 공동저자들과 협업을 하면서 발생한 대화 내용과 모든 파일이 다 시간순으로 기록으로 남아 있고 검색해서 찾아보기도 편했지만, 메신저의 대화창 자체를 기록을 저장하는 수단으로 쓰는 것은 너무 무리였다. (게다가 대화 개수가 10,000개를 넘어가면 그보다 과거의 내용은 돈을 내지 않으면 볼 수도 없다.)

위의 여러 가지 서비스들을 다 시도해 보는 과정에서, 모두 어느 정도 써 보다가 다 중단되었지만, 그러한 시도를 하는 동안에 병행해서 계속 기록을 남기던 가장 원초적인 수단은 결국 메모장(...)이었다.

그 어떤 서식도 넣을 수 없었지만, 그 안에서 내가 나만의 indent를 가지고 위에서 아래로 순서대로 기록을 남기고, 파일 이름은 날짜와 가장 중요한 내용으로 하고 (예: 180117_routing_table_update_issue.txt), 그 파일들을 dropbox 폴더에 모아 놓는 이 원시적인 작업만을 내가 멈추지 않고 해 오고 있었다. 어쩌면 나는 강력한 도구보다는 불필요한 것이나 군더더기가 없으면서 접근성이 좋은, 미니멀리즘 비슷한 것을 원했던 것일까?

결국 위와 같은 고민을 거쳐서 지금은 구글 드라이브에 폴더 하나를 통째로 모든 공동연구자들과 공유하고, 그 아래에 워드 문서를 큼지막한 이슈 별로 만들고, 그 문서 안에서 매일매일의 날짜마다 새 페이지를 만들어서 그날 겪은 문제와 그 전날의 문제를 해결한 내역, 앞으로 할 일 등을 그저 텍스트로 작성하고, 해결이 안된 부분은 빨간 글씨, 해결 완료한 부분은 파란 글씨로 표시하는 최소한의 서식만 남겨 둔 채 사용을 해 보았더니, 현재로써는 이게 가장 생산성이 좋다.

사실 '서투른 목수가 연장 탓'을 한다는 속담도 떠오르고, 연구가 정말 절실하거나 교수님께서 나를 더 많이 쪼시거나(...) 하시면 도구 따위가 문제가 될 수 없겠지만... 그래도 기왕이면 내가 쓰기 편하고, 내 손에 잘 익으면 그만큼 마음의 거리낌이 줄어드는 만큼 연구에 집중할 수도 있는 것이 아닐까? 게다가 최근 5일 동안은 위와 같은 시도의 끝에 정착한 구글 드라이브와 최소한의 서식이 꽤 좋은 생산성을 실제로 보여주고 있기도 하니까.

좀더 일찍 이런 손에 잘 익는 도구에 대한 고민을 했었으면 어땠을까 싶지만... 뭐 지금이라도 늦지 않았다고 생각한다. 남은 시간 동안 열심히 달려 보자.

부끄러운 사실이지만, 최근 들어서야 코딩할 때 파이썬(python)을 쓰기 시작했다.

말이 최근이지 불과 이틀 전이다. ㅡㅡ;;

애초에 네트워크 시뮬레이션 특성상 핵심 구현은 C/C++을 쓸 수밖에 없고, 똑같은 것을 실제 장비에서 실험을 해보려면 리눅스 디바이스 드라이버를 고쳐야 해서 결국 C를 써야 한다. 전에 연구실에서 IoT 테스트베드 구현에 깊게 참여하던 당시에는 IoT 미들웨어가 순수 Java로만 되어 있었고, 과제 연차평가를 보여줄 시연용 모바일 기기도 안드로이드여서 Java 기반이니 지금껏 Java와 C/C++만 줄기차게 써온 셈이다.

물론 스크립트 언어를 안 쓴 것은 아닌데, 그게 리눅스 쉘(shell) 스크립트와 awk였다. QualNet이나 ns-3가 만들어 내는 수많은 반복 시뮬레이션을 batch로 실행하고, 실행 후에 만들어지는 여러 개의 데이터 텍스트 파일들을 정리해서 엑셀이나 Gnuplot에 붙이기 좋게 만들 필요가 있었다. 

문제는 shell (bash)이든 awk든 스크립트 언어라서 바로바로 돌려볼 수 있기는 한데, 왠지 코드가 쉽게 써지지 않는 것은 단지 나의 기분탓이었을까? (...)

사실 bash나 awk 모두 잘(?) 쓰면 아주 강력한 스크립트 언어인 것은 분명하지만, 이상하게 빨리 익숙해지는 느낌은 잘 들지 않았다. 내가 집중적으로 실험할 때에만 폭풍처럼 몰아쳐서 스크립트를 만들다가 또 한참 안쓰고 잊어버려서 그런 것일지도? 아무튼 awk로 내가 머릿속에서 상상하는 것처럼 텍스트를 예쁜 과일 자르듯 쉽게 파싱하려면 상당한 시간의 구글링과 trial-and-error를 거쳐야만 했다.

최근에도 bash와 awk의 조합으로 ns-3 시뮬레이션을 대량으로 돌리고, 그 결과로 생성되는 텍스트 파일 중에서 몇몇 지정된 노드 번호에 대해서만 로그 데이터를 읽어들여서 파싱하는 작업을 했는데, 최근에 요구사항이 추가돼서 결과 데이터를 한번 더 가공해야 하는 상황이 되었다.

이미 만들어 놓은 awk 코드를 또 고치려니 선뜻 손이 가지 않아서, 차라리 파이썬으로 해 봐야겠다는 생각이 들어서 그냥 파이썬의 파일 입출력 예제 코드와 string 포맷팅 등의 기초적인 정보를 구글링해서 만들어 보았다.

그랬더니,

...15분 만에 결과 데이터가 내가 원하는 형태로 터미널 화면에 뙇.

Aㅏ...

기존의 awk와 shell 스크립트를 뜯어고치면 절대 완성하지 못할 시간인데...

그리고 다른 데이터에 대한 유사한 후처리 작업을 ns-3 시뮬레이션 상에서 C++ 함수로 구현해 둔 것도 있는데, 그 당시에 구현하던 때에도 30분 넘게 걸렸었는데 파이썬은 문법을 구글링하고 vi에서 생으로 코드를 짰는데도 15분이라니.

게다가 그동안 자바로 코딩했던 경험상, 똑같은 기능을 자바로 구현하면 100줄은 쉽게 넘어갈 코드가 파이썬에서 주석과 디버그용 print문 합쳐서 45라인...

...난 지금까지 뭘 한거지? ㅋㅋㅋㅋㅋ

예전에 오버레이 네트워크 상에서 돌리는 라우팅 프로토콜을 만들어야 된다고 징징거릴 때, 주변에서 파이썬으로 먼저 만들어 보는 건 어떠냐는 제안에도 파이썬을 써본 적이 전혀 없어서 익숙한 Java로 하겠다고 그랬는데...

테스트용 웹서버 구축할 때에도 Spring Boot 상에서 자바로 노동(?)을 하고 있을 때에도 옆에서 아는 형이 Django로 파이썬으로 만들면 더 빠르다고 했을 때에도 선뜻 바꿀 생각을 못했는데... @_@ (정신 가출)

다양한 프로그래밍 언어로 문자열 처리 어플리케이션 개발 시 소요되는 시간 비교(Prechelt and Garret) (출처: HACKERNOON [1])

위의 그래프가 충분히 이해가 가는 순간이다.

게다가 내가 목표로 하는 개발환경은 실행속도 따위(...) 그다지 의미가 없고, 코드만 빨리 완성되면 가상 머신 여러 개 만들어서 밤에 자는 동안 batch로 잔뜩 돌려놓기만 하면 되니까... 진작에 파이썬을 여기저기 적용해서 쓸 걸 ㅠㅠ

게다가 파이썬을 단 한번도 써본 적 없다고 괜히 겁먹은 거잖아?!

기존에 다른 프로그래밍 언어들을 장시간 다뤄본 사람 입장에서 파이썬은 배울 필요 없이 그냥 일단 쓰고 보면 되는 거였다. ㅡㅡ;;

물론 텍스트를 잘 파싱/편집/재구성하는 가장 강력한 도구로써 awk를 쓰는 것이 여전히 더 유리한 상황은 있을 것이다. 하지만 비교적 단순한 스트링 파싱은 그냥 파이썬에서 직관적인 코드를 써서 훨씬 더 빨리 만들어낼 수 있음을 이번에 경험으로 알게 되었다.

앞으로는 C++ 시뮬레이션 코드를 bash로 반복 실행을 하고, awk로 여기저기 흩어진 데이터를 한데 모으는 것까지만 하고, 그 뒤의 스트링 파싱이나 평균 계산 등은 다 파이썬으로 하면 될 것 같다.

생산성이 좋다고 주변에서 일관되게 얘기하면 그러한 줄 알고 신속하게 적용할 수 있는 사고방식의 중요성을 느낀다. ㅠㅠ

외곬수가 되지 말자...

<참고자료>

[1] Nick Humrich, "Yes, Python is Slow, and I Don’t Care," HACKERNOON,

https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1