기술 블로그 모음

안녕하세요! 올리브영에서 리뷰/SNS 프론트엔드 개발을 담당하고 있는 d9입니다. 저희 조직에서는 올리브영의 SNS…

LY Corporation에서는 2024년 10월에 사내 웹 프런트엔드 개발에 관여하는 사내 구성원을 대상으로 본인이 생각하는 2024년의 웹 프런트엔드 관련 근황 및 관련 툴 이...

안녕하세요! 리멤버앤컴퍼니 파운데이션 크루에서 Web Frontend Software Engineer로 일하고 있는 성정민입니다.최근 저는 사용자가 검색창에 키워드를 입력할 때마다 실시간으로 UI를 업데이트하는 기능을 개발했습니다. 그런데 문제가 발생했어요. 검색창에 글자를 입력할 때마다 수천 개의 데이터를 필터링하고 화면에 표시해야 하는데, 이 과정...

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

이력서 작성에 고민해보신 적이 있나요? 토스에는 여러분의 고민한 내용이 남긴 GitHub 저장소 링크 하나만 제출하면 돼요.

주요내용 25년 4월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. A Categorical Archive of ChatGPT Failures ChatGPT와 같은 대형 언어 모델의 한계를 분석한 내용이다. 논리는 크게 11개의 실패 유형으로 구분되며, 논리적 추론, 수학적 계산, 사실 오류, 편견 및 차별, 코딩 오류 등 다양한 영역...

왓챠 웹은 2016년부터 react + node(express)기반으로 운영되었지만, 최근 대중적인 프레임워크의 발전으로 인해 우리의 기존 구조를 유지하는 것이 점점 부담되고 있었습니다. 이에 따라 Remix로 마이그레이션을 결정한 과정과 경험을 공유하려 합니다.왓챠 웹 구조 소개 & 마이그레이션을 고려한 이유왓챠는 오랜 역사를 가진 서비스입니...

오늘은 토스 자체 React Native 프레임워크 Bedrock가 어떻게 파일 기반 라우팅의 문제를 해결했는지 소개해드릴게요.

토스의 디자인 편집기 데우스(Deus)! 이번 모닥불에서는 토스의 자체 디자인 편집기 데우스(Deus) 프로젝트를 소개합니다! 디자인과 개발 사이의 경계를 넘나드는 새로운 가능성을 만나보세요! 데우스(Deus)가 풀어낸 기술적 도전과 그 여정을 통해, 우리가 함께 만들어갈 미래를 이야기합니다.

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

프론트엔드 개발 경험을 향상시키는 HMR(Hot Module Replacement)의 원리와 다양한 번들러가 HMR을 어떻게 지원하는지 살펴보고, ESBuild 기반 번들러를 직접 개발한 과정을 소개드려요.

왜 토스증권 PC의 그리드 레이아웃을 왜 직접 구현하게 되었는지, 그리고 어떻게 만들어져 있는지를 이제부터 소개해 드릴게요.

들어가며 안녕하세요. LINE+ UIT 조직에서 프런트엔드 개발을 하고 있는 강형민입니다. LY에서는 매년 'Front-end Global Workshop'을 개최하고 있습니다. ...

