Aggregate를 애그리게잇 대신 조립물로 쓴 사연

동료 유영모가 ID로 다른 애그리게잇을 참조하라에서 애그리게잇을 본문에서 조립물로 바꾼 사연에 대한 이야기다.

두레이로 popit 글 검토를 하는 우리회사

popit 글 검토는popit 저자들이 글을 쓰는 워드프레스 시스템 상에서 벌어진다. 그런데, 사내에서 쓰는 두레이로 우리끼리 대화를 하고 싶어서 회사안에서는 채널을 만들었다. 워드프레스는 결과물 편집은 좋지만, 의견을 주고 받기는 어려우니까. 그러던 차에 내가 검토를 요구하는 유영모에게 아래와 같이 답했다.

이 글의 모티브가 된 나의 두레이 댓글

대중성은 필요 없고, 사회에 이익이 되느냐?

나에게 중요한 것은 그것이다. 나는 출판사도 아니고 돈을 받는 저자도 아니니까. 그저 생업에 쫓겨 본격적으로 나서지 못했지만, 우리나라 개발자들의 앞날을  위해 뭔가를 해보려고 했다. 지금도 하고 있고... 이왕에 댓글을 쓰고 팝잇에도 글을 쓰는거 그에 충실하자 마음 먹고 어쩌면 사대주의에 물든 나와 생각이 다른 개발자들이 불나방처럼 올 수도 있는 피곤한 논쟁을 할 각오도 했다. 그래서, 유영모에게 소수만 관심을 둘 제안을 했다.

대강 이해하는 DDD 배경 지식

내가 알기로는 DDD의 Aggregate는 저자인 에릭 에반스가 소프트웨어를 만드는 부품 혹은 빌딩블록_{Building Block}의 하나로 소개한 것이다. 간단한 프로그램이나 앱 프론트와 같이 사용자 인터페이스 위주의 프로그램은 또 그 대상이 아니다. 비교적 안정적으로 쓰이는 프로그램이면서 동시에  복잡한 로직을 담고 있는 코드가 DDD 담론의 대상이다. 그렇다보니 빌딩블록_{Building Block}이라는 우리 말로 생각해보면 구조물이란 복합적 덩어리가 등장한다.

그러한 구조물 중에 또 한가지 유형인 Aggregate는 Entity라는 또 다른 구조물이 있다는 전제하에 생겨난다. 값이 바뀌더라도 지속적으로 그게 하나의 대상의 상태 변화를 나타낸다는 개념이 바로 Entity이고, RDBMS의Entity나 객체지향의Entity나 개념적으로는 큰 차이가 없다. RDBMS는 동적이고 행위 중심의 개념이 담기기 어렵다는 차이만 있을 뿐이다.

그런데, 우리 인간은 사회적 동물이라고 한다. 그래서 인지, 복잡한 데이터를 담을 때에도 사회를 닮은 연결망을 구성하는 방식을 택했다. 물론, 알고리즘 관점에서 그 결과를 도출할 수도 있지만, 어쨌든 그저 검증할 수 없는 생각일 뿐이니 뭐라고 믿는 좋다. 중요한 사실은 Entity는 다른Entity_{이하 엔터티}와 관계를 같고, 데이터를 탐색하다 보면 그물망을 옮겨 다녀야 한다. 예를 들어, 직원 정보를 관리하기 위해 Employee 엔터티를 정의하고 레코드를 보관했다고 가정하자. 그런데, 그가 조직을 옮겨간 이력을 관리하고 싶어 조직 필드를 만들었다고 생각해보자. 그 후에 그때 그 조직의 성과를 보고 싶다고 하면, 조직을 다시 엔터티로 정의해야 한다. 그리고 관계를 설정해야 한다. 연관객체 혹은 릴레이션이라고 부르는 구현체가 바로 그것이다.

조립이란 무엇인가?

아래 레고 블럭 이미지를 보자. 좋아하는 분도 있겠지만, 나는 생각만해도 피곤하다. 복잡한 소프트웨어를 구성하는 일과 코드를 만드는 일은 그런 지적 피곤함과 인내를 요한다. 그 피곤함을 견뎌내는 학습이 바로 개바자/설계자/엔지니어로써 나를 성장시키는 동력이기도 하다.

레고 블럭 이미지

암튼 그래서 작은 프로그램 단위를 객체 혹은 뭐라 부르든 일관성있는 구조물 혹은 빌딩 블록으로 묶어야 한다. 부품을 매번 새로 개발할 수는 없으니까. 90년대에 무슨 절대 가치처럼 남용되던 컴포넌트나 재사용이란 말이 바로 그 일이다. 그리고 그 부품도 유형을 만들어서 노하우 재사용이나 더 큰 단위의 컴포넌트를 만들 필요가 있고, 그러한 제한중에 오래도록 살아남는 실천법이 바로 DDD다.

그 과정에서 엔터티의 조립물이 바로 Aggregate이라고 나는 주장한다. 왜냐면 뭘 우선시하고 뭔 바닥에 두고 하는 조립할 때의 고민이 바로 엔터티 루트를 정하고 SQL 문장안에 들어가는 구체적인 사항을 얼만큼 숨기고(객체 지향 관점의 Encapsulation) 얼만큼 드러낼(API 설계) 것인지를 정하는 일이기 때문이다.

결론

그래서, 국립국어원이나 JTBC 비하인드 뉴스에서나 고민할법한 Aggregate 표기법으로 시간을 낭비할 바에는 조립이라는 우리말을 통해 사고를 열어주는 편이 나을 것이라도 주장한다.