목록으로
업무 생산성 개선을 위한 AI 활용
셀 수 없어서 만들었습니다 — 흩어진 시설민원을 한 곳에 모으고, AI가 담당을 제안하게 하기까지
대장은 있었는데 셀 수가 없었습니다. 개발을 배운 적 없는 시설 담당 직원이 Claude Code에 말로 시켜 포털을 만들었고, 전화·구두·종이 대장으로 흩어지던 시설민원 2,498건이 한 곳에 모였습니다. 웹 민원은 규칙이 먼저 접수안을 만들고 AI가 담당을 제안하며, 확정은 담당자가 합니다. AI에 보내기 전 개인정보를 지우는 코드는 공개했습니다.
🤖 활용 AI 도구
Claude Code(포털 개발), OpenAI gpt-4.1-mini → gpt-6-luna(민원 담당 분야 제안, 10월 27일 교체)
① 어떤 상황에서 AI를 활용했나요?
「천장에서 물이 떨어져요.」
이 한 문장이 어디로 가야 하는지 정하는 게 제 일의 시작입니다. 저는 성균관대학교 자산관리처 관리팀 장상민입니다. 자연과학캠퍼스(수원)와 인문사회과학캠퍼스(서울) 두 곳의 시설을 고치고 공사를 감독합니다. 올해 1월에 들어왔고 개발은 배운 적이 없습니다.
들어와서 처음 막힌 건 고치는 일이 아니라 세는 일이었습니다. 민원은 전화로도 오고 메일로도 오고, 복도에서 마주쳐 말로도 들어옵니다. 두 캠퍼스 모두 수기 민원관리대장은 있었지만 빠진 게 많았습니다. 구두나 전화로 들어온 건은 작업 지시만 하고 대장에 올리지 않았고, 처리하는 쪽에서 따로 정리해 둔 것도 기준이 제각각이었습니다. 지난달에 몇 건이 들어왔는지, 하나 처리하는 데 얼마나 걸렸는지 대답할 수 없었습니다. 대장은 있었는데 셀 수가 없었습니다.
그래서 시설통합포털을 만들었습니다. 학교가 예산을 세워 추진한 사업이 아니고, 학교가 따로 발주하거나 용역을 준 개발비는 없습니다. AI 호출과 서버 비용은 부서가 냅니다. AI 호출 쪽은 코드와 공개 단가로 계산하면 한 달에 1달러가 안 됩니다. 만들고 쓰는 것은 팀장과 처장께 보고해 승인을 받았고, 개인정보처리방침은 자산관리처 명의로 공개돼 있습니다. 이 공모전에 내는 것도 보고했습니다.
AI는 두 군데에 썼습니다. 먼저 흩어진 민원을 한 곳에 모으는 포털 자체를 Claude Code에 말로 시켜 만들었습니다(만든 AI). 그다음 그 포털에 민원 글을 읽고 담당을 제안하는 AI를 붙였습니다(읽는 AI). 둘은 하는 일이 달라 따로 적습니다.
② 어떤 AI를 어떻게 활용했나요?
만든 AI — Claude Code. 입사하고 얼마 안 돼 같이 일하는 분들과 이야기하다 민원 시스템 얘기가 나왔습니다. 공사관리 쪽을 먼저 만들어 돌아가기 시작하자 민원 쪽을 기획해 팀장께 보여 드렸고, 팀장께서 해 보자고 힘을 실어 주셨습니다. 시스템이 여러 개가 되니 따로따로 로그인해야 해서 한 화면으로 합친 게 지금의 포털입니다. 만드는 방식은 Claude Code에 말로 시키고, 나온 화면을 직접 눌러 보고, 안 되면 다시 시키는 식입니다. 고쳐서 올렸는데 직원 화면에는 옛 화면이 그대로 떠서 한참 헤맸고, 올릴 때마다 버전 번호를 올려야 한다는 걸 그때 알았습니다.
시키는 말은 이런 식입니다. 「전화번호와 이름을 지운 다음에 AI로 보내라」, 「AI가 제때 답을 못 하면 원래 규칙 결과로 접수를 이어 가라」. 지우는 부분에는 자동 검사를 붙여 고칠 때마다 돌렸고, 화면은 접수부터 담당 옮기기까지 제가 직접 눌러 봤습니다.
4월부터 10월 25일까지 민원 2,498건이 모였습니다(10월 26일 조회). 수기 대장을 옮겨 담은 것 1,914건, 초기에 따로 표기하던 전화 접수 141건(6월 26일 뒤로는 수기 접수로 합쳤습니다), 웹으로 직접 들어온 것 443건입니다.
읽는 AI — gpt-4.1-mini, 10월 27일부터 gpt-6-luna. 처음 담당 분류는 단어 목록 규칙으로 했습니다. 「누수」, 「물이 새요」, 「배관」이 들어오면 배관 문제로 보고 기계 담당에게 보냈습니다. 문맥은 보지 않았습니다. 그래서 「천장에서 물이 떨어져요」도 기계로 갔습니다. 원인이 옥상 방수층이나 외벽이면 건축 담당 일인데도요. 5월 4일부터 7월 22일까지 11주 동안 기계로 갔다가 건축으로 다시 옮긴 것이 11번이었습니다. 이것도 기록이 쌓이고 나서야 보였습니다.
문장을 읽는 AI를 붙이기로 하고도 바로 붙이지는 않았습니다. 7월 12일, 처리까지 끝난 민원 89건을 놓고 담당자가 처리한 결과를 정답으로 삼아 단어 목록 규칙과 후보 모델 둘에 똑같이 넣어 봤습니다. 89건은 관리팀 일이 아니었던 15건, 관리팀 일이었던 73건, 처리 결과가 「확인 불가」라 어느 쪽에도 넣지 않은 1건입니다. 관리팀 일이 아니었던 15건 가운데 「관리팀 일 아님」으로 걸러낸 것은 규칙 3건, gpt-4o-mini 3건, gpt-4.1-mini 7건이었습니다. 관리팀 일이었던 73건을 잘못 거른 것은 0건, 6건, 4건이었습니다. 그래서 gpt-4.1-mini를 골랐습니다. 10월 27일에는 AI에게 주는 지시문을 고친 판으로 같은 89건을 다시 시험했습니다. 지시문이 바뀐 시험이라 같은 gpt-4.1-mini도 잘못 거른 것이 7월의 4건과 달리 3건이었습니다. 걸러낸 것은 gpt-4.1-mini 7건, gpt-6-luna 6건으로 1건 모자랐지만, 잘못 거른 것은 3건과 2건으로 1건 적었습니다. 한 건 비용은 약 8분의 1이었고, 답이 오는 시간은 중간값 2.3초로 gpt-4.1-mini(1.2초)보다 길었지만 서버가 기다리는 4초 안이었습니다. 그래서 그날부터 gpt-6-luna를 씁니다. 지금은 AI가 「관리팀 일 아님」이라고 해도 규칙 판정과 엇갈리면 반려하지 않고 담당자가 다시 봅니다.
7월 22일부터는 웹 민원이 들어오면 AI를 부릅니다. 지금 웹으로 들어온 민원은 이렇게 갑니다. 1) 단어 목록 규칙이 먼저 접수안을 만듭니다. 2) 보내기 직전에 개인정보를 지웁니다. 3) AI가 글을 읽고 담당 분야와 종류를 제안합니다. 4) 담당자가 보고 확인·배정하고, 맞지 않으면 다른 분야로 옮깁니다. AI가 제때 답하지 못하면 1)의 규칙 결과로 접수는 그대로 진행됩니다.
민원 글은 미국에 있는 회사 서버로 나갑니다. 그래서 지금은 나가기 직전에 이메일, 주민등록번호, 학번, 전화번호, 호칭이 붙은 이름 다섯 가지를 [메일], [전화] 같은 말로 바꿉니다. 순서도 정해 뒀습니다. 이메일을 맨 먼저 지웁니다. 늦게 지우면 메일 주소 앞쪽 숫자만 번호로 지워지고 뒷부분이 남기 때문입니다. 나머지는 순서를 바꿔도 결과가 같습니다. 번호 바로 앞뒤에 숫자가 더 붙어 있으면 번호로 보지 않게 해 둬서, 한 규칙이 다른 번호 안쪽을 잘라 가지 못하기 때문입니다. 민원 분류에서 AI를 부르는 길은 코드에 하나뿐이고, 그 길목에 지우는 처리가 들어 있습니다. 끄는 설정이 없어서 늘 거칩니다.
③ 활용 결과 어떤 변화가 있었나요?
먼저 만든 AI, 포털로 달라진 것입니다. 흩어져 있던 민원이 4월부터 10월 25일까지 2,498건 한 곳에 모였습니다. 작업 지시만 하고 대장에 올리지 않던 건도 이제는 남습니다. 어떤 건물에서 무엇이 몇 번 났는지 화면에서 봅니다. 지난달에 몇 건이 들어왔느냐는 질문에 이제 대답할 수 있습니다.
창구도 달라졌습니다. 웹으로 직접 들어온 민원은 443건입니다. 달별로는 5월 50건, 6월 50건, 7월 65건, 8월 46건, 9월 76건이고, 10월은 25일까지 156건입니다. 이 443건에는 누가 전화를 받아 적고 위치를 확인해 담당자에게 넘기는 단계가 없습니다. 그 단계는 한 건에 5분 안팎 걸립니다(담당자 추정). 443건이면 37시간쯤 됩니다. 443건 가운데 87건(19.6%)은 근무시간 밖에 들어왔습니다. 9월 6일 일요일 오후 1시 7분에 들어온 것도 있습니다. 전화로만 받던 때라면 다음 근무일까지 기다려야 했을 민원입니다.
웹 창구는 만든 뒤로 넓어졌습니다. 4월에는 정보통신팀이 학교 앱(킹고M) 메뉴에 「시설불편신고」를 달아 줬고, 7월쯤에는 두 캠퍼스 엘리베이터와 화장실에 「QR 스캔 후 바로 접수」 스티커를 붙였습니다.
이제는 제 개인 도구가 아닙니다. 두 캠퍼스 직원 스물한 명이 씁니다. 8월 26일부터 9월 26일까지 포털 안에서 직원과 협력사에게 만족도를 물었더니 17명이 답했고 평균 4.35점(5점 만점)이었습니다.
읽는 AI를 붙인 뒤의 결과는 접수 화면을 손본 9월 24일부터 10월 25일까지 들어온 웹 민원 170건으로 셌습니다. 이 기간의 AI는 gpt-4.1-mini입니다. 그중 162건은 AI 제안이 반영돼 접수됐고, 8건은 규칙 결과대로 접수됐습니다. AI 제안이 반영된 162건 가운데 115건(71%)은 처음 배정된 담당 그대로 민원이 닫혔습니다(종결). 처리 완료 98건과, 공사 발주로 넘기면서 닫은 17건입니다. 나머지는 다른 분야로 옮긴 것 11건, 담당자가 「관리팀 일 아님」으로 닫은 것 29건, 아직 처리 중인 것 7건입니다. 29건은 관리팀이 맡을 일이 아니라고 보고 닫은 건수이고, AI가 틀린 건수를 센 것이 아닙니다. 약 한 달치 숫자이고, 10월 27일에 바꾼 gpt-6-luna도 같은 방법으로 계속 셉니다.
④ 나만의 방식 또는 개선 포인트는 무엇인가요?
혼자 쓰는 도구면 제가 조심하면 되지만, 스물한 명이 쓰고 제가 자리에 없어도 지켜져야 합니다. 그래서 지켜야 할 것은 화면에서 아예 못 하게 막아 두었습니다.
첫째, AI는 제안만 합니다. 규칙이 먼저 접수안을 만들고, AI가 담당을 제안하고, 담당자가 확인해 확정합니다. AI에는 민원 저장소에 접근할 권한이 없고, 서버 코드는 AI가 낸 답으로 민원 상태를 바꾸지 않습니다. 상태를 바꾸려면 정해진 절차를 거쳐야 하는데, 그 절차는 로그인했는지, 직원인지, 포털 권한이 있는지, 담당 구역인지를 차례로 보고 저장 직전에 한 번 더 봅니다.
둘째, AI가 멈춰도 접수는 멈추지 않습니다. AI가 4초 안에 답하지 못하거나, 연달아 실패하거나, 하루·사람별로 정해 둔 호출 횟수를 넘으면 AI를 건너뛰고 규칙 결과로 접수를 그대로 진행합니다. 이렇게 안 될 때 쓰는 예비 경로를 폴백(fallback)이라고 합니다. 규칙 결과가 맞지 않으면 담당자가 보고 옮깁니다.
셋째, 옮긴 기록이 남습니다. 담당자가 담당을 다른 분야로 옮기면(이관), 처음 자동으로 정한 담당과 사람이 정한 담당, 옮긴 사람·시각·이유가 한 건 안에 나란히 남습니다. 처음 판정을 AI가 했는지 규칙이 했는지도 같이 남습니다. 그대로 확정한 건도 같이 셉니다. 그래야 틀린 비율을 낼 분모가 생깁니다. 화면에서는 이 기록을 고칠 수 없고, 같은 기록이 세 곳(민원의 원래 담당 칸, 바뀐 담당 칸, 따로 모아 두는 고친 기록)에 남아서 한 곳만 바뀌면 어긋난 게 드러납니다.
넷째, 보내기 직전에 지우되 확실할 때만 지웁니다. 공개한 코드에는 지우지 말아야 할 것(호실번호, 날짜 같은 것)을 잘못 지우지 않는지 보는 검사가 52개 중 26개 들어 있습니다. 27501호나 2026년을 개인정보로 오해해 지우면 AI가 판단할 재료가 없어집니다. 호칭 없이 이름만 쓴 경우처럼 아직 못 잡는 것도 있어서, 그 목록을 공개 코드 설명에 그대로 적어 두었습니다.
민원 원문과 연락처는 서울에 있는 서버(구글 클라우드 서울 데이터센터)에 저장되고, 민원 글 가운데 AI로 나가는 것은 지운 뒤의 본문뿐입니다. 개인정보처리방침에는 국외로 나간다는 것을 법이 정한 항목대로 적었습니다.
AI에게는 아직 결재권을 주지 않았습니다. 제안까지가 AI 몫이고, 확정은 사람이 합니다.
⑤ 다른 사람도 따라 할 수 있나요?
제 시스템을 그대로 옮길 필요는 없습니다. 규칙 네 개면 되고, 엑셀이든 메신저든 지금 쓰는 도구 그대로 오늘 적용됩니다.
첫째, 그대로 둔 것도 같이 셉니다. 틀린 것만 모으면 몇 번 틀렸다는 말은 해도 나아지고 있다는 말은 못 합니다. 분모가 없어서입니다. 엑셀이면 「그대로 둠」도 한 줄씩 적으면 됩니다.
둘째, 보내기 직전에 지웁니다. AI 창에 붙여넣기 전에 이름과 번호를 [이름], [전화]로 바꾸는 것부터 합니다. 한 번 붙여넣은 글은 되돌릴 수 없습니다. 다만 확실할 때만 지웁니다. 멀쩡한 말을 지우면 AI가 판단할 재료가 없어집니다.
셋째, AI가 낸 답과 사람이 정한 답을 따로 남깁니다. 같은 칸에 덮어쓰지 않습니다. 엑셀이면 열 하나만 더 만들면 됩니다.
넷째, AI가 멈춰도 일은 멈추지 않게 합니다. 안 될 때 무엇을 할지 먼저 정해 놓고 붙입니다.
지우는 코드는 공개해 뒀습니다. 파일 하나고 설치할 것도 없습니다. archi-pixel.github.io/llm-mask-ko 에서 직접 문장을 넣어 보실 수 있고, 코드와 검사 52개는 github.com/archi-pixel/llm-mask-ko 에 있습니다. 공개본은 10월 27일에 검사를 52개로 늘린 판이고, 같은 날 운영에도 같은 파일을 넣었습니다. 운영에서는 여기에 실제로 AI에 보내는 길을 보는 검사 2개를 더해 54개를 돌립니다.
9월에는 두 캠퍼스 관리팀과 법인 직원 13명에게 포털 사용법을 한 번 설명했습니다. 저는 개발을 배운 적이 없고 올해 1월에 들어온 직원입니다. 그래서 이 네 개는 누구나 할 수 있다고 말할 수 있습니다.
같이 낸 자료: 붙임 1 「셀 수 없어서 만들었습니다」(이 글을 실제 화면과 함께 정리, 숫자 출처는 8쪽) · 붙임 2 「AI에 보내기 전에 지운 것」 · 붙임 3 「AI가 제안하고, 사람이 확정합니다」 · 붙임 4 60초 영상 · 붙임 5 한 장 요약
「천장에서 물이 떨어져요.」
이 한 문장이 어디로 가야 하는지 정하는 게 제 일의 시작입니다. 저는 성균관대학교 자산관리처 관리팀 장상민입니다. 자연과학캠퍼스(수원)와 인문사회과학캠퍼스(서울) 두 곳의 시설을 고치고 공사를 감독합니다. 올해 1월에 들어왔고 개발은 배운 적이 없습니다.
들어와서 처음 막힌 건 고치는 일이 아니라 세는 일이었습니다. 민원은 전화로도 오고 메일로도 오고, 복도에서 마주쳐 말로도 들어옵니다. 두 캠퍼스 모두 수기 민원관리대장은 있었지만 빠진 게 많았습니다. 구두나 전화로 들어온 건은 작업 지시만 하고 대장에 올리지 않았고, 처리하는 쪽에서 따로 정리해 둔 것도 기준이 제각각이었습니다. 지난달에 몇 건이 들어왔는지, 하나 처리하는 데 얼마나 걸렸는지 대답할 수 없었습니다. 대장은 있었는데 셀 수가 없었습니다.
그래서 시설통합포털을 만들었습니다. 학교가 예산을 세워 추진한 사업이 아니고, 학교가 따로 발주하거나 용역을 준 개발비는 없습니다. AI 호출과 서버 비용은 부서가 냅니다. AI 호출 쪽은 코드와 공개 단가로 계산하면 한 달에 1달러가 안 됩니다. 만들고 쓰는 것은 팀장과 처장께 보고해 승인을 받았고, 개인정보처리방침은 자산관리처 명의로 공개돼 있습니다. 이 공모전에 내는 것도 보고했습니다.
AI는 두 군데에 썼습니다. 먼저 흩어진 민원을 한 곳에 모으는 포털 자체를 Claude Code에 말로 시켜 만들었습니다(만든 AI). 그다음 그 포털에 민원 글을 읽고 담당을 제안하는 AI를 붙였습니다(읽는 AI). 둘은 하는 일이 달라 따로 적습니다.
② 어떤 AI를 어떻게 활용했나요?
만든 AI — Claude Code. 입사하고 얼마 안 돼 같이 일하는 분들과 이야기하다 민원 시스템 얘기가 나왔습니다. 공사관리 쪽을 먼저 만들어 돌아가기 시작하자 민원 쪽을 기획해 팀장께 보여 드렸고, 팀장께서 해 보자고 힘을 실어 주셨습니다. 시스템이 여러 개가 되니 따로따로 로그인해야 해서 한 화면으로 합친 게 지금의 포털입니다. 만드는 방식은 Claude Code에 말로 시키고, 나온 화면을 직접 눌러 보고, 안 되면 다시 시키는 식입니다. 고쳐서 올렸는데 직원 화면에는 옛 화면이 그대로 떠서 한참 헤맸고, 올릴 때마다 버전 번호를 올려야 한다는 걸 그때 알았습니다.
시키는 말은 이런 식입니다. 「전화번호와 이름을 지운 다음에 AI로 보내라」, 「AI가 제때 답을 못 하면 원래 규칙 결과로 접수를 이어 가라」. 지우는 부분에는 자동 검사를 붙여 고칠 때마다 돌렸고, 화면은 접수부터 담당 옮기기까지 제가 직접 눌러 봤습니다.
4월부터 10월 25일까지 민원 2,498건이 모였습니다(10월 26일 조회). 수기 대장을 옮겨 담은 것 1,914건, 초기에 따로 표기하던 전화 접수 141건(6월 26일 뒤로는 수기 접수로 합쳤습니다), 웹으로 직접 들어온 것 443건입니다.
읽는 AI — gpt-4.1-mini, 10월 27일부터 gpt-6-luna. 처음 담당 분류는 단어 목록 규칙으로 했습니다. 「누수」, 「물이 새요」, 「배관」이 들어오면 배관 문제로 보고 기계 담당에게 보냈습니다. 문맥은 보지 않았습니다. 그래서 「천장에서 물이 떨어져요」도 기계로 갔습니다. 원인이 옥상 방수층이나 외벽이면 건축 담당 일인데도요. 5월 4일부터 7월 22일까지 11주 동안 기계로 갔다가 건축으로 다시 옮긴 것이 11번이었습니다. 이것도 기록이 쌓이고 나서야 보였습니다.
문장을 읽는 AI를 붙이기로 하고도 바로 붙이지는 않았습니다. 7월 12일, 처리까지 끝난 민원 89건을 놓고 담당자가 처리한 결과를 정답으로 삼아 단어 목록 규칙과 후보 모델 둘에 똑같이 넣어 봤습니다. 89건은 관리팀 일이 아니었던 15건, 관리팀 일이었던 73건, 처리 결과가 「확인 불가」라 어느 쪽에도 넣지 않은 1건입니다. 관리팀 일이 아니었던 15건 가운데 「관리팀 일 아님」으로 걸러낸 것은 규칙 3건, gpt-4o-mini 3건, gpt-4.1-mini 7건이었습니다. 관리팀 일이었던 73건을 잘못 거른 것은 0건, 6건, 4건이었습니다. 그래서 gpt-4.1-mini를 골랐습니다. 10월 27일에는 AI에게 주는 지시문을 고친 판으로 같은 89건을 다시 시험했습니다. 지시문이 바뀐 시험이라 같은 gpt-4.1-mini도 잘못 거른 것이 7월의 4건과 달리 3건이었습니다. 걸러낸 것은 gpt-4.1-mini 7건, gpt-6-luna 6건으로 1건 모자랐지만, 잘못 거른 것은 3건과 2건으로 1건 적었습니다. 한 건 비용은 약 8분의 1이었고, 답이 오는 시간은 중간값 2.3초로 gpt-4.1-mini(1.2초)보다 길었지만 서버가 기다리는 4초 안이었습니다. 그래서 그날부터 gpt-6-luna를 씁니다. 지금은 AI가 「관리팀 일 아님」이라고 해도 규칙 판정과 엇갈리면 반려하지 않고 담당자가 다시 봅니다.
7월 22일부터는 웹 민원이 들어오면 AI를 부릅니다. 지금 웹으로 들어온 민원은 이렇게 갑니다. 1) 단어 목록 규칙이 먼저 접수안을 만듭니다. 2) 보내기 직전에 개인정보를 지웁니다. 3) AI가 글을 읽고 담당 분야와 종류를 제안합니다. 4) 담당자가 보고 확인·배정하고, 맞지 않으면 다른 분야로 옮깁니다. AI가 제때 답하지 못하면 1)의 규칙 결과로 접수는 그대로 진행됩니다.
민원 글은 미국에 있는 회사 서버로 나갑니다. 그래서 지금은 나가기 직전에 이메일, 주민등록번호, 학번, 전화번호, 호칭이 붙은 이름 다섯 가지를 [메일], [전화] 같은 말로 바꿉니다. 순서도 정해 뒀습니다. 이메일을 맨 먼저 지웁니다. 늦게 지우면 메일 주소 앞쪽 숫자만 번호로 지워지고 뒷부분이 남기 때문입니다. 나머지는 순서를 바꿔도 결과가 같습니다. 번호 바로 앞뒤에 숫자가 더 붙어 있으면 번호로 보지 않게 해 둬서, 한 규칙이 다른 번호 안쪽을 잘라 가지 못하기 때문입니다. 민원 분류에서 AI를 부르는 길은 코드에 하나뿐이고, 그 길목에 지우는 처리가 들어 있습니다. 끄는 설정이 없어서 늘 거칩니다.
③ 활용 결과 어떤 변화가 있었나요?
먼저 만든 AI, 포털로 달라진 것입니다. 흩어져 있던 민원이 4월부터 10월 25일까지 2,498건 한 곳에 모였습니다. 작업 지시만 하고 대장에 올리지 않던 건도 이제는 남습니다. 어떤 건물에서 무엇이 몇 번 났는지 화면에서 봅니다. 지난달에 몇 건이 들어왔느냐는 질문에 이제 대답할 수 있습니다.
창구도 달라졌습니다. 웹으로 직접 들어온 민원은 443건입니다. 달별로는 5월 50건, 6월 50건, 7월 65건, 8월 46건, 9월 76건이고, 10월은 25일까지 156건입니다. 이 443건에는 누가 전화를 받아 적고 위치를 확인해 담당자에게 넘기는 단계가 없습니다. 그 단계는 한 건에 5분 안팎 걸립니다(담당자 추정). 443건이면 37시간쯤 됩니다. 443건 가운데 87건(19.6%)은 근무시간 밖에 들어왔습니다. 9월 6일 일요일 오후 1시 7분에 들어온 것도 있습니다. 전화로만 받던 때라면 다음 근무일까지 기다려야 했을 민원입니다.
웹 창구는 만든 뒤로 넓어졌습니다. 4월에는 정보통신팀이 학교 앱(킹고M) 메뉴에 「시설불편신고」를 달아 줬고, 7월쯤에는 두 캠퍼스 엘리베이터와 화장실에 「QR 스캔 후 바로 접수」 스티커를 붙였습니다.
이제는 제 개인 도구가 아닙니다. 두 캠퍼스 직원 스물한 명이 씁니다. 8월 26일부터 9월 26일까지 포털 안에서 직원과 협력사에게 만족도를 물었더니 17명이 답했고 평균 4.35점(5점 만점)이었습니다.
읽는 AI를 붙인 뒤의 결과는 접수 화면을 손본 9월 24일부터 10월 25일까지 들어온 웹 민원 170건으로 셌습니다. 이 기간의 AI는 gpt-4.1-mini입니다. 그중 162건은 AI 제안이 반영돼 접수됐고, 8건은 규칙 결과대로 접수됐습니다. AI 제안이 반영된 162건 가운데 115건(71%)은 처음 배정된 담당 그대로 민원이 닫혔습니다(종결). 처리 완료 98건과, 공사 발주로 넘기면서 닫은 17건입니다. 나머지는 다른 분야로 옮긴 것 11건, 담당자가 「관리팀 일 아님」으로 닫은 것 29건, 아직 처리 중인 것 7건입니다. 29건은 관리팀이 맡을 일이 아니라고 보고 닫은 건수이고, AI가 틀린 건수를 센 것이 아닙니다. 약 한 달치 숫자이고, 10월 27일에 바꾼 gpt-6-luna도 같은 방법으로 계속 셉니다.
④ 나만의 방식 또는 개선 포인트는 무엇인가요?
혼자 쓰는 도구면 제가 조심하면 되지만, 스물한 명이 쓰고 제가 자리에 없어도 지켜져야 합니다. 그래서 지켜야 할 것은 화면에서 아예 못 하게 막아 두었습니다.
첫째, AI는 제안만 합니다. 규칙이 먼저 접수안을 만들고, AI가 담당을 제안하고, 담당자가 확인해 확정합니다. AI에는 민원 저장소에 접근할 권한이 없고, 서버 코드는 AI가 낸 답으로 민원 상태를 바꾸지 않습니다. 상태를 바꾸려면 정해진 절차를 거쳐야 하는데, 그 절차는 로그인했는지, 직원인지, 포털 권한이 있는지, 담당 구역인지를 차례로 보고 저장 직전에 한 번 더 봅니다.
둘째, AI가 멈춰도 접수는 멈추지 않습니다. AI가 4초 안에 답하지 못하거나, 연달아 실패하거나, 하루·사람별로 정해 둔 호출 횟수를 넘으면 AI를 건너뛰고 규칙 결과로 접수를 그대로 진행합니다. 이렇게 안 될 때 쓰는 예비 경로를 폴백(fallback)이라고 합니다. 규칙 결과가 맞지 않으면 담당자가 보고 옮깁니다.
셋째, 옮긴 기록이 남습니다. 담당자가 담당을 다른 분야로 옮기면(이관), 처음 자동으로 정한 담당과 사람이 정한 담당, 옮긴 사람·시각·이유가 한 건 안에 나란히 남습니다. 처음 판정을 AI가 했는지 규칙이 했는지도 같이 남습니다. 그대로 확정한 건도 같이 셉니다. 그래야 틀린 비율을 낼 분모가 생깁니다. 화면에서는 이 기록을 고칠 수 없고, 같은 기록이 세 곳(민원의 원래 담당 칸, 바뀐 담당 칸, 따로 모아 두는 고친 기록)에 남아서 한 곳만 바뀌면 어긋난 게 드러납니다.
넷째, 보내기 직전에 지우되 확실할 때만 지웁니다. 공개한 코드에는 지우지 말아야 할 것(호실번호, 날짜 같은 것)을 잘못 지우지 않는지 보는 검사가 52개 중 26개 들어 있습니다. 27501호나 2026년을 개인정보로 오해해 지우면 AI가 판단할 재료가 없어집니다. 호칭 없이 이름만 쓴 경우처럼 아직 못 잡는 것도 있어서, 그 목록을 공개 코드 설명에 그대로 적어 두었습니다.
민원 원문과 연락처는 서울에 있는 서버(구글 클라우드 서울 데이터센터)에 저장되고, 민원 글 가운데 AI로 나가는 것은 지운 뒤의 본문뿐입니다. 개인정보처리방침에는 국외로 나간다는 것을 법이 정한 항목대로 적었습니다.
AI에게는 아직 결재권을 주지 않았습니다. 제안까지가 AI 몫이고, 확정은 사람이 합니다.
⑤ 다른 사람도 따라 할 수 있나요?
제 시스템을 그대로 옮길 필요는 없습니다. 규칙 네 개면 되고, 엑셀이든 메신저든 지금 쓰는 도구 그대로 오늘 적용됩니다.
첫째, 그대로 둔 것도 같이 셉니다. 틀린 것만 모으면 몇 번 틀렸다는 말은 해도 나아지고 있다는 말은 못 합니다. 분모가 없어서입니다. 엑셀이면 「그대로 둠」도 한 줄씩 적으면 됩니다.
둘째, 보내기 직전에 지웁니다. AI 창에 붙여넣기 전에 이름과 번호를 [이름], [전화]로 바꾸는 것부터 합니다. 한 번 붙여넣은 글은 되돌릴 수 없습니다. 다만 확실할 때만 지웁니다. 멀쩡한 말을 지우면 AI가 판단할 재료가 없어집니다.
셋째, AI가 낸 답과 사람이 정한 답을 따로 남깁니다. 같은 칸에 덮어쓰지 않습니다. 엑셀이면 열 하나만 더 만들면 됩니다.
넷째, AI가 멈춰도 일은 멈추지 않게 합니다. 안 될 때 무엇을 할지 먼저 정해 놓고 붙입니다.
지우는 코드는 공개해 뒀습니다. 파일 하나고 설치할 것도 없습니다. archi-pixel.github.io/llm-mask-ko 에서 직접 문장을 넣어 보실 수 있고, 코드와 검사 52개는 github.com/archi-pixel/llm-mask-ko 에 있습니다. 공개본은 10월 27일에 검사를 52개로 늘린 판이고, 같은 날 운영에도 같은 파일을 넣었습니다. 운영에서는 여기에 실제로 AI에 보내는 길을 보는 검사 2개를 더해 54개를 돌립니다.
9월에는 두 캠퍼스 관리팀과 법인 직원 13명에게 포털 사용법을 한 번 설명했습니다. 저는 개발을 배운 적이 없고 올해 1월에 들어온 직원입니다. 그래서 이 네 개는 누구나 할 수 있다고 말할 수 있습니다.
같이 낸 자료: 붙임 1 「셀 수 없어서 만들었습니다」(이 글을 실제 화면과 함께 정리, 숫자 출처는 8쪽) · 붙임 2 「AI에 보내기 전에 지운 것」 · 붙임 3 「AI가 제안하고, 사람이 확정합니다」 · 붙임 4 60초 영상 · 붙임 5 한 장 요약