Motivation 문서 원본 보기

[[분류: Style: Lessons in Clarity and Grace]]

== 개요 ==
어떻게 Introduction, Motivation, 그리고 Conclusion을 써야 할 것이지 설명한다.

Motivation은 크게 두가지 목적이 있다.
* 독자들에게 앞으로 어떤 것에 대해서 설명할으로써, 그들이 좀더 많은 지식을 가지고 글을 읽을 수 있도록 함
* 독자들이 글을 읽고 싶도록 Motivate하여, 그들이 그을 더욱 자세히 읽도록 함

== Introduction 을 작성하는 법 ==
Introduction은 당신 뿐만 아니라 독자들도 흥미로워하는 지식을 통해서 독자들을 Motivating하여야 한다. Introduction은 다음 세가지 단계로 구성된다.
 Shared context -> Problem -> Solution/Main Point/Claim

=== Part 1: Establishing a Shared Context ===
우선 독자들이 알고 있는 사실을 환기하며 글을 시작해야 한다. 이를 통해서 독자들은 뒤에 제시될 Problem이 독자들이 잘 알고 있는 분야에 큰 문제가 된다는 사실을 더욱 공감할 수 있게 해야 한다. 이런 사실은 역사적인 Background사실이나, 아니면 Recent event, 혹은 Common belief와 같은 것들이 온다.
<blockquote>
Memory bugs persist as enduring security vulnerabilities in
software systems. Arising from developers’ oversights and the
use of memory-unsafe languages, these bugs are prime targets
for exploitation by attackers. Numerous strategies have been
proposed to prevent or detect use-after-free (UAF) bug.
OTA incorporates the notion of virtual
aliasing [23], where multiple aliases
of objects are mapped to a single page [42]. 
</blockquote>

=== Part 2: Starting the Problem ===
Shared context에 대한 글 뒤에, 보통은 But 혹은 However과 같은 말로써, Shared context에서 가지는 문제점을 지적하게 된다. Problem이 Problem처럼 느껴지기 위해서는 두개의 조건을 만족해야 한다.
# Condition 혹은 Situtation: 문제를 일으킬 가능성이 있는 존재 (E.g., 테러, 과음, 계엄)
# Itolerable consequence or cost of the condition: 그 존재로 인하여 발생하는 비용 (E.g., 사회혼란, 건강의 해악)

우선 Condition혹은 Situtation이 나오고 그후 <So, what?>에 해당하는 답인 Cost에 해당하는 설명이 나와야 한다.
<blockquote>
However, the
aliased-based OTA<condition> introduces a notable performance overhead
due to frequent system calls (one syscall for each allocation or
free) <so, what?>.
</blockquote>

Problem은 크게 두개의 종류로 나누어진다.
# Practical problem: Action을 요구하는 문제이다. 이 문제는 해결해야 하는 문제로, 특정 행위를 해서 해결해야 한다. 예를 들어서, 술을 먹는 학생들이 일으키는 문제를 해결하기 위한 방안들은 Practical problem이다.
# Conceptual problem: Understanding를 요구하는 문제이다. 이 문제는 밝혀내야 하는 문제로, 이해를 통해서 해결해야 한다. 예를 들어서 술을 먹는 학새들이 왜 술을 먹는가에 대한 문제는 밝혀내야 하는 문제이다.

이 두 종류는 해결하고자 하는 문제의 종류가 다르기 때문에, 과연 내 문제가 두 종류중 어느것에 속하는지를 알아내는 것이 Motivation을 쓰기 전에 생각해야할 중요한 문제라고 할 수 있을것이다.

=== Part 3: Starting the Solution ===
Solution은 이제 본격적으로 우리가 주장하고 싶은 바이다.
; Practical Problems: WHat We Should Do
: Practical problem을 해결하기 위해서 저자는 독자에게 '''어떠한 행위'''를 해야 함을 주장해야 한다.

; Conceptual Problems: What We Should Think
: Conceptual problem을 해결하기 위해서 저자는 독자에게 '''이해 혹은 믿음(Understand or believe)'''를 해야 함을 설득해야 한다.

<blockquote>
This paper introduces BUDAlloc, presenting a new design
approach for the practical implementation of OTA. BUDAlloc
aims to strike a balance between performance and memory
overhead while providing strong UAF bug detectability<solution/point>. 
BUDAlloc does not compromise compatibility, allowing unmodified
binaries to use BUDAlloc by simply replacing the default
allocator using LD_PRELOAD.
The core idea of BUDAlloc consists of two parts: separating
virtual address from in-kernel memory management, and
co-designing a one-time-allocator and virtual address management
at the user-level. <solution/point>
</blockquote>

=== Another Part: Prelude ===
위에 설명한 것 이외에, Skillfull한 저자들은 다음의 장치를 이용해서 보다 확끄는 Introduction을 작성하기도 한다.
# A Quotation: 인용 E.g., "호의가 계속 되면 권리인줄 알더라 - 고길동"
# A Startling Fact: E.g., "구체형 지구의 둘레는 약 4만 km라고 배운다. 만약 4만 km로 구체 지구가 정말로 맞다면, 5km만 지나도 굴곡이 생기기 시작해야 한다. 하지만 지구는 그렇게 생기지 않았다. 수십, 수백 km를 지나도 땅은 평평하다."
# An illustrative anecdote: "내가 피행기에 타보니깐, 지구의 표면이 둥글게 보이는게 아니라 평평하게 보이더라"

== Introduction을 개조하는 법 ==
# 문제가 Practical problem인지 아니면 Conceptual problem인지를 구분한다.
# Introduction이 끝나는 부분을 명확히 한다.
# Introduction을 shared context + problem + solution/main point/claim의 세 부분으로 나눈다.
# Shared context뒤에 But, However과 같은 단어를 사용해서 shared context에서 challenge하려는 문제가 무엇인지를 명확히 한다.
# Problem을 condition과 cost로 나누어 설명한다.
# Introduction말미에, solution/main point/claim을 명확히 강조하며 끝을낸다.

== Conclusion 작성법 ==
Conclusion은 글의 요점, 중요성, 그리고 암시하는 바를 문제와 함께 다시한번 정리해야 한다. Conclusion은 Introduction보다는 정형화 되어 있지 않지만, Introduction의 순서를 반대로 하는 것으로 어느정도 흐름을 잡을 수 있다.
* 간단한 요점, 주장, 그리고 해결방안으로 시작한다.
<blockquote>
This paper presents a practical OTA designed by separating
virtual and physical address management and by co-designing
one-time-allocator and virtual address management at the user-
level.
</blockquote>

* 중요성을 다시하번 강조한다. So, What?
<blockquote>
BUDAlloc showcases well-rounded results in terms of
performance, memory use, scalability, and bug detectability
compared to FFmalloc, DangZero, and MarkUs.
</blockquote>

* 추가적으로 필요한 이야기를 제시한다. Now What?
* Prelude에서 말한 3가지 요소를 마지막으로 마무리 한다.

보통 Computer sience논문에서는 아래 두 요소는 생략한다.