[기술논의] Page 모델 타입 결정

문제 상황

책 페이지 안에는 사진, 영상, 음성 등 용량이 큰 정보들이 담기는데, 이를 배열에 저장했을 때 페이지의 삽입(INSERT), 삭제(DELETE)가 불리하다고 생각했습니다. 예를들어, 책 페이지를 배열에서 관리하면 1,000장 10,000장 넘어갔을 때 앞 페이지의 삽입으로 인한 뒷 페이지들의 값 변화에 많은 비용이 발생하게 됩니다.

따라서 책 페이지 하나를 노드로 생각하고,

이를 Linked List로 관리하여 생성 및 수정을 할 때 삽입/삭제가 유용하도록 하고자 했다.

연결리스트의 경우 레퍼런스가 필요한 모델이 될텐데,

이를 class + Sendable vs Actor 타입 결정에 대한 논의이다.

---

문제 해결

위 레퍼런스 타입을 정할 때 아래와 같은 사항을 고려하였다.

Class + Sendable로 진행했을 시

장점

• 페이지 간의 관계를 노드로 표현할 수 있다.
• Actor보다 자연스러운 내부 접근이 가능하다.

단점

• Swift 6 환경에서 비동기 작업시 Sendable을 준수해야 하는 문제가 있다.
  • 이 경우 모든 프로퍼티가 let으로 고정되어야 하는 단점이 있다.

Actor로 진행했을 시

장점

• 페이지 간의 관계를 노드로 표현할 수 있다.
• Swift6 환경에서 동시성 프로그래밍을 안전하게 사용할 수 있다.
• actor의 내부 프로퍼티가 변수여도 된다.

단점

• actor의 프로퍼티나 메서드에 접근하려는 경우 비동기가 아님에도 불구하고 async/await 구문을 사용해야하는 불편함이 있다.

위와같은 타입을 사용하면 페이지간의 노드관계를 표현가능하다는 장점이 있으나, 데이터를 불러오는 등 비동기 상황에 있어서는 불편함이 있다는 것을 확인했다.

이에 대한 논의를 지속하다보니, 비동기 상황에서의 조작은 struct가 이점이 있다는 것을 깨달았다.

따라서, struct를 사용하여 노드관계를 내려놓고 배열로 구현 가능할 것같다는 결론에 도달했다.

하지만, 모든 파일을 메모리로 한번에 불러오는 것에 대한 부담이 여전히 존재했다.

이것을 극복하고자, struct내부에 데이터를 직접 적재하는 것 대신, disk에 저장되어있는 경로만 저장하여 필요할 때 Disk로부터 불러오는 것으로 결정하였다.

이를 통해 비동기 상황에서도 안전하게 사용 가능하고, 메모리에 부담이 적은 방식을 도출할 수 있었다.

---

결론

• 기본적으로 struct를 사용하고 배열에 페이지들을 저장하되 멀티미디어에 대한 데이터는 메타데이터 형태로 가지고 있는다.

  그리고 필요할 때 metadata의 path를 통해 실제 미디어를 불러온다.

• 위 방법으로 실행 시 성능의 문제가 발생하면, 연결리스트 및 class + Sendable 혹은 Actor를 도입한다. 둘 중 어떤 방법을 채택할지는 구현해보며 결정한다.