기술 블로그 모음

deFign : 네이버페이의 디자인 시스템을 정의하다안녕하세요. 네이버페이 금융FE, 디자인시스템TF 소속 안재연입니다.출처: https://m.post.naver.com/viewer/postView.naver?volumeNo=36104441&memberNo=30633733지난 6월 21일, 네이버페이 모바일 5탭이 오픈되었습니다. 네이버 증권과 부동산이 네이버페이 소속으로 변경된 후 네이버페이 하나로, 결제부터 금융까지 이룰 수 있는 첫 걸음을 떼게 되었습니다. 이와 함께 네이버페이의 모든 서비스를 한 눈에 볼 수 있도록 각 서비스 하단에 5탭 컴포넌트가 추가되었습니다.‘모든 서비스에서 같은 컴포넌트를 보여준다면, 한 곳에서 개발하고 관리하는게 편하지 않을까?’라는 생각부터 출발하여 네이버파이낸셜의 모든 서비스에서 공통으로 사용할 수 있는 디자인 시스템을 설계하게 되었습니다.이 글의 대상 독자는 디자인 시스템을 도입 예정이시거나, 도입하는 과정에서 방향성으로 고민하시는 분들 혹은 디자인 시스템에 관심을 가지고 계시는 분들입니다.Design System디자인 시스템이 무엇인지 생소하신 분들도 있을 것이라 생각합니다. Design은 말 그대로 화면의 UI를 어떻게 설계할 지 고민하는 것이고, System은 하나의 체계를 갖춘다는 의미입니다. 즉, Design System이란 화면의 UI 요소 중 공통 패턴과 주요 컴포넌트를 추출하여, 구성원들이 이를 효율적으로 사용하는 하나의 프로세스를 의미합니다.네이버페이는 어떻게 디자인 시스템을 도입하게 되었을까요?초기의 네이버페이는 운영하고 있는 서비스들의 규모가 그렇게 크지 않았기 때문에, 각 서비스에서 개선 요청 사항들을 각각 반영하고 있었습니다.하지만 운영하는 서비스가 증가하고, 각 서비스의 규모가 커지면서 조금씩 문제 상황이 발생하기 시작했습니다. 동일한 UI임에도 각 서비스에서 UX 향상을 위해 추가한 개선 사항들이 서비스별로 조금씩 다른 동작, 조금씩 다른 코드들을 초래한 것입니다.저희는 디자인 시스템 도입으로 위와 같은 상황을 개선하고자 했습니다. 사용자가 네이버파이낸셜의 모든 서비스에서 동일한 UI, UX를 경험할 수 있고, 개발자가 공통된 UI를 서비스에 쉽게 적용할 수 있도록 디자인 설계부터 마크업 조직, 개발 조직과 함께 기준을 세워 작업의 생산성 향상을 도모하였습니다.우리가 만들고 싶은 디자인 시스템디자인 시스템을 만드는 구성원들과 함께 이야기 해 보았을 때, 우리가 만들고 싶은 디자인 시스템의 키워드는 다음과 같았습니다.#일관성 #효율성 #커뮤니케이션_기준 #공통_UI_라이브러리 #공통_인터랙션 #유연성 #확장성 #UX_가이드 #UX_Writing_가이드 #스토리북키워드를 중심으로 대원칙을 설계하고 작업을 시작하게 되었습니다.대원칙 1. 디자인 변경에 대한 파편화는 가급적 통제한다.대원칙 2. 디자인 변경사항의 빠른 적용을 위한 구조를 설계한다.대원칙 3. 각자의 생각과 노력은 하나의 언어로 표현하여 동일한 이해도를 가져간다.디자인 시스템 작업 과정 살펴보기디자인 시스템 작업 과정을 간단히 소개하면 다음과 같습니다.컴포넌트 단위로 디자인을 설계하여 Figma에 추가합니다.디자인 시스템 컴포넌트에서 사용하는 수치들은 디자인 토큰으로 추출하여 모든 서비스, 컴포넌트에서 함께 사용합니다.컴포넌트는 디자인, 마크업, FE 조직이 함께 만듭니다.디자인 토큰 추출하기모든 서비스, 컴포넌트에서 공통으로 사용하는 디자인 토큰은 자동화하여 추출했습니다.자동화 추출에는 Figma API와 Figma Plugin을 사용하였습니다.Figma API : https://www.figma.com/developers/apiFigma Plugin : https://www.figma.com/plugin-docs/개발에서 사용하기 편한대로 추출 형태도 다양화 하였습니다.컴포넌트 개발하기각 서비스에서 공통적으로 사용하는 UI는 사용성 검토 후 Figma 컴포넌트로 도출합니다. 디자이너가 컴포넌트와 variant(option)을 정의하면 마크업 개발자와 FE 개발자가 컴포넌트를 리뷰하고, 더 나은 사용성을 위해 variant와 디자인 등을 조정합니다.이후 마크업과 FE 개발자들은 추출한 디자인 토큰을 활용하여 컴포넌트 개발을 시작합니다. 이때 엣지 케이스 대응, 디바이스 분기, 에러 케이스 대응을 추가하여 최대한 많은 경우를 커버할 수 있도록 개발합니다.스토리북으로 컴포넌트를 사용하는 개발자들의 생산성 향상만들어진 컴포넌트와 디자인 토큰은 스토리북을 통해 쉽게 형상을 파악할 수 있도록 하였습니다. 다양한 서비스에서 사용하는 만큼, 각 서비스마다 다른 버전을 사용할 수 있어 버전 별로 스토리북 확인이 가능하도록 기능을 추가해두었습니다.공통 인터랙션 혹은 hook 사용이 필요한 컴포넌트의 경우 Docs를 보다 구체적으로 작성하였습니다. 사용법과 사용 예시를 모두 첨부하여 Docs만으로도 손쉽게 컴포넌트 적용이 가능합니다.Footer 컴포넌트 개발기deFign에 대한 소개에 이어 FE 개발자로 디자인시스템 Footer 컴포넌트를 개발하고 출시하기까지의 과정과 경험을 공유합니다.1. 디자인 전달Footer 컴포넌트는 네이버페이 모든 서비스 최하단에 노출되는 컴포넌트입니다. 각 서비스마다 노출되는 정보가 다르기 때문에 디자이너분께서 모든 케이스를 정리해서 figma로 공유해주셨습니다.2. 초기 인터페이스 고민처음 전달받았던 Footer 컴포넌트는 FooterQuickMenu 컴포넌트와 FooterInfo 컴포넌트로 구성되어 있었습니다. 서비스 별로 노출할 정보를 기준으로 어떤 정보를 props로 받아야 하는 지, static한 정보로 보여주어야 할 지 고민했습니다.제가 초기에 생각했던 인터페이스는 다음과 같습니다.FooterQuickMenu : 메뉴 종류와 개수는 서비스마다 다르니, 메뉴 List를 props로 받아서 노출하는 형식// FooterQuickMenu props 예시const props = [ { title : '로그아웃', }, { title : '면책조항', tooltip : true, // 메뉴에 툴팁을 노출하는 케이스 tooltipIcon : <TooltipIcon />, }]FooterInfo : 법적 고지도 서비스마다 달라 props로 받기 / 사업자 정보는 동일하기 때문에 static3. 디자인시스템 팀원들과 함께 인터페이스 의논해보기제가 고민한 인터페이스가 완벽하지 않을 수 있기 때문에, 팀원들과도 함께 검토해 보았습니다.팀원들은 Footer에서 노출하는 정보가 각 서비스마다 하나로 고정된다면, 서비스 type만 props로 받고 필요한 정보는 디자인 시스템에서 모두 제공하는 것이 더 사용성이 좋겠다는 의견을 제시해주었습니다. 또 Footer는 사용처에서 굳이 FooterQuickMenu, FooterInfo를 각각 선언해서 사용할 필요가 없으니 Footer 컴포넌트 하나로 사용자에게 제공하는 것이 어떻겠냐는 의견을 주셨습니다.그리하여, 최종 Footer의 인터페이스를 다음과 같이 정할 수 있었습니다.<Footer type='stock' // type으로 각 서비스의 타입 전달 overrideMenu={{ // 기존에 노출되던 메뉴의 title, url 등을 수정할 때 전달 '전체서비스': { url: 'https://new-url.naver.com' } }} /> Footer 컴포넌트 뿐만이 아니라, 모든 컴포넌트 제작 과정에서 인터페이스를 다 함께 고민하였었는데, 이 과정 덕분에 더 좋아진 사용성을 가진 컴포넌트를 제작할 수 있었던 것 같습니다.4. 예상치 못했던 예외 케이스의 등장계획한 대로, 예상한 대로 모든 일이 진행된다면 정말 좋겠지만 그렇지 않은 것이 현실입니다. Footer 컴포넌트를 개발할 때도 예상치 못했던 예외 케이스가 등장하였습니다.Footer 컴포넌트에서는 각 서비스의 type만 전달받기로 하였는데, 부동산에서만 각각 다른 8개의 Footer가 필요하다는 요청이 추가된 것입니다. 기존의 인터페이스에서 overrideMenu prop을 제공하였지만, 현재 노출되고 있는 메뉴의 title, url 정도만 수정이 가능하고 새로운 메뉴를 추가할 수는 없었기 때문에 overrideMenu 를 활용할 수는 없었습니다.처음에는 type을 8개를 추가해야 할까 고민하였습니다. 하지만 공통적인 부분만 부동산 type으로 제공하고, 수정이 필요한 menu는 custom해서 사용할 수 있도록 overwriteMenuList prop을 열어주는 방향으로 진행하게 되었습니다.<Footer type='realEstate' overwriteMenuList={[ { title: isLogin ? FOOTER_QUICK_MENU_TITLE.LOGOUT : FOOTER_QUICK_MENU_TITLE.LOGIN, href: '#', onClickLogin: () => { alert('클릭 로그인'); }, onClickLogout: () => { alert('클릭 로그아웃'); }, }, { title: FOOTER_QUICK_MENU_TITLE.ALL_SERVICE, href: isMobile ? URL.ALL_SERVICES.MOBILE : URL.ALL_SERVICES.PC, }, FOOTER_QUICK_MENU_ITEM_MAP.realEstate['약관 및 정책'], // Footer에서 기본으로 사용하던 요소는 export 해 두어, 사용처에서 쉽게 재선언이 가능하도록 했습니다. ]}/>5. 적당히 열리고 적당히 닫힌 인터페이스overwriteMenuList prop을 추가할 때 부동산 서비스 개발자분께서 ‘overwriteMenuList를 사용하려면 Footer에서 기본으로 사용하는 모든 menu들도 재작성해야하나요?’라는 질문을 해주셨습니다.서비스별로 공통적으로 사용하는 menu라면 상수로 선언한 후에 export 해 두면, overwriteMenuList를 사용하더라도 각 서비스에서 모든 menu를 재작성할 필요 없이 필요한 것만 import하여 간편하게 사용할 수 있겠다는 생각이 들었습니다. 그래서 추가된 것이 위 예시의 FOOTER_QUICK_MENU_ITEM_MAP 입니다. 원하는 메뉴는 이미 FOOTER_QUICK_MENU_ITEM_MAP 에 선언되어 있으니, 가져다 쓰기만 하면 됩니다.이처럼, Footer를 만들면서 어떻게 하면 사용처에서 조금 더 쉽게 사용할 수 있을까를 많이 고민하게 되었습니다.너무 열어준 인터페이스를 제공하면, 디자인 시스템 Footer는 공통된 마크업만 전달할 뿐, 사용처에서는 모든 정보를 직접 선언해서 사용해야 했습니다. 사실상, 이미 각 서비스에서 사용하고 있던 Footer와 별반 다를게 없었죠.반면 너무 닫힌 인터페이스를 제공하면, 위의 부동산 Footer의 경우처럼 예상치 못한 케이스에 당황하는 사태가 발생하게 됩니다.그래서 인터페이스를 제공할 때 많은 고민과 대화를 했었습니다. Footer 컴포넌트를 만들면서 느낀 점은, 각 서비스의 개발자 분들과 대화를 하면서 적당히 열림과 적당히 닫힘 사이의 인터페이스를 함께 만들어 나가야 한다는 것이었습니다. 열림과 닫힘 사이 딱 좋음이란 기준은 너무나도 주관적이어서 제가 결정할 수 있는 것이 아니더라구요. 서비스 개발자 분들과 꾸준히 대화를 하면서 어떻게 하면 더 편하게 사용할 수 있을까를 끊임없이 물어보았던 과정이 더 나은 인터페이스를 가능하게 해주었다고 생각합니다.deFign : 네이버페이의 디자인 시스템을 정의하다.이런 과정을 거쳐 하나둘씩 만들어진 네이버페이의 디자인 시스템이 바로, deFign입니다. 네이버페이의 디자인 시스템을 정의한다는 의미를 담고 있습니다. (사담이지만, 이름이 정말 마음에 듭니다🥰)2023년 6월 21일 네이버페이 모바일 5탭 서비스를 오픈에 맞추어 모든 서비스에 디자인 시스템 컴포넌트들이 적용되었습니다. 이제 공통된 컴포넌트는 모두 deFign에서 설계, 개발, 관리됩니다.deFign의 도입으로 네이버페이의 어떤 서비스를 이용하더라도, 같은 UI와 사용성을 가진 컴포넌트를 마주할 수 있어 사용자 경험은 보다 향상될 것입니다. 또한 각 서비스의 개발자 역시 반복되는 비슷한 코드의 추가, 분기문 추가의 지옥을 벗어나 보다 효율적인 개발 life가 가능해 질 것입니다.앞으로의 deFign저희 deFign 팀은 version 1.0.0 오픈에 이어 Phase 2도 준비하고 있습니다. 더 많은 UI의 공통화, 동일한 언어로의 설계를 이루어 많은 디자이너와 개발자의 생산성 향상에 힘 쓸 예정입니다.이와 함께 통계 시스템을 구축하여, 사용자가 어떻게, 얼마나 디자인 시스템을 사용하는지에 초점을 맞추어 방향을 설계할 계획입니다.더 발전할 deFign 기대해 주시길 바랍니다!긴 글 읽어주셔서 감사합니다.deFign : 네이버 페이의 디자인 시스템을 정의하다 was originally published in NAVER Pay Dev Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

