제1부 제도와 시스템 기반

1.4 IRIS·NTIS·RCMS — 시스템과 데이터 인프라

국가R&D의 신청·협약·연구비·성과·정산은 모두 전산 시스템에서 처리된다. 종이로 하는 일이 아니다. 시스템을 모르면 마감을 놓치고, 연구비를 못 쓰고, 성과를 등록 못 해 한 일도 인정받지 못한다. 이 장은 수행기관이 닿는 주요 시스템의 역할과 분업을 정리한다.

정직 고지: 시스템은 통합·개편·명칭변경이 매우 잦다. 과거 여러 부처별 시스템(예: 부처별 사업관리시스템)이 통합되는 흐름 속에 있다. 아래 명칭·역할 경계는 시점에 따라 달라질 수 있으니, 실제 과제는 공고문이 지정한 시스템을 따른다(확인 필요).

1.4.1 시스템의 분업 — 한 장으로

역할로 나누면 시스템은 대체로 세 묶음이다.

• IRIS(범부처 통합연구지원시스템): 신청부터 협약·변경·평가·정산까지 과제 행정의 중심 창구(범부처 통합을 지향하는 시스템 — 적용 범위·명칭 확인 필요).
• RCMS(연구비통합관리시스템): 연구개발비의 집행·증빙·관리 전용. 연구비카드·계좌와 연계해 비목별 집행을 투명하게 기록(4.2).
• NTIS(국가과학기술지식정보서비스): 국가R&D 과제·인력·성과·통계의 포털. 성과 등록·검색, 과제 정보 공개(5.2).

1.4.1.1 생애주기에 시스템을 포개기

어느 단계에 어느 시스템을 쓰는지 생애주기(0.1.6)에 포갠다.

함의: 한 시스템만 알면 안 된다. 신청은 IRIS, 돈은 RCMS, 성과는 NTIS로 갈린다. 담당자(신청·연구비·성과)를 나눠 두는 이유이기도 하다(1.4.5).

1.4.2 IRIS — 신청·협약·관리의 창구

수행기관이 과제 행정에서 가장 많이 들어가는 시스템. 생애주기(0.1.6)를 따라 하는 일:

• 공고 확인·신청: 사업 공고 열람, 연구개발계획서·예산·참여기관·연구원 정보 입력·제출(3.3, 3.4).
• 기관·연구자 등록: 기관 정보, 사업자·연구소 정보, 연구자 프로필(경력·실적)을 사전 등록해 두어야 신청이 매끄럽다.
• 협약·변경: 선정 후 협약 체결, 연구책임자·예산·참여기관 변경 신청(4.1).
• 평가·보고: 연차·단계·최종 보고서 제출, 평가 결과 확인(5.1).
• 정산 연계: 종료 후 정산 자료 제출(5.4).

실무 함정:

• 사전 등록을 미루면 마감에 막힌다: 기관·연구자·연구소 정보 등록, 공인인증/전자서명 준비는 공고 마감 직전이 아니라 미리. 시스템 등록 지연으로 신청 자체를 못 하는 사고가 흔하다.
• 마감 직전 폭주: 마감일에는 접속 폭주로 제출이 지연·실패할 수 있다. 하루 이상 여유를 두고 제출.
• 입력 항목이 곧 평가자료: 시스템에 입력한 정량 정보(실적·예산·목표)는 그대로 평가에 쓰인다. 첨부 계획서와 수치가 어긋나지 않게 정합을 맞춘다.

1.4.2.1 신청 제출 D-day 타임라인 — 사고 없이 내는 법

마감 사고는 거의 다 "막바지"에서 난다. 가상 타임라인으로 안전 절차를 본다.

원칙: 마감일에 제출하지 않는다. 시스템 검증 오류(필수항목 누락·형식 불일치)는 제출 시점에야 뜨는 경우가 많아, 하루 이상의 여유가 필요하다. 컨소시엄 과제는 다른 기관의 입력 지연이 우리 제출을 막으므로 더 일찍 독촉한다(3.2).

1.4.3 RCMS — 연구비를 쓰는 곳

연구개발비는 RCMS(연구비통합관리시스템)와 연구비카드·전용계좌를 통해 집행·기록된다(상세 4.2).

• 집행 등록: 인건비·재료비·여비 등 비목별 집행을 증빙과 함께 등록.
• 카드·계좌 연계: 연구비카드 사용 내역이 자동 연계되어 투명성 확보. 현금 인출·임의 사용이 막힌다.
• 집행 점검: 전문기관이 비목 한도·목적 적합성을 점검. 부적정 집행은 즉시 드러난다.
• 정산 기초자료: 집행 내역이 그대로 정산의 근거가 된다 — 평소 정확히 등록하면 정산이 가볍다.

핵심: RCMS는 "투명성 강제 장치"다. 우회·임의 집행을 어렵게 만들어 부정을 예방한다. 이를 우회하려는 시도(허위 증빙·카드깡 등)가 곧 연구비 부정의 전형이며 중대 제재 사유다(6.3).

1.4.3.1 RCMS가 막는 것 — "왜 이렇게 불편한가"의 이유

수행기관은 RCMS·연구비카드를 "불편한 통제"로 느끼지만, 그 불편함이 수행기관을 보호한다.

→ 정산·점검·감사에서 "우리는 규정대로 썼다"를 데이터로 증명

견해: 투명성 장치를 우회 대상이 아니라 알리바이 장치로 보면 관점이 바뀐다. 규정대로 쓰면 시스템이 자동으로 결백을 증명해 준다(4.2.8). 우회하려는 순간 그 데이터가 거꾸로 증거가 된다.

함정(균형): 다만 RCMS가 "통과시켰다"가 곧 "정산에서 인정된다"를 보장하지는 않는다. 시스템은 형식·한도 체크를 도울 뿐, 목적 적합성·증빙 충실성의 최종 판단은 정산·점검에서 사람이 한다 — 시스템이 막지 않았어도 사후에 부적정으로 지적될 수 있다(4.2, 5.4). 또한 등록 시점·증빙 첨부의 흔적이 그대로 남는 만큼 입력 실수·지연도 똑같이 기록되어 거꾸로 불리하게 작용할 수 있고, 시스템 장애·승인 지연으로 마감에 쫓길 위험도 있다(시기·운영은 시점 의존, 확인 필요). "시스템이 알아서 해 준다"가 아니라 "시스템은 흔적을 남기고, 판단은 여전히 규정·사람이 한다"가 정확한 그림이다.

1.4.4 NTIS — 성과를 등록하고 정보를 얻는 곳

NTIS는 국가R&D 정보의 공개 포털이자 성과 등록 창구다.

