1부: 데이터도 정답도 없다: 하이퍼커넥트가 LLM을 길들이는 법

이 글은 2부작 중 첫 번째 글입니다. 이번 글에서는 2025년 초 수행되었던 Tinder의 AI-enabled Discovery 프로젝트를 예시로, 정답 데이터가 없는 open-ended generation 문제에서 “좋은 설명이란 무엇인가?”를 먼저 정의하고, 그것을 사람이 일관되게 평가할 수 있는 정책으로 정리해 나간 과정을 소개합니다. 2부에서는 이렇게 만든 정책을 바탕으로 LLM-as-a-Judge를 설계한 과정을 다룹니다.

들어가며

“얘 진짜 성격 좋아, 너랑 취미도 잘 맞고. 한번 만나봐.”

누군가에게 소개팅을 주선하거나 받아본 경험, 다들 한 번쯤 있으시죠? 연애 상대를 러닝 크루, 클라이밍 동호회, 와인 모임 등에서 찾는 것보다, 주변 사람이 소개해주는 상대가 더 잘 맞는 경우가 많습니다. 그 이유 중 하나는 노련한 소개팅 주선자의 설명 덕분이죠.

노련한 주선자는 다짜고짜 사진부터 들이밀며 소개하지 않습니다. 이 사람이 어떤 사람인지, 왜 당신과 잘 어울릴 것 같은지를 먼저 설명합니다. 그리고 마지막에 사진을 보여주죠. 빌드업이 지나치면 오히려 불안감이 커지기도 하지만, 많은 경우 이런 설명이 호감도 형성에 큰 영향을 줍니다. 사진만 봤을 땐 그냥 시큰둥했을 상대에게도, 설명 덕분에 매력적으로 느껴지기도 하니까요.

심리학에서는 이런 현상을 초두효과(Primacy effect)라고 부릅니다. 사람은 처음 접한 정보에 더 큰 영향을 받는 경향이 있으며, 이후의 정보보다 먼저 주어진 정보가 인상 형성에 더 큰 역할을 합니다. 예를 들어, “이 사람 성격 정말 좋아, 너랑 잘 맞을 거야”라는 말을 먼저 들으면, 그 다음에 보는 사진이나 행동도 그 설명을 떠올리며 더 긍정적으로 해석하게 되는 것이죠.

그렇다면 이런 인지적 특성을 데이팅 앱에도 적용해볼 수 있지 않을까요? 사진을 먼저 보여주는 대신, 이 상대와 내가 왜 잘 맞을지를 먼저 설명해주는 거죠. 마치 소개팅 주선자처럼요. 유저가 “아, 이 사람이랑 나 잘 맞을지도?”라는 생각을 먼저 하게 만들고, 그 다음 사진을 보여주는 방식입니다.

이런 “소개팅 주선자”를 데이팅앱에 넣으려면 어떻게 해야 될까요? 이 기능을 간단히 설명 기능(Explanation Module)이라고 불러볼게요. 이 기능을 쉽게 구현하는 방법으로 LLM 활용을 떠올려볼 수 있습니다. 그렇다면 여러분의 팀은 어떤 방식으로 이 모듈을 만들 것 같으신가요?

예를 들어 이런 조건이 있다고 해봅시다.

처음 출시하는 기능이라 Ground Truth 데이터는 없다 (즉, “이 상황에서는 이 설명이 나와야 해” 같은 정답이 없다)
서빙을 위해 8B 이하의 LLM만 사용 가능하다 (즉, 프롬프트 엔지니어링 만으로는 원하는대로 동작하지 않을 수 있다)
배포 수준 품질을 만족시켜야 한다

그렇다면 보통은 프로덕트 매니저(PM)가 “소개 기능 제안서”를 만들고, 거기에 어떤 말을 Explanation Module이 출력 해야 할지 예시를 붙이겠죠. 그걸 머신러닝 엔지니어(MLE)가 받아서, 프롬프트 엔지니어링을 하거나, synthetic data로 소량 파인튜닝하거나 등등 알려진 레시피들을 시도할 것입니다.

