와, 얼마만의 정식(?) 블로그 포스팅인지 모르겠다.

요 근래 OS 프로젝트를 하느라 거의 밤샘하다시피하면서 폐인 생활을 계속했었는데, 딱 하나 잘못 생각했던 것 때문에 거의 2일 이상을 날려먹었음을 깨닫고 그동안 짰던 priority donation 코드를 싹다 버리고 새로 짰다. -_- 2일 동안 밤새서 만든 코드보다 양도 더 적고 버그도 적었다.

그렇다면 그동안 했던 삽질이 헛수고냐라고 묻기 쉬운데 잘 생각해보면 꼭 그런 것 같지만은 않다. 그렇게 삽질을 하면서 어떤 버그나 문제가 발생했을 때 잠재적인 원인을 유추하는 스킬이 생기고 특히 이번 프로젝트를 통해 gdb 사용법을 좀더 자세히 알게 되었다.

어제의 작업 화면. 현재 버전에선 가운데 화면의 코드 중 절반 이상이 바뀌었다.

OS 커널 코딩은 SP 때와 상당히 다른 느낌이다. SP 때는 코딩량 자체가 많았지만, OS는 코딩량은 얼마 안 되어도(Pintos 처음 코드와 현재 내가 고친 코드를 diff 뜬다면 아마 100줄 정도밖에 안 바뀌었을 것이다) 한줄 한줄의 의미와 영향력이 엄청나게 중요해서 정말로 생각을 많이 해야 한다. 모니터를 보며, vi의 ctags로 이리저리 돌아다니며 계속 생각하고 모델링해야 하는 것이다. 또한 내가 처음부터 만드는 프로그램이 아니고 이미 Pintos라는 주어진 OS 골격 안에서 프로그램을 짜야 하기 때문에 다른 사람이 만들어둔 소스를 읽는 스킬도 중요한 것 같다.

SP를 들으며 "Segmentation Fault"에 익숙해졌다면 OS를 진행하면서 "Kernel Panic"에 익숙해졌다. -_- 이제 블루스크린이나 커널패닉이 떠도 개발자가 얼마나 고생했을까 하는-_- 동병상련(?)의 마음이 들 것 같다; 물론 데이터 날려먹으면 화는 나겠지만..;;

SP와 OS를 들으며 느끼는 거지만, 큰 규모의 디버깅이 힘든 프로그램을 짤 때는 다음을 꼭 지켜야 하는 것 같다.

• 하다가 막히면 일단 쉬자. 게임을 한판 하든 산책을 하고 오든 잠을 자든 다른 짓을 하고 다시 보면 새로운 아이디어가 떠오르는 경우가 많다.
• 오랫동안 짠 코드라고 버리기를 아쉬워하지 말자. 보다 나은 설계가 있다면 최대한 빨리 적용하고 테스트해보자. (물론 만일에 대비하여 버전관리 시스템을 사용하는 것을 권장한다)
• 잘 이해가 안 되는 부분이 있다면 다른 사람에게 물어보거나 같이 토론하는 것이 큰 도움이 된다. 직접적으로 답을 제시받지 못하더라도 남에게 설명하기 위해 스스로 문제를 정리하게 되기 때문이다.

이제 오늘 중으로 18개의 test-case 중 남은 2개에 해당하는 nested donation 구현만 끝낸다면 1번 프로젝트는 끝난다. 그러나 2번 프로젝트는 훨씬 더 많은 test-case가 기다리고 있다는 소문이..... OTL