모델보다 먼저 고민한 데이터

AI 추천 시스템, 모델보다 먼저 고민한 것은 데이터였습니다

-반장노트 프로젝트에서 모델별 데이터 요구사항과 Filtering 기준을 검토한 경험-

1. 처음부터 모델을 고르지 않았던 이유

AI 추천 시스템을 준비한다고 하면 흔히 협업 필터링이나 딥러닝 모델부터 떠올리게 됩니다. 저 역시 어떤 추천 방법을 사용할 수 있을지 관심이 있었지만, 반장노트 프로젝트에서 가장 먼저 확인한 것은 알고리즘이 아니라 데이터였습니다.

당시에는 추천에 활용할 행동 이력과 학습 데이터가 축적되지 않은 상태였습니다. 직종, 경력, 급여와 같이 서비스에서 입력받을 수 있는 항목은 생각해 볼 수 있었지만, 사용자가 실제로 어떤 대상을 선택했고 어떤 결과로 이어졌는지를 보여주는 기록은 아직 없었습니다. 결국 모델을 학습시키거나 성능을 비교할 근거가 부족했습니다.

이 상황에서 하나의 모델을 먼저 결정하면 그 모델이 요구하는 데이터를 뒤늦게 수집해야 할 수도 있습니다. 반대로 데이터부터 무작정 저장하면 실제 학습에 필요한 구분이나 맥락이 빠질 수 있습니다. 그래서 접근 순서를 바꿨습니다. 현재 확보 가능한 항목을 살펴본 다음, 여러 추천 방법이 요구하는 데이터를 비교하고, 서비스 초기에 무엇을 기록해야 하는지부터 검토했습니다.

“지금 어떤 모델이 가장 좋은가?”보다 “나중에 모델을 비교할 수 있도록 지금 어떤 데이터를 남겨야 하는가?”가 먼저였습니다.

이 글은 추천 모델의 구현 결과나 성능을 소개하는 글이 아닙니다. 현재 데이터 수집을 준비하는 과정에서 제가 검토한 추천 방법, 필수 조건 처리에 대해 내린 결정, 그리고 데이터 구조를 생각하면서 발견한 기술적 문제를 공유하려는 글입니다.

2. 추천 모델을 데이터 관점에서 비교해 보았습니다

추천 방법마다 필요한 정보의 형태가 다릅니다. 프로필의 속성을 비교하는 방법, 여러 사용자의 행동 패턴을 비교하는 방법, 실제 요청이나 수락 결과를 학습하는 방법은 데이터가 만들어지는 위치부터 다릅니다. 따라서 알고리즘의 일반적인 장단점보다 반장노트에서 어떤 데이터가 있어야 작동하는지를 기준으로 살펴보았습니다.

속성 기반 추천: 가지고 있는 정보가 곧 선호는 아닙니다

직종이나 경력처럼 구조화된 값은 비교하기 쉽습니다. 하지만 이런 정보만으로 “누구를 더 선호하는가”를 설명하기는 어렵습니다. 예를 들어 최소 경력 조건을 두 사람 모두 충족한 상황에서, 경력이 더 많은 사람이 반드시 더 자주 선택되는지는 데이터가 있어야 판단할 수 있습니다.

이 때문에 기본 프로필 외에 역할과 작업 방식, 협업 환경에 대한 선호 같은 추가 항목을 생각했습니다. 설문을 활용해 이런 정보를 선택형으로 수집하는 방법도 검토했습니다. 다만 설문 응답은 사용자가 스스로 표현한 선호이며, 실제 행동의 정답 데이터와는 구분해야 합니다. 선호한다고 답한 조건이 실제 선택으로 이어지는지는 나중에 확인해야 하기 때문입니다.

협업 필터링: 사용자가 많다는 것만으로는 충분하지 않습니다

협업 필터링은 특히 검토해 보고 싶은 방식 중 하나였습니다. 여러 담당자가 비슷한 반장에게 관심을 보이거나 요청하는 패턴이 있다면, 프로필만으로 드러나지 않는 유사한 선호를 활용할 가능성이 있습니다. 이를 위해서는 “어떤 담당자가 어떤 반장과 상호작용했는가”를 연결할 수 있는 이력이 필요합니다.

여기서 사용자 수보다 먼저 생각한 것은 상호작용 행렬의 밀도였습니다. 행을 담당자, 열을 반장이라고 생각하면 초기에는 대부분의 칸이 비어 있을 가능성이 있습니다. 특히 새로운 반장과 새 담당자에게는 이력이 없으며, 서로 같은 대상과 상호작용한 기록이 적다면 비슷한 취향을 추정하기도 어렵습니다.

또한 요청이 발생한 기록은 관심의 신호로 해석할 여지가 있지만, 요청 기록이 없다는 이유만으로 관심이 없었다고 단정할 수는 없습니다. 후보를 한 번도 보지 못했을 수도 있기 때문입니다. 이처럼 협업 필터링에 사용할 행동 데이터를 어떤 의미로 해석할지까지 염두에 두고 수집 항목을 검토했습니다. 실제 적용 여부는 아직 정하지 않았습니다.

