모아 둔 공고를 지원할 수 있는 사람에게 전달하기
나루는 일본 취업을 준비하는 한국인을 위해 채용공고·기업·이벤트·멘토링을 모은 서비스입니다. 저는 팀의 기존 서비스에 참여해 채용 유형 분류, 회원 조건에 따른 공고 매칭, 이메일 발송과 운영 화면을 구현했습니다.
공고가 모여 있어도 지원할 수 없는 공고나 같은 공고를 반복해 보내면 알림의 가치가 떨어집니다. 수집한 정보의 근거부터 매칭 판단, 발송 기록까지 이어지는 흐름이 필요했습니다.
서비스 공개 중
NARU
일본 채용 정보를 지원 조건에 맞는 사람에게 전달하는 취업 플랫폼입니다.
팀의 기존 서비스에서 원문 근거에 따른 채용 유형 분류, Spring Boot 회원 조건 매칭, 동의와 이력을 관리하는 이메일 발송을 맡았습니다.
결과공개 서비스 · 공고 분류·매칭·발송 이력 구현
원문에 없는 지원 조건은 추정하지 않았습니다
일본 공고는 신졸(졸업 예정자), 제2신졸(졸업 후 초기 경력자), 경력 채용을 구분합니다. 저는 수집한 원문의 명시적 표현으로 이를 판단하는 Python 분류기를 구현하고, 판단마다 원문 필드·일치 문구·출처 URL을 남겼습니다.
‘28卒’는 2028년 졸업 기수의 근거가 되지만 ‘2028년 4월 입사’만으로 기수를 추정하지 않습니다. 이미 졸업한 사람을 뜻하는 ‘기졸’도 제2신졸로 자동 분류하지 않았습니다. 근거가 없으면 미확인, 충돌하면 모호한 상태로 남기고 이런 경계 조건을 테스트로 확인했습니다.
발송 전에 후보와 매칭 근거를 확인했습니다
Spring Boot에서 회원의 채용 유형·졸업 기수·관심 직무와 공고 조건을 비교하고, 메일을 보내지 않고 후보와 매칭 근거를 확인하는 사전 검증(dry-run)을 구현했습니다. 이메일에서도 같은 매칭 로직을 사용해 웹과 메일의 기준이 달라지지 않도록 했습니다.
새로 게시된 공고 중 최대 5개를 고르고, 이전 이메일에 포함한 공고는 발송 기록으로 제외합니다. 보낼 공고가 없으면 메일을 만들지 않으며, 미리보기는 DB 변경이나 외부 발송 호출 없이 확인할 수 있습니다.
발송 API 호출 뒤에도 관리할 상태가 남았습니다
기존 인앱 알림 설정을 이메일 동의로 간주하지 않고, 주제별 명시적 동의를 별도로 관리했습니다. 같은 발송 작업·회원·주제의 중복은 DB 유니크 제약으로 막고, 발송 업체의 멱등키도 함께 사용했습니다.
서명을 검증한 웹훅으로 전달·반송·신고를 기록하고 이후 발송 차단에 반영합니다. 운영 화면에서는 발송 스위치, 이력, 실패 건 재시도를 확인할 수 있으며, 환경 설정과 DB 양쪽이 허용하기 전에는 실제 발송되지 않도록 구성했습니다.
담당 기능의 코드와 분류·매칭·발송 조건을 확인하는 테스트, 운영 화면을 구현했습니다. 서비스는 공개되어 있습니다.
데이터를 가져오는 것뿐 아니라 불명확한 조건을 어떻게 남길지, 누구에게 보낼 수 있는지, 무엇을 보냈는지, 실패 후 어떻게 재시도할지까지 설계하게 되었습니다.
아직 검증하지 않은 범위
전체 회원 대상 자동 발송의 운영 상태와 메일 도달률·지원 전환 효과는 아직 확인하지 않았습니다.