기억 - Universal Search

한국 과제 이름 : kPrism

오래 전부터 구글 검색 결과 페이지는 10 blue links 로 알려져 있었다. 오랜 세월이 지난 지금에도 뭔가 마땅한 결과를 못 보여 주면 전통적인 양식을 따른다. 전통적인 web result UI 에도 여러 가지 의미들이 있지만, 이 단조로운 결과를 여러 의미로 다채롭게 만들기 위해서 오랫동안 노력들을 해 왔고, 구글에 조인했던 2007년 즈음은 이것의 한창이었던 시기였었다. 가까운 경쟁자인 네이버 검색 결과 페이지를 보면 다양한 조각들로 되어 있고, 한편의 삐딱한 시각으로는 사용자가 뭘 좋아할 지 몰라서 다 준비해 본다. 라는 시각도 있어서 최선을 다한 것이었냐 라는 논란이 일기도 했던 시기였다.

이전의 모바일, 임베디드의 때를 싹 지우고 새 마음으로 구글에 조인해서 맡게 된 첫번째 과제였고, 과제 이름은 kPrism. Prism 은 무지개처럼 펼쳐지는 그거 맞고, k 가 야심차게 붙어 있는데, Korea 의 K 맞다. 8명이서 나눠서 하던 나름 큰 규모의 과제였었고, 여기서 다양한 결과들을 모으고 붙이는 universal search, 한국어로도 유니버설 검색 과제가 있었더랬다.

2008 년 1월 런치된 한국형 유니버설 검색

챌린지들

참고로 당시에는 software engineer 들이 닥치는 대로 풀어야 하는 문제들을 풀어 나가던 시기였기에 뭐든 했더랬다. 지금으로 치면 frontend 와 backend가 나누어져 있는 구조인데, backend 에서 랭킹을 포함해서 보여 주고 싶은 결과의 구조를 다 만들어 주고, frontend는 주어진 구조를 잘 표현해서 화면에 배치하고 사용자의 행동을 담아 내는 역할을 했다. 프론트엔드부터 챙겨 보자면, 당시 크롬이 있기 전이었기에 툴툴거리면서 Internet Explorer 와 Firefox 를 켜며 한땀한땀 다루었었고, 아직 진지한 Javascript가 쓰이기 전이어서HTML/CSS의 기본에 충실한 접근들을 했더랬다.

그 이외의 모든 고민은 백엔드에서 한다. 결과들을 tree 형태로 묶어 보여 주기로 하는 result group 이 도입되었고, 각각의 vertical 들의 사정에 맞는 정보들이 담기게 된다. 그룹들 사이에는 누가 더 나은지 비교하게 되고, vertical 간의 ranking , vertical 내에서 결과들 사이의 ranking 들이 이슈가 된다. 각 vertical 들을 별도의 resource 들을 운영하면서 진행해야 하는지 기존의 web 에 묻어 갈 것인지가 가장 큰 고민이었다. 하나의 쿼리에 뉴스와 이미지 등이 웹과 싸우게 되고, 억지로 그룹을 지으면 blog@2 과 image@1 는 제대로 비교하고 있는지..? 화면에서 group 을 굳이 매겨서 여기까지는 skip 하시오.. 라는 걸 어떻게까지 대비해야하는지..? 그룹처럼 보이려면 3개는 묶어야 할텐데.. 진짜..?

kPrism의 필요에 의해 result group에 앞서서 참가를 하였고, result group 에 대한 기여, 과제 런치와 함께 여러 좋은 일들이 생겼다. 버티컬들이 따로 옮겨다니진 않았지만, 지금까지 아주 오랫동안 result group 이 쓰이고 있었고, 이 당시부터 오른쪽 영역은 광고보다 다른 데 쓰자 했었더랬다. 이후 지금의 answer block, knowledge panel 의 토대가 되었으며, 클릭 가능한 건 뭐든지 result click 으로 간주되었고, 분석하는 pipeline 에서는 click credit 을 분배해 나갔더랬다. 자연스럽게 이 모든 것들은 web 의 index 로 통일되어 관리되었다.

블로그를 위한 노력들

