AI가 스스로 회의하고 코딩하는 시대? 'Agency Agents'의 진짜 의미와 생태계 (현직 개발자의 딥다이브)
“우리는 지금 AI가 인간의 ‘질문’에 답하는 시대를 지나, 인간의 ‘목표’를 스스로 달성하는 시대로 넘어가고 있습니다.”
안녕하세요! 기술의 이면을 파헤치는 것을 즐기는 현직 개발자입니다. 최근 개발자 커뮤니티를 뜨겁게 달구고 있는 키워드가 있죠. 바로 ‘Agency Agents(에이전시 에이전트)’ 또는 ‘Agentic Workflows’입니다.
불과 1~2년 전만 해도 우리는 ChatGPT에게 “이 코드 좀 짜줘”라고 명령하고, 나오는 결과를 복사해서 붙여넣는 데 열광했습니다. 그런데 요즘 깃허브(GitHub) 트렌드나 최신 논문들을 보면 분위기가 심상치 않더라고요. 이제는 AI에게 “우리 서비스 로그인 페이지 좀 만들어줘”라고 던져주면, 기획자 AI, 프론트엔드 AI, 백엔드 AI, QA AI가 알아서 그룹 채팅방을 파고 회의를 하며 코드를 짜고 테스트까지 마무리하는 시대가 오고 있습니다.
처음 이 개념을 접했을 때 제 솔직한 심정은 ‘와, 이거 미치겠네. 내 밥그릇은 안전할까?’ 하는 두려움과 ‘이걸로 내 귀찮은 단순 반복 업무를 싹 다 자동화할 수 있겠다!’는 짜릿함이 교차했습니다. 그래서 오늘은 여러분과 함께 이 Agency Agents가 도대체 무엇인지, 기술적으로 어떻게 구현되는지, 그리고 우리가 당장 실무에 어떻게 써먹을 수 있을지 사람 냄새 풀풀 나게, 하지만 아주 딥(deep)하게 파헤쳐보려고 합니다.
🎯 TL;DR (바쁜 현대인을 위한 10초 요약)
Agency Agents(에이전시 에이전트)란? 단순 텍스트 생성기(LLM)에 ‘자율성(Agency)’을 부여하여, 스스로 계획을 세우고(Planning), 도구를 사용하며(Tool Use), 기억을 유지하고(Memory), 심지어 다른 에이전트들과 협업하여 복잡한 목표를 완수하는 자율형 인공지능 시스템입니다.
⚙️ The Architecture / Technical Deep Dive: 에이전트는 어떻게 ‘생각’하고 ‘행동’하는가?
단순한 LLM(대규모 언어 모델)과 Agency Agent의 가장 큰 차이는 ‘행동력(Action)’과 ‘피드백 루프(Feedback Loop)’에 있습니다. LLM이 뇌(Brain)라면, Agent는 뇌에 손과 발, 그리고 메모리 칩을 달아준 형태입니다.
이 시스템이 동작하는 핵심 원리는 크게 4가지 컴포넌트로 나눌 수 있습니다.
- Profile (페르소나 부여): 에이전트가 어떤 역할을 할지 정의합니다. (예: “너는 20년 차 시니어 파이썬 개발자야.”)
- Memory (단기/장기 기억): 문맥을 유지하는 단기 기억(Context Window)과, 벡터 데이터베이스(Vector DB)를 활용해 과거의 경험을 검색해오는 장기 기억을 갖습니다.
- Planning (추론 및 계획): 복잡한 문제를 작은 단위로 쪼개는 능력입니다. 대표적으로 ReAct (Reasoning and Acting) 프레임워크가 사용됩니다.
- Tools / Actions (도구 사용): 웹 검색, API 호출, 코드 실행, 파일 읽기/쓰기 등 실제 세상(또는 시스템)과 상호작용하는 능력입니다.
개발자 시각에서 이 구조를 코드로 살짝 엿볼까요? 우리가 에이전트를 구현할 때 내부적으로는 대략 이런 무한 루프(While loop)가 돌고 있다고 생각하시면 됩니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# ReAct (Reasoning + Acting) 기반 에이전트의 단순화된 내부 로직
def run_agent(objective):
context = ""
while True:
# 1. LLM에게 현재 상황을 주고 다음 행동을 생각(Thought)하게 함
prompt = f"목표: {objective}
현재 문맥: {context}
다음 행동을 결정해."
thought_and_action = llm.generate(prompt)
# 2. 에이전트가 '종료'를 결정하면 루프 탈출
if "FINAL_ANSWER" in thought_and_action:
return extract_answer(thought_and_action)
# 3. 도구(Tool) 선택 및 실행 (예: 구글 검색, 파이썬 코드 실행)
tool_name, tool_args = parse_action(thought_and_action)
observation = execute_tool(tool_name, tool_args)
# 4. 결과를 문맥에 추가하고 다시 반복 (Observation)
context += f"
행동: {tool_name}
결과: {observation}"
이런 단일 에이전트를 넘어서, 최근에는 멀티 에이전트 시스템(Multi-Agent Systems)이 대세입니다. LangGraph나 CrewAI 같은 프레임워크를 사용하면, 각기 다른 역할을 가진 에이전트들을 노드(Node)로 만들고 이들 간의 대화 흐름을 DAG(방향성 비순환 그래프) 형태로 설계할 수 있습니다.
표 1: 기존 LLM 시스템과 Agency Agents 비교
| 구분 | 기존 LLM (예: ChatGPT) | Agency Agents (예: AutoGen, CrewAI) |
|---|---|---|
| 핵심 목적 | 질문에 대한 텍스트/코드 생성 | 주어진 목표의 자율적 완수 |
| 작동 방식 | 단발성 요청-응답 (One-shot) | 추론 ➡️ 행동 ➡️ 관찰의 무한 루프 |
| 상호작용 | 인간과 AI의 1:1 대화 | AI와 AI 간의 다대다(N:N) 협업/토론 |
| 도구 사용 | 제한적 (플러그인 등) | 자유로운 외부 API, 터미널, DB 접근 |
| 오류 수정 | 인간이 다시 프롬프트를 수정해야 함 | 스스로 오류를 인지하고 다시 코드를 작성함 |
🚀 Why it Matters (Impact): 이 기술이 판을 뒤엎을 3가지 이유
Agency Agents가 그저 지나가는 유행이 아니라, 우리 산업 전반에 거대한 파장을 일으킬 것이라고 확신하는 이유가 있습니다.
1. 소프트웨어 개발 생명주기(SDLC)의 파괴적 혁신 지금까지 코파일럿(Copilot)이 개발자의 타이핑 속도를 높여주는 ‘자동 완성’ 도구였다면, Agency Agents는 아예 ‘가상의 개발팀’을 꾸려줍니다. 버그 리포트가 올라오면 ➡️ 매니저 에이전트가 이슈를 분석하고 ➡️ 시니어 개발자 에이전트가 코드를 수정하며 ➡️ QA 에이전트가 테스트 코드를 작성하고 돌려봅니다. 인간 개발자는 이들이 제출한 Pull Request(PR)를 리뷰하고 승인(Approve)하는 ‘오케스트레이터(Orchestrator)’ 역할로 격상됩니다.
2. Intent-Based UI(의도 기반 인터페이스)로의 전환 소프트웨어의 형태가 바뀔 것입니다. 지금은 사용자가 항공권을 예매하기 위해 버튼 10개를 누르고, 결제창을 거쳐야 하죠. 하지만 앞으로는 “이번 주말 제주도 가는 가장 싼 표 2장 예매해줘”라는 의도(Intent)만 던지면, 백그라운드에서 에이전트들이 웹 브라우저를 조종하고 API를 호출해 결과를 가져올 것입니다. ‘소프트웨어를 쓰는 소프트웨어’의 등장입니다.
3. ‘1인 유니콘 기업’의 탄생 가시화 아이디어 하나만 있으면, AI 에이전트 수십 명을 월 몇만 원에 고용하여 글로벌 서비스를 론칭할 수 있습니다. 마케팅 에이전트, 고객 CS 에이전트, 데이터 분석 에이전트가 24시간 쉬지 않고 일하는 회사를 상상해보세요. 기술적 진입 장벽이 무너지면서 창의력과 기획력이 최고의 무기가 되는 시대가 열리고 있습니다.
💡 Hands-on / Use Case (Blueprint): 내 맘대로 부리는 가상 개발팀 만들기
백문이 불여일견! 제가 최근에 사이드 프로젝트에 적용해봤던 가상의 소프트웨어 하우스 구축 시나리오를 공유해드릴게요. 파이썬 프레임워크인 CrewAI를 활용하면 이렇게 직관적으로 AI 팀을 꾸릴 수 있습니다.
목표: “최신 AI 트렌드를 분석해서 벨로그(Velog) 마크다운 형식의 블로그 포스트를 자동으로 작성해라.”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
from crewai import Agent, Task, Crew, Process
# 1. 에이전트(직원) 정의하기
# 리서처: 웹 검색 능력을 가진 데이터 수집가
researcher = Agent(
role='시니어 기술 리서처',
goal='최신 AI 트렌드와 Agency Agent에 대한 핵심 정보 수집',
backstory='당신은 실리콘밸리에서 가장 트렌드에 민감한 테크 리서처입니다. 팩트 기반의 정확한 데이터를 사랑합니다.',
verbose=True,
allow_delegation=False
)
# 라이터: 정보를 바탕으로 글을 쓰는 작가
writer = Agent(
role='테크 칼럼니스트',
goal='리서처가 준 데이터를 바탕으로 사람 냄새 나는 매력적인 한국어 블로그 포스트 작성',
backstory='당신은 독자들의 호기심을 자극하고 어려운 기술을 쉽게 풀어쓰는 천재적인 현직 개발자 출신 작가입니다.',
verbose=True,
allow_delegation=False
)
# 2. 할 일(Task) 정의하기
task1 = Task(description='Agency Agent의 최신 깃허브 트렌드 조사', expected_output='핵심 요약 리포트', agent=researcher)
task2 = Task(description='리포트를 바탕으로 블로그 포스트(마크다운) 작성', expected_output='완성된 블로그 글', agent=writer)
# 3. 크루(팀) 결성 및 일 시키기
tech_blog_crew = Crew(
agents=[researcher, writer],
tasks=[task1, task2],
process=Process.sequential # 순차적으로 작업 진행
)
# 실행!
result = tech_blog_crew.kickoff()
print(result)
코드를 실행하면 터미널 창에서 리서처와 작가가 서로 대화를 나누고, 구글 검색을 하고, 초안을 반려하며 글을 다듬어가는 과정을 실시간으로 볼 수 있습니다. 이 과정을 지켜보고 있으면 정말 “와, 미쳤다”는 말이 절로 나옵니다. 혼자서 일주일 걸릴 자료조사와 초안 작성이 단 5분 만에 끝나는 마법을 경험할 수 있죠.
🛑 Honest Review (The Truth): 장밋빛 환상 이면의 쓰디쓴 한계점들
하지만 현실은 결코 호락호락하지 않습니다. 현직 개발자로서 이 기술을 실무에 도입하려다 벽에 부딪히며 느꼈던 솔직하고 뼈아픈 한계점들을 말씀드릴게요. 무조건적인 찬양은 금물입니다.
표 2: Agency Agents의 환상과 현실
| 기대했던 환상 (Expectations) | 마주친 현실 (Reality) | 극복을 위한 고민 |
|---|---|---|
| “알아서 에러를 고쳐줄 거야!” | 무한 루프의 늪. 에러를 고치려다 다른 에러를 내고, 밤새 서로 싸우다가 토큰만 낭비함. | Agent의 최대 재시도 횟수(Max Iterations) 설정 및 Human-in-the-loop(인간 개입) 필수 설계. |
| “복잡한 시스템도 한 번에 만들겠지?” | 컨텍스트 유실. 대화가 길어지면 초기 목표를 까먹거나 엉뚱한 라이브러리를 사용함. | 철저한 모듈화. 큰 태스크를 아주 작은 마이크로 태스크로 쪼개어 각각 독립적인 Agent에게 할당. |
| “비용이 훨씬 저렴할 거야!” | 토큰 폭탄 청구서. 생각(Thought) 과정을 모두 출력하므로 GPT-4 기준 API 비용이 상상을 초월함. | 추론은 저렴한 로컬 모델(Llama 3 등)로, 중요한 의사결정만 고성능 모델(GPT-4o, Claude 3.5)로 라우팅하는 하이브리드 전략. |
가장 치명적인 문제는 ‘비결정성(Non-determinism)’입니다. 일반적인 코드는 인풋이 같으면 아웃풋이 같습니다. 버그가 나면 디버깅이 가능하죠. 하지만 Agent 시스템은 확률 기반의 LLM에 의존하므로, 어제는 잘 작동하던 파이프라인이 오늘은 갑자기 환각(Hallucination)에 빠져 엉뚱한 결과물을 내놓을 수 있습니다.
시스템의 복잡도가 올라갈수록 어느 Agent가 어디서 잘못된 판단을 했는지 추적(Observability)하기가 지옥처럼 어렵습니다. 따라서 초기에는 핵심 비즈니스 로직보다는 ‘실패해도 타격이 적은 보조 업무(사내 문서 검색, 초안 작성, 보조 QA)’에 도입하는 것이 현명합니다.
🏁 Closing Thoughts: 우리는 이제 ‘코더’가 아닌 ‘오케스트레이터’가 되어야 합니다
Agency Agents 기술은 완벽하지 않습니다. 때로는 멍청한 실수를 반복하고, 엄청난 API 비용을 청구하며 우리를 당황하게 만들죠. 하지만 분명한 것은 이 기술의 발전 속도가 우리의 예상보다 훨씬 빠르다는 것입니다. 모델의 추론 능력이 비약적으로 상승하고 컨텍스트 윈도우가 무한에 가깝게 확장되면서, 지금 우리가 겪는 한계점들은 곧 기술적으로 해결될 가능성이 높습니다.
현직 개발자로서 저는 이 변화를 위협이 아닌 거대한 레버리지(Leverage)로 받아들이기로 했습니다. 코드를 한 줄 한 줄 직접 짜는 시대(Coder)는 저물어가고 있습니다. 대신 여러 AI 에이전트들의 성향을 파악하고, 명확한 목표(Prompt)와 도구(Tools)를 쥐여주며, 이들이 최고의 성과를 내도록 지휘하는 ‘오케스트레이터(Orchestrator)’의 시대가 도래했습니다.
여러분의 다음 토이 프로젝트에는 프론트엔드와 백엔드를 직접 다 짜는 대신, 가상의 AI 크루(Crew)를 고용해보는 건 어떨까요? 이들이 밤새워 여러분의 아이디어를 코드로 구현해내는 모습을 지켜보는 것만으로도, 여러분은 이미 미래의 개발 방법론 한가운데 서 있는 것입니다.
기술의 파도를 타는 탐험가 여러분, Agency Agents가 열어갈 새로운 생태계에서 여러분만의 멋진 가상 오케스트라를 지휘해보시길 응원합니다! 🔥
References
- https://github.com/joaomdmoura/crewAI
- https://python.langchain.com/docs/langgraph/
- https://microsoft.github.io/autogen/
- https://arxiv.org/abs/2210.03629
