안녕하세요. 저는 당근에서 디자인 시스템을 만들고 운영하고 있는 하태영입니다. 이번 글에서는 제가 1년 반 동안 디자인 시스템을 만들며 시도했던 다양한 접근 방법과 그 과정에서 함정에 빠진 경험, 그리고 이 경험을 통해 배운 것 들을 공유하고자 합니다. 디자인 시스템을 만들다 보면 ‘디자인 시스템’이라는 단어가 굉장히 넓은 스펙트럼을 가지고 있고 이로 인해 팀원간 소통의 오류나 팀의 방향성이 흐트러지는 경험을 하게 됩니다.

파이썬으로 만들어진 프로그램을 배포할 때는 항상 파이썬 가상 환경을 사용했습니다. pipx가 사용되는 것은 여러 웹 사이트나 문서에서 많이 봐왔지만, 처음엔 ‘늘 사용하던 파이썬 가상 환경만 사용하면 됐지.. 뭘 더 배워야 하나’ 했습니다. 하지만 pipx를 사용하고 나니 제가 콘솔 스크립트가 포함된 파이썬 프로그램을 배포하는 과정이 엄청 지저분했구나 하는 생각이 들었습니다. 여러분도 제가 느낀 이런 천지가 개벽하는 느낌을 받을 수 있으면 좋겠습니다. 그래서 여러분에게도 pipx를 소개하고자 합니다.

알라미는 유저들의 다양한 니즈를 충족할 수 있도록 알람 소리를 여러 방법으로 커스텀할 수 있는 기능들을 제공하고 있습니다. 저는 최근 안드로이드 알라미 앱에 인플루언서 벨소리 기능을 추가했고, 이 과정에서 클린 아키텍처를 이해하고 적용할 수 있었습니다. 이때의 배움을 예시를 통해 공유해 보고자 합니다.

‘React Native, Metro를 넘어서’ 1회에서는 번들러가 무엇인지와 번들러의 역할로 Resolution, Load, Optimization에 관해 소개했습니다. 1부 마지막에서 파일 크기를 줄이기 위한 Optimizaton을 간단히 이야기하고, 파일 크기를 줄이는 테크닉에는 크게 Minification과 Tree Shaking이 있다고 말씀드렸죠. 이 글인 2부에서는 Metro와 ESBuild의 차이를 조금 더 명확하게 알기 위해서, 이 각각의 테크닉이 구체적으로 어떤 역할을 하는지 살펴보겠습니다. 그리고 토스에서 Metro를 ESBuild로 바꾼 여정도 소개합니다.

토스에서 프론트엔드 개발자로 일하고 있는 박서진이라고 합니다. 이 글에서는 저희가 매일 사용하고 있는 Metro, webpack 아니면 ESBuild와 같이 그런 번들러가 무엇인지에 대해서 자세하게 알아보겠습니다. 번들러가 무엇인지를 알면 Metro도 ESBuild도 생긴 것만 다른 똑같은 번들러라는 걸 알게 되고, 두 번들러를 (쉽지는 않습니다만) 갈아끼울 수 있다는 것도 알게 될 것입니다.

애플리케이션 현대화에 따라 컨테이너 기반의 마이크로서비스 아키텍처가 많은 부분에서 적용되고 있습니다. 이러한 기반 아키텍처는 컨테이너를 기반으로 한 배포 파이프라인이 필요한 경우가 많습니다. 그리고 이러한 배포 파이프라인으로 전달되는 최종 결과물은 컨테이너 이미지이며, 이 결과물을 어떻게 만들어 내는가에 따라서 효율적인 파이프라인을 가지고 있다와 아니다를 말할 수 있습니다. 하지만 우리가 여기서 중요하게 봐야 하는 또 다른 지점이 있는데, 바로 파이프라인등을 통해서 컨테이너가 빌드될 때 컨테이너의 용량을 줄이는 것입니다.

메타 인지를 높이는 데 가장 효과적인 방법은 피드백을 이용하는 것이다. 예를 들면 개발자들은 프로그래밍 언어를 배울 때부터 피드백에 익숙해져 있다. 코드를 타이핑하는 순간 컴파일러가 바로 구체적인 피드백을 준다. 무엇이 잘못되었는지를 바로 인지하고 고친다. 한 줄을 작성해도 그 안에 컴파일러 간의 몇 번의 피드백이 담겨 있다. 피드백을 있는 그대로 수용하는 것만으로 성장으로 연결되지 않는다. 피드백을 어떻게 받아들이는지가 중요하기 때문이다. 이 글은 피드백 받는 당사자 입장에 피드백을 받아들이고 이를 통해 성장하는 법을 다룬다.

이번에 소개할 개발자는 프론트엔드 분야에서 다양한 활동을 이어가며, 개발자로서 본인을 알리는 일에 진심인 인물입니다. 그가 운영하는 디스코드 참가자만 1,800여 명, 카카오톡 오픈채팅방에만 1500+900명이 참여하고 있고, 자신의 이름을 내건 컨퍼런스까지 엽니다. 요즘IT에서도 ‘테오의 프론트엔드’라는 필명으로 활동하며 누적 조회수 53만 회를 달성한 개발자 ‘테오’가 바로 오늘 소개할 주인공인데요.

현재 나는 회사 내부에서 쓰는 여러 운영툴의 프론트엔드 파트를 담당하고 있다. 다만 회사마다 운영툴의 개수와 규모는 모두 달라서, 내 경험이 일반적이라고 설명할 순 없다. 그러나 이 직무를 준비하면서 정보가 많지 않아 어려웠던 기억이 있고, 작은 도움이라도 주고 싶다는 생각이 들었다. 이번 글에서는 필자가 어떤 ‘운영툴’을 만들고 있는지, 이러한 툴을 만들며 느낀 장단점과 특징을 공유해 보고자 한다.

앞서 K8sGPT를 통한 쿠버네티스 AIOps의 가능성 1부에서는 K8sGPT에서 지난 1년간 보여준 변화를 소개했습니다. 이번 글에서는 공개된 AI 제공자를 사용하는 게 아닌 ‘나만의 AI 제공자를 사용하는 법’을 소개하고 K8sGPT의 미래 전망에 대해 나름대로의 생각을 공유하도록 하겠습니다.