하지만, 막상 그렇게 해봐도 잘 안 됩니다. 이런 프로젝트를 진행해 보신 분들이라면 아실 겁니다. 아무리 예쁘게 프롬프트를 짜고 모델을 고쳐도, LLM이 내놓는 설명이 기대한 만큼 만족스럽지 않다는 것을요. PM은 “이건 너무 밋밋하고 비논리적이야”라고 실망하고, MLE는 “데이터도 없고 모델도 작은데, 이 이상 뭘 더 하라는 거야?”라며 답답해합니다.

이렇게 LLM이 PM과 MLE의 기대치와 다르게 동작하는 문제는 현업에서 쉽게 발생합니다. 사실 하이퍼커넥트 MGAI 팀도 비슷한 벽을 마주쳤습니다. PM과 MLE 모두가 만족할 수 있는 설명을 만들기란 생각보다 훨씬 어려웠습니다. 하지만 팀은 이 문제를 해결할 수 있는 “이터레이션 프로세스”를 찾아냈습니다. 정책을 세우고, 직접 평가하고, 개선해나가는 이터레이션을 반복하며 결국 출시 가능한 수준의 Explanation Module을 만들어낼 수 있었습니다.

이 글에서는 PM과 MLE 모두가 만족하는 LLM 기반 설명 시스템을 어떻게 만들어낼 수 있는지, 그 과정을 소개합니다. 핵심은 두 역할이 각자의 경계를 허물고 유기적으로 협업하는 데 있으며, 이는 하이퍼커넥트의 일하는 문화중 하나인 Proactive와 맞닿아 있습니다.

보다 구체적인 접근 방식은 다음 두 편의 글에 나눠 설명합니다.

1부: LLM이 적절한 설명을 생성하도록 유도하는 정책(Policy)을 어떻게 수립했는가
2부: 그렇게 만들어진 설명을 자동으로 평가해주는 LLM Judge는 어떻게 설계되었는가

Tinder AI-Enabled Discovery

Tinder는 세계에서 가장 많은 사용자를 보유한 데이팅 앱입니다. 직관적인 UI와 빠른 템포의 사용자 경험 덕분에 전 세계 유저들에게 폭넓은 사랑을 받아왔습니다.

하지만 Tinder는 여기에 머무르지 않고, 더 풍부하고 개인화된 만남의 경험을 제공하고자 새로운 프로젝트를 시작했습니다. 이 프로젝트는 Tinder AI-enabled Discovery라고 불립니다.

AI-enabled Discovery는 더 나은 추천을 위해 사용자로부터 질문과 답변을 통해 추가적인 신호를 수집하고, 이를 바탕으로 유저가 어떤 사람이고 어떤 상대를 원하는지를 모델이 이해할 수 있도록 돕습니다. 단순히 매칭할 상대를 나열하는 것이 아니라, 유저가 왜 그 상대와 잘 맞는지를 설명하는 추천 시스템을 구축하는 것이 핵심입니다.

이 시스템은 일종의 “AI 주선자”처럼 작동합니다. 유저에게 상대를 단순히 보여주는 것을 넘어, 이 상대는 어떤 사람인지, 왜 당신과 잘 맞는 사람인지 설명합니다. Tinder와 MGAI 팀은 이러한 기능을 만들기 위해 협업을 진행했습니다.

설명 생성, 생각보다 어려운 일입니다

이런 설명 생성은 LLM의 자연어 생성 능력으로 쉽게 해결될 것 처럼 보입니다. 하지만 동시에 이런 open-ended generation task는 고유한 어려움이 있습니다. “무엇이 좋은 설명인가?”라는 질문에 답이 없기 때문입니다.

예를 들어보겠습니다. 한 여성 유저는 다음과 같은 특성을 가지고 있습니다.

30대 중반, 디자이너, IT 업계 종사
애견인, 술 마시는 사람을 선호하지 않음
가끔 따릉이를 탐

