4강 — 데이터를 어디서 가져오는가 (수집 3가지 방법 & Steam API)

🎯 학습 목표

• 분석할 데이터를 구하는 방법 3가지를 알고 상황에 맞게 고를 수 있다
• API가 무엇이고 왜 가장 안전한지 설명할 수 있다
• 우리가 쓸 steamreviews와 게임 ID가 어떻게 동작하는지 이해할 수 있다

📖 해설

1. 데이터 확보가 분석의 가장 큰 일입니다

분석이라고 하면 그래프 그리는 걸 떠올리시겠지만, 실무에선 데이터를 구하고 정리하는 데 전체 시간·비용의 60~70%가 듭니다. 가장 어렵고 비싼 작업이 바로 데이터 수집이에요. 그래서 이 강에서는 데이터를 어디서, 어떻게 가져오는지를 다룹니다.

2. 왜 자동 수집일까요? — 효율성 + 재현 가능성

상사가 "경쟁사 리뷰 1만 개 분석해줘"라고 했다고 해봅시다. - 수작업(복붙)이면? — 1개 30초 × 1만 = 30만 초 = 약 83시간(약 10일)이에요. 오타에 포맷도 뒤죽박죽이고요. 다음 달에 또 필요하면 처음부터 반복해야 합니다. - 프로그램으로 자동 수집하면? — 5분이면 끝나요. 정확하고 포맷도 일관되며, 다음에도 버튼 하나로 다시 실행하면 됩니다.

그래서 자동화의 두 키워드는 효율성(시간·비용·오류 절감)과 재현 가능성(언제든 다시)입니다.

3. 데이터 구하는 3가지 방법

안전한 순서로 기억하세요 — API > 공개 데이터셋 > 스크래핑. (Kaggle = 데이터 과학 경진대회 플랫폼, 허깅페이스 = AI 모델·데이터 공유 플랫폼)

4. API = 식당 메뉴판 (이 비유가 제일 중요해요)

API(Application Programming Interface)는 어떤 서비스가 "이건 가져가도 돼"라고 공식적으로 열어둔 데이터 통로입니다. - 식당 메뉴판으로 생각해 보세요. 메뉴에 있는 건 주문할 수 있어요("리뷰 목록 주세요" ✓). 하지만 메뉴에 없는 건 안 됩니다("리뷰어 이메일 주세요" ✗ — 개인정보라 애초에 안 올려놨죠). - 서비스가 안전한 것만 골라 열어두는 이유가 있어요. 모든 데이터를 다 열면 경쟁사 유출·개인정보 사고·서버 부하가 생기거든요. 우리는 그 메뉴 안에서만 요청할 수 있습니다.

꼭 기억하세요 — API는 만능이 아닙니다. 제공하는 범위 안에서만 받을 수 있지만, 그 안에서는 안전하고 빠릅니다.

5. API 호출은 어떻게 생겼을까요? (개념)

1. 게임 ID를 입력합니다. Steam의 모든 게임엔 고유 숫자 ID가 있어요(주민번호처럼요). 예를 들어 스타듀밸리는 413150입니다.
2. 그 ID로 API 주소(URL)를 만듭니다. 이 주소로 요청하면 Steam 서버가 리뷰를 줘요.
3. 서버가 JSON 형식으로 응답합니다. success: 1(요청 성공), total_reviews: 5847(총 리뷰 수)처럼 중괄호 안에 키:값 쌍으로 와요. (JSON = JavaScript Object Notation, 웹 데이터 표준 형식)

응답 속 주요 필드는 이렇습니다(이게 곧 분석거리예요).

6. API의 장단점 (상사에게 설명할 수 있어야 해요)

• 장점: ① 공식 허용이라 법적으로 안전합니다(법무팀 통과가 쉬워요). ② JSON으로 깔끔하게 와서 전처리 시간이 줄어요. ③ 필요한 것만 받으니 빠르고요. ④ 사이트 디자인이 바뀌어도 안정적입니다(버전 관리를 하거든요).
• 단점: ① 메뉴에 없으면 못 받아요(제한적). ② API 키(신분증) 발급이 필요할 수 있어요. ③ rate limit(요청 횟수 제한)이 있고요 — 서비스마다 다르지만 "하루 1만 회까지"처럼 상한을 두는 식입니다. ④ 갑자기 유료화될 수도 있습니다(실제 사례가 있어요).

7. 스크래핑은 왜 위험할까요?

