인스타그램 API로 경찰과 도둑 앱 하루치 지표를 구해 디스코드로 보내기

어드민 지표 대시보드를 만든 과정을 일곱 편으로 나눠 적었다. 이 글은 2편이다.

1. 경찰과 도둑 앱 지표를 골라 매일 모으기로 한 이유
2. 인스타그램 API로 경찰과 도둑 앱 하루치 지표를 구해 디스코드로 보내기
3. 서비스 계정으로 경찰과 도둑 앱의 Google Play 통계 CSV 받기
4. App Store Connect API로 경찰과 도둑 앱 다운로드와 노출 수 받기
5. GA4 Data API로 경찰과 도둑 앱과 웹사이트 지표 모으기
6. AdMob API 갱신 토큰으로 경찰과 도둑 앱 광고 지표 매일 받기
7. Supabase로 경찰과 도둑 앱 지표 대시보드 만들기

1편에서 매일 숫자를 모아 우리 데이터베이스(DB)에 쌓아 두기로 정했다. 이 글은 그중 가장 먼저 만든 인스타그램 수집과 디스코드 리포트 이야기다.

인스타부터 시작한 이유

대시보드 전체는 2~3주짜리 일로 봤는데, 인스타 숫자를 디스코드로 받는 건 1~2일이면 끝날 것 같았다. 그래서 마케터가 다음 날부터 바로 쓸 수 있는 것부터 만들어 보기로 했다.

무엇보다 인스타 숫자는 늦게 모을수록 놓치는 게 생겼다. 계정 하루 지표는 90일까지 보관되지만 한 번에 물을 수 있는 건 최근 30일까지이고, 게시물 숫자는 누적값만 준다(자세한 건 1편에 적었다). 그래서 하루라도 빨리 기록을 시작해야 했다.

인스타 API의 두 갈래

인스타 숫자를 받아 오는 API를 검색해 보면 페이스북 페이지를 연결하는 것부터 시작하는 글이 많다. 그런데 그건 Facebook 로그인을 쓰는 방식의 이야기였다.

지금은 Instagram 로그인으로 쓰는 API가 따로 있다. 페이스북 페이지를 연결하지 않아도 인스타 프로페셔널 계정 하나로 쓸 수 있고, 주소도 graph.facebook.com이 아닌 graph.instagram.com을 쓴다.

우리는 우리 계정 숫자만 읽으면 됐기 때문에 이 방식이 더 간단했다. 앱 심사나 비즈니스 인증, 페이지 연결을 하지 않아도 돼서 앱을 "개발 모드"로 두고 우리 계정을 테스터로 넣어 쓰기로 했다.

따라 하기 1. 프로페셔널 계정 확인

인스타가 계정과 게시물 반응을 모아 보여 주는 통계(인사이트)를 API로 받으려면 프로페셔널 계정이어야 한다. 비즈니스나 크리에이터 계정이 여기에 들어간다.

1. 휴대폰 인스타 앱에서 우리 계정 프로필로 간다
2. 오른쪽 위 줄 세 개(설정)를 누른다
3. "전문가용" 아래 "계정 유형 및 도구"를 누른다
4. 이미 비즈니스나 크리에이터면 그대로 둔다. 아니면 프로페셔널 계정으로 전환한다

우리 계정은 이미 크리에이터 계정이라 여기는 그냥 넘어갔다.

따라 하기 2. 개인 페이스북으로 Meta 개발자 등록

Meta 앱은 페이스북 계정으로 만든다. 처음에는 '팀용 페이스북 계정을 새로 하나 만들까?' 고민했다. 그런데 새로 만든 팀용 계정은 가짜 계정으로 분류돼 정지될 수 있고, 그렇게 되면 그 계정으로 만든 앱도 같이 막힌다. 그래서 결국 내 개인 페이스북으로 개발자 등록을 했다.

앱은 내 계정 소유가 되지만, 앱이 읽는 건 테스터로 연결한 팀 인스타 계정의 숫자다. 나중에 앱 역할에 팀원을 관리자로 넣어 두면 내가 빠져도 이어서 관리할 수 있다.

1. https://developers.facebook.com 에 페이스북 계정으로 로그인한다
2. 처음이면 개발자 등록 안내를 따라간다

