매일 한 명에게 카톡 보내기가 어려운 이유 — 플랫폼 정책이라는 벽

가족 한 명에게 매일 정해진 시각에 같은 메시지를 보내는 자동화를 만들려고 했다. 약 먹을 시간 알림 같은 것이다.

기술적으로는 간단해 보였다. 카카오톡에 “친구에게 메시지 보내기” REST API가 있고 무료다. 스케줄러 걸고 호출하면 끝이라고 생각했다.

실제로 시간을 다 쓴 건 코드가 아니라 정책 이해였다.

벽 1: 아무에게나 못 보낸다

카카오 정책상 친구 메시지 API는 “같은 앱에 로그인하고 동의한 친구” 에게만 보낼 수 있다.

즉 받는 사람도 한 번은 이 앱에 카카오 로그인을 하고 “메시지 전송” 동의를 해야 한다. 내가 만든 앱인데, 받는 사람이 그 앱에 로그인해야 한다.

처음엔 이게 이상하게 느껴졌다. 내 친구에게 내가 메시지를 보내는 건데 왜.

생각해보면 당연한 설계다. 이 제약이 없으면 누구나 친구 목록 전체에 스팸을 보낼 수 있다. 카카오 입장에서는 막아야 하는 경로다. 불편한 게 아니라 그러라고 만든 것이다.

벽 2: 검수를 받아야 한다

두 번째 벽은 권한 검수다. 친구 메시지 전송 권한을 정식으로 쓰려면 비즈 앱으로 전환하고(사업자 등록 필요) 검수를 신청해야 한다.

가족 한 명에게 하루 한 번 보내려고 사업자 등록을 할 수는 없었다.

우회하지 않고 안에서 푸는 방법

여기서 선택지가 갈린다.

우회 경로는 있다. 카카오톡 자동화 앱을 쓰거나, 웹 자동화로 로그인해서 메시지를 보내거나. 검색하면 방법이 나온다.

이걸 안 하기로 했다. 이유는 두 가지다.

첫째, 계정이 정지될 수 있다. 가족에게 알림 보내려다 카톡 계정을 잃으면 손해가 훨씬 크다.

둘째, 깨진다. 공식 API가 아닌 경로는 상대가 바꾸면 그날 죽는다. 매일 돌아야 하는 알림인데 언제 죽을지 모르는 구조로 만들 수 없다.

그래서 정책 안에서 방법을 찾았다.

팀 멤버 모드

카카오 개발자 콘솔에는 팀 관리 기능이 있다. 앱에 팀 멤버를 초대할 수 있다.

받는 사람을 팀 멤버로 초대하고, 그 사람이 초대를 수락하면(개발자 약관에 1회 동의) 검수 없이도 발송 대상이 된다.

정리하면 이렇다.

• 나와 받는 사람이 둘 다 팀 멤버다
• 검수 신청이 필요 없다
• 검수 전 발송 건수 쿼터가 있지만 하루 1건에는 영향이 없다

개인용 1:1 리마인더라면 여기까지로 충분하다. 비즈 앱 전환도, 사업자 등록도 필요 없다.

이 방법의 한계는 명시해뒀다

다만 정직하게 적어둘 게 있다. 팀 멤버 모드는 본래 개발·테스트용 통로다.

가족이나 지인에게 소량 발송하는 용도로는 현실적으로 계속 쓸 수 있지만, 카카오가 “상시 서비스”로 공식 보장하는 방식은 아니다. 정책이나 쿼터가 바뀌면 영향을 받을 수 있다.

이걸 README 맨 위에 적어뒀다. 나중에 갑자기 안 되기 시작했을 때 “왜 안 되지”로 헤매지 않기 위해서다. 알려진 취약점은 발견 시점에 기록해두는 게 낫다.

설정 절차가 코드보다 길었다

실제로 완성하고 보니 README의 대부분이 카카오 개발자 콘솔 설정 절차였다.

1. 애플리케이션 추가
2. REST API 키 복사
3. 카카오 로그인 활성화
4. Redirect URI 등록 (.env 값과 정확히 일치해야 함)
5. 동의항목에서 talk_message, friends 켜기
6. 받는 사람을 팀 멤버로 초대
7. (선택) Client Secret 설정

코드는 스케줄러와 토큰 갱신이 전부였다.

이런 프로젝트에서는 설정 절차 자체가 산출물이다. 반년 뒤에 다시 세팅할 때 이 목록이 없으면 처음부터 헤맨다. 코드보다 이 문서가 오래 쓸모 있을 가능성이 높다.

특히 4번(Redirect URI 정확히 일치)은 실제로 한 번 틀려서 시간을 썼다. 오류 메시지가 친절하지 않아서 원인 찾기가 어려웠다. 이런 건 겪은 사람이 적어두지 않으면 다음 사람도 똑같이 겪는다.

토큰 갱신

마지막으로, 카카오 액세스 토큰은 만료된다. 리프레시 토큰으로 갱신해야 한다.

매일 도는 서비스라 여기서 실패하면 조용히 알림이 멈춘다. 조용히 멈추는 게 가장 나쁜 실패 모드라, 갱신 실패 시 로그에 남기고 눈에 띄게 만들었다.

앞서 알림 시스템 글에서 “아무 일 없어도 정기 브리핑을 보낸다”고 적은 것과 같은 이유다. 아무것도 안 오는 상태와 죽은 상태를 구분할 수 있어야 한다.

정리

• 플랫폼 API 를 쓸 때 진짜 벽은 기술이 아니라 정책일 때가 많다
• 스팸 방지 제약은 불편한 게 아니라 그러라고 있는 것이다. 우회 대상이 아니다
• 우회 경로는 계정 정지 위험과 “상대가 바꾸면 죽는” 취약함을 함께 가진다
• 정책 안에 개인용 통로가 있는 경우가 있다(팀 멤버 모드). 먼저 찾아본다
• 정식 보장이 아닌 방법을 쓸 때는 한계를 문서 맨 위에 적는다
• 설정 절차가 코드보다 중요한 프로젝트가 있다. 그게 진짜 산출물이다
• 매일 도는 자동화는 조용히 멈추지 않게 만든다