## 한 줄 요약
AI가 만든 브리핑을 지정된 카카오톡 단톡방에 공유할 때, 방 이름을 정확히 확인하고 동명이면 전송을 차단하는 안전장치를 설계했다.
## 이런 분께 도움이 된다
- 여러 단체방이나 고객 채널에 같은 공지를 보내는 운영자
- 비슷한 이름의 채팅방 때문에 오발송이 걱정되는 분
- AI 자동화를 도입하고 싶지만 마지막 전송 단계가 불안한 분
- 성공 여부가 애매할 때 중복 전송되는 문제를 피하고 싶은 분
## 시작한 이유
콘텐츠를 만드는 일과 실제로 보내는 일은 전혀 다른 문제였다. 브리핑 내용이 좋아도 엉뚱한 방에 보내면 자동화는 실패다. 비슷한 이름의 방이 있거나 검색 결과가 여러 개일 때는 더 위험하다.
처음에는 대상 방 이름 목록만 있으면 충분할 것 같았다. 실제 화면에서 검색해 보니 공백, 기호, 이모지처럼 작은 차이가 있었고, 일반 채팅과 공개 채팅의 검색 위치도 달랐다. 검색 결과 첫 번째 항목을 무조건 누르는 방식은 사용할 수 없었다.
그래서 이 작업의 기준을 "빨리 보내기"가 아니라 "확실한 경우에만 한 번 보내기"로 바꿨다.
## 사용한 도구
- Hermes Agent: 전송 절차와 차단 조건 설계
- Python 방 안전검사기: 허용 목록과 검색 결과 비교
- Windows 화면 자동화 도구: 카카오톡 검색, 입력, 전송 후 상태 확인
- 브리핑 검사기: 내용 검사를 통과한 문서만 전송 단계로 넘김
## AI와 함께 만든 과정
처음 세운 요청은 다음과 같았다.
승인한 채팅방에만 보내고, 이름이 같은 방이 둘 이상이면 절대 보내지 않게 해 줘.이 요청을 실제 규칙으로 바꾸면서 전송 전후의 조건을 나눴다.
### 전송 전 확인
- 설정 파일의 허용 목록에 있는 방만 대상으로 삼는다.
- 검색한 이름과 실제 창 제목을 비교한다.
- 같은 이름의 후보가 두 개 이상이면 중단한다.
- 브리핑 내용 검사가 통과하지 않으면 전송 단계로 넘어가지 않는다.
- 시연용 가상 데이터나 예시 링크가 남아 있으면 중단한다.
- 입력창에 기존 초안이 남아 있으면 새 내용을 붙여넣지 않는다.
### 전송 후 확인
- 전송 뒤 입력창이 비워졌는지 확인한다.
- 새 메시지의 제목과 날짜를 다시 읽어 본다.
- 전송 결과가 애매하면 자동으로 다시 보내지 않는다.
- 실패한 방을 다른 비슷한 방으로 대체하지 않는다.
- 방별 결과를 따로 기록한다.
이 규칙을 검사하기 위해 두 가지 예제를 만들었다. 하나는 정확히 일치하는 방이 하나인 경우였고, 다른 하나는 같은 이름의 후보가 두 개인 경우였다. 첫 예제는 통과했고, 두 번째 예제는 의도대로 차단됐다.
작업 중에는 화면 자동화가 항상 같은 방식으로 움직이지 않는다는 것도 확인했다. 창 위치가 달라지거나 앱이 잠금 상태가 되면 클릭 결과가 달라질 수 있었다. 이때 무리하게 계속 누르지 않고 중단하도록 설계했다. 자동화에서 실패를 숨기지 않는 것이 기능을 하나 더 추가하는 것보다 중요했다.
## 결과
최종 스킬에는 콘텐츠 생성 규칙뿐 아니라 공유 단계의 안전장치도 포함됐다.
- 허용된 대상만 처리
- 방 이름 일치 여부 확인
- 동명 후보가 있으면 차단
- 내용 검사 통과 후에만 전송
- 방마다 한 번만 전송
- 결과가 불확실하면 자동 재시도 금지
- 전송 결과 기록
### 전과 후
| 항목 | 단순 자동화 | 안전장치를 넣은 방식 |
|---|---|---|
| 대상 선택 | 검색 결과 첫 항목 클릭 | 허용 목록과 실제 창 제목 비교 |
| 동명 채널 | 잘못 선택할 가능성 | 후보가 여러 개면 차단 |
| 내용 상태 | 만들어진 문서를 바로 전송 | 검사 통과 문서만 전송 |
| 실패 처리 | 반복 클릭하거나 재전송 | 중단 후 원인 기록 |
| 성공 확인 | 입력 동작으로 성공 추정 | 입력창과 새 메시지를 다시 확인 |
이 결과는 "모든 상황에서 자동으로 보낸다"는 시스템이 아니다. 조건이 맞지 않으면 보내지 않는 시스템이다. 커뮤니티 운영에서는 이쪽이 훨씬 현실적이었다.
## 작업하면서 배운 점
첫째, 자동화에서는 멈추는 조건을 먼저 정해야 했다. 성공 절차만 만들면 예외 상황에서 엉뚱한 행동을 할 수 있다.
둘째, 화면에서 보이는 이름과 사람이 부르는 이름은 다를 수 있었다. 공백과 기호까지 포함한 실제 표시명을 따로 기록하는 작업이 필요했다.
셋째, "전송 명령을 실행했다"와 "상대방에게 정상적으로 보였다"는 같은 뜻이 아니었다. 전송 후 상태를 다시 읽는 과정이 필요했다.
넷째, 결과가 불확실할 때 자동 재시도하지 않는 원칙이 중복 메시지를 막아 줬 다. 실패를 성공처럼 보고하는 것보다 멈추고 알리는 편이 안전했다.
## 다른 업무에 적용한다면
같은 방식은 이메일 수신자 확인, 파일 업로드 대상 확인, 고객별 보고서 배포에도 적용할 수 있다. 다음 네 가지를 정하면 된다.
1. 허용된 대상 목록
2. 대상이 하나임을 증명하는 방법
3. 실행 전에 확인할 내용 조건
4. 실행 뒤 성공을 확인하는 방법
## 앞으로의 계획
초기에는 소수의 승인된 채널에서 사람이 결과를 확인하고, 충분히 안정적일 때만 자동 전송 범위를 넓힐 예정이다. 새 채널을 추가할 때도 이름과 접근 상태를 먼저 확인하고 허용 목록에 넣은 뒤 테스트한다.
## 재사용 가능한 프롬프트
> 여러 채널에 같은 내용을 배포하는 자동화를 설계해 줘. 허용 목록에 없는 대상은 제외하고, 이름이 정확히 일치하는 후보가 하나일 때만 실행해 줘. 후보가 여러 개이거나 결과가 불확실하면 중단하고, 자동 재시도나 비슷한 대상 대체는 하지 마. 실행 전 내용 검증과 실행 후 성공 확인 절차도 포함해 줘.
