[조혜린] 6장 - 낯선 시스템에 빨리 친숙해지기

06장/조혜린.md

@@ -0,0 +1,31 @@
+## 6장. 낯선 시스템에 빨리 친숙해지기
+
+### 1. 낯선 코드 이해
+
+새로운 프로젝트에 투입되었을 때는 코드를 분석하기에 앞서 서비스의 목적과 주요 기능, 전체적인 아키텍처를 먼저 파악해야 함. README, 설계 문서 등을 통해 프로젝트의 구조를 이해하고, 이후 실제 실행 흐름을 따라가며 각 구성요소의 역할과 의존 관계를 파악하는 것이 중요함.
+
+실제 회사에서 프로젝트에 투입되었을 때도 서비스가 어떤 서비스인지, 전체적으로 어떤 구조를 가지고 있는지까지는 파악했었다. 하지만 본격적으로 코드를 분석하는 과정에서는 어려움이 많았다. 하나의 페이지에도 여러 컴포넌트가 존재하고, 그 컴포넌트 내부에 또 다른 컴포넌트들이 중첩되어 있다 보니 어디서부터 살펴봐야 할지 막막했던 기억이 있다. 전체 구조를 이해하는 것과 실제 코드를 이해하는 것은 또 다른 문제라는 걸 느꼈다.
+
+### 2. 점진적인 정신 모델 구축
+
+처음부터 시스템 전체를 이해하려 하기보다 작은 기능부터 분석하며 점진적으로 이해 범위를 확장해야 함. 하나의 기능이 어떤 흐름으로 동작하는지 파악하고, 관련된 구성요소와 의존 관계를 따라가며 시스템에 대한 이해를 넓혀가는 방식. 필요하다면 순서도나 순차 다이어그램 등을 활용해 복잡한 구조를 시각화할 수 있음.
+
+이 부분이 특히 인상 깊었다. 당시에는 하나의 페이지에 들어가면 그 페이지와 관련된 코드를 전부 이해해야 할 것처럼 느껴졌고, 그러다 보니 분석을 시작하기도 전에 막막함이 앞섰던 것 같다. 그때 작은 기능부터 점진적으로 이해하자는 기준이 있었다면 조금은 덜 혼란스럽지 않았을까 싶다.
+
+다만 무조건 작은 기능부터 분석하는 것이 정답은 아니라고 생각한다. 개별 기능에만 집중하다 보면 오히려 전체적인 맥락이나 기능 간 연결 관계를 놓칠 수도 있기 때문이다. 결국 전체 구조를 먼저 이해하되, 실제 코드 분석은 작은 단위부터 시작하고 필요에 따라 범위를 넓혀가는 균형이 중요하다고 느꼈다.
+
+### 3. 안전한 리팩터링
+
+리팩터링은 기존 동작을 유지하면서 코드의 내부 구조를 개선하는 작업. 변경하기 전에 기존 동작을 검증할 수 있는 테스트를 작성하고, 리팩터링 이후에도 동일하게 동작하는지 확인해야 함.
+
+또한 스카우트 규칙에 따라 코드를 처음 발견했을 때보다 조금 더 나은 상태로 남기는 것을 지향하되, 변경의 필요성과 영향 범위를 고려해야 함. 모든 코드를 무조건 개선하는 것이 아니라 상황에 따라 리팩터링을 미루는 것도 합리적인 선택.
+
+이번 장에서도 테스트의 중요성이 반복해서 등장하는 것을 보며 저자가 테스트를 정말 중요하게 생각한다는 것을 느꼈다. 앞선 장에서도 테스트에 대한 내용을 여러 차례 접했는데, 기존 코드를 이해하고 수정하는 과정에서도 테스트가 중요한 역할을 한다는 점이 인상적이었다. 책을 읽을수록 테스트는 단순히 코드가 정상적으로 동작하는지 확인하는 수단이 아니라, 기존 코드를 자신 있게 변경할 수 있도록 도와주는 기반이라는 생각이 든다. 그만큼 프로젝트에 테스트를 도입하고 유지하는 것이 중요하다고 생각하게 되는 것 같다.
+
+### 4. 되돌릴 수 있는 작은 변경
+
+코드 변경은 가능한 한 작고 독립적으로 검증할 수 있는 단위로 나누어 진행해야 함. 변경의 목적과 영향 범위를 명확히 하고, 테스트와 버전 관리를 통해 문제가 발생했을 때 원인을 추적하고 이전 상태로 되돌릴 수 있도록 관리해야 함. PR과 코드 리뷰 역시 변경 의도와 검증 결과를 공유하는 과정으로 활용.
+
+이 부분에 공감했다. 한 번에 많은 부분을 개선하려고 변경 범위를 크게 가져가면 당장은 효율적이라고 생각할 수 있지만, 예상하지 못한 문제가 발생했을 때 오히려 더 많은 리소스가 필요해질 수 있다. 특히 여러 변경이 한꺼번에 이루어지면 어느 부분에서 문제가 발생했는지 파악하기도 어려워진다.
+
+결국 좋은 코드를 만드는 것만큼이나 그 코드를 얼마나 안전하게 변경할 수 있는지도 중요하다고 생각한다. 리팩터링의 규모가 크다고 반드시 더 좋은 개선이 되는 것은 아니며, 작은 단위로 수정하고 검증하는 과정이 장기적으로는 더 효율적일 수 있다는 점을 다시 한번 느꼈다.