[서평] 마이크로소프트웨어 388호, SEARCH 검색

[ 읽게 된 동기 ]


개발자의 자기계발. 평소 접하지 못하는 새로운 기술을 만나기 위함.

 

[ 한줄평 ]


검색 기술을 사용하는 다양한 산업군. 산업군 속의 시행착오 그리고 열정 넘치는 도전.

 

[ 서평 ]


 

아침에 눈을 뜨지마자 알람을 끄고, 그동안의 푸시 알림을 확인한다. 페이스북, 카카오톡, 이메일 등등.

샤워 후 오늘의 날씨를 확인하고, 외투를 고른다. 혹, 손흥민이 골을 넣었는지 체크를 하고 시간에 맞춰 출근한다. 집을 나와 버스와 지하철 위치를 확인하고, 조용히 외친다. “아! 오늘도 지각! 쉣!”

 

이 흔하디 흔한 루틴 속에서 우리는 굉장히 많은 “검색” 을 하고 있다. 유저가 “검색” 을 하기 까지, 그리고 “검색”을 하고 나서 이뤄지는 Back-end 의 기술적 행위는 이시대 최첨단 컴퓨터 과학의 집약체다.

날씨를 확인하는 행위, 손흥민의 골 장면을 찾는 행위만이 “검색” 이라 하기엔 그 범위가 너무 좁다. 단순히 페이스북 앱을 열어 피드를 확인할 때도 페이스북의 Back-end Service 는 ‘검색 버튼’ 을 누르는 것과 유사한 동작들을 수행하고 있다.

 

마이크로소프트웨어 388호, SEARCH 검색 편.

이번 호에서는 이러한 ‘검색’ 이 어디서 부터 시작되었는지, 어떤 기술들을 사용하는지, 어떻게 기업에 적용되는지. 그리고 그 기술들이 우리에게 어떻게 보여지는지를 다룬다.

 

 

검색이 뭐 그리 대단해? 

 

개발자로써 내년부터 시행되는 코딩의 공교육에 대해 동료들과 이야기를 주고 받곤 한다. 과연 한국형 코딩 교육은 어떻게 될까? 많은 학생들이 코딩을 배워서 10년 뒤, 20년 뒤에는 우리나라가 미국 실리콘밸리를 앞서게 될까?

아쉽게도 현업의 개발자들은 한국형 코딩 교육에 많은 우려를 표하고 있다. 이유는 ‘한국형’ 이 될 것이 뻔하기 때문이다.

 

나는 7년차 개발자로써, 코딩 교육은 이러한 사례 위주로 접근해야 한다고 생각한다.

코딩 교육의 필요성으로 많은 사람들은 “프로그래밍적 사고” 를 기르기 위함이라고 말한다. 하지만, 도대체 그게 뭐길래 그리 강조하고 정책으로 정하고 입시를 뒤 흔드는 지는 말하지 않는다. 나는 그 이유가 우리나라 정치인들이 “프로그래밍적 사고” 가 없어서 이기 때문이라 생각한다.

사내에서 신입 개발자를 교육시켜보기도 했고, 비전공자 대상 코딩 교육도 경험해본 입장에서 무작정 “코딩 해!” 라는 접근은 올바르지 않다고 생각한다. 코딩을 위해 배우는 여러 기초 개념들이 어떤 식으로 우리네 삶에 적용되고 있는지를 보여주는게 우선이다. 그런 점에서 누구나 사용하는 “포털 사이트 검색” 이야말로 그 사례로 적합하다.

 

<네이버 ‘파리’ 검색시 파워 링크 | 2017.12.16 현재>

 

과연 컴퓨터는 어떤 식으로 데이터를 처리할까? 우리가 네이버에 ‘파리’ 를 검색하면 파리에 가는 항공사 중 어떤 항공사가 가장 먼저 나올까? 이런 식의 질문에서 부터 학생들의 관심을 유발하는 것이다.