이 여성 유저에게 다음과 같은 남성 유저를 추천하려 합니다.

30대 초반, 개발자, 사이클링 매니아
애견인, 가끔 위스키를 마심
사진 찍어주는 걸 좋아함

이럴 때, 어떤 정보를 강조해야 매력적이고 설득력 있는 설명이 될까요?

애견인이라는 공통점은 분명 긍정적입니다.
같은 IT 업계 종사자라는 점도 강조할 수 있겠죠.
사이클링 매니아라는 점은 애매합니다. 따릉이를 가끔 타는 것과 본격적인 사이클링은 결이 다르기 때문입니다.
가끔 술을 마시는 점은, “술 마시는 사람을 싫어하는 유저”에게는 오히려 마이너스일 수 있습니다.
사진을 찍는 취미는 어떻게 보면 중립적입니다. 강조한다고 해서 반드시 매칭 확률이 올라간다고 보장하긴 어렵습니다.

이렇듯 유저의 정보를 바탕으로 어떤 설명을 생성할지 결정하는 것은 단순한 기술 문제가 아니라, 제품 설계의 핵심입니다. 정보가 불충분하거나, 유저마다 가치 판단이 다르고, “일반적 상식”이라는 것도 정의하기 어렵기 때문입니다. 그럼에도 불구하고, 우리는 LLM이 생성해야 하는 설명의 방향을 명확히 정책으로 정리할 필요가 있습니다. 왜냐하면 그래야 PM, MLE 등 프로젝트에 참여하는 모두가 같은 목표를 향해 일할 수 있기 때문입니다. 그렇지 않으면 각자 자신의 직관에 따라 설명을 정의하고 제품을 만들어, 제품의 일관성을 해칠 수 있습니다.

이제 PM들이 정책을 직접 작성해보기 시작할 때입니다. 처음엔 모두가 비슷한 생각을 하고 있다고 느낄 수 있지만, 아마 얼마 지나지 않아 세 가지 중요한 문제를 마주하게 됩니다.

첫 번째 문제는 생각보다 서로의 의견이 너무 다르다는 점입니다. 누군가는 어떤 속성을 굉장히 중요한 매칭 기준으로 여기는 반면, 또 다른 사람은 그것을 별로 중요하지 않게 생각합니다.

예를 들어, ‘술을 마신다’는 정보는 어떤 유저에게는 매칭에서 반드시 걸러야 할 요소이지만, 어떤 사람에게는 그냥 부수적인 정보일 뿐입니다. ‘영화 감상’이라는 같은 취미도 사람마다 받아들이는 방식이 다릅니다. 누군가는 주말마다 넷플릭스 신작을 챙겨보고 극장에서 팝콘을 먹는 즐거움을 말하고, 누군가는 빨간 안경을 쓰고 비평하는 것을 말합니다. 누군가에겐 엑셀도 데이터베이스이고, 누군가에겐 html도 프로그래밍 언어입니다 (?). 이처럼 같은 단어, 같은 특성이라도 받아들이는 의미가 사람마다 다르기 때문에, 무엇을 강조하고 무엇을 생략해야 할지에 대한 합의가 쉽게 이뤄지지 않습니다.

두 번째 문제는, 설사 열띤 토론 끝에 어느 정도 합의에 도달하더라도 그것을 ‘정책’이라는 형태로 명료하게 표현하기가 매우 어렵다는 점입니다. 가능한 많은 케이스를 포괄하려고 문장을 추상화하면, 구체적인 엣지 케이스들이 구멍을 빠져나갑니다. 반대로 그런 예외 케이스들을 하나씩 막으려고 규칙을 세세하게 적다 보면, 정책이 지나치게 길어지고 특정 상황에만 동작하는 프랑켄슈타인이 되어 있습니다. 이쯤 되면 ‘우리가 지금 만드는 정책이 정말 현실적인가?’라는 회의가 슬슬 들기 시작합니다.

