목표

✅ 데스크 리서치 보강
🔄 문제 원인 분석 및 정의
✅ 파이썬을 이용한 웹 스크래핑 완강

🌟 목표 달성률 : 75%

데이터 분석 강의

chap.2 파이썬을 이용한 웹 스크래핑

교수자 : Charles R. Severance

데이터가 흐르는 길: XML부터 API 보안까지

1. 데이터의 포장법: XML vs JSON

데이터를 주고받으려면 약속된 형식이 필요하다. 마치 서류를 보낼 때 특정 양식을 사용하는 것과 같다.

1️⃣ XML (과거의 표준): 태그(< >) 기반의 엄격한 형식. 문서 구조를 정교하게 표현할 수 있지만 무겁다. (예: 공공데이터 API, 금융권 시스템)
2️⃣ JSON (현재의 대세): 키-값({Key: Value}) 기반의 경량 형식. 가독성이 좋고 처리 속도가 빨라 현대 웹/앱 서비스의 표준으로 자리 잡았다.

2. 데이터의 설계도: XML Schema & XSD

데이터가 내 마음대로 들어오면 시스템은 망가진다. 그래서 '설계도'가 필요하다.

• XSD: 데이터의 타입(숫자인지 문자인지), 필수 포함 여부, 순서 등을 정의한 규칙서.

왜 중요한가? 데이터 품질을 보장한다. 잘못된 형식의 데이터가 들어오면 입구에서 컷(Error)하여 시스템의 안정성을 높인다.

3. 시스템의 조립법: SOA (Service Oriented Architecture)

거대한 서비스를 하나의 덩어리로 만들지 않고, '기능별 레고 블록'으로 쪼개서 설계하는 방식이다.

• 핵심: 각 서비스는 독립적이며, 서로 표준화된 방식(API)으로 대화합니다.
• 장점: 재사용성이 높고, 특정 기능이 고장 나도 전체 서비스가 멈추지 않는 유연함을 가진다.

+ SOA의 진화: MSA (Microservices Architecture)
오늘 배운 SOA가 "서비스 단위로 쪼개자"는 철학의 시초라면, MSA는 그 철학을 현대의 클라우드 환경에 맞춰 더 가볍고 날카롭게 다듬은 결과물이다.

1️⃣ SOA (과거): 서비스 덩어리가 다소 크고, ESB(Enterprise Service Bus)라는 중앙 관리자가 모든 대화를 통제하는 구조. 관리는 편하지만 중앙이 막히면 전체가 느려질 수 있다.
2️⃣ MSA (현재 대세): 서비스를 더 작게(Micro) 쪼개고, 중앙 통제 대신 서비스들끼리 직접 가벼운 REST API(주로 JSON)로 빠르게 소통한다.

4. 실전: API를 통해 데이터 뜯어보기 (Parsing)

구글 지도 API 예제를 통해 확인한 데이터 수집 메커니즘

① Request: 우리가 원하는 조건(주소 등)을 담아 서버에 요청을 보낸다.
② Response: 서버는 전체 데이터가 아닌, 질문에 맞는 정보만 JSON 봉투에 담아 보내준다.
③ Parsing: 파이썬의 json.loads()와 같은 도구로 봉투를 뜯어, 수많은 정보 중 우리가 필요한 '위도/경도' 알맹이만 핀셋으로 집어낸다.

5. 출입 통제와 보안: OAuth & API Key

아무나 우리 회사의 소중한 데이터를 가져가게 둘 순 없다. 그래서 '디지털 신분증'이 필요하다.

• API Key: "누가, 얼마나" 가져가는지 추적하고 과금하는 기준이 된다.

  ⛔️ 보안의 핵심: 이 키는 내 신용카드 번호와 같다. 절대 코드에 직접 노출하지 않고 별도의 파일로 관리해야 한다. 유출 시 즉시 재발급(Regenerate)하여 피해를 막아야 한다.

서비스 기획 입문 과제

네이버 플러스 스토어

step 3. 문제 원인을 파악하고 문제 정의

1. 문제 현상

문제 현상
사용자는 멤버십 혜택의 조건과 범위를 파악하기 어렵다고 느낀다.

부정적 결과
1. (사용자 관점) 멤버십 비용을 지불하고 있음에도 혜택을 충분히 활용하고 있다는 확신이 없어 심리적 만족도가 낮고, 멤버십 유지 동기가 약해진다.
2. (비즈니스 관점) 다양한 혜택을 설계하고 제공하는 데 비용을 투자했음에도, 사용자가 인지하지 못해 이용되지 않는 혜택이 발생하고 있어 투자 대비 효과가 낮아진다.

2. 문제 원인 파악

(Why 1) 왜 파악하기 어렵다고 느끼는가?
멤버십 혜택이 쇼핑, 콘텐츠, 오프라인 제휴, 생활 서비스 등 정말 다양하게 여러 영역에 걸쳐 있는데, 사용자에게 노출되는 혜택은 쇼핑·결제 맥락의 일부에 그치기 때문이다.
(Why 2) 왜 쇼핑·결제 맥락 외 혜택이 인지되지 않는가?
혜택을 이용할 수 있는 맥락과 혜택을 인지하는 시점이 분리되어 있어, 사용자의 기억에 의존해야 하기 때문이다.
(Why 3) 왜 혜택이 기억에 남지 않는가?
혜택이 다양한 영역에 걸쳐 있어 가입 시점에 한 번 인지한 뒤에는, 사용 과정에서 사용자가 직접 찾아보지 않으면 다시 떠올리기 어렵고, 서비스 내에서도 이를 반복적으로 상기시켜 주는 경험이 부족하기 때문이다.

문제 원인 : 멤버십 혜택의 노출 시점과 사용 맥락이 어긋나 있어, 사용자는 혜택을 ‘존재하는 정보’로는 알더라도 ‘내가 지금 쓸 수 있는 가치’로는 체감하지 못한다.

(Why 4) 왜 체감할 수 있는 경험이 설계되어 있지 않은가?
혜택이 다양한 만큼 사용자마다 실제로 이용하는 혜택이 달라, 모든 사용자에게 일괄적으로 혜택을 반복하여 고지할 수 없기 때문이다.
(Why 5) 왜 맞춤 고지를 하지 못하는가?
서비스가 사용자의 혜택 이용 패턴과 생활 맥락을 파악해 개인화된 방식으로 혜택을 고지하는 체계가 갖춰져 있지 않기 때문이다.
(Why 6)왜 개인화 방식이 갖춰져 있지 않은가?
서비스가 보유한 사용자 행동 및 이용 맥락 정보를 혜택 노출과 연결해, 개인화된 혜택 안내 경험으로 전환하는 체계가 충분히 설계되어 있지 않기 때문이다.

문제 정의 : 사용자는 네이버플러스 멤버십 혜택을 자신의 이용 맥락에서 적시에 인지하지 못해, 멤버십의 실질적 가치를 충분히 체감하지 못한다.

---

처음엔 Why6까지 가서 정의를 도출하였으나 뭔가 문제 해결방안을 미리 염두해 두고 도출한 느낌이라 지우고 Why3까지 하고 문제 정의를 도출했다.

오늘의 회고

• 성취 : 파이썬을 이용한 웹 스크래핑 완강
• 개선 : 문제 원인 파악 및 문제 정의 논리적 허점 보완하기, 튜터님 피드백 받기
• 학습 : 인터넷에서 데이터를 주고받는 전체 메커니즘에 대한 이해

💭 오늘의 한 줄 평 : 사용자를 이해하기 위해 네이버 플러스 스토어에 대한 탐색을 하다가... 장을 봤다