코드 자동화를 위한 설계 - 에이전트 이해하기

Posted Mar 15, 2026 Updated Mar 23, 2026

By ogongchill

37 min read

Barlow Automation

0. 들어가며

Slack 슬래시 커맨드로 개발자가 기능/리팩토링/버그 요청을 입력하면, AI가 GitHub 코드를 분석해 GitHub 이슈 초안을 자동 생성하는 시스템을 구축하고자 한다.

현재 상당히 거지이므로 최대한 비용 효율적이며 관리하기 용이한 Github Issue 자동화 워크플로우를 구축한는 것을 목표로 시작하였다. 그러나 진행할수록 여러 무엇을 어떻게 만들어야 할지에 관한 방향성을 확실하게 잡지 못한 상태로 프로젝트의 진행이 모처럼 되지 않았다. LLM 과 Agent 그리고 이를 지원하는 여러 소프트웨어 생태에 관한 이해 없이 무작정 시작했기 때문이다.

현재 프로젝트의 방향성을 보다 명확히 하고, 설계를 확실하게 하기 위해 글을 통해 정리하고자 한다.

1. LLM Agent 생태는 지금…

1.1 MCP의 태동

초기의 LLM은 텍스트를 생성하는 데는 뛰어났지만, 바깥 세계와 연결되는 방식은 제각각이었다. 어떤 서비스는 자체 function calling을 만들고, 어떤 서비스는 별도의 connector를 붙였고, 어떤 개발팀은 GitHub나 파일 시스템, 데이터베이스와 연결하기 위해 매번 다른 방식을 사용해야 했다.

Anthropic은 2024년 11월 25일, MCP를 오픈 표준으로 소개하며 개발자가 MCP 서버를 통해 데이터를 노출하거나, 반대로 MCP 클라이언트를 만들어 서버에 연결할 수 있게 해준다고 설명했다.

MCP는 이 문제를 해결합니다. 이는 AI 시스템을 데이터 소스와 연결하는 보편적이고 개방적인 표준을 제공하여 단편화된 통합을 단일 프로토콜로 대체합니다. 그 결과 AI 시스템이 필요한 데이터에 액세스할 수 있는 더 간단하고 신뢰할 수 있는 방법이 탄생했습니다.
Introducing the Model Context Protocol

2025년 5월, OpenAI는 Responses API에 remote MCP server 지원을 추가했고, 동시에 MCP steering committee에 참여하며 사실상 공통 규약으로 자리잡았다.

1.2 표준화 움직임

다시 우리의 목표로 돌아가보자. 우리가 원하는 것은 LLM Agent의 자동화 워크플로우다. 단순히 LLM이 외부와 통신하는 방식을 제어하는 것이 아니라 더 높은 추상화의 단계에서 이를 정의하고 쉽게 사용하고 싶다. 그게 AI를 사용하는 가장 큰 이유이니까.

언젠가 MCP처럼 에이전트 자체도 표준이 나올 수 있나? 현재 그런 움직임이 있을까?

현재 모든 에이전트를 아우르는 단일 공통 규약이 존재하지는 않지만 레이어별 표준로 나뉘어 생기는 흐름이 존재한다.

1. 도구 연결 표준: MCP

에이전트가 외부 도구와 문맥에 접근하는 방법을 표준화

2. 에이전트 간 통신 표준: A2A (Agent2Agent)

에이전트들이 서로 통신하고, 정보를 안전하게 교환하고, 작업을 조정할 수 있게 하는 프로토콜
“에이전트 자체 표준”이라기보다, 에이전트 ↔ 에이전트 상호운용 표준에 가깝움

3. 에이전트 발견·신원·메시징·관측성 표준: AGNTCY

discovery(에이전트 찾기), identity(신원/검증), messaging(통신), observability(모니터링) 을 바탕으로 한 운영 인프라 스택

