팀 전체에 대여섯 개의 AI 에이전트를 배포하고 나면, 기묘한 일이 발생합니다. 금요일 오후, 배포일입니다. PM은 자신들의 AI가 변경 영향도를 요약했다고 말합니다. 개발자는 자신들의 AI가 코드를 리뷰했고 아무것도 발견하지 못했다고 말합니다. QA는 자신들의 AI가 테스트 스위트 (test suite)를 실행했고 모든 것이 통과되었다고 말합니다. 그러다 운영 환경 (production)이 깨집니다. 로그를 뒤져봐도 보이는 것은 "시스템 호출 (system call)"뿐입니다. 어떤 에이전트가, 언제, 어떤 컨텍스트에서, 누구를 대신하여 어떤 호출을 했는지 알 방법이 없습니다. 세 명의 에이전트가 하나의 서비스 계정 (service account)과 하나의 API 키를 공유하며, 책임 소재는 전혀 없습니다. 결국 인간이 책임을 지게 되지만, 심지어 누구와 이야기해야 할지도 파악할 수 없습니다.

이것은 사고 실험이 아닙니다. 정체성 (identity)에 대해 고민하지 않고 기존 인프라에 AI 어시스턴트를 덧붙일 때 실제로 일어나는 일입니다. API 크레딧을 대량으로 구매하고, 서비스 계정을 생성하고, 팀 전체가 공유하면 끝입니다. 한 사람이 자신의 업무를 위해 하나의 어시스턴트를 사용할 때는 문제가 없습니다. 하지만 여러 에이전트가 서로 다른 역할로 병렬 실행되는 순간 시스템은 무너집니다.

권한 (Permissions)이 가장 먼저 무너집니다. 경쟁 조사 에이전트는 모든 프로젝트 채널의 토론에 접근할 수 있어야 합니다. 코드 리뷰 에이전트는 PR (Pull Request)과 저장소 (repository) 메시지만 볼 수 있어야 합니다. 서비스 계정 모델에서는 이러한 구분이 존재하지 않으며, 단 하나의 이진 스위치(binary switch)만 존재합니다: 접근 가능 또는 접근 불가. 팀들은 수동으로 그룹을 생성하고, 메시지를 전달하며, 권한 경계 (permission boundaries)를 직접 설정함으로써 이를 우회합니다. 에이전트가 늘어날수록 이러한 수동 격리 방식은 균열이 생기기 시작합니다. 우리가 대화해 본 일부 팀들은 에이전트의 가시성을 제어하기 위해 12개 이상의 별도 그룹을 만들게 되었고, 인간이 그 사이에서 메시지 라우터 (message router) 역할을 수행하게 되었습니다. 그 시점에서 AI는 오히려 일을 더 느리게 만들고 있습니다.

업무 이력 (work history) 문제는 더욱 구체적입니다. 팀에 합류한 지 3개월 된 엔지니어라면, 그가 무엇을 잘하는지, 어떤 부분에서 부주의한지, 지난 스프린트에서 어떤 모듈을 완벽하게 처리했는지 알 수 있습니다. 다음에 업무를 할당할 때, 당신은 그 정보를 활용합니다. 반면 100개의 작업을 수행한 에이전트의 경우, 완료율 (completion rate), 거절 횟수 (rejection count), 잘 처리하는 작업 유형 등 모든 정보가 집계되지 않은 채 채팅 로그에 흩어져 있습니다. 에이전트에게 코드 리뷰 작업을 할당하는 것은 본질적으로 동전 던지기와 같습니다. 하나의 프로젝트에서 세 명의 에이전트가 병렬로 작동하며, 한 명은 리서치를 하고, 한 명은 제안서를 초안 작성하며, 한 명은 테스트를 실행하고 있을 때, 리더는 지난번에 누가 품질을 제대로 제공했는지, 혹은 누가 두 번이나 반려되었는지에 대한 데이터가 전혀 없습니다. 그들은 모두 똑같은 기본 아바타를 가지고 있습니다.

