가늘어도 긴놈이 장땡

퇴근할라는 김 모 수석 붙잡고 나눈 대화중 건질만한거 몇가지.

Posted by maceo

이베이 아키텍쳐 가 작년에 화제였다고 한다. 뒤늦게 알고선 회사에 공유차원에서 뿌렸다. 다들 어느 정도 충격을 받은 분위기. 그런데 이번에 MS에서 컨설팅하러 들어온 김 모 수석 컨설턴트에게 이베이 아키텍쳐에 대한 의견을 물었더니 흥미로운 대답을 해줬다.

"이베이 아키텍쳐요? DB를 SAM파일 수준으로만 사용하고 그 위에 OR매핑 올린거 말씀이죠? 몇년전에는 몰라도 지금은 시대에 뒤떨어인 아키텍쳐지요. 이런 아키텍쳐의 근본적인 사상은 옛날 TP모니터 시절, 모든 트랜잭션은 TP모니터에서 관리해야 한다는 사상에서 나온건데 이건 너무 이상적인 것이죠.

이거 만들 때 SUN에서 이베이에 상당 금액을 펀딩해서 레퍼런스 한번 만들 작정으로 밀어붙인거지, 그게 아니었으면 못했을겁니다. 일년 반정도 걸린걸로 알고 있습니다.  요즘의 추세는 용도별/업무별로 DB를 분리하고, 이건 똑같습니다만, EAI를 도입해서 업무가 비동기적으로 처리될 수 있도록 하는겁니다. 여러 DB를 참조하는 요구사항은 최대한 쳐내긴 하지만, 그렇지 못한 것들은 EAI 를 태워서 비동기적으로 처리합니다. 그렇게 했을 때 만족할만한 응답시간을 보이지 못하는 것들은 가끔 분산트랜잭션을 써서라도 동기적으로 처리하기도 합니다. 물론 성능에 희생이 약간 있습니다. MSDTC를 켜놓으면 관리상 어려움도 있죠. 하지만 이베이 수준의 OR매퍼 새로 만드는 것보다는 훨씬 쉽습니다..

KT NeOSS사이트가 2004년 당시 완전 재구축할 때 저런 아키텍쳐를 기반으로 했습니다. 당시로써는 MS플랫폼하에 세계에서 몇손가락 안에 꼽히는 규모였죠."

덧붙이자면 KT NeOSS 는 KT의 네트워크 관련된 고객 영업지원 시스템인데, 메가패스, ADSL 전용망  전화 관련된 기기 관리 회선 관리 고객 관리 뭐 그런 것들 해준다. 김 수석 얘기로는 회선이 2억 넘고 고객숫자도 거의 1억(개인,기업고객들..) 서비스 사용기록 등등의 데이터는 상상을 초월한다고 한다. 이런 사이트는 각 업무별로 DB를 분리하고(슈퍼돔 64way 16대가 들어가  있다) EAI로는 BizTalk을 썼다고 한다. 잘 돌아간다네~

그리고 Scalibility 관련하여 마이스페이스 DBA랑 같이 교육받으면서 들었다면서 마이스페이스 사례도 얘기해줬다. 마이스페이스의 트래픽은 정말 상상을 초월한다. 이베이보다도 훨씬 크다. 여기는 SQL서버 인스턴스가 500개가 돌아간다고 한다. 당연히 용도별로 DB분리되어 있는데, 여기 아키텍쳐에서 신기한 것은 캐쉬 데이터베이스가 있다는거다. 자주 사용되는 데이터를 별도의 DB서버에 갖다놓고 거기서 읽어가게 한다는거지. 그런 서버가 메인DB앞단에 수십대가 있다고 한다. 캐쉬할 데이터는 전날치 트래픽을 분석해서 자주 요청되는 데이터들을 모아서 하루에 한번씩 각 서버에 배치시켜 놓는다고. 여기에 SQL2005 의 Shared database 기술이 쓰였고, 데이터 갖다놓는 알고리즘은 자체적으로 만들었다는구먼. 아 신기한 아키텍쳐다...

