공룡호가 사는 세상 이야기

사용자 삽입 이미지
앞서 리뷰했던 메모리 관련 Article과 관련 있는 기사를 한번 더 보고자 한다.
프로그래밍에서 메모리 결함은 대부분 잘못된 코딩 습관에서 온다고 언급했었다.
사실, 메모리 결함 뿐 만이 아니다. 모든 오류나 결함은 마찬가지이다.
같은 맥락에서, 이번 Article을 읽다가 인상 깊은 구절을 발견했다.
C 프로그램에서 컴파일 옵션에 -O -Wall -W -Wshadow -pedantic을 사용하면, 소스코드에서 올바르지 않거나 의심스러운 부분진단 메시지로 날려준다.

많은 개발팀이 컴파일러가 제공하는 진단 결함을 불치병이나 세금처럼 필요악으로 취급한다.

내 경험으로는 아무리 잘 관리해도 진단 메시지를 무시하는 50만 줄짜리 프로젝트는 오류가 적어도 5000개 정도 존재한다. 물론, 그 중 적어도 몇 개 정도는 자주 발생하는 오류로 드러난다. 결코 음수가 되지 않는 unsigned 정수를 조건으로 사용하거나, 선언한 변수에 철자 오류가 있어 전혀 사용되지 않는 경우 등이다. 모든 컴파일러 진단 메시지를 하나씩 없애가는 과정에서 코드 품질은 극적으로 향상된다. 컴파일러 진단 메시지는 자동화하기가 쉬우므로 비용도 적게 든다

사실, 그렇지 않은가 Error는 수정하지 않으면, 컴파일을 할 수 없으므로 어쩔 수 없이 하게 되지만, Warnning은 그냥 지나치기 일쑤다. 지나치다 보면 이제 손대기 귀찮고 짜증날 정도로 많아지게 되고, 나중엔 아예 손을 쓰기조차 어려워진다. 그래도 컴파일은 된다. 기대하는 대로 작동한다. 하지만 오류는 언제나 잠재 해 있다는 것이 문제이다.

메모리 오류에 한정되어 있지만, 이는 굉장히 중요한 문제이다.
컴파일 옵션을 주어 모든 진단 메시지를 확인하고 그에 따른 진단 과정을 살펴보면서, 올바른 코딩 습관에 대해 다시 한번 더 생각 할 기회와 메모리 오류에 대해 진단하고 해결하는 과정도 함께 익힐 수 있을 것 같다. 코드 품질을 극적으로 높이는 관건은 기술적 혁신이 아니라 문화적인 혁신이다. 맞는 말이다.



메모리 오류
때문에 고생한 적이 한 두번이 아니다. Syntax 오류가 아니라서 더더욱 잡아내기 힘들고, 특수한 상황 설정을 해 놓고 체크하지 않는 한 발견해 내기도 힘들다. 또, 시스템에 따라 발생하는 시기 또한 달라질 수 있어 여간 짜증나는 오류가 아닐 수 없다. 릴리즈 단계까지 발견되지 않는 경우도 있고, 심지어 모 회사 입사시험에도 나왔었다. 메모리 누수가 일어나는 것을 효과적으로 잡아 낼 방법은? 하고 말이다.

메모리 오류의 유형은 1.메모리 누수, 2.할당 오류, 3.dangling 포인터, 4.배열 경계 위반 등이 있는데, 이는 객체지향 언어에서도 크게 다르지 않다.
Article에서는 오류 각각의 케이스 별 예제코드와 그 대처법에 대해서 다루고 있다. 여기서 설명하고 있는 것들로 메모리 오류를 모두 방지할 수는 없다. 하지만, 메모리 오류의 각 케이스를 알고, 그에 대한 일반적인 대처방안, 메모리 도구 등 메모리 프로그래밍의 전략을 익히는 데는 꽤 괜찮은 기사가 아닐까 싶다.

기사 내용에도 언급이 되어 있지만, 대부분의 프로그램 오류는 잘못된 코딩 습관에서 비롯된다(그것은 협업에서도 마찬가지이다). 리뷰라고 할 것 까지도 없지만, 나는 주로 학생 개발자들의 수준에 맞추어 Article을 선택한다. 습관이라는 것은 그게 무엇이든 한 번 굳어지면 고치기 힘들다. 현업에서 개발을 꿈꾸는 많은 학생 개발자들이 올바른 코딩 습관을 기르는 데 조금이나마 도움이 되었으면 좋겠다.

메모리 디버깅 기법(바로가기)