데우스랠리 데이터 저장 구조 고민

데우스랠리 초기에는 Rally Editor에서 잘 맞았던 flatTree 구조를 다시 적용해보려고 했어요. id 기반으로 노드를 찾고 수정하기 쉬웠고, MobX observable 관점에서도 납작한 객체 단위로 감시하는 구조가 좋아 보였어요.

하지만 데우스랠리는 Rally Editor와 달리 Deus에서 내려오는 원본 트리 구조, 프리뷰, 코드젠, 저장 동기화가 함께 움직여야 했어요. flatTree를 쓰면 단일 노드 접근은 쉬워졌지만, 계층 관계를 다시 복원하고 동료가 구조를 따라갈 때의 인지부하가 커졌어요.

결국 제가 먼저 제안했던 flatTree 구조를 내려놓고, 원본 데이터와 가까운 트리 구조로 롤백했어요. 좋은 자료구조를 고르는 문제라기보다, 지금 제품의 데이터 흐름과 팀이 유지할 수 있는 구조를 다시 판단하는 과정이었어요.

처음에는 전에 잘 맞았던 구조를 재사용하는 게 합리적이라고 생각했어요. 데우스랠리도 타임라인과 모션을 다루는 에디터였고, flatTree를 쓰면 노드 단위 접근과 수정이 단순해질 거라 봤어요.

MobX observable 관점에서도 중첩 객체의 중간값을 감시하기보다 납작한 객체 단위를 감시하는 편이 더 유리해 보였어요. 그래서 초반 판단만 놓고 보면 flatTree는 꽤 자연스러운 선택이었어요.

데우스랠리의 데이터 흐름은 Rally Editor보다 훨씬 복잡했어요. Deus에서 내려오는 원본 데이터, 플러그인 내부 store, 프리뷰, 코드젠, 저장 동기화가 함께 움직여야 했어요. 이 구조에서는 데이터 저장 방식이 단순한 구현 취향이 아니라, 기능 개발과 협업 속도에 바로 영향을 주는 기초 설계였어요.

id 접근 성능만 보고 판단하지는 않았어요. 원본 데이터 형태, 변환 비용, 동료가 구조를 따라갈 때의 인지부하를 함께 봤어요. Rally Editor에서 잘 맞았던 flatTree 구조가 데우스랠리의 입력 데이터와 협업 방식에도 맞는지 실제 설계에 적용해보며 확인했어요.

적용해보니 생성, 삭제, 복제 과정에서 parent-child 관계와 중첩된 자식 관계를 직접 관리해야 하는 비용이 계속 드러났어요. Deus에서 내려온 원본 데이터가 이미 트리 구조였기 때문에, flatTree를 쓰려면 먼저 flatten하고, 프리뷰나 코드젠처럼 계층 관계가 필요한 곳에서는 다시 관계 중심으로 복원해야 했어요.

협업 측면의 비용도 컸어요. 자식 노드를 다룰 때마다 부모 참조를 일일이 갱신하는 손이 들어갔고, 함께 작업하던 동료도 구조가 계속 헷갈린다는 의견을 줬어요. 기능 개발 과정에서도 flatTree가 병목이 되고 있다는 걸 체감했어요.

처음 flatTree를 제안한 건 저였지만, 제 선택이 지금 제품 맥락에는 맞지 않는다고 인정하고 트리 구조로 되돌리는 방향을 제안했어요.

결국 flatTree를 적용해본 뒤 트리 구조로 롤백했어요.

id 기반 단일 노드 접근이라는 편의는 분명 매력적이었어요. 하지만 그 이점만으로는 데우스랠리의 데이터 흐름을 감당하기 어려웠어요. 원본이 이미 트리였고, 계층 관계가 필요한 지점마다 복원 비용이 따라붙는 상황에서는 원본 구조와 가깝고 동료가 따라가기 쉬운 쪽이 더 나은 선택이라고 판단했어요.

이 과정에서 flatTree의 단일 노드 접근 편의성은 일부 내려놓았어요. 대신 parent-child 관계가 코드 구조에 자연스럽게 드러났고, 동료가 구조를 따라가고 리뷰할 때의 인지부하도 낮아졌어요. 결과적으로 id 접근 편의보다 원본 구조와의 정합성, 그리고 협업 중 인지부하를 우선에 둔 판단이었어요.

롤백 이후 가장 크게 회복된 건 동료와의 커뮤니케이션이었어요. 데이터 구조를 설명하기 쉬워졌고, 기능을 어느 위치에 추가할지도 더 명확해졌어요.

Deus에서 내려오는 원본 데이터 구조와 내부 store 구조가 가까워지면서 불필요한 변환 부담도 줄었어요. 단일 책임 같은 전통적인 좋은 코드 기준도 트리 구조에서는 더 쉽게 설명하고 적용됐어요.

전에 잘 맞았던 구조라도 새 제품의 입력 데이터와 협업 맥락에 맞지 않으면 과감히 버릴 수 있어야 한다는 걸 배웠어요.

좋은 구조는 아이디어만 좋아서는 부족해요. 팀이 따라갈 수 있을 만큼 인지부하가 낮아야 하고, 기능 개발 속도도 계속 지탱할 수 있어야 해요. 제가 먼저 제안한 구조라도 실제 개발 과정에서 병목이 된다면, 그 선택이 지금 맥락에 맞지 않는다는 걸 인정하고 되돌리는 판단이 필요했어요.

다음에 비슷한 선택을 한다면 먼저 원본 데이터의 형태, 변환 비용, 팀의 숙련도, 리뷰 가능성을 같이 보려고 해요.

특히 에디터처럼 데이터 구조가 기능 개발 전체에 영향을 주는 경우에는, 이론적으로 좋아 보이는 구조보다 팀이 계속 유지할 수 있는 구조인지 더 일찍 검증해보고 싶어요.