diff --git "a/05\354\236\245/\354\236\245\354\240\225\355\233\210.md" "b/05\354\236\245/\354\236\245\354\240\225\355\233\210.md"
new file mode 100644
index 0000000..d77cb11
--- /dev/null
+++ "b/05\354\236\245/\354\236\245\354\240\225\355\233\210.md"
@@ -0,0 +1,53 @@
+# 05장 자동 테스트: 좋은 소프트웨어를 만드는 최고의 습관
+
+2장에서 AI가 짜준 코드를 어떻게 믿을 수 있을까에 대해 생각했었다.
+
+코드를 읽고 이해하는 능력도 필요하지만 이번 장을 읽으면서 이해했다고 생각한 코드가 실제로 그렇게 동작하는지 확인하는 과정도 필요할것 같다.
+
+이 장에서는 자동 테스트를 문서이자 리팩터링의 안전망이라고 설명한다. 테스트를 작성하는 이유를 단순히 버그를 찾는것으로만 생각하면 놓치는 부분이 있는것 같다.
+<br /><br />
+
+## 테스트도 문서가 될 수 있다.
+
+3장에서 주석은 `무엇을` 했는지보다 `왜` 했는지에 집중해야 한다고 정리했었다.
+
+그렇다면 이 코드가 무엇을 하는지 어떤 상황에서 실패해야 하는지는 어디에 남길 수 있을까. 책에서는 잘 작성된 테스트가 그 역할을 할 수 있다고 설명한다.
+
+예를 들어 회원가입 기능을 이해해야 한다면 `이미 사용 중인 이메일로는 가입할 수 없다`라는 테스트만으로도 하나의 비즈니스 규칙을 알 수 있다. 함수 안의 코드를 전부 읽기 전에도 어떤 동작을 기대해야 하는지 파악할 수 있는것이다.
+
+물론 테스트 이름만 잘 적는다고 문서가 되는것은 아닐것 같다. 이름에 적힌 동작을 실제로 검증하고 있어야 한다. 테스트가 통과하는지와 함께 무엇을 검증하는지도 읽어봐야겠다.
+<br /><br />
+
+## 테스트하기 어렵다면 코드의 책임도 의심해보자.
+
+책에서는 게시글을 저장하고, 로그를 남기고, 이메일까지 보내는 메서드를 예시로 설명한다. 돌아가는 코드만 보면 문제를 못 느낄 수 있지만 테스트를 작성하려는 순간 너무 많은 일을 하고 있다는것을 알게 된다.
+
+3장에서 useEffect의 이름을 지을 때 `And`, `Also`가 필요하다면 책임이 너무 많은지 의심해보자는 내용을 적었었다. 테스트도 비슷한 역할을 할 수 있을것 같다.
+<br /><br />
+
+## 모든 테스트를 같은 방식으로 작성할 필요는 없다.
+
+책에서는 자동 테스트를 크게 세 가지로 나눈다.
+
+- 단위 테스트: 개별 함수나 구성요소를 격리해서 검증한다.
+- 통합 테스트: 여러 구성요소가 연결되었을 때의 동작을 검증한다.
+- E2E 테스트: 사용자 진입점부터 시스템 전반을 거치는 흐름을 검증한다.
+
+테스트 피라미드의 위로 갈수록 실행이 느려지고 유지보수 비용도 커진다. 그렇다고 단위 테스트만으로 모든것을 확인할 수도 없다. 각각은 맞게 동작해도 연결되는 과정에서 문제가 생길 수 있기 때문이다.
+
+프론트엔드에 적용한다면 입력값을 검증하는 함수는 단위 테스트로 입력과 제출 과정의 연결은 통합 테스트로 확인할 수 있을것 같다. 실제 사용자가 주요 기능을 끝까지 사용할 수 있는지는 E2E 테스트로 확인하고.
+
+중요한건 비율을 무조건 맞추는것보다 어떤 위험을 어느 단계에서 확인할지 정하는것 같다. 프레임워크 자체나 비공개 메서드의 구현보다 내가 작성한 코드가 외부에 약속한 동작에 집중해야겠다.
+<br /><br />
+
+## 커버리지보다 무엇을 검증했는가
+
+책에서는 함수를 호출하기만 해도 실행률에는 반영되지만 유용한 결과를 확인하지 않으면 실질적인 보호를 제공하지 못한다고 설명한다.
+
+이 부분이 AI와도 연결된다고 생각했다. AI에게 구현과 테스트를 전부 맡긴 뒤 모두 통과했다는 이유만으로 믿어도 될까?
+
+AI가 요구사항을 잘못 이해했다면 구현과 테스트가 같은 오해를 공유할 수도 있을것 같다. 기존 코드의 결과를 그대로 기댓값에 넣어버린다면 잘못된 동작도 맞는 동작으로 굳어질 수 있고.
+
+따라서 AI에게 테스트 작성을 맡기더라도 성공 조건과 실패 조건, 경곗값은 내가 요구사항을 기준으로 확인해야 한다. AI는 놓친 케이스를 제안하는 데 도움을 줄 수 있지만 무엇이 옳은 결과인지 판단하는 책임까지 넘길 수는 없다고 생각한다.
+
+당장 프로젝트 전체에 테스트를 붙이려고 하기보다 다음에 버그를 수정할 때 그 버그를 재현하는 실패하는 테스트 하나부터 작성해보고 싶다. 수정 후에는 통과하고 나중에 같은 문제가 생기면 다시 알려주는 테스트. 그런 테스트가 쌓이면 기존 코드를 바꾸는 데에도 더 자신감이 생길것 같다.