• 성과 등록: 논문·특허·시제품·기술이전·사업화 등 성과를 등록해야 실적으로 인정(5.2). "한 일"이 아니라 "등록한 일"이 실적이다.
• 과제·통계 검색: 과거·진행 과제, 수행기관, 분야별 투자 동향을 검색 — 사업 탐색·경쟁 분석·기획에 유용(3.1, 6.1). 유사 과제가 이미 있었는지, 어떤 기관이 무엇을 했는지 파악.
• 참여연구원 정보: 연구자별 과제 참여 이력·참여율 관리의 기초 데이터(4.3).

활용 팁(견해): 제안 기획 단계에서 NTIS로 유사·선행 과제를 검색하면, 차별성 논리(6.1)와 중복성 회피(국가R&D는 중복지원을 제한)에 직접 도움이 된다.

1.4.4.1 NTIS를 "정보 무기"로 쓰기 — 기획 전 정찰

NTIS는 성과 등록 의무를 넘어 경쟁 정찰 도구다. 제안 전에 다음을 캔다(3.1.6, 6.1.4).

• 선행·유사 과제: 우리가 하려는 주제가 이미 지원됐나 → 중복 회피·차별성 논리.
• 경쟁 기관: 이 분야를 누가 수행했나 → 컨소시엄 후보·경쟁자 파악(3.2).
• 수행기관 트랙레코드: 잠재 파트너의 과거 수행·성과 → 파트너 검증(3.2.4).
• 투자 동향: 분야별 과제 수·예산 추이 → 정책 방향·기회(1.2.5).

견해: 제안서를 쓰기 전 NTIS 정찰에 반나절을 쓰면, "이미 있는 것을 모르고 제안"하는 치명적 실수를 피하고 차별성 논리를 데이터로 무장한다.

1.4.5 시스템 사용 준비 — 진입 전 체크리스트

처음 진입하는 기업이 시스템 때문에 헤매지 않으려면 미리 준비한다.

• [ ] 기관(사업자) 정보·기업부설연구소 정보 시스템 등록
• [ ] 연구책임자·참여연구원 프로필(경력·학력·실적) 등록·갱신
• [ ] 전자서명/공동인증 등 인증수단 준비(기관·개인)
• [ ] 연구비카드·전용계좌 발급 절차 확인(선정 후 신속 처리 위해)
• [ ] 담당자 계정·권한 정리(기관 내 신청·연구비·성과 담당 분리)
• [ ] 공고별 지정 시스템·서식·제출 마감 확인(3.1)

1.4.5.1 사내 역할 분리 — 한 사람에게 몰지 마라

작은 회사일수록 대표·연구소장 한 명이 신청·연구비·성과를 다 맡는데, 이는 사고와 병목의 원인이다(4.2.7). 최소한의 분리:

견해: 인력이 적어 겸직하더라도 집행과 승인은 가능한 한 분리한다(견제). 한 사람이 다 쥐면 그 사람의 부재·실수·일탈이 곧 과제 위기가 된다. 권한·계정도 역할대로 나눠 추적성을 남긴다.

1.4.6 데이터가 연결돼 있다는 함의 — 정직성의 강제

시스템들이 연계돼 있다는 사실 자체가 수행기관에 주는 메시지가 있다.

• 참여율·중복이 교차 검증된다: 한 연구자가 여러 과제에 올린 참여율 합, 중복지원 여부가 시스템 간 대조로 드러난다(4.3). 허위 참여·중복 신청은 숨기기 어렵다.
• 집행·성과·정산이 한 줄로 이어진다: 연구비 집행(RCMS) → 성과(NTIS) → 정산(IRIS)이 데이터로 연결돼, 어느 한 곳의 거짓이 다른 곳과 어긋나면 드러난다.
• 이력이 남는다: 제재·환수·불성실 이력이 시스템에 남아 다음 과제 자격에 영향(6.3).

1.4.6.1 교차검증이 검출하는 전형 — "데이터는 거짓말을 안 한다"

시스템 연계가 실제로 무엇을 검출하는지(상세 6.3.6).

결론(견해): 시스템은 정직한 수행을 가장 쉬운 길로 만들고 편법을 가장 어려운 길로 만든다. "안 걸린다"는 가정은 데이터 연계 앞에서 틀린다(6.3.6). 시스템을 "귀찮은 행정"이 아니라 수행을 증명하고 보호하는 인프라로 쓰는 것이 현명하다.

1.4.8 IRIS 신청 화면 흐름 — 입력의 실제 순서

1.4.2는 IRIS에서 하는 일을 나열했다. 여기서는 실제 신청 입력이 대체로 어떤 순서로 흐르는지, 어디서 막히는지를 본다(화면 구성·명칭은 개편이 잦으므로 시점·사업에 따라 다름 — 확인 필요. 정확한 흐름은 공고가 지정한 시스템의 매뉴얼을 따른다).

1.4.8.1 신청 입력의 통상 흐름(가상·확인 필요)

함정: 각 단계의 저장이 누락되거나, [7]의 정량목표가 [4] 첨부 계획서와 어긋나면 검증에서 막히거나 평가에서 불리하다(1.4.2). [9]의 자동검증은 필수항목 누락·형식 불일치를 제출 시점에야 뱉어 내는 경우가 많아, 막바지 제출은 위험하다(1.4.2.1).

1.4.8.2 컨소시엄 신청의 분산 입력 — 병목 지점

공동·위탁기관이 있으면 각 기관이 자기 정보를 직접 입력해야 하는 구조가 흔하다(기관 계정으로 접속해 분담·연구원·예산 입력). 주관이 다 대신 못 하는 부분이 있다.

• 타 기관 입력 지연 = 우리 제출 불가: 한 기관이라도 입력을 안 끝내면 전체 제출이 막힐 수 있다.
• 참여율·예산 합 검증: 기관별 입력이 합쳐져 참여율 합·예산 매칭이 검증된다 — 한 곳의 숫자 오류가 전체 검증을 막는다.

견해: 컨소시엄 과제는 주관이 각 기관 입력 마감을 별도로 명시하고(D-5 등) 독촉한다(1.4.2.1, 3.2). "다들 알아서 하겠지"가 마감 사고의 단골 원인이다.

1.4.9 시스템 간 데이터 연계 — 무엇이 어디로 흐르나

1.4.6은 "데이터가 연결돼 있다"는 함의를 정직성 측면에서 봤다. 여기서는 실무적으로 어떤 데이터가 시스템 사이를 오가는지를 정리한다(연계 범위·방식은 개편에 따라 다름 — 확인 필요).

1.4.9.1 데이터 흐름 지도(개념·확인 필요)

