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

데우스랠리에서는 중간 노드 하나를 수정할 때도 그 노드의 데이터만 보고 작업하기 어려웠어요. Deus에서 받은 트리 구조를 그대로 사용하고 있어, 부모·형제·자식에 미치는 영향까지 함께 확인해야 했기 때문이에요. 여러 노드의 관계를 함께 고려하는 과정에서 타입 오류가 나거나 필요한 로직을 빠뜨리는 일이 반복됐어요.

이 문제를 줄이려고 랠리 에디터에서 사용했던 flatTree 구조로 바꾸자고 동료에게 제안했고, 실제로 적용해 함께 검증했어요. 특정 노드의 수정은 쉬워졌지만 팀이 기능을 추가하고 검증하는 과정의 복잡함은 줄지 않았어요. 결국 트리 구조로 돌아가되, 각 노드 인스턴스가 자신과 관련된 계산과 변경 로직을 맡도록 메서드를 정의했어요.

기존 트리 구조에서는 중간 노드 하나를 바꾸려 해도 부모·형제·자식에 미치는 영향까지 함께 확인해야 했어요. 기능 하나를 추가할 때마다 살펴야 할 범위가 넓어졌고, 관계를 따라 수정하는 과정에서 타입 오류가 생기거나 필요한 로직을 빠뜨리는 일이 반복됐어요.

변경이 필요한 노드만 보고 수정할 수 있다면 확인해야 할 범위를 좁히고, 구조의 복잡함에서 생기던 오류도 줄일 수 있다고 봤어요.

해결책으로 랠리 에디터에서 사용했던 flatTree 구조를 동료에게 제안하고 함께 적용했어요. 수정할 노드의 데이터에 집중할 수 있으면, 관계를 따라 수정하다 생기는 타입 오류와 로직 누락도 줄일 수 있다고 기대했어요.

Deus에서 내려온 원본 트리는 먼저 flatTree로 펼쳐야 했고, 코드 생성 전에는 다시 트리로 조립해야 했어요. 다만 기능 추가와 수정이 충분히 단순해진다면 감수할 수 있는 비용이라고 봤어요.

적용 뒤에도 동료가 flatTree의 노드 관계를 이해하는 데 어려움을 겪었고, 팀이 기능을 추가하고 검증하는 과정의 복잡함도 줄지 않았어요. 한 노드의 수정만 편해졌을 뿐 팀이 겪는 복잡함이 그대로라면, 처음 해결하려던 문제의 답이 될 수 없다고 판단했어요.

그래서 flatTree 구조는 이 문제의 해결책이 아니라고 보고 Deus 원본과 같은 트리 구조로 돌아갔어요. 그대로 복원하지는 않고, 각 노드 인스턴스가 자신과 관련된 계산과 변경 로직을 맡도록 메서드를 정의했어요.

수정할 노드만 보면 됐던 flatTree의 편의는 포기했어요. 대신 변경에 필요한 로직을 각 인스턴스 안에서 다루면서, 처음 문제였던 타입 오류와 로직 누락 가능성을 줄였어요.

특정 노드만 바꾸기 쉬운 구조가 곧 팀이 변경하기 쉬운 구조는 아니라는 걸 배웠어요. 자료구조를 고를 때는 한 노드의 수정 편의뿐 아니라, 동료가 관계를 이해하고 변경 영향을 검증할 수 있는지도 함께 봐야 했어요.

다음에 비슷한 구조를 바꿀 때는 작은 범위에 먼저 적용하고, 처음 풀려던 문제를 실제로 줄였는지 동료와 더 일찍 확인하려고 해요.