1. 배경: 같은 뜻을 다른 말로 쓰는 두 문서
프리딕션에서 상상우리를 대상으로, 이력서와 채용 공고를 분석해 직무와 인재를 연결하는 추천 시스템을 만든 프로젝트입니다.
문제 정의는 단순해 보였습니다. 공고가 요구하는 것과 지원자가 가진 것을 비교해서 잘 맞는 순서로 보여주면 됩니다.
실제로 데이터를 보고 나서 이것이 왜 어려운지 알았습니다.
2. 문제 정의: 동일 역량의 상이한 표현
이력서와 공고를 나란히 놓고 보면, 같은 역량을 서로 다른 단어로 기술하는 경우가 압도적으로 많았습니다.
공고는 조직의 언어로 쓰입니다. 직무를 정의하고 요구 조건을 나열하는 방식입니다. 이력서는 개인의 언어로 쓰입니다. 자기가 한 일을 경험 중심으로 서술합니다. 같은 능력을 가리키면서도 표현이 완전히 다릅니다.
- 공고: "데이터 기반 의사결정 지원 경험"
- 이력서: "로그 분석해서 지표 만들고 개선안 제안"
사람이 읽으면 같은 이야기입니다. 키워드 매칭은 공통 단어가 거의 없다고 판단합니다.
처음에 만든 TF-IDF 기반 베이스라인이 정확히 이 지점에서 무너졌습니다. 단어 빈도로 벡터를 만들고 유사도를 계산하는 방식이라, 표현이 다르면 아무리 같은 뜻이어도 점수가 나오지 않았습니다.
반대 방향의 오류도 있었습니다. 흔한 단어가 우연히 겹쳐서 관련 없는 공고가 상위에 올라오는 경우입니다. "관리", "운영", "개발" 같은 말은 거의 모든 문서에 있습니다.
3. 기술적 난점
용어가 표준화되어 있지 않습니다. 같은 직무를 회사마다 다르게 부르고, 같은 기술을 축약어로 쓰기도 정식 명칭으로 쓰기도 합니다.
문서의 길이와 구조가 제각각입니다. 어떤 이력서는 한 장이고 어떤 것은 열 장입니다. TF-IDF는 문서 길이에 민감해서, 짧은 문서와 긴 문서를 공정하게 비교하기 어려웠습니다.
정답이 없습니다. "이 지원자와 이 공고가 얼마나 맞는가"에 대한 라벨이 없었습니다. 그러니 모델을 평가할 기준부터 만들어야 했습니다.
4. 대안 검토
1안. 동의어 사전을 만든다
같은 뜻의 표현을 목록으로 관리해 매칭 시 확장합니다.
- 장점: 통제 가능하고 결과를 설명하기 쉽습니다.
- 단점: 끝이 없습니다. 새로운 표현이 계속 나오고, 사전을 유지하는 것 자체가 일이 됩니다. 그리고 문맥에 따라 같은 말이 다른 뜻인 경우를 처리하지 못합니다.
2안. 임베딩 기반 의미 매칭으로 전환합니다
텍스트를 의미 공간의 벡터로 바꿔서, 표현이 달라도 의미가 가까우면 가깝게 놓이도록 합니다.
- 장점: 표현 불일치를 근본적으로 다룹니다. 사전 관리가 필요 없습니다.
- 단점: 왜 그렇게 매칭됐는지 설명하기 어렵고, 도메인에 맞는 임베딩이 필요합니다.
3안. 규칙 기반으로 항목을 구조화한 뒤 비교합니다
이력서와 공고에서 항목을 추출해 정형화한 뒤 비교합니다.
- 장점: 정확하고 설명 가능합니다.
- 단점: 비정형 텍스트에서 항목을 추출하는 것 자체가 더 어려운 문제입니다. 문제를 옮긴 것에 가깝습니다.
5. 설계 결정 및 근거
2안으로 갔습니다. 다만 TF-IDF를 버린 게 아니라 베이스라인으로 남겨두고 그 위에 올렸습니다.
이 순서가 중요했습니다. TF-IDF를 먼저 만들었기 때문에 무엇이 안 되는지 구체적으로 알 수 있었습니다. 실패 사례를 모아보니 대부분이 "표현이 다른데 뜻이 같은" 경우였고, 그것이 임베딩으로 전환할 근거가 됐습니다. 베이스라인이 없었다면 "느낌상 별로다" 수준에서 그쳤을 것입니다. 그리고 개선 후에도 비교 대상이 있어서 나아졌는지 판단할 수 있었습니다.
동일 벡터 공간으로의 매핑
기술적으로 가장 중요했던 부분은 이력서와 공고를 동일한 벡터 공간에 매핑하는 것이었습니다.
두 문서는 문체도 길이도 목적도 다릅니다. 각각 따로 처리하면 비교 자체가 성립하지 않습니다. 이에 따라 전처리 단계에서 표기를 정규화하고, 문서 성격에서 오는 편차를 줄여 같은 기준으로 벡터화되도록 만들었습니다.
여기에 자체 개발한 임베딩(PRE2VEC)을 적용했습니다. 범용 임베딩은 일반적인 의미는 잘 잡지만, 이 도메인의 미묘한 차이는 놓치는 부분이 있었습니다. 도메인 데이터로 학습한 임베딩을 쓰니 단어 빈도가 아니라 문맥과 의미를 기준으로 적합도를 판별할 수 있게 됐습니다.
응답 페이로드의 정형화
추천 엔진을 FastAPI 기반 REST API로 만들면서 신경 쓴 부분이 있습니다. 점수만 던지지 않는 것입니다.
유사도 점수 하나만 주면 받는 쪽에서 할 수 있는 게 없습니다. 이에 따라 상위 매칭 목록과 점수를 함께 정형화된 구조로 직렬화해서 반환했습니다. 클라이언트가 추가 가공 없이 화면에 바로 쓸 수 있게 한 것입니다.
피드백 기반 가중치 조정
정답 라벨이 없다는 문제는 사용자 반응을 정답 대신 쓰는 방식으로 접근했습니다.
추천 결과에 사용자가 어떻게 반응하는지를 수집하고, 그 데이터로 유사도 계산의 가중치를 조정하는 루프를 만들었습니다. 처음부터 완벽한 가중치를 찾으려 하지 않고, 데이터가 쌓일수록 나아지는 구조를 만드는 쪽을 택했습니다.
6. 결과
6.1 무엇이 달라졌는가
| 항목 | 베이스라인 (TF-IDF) | 임베딩 매칭 |
|---|---|---|
| 동일 어휘 매칭 | 성립 | 성립 |
| 표현이 다른 동일 역량 | 매칭 실패 | 의미 기준으로 연결 |
| 판정 근거 | 어휘 일치 여부 | 벡터 유사도 점수 |
| 개선 경로 | 불용어·가중치 수작업 | 피드백 기반 가중치 조정 |
베이스라인을 먼저 만들어 둔 덕분에 전환 근거를 실패 사례로 제시할 수 있었습니다. TF-IDF가 놓친 건을 모으니 대부분이 표현만 다르고 뜻이 같은 경우였고, 이 분포가 임베딩 전환의 판단 근거가 되었습니다.
6.2 검증하지 않은 부분
정량 지표(정확도·재현율)는 측정하지 않았습니다. 매칭 정답 집합을 구축하지 않은 상태에서 진행한 프로젝트이며, 평가는 담당자가 결과 목록을 검토하는 정성 방식으로만 이루어졌습니다.
같은 작업을 다시 한다면 소규모라도 정답 집합을 먼저 만들 것입니다. 정답 집합이 없으면 개선 여부를 주장할 근거가 사후에 생기지 않습니다.
6.3 이후
이 매칭 알고리즘은 외부 기업과의 공급 계약으로 이어졌습니다.
7. 결론 및 시사점
베이스라인은 폐기 대상이 아니라 판단 근거입니다. TF-IDF는 결국 교체됐지만, 이를 만든 시간이 낭비가 아니었습니다. 무엇이 왜 안 되는지 구체적으로 아는 것이 다음 선택의 근거가 됐고, 개선 폭을 측정하는 기준이 됐습니다. 처음부터 좋아 보이는 방법으로 직행했다면 그게 실제로 나은지 말할 수 없었을 것입니다.
매칭 문제는 대체로 "같은 공간에 놓는" 문제입니다. 이력서와 공고, 질문과 문서, 사용자와 상품처럼 성격이 다른 두 대상을 비교할 때, 어려움은 비교 자체가 아니라 비교 가능한 형태로 만드는 데 있었습니다. 이후 검색이나 추천 문제를 볼 때 "이 둘이 정말 같은 기준으로 표현되고 있나"를 먼저 확인하게 됐습니다.
정답이 없으면 정답을 만들어가는 구조를 설계합니다. 라벨이 없다고 멈추는 대신, 사용자 반응을 신호로 삼아 점점 나아지는 루프를 만들었습니다. 처음에 완벽할 필요는 없고, 나아지는 방향이 보장되면 됩니다. 이 관점은 이후 다른 프로젝트에서도 계속 쓰고 있습니다.