요약 우테코 미션을 수행하면서 기억하고 싶은 부분들을 정리합니다.

목차

• 레벨2 - 미션 1단계
  • 레벨2의 시작
  • 간단한 회고
  • 공부내용
    • 📌 Q1 ) CSS 스타일을 사용한 이유는?
    • 📌 Q2 ) propsDrilling은 불편해!
  • 이번주 키워드
    • 🔑 K1 ) 도메인 중심 폴더구조
    • 🔑 K2 ) 전문용어를 바탕으로 먼저 설명하기

레벨2 - 미션 1단계

레벨2의 시작

이전 기억을 되살려서 다시 적으려니까 여간 힘든게 아니다 ㅋㅋㅋㅋ

간단히 기억나는 것만 적어보자면 .. 아

머리를 굉장히 길게 길렀었는데, 거의 5-6년만에 매우매우 짧게 머리를 잘랐다.

이유를 들어보자면, 무슨 일이 있었던건 아니고 우테코 기간 동안에 머리를 풀고 있을 이유도 없었고 (화장안함 .. 힘듦.. )

계속해서 묶고있음 + 슬슬 더워짐 이슈로 .. 그리고 조금은 질리기도 했던 것 같다. 간단히 말해서 그냥 단발병이 왔다! ㅋㅋㅋㅋㅋㅋ

한순간에 짧아진 내 머리를 보고 놀라던 사람들의 모습이 훤하다 .. ㅎㅎ 하지만 난 단발이 좋아졌다. 시원하고, 기분 전환에도 매우 좋았다.

간단한 회고

레벨 2의 간단한 회고라면 .. 음

머핀, 헤일리, 퐁쥬, 피터. 이 네사람이 내 레벨 2의 전부가 아닐까

피터네 유강스를 포함해서 난 이들에게서 너무나도 많은 것을 배웠고, 모든 것을 함께했고, 우테코가 끝나더라도 계속해서 만나고 싶은 사람임엔 틀림없다.

레벨1과 비교해서 보자면 레벨2에서 확실히 경험한것도, 배운것도 더 많은 것 같다. 지침의 정도만 보자면 레벨1이 더 힘들었어. 새로운 환경 적응이 안돼서 ㅠㅠ

하지만 레벨 2에서는 사람들이랑 정말 많이 친해져서 고민도 털어놓고, 함께 놀러다니기도 하면서 정말 많이 회복되었던 것 같다.

공부내용

📌 Q1 ) CSS 스타일을 사용한 이유는?

📌 Q2 ) propsDrilling은 불편해!

📌 Q1 ) CSS 스타일을 사용한 이유는?

사용해보며 느낀 점

기술적인 근거

📌 Q2 ) propsDrilling은 불편해!

☑️ propsDrilling이란?

문자 그대로 해석하면 “props를 여러 컴포넌트를 거쳐 전달하는 것”을 의미한다.

즉, 어떤 데이터를 하위 컴포넌트까지 전달하려고 할 때, 그 중간 단계의 컴포넌트들이 직접 그 데이터를 사용하지 않음에도 불구하고 props를 통해 해당 데이터를 계속 전달해야 하는 상황이다.

☑️ propsDrilling이 발생하는 이유

React는 단방향 데이터 흐름(one-way data flow)을 따르기 때문에,

상위 컴포넌트가 가진 상태나 데이터를 하위 컴포넌트로 넘기려면 props를 통해 전달해야 한다.

☑️ propsDrilling의 문제점

• 중간 컴포넌트가 불필요하게 props에 의존하게 된다.
• 컴포넌트 간의 결합도가 높아져 리팩토링이 어려워진다.
• 재사용성과 가독성이 떨어지며, 유지보수가 어려워진다.

☑️ propsDrilling 해결방법

• Context API

  전역적인 상태 공유를 통해 중간 단계 컴포넌트를 거치지 않고도 필요한 곳에서 데이터를 바로 사용할 수 있게 한다.

• 컴포지션 패턴

  children이나 custom hooks 등을 이용해 구조를 단순화하거나, 데이터 전달 방식 자체를 재설계한다.

  단, children은 상태 전달을 직접적으로 해결해주지는 않는다. 일종의 눈속임!

☑️ propsDrilling에 대한 오해

하지만 propsDrilling이 무조건 나쁜 것만은 아니다.

명시적으로 데이터가 어떤 경로를 통해 흐르는지를 보여줌으로써,컴포넌트 간의 의존성, 위계관계, 데이터 흐름을 명확하게 나타내는 장점도 있다.

• ContextAPI의 단점

  Context의 value가 변경되면 하위의 모든 Consumer 컴포넌트가 리렌더링되기 때문에 성능 이슈로 이어질 수 있다.

  • 상태가 어디서 사용되고, 어디서 변경되는지 추적이 어려워질 수 있다.

  • 코드 상에서 어떤 컴포넌트가 어떤 데이터를 사용하는지 명확하지 않아, 예상치 못한 변경이 일어날 수 있다.

