Microsoft Forms로 사내 신청·의뢰 접수 창구 만들기 ── 메일과 말로 오는 의뢰를 폼으로 모으기

「서버 계정 만들어 주세요」는 메일로 오고, 「프린터 상태가 이상하니 한번 봐 주세요」는 복도에서 마주치며 말로 부탁받고, 「이 청구서 처리 부탁드립니다」는 책상에 스티커 메모로 붙어 있습니다. IT나 총무·경리처럼 사내 의뢰를 받는 부서로부터, 이런 상태를 어떻게든 하고 싶다는 상담을 자주 받습니다.

의뢰하는 쪽은 「말했으니 해 주겠지」라고 생각하고, 받은 쪽은 기억과 메일함에만 의존합니다. 하필 바쁜 날에 한 건이 빠지고, 「그 건 어떻게 됐나요?」에서야 드러납니다. Microsoft 365를 이미 쓰는 회사라면, 이 문제는 Microsoft Forms를 접수 창구로 두고 Power Automate로 알림과 기록을 자동화하는 「접수 패턴」으로 상당 부분 해결할 수 있습니다. 이 글에서는 폼 설계 실무, 파일 업로드 제약, 접수 흐름의 기본형, Forms만으로 접수할 때 생기는 한계와 목록으로 옮겨 적는 편이 표준이 되는 이유까지 정리합니다. 승인·결재 자체의 설계는 별도 글 「Power Automate로 승인 흐름 만들기 ── 종이와 메일의 품의·신청을 전자화하기」가 중심이므로, 이 글은 「접수」에만 초점을 맞춥니다.

대상 독자와 전제 환경

• 대상 독자: IT·총무·경리 등, 사내에서 의뢰나 신청을 받는 쪽의 담당자입니다. Power Automate를 다뤄 본 적이 없다는 전제로 썼습니다.
• 전제 환경: Microsoft 365를 도입했고 Microsoft Forms와 SharePoint를 쓸 수 있을 것. 흐름을 만들려면 Power Automate를 쓸 수 있는 라이선스가 필요하지만, 이 글에서 쓰는 Forms·SharePoint·Outlook·Teams 커넥터는 모두 표준 커넥터 범위이고 프리미엄 커넥터는 나오지 않습니다(경계 정리는 「Power Automate의 라이선스와 표준·프리미엄 커넥터의 경계」).
• 필요한 권한: 폼을 둘 그룹(팀)의 구성원일 것, 옮겨 적을 SharePoint 사이트에 목록을 만들 수 있을 것. 테넌트 관리자 권한은 필요 없지만, 응답자 이름 기록의 기본값이나 외부 공유 가능 여부는 관리자 설정으로 정해집니다.¹
• 이 글에서 만드는 것: 의뢰를 받는 폼 하나, 접수 대장인 SharePoint 목록 하나, 접수 때 동작하는 클라우드 흐름 한 개입니다.

1. 먼저 결론

• 의뢰 접수 창구는 「입력 형식」과 「기록을 둘 곳」을 세트로 설계합니다. 현실적인 최소 구성은 「Forms로 받기 → Power Automate로 SharePoint 목록에 옮기기 → 알림」입니다.
• 흐름의 기본형은 트리거 「새 응답이 제출되면」과 동작 「응답 세부 정보 가져오기」 두 단계입니다. Forms 커넥터에는 이 트리거 하나·동작 하나(+폼 세부 정보 가져오기)만 있어, 외울 것은 많지 않습니다.²³
• 공개 범위는 조직 내부 한정이 원칙입니다. 「이름 기록」을 켜면 응답자 이름과 메일 주소가 자동으로 남아, 성명·소속을 적게 할 필요가 없습니다. 조직 밖에도 여는 설정에서는 응답이 익명이 되어 누가 냈는지 기록되지 않습니다.⁴
• 파일 업로드 질문은 조직 내부 한정 폼 전용입니다. 질문 하나당 최대 10개 파일, 파일당 한도는 10MB·100MB·1GB 중에서 고르며, 파일은 OneDrive for Business에 저장됩니다.⁵
• Forms는 접수 창구 전용으로 역할을 나누는 것이 오래 가는 요령입니다. 제출 후 수정이나 진행 확인 기능은 없고, 응답 목록에도 상태 관리 장치가 없으므로 대장은 SharePoint 목록 쪽에 둡니다.⁶
• 응답 수 한도는 회사·학교 계정에서 최대 5,000,000건이라 사내 이용에서는 사실상 제한이 없지만, 50,000건을 넘으면 요약 그래프나 개별 응답 보기를 쓸 수 없습니다. 한도보다 먼저 「목록 관리가 약하다」는 점이 벽에 됩니다.⁷
• 조직 밖에서 받을 때 첨부가 필요하다, 건수가 많아 핵심 시스템과 연결하고 싶다, 진행 상황을 의뢰자에게 공개하고 싶다 ── 이 지점부터 Forms가 감당하는 범위를 넘기기 시작합니다. 구분은 7장의 판단표에 모았습니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 23건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 메일·구두 의뢰의 무엇이 문제인가

