- 프로젝트 진행중에 단순한 스크립트 작성에서 자율적 AI 에이전트 구축으로 발전하는 과정이 반복적으로 나타남
- 개발중인 도구들에 대해 도구 접근권을 부여하자 단순 대화형 모델이 계획·실행·반복 가능한 에이전트로 전환됨
- 분류기나 조건문 기반 로직은 결국 에이전트 구조로 대체되며, 모델이 선택한 도구 호출 중심의 단순한 구조가 더 유연하고 강력함
- 인간의 역할은 Human-in-the-Loop에서 Human-on-the-Loop로 이동하고, 목표와 가드레일 설정이 핵심 과제가 됨
- 코드 복잡도보다 신뢰와 판단 관리가 중요해지며, 에이전트는 개발자와 함께 성장하는 시스템으로 자리잡음
단순 스크립트에서 에이전트로의 수렴
- 2025년 동안 진행한 대부분의 AI 프로젝트가 최종적으로 에이전트 형태로 귀결되었음
- 입력·처리·출력 구조의 간단한 스크립트가 반복 루프, 도구 배열, JSON 파싱을 추가하며 에이전트로 발전
- 본인이 생각하는 에이전트의 정의 : 도구에 접근할 수 있는 상태로 루프를 통해 실행되는 모델
- 즉, 충분한 시간이 주어진다면 모든 AI 프로젝트는 에이전트로 수렴하게 됨
자율성으로의 중력 이동
- 단순한 자동화 기능을 넘어서, 소프트웨어가 ‘디지털 인턴’ 처럼 스스로 판단하고 실행하는 단계로 이동
-
Gemini Scribe는 처음엔 단순한 옵시디언용 채팅 플러그인이었으나,
read_file 도구 접근을 허용하자 문맥 관리와 실행을 스스로 수행
- 사용자는 더 이상 모델의 입력을 수동 관리하지 않고, “회의록을 읽고 요약하라”는 지시 수준의 명령만 전달
- 이러한 변화는 대화에서 위임으로의 전환을 의미하며, 에이전트가 계획·실행·반복을 담당하는 구조로 발전
스크립트에서 Sudoers로
-
Gemini CLI 개발 과정에서도 모델이 명령 실행 도구를 사용하면서 단순 코드 생성기를 넘어 자율적 실행자로 확장
- 모델이 테스트를 실행하고 실패를 감지한 뒤, 스스로 수정 후 재실행하는 루프를 구성
- 이 과정에서 보안과 신뢰 문제가 부각되어,
sudoers 파일처럼 권한 구분 정책 시스템이 필요해짐
- 단순 스크립트는 정책 엔진이 불필요하지만, 에이전트는 판단 오류 방지용 가드레일이 필수
분류기가 되고 싶었던 에이전트
-
Podcast RAG 프로젝트에서, 사용자 질의에 따라 검색 대상을 분류하는 AI 분류기를 만들었으나 한계가 드러남
- 분류 로직이 사용자 의도를 완전히 반영하지 못하고, 모델이 이미 잘 수행할 수 있는 판단을 코드로 제한
- 해결책은 분류기를 제거하고
search_descriptions, search_episodes 두 도구를 에이전트에 제공한 것
- 에이전트가 상황에 따라 도구를 선택·병행 사용하며 더 유연한 검색 수행
- Gemini Scribe에서도 복잡한 문맥 예측 로직을 제거하고, 필요 시점에 파일을 읽는 도구 호출 구조로 단순화
- “AI가 무엇을 해야 할지 if/else로 결정하고 있다면, 이미 에이전트를 만들고 있는 것”이라는 개발 기준 제시
Human-on-the-Loop로의 전환
- 인간의 역할이 모든 단계를 승인하는 구조에서 목표와 경계만 설정하는 감독자 역할로 이동
- 에이전트는 인간의 지속적 개입 없이 작업을 수행하므로, 명확한 목표·경계·예외 처리 정의가 필수
- 적절한 가드레일이 없으면 에이전트가 입력 대기나 비생산적 경로에 빠질 위험도 존재
- 인간은 실행자가 아니라 감독자이자 경계 설정자로서 시스템의 방향을 관리함
복잡성을 받아들이기
- 에이전트 구축은 겉보기보다 어렵지 않으며, 오히려 조건 분기와 예외 처리 로직을 제거해 단순화 가능
- 모델이 상황에 따라 판단하므로, 사전 예측 로직이 불필요
- 진짜 복잡성은 코드가 아니라 신뢰와 판단 위임에 있음
- 개발자는 문법 오류보다 판단 오류를 방지하는 설계에 집중해야 함
- 에이전트는 고정된 스크립트와 달리 사용자의 요청에 따라 진화하며 더 나은 방법을 찾아가는 시스템
- 단순 스크립트에 도구 정의를 추가하고 싶어질 때, 이미 에이전트 구축 단계에 진입한 것임