한국에서는 당시 네이버 안에 자료들이 가두어져 있어 이걸 풀려는 노력들을 많이 했었고, 그 일환으로 일정 요건을 갖춘 페이지들을 블로그라 부르며 별도의 섹션으로 놓아 특별한 대우들을 하려 했었다. 지금에야 한풀 꺾였다지만, 당시 블로그라는 게 대세 중 하나이기도 했었고, 한국의 웹이 구글 크롤러들에게 잘 보여지는가 체크하는 것부터, 뉴스를 copy 한 것들을 어디까지 인정해 주어야 하는가 등의 authority 관련 이슈들, 당시에도 만연하던 기계가 만들어 내는 자료들을 어찌할 것인가에 대한 이슈들까지..

당연하게 어디까지가 블로그냐에 대해 '한국에서만' 의 가치를 두다 보니 잘 안 되었더랬다. 웹의 일부로 치면서 site level cluster를 운영할 건지, 별도의 crawl / index 를 꾸릴 것인지를 고민했었다. 구글 검색 결과에서는 별도의 blog 블럭이 있으면 웹이랑 다르게 불러야 하나 말아야 하나 등의 고민들이 있었더랬다. blogger, textcube 등을 사서 어떻게 할 건지 등도 같이 고민했었고, 그 마무리 지점 즈음에는 구글판 지식인을 꿈꾸었던 놀(KNOL, https://en.wikipedia.org/wiki/Knol)이 있다. 하지만, 네이버가 지식인과 블로그를 중심으로 꿋꿋하게 잘 버텼기에 구글 시각에서는 잘 안 되었고, 이후 모바일 세상과 유튜브 세상이 올 때까지 패배를 인정할 수밖에 없었다. 적군이었지만 박수를 보내는 한편, 요즘 소버린 시국을 맞이해서 조금 더 역할을 맡아 주면 하는 개인적인 바램도 있다.

KNOL

App 에서의 노력

이후 모바일 세상이 왔고, 모바일 세상에서 저 결과들이 섞여서 보여지려 한다면 등에 대해 비슷한 노력들이 필요했다. 새로운 vertical 이 만들어지고 사라지고 하는 게 그 자체가 지니는 난이도가 있고, 야기하는 사용자의 편의성과 임팩트 등이 고민이 많게 된다. 여기서 양대 산맥으로 나누어 졌던 모바일 세상에 여지가 생겼다. 안드로이드와 아이폰에서 ‘게임’을 찾는다면 ? 스타크래프트는 아니잖아 ? 안드로이드 폰에서 ‘네이버’를 검색하면 네이버 앱이 다운로드 될 수 있게 해야 하지 않을까 ?

별도의 vertical 이 필요할까? 라는 질문에는 의외로 쉽게 접근을 했다. 안드로이드에서는 플레이스토어, 아이폰에서는 앱스토어. 초기에 제3의 마켓들이 있었다지만, 법적 검토로는 무시해도 될만한 수준이었더랬다. 모바일에서는 상대 스토어들을 안 보이게 하는 것만으로 꽤 좋은 결과가 나왔었다. 전통적인 검색과 모바일 시장의 자연스런 결합이었고, 특정 사이트를 + 해 주는 거면 불편한데, 어차피 도움 되지 않는 사이트를 빼 주는 형태로 자연스레 구현이 되었더랬다. 의외로 이걸 '앱' or '어플' , or 'App' or 'Application' 이름 정하는 데 꽤 고민을 했더랬다. 당시에는 은근히 Chrome extension 도 Chrome app 이라 부르고 있던 시절이었고, app/application 이라는 말을 생각보다 광범위하게 쓰인다.

Ranking 은 언제나 물음표였다. 예를 들면 '게임'이라는 쿼리에 구글의 결과와 플레이스토어 결과가 같아야 하느냐 ? 라는 질문은 언제나 단골 질문이었고, 이후에도 많은 질문들이 생겨났으며, 이를 풀기 위해서는 모바일 친화적인 여러 과제들이 아래의 질문들을 이어 받아 진행하게 된다. 유니버설 검색은 여기까지...

- 공식 사이트를 구하는 만큼 공식 앱을 구하는 노력은 어떻게 되어야 할까 ?

- 앱을 다운로드한 사용자한테는 다르게 보여 주어야 하지 않을까?

- 사용자가 앱을 지우면 구글 검색은 어떻게 알지 ?

- 구글 로그인 안 한 사용자들한테는 어떻게 ?

- 기계가 두 개면 ? 한 기계에 여러 사용자가 들어오는 거면 ?