네이버 검색은 사용자 중심의 빠르고 원활한 검색 경험을 제공하기 위해 지속적으로 웹 성능을 모니터링하고 최적화하고 있습니다. 2024년에는 특히 LCP(Largest Contentful Paint)를 핵심 성능 지표로 삼아 여러 최적화 작업을 진행하였으며, 그 결과 네이버 검색의 웹 성능은 목표로 삼았던 구글 글로벌 LCP와 유사한 수준인 LCP p95 기준 2.31초를 달성할 수 있었습니다. 또한 2024년에 새로운 서치 피드 서비스가 도입되면서 기존의 웹 기반 성능 지표로는 측정하기 어려운 무한 스크롤 영역을 측정할 수 있는 새로운 성능 지표를 개발하여 관리하고 있습니다. 새로운 성능 지표는 동적 콘텐츠 로딩의 체감 속도와 이미지 렌더링 타이밍을 평가하는 데 활용됩니다. 이 글에서는 1) 2024년 네이버 통합검색의 웹 성능을 정리하고, 2) 새롭게 도입된 성능 지표를 소개하며, 3) 2024년 네이버에서 진행한 몇 가지 성능 개선 사례를 살펴봅니다. 2024년 네이버 통합검색 성능 연간 지표 네이버 검색은 LCP를 가장 중요한 성능 지표로 설정하고 있으며, 구글 글로벌 LCP 수준인 p95(95번째 퍼센타일) 기준 2.5초 이하를 목표로 하고 있습니다. 2024년 12월 기준 네이버 검색의 LCP Good Score는 96.59%를 기록했는데, 이는 대부분의 사용자들이 페이지 로딩 시 콘텐츠가 빠르고 원활하게 표시되고 있음을 의미합니다. 꾸준히 시스템을 모니터링하고 개선하기 위해 노력한 덕분에 2024년 하반기부터 성능 지표가 점진적으로 개선될 수 있었습니다. 2024년 네이버 통합검색 성능 개선 사례에서 구체적인 개선 사례를 확인할 수 있습니다. 2024년 네이버 검색의 전체 LCP는 p95 기준 약 2.31초이며, INP(Interaction to Next Paint)는 0.26초입니다. INP는 사용자가 버튼을 클릭하거나 입력을 했을 때 화면이 다음 단계로 넘어가기까지 걸리는 시간을 의미합니다. INP는 Core Web Vitals의 주요 지표 중 하나로 네이버 검색에서도 유심히 모니터링하고 있습니다. 구글에서는 좋은 INP를 200ms 이하로 안내하고 있습니다. 2024년 하반기부터 네이버 검색의 INP 지표가 점점 개선되고 있지만, 아직 목표 기준인 60ms를 초과하므로 추가적인 최적화 작업이 필요합니다. 2024년 네이버 통합검색의 새로운 성능 지표 네이버 검색은 최근 무한 스크롤 방식의 서치 피드(Search Feed)를 도입하여 사용자 경험을 개선하기 위해 노력하고 있습니다. 그런데 기존의 LCP 지표만으로는 동적으로 로드되는 무한 스크롤 영역의 성능을 정확하게 평가하는 데 한계가 있었습니다. LCP는 페이지를 최초로 로딩할 때 주요 콘텐츠의 시각적 완성도를 측정하는 데 효과적이지만, 사용자가 직접 스크롤로 새로운 데이터를 요청하는 서치 피드의 특성을 반영하기 어려웠습니다. 이러한 문제를 해결하기 위해 네이버 검색에서는 새로운 성능 지표를 정의하여 관리하고 있습니다. 피드 사용자 체감 성능 지표: FUPP FUPP(Feed User Perceived Performance)는 서치 피드의 동작 흐름과 사용자 상호작용을 기반으로 설계된 지표입니다. 사용자가 화면 아래까지 스크롤하여 새로운 콘텐츠를 요청하면, 백엔드 API 호출이 트리거되고 해당 데이터를 받아 화면에 렌더링하는 과정이 시작됩니다. FUPP는 API 호출이 시작되는 시점부터 서치 피드의 첫 번째 주요 이미지가 화면에 완전히 렌더링될 때까지의 시간을 측정합니다. 이는 단순히 네트워크 응답 속도뿐 아니라 데이터 처리와 시각적 요소의 표시 시간까지 포괄함으로써, 사용자가 실제로 새로운 콘텐츠를 '인지'하는 순간을 측정합니다. 즉, FUPP는 무한 스크롤 환경에서 사용자가 다음 콘텐츠를 얼마나 빠르게 확인할 수 있는지를 평가하는 기준입니다. 위 내용을 바탕으로 FUPP를 측정한 결과 p95 기준 약 1.5초로 나타났습니다. 이는 대다수 사용자가 1.5초 이내에 새로 로드된 서치 피드 콘텐츠를 확인할 수 있음을 의미합니다. 다시 말해 사용자가 화면 아래에 도달하기 1.5초 전에 서치 피드를 요청하면 끊김 없이 콘텐츠를 확인할 수 있습니다. 피드 이미지 로드 타이밍 지표: FILT 대부분의 서치 피드에서 가장 많은 영역을 차지하는 부분은 이미지입니다. 따라서 이미지 로딩 속도가 사용자 체감 성능에 많은 영향을 주게 됩니다. 네이버 검색에서는 FILT(Feed Image Load Timing)라는 지표를 도입해 서치 피드에서 이미지가 언제, 어떻게 로드되었는지를 분석하고 있습니다. 이미지가 노출되는 시점을 총 4가지 유형으로 세분화하여 FILT를 측정했습니다. 첫 번째 유형은 Standby(대기 중)로 이미지 로딩이 아직 시작되지 않은 상태를 의미합니다. 브라우저의 lazy loading 방식을 이용하므로 Standby는 아직 브라우저가 이미지를 로드하지 않은 상태입니다. 측정한 결과 전체 이미지 중 14%가 이 유형에 해당했습니다. 두 번째 유형인 Early(미리 로드됨)는 사용자가 해당 피드 영역에 도달하기 전에 이미지가 로드된 경우로, 사용자는 끊김 없이 피드를 소비할 수 있습니다. 전체 이미지의 75%를 차지합니다. 세 번째 유형은 Viewport(화면 내 로드됨)로 사용자가 피드에 진입한 시점에는 이미지가 로드 중이었지만 피드를 소비하는 과정에서 로드가 완료되는 경우입니다. 전체 이미지의 약 11%를 차지하고 있습니다. 마지막 유형은 Late(늦은 로딩)로 사용자가 피드를 지나친 후에 이미지가 로드된 경우입니다. 즉, 사용자가 해당 이미지를 확인하지 못한 상태로 피드를 지나쳤음을 의미합니다. 다행히 이런 경우는 0% 수준으로 확인되었습니다. 서치 피드 최적화 FUPP와 FILT 지표로 서치 피드의 성능을 정량적으로 측정하고 모니터링할 수 있는 체계를 구축했고, 이를 활용해서 서치 피드 최적화 실험을 진행했습니다. 무한 스크롤 방식의 고민 중 한 가지는 콘텐츠를 호출하는 시점입니다. 사용자가 화면을 끝까지 스크롤한 이후 콘텐츠를 로드한다면 대기 시간이 발생하여 사용성에 문제가 생길 수 있습니다. 반면 사용자가 화면 아래에 도달하기 전에 콘텐츠를 너무 빠르게 로드하면 소비 의도가 없는 사용자에게도 콘텐츠가 노출되어 서버 리소스가 불필요하게 소모될 수 있습니다. 그래서 우리는 로드 시점에 따른 사용성과 서버 부하 등을 확인할 수 있는 ABT를 진행했습니다. 화면 맨아래에서부터 200&Tilde1,600px 구간을 실험 구간으로 설정하고, 구간별로 서치 피드 호출 시점을 조정하여 소비 지표와 시스템 지표를 종합적으로 확인했습니다. 그 결과 콘텐츠 로드 시점을 100px 조정할 때마다 서버 호출량은 5%, 사용자 도달률은 2% 변동하는 패턴을 확인할 수 있었습니다. 예를 들어 화면 아래에서 600px 위치에서 콘텐츠를 로드하면, 800px 위치 대비 서버 호출량이 10% 감소했으나 사용자 도달률도 4% 하락했습니다. FILT 지표 역시 주목할 만한 변화를 보였습니다. 로드 시점이 늦어질수록 Viewport 비중이 증가했는데, 이는 이미지 요청 시점이 늦어졌기 때문에 발생한 현상으로 예측한 결과였습니다. 흥미로운 부분은 특정 시점(약 1,000px) 이후에는 로드 시점을 더 앞당겨도 Early 비중이 개선되지 않는다는 점이었습니다. 소비 지표(클릭률, 이탈률 등)에서도 유의미한 인사이트를 확인할 수 있었습니다. 로드 시점이 늦어질수록 소비 지표는 안 좋아질 것으로 예상했고, 실제로도 가설을 입증하는 데이터를 확인할 수 있었습니다. 반면 로드 시점이 빠를수록 소비 지표가 개선될 것이라는 초기 가설과 달리 특정 시점(약 1,200px)을 기준으로 소비 지표는 오히려 감소했습니다. 이는 콘텐츠 소비 의도가 없는 사용자에게까지 피드가 노출되므로 해당 사용자들이 피드를 무시하거나 빠르게 이탈하는 행동 패턴에 기인한 것으로 판단하였습니다. 실험 데이터를 종합한 결과, 화면 아래에서부터 600&Tilde1,000px 구간에서 서치 피드를 호출하는 것이 가장 효율적이라는 결론을 내렸습니다. 현재 네이버 검색은 1,000px을 기준점으로 채택하여 서비스 안정성과 사용자 경험을 동시에 개선했으며, 향후 트래픽 변동이나 사용자 패턴 변화에 따라 데이터 기반으로 유연하게 조정할 계획입니다. 2024년 네이버 통합검색 성능 개선 사례 네이버 검색에서 2024년에 진행한 몇 가지 성능 개선 사례를 소개합니다. 지역플러스 영역 LCP 개선 네이버 검색의 지역플러스 영역은 장소 검색 시 표시되는 검색 결과로, 주로 이미지와 함께 노출됩니다. 2024년 5월 30일 업데이트로 LCP p95 수치가 3,000ms에서 2,000ms로 30% 개선되었습니다. 이러한 성능 개선의 핵심 요인은 CSS의 background-image 속성을 사용해 이미지를 로딩하는 방식에서 img 태그를 사용하는 방식으로 변경한 데 있습니다. 과거에는 Internet Explorer 환경에 대응해야 해서 object-fit 속성 대신 background-image 속성을 사용할 수 밖에 없었습니다. background-image 속성을 사용하여 이미지를 삽입하는 방식은 브라우저가 DOM 파싱이 완료된 후에 CSS 파일을 파싱하면서 이미지를 요청합니다. 그 결과 이미지가 렌더링되기까지 추가적인 지연이 발생하며, 이는 LCP를 악화시키는 요인이 될 수 있습니다. 반면 HTML의 img 태그를 활용하는 방식은 HTML 문서를 파싱하는 즉시 img 태그를 인식하고 리소스 요청을 시작합니다. 이 방식은 브라우저의 초기 파싱 단계에서 이미지를 빠르게 불러오므로 이미지 렌더링 시간을 단축하고 LCP에 긍정적인 영향을 줄 수 있습니다. 다음의 그림은 각 이미지 로딩 방식을 적용했을 때 브라우저에서 이미지를 로드하는 과정을 나타낸 것입니다. 파란색 박스로 표시된 영역은 img 태그를 사용했을 때, 빨간색 박스로 표시된 영역은 background-image 속성을 사용했을 때입니다. 이번 개선 사례에서 네이버 검색의 성능 최적화 작업이 단순히 코드 최적화나 서버 인프라 개선에 국한되지 않으며, 프런트엔드 렌더링 전략의 미세 조정만으로도 상당한 효과를 얻을 수 있다는 점을 확인할 수 있었습니다. 네이버 통합검색 성능 개선에 도움을 주신 플레이스 검색 서비스 개발팀의 이대희 님, 임지수 님(메인&플레이스UI개발)께 감사드립니다. 크리스마스 브랜드검색 Flicking 성능 개선 크리스마스 시즌 동안, 네이버 검색의 특정 영역에서 egjs/Flicking을 활용한 UI의 화면이 끊기는 현상이 발생했습니다. 비록 이 문제가 Web Vitals 지표에는 큰 영향을 주지 않았지만, 사용자 경험에는 부정적인 인상을 남길 가능성이 높았습니다. 문제의 원인을 분석한 결과, 첫 번째로 marginLeft 속성을 지속적으로 변경함에 따라 브라우저가 레이아웃 재계산(reflow)을 빈번하게 수행하게 된 부분이 큰 영향을 주었습니다. 이로 인해 화면의 애니메이션이 부드럽게 이어지지 않고 중간에 끊기는 현상이 발생했습니다. 두 번째로, 배경 이미지를 CSS의 background-image 속성으로 로드했기 때문에 이미지 로딩 속도가 상대적으로 느려졌습니다. 이 문제를 해결하기 위해 marginLeft 속성 대신 transform:transX 속성을 적용하도록 안내했습니다. 이렇게 하면 레이아웃을 재계산하지 않고 GPU 가속을 활용하므로 애니메이션이 훨씬 부드럽게 구현됩니다. 또한 앞선 사례에서 소개한 것처럼 background-image 속성 대신 img 태그 기반의 방식으로 이미지를 렌더링하도록 변경하여 이미지 로드 속도를 향상시켰습니다. egjs/Flicking을 사용할 때 marginLeft를 사용한 원인을 확인해 보니 Flicking 애니메이션 도중 Parallax 효과를 구현하기 위해서였습니다. 사실 egjs/Flicking에서도 Parallax 기능을 제공하고 있었지만 당시 제공된 문서의 설명이 충분하지 않아 실제 적용 과정에서 어려움을 겪었던 것으로 파악됩니다. 이에 따라 관련 내용을 보완하였으며, 이외에도 egjs/Flicking에서 제공하는 다양한 기능을 제대로 활용할 수 있도록 지속적으로 문서를 개선할 계획입니다. 마치며 2024년 네이버 통합검색의 웹 성능은 꾸준한 관리로 지속적인 개선을 이루었으며, LCP p95 기준 2.31초를 기록할 만큼 안정적인 수준에 도달했습니다. 또한, 새로운 서치 피드 서비스에 적합한 성능 지표인 FUPP와 FILT를 도입하여 무한 스크롤 영역의 성능을 보다 정밀하게 측정하고 최적화할 수 있었습니다. 앞으로 다음과 같은 부분을 개선할 계획입니다. SSR(ServerSideRendering)과 부분 CSR(ClientSideRendering)이 공존할 때 성능 측정 방법 개발 INP 지표 개선을 위한 추가 최적화 네이버 검색은 지속적으로 성능을 관찰하고 개선하여 더욱 빠르고 효율적인 검색 환경을 제공하고 사용자 경험을 극대화하는 것을 목표로 하고 있습니다.

