혼재된 채용 용어를 도메인 모델링으로 정리한 과정

Introduction

• 문제 상황
• 고민했던 상황
• 용어 정리
• 관심사 분리
• 채용 공고 전시
  • 요구사항
  • 모니터 크기 화면에서 채용 공고 크기는 전체 조회수에 비례한다.
  • 모니터 크기 화면에서 채용 공고 순서는 최근 조회 빈도로 결정된다.
• 용어 정리
  • 추가 고민 사항
• 정책 정리 : 사용자 정의 고민
  • 총 두 가지로 고민했다.
• 채용 공고 수집 정리
• 추가 고민 사항
• 필수 정보와 부가 정보

“직군, 직무, 직종”… 채용 공고 데이터를 다루다 보면 자주 마주치는 용어지만, 회사마다 이 의미가 조금씩 달라 일관되게 수집하거나 분류하기가 어려웠다. 혼재된 개념들로 인해 공고 수집 기준이 불명확해졌고, 어떤 공고는 수집되고 어떤 공고는 누락되는 일이 반복되었다.

• 이 문제를 해결하기 위해 ‘도메인 모델링’ 관점에서 용어를 명확히 정의하고, 수집과 전시 기준을 나누는 구조를 설계했다.

문제 상황

• 어떤 공고는 ‘프론트엔드 개발자’로만 적혀 있다.
• 어떤 공고는 ‘개발 직무’만 표기되어 있다.
• 일부 공고는 ‘소프트웨어 엔지니어’와 같은 포괄적인 명칭만 적혀 있었다.

직군 / 직무 / 직종 개념이 혼재되어 있었고, 명확한 기준 없이 수집하면 전시 기준도 불명확해지는 상황이었다.

고민했던 상황

• 일부 채용 공고는 너무 간단한 문구만 있어 유의미한 정보를 추출하기 어려웠다.
• 반대로 어떤 공고는 정보가 너무 많아 정제하는 데 오히려 혼선이 생겼다.

‘이 공고는 수집해야 하나?’ 라는 판단 기준을 명확히 하지 않으면, 사용자가 원하는 정보를 놓치거나 불필요한 정보까지 모두 노출되는 문제가 발생할 수 있었다.

이런 문제를 해결하기 위해 도메인 모델에서 ‘채용공고’, ‘직무’, ‘직종’을 명확히 나누고, 각 기준에 따라 수집 조건을 다르게 설정했다.

용어 정리

• 직업 , 채용 공고, 채용 공고 리스트, 직군 등 단어에 내제된 의미를 서로 다르게 해석해서 정리하는 시간을 가졌다.

해당 블로그 정보를 참고해서 필요한 정보만 추출했다

관심사 분리

노출 방법과 수집 방법 사이 경계를 만들고 각자 역할에 집중할 수 있도록 관리 영역을 분리했다.

• 채용 공고 전시 : 채용 공고를 노출하는 입장에서는 채용 공고 데이터 노출 방식을 고민한다.
• 채용 공고 수집 : 채용 공고를 수집하는 입장에서는 채용 공고 정보가 정확한지 검증한다.

관심사에 따라 상태를 분리하면 채용 공고 전시 영역은 채용 공고(job) 이벤트만 관심있고, 채용 공고 수집 영역은 수집된 채용 공고(crawledJob) 이벤트만 관심있다.

• 채용 공고 전시 영역에서 채용 공고는 노출 대상일 뿐이고 채용 공고 상태가 열렸는지 닫혔는지만 중요하다.
• 채용 공고 수집 영역에서 채용 공고는 수집 대상이며 채용 공고 상태가 검증 대기중인지, 수정됐는지 검증됐는지, 반려됐는지가 중요하다.

채용 공고 전시

요구사항

• 모니터 크기 화면에서 렌더링 되는 경우 다음처럼 동작한다.
  • 전체 조회수에 비례해 채용 공고 크기가 결정된다.
  • 최근 조회 빈도로 채용 공고 순서가 결정된다.
• 앱 크기 화면에서 렌더링 되는 경우 다음처럼 동작한다.
  • 전체 조회수에 비례해 채용 공고 순서가 결정된다.
  • 최근 조회 빈도로 🔥 표시가 결정된다.

모니터 크기 화면에서 채용 공고 크기는 전체 조회수에 비례한다.

• 요구사항
  • 클릭 수가 늘어날 때마다 기본 사이즈에서 점차 커져야 한다.
  • 사이즈 변화는 2 제곱 형태로 늘어난다.
  • 사이즈 변화할 때 이전에 가로가 두 배 늘어나면 다음에는 세로가 두 배 늘어난다. ( 번갈아가면서 늘어난다.)
  • 최대 크기는 지면 가로 크기의 1/4 까지다. 최소 크기는 지면 가로 크기의 1/32이다.
