13. 객체보다 관계

회의실 화이트보드 앞에서 아키텍처를 설명할 때, 사람들은 동그라미 안에 무엇을 적었는지에 크게 신경 쓰지 않는다. “여기가 API 서버고, 여기가 큐고, 여기가 워커다.” 이름은 말하는 순간 필요할 뿐, 정작 서로 눈으로 좇는 것은 동그라미 사이를 잇는 화살표다. 어디서 어디로 요청이 가는지, 어느 화살표가 비동기이고 어느 화살표가 동기인지. 발표가 끝나고 나면 동그라미 안의 이름보다 화살표의 흐름이 더 오래 기억에 남는다.

12장에서 살펴본 npm 의존성 그래프도 같은 모습이다. 패키지 이름은 그래프 위의 점 하나하나에 붙은 이름표일 뿐, 그 점을 다른 이름의 다른 패키지로 통째로 바꿔치기해도 “누가 누구에게 의존하는가”라는 화살표의 그물은 조금도 달라지지 않는다. 5장에서 체스판의 나이트를 이야기하며 나무를 깎든 플라스틱을 찍어내든 상관없다고 했던 것과 같은 문장을, 이번에는 그래프 전체에 대해 쓸 수 있다. 점의 재질은 상관없다. 의존성 그래프를 의존성 그래프로 만드는 것은 점에 적힌 이름이 아니라 화살표가 그리는 모양이다.

이 관찰을 조금 더 밀어붙이면 이상한 실험을 해 볼 수 있다. 회사의 조직도에서 이름을 전부 지우고 익명의 번호로 바꿔 보자. “1번이 2번에게 보고하고, 2번과 3번이 4번에게 보고한다.” 실제 인사 정보는 하나도 남지 않았지만, 조직도가 전달하려던 정보, 즉 누가 누구에게 보고하는가라는 구조는 이 익명화된 도식만으로도 완전히 복원된다. 반대로 이름표는 전부 살려 두고 화살표만 지워 버리면 어떻게 될까. 그 순간 조직도는 그냥 이름이 나열된 명단으로 무너진다. 정보가 실려 있던 곳은 이름이 아니라 화살표였다는 뜻이다.

지금까지는 대상 하나를 먼저 세워 두고 그 위에 관계를 얹는 순서로 이야기를 진행해 왔다. 젓가락이 먼저 있고 같음의 기준이 따라왔고, User 클래스가 먼저 있고 그 이름이 약속하는 바가 따라왔다. 그런데 화이트보드 앞에 서서 화살표를 좇고 있으면 이 순서를 뒤집어도 잃는 것이 없다는 사실이 드러난다. 동그라미를 속이 텅 빈 점으로 취급해도 그림은 완전하다. 점은 화살표가 시작하거나 끝나기 위해 필요한 최소한의 자리다. 그 자체로 무언가를 담고 있을 필요는 없다.

여기서 하나의 사고방식이 조용히 자리를 잡는다. 대상이 무엇을 담고 있는지 먼저 묻는 대신, 대상들 사이에 어떤 화살표가 그어져 있는지를 먼저 보는 방식이다. 조직도의 이름을, 패키지의 이름을, 심지어 젓가락과 참새의 구체적인 생김새까지 다 지워도 화살표의 그물만 온전하면 구조는 살아남는다. 관계망 하나만 쥐고 있으면 그 관계가 정확히 무엇을 연결하고 있는지는 나중에 채워 넣어도 된다는 뜻이다. 대상보다 관계를 먼저 보기 시작한 순간, 그림의 중심도 자연스럽게 관계로 옮겨간다.

다만 이렇게 관계만 남긴 그물 두 개를 나란히 놓았을 때 아직 풀리지 않는 질문이 하나 남는다. 조직도 하나와 선수과목 체계도 하나에서 이름을 전부 지우고 화살표의 배치만 남겼는데, 그 두 그물의 모양이 우연히 겹친다면 어떨까. 재료도 다르고 화살표가 가리키는 현실도 전혀 다른 이 둘을 두고, 무엇을 같다고 볼 때 우리는 두 구조를 같다고 말하는 걸까. 다음 화에서는 이 질문을 붙잡는다.