AI 실험

AI 에이전트를 Romergo에 초대했는데 이게 뭔지, 뭐라고 불러야 할지 모르겠습니다.

애플리케이션의 AI 통합은 대부분 예측 가능한 방식으로 설계됩니다. 제품은 스파크 버튼을 추가하고, 자체 모델에 요청을 보내고, 사이드바에 응답을 표시합니다.

또 다른 일반적인 옵션이 있습니다. 애플리케이션은 MCP 서버를 제공하고 사용자는 ChatGPT, Claude 또는 다른 에이전트를 열고 애플리케이션 데이터 작업을 요청합니다. 이는 상담원에게 좋은 도구를 제공하지만 대화는 다른 곳에서 이루어집니다. 편집기를 종료하고 현재 열려 있는 내용을 설명하고 다시 전환하여 결과를 확인해야 합니다.

채팅과 편집 사이를 전환하는 데 지쳤고 아이디어가 떠올랐습니다. 이를 완전히 피할 수 있다면 어떨까요?

AI 패널을 에디터에 직접 추가했지만 Romergo에서 호스팅하는 모델에는 연결하지 않았습니다. 대신 사용자는 개인 AI 에이전트를 공개 세션에 초대합니다.

에이전트는 ChatGPT, Claude, Codex 또는 다른 MCP 호환 클라이언트 등 이미 존재하는 위치에 남아 있습니다. 모델, 구독, 메모리, 설정 및 사용 가능한 도구를 유지합니다. Romergo는 프로젝트 편집을 위한 작업 공간, 현재 컨텍스트 및 전문 도구만 제공합니다.

연결 후 사용자는 Builder에서 직접 에이전트에 쓸 수 있습니다.

• 열린 장면을 묘사하십시오.
• 이 장의 음악을 변경하세요.
• 강조 표시된 대화를 다시 작성하십시오.
• 다른 배경을 넣으세요.
• 전환 논리를 확인하십시오.
• 장면이 예상한 대로 작동하지 않는 이유를 설명하세요.

답변, 질문 및 중간 상태가 동일한 패널로 반환됩니다. 패널에는 텍스트뿐만 아니라 전체 작업 주기도 표시됩니다. 즉, 명령 수신, 에이전트에 할당, 도구 실행 중, 확인 필요, 작업 완료 또는 오류 발생 등이 표시됩니다. 더 이상 편집기를 떠날 필요가 없습니다.

실험으로 시작됐는데

나는 새로운 프로토콜을 고안하거나 새로운 제품 카테고리를 내놓을 생각이 전혀 없었습니다. 저는 한 가지 간단한 아이디어를 테스트하고 싶었습니다. 개인 사용자 에이전트가 MCP를 통해 외부에서 Romergo를 제어할 뿐만 아니라 일시적으로 편집기 내부의 라이브 세션에 참여할 수 있습니까?

첫 번째 버전은 실험이었습니다. 놀랍게도 제가 직접 사용할 수 있을 만큼 효과가 좋았습니다.

가장 짧은 다이어그램은 다음과 같이 그릴 수 있습니다.

Personal AI agent  <->  MCP  <->  Romergo Builder

그러나 양방향 표시가 중요합니다.

일반적인 MCP 호출은 에이전트에서 시작됩니다. 에이전트는 애플리케이션에 연결하기로 결정하고 해당 도구를 호출합니다. 내 실험에서 Romergo는 작업을 시작할 수도 있습니다. 사용자는 Builder에서 명령을 작성하고 Romergo는 이를 보안 채널에 배치하며 이미 연결된 에이전트는 MCP를 통해 명령을 받습니다.

그런 다음 에이전트는 일반적인 Romergo 도구를 사용하여 프로젝트를 읽거나 수정하고 동일한 채널을 통해 결과를 Builder에 반환합니다.

그러면 닫힌 루프가 생성됩니다.

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

Romergo는 이러한 단계에서 모델을 실행하지 않습니다.

동시에 MCP 자체를 변경하지 않았고 실제 서버 푸시를 추가하지도 않았습니다. 프로토콜 관점에서 볼 때 모든 통화는 여전히 에이전트에 의해 시작됩니다. 반대 방향은 보안 사서함으로 구현됩니다. 빌더는 명령을 채널에 기록하고 에이전트는 일반적인 긴 폴링 MCP 도구를 통해 이를 기다립니다. 그런 다음 에이전트는 동일한 일반적인 도구 호출을 사용하여 이벤트를 다시 보냅니다.

양방향 동작은 새로운 MCP 전송을 통하지 않고 애플리케이션 세션 수준에서 나타납니다. 이러한 구별은 중요합니다. 현재 구현은 표준 MCP 호출 위에 구축된 소규모 세션 계약으로 가장 잘 이해됩니다.

