지식 기록장

ChatGPT가 나온 지 3년 반이 지났다. 그 사이에 AI는 대화 상대에서 코드를 짜고 도구를 쓰고 스스로 개선하는 에이전트로 변했다. 변화가 너무 빨라서 지금 쓰이는 기술이 어디서 출발했고, 왜 이런 형태가 되었는지 잘 보이지 않는다.LLM은 결국 "다음에 올 것을 예측하는 시스템"이다. 이 단순한 원리에서 출발해서, 왜 AI에게 컨텍스트가 중요한지, 어떻게 에이전트가 되었는지, 26년 현재 어디까지 왔는지를 정리한다. 1. 다음에 올 것을 예측한다는 아이디어1948년, 클로드 섀넌은 논문 "A Mathematical Theory of Communication"에서 마르코프 체인을 언어에 적용했다. "앞에 나온 글자를 바탕으로 다음 글자의 확률을 결정하는 방식"을 수학적으로 정리한 것이다. 현대 LL..

GPT에게 "주문 취소 시 환불은 어떻게 처리되나요?"라고 물으면 일반적인 상황에서 상식적인 답변이 나온다. 하지만 우리 회사의 API가 실제로 어떻게 동작하는지는 모른다. 학습 데이터가 없기 때문이다.RAG는 이 문제를 해결하는 구조이다. AI에게 "이 문서를 읽고 답변해라"라고 관련 문서를 함께 넘기는 것이다. 이 글에서는 사내 문서 검색 시스템에 간단한 RAG 챗봇을 구현하면서 이해한 내용을 정리한다. 1. LLM은 왜 모르는 것이 있을까LLM은 학습 데이터의 통계적 패턴을 압축한 모델이다. "모른다"에는 두 가지 의미가 있다.- 학습 데이터 컷오프 : 학습 이후에 발생한 사건이나 업데이트된 정보에 접근할 수 없다. 모델의 지식은 학습 시점에 고정된다.- 비공개 정보 : 사내 문서, 독점 시스템, ..

AI와 함께 코딩을 하다 보면 이런 상황이 반복된다.나 : 문서 검색 기능이 필요해AI : BM25 알고리즘으로 구현하겠습니다.나 : 그게뭔데?AI가 제안한 기술을 내가 모른다. 이때는 어떻게 해야할까? 전부 이해하고 넘어가야 하는가, 아니면 모르는 채로 진행해도 되는가?사내 문서 검색 시스템을 만들면서 이 질문을 반복적으로 마주쳤다. BM25, MCP, SSE, 청킹 전략... 처음 듣는 것들이 계속 나왔다. 그 과정에서 나름의 기준을 정리하고 사고한 과정을 서술하겠다. 1. 실제로 일어난 일검색 기능을 만들어야 했다. 약 500개의 MDX 문서에서 원하는 정보를 찾는 기능이다. AI에게 검색 기능 구현을 요청했더니 BM25라는 알고리즘으로 구현된 코드가 나왔다. 나는 BM25가 뭔지 몰랐다. 하지만 ..

검색창에 "주문 취소"를 입력하면 1,500개의 문서 조각 중에서 가장 관련 있는 것을 골라야한다. 어떤 기준이 있을까?사내 문서 검색 시스템을 만들면서 BM25라는 스코어링 알고리즘을 사용했다. 직접 구현하지는 않고 AI에게 위임했지만, 왜 이 공식이 동작하는지는 이해하고 있어야 한다. 검색 품질을 판단하려면 점수가 어떻게 매겨지는지 알아야 하기 때문이다.이 글에서는 BM25가 무엇이고, 왜 이렇게 생겼는지를 직관부터 수식까지 단계적으로 설명한다. 1. 가장 단순한 방법"주문 취소"를 검색한다고 하면 가장 먼저 떠오르는 방법은 단어를 세는 것이다."주문"과 "취소"가 많이 나오는 문서가 관련 있는 문서 아닌가?맞다. 이게 TF(Term Frequency)이다. 특정 단어가 문서에 몇 번 나오는지 세는 ..

2편까지 검색 엔진과 RAG 챗봇을 만들었다. 사람이 검색하고, 사람이 질문하는 구조이다. 이번에는 사람이 아니라 AI가 직접 문서를 조회하는 구조, MCP 서버를 다루어보겠다. 1. MCPMCP는 Model Context Protocol의 약자이다. AI가 외부 도구를 호출할 수 있게 해주는 표준 프로토콜이다.기존 워크플로우를 보면[기존] 개발자가 문서를 검색 → 복사 → AI 채팅에 붙여넣기 → 질문[MCP] AI가 직접 검색 도구를 호출 → 문서를 가져옴 → 알아서 답변기존에는 사람이 중간에서 사내 문서의 내용을 복붙하는 과정이 필요했다. MCP를 쓰면 AI가 "이 주제에 대한 문서가 필요하다"고 판단하면 스스로 검색 도구를 호출해서 컨텍스트를 확보한다. 2. RAG와 MCP의 차이둘 다 "AI..

