카카오톡 봇 탁구는 왜 사진을 못 보도록 만들었을까

클코단에서 며칠 전 여러 사람이 한꺼번에 탁구에게 사진을 인식하는지 캐물었다. 외부 이미지 주소를 던진 요청 하나에서 탁구가 답을 하다 말고 멈추자 방은 "레드팀 성공"이라며 술렁였다. 실제로 무슨 일이 있었는지, 카카오톡 봇 생태계와 탁구를 움직이는 코드를 함께 짚어본다.

카카오톡은 애초에 사진을 사진으로 넘기지 않는다

탁구는 방에 사진이 올라와도 "이모티콘이나 사진은 저한테 안 보여요, 카톡이 글자로만 넘겨주거든요"라고 답하도록 만들어져 있다. 탁구가 사용하는 입력 경로에서는 텍스트가 아닌 콘텐츠가 종류를 나타내는 정보로만 전달된다.

공식 봇 API가 아니라 기기의 메시지 데이터베이스를 관찰해 대화를 가져오는 Iris 같은 브릿지는 메시지와 첨부정보를 데이터베이스에서 읽어 전달한다. 이런 브릿지는 카카오톡 약관이 허용하지 않는 방식이라 계정이 정지될 위험까지 감수하고 돌아가는 구조다. 그래서 사진 원본을 끌어와 분석하는 기능까지 욕심내기보다 텍스트 흐름만 안정적으로 다루는 쪽을 택하는 경우가 많다. 사진을 카카오톡 공유 메시지에 넣어 전달하는 경로는 있다. 다만 그건 사진을 "본다"기보다 새 이미지를 얹어 보내는 기능에 가깝다. 누군가 방 안에서 사진을 찍어 올리는 순간, 탁구 입장에서는 "사진 한 장이 왔다"는 사실만 남고 그 안에 뭐가 있는지는 처음부터 도착하지 않는다.

사진을 안 보는 건 로드맵에도 적힌 결정이다

개발자가 방에서 "처리 속도 때문에 막아놨다"고 설명한 배경은 이 프로젝트의 기능 확장 계획서에도 그대로 남아 있다. 계획서는 이미지 비전 분석을 "Phase 3 이후 후보"로 미뤄두고, 지금 단계에서는 사진이 왔다는 사실과 보낸 사람·시각만 기록해 요약에 "이미지 N장 공유"라는 문구로만 흔적을 남기도록 정해뒀다. 원본은 로컬에 격리해 저장하고 공개 웹에는 올리지 않는다. 운영진에게도 URL이나 경로는 노출하지 않는다는 조항까지 있다. 새 LLM 호출을 거의 만들지 않는 선택이다. 계획서는 이를 방 규모(약 666명)에서 사진마다 모델을 태우는 비용을 감당하지 않겠다는 결정이라고 못 박아 둔다.

실제로 비전 기능을 켜면 속도 문제는 숫자로도 드러난다. 비전 모델 비교에서는 모델 간 응답 시간에 격차가 나타난다. 이미지 한 장을 붙일 때 드는 토큰도 해상도에 따라 1,000토큰대까지 붙는다. 대화가 이어지며 앞서 올라온 사진까지 매번 다시 붙여 보내는 구조라면 그 부담은 방 하나가 아니라 대화 턴마다 누적된다. 이런 수치는 비전 기능에 속도와 토큰 부담이 따른다는 점을 보여준다.

이런 절충은 탁구만의 사정이 아니다. 같은 카카오톡 위에서 사진을 실제로 "읽는" 챗봇으로는 업스테이지의 아숙업(AskUp)이 있다. 2023년 출시 당시부터 문서 사진을 올리면 광학문자인식(OCR)으로 글자를 뽑아 요약해주는 방식으로 화제를 모았고, 서비스 소개에 따르면 출시 사흘 만에 채널 친구 3만 명을 넘겼다. 다만 아숙업의 방식은 범용 비전보다 글자를 뽑아내는 OCR에 가깝다. 탁구의 "존재만 표기" 방식과 아숙업의 OCR 방식은 이미지 전체를 범용 비전 모델에 직접 입력하지 않는다는 점은 같다.

사진 대신 링크를 주면 다른 문이 열려 있었다

방 사람들이 이번에 시도한 방법은 사진 파일이 아니라 이미지 주소(URL)를 문장에 넣는 것이었다. 이 경로는 탁구에게 실제로 뚫린 전례가 있다. 방에 올라온 사진은 로컬에만 저장하고 모델에 넘기지 않는다. 그런데 같은 사진을 다른 곳에 올려 그 주소를 링크로 주면 링크 요약 기능이 페이지를 통째로 받아와 버리는 사고가 있었다. 위키미디어 이미지 주소 하나를 요약시켰더니 토큰이 대량으로 소모됐다. 평소보다 비용도 크게 뛰었다. 격리해서 안 보여주기로 한 원칙이 URL 한 줄로 우회된 사례다.

그 뒤로는 확장자와 실제 파일 종류(Content-Type)를 먼저 확인해 이미지로 판정되면 요약 대상에서 걸러내도록 고쳐졌다. 외부 웹 콘텐츠를 자동으로 받아와 처리하는 챗봇·에이전트에서 이런 허점은 드물지 않다. 사용자가 준 URL을 서버가 자동으로 가져오는 기능은 서버 사이드 요청 위조(SSRF) 방어 관점에서도 주의가 필요하다. 에이전트가 URL을 스스로 판단해 열어보는 구조라면 그 판단 하나하나가 공격 표면이 된다는 지적이 최근 AI 에이전트 보안 논의에서 반복해서 나온다.

그날 방에서 멈춘 화면은 뚫림이 아니라 방어였다

정황을 맞춰보면 그날 탁구가 답변 도중 멈춘 장면은 새로운 우회가 성공한 순간이라기보다, 이미 고쳐둔 필터가 이미지 주소를 뒤늦게 잡아채 요약을 중단시킨 결과에 가깝다. 링크를 받으면 일단 페이지 성격을 판단하는 동작이 먼저 시작된다. 그 사이에 이미지로 판정되면 처리가 끊긴다. 밖에서 보기엔 뭔가 시도하다 급히 멈춘 모양으로 보일 만하다.

방에서 나온 "URL·문맥만으로 추론했을 가능성" 지적도 방향은 맞다. 실제로 사진 픽셀을 받아 보는 경로 자체가 탁구에는 없다. 그러니 그럴듯한 답이 나왔다면 주소나 대화 맥락에서 짐작한 텍스트일 뿐 화면을 본 결과가 아니다. 모델이 이미지를 직접 참조하지 않고 그럴듯한 설명을 지어내는 것은 환각의 한 형태다. 새 챗봇이 나올 때마다 이런 한계를 캐묻는 시도가 곧바로 뒤따른다. 진짜와 흉내를 가려내는 과정 자체를 놀이로 즐기는 분위기도 흔하다.

이번 소동은 사진을 못 보게 한 설계가 실전에서도 유지됐다는 점을 보여준다. 우회가 성공한 건 아니었다. 사람 많은 커뮤니티 봇을 개인이 운영한다면, 모든 사진을 매번 비전 모델에 태우는 대신 "존재만 표기하고 원본은 격리 저장"하는 절충도 고려할 만하다. 남는 질문은 이 절충이 언제까지 유지되느냐다. 계획서의 Phase 3이 열리는 날 탁구가 사진을 정말 읽기 시작할지, 아니면 존재 표기만으로 충분하다는 판단이 굳어질지는 아직 정해지지 않았다.