인스타그램 API로 경쟁사 공개 계정 분석하기 — business_discovery 셋업 실전기

경쟁사의 인스타그램 계정을 매번 손으로 들여다보는 일이 번거로워서, 이걸 자동으로 가져올 수 없을까 하는 생각이 들었습니다. 막상 알아보니 길이 생각보다 복잡했습니다. 비로그인으로 긁자니 금방 막히고, 공식 API는 "남의 계정은 못 본다"는 이야기가 많았습니다. 이번에 처음부터 끝까지 직접 셋업을 밟아보았고, 중간에 (#10) 에러로 한참을 헤맸습니다. 같은 시도를 하려는 분이 저처럼 시간을 버리지 않도록 그 과정을 정리해두려 합니다.

이 글은 Instagram Graph API와 Meta 앱을 한 번이라도 만져봤다는 가정 하에 쓰였습니다. 사용한 API 버전은 v25.0 기준입니다.

비로그인 스크래핑으로는 어디까지 보이는가

가장 먼저 떠올린 방법은 로그인 없이 공개 프로필을 긁는 것이었습니다. 인스타그램에는 web_profile_info라는 비공식 엔드포인트가 있어서, 로그인 없이도 프로필 정보와 최근 게시물 일부를 JSON으로 돌려줍니다.

다만 여기엔 분명한 천장이 있었습니다. 비로그인 상태로는 최근 12개 남짓한 게시물까지만 보이고, 그 뒤로는 "로그인하라"는 벽(로그인 월)이 막아섭니다. 무한 스크롤로 과거를 더 파고들 수가 없습니다. 한두 번 들여다보는 용도라면 모를까, 전체 히스토리를 보거나 주기적으로 추적하기에는 적합하지 않다는 생각이 들었습니다.

한 가지 역설적인 점은 기억해둘 만합니다. 좋아요 수는 오히려 비로그인 쪽에서 더 잘 보입니다. 이 사실은 뒤에서 다시 등장합니다.

business_discovery — 남의 계정을 동의 없이 읽는 유일한 길

공식 경로를 파고들면서 알게 된 것은, Instagram Graph API의 대부분 기능이 "상대방이 내 앱에 권한을 위임해야" 동작한다는 사실이었습니다. 댓글 관리도, 인사이트 조회도, DM도 전부 그렇습니다. 즉 경쟁사가 내 앱에 로그인해줄 리 없으니, 보통의 방법으로는 남의 계정을 볼 수 없습니다.

그 와중에 단 하나의 예외가 있었습니다. 바로 business_discovery 엣지입니다. 이것은 상대방의 동의 없이도 공개 계정의 데이터를 읽을 수 있는 유일한 공식 통로입니다. 호출 형태를 보면 그 구조가 한눈에 들어옵니다.

curl -G "https://graph.facebook.com/v25.0/{MY_IG_USER_ID}" \
  --data-urlencode "fields=business_discovery.username(TARGET_USERNAME){followers_count,follows_count,media_count,biography,website,media.limit(25){caption,comments_count,timestamp,media_type,media_url,permalink}}" \
  --data-urlencode "access_token={TOKEN}"

핵심은 인증 주체가 '내 계정'이고, 분석 대상은 그저 파라미터라는 점입니다. TARGET_USERNAME 자리에 들어가는 상대 계정은 아무것도 하지 않고, 아무 동의도 하지 않습니다. 그래서 경쟁사 분석이 성립합니다.

물론 대상에는 조건이 붙습니다. 대상 계정이 공개 상태의 professional 계정(비즈니스 또는 크리에이터)이어야 합니다. 개인(personal) 계정은 빈 응답이 돌아오고, 나이 제한이 걸린 계정도 데이터를 주지 않습니다. 다행히 마케팅을 하는 계정은 대부분 professional이라 실무에서 걸리는 경우는 많지 않았습니다.

들어가기 전 갖춰야 할 세 가지 전제

본격적으로 셋업하기 전에, 갖춰야 할 전제가 세 가지 있습니다. 흥미로운 것은 세 가지 모두 '내 쪽' 자산이라는 점입니다. 상대방과는 아무 상관이 없습니다.

• 내 인스타그램 계정이 professional(비즈니스 또는 크리에이터)일 것
• 그 인스타그램 계정이 Facebook '페이지'에 연결되어 있을 것 (개인 프로필이 아니라 페이지입니다. 페이지가 없으면 내용이 하나도 없는 껍데기 페이지를 만들어도 됩니다)
• Meta 앱에 'Facebook 로그인이 포함된 Instagram API' 이용 사례가 설정되어 있을 것

여기서 제가 처음에 헷갈렸던 지점을 짚고 넘어가야겠습니다. 콘텐츠 발행에 흔히 쓰는 'Instagram 로그인' 경로, 즉 graph.instagram.com을 쓰는 방식에는 business_discovery 엣지가 없습니다. 이 엣지는 오직 graph.facebook.com을 쓰는 Facebook 로그인 경로에만 존재합니다. 발행과 분석은 다른 문이라는 것을, 저는 한참 뒤에야 깨달았습니다.

실제로 밟은 셋업 순서

제가 실제로 밟은 순서는 다음과 같습니다. 대부분 Meta Business Suite와 앱 대시보드를 오가는 작업입니다.

1. Meta Business Suite → 비즈니스 설정 → 페이지 → 새 Facebook 페이지 생성
   (내용이 하나도 없는 껍데기 페이지여도 무방)
2. 같은 곳 → Instagram 계정 → 내 IG를 그 페이지에 연결
3. 앱 대시보드 → 이용 사례에 'Facebook 로그인이 포함된 API 설정' 추가
   → 'Add required content permissions'
     (instagram_basic / pages_read_engagement / pages_show_list / business_management)
   → 메시지(DM) 권한은 필요 없음
4. Graph API Explorer → 앱 선택 → 권한 체크 → 토큰 발급 → 동의(페이지 + IG 포함)
5. me/accounts 로 '내 IG business account id' 확보 (페이지 ID가 아님에 주의)
6. 그 id 로 business_discovery 호출

5번 단계가 의외로 중요합니다. business_discovery 호출의 첫 경로 세그먼트에 들어가는 것은 페이지 ID가 아니라, 페이지에 연결된 인스타그램 계정의 id입니다. 이 값은 다음 호출로 확인할 수 있습니다.

curl -G "https://graph.facebook.com/v25.0/me/accounts" \
  --data-urlencode "fields=name,instagram_business_account{id,username}" \
  --data-urlencode "access_token={TOKEN}"

응답의 instagram_business_account.id가 바로 위 호출의 {MY_IG_USER_ID} 자리에 들어갈 값입니다.

#10 에러, 진짜 원인은 권한 한 줄이었습니다

여기까지 마치고 자신 있게 첫 호출을 날렸는데, 돌아온 것은 다음 한 줄이었습니다.

(#10) Application does not have permission for this action

솔직히 말하면 이 지점에서 가장 오래 헤맸습니다. 권한을 분명히 넣었는데 왜 안 되는지 알 수가 없었습니다. 그래서 무작정 다시 시도하는 대신, 무엇이 되고 무엇이 안 되는지를 하나씩 갈라보기로 했습니다.

먼저 instagram_basic 권한 자체는 멀쩡히 동작했습니다. me/accounts로 내 계정에 연결된 인스타그램 정보를 잘 읽어왔으니까요. 그렇다면 토큰이 죽은 것도 아니고, 기본 권한이 없는 것도 아니었습니다.

결정적인 단서는 다른 데서 나왔습니다. business_discovery로 '내 계정이 내 계정을 조회'하는 것조차 같은 #10 에러가 났습니다. 대상이 누구냐의 문제가 아니라, business_discovery 호출 자체가 막혀 있다는 뜻이었습니다. 이 사실을 확인한 순간 진단의 방향이 잡혔습니다.

검색을 하다 보면 "크리에이터 계정이라 안 된다"는 이야기가 나오는데, 이것은 스토리 게시 같은 다른 기능에 해당하는 이야기였습니다. business_discovery는 크리에이터 계정으로도 잘 됩니다. 이 부분에서 한 번 더 길을 잘못 들 뻔했습니다.

진짜 원인은 권한 한 줄이었습니다. business_discovery는 직관과 달리 인사이트(insights) 계열로 분류되어 있어서, instagram_basic만으로는 부족하고 instagram_manage_insights 권한이 추가로 필요했습니다. 권한 설명을 다시 읽어보니 힌트가 그대로 적혀 있었습니다.

instagram_manage_insights 권한은 앱이 Facebook 페이지에 연결된 Instagram 계정의 인사이트에 액세스하도록 허용합니다. 또한 앱이 다른 비즈니스 프로필의 프로필 정보와 미디어를 둘러보고 읽을 수 있습니다.

마지막 문장, "다른 비즈니스 프로필의 프로필 정보와 미디어를 둘러보고 읽을 수 있습니다"가 바로 business_discovery였던 것입니다. 좋아요 인사이트를 보겠다는 게 아닌데도 이 권한이 필요했던 셈입니다.

이 권한은 이용 사례의 기본 권한 묶음에는 들어 있지 않아서, 앱의 '권한 및 기능' 화면에서 따로 추가해야 했습니다. 개발 모드의 관리자는 이 권한이 '테스트 준비 완료(Standard access)' 상태이기만 하면 App Review 없이도 바로 쓸 수 있었습니다. 권한을 추가하고 토큰을 다시 발급하니, 그토록 막혀 있던 호출이 한 번에 성공했습니다.

돌이켜 생각해보면, self 조회도 막히는지 먼저 확인한 것이 진단을 빠르게 만든 갈림길이었습니다. 대상의 문제인지, 호출의 문제인지를 가르는 가장 간단한 실험이었습니다.

되는 것과 안 되는 것

막상 동작하고 나니, 이 API로 얻을 수 있는 것과 없는 것의 경계가 꽤 분명했습니다. 이 경계를 모르고 들어가면 "왜 이 필드는 비어 있지" 하며 시간을 쓰게 됩니다.

구분	가능 여부
프로필(팔로워·팔로잉·게시물 수, 소개, 웹사이트)	가능
게시물 캡션·게시 시각·미디어 타입·permalink	가능
게시물별 댓글 수	가능
전체 게시물 히스토리(페이징 커서로 수천 개)	가능
좋아요 수(like_count)	불가 — 전부 0으로 옴
댓글 본문(텍스트)	불가 — 개수만
도달·노출·저장·오디언스(인사이트)	불가 — 본인 계정만

여기서 앞서 말한 역설이 다시 등장합니다. 좋아요 수는 공식 API로는 0만 돌아오는데, 비로그인 web_profile_info로는 실제 값이 보입니다. 그래서 결국 정밀하게 분석하려면 두 경로를 섞게 됩니다. 히스토리와 캡션, 댓글 수는 공식 API로, 좋아요는 비로그인으로 보완하는 식입니다. 깔끔하지는 않지만, 현실적인 타협이었습니다.

셋업 이후에 만난 또 다른 벽들

해시태그는 또 다른 심사의 벽

계정 분석이 되니 욕심이 생겨서, 특정 해시태그의 인기 게시물도 가져와보려 했습니다. ig_hashtag_search와 top_media가 그 역할을 합니다. 그런데 같은 토큰으로 호출하자 API가 직접 "Facebook의 심사를 받으라"고 거절했습니다. 이 기능은 'Instagram Public Content Access'라는 별도 기능에 묶여 있어서, 비즈니스 인증과 App Review를 통과해야만 쓸 수 있었습니다.

business_discovery가 개발 모드에서 바로 됐던 것과 달리, 해시태그 쪽은 자가 사용으로도 열리지 않습니다. 심사 자체가 까다롭고 승인을 장담하기 어렵다는 점도 감안해야 합니다. 만약 해시태그 분석이 꼭 필요하다면, 공식 경로를 기다리기보다 Apify 같은 스크래핑 서비스를 쓰는 편이 현실적입니다. 가입은 무료이고 매월 일정 크레딧이 제공되며, 그 이상은 사용량만큼 과금되는 구조입니다. 다만 이것은 공식 경로가 아니며 약관상 회색 지대에 있다는 점은 분명히 인지하고 써야 합니다.

토큰을 오래 쓰려면

Graph API Explorer에서 받는 토큰은 한두 시간이면 만료되는 단기 토큰입니다. 잠깐 실험하기엔 충분하지만, 자동화에 박아두기엔 곤란합니다. 오래 쓰는 방법은 두 가지가 있었습니다.

하나는 단기 토큰을 60일짜리로 교환하는 방법입니다.

curl -G "https://graph.facebook.com/v25.0/oauth/access_token" \
  --data-urlencode "grant_type=fb_exchange_token" \
  --data-urlencode "client_id={APP_ID}" \
  --data-urlencode "client_secret={APP_SECRET}" \
  --data-urlencode "fb_exchange_token={SHORT_LIVED_TOKEN}"

다른 하나는 비즈니스 설정에서 시스템 사용자(System User) 토큰을 만드는 것입니다. 만료를 '없음'으로 둘 수 있어서 자동화에 가장 적합합니다. 다만 함정이 하나 있었습니다. 시스템 사용자에게 '앱' 역할을 할당하지 않으면 토큰 생성 단계에서 "사용 가능한 권한 없음"이라며 막힙니다. 페이지만 할당하고 앱을 빠뜨려서 한 번 더 헤맸습니다. 참고로 인스타그램 계정을 시스템 사용자에 직접 할당하려 하면 invalid_scope 글리치가 종종 나는데, 어차피 페이지를 통해 접근하므로 인스타그램을 직접 할당하지 않아도 동작했습니다.

영상은 캡션이 전부가 아니었습니다

처음에는 영상 게시물에서 캡션 텍스트만 가져올 수 있다고 생각했습니다. 그런데 응답에 media_url이 함께 오는데, 영상의 경우 이것이 실제 MP4 파일의 주소였습니다. 즉 파일을 내려받아 프레임을 뽑아 화면을 분석하거나, 음성을 추출해 받아쓰기를 하면 영상의 내용까지도 분석할 수 있습니다. 물론 API가 그 분석을 대신 해주는 것은 아니고, 파일을 받은 다음은 온전히 내 몫입니다.

정리하며

결국 business_discovery는 합법적이고, 비용이 들지 않으며, 계정이 차단될 걱정도 없는 경쟁사 분석의 정공법이었습니다. 비로그인 스크래핑이 주는 불안함도, 자동화 계정이 밴당할 위험도 여기에는 없습니다.

다만 공짜로 얻는 길은 아니었습니다. Facebook 페이지 연결, Facebook 로그인 이용 사례, 그리고 instagram_manage_insights 권한이라는 세 개의 관문을 지나야 했고, 좋아요 수와 해시태그라는 데이터의 한계도 분명했습니다. 이 관문과 한계를 미리 알고 들어가야 시간을 버리지 않는다는 것이, 이번에 얻은 가장 실용적인 교훈입니다.

그리고 가장 기억에 남는 삽질은 역시 #10 에러였습니다. 그토록 막막했던 원인이 결국 권한 한 줄이었다는 사실은, 에러 메시지가 친절하지 않을수록 "무엇이 되고 무엇이 안 되는지"를 차분히 갈라보는 일이 중요하다는 것을 다시 한번 일깨워주었습니다.