Paper Writing

(1) 일을 다 끝내기 전에라도 미리 논문을 쓴다/쓰기 시작한다.

첫째로 일반적으로 하고 있는 프로젝트 전체가 하나의 논문이 되는 것은 아니다. 프로젝트와는 별도로 논문을 쓰기 시작하면 어떤 한 부분에 대해 더 집중할 수 있게 된다.

둘째로 논문을 쓰는(계획하는) 과정에서 자신의 생각을 정리할 수 있게 된다. 지금 하고 있는 일의 의미가 뭔지.어떤 것을 다른 사람들에게 보여주고 싶은 건지. 내가 한 일이 남들에게는 어떻게 비치게 되는지.

이 과정에서 지금 자기가 잘못된방향으로 가고 있는 것을 발견하고, 일찍 잘못을 수정할 수 있게 된다.

(2) 리젝(심사탈락)을 두려워 하지 않는다.

리젝되면 당연히 좌절한다. 그리고 100이면 100 자기 논문이 리젝된 이유는 항상 바보같은 리뷰어(심사위원) 한두명이 제대로이해를 못하고 깽판을 쳤기 때문이다. 물론 정치적인 이유로 파워싸움에서 좋은 논문이 사장되는 경우도 많이 있다.

하지만 그 와중에서 보통 좋은 커멘트들을 많이 건질 수 있다. 현재 자기 아이디어의 문제가 무엇인지, 혹은 실험 방법의 문제가무엇인지 나름대로 전문적이고 똑똑한 교수(대학원생)들이 조언을 해준다. 만약 이 사람들이 잘못 이해하고 엉뚱한 커멘트를 해댄다면논문이 자신의 아이디어를 정확하게 전달하지 못하고 있는 것이므로, 좀더 이해하기 쉽도록 고쳐 써야 한다.

그리고 보통 이렇게 두번째 세번째로 작성된 논문은 첫 논문보다 향상되기 마련이다.

(3) 먼저 핵심이 되는 주요 기여 항목(contribution)을 먼저쓴다.

단순히 자기가 한 일을 나열해서는 논문이 되지 않는다.

논문은 기본적으로 무언가를 주장하는 내용인데, 이 컨트리뷰션이야 말로 논문에서 자기가 말하고 싶은 핵심 내용이다.

이를테면 “나는 이논문에서 무엇이 어떻게 설명됨을 보여주었다.”, “나는 이 논문에서 무엇을 어떻게 할수 있음을 보여주었다.”, “나는 이논문에서 나의 방법을 쓰면 기존에 비해 이렇게 좋아짐을 보여주었다.”. 라는 간단한 문장들이다. 학회지에 따라 이 컨트리뷰션을 직접적으로 서술하는 곳도 있고 그렇지 않은 곳도 있지만, 논문을 쓰는 과정에서는 이 문장들을 일단 만들고 시작한다.

(4) 논문의 모든 나머지는 위에서 말한 컨트리뷰션을 뒷바침하기 위한 덧붙임에 불과하다.

그러므로 위에서 기술한 컨트리뷰션에 집중해서, 필요없는 내용을 넣지 말고 꼭 필요한 내용들이 어떤 식으로, 어떤 순서로 덧붙여 질지를 생각해서 논문을 구성해야 한다.

(5) 명심할 것은 논문은 자기가 한 일(S/W, H/W)에 대한 상세 사용 설명서가 아니다.

논문에서 가장 중요한 일은 이것을 잘 모르는 사람에게 주된 아이디어를 전달하는 일이다.

논문의 진정한 용도는 쓰는 사람이 아니라 읽는 사람이다. 자세한 내용을 넣을 수 있을 만큼 충분히 넣으면 좋지만, 세부적인 내용보다는 일단 전체적으로 “무슨 문제가 있어서 왜” 자기가 아이디어가 있어야 하는지,”일단 큰틀에서 어떻게” 자기 아이디어가 작동하는지, “결과적으로” 어떻게 되는지를 논문을 대충 읽을때도 금방 알 수 있도록전체 구조를 완성해야 한다.

본인이 (특히나 시간에 쫒겨가며) 남의 논문 읽을 때 어떻게 하는지 생각해 보면 감이 온다.

(6)논문의 구조를 잡을 때는 워드나 LaTeX 말고 파워포인트(또는 MindManager)로 하는 것을 추천한다.

