작성일·마지막 확인: 2026-08-29
자동화를 만들다 보면 “여기까지 됐으니 마지막 클릭도 맡기자”는 유혹이 생긴다. 초안을 만들고 파일을 정리하는 단계까지 잘 돌아가면 게시나 전송도 같은 일처럼 보이기 때문이다. 하지만 내부 준비와 외부 실행은 실패 비용이 다르다. 제가 승인 경계를 정할 때 보는 기준은 기술적으로 클릭할 수 있는지가 아니라, 잘못 실행됐을 때 되돌릴 수 있는지, 다른 사람에게 영향을 주는지, 돈·권리·민감정보가 움직이는지다.
이 글이 필요한 사람
Telegram이나 채팅에서 PC 작업을 요청하고, AI 에이전트가 문서·블로그·이메일 같은 도구를 다루게 하려는 1인 사업자와 소규모 운영자에게 맞춘 노트다. 자동화가 초안을 준비하는 단계는 익숙하지만 어느 지점에서 멈춰야 하는지 애매한 경우, “승인 필요”라는 말만 써 놓고 실제 절차는 정하지 않은 경우에 특히 필요하다.
기준 환경과 전제
- Windows PC에서 로컬 파일과 브라우저 도구를 사용한다.
- 모바일 메시지는 요청의 입구일 뿐, 곧바로 모든 권한을 뜻하지 않는다.
- 고객사 또는 프로젝트별 작업 공간과 상태 원본이 분리되어 있다.
- 게시·전송·삭제 전에는 사람이 결과와 대상을 확인할 수 있다.
여기서 승인은 단순한 “네” 한 글자가 아니다. 대상, 작업, 변경 범위, 최종 산출물이 보이는 상태에서 내린 명시적 결정이어야 한다. 이전 작업에 대한 승인을 다음 작업에 재사용하지 않고, 사용자가 답하지 않은 상태를 동의로 해석하지 않는다.
먼저 작업을 세 구간으로 나눈다
저는 한 업무를 조회, 준비, 실행으로 나눠 본다. 조회는 원본 상태를 읽는 단계다. 준비는 초안이나 새 파일을 만들되 외부에는 반영하지 않는 단계다. 실행은 게시, 전송, 결제, 삭제처럼 시스템 밖의 상태를 바꾸는 단계다. 같은 버튼 흐름에 있더라도 세 구간을 분리하면 어디서 승인을 받아야 하는지 보인다.
예를 들어 블로그 글 자동화라면 자료 읽기와 초안 파일 생성은 준비 단계다. 관리자 화면에 초안을 올리는 것도 계정 정책에 따라 변경 작업일 수 있다. 공개 버튼을 누르는 행위는 분명한 외부 실행이다. “글 작성”이라는 한 문장으로 이 과정을 묶지 않고 각 단계의 산출물과 권한을 따로 적는다.
반드시 사람이 승인할 작업
외부 공개와 직접 전송
블로그 공개, SNS 발행, 고객 이메일·메시지 발송은 사람이 대상 계정과 최종 내용을 확인한 뒤 실행한다. 맞춤법이 맞아도 고객명이 틀릴 수 있고, 첨부파일이 이전 버전일 수도 있다. 예약 발행 역시 외부 공개이므로 예약 시각과 시간대를 함께 보여줘야 한다.
돈, 계약, 계정 권한
결제, 환불, 가격 변경, 유료 서비스 가입, 계약 수락, 사용자 초대와 관리자 권한 부여는 자동 추론으로 확정하지 않는다. 자동화는 주문이나 청구 상태를 모으고 비교표를 준비할 수 있지만 최종 의사결정과 인증은 사람이 직접 맡는다. 인증창이나 비밀번호 입력도 에이전트에게 넘기지 않는다.
삭제, 덮어쓰기, 대량 변경
파일 삭제와 데이터 초기화는 물론, 기존 원고를 같은 이름으로 저장하는 일도 승인 대상으로 본다. 가능한 경우 새 파일로 저장해 차이를 비교하고, 교체 전 백업과 복구 방법을 확인한다. 여러 고객이나 여러 게시물에 동시에 적용되는 변경은 한 건보다 영향 범위가 크므로 대상 목록을 먼저 제시한다.
민감정보의 사용과 이동
개인정보, 건강정보, 결제정보, 비공개 계약자료를 외부 AI 서비스나 다른 저장소로 보내는 작업은 별도의 정책과 동의가 필요하다. “요약만 한다”는 목적이 전송 사실을 없애 주지는 않는다. 필요한 범위로 최소화하고, 가능하면 식별값을 제거한 사본을 준비한다.
승인 카드에 보여줄 항목
- 대상: 고객 ID, 계정, 문서 또는 게시물의 식별자
- 행동: 공개, 전송, 교체, 삭제 등 실제로 바뀌는 상태
- 범위: 한 건인지 여러 건인지, 첨부파일이 포함되는지
- 최종본: 사람이 직접 열어 확인할 수 있는 미리보기 또는 파일
- 되돌리기: 취소·복원 가능 여부와 필요한 절차
- 승인 유효범위: 이번 한 번에만 적용되는지 여부
승인 요청에는 비밀값을 넣지 않는다. 로컬 전체 경로도 필요한 경우가 아니면 작업 루트 기준의 상대경로로 표시한다. 고객 이름이 민감할 수 있는 채널에서는 내부 ID와 최소한의 설명만 쓰고, 자세한 검토는 승인된 화면에서 한다.
단계별 운영 흐름
- 요청을 받으면 대상과 작업을 구조화하고, 모호하면 실행 전에 질문한다.
- 현재 상태를 원본에서 다시 읽는다. 대화 기억을 최신 상태로 가정하지 않는다.
- 외부 반영 없이 초안이나 새 파일을 준비한다.
- 자동 검사와 사람이 볼 미리보기를 만든다.
- 승인 카드에 대상·변경·최종본을 표시하고 멈춘다.
- 명시적 승인을 받은 뒤에도 대상과 현재 상태가 바뀌지 않았는지 재조회한다.
- 승인된 한 건만 실행한다.
- 성공 메시지에 의존하지 않고 외부 상태를 다시 읽어 확인한다.
- 승인 내용과 확인 결과를 비밀정보 없이 기록한다.
실무 예시: 게시물 공개 요청
다음은 절차를 설명하기 위한 가상 예시다. 사용자가 “준비한 글 올려줘”라고 말했을 때 곧바로 공개하지 않는다. 먼저 어느 고객의 어느 글인지 식별하고, 현재 파일과 관리자 화면의 대상 계정이 일치하는지 확인한다. 제목, 본문, 대표 이미지, 공개 범위, 예약 여부를 미리보기로 보여준다. 사용자가 이 특정 버전의 공개를 승인하면 직전에 상태를 다시 확인한 뒤 한 건만 실행한다. 이후 실제 공개 URL과 표시된 제목을 다시 읽는다. 승인 뒤 본문이 수정됐다면 기존 승인은 무효로 보고 새 최종본에 대해 다시 확인받는다.
자주 실패하는 접근
- “외부 작업은 승인받는다”는 문장만 두고 승인 화면에 대상을 표시하지 않는 것
- 채팅의 오래된 “계속 진행해”를 이후 모든 작업의 포괄 승인으로 쓰는 것
- 사용자가 자리를 비우거나 답하지 않은 상태를 묵시적 동의로 처리하는 것
- 도구가 성공 코드를 반환했다는 이유로 게시·전송 결과 확인을 생략하는 것
- 초안 생성 권한을 얻은 에이전트에 삭제·결제 권한까지 한꺼번에 주는 것
- 승인 요청에 비밀번호, 토큰, 전체 고객 목록을 붙이는 것
승인 단계가 많기만 하면 안전한 것도 아니다. 중요하지 않은 내부 조회까지 매번 물으면 사용자가 기계적으로 승인하게 된다. 실패 영향이 낮고 읽기 전용인 작업은 정책으로 허용하고, 영향이 큰 경계에서 필요한 정보를 충분히 보여주는 편이 낫다.
검증 체크리스트
- 승인하지 않은 상태에서 공개·전송·삭제 요청이 실제로 멈추는가
- 승인 카드에 대상 계정, 작업, 범위, 최종본이 모두 보이는가
- 여러 후보가 있을 때 시스템이 임의로 하나를 선택하지 않는가
- 최종본이 바뀌면 이전 승인이 폐기되는가
- 승인 직전과 실행 직후 대상 상태를 다시 읽는가
- 대량 작업은 전체 대상 목록과 건수를 별도로 확인하는가
- 삭제 전 백업과 복원 절차가 실제로 준비되어 있는가
- 로그에 토큰, 인증 헤더, 개인정보가 남지 않는가
- 실패한 작업을 성공으로 보고하지 않는가
보안과 개인정보 주의
최소 권한이 기본이다. 조회용 프로필에는 쓰기 권한을 주지 않고, 게시용 계정도 필요한 사이트와 역할로 제한한다. API 키와 비밀번호는 승인 메시지나 채팅으로 전달하지 않는다. 승인은 인증을 대신하지 않으며, 결제와 보안 설정처럼 민감한 화면은 사용자가 직접 처리한다. 기록을 남길 때도 누가 어떤 고객의 무엇을 승인했는지 필요한 범위만 보관하고 보존 기간을 정한다.
함께 읽을 작업 노트
대상을 잘못 고르는 문제부터 막으려면 CSV 고객사 레지스트리 만드는 방법을 참고할 수 있다. 메시지가 PC 도구 실행으로 이어지는 전체 구조는 Telegram 봇으로 PC 업무를 요청하는 기본 구조에 정리되어 있다.