최근 Claude Code로 새로운 에이전트 아키텍처를 짜다가 뻗어버렸다. 서로 다른 시스템을 연결할 때마다 인터페이스 맞추느라 밤을 새웠는데, 영상 하나가 이 난제를 해결할 실마리를 던졌다.
관계의 혁명 — 무엇인지가 아니라 무엇을 하는지
내가 블로그 자동화 파이프라인을 구축할 때, Notion, Telegram, Vercel을 각각 '정적인 객체'로 보고 일대일 매핑을 시도했다가 실패한 적이 있다. Notion의 데이터베이스 구조가 바뀌면 파이프라인 전체를 뜯어고쳐야 했다.
영상에서 말하는 '관계의 혁명'은 이 문제를 정확히 짚는다. 시스템을 '무엇인지'로 정의하는 대신, '무엇을 하는지' — 즉 다른 시스템과 어떤 관계를 맺고 어떤 변환을 수행하는지로 보라는 것이다.
그제서야 내 파이프라인이 "Notion에서 읽고 → Vercel에 푸시하는 흐름"으로 재설계됐다. 각 요소의 내부 구조는 몰라도 관계의 화살표만 알면 시스템이 돌아간다.
동일구조의 힘 — 솔루션 재사용
금융 시스템에서 쓰던 데이터 검증 로직을 AI 모델 파이프라인에 그대로 가져다 쓰고 있다. 코드 몇 줄 바꾸지 않고 그대로 통했다.
범주론이 말하는 '동일구조(Isomorphism)'는 이런 가능성을 보여준다. 서로 다른 도메인이라도 구조적 패턴이 같으면, 한 쪽에서 증명된 해결책을 그대로 가져다 쓸 수 있다. 단순히 코드를 재사용하는 게 아니라, '솔루션' 자체를 재사용하는 것이다.
요네다 보조정리 — 상호 운용성은 DNA에 내재되어야 한다
내가 처음 Cursor로 MCP 서버를 만들었을 때, 인터페이스 호환성 문제로 며칠을 헤맸다. 그때도 요네다 보조정리가 통했을 텐데.
객체의 내부를 모르더라도, 그 객체가 시스템 내 다른 모든 객체와 맺는 관계의 총합을 알면 그 객체를 완벽하게 정의할 수 있다. 이 원칙을 처음부터 적용했으면, 나중에 '아 이거 호환 안 되네' 하고 뒤늦게 인터페이스를 바꾸는 삽질을 안 했을 텐데.
상호 운용성은 사후 처리가 아니라 시스템의 DNA에 내재되어야 한다. 이걸 배웠다.
통합 프레임워크로서의 범주론
생물학자가 뉴런 네트워크를 연구하고, 물리학자가 우주를 상호작용의 망으로 모델링하고, 내가 AI 시스템을 설계할 때 — 서로 다른 분야의 전문가들이 같은 언어로 대화할 수 있다면?
범주론은 이 '공용어(Lingua Franca)' 역할을 한다. 지식을 정적 데이터가 아닌 동적 관계망으로 다루는 AI를 만들 때, 이 프레임워크가 강력한 도구가 될 것 같다.
관계 그래프를 만들어 봐야겠다
어떻게 만드는지 좀 공부도 해야겠다. 범주론으로 시스템을 설계할 때, 각 컴포넌트 간의 관계를 어떻게 시각화할 수 있을지 알아봐야겠다.
실제로 그래프 그리는 도구와 방법을 찾아봐야겠다. 내가 만든 에이전트 아키텍처를 이 새로운 관점에서 다시 그려볼 생각이다. 아키텍처를 정적인 '객체' 중심에서 동적인 '관계' 중심으로 바꾸면, 데이터 사일로는 사라지고 진짜 확장 가능한 시스템이 나올 것 같다.