대학원에 들어온 후로 준비했던 논문들이 몇 개 있는데, 그 중에 석사졸업연구로 진행했던 "DoubleClick: Click modular router의 성능 향상에 관한 연구"를 얼마 전 APSYS에 submit하었고(물론 accept될지 안될지는 아직 모름) PacketShader의 후속 프로젝트로 진행한 nShader라는 network application을 위한 GPU/CPU task scheduling framework 연구가 있다. 원래는 이걸로 이번에 OSDI에 논문을 내려고 했지만 생각했던 대부분의 프로그램 구현과 실험을 거의 모두 했음에도 writing 미비로 제출하지 못하고 다음으로 미루어졌다.

몇 차례 연구를 진행하고 논문을 쓰다가 막판에 내지 못하는 상황을 겪으면서, 그 이유가 무엇일까 고민해보게 되었다.

한 가지는 아직 충분한 스토리라인을 만들기 위한 배경지식이 부족하다는 것을 꼽을 수 있겠다. 내가 전에도 적은 적이 있듯이, 석사생활을 되돌아보면서 가장 아쉬운 부분이 논문을 "좀더" 많이 읽지 못했다는 점이다. 논문을 하루에 한편씩만 꾸준히 읽어도 엄청난 자산이 되는데, 문제는 단순히 많이 읽는 것이 중요한 게 아니라 critical thinking을 하면서 읽어야 한다는 것이다. 그 과정에 익숙해지기까지는 논문을 읽는 데 시간이 많이 걸린다. 이 부분은 요즘에 와서야 좀 감이 오는 것 같다. 논문을 읽으면 예전엔 그냥 '우왕 그렇구나'하고 설득당했는데(...) 요새는 '이러이러한 방법도 있는데 왜 안 썼지?', '이 대상에 이 방법을 적용하는 것보단 다른 방법이 나을 것 같은데 왜 이렇게 했지?', '이 문제를 풀 땐 이게 어려운 점일 것 같은데 제대로 설명하고 있나?', '이 방법을 다른 대상에 적용해보면 어떨까?' 등등의 질문을 던지게 되었다.

논문을 많이 못 읽었던 이유는 뭐랄까, 여유가 없었던 것 같다. 일단 교수님이 이런 문제 한번 들여다보자 하고 던져준 것으로 시작했는데---처음이니까 일단은 연구하는 방법을 배운다는 생각으로---실제 그 문제를 제대로 들여다보기까지 문서화되지 않은, 선배들이 했던 삽질을 또 하느라 허비한 시간이 너무 많았다. 이건 단순히 선배들을 탓할 수만도 없는 것이, 무엇을 모르는지 정확히 알아야 선배들한테 질문을 할 수 있을 텐데 어떤 문제에 맞닥뜨렸을 때 질문을 할 것인지 아니면 혼자서 더 살펴볼 것인지 선택하는 기준(?)에 대해 깨닫는 시간이 오래 걸렸다고 보는 것이 맞을 것이다. 사실 최광무 교수님의 표현을 빌리자면, 무엇을 모르는지 아는 것이 학생의 첫걸음이라고 했다. 수업이나 조교하는 오버헤드도 있었지만 이건 누구나 공통적으로 하는 일이니까 나만 힘들었다고 말할 수 없겠다.

그래도 다행히 석사졸업을 무사히 할 수 있었던 건, 그러다가 막판에 선택과 집중에 성공했기 때문이다. 졸업논문 데드라인 한달 남겨놓고 연구의 범위를 확 좁혀들어가니 논문의 스토리라인이 명확해지고 해야 할 일도 명확해지고 그 전까지 했던 삽질 노하우를 모두 활용하게 되면서 순식간에 논문을 써낼 수 있었던 것이다. 물론 지금 다시 석사논문 읽어보면.... 음... 이건 흑역사다. ㅋㅋ

요번에 APSYS 논문 제출하고 나서 출장가신 교수님과 영국에 있는 건이형과 함께 Skype 채팅으로 잠깐의 회고를 진행했다. '그래도 이번엔 submit은 할 수 있는 정도의 수준는 되었는데, 그래도 여전히 부족한 건 어떻게 보완할 수 있을까?' 그리고 OSDI 논문이 불발되고 나면서 다시 건이형과 회고한 내용도 같은 맥락이다. 그 내용을 기억해두기 위해 글로 정리해본다.

지금까지의 경험과 선배들의 조언을 종합해보면, 좋은 (공학) 논문은 다음의 조건을 만족해야 한다:

1. 어떤 문제를 왜 풀어야 하는지 설득한다.
2. 그 문제를 내가 어떻게 풀었는지 이해시킨다.
3. 그렇게 푼 방법이 타당함을 누구나 인정할 수 있는 과학적인 방법으로(실험이나 수학적 증명 등) 보여준다.
4. 다른 사람들의 관련 연구와 비교했을 때 내 방법이 가지는 차별점이 무엇인지 명확하게 알려준다.
5. 이를 다른 연구자들이 같은/비슷한 문제들을 궁금해할만한 적절한 타이밍에 맞춰서 학회에 발표한다.

