"한빛미디어 서평단 <나는 리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."
이 책을 읽게된 계기
이 글을 작성하는 시점(26년 2월)에 온 세상은 AI 얘기로 떠들썩하다. 링크드인, 해커뉴스부터 모든 미디어는 AI에 집중하고 있다. 주식시장도 마찬가지다. 너무 많은 자본과 관심이 AI에 집중되고 있다. 개발자 입장에서 AI는 기술적 거품은 없어 보인다. 하지만 성급한 투자자들 눈에는 투자 대비 수익(ROI)이 성에 차지 않아 버블처럼 무너질까 두렵다.
일론 머스크는 AI와 로봇 기술이 급격하게 발전함에 따라 10 - 20년 뒤 노동시장은 지금과 다르며 전통적인 방식의 노후 자금 저축이 무의미해질 수 있다는 주장을 하고 있다. 이런 비관적인 소식을 접할 때마다 지금 하고 있는 일들이, 공부와 연구들이 의미가 있을까? 하는 걱정도 있다.
소문에 사서 뉴스에 팔아라. 요즘은 이 말을 뼈저리게 느끼고 있는 세상이다. AI를 위해 필요한 칩들을 구매하기 위해 기업들이 줄을 서고 있다. 전기도 많이 필요해져서 전기 인프라나 원전 설비에도 돈이 쏠리고 있다. 거대한 손들이 오가는 이곳에서 개미들은 어떻게 해야 할까?
금융시장은 정보의 비대칭이 굉장히 심하다고 느낀다. 정보 비대칭 속에서 더 빠르게 인사이트를 얻을 수 있는 방법은 무엇일까? 백엔드 개발자로 일하면서 가장 잘할 수 있는 일이 무엇이냐고 묻는다면 서버를 개발하는 일이다. 바로 금융 도메인에 적합한 AI 에이전트를 개발하여 활용해 보는 것이 어떨까 하는 결론에 도달했다.
본래 HR 도메인에서 백엔드 개발자로 있기 때문에 금융 도메인에 대한 지식도 부족하고, AI 관련 개발을 해본 적도 없기 때문에 스스로 공부해서 헤쳐나가야 할 영역이다. 그러던 중 운이 좋게 한빛미디어 서평단 활동을 할 수 있게 되었고, 또 운이 좋게 AI 관련 도서를 선택할 수 있어서 이 글을 작성할 수 있게 되었다.
책을 읽고 얻은 인사이트와 적용점
이 책을 읽고 나의 개인 프로젝트에 적용해 볼 만한 내용을 담은 챕터들은 다음과 같았다:
- 아키텍처 및 설계 심화 (2. 에이전트 시스템 설계, 5. 오케스트레이션)
- 실질적인 기능 구현 (4. 도구 사용, 6. 지식과 메모리)
- 품질 관리 및 운영 (9. 검증 및 측정, 10 프로덕션 모니터링)
각 챕터를 읽으면서 어떤 내용이 어떤 인사이트로 이어졌고, 내 개인적인 프로젝트에 어떻게 적용할지를 아래 정리해 보았다. 일부 챕터들은 개인 프로젝트의 진행도에 따라서 읽지 않은 부분이 있다는 점을 참고하면 좋겠다.
4. 도구 사용
챕터 5 오케스트레이션에서 활용될 도구들이 어떻게 개발될 수 있는지 다룬다. 도구라는 단어는 쉽게 와닿지 않기 때문에 랭체인 기초 부분을 읽어보면 그 의미를 알 수 있다.
랭체인 기초
"4. 도구 사용"의 앞부분에서는 랭체인 기초를 다룬다. 배경 지식이 전혀 없는 상태였기 때문에 LLM이 여러 요소들과 어떻게 상호작용하여 결과물을 만들어내는지 이해하는데 큰 도움이 되었다.
간단하게 랭체인의 대화 컨텍스트를 유지하기 위한 메시지 구조를 이해하면 된다. 다음 세 가지 유형이 있다:
- HumanMessage: 사용자의 입력
- AIMessage: 모델의 응답
- ToolMessage: 도구 호출 결과
즉 LLM 자체는 무상태 기반이기 때문에 사용자, 도구, 모델 세 가지의 상호작용의 결과를 리스트에 순서대로 append 하면서 컨텍스트를 유지하는것이 핵심이다. 또한 컨텍스트 윈도우 개념을 이해하는게 중요하다. 컨텍스트 윈도우는 모델이 한 번의 추론 과정에서 동시에 '바라보고' 처리할 수 있는 데이터의 최대 허용량을 나타낸다.
지금까지 대화한 히스토리와 지금 하려는 질문 그리고 전달되어서 생성되는 답변까지 고려하여 허용량 내에서 질문을 해야 한다. 허용량을 넘어서면 에러처리가 되어 반환된다. 이러한 문제를 극복하기 위해 지난 히스토리를 압축하거나, 지난 히스토리를 잊어버리고 윈도우를 앞으로 전진시키게 된다.
도구들
오늘날 LLM 서비스는 사용자, 도구, 모델 세 가지의 상호작용의 결과로 이해할 수 있다. 여기서 도구는 무엇인지 챕터 4에서는 5가지 타입으로 나눠서 설명했다. 책에 나온 내용들 외적으로 조사를 통해 아래처럼 표를 만들어 정리해 두었다. 이 중에서 주목해 볼 만한 내용은 API 기반 도구와 MCP다.
| 도구 유형 | 의미 | 백엔드/아키텍처 관점의 특징 | 활용 예시 |
| 로컬 도구 (Local) |
에이전트가 실행되는 동일한 런타임/서버 환경 내에서 직접 실행되는 함수나 스크립트 | - 네트워크 지연이 없고 빠름 - 악의적인 프롬프트 인젝션부터 격리가 필수적임 |
로컬 파일 읽기/쓰기, 내장 계산기 함수, 서버 내 정규표현식 파서 등 |
| API 기반 도구 (API-based) |
외부 서비스와 네트워크(HTTP, gRPC)를 통해 통신하여 데이터를 주고 받는 도구 | - 가장 흔한 형태(Restful 통신) - 외부 의존성이 생기며, 인증/인가(API Key), 타임아웃, 재시도 로직 처리가 필요함 |
DART 전자공시 API 조회, 실시간 주가 검색, 구글 검색, 외부 날씨 API 연동 |
| 플러그인 도구 (Plugin) |
특정 AI 플랫폼(ChatGPT 등)의 생태계 표준 규격(보통 OpenAPI Spec)에 맞춰 패키징된 도구 | - 규격화된 인터페이스(Swagger/OpenAPI)를 제공하여 에이전트가 도구의 입출력 스키마를 쉽게 이해하도록 추상화된 형태 | ChatGPT Plugins, Custom GPTs의 외부 Actions, LangChain의 툴킷 |
| MCP (Model Context Protocol) |
AI 모델이 로컬/원격 데이터 소스에 안전하게 접근하도록 돕는 오픈 표준 프로토콜(Anthropic 주도) | - AI를 위한 표준화된 데이터 연결 파이프 - 에이전트와 데이터 소스를 디커플링하여 아키텍처 종속 |
로컬 DB(PostgreSQL, SQLite) 직접 연결, 로컬 Git 저장소 파일 컨텍스트 주입 등 |
| 상태 유지 도구 (Stateful) |
단발성 호출로 끝나지 않고, 여러 번의 호출 사이에서 상태(State)나 세션을 유지하는 도구 | - 무상태(Stateless)인 LLM에게 세션을 제공 - 메모리 관리가 필요하며, 연속된 작업(워크플로우)을 수행할 때 필수적임 |
Python 코드 인터프리터(변수 값 유지), 브라우저 자동화 도구(쿠키 및 로그인 상태 유지) |
내가 API 기반으로 만들 수 있는 도구의 종류는 DART 공시를 조회하거나 네이버 API를 통해 뉴스를 조회하거나, 한국투자증권의 OpenAPI를 이용할 수 있다. MCP로는 벡터 DB과 같은 로컬 DB를 구성해서 스스로 필요한 내용들을 조회할 수 있도록 열어두는 방식을 고려할 수 있다.
5. 오케스트레이션
오케스트레이션은 단순히 어떤 도구를 언제 호출할지 결정하는 것을 넘어 각 모델 호출(model invocation)에 적합한 컨텍스트를 구성해 효과적이고 근거 있는 행동을 유도하는 과정을 포함합니다. (p. 127)
근본적으로 LLM 자체는 주어진 컨텍스트 내에서 통계적 확률에 따라 다음 단어를 예측하는 '단순 문답형' 텍스트 생성 엔진에 불과하다. 이전 상태를 기억 못 하는 무상태(stateless)이기 때문에 이런 단순한 기능으로는 우리가 지금 누리고 있는 웹기반 ChatGpt, Gemini에서 제공하는 복잡한 AI 서비스를 제공할 수 없다.
이 모든 건 백엔드 코드 단에서 단순한 LLM을 어떻게 감싸고, 어떤 순서로 다단계 호출을 하며, 외부 시스템(API, DB)과 어떻게 엮어낼 것인가가 중요하다. 5. 오케스트레이션 챕터에서는 이러한 내용을 다루고 있다.
5.1 에이전트 유형
[표 5-1 공통적인 에이전트 아키타입]
| 에이전트 유형 | 강점 | 약점 | 최적 적용 사례 |
| 반사형 에이전트 | 밀리초 단위 응답 | 다단계 추론 불가 | 키워드 라우팅, 단순 조회 |
| 리액트 에이전트 | 유연한 적응력 | 더 높은 지연시간과 비용 | 탐색형 워크플로, 트러블 슈팅 |
| 계획 후 실행 에이전트 | 명확한 작업 분해 | 계획 수립 오버헤드 | 복잡한 다단계 프로세스 |
| 쿼리 분해 에이전트 | 근거가 명확한 검색 정확도 | 다수의 도구 호출 필요 | 리서치, 사실 기반 QnA |
| 성찰형 에이전트 | 초기 오류 감지 | 추가 연산 및 지연시간 | 고위험, 안전이 중요한 작업 |
| 심층 리서치 에이전트 | 다단계 및 적응형 조사 관리 | 높은 연산 비용과 매우 긴 지연시간 | 장문의 문헌 리뷰 |
위 표는 책에서 제시하는 기본적인 에이전트 유형을 나타낸다. 저자는 앞으로 더 많은 에이전트 유형이 개발될 것이며 이것은 출발점임을 언급했다. 내가 개인적으로 개발하고 있는 서비스는 단순한 워크플로우에 단순한 LLM의 문답 기능을 활용하고 있다.
책을 읽지 않았다면 이러한 방향으로 발전하고 있다는 사실을 깨닫지 못하고 개발을 하고 있었을 것 같다. 하지만, 인지하지 못했을 뿐 개발 방향 자체는 특정 타입의 에이전트를 구축하고 있음은 변하지 않는다.
일반적인 심층 리서치는 검색, 요약, 재검색 플로우를 수 초에서 수 분 내에 동기식으로 While 루프를 돌려 수행하는 방식이다. 내가 고려하는 방식은 이 루프의 주기를 하루 또는 한 달로 늘려 비동기적으로 분리해서 처리하는 방식이다. 아래는 그 흐름을 도표로 작성했다.
매일 뉴스와 공시를 스케줄 Polling방식으로 수집한다. 이에 따른 시장의 반응도 증권을 통해서 수집한다. 매일 특정 시간에 일간 배치, 기간배치를 이용해 집계 처리를 한다. 집계 처리된 데이터들은 산업 섹터, 경제 지표 등등에 따라 분류를 하고 이를 LLM에게 컨텍스트로 제공할 수 있다.
이 흐름에서 단일 LLM 호출 자체는 무상태 문답형 일지 몰라도 데이터를 수집하고(일간), 압축하고(월간), 최종 프롬프트에 주입하는 전체 백엔드 파이프라인 자체가 거대한 기억이며 심층 리서치 에이전트로 동작하게 된다.
5.2 도구 선택
[표 5-2 도구 선택 전략]
| 기법 | 장점 | 단점 |
| 표준 도구 선택 | 구현이 단순함 | 도구의 수가 많아지면 확장성이 떨어짐 |
| 시맨틱 도구 선택 | - 매우 많은 수의 도구로 확장성이 뛰어남 - 보통 구현 시 지연시간이 낮음 |
시맨틱 충돌(sematic collision) 때문에 선택 정확도가 떨어지는 경우가 많음 |
| 계층적 도구 선택 | 매우 많은 수의 도구로 확장성이 뛰어남 | 연속으로 파운데이션 모델을 여러 번 호출해야 해서 더 느림 |
표준 도구 선택은 에이전틱 코딩에서 말하는 툴, 스킬과 굉장히 유사하다. 각 도구에 이름과 설명을 바탕으로 실제 명령어를 실행하기 전에 파운데이션 모델을 한 번 호출해서 도구 선택을 하게 한다. 선택된 도구를 이용해서 메인 요청을 수행한다.
작업이 완료되거나 인간 개입(human in the loop) 패턴 혹은 사람의 확인이 필요한 경우, 특정 채널에 알림을 보내는 도구도 등록할 수 있다. 아래는 특정 기업의 주식을 매수하라는 클라이언트의 요청이 왔을 때 어떻게 도구가 선택될 수 있는지, 그리고 컨텍스트가 어떻게 유지되어야 하는지를 내가 개발하려는 프로젝트에 어떻게 적용할 수 있을지 아이디어를 시퀀스 다이어그램으로 표현했다.
주식 구매와 같은 크리티컬 한 작업은 결국 사람의 결재과정이 플로우 속에 존재해야 하고, 매 LLM과의 상호작용에는 컨텍스트를 유지하는 방법을 고려해야 한다는 점을 여기서 기억하고 넘어간다. 간단한 방식이지만 오히려 도구의 개수가 많아지면 잘못된 도구선택을 방지하기 위한 가드레일이 필요해 보인다.
만약 50개 100개의 도구가 존재한다면 매번 LLM을 요청할 때마다 토큰 비용이나 정확도에 대한 우려가 생길 수밖에 없다. 이를 해결하기 위한 방법으로 시맨틱 도구 선택이 제시되었다. RAG를 도구 선택에 사용한다고 이해할 수 있다. 미리 도구에 관련된 설명들을 임베딩하여 백터 DB에 저장하고 사용자의 요청을 백터 화해서 가장 유사한 도구를 가져오는 방식이다. 이 방식은 표준 도구 선택보다 빠르고, 성능도 우수하며 확장성도 충분히 좋다.
시맨틱 도구 선택 방식이 충분하지 않은 경우가 있다. 시맨틱 도구 선택 방식은 근본적으로 텍스트를 벡터(숫자 좌표)로 변환하여 두 점 사이의 수학적 거리(Consine Similarity)를 재는 기술이기 때문이다. 예를 들어, "현대건설 주가는 볼 필요 없고, 최근 유상증자 관련 DART 공시만 분석해 줘"라는 요청을 했을 때, 백터 임베딩 모델은 이 문장에서 주가, 분석이라는 키워드의 가중치를 높게 잡아 주가 조회 도구와 공시 조회 도구를 호출해서 분석하게 될 수 있다. 결과적으로 주가는 볼 필요 없다는 의도를 제대로 이해하지 못하는 이슈가 발생한다.
이를 해결하기 위한 방법으로 계층적 도구 선택 방식을 사용한다. 도구들을 그룹화해서 단계적으로 도구 그룹 → 도구 선택의 과정을 에이전트를 통해 거치면 되기 때문에 자연어를 이해할 수 있게 된다. 아래는 그 과정을 이해하기 쉽게 시퀀스 다이어그램으로 표현해 보았다.
이쯤에서 의문점은 "그렇다면 계층적 도구 선택과 표준 도구 선택의 차이점은 무엇인가?"이다. 결국 에이전트를 사용하기 때문에 동일하지 않냐는 것이다. 내가 이해한 차이점을 아래에 다이어그램으로 비교해 두었다.
왼쪽의 표준 도구 선택은 결국 단일 에이전트에서 모든 도구 컨텍스트를 한 번에 넘겨서 처리하게끔 하는 방식이다. 이 방식은 도구의 개수가 늘어날수록 문제가 발생함을 이해하였고 그 결과 시맨틱 도구 선택을 대안으로 선택할 수 있었다.
반면에 계층적 도구 선택 방식은 책임을 분리하여 여러 단계를 사용하는 방식이다. 여기서 좀 더 나아가면 슈퍼바이저/서브 에이전트 방식으로 확장될 수 있다. 슈퍼바이저 에이전트는 단순히 도구 선택의 책임만 갖고, 서브 에이전트에게 선택된 도구를 이용해서 실질적인 요청 처리를 위임(Delegate)한다. 결국 설계측면에서 보면 엔터프라이즈급의 시스템을 설계함에 있어서 객체지향과 DDD의 이해는 필수로 여겨진다.
5.4 도구 토폴로지
5.4에서는 도구 토폴로지에 대해 설명한다. 종류로 (1) 단일 도구 실행, (2) 병렬 도구 실행, (3) 체인/트리 (4) 그래프. 4가지 방식이 있으며 왼쪽에서 오른쪽으로 갈수록 복잡성이 증가하기 때문에 이전 쉬운 토폴로지로 구현할 수 있다면 쉬운 방식을 택하는 게 유지보수에 유리하다. 단일 도구 실행은 모델이 하나의 도구의 결과를 동기적으로 받아서 클라이언트에게 응답을 반환한다. 병렬은 말 그대로 동기적인 병렬이다. 체인부터 복잡해지는데 A, B, C라는 워크플로우를 수행할 때 A가 완료되면 B 그리고 순차적으로 C를 수행할 수 있는 관계를 말한다. 반면에 그래프는 복잡한 분기문이 동적으로 결정되며 중간에 사이클이 발생할 수 있다.
내가 진행 중인 프로젝트에서는 DART의 공시를 스케줄러가 트리거하여 Polling해온다. 수집된 데이터를 바탕으로 공시의 성격을 분류하는데 이 부분은 LLM으로 할 수 있도록 전략패턴으로 구성해 두었다. 다만 빠르게 판단이 필요한 시점이기 때문에 단순한 문자열 매칭으로 분류할 수 있도록 해두었다. 우리나라의 전자공시는 분류체계가 쉽게 되어있지만, 미국의 공시는 k-8, k-10 등으로 구분되며 내부 내용이 k-8은 내부 내용이 제각각일 가능성이 있다. 이 경우에 LLM을 통해 분류할 수 있도록 열어둔 것이다.
결국 LLM이 참여하여 동적으로 이 공시 데이터를 더 분석하면 좋을지 결정되는 분기문과 정보의 적절성을 판단하는 과정들이 들어가 있기 때문에 그래프 토폴로지로 생각해 볼 수 있었다. 아래는 그러한 과정을 그려보았다.
아직은 심층 리서치 에이전트를 위한 집계 데이터 셋을 구성하지는 못했지만 어느 정도 틀이 잡힌 상태이다. 결과를 응답할 때 지연시간, 실시간성을 고려해서 설계를 해야 한다. 만약 정확성은 떨어지지만 빠른 응답속도를 요구하는 케이스가 분명 존재한다. 그 경우는 일단 응답을 하고 추가적인 분석은 비동기로 분리해서 정보의 정확성을 보완하는 방식을 제공해야 한다.
5.5 컨텍스트 엔지니어링
컨텍스트 엔지니어링은 메모리, 지식, 오케스트레이션이 교차하는 지점에 위치합니다. 오케스트레이션이 워크플로에서 어떤 단계를 수행할지 결정한다면 컨텍스트 엔지니어링은 각 단계가 효과적으로 실행되는 데 필요한 정보를 갖추도록 책임집니다. 파운데이션 모델이 계속 발전함에 따라 에이전틱 시스템 설계의 최전선은 모델 아키텍처 자체에서 우리가 제공하는 컨텍스트의 품질로 이동하고 있습니다. (p.154)
DART 전사공시의 OpenAPI 응답은 XML로 이뤄진다. 파싱을 하고, 중요한 정보만 골라서 LLM에게 전달하는 것이 중요하다. 만약 XML태그와 같이 불필요한 정보도 같이 전달하게 된다면 토큰이 낭비될 뿐만 아니라 응답 자체의 정확성이 떨어지게 된다.
컨텍스트 엔지니어링을 하면서 '책임'을 분리해야 한다. 파싱을 담당하는 책임, 공시를 분석하는 책임, 주요 지표를 계산하는 책임 등 작게 잘라서 작은 컨텍스트로 하나의 책임만을 담당하도록 요청을 해야 한다.
6. 지식과 메모리
지식(주로 RAG로 구현)은 기술 스펙, 정책 문서, 상품 카탈로그, 고객 또는 시스템 로그 같은 사실이나 도메인 특화 콘텐츠를 생성 시점에 끌어와 에이전트가 즉각적인 대화를 넘어 검증 가능한 정보를 '알도록' 만듭니다. 이는 특히 모델 자체, 즉 가중치와 편향에 저장된 정보를 보완합니다.
반면 메모리는 에이전트 자신의 히스토리를 포착합니다. 과거의 사용자 대화, 도구 출력, 상태 업데이트 등이 여기에 포함됩니다. 메모리를 통해 에이전트는 여러 턴과 세션에 걸쳐 연속성을 유지하며 과거 상호작용을 '기억'하고 이 이력을 활용해 앞으로의 의사결정을 내릴 수 있습니다. (p.157)
"컨텍스트 윈도 관리"는 각 파운데이션 모델들의 컨텍스트 한계를 어떻게 극복할지에 대한 방법론이다.
백엔드 개발자인 내가 디자이너, 기획자, 프론트와 논의를 한다고 가정한다. 나의 기억력은 2일이며 3일 전에 논의한 내용까지 기억하려면 에러를 발생시키게 된다. 따라서 3일 전의 모든 대화내역은 지워버리고 새로운 내용을 기억하기 시작한다. 이 방식이 가장 기본적인 롤링 방식이다. 다른 방법으로는 과거의 기억을 더 작고 보관하기 쉽게 압축시켜 두는 것이다. 예를 들어, 7일치를 1일 치로 압축시키면 나는 7일에서 오늘 기억까지 총 8일(온전하지 않지만)을 기억할 수 있다. 이러한 제약이 최대 컨텍스트 크기이다.
| 제조사 | 주요 모델 | 최대 컨텍스트 크기 |
| Google |
Gemini 1.5 Pro / Flash | 2,000,000 토큰 |
| Anthropic | Claude 3.5 Sonnet / Opus | 200,000 토큰 |
| OpenAI | GPT-4o / o1 계열 | 128,000 토큰 |
| Meta | Llama 3.1 (8B, 70B, 405B) | 128,000 토큰 |
| Gemini 1.5 Pro / Flash | 2,000,000 토큰 |
전체 텍스트 검색에서는 역인덱스, BM25에 대해 설명한다. 원래 있던 기술을 LLM에게 적절한 컨텍스트를 전달하기 위한 검색 기능을 붙인 것이다. 역인덱스는 흔히 전공서적 뒤쪽에 있는 페이지를 예를 들어 설명한다. 이 책의 뒤편에도 다음과 같은 페이지가 존재한다:
의미 있는 용어들로 토큰화하고, 각 페이지의 위치를 리스트업 하면 된다. 예를 들어, "데이터 정화 강화학습"을 검색하면 "데이터 정화"로부터 120페이지, "강화학습"으로부터 33페이지를 가져올 수 있다. BM25는 가져온 페이지들을 순위를 매겨서 어떤 것을 LLM에게 먼저 제공할지를 결정해 주는 알고리즘과 같다.
그다음으로 나온 방식은 시멘틱 메모리와 벡터 스토어다. 이전에서 논의했듯이 컨텍스트들을 미리 벡터화에서 벡터 DB에 임베딩 해두고, 클라이언트의 요청을 받아 벡터화해서 서로 거리가 비슷한 컨텍스트를 함께 프롬프트에 담아서 LLM에게 전달하는 방식이다.
RAG 관련 실험은 이전 포스팅에서 진행한 경험이 있다: [RAG 실험 #1] 개념은 나중에 - 내 Mac에서 RAG를 일단 돌려보기
6.3 그래프 RAG
그래프 RAG(그래프 기반 검색 증강 생성)은 그래프 기반 데이터 구조를 도입해 검색 과정을 향상하는 고급 RAG 확장 기법입니다. 그래프를 활용하면 그래프 RAG는 정보 조각들 사이의 복잡한 상호 관계와 의존성을 관리하고 활용할 수 있어 생성된 느 콘텐츠의 풍부함과 정확성을 크게 높일 수 있습니다. (p.168)
벡터 검색 기반 RAG에서 실무적 한계를 부딪힌다면 고려해 볼 만한 방법이다. 물론 더 비싸고 복잡도가 큰 방법이다. 6.3 그래프 RAG에 대한 내용도 사실 Gemini와 소통하면서 이미 어떻게 적용할지에 대한 아이디어를 얻고 있는 상태에서 읽게 되었다.
아이디어 자체는 심플하다. 기업과 기업 간의 관계 그리고 산업 섹터의 그룹화를 그래프 DB 화하고 싶었다. 최근 전자공시 관련 책을 읽으면서 업스트림과 다운스트림 개념에 대해 알게 되었다. 예를 들어, 현대건설 측에서 원전 수주 공시라는 이벤트가 발생했을 때 현대건설의 업스트림기업과 다운스트림 기업을 알게 된다면 산업의 방향과 돈의 흐름을 빠르게 캐치할 수 있다는 것 아닐까?
업스트림은 두산에너빌리티와 같은 핵심 기자재 및 설비를 공급해 주는 기업이다. 다운스트림은 AWS처럼 데이터센터를 짓기 위해 소형 원전을 발주할 수 있는 주체가 된다. 돈의 흐름은 기자재를 공급해 주는 업스트림부터 실제 수주를 받아 건설을 해서 정산을 받는 현대 건설 그리고 건설한 결과물로부터 서비스를 창출하여 실질적으로 영업이익을 가져오는 다운스트림이 마지막이 된다.
이러한 아이디어를 실현하기 위해 현재 고민 중인 백엔드 아키텍처에서의 데이터 흐름이다. 기업에 대한 정보들은 모두 노드로 들어간다. 핵심은 그 노드 간의 엣지를 어떻게 설계하냐가 LLM의 컨텍스트 관리의 핵심이다.
9. 검증 및 측정 & 10. 프로덕션 모니터링
아직 읽을 시기가 아니라서 생략합니다. 실제로 용도가 생겼을 때 발췌독할 예정인 챕터들.
이 책에 대해 어떻게 생각하는가?
이 시대 AI의 본질은 무상태 LLM을 호출을 통해 문답형 텍스트 생성기에 불가하다. 그럼에도 불구하고 너무나 복잡한 개념들이 추상화되어 더욱 학습이 어려워지는 것 같다. 이 책에서도 마찬가지로 '멀티 에이전트'라는 개념과 '단일 에이전트'라는 개념을 나눴다. 도대체 '멀티 에이전트'란 무엇인가?
소프트웨어 설계 관점에서는 LLM의 본질을 이해하고 도메인별로 컨텍스트를 완벽히 격리하여 각 책임에만 집중할 수 있도록 워크플로우를 설계하는 것이 중요해 보인다. LLM은 단지 인프라 계층의 Repository와 다를 게 없어 보인다. 우리가 DB에서 데이터를 꺼내오기 위해 SQL을 작성하듯, LLM이라는 '비결정론적 추론 엔진'에서 데이터를 가져오기 위해 Prompt를 작성하는 것과 동일하다. 다만 그 기능이 광범위해서 적절한 하네스와 가드레일처럼 소프트웨어 공학적 장치들이 엄격하게 요구된다.
이러한 내재적인 원리와 물리적 한계점을 바탕으로 개념이 진화되어야 하는데, 너무나 복잡한 용어들과 기술들이 추상화되어 복잡도가 점점 높아지고 있다. 책 커버리지는 AI 엔지니어링 측면에서 훌륭하나 불필요한 복잡도를 갖고 있다. 이 책을 읽을 때는 LLM의 도움을 받아서 읽는 것을 추천한다.
참고 자료
- Cookbook Agent Patterns - Basic workflows | Claude
- Building effective agents | Anthropic (2024)
