TypeScript 4.9 Iteration Plan이 공개되면서 이제 9월 20일부터 ‘타입스크립터(TypeScript) 4.9 Beta 버전’을 사용할 수 있게 됩니다. 이번 릴리즈에서 개인적으로 가장 기대하는 기능은 바로 ‘satisfies’ 키워드입니다. 이 글에서는 이 키워드가 무엇이고, 왜 필요하고, 어떤 문제를 해결하는지에 대해서 서술하고자 합니다.

AWS ECS는 꽤 편리하고 생각보다 여러 곳이 사용하고 있는 운영 환경입니다. 그런데도 클라우드 환경에서는 매우 중요한 Auto Scaling과 관련하여 아쉬움이 많았던 서비스인데요. 트래픽이 갑자기 spike 치는 일이 종종 발생하는 Airbridge 워크로드에서는 고통이 꽤 컸었습니다. Auto Scaling이 잘 안되면 비용이 많이 낭비되기 때문입니다. 이번 글에서는 AWS ECS Managed Cluster Auto Scaling과 비용 관련 문제점, 그리고 Airbridge Backend 팀에서 어떻게 개선했는지 소개합니다.

리뷰가 좋은 것은 다들 알지만 실제로는 문화로 잘 자리 잡기 어렵습니다. 많은 회사에서 ‘바쁘다’거나 ‘그 시간에 코드 한 줄을 더 작성하는 낫다’라는 이유로 하지 못하기도 합니다. AB180에서도 지금의 리뷰 문화로 발전하기까지 매우 긴 시간이 걸렸습니다. 4년 이상 전부터 ‘코드 리뷰(Code Review)’를 했었지만, 지금의 문화와는 약간의 차이가 있었습니다. 오늘은 AB180 팀에서 만족하는 리뷰 문화가 정착까지의 여정을 함께 살펴보겠습니다.

SaaS를 만들어 고객에게 제공하는 과정에서 한 개로 시작한 컴포넌트가 필요에 따라 여러 개로 나누어져 관리하는 경우를 흔히 볼 수 있습니다. 이렇게 나누어진 컴포넌트 사이에는 연관관계가 생기고, 때로는 하나의 컴포넌트가 다른 컴포넌트에 의존성이 생기기도 합니다. AB180의 Airbridge API 개발팀에서도 다양한 컴포넌트를 다루고 있고, 이 과정에서 겪었던 몇 가지 문제점을 Monorepo를 통해 해결한 경험을 소개하고자 합니다.

스타트업에 있다 보면 “우리 회사는 일하는 체계가 없다“라는 이야기를 심심치 않게 듣습니다. 일하는 방식이 정해져 있지 않고, 그때그때 구두로 내려온 일을 쳐내기 급급하다는 불만을 같이 토로하기도 합니다. 일을 잘하기 위해 글을 찾아보면 ‘개발을 잘하고 커뮤니케이션을 잘하자’라는 좋은 글이 많지만, 팀이 어떻게 움직이는지에 대한 글은 흔치 않습니다. 오늘은 하나의 로드맵을 향해서 모인 히어로들이 일하는 방법에 대한 이야기를 풀어볼까 합니다.

처음 AB180 백엔드 팀에 들어왔을 때 AWS 상의 거의 모든 권한을 가지고 개발할 수 있었습니다. 풍부한 권한으로 불편함 없이 지내던 중 외부 회사와 파트너십을 맺기 위해 보안 감사를 받아야 했습니다. 보안 감사를 진행하면서 몇몇 개선사항이 있었고 그중 한 가지 수정해야 할 사항이 ‘개발자에게 너무 많은 권한이 부여되고 있다.’였습니다. 그래서 팀 내에서도 AWS의 권장 사항처럼 최소 권한 정책으로 권한을 지급하기로 했습니다.

로컬에서 빌드를 돌리다 보면 느린 속도에 답답함을 느끼곤 합니다. 많은 이유가 있지만 하나만 꼽는다면 기능이 늘며 코드 베이스가 큰 폭으로 증가했기 때문입니다. 당장 서비스를 시작한 2016년보다 2.7배 정도 많은 기능을 제공하고 있습니다. 기능이 늘어나도 개발 경험이 불편해지는 것은 정말로 막고 싶었습니다.