AI가 코드를 대신 써주는 시대에, 나는 오히려 실패를 더 빨리 드러내는 방법을 배워야 한다고 느꼈습니다.
The Pragmatic Programmer 4장은 그 감각을 아주 분명하게 말합니다.
좋은 코드는 실패하지 않는 척하는 코드가 아니라, 실패가 생겼을 때 조용히 썩지 않도록 말하게 만드는 코드입니다.
이 장의 제목은 Pragmatic Paranoia입니다.
말 그대로 실용적인 편집증입니다.
하지만 여기서 편집증은 불안이 아닙니다.
시스템은 언젠가 실패한다는 사실을 인정하는 태도입니다.
입력은 틀릴 수 있고, 네트워크는 끊길 수 있고, 내 가정은 틀릴 수 있습니다.
문제는 실패 자체가 아니라 실패를 감추는 구조입니다.
가장 크게 남은 개념은 계약입니다.
함수와 모듈은 서로 기대하는 것이 있고, 보장해야 하는 것이 있습니다.
이것이 불분명하면 사람도 헷갈리고 AI 에이전트도 함부로 고칩니다.
반대로 precondition과 postcondition이 분명하면, 코드는 작은 약속들의 네트워크가 됩니다.
나는 이 장을 읽으며 내 블로그 자동화와 에이전트 작업을 떠올렸습니다.
자동 배포가 실패했을 때 조용히 넘어가면 안 됩니다.
음원이 빠졌다면 글에 표시되어야 하고, 링크가 깨졌다면 배포 전에 멈춰야 합니다.
빠른 실패는 사용자에게 불친절한 것이 아니라, 더 큰 손상을 막는 친절입니다.
또 하나 남은 것은 자원 관리입니다.
열었으면 닫아야 합니다.
빌렸으면 돌려줘야 합니다.
이것은 파일과 메모리만의 이야기가 아닙니다.
시작하고 닫지 않은 작업, 검증하지 않은 TODO, 중간에 멈춘 자동화도 마음의 자원을 계속 붙잡습니다.
오늘 내가 적용할 행동은 단순합니다.
핵심 함수 하나에 기대와 보장을 적고, catch-all 예외 하나를 더 좁게 만들고, 열고 닫는 자원 패턴을
테스트로 확인하는 것입니다.
실용주의 개발자는 실패를 부정하지 않습니다.
실패가 말할 수 있는 구조를 만듭니다.