아, 오라클 10g의 RAC에 대한 의견도 피력함. 실제 헤비한 로드가 들어오는 운영상황에서는 8 node 정도가 한계이고 더 이상 붙이면 아무리 메모리 공유를 한다고 하더라도 노드들끼리 메모리 동기화시키는 로드 때문에 성능향상이 별로 없다고.... 따라서 이베이나 마이스페이스급 트래픽을 보이는 곳에서는 먹히지 않는 방법이라고 한다. 이에 대해 나름 한국 오라클 출신 울팀 권대리는 "MS사람답게 얘기하네요" 라는 짤막한 촌평을... ㅎㅎㅎ 오라클 구루들은 이에 대해 뭐라 그럴지 궁금하군....

--------------

DB가 용도별로 쪼개져 있는거 좋다. 그런데 비즈니스 로직은 어떻게 되어야 할까? DB에 sp의 형태로 들어가 있어야 하나? 도메인 레이어가 있어야 하나? 시스템 아키텍쳐와는 별개로 SW아키텍쳐를 구성하는 것도 참 문제다. 정답이 없는건 당연한데, 정답에 접근하는 방법조차도 나와 있는게 너무 없다. 아키텍쳐는 역시 어렵다.

--------------

MCA:Database 라는게 생겼다. Microsoft Certified Architect : Database 이다. 국내엔 한명도 없다. 한국MS에도 없다. 전세계에는 100명 정도란다. MS 프로덕트 그룹하고 바로 컨택을 할 수 있는 거의 유일한 통로라는군. 미국가서 5주 교육받는데 2만5천 달러다. 교육받고 셤보는데 드럽게 어렵다고 한다. MS홈페쥐가서 찾아보자.

Posted by maceo

  실전 코드로 배우는 실용주의 디자인 패턴  

앨런 홀럽 지음, 송치형 옮김
너무 단순한 예제들 때문에 실제 프로젝트에서의 패턴 활용법을 깊이 있게 이해할 수 없는 기존의 책들과 달리, '라이프 게임'과 '소형 내장 데이터베이스'를 구현해 가며 패턴을 학습하도록 한다. 두 프로그램을 통해 상용 제품 수준의 애플리케이션에서 실제로 패턴을 활용할 수 있는 방법을 익히게 되는 것이다.

 환상적인 책!!!!! 디자인 패턴 책을 몇권 보고 실무에 조금 적용해본 사람이라면 객체 지향 소프트웨어 설계가 얼마나 어려운지, 적절한 곳에 적절한 패턴을 사용하는 것이 얼마나 헷갈리는 일인지 피부로 느끼고 있을 것임. 이 책은 바로 딱 그런 상태에 있는 개발자들을 위한 책임. 이런 좋은 책을 내준 사이텍 미디어에 감사를...

Posted by maceo

일전에 번역한 1TB 를 1시간에 로드하기를 근간으로 하고 sqlleade.com 의 문서도 읽어보고

여러가지 테스트를 해본 결과, 다음 설정이 베스트가 아닌가 싶다.

A서버(2000 or 2005) -> B서버(2005) 로 BIG_TABLE 을 이관한다고 가정하면

1. B서버에 SSIS 를 설치하고

2. B서버에 BIG_TABLE 을 생성. clustered index 도 생성해줌. 2005라면 파티션드 테이블로 함. 파티션을 n개로 했다면...

3. A서버의 BIG_TABLE을 읽어서 B서버의 BIG_TABLE로 FastLoad 하는 n개의 SSIS 패키지를 생성. SSIS와 SQL2005가 같은 머신에 있으면 OLEDB대상 말고 SQL서버 대상으로 함. 이건 Shared Memory를 통해서 DB에 데이터 넣으므로 조금 더 빠름. FastLoad 할 때는 TABLOCK 잡도록 함. 읽어올 때 where 조건은 clustered index 를 기준으로 데이터 안겹치게 함. 파티션 테이블 만들때 기준으로 하면 될 것임. 데이터 읽어올때는 order by clustered index 컬럼을 넣어줌. 이렇게 하면 데이터 들어가는 순서와 클러스터드 인덱스의 정렬순서가 동일하기 때문에 추가적인 부하가 거의 없이 클러스터드 인덱스를 만들 수 있음. 자세한 것은 BOL의 BULK INSERT 성능 최적화 부분을 읽어보면 됨.

4. 패키지를 실행하는 bat파일을 n개 만들고 한꺼번에 실행.

