본문 바로가기메뉴 바로가기


카카오 AI추천 : 협업 필터링 모델 선택 시의 기준에 대하여

안녕하세요. 카카오 추천팀의 hee.yoon입니다. 

여기에서는 협업 필터링(Collaborative Filtering, CF)이 무엇인지를 먼저 살펴 본 다음, 협업 필터링을 활용해 추천 시스템을 개발할 때 중요하게 고려해야 하는 항목에 대해 이야기하고자 합니다.


들어가며

협업 필터링(Collaborative Filtering, CF)을 활용하여 새로운 추천 모델을 만들어야 한다고 생각해 봅시다. 무엇부터 고민을 시작할 것 같나요? 

어떤 모델을 쓸까? Matrix Factorization(행렬 분해)1 모델을 쓸까? 딥러닝 모델을 쓸까? ···

사실 이보다 더 중요하게 고민해야 할 부분은 “어떤 문제를 풀까”입니다. 어떤 문제를 푸느냐에 따라, 어떤 모델이 적합할지에 대한 답을 할 수 있게 되겠죠.

예를 들어, 이미 많은 유저가 사용하고 있어 충분한 피드백이 있는 서비스와, 그렇지 않은 서비스에서 사용할 수 있는 모델은 서로 다를 수 있습니다. 아이템을 1개만 추천하는 구좌와 30개를 추천하는 구좌에서도 차이가 있을 수 있습니다. 또한, 클릭 확률을 정확하게 예측하는 것이 중요한 경우도 있고, 그보다는 랭킹 자체가 더 중요한 경우도 있습니다.

이처럼 다양한 상황에서 활용할 수 있는 추천 모델은 각기 다를 수 있습니다. 먼저 추천 모델의 종류를 알아보고, 이중 추천 시스템에서 가장 많이 활용되고 있는 협업 필터링(CF)이 무엇인지를 살펴보겠습니다. 이어서, 이를 활용해 추천 시스템을 개발할 때 중요하게 고려해야 하는 점들에 대해 살펴봅시다. 

 1Matrix Factorization(행렬 분해) 모델: 사용자의 기호 데이터를 행렬로 만드는 방식. 모든 사용자가 모든 콘텐츠를 소비할 수는 없기 때문에, 비어있는(sparce) 행렬이 만들어지는데, 이렇게 행렬의 비어 있는 부분을 채우는 기술을 통틀어 Matrix Factorization(행렬 분해)이라고 함.

추천 모델

추천 모델은 크게 두 가지로 나눌 수 있습니다. 유저, 아이템 상호작용 데이터를 활용하는 협업 필터링(Collaborative Filtering, CF) 모델과, 유저 및 아이템의 텍스트 및 이미지 정보 등을 활용하는 콘텐츠 기반 필터링(Content-based Filtering, CB) 모델입니다.

  • 협업 필터링(CF): 추천에서 가장 많이 사용되는 기술로, 유저-아이템 간 상호 작용 데이터를 활용하는 방법론. 즉, “이 영화를 좋아했던 다른 사람들은 또 어떤 영화를 좋아해요?”
  • 콘텐츠 기반 필터링(CB): 콘텐츠 자체를 분석해 유사한 콘텐츠를 찾는 기술로, 대상 자체의 특성을 바탕으로 추천하는 방법론. 즉, “라디오헤드를 좋아하는 사람은 콜드플레이도 좋아하지 않을까요?”

CF 모델의 핵심 가정은 나와 비슷한 취향을 가진 유저들은 어떠한 아이템에 대해 비슷한 선호도를 가질 것이라는 점입니다. 실제로 주위에서도 몇 가지 영화 취향이 비슷한 경우, 임의의 영화에 대한 평이 비슷할 가능성이 높습니다. 한편, CB 모델의 경우, 유저-아이템의 상호작용 데이터 없이도, 아이템 자체의 이름, 카테고리, 상세 설명, 이미지 등을 활용해 유사성을 판단하고 비슷한 아이템을 추천할 수 있습니다. 