데이터를 통합하여 관리할 것인가? 각 도메인이 데이터를 관리하되 활용 관점의 통합을 추구할 것인가? 데이터 메시를 달성하기 위한 방법은 여러 가지가 있을 수 있으며, 적용할 조직에 맞게 필요한 개념만 일부 채택할 수도 있습니다. 업무의 이해가 중요한 금융 데이터의 경우, 데이터 메시 아키텍처를 통해 데이터 관리에 대한 새로운 시사점을 발견할 수 있습니다.

디지털 트윈은 다양한 애플리케이션을 통해 조직이 보다 효율적이고 혁신적인 비즈니스 모델을 만들고 새로운 수익원을 창출할 수 있는 확장성을 가지고 있어서 다양한 산업군에 적용이 가능합니다. 그중 가장 활용도가 높은 분야는 바로 제조업입니다. 디지털 트윈을 사용하여 제조 현장에서 발생한 데이터를 분석하고 도메인 날리지를 접목함으로써 소재·부품·장비 공정 ...

디지털 트윈의 시뮬레이션은 단순히 데이터를 통해 예측하는 것에 그치지 않습니다. 가장 중요한 전제는 실제 환경을 가상에 동일하게 반영해야 한다는 점입니다. 단순히 전기, 기계 모델을 만드는 것이 아니라 질량으로 인한 중력, 온도, 습도 등 물리적 환경이 그대로 반영되어야 하고 그 이후에 기구의 위치 및 속도 이동 등 행동학적 요소가 적용된 뒤 이 모든...