Octo는 우리가 AgentCard라고 부르는 것으로 이 문제를 해결합니다. 각 에이전트는 생성 시 AgentCard를 부여받으며, 여기에는 생성자, 소유자, 마운트된 기술 (mounted skills), 런타임 유형 (runtime type), 과거 작업 횟수, 거절 횟수, 그리고 작업 유형별 강점이 기록됩니다. 이 필드들은 한 번 설정되고 고정되는 것이 아닙니다. 에이전트가 업무를 수행함에 따라 업데이트됩니다. 엣지 케이스 (edge cases)를 놓쳐 세 번이나 반려된 에이전트는 그 기록이 카드에 남습니다. 반면 데이터 분석 작업을 연속으로 다섯 번 완벽하게 수행한 에이전트는 자연스럽게 유사한 작업의 최우선 후보로 떠오릅니다. 업무 할당이 추측에서 데이터 기반의 판단으로 바뀌는 것입니다. 단순한 아이디어지만, 이를 실행하는 협업 플랫폼은 매우 드뭅니다.

권한 (Permissions)은 별도의 에이전트 IAM 계층이 아닌 소유권으로부터 흐릅니다. 에이전트의 유효 권한은 소유자의 권한과 현재 워크스페이스에서의 역할의 교집합입니다. 인턴의 에이전트는 인턴 본인이 접근할 수 없기 때문에 프로덕션 설정 (production configs)을 건드릴 수 없습니다. 모든 작업은 특정 개인으로 추적되므로, 추가적인 설계 작업 없이도 감사 (audit) 요구 사항을 충족합니다. 에이전트가 특정 Loop (구조화된 작업 단위인 당사의 용어)에 할당되면, 해당 에이전트는 워크스페이스 내의 다른 작업이 아닌 해당 Loop 내의 정보만 볼 수 있습니다. 이 경계는 작업 수준 (task level)에서 강제됩니다.

우리는 의도적으로 KPI 점수 산정 시스템을 구축하지 않았습니다. Octo의 피드백 메커니즘은 의도적으로 가볍게 설계되었습니다. 결과물(deliverable)을 검토할 때, 승인하거나 다시 돌려보낼 수 있으며, 다시 돌려보낼 때는 반드시 이유를 기재해야 합니다. "예외 케이스가 포함되지 않음" 또는 "결론에 데이터 근거가 부족함"과 같은 내용이 Loop에 첨부되며, 에이전트는 다음 유사한 작업 시 해당 피드백을 읽습니다. 이는 사람들이 공식적인 교육 세션이 아니라, 실제 업무를 수행하고 수정을 거치며 배우는 방식과 유사합니다. 시스템이 더 오래 운영될수록, 에이전트는 팀의 코드 컨벤션 (code conventions), 출력 형식 선호도, 승인 기준을 더 잘 이해하게 됩니다. 이는 더 긴 시스템 프롬프트 (system prompt)를 작성한다고 해서 얻을 수 있는 것이 아닙니다. 프롬프트는 정적이지만, 피드백은 축적되기 때문입니다.

에이전트에게 정체성 (identity)과 작업 이력 (work history)을 부여하는 것은 AI에 기업의 인사 관리 (HR) 관료주의를 적용하는 것처럼 들릴 수 있으며, 불필요한 구조를 추가하는 것에 대해 자연스러운 회의론이 존재할 수 있습니다. 하지만 실제로는 그 반대입니다. 정체성은 단순히 통제를 위한 것이 아닙니다. 정체성이 없다면 권한 경계 (permission boundaries)는 모호하게 유지되고 보안 리스크는 높게 유지됩니다. 작업 이력이 없다면 모든 에이전트 할당은 도박이 되며 과거의 성능 데이터는 낭비됩니다. 피드백 축적이 없다면, 매번 동일한 선호도를 다시 가르쳐야 합니다. 이러한 문제들은 단일 어시스턴트와 채팅할 때는 나타나지 않습니다. 하지만 에이전트들이 여러 역할을 넘나들며 업무를 수행하고, 결과물을 책임지며, 프로덕션 (production) 환경에서 운영을 실행하는 순간 나타납니다. 그 시점에서 정체성은 있으면 좋은 기능 (nice-to-have)이 아니라, 인프라 (infrastructure)입니다.

Octo는 GitHub에서 Apache 2.0 라이선스 하에 오픈 소스로 공개되어 있으며, 프라이빗 배포 (private deployment)를 지원합니다. 이 플랫폼은 에이전트 정체성, Loop 작업 단위, 피드백을 통한 선호도 축적, 그리고 6가지 협업 모드 (Pipeline, Critic, Split, Roundtable, Solo, Swarm)를 중심으로 구축되었습니다. 웹, 데스크톱, 모바일, 브라우저 확장 프로그램 및 CLI에서 사용할 수 있습니다.

Repo: https://github.com/Mininglamp-OSS/octo-server