주요내용 25년 3월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. 2024 Frameworks Year in Review Netlify의 웹덕후들이 2024년의 흐름 그리고 25년도에 대한 기대를 정리해 줍니다. How long is a second in JavaScript? JavaScript에서 '초'의 길이와 시간 측정의 역사와 과학적 배경을 탐구해 봅니다. Optimizing the Critical Rendering Path 웹 페이지의 초기 렌더링을 지연시키는 주요 자원들을 식별하고, 이를 최적화하여 사용자 경험을 향상시키는 방법을 다룹니다. Sunsetting Create React App React 공식 팀이 Create React App(CRA)을 더 이상 유지하지 않기로 결정했습니다. >> FE News 25년 3월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기

주요내용 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를 활용한 다양한 개발 도구가 어떻게 개발 방식을 변화시킬 수 있는지 알아봅니다. Toss Frontend Fundamentals 토스의 프런트엔드 개발자들이 공개한 변경하기 쉬운 프론트엔드 코드를 위한 지침서 Do JavaScript frameworks still need portals? Dialog, popover, CSS anchor positioning 등의 기능으로 Portal(React), Teleport(Vue) 를 대체하는 방법을 소개합니다. >> FE News 25년 2월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기

모닥불 10화 특집: 캠프파이어 에피소드 🔥 이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요. 사전에 접수된 시청자 여러분의 다양한 사연과 질문 그리고 코드 리뷰까지! 지금 바로 확인해보세요!

배경2022년 리멤버 리브랜딩리멤버는 2022년 7월 ‘기회가 열린다, 리멤버’라는 슬로건과 함께 명함 앱을 넘어 비즈니스의 다양한 기회가 열리는 직장인 슈퍼앱으로 나아가고자 리브랜딩이 진행되었습니다.이 과정에서 리브랜딩 심볼의 큰 변화가 있었는데요. 명함을 연상시키는 기존 사각형을 벗어나 다양한 기회가 열리는 ‘문’을 형상화한 스퀘어로 진화했고, 이...

