diff --git "a/06\354\236\245/\354\247\200\353\257\274\354\236\254.md" "b/06\354\236\245/\354\247\200\353\257\274\354\236\254.md"
new file mode 100644
index 0000000..a1f1572
--- /dev/null
+++ "b/06\354\236\245/\354\247\200\353\257\274\354\236\254.md"
@@ -0,0 +1,31 @@
+## 6장 핵심 정리
+
+실무에서는 새로운 프로젝트를 처음부터 만드는 것보다 이미 구축된 코드를 이해하고 수정하는 일이 더 많다. 따라서 낯선 코드를 마주했을 때는 모든 것을 **한 번에 이해하려 하기보다, 프로젝트의 목적과 사용자, 아키텍처, 기존 문서를 먼저 살펴보며 전체적인 맥락을 파악하는 것이 중요**하다. 문서만으로 이해하기 어려운 부분은 실제 코드와 대조하고, 팀원에게 질문하며 필요한 정보를 얻어야 한다.
+
+코드의 동작을 이해할 때는 **애플리케이션의 진입점**을 찾고, 특정 기능이 실행되는 흐름을 따라가 보는 것이 효과적이다. 브라우저 개발자 도구, API 테스트 도구, 로그, 디버거 등을 활용하면 요청과 응답이 어떤 과정을 거치는지, 데이터가 어떻게 변환되는지, 어떤 외부 시스템에 의존하는지 확인할 수 있다. 또한 복잡한 시스템을 하나의 기능이나 실행 경로 단위로 나누고, 다이어그램 등으로 시각화하면서 이해의 범위를 점진적으로 넓혀가는 것이 좋다.
+
+기존 코드를 수정할 때는 **현재 동작을 이해하고 보존하는 것을 우선**해야 한다. 리팩토링 전 **테스트를 추가해 기존 동작을 기록**하고, 변경할 때마다 테스트를 실행하면 예상치 못한 문제를 줄일 수 있다. 여기에 코드를 처음 발견했을 때보다 조금이라도 더 나은 상태로 남겨두는 스카우트 규칙을 적용하되, 모든 코드를 한 번에 개선하려 하기보다는 현재 작업에 필요한 범위에서 점진적으로 개선하는 것이 중요하다.
+
+변경 과정에서는 **작고 되돌릴 수 있는 단위로 작업하고, 각 변경의 목적과 결과를 명확하게 남겨야 한다.(커밋 쪼개기!!)** 의미 있는 커밋 메시지와 짧은 브랜치, 작은 PR, 코드 리뷰 등을 활용하면 변경사항을 이해하고 검토하기 쉬워지며, 문제가 생겼을 때도 원인을 파악하고 되돌리기 수월하다. 결국 낯선 코드를 잘 다룬다는 것은 처음부터 모든 것을 아는 것이 아니라, 필요한 정보를 체계적으로 찾아 시스템을 이해하고, 작은 변경을 검증하며 안전하게 개선해 나가는 능력이다.
+
+## 인상 깊었던 부분
+
+> 기존 코드로 작업하는 데도 장점이 있다. 인프라를 걱정하는 대신 당면한 문제에 집중할 수 있도록 주요한 결정이 이미 많이 내려져 있기 때문이다.
+
+→ 기존 코드를 수정할 때는 이미 정해진 맥락 안에서 작업하기 때문에 오히려 당면한 문제에 집중할 수 있다는 말에 깊이... 공감했다 ㅎㅎ 내가 기존 코드를 수정하면서 어려움을 느끼는 건 대대적인 변경 자체가 무섭다기보다는, 수정하기 전에 전체 흐름을 파악하는 과정이 어렵기 때문인 것 같다. 조금만 고쳤는데도 사이드 이펙트가 발생한다면, 내가 수정한 부분이 시스템의 다른 부분과 어떻게 연결되어 있는지 충분히 이해하지 못했기 때문일 수 있다.
+그래서 이번 장에서 다루는 탐색 방법들이 특히 유익하게 느껴진 것 같다. 아직 경험이 많지 않은 주니어 개발자에게도 꼭 필요한 기술이고, 여러 서비스를 빠르게 이해해야 하는 스타트업 환경에서도 유용하게 활용할 수 있을 것 같다.
+
+> 제품 관리자처럼 제품에 대해 깊이 아는 사람부터 찾아가는 것이 좋다. 이들과 회의를 잡고 배울 준비를 하자. 나중에 참고할 수 있게 최대한 꼼꼼하게 메모한다. 질문이 가장 중요하다. 멍청한 질문이란 없다. 질문하지 않는 것만이 멍청한 일이다.
+
+→ 이 부분을 읽으면서 입사 초기에 PM이나 PO에게 제품에 대해 충분히 질문해 볼 걸 하는 생각이 들었다. ㅜㅜ 우리 회사는 두 가지 플랫폼을 다루는데, 서로 연관되어 있으면서도 별개의 정책을 갖는 경우가 많아 이해하기 어려웠다. 예를 들어 A 플랫폼을 결제하면 B 플랫폼을 무료로 이용할 수 있지만, B만 별도로 결제할 수도 있고 가격이나 월간 및 연간 정책도 다르다. 이런 맥락을 파악하는 데 초반 몇 개월을 사용했던 것 같다.
+돌이켜 보면 혼자 하나씩 알아내려고 하기보다 제품을 잘 아는 PM이나 PO에게 시간을 요청해 전체적인 구조와 정책을 먼저 들었다면 훨씬 빠르게 이해할 수 있었을 것이다.
+
+> 이해관계자들과 이야기를 나눴다면, 다음 단계는 아키텍처 결정 기록(ADR)을 포함해 읽을 수 있는 모든 문서를 샅샅이 살펴보는 것이다. 프로젝트의 큰 그림을 이해하고 나면 이런 문서들이 비로소 의미 있게 다가올 것이다.
+
+→ 나는 프로젝트를 이해하기 위해 문서부터 읽으려고 했는데, 오히려 큰 그림을 모르는 상태에서 문서까지 한 번에 이해하려다 보니 시간이 오래 걸렸던 것 같다. 문서에 적힌 용어나 설계 결정이 어떤 맥락에서 나왔는지 모르면 내용을 읽어도 쉽게 와닿지 않을 수 있다.
+먼저 제품과 시스템이 어떤 구조인지 파악하고, 그다음 문서를 읽으며 구체적인 내용을 채워 나가는 방식도 필요하겠다는 생각이 들었다. 문서를 많이 읽는 것만큼이나 **어떤 순서로 정보를 접하느냐**도 중요하다는 점이 인상 깊었다.
+
+> 애플리케이션 진입점 찾기, 요청과 응답 추적하기, 외부 의존 시스템 위치 파악하기 등을 통해 실행 흐름을 이해하는 기술을 배운다.
+
+→ 이 부분을 읽으면서 크루나 플레이그라운드가 실제로 어떻게 동작하는지 실행 흐름을 따라가 보면서 파악해 보면 좋겠다는 생각이 들었다. 단순히 코드 한 부분만 읽는 것보다 사용자의 행동이 어떤 코드를 거쳐 처리되는지 전체 흐름을 이해하면 코드 리뷰를 할 때도 더 도움이 될 것 같다!! 🧎🏻‍♀️...
+특히 다음 문장이 기억에 남았다. **시스템을 관통하는 요청의 여정을 추적하는 것은 코드의 작동 방식과 관련 시스템을 이해하는 아주 좋은 방법이다!**