패턴으로 익히고 설계로 완성하는 리액트를 읽고 나서
패턴으로 익히고 설계로 완성하는 리액트를 읽고 나서
이 책을 읽은 이유
프로젝트를 처음 시작할 땐 단순했던 구조가 시간이 지날수록 점점 복잡해졌다. 컴포넌트는 자꾸 거대해지고, 코드가 점점 읽기 어려워지면서 "이게 진짜 최선일까?"라는 생각이 들기 시작했다.
특히 팀 작업을 하면서는 유지보수와 확장에 대한 부담도 커지고, 테스트 코드조차 손대기 어렵게 느껴졌다. 그래서 "더 좋은 설계, 더 나은 패턴"에 대한 갈증이 쌓였고, 마침내 『패턴으로 익히고 설계로 완성하는 리액트』를 집어들게 됐다.
이 책이 지금 내가 마주한 구조적인 문제들을 푸는 실마리, 그리고 앞으로 더 깔끔하고 읽기 쉬운 코드를 쓰는 데 분명 도움이 될 거란 기대가 컸다.
이 책을 읽으면서 느낀 점들
1 ~ 47p
수도 없이 봐왔던 리액트 안티패턴 코드다. 컴포넌트 파일 안에 비즈니스 로직이 포함되어 있어 코드를 읽기 어렵게 만든다.
이러한 코드는 컴포넌트의 책임이 명확하지 않고, 재사용성이 떨어져 DRY 원칙을 지키기 어렵다. 또한 테스트 코드 작성도 어려워진다. 왜냐하면 비즈니스 로직과 뷰 로직을 모두 고려한 테스트 코드를 작성해야 하기 때문이다.
이러한 리액트 안티패턴을 알고 있었지만, 일이 바빠 그냥 넘어간 경우도 있었다. 앞으로 이러한 안티패턴 코드를 보면 더 나은 코드로 수정하도록 노력해야겠다.
48 ~ 76p
요즘 내가 진행 중인 프로젝트에서 가장 크게 체감하는 문제는 구조적인 복잡성의 증가다.
프로젝트 규모가 커지면서 컴포넌트 간의 의존성이 점점 심해지고, 폴더의 책임이 모호해지며, 일관되지 않은 규칙으로 작성된 파일들이 늘어나고 있다. 또한, 도메인 간의 의존성이 얽히면서 유지보수와 확장에 큰 어려움을 겪고 있다.
프로젝트 초기에는 비교적 단순한 구조로 출발했지만, 지금의 규모와 복잡도를 감안하면 그때의 폴더 구조는 분명히 한계가 있었던 것 같다. 이제는 구조적인 리팩토링이 필요한 시점이라고 판단한다.
이러한 문제를 해결하기 위해 FSD 아키텍처 도입을 고민하고 있으며, 러닝 커브가 크지 않으면서 관심사에 따라 명확히 구분할 수 있는 도메인 기반 폴더 설계도 고려하고 있다.
이번에 읽는 이 책을 통해 그동안 품어온 고민들이 조금이나마 해소되고, 현재 프로젝트의 구조적 문제에 대한 명확한 해답을 얻을 수 있기를 바란다.
꼭 완독해야지~!
77 ~ 113p
나는 지금까지 사진에 나와 있는 방식은 한 번도 생각해본 적이 없었다. 그 사진에서는 하나의 컴포넌트에 여러 개의 리액트 노드를 props로 전달하는 방법이 소개되어 있었다.
이러한 방식의 장점은, 컴포넌트를 props로 전달하기 때문에 하위 컴포넌트에 다시 props를 넘길 필요가 없다는 것이다. 즉, 상위 컴포넌트에서 모든 데이터를 넘겨줄 수 있어 자연스럽게 props 드릴링을 방지할 수 있다.
나는 지금까지 이 책을 읽으며 대부분의 내용을 이미 알고 있다고 생각했고, 과연 이 책에서 새롭게 얻어갈 것이 있을까 하는 의문도 들었다. 하지만 그런 생각은 오만이었다. 사진에 나온 코드 예시를 보고 큰 충격을 받았다. 그런 방식은 한 번도 떠올려본 적이 없었기 때문이다.
역시 어떤 책이든 배울 점은 있기 마련이다. 익숙하다고 생각했던 내용 속에서도 새로운 관점을 발견할 수 있다는 사실을 다시금 느꼈다.
114 ~ 126p
많은 개발자들이 항상 중요하게 생각하는 것이 있다. 바로 테스트 코드다. 테스트 코드는 개발자가 작성한 코드가 의도한 대로 동작하는지 검증할 수 있는 중요한 수단이다.
하지만 현실에서는 "시간이 없다"는 핑계나 "테스트 코드 작성이 어렵다"는 이유 등으로 테스트 코드를 작성하지 않는 경우도 많다. 그리고 이런 말도 있다. 정해진 기간 내에 기획에 맞는 구현을 완료하고, 거기에 더해 테스트 코드까지 작성해야 하며, 만약 시간 내에 테스트 코드를 작성하지 못했다면 실력이 부족하다는 평가를 받을 수 있다.
나 역시 그런 평가를 듣고 싶지 않기에, 테스트 코드를 꾸준히 작성하려고 노력하고 있다.
비록 처음에는 어렵고 시간이 걸렸지만, 작성해둔 테스트 코드 덕분에 예상치 못한 버그를 빠르게 잡을 수 있었던 경험도 있었다.
앞으로 나는 '테스트 코드를 통해 더 나은 코드를 작성한다'는 관점으로 계속해서 연습하고 발전해 나가고 싶다
126 ~ 154p
개발자에게 리팩토링은 끝없는 숙제이자 반복되는 과제라고 생각한다. 개발이 완료된 이후에도, 다음 개발을 더 잘하기 위해 리팩토링은 반드시 필요한 과정이다.
리팩토링이 중요한 이유는, 한 번 작성한 코드도 시간이 지나면 금세 레거시가 되기 때문이다. 과거의 코드에 안주하지 않고, 더 나은 구조와 가독성을 위해 지속적으로 개선해나가야 한다.
리팩토링을 통해 코드는 더 읽기 쉬워지고, 이는 나뿐만 아니라 함께 일하는 동료 개발자들에게도 큰 도움이 된다. 또한 기능 단위로 잘 나뉜 코드는 재사용성이 높아지고, 기획 변경이 되었을 때에도 유연하게 대응할 수 있게 해준다.
가끔 리팩토링을 하다 보면 ‘처음부터 잘 짰다면 이 고생은 안 했을 텐데’라는 생각이 들기도 한다. 하지만 이런 시행착오도 개발자의 성장 과정이라 생각하며, 틈날 때마다 리팩토링하려고 노력하고 있다.
앞으로도 복잡하고 지저분한 코드를 더 깔끔하게 정리해, 누구나 읽기 쉬운 코드로 만들기 위해 꾸준히 개선해 나갈 것이다
155 ~ 186p
"항상 점진적으로 문제를 해결하라"는 말은 많은 개발자들이 강조하는 원칙이다. 리팩토링이나 테스트 코드 작성도 한 번에 끝내려 하기보다 점진적으로 진행하는 것이 좋다.
점진적으로 작업하면 언제든 배포 가능한 상태를 유지할 수 있다. 문제가 생겨도 어디서 발생했는지 빠르게 파악할 수 있다.
나 역시 여러 리팩토링을 해봤지만, 가장 효과적이었던 방법은 점진적인 리팩토링이었다. 한꺼번에 많은 코드를 수정하면 버그가 생기고 원인을 찾기 어려웠다.
리팩토링의 핵심은 변경 전후 기능이 동일하게 작동해야 한다는 점이다.
앞으로도 더 나은 코드를 작성하고, 팀원들과 함께 보기 좋은 코드를 만들기 위해 꾸준히 노력할 것이다.
187 ~ 216p
오늘도 하나 크게 배운 게 있다. 바로 사진에 나와 있는 방식인 ACL(오류 방지 계층, Anti Corruption Layer) 개념이다.
ACL은 프론트엔드와 백엔드 간의 API를 연결해주는 역할을 한다. 이를 구현하면 클라이언트와 외부 서비스 간 상호작용을 하나의 통합 인터페이스로 관리할 수 있다.
그동안 나는 UI 컴포넌트에서 직접 null이나 undefined 값을 처리하곤 했다. 하지만 이런 방식은 컴포넌트를 복잡하게 만들고, 유지 보수성을 떨어뜨린다.
반면, ACL을 통해 데이터를 가공하고 예외 처리를 미리 해두면, 컴포넌트는 오직 UI에만 집중할 수 있게 된다. 결과적으로 더 깔끔하고 읽기 쉬운 코드가 된다.
지금까지 왜 이런 방식을 생각하지 못했는지 아쉬울 정도다. 오늘도 한 대 얻어맞은 듯한 기분이다. 앞으로 ACL을 적극 활용해 더 깔끔하고 견고한 코드를 작성하는 개발자가 되겠다.
217 ~ 244p
단일 책임 원칙, 의존관계 역전 원칙, 명령과 조회 책임 분리 원칙 등... 소프트웨어 공학에는 좋은 코드를 작성하기 위한 다양한 법칙들이 존재한다. 그리고 이 법칙들은 리액트 같은 프론트엔드 개발에도 충분히 적용할 수 있다.
이러한 원칙들은 수많은 개발자들의 경험을 통해 정리된, 말 그대로 조상님들의 지혜다. 나는 이 지혜들을 공부하고 이해함으로써 더 나은 코드를 작성하려 노력해야 한다.
물론 나도 한때는 그런 원칙들을 잘 몰랐던 시절이 있었다. 신입 시절에는 이런 법칙들을 고려하지 않고 개발하곤 했다. 지금은 책도 읽고 공부하면서 점차 지식을 쌓아가고 있지만, 돌이켜보면 그 당시엔 정말 많이 무지했던 것 같다.
개발자는 사고력도 중요하지만, 좋은 코드를 위한 공부와 꾸준한 노력이 필수적이다. 왜냐하면 개발은 혼자 하는 일이 아니라, 항상 동료들과 함께하는 협업이기 때문이다. 그래서 나는 앞으로도 협업을 잘하는 개발자가 되기 위해 계속해서 노력할 것이다.
245 ~ 288p
요즘 코드를 이해하는 데 시간이 오래 걸릴 때가 많다. 그럴수록 느끼는 건, 코드란 결국 '읽기 쉬움'이 핵심이라는 점이다. 이를 위해선 결합도를 낮추고 응집도를 높이는 구조가 필요하고, 함수의 로직이 길어지면 과감히 나눠서 리팩토링해야 한다.
현재 진행 중인 프로젝트도 규모가 커지면서 복잡한 파일이 많아졌다. 그럴 때마다 코드를 읽는 일이 점점 더 어렵고 부담스럽게 느껴진다. 그래서 최근엔 ‘한 함수는 하나의 역할만’이라는 원칙을 기준 삼아 리팩토링하려 한다.
소규모 프로젝트에선 잘 느끼지 못했지만, 규모가 커질수록 유지보수는 곧 생산성과 직결된다. 읽기 쉬운 코드는 미래의 나뿐만 아니라 팀 전체의 효율을 높인다.
나는 이런 고민들은 개발자라면 누구나 겪는 일이라 생각한다. 그래서 나는 이 과정을 즐기며, '읽기 쉬운 코드'를 꾸준히 작성하며 더 나은 협업과 유지보수를 위해 계속 노력할 것이다.
289 ~ 356p
이 책을 완독하며 애플리케이션의 품질을 높이는 다양한 방법을 배울 수 있었다. 특히 소프트웨어 공학의 핵심 원칙인 ACL, DIP, SRP, DRY 등의 개념을 실제 리액트 애플리케이션에 어떻게 적용할 수 있는지에 대한 구체적인 설명과 예시는 큰 도움이 되었다.
책에서 얻은 지식은 단순한 이론에 그치지 않고, 앞으로 실제 프로젝트에 적극 활용할 계획이다. 좋은 애플리케이션은 개인의 역량뿐 아니라, 팀원들과 함께 공통된 원칙과 규칙을 지키며 협업할 때 완성된다는 점도 다시금 깨달았다.
그동안 프로젝트 규모가 커질수록 다양한 문제들이 발생해 고민이 많았는데, 이 책을 통해 그 해답의 실마리를 찾은 듯하다.
이 책을 시작점으로 삼아 더 나은 코드, 유지 보수가 쉬운 구조를 지향하며 꾸준히 성장해 나갈 것이다. 부족한 지식은 계속해서 보완하고, 빠르게 변화하는 개발 생태계 속에서 좋은 동료이자 책임 있는 개발자로 자리매김할 수 있도록 노력하겠다.
이 책을 추천하는 이유
이 책을 덮고 나니 '진짜 좋은 코드는 결국 읽기 쉽고, 모두가 이해할 수 있는 코드'라는 사실을 다시 한 번 마음에 새기게 됐다.
그리고, 우리가 늘 교과서처럼 듣던 소프트웨어 공학 원칙들 SRP, DIP, DRY 같은 법칙이 리액트에서도 실제로 엄청 중요하게 작동한다는 걸 제대로 체감했다.
내가 겪었던 구조적 한계, 복잡한 프로젝트 속에서 길을 잃은 듯한 기분, 그리고 '이렇게 해도 되나?' 싶은 순간마다 이 책이 정말 든든한 가이드가 되어주었다.
프로젝트가 커지면서 코드 품질이나 구조에 고민이 많은 개발자, 리팩토링과 협업에 관심 있는 분들이라면 이 책에서 꼭 한 번쯤, 실무에 바로 적용할 수 있는 팁과 답을 얻을 수 있을 거라고 자신 있게 추천한다.