diff --git "a/06\354\236\245/\354\235\264\354\247\204\355\230\201.md" "b/06\354\236\245/\354\235\264\354\247\204\355\230\201.md"
new file mode 100644
index 0000000..d68c284
--- /dev/null
+++ "b/06\354\236\245/\354\235\264\354\247\204\355\230\201.md"
@@ -0,0 +1,49 @@
+# 6장. 낯선 시스템에 빨리 친숙해지기
+
+## 낯선 코드 미해
+
+해당 레거시 코드에 대한 이해 과정을 나만의 언어로도 해석해봤다.
+(FE의 관점이라고도 볼 수 있다.)
+
+1. 프로젝트 이해 = 결국 프로젝트/서비스/기능이 만들어지게된 배경을 파악한다.
+2. 기존 문서 검토 = ADR과 온보딩 문서를 통해 이전 담당자의 선택 의도를 파악한다.
+3. 아키텍처와 프로젝트 구조 이해 = 프로젝트의 전체 구조를 파악한다. (e.g. 폴더 구조 > FSD, 기능별 등)
+4. 실행 흐름 파악 (애플리케이션 진입점 찾기 = app.tsx)
+5. 데이터에 따른 요청 여정 추적
+6. 외부 의존 관계 파악 (e.g. package.json)
+
+결국 낯선 코드, 레거시 코드를 파악한다는 것은 이전 팀원들의 의도를 파악하는 것과 같다고 생각한다.
+선택 근거, 목적 등을 파악하는 과정이고 그것이 잘못됐다면 고쳐야하고 적절히 수용도 필요하다.
+또한 내가 쓴 코드와 문서도 레거시가 된다. 그 말은 나도 ADR 드 문서화를 잘 해둬야 한다는 것을 의미하기도 한다.
+
+## 점진적인 정신 모델 구축
+
+> 새로운 프로젝트에 합류했을 때 모든 것을 한꺼번에 이해하려고 하는 것은 지나치게 부담스럽고 비효율적이다.
+
+결국 가장 중요한 말이다.
+뭐든 시스템을 파악하기 위해서 큰 범위를 잡아서는 안된다. 애초에 내 머리가 한번에 이해할 수 있는 양이 그리 크지 않기 때문이다.
+
+따라서 복잡한 시스템이 있다면 어떤 기준으로든 분리를 하고 시작하자.
+특히 AI를 활용하면 이 구조 파악이 훨씬 쉬운 것 같다.
+
+## 샘플 프로세스
+
+1. 소스 코드 관리 시스템에서 프로젝트를 복제c10ne한다.
+2. README, 코딩 표준, 아키텍처 등 기타 지원 문서를 검토한다.
+3. 진행하면서 노트（아키텍처, 빌드 명령. 공통 SQL, 업계 표준, 용어 등）를 작성한다. 이 노트
+   는 주저 말고 팀원들과 공유하자.
+4. 빌드 스크립트를 검토한다.
+5. 프로젝트 의존 관계를 검토한다.
+6. 프로젝트 구조（패키지, 네임스페이스, 모듈, 아티팩트 등）를 검토한다.
+7. CI/CD 파이프라인을 검토한다.
+8. 프로젝트 의존 구성요소（빌드 도구. 런타임, 언어）를 설치한다.
+9. IDE에서 다음을 수행한다.
+   - 애플리케이션을실행하고디버깅한다.
+   - 흥미로운 메서드에 중단점을 추가하고 애플리케이션 실행을 추적해 본다.
+   - 단위 테스트를 실행하고 디버깅한다.
+   - 흥미로운 메서드에 중단점을 추가하고 애플리케이션 실행을 추적해 본다.
+10. 명령행에서 다음을수행한다.
+    - 프로젝트 산출물을 빌드한다.
+    - 단위 테스트를 실행한다.
+    - 필요한 컨테이너（데이터 저장소 등）를 시작한다.
+    - 로컬에서 애플리케이션을실행한다（포트, URL 등）.