5강 — 데이터 수집의 경계 (can ≠ may)
🎯 학습 목표
- "기술적으로 가능하다"와 "해도 된다"가 왜 다른지 설명할 수 있다 (can vs may)
- 무엇을 보고 수집해도 되는지 판단할 수 있다
- 면접에서 "이 데이터 어디서 수집했나요?"라는 질문에 떳떳하게 답할 수 있다
📖 해설
1. can ≠ may
4강에서 코드 세 줄로 수천 개 리뷰를 가져올 수 있다는 걸 봤죠. 기술적으로 가능(can)합니다. 그런데 해도 되는 걸까요(may)? - Can I do this? = 할 능력이 있느냐(기술) - May I do this? = 해도 되느냐(허락) - 우리는 지금까지 "can"을 배웠고, 이 강에서 "may"를 배웁니다. 잘못하면 소송·계정 영구정지·회사 타격까지 실제로 일어나거든요.
2. 실제로 벌어진 3가지 사례
| 사례 | 무엇을 했나 | 결과 | 교훈 |
|---|---|---|---|
| 데이터 업체 | 공개된 프로필 정보를 대량 수집("어차피 공개잖아") | 약관 위반 소송, 수천만 달러(수백억) 배상 | 공개됨 ≠ 수집해도 됨 |
| 연구자 | 학술 목적으로 SNS 데이터 대량 수집("연구니까 괜찮겠지") | 계정 영구정지 + 논문 게재 거부 + 윤리 위반 조사 | 목적이 좋아도 방법이 정당화되지 않음 |
| 스타트업 | 경쟁사 가격을 자동 수집해 비교 서비스 | 업무방해 고소 → 서비스 중단 → 투자 철회 → 폐업 | 아이디어·기술이 좋아도 약관 미확인이면 끝 |
3. 이게 왜 나와 상관있을까요?
"나는 대기업도 연구자도 스타트업도 아닌데?"라고 생각하실 수 있어요. 그런데 세 관점 모두 해당됩니다. - 개인: 약관을 위반하면 Steam 계정이 영구 차단될 수 있어요(산 게임이 다 날아갑니다). 심하면 법적 책임까지요. - 취업(이게 중요해요): 포트폴리오에 "게임 리뷰 감성 분석"을 넣으면 면접관이 "이 데이터 어디서 가져왔나요?"라고 묻습니다. "스크래핑했어요"라고 답하면 → "약관은 확인했나요?"에서 막혀요. 여기서 막히면 오히려 큰 마이너스입니다(기술력은 있는데 판단력이 없다는 인상을 주거든요). - 회사: 입사 후 이런 실수를 하면 회사에 큰 손해를 끼칠 수 있어요. 그리고 "몰랐다"는 변명이 안 됩니다(법은 모르면 오히려 더 엄격할 때도 있어요).
4. 판단하는 4가지 요소
- 이용약관(ToS, Terms of Service) — 가입할 때 "동의" 누르는 그 긴 문서예요. "자동화된 수집 금지", "상업적 사용 금지" 같은 게 적혀 있고, 어기면 계약 위반입니다.
- API 정책 — API 제공처의 개발자 문서(이렇게 쓰세요/하루 몇 번까지/이 목적으로만).
- 저작권법 — 리뷰 텍스트도 작성자에게 저작권이 있는 저작물이에요. 함부로 복제·상업 이용하면 침해가 됩니다.
- 개인정보 보호법 — 한국엔 개인정보보호법, 유럽엔 더 엄격한 GDPR이 있어요. 이름·프로필 사진도 개인정보일 수 있습니다.
5. 약관에서 찾을 5개 키워드
약관은 깁니다. 다 읽지 말고 키워드로 검색하세요(대부분 영어라 번역기를 써도 돼요. 중요한 건 확인하는 습관입니다).
| 키워드 | 뜻 |
|---|---|
automated |
자동화된 접근 금지 |
scraping |
스크래핑 금지 |
crawling |
크롤링(웹 돌며 수집) 금지 |
commercial use |
상업적 사용 관련(non-commercial only=비상업만) |
rate limit |
속도/횟수 제한 |
예문을 같이 해석해 볼게요. - "You agree not to use any automated system to access the Service" → 봇·크롤러·스크립트로 접근하지 말라는 뜻이에요(사람이 브라우저로 보는 건 OK). - "API access is limited to non-commercial, personal use only" → 이 API로 돈 버는 서비스를 만들면 안 되고, 개인 학습·취미로만 쓰라는 거예요.
6. 수집 전 체크리스트 (3가지 카테고리)
- 법적·정책: ① 약관이 자동 수집을 금지하는가 ② API 사용 정책을 확인했는가 ③ 상업적 이용 시 별도 라이선스가 필요한가
- 기술적: ④ rate limit을 확인했는가 ⑤ 내 코드가 그 제한을 지키는가(예: 요청 사이에 1초 대기)
- 윤리적: ⑥ 수집 목적이 명확한가("일단 다 긁자"는 금물이에요) ⑦ 필요 이상으로 긁지 않는가(100개면 충분한데 10만 개는 ✗)
7. 우리 과정엔 어떻게 적용될까요?
- 목적: 학습·포트폴리오(비상업) → 안전한 영역입니다.
- 방법: 공식 API만(steamreviews) 씁니다. 웹 스크래핑은 하지 않아요.
- 양: 수백~수천 건, 분석에 필요한 만큼만.
- 가이드라인 네 줄로 정리할게요 — ① 공식 API만 ② 속도 제한 준수(요청 사이 1~2초) ③ 적정 수집량 ④ 비상업적.
8. 면접 모범답안 (그대로 외워두세요)
"데이터 수집에서 무엇을 고려했나요?"라는 질문엔 이 네 가지로 답하세요. 1. 수집 전에 이용약관을 확인했습니다. 2. API 호출 제한을 준수했습니다. 3. 학습에 필요한 수준으로 수집량을 제한했습니다. 4. "기술적 가능성과 윤리적 허용의 균형"을 배웠습니다. ← 면접관이 가장 듣고 싶어 하는 문장이에요.
🔑 핵심 용어
| 용어 | 쉬운 설명 |
|---|---|
| can vs may | 할 수 있다(기술) vs 해도 된다(허락) |
| 이용약관(ToS) | 가입 시 동의하는 문서. 수집 가능 여부의 1차 기준 |
| GDPR | 유럽의 엄격한 개인정보 보호 규정 |
| rate limit | API 요청 횟수 제한 |
| 비상업적(non-commercial) | 돈 버는 목적이 아닌 용도 |
🎮 게임 기획자 시점
포트폴리오의 신뢰도는 결과물의 화려함이 아니라 과정의 판단력에서 나옵니다. "데이터 출처: Steam 공식 API, 약관 확인 완료, 학습 목적 비상업적"이라는 한 줄이 면접에서 "기술력 + 판단력을 모두 갖춘 사람"이라는 인상을 만들어요. 게임 업계는 IP·약관·퍼블리싱 계약에 민감하니, 이 감각은 기획자 직무에서도 그대로 자산이 됩니다.
⚠️ 흔한 오해 / 짚고 갈 점
- "공개된 정보 = 마음대로 써도 됨"이 절대 아닙니다. 사례 1이 정확히 그 착각으로 수백억을 물었어요.
- "좋은 목적이면 봐준다"도 아니에요. 사례 2(학술)가 반례입니다.
✅ 30초 정리
- 기술적 가능(can) ≠ 윤리·법적 허용(may). 실무에선 해도 되냐가 더 중요해요.
- 판단 4요소(약관·API정책·저작권·개인정보) + 키워드 검색 + 체크리스트 습관화.
- 우리는 공식 API만·적정량·비상업으로 안전하게. 이 판단력이 곧 취업 경쟁력입니다.
▶️ 다음 강 연결
이론(수집 방법 + 경계)을 다 배웠어요. 이제 진짜 손으로 해봅시다 → 6강: Steam 리뷰 수집 실습 + 파이썬 기초.