논문 심사 일정 관리 시스템 개발 범위 작성 방법을 단계별로 정리했습니다. 심사 프로세스 문서화, 권한·화면 체크리스트, 기존 시스템 연동까지 외주 RFP에 꼭 포함할 항목을 확인하세요.
- 결론 먼저: 개발 범위는 '심사 단계 → 화면 → 알림 → 데이터' 순으로 문서화하라
- 1단계: 심사 프로세스 단계별 요구사항 문서화 — 접수 마감부터 최종 수락까지
결론 먼저: 개발 범위는 '심사 단계 → 화면 → 알림 → 데이터' 순으로 문서화하라
"논문 심사 되는 시스템 만들어 주세요" — 개발사에 이 한마디로 견적을 받았다가 프로젝트 중반에 가장 많이 듣는 말이 바로 "그건 별도 개발이라 추가 견적입니다"입니다. 기능 범위를 초과하는 개발은 별도 견적으로 처리되는 게 업계 표준이고, 문자 발송비·외부 유료 API·PG 수수료 같은 항목도 기본 비용에 포함되지 않는 경우가 대부분이에요. 즉, 범위를 흐리게 전달하면 견적도, 일정도, 예산도 흔들립니다.
개발사가 견적을 매기는 단위는 '심사가 된다'가 아니라 화면 개수, 권한 종류, 알림 채널, 데이터 구조입니다. 같은 기능이라도 이 네 가지가 어떻게 정의되느냐에 따라 표준 솔루션 범위(구축 4~6주)로 끝날 수도, 커스텀 요건(6~10주)으로 넘어갈 수도 있으니까요. 그래서 문서화 순서가 중요합니다. | 정리 방식 | 개발사 입장에서 보이는 것 | 결과 |
| "논문 심사 되는 시스템" | 기능 범위 불명확 | 범위 확정 전까지 견적 불가, 추후 추가 비용 발생 |
|---|---|---|
| 단계별 화면·알림·데이터 정의 | 화면 수·권한·연동 항목 확인 가능 | 표준 범위 vs 커스텀 구분이 명확해짐 |
실제로 적는 방법
접수 마감부터 최종 수락까지 단계를 먼저 세로로 채우고, 각 단계마다 가로로 네 칸을 채우면 됩니다.
1단계: 심사 프로세스 단계별 요구사항 문서화 — 접수 마감부터 최종 수락까지
접수 마감 당일 밤 11시, "파일이 안 올라가요"라는 문의가 쏟아지고, 일주일 뒤엔 심사위원마다 직접 문자를 보내 기한을 재촉하는 일이 반복된다면, 그 프로세스는 아직 한 번도 문서로 정리된 적이 없다는 신호입니다. RFP의 첫 장은 바로 여기서 시작합니다.
다섯 단계별로 적을 것
- 접수 마감: 투고 기한 자동 마감 기준, 마감 리마인드 발송 시점, 업로드 용량과 허용 파일 형식
- 심사위원 배정: 분야 매칭 규칙, 심사 가능 편수 제한, 블라인드 심사 적용 여부
- 심사 기한: 위원별 기한 설정, 기한 임박 리마인드(이메일·문자) 채널과 발송 횟수
- 수정 요청: 심사 의견 전달 방식, 재제출 기한, 재심사 라운드 수
- 최종 수락: 수락·거절 통보 발송, 학회지·발표 세션 연계 여부
수동 개입 지점과 자동 처리 지점을 나눠야 하는 이유
판단 기준은 단순합니다. 자동 처리 지점은 그 자체가 개발 항목이 되고, 수동 개입 지점은 관리자 화면·권한 항목이 됩니다. 이 구분 없이 견적을 받으면 "이것도 기본으로 되는 거 아니에요?"라는
2단계: 역할별 권한·화면 체크리스트와 기존 시스템 연동 점검
마감 이틀 전, 심사위원이 운영자에게 "이 논문 저자가 누구인가요?"라고 묻는 순간 익명 심사는 무너집니다. 권한 설계는 사고가 나기 전, RFP 단계에서 못 박아야 하는 영역입니다.
역할별 화면·권한 한 장 표
| 역할 | 필요한 화면 | 권한 경계 |
|---|---|---|
| 투고자 | 논문 제출·수정, 심사 상태 확인 | 자기 논문만 열람·수정 |
| 심사위원 | 배정 목록, 심사평 입력, 기한 관리 | 투고자 정보 비식별 상태로만 원문 열람 |
| 운영자 | 배정 관리, 독촉 발송, 통계 | 전체 조회는 가능하되 개인정보 열람은 별도 권한으로 분리 |
심사위원 익명성은 "이름 가림" 수준으론 부족합니다. 가림 범위를 항목화해서 RFP에 넣으세요.
- 저자명·소속·이메일 화면 마스킹
- 논문 표지·감사의 글 페이지 비식별 처리
- 파일명·문서 속성에 남는 저자 정보 제거 여부
- 투고자가 심사위원 이름을 확인할 수 없는 조건
개인정보·논문 원본 보관 기간과 파기 조건도 같은 문단에 명시합니다. 기준을 학회가 먼저 정하지 않으면 데이터가 시스템에 무기한 쌓이고, 그게 곧 리스크로 돌아옵니다.
3단계: 구축 방식 비교와 협의 — 구독형 vs 맞춤 개발, 변경 비용 기준
3단계: 구축 방식 비교와 협의 — 구독형 vs 맞춤 개발, 변경 비용 기준
견적을 받다 보면 "구독형은 월 5만원, 맞춤 개발은 별도 견적"이라는 답만 듣고 끝나는 경우가 많아요. 문제는 겉보기 가격이 아니라 내 학회의 요구사항이 어느 쪽 기능 범위 안에 들어가는지입니다. 논문 심사 시스템은 회원 관리, 초록 접수, 심사 배정, 결제가 얽혀 있어서, "저렴한 플랜"을 골랐다가 필요 기능이 상위 요금제에만 있다는 걸 늦게 알면 일정이 먼저 무너집니다.
| 항목 | 구독형 | 맞춤 개발 |
|---|---|---|
| 오픈 속도 | 자료 준비 후 최단 3일에 1차 시안 | 표준 기준 4~6주, 커스텀 포함 시 6~10주 |
| 기능 자유도 | 요금제 범위 내 | 범위 밖 요구도 개발 가능 |
구독형이 저렴해 보여도 주의할 지점이 분명합니다. - 예약·결제·알림톡·관리자 기능은 성장 관리형(월 20만원~)부터 제공되는 구조라면, 심사 위원 알림과 참가비 결제가 필요한 순간 최저 플랜은 답이 아닙니다.
4단계: 문의 전 준비물과 흔한 실수 — 견적 빠르게 받는 체크리스트
견적 문의를 보내기 전에 준비물이 갖춰졌는지부터 점검해 보세요. 준비가 된 문의와 그렇지 않은 문의는 답변 속도와 견적의 정확도가 완전히 다릅니다. 개발사 입장에서는 범위가 보이는 문의는 바로 답할 수 있지만, "논문 심사 시스템 하나 만들려고요, 얼마예요?"라는 문의는 되물을 수밖에 없습니다.
문의 전에 챙길 5가지 준비물
- 심사 프로세스 표 — 1단계에서 정리한 접수 → 심사 배정 → 심사 → 최종 결정 흐름을 한 장으로
- 역할별 권한·화면 체크리스트 — 관리자, 심사위원장, 심사위원, 투고자가 각각 무엇을 보고 할 수 있는지
- 기존 시스템 자료 — 현재 홈페이지·등록 시스템 화면 캡처와 회원 수, 연간 투고 편수
- 정책 요구사항 — 블라인드 심사 여부, 개인정보 보관 기준
- 희망 오픈 일정 — 학술대회일이나 투고 마감 기준을 역산한 날짜
여기서 특히 세 번째가 자주 빠집니다. 기존 홈페이지의 회원관리·사전등록·결제를 단일 플랫폼에서 통합 운영하는 방식(홍커뮤니케이션 학회 홈페이지 솔루션 등)이 있는 만큼, 현재 시스템의 화면과 데이터 규모를 먼저 보여주면 "새로 만들지, 연결할지" 판단이 훨씬 빨라집니다.