• IRIS → RCMS: 협약된 과제·예산 정보가 연구비 집행의 기준으로 넘어간다.
• RCMS → IRIS: 집행 실적이 정산·점검의 근거로 돌아온다(1.4.3).
• IRIS·과제 → NTIS: 과제·연구자·성과 정보가 등록·공개된다(1.4.4).
• 연구자·참여율·제재 이력: 시스템 간 대조로 참여율 합·중복·결격이 검증된다(1.4.6.1, 1.3.10.3).

함의: 한 곳에 잘못 입력하면 연계된 다른 곳까지 어긋난다. 예컨대 IRIS의 과제 예산과 RCMS의 집행 기준이 안 맞으면 집행이 막히거나 정산에서 차이가 난다. 견해: 입력은 한 번에 정확히 — 시스템이 연결돼 있어 사후 수정이 여러 곳을 건드린다.

1.4.10 자주 나는 시스템 오류 — 입력·전송·검증

마감·집행·등록에서 반복되는 시스템 사고를 유형화한다. 대부분 미리 준비하면 피할 수 있는 것들이다.

1.4.10.1 오류 유형과 예방 — 비교표

1.4.10.2 사고가 났을 때 — 즉시 할 일

오류·장애로 마감·처리가 막히면 당황하지 말고 절차대로.

• 증거를 남긴다: 오류 화면·메시지·시각을 캡처. 장애였음을 입증할 근거가 권익 보호에 쓰인다.
• 공식 채널로 즉시 연락: 전문기관·시스템 헬프데스크에 상황을 알리고 안내를 받는다(1.2.4). 시스템 장애로 인한 마감 구제는 사업·상황에 따라 다름(확인 필요) — 그래서 애초에 막바지를 피하는 것이 최선.
• 백업을 확보한다: 제출 확인서·접수번호·입력 데이터 사본(1.4.2.1). 다음에 같은 사고를 피할 기록.

견해: 시스템 오류의 90%는 "막바지"와 "사전 미준비"에서 온다(1.4.5). 오류 대응 매뉴얼보다 여유 있는 일정과 사전 등록이 훨씬 강한 예방책이다.

1.4.11 마감 D-1 실제 입력 타임라인 워크스루(가상)

1.4.2.1은 D-14부터의 큰 일정을, 1.4.8.1은 입력 화면 흐름을 줬다. 여기서는 마감 전날(D-1) 하루를 시간 단위로 쪼개, 막바지에 실제로 무슨 일이 벌어지고 어떻게 사고 없이 제출을 끝내는가를 본다. 시각·화면은 예시이며 사업·시스템에 따라 다르다(확인 필요).

1.4.11.1 D-1 시간대별 타임라인(가상)

견해: 이 타임라인의 핵심은 제출을 D-1 오후에 끝내고, 검증 오류를 잡을 1~2시간을 남기는 것이다. 자동검증은 제출 버튼을 눌러야 비로소 누락·형식 오류를 뱉는 경우가 많아(1.4.8.1), "다 입력했으니 됐다"가 아니라 "제출 시도까지 해 봐야 끝"이다. 14:00 1차 시도가 16:00 완료를 만든다 — 이 버퍼가 사고를 흡수한다.

1.4.11.2 D-1에 자주 발생하는 문제 — 미니 카탈로그

함정: 위 여섯 중 다수는 마감일(D-0) 오후에야 발견하면 수습 불가다 — 위탁기관 입력 독촉, 확약서 추가 발급, 첨부 재작성에는 시간이 든다. D-1에 끝내는 이유가 이것이다.

1.4.12 시스템 오류·전송 실패 — 실제 대응 한 장면(가상)

1.4.10은 오류 유형과 예방을 표로 줬다. 여기서는 실제로 전송이 실패한 순간 무엇을 하는지를 한 장면으로 펼친다. 화면·메시지·대응은 예시이며 사업·시점에 따라 다르다(확인 필요).

1.4.12.1 전송 실패 순간의 대응 워크스루(가상)

 [상황] D-1 15:40, 제출 버튼 클릭 → "처리 중" 후 화면 멈춤,
        잠시 뒤 "전송 중 오류가 발생했습니다(코드 OO)" 메시지.

 [당황하지 말고, 순서대로]
 ① 즉시 캡처            오류 화면·메시지·코드·시각(시계 포함)을 스크린샷.
                        → 장애였음을 입증할 1차 증거(1.4.10.2)
 ② 중복 제출 확인       새로고침/재로그인 후 '제출 상태'·접수목록 확인.
                        → 실제로는 접수됐는데 화면만 끊긴 경우가 있다.
                          접수번호가 있으면 완료된 것 — 재제출로 중복 만들지 말 것.
 ③ 미접수면 재시도      접수 안 됐으면 입력 손상 여부 확인 후 재제출.
                        브라우저·캐시 문제일 수 있어 다른 브라우저로도 시도.
 ④ 헬프데스크 연락      해소 안 되면 시스템 헬프데스크·전문기관에 즉시 연락.
                        오류코드·시각·과제명·접수시도 내역을 정리해 전달(1.2.9).
 ⑤ 기록 남기기         통화·문의 시각, 안내받은 내용, 임시 접수번호 등 기록.
                        장애 구제는 사업·상황에 따라 다름(확인 필요) — 근거가 필요.

견해: 전송 실패에서 가장 위험한 두 실수는 ① 확인 없이 마구 재제출해 중복 신청을 만드는 것, ② 증거를 안 남기고 시간만 흘려보내는 것이다. ②번을 먼저(캡처), 그다음 ②중복 확인, 그다음 재시도·연락의 순서를 지킨다. 그리고 이 모든 드라마는 마감일이 아니라 D-1에 일어났기에 수습할 시간이 있었다는 점이 핵심이다(1.4.11). 마감일 23:50에 같은 일이 나면 손쓸 수 없다.

1.4.12.2 장애를 주장하려면 — 무엇이 근거가 되나

견해: 시스템 장애로 인한 마감 구제 인정 여부·범위는 사업·전문기관에 따라 다르다(확인 필요). 그래서 근거를 쌓아 두되, 구제를 믿고 막바지에 거는 것은 도박이다. 근거는 보험일 뿐, 실질적 안전판은 D-1 제출이다(1.4.2.1).

1.4.13 RCMS 집행등록 한 건의 화면 흐름(가상)

1.4.3은 RCMS가 무엇을 하는지를 개념으로 줬다. 여기서는 연구비 집행 한 건을 등록하는 화면 흐름을, 재료비 구매를 예로 단계별로 본다. 화면 구성·항목명은 개편이 잦으므로 시점·시스템에 따라 다르며, 정확한 절차는 RCMS 매뉴얼·전문기관 안내를 따른다(확인 필요). 비목 인정·증빙 기준의 실무 상세는 4.2.