https://ehdnsdlek.tistory.com/87 소스코드 분석부터 RAG까지, 사내 문서 검색 시스템 구축하기 (1)API를 연동해야 하는데 문서가 없다. Swagger는 있지만 필요한 정보가 빠져있고, API 명세와 실제 동작이 다른 경우도 많다. 담당자가 바뀌면서 "이 API가 왜 이렇게 동작하는지" 아는 사람도 없다. 결ehdnsdlek.tistory.com1편에서 전체 아키텍처를 설계했다. 이번에는 실제 구현 내용을 다루어보겠다. MDX 문서를 어떻게 쪼개고, BM25로 어떻게 점수를 매기고, RAG 챗봇이 어떻게 문서를 찾아서 답변하는지를 코드와 함께 설명한다.전체 흐름은 두 개의 파이프라인으로 나뉜다. 오프라인에서 인덱스를 만드는 파이프라인과, 런타임에서 검색하는 파이프라인이다. 1..

API를 연동해야 하는데 문서가 없다. Swagger는 있지만 필요한 정보가 빠져있고, API 명세와 실제 동작이 다른 경우도 많다. 담당자가 바뀌면서 "이 API가 왜 이렇게 동작하는지" 아는 사람도 없다. 결국 매번 담당 개발자를 찾아 물어봐야 한다. 이런 상황은 꽤 많은 팀에서 겪는 문제이다.이 글에서는 소스코드를 AI로 분석하고, 검색 가능한 문서 시스템을 만든 과정을 정리한다. 결론부터 말하자면, 전체 파이프라인은 다음과 같다.소스코드 -> SSoT -> 문서 -> 검색 1. 발생한 문제신규 서비스 PoC를 진행하면서 기존 시스템의 API를 연동해야 했다. 문제는 세 가지였다.(1) 개발 히스토리가 단절되었다.팀 변동이 잦은 조직에서 흔히 발생하는 문제인데, 코드에 주석도 없고 위키도 비어있어서..

스프링을 처음 접하면 @Controller, @Service, @Autowired 같은 어노테이션부터 마주하게 된다. 코드에 어노테이션을 붙이면 뭔가 알아서 동작하는 것 같은데, 정확히 왜 이렇게 하는 건지는 잘 와닿지 않는다. 이 글에서는 스프링의 핵심 개념들을 정리한다. 결론부터 말하면 전부 "스프링이 객체를 관리한다"는 한 가지에서 출발한다. 1. 스프링을 쓰는 이유스프링은 객체의 생성과 관리를 대신 해주는 프레임워크이다. 이게 왜 중요한지를 코드를 보면 바로 이해된다.회원 데이터를 메모리에 저장하다가 DB로 바꿔야 하는 상황을 생각해보자.스프링 없이 직접 하면 MemberRepository를 사용하는 모든 곳을 찾아서 수정해야 한다. // MemberService.java private fin..

이전 글에서 웹 서버와 WAS의 역할, 서블릿이 HTTP를 객체로 추상화해준다는 사실, 멀티 쓰레드와 쓰레드 풀의 동작 원리를 정리했다. 이번 글에서는 그 서블릿을 실제로 어떻게 사용하는지, 그리고 서블릿만으로 웹 어플리케이션을 만들다 보면 어떤 불편함이 생기고, 그 불편함이 어떻게 MVC 패턴과 프론트 컨트롤러, 그리고 최종적으로 Spring MVC라는 프레임워크로 이어지는지를 정리한다.1. 서블릿으로 HTTP 요청 다루기이전 글에서 서블릿은 HTTP 메세지를 자바 객체로 추상화해준다고 했다. 개발자는 텍스트로 된 HTTP 메세지를 직접 파싱하지 않고, HttpServletRequest와 HttpServletResponse라는 객체를 통해 요청을 읽고 응답을 쓴다.그렇다면 실제로 클라이언트가 서버에 데..

스프링 MVC를 본격적으로 배우기 전에 웹 서버, 서블릿, 멀티 쓰레드 같은 개념을 먼저 학습해야한다.프레임 워크를 사용하기 전에 그 프레임 워크가 대신 해주는 일이 무엇인지 알아야 하기 때문이다.스프링 MVC는 @Controller, @GetMapping 같은 어노테이션 몇 개만 붙이면 HTTP 요청을 받아 응답을 돌려줄 수 있어 편하다.하지만 그 편리함이 어디서 오는지는 잘 보이지 않는다. 요청이 들어와서 내 컨트롤러 메서드가 호출되기까지, 그 사이에 누가 TCP 연결을 받고 HTTP 메시지를 파싱하고 쓰레드를 할당하는지 모르는 채로 코드는 돌아간다.웹 서버와 WAS의 차이, 서블릿이 대신 해주는 일, 멀티 쓰레드 처리가 이뤄지는 방식, 서버가 내려주는 응답의 형태, 그리고 자바 웹 기술의 흐름을 정..