코딩 AI 에이전트가 지식 작업 에이전트보다 뛰어난 이유

AI 에이전트는 현재 주로 소프트웨어 엔지니어링 분야에서 상당한 발전을 보여주고 있습니다. 오늘날 대부분의 에이전트 도구 사용은 이 분야에 집중되어 있으며, 다른 유형의 작업은 훨씬 뒤처져 있습니다. Composio의 CTO인 Karan Vaidya는 이러한 격차를 AI 에이전트 개발의 현재 상태를 이해하는 데 중요한 영역으로 지적합니다.

Git, CI/CD, 린터와 같은 시스템은 이미 자동화를 위해 설계되어 코딩 환경이 본질적으로 '에이전트 준비' 상태였습니다. Karan Vaidya는 이러한 기존 인프라가 AI 에이전트가 코딩 도메인에서 번성할 수 있도록 한 요소라고 강조합니다.

이러한 기초 요소를 구축하는 것은 소프트웨어 개발을 넘어 AI 에이전트 기능을 확장하는 데 중요합니다. 이러한 중요한 기둥 중 첫 번째는 중앙화입니다.

반대로 지식 작업은 Salesforce, Notion, Slack과 같은 수많은 애플리케이션에 중요한 데이터가 분산되어 매우 파편화되어 있습니다. 이러한 분산으로 인해 지식 작업 에이전트는 흩어진 정보를 수동으로 조립하는 데 상당한 시간과 노력을 소비해야 하므로 효율성이 저해됩니다. 통합된 진실의 원천이 없으면 에이전트는 다양한 플랫폼에서 복잡한 작업을 효과적으로 수행하는 데 어려움을 겪습니다.

코딩에서는 Git이 모든 변경 사항에 대한 완전한 역사적 기록을 자동으로 제공하여 에이전트가 과거 결정을 이해하고 오류를 되돌릴 수도 있게 합니다. 이 내장된 기록은 에이전트의 학습 및 적응 능력에 매우 중요합니다. 그러나 지식 작업은 일반적으로 이러한 포괄적인 기록이 부족하여 에이전트가 새로운 작업마다 백지 상태에서 시작해야 하며 이전 경험을 활용할 수 없습니다.

지식 작업 환경의 정보는 종종 수백 가지의 다른 애플리케이션에 분산되어 있습니다. 결정적으로, 이러한 애플리케이션 중 어느 것도 작업이나 데이터에 대한 통합된 기록을 유지하지 않습니다. 결과적으로 지식 작업에서 작동하는 에이전트는 기억력이 부족하며 거의 매번 백지 상태에서 시작해야 하므로 과거의 성공이나 실패로부터 배울 수 없습니다.

에이전트가 지식 작업 환경에서 작업을 완료할 때, 단순히 성공을 보고할 뿐 자신의 행동에 대한 검증 가능한 기록을 제공하지 않습니다. 작업이 실제로 올바르거나 효과적으로 수행되었는지 확인하는 내장된 메커니즘이 없습니다. 이러한 명확한 작업 기록의 근본적인 부재는 에이전트에게 책임을 묻거나 그들의 결과물을 신뢰하기 어렵게 만듭니다.

중앙화된 로깅은 에이전트가 수행하는 모든 작업(접촉한 모든 애플리케이션에 걸쳐)을 기록할 수 있게 합니다. 여기에는 에이전트가 상호 작용한 것, 건너뛴 것, 그리고 궁극적으로 성공하거나 실패한 것이 포함됩니다. 이 포괄적인 로깅 시스템은 에이전트에게 필수적인 기억력을 제공하여 성공적인 작업 패턴을 이해하고 복제할 수 있게 합니다. 또한 이러한 로그는 사용자에게 중요한 투명성을 제공하여 프로세스 초기에 오류를 식별하고 해결하여 에이전트 성능에 대한 더 큰 신뢰를 조성할 수 있게 합니다.

'지도'는 플랫폼의 아키텍처와 정보가 다른 구성 요소 간에 어떻게 흐르는지를 나타내며, 시스템에 대한 객관적인 이해를 제공합니다. '스타일'은 회사의 특정 선호도와 암묵적인 규칙, 예를 들어 린터에 의해 강제되는 코딩 표준이나 선호하는 데코레이터와 같이 해당 조직 내에서 '좋은 것'이 무엇인지를 지시하는 것을 의미합니다. 코딩 에이전트는 이러한 두 가지 차원을 코드베이스에서 직접 자연스럽게 접근하여 기능뿐만 아니라 원하는 운영적 뉘앙스도 이해할 수 있습니다.

중앙화된 로깅은 조직이 어떻게 운영되는지에 대한 상세한 지도를 효과적으로 생성하여 성공적인 접근 방식을 추출하고 일반적인 실패 모드를 식별합니다. 이 시스템은 도구가 일반적으로 작동하는 방식, 회사가 해당 도구를 특정하게 활용하는 방식, 그리고 개별 사용자 선호도라는 세 가지 다른 수준에서 작동합니다. 이 포괄적인 운영 정보를 캡처함으로써 에이전트는 더 이상 조직의 선호도를 추측할 필요가 없으며, 회사 표준 및 개별 사용자 요구에 맞춰 행동을 더욱 정확하게 조정할 수 있습니다.

