서론최근에 사이드 프로젝트에서 S3 버킷에 파일을 업로드해야 하는 일이 생겼고, 자연스럽게 통합 테스트를 작성해야 할 상황이 됐다. 하지만 실제 AWS S3 환경에서 테스트를 작성하는 데는 몇 가지 현실적인 문제들이 예상됐다. 1. 비용 문제S3는 사용량 기반으로 요금이 부과되기 때문에, 테스트가 자주 실행되는 환경에서는 비용이 계속 쌓일 가능성이 있다. 특히, 개발하면서 테스트를 반복적으로 실행하다 보면 생각 이상으로 비용이 발생할 수밖에 없다. 현재 사이드프로젝트의 테스트코드 실행 주기가 pre-commit에만 달려있어도, 하루에 십 수번은 넘게 실행되고 있다.2. 보안 문제 테스트 환경에서 IAM의 Access Key와 Secret Key를 사용하는 건 보안상 굉장히 위험할 수 있다. 키가 노출되면..

멱등성(Idempotency)멱등성이라는 용어부터 살펴보자. 멱등성은 수학에서 유래된 개념으로, 같은 작업을 여러 번 반복해도 결과가 달라지지 않는 성질을 뜻한다. 이 개념은 HTTP Method에서도 중요한 역할을 한다.예를 들어, 같은 GET 요청을 서버에 1번 보내든 10번 보내든, 서버에서 반환되는 데이터는 항상 동일하다. 하지만 POST 요청은 어떨까? 여러 번 실행하면 새로운 데이터가 계속 추가될 수 있다. 바로 이런 차이가 멱등성과 관련이 있다.  HTTP Method의 멱등성위에서 언급한 것처럼, HTTP Method에도 멱등성을 적용할 수 있다. RFC 7231 문서에는 여러 번 동일한 요청을 보냈을 때 서버에 미치는 의도된 영향이 동일한 경우 멱등성을 가진다고 정의되어있다. 아래 표는,..

서론최근 신입 개발자분이 입사하셨다. TypeORM을 사용해서 특정 기능을 구현하던 도중, 계속해서 하위 테이블에서 상위 테이블의 FK가 NULL로 들어가는 문제가 있었다. 구현하신 로직을 따라가면서 문제점을 발견할 수 있었는데, 기존에 하위 모델에서 가지고 있는 상위 모델 객체의 정보를 저장 직전에 ORM의 create 인터페이스로 새로 생성하여 저장했기 때문이다. 현재 내가 개발중인 도메인의 테이블들은 대부분 비정규화가 심한 테이블들이여서 ORM에서 관계를 매핑해주지 않고 ORM의 인터페이스 혹은 raw query로 JOIN을 수행하고 있다. 이렇다보니 한 번에 무엇이 문제인지 찾을 수 없었다. 사용하고 있는 특정 기술들 중 핵심적인 ORM이기 때문에, 이번 일을 계기로 하나하나 직접 사용하며 정리해..

처음으로 오픈소스에 기여해보았다 (feat. 오픈소스 멘토링)저는 처음 오픈소스에 기여하겠다!!! 라는 생각을 실천하는데 1년이나 걸렸습니다.부끄럽지만 너무 다가가기 어렵고 힘들었습니다. 하여 누구나 오픈소스에 쉽게 접했으면 하는 마음에 다소 가mag1c.tistory.com 오픈소스 멘토링 때 선정했던 두 가지 이슈 중에, 선택하지 않았던 nest의 file-validation-pipe의 이슈를 다시 살펴보았다.누군가가 PR을 하겠다고 코멘트가 달려있어서 선택하지 않았던 이슈였지만 누가 먼저 PR을 보내느냐가 중요하다던 말이 떠올랐다. 간단한 이슈였기 때문에 바로 PR을 보냈고, 곧바로 머지 되었다. (멤버분의 코멘트로 보아 11버전에서 업데이트 될 것 같다)    이슈 정의기존 NestJS의 파일 V..

