복잡한 분기와 타입 추론의 고통개발을 하다 보면, 조건에 따라 서로 다른 로직을 실행해야 할 때가 많아요. 이러한 상황에서 우리는 흔히 문을 사용하죠. 하지만 복잡한 조건들이 겹쳐질수록 분기문은 점점 난잡해지고, 이를 유지 보수하는 것이 어려워집니다. 특히, 타입스크립트와 같은 강력한 타입 시스템에서는 타입이 추가될 때마다 모든 분기 조건을 다 신경 써야 하는데, 이를 놓치면 버그가 발생할 가능성이 커져요.저 또한 과거 프로젝트에서 타입이 추가되었음에도, 기존 분기문에서 해당 타입을 고려하지 않아 발생한 버그를 경험한 적이 있어요. 이러한 문제는 분기문의 복잡성을 줄이고, 타입 추론을 더욱 쉽게 할 수 있는 도구가 필요하다는 고민을 불러일으켰습니다.이러한 문제를 해결하기 위해 도입된 도구 중 하나가 바로 입니다. 이 라이브러리는 TC39에서 제안한 패턴 매칭을 기반으로 하고 있으며, 복잡한 조건부 분기를 간결하게 작성할 수 있게 도와줘요.과연 ts-pattern은 타입스크립트에서 if문을 대체할 수 있을까?• None 최근 벤치마크 , 삼항 연산자에 비해 성능이 현저히 떨어집니다.• None 문은 초당 약 10억 회 이상의 연산을 처리할 수 있는 반면, 초당 130만 회 정도의 연산을 수행하며 99% 더 느립니다.은 다양한 데이터 구조와 복잡한 타입 추론을 지원하기 위해, 입력 타입의 가능한 모든 경우를 사전에 계산하는데요. 내부 코드를 살펴보면 파일에서는 클래스 기반으로 패턴 매칭을 구현하고, this를 사용해 상태를 함수 체이닝을 통해 공유합니다. 이러한 방식은 안전한 타입 매칭을 제공하지만, 자바스크립트 엔진이 최적화된 기본 와 비교하면 성능이 떨어질 수밖에 없어요.이 성능 이슈는 복잡한 분기 로직에서 을 무조건 사용해야 하는지에 대해 고민하게 만들었습니다.우리는 실제로 ts-pattern을 어떻게 사용하고 있었나?실제로 제가 을 사용한 코드를 돌아봤을 때, 대부분 복잡하지 않은 코드에서 사용되고 있었어요. 복잡한 분기 로직이나 타입 체크가 필요한 상황에서는 이 큰 도움이 되었지만, 그렇지 않은 경우에는 오히려 오버엔지니어링처럼 느껴졌고요.특히 문법을 사용해 조건에서 처리되지 않은 모든 경우를 타입스크립트 컴파일러가 감지하고 타입 체크를 할 수 있다는 점에서는 유용했지만, 간단한 조건 분기를 처리할 때는 기존 방식이 더 효율적일 수 있다는 생각이 들었어요.또한 다시 한번 생각해봐야 할 질문은, “정말 을 사용할 만큼 복잡한 분기가 자주 발생하는가?”입니다. 복잡한 분기가 필요할 때도 있지만, 그런 상황에서는 “오히려 코드를 더 간결하게 만들 수 있는 방법을 고민하는 것이 본질적인 해결책이 아닐까?” 라는 생각도 해보았어요.복잡한 분기문을 간결하고 안전하게 처리하는 방법1. 복잡한 분기문을 단순하고 안전하게 처리하기복잡한 분기는 피할 수 있다면 나 를 사용해 더 단순하게 표현하는 것이 좋아요. 특히 early return 패턴을 활용하면 조건을 명확하게 처리할 수 있어요.을 사용해 더 선언적으로 분기 처리를 다룰 수 있습니다.여기서

