← 설명서로 돌아가기

봇의 탄생 일화

작성일: 2026년 7월 1일

1. 왜 이 봇을 만들었나요?

치지직에는 '라운지 알림'이 없습니다

치지직에는 스트리머들이 팬들과 일상을 나누고 방송 일정이나 공지사항을 올리는 커뮤니티(라운지) 공간이 있습니다. 유튜브 커뮤니티 탭이나 트위터(X)와 비슷한 기능이라고 생각하시면 됩니다.

그런데 한 가지 아주 불편한 점이 있었습니다. 스트리머가 라운지에 새 글을 올려도 팬들에게 알림을 보내는 기능이 치지직 앱이나 웹에 아예 존재하지 않았습니다. 실시간 방송이 시작되면 알림이 오는 것과 달리, 공지글은 직접 들어가서 확인해야만 했습니다.

스트리머들이 선택한 불편한 해결책 — 네이버 카페

이 문제 때문에 많은 스트리머들이 어쩔 수 없이 같은 회사(네이버)에서 운영하는 '네이버 카페' 서비스를 별도로 사용하여 공지를 올려왔습니다. 카페에 글을 올리면 카페 앱을 통해 알림이 가기 때문입니다.

하지만 이 방식에는 스트리머와 시청자 모두에게 불편함이 있었습니다.

• 스트리머 입장에서는 시청자 간의 친목, 스팸, 욕설 등을 관리해야 하는 운영 부담이 있고, 시청자 입장에서는 스트리머가 카페에 공지를 올릴 경우 알림을 받기 위해 개별 카페에 가입해야 하는 번거로움이 있었습니다.

그래서 직접 만들었습니다

"팬들이 이미 모여 있는 디스코드나 개인이 별도로 스트리머의 커뮤니티 공지를 그대로 받아볼 수는 없을까?"

이 단순하고 직관적인 아이디어에서 봇 개발이 시작되었습니다. 스트리머는 치지직 라운지에만 글을 쓰면 되고, 주로 디스코드를 사용하는 시청자는 디스코드를 떠나지 않고 그 자리에서 알림을 받을 수 있도록 하는 것이 목표였습니다.

카페 가입도 없고, 추가 앱 설치도 없고, 두 군데 글 올리는 수고도 없습니다. 치지직과 디스코드를 바로 잇는 연결고리 역할을 합니다.

2. 어떻게 만들었을까요?

네이버는 공식적으로 알림용 통로를 열어두지 않았습니다

앱이나 웹 서비스에서 외부 개발자가 데이터를 가져오려면, 서비스 회사가 공식적으로 '데이터 연결 통로(API)'를 열어두어야 합니다. 마치 회사 건물에 손님이 들어오려면 정문이 있어야 하는 것처럼요.

몇몇 플랫폼은 방송 시작 여부나 커뮤니티 데이터를 외부에서 가져갈 수 있는 공식 통로를 제공합니다. 하지만 네이버 치지직은 라운지(커뮤니티) 데이터를 외부에서 가져올 수 있는 공식 통로를 제공하지 않았습니다. 검색해봐도 관련된 공식 문서나 개발자 가이드가 전혀 없습니다.

직접 치지직 웹사이트를 분석하여 숨겨진 통로를 찾아냈습니다

공식 통로가 없다고 해서 방법이 없는 건 아닙니다. 저는 브라우저에서 치지직 웹사이트가 어떻게 데이터를 주고받는지를 직접 분석하는 방식으로 접근했습니다.

쉽게 비유하면, 레시피를 공개하지 않는 음식점의 요리를 먹어보면서 "이 재료가 들어갔겠구나"를 하나씩 추론하는 과정과 비슷합니다. 치지직 웹사이트가 서버와 어떤 데이터를 주고받는지, 어떤 형식으로 요청하는지를 직접 관찰하고 분석했습니다.

수많은 시행착오와 테스트 끝에, 치지직 라운지의 최신 게시글 정보를 가져올 수 있는 숨겨진 내부 통로의 주소와 데이터 형식을 완전히 파악하는 데 성공했습니다.

