TwentyTwentyOne

발급한 JWT를 이제 어디에 쓰지? 보호된 API에서 토큰 검증하고 현재 로그인 사용자를 꺼내는 방법 — FastAPI · Spring Boot · Node.js지난 글에서 세션과 JWT의 차이를 정리했죠.그런데 사실 인증은 “로그인 성공”에서 끝나지 않습니다.진짜 중요한 건 그다음이에요.보호된 API에서 토큰을 어떻게 읽는지이 토큰이 진짜인지 어떻게 검증하는지현재 로그인 사용자를 어디서 꺼내는지인증 안 된 요청은 어디서 막는지이 단계가 들어가야 비로소“로그인 기능이 있는 서비스”가 아니라“인증이 실제로 적용된 API 서버” 가 됩니다.이번 글에서는 그걸 FastAPI, Spring Boot, Node.js 기준으로 이어서 정리해보겠습니다.FastAPI는 OAuth2PasswordBearer를 통해 Be..

세션이 좋을까, JWT가 좋을까? 로그인 이후 인증 상태를 유지하는 두 가지 방식 제대로 이해하기 — FastAPI · Spring Boot · Node.js비밀번호 해시까지 붙이고 나면, 이제 진짜로 다음 질문이 나옵니다.“로그인 성공한 사용자를 이제 어떻게 기억하지?”여기서 거의 무조건 나오는 단어가 두 개예요.세션(Session)JWT근데 이 주제는 늘 좀 이상하게 흘러갑니다.누군가는 “요즘은 무조건 JWT죠”라고 하고,또 누군가는 “아니, 세션이 더 안전해요”라고 하죠.솔직히 말하면… 둘 다 반쯤 맞고, 반쯤은 맥락이 빠진 말입니다.저도 예전엔 JWT가 더 최신이고 멋진 방식처럼 느껴졌어요.토큰 하나 들고 다니면 되니까 뭔가 더 현대적이고, 마이크로서비스랑도 잘 맞고, 모바일 앱에도 잘 어울려 보..

비밀번호를 그대로 저장하면 왜 위험할까? 해시, 검증, 인증의 첫 단추 제대로 끼우기 — FastAPI · Spring Boot · Node.js여기까지 시리즈를 따라오면서 회원가입 구조, 서비스 계층, repository, 트랜잭션까지 왔잖아요.이쯤 되면 진짜 자연스럽게 붙는 질문이 하나 있어요.“비밀번호는 이제 어떻게 저장하지?”이 질문이 은근히 무섭습니다.왜냐하면 여기서 대충 넘어가면, 앞에서 그렇게 열심히 구조를 잘 나눠놔도 한 번에 보안 구멍이 생기거든요.저도 아주 초반엔 이런 생각을 한 적이 있었어요.그냥 DB에 저장하면 안 되나?SHA-256 한 번 돌리면 되는 거 아닌가?어차피 내 서비스 작은데, 나중에 바꾸면 되지 않을까?근데 이게 진짜 위험한 생각이더라고요.비밀번호는 “그냥 저장하면 안..

여러 작업 중 하나라도 실패하면 어떻게 될까? 백엔드에서 트랜잭션을 이해해야 하는 이유 — FastAPI · Spring Boot · Node.jsrepository까지 나누고 나면, 이제 슬슬 백엔드가 “진짜 실무 냄새”를 내기 시작합니다.그리고 거의 반드시 마주치는 주제가 하나 있어요.바로 트랜잭션(Transaction) 입니다.이 말을 처음 들으면 좀 거창하게 느껴져요.저도 처음엔 그랬습니다.뭔가 은행 시스템, 결제 시스템, 엄청 무거운 엔터프라이즈 얘기 같았거든요.근데 막상 서비스 개발을 하다 보면 생각보다 너무 빨리 등장합니다.예를 들면 이런 상황이요.회원가입하면서 사용자 저장 + 프로필 저장주문 생성하면서 주문 저장 + 재고 차감결제 성공 처리하면서 결제 상태 변경 + 포인트 적립게시글 삭제하..

서비스 다음은 Repository다 — 데이터 접근을 어디서 끊어야 코드가 안 무너질까? FastAPI · Spring Boot · Node.js서비스 계층까지 나누고 나면, 이제 거의 반드시 나오는 질문이 있어요.“그럼 DB 조회는 어디서 하지?”“서비스에서 바로 SQL 써도 되나?”“repository를 꼭 따로 만들어야 하나?”저는 이 질문이 되게 중요하다고 생각해요.왜냐하면 여기서 한 번 방향을 잘못 잡으면, 나중에 서비스 코드가 슬금슬금 DB 구현 세부사항까지 다 알아버리거든요. 처음엔 별거 아닌데, 쿼리가 늘고 조건이 복잡해지고 저장 방식이 바뀌기 시작하면 그때부터 코드가 탁해집니다.이번 글에서는 Repository 계층 이야기를 해보겠습니다.정확히는,repository가 왜 필요한지서비스와 ..