메일과 말로 의뢰를 받는 운영의 문제는, 담당자가 아무리 애써도 풀리지 않는 구조에 있습니다.

• 누락이 구조적으로 생깁니다. 의뢰가 받은 편지함·채팅·말·스티커 메모처럼 서로 다른 경로로 들어오므로 「전체 목록」이 어디에도 없습니다. 한 건도 빠뜨리지 않는 일을 개인의 기억력에 걸고 있는 상태입니다.
• 형식이 제각각이라 주고받기가 늘어납니다. 「PC 설정 부탁드립니다」라는 메일만으로는 대상 PC, 희망일, 이유를 알 수 없어 다시 묻는 주고받기가 생깁니다. 의뢰할 때마다 필요 항목을 떠올려 적는 일은 의뢰하는 쪽에도 부담입니다.
• 상태가 보이지 않아 「말했다, 안 했다」가 됩니다. 의뢰자 쪽에서는 접수됐는지, 착수했는지, 언제 끝나는지가 보이지 않습니다. 담당자가 「듣지 못했습니다」라고 하면 진실 공방이 됩니다. 독촉과 확인 대화 자체가 양쪽 시간을 깎습니다.
• 집계할 수 없습니다. 한 달에 몇 건의 의뢰가 있고 어디에 시간을 썼는지 데이터가 남지 않으므로, 「사람이 부족하다」「이 시스템은 문의가 너무 많다」는 이야기를 숫자로 보여 줄 수 없습니다.

이런 문제는 「의뢰 입구를 하나로 두고, 필요 항목을 정해진 형식으로 받고, 받는 순간에 기록과 알림이 남는다」는 장치로 바꾸면 한꺼번에 해소 쪽으로 갑니다. Forms와 Power Automate를 쓰는 이유는, Microsoft 365를 이미 쓰고 있다면 이 장치를 추가 비용 없이 만들 수 있는 경우가 많기 때문입니다(이 글에서 쓰는 Forms·SharePoint·Outlook·Teams 각 커넥터는 표준 커넥터 범위입니다. 라이선스 사고방식은 「Power Automate의 라이선스와 표준·프리미엄 커넥터의 경계」에서 정리합니다).

3. 폼 설계 실무

질문은 「선택하게 하기」를 기본으로 둡니다

폼 설계의 목표는, 의뢰자가 헤매지 않고 낼 수 있고, 받은 쪽이 되묻지 않고 움직일 정보가 갖춰지는 것입니다. 원칙은 「선택지로 받고, 텍스트는 최소한」입니다.

• 의뢰 종류는 선택지로 둡니다. 「계정 만들기/PC·주변 기기/소프트웨어 도입/기타」처럼, 나중에 집계와 흐름 분기에 쓸 축을 선택지로 확정합니다.
• 기한은 날짜 질문으로 받습니다. 「가능한 빨리」「이번 주 안」 같은 흔들림을 없애고, 흐름 쪽에서 미리 알림에도 쓸 수 있게 됩니다(영업일과 마감일 처리는 「Power Automate의 정기 실행 흐름과 영업일 설계」에서 다룹니다).
• 자유 서술은 「보충」 한 문항으로 모으는 것이 기준입니다. 여기에 실무상 주의가 하나 있습니다. 한 줄 텍스트(짧은 대답)에 255자를 넘는 입력이 있으면, 흐름이 돌기도 하고 안 돌기도 하는 알려진 문제가 있습니다. 긴 글이 들어갈 수 있는 질문은 처음부터 「긴 대답」(여러 줄 텍스트)으로 둡니다.⁸

그리고 「너무 많이 적게 하지 않는」 일입니다. 접수 폼의 역할은 의뢰를 빠짐없이 붙잡는 것이지, 그 자리에서 모든 정보를 긁어 모으는 것이 아닙니다. 질문이 많은 폼은 말·메일로 되돌아가게 만듭니다. 자세한 내용 확인이 필요한 안건은 접수 뒤 담당자가 연락한다는 전제로, 폼은 몇 분이면 낼 수 있는 수준으로 줄입니다.

분기로 「관계없는 질문」을 보여 주지 않습니다

