이번에 준비하고 있던 논문은 "nShader"라는 이름으로 기존의 PacketShader와 SSL Shader를 포함하여 임의의 새로운 네트워크 패킷 처리 기능을 하나의 소프트웨어 프레임워크 위에서 구현할 수 있도록 만드는 것이다. 단순히 프레임워크만 만드는 것이 아니라 scheduler를 바꿔가며 구현할 수 있도록 하고, 나름대로의 새로운 아이디어를 적용한 scheduler로 기존 shader 시리즈보다 성능을 더 향상시키는 것이 골자이다.

오늘 낮 12시가 NSDI 학회 데드라인이었는데, 결국 이건 아직 낼 때가 안 되었다는 결론을 내고 다음에 다른 학회에 내기로 했다. 지금까지의 과정에서 몇 가지 느낀 점들을 적어본다.

꼼꼼한 기록의 중요성

시스템 연구는 특성상 삽질을 많이 하게 된다. 아무리 경험이 많은 사람이라도, 모든 것을 처음 밑바닥부터 다 구현하는 것이 아닌데다, 아무래도 좀더 low-level을 만지다보니 일반적인 user-level application과 달리 어떤 기능의 정확한 동작과 성능에 영향을 주는 요소가 매우 많기 때문이다. (kernel 버전이나 BIOS 설정까지도 포함, 코드 1줄만 바꿔도 성능이 완전히 달라질 수도 있고, 등등.) 따라서 나중에 실험 재현을 위해서는 실험 환경에 대한 꼼꼼한 기록과 코드 버전 관리가 필수다.

이번 논문의 경우 처음 아이디어는 (지금은 영국에 가있는) 선배로부터 나온 것이다. 지난 1~2월에 빡시게 일해서 framework와 PacketShader/SSLShader 포팅을 이미 완료한 상황이었고, 나는 3월부터 5월까지는 수업 몰아듣기와 조교 및 APSys 논문 준비로 바빠서 일을 못했다. 또한 그 선배는 3월부터 영국에 가서 일하게 되었고, 내가 6~7월 APSys 행사 업무로 바쁜 사이 같이 실험 도와주던 분도 미국으로 가게 되었다. 그렇게 공백기가 있은 후 8월부터 본격적으로 논문 준비에 들어갔는데, 기록 미비로 인한 여러 문제점을 겪어야 했고 결국 이번에 바로 논문을 완성하지 못하는 한 이유가 되었다.

우선, 몇몇 실험의 기록과 코드가 제대로 남아있지 않았다. 미국으로 간 분이 했던 실험을 조건을 바꿔서 다시 해볼 필요가 생겼는데, 실험의 최종 결과 그래프만 엑셀에 덩그러니 남아있고 어떤 서버(하드웨어)에서 했는지에 대한 기록과 실험 때 사용한 코드가 남아있지 않았다. 결국 실험스크립트를 새로 짜야 했고, dictionary 자료구조라서 순서가 보장이 안 되는 항목을 index로 구분하게 해놓아서 실험 데이터의 x/y축이 뒤죽박죽이었다든가 하는 문제가 있었다. (다행히 그 실험의 경우엔 그래프 모양만 보고도 어느게 어느것에 해당하는지 알 수 있었지만.) 그래서 원래는 하루 예상했던 일이 거의 일주일이나 걸렸다. 미국과 시간대가 안 맞으니 계속 이메일과 카톡으로 비동기 커뮤니케이션을 해야 했으니까.

그 다음은, 논리 전개에 대한 기록이 미비했다. 원래는 내가 2저자로 들어가고 영국으로 간 선배가 1저자가 될 예정이었으나, 그분도 영국에서 일하게 되면서 교수님과의 의논 끝에 이 논문에 필요한 실질적인 작업을 하기 어렵다는 판단 하에 내가 1저자를 하기로 결정되었다. 1저자가 되었으니 당연히 논문의 모든 문장에 책임을 져야 하는 법. 그런데... 막상 중간 정도 쓰여있던 writing을 바탕으로 내가 writing을 시작하고 보니, 도대체 구체적으로 정의된 게 거의 없는 것이다. 특히 이 논문의 핵심 아이디어 중 하나는 'TCP congestion control과 유사한 방법으로 GPU offloading fraction을 조정했더니 성능이 잘 나오더라'인데, 실제로 일을 할 때는 '해보니까 잘 된다'였지 이걸 어떠어떠한 구체적인 근거가 있어서 그 방법을 선택했다는 logic이 없었던 것. 그러다보니 우리가 구현한 알고리즘에 사용된 각종 parameter의 값들도 죄다 magic number였고, 이는 그러한 magic number tuning 없이도 어느 조건에서나 최적 성능이 나온다라는 주장과 대치되는 것이다.

