walk to dream.

정보를 분류하고 관계를 맺는 태그 시스템

블로그와 더불어 태그는 웹2.0에서 정보를 분류하고 재생산 하고 관계를 맺는 도구로 최근 가장 이슈가 되고 있는 서비스이다. 요즘 새로 오픈하는 서비스들의 대부분이 태그를 통해서 정보를 분류하여 보여주는 방법을 사용하고 있다.

태그 시스템은 많은 개발자들에 의해 구조화 되어 왔으며 각 개발자들의 방식을 발전시켜가며 정형화되고 있다. 하지만데이터베이스를 통한 거대(Scale)한 태그 시스템을 만드는 방법에 대해서는 아직 누구도 뚜렷한 해답을 내지 못하고 있으며 여러논의만 진행되고 있는 상황이다.

del.icio.us 메일링 리스트에 “누군가 del.icio.us의 데이터베이스 스키마에 대해 좀 알려주세요” 같은질문이 종종 올라온다고 한다. del.icio.us의 개발자인 조슈아 샤흐터(Joshua Schachter)의 인터뷰를 보면이런 말이 있다.

“나는 mod_perl, HTML::Mason, 그리고 MySQL. 주로 사용한다. 이들은 매우 전형적인 툴이다. 최근 그로드를 유지하기에는 몇몇 문제점을 가지고 있다. 그래서 지금 새로운 아키텍쳐를 찾고 있는 중이다. 태그는 표준 RDBMS로는만족스럽게 표현하지는 못 한다”

맨 마지막 문구는 조슈아 샤흐터가 인터뷰나 메일의 답변을 통해 자주하는 말이 있다. 데이터베이스를 설계하는 입장에서는 다소실망스러운 말이겠지만, 많은 웹 서비스의 경우 특히 큰 규모의 웹 서비스에서는 RDMBS로 구현하기 힘든 부분이 많이 있다.
조슈아 샤흐터는 이런 말도 한다.

“빠른 최적화는 피하라”

물론 요구분석에 따른 설계는 철저히 해야 하지만, 결과를 미리 예측하고, 섣부른 판단으로 최적화(optimize)하는것보다 하나하나 부딪히며 경험을 통해 재설계(rearchitechting)하는 방법이 기술을 가장 빨리 습득하고 업무도 가장빨리 진행할 수 있는 지름길이 된다(물론, 욕도 많이 먹는다).

이제 많은 개발자들로부터 커스터마이징 되고 있는 태그시스템의 여러 가지 구현 방법에 대해서 이야기 해보자. 이 방법들 중 자신이 만들려고 하는 서비스에 적합한 방법을 찾고, 큰규모의 태그 시스템을 구현할 수 있을지에 대한 해답도 찾아보기 바란다.http://tagschema.com/blogs/tagschema/에서는 태그의 구성요소를 <그림 6>과 같이정의하고 있다.

<그림 6>에서 말하는 세 가지 구성요소로써의 태그 시스템의 구성은 특히, 연관관계는 굉장히 어렵고 복잡하다. 그리고 대부분의 웹 서비스들이 위의 세 가지 구성요소에서 태그 시스템을 구현하는 경우는 거의 없다.

<그림 7>은 우리가 일반적으로 생각하는 태그의 구조이다. 여기에서 사용자는 아이템과 태그에 종속적이다.아이템은 태그로 분류할 수 있는 모든 단위를 뜻한다. <그림 7>에서의 user라는 구성요소로 관계설정 필요하다면보통은 아이템 중 하나의 종류로 들어갈 수 있다.

아이템은 포스트가 될 수도 있고, 사진이나 북마크가 될 수도 있다. 그리고 태그가 아이템의 한 종류가 될 수도 있다.아이템과 태그의 관계는 ‘Item(1-many) <---------> (0-Many)Tags’이다. 아이템이 태그를0개 이상 가질 수도 있지만 태그는 아이템이 없이는 따로 존재할 수 없다.

태그 시스템에서 가장 일반적으로 쓰이는 관계를 설정하고 그에 따라 각 태그의 구조를 쿼리로 분석해보자.

1. Item(tag) : tag가 가지고 있는 Item List
2. Tag(item) : item이 가지고 있는 Tag List
3. Tag( ) : 중복을 허용하지 않는 모든 Tag list

현재 서비스 중인 대부분의 태그 서비스가 표시되는 방식은 이 세 가지 표현으로 소화할 수 있다. 이제 이 세 가지 관계를통해 각 태그 스키마의 구현 방법에 대해 알아보자. 또, 앞으로 나올 태그 스키마의 이름은http://www.pui.ch/phred/archives/ 2005/04/tags-database-schemas.html에서나온 이름을 붙일 것이다.

