12-Factor Agents: 신뢰할 수 있는 LLM 에이전트 개발 패턴 요약

에이전트 개발의 여정과 현실

발표자인 Dex Horthy는 에이전트(Agent)를 개발해본 경험이 있는지 청중에게 물으며 강연을 시작합니다. 그는 많은 개발자들이 에이전트 개발에 도전하지만, 실제로는 70~80% 수준에서 멈추는 경우가 많다고 말합니다.

"70~80%까지는 금방 만들 수 있어요. CEO도 신나고 팀원도 늘어나죠. 그런데 그 다음이 문제입니다."

이 단계에서 개발자들은 복잡한 콜스택을 파고들며, 프롬프트가 어떻게 만들어지는지, 도구(tool)가 어떻게 전달되는지 역추적하게 됩니다. 결국,

"저처럼 결국 다 버리고 처음부터 다시 시작하게 되죠."

또한, 모든 문제가 에이전트로 해결될 필요는 없다는 점도 강조합니다. 예를 들어, DevOps 에이전트를 만들려다 결국

"이거 그냥 bash 스크립트로 90초 만에 쓸 수 있었겠구나"
라는 깨달음을 얻었다고 합니다.

현업에서 발견한 패턴과 12-Factor Agents의 탄생

Dex는 100명 이상의 창업자, 개발자, 엔지니어와 대화하며 실제 현업에서 잘 동작하는 LLM 기반 에이전트의 공통 패턴을 발견합니다.

"대부분의 프로덕션 에이전트는 사실 그렇게 '에이전트적'이지 않아요. 그냥 소프트웨어에 가까워요."

이 패턴들은 기존 코드를 완전히 새로 쓰는 것이 아니라, 작고 모듈화된 개념을 기존 코드에 적용하는 방식이었습니다. Dex는 이를 바탕으로 12-Factor Agents라는 개념을 정리해 GitHub에 공개했고, 많은 공감을 얻었습니다.

"이건 프레임워크를 비판하려는 게 아니에요. 오히려 정말 좋은 빌더들이 빠르게 움직이면서도 높은 신뢰성을 얻을 수 있도록, 프레임워크가 어떤 기능을 제공해야 하는지에 대한 '위시리스트'에 가깝습니다."

12-Factor Agents의 주요 원칙들

1. LLM의 마법은 '문장을 JSON으로 바꾸는 것'에서 시작된다

LLM이 할 수 있는 가장 마법 같은 일은 복잡한 코드나 도구 사용이 아니라,

"이런 문장을 이런 JSON으로 바꿔주는 것"
입니다. 이 JSON을 어떻게 활용할지는 이후의 다른 패턴들이 담당합니다.

2. 프롬프트와 컨텍스트 윈도우를 '직접' 소유하라

프롬프트를 잘 다루는 것이 에이전트의 품질을 좌우합니다.

"결국 어느 순간엔 모든 토큰을 직접 손으로 써야 할 거예요."
LLM은 입력된 토큰에만 반응하는 순수 함수이기 때문에,
"좋은 토큰을 넣는 것, 그게 신뢰성의 핵심입니다."

컨텍스트 윈도우 역시 마찬가지입니다.

"모든 토큰을 하나하나 살펴보고, 정보를 얼마나 명확하게 전달하는지 최적화해야 해요."

3. 도구(tool) 사용은 '마법'이 아니다

많은 사람들이 도구 사용을 에이전트의 핵심으로 생각하지만, Dex는

"도구 사용은 해롭다(tool use is harmful)"
라고까지 말합니다. 실제로는 LLM이 JSON을 출력하고, 이를 결정론적 코드가 받아 처리하는 구조일 뿐입니다.

4. 제어 흐름(Control Flow)을 직접 소유하라

에이전트의 실행 흐름을 직접 관리해야 높은 신뢰성을 얻을 수 있습니다.

"코드는 그래프입니다. if문을 써봤다면 이미 DAG(Directed Acyclic Graph)를 쓴 거예요."

에이전트의 기본 구조는 다음과 같습니다:

프롬프트: 다음 스텝을 어떻게 선택할지 지시
스위치문: 모델이 출력한 JSON을 받아 처리
컨텍스트 윈도우: 정보를 누적
루프: 언제, 어떻게 종료할지 결정

"제어 흐름을 직접 소유하면 break, switch, summarize, LM이 판정하는 등 다양한 유연성을 가질 수 있습니다."

5. 상태(State) 관리와 API화

에이전트의 실행 상태와 비즈니스 상태를 분리해 관리해야 합니다.