신규 아이템의 경우, 유저와의 상호작용 데이터가 없기 때문에 CF 모델에서는 추천되기 어렵지만, CB 모델에서는 텍스트 혹은 이미지 유사성 기반의 추천이 가능합니다. 한편, CF 모델은 유저-아이템의 상호작용을 바탕으로 하기 때문에, 꼭 텍스트/이미지 기반 유사성이 높지 않더라도, 실제로 함께 소비하는 경향이 높은 아이템을 발견하여 추천이 가능합니다. 이처럼 CF와 CB 모델은 서로 상호 보완적인 역할을 한다고 볼 수 있습니다.

이 중에서, 추천 시스템에서 가장 많이 사용되는 기술인 만큼 “CF 모델”에 초점을 맞춰 보겠습니다.

협업 필터링(Collaborative Filtering, CF) 모델

CF 모델은 크게 두 가지 접근 방법으로 나뉩니다. 메모리 기반의 접근 방식과 모델 기반의 접근 방식입니다.

  • 메모리 기반의 접근 방식: 가장 전통적인 접근 방식입니다. 유저 간/아이템 간 유사도를 메모리에 저장해두고 있다가, 특정 유저에 대하여 추천이 필요할 때 해당 유저와 유사한 k 명의 유저가 소비한 아이템들을 추천하거나, 혹은, 특정 아이템에 대한 Rating 예측이 필요할 때 해당 아이템과 유사한 k 개의 아이템의 Rating을 기반으로 추정을 할 수 있습니다.
  • 모델 기반의 접근 방식: Latent Factor 방식과 Classification/Regression 방식 및 딥러닝을 사용한 접근 등 다양한 접근 방식이 있습니다. 

모델 기반의 접근 방식

Latent Factor2 방식: Matrix Factorization(행렬 분해)

모델 기반의 접근 방식 중에서도 Latent Factor 기반의 방식, 특히 아이템 Latent Vector(잠재 벡터)와 유저 Latent Vector 간 Inner Product로 아이템에 대한 유저의 선호를 모델링 하는 Matrix Factorization 방식의 접근은, 간단하지만 강력한 추천이 가능합니다. Autoencoder3를 추천에 활용하기도 하는데, 이는 Latent Factor 방식의 일반화(Generalization)4라고 볼 수 있습니다. (10번 레퍼런스 참조)

Classification/Regression(분류/회귀) 방식

Classification/Regression 방식은 콘텐츠 기반 추천 방식과 쉽게 융합이 가능합니다. 피처 X 가 주어졌을 때, 라벨 y를 예측하는 구조이기 때문에, 피드백 y를 예측하는 상황에서,  X에 콘텐츠 관련 정보를 피처로 만들어서 추가하면, 피드백 데이터뿐만 아니라 콘텐츠 데이터를 활용한 추천이 가능합니다.

최신의 융합 모델 방식

최근에는 다양한 방식의 모델들이 제안되며, 단순하게 모델을 분류하기 어려운 부분도 있는데요, Latent Factor 모델과 Classification/Regression 모델의 특징을 모두 가지고 있는 Factorization Machine 계열의 모델들도 제안되어 왔고, 딥러닝을 활용하여 복잡한 Interaction을 모델링 하는 방향으로 Latent Factor 모델을 확장한 Neural Collaborative Filtering도 제시되었으며, 레이어 설계가 자유로운 딥러닝 모델 특성상 자연스럽게 콘텐츠 정보를 결합한 하이브리드 추천 방식의 모델도 많이 제안되었습니다. 

이처럼, 다양한 CF 모델 중 어떤 CF 모델을 사용해야 할지는 크게 다음의 3가지 요소가 결정합니다. 

