입사를 하게 됐다. OJT 하면서 들었는데, 시리즈 C 확정이 되고 회사도 선릉으로 옮겨갈거라 한다. 너무 좋다...
인턴은 3월 2일까지지만 전환 평가가 그 전에 끝난다고 한다. 인턴 과제가 있는데, 설까지 끼여 있어서 개발기간이 2~3주 남짓이다.
일단은 인턴에 집중하는게 좋을 것 같아 다른 면접은 포기하기로 결정했다.
오늘은 맥에 적응하느라 애를 먹었는데, 설정을 할 수록 알 수 없는 변경이 된다. 애플... 과연 편해질까. 얼마전 있었던 방해금지 알람 사건이 하루종일 떠올랐다.
쉬는 동안 짬짬이 요구사항 정리를 했다. 새리와 얘기했는데, 크게 달라지는 부분은 없을 것 같다. 가장 큰 고민은 리소스 관한 것이었는데, 분리하고 문제가 생기면 합치는 방향으로 가기로 했다.
API가 너무 거대한 부분도 있지만, 자식이 얽혀있어 리소스가 명확하지 않은 느낌이기 때문이다. 요구사항만 놓고 보니 금방 할 수 있을 것 같은데, 너무 쉬워보이니 오히려 뭔가 놓치고 있을 것 같은 느낌이 든다.
새로운 사람은 받지 않기로 했다. 우리가 케어를 해주지 못할 것 같다는 것이 이유였는데, 근본적으로 생각해보면 여유가 없어서 그렇다. 각자 인턴과 수습이 끝나 안정기가 찾아오면 다시 생각해보기로 했다.
내일 코틀린 스터디 발표 차례라 문서를 정리했다. 간단하게 하고 싶었는데 중요한 부분이 너무 많아 꽤 걸렸다. 틈틈히 읽어두길 잘했다.
자바 코드로 변환시켜서 확인해보니 이해가 잘 되는 느낌이다. 쉽게 만들어둔 부분들은 모두 수신객체를 첫 번째 매개변수로 받도록 되어 있는데, 언어 설계 자체가 이렇게 되어있는 것 같다.
편한 부분이 많아 보이긴 한데, Java만 써와서 그런지 위험해 보이기도 한다. 실력에 따라 코드 퀄리티의 편차가 심하지 않을까 하는 생각이다. 그런데 잘 생각해보면 자바 자체가 객체지향적으로 코딩할 수 있느냐에 따라 천차만별의 코드가 나오기 때문에 잘 모르겠다. 혼자하는데 익숙한 사람은 파이썬 스크립트 같은 코드를 작성할 수도 있을 것 같다..
그럼에도 편의성 때문에 직관성이나 일관성은 많이 챙겨갈 수 있을 것 같은데, 이런 부분이 좋은 라이브러리 개발로 이어질 것 같다. 스니펫 생성기를 코틀린으로 만들어볼까 하는 생각이 들었는데, 자바 코드를 보니 큰 의미는 없을 것 같다. 한참 멀었지만 코프링대신 아예 프레임워크를 바꿔버리는 케이스가 조금은 이해되는 것 같다.
애드테크 대해 알아봤다. 너무 내용이 방대해서 일단 키워드 위주로 훑어 가려고 했다.
전체적인 흐름은 포털 배너만 쓰던 시절은 크게 문제가 없었지만 기존 광고가 복잡해지니 문제가 생기기 시작해서 애드 네트워크가 나왔다. 대량 판매의 문제점이 생기자 애드 익스체인지가 생겨나고 DSP SSP같은 프로그래매틱 플랫폼이 생겨났다고 한다.
현재는 개인정보 수집때문에 제 3자 쿠키가 막혀서 새로운 대안을 모색해야 하는 시점이라 한다. 하지만 퍼스트 파티 쿠키를 제공하거나 직접 사용하는 식은 애드테크가 아니라 마테크기때문에 핑거프린트 같은 방법을 이용해야 한다.
해쉬를 이용해서 유사도를 판단할 수 있다고 하는데 정확히 이해가 되지는 않았다. 좀 더 찾아봐야겠다.
스터디를 진행했다. 내가 위험해 보인다고 한 부분들은 다른 분들도 비슷하게 생각했던 것 같다. 크게 중위 함수와 중첩 메소드가 있었다. 중첩 메소드 같은 경우는 클로저를 이용할 수 있다는데 의의가 있는 것 같다는 의견이 있었다. 아무래도 함수형은 생각을 못했던 것 같다. 중위 함수 같은 경우는 dsl을 만들때 좋다고 했는데, 잘 짜여진 dsl을 보니 거의 스크립트처럼 변해있었다. 궁극적으로는 도메인 전문가가 코딩을 못 하더라도 어떤 흐름으로 로직이 이루어지는지 알 수 있도록 하는데 의의가 있을 것 같다는 것이었다.
어제에 이어서 dsp와 ssp를 이어서 살펴봤다. 살펴보기 앞서서 애드 서버에 관한 것도 찾아봤는데 애드 네트워크 이전의 흐름이 좀 더 명확하게 보인다.
이제부터 기술적인 영역인데, dsp는 광고주 입장에서 자동화를 시켜주는 플랫폼이고, ssp는 퍼블리셔 입장에서 자동화를 시켜준다. 양 쪽이 서로 거래하는데 RTB PMP PD 등의 방법을 사용한다. 일반적으로 RTB를 얘기하는 것 같긴 한데, 익스체인지에서만 거래하는 것이 아니고 익스체인지 자체도 여러 채널과 연결이 되어 있어 그런 것 같다. 그저께봤던 애드 네트워크가 사라지지 않는 이유와 조금 연결되는게 아닌가 싶다. 그럼 실제로 구현할때도 여러 거래에 대한 가능성을 염두해둬야 할 것 같다.
내일은 프로그래매틱 바잉과 DMP에 대해 조금 더 들어가보고 발표정리도 조금씩 시작해야겠다.
요구사항 정리가 어느정도 끝났다. 걱정했던 부분들은 잘 얘기가 된 것 같다. 이제 2월까지 쉰다. 그 동안 미지근하게 달린 것 같은데 사실 나도 2월쯤이면 프로젝트가 마무리 될 것으로 생각했었다. 이제야 제대로 시작 할 수 있는 환경이 만들어진게 ㅋㅋ 역시 일정은 내 마음대로 되지 않는다는 것을 다시 한 번 느낀다.
거래 방식을 중점적으로 살펴봤다.
RTB, PD, PMP라는 방식으로 거래한다.
RTB는 말 그대로 실시간 거래, PD는 직접 하되 프로그램을 이용해서 진행한다. PMP는 경매를 비공개로 진행한다.
PD는 보장 계약과 우선 거래를 포함한다. PMP도 마찬가지지만, 사람이 관여하지 않는다.
판매자 입장에서는 워터폴 방식과 헤더 비딩을 주로 사용한다.
우선 mediation 플랫폼이라는 것이 있는데, 매체가 애드 네트워크와 연동하는 규칙을 관리해준다.
워터폴 방식은 여기서 가장 괜찮아 보이는 것을 먼저 선택하고 응답이 없으면 차순위로 요청을 보내는 것이다.
여기에 가중치를 더할 수도 있다.
헤더 비딩의 경우는 여러가지 채널에 동시에 요청해서 최적의 결과를 선택하는 것이다. 워터폴의 경우 순차적으로 요청해서 더 좋은 기회가 있을 가능성을 닫아버린다.
DMP를 살펴봤다.
데이터가 공유되기 때문에 주로 서드파티를 사용하지만 서드파티만 사용할 수 있는 것은 아니다. 헷갈렸던 부분이다. 다만 전문적으로 수집을 하는 CDP라는 플랫폼이 있고 상호 보완적으로 사용할 수 있나보다.
목적은 비식별 데이터를 가공해서 관심사가 유사한 유저들을 군집화시키는 것이다.
프로세스는
정보 수집 -> 데이터 정규화 -> 프로필 생성 -> 데이터 저장 -> 산출물 생성
핵심은 같아 보이는 사람을 묶어서 경향성을 파악하는 것이다. 그래서 광고 시청자를 특정하는 것이다.
구매할때는 어떤 청중이 가장 괜찮을지 찾아 실시간으로 최적화를 진행하고, 리타겟팅에 활용한다.
원리는 여러 고객들의 특징을 합쳐서 얼추 비슷해 보이는 사람들을 특정하는 것이다.
엄청 비슷하게 할 수도 있고 대충 때려맞추는 식으로 느슨하게 갈 수도 있다. 효과가 잘 나오는 쪽으로 간다.
DSP에 붙는다고 생각하지만 판매에도 사용된다.
판매측에서는 효과가 좋은 인벤토리가 있으면 비싼 가격에 팔 수 있다. 그러면 해당 인벤토리도 분석해서 어떤 대상이 많이 보는지 분석을 해야 한다.
이런 사람이 나타나면 해줘 -> 이 쪽에 이런 사람이 나타날 가능성이 높아
그리고 얻어낸 잠재고객의 세그먼트를 잘 나눠서 그 자체를 판매할 수도 있다.
이런 부분을 전문적으로 하는 업체를 데이터 브로커라고 한다.
그리고 최근에는 개인정보때문에 문제가 생겨 CDP가 뜨고 있다.
Powered with by Gatsby 2.0