'2018/03/13'에 해당되는 글 2건

내 블로그에도 구글 애드센스(AdSense)를 달아 놓았고, 인터넷을 다니면서 구글 광고는 흔하게 많이 접한다. 몇 년 전부터 지금까지 구글 광고를 보면서 느끼는 명백한 한계점이 하나 있는데, 바로 "내가 이미 구입을 완료한 제품에 대한 광고를 지속적으로 나에게 노출시키는 것"이다.

직접 확인한 두 가지 사례가 있다.

첫 번째로, 해외에 잠시 다녀오기 위해서 호텔 검색 사이트(호X스닷컴)에서 특정 지역의 호텔들을 검색해서 몇 개를 살펴보았고, 그렇게 며칠 동안 검색한 뒤에 하나를 정해서 예약과 결제를 모두 완료했다. 그런데 그 뒤로 일주일이 지나도록 내가 인터넷을 돌아다닐 때마다 거의 대부분의 구글 광고에서, 내가 이미 예약한 바로 그 호텔에 대한 광고를 보여주는 것이었다. 우스운 것은, 내가 며칠 전에 결제했을 때의 가격보다도 더 비싼 가격을 "특가"라고 광고하는 것이었다. ㅎㅎ

두 번째는, 얼마 전에 스마트폰 케이스를 사기 위해서 또 구글 검색을 여러 번 했고, 그 중에 매우 얇은 케이스 하나를 잘 구입했는데, 구입한 지 벌써 몇 주가 지났는데 오늘 갑자기 구글 광고에서 내가 구입한 것과 정확히 똑같은 제품을 광고의 한 가운데에 배치해서 보여주었다. 내가 그 케이스를 구입한 쇼핑몰에서 내보낸 광고였는데, 다른 모양의 케이스들이나 강화유리를 보여줬을 만도 한데 정확히 내가 구입한 그 물건만 일부러 강조해서 광고에서 표시되고 있었다.

결국 구글은 내가 검색하고 가장 많이 쳐다보고 있었던 페이지가 무엇인지는 알고 있지만, (쇼핑몰 사이트에 내장된 구글 애널리틱스와 내 구글 계정의 검색 기록을 종합하면 아마 쉽게 알 수 있을 것이다) 내가 이미 구입해서 더 이상 흥미가 없는 제품이라는 판단은 아직 못 하는 듯 하다.

솔직히 구매 내역도 내 계정의 지메일을 조사하면 알 수 있을 텐데, 내 지메일도 속속들이 다 들여다 보고 있으면서 (호텔이나 항공권을 결제하면 내가 시키지도 않았는데 자동으로 구글 캘린더에 모두 등록되는 것만 봐도 알 수 있다), 구글 광고에 보여 줄 제품을 표시할 때에 지메일을 적극적으로 확인하지 않는 것은 좀 의외다.

아직 특정 쇼핑몰에서 보내 주는 주문/구매 내역에 대한 이메일 내용을 "자신 있게(충분한 confidence level을 유지한 채)" 분석해 내지는 못하는 것인가 하는 생각이 든다. 쇼핑몰이나 각종 결제 사이트마다 워낙 레이아웃과 텍스트 내용이 제각각이라서 아마 정확도를 높이기가 아직은 쉽지는 않을 지도 모르겠다.

하지만 사실 구글 어시스턴트와 같이 음성인식 비서가 발전하는 속도로 봤을 때, 이메일에 적혀 있는 자연어와 표 형식으로 잘 구분된 데이터 (대부분의 주문 내역은 표를 이용해서 제품 이름과 구매수량, 단가, 결제금액, 시간 등을 정렬해서 보여주고 있으니까)를 머신러닝을 써서 분석해 내는 것은 마음만 먹으면 금새 해낼 수 있을 것 같다.

결국 구글이 애드센스의 광고 추천 정확도를 지금보다 조금 더 개선시키기 위해서 사용자의 지메일 상의 각종 구매 내역과 전세계 쇼핑몰 사이트에서의 구글 애널리틱스에 기록된 방문 기록을 종합해서 빅데이터 분석을 수행할 의지가 있느냐 없느냐의 문제로 귀결된다.

