담당자가 없으면 멈추는 업무, 자동화부터 하면 될까?

요청을 받으면 뭘 바꾸려는 건지부터 물어봐.

“담당자가 없으면 처리가 멈추니 자동화해달라.” 이런 요청이 오면 나는 멈춘 요청 한 건부터 달라고 해. 자동화 버튼을 만드는 게 목적은 아니잖아. 누가 어떤 일을 하려다가 어디서 막혔는지 봐야 해. 고객이 기다린 일과 운영자가 다시 한 일을 나눠 적고, 지금은 어떻게 우회해서 처리하는지도 물어봐.

처음에는 안건 한 장이면 돼. 현상, 목적, 시스템 수정안, 기대효과를 연결해서 적어. “인계가 안 된다”는 현상에 “자동 실행”을 바로 붙이지 말고, 요청 내용과 근거를 다음 사람이 볼 수 있는지부터 확인하는 거야. 기대효과 옆에는 나중에 확인할 지표를 적고.

이 글에서는 공개된 넥슨의 계정 보호 업무 개선 사례에서 출발해 CP-01이라는 예제 안건을 풀어볼게. 대상 판단 기준은 그대로 두고, 접수·인계·승인·처리 결과가 이어지도록 만드는 일이야. 여기서 남길 첫 기록은 아래 접수서야.

설명만 듣지 말고 요청 한 건을 끝까지 따라가.

운영 담당자가 “대체로 이렇게 해요”라고 설명하면 실제 요청을 같이 열어봐. 정상 종료된 건, 담당자 부재로 멈춘 건, 자료가 부족해서 되돌아온 건을 각각 따라가는 거야. 화면에서는 끝났는데 메신저에서는 다시 확인하고 있을 수도 있어. 문서에 적힌 순서와 실제로 하는 일이 같은지부터 맞춰.

단계마다 입력, 처리, 출력, 다음 담당자를 적어. 자료는 누가 만들고 어디로 보내는지, 받았다는 표시는 어디에 남는지, 담당자가 없으면 누가 가져가는지 물어봐. 같은 정보를 다른 목록에 다시 적는다면 그 일도 빠뜨리지 마. 새 화면이 생겨도 그대로 남기 쉬운 일이거든.

설명이 다르면 어느 쪽 말이 맞는지 바로 정하지 않아. 확인할 요청과 기록, 답해줄 역할을 남겨. 현재 흐름이 틀렸는데 변경 흐름부터 그리면 나중에 설계를 다시 해야 해. D02를 운영과 같이 보면서 빠진 전달과 되돌아가는 경로를 채워.

느리다는데, 어디서 얼마나 기다리는 거야?

전체 처리시간과 실제 작업시간을 나눠봐. 예를 들어 접수부터 종료까지 6시간인데 사람이 확인한 시간은 10분인 예제라면, 나머지 5시간 50분에 뭘 기다렸는지가 먼저야. 자료를 기다렸는지, 담당자를 못 찾았는지, 승인이 밀렸는지에 따라 고칠 곳이 달라져.

데이터를 요청할 때는 기간과 대상부터 적어. 접수, 자료 보완, 검토 시작, 승인, 실행, 결과 확인 시각을 받을 거야. 사람의 작업시간은 별도로 받아야 해. 같은 요청에 메시지가 다섯 번 왔다고 요청 다섯 건으로 세면 안 되겠지. 종료된 요청만 보면 아직 오래 기다리는 건이 빠지니 미종료 현황도 같이 봐.

집계가 오면 몇 건은 원자료와 직접 대조해. 중복과 빠진 값은 어떻게 처리했는지, 같은 정의로 다음 달에도 계산할 수 있는지 확인해. 원인을 말할 자료가 없으면 수집 항목을 보완하고, 확인된 구간부터 판단해. D03에 정의를 남겨두면 배포 후에도 같은 기준으로 비교할 수 있어.

이걸 만들면 기존에 하던 일 중에 뭐가 없어져?

나는 이 질문을 먼저 해. 새 기능은 생겼는데 원래 하던 확인과 입력을 그대로 해야 한다면 일이 하나 더 생긴 거잖아. 기존 도구 연결, 요청 화면 보완, 전체 자동화를 나란히 놓고 없어지는 일과 남는 일을 적어봐.

이 안건에서는 기존 요청·승인 체계를 연결하는 안부터 볼 거야. 이미 승인하는 곳이 있는데 새 승인함을 또 만들 필요가 있는지 확인해야 해. 기존 도구에 대상 변경 이력이 없으면 그 부분을 보완하면 되는지 개발과 이야기하고. 지원되지 않는다는 답을 받으면 어떤 조건 때문에 안 되는지도 남겨.