1.4.13.1 재료비 1건 집행등록 흐름(가상·확인 필요)

함정: ① 비목 오선택(소모품을 장비로 등)은 검증·점검에서 걸린다. ② 사용목적이 '과제 무관'으로 보이면 집행이 부적정으로 의심된다 — 목적을 과제 활동과 연결해 구체적으로 적는다. ③ 증빙 누락·지연은 정산 부담으로 돌아온다 — 집행 시점에 바로 첨부한다(4.2). ④ 카드 자동연계가 있어도 사용목적·증빙은 사람이 채워야 완성된다.

1.4.13.2 집행등록을 미루면 — "쌓이면 정산 지옥"

 좋은 습관: 집행 즉시 등록·증빙 첨부
   → 데이터가 평소 정확히 축적 → 정산이 가볍다(1.4.3)

 나쁜 습관: "나중에 몰아서"
   → 영수증 분실·목적 기억 안 남·증빙 누락 → 정산·점검에서 곤욕
   → 부적정 의심 시 소명 부담(6.3)

견해: RCMS 집행등록은 "그때그때"가 압도적으로 비용이 적다. 한 건을 미루면 그 건의 목적·증빙을 나중에 복원해야 하는데, 시간이 지날수록 복원 비용이 커진다. 집행과 등록을 같은 날에 묶는 것이 정산을 가볍게 하는 가장 단순한 규율이다(1.4.3.1의 "알리바이 장치" 관점).

1.4.14 자주 묻는 시스템 Q&A

1.4 전반의 실무 궁금증을 Q&A로 모은다. 모든 답은 일반적 경향이며, 화면·명칭·기준은 개편이 잦으므로 공고 지정 시스템·매뉴얼·전문기관 확인이 최종이다(BK-05).

1.4.14.1 신청·시스템 Q&A(가상·확인 필요)

 Q1. 어느 시스템에 신청하는지 어떻게 아나?
 A.  공고문이 지정한다. 시스템은 통합·개편이 잦아(1.4 정직고지)
     "이 사업은 늘 그 시스템"이라 단정하지 말고 공고에서 확인.

 Q2. 기관·연구자 등록은 언제 하나?
 A.  공고 마감 직전이 아니라 미리(1.4.5). 등록·인증서 준비
     지연으로 신청 자체를 못 하는 사고가 흔하다. 최소 D-14(1.4.2.1).

 Q3. 시스템 입력값과 첨부 계획서 수치가 다르면?
 A.  검증에서 막히거나 평가에서 불리하다(1.4.8.1). 입력값이
     그대로 평가자료가 되므로 정합을 맞춘다. D-1 정합 점검(1.4.11.1).

 Q4. 컨소시엄인데 우리(주관)가 다 입력하면 안 되나?
 A.  공동·위탁기관이 자기 정보(분담·연구원·예산)를 직접 입력해야
     하는 구조가 흔하다(1.4.8.2). 한 곳이라도 미완이면 제출이
     막힐 수 있으니 기관별 마감을 명시하고 독촉.

 Q5. 마감일에 내면 왜 위험한가?
 A.  접속 폭주·전송 지연·장애, 그리고 검증 오류를 잡을 시간이
     없다(1.4.2.1, 1.4.11). 장애 구제는 보장되지 않는다
     (확인 필요). D-1에 끝낸다.

 Q6. 연구비카드가 자동연계되면 RCMS에 따로 등록 안 해도 되나?
 A.  카드 내역이 연계돼도 비목·사용목적·증빙은 사람이 채워야
     집행등록이 완성된다(1.4.13.1). 자동연계는 일부일 뿐.

 Q7. 성과는 언제 NTIS에 등록하나?
 A.  '한 일'이 아니라 '등록한 일'이 실적이다(1.4.4). 성과 발생
     시 바로 등록한다 — 미루면 기한 경과·항목 누락 위험(1.4.10.1, 5.2).

 Q8. 한 곳에 잘못 입력하면 다른 시스템도 틀어지나?
 A.  그렇다. IRIS·RCMS·NTIS가 연계돼(1.4.9) 한 곳의 오류가
     연계처까지 어긋난다. 사후 수정이 여러 곳을 건드리므로 한 번에
     정확히 입력한다.

 Q9. 시스템 알림을 놓쳐 마감을 놓쳤다. 구제되나?
 A.  알림은 시스템·이메일·공문으로 흩어져 온다(1.2.8.1).
     수신 누락은 통상 수행기관 책임으로 본다 — 수신 계정을 공석으로
     두지 말고, 들어오는 문서·마감을 대장으로 관리한다.

 Q10. 데이터 교차검증으로 무엇이 잡히나?
 A.  참여율 합·중복지원·집행–성과 불일치 등이 시스템 대조로 드러난다
      (1.4.6.1). "안 걸린다"는 가정은 틀린다 — 정직이 가장
      쉬운 길이 되도록 설계돼 있다.

1.4.15 시스템에 처음 들어가기 — 회원가입·기관등록·인증·연구자 프로필을 0에서 세우기

1.4.2·1.4.5는 "기관·연구자 등록·인증서 준비를 미리 하라"고 반복했다. 그러나 처음 진입하는 기업·기관에게는 그 "등록"이라는 행위 자체가 막막하다 — 무엇을, 누가, 어떤 서류로, 어떤 순서로 하는지가 안 보인다. 이 절은 시스템에 아무 계정도 없는 0의 상태에서, 신청 버튼을 누를 수 있는 상태(1)까지 가는 절차를 정리한다. 2.4.11이 "연구비 관리체계를 0에서 1로" 세웠다면, 이 절은 그 시스템 판이다.

정직 고지: 회원가입·기관등록 화면, 인증수단, 연구자 식별번호의 명칭·절차·필요서류는 시스템 개편·사업·시점에 따라 다르다 — 모두 확인 필요. 아래는 대체로 거치는 단계와 준비물의 구조이며, 정확한 절차는 공고가 지정한 시스템의 회원가입·기관등록 매뉴얼과 전문기관 안내를 따른다.

1.4.15.1 "기관 계정"과 "개인 계정"은 다르다 — 두 줄기를 먼저 구분

초보자가 가장 자주 엉키는 지점: 시스템 진입은 두 개의 다른 줄기다. 하나라도 비면 신청이 막힌다.