저는 처음 오픈소스에 기여하겠다!!! 라는 생각을 실천하는데 1년이나 걸렸습니다.부끄럽지만 너무 다가가기 어렵고 힘들었습니다. 하여 누구나 오픈소스에 쉽게 접했으면 하는 마음에 다소 가벼운 스타일로 포스팅을 진행하려 합니다.  오픈소스에 기여하게 된 계기우리는 오픈소스를 쉽게 접하고 사용한다. 특히 node 진영에서는 npm install 딸깍 한 번이면 오픈소스를 쉽게 받아 사용할수 있다. 어제도 메세지큐를 사용하기 위해 bullmq @nestjs/bullmq를, UI Board를 위해 @bull-board/api와@bull-board/express를 갖다 썻으니 벌써 4개의 오픈소스를 사용한 셈이다.     동물은 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다는데, 개발자로 살면서 나도 죽기전에 ..

배경최근 몇 차례의 코드 리뷰 경험들로 공유하는 문화가 얼마나 큰 이펙트가 있는지 경험할 수 있었다. 하지만 현재 조직에서는 홀로 서버 개발을 진행하다보니 내가 작성하고 있는 코드가 과연 좋은 방향으로 나아가고 있는 것인지 혹은 구조적이나 가독성 등 좋은 코드를, 올바른 설계를 하고 있는 것일까? 라는 의구심이 생겼다. 또한, 여러 번 기술 면접을 다녀왔는데 많은 조직에서 내부적으로 소나 큐브를 정적 코드 분석 도구로 활용하고 있었다.소나큐브를 통해 받을 수 있는 코드 리뷰를 통해 코드 품질 향상과 더불어, 코드 일관성 등의 컨벤션도 정립하고자 도입하게 되었다.   설치 Installing from Docker | SonarQube DocsExplains how to install the SonarQub..

[NestJS] 의존성 제어 1 - 레이어간 의존성 낮추기(Layered Architecture)최근 인프랩 면접에서 얻게 된 코드 리뷰를 통해 현업에서 사용하고 있는 코드들에 대해 되짚어 보고 있다. 값진 경험을 통해 메타인지를 할 수 있게 되었고, 오답이라고 생각하는 부분에 대한 mag1c.tistory.com 1편의 연장선으로, 실제 기술 면접의 코드 리뷰에서 mysql2에 의존적인 코드를 어떻게 변화에 유연하게 만들것이냐는 질문을 받았다. 레이어간 역할을 명확하게 하는데 그치지 않고 데이터베이스에 엑세스하는 레이어를 두 단계로 나눠서, 레포지토리 레이어는 단순 쿼리 실행 레이어로 인프라 레이어를 데이터베이스와 연결하는 레이어로 두어 인프라 레이어만 교체하게끔 할 수 있다고 생각했다. ORM, DB..

전환 이유레퍼런스들을 찾아보면, 대부분이 PM2를 통해 간편하게 인스턴스를 띄워 사용하다가, 컨테이너 단위로 전환하고 노드 환경에서는 추가로 pm2-runtime을 도커 컨테이너 내부에서 적용하는 경우를 많이 봤던 것 같다. 나는 반대로, 현재 운영중인 서비스를 계속해서 개발하면서 겪은 문제들을 개선하기 위해 배포 파이프라인을 Git Actions - Docker에서 Git Actions - PM2로 전환하였다. 1. 긴 배포 시간 (길면 3~5분, 평균 1분 후반대)2. 간헐적인 서비스 장애 탐지의 위치 이동 서버와 백엔드 코드를 혼자 관리하다 보니 빈번하게 코드를 업데이트해야 한다. 테스트 같은 안전 장치의 통과를 위해 소요되는 시간은 언제나 수긍하지만, Docker 프로세싱의 긴 소요 시간은 점차 ..