2Latent Factor(잠재 인수) : 사용자와 아이템 데이터에 숨어있는 특징을 잠재적인 차원(Factor)을 사용해 나타내고자 하는 모델로, Matrix Factorization(행렬 분해) 방식이 대표적.
3Autoencoder : 학습 데이터에 레이블 데이터를 별도로 구축할 필요가 없는, 주어진 데이터만으로 학습이 가능한 비지도 학습 모델로, Encoder와 Decoder의 2개의 신경망으로 구성됨. Encoder는 입력 데이터에서 학습에 중요하다고 판단되는 정보만을 남기고 불필요하다고 판단되는 데이터는 제거함으로써 첫 입력 데이터보다 더 작은 크기의 데이터를 생성하는 역할을 하며, Decoder는 다시 처음의 입력 이미지로 복원하는 역할을 함. 이때, Encoder가 생성하는 더 작은 크기의 데이터를 Latent Vector(잠재 벡터)라고 칭함. 즉, Autoencoder가 학습하고 데이터를 생성하는 과정은 한 문장의 설명을 듣고 몽타주를 그리는 과정과 유사함.
4Generalization(일반화) : 모델이 특정 데이터에 과 적합(Overfitting) 되지 않고 다양한 데이터에 모두 적용 가능한 상태가 되는 것을 말함.

어떤 CF 모델을 선택할 것인가(1): 피드백(Feedback) 데이터

CF 모델은 유저, 아이템 상호작용 데이터를 활용한다고 언급하였는데요, 이 피드백 데이터의 종류에 따라서 모델의 선택이 달라질 수 있습니다.  

카카오에는 다양한 서비스가 존재하는 만큼 다양한 형태의 피드백이 존재합니다. 예를 들어, 선물하기의 경우, “이 선물 좋아요”, 다음 영화 “평점”과 같이 유저의 콘텐츠에 대한 선호를 직접 수집할 수 있는 경우가 있습니다. 이러한 피드백은 Explicit Feedback(명시적 피드백)이라고 합니다. 유저의 선호를 유저가 직접 표현한 데이터이기 때문에 정확도가 높습니다. 그러나 이러한 피드백을 애써 남기는 유저는 많지 않습니다. 흔히 말하는 MovieLens(영화 평점) 데이터와 같은 유형의 데이터를 얻을 수 있는 서비스는 한정적입니다. 

반면, 클릭, 콘텐츠 소비, 구매와 같은 행동 패턴은 유저도 모르는 사이에 자연스럽게 유저의 선호를 유추할 수 있게 합니다. 선물하기에서는 “클릭”, “구매”,  픽코마의 경우, “클릭”, “콘텐츠 소비”, “코인 사용”과 같은 피드백, 다음 뉴스의 경우에는 “클릭” 및 “체류 시간”에 관한 피드백을 수집하기도 합니다. 이러한 피드백의 경우,  유저가 이 콘텐츠에 대해 싫어하는지는 알 수가 없습니다(Unary Rating). 즉, 유저가 해당 콘텐츠를 여러 번 소비한 경우에는 선호가 높다고 가정할 수 있지만, 유저가 클릭하지 않은 아이템이 유저가 선호하지 않아서 소비하지 않은 것인지, 알고 보니 취향인데 소비하지 않은 것인지는 알 수 없습니다. 

Implicit Feedback(암시적 피드백)의 이러한 특성을 잘 고려한 모델이 흔히 Alternating Least Squares(ALS)5라 불리는 모델입니다. 유저가 스스로 밝힌 취향 그 자체인 Explicit Feedback과 달리 Implicit Feedback은 유저가 해당 아이템을 소비하고 불만족하였을 수도 있고, 소비하지 않은 아이템을 꼭 싫어한다고 볼 수도 없기 때문에, 이러한 불확실성을 반영하기 위해 Confidence 개념을 도입했습니다. Implicit Feedback이 존재하는 경우는 “선호가 있다”라고 해석하고, 반대의 경우는 “선호가 없다”라고 해석합니다. 다만, 그러한 판단이 얼마나 확신할 수 있는지는 Implicit Feedback을 바탕으로 계산하게 됩니다. 아무래도 특정 아이템을 소비한 횟수가 많으면 많을수록, 실수로 소비했다거나, 소비 후 불만족했다고 보기 어렵겠죠. 또한, 한 번도 소비하지 않은 경우는 불확실성이 매우 높을 것이고요. 