5. 네크웍을 마구 써대면서 테이블에 집어넣음. 테이블에 데이터 넣으면서 블러킹 발생하지 않는지 관찰. 파티션드 테이블이므로 블러킹이 없을 것임. 만약 2000 서버의 통짜 테이블이라면 FastLoad, rows_per_batch = 2500 commit_size = 2500 정도로 하는게 익스텐트 할당할 때 블러킹 거의 없이 잘 들어가는 것 같음.

위와 같이 하면 bcp로 텍스트로 내리는 과정 없이 네트웍타고 바로 넣어버리기 때문에 무쟈게 빠름. 아, 서버간 네트웍은 기가비트 이더넷이고 A서버 B서버 스토리지 모두가 괴물급 스토리지면 완전 대박임.

Posted by maceo

  T-SQL Progarmming - Inside Microsoft SQL Server 2005  

Itzik Ben-Gan 외 지음, 필라넷 DB 사업부 옮김, 김정선 감수
T-SQL 내부 아키텍처에 대한 상세한 정보와 풍부한 프로그래밍 레퍼런스를 소개한다. 데이터베이스 개발자와 관리자가 실제 운영 환경에서 직면할 수 있는 복잡한 문제에 대한 솔루션으로 활용할 수 있는 권장 사례, 전문가의 비법, 예제 코드를 얻을 수 있다.

SQL2000 의 T-SQL 개발에 어느정도 익숙한 개발자라면 큰 무리없이 읽을 수 있다. 대단한 충격을 주는 내용은 아니지만 구석구석 알아두면 좋은 팁들이 많다. 번역 상당히 잘된 것 같다. SQL서버는 안그래도 자료도 별로 없고 공부할꺼리도 별로 없는데 그나마 이거라도 있으니 다행이다. 평이 좀 시큰둥하긴 한데, 상당히 좋은 책이다 ;-)

이제 1/3 가까이 읽었는데 역시 영어라 진도가 잘 안나가긴 한다. 대체로 쿼리의 난이도가 높지는 않지만, 잊기 쉬운 기본적인 사항을 잘 설명해주고 있다. 미처 몰랐던 것들도 몇개 배웠다. 역시나 좋은 책이다. SQL2005 공부하는 사람들은 기본기를 다지는 차원에서 꼭 봐야할 듯.







켄 헨더슨의 아키텍쳐 & 인터널 책이 MS내부 엔지니어 교육수준으로 200레벨밖에 안된다고 한다. 한국MS 내부 엔지니어가 그랬으니 이건 확실하다. 내부 엔지니어 교육은 500레벨까지 있다. 위의 책들은 한 150레벨 정도 되려나? 생짜 초보자용 책은 아니지만 이해에 크게 무리는 없으니...

그런데 상당수의 DBA들이 켄 헨더슨 책은 말할 것도 없고 저정도 되는 책도 안본다. 영어이기 때문이다. 책도 안보고 white paper 도 잘 안본다. 그러니까 결국 누구나 볼 수 있는 자료도 안본다는 얘기다. 이런 사람들이라면 아마도 MS기준으로 한 110~120레벨 되려나? 이정도는 상식적인 사고가 가능한 사람이 2,3년 경험 쌓으면 누구나 도달할 수 있다. 아무나 뽑아놓고 굴리면 다 할 수 있다. 이래서는 전혀 차별성이 없다.

사실 200레벨을 완벽하게 이해하는 DBA도 국내엔 몇 없을 걸로 본다. 서버 내부로 들어가면 사실상 OS 공부나 마찬가지다. 비전공자의 한계가 여기서 명확하게 드러난다. 그리고 국내 실정상 웹개발 몇년 하다가 DB로 오는 경우가 많아서 멀티스레드, IO, 메모리 관리 경험이 없는 DBA들이 대부분이다. KAIST, 서울대 정도 말고는 학부레벨에서 OS를 직접 만들어본 전산 전공자도 거의 없으니 어차피 대부분의 전산전공자들도 OS에 대한 이해는 피상적일 수밖에 없을거다. 위에서 잠깐 얘기한 한국MS 엔지니어도 SQLOS가 전문 영역이긴 한데, 자기도 전산전공이지만 OS는 책으로만 배웠다고 했다. 이 사람 얘기로는 한국MS SQL서버 엔지니어들은 Inside Windows 2000 하고 Inside SQL Server 2000, 아키텍쳐 & 인터널 책을 두세번 반복해서 읽는다고 한다. 그러면 서버 내부 돌아가는게 대충 이해가 간다는군. 근데 아키텍쳐 & 인터널 읽어보면 알겠지만 존내 어렵다 -_-;;;;