일상 생활에 필요한 서비스를 하나의 앱에서 원스톱으로 처리하는 모바일 앱을 ‘슈퍼앱’이라고 합니다. 슈퍼앱의 등장으로 전에 없던 시장을 만들고 있고, 스마트폰 앱에 불과했던 애플리케이션이 온갖 서비스가 융합된 플랫폼으로 진화하고 있으며, 기술 경계를 허물고 넓히며 거대 생태계의 중심이 되고 있습니다.

과거 ERP 시스템은 획일적이고 경직되어 있었습니다. 하지만 오늘날 빠르게 변화하는 기술과 진화하는 고객 선호도에 따라 유연하고 최적의 애플리케이션과 신속하게 호환될 수 있는 엔터프라이즈 소프트웨어 포트폴리오가 필요해졌습니다. 컴포저블 ERP를 사용하면 원하는 SaaS 또는 클라우드 기반 CRM, HRM, SCM 또는 기타 ERP 구성 요소를 선택하여...

디지털 트윈 소프트웨어를 사용하면 데이터센터를 어떤 구성으로든 배치하고 시뮬레이션하여 예기치 못한 문제를 시험해볼 수 있습니다. 심지어 냉각 장치나 공기 흐름 장치 고장, 회로 차단기 오작동과 같은 치명적인 결함까지 시험 가능합니다. 그 다음 이런 극한의 조건에서 시스템이 어떻게 대응하는지 보게 됩니다.

