hmk run dev

모노레포에서 린트 작업의 처리 속도를 크게 향상시키기 위해, 동기 방식에서 비동기 방식으로 전환한 경험을 공유합니다. Node.js의 이벤트 루프와 비동기 처리의 원리를 이해하면 빌드 파이프라인의 효율성을 대폭 개선할 수 있습니다. 왜 린트 시간을 개선해야 했는가? 모노레포 프로젝트가 커질수록 린트 작업은 점점 더 많은 시간을 소요합니다. 특히 CI/CD 파이프라인에서 모든 패키지를 일일이 검사하는 과정은 개발 생산성을 저하시키는 주요 요인이 됩니다. 기존에는 변경된 패키지마다 린트 작업을 순차적으로(동기적으로) 실행했으나, 이 방식은 패키지 수가 늘어날수록 선형적으로 시간이 증가하는 문제가 있었습니다.해결 접근법: 비동기 병렬 처리코드를 분석해보면, 기존에는 execSync를 사용해 패키지별 린트 작업..

웹 애플리케이션 개발 중 예상치 못한 에러를 마주칠 때가 있습니다. 그중에서도 특히 외부 API와 연동할 때 발생하는 문제는 디버깅이 어려울 수 있습니다. 최근 저희 팀은 카카오 로그인 구현 과정에서 긴 URL로 인해 발생하는 404 에러와 Nginx 오류 화면을 마주쳤습니다. 이 글에서는 그 원인과 해결 방안, 그리고 이와 관련된 개발 시 고려해야 할 사항들을 공유하고자 합니다.문제 상황카카오 로그인 구현 시 kauth.kakao.com/oauth/authorize로 로그인 요청을 보내는 과정에서 URL이 너무 길 경우 404 에러 및 Nginx 오류 화면이 나타나는 문제가 발생했습니다. 특히 UTM 파라미터(마케팅 추적 코드)와 같은 추가 매개변수가 포함된 경우에 이런 현상이 두드러졌습니다.문제의 예..

Next.js 14의 App Router 환경에서는 서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR), 정적 생성(SSG), ISR 등 다양한 렌더링 방식을 상황에 맞게 조합할 수 있다. 특히 App Router는 서버 컴포넌트와 클라이언트 컴포넌트를 구분하고, 내장 fetch의 캐시 전략과 메타데이터 설정이 유연해지면서 SEO 대응 방식도 훨씬 정교해졌다. 그중 하나가 searchParams 기반 SSR이다. 기존의 다이나믹 라우트 방식과 달리, URL의 query string을 기반으로 서버에서 데이터를 받아 페이지를 렌더링하는 방식이다. 이 방식은 필터형 상품 페이지나 SKU 조합 페이지에서 매우 유용하다. 하지만 SEO 관점에서 보면 몇 가지 주의할 점이 있다. 렌더링 방식별 SEO..

Next.js는 다양한 렌더링 방식을 제공합니다. 정적 생성(SSG), 서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR), 그리고 점진적 정적 생성(ISR)까지 다양한 전략이 가능하죠. 버전이 14에 도달하면서 App Router가 정식화되었고, fetch() 내장, cache, revalidate, searchParams, server/client component 분리 등 보다 유연한 방식으로 구성할 수 있게 되었습니다.하지만 기능이 다양해진 만큼 "어떤 상황에서 어떤 렌더링 방식을 선택해야 하는지"는 더욱 고민되는 지점입니다. 특히 실무에서 많이 마주치는 SKU 기반 조합 페이지나, 필터형 검색 결과 페이지 등에서는 의사결정이 쉽지 않습니다.이번 글에서는 실제 사례를 중심으로, 어떤 ..

Next.js 프로젝트에서 백엔드 API와 통신할 때, 우리는 종종 브라우저 또는 서버(SSR/API 라우트 등)에서 외부 서버로 HTTP 요청을 보냅니다. 이때 성능 최적화를 고려한다면 "keep-alive" 설정을 살펴볼 필요가 있습니다. 브라우저에서 keep-alive는 어떻게 작동할까?서버 → 서버 요청에서는 왜 명시적으로 설정이 필요할까?실제로 어떻게 적용할 수 있을까? HTTP keep-alive란?기본적으로 HTTP 요청은 다음 흐름을 따릅니다:연결 열기 → 요청 보내기 → 응답 받기 → 연결 닫기이런 구조는 요청마다 새로운 TCP 연결을 만들고 끊는 비효율을 초래합니다. 특히, 서버 → 서버 간에 수백~수천 개의 API 호출이 일어난다면 이 비용은 무시할 수 없습니다.keep-alive는 ..

