친구톡 종료와 3시간 45분의 탐색 - 알림톡+친구톡에서 알림톡+상담톡으로
전환점: 카카오톡 친구톡 서비스 2025년 12월 31일 종료
알림톡 (정보 전달) → 채널 추가 유도 → 친구톡 (양방향)이 설계는 giftcall-kakao-implementation.html에 상세히 기록되어 있습니다:
2026년 1월 6일 월요일 아침, 친구톡 종료 이후 어떻게 양방향 소통을 구현할지 고민하기 시작했습니다. 이미 알림톡 템플릿 설계와 LLM 메시지 생성 시스템은 구축해둔 상태였지만, 고객의 답장을 받을 방법이 막막했습니다.
과정: 3시간 45분 동안 3단계에 걸친 전략 변화
알림톡 (정보 전달) → 채널 추가 유도 → 친구톡 (양방향)알림톡 (정보 전달) → 채널 추가 유도 → 브랜드메시지 (양방향)친구톡이 종료되었으니 브랜드메시지를 사용하면 되지 않을까? 브랜드메시지도 채널 친구를 대상으로 양방향 소통이 가능하다고 문서에 나와 있었습니다.
하지만 알림톡 템플릿에 "채널 추가" 유도 문구를 넣으려고 하니 문제가 생겼습니다:
알림톡 (정보 전달) → 고객 답장 → 상담톡 자동 시작 (양방향)카카오톡 문서를 더 찾아보다가 "상담톡"이라는 서비스를 발견했습니다. 알림톡에 답장하면 자동으로 상담톡 세션이 시작된다는 내용이었습니다.
이해를 돕기 위해 3가지 서비스를 비교하는 표를 만들었습니다:
| 항목 | 알림톡 | 브랜드메시지 | 상담톡 |
|---|---|---|---|
| 메시지 성격 | 정보성 (일방향) | 광고성 (양방향) | 상담 (양방향) |
| 채널 친구 추가 | 불필요 | 필요 | 불필요 ⭐ |
| 양방향 소통 | ❌ | ✅ | ✅ ⭐ |
| 발송 시작 | 기업 → 고객 | 기업 → 고객 | 고객 답장 시 |
| 템플릿 심사 | 엄격 (정보성만) | 유연 (광고 가능) | 불필요 |
| 우리 프로젝트 | 50% | 80% | 95% ⭐ |
게임 체인저: 알림톡 → 상담톡 전환
상담톡을 발견하고 나서 가장 궁금했던 것은 "정말 작동하는가?"였습니다. 문서만 보고 판단하기에는 불안했습니다. 그래서 메가버드에 직접 테스트를 요청했습니다.
메가버드 담당자가 실제로 알림톡을 발송하고 답장을 보내는 테스트를 진행했습니다. 결과는 성공! 알림톡에 답장하니 자동으로 상담톡 세션이 시작되었습니다.
상담톡 전환이 확인되자 템플릿 문구를 수정했습니다. "채널 추가"를 유도하는 대신 "이 메시지에 답장해주세요"로 변경했습니다:
안녕하세요 #{name}님,
#{store_name}입니다.
#{sender_name}께서
#{sender_occasion}
#{product_name}을(를) 보내주셨습니다.
냉장 제품으로 직접 수령이 필요하여
배송 정보를 확인 부탁드립니다.
📍 배송지: #{address}
📦 배송 가능일: #{delivery_date}
배송지 변경이나 일정 조율이 필요하시면
이 메시지에 답장해주세요.
감사합니다."이 메시지에 답장해주세요" → 상담톡 세션 시작
이 한 줄이 전체 시스템의 핵심입니다. 채널 추가 없이도 양방향 소통이 가능해졌습니다.
확인 과정: 딜러사를 통한 문의
상담톡 발견 후 확실하게 하기 위해 카카오 비즈센터에도 문의했습니다. 하지만 예상치 못한 답변을 받았습니다:
"알림톡은 기술지원이 필요한 API 상품으로 공식 딜러사를 통해 이용 가능한 서비스입니다. 이에 따라, 알림톡 탬플릿의 심사 가이드, 반려 사유, 반려 요청, 긴급 검수 등에 대해서는 비즈메시지 고객센터에서는 확인이 어렵습니다. 심사 관련하여서는 딜러사에서 비즈메시지 라운지로 확인을 해야 하는 내용으로 이용 중인 딜러사로 문의하여서 확인 부탁드립니다."
카카오 비즈센터가 직접 답변하지 않는다는 것을 알고, 메가버드에 다시 문의했습니다:
질문:
답변:
메가버드 답변이 "상담톡 아님"이라고 하니 혼란스러웠습니다. 그런데 실제 테스트에서는 답장이 가능했습니다. 그렇다면 이것은 브랜드메시지인가? 아니면 다른 무언가인가?
병행 작업: 전략 탐색과 동시에 개발 진행
메시징 전략을 탐색하는 동안에도 개발은 계속 진행했습니다:
PUT /api/v1/messages/{id} - 메시지 업데이트 (draft → sent)POST /api/v1/messages/{id}/regenerate - LLM 메시지 재생성messageService.js 생성 (API 호출 분리)StatusBar.vue - 실시간 통계 (발송/응답/대기/확정)Toast.vue - 우측 하단 알림처음부터 양방향일 필요는 없습니다. 고객이 필요할 때만 답장하면 되는 것이 오히려 더 자연스럽습니다. 강제로 채널 추가를 유도하는 것보다 훨씬 UX가 좋습니다.
이번 작업을 통해 카카오톡 메시징 서비스의 구조를 이해하게 되었습니다:
문서만 보면 알 수 없는 것들이 많습니다. 직접 받아보고 답장해보니 비로소 확신이 생겼습니다. "메시지 발송 가능한가요?" → "가능합니다" ✅
친구톡 종료라는 예상치 못한 변수가 생겼지만, 오히려 더 나은 방법(상담톡)을 찾게 되었습니다. 유연하게 대응하는 것이 중요합니다.