이 글이 다루는 시기: 2012년 8월 ~ 10월

= 첫 버전 공개로부터 2개월까지

나래온 첫 버전은 아니고, 2번째 버전

군 생활에 바쁘다 보니, 이번 글도 또 기억이 아슬아슬해질 즈음에 쓰게 되었다.
이번 글은 초기의 버그들에 대해서 다루려고 한다.

조합이 문제가 되는 경우가 많은 현재와 달리(즉 n가지 조건이 모두 갖추어져야 재현이 가능한 버그), 초기에는 프로그램 자체가 잘못 만들어져 나오는 버그가 많았다. 고백하자면 그 당시에는 프로그래밍 실력이 지금에 비해 많이 부족했을 뿐더러, 단위 테스트가 무엇인지도 몰랐기 때문이다. 회고하건대 3.0이 나오기 전까지 일어난 버그들은 단위 테스트를 충실히 했을 시 해결이 가능한 버그들이 대부분이었다.

https://archive.is/gl248
3.0 정도까지의 버전 기록을 볼 수 있는 페이지. ncity 상황이 좋지 않아 아카이브함.

예를 들어서 감시쪽 버그가 그러한데, 즉시 켜서 이것저것 찔러볼 수 있는 메인 프로그램과 달리, 감시 프로그램은 즉시 확인해볼 수가 없지 않은가. 그래서 감시 프로그램 버그는 한참 뒤에 발견되는 경우가 적지 않았다. 그러나 감시 프로그램 주요 부분이 단위 테스트에 포함된 건 당시로부터 2년 4개월 후였다.

유닛 테스트로 방지할 수 있었던 단순 실수가 아닌 조합 버그로는, V3 lite, QSoft 램디스크, AS SSD Benchmark 버그가 있었다. V3 lite는 권한을 필요한 만큼만 가져다 쓰게 만들어서 해결. QSoft 램디스크는 어떤 명령을 던져도 뻗는 버그가 있었으므로 볼륨명으로 확인해서 피해가는 걸로 반쪽짜리 해결(하지만 이게 최선이였다). AS SSD Benchmark 버그는 핸들을 최소 시간 만큼만 들고 있다가 닫게 만들어서 해결하였다.

그 밖에 구조적인 문제도 있었다. 각 메소드들의 공개 수준이 적절치 않았으며, 슈퍼 클래스, 슈퍼 유닛을 남발했다. 이 문제는 결국 5버전에서 거의 처음부터 다시 쌓아 올리는 방식으로 교정이 된다. 당시에는 거의 혼자 사용할 목적으로 만들어진 2K 내외의 프로그램이었으니 문제가 없었으나, 나중에는 10K 단위의 프로그램으로 성장하면서 문제가 되었던 것이다.