에이전트가 코드를 작성하는 순간, 일련의 자동화된 검사가 즉시 뒤따릅니다. 단위 테스트는 작고 지역적인 실수를 잡아내고, 통합 테스트는 하위 구성 요소에 영향을 미치는 오류를 식별합니다. 컴파일러와 린터는 구조적 및 스타일적 표준을 강제하여, 에이전트가 미리 정의된 기준에 대해 자체 출력을 검증할 수 있는 폐쇄 루프를 생성하여 신뢰성을 크게 향상시킵니다.

실제 시나리오에서 자율 에이전트는 종종 비참한 결과를 초래하는데, 이는 현재의 테스트 방법이 행동의 필요성이나 적절성을 검증하지 못하기 때문입니다. 예를 들어, AI 에이전트가 기술적으로 유효한 실제 주소로 이메일을 보낼 수 있지만, 그 행동이 애초에 발생했어야 했는지 의문을 제기하는 테스트가 없었기 때문에 사용자의 평판에 치명적인 손상을 입힐 수 있습니다. 견고한 내부 검증이 없으면 인터넷 자체가 피드백 루프가 되며, 종종 피해가 이미 발생한 후에야 나타납니다. 행동의 진정한 영향과 의도를 평가하는 이러한 간극은 제어된 코딩 환경 외부에서 에이전트가 현재 배포되는 방식의 중요한 결함을 강조합니다.

AI 에이전트를 제어하는 데 프롬프트에만 의존하는 것은 불충분합니다. Meta의 AI 정렬 책임자조차도 취약한 프롬프트 기반 제약으로 인해 200개의 중요한 이메일을 실수로 잃었습니다. 이와 대조적으로 소프트웨어 개발은 Git 브랜치와 코드 소유자를 통해 구조적 거버넌스를 사용하여 에이전트 행동의 파급 효과를 제한하고, 변경 사항이 검토되고 승인되도록 합니다. 진정한 거버넌스는 쉽게 우회될 수 있는 단일 게이트가 아닌, 에이전트 주변에 여러 겹의 제약과 구조적 장벽을 요구합니다. 이러한 견고한 경계의 본질적인 부족은 지식 작업 에이전트를 신뢰하기 어렵게 만드는데, 이는 그들이 코딩 에이전트보다 본질적으로 나쁘기 때문이 아니라 이러한 보호 조치가 없는 환경에서 작동하기 때문입니다.

다양한 애플리케이션의 현재 권한 시스템은 AI 에이전트의 강력한 거버넌스를 강제하기에는 너무 파편화되고 분산되어 있습니다. 취약한 프롬프트에 의존하는 대신, 에이전트가 접근하고 수행할 수 있는 것에 대한 결정론적 제어가 필수적입니다. 이는 에이전트의 메모리 외부에서 경계를 정의하여, 예를 들어 채용 에이전트는 이메일만 읽을 수 있고, 지원 에이전트는 이메일을 작성할 수는 있지만 보낼 수는 없도록 보장하는 것을 의미합니다. 이러한 적절하게 범위가 지정된 접근은 에이전트가 부주의하게 또는 의도적으로 중요한 운영 라인을 넘어서는 것을 방지하여 훨씬 더 강력한 제어 및 보안 계층을 제공합니다.

하나는 에이전트가 도달할 수 있는 범위에 대한 것이고, 다른 하나는 해당 범위 내에서 에이전트가 어떻게 행동할 수 있는지에 대한 것입니다. 자연어 정책을 사용하여 에이전트 작업을 제어할 수 있으며, 이메일 삭제 제한이나 특정 도메인 접근 제한과 같은 예방 규칙을 지정할 수 있습니다. 이러한 결합된 접근 방식은 에이전트가 단순히 행동하도록 요청하는 것이 아니라 에이전트가 할 수 있는 것을 강제함으로써 진정한 거버넌스를 보장하여 안전과 신뢰성을 향상시킵니다.

마지막 기둥은 되돌리기입니다. 이것은 일이 잘못될 경우 중요한데, 행동을 취소할 수 있는 능력입니다. 코딩에서는 거의 모든 변경 사항이 기록되고 되돌릴 수 있으므로 실험하고 실수를 수정하는 것이 비교적 안전합니다. 이와 대조적으로 지식 작업의 많은 행동(예: 이메일 삭제 또는 송금 시작)은 영구적이며 '실행 취소' 버튼이 없습니다. 되돌리기의 이러한 근본적인 차이는 위험 프로파일을 크게 변경하여 지식 작업을 코딩보다 본질적으로 덜 용서하는 작업으로 만듭니다.

코딩에서는 '사후 신뢰'라는 개념이 있습니다. 즉, 작업을 실행하고 확인하며 필요한 경우 되돌릴 수 있습니다. 그러나 지식 작업에서는 대부분의 행동에 실행 취소 버튼이 없어 오류가 거의 되돌릴 수 없습니다. 이러한 되돌리기의 부재는 전체 방정식을 크게 변경하여 실패의 '폭발 반경'을 확장하고 지식 작업의 실수를 코딩의 실수보다 훨씬 더 위험하게 만듭니다.

이메일을 영구적으로 제거하는 하드 삭제와 같이 지식 작업에서 되돌릴 수 없는 행동과 관련된 위험을 완화하려면 샌드박스가 중요합니다. 에이전트는 먼저 샌드박스 환경 내에서 행동을 수행하여 사용자가 프로덕션 환경으로 푸시하기 전에 이를 검토하고 승인할 수 있도록 합니다. 이 접근 방식은 타이밍 모델을 역전시켜 오류가 발생한 후에 반응하는 것이 아니라 실제 결과가 발생하기 전에 실수를 선제적으로 감지하고 수정할 수 있도록 합니다.