네이버 검색 FE 시스템 구축 과정에서 저희는 다음과 같은 문제에 직면했습니다. 첫째, 유사하지만 영역이 다른 경우 비슷한 작업을 반복하는 경우가 있었습니다. 검색의 각 영역은 마이크로서비스 아키텍처(MSA)로 이루어져 있으며 클라이언트 코드 역시 영역별로 관리되고 있었습니다. 이로 인해 영역 간 동일한 유형의 작업을 반복해야 했고, 경험이 축적되기보다는 업무의 성장이 저해되는 결과를 초래했습니다. 둘째, 유사한 UI를 매번 새로 개발해야 하는 비효율성이 존재했습니다. 코드의 재활용이 어려워서 유사한 패턴의 UI를 구현할 때마다 새로운 코드를 작성해야 했고, 이는 자원의 낭비로 이어졌습니다. 셋째, 데이터가 부족해 개선 작업이 어려웠습니다. 개선이 이루어져도 이를 측정할 수 있는 데이터가 부족해서 실제 효과를 파악하기 어려웠습니다. 그 결과, 어디부터 개선해야 할지, 문제는 없을지 등을 판단하기가 어려워 개선 작업의 방향성을 설정하기 어려웠습니다. 넷째, 피드백 주기가 지나치게 길다는 문제가 있었습니다. 디자인이 실제 코드로 구현되어 동작하기까지의 시간이 너무 오래 걸렸고, 이 과정 중에 디자인이 수정되면 재작업이 많아지는 비효율적인 상황이 발생했습니다. 이 글에서는 이 문제들을 해결하기 위한 저희의 해결 방안과 현재 고민하고 있는 문제를 공유하겠습니다. 해결 방향 이러한 문제를 해결하기 위해 저희가 생각한 해결 방향은 다음과 같습니다. 첫째, 서버 주도 UI(Server Driven UI) 방식을 도입했습니다. 비슷한 작업이 반복되는 문제를 해결하기 위해 UI를 한곳에 모으고 이를 재활용할 필요가 있었습니다. 서버에서는 비즈니스 로직만 구현하고 UI를 생성하는 서버를 별도로 두는 것이 적합하다고 판단하여 서버 주도 UI 방식을 채택했습니다. 이를 통해 클라이언트 측에서 UI를 반복해 개발할 필요 없이 서버에서 다양한 상황에 맞춰 유연하게 UI를 전달할 수 있게 되었습니다. 이는 비슷한 개발 작업을 줄이고 유지 보수의 효율성을 크게 향상시켰습니다. 둘째, 디자인 시스템(Design System)을 통한 해결책을 마련했습니다. 기존에는 UI가 유사해도 개발자가 달라서 별도로 개발하여 중복이 발생했다면, 이제는 자주 사용되는 UI 요소를 일관된 디자인 시스템으로 구축하여 재사용이 가능하도록 만들었습니다. 이는 개발자와 디자이너 모두에게 큰 도움이 되었으며, UI 개발 시간을 단축시키고 중복된 노력을 최소화할 수 있었습니다. 셋째, 데이터 기반의 접근 방식을 도입했습니다. 현재 데이터가 부족해 개선 작업이 어렵다는 문제를 해결하기 위해, 더 많은 데이터를 수집하고 이를 바탕으로 피드백 루프를 강화하는 계획을 수립했습니다. 특히 현재 사용되고 있는 UI를 분석하고 그 데이터를 수집하여, 이후 개발 및 운영 과정에 적극적으로 활용하고자 했습니다. 이를 통해 서비스에 많이 사용되는 컴포넌트와 모듈을 수집하고 사용자의 패턴을 파악하며 어떤 UI가 효과적인지에 대한 통찰을 얻어 UI와 UX를 최적화할 수 있게 되었습니다. 더 나아가, 데이터 분석 결과는 새로운 기능 개발뿐만 아니라 기존 UI의 개선 작업에도 큰 도움이 되었습니다. 마지막으로, Design To Code를 통해 제한된 환경에서의 자동화를 도입했습니다. 긴 피드백 주기를 줄이기 위해, 디자인을 코드로 변환하는 과정을 자동화하는 시스템을 적용하여 디자인과 개발의 간극을 줄였습니다. 이로 인해 디자이너가 수정한 내용을 신속하게 반영할 수 있게 되었고, 개발자는 재작업을 줄이며 효율성을 극대화할 수 있게 되었습니다. Flexible Rendering Engine 해결 방안의 첫 번째 주제인 유연한 렌더링 엔진(Flexible Rendering Engine), 서버 주도 UI와 디자인 시스템에 대해 설명하겠습니다. 서버 주도 UI(Server-Driven UI) 템플릿 및 컴포넌트 기반의 한계 2021년에 처음 도입한 템플릿 기반 방식은 미리 정의된 몇 가지 템플릿을 사용하여 신속하게 화면을 구성해 개발 속도를 향상시킬 수 있었습니다. 그러나 다양한 UI 요구 사항에 맞춰 동적으로 변화하기에는 한계가 있었습니다. 새로운 요구 사항이 발생할 때마다 템플릿을 수정하거나 새로 생성해야 했기 때문에, 마치 정해진 레고 블록으로만 조립해야 하는 것처럼 유연성이 부족했습니다. 그래서 저희는 컴포넌트 기반으로 전환했습니다. 컴포넌트 기반은 UI를 작은 단위로 분할하여 재사용이 가능했고 확장성 측면에서 이점이 있었습니다. 하지만 과도하게 세분화된 컴포넌트 구조로 인해 데이터 전송량이 크게 증가했고 서버와 클라이언트 간의 통신이 복잡해졌습니다. 그 결과, 컴포넌트 구조에서는 성능 저하와 복잡성 문제가 발생했습니다. 개발 방식 장점 단점 템플릿(블록) UI 표현이 적음데이터만 변경 생산성 확장성 컴포넌트 UI 표현이 많음데이터와 함께 조립 확장성 생산성 템플릿 방식과 컴포넌트 방식 모두 각기 다른 한계가 있었기에, 저희는 새로운 접근이 필요하다는 결론을 내렸습니다. Sweet Spot 찾기: 모듈 도입 템플릿 기반은 고정된 틀 안에서 신속하게 UI를 구성할 수 있었으나 확장성이 부족했고, 반면 컴포넌트 기반은 지나치게 많은 컴포넌트를 사용하면서 복잡성과 성능 저하 문제를 겪었습니다. 이러한 상황에서 저희는 이 두 가지 방식의 중간 지점, 즉 스위트 스폿(sweet spot)을 찾기 위해 모듈이라는 개념을 도입했습니다. 모듈은 템플릿보다는 유연하고, 컴포넌트보다는 덜 복잡한 단위입니다. 이를 통해 다양한 상황에서도 적절한 수준의 UI 조립이 가능하고 확장성과 성능을 모두 확보할 수 있다는 장점이 있습니다. 저희는 블록의 크기와 복잡도의 기준을 큰 틀에서는 정했지만 상세한 규칙은 만들지 않았습니다. 이는 서비스가 변화하면서 함께 변화하는 영역이라 저희가 제어하기 쉽지 않았고, 너무 제한된 상황을 만들 수 있었기 때문입니다. 대신 적절한 기준으로 모듈화를 하고, 이후 데이터를 기반으로 모듈을 설정하며, 데이터를 분석하면서 블록 수준을 조정해 최적의 구조를 찾아가는 방식을 선택했습니다. Fender(Flexible Rendering)의 구조 유연한 렌더링 엔진은 JSON 데이터를 통해 클라이언트의 UI를 동적으로 제어하는 서버 주도 UI의 서버입니다. 서버는 UI의 각 블록을 정의하여 클라이언트에 전송하고 클라이언트는 이 데이터를 받아 실시간으로 UI를 렌더링합니다. 이 구조의 중요한 특징은 모든 UI 요소를 자유롭게 변화시키는 것이 아니라, 적정한 수준에서 블록 단위로 제어한다는 점입니다. 이를 통해 저희는 복잡성을 줄이면서도 유연성을 확보할 수 있었습니다. 예를 들어, 서버가 특정 조건에 맞춰 JSON 데이터를 전송하면 클라이언트는 별도의 추가 개발 없이 즉시 UI를 변경할 수 있습니다. 유연한 렌더링의 주요 장점은 크게 세 가지입니다. 서버에서 UI를 제어하므로 유연하게 UI를 업데이트할 수 있다. 블록 단위로 제약을 두어 복잡성을 줄이고 성능을 최적화한다. 다양한 상황에서 블록을 재활용해 개발 효율성을 높일 수 있다. 높은 재사용성(High Portability) 이러한 방식으로 저희는 다양한 UI 요구 사항에 유연하게 대응하면서도 성능과 효율성을 모두 확보할 수 있었습니다. 대표적인 사례로 최근에 배포된 숏텐츠 서비스를 들 수 있습니다. 숏텐츠 서비스는 문서형 콘텐츠를 개인화된 키워드 방식으로 쉽게 보여주는 서비스로, 모바일, PC 등 여러 플랫폼의 검색, 메인 등 다양한 지면에서 활용되고 있습니다. 숏텐츠는 제공되는 각 지면마다 폰트 크기나 패딩, 버튼 등의 스타일이 조금씩 다르지만 대부분의 구조는 유사합니다. 각각 독립적으로 개발했을 때의 장점도 있지만, 다양한 지면에서 재사용함으로써 효율성을 증대시켰습니다. 디자인 시스템 레거시 시스템에 디자인 시스템을 도입하기 위한 전략 처음 디자인 시스템을 도입할 당시의 상황을 살펴보면, 이미 많은 곳에 디자인 시스템이 적용되어 다양한 사례가 있었지만 저희 팀은 경험이 없었습니다. 또한 Figma와 같은 도구가 편의성을 제공했지만 해당 도구에 대한 이해도가 높지 않은 상황이었습니다. 이미 성공한 사례는 많았기에 저희는 실패 사례에 초점을 두고 리서치를 진행했습니다. 대부분의 실패는 시스템을 만드는 것보다 적용하는 과정에서 발생했습니다. 디자인과 개발 사이의 간극으로 인한 이슈, 디자인 시스템을 만드는 사람과 사용하는 팀 사이의 한계가 주요 문제점으로 드러났습니다. 이러한 부분을 고려하여 저희는 디자인 시스템을 완벽하게 만드는 것보다 서비스에 디자인 시스템을 적용하는 것에 집중했습니다. 따라서 서비스 전체를 대표하는 디자인 시스템보다는, 당장 개발해야 하는 서비스를 기반으로 필요한 부분을 디자인 시스템으로 구축했습니다. 또한 개발자와 디자이너가 함께 협의하고 수준을 맞추기 위해 노력했으며, 적용 비용을 낮추기 위해 디자인 시스템을 만드는 사람과 사용하는 사람을 구분하지 않기로 했습니다. 디자인 시스템 구축 vs 서비스 개발: 무엇이 먼저인가 앞서 언급한 것처럼, 디자인 시스템을 도입할 때 저희는 디자인 시스템 구축과 서비스 개발의 우선순위에 대해 많은 고민을 했습니다. 디자인 시스템을 먼저 완성한 후 서비스에 적용하는 것이 이상적이겠지만, 당시 저희는 디자인 시스템 구축 경험이 부족했기에 디자인 시스템을 먼저 완성한 후에 적용하는 것은 비현실적이라는 결론에 도달했습니다. 그래서 저희는 서비스 개발 과정에 디자인 시스템을 점진적으로 도입하는 전략을 선택했습니다. 특히 통합검색 개편 프로젝트에서 새로운 영역을 대상으로 디자인 시스템을 적용해나갔는데, 이는 필요한 컴포넌트를 개발하고 디자인 시스템을 도입하는 데 적절한 테스트베드 역할을 했습니다. 또한, 초기에는 모든 컴포넌트를 직접 만들기보다는 외부 라이브러리인 Bootstrap을 활용해 빠르게 결과물을 확인하며 디자인 시스템의 가능성을 신속하게 검증했습니다. 그리고 점차 저희만의 컴포넌트를 추가하면서 시스템을 확장해나갔습니다. 디자인 시스템 구축 vs 디자인 시스템 사용: 함께 혹은 따로 디자인 시스템을 도입할 때, 저희는 초기 단계에서 시스템을 만드는 사람과 사용하는 사람을 구분하지 않고 동일한 팀에서 함께 일하는 방식을 택했습니다. 이는 디자인 시스템을 빠르게 적용하는 데 효과적이어서 초기에는 매우 유용했지만, 디자인 시스템의 품질을 향상시키는 데는 한계가 있었습니다. 그 이유는 개발자가 서비스 개발에 집중하면서 디자인 시스템 자체를 개선하기 어려웠기 때문입니다. 디자인 시스템의 문서화나 자체 완성도 측면에서 부족함이 발생했고 이는 생산성에도 영향을 미치기 시작했습니다. 이후 저희는 역할을 분리하는 전략을 도입했습니다. 디자인 시스템을 만드는 팀과 이를 사용하는 팀을 분리함으로써 시스템의 품질을 높이고 각 팀이 자기 역할에 집중할 수 있었습니다. 만드는 팀과 사용하는 팀이 같은 팀에서 일했던 경험이 있었기에, 역할을 분리한 이후에도 서로 잘 이해하고 원활하게 협업할 수 있었습니다. 이를 통해 시스템 적용 과정에서 큰 문제 없이 시스템의 품질을 지속적으로 향상시킬 수 있었습니다. 협업의 비용을 낮추기 위한 노력 협업 비용을 낮추기 위해 같이 일했고, 각 영역의 품질을 높이기 위해 분리했습니다. 협업이 원활했지만 협업 비용을 완전히 해소하기는 어려웠기에 프로세스를 더욱 체계화하여 생산성과 효율성을 높였습니다. 디자인 시스템에 없는 컴포넌트는 서비스에서 필요에 따라 빠르게 만들고, 이후 이를 디자인 시스템으로 이관. 비동기(async)적으로 동기화. 컴포넌트의 조합인 모듈은 디자인 시스템 모듈을 공통화하되, 서비스 개발 시 편의성을 위해 컴포넌트를 조합하여 템플릿으로 만든 후, 이후에 데이터를 바탕으로 비동기적으로 동기화. 즉, 디자인 시스템과 서비스를 정확하게 맞추기보다는 개발 과정에서 생산성으로 높이고 기술적으로 빈 공간을 업데이트하여 효율적인 구조를 만들기 위해 노력했습니다. 또한, 기존에 개발자와 디자이너가 수시로 함께 확인하고 피드백을 주고받으며 디자인 시스템을 구축해나가는 것은 효과적이었지만, 디자이너가 Figma를 업데이트할 때마다 개발자가 디자인 시스템에 반영하면서 많은 비용이 소요되었습니다. 이러한 문제를 해결하기 위해 Figma API를 활용해 주기적으로 업데이트 사항을 모아서 알림을 주는 도구를 개발했습니다. 이를 통해 반복되거나 불필요한 협업 포인트를 줄이고 변경 사항을 놓치지 않을 수 있게 되었습니다. 현재 해결하고 있는 고민 저희는 디자인 시스템을 성공적으로 도입하고 많은 문제를 해결했지만, 여전히 몇 가지 고민이 남아있습니다. 첫째, 새로운 디자이너나 개발자가 기존의 디자인 시스템에 적응하는 데 시간이 오래 걸린다는 문제가 있습니다. 현재는 디자이너와 개발자가 매우 긴밀하게 협업하고 있지만, 앞으로는 더 느슨한 협업 구조를 통해 효율성을 높이고 새로운 인력도 쉽게 적응할 수 있는 체계를 마련할 필요가 있습니다. 둘째, 특정 서비스에만 특화된 컴포넌트를 디자인 시스템에 포함시킬 필요가 있는지에 대한 고민이 있습니다. 모든 컴포넌트를 포함시키는 것이 효율적이지 않을 수 있으며, 특정 서비스에만 사용되는 컴포넌트는 별도로 관리하는 것이 더 나을 수 있습니다. 마지막으로, 시간이 지남에 따라 지속적으로 증가하는 컴포넌트를 어떻게 관리할 것인가가 중요한 과제가 되고 있습니다. 컴포넌트가 너무 많아지면 디자인 시스템 자체가 복잡해져 관리와 유지 보수가 어려워질 수 있습니다. 저희는 재사용 가능한 컴포넌트만을 엄선하고 불필요한 중복을 줄이는 방향으로 시스템을 지속적으로 개선해 나가야 합니다. 이런 고민을 저희가 어떻게 해결해 나가고 있는지 이어서 설명하겠습니다. Developer eXperience 지금까지도 많은 디자인과 개발이 이루어졌지만, 팀원이 늘어나면서 앞으로 디자인과 컴포넌트는 점점 증가할 것입니다. 기존 팀원도 모든 디자인과 컴포넌트를 기억할 수는 없을 것이고, 새로운 팀원도 이를 전부 파악해 두기 어려울 것입니다. 이러한 상황을 해결하기 위해 저희는 다음과 같은 질문을 해보았습니다. 우리가 만든 디자인과 컴포넌트는 무엇이 있을까? 어떻게 만들고 있을까? 어떻게 사용하고 있을까? 어떻게 관리할 수 있을까? 모두에게 동일한 경험을 어떻게 제공할 수 있을까? 이 장에서는 개발자 경험을 쌓고 공유하는 과정을 소개하겠습니다. 디자인 시스템을 만드는 사람과 사용하는 사람에게서 경험을 얻어 데이터로 변환하고, 그 데이터를 처음 접하는 사람 또는 모두에게 제공하면 자연스러운 순환이 이루어질 것입니다. 이렇게 되면 자연스럽게 순환하는 데이터를 통한 자동화로 이어질 수 있습니다. 경험을 공유하는 과정에서는 Webpack, Figma Plugin, Action 등 다양한 형식을 이용할 수 있습니다. 여기에서 얻은 데이터는 텍스트나 JSON과 같은 형식으로 최종 저장되며, 순환하여 더 나은 시스템을 만드는 데 도움을 줄 수 있습니다. META: 경험을 데이터로 만들고 공유하기 자동화를 제공하거나 반복적인 작업을 줄이는 등 편의성을 제공하거나 시스템을 만들기 위해서도 데이터와 정보가 매우 중요합니다. 저희의 경험을 데이터로 나타낼 수 있는 첫 시작인 META를 소개하겠습니다. 여기서 말하는 META는 프로젝트에 있는 모든 정보를 의미하며, CSS 파일, 데모, JSDoc, 템플릿, 컴포넌트, 모듈, 타입 등이 있습니다. 이 META를 통해 경험을 공유하려고 합니다. 저희가 만든 META Analyzer를 통해서, 프로젝트에 담긴 코드와 파일로부터 META를 만들 수 있습니다. META Analyzer는 AST(Abstract Syntax Tree, 추상 구문 트리) 파서를 이용해 만들었습니다. AST는 소스 코드의 문법을 트리 형태로 표현한 구조로, 컴파일러에서 많이 사용합니다. export, let, const, boolean, number 등 저희가 알고 있는 문법 하나하나가 트리 구조의 노드에 해당합니다. 잘 알려진 AST 파서로는 Babel, TypeScript가 있으며 번들러, 트랜스파일러, 프레임워크, 문서 등에서 사용되고 있습니다. META에는 TypeScript 모듈의 AST 파서를 사용했습니다. index, entry에서 시작하여 연결된 모든 파일의 구조를 파악할 수 있습니다. 코드를 파싱하면 다음과 같이 export, function, import, JSX 등 어떤 문법을 사용했는지 알 수 있습니다. AST를 이용하면 문법 외에 어떤 정보를 얻을 수 있을까요? Visual Studio Code의 툴팁에서 인터페이스가 사용된 위치와 정의된 위치를 확인할 수 있듯이, 단순히 인터페이스나 컴포넌트의 유무뿐만 아니라 다음과 같은 연관 관계 정보를 알 수 있습니다. 컴포넌트를 사용했을 때 어떤 모듈에서 가져왔는지 스타일을 사용했을 때 어떤 CSS를 가져왔는지 인터페이스를 사용했을 때 정의된 위치가 어디인지 컴포넌트에는 Props를 사용하고 있고, Props에는 JSDoc, 상위 집합(superset), 상속, 의존 관계 등이 포함됩니다. 이를 통해 컴포넌트와 템플릿을 기준으로 시작하여 연관된 모든 정보를 가져올 수 있습니다. META 활용 사례 컴포넌트와 템플릿, 그리고 연계된 정보는 곧 경험입니다. 저희는 META를 통해 이 경험을 공유할 수 있습니다. 그런데 META로 경험을 공유할 수 있다면 정확히 어떤 것이 가능해질까요? 정보를 어떻게 다룰지는 정보를 가지고 있는 사람에게 달려있습니다. 정보를 어떻게 다루고 경험을 어떻게 표현하고 공유할 수 있는지, META를 활용한 여러 사례를 소개하겠습니다. 디자인과 개발의 1:1 매칭: Figma 플러그인 API를 활용한 Design to Code 첫 번째 사례는 디자인과 개발의 매칭입니다. 개발자는 디자인 요소를 개발로 옮겨야 합니다. 어떤 디자인이 어떤 컴포넌트로 연결되는지 모든 개발자가 알기는 어렵고 새로 입사한 팀원은 만들기도 어려울 수 있습니다. 디자인 요소를 개발로 옮기는 방법을 몇 가지 소개하면 다음과 같습니다. 디자인을 재사용하기 위해 컴포넌트화하고, 컴포넌트화된 디자인에 대해 개발 컴포넌트로서 함수를 정의하고 마크업을 작성하여 개발 디자인의 variants 타입에 따라 디자인의 모양과 값을 확인할 수 있으며, 스타일에 hex 값 또는 variable을 사용 가능 개발 시에는 조건에 따라 Props로 동기화해서 개발하고, 스타일에 CSS variable을 사용해 디자인과 개발 매칭 이와 같이 디자인과 개발 요소가 연결되므로 어떤 디자인이 어떤 컴포넌트와 동기화되어 있는지 파악해야 합니다. 개발 시 디자인의 요소 스타일, 변수, variants 등을 고려해야 하며, 디자인을 통해 마크업, CSS, SVG까지 개발해야 할 수도 있습니다. 여기서 다음과 같은 질문이 제기됩니다. 디자인을 통해 마크업을 쉽게 할 수 있을까? HTML 대신 다른 형식으로 바꿀 수 있을까? 이렇게 만든 디자인과 컴포넌트를 전부 기억할 수 있을까? 디자인 컴포넌트처럼 개발 컴포넌트도 재사용할 수 있을까? 모든 개발자가 처음부터 디자인을 잘 이해하는 것은 아닙니다. 스타일, 변수, variants 등 디자인 요소를 이해하기 어려울 수 있고, 마크업 작업 경험이 적다면 더욱 어려울 수 있습니다. 그렇기 때문에 디자인을 쉽게 이해하고 접근하기 위해 디자인을 코드로 바꿔주는 도구가 필요했습니다. 하지만 에디터로 개발하기에는 목적, 대상, 범용성, 기능이 매우 제한적이고 개발 비용과 유지 보수 비용이 매우 클 것이라고 판단해 조건을 변경했습니다. Design To Code라는 개념은 그대로 유지하되 에디터가 아닌 단순 플러그인으로 한정된 기능만 제공하여, 한 번의 클릭으로 하나의 결과를 얻어낼 수 있게 했습니다. 범용성은 적더라도 목적과 대상이 한정되어 유지 보수도 용이하다고 판단했습니다(이 시점은 Figma의 Variable과 Code Connect가 출시되기 이전입니다). Figma 플러그인 API를 이용하면 Figma 디자인에 접근하여 디자인 정보, 파일 정보, 프로젝트 정보를 파악할 수 있으며, 이 정보를 이용해 디자인을 개발로 변환할 수 있습니다. Figma 플러그인은 크게 API 레이어와 UI 레이어로 나뉩니다. API 레이어: Figma 플러그인 API를 통해 디자인 정보를 확인 UI 레이어: UI를 표현할 수 있지만 디자인 정보를 확인할 수 없음 따라서 API 레이어에서 얻은 디자인 정보를 UI 레이어로 전송해야 합니다. API 레이어에서는 플러그인 API를 통해 얻은 정보와 메서드를 호출해 얻은 정보에서 불필요한 정보를 제거하고 이름, 사이즈, 위치, 스타일, 키 등 필요한 정보만으로 정제된 데이터를 생성해 UI 레이어로 전송합니다. UI 레이어는 옵션에 따라 데이터를 JSX(JavaScript XML), JSON 등의 형식으로 변환하여 사용자에게 보여줍니다. 프로토타이핑한 플러그인은 다음과 같이 간단한 UI로 구성되어 있습니다. 왼쪽에는 가져온 코드를 보여주고 오른쪽에는 코드를 그대로 화면으로 렌더링한 결과를 보여줍니다. 플러그인으로 마크업을 대체할 수 있으므로 세부 작업만 추가하고 개발로 옮겨 시간을 크게 절약할 수 있게 되었습니다. 다만, 이 과정은 디자인 정보를 통해 마크업을 새로 만드는 과정이기에 새로 만드는 경우에 효과적입니다. 하지만 이전에 만든 컴포넌트가 존재하는 경우에는 어떨까요? 이미 존재한다는 사실을 모르고 중복 개발하면 낭비가 될 수 있습니다. 디자인이 어떤 컴포넌트와 연결되는지 알려주고 비슷한 디자인을 매칭해 준다면 이를 방지할 수 있을 것입니다. 플러그인에서 디자인 정보를 토대로 기존의 컴포넌트와 매칭하고, 매칭되지 않으면 앞에서 설명한 방식으로 새로 개발하면 됩니다. 기존에 만든 컴포넌트를 어떻게 플러그인에 연결할까요? 플러그인 API로 얻은 디자인 정보를 컴포넌트의 Props 인터페이스에 JSDoc 주석 형태로 주입합니다. JSDoc 주석을 선택한 이유는 개발과 다른 도구에 영향을 끼치지 않기 때문입니다. 이를 위해 커스텀 태그를 사용해 Figma 정보를 주입합니다. 예를 들어 컴포넌트 집합체에서는 set key를 사용하고, 각 컴포넌트에는 key를 사용하고, 패턴이 있는 이름의 경우에는 이름을 사용해서 디자인과 컴포넌트를 매칭합니다. 컴포넌트 매칭과 유사하게 Figma의 구조나 variant의 타입에 따른 값을 Prop의 JSDoc으로 주입함으로써 디자인과 개발을 연결할 수 있습니다. variant의 타입이 instance, boolean, text인 경우 값을 주입할 수 있으며 그 밖의 커스터마이즈한 값을 직접 수정할 수 있습니다. 이러한 정보는 플러그인 API를 통해서만 얻을 수 있기 때문에 일반적으로 얻기는 어렵지만, 플러그인에서 개발하는 경우에는 매칭에 필요한 정보가 JSDoc에 담겨 제공됩니다. 이러한 JSDoc 정보는 인터페이스에 담겨있고, 인터페이스는 META에 포함됩니다. META가 저장된 위치 URL을 플러그인에서 추가하여 사용할 수 있습니다. 저희가 만든 Search Design System과 디자인 시스템을 사용 중인 Fender도 META를 사용하고 있어서, 두 META를 플러그인에서 추가하여 사용할 수 있고 외부의 컴포넌트도 적합하다면 META로 추가하고 사용할 수 있습니다. 디자인 정보가 담긴 첫 데이터는 아무것도 매칭되지 않은 원시(RAW) 데이터입니다. META에 담긴 컴포넌트 정보와 디자인 정보가 일치하면 원시 데이터는 매칭된 컴포넌트 데이터로 변환됩니다. 매칭된 데이터는 매칭되기 전 데이터와 인터페이스가 동일하기 때문에 이전과 동일하게 JSX나 JSON 또는 그 밖의 다양한 형식으로 출력할 수 있습니다. META에는 Props 정보, 컴포넌트 정보, 연계된 스타일 정보도 포함되어 있습니다. 매칭되는 경우 기존 컴포넌트로 대체하여 스타일을 생략하고, Props 연결, 문서 연결 등 개발자에게 다양한 도움을 제공할 수 있습니다. 또한 Fender의 경우 JSON 형식으로 변환이 가능하며, Fender JSON Simulator에서 복사해 붙여넣어서 동일하게 출력할 수 있습니다. 디자인과 개발을 연결하는 플러그인(Design to Code) 적용 전후의 효과를 요약하면 다음과 같습니다. 플러그인 적용 전 플러그인 적용 후 디자인이 어떤 컴포넌트와 연결되었는지 직접 확인해야 함 연결되는 컴포넌트가 존재하지 않는다면 직접 마크업하여 컴포넌트를 개발해야 함 디자인에 해당하는 컴포넌트를 직접 찾을 필요 없이 플러그인에서 매칭 매칭되지 않는다면 새로운 컴포넌트로서 원시 마크업으로 제공됨 새로운 컴포넌트 개발과 기존 컴포넌트 재사용에 있어 더 나은 편의성을 제공하여 마크업 및 JSON 변환 비용을 절감 디자인 차이점 비교(Design Diff) 두 번째 사례는 디자인 차이점 비교(Design Diff)입니다. 개발자는 디자인을 따라 컴포넌트를 개발합니다. 플러그인을 통해 만든 컴포넌트는 하루가 지나도 잘 매칭이 되고 있을까요? 대부분은 매칭이 잘 되고 있을 것입니다. 하지만 매칭이 되지 않거나 디자인이 바뀌었다면 개발자가 알기 어렵습니다. Figma의 웹훅과 람다를 이용하여 변경 알림을 개발해보았지만, UI가 실제로 바뀌지 않아도 1분마다 알림이 왔고 변경 사항 확인도 불가능했습니다. 그래서 웹훅을 사용하는 대신 직접 차이점을 알아내려고 했습니다. 플러그인을 통해 만든 컴포넌트라면 META에 등록 및 관리되고 있다고 볼 수 있습니다. META에는 컴포넌트마다 Figma 디자인 정보인 key를 포함하고 있습니다. 또한 Figma REST API에서는 node-id나 key를 통해 스냅샷 이미지를 생성할 수 있습니다. META에 등록된 모든 컴포넌트의 스냅샷 이미지를 저장하고, 일정 주기마다 새로운 스냅샷과 이미지를 비교해 변화를 감지합니다. 또한 다음과 같은 변경 사항도 감지할 수 있습니다. 이름이 변경된 경우 key 값 변경으로 인한 매칭 해제 잘라내기로 인한 id, key 값 변경 이러한 변경 사항에 대한 알림을 메신저로 전달합니다. 이를 통해 변경 사항을 바로 알 수 있으므로 오류를 방지할 수 있었고 커뮤니케이션 비용이 감소했습니다. 트리거는 다음과 같은 경우에 발생합니다. 개발 코드가 머지되는 경우 디자이너/개발자의 활동 시간에 약 4번 정도 검사 스케줄 실행 실제 적용 사례를 보면, Q 아이콘의 변경에 따른 디자인 변화가 있었을 때 알림이 발생하여, 디자이너가 놓칠 수 있었던 변경 사항을 바로 확인하고 개발에 반영할 수 있었습니다. 디자인 차이점 비교(Design Diff) 적용 전후를 살펴보면 다음과 같습니다. Design Diff 적용 전 Design Diff 적용 후 디자인 변경 시 다음 회의에서 변경 사항을 공유받아 개발 변경 사항 확인을 놓쳐서 QA 단계에서 이슈 발생 변경 사항에 따른 알림이 오면 사유를 확인하여 즉시 개발 반영 및 공유 가능 지금까지 디자인 변경 2건, 개발 변경 1건을 바로 확인하여 오류 방지 통계 분석(Analytics): 템플릿과 컴포넌트 사용 현황 확인 세 번째 사례는 사용처를 확인하는 통계 분석(Analytics)입니다. 저희가 만든 컴포넌트와 템플릿이 어디에서 사용되고 있는지, 디자인은 어디에서 사용되고 있는지, 그리고 반대로 사용되지 않는 컴포넌트, 템플릿, 디자인이 있는지 확인이 필요했습니다. 정적으로는 코드 빌드를 통해 얻은 META에서 연관 관계를 파악하여 자주 사용되거나 사용되지 않는 컴포넌트, 템플릿을 대략 확인할 수 있습니다. 하지만 데모가 변경되어 실제로는 사용되지 않을 수도 있기 때문에, 실시간으로 로그에 컴포넌트와 템플릿 사용 기록이 담겨 전송된다면 더욱 정확하게 사용 현황을 분석할 수 있습니다. 또한 META와 연동하여 전체 템플릿, 컴포넌트 중 가장 많이 사용된 것은 무엇인지, 미사용 템플릿 현황은 어떤지, 해당 미사용 템플릿이 적용된 서비스가 종료되었는지 혹은 출시 전인지 확인하여 정리 대상 여부를 판단할 수 있습니다. Fender와 SDS(Search Design System) META를 통해 템플릿의 실제 사용처를 확인하는 통계 페이지에서 확인할 수 있는 정보는 다음과 같습니다. 템플릿과 컴포넌트의 관계 사용 여부 SDS 컴포넌트를 얼마나 잘 사용하고 있는지 여부 미사용 여부와 기간 등 문서(Docs) 네 번째 사례는 문서입니다. 문서에서는 프로젝트에 어떤 컴포넌트가 있는지, 컴포넌트의 역할, 모습, 사용 방법 등을 확인할 수 있습니다. 여기서 META를 이용하면 인터페이스 prop, type 등에 해당하는 기본적인 정보와 JSDoc 정보를 통해 클래스 이름, 설명, Figma key 등을 확인할 수 있어, 예시와 연결하여 control, 인자 타입, 설명에 도움을 줄 수 있습니다. 이외에도 여러 도구에서 META를 활용할 수 있습니다: Visual Studio Code와 같은 IDE(Integrated Development Environment, 통합 개발 환경) 도구 배포된 컴포넌트에서 JSDoc이 자동으로 툴팁을 제공해 문서 역할을 수행하며 개발 시 즉각적인 도움말 제공 Storybook META를 이용해 타이틀 영역을 자동으로 생성 Figma Key를 이용해 컴포넌트와 연결된 디자인 링크를 추가 Figma 플러그인 디자인과 연결된 컴포넌트 확인 사용 예시를 바로 확인 가능 또한 META를 통해 어떤 Prop이 ReactElement로 사용되었는지에 따라 반자동으로 디자인 구조인 Anatomy를 확인할 수 있습니다. Prop이 어디에 반영되는지, 사이즈와 사용되고 있는 클래스까지 확인할 수 있습니다. 최소한의 작업으로 META에서 사용자에게 필요한 정보를 추출하여 보여줄 수 있고, 문서와 플러그인의 연결, 문서와 디자인의 연결을 통해 언제 어디서든 사용 방법에 대한 도움을 제공할 수 있습니다. 네이버 검색 FE 시스템 아키텍처 디자이너는 디자인 시스템을 설계합니다. 이렇게 설계된 디자인 시스템은 Search Design System 플러그인을 통해 컴포넌트로 전환됩니다. 디자인 시스템을 기반으로 서비스 디자인을 설계하며, 물론 디자인 시스템에 없는 디자인도 존재할 수 있습니다. 기존의 디자인 시스템 컴포넌트는 Search Design System 플러그인을 통해 매칭되고 새로운 컴포넌트는 새로 개발합니다. 개발한 결과는 Fender를 통해 서비스됩니다. 서비스로 출시된 이후에는 사용자의 피드백과 META를 통해 얻은 정보를 바탕으로 개선할 부분, 반복되는 작업 등을 파악합니다. 이 정보는 다시 디자인 시스템과 서비스에 반영됩니다. 이러한 순환 구조를 통해 데이터를 기반으로 지속적으로 성장 가능한 FE 시스템을 구축하고 있습니다. 남아있는 고민 디자인 토큰을 설계하고 Figma와 연동하는 방법, 디자이너와 개발자, 디자인 시스템을 만드는 팀원과 사용하는 팀원 사이의 워크플로우, 서비스를 배포하고 오류를 수집해서 개선하는 DevOps 등 많은 주제가 있지만, 지면 관계상 여기서는 다루지 않겠습니다. 여전히 고민은 남아있습니다. 새로운 팀원이 왔을 때 이런 프로세스에 잘 적응할 수 있을지 현재 UI 재활용성이 사후에 많이 개선되는데, 사전에 재활용성을 높일 수 있는 방법은 없을지 UI 재활용만큼 인터랙션도 재활용할 수 없을지 전보다 많은 데이터를 볼 수 있게 되었는데 이를 어떻게 더 잘 활용할 수 있을지 이러한 고민은 지속적으로 해결해나가고 그 과정을 다른 기회에 공유하겠습니다. 이 글은 TEAM NAVER CONFERENCE 'DAN 24'에서 발표한 내용을 토대로 작성되었으며, 발표 내용과 자료는 DAN 24에서 보실 수 있습니다.