"비즈니스는 속도가 생명이다." 초기 단계에서는 빠른 제품 출시와 시장 적응을 위해 효율성보다 결과를 우선시하기 쉽다. 이는 자연스럽게 기술 부채를 남기고, '레거시 코드'라 불리는 코드 뭉치나 비효율적인 아키텍처로 이어진다. 하지만, 레거시는 단순히 부정적인 요소가 아니다. 오히려 현재의 비즈니스를 지탱하는 '기반'이자 과거의 성과를 보여주는 흔적이기도 하다."우리는 이 레거시 덕분에 지금까지 성장할 수 있었다." 라는 생각도 가능하다. 레거시란 무엇인가?레거시는 단순히 "오래된 코드"를 의미하지 않는다. 본질적으로 유지보수가 어렵고, 팀의 생산성을 저하시키는 시스템을 뜻한다. 이는 코드의 나이가 아니라 구조적 문제, 복잡성, 문서화 부족, 또는 기술 부채로 인해 발생하는 결과이다.또 다른 관점에서, ..

로그는 에러 뿐만아니라 비즈니스 결정을 위한 중요한 요소가 된다.     이처럼 많은 로그를 자동화하기 위해서 많은 중복 코드가 발생할 수 밖에 없다.  토스는 자체 디자인 시스템인 TDS를 이용해 로깅을 자동화했다.  첫번째 시도 - 디자인시스템에 로그 기능을 추가하자개발 비용도 적고 기존에 사용하던 곳에도 적용하기 쉬웠음 그러나, 계열사 별로 로그 코드가 많고 형태가 달라 통합하기 쉽지않음그리고 로깅관련 코드가 함께 배포되는 이슈가 있었음  TDS가 로깅관련 코드를 포함해 로깅관련 수정사항을 반영하면 모든 컴포넌트의 디자인 사양도 변경해야하는 문제도 발생했다.   두번째 시도 -  HOC 형태로 로그 감싸기  TDS 컴포넌트를 감싸 제공하는 형태로 제공,서로 독집적으로 수정하고 배포가 가능해졌다. ..

프론트엔드 개발의 중요성프론트엔드프런트엔드 개발은 웹 애플리케이션이나 웹사이트의 ‘얼굴’입니다. 사용자가 처음 만나는 부분이기 때문에, 프런트엔드 개발의 품질은 사용자의 첫인상에 직접적인 영향을 미치죠. 하지만 왜 그렇게 중요한 걸까요? 몇 가지 예시를 통해 살펴보겠습니다.   1. 사용자 경험(UX)사용자가 웹사이트를 방문했을 때, 그들이 어떻게 느끼는지가 중요합니다. 예를 들어, 여러분이 좋아하는 온라인 쇼핑몰에서 상품을 검색할 때, 결과가 빠르게 나타나고, 디자인이 깔끔하며, 직관적으로 탐색할 수 있다면, 그 경험이 얼마나 긍정적일까요? 반면, 느린 로딩 속도와 복잡한 내비게이션으로 인해 불편함을 느낀다면, 아마도 다시 방문하고 싶지 않을 겁니다. 이처럼 프런트엔드 개발은 사용자 경험을 극대화하는..

WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다. 실시간 통신: 브라우저 간에 실시간으로 오디오, 비디오, 데이터 스트림을 주고받습니다.(기본적으로 UDP 사용)플러그인 불필요: 별도의 설치나 플러그인이 필요 없으며, HTML5와 자바스크립트만으로 통신이 가능합니다.P2P 연결: 서버를 통해 데이터를 중계하지 않고, 사용자들끼리 직접 통신하여 지연 시간을 최소화합니다.보안: 기본적으로 모든 통신은 암호화되어 있어, 보안이 중요한 실시간 통신에 적합합니다. 중개서버를 거치지 않기 때문에 빠른 속도로 통신이 가능하며 HTTPS..

3년 차 프런트엔드 개발자로서, 요즘 많은 개발자들이 사용하는 React와 Next.js 같은 프레임워크를 나도 사용하고 있다.그러다 문득, 내가 현재 쓰고 있는 기술 스택들이 왜 등장하게 되었는지, 그리고 어떤 문제를 해결하거나 개선했기에 지금까지 널리 사용되고 있는지 궁금해졌다. (재미있게도, 일부는 과거 방식으로 되돌아가는 것처럼 보이기도 한다.)참고로, 이 글에서는 WEB 1.0이나 IE 등장 등 웹의 초기 역사보다는, JSP 등의 백엔드 중심 개발에서 프런트엔드 직군이 본격적으로 생겨난 시점부터 이야기를 시작해 보려고 합니다.프런트엔드 직군의 탄생: 백엔드 중심에서 프런트엔드로초기 웹 개발: 웹 개발 초기에는 프런트엔드와 백엔드의 경계가 불분명했습니다. JSP, PHP, ASP 같은 서버 사이드..