이처럼 ALS 모델은 단순히 관찰된 피드백뿐만 아니라 관찰되지 않은 제로 피드백의 경우에도 학습 과정에 반영 가능합니다. 이 과정에서 계산량이 많아지다 보니, alternating-least-squares optimization 방식을 사용하여 학습을 진행하기 때문에 위와 같은 이름이 붙게 되었습니다.

참고:  Implicit Feedback의 특성을 고려하여 Confidence 개념을 도입한 ALS의 Cost 공식(2번 레퍼런스 참조)

 5Alternating Least Squares(ALS) : 교대 최소 제곱법. 목적함수를 최적화하는 기법으로, 사용자와 아이템의 Latent Factor를 한 번씩 번갈아가며 학습시킴. 아이템의 행렬을 상수로 놓고 사용자 행렬을 학습시키고, 사용자 행렬을 상수로 놓고 아이템 행렬을 학습시키는 과정을 반복함으로써 최적의 Latent Factor를 학습시키는 방법.

어떤 CF 모델을 선택할 것인가(2): 메트릭(Metrics)

CF 모델을 어떤 기준으로 평가하느냐에 따라서도 모델의 선택이 달라질 수 있습니다. 우리가 추천 모델을 사용하게 되는 구좌의 맥락이 약간씩 다른데, 그때마다 우리가 최적화해야 하는 메트릭도 달라질 수 있습니다.

예를 들어, 광고 추천의 경우에는 광고를 클릭할 예상 확률(predicted click-through rate)이 광고 과금액 선정에 직접적인 영향을 미치기 때문에, 클릭할 확률을 정확하게 맞추는 게 중요합니다. 한편, Top N 개의 후보군을 추출하는 경우에는, 예측값 자체보다는 상위 추천 결과에 유저가 클릭할 만한 아이템이 얼마나 많이 추천되는지가 중요한 경우도 있습니다. 이러한 목적에 맞추어 최적화해야 하는 메트릭을 선택합니다.

하나의 모델을 학습할 때, 여러 가지 메트릭 중에서 어떤 메트릭은 개선이 되어도, 다른 메트릭에서는 개선이 일어나지 않는 경우도 종종 있습니다. 예를 들어, 예측값과 실제 클릭 여부(0, 1) 사이의 차이를 측정하는 지표인 Log Loss가 줄어들어도 랭킹은 그대로일 수 있고, 따라서 랭킹 메트릭은 개선이 되지 않을 수도 있습니다. 이처럼, 여러 메트릭을 측정하더라도, 현재 문제 상황에서 가장 중요한 개선 메트릭이 무엇인지를 파악하는 것이 매우 중요합니다. 

예를 들어 보겠습니다. 예측값과 실제 클릭 여부의 차이를 측정하는 메트릭이 아닌, 클릭 확률로 줄을 세웠을 때, 클릭한 아이템이 클릭하지 않은 아이템보다 상위에 랭크될 확률을 계산한 AUC를 최적화하는 것이 중요한 태스크의 경우에는, Bayesian Personalized Ranking(BPR)6과 같이 AUC를 직접 최적화하는 모델을 사용하는 것이 적합할 수 있습니다. 

많은 추천 모델들이 랭킹 문제를 풀고 있지만, 랭킹 자체를 최적화하기보다는, 아이템 한 개와 관련된 Pointwise Loss7의 최적화를 통해 랭킹 메트릭의 최적화 또한 기대합니다. 즉, 특정 아이템에 대해 예측한 값이 실제 값과 얼마나 다른지를 Loss로 정의하고, 그 Loss를 최소화하는 방식으로 작동합니다.  