당장 코드 구현하고 실험해볼 때야 일단 잘 되면 좋은 것이지만, writing을 하는 입장이 되면 전혀 다르다. 다른 방법도 많은데 왜 그렇게 해야 하는지 왜 그렇게 해서 잘 되는지를 정확하고 구체적으로 설명을 해주어야 하고, 우리의 design decision에 대해서도, 우리가 생각한 technical challenge에 대해서도 구체적인 근거가 있어야 한다. 예를 들면 'scheduler가 light-weight해야 한다'라는 말은 누구나 할 수 있지만, 그게 얼마나 light-weight해야 하는지는 context마다 다를 수 있다. '초당 1백만개 이상의 패킷과 그 패킷으로부터 생성된 task를 매번 scheduling해야 하므로 commodity server에서 자주 사용되는 xxx 모델급의 CPU 성능을 가정했을 때 300 CPU cycle 안에 돌아가야 한다'라든지 하는 식으로 밝혀줘야 하는 것이다.

문제는 그분도 10월초 한국에서의 결혼과 현지에서 작업하고 있는 다른 논문 준비 때문에 나와 커뮤니케이션을 충분히 미리 하지 못했다. 사실 그 선배 머릿속에는 '이런 이야기는 이러이러한 방법으로 보여주면 충분할 것 같고, 이건 우리가 좀더 해봐야 하고, etc etc' 이런 로드맵이 있는 셈이었는데, 그게 논문에도 회의록에도 기록이 전혀 안 남아있었던 것. 그러다보니 한달만에 writing과 추가 실험을 모두 다 해야 하는 상황에서, full paper에서 요구되는 수준의 detail로 어떤어떤 것들이 필요하다는 것을 파악만 겨우 했지 실제로 그 파악한 detail들을 모두 살펴보고 검증하고 실험 or 인용할 시간이 부족했다. 어떻게 보면 그 선배의 머릿속을 backtracking하느라 시간이 다 간 셈이랄까.

그렇다고 해서 그 선배를 탓할 생각은 전혀 없다. 사람이다보니 모든 일에 항상 최상의 퍼포먼스를 가지고 임할 수는 없는 일이고, 나 또한 이것만 하기에도 바쁘게 만든 여러 가지 다른 정황이 나를 더 힘들게 했기 때문이다.

writing만 하든지 실험만 하든지 서버관리만 하든지...

데드라인 3주 전, 연구실의 대표 웹·이메일 서버이자 모든 논문과 소스코드의 버전관리 저장소가 들어있는 an.kaist.ac.kr 서버의 하드디스크가 수명을 다해 죽었다. 다행히 RAID-1으로 미러링되어 있었는데, 문제는 과거에 서버관리하던 사람이 2가지 종류의 RAID 프로그램을 중복 설정해놨다는 것. 이 왜 그렇게 했는지, 어떻게 그렇게 했는지에 대한 문서가 남아있지 않았다. 나름대로 로그도 뒤져보고 시스템관리자 커뮤니티에 질문도 해보고 그랬으나 실제 디스크 수준의 RAID가 둘 중 어느 것이었는지 알 수가 없었다. 그래서 둘 중 명령어로 상태가 정확하게 조회되는 하나를 찍어서 RAID rebuild를 해놓았고 이때까지는 별 문제가 없었다.

데드라인 2주 전, 연구실 서버룸의 에어컨이 수명을 다해 죽었다. 서버실 온도는 50도를 넘어갔고, an.kaist.ac.kr 서버의 아직 교체하지 않았던 다른 하드디스크도 과열로 마저 죽었다. 따라서 새로 미러링된 하드디스크를 다시 미러링하도록 설정하여 복구(?)했다. 연구실의 모든 선풍기를 동원하여 자연 냉방을 해야 했는데, 마침 죽은 날이 토요일이라 에어컨 A/S는 월요일에나 부를 수 있었고 점검 결과 컴프레셔 고장으로 수리비용이 교체비용과 비슷하게 나온다는 결론에 도달했다. 영국에 계신 교수님과 상의를 거쳐 에어컨을 새로 구입하기로 하였고, 중간에 우천으로 하루 연기된 것을 포함 결국 돌아오는 금요일(데드라인 5일 전)에 되어서야 설치가 완료되었다. 에어컨이 없는 동안은 서버를 켤 수 없었기 때문에 최소한의 필수 서버만 켜두고 주로 논문 writing 작업을 했으나, 실험결과가 절대적으로 부족하다는 문제에 직면했다.