• 개인 줄기: 연구책임자·참여연구원 각자가 회원가입하고 본인 프로필을 채운다. 한 연구자의 이력은 여러 과제에 걸쳐 시스템에 누적되며(1.4.4, 4.3), 통상 연구자별 고유 식별(번호 등)으로 관리된다(명칭·체계 확인 필요).
• 기관 줄기: 회사·대학·연구소를 시스템에 기관으로 등록해야, 그 기관 이름으로 과제를 신청·협약할 수 있다. 사업자등록·기업부설연구소 정보 등 기관 정보가 여기 붙는다.
• 연결: 개인이 기관에 소속(매핑)되어야 "그 기관 소속 연구자"로 신청에 들어간다. 이 매핑이 안 되면, 계정은 있는데 정작 우리 기관 과제에 못 붙는 사고가 난다.

견해: 작은 회사일수록 대표 한 사람이 개인·기관 줄기를 한꺼번에 처리하려다 엉킨다. "기관을 세우는 일"과 "사람을 등록하는 일"을 분리해 생각하면 막힘이 준다(1.4.5.1의 역할 분리와 같은 정신).

1.4.15.2 처음 진입의 통상 순서 — 0에서 신청 가능 상태까지(가상·확인 필요)

핵심 감각: [2] 기관 등록은 즉시 끝나지 않을 수 있다. 사업자·연구소 정보 확인·승인에 시간이 걸리면, 공고 마감 직전에 시작한 기관은 신청 자체를 못 한다 — 1.4.2가 "사전 등록을 미루면 마감에 막힌다"고 경고한 사고의 실체가 바로 이 승인 대기다. 처음 진입 기관은 공고가 뜨기 전에 [1]~[5]를 끝내 두는 것이 안전하다(0.1.11의 "미리 움직이는 자").

1.4.15.3 미리 갖춰 둘 준비물 — 등록 전 확보하고 시작

등록 화면 앞에서 서류를 찾느라 멈추지 않도록, 처음 진입 기관이 미리 모아 둘 것(품목·서식은 시스템·사업마다 다름 — 확인 필요):

• [ ] 사업자등록증(기업)·기관 고유번호 등 기관 식별 서류
• [ ] 기업부설연구소·연구개발전담부서 인정서(있는 경우 — 자격·가점에 쓰일 수 있음, 1.3, 2.4)
• [ ] 기관·개인 인증수단(전자서명/공동인증 등, 기관용·개인용이 다를 수 있음)
• [ ] 연구책임자·참여연구원의 경력·학력·실적 정보(프로필 입력용, 4.3)
• [ ] 연구비카드·전용계좌 발급 절차 확인(선정 후 신속 처리 위해 미리, 1.4.5)
• [ ] 사내 담당·권한 배분 계획(신청·연구비·성과 담당 분리, 1.4.5.1)

견해: 이 준비물의 절반은 "회사에 원래 있는 서류"이고 나머지 절반(인증수단·연구소 인정·프로필)은 발급·정리에 시간이 걸린다. 시간이 걸리는 항목부터 먼저 착수하는 것이 마감 사고를 막는 길이다(1.4.2.1의 D-14 타임라인과 연결).

1.4.15.4 처음 진입에서 자주 나는 사고 — 미리 알면 피한다

정직 고지: 위 사고·예방은 일반적 경향이며, 회원가입·기관등록·인증의 정확한 화면·필요서류·승인 소요는 그 시스템의 매뉴얼과 전문기관 안내가 최종이다(BK-05). 모르면 마감 한참 전에 전문기관에 절차를 문의해 둔다(1.2.4).

1.4.16 시스템 간 불일치가 정산에서 발생하는 메커니즘 — 끝까지 추적(가상)

1.4.9는 "데이터가 시스템 사이를 오간다"를, 1.4.6은 "불일치가 드러난다"를 개념으로 줬다. 그러나 실무자가 실제로 두려워하는 것은 그 불일치가 정산에서 구체적으로 어떻게 돈으로 환수되는가다. 여기서는 한 가상 과제의 숫자를 끝까지 따라가, IRIS(협약 예산)·RCMS(실제 집행)·NTIS(성과)의 어긋남이 정산에서 어떤 결과를 낳는지 본다. 숫자·항목은 모두 예시이며, 정산 기준·환수 판단은 「연구개발비 사용 기준」·전문기관 해석이 최종이다(확인 필요).

1.4.16.1 불일치의 씨앗 — 어디서 어긋나기 시작하나

 [협약 시점 — IRIS]
  인건비       60,000  (천원, 가상)
  재료비       30,000
  연구활동비   10,000
  ─────────────────────
  계          100,000  ← 이 숫자가 RCMS 집행의 '기준'으로 넘어감(1.4.9)

 [수행 중 — RCMS 실제 집행]
  인건비       52,000  (참여연구원 1명 중도 퇴사로 미집행분 발생)
  재료비       41,000  (시제품 재제작으로 초과 집행)
  연구활동비    9,000
  ─────────────────────
  계          102,000  ← 총액도, 비목 구성도 협약과 어긋남

씨앗 셋:

• 비목 간 어긋남: 재료비가 협약 30,000인데 41,000 집행 → 비목 한도 초과(전용 한도·승인 없이는 문제).
• 총액 어긋남: 102,000 집행인데 협약은 100,000 → 초과 2,000은 인정 안 될 수 있다.
• 인건비 미집행: 참여연구원 퇴사로 8,000 미집행 → 이 변경을 IRIS에 신고했나가 쟁점(4.1.4, 4.3).

1.4.16.2 정산에서 한 줄씩 발생하는 과정(가상 추적)

정산은 IRIS의 협약 예산과 RCMS의 집행 실적을 비목별로 대 본다. 어긋남이 한 줄씩 드러난다.

핵심 쟁점:

• 재료비 초과 11,000 → 사전 비목전용 승인(IRIS) 없으면 초과분이 '인정 안 되는 집행'으로 → 환수 대상이 될 수 있다
• 그런데 그 돈은 이미 썼다 → 이미 쓴 돈을 환수당하면 자부담으로 메움
• 인건비 미집행 8,000 → 퇴사 사실을 IRIS에 신고 안 했으면 "있지도 않은 인력으로 인건비를 협약했다"는 별도 지적까지

견해: 여기서 돈이 두 번 누수된다. ① 재료비 초과 11,000을 비목전용 승인 없이 썼다면 그 초과분이 불인정 → 회사가 자부담으로 메운다. ② 인건비 미집행 8,000은 잔액 반납이라 손해는 아니지만, 퇴사를 신고 안 한 절차 누락이 별도 지적·신뢰 손상으로 남는다. 핵심 메커니즘은 단순하다: IRIS의 협약(약속)과 RCMS의 집행(실제)이 어긋나는데 그 어긋남을 사전에 IRIS에 반영(변경신고·비목전용 승인)하지 않으면, 정산에서 비목별 대조에 걸려 불인정·환수가 된다.