4. 프로젝트별 에이전트 행동 힌트 표준: [AGENTS.md]((https://openai.com/ko-KR/index/agentic-ai-foundation)

AGENTS.md를 저장소 내에서 AI coding agents가 일관된 프로젝트별 지침을 읽기 위한 가벼운 Markdown 규약
repo 안에서 agent behavior를 예측 가능하게 만드는 문서

아직은 정글같은 생태계 그러나 MCP는 사실상 공통 규약으로 자리잡았으나, A2A나 그 밖의 규약은 아직 그런 수준까지 갔다고 보긴 어렵다. A2A는 이제 막 Linux Foundation 산하에서 v1.0 stable로 나온 단계이며 다른 표준도 이제 시작하는 단계이다.

1.3 라이브러리/프레임워크 지원

공통 규약이 성립되고 발전되는 현재 흐름 속에서도 아직까지 AI Agent와 관련된 기능들은 LLM Provider 종속적이다.

따라서 가장 쉬운 방법은 해당 LLM 제공사가 공식적으로 지원하는 라이브러리를 사용하는 것이다. Openai모델을 사용하기 위해서는 Openai agent sdk를, Claude Code기반은 anthropic agent sdk, Google의 모델은 Google ADK를 사용하는 것이 가장 직관적이고 편할 것이다. 그러나 시스템이 이에 종속적이게 되겠지.

LangChain, LangGraph와 같은 model-agnostic 프레임워크는 특정 LLM provider에 직접 종속되지 않고, 여러 모델을 비교적 일관된 방식으로 연결하고 오케스트레이션할 수 있게 해준다는 점에서 매력적이다. LLM 모델 교체, 추상화된 워크플로우 설계, 상태 기반 에이전트 흐름 구성 측면에서는 실용적인 선택지가 될 수 있다.

그러나 이러한 접근에도 분명한 한계가 있다. 가장 큰 단점은 LLM provider가 새롭게 출시하는 최신 모델이나 고유 기능을 즉시 활용하기 어렵다는 점이다. LLM Provider가 제공하는 라이브러리는 새로운 기능이 가장 먼저 반영되지만, 범용 프레임워크는 이를 추상화 계층 안에 편입시키는 데 시간이 걸릴 수밖에 없다. 또한 프레임워크 자체의 개념과 사용법을 별도로 익혀야 하므로, SDK 학습과는 또 다른 러닝 커브가 발생한다.

1.4 결론

LLM 및 agentic system 개발은 당분간 벤더 종속성이 클 수밖에 없는 구조에 놓여 있다고 볼 수 있다
개발자는 각 벤더가 제공하는 SDK와 프레임워크, 그리고 그 사이를 잇는 추상화 계층 사이에서 현실적인 균형점을 직접 선택해야 하는 상황

2. Agent 이해하기

2.1 Agent란 무엇인가

AI Agent라는 단어를 들었을 때, 우리는 과연 무엇을 떠올리게 될까.

어떤 사람은 Claude Code의 subagent처럼 특정 역할을 분담받아 협업하는 코딩 에이전트를 생각할 수 있고, 다른 사람은 사용자 질문에 답하는 AI 챗봇을 agent라고 부를 수 있다. 또 어떤 사람은 Google Assistant와 같은 음성 기반 개인 비서형 시스템을 연상할 수도 있다. 이들은 모두 어느 정도 자율성과 상호작용성을 가진다는 점에서는 비슷하지만, 실제 구조와 동작 방식, 그리고 기대되는 책임 범위는 상당히 다르다. Claude Code의 subagent는 독립된 컨텍스트와 권한을 가진 전문화된 보조 에이전트로 설명되며, OpenAI는 agents를 단순한 목표부터 복잡하고 개방적인 워크플로우까지 수행하는 시스템으로 넓게 정의한다.

그렇다면 Git Issue 생성 자동화 시스템에서 말하는 agent는 무엇을 의미하는가. 이는 단순히 LLM을 호출하고 tool calling을 수행하는 실행 단위인가, 아니면 Claude Code의 subagent처럼 특정 역할을 맡아 다른 구성 요소와 협업하는 주체인가. 더 나아가 여러 agent의 조합으로 이루어진 자동화 워크플로우 전체까지도 agent라고 볼 수 있는가.

에이전트란 무엇인가

문제는 바로 여기에 있다. 오늘날 agent라는 용어는 넓고 모호하게 사용되며, 비슷한 개념을 가리키는 듯 보이지만 실제로는 서로 다른 수준의 자율성, 제어 방식, 책임 범위를 전제하는 경우가 많다. 실제로 OpenAI는 agent를 넓은 실행 시스템으로 설명하는 반면, Anthropic은 workflow와 agent를 중요한 두 아키텍처로 구분하고, Google ADK는 이를 LlmAgent, Workflow Agent, Custom Agent처럼 프레임워크 차원에서 구조화한다.

따라서 시스템 설계에 앞서 먼저 정리해야 할 것은 기능 목록이 아니라 정의다. 즉, 우리 맥락에서 agent는 무엇이며, workflow와는 어떻게 구분되는가를 분명히 해야 한다. 이 경계가 명확해져야만 역할 분리, 오케스트레이션 방식, 실패 처리, 승인 절차, 관측 가능성, 책임 범위까지 일관된 기준 위에서 논의할 수 있다.

본 글에서는 agent를 사용자 입력과 문맥을 바탕으로 LLM이 추론을 수행하고, 필요 시 tool 또는 function calling을 통해 외부 자원과 상호작용하며, 그 결과를 반영해 다음 행동과 응답을 생성하는 주체로 정의한다. 이러한 agent는 시스템 내에서 LLM의 자율적 판단이 개입되는 최소 실행 단위로 본다. 이 정의에서 agent는 전체 workflow나 시스템 수준의 오케스트레이션과는 구별되며, 사전에 고정된 절차에 따라 수행되는 deterministic한 작업과도 분리된다. 즉, 본 글이 다루는 agent는 Anthropic이 설명하는 LLM agent의 개념에 가까우며, 자율적 판단과 도구 사용 가능성을 핵심 속성으로 갖는 단위라고 볼 수 있다.

2.2 Idempotent Agent?

우리가 직접 Agent를 개발할 일은 거의 없을 것이다. agent내부 동작을 구현하고, tool calling 기능을 만들고, turn을 관리 하는 등의 agent 내부 레벨의 기능은 우리의 관심사가 아니다.

이는 현재 llm provider에서 직접 제공하고 있으며 agent내부의 deterministic한 기능들은 llm provider가 내부 코드로 혹은 강한 프롬프트로 혹은 알지 못하는 어떤 것으로 제어하고 있을 것이다. 이를 제어하는 방식, 철학, 개념등은 조금식 다르나 분명 공통적인 부분도 존재한다.

가장 공통적인것

llm 호출 응답은 non-deterministic 하다
agent의 동작은 deterministic하게 강제할 수 있다(claude code의 hook, open ai 의 max turn, max token 등)

llm provider는 사용자가 agent의 동작을 제어할 수 있도록 여러 장치를 제공한다. 그렇다면 이를 어떻게 제어해야 가장 일관적이고, 예측 가능하며 똑똑하게 동작할 수 있을까?

Can AI Agents Exhibit Idempotency?

예를들어 이런 요청이 있다고 하자.

feat/ 사용자 로그인 기능 추가해줘

feat/ 사용자 로그인 기능 추가

위의 요청은 사실상 동일한 의미를 갖는다. LLM은 기본적으로 확률적이기에 Idempotent할 수 없다. 따라서 deterministic한 구조를 설계하여 최대한 LLM Agent가 Idempotent하게 동작하는 것을 목표로 해야 한다. 그럼 이것을 어떻게 구현할 수 있을까?

글에서는 4가지의 결정론적인 방식을 사용하여 LLM Agent를 최대한 Idempontent하게 사용하는 구조를 제시한다.

입력의 정규화 / canonicalization: Φ

자연어 입력의 다양한 표현을 시스템이 이해하는 하나의 표준 표현으로 바꾸는 것

예시 사용자 입력이 아래처럼 제각각 들어온다고 해보자.

- “회원가입 기능 이슈 만들어줘”
    
- “signup 관련 feature issue 생성”
    
- “카카오 로그인 회원가입 추가해야 함”
    
- `/feat signup`

이걸 그대로 policy layer가 받으면, 매번 해석이 달라질 수 있다.

그래서 먼저 이런 식으로 바꾼다.

  
{  
  "intent": "CREATE_ISSUE",  
  "issue_type": "FEAT",  
  "domain": "AUTH",  
  "target": "SIGNUP",  
  "provider": "KAKAO"  
}

여기서 하는 일

동의어 통합 - 회원가입 / signup / 가입 → SIGNUP
표현 통합 - 기능 추가 / feature / feat → FEAT
필요 시 slot 추출 - 카카오 → provider=KAKAO

raw text 다양성 → canonical form 하나

매핑의 결정론적 고정: π

canonicalized data가 들어오면 어떤 행동을 할지 규칙적으로 고정하는 것

예시 canonical input이 이렇게 나왔다고 하자.

  
{  
  "intent": "CREATE_ISSUE",  
  "issue_type": "FEAT",  
  "domain": "AUTH",  
  "target": "SIGNUP"  
}

그러면 정책은 이런 식으로 고정될 수 있다

정책 규칙 예시

- `intent=CREATE_ISSUE` 이면 무조건 issue generation flow로 간다.
- `issue_type=FEAT` 이면 FEAT 템플릿을 사용한다.
- `domain=AUTH` 이면 auth 관련 repo/path만 읽는다.
- 기존 유사 issue가 있으면 새 issue 생성 대신 중복 검토 단계로 보낸다.

agent가 매번
“이번엔 뭘 할까?”를 크게 고민하는 게 아니라

입력 상태 → 행동 규칙

이 매핑이 좁혀져 있기 때문에 항상 예측 가능하게 동작할 수 있다.

상태의 강제 투영: P

중간에 애매하거나 꼬인 상태가 생겨도 시스템 상태를 안정적인 상태로 다시 맞추는 것

예시 1: GitHub issue 생성 성공 여부가 애매한 경우

agent가 issue create API 호출
    
응답 timeout 발생
    
성공했는지 실패했는지 모름

이때 그냥 재시도하면 중복 issue가 생길 수 있음.

그래서 P를 적용한다:

현재 GitHub 상태를 다시 조회
동일한 canonical key를 가진 issue가 이미 있는지 확인
있으면 상태를 ISSUE_CREATED로 투영
없으면 상태를 READY_TO_RETRY로 투영

즉 내부적으로는 애매한 상태:

unknown
maybe_created
api_timeout

이런 걸 그대로 두지 않고, 안정적인 상태로 복귀한다.

CREATED
NOT_CREATED
NEEDS_REVIEW
RETRYABLE_FAILURE

예시 2: Slack 승인 버튼을 눌렀는데 세션 상태가 꼬인 경우

원래 상태머신이:

DRAFTED -> REVIEW_PENDING -> APPROVED -> CREATED

여야 하는데, 네트워크 문제로
승인은 되었는데 내부 DB엔 아직 REVIEW_PENDING으로 남아 있을 수 있음.

이때 projection은:

Slack action log 확인
GitHub issue 존재 여부 확인
내부 세션 상태를 실제 외부 상태에 맞춰 재설정

예:

GitHub에 issue 있으면 → CREATED
issue 없고 승인만 있으면 → APPROVED_WAITING_EXECUTION

피드백 루프와 corrective policy

실패했을 때 무작정 재시도하지 않고, 실패 원인에 맞는 교정 행동을 넣는 것

예시 1: issue 내용이 너무 모호하게 생성된 경우

초안이 이렇게 나왔다고 해보자.

회원가입 기능을 추가합니다.

이건 너무 빈약해서 바로 올리기 어려움.

그럼 corrective policy가 개입:

누락 필드 검사
acceptance criteria 없음 감지
관련 파일/도메인 맥락 부족 감지

그리고 재생성 프롬프트를 더 좁힌다:

대상: auth/signup
포함 필수:
- 목적
- 배경
- 작업 항목
- 완료 조건
불필요한 일반론 제거

즉 첫 출력이 부정확할 때
다음 출력 공간을 더 좁혀서 수렴시킴.

예시 2: repo 탐색 범위가 너무 넓어서 산만한 경우

처음 agent가 repo 전체를 뒤져서 엉뚱한 내용까지 읽었다고 하자.

그러면 corrective policy:

탐색 범위를 auth 관련 path로 제한
read budget 축소
search target 재설정

즉, “다시 해봐”가 아니라 “이번엔 src/auth, docs/auth, user-service만 봐”

처럼 더 좁혀주는 것.

예시 3: 중복 issue 생성 시도

사용자가 같은 요청을 다시 보냄.

“회원가입 기능 추가해줘”
나중에 또 “signup feature issue 만들어줘”

corrective policy는:

canonical key 비교
기존 open issue 검색
동일하면 새로 생성하지 않고
- 기존 issue 링크 반환
- 또는 comment 추가
- 또는 “이미 존재” 상태로 종료

이건 실패 복구이기도 하고 멱등성 유지이기도 하다.

Implementing on Claude Code ?

Φ 입력 canonicalization → skill / CLAUDE.md 규칙 / 입력 포맷 강제
π deterministic mapping → hooks + subagent 분리 + 명시적 규칙
P state projection → hook에서 외부 상태 조회 후 안정 상태로 재판정
feedback loop → 검증 hook + 실패 시 재프롬프트/재분기 정책

이런 식으로 Claude Code환경에서 적용해 볼 수도 있겠다.

3. Agentic System

앞으로 내용에서는 Agent와 Agentic System 혹은 workflow를 명확히 구분 할 것이다. 코드레벨에서 결정론적이게 통제되는것은 Agentic System(workflow)이고 LLM을 통해 응답이 non-deterministic 한 작업을 Agent(LLM Agent)라고 할 것이다.

3.1 Determinism

Agent 자체와 Agent를 활용하는 시스템 전체는 구분해서 볼 필요가 있다.

우리가 만들고자 하는 것은 예측 가능하고, 실패 시 복구 가능하며, 운영 가능한 시스템이다.
비록 내부에 예측 불가능한 LLM이 포함되더라도, 그 LLM을 감싸는 시스템 전체는 일관되고 통제 가능하게 동작해야 한다.

이 점에서 주요 프레임워크들은 공통적으로 결정론적인 부분과 비결정론적인 부분을 분리해 설명한다.

Anthropic은 이를 Agent와 Workflow로 구분한다.

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.
Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks. building-effective-agents

Google의 Agent ADK 역시 유사하게 이를 구분한다.

LLM Agents (LlmAgent, Agent): These agents utilize Large Language Models (LLMs) as their core engine to understand natural language, reason, plan, generate responses, and dynamically decide how to proceed or which tools to use, making them ideal for flexible, language-centric tasks.
Workflow Agents (SequentialAgent, ParallelAgent, LoopAgent): These specialized agents control the execution flow of other agents in predefined, deterministic patterns (sequence, parallel, or loop) without using an LLM for the flow control itself, perfect for structured processes needing predictable execution. core-agent-categories

즉, Agent를 사용하는 시스템을 설계할 때는 LLM이 맡아야 할 비결정론적 판단 영역과 코드가 책임져야 할 결정론적 제어 영역을 명확히 분리해야 함을 알 수 있다.

이제 이를 다시 GitHub Issue 자동 생성 시스템에 적용해보자.

결정론적인 것

이 영역은 시스템이 항상 동일한 원칙으로 동작하도록 보장하는 부분이다.

워크플로우
- 사용자 입력 → 이슈 초안 생성 → 사용자 검토 → 재생성 또는 승인
단계 전이 조건
- 승인하면 종료
- 재요청하면 재생성
- 드롭하면 중단
각 Agent의 역할 분리
- 읽기 담당
- 초안 작성 담당
- 피드백 반영 담당
입출력 스키마
- Issue title
- summary 등
권한과 실행 범위
- 읽기 전용 도구만 허용
- 특정 repository / path만 접근 가능하도록 제한
재시도 / 중단 정책
- 실패 시 재시도 횟수 제한
- 특정 조건에서 강제 중단
사람 개입 지점
- 최종 등록 전 반드시 사용자 승인 필요

비결정론적인 것

이 영역은 LLM이 맥락을 해석하고 판단하며 생성하는 부분이다.

Issue 내용 자체
- 제목
- 본문 표현
- 요약 방식
- 세부 문장 구성
무엇을 중요하게 볼지에 대한 판단
- 요구사항 해석
- 핵심 문제 식별
- 우선순위 추정
코드 / 문서 맥락을 요약하는 방식
- 어떤 파일을 더 relevant하다고 볼지
- 어떤 정보를 중심으로 설명할지
모호한 요구사항을 구체화하는 방식
- 불명확한 요청을 어떤 방향으로 정리할지
- 어떤 수준까지 세부화할지
피드백 반영 방식
- 재생성 시 어떤 표현을 수정할지
- 어떤 구조를 유지하고 무엇을 바꿀지

따라서 GitHub Issue 자동 생성 시스템에서의 핵심 설계 원칙은 다음과 같이 정리할 수 있다.

이슈의 내용은 LLM이 생성하더라도,
그 생성이 놓이는 워크플로우, 검증, 권한, 승인, 중단 조건은
반드시 코드 레벨에서 통제되어야 한다.

3.2 Idempotency

기존 웹 시스템에서 중복 요청은 단순히 짜증 나는 일일 수 있지만, AI 기반 시스템에서는 치명적일 수 있다.

RAG 파이프라인이 민감한 고객 이메일을 두 번 발송함.
AI 에이전트 두 개가 독립적으로 동일한 환불을 승인함.
장기 워크플로우가 중간 단계에서 재시도되면서 하위 효과를 재트리거함.

AI 오케스트레이션은 본질적으로 multi-step이며 stateful하며 비동기적이다. 모델 추론 시간이나 API 제한으로 인해 지연을 예측할 수 없으며, 복구 과정에서 여러 계층의 재시도가 발생할 수 있다. 이때 시스템 레벨에서의 멱등성(Idempotency) 설계가 없다면 재시도와 동시성은 돌이킬 수 없는 부작용을 낳는다.

workflow에서의 멱등성:
1. 시스템이 두 번의 호출이 동일한 의도임을 인식해야 함.
2. 작업이 이미 성공적으로 완료되었는지 알아야 함.
3. 상위 workflow가 재시도 중임을 모르더라도 중복을 방지해야 함.

AI를 사용한 워크플로우에서 불필요한 재시도와 중복 요청은 모델 호출 비용으로 고스란히 나가기 때문에 이를 처리하는것이 중요하다.

LLM Agent가 예측할 수 없다는 것을 인지하고 이를 위한 가드레일을 시스템 레벨에서 확실하게 구현해야 한다는 것.

4. 어떤 프레임워크를 써야하나?

4.1 비교

현재 검토 중인 에이전트 프레임워크를 비교해보면, 각 도구는 지향점이 꽤 다르다.

1. OpenAI Agents SDK - 가벼운 프레임워크

특징: agent, tool, handoff 같은 작은 primitive 중심
장점: 서버 코드에서 흐름을 세밀하게 통제하기 좋고, 단발성 작업이나 오케스트레이션 로직을 코드 레벨에서 명시적으로 제어하기 편하다
용량도 비교적 크지 않은 편이라, 경량 SDK를 선호하는 경우 잘 맞는다

2. Anthropic Agent SDK - Claude Code를 라이브러리처럼 제공

특징: Claude CLI를 그대로 사용하는 실행환경과 런타임을 함께 포함한 패키지
장점: Claude Code 스타일의 코딩 에이전트 경험을 코드로 확장하기에는 매력적일 수 있음
단점: 모델 비용도 높고, 패키지 자체도 무거워서 서버리스 환경이나 경량 오케스트레이션 용도에는 부담이 큼(250MB)
그래서 현재 기준에서는 우선순위가 많이 떨어짐

3. Google ADK - 얇은 에이전트 개발 키트

특징: OpenAI Agents SDK보다는 프레임워크 차원의 추상화가 조금 더 있는 편
느낌: 직접 다 짜기보다는 프레임워크가 제공하는 구조 위에서 설계하는 방식
장점: 패키지 자체는 가볍고, 에이전트 구조를 일정 수준 추상화해서 다루기 좋음

4.2 현재 판단

Anthropic Agent SDK는 현재 계획하고 있는 서버리스 환경 + 단발성 작업 중심구조에 사용하기에는 모델 비용도 비싸고 패키지도 무거워서 현재 용도에는 맞지 않을 가능성이 크다.

실제로 선택지는 Google ADK와 OpenAI Agents SDK 쪽으로 좁혀진다.

에이전트 간 연결과 흐름을 코드 레벨에서 직접 제어하고 싶다면
→ OpenAI Agents SDK
프레임워크가 어느 정도 구조를 제공해주고, 그 위에서 추상적으로 설계하고 싶다면
→ Google ADK

현재 내 환경은 서버리스 + 단발성 작업이기 때문에,
지속 실행형 상태 관리나 복잡한 그래프 기반 오케스트레이션보다는
명시적이고 가벼운 제어가 더 중요하다.
그래서 지금 기준으로는 OpenAI Agents SDK 쪽이 더 적합해 보인다.

LangGraph?

LangGraph는 이번 선택지에서는 제외하고 있다.

이유는 현재 목표가

장기 실행형 에이전트
복잡한 상태 그래프
지속적인 workflow orchestration

즉 LangGraph가 나쁜 도구라기보다,
현재 문제의 성격과는 잘 맞지 않는다고 보는 편이 맞다.

4.3 결론

결국 프레임워크마다 설계 철학이 너무 다르다.

어떤 곳은 primitive 중심
어떤 곳은 런타임 포함형
어떤 곳은 프레임워크 추상화 중심

이라서, 이름은 다 “agent SDK” 비슷하게 붙어 있어도
실제로는 해결하려는 문제와 사용 방식이 꽤 다르다.
이 때문에 공통점이 많다기보다, 오히려 각자 전혀 다른 방향을 보고 있는 느낌이 강하다.

현재 기준에서는
Google ADK와 OpenAI Agents SDK 중 하나를 선택할 가능성이 높고,
OpenAI Agents SDK를 사용하는 것이 빠르게 시작할 수 있을 것 같다.

Git, DevOps, AI

This post is licensed under CC BY 4.0 by the author.