그러나 BPR의 경우, 단순히 아이템 한 개가 아니라, 선호하는 아이템과 선호하지 않는 아이템 페어8를 활용하여, 선호하는 아이템이 더 상위에 랭크되는지를 측정하는 메트릭인 AUC를 직접 최적화하는 학습 프레임워크를 제공합니다. 즉, 선호하는 아이템과 선호하지 않는 아이템의 예측값 사이의 차이를 최대한 벌리는 방식으로 작동합니다. 

참고:  BPR Maximization 함수(3번 레퍼런스 참고)

 6Bayesian Personalized Ranking(BPR) : 아이템에 대한 사용자의 선호도를 확률 모형화한 모델로, 사용자가 선호하는 아이템을 단계별로 카테고리화(긍정적 아이템, 부정적 아이템) 해서 분석을 진행함. 아이템을 카테고리화할 때 사용자가 내재적 피드백을 제공했는지 안 했는지의 정보만을 이용하기 때문에 정보의 손실이 발생할 수 있지만, 기존의 기법 대비 우수한 성능을 보이는 모델.
7Point-wise: 손실 함수(Loss Function)에서 한 번에 하나의 아이템만을 고려하는 방법으로, 하나의 사용자에 대응하는 하나의 아이템만을 자기고 Score를 계산하고 이를 Label Score과 비교해서 최적화함. 아이템 간의 순서 관계를 무시하고 독립적인 개체로써 학습시키고 결과만을 정렬한다는 단점이 있으나, 그만큼 직관적인 모델이기도 함.
8Pair-wise: 손실 함수(Loss Function)에서 한 번에 2개의 아이템을 고려하는 방법. 1개의 긍정적 아이템과 1개의 부정적 아이템을 고려하기 때문에, 데이터 셋에 {사용자, 긍정적 아이템, 부정적 아이템}의 3가지 항목이 포함되어야 하고, 이로 인한 데이터 중복을 해결하기 위해 Sampling 기법이 활용됨.  

어떤 CF 모델을 선택할 것인가(3): Bias & Feedback Loop

마지막으로 고려할 점은, 추천 시스템에서 학습에 활용하는 피드백 데이터는 본질적으로 실험 데이터가 아닌 관찰 데이터라는 점입니다. 즉, 통제된 환경이 아닌, 여러 가지 요인에 의해 데이터 수집에 영향을 받아 다양한 Bias가 끼어있는 데이터입니다. 대표적으로, 추천 시스템이 노출시키는 특정 아이템에만 노출이 된 아이템에 대한 유저의 피드백만을 관찰할 수 있습니다. 이와 같은 문제는 피드백 루프(Feeback Loop)로 더욱 강화됩니다. 즉, 추천 시스템이 추천한 결과를 다시 추천 시스템이 학습하여, 계속 모델 Bias가 강화되는 문제입니다. 

이는 유저에게 더 큰 만족을 줄 수도 있는 아이템의 유입을 어렵게 하여, 장기적으로는 추천 시스템의 온라인 성능이 하락하는 문제로 이어질 수 있습니다. 동시에 Bias가 존재하는 데이터는 오프라인에서 신규 모델 개발에 있어 평가를 어렵게 합니다. 

이러한 Bias가 존재하는 데이터 셋을 이용하여 평가가 이루어지면, 기존 모델에 더 유리하게 평가가 되기도 합니다. 특히, nDCG(normalized Discounted Cumulative Gain)9와 같은 메트릭의 경우, 이러한 Bias가 존재하는 데이터로 평가할 경우, 기존 추천 결과를 얼마나 모사하느냐를 평가하게 되기 때문에, 각별한 주의가 필요합니다. 