데이터센터와 네트워크 간에는 늘 긴밀한 관계가 있었습니다. 클라우드 사용 및 온라인 액세스 의존성이 증가함에 따라 이런 관계는 더욱 긴밀해질 것입니다.

헤드리스 아키텍처를 이용한 플랫폼은 데이터베이스, 비즈니스 로직, 통합 기능을 갖춘 완전한 백엔드 시스템을 제공하는 API 우선 아키텍처를 내장합니다. 개발팀은 플랫폼의 API 혹은 SDK를 사용해 고객 대면 프론트엔드 사용자 경험 및 통합을 제대로 맞춤화할 수 있습니다.

고가용성과 자동 확장, 자체 치유가 되는 클라우드 인프라는 그리스 신화의 머리 많은 괴물 히드라만큼이나 회복력이 뛰어납니다. 이런 회복력의 대부분은 컨테이너를 사용해 만듭니다.

들어가며 안녕하세요. 트렌비 스토어팀에서 백엔드 개발을 맡고 있는 오언입니다. 최근 마이크로 서비스 환경에서 API 문서를 효율적으로 관리할 수 있는 공용 API 문서 서버를 구축하였고 이에 대한 내용을 공유하고자 합니다. 1. API 문서를 효율적으로 관리할 수 없을까? API를 제공하거나 사용하는 개발자들에게 있어서 API 명세를 정리하고 공유하는...