또한, propsDrilling을 피하려고 무리하게 컴포넌트 구조를 children 중심으로 바꾸면, 오히려 컴포넌트의 캡슐화가 깨지거나, 구조가 더 복잡해지는 역효과가 날 수 있다

✔️ A2 ) 결론

propsDrilling이 발생했다면, 무조건 피하려 하지 말고 먼저 상태의 위치와 흐름을 점검해보자.

이는 종종 “상태가 잘못된 위치에 있거나, 공유 방식이 비효율적이라는 신호”일 수 있다.

이번주 키워드

🔑 K1 ) 도메인 중심 폴더구조

🔑 K2 ) 전문용어를 바탕으로 먼저 설명하기

🔑 K1 ) 도메인 중심 폴더구조

3번째 상품 목록 미션에서 느꼈던 불편함을 해소한 사례이다.

step1에서 기능 중심의 폴더구조를 계속 유지하다 보니 점점 불편함을 느꼈던 것 같다.

가장 크게 느꼈던 문제는 관심사 분리가 제대로 되어 있지 않다는 점이였는데, 하나의 컴포넌트와 관련된 로직들이 여기저기 흩어져 있어서

결합도는 높고 응집도는 낮은 구조로 코드를 작성하고 있다는 생각이 들었다.

아래 이미지에서 왼쪽 이미지는 step1에서 사용해오던 기능 중심 구조이다. page에서 사용하는 컴포넌트나 함수들이 흩어져 있어서 참조 흐름이 복잡하게 느껴졌다.

이전에 유지하던 폴더구조에 불편함을 느껴 토스의 폴더구조를 참고해 도메인 중심 구조를 적용해 보았다.

위와 같이 도메인 중심 폴더구조를 가져갔을 때의 장점은,

특정 기능을 제거할 때 해당 디렉토리만 삭제하면 관련 코드가 모두 정리되는 구조라는 것이다. 기능이 복잡해질수록 도메인 중심 구조가 훨씬 구분이 쉬워질 것 같다는 생각이 들었다.

도메인 중심 폴더구조를 도입해보면서 느꼈던 편리한 점은 아래와 같다.

• 관련된 기능들끼리 모여있어서 시선이 분산되지 않는다.
• 응집도가 이전보다 훨씬 높아졌다는 느낌을 받았다.
• 만약 수정이 필요하다면 관련 도메인 페이지 안에서만 수정 및 변경이 이뤄진다.

🔑 K2 ) 전문용어를 바탕으로 먼저 설명하기

미션을 하다보면 어딘가 늘 답답함을 느끼곤 했다.

궁금한것도 많고, 알고싶은것도 많은데, 그런 부분들을 충분히 해소하고 넘어가지 못하니까 생기는 문제였던 것 같다.

예를 들어, 이런 고민들이 있었다.

• 커스텀 훅을 만들 때, 어디까지 기능을 나눠서 분리해야 할까?
• 같은 도메인을 다룬다면 하나의 커스텀 훅으로 묶는게 좋은걸까?
• API별로 파일을 분리하는게 나을까, 아니면 같은 도메인의 CRUD를 가진다면 하나의 파일에서 함수만 분리하는게 좋은걸까?

시지프를 통해 알게 된 점을 공유하자면,

“캉골은 고민 지점도 좋고, 아이디어도 좋은데 계속 발산하고 있어요. 혼자서 구조화하고 수렴시키는 연습을 더 해보아요. 그게 캉골의 발전에 많이 도움이 될거에요.

이번 돌아보기 활동처럼, 문제 하나를 구조적으로 분석해서 해결하는 경험 같은 것이 도움이 될거에요.”

그동안 내게 필요했던 것은 발산된 고민과 아이디어를 하나의 명확한 지점으로 수렴시키는 것이였다.

그리고 그 고민의 핵심을 전문용어로 표현할 수 있게 좁히는 과정이 필요했다.

아까 들었던 고민들을 예로 들어보자면, 이들은 결국 응집도와 단일 책임 원칙(SRP)라는 키워드로 정리할 수 있다.

• 연관된 로직들이 얼마나 긴밀하게 연결되어 있나?
• 이 로직은 이 함수(훅)이 책임져야 하는 범위인가?

라는 질문으로 다시 돌아오게 되는 것이다.

이처럼 여러 생각이 흩어지기만 하고 하나로 뭉쳐지지 못했던 이유는, 내가 그 중심을 잡아줄 키워드를 잘 정리하지 못했기 때문이었던 것 같다.

앞으로는 이런 고민들을 하나의 개념이나 원칙으로 수렴시키는 연습이 나에게 많이 필요할 것 같다.