처음 크롬을 접했을 때의 희열을 잊을 수 없다. 브라우저와 계정이 직접 연동된다는 것은 아주 큰 편리함을 가져다주었다. 몇 년간 크롬의 모든 것이 좋기만 했다. 하지만 새로운 구글 계정을 만들면서 이야기는 달라졌다. 구글 계정을 여러 개로 나눈 이유는 일과 취미를 분리하기 위함이었다. 그리고 두 번째 계정으로 크롬을 사용하게 되면서 전에는 보이지 않던 단점들이 눈에 들어오기 시작했다. 그때 아크 브라우저를 만나게 되었고, 그동안의 답답함이 해소되는 경험을 했다. 이번 글에서는 개발자의 관점에서 크롬을 정말 사랑하면서도 느꼈던 약간의 아쉬움, 그리고 아크가 그것을 어떻게 개선했는지 리뷰를 통해 살펴보고자 한다.

2024년의 상반기가 끝나고 어느덧 평가 시즌이 다가왔다. 소심한 성격의 소유자인 나는 평가 시즌이 다가올 때마다 불안감에 휩싸이곤 한다. 내가 불안한 이유는 ‘최악의 평가를 받으면 어떡하지?’라는 생각과 나의 단점을 지적받는 것이 두렵기 때문이다. 어느 유명한 경영학자는 사람들에게 자신이 가진 단점을 고치려고 하기보다, 장점을 극대화하는 데 집중하라고 조언했다. 그러나 단점을 극복하려 노력하지 않고, 그대로 둔다면 결국 언젠가 내 발목을 잡을지도 모른다. 그렇다면 어떻게 도움이 되는 방향으로 피드백을 수용할 수 있을까? 이번 글에서는 내가 단점을 극복하고 성장할 수 있었던 방법과 생각을 공유해 보고자 한다.

최근 우리 팀에서 누구나 간단히 쿠버네티스 리소스를 생성, 조회, 삭제할 수 있는 운영 툴을 개발하자는 의견이 나왔다. 복잡한 클라우드 인프라를 쉽고 직관적으로 관리할 수 있게 만들어 생산성을 높이자는 취지였다. 본 개발에 앞서 다양한 UI와 UX를 시도하기 위한 프로토타입 개발이 시작되었고, 나도 여기 참여하게 되었다. 쿠버네티스 API를 활용해 툴을 개발하는 과정은 매력적이면서도 도전적인 작업이었다. 이 글에서는 툴의 개발 과정을 간략히 소개하고, 그 과정에서 가진 의문과 고민을 공유하고자 한다.

프론트엔드 개발자 입장에서는 개발할 때 로컬 환경에 백엔드 서버를 일일이 빌드하는 일은 다소 번거롭게 느껴진다. 그래서 최근 내가 속한 팀에서는 백엔드 서버를 브랜치 단위로 배포하고, 클라이언트를 개발하는 서버에서 직접 배포된 백엔드 서버를 향해 API를 요청하기로 하였다. 하지만 서버가 허용한다고 하더라도 브라우저 자체적으로 차단하는 리소스가 있다. 브라우저는 HTTP와 HTTPS 간 통신에서 쿠키 전송을 허용하지 않고 차단해 버린다. 자, 그럼 어떻게 해야 할까? 내가 시도한 방법을 공유한다.

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

최근 우리 팀에서는 UI 라이브러리를 직접 만들기로 결정했다. 우리 라이브러리를 쓰는 사용자는 어떤 배치를 주로 선호할지, 또한 일반적으로 권장하는 배치 방법이 있는지에 대한 고민으로 이어졌다. 하지만 열심히 이곳저곳을 찾아봐도 명확하게 답을 주는 곳은 없었다. 그래서 이 기회에 W3C 문서와 예시를 참고하여, 나만의 설계 원칙을 직접 세워보기로 했다. 이번 글에서는 스스로 정립해 본 푸터 컴포넌트의 배치와 설계 원칙에 관해 이야기해 보고자 한다.

최근 회사 프로젝트에서 API 제너레이터를 사용해 보기로 했고, JSON 파일을 타입스크립트 파일로 변환해 주는 효율적인 라이브러리가 있는지 찾아보게 되었다. 결과적으로 내가 선택한 라이브러리는 ‘swagger-typescript-api’다. API 자동 생성을 처음 해보는 개발자, 특히 나처럼 타입스크립트를 다루는 개발자에게 도움이 되는 라이브러리로 이번 글에서 살펴보고자 한다.

최근 Nuxt 프레임워크를 사용하는 프로젝트를 진행했는데, 그동안 Vue 개발에 익숙해진 나머지 브라우저 리소스가 당연히 존재할 거라 가정하는 실수를 범했다. 그리고 이 일을 계기로, SSR에서 DOM 생성 직전에 이루어지는 Hydration의 중요성을 깨닫게 되었다. 이번 글에서는 ‘SSR에서 브라우저 API를 사용할 때 Hydration을 고려해야 한다’는 기본적이면서도 중요한 사실을 이야기해 보고자 한다.

내가 처음 개발자가 되기로 마음먹은 것은 웹 화면에 내 생각을 그대로 옮겨놓을 수 있다는 점 때문이었다. 우연히 유튜브에서 한 영상을 보게 되었는데, 바로 Canvas API를 활용해 만든 인터랙티브 웹 포트폴리오 영상이었다. 영상을 보니 개발자로서 무엇이든 만들어 낼 수 있을 것 같다는 생각이 들었다. 나는 초심을 되찾을 겸 Canvas API를 공부해 보기로 했다. 이론만 공부하면 재미가 없으니 간단한 작업물을 만들어 보고 싶었고, 가을을 맞이해 바람에 흩날리는 비와 낙엽을 표현해 보았다.

컴포넌트란 재사용 가능하고 캡슐화되어있는 클래스 또는 그 클래스를 기반으로 생성되는 각각의 인스턴스를 말한다. 컴포넌트 개념이 처음 나타난 시기는 1990년대까지 거슬러올라간다. 재사용성에 초점을 맞춘 컴포넌트 기반 아키텍처(CBA)라는 설계 방법이 소프트웨어 엔지니어들 사이에서 활발히 논의되기 시작했다.