(메인 버전 릴리즈노트에 내 PR이 있다니 보람차다)Nest v11의 릴리즈노트를 보며, Express v5의 도입과 더불어 Node 20버전 미만은 지원을 중단하는 등의 패치 내용을 죽 읽어보다가, imporove bootstrap perfomance 라고 적힌 Features가 눈에 띄었다. 앱을 실행하는, 가장 핵심적인 코어의 기능이 개선되었다고 하는데, 어떤 변화가 있었길래 전반적인 앱 실행 속도가 향상되었는가에 대한 궁금증에 적당히 파헤쳐보고자 한다. 불투명 키 알고리즘의 추가로 앱 실행속도 향상Nest v11에서는 모듈 간의 고유성을 보장하기 위한 기존의 불투명 키(Opaque key) 생성 방식이 개선되어 동적 모듈과 대규모 애플리케이션에서 직렬화 비용이 대폭 줄어 부트스트래핑 성능이 향상..

2년 넘게 기술 블로그를 운영해오면서 블로그 세팅할 때 처음으로 들어가보고, 2년만에 구글 서치 콘솔에 들어가봤다. 어마어마하게 색인이 생성되지 않았는데, 아마 블로그를 운영하면서 불필요한 카테고리를 삭제하거나, 이동시킨 이유들 때문인 것 같다. 4040, 4043, 차단등의 문제는 제외하더라도, 적절한 표준 태그가 포함된 대체 페이지, 색인이 생성되지 않음 의 사유에 해당하는 페이지들은 색인 생성을 한 번쯤은 신청할 필요가 있어 보인다. 기술 블로그만해도 1500페이지 가량 되는 것 같은데, 이 수많은 페이지들을 일일이 색인 생성 요청을 보낼 수 없는 노릇이다. 그래서 GCP의 Web Search Index API를 이용해 자동으로 요청을 보내어 처리하였다. 페이지 색인 생성이 필요한 페..

서론최근에 사이드 프로젝트에서 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이기 때문에, 이번 일을 계기로 하나하나 직접 사용하며 정리해..

1년차 백엔드 개발자의 회고록 / 2023년을 되돌아보며..두서없이 쓰는 본인의 개발 입문 1년( + 1개월) 기념 (실무 3개월차) 1년을 되돌아보며 작성하는 장황한 글이다. 왜 개발자를 선택했는가? 나는 작년 11월. 국비지원 백엔드 개발자 양성과정 교육을mag1c.tistory.com 개발자로서의 2024년올해는 계속해서 도전하는 한 해였지만 반대로 빠르게 번아웃을 맞았던 한 해이기도 하다. 성과Java, Spring으로 시작했던 개발이 작년 말 입사 후 Node쪽으로 완전히 변하게 되었고, 입사하자마자 업무를 바로 수행해야 하는 상황에 적응하기 위해 부단히 노력했다. 노력 덕분인지 입사 2주만에 두 개의 스프린트를 모두 완료하였고, 곧바로 수습 종료 후 정규직으로 전환되었다. 올해는 자율적으..

서론트랜잭션의 격리 수준 포스팅에서 다루지 않았던 이상현상 중 Lost Update와 Write Skew같은 일관되지 않은 쓰기 결과를 반환하는 데이터 부정합 문제가 있다. PostegraSQL에서는 격리 수준을 REPEATABLE READ로 설정하는 것만으로도 쓰기 결과를 올바르게 보장할 수 있다. 하지만 MySQL의 MVCC(Multi Version Concurrency Control)은 일관된 읽기(Consistence Read)를 지원하지만 위와 같은 데이터 업데이트의 부정합 문제를 REPEATABLE READ의 격리 수준 만으로는 해결할 수 없다.  아래 그림은 MySQL에서 REPEATABLE READ 격리 수준을 사용했을 때 Lost Update가 발생하는 상황이다. 고객 A가 10,000원..