• 비기능 요구사항
  • 클릭 수에 비례한다면 요청 수가 급증할 경우 대응하기 어려워질 수 있다. 1 → 10건으로 늘어날때는 대비되게 1,000 → 10,000 건으로 늘어날 때는 큰 차이를 느끼지 못하도록 한다.

모니터 크기 화면에서 채용 공고 순서는 최근 조회 빈도로 결정된다.

• 요구사항
  • 우선 순위는 다음처럼 결정한다.
  • 5분 간 가장 많이 클릭한 채용 공고 순으로 나열한다.
  • 빈 공간이 생기지 않도록 나열한다. 빈 공간이 생겼을 경우 우선 순위가 낮지만 빈 공간을 채울 수 있는 공고를 우선 배치한다. (맞는 공고를 꺼내올 때 그 중 우선 순위가 높아야 한다.)
  • 빈 공간이 생겼을 때 지면 크기 1/32 * 1/32 정도의 공간은 무시해도 된다.
  • 배치 방법은 다음처럼 결정한다.
  • 좌측 상단 부터 우선 순위가 높은 순으로 나열한다.
  • 우선 순위 기준으로 우측으로 나열한다.
• 비기능 요구사항
  • 트래픽 기준으로 변경 빈도율을 고민해볼 필요가 있다. 사용자가 많이 몰린다면 자주 변경되는 일이 사용자와 인터렉션을 높이는 일인지 고민해야 한다.
  • 공백이 생길까 우려 된다. 다음과 같은 상황에서 공백을 메꿀 수 있도록 구현해야 한다.

용어 정리

추가 고민 사항

• 사용자 단위 고민
• IP를 활용한 위치 인식
• 채용 공고 정렬 방식에 대한 고민

정책 정리 : 사용자 정의 고민

우리는 사용자 행동을 이벤트로 기록하고 있다. 사용자 행동 관측해 다각도의 분석 모델을 구현하기 위해서이다. 다각도의 분석 모델을 개발 시점에서 해석하자면 사용 방법을 예측할 수 없는 상황이다. 사용 방법을 예측할 수 없으니 사용자를 어떻게 해석할지도 어려운 상황이다.

우리는 인증을 제공하지 않기 때문에 회원 정보를 기록하는 서비스와 달리 사용자를 정의하기 어려웠다.

총 두 가지로 고민했다.

• 페이지를 유지하는 동안 : 페이지를 유지하는 동안을 동일한 사용자로 볼지
• 세션을 유지하는 동안 : 세션을 유지하는 동안을 동일한 사용자로 볼지

사용 방법을 예측한 분석 방식과 개발 과정을 분석했다.

• 예측한 분석 방식
  • 페이지 유지하는 동안 : 사용자가 랜딩 페이지에 접근할 때마다 채용 공고를 몇 회 클릭하는지
  • 세션을 유지하는 동안 : 사용자가 랜딩 페이지에 접근하는 빈도가 몇 회인지
• 개발 방식
  • 페이지 유지하는 동안 : 랜딩 페이지 조회할 때마다 새로운 키를 발급하면 되서 간단하다.
  • 세션을 유지하는 동안 : 랜딩 페이지 조회할 때마다 세션 키에 대한 이전 정보가 존재하는지 조회해야 해서 복잡하다.

채용 공고 수집 정리

추가 고민 사항

• 사용자와 유대감을 높이기 위한 방법 : 필수 정보와 부가 정보
• 데이터 검증 파이프라인 구현

필수 정보와 부가 정보

채용 공고 데이터 정형화는 리소스 소모가 많았고 제공할 데이터를 제한해야 했다.

정보 조회 편의성을 높여 사용자와의 유대감을 높이기로 했고 최대한 많은 정보 노출을 목표한다.

다른 채용 공고 페이지는 많은 정보를 노출하기 위해 어떤 고민을 했는지 분석한다.

채용 공고를 수집할 때 의미 있다고 생각하는 정보를 함께 수집해 최대한 많은 정보를 수집하기로 했다.

그리고 필수 요소와 부가 요소로 구분했다.

• 필수 요소 : 화면 렌더링에 필요한 정보
• 부가 요소 : 화면 렌더링에 필요하지 않은 정보이며 의미있다고 생각하는 정보

부가 요소는 태그처럼 나열된다. 사용자는 채용 공고를 들어가지 않아도 해당 페이지에서 필요한 정보를 파악할 수 있도록 구성했다.

검증 전 채용 공고는 다음 케이스로 분류되어 작업이 진행된다.

• 이전 수집 정보가 존재하지 않은 경우 : 채용 공고 새로 추가된 경우
• 새로 수집된 정보가 존재하지 않은 경우 : 채용 공고 내려간 경우
• 새로 수집된 정보와 이전 수집 정보과 다른 경우 : 채용 공고 수정된 경우
• 새로 수집된 정보와 이전 수집 정보가 같은 경우 : 채용 공고 유지되는 경우