그러니까 나는 2번, 3번에만 집중하고(물론 이것도 아직은 구멍이 여기저기 많지만) 1번과 4번을 제대로 못했던 것이다. 5번은 약간의 운도 따라야 하는 부분이고 1번과 4번을 잘 하면 해결되는 부분이기도 해서 여기선 논외로 한다.

교수님의 코멘트는, 내 writing이 일단 내 생각을 비비 꼬지 않고 있는 그대로 잘 보여준다는 점은 괜찮은데, 생각이 너무 단순하다는 것. '그래서 무엇을 하겠다는 건지' 어떤 vision과 통찰이 보이지 않는다는 것이다. 그러면서 나보고 소설(...)을 좀 읽고 상상력을 키우면 어떨까라는 제안을 하시기도 했다;; 복잡미묘한 스토리라인과 플롯이 전개되는 과정을 보라는 뜻이셨을까. (그래도 다행인 건 내 writing이 무슨 소린지는 전달이 된다는 점. -_-) 뭐, 내 해석은, 그렇다고 정말 논문을 소설처럼 쓰라는 뜻이 아니라, 이른바 '큰 그림'을 좀더 설득력있게 전달하는 연습을 해야 한다는 것으로 이해했다.

건이형의 코멘트 및 해석은, 좀더 깊이있게 생각하는 연습을 해보라는 것이다. 일단 글로 써놓고 고쳐나가는 것도 한 방법일 수 있지만, 먼저 머릿속에서 논리의 흐름을 정리한 다음 이걸 교수님이나 다른 사람들에게 말로 설명하고 피드백받는 과정을 많이 거쳐야 한다는 것. 그러다보면 교수님이 구멍이 있는 부분을 잡아내고 그걸 메꾸려다보면 자연스럽게 다른 논문도 찾아보고 스스로 고민하게 되면서 스토리라인을 잡아나가게 된다는 것이다. 이를 반복하다보면 좀더 효율적인 의사소통을 위해 그동안 쌓인 배경지식을 바탕으로 머릿속에서 미리 '시뮬레이션'을 돌려보게 되고 그게 익숙해지면 더 생산적인 대화를 할 수 있다는 것. 그러면서 자기가 Microsoft Research에 포닥으로 가서 두달째 하고 있는 일이 그러한 토론만 주구장창하는 거라면서, 내가 지금까지는 일단 연구를 시작해놓고 논문 데드라인 닥쳐서 스토리라인을 만들려다보니 시간도 없고 급하게 하느라 힘든 것인데 일단 구현부터 하고 보는 bottom-up 방식으로 예상치 못한 새로운 발견이 나올 수도 있지만 top-down으로 많은 토론을 거쳐서 주제를 잡아야 나중에 논문 쓸 때 스토리라인이 균형있게 잘 잡힌다고 이야기해주었다.

생각해보면, 석사 때 PacketShader 프로젝트에 참여하기 시작한 것 자체가 "내가 이 주제가 정말 재미있는지는 아직 감이 안 잡혀서 모르겠지만, 일단 대충 관심분야는 맞으니 우선 부딪혀보면서 연구하는 방법을 배우고 경험을 쌓자"라는 것이었지, 내가 어떤 문제를 풀어야겠다고 생각하고 그걸 왜 풀어야 하는지 어떻게 풀고 싶은 것인지가 있는 게 아니었다. 따라서 이런 관점에서 교수님을 설득하려고 시도해보지 않았던 것이다(!). 약간은 닭과 달걀의 관계도 있는 게, 그래도 뭔가 방법을 만들어갔고 이걸 이런 과정을 거쳐서 설득하려고 했으면 좀더 유익한 피드백을 받고 이런 깨달음에 더 빨리 도달하지 않았을까 싶기도 하다. 어쨌든, 교수님조차 설득하지 않는데 어떻게 좋은 스토리라인이 나오며 어떻게 좋은 논문을 쓰리요. ㅠ_ㅠ 그걸 처음 제대로 시도(?)한 게 졸업논문(DoubleClick)과 글로벌박사펠로우십 연구제안서인 것 같다. 곰곰이 되짚어보면, 교수님들이 미팅 때 '그건 왜 그렇게 하는 거지?'라는 질문을 가끔(?) 던지셨던 것 같기는 한데, 그냥 '어떻게' 하는지만 생각하고 대답하기도 바빠서(?) 간과했던 적이 많았다. 앞으로는 교수님을 설득하는 연습부터 시작해야 할 듯.

문득 예전에 보았던 글이 떠오른다. "You are the expert, not your professor." 찾아보니 이런 발표 자료도 있다: "Managing your supervisor"