상담원이 세션에 입장하는 방법

빌더는 임시 채널 코드를 생성합니다. 사용자는 다음과 같은 짧은 시작 프롬프트를 AI 채팅에 복사합니다.

내 Romergo Builder 채널에 가입하세요. 각각의 새 명령을 한 번씩 실행하고 결과나 질문을 Builder로 다시 보낸 다음 명시적으로 중지하라고 요청할 때까지 계속 기다리세요.

그런 다음 에이전트는 MCP 도구 romergo_join_builder_channel을 호출하고 코드를 전달합니다. 이는 핸드셰이크입니다. Romergo는 OAuth 세션, 채널 소유자 및 만료 날짜를 확인한 다음 대화 상태와 마지막 명령 커서를 반환합니다.

다음으로 에이전트는 romergo_wait_for_builder_command를 호출합니다. 이는 편집기의 다음 명령을 기다리는 긴 폴링입니다. 아무것도 도착하지 않으면 에이전트는 커서를 저장하고 다시 대기를 시작합니다. 명령이 존재하는 경우 다음이 포함됩니다.

• 지침 텍스트;
• 명령 ID;
• 단조로운 시퀀스;
• Builder의 현재 경로;
• 열려 있는 프로젝트, 장 및 장면의 ID(URL에 있는 경우)
• 편집기 표면 유형 및 컨텍스트 캡처 시간
• 사용자가 선택한 텍스트(있는 경우)

첨부된 모든 컨텍스트는 신뢰할 수 없는 애플리케이션 콘텐츠로 표시됩니다. 이는 작업을 위한 데이터이며 에이전트의 제어 명령의 연속이 아닙니다.

에이전트는 기존 Romergo MCP 도구를 사용하여 작업을 수행합니다. 예를 들어 프로젝트와 챕터를 읽고, 에셋을 찾고, 장면을 변경한 후 저장된 결과를 확인할 수 있습니다.

작동하는 동안 에이전트는 romergo_report_builder_event를 호출하고 패널에 다음을 보낼 수 있습니다.

• status - 짧은 중간 상태;
• question - 답변 없이는 안전하게 계속할 수 없는 질문;
• reply — 완료된 결과;
• error - 오류에 대한 명확한 설명.

응답은 commandId에 바인딩되고 마지막으로 처리된 시퀀스에서 다음 명령을 읽습니다. 처음 실행되면 API는 client_id OAuth 클라이언트에 명령을 원자적으로 할당합니다. 연결된 다른 에이전트는 동일한 작업을 동시에 선택할 수 없습니다. 커서는 시간 초과 또는 재연결 후에도 계속되는 데 도움이 되며, 특정 도구 호출에 대한 일회성 확인은 인수 지문으로 보호되며 다른 작업에 재사용할 수 없습니다.

권한은 프롬프트가 아닌 방에 속합니다.

연결하기 전에 사용자는 채널 설정을 확인하고 에이전트가 수행할 수 있는 작업(프로젝트 읽기, 콘텐츠 편집, 미디어 및 오디오 작업, 데이터 게시 또는 삭제)을 선택합니다. 이러한 설정은 패널 헤더의 기어를 통해 언제든지 열 수 있습니다.

기본적으로 미디어 읽기, 편집, 작업이 가능하며 사용자의 직접 요청은 이미 이러한 작업을 적용할 수 있는 권한으로 간주됩니다. 게시 및 삭제는 비활성화되고 별도로 활성화됩니다. 원하는 경우 사용자는 더 엄격한 모드를 활성화하고 모든 변경 사항을 다시 확인하거나 게시 및 삭제에 대해서만 확인을 요구할 수 있습니다.

이것은 시작 프롬프트의 단순한 텍스트가 아닙니다. 공통 서버 래퍼는 수정 MCP 도구를 호출하기 전에 범위를 확인합니다. 추가 확인이 활성화되면 Builder는 "한 번 허용" 및 "거부" 버튼을 사용하여 정확한 작업을 표시하는 반면 원래 호출은 계속해서 결정을 기다립니다. 권한은 명령, 도구 및 인수 지문에 바인딩되며 일단 실행되면 더 이상 유효하지 않습니다.

각 수정 도구의 시작, 완료, 오류 및 차단은 자동으로 패널에 반환됩니다. 각 최종 답변에는 상태와 결과에 대한 구체적인 설명이 포함된 구조화된 요약이 포함되어야 합니다. 변경 후 에이전트는 변경된 엔터티, 수행된 검사 및 결과에 대한 링크도 나열합니다. Builder는 응답 텍스트 바로 아래에 이 요약을 표시합니다. 채널은 설정에서 명시적으로 종료될 수 있습니다. 이전 코드는 즉시 작동을 멈춥니다.

