이 글의 순서
핵심 내용
구인구직 앱은 공고를 보여주는 범위와, 지원서를 접수해 기업이 확인하는 범위에 따라 필요한 화면과 개발 작업이 달라집니다. 앱 안에서 입사 지원을 받으려면 구직자의 지원 화면뿐 아니라 기업의 지원자 목록·상세, 지원 상태를 저장하고 전달하는 기능까지 함께 정해야 합니다.
첫 의뢰에서는 ‘채용 앱을 만들어 주세요’보다 누가 공고를 올리고, 어디에서 지원하며, 누가 지원서를 확인하는지를 먼저 정리하는 편이 좋습니다. 이 글에서는 공고 열람형·앱 내 지원형·기업 검토형을 비교하고, 공고 한 건에 들어온 지원서가 양쪽 화면에서 어떻게 연결되어야 하는지 살펴봅니다.
공고를 보는 앱과 지원을 받는 앱의 견적 범위는 다릅니다
세 범위는 상담을 위한 구분입니다. 앱 내 지원형은 공고 열람에 접수·내역 조회를 더하고, 기업 검토형은 기업 담당자의 처리 화면까지 더합니다. 모든 서비스가 세 번째 범위까지 한꺼번에 개발할 필요는 없습니다. 기존 채용 사이트에서 지원을 받을 수도 있고, 플랫폼 직원이 기업을 대신해 지원서를 확인하는 방식도 가능합니다.
| 확인할 항목 | 공고 열람형 | 앱 내 지원형 | 기업 검토형 |
|---|---|---|---|
| 구직자의 행동 | 공고 검색·상세 확인 후 정해진 외부 경로로 지원 | 앱에 이력서·지원서를 제출하고 내 지원 내역 확인 | 내 지원 내역에서 기업이 전달한 검토 상태 확인 |
| 공고를 올리는 사람 | 플랫폼 직원 또는 승인된 기업 담당자 중 선택 | 같은 등록 주체에 앱 내 접수 설정 추가 | 기업 담당자의 공고 작성·수정·마감 권한 설정 |
| 지원서가 모이는 곳 | 외부 지원 페이지나 기존 접수 경로 | 앱 서버의 지원 목록·상세와 접수 담당자 화면 | 지원한 기업의 담당자용 목록·상세 |
| 기업 담당자 화면 | 앱 밖의 기존 업무 도구를 쓸 수 있음 | 접수 담당자에게 필요한 조회·파일 확인 범위 결정 | 지원서 열람·검토 상태 변경·결과 전달 범위 결정 |
| 견적에서 확인할 작업 | 검색 조건·공고 공개·마감·외부 이동 | 이력서 입력/첨부·제출·저장·내역 조회 | 기업별 접근 권한·처리 기록·구직자에게 보일 상태 |
‘지원하기’ 버튼이 외부 사이트를 여는지, 앱 안에 지원서를 저장하는지부터 다릅니다. 앱 안에서 접수한다면 지원자가 제출을 마쳤다고 확인할 화면과, 담당자가 실제로 접수 내용을 읽는 화면이 모두 필요합니다.
기업 담당자 기능도 별도 앱으로만 만들 필요는 없습니다. 구직자는 모바일 앱을 쓰고 기업은 PC 웹 화면을 쓰는 구성이 가능합니다. 첫 견적에서는 ‘앱 두 개’라고 먼저 고정하기보다 각 역할이 사용할 기기와 업무를 전달하세요.
같은 공고·지원서가 구직자와 기업 화면에서 이어져야 합니다
공고를 읽고 지원한 뒤 ‘접수 완료’ 안내만 보이면, 구직자는 나중에 무엇을 냈는지 확인하기 어렵습니다. 기업도 공고 제목만 있는 목록으로는 여러 지원서를 구분하기 어렵습니다. 공고 번호와 지원 번호를 기준으로 같은 기록을 연결하는 흐름이 필요합니다.
예를 들어 ‘온라인몰 운영 담당자’ 공고 J-101에 지원 A-101이 접수됐다고 정해봅시다. 구직자의 내 지원 내역에는 공고명·제출한 이력서·접수 상태가 보입니다. 기업 담당자는 해당 공고의 지원자 목록에서 같은 A-101을 열어 지원 내용을 확인합니다.
이후 담당자가 ‘검토 중’으로 변경하면 서버가 처리 상태를 저장하고, 구직자가 내 지원 내역을 다시 열었을 때 바뀐 상태를 보여주는 식입니다. ‘접수 완료’는 지원서가 저장됐다는 뜻이고, ‘검토 중’은 담당자가 정한 검토 단계입니다. 파일을 열었다는 사실만으로 검토 완료나 채용 확정으로 바꾸지 않도록 구분해야 합니다.
알림도 따로 정합니다. 상태를 앱의 내 지원 내역에 표시하는 범위와 푸시·이메일까지 발송하는 범위는 같지 않습니다. ‘결과 안내 포함’이라고만 적지 말고 어떤 상태 변경을 어느 채널로 전달할지 견적에서 확인하세요.
이력서 양식과 제출 후 수정 기준을 먼저 정하세요
구직자가 앱에서 경력·학력 등을 직접 입력하는 방식과, 가지고 있는 이력서 파일을 첨부하는 방식은 필요한 화면과 처리가 다릅니다. 두 가지를 모두 제공하면 편리할 수 있지만 양쪽 입력·첨부·조회 흐름이 개발 범위에 들어갑니다.
파일 첨부를 선택한다면 허용할 파일 형식·크기와 기업 담당자가 확인할 방법도 정해야 합니다. 단순 다운로드와 앱 안의 문서 미리보기는 별도 작업입니다. 파일을 올리고 내려받을 때 접근 권한과 파일 조건을 확인하는 설계도 필요합니다. 파일 업로드의 기본 보호 항목은 OWASP 자료에서도 확인할 수 있습니다.
제출한 지원서를 나중에 어떻게 다룰지도 중요합니다. 공통 이력서를 수정했을 때 이전 지원서까지 바뀌는지, 지원 당시 내용을 보존하는지에 따라 기업이 읽는 자료가 달라집니다. 지원 당시 내용을 보존하고, 이후 수정은 다음 지원부터 반영하는 방식을 첫 검토안으로 삼을 수 있습니다. 이미 접수한 지원서의 교체를 허용한다면 기업이 어느 버전을 읽었는지도 함께 정해야 합니다.
같은 공고에 다시 지원할 수 있는지, 지원을 취소하면 기업 화면에 무엇이 남는지, 마감 직전 접수 중에 공고가 닫히면 어떻게 안내할지도 짧은 예로 전달하세요. 이 조건들이 실제 접수·조회 화면의 기준이 됩니다.
기업별로 지원서를 볼 수 있는 범위를 나눠야 합니다
기업이 직접 가입하는 서비스라면 계정을 만들었다는 사실과 공고를 공개할 수 있다는 권한을 구분할 수 있습니다. 기업 확인 후 공고 작성을 허용할지, 작성은 가능하되 플랫폼 직원이 공개를 승인할지 정하세요. 확인 절차에 필요한 정보와 담당자도 함께 전달하는 편이 좋습니다.
지원서는 해당 기업의 지정된 담당자가 읽도록 범위를 정합니다. 한 기업에 담당자가 여러 명이라면 전체 공고를 함께 볼지, 맡은 공고만 볼지 결정해야 합니다. 다른 기업의 지원서를 주소나 번호만 바꿔 열 수 없도록 서버에서 각 요청의 권한을 검사해야 합니다. 요청마다 권한을 확인하는 원칙은 OWASP 권한 관리 지침을 참고할 수 있습니다.
구직자 역시 자신의 지원 내역만 조회하도록 합니다. 플랫폼 운영자가 문의 대응을 위해 열람할 범위, 파일 보관·삭제 조건과 기업 담당자 퇴사 시 접근 해제도 별도로 정리하세요. 구체적인 개인정보 처리·채용 운영 기준은 서비스 운영 방식에 맞춰 검토할 항목입니다.
첫 견적에서는 공고 한 건과 지원 한 건으로 확인해보세요
처음부터 추천·채팅·영상 면접·기업 유료 상품을 모두 넣기보다, 시작할 접수 흐름을 한 문장으로 정리하세요. ‘플랫폼 직원이 공고를 등록하고, 구직자는 파일 이력서로 지원하며, 기업 담당자는 PC에서 지원서를 확인한다’처럼 역할과 기기를 함께 쓰면 개발 범위를 비교하기 쉽습니다.
| 구분 | 첫 범위에서 정할 항목 | 필요할 때 추가로 검토할 항목 |
|---|---|---|
| 공고 | 등록 주체·검색 조건·공개/마감 기준 | 유료 공고·상단 노출·외부 채용 시스템 연동 |
| 지원 | 앱 내 접수 여부·이력서 방식·취소/중복 기준 | 복수 이력서·포트폴리오 관리·지원서 버전 교체 |
| 기업 | 지원 목록·상세·검토 상태·담당자 권한 | 담당자별 배정·면접 일정·지원자와 채팅 |
| 안내 | 내 지원 내역에 표시할 상태 | 푸시·이메일·별도 결과 통지 |
견적을 요청할 때는 다음처럼 전달할 수 있습니다.
구직자는 앱에서 공고를 검색하고 PDF 이력서로 지원합니다. 기업 담당자는 PC 웹에서 자기 기업의 지원서를 읽고 ‘접수 완료·검토 중’ 상태를 관리합니다. 공고 공개 전에는 플랫폼 직원이 확인합니다. 공고 한 건과 지원 한 건이 양쪽 화면에서 연결되는 범위로 견적을 받고 싶습니다. 기업용 별도 모바일 앱, 채팅, 추천 기능은 추가 범위로 구분해 주세요.
검수할 때도 구직자의 제출 화면에서 끝내지 않습니다. 지원 후 목록·상세를 다시 열어 제출 내용이 남아 있는지, 기업 담당자가 같은 지원서를 읽는지, 다른 기업이나 다른 구직자가 조회하면 차단되는지 확인해야 합니다. 공고 마감과 중복 제출 같은 조건도 함께 확인하면 좋습니다.
구인구직 앱의 첫 개발 범위는 ‘공고를 어디까지 보여줄까’와 ‘지원서를 누가 받아 어디까지 처리할까’를 함께 정하는 일입니다. 대상 구직자·참여 기업·현재 쓰는 접수 도구가 있다면 상담 때 전달해 주세요. 필요한 화면과 연결 범위를 나눠 검토할 수 있습니다.