그리하여 데드라인 4일 전이 되었는데, 연구실 서버룸의 에어컨 누전차단기가 수명을 다해 죽었다. 이제 이쯤 되면... 만성 멘붕이다. 토요일 밤에 학교 전기실 당직자를 불러 점검해보았고 결국 일요일에 교체. 근데 교체 과정에서 누전차단기의 입력전원을 차단하기 위해 서버실 전원을 모두 한번 내렸는데, an.kaist.ac.kr이 재부팅을 했더니 살아나지 않았다! ㅋㅋㅋㅋㅋㅋㅋㅋ 이유는 2가지 종류의 RAID 중에서 disk level로 미러링하는 게 있고 partition level로 미러링하는 게 있었는데 후자로 서버를 살려놓았던 것. 근데 디스크 2개를 다 갈고 나니 파티션 테이블과 부팅 정보가 날아간 거다.;; 뭐... 굳이 잘못을 따진다면 불필요하게 헷갈리도록 RAID를 설치해놓은 전 관리자를 탓해야 하겠으나 이미 학교에 없는지 한참 된 사람이기도 하고 일단 논문을 쓰는 게 더 급한 상황이니 응급조치를 새로 설치 후 testdisk 프로그램 통해 수동 복구. 누전차단기 덕분에 데드라인 4일 전에 48시간을 고스란히 날렸다.

..이러니 논문이 나올 리가 있겠는가. ㅠㅠ

무엇보다 1~2주 전 사이에 멘붕이 심했는데, 사실 이러한 일련의 사건이 벌어진 것 자체보다도 주변에서 나를 아무도 안 도와준다는 느낌이 들었던 게 더 큰 것 같다. 서버실 관리자도 따로 없어서 내가 혼자 관리하는 상황이고, 논문도 갑자기 1저자를 맡아서 마무리를 해야 하는 상황이라 writing만 하기도 벅찬 걸 실험·코딩도 해야 하는데 같이 일하는 사람들은 다 영국에 있고. 뭐, 인터넷이 발달해서 메신저나 스카이프·구글 행아웃 등으로 연락을 하려면 할 수는 있지만, 소소하게 일상에서 힘든 부분 나누고 생각날 때마다 시시콜콜 물어보기는 아무래도 힘들다. 그쪽도 나름대로 다른 일들로 바빴고, 시차도 무시할 수 없는 요소니까.

원래 서버관리자는 이 논문 끝나고 뽑을 예정이었는데, 하필이면 데드라인 앞두고 일이 터진 건 그냥 운이 나쁜 거라서 어떻게 할 수가 없었다. 또한 실험이나 코딩도 연구실에서 당장 후배를 가르쳐가면서 일을 하기에는 일단 1개월이라는 시간 자체가 그리 충분하지 않았던 것도 아쉽다.

To the next step

그래도 어쨌든 9페이지 분량의 논문을 쓰면서 진짜 제대로 된 12~14페이지 full paper가 되려면 어느 정도의 노력과 일의 양이 필요하겠구나라는 감은 좀 잡은 것 같다. 11월에 MSR 인턴을 가기 전에 다른 학회에 submit을 하는 게 목표인데, accept이 되든 안 되든 일단 내 스스로 봐서 만족할만한 논문을 쓰는 건 쉽지 않은 일인 것 같다. 사실 교수님도 이미 데드라인 며칠 전부터 이번 논문은 힘들 거라는 걸 알고 계셨고, 나는 2주 전부터 이 상태로는 아무리 열심히 해도 스스로 만족스러울 것 같지 않음을 예상하고 있었다. 물론 교수님이 끝까지 내자고 하셨으면 어떻게 냈을지도 모르지만 절대적으로 일의 양과 들인 시간이 모자른 건 무슨 수를 써도 메꿀 수 없는 법.

주변 사람들하고 얘기해보면, 사실 어느 정도 스스로 논문을 리드해서 작성할 수 있게 되려면 기본적으로 걸리는 시간이 있다고들 한다. 개개인마다 차이는 있겠지만, 아직 나는 그 leap을 뛰어넘지 못한 상태인 듯. 이 정도 하면 되겠다라는 감은 생겼지만 실제 그 정도 하기까지 걸리는 시간이 항상 예상보다 많이 걸린다. 그 간극을 극복하는 날이 빨리 오기를...