사람인 API 승인이 늦을 때 채용공고 서비스를 만드는 방법

채용공고 서비스를 만들기로 했는데 데이터 접근 승인이 늦어지면 화면 개발도 멈춰야 할까. 클코단에서는 공모전 출품작에 사람인 API를 쓰려는 개발자가 답을 기다리며 다른 경로를 고민했다. 승인 여부가 불확실할 때 무엇을 확인하고, 시제품은 어떤 데이터로 만들 수 있는지가 이 기사의 질문이다.

승인 요청에 답이 없다면 신청 상태부터 확인해야 한다

사람인 공식 안내에 따르면 채용정보 API는 이용신청과 승인 후에 쓸 수 있다. 승인 메일을 받은 다음 로그인해 앱을 등록하고 access-key를 확인하는 순서다. 신청 화면에는 API를 사용할 URL과 50자 이상의 이용목적을 적는 항목도 있다.

공개 안내에서 승인 소요 기간이나 무응답의 의미는 확인되지 않는다. 답이 늦다는 사실만으로 심사 중인지 거절됐는지 단정할 수 없다. (oapi.saramin.co.kr)

방에서는 바로 그 상태를 알 수 없다는 점이 개발 일정의 걸림돌로 거론됐다. 신청 내용을 다시 확인하고 공식 안내에 나온 API 문의처로 상태를 물을 수는 있다. 다만 문의가 승인이나 특정 답변 시점을 보장하지는 않는다. 시제품의 데이터 연결을 승인 결과 하나에만 걸어두면 기다리는 시간만큼 핵심 기능을 시험할 기회도 줄어든다. (oapi.saramin.co.kr)

승인 뒤에는 어떤 공고를 어떻게 가져올 수 있나

사람인 Job Search API는 GET /job-search로 등록된 채용정보를 검색한다. 발급받은 access-key가 필수이고 Accept 헤더로 JSON 또는 XML 응답을 선택한다. 검색어에는 기업명·공고명·직무내용 등을 넣을 수 있다. 지역과 직무 조건도 제공한다. 응답에는 공고 번호·표준 URL·진행 여부·게시 시각·마감 시각 등이 담긴다. 공식 사용안내에는 하루 최대 500회 호출이라고 적혀 있다. (oapi.saramin.co.kr)

공모전용 검색 화면은 승인 전에도 응답 형식을 기준으로 설계할 수 있다. 예를 들어 사용자가 지역과 직무를 고르면 목록을 요청한다. 결과의 제목·기업·마감 상태는 카드로 보여주고, 카드를 누르면 응답의 표준 URL에서 원래 공고를 확인하게 한다. 아직 키가 없다면 실제 조회가 성공했다고 꾸미지 말고 임시 예시 데이터로 화면 동작만 시험해야 한다. (oapi.saramin.co.kr)

데이터를 얻는 것과 원하는 사업 방식으로 쓰는 것은 별개다. 사람인 이용자 주의사항은 API 기반 서비스의 재판매와 이용요금 부과를 금지한다. 공모전 시연 이후 유료 기능까지 생각한다면 기능 구현보다 앞서 이용 조건이 사업 구상과 맞는지 확인해야 한다. (oapi.saramin.co.kr)

고용24는 대안이지만 승인 절차까지 없애주지는 않는다

방에서는 정부24 쪽 데이터로 개인 대상 공고를 충분히 제공하기 어렵다는 우려가 나왔다. 그 경험을 모든 공공 채용 API의 제한으로 넓혀 해석할 필요는 없다. 한국고용정보원의 고용24는 별도의 채용정보 API를 공개하며 공고 목록과 상세 조회를 제공한다. 목록 요청 예시에는 authKey, callTp=L, returnType=XML, startPage, display가 들어간다. 지역·직종·키워드도 검색 조건으로 쓸 수 있다. (work24.go.kr)