워드나 레이텍을 쓰더라도 일단 문장과 패러그래프를 만드는 것 보다는 개조식으로 (Bullet을 이용해서) 내용을 작성하는 것이 스스로 논문 전체 구조를 흩어보는데 편하다. 즉, 구조를 잡을때는 각 섹션(절)별로 그 세션에서 무슨 이야기를 하고 싶을지를 몇 개의 간단한 문장으로 적는 것이다.

<예> Introduction

• 미소녀 연애 시뮬레이션(미연시) 게임을 만드는데 시간과 돈이 많이 걸린다.
• 기존 미연시 게임 엔진들은 주로 어떠어떠한 스크립트 엔진기술을 이용한다.
• …..

(7) 자신이 보통 논문이 읽는 순서대로 구조를 작성한다.

(즉 스스로 독자를 가정해서) 나같으면

Abstract ->Conclusion -> Introduction -> Experimental Results -> RelatedWork -> Main How-To의 순서로 쓰겠다.

(8) Abstract를 작성하는 일은 논문 전체의 구조를 잡는 일과 직결된다.

Abstract가 논문의 축약본이므로. 이걸 맨 마지막에 할 수도 있는데, 처음에 한번 하고, 나중에 다시와서 바로잡는 편이 더 낫다고 생각한다.

Abstract에서는 다음의 내용을 대충 다음 비중으로 적는다.

• 문제의 소개 (1 ~ 2 문장)
• 우리의 핵심 아이디어 (2 ~ 4 문장) + 다른 컨트리뷰션(더 써야할게 있다면, 1~2문장)
• 실험 방법 및 결과 소개 (1 ~ 2문장)

<예> Abstract

• 미소녀 연애 시뮬레이션 게임을 만드는데 시간과 돈이 많이 걸린다.
• 기존 스크립트 엔진들을 차기작을 만들기 위해서는 엔진을 다시 고쳐야 했다.
• 우리는 모듈화된 스크립트 엔진을 구성해서 이런 불편을 없앴다.
• 우리 엔진은 액션, 리액션, 텍스트, 그리고 그래픽이 모두 별도의 동적 스크립트 엔진으로 독립적으로 구성되어 있다.
• 그러므로 한 엔진이 진화하더라도, 다른 엔진들은 그대로 사용할 수 있다.
• 본회사의 세가지 19금게임을 전 연령판으로 업데이트 할때 평균 40%의 게임 시스템이 변경되어야 했다.
• 그러나 우리 엔진은 각각의 모듈에 대해 서로 다른 명령어 키트를 정의하는 방식으로, 평균 X%의 코드만 변경이 요구되었다.

(9) Conclusion에서는

간단하게 핵심 아이디어 및 컨트리뷰션을 명확히 반복해서 써주고, 결과 (있다면, 아직 없다면 상세한 숫자는 XXX로 표시해 둔다.)를 소개한다.  문제를 다시 소개하지 않아도 된다. (하더라도 한문장으로 끝낸다.)

<예> Conclusion

• 우리는 이 논문에서 미소녀 연애 시뮬레이션 게임을 위한 모듈화된 스크립트 엔진을 제시했다.
• 우리 엔진은 각각의 모듈이 별도의 동적 스크립트 엔진이다.
• 결과적으로 게임을 업데이트 할때, 시스템이 변경되더라도 엔진이 변경되지 않았다.
• 우리 결과에서 평균 40%의 시스템 변경이 X%의 코드 변경만 요구되었다.

(10) Introduction은 풀려고자 문제를 독자에게 소개하는 자리이다. 

독자들도 바쁜사람이라서 흥미가 없으면 논문을 대충읽게 되니까, 여기서 독자의 흥미를 끌어야 한다. 즉, “어떤 문제가 있는데”, “이 문제가 왜 중요하고”, “나는 어떤식으로 접근한다.” + “그러므로 내 기여는 아래와 같다.” 의 순으로 쓰게 된다. 바쁜사람들은 인트로덕션까지만 읽고, 본문은 쳐다 보지도 않는다.

모든 독자가 이 문제에 대한 전문가는 아니다. 이 분야에 전혀 문외한인 사람들도 이 논문을 읽게 될지 모른다. (리뷰어를 통과한 다음 논문이 유통되는 과정을 생각해 보자. 혹시아나 <과학>이나 <자연>에서 유명한 사람이 인용 해줄지.) 그러므로 그 사람들도 이 인트로뎍션에서 위에서 따옴표로 말한 것들의 개략은 이해할 수 있도록 해줘야 한다.