하여간 DB밑바닥은 밑바닥으로 가면 갈수록 이해가 어렵고 그다지 중요성도 못느끼기 때문에 DB에 관심있다는 사람들은 튜닝 정도 하다가 대부분 위쪽 영역으로 올라간다. 모델링, 메타데이터, 데이터 아키텍쳐 뭐 그런 영역 말이다. 하지만 역시 거기도 상식적인 사고가 가능하면 이해가 어렵지 않은 분야라 그냥 열심히만 하면 된다. 차라리 그 동네에서 이야기하는 이상을 실현하기 위해서 조직을 바꿔내는게 훨씬 더 힘든 문제라면 문제겠지...

아 진짜 두서없다.

그러니까 결론은 DB하는 사람들 공부 의외로 디게 안한다는거다. 고시공부하듯 DB공부하는 사람 하나도 못봤다. 근데 뭐든 경지에 오르려면 고시공부하듯 최소 1년이상은 파야된다. 떡하니 고시붙은건 아니지만 그 비슷한 공부를 해보니 알겠더라. 근데 문제는 이렇게 공부해봐야 알아주는 사람도 별로 없고 돈버는길도 별로 안보인다는거다. 흠... 그래서 다들 공부를 안하는거였나? -_-;;;;;;;

Posted by maceo

역시나 sqlleader.com 에 질문 & 답

-----------

제 목    Re) 패키지 외부에서 변수값 넘기는 예제에서 질문 · 작성자    한대성 (MVP) · 글정보    조회 : 10, 등록일 : 2007/04/17 16:57

안녕하세요..박노철 님..^^ 오랫만입니다.. 언제 조만간 온라인에서 자주 뵌 분드라고 번개 한 번 합시다.ㅎㅎ   해결 방법으로는, 값을 지정하기 전에 EvaluateAsExpression 의 속성 값을 False로 해 버리는 것도 같이 추가하면 됩니다.   예)  /SET "\Package.Variables[사용자::day].Properties[EvaluateAsExpression]";False /SET "\Package.Variables[사용자::day].Properties[Value]";2 패키지 많이 작성하시는가 보내요..^^ 좋은 자료나 특이한 상황, 경험 있으시면 같이 공유 부탁.ㅎㅎ   그럼 수고하세요. 작성자 : 박노철 , 등록일 : 2007-04-17 오후 3:49:00 dtexec 로 패키지 실행할 때 패키지 내부의 변수값을 조작하기 위해서   /SET '\Package.Variables[사용자::day].Properties[Value]';'16'   이렇게 커맨드 라인에 추가를 했는데요 값이 바뀌지가 않습니다. 패키지 내부에서 사용자::day 변수는 다음과 같이 선언되어 있습니다.   사용자::day      (DT_WSTR,2)(DAY(GETDATE()) (EvaluateAsExpression 은 True 입니다)   제 생각에는 커맨드 라인에서 값을 정상적으로 넘기긴 했지만, 실제로 패키지가 수행될 때는 변수에 정의된 것이 수행되면서 값을 바꿔버리는게 아닌가 하는 추측을 해봤습니다. 그래서 저 변수의 EvaluateAsExpression 을 False 로 하고 값은 01 로 바꿨습니다. 즉 상수로 고정시킨거죠. 그러니까 원래 의도했던대로 16이 들어가더군요. 이런게 필요한 이유는 이렇습니다. 매일 한번씩 FTP로 데이터를 읽어서 DB에 넣는 패키지가 있는데요, 이게 정상적으로 수행되면 문제가 없지만 혹시라도 실패해서 전날이나 전전날걸 돌려야 할 때 수동으로 값을 넣기 위함입니다. 그런데 예제에는 ExecDate 라는 값을 20070201 인가로 고정했더군요. 하지만 실제로는 SQL Agent 에 걸어놓고 지가 알아서 그날치 데이터를 읽어오길 원하므로 수행날짜 변수에 GETDATE() 를 사용할 수 밖에 없는 상황입니다만...   정리하자면 질문은 이렇습니다.   'EvaluateAsExpression = True 인 변수에 대해서도 커맨드 라인에서 값을 넘겨주는 방법은 없는가?'   입니다. 언제나 많은 도움 감사드리고 있습니다. 그럼 수고하세요 ^^

박노철 예 번개 좋지요~ ㅎㅎㅎ 저런 간단한 방법이 있었다니 콜럼버스 달걀깨듯 하시는군요 ㅋ 감사합니다 ^^ 2007/04/18

Posted by maceo

역시나 sqlleader.com 에서 주고받은 문답...

----------

제 목   Re) 조회 변환 캐싱하는거 병렬 진행 맞나요??? · 작성자    한대성 · 글정보   Hit : 14, Date : 2007/03/19 21:34