이렇게 파악한 정보를 바탕으로 "1분에 한 번씩 치지직 라운지에 새로운 글이 올라왔는지 확인하고, 새 글이 감지되면 즉시 디스코드로 전송하는" 감지 엔진을 직접 구현했습니다.

3. 왜 이렇게 빠르고 안정적일까요?

혼자서 매분 확인하다 보면 '로봇 차단'에 걸립니다

봇이 치지직 라운지의 새 글을 감지하는 방식은, 1분마다 치지직 서버에 "새 글 있나요?" 라고 묻는 것입니다.

여기서 문제가 생깁니다. 수천 개의 디스코드 서버에서 수만 명의 팬들이 수십, 수백 명의 스트리머를 등록해 두면, 1분마다 수천 번의 확인 요청이 치지직 서버로 집중됩니다. 그러면 네이버 서버의 보안 시스템이 이를 "특정 컴퓨터(IP 주소)에서 너무 많은 자동 요청이 들어온다. 악성 봇일 수 있다"고 판단하여 해당 컴퓨터의 접근을 일시적으로 차단합니다. 이렇게 되면 알림이 전혀 오지 않거나, 30분~1시간씩 늦어지는 심각한 문제가 생깁니다.

5개의 중계 경로와 170만 개의 IP 주소로 이 문제를 해결했습니다

이 문제를 해결하기 위해, 저는 세계 각지에 위치한 4개의 환경(물리 서버 2개 및 서버리스 노드 2개)에서 총 5개의 독립적인 중계 경로(오사카 서버의 IP 2개 포함)를 구축했습니다.

• 한국(서울) 구글 프록시 서버 1개 — 치지직 서버와 물리적으로 가장 가깝고, '국내 전용' 설정 방송도 감지 가능합니다.
• 해외 인스턴스 서버 2개 — 무중단 봇 운영을 위해 각각 다른 나라(일본 오사카 1개, 미국 오리건 1개)에서 고가용성(HA) 방식으로 운영하며, 오사카 서버는 2개의 IP를 활용합니다.
• 클라우드플레어 글로벌 엣지 1개 — 전 세계 어느 곳에서든 빠르게 중계합니다.

치지직에 "새 글 있나요?" 라는 확인 요청을 보낼 때, 이 5개의 경로가 돌아가면서 번갈아 요청을 보냅니다. 마치 5명이 교대로 한 명씩 가게에 들어가 "재고 있나요?"를 확인하는 것처럼요. 한 명이 계속 물어보면 수상해 보이지만, 여러 명이 돌아가며 자연스럽게 물어보면 네이버 서버에 무리를 주지 않는 선에서 합법적이고 안전한 방식으로 데이터를 조회하게 됩니다.

게다가 구글(GCP) 서버는 약 19만 개의 서버 IP 주소, 클라우드플레어는 약 152만 개의 IP 주소를 보유하고 있어, 요청마다 매번 다른 IP 주소로 확인합니다. 마치 매번 다른 사람이 들어가 확인하는 것과 같은 효과로, 차단 가능성을 거의 0%에 가깝게 낮췄습니다.

'국내 전용' 방송도 놓치지 않습니다

일부 스트리머는 해외 시청자를 위한 국가 제한을 걸어 방송을 국내에서만 볼 수 있도록 설정합니다. 이 경우 서버가 해외에 있으면 방송 시작 여부를 확인할 때 "이 방송은 한국에서만 볼 수 있습니다"라는 오류가 뜨며 감지에 실패합니다.

저는 한국 서울에 위치한 구글 서버를 중계 기지로 활용하여 마치 한국 사람이 직접 치지직을 열어보는 것처럼 방송 시작 정보를 가져옵니다. 덕분에 국내 전용으로 설정된 스트리머의 방송도 빠짐없이 감지해 알림을 보낼 수 있습니다.

한 서버가 죽어도 다른 서버가 30초 안에 자동으로 살아납니다

세상에 절대로 오류가 없는 서버는 없습니다. 아무리 잘 만든 시스템도 갑작스러운 장애가 생길 수 있습니다. 그래서 저는 메인 서버(구글 GCP)와 예비 서버(오라클 클라우드)를 항상 함께 운영합니다.

