토스 디자인 컨퍼런스 Simplicity 사이트를 개발하며 고민한 내용을 공유합니다.

.css-1vn47db{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;-webkit-flex:none;-ms-flex:none;flex:none;}.css-14on8x8{font-size:17px;letter-spacing:0em;line-height:1.6;font-weight:normal;color:var(

.css-1vn47db{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;-webkit-flex:none;-ms-flex:none;flex:none;}
.css-14on8x8{font-size:17px;letter-spacing:0em;line-height:1.6;font-weight:normal;color:var

Simplicity 4 : 뒤에 개발자 있어요

낯선 서비스에 대한 문제를 발견하고 싶을 땐 어떤 리서치를 해야할까요?

진짜 문제 발견을 위해, 사용자 여정 함께 걸어보기

LLM으로 에러 원인 분석과 해결 방안 제시까지 자동화하고, 팀의 생산성을 향상시킨 이야기를 들려드립니다.

Flowise와 LLM을 활용한 에러 분석 자동화

이번 모닥불에서는 토스 프론트엔드 챕터가 어떻게 코드 리뷰 문화를 활성화했는지 알려드릴게요.

‘고맥락자 코드 리뷰’ 부터 ‘코드스멜 워킹그룹’, ‘가독성 위원회’ 그리고 ‘코드 리뷰 배틀’ 까지실전에 적용해 볼 수 있는 다양한 코드 리뷰 꿀팁들, 지금 바로 공개합니다!

.css-1vn47db{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;-webkit-flex:none;-ms-flex:none;flex:none;}.css-of5acw{margin:24px 0 8px;text-align:center;}.css-oni540{position:relative;width:100%;he

.css-1vn47db{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;-webkit-flex:none;-ms-flex:none;flex:none;}
.css-of5acw{margin:24px 0 8px;text-align:center;}.css-oni540{position:relative;width:100%;h

코드 리뷰할 시간이 어딨어요? 모닥불 | EP.12

AI 시대에 디자이너는 어떤 모습일까요?
한번 쯤 이런 생각 해보지 않으셨나요? UI가 더 이상 필요 없어지거나, 로봇이 모든 일을 대신하는 날이 오면, 디자이너는 어떤 역할을 하게 될까요?

.css-1vn47db{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;-webkit-flex:none;-ms-flex:none;flex:none;}.css-1c1qox8{font-size:30px;letter-spacing:0em;line-height:1.55;font-weight:bold;color:var(-

.css-1vn47db{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;-webkit-flex:none;-ms-flex:none;flex:none;}
.css-1c1qox8{font-size:30px;letter-spacing:0em;line-height:1.55;font-weight:bold;color:var(

AI 시대에 디자이너로 살아남기



주요내용



25년 5월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.


React Compiler RC
useMemo 없이도 성능 최적화를 자동으로 처리해주는 새로운 리액트 컴파일러가 드디어 RC 단계에 도달했다.
proposal-record-tuple is withdrawn
값 기반 데이터 구조 도입을 목표로 했던 R&amp;T가 철회되고, 더 유연한 대안인 Composite 제안이 새롭게 부상 중이다.
Features That Every JavaScript Developer Mus

주요내용





25년 5월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.



React Compiler RC

useMemo 없이도 성능 최적화를 자동으로 처리해주는 새로운 리액트 컴파일러가 드디어 RC 단계에 도달했다.


proposal-record-tuple is withdrawn

값 기반 데이터 구조 도입을 목표로 했던 R&T가 철회되고, 더 유연한 대안인 Composite 제안이 새롭게 부상 중이다.


Features That Every JavaScript Developer Mu

FE News 25년 5월 소식을 전해드립니다!

알고 보면 더 재미있어요. 심플리시티 시즌 4의 흥미로운 제작기를 소개합니다.

Simplicity 4 : AI 아바타가 발표하는 온라인 컨퍼런스 제작기

2,800만 명이 쓰는 앱에서 7,000명의 경험까지 챙기기 위해,  토스는 어떤 노력을 하고 있을까요?

.css-1vn47db{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;-webkit-flex:none;-ms-flex:none;flex:none;}

[Simplicity 4 세션] 진짜 모두를 위한 금융

일하느라 사용자를 만날 시간이 없다면, 점심시간은 어떨까요? 식사하며 사용자의 목소리를 듣는 토스 팀의 이야기를 들려드릴게요.

[Simplicity 4 세션] 모두가 유저를 만나는 순간까지

시각 장애인이 토스를 더 쉽게 쓰려면, 무엇이 달라져야 할까요? 리서치를 통해 얻은 세 가지 인사이트를 공유할게요.

[Simplicity 4 세션] 우리가 몰랐던 시각 장애인의 UX

‘토스트’를 소개합니다. 인간이 3일 걸려 만드는 3D 그래픽을 10초 만에 만든다니, 퀄리티까지 따라올 수 있을까요? 

[Simplicity 4 세션] 토스 그래픽을 10초 만에 그리는 AI

AI는 UX라이터에게 위기이자 기회예요. 다크패턴을 계기로, 라이터에서 프롬프트 엔지니어로 성장한 이야기를 들려드려요.

[Simplicity 4 세션] AI시대에 라이터로 살아남기

각종 법적 제한 때문에 자유롭지 않은 동의 화면 디자인. 관성을 깨면 얼마나 달라질 수 있을까요?

[Simplicity 4 세션] 동의 화면도 간결해질 수 있을까

사용자가 원하는 기능을 잘 찾는지, 정성적인 경험도 이제 수치로 말할 수 있어요. 토스만의 새로운 기준으로요.

[Simplicity 4 세션] 경험을 수치화하는 방법

인터랙션 개발의 매력은 무엇일까요? 아름다움과 감각을 설계하는 세 명의 인터랙션 개발자가 답해드릴게요.

[Simplicity 4 세션] 디자인 조직의 개발자들

토스를 처음 써보는 외국인에게 토스를 어떻게 소개해야 할까? 모두가 감탄한 온보딩, 그 중심에는 인터랙션이 있었어요.

[Simplicity 4 세션] 인터랙션으로 첫 인상 만들기

IT 업계에 3D 그래픽이 넘쳐나는 시대. 토스는 어떻게 '토스다움'을 만들어냈을까요? 그 여정을 보여드려요.

[Simplicity 4 세션] 토스 그래픽 더 토스답게 만들기

스케치, 피그마, 프레이머… 모두 써봤지만 우리에게 딱 맞는 건 없었어요. 그래서 만들었습니다. 토스만의 디자인 툴, 데우스.

[Simplicity 4 세션] 토스가 디자인툴을 만든 이유

토스 디자인 컨퍼런스 Simplicity가 돌아왔어요.

Simplicity 4 : 한 번쯤 이상을 꿈꿔본 모두에게

토스앱의 다양한 광고는 어떤 과정을 거쳐 유저에게 노출될까요?

토스는 어떻게 광고를 보여줄까? 토스애즈 ML 톺아보기

컴퓨팅 성능의 발전에 따라 데이터 통합 프로세스가 전통적인 ETL(추출, 변환, 로드)에서 ELT(추출, 로드, 변환)로 전환되고 있습니다. ETL은 컴퓨팅 성능이 상대적으로 지금처럼 강하지 않았을 때 개발된 개념으로, 데이터의 관점에서 보면 데이터를 먼저 로드한 후 변환하는 것이 성능과 확장성 측면에서 유리합니다.

이에 따라 Apache Iceberg와 같은 오픈 테이블 형식을 비롯하여, 스키마 진화(Schema Evolution)가 가능한 다양한 기술이 등장했습니다. 또한 고성능 OLAP 엔진의 필요성이 더욱 커지면서 St

컴퓨팅 성능의 발전에 따라 데이터 통합 프로세스가 전통적인 ETL(추출, 변환, 로드)에서 ELT(추출, 로드, 변환)로 전환되고 있습니다. ETL은 컴퓨팅 성능이 상대적으로 지금처럼 강하지 않았을 때 개발된 개념으로, 데이터의 관점에서 보면 데이터를 먼저 로드한 후 변환하는 것이 성능과 확장성 측면에서 유리합니다.


이에 따라 Apache Iceberg와 같은 오픈 테이블 형식을 비롯하여, 스키마 진화(Schema Evolution)가 가능한 다양한 기술이 등장했습니다. 또한 고성능 OLAP 엔진의 필요성이 더욱 커지면서 S

StarRocks의 도입 배경과 성능 최적화

토스 쇼핑은 어떻게 수백만 사용자에게 개인화된 상품 추천을 제공할까요? 그 접근법을 소개해 드릴게요.

🛒 토스 쇼핑 추천 시스템: 수백만 사용자와 상품을 잇는 멀티 스테이지 접근법

원문: You should know this before choosing Next.js…


원문: You should know this before choosing Next.js

프로젝트의 기술 스택을 선택하는 것은 중요하고 중대한 결정입니다. 특히 기업 환경에서는 프로젝트의 로드맵, 개발 속도, 결과물의 품질, 나아가 행복한 팀을 구성하고 유지하는 능력에까지 장기적인 영향을 미치는 다년간의 노력을 수반하곤 합니다.
오픈소스 소프트웨어 모델은 이에 대한 근본적인 해답입니다. 오픈소스로 개발된 소프트웨어를 사용함으로써 누구든지 자신의 사용 사례에 맞게 확장하거나 수정할 수 있습니다. 더 중요한 것은, 오픈소스 소프트웨어

원문: You should know this before choosing Next.js
프로젝트의 기술 스택을 선택하는 것은 중요하고 중대한 결정입니다. 특히 기업 환경에서는 프로젝트의 로드맵, 개발 속도, 결과물의 품질, 나아가 행복한 팀을 구성하고 유지하는 능력에까지 장기적인 영향을 미치는 다년간의 노력을 수반하곤 합니다.
오픈소스 소프트웨어 모델은 이에 대한 근본적인 해답입니다. 오픈소스로 개발된 소프트웨어를 사용함으로써 누구든지 자신의 사용 사례에 맞게 확장하거나 수정할 수 있습니다. 더 중요한 것은, 오픈소스 소프트웨어의 

(번역) Next.js를 선택하기 전에 반드시 알아야 할 것들


 
안녕하세요! 네이버 프런트엔드 개발자 모임(H26y &amp; FE News)입니다.
국내 프런트엔드 러버 여러분들 반갑습니다.

이 설문조사는 국내 개발자들이 어떤 FE/JS 환경에서 개발하고 있는지를 파악하고, 이를 공유해 국내 생태계에 도움을 주고자 기획하게 되었습니다.

설문조사의 주요 목적은 다음과 같습니다.


어떤 기술 영역에서 집중이 필요한지 판단할 수 있는 지표를 공유  
국내 개발자들의 FE/JS 환경을 확인해 기술스택 선택을 도와주는 역할 
여러분의 소중한 답변은 국내 생태계 발전에 큰

안녕하세요! 네이버 프런트엔드 개발자 모임(H26y & FE News)입니다.

국내 프런트엔드 러버 여러분들 반갑습니다.


이 설문조사는 국내 개발자들이 어떤 FE/JS 환경에서 개발하고 있는지를 파악하고, 이를 공유해 국내 생태계에 도움을 주고자 기획하게 되었습니다.


설문조사의 주요 목적은 다음과 같습니다.



어떤 기술 영역에서 집중이 필요한지 판단할 수 있는 지표를 공유  

국내 개발자들의 FE/JS 환경을 확인해 기술스택 선택을 도와주는 역할 

여러분의 소중한 답변은 국내 생태계 발전에 큰 기여

[State of FE·JS Korea 2025] 설문조사 안내

네이버페이 차세대 아키텍처 개편을 위한 Plasma 프로젝트가 마무리 단계에 접어들면서, 안정적인 운영을 위한 최종 작업을 진행하고 있습니다.

이 글에서는 네이버페이 주문의 메인 DB를 Oracle에서 사내 분산 DB 플랫폼인 nBase-T로 변경한 이후에 Oracle을 비동기 복제 방식으로 전환하는 과정에서 발생한 성능 문제와 서비스 개발자의 시선에서 해결 과정에 참여한 경험에 대하여 공유하고자 합니다.

이슈

서비스 호출량이 많아지는 상황에서 nBase-T → Oracle 데이터 동기화 처리 지연 현상이 관측되었습

네이버페이 차세대 아키텍처 개편을 위한 Plasma 프로젝트가 마무리 단계에 접어들면서, 안정적인 운영을 위한 최종 작업을 진행하고 있습니다.


이 글에서는 네이버페이 주문의 메인 DB를 Oracle에서 사내 분산 DB 플랫폼인 nBase-T로 변경한 이후에 Oracle을 비동기 복제 방식으로 전환하는 과정에서 발생한 성능 문제와 서비스 개발자의 시선에서 해결 과정에 참여한 경험에 대하여 공유하고자 합니다.


이슈


서비스 호출량이 많아지는 상황에서 nBase-T → Oracle 데이터 동기화 처리 지연 현상이 관측

CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제

서버는 365일 1분 1초를 쉬지 않고 작동되므로 서버실의 냉방이 제대로 되지 않으면 온도가 계속 올라가게 됩니다. 서버실의 온도가 상승하면 서버의 성능이 제한되어 점차 속도가 느려지다가 결국 서버가 작동하지 않는 상황에 이를 수 있습니다. 서버실의 최적 온도는 22~26℃ 정도입니다. 이 최적의 온도를 유지하기 위해 공조 시스템은 서버실에 공급하는 공기의 온습도, 청정도, 기류 등을 조절합니다. 

공조 시스템은 열원설비, 공기조화기, 자동제어설비 등으로 이루어져 있습니다. 전통적인 데이터센터에서 공조 시스템은 냉동기(가정으로

서버는 365일 1분 1초를 쉬지 않고 작동되므로 서버실의 냉방이 제대로 되지 않으면 온도가 계속 올라가게 됩니다. 서버실의 온도가 상승하면 서버의 성능이 제한되어 점차 속도가 느려지다가 결국 서버가 작동하지 않는 상황에 이를 수 있습니다. 서버실의 최적 온도는 22~26℃ 정도입니다. 이 최적의 온도를 유지하기 위해 공조 시스템은 서버실에 공급하는 공기의 온습도, 청정도, 기류 등을 조절합니다. 


공조 시스템은 열원설비, 공기조화기, 자동제어설비 등으로 이루어져 있습니다. 전통적인 데이터센터에서 공조 시스템은 냉동기(가정으

데이터센터 각 세종의 스마트 공조 설루션, NAMU III



주요내용



25년 4월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.


A Categorical Archive of ChatGPT Failures
ChatGPT와 같은 대형 언어 모델의 한계를 분석한 내용이다. 논리는 크게 11개의 실패 유형으로 구분되며, 논리적 추론, 수학적 계산, 사실 오류, 편견 및 차별, 코딩 오류 등 다양한 영역에서 제한이 발견된다.
프롬프트 엔지니어링 가이드
프롬프트 엔지니어링은 다양한 애플리케이션과 연구 주제에 언어 모델(LMs)을 효율적으로 사용하기 위해

주요내용





25년 4월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.



A Categorical Archive of ChatGPT Failures

ChatGPT와 같은 대형 언어 모델의 한계를 분석한 내용이다. 논리는 크게 11개의 실패 유형으로 구분되며, 논리적 추론, 수학적 계산, 사실 오류, 편견 및 차별, 코딩 오류 등 다양한 영역에서 제한이 발견된다.


프롬프트 엔지니어링 가이드

프롬프트 엔지니어링은 다양한 애플리케이션과 연구 주제에 언어 모델(LMs)을 효율적으로 사용하기

FE News 25년 4월 소식을 전해드립니다!

코드 작성에 AI의 도움을 받을 수 있는 가장 유명한 도구 중 하나로, GitHub이 2021년 발표한 GitHub Copilot이 있습니다. 2024년 12월 GitHub Copilot for VS Code 무료 플랜을 제공하기 시작해,
제한적(2k/월 코드 어시스트, 50건/월 채팅)이긴 하지만 누구나 활용할 수 있게 되었습니다.

그런데 Copilot의 도움을 받으려면 프롬프트로 질의를 작성해야 하며, Copilot이 각자의 환경에 맞춰 답변하게 하려면 매번 프롬프트로 상황을 전달해야 합니다. 이는 매우 귀찮고 불편한 작

코드 작성에 AI의 도움을 받을 수 있는 가장 유명한 도구 중 하나로, GitHub이 2021년 발표한 GitHub Copilot이 있습니다. 2024년 12월 GitHub Copilot for VS Code 무료 플랜을 제공하기 시작해,
제한적(2k/월 코드 어시스트, 50건/월 채팅)이긴 하지만 누구나 활용할 수 있게 되었습니다.


그런데 Copilot의 도움을 받으려면 프롬프트로 질의를 작성해야 하며, Copilot이 각자의 환경에 맞춰 답변하게 하려면 매번 프롬프트로 상황을 전달해야 합니다. 이는 매우 귀찮고 불편한 

나만의 Visual Studio Code Copilot 지침 만들고 활용하기

안녕하세요. 지그재그 서비스팀 로빈입니다.🙂
오늘은 저희 팀에서 관리하고 있는 상품상세페이지(Product Detail Page. 이하 PDP) 서비스의 프로젝트 아키텍처에 대해 간단히 소개해보려고 합니다.
PDP 서비스는 2024년부터 &ldquo;Domain-Driven 헥사고날 아키텍처&quot;의 프로젝트 구조를 띠고 있는데요, 이렇게 운영한지 어느덧 1년을 향해 가고 있습니다.
국내외 여러 테크 블로그들을 돌아다녀보면 헥사고날 아키텍처란 무엇인지, DDD와 애그리거트는 무엇인지, 이미 그 개념들에 대해 충분히 잘 설명된 

안녕하세요. 지그재그 서비스팀 로빈입니다.🙂
오늘은 저희 팀에서 관리하고 있는 상품상세페이지(Product Detail Page. 이하 PDP) 서비스의 프로젝트 아키텍처에 대해 간단히 소개해보려고 합니다.
PDP 서비스는 2024년부터 “Domain-Driven 헥사고날 아키텍처"의 프로젝트 구조를 띠고 있는데요, 이렇게 운영한지 어느덧 1년을 향해 가고 있습니다.
국내외 여러 테크 블로그들을 돌아다녀보면 헥사고날 아키텍처란 무엇인지, DDD와 애그리거트는 무엇인지, 이미 그 개념들에 대해 충분히 잘 설명된 자료들을 접할 수 있

코드 사례로 보는 Domain-Driven 헥사고날 아키텍처

프로그래밍을 하다 보면 테스트의 필요성을 통감하는 순간이 찾아옵니다.
하지만 테스트를 꾸준히 작성하는 팀은 많지 않습니다. 만일 팀의 룰로 인해 강제로 테스트를 작성하고 있더라도, 업계의 구루가 말하는 TDD의 이점은 별로 와닿지 않고, 프로그램 코드보다 테스트 코드를 작성하는 데 더 많은 시간을 소모하고 있는 자신을 보며 자괴감을 느끼고 있을지도 모릅니다.

'테스트하기 좋은 코드가 좋은 코드다'라는 말을 들어보았을 것입니다. 이 격언에는, 프로그램 코드와 테스트 코드는 서로 상호작용하며, 프로그램 코드가 나쁘면 테스트 코드

프로그래밍을 하다 보면 테스트의 필요성을 통감하는 순간이 찾아옵니다.
하지만 테스트를 꾸준히 작성하는 팀은 많지 않습니다. 만일 팀의 룰로 인해 강제로 테스트를 작성하고 있더라도, 업계의 구루가 말하는 TDD의 이점은 별로 와닿지 않고, 프로그램 코드보다 테스트 코드를 작성하는 데 더 많은 시간을 소모하고 있는 자신을 보며 자괴감을 느끼고 있을지도 모릅니다.


'테스트하기 좋은 코드가 좋은 코드다'라는 말을 들어보았을 것입니다. 이 격언에는, 프로그램 코드와 테스트 코드는 서로 상호작용하며, 프로그램 코드가 나쁘면 테스트 코

테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)

연구실의 기술은 서비스나 상품을 통해 세상과 만나기를 기다립니다. 제가 속한 네이버랩스의 디지털 트윈(Digital Twin) 기술도 마찬가지입니다. 디지털 트윈은 현실 공간을 복제하여 가상 환경에서 3차원으로 동일하게 구현하는 기술로, 그간에는 주로 로봇과 자율주행의 핵심 기술 중 하나였습니다.

이 기술을 다양한 네이버 서비스에 확대 적용하고자 해왔는데, 그중 하나가 지난 해 12월 오픈한 네이버 지도의 거리뷰3D입니다. 이 글에서는 거리뷰3D에 네이버랩스의 디지털 트윈 기술이 도입된 배경과 실제 제작 프로세스를 간략히 소개

연구실의 기술은 서비스나 상품을 통해 세상과 만나기를 기다립니다. 제가 속한 네이버랩스의 디지털 트윈(Digital Twin) 기술도 마찬가지입니다. 디지털 트윈은 현실 공간을 복제하여 가상 환경에서 3차원으로 동일하게 구현하는 기술로, 그간에는 주로 로봇과 자율주행의 핵심 기술 중 하나였습니다.


이 기술을 다양한 네이버 서비스에 확대 적용하고자 해왔는데, 그중 하나가 지난 해 12월 오픈한 네이버 지도의 거리뷰3D입니다. 이 글에서는 거리뷰3D에 네이버랩스의 디지털 트윈 기술이 도입된 배경과 실제 제작 프로세스를 간략히 소

네이버 거리뷰3D, 디지털 트윈을 곁들인

로그 모니터링 시스템은 서비스 운영을 위해서 반드시 필요한 시스템입니다. 로그 모니터링 시스템 구축에는 인덱스 기반의 빠른 검색을 제공하는 검색 엔진인 Elasticsearch가 널리 사용됩니다. 네이버도 Elasticsearch 기반의 로그 모니터링 시스템을 구축했으며, 수천 대의 서버로 수 페타바이트 규모의 로그 데이터를 저장하고 있습니다. 최근 들어 서비스 규모가 확장되고 저장해야 하는 로그 데이터의 규모와 트래픽 양이 급속도로 증가하면서 Elasticsearch 기반의 로그 모니터링 시스템은 비용 문제와 더불어 확장성 문제에

NELO Alaska: 대용량 로그 데이터 저장을 위한 Apache Iceberg 도입기

네이버 검색은 사용자 중심의 빠르고 원활한 검색 경험을 제공하기 위해 지속적으로 웹 성능을 모니터링하고 최적화하고 있습니다. 2024년에는 특히 LCP(Largest Contentful Paint)를 핵심 성능 지표로 삼아 여러 최적화 작업을 진행하였으며, 그 결과 네이버 검색의 웹 성능은 목표로 삼았던 구글 글로벌 LCP와 유사한 수준인 LCP p95 기준 2.31초를 달성할 수 있었습니다. 

또한 2024년에 새로운 서치 피드 서비스가 도입되면서 기존의 웹 기반 성능 지표로는 측정하기 어려운 무한 스크롤 영역을 측정할 수 

네이버 검색은 사용자 중심의 빠르고 원활한 검색 경험을 제공하기 위해 지속적으로 웹 성능을 모니터링하고 최적화하고 있습니다. 2024년에는 특히 LCP(Largest Contentful Paint)를 핵심 성능 지표로 삼아 여러 최적화 작업을 진행하였으며, 그 결과 네이버 검색의 웹 성능은 목표로 삼았던 구글 글로벌 LCP와 유사한 수준인 LCP p95 기준 2.31초를 달성할 수 있었습니다. 


또한 2024년에 새로운 서치 피드 서비스가 도입되면서 기존의 웹 기반 성능 지표로는 측정하기 어려운 무한 스크롤 영역을 측정할 수

2024 네이버 통합검색의 웹 성능 리뷰

기존 호텔 검색에서는 블로그에서 장소(Point of Interest, POI) 정보를 추출하고 다국어 음차 변환 및 번역을 수행하며 검색 키워드와 스니펫을 자동 생성하는 과정에서 대형 언어 모델(Large Language Model, 이하 LLM)을 활용했습니다. 하지만 LLM은 강력한 성능을 제공하는 대신 높은 연산 비용과 긴 응답 시간으로 인해 실시간 검색 서비스에 적용하기 어려웠습니다. 반면, sLLM(small large language model)은 빠르고 효율적이지만 성능이 낮아 검색 품질이 저하될 우려가 있었습니다.

호텔 검색, 어떻게 달라졌을까요? 2편 - 지식 증류

호텔 검색을 고도화하기 위해서 검색 키워드 동의어·유의어 보강, 검색 문서 커버리지 확대, 질의와 연관된 콘텐츠 수급 기술이 필요했습니다. 이를 해결하기 위해 플레이스 AI 팀은 다국어 음차 변환 및 번역 모델 → POI 매칭 → 검색 키워드 및 스니펫 추출의 세 가지 단계를 포함한 프로젝트를 진행했습니다.


  POI: 사용자가 관심을 가질 만한 장소(Point of Interest)를 의미하며, 레스토랑, 호텔, 관광지, 쇼핑몰 등 다양한 유형의 장소를 포함합니다. 네이버 플레이스에서는 이러한 POI 정보를 체계적으로 관

호텔 검색을 고도화하기 위해서 검색 키워드 동의어·유의어 보강, 검색 문서 커버리지 확대, 질의와 연관된 콘텐츠 수급 기술이 필요했습니다. 이를 해결하기 위해 플레이스 AI 팀은 다국어 음차 변환 및 번역 모델 → POI 매칭 → 검색 키워드 및 스니펫 추출의 세 가지 단계를 포함한 프로젝트를 진행했습니다.



  
POI: 사용자가 관심을 가질 만한 장소(Point of Interest)를 의미하며, 레스토랑, 호텔, 관광지, 쇼핑몰 등 다양한 유형의 장소를 포함합니다. 네이버 플레이스에서는 이러한 POI 정보를 체계적으로

호텔 검색, 어떻게 달라졌을까요? 3편 - 검색 시스템

검색 서비스는 사용자의 다양한 질의에 대응해야 하며, 새로운 검색 키워드가 지속적으로 추가됩니다. 특히, 이미지 검색에서는 단순한 키워드 기반 매칭이 아니라, 검색 의도에 맞춰 가장 적합한 이미지를 찾아 제공하는 것이 중요합니다.

기존에 공개된 CLIP(Contrastive Language-Image Pre-training) 모델은 일반적인 Text-Image Retrieval에는 활용될 수 있었지만, 플레이스(명소, 호텔, 관광지 등) 도메인에 최적화되지 않아 검색 품질이 충분하지 않았습니다. 특히, 대표 이미지가 특정 이미

검색 서비스는 사용자의 다양한 질의에 대응해야 하며, 새로운 검색 키워드가 지속적으로 추가됩니다. 특히, 이미지 검색에서는 단순한 키워드 기반 매칭이 아니라, 검색 의도에 맞춰 가장 적합한 이미지를 찾아 제공하는 것이 중요합니다.


기존에 공개된 CLIP(Contrastive Language-Image Pre-training) 모델은 일반적인 Text-Image Retrieval에는 활용될 수 있었지만, 플레이스(명소, 호텔, 관광지 등) 도메인에 최적화되지 않아 검색 품질이 충분하지 않았습니다. 특히, 대표 이미지가 특정 이

호텔 검색, 어떻게 달라졌을까요? 4편 - 이미지 검색

네이버는 호텔 검색이 다루는 범위를 대폭 확대하고 더 풍성한 결과를 제공하기 위해, 검색 엔진을 전환하고 대형 언어 모델(Large Language Model, 이하 LLM)을 도입했습니다. 그 결과 검색 품질과 사용자 경험 모두에서 큰 변화를 이끌어냈습니다. 이 글에서는 기존 문제점과 이를 해결하기 위한 접근법, 그리고 얻은 결과를 실제 사례와 함께 살펴보겠습니다.

문제와 해결

기존 호텔 검색 엔진은 짧은 질의에는 강하지만 다루는 범위는 좁았기에 새로운 유형의 질의 대응이 필요했습니다. 이를 위해 '호텔 검색 의도가 있

네이버는 호텔 검색이 다루는 범위를 대폭 확대하고 더 풍성한 결과를 제공하기 위해, 검색 엔진을 전환하고 대형 언어 모델(Large Language Model, 이하 LLM)을 도입했습니다. 그 결과 검색 품질과 사용자 경험 모두에서 큰 변화를 이끌어냈습니다. 이 글에서는 기존 문제점과 이를 해결하기 위한 접근법, 그리고 얻은 결과를 실제 사례와 함께 살펴보겠습니다.


문제와 해결


기존 호텔 검색 엔진은 짧은 질의에는 강하지만 다루는 범위는 좁았기에 새로운 유형의 질의 대응이 필요했습니다. 이를 위해 '호텔 검색 의도가

호텔 검색, 어떻게 달라졌을까요? 1편 - 문제와 해결



주요내용



25년 3월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.


2024 Frameworks Year in Review
Netlify의 웹덕후들이 2024년의 흐름 그리고 25년도에 대한 기대를 정리해 줍니다.
How long is a second in JavaScript?
JavaScript에서 '초'의 길이와 시간 측정의 역사와 과학적 배경을 탐구해 봅니다.
Optimizing the Critical Rendering Path
웹 페이지의 초기 렌더링을 지연시키는 주요 자

주요내용





25년 3월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.



2024 Frameworks Year in Review

Netlify의 웹덕후들이 2024년의 흐름 그리고 25년도에 대한 기대를 정리해 줍니다.


How long is a second in JavaScript?

JavaScript에서 '초'의 길이와 시간 측정의 역사와 과학적 배경을 탐구해 봅니다.


Optimizing the Critical Rendering Path

웹 페이지의 초기 렌더링을 지연시키

FE News 25년 3월 소식을 전해드립니다!



주요내용



25년 2월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.


Cascading Spy Sheets: Exploiting the Complexity of Modern CSS for Email and Browser Fingerprinting
Javascript와 Cookie 없이 CSS만으로 브라우저 지문 채취의 가능함이 증명되었습니다
The Ai-Assisted Developer Workflow: Build Faster and Smarter Today
AI를 활용한 다양한 개발

주요내용





25년 2월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.



Cascading Spy Sheets: Exploiting the Complexity of Modern CSS for Email and Browser Fingerprinting

Javascript와 Cookie 없이 CSS만으로 브라우저 지문 채취의 가능함이 증명되었습니다


The Ai-Assisted Developer Workflow: Build Faster and Smarter Today

AI를 활용한 다양한

FE News 25년 2월 소식을 전해드립니다!

이 글에서는 리눅스 커널 기능인 Control Groups(이하 cgroups)에 대해서 간단히 알아보고, Kubernetes(이하 k8s)가 cgroups를 어떻게 사용하는지 살펴보겠습니다. Kubernetes와 cgroups 간의 관계를 이해하는 데 도움이 되기를 바랍니다.

cgroups란

cgroups는 시스템에서 실행되는 여러 프로세스를 그룹으로 묶고, 각 그룹이 사용할 수 있는 CPU, 메모리, I/O, 네트워크 등의 자원 사용을 제한하고 격리하는 리눅스 커널 기능입니다.

이 글에서는 여러 자원 중 k8s와

이 글에서는 리눅스 커널 기능인 Control Groups(이하 cgroups)에 대해서 간단히 알아보고, Kubernetes(이하 k8s)가 cgroups를 어떻게 사용하는지 살펴보겠습니다. Kubernetes와 cgroups 간의 관계를 이해하는 데 도움이 되기를 바랍니다.


cgroups란


cgroups는 시스템에서 실행되는 여러 프로세스를 그룹으로 묶고, 각 그룹이 사용할 수 있는 CPU, 메모리, I/O, 네트워크 등의 자원 사용을 제한하고 격리하는 리눅스 커널 기능입니다.


이 글에서는 여러 자원 중 k

리눅스의 Control Groups 기능이 Kubernetes에 어떻게 적용되는지 살펴보기

Noir는 Go로 작성한 개별 데이터 특화 검색 엔진으로, 메일처럼 사용자마다 데이터가 분리된 서비스에 효과적입니다. 대표적으로 네이버 메일, 메시지 검색 서비스 등이 Noir를 사용하고 있습니다.

수년간 Noir를 개발 및 운영하는 동안 Noir 서버 메모리 사용량이 시간이 갈수록 천천히 증가하는 현상이 자주 관찰되었고 이를 해결하기 위해 큰 노력을 기울였습니다.

Go는 가비지 컬렉터(GC)가 있는 언어로, 개발자가 메모리 관리에 크게 신경 쓰지 않아도 된다는 장점이 있습니다. 하지만 개발자가 메모리 관리에 개입할 수 

Noir는 Go로 작성한 개별 데이터 특화 검색 엔진으로, 메일처럼 사용자마다 데이터가 분리된 서비스에 효과적입니다. 대표적으로 네이버 메일, 메시지 검색 서비스 등이 Noir를 사용하고 있습니다.


수년간 Noir를 개발 및 운영하는 동안 Noir 서버 메모리 사용량이 시간이 갈수록 천천히 증가하는 현상이 자주 관찰되었고 이를 해결하기 위해 큰 노력을 기울였습니다.


Go는 가비지 컬렉터(GC)가 있는 언어로, 개발자가 메모리 관리에 크게 신경 쓰지 않아도 된다는 장점이 있습니다. 하지만 개발자가 메모리 관리에 개입할 

Go GC를 너무 믿지 마세요 - 메모리 누수 탐지와 GC 주기 조절

안녕하세요! 앱개발팀의 레이몬드입니다. 2024년 한 해동안 모듈화를 경험하면서 느낀점들과 후회하는 것들을 글로 써보고자 합니다.
2023년 초부터 논의해 오던 모듈화를 2024년에 본격적으로 진행했고 지금도 모듈화 작업을 이어 나가고 있습니다. 1년동안 진행한 작업들을 되돌아 보니 생각보다는 많은 작업들을 진행했더라구요. 많은 모듈화 관련 포스트들이 모듈화의 필요성에 대해 다루고 있어서 비슷한 내용보다는 다른 관점인 모듈화를 진행하면서 느낀점들과 아쉬웠던 것들을 정리하고자 합니다.

1년동안의 iOS 모듈화 진행기

원문: Revealed: React’s experimental animations API 12년(!) 전 처음 출시된 이래로 리액트의 API…


원문: Revealed: React’s experimental animations API

12년(!) 전 처음 출시된 이래로 리액트의 API에는 눈에 띄는 애니메이션 공백이 존재했습니다.
그동안 뷰와 스벨트 같은 가장 가까운 경쟁사들은 광범위하진 않지만 애니메이션을 조금 더 쉽게 만들어주는 API를 도입했습니다. 반면에 리액트 개발자는 Motion for React, React Spring 등과 같은 써드파티 라이브러리에 의존해야 했습니다.
그러나 이제 상황이 달라졌습니다.
리액트가 드디어 첫 번째 애니메이션 API를 도입합니다

원문: Revealed: React’s experimental animations API
12년(!) 전 처음 출시된 이래로 리액트의 API에는 눈에 띄는 애니메이션 공백이 존재했습니다.
그동안 뷰와 스벨트 같은 가장 가까운 경쟁사들은 광범위하진 않지만 애니메이션을 조금 더 쉽게 만들어주는 API를 도입했습니다. 반면에 리액트 개발자는 Motion for React, React Spring 등과 같은 써드파티 라이브러리에 의존해야 했습니다.
그러나 이제 상황이 달라졌습니다.
리액트가 드디어 첫 번째 애니메이션 API를 도입합니다. 

(번역) 리액트의 실험적인 애니메이션 API 공개

네이버 검색 FE 시스템 구축 과정에서 저희는 다음과 같은 문제에 직면했습니다.



첫째, 유사하지만 영역이 다른 경우 비슷한 작업을 반복하는 경우가 있었습니다.

검색의 각 영역은 마이크로서비스 아키텍처(MSA)로 이루어져 있으며 클라이언트 코드 역시 영역별로 관리되고 있었습니다. 이로 인해 영역 간 동일한 유형의 작업을 반복해야 했고, 경험이 축적되기보다는 업무의 성장이 저해되는 결과를 초래했습니다.

둘째, 유사한 UI를 매번 새로 개발해야 하는 비효율성이 존재했습니다.

코드의 재활용이 어려워서 유사한 패

네이버 검색 FE 시스템 구축 과정에서 저희는 다음과 같은 문제에 직면했습니다.





첫째, 유사하지만 영역이 다른 경우 비슷한 작업을 반복하는 경우가 있었습니다.


검색의 각 영역은 마이크로서비스 아키텍처(MSA)로 이루어져 있으며 클라이언트 코드 역시 영역별로 관리되고 있었습니다. 이로 인해 영역 간 동일한 유형의 작업을 반복해야 했고, 경험이 축적되기보다는 업무의 성장이 저해되는 결과를 초래했습니다.


둘째, 유사한 UI를 매번 새로 개발해야 하는 비효율성이 존재했습니다.


코드의 재활용이 어려워서 

[DAN 24] 데이터 기반으로 지속 성장이 가능한 네이버 검색 FE 시스템 구축하기

원문: How React Compiler Performs on Real Code 리액트 컴파일러가 초기 로드 및 인터랙션 성능에 미치는 영향을 수치와 함께 살펴봅니다. 이 글에서 사용된 수치는 실제 앱에서 측정되었습니다. 유튜브: How React…


원문: How React Compiler Performs on Real Code

리액트 컴파일러가 초기 로드 및 인터랙션 성능에 미치는 영향을 수치와 함께 살펴봅니다. 이 글에서 사용된 수치는 실제 앱에서 측정되었습니다.
유튜브: How React Compiler Performs On Real Code

      
    
  
  
    
이 글은 제가 “React Advanced” 컨퍼런스에서 발표한 내용을 기반으로 구성되었습니다. 글보다 영상을 선호하신다면 How React Compiler Performs On Reac

원문: How React Compiler Performs on Real Code
리액트 컴파일러가 초기 로드 및 인터랙션 성능에 미치는 영향을 수치와 함께 살펴봅니다. 이 글에서 사용된 수치는 실제 앱에서 측정되었습니다.
유튜브: How React Compiler Performs On Real Code

      
    
  
  
    
이 글은 제가 “React Advanced” 컨퍼런스에서 발표한 내용을 기반으로 구성되었습니다. 글보다 영상을 선호하신다면 How React Compiler Performs On React 

(번역) 실제 코드에서 리액트 컴파일러의 성능

안녕하세요, 카카오스타일 지그재그 서비스 FE팀의 제이슨입니다.
2023년 초, 저희 팀은 비즈니스와 더불어 기술적인 개선이 필요하다는 것을 느꼈습니다. 그중에서도 특히 여러 지면에서 독립적으로 관리되고 있던 상품 카드 컴포넌트의 일원화 작업이 중요하게 여겨졌고. 이 문제를 해결하기 위해서는 단순 리팩토링을 넘어, 팀 전체의 UI/UX를 통합적으로 관리할 수 있는 디자인 시스템의 재구축이 필요하다고 판단했습니다.

프론트엔드팀의 디자인 시스템 재구축기

원문: How we shrunk our Javascript monorepo git size by 94% 이건 낚시가 아닙니다. 진짜로 해냈습니다! 우리는 마이크로소프트에서 1JS…


원문: How we shrunk our Javascript monorepo git size by 94%

이건 낚시가 아닙니다. 진짜로 해냈습니다! 우리는 마이크로소프트에서 1JS라고 부르는 대규모 자바스크립트 모노레포에서 작업하고 있습니다. 이는 단순한 GB 크기의 문제가 아니라, 코드의 양과 기여된 작업의 규모 면에서도 방대한 양을 자랑합니다. 최근에는 월간 활동 사용자가 1,000명을 넘었고, 약 2,500개의 패키지와 2천만 줄의 코드가 있습니다! 제가 최근에 저장소를 복제했을 때 크기가 무려 178GB였습니다.

이렇게 

원문: How we shrunk our Javascript monorepo git size by 94%
이건 낚시가 아닙니다. 진짜로 해냈습니다! 우리는 마이크로소프트에서 1JS라고 부르는 대규모 자바스크립트 모노레포에서 작업하고 있습니다. 이는 단순한 GB 크기의 문제가 아니라, 코드의 양과 기여된 작업의 규모 면에서도 방대한 양을 자랑합니다. 최근에는 월간 활동 사용자가 1,000명을 넘었고, 약 2,500개의 패키지와 2천만 줄의 코드가 있습니다! 제가 최근에 저장소를 복제했을 때 크기가 무려 178GB였습니다.

이렇게 큰 

(번역) 자바스크립트 모노레포의 깃 용량을 94% 줄인 방법

원문: Optimising for High Latency Environments 지난주에 CrUX에 새롭게 포함된 RTT…


원문: Optimising for High Latency Environments

지난주에 CrUX에 새롭게 포함된 RTT 데이터 항목에 대해 링크드인에 짧은 업데이트를 게시했습니다. 간단히 읽어보시면 도움이 될 것입니다.
크롬은 최근 크롬 사용자 경험 보고서(CrUX)에 왕복 시간(RTT) 데이터를 추가하기 시작했습니다. 이는 방문자들의 네트워크 토폴로지와 높은 지연 시간이 있는 지역에서 우리가 얼마나 영향을 받을 수 있는지에 대한 흥미로운 인사이트를 제공합니다.
RTT란 무엇인가요?
왕복 시간(RTT)은 기본적으로 지연 시간을

원문: Optimising for High Latency Environments
지난주에 CrUX에 새롭게 포함된 RTT 데이터 항목에 대해 링크드인에 짧은 업데이트를 게시했습니다. 간단히 읽어보시면 도움이 될 것입니다.
크롬은 최근 크롬 사용자 경험 보고서(CrUX)에 왕복 시간(RTT) 데이터를 추가하기 시작했습니다. 이는 방문자들의 네트워크 토폴로지와 높은 지연 시간이 있는 지역에서 우리가 얼마나 영향을 받을 수 있는지에 대한 흥미로운 인사이트를 제공합니다.

RTT란 무엇인가요?
왕복 시간(RTT)은 기본적으로 지연 시간을 

(번역) 지연 시간이 긴 환경 최적화하기

지그재그는 상품 판매를 촉진하기 위해 이벤트나 기획전을 주요 마케팅 수단으로 활용합니다. 기획전은 한정된 기간 동안 고객에게 특정 상품 정보와 추가적인 할인 혜택을 명확하게 제시하여 판매를 유도하는 역할을 합니다. 따라서 다양한 기획전을 지속적으로 발행해 고객의 관심을 유도하고, 브랜드 충성도를 높이며, 구매율을 증가시키고 있습니다. 또한, 다양한 테마와 카테고리별 기획전을 통해 고객의 소비 패턴과 선호도에 맞춘 맞춤형 쇼핑 경험을 제공합니다. 이러한 전략은 이커머스 사이트의 경쟁력을 강화하고 지속적인 성장을 도모하는 데 중요한 역

기획전 애니메이션 모듈 개발

원문 : An SSR Performance Showdown 💡 노트: 첫 번째 버전의 벤치마크에서 몇 가지 실수가 있었으며, 이는 Theo Browne의 이 트윗에 요약되어 있습니다. 먼저 이러한 오류에 대해 사과드리며, Rich Harris…


원문 : An SSR Performance Showdown


💡 노트: 첫 번째 버전의 벤치마크에서 몇 가지 실수가 있었으며, 이는 Theo Browne의 이 트윗에 요약되어 있습니다. 먼저 이러한 오류에 대해 사과드리며, Rich Harris, Ryan Carniato, Dan Abramov, Balázs Németh, Dominic Gannaway의 수정에 대해 진심으로 감사의 말씀을 전합니다. 또한 Preact 버전에 기여해주신 Jovi De Croock에게도 감사를 표합니다.

서버 사이드 렌더링(SSR)은 Node.j

원문 : An SSR Performance Showdown
💡 노트: 첫 번째 버전의 벤치마크에서 몇 가지 실수가 있었으며, 이는 Theo Browne의 이 트윗에 요약되어 있습니다. 먼저 이러한 오류에 대해 사과드리며, Rich Harris, Ryan Carniato, Dan Abramov, Balázs Németh, Dominic Gannaway의 수정에 대해 진심으로 감사의 말씀을 전합니다. 또한 Preact 버전에 기여해주신 Jovi De Croock에게도 감사를 표합니다.
서버 사이드 렌더링(SSR)은 Node.js로 고

(번역) SSR 성능 대결

원문 : Flexible network data preloading in large SPAs 주의: 이 글은 클라이언트 사이드에서 렌더링하는 SPA의 성능을 개선하기 위한 맞춤형 솔루션에 중점을 둡니다. Next.js, Remix…


원문 : Flexible network data preloading in large SPAs


주의: 이 글은 클라이언트 사이드에서 렌더링하는 SPA의 성능을 개선하기 위한 맞춤형 솔루션에 중점을 둡니다. Next.js, Remix와 같은 프레임워크를 사용 중이라면, 이러한 최적화는 자동으로 처리되는 경우가 많습니다 :)

제 경험상으로 클라이언트 사이드 렌더링을 구현할 때 중요한 최적화 중 하나는 페이지 로드 시 네트워크 데이터를 미리 로딩하는 것입니다. 제가 근무했던 세 회사에서 경험한 바로는, 대규모 SPA는 일반적으로 페

원문 : Flexible network data preloading in large SPAs
주의: 이 글은 클라이언트 사이드에서 렌더링하는 SPA의 성능을 개선하기 위한 맞춤형 솔루션에 중점을 둡니다. Next.js, Remix와 같은 프레임워크를 사용 중이라면, 이러한 최적화는 자동으로 처리되는 경우가 많습니다 :)
제 경험상으로 클라이언트 사이드 렌더링을 구현할 때 중요한 최적화 중 하나는 페이지 로드 시 네트워크 데이터를 미리 로딩하는 것입니다. 제가 근무했던 세 회사에서 경험한 바로는, 대규모 SPA는 일반적으로 페이지 로

(번역) 대규모 SPA에서 유연하게 네트워크 데이터 미리 로딩하기

테스트를 거치지 않은 소프트웨어는 없습니다. 하지만 많은 기능을 가져 복잡해진 현대의 소프트웨어를 온전히 테스트하는 것은 굉장히 어려운 일입니다.
이러한 테스트를 자동화하지 않은 채 소프트웨어를 지속적으로 배포하는 것은 불가능에 가깝다고 할 수 있습니다.
이번 글에서는 카카오스타일에서 진행하는 UI 테스트 자동화 시스템에 대해 설명해보겠습니다.

UI 테스트 자동화

카카오스타일에서는 서버 드리븐 UI(Server Driven UI, 이하 SDUI)를 통해 UI의 유연성을 가져가고 있습니다. 서버가 클라이언트 UI를 동적으로 제어하므로써 빌드 및 배포 없이도 UI 업데이트를 할 수 있고, A/B 테스트도 효율적으로 수행할 수 있었습니다. 다만 이렇게 구축된 시스템을 몇년간 운영하다보니 몇가지 문제점이 발생했습니다.
이 글에서는 초기 구조에서 어떤 문제가 발생했는지 살펴보고, 전시팀에서 어떤 방식으로 개선해 나갔는지에 대해 이야기 해보려고 합니다.

Server Driven UI 호출 구조 개선

원문: Sneaky React Memory Leaks: How the React compiler won’t save you…


원문: Sneaky React Memory Leaks: How the React compiler won’t save you


      
  
    
몇 주 전에 저는 리액트에서 useCallback이나 useEffect 같은 메모이제이션 훅을 사용할 때, 클로저가 어떻게 메모리 누수를 일으킬 수 있는 지에 대한 글을 썼습니다. 이 글은 TLDR WebDev, https://bytes.dev/, This Week In React와 같은 멋진 뉴스레터 및 X에서 주목을 받았습니다 (응원해 주셔서 감사합니다! 🙏).
당연히 많은

원문: Sneaky React Memory Leaks: How the React compiler won’t save you

      
  
    
몇 주 전에 저는 리액트에서 useCallback이나 useEffect 같은 메모이제이션 훅을 사용할 때, 클로저가 어떻게 메모리 누수를 일으킬 수 있는 지에 대한 글을 썼습니다. 이 글은 TLDR WebDev, https://bytes.dev/, This Week In React와 같은 멋진 뉴스레터 및 X에서 주목을 받았습니다 (응원해 주셔서 감사합니다! 🙏).
당연히 많은 사

(번역) 교묘한 리액트 메모리 누수 - 리액트 컴파일러가 당신을 구하지 못하는 이유


원문: Understanding React Compiler

리액트의 핵심 아키텍처는 사용자가 제공한 함수(즉, 컴포넌트)를 반복해서 호출합니다. 이 사실은 멘탈 모델을 단순화하여 인기를 얻었지만 성능 문제가 발생할 수 있는 지점을 만들기도 했습니다. 일반적으로 함수가 비용이 큰 작업을 수행하면 앱이 느려집니다.
따라서 개발자는 어떤 함수를 언제 다시 실행해야 하는지 수동으로 리액트에 알려줘야 했기 때문에 성능 튜닝은 골칫거리가 되었습니다. 리액트 팀은 이제 리액트 컴파일러라는 도구로 개발자들의 코드를 다시 작성하여 개발자가 수작

원문: Understanding React Compiler
리액트의 핵심 아키텍처는 사용자가 제공한 함수(즉, 컴포넌트)를 반복해서 호출합니다. 이 사실은 멘탈 모델을 단순화하여 인기를 얻었지만 성능 문제가 발생할 수 있는 지점을 만들기도 했습니다. 일반적으로 함수가 비용이 큰 작업을 수행하면 앱이 느려집니다.
따라서 개발자는 어떤 함수를 언제 다시 실행해야 하는지 수동으로 리액트에 알려줘야 했기 때문에 성능 튜닝은 골칫거리가 되었습니다. 리액트 팀은 이제 리액트 컴파일러라는 도구로 개발자들의 코드를 다시 작성하여 개발자가 수작업으

(번역) 리액트 컴파일러 이해하기

근래의 많은 기업과 마찬가지로 카카오스타일도 불필요한 비용 낭비가 발생하지 않도록 많은 노력을 기울이고 있습니다. 물론 이전이라고 사용하지 않는 리소스를 방치하며 비용을 낭비한 것은 아니고, 좀 더 세밀한 부분까지 주의를 기울이기 시작했다고 생각해주시면 됩니다. 이번 글은 그 중 하나를 소개해보려고 합니다.

웹폰트 최적화를 통한 CDN 비용절감

원문: HTML attributes vs DOM properties 속성(attribute)과 프로퍼티(property…


원문: HTML attributes vs DOM properties

속성(attribute)과 프로퍼티(property)는 근본적으로 다른 개념입니다. 같은 이름의 속성과 프로퍼티를 서로 다른 값으로 설정할 수 있습니다. 예를 들면 다음과 같습니다.
&lt;div foo="bar">…&lt;/div>
&lt;script>
  const div = document.querySelector('div[foo=bar]');

  console.log(div.getAttribute('foo')); // 'bar'
  console.log

원문: HTML attributes vs DOM properties
속성(attribute)과 프로퍼티(property)는 근본적으로 다른 개념입니다. 같은 이름의 속성과 프로퍼티를 서로 다른 값으로 설정할 수 있습니다. 예를 들면 다음과 같습니다.
…

  const div = document.querySelector('div[foo=bar]');

  console.log(div.getAttribute('foo')); // 'bar'
  console.log(div.foo); // undefined

  div.foo = 'he

(번역) HTML 속성 vs DOM 프로퍼티

원문: Infer type predicates from function bodies using control flow analysis #16069 해결 #38390 해결 #10734 해결 #50734 해결 #12798 해결 이 PR…


원문: Infer type predicates from function bodies using control flow analysis

#16069 해결
#38390 해결
#10734 해결
#50734 해결
#12798 해결
이 PR은 타입스크립트의 기존 제어 흐름 분석을 사용하여 적절한 곳에서 불리언(boolean) 값을 반환하는 함수에 대한 타입 서술어(type predicates)를 추론합니다. 예를 들면 다음과 같습니다.
function isString(x: string | number) {
  return typeof x

원문: Infer type predicates from function bodies using control flow analysis
#16069 해결
#38390 해결
#10734 해결
#50734 해결
#12798 해결
이 PR은 타입스크립트의 기존 제어 흐름 분석을 사용하여 적절한 곳에서 불리언(boolean) 값을 반환하는 함수에 대한 타입 서술어(type predicates)를 추론합니다. 예를 들면 다음과 같습니다.
function isString(x: string | number) {
  return typeof x =

(번역) 제어 흐름 분석을 통해 함수 내부로부터 타입 서술어 추론하기


이 글은 원래 원문에 게시된 넷플릭스 기술 블로그 글을 번역한 것입니다. 넷플릭스가 아닌 emewjin이 번역했으며 원본 저작권은 Netflix, Inc에 있습니다.

by Moshe Kolodny
이번 글에서 웹 기반 사용자 인터페이스(UI) 애플리케이션의 엔드투엔드(E2E) 테스트에 대한 새로운 관점을 제공하는 혁신적인 라이브러리인 SafeTest를 소개하게 되어 기쁩니다.
기존 UI 테스트의 문제점
전통적으로 UI 테스트는 단위 테스트 또는 통합 테스트(엔드투엔드(E2E) 테스트라고도 합니다)를 통해 수행되었습니다. 그러나 

이 글은 원래 원문에 게시된 넷플릭스 기술 블로그 글을 번역한 것입니다. 넷플릭스가 아닌 emewjin이 번역했으며 원본 저작권은 Netflix, Inc에 있습니다.
by Moshe Kolodny
이번 글에서 웹 기반 사용자 인터페이스(UI) 애플리케이션의 엔드투엔드(E2E) 테스트에 대한 새로운 관점을 제공하는 혁신적인 라이브러리인 SafeTest를 소개하게 되어 기쁩니다.

기존 UI 테스트의 문제점
전통적으로 UI 테스트는 단위 테스트 또는 통합 테스트(엔드투엔드(E2E) 테스트라고도 합니다)를 통해 수행되었습니다. 그러나 이

(번역) 프런트엔드 테스트에 대한 새로운 접근 방식 SafeTest를 소개합니다

원문 : How To Improve INP With Chrome DevTools INP(Interaction to Next Paint)는 2024년 3월에 세 가지 Google 핵심 웹 바이탈 중 하나가 될 성능 지표입니다. INP…


원문 : How To Improve INP With Chrome DevTools

INP(Interaction to Next Paint)는 2024년 3월에 세 가지 Google 핵심 웹 바이탈 중 하나가 될 성능 지표입니다.
INP는 다른 페이지 속도 지표들보다 개선하기 어려운 경향이 있습니다. 왜냐하면 측정을 위해 페이지 인터랙션이 필요하고, 이를 최적화하기 위해서는 종종 복잡한 자바스크립트 로직을 디버깅해야 하기 때문입니다.
이 글은 크롬 개발자 도구를 사용하여 페이지 인터랙션을 분석하고 사이트의 반응 속도를 더 빠르게 만드

원문 : How To Improve INP With Chrome DevTools
INP(Interaction to Next Paint)는 2024년 3월에 세 가지 Google 핵심 웹 바이탈 중 하나가 될 성능 지표입니다.
INP는 다른 페이지 속도 지표들보다 개선하기 어려운 경향이 있습니다. 왜냐하면 측정을 위해 페이지 인터랙션이 필요하고, 이를 최적화하기 위해서는 종종 복잡한 자바스크립트 로직을 디버깅해야 하기 때문입니다.
이 글은 크롬 개발자 도구를 사용하여 페이지 인터랙션을 분석하고 사이트의 반응 속도를 더 빠르게 만드는 

(번역) 크롬 개발자 도구로 INP를 개선하는 방법

원문: Feature-Sliced Design: The Best Frontend Architecture…


원문: Feature-Sliced Design: The Best Frontend Architecture


      
    
  
  
    
들어가며
프런트엔드 개발자는 종종 애플리케이션 아키텍처와 관련된 문제에 직면합니다. 대부분 모듈 간의 느슨한 결합과 높은 응집력을 제공해야 하며 쉽게 확장할 수 있는 아키텍쳐를 필요로 합니다.
이 글은 기능 분할 설계(Feature-Sliced Design, FSD) 아키텍처에 대해 설명합니다. 제 생각에는 이 아키텍처가 사용 가능한 옵션 중 최고라고 생각합니다. 차례대로 FSD의 개

원문: Feature-Sliced Design: The Best Frontend Architecture

      
    
  
  
    

들어가며
프런트엔드 개발자는 종종 애플리케이션 아키텍처와 관련된 문제에 직면합니다. 대부분 모듈 간의 느슨한 결합과 높은 응집력을 제공해야 하며 쉽게 확장할 수 있는 아키텍쳐를 필요로 합니다.
이 글은 기능 분할 설계(Feature-Sliced Design, FSD) 아키텍처에 대해 설명합니다. 제 생각에는 이 아키텍처가 사용 가능한 옵션 중 최고라고 생각합니다. 차례대로 FSD의 개념

(번역) 기능 분할 설계 - 최고의 프런트엔드 아키텍처

지난 1부에서는 프론트엔드에서 어드민 페이지를 리액트 앱으로 마이그레이션 할 때 왜 Client Side GraphQL을 선택했고, 환경을 어떻게 구축했는지에 대해 소개했었다. 2부인 이번 글에서는 GraphQL…

지난 1부에서는 프론트엔드에서 어드민 페이지를 리액트 앱으로 마이그레이션 할 때 왜 Client Side GraphQL을 선택했고, 환경을 어떻게 구축했는지에 대해 소개했었다.
2부인 이번 글에서는 GraphQL을 이용해서 실제로 프론트엔드 개발을 어떻게 했는지에 대해 구체적으로 소개하려고 한다. 1부에서 자세하게 다루지 않은 이야기 위주로 작성했다.
들어가며
이 글의 재료는 &#x3C;유저의 정산 정보를 확인하고 수정할 수 있는 모달>을 개발하는 과정이다. 이 기능에 대해 간략하게 소개하면 다음과 같다.

페이지 진입 시 일부 유

지난 1부에서는 프론트엔드에서 어드민 페이지를 리액트 앱으로 마이그레이션 할 때 왜 Client Side GraphQL을 선택했고, 환경을 어떻게 구축했는지에 대해 소개했었다.
2부인 이번 글에서는 GraphQL을 이용해서 실제로 프론트엔드 개발을 어떻게 했는지에 대해 구체적으로 소개하려고 한다. 1부에서 자세하게 다루지 않은 이야기 위주로 작성했다.

들어가며
이 글의 재료는 을 개발하는 과정이다. 이 기능에 대해 간략하게 소개하면 다음과 같다.
페이지 진입 시 일부 유저 정보가 row로 제공되는 테이블이 보여짐
각 row별로 버

Client side GraphQL로 어드민 만들기 2부 - 어떻게 개발했는가

이 글에서는 회사에서 어드민 제품의 프론트엔드를 레거시 프로젝트에서 모던한 프로젝트로 마이그레이션 할 때, 백엔드 리소스를 최소화하기 위해 Client side GraphQL…

이 글에서는 회사에서 어드민 제품의 프론트엔드를 레거시 프로젝트에서 모던한 프로젝트로 마이그레이션 할 때, 백엔드 리소스를 최소화하기 위해 Client side GraphQL을 사용하기로 선택한 내용과 어떻게 그 환경을 구축했는지 적어보려 한다.
글이 너무 길어져서 (글 작성을 작년부터 시작했는데 배포를 미루고 미뤘던 이유가 있었다) GraphQL로 실질적인 개발 과정은 어떻게 이루어지고 있느냐에 대해 이야기는 2부에서 하려고 한다.
배경
레거시 어드민을 리액트 앱으로 마이그레이션 하기로 했다. 이때 백엔드 리소스가 없어서 프론트엔

이 글에서는 회사에서 어드민 제품의 프론트엔드를 레거시 프로젝트에서 모던한 프로젝트로 마이그레이션 할 때, 백엔드 리소스를 최소화하기 위해 Client side GraphQL을 사용하기로 선택한 내용과 어떻게 그 환경을 구축했는지 적어보려 한다.
글이 너무 길어져서 (글 작성을 작년부터 시작했는데 배포를 미루고 미뤘던 이유가 있었다) GraphQL로 실질적인 개발 과정은 어떻게 이루어지고 있느냐에 대해 이야기는 2부에서 하려고 한다.

배경
레거시 어드민을 리액트 앱으로 마이그레이션 하기로 했다. 이때 백엔드 리소스가 없어서 프론트

Client side GraphQL로 어드민 만들기 1부 - 환경 구축

2023년 겨울, 사내 에디터 라이브러리를 리팩토링한 경험에 대해 글로 기록하려고 한다. 리팩토링 계기 XP…

2023년 겨울, 사내 에디터 라이브러리를 리팩토링한 경험에 대해 글로 기록하려고 한다.
리팩토링 계기

XP 팀은 나누고 정복하지 않고, 정복하고 나누고 또 정복한다. 처음에는 소규모 팀이 소규모 시스템을 작성한다. 그런 다음 자연스러운 분할선을 찾아 시스템을 비교적 독립적인 부분으로 나누어 확장한다.” - 켄트 벡, 익스트림 프로그래밍

나누고 정복하지 않고, 정복하고 나누고 또 정복하는 이유는 우리가 만들 대상을 처음부터 잘 알지 못하기 때문이라고 한다. 일단 정복한다는 것은 일단 학습한다는 의미이며, 일하면서 정복하다 보면 

2023년 겨울, 사내 에디터 라이브러리를 리팩토링한 경험에 대해 글로 기록하려고 한다.

리팩토링 계기
XP 팀은 나누고 정복하지 않고, 정복하고 나누고 또 정복한다. 처음에는 소규모 팀이 소규모 시스템을 작성한다. 그런 다음 자연스러운 분할선을 찾아 시스템을 비교적 독립적인 부분으로 나누어 확장한다.” - 켄트 벡, 익스트림 프로그래밍
나누고 정복하지 않고, 정복하고 나누고 또 정복하는 이유는 우리가 만들 대상을 처음부터 잘 알지 못하기 때문이라고 한다. 일단 정복한다는 것은 일단 학습한다는 의미이며, 일하면서 정복하다 보면 학

합성형 컴포넌트로 에디터 리팩토링하기

원문 : Introducing StyleX StyleX를 소개하게 되어 매우 기쁩니다. StyleX…


원문 : Introducing StyleX

StyleX를 소개하게 되어 매우 기쁩니다. StyleX는 야심찬 애플리케이션을 위한 표현력 있고, 결정론적이고, 신뢰할 수 있으며 확장성을 갖춘 스타일링 시스템입니다. 기존에 출시된 스타일링 라이브러리들로부터 최고의 아이디어를 가져와서, 익숙하면서도 독특하고 새롭게 만들었습니다.
StyleX 란?
StyleX는 CSS-in-JS 라이브러리들의 개발자 경험을 유지하고 컴파일 단계의 도구를 사용해 정적 CSS의 성능 및 확장성과 연결합니다. 하지만 StyleX는 단순한 컴파일러 기반 CS

원문 : Introducing StyleX
StyleX를 소개하게 되어 매우 기쁩니다. StyleX는 야심찬 애플리케이션을 위한 표현력 있고, 결정론적이고, 신뢰할 수 있으며 확장성을 갖춘 스타일링 시스템입니다. 기존에 출시된 스타일링 라이브러리들로부터 최고의 아이디어를 가져와서, 익숙하면서도 독특하고 새롭게 만들었습니다.

StyleX 란?
StyleX는 CSS-in-JS 라이브러리들의 개발자 경험을 유지하고 컴파일 단계의 도구를 사용해 정적 CSS의 성능 및 확장성과 연결합니다. 하지만 StyleX는 단순한 컴파일러 기반 CSS

(번역) StyleX를 소개합니다

원문 : https://www.epicweb.dev/why-i-wont-use-nextjs by Kent C. Dodds…


원문 : https://www.epicweb.dev/why-i-wont-use-nextjs by Kent C. Dodds.

새로운 프로젝트가 주어졌습니다. 혹은 기존 프로젝트를 더 현대적인 접근법으로 업그레이드하려는 동기가 있을 수 있습니다. 아니면 아마도 현재 사용 중인 모던 프레임워크에 만족하지 못하고 있거나 자신에게 의문을 품고 대안을 조사 중일 수도 있습니다. 뭐든 간에, 결정을 내려야 합니다.
선택할 수 있는 “모던” 프레임워크는 많습니다. 지금 당장 이러한 선택에 직면하지 않더라도 향후 시장성과 생산성을 높이기 위해 

원문 : https://www.epicweb.dev/why-i-wont-use-nextjs by Kent C. Dodds.
새로운 프로젝트가 주어졌습니다. 혹은 기존 프로젝트를 더 현대적인 접근법으로 업그레이드하려는 동기가 있을 수 있습니다. 아니면 아마도 현재 사용 중인 모던 프레임워크에 만족하지 못하고 있거나 자신에게 의문을 품고 대안을 조사 중일 수도 있습니다. 뭐든 간에, 결정을 내려야 합니다.
선택할 수 있는 “모던” 프레임워크는 많습니다. 지금 당장 이러한 선택에 직면하지 않더라도 향후 시장성과 생산성을 높이기 위해 학습

(번역) 내가 Next.js를 사용하지 않는 이유

안녕하세요, 카카오스타일 전시 UX팀의 샌즈입니다.
모두들 알고 계시듯 null(널)은 값이 없음을 나타냅니다. 그리고 null 값인 객체에 접근하려고 하면 그 유명한 NullPointerException(NPE)이 발생합니다. 그런데 null 값을 가지지 않는 다고 설정한 변수에서 NPE가 발생하는 현상을 겪어 그 내용을 공유해보려고 합니다.

내가 만든 non-null 변수에서 NullPointerException이 발생할 리가 없어!

원문: https://alan.norbauer.com/articles/relay-style-graphql 이 글은 원작자의 동의를 받고 한국어로 번역되었습니다. 오역 또는 더 정확한 표현에 대한 코멘트는 항상 환영입니다! ”미래형 Relay-style…


원문: https://alan.norbauer.com/articles/relay-style-graphql
이 글은 원작자의 동의를 받고 한국어로 번역되었습니다.
오역 또는 더 정확한 표현에 대한 코멘트는 항상 환영입니다!



”미래형 Relay-style GraphQL은 이미 존재한다 - 다만 고르게 퍼져있지 않을 뿐이다.”
– William Gibson, probably

“Relay-style GraphQL”은 React 애플리케이션에서 GraphQL을 사용하는 한 가지 방법이며, 아마도 현재 사용하고 있는 방법보다 더 나은

원문: https://alan.norbauer.com/articles/relay-style-graphql
”미래형 Relay-style GraphQL은 이미 존재한다 - 다만 고르게 퍼져있지 않을 뿐이다.”
“Relay-style GraphQL”은 React 애플리케이션에서 GraphQL을 사용하는 한 가지 방법이며, 아마도 현재 사용하고 있는 방법보다 더 나은 방법일 것입니다. 이 방법은 Meta의 GraphQL 오픈소스 라이브러리, Relay의 아이디어를 따릅니다.
Relay는 이러한 아이디어1를 독점하지 않으며, Apollo와