다이엔이 그려준 나... ㅋㅋㅋ 운동 좋아한다고 했더니 근육몬으로 그려줬다. 💪
근데 나보다 크론을 더 닮은 것 같다 😂
.
.
.
방학이 끝나고 첫 주이다! 화이팅하자 😊
똑똑하게 학습하기
유튜브 알고리즘에 의해 '똑똑하게 학습하는 방법' 영상을 봤다. 내용을 간단하게 말하자면,
이해가 안되는 내용이 있을 때, 떠올리기 연습을 해야 한다. 예를 들면, 설명하기, 마인드 맵 그려보기, 백지에 적어보기, 퀴즈 풀어보기 등이 있다. 분명, 머리가 아플 것이다. 하지만 이렇게 했을 때 학습한 내용이 장기적으로는 기억에 더 잘 남는다고 한다.
이해가 안된다고 계속해서 강의 영상만 다시 보게 되면, 단기적으로는 잘 이해할 수 있지만, 장기적으로는 금방 잊는다고 한다
이해가 정말 하나도 안되면 영상을 보는 게 맞는데,
어느 정도 이해가 됐다면, 떠올리기 연습을 하고 추론하는 연습을 통해서
머리를 많이 써서 학습하는 게 맞는 것 같다. React 공식문서 읽으면서 의식적으로 해봐야겠다.
OOP 관점과 FP 관점 그리고 React 그리고 멀티 패러다임
우연히 링크드인을 보다가 이동욱님이 올리신 글을 봤다. OOP 관점과 FP 관점에서의 경험을 얘기해주시고, 더 나아가 이를 융합하는 멀티 패러다임에 대해 얘기해주셨다.
이 글이 공감이 갔는데,
레벨 1에서 OOP 관점에서 상태관리를 설계를 하다가 레벨 2에서 React를 사용하며 useState를 쓰니 이전만큼 OOP 관점에서 설계할 거리가 줄게 되었고, 오히려 함수 하나하나에 신경쓰며 FP 관점에 프로그래밍하게 되어 레벨 1 관점을 완전히 이어가지 못하는 것에 대한 아쉬움이 있었기 때문이다. (물론 OOP 관점에서의 역할, 책임, 협력의 본질은 SOLID 원칙과 결합시켜, 여전히 지키려고 노력하고 있지만... 이전만큼 잘 되지는 않았다. 경험부족 역량부족도 맞다.)
그러면서 이상한 고민을 하게 된다. 나름 합리적이라고 생각하기도 했는데,
React를 사용하며 상태관리를 useState로 하지 않는 것이다.
상태관리를 레벨 1처럼 도메인을 React 외부에 따로 두면, React는 View만 담당하게 되어 관심사의 분리도 자연스럽게 된다고 생각했다. 그리고 조금 찾아보니 useSyncExternalStore라는 훅이 있어서 아주 간단하게 할 수 있었다.
그럼에도 시도하지 못했는데,
다들 좋은 방법은 아닌 것 같다고 했기 때문이다. useState도 제대로 다루지 못하면서 이후에 등장한 useSyncExternalStore를 하는 훅을 공부하는 것은 무리한 생각이라는 의견과 대부분의 사람들이 useState를 선택한 이유가 있을 것이니 그것을 따라야 한다는 의견이 많았다.
반란군이 되어 시도해볼 수도 있지만, 고민을 했다.
우테코 미션의 본질에서 벗어난 시도는 아닌가에 대해서 진지하게 고민을 했다.
이런 결론은 내렸다. 지금 당장 '저수준'의 도전은 하지는 말자. 사실 객관적으로 생각해보면, useSyncExternalStore를 사용해서 Store를 만드는 것은 저수준의 도전이다. jsx 만들기나 TanStack Query 만들기와 비슷한 도전이다. 당장 내가 미션을 하는데 도움이 될 시도는 아니었다.
그래서 미션이 끝나고 나면 도전해보기로 우선순위를 미뤘다. 현재는 미션에 집중하기로 했다.
그리고 지금은 왜 useSyncExternalStore를 추천하지 않는 지에 대해 간단하게 고민해보기로 했다.
고민을 정리하면 이랬다.
- 왜 상태를 React 외부에서 관리하지 않을까?
- React는 View만 담당하도록 해서 관심사의 분리를 철저하게 할 수 있을텐데?
- useState 같은 훅을 사용하는 것보다 상태와 관련된 행위를 묶어서 좀 더 응집도 높게 관리할 수 있을텐데?
결론은
- React 외부에서 레벨 1처럼 상태를 관리할만큼 상태 관리할 사이즈가 크지 않다.
- useState 같은 훅을 쓰면 편리하게 대부분 처리되기 때문에 굳이 할 필요가 없다.
- 프론트엔드 개발자들이 생각보다 OOP 설계를 낯설어하고 어려워한다.
나는 헌업에 있는 사람이 아니니까 '사이즈'라는 말은 공감이 잘 안됐다.
하지만 확실히 useState를 쓰면 굉장히 상태 관리 신경쓸 부분이 줄기 때문에 굳이 React 외부로 상태를 뺄 필요는 없긴 한다.
그리고 원래 React가 클래스형 컴포넌트일 때, 컴포넌트 내부에서 상태를 관리하다가 그 부분이 hook으로 빠지게 되면서 useState가 등장한거라 여전히 컴포넌트 내부에서 관리하는 부분도 이해는 간다.
그래서 다시 동욱님의 글로 돌아가면, 이렇게 말씀하신다.
OOP는 복잡한 문제를 구조적으로 잘 쪼개어 해결하기 편하지만, 간단한 문제마저도 불 필요하게 복잡해지게 만들었다. 반면, FP는 상태나 부수효과를 최소해서 문제를 간단하게 해결하지만, 시스템의 요구사항이 복잡하여 상태 변화가 여러 객체/모듈에 걸쳐 발생한다면 복잡성을 오히려 제어하기가 어려웠다. (중략)
객체로는 모든 문제를 풀 수 있지만, 문제를 단순화 시켜주고, 더 쉽게 풀어주지 못할 때가 있다. (중략)
그래서 어떤 문제를 만났을 때 여러 형태로 풀어보는 경험이 대단히 중요하다. 그래야 적절한 도구를 선택할 수 있다.
매우 공감이 가는 부분이다. 나도 여러 관점으로 문제를 해결해봐야겠다. 융합해서도.
동욱님은 마지막으로 OOP와 FP 양 쪽 모두를 다루면서 어떤 것을 지향하고 어떤 점이 다른지에 대해 공부하는 컨텐츠로 유인동님의 '멀티 패러다임' 책을 추천하셨다. 최근에 발행되었던데 한번 읽어봐야겠다.
크론과 원오원
나는 가끔 상대가 상처받는 말을 해도 '허허' 하고 넘길 때가 있다.
특히 여러 사람이 있는 회식 자리에서 무례한 발언을 하는 사람에게 그렇다.
상황이 어색해지는 게 싫어서, 화내는 방법을 잘 몰라서 웃어버리는 것 같다.
이에 크론은 '상대방에 말에 반응해서 마침표 찍기'라는 금쪽처방을 해줬다.
상처받는 말을 들으면 자기 방어를 통해서 혼자서 상처를 끌어안지 않고 그 상황에서 마침표를 찍는 것이다.
최근에 본 대도시의 사랑법이라는 영화에서 비슷한 사례를 봤다.
회식 자리에서 김고은이 상사의 무례한 발언을 받았다. 이때 김고은은 바로 자기 방어 발언을 한다.
상사는 '너 되게 예민하다' 라던가 '사소한 거에 목숨걸지마' 라고 하며 오히려 상대를 몰아간다.
그러면 김고은은 분위기 신경쓰지 않고 할 말을 한다.
대단하다고 생각했다.
분위기 곱창내는 건 너무 싫지만,
정말로 무례하다면 솔직하게 받아치는 것도 방법인 것 같다.
물론 화를 내고 싶진 않다. 감정을 제어할 수 없다는 건 지는 거니까.
그냥 솔직하고 예의있게 받아치고 싶다. 너무 어렵지만 계속 연습해봐야 하는 과제같다.
좋았던 경험의 페어프로그래밍
이번 페어는 '다이엔'과 함께 했다. 정말 좋은 경험이었다.
다이엔에게 배울 점이 크게 2가지 있었다.
- 긍정적으로 의견을 들어준다. 수용 여부와 상관없이 일단 긍정적으로 들어주고 토론해준다. 덕분에 어떤 의견이라도 함께 얘기해보고 적용할 수 있었다. 너무 즐겁다는 생각이 들었고, 부담없이 의견을 막 나눴던 것 같다.
- 초반에 미션을 진행하며, 미션과 직접적으로 연관은 없지만 함께 시도해보면 좋을 Clean Code 규칙을 얘기했다. 그리고 구현하면서 천천히 적용시켰는데, 놀랐던 점은 마감에 가까워질 수록 안 지킬 수도 있는데 계속 상기시켜주면서 끝까지 챙겨줬다.
제어 컴포넌트, 비제어 컴포넌트
카드 폼을 만들 때 제어 컴포넌트로 만들었다. 입력에 따른 유효성 검사가 바로 대응되어야 돼서이다. 그럼 언제 비제어 컴포넌트가 좋을 지 생각해봤다. 네이버를 써보니 바로 알 수 있었다. 로그인 할 때이다. 바로 값을 얻을 필요가 없다. 제출 버튼을 누를 때 검사하면 된다. 그래서 상황에 따라 제어, 비제어를 선택하면 될 것 같다.
단, 제어 컴포넌트와 비제어 컴포넌트를 넘나는 건 안 좋은 방법이다.
컴포넌트를 항상 작게 나누는 게 좋을까?
컴포넌트 항상 작게 나누는 것이 좋은가? 아니라고 생각한다.
이유는 컴포넌트를 '밀키트'라고 생각하면 쉽다.
'버섯', '면'처럼 작게 단위 나눠져 있으면 여러 밀키드에 사용할 수 있어서 재사용성이 올라간다.
하지만 '땅콩 소스'가 여러 밀키드에서 쓰이는 데도 불구하고 '땅콩', '마요네즈', '올리고당' 등으로 나눠져있다면 매번 사용할 때마다 합쳐줘야 하는 비용이 발생한다.
그러니까 무조건 더 작게 나눌 수 있다고 매번 문제를 작게 나누는 게 아니라,
컴포넌트 내부까지 들어가는 비용, 컴포넌트를 다시 합치는 비용을 고려하며 고민을 해보면서 적절히 컴포넌트를 나누는 게 중요하다고 생각한다.
고민 1) 누구를 대상으로 말을 해야 할까?
상대의 지식 주순을 모를 때, 여러 명이 나의 의견을 듣고 있으면 누구를 기준으로 수준을 맞춰야 할 지 모르겠다. 얼굴을 보고 말하지 않을 때는 잘 말하고 있는 지 더욱 모르겠다.
고민 2) 학습한 내용을 공유하는 범위를 어떻게 잡아야 할까?
내가 학습한 내용을 '모두에게' 말하는 것이 늘 좋은 것은 아니라는 것을 깨달았다.
이유는
- 함께 성장한다는 관점에서 '나의 의견'을 상대에게 말하는 것이 항상 좋은 것은 아님.
- 아직 해당 부분을 구현하지 않은 사람에게는 이미 구현을 완료한 나의 의견이 모범 답안처럼 느껴져서 창의적으로 사고할 수 없게 됨.
- 나의 의견에 설득당해서 스스로 생각해볼 기회를 잃어버림. 나만 성장하게 됨. 장기적인 관점에서 모두가 나의 구현을 따르는 건 나의 성장도 방해함. 적절히 나와 비슷하게 구현한 사람과 아닌 사람이 비율이 비슷해야 토론이 가능함. 그래야 내가 더 성장함.
그래서 '필요한 사람에게 적절히 나의 의견'을 말하는 게 중요하다. 필요하지 않은 사람에게는 독이 될 수도 있는 것 같다. 하지만 나도 말하고 싶지 않은데, 그 사람이 와서 듣는다면 어떡할까? 이건 내가 신경쓸 영역은 아닌 것 같다. 결론적으로, 나도 성장을 원하는 사람이니까 내 의견에 대한 피드백이 필요하다. 그러니까 적절히 상대를 골라서 토론을 하면 될 것 같다.
나만의 Best Practice 만들기
한 주동안 크루들을 관찰하며 얻은 장점을 가지고 만든 Best Practice이다.
다음주에 실천해보겠다.
- 따라하고 싶은 것
- 좋은 자료가 있으면 공유한다. 단, 이유를 포함해서
- 상대방의 의견을 수용할 때 개선할 점이 있더라도, 긍정적으로 들은 부분을 먼저 피드백 해준다.
- 그 후, 개선점을 함께 얘기한다.
- 개념적인 부분을 설명했을 때, 예시를 함께 얘기한다. (~에 예시를 들자면~)
- 상대를 볼 때 어떠한 이유로든 부정적인 마음이 든다면, 상대의 장점을 최소 1개 찾아본다.
헤일리 화이팅~