8Knockdowns

한국어 (KO) English (EN) 1. 독립 데이터 파일(JSON) 분리의 본질적 이유 기존 하드코딩 방식의 가장 큰 한계는 새로운 학습용 영어 청크를 추가하거나 수정할 때마다 전체 애플리케이션 소스 코드(`index.html`)를 직접 건드려야 한다는 점이었습니다. 이는 데이터 유실과 로직 붕괴의 위험성을 동반합니다. 이를 극복하고자 샘플 청크 데이터를 외부의 독립된 chunks.json 파일로 완벽히 격리했습니다. 비동기 네트워크 요청(Fetch API)을 통해 데이터를 실시간 파싱함으로써, 애플리케이션 소스 코드의 안정성을 확보하고 데이터만 무한히 확장할 수 있는 유연한 데이터 레이어를 구축했습니다. 💡 핵심 요약: 코딩을 모르는 비전공자 관점에서도 엑셀 양식 형태의 JSON 파일 내용만 변경하면 메인 시스템의 수정 없이 청크 데이터를 무한히 갈아끼울 수 있는 완벽한 아키텍처 격리가 달성되었습니다. 2. TDD(테스트 주도 개발) 검증 엔진의 설계 원리 안정적인 데이터 로드를 보장하기 위해 브라우저 개발자 도구(Console) 단에서 작동하는 초경량 TDD 검증 파이프라인을 이식했습니다. 검증은 다음 두 단계의 철저한 관문을 거칩니다. 관문 1 (네트워크 수신): 외부의 chunks.json 파일이 유실되거나 주소가 꼬이지 않고 메모리에 안전하게 반환(Fetch)되는가? 관문 2 (데이터 무결성): 긁어온 1번 청크의 데이터 본문 텍스트가 타겟 표현("Forget about it.")과 한 글자의 오차도 없이 완벽히 매칭되는가? TDD의 핵심은 "의도된 실패(Red)" 를 먼저 확인하는 것입니다. 일부러 텍스트 검증부에 오타를 내어 디버거가 검붉은색 경고(Assertion Failed)로 시스템을 정밀하게 가로막아 세우는 브레이크 포인트 기능을 눈으로 확인했습니다. 이후 원문을 올바르게 복구함으로써 시스템 스스로 초...

한국어 (KO) English (EN) 구글 블로거 데이터 스크래핑 아카이브 프로젝트 분석 클라우드 개발 환경(GitHub Codespaces) 내에서 구글 블로거(Blogger/Blogspot)에 축적된 115개의 포스트 데이터를 로컬 디렉터리로 이식하기 위해 총 3가지의 시나리오를 설계하고 검증을 진행했습니다. 구글의 철저한 보안 메커니즘และ 호스트 차단 정책 속에서 각 방식이 직면한 기술적 한계와 최종 성공 경로에 대한 정밀 분석 보고서입니다. 1. 비인증 공개 RSS/Atom 피드 크롤러 방식 실패 (Blocked) 깃허브 오픈소스 리포지토리의 기본 크롤링 메커니즘을 이식하여 세팅했습니다. 인증 없이 블로그 식별자 주소 뒤에 아톰 피드 주소를 덧붙여 간편하게 XML 데이터를 요청하는 방식입니다. 로컬 PC 환경에서는 일시적으로 작동할 수 있으나, 가상 클라우드 인프라(Microsoft Azure/GitHub 데이터 센터) 환경에서 구글 서버로 접근을 찌르는 순간 구글 보안 엔진이 이를 악성 트래픽(DDoS 또는 크롤링 봇)으로 인지했습니다. 그 결과 데이터 반환 대신 일반 로그인 세션 주소인 ://blogger.com 로 강제 리다이렉션을 발생시켜 too many redirects (MaxRetryError) 장벽에 가로막혔습니다. 2. 구글 Cloud Console 공식 API 연동 방식 (OAuth 2.0) 실패 (Scope Mismatch) 구글이 합법적으로 승인하는 규격에 맞추어 Cloud Console에서 프로젝트를 생성하고, 데스크톱 인증 열쇠 파일( client_secret.json )을 발급받아 환경을 구축했습니다. 아이디와 비밀번호 유출 없이 비공개 드래프트 글까지 실시간 원격 동기화할 수 있는 가장 정석적인 루트입니다. 그러나 클라우드 에이전트 터미널 환경 특성상 기존 실습 로그에 남아있던 오염된 세션 환경 변수(...