그러므로 일단은 가능한한 일반적인 (주의. 너무 일반적인데서 시작하면 지루해진다.) 부분에서 시작해서 일반적인 논조의 문제를 소개한다. 그 다음으로는 현재 다른 사람들은 어떤식으로 풀고 있는지를 간단하게 설명해준다.

(학회 전통에 따라 다르지만 관련 연구를 Introduction에서 소개하기도 하고, 뒤에 Related Work를 따로 붙이기도 한다. 뒤에 따로 붙일 경우에는 Intro에서는 너무 많이 다르지 않고, 일반화 시켜서 간략하게만 접근한다.)

그 다음 자기 아이디어의 핵심을 간략하게 소개한다.  중요한건 자기 아이디어를 항상 [짧은한문장], [두,세문장], 그리고 [한 문단]으로 요약할 수 있어야 한다는 거다. 길가다가 어떤 사람이 너 지금 뭐 연구 하냐고 물어봤을때 일단 짧은 한문장으로 대답해 주고, 그 사람이 재미있어 하면 두-세 문장으로 늘려서 대답해 줄 수 있어야 한다. 아직 그렇지 못하다면 자기 일을 논문으로 쓰는 과정에서 이것을 달성하게 된다.

여기에 나는 전체 아이디어의 개요를 한눈에 보여줄수 있는 그림, 도면(혹은 코드 예제)를 삽입하는 것을 추천한다. (이는 특허의 첫번째 그림과 같은 역할을 한다.) 아니면 자신의 결과중 그 의미를 가장 이해하기 쉬운거 하나를 Motivating Example로 삽입해서 본인이 도대체 뭘 이루려고 한건지를 강력하게 설명한다.

다음으로 학회 전통에 따라 기여 항목을 직접적으로 서술한다. 아니라면 위의 아이디어 핵심에서 서술되었어야 한다. 읽는 사람들은 바빠서 대충 읽는 사람들이므로, 중요한 기여항목은 솜씨있게 반복해서 이야기 해줘도 좋다. (너무 많이 반복하면 지루하다. 그 줄타기를 잘 하는건 경험에서 나올 듯.)

그 다음으로 목차서술이 올 수 있다. 섹션2에서는 뭐가 나오고, 섹션3에서는 뭐가 나오고 등등. 이걸 좋아하는 사람이 있고 싫어하는 사람이 있는데 나는 좋아한다. (논문 전체에 대한 지도 같은 개념이므로) 페이지수 제한에 걸렸다면 빼버려도 상관없다.

<예> Introduction

• 미소녀 연애 시뮬레이션(미연시) 게임을 만드는데 시간과 돈이 많이 걸린다.     // (일반적 소개)
• 기존 미연시 게임 엔진들은 주로 어떠어떠한 스크립트 엔진기술을 이용한다.     // (기존 기술)
• 그런데 이 기술은 그래픽에 수정을 가하거나 패치를 만드는데 이러이러한 불편이 있다.  // (기존 기술의 문제)
• 특히 차기작에서 새로운 기능을 추가하기 위해서는 엔진 전체를 새로 만드는 일이 허다하다. // (기존기술의 문제)
• 그래서 우리는 기능별로 모듈화된 미소녀 게임 엔진을 만들었다. [그림1] // (우리의 접근 방법)
• 우리 엔진은 동적 스크립트를 사용해서 코드 변경 없이 새로운 시스템을 형성할수 있도록 한다. // (우리 접근 방법)
• 우리 엔진은 모듈화 구조 및 통일된 인터페이스를 사용하여, 별도 모듈 컴파일을 없앴다. // (우리 접근방법)
• 이 논문에서 우리의 기여는 다음과 같다.  // (주요 기여 항목)
  • a) 우리는 동적 스크립트 엔진 구조를 제안한다. 이 구조는 코드 변경없이 다양한 새로운 액션-리액션 시스템을 추가할수 있게 한다.
  • b) 우리는 모듈화된 엔진 구조 및 인터페이스를 제안하였다. 이 구조를 통해 한 엔진이 변경되더라도, 다른 엔진은 코드 변경이 없도록 만든다.
  • c) 우리는 모듈화된 동적 스크립트 엔진의 한 구현예를 보여주었으며, 실제 구현에 있어서의 문제점을 소개한다.
• [그림 1] (a) 우리 스크립트 엔진의 블록 구조도 및 (b) 동적 스크립트 예시  // (개괄적, 요약적 설명 그림)

 

(11) Experimental Results

