개인 AI 봇을 카카오톡에 붙일 수 있을까: 오픈채팅·채널·텔레그램의 차이

AI 에이전트를 컴퓨터 밖에서도 부르고 싶다면 익숙한 카카오톡부터 떠올리기 쉽다. 하지만 ‘카카오톡에 봇을 붙인다’는 말에는 오픈채팅 참여, 채널 응대, 자기 자신에게 알림 보내기가 뒤섞여 있다. 개인용 에이전트를 대화로 제어하려면 실제로 열려 있는 경로는 무엇일까?

OMO를 설치해도 메시지 통로가 생기지는 않는다

커뮤니티에서는 OMO가 무엇인지 묻는 질문이 개인 봇 이야기로 이어졌다. OMO는 oh-my-opencode라는 이름으로 알려진 에이전트 하네스다. 현재 프로젝트 문서는 Oh My OpenAgent라는 이름도 사용하며, 여러 에이전트와 도구를 조율하는 기능을 설명한다. 하네스를 쓴다고 해서 카카오톡 메시지를 받거나 보낼 권한이 생기지는 않는다. (omo.dev)

휴대전화에서 작업을 지시하려면 입구와 실행부를 나눠야 한다. 메신저가 요청을 받고, 브리지 서버가 보낸 사람과 명령을 확인한 뒤 에이전트에 전달한다. 실행 결과를 다시 메신저 형식에 맞춰 돌려줘야 대화가 완성된다. 방에서도 카카오톡을 에이전트 자체가 아니라 연결 화면으로 보는 의견이 나왔다.

이 구분은 OMO를 쓰지 않아도 같다. 백엔드가 OpenCode든 직접 만든 API든, 메신저가 제공하는 수신·응답 방식에 맞춰야 한다. 먼저 확인할 것은 모델 성능이 아니라 원하는 채팅방에 공식 연결 경로가 있는지다.

오픈채팅과 카카오톡 채널은 다른 출입구다

여럿이 모인 오픈채팅방에 봇 계정을 넣고 모든 발화를 읽는 모습부터 상상하기 쉽다. 그러나 카카오디벨로퍼스의 공개 메시지 문서는 오픈채팅방의 대화를 받아 처리하는 범용 봇 API를 안내하지 않는다. 과거 카카오 공식 개발자 게시판에서도 오픈채팅 API는 제공하지 않는다고 답했다. 공개 문서와 답변만으로 향후 제공 여부까지 단정할 수는 없지만, 현재 구현 계획을 그 API에 기대기는 어렵다. (devtalk.kakao.com)

공식적으로 문서화된 대화형 경로는 카카오톡 채널 챗봇이다. 사용자가 채널 봇에 말을 걸면 설정한 블록에 연결된 스킬 서버가 HTTP POST로 요청을 받는다. 서버는 사용자 발화 등이 담긴 JSON을 읽고 응답 JSON을 반환한다. 카카오비즈니스 가이드는 스킬 서버 등록, 블록 연결, 테스트와 채널 배포 절차를 각각 설명한다. (business.kakao.com)

따라서 채널 챗봇은 고객이나 구성원이 채널에 질문하는 서비스에 맞는다. 이미 운영 중인 오픈채팅방의 발화를 같은 방식으로 가져오는 기능은 아니다. 방에서 오픈채팅용 봇과 개인 봇의 설계가 다르다는 의견이 나온 이유도 여기에 있다. 어느 방에서 대화할지 결정하면 사용할 수 있는 연결 방식부터 달라진다.

‘나에게 보내기’는 개인 비서와 어디가 다른가

카카오톡 메시지 API에는 자기 자신에게 메시지를 보내는 기능이 있다. 카카오의 튜토리얼은 개발자 앱을 만들고, 카카오 로그인을 설정한 뒤 메시지 전송 동의를 거쳐 템플릿을 발송하는 순서를 제시한다. 자동화 작업이 끝났다는 결과를 ‘나와의 채팅’으로 받는 용도라면 이 경로가 유용하다. (developers.kakao.com)