현재 네이버에서 ‘파리’ 를 검색하면 가장 최상단에는 “세스코” 가 나온다. 세스코. 해충박멸 1위 기업이 네이버에 가장 돈을 많이 냈나보다.

 

그리고 학생들에게 묻고 싶다.

과연 ‘파리’ 라는 단어는 ‘프랑스 파리’ 를 의미할까? 아니면 ‘곤충 파리’ 를 의미할까? 이를 알기 위해서는 어떤 정보들이 더 필요할까? 그 정보들은 어떻게 얻을 수 있을까?

 

다양한 자연어 처리 기술을 API로 제공하는 봇 프레임워크들을 살펴보면 각기 용어는 다르지만 공통적으로 제공하는 요소가 있다. 바로 Intent(의도), Entity(개체), Context(맥락)이다. 최소한 이 3가지는 이해해야만 대화라는 것이 가능하다.

 

프로그래밍적 사고는 이런 식의 질문에 대답하면서 형성되는 것이지, 단순히 API 를 외우는 코딩 교육에서 형성되는 것이 아니다. 도대체 왜 원천 데이터가 중요한지, 영어 말뭉치를 왜 한국어 번역에 사용할 수 없는지. 효율적이고 빠른 검색을 위한 기술이 어디까지 발전 했는지. 이 기술은 어떻게 적용되어 있는지.

이러한 기술적 측면에서의 이야기를 마이크로소프트웨어 388호, SEARCH 검색 편에서 풀어나간다.

 

 

검색기술. 컴퓨터 과학의 집약체.

 

지난 마이크로소프트웨어 387호 AI 인공지능 편에 이어 두 번째 마이크로소프트웨어 매거진을 읽었다. 나는 안드로이드 앱개발을 7년째 하는 개발자로써, 검색 기술과 관련된 내용에 그저 막연한 개념만을 추측했다. 협업 필터며, 자연어 처리 등의 몇몇 키워드만 들어봤을 뿐이다.

지난해 큐레이션 서비스를 기획하며, 뉴스 추천 엔진을 기획하려 했지만 너무도 거대한 기술임을 확인하며 좌절감을 맛보기도 했다. 지금 생각해보면 도대체 무슨 생각으로 큐레이션 자동화 엔진을 틈틈히 만들 수 있을거라 생각했는지 모르겠다.

 

검색 기술에는 가능한 대부분의 기술력이 투입된다. 간단히 index 를 찾는 기술부터 자연어처리를 지나, 인공지능까지. 그야말로 현 컴퓨터 과학의 집약체라 할 수 있다. 하지만, 개개인의 엔지니어들이 이러한 기술력을 모두 익힐 수는 없을 터, 게다가 급변하는 시장 위의 스타트업 만큼 구글 등의 연구자들은 매일같이 논문을 발표한다.

이러한 상황 속에서 비즈니스 그룹은 ‘최적’ 의 선택을 해야만 하고, 그 과정에서 그들의 노하우가 쌓이고 있다.

 

쇼트해드(Short Head) 영역에 포함되는 상위 1만위의 검색어는 전체 검색횟수의 66.38%를 차지하고 있다. 상위 1만위의 검색어에서 상당수의 트래픽이 발생하며, 많은 고객이 동일한 검색어를 검색하고 있다.

 

티몬의 아티클에서 위와 같은 문장을 발견했다. 이는 직접 검색 서비스를 운영하지 않으면 얻을 수 없는 귀한 데이터다. 일반적으로 우리는 남들과 비슷한 단어를 검색한다. 아마 대부분의 사람들이 네이버 실시간 검색어에 오르는 ‘단어’ 들을 검색 할 것이다. 본문에서는 이러한 내용들을 다루고 있다.

 

 

‘in’은 ‘startup’, ‘Korea’와 비교하면 매우 일반적으로 사용하는 용어다. 이 예시가 아니더라도 대부분의 문서에서 한번 이상씩 나타날 가능성이 높다고 쉽게 예상할 수 있다. 즉, ‘in’의 경우 DF가 매우 높은 용어이기 때문에 결과 연관성에 미치는 영향력이 매우 적다고 할 수 있다.

 