안녕하세요..^^   전에 다음과 같은 질문에 대해 이렇게 답변 드린 적이 있었네요..      Q) 그림은 순차적이지만 조회 변환을 위한 데이터 캐시는 한꺼번에 하는게 맞는건가요??    A) 넵.. 패키지 내에 있는 조회 변환 데이터를 먼저 와장창 캐싱 한 후에 작업을 수행합니다.   조회 변환에 대해 테스트 할 때 다른 작업들에 비해 먼저 캐싱하는 것만 확인하였지, 개별 조회 작업 간의 순서에 대해서는 별 생각 없어서 "와장창 (한번에)" 라는 표현으로 설명드렸는데, 질문 올리신 것 보고 테스트 해 보니 박노철님 말씀대로 순차적으로 캐싱되네요..   혹시나 해서 Execution Tree를 여러 개 생성되도록 해보고, 여러 데이터 흐름 작업에 대해 동시에 실행을 시켜도 모두 순차적으로 캐싱되는 것 같습니다.   아마도 하나의 Lookup Cache 영역을 이용하기 때문이지 않을까 싶네요..(추측)   테스트 하다가 재미있는 것을 확인했는데요.. 동일한 조회 쿼리(or 테이블)에 대해 동일한 열을 캐싱시킬 때에는 한 번만 캐싱한다는 것입니다..(자료를 찾아보니 실제로 그렇다고 하네요..^^)   훔훔훔... 재미있는 것 알게 되었습니다..^^캄사.....ㅎㅎ             작성자 : 박노철 , 등록일 : 2007-03-19 오후 3:40:00 안녕하세요. 간만에 질문드립니다. ^^   조회 변환의 설정을 디폴트로 해놓고   조회 변환에 쿼리 입력하고 이런 조회 변환을 20개를 주욱 이어붙였을 경우 '동시에' 20개의 커넥션을 DB에 열어서 데이터를 주우욱 읽어오는 걸로 알고 있었습니다. 예전에 그렇게 설명해주신 것 같구요.. 그런데 오늘 로그를  살펴보니까 각 조회 변환이 데이터 캐시하는게 순차적이더군요... 간단하게 정리하면 이렇습니다.   --goodsdaq_brand ssis 15:05:05 ~ 15:05:08 --maker ssis 15:05:09 ~ 15:05:10 --dealersettletbl ssis 15:05:12 ~ 15:05:30 --custom ssis 15:05:32 ~ 15:07:36 --dsdeliverygroup ssis 15:07:46 ~ 15:07:52 --goods_discount_list ssis 15:07:54 ~ 15:07:59 --freeint_charge_goods ssis 15:08:03 ~ 15:08:12 --fn_get_goods_satisfaction_point ssis 15:08:14 ~ 15:11:11   (후략..)   그림상으로 goodsdaq_brand 이 가장 첫번째 오는 조회변환입니다. 사실 조회 변환 전에 OLEDB 원본 3개에서 테이블을 하나씩 읽어서 병합 조인을 하고 그 결과를 20여개의 조회변환을 주욱 태우는 건데요, 3개의 OLEDB원본과 첫번째 조회변환 goodsdaq_brand는 동시에 시작이 됩니다만, 늘어서 있는 20개의 조회변환이 데이터를 캐시해오는 것은 순차적인 것 같네요. 이게 정상적인건가요?? 제가 잘못본건가요??? 아니면.. 설정을 뭔가 바꿀 수 있는게 있는건가요??? 사실 메모리에 데이터 다 들고 있을거면 그냥 15:05:05 에 패키지 스타트하면 커넥션 23개 동시에 열어서 모든 조회 변환의 start 시간이 동일하게 찍혀도 될 것 같은데... 어찌된 일인지 도움을 좀 부탁드립니다.   참고로 EngineThread 는 32, MaxConcurrentExecutables 도 32 입니다 SSIS 엔진이 도는 서버는 32way 입니다.

