Skip to Content
AI & Agents포켓몬 GO 전용 아침 브리핑
🤖 AI & Agents2026년 10월 17일

포켓몬 GO 전용 아침 브리핑

#pokemon-go#discord#automation
OpenClaw와 아침 브리핑 자동화6 / 6
PogoAtlas API를 이용해 포켓몬 GO 일정과 레이드를 전용 아침 메시지로 구성했습니다. 수집과 알림을 나누고 Discord에서 읽기 편하게 정보를 정리한 과정을 소개합니다.

포켓몬 GO 일정은 일반 뉴스나 메일과 섞지 않고 따로 받고 싶었습니다. 그래서 기존 아침 브리핑은 유지하고, 한국 시간 08:05에 실행되는 포켓몬 GO 전용 알림을 추가했습니다.

알림에 쓰는 정보는 PogoAtlas API에서 가져옵니다. 같은 Discord 채널에 보내더라도 메시지를 만드는 프로그램과 실행 일정은 일반 브리핑과 분리했습니다.

수집과 알림 분리

PogoAtlas API는 일정, 레이드, 맥스배틀, 리서치 정보를 제공합니다. 브리핑 생성기는 이 정보를 읽어 메시지를 만드는 역할만 맡습니다. 알림을 보낼 때 원본 사이트를 다시 수집하거나 누락된 날짜를 추측하지 않도록 했습니다.

특히 레이드는 일정과 현재 확인된 보스 목록이 항상 같지는 않습니다. 행사에 특정 보스가 예정돼 있다는 이유만으로 지금 등장 중이라고 표시하면 잘못된 안내가 됩니다. 메시지를 만들 때도 API가 가진 일정과 현재 상태를 구분하고, 행사 시작·종료 시각을 함께 사용합니다.

이 구분은 API와 브리핑이 서로 다른 날짜 기준을 적용하지 않게 하는 데도 필요했습니다. 일정 처리가 바뀌면 API의 결과에 맞춰 브리핑을 수정하고, 알림 쪽에 별도 판단 규칙을 쌓지 않는 방식입니다.

API를 조회하는 순서

PogoAtlas에서는 데이터 갱신과 조회 요청을 나눴습니다. 따라서 브리핑에서 조회할 때마다 외부 사이트를 다시 읽는 대신, 동기화된 자료를 API에서 가져옵니다. 이 구조에서는 메시지 작성 오류를 고치려고 원본 수집까지 반복할 필요가 없습니다.

현재 API 문서에 있는 조회 경로를 로컬 실행 주소로 적으면 다음과 같습니다. API가 실행 중이고 데이터 동기화를 마친 상태를 전제로 합니다.

bash
example/pogo-briefing-input.sh
curl --fail-with-body 'http://localhost:8001/v1/status' curl --fail-with-body 'http://localhost:8001/v1/raids/current?day=today' curl --fail-with-body 'http://localhost:8001/v1/raids/current?day=tomorrow' curl --fail-with-body 'http://localhost:8001/v1/events/calendar?month=2026-10'

day는 today와 tomorrow 중 하나이고, 월간 일정은 month=YYYY-MM으로 요청합니다. 실행 중인 API의 /docs와 /openapi.json에서 실제 응답을 함께 확인할 수 있습니다. 위 명령은 자료 조회 예시이며 Discord 전송은 하지 않습니다.

상태 요청을 먼저 보는 이유는 빈 행사 목록과 갱신 실패를 구분하기 위해서입니다. 데이터가 없다고 바로 “오늘 일정 없음”으로 바꾸면 수집 실패까지 정상 일정처럼 보일 수 있습니다. 브리핑은 API에 있는 출처와 갱신 상태를 보고 사용할 항목을 고릅니다.

일정 시작·종료 시각과 예정 정보

아침 알림에는 두 가지 질문이 섞입니다. “지금 어떤 보스가 있는가”와 “오늘 어떤 행사가 있는가”입니다. 오전에 끝나는 행사도 오늘 일정에 들어가지만, 종료한 보스를 현재 목록에 넣어서는 안 됩니다.

예를 들어 한국 시간 10시에 교체되는 가상의 보스가 있다면 다음처럼 구분할 수 있습니다.

조회 시점현재 상태오늘 일정 설명
08:05교체 전 보스10시 교체 예정
10:00종료 시각이 지난 상태새 일정의 시작 여부 확인
다음 날 08:05다음 날의 현재 상태전날 일정을 그대로 재사용하지 않음

이 표는 날짜 해석 예시이며 특정 보스의 실제 일정은 아닙니다. 브리핑이 별도로 시간을 보정하거나 행사 제목에서 보스를 추정하면 웹 화면과 알림의 결과가 달라질 수 있습니다. 그래서 시간 해석은 API에 모으고, 브리핑은 응답의 기간과 상태를 표시하는 데 집중했습니다.

메시지에 넣을 정보를 줄이는 작업도 이 판단 뒤에 합니다. 출처가 미확인인 정보를 먼저 정확한 값처럼 만든 다음 표시만 줄이는 방식으로는 해결되지 않습니다. 확인된 CP와 약점은 공략 항목에 쓰고, 확인하지 못한 값은 비워 두거나 상세 화면으로 연결하는 식입니다.

등급별 표시 정보

모든 보스에 같은 항목을 붙이면 메시지가 길어집니다. 주요 레이드에는 종료일과 포획 CP, 약점, 날씨 정보를 표시하고, 나머지는 이름 중심의 짧은 목록으로 구성했습니다.

항목표시 내용
주요 레이드이름, 기간, CP, 공략 정보
일반 레이드이름 중심의 목록
행사행사명, 일정, 보너스
시즌·패스개별 행사와 구분한 항목

사용할 수 있는 정보를 모두 보여주기보다, 아침에 메시지를 보고 오늘 무엇을 할지 판단할 때 필요한 내용을 먼저 배치했습니다. 초기 작업 등록 때는 미리보기와 실제 Discord 전송을 함께 확인했습니다.

Discord 메시지 구성

이후에는 새로운 항목을 계속 붙이기보다 읽는 방식을 정리했습니다. 행사명과 일정을 한 줄에 두고, 보너스는 항목별로 나눴습니다. 이름과 CP는 강조하고 행사 사이에는 여백을 넣었습니다.

하단에 붙이던 자료 갱신 시각과 출처 설명도 줄였습니다. API에서 데이터를 관리할 때는 필요한 정보지만 매일 받는 알림에 모두 붙이면 정작 일정과 보상을 찾기 어려웠습니다. 상세 정보는 API에 남기고 메시지는 요약에 집중하도록 했습니다.

10월의 마지막 형식 변경은 테스트와 실제 API를 사용한 미리보기에서 확인했습니다. 변경 직후 새 Discord 메시지를 보내지는 않았습니다. 메시지 구성 수정과 전송 확인을 따로 기록해 둔 이유입니다.

Last updated on