저희 서비스는 MAU 약 65만 명 정도가 되는, 작지 않은 규모의 서비스입니다. 연말, 연초에는 성수기여서 MAU가 100만이 훌쩍 넘어버리기도 합니다. 그리고 저희 팀은 25년 초에 약 10명 정도의 백엔드 + 프론트엔드 개발자들이 한 팀으로 일하도록 개편되었습니다. 25년 한 해 동안 많은 일이 있었는데, 오늘은 이 과정에 대해 이야기해보려 합니다. 갑작스러운 변화 AI의 발전과 상장 준비 등의 이유로 권고 사직이 시작되었습니다. 이때 알게 된 회사의 악순환 사이클이 있었습니다. 권고사직 → 주변 팀원들의 의욕 저하 → 이직 → 인력 부족 → 채용 → 다시 권고사직. 결국 이 사이클 속에서 개발팀에는 저 혼자만 남게 되었습니다. 혼자 남았을 때는 생각보다 막막했습니다. 저는 프론트엔드 개발자이지만 당장
법학을 전공하고 컴퓨터공학을 부전공하며 프론트엔드 개발자로 일하다 보니, 언뜻 보면 전혀 다른 두 분야에서 공통점을 발견했습니다. 바로 논리적 사고의 구조가 매우 닮아있다는 것입니다. 법학, 문과에서 가장 이과스러운 학문 대부분의 문과 학문이 해석의 여지가 많고 정답이 모호한 반면, 법학은 꽤 명확한 답이 존재합니다. 물론 복잡한 사안에서는 해석이 갈릴 수 있지만, 기본적인 법리 적용에는 정해진 논리적 절차가 있습니다. 특히 형법에서 이런 특징이 두드러집니다. 어떤 행위가 범죄에 해당하는지 판단할 때는 다음 세 가지 요건을 순차적으로 검토합니다. 구성요건해당성 - 법에서 정한 범죄의 구성요건에 해당하는가? 위법성 - 그 행위가 법질서에 위반되는가? 책임 - 행위자에게 비난가능성이 있는가? 이 세 조건을 모두
웹 애플리케이션에서 사용자 인증은 가장 기본적이면서도 중요한 요소 중 하나입니다. 또한 프론트엔드 개발자에게는 서버에서 생성한 JWT 토큰을 클라이언트에서 어떻게 관리하느냐가 중요한 요소입니다. 클라이언트에도 여러 저장소가 있지만, 그 중 localStorage는 개발 난이도가 쉽고 구현하기 간편하다는 장점이 있습니다. 저희 프로젝트는 Vue.js에서 Next.js로 전환되었는데, 기존 Vue.js로 된 프로젝트에서 localStorage로 토큰을 관리하고 있었기에 Next.js로 전환할 때에도 이 로직을 그대로 사용하게 되었습니다. 하지만 서비스를 운영하면서 localStorage 기반 인증 시스템으로 인한 여러 문제점들이 드러나기 시작했습니다. 결국 이번에 Cookie 기반 인증 시스템으로 전환을 진행했
최근 프로젝트에서 OpenAI API를 활용한 실시간 채팅 기능을 구현하면서 예상치 못한 문제를 만났습니다. 백엔드에서는 SSE(Server-Sent Events)로 응답을 한 글자씩 스트리밍하는데, 브라우저에서만 모든 내용이 한꺼번에 도착하는 현상이었습니다. (curl이나 Postman을 통한 요청에서는 정상적으로 스트리밍) 이 문제를 해결하는 과정에서 Next.js의 기본 압축 설정에 대해 알게 되었고, 최종적으로 BFF(Backend for Frontend) 패턴으로 해결할 수 있었습니다. 혹시 비슷한 문제를 겪고 계신 분들께 도움이 되길 바라며 경험을 공유해보겠습니다. 프로젝트 구조 및 문제 상황 우리 프로젝트의 구조는 다음과 같았습니다. 프론트엔드 - 사용자 질문 입력 백엔드 - OpenAI API
전역 상태 관리, 정말 필요한 곳에서만 사용하고 있을까? 전역 상태 관리의 문제점들 프론트엔드 개발을 하다 보면 컴포넌트 간 상태 공유가 필요한 순간들이 있습니다. 이때 대부분 전역 상태 관리 라이브러리를 도입하게 되는데, 시간이 지날수록 다음과 같은 문제들을 마주하게 됩니다. 1. 예측하기 어려운 상태 변화 전역 상태는 어느 컴포넌트에서든 접근하고 변경할 수 있기 때문에, 특정 상태가 어디에서 사용되고 변경되는지 파악하기 어려워집니다. 이런 상황에서 버그가 발생하면 어느 컴포넌트에서 상태를 변경했는지 추적하기 매우 어려워집니다. 2. 상태 초기화 관리의 복잡성 지역 상태(useState)는 컴포넌트가 언마운트될 때 자동으로 초기화됩니다. 반면, 전역 상태는 개발자가 명시적으로 초기화 시점을 관리해야 합니다
서비스를 개선할 때 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를 선택했습니다. SSG(Sta
