총 5개의 글
들어가며 - 왜 블로그를 만들게 되었나요? 개발자로서 학습 내용을 기록하고 공유하는 것은 매우 중요한 일입니다. 저는 그동안 Notion에 개발 학습 내용을 기록해왔는데, 이를 블로그 형태로 공유하고 싶다는 생각이 들었습니다. 그러나 velog나 tistory 등 블로그 플랫폼으로 마이그레이션하기에는 많은 시간이 필요했습니다. 노션의 이미지는 aws s3로 저장되는데, 이 데이터를 옮기는 작업이 번거로웠기 때문입니다. 그리고 가장 큰 이유로, 익숙한 Notion으로 계속 글을 작성하고 싶었습니다. 그래서 Notion API를 활용해 직접 블로그를 구축하기로 결정했습니다. Notion API로 블로그 만들기 Next.js + Notion API 블로그 구축을 위해 Next.js를 선택했습니다. SSG(Sta
Playground를 만들게 된 이유 프론트엔드 개발에서 디자인 시스템은 매우 중요한 역할을 합니다. 일관된 UI를 구축함으로써 사용자 경험을 향상시키고, 개발자와 디자이너의 리소스를 절약하여 효율적인 업무 환경을 조성합니다. 디자인 시스템은 단순히 컴포넌트 모음이 아닌, 팀 전체가 따라야 할 규칙과 원칙을 담고 있습니다. 하지만 아무리 훌륭한 디자인 시스템도 제대로 문서화되지 않으면 그 가치가 크게 떨어집니다. 문서화가 부실하면 팀원들은 규칙을 자주 어기게 되고, 시간이 지날수록 시스템의 일관성이 희미해져 결국 사라지게 됩니다. 코드상으로 디자인 시스템의 규칙을 강제할수도 있지만, 개발자 뿐 아니라 디자이너에게도 제공할 문서가 필요합니다. 따라서 디자인 시스템을 명확히 문서화하고 팀원들이 쉽게 접근할 수
서비스를 개선할 때 AB 테스트는 매우 중요한 도구입니다. 오늘은 Next.js의 Middleware를 활용하여 간단하게 AB 테스트를 구현한 경험을 공유하고자 합니다. AB 테스트는 두 가지 버전(A와 B)의 웹페이지나 기능을 사용자들에게 무작위로 보여주고, 어떤 버전이 더 효과적인지 측정하는 방법입니다. 이번 AB 테스트는 상세페이지 개편 이후 실제 구매로 전환되는 비율에 변화가 있는지를 테스트했습니다. 기존에 Google Tag Manager(GTM)가 연결되어 있었기 때문에 특정 상세페이지에 진입했을 때 50:50으로 각각 다른 페이지로 보내주기만 하면 이를 활용하여 결제 페이지 진입률이나 최종 구매 전환율 등을 추적할 수 있었습니다. Next.js Middleware로 구현하기 Next.js의 Mi
전역 상태 관리, 정말 필요한 곳에서만 사용하고 있을까? 전역 상태 관리의 문제점들 프론트엔드 개발을 하다 보면 컴포넌트 간 상태 공유가 필요한 순간들이 있습니다. 이때 대부분 전역 상태 관리 라이브러리를 도입하게 되는데, 시간이 지날수록 다음과 같은 문제들을 마주하게 됩니다. 1. 예측하기 어려운 상태 변화 전역 상태는 어느 컴포넌트에서든 접근하고 변경할 수 있기 때문에, 특정 상태가 어디에서 사용되고 변경되는지 파악하기 어려워집니다. 이런 상황에서 버그가 발생하면 어느 컴포넌트에서 상태를 변경했는지 추적하기 매우 어려워집니다. 2. 상태 초기화 관리의 복잡성 지역 상태(useState)는 컴포넌트가 언마운트될 때 자동으로 초기화됩니다. 반면, 전역 상태는 개발자가 명시적으로 초기화 시점을 관리해야 합니다
최근 프로젝트에서 OpenAI API를 활용한 실시간 채팅 기능을 구현하면서 예상치 못한 문제를 만났습니다. 백엔드에서는 SSE(Server-Sent Events)로 응답을 한 글자씩 스트리밍하는데, 브라우저에서만 모든 내용이 한꺼번에 도착하는 현상이었습니다. (curl이나 Postman을 통한 요청에서는 정상적으로 스트리밍) 이 문제를 해결하는 과정에서 Next.js의 기본 압축 설정에 대해 알게 되었고, 최종적으로 BFF(Backend for Frontend) 패턴으로 해결할 수 있었습니다. 혹시 비슷한 문제를 겪고 계신 분들께 도움이 되길 바라며 경험을 공유해보겠습니다. 프로젝트 구조 및 문제 상황 우리 프로젝트의 구조는 다음과 같았습니다. 프론트엔드 - 사용자 질문 입력 백엔드 - OpenAI API