의뢰 종류에 따라 물어야 할 것이 다르면 분기(branching)를 씁니다. 선택지 답에 따라 다음에 보여 줄 질문이나 섹션을 바꿀 수 있어, 「계정 만들기면 대상 시스템과 권한을, 기기 고장이면 자산 번호와 증상을」처럼 응답자에게는 관련 있는 질문만 보여 줄 수 있습니다. 분기는 뒤쪽 질문으로만 건너뛸 수 있고(앞 질문으로는 되돌릴 수 없으므로), 공통 질문을 앞쪽에, 종류별 질문은 섹션으로 나눠 뒤쪽에 두는 구성이 짜기 쉽습니다.⁹

공개 범위와 응답자 정보 ── 조직 내부 한정과 익명의 차이

Forms 공개 범위는 세 종류입니다.⁴

사내 신청·의뢰 접수 창구는 조직 내부 한정이 원칙입니다. 이유는 세 가지입니다.

1. 「누가 냈는지」를 적게 하지 않아도 됩니다. 「이름 기록」을 켜면 응답자 이름과 메일 주소가 응답에 자동으로 붙습니다. 성명·소속·연락처처럼 「매번 같은 것을 적는」 질문을 통째로 빼낼 수 있습니다.⁴
2. 한 사람당 한 번 제한이나 파일 업로드처럼, 조직 내부 한정에서만 쓰는 기능이 있습니다. 「한 사람당 하나의 응답」도 조직 내부 한정일 때만 설정할 수 있습니다.⁴
3. 흐름에서 의뢰자에게 회신할 수 있습니다. 응답 세부 정보에 응답자 메일 주소(Responders’ Email)가 들어가므로, 접수 완료 메일을 그대로 보낼 수 있습니다(5장). 익명 폼에서는 이것이 되지 않습니다.¹⁰

참고로, 조직 전체 기본값으로 응답자 이름을 기록할지는 Microsoft 365 관리 센터의 Forms 설정(「기본적으로 이름 기록」)에서 관리자가 제어할 수 있습니다. 외부 공유(조직 밖 응답 요청) 자체를 테넌트에서 허용할지도 같은 화면의 설정입니다. 회사 정책으로 「사내 설문은 익명이 기본」과 같은 규칙이 있다면 여기도 확인해 둡니다.¹

그래도 조직 밖에 열어야 할 때 무엇을 잃는지도 정리해 둡니다.

• 누가 냈는지 기록되지 않습니다. 조직 밖에도 연 폼의 응답은 익명이 되고, 응답자는 로그인하지 않고 제출할 수 있습니다.¹¹ 사칭도 중복 제출도 폼 쪽에서는 막지 못합니다. 「한 사람당 하나의 응답」 제한도 조직 내부 한정에서만 쓰므로, 같은 사람이 몇 번이든 보낼 수 있습니다.⁴
• 첨부를 받을 수 없습니다. 파일 업로드 질문은 조직 내부 한정 폼 전용입니다.⁵
• 흐름에서 의뢰자에게 회신할 수 없습니다. 응답자 메일 주소(Responders’ Email)를 얻을 수 없어, 접수 완료 메일 자동 회신처럼 효과가 큰 장치를 쓸 수 없습니다(메일 주소를 자유 서술로 적게 하는 운영은, 받는 사람 오타가 곧 도착하지 않는 메일이 됩니다).
• 애초에 허용되지 않은 경우도 있습니다. 외부 공유는 테넌트 관리자 설정으로 막을 수 있어, 링크를 나눠 줘도 응답하지 못하는 사고가 납니다. 미리 관리자에게 확인해 주세요.¹

조직 밖을 대상으로 할 때는 「건수가 적고, 첨부도 본인 확인도 필요 없는 설문 수준의 접수」까지가 안전한 범위입니다. 그것을 넘으면 7장 판단표대로 웹 폼 쪽 설계로 바꿉니다.

개인 폼으로 두지 않기 ── 만든 사람의 퇴사에 대비합니다

놓치기 쉽지만 중요한 논점입니다. 개인이 만든 폼은 그 사람 계정에 묶이고, 퇴사 등으로 계정이 테넌트에서 삭제되면 계정 관련 데이터는 삭제 후 30일 뒤에 사라집니다.¹¹ 접수 폼은 업무의 입구이므로 담당자 개인의 소유로 두지 말고, 그룹(팀) 폼으로 만들거나, 이동·퇴사 때 소유권을 넘기는 운영을 정해 둡니다.⁸