문제는 접근 조건이다. 고용24 안내는 오픈 API를 기업회원 전용으로 설명한다. 회원가입 후 인증키를 신청하고 담당자 심사를 거쳐야 한다. 사람인 승인을 기다리는 개인 개발자라면 고용24를 즉시 발급되는 대체 키로 가정해서는 안 된다. 신청 자격을 충족하는 팀이라면 두 API의 절차를 나란히 진행할 수 있다. (work24.go.kr)

두 서비스를 동시에 검토한다면 응답 형식 차이도 구현에 반영해야 한다. 사람인은 JSON과 XML을 선택할 수 있지만 고용24 채용정보 목록 명세는 XML을 요구한다. 내부에서는 출처·원본 공고 번호·제목·지역·마감 상태·원문 URL을 같은 필드로 변환할 수 있다. 화면은 변환된 목록을 읽게 하고 데이터 제공처별 요청과 해석은 분리하는 방식이다. 이 구조라면 한쪽 승인 결과가 늦어져도 검색 화면 전체를 다시 만들 필요가 없다. (oapi.saramin.co.kr)

직접 수집은 쉬운 우회로가 아니라 별도 운영 방식이다

방에서는 API를 받지 못하면 공고를 직접 모으자는 의견도 나왔다. 실시간 공고를 공유하는 채팅방 역시 정보 탐색에 도움이 된다는 제안이었다. 하지만 공유된 링크나 웹페이지에서 공고를 봤다는 사실만으로 그 내용을 서비스에 자동 수집·재게시할 권한까지 확보되지는 않는다. 수집 대상과 이용 조건을 확인하지 못했다면 이를 승인된 데이터 소스로 취급하면 안 된다.

직접 수집을 선택한 뒤에는 가져오는 일보다 현재도 지원 가능한 공고인지 확인하는 일이 중요해진다. 써본 사람들 사이에서도 원문 사이트마다 구조가 다르고 중복이나 마감 공고를 정리하는 일이 번거롭다는 반응이 있다. 개별 경험을 모든 사이트의 사정으로 일반화할 수는 없다. 다만 원문 URL과 출처별 공고 번호를 보관하고 표시 직전에 마감 상태를 재확인해야 한다는 설계 과제는 분명하다.

검색 노출까지 계획한다면 오래된 공고를 방치할 수도 없다. Google 검색 센터는 종료된 채용공고의 JobPosting 구조화 데이터를 제거하거나 validThrough를 지난 시각으로 설정하는 방법을 안내한다. 공고를 많이 확보하는 능력과 유효한 공고만 보여주는 능력은 다른 문제다. (developers.google.com)

공모전 시제품은 데이터 경로를 바꿔도 작동해야 한다

Claude Code로 이 시제품을 만든다면 작업 요청도 작게 나눌 수 있다. 먼저 출처별 공고를 공통 목록으로 바꿀 필드를 정하고 임시 예시 데이터로 검색·상세 이동·마감 표시를 구현한다. 다음에는 승인받은 API의 공식 명세에 맞춰 요청과 응답 변환을 붙인다. 사람인 키가 발급되면 JSON 응답을, 고용24 이용 자격과 키가 확보되면 XML 응답을 각각 연결하는 순서다. (oapi.saramin.co.kr)

입력은 검색 조건과 출처별 응답이고 산출물은 출처가 표시된 공고 목록이다. 테스트에는 같은 공고의 중복 표시, 마감 공고의 잔존, 원문 링크 오류를 넣는다. 이 순서는 API 승인을 받았다고 가정해 결과물을 시연하는 것과 다르다. 승인 전에는 검색 경험을 검증하고 승인 후에는 실제 공고가 그 경험을 지탱하는지 검증한다.

사람인과 고용24 모두 신청과 심사가 필요하다. 다른 API를 찾는 것만으로 대기 문제가 사라지지는 않는다. 공모전 서비스의 성패를 가를 질문은 어느 한 곳의 키를 먼저 받느냐보다 구체적이다. 데이터 출처가 달라져도 사용자가 지금 지원할 수 있는 공고를 정확히 찾을 수 있는가. (oapi.saramin.co.kr)