지도학습: 하나의 “정답”으로 묶을 수 없는 행동들

로지스틱 회귀나 XGBoost 같은 지도학습 기반 랭킹 모델도 후보로 생각했습니다. 이 경우 공고와 반장의 특징을 Feature로 만들고, 이후 발생한 행동을 Label로 구성할 수 있습니다. 문제는 어떤 행동을 예측해야 하느냐였습니다.

담당자의 요청 여부를 예측하는 경우와, 요청을 받은 반장의 수락 여부를 예측하는 경우는 서로 다른 문제입니다. 요청을 받을 가능성이 높은 사람이라고 해서 수락할 가능성도 높은 것은 아닙니다. 실제 매칭 결과만 보관하면 이 두 단계 가운데 무엇이 영향을 주었는지 구분하기도 어렵습니다.

따라서 지도학습 모델을 미리 하나로 정하기보다 요청, 응답, 최종 결과를 분리해 기록하면 이후 데이터의 분포와 양에 따라 예측 목표를 비교할 수 있다고 판단했습니다. 이것이 모델 후보를 살펴보면서 데이터 수집을 먼저 고민한 이유입니다.

3. 필수 조건은 추천 점수로 다루지 않기로 했습니다

여러 모델을 고민하는 동안 한 가지는 비교적 분명하게 결정할 수 있었습니다. 직종, 최소 경력, 급여처럼 반드시 충족해야 하는 조건은 Ranking 모델에 맡기는 것이 아니라 사전에 Filtering으로 처리해야 한다는 점입니다.

예를 들어 직종이 다르거나 최소 경력을 만족하지 못한 후보는, 다른 특성이 아무리 좋아도 추천 가능한 후보가 아닙니다. 이런 조건을 가중치 점수에 섞으면 다른 요소가 높은 점수를 받아 필수 조건 미충족 후보가 상위에 나타날 수 있습니다. 이는 추천 품질 이전에 서비스의 제약 조건을 지키지 못하는 문제입니다.

그래서 전체 후보에서 필수 조건을 검증해 추천 가능한 집합을 만든 뒤, 남은 후보의 순위를 Ranking에서 결정하는 형태로 역할을 구분했습니다. Filtering은 “추천 가능 여부”를 판단하는 단계이고, Ranking은 “추천 가능한 후보 중 누가 먼저 보일지”를 판단하는 단계입니다.

이 결정은 특정 모델을 선택했다는 뜻이 아닙니다. 협업 필터링이든 속성 기반 방식이든 지도학습 랭킹이든 필수 조건 필터는 동일하게 적용할 수 있습니다. 반대로 필터를 통과했다고 해서 그 후보들의 추천 순위가 자동으로 정해지는 것도 아닙니다.

필수 정보가 누락되어 조건 충족 여부를 판단할 수 없는 경우도 단순히 통과 처리해서는 안 됩니다. 이런 예외를 어떻게 확인하고 처리할지는 실제 필터 구현 단계에서 별도로 정해야 할 검증 기준입니다. 설계 검토 과정에서 모델보다 먼저 도메인의 필수 조건을 고정해야 한다는 점이 명확해졌습니다.

4. 모델을 생각하니 “무엇을 기록할지”가 달라졌습니다

모델 후보를 검토하고 필터링의 역할을 구분한 뒤에는, 데이터 목록을 단순히 늘리기보다 각 데이터가 어떤 질문에 답할 수 있는지 중심으로 생각했습니다. 현재 이 항목들은 실제 수집을 준비하기 위해 검토하고 있는 내용이며, 운영 DB에 모두 반영되었거나 수집이 완료된 것은 아닙니다.

프로필과 설문: Feature가 될 수 있는 정보인가?

직종, 경력, 급여 같은 기본 항목은 필터링에 필요합니다. 향후에는 요구 경력과 실제 경력의 차이, 제시 급여와 희망 급여의 차이 등으로 변환해 모델의 입력값으로 사용할 가능성도 있습니다. 다만 입력에 사용할 수 있다는 것과 실제 예측력이 있다는 것은 다릅니다.

선호 설문도 같은 관점에서 살펴보았습니다. 모든 사용자에게 긴 설문을 요구하기보다, 기본 프로필로 설명하기 어려운 차이를 보완할 수 있는지 먼저 따져보아야 합니다. 한 현장 안에서도 담당자의 역할과 운영 방식이 다를 수 있기 때문에 작업 방식이나 협업 선호가 의미 있는 Feature인지 검토하는 것입니다. 실제로 유효한 정보인지는 데이터가 쌓인 다음 확인해야 합니다.

노출·선택·응답: 같은 행동처럼 저장하면 안 됩니다

행동 데이터에서는 “기록이 없다”는 사실의 의미가 특히 중요했습니다. 어떤 후보가 요청받지 못한 이유는 선호되지 않아서일 수도 있지만, 애초에 추천 목록에 나타나지 않았기 때문일 수도 있습니다. 서버가 목록을 생성했다는 사실과 화면에서 후보가 실제 노출되었다는 사실도 구분해야 합니다.

