이전 글에서 Container 중심 구조의 한계와 Feature-Sliced Design(FSD)으로의 전환 이유를 정리했습니다. 이번 글에서는 실제로 FSD를 프로젝트에 도입하면서 고민했던 내용들을 공유합니다.

오랜 고민 끝에 이직을 결심했다. 회사에 퇴사 의사와 퇴사일까지 이미 통보한 상태다.

이직을 고민한 건 1년쯤 됐지만, 막상 결심하고 나니 모든 게 빠르게 진행됐다.

사실 식스티헤르츠가 나쁜 회사는 아니었다. 처우도 좋았고, 일도 여유롭고 자유롭게 할 수 있었다. 그런데도 나는 계속 이직을 고민하고 있었다.

그 이유를 스스로 찾고, 나 자신을 조금 더 알고 싶어서 이 글을 쓴다.

이전 글에서 SOLID 원칙 중 O에 해당하는 OCP를 충족하는 React 개발에 대해 다루었습니다. 이번에는 L에 해당하는 리스코프 치환 원칙(Liskov Substitution Principle, LSP)에 대해 이야기해보려 합니다. React 개발에서 이 원칙이 어떻게 적용될 수 있는지 함께 살펴볼게요.

이전 글에서 SOLID 원칙을 간단하게 소개하고, 그 중 S에 해당하는 SRP를 충족하는 React 개발에 대해 다루었습니다. 이번에는 O에 해당하는 개방-폐쇄 원칙(Open-Closed Principle, OCP)에 대한 소개와 함께, React 개발에 어떻게 적용될 수 있는지 구체적인 예시를 통해 살펴보겠습니다.

어느덧 2025년이 마무리되고 있습니다.

짧게나마 2025년을 돌아보았는데, 여러모로 반성을 많이 하게 되는 해입니다. 그래도 이번 해를 지내면서 회고하지 않으면 개선되지 않는다는 것을 깊게 체감했습니다.

그래서 지난 일들을 간단히 회고하면서 잘한 점은 칭찬하고, 못한 점은 어떻게 개선할지 고민해보려 합니다.

프론트엔드 아키텍처를 설계할 때 가장 어려운 점은 규모가 커졌을 때도 유지 가능한 구조를 만드는 것이라고 생각합니다.

이 글에서는 제가 사용했던 Container 중심 아키텍처의 의도와 개념, 그리고 그 구조가 확장되며 드러난 한계를 정리하고, 왜 Feature-Sliced Design(FSD)을 다음 선택지로 정하게 되었는지를 이야기해 보려고 합니다.

혹시 SOLID 원칙에 대해 들어보셨나요? 개발을 접하신 분이라면 자세히는 몰라도 한 번쯤 이름은 들어보셨을 거예요. SOLID 원칙은 객체지향 설계에서 지켜야 할 5가지 소프트웨어 개발 원칙(SRP, OCP, LSP, ISP, DIP)을 말합니다.

• SRP(Single Responsibility Principle): 단일 책임 원칙
• OCP(Open Closed Principle): 개방 폐쇄 원칙
• LSP(Liskov Substitution Principle): 리스코프 치환 원칙
• ISP(Interface Segregation Principle): 인터페이스 분리 원칙
• DIP(Dependency Inversion Principle): 의존 역전 원칙

이런 원칙들을 지키면 좋은 객체지향 설계에 가까워질 수 있습니다. 그런데 'React에 객체지향이라니?' 하고 의아하게 생각하실 수도 있을 것 같아요. 하지만 우리는 이런 원칙들을 조금 더 넓은 시야로 바라볼 필요가 있다고 생각합니다.

Front-end 개발을 하다 보면 필연적으로 마주치는 상황이 있습니다. 바로 DB 데이터와의 연동입니다. 대부분의 프로젝트는 이 과정을 BE REST API에 의존하고 있습니다.

BE API가 완성되지 못하면 FE 프로젝트도 완성되지 못하고, 인터페이스가 변경되면 FE 프로젝트도 변경되어야 합니다. 여러분들은 이 의존성을 잘 관리하고 계신가요?

이 글에서는 BE API 의존성을 관리하면서 겪었던 시행착오와 함께, 현재 저희가 나아가고 있는 방향을 소개해드리려고 합니다.

프로젝트를 개발하다 보면 "Build Once, Deploy Anywhere" 개념을 한 번쯤은 접하게 됩니다. 한 번의 빌드로 여러 환경에 배포하거나, 환경변수만 수정해 다양한 variant로 배포하고 싶은 니즈를 표현하는 문구입니다.

하지만 Next.js는 빌드 타임에 환경변수를 결정하는 철학을 가지고 있어, 이 개념과 본질적으로 충돌합니다.

누군가는 어쩔 수 없이 Docker 이미지 하나로 여러 환경에 배포해야 하는 상황에 마주할 수 있습니다

이 글에서는 그런 분들을 위해 Next.js app router에서 런타임 환경변수를 사용하기 위한 다양한 방법을 살펴봅니다.

Next.js App Router로 전환하면서 가장 혼란스러운 부분은 렌더링 방식의 변화입니다.

Page Router에서 SSR/SSG 기반 렌더링을 사용했다면, App Router에서는 RSC+Client Component 기반 렌더링을 사용하도록 변경되었습니다.

이 글에서는 두 방식의 동작 원리를 비교하고, App Router는 Page Router의 개선 버전이 아닌 서로 다른 패러다임을 가진 Next.js의 렌더링 방식임을 설명하려고 합니다.