이와 같은 Bias 및 피드백 루프 문제를 방지하는 가장 간단한 방법으로, 랜덤하게 추천된 데이터를 수집해 학습 및 평가에 활용하는 방법이 있지만, 랜덤 데이터 수집은 유저 경험에 상당한 악영향을 끼칠 수 있어 대규모로 수집하는 것은 어렵습니다. 그래서 Bias가 존재하는 데이터로도 최대한 공정한 평가를 하기 위한 Debiasing 방법들이 연구되고 있습니다. 평가뿐만 아니라, 모델 학습에 있어서도 Debiasing 방법론을 활용한 연구들이 진행되고 있습니다(7번 레퍼런스 참조).

9nDCG(normalized Discounted Cumulative Gain): 추천 시스템에서 랭킹 추천 분야에서 많이 쓰이는 평가 지표로, 특히 상위의 랭킹 리스트가 하위 랭킹 리스트보다 확연​​하게 중요한 도메인에서 유용한 평가 기준.

마무리

카카오에는 다양한 서비스가 존재하는 만큼, 다양한 문제도 존재합니다. 여러 가지 문제에 범용적으로 활용될 수 있는 솔루션을 개발할 수도 있고, 특수한 상황에 적합한 솔루션을 개발하는 것이 필요한 케이스도 있습니다.

이 글을 읽는 여러분과 함께, 단순히 정의된 문제를 푸는 것이 아니라, 문제를 찾고 문제를 정확히 정의하여, 문제에 적합한 모델, 메트릭, 데이터 수집 방법 등을 설계하여 문제를 해결하는 경험을 통해 함께 성장하는 경험을 할 수 있다면 좋을 것 같습니다. 


참고) 

  1. Charu C Aggarwal. 2016. Recommender Systems. Springer.
  2. Y. Hu, Y. Koren, and C. Volinsky. Collaborative filtering for implicit feedback datasets. In IEEE International Conference on Data Mining (ICDM 2008)
  3. S. Rendle, C. Freudenthaler, Z. Gantner, and L. Schmidt-Thieme. Bpr: Bayesian personalized ranking from implicit feedback. In UAI, 2009.
  4. P. Cremonesi, Y. Koren, and R. Turrin. Performance of recommender algorithms on top-n recommendation tasks. In RecSys 2010
  5. Wei Chen, Tie-Yan Liu, Yanyan Lan, Zhi-Ming Ma, and Hang Li. 2009. Ranking Measures and Loss Functions in Learning to Rank. In NIPS.
  6. D. C. Liu, S. Rogers, R. Shiau, D. Kislyuk, K. C. Ma, Z. Zhong, J. Liu, and Y. Jing, “Related pins at pinterest: The evolution of a real-world recommender system,” in WWW Companion, 2017
  7. Tobias Schnabel, Adith Swaminathan, Ashudeep Singh, Navin Chandak, and Thorsten Joachims. 2016. Recommendations as Treatments: Debiasing Learning and Evaluation. In International Conference on Machine Learning.
  8. Longqi Yang,Yin Cui, Yuan Xuan, Chenyang Wang, Serge Belongie, and Deborah Estrin. Unbiased Offline Recommender Evaluation for Missing-not-at-random Implicit Feedback. In RecSys 2018
  9. Jiawei Chen, Hande Dong, Xiang Wang, Fuli Feng, Meng Wang, and Xiangnan He. 2020. Bias and Debias in Recommender System: A Survey and Future Directions.
  10. S. Li, J. Kawale, and Y. Fu. Deep collaborative filtering via marginalized denoising auto-encoder. In CIKM 2015.
  11. Xiangnan He, Lizi Liao, Hanwang Zhang, Liqiang Nie, Xia Hu, and Tat-Seng Chua. Neural collaborative filtering. In Proceedings of the 26th International Conference on World Wide Web 2017