모닥불 10화 특집: 캠프파이어 에피소드 🔥 이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요. 사전에 접수된 시청자 여러분의 다양한 사연과 질문 그리고 코드 리뷰까지! 지금 바로 확인해보세요!

안녕하세요. LINE Plus ABC Studio 기획자 한영주입니다. 저는 일본 최대 규모의 배달 서비스인 데마에칸(Demaecan, 出前館) 앱을 기획하고 있습니다. 한국의 배...

안녕하세요. 누구나 쉽게 시작하는 클라우드 네이버클라우드 ncloud.com 입니다. 고객 데이터를 분석하고 싶은데 어떻게 해야 하지? 쉽게 홈페이지의 개선 포인트를 찾을 수 있을까? 홈페이지의 개선 포인트를 찾고 싶은데 어디서부터 시작해야 할지 막막하고, 데이터 분석부터 시작하려고 하니 어려운 외산 툴을 익히느라 힘들었던 경험을 했던 분들이 많이 있...

안녕하세요. LINE Plus ABC Studio에서 일본 음식 배달 서비스 Demaecan(出前館, 이하 데마에칸)의 디자인을 담당하고 있고, 사용자의 다양한 목소리를 담을 수 ...

유종의 미 그리고 회고

Kotlin Multiplatform은 에코시스템의 라이브러리 수가 2024년에만 35% 늘어나며 빠르게 성장하고 있습니다. 그러나 라이브러리 수가 그 어느 때보다 많아졌음에도 사용 사례와 타깃 플랫폼에 맞는 라이브러리를 찾기는 여전히 쉽지 않습니다. iOS와 Android에서 권한을 처리할 솔루션을 찾는 경우도, 모바일과 웹을 모두 지원하는 Comp...