한 가지, 흐름 쪽 주의가 있습니다. 그룹 폼은 Power Automate 트리거의 폼 ID 목록에 나타나지 않으므로, 폼 편집 화면 URL의 FormId= 이후 값을 복사해 폼 ID로 직접 넣어야 합니다.³ 한 단계가 늘지만, 특정인에게 묶이는 일을 피하는 쪽이 이득이 큽니다.

4. 파일 업로드 사양과 제약

「견적서 PDF를 붙여 구매 신청」「오류 화면 스크린샷을 붙여 장애 보고」처럼, 의뢰에 첨부 파일이 따라오는 경우는 많습니다. Forms의 파일 업로드 질문 사양은 정확히 잡아 둘 필요가 있습니다.⁵

• 조직 내부 한정 폼 전용입니다. 공개 범위가 「내 조직의 사용자만 응답할 수 있음」 또는 「조직 내 특정 사용자만 응답할 수 있음」일 때만 추가할 수 있고, 조직 밖에도 연 폼에서는 쓸 수 없습니다. 즉 「외부 거래처가 첨부를 붙여 신청하게 한다」는 용도에는 Forms를 쓸 수 없습니다.
• 질문 하나당 최대 10개 파일까지 받으며, 파일 하나 크기 한도는 10MB·100MB·1GB 중에서 고릅니다.
• 파일 종류를 제한할 수 있습니다. Word·Excel·PowerPoint·PDF·이미지·동영상·음성 중에서 허용할 종류를 고를 수 있어, 「견적서는 PDF만」처럼 받을 수 있습니다.
• 저장 위치는 폼 소유자에 따라 달라집니다. 개인 폼이면 만든 사람의 OneDrive for Business 「앱 > Microsoft Forms > (폼 이름) > (질문 이름)」 폴더, 3장에서 추천한 그룹 폼이면 그룹의 SharePoint 사이트에, 응답자가 올린 파일이 쌓입니다.

흐름에서 업로드 파일을 다룰 때는 한 단계가 더 있습니다. 「응답 세부 정보 가져오기」가 돌려주는 업로드 질문의 답은 파일 이름이나 ID를 담은 JSON 문자열이므로, 「JSON 구문 분석(Parse JSON)」에 스키마를 주고 분해한 뒤 first(body('Parse_JSON'))?['id'] 같은 식으로 파일 ID를 꺼내 파일 가져오기 동작에 넘깁니다.¹⁰

스키마를 만드는 방법은, 공식 절차대로 실제 출력에서 만드는 것이 확실합니다. ① 흐름을 저장하고 테스트 실행한 뒤 폼에서 파일을 하나 업로드한다 → ② 실행 기록에서 「응답 세부 정보 가져오기」를 열고 그 업로드 질문의 출력을 복사한다 → ③ 「JSON 구문 분석」 동작의 「샘플에서 생성」에 붙여 넣는다, 의 세 단계입니다.¹⁰

손으로 쓰고 싶다면 쓰는 속성만 선언한 최소 형태로 충분합니다(선언하지 않은 속성이 와도 JSON 구문 분석은 통과합니다). 공유 링크를 만드는 데 필요한 것은 파일 ID뿐이므로, 실질적으로는 이것만이면 됩니다.

{
    "type": "array",
    "items": {
        "type": "object",
        "properties": {
            "id":   { "type": "string" },
            "name": { "type": "string" }
        },
        "required": [ "id" ]
    }
}

여기서 가장 주의할 점은 답이 배열로 돌아온다는 것입니다. 공식 식이 first(body('Parse_JSON'))?['id']처럼 첫 요소를 꺼내는 형태인 이유가 여기 있습니다.¹⁰ 참고로 first(...)는 파일이 하나라는 전제의 쓰기입니다. 여러 파일을 허용한 질문에서는 답이 파일별 객체를 나열한 배열로 오므로, 구문 분석 결과를 Apply to each로 돌며 파일마다 가져옵니다(첨부가 하나면 충분한 의뢰라면, 질문 쪽 한도를 1파일로 두는 것이 쉽습니다). 또한 파일 가져오기에 쓰는 커넥터는 위의 저장 위치에 맞춥니다. 개인 폼이면 OneDrive for Business 커넥터, 그룹 폼이면 저장 위치가 그룹 SharePoint 사이트이므로 SharePoint 커넥터로 그 사이트를 지정해 가져옵니다. 그룹 폼인데 OneDrive 커넥터로 파일을 찾아 보이지 않는다, 는 조합 실수가 전형적인 막힘입니다.

