수학 '범주론'으로 데이터베이스를 다룬다고? CQL 들여다보기

좀 낯설지만 흥미로운 시도

데이터베이스라고 하면 보통 SQL을 떠올리잖아요. 테이블 만들고, 조인하고, 쿼리 날리고요. 그런데 여기, 데이터베이스를 완전히 다른 시각, 즉 수학의 범주론(category theory)으로 바라보는 도구가 있어요. 바로 CQL(Categorical Query Language)이에요. 이름부터 좀 진입장벽이 있지만, 아이디어 자체는 꽤 매력적이거든요.

범주론이 뭐냐면

겁먹지 말고 들어보세요. 범주론은 "대상(object)들과 그 사이의 화살표(연결, morphism)"를 가지고 세상을 설명하는 수학이에요. 핵심은 점 하나하나가 뭔지보다 "점들이 어떻게 연결돼 있는가"에 집중한다는 거예요.

이걸 데이터베이스에 대입하면 그림이 딱 그려져요. 테이블(예: 직원, 부서)을 "대상"으로 보고, 테이블 사이의 관계(직원은 어떤 부서에 속한다 같은 외래키)를 "화살표"로 보는 거예요. 그러면 데이터베이스의 스키마(구조 설계도) 자체가 하나의 "점과 화살표로 이뤄진 그림"이 되는 거죠. CQL은 바로 이 그림을 수학적으로 엄밀하게 다뤄요.

뭐가 다른가요 — '데이터 마이그레이션'이 핵심

CQL이 가장 빛나는 지점은 데이터 마이그레이션(data migration), 즉 한 구조의 데이터를 다른 구조로 옮기는 작업이에요. 실무에서 제일 골치 아픈 일 중 하나가 "옛날 DB 구조에서 새 구조로 데이터를 안전하게 옮기기"잖아요. 컬럼을 합치고, 테이블을 쪼개고, 관계를 바꾸다 보면 데이터가 새거나 망가지기 쉽거든요.

CQL은 두 스키마(그림) 사이의 "대응 관계"를 함자(functor)라는 수학적 사상으로 정의해요. 함자가 뭐냐면, 한 그림의 점과 화살표를 다른 그림의 점과 화살표로 "구조를 망가뜨리지 않고" 옮겨주는 규칙이에요. 이 대응을 한번 제대로 정의해두면, 데이터 변환이 수학적으로 일관성이 보장된 채로 자동 실행돼요. "옮기다 보니 어떤 직원의 부서가 사라졌다" 같은 무결성 깨짐을, 코드를 일일이 검사하는 대신 이론 차원에서 막아주는 거죠.

쉽게 비유하면, 일반적인 마이그레이션 스크립트가 "손으로 짐을 하나씩 옮기다 떨어뜨릴 위험"이라면, CQL은 "옮기기 전에 규칙을 증명해두고 그 규칙대로 통째로 옮기는" 방식이에요.

업계 맥락에서 보면

사실 "함수형·수학적 엄밀함을 데이터에 적용하자"는 흐름은 새롭진 않아요. 하스켈 같은 함수형 언어 진영, 타입을 엄격하게 다루는 도구들이 비슷한 철학을 공유하거든요. 일반적인 ORM이나 마이그레이션 툴(Flyway, Liquibase 등)이 "절차를 잘 적어두자"에 가깝다면, CQL은 "애초에 잘못될 수 없는 구조로 증명하자"에 가까워요. 다만 그만큼 배우기 어렵고, 아직은 학술·연구 색채가 강한 niche 도구라는 한계도 분명해요.

한국 개발자에게 주는 시사점

당장 회사 DB를 CQL로 바꾸자는 얘기는 아니에요. 그건 현실적이지 않거든요. 하지만 "데이터의 구조를 점과 화살표의 그림으로 바라보는 사고방식"은 배워둘 가치가 충분해요. 스키마를 설계할 때 관계의 일관성을 먼저 그림으로 그려보는 습관, 마이그레이션을 "절차"가 아니라 "두 구조 사이의 정확한 대응"으로 바라보는 관점은 실무에서도 실수를 크게 줄여줘요.

특히 마이크로서비스로 DB가 여러 개로 쪼개지는 요즘, 서비스 간 데이터 동기화와 변환이 점점 더 중요해지고 있거든요. 이럴 때 "무결성을 어떻게 이론적으로 보장할까"라는 CQL의 질문은 우리에게도 똑같이 유효해요.

마무리

CQL은 당장 쓸 도구라기보다, 데이터베이스를 바라보는 새로운 안경에 가까워요. 수학이 멀게 느껴졌던 분이라도 "점과 화살표"라는 한 컷으로 데이터 구조를 다시 보면 의외로 많은 게 또렷해질 거예요. 여러분은 마이그레이션을 '절차'로 짜고 있나요, 아니면 '구조의 대응'으로 설계하고 있나요?