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

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

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

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

우리는 하루 대부분의 시간을 일하는 데 사용합니다. 하지만 현실은 어떤가요? 과연 나는 들이는 시간만큼 결과물을 내고 있을까요? 혹시 본인이 다음 내용 중 해당하는 게 있는지 확인해보세요. 출근은 일찍 했는데 뭐부터 해야 할지 모르겠다, 오늘 온종일 일했는데 뭘 했는지 모르겠다, 일하는데 사소한 것을 빼먹어서 수정사항이 생긴다, 일정을 못 지켜서 야근하는 날이 자주 있다. 고개를 한 번이라도 끄덕이셨나요?  그렇다면 오늘 제가 공유할 내용이 큰 도움이 될 것입니다.

이번 글에서는 지난 3년간 개인 기여자(Individual Contributor, IC)가 아닌 한 명의 리더로서 좋은 리더란 무엇인지, 또 좋은 리더가 되려면 어떤 역량이 필요한지에 스스로 고민해 봤던 내용에 관해 적어보려고 한다. 아무리 기여자로서 일을 잘했던 사람이라고 해도 이 경험이 좋은 리더로서의 역량으로 이어지리란 법은 없기 때문에 자연스럽게 이런 고민을 시작하게 되었다. 리더에게는 단지 커뮤니케이션뿐 아니라, 나 스스로에 대한 이해와 인간 본연의 심리와 본능, 조직의 특성에 대한 이해와 같은 인문학적인 소양까지도 필요하다고 느꼈다.

새로운 것을 배우는 것이 직업의 정수인 소프트웨어 개발자에게는 효과적으로 학습하는 방법을 아는 것이 매우 중요합니다. 새로운 언어, 프레임워크, 도구를 빠르게 익힐 수 있다면 다른 개발자보다 획기적으로 생산성을 높일 수 있죠. 이 글에서는 제가 학습하며 배운 것을 공유하고, 새로운 기술을 빠르게 습득하는 방법에 관해 설명하겠습니다.

‘데브렐’이라는 직무를 아시나요? 디벨로퍼 릴레이션십(Developer Relations, 개발자 관계)을 줄여 ‘데브렐’이라 하고, DR이라고 하기도 합니다. 데브렐은 개발자, 기술 커뮤니티를 대상으로 관계를 만드는 일을 합니다. 비즈니스에서 기술과 개발자의 역할이 중요해지다 보니 생겨난 직무라고 할 수 있습니다. 나날이 존재감이 커지고 있는 데브렐 커뮤니티 ‘데브챗’을 만나 직무와 커뮤니티, 컨퍼런스에 대해 이야기 들어봤습니다.

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

B2B SaaS 애플리케이션 개발을 시작하면서 KOS팀은 인터페이스 정의 언어(이하 IDL, Interface Definition Language)를 도입하게 되었습니다. IDL은 소프트웨어의 인터페이스를 정의하는 명세 언어를 말하고, 특정한 언어에 국한되지 않는 방법으로 인터페이스를 정의하여 애플리케이션들의 언어가 다르더라도 동일한 인터페이스로 통신할 수 있도록 합니다.