console.blog()

들어가며프론트엔드 프로젝트의 규모가 커지면 효율적인 코드 구조화의 중요성이 더욱 부각되기 마련이다.이를 해결하기 위해 구조화된 설계와 디자인 패턴을 많이 사용하는 추세이다.최근 PHP 와 Vue로 작성된 페이지를 Next.js로 마이그레이션 하는 과정에서팀내 프로젝트 패턴을 통일하기 위해 FSD 방법론을 도입하려고한다.Feature-Sliced Design(FSD) 아키텍처를 활용하고 이를 실제 프로젝트에 적용하는 방법에 대해 알아보자.FSD란?Feature-Sliced Design은 프론트엔드 아키텍처 방법론으로,비즈니스 로직을 기능(feature) 단위로 분할하고 계층화된 구조로 관리하는 접근 방식이다.이는 프로젝트의 복잡성을 효과적으로 관리하고, 코드의 재사용성과 유지보수성을 향상시키는데 도움을 준..

왜 이 글을 쓰게 됐나? 🤔최근 같이 교류하던 분들과 친한 개발자 분이 이렇게 물어봤다. ”이 @components 같은 거 왜 쓰는 거예요? 어떤 이유가 있죠?"솔직히 나도 처음엔 그냥 "깔끔해 보여서" 쓰기 시작했다. 이참에 내가 쓰던 방식을 같이 복기하면서 정리해볼까 한다.alias가 뭔지 알아보자상대경로의 불편함부터 보자프로젝트 하다 보면 이런 코드 진짜 많이 보게 된다// 깊이가 깊어질수록...import { Button } from '../../../components/common/Button';import { Input } from '../../../components/common/Input';import { useAuth } from '../../../hooks/useAuth';이런 im..

"더 깊이 알고 싶다", "이게 최선일까?", "정말 이게 맞는 걸까?"개발자로서 끊임없이 마주치는 이 질문들에 대한 답을 찾을 수 없겠지만,정해진 길이 없는 개발자의 성장 경로에서, 혼자만의 학습이 아닌 새로운 방향을 찾고 싶었다.그렇게 시작한 10주간의 여정이 마무리되었다.  다양한 경력을 가진 팀원들과 함께하며 새로운 시각을 발견했다.밤늦게까지 이어진 과제와 코드 리뷰 시간은 단순한 기술 공유를 넘어 서로의 관점을 이해하는 소중한 시간이었다.'이런 식으로도 생각할 수 있구나!' 하는 깨달음의 순간들이 쌓여갔고,열정 넘치는 코치님들의 멘토링은 기술 외적인 부분에서도 값진 배움을 선물해주었다.  처음엔 모든 과제를 완벽하게 해내겠다는 욕심을 부렸지만,회사 업무와 병행하는 게 쉽지만은 않았다.하지만 31..

1. 문제AWS를 활용한 CI/CD 파이프라인 구축 과제를 시작하며 여러 고민이 있었다. 우선 어떤 클라우드 서비스를 선택할지가 큰 고민이었다. Vercel이나 Firebase도 좋은 선택지였지만, AWS를 선택한 이유는 실제 업무 환경에서 가장 많이 사용되는 서비스이고, S3와 CloudFront의 조합이 비용 효율적이면서도 확장성이 좋다고 판단했기 때문이다.특히 AWS 서비스들의 연동 과정이 생각보다 복잡했다. S3 버킷 설정부터 CloudFront 배포, IAM 권한 설정까지 하나하나가 새로운 도전이었다. 처음에는 문서를 보며 따라 하는 것조차 쉽지 않았고, 특히 IAM 권한 설정에서 많은 시행착오를 겪었다. 최소 권한 원칙을 지키면서도 필요한 모든 기능을 사용할 수 있게 설정하는 것이 어려웠다.G..

1. 문제이번 주 과제는 테스트 시나리오를 직접 작성하고 구현하는 것이었다. 이 과정에서 몇 가지 문제와 고민이 생겼다.테스트 전략 수립팀 내에서 다양한 테스트 의견이 있었고(Unit + E2E, Unit + Integration, 모든 테스트), 적절한 테스트 전략을 결정하는데 어려움이 있었다.통합 테스트만으로도 충분하다는 결론이 났다, 나도 동감했고 통합 테스트를 작성하다 시간이 남아서 E2E 테스트의 필요성도 느껴 추가 도전을 결정했다.테스트 환경 구성Integration 테스트를 위한 MSW 설정과 API 모킹 방법 고민E2E 테스트를 위한 Playwright 환경 설정과 학습이 필요했다.특히 윤년, 월말 등 시간 관련 테스트를 위한 모킹 전략 수립이 어려웠다.테스트 시나리오 설계반복 일정이라는 ..

1. 문제이번 주 과제는 지난주에 리팩토링한 프로젝트 구조를 바탕으로 테스트 코드를 작성하고, FSD 패턴과 상태 관리에서 미숙했던 부분을 개선하는 것이었다. 이 과정에서 몇 가지 문제와 고민이 생겼다.테스트 범위 결정의 어려움주요 기능을 모두 테스트하려다 보니 테스트 범위를 어디까지 설정해야 할지 고민이 많았다. 특히 유틸리티 함수와 커스텀 훅의 테스트부터 시작해, 전체 흐름을 확인하는 통합 테스트까지 커버하려고 하니 테스트 케이스 관리와 코드 작성이 생각보다 오래 걸렸다.데이터 상태의 독립성 유지각 테스트가 독립적으로 작동하도록 테스트 데이터와 핸들러를 설정하는 방법을 고민하게 되었다. 특히 mock 데이터를 기반으로 테스트를 진행하면서 테스트 간 상태 초기화와 독립성을 어떻게 유지할지 어려움이 있었..

1. 문제이번 주 과제는 기존의 상태 관리와 컴포넌트 구조를 FSD(Folder Structure Design) 패턴으로 리팩토링하고, react-query와 zustand를 활용해 상태 관리 방식을 개선하는 것이었다. 이를 진행하면서 다음과 같은 문제들이 있었다:코드 구조의 복잡성상태 관리와 API 호출, UI 로직이 한 파일에 얽혀 있어 코드가 길어지고, 컴포넌트별로 코드를 이해하기 어려운 점이 많았다.프로젝트가 커질수록 파일 간 의존성이 높아지고, 변경 사항을 적용할 때 발생할 수 있는 오류 가능성 또한 높아졌다.유지보수성 저하상태 관리와 관련된 로직이 분산되어 있어 특정 기능이나 컴포넌트를 수정할 때 관련된 코드를 모두 찾아 수정해야 하는 번거로움이 있었다.여러 곳에서 필요한 상태를 공유할 때 상..

1. 문제이번 주에는 기존 리액트 코드의 상태 관리 방식을 Context와 Custom Hook을 활용해 리팩토링하는 과제가 있었다. 컴포넌트마다 각기 다른 상태와 로직을 관리하고 있었기 때문에 코드가 복잡해지고, 유지보수가 어려워지는 문제가 있었다. 특히 다음과 같은 문제가 있었다:복잡한 상태 관리AdminPage, CartPage 같은 주요 컴포넌트에서 여러 상태(products, cart, coupons)를 개별적으로 관리하고 있었다.상태가 분산되다 보니 로직이 길어지고, 코드 흐름을 이해하기 어려웠다.중복된 코드제품 추가, 수정, 삭제 등의 로직이 각각의 컴포넌트에 중복되어 있었다.동일한 로직을 여러 곳에서 관리하다 보니, 기능을 수정할 때 모든 컴포넌트를 일일이 수정해야 하는 번거로움이 있었다...