더북(TheBook)

인공지능(AI)이 발전함에 따라 소프트웨어의 신뢰성 문제가 더 중요해졌다. 항공기의 운항이나 자동차의 자율주행 등 프로그램이 인간의 삶을 망가뜨릴 수 있는 결정을 내릴 수 있다면 그것이 우리 의도대로 제대로 작동한다는 사실을 확실히 해야 한다.

프로그램을 더 안전하게 만들려면 어떻게 해야 할까? 훌륭한 프로그래머가 필요하다고 대답하는 사람도 있을 것이다. 프로그래머에게 물어보면, 전체 프로그래머 중 단 10%만이 훌륭한 프로그래머라고 답하는 사람이 90%나 되며 그와 동시에 프로그래머 중 90%는 자신이 그 10%의 훌륭한 프로그래머에 속한다고 대답한다!

프로그래머에게 가장 필요한 자질은 자기 자신의 한계를 깨닫는 것이다. 우리는 자신이 기껏해야 평균적인 프로그래머에 지나지 않는다는 사실을 직시해야 한다. 우리는 전체 시간 중 20%를 버그가 있는 프로그램을 작성하는 데 소비하고, 40%를 버그가 있는지 없는지 확실치 않은 코드를 리팩터링(refactoring)하는 데 사용하며, 나머지 40%를 프로덕션(production)에 이미 들어 있는 코드를 디버깅하는 데 사용한다. 버그에는 눈에 띄는 분명한 버그와 눈에 띄지 않는 불분명한 버그가 있기 때문이다. 하지만 불분명한 버그가 나중에 분명한 버그로 자신을 드러낸다는 사실은 확실하다(다만 그 모습을 드러낼 때까지 얼마나 시간이 걸릴지가 문제일 뿐이다). 여기서 버그가 분명해지기까지 얼마나 오랫동안, 얼마나 많은 해악을 끼칠 것인가 하는 문제가 남는다.

이 문제를 어떻게 다룰 수 있을까? 현재까지 나온 그 어떤 프로그래밍 도구, 기법, 훈련 방식도 프로그램에서 버그를 완전히 없애지는 못한다. 하지만 특정 유형에 속하는 버그는 없앨 수 있고, 없애지 못하고 남은 버그가 프로그램에서 별도로 구분된(안전이 보장되지 않는) 영역에서만 일어난다고 보장할 수 있는 프로그래밍 기법도 여럿 있다. 이런 기법을 사용하면 버그를 더 쉽고 효율적으로 잡을 수 있기 때문에 프로그래밍에서 아주 큰 차이가 나타난다. 예를 들어 버그의 존재를 증명하지 못할 정도로 프로그램을 복잡하게 짜는 대신, 버그가 없음이 명확히 보이는 단순한 프로그램을 작성하는 방법이다.3

이 장의 나머지 부분에서는 불변성(immutability), 참조 투명성(referential transparency), 치환 모델(substitution model) 등을 설명하면서 몇 가지 권장할 만한 코딩 기법을 보여준다. 설명한 기법을 함께 활용하면 여러분의 프로그램을 더 안전하게 만들 수 있다. 이런 개념을 이 책에서는 반복 적용할 것이다.

 

 


3 “… 소프트웨어를 설계하는 데는 두 가지 방법이 있다. 한 가지 방법은 설계를 아주 단순화해서 결함이 없음을 확실히 알 수 있도록 만드는 것이고, 또 다른 방법은 설계를 아주 복잡하게 만들어서 결함이 있는지 확실히 알 수 없도록 만드는 것이다.” ACM 소식지(Communications of the ACM) 24권(1981년 2월) 75~83페이지에 실린 C.A.R 호어(Hoare)의 “황제의 낡은 옷(The Emperor’s Old Clothes)”을 참고하라.

신간 소식 구독하기
뉴스레터에 가입하시고 이메일로 신간 소식을 받아 보세요.