지시사항이 아닌 목표: AI 에이전트가 실제로 수행할 수 있는 작업 작성하기
요약
Google은 자사 어시스턴트가 단순 지시사항 처리 수준을 넘어, '목표(objectives)' 기반의 에이전트로 진화하고 있음을 발표했습니다. 이는 사용자가 최종 결과(outcome)를 정의하면, 에이전트가 스스로 작업을 계획하고 도구를 사용하여 실행하는 방식입니다. 성공적인 목표 설정을 위해서는 '완료의 정의', '경계', 그리고 '에스컬레이션 규칙' 세 가지 요소가 필수적입니다.
핵심 포인트
- 단순 지시사항 대신 최종 결과(목표)를 정의해야 합니다.
- 성공적인 에이전트 목표는 완료 상태, 경계, 예외 처리 규칙을 포함합니다.
- 에이전트는 스스로 계획을 수립하지만, 첫 실행은 반드시 검토가 필요합니다.
지난 목요일 Google의 Gemini at Work 행사에서 이 회사는 자사 어시스턴트가 에이전트로 진화하고 있다고 발표했습니다. 즉, 사용자를 대신하여 작업을 계획하고, 도구를 사용하며, 비즈니스 시스템에 연결하는 에이전트입니다. 대부분의 보도는 기능 목록에 초점을 맞출 것입니다. Google Cloud CEO Thomas Kurian의 한 문구가 그 아래 모든 항목보다 더 많은 주목을 받을 자격이 있습니다: 새로운 에이전트에게는 단순히 '지시사항'이 아니라 **'목표(objectives)'**가 주어질 수 있다는 것입니다.
이는 소규모 사업주들이 실제로 다음에 필요로 하는 기술에 대한 다섯 단어짜리 직무 설명입니다. 프롬프트 작성 능력이 아닙니다. 위임 능력입니다. 그리고 위임에는 대부분의 사람들이 어렵게 배우는 규칙이 있는데, 이는 이제 소프트웨어에도 적용되는 직원 형태의 규칙들입니다.
지시사항과 목표의 차이점
지시사항은 사용자가 생각하고 에이전트가 타이핑하는 방식입니다:
"화요일에 견적 문의를 했던 계약업체에게 후속 이메일을 작성해 줘."
목표는 사용자가 결과(outcome)를 정의하고 에이전트가 작업을 계획하는 방식입니다:
"2주 동안 답변이 없는 모든 견적은 금요일까지 '예' 또는 '아니오'로 처리되어야 해. 초안은 내가 승인할 수 있도록 큐에 넣어줘. 두 번이나 연락이 끊긴 사람은 전화 통화가 필요하다는 플래그를 달아줘."
두 번째 방식에서 진정한 레버리지가 있습니다. 하지만 여기 함정이 있습니다: 대부분의 사람들은 에이전트에게 그 목표가 도저히 충족할 수 없는 것을 맡기는데, 왜냐하면 그 목표에는 에이전트가 스스로 추론할 수 없는 세 가지 요소가 빠져 있기 때문입니다. 에이전트는 계획을 세울 뿐, 마음을 읽지는 못합니다.
모든 목표에 필요한 세 가지 요소
1. 완료의 정의(A definition of done). "후속 조치를 개선하자"는 바람일 뿐입니다. "2주 동안 답변이 없는 모든 견적은 금요일까지 '예' 또는 '아니오'로 처리되어야 해"는 목표입니다. 이것은 작업이 끝났는지 확인할 수 있는 순간을 포함합니다. 만약 외부에서 그 작업이 완료되었는지 알 수 없다면, 에이전트도 알 수 없습니다. 숫자나 날짜를 넣어 한 문장으로 완료 상태(done-state)를 작성하세요.
2. 경계(Boundaries). 에이전트가 만질 수 있는 것과 절대 만지면 안 되는 것을 정의합니다. 유용한 버전은 간결합니다. 즉, 인용 로그(quote log), 이메일 기록(email history), 캘린더를 읽을 수는 있습니다. 아웃바운드 메시지를 초안 작성할 수는 있습니다. 하지만 승인 없이 아무것도 보내거나, 돈과 관련된 것을 만지거나, 처음 접촉하는 사람에게 연락해서는 안 됩니다. 두 가지 목록을 만들고 5분 동안 작성하면, 비서와 사고 사이의 차이를 알 수 있습니다.
3. 에스컬레이션 규칙(An escalation rule). 언제 멈추고 물어볼지 결정합니다. 효과적인 방법은 다음과 같습니다: '무언가가 경계에 맞는지 확실하지 않거나, 고객이 화난 내용, 법률 관련 내용, 또는 혼란스러운 내용으로 답장하면 — 멈추고 저에게 가져오세요.' 에이전트는 규칙 사이의 공백에서 가장 잘못 작동합니다. 그 공백에 서 있을 명시적인 장소를 부여하세요.
만약 목표(objective)가 이 세 가지를 모두 갖추고 있다면, 에이전트는 그것에 맞춰 계획을 세울 수 있습니다. 만약 하나라도 빠져 있다면, 에이전트는 무언가로 그 공백을 채우게 될 것이며 — 당신은 그것으로 채워진 것을 좋아하지 않을 것입니다.
첫 번째 계획은 절대 검토 없이 실행시키지 마세요
Google의 발표는 메커니즘을 명확하게 설명합니다. 즉, 에이전트에게 작업을 할당하거나, 태스크를 예약하거나, 이벤트에 응답하도록 맡기면, 에이전트는 스스로 작업 계획(plan)을 세웁니다 — 각자 고유한 정체성을 가진 하위 에이전트들의 목록을 만들어 병렬로 다단계 작업을 실행합니다. 어떤 도구를 사용하게 되든 이것을 패턴으로 간주하세요: 에이전트가 계획할 수 있게 되면, 당신의 일은 단계를 작성하는 것에서 계획을 읽는 것으로 바뀝니다.
목표 모드(objective-mode)를 안전하게 만드는 규칙은 다음과 같습니다: 어떤 목표의 첫 실행도 명령이 아니라 제안입니다. 에이전트가 실행하기 전에, 그 계획을 읽으세요. 무엇을 만질 것이고, 어떤 순서로? 누구에게, 무엇을 보낼 것인가? 당신이 예상하지 못한 하위 태스크는 무엇입니까?
대부분의 첫 번째 계획은 지루한 방식으로 틀립니다 — 잘못된 고객을 우선순위에 두거나, 당신의 지역에서 아무도 사용하지 않는 어조로 초안을 작성할 것입니다. 그것을 잡아내는 데 5분이 걸립니다. 그것을 실행하게 하는 것은 일주일간의 정리 작업과 이상한 이메일을 받은 고객 한 명을 의미합니다. 첫 번째 계획이 검토를 통과한 후에는, 이후 실행에서는 간헐적인 점검(spot-check)만 필요합니다: 주당 20분 동안 실제로 무엇이 나갔는지 읽어보는 것입니다.
에이전트가 자신의 작업에 서명하다
발표된 내용 중 한 가지 세부 사항은 보이는 것보다 더 중요합니다. 바로 Google의 동료 에이전트들이 자체 Workspace 계정(자체 이메일 주소, 캘린더, Drive)을 갖게 되며, 회사 디렉터리에 존재하게 되고, 사람에게가 아닌 해당 에이전트를 지칭하는 감사 추적 기록(audit trail)이 생성된다는 점입니다. 동료들은 그 에이전트와 다른 누구와 일할 때와 똑같이 작업합니다.
브랜딩을 제거하면 그것은 책임 소재 아키텍처(accountability architecture)가 됩니다. 고객이 "왜 제가 이것을 받았나요?"라고 물었을 때, 검사 가능한 답변이 존재합니다. 즉, 어떤 목표였는지, 어떤 규칙이었는지, 어떤 승인이 있었는지를 말입니다. 만약 어떤 스택에서든 위임 습관을 구축한다면, 이 속성을 유지해야 합니다. 모든 에이전트의 행동은 인간이 승인한 서면화된 목표와 경계로 거슬러 올라가야 합니다. 이것이야말로 위임을 부인할 수 있는 것이 아니라 방어 가능하게(defensible) 만드는 요소이며, 다른 모든 것이 변하더라도 살아남는 부분입니다.
모델은 약속이 아닌 구성 요소이다
더 주목할 만한 발표 세부 사항이 하나 더 있습니다. 기본적으로 Google의 에이전트는 작업에 가장 적합한 모델을 선택하며, 사용자는 이를 재정의할 수 있습니다. 여기에는 Anthropic의 Claude를 시작으로 타사 모델을 선택하는 것이 포함됩니다. Google의 에이전트는 Claude의 모델을 구동하고 Slack, Microsoft 365, Jira, Postgres와 연결합니다.
소규모 비즈니스를 위한 실질적인 해석은 이렇습니다. 더 이상 문에 걸린 로고가 작업하는 모델이 아니며, 결코 다시 그럴 일도 없을 것입니다. "올바른" 모델을 선택하는 데 최적화하는 것을 멈추세요. 모든 모델보다 오래 지속되는 계층—즉, 서면 목표, 경계, 계획 검토 습관—에 투자해야 합니다. 이 요소들은 다음 분기에 출시되는 무엇에도 전이될 수 있습니다. 항상 다음 분기가 있기 때문입니다.
목표 모드(objective mode)를 사용해야 할 때와 그렇지 않은 경우
목표 모드(Objective mode)는 명확한 완료 상태(done-state)를 가진 반복적인 업무에서 가치를 발휘합니다: 후속 조치 주기(follow-up cycles), 응답 검토, 보고서 취합, 받은 편지함 분류(inbox triage), 일정 조정 라운드, 공급업체 서류 추적 등입니다. 지시 모드(Instruction mode)는 여전히 일회성 업무, 새로운 상황, 그리고 아무도 그 작업이 실제로 어떻게 수행되는지 문서화하지 않은 모든 경우에 적합합니다. 오직 누군가의 머릿속에만 존재하는 프로세스는 위임할 수 없습니다.
바로 이 점이 실제 도입 순서입니다: 반복적인 워크플로우 하나를 선택하고, 오늘 그것이 어떻게 수행되는지 문서로 작성한 다음, 세 가지 요소가 모두 포함된 목표(objective)로 변환합니다. 그리고 이것이 생성하는 첫 번째 계획을 검토한 후, 주간 단위의 점검으로 실행해 봅니다. 워크플로우 하나입니다. 이것이 전체 계획이며, 에이전트가 Google에서 오든, Microsoft에서 오든, 아니면 20달러짜리 자동화 도구에서 오든 상관없이 동일한 계획입니다.
The AI Agent Owner's Playbook은 이 전 과정을 다룹니다 — 목표 작성 형식(objective-writing format), 권한 사다리(permission ladder), 그리고 계획 검토 체크리스트(plan-review checklist)를 담고 있습니다: The AI Agent Owner's Playbook — 49 CAD, 즉시 다운로드.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기