‘MySQLicious Solution’ 태그 스키마

<그림 8>의 구조는 태그에 관한 스키마를 따로 구성하지 않은 형태이다. 하나의 테이블로 구성되어 있으며분류로서의 태그를 구현했다기 보다 아이템에 대한 키보드와 비슷한 개념의 구조이다. 대부분의 태그에 대한 분류는 풀텍스트서치(fulltext search)로 구현될 수 있지만 비용이 아주 많이 든다는 단점이 있다.

<리스트 1> MySQLicious relation query

Item(tag)
SELECT * FROM Item WHERE tags like ‘%blog%’
Tag(item)
SELECT tags FROM Item WHERE Itemid = ‘1’
Tag()
Query로 표현하기 힘들다.

‘Scuttle Solution’ 태그 스키마

<그림 9>처럼 태그에 대한 스키마를 정의해 놓으면 ‘MySQLicious’ 보다 효율적인 분류가 가능해 진다. 두 개의 테이블로 구성되어 있으며, 대부분의 서비스들은 이런 스키마를 ‘카테고리’라는 기능으로 구현한다.

이 구조의 스키마는 위의 관계를 표현하는 데에만 적용한다면 참 좋은 스키마 구조이다. 하지만 보다 기능적인 태그의 관리를 하고 싶다면 스키마로는 부족한 점이 많다.

<그림6> 태그의 구성요소

<그림7> 일반적인 태그 구조

<그림8> 태그 스키마 1 (MySQLicious)

<그림9> 태그 스키마 2 (Scuttle)

<리스트 2> Scuttle relation query

Item(tag)
SELECT i.* FROM Item i, Tag t
WHERE i.itemid = t.itemid AND t.tagname = ‘blog’
Tag(item)
SELECT t.tagname FROM Item i, Tag t
WHERE i.itemid = t.itemid AND t. itemid = ‘1’
Tag()
SELECT tagname FROM Tag
GROUP BY Tagid

‘toxi Solution’ 태그 스키마

<그림 10>의 구조는 ‘Scuttle’보다 태그 관리를 유용하도록 하기 위해 태그 테이블을 하나 더 두고있다. 태그 맵은 아이템과 태그의 게이트웨이와 같은 역할을 한다. 태그 테이블은 태그를 다양한 방법으로 관리할 수 있도록도와준다. 태그 서비스의 대부분은 ‘toxi’의 구조를 적용하고 있다.

<그림10> 태그 스키마 3 (toxi)

추가(Insert)나 갱신(UPDATE) 비용이 다른 스키마구조 보다 많이 들기는 하지만 그 비용보다는선택(SELECT)의 비용이 훨씬 줄어들고 전체의 태그를 보여 주거나 태그에서의 링크 순으로 표시할 때 효과적으로 관리할 수있다.

<리스트 3> toxi relation query

Item(tag)
SELECT i.* FROM Item i, Tagmap tm, Tag t
WHERE t.itemid = tm.itemidAND tm.tagid = t.tagid AND t.tagname = ‘blog’
Tag(item)
SELECT t.tagname FROM Item i, Tagmap tm, Tag t
WHERE i.itemid = tm.itemid AND tm.tagid = t.tagid AND i.itemid = ‘1’
Tag()
SELECT tagname FROM Tag

<그림 10>과 같은 구조의 ‘toxi’에서 약간의 테이블 구조를 변화 시키는 것만으로 자신의 서비스에 맞는, 아니면 경우에 따라 비용이 많이 절감될 수 있는 태그 스키마도 제공해 줄 수 있다.

<그림11> 태그 스키마 3-1 (toxi1)

<그림 11>은 <그림 10>에서 Tagid를 없애고 tagname을 기본 키로 두면서, Item에Tags 필드를 추가한 구조이다. 이 구조는 테이블간의 연결을 많이 줄일 수 있는 구조이다. 하지만 추가(Insert),갱신(Update), 삭제(Delete)의 비용이 ‘toxi’보다 두 배 이상 더 비싸다. 한편, 이용 패턴의 대부분이선택(Select)에 편중되어 있기 때문에 서비스의 흐름을 파악한다면 오히려 비용을 줄일 수 있는 여지도 많이 보이는 구조이기도하다.

<리스트 4> toxi relation query 2