박노철 네... 그렇군요. 조회변환에서 캐싱하는 것 중에서 시간이 꽤 많이 걸리는 것들이 3개 정도 있어서 이걸 OLE DB 원본으로 빼고 병합조인-left join 으로 처리했더니 두배이상 느려지더군요. OLE DB 원본 3개는 동시에 읽어오니까 데이터 읽어오는 시간은 분명히 줄어드는 것을 확인했는데요, 병합조인이 3개 들어가고 그게 다 left join 이어서 그런지... 그리고 찾아보셨다는 그 자료는 어디에 있는것이죠?? ^^

Posted by maceo

-마이크로 컨텐츠란 무엇인가?
데이터를 최소 단위로 만드는거. 더이상 분리할 수 없는...
활용되기 쉽게.
이런 요소들이 독립된 URL identity 을 가지고 활용할 수 있도록 한다. 퍼머링크.
다른 것들과 붙어서 독립적으로 활용될 수 있도록 한다.

-마이크로 컨텐츠의 활용

사진클릭하면 별도 화면으로 넘어감
동영상 클릭하면 ap 동영상 보이고 딴것들도...

-마이크로 컨텐츠를 활용한 데이터간 리믹스
그때그때 필요한 컨텍스트에 따라서 작은 데이터를 가져감.
(머. 관련 상품, 상품평도 그런거?)
이거 야후 에디터가 안하고 자동으로 해줄수는 없으까?
아니면 사람들이 이거 사용할 수 있도록 할 수는 없으까?
(음. 이거 자기 상품에 붙은 상품평은 그 판매자가 가져가서 활용할 수 있도록 하면?
걔네들 자체 사이트에 쉽게 붙일 수 있도록? 매출은 어디서 발생? -_-;)

-구조화된 데이터
생산하는거 귀찮아함. 태그달고~

-구조화된 데이터의 생산 - 구글 베이스
(준비된 카테고리를 제공하는건 어렵다~ 구조 자체의 경직성도 문제. 태그는 자유롭다. 그 중간은 어디쯤? 생산하기에도 덜 귀찮고 시스템이 분류하기에도 편한 형태는???)

Application 2.0 - 소비와 유통의 관점.

App2.0 - 소비(1)검색과 브라우징
브라우징->검색->관계를 통한 필터링(개인화검색 소셜검색 북마크 태깅 클러스터링 RSS)
(상품검색에서 소셜검색이 의미가 있나? 내가 아는 애가 산거를 먼저 보여준다??? 다른 사람이 많이 산거를 보여준다? 근데 그거 이미 베스트셀러자나? -_-;;;;
개인화 검색을 고도화하는건 어떤가? 내가 생각지도 못한 죽이는 상품을 알아서 먼저 갈쳐주는거~ 아니면. 나의 취향을 반영한 검색? 나의 취향을 고려한 추천? 음. 근데 추천상품같은거는 그렇게 주의해서 안보는데... 검색결과가 나의 취향 반영한거라면?? )

app2.0 - 소비(2) 소셜화
orkut.com 에서 관계를 맺게 해줌. 그담에 뭐하까? sn2.0 에서 데이터가 확 붙음. 관계를 만들고 이 네트워크에 데이터를 싣는다. 이렇게 해서 데이터를 소비. 하지만 기존의 IA, 디렉토리, 사용성 등등 아직도 필요. 기본적인 것임.

데이터는 보여주기만 하면 별로.. 사용자의 관계가 들어오면 대박!!!! 네이버 서비스들 봐도 그렇더라. 서비스에 사람의 힘을 도입해야 된다. (소셜 쇼핑이란게 가능한가? 내 친구가 g마켓에서 물건사는거 볼 수 있으면 어떠려나??? 근데 쇼핑목록은 공개안하고 싶을 경우도 많은데? 민망한거 사면 어쩔라고? -_-;;;;)

요즘은 관계가 있는 곳에 사람들이 활동. 데이터만 있는 곳은 별로...

음... 바빠서 막넘어간다. ㅋㅋㅋㅋㅋㅋ

Posted by maceo

거의 실시간 포스팅? ㅎㅎㅎㅎ
---------------------------------
데이터 2.0 + 애플리케이션 2.0 = Web2.0

