TwentyTwentyOne

Python으로 공부하는 OpenAI 17편 — 운영은 “잘 되는지”가 아니라 “지금 이상한지 빨리 아는지”로 갈립니다여기까지 오면 기능은 꽤 많이 붙었습니다.채팅도 되고, RAG도 되고, 백그라운드 작업도 되고, 재시도와 멱등성도 어느 정도 잡았죠.근데 운영은 여기서 또 결이 달라집니다.실제로 서비스가 흔들릴 때 제일 무서운 건 에러 하나 자체가 아니라, 이상해지고 있는데 아무도 모르고 지나가는 시간이에요.사용자는 “오늘 좀 느리네?” 하고 나가고, 운영자는 “아까부터 토큰이 왜 늘지?” 싶고, 개발자는 “RAG가 흔들린 건가, 모델이 느린 건가, Redis가 밀린 건가”를 뒤늦게 추적합니다.그래서 이번 편은 관측성, 그러니까 observability 이야기입니다.거창하게 들리지만, 저는 그냥 이렇게 ..

Python으로 공부하는 OpenAI 16편 — 운영 배포에서 제일 많이 터지는 건 코드보다 설정이다여기까지 오면 보통 이런 착각이 생깁니다.“이제 기능은 다 붙였으니까, 배포만 하면 되겠네.”근데 이상하게 실제 운영에서 제일 많이 사고 나는 건모델 품질보다도, 프롬프트보다도, 오히려 환경변수, 비밀키, 환경 분리, 로그, 권한 같은 데서 터집니다.이거 좀 허무해요.몇 주 동안 공들여 만든 기능은 잘 도는데,정작 운영 첫날에:dev 키가 prod에 들어가 있고로그에 API 키 비슷한 값이 찍히고staging과 production이 같은 벡터 스토어를 바라보고관리자 키를 워커까지 다 같이 쓰고테스트용 .env가 이미지 안에 들어가 있고장애 나서 로그 보려는데 민감정보까지 같이 남아 있고이런 식으로 망가지는..

Python으로 공부하는 OpenAI 15편 — 테스트 가능한 구조로 바꿌 순간, AI 백엔드가 비로소 개발자 손에 들어옵니다여기까지 오면 기능은 꽤 많이 붙었습니다.채팅도 되고, RAG도 되고, 스트리밍도 되고, 백그라운드 작업도 나눴고, 재시도랑 멱등성까지 봤죠.근데 이쯤에서 거의 꼭 막히는 지점이 하나 있습니다.“이걸 어떻게 테스트하지?”“실제 OpenAI API를 안 부르고도 서비스 로직을 검증할 수 있나?”“RAG 검색 결과가 바뀌어도 앱 로직은 안전한지 어떻게 확인하지?”“Pydantic 검증이 깨졌을 때 테스트로 먼저 잡을 수 있나?”솔직히 AI 기능 붙인 코드가 무서운 이유는 이거예요.눈으로 몇 번 눌러보면 되는 것 같지만, 실제로는 가장 회귀가 자주 나는 영역이기도 하거든요.OpenAI ..

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

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

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

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

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

Python으로 공부하는 OpenAI 8편 — 채팅 히스토리는 전부 저장하고, 모델에는 필요한 만큼만 보내야 합니다7편에서 previous_response_id로 대화를 이어붙이는 데까지 왔죠.여기까지 해보면 처음엔 꽤 신기합니다. “오, 진짜 이전 맥락을 기억하네?” 싶어요.근데 조금만 써보면 바로 다른 문제가 보입니다.대화가 길어질수록 점점 무거워짐비용이 신경 쓰이기 시작함같은 질문인데 응답 속도가 느려지는 느낌이 듦예전 대화까지 다 들고 가는 게 맞나 싶어짐“DB엔 다 저장하고 싶지만, 모델한테도 다 보내야 하나?”라는 고민이 생김여기서부터가 진짜 운영 감각입니다.OpenAI 문서도 Responses API와 함께 conversation state, compaction, counting tokens..

Python으로 공부하는 OpenAI 7편 — FastAPI에서 대화 히스토리를 이어가는 채팅 API 만들기6편에서 스트리밍까지 붙여보면, 이제 딱 이런 생각이 듭니다.“오, 말은 잘 흘러가는데… 새로 질문할 때마다 기억을 다 잃어버리네?”맞아요.채팅 서비스가 “채팅 서비스처럼” 느껴지려면, 단순히 답을 잘 만드는 것만으로는 부족합니다.이전 대화를 이어가는 구조, 그러니까 conversation state가 있어야 해요.OpenAI 공식 문서도 이걸 꽤 분명하게 설명합니다. 텍스트 생성 요청 자체는 기본적으로 독립적이지만, 여러 턴의 대화를 만들려면 상태를 관리해야 하고, Responses API에서는 이를 위해 previous_response_id나 conversation을 사용할 수 있다고 안내합니다..