파이썬 스터디 : 003. 서비스마다 달라지는 정보구조

이 글은 002편에서 이어지는 글입니다.

 

서비스마다 정보의 구조가 달라진다

저번 시간에는 달력 안에 들어있는 메모들을 갖고 분석을 해보았다. 그리고 그 과정에서 바뀌지않는 정보와, 바꿀 수 있는 정보. 두가지가 있다는걸 알게됐다. 그렇다면 달력이 아니라, 다른 서비스에서는 어떤 정보들을 사용하고 있을까? 

예를 들어 다이어리, 일기장 서비스를 사용한다고 해보자. 그러면 일단 날짜가 중요하다. 특정 날짜에 쓴 글들이 여러개일 수도 있고, 하나일 수도 있다. 심지어 내용을 수정해 카테고리를 바꾸거나, 제목, 내용을 바꾸는 것도 가능하다. 전체 공개를 하거나, 비밀글로 바꿔버릴 수도 있다. 그렇다면 이런 일기장에서 '바꿀 수 없는 정보'는 무엇일까?

 

 

외부로 공개된 일기장 서비스의 경우

• 사용자 입장에서는 날짜보다 카테고리가 더 우선적으로 보임
  
• 한 날짜에도 여러 일기를 작성할 수 있음
• 달력과 다르게, 작성 버튼을 누르는 순간에만 게시글이 생성됨
• 과거에 작성된 글을 수정할 수는 있지만, 과거나 미래 시간에 글을 쓸 수는 없음
• 작성 시점을 제외하면, 사용자가 거의 모든 정보를 마음대로 바꿀 수 있음

 

일기장은 달력 메모와 다르게, 현재 시점에만 글을 사용할 수 있다. 게다가 사용자가 글을 작성하지 않을 경우, 그 어떤 정보도 만들어지지 않는다. 또한 관리자와 사용자 입장에서 볼 때, 큰 차이가 있는 서비스들 중 하나다. 

 

" 일기는 최상단의 카테고리를 구분해서 보여주지만, 사실 별로 중요한 정보는 아니다 "

• 사용자 입장에서는 카테고리를 마음대로 생성할 수 있고
• 기존의 글의 카테고리도 마음대로 이동할 수 있음
• 사실상 카테고리는 글이 작성된 날짜,시간보다 하위에 있는 정보

 

정보를 분석하는 방식에는 여러가지 방식이 있다. 그러나 일반적으로 '변하지 않는 정보'가 더 우선순위가 높다. 특히 특정 아이템을 찾을 수 있는 고유 ID를 무엇으로 하느냐에 따라, 관리자 입장에서는 효율이 크게 달라진다. 

 

티스토리 블로그의 글 관리 화면

 

글을 작성한 사람의 입장에서는 '글의 제목'과 '카테고리'로 구분을 하는 것이 관리 편하다. 그러나 서버나, DB (데이터베이스) 입장에서 바라본다면, 제목과 카테고리는 사용자가 얼마든지 바꿀 수 있는 것들이다. 그러니 변하지않는 것들을 폴더로 만들고. 그 안에 바뀔 수 있는 내용들을 담고있는 것이 더 안전하다. 

또한 1명의 사용자 입장에서는 자신의 글만 확인하겠지만. 서버나 DB 입장에서는 수백만명의 사용자가 작성한, 수천만개의 게시글을 다뤄야한다. 그러니 사용자 ID같이, 변할 수 없는 값과 함께, 그 사람이 쓴 글의 '고유 ID'를 갖고있어야한다. 그래야 그 사람들이 쓴 글들을 순서대로, 날짜나 특정 순서대로 확인할 수 있기 때문이다.

 

 

 

사용자에 따라 정보가 달라진다

일기의 경우, 글을 쓴 사람과 보는 사람이 큰 차이를 느끼기 어렵다. 글을 쓰거나, 편집할 권한을 더 갖고있을 뿐. 대부분 비슷한 수준의 정보를 갖고있기 때문이다. 그렇다면 여러 기자들이 함께 일하는 뉴스채널의 경우는 어떨까? 

 

 

기자들이 사용하는 뉴스 사이트의 경우

• 작성 플랫폼과, 뉴스를 올리는 플랫폼이 별도라, 관리자가 따로 있음
• 일기장과 마찬가지로, 제목, 카테고리, 내용 등을 자유롭게 바꿀 수 있음
• 기자가 뉴스를 작성 했더라도, 관리자가 카테고리를 바꾸거나, 글을 비공개 처리 할 수 있음 

 

 

 

뉴스는 일기장과 비슷하지만, 여러 사람이 한 곳에 같이 글을 올릴 수 있다. 글을 쓰는 기자의 경우 여러 글을 써서 미리 올려두고. 동일한 시각에 공개하거나. 이미 올린 기사를 편집해 추가 사실을 넣을 수도 있다. 또한 일기장이 사용자가 작성과 관리를 함께 한다면. 뉴스 사이트를 관리하는 사람이 따로 있다. 필요하다면 기사를 내리거나, 서로 엮어주기도하고. 특집 기사를 시리즈물로 변경할수도 있다. 

이런 관점 때문에 '어떤 기자가 이 기사를 작성했는지'와 그 '기자가 어떤 기사들을 작성했는지'를 확인하는, 관리자 페이지가 필요해진다. 분명 뉴스 기사라는 하나의 아이템인데도. 작성자와 보는 사람. 관리자의 입장에서 전혀 다른 정보가 중요해지는 것이다.

 

 