나를 포함한 많은 독자가 Introduction에서 문제에 대해 감을 잡고, 실험결과로 점프한다. “그래서 얼마나 좋아지는 걸까?” 결과가 너무 안좋으면 굳이 복잡한 디테일을 읽고 싶어 하지도 않는다. 그러므로 나도 결과부터 먼저 정리한다.

우선 먼저 그래프 부터 그린다.

아직 결과가 끝나지 않았다고 하더라도, 일단 더미 그래프를 그려둔다. 어떤 어떤 그래프/표를 몇개 넣을 것인가? X축은 뭐가 되고, Y 축은 뭐가 되는가? 막대그래프를 그릴것인가, 선그래프를 그릴 것인가?

특히 실험이 아직 끝나지 않았을 때 이게 훨씬 더 중요하다. 어떤 실험을 어떻게 해야 하는지 이 과정에서 다시한번 생각해 볼 수 있을 것이다. 독자의 입장에서 접근해 본다. 자기가 현재 하려고 했던 실험이 정말 자기가 주장하는 바를 밝혀 주는가? 독자들이 어떤것을 지적할 수 있겠는가?

더미데이터로 예상하는 그래프 모양을 그려볼 수도 있다. 자기 방법의 장단점은 자기가 가장 잘 알테니까, 어떤 입력의 어떤 범위에서 어떤 장점을 보일지 아니면 단점을 보일지를 희망적으로 그려보고, 독자들이 합리적이고 믿을만하게 받아들일 수 있는 모양이 어느정도인지 생각해본다. (단 더미 그래프는 반드시 더미 그래프라고 표시해 두고, 더미 그래프를 제출하는 치명적인 실수를 하는 일이 없도록 할것. 혹은 드래프트 리뷰시 교수가 잘못된 희망을 가지지 않도록 예방할 것)

이 방법의 또 다른 장점은 마지막에 논문 제출시간 다 되어 왔을 때, 축 설명 폰트 사이즈, 그래프 선 굵기, 그래프 제목 같은 사소한 문제 때문에 시간을 낭비하지 않도록 해준다. 마감시간 30분전에 최종 실험이 끝나는 한이 있더라도 그냥 데이터만 덮어쓰면 그래프가 다시 그려져서 그대로 논문안에 들어갈 수 있도록 해두는 것이다. (물론 실험결과에 대한 설명이 개발 세발이겠지만)

실험 환경및 매개변수들은 별도의 표로 깔끔하게 정리하는 편이 좋다.

<예> Experimental Results

[표1] 컴파일 및 개발, 실행 환경 일람

[그래프1] 막대그래프, 벤치마크 어플리케이션을 통한 엔진 성능 측정   => 엔진 오버헤드가 낮음을 보여주자.

X축 - [(1) 액션 100%, (2) 그래픽 100%, (3) 동영상 100%, (4) 텍스트 100%] Y축 - 로딩및 리액션 시간

[표 2] 어플리케이션 및 개발 요구사항 => 문제 사이즈가 어떤지를 보여주자.

   <제목 : 프로젝트 : 원본 게임 크기 (멀티미디어 제외) : 단순 스크립트 수정: 액션 및 시스템 수정>    <해롱해롱 비치대작전 : 전연령화 버전 : 120 MB : 40% : 20%>    <블랙 데이트 : 고사양 리메이크 : 10 MB : 25% : 80%>    <그리핀 헌트리스 : 18추버전 : 200 MB : 10% : 20%>

[그래프2] 쌓아진 막대그래프, 어플리케이션별 엔진 코드 수정 % 및 그 내역 => 얼마나 코드를 적게 고치나.

X축 - 비치대작전, 데이트, 헌트리스 Y축 - 그래픽엔진수정, 액션엔진수정, 텍스트엔진수정, …

[그래프3] 라인그래프, 어플리케이션별 개발 진척 로그 => 얼마나 일이 빨리 끝나나

X축 - 시간 (man-day) Y축 - 진척도 (%) [범례: 빨간색- 비치대작전, 파란색-데이터, 초록색-헌트리스]  

(12) Related Work

자기의 일이 다른 사람들의 일과 어떻게 다른지를 이야기 해준다. 다른 사람들 깍아내려야지만 자기 논문이 사는 것은 아니다. 다른 사람들의 일을 훌륭하게 요약해 주고, 자기일이 어떻게 다른지, 그래서 어떤 경우에 더 좋은지를 이야기 해주는 걸로 충분하다. 모든 다른 사람보다 모든 경우에 다 좋으면 킹왕짱이겠지만, 그렇지 못할경우가 많을테니까. 분명 뭔가 하나는 좋은게 있을꺼다. 논문에 졸업해야 해서 억지로 하는일임 이라고 쓸수는 없을 테니까.

