코드 리뷰를 하다가 함수 하나를 이해하려고 파일 열두 개를 넘나든 경험, 다들 있으시죠? 프로그래밍 언어 연구자 로렌스 트랫(Laurence Tratt)이 이 문제를 정면으로 다루는 글을 올렸어요. 제목이 "전역적 속성을 위한 지역적 추론(Local Reasoning for Global Properties)"인데요, 좋은 언어와 좋은 설계가 공유하는 핵심 원리를 한 문장으로 꿰뚫는 개념이라 소개해보려고 해요.
지역적 추론, 이게 뭐냐면
지역적 추론(local reasoning)이란, 지금 눈앞에 보이는 코드 조각만 읽고도 그 동작을 정확히 이해하고 확신할 수 있는 능력을 말해요. 반대는 전역적 추론이겠죠. 이 함수가 뭘 하는지 알려면 호출하는 쪽, 호출되는 쪽, 저 멀리 있는 전역 변수, 심지어 다른 스레드에서 벌어지는 일까지 다 살펴봐야 하는 상황이요. 코드베이스가 커질수록 전역적 추론의 비용은 감당이 안 되게 불어나요. 사람 머리는 한 번에 담을 수 있는 맥락의 양이 정해져 있으니까요.
그런데 재미있는 역설이 하나 있어요. 우리가 정말 보장하고 싶은 것들은 대부분 전역적 속성이거든요. "이 프로그램은 절대 해제된 메모리를 건드리지 않는다", "두 스레드가 같은 데이터를 동시에 수정하는 일은 없다", "이 계좌 잔액은 절대 음수가 되지 않는다" 같은 것들이요. 이런 속성은 프로그램 전체에 걸쳐 성립해야 의미가 있어요. 그럼 전체를 다 봐야 확인할 수 있는 성질을, 부분만 보고 어떻게 보장할 수 있을까요?
지역 규칙이 전역 보장을 만드는 마법
답은 이거예요. 언어나 설계가 잘 고른 지역 규칙을 강제하면, 모든 코드가 각자 자기 자리에서 그 규칙만 지켜도 전역 속성이 저절로 따라오게 만들 수 있다는 거죠. 가장 극적인 예가 러스트의 소유권 시스템이에요. 러스트 컴파일러는 함수 하나를 검사할 때 프로그램 전체를 보지 않아요. 그 함수 안에서 빌림 규칙, 그러니까 하나의 값에 대해 수정 가능한 참조는 동시에 하나만 존재해야 한다는 규칙이 지켜지는지만 봐요. 그런데 모든 함수가 이 지역 검사를 통과하면, 프로그램 전체에 데이터 레이스가 없다는 전역적 보장이 따라와요. 부분의 검사가 모여서 전체의 증명이 되는 구조인 거죠.
타입 시스템도 같은 원리예요. 함수 시그니처가 "문자열을 받아 정수를 돌려준다"라고 선언하면, 호출하는 쪽은 함수 내부 구현을 안 봐도 되고, 함수 쪽은 호출자가 누군지 몰라도 돼요. 시그니처라는 경계에서 약속을 검사하는 것만으로 프로그램 전체의 타입 안전성이 조립되니까요. 캡슐화도 마찬가지예요. 클래스의 필드를 private으로 감추고 메서드로만 접근하게 하면, "이 리스트는 항상 정렬된 상태다" 같은 불변식을 깨뜨릴 수 있는 코드가 그 클래스 안으로 한정돼요. 불변식이 지켜지는지 확인하려고 코드베이스 전체를 뒤질 필요 없이 파일 하나만 꼼꼼히 보면 되는 거예요.
반대로 지역적 추론을 파괴하는 대표 주자들도 떠올려보세요. 아무 데서나 읽고 쓰는 전역 변수, 여러 모듈이 공유하는 가변 상태, 어디서 잡히는지 알 수 없는 예외 같은 것들이요. 이런 것들이 코드를 어렵게 만드는 진짜 이유는 문법이 복잡해서가 아니라, 코드를 이해하는 데 필요한 맥락의 반경을 무한대로 넓혀버리기 때문이에요.
한국 개발자에게 주는 시사점
이 개념은 언어 선택을 넘어 일상적인 설계에 바로 적용할 수 있어요. 코드 리뷰나 설계 회의에서 "이 코드를 이해하려면 얼마나 멀리까지 봐야 하지?"라는 질문을 던져보세요. 모듈 경계를 정하고, 인터페이스를 좁히고, 상태를 바꾸는 지점을 한곳으로 모으는 결정들이 전부 지역적 추론의 반경을 줄이는 작업이거든요. 마이크로서비스 사이의 API 계약, 함수형 스타일에서 순수 함수를 선호하는 트렌드도 결국 같은 뿌리에서 나온 거고요. 새 언어나 프레임워크를 평가할 때도 "이게 지역적 추론을 도와주는가"를 기준으로 삼으면 유행 너머의 본질이 보여요.
한줄 정리: 좋은 언어와 좋은 설계는 개발자가 지역 규칙만 지키면 전역적 안전이 저절로 따라오도록 만든다. 여러분의 코드베이스에서 지역적 추론을 가장 심하게 방해하는 범인은 뭔가요?
🔗 출처: Hacker News