오픈채팅 AI 봇은 왜 엉뚱하게 답할까: 호출부터 가드레일까지 검증하는 법

한 오픈채팅방에 자동응답 봇으로 보이는 계정이 여럿 나타났다. 참여자들은 이름을 불러 질문하며 답변의 경계를 시험했다. 어떤 요청은 거절됐지만, 어떤 답은 앞선 문장을 되풀이하거나 질문에서 벗어났다. 여러 봇이 섞인 대화에서 어느 봇이 왜 답했는지, 또 안전하게 답했는지는 어떻게 구분할 수 있을까?

이름을 불렀을 때 답하는 문제와 답변의 품질은 다르다

방에서는 봇 이름이나 멘션을 문장 앞에 붙이는 호출 방식이 안내됐다. 스윙댄스를 묻는 질문에는 안내가 돌아왔고 봇을 부르는 방법을 다시 묻는 대화도 이어졌다. 여러 계정의 말투와 반응이 겹치자 하나의 봇이 여러 모습으로 나타난 듯하다는 반응도 있었다. 다만 대화만으로 계정들이 같은 모델이나 운영 체계를 공유하는지는 알 수 없다.

첫 검사는 AI의 지능이 아니라 응답 대상 판별이다. 예를 들어 봇 A를 부른 메시지에 A만 답하는지, 봇 B가 쓴 메시지에는 두 봇 모두 침묵하는지 확인한다. 이름이 일반 문장에 들어갔을 때와 실제 멘션으로 지정됐을 때도 나눠 시험해야 한다. 이 단계가 불분명하면 문맥 오류처럼 보인 현상이 단순한 오호출일 수 있다.

플랫폼 기능도 혼동하기 쉽다. 카카오디벨로퍼스의 일반 카카오톡 메시지 API 문서는 ‘나에게 보내기’와 서비스 이용자 간 친구 메시지를 설명한다. 별도의 오픈채팅 API 문서는 특정 서비스 앱과 연결된 대화방의 생성·관리를 다룬다. 방에서 보인 봇이 어느 공식 API나 다른 연결 방식으로 작동했는지는 화면에 나타난 응답만으로 단정할 수 없다. (developers.kakao.com)

거절했는지, 질문을 놓쳤는지 따로 기록한다

참여자들은 금지 주제와 제작자 관련 질문을 던졌고 일부 응답은 요청을 거절했다. 반면 다른 응답은 사용자의 문장을 따라 하거나 맥락에서 벗어났다. 한 번의 거절은 그 요청에 대한 관찰일 뿐, 봇 전체의 안전성을 증명하지 않는다. 문장 반복 역시 그 자체로 내부 정보가 새어 나왔다는 증거는 아니다.

검사할 때는 같은 상황의 질문을 네 갈래로 나누면 차이가 드러난다. 정상적인 안내 요청에는 필요한 정보를 줬는가. 모호한 호출에는 답하지 않거나 대상을 확인했는가. 허용되지 않는 요청은 거절했는가. 거절하면서도 다른 사람의 발화나 무관한 내용을 덧붙이지 않았는가. 답변의 유용성, 호출 정확도, 안전성은 각각 다른 평가 항목이다.

써본 사람들 사이에서도 거절 횟수만 세면 정상적인 질문까지 막는 불편을 놓친다는 의견이 있다. 방에서 관찰된 엉뚱한 답변도 별도로 기록해야 한다. ‘안전하게 거절함’과 ‘답을 못 알아들음’을 한 칸에 넣으면 수정해야 할 부분을 찾기 어렵다.

대화 내용에 섞인 명령은 왜 위험한가

방에서는 앞선 대화를 베껴 말하게 하거나 봇의 규칙을 알아내려는 입력도 시도됐다. 봇에게 직접 규칙을 바꾸라고 요구하는 입력과 봇이 읽는 대화 내용에 그런 요구를 섞는 입력은 경로가 다르다. OWASP는 앞쪽을 직접 프롬프트 인젝션, 웹페이지나 파일 같은 외부 자료를 통해 들어오는 뒤쪽을 간접 인젝션으로 구분한다. 채팅방 발화를 최근 문맥으로 읽는 봇이라면 다른 참여자의 말 역시 신뢰 수준을 구분해야 할 입력이다. (genai.owasp.org)