여기에 추가로 뉴스 기사에 댓글을 달게된다면 어떨까? A기자가 쓴 뉴스에. B라는 사람이 단 댓글. 그리고 또다시 그 댓글에 대한 답글이 붙는다면? 이런 식으로 여러 서비스의 아이템들을 들여다보면. 모든게 트리구조로, 더 중요한 상위 정보에서 연관되어 이어진다는것을 알 수 있다. 

 

 

 

이번에는 글이 아니라 음악 서비스를 한번 들여다보자. 일반적인 음악 서비스는 스트리밍 기반이므로. 음악을 올리는 사람과, 사용자, 서비스 관리자가 따로 나뉘어있다. 뉴스 서비스의 경우와 비슷해보이지만, 음악 서비스는 구조가 훨씬 복잡하다. 

 

 

스트리밍을 통한 음원 서비스의 경우

• 음악 파일을 업로드하고, 재생된 횟수만큼 정산을 받는 플랫폼이 따로 있어야한다
• 음악 파일을 업로드한 사람은 개인 아티스트일수도 있고, 회사일 수도 있다
• 음악을 업로드할 때, 단일 음원 / 앨범 타입 두가지 구분이 필요하다
• 앨범타입은 앨범에도 고유 ID가 필요하고, 음악별로 앨범 내 트랙번호가 필요하다.
• 음원별로 저작권 보유 체크를 해야하고, 음악파일을 업로드한 사람과 비교 체크를 해야한다.

 

 

 

 

일기장이나 뉴스 사이트의 경우 내 ID로 로그인만 되어있다면, 얼마든지 글을 쓸 수 있었다. 그러나 음악 스트리밍을 위한 음원 업로드의 경우. 그 음원이 내 것이라는 증거가 필요하다. 그렇지않으면 온갖 불법 업로드가 가능해지고, 재생횟수에 맞춰 금액을 정산받기가 어렵기 때문이다. 

 

게다가 앨범 단위의 업로드시, 여러 음악과 이 앨범이 서로 연결되어있다는걸 알려줘야하고. 그 앨범 속에서 다시 몇번째 음악인지. 개별 음원에 대한 저작권 보유권도 체크해줘야한다. 그러니 일기장이나, 뉴스 사이트보다 훨씬 복잡하고, 다양한 정보를 담아야한다. 

 

 

가설을 세우고, 실제로 그 가설이 맞는지 확인해보자

 

필자가 음원 서비스 쪽을 정리하면서 가장 복잡하게 생각했던 건. 앨범 단위의 음원과, 개별 음원에 대한 고유 ID를 만들 때. 과연 어떤 방식으로 넘버링을 해야하는지에 대한 부분이었다. 단일 음원이라면, 글처럼 단순 넘버링만 처리해줘도 된다. 그러나 앨범이 들어가는 경우. 앨범이라는 폴더 내에서 다시 넘버링이 필요하기 때문에. 그 아티스트가 올린 음원의 순서와, 앨범 내에서의 순서. 두가지가 모두 맞춰져야한다. 

 

단순하게 생각한다면. 앨범과 상관없이 올린 순서대로 넘버링을 붙여주고. 앨범 타입인 경우, 별도로 폴더를 만들어 처리하게 할수도 있을 것이다. 하지만 이 경우는 '음원을 업로드하고 관리하는 사람'에겐 편리하지 않은 구조라. 분명 더 좋은 방식이 있을 거라고 본다. 이런식으로 가설을 세우고, 실제 서비스가 어떤 방식을 쓰고있는지를 분석해보면. 분명 더 많은 내용을 알게될 것이다. 

 

이 글에서 모든 서비스의 구조를 더 다루진 못했지만. 다음과 같은 케이스들을 생각해볼 수 있을 것 같다.

 

• A가 B에게 보낸 메일의 경우
• 단톡방에서 쓴 채팅의 경우
• 커머스에 올린 상품의 경우
• 달러를 다루는 환전소의 경우
• 가상화폐 거래소의 경우

 

---

 

자료구조의 개념을 이해하기위해, 실제 서비스들 중 몇몇 사례를 다뤄보았다. 그 과정에서 나는 실제로 우리가 눈으로 보는 것과 달리. 변하지않는 정보와, 변할수 있는 정보 두가지가 있다는 것을 확실하게 알게되었다. 또한 동일한 아이템임에도, 사용자가 누구인지에 따라 전혀 다른 정보들이 우선순위를 갖게된다는 것도 알게 되었다.

 

 

결국 정보 구조라는 것은 서버와 DB의 관점에서 최적의 설계를 만들어야하고. 사용자별로 다른 정보 템플릿을 입력할 수 있어야한다. 그리고 그 중심에는 변하지않는 정보. 고유 ID라는 것이 있다. 스스로 이 개념을 이해하고 다시 정보구조 강의를 확인해보니, 이해하기가 훨씬 쉬웠다. '누구의 관점에서 보는 정보'를 더 우선으로 볼 것인지. 그리고 어떤 정보를 더 먼저 수정할 것인지. 그런 순서나 정보의 중요도를 파악할 수 있었기 때문이다.

 

이제 정보 구조라는 것이 무엇인지 알았으니. 실제 파이썬을 기반으로 어떤 것들이 가능한지. 또, 어떻게 해야 저런 정보들을 한 곳에 담을 수 있는지. 하나하나 알아볼 차례다.