협회 홈페이지 제작 시 채용 공고 관리 기능을 등록보다 접수와 마감 중심으로 설계하는 기준과 5단계 순서를 정리했습니다. 채용 유형별 카테고리, 관리자 화면, 개인정보 정책까지 사무국 실무 관점에서 안내합니다.
- 결론 먼저: 채용 공고 관리는 '등록'보다 '접수와 마감'부터 설계해야 합니다
- 1단계 – 협회 채용 유형별 공고 카테고리와 핵심 기능 목록 확정
결론 먼저: 채용 공고 관리는 '등록'보다 '접수와 마감'부터 설계해야 합니다
협회 사무국에서 채용 공고 요구사항을 정리할 때 가장 흔한 실수는 "공고를 어떻게 예쁘게 올릴까"부터 시작하는 겁니다. 그런데 정작 개발이 끝나고 나서 문제가 터지는 지점은 따로 있습니다. 마감 시점에 접수된 이력서가 어디로 쌓이는지, 누가 열람할 수 있는지, 마감 후 지원서는 어떻게 정리되는지 — 전부 '게시'가 아니라 '접수와 마감'의 문제죠. 채용 공고는 협회 홈페이지에서 단순 게시물이 아니라 지원자 접수 데이터를 다루는 운영 기능으로 봐야 합니다. 그래서 설계 순서가 중요합니다.
1. 채용 유형별 카테고리 확정 — 상임직·비상임·위촉·인턴 등 협회가 실제 운영하는 유형부터 나눕니다. 유형이 달라지면 접수 양식도 달라지기 때문입니다. 2. 관리자 등록·수정·마감 화면 — 공고를 올리고, 모집 요강을 수정하고, 마감 처리하는 흐름을 사무국 담당자 기준으로 정합니다. 관리자 페이지가 별도 권한으로 분리되는지 확인하세요. 3. 이력서 접수와 개인정보 정책 — 동의 문구, 보관 기간, 불합격자 지원서 파기 시점까지 문서로 정해둡니다. 여기가 빠지면 개발 후반에 재작업이 발생합니다. 4. 지원자 현황 집계와 알림 — 접수 건수 확인, 마감 임박 알림(알림톡·이메일 등)이 관리자 화면과 연결되는지 봅니다. 5.
1단계 – 협회 채용 유형별 공고 카테고리와 핵심 기능 목록 확정
협회 채용이라는 걸 한 번만 겪어본 분도 알 겁니다. "공고 하나만 올리면 되지" 하고 시작했다가, 어느 순간 정규직 공고와 위원회 위원 공모가 같은 양식에 섞여 있는 통계가 없는 목록이 되어버리는 거죠. 사무국 입장에서 지원자 관리가 어긋나는 첫 번째 지점이 바로 여기입니다.
왜 '유형 확정'이 기능보다 먼저인가
협회 채용은 일반 기업과 다르게 유형이 갈립니다.
- 임직원 정규 채용 — 지원 자격, 경력 조건, 전형 절차가 가장 복잡
- 자문위원·위원회 위원 공모 — 첨부 서류가 서약서·경력증명서 등으로 달라지고 심사 주체가 이사회인 경우가 많음
- 사무국 계약직·인턴 — 모집 기간이 짧고 마감 처리가 잦음
- 상근 직원 채용 — 공고 노출 기간과 서류 접수 마감이 분리되는 경우가 있음
유형마다 지원 자격, 첨부 서류, 모집 기간, 심사 절차가 다르니, 카테고리를 먼저 나눠 놓지 않으면 뒤에서 폼 설계가 모든 유형의 최대공약수로 평평해집니다. 그러면 정작 필요한 서류를 못 받거나, 위원 공모에 정규 채용용 문항이 붙는 일이 생깁니다.
유형별로 확인할 기능 목록
카테고리가 정해졌다면 이 순서로 기능을 점검해 보세요.
2단계 – 사무국이 직접 운영할 관리자 화면 설계 기준
채용 공고 하나 올리려고 개발자에게 연락을 돌리는 사무국이 생각보다 많습니다. 원인은 대개 하나예요. 지원자가 보는 홈페이지 화면만 보고 견적을 냈고, 정작 공고를 등록하고 지원자를 정리하는 관리자 화면은 요구사항에서 빠져 있었던 겁니다. 그래서 텍스트 하나 고치는 일도 매번 수정 요청이 됩니다.
관리자 화면의 설계 잣대는 화려함이 아니라 실무자가 직접 다루는 구조입니다. 최소한 아래는 양식으로 입력되고, 버튼으로 처리되어야 합니다.
3단계 – 이력서 접수의 개인정보 수집·동의·보관·파기 기준
채용 공고를 올린 직후 가장 먼저 쏟아지는 게 이력서입니다. 흔히 "주민등록번호를 안 받으니 개인정보 이슈는 없다"고 넘기기 쉬운데, 성명·연락처·학력·경력만으로도 이미 개인정보입니다. 그래서 이력서 접수 기능은 만들고 나서 손보는 게 아니라, 설계 단계에서 처리 방침부터 확정해야 합니다.
접수 단계에서 확정할 세 가지
- 수집 항목과 목적 명시: 지원 폼에 어떤 개인정보를 어떤 목적으로 쓰는지 적고, 제출 전 동의 체크박스를 둡니다.
- 저장 방식 결정: 이력서 파일을 홈페이지 서버에 저장할지, 담당자 이메일로만 전송할지 정합니다. 서버 저장을 택하면 보관 기간 제한을 함께 설계합니다.
- 보관·파기 기준: 채용 목적 달성 후 일정 기간 경과 시 파일 삭제·백업 폐기로 파기한다는 기준을 문구로 밝힙니다.
전송 구간과 조회 권한
전송은 SSL(https)이 기본 전제입니다. 서버와 SSL을 기본 포함하는 구독형 제작 서비스도 있으니, 상담 때 "당연히 되는 것"으로 확인해두면 나중에 따로 비용을 만나지 않습니다.
4단계 – 지원 접수 알림·현황 집계, 기존 홈페이지 연동 점검, 견적 전 최종 체크리스트
공고를 올리는 데까지만 설계하면 절반입니다. 나머지 절반은 공고가 살아 있는 동안 담당자가 매일 반복할 일 — 오늘 몇 명이 들어왔는지 세고, 명단을 뽑아 취합하는 과정에서 판가림 납니다.
지원 현황은 두 겹으로 집계되게
관리자 페이지에서 공고 단위 접수 건수와 모집부문 단위 접수 건수가 따로 보이고, 지원자 명단은 엑셀 다운로드로 한 번에 뽑히는 구조가 기본값이어야 합니다.
실행 전 점검표
| 점검 | 기준 |
|---|---|
| 결론 먼저: 채용 공고 관리는 '등록'보다 '접수와 마감'부터 설계해야 합니다 | 협회 홈페이지에서 채용 공고는 단순 게시물이 아니라 지원자 접수 데이터를 다루는 운영 기능입니다. 설계 순서는 (1) 채용 유형별 카테고리 확정 |
| 1단계 – 협회 채용 유형별 공고 카테고리와 핵심 기능 목록 확정 | 협회는 임직원 정규 채용, 자문위원·위원회 위원 공모, 사무국 계약직·인턴, 상근 직원 채용 등 유형이 나뉩니다. 유형별로 지원 자격, 첨부 서 |
| 2단계 – 사무국이 직접 운영할 관리자 화면 설계 기준 | 관리자 화면은 '사무국 실무자가 개발자 없이 쓸 수 있는가'를 기준으로 설계합니다. 구체적으로는 공고 등록 시 모집부문·모집인원·접수 기간·필수 |
| 3단계 – 이력서 접수의 개인정보 수집·동의·보관·파기 기준 | 이력서는 주민등록번호가 없어도 성명·연락처·학력·경력 등 개인정보이므로 접수 단계에서 처리 방침을 설계에 반영해야 합니다. 필수 확정 항목은 다 |