데이터 2.0

데이터의 정의 -> 뭘 서비스할 것인가? 아마존->상품 / 플리커->사진 / 벅스->음악
서비스의 본질 정의

Q)"새로운 쇼핑경험을 서비스한다" 이건 데이터냐 애플리케이션이냐?
쇼핑경험을 구성하는것은? 가격은 기본. 내가 뭘 원하는지 잘 모를때도 알아서 제공해줄 수 있으면???  쇼핑하는 재미도???? 어떤게 쇼핑의 재미를 구성하나?????

데이터 생산 -> 어떻게 데이터를 생산할 것인가?
생산의 방법이 서비스의 방향을 결정. 구글은 엔진이 긁어옴. 야후는 사람이. 서비스하려는 데이터는 동일. 기회 별로 없다.

데이터 가공 -> 정제, 카테고라이징 메타데이터. 이거 잘하는 사람 별로 없다. 기회 있음


애플리케이션 2.0

입력/출력 UI

전달 -> 검색/브라이징/구독

활용 -> 관계맺기. 공급자/사용자/데이터간 IA, 그루핑 등등...
-------------------------------------------------------
운영 레이어. 데이터 관리 및 업데이트 기능 관리 및 업데이트 CS

1.0 에서는 데이터 애플리케이션 1:1
2.0 에서 데이터는 여러 애플리케이션을 찾아 해맨다. 더 많은 app 에서 이거 더 많이 쓸 수 있도록. (RSS로 데이터 뿌린다? 마이크로포맷?) 데이터는 많이 쓰일수록 가치를 지닌다. --> 일반인들이 관심있나?

2.0 에서 애플리케이션은 여러 데이터를 다룰 수 있어야 한다. 상품상세 페쥐에서 여러 사이트꺼 보여주기? 레뷰 컨텐츠 제휴???? 딴데 상품을 보여줄 수는 없다. API, 매쉬업이 이런거 위해서 존재.

데이터 : 애플 = n : n 으로. 하는 여러가지 관점/기법

네이버 검색은 애플리케이션. 여러 데이터를 다룰 수 있다. 네이버는 버티컬 서비스 위주로 발전. 1차는 버티컬 서비스 붙이기. 2차는 이거 모으기. 상거래는 상품 버티컬. 데이터를 통합검색에서 잘 보이게 할 수 있도록 저장잘하는게 훨씬 중요했다. 네이버가 여러 블로그 검색하는거는 더 좋은 데이터 찾아서 하는거였음. 네티즌이 공격해서 그런거 아니었음.

각자 잘 하는 것을 더 잘하고 잘 하는 선수들끼리 서로 결합하자!

뭐를 잘할거냐?????!!!! 데이터? 애플리케이션? 모자라는건 어디서 채워오나???

확장된 개념의 데이터??? 가 뭐냐?

data2.0 = 확장된 개념의 데이터
데이터의 롱테일 -> 컨텍스트의 롱테일로 확장.
새로운 데이터. 네이버 책검색, 지도 등등 돈 마니 드는것들은 아직 웹에 없음. 이거 올리면 새로운거. 근데 돈도 없는데 어떻게 할래? 사실상 이제 불가능.

음악(텍스트.이미지.오디오.동영상모두 포함) 영화도 책도 부동산도 지역도...
특정 주제에서 포맷별로 확장됨.
이것도 거의 끝났음. 이거 구현되는게 사용자 생산 플랫폼의 기능 확장. 나 뿐만 아니라 수많은 사람들이 데이터를 생산하도록 변화됨. 데이터의 롱테일. 블로그의 의의...

데이터의 롱테일. 이거 어떻게 찾을까? 어떻게 전달해줄까? 새로운 문제로 대두. 그래서 메타화로 발전. 추천/평가/리뷰/링크/관계/메타/어텐션 등등... 이런거 전문으로 다루는 애플리케이션도 생김. 메타 데이터들이 서로 관계를 맺으면서 다른 가치, 다른 의미를 생성. -> 컨텍스트의 롱테일. 대부분의 web2.0 서비스들이 컨텍스트의 롱테일을 구현. 나에게 이런 데이터가 있는가???