세 번째 문제는, 어렵게 만든 이 정책을 LLM이 잘 따라서 의도된 결과를 생성할 수 있을지 미리 알 수 없다는 점입니다. 만든 정책을 그대로 프롬프트에 넣고 설명 생성을 요청하면, 그럴듯한 결과가 나올 것 같지만 현실은 그렇지 않습니다. 우리가 회의실에서 고민하며 만들어 낸 대표 케이스들에 대해서는 LLM이 꽤 괜찮은 설명을 만들어내기도 합니다. 하지만 지나가던 옆 팀원이 재미삼아 던진 엣지 케이스에 대해서는 이상한 조합의 문장을 내놓기도 하죠. 그런 실패 사례를 하나둘 막다 보면 프롬프트는 점점 누더기가 됩니다. 정책을 고치고, 프롬프트를 수정하고, 다시 막고, 또 수정하는 과정이 반복되며 입력 토큰 수는 걷잡을 수 없이 불어나기 시작합니다.

각자의 주관을 하나의 기준으로

그래서 다음 이터레이션 프로세스를 제안합니다.

프로세스는 다음과 같습니다.

PM: 빠르게 첫 정책을 만듭니다. 엉성해 보여도 괜찮습니다. 일단 반드시 포함되어야 한다고 생각하는 기준을 중심으로 작성합니다. 이때 가능한 한 일반적이고 포괄적인 문장을 쓰는 것이 좋습니다.
Engineer: 빠르게 model steering을 시도합니다. 미리 준비된 유저 쌍 데이터를 활용해, 해당 정책을 기반으로 설명을 생성해봅니다. 출력 결과가 너무 괴상하지만 않다면 그대로 평가 대상으로 사용합니다. 프롬프트를 다듬거나 최적화하려고 애쓰기보다는, 일단 결과를 빠르게 보는 것이 중요합니다.
PM & Engineer: 각자 자리에서 설명에 대한 pass/fail 평가를 진행합니다. 이때 판단의 기준은 ‘정책에 맞느냐’보다는 ‘내가 보기엔 이 설명이 제품 관점에서 괜찮은가’입니다. 즉, 각자의 직관이 판단 기준입니다. 그리고 이 과정에서 가장 중요한 건 평가 이유, 즉 critique입니다. pass든 fail이든 그 근거를 아주 상세하게 남깁니다.
PM & Engineer: 한 회의실에 모여 의견을 공유하고 합의를 도출합니다. 각자가 남긴 critique를 바탕으로 왜 이 설명이 괜찮았는지 혹은 왜 아니었는지에 대해 논의합니다. 이때 서로 평가가 엇갈린 샘플들이 핵심 논의 대상이 됩니다. 예를 들어, PM은 pass라고 했지만 Engineer는 fail이라고 평가한 설명이 있다면, 그 이유를 상세히 비교합니다. “왜 이 표현은 비논리적으로 느껴졌는가”, “이 설명이 추천 요소와 연결되는 방식이 자연스러운가” 같은 질문을 던지며, 제품 관점과 모델 관점의 차이를 좁혀갑니다. 이렇게 도출된 합의 사항은 곧바로 정책 문장에 반영됩니다. 예를 들어, “설명은 사용자 간에 명시적으로 공유하는 특성을 주제로 만들어야 한다” 같은 문장으로 구체화됩니다. 결국 이 과정은, ‘정책을 단순히 적는 것’이 아니라, 팀의 합의된 기준을 정제해나가는 과정입니다.
이 과정을 반복합니다. 더 이상 큰 변화가 없을 때까지 반복합니다.

이 프로세스가 잘 동작하는 네 가지 이유가 있습니다.

첫 번째는, 우리가 이 과정을 시작할 때부터 ‘정책은 실패할 것’이라는 가정 아래 빠르게 model steering을 시도한다는 점입니다. 처음 만든 정책이 곧바로 잘 작동할 가능성은 낮습니다. 왜냐하면 초반에는 우리가 만들고자 하는 프로덕트의 완벽한 정책이 무엇인지 모르기 때문입니다. 이는 1) LLM의 한계가 무엇인지 몰라서 2) 우리가 원하는 게 뭔지 명확히 몰라서 그렇습니다. 따라서 처음부터 정교한 프롬프트를 설계하느라 시간을 들이기보다는, 빠르게 결과를 보고 빠르게 실패하는 것입니다.