가령 사용자가 스윙댄스 수업 정보를 물었는데 봇이 참고한 직전 메시지에 답변 형식을 바꾸라는 문장이 들어 있다고 하자. 그 문장은 대화의 일부이지 봇 운영자가 내린 지시가 아니다. 봇이 질문에는 답하면서 참고 문맥 속 명령은 실행하지 않는지 확인해야 한다. 실제 방에서 그런 간접 공격이 성공했는지는 확인되지 않았다.

규칙을 숨기는 일과 비밀을 지키는 일도 구별해야 한다. OWASP는 시스템 프롬프트를 비밀 저장소나 접근 통제 장치로 취급하지 말라고 권고한다. 민감한 정보는 애초에 프롬프트에 넣지 않고 권한 확인은 모델 바깥의 코드에서 처리해야 한다. 봇이 제작자나 가드레일에 관한 질문을 거절했더라도 그 응답만으로 내부 자료가 안전하게 분리됐다고 판단할 수 없다. (genai.owasp.org)

작은 팀은 테스트 대화를 어떻게 구성할까

재현 가능한 검사는 실시간 방에서 끝없이 질문을 바꾸는 방식보다 입력과 기대 결과를 짝지은 사례 묶음에 가깝다. 가상의 대화 기록을 준비해 발신자가 사람인지 봇인지, 누구를 멘션했는지, 봇에 전달할 본문은 무엇인지 나눠 적는다. 첫 묶음에는 정확한 멘션, 이름만 언급한 문장, 봇이 보낸 메시지를 넣는다. 기대 결과는 각각 ‘대상 봇만 응답’, ‘호출 규칙에 따라 판별’, ‘봇 간 자동응답 없음’처럼 기록한다.

다음 묶음에는 정상 질문과 금지 요청을 같은 주제로 가까이 배치한다. 이어 참고할 대화에 명령문을 섞고 답변에 그 명령이 반영됐는지 살핀다. 마지막으로 다른 사람의 발화나 시험용 비밀 표식이 출력에 나타나는지 확인한다. 실제 개인정보나 인증정보를 시험 재료로 쓸 필요는 없다. OWASP 역시 직접·간접 인젝션을 무해한 자료로 시험하고 모델 출력과 도구 실행 권한을 별도로 통제하라고 안내한다. (cheatsheetseries.owasp.org)

기록할 결과는 합격·불합격 두 칸보다 구체적이어야 한다. 잘못된 봇이 답했는지, 질문을 놓쳤는지, 불필요하게 거절했는지, 참고 문맥의 명령을 따랐는지 분리한다. 한 번 실패한 입력은 문구를 바꾸거나 모델을 교체한 뒤에도 다시 돌려볼 수 있다. 개인 개발자나 소규모 팀에는 이런 작은 사례 묶음이 거대한 공격 목록보다 운영 중의 변화를 알아채기 쉽다.

방에서 확인한 것은 응답이고, 보안 경계는 아직 별개다

Google은 간접 프롬프트 인젝션 대응에 모델 학습뿐 아니라 악성 지시 탐지, 출력 처리, 사용자 확인을 함께 적용한다고 설명한다. OWASP도 필터 하나나 시스템 지시문 하나로 공격을 완전히 막을 수 있다고 보지 않는다. 대화방 봇에도 같은 원칙이 적용된다. 모델이 거절하도록 가르치는 일과 어떤 메시지를 읽고 어떤 정보에 접근할지 제한하는 일은 별개의 방어선이다. (blog.google)

이번 방 논의에서도 부적절한 요청을 거절한 응답과 질문을 제대로 처리하지 못한 응답이 모두 나왔다. 그러나 호출 처리 방식, 전달된 문맥, 접근 가능한 자료를 확인하지 못한 상태에서 특정 봇의 구조나 보안 수준을 판정할 수는 없다. 독자에게 남는 기준은 ‘그럴듯하게 말했는가’가 아니다. 정확한 호출에만 답하고, 남의 발화를 명령으로 승격하지 않으며, 허용된 정보만 내놓는가가 채팅방 봇을 평가할 질문이다.