1.4.16.3 막을 수 있었던 지점 — 어긋남을 '사전에 IRIS로' 흡수하기

이 사고는 집행 자체가 나빠서가 아니라, 집행의 변화를 시스템(IRIS)에 제때 반영 안 해서 났다. 막는 길은 집행 시점마다 있었다.

 [재료비 초과가 보일 때 — 41,000으로 가기 전]
   → 비목전용(재료비↑ 인건비↓)을 IRIS에서 사전 승인받는다(4.1.4)
   → 승인 후 집행하면 정산에서 '승인된 전용'으로 인정

 [참여연구원 퇴사 시점]
   → 즉시 IRIS에 참여연구원 변경 신고(4.3, 4.1.4)
   → 인건비 미집행분의 사유가 시스템에 남아 정산이 깔끔

 [집행 총액이 협약을 넘을 것 같을 때]
   → 넘는 집행은 원칙적으로 자부담. 정부지원금으로 넘겨 쓰면 불인정
   → 한도 안에서 쓰거나, 변경 절차를 먼저

견해: 정산은 사후에 몰아서 맞추는 것이 아니라, 수행 중 변화를 그때그때 IRIS·RCMS에 반영해 두면 자동으로 맞는다(1.4.3 "평소 정확히 등록하면 정산이 가볍다"). 비목전용·참여변경은 "귀찮은 행정"이 아니라 정산에서 환수당하지 않기 위한 사전 정렬이다. RCMS가 집행을 막지 않았다고 해서 정산에서 인정되는 것이 아니다(1.4.3.1 함정) — RCMS는 흔적을 남기고, 정산은 그 흔적을 협약(IRIS)과 대 본다. 둘을 어긋난 채 두면 그 간극이 그대로 환수액이 된다.

1.4.16.4 성과 쪽 불일치 — NTIS와도 어긋난다(가상)

불일치는 돈(IRIS↔RCMS)만이 아니라 성과(NTIS)에서도 발생한다.

견해: NTIS 성과는 집행(RCMS)·참여(IRIS)와 정합해야 한다. "인건비를 받은 연구원"이 그 과제 성과에 이름이 없거나, "집행은 가득 했는데 성과가 비면" 교차대조에서 걸린다. 그래서 성과 등록도 그때그때, 사사·과제번호를 정확히 달아 둔다(5.2). 세 시스템이 한 줄로 정합할 때 정산·평가가 가볍고, 한 곳이 어긋나면 그 한 곳이 전체 신뢰를 흔든다.

1.4.17 시스템 권한·역할 체계 — 계정마다 다른 "할 수 있는 일"

1.4.5.1은 "사내에서 누가 신청·연구비·성과를 맡나"라는 조직 분담을, 1.4.15.1은 "개인·기관 두 계정 줄기"를 봤다. 그 사이에 실무자가 자주 놓치는 한 층이 있다 — 시스템이 계정마다 부여하는 권한(role)의 층위다. 기관에는 보통 다른 계정에 권한을 주고 회수하는 관리자(마스터) 권한이 있고, 그 아래로 연구책임자·연구비담당·행정담당이 할 수 있는 일이 다르게 묶인다. 이 구조를 모르면 "왜 이 화면이 안 열리나", "왜 우리 기관 과제에 못 붙나", "퇴직자가 아직 마스터인데 아무도 못 바꾼다" 같은 사고가 난다.

정직 고지: 권한의 명칭·구분·부여 절차·세분 정도는 시스템(IRIS·RCMS 등)·개편·사업에 따라 다르다 — 모두 확인 필요. 아래는 대체로 존재하는 권한 층위의 구조이며, 정확한 권한 체계는 해당 시스템 매뉴얼·전문기관 안내를 따른다.

1.4.17.1 권한 층위와 할 수 있는 일 — 주체 대조(가상·확인 필요)

조직의 역할(1.4.5.1)과 시스템의 권한은 포개지지만 같지 않다. 조직에선 한 사람이 여러 역할을 겸해도, 시스템에선 그 사람의 계정에 어떤 권한이 켜져 있나가 따로 정해진다.

(O 주담당 · △ 가능/보조 · – 통상 불가. 실제 구분은 시스템·설정에 따라 다름 — 확인 필요.)

핵심 감각: 마스터는 "일을 하는 권한"이 아니라 "권한을 나눠 주는 권한"이다. 마스터가 비어 있거나 잘못된 사람에게 묶이면, 정작 일할 사람에게 권한을 못 주는 마비가 온다(1.4.18).

1.4.17.2 권한을 어떻게 나눌까 — 결정 ①②③

작은 기관일수록 "대표 한 계정이 마스터+모든 권한"을 가진다. 편하지만 위험하다. 세 갈래:

트레이드오프 한 줄: 권한을 모을수록 빠르고 부서지기 쉽고, 나눌수록 느리고 튼튼하다. 핵심은 집행과 승인을 같은 계정에 두지 않는 것(1.4.5.1)과 마스터를 한 사람에게만 묶지 않는 것이다.

1.4.17.3 함정과 견해

• 마스터가 퇴직자에게 묶임: 권한을 줄 사람이 사라져 신규 담당에게 권한을 못 준다(1.4.18).
• 권한 회수를 안 함: 퇴직·전보자의 권한이 살아 있어 계정 사고·부정 입력의 통로가 된다 — 데이터 교차검증에 거꾸로 흔적이 남는다(1.4.9).
• 연구책임자 변경 시 권한 이관 누락: 책임자가 바뀌었는데 시스템 권한은 옛 사람에 묶여, 변경·정산이 막힌다(4.1).

견해: 권한 설계의 황금률은 "최소권한 + 이원 마스터"다. 각자에게 자기 일에 필요한 만큼만 주고(과다 권한은 사고 표면적을 넓힌다), 마스터만은 반드시 둘 이상이 갖게 한다. 마스터가 하나면 그 하나의 부재가 곧 기관 전체의 시스템 마비다 — 이것은 '편의'가 아니라 '단일 장애점'이다.

1.4.18 위임·대리입력·계정·인증서 관리 사고 — 한 계정에 묶인 위험(가상 post-mortem)

1.4.5.1은 "한 사람에게 몰지 마라"를 견해로 던졌고, 1.4.15.4는 처음 진입 사고를 표로 줬다. 그러나 더 아픈 사고는 진입 후 수행 중에, 계정·인증서·대리입력을 둘러싸고 난다. 여기서는 한 가상 과제의 계정 사고를 끝까지 추적해 post-mortem한다(상황·시각은 예시 — 확인 필요).

