LMS 도입을 결정하고 나면 다음 관문은 업체 접촉입니다. 이때 대부분 견적 요청 메일부터 보냅니다. 그런데 견적서 세 장이 돌아오면 금액이 제각각인데 무엇 때문에 차이가 나는지 알 수 없습니다. 제안요청서(RFP, Request for Proposal)는 원하는 기능을 나열하는 문서가 아니라, 우리 교육 운영이 무엇을 할 수 있어야 하는지를 검증 가능한 문장으로 적어 모든 업체에 똑같이 전달하는 문서입니다. 같은 질문을 받은 제안서라야 같은 축 위에서 비교됩니다. 이 글은 LMS 제안요청서를 처음 쓰는 담당자를 기준으로, 무엇을 어떤 순서로 적는지 정리합니다.
견적을 비교할 수 없는 이유는 요구사항이 없기 때문이다
같은 요청을 받았는데 금액이 두 배 이상 벌어지는 일은 흔합니다. 원인은 대개 업체가 아니라 요청 쪽에 있습니다. "임직원 온라인 교육 시스템이 필요합니다"라는 문장 하나를 받으면, 어떤 업체는 표준 임대형 서비스를 그대로 제안하고 어떤 업체는 인사시스템 연동과 화면 개발까지 포함해 계산합니다. 둘 다 요청에 어긋나지 않습니다. 요청이 그 차이를 구분하지 않았기 때문입니다.
이 상태에서 가장 싼 제안을 고르면, 계약 이후 "그건 범위 밖입니다"라는 말을 반복해서 듣게 됩니다. 추가 개발 견적이 붙고, 일정이 밀리고, 예산 심의를 다시 받아야 합니다. 반대로 요구사항 목록이 먼저 있으면 업체마다 "이 항목은 기본 제공, 이 항목은 별도 개발"이라고 표시해 돌려주므로, 금액 차이의 이유가 그 자리에서 드러납니다.
그래서 제안요청서를 쓰는 시간은 업체를 고르는 시간이 아니라 우리가 무엇을 원하는지 우리 스스로 확정하는 시간입니다. 실제로 요구사항을 적다 보면 내부에서 합의되지 않은 것이 드러납니다. 수료 기준을 부서별로 다르게 갈지, 협력사 인원도 태울지, 기존 수강이력을 어디까지 가져올지 같은 것들입니다. 이 결정을 업체 미팅 자리에서 즉석으로 내리면 그때부터 범위가 흔들립니다.
요구사항은 여섯 갈래로 나눠 적는다
기능만 나열하면 반드시 빠지는 영역이 생깁니다. 공공 소프트웨어 사업에서 요구사항을 기능·성능·인터페이스·데이터·보안 같은 유형으로 나눠 적도록 안내하는 이유도 같습니다. 유형을 먼저 만들어 두면 비어 있는 칸이 눈에 보입니다. LMS 도입에 맞춰 여섯 갈래로 줄이면 아래와 같습니다.
| 유형 | 무엇을 적나 | 빠지면 생기는 문제 |
|---|---|---|
| 기능 | 회원·과정 개설·수강신청·진도·시험·설문·수료 처리·증명서 발급까지 운영 한 바퀴 | 운영 흐름 중간에 수작업 구간이 남는다 |
| 데이터 | 이관 대상과 건수, 보관 기간, 파기 절차, 계약 종료 시 반출 형식 | 과거 이수 이력이 끊겨 증빙이 불가능해진다 |
| 연동 | 인사시스템·통합인증(SSO)·결제·동영상 플랫폼·메일과 문자 발송 | 계정과 명단을 매번 엑셀로 옮기게 된다 |
| 성능·용량 | 동시 접속 규모, 콘텐츠 저장 용량, 영상 트래픽 기준 | 법정교육 마감일에 접속이 몰려 멈춘다 |
| 보안·개인정보 | 관리자 권한 분리, 접근 기록, 암호화, 보유 인증 현황 | 내부 감사와 보안 검토 단계에서 도입이 멈춘다 |
| 운영·지원 | 유지보수 범위, 장애 접수 경로와 대응 기준, 관리자 교육과 매뉴얼 | 담당자가 바뀌면 시스템이 방치된다 |
여섯 칸 중 담당자들이 가장 자주 비워 두는 곳은 데이터와 운영·지원입니다. 둘 다 도입 시점에는 급하지 않고 몇 년 뒤에 문제가 되는 항목이라 그렇습니다. 그런데 이 두 칸이 나중에 가장 비싼 대가를 치릅니다. 기존 시스템에서 넘어오는 경우라면 옮길 데이터의 범위를 먼저 정하는 편이 안전합니다. 이 부분은 쓰던 LMS 갈아타기: 회원·수강이력·수료 데이터 이관 체크리스트에서 항목별로 다뤘습니다.
한 줄을 검증 가능한 문장으로 고친다
요구사항 문서의 품질은 분량이 아니라 문장 단위에서 갈립니다. 판단 기준은 하나입니다. 이 문장으로 나중에 "됐다/안 됐다"를 다툴 일이 없는가. 여지가 있다면 아직 요구사항이 아니라 희망사항입니다.
| 흔한 문장 | 왜 위험한가 | 고친 문장 |
|---|---|---|
| 모바일에서도 학습이 가능해야 함 | 화면만 열려도 충족으로 볼 수 있다 | 학습자 화면은 모바일 브라우저에서 동작하며, 동영상 시청 위치가 PC와 동일하게 이어져야 한다 |
| 수료증을 발급할 수 있어야 함 | 수동 발급도 발급이다 | 과정별로 수료 기준(진도율·평가 점수·출석)을 다르게 설정할 수 있고, 기준 충족 시 자동 발급되며 발급 이력 조회와 재발급이 가능해야 한다 |
| 안정적으로 운영되어야 함 | 측정할 수 없다 | 동시 접속 ○○○명 기준으로 학습 화면이 동작해야 하며, 제안사는 근거 자료를 제안서에 첨부한다 |
| 기존 데이터를 옮겨 주어야 함 | 범위와 책임이 없다 | 이관 대상은 회원 ○○건·수강이력 ○○건·수료 ○○건이며, 이관 후 검증 방법과 오류 처리 책임을 제안서에 기술한다 |
| 필요 시 커스터마이징 지원 | 비용과 절차가 열려 있다 | 계약 범위에 포함되는 화면 수정 범위를 명시하고, 범위를 넘는 요청의 산정 방식과 승인 절차를 기술한다 |
고친 문장들의 공통점은 주체·조건·판정 방법이 들어 있다는 것입니다. 반대로 "지원", "가능", "고려" 같은 단어로 끝나는 문장은 검수 시점에 반드시 해석이 갈립니다. 숫자를 아직 정하지 못했다면 빈칸으로 두더라도 항목 자체는 남겨 두는 편이 낫습니다. 그 빈칸이 내부 협의를 강제합니다.
제안요청서 한 장이 만들어지는 순서
1단계에서 적어야 할 것은 시스템이 아니라 지금의 운영입니다. 연간 몇 개 과정을 여는지, 대상 인원이 몇 명인지, 차수를 나눠 운영하는지, 지금 어느 작업을 엑셀로 하고 있는지를 적습니다. 이 기록이 없으면 요구사항이 남의 회사 이야기가 됩니다. 무엇을 물어봐야 할지 감이 잡히지 않는다면 기업교육 담당자를 위한 LMS 선택 가이드의 체크리스트를 질문지로 삼아도 됩니다.
4단계를 건너뛰는 경우가 많은데, 제안서를 받는 쪽에 필요한 정보이기도 하지만 우리 쪽 준비 상태를 점검하는 장치이기도 합니다. 평가 항목과 배점을 못 적겠다면 아직 무엇이 중요한지 정하지 못한 것이고, 일정을 못 적겠다면 언제 오픈할지 합의되지 않은 것입니다. 예산 범위를 어디까지 공개할지는 조직마다 다르지만, 최소한 내부적으로는 확정한 상태로 발송해야 제안서를 받고 나서 다시 예산을 짜는 일이 없습니다. 예산 항목을 세우는 순서는 교육예산 편성과 집행에 정리돼 있습니다.
자주 빠지는 네 항목
요구사항 표를 다 채우고도 계약 이후에 문제가 되는 항목은 대체로 정해져 있습니다. 발송 전에 이 넷이 문서에 있는지만 따로 확인하세요.
- 유지보수 범위와 대응 기준. 무엇이 무상이고 무엇이 유상인지, 장애를 어디로 접수하고 언제까지 답을 받는지를 적습니다. "유지보수 포함"이라는 한 줄은 범위를 정하지 않은 것과 같습니다.
- 계약 종료 시 데이터 반출. 우리 데이터를 어떤 형식으로 돌려받는지를 계약 전에 정해 둡니다. 이 조항이 없으면 다음 전환에서 협상력이 사라집니다.
- 추가 요청의 처리 방식. 오픈 이후 화면 수정이나 기능 추가 요청은 반드시 생깁니다. 산정 기준과 승인 절차를 미리 적어 두면 그때마다 협상하지 않아도 됩니다.
- 담당 인력과 인수인계. 구축 담당자와 운영 담당자가 다른 경우가 많습니다. 오픈 후 누가 우리 창구인지, 관리자 교육과 매뉴얼이 어디까지 제공되는지를 적습니다.
여기까지 정리했다면 남은 것은 형식입니다. 어떤 시스템을 어떤 방식으로 도입할지 큰 그림을 먼저 맞추고 싶다면 LMS 도입 완전정복 2026에서 의사결정 순서 전체를 볼 수 있습니다.
공공기관이라면 절차가 하나 더 붙는다
민간 기업은 제안요청서를 어떤 형식으로 만들어 몇 개 업체에 보낼지 발주자가 정합니다. 공공기관·학교·지자체 산하기관은 여기에 조달 절차가 더해집니다. 통상 규격에 대한 의견을 받는 사전규격공개를 거쳐 입찰을 공고하고, 제출된 제안서를 정해진 기준에 따라 평가하는 순서로 진행됩니다.
이때 기술과 가격을 어떤 비율로 볼지, 평가 항목과 배점을 어떻게 구성할지, 어떤 계약 방식을 적용할지는 관계 법령과 계약예규, 그리고 각 기관의 내부 규정에 따라 달라집니다. 발행 시점(2026-08) 기준의 일반론으로 판단하지 말고 반드시 소관 계약·조달 부서와 함께 확인하세요. 공공 소프트웨어 사업의 경우 요구사항을 유형별로 상세하게 적도록 안내하는 정부 가이드와 작성 예시가 별도로 배포되어 있으므로, 담당 부서를 통해 최신본을 확보해 양식의 기준으로 삼는 편이 안전합니다.
교육 담당자 입장에서 달라지는 것은 하나 더 있습니다. 공고로 나가는 문서는 나중에 고치기 어렵다는 점입니다. 민간 발주는 미팅에서 보완할 수 있지만, 공고된 규격은 그 문장 그대로 평가와 검수의 기준이 됩니다. 앞의 표 2에서 다룬 문장 교정이 공공 발주에서 더 중요한 이유입니다.
발송 전 마지막 점검
| # | 확인 항목 | 충족 판단 |
|---|---|---|
| 1 | 여섯 유형 중 비어 있는 칸이 없는가 | 데이터·운영지원 칸이 특히 비기 쉽다 |
| 2 | "지원·가능·고려"로 끝나는 문장이 남아 있는가 | 검색해서 전부 다시 쓴다 |
| 3 | 대상 인원과 동시 접속 규모가 숫자로 적혀 있는가 | 추정치라면 근거를 함께 적는다 |
| 4 | 이관할 데이터의 범위와 건수가 적혀 있는가 | 기존 시스템이 있다면 필수 |
| 5 | 평가 항목·일정·제출 형식이 안내되어 있는가 | 없으면 제안서 형식이 제각각이 된다 |
| 6 | 질의응답 창구와 마감이 정해져 있는가 | 답변은 전체 업체에 동일하게 공유 |
제안요청서는 잘 쓸수록 업체를 압박하는 문서가 되는 것이 아니라, 우리 운영을 이해한 제안을 받아오는 문서가 됩니다. 요구사항이 명확하면 업체도 불확실성에 대비한 여유분을 금액에 얹을 이유가 줄어듭니다. 반대로 애매한 요청은 제안서와 견적 모두를 방어적으로 만듭니다.
요구사항을 정리하는 단계에서 "이 기능이 일반적인 LMS에 기본으로 있는 것인지"가 헷갈린다면, 문서를 완성하기 전에 한 번 물어보는 편이 시간을 아낍니다. 맑은소프트는 16년간 교육 시스템을 구축·운영해 왔고, 현재 약 375개 기관의 교육 운영을 지원하고 있습니다. 요구사항 목록을 놓고 어느 항목이 표준 기능이고 어느 항목이 별도 개발인지 확인이 필요하시면 문의하기를 통해 상담을 요청하실 수 있습니다.
