Michael Johnson프로필 스냅샷 하나만으로 두 IG 크리에이터를 비교하는 일은 쉽지만, 누가 꾸준히 콘텐츠를 게시하는지, 게시물이 시간이 지나면서 어떤 반응을 얻는지 파악하기는 더 어렵습니다. 한 번만 확인하면 게시물의 게시 시점이 서로 달라 비교가 왜곡되고, 수동으로 관리하는 표는 금세 오래된 정보가 됩니다. 실용적인 해결책은 공개 미디어를 일정에 따라 수집하고, 각 응답을 별도의 관찰 기록으로 저장한 뒤 자체 데이터에서 변화를 계산하는 것입니다.
아래는 같은 분야의 공개 계정을 매주 비교해야 하는 마케터, 분석가 또는 개발자를 위한 실무 구성입니다. 데이터 수집에는 jsonscraper의 IG Scraper API를 사용하고, Python으로 일정을 관리하고 데이터를 정규화해 기록을 저장합니다. 이 글은 프로필 및 경쟁 게시물 모니터링을 다룬 주제를 이어가며, 비교 보고서에 활용할 수 있는 일관된 관찰 데이터 모델에 초점을 맞춥니다.
먼저 비교할 대상을 정하세요
요구사항은 보통 “성과가 좋은 크리에이터 찾기”처럼 넓게 표현됩니다. 기술적으로 유용한 모니터링을 위해서는 측정 가능한 질문으로 범위를 좁히는 편이 좋습니다. 게시물이 얼마나 자주 올라오는지, 어떤 형식이 등장하는지, 확인 시점에 공개된 좋아요와 댓글 수가 얼마인지, 그리고 게시 후 이 수치가 어떻게 변하는지를 살펴볼 수 있습니다. 이런 지표를 활용하면 수동 검토를 위한 계정을 선별하거나 비교 요약을 만들 수 있습니다.
공개 카운터는 요청 시점의 스냅샷입니다. 따라서 아키텍처에서 중요한 것은 복잡한 모델이 아니라 수치와 함께 수집 시각을 저장하는 일입니다. 매일 밤 같은 미디어의 정보를 받아 이전 행을 덮어쓰면 증가량 계산에 필요한 기록이 사라집니다. 대신 관찰 데이터를 변경하지 않고 저장하세요. 게시물 하나와 수집 시각 하나당 한 행을 기록하면 됩니다.
비교는 같은 기간, 서로 비교 가능한 게시물로 제한해야 합니다. 예를 들어 같은 달력 월에 처음 발견된 게시물을 살펴보거나, 각 스냅샷에서 게시물의 게시 후 경과 시간을 고려할 수 있습니다. 그렇지 않으면 어제 올라온 릴스는 오래된 게시물보다 반응을 모을 시간이 짧다는 이유만으로 성과가 낮아 보일 수 있습니다.
파이프라인: 요청, 정규화, 기록
최소한의 프로세스는 네 단계로 구성됩니다. 선택한 프로필에서 공개 미디어 목록을 가져오고, 응답을 공통 스키마로 변환하고, 행을 저장소에 기록한 뒤, 일정에 따라 보고서를 생성합니다. IG Scraper API 페이지에는 기본 URL과 게시물을 여러 청크로 반환하는 사용자 경로를 포함한 엔드포인트 안내가 나와 있습니다. 통합하기 전에 각 경로의 매개변수와 응답 예시는 Postman 컬렉션에서 확인하세요.
API 기본 URL은 https://ig.jsonscraper.com입니다. 초기 확인을 위해 문서에는 사용자 이름으로 프로필을 조회하는 요청이 나와 있습니다. 게시된 예시에서는 GET /v1/user/by/username에 username, license_key, cache_timeout 매개변수를 사용합니다. 게시물을 가져오는 경로는 GET /v1/user/medias/chunk입니다. 정확한 인수, 이어받기 필드, 응답 구조는 해당 요청의 문서를 확인하세요. 한 경로의 스키마를 다른 경로에 그대로 적용하지 마세요.
import os
import requests
BASE = "https://ig.jsonscraper.com"
KEY = os.environ["JSONSCRAPER_LICENSE_KEY"]
def get_profile(username: str) -> dict:
response = requests.get(
f"{BASE}/v1/user/by/username",
params={
"username": username,
"license_key": KEY,
"cache_timeout": 60,
},
timeout=30,
)
response.raise_for_status()
return response.json()
print(get_profile("example_account"))
이 짧은 예시는 문서에 나온 프로필 경로를 따르며 HTTP GET 요청으로 매개변수를 전달하는 방법을 보여줍니다. cache_timeout=60은 게시된 예시에 있는 값입니다. 이 매개변수가 지원되는 경로에서만 사용하고 자세한 사항은 문서와 대조해 확인하세요. 키는 코드나 브라우저 애플리케이션이 아니라 환경 변수에 저장합니다.
게시물 수집 연결하기
프로필 확인을 마친 뒤 미디어 목록 요청을 추가하세요. API 페이지에는 GET /v1/user/medias/chunk가 나와 있습니다. 결과를 처리할 때는 문서에서 안내하는 청크 처리 방식을 사용하세요. 매개변수 이름과 페이지네이션 종료 조건은 경로 이름만 보고 추측하지 말고 Postman의 최신 요청 설명에서 확인해야 합니다.
아래는 전송 호출의 골격이지, 완성된 엔드포인트 계약이 아닙니다. 실행 전에 문서에 명시된 인수로 params를 채우세요. 응답을 받은 뒤 어댑터는 선택한 경로의 실제 JSON으로 확인된 필드만 읽어야 합니다.
def fetch_media_chunk(username: str, params: dict) -> dict:
query = {
**params,
"username": username,
"license_key": KEY,
}
response = requests.get(
f"{BASE}/v1/user/medias/chunk",
params=query,
timeout=30,
)
response.raise_for_status()
return response.json()
다음으로 응답을 내부 형식에 맞게 변환하는 어댑터 함수를 작성하세요. 분석에는 안정적인 게시물 식별자, 작성자, 링크, 게시 날짜, 미디어 유형, 사용 가능한 공개 카운터가 유용할 수 있습니다. 정확한 필드 이름과 유형은 문서와 JSON 예시를 확인하세요. 지표가 없으면 0을 넣지 말고 빈 값으로 저장해야 합니다. 0은 실제로 측정한 카운터가 0이라는 뜻이고, 빈 값은 데이터가 없다는 뜻입니다.
def normalize_media(item: dict, username: str, observed_at: str) -> dict:
# 선택한 엔드포인트의 JSON을 확인한 후에만 키를 지정하세요.
return {
"username": username,
"media_id": item.get("DOCUMENTED_MEDIA_ID_KEY"),
"media_url": item.get("DOCUMENTED_MEDIA_URL_KEY"),
"published_at": item.get("DOCUMENTED_PUBLISHED_AT_KEY"),
"media_type": item.get("DOCUMENTED_MEDIA_TYPE_KEY"),
"likes": item.get("DOCUMENTED_LIKE_COUNT_KEY"),
"comments": item.get("DOCUMENTED_COMMENT_COUNT_KEY"),
"observed_at": observed_at,
}
자리표시자 이름을 해당 엔드포인트 응답의 정확한 키로 바꾸고, 저장해 둔 JSON 샘플을 대상으로 매핑 테스트를 작성하세요. 그러면 통합 업데이트 시 스키마 변경을 알아챌 수 있으며, 확인되지 않은 필드 이름을 확정된 계약인 것처럼 제시하지 않게 됩니다.
현재 값만이 아니라 관찰 기록을 저장하세요
프로토타입에는 CSV를 사용할 수 있고, 정기 운영에는 PostgreSQL, Supabase 또는 분석용 데이터 웨어하우스가 적합합니다. 관찰 테이블에는 username, media_id, published_at, observed_at, likes, comments, 원본 JSON을 저장할 수 있습니다. media_id와 observed_at의 조합으로 스냅샷을 고유하게 식별합니다. 별도의 프로필 테이블에는 추적할 계정 목록과 모니터링 추가 날짜를 저장합니다.
원본 응답을 저장하면 디버깅과 정규화 데이터 재구성에 도움이 됩니다. 프로젝트 목적과 조직의 규칙에 따라 보존 기간을 제한하고, 테이블 접근을 관리하며, 선택한 분석에 필요하지 않은 정보는 수집하지 마세요. CRM이나 직접 마케팅 활동에 활용한다면 적용 가능한 법적 근거를 별도로 확인해야 합니다. 공개 데이터에 기술적으로 접근할 수 있다는 사실만으로 이 문제가 해결되지는 않습니다.
CREATE TABLE media_observations (
username TEXT NOT NULL,
media_id TEXT NOT NULL,
media_url TEXT,
published_at TIMESTAMPTZ,
observed_at TIMESTAMPTZ NOT NULL,
media_type TEXT,
likes BIGINT,
comments BIGINT,
raw_json JSONB,
PRIMARY KEY (media_id, observed_at)
);
응답 검증이 성공한 뒤 데이터를 묶음으로 기록하세요. 동일한 작업을 다시 실행해도 기본 키 조합 덕분에 스냅샷 중복 생성을 막을 수 있으며, 애플리케이션에서는 충돌 시 삽입을 건너뛰도록 설정할 수 있습니다. 다른 시점에 새로 실행하면 별도 행이 저장되어 시계열 기록이 이어집니다.
질문에 답하는 지표를 계산하세요
게시 빈도를 나타내는 기본 지표는 선택한 기간에 계정이 게시한 고유 미디어 수입니다. published_at 필드가 있고 올바르게 해석되었다면 쉽게 계산할 수 있습니다. 공개 반응의 변화를 평가하려면 동일한 media_id의 두 관찰값을 비교하세요. 좋아요의 절대 변화량은 나중 카운터에서 이전 카운터를 뺀 값이고, 상대 변화율은 변화량을 이전 값으로 나눈 값입니다. 댓글에도 같은 계산을 적용할 수 있습니다.
이전 값이 0이거나 없는 경우 상대 증가율은 정의되지 않습니다. 절대 차이를 표시하고 백분율 계산을 위한 기준값이 없다는 점을 분명히 하세요. 관찰 사이에 카운터가 변할 수 있으므로 보고서에는 스냅샷 간격과 마지막 수집 시각을 표시해야 합니다. 이런 세부 정보는 독자가 수치를 올바르게 해석하는 데 도움이 됩니다.
def growth(previous, current):
if previous is None or current is None:
return {"delta": None, "rate": None}
delta = current - previous
rate = None if previous == 0 else delta / previous
return {"delta": delta, "rate": rate}
설명 가능한 가중치 없이 계정을 하나의 순위로 합산하지 마세요. 실용적인 보고서는 보통 게시물 수, 게시물당 좋아요와 댓글의 중앙값, 형식별 분포, 같은 게시 후 경과 시간대에서의 반응 변화를 함께 보여줍니다. 중앙값은 유난히 큰 게시물 하나가 결과에 미치는 영향을 줄이고, 게시물 수는 비교의 기반이 되는 표본 크기를 보여줍니다.
게시물의 게시 후 경과 시간은 두 가지 방식으로 고려할 수 있습니다. 첫 번째는 미디어를 처음 발견한 뒤 동일한 간격, 예를 들어 일정한 주기로 카운터를 반복 수집하는 것입니다. 두 번째는 비슷한 경과 시간대에 관찰된 게시물을 비교하는 것입니다. 일정 실행을 놓쳤다면 실제 변화가 정확히 하루 동안의 증가량인 것처럼 표시하지 마세요. 시간 기록을 사용해 실제 간격을 계산해야 합니다.
실행과 품질 관리를 자동화하세요
cron, GitHub Actions 또는 ETL 오케스트레이터를 사용해 수집을 일정에 따라 실행하세요. 작업 순서는 간단합니다. 계정 목록을 읽고, 필요한 청크를 요청하고, HTTP 상태와 응답 구조를 확인하고, 데이터를 정규화해 스냅샷을 저장한 다음 실행 로그를 기록합니다. 실행마다 처리한 계정 수, 미디어 수, 오류, 소요 시간을 기록하면 실제 활동 변화와 수집 장애를 구분하는 데 도움이 됩니다.
일시적인 오류에는 횟수를 제한하고 대기 시간을 두어 재시도하세요. 오류 응답을 저장할 때는 비밀 키를 제외한 요청 맥락을 남기세요. 커서를 따라 무한 반복하지 마세요. 중단 조건은 엔드포인트 응답에 명시된 종료 조건을 따라야 합니다. 문서에 제한이나 사용 규칙이 있다면 그에 맞춰 수집 빈도와 표본 크기를 설정하세요.
cache_timeout 매개변수는 지원되는 경로의 IG API 페이지에 명시되어 있습니다. 짧은 시간 안에 다시 요청해도 가치가 더해지지 않는 경우 캐시가 유용합니다. 변화를 추적할 때는 분석 질문에 맞는 수집 간격을 선택하세요. 예를 들어 구체적인 목적 없이 같은 프로필을 자주 반복 요청하는 것보다 매일 스냅샷을 수집하는 편이 주간 검토에 더 적합합니다.
정기 실행을 시작하기 전에 작은 표본으로 테스트하세요. 응답 샘플을 저장하고 식별자와 날짜를 확인한 뒤, 정규화된 필드를 원본 JSON과 대조하고 몇 개 행은 직접 검토합니다. 값 누락, 빈 목록, 예상과 다른 형식을 검사하는 테스트도 추가하세요. API가 변경되면 이런 검사가 주말에 보고서가 어긋난 뒤 알아차리는 것보다 빠르게 문제를 발견해 줍니다.
AI는 어디에 유용할까요
AI는 계산이 끝난 결과를 간결하게 설명하는 마지막 단계에 적합합니다. 원시 데이터 전체가 아니라 집계값과 게시물 링크를 전달하세요. 예를 들어 주별 미디어 수, 공개 반응의 중앙값, 지정한 기간에 변화가 가장 컸던 게시물 목록을 입력할 수 있습니다. 모델에 관찰 내용을 정리하고 근거가 된 레코드 식별자를 함께 표시하도록 요청하세요.
동일한 규칙에서 재현 가능한 결과가 나오도록 지표 계산은 일반 코드로 처리하는 편이 좋습니다. 모델은 텍스트 요약을 작성하거나 미리 정한 주제별로 캡션을 분류하거나 수동 검토를 위한 질문을 제안할 수 있습니다. 주제 분류에 사용한다면 모델이 붙인 라벨을 원래 캡션과 별도로 저장하고 지침 또는 분류기의 버전을 기록하세요. 그래야 이후 변경으로 과거 기록이 눈에 띄지 않게 덮어쓰이는 일을 막을 수 있습니다.
자동 보고서를 특정 인물의 채용, 계약 또는 평가에 대한 자동 의사결정으로 바꾸지 마세요. 공개 데이터는 범위를 제한한 콘텐츠 분석에 사용하고, 특히 사업상 결정에 영향을 줄 때는 결론을 사람이 직접 검토해야 합니다. 이렇게 하면 모니터링의 유용성을 유지하면서 측정 가능한 카운터와 그 해석을 구분할 수 있습니다.
결과는 어떤 모습일까요
여러 차례 수집을 거치면 각 게시물이 언제 발견되었는지, 각 관찰 시점에 반응이 얼마나 있었는지, 지표가 어떻게 바뀌었는지 보여주는 표가 만들어집니다. 주간 요약으로는 누가 꾸준히 게시했는지, 어떤 형식을 더 자주 사용했는지, 비교 가능한 스냅샷 사이에 어떤 게시물이 반응을 얻었는지, 확실한 비교를 위한 데이터가 아직 부족한 곳은 어디인지 등 실무적인 질문에 답할 수 있습니다.
이 프로세스는 간헐적인 수동 확인을 반복 가능한 조사로 바꾸는 데 도움이 됩니다. 그렇다고 정성적 콘텐츠 분석을 대체하는 것은 아닙니다. 지표는 게시 빈도와 확인 가능한 공개 반응을 설명할 뿐, 의미와 잠재 고객, 브랜드 적합성은 별도로 평가해야 합니다. 다만 일정한 수집 일정과 보존된 기록, 명확한 계산 로직을 갖추면 평가를 검증할 수 있고 팀에서 활용하기도 쉬워집니다.
시작하려면 IG Scraper API 페이지를 열고 Postman 문서에서 게시물 경로의 매개변수를 확인하세요. 그런 다음 테스트 계정으로 어댑터를 구현하고 첫 스냅샷을 저장합니다. 스키마가 확인되면 일정 실행, 오류 관리, 선택한 지표에 대한 보고서를 추가하세요.