받은 파일을 승인 요청에 첨부해 돌릴 때는, 파일 콘텐츠를 바이너리로 첨부 필드에 넘깁니다.¹² 다만 승인 동작이 메일에 첨부할 수 있는 파일은 5MB까지이고, 그것을 넘는 첨부는 승인자가 Power Automate 포털의 승인 목록에서 확인하는 움직임이 됩니다.⁸ 큰 파일은 첨부로 돌리지 말고 SharePoint에 저장한 뒤 링크를 돌리는 편이 확실합니다.

5. Power Automate로 접수를 움직이기

기본형은 2단계+출구 3개입니다

Forms는 응답이 도착해도 기본값으로는 아무에게도 알리지 않습니다(폼 소유자용 알림 설정은 있지만, 받는 사람이나 문구를 고를 수는 없습니다¹⁰). 접수를 업무로 돌리는 일은 Power Automate의 몫입니다. 흐름의 기본형은 트리거 「새 응답이 제출되면」에서 폼을 지정하고, 이어서 「응답 세부 정보 가져오기」로 각 질문의 답을 동적 콘텐츠로 꺼내는 두 단계입니다.² 그다음 출구는 「대장에 기록」「의뢰자에게 접수 알림」「담당 팀에 알림」 세 가지입니다.

flowchart TD
    Submit[의뢰자가 Forms에서 제출<br/>조직 내부 한정·로그인 완료] --> Trigger[새 응답이 제출되면<br/>클라우드 흐름 시작]
    Trigger --> Details[응답 세부 정보 가져오기<br/>답을 동적 콘텐츠화]
    Details --> Record[SharePoint 목록에 항목 만들기<br/>상태: 접수됨]
    Record --> Ack[의뢰자에게 접수 완료 메일<br/>응답 내용 사본을 넣기]
    Record --> Team[담당 팀 Teams 채널에 게시]
    Record --> Need{승인이 필요한 종류?}
    Need -- 예 --> Approval[승인 흐름으로<br/>시작 후 승인 대기]
    Need -- 아니요 --> Work[담당자를 배정하고 대응]
    Approval --> Back[결과를 목록에 다시 기록]
    Work --> Back2[대응 상황을 상태 열에서 갱신]

개념도와 실제 화면 사이가 가장 헤매는 지점이므로, 이 그림을 그대로 만들 때의 클릭 순서도 적어 둡니다. 옮겨 적을 SharePoint 목록은 먼저 만들어 두세요.

1. Power Automate 포털을 열고, 왼쪽 메뉴 「만들기」에서 「자동화된 클라우드 흐름」을 고릅니다. 흐름 이름을 입력합니다.
2. 트리거 검색란에 「Forms」를 넣고 「새 응답이 제출되면」을 고릅니다.²
3. 트리거의 「폼 ID」에서 폼을 고릅니다. 그룹 폼은 목록에 나오지 않으므로, 폼 편집 화면 URL의 FormId= 이후를 붙여 넣습니다(3장).³
4. 「새 단계」→ 검색란에 「Forms」→ 동작 「응답 세부 정보 가져오기」. 여기에서도 같은 폼을 지정하고, 「응답 ID」에는 트리거의 동적 콘텐츠 「응답 ID」를 넣습니다(자동으로 들어가 있는 경우도 있습니다).²
5. 「새 단계」→ 「SharePoint」→ 「항목 만들기」. 사이트 주소와 목록 이름을 고르고, 각 열에 「응답 세부 정보 가져오기」의 동적 콘텐츠(각 질문의 답)를 할당합니다. 상태 열에는 접수됨 같은 고정 값을 넣어 둡니다.
6. 「새 단계」→ 「Office 365 Outlook」→ 「이메일 보내기 (V2)」. 「받는 사람」에 동적 콘텐츠 Responders’ Email을 넣고, 본문에 응답 내용 사본과 대략의 일수를 적습니다.¹⁰
7. 「새 단계」→ 「Microsoft Teams」→ 「채팅 또는 채널에 메시지 게시」. 담당 팀의 팀과 채널을 고르고, 종류·기한·의뢰자와 목록 항목 링크를 올립니다.
8. 오른쪽 위 「저장」→ 「테스트」로 수동 테스트를 시작하고, 실제로 폼에서 한 건을 제출합니다. 각 단계의 입력·출력을 열어 값이 예상대로 들어갔는지 확인합니다.

승인으로 가는 분기는 이 다음입니다. 우선 위의 1〜8만으로 「한 건 내면 대장에 올라가고, 의뢰자에게 메일이 가고, 팀에 알림이 뜬다」까지 통과시킨 뒤 조건 분기를 겹치는 편이 안전합니다.

SharePoint 목록으로 옮기기 ── 접수 대장을 만듭니다