hee.yoon
hee.yoon 추천팀 머신러닝 엔지니어입니다
Top Tag
2021
2021-new-krew
Ad Platform
Ad tech
adaptive-hash-index
adt
adtech
agile
agilecoach
ai
algorithm
Algorithm/ML
Algorithm/Ranking
almighty-data-transmitter
Analyzer
android
angular
anycast
App2App
applicative
Architecture
arena
ast
async
aurora
babel
babel7
Backend
BApp
bgp
big-data
binary
ble
blind-recruitment
block
Block Chain
blockchain
bluetooth
brian
business
Cache
cahtbot
canvasapi
Caver
cch
cd
CDR
ceph
certificate
certification
CF
cgroup
chrome
ci
cite
client
clojure
close-wait
cloud
cloudera-manager
clustered-block
cmux
cnn
code-festival
code-review
codegame
codereview
coding
coding test
Collaborative Filtering
communication
competition
Compliance
component
conference
consul
container
contents
contest
contribution
cookie
core-js@3
Corporate Digital Responsibility
couchbase
COVID-19
cpp
culture
Data
data-engineering
DB
deep-learning
Dependency
dependency-graph
desktop
dev
dev-session
dev-track
developer
developer relations
developers
devops
digitalization
digitaltransformation
dns
docker
dr
Electron
employeecard
emscripten
eslint
event
extract-text
Feature List
Featured
Feedback
friendstime
front-end
frontend
functional-programming
funfunday
fzf
garbage-collection
gawibawibo
GC
GHC
github
globalpollution
go
Grace Hopper Celebration
graphdb
graphql
Ground X
growth
ha
hadoop
hate speech
hbase
hbase-manager
hbase-region-inspector
hbase-snashot
hbase-table-stat
hbase-tools
hri
ICPC Sinchon
id
if kakao
ifkakao
infrastructure
innodb
internship
ios
item
Java
javascript
javascript web-assembly
JCMM
JIRA
jsconf
jsconfkorea
json
k8s
kafka
kakao
kakao-Career-Boost-Program
kakao-commerce
kakao-games
kakaoarena
kakaobrain
kakaocommerce
kakaocon
kakaoenterprise
kakaok
kakaokey
kakaokrew
kakaomap
kakaopage
kakaotalk
KAS
KCDC
khaiii
Klaytn
Klip
KnowledgeGraph
kubernetes
l3dsr
l4
License
links
Linux
load-balancing
MAB
Machine Learning
machine-learning
map
marathon
meetup
melon
mesos
message
Messaging
microservice
Microsoft TypeScript
mm
mobil
mobile
mocking
monad
monorepo
ms-office
MSA
mtre
mysql
mysql-realtime-traffic-emulator
nand-flash
network
new
new-krew
nfc
Nickface
nomad
ocp
olive
onboarding
open
open source
opensource
openstack
OpenWork
OSS
page
pair programming
parallel
PBA
performance
planning poker
Platform
polyfill
preview
programming-contest
project
project-structure
pycon
python
quagga
react
reactive-programming
reactor
recap
recommendation
recommendation system
recruitment
redis
redis-keys
redis-scan
related-blind
Renderer
rest
Rome
rubics
ruby
rxjs
s2graph
scala
scalaz
seminar
Serve
server
service
service worker
session
sharding
shopping
Shuffle Partition
socket
spark
spark-streaming
SpringBoot
ssd
Statistics/Analysis
Stomp
storage
storm
style-guide
summer internship
support
System
talk
talkchannel
tcp
tech
Techtalk
test
thread
Thread-Debugging
time-wait
tmux
Topic Modeling
typescript
Untact
update
User Story
vim
vim-github-dashboard
vim-plugin
vue
vue.js
WASM
web
web-cache
web-worker
webapp
webgl
WebSocket
webworkers
weekly
Women Technologists
work
workplatform
개인화 추천
길찾기
라이선스
연관 추천
오픈소스
오픈소스검증
의존성분석
일하는방식
협업
All Tag
2021
2021-new-krew
Ad Platform
Ad tech
adaptive-hash-index
adt
adtech
agile
agilecoach
ai
algorithm
Algorithm/ML
Algorithm/Ranking
almighty-data-transmitter
Analyzer
android
angular
anycast
App2App
applicative
Architecture
arena
ast
async
aurora
babel
babel7
Backend
BApp
bgp
big-data
binary
ble
blind-recruitment
block
Block Chain
blockchain
bluetooth
brian
business
Cache
cahtbot
canvasapi
Caver
cch
cd
CDR
ceph
certificate
certification
CF
cgroup
chrome
ci
cite
client
clojure
close-wait
cloud
cloudera-manager
clustered-block
cmux
cnn
code-festival
code-review
codegame
codereview
coding
coding test
Collaborative Filtering
communication
competition
Compliance
component
conference
consul
container
contents
contest
contribution
cookie
core-js@3
Corporate Digital Responsibility
couchbase
COVID-19
cpp
culture
Data
data-engineering
DB
deep-learning
Dependency
dependency-graph
desktop
dev
dev-session
dev-track
developer
developer relations
developers
devops
digitalization
digitaltransformation
dns
docker
dr
Electron
employeecard
emscripten
eslint
event
extract-text
Feature List
Featured
Feedback
friendstime
front-end
frontend
functional-programming
funfunday
fzf
garbage-collection
gawibawibo
GC
GHC
github
globalpollution
go
Grace Hopper Celebration
graphdb
graphql
Ground X
growth
ha
hadoop
hate speech
hbase
hbase-manager
hbase-region-inspector
hbase-snashot
hbase-table-stat
hbase-tools
hri
ICPC Sinchon
id
if kakao
ifkakao
infrastructure
innodb
internship
ios
item
Java
javascript
javascript web-assembly
JCMM
JIRA
jsconf
jsconfkorea
json
k8s
kafka
kakao
kakao-Career-Boost-Program
kakao-commerce
kakao-games
kakaoarena
kakaobrain
kakaocommerce
kakaocon
kakaoenterprise
kakaok
kakaokey
kakaokrew
kakaomap
kakaopage
kakaotalk
KAS
KCDC
khaiii
Klaytn
Klip
KnowledgeGraph
kubernetes
l3dsr
l4
License
links
Linux
load-balancing
MAB
Machine Learning
machine-learning
map
marathon
meetup
melon
mesos
message
Messaging
microservice
Microsoft TypeScript
mm
mobil
mobile
mocking
monad
monorepo
ms-office
MSA
mtre
mysql
mysql-realtime-traffic-emulator
nand-flash
network
new
new-krew
nfc
Nickface
nomad
ocp
olive
onboarding
open
open source
opensource
openstack
OpenWork
OSS
page
pair programming
parallel
PBA
performance
planning poker
Platform
polyfill
preview
programming-contest
project
project-structure
pycon
python
quagga
react
reactive-programming
reactor
recap
recommendation
recommendation system
recruitment
redis
redis-keys
redis-scan
related-blind
Renderer
rest
Rome
rubics
ruby
rxjs
s2graph
scala
scalaz
seminar
Serve
server
service
service worker
session
sharding
shopping
Shuffle Partition
socket
spark
spark-streaming
SpringBoot
ssd
Statistics/Analysis
Stomp
storage
storm
style-guide
summer internship
support
System
talk
talkchannel
tcp
tech
Techtalk
test
thread
Thread-Debugging
time-wait
tmux
Topic Modeling
typescript
Untact
update
User Story
vim
vim-github-dashboard
vim-plugin
vue
vue.js
WASM
web
web-cache
web-worker
webapp
webgl
WebSocket
webworkers
weekly
Women Technologists
work
workplatform
개인화 추천
길찾기
라이선스
연관 추천
오픈소스
오픈소스검증
의존성분석
일하는방식
협업

위로