이스티오 프로젝트는 CNCF에 가입하여 인큐베이팅 프로젝트가 되었습니다. 그 배경에는 이스티오에 많은 시간을 투자한 구글이 기존의 이스티오 상표권을 포기하고, Linux Foundation에 기증한 것이 있었습니다. 기존에도 OUC에 속한 오픈소스였으나, CNCF에 가입하게 되면서 장기적으로 개방형 오픈소스를 통해 발전해 나갈 것이라고 생각합니다.

서비스 메시는 애플리케이션 트래픽을 관리, 추적 및 보안성을 강화하기 위해 플랫폼 레이어에 구성되는 네트워크 제어 방법입니다. 서비스 메시는 데이터 플레인, 컨트롤 플레인 두 개 컴포넌트로 구성되는데, 데이터 플레인은 애플리케이션 사이에 있는 프록시 네트워크로 구성되고, 컨트롤 플레인은 프록시에게 수행할 작업을 알려주고 메시를 작동하는 사람을 위한 인...

안녕하세요. 올리브영에서 앱 개발을 담당하고 있는 쌈(ssam) 입니다. 약간은 늦었을 수도 있지만 올리브영의 성장과 함께 앱이 어떤 변화를 겪고 있는지 공유드리려고 하며 앱 아키텍처 도입 시리즈의 첫 번째 이야기로 올리브영의 앱(Android…

클라우드 컴퓨팅은 기업이 기술을 소비하는 방식을 바꾸며 확실한 진화를 이루었습니다. 어떤 신기술이라도 장단점은 있기 마련이다. 이제 막 클라우드 여정을 시작하려는 기업이라면, 이 정보를 목표를 달성하고 장애물을 피하는 데 활용하기 바랍니다.

오픈소스 소프트웨어는 세계 경제를 뒷받침하며 대부분 기업의 핵심 인프라입니다. 전 세계 5,600만 명의 개발자가 오픈소스 프로젝트에 기여하고 기업의 95%가 개방적인 혁신 방식을 활용합니다. 오픈소스는 소비자의 눈에 직접 보이지 않을 수 있지만, 사람들을 연결하고 원격 작업을 구현하며 금융 산업과 결제 관리의 효율성을 높입니다.

안녕하세요. 저는 Trading Platform팀 Backend 엔지니어로 근무하고 있는 현건수(Pir)입니다. 이번에 투표시스템을 맡게 되어, 일반 투표와 선착순 투표시스템 그리고 앞으로 확장적으로 늘어날 투표 시스템 아키텍처에 대해 OOP 기반으로 구성한 것을 공유하려고 합니다. 목차 투표 시스템 요구사항 투표 시스템 아키텍처 요구사항 투표 시스템...

줌인터넷에는 혁신적이고, 사용자의 입장에서 더욱 쉽고 편리하게 콘텐츠 경험을 제공할 수 있도록 끊임없이 고민하는 개발자분들이 계십니다. 빅데이터팀, 핀테크개발팀, 포털개발팀, 부설 연구소 그리고 인프라 보안팀까지! 같은 개발실이지만 업무와 역할이 팀마다 천차만별인데요. 줌인터넷의 개발자분들은 어떻게 업무를 하고 있는지 또 맡고 계신 업무의 영역은 무엇...

National Digital Twin은 각 부문 및 조직 전반에 걸쳐 최적화 계획이 가능한 연결된 디지털 트윈(Connected Twins)의 생태계가 될 것입니다. 예를 들어, NDT상에서 ‘시차 근무 시간 제도’가 적용된 상황을 시뮬레이션했을 때, 국가 및 지역 단위에서 운송과 교통이 에너지 네트워크에 미치는 영향을 모델링하고 시뮬레이션 하여 그...

기업이 구현하고 활용하는 디지털 트윈의 핵심 영역은 시뮬레이션입니다. 물리적이고 시각적인 실험도 가능하고 더 나아가 데이터 분석을 통해 현상을 해석하고 대안을 도출하는 것도 포함됩니다. 예를 들어 공장에서는 각종 설비 데이터가 가상공간에 표현되고 시뮬레이션을 통해 장비를 운영함으로써 문제점을 예측해 볼 수 있습니다. 이처럼 가상공간에서 예측된 문제점을...

컬리 프로덕트 디자인 원칙을 소개합니다

잼스택(Jamstack)은 점점 인기가 높아지고 있는 웹 개발 방식으로, 웹 개발 및 웹 페이지의 다운로드 속도를 높이기 위해 주로 사용됩니다. 데브옵스와 CI/CD에서 파생된 잼스택은 인터랙티브 웹 페이지 구축의 오랜 전통을 뒤집었다는 점에서 주목받고 있습니다.

카프카 스트림즈를 추가하다

카프카 설정 튜닝만으로 색인 속도를 개선하다

기업은 전략, 구조, 프로세스 및 인력 구성에서 수많은 개선 사항을 부가적으로 발견할 수 있다. 보다 독립적이고 전문화된 서비스 소프트웨어 개발, 테스트 및 배포를 위한 자동화된 도구, 더 빠른 릴리즈를 가능하게 한다. 내부 IT 인력은 업무 효율성이 높아지면서, 재투자 또는 비용 절감을 위한 자본을 확보하는 데 기여하게 된다. 이러한 민첩성은 기업과...

오늘날 기업은 변화에 앞서 준비해야만 합니다. 어떤 아키텍처라도 변화를 수용할 수 있어야 합니다. 시스템이란 처음에는 최적화된 상태이겠지만, 시간이 지나도 계속 좋은 아키텍처이지는 않습니다. 지금 제대로 동작하는 시스템을 만드는 것만으로는 충분하지 않습니다. 내일과 모레의 빠른 변화도 수용할 수 있어야 합니다.

글로벌 물류는 단기적으로는 팬데믹과 백신접종의 영향을 받을 것이지만 장기적 전망은 물류의 구조적 대 변화의 물결에 의해 좌우될 것이다. 결국 수요의 이례적인 변화로 나타난 물류 체인상의 장애는 글로벌 무역패턴이 정상화되면서 물류공급망의 취약점을 재 보강하는 계기가 될 것이며 장기적 측면에서 해상운송산업의 구도에도 대 변화를 촉진하는 결과가 될 것으로 ...

5~6년 전부터 MSA에 대해서 많은 논의가 있어왔습니다. MSA와 같은 모듈형 아키텍처 스타일은 클라우드 기반 환경에 적합해 높은 인기를 구가하고 있습니다. 특히 도커(Docker), 쿠버네티스(Kubernetes) 등과 같은 컨테이너 기반의 플랫폼과 조합이 잘 어우러지면서 클라우드 플랫폼과 MSA는 서로 끌어주고 밀어주면서 발전하고 있습니다.

글로컬(Glocal)은 세계화를 추구함과 동시에 해당 지역의 문화 혹은 고객의 니즈에 맞는 제품 및 서비스를 제공하는 것입니다. 기업들은 왜 지극히 세계적이면서도 지역적인 글로컬을 현지화 전략으로 선택한 것일까요?

참고: 해당 글은 2020년 여름에 작성 되었습니다. 현재와는 많은 기술격차가 있을 수 있습니다.User Response: Click Prediction (Estimation)특정 고객으로부터 추출된 노출과 클릭 히스토리는 큰 의미를 갖게 됩니다. 고객에게 타게팅 된 광고를 제공하고 노출시키는 것을 위한 발판이 되기 때문입니다. 이는 매력적인 광고 상...