접수한 의뢰는 흐름의 맨 앞에서 SharePoint 목록에 한 행씩 옮깁니다. 목록에는 응답 사본에 더해, 폼에는 없는 「관리용 열」을 두는 것이 핵심입니다.

의뢰자에게 추가로 물은 내용이나 경과는 메일에 흩뿌리지 말고 이 목록(또는 목록 항목에 묶인 Teams 스레드)으로 모으면, 「말했다, 안 했다」의 기록이 한곳에 모입니다. 보기를 「상태=미완료」로 만들면 아침 회의에서 그대로 쓸 대응 목록이 됩니다. Excel로 옮기는 템플릿도 있지만¹⁰, 여러 사람이 상태를 계속 갱신하는 대장에는 보기·열 형식·버전 기록을 가진 목록이 맞습니다. Excel 대장에서 목록으로 옮기는 사고방식은 「Excel 대장을 SharePoint 목록으로 바꾸기 ── 공유·이력·흐름 연동으로 「대장이 깨지는」 일을 끝내기」에 정리했습니다.

접수 알림 ── 「도착했습니다」를 첫 1분에 돌려줍니다

메일 의뢰와 체감이 가장 다른 지점이 여기입니다. 흐름에서 알림을 두 종류 냅니다.

• 의뢰자에게 보내는 접수 완료 메일. 조직 내부 한정 폼이면, 응답 세부 정보에 들어 있는 응답자 메일 주소(Responders’ Email)로 Outlook 커넥터에서 바로 보낼 수 있습니다.¹⁰ 본문에는 응답 내용 사본과 「영업일 3일 이내에 담당자가 연락합니다」 같은 대략의 기한을 넣습니다. 의뢰자가 독촉하고 싶어지는 원인 대부분은 「도착했는지조차 모른다」는 것이라, 이 한 통으로 문의가 꽤 줄어듭니다. Forms 자체에도 응답자 확인 메일 설정은 있지만, 문구를 업무에 맞출 수 있는 것은 흐름에서 보내는 방식입니다.¹⁰
• 담당 팀에 보내는 Teams 알림. 개인 메일로 보내면 다시 특정인에게 묶이므로, 담당 팀 채널에 게시합니다. 종류·기한·의뢰자와 목록 항목 링크를 올려 두면, 채널이 그대로 「새 의뢰 받은 편지함」이 됩니다.

승인으로 연결하기

「소프트웨어 구매는 상급자 승인이 필요하다」와 같은 종류는, 접수 흐름에서 승인 동작(시작 후 승인 대기)으로 연결합니다. Forms 응답 내용을 승인 요청에 넣는 템플릿도 마련되어 있어, 승인 결과에 따라 의뢰자에게 결과 메일을 돌려주는 형태까지 한 번에 짤 수 있습니다.¹⁰ 승인 종류, 시간 제한과 독촉, 승인 기록을 남기는 방법 같은 설계 논점은 「Power Automate로 승인 흐름 만들기 ── 종이와 메일의 품의·신청을 전자화하기」에서 자세히 다루므로 그쪽을 봐 주세요. 접수 흐름이 안정적으로 돌기 시작하면, 흐름의 공동 소유자 설정과 오류 시 알림도 일찍 넣어 둡니다(오류 처리 설계는 「Power Automate의 오류 처리와 재시도 설계」를 참고).

6. Forms 단독의 한계 ── 그래서 목록으로 옮기는 편이 표준입니다

Forms만으로 접수를 끝내려 하면 다음 벽에 부딪힙니다.