공수 외에도 반복 조회 비용, 요청이 몰릴 때의 지연, 규칙 유지, 장애 때 운영자가 할 일을 봐. 이번에는 요청 인계와 승인 범위를 먼저 고치고, 탐지 기준이나 전면 자동 판단은 별도 안건으로 나눠. D04에는 선택 이유와 다시 검토할 조건까지 적어두는 거야.

컴플라이언스도 뭘 확인할 건지 적어서 가져가.

“개인정보 문제 없나요?”만 물으면 답하기 어렵겠지. 어떤 정보를 누가, 왜 보고, 어디에 얼마나 보관하려는지 보여줘야 해. 이 안건에서는 개인정보 보호법 제15조의 처리 근거와 목적, 제16조의 최소 수집 원칙, 안전성 확보조치 기준을 출발점으로 봐. 서비스 약관과 처리방침, 기존 권한표와 보관 기준도 같이 대조하고.

목록에서 원문 자료를 전부 보여달라는 요구가 왔다고 해보자. 목록은 마스킹한 대상과 상태만 보여주고, 상세 근거는 필요한 권한으로 열어보는 안을 적어 보내. 왜 필요한지, 누가 확인할지, 확인 결과가 어느 화면과 데이터에 반영되는지를 D05에 연결해.

답변을 받으면 검토표만 완료로 바꾸지 마. 권한표, 화면 표시 항목, 보관·파기 설계도 같이 바뀌어야 해. 기간이나 대결 권한이 미정이면 확인할 역할과 필요한 자료를 남겨. 개발자가 빈칸을 자기 판단으로 채우게 두면 나중에 서로 다른 정책을 이야기하게 돼.

조건을 한 박스에 몰아넣으면 설계가 안 보여.

“사용 가능하면 실행”이라고 적으면 짧긴 해. 그런데 자료가 있는지, 승인됐는지, 승인 뒤 대상이 바뀌었는지는 서로 다른 조건이잖아. 나는 확인하는 순서대로 나눠. 노드에는 이름과 설명을 따로 적고, 선에는 그 조건의 결과를 붙여. 결과가 같을 때 합류시키고, 담당자나 후속 처리가 다르면 분리해.

이 안건에서는 요청을 받고 자료 확인, 승인 확인, 승인본과 현재본 비교를 차례로 거쳐. 자료가 없으면 보완으로, 승인이 없거나 범위가 달라졌으면 검토로 돌아가. 통과하면 실행 대기로 가는 거야. 다음 단계로 가는 조건과 되돌아갈 곳을 둘 다 그려야 해.

실행 이후도 따로 봐. 응답이 안 왔다고 바로 실패로 끝내면 이미 처리된 계정을 다시 처리할 수 있어. 결과 확인 중으로 두고 실제 결과를 조회해. 일부만 성공했다면 대상별로 나눠 남겨. D06의 각 규칙을 화면과 테스트에 연결할 수 있어야 설계서로 쓸 수 있어.

버튼을 누르면 그다음에 뭐가 나오는지까지 적어.

요청 상세 화면 하나부터 그려봐. 위에는 요청 번호, 상태, 담당 역할, 최근 변경 시각이 있어야 해. 가운데는 대상과 요청 이유, 자료, 승인된 검토본을 두고. 아래에는 지금 할 수 있는 작업과 이력을 놓는 거야. 다른 화면으로 이동해야 하면 돌아오는 경로도 정해.

설계서에는 버튼명만 쓰지 않아. 노출 조건, 누를 수 있는 역할, 클릭 후 처리, 기다리는 동안의 화면, 성공·실패 문구, 남길 기록을 같이 써. 잠깐 보여줄 안내인지 확인할 때까지 남길 안내인지도 정하고. 화면에서 버튼을 막아도 서버에서 같은 조건을 확인해야 해.

예를 들어 A·B를 승인한 뒤 C를 추가하면, “처리할 수 없음”만 보여주지 말고 승인 대상 A·B와 현재 대상 A·B·C를 같이 보여줘. 안내는 “승인 후 대상이 바뀌었어. 추가된 대상을 검토한 뒤 다시 승인해줘.”처럼 다음 행동이 보여야 해. 실제 고객·운영 화면의 문체는 해당 서비스 규칙에 맞춰 정하고, 문구의 의미와 노출 시점은 설계서에 고정해.

