TwentyTwentyOne

RAG 품질이 안 나오는 이유 — chunk 크기, overlap, k값, 프롬프트 문제를 어떻게 봐야 하나첫 번째 RAG를 만들고 나면 보통 되게 비슷한 순간이 와요.처음 질문 하나는 잘 맞습니다.그래서 속으로 살짝 신나요.“오… 됐다.”근데 두 번째, 세 번째 질문부터 이상해집니다.어떤 질문에는 진짜 그럴듯하게 답하는데,어떤 질문에는 엉뚱한 chunk를 물고 오고,가끔은 문서를 가져와 놓고도 답을 이상하게 하고,또 어떤 경우엔 문서 안에 답이 있는데도 못 찾습니다.이쯤 되면 많은 분이 바로 이렇게 생각해요.“모델이 별론가?”“임베딩 모델을 더 좋은 걸로 바꿔야 하나?”“벡터DB를 바꿔야 하나?”물론 그런 경우도 있습니다.그런데 실제로는 그 전에 먼저 봐야 할 게 있어요.RAG 품질 문제의 상당수는 c..

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

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

첫 번째 RAG 만들기 — Retriever로 찾고, 문서를 넣고, 근거 기반으로 답하게 하기여기까지 왔으면 이제 드디어 많은 사람이 말하는 그 단어, RAG를 직접 만질 차례입니다.사실 저는 처음에 RAG를 너무 거창하게 생각했어요.뭔가 엄청 복잡한 아키텍처 같고, 벡터DB도 붙어야 하고, 검색 최적화도 해야 하고, 평가도 해야 하고…맞아요. 나중엔 그렇게 커질 수 있습니다.근데 첫 번째 RAG는 그렇게 시작할 필요가 없어요.진짜 출발은 생각보다 소박합니다.질문이 들어오면 관련 문서를 찾고, 그 문서를 프롬프트에 넣고, 그 문서를 근거로 답하게 만든다.LangChain 문서도 retriever를 비정형 쿼리를 받아 관련 문서를 반환하는 인터페이스로 설명하고, RAG를 특정 소스 정보에 대해 질문에 답하..

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

👨‍💻 2026 AI 개발자 필수 기술 랭킹 TOP 15“코딩 잘하는 개발자 → AI를 ‘일하게 만드는 개발자’로”이제 현실 얘기하자.2026년 개발자는 이렇게 바뀌고 있다.코드를 직접 다 짜는 사람 ❌AI에게 코드 ‘시스템’을 맡기는 사람 ⭕실제로 개발자의 75% 이상이 업무 절반 이상을 AI로 수행하고 있다는 데이터도 있다. (Pragmatic Engineer)🧠 2026 AI 개발자 기술 랭킹🥇 1위 — AI Agent 설계 능력이게 핵심이다.이제 개발자는 코드를 짜는 사람이 아니라AI가 일을 하게 만드는 사람이다.해야 할 것Agent 구조 설계Tool 연결Workflow 구성AI를 쓰는 게 아니라 AI를 조직화한다📌 기업 앱의 40%가 AI Agent 포함 예정 (Medium)🥈 2위 ..

LangChain, 왜 다들 이야기할까? 주니어 개발자가 처음 LangChain을 공부해야 하는 진짜 이유처음 생성형 AI 서비스를 만들겠다고 마음먹었을 때, 저도 되게 단순하게 생각했어요.“모델 API 하나 연결하고, 프롬프트 잘 쓰면 끝 아닌가?”근데 조금만 만들다 보면 바로 벽을 만납니다.사용자 질문이 길어지면 문맥 관리가 필요하고,외부 문서를 읽혀야 하면 검색 구조가 필요하고,실시간 데이터를 써야 하면 툴 연결이 필요하고,응답을 JSON으로 받아서 화면에 뿌리려면 출력 형식도 제어해야 하죠.그때부터 느끼게 됩니다.아… 이건 그냥 LLM 한 번 호출하는 코드로는 점점 감당이 안 되는구나.LangChain은 바로 그 지점에서 등장하는 프레임워크입니다. 공식 문서에서는 LangChain을 LLM 기반 ..

LLM 실전 활용 7: Agent 실패 패턴 총정리 — 왜 AI는 데모에선 잘 되는데, 운영에선 망가질까솔직히 말하면,Agent 프로젝트의 절반 이상은 운영 단계에서 무너진다.데모에서는똑똑하고계획도 세우고말도 그럴듯한데막상 서비스에 올리면 이런 소리가 나온다.“비용이 감당이 안 됩니다.”“가끔 말도 안 되는 행동을 해요.”“왜 저 도구를 썼는지 아무도 몰라요.”이건 모델 성능 문제가 아니다.👉 구조 설계 문제다.이번 글은Agent가 실무에서 실패하는 전형적인 패턴을“하지 말아야 할 것들” 중심으로 정리한다.이걸 알고 시작하면, 최소한 같은 구덩이엔 안 빠진다.1. 실패 패턴 #1 — 무한 루프 (가장 흔하고 가장 치명적)증상Agent가 계속 생각한다같은 행동을 반복한다종료되지 않는다토큰·비용 폭발원인멈..

LLM 실전 활용 6: 메모리 설계 — Agent는 무엇을 기억해야 하고, 무엇을 반드시 잊어야 하는가Agent를 붙이고 나서,처음엔 다들 이렇게 말한다.“이제 대화도 이어지고, 꽤 사람 같다.”그런데 서비스에 올리는 순간이상한 일이 벌어진다.예전에 한 말을 계속 끌고 온다이미 끝난 얘기를 다시 꺼낸다엉뚱한 맥락을 연결한다대화가 길어질수록 점점 멍청해진다이때의 문제는👉 모델도, 프롬프트도 아니다.거의 항상 원인은 하나다.“메모리 설계”이번 글은Agent가 왜 기억 때문에 망하는지,그리고 어떤 기억만 남겨야 하는지를실무 관점에서 정리한 글이다.1. 가장 위험한 착각: “다 기억하면 더 똑똑해진다”이건 거의 본능에 가깝다.“이전 대화를 다 넣어주면맥락을 잘 이해하겠지?”❌ 아니다.대부분의 경우 정반대다.이..

LLM 실전 활용 5: AI Agent의 탄생 — “질문에 답하는 AI”에서 “목표를 달성하는 시스템”으로Tool Calling까지 붙이고 나면,이런 순간이 온다.“이제 함수도 부르고, 조회도 하는데…왜 일을 ‘끝까지’ 못 하지?”중간에 멈추고다음 행동을 스스로 결정 못 하고매번 사람 지시를 기다린다여기서 한 단계 더 나아간 개념이 바로 AI Agent다.👉 Agent는 ‘대답하는 존재’가 아니라‘목표를 향해 행동을 이어가는 구조’다.이번 글에서는Agent가 정확히 무엇인지Tool Calling과 뭐가 다른지Agent가 왜 “루프 구조”를 가지는지실무에서 쓸 수 있는 최소 Agent 구조를 현실적인 시선으로 정리한다.1. Agent를 한 문장으로 정의하면“목표를 입력받고,스스로 다음 행동을 계획하고,도..