• 제출 뒤 상태가 보이지 않습니다. 기본값에서는 응답자가 제출한 내용을 나중에 고칠 수 없습니다. 만든 사람 쪽에서 응답자 본인이 답을 저장·편집하도록 허용하는 설정이 제공된 환경도 있지만, 그것은 응답 내용을 고치는 수단에 그칩니다. 폼 설정으로 준비된 것은 접수 시작·종료 시각이나 한 사람당 한 번 제한 등이고⁶, 자기 의뢰가 지금 어떤 상태인지(접수됨·대응 중·완료)를 확인하는 화면은 없습니다. 「낸 다음」을 받쳐 주는 기능은 없다고 보는 편이 실제에 맞습니다. 편집을 허용하지 않은 환경에서 수정이 「한 번 더 제출」로 이뤄지면, 어느 쪽이 최신인지는 받은 쪽이 판단하게 됩니다.
• 응답 목록의 관리 기능이 약합니다. Forms 응답 화면은 집계와 열람용이지, 상태 열도 담당자도 둘 수 없고 「미대응만 표시」도 되지 않습니다. 접수 관리에 필요한 것은 목록을 「갱신해 가는」 기능인데, 그것은 Forms가 맡는 범위 밖입니다.
• 한도는 건수보다 기능 면에서 먼저 옵니다. 회사·학교 계정 폼은 폼당 최대 5,000,000건까지 응답을 받고, 질문은 200개, 텍스트 답은 문항당 4,000자까지입니다(이 밖에, 한 번의 응답당 텍스트 답 합계 200,000자라는 제한도 있지만, 이는 한 응답자가 한 번 제출 안에서 닿는 종류의 한도이지, 응답이 쌓여 닿는 것이 아닙니다). 실무에서 먼저 걸리는 것은 건수가 아니라 기능 제한으로, 50,000건을 넘으면 요약 그래프·개별 응답 보기·인쇄 등을 쓸 수 없고 CSV 내보내기로만 가져오게 됩니다.⁷ 사내 접수에서 건수 한도에 닿는 일은 거의 없지만, 오래 쓰는 폼에서는 「Forms에 쌓아 둔다」는 설계 자체가 부담이 됩니다. 응답이 늘면 내보낸 뒤 응답을 지우라는 안내가 나와 있고¹¹, 어느 쪽이든 이력을 둘 곳은 따로 필요합니다.

즉 Forms는 「입력 형식을 나눠 주는 도구」로는 뛰어나지만, 「받은 뒤를 관리하는 도구」는 아닙니다. Forms는 접수 창구, 대장과 상태 관리는 SharePoint 목록, 알림과 연동은 Power Automate라는 역할 나눔이, 각자의 잘하는 쪽에 맞는 표준입니다.

7. 어디까지 Forms로 받을 것인가 ── 판단표

접수 창구의 도구 구성에는 단계가 있습니다. 기준을 표로 둡니다.

판단의 감각은 「의뢰자가 사내에 있는 동안은 Forms로 버틸 수 있고, 조직 밖이 끼면 설계를 바꾼다」입니다. 조직 밖과의 종이·FAX·메일 첨부 주고받기를 접수 창구째 다시 보는 이야기는 「FAX 수주를 웹으로 옮기려면 ── 병행 운영 기간 설계와 단계 이행 실무」와 「메일로 도착하는 발주서·청구서 PDF를 Power Automate로 자동 처리하기 ── 저장·분류·알림·읽기 설계」에서 다룹니다.

8. 정리

메일과 말로 오는 의뢰가 힘든 이유는, 의뢰 전량이 어디에도 없고, 형식이 맞지 않고, 상태가 보이지 않기 때문이었습니다. Microsoft Forms로 입구를 하나로 두고, 조직 내부 한정+이름 기록으로 「누가 냈는지」를 자동화하고, Power Automate로 접수 순간에 대장 기록과 접수 알림을 돌려줍니다. 이 패턴만으로 「그 건 어떻게 됐나요?」라는 주고받기는 꽤 사라집니다.

설계의 핵심은 선택지 중심으로 너무 많이 적게 하지 않는 폼, 조직 내부 한정과 익명의 차이를 이해하는 것, 파일 업로드 제약(조직 내부만·최대 10파일·파일당 최대 1GB)을 파악하는 것, 그리고 Forms에 대장을 기대하지 않는 것입니다. Forms는 접수 창구, 목록이 대장, 흐름이 알림과 연동. 이 역할 나눔을 지키는 접수는 담당자가 바뀌어도 오래 돌아갑니다. 그리고 조직 밖 접수나 첨부, 건수와 연동 요건이 부풀어 오면, 그때가 웹 폼 개발이나 전용 시스템을 검토할 시점입니다.

다음 한 걸음 ── 첫 하나를 만들 때의 점검 목록

처음부터 모든 의뢰를 한 폼에 모으려 하면 질문이 늘어 아무도 쓰지 않게 됩니다. 먼저 한 종류만 통과시키세요.

• 대상으로 삼을 의뢰를 한 종류만 고릅니다(건수가 많고 형식이 흔들리는 것이 맞습니다)
• 질문은 5〜10개에 맞춥니다. 의뢰 종류·기한·보충 세 가지는 반드시 넣습니다
• 자유 서술은 「긴 대답」으로 둡니다(한 줄 텍스트의 255자 문제를 피하기 위해. 3장)
• 공개 범위를 「조직 내부 한정」으로 두고 「이름 기록」을 켭니다
• 개인 폼이 아니라 그룹(팀) 폼으로 만듭니다
• 옮겨 적을 SharePoint 목록을 먼저 만듭니다. 상태·담당자·대응 메모 세 열은 반드시 둡니다
• 흐름을 「응답 세부 정보 가져오기 → 항목 만들기 → 접수 완료 메일 → Teams 게시」 순으로 짜고, 테스트 실행으로 한 건을 통과시킵니다
• 접수 완료 메일에 「언제까지 무엇이 일어나는지」를 적습니다
• 흐름에 공동 소유자를 한 명 이상 추가합니다(만든 사람이 자리를 비워도 고칠 수 있게)
• 2주 운영하고, 되물음이 생긴 항목을 폼 질문에 더합니다