아래 요청 상세 시연에서 자료 보완부터 승인, 대상 추가, 재검토, 결과 조회까지 눌러봐. D07을 읽고 이 화면을 보면 무엇을 설계에 남겨야 하는지 연결될 거야.

AI한테 한 번에 다 만들라고 하면 계속 어긋나.

먼저 말부터 맞춰. 내가 “노드”라고 하면 박스 하나인지, “노드 설명”은 안의 작은 글자인지, “분기 라벨”은 선에 붙는 조건인지 정해두는 거야. 같은 단어를 다르게 이해하면 수정을 여러 번 해도 엉뚱한 곳을 고치게 돼.

그다음 이번에 다룰 구간을 좁혀. 전체 설계서를 한 번에 완성시키기보다 자료 확인 구간부터 해보는 거야. 시작과 끝, 확인 순서, 결과별 이동, 남길 기록을 주고 “이해한 것부터 설명해봐”라고 해. 여기서 내가 원하는 흐름과 다른 부분을 잡고 나서 화면을 수정시켜.

답변이 나오면 그럴듯한 설명으로 넘기지 않아. “조회 결과가 없으면 왜 종료야?”, “여기서 막히면 다음 담당자는 뭘 보면 돼?”, “그 버튼을 눌렀다는 기록은 어디에 남아?”처럼 빠진 연결을 물어봐. 기존 자료로 계속할 수 있는 경우와 정말 멈춰야 하는 경우를 나누게 하는 거지.

기획서에는 문제와 근거, 대안과 범위를 남겨. 설계서에는 노드별 조건, 화면·문구, 처리 결과, 이력을 남기고. AI 답변을 그대로 붙이는 게 아니라 이 두 문서에서 빠진 칸을 채우는 데 쓰는 거야. 아래 요청문은 CP-01에 맞춰 다시 쓴 예시야.

1 · 작업 범위와 단어부터 맞춰

이번에는 CP-01의 자료 확인부터 승인 요청까지 구간만 볼 거야.
노드는 박스 하나, 노드명은 제목, 노드 설명은 확인할 내용, 분기 라벨은 선에 붙는 결과로 통일하자.
자료 유무와 승인 여부를 한 조건으로 합치지 말고 확인 순서대로 나눠줘.
먼저 시작·조건·처리·다음 단계로 네가 이해한 흐름부터 적어봐. 아직 화면은 수정하지 마.

2 · 흐름이 맞으면 한 구간만 수정시켜

지금 확인한 자료 확인 구간을 반영해줘. 승인 이후 구간은 그대로 둬.
각 노드에 이름과 설명을 넣고, 분기 결과는 해당 선에 붙여. 같은 처리로 끝나면 합류시켜줘.
노드 크기와 간격, 시작 높이를 맞추고 선이 박스나 라벨을 지나가지 않게 해.
수정 후 실제 화면에서 시작·각 분기·합류·다음 단계 연결을 확인해줘.

3 · 답을 읽고 빠진 조건을 다시 물어봐

자료 조회에 실패했다고 전부 종료로 묶은 이유가 뭐야?
이미 확인된 자료로 진행할 수 있는 경우와 필수 자료가 없어 멈춰야 하는 경우를 나눠봐.
각 경우에 화면에는 무슨 문구가 나오고, 누가 다음에 뭘 해야 하며, 어떤 기록이 남는지도 써줘.
확정한 규칙만 설계서에 반영하고 영향받는 QA 항목을 같이 정리해줘.

회의했으니 전달 끝? 다음 사람이 다시 물어보면 덜 된 거야.

기획서와 설계서는 읽는 목적이 달라. 기획서는 왜 이 일을 하는지, 어떤 대안을 골랐는지, 이번 범위가 어디까지인지 이해하게 해야 해. 설계서는 그 결정을 화면과 처리 조건으로 구현할 수 있어야 하고. 두 문서가 같은 말을 반복하기보다 같은 요구사항을 서로 연결해줘야 해.

나는 요구사항에 번호를 붙여서 연결할 거야. R-03이 승인 후 대상 변경이라면, D06에는 재검토 조건, D07에는 승인본 비교 화면, T-03에는 기존 승인으로 실행되지 않는 결과가 있어야 해. 회의에서 바꾼 내용은 이 연결된 문서에 같이 반영해.

