오늘 TIL 3줄 요약

• 여러분은 완벽한 소프트웨어를 만들 수 없다.

• 계약으로 설계하라.(DBC, Design By Contract)

• 자신이 시작한 것은 자신이 끝내라.

TIL (Today I Learned) 날짜

2022. 05. 19

오늘 읽은 범위

4장. 실용주의 편집증

책에서 기억하고 싶은 내용을 써보세요.

• 우리는 방어적으로 코딩하라고 배운다. 만약 조금이라도 의심이 들면 주어진 모든 정보를 확인한다. 잘못된 데이터를 찾아내기 위해 단정문을 사용하고, 공격자나 불량 사용자가 만들었을지도 모르는 데이터를 불신한다.

• 실용주의 프로그래머는 자기 자신 역시 믿지 않는다. 어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 실용주의 프로그래머는 자신의 실수에 대비한 방어책을 마련한다.

• DBC는 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다. 정확한 프로그램이란 무엇인가? 자신이 하는 일이라고 주장하는 것보다 많지도 적지도 않게 딱 그만큼만 하는 프로그램이다. 이 주장을 문서화하고 검증하는 것이 '계약에 의한 설계'의 핵심이다.

• 만약 계약 당사자 중 어느 한쪽이라도 이 계약 내용을 지키지 못하면(이전에 양측이 동의한 내용에 따라) 해결 방안이 실행된다. 예외가 발생할 수도 있고 아니면 프로그램을 종료시킬 수도 있다. 무슨 일이 벌어지든지 확실한 점은 계약에 부응하지 못하는 것은 버그라는 것이다. 이것은 결코 발생해서는 안 되는 일이며, 그렇기 때문에 선행 조건을 이용해서 사용자입력값을 검증한다거나 해서는 안 된다.

• 우리는 '부끄럼쟁이' 코드를 작성하라고 권했다. 이번에는 '게으름뱅이' 코드를 강조하고 싶다. 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다. 무엇이든 수용하고 결과로는 무엇이든 다 준다고 계약에 쓰여 있다면, 여러분은 정말이지 많은 코드를 작성해야 할 것이다!

• 문제를 찾고 원인을 밝히기 위해서는 사고가 난 지점에서 일찍 멈추는 것이 유리하다.

• 어겨서는 안 되는 고정된 규칙인 요구사항과 경영진이 바뀌면 얼마든지 없어질 수 있는 단순한 정책을 혼동하지 말아야 한다. 의미론적 불변식은 무언가가 품은 진짜 의미의 중심이 되어야 하며, 훨씬 역동적으로 변하는 비즈니스 규칙처럼 일시적인 정책에 영향을 받으면 안 된다. 우리가 의미론적 불변식이라는 용어를 사용하는 것은 이 때문이다.

• '그런 일은 절대 일어날 리 없어.'라는 사고에 빠지기 쉽다. 우리 중 대다수가 코드를 작성할 때 파일이 성공적으로 닫혔는지, 혹은 트레이스 문이 우리 예상대로 찍혔는지 확인하지 않았던 적이 있을 것이다. 그리고 다른 모든 조건이 늘 그대로라면 그럴 필요가 없었을지도 모른다. 문제의 코드는 정상적인 상황에서는 실패하지 않았을 것이다. 하지만 우리는 지금 방어적으로 코딩하고 있다. 데이터가 우리가 생각하는 대로인지, 서비스에서 작동하는 코드가 우리가 생각하는 그 코드인지 확인해야 한다. 필요한 라이브러리들이 올바른 버전으로 실제로 로드됐는지도 확인해야 한다.

• 모든 오류는 정보를 준다. 여러분은 오류가 발생할 리 없다고 자신을 설득하고선 그걸 무시하기로 할 수 도 있다. 반면에 실용주의 프로그래머는 만약 오류가 발생했다면 정말로 뭔가 나쁜 일이 생긴 것이라고 자신에게 이야기한다.

• 가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다. 게다가 프로그램을 멈추는 것이 할 수 있는 최선인 경우가 흔하다. 방금 있을 수 없는 일이 발생했다는 것을 코드가 발견했다면 프로그램은 더는 유효하지 않다고 할 수 있다. 이 시점 이후로 하는 일은 모두 수장쩍은 게 된다. 되도록 빨리 종료할 일이다. 일반적으로 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다.

• '그런 일은 절대 일어날 리 없어'라고 자신을 기만하지 말자. 그런 일이 절대 일어나지 않을 거라는 생각이 든다면 그런 일을 확인하는 코드를 추하가라. 단정문을 사용하라. 다만 주의하라. 문제를 발견하려고 넣은 코드가 오히려 문제를 만들 수 있다.

