국내 IT 기업들의 기술 블로그 글을 한 곳에서 모아보세요
Gateway API 솔루션의 미래를 개척하는 NGINX Kubernetes 커뮤니티가 Gateway API 의 일반 가용성을 공식적으로 발표한 지 거의 1년 반이 지났습니다. 이는 Kubernetes 클러스터에서 네트워킹 및 트래픽 관리가 처리되는 방식을 새롭게 정의한 이정표입니다. 이는 단순한 증분적 업데이트 그 이상이었습니다. 이는 클라우드 기반...
이 글에서는 글로벌 컨퍼런스인 COP29, CES 2025, WEF 2025에서 강조한 ESG 관련 메시지를 통해 ESG 경영에 영향을 미칠 수 있는 주요 이슈들을 재조명하고자 합니다.
이 아티클에서는 기업 애플리케이션을 구축 운영할 때 기업과 사용자 모두에게 높은 가치를 제공하는 클라우드 네이티브 애플리케이션의 특장점에 살펴봅니다.
매장 도메인을 구현해 나가는 여정 안녕하세요! 올리브영에서 매장 도메인을 담당하고 있는 알렉스입니다 :) 이전 글에서 저희는 이벤트 스토밍, 바운디드 컨텍스트 식별, 컨텍스트 매핑 등 DDD…
매장 도메인 분리의 첫걸음 안녕하세요! 올리브영에서 매장 도메인을 담당하고 있는 알렉스입니다 :) 2023년도 11월에 주니어 개발자의 우당탕탕 입사기로 첫 포스팅을 하고 벌써…
복합건물 (아파트, 다세대 주택) 주소정제 정복
사용자의 배달 주소를 기반으로 어느 행정동/법정동에 속해 있는지를 판단하기 위해 기존에는 C++로 작성된 웹 서버를 사용하였습니다. 서버 한 대당 피크 시간 기준 2000TPS를 상회하는 많은 요청을 10ms 이하 시간으로 응답할 수 있는 높은 성능을 제공했지만, C++의 특성상 여러가지 단점이 존재했습니다. 이를 Java 및 Spring Boot 기반으로 전환하기까지의 경험을 공유합니다. 배경 배달의민족에서는 배달 주소를 기반으로 어느 […] The post 이젠 보내줄 때가 되었다. 대규모 트래픽의 C++ 시스템 Java로 전환하기 first appeared on 우아한형제들 기술블로그.
안녕하세요.️ 쿠폰증정스쿼드에서 백엔드 개발 담당하는 어푸입니다! 지난 글에서는 Redis Pub/Sub…
이 아티클에서는 디지털 트랜스포메이션이 가속화되는 AI 시대에 기술 전략과 비즈니스 목표 사이에서 균형을 유지하며 조직의 IT 아키텍처를 효과적으로 관리하는 아키텍처 리뷰 보드(ARB)의 역할과 변화를 살펴봅니다.
By: Rajiv Shringi, Oleksii Tkachuk, Kartik SathyanarayananIntroductionIn our previous blog post, we introduced Netflix’s TimeSeries Abstraction, a distributed service designed to store and query la...
이 글은 망 중립성(Net Neutrality) 정책이 기업 네트워크와 인터넷 서비스에 미치는 영향에 대해 심도 있게 분석하고 있습니다.
안녕하세요. 저는 LINE+ ABC Studio에서 앱을 개발하고 있는 윤기영입니다. 최근 운영 중이던 앱의 규모가 점점 커지면서 기존 구조로는 앱을 유지 보수하거나 확장하기 어려...
컬리의 새로운 배송 시스템 구축 과정과 프로젝트에서 얻은 교훈을 소개합니다.
# GS SHOP의 AWS 네트워크 변경 배경 GS SHOP은 오랜 기간 운영해온 인천 IDC의 서비스 종료에 맞춰, All Cloud 전환을 목표로 1,000대 이상의 서버를 클라우드로 이전하기 시작했습니다. 이 대규모 전환 작업은 2024년 성공적으로 마침표를 찍게 되었고, 이 과정에서 고도화 및 개선한 경험을 나눠보고자 합니다. # ...
안녕하세요. 일본 최대 규모의 음식 배달 서비스 Demaecan(出前館, 이하 데마에칸) 프로덕트를 담당하는 김영재라고 합니다. 어느덧 프로덕트를 쇄신한 지 2년 반이 되어가고 있...
패션상품검색 시스템 개선 배경 GS SHOP은 국내 최대 규모의 온라인 패션 플랫폼으로, 700만 개가 넘는 방대한 양의 패션 상품 데이터를 보유하고 있습니다. 이러한 대규모 데이터에서 고객이 원하는 상품을 빠르고 정확하게 검색할 수 있도록 하는 것은 온라인 쇼핑 경험을 향상시키는 데 있어 필수적입니다. 기존에는 상품 이미지와 상품명, 카테고리 정보 ...
안녕하세요, 하이퍼커넥트 Media Lab의 Media Server Team에서 Media Server Engineer로 일하고 있는 Simon.Y 입니다. 저희 Media Server Team은 “사람들이 제약 없이 모여서 소통할 수 있도록 안정적인 연결을 제공하고 미디어 품질을 높이기 위해 노력한다”는 미션을 가지고 있습니다. 이 목표 아래, 대규...
이 사례는 프라이스라인의 CTO 마틴 브로드벡이 직접 작성했습니다. 프라이스라인은 12요소 방법론, 모노리포 접근 방식, 컨테이너 기반 마이크로서비스 등을 활용하여 소프트웨어 개발 방식을 혁신하고 있으며, 이러한 변화를 통해 고객 우선 접근 방법을 성공적으로 구현하고 있습니다
이 글에서는 모놀리식 아키텍처의 한계를 극복하고 MSA로 전환하는 과정에서 고려해야 할 핵심 전략을 다루고 있습니다. 경량화의 주요 개념을 설명하고, 이를 통해 기업이 개발 효율성과 확장성을 동시에 달성할 수 있는 방안을 제시합니다.
이 글에서는 IT 인프라, 애플리케이션, 그리고 서비스의 현대화를 통해 기업이 어떻게 더 신속하고 안정적인 서비스를 제공할 수 있는지, 그리고 마이크로서비스, 서버리스 아키텍처, 데브옵스 등 최신 기술들이 기업 환경에 어떤 변화를 가져오는지 설명합니다.
5. 출시 다음에는 ‘개선과 운영’ 홈탭을 출시하는 과정에서 팀 내에 많은 변동이 있었다. 커리어 개발・창업・이민 준비 등 다양한 이유로 팀원들은 회사를 떠났다. 초기 기획을 함께 이끌어주던 디자이너 동료도 떠나게 되었고, PM…
안녕하세요! 올리브영의 POS 개발자, Q평E평입니다. 올리브영은 유연한 서비스의 운영을 위해 IDC의 On-Premise 운영 방식에서, 많은 부분을 Cloud로 전환해오고 있습니다. 올리브영의 POS도 마찬가지인데요! POS…
디지털 트윈이 제조, 항만, 교통, 건물, 에너지, 조선 등의 산업 분야에서 제품 디자인, 성능 시뮬레이션, 자율 주행, 작업장 계획 효율화, 물류창고 관리 등에 활용되어 오고 있습니다. 2000년 초 디지털 트윈이 소개된 이래, 부분적으로 사용되어 오긴 했지만, 요즘 다양한 분야에서 각광받고 있는 것은 새로운 분야에 디지털 트윈을 구체화하고 적용할 ...
디지털 트윈이 제조, 항만, 교통, 건물, 에너지, 조선 등의 산업 분야에서 제품 디자인, 성능 시뮬레이션, 자율 주행, 작업장 계획 효율화, 물류창고 관리 등에 활용되어 오고 있습니다. 2000년 초 디지털 트윈이 소개된 이래, 부분적으로 사용되어 오긴 했지만, 요즘 다양한 분야에서 각광받고 있는 것은 새로운 분야에 디지털 트윈을 구체화하고 적용할 ...
애플리케이션 현대화(Application Modernization)는 기존 애플리케이션을 클라우드 네이티브 환경에서 가장 잘 구동될 수 있게 개선하는 활동을 의미합니다. 단순 레거시 인프라 환경에서 구동하는 애플리케이션을 클라우드에 배포하는 것이 아니라, 클라우드가 주는 이점을 최대한 살리기 위해 애플리케이션을 개선하는 것입니다.
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.
데이터를 통합하여 관리할 것인가? 각 도메인이 데이터를 관리하되 활용 관점의 통합을 추구할 것인가? 데이터 메시를 달성하기 위한 방법은 여러 가지가 있을 수 있으며, 적용할 조직에 맞게 필요한 개념만 일부 채택할 수도 있습니다. 업무의 이해가 중요한 금융 데이터의 경우, 데이터 메시 아키텍처를 통해 데이터 관리에 대한 새로운 시사점을 발견할 수 있습니다.
디지털 트윈은 다양한 애플리케이션을 통해 조직이 보다 효율적이고 혁신적인 비즈니스 모델을 만들고 새로운 수익원을 창출할 수 있는 확장성을 가지고 있어서 다양한 산업군에 적용이 가능합니다. 그중 가장 활용도가 높은 분야는 바로 제조업입니다. 디지털 트윈을 사용하여 제조 현장에서 발생한 데이터를 분석하고 도메인 날리지를 접목함으로써 소재·부품·장비 공정 ...
디지털 트윈의 시뮬레이션은 단순히 데이터를 통해 예측하는 것에 그치지 않습니다. 가장 중요한 전제는 실제 환경을 가상에 동일하게 반영해야 한다는 점입니다. 단순히 전기, 기계 모델을 만드는 것이 아니라 질량으로 인한 중력, 온도, 습도 등 물리적 환경이 그대로 반영되어야 하고 그 이후에 기구의 위치 및 속도 이동 등 행동학적 요소가 적용된 뒤 이 모든...
일상 생활에 필요한 서비스를 하나의 앱에서 원스톱으로 처리하는 모바일 앱을 ‘슈퍼앱’이라고 합니다. 슈퍼앱의 등장으로 전에 없던 시장을 만들고 있고, 스마트폰 앱에 불과했던 애플리케이션이 온갖 서비스가 융합된 플랫폼으로 진화하고 있으며, 기술 경계를 허물고 넓히며 거대 생태계의 중심이 되고 있습니다.