Agentic AI (에이전트형 AI)에 관한 논의는 종종 하나의 목표에 집중됩니다. 바로 에이전트를 더 자율적으로 만드는 것입니다.

더 많은 도구. 더 많은 추론 (Reasoning). 더 많은 계획 (Planning). 더 많은 독립성.

이는 마치 진보처럼 들립니다.

하지만 더 많은 자율성이 항상 정답일까요?

소프트웨어 엔지니어로서 우리는 좀처럼 "더 많이"를 위해 최적화하지 않습니다. 모놀리스 (Monolith)로 충분할 때 분산 시스템 (Distributed systems)을 구축하지 않습니다. 마이크로서비스 (Microservices)가 유행한다고 해서 도입하지도 않습니다. 우리는 기능과 복잡성 사이의 균형을 맞추는 아키텍처를 선택합니다.

AI 에이전트에도 동일한 원칙이 적용됩니다.

질문은 **"내 에이전트가 얼마나 자율적일 수 있는가?"**가 아닙니다.

**"내 에이전트가 어느 정도의 자율성을 가져야 하는가?"**입니다.

자율성은 설계 결정 (Design Decision)이다

사람들이 자율성을 이야기할 때, 종종 에이전트가 가지고 있거나 가지고 있지 않은 하나의 기능으로 생각하곤 합니다.

현실적으로 자율성은 설계 결정 (Design decision)입니다.

우리가 에이전트에게 스스로 결정을 내리도록 허용할 때마다, 우리는 에이전트의 책임을 증가시키고 있는 것입니다. 그 책임에는 이점이 따르지만, 새로운 엔지니어링 과제도 함께 도입됩니다.

더 많은 자율성은 에이전트가 개발 과정에서 예상하지 못한 상황에 적응할 수 있음을 의미합니다. 모든 단계를 안내받지 않고도 목표를 향해 나아갈 수 있습니다.

동시에, 예측, 검증, 디버깅 (Debug), 그리고 신뢰하기가 더 어려워집니다.

자율성은 공짜가 아닙니다.

자율성 스펙트럼 (Autonomy Spectrum) 관점에서 생각하기

자율성을 이분법적인 개념으로 다루는 대신, 하나의 스펙트럼으로 생각하는 것이 도움이 됩니다.

한쪽 끝에는 단순히 응답을 생성하기만 하는 시스템이 있습니다. 이들은 행동을 취할 권한이 없습니다.

자율성이 증가함에 따라, 에이전트는 행동을 제안하고, 도구 (Tools)를 호출하며, 여러 단계를 계획하고, 결국 최소한의 인간 개입으로 목표를 달성하는 방법을 결정하기 시작합니다.

중요한 관찰 결과는 이 스펙트럼을 따라가는 모든 단계가 기능과 복잡성을 모두 증가시킨다는 점입니다.

그렇기 때문에 목표는 가장 높은 수준에 도달하는 것이 되어서는 안 됩니다.

당신의 문제가 실제로 요구하는 수준에서 멈추는 것이어야 합니다.

더 많은 자율성이 항상 더 나은 것은 아니다

사내 인사(HR) 어시스턴트를 구축한다고 상상해 보십시오.

이 어시스턴트의 주요 책임은 회사 정책에 관한 질문에 답하는 것입니다.

이 어시스턴트에게 내부 시스템을 자율적으로 탐색하고, 직원 기록을 수정하며, 이메일을 보낼 수 있는 능력을 부여하는 것이 더 나은 어시스턴트를 만들까요?

아마 아닐 것입니다.

그것은 가치보다 더 많은 리스크를 초래할 뿐입니다.

이제 생산 장애(production incidents) 조사를 담당하는 운영 에이전트(operations agent)를 생각해 보십시오.

이 에이전트는 로그를 검사하고, 모니터링 시스템을 쿼리하며, 문서를 검색하고, 배포 이력을 비교하며, 발견한 내용에 따라 조사를 지속적으로 조정해야 할 수도 있습니다.

이런 경우 미리 정의된 워크플로(workflow)는 금방 한계에 부딪힙니다.

여기서 더 큰 자율성은 진정으로 솔루션을 개선합니다.

차이점은 기술이 아닙니다.

해결하려는 문제입니다.

제한된 자율성 (Bounded Autonomy) 설계하기

가장 큰 오해 중 하나는 프로덕션 에이전트(production agents)가 완전히 자율적이어야 한다는 것입니다.

실제로 많은 성공적인 시스템은 의도적으로 제약을 가합니다.

제한된 자율성(Bounded autonomy)은 에이전트가 명확하게 정의된 한계 내에서 독립적으로 작동할 수 있도록 합니다.

그러한 한계에는 다음과 같은 것들이 포함될 수 있습니다:

• 에이전트가 접근할 수 있는 도구(tools) 제한
• 수행할 수 있는 작업(tasks) 범위 제한
• 영향력이 큰 작업 수행 전 승인 요구
• 지출 또는 실행 한도 강제
• 에이전트가 중단하고 에스컬레이션(escalate)해야 하는 시점 정의

이러한 제약은 에이전트를 약화시키지 않습니다.

오히려 에이전트를 더 예측 가능하고, 더 신뢰할 수 있으며, 더 믿기 쉽게 만듭니다.

자율성(Autonomy)과 주체성(Agency)

자율성이 증가함에 따라, 에이전트는 자연스럽게 더 많은 주체성(agency)을 갖게 됩니다.

에이전트는 요청에 응답하는 단계에서 목표를 능동적으로 추구하는 단계로 이동합니다.

하지만 주체성은 항상 책임과 함께 성장해야 합니다.

프로덕션 시스템을 독립적으로 수정할 수 있는 에이전트는 단순히 문서를 요약하는 에이전트보다 훨씬 더 높은 기준을 적용받아야 합니다.

우리가 부여하는 자율성의 양은 항상 시스템에 대한 신뢰 수준과 그 행동의 결과(consequences)를 반영해야 합니다.

적절한 수준 선택하기

에이전트의 자율성을 높이기 전에, 몇 가지 질문을 던져볼 가치가 있습니다.

• 이 문제는 미리 정의된 워크플로 (workflow)로 해결할 수 있는가?
• 다음 단계가 진정으로 사전에 알 수 없는 정보에 의존하는가?
• 에이전트가 잘못된 결정을 내리면 어떤 일이 발생하는가?
• 위험한 행동을 저위험 추론 (low-risk reasoning)과 분리할 수 있는가?
• 제한된 자율성 (bounded autonomy)으로도 동일한 결과를 얻을 수 있는가?

이러한 질문들은 종종 가장 단순한 해결책이 가장 적절한 해결책임을 드러내 줍니다.

마치며

에이전틱 AI (Agentic AI)의 미래는 무제한의 자율성을 가진 에이전트를 구축하는 것에 있지 않습니다.

그것은 적절한 자율성을 가진 에이전트를 설계하는 것에 관한 것입니다.

최고의 엔지니어는 자율성을 극대화하지 않습니다.

그들은 자율성이 어디서 시작되고, 어디서 끝나는지, 그리고 언제 인간이 루프의 일부 (part of the loop)로 남아 있어야 하는지를 의도적으로 결정합니다.

소프트웨어 엔지니어링에서 훌륭한 아키텍처 (architecture)는 결코 더 많은 것을 하는 것에 관한 것이 아니었기 때문입니다.

그것은 정확히 필요한 것만을 수행하고, 그 이상은 하지 않는 것에 관한 것이었습니다.