ESLint와 Prettier는 JavaScript나 TypeScript의 코드 품질을 높이고 일관된 형식을 유지하는 데 자주 사용하는 도구입니다. ESLint를 사용하면 잠재적인 문제를 빠르게 확인할 수 있고, Prettier를 사용하면 코드 서식에 신경쓰지 않고 코드 작성에만 집중할 수 있어 편리합니다.하지만, 매번 프로젝트를 생성할 때마다 ESLint/Prettier 등을 설정하는 작업은 꽤 번거롭습니다. 컨피그 파일을 만들고, 플러그인을 설치하고, 추천 규칙을 적용하는 작업이 반복되며, 아예 다른 저장소 설정을 그대로 가져와서 쓰기도 합니다.같이 오래되고 유명한 라이브러리로 규칙을 통일하는 방법도 있지만, 사용 해보니 필요 이상으로 엄격한 규칙이 작업 흐름을 방해하고 생산성을 저하 시킨다고 느꼈습니다. ESLint가 고치라고 해서 고치긴 했는데, 이걸 왜 고쳐야 하지?라는 생각도 들었습니다. 또한, 저장소마다 다른 컨피그 설정 때문에 혼란을 겪기도 했습니다.코어웹프론트개발팀은 이런 문제점을 근본적으로 해결하기 위해, 우리에게 필요한 규칙들만 모아놓은 공유 컨피그 패키지를 도입하게 되었습니다. 그 결과, 각 저장소에서 일관된 개발 경험을 제공하게 되었고, 이는 개발자들의 생산성 향상에 큰 도움을 주었습니다.공유 컨피그를 만들면서 팀원끼리 자연스럽게 규칙을 논의하기도 했습니다. 논의 과정에서 의견이 갈리는 규칙들에 대한 조율이 필요했는데, 이를 통해 코드 리뷰에서의 불필요한 논쟁을 줄이는 효과를 얻기도 했습니다.패키지를 구현하는 것은 생각보다 어렵지 않았지만, 더 어려웠던 건 바로 팀원 간의 합의였습니다. 개발자마다 선호하는 규칙과 생각이 다르다 보니 의견을 조율하는 과정에 꽤 시간이 걸렸습니다. 긴 논의가 필요한 경우에는 Slack 투표나, 프론트엔드 개발자들이 모여있는 채널에서 의견을 모아 결정하기도 했습니다.이 글에서는 eslint-config-airbnb 패키지의 대안으로 @rushstack/eslint-config를 선택하게 된 과정을 공유하려고 합니다. 또한, 공유 ESLint 컨피그 패키지를 만드는 과정과 컨피그에 대한 설명, 그리고 추천할 만한 규칙 몇 가지에 대해서도 다루어보겠습니다.Airbnb의 eslint-config-airbnb 패키지는 많은 프론트엔드 개발자가 사용하는 대표적인 코딩 스타일 가이드입니다. 다양한 JavaScript와 React 관련 규칙들을 포함하고 있는 Airbnb 규칙은 2015년 5월에 오픈소스로 처음 공개되어 현재까지도 많은 프로젝트에서 사용되고 있습니다.Airbnb 규칙을 사용하면 ESLint 설정 시간을 줄여준다는 장점이 있지만, Airbnb 조직이 정한 코딩 스타일 가이드를 따라야하는 단점이 있습니다. 코드의 세세한 부분까지 규칙이 적용되어있기 때문에, 개발 과정에서 ESLint 경고를 제거하기 위한 사투가 펼쳐지곤 합니다. Airbnb 규칙을 사용하면서 불편함을 느꼈던 사례는 글 마지막의 부록에 적어두었습니다.Airbnb 규칙이 생산성을 떨어뜨린다고 느꼈던 저는, 팀에 우리만의 E

지난해 Public Cloud 전환 프로젝트를 수행하면서 AWS CDK(Cloud Development Kit)로 인프라를 구축했던 경험을 공유하려고 합니다.IaC(Infrastructure as Code) 개발도구의 선택 과정부터 개발 및 배포파이프라인 구축까지 시행착오를 겪고 고민했던 내용을 전달해 보겠습니다.AWS 리소스를 코드로 생성하는 여러 가지 방법이 있습니다. 몇 가지 주요한 방법은 다음과 같습니다.그 중 기술 요구사항과 운영 유지보수를 고려하여 AWS CDK와 Terraform을 검토하기로 합니다.먼저 고객 담당자에게 워크로드의 Multi Cloud 활용 계획을 확인합니다.Terraform은 다양한 CSP(Cloud Service Provider)를 지원하기 때문에 개발도구 선정에 중요한 요소입니다.CSP별로 지원하는 API는 다르지만 HCL(HashiCorp Configuration Language) 문법을 동일하게 활용해 개발 할 수 있습니다.그리고 개발한 코드를 운영할 주체가 누구인지 확인합니다.AWS CDK는 다양한 언어를 지원하기 때문에 운영자가 친숙한 언어를 선택할 수 있는 장점이 있습니다.Terraform의 HCL 문법은 직관적이고 가독성이 좋지만 언어라고 하기에는 부족하고 Script에 가깝다는 생각이 듭니다.두 가지 개발도구 모두 OSS(Open Source Software)로 구축 할 수 있고Terraform은 엔터프라이즈 버전의 경우 사용자관리, 보안, 거버넌스 등 다양한 기능을 제공하지만 라이선스 비용이 적지는 않습니다.결국 고객사 내부 검토를 거쳐 AWS CDK를 개발도구로 선정합니다.AWS 개발자 문서와 온라인 학습프로그램 Skill Builder로 기본기를 다지고 CDK Workshop 으로 실습을 합니다.다음은 반드시 알아야 할 CDK 개념에 대해 정리했습니다.App은 애플리케이션을 구성하는 최상위 단계의 추상화입니다.애플리케이션은 하나 이상의 Stack으로 구성되며, 각 스택은 다양한 Construct를 포함할 수 있습니다.CDK App을 개발하고 배포하기 위해서는 선택한 언어에 상관없이 Node.js 기반 CLI 도구인 AWS CDK Toolkit을 사용해야 합니다.다음은 CLI를 실행할때 배포되는 과정을 보여줍니다.• None 애플리케이션을 만들고 실행합니다.• None 정의한 애플리케이션 모델을 조사하고 합성(Synthesize)을 합니다.• None AWS CDK에 의해 생성된 AWS CloudFormation 템플릿을 작성하고 배포합니다.결국 CDK는 오랜기간 검증된 CloudFormation을 레버리지하여 개발자에게 친숙한 언어로 추상화된 라이브러리를 제공하는 툴이라고 할 수 있습니다.CDK가 중간에서 컴파일러 역할을 한다고 볼 수도 있구요. 따라서 CloudFormation의 기본적인 개념과 구조에 대한 최소한의 학습은 필요합니다.CDK를 운영할 조직 또는 담당자에게 친숙한 언어가 가장 좋은 선택이라고 생각됩니다.그런데 AWS에서 권고하는 언어는 TypeScript인데요. 저같은

