소프트웨어 개발이라는 분야는 끊임없이 변하지만, 그 변화의 밑바탕에는 변하지 않는 무언가가 있다. 바로 ‘관계’다. 데이터와 데이터, 함수와 함수, 시스템과 시스템 사이의 관계를 정의하고 다루는 일이 개발자의 본질적 업무라면, 그 관계의 본질을 탐구하는 수학은 언젠가부터 개발자의 사고를 지배하기 시작했다. 그중에서도 범주론은 가장 추상적이면서도 실용적인 도구로 자리 잡았다. 특히 ‘순서’라는 개념은 범주론의 핵심 아이디어 중 하나로, 단순한 크기 비교를 넘어 시스템 전체의 구조를 이해하는 열쇠가 된다.
범주론에서 말하는 순서는 단순히 ‘A가 B보다 크다’라는 이항 관계를 넘어선다. 그것은 두 객체 사이의 방향성을 가진 연결, 즉 ‘화살표’로 표현된다. 이 화살표는 ‘작다’, ‘포함된다’, ‘선행한다’와 같은 다양한 의미를 담을 수 있으며, 그 자체로 하나의 시스템을 형성한다. 예를 들어, 부분 순서 집합(partially ordered set)은 어떤 객체들이 서로 비교 가능한지 여부를 결정하는 규칙을 제공한다. 이는 마치 코드베이스에서 모듈 간의 의존성을 정의하는 것과 닮았다. 어떤 모듈이 다른 모듈에 의존하는지, 혹은 독립적인지를 결정하는 것은 결국 시스템의 구조를 결정짓는 순서와 같다.
이 글에서 흥미로운 점은 순서의 개념이 얼마나 광범위하게 적용될 수 있는지를 보여준다는 것이다. 선형 순서(linear order)는 모든 객체가 서로 비교 가능한 경우를 말하지만, 현실의 시스템은 대부분 부분 순서에 가깝다. 데이터베이스의 인덱스, 버전 관리 시스템의 커밋 히스토리, 심지어 함수형 프로그래밍의 모나드까지, 이들은 모두 어떤 방식으로든 순서에 의존한다. 하지만 그 순서가 항상 명시적인 것은 아니다. 때로는 암묵적으로 존재하며, 개발자가 그 구조를 파악하지 못하면 시스템은 예상치 못한 방향으로 흘러가기 마련이다.
순서는 시스템의 숨겨진 뼈대다. 그것을 이해하지 못하면, 코드는 그저 명령어의 나열에 불과하다.
범주론이 제공하는 통찰은 바로 이런 점에서 빛난다. 순서를 범주의 관점에서 바라보면, 객체와 화살표로 구성된 그래프가 된다. 이 그래프는 시스템의 정적 구조를 시각화할 뿐만 아니라, 동적 변화를 설명하는 도구로도 기능한다. 예를 들어, 함수형 프로그래밍에서 모나드는 일련의 연산을 순서대로 연결하는 구조를 제공하는데, 이는 범주론의 모노이드 개념과 직접적으로 연결된다. 여기서 순서는 더 이상 단순한 비교가 아니라, 연산의 흐름을 결정하는 규칙이 된다.
물론, 범주론이 모든 문제를 해결해주는 만능 열쇠는 아니다. 오히려 그것은 문제를 더 추상적으로 바라보게 함으로써, 해결책을 찾기 위한 새로운 관점을 제공한다. 순서라는 개념을 통해 우리는 코드 속의 계층 구조를 더 명확히 이해할 수 있다. 어떤 함수가 다른 함수보다 ‘먼저’ 실행되어야 하는지, 어떤 데이터가 다른 데이터에 ‘의존’하는지를 결정하는 것은 결국 순서의 문제다. 그리고 그 순서를 제대로 정의하지 못하면, 시스템은 예측 불가능한 행동을 하게 된다.
개발자로서 우리는 종종 기술의 표면적인 기능에만 집중하곤 한다. 새로운 언어의 문법, 최신 프레임워크의 API, 성능 최적화 기법 등등. 하지만 그 이면에 있는 수학적 원리를 이해하려 노력할 때, 비로소 기술은 단순한 도구를 넘어 사고의 확장 도구가 된다. 범주론이 어려운 이유는 그것이 너무나도 근본적이기 때문이다. 순서, 집합, 함수 같은 개념들은 이미 우리가 매일 다루는 것들이지만, 그것들을 범주의 언어로 재해석하는 순간 새로운 세계가 열린다.
이 글은 그런 재해석의 과정 중 하나를 보여준다. 순서라는 일상적인 개념이 어떻게 수학적 구조로 변모하고, 다시 코드의 설계 원칙으로 이어지는지를 설명한다. 개발자에게 필요한 것은 더 많은 라이브러리가 아니라, 이런 근본적인 이해일지도 모른다. 시스템을 설계할 때, 우리는 무의식적으로 범주론의 언어를 사용하고 있다. 다만 그것을 명시적으로 인식하지 못할 뿐이다.
더 읽어보고 싶다면, 여기에서 원문을 확인할 수 있다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