Romergo에는 무엇이 있고 사용자에게 남아 있는 것은 무엇입니까?

나는 이 아키텍처를 관심사의 분리로 생각하고 싶습니다.

Romergo는 다음을 제공합니다.

• 편집기 및 시각적 작업 공간;
• 현재 프로젝트, 페이지 및 선택 항목;
• 양방향 의사소통을 위한 임시 공간;
• 프로젝트 읽기, 수정 및 확인을 위한 도메인별 도구
• OAuth, 액세스 권한 및 세션 이벤트 기록
• 사용자가 질문, 진행 상황 및 결과를 볼 수 있는 인터페이스입니다.

사용자 에이전트는 다음을 제공합니다.

• 모델을 만들고 계산합니다.
• 자신의 구독;
• 추론 및 계획;
• 메모리 및 개인화(선택된 에이전트가 제공하는 경우)
• 기타 연결된 도구;
• 사용자에게 친숙한 작업 스타일.

지능은 애플리케이션에 속하지 않습니다. 앱은 이 지능이 안전하게 작동할 수 있는 곳을 만들어줍니다.

일반 내장 부조종사를 만들어 보는 것은 어떨까요?

내장된 AI는 설명하기 쉽고 활성화하기가 더 쉬울 것입니다. 사용자가 버튼을 누르면 애플리케이션이 선택한 모델을 호출하고 모든 것이 작동합니다.

그러나 Romergo는 또한 AI 인프라의 운영자가 되어야 합니다.

• 추론 비용을 지불하거나 계획을 통해 비용을 전달합니다.
• 사용자를 위한 모델을 선택합니다.
• 자신만의 메모리와 개인화를 생성합니다.
• 외부 서비스를 다시 연결합니다.
• 추가적인 민감한 컨텍스트를 저장합니다.
• 수평적 AI 제품의 역량을 끊임없이 따라잡아보세요.

개인 에이전트를 사용할 때 이 모든 것은 이미 사용자 측에 존재합니다. Romergo는 또 다른 ChatGPT를 구축하려고 하지 않습니다. ChatGPT, Claude 또는 다른 상담원에게 특수한 작업 공간과 명확한 도구를 제공합니다.

이는 창의적인 편집자에게 특히 흥미로울 것입니다. 동일한 에이전트는 사용자가 대화를 작성하는 방법, 선호하는 어조, 이미 논의된 참조, 사용하는 외부 도구를 알 수 있습니다. Romergo는 배경 하나를 교체하거나 장면을 재배열하기 위해 이 전체 시스템을 복사할 필요가 없습니다.

가장 이상한 점은 에이전트가 외부에도 있고 내부에도 있다는 것입니다.

에이전트는 물리적으로 Romergo로 이동하지 않습니다. 해당 모델과 에이전트 루프는 원래 AI 클라이언트에서 계속 실행됩니다.

그러나 사용자의 관점에서 보면 에이전트는 편집기 내부에 있습니다.

• 내장 패널로부터 명령을 받습니다.
• 사용자가 어느 페이지에 있는지 알고 있습니다.
• 첨부된 선택 항목을 봅니다.
• 동일한 프로젝트를 변경합니다.
• 동일한 패널에 질문을 하고 답변을 반환합니다.
• 페이지를 전환하거나 다시 연결한 후 대화를 계속할 수 있습니다.

따라서 여기서는 "애플리케이션 내부 AI"와 "MCP를 통한 외부 AI"라는 표현이 모두 정확하지 않습니다. 오히려 애플리케이션 세션에 외부 에이전트가 일시적으로 존재하는 것입니다.

나는 이 방향으로 움직인 최초의 사람이 아니다

실험이 효과가 있은 후 비슷한 접근 방식을 찾기 시작했습니다.

에이전트 클라이언트 프로토콜을 사용하면 Zed 및 JetBrains와 같은 편집자가 외부 코딩 에이전트를 연결할 수 있습니다. Tidewave는 Claude Code, Codex 및 기타 ACP 에이전트를 실행 중인 웹 애플리케이션 옆에 배치하고 브라우저 및 런타임 컨텍스트를 전달합니다. Obsidian Agent Client는 Claude Code, Codex 및 Gemini를 노트 바로 옆에 표시하고 활성 문서와 선택 항목을 자동으로 첨부합니다. marimo은 외부 에이전트에게 라이브 노트북을 공유 작업 공간으로 제공합니다.