결정 기록에는 무엇을 정했는지뿐 아니라 왜 정했는지, 누가 확인했는지, 아직 누구에게 뭘 물어봐야 하는지를 남겨. 미정 사항 때문에 착수할 수 없는 범위도 표시하고. 개발 중 새 예외가 나오면 문서 버전과 영향받는 항목을 바꿔서 다시 전달해.

안 된다는 말만 보내면 여러 사람이 같은 확인을 하게 돼.

테스트의 시작은 정확한 현상 재현이야. T-03이라면 A·B를 승인하고, C를 추가해서 저장한 다음, 이전 승인으로 실행을 요청하는 순서를 적어. 기대 결과는 재검토 전환과 실행 차단이야. 이 순서와 조건이 있어야 개발도 같은 문제를 볼 수 있어.

기기, OS와 브라우저 버전, 권한, 요청 상태, 입력값, 기대 결과와 실제 결과, 발생 시각을 남겨. 한 번만 나왔으면 한 번 나왔다고 적고, 다시 안 나왔으면 어떤 조건으로 몇 번 확인했는지도 써. 내가 본 사실과 추정한 원인을 나눠서 전달하는 거야.

수정됐다는 답을 받으면 같은 조건으로 다시 확인해. 대상 변경 차단을 고쳤다면 변경 없는 정상 승인, 반려 후 재요청, 결과 조회도 이어서 봐. 원래 되던 흐름이 같이 막혔을 수도 있잖아. D10에는 실행 결과와 증빙이 붙어야 하고, 시나리오를 적어둔 것만으로 통과 표시를 하면 안 돼.

배포할 때는 운영이 그만해도 되는 일까지 정해.

배포 요청에는 버전, 범위, 사전 조건, 순서, 확인 역할, 중단 조건과 복구 절차를 적어. 운영에는 새 화면 사용법과 함께 기존 수기 전달을 언제 종료하는지도 알려줘. 처음에 대조할 필요가 있어도 두 벌로 하는 일을 계속 남겨두면 개선이 덜 끝난 거야.

복구도 구체적으로 나눠. 페이지를 이전 버전으로 돌리는 것과 이미 적용된 계정 조치를 되돌리는 건 다른 일이야. 신규 실행을 멈추고, 진행 중인 요청의 실제 결과를 확인한 뒤, 기존 접수 경로로 전환할지 정해. 계정 복구가 필요하면 그 권한과 절차를 별도로 따라야 해.

제한된 범위에서 요청 인계와 결과 조회가 이어지는지 확인하고 넓혀. 승인 범위를 벗어난 조치나 중복 실행, 결과 추적 불가가 나오면 확대를 멈춰. 기능 배포, 운영 인수, 기존 업무 종료를 각각 확인해서 D11에 남겨.

그래서 내가 뭘 남겼는지, 마지막에 연결해서 봐.

접수서만 있으면 왜 그 기능을 골랐는지 모르고, 화면만 있으면 어떤 문제를 풀었는지 모르잖아. D01의 문제에서 D04의 판단, D06·D07의 설계, D10의 검수, D11의 배포까지 따라갈 수 있어야 해. 다음 사람이 같은 설명을 다시 듣지 않아도 이어갈 수 있게 남기는 거야.

결과는 D03에서 정한 기준으로 봐. 같은 요청 유형에서 대기와 작업시간, 재문의와 중복 입력이 줄었는지 확인하고, 오조치와 복구 부담도 함께 봐. 기간이나 요청 구성이 바뀌었으면 그 차이부터 적어. 화면을 배포했다는 사실과 업무가 나아졌다는 결과는 따로 확인해야 해.

여전히 기다린다면 어느 구간인지 다시 봐. 자료가 안 오는 건지, 개인 메시지로 계속 전달하는 건지, 승인 대기가 그대로인지 확인하고 후속 안건으로 남겨. 남은 항목에는 확인 역할과 다음 점검 시점도 적어. 이게 내가 다음 사람에게 넘길 마지막 기록이야.

참고 자료

넥슨 플랫폼본부의 계정 보안 프로세스 개선기(2023-12-01)를 참고했다. 본문은 이 문제를 내가 맡았을 때의 설계안이며, 화면 시연과 A·B·C 요청은 설명용 예제다.

법령은 2026-09-24 기준으로 개인정보 보호법 제15·16조와 개인정보의 안전성 확보조치 기준을 확인했다. 서비스에 적용할 때는 처리 목적과 데이터, 권한에 맞춰 검토한다. 공식 조문 · 안전성 확보조치 기준

한국어·영어·중국어판은 한국의 규정을 기준으로 작성한 같은 설계안이다.