재작년~작년에 한창 컨텐츠를 활용하기 위한 방안을 고민 할 때가 있었다.
시간 정보와 공간 정보를 다루기 위한 방법을 고심했었는데
요즘 실무 필드에서 이런 고민을 하는 사람을 많이 접하게 되니
그 때 했던 생각들이 떠오른다.
이번 테터캠프에서도 지역 정보를 활용하기 위한 시도가 많이 엿보였다.
하지만 내가 가진 생각과는 그 활용성이 좀 다른 듯하다.
난 시간 정보를 나열식으로 보지 않고 다차원 축으로 보고 싶다는 생각과
공간 정보를 연속된 공간체로 보지 않고 개별적인 지점으로 보고 싶다는 생각을 했었다.
아직 이런 접근은 어디서도 하고 있는 것 같지 않지만
내후년 쯤이면 내가 가진 생각이 또 어딘가에서 시도 되지 않을까 기대한다.
시간을 다차원 축으로 보는 방법은
[12월 5일, 12월 6일 ...] 의 축과
[아침(... 5일 아침, 6일 아침 ...), 점심(... 5일 점심, 6일 점심 ...), 저녁 (... 5일 점심, 6일 저녁 ...)] 의 축,
[매년 봄, 매년 여름, 매년 가을, 매년 겨울], [매년 크리스마스 ...] 의 축,
(부지런한 사용자라면) [A 양을 만나던 시기, B 양을 만나던 시기, 싱글이던 시기 ...] 의 축 등
여러 기준축을 인덱스로 삼는 것이다.
예를들면 감성적인 밤 시간에 쓴 유치한 편지만을 정렬할 수 있는 기준점을 말한다.
일몰 시간의 사진만 검색하기 위해 EXIF 의 시간과 색상 정보의 정렬 필터를 만들어 본 적이 있는데
이러한 관점이 의외로 쓸모가 있다는 것을 확인할 수 있었다.
공간을 점으로 바라 보는 관점은 공간을 연속된 지점의 집합체로 보지 않기 위한 것이다.
우리는 지리 정보에 익숙하지만 굳이 공간적 연속성을 부여해야만 하는 정보는 생각보다 많지 않다.
그리고 사람들은 자신의 연고가 되는 동네가 아니라면 주소를 기준점으로 삼는데 익숙하지 않다.
우리 회사는 서대문구에 있지만 한 발만 더 가면 중구가 되는 지점이 있고
버스 몇 정거장이면 종로구가 되어 버린다.
그러나 내가 인지하는 지점은 모두 '회사 근처'다.
그래서 회사 근처 맛집을 찾으려면 서대문구, 중구, 종로구를 모두 검색 해야 한다.
이럴 때 주소 정보는 별반 도움이 되지 않는다.
게다가 행정 구역은 얼마든지 변할 수 있어서 주소는 좋은 좌표계가 아니다.
그리고 위도와 경도는 사람에게는 더 최악인 좌표계이다.
하지만 블로그의 포스트와 같이 지도와 연계될 필요가 없는 지역 정보라면
굳이 지도상의 연속된 공간에 배치할 이유가 없다.
그래서 난 모든 공간 정보가 지도 API 와 연계되는 요즘의 분위기에는 만족하지 못하는 편이다.
(다른 표현의 공간적 접근 방법을 한동안 잠재워 버릴 것 같은 분위기라서..)
지도 위에 올려야 하는 정보라면 맛집 정보나 여행 정보와 같은 것들이다.
'한석이네 집'에서 놀았던 일의 집합은 지도에 표현될 필요가 없다.
'한석이네 집'은 실제로 어디에 배치되든 상관 없는 하나의 추상적 공간 지점이니까.
'서울시 강서구 화곡동..'으로 주소가 부여되어야 한다면 그건 더 이상 '한석이네 집'이 아니다.
한석이가 이사를 했다면 '한석이네 집'이라는 태그 빼고는
어떤 지역 태그도 '한석이네 집'을 표현할 수 없는 것이다.
그러나 나에게 '한석이네 집'이라는 공간 정보는 어찌되었든 평생 변하지 않는 좌표 지점이다.
다른 어떤 사용자의 또 다른 '한석이네 집'과는 모양이 같지만 전혀 다른 상대적인 지점일 것이고
그럼에도 이 좌표는 그 사용자 개인의 좌표상에서는 위치가 변하지 않는 고정적인 값이다.
(수학으로 치면 스칼라가 아니라 벡터다.)
각각 개별적인 사용자에게 지역 정보는 이런 상대적인 좌표들의 집합이고
이런 좌표는 연속적인 공간계 위에 배치하지 않은 것이 더 적절하다.
물론 전체 사용자 모두가 절대적인 좌표를 공유해야하는
맛집 정보나 여행 정보와 같은 공식적인 지리 정보는
연속된 공간체인 지도상에 표현되야 마땅하다.
이 두 공간 개념은
싸이월드와 블로그가 별차이가 없지만 완전히 다르 듯이
같은 정보이면서도 완전히 다른 표현이 필요한
서로 등을 맞댄 쌍둥이다.
시간 정보와 공간 정보를 다루기 위한 방법을 고심했었는데
요즘 실무 필드에서 이런 고민을 하는 사람을 많이 접하게 되니
그 때 했던 생각들이 떠오른다.
이번 테터캠프에서도 지역 정보를 활용하기 위한 시도가 많이 엿보였다.
하지만 내가 가진 생각과는 그 활용성이 좀 다른 듯하다.
난 시간 정보를 나열식으로 보지 않고 다차원 축으로 보고 싶다는 생각과
공간 정보를 연속된 공간체로 보지 않고 개별적인 지점으로 보고 싶다는 생각을 했었다.
아직 이런 접근은 어디서도 하고 있는 것 같지 않지만
내후년 쯤이면 내가 가진 생각이 또 어딘가에서 시도 되지 않을까 기대한다.
시간을 다차원 축으로 보는 방법은
[12월 5일, 12월 6일 ...] 의 축과
[아침(... 5일 아침, 6일 아침 ...), 점심(... 5일 점심, 6일 점심 ...), 저녁 (... 5일 점심, 6일 저녁 ...)] 의 축,
[매년 봄, 매년 여름, 매년 가을, 매년 겨울], [매년 크리스마스 ...] 의 축,
(부지런한 사용자라면) [A 양을 만나던 시기, B 양을 만나던 시기, 싱글이던 시기 ...] 의 축 등
여러 기준축을 인덱스로 삼는 것이다.
예를들면 감성적인 밤 시간에 쓴 유치한 편지만을 정렬할 수 있는 기준점을 말한다.
일몰 시간의 사진만 검색하기 위해 EXIF 의 시간과 색상 정보의 정렬 필터를 만들어 본 적이 있는데
이러한 관점이 의외로 쓸모가 있다는 것을 확인할 수 있었다.
공간을 점으로 바라 보는 관점은 공간을 연속된 지점의 집합체로 보지 않기 위한 것이다.
우리는 지리 정보에 익숙하지만 굳이 공간적 연속성을 부여해야만 하는 정보는 생각보다 많지 않다.
그리고 사람들은 자신의 연고가 되는 동네가 아니라면 주소를 기준점으로 삼는데 익숙하지 않다.
우리 회사는 서대문구에 있지만 한 발만 더 가면 중구가 되는 지점이 있고
버스 몇 정거장이면 종로구가 되어 버린다.
그러나 내가 인지하는 지점은 모두 '회사 근처'다.
그래서 회사 근처 맛집을 찾으려면 서대문구, 중구, 종로구를 모두 검색 해야 한다.
이럴 때 주소 정보는 별반 도움이 되지 않는다.
게다가 행정 구역은 얼마든지 변할 수 있어서 주소는 좋은 좌표계가 아니다.
그리고 위도와 경도는 사람에게는 더 최악인 좌표계이다.
하지만 블로그의 포스트와 같이 지도와 연계될 필요가 없는 지역 정보라면
굳이 지도상의 연속된 공간에 배치할 이유가 없다.
그래서 난 모든 공간 정보가 지도 API 와 연계되는 요즘의 분위기에는 만족하지 못하는 편이다.
(다른 표현의 공간적 접근 방법을 한동안 잠재워 버릴 것 같은 분위기라서..)
지도 위에 올려야 하는 정보라면 맛집 정보나 여행 정보와 같은 것들이다.
'한석이네 집'에서 놀았던 일의 집합은 지도에 표현될 필요가 없다.
'한석이네 집'은 실제로 어디에 배치되든 상관 없는 하나의 추상적 공간 지점이니까.
'서울시 강서구 화곡동..'으로 주소가 부여되어야 한다면 그건 더 이상 '한석이네 집'이 아니다.
한석이가 이사를 했다면 '한석이네 집'이라는 태그 빼고는
어떤 지역 태그도 '한석이네 집'을 표현할 수 없는 것이다.
그러나 나에게 '한석이네 집'이라는 공간 정보는 어찌되었든 평생 변하지 않는 좌표 지점이다.
다른 어떤 사용자의 또 다른 '한석이네 집'과는 모양이 같지만 전혀 다른 상대적인 지점일 것이고
그럼에도 이 좌표는 그 사용자 개인의 좌표상에서는 위치가 변하지 않는 고정적인 값이다.
(수학으로 치면 스칼라가 아니라 벡터다.)
각각 개별적인 사용자에게 지역 정보는 이런 상대적인 좌표들의 집합이고
이런 좌표는 연속적인 공간계 위에 배치하지 않은 것이 더 적절하다.
물론 전체 사용자 모두가 절대적인 좌표를 공유해야하는
맛집 정보나 여행 정보와 같은 공식적인 지리 정보는
연속된 공간체인 지도상에 표현되야 마땅하다.
이 두 공간 개념은
싸이월드와 블로그가 별차이가 없지만 완전히 다르 듯이
같은 정보이면서도 완전히 다른 표현이 필요한
서로 등을 맞댄 쌍둥이다.