자연어 처리를 하면서 얻은 노하우들을 공유하기도 한다. 최근 앱개발 등의 프론트엔드 기술보다, 이러한 백엔드 기술에 관심을 보이고 있는 중인데, 각 단어별로 가중치를 주며 이를 수치화 한 뒤 계산하는 방식 등. 어떻게 해서든 계산 가능한 데이터로 치환하는 과정에서 엔지니어로써 참 묘한 감정을 느낀다.

도대체 어떻게 인류는 세상의 모든 것들을 ‘수치화’ 할 수 있는걸까? 나 또한 한 명의 개발자로써 일하고 있지만, 아마 대부분의 개발자들이 그런 생각을 할 것이다. ‘참 신기하다고’

 

따라서 문장을 번역할 때 입력 단어에 따라 다른 가중치를 부여하면 보다 정확한 결과를 얻을 수 있을 것이라고 추측할 수 있다. 실제로 이 모델은 이미지 캡셔닝(Image Captioning), 자동 번역 등에서 기존 seq2seq 모델을 뛰어넘는 성능을 보이는 것으로 알려져 있다.

 

한편으론 아쉽기도 하다. 안드로이드 개발자로 일하며, 이러한 데이터를 다룰 기회가 거의 없었다. 최근에는 자금관리 서비스를 만들며 금액 및 금융기관 분류 데이터를 다뤘는데, 이러한 데이터를 다루는 것은 처음이라 굉장히 애를 먹었다. 많은 개발자들이 그렇듯, ‘아… 나는 정말 아무것도 모르구나…’ 하는 좌절감도 맛봤다.

 

규칙 기반 대화 시스템은 미리 정해진 규칙에서 조금만 달라져도 시스템이 내용을 인식하지 못하는 문제가 있다. 사용자가 유의어로 대체해서 요청하거나(틀어줘 -> 들려줘), 비슷한 내용의 요청을 의역(Paraphrase) 하거나(최신 인기 가요 틀어줘 -> 요즘 인기있는 노래 뭐 있어), 오타 (툴어조 -> 틀어줘 등) 같은 경우 해당규칙을 일일히 정의해야 정상적으로 처리할 수 있다.

 

또한 ‘챗봇’ 등이 뜨면서 고객과의 접점이 점차 늘어났기에 데이터 또한 기하급수적으로 늘어나는 중이다. 하지만, 이 분야들이 빠르게 발전하는 만큼 그동안의 축적된 경험 등이 전무하기에 ‘도메인 지식’ 이 충분한 엔지니어들이 많지 않다.

다소 머리 아프긴 하지만, 이러한 개념들에 흥미가 생기는 스스로를 보며 사회 첫 발을 ‘개발자’ 로 시작한 것에 나름의 자부심이 생기기도 했다.

 

 

그리고 비즈니스.

 

마이크로소프트웨어가 재밌는 이유는 단순 기술문서의 모음집이 아니라, 비즈니스 영역의 글도 함께 녹아있기 때문이다.

 

부끄럽게도 자마린이 뭔지도 잘 모르던 상황에서 지푸라기를 잡는 심정으로 ‘Hello World’ 를 찍고 몇 번의 테스트 후에 급하게 도입을 결정했다.

 

기술적 욕심만을 부리는 개발자는 필드에서 인정받기 힘들다. 필드에서는 언제나 레거시 코드가 있고, 출시 일이 있다. 그야말로 정해진 기간에 달리는 자동차의 바퀴를 갈아 끼워야 하는데, 그 과정에서 늘 더 나은 방향만을 추구하다 보면 달리는 자동차의 바퀴가 결국 터져버리는 것이다.