더 일반적인 실험도 있습니다. AG-UI는 사용자 인터페이스와 에이전트 백엔드 간의 양방향 통신을 표준화합니다. WebMCP은 웹 페이지가 연결된 브라우저 또는 데스크톱 에이전트에서 사용할 수 있는 도구를 등록하도록 제안합니다. 에이전트 응용 프로토콜은 응용 프로그램이 UI 및 도메인 도구를 소유하고 외부 에이전트가 추론, 기록 및 범용 도구를 소유하는 모델을 설명합니다.

즉, 기본 아이디어는 이미 여러 형태로 존재합니다. 그러나 대부분의 구현은 IDE, 로컬 코딩 에이전트 또는 회사 자체에서 배포하는 에이전트에 중점을 둡니다.

Romergo 실험은 약간 다른 질문 때문에 흥미롭습니다. 개인 사용자 에이전트가 일반 창의적 애플리케이션에 들어갈 수 있다면 어떻게 될까요?

새로운 모델이 아닙니다. 모델에 대한 API 키가 아닙니다. 내장된 부조종사 응용 프로그램이 아닙니다. 사람이 이미 매일 사용하고 있는 에이전트.

편리함은 문제의 절반에 불과하다

외부 에이전트가 애플리케이션 명령을 수신하고 프로젝트를 변경할 수 있게 되면 보안은 더 이상 선택 기능이 아닙니다.

하나의 OAuth 화면으로 답변할 수 없는 질문이 발생합니다.

• 특정 룸에서 사용할 수 있는 페이지와 엔터티
• 확인 없이 어떤 조치가 허용됩니까?
• 프로젝트 텍스트에 프롬프트 삽입이 포함될 수 있습니까?
• 에이전트가 사용자 명령을 신뢰할 수 없는 데이터와 구별하는 방법
• 시간 초과 후 명령은 어떻게 되나요?
• 단지 확실한 텍스트 답변이 아닌 실제 변경 사항을 사용자에게 보여주는 방법
• 세션을 취소하고 에이전트가 실제로 듣기를 중단했음을 증명하는 방법
• 개인 에이전트의 메모리와 외부 연결 중 특정 응용 프로그램에서 사용할 수 있는 부분은 무엇입니까?

현재 버전은 사용자 및 시간별로 채널을 제한하고 OAuth, 서버 범위, 일회성 확인, 원자 명령 청구 및 명시적 수명 주기를 사용합니다. 이것은 여전히 ​​실험이지만 이제 중요한 경계는 에이전트를 위한 지침이 아니라 실행의 일부입니다.

뭐라고 부를까?

아직 최종 타이틀이 없습니다.

Bring Your Own AI는 일반적으로 자체 API 키 또는 모델 선택을 의미합니다. 사용자가 모델뿐만 아니라 메모리, 도구 및 에이전트 루프도 가져오기 때문에 Bring Your Own Agent가 더 가깝습니다. 그러나 BYOA는 실험의 중요한 부분을 설명하지 않습니다. 애플리케이션은 에이전트에 연결하고 라이브 세션을 유지할 수도 있습니다.

아마도 이것은 다음과 같습니다:

• 라이브 에이전트 채널;
• 애플리케이션-에이전트 세션;
• 에이전트 존재층;
• 개인 에이전트 브리지;
• 양방향 MCP;
• 아니면 기존 아이디어 위에 성공적인 실험을 했을 수도 있습니다.

이름만으로 새로운 기준을 제시하고 싶지는 않습니다. 첫째, 그러한 모델이 Romergo 외부에서 유용한지, 그리고 이를 신뢰하려면 어떤 경계가 필요한지 이해하는 것이 더 중요합니다.

애플리케이션에는 기본 AI가 필요하지 않을 수 있습니다.

오늘날 거의 모든 제품은 자체 어시스턴트를 구축하려고 합니다. 결과적으로 사용자는 많은 별도의 AI를 갖게 됩니다. 하나는 편집기에, 다른 하나는 메일에, 세 번째는 작업 시스템에 있습니다. 각각은 고유한 짧은 기억, 고유한 한계 및 고유한 가격을 가지고 있습니다.

또 다른 가능한 모델이 있습니다.

이 앱은 작업 공간, 라이브 컨텍스트 및 특수 도구를 제공합니다. 사용자는 이미 신뢰하는 에이전트를 불러옵니다. 작업하는 동안 에이전트는 애플리케이션에 참여하여 작업 완료를 돕고 사용자와 함께 떠납니다.

이것이 독립된 건축 카테고리가 될지는 아직 모르겠습니다. 하지만 이제 나는 그러한 사이클을 조립할 수 있고 실제로 사용할 수 있다는 것을 알고 있습니다.

하지만 나는 실험이 매우 재미있다는 것을 알고 있습니다.

개발 블로그로 돌아가기