여기까지 되면 의뢰 종류를 하나씩 늘려 갑니다. 늘리는 것은 폼의 질문이 아니라 종류의 선택지와 분기입니다.

관련 글

• Power Automate로 승인 흐름 만들기 ── 종이와 메일의 품의·신청을 전자화하기
• Excel 대장을 SharePoint 목록으로 바꾸기 ── 공유·이력·흐름 연동으로 「대장이 깨지는」 일을 끝내기
• Power Automate로 업무 자동화하기 ── 클라우드 흐름·데스크톱 흐름의 구분과 오류 처리 설계
• 메일로 도착하는 발주서·청구서 PDF를 Power Automate로 자동 처리하기 ── 저장·분류·알림·읽기 설계

관련 상담 영역

合同会社小村ソフト에서는 Microsoft 365를 살린 사내 업무의 접수·대장·알림 장치 만들기 상담부터, Forms로는 담지 못하는 대외 웹 폼·업무 시스템 개발까지 다룹니다.

• 기술 상담·설계 리뷰
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Microsoft Forms의 파일 업로드 질문은 조직 밖 사람도 쓸 수 있나요?

쓸 수 없습니다. 파일 업로드 질문은 폼 공개 범위를 「내 조직의 사용자만 응답할 수 있음」(또는 조직 내 특정 사용자)으로 둔 경우에만 추가할 수 있고, 조직 밖 응답을 허용하면 이 질문 자체를 쓸 수 없습니다. 올라온 파일은 조직의 OneDrive for Business에 저장되며, 질문 하나당 최대 10개 파일, 파일당 한도는 10MB·100MB·1GB 중에서 고른 값까지입니다. 조직 밖에서 첨부 파일을 받아야 한다면 OneDrive/SharePoint의 파일 요청 기능을 함께 쓰거나, 웹 폼 개발을 검토합니다.

Microsoft Forms 폼은 응답을 몇 건까지 받을 수 있나요?

회사 또는 학교 계정의 폼은 최대 5,000,000건까지 응답을 받습니다(GCC High/DoD 환경은 50,000건). 사내 신청·의뢰 접수에서 이 한도 자체가 문제가 되는 일은 거의 없습니다. 다만 50,000건을 넘으면 요약 그래프 표시나 개별 응답 보기 같은 기능을 쓸 수 없고 CSV 내보내기로만 가져오게 됩니다. 응답 목록에는 상태 관리 기능도 없으므로, 건수와 관계없이 접수한 의뢰는 Power Automate로 SharePoint 목록에 옮겨 대장을 만드는 편이 표준입니다.

폼 응답자가 누구인지 자동으로 남길 수 있나요?

공개 범위를 조직 내부로 한정하면 남길 수 있습니다. 「내 조직의 사용자만 응답할 수 있음」으로 두고 「이름 기록」을 켜면, 응답자 이름과 메일 주소가 응답과 함께 자동으로 남아 성명이나 소속을 따로 적게 할 필요가 없습니다. 한 사람당 한 번으로 제한하는 옵션도 조직 내부 한정일 때만 쓸 수 있습니다. 반대로 「모든 사용자가 응답할 수 있음」으로 두면 응답은 익명이 되어 누가 보냈는지 기록되지 않습니다. 사내 신청·의뢰 접수 창구는 조직 내부 한정이 원칙입니다.

신청 접수 창구는 Forms와 SharePoint 목록 중 어느 쪽으로 만들어야 하나요?

입력하는 사람의 손쉬움을 우선하면 Forms, 대장으로 관리하는 쪽을 우선하면 SharePoint 목록입니다. Forms는 스마트폰에서도 넣기 쉽고 질문 분기나 필수 설정도 간단하지만, 제출 후 수정이나 진행 확인이 안 되고 응답 목록의 관리 기능도 약합니다. 실무에서는 「Forms로 받고 Power Automate로 SharePoint 목록에 옮긴다」는 구성이면 입력의 손쉬움과 대장 관리를 같이 가져갈 수 있습니다. 열이 많은 정형 신청이고 입력자 전원이 목록을 다룰 수 있다면, 목록 폼으로 바로 받는 구성도 선택지입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.