프로그래밍을 하다 보면 테스트의 필요성을 통감하는 순간이 찾아옵니다.하지만 테스트를 꾸준히 작성하는 팀은 많지 않습니다. 만일 팀의 룰로 인해 강제로 테스트를 작성하고 있더라도, 업계의 구루가 말하는 TDD의 이점은 별로 와닿지 않고, 프로그램 코드보다 테스트 코드를 작성하는 데 더 많은 시간을 소모하고 있는 자신을 보며 자괴감을 느끼고 있을지도 모릅니다.'테스트하기 좋은 코드가 좋은 코드다'라는 말을 들어보았을 것입니다. 이 격언에는, 프로그램 코드와 테스트 코드는 서로 상호작용하며, 프로그램 코드가 나쁘면 테스트 코드도 함께 나빠진다는 의미가 숨어 있습니다.많은 사람이 테스트 코드를 부가적인 것으로 생각하고, 개선하려는 노력을 기울이지 않습니다. 하지만 나쁜 테스트 코드를 방치한 채로 테스트 커버리지만 올리는 것은 곰팡이 핀 벽 위에 벽지를 바르는 것과 다름 없는 일입니다.높은 커버리지의 테스트 수트가 있다면, 테스트가 파란 불일 동안에는 안심이 될 것입니다. 하지만 유지 보수를 계속할수록 곤란을 일으키는 테스트 코드의 범위가 늘어 갑니다. 버그로부터 코드를 지켜주던 테스트 코드의 든든한 벽이 어느 순간 넘어야 할 거대한 산으로 돌변하게 되는 것입니다.이 글에서는 테스트를 작성할 때 유념할 점과 좋은 코드의 개념에 대해 다룹니다. 프런트엔드를 기준으로 작성했지만 TypeScript를 사용하는 개발자라면 대체로 도움이 되는 내용일 것입니다. 예시 코드는 TypeScript로 작성되었고, 유닛 테스트의 기본 사용법을 숙지하고 있어야 이해하기 수월합니다.나는 왜 테스트가 어려울까처음 테스트를 작성하는 상황을 떠올려 봅시다. 프로그램 코드도, 테스트도 없는 백지 위에서 켄트 벡의 가르침을 떠올리며 간단한 테스트를 먼저 작성합니다. 그리고 대응하는 프로그램 코드를 작성한 뒤 터미널의 파란 불을 보며 만족스럽게 커피를 한 모금 홀짝이는 시간을 가집니다.테스트 - 코딩 - 리팩터링 삼박자의 왈츠를 즐기고 있으면, 얼마 지나지 않아 난관이 찾아옵니다. 가령 window.localStorage를 사용해 유저 데이터를 저장해야 하는 상황이 온다면, 갑자기 리드미컬한 첼로 선율이 끊기고 발이 꼬이기 시작할 것입니다.하지만 이 정도는 큰 위기가 아닙니다. 테스트 프레임워크에서는 글로벌 객체나 싱글턴 클래스를 모킹(mocking)하기 위한 다양한 메서드를 제공하고 있으므로, Jest 문서를 조금 뒤지면 손쉽게 테스트를 작성할 수 있습니다.새로운 모킹 기술을 습득했다는 자부심으로 가득 찬 우리는 다시 리듬에 몸을 맡기고 도처에 깔린 글로벌 객체를 무자비하게 모킹하며 종횡무진으로 테스트와 프로그램 코드를 작성합니다. 어느새 그 날의 업무가 끝나고 편안한 마음으로 침대에 눕겠죠.다음 날, 그리고 또 다음 날, 우리는 서서히 무언가 잘못되어 감을 느낍니다. 테스트를 한 줄 작성할 때마다 테스트보다 긴 목(mock) 초기화 구문을 작성해야 하고, 테스트 데이터를 하나 변경해야 할 뿐인데 테스트 코드의 경로에서 10계층은 떨어진 폴더에 존재하는 괴상망측한 JSON 파

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

들어가며이번 글에서는 Typescript의 데코레이터에 대해 소개해 보려 합니다. 최근 Typescript를 공부하다가 데코레이터라는 것을 알게 되었는데 잘 이용하면 유용하게도 쓰일 수 있겠다 싶었습니다. Java의 annotaion과도 비슷한 느낌인데 Typescript에서는 데코레이터라고 칭하고 있었습니다. 반복되는 로직을 줄이고자 많이 사용하는 점에서는 Hook을 이용하여 로직을 분리하는 것과 비슷해 보이기도 했지만 어떤 것이 다른지 좀 더 심층적으로 들여다 보려고 합니다. Typescript 공식 문서에 소개된 내용과 사내 강의 플랫폼인 엘리스를 통하여 알아보았고 이 글을 써 가면서 느낀 점은 어떤 것이든 나의 개발 상황에서의 최선의 판단에 따라 다양한 방법을 시도해 볼 수 있겠구나 였습니다.데코레이터 (Decorator)란?데코레이터의 개념데코레이터, 단어 뜻만 보면 어딘가에 장식을 하는 것 처럼 보입니다. 이 뜻과 비슷하게 데코레이터는 함수를 감싸면서 꾸며주는데, 소프트웨어적 관점으로 설명드리면 GoF(Gang of Four) 디자인 패턴에 소개된 구조적 디자인 패턴 중 하나로써, 기존 함수를 바꾸지 않고 관찰, 수정, 오버라이딩 할 수 있는 함수를 뜻합니다. 그리고 클래스 선언, 메소드, 접근자, 프로퍼티 또는 매개변수에 사용할 수 있는 특수한 종류의 선언입니다. @expression형식을 사용하여 호출되는 정보와 함께 런타임에 호출됩니다. 이처럼 공통으로 사용되는 함수를 데코레이터로 만들어 감싸면서 중복을 방지하고 가독성과 효율성을 높입니다. 하지만 주의할 점이 있습니다. 아래는 Typescript Documentation에 데코레이터에 대한 설명을 보면 다음과 같은 문장이 있습니다.데코레이터는 JavaScript에 대한 2단계 제안이며 TypeScript의 실험적 기능으로 이용 가능합니다.아직은 온전하게는 사용하기에는 조금 어려움이 있다는 뜻으로 보입니다. 하지만 Nestjs, TypeORM 등에서 데코레이터를 적극 활용하고 있기 때문에 점차적으로 타입스크립트에 온전히 적용되지 않을까 예상되고 있습니다.데코레이터 팩토리데코레이터가 선언에 적용되는 방식은 사용자가 원하는 데로 수정하고 싶다면 데코레이터 팩토리를 사용할 수 있습니다. 데코레이터 팩토리는 단순히 데코레이터가 런타임에 표출할 표현식을 반환하는 함수입니다. 간단한 예는 아래 코드와 같습니다.function someThing(value: string) { // 데코레이터 팩토리 return function (target) { // 데코레이터 // 'target'과 'value' 변수를 가지고 무언가를 수행합니다. };}데코레이터 평가클래스에서 다양한 선언에 데코레이터를 적용하는 방법을 Typescript 문서에서는 아래와 같이 정의하고 있습니다.메서드, 접근자 또는 프로퍼티 데코레이터가 다음에 오는 매개 변수 데코레이터는 각 인스턴스 멤버에 적용됩니다.메서드, 접근자 또는 프로퍼티 데코레이터가 다음에 오는 매개 변수

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