Compose Multiplatform은 개발자가 다양한 플랫폼에서 UI 구현을 공유할 수 있도록 JetBrains에서 설계한 선언적 UI 프레임워크입니다. 1.7.0 릴리스는 공통 코드의 구성 요소 추가, 타입에 안전한 탐색 지원, iOS에서의 큰 성능 개선을 제공하고 최신 Jetpack Compose 업데이트의 변경 사항을 포함합니다. 이번 릴리스...

안녕하세요. 드라마앤컴퍼니에서 현재 채용 서비스를 개발하고 있는 웹 프론트엔드 개발자 오종택입니다. 이전에는 동료 분들의 비즈니스 임팩트를 극대화 하기 위한 UTS(User Targeting System, 조건에 맞는 유저를 찾아주는 쿼리 빌더) 등의 인터널 제품을 만들기도 했습니다.리멤버 웹 팀은 리멤버 블랙, 리멤버 채용 솔루션 등 모든 서비스의 ...

주요내용 25년 1월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. Web Almanac 2024 전 세계 1천7백만개의 웹사이트를 분석, 현재 웹 기술의 사용과 웹페이지들의 상태를 확인할 수 있습니다. JavaScript Benchmarking Is a Mess JS 벤치마크 수행결과는 얼만큼 신뢰할 수 있을까요? 어떤 요소들이 결과에 영향을 미치고 있을까요? How Big Technical Changes Happen at Slack Slack은 기술적 변화를 어떻게 관리하고 기술 도입을 위한 전략을 확인해 보세요. Anders Hejlsberg: How we wrote the TypeScript compiler TS 코어 개발자로부터 들어보는 TS 컴파일러 개발 이야기 >> FE News 25년 1월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기