졸업 논문은 특별히 지정된 분량은 없다. 하지만, 기존의 논문들을 보면 약 35 페이지 내외로 한다. [“졸업 때려잡기”] 를 참고한다.
이것은 요약, 목차, 그림, 표, reference 를 모두 포함한 것이다. 폰트는 한글의 경우, 신명조로 하고 크기는 10 으로 한다.
또한 평균적으로 20 개 가까운 표를 사용하고, 5 개 내외의 표를 사용한다.
차례는 약간씩 다르기는 하지만 대개 '논문의 제목 → 요약 → 목차 → 그림목차 → 표목차 → 논문의 본론' 순서로 한다.
기존의 다른 논문(총 40장)을 참고한 각 목차별 페이지 수는 다음과 같다.

1. 서론 : 2장
2. 관련연구 : 5장
3. Overview : 2장
4. 본론 및 구현 : 19장
5. 실험 : 6장
6. 향후 연구과제 및 결론 : 2장
7. 참고문헌 : 4장

임베디드 시스템이 소형화되면서도 많은 기능들이 요구됨에 따라 여기에 올라가는 임베디드 소프트웨어 역시 점점 복잡해지고 있다. 특히 멀티 쓰레드 환경에서 수행되는 임베디드 소프트웨어의 경우, 실행도중 오류가 발생했을 때 버그의 원인을 찾기가 어려울 뿐 아니라, 버그를 재현하는 것 또한 쉽지 않다. 효과적인 디버깅을 하기 위해서는 프로그램 실행 중에 버그가 발생했던 상황을 그대로 재현해야 한다. 본 논문에서는 프로그램이 실행하는 도중에 이벤트가 발생하는 시점의 이벤트 정보를 record 하고, 나중에 이를 이용하여 버그가 발생한 시점으로 replay할 수 있는 기법을 개발하였다. VPOS[1] 에 이 기법을 적용함으로써 임베디드 소프트웨어의 결함을 좀더 쉽게 탐지하여 효율적인 디버깅이 가능하도록 하였다.

소프트웨어 프로젝트에서의 성패를 결정짓는 과정 중 하나가 디버깅이라고 할 만큼, 예전에 비해서 디버깅의 중요성은 점점 강조되고 있다. 프로그램 수행 도중에 버그가 발생했을 때, 서버 또는 데스크 탑 기반의 소프트웨어와는 달리 임베디드 소프트웨어는 제한된 환경에서 디버깅을 해야 하기 때문에 더 많은 시간과 비용이 요구된다. 또한 임베디드 시스템이 소형화되고, 여러가지 기능들이 요구되어짐에 따라 임베디드 시스템 위에서 동작하는 임베디드 소프트웨어는 점점 복잡해지고 있다.

효과적인 디버깅을 하기 위해서는 버그가 발생했을 당시의 상황을 그대로 재현하여 버그의 원인을 찾아내야 한다.
이전의 coredump 를 이용하는 디버깅 방법의 경우, coredump 가 생성되었던 당시의 정보만을 바탕으로 재현할 수는 있지만, 이 경우 coredump 가 생성되기까지의 이전 정보를 얻을 수 없기 때문에 버그의 원인이 되는 단서를 탐지하는데 한계가 있다. 또한 기존의 record and replay 를 이용한 디버깅 방법의 경우, 프로그램의 실행정보를 얻기 위해 소스코드에 실행정보를 record 하는 코드를 삽입함으로서 실행 결과의 변화를 초래하는 탐침 효과(probe effect) 를 발생시킨다.
대부분의 임베디드 소프트웨어 디버깅의 경우 타겟(on-target) 자체의 디버깅 보다는 UART, JTAG 과 같은 인터페이스를 이용한 호스트에서의 원격 디버깅 방법을 사용한다. 이러한 방법은 호스트와 타겟 간의 시간 차로 인한 지연으로 버그가 발생한 당시의 상황을 재현하기 힘들다.
요즘 들어, 이러한 문제점을 보완하기 위해 고성능의 하드웨어 기반의 디버깅 장비나 소프트웨어 디버깅 도구들이 출시되고 있다. 하지만 가격이 고가이면서도 개발환경(컴파일러, 아키텍처, 운영체제)에 의존적이기 때문에 디버깅에 제한이 있다.

