Microsoft research Simon PJ의 강연 요약
- 먼저 쓰기 시작해라.
- 쓰다보면 아이디어가 발전한다. 연구를 진행하고 나서의 결과물이 논문이 아니다.
- 논문을 쓰는 과정 자체가 연구다. 쓰다보면 부족한 부분, 개선해야할 점이 보이고, 그러면서 연구를 진행하자.
- 키 아이디어를 잡자.
- 논문을 쓰는 목적은 아이디어를 전달하는 것이다. 아이디어는 프로그램 같은 것보다 생명력이 길다. 모짜르트의 악보를 생각해봐라. 실현한 연주는 오래가지 않지만, 악보에 담긴 악상은 지금도 유효하다. 그리고 그것을 써서 퍼트리지 않으면 무의미하다.
- 좋은 아이디어가 떠오르길 기다리지 마라. 다른 논문의 좋은 아이디어에 압도되어 기죽지 마라. 쓰다보면 발전한다. 그리고 쓰는 과정이 일종의 생각과 생각을 주고 받는 대화와 비슷하다.
- 그리고 아이디어는 하나의 clear, sharp ping이어야 한다. 논문을 읽고나서 남는 하나의 키 아이디어가 있어야 하고, 그것 하나를 하나의 논문을 통해 전달해야 한다.
- 이야기로 전달해라.
- 화이트 보드 앞에서 설명한다고 생각해봐라. 그 순서로 논문을 쓰자.
- 너의 공헌을 앞부분에 두어라.
- 문제를 먼저 기술하고, 이것에 대해 어떤 공헌을 했는지 서론의 초반에 가능하면 써라. 논문의 첫 페이지에 초록과 같이 보이도록 하면 좋다.
- 문제는 가능하면 구체적이고, 논문 안에서 해결되는 작은 덩어리면 좋다. 크고 모호한 문제(에베레스트)를 기술하는 것은 의미 없다. 어떤 버그에 대해 얘기하고 싶다면, 버그의 역사에 대해 얘기할 필요 없을 것이다.
- 너의 공헌이 무엇인지 분명하고 구체적으로 밝혀라.
- 서론에서 문제-공헌의 조합을 썼다면 나머지 부분에서 그것을 뒷받침하는 구체적인 증거를 제시하는 것이다.
- 증거들이 어디서 어떤식으로 쓰여져 있는지 스토리텔링으로 서론의 마지막을 쓰자. 플롯과 단순 시간순 서사의 차이를 생각해보라. 단순히 순서대로 쓰면 아무도 안 본다.
- 관련 논문은 나중에 쓰자.
- 내 아이디어에 대한 얘기가 독자들이 궁금해 할 내용이다. 관련 논문- 특히 문제를 해결하려고 시도한 역사를 언급하는 것은 지나치게 돌아 가는 길이 된다.
- 그리고 관련 논문을 길게 쓰는 것은 독자를 지치게 하고, 독자 스스로를 멍청하게 느끼게 한다.
- 또한 관련 논문을 까내리는 것은 피하자. 영감을 준 논문에 대해서는 관대하게 그러했던 점을 언급해라. 존경과 사랑은 나눌수록 커진다. 그렇게 쓴다고 해서 너의 공헌이 작아지는 것이 아니다.
- 너의 아이디어의 약점에 대해서도 밝히는 것이 좋다. disarming하는 것이 좋다.
- 독자를 먼저 생각하면서 써라.
- 독자가 이해하기 쉽도록 문제를 풀어서 쓰고, 가능하면 예제를 제시하자.
- 절대 니가 문제를 해결한 삽질한 과정으로 논문을 쓰지 마라. 상대방이 이해할 수 있는 방식으로 써야 한다.
- 독자의 말을 들어라.
- 전문가 독자도 좋지만, 비전문가 독자의 도움을 받는 것도 좋다.
- 모든 독자는 단 한번만 너의 글을 처음으로 읽을 수 있다. 이 기회를 놓치지 마라.
- 단순히 오탈자, 문법적 오류에 대한 피드백을 받는 것은 지양하자. 그런 피드백 보다는 어떤 부분에서 읽기가 막히는 지, 이해가 어려운지, 말이 안되는 것 같은 부분은 없는지를 받아야 한다. 그런 것을 원한다고 분명히 밝혀야 한다.
- 리뷰어에 대해서 고마운 입장을 가지자. 그 사람들은 너의 글에 대해 깊이 읽어주는 몇 안되는 사람이다. 그렇게 시간을 내는 것은 쉽지 않다. 아주아주 고마워하는 것이 좋다. 물론 쉽지는 않다.
- 리뷰어의 비평에 고마워하며 받아들이고, 리뷰어가 이해 못한 것 같다면 리뷰어를 멍청이 취급하는 것보다 다음과 같이 생각하는 것이 좋다. “이 멍청이도 이해할 수 있도록 논문을 다시 써야지”