영아용 헬스케어 스타트업 ‘올비’ 는 빠듯한 출시 일정 속에서 안드로이드와 아이폰 두 개의 클라이언트를 모두 제작해야 하는 상황이었다. 이에 올비 CTO 는 크로스 플랫폼 ‘자마린 Xamarin’ 을 선택했고, 이 과정 속에서의 시행착오와 고민 그리고 기술적 이야기를 풀었다.

나 또한 작년 큐레이션 서비스 도밍고뉴스를 만들며, 빠르게 파이썬을 배워 백엔드를 구축하고, Node.js 로 푸시를 발송하는 등의 경험을 했다. 스타트업은 정말이지 학습 시간을 무시하며 빠르게 달릴 수 밖에 없는 상황임에 동의한다.

 

<헤헿. 아메리카노와 생 초콜릿을 씹으며. With 마소.>

 

이러한 개발자들의 비즈니스 이야기가 마이크로소프트웨어가 갖는 재미이지 싶다.

다소 아쉬운 점은 ‘검색’ 을 논하면서 ‘네이버’ 와 ‘구글’ 의 엔지니어 글이 없었다는 점이다. 마지막 파트에 네이버 검색엔진 리더의 글이 실리긴 했지만, 이는 인터뷰였다. 네이버나 카카오 검색파트 엔지니어 글이 실렸더라면 보다 흥미있는 편이 되지 않았을까 싶다.

 

한 달 만에 갖는 여유로운 주말.

아메리카노와 생 초콜릿. 그리고 엔지니어들의 이야기가 담긴 마이크로소프트웨어와 함께 했다.

 

 