...물론 이렇게 소소하게 구글이 인터넷에서 나에게 추천하는 모든 것에 대한 정확도를 높여 갈 수록 사람들은 오히려 구글을 더 무서워하게 될 지도 모른다. (이미 돌이킬 수 없게 무서운 존재인 것은 사실이지만...) 구글은 너무 무서워지지 않기 위해서 일부러 안하고 있는 것일까?

연구에 대한 실험 코드를 고쳐 가며 새로 데이터를 뽑고, 또 문제가 있거나 개선할 부분이 보이면 다시 고치기를 반복하고 있다. 이 과정에서 내가 개인적으로 유난히 시간을 많이 소비하는 단계가 있음을 알게 되었는데, 바로 어떤 설계(design)으로 개선해서 목적을 달성할 것인지 결정하는 단계이다.

예를 들어, 라우팅 프로토콜을 고치는 과정에서, source node가 자신이 트래픽을 보내기 위해서 먼저 경로를 탐색(route discovery)하고 선택해야 하는데, 이러한 과정을 자주 하게 되면 그만큼 네트워크 전체에 부정적인 영향을 끼치게 된다. 이러한 route discovery 자체를 줄이기 위해서 먼저 실제로 route discovery를 몇 번씩 했는지 파악을 할 필요가 생겼다. 이것을 어떻게 기록할 것인지 생각을 해 보았는데,

1. 그냥 각 source node의 ID로 된 텍스트 파일을 만들고, 매 초마다 route discovery를 몇 번 했는지 숫자를 텍스트 파일에 시간 순서대로 한 줄씩 기록하는 방법
2. Route discovery 전체를 기록하는 텍스트 파일 한 개를 만들고, 모든 source node가 같은 파일 포인터에 접근해서 시간, 노드ID, route discovery를 수행했다는 flag를 한 줄로 기록하는 방법

위의 두 가지 외에도 다양한 방법들로 기록할 수 있어 보였다.

그런데 나중에 통계를 내고 엑셀 파일 같은 곳에 가져다 쓸 것까지 생각을 해 봤을 때 어느 방법이 가장 좋은지 쉽게 판단이 잘 안 되는 것이었다. 이게 깔끔하게 마음 편한 방법으로 잘 정리가 되지 않자, 이것 때문에 하루 종일 다른 작업을 못하고 그냥 고민만 하고 딴짓만 하다가 시간을 보내고 말았다.

사실은 내가 연구 측면에서 정의한 문제를 해결하는 방법이 아니고, 라우팅프로토콜의 성능을 측정하는 데 필요한 작은 통계 생성 방법일 뿐이고 어떤 설계를 따르던지 어차피 시뮬레이션 성능에 큰 영향을 주지는 않기 때문에 무시하고 한 가지를 얼른 정해서 진행을 해도 되는 것이었는데, 어느 한 가지를 고르는 것이 속 시원하지 못하다는 이유로 연구 전체를 진행하지 못하고 마치 트랩에 걸리듯이 꼼짝하지 못했다.

결국 지금 밤이 되어서 그냥 첫 번째 방법으로 진행해서 얼른 경로 탐색에 대한 기록부터 만들어내고, 그렇게 각 source node별로 만들어진 기록을 합산하는 스크립트를 파이썬으로 빨리 만들어서 붙이기로 했다. 사실 이미 각 노드마다 flow 트래픽 사용량에 대한 통계를 똑같은 방식으로 만들어 내고 똑같이 파이썬 코드로 후처리(post-processing)를 하고 있었기 때문에 기존의 코드를 재활용해서 가장 적은 시간을 들여서 통계를 만들어낼 수 있는 것이기도 했다. (지저분하게 파일 개수가 많아지는 것, ns-3 코드 상에서 파일 포인터가 많아지는 것 외에는 그 어떤 문제도 없기도 하고...)

나는 지나치게 조심스러운 것이 단점이므로, 그냥 가급적이면 조금 더 빨리 결정한 다음, 뒤도 돌아보지 말고 밀어붙인 뒤에 나중에 문제가 터지면 그것을 그 시점에서 재빨리 고쳐 나가서 목적부터 달성하기 위해 노력해야겠다.

그러므로 내일 일을 걱정하지 말아라. 내일 일은 내일 걱정할 것이오. 한 날의 괴로움은 그 날의 것으로 충분하다 (마태복음 6:34)