이 과정을 통해 PM은 LLM의 한계를 현실적으로 체감하게 되고, 자연스럽게 더 달성 가능한 목표를 세우게 됩니다. 예를 들어, 정책의 문장을 더 명료하게 작성해야 하는 이유가 이 시점에서 분명해집니다.

엔지니어 역시 이 과정을 통해 어떤 정책은 간단한 프롬프트 수정만으로도 충분히 구현 가능하지만, 어떤 정책은 그렇지 않다는 점을 직접 확인하게 됩니다. 예를 들어 ‘흡연자와 비흡연자’, ‘종교인과 비종교인’처럼 상반되는 특성은 LLM이 꽤 잘 구분할 수 있습니다. 하지만 ‘운동을 좋아함’과 ‘산책을 좋아함’처럼 포함 관계가 애매한 규칙은 LLM이 쉽게 놓칩니다. 사실 어떤 사람에게는 산책이 운동이 아닐 수도 있기에, 사람에게도 일관적인 답을 듣기에 어려운 규칙이기도 합니다. 포함이라는 개념은 주관적이며, 맥락에 따라 달라질 수 있기 때문입니다.

두 번째 이유는, 평가 방식이 pass/fail이라는 단순한 구조를 갖기 때문입니다. 5점짜리 리커트 척도로 정량화하려고 하면 오히려 판단이 더 어려워집니다. 사람들은 종종 3점과 4점 사이에서 헷갈리기 마련입니다. 예를 들어 제품을 설계하는 PM이 어떤 기능이 충분히 좋은지를 평가해야 한다고 가정해봅시다. 만약 5점 척도를 사용한다면, PM은 이렇게 고민하게 됩니다:

“이 기능이 4점이면 좋은 건가? 아니면 최소 3점 이상이어야 하나?”

이러한 판단 기준 자체가 모호하고, 결국 숫자를 부여하는 과정이 의미 없는 논쟁으로 흐를 수 있습니다. 하지만 “좋다/싫다” 또는 “사용할 수 있다/없다” 같은 이분법적 평가는 훨씬 명확합니다. 판단을 내리는 사람은 그저 자신의 직관적 감상에 따라 빠르게 평가할 수 있고, 의사결정의 인지적 부담이 줄어듭니다.

물론, 그 직관이 초기에는 틀릴 수도 있습니다. 하지만 괜찮습니다. 이터레이션 프로세스를 거치며, PM의 감각도 자연스럽게 조정됩니다. 중요한 건 처음부터 완벽한 점수를 매기는 것이 아니라, 결정이 가능한 단순한 기준을 갖고 빠르게 학습과 개선을 반복하는 구조를 만드는 것입니다.

세 번째로, critique를 작성하는 과정은 팀원 각자가 ‘내가 생각하는 좋은 설명이란 무엇인가’를 스스로에게 묻고, 그것을 언어로 정리해보는 계기가 됩니다. pass/fail 자체보다 중요한 것은 그 판단의 근거를 언어화하는 과정입니다. 여기에서 각자의 결정 경계(decision boundary)가 명확히 드러나게 됩니다. 어떤 설명은 좋다고 느껴지고, 어떤 설명은 불편하게 느껴지는지, 왜 그런지를 설명하는 과정에서 자신의 제품 기준이 뚜렷해집니다. 그리고 이 기준은 동료들과 쉽게 공유할 수 있습니다.

마지막으로, 이렇게 각자의 기준이 공유되는 순간, 팀 전체의 decision boundary가 만들어집니다. 처음엔 제각각이었던 제품 지향점들이 critique을 통해 구조화되고, 그 구조가 명료한 문장으로 정리되면서 정책의 형태를 갖추게 됩니다. 이 명문화된 결정 경계는 LLM도 쉽게 이해할 수 있고, 결과적으로 모델이 생성하는 설명도 더 나아지게 됩니다.