[ 인상 깊은 문구 ]


 

  • ‘협업(Collaboration) 기능’을 갖는 에이전트로 구성된다면, 하나의 에이전트에서 장애가 발생했을 때 서비스의 중단이나 이상 결과를 전달할 수 있다. 그렇기 때문에 집단지성이나 학습을 위한 데이터 전처리는 ‘협업 기능’보다는 ‘협력 기능’이 강조된 에이전트로 구성해 올바른 지식이 만들어내는  것이 좋다.
  • 그래서 이런 문서는 기계학습의 학습율을 높이고, 지식의 완성도를 검증하는 전문가의 큐레이션 과정을 거쳐 값을 보정한다.
  • 이렇듯 인공지능 지식 검색 서비스는 사람의 일자리를 뺏는 것이 아닌 보조적인 역할을 수행하는 방향으로 가다듬어야 한다.
  • 상당히 고민스럽게도 재현율과 정확도는 상충 관계이기 때문에, 둘 사이의 적절한 균형점을 잡는 것이 검색 결과 품질의 기본이고, 검색 기획자의 고민거리다.
  • 쇼트해드(Short Head) 영역에 포함되는 상위 1만위의 검색어는 전체 검색횟수의 66.38%를 차지하고 있다. 상위 1만위의 검색어에서 상당수의 트래픽이 발생하며, 많은 고객이 동일한 검색어를 검색하고 있다.
  • 검색은 단순 검색 결과의 목록이 아닌 정보로서의 역할까지도 한다.
  • 나는 주어진 일에 맞춰 시간과 공간을 조정하던 방식에서, 하고 싶은 일을 선택하고 일하는 시간과 공간을 나의 욕구에 맞춰 조정하기를 원했다.
  • 포트폴리오 생활자가 된다는 것은 필수적인 것을 해결할 충분한 수입의 정도를 규정하고 여분을 더 벌려고 삶을 희생하지 않는다는 뜻이다.
  • 안전하게 보호 받던 감옥에서 열린 세상으로 나가는 일을 과소평가하지 않기로 했다. 이는 생각 보다 훨씬 어려운 일이었다. 그곳은 불편하고 답답했지만 안전이 보장되었던 비좁은 동굴이었다. 거기서 나오니 깊이가 얼마나 되는지, 밑바닥이 어떻게 생겼는지도 알 수 없는 허공에 발을 디딘 기분이었다.
  • 그러다 그는 매일 6시 시작된 암호문에 날씨라는 낱말이 들어갈 거라는 사실을 깨닫고, 암호문을 독일어 ‘wetter(날씨)’란 단어와 매칭하는 작업을 했다.
  • 위시켓에서 활동하는 프리랜서들은 종종 클라이언트가 작업자를 선정할 때 어떤 요소를 중점적으로 보는지 물어볼 때가 있다. 그동안 수많은 클라이언트에게 피드백을 받은 결과, ‘커뮤니케이션 능력’이라고 답하는 클라이언트가 압도적으로 많다.
  • 열혈 포켓몬고 이용자들은 OSM을 수정하거나 그곳에 뭔가를 추가하면 해당 지도가 곧 게임에 반영된다는 사실을 알아챘다. 그 후 더욱 열정적으로 OSM 편집에 참가했다. 이런 한국 포켓몬고 이용자들의 활발한 OSM 활동에 힘입어 2017년 1월 26일 OSM 편집자 순위에서 한국은 미국을 누르고 세계 1위를 차지하는 놀라운 성과를 일궈냈다. 포켓몬고가 한국에 정식 출시된지 불과 3일만의 일이다.
  • 위키백과처럼 OSM 사용자들도 지도 위에 지형지물을 자유롭게 추가, 수정, 삭제할 수 있다. 편집 이력 정보도 저장된다.
  • 일본 도요타 자동차는 2015년 8월 OSM을 근간 지도로 사용하는 텔레나브(Telenav)의 내비게이션을 자사 차량용 내비게이션으로 선정하기도 했다. 자동차 회사에서 OSM을 활용한 최초의 사례다.
  • HOT는 전 세계 자원봉사자들과 함께 이 지역 지도제작에 바로 착수했으며 단 2주만에 태풍의 피해를 입은 모든 지역의 지도제작을 마쳤다. 미국 적십자를 포함한 구호단체들이 현장의 정확한 상황이 표시된 이 지도를 이용해 태풍 피해자들에게 적절한 구호활동을 펼칠 수 있었다. 지도가 생명을 구한 것이다.
  • 2012년 애플(Apple)이 구글 맵과 결별하고 1년만에 애플 맵을 발표할 수 있었던 까닭도 과감히 OSM을 차용했기 때문이었다.
  • ‘빠르고’, ‘정확하게’라는 표현에서 알 수 있듯이, 검색을 실제로 구현할 때에 반드시 만족해야 하는 두 가지 요소가 있다. 바로 성능과 결과의 연관성이다.
  • ‘in’은 ‘startup’, ‘Korea’와 비교하면 매우 일반적으로 사용하는 용어다. 이 예시가 아니더라도 대부분의 문서에서 한번 이상씩 나타날 가능성이 높다고 쉽게 예상할 수 있다. 즉, ‘in’의 경우 DF가 매우 높은 용어이기 때문에 결과 연관성에 미치는 영향력이 매우 적다고 할 수 있다.
  • 검색에서 핵심이 되는 또 하나의 개념은 텍스트 분석이다. 대표적인 분석 방법으로 토큰화, 필터링, 어근 분리 등이 있다.
  • 이러한 질문에 대한 답을 찾기 위해 채용 공고의 “마감일”과 “상시채용 여부”의 필드에 감쇄함수를 다양하게 적용해 A|B 테스트로 감쇄함수의 최적화를 시도했다. 그 결과 일반 사용자들은 “상시채용” 보다는 “마감일”이 정해진 채용 공고, “마감일”이 한참 남은 채용 공고 보다는 “마감일”에 임박한 채용 공고를 더욱 중요하게 생각한다는 사실을 찾았다.
  • 협업 필터링(Collaborative Filtering)은 추천 시스템을 설계할 때 가장 많이 사용하는 방식 중 하나다. 방대한 양의 사용자 방문 로그(행동 데이터)를 수집하고 분석해 유사한 행동 패턴을 갖는 다른 사용자들의 데이터를 기반으로 정보를 추천하는 방식이다.
  • 일반적으로 ‘검색’은 대량의 문서 집합에 검색 질의를 수행한다. 반변 퍼컬레이터는 검색 질의를 저장해두고, 특정문서를 검색하는 질의를 찾아내는 방식을 의미한다. 이 때문에 ‘역질의’라고 부른다.
  • 사내 인프라에 설치된 모니터링 시스템으로는 아무런 단서도 얻지 못했다. 이때, Voyager는 특정 회선 사업자명이 나타나는 빈도가 올라가는 것을 보여줬다. 게임 서버가 아니라 인터넷 회선 문제를 밝힌 덕분에 기술팀이 내부 원인을 찾기 위해 더 많은 시간을 소모하지 않고 적절하게 공지할 수 있었다.
  • 한국어는 문장에서 문법 요소를 잘 분리하는 간단한 알고리즘이 존재하지 않는다. 특정한 글자가 문법 요소인지 어간의 일부인지 모호한 경우가 많다. 사전에 없는 말을 파싱한다면 더욱 어렵다. 인터넷이나 게임 커뮤니티에서 사용하는 단어 중 아직 사전에 없는 경우가 많다.
  • 내용이 디지털로 저장되어 있고 누구나 특별한 제한 없이 사용할 수 있는 백과사전은 위키피디아가 유일하며 그런 의미에서 위키피디아의 중요성은 날로 커지고 있다.
  • 그만큼 챗봇은 생각보다 거창하지 않은 것임을 강조하고 싶다.
  • 다양한 자연어 처리 기술을 API로 제공하는 봇 프레임워크들을 살펴보면 각기 용어는 다르지만 공통적으로 제공하는 요소가 있다. 바로 Intent(의도), Entity(개체), Context(맥락)이다. 최소한 이 3가지는 이해해야만 대화라는 것이 가능하다.
  • 예상되는 대화를 기준으로 디자인을 수행해야 하기 때문에 도메인(특정주제) 전문가가 필요하다.
  • 맥락을 파악하지 못한 봇은 명시적으로 ‘Intent’와 ‘Entity’를 알려주지 않으면 ‘Context’를 파악하지 못한다.
  • 딥러닝 모델에서 가장 부족한 능력은 바로 ‘Memorization’이다. ‘Memorization’이란 과거의 기억을 ‘정확히’ 기억하고 있는 것이다.
  • 규칙 기반 대화 시스템은 미리 정해진 규칙에서 조금만 달라져도 시스템이 내용을 인식하지 못하는 문제가 있다. 사용자가 유의어로 대체해서 요청하거나(틀어줘 -> 들려줘), 비슷한 내용의 요청을 의역(Paraphrase) 하거나(최신 인기 가요 틀어줘 -> 요즘 인기있는 노래 뭐 있어), 오타 (툴어조 -> 틀어줘 등) 같은 경우 해당규칙을 일일히 정의해야 정상적으로 처리할 수 있다.
  • 따라서 문장을 번역할 때 입력 단어에 따라 다른 가중치를 부여하면 보다 정확한 결과를 얻을 수 있을 것이라고 추측할 수 있다. 실제로 이 모델은 이미지 캡셔닝(Image Captioning), 자동 번역 등에서 기존 seq2seq 모델을 뛰어넘는 성능을 보이는 것으로 알려져 있다.
  • 현재의 방식은 아무래도 개발팀을 효율적으로 운용하기 위해서 연구개발팀과 포팅(한 플랫폼 혹은 OS용으로 완성된 프로그램을 다른 플랫폼 용으로 다시 제작하는 것)팀 으로 나누게 되는데 포팅을 담당하는 인력은 아무래도 제품의 기획과정까지 참여할 여유는 없어 포팅을 위한 코딩을 하게 된다.
  • 부끄럽게도 자마린이 뭔지도 잘 모르던 상황에서 지푸라기를 잡는 심정으로 ‘Hello World’ 를 찍고 몇 번의 테스트 후에 급하게 도입을 결정했다.
  • 결론은 기존의 앱개발을 잘 알지 못하면 자마린만으론 제대로된 앱을 만들 수 없었다.
  • 여러차례 말했듯 크로스 플랫폼은 수많은 개발자들이 바랬던 것이다. 그러나 희망에 비해 현실은 냉혹했다.
  • 안타깝게도 한국의 앱 개발사들은 이와 같은 표준이나 디자인 가이드 라인에 대하여 무지하거나 무시하는 경향이 있다.
  • 지금은 Swift가 새로 출시돼 매우 우수한 언어로 인정받고 있지만 나온지 한참 됐던 C# 이 이정도로 진화된 모습이었던 것을 몰랐던 것에 대한 아쉬움에 개발자로서 많은 반성을 하게 됐다.
  • 한국에서는 IT산업이 지속 성장할 수 있게 해주는 두개의 탑(산업)이 있는데, 하나는 공공산업이고 나머지 하나가 바로 금융산업이기 때문이다.
  • 마리아DB(MariaDB) 는 MySQL 커뮤니티 버전을 기반으로 만든 MySQL 호환 데이터베이스다.
  • 한편, 중국의 Ehang은 그동안 군집 비행에 대해서 잘 알려지지 않았지만, 최근 미국이 기록하고 있던 기네스북 기록인 500대를 깨고, 1000대 군집 비행에 성공했다.
  • 실제 비행 실험을 하는 경우, 간헐적 통신 두절 현상으로 위치를 측정 못해 제어가 어려워지는 경우가 많이 발생한다.
  • 다양한 알고리즘을 포함한 비행 제어 시스템들이 최근에는 오픈소스로 공유되고 있다
  • Sk텔레콤은 이동통신 가입자 구성을 보면, 20대 청년계층 가입자는 전체 가입자 비중에서 약 16%에 달한다. 이들은 높은 통신비용을 꼬박꼬박 연체 없이 지불하는 소비패턴을 가지고 있다. 조금 다른 신용등급 평가기준을 적용할 수 있지 않을까?
  • 모든 것이 연결된 사회에서 데이터가 생성되면 축적된 데이터는 공유된 자산이자 사회기술적 발전의 연료로 사용돼야 할 것이다. 그러므로 데이터 기반 진화의 출발점은 데이터 생태계의 구축이다.
  • 시장 조사 따위를 우습게 알던 스티브 잡스의 태도는 일반적인 미국 사업가보다는 인도 철학가에 가깝기 때문이다.
  • 특히 애플의 마케팅 철학은 잡스가 평생 간직하며 살아간다. 고객과의 공감이 중요하고 중요한 것에만 집중해야 하며, 최상의 품질을 지니고 있다는 인상을 심어주어야 한다는 세 가지 철학이었다.
  • 구글 데이터 센터에서는 이 쿼리 하나에 8600개의 CPU, 3600개의 디스크가 사용됐는데, 실제 실행 비용은 20$ 밖에 소요되지 않았다.
  • 검색 엔진에 관심있는 개발자 중에서 시스템 프로그래밍을 하고 싶으신 분들은 C에 능숙해야 하고, 서비스 개발에 관심 있으면 자바, 파이썬을 알아두면 좋다. 그래도 이론적으로 깊이 있는 연구를 하려면 C를 잘 알아야 한다.
  • 모바일 시대에는 사용자들의 상황과 맥락에 맞는 검색 결과를 보여주는 게 더욱 중요해졌다. 핵심은 ‘사용자의 의도를 파악하는 것’ 이다.
  • 모바일 검색 시대에는 추천 서비스가 결국 개인화 서비스다. 진짜 사용자 개인이 좋아하는걸 추천해줘야 한다. 다른 사람들에게 인기있는 것을 추천해주는 것은 의미 없다.

 

Share:
오세용 Domingo

오세용 Domingo

글쓰는 감성개발자 오세용입니다. IT, 책, 축구, 커뮤니티 등에 관심이 많습니다.