1.4.18.1 가상 사고 — "대표 계정 하나에 다 묶였다"

 [배경] 5인 기업. 대표가 마스터·연구책임자·연구비담당을 한 계정으로 겸함.
        직원 A가 평소 대표 아이디·인증서로 대리 로그인해 입력해 왔다.

 [D-1 14:00] 변경신고 제출 마감 전날. 대표는 해외 출장(시차·연락 지연).
 [14:10] A가 대리 로그인 시도 → "인증서 만료" 메시지.
         갱신은 본인(대표) 확인이 필요한 구조 → A가 못 푼다.
 [15:00] RCMS 집행 마감분도 같은 계정 → 집행등록도 막힘.
 [16:00] 백업 마스터 없음 → 권한을 넘겨받을 다른 계정도 없음.
 [결과] 변경신고·집행등록 둘 다 마감 내 처리 실패. 대표 귀국까지 정지.

무엇이 한꺼번에 무너졌나: ① 단일 계정에 마스터·책임자·연구비가 다 묶임, ② 대리 로그인이라 본인 부재 시 인증을 못 풂, ③ 백업 마스터 부재로 권한 재배정 불가. 셋이 겹쳐 한 사람의 부재가 과제 전체의 정지가 됐다(1.4.5.1이 경고한 바로 그 그림).

1.4.18.2 post-mortem — 근본 원인과 막을 수 있던 지점

겉으로는 "인증서 만료"가 원인 같지만, 그것은 방아쇠일 뿐이다. 한 겹씩 들춘다.

막을 수 있던 지점(각 층마다 있었다):

• 인증서 만료일 관리: 인증서·계정 만료일을 대장으로 관리, 만료 전 미리 갱신(갱신 소요·절차는 발급기관 기준 — 확인 필요).
• 권한 분리·이원 마스터: 연구비담당·백업 마스터를 별도 계정으로(1.4.17).
• 대리 로그인 금지·정식 위임: 남의 아이디·인증서를 빌려 쓰지 말고, 시스템이 허용하는 정식 권한 부여로 처리(1.4.18.3).
• 막바지 회피: 변경·집행을 D-1에 몰지 않기(1.4.11).

1.4.18.3 대리입력·위임의 경계 — 어디까지 되고 어디부터 위험한가

"바빠서 남이 대신"은 흔하지만, 무엇을 대신하느냐에 따라 단순 편의와 사고·부정의 경계가 갈린다.

견해: 경계의 핵심은 "입력의 분업"과 "인증·서명의 위임"을 가르는 것이다. 입력은 권한만 있으면 나눠도 된다. 그러나 인증·전자서명은 그 사람이 그 행위를 했다는 책임의 표식이라, 남이 대신하면 부재 시 막히고(이번 사고) 분쟁 시 진정성을 다툰다. 위임이 필요하면 아이디를 빌리는 것이 아니라 시스템이 제공하는 정식 권한 부여·위임 기능으로 처리한다(가능 범위는 시스템마다 다름 — 확인 필요).

1.4.18.4 계정·인증서 관리 점검표

 분기·담당 교체 때마다 한 번씩
 ─────────────────────────────────────
 [ ] 마스터가 둘 이상인가(주+백업)            (1.4.17.2)
 [ ] 퇴직·전보자 권한을 회수했나
 [ ] 인증서·계정 만료일을 대장으로 관리하나
 [ ] 인증서 만료 전 갱신 알림 체계가 있나(소요·시점 확인 필요)
 [ ] 남의 아이디·인증서 대리사용을 금지·정식위임으로 대체했나
 [ ] 연구책임자 변경 시 시스템 권한도 이관했나(4.1)
 [ ] 담당 교체 시 계정·진행 것은·미제출 건을 인수인계 문서로 넘겼나

견해: 계정·인증서는 "있다가 없으면 그제야 보이는" 인프라다. 평소엔 대표 계정 하나로도 운영되니 분리·백업의 필요가 안 보이다가, 부재·퇴직·만료라는 단 한 번의 사건에 전부 멈춘다. 비용은 작다(계정 하나 더, 만료일 대장 한 장). 그 작은 비용이 단일 장애점을 없앤다 — 이것이 1.4.17(권한 이원화)과 이 절이 한 몸인 이유다.

1.4.19 데이터를 거꾸로 읽는 사람들 — 점검관·정산관·감사관의 시점

1.4.3.1은 시스템 흔적을 '결백을 증명하는 알리바이'로 보라 했고, 1.4.16은 협약·집행·성과의 숫자 불일치가 정산에서 환수로 이어짐을 추적했다. 그러나 그 흔적을 거꾸로 읽는 사람들 — 점검관·정산관·감사관 — 의 시점은 아직 정면으로 다루지 않았다. 그들은 우리가 입력한 값(얼마·무슨 비목)만 보는 것이 아니라, 시스템이 자동으로 남긴 메타데이터(언제 입력했나·몇 번 고쳤나·어디서 썼나)를 읽어 이상을 검출한다. 이 시점을 알면 무엇이 깃발을 세우는지 미리 보인다.

정직 고지: 점검·감사의 기준·룰·방식은 기관·시점·사업마다 다르고 상당 부분 비공개다(확인 필요). 아래 패턴은 구조를 보이기 위한 가상이며, 실제로 무엇을 어떻게 보는지는 그 사업의 점검·정산 기준이 정한다.

1.4.19.1 그들이 보는 것은 '입력값'이 아니라 '흔적'

시스템은 우리가 의식하지 않아도 다음을 자동으로 남긴다: 접속 시각, 입력·수정 타임스탬프, 정정 횟수·이력, 일괄/개별 입력 패턴, 카드 승인 시각·가맹점, 인건비 입금일. 점검관은 이 메타데이터를 협약(IRIS)·집행(RCMS)·성과(NTIS)·근태·출장과 교차해 "말이 되나"를 본다(1.4.9 데이터 연계의 적대적 활용).

핵심 감각: 값은 우리가 채우지만 흔적은 시스템이 채운다. 그래서 값은 꾸며도 흔적은 꾸미기 어렵다 — 거꾸로 읽는 사람은 값보다 흔적의 '자연스러움'을 본다.

1.4.19.2 이상신호 카탈로그 — 무엇이 깃발을 세우나(가상)

(전부 가상 패턴. 실제 점검 룰은 비공개·시점 의존 — 확인 필요.)

이 패턴들의 공통점: 어느 것도 단일 값으로는 부정이 아니다. 거꾸로 읽는 사람은 값들의 관계와 시각에서 이상을 본다.

1.4.19.3 같은 데이터, 알리바이가 되기도 무기가 되기도