다만 발송 API가 곧 대화 수신 API는 아니다. 나에게 보낸 메시지에 사용자가 답장했다고 해서 그 답장이 개발자 앱의 에이전트로 전달되는 경로가 제공되는 것은 아니다. 카카오의 친구 메시지 기능도 자유로운 봇 발송 수단과는 다르다. 카카오 공식 튜토리얼은 사용자가 서비스 안에서 친구를 선택하는 흐름을 설명하며, 서비스가 사용자에게 자동 발송하는 용도가 아니라고 명시한다. (developers.kakao.com)

개인 개발자에게는 여기서 실용적인 선택지가 갈린다. 필요한 게 작업 완료 알림이면 ‘나에게 보내기’를 검토할 수 있다. 카카오톡 안에서 질문을 입력하고 답을 받으려면 채널 챗봇의 사용 흐름을 검토해야 한다. 일반 개인 채팅이나 오픈채팅을 채널 챗봇과 같은 것으로 취급하면 설계가 처음부터 어긋난다.

텔레그램으로 개인 봇을 만들 때의 실제 순서

개인 대화형 봇이 목표라면 텔레그램은 입구가 더 명확하다. 공식 안내에 따르면 BotFather에서 봇을 만들고 토큰을 받은 뒤 Bot API로 메시지를 주고받는다. 입력은 getUpdates로 가져오거나 setWebhook으로 받을 수 있다. 두 방식을 동시에 쓰지는 않으며, 답장은 sendMessage로 보낸다. (core.telegram.org)

구현 순서는 구체적이다. 개인 채팅에서 보낸 텍스트를 수신하고, 허용한 사용자와 채팅인지 확인한다. 브리지는 그 텍스트를 에이전트의 입력으로 넘긴다. 응답에서 사용자에게 보여줄 부분만 추려 원래 채팅에 보낸다. 입력은 채팅 메시지이고, 산출물은 에이전트의 답변이나 작업 상태다. 직접 서버를 운영한다면 처음에는 폴링으로 입출력을 시험하고, 외부에서 받을 주소가 필요할 때 웹훅을 검토할 수 있다.

OpenCode를 실행부로 택하는 경우에는 공식 문서의 opencode serve가 HTTP 서버를 제공한다. 문서에는 세션 생성과 세션에 메시지를 보내는 API도 명시돼 있다. 브리지가 세션을 만들고 메시지를 전달한 다음 응답을 텔레그램으로 돌려주는 구성이 가능하다. 이것은 공식 기능을 조합한 구현 경로이지, OMO 설치만으로 완성되는 기능은 아니다. (dev.opencode.ai)

써본 사람들 사이에서는 휴대전화로 작업 상태를 확인하는 편리함과 긴 작업의 진행 상황을 채팅 화면에 제대로 보여주기 어렵다는 반응이 함께 나온다. 그래서 답변 한 줄만 돌려주는 봇과 세션·진행 상태까지 보여주는 원격 클라이언트는 필요한 작업량이 다르다.

대화 상대가 늘어나면 권한 설계도 바뀐다

개인 봇에서는 허용할 채팅을 좁히는 일이 먼저다. 텔레그램 공식 문서는 봇 토큰을 가진 사람이 봇을 제어할 수 있다고 경고한다. OpenCode 서버 문서도 기본 접속 주소가 로컬이며, 서버를 보호할 인증 설정을 제공한다고 안내한다. 메신저 명령을 곧바로 파일 수정이나 셸 실행에 연결한다면 사용자 확인과 도구 권한을 브리지에서 분리해야 한다. (core.telegram.org)

그룹에서는 문제가 달라진다. 텔레그램 봇은 기본적으로 Privacy Mode를 사용해 관련 명령과 답장 위주로 수신한다. 모든 발화를 읽도록 바꾸는 일은 기능뿐 아니라 참여자의 기대에도 영향을 준다. 반면 카카오톡 채널 챗봇은 채널에 말을 건 사용자를 응대하는 구조다. 두 방식 모두 ‘메신저에 붙였다’고 부를 수 있지만, 누가 봇에게 말을 거는지부터 다르다. (core.telegram.org)

방의 질문을 구현 조건으로 바꾸면 답은 선명해진다. 오픈채팅 참여 봇, 채널 응대 봇, 혼자 쓰는 원격 에이전트는 같은 프로젝트가 아니다. 개인 작업을 대화로 제어하려는 경우, 카카오톡에 얼마나 익숙한지보다 입력을 공식적으로 받을 수 있는가가 첫 번째 갈림길이다.