평소에는 메인 서버 혼자 모든 알림 업무를 처리하고, 예비 서버는 "메인 서버가 잘 작동하고 있나?" 를 감시하며 대기합니다. 만약 메인 서버에 문제가 생기면 예비 서버가 30초 안에 자동으로 메인 역할을 넘겨받아 아무 일도 없었던 것처럼 서비스를 계속 이어갑니다.

또한 두 서버는 평소에도 알림 등록 정보(어떤 채널에 어떤 스트리머가 등록되어 있는지)를 실시간으로 동기화(최신 상태 공유)하고 있어서, 메인 서버가 갑자기 꺼져도 예비 서버가 완벽한 상태로 대신할 수 있습니다.

4. 왜 무료인데 서버 비용이 안 드나요?

클라우드 서비스의 '무료 구간'을 극한까지 활용했습니다

구글 클라우드(GCP), 오라클 클라우드(Oracle Cloud), 클라우드플레어(Cloudflare)는 모두 소규모 사용자나 학생을 위해 기본적인 서버 자원을 무료로 제공합니다. 단, 사용하는 자원(메모리, 처리 용량)이 무료 한도를 넘어가면 바로 유료로 전환됩니다.

저는 이 무료 한도 안에서 최대한의 성능을 끌어내기 위해 극한의 최적화 기술을 적용했습니다. 현재 아키텍처는 사용자가 크게 늘어나도 서버를 효율적으로 수평 확장(Scale-out)할 수 있도록 설계되어 있어, 영구적으로 안정적인 무료 운영이 가능합니다.

일반적인 방식이라면 메모리가 훨씬 많이 필요합니다

디스코드 봇이 많은 서버에 동시에 연결하려면 '샤드(Shard)' 라는 단위로 연결을 나누어야 합니다. 텔레비전 채널이 여러 개인 것처럼, 봇도 한 번에 여러 서버에 연결하기 위해 여러 개의 채널을 동시에 열어두는 것입니다. 봇은 최대 5만 대의 디스코드 서버에 대응하기 위해 20개의 채널(샤드)을 열어두어 작동합니다.

일반적인 방법이라면 채널(샤드) 하나당 별도의 프로그램을 실행해서 20개의 프로그램을 동시에 띄워야 합니다. 20개의 프로그램이 동시에 실행되면 메모리 사용량이 폭발적으로 늘어납니다.

저는 여기서 아이디어를 뒤집었습니다. 프로그램을 20개 띄우는 대신, 하나의 프로그램 안에서 20개의 채널을 동시에 열고 처리하는 방식을 구현했습니다. 마치 한 명의 직원이 20개의 전화를 동시에 다 처리하는 것처럼요. 그 결과, 구글의 무료 서버(총 메모리 955MB 제한) 안에서 제공되는 최대 메모리 한도 내에서 매우 안전하고 안정적으로 20개 채널 전체를 완벽하게 구동합니다.

예비 서버는 평소엔 거의 아무것도 안 합니다

예비 서버(오라클 클라우드)는 평소 무료 한도 범위 내의 안전한 메모리 사용량만 유지하며 대기합니다. 디스코드에 로그인도 하지 않고, 그냥 "메인 서버야, 살아있어?" 라는 신호만 주기적으로 확인합니다. 서버 자원을 거의 쓰지 않으니 무료 한도를 초과할 일이 없습니다.

메인 서버에 문제가 생겼을 때만 처음으로 디스코드에 로그인하고 알림 업무를 시작합니다.

이렇게 해서 월 서버 비용은 0원입니다

• 메인 구글 클라우드(GCP): 평생 무료 티어 서버 사용 중, 무료 티어 제공 최대 메모리(955MB) 한도 내에서 안전하게 작동하여 한도 초과 위험 없음
• 구글 한국 프록시 서버 (GCF): 금액이 월 1만원 수준으로 청구되나 구글 무료 크레딧 등으로 전액 삭감
• 서브 오라클 클라우드: 평생 무료 티어 서버 사용 중, 제공되는 넉넉한 최대 메모리(12GB) 한도 내에서 매우 안정적으로 대기 및 작동
• 클라우드플레어 Workers: 평생 무료 플랜으로 운영 중
• 합계: 월 0원

