우리는 계속해서 그것들을 “에이전트 (agents)”라고 부르고 있으며, 소프트웨어처럼 관리하고 있습니다.

그것이 실수입니다.

소프트웨어는 고정된 산출물 (artifact)입니다. 당신은 그것을 디프 (diff)하고, 버전을 매기고, 롤백 (roll back)할 수 있으며, 어제의 빌드 (build)가 오늘의 빌드처럼 동작할 것이라고 신뢰할 수 있습니다. 에이전트는 고정된 산출물이 아닙니다. 그것은 모델 (model), 프롬프트 (prompt), 메모리 저장소 (memory store), 도구 세트 (set of tools), 권한 구조 (permission structure), 그리고 세상에 대한 일련의 가정 (assumptions)들이 실시간으로 결합된 형태입니다. 이 중 그 어떤 것이라도 코드 한 줄 건드리지 않고도 스스로, 조용히 변할 수 있습니다.

이것을 일반적인 배포 (deploy)처럼 취급한다면, 당신은 향후 1년 동안 유령들을 디버깅 (debugging)하며 시간을 보내게 될 것입니다.

이제 개발자들에게 에이전트를 위한 기록 시스템 (system of record)이 필요할 때입니다.

에이전트가 어제와 다르게 오늘 다르게 행동한다면, 그 원인은 코드 디프 (code diff) 안에 깔끔하게 자리 잡고 있는 경우가 거의 없습니다.

그것은 조용히 업데이트된 모델일 수 있습니다. 누군가 슬랙 (Slack) 스레드에서 수정한 프롬프트일 수 있습니다. 상류 (upstream)에서 변경된 도구 스키마 (tool schema)일 수 있습니다. 오래된 메모리일 수 있습니다. 드리프트 (drift)된 검색 인덱스 (retrieval index)일 수 있습니다. 취소된 권한일 수 있습니다. 혹은 단순히 더 이상 사실이 아니게 된 환경적 가정일 수 있습니다.

Git은 코드를 추적합니다.

하지만 Git은 마음 (mind)을 추적하기 위해 만들어진 것이 아닙니다.

그리고 실제로 동작하는 것은 바로 그 마음입니다.

우리는 더 이상 코드를 배포하지 않습니다.

우리는 지능 (intelligence)을 배포합니다.

에이전트 확산 (Agent sprawl)은 빠르게 일어납니다

모든 팀의 에이전트 여정은 기만적일 정도로 깔끔한 방식으로 시작됩니다: 하나의 에이전트, 하나의 워크플로 (workflow), 하나의 모델, 하나의 프롬프트, 하나의 도구 세트.

깔끔하고, 읽기 쉬우며, 제어 가능합니다.

하지만 결코 그 상태로 머물지 않습니다.

다른 팀이 변형을 원합니다. 고객이 커스텀 워크플로를 요구합니다. 기반 모델이 교체됩니다. 도구의 형태가 바뀝니다. 권한이 강화되거나 완화됩니다. 누군가 메모리를 덧붙입니다. 누군가 새로운 환경을 위해 에이전트를 포크 (fork)합니다. 그리고 어딘가에서, 조용히, 오래된 버전이 여전히 실행되고 있습니다—그것이 어디에 있는지, 왜 실행 중인지, 무엇을 하고 있는지 아무도 정확히 기억하지 못합니다.

몇 달 안에, 조직은 당연히 답할 수 있어야 하는 질문들에 답할 능력을 상실하게 됩니다:

• 우리가 실제로 보유한 에이전트(agent)는 무엇인가?
• 각 에이전트는 무엇을 할 수 있는가?
• 어떤 컴포넌트(component)를 안전하게 재사용할 수 있는가?
• 어떤 버전이 프로덕션(production) 환경에서 작동하고 어떤 것이 실패하는가?
• 이 에이전트를 새로운 환경에서도 신뢰할 수 있는가?

에이전트가 유용해지는 순간, 그것들은 인프라(infrastructure)가 됩니다.

그리고 기록 시스템(system of record)이 없는 인프라는 인프라가 아닙니다.

그것은 단지 리스크(risk)일 뿐입니다.

벤치마크(Benchmarks)는 필요하지만, 충분하지는 않습니다

본능적으로 벤치마크(benchmarks)와 보안 테스트(security testing)를 찾게 됩니다.

평가(eval)를 실행하고, 점수를 얻고, 결과가 녹색(green)이면 배포(ship)합니다.

하지만 이러한 방법들은 좁은 질문에만 답합니다: 통과인가 실패인가?

• 에이전트가 그 답을 얻기 위해 무엇에 의존했는지 알려주지 않습니다.
• 이번 실행과 지난 실행 사이에 주변 스택(stack)에서 무엇이 변했는지 알려주지 않습니다.

코드는 Git이 있습니다. 인프라에는 Terraform 상태(state)가 있습니다. 데이터에는 리니지(lineage) 도구가 있습니다.

에이전트에는 그에 상응하는 것이 아무것도 없습니다.

Octo가 이를 바꿉니다.

에이전트가 변경될 때마다, Octo는 전체 에이전트 스택(agent stack)을 캡처합니다:

• 모델 (Models)
• 프롬프트 (Prompts)
• 도구(Tools) 및 MCP 서버
• 메모리(Memory) 및 검색(retrieval)
• 권한 (Permissions)
• 런타임 설정 (Runtime configuration)
• 환경 가정 (Environment assumptions)

단순히 에이전트가 실행된 후의 트레이스(traces)나, 테스트 후의 점수(scores)만이 아닙니다.

에이전트 자체의 실제 배포 가능한 형태(deployable shape)입니다.

무엇이 변했는지 궁금해하는 대신, 팀은 에이전트의 버전 히스토리(version history)를 얻게 됩니다:

• 어떤 고객이 이 버전을 실행하고 있는가?
• 오케스트레이션(orchestration)에서 무엇이 변했는가?
• 왜 이 배포가 갑자기 실패하기 시작했는가?
• 이 에이전트가 새로운 환경으로 안전하게 이동할 수 있는가?
• 새로운 고객을 위한 새로운 장소에서 작동하도록 에이전트를 어떻게 변경해야 하는가?

이러한 질문들은 더 이상 탐정 놀이(detective work)가 아닙니다.

그것들은 평범하게 답변 가능한 엔지니어링 질문이 됩니다.

운영 환경(production)의 장애를 디버깅하는 상황을 상상해 보십시오.

Git에는 코드 변경 사항이 없습니다. 벤치마크(benchmark)는 여전히 통과합니다. 하지만 검색 인덱스(retrieval index)가 드리프트(drift)되었고, 상위(upstream)의 도구 스키마(tool schema)가 변경되었으며, 하나의 권한이 조용히 사라졌습니다.

이 중 어느 것도 코드 차이(code diff)에는 남아 있지 않습니다.

Octo는 저장소(repository)뿐만 아니라 에이전트의 전체 히스토리를 보여줍니다.

우리는 모든 운영 에이전트가 결국 버전 히스토리를 갖게 될 것이라고 믿습니다.

모든 배포는 증거를 지니게 될 것입니다.

모든 재배포는 무엇이 변했는지 이해하는 것에서 시작될 것입니다.

그것이 우리가 향해 구축하고 있는 미래입니다.

오늘, 그 미래는 Octo와 함께 시작됩니다.

선착순 100명의 사용자에게 얼리 액세스(early access)를 개방합니다.

Octo 얼리 액세스 대기 명단에 참여하세요: https://pelagicplatforms.com/octo/waitlists/