컨트롤러에 로직을 다 넣으면 왜 망가질까? 서비스 계층(Service Layer)과 비즈니스 로직 분리 제대로 이해하기 — FastAPI · Spring Boot · Node.js백엔드 처음 만들 때는요, 진짜 자연스럽게 이렇게 됩니다.요청 받음값 꺼냄검증함계산함저장함응답 만듦문제는… 이걸 전부 컨트롤러에서 해버리기 시작하면 코드가 아주 빠르게 무거워진다는 거예요.처음엔 별거 아닌 것 같거든요.API 하나쯤은 컨트롤러에서 다 처리해도 되지 않나 싶죠.근데 기능이 3개, 10개, 20개로 늘어나는 순간부터 슬슬 보이기 시작합니다.같은 비즈니스 로직이 여러 API에 중복되고테스트하려면 HTTP 요청부터 만들어야 하고트랜잭션 경계가 애매해지고컨트롤러가 점점 “뭐든지 다 하는 클래스”가 됩니다저는 이 시점이 백..

DTO와 Schema를 왜 따로 둬야 할까? 입력 검증과 요청 모델 설계 제대로 시작하기 — FastAPI · Spring Boot · Node.js백엔드 프로젝트를 조금만 만들다 보면 꼭 한 번은 이런 유혹이 옵니다.“굳이 DTO까지 나눠야 하나?”“그냥 들어온 JSON 바로 받아서 쓰면 안 되나?”“엔티티나 모델 하나로 요청/응답 다 처리하면 편한데…”저도 처음엔 그렇게 생각했어요.근데 이 방식은 초반엔 빨라 보여도, 기능이 붙을수록 아주 높은 확률로 문제를 만듭니다.요청값이 이상한데도 서비스까지 들어가고DB 컬럼 구조가 그대로 외부 API에 노출되고응답에서 숨겨야 할 필드가 같이 나가고프론트 요구사항이 바뀔 때 엔티티까지 흔들리고나중엔 “이 클래스는 요청용인가, 응답용인가, DB용인가”가 헷갈립니다..

운영에서 진짜 차이 나는 백엔드 기본기 — 로깅과 요청 추적(Request ID / Trace ID) 구현하기 (FastAPI · Spring Boot · Node.js)백엔드 만들다 보면 어느 순간부터 이런 일이 생겨요.에러는 났는데, 로그가 너무 많아서 어느 요청에서 터진 건지 도통 못 찾겠는 거죠. 같은 시각에 사용자 요청이 수십 개, 수백 개 들어오면 로그 줄만 봐서는 진짜 막막합니다. 그래서 대부분의 프레임워크는 요청 전후에 공통 처리를 넣을 수 있는 미들웨어나 필터를 제공하고, Spring Boot 쪽은 MDC, FastAPI는 middleware, Express는 middleware 패턴으로 이 문제를 풀게 됩니다. (FastAPI)저는 이 시점을 꽤 중요하게 봐요.전역 예외 처리까지는 “A..

백엔드가 진짜 백엔드처럼 보이기 시작하는 순간 — 공통 응답 포맷과 전역 예외 처리 구현하기 (FastAPI · Spring Boot · Node.js)백엔드 프로젝트를 처음 만들 때는 보통 이런 데서 기분이 좋아집니다.“오, API 호출하면 값 잘 오네?”근데 조금만 기능이 늘어나면 바로 이상한 일이 생겨요.어떤 API는 { "name": "..." } 로 주고어떤 API는 { "data": { ... } } 로 주고어떤 API는 에러가 나면 그냥 문자열만 내려주고어떤 API는 500인데 왜 실패했는지 감도 안 오고프론트는 매번 응답 형식이 달라서 분기문이 늘어나고나중엔 “이건 어느 형식이 맞는 거지?”가 됩니다저는 이 단계가 백엔드 초반에 진짜 중요하다고 생각해요.구조를 잘 나눠도, 응답 형식과 에러..

백엔드 프로젝트의 두 번째 뼈대, 환경변수와 설정 분리부터 제대로 하자 — FastAPI · Spring Boot · Node.js지난 글에서는 프로젝트 구조를 먼저 잡았습니다.솔직히 그 글은 약간 “집 짓기 전에 땅 고르는 이야기”에 가까웠어요.이번 글부터는 조금 더 현실적인 얘기로 들어가 보겠습니다.백엔드 프로젝트를 처음 만들면 대부분 이런 식으로 시작하죠.DB_URL = "postgresql://user:password@localhost:5432/mydb"SECRET_KEY = "my-secret-key"DEBUG = True처음엔 편해요.정말 편합니다.근데 이 방식은 프로젝트가 조금만 커져도 바로 발목을 잡아요.로컬에서 쓰던 DB 주소가 운영에 그대로 들어가고비밀번호가 깃에 올라가고테스트 환경과 ..