이러한 문제점을 해결하기 위해서 본 논문에서는 record and replay 기법을 이용한 효율적인 임베디드 소프트웨어 디버깅 기법을 제시한다.

1. 소프트웨어가 수행 도중, 이벤트(하드웨어 또는 소프트웨어 인터럽트) 발생시, 로그(log) 데이터를 저장함으로서, 나중에 이벤트가 발생했던 상태를 replay 할 수 있다.
2. VPOS[1] 에 포함(built-in) 됨으로서, 타겟 디버깅이 가능하고, replay 시에 디버깅 명령어를 이용하여 버그의 원인을 탐지할 수 있다.
3. 커널(kernel) 레벨에서 record and replay 기법을 사용함으로서, kernel 에 대한 지식이 없는 개발자나 사용자들도 손쉽게 kernel-aware 를 통한 추상화된 kernel 정보를 얻을 수 있다.

임베디드 시스템 상에서 프로그램이 실행될 때 발생하는 이벤트(하드웨어 또는 소프트웨어 인터럽트)마다, 이벤트 로그 데이터를 메모리의 특정 영역에 저장한다. 이후, 실행 도중 익셉션(exception)이 발생하거나, 프로그램 실행이 종료되면, 메모리의 특정 영역에 저장되어 있는 로그 데이터를 플래시 메모리에 저장한다.
타겟 재부팅(reboot) 후에, replay 모드에서 플래시 메모리에 저장된 이벤트 로그 데이터들이 발생한 순서대로 리스트(list)화 되어 출력되고, 여기서 replay 하고자 하는 이벤트를 선택한다. 선택한 이벤트가 발생한 시점에서 PC 레지스터(register)가 가리키고 있던 메모리 주소에 저장되어 있는 명령어 코드는 메모리의 다른 영역에 백업(backup)되고, 여기에 트랩(trap)을 발생시키는 명령어 코드를 삽입한다. 프로그램이 실행되면서, 삽입된 코드에 의해 트랩이 발생하게 되면, 디버깅 명령어를 사용할 수 있는 디버깅 모드로 진입하게 된다. 여기서 명령어를 통해 선택한 이벤트가 발생한 시점의 여러 가지 상태 정보들을 얻을 수 있음으로써 버그의 원인을 탐지할 수 있다.

초기의 record and replay 관련 연구들은 프로그램 실행 중에 발생하는 이벤트 정보와 그에 따른 순서와 내용을 모두 저장하는 방식을 사용했다[2,3]. 이 방법의 경우, 비교적 정확한 replay 를 보장할 수 있다는 장점이 있는 반면, 저장되는 정보의 양이 비효율적으로 커진다는 단점이 있다.
그 이후, 프로그램이 수행 중에 공유 메모리에 접근하는 순서만을 기록하는 방법이나 메시지(message)나 세마포어(semaphore)를 이용한 동기화 이벤트 만을 저장하는 방법이 연구되었다[4,5,6]. 하지만, 프로그램을 정확히 replay 하기 어렵거나, replay 정보를 수집하기 위한 소스코드 삽입으로 인한 탐침 효과가 비교적 커짐에 따라 실제 프로그램 실행과 다른 결과를 초래하였다.
최근에는 소프트웨어적인 접근뿐만이 아니라, 하드웨어 지원을 통해 좀더 정확하고, 효율적인 record and replay 방법이 연구되고 있다[7,8].
본 논문에서는 POSIX API 를 지원하는 VPOS 에 record and replay 기법을 적용하여 소스코드를 변경하지 않고, 임베디드 시스템 환경에서 임베디드 소프트웨어의 결함을 효율적으로 탐지하도록 구현하였다.