• 자신이 시작한 것은 자신이 끝내라. 리소스를 할당하는 함수나 객체가 리소스를 해제하는 책임 역시 져야 한다는 뜻일 뿐이다.

• 언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. '너무 큰'단계나 작업은 하지 않게 될 것이다.

• 너무 큰 작업은 무엇일까? '예언'을 해야 하는 모든 작업이다. 자동차 헤드라이트로 비출 수 있는 거리에 한계가 있는 것 처럼 우리도 한두 단계 앞의 미래만 내다볼 수 있다. 끽해야 몇 시간이나 며칠 정도일 것이다. 그 너머는 경험에 기반한 추측을 벗어난 무모한 억측의 영역이다.

• 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 4장 까지 읽으면서 이 책이 말하는 것이 무엇인가에 대해서 드는 생각은 실용주의 프로그래머란 낙관을 경계하고, 효율적이게 행동하라는 것이다.

• 효율은 목적과 맥락에 따라 달라지는 것이다. 우리는 가시적인 결과값에 현혹되어 그것이 가장 효율적이라고 단정짓는 오류에 빠지기 쉽다. 그러나 그것이 모든 상황에서 통용되는 것은 아니다. 우리는 전능하지도 전지하지도 않다. 완벽하지 않다는 이야기다. 완벽하지 않다는 것을 인정한다면 우리는 언제 어떤 상황이 일어나지 않아도 이상하지 않다는 것을 인정할 수 있다. 그렇다면 그 상황에 대비하기 위해서는 어떻게 해야 하는가가 4장이 이야기하고자 하는 핵심이라는 생각이 든다.

• 이는 개발 외적인 부분과 연관지어 생각할 수 있지 않을까? 블랙박스가 보편화 된 이후 급발진 사고에 대한 기록이 유튜브에 올라와 종종 본 적이 있다. 자동차가 운전자의 통제를 벗어나 급발진하고 이후 통제가 먹히지 않는 것은 자동차를 설계한 사람도, 운전자도 전혀 예상하지 못하고 일어나서는 안될 일이다. 그런 일이 일어날 리 없다고 생각할 수 있다. 그럼에도 이미 일은 일어나지 않은가? 이후 급발진의 원인을 분석해 본다면 정말 사소한 것들이 원인이 되는 경우가 많다. 구글에 자동차 급발진 원인이라고 검색해서 나오는 사례들만 하더라도 정말 사소한 것들이 원인이지만, 쉽게 여기고 넘어가기 쉬운 문제들이다. 4장에서 말하는 단정법은 이와 관련되어 좀 더 확실히 하고 넘어가는 방법이라는 느낌이 든다. 사고는 예상할 수 없기 때문에 사고인 것이다. 예상할 수 있다면 그것은 더 이상 사고가 아니라 문제를 방치한 잘못이 아닌가?

• 때로는 돌아가는 것이 바로 가는 것 보다 더 나을때가 있다. 프로그램의 구동 속도 측면에서 단정법은 비효율적이라고 생각할 수 있지만, 안정성의 측면에서 본다면 단정법은 프로그램이 안정적으로 구동하고 예상하지 못한 문제의 해결을 도와줄 수 있는 보험이다. 우리도 암이나 사고가 일어날 것이라고 가정하고 보험을 드는 것은 아니지 않은가? 일어나면 안될 일이 일어났을 때 해결하기 위해서 비싼 돈을 주고 보험을 드는 것이 아닌가? 보험을 들지 않아도 일이 일어나지 않는다면 괜찮지만 일이 일어났을때는 더 큰 문제가 발생하지 않는가? 만약의 사태에 대비하는 것은 언제나 옳다.

• 그렇다고 해서 모든 일에 보험을 드는 것은 다시 비효율적인 일이다. 그러니 보험을 들어야 할 곳과 보험을 들지 않아야 할 곳을 정확하게 구분하고 판단해야 한다. 그러기 위해서는 도구를 잘 사용하고, 도구에 익숙해야 하며, 보다 나은 도구들에 대해 배워가야 한다. 예측은 더 많은 도구들을 사용함으로써 보다 정교해지고, 도구의 목적에 맞는 곳에 적절하게 도구를 사용해야 오류를 예방할 수 있다. 이는  곧 3장과 2장의 내용과 연결된다는 생각이 든다. 매 장을 읽으면서 이 전의 장과 연관지어 생각하기에 점점 글을 쓰는 것이 벅차다는 생각이 들지만 이것이 독서의 매력이 아니겠는가. 결과적으로 추후에 이 책을 읽는 챌린지를 끝마쳤을때 나는 이 책이 말하고자 하는 것이 무엇인가에 대해서 잘 이해할 수 있겠다는 생각이 든다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

오늘 읽은 다른사람의 TIL