그런데 등록하던 중에 화면이 하얗게 멈추더니 아무것도 눌리지 않았다. 알고 보니 팝업 안에서만 열리는 주소로 넘어가 있었다. 앱 목록 주소(https://developers.facebook.com/apps/)로 다시 들어가니 그제야 이어서 진행할 수 있었다. 혹시 같은 화면에서 멈췄다면 새로고침보다 앱 목록 주소로 다시 들어가 보면 된다.

따라 하기 3. 앱 만들기

1. 위쪽 "내 앱"으로 들어가 오른쪽 "앱 만들기"
2. 앱 이름을 넣는다. 우리는 dongsim-metrics
3. 사용 사례 고르는 화면에서 "Instagram에서 메시지 및 콘텐츠 관리"(Manage messaging and content on Instagram)를 고른다
4. 비즈니스 포트폴리오 연결을 물으면 건너뛰어도 된다
5. 끝까지 넘어가서 대시보드로 간다

따라 하기 4. 권한 두 개만 추가

1. 앱 대시보드에서 "Instagram에서 메시지 및 콘텐츠 관리" 줄을 누른다(이용 사례 맞춤 설정으로 간다)
2. 왼쪽 "권한 및 기능"
3. 목록에서 두 개만 오른쪽 "추가"를 누른다
   • instagram_business_basic
   • instagram_business_manage_insights

추가한 줄은 상태가 "테스트 준비 완료"로 바뀌고 버튼이 "옵션"이 된다. 다만 조회수와 좋아요를 읽는 데 필요한 instagram_business_manage_insights는 기본으로 들어 있지 않아서 따로 추가해야 한다.

목록에는 댓글 관리, DM, 게시 권한도 있다. 처음에는 '다 받아 두면 데이터를 더 주지 않을까?' 싶었다. 그런데 알고 보니 이 권한들은 계정에 글을 쓰고 지우는 데 쓰는 권한이었다.

앱이 계정에 접근할 때 쓰는 토큰이 새기라도 하면, 누군가 우리 계정에 글을 올릴 수도 있다. 그래서 읽기 권한만 받았다.

따라 하기 5. 인스타 테스터 등록과 수락

개발 모드 앱은 앱 역할에 들어간 계정만 쓸 수 있다. 우리 인스타를 여기에 넣지 않으면 다음 단계에서 계정 추가가 실패한다.

1. 앱 대시보드 왼쪽 "앱 역할" → "역할"

2. 오른쪽 위 "사람 추가"

3. 창 아래쪽 "이 앱에 대한 추가 역할"의 Instagram 테스터를 고른다

4. 우리 인스타 사용자 이름을 넣고 추가한다

   

   그런데 창 위쪽에도 그냥 "테스터"가 있다.

   이름이 비슷해서 헷갈리기 딱 좋은데, 그건 페이스북 계정용이다.

   인스타 계정은 아래쪽 "Instagram 테스터"로 넣어야 한다.

   

   초대를 보냈으면 인스타 쪽에서 받아야 한다.

5. 컴퓨터 브라우저로 instagram.com 에 우리 인스타 계정으로 로그인한다

6. 설정 → "앱 및 웹사이트" → "테스터 초대" → 수락

따라 하기 6. 토큰 만들기

1. 이용 사례 맞춤 설정 왼쪽의 "Instagram 로그인이 포함된 API 설정"

   

2. "2. 액세스 토큰 생성"을 펼치고 "계정 추가"

3. 뜨는 창에서 우리 인스타로 로그인하고 허용한다

4. 목록에 계정이 생기면 옆의 "토큰 생성"

토큰 생성을 누르면 긴 문자열이 나온다. 우리 계정 숫자를 읽을 때 쓸 값이니 복사해서 비밀번호 관리자에 넣는다.

그런데 바로 위 "1. 필수 메시지 권한 추가" 칸에 파란 Add all required permissions 버튼이 크게 있다. 필수라니까 눌러야 할 것 같았는데, 누르면 댓글 관리와 메시지 권한이 같이 추가된다. 숫자만 읽을 거면 앞에서 넣은 두 권한이면 충분하니 이 버튼은 누르지 않아도 된다.

토큰을 확인하려고 브라우저 주소창에 넣고 API를 불러 보는 건 하지 않는 게 좋다. 토큰이 들어간 주소가 방문 기록에 남고, 동기화된 다른 기기에도 그대로 남기 때문이다.

60일 만료와 연장

이 토큰은 오래 쓸 수 있는 장기 토큰인데도 60일이면 만료된다. 그때마다 사람이 다시 만들 수는 없어서, 매일 숫자를 모아 DB에 쌓는 서버 코드(수집기)에서 토큰을 연장하게 했다.

GET https://graph.instagram.com/refresh_access_token
    ?grant_type=ig_refresh_token
    &access_token=지금 토큰

이걸 부르면 만료 시점이 다시 60일 뒤로 바뀐 새 토큰이 온다. 다만 만든 지 24시간이 안 된 토큰은 거절된다.

연장 방법은 찾았는데, 새 토큰을 어디에 둘지가 걸렸다. GitHub Actions 예약 실행(정해 둔 시각에 작업을 자동으로 돌려 주는 GitHub 기능)이 우리 웹 서버(Vercel)의 수집 주소를 부르면, 서버가 숫자를 받아 데이터베이스 서비스인 Supabase에 저장한다(7편). 그런데 서버는 실행 설정으로 받은 환경변수를 스스로 고쳐 쓸 수 없다.

그래서 처음 한 번만 환경변수로 토큰을 받고, 연장한 토큰은 DB(metrics_tokens 테이블)에 저장해서 다음부터 그걸 쓰게 했다. 일주일에 한 번 연장하고, 연장이 계속 실패해서 만료까지 10일도 안 남으면 수집을 실패로 끝내게 했다. 그러면 GitHub Actions 실패 메일이 온다.

게시물 숫자 받기

토큰이 생기면 게시물 목록부터 받는다. 그다음 게시물마다 숫자를 이런 식으로 요청한다.

# 게시물 목록
GET https://graph.instagram.com/v23.0/me/media
    ?fields=id,permalink,caption,media_type,media_product_type,timestamp
    &access_token=...

# 게시물 하나의 숫자 (피드)
GET https://graph.instagram.com/v23.0/{게시물ID}/insights
    ?metric=views,reach,likes,comments,saved,shares,total_interactions,profile_visits,follows
    &access_token=...

다만 토큰이 주소에 들어간다. 요청 주소를 로그에 남기면 토큰이 그대로 새어 나가서, 요청이 실패했을 때도 주소를 메시지에 넣지 않게 했다.

예제 코드의 impressions 오류

검색해서 나오는 예제는 대부분 impressions를 부른다. 그런데 이 지표는 2025년 4월 21일 이후 모든 버전에서 오류를 내고, views로 바뀌었다.

그래서 2024년 이전 글을 따라 하면 처음 요청부터 막힐 수 있다.

누적값만 주는 게시물 숫자

원래는 어제 하루 이 게시물을 몇 명이 봤는지 알고 싶었다. 그런데 게시물 인사이트는 지금까지의 누적값만 준다.

그래서 매일 같은 시각(한국 오전 9시쯤, 예약 시각은 7편)에 누적값을 기록해 두기로 했다. 오늘 누적에서 어제 누적을 빼면, 두 번 기록한 사이에 늘어난 하루치가 나온다.

(위 표는 계산 방식을 보여 주려고 만든 숫자다.)

다만 이렇게 하루치를 구하려면 기록을 하루도 빠뜨리면 안 된다. 하루라도 빠지면, 그날 늘어난 숫자는 다음 날 늘어난 숫자와 합쳐져 이틀치로만 남는다.

하루가 끝난 시각이 아닌 end_time

게시물과 달리 계정 전체 숫자(그날 우리 인스타를 본 사람 수)는 하루 단위로 준다. 응답은 대충 이렇게 생겼다.

{ "value": 2152, "end_time": "2026-09-13T07:00:00+0000" }

처음에는 end_time이라니까 이 시각에 하루가 끝난 줄 알았다. 그렇게 계산했더니 9월 13일이 3,708명으로 나왔는데, 같은 날을 다른 방식으로 물으면 2,152명이었다. '같은 날인데 왜 1,500명이 차이 나지?' 싶었다.

그래서 하루를 어디서부터 어디까지로 잡는지 바꿔 가며 같은 날을 다섯 번 물어봤다. 확인해 보니 end_time은 그 하루가 시작하는 시각이었다. 아직 진행 중인 오늘 치도 이미 지난 시각으로 찍혀 왔고, 10월 2일에 올린 게시물의 도달도 10월 2일 칸에 잡혔다.

그런데 하루치를 따로 요청할 때도 경계를 맞춰야 했다.

since = 직전 하루의 시작 + 1초
until = 이 하루의 시작

이렇게 줘야 하루 단위 값과 같았고, 1초만 당겨도 이틀치가 합쳐졌다. 그래서 API가 붙인 이름만 보고 판단하지 않고, 다른 방식으로 물은 값이나 게시한 날짜처럼 이미 아는 숫자와 맞춰 본 다음 쓰기로 했다.

하루가 23시간인 날

처음에는 위 경계를 시작 - 24시간 + 1초로 계산했다. 그런데 코드를 검토하다 보니 서머타임이 시작하는 날에는 이 계산이 맞지 않았다.

인스타의 하루는 미국 서부 자정 기준이다. 미국 서부는 서머타임이 있어서, 서머타임이 시작하는 날(다음은 2027년 3월 14일)은 하루가 23시간이다. 여기서 24시간을 빼면 그날도 이틀치가 합쳐진다.

그래서 24시간을 직접 빼지 않고, 인스타가 준 직전 하루의 경계를 그대로 쓰게 바꿨다. 23시간, 25시간짜리 날을 흉내 낸 가짜 응답으로 테스트도 추가했다.

시간대 이야기가 나온 김에, 인스타의 하루가 한국 시간으로는 언제부터 언제까지인지도 확인했다. 미국 서부 자정은 한국 시간으로 오후 4시(서머타임이 아닐 땐 오후 5시)다. 인스타의 10월 15일은 한국의 10월 15일 오후 4시부터 16일 오후 4시까지다.

그래서 리포트 문구에 이 한국 시간 범위를 같이 적었다. 어드민 화면에서는 Google Play처럼(3편) 계정 하루 숫자를 하루 뒤로 옮겨 한국 날짜에 맞춘다.

통째로 거절된 릴스 지표 요청

피드 게시물은 프로필 방문, 팔로우, 프로필 링크 클릭을 준다. 그런데 릴스에 이 셋을 같이 요청하면 요청 전체가 거절돼서 다른 지표도 받을 수 없다.

그래서 게시물 종류마다 다른 지표 목록을 요청했다. 릴스에는 처음 3초 안에 넘긴 비율(reels_skip_rate)과 평균 시청 시간을 대신 넣었다.

9월 16일 릴스는 넘긴 비율이 66.8%였다. 셋 중 둘은 3초 안에 넘겼다.

리포트 모양 정하기

리포트 문구를 쓰기 전에 게시물 12개와 계정 30일치를 전부 받아 봤다. 머릿속으로 리포트를 설계하는 것보다 실제 숫자를 보는 게 빨랐다.

게시물 숫자는 올리고 2~3일이 지나면 거의 늘지 않았다. 9월 13일 게시물을 올린 날부터 계정 하루 도달이 2,152명, 1,652명, 440명으로 줄었다.

그런데 본 사람의 99%가 팔로워가 아니었다. 30일 동안 7,998명이 봤는데 그중 팔로워는 76명이었다. 당시 팔로워가 79명이었으니 팔로워는 세 명 빼고 다 봤는데, 그래 봐야 전체의 1%였다.

좋아요 수는 비슷했는데 공유 수는 차이가 있었다. 좋아요는 게시물마다 8~36개였는데 공유는 0~218회였고, 도달이 큰 게시물은 예외 없이 공유가 많았다. 9월 4일 모집 글은 공유 218회, 도달 5,310명이었다.

다만 게시물별 유입 경로(탐색 탭, 해시태그)는 API로 받지 못했다. 팔로워 나라와 나이는 팔로워 100명부터 받을 수 있다.

이렇게 보니 올리고 2~3일 뒤에 한 번 보면 충분할 것 같았다. 그래서 게시물 리포트는 올린 지 3일째에 한 번만 보내기로 했다.

급상승 알림도 평소보다 도달이 많이 늘었을 때만 보내기로 했다. 가장 최근에 끝난 하루의 도달이 직전 14일 가운데 값의 3배 이상이면서 300명 이상일 때 보낸다. 평소 하루 5명이 보던 계정에 20명만 와도 4배가 되기 때문에 300명 하한을 뒀고, 며칠 이어지는 급상승은 첫날만 알리게 했다.

매일 리포트도 처음에는 넣어 봤다. 그런데 게시물이 없는 날은 하루 도달이 0~60명이라 매일 와도 읽을 게 없었다. 그런 메시지가 쌓이면 사람들이 채널을 안 볼 것 같아서 뺐고, 결국 일주일에 메시지 서너 개 정도가 오게 됐다.

비교할 게시물 고르기

게시물 리포트에 보통 게시물보다 몇 배인지를 넣으려고 했다. 9월 4일 모집 글을 "보통 게시물(450명)의 12배"라고 적으려다 보니 조금 이상했다. 450명은 그 글을 포함한 12개의 가운데 값이었고, 그 글을 빼면 385명이었다.

검토하다 보니 비교 대상도 문제였다. 그 게시물보다 나중에 올린 게시물은 올린 지 하루라 숫자가 아직 작은데, 이런 게시물까지 비교에 들어가면 순위가 실제보다 좋게 나온다.

그래서 비교 대상을 그 게시물보다 먼저 올린 것으로 좁혔다. 문장도 "지금까지 올린 12개 중"에서 "이 게시물까지 올린 3개 중"처럼 바꿨다.

따라 하기 7. 디스코드 웹후크 만들기

리포트 모양을 정했으니 이제 디스코드로 보낼 차례였다. 봇을 따로 만들 필요 없이, 정해진 주소로 글을 보내면 채널에 메시지를 올려 주는 디스코드 웹후크를 썼다.

1. 리포트를 받을 채널 이름 옆 톱니바퀴(채널 편집)를 누른다

2. 왼쪽 "연동"을 누르고 "웹후크"로 들어간다

   

3. "새 웹후크"를 누른다

4. 이름을 인스타 리포트로 바꾸고 채널을 고른다

5. 프로필 사진을 바꾸고 싶으면 왼쪽 그림을 누른다. 우리는 팀 캐릭터 냥파(경찰 고양이)가 돋보기를 든 그림을 넣었다

6. "웹후크 URL 복사"를 누른다

웹후크 주소는 비밀번호처럼 다룬다. 이 주소를 알면 누구나 그 채널에 글을 쓸 수 있다. 혹시 샜다면 그 웹후크를 지우고 새로 만들면 된다.

연결이 잘됐는지는 터미널에서 바로 확인할 수 있다.

curl -H "Content-Type: application/json" -d '{"content":"웹훅 연결 테스트예요"}' "웹훅주소"

채널에 메시지가 뜨면 연결은 끝이다.

보내기 전에 챙길 것

게시물 캡션에 @everyone이 들어 있으면 리포트가 서버 전체에 알림을 울린다. 그래서 보낼 때 allowed_mentions: { parse: [] }를 같이 보내 멘션을 막았다. 글자는 그대로 보이고 알림은 안 울린다.

보낼 때마다 이름도 바꿀 수 있다. 본문에 username을 넣으면 그 메시지만 봇 이름이 바뀐다. 그래서 월요일 아침에 지난주 숫자를 그 전 주와 견줘 보내는 주간 리포트(7편)는 같은 웹후크로 보내면서 이름만 "주간 리포트"로 바꿨다.

웹후크 전송 제한을 찾아보면 분당 30회라는 숫자가 여기저기 나온다. 그런데 공식 문서에는 없고, 응답 헤더와 요청이 너무 많다는 429 응답을 보고 맞추라고만 한다. 하루 몇 번 보내는 용도라 상관없지만, 출처 없는 숫자를 기준으로 코드를 짜지는 않기로 했다.

리포트 문구 다듬기

처음 초안은 이랬다.

계정 도달이 평소의 3배예요

그런데 다시 읽어 보니 "계정 도달"이 문장으로 잘 안 읽혔다. 인사이트 메뉴 이름을 그대로 옮긴 말이라, 무슨 일이 있었는지가 보이게 풀어 썼다.

9월 13일 하루 동안 2,152명이 우리 인스타를 봤어요

다만 목록 안의 "도달"은 인스타 앱 화면과 숫자를 맞춰 볼 때 찾기 쉽게 그대로 뒀다.

디스코드 헤더(#)와 이모지도 뺐다. 헤더는 글자가 커서 짧은 리포트도 휴대폰 한 화면을 넘겼고, 이모지는 봇 이름과 아이콘이 이미 하는 일을 반복했다. 대신 첫 줄을 굵게 해서 휴대폰 알림에 첫 줄만 보여도 무슨 일인지 알게 했다.

평소(직전 14일 가운데 값) 하루 6명 보던 계정을 465명이 본 날이었다.

같은 리포트 두 번 막기

예약 실행과 손으로 돌린 실행이 겹치면 같은 리포트가 두 번 갈 수 있다. 그래서 보내기 전에 이 게시물 리포트를 보낸다는 기록을 DB에 먼저 남기게 했다. 이미 다른 실행이 기록을 남겼다면 보내지 않는다.

기능을 처음 켜는 날도 조심해야 했다. 그냥 켜면 옛 게시물 리포트가 한꺼번에 전송돼서, 올린 지 7일이 넘은 게시물은 보내지 않게 했다.

내 컴퓨터에서 미리 보기

우리 웹 저장소는 공개라, 리포트 예약 실행 로그에는 무엇을 보냈고 무엇이 실패했는지만 남기게 했다. 공개 저장소 로그에 무엇을 남기는지는 7편에 모아 적었다.

메시지 내용을 미리 보고 싶을 때는 내 컴퓨터(로컬)에서 미리보기로 돌린다.

node --env-file=.env.local scripts/instagram-report.mjs          # 미리보기
node --env-file=.env.local scripts/instagram-report.mjs --send   # 실제로 보냄

첫 실전 리포트

10월 6일, 이슈를 열고 구현한 뒤 코드와 문구 검토를 따로 거쳤다. 고친 뒤 한 번 더 검토해 머지(만든 코드를 본 코드에 합치기)했다. 실제 DB로 두 번, 실제 디스코드로 한 번 돌려 숫자가 덮어써지는지와 중복 전송이 막히는지 확인했다.

첫 리포트는 10월 2일 게시물이었다. 3일 동안 252명이 봤고, 이 게시물까지 올린 11개 중 8번째였다. 검토를 두 번 거쳐 내보낸 리포트가 처음 전한 소식은 "보통보다 적다"였다. 보통 게시물(552명)의 절반이 안 됐다.

운영 중 잠긴 Meta 개발자 계정

10월 10일, 수집이 갑자기 실패했다.

API access blocked (code 200, OAuthException)

처음에는 토큰 만료부터 의심했다. 그런데 토큰은 멀쩡했고(만료는 12월), 가장 기본 호출인 /me부터 막혔다.

확인해 보니 Meta가 비정상 트래픽으로 개발자 계정을 잠근 상태였다. developers.facebook.com 에 들어가 계정 인증을 하니 바로 풀렸고, 인스타 계정 자체는 아무 문제가 없었다.

다행히 망가진 건 없었다. 풀린 뒤 GitHub Actions에서 손으로 한 번 돌리니 그날 게시물 숫자가 채워졌다.

계정 하루 지표는 마지막으로 받은 날의 7일 전부터 다시 받는 구조라 빈 날이 저절로 채워졌다. 게시물 리포트도 그날 숫자를 못 받으면 다음 날로 미루는 구조라 놓친 리포트는 없었다. 처음부터 며칠 치를 다시 받게 해 둔 덕분에 빠진 숫자와 리포트를 챙길 수 있었다.

어드민 인스타 탭

디스코드는 읽을 게 있을 때 알려 주는 용도고, 하루 단위 숫자는 어드민 화면에서 본다. 팔로워가 100명 미만이면 인스타가 하루 팔로워 증감을 안 줘서, 이 숫자도 따로 계산했다.

수집할 때마다 지금 팔로워 수를 기록해 두고, 그 차이로 증감을 세게 했다. "10월 6일 아침 기록보다 1명 늘었다"처럼 언제와 비교했는지도 같이 적었다.

표 머리의 "도달한 계정", "참여율"은 무엇을 센 숫자인지 바로 알기 어려워서 "본 사람", "반응률"로 바꿨다. 반응률은 (좋아요 + 댓글 + 저장 + 공유) ÷ 본 사람으로 계산한다. 인스타에는 참여율 공식 정의가 없어서 도구마다 분모가 다른데, 우리는 이 공식 하나로 고정했다.

이제 인스타 숫자는 매일 모이고, 읽을 게 있을 때만 디스코드로 리포트가 간다. 그런데 Google Play 통계 파일을 받으려니 권한을 줬는데도 403이 계속 나왔다. 다음 편에는 이 403이 기다리면 풀리는 건지, 내가 무엇을 잘못 넣은 건지 확인한 과정을 적었다.

다음 편: 3편 서비스 계정으로 경찰과 도둑 앱의 Google Play 통계 CSV 받기