"함께 수정되는 파일을 같은 디렉토리에 두기"의 지역성에 대한 내용을 추가하면 어떨까요?

[ssi02014]

함께 수정되는 파일을 같은 디렉토리에 두기 페이지 내용에 캐시의 지역성을 함께 언급하면 해당 페이지에 대한 내용을 조금 더 깊게 이해하는데 도움이 될 것이라고 생각해요.

하지만, 다른 분들에게는 해당 내용이 조금 과하다고 느끼실 수 있을 것 같아 고민이 드네요 ㅎㅎ🤔

아래는 관련 내용을 추가해서 수정한 내용입니다. 말이 조금 이상하거나 개선해야 될 부분이 있다면 말씀해주세요 🤗

## 함께 수정되는 파일을 같은 디렉토리에 두기
프로젝트에서 코드를 작성하다 보면 Hook, 컴포넌트, 유틸리티 함수 등을 여러 파일로 나누어서 관리하게 돼요. 이런 파일들을 쉽게 만들고, 찾고, 삭제할 수 있도록 올바른 디렉토리 구조를 갖추는 것이 중요해요.

함께 수정되는 소스 파일을 하나의 디렉토리에 배치하면 코드의 의존 관계를 명확하게 드러낼 수 있어요. 그래서 참조하면 안 되는 파일을 함부로 참조하는 것을 막고, 연관된 파일들을 한 번에 삭제할 수 있어요.

+ 이러한 디렉토리 구조는 캐시의 지역성과도 밀접한 관련이 있어요. 캐시의 지역성에는 주로 두 가지 원칙이 있습니다. 시간 지역성과 공간 지역성이에요.

+ - 시간 지역성(Temporal Locality)은 특정 데이터나 메모리 주소에 대한 접근이 최근에 발생했을 경우, 가까운 미래에도 다시 접근할 가능성이 높다는 원칙입니다. 예를 들어, 반복문 내에서 같은 변수를 여러 번 사용하는 경우가 이에 해당하죠.
+ - 공간 지역성(Spatial Locality)은 특정 메모리 주소에 접근한 후, 그 주소와 가까운 다른 주소에 접근할 가능성이 높다는 원칙입니다. 예를 들어, 배열의 첫 번째 요소에 접근한 후 두 번째 요소에 접근하는 경우가 이에 해당하죠.

+ 이러한 원칙을 디렉토리 구조에 적용해 본다면, A라는 파일이 변경될 때 가까운 미래에 또 다시 A파일이 또 수정 될 가능성이 높고, 이와 관련된 주변 코드들이 함께 변경될 확률이 높다는 것을 의미해요.
+ 따라서, 함께 수정되는 파일들을 하나의 디렉토리에 배치하면 이러한 지역성을 활용 할 수 있고, 유지 보수도 원활하게 하여 개발자의 경험이 한층 더 좋아질 수 있어요.

[Kimbangg]

@ssi02014 님 꼼꼼하게 리뷰주셔서 감사합니다 🙏
"캐시의 지역성" 과 이를 구성하는 특징 모두 익숙하지 않다보니, 해당 용어와 뜻을 이해하는 과정이 피로도를 올릴 수 있겠다는 걱정이 조금 들어요.
문서를 읽으면서 채웠으면 좋겠다고 느꼈던 점을 공유해주시면, 개선 사항을 함께 고민 해볼 수 있을 것 같습니다.

+) 비슷한 경험이 없는 독자들에게도 "함께 배치하는 것의 장점"을 느낄 수 있도록 부연 설명을 해주셨다는 점에 @ssi02014 님의 따뜻한 마음을 느낄 수 있었습니다. 깊이 고민해보시고, 이를 글로 작성해주셔서 정말 감사드려요.

[ssi02014]

@Kimbangg 답변 감사합니다!

"캐시의 지역성" 과 이를 구성하는 특징 모두 익숙하지 않다보니, 해당 용어와 뜻을 이해하는 과정이 피로도를 올릴 수 있겠다는 걱정이 조금 들어요.

네! @Kimbangg 님께서 말씀해 주신 내용도 공감합니다! 캐시의 지역성에 익숙하지 않은 인원들에게는 해당 개념을 녹여서 "함께 수정되는 파일을 같은 디렉터리에 두기"를 설명한다면 굉장히 피로도를 느낄 수 있다고 생각합니다. 🥲