웹 스크래핑은 신문 스크랩처럼 페이지 전체(HTML)를 받아 → 원하는 부분을 찾아 → 추출(파싱) → 저장하는 방식이에요. 자유도는 높지만 이런 문제가 있어요. - 법적 리스크(이용약관 위반·업무방해), 불안정(사이트 구조가 바뀌면 코드가 깨짐), 유지보수 악몽. - 결론은 이겁니다 — API가 있으면 무조건 API. 스크래핑은 API가 없고, 이용약관을 확인해 문제없을 때만 마지막 수단으로 씁니다. (자세한 경계는 5강에서 다뤄요.)

8. 우리의 도구 — steamreviews 라이브러리

steamreviews는 Steam 공식 API를 편하게 쓰도록 누군가 만들어 둔 라이브러리(레고 블록)예요. - 설치 한 줄에 코드 서너 줄이면 수천 개 리뷰를 수집합니다. - 페이지네이션(API가 한 번에 20개씩만 주는 걸 알아서 250번 반복), 에러 시 자동 재시도, rate limit 준수까지 다 대신 처리해줘요. - "바퀴를 다시 발명하지 마라"는 말처럼, 검증된 도구를 쓰면 우리는 데이터로 뭘 분석할까라는 본질에 집중할 수 있습니다.

게임 ID 찾는 법: Steam 상점에서 게임을 검색 → 게임 페이지 → 주소창 URL의 store.steampowered.com/app/숫자/에서 그 숫자가 ID예요. (데이터베이스의 기본키처럼, 게임을 식별하는 유일한 키죠.)

참고로 자주 분석하게 될 게임들의 ID를 몇 개 적어둡니다. 스타듀밸리 413150, 테라리아 105600, 카운터 스트라이크 2 730, 배틀그라운드 578080, 로스트아크 1599340. 분석 대상을 바꿀 때 이 숫자만 갈아 끼우면 됩니다.

실제 코드는 이렇게 생겼어요. 설치(pip install steamreviews) 후 라이브러리를 불러오고, 게임 ID 하나만 넘기면 끝입니다.

import steamreviews

app_id = '413150'  # 스타듀밸리
# 리뷰 묶음(review_dict)과 몇 번 요청해서 받았는지(query_count)를 함께 돌려줍니다
review_dict, query_count = steamreviews.download_reviews_for_app_id(app_id)

# 수집된 리뷰 개수 확인
print(f"수집된 리뷰: {len(review_dict['reviews'])}개")

실행하면 Downloading reviews for app_id 413150... Progress: 100%처럼 진행 상황이 찍히고, 가령 47번 요청을 나눠 보내 5,847개를 모았다는 식으로 결과가 나옵니다. 우리는 한 번 호출했을 뿐인데, 라이브러리가 안에서 수십 번을 알아서 반복해 준 거예요. 이 코드는 7강 실습에서 직접 돌려봅니다.

🔑 핵심 용어

🎮 게임 기획자 시점

"어떤 데이터가 있어야 어떤 분석이 가능한지"를 아는 게 핵심이에요. 예를 들어 "리뷰어 평균 플레이 시간"을 분석하려면 playtime_forever 필드가 있어야 하죠. 응답 구조를 알아야, 기획적으로 답할 수 있는 질문이 정해집니다. 또 playtime_forever가 분 단위라는 함정처럼, 데이터의 의미를 정확히 알아야 잘못된 결론을 피할 수 있어요.

⚠️ 흔한 오해 / 짚고 갈 점

• playtime_forever는 분 단위예요. 시간으로 착각하면 분석이 60배 틀어집니다(÷60 필요).
• "공개 API니까 다 받아도 된다"가 아닙니다. 범위·횟수 제한이 있고, 윤리·법적 경계는 5강에서 따로 다뤄요.

✅ 30초 정리

1. 데이터 구하기는 공개셋 / API / 스크래핑 3가지. 안전·속도·법적리스크를 보고 고르는 선택의 문제입니다.
2. API = 공식 메뉴판. 가장 안전·깔끔·빠릅니다. 메뉴에 있는 것만 받지만 그 안에선 최고예요.
3. 우리는 steamreviews로 게임 ID만 넣어 리뷰를 수집합니다(복잡한 건 라이브러리가 처리해요).

▶️ 다음 강 연결

기술적으로 수집이 가능해졌어요. 그런데 "해도 되는가"는 다른 문제입니다 → 5강: 데이터 수집의 법적·윤리적 경계 (can ≠ may).