개발자에게 진짜 필요한 수학은 논리학입니다 — 《Logic for Programmers》

“개발자한테 수학이 필요하냐”는 논쟁, 커뮤니티에서 한 번쯤 보셨을 거예요. 미적분이나 선형대수는 솔직히 머신러닝이나 그래픽스 같은 특정 분야가 아니면 쓸 일이 잘 없죠. 그런데 딱 하나, 모든 개발자가 매일같이 쓰면서도 제대로 배운 적은 없는 수학이 있어요. 바로 논리학인데요. 이걸 정면으로 다룬 《Logic for Programmers》라는 책이 있어서 소개해요. 저자는 형식 명세 도구 TLA+의 실무 입문서를 쓴 힐렐 웨인(Hillel Wayne)으로, “수학을 위한 수학”이 아니라 “내일 출근해서 바로 써먹는 논리학”을 표방하는 책이에요.

조건문을 다루는 기술, 명제 논리

책의 출발점은 명제 논리예요. AND, OR, NOT — 우리가 if문에서 매일 쓰는 그거요. “이걸 뭘 배워?” 싶으시겠지만, 막상 부정이 섞이면 다들 헷갈리기 시작하거든요. !(isAdmin && isActive)가 !isAdmin || !isActive와 같다는 드모르간 법칙을 몸에 익혀두면, 몇 겹으로 꼬인 조건문을 자신 있게 뒤집고 단순화할 수 있어요. 리팩토링하다가 “이 조건 뒤집어도 진짜 같은 거 맞나?” 하고 불안해서 원래 코드를 못 건드린 경험, 다들 있잖아요. 그게 바로 논리학 훈련이 없어서 생기는 비용이라는 거죠. early return으로 중첩을 풀어내는 것도 결국 조건의 부정을 정확히 다루는 기술이고요.

“모든”과 “어떤” — 술어 논리

한 단계 올라가면 술어 논리가 나와요. 이게 뭐냐면, “모든 X에 대해(∀)”와 “어떤 X가 존재한다(∃)”를 다루는 논리인데요. 사실 우리가 시스템을 설계할 때 세우는 규칙이 전부 이 형태예요. “모든 주문에는 유효한 결제 수단이 연결되어 있다”, “관리자 계정이 적어도 하나는 존재한다” 같은 것들이요. 이런 걸 불변식(invariant)이라고 부르는데, 시스템이 어떤 상태에 있든 항상 참이어야 하는 조건이라는 뜻이에요. 버그의 상당수는 결국 불변식이 깨진 상태거든요. 규칙을 머릿속 느낌으로만 갖고 있는 것과 논리식으로 명확히 적을 수 있는 것의 차이가, 설계 실력의 차이로 이어진다는 게 책의 주장이에요.

논리가 도구가 되는 순간들

이 책이 좋은 건 이론에서 멈추지 않는다는 점이에요. 논리를 실제 도구로 연결해줘요. 대표적인 게 속성 기반 테스트(property-based testing)인데요. 예제 입력을 하나하나 만드는 대신 “정렬 함수의 출력은 항상 오름차순이다” 같은 성질을 쓰면, Hypothesis(파이썬)나 fast-check(자바스크립트) 같은 라이브러리가 수백 개의 입력을 자동 생성해서 그 성질을 깨는 반례를 찾아줘요. 그 밖에도 데이터베이스 제약조건 설계, 사전조건과 사후조건을 명시하는 계약(assertion), 복잡한 비즈니스 요구사항을 빠짐없이 표로 정리하는 의사결정 테이블, 그리고 TLA+나 Alloy 같은 형식 명세 도구까지 — 전부 논리학이라는 하나의 뿌리에서 나온 도구들이라는 걸 보여줘요.

왜 하필 지금일까요

형식 기법은 오랫동안 학계의 전유물이었지만, AWS가 TLA+로 S3와 DynamoDB의 설계 결함을 출시 전에 잡아낸 사례가 알려지면서 실무 도구로 재평가받고 있어요. 그리고 개인적으로는 AI 코딩 시대라서 더 중요해졌다고 봐요. LLM에게 코드를 맡기는 시대에 개발자의 핵심 역량은 코드를 치는 속도가 아니라 요구사항을 애매함 없이 표현하는 능력으로 옮겨가고 있잖아요. “이 함수는 어떤 입력에서든 이 성질을 만족해야 해”라고 정확히 말할 수 있는 사람이 AI를 제대로 부리는 거고, 그 근육이 바로 논리학이거든요.

정리하면

논리학은 배워두면 조건문 리팩토링, 테스트 설계, 코드 리뷰에서의 커뮤니케이션까지 두루 좋아지는 가성비 좋은 기초 체력이에요. 여러분은 조건문을 뒤집을 때 확신을 갖고 하시나요, 아니면 테스트가 통과하길 기도하시나요? 실무에서 논리가 부족해서 고생했던 순간이 있다면 공유해 주세요.