data2.0 = 사용자가 함께 만드는 데이터(1) who?
데이터는 사용자와 공급자가 함께 만든다.
각자의 역할은???
ucc 를 위해서는 사용자들에게 플랫폼을 준다. 게시판.블로그.
제휴/b2b는 플랫폼을 선별된 사람들에게만 준다. 데이터를 제공받으면서 마케팅 플랫폼을 제공. 의외로 좋은 데이터 준다. 제대로 컨텐츠 만드느 사람들은 선별된 사람들. 네이버 플레이어 픽스카우. (사용자를 부각시키는 상거래?)

데이터 포트폴리오 전략 필요. 방향을 정의. 누가 무엇을 만들게 할 거냐? 서비스의 방향을 결정. 사람이 만들게 할거냐? 크롤링? 제휴? 등등의 전략이 필요함... 정확한 데이터가 필요하면 우리가 직접? ucc 도 검증할 수 있으면 ucc로... 등등의 전략. 리뷰. 야후는 직접. 구글 로컬은 외부 리뷰 검색해서 보여줌.

플랫폼 구축 및 커버리지 확보 전략.

ucc , rmc 가 서로를 보완해주는 관계를 만들어야 한다.
rmc 시드데이터로 기능할 수 있어야 함. rmc 보고 ucc 생산. 부족한 부분 채워주고...
(핸폰 카메라로 찍어서 상품평에 쉽게 넣을 수 있도록?)
(지도에 이베이 경매 물품 뿌려주기)

data2.0 = 사용자가 함께 만드는 데이터(2) why?

커뮤니티 붐일때 그거 붙여서 재미본데는 커뮤니티 솔루션 업체. 나중에 썰렁~
ucc도 막 붙이면 이렇게 될 것 같음. 사용자는 꼭 필요한 이유가 있으면 알아서 올린다.
이유를 줘야함. 상품평? 뭐하러 올려? 포인트 준데. 뭐주까?
필요. 이걸 다 충족시켜야 함. 브랜드 안정성 시스템 안정성 모두 필요. 상품평은 굳이 집착하는 컨텐츠는 아님. 정성들여 쓴 것들은 블로그에? 그럼 그걸 끌어올 수 있어야 함.  상품 상세 페쥐에 검색엔진 검색 결과 링크???

나랑 관계가 있는 곳에다가 생산함. 원래 있던 곳. 아는 사람 있는 곳. 주목원해서 오픈네트워크에 올린다던가.. 다른 데이터나 애플. 여기 올리면 딴데서 갖다쓰기 쉽다. 이런 이유들이 존재... 새로운 상거래 사이트는 어떻게 포지셔닝 해야 하나? 이럴때는 소셜 애플리케이션의 형태를 띤다.
(사람을 묶어둘 수 있는 기능을 상거래 사이트에 구현할 수는 없나?)

이유. 를 충족할 수 있어야 하는데 대부분의 사업기획서는 이게 빠져있다.


동영상 ucc의 생산이유? (1)
jumpcut.com 기능의 재공. 딴데 없다. 웹에서 동영상 편집. 유일하다.
eyespot.com 재료의 제공. 기능도 있지만 재료도 함께 제공.

인센티브의 제공.
인프라의 제공.

->이유를 제공하려는것.

동영상 ucc의 생산이유? (2)
mncast.com 은 여러 인디 사이트와 제휴를 맺어서 동영상 업로드 모듈 붙여주고 그거 공유.
어드민같은거 제공. mncast.com 은 동영상 올릴 니드가 있는 곳으로 찾아갔음. 그담에 이거를 쉽게 퍼갈 수 있도록. 데이터저장소와 컨텍스트애플리케이션의 분리되는 모습. 생산,소비의 이슈를 모두 해결. 하지만 생산을 계약 형태로 풀어냄. 1.0 방식. 이거를 오픈마켓 형태로 풀어낼 수는 없나...? 누구나 갖다 써서 붙일 수 있도록. api, 서비스 행태? (유튜브는 마이스페이스 통해서 퍼지기 시작)

data2.0 = 사용자가 함게 만드는 데이터 (2) what?
사용자는 생산만 하는게 아니고 ucc만 보고 싶어하는 사람도 적다. 재생산이 이슈!

data2.0 = 사용자가 함게 만드는 데이터 (2) what?
재생산이 많이 일어난다. 재생산을 쉽게해주려면? 재료와 작업실의 제공이 필요.

Posted by maceo

Posted by maceo