1.4.3.1의 뒷면이 여기 있다. 평소 정합하게 그때그때 입력하면 메타데이터가 결백을 자동 증명한다. 그러나 어긋나거나 막바지에 몰아치면 같은 데이터가 검사의 무기가 된다 — 마감 직전 일괄 입력의 타임스탬프가 그대로 "평소 관리 안 했다"의 증거가 된다.

견해: "안 걸린다"는 가정은 메타데이터 앞에서 틀린다(1.4.6.1). 점검관은 우리가 채운 값보다 시스템이 채운 흔적을 본다는 사실이, 정직을 가장 쉬운 길로 만든다.

1.4.19.4 적대적 점검을 견디는 습관 — 점검표

 흔적이 처음부터 자연스럽게 쌓이게 하는 습관
 [ ] 집행과 등록을 같은 날에 묶는다(1.4.13.2)
 [ ] 사용목적을 과제 활동과 구체적으로 연결해 적는다(1.4.13.1)
 [ ] 정정은 최소화하고, 불가피하면 사유를 메모로 남긴다
 [ ] 예외·애매한 집행은 사전 질의하고 근거를 보관한다(4.2)
 [ ] 카드는 연구 목적·장소와 정합하게 쓴다
 [ ] 인건비·참여율은 실제 투입과 일치시킨다(4.3)

견해: 적대적 점검을 통과하는 비결은 '잘 둘러대기'가 아니라 흔적이 애초에 자연스럽게 쌓이게 하는 것이다. 그때그때의 작은 규율이, 나중에 거꾸로 읽혀도 일관되게 결백을 말하는 데이터를 만든다.

1.4.20 시스템 밖과의 경계 — 무엇을 시스템이 대신 안 해주나

1.4.9는 IRIS·RCMS·NTIS가 서로 데이터를 주고받는 '시스템 사이'의 인터페이스를 그렸다. 그러나 실무에서 더 자주 사고가 나는 경계는 시스템과 시스템 밖 실세계 사이다 — 은행·인증기관·카드사·공인시험기관·세무. 시스템은 기록·검증을 하지만, 계좌를 트고 인증서를 발급하고 시험성적서를 끊는 실물·법적 행위는 시스템 밖 외부기관이 한다. 이 경계를 모르면 "시스템엔 다 넣었는데 정작 일이 안 되는" 사고가 난다.

정직 고지: 아래 외부기관 절차·소요(리드타임)는 기관·시점에 따라 다르다(확인 필요). 수치는 자릿수 감각용 가상이다.

1.4.20.1 시스템이 끝나는 자리 — 손이 외부로 넘어가는 경계

시스템 화면에서 '입력·연계·검증'은 끝나지만, 그 입력이 가리키는 실물은 외부에서 만들어진다.

핵심: 시스템은 이 결과물을 연계·기록·검증하지만 만들어 주지는 않는다(1.4.15의 "회사에 원래 있는 서류"가 아닌 '발급에 시간 걸리는 절반'이 바로 이 외부 경계다).

1.4.20.2 경계마다 리드타임이 있다 — 시스템 마감 ≠ 외부 처리(가상)

함의: 시스템 안 작업은 끝냈는데 외부 리드타임을 계산에 안 넣으면 마감·집행·산출물이 줄줄이 밀린다. 시스템 마감일만 보고 역산하면 늦는다.

1.4.20.3 경계에서 나는 사고 패턴

• 카드 발급 지연: 협약은 됐는데 연구비카드가 안 나와 초기 집행을 못 한다(1.4.5).
• 인증서 만료: 다 입력하고 제출 단계에서 인증서가 만료라 막힌다(1.4.18.1의 사고가 정확히 이 경계).
• 공인시험 예약 밀림: 최종연도에 공인시험을 잡으려는데 예약이 밀려 성적서를 못 끊어 산출물이 빈다(필수산출물 미달은 1.3 영역).

공통점: 세 사고 모두 시스템 안에서는 아무 문제가 없었다. 사고는 시스템이 끝나는 자리, 외부 리드타임을 빠뜨린 경계에서 났다.

1.4.20.4 경계를 미리 당겨 두기 — 견해·체크

 외부 경계 관리 — 리드타임이 긴 것부터 선조치
 [ ] 인증서·기관등록·연구소 인정 → 공고가 뜨기 전에(1.4.15)
 [ ] 연구비카드·전용계좌 → 선정 직후 즉시 발급·연계(1.4.5)
 [ ] 공인시험 → 연차·예산 계획에 일정·비용을 박고 미리 예약(1.3·3.4 영역)
 [ ] 외부 의존 항목을 목록화 → 각 리드타임 확인 → 시스템 마감에서 역산해 착수일 고정

견해: 시스템 마감만 보면 늦는다. 실질 마감은 '외부 리드타임을 더한 마감'이다. 1.4의 모든 D-day 타임라인(1.4.2.1·1.4.11)이 '시스템 안의 여유'를 말한다면, 이 절은 '시스템 밖의 여유'를 더한다 — 둘 다 점검해야 사고가 안 난다.

1.4.7 이 장의 요약 — 다음으로

• 시스템은 IRIS(신청·관리)·RCMS(연구비)·NTIS(성과·정보)로 분업되며, 생애주기 단계마다 쓰는 곳이 다르다(1.4.1).
• 사전 등록·인증을 미리 끝내고, 신청은 마감 며칠 전에 낸다(1.4.2.1).
• RCMS·연구비카드의 통제는 불편하지만 우리의 결백을 자동 증명한다(1.4.3.1).
• NTIS는 성과 등록 창구이자 기획 전 정찰 무기다(1.4.4.1).
• 사내 역할(신청·연구비·성과)을 분리하고, 데이터 교차검증을 의식해 정직하게(1.4.5.1, 1.4.6).
• 처음 진입하는 기관은 개인·기관 두 줄기의 회원가입·기관등록·인증·연구자 프로필을 공고 전에 0에서 세워 둔다 — 기관 등록 승인은 시간이 걸려 마감 직전엔 늦는다(1.4.15).
• IRIS 신청은 정해진 입력 흐름을 타며, 컨소시엄은 타 기관 입력 병목을 미리 친다(1.4.8).
• 시스템 간 데이터가 연계되므로 한 곳을 정확히 입력하고, 자주 나는 오류는 여유 일정·사전 준비로 예방한다(1.4.9, 1.4.10).
• IRIS(협약)·RCMS(집행)·NTIS(성과)가 어긋난 채 두면 그 간극이 정산에서 불인정·환수가 된다 — 비목전용·참여변경을 사전에 IRIS로 흡수해 세 시스템을 정합시킨다(1.4.16).

제1부(제도·시스템 기반)를 마친다. 이제 제2부(2.1~2.4)에서 수행 주체를 연구기관·대기업·중소기업으로 갈라 각자의 길을 그린다.