요약하자면, 이 프로세스는 LLM의 출력 결과를 빠르게 확인하고, 그것을 바탕으로 팀원 각자가 자신의 기준을 정리한 뒤, 팀 차원에서 그 기준을 조율하고 언어화해 다시 모델에 전달하는 흐름입니다. 인간의 기준이 언어로 정리되어 팀에 공유되고, 다시 모델에게도 전파되는 이 정렬 과정이 반복될수록, LLM은 팀이 기대하는 방향에 더 근접한 출력을 만들어냅니다.

그리고 이는 하이퍼커넥트가 강조하는 Proactive 문화와도 맞닿아 있습니다. PM은 LLM의 한계를 명확히 이해하고 제품을 잘 설계할 수 있습니다. 엔지니어는 기술적 실패를 빠르게 공유하고, 정책의 방향성에 기술적 입력을 넣을 수 있게 됩니다. 각자 생각하는 제품을 위한 최선을, 경계선 의식 없이 팀과 모델에까지 전달하는 것입니다. 이런 방식은 불확실성이 큰 LLM 관련 프로젝트를 할 때 큰 도움이 됩니다.

정책 수렴, 그 다음은?

이렇게 이터레이션을 몇 번 돌리다 보면, 꽤 빠른 속도로 정책이 수렴하는 것을 확인할 수 있습니다. 초반에는 크고 작은 수정이 빈번하게 일어나지만, 점차 의견 충돌이 줄고, pass/fail 기준도 일정해지며 정책 문장이 거의 손대지 않아도 되는 시점이 옵니다. 이 지점에 도달하면, 우리는 해당 정책이 어느 정도 안정화되었다고 판단할 수 있습니다.

이후 단계에서는, 수립된 정책에 따라 동작하는 모델을 실시간으로 서빙 가능한 형태로 만드는 작업이 필요합니다. 일반적으로 상용 LLM에 잘 짜여진 프롬프트를 넣어주는 것으로도 고품질 출력을 만들 수 있지만, 실시간 서빙에는 적합하지 않은 경우가 많습니다. 이를 해결하기 위해 상용 LLM이 생성한 설명 예시를 학습 데이터로 삼거나, 사람이 정책에 기반하여 만든 데이터로 작은 모델을 학습합니다. 이 과정을 통해, 정책을 내재화한 작고 빠른 모델을 만들 수 있습니다. 이 글에서는 세부적인 학습 방법에 대해서는 다루지 않겠습니다.

다만, 이렇게 학습된 모델의 출력을 사람이 하나하나 평가하는 것은 불가능에 가깝습니다. 수천, 수만 개의 설명을 수작업으로 검토하는 것은 현실적이지 않기 때문입니다. 그래서 우리는 이 시점부터 LLM Judge를 사용합니다. 즉, LLM이 생성한 설명을 또 다른 LLM이 평가하도록 하는 구조입니다. 이때 핵심은, 평가에 사용되는 LLM Judge가 정책을 정확히 이해하고 그에 따라 판단할 수 있도록 만들어져야 한다는 점입니다. 어떻게 하면 정책을 잘 따르는 LLM Judge를 만들 수 있을지는 이후 공개할 2부 글에서 더 자세히 다룰 예정입니다.

마치며

좋은 설명을 만들려면 좋은 설명이 무엇인지 알아야 합니다. 설명을 잘하는 LLM을 만든다는 것은 곧 우리가 원하는 설명이 무엇인지 끊임없이 묻고, 합의하고, 그 기준을 모델에까지 일관되게 전달하는 일입니다. 이 과정에는 시행착오도 있고, 애매한 순간도 많지만, Tinder와 하이퍼커넥트는 Proactive한 문화 속에서 경계선 없이 유기적으로 협업하며 함께 문제를 풀어냈습니다. 이런 불확실성이 가득한 문제를 저희 MGAI 팀과 함께 풀고 싶은 분을 기다리고 있습니다!