에이전트 프레임워크의 기본 아이디어

한 줄 요약: 에이전트 = 생각하는 두뇌(대규모 모델) + 손발이 되는 몸(도구와 환경). 에이전트 프레임워크는 이 "두뇌"에 "몸"을 달아 주는 비계입니다. 도구, 권한, 메모리, 멀티 에이전트 협업 같은 잡일을 모두 떠맡아 주므로, 개발자는 "에이전트가 무엇을 해야 할지 제대로 생각하게 만드는 일"에만 신경 쓰면 됩니다.

---

1. 에이전트는 어떻게 동작하는가?

모든 에이전트(아무리 복잡하더라도)는 단순한 루프 위에서 돌아갑니다:

인지(무엇이 보이는가) → 사고(무엇을 할지 결정) → 행동(직접 실행) → 결과 관찰 → 다시 사고 → …

예를 들어 "항공권 예약 어시스턴트"를 생각해 봅시다:

1. 인지: "다음 주 수요일에 상하이행 항공권을 예약해 줘"라는 지시를 받음
2. 사고: 항공편 조회, 가격 비교, 예약이 필요함
3. 행동: 항공편 조회 도구 호출, 예약 도구 호출
4. 관찰: "발권 성공, ¥880"이라는 결과를 확인
5. 다시 사고: 더 저렴한 선택지를 사용자에게 알려 줄까?

이 루프 자체는 단순합니다. 어려운 것은 "행동" 단계를 실제로 일어나게 하면서도 안전하고 제어 가능하게 만드는 일입니다.

---

2. 대규모 모델은 "두뇌"일 뿐, "몸"이 필요하다

대규모 모델(LLM) 자체가 할 수 있는 일은 단 하나입니다: 입력된 텍스트를 바탕으로 출력 텍스트를 생성하는 것.

실제로 다음 일들은 하지 못합니다:

• ❌ HTTP 요청 전송하기
• ❌ 파일 읽기/쓰기
• ❌ 데이터베이스 조작
• ❌ 이전 대화 이외의 것을 기억하기

대규모 모델을 "움직이게" 하려면 도구를 연결해 줘야 합니다. 이 "도구 연결" 과정이 바로 에이전트 프레임워크의 핵심 작업입니다.

비유: 레고

대규모 모델은 가장 뛰어난 레고 부품 더미입니다(이해하고 추론할 수 있음). 에이전트 프레임워크는 설명서 + 수납 상자입니다. 설명서는 부품을 조립하는 방법을 알려 주고(워크플로), 수납 상자는 분류와 보관을 담당합니다(도구 관리, 권한, 메모리). 설명서와 수납 상자가 없다면, 부품이 아무리 뛰어나도 바닥에 흩어진 블록에 불과합니다.

---

3. 프레임워크는 도대체 무엇을 관리하는가?

완전한 에이전트 프레임워크는 보통 다음 문제들을 해결해야 합니다:

하나씩 살펴 보겠습니다:

3.1 도구는 어떻게 제공하는가(Tool Calling)

프레임워크는 각 도구를 "설명서" 형태로 대규모 모델에게 보여 줍니다:

{
  "name": "get_weather",
  "description": "查询某个城市的天气",
  "parameters": {
    "city": { "type": "string", "description": "城市名，例如 北京" }
  }
}

설명서를 본 대규모 모델은 "get_weather를 city=베이징 파라미터로 호출하겠다"고 말합니다. 프레임워크는 이 호출을 실제로 실행하고 결과를 대규모 모델에게 돌려주는 책임을 집니다. 이 과정 전체에서 개발자는 도구를 등록하기만 하면 되고, 대규모 모델에게 사용법을 가르칠 필요가 없습니다.

3.2 무엇을 만질 수 있는가(권한과 샌드박스)

에이전트는 신뢰할 수 없는 걸까요? 그렇지는 않습니다. 하지만 능력의 경계는 명확해야 합니다. 프레임워크가 제공하는 것:

• 권한 선언: 이 에이전트는 /data 디렉터리만 읽을 수 있고 시스템 파일에는 쓸 수 없음
• 샌드박스: 격리된 환경에 가두어, "폭주"하더라도 바깥 세상에 영향을 주지 못하게 함

3.3 기억할 수 있는가(메모리와 컨텍스트)

대규모 모델은 대화할 때마다 "기억 상실" 상태가 됩니다. 프레임워크의 역할:

• 단기: 여러 턴의 대화를 컨텍스트로 정리
• 장기: 중요한 정보를 데이터베이스/벡터 스토어에 저장해 다음에도 떠올릴 수 있게 함

3.4 혼자서 감당되는가(멀티 에이전트)

하나의 작업을 여러 에이전트에 나누어 협업시킬 수 있습니다: 하나는 조사, 하나는 코드 작성, 하나는 리뷰를 담당합니다. 프레임워크는 이들을 오케스트레이션하고, 누가 먼저이고 누가 나중인지, 결과를 어떻게 취합할지 결정합니다.

3.5 세계와 어떻게 연결하는가(MCP 등 프로토콜)

서로 다른 시스템 간의 연결에는 표준 프로토콜이 필요합니다(예: MCP — Model Context Protocol, 모델 컨텍스트 프로토콜). 프레임워크는 이러한 프로토콜을 구현하여, 에이전트가 외부 도구와 "플러그 앤 플레이"로 연결되게 합니다.

---

4. 구체적인 예: "날씨 도우미" 만들기

프레임워크 없이는 이렇게 작성해야 할 것입니다:

// 의사 코드: 프레임워크가 없는 세계
const text = "北京天气怎么样";
const intent = llm.analyze(text);           // 모델이 의도를 파악하게 함
if (intent.action === "query_weather") {
  const data = await fetch(`/api/weather?city=${intent.city}`);
  const answer = llm.generate(data, text);   // 결과를 자연스러운 문장으로 정리
  return answer;
}

프레임워크를 사용하면(DSH/Cordis 스타일로 예시):

// 의사 코드: 프레임워크가 있는 세계
ctx.set('weather', weatherApi);      // 도구 등록(사이드 이펙트 공급)

// "날씨 플러그인"을 컴포넌트로 등록
ctx.use({
  inject: ['weather'],               // 날씨 서비스가 필요하다고 선언
  apply(ctx) {
    ctx.commands.register('天气 <city>', async (city) => {
      const data = await ctx.weather.query(city);   // 바로 사용
      return `☀️ ${city} 今天 ${data.condition}`;
    });
  },
});

차이점은 무엇일까요?

• 프레임워크 없음: 모든 단계를 직접 손으로 작성해야 하고, 도구가 많아지면 금방 엉망이 됨
• 프레임워크 있음: "무엇이 필요하고 무엇을 제공하는지"만 선언하면, 연결, 스케줄링, 정리는 프레임워크가 담당

---

5. "어시스턴트"에서 "자기 진화"로

전통적인 에이전트 프레임워크에서 컴포넌트는 개발 시점에 하드코딩되고 실행 중에는 변하지 않습니다.

하지만 미래에는(이 논문의 핵심 동기 중 하나이기도 합니다) 에이전트가 이렇게 동작할 것입니다:

1. 에이전트가 자신에게 특정 도구가 없다는 것을 발견
2. 새 도구를 스스로 작성(또는 다른 에이전트에게 작성시킴)
3. 새 도구를 실행 중인 프레임워크에 동적으로 설치
4. 한동안 사용해 보고 별로라고 판단되면 동적으로 제거하고 더 나은 것으로 교체

이것이 "자기 진화 에이전트"입니다: 실행 중인 시스템이 스스로를 수정하는 것.

멋지게 들리지만 위험하기도 합니다. 설치한 것을 제거할 수 없거나, 제거하다가 다른 것을 망가뜨리면 시스템이 다울됩니다. 이 문제를 해결하려면 제1장 제3절의 주제인 동적 컴포지션이 필요합니다.

---

핵심 요점 정리

• 에이전트 = 인지 → 사고 → 행동의 루프
• 대규모 모델은 "두뇌"일 뿐이며, "몸"을 달아 주는 것은 프레임워크의 책임
• 프레임워크의 5대 책임: 도구, 권한, 메모리, 오케스트레이션, 연결
• 미래의 에이전트는 자기 컴포넌트를 스스로 수정 → "동적 컴포지션"에 의존해야 함

🚀 다음 섹션: "왜 동적 컴포지션이 필요한가" — 지금의 소프트웨어가 왜 "재시작 없이 장착하고 분리하는 것"을 할 수 없는지, 그리고 그것이 얼마나 중요한지 살펴 봅니다.