아프니까 개발자다 아프니까 개발자다

LangChain이 해결한 문제는 명확했다. LLM을 쓸 수 있는 형태로 만들기 위한 반복 작업을 없애는 것이다. 그런데 에이전트를 실제로 만들다 보면 또 다른 벽에 부딪힌다."결과가 부족하면 다시 검색한다." 이 한 문장을 코드로 표현하는 순간, 선형 체인(Chain)은 한계를 드러낸다. 루프가 없기 때문이다. 체인은 A → B → C로 흘러갈 수는 있어도, "C가 충분하지 않으면 B로 돌아가라"는 구조를 표현할 방법이 없다.LangGraph는 그 한계를 해결하기 위해 2024년에 등장했다. LangChain의 연장선이지만, 패러다임이 다르다. 선형(linear)에서 그래프(graph)로 달라졌다.1. 배경 — LangChain의 체인(Chain)이 충분하지 않았던 이유LangChain의 초기 핵심 개..

이전 글에서는 LLM 구조화 출력을 구현하는 두 전략 — ProviderStrategy와 ToolStrategy — 중 어떤 것을 선택해야 하는지 다뤘다. 전략을 정했다면 다음 질문은 스키마를 어떻게 설계하느냐다. 스키마가 부실하면 전략이 무엇이든 LLM이 잘못된 값을 채운다. 그 스키마의 도구가 Pydantic이다.Pydantic이란Pydantic은 Python 타입 어노테이션을 그대로 검증 규칙으로 쓰는 데이터 검증 라이브러리다. 2017년 Samuel Colvin이 만들었고, FastAPI가 요청/응답 스키마를 Pydantic으로 선언하면서 폭발적으로 보급됐다. 2023년에 v2로 재작성되면서 내부 엔진이 Rust로 바뀌었고 검증 속도가 v1 대비 5~10배 빨라졌다.Pydantic이 LLM 생태계..

LLM마다 코드를 따로 써야 했던 시절OpenAI GPT를 쓰다가 Anthropic Claude로 바꾸려면 얼마나 손봐야 할까? 2023년 초까지만 해도 대답이 단순했다. "코드를 거의 다시 써야 한다." 각 LLM 제공사(provider)가 저마다 다른 SDK, 다른 함수 이름, 다른 요청 형식을 썼기 때문이다.LLM provider별로 완전히 다른 코드가 필요한 상황. 위 다이어그램은 동일한 "AI에게 질문하기"라는 목적을 달성하기 위해 provider마다 함수 이름, 매개변수 이름, 메시지 포맷이 모두 다른 현실을 보여 준다. OpenAI는 client.chat.completions.create(), Anthropic은 client.messages.create(), Google은 generate_c..

2022년 말 ChatGPT가 공개된 이후, 개발자들 사이에서 한 가지 공통된 질문이 등장했다."LLM을 내 서비스에 어떻게 집어넣지?"답은 간단해 보였다. API를 호출하면 된다. 그런데 실제로 해보면 달랐다. 대화 이력을 직접 관리해야 하고, 외부 검색 기능을 붙이려면 연결 코드를 따로 짜야 하고, LLM이 여러 번 판단을 반복하도록 루프를 구현해야 했다. 강력한 언어 모델을 손에 쥐었는데, 정작 그것을 "쓸 수 있는 형태"로 만드는 데 시간의 대부분을 써야 했다.LangChain은 그 반복을 없애려는 시도로 2022년 10월에 등장했다.1. 배경 — GPT 등장 이후 개발자들이 맞닥뜨린 문제LLM(Large Language Model, 거대 언어 모델) API는 사실 단순하다. 텍스트를 보내면 텍스..

assistant 롤은 MCP가 만든 게 아니다user / assistant 롤 구조는 2023년 3월 OpenAI가 Chat Completions API를 공개하면서 업계 표준이 됐다. 이후 Anthropic Messages API, Google Gemini, Mistral 등 사실상 모든 LLM 제공자가 동일한 구조를 채택했다. messages 배열에 user와 assistant 턴을 번갈아 넣어 대화 history를 표현하는 방식은 MCP 이전부터 이미 보편적 관행이었다.MCP(Model Context Protocol)는 2024년 11월 Anthropic이 발표했고, prompts/get 응답의 messages 배열도 이 기존 표준을 그대로 빌려왔다. MCP가 새로 더한 것은 롤 자체가 아니라 서..

MCP의 세 기본 단위 중 Prompts는 가장 오해받는다. Tools는 "AI가 실행하는 함수"라고 설명하면 직관적으로 와닿는다. Resources는 "AI가 읽는 데이터"라고 하면 이해된다. 그런데 Prompts는? "서버에 저장된 재사용 프롬프트 템플릿"이라는 설명을 들으면 "그냥 클라이언트에서 관리하면 되지 않나?"라는 의문이 든다.이 의문이 Prompts를 이해하는 출발점이다.왜 프롬프트를 서버에 두는가AI 개발 도구를 만든다고 가정하자. "코드 리뷰 해줘"라고 요청할 때 어떤 프롬프트를 쓸 것인가? 팀원 10명이 각자 다른 방식으로 요청하면 결과 품질이 들쭉날쭉해진다. 누군가 몇 달에 걸쳐 다듬은 최적 프롬프트가 있다면, 그걸 모두가 쓸 수 있어야 한다.클라이언트(IDE 플러그인)에 프롬프트를..

지난 글에서 MCP의 세 기본 단위(Tools·Resources·Prompts)를 큰 그림으로 훑었다. 이번 글은 그 중 Resources를 뼈대까지 분해한다. Resources는 5가지 요청 메서드 + 2가지 알림으로 구성되며, "AI가 외부 데이터를 어떻게 읽는가"라는 문제를 URI(Uniform Resource Identifier) 기반 접근 모델로 푼다.먼저 가장 흔한 오해부터 짚는다. Tools로도 파일을 읽을 수 있는데 왜 Resources가 따로 필요한가?Tools vs Resources — 같은 파일, 다른 목적Tools의 read_file 도구와 Resources의 resources/read는 둘 다 파일 내용을 돌려주지만, MCP 명세가 둘을 분리한 이유가 있다. 핵심 차이는 누가 트리..

지난 글에서 JSON-RPC 2.0이 봉투 6단어(jsonrpc·id·method·params·result·error)만 정의하고, 그 안의 내용물은 전부 상위 계층이 채운다는 걸 짚었다. 그 상위 계층이 바로 MCP(Model Context Protocol)다. 이번 글은 MCP가 봉투 안에 실제로 뭘 채웠는지를 다룬다 — 메서드 이름, params 구조, result 구조, 그리고 각 메서드가 왜 필요하고 언제 쓰이는지.MCP의 메서드는 현재 20여 개다. 흩어져 보이지만 세 기본 단위(Tools·Resources·Prompts)와 초기화·보조 카테고리로 묶으면 구조가 선명해진다. 가장 중요한 발견을 먼저 꺼내자면 — MCP는 단방향이 아니다. 서버가 클라이언트에게 LLM 호출을 위임(sampling..