서비스를 개선할 때 AB 테스트는 매우 중요한 도구입니다. 오늘은 Next.js의 Middleware를 활용하여 간단하게 AB 테스트를 구현한 경험을 공유하고자 합니다. AB 테스트는 두 가지 버전(A와 B)의 웹페이지나 기능을 사용자들에게 무작위로 보여주고, 어떤 버전이 더 효과적인지 측정하는 방법입니다. 이번 AB 테스트는 상세페이지 개편 이후 실제 구매로 전환되는 비율에 변화가 있는지를 테스트했습니다. 기존에 Google Tag Manager(GTM)가 연결되어 있었기 때문에 특정 상세페이지에 진입했을 때 50:50으로 각각 다른 페이지로 보내주기만 하면 이를 활용하여 결제 페이지 진입률이나 최종 구매 전환율 등을 추적할 수 있었습니다. Next.js Middleware로 구현하기 Next.js의 Mi
Playground를 만들게 된 이유 🤔 프론트엔드 개발에서 디자인 시스템은 매우 중요한 역할을 합니다. 일관된 UI를 구축함으로써 사용자 경험을 향상시키고, 개발자와 디자이너의 리소스를 절약하여 효율적인 업무 환경을 조성합니다. 디자인 시스템은 단순히 컴포넌트 모음이 아닌, 팀 전체가 따라야 할 규칙과 원칙을 담고 있습니다. 하지만 아무리 훌륭한 디자인 시스템도 제대로 문서화되지 않으면 그 가치가 크게 떨어집니다. 문서화가 부실하면 팀원들은 규칙을 자주 어기게 되고, 시간이 지날수록 시스템의 일관성이 희미해져 결국 사라지게 됩니다. 코드상으로 디자인 시스템의 규칙을 강제할수도 있지만, 개발자 뿐 아니라 디자이너에게도 제공할 문서가 필요합니다. 따라서 디자인 시스템을 명확히 문서화하고 팀원들이 쉽게 접근
개발을 하다 보면 VS Code의 ESLint가 가끔 제대로 동작하지 않는 경우가 있습니다. 이는 저만의 문제가 아니라 팀원 모두가 공통적으로 겪고 있던 이슈였습니다. 특히 대규모 프로젝트에서는 VS Code의 ESLint 확장 프로그램이 메모리 부족이나 성능 문제로 제대로 작동하지 않는 경우가 종종 발생하는 것 같습니다. 저의 경우 이 상태에서 VS Code의 Developer: Reload Window 를 하면 일시적으로 해결되곤 했습니다. 그러나 이런 상황에서 개발자들은 lint 에러를 인지하지 못한 채로 코드를 push하게 되고, GitHub Actions에서 빌드가 실패하는 것을 확인하게 됩니다. 빌드 체크에 약 5분 정도 소요되는데, 이런 상황이 반복되면서 개발 생산성이 저하되는 문제가 있었습니다
들어가며 - 왜 블로그를 만들게 되었나요? 🤔 개발자로서 학습 내용을 기록하고 공유하는 것은 매우 중요한 일입니다. 저는 그동안 Notion에 개발 학습 내용을 기록해왔는데, 이를 블로그 형태로 공유하고 싶다는 생각이 들었습니다. 그러나 velog나 tistory 등 블로그 플랫폼으로 마이그레이션하기에는 많은 시간이 필요했습니다. 노션의 이미지는 aws s3로 저장되는데, 이 데이터를 옮기는 작업이 번거로웠기 때문입니다. 그리고 가장 큰 이유로, 익숙한 Notion으로 계속 글을 작성하고 싶었습니다. 그래서 Notion API를 활용해 직접 블로그를 구축하기로 결정했습니다. Notion API로 블로그 만들기 ⚡️ Next.js + Notion API 블로그 구축을 위해 Next.js를 선택했습니다. S