실행 상태: 현재 스텝, 다음 스텝, 재시도 횟수 등
비즈니스 상태: 사용자 메시지, 표시 데이터, 승인 대기 등

이 상태를 REST API나 MCP 서버 뒤에 두고, 컨텍스트 윈도우를 데이터베이스에 직렬화/복원할 수 있어야 합니다.

"에이전트는 그냥 소프트웨어입니다. 잘 만들려면 유연성이 필요하고, 그 핵심은 내부 루프를 직접 소유하는 거예요."

6. 에러 처리와 컨텍스트 최적화

모델이 API를 잘못 호출하거나 에러가 발생했을 때,

"에러를 컨텍스트 윈도우에 그냥 쌓지 말고, 요약해서 필요한 정보만 남기세요."
이렇게 해야 모델이 맥락을 잃지 않고 더 좋은 결과를 낼 수 있습니다.

7. 인간과의 상호작용(휴먼 인더 루프)

에이전트가 도구 호출과 인간 메시지 중 무엇을 선택할지 자연어 토큰에서 결정하게 하면,

"모델이 '완료', '추가 설명 필요', '매니저와 대화 필요' 등 다양한 의도를 자연스럽게 표현할 수 있습니다."

이 방식은 이메일, 슬랙, 디스코드, SMS 등 다양한 채널에서 에이전트와 상호작용할 수 있게 해줍니다.

8. 마이크로 에이전트(Micro Agents) 구조

효과적으로 동작하는 에이전트는 대부분 작고 집중된(micro) 구조를 가집니다.

"대부분의 파이프라인은 결정론적 코드로 처리하고, LLM은 3~10단계의 작은 루프에서만 사용합니다."

예시로, HumanLayer의 배포 봇은 대부분 CI/CD 코드로 처리하다가,

"GitHub PR이 머지되고 테스트가 통과하면, 모델에게 '배포해'라고 시킵니다. 모델이 '프론트엔드부터 배포할게요'라고 하면, 사람이 '아니, 백엔드 먼저 해'라고 자연어로 수정할 수 있죠."

이렇게 자연어를 JSON으로 바꿔 워크플로우의 다음 단계를 결정합니다.

9. 상태는 '무상태(stateless)'로 관리

에이전트는 상태를 직접 소유하지 않고, 외부에서 관리해야 합니다.

"에이전트는 리듀서가 아니라 트랜스듀서입니다. 여러 단계를 거치니까요."

프레임워크 vs. 라이브러리, 그리고 앞으로의 방향

Dex는

"에이전트에 필요한 건 부트스트랩이 아니라, shadCN처럼 스캐폴딩만 해주고 나머지는 내가 직접 소유하는 구조"
라고 강조합니다.

요약 및 마무리

에이전트는 결국 소프트웨어입니다.
LLM은 무상태 함수이므로, 컨텍스트와 상태, 제어 흐름을 직접 소유해야 최고의 결과를 얻을 수 있습니다.
인간과의 협업을 적극적으로 설계해야 하며,
어려운 부분을 직접 다루는 것이 오히려 더 좋은 에이전트를 만드는 길입니다.

"여러분 모두 소프트웨어를 만들 수 있습니다. switch문, while문 써봤다면 할 수 있어요." "에이전트는 사람이랑 같이 할 때 더 좋아집니다. 인간과 협업하는 방식을 꼭 고민해보세요." "어려운 부분이 있지만, 지금은 직접 해보는 게 좋습니다. 대부분의 프레임워크는 AI의 어려운 부분을 감추려 하지만, 오히려 그 부분에 집중할 수 있도록 도와주는 도구가 필요합니다."

Dex는 오픈소스와 협업의 중요성을 강조하며,

"함께 더 나은 에이전트를 만들어봅시다. 복도에서 만나요!"
라는 인사로 발표를 마무리합니다.

핵심 키워드 요약

에이전트(Agent)
LLM(대형 언어 모델)
프롬프트 엔지니어링
컨텍스트 윈도우
제어 흐름(Control Flow)
도구 사용(Tool Use)
상태 관리(State Management)
마이크로 에이전트(Micro Agents)
인간과의 상호작용(Human in the Loop)
오픈소스, 협업

💡 결론:
에이전트 개발은 복잡해 보이지만, 결국은 기본에 충실한 소프트웨어 엔지니어링입니다.
직접 제어하고, 직접 실험하고, 인간과 협업하는 구조를 고민한다면, 누구나 신뢰할 수 있는 LLM 에이전트를 만들 수 있습니다! 🚀