프로젝트 초반에는 DTO가 거의 등장하지 않습니다. 컨트롤러에서 값을 바로 받아서 쓰거나, 간단한 타입 정의 정도로 흐름을 유지합니다. 그러다 코드가 늘어나고, 요청과 응답이 복잡해지기 시작하면 DTO가 하나씩 생깁니다. ValidationPipe를 붙이고, class-validator를 적용하면서 “여기까지 오면 이제 입력은 안전하다”는 느낌이 들기 시작합니다. 문제는 이 시점부터입니다. DTO를 신뢰하기 시작하면서, 자연스럽게 빠져나가는 가정들이 생깁니다. 대부분은 바로 티가 나지 않고, 운영 단계에서 조금씩 드러납니다. DTO가 있다는 이유로 생기는 가정DTO를 도입하면, 코드 곳곳에서 비슷한 전제가 깔립니다.이 값은 이미 검증되었다형태는 항상 DTO 정의와 같다null이나 undefined는 들어..
서비스를 만들든, 업무에서 데이터를 다루든 결국 한 번은 DB 이야기를 듣게 됩니다. “DB에 넣어둬요”, “쿼리 짜주세요”, “NoSQL로 가죠” 같은 말이 자연스럽게 오갑니다. 처음엔 다 비슷하게 들리는데, 막상 프로젝트에 들어가면 선택이 꽤 중요해집니다. 구매 후에 아쉬움이 남는 포인트는 생각보다 늘 비슷합니다.성능이 부족해서라기보다는, 내 사용 방식과 안 맞았던 경우가 더 많습니다. DB도 비슷합니다. 무조건 최신이거나 유행한다고 좋은 게 아니라, 내가 다루는 데이터 성격과 트래픽, 운영 방식에 맞아야 편합니다. 그래서 데이터베이스(DB)란? SQL vs NoSQL 차이를 미리 정리해두면 현업 대화가 훨씬 쉽게 들립니다. 데이터베이스(DB)는 “데이터를 안전하게 보관하고 꺼내 쓰는 곳”입니다..
프로젝트가 어느 정도 커지면, 에러를 문자열이나 단일 Error로 처리하는 방식이 점점 불편해집니다. 로그를 봐도 원인을 바로 알기 어렵고, 호출부에서는 에러 내용을 파싱해서 분기해야 하는 상황이 늘어납니다. 이 시점에서 자연스럽게 에러 타입을 나누기 시작합니다. 도메인 에러, 인프라 에러, 인증 에러처럼 이름을 붙이고, 각각을 타입이나 클래스로 표현합니다. 처음에는 코드가 훨씬 정돈된 것처럼 보입니다. 하지만 일정 시점이 지나면, 에러 타입을 나눈 대가가 서서히 드러나기 시작합니다. 에러를 나누기 전의 상태초기에는 보통 이런 코드로 시작합니다. async function findUser(id: string) { const user = await repo.find(id); if (!user) { ..
“서버는 클라우드에 올렸어요.” “AWS로 옮기면 됩니다.” 같은 말을 들으면, 대충 ‘인터넷 어딘가에 올리는 느낌’은 옵니다. 그런데 막상 클라우드가 정확히 뭔지, 그리고 AWS, Azure, GCP가 무엇이 다른지까지 들어가면 설명이 꼬이기 쉽습니다. 용어가 어려워서가 아니라, 그림이 없어서 헷갈리는 경우가 많습니다.클라우드란 무엇인가를 한 문장으로 말하면 “필요할 때 빌려 쓰는 IT 인프라”에 가깝습니다. 서버, 저장공간, 데이터베이스 같은 걸 내 회사에 직접 사서 설치하는 대신, 큰 사업자가 준비해둔 자원을 인터넷으로 빌려 쓰는 방식입니다. 그래서 규모가 커지거나, 갑자기 트래픽이 늘어도 유연하게 대응할 수 있는 장점이 있습니다. 클라우드는 ‘내 서버를 사는 방식’과 무엇이 다를까요?예전 방식..
타입 가드를 어느 정도 쓰다 보면, 비슷한 코드가 계속 늘어나는 시점이 옵니다. 외부에서 들어오는 값을 하나하나 확인하고, 필드 타입을 검사하고, 조건이 조금만 달라져도 또 다른 가드를 만듭니다. 이쯤 되면 자연스럽게 스키마 검증 도구를 보게 됩니다. zod, io-ts 같은 라이브러리가 대표적입니다. 처음에는 “타입 가드 대신 쓰면 편하겠다” 정도의 기대에서 시작합니다. 막상 붙이고 나면, 편해지는 부분도 있고, 생각보다 불편해지는 부분도 같이 따라옵니다. 이 글에서는 스키마 검증을 도입하면서 코드가 어떻게 바뀌는지, 그리고 어떤 변화가 오래 남는지 위주로 정리해 봅니다. 타입 가드만 쓰던 시기의 코드스키마 검증을 붙이기 전에는 보통 이런 형태로 시작합니다. type LoginBody = { emai..
“서버가 터졌다”, “서버에 올렸다”, “서버에서 처리한다” 같은 말을 자주 듣습니다. 그런데 막상 서버가 정확히 뭐냐고 물으면 설명이 애매해지는 경우가 많습니다. 용어는 익숙한데, 머릿속 그림이 없어서 그렇습니다.서버는 어렵게 말하면 복잡해 보이지만, 역할만 놓고 보면 단순합니다. 누군가가 요청하면, 그 요청을 받아서 필요한 일을 처리하고, 결과를 돌려주는 쪽입니다. 웹 서비스는 이 흐름을 중심으로 돌아갑니다. 서버는 “요청을 받아서 처리하고 돌려주는 곳”입니다서버를 한 문장으로 말하면 이렇습니다. 요청을 받는 쪽입니다. 사용자가 앱이나 웹에서 버튼을 누르거나 검색을 하면, 그 행동이 서버로 전달됩니다. 서버는 “무슨 요청인지” 확인하고, 필요한 데이터를 찾거나 계산한 뒤, 결과를 다시 보내줍니다...