따라서 최종 요청 여부만 저장하는 대신 추천이 생성된 기록, 후보가 노출된 기록, 요청한 기록, 요청에 대한 응답을 서로 연결할 수 있도록 생각했습니다. 노출 순위도 함께 남겨야 하는데, 같은 후보라도 상단에 보이는지 하단에 보이는지에 따라 선택 기회가 달라질 수 있기 때문입니다.

예를 들어 과거 요청 내역만 보고 “요청하지 않았으니 선호하지 않았다”고 라벨을 붙이면 학습 데이터에 오류가 생길 수 있습니다. 반장이 실제로 요청받지 않은 경우를 “거절했다”로 처리하는 것도 마찬가지입니다. 추후 모델을 학습할 때 음성 사례를 정의하려면, 최소한 무엇이 관찰된 행동이고 무엇이 관찰되지 않은 상태인지 분리할 수 있어야 합니다.

추천 당시의 상태: 나중에 바뀐 값으로 과거를 설명할 수는 없습니다

사용자 프로필이나 모집 조건은 시간이 지나면 달라질 수 있습니다. 현재 저장된 경력이나 희망 급여만으로 몇 주 전의 추천을 분석하면, 당시 실제로 사용했던 값과 다른 값으로 결과를 설명할 위험이 있습니다. 이 때문에 추천 시점에 적용한 조건과 정책을 재현할 수 있는지 역시 검토할 항목에 넣었습니다.

모든 값을 중복 저장할지, 변경 이력을 버전으로 관리할지는 실제 저장 구조에 맞춰 정할 문제입니다. 하지만 어떤 방식을 택하든 추천 시점의 Feature와 이후 발생한 Label을 올바르게 연결할 수 있어야 한다는 원칙은 같습니다. 이 부분은 모델 구조보다 데이터의 의미를 먼저 정리해야 하는 지점이었습니다.

5. 지금 결정한 것과 아직 결정하지 않은 것

현재까지 내린 가장 분명한 결정은 필수 조건을 사전 Filtering으로 분리한다는 것입니다. 직종·경력·급여를 만족하지 않는 후보는 Ranking의 대상이 아니며, 추천 순위를 정하는 알고리즘이 바뀌어도 이 규칙은 유지해야 합니다.

반면 필터를 통과한 후보의 순서를 어떻게 정할지는 아직 확정하지 않았습니다. 속성 기반 추천이 적합할 수도 있고, 충분한 상호작용이 축적되면 협업 필터링을 검토할 수도 있습니다. 실제 요청·수락 사례가 쌓이고 Label의 의미가 확인되면 지도학습 기반 랭킹을 비교할 수도 있습니다. 어느 방법이 적합한지는 실제 데이터를 보기 전에는 단정하기 어렵습니다.

현재는 모델 학습 결과나 성능 개선 수치를 제시할 수 있는 단계가 아닙니다. 데이터 수집을 준비하면서 각 추천 방식에 필요한 정보와 이벤트의 의미를 검토하고 있습니다. 데이터가 들어오기 시작하면 단순 건수부터 세는 것이 아니라, 사용자별 상호작용이 얼마나 겹치는지, 요청과 응답 데이터가 어떻게 분포하는지, 결측이나 노출 편향은 없는지 먼저 확인해야 합니다.

그 분석에 따라 필요한 수집 항목을 조정할 수 있고, 처음 생각한 모델이 적합하지 않다는 결론이 나올 수도 있습니다. 저는 이 가능성을 열어 두는 것이 초기 단계에서는 오히려 중요하다고 생각했습니다. 아직 알 수 없는 것을 임의의 점수나 모델 이름으로 채우기보다, 나중에 판단할 근거를 남기는 구조가 필요했기 때문입니다.

6. 마치며

이번 작업을 시작할 때는 추천 알고리즘을 고르는 문제가 가장 클 것이라고 생각하기 쉽지만, 실제로 먼저 마주한 질문은 데이터였습니다. 현재 어떤 정보가 없고, 그 정보가 없으면 어떤 모델을 평가할 수 없는지부터 따져보았습니다.

그 과정에서 협업 필터링과 지도학습 기반 추천의 가능성을 검토했고, 필수 조건과 Ranking을 분리한다는 설계 결정을 내렸습니다. 또 향후 활용할 수 있는 데이터는 단순히 요청이나 매칭 결과만이 아니라 추천 노출부터 응답까지 의미가 다른 이벤트를 연결한 기록이어야 한다는 점을 확인했습니다.

아직 실제 추천 모델의 성능을 보여줄 결과는 없습니다. 그러나 데이터를 어떻게 기록하느냐에 따라 훗날 비교할 수 있는 모델과 평가할 수 있는 질문이 달라진다는 사실은 설계 단계에서부터 충분히 고려할 수 있었습니다.

데이터가 없는 추천 시스템에서 첫 번째 기술적 선택은, 어떤 모델을 쓸지가 아니라 무엇을 관찰하고 기록할지 정하는 일이었습니다.

Yeon