비슷한 업적의 다른 사람의 일을 일부러 언급 안하는 건 피하는게 좋다. 독자가 그 일을 안다면, 결국 작가들이 공부를 게을리 해서 그 일을 몰랐던가, 아니면 알고도 모른척 했던가 라고 생각할테니까. 둘다 연구자로서는 감점이다. 특히 두번째는 실격에 가깝다.

<예> Related Works

• SCUMM엔진은 고전 그래픽 어드벤처 게임에 사용되었으며, 지금은 사용되지 않는다.
• 이파리사의 엔진은 어떤 문제가 있었다.  우리는 그런 문제가 없다.
• 달사의 엔진은 좋긴한데, 어떤어떤 경우 어떤 문제가 있었다. 우리는 이 경우를 이렇게 피해갔다.

(13) Main-Body

이제 정말로 관심 있는 독자들이 본문에 들어와서 관심있게 읽게 된다. (물론 처음 심사하는 사람들은 당연히 관심읽게 있는다.) 본인이 한 일이므로 가장 자신있게 적을 수 있는 부분이기도 하다.  문제는 페이지가 한정되어 있다는 점이다. 그러므로 핵심 내용과 꼭 필요한 것을 위주로 걸러가면서 적는다.

마찬가지로 먼저 그림 (혹은 코드, 표)을 그린다. 그림을 그리면서 어디어디를 어떻게 설명해야 할지 본인 스스로 감을 잡게 된다. 소프트웨어의 경우 핵심 부분의 예제 코드를 보여 주는 것도 도움이 된다. 그리고 나서 중요한 것을 위주로 꼭 설명해야 할것들의 리스트를 다단계로 적는다.  페이지가 모자라면 중요도가 떨어지는 것 부터 자른다.

정 페이지가 모자라고 할말이 많으면 더 긴버전의 리포트를 만들어서, 자세한 내용을 원하는 사람들을 위해 그 리포트를 인용해 준다.

한 섹션으로 할수도 있지만 메인 아이디어 –> 실제 구현의 두 섹션으로 나누어 적는 것도 괜찮다. 첫번째 섹션에서는 주된 아이디어에 대해서 전체적 추상적으로 논하고, 실제 구현의 문제는 두번째 섹션에서 언급해 준다.

<예> (전문적이어서 생략)

(14) 반복 및 재구성

여기 까지 오는 과정에서 본인 스스로 자기 일을 충분히 정리할수 있게 된다. 다시 들여다보면 소개-본문-실험-결론의 아귀가 안맞거나, 심지어 자기의 <기여항목>이 자기가 처음에 생각하고 있던것과 다를수도 있다. 이런 것들을 다시 맞추고 몇번 반복하면 점점더 좋은 구조의 논문이 만들어 진다.

(15) 지도교수 면담

내생각에, 여기까지 왔을때가 지도교수랑 면담하기 제일 좋을 때다. 일단 지금까지 만든 개요를 가지고 지도교수에게 자기가 한일을 이해시킨다. 농담이 아니라, 모든 지도교수가 모든 학생의 모든 연구를 다 이해하고 있지는 못하다. 아까 말했듯, 심지어 학생 본인도 자기가 하는 일이 뭘 의미하는지를 논문 쓰기 전까지 잘 이해하지 못하기도 하니까 당연하다. 그리고 만약 자기 지도교수가 자기일을 잘 이해 못한다면, (그 사람은 그분야에서 그래도 얼마정도 인정받은 사람이다) 지금 개요가 <기여항목>과 <핵심 아이디어="">를 충분히 잘 전달하지 못했다는 거다.

자기 지도교수도 하나 설득 못 시키면서, 다른 심사위원들을 어떻게 설득시키겠는가?

본인 지도교수는 똑똑한 사람이므로 이 내용을 일단 이해하면 훌륭한 조언을 해 줄거다. 특히 어떤 내용을 더 집어넣을지, 어디를 뺼 지, 무슨 실험이 더 필요한지 빨리 catch해서 이야기를 해 준다. 시간이 아직 좀 있으므로 이때 내용을 미리 고치고, 실험을 재설계한다.

물론 본인 지도교수가 반신급이라 못 만나면 할수 없음. 그럴땐 고년차 박사과정이나 포닥하고 상의하자. 본인이 이미 교수님이시라면, 혹은 다른 연구직이시라면, 공동 저자가 될만한 사람과 상담할 수도 있다.

