*이 장을 다 읽고 나면 알게 될 것: Agent의 네 가지 구성요소가 무엇인지, 감각·두뇌·기억·행동을 각각 어떻게 설계하는지, 여러 Agent를 하나로 엮는 오케스트레이션이 왜 필요한지, 그리고 완벽하지 않아도 시작할 수 있다는 것*
도입: 어느 날 밤, 화이트보드 앞에서
2024년 가을. 나는 나의 시스템 사무실의 화이트보드 앞에 서 있었다. 새벽 두 시였다.
화이트보드에는 네모 상자 수십 개가 그려져 있었다. 상자들 사이를 화살표가 이었다. 어떤 화살표는 곧고, 어떤 화살표는 점선이었다. 한쪽 구석에는 "pgvector"라고 적혀 있었고, 가운데에는 "LangGraph"가 있었고, 반대편에는 "Qwen"이라고 적혀 있었다. 그 위에 빨간 마커로 크게 썼다. "이게 나인가?"
웃기는 질문이었다. 소프트웨어 아키텍처를 그리면서 "이게 나인가"라니. 그러나 그 순간 나는 진심이었다. 내가 만들고 있는 것은 단순한 자동화 시스템이 아니었다. 내 판단 방식을 모방하고, 내 기억을 저장하고, 내 습관을 학습하고, 내 대신 행동하는 무언가였다. 그것을 뭐라고 불러야 할지 모르겠어서 잠시 멈췄다. 비서? 아니다. 비서는 시키는 일만 한다. 이건 다르다. 이건 나를 알아야 한다.
그때 머릿속에 떠오른 단어가 있었다. 분신.
1부에서 우리는 일상의 일곱 영역을 봤다. 시간, 정보, 관계, 자산, 건강, 학습, 창작. 각 영역에서 Agent가 어떤 자리에 앉을 수 있는지를 살펴봤다. 이제 2부로 넘어간다. 직접 만드는 단계다.
만들기의 첫 단계는 설계다. 좋은 건물을 짓기 전에 좋은 설계도가 필요하듯, 좋은 Agent를 만들기 전에 좋은 아키텍처가 필요하다. 이 장에서는 개인 Agent의 아키텍처를 그린다. 네모 상자와 화살표, 그리고 그것들이 왜 거기에 있는지를 설명한다.
겁먹을 필요는 없다. 아키텍처라는 말이 거창하게 들리지만, 핵심은 단순하다. Agent는 네 가지로 이루어진다. 감각, 두뇌, 기억, 행동. 이 네 가지를 이해하면 나머지는 응용이다.
9.1 비서가 아니라 분신이다
먼저 개념을 바로잡아야 한다.
많은 사람이 AI Agent를 비서로 생각한다. "이거 해줘", "저거 찾아줘", "이 메일 보내줘". 명령을 내리면 실행하는 존재. 그것도 Agent이긴 하다. 그러나 그것은 가장 낮은 수준의 Agent다.
좋은 개인 Agent는 비서가 아니다. 분신이다. 차이가 뭔가.
비서는 시키는 일을 한다. 분신은 시키지 않아도 할 일을 안다. 비서는 맥락을 매번 설명해줘야 한다. 분신은 맥락을 이미 알고 있다. 비서는 실수하면 사용자가 바로잡는다. 분신은 사용자의 판단 기준을 학습해서 스스로 교정한다.
구체적으로 말하면 이렇다. 내가 매주 월요일 아침에 주간 보고서를 쓴다고 하자. 비서형 Agent는 "주간 보고서 써줘"라고 명령하면 빈 템플릿을 채운다. 분신형 Agent는 다르다. 월요일 아침이 되면 지난주의 회의록, 이메일, 메시지, 캘린더를 스스로 훑는다. 내가 주간 보고서에서 늘 강조하는 항목이 무엇인지 안다. 내가 싫어하는 표현이 무엇인지 안다. 그래서 초안을 미리 만들어둔다. 내가 출근하면 이미 거기에 있다.
이것이 가능하려면 Agent가 나를 알아야 한다. 내 습관, 내 선호, 내 판단 기준, 내 기억. 이것이 아키텍처의 출발점이다.
현실적으로 보면, 2026년 현재 완전한 분신형 Agent는 아직 없다. ChatGPT의 메모리 기능, Claude의 프로젝트 기능, 구글의 제미나이가 그 방향으로 가고 있다. 그러나 아직은 초기 단계다. 진짜 분신을 만들려면 직접 설계해야 한다. 그래서 이 장이 필요하다.
잠시 멈추고 생각해보자
당신이 AI에게 가장 자주 하는 요청은 무엇인가? 그 요청은 비서에게 시키는 일인가, 분신에게 맡기는 일인가? 만약 분신이 있다면 시키지 않아도 해줬으면 하는 일은 무엇인가?
9.2 네 가지 구성요소 — 감각, 두뇌, 기억, 행동
사람의 몸을 생각해보자.
우리는 눈으로 보고, 귀로 듣고, 피부로 느낀다. 이것이 감각이다. 뇌가 그 정보를 처리하고 판단한다. 이것이 두뇌다. 과거의 경험을 저장하고 꺼내 쓴다. 이것이 기억이다. 손으로 쓰고, 입으로 말하고, 발로 움직인다. 이것이 행동이다.
Agent도 마찬가지다. 구성요소는 네 가지뿐이다.
감각(Perception). Agent가 외부 세계에서 정보를 받아들이는 채널이다. 캘린더 데이터, 이메일, 메시지, 건강 데이터, 뉴스 피드, 날씨, 주가. Agent가 뭘 알 수 있는가는 감각이 결정한다.
두뇌(Brain). 받아들인 정보를 처리하고 판단하는 엔진이다. 대부분의 경우 LLM이 이 역할을 한다. GPT-4o, Claude, Qwen3, Llama. 어떤 LLM을 쓰느냐에 따라 Agent의 사고력이 달라진다.
기억(Memory). Agent가 과거의 맥락을 저장하고 꺼내 쓰는 장치다. 어제 무슨 대화를 했는지, 지난달에 어떤 결정을 내렸는지, 사용자가 어떤 선호를 보였는지. 기억이 없는 Agent는 만날 때마다 처음 보는 사람이다.
행동(Action). Agent가 외부 세계에 영향을 미치는 수단이다. 메시지 보내기, 일정 잡기, 파일 저장, API 호출, 알림 보내기. 생각만 하고 아무것도 안 하면 쓸모가 없다.
이 네 가지가 전부다. 아무리 복잡한 Agent도 이 네 가지의 조합이다. 구글의 제미나이도, OpenAI의 o3도, 내가 나의 시스템에서 만든 시스템도 결국 감각-두뇌-기억-행동의 루프를 돌린다. 차이는 각 구성요소의 깊이와 연결 방식에 있다.
이제 하나씩 설계해보자.
9.3 감각 설계 — Agent의 눈과 귀를 만든다
Agent의 감각은 곧 데이터 입력이다.
사람의 눈이 좋으면 세상이 더 잘 보이듯, Agent의 감각이 풍부하면 판단이 더 정확해진다. 그러나 모든 데이터를 다 넣으면 좋은 것은 아니다. 정보 과잉은 사람에게도 Agent에게도 독이다. 좋은 감각 설계는 무엇을 볼 것인가를 정하는 일이다.
개인 Agent가 받아들일 수 있는 감각 채널을 정리해보면 크게 다섯 가지다.
시간 데이터. 캘린더, 일정, 마감, 반복 루틴. 구글 캘린더 API, 아웃룩 API 등으로 연결한다. 이것은 가장 기본이면서 가장 중요한 감각이다. Agent가 "지금 사용자가 뭘 하고 있는가"를 알 수 있는 유일한 채널이기 때문이다.
소통 데이터. 이메일, 메시지, 슬랙, 카카오톡. 누구와 무슨 이야기를 했는지, 어떤 요청이 들어왔는지, 어떤 답장을 해야 하는지. 이 데이터가 풍부하면 Agent는 관계의 맥락까지 파악할 수 있다.
정보 데이터. 뉴스 피드, RSS, 구독 중인 뉴스레터, 즐겨찾기한 기사. 사용자의 관심사가 어디에 있는지를 보여준다.
건강 데이터. 스마트워치의 심박수, 수면 시간, 걸음 수, 운동 기록. 애플 헬스킷, 삼성 헬스, 핏빗 API 등으로 연결한다. 사용자의 신체 상태를 알면 일정 추천의 질이 달라진다.
자산 데이터. 계좌 잔고, 카드 결제 내역, 투자 포트폴리오. 가장 민감한 데이터다. 연결할 수 있다면 강력하지만, 보안과 프라이버시의 문제가 크다.
여기서 중요한 원칙이 하나 있다. 처음부터 다섯 채널을 다 열지 마라. 하나부터 시작한다. 가장 추천하는 출발점은 시간 데이터다. 캘린더 하나만 연결해도 Agent는 놀랄 만큼 많은 것을 할 수 있다. "오늘 오후 회의 전에 관련 자료를 정리해두겠습니다", "내일 빈 시간이 두 시간 있으니 밀린 보고서를 쓸 수 있습니다". 이 정도만 해도 유용하다.
한국에서 감각 설계가 특히 어려운 이유가 하나 있다. 카카오톡이다. 한국인의 소통은 카카오톡으로 흐른다. 그런데 카카오톡은 공식 API를 개인 개발자에게 열어주지 않는다. 슬랙이나 텔레그램은 API가 열려 있어서 Agent 연결이 쉽다. 카카오톡은 아니다. 이것은 한국에서 개인 Agent를 만들 때 마주치는 가장 현실적인 벽 중 하나다. 우회 방법이 아예 없지는 않지만, 깔끔하지 않다. 이 문제는 10장에서 다시 다룬다.
잠시 멈추고 생각해보자
당신의 하루를 데이터로 바꾼다면, 어떤 데이터가 가장 많을 것 같은가? 그 데이터 중 Agent에게 보여주고 싶은 것과 보여주고 싶지 않은 것의 경계는 어디인가?
9.4 두뇌 설계 — 어떤 LLM을 선택할 것인가
감각이 데이터를 모았다. 이제 그것을 처리할 두뇌가 필요하다.
2026년 현재, Agent의 두뇌는 거의 예외 없이 LLM이다. 선택지는 크게 세 갈래로 나뉜다.
첫째, 클라우드 상용 모델. OpenAI의 GPT-4o, 앤트로픽의 Claude, 구글의 제미나이. 성능이 가장 높다. 설치할 것도 없다. API 키 하나면 바로 쓴다. 대신 데이터가 외부 서버로 나간다. 비용도 호출량에 비례한다. 많이 쓰면 많이 낸다.
둘째, 오픈소스 모델. 알리바바의 Qwen3, 메타의 Llama, 미스트랄. 내 컴퓨터나 내 서버에서 돌릴 수 있다. 데이터가 밖으로 나가지 않는다. 비용도 서버 유지비뿐이다. 대신 성능은 상용 모델보다 한 단계 아래인 경우가 많다. 그리고 처음 설치가 좀 번거롭다.
셋째, 하이브리드. 민감하지 않은 작업은 클라우드 상용 모델에게, 민감한 작업은 로컬 오픈소스 모델에게 맡긴다. 현실적으로 가장 합리적인 선택이다.
내가 나의 시스템 — 반도체·AI 글로벌 밸류체인 분석·정보 제공 플랫폼 — 에서 택한 방식이 바로 하이브리드다. 기업 정보 분석처럼 빠른 추론이 필요한 작업에는 GPT-4o나 Claude를 쓴다. 개인 데이터를 다루거나 내부 지식을 처리할 때는 Qwen3를 RunPod 위에서 돌린다. 두 모델이 하나의 시스템 안에서 공존한다. 이것이 가능한 이유는 LangGraph 때문이다. LangGraph는 여러 모델을 하나의 흐름으로 엮어주는 오케스트레이션 도구다. 이것은 9.6절에서 더 자세히 다룬다.
두뇌를 선택할 때 고려해야 할 기준은 네 가지다.
성능. 복잡한 추론, 긴 맥락 이해, 정확한 응답. 이것이 가장 직관적인 기준이다. 그러나 성능만 보면 안 된다.
비용. API 호출 비용은 쌓인다. 하루에 백 번 호출하면, 한 달이면 삼천 번이다. GPT-4o 기준으로 월 몇만 원에서 수십만 원까지 나갈 수 있다. 개인이 쓰기에 부담이 될 수 있다.
프라이버시. 내 건강 데이터, 자산 데이터, 개인 대화를 외부 서버에 보내도 괜찮은가. 이 질문에 "아니오"라면 로컬 모델이나 하이브리드를 택해야 한다.
지연 시간. Agent가 응답하는 데 5초가 걸리면 짜증이 난다. 0.5초면 자연스럽다. 클라우드 모델은 네트워크 지연이 있고, 로컬 모델은 하드웨어 성능에 달려 있다.
내 경험상, 개인 Agent를 처음 만들 때는 클라우드 상용 모델로 시작하는 것이 좋다. 빠르게 프로토타입을 만들고, 실제로 써보고, 어디서 문제가 생기는지 확인한 다음에 최적화한다. 처음부터 오픈소스 모델 설치에 매달리면 Agent를 만들기도 전에 지친다. 나도 그랬다.
9.5 기억 설계 — Agent에게 과거를 준다
Agent와 챗봇의 가장 큰 차이는 기억이다.
챗봇은 대화가 끝나면 모든 것을 잊는다. 다음에 다시 시작하면 처음부터다. Agent는 다르다. 어제 무슨 이야기를 했는지 기억한다. 지난달에 어떤 결정을 내렸는지 안다. 사용자가 "그때 그 건" 하면 뭘 말하는지 알아듣는다. 이것이 가능하려면 기억 시스템이 필요하다.
기억은 두 종류로 나뉜다.
단기 기억(Short-term Memory). 지금 진행 중인 대화의 맥락이다. "아까 말한 그 보고서"에서 "그 보고서"가 무엇인지 아는 것. 대부분의 LLM은 컨텍스트 윈도우라는 형태로 단기 기억을 지원한다. GPT-4o는 약 12만 8천 토큰, Claude는 약 20만 토큰까지 한 번에 기억할 수 있다. 길다. 그러나 무한하지는 않다. 대화가 길어지면 앞부분을 잊기 시작한다.
장기 기억(Long-term Memory). 대화가 끝난 뒤에도 남아 있는 정보다. 사용자의 선호, 과거의 결정, 중요한 사건, 반복 패턴. 이것은 LLM 자체로는 안 된다. 별도의 저장소가 필요하다.
장기 기억을 구현하는 가장 보편적인 방법이 벡터 데이터베이스(Vector DB)다. 핵심 원리는 이렇다. 텍스트를 숫자 벡터로 바꾼다. 의미가 비슷한 텍스트는 비슷한 벡터를 갖는다. 그래서 "지난주 팀 회의에서 논의한 내용"이라고 검색하면, 정확히 "지난주 팀 회의"라는 단어가 없어도 관련된 기억을 찾아온다. 의미 기반 검색이다.
내가 쓰는 벡터 데이터베이스는 pgvector다. PostgreSQL의 확장 기능이다. 왜 이것을 택했는가. 세 가지 이유가 있다. 첫째, PostgreSQL은 이미 전 세계에서 가장 많이 쓰이는 관계형 데이터베이스 중 하나다. 안정성이 검증되었다. 둘째, 벡터 검색과 일반 SQL 검색을 하나의 데이터베이스에서 동시에 할 수 있다. "2024년 10월에 저장된 기억 중 '예산'과 의미가 비슷한 것"이라는 복합 쿼리가 가능하다. 셋째, 별도의 벡터 전용 데이터베이스를 운영하지 않아도 된다. 운영 부담이 줄어든다.
물론 pgvector만이 답은 아니다. Pinecone, Weaviate, Chroma, Milvus 같은 전용 벡터 데이터베이스도 있다. 각각 장단점이 다르다. 그러나 개인 Agent를 처음 만드는 단계에서는 pgvector가 가장 실용적이라는 것이 내 판단이다.
기억 설계에서 가장 중요한 것은 무엇을 기억할 것인가를 정하는 일이다. 모든 대화를 다 저장하면 기억이 너무 많아진다. 검색이 느려지고, 불필요한 정보가 섞인다. 반대로 너무 적게 저장하면 Agent가 맥락을 놓친다.
좋은 기억 전략은 세 가지 층위를 갖는다. 사실 기억 — 사용자가 명시적으로 말한 정보. "나는 매주 화요일에 요가를 한다." 선호 기억 — 사용자의 패턴에서 추론한 정보. "이 사용자는 아침보다 오후에 긴 글을 읽는 경향이 있다." 에피소드 기억 — 특정 사건의 맥락. "2025년 3월에 이직을 고민했다." 이 세 층위를 구분해서 저장하면 Agent의 기억이 훨씬 정교해진다.
잠시 멈추고 생각해보자
만약 당신의 Agent가 지난 1년간의 모든 대화를 기억하고 있다면, 그것은 편리한가 불편한가? 기억의 삭제 권한은 누구에게 있어야 하는가?
9.6 행동 설계와 오케스트레이션 — Agent가 세상에 손을 뻗는다
감각으로 데이터를 모으고, 두뇌로 판단하고, 기억에서 맥락을 꺼냈다. 이제 행동할 차례다.
Agent의 행동은 크게 네 가지로 나뉜다.
정보 전달. 분석 결과를 사용자에게 보여주기, 요약 제공, 알림 보내기. 가장 기본적인 행동이다.
외부 시스템 호출. API를 통해 다른 서비스를 작동시키기. 캘린더에 일정 추가, 이메일 발송, 슬랙 메시지 전송, 파일 저장. 이것이 Agent를 단순한 챗봇과 구분하는 핵심이다.
자동화. 특정 조건이 충족되면 미리 정해진 행동을 실행하기. "매일 아침 8시에 오늘의 일정과 날씨를 정리해서 보내기", "미답장 이메일이 24시간 지나면 알려주기". 사용자가 명령하지 않아도 작동하는 행동이다.
의사결정 보조. 선택지를 정리하고, 장단점을 분석하고, 추천을 제시하기. 가장 고수준의 행동이다. 그러나 최종 결정은 사용자에게 남겨둬야 한다. Agent가 혼자 결정하는 순간 신뢰가 깨진다.
행동 설계에서 핵심 원칙은 도구(Tool) 기반 설계다. Agent에게 "이메일을 보내라"고 시키는 것이 아니라, "이메일 보내기 도구를 쓸 수 있다"고 알려주는 것이다. Agent는 상황에 따라 어떤 도구를 쓸지 스스로 판단한다. LangGraph나 LangChain 같은 프레임워크가 이 구조를 지원한다.
여기서 질문이 하나 더 생긴다. Agent가 하나일 필요가 있는가.
답은 "아니다"이다. 실제로 잘 작동하는 시스템은 대부분 멀티 에이전트(Multi-Agent) 구조다. 시간 관리 Agent, 정보 정리 Agent, 건강 추적 Agent가 각각 따로 있고, 이들을 총괄하는 조율 Agent(Orchestrator)가 위에 앉는다.
왜 이렇게 나누는가. 두 가지 이유다.
첫째, 단일 Agent에게 모든 것을 맡기면 프롬프트가 너무 길어진다. "너는 시간도 관리하고 건강도 추적하고 자산도 분석하고 뉴스도 정리하는 Agent야." 이렇게 쓰면 Agent는 다 어중간하게 한다. 각 영역에 전문화된 Agent를 따로 만들면 각각의 품질이 올라간다.
둘째, 유지보수가 쉬워진다. 건강 Agent를 고칠 때 시간 Agent는 건드리지 않아도 된다. 새 영역이 필요하면 새 Agent를 추가하면 된다. 소프트웨어 공학에서 말하는 모듈화의 원칙이 그대로 적용된다.
나의 시스템에서 내가 설계한 아키텍처도 이 구조다. Article Lingua(학습), SAF(자산 분석), KVIC(기업 정보)가 각각 독립된 Agent다. 이들은 LangGraph의 그래프 구조 위에서 각자의 노드로 작동하고, 필요할 때 서로 데이터를 주고받는다. 하나의 거대한 Agent가 아니라 여러 전문 Agent의 협업이다. 마치 한 팀의 전문가들이 각자의 역할을 하면서 함께 일하는 것과 같다.
오케스트레이션의 핵심은 흐름 제어다. 어떤 Agent가 먼저 작동하고, 그 결과를 어떤 Agent에게 넘기고, 어디서 사용자의 승인을 받고, 어디서 자동으로 진행하는가. 이 흐름을 설계하는 것이 아키텍처의 마지막 퍼즐이다.
LangGraph가 이 역할을 한다. LangGraph는 Agent의 작업 흐름을 방향 그래프(Directed Graph)로 표현한다. 각 노드는 하나의 작업이고, 엣지는 작업 간의 흐름이다. 조건부 분기도 가능하다. "사용자가 승인하면 이쪽으로, 거부하면 저쪽으로." 이런 흐름을 코드로 명확하게 정의할 수 있다.
잠시 멈추고 생각해보자
당신의 일상에서 Agent에게 맡기고 싶은 행동은 무엇인가? 그중 Agent가 혼자 결정해도 되는 행동과 반드시 당신의 승인이 필요한 행동은 어떻게 구분되는가?
9.7 처음부터 완벽할 필요는 없다
지금까지 감각, 두뇌, 기억, 행동, 오케스트레이션을 봤다. 다섯 가지나 되니 벅차게 느낄 수 있다. 그러나 한 가지만 기억하면 된다. 처음부터 다 만들 필요 없다.
좋은 Agent는 한 번에 완성되지 않는다. 점진적으로 자란다.
내가 권하는 방법은 이렇다.
1단계. 감각 하나, 두뇌 하나, 행동 하나. 캘린더 데이터를 읽어서(감각), GPT-4o가 오늘의 일정을 정리하고(두뇌), 아침마다 요약을 보내준다(행동). 기억은 아직 없다. 이것만으로도 쓸 만하다.
2단계. 기억을 추가한다. pgvector를 연결해서 대화 내역과 사용자 선호를 저장한다. Agent가 "지난주에도 비슷한 일정이 겹쳤는데, 그때는 오후 회의를 옮겼죠"라고 말할 수 있게 된다. 이 순간부터 Agent가 분신처럼 느껴지기 시작한다.
3단계. 감각을 늘린다. 이메일을 연결한다. 건강 데이터를 연결한다. Agent가 아는 것이 많아지면 판단의 질이 올라간다.
4단계. 행동을 늘린다. 일정 추가, 이메일 초안 작성, 리마인더 설정. Agent가 할 수 있는 일이 늘어난다.
5단계. 멀티 에이전트로 확장한다. 영역별 전문 Agent를 만들고 오케스트레이터로 엮는다.
이 다섯 단계를 한 달 안에 다 할 필요 없다. 1단계만 해도 충분히 유용하다. 그리고 1단계를 써보면서 "여기에 기억이 있으면 좋겠다", "여기에 이메일도 연결하면 좋겠다"는 생각이 자연스럽게 든다. 그때 다음 단계로 넘어간다. 이것이 점진적 구축이다.
금융·제조 기업의 시스템과 AI/ML 솔루션을 봐온 사람으로서 한 가지 확신이 있다. 처음부터 완벽한 시스템을 만들려는 시도는 거의 예외 없이 실패한다. 작게 시작해서, 써보고, 고치고, 늘리는 시스템만이 살아남는다. Agent도 다르지 않다.
다음 장에서 실제로 만든다. 10장에서는 LangGraph, pgvector, 오픈소스 LLM이라는 구체적인 기술 스택을 잡고, 코드 수준에서 첫 Agent를 설계한다. 이 장에서 그린 아키텍처가 실제 코드로 바뀌는 순간이다.
핵심 정리
개인 Agent는 비서가 아니라 분신이다. 비서는 시키는 일만 하지만, 분신은 나를 알고 스스로 판단한다. 분신을 만들려면 아키텍처가 필요하다.
Agent의 아키텍처는 네 가지 구성요소로 이루어진다. 감각(데이터 입력), 두뇌(LLM), 기억(벡터 데이터베이스), 행동(API 호출과 자동화). 이 네 가지의 조합이 Agent의 능력을 결정한다.
감각 설계는 무엇을 볼 것인가를 정하는 일이다. 시간, 소통, 정보, 건강, 자산 데이터 중 하나부터 시작한다. 캘린더가 가장 좋은 출발점이다.
두뇌 설계는 어떤 LLM을 쓸 것인가를 정하는 일이다. 클라우드 상용 모델, 오픈소스 모델, 하이브리드 중 선택한다. 처음에는 클라우드 모델로 빠르게 시작하는 것이 합리적이다.
기억 설계는 Agent에게 과거를 주는 일이다. 단기 기억은 LLM의 컨텍스트 윈도우가, 장기 기억은 pgvector 같은 벡터 데이터베이스가 담당한다. 무엇을 기억할 것인가를 정하는 것이 가장 중요하다.
행동 설계와 오케스트레이션은 Agent가 세상에 손을 뻗고, 여러 Agent가 협업하는 구조를 만드는 일이다. LangGraph 같은 프레임워크가 이 흐름을 제어한다.
처음부터 완벽할 필요 없다. 감각 하나, 두뇌 하나, 행동 하나로 시작해서 점진적으로 키운다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신이 만들고 싶은 개인 Agent는 비서에 가까운가, 분신에 가까운가? 분신이 되려면 Agent가 당신에 대해 무엇을 알아야 하는가?
질문 2. 감각 채널 다섯 가지(시간, 소통, 정보, 건강, 자산) 중 당신의 Agent에게 가장 먼저 열어줄 채널은 무엇인가? 그 이유는 무엇인가?
질문 3. 두뇌를 선택할 때 성능, 비용, 프라이버시, 지연 시간 중 당신에게 가장 중요한 기준은 무엇인가? 그 기준에 따르면 어떤 모델을 선택하게 되는가?
질문 4. Agent의 기억에서 삭제 권한은 누구에게 있어야 하는가? 사용자가 "이건 잊어줘"라고 하면 Agent는 정말 잊어야 하는가, 아니면 "잊은 척"만 하면 되는가?
질문 5. 멀티 에이전트 구조에서 Agent끼리 정보를 공유할 때, 건강 Agent가 수집한 데이터를 자산 Agent가 볼 수 있어야 하는가? 그 경계는 어떻게 정해야 하는가?
더 깊이 탐구하기
Harrison Chase 외, 「LangGraph Documentation」 (2024~2026). 멀티 에이전트 오케스트레이션의 실무 표준이 되어가는 프레임워크의 공식 문서.
Lilian Weng, 「LLM Powered Autonomous Agents」 (2023). OpenAI 연구자가 정리한 Agent 아키텍처의 개론. 감각-두뇌-기억-행동 프레임워크를 학술적으로 정리한 글이다.
Andrew Ng, 「Agentic AI Design Patterns」 강연 시리즈 (2024~2025). Agent 설계의 네 가지 패턴(반성, 도구 사용, 계획, 멀티 에이전트)을 명쾌하게 정리한다.
pgvector 공식 문서 및 Supabase Vector 가이드 (2025). PostgreSQL 기반 벡터 검색의 실무 가이드. 개인 Agent의 장기 기억을 직접 구현할 때 가장 먼저 볼 자료다.
나의 시스템 Composite AI Framework 백서 (2025). LangGraph와 pgvector를 활용한 멀티 에이전트 아키텍처의 실무 설계 사례.
다음 장에서는 기술 스택으로 들어간다. LangGraph, pgvector, 오픈소스 LLM. 이 세 가지 도구가 무엇이고, 왜 이것들을 선택했으며, 어떻게 조합하는지를 구체적으로 본다. 아키텍처가 코드가 되는 순간이다.