TwentyTwentyOne

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

Python으로 공부하는 OpenAI 13편 — 오래 걸리는 AI 작업은 API 서버에서 바로 처리하지 말고, 백그라운드 작업으로 분리해야 합니다여기까지 시리즈를 따라오면, 슬슬 이런 순간이 옵니다.“기능은 다 되는데, 어떤 요청은 너무 오래 걸린다.”“문서 업로드하고 벡터 스토어 색인까지 한 번에 하려니까 API가 답답하다.”“긴 요약, 대량 생성, 대량 임베딩 작업을 요청-응답 한 번에 묶어두니 운영이 불안하다.”이때 필요한 감각이 바로 백그라운드 작업 분리입니다.솔직히 이 단계부터는 코드만 잘 짜는 문제가 아니라,AI 기능을 운영 가능한 백엔드 구조로 바꾸는 문제에 가까워집니다.OpenAI 공식 문서도 “Run and scale” 아래에 Background mode, Streaming, Webhoo..

Python으로 공부하는 OpenAI 12편 — 비용은 기능보다 늦게 터지지만, 한 번 터지면 훨씬 아픕니다OpenAI 기능은 처음 붙일 때 되게 재밌습니다.채팅 붙고, RAG 붙고, 스트리밍 붙고, 출처까지 붙으면 꽤 근사해 보여요.근데 서비스가 진짜 서비스가 되는 순간,거의 반드시 부딪히는 문제가 하나 있습니다.“이거 비용이 어디서 이렇게 많이 나가지?”이 질문은 늘 늦게 옵니다.처음엔 API 몇 번 호출하니까 체감이 잘 안 돼요.근데 사용자 수가 조금만 늘어도 바로 보입니다.히스토리를 너무 많이 보내고 있나?RAG chunk를 너무 많이 넣고 있나?출력이 너무 길게 나오나?캐시될 수 있는 프롬프트를 매번 바꾸고 있나?로그는 많은데, 정작 어디서 새는지 모르나?이번 글은 바로 그 얘기입니다.기능 얘기..

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

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

Python으로 공부하는 OpenAI 11편 — RAG 답변에 출처까지 붙여야, 이제 진짜 “믿고 쓰는 서비스”가 됩니다RAG를 붙이고 나면, 처음엔 그 자체로 꽤 감동적입니다.“오, 내 문서를 찾아서 답하네?” 여기까지 오면 일단 반은 왔어요.근데 실무에서는 여기서 꼭 한 번 더 걸립니다.사용자 입장에서 제일 중요한 질문이 남아 있거든요.“그래서 이 답이 어디 문서를 근거로 나온 건데?”이 질문에 답을 못 하면, 서비스는 금방 애매해집니다.답이 맞아 보여도 찜찜하고, 틀렸을 때 어디서 어긋났는지 추적도 어렵고, 운영하는 사람도 디버깅이 힘들어요.그래서 이번 편은 출처 이야기입니다.그냥 RAG가 아니라, citation-friendly RAG, 그러니까 근거를 같이 보여주는 RAG 응답 구조를 만들어보겠..

Python으로 공부하는 OpenAI 10편 — RAG가 붙었는데 답이 별로라면, chunking과 top-k부터 다시 봐야 합니다9편에서 RAG를 붙이면, 처음엔 되게 뿌듯합니다.“이제 우리 문서를 찾아서 답하네?” 싶거든요.근데 그 다음에 거의 꼭 오는 순간이 있어요.검색은 되는 것 같은데 답이 좀 엉성하다.문서가 분명 있는데 못 찾는다.찾긴 찾는데 엉뚱한 조각을 들고 온다.관련 문서를 너무 많이 넣으니까 오히려 답이 흐려진다.이쯤 되면 많은 분이 바로 모델 탓을 합니다.근데 실제로는 모델보다 먼저 봐야 할 게 있어요.문서를 어떻게 쪼갰는지(chunking), 몇 개를 가져오는지(top-k), 그리고 검색 결과를 어떻게 정리해서 넣는지이 세 가지에서 품질이 갈리는 경우가 정말 많습니다.OpenAI 문..

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

Python으로 공부하는 OpenAI 9편 — FastAPI 채팅에 RAG를 붙이면, 이제 내 문서를 근거로 답하기 시작합니다7편, 8편까지 오면 채팅이 꽤 그럴듯해집니다.대화도 이어지고, 히스토리도 관리하고, 오래된 맥락은 압축해서 들고 가고… 여기까지도 사실 꽤 잘 만든 구조예요.근데 실무에서는 거의 반드시 이런 순간이 옵니다.“모델이 말은 잘하는데, 우리 문서 기준으로 답하게 하려면?”“사내 위키, FAQ, 정책 문서, 블로그 글을 바탕으로 답하게 하고 싶은데?”“대화 기억이랑 문서 검색은 뭐가 다르지?”바로 여기서 RAG가 들어옵니다.RAG는 거창하게 말하면 Retrieval-Augmented Generation이고, 더 쉽게 말하면 “모델이 답을 만들기 전에, 관련 문서를 먼저 찾아서 그걸 근거..

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