diff --git "a/08\354\236\245/\354\236\245\354\240\225\355\233\210.md" "b/08\354\236\245/\354\236\245\354\240\225\355\233\210.md"
new file mode 100644
index 0000000..f19c959
--- /dev/null
+++ "b/08\354\236\245/\354\236\245\354\240\225\355\233\210.md"
@@ -0,0 +1,48 @@
+# 08장 다양한 데이터 기술을 적절하게 사용하는 방법
+
+프론트엔드 개발자에게 데이터란 어디까지일까.
+
+API 응답을 받아 화면에 보여주는 과정만 생각하면 데이터베이스나 트랜잭션은 멀게 느껴질 수 있다. 하지만 화면에 보여줄 값이 어떤 형식으로 전달되는지, 언제 최신 상태가 되는지, 데이터가 많아지면 어떤 문제가 생기는지는 사용자 경험과 바로 연결된다.
+
+이 장은 데이터 형식과 저장 방식부터 조회 성능, 캐시, 데이터 이전까지 다룬다. 모든 기술을 다 쓰는것보다 현재 요구사항에 맞는 선택을 해야 한다는 내용이 가장 크게 남았다.
+<br /><br />
+
+## 익숙한 형식이라고 쉽게 생각하지 말자
+
+책에서는 정해진 스키마와 관계를 가진 정형 데이터와 이미지, 문서 같은 비정형 데이터를 구분하고, JSON, XML, CSV, YAML의 특징을 설명한다.
+
+API에는 JSON, 사람이 편집하는 설정에는 YAML, 표 형태의 데이터 내보내기에는 CSV처럼 목적에 따라 적절한 형식이 다르다. 자주 사용하는 형식이라고 모든 상황에 맞는것은 아니다.
+
+특히 JSON에는 날짜를 위한 별도 자료형이 없다는 부분이 눈에 들어왔다. 날짜처럼 보이는 문자열을 받았다고 해서 그 의미까지 명확해지는것은 아니다. 어느 시간대를 기준으로 하는지, 특정 순간인지 아니면 생년월일처럼 날짜 자체가 중요한 값인지도 구분해야 할것 같다.
+
+책에서는 UTC 저장과 화면에서의 현지 시간 변환, ISO 8601 형식 사용을 권한다. 이때도 모든 날짜를 무조건 같은 방식으로 바꾸기보다 해당 데이터의 의미부터 확인해야겠다고 생각했다. 생년월일과 게시글 작성 시각은 같은 문제가 아니기 때문이다.
+
+CSV도 단순히 쉼표로 나누면 끝나는 형식은 아니다. 값 안에 쉼표나 따옴표, 줄바꿈이 들어갈 수 있다. 익숙하고 간단해 보이는 데이터일수록 경계 조건을 놓치지 않아야겠다.
+<br /><br />
+
+## 기술 이름보다 데이터에 어떤 질문을 할지부터
+
+책에서는 데이터베이스를 선택할 때 데이터 구조, 읽기와 쓰기 패턴, 질의의 복잡성, 확장성과 일관성 요구사항을 고려하라고 설명한다.
+
+- 관계형 데이터베이스: 명확한 관계와 복잡한 조회, 트랜잭션이 중요한 경우
+- 문서 데이터베이스: 문서마다 구조가 다르거나 데이터 구조가 자주 달라지는 경우
+- 키-값 저장소: 키를 통한 단순하고 빠른 접근이 필요한 경우
+- 그래프 데이터베이스: 데이터 간의 연결과 경로 탐색이 중요한 경우
+- 벡터 데이터베이스: 임베딩을 이용한 유사도 검색이 필요한 경우
+
+종류를 외우는것보다 `우리는 이 데이터로 무엇을 해야 하지?`부터 물어야 하는것 같다. AI 기능을 만든다고 무조건 벡터 데이터베이스가 필요한것도 아니고 익숙하다는 이유만으로 모든 데이터를 같은 방식으로 다룰 수도 없다.
+
+데이터에 접근하는 방식도 마찬가지다. 책에서는 직접 SQL을 사용하는 방법, 저장소 패턴, ORM을 설명하면서 추상화 수준이 높다고 항상 더 좋은것은 아니라고 한다. 개발 속도뿐 아니라 팀이 이해하고 유지보수할 수 있는지, 실제로 어떤 조회가 실행되는지도 봐야 한다.
+
+여러 변경을 하나의 작업으로 다뤄야 하는 경우에는 트랜잭션의 경계도 중요하다. 책의 송금 예시처럼 출금과 입금 중 하나만 성공해서는 안 되는 작업이 있기 때문이다. 화면에서 성공 메시지를 보여주는 기준 역시 실제로 무엇이 완료된것인지와 맞아야 할것 같다.
+<br /><br />
+
+## 코드는 바꿔도 사용자의 데이터는 남아야 한다.
+
+책에서는 데이터 이전을 단순한 복사가 아니라 계획과 변환, 검증이 필요한 작업으로 설명한다. ETL은 데이터를 추출하고, 대상 형식으로 변환하고, 적재하는 과정이다. 각 단계에서 무엇이 실패했는지 알 수 있어야 하고, 작은 샘플부터 결과를 확인해야 한다.
+
+또한 데이터베이스 스키마의 변경 이력도 코드처럼 관리해야 한다. 필드를 바꾸는것은 새 코드의 타입을 바꾸는 일로 끝나지 않고, 이미 저장된 데이터와 기존 버전이 그 변경을 어떻게 받아들일지도 고려해야 하는것이다.
+
+6장의 작고 되돌릴 수 있는 변경과도 연결되는것 같다. 다만 데이터는 코드를 이전 버전으로 되돌린다고 자동으로 복구되는것이 아니니, 이전 데이터를 어떻게 보존하고 실패하면 어떻게 복구할지도 함께 고민해야겠다.
+
+결국 8장도 기술을 많이 아는것에서 끝나지 않고 `왜 지금 이 선택이 필요한가`를 묻는 내용이라고 생각한다. 아직 일어나지 않은 대규모 트래픽을 상상하며 복잡하게 만들기보다 현재의 데이터와 요구사항을 이해하고 실제 지표를 보면서 바꿔가는 개발자가 되고 싶다.