안녕하세요. 인프랩 데브옵스 엔지니어 선비입니다.오늘은 AWS CDK에서 Terraform으로 글에서 다룬 AWS CDK/Terraform, 그리고 인프콘 2022에서 발표했던 Terragrunt를 지나서 Pulumi에 정착하게 된 인프랩의 IaC 구축기를 풀어보고자 합니다.이번 Part 1 글에서는 Terragrunt를 두고 또 한 번 새로운 도구로 넘어오게 된 배경과 과정, 그리고 이제는 정착할 수 있을 것이라고 생각하는 이유에 대해 한 번 이야기해보려고 합니다.먼저 이 글을 통해서 IaC를 처음 접하시는 분들을 위해 IaC에 대한 간략한 소개와, 인프랩 데브옵스 팀이 어째서 IaC를 정말 중요하게 생각하고 있는지에 대해 말씀드리겠습니다.IaC는 Infrastructure as Code(코드형 인프라)의 약자로, 코드를 통해서 인프라를 관리하는 것을 의미합니다. IaC는 인프라 관리를 자동화하는 다양한 방법 중에서도 소프트웨어 개발 방법론 등 소프트웨어 개발을 위한 수많은 기술과 도구들을 인프라 관리에 적용할 수 있도록 하므로 특히 강력한 방법이라고 할 수 있습니다.제가 인프랩에 합류한 2021년 9월 당시까지만 하더라도 인프랩의 인프라 구성은 메인 서비스 컨테이너와 Redis 캐시, PostgreSQL 데이터베이스, 람다 함수 몇 가지 정도로 그다지 복잡하지 않았습니다. 또한 변화가 일어나는 경우도 많지 않았기 때문에 이 때의 인프라 구성 작업은 대부분 웹 콘솔에서 수동으로 진행되었고 몇 개의 리소스만 AWS CDK를 이용하여 구성하는 상태였습니다.하지만 2021년 말부터 랠릿이 개발되면서 인프라 구성 업무가 급속도로 늘기 시작했습니다. 그 때는 제가 인프랩에 데브옵스로 합류하면서 팀 내 비효율을 기술로 해결하겠다는 당찬 포부와 함께 2년 내에 만들고자 했던 두 가지에 집중하던 시기였는데요,• 전문 지식이 없이도 팀원들이 고수준의 자동화를 직접 구축할 수 있도록 도와주는 추상화가 잘 된 신뢰할 수 있는 파이프라인 시스템• 팀원들이 방향 설정과 동기 부여에 사용할 만한 모든 데이터를 일관적인 방식으로 수집하고 시각화하는 모니터링 시스템몇 가지 조사를 한 후 단기간 내에는 이러한 목표를 달성하기 어렵다는 결론을 내림과 동시에, 이들을 달성하기 위해서는 첫째로 반드시 개인이 아닌 팀으로서 효율적으로 협업할 수 있어야 하고, 둘째로 내일은 오늘보다 더 효율적으로 일할 수 있게 만드는 환경이 준비되어야 한다는 생각을 하게 되었습니다. 즉, 시행착오를 통해 알아낸 정보를 일시적으로 활용하는 것을 넘어 업무 흐름에 적용함으로써 팀원들의 노력을 차곡차곡 쌓아나갈 수 있는 업무 방식이 기반이 되어야 한다고 생각하였습니다.그리하여 시급한 업무를 진행하는 시간을 빼고는 대부분의 시간과 노력을 업무 방식 개선에 투자하게 되었고, IaC 도입은 가장 핵심적인 업무 방식 개선 방안이었습니다.이 때 생각했던 원하는 수준의 IaC는 다음과 같았습니다.• 특별한 경우를 제외하고는 모든 인프라 구성을 IaC를 이용해서 할 수 있다.• 팀에서 한 번 구축해본 구성의