(16) 문장화

이제야 비로소 본문(텍스트)을 만들기 시작한다. 영어 논문일 경우 (혹은 기타 비모국어 논문), 이 과정이 고통스럽다. 하지만 이걸 맨 마지막에 하는 것에 주목한다. 개요를 다 만들고 났으면 정말로 영어 문장 만드는 일에만 집중하면 된다. 두개를 동시에 하는거에 비해 일의 난이도가 훨씬 줄어든다. 그리고 영어를 잘하는 제2,3저자를 모집해서 본문을 만들어 가는 일도 된다. (아직 없었다면) 이 보조 저자들도 만들어진 논문 구조개요를 보고 내용을 잘 이해해서 따라오게 되므로 응집력 있는 논문을 쓸수 있게 해준다.

또 실험이 아직 남아있다면, 실험 돌리는 동안에 본문을 만드는 작업을 병행할 수 있다.

(17) 표, 그래프의 자막(캡션)

캡션사이즈는 너무 작으면 안된다. 하지만 너무 클 필요는 또 없다. 캡션을 한줄로 짧게 제목만 달 수도 있지만, 캡션에다가 길게 설명을 늘여쓰는 일도 가능하다. 논문 페이지수가 모자랄떄 쓸 수 있는 테크닉이다. 덤으로 그림만 보고 넘어가는 사람들에게 좀더 아이디어를 잘 전달해 줄 수 있다.

(예) [그림4] 스크립트 엔진 구조도: 오른쪽 네모는 스크립트 메인엔진으로 스크립트는 세모로 표시된 이진 힙에 저장되어 있다. 엔진은 스크립트 입력으로 부터 명령 패킷 (동그라미화살표)을 만들어서 아웃풋 큐에 저장하게 된다.

(18) 제목

제목은 섹시하게 잡아야 한다. 키워드가 제목에 꼭 들어가게 만든다. 생각없이 인용하는 많은 사람들이 논문마감 하루전에 자기 토픽으로 구글 스칼라 검색해서 제목이 그럴듯한걸 집어넣기 때문이다. 한 구문으로 논문 전체를 압축해야 하므로 생각을 많이 해야한다. 떄로는 그냥 직접적으로 적는게 좋기도 하고(“모모를 위한 모모 기술”), 약칭이나 별명을 붙여서 그럴듯하게 보이기도 하고 (“ABCD: 모모하는 모모 시스템”), 감상적으로 가보기도 하고 (“모모에 관해서”), 비굴하게 가기도 하고 (“모모를 모모하는 사례”), 개인 취향에 따라 다르기때문에 특별한 조언은 없다. 다만 맨날 똑같은걸 반복하는 일을 피한다.

(19) 논문의 목적

공식적으로 논문은 독자들에게 정보를 전달하는, 독자들을 교육시키는 수단이다. 그러므로 논문은 읽는 사람들에게 최선이 될수 있도록 쓰여저야 하며, 읽는 사람들이 논문에서 무엇인가를 배운다면 그 논문은 성공한 것이다. (물론 읽지도 않고 제목만 보고 인용해 주신다면야 굽신굽신.) 독자들이 쉽게 자신의 생각에서 뭔가를 배울 수 있도록 하는데 최선을 다한다.

다만 그러기 위해서는 일단 출판되어야 한다.

한가지 좋은 소식은 일단 쓴 논문은 기본적으로 어딘가에 궁극적으로 출판된다. 근데 처음부터 너무 높게 목표를 잡으면 시간 낭비고 (리뷰를 받기 까지의 기간이 너무 길다), 너무 낮게 잡으면 이건 더 큰 시간 낭비다 (아무도 읽지 않고 알아 주지도 않는다).

약간 높은데에서 시작해서 점점 내려가는 방식을 택하자.

---

How to Write a Great Research Paper

Professor Simon Peyton Jones, Microsoft Research, gives a guest lecture on writing.

Seven simple suggestions:

don’t wait - write, identify your key idea, tell a story, nail your contributions, put related work at the end, put your readers first, listen to your readers.

Abstract of the talk

Professor Simon Peyton Jones, Microsoft Research, gives a guest lecture on writing. Seven simple suggestions: don’t wait - write, identify your key idea, tell a story, nail your contributions, put related work at the end, put your readers first, listen to your readers. Prof. Peyton Jones’ lecture contained a lot of question and answer sessions with the audience. These have been removed from this video, cutting the original 50 minute lecture down to 30 minutes.