실제로 매일 여러 개의 AI 에이전트를 사용하고 계신 분 있나요?

어떻게 하셨는지 좀 알려주실 수 있나요?

현재 세 개의 다른 AI 에이전트를 사용 중인데, 같은 작업에 쓰고 있는 것 같네요. 에이전트 중 한두 개는 WhatsApp의 다른 대화 내용에 접근할 수 있어서, 접근 권한이 없는 에이전트보다 더 자주 쓰게 됩니다.

어떤 게 가장 실용적이고 제 업무 상황에 잘 맞는지 알아내려고 세 에이전트를 서로 경쟁시키고 있어요. 제가 쓰는 세 가지는 다음과 같습니다:

• Instinct

• Pally

• Pho / Fo

두 에이전트가 같은 문서에서 작업하게 했더니 수정 사항이 충돌하더군요. 피하는 유일한 방법은 각자 다른 섹션을 할당하고 병합하기 전에 확인하는 것뿐이었습니다.

소프트웨어 개발에 병렬 에이전트 세션을 사용해 왔지만, 통합을 담당할 명확한 주체 하나를 두는 걸 선호합니다.

작업 트리를 분리하고 책임을 명확히 하는 게 큰 도움이 됩니다. 까다로운 부분은 사실 Git 충돌이 아니에요. 두 에이전트가 같은 아키텍처에 대해 서로 다른 가정을 하고, 둘 다 완벽하게 유효한 코드를 생성하지만 서로 잘 맞지 않을 때가 문제죠.

인간의 통합 검토 없이 에이전트들이 안정적으로 조율하고 변경 사항을 병합하게 만든 사례가 있는지 궁금하네요.

이런 질문들이 좀 의아하네요. Anthropic이나 OpenAI 같은 빅2를 사용하는 사람들은 이미 안정적으로 여러 에이전트를 사용하고 있거든요. 본인만의 로컬 환경을 구축하려는 거라면 질문이 이해가 가지만요. 2026년 말인데.. 다들 여러 AI 에이전트 쓰고 있지 않나요?

저는 여전히 메인 에이전트 하나가 작업을 조율하는 방식을 선호합니다.

네

네, 저는 역할이 정의된 에이전트들을 사용하고 있고, 하나가 오케스트레이터 역할을 하며 프로젝트 계획을 관리합니다. 코딩 에이전트와 인프라 관리 에이전트에게 작업을 넘겨주죠. 코딩 에이전트가 PostgreSQL 데이터베이스로 프로젝트를 테스트해야 하면 인프라 에이전트에게 임시 컨테이너를 띄우라고 요청합니다. 현재 직접 메시징을 위해 A2A를 사용하고 있고, 코딩 프로젝트에서 서로 조율할 수 있도록 로컬 Forgejo 인스턴스도 쓰고 있습니다. Vikunja가 생각만큼 잘 안 돼서, 범용 프로젝트 관리를 위한 저만의 '에이전트 우선' 프로젝트 관리 시스템을 만들려고 노력 중입니다.

저는 코딩 작업에 여러 에이전트를 꽤 자주 사용합니다.

Claude, OpenAI, Google의 Argon 같은 주요 모델들을 메인으로 쓰고, Opencode를 통해서도 다양한 에이전트를 정기적으로 사용하죠.

종종 같은 프로젝트의 여러 기능을 동시에 작업하게 할 때도 있습니다.

처음에는 git-worktrees를 테스트해 봤는데, 실제 개발보다 병합 충돌 해결에 시간을 더 많이 쓰게 돼서 지금은 여러 기능을 하나의 브랜치에서 작업하는 편입니다(지저분한 건 알지만요).

요즘은 레포의 .agents/ 폴더에 계획 섹션을 만들어 둡니다.

기본적으로 마크다운 문서를 사용한 '태스크 보드' 시스템을 통해 작업할 내용을 먼저 계획하는 워크플로우를 가지고 있습니다. 에이전트의 첫 번째 단계는 기능을 명세화하고 태스크 보드 항목을 만드는 거죠. 큰 기능이라면 아키텍처 스킬을 가진 에이전트가 검토를 거쳐 우리 레포 컨벤션에 맞는지 확인합니다. 그다음 순차적인 작업으로 나누고요.

데이터베이스나 데이터 모델 작업은 가장 먼저 합니다. 마이그레이션이 겹치거나 순서가 꼬이면 가장 골치 아프니까요.

기능의 복잡도에 따라 다른 에이전트에게 아키텍처를 먼저 검토하게 하고, 작업을 나누기 전에 다듬기도 합니다.

그다음 해당 기능 담당 에이전트가 올바른 순서대로 작업을 시작합니다.

저는 기본적으로 여러 기능에 대해 여러 에이전트를 돌리며 이 루프를 실행합니다. 레포 전체에 적용되는 몇 가지 규칙이 있어요. 예를 들어, 서로 다른 기능의 데이터베이스 티켓을 동시에 작업하게 하지 않고, 에이전트들이 따라야 할 엄격한 마이그레이션 컨벤션을 가지고 있습니다.

사실 이런 식으로 수많은 기능을 처음부터 끝까지 완벽하게 빌드하는 경우는 거의 못 봤습니다. 기능이 완성되면 다듬는 과정이 필요하거든요. 그래서 기능이 빌드되면 제가 직접 사용해 보면서 UI나 빌드 가정을 다듬는 주기를 몇 번 거칩니다.

세상에서 가장 효율적인 워크플로우는 아닐지 몰라도, 저한테는 꽤 잘 작동하고 있습니다.

네, 매일 사용하지만 주로 Databricks 안에서 씁니다. 파이프라인과 노트북 작업에는 Genie Code를 쓰고, 같은 데이터 위에서 비즈니스 관련 질문을 처리할 때는 Genie Spaces를 씁니다. 이게 가능했던 이유는 같은 Unity Catalog 컨텍스트(같은 테이블, 같은 권한, 같은 계보)를 공유하기 때문에 서로 조율할 필요가 없기 때문입니다. 그래서 Genie Code가 테이블을 수정하거나 컬럼을 추가하면, 제가 따로 전달하지 않아도 Genie Spaces가 바로 알아차리죠.

제가 여전히 직접 조율하는 부분은 범위 설정입니다. 각 에이전트에게 명확한 영역(하나는 빌드 및 수정, 하나는 질문 답변)을 주고, 프로덕션에 영향을 주는 건 실행 전에 제가 직접 검토합니다. 두 에이전트가 같은 것을 자유롭게 수정하게 두는 건 경험상 얻는 것보다 잃는 게 많았습니다.

제가 시도했던 어떤 오케스트레이션 프레임워크보다도, 밑바닥에 깔린 공유 거버넌스 계층이 훨씬 중요했습니다.