5. 내 디스코드 서버는 안전한가요?

봇은 채팅 내용을 읽을 수 없습니다

많은 분들이 봇을 초대할 때 "이 봇이 우리 채팅을 감시하거나 개인 정보를 수집하진 않을까?" 걱정하십니다. 이 부분에 대해 명확하게 말씀드릴 수 있습니다.

봇은 기술적으로 채팅 내용을 읽는 것 자체가 불가능합니다.

디스코드 봇은 설정에 따라 채팅 내용을 읽거나 멤버 목록을 수집하는 권한을 받을 수 있습니다. 저는 이런 민감한 권한들을 개발 설정 단계에서 아예 모두 꺼뒀습니다. 설정 자체를 꺼뒀기 때문에, 설령 해킹을 당하거나 운영자가 마음이 바뀌더라도 채팅을 읽는 것이 기술적으로 불가능한 구조입니다.

봇이 반응하는 유일한 순간은 여러분이 직접 /등록, /삭제 같은 슬래시(/) 명령어를 입력했을 때와 스트리머의 알림 전송뿐입니다.

저장하는 정보는 딱 3가지뿐입니다

봇이 알림을 보내기 위해 꼭 필요한 최소한의 정보만 저장합니다.

1. 알림을 보낼 디스코드 채널 번호 (어디로 알림을 보내야 하는지)
2. 등록된 스트리머의 고유 번호 (누구의 소식을 감지해야 하는지)
3. 스트리머의 닉네임 (알림 메시지에 이름을 표시하기 위해)

채팅내역, 이메일 주소, 어떤 멤버가 있는지와 같은 민감한 개인 식별 정보는 단 하나도 수집하지 않습니다.

봇을 서버에서 내보내거나 /삭제 명령어로 스트리머 등록을 해제하면, 해당 데이터는 즉시 영구적으로 삭제됩니다.

디스코드 본사 공식 인증 봇입니다

제 봇은 디스코드 본사에서 직접 진행하는 보안 심사와 신원 검증을 통과하여 공식 인증 배지(Verified App)를 받았습니다. 이 인증은 아무 봇이나 받을 수 없으며, 총 인원수 1만명 이상의 대규모 서버에 도입되었거나 사용자 수가 일정 수준 이상인 봇들은 반드시 이 심사를 통과해야만 계속 서비스를 이어갈 수 있습니다.

즉, 디스코드 본사가 제 봇의 보안성과 안정성, 그리고 운영자의 신원을 철저히 검증했다는 의미입니다.

6. 주요 기능 요약

기능	설명
생방송 시작 알림	등록한 스트리머가 방송을 켜면 즉시 알림과 함께 실시간 방송 화면 미리보기를 전송합니다. (※ 단, 성인 제한 방송은 디스코드 보안 가이드 및 안전한 환경 조성을 위해 미리보기 이미지가 자동으로 제외됩니다.)
라운지 공지 알림	스트리머가 커뮤니티(라운지)에 새 글을 올리면 즉시 알림을 전송합니다. 글 내용뿐만 아니라 포함된 사진과 링크까지 가독성 높은 디스코드 임베드(Embed) 형식으로 깔끔하게 포매팅하여 누락 없이 전달합니다.
알림 메시지 커스텀	알림이 올 때 @everyone, 특정 역할, 또는 멘션 없음 중 선택하고 메시지 문구도 직접 작성할 수 있습니다.
닉네임 검색 등록	스트리머를 등록할 때 복잡한 32자리 ID를 찾을 필요 없이 닉네임만 입력하면 자동으로 찾아줍니다.
실시간 서버 상태 확인	/핑 명령어 하나로 현재 봇이 연결된 5개 중계 경로의 건강 상태를 실시간으로 확인할 수 있습니다.

"글로만 정교한 것이 아닙니다. 이 모든 최적화 기술이 적용된 실제 봇의 깔끔한 알림 화면과 작동 예시는 봇의 가이드에서 직접 확인하실 수 있습니다."