Item(tag)
SELECT i.* FROM Item i, Tagmap tm
WHERE i.itemid = tm.itemidAND tm.tagname = ‘blog’
Tag(item)
SELECT tags FROM Item WHERE itemid = ‘1’
Tag()
SELECT tagname FROM Tag

<그림 11>과 같은 스키마 구조에서의 선택과 추가 등의 비용을 비교해보자.

선택(Select) 비용 : MySQLicious > Scuttle > Toxi > Toxi1
추가(Insert), 갱신(Update), 삭제(Delete) 비용 : MySQLicious
< Scuttle < Toxi < Toxi1

자신이 개발할 태그 시스템의 규모와 용도를 파악하고 위의 스키마를 커스터마이징 한다면, 분명 효과적인 태그 시스템을 개발 할 수 있을 것 이다.

마지막으로 앞에서 설계한 블로그의 포스트를 예로 Toxi 솔루션을 적용해보자.

Toxi 솔루션을 블로그에 적용하기

<그림 12>는 블로그의 스키마에서 나온 blog_post에 태그 스키마를 적용한 모습이다. 이 예에서는블로그의 포스트를 기준으로 태그를 적용한 모습이지만 다른 아이템에서도 적용되는 모습은 대부분 비슷할 것이다. 그리고 <그림12>에서 태그 맵과 태그 테이블을 잘 이용한다면 서비스를 이용하는 모든 사용자의 태그와 그 태그에 대한 모든 분류의정보를 얻고, 사용자에게 어떠한 태그가 가장 인기 있는지의 여부도 파악할 수 있다.

<그림12> blog_post에 테그 스키마를 적용한 모습

<리스트 5> Blog tag relation query

Item(tag)
SELECT b.* FROM blog_post b, Tagmap tm
WHERE b.blogid = ‘10000002’AND b.blogid = tm.blogid AND b.blog_serial = tm.blog_serialAND tm.tagname = ‘blog’
Tag(item)
SELECT tags FROM blog_post
WHERE blogid = ‘10000002’ AND blog_serial = ‘123’
Tag()
SELECT tagname FROM Tag
WHERE blogid = ‘10000002’

지금까지는 한 가지 아이템으로서 태그와의 관계를 구성해 보았다. 같은 태그로 구성된 여러 아이템이 있다고 가정해보자.블로그를 예로 들면 아이템으로 활용가치가 있는 것 중 포스트, 사진, 블로그 심지어 태그까지도 아이템으로 묶을 수 있다. 특히블로거라면 이처럼 서로 다른 아이템을 태그를 통해 한꺼번에 분류하고 싶어할 수도 있다. 아이템으로서의 태그도 중요한 개념이긴하지만 태그는 다른 태그와 조합하여 새로운 아이템으로 구성할 수 있다는 장점을 가지고 있기 때문이다.

이렇게 여러 아이템에 대한 태그와 관계를 스키마로 표현하는 것도 상당히 의미 있고 재미있는 일이다. 이렇게 하는 데에는여러 가지 방법이 있다. ‘toxi’ 스키마를 예로 든다면 각 아이템마다 태그 맵 테이블과 태그 테이블을 따로 두고연결(Union)하는 방법도 있고, 태그 맵에 각 아이템의 특성을 구분할 수 있는 필드를 추가하여 분류할 수도 있다. 많이복잡하고 어려울 수도 있지만 기술적으로 가능하다면 충분히 설계할 만한 가치가 있는 분류 방법이다.

지금까지 태그 시스템에서 알아본 방법은 가장 일반적으로 사용되고 있는 스키마의 형태이다. 아직도 계속 이런 스키마에 대해서 연구 중이다. 태그 시스템을 DBMS가 아닌 파일 시스템으로 구현해 놓은 곳도 쉽게 찾을 수 있다.

현재의 웹 환경은 이전과 달리 다양하고 복잡한 스키마 구조를 요구한다. 그리고 쏟아지는 데이터의 분량 또한 엄청나다.이러한 데이터들은 태그나 다른 툴에 의해 분류되고 공유되어 진다. 지금까지 블로그와 태그 시스템을 통해 그러한 웹 환경의일부분을 살펴보았지만 앞으로는 더욱 다양한 서비스들이 쏟아져 나오고 우리들이 해야 할 일도 늘어날 것이다. 앞서 말한 것처럼이러한 웹 환경에서 유저들이 생산해내는 정보나 데이터의 가치를 더 높여주는 것이야 말로 개발자들이 해야 할 몫이다.

제공 : DB포탈사이트 DBguide.net