아래 내용은 단순하게 제가 "함께 수정되는 파일을 같은 디렉터리에 두기"와 "캐시의 지역성"을 연관 지어서 생각했을 때 이해에 도움이 될 내용을 간단하게 남겨봅니다. 해당 내용이 누군가에게는 "함께 수정되는 파일을 같은 디렉터리에 두기"를 더 이해하는 데 도움이 되지 않을까 생각합니다! 😄

---

Comment

저는 캐시의 지역성을 기반으로 폴더 구조를 접근하니 "함께 수정되는 파일을 같은 디렉토리에 두기"를 더 깊게 이해하게 되었습니다.

현대 컴퓨터 시스템과 웹 생태계에 있어서 캐시는 굉장히 중요한 요소중 하나입니다.
적절한 캐시 활용과 높은 캐시 히트 비율은 시스템의 전반적인 성능을 향상시키는데 큰 도움이 되며, 이러한 캐시는 효율적으로 동작하기 위해 캐시의 지역성을 기반으로 설계되고 동작합니다.

캐시의 지역성에는 대표적으로 시간 지역성(Temporal Locality)과 공간 지역성(Spatial Locality)이 있습니다.

• 시간 지역성(Temporal Locality)은 특정 데이터나 메모리 주소에 대한 접근이 최근에 발생했을 경우, 가까운 미래에도 다시 접근할 가능성이 높다는 원칙입니다. 예를 들어, 반복문 내에서 같은 변수를 여러 번 사용하는 경우가 이에 해당합니다.
• 공간 지역성(Spatial Locality)은 특정 메모리 주소에 접근한 후, 그 주소와 가까운 다른 주소에 접근할 가능성이 높다는 원칙입니다. 예를 들어, 배열의 첫 번째 요소에 접근한 후 두 번째 요소에 접근하는 경우가 이에 해당합니다.

이러한 캐시 시스템을 개발자 관점에서 접근해봤을 때, 개발자의 뇌(?)를 하나의 캐시라고 가정해보겠습니다. 캐시에 모든 데이터를 담을 수 없듯이, 개발자도 거대한 프로젝트 구조와 맥락을 한번에 파악하기란 굉장히 어렵습니다. 그러나 특정 영역 혹은 폴더 맥락에 집중한다면, 해당 영역에 대한 추가/수정과 같은 처리를 빠르게 할 수 있습니다. (이는 마치 캐시 히트🎯가 발생하는 것과 유사합니다!)

프로젝트를 진행하면서 A라는 특정 기능 혹은 파일이 변경 됐을 때를 생각해보겠습니다.

특정 기능 A를 수정 후에는 우리는 해당 A를 가까운 미래에 다시 변경 할 확률이 높습니다. 예를 들어, 버그 수정, 기능 개선, 코드 리뷰를 통해 다시 A를 수정해야 될 수 있습니다. 이는 캐시의 시간 지역성과 연관 지어 생각해 볼 수 있습니다.

또한, 특정 기능 A가 수정 될 때, 관련된 주변 코드들이 함께 변경 될 확률이 높습니다. 예를 들어, A와 관련된 component, hook, util, test, style 코드 등이 있습니다. 이는 캐시의 공간 지역성과 연관 지어 생각 해 볼 수 있습니다.

이러한 특성을 생각했을 때 함께 수정되는 파일들을 동일한 디렉토리에 위치시키면, 개발자는 더 효율적으로 작업할 수 있습니다. 이는 높은 개발자 캐시 히트율로 이어집니다. 반면, 지역성을 고려하지 않고 폴더 구조를 갖게 된다면, 개발자는 프로젝트 내 여러 폴더를 탐색하며 프로젝트 맥락을 파악해야 하므로 많은 인지적 리소스가 소모(개발자 캐시 미스!😫)될 수 있습니다. 이는 프로젝트 규모가 커질수록 더욱 심화됩니다.

현대 컴퓨터 시스템과 웹 생태계에서 높은 캐시 히트율이 성능 향상으로 이어지듯이, 개발 과정에서도 이러한 개발자 캐시 히트율이 높으면 개발 생산성과 유지보수성이 크게 향상됩니다. 결과적으로 더 나은 개발자 경험(DX)을 제공할 수 있습니다.

---

#104
위 내용을 코멘트로 추가했습니다 🙏