모바일 웹 서비스에서 다른 앱을 열어야 하는 경우가 있습니다. 예를 들어, 온라인 쇼핑몰에서 카드 결제를 선택하면 선택한 카드의 앱을 실행해서 결제를 완료하죠. 모바일 환경에서 이렇게 나의 웹 또는 앱 서비스에서 다른 앱을 열고 싶다면 딥링크(Deep Link)를 사용해야 되는데요. 이번 포스트에서는 딥링크에 대해서 알아보고 커스텀 URL 스킴을 중심으로 특정 외부 앱을 실행하는 방법을 알아볼게요.

FEConf2023에서 발표한 <리액트 바깥의 프론트엔드 생태계>를 정리한 글입니다. 발표 내용을 2회로 나누어 발행합니다. 1회에서는 리액트의 등장과 리액트가 멋진 부분, 동시에 리액트 등장 후 잃게 된 것, 그리고 프론트엔드 애플리케이션을 구성하기 위한 다양한 선택지를 살펴봤습니다. 이번 글 리액트 바깥의 프론트엔드 2회에서는 리액트 외의 프론트엔드 생태계를 살펴보고 상황에 따라 적절한 도구를 찾는 방법에 대해 다뤄보겠습니다.

FEConf2023에서 발표한 <리액트 바깥의 프론트엔드 생태계>를 정리한 글입니다. 발표 내용을 2회로 나누어 발행합니다. 1회에서는 리액트의 등장과 리액트가 멋진 부분, 동시에 리액트 등장 후 잃게 된 것, 그리고 프론트엔드 애플리케이션을 구성하기 위한 다양한 선택지를 살펴봅니다. 이번 글 리액트 바깥의 프론트엔드 2회에서는 리액트 외의 프론트엔드 생태계를 살펴보고 상황에 따라 적절한 도구를 찾는 방법에 대해 다룹니다.

최근에 VMware의 수석 엔지니어이자 쿠버네티스 및 구글 컴퓨트 엔진의 창시자 중 한 명인 조 베다를 인터뷰할 수 있는 기회가 있었습니다. 조 베다는 마이크로소프트와 구글에서 다양한 경험을 쌓은 베테랑 소프트웨어 엔지니어입니다. 더불어, 베다는 현재 VMware에 인수된 클라우드 네이티브 분야의 선두 주자인 헵티오(Heptio)를 공동 설립한 주요 인물 중 한 명입니다. 인터뷰 내용에 대한 전문은 아래에 첨부했으니 독자 여러분들의 많은 관심 부탁드립니다!

저는 2005년 10월에 입사한 구글에 사직서를 제출했습니다. 지난주가 약 18년을 근무한 구글에서 저의 마지막 근무였죠. 제가 입사한 시점에 갓 상장했던 구글의 임직원들은 다른 대부분의 회사, 그리고 대중에 퍼진 이야기와 달리, 주니어 엔지니어부터 최고 경영진에 이르기까지 옳은 일을 하려고 노력하는 진정으로 선량한 사람들이었습니다. 종종 조롱받기도 했던 "사악해지지 말자"라는 모토는 당시 구글의 실제 원칙이었습니다.

넷마블 QA실에서는 ‘크래시리포트’라는 시스템을 운영하고 있습니다. 크래시리포트는 게임 실행 과정에서 예상치 못한 종료 현상이 발생할 때, 그 상황을 저장한 데이터를 크래시라 합니다. 이러한 크래시리포트 운영용으로 마련한 엣지 서버 클러스터 환경에서는 신규 파드 추가마다 최소 1분 이상 필요했습니다. 게임 사용자가 언제 급증할지 예측할 수 없기에, 스케줄에 맞춘 확장도 적합하지 않았습니다. 또한 서버에 접속하는 클라이언트의 통신 연결 대기 시간은 대략 10~20초로 설정돼 있어서, 신규 파드를 준비하기 위해 소모하는 1분 동안 누락되는 데이터도 늘어날 수밖에 없었습니다.

여기어때에서는 WorkerNode의 AutoScaling 도구로 Karpenter를 사용하고 있습니다. 일반적으로 POD의 수량이 부족한 상황이 되면 HPA에 의해 POD가 Scale out 되며 신규 배포가 수행됩니다. 이때 WorkerNode에 충분한 공간이 있다면 정상적인 배포가 이루어지겠지만 공간이 부족한 상황이라면 POD는 모두 Pending 상태에 빠집니다. 이러한 상황을 해결하기 위해서는 WorkerNode를 Scale out 해주는 과정이 필요한데 이러한 과정을 담당하는 도구가 Karpenter입니다.

안녕하세요? 29CM iOS 엔지니어 박형석입니다. 팀의 성장과 서비스의 변화는 소프트웨어의 변경을 동반하고 때때로 레거시를 양산합니다. 손놓고 있었던 레거시는 어느새 여기저기 뿌리를 내리고 처음에 얕았던 녀석은 시간이 지날수록 깊고 단단해 집니다. 이번 글에서는 크고 난해한 레거시를 다루었던 팀의 사례를 소개하려고 합니다. 29CM iOS 팀에 있었던 레거시와 그 문제, 해소 과정 등을 공유드리며 안정적인 서비스를 만들어 가려는 팀의 노력에 대해 공유드리고자 합니다.

과거 일했던 회사에서 처음 배운 것 중 하나는 어떤 대가를 치르더라도 코드 재작성을 피하는 것이었다. 변경을 거듭할 때마다, 잘 되던 것이 오히려 버그로 회귀할 위험이 있기 때문이다. 기존 코드를 바꿔야 한다면 이것은 더 큰 문제이다. 기존 코드가 특별한 작업 방식과 밀접하게 연결되어 있다면 수정하는 것 자체가 매우 어려울 수 있다. 이 상황에서 코드를 변경하면 다른 여러 곳을 함께 변경해야 할 수도 있다. 변화에 대한 기존 코드의 이러한 저항을 코드 경직성(code rigidity)이라고 한다.

프론트엔드 개발자라면 아마 웹사이트 성능을 최적화하는 것에 관심이 있을 것이다. 웹사이트 로딩 시간을 줄이고, 물 흐르듯 자연스러운 사용자 경험을 만드는 것은 비즈니스에도 큰 영향을 끼친다. 웹을 최적화할 수 있는 방법에는 여러 가지가 있는데, 그중에서 빠질 수 없는 개념이 바로 캐싱이다. 이번 글에서는 프론트엔드 개발자가 알아야 할 캐싱의 종류와 개념을 살펴보려고 한다.