top of page

Meta Thin Orchestrator: 라우터의 업무를 줄이면 에이전트 신뢰성이 높아지는 이유

2시간 전
9분 분량

Meta는 중앙 조정자에서 도메인 추론을 제거한 뒤 AI 에이전트의 신뢰성이 높아졌다고 말한다. Meta thin orchestrator는 더 제한된 역할의 컴포넌트, 즉 작업을 배정하는 라우터에 책임을 맡기고 전문 에이전트가 기술적 결정을 처리하도록 한다.

이 구분은 익숙한 설계 본능에 도전한다. 에이전트가 실수하면 개발자는 흔히 더 많은 문서, 더 많은 예시, 또는 더 상세한 지침을 제공한다. 하지만 정보를 추가하면 서로 충돌하는 규칙도 늘어난다. 시스템은 올바른 답을 가지고 있으면서도 이를 잘못된 곳에 적용할 수 있다.

핵심 긴장은 모든 것을 이해하는 조정자와 책임이 엄격히 제한된 조정자 사이에 있다. Anthropic은 유용한 비교 사례를 제공한다. Anthropic의 연구 시스템은 주도 에이전트에게 조사 계획을 세울 재량권을 부여한다. 특히 소프트웨어가 이미 필요한 순서를 알고 있을 때, 그 재량권이 어디에서 가치를 발휘하는지가 관건이다.

Meta가 파이프라인 에이전트에서 바꾼 점

중요한 아키텍처 변경은 의사결정 권한이 어디에 놓이느냐에 있다.

Meta는 10월 19일 공개한 thin orchestrator architecture에서 추천 시스템용 데이터 열 온보딩을 자동화한 사례를 설명한다. 이 구현은 도메인 작업을 수행하지 않는 1,300줄 규모의 오케스트레이터를 사용해 14개의 전문 에이전트로 20개가 넘는 워크플로를 조정한다. 회사는 구성 준비 시간이 수작업으로는 3~4일, 이전 시스템에서는 약 하루가 걸렸지만 이제 한 시간 이내로 줄었다고 말한다. 변경 사항의 약 3분의 2는 상당한 사람의 수정 없이 반영된다. 이는 독립적으로 검증된 성능 측정치가 아니라 회사가 보고한 결과다.

이 수치는 범위가 정해진 엔지니어링 작업을 필요한 단계에 따라 처리한다는 유용한 운영 목표를 보여준다. 이를 자율 소프트웨어 개발 전반에 관한 주장으로 확대해서는 안 된다. 변경 사항 준비, 검토, 배포, 운영은 여전히 서로 다른 활동이다.

이 구분은 독자가 속도를 해석하는 방식도 바꾼다. 자동화된 준비에 한 시간이 걸린다고 해서 요청부터 신뢰할 수 있는 프로덕션 동작까지 한 시간이 걸린다는 뜻은 아니다. 검토 대기열, 통합 문제, 배포 일정은 측정 대상 활동 밖에 있을 수 있다.

그 경계 안에서도 준비 시간은 중요하다. 엔지니어가 익숙한 변경 사항을 조립할 때까지 기다리는 작업은 이후의 모든 과정을 지연시킬 수 있다. 이 부담을 줄이면 시스템이 이후 모든 결정의 책임을 떠맡지 않아도 가치를 만들 수 있다.

아키텍처의 질문은 조정자가 작업을 진행하려면 기술적 판단이 필요한가 하는 점이다. 워크플로가 이미 다음으로 허용된 단계를 지정한다면, 모델에게 그 단계를 다시 찾아내도록 요구하는 일은 또 다른 오류 기회를 만든다.

명시적 규칙에 따라 작동하는 결정론적 컴포넌트는 근본적인 엔지니어링 문제를 해석하지 않고도 순서를 강제할 수 있다. 이 컴포넌트의 책임은 전제조건이 갖춰졌는지, 그리고 이전 단계가 적절히 완료됐는지를 확인하는 일이 된다.

이는 코드가 어떻게 바뀌어야 하는지 결정하는 것보다 더 좁은 업무다. 또한 조정자를 평가할 더 명확한 기준을 제공한다. 전문 에이전트의 기술적 답변에는 더 깊은 검토가 필요하더라도, 검토자는 조정자가 허용된 경로를 따랐는지 확인할 수 있다.

따라서 이 뉴스의 가치는 더 빠른 준비에만 있지 않다. Meta의 설명은 실질적인 아키텍처 과제를 제기한다. 중앙 모델에 맡기는 각각의 결정을 정당화해야 한다는 것이다. 조정자의 정보 접근 범위는 시스템 역량과 함께 자동으로 커지기보다 그 책임을 따라야 한다.

엔지니어링 리더에게는 구매 평가의 질문도 달라진다. 에이전트가 작업을 완료하는 시연보다, 각 중요한 결정을 어떤 컴포넌트가 내렸는지 보여주는 기록이 더 많은 것을 드러낸다.

모든 것을 아는 조정자를 구축하는 팀에 가해지는 압력

중앙 에이전트의 폭넓은 지식은 왜 그 지식이 필요한지 설명해야 할 의무를 만든다.

즉각적인 압력은 서로 다른 관례를 가진 시스템 전반에서 내부 자동화를 구축하는 팀에 가해진다. 설득력 있는 시연은 익숙하지 않은 입력이 같은 워크플로에 들어왔을 때만 드러나는 모호성을 감출 수 있다.

한 서비스의 기존 필드와 유사해 보이는 필드가 포함된 예시 온보딩 요청을 생각해 보자. 범용 에이전트는 익숙한 패턴을 알아보고 이를 재사용할 수 있다. 까다로운 질문은 그 패턴이 현재 서비스에 속하는가이다.

이는 단순한 정보 부족이 아니라 해석의 문제다. 두 서비스의 문서를 모두 제공해도 어떤 관례가 요청을 지배하는지는 정해지지 않는다. 시스템은 변경을 생성하기 전에 그 관계를 확립해야 한다.

변경 사항도 작성하는 조정자는 두 책임을 모두 떠안는다. 결과가 실패하면 조사자는 분류, 해석, 구현, 검증 중 어디에서 실수가 발생했는지 판단해야 한다.

이 책임을 분리하면 점검할 지점이 늘어난다. 그것이 정확성을 보장하지는 않지만, 실패 설명을 더 구체적으로 만들 수 있다. 팀은 전문 에이전트의 추론을 논의하기 전에 요청이 올바른 전문 에이전트에게 전달됐는지 물을 수 있다.

근본적인 우려에는 연구 선례가 있다. long-context retrieval에서 Nelson F. Liu와 동료들은 정보 배치가 질의응답 및 검색 작업의 성능에 영향을 미친다는 사실을 발견했다. 긴 입력의 중간에 있는 관련 자료는 연구 대상 모델이 활용하기 더 어려운 경우가 많았다.

이 연구가 현재의 모든 모델 동작을 입증하는 것은 아니다. 또한 Meta의 구현을 독립적으로 검증하지도 않는다. 다만 더 좁은 교훈은 여전히 관련이 있다. 정보를 받아들이는 능력과 정보를 신뢰성 있게 적용하는 능력은 다르다.

기업 구매자에게 이 구분은 시스템이 얼마나 많은 자료를 받아들일 수 있는지로 주로 평가할 때의 약점을 드러낸다. 저장 용량과 입력 길이는 특정 행동에 올바른 지침이 적용되는지를 설명하지 못한다.

더 유익한 시연에는 충돌하는 관례, 불완전한 요청, 이전에 완료된 작업이 포함될 것이다. 이러한 사례는 시스템이 모호성을 해소하는지, 설명을 요청하는지, 아니면 근거 없는 가정에 따라 진행하는지를 보여준다.

따라서 지식 구성은 운영 설계의 일부가 된다. 검색 가능한 지식 기반을 유지하는 팀은 문서와 그 문서가 설명하는 시스템 간 관계를 보존해야 한다는 관련 과제에 직면한다.

자동화에서는 그 관계가 행동으로 이어지는 인계 과정에서도 유지돼야 한다. 기술적으로 정확한 지침도 현재 리포지터리, 환경 또는 요청에는 부적절할 수 있다.

따라서 단기적 대응은 프롬프트를 줄이는 일보다 더 구체적이어야 한다. 팀은 폭넓은 이해가 필요한 결정과 알려진 조건에 대한 신뢰할 수 있는 확인만 필요한 결정을 구분해야 한다.

이 작업은 아키텍처 자체에 압력을 가한다. 지침 하나를 더하는 일은 쉽지만, 중앙 에이전트가 그에 상응하는 책임을 가져야 한다는 점을 입증하려면 더 세심한 검토가 필요하다.

Meta Thin Orchestrator가 오류 표면을 바꾸는 방식

조정자의 책임을 줄이면 오류가 발생할 수 있는 지점과 그 오류가 전파될 수 있는 범위가 바뀐다.

Meta thin orchestrator를 유용하게 해석하는 방법은 오류가 유입될 수 있는 지점들의 집합, 즉 오류 표면의 변화로 보는 것이다. 그 중요성은 도메인 결정에 대한 중앙 컴포넌트의 권한을 줄이는 데서 나온다.

조정자는 이후의 모든 단계에 영향을 미치는 실수를 할 수 있다. 부적절한 경로를 선택하면 유능한 전문 에이전트조차 잘못된 작업에 대해 훌륭한 답을 낼 수 있다.

그래서 라우팅 품질은 유난히 중요하다. 하위 단계의 결과물이 내부적으로 일관돼 보일 수 있으므로 라우팅 오류는 발견하기 어렵다. 잘못된 전문 에이전트도 그럴듯하게 유효한 작업을 만들어낼 수 있다.

명시적 워크플로는 조사자에게 다른 기준점을 제공한다. 모델이 왜 그 경로를 적절하다고 판단했는지 재구성하는 대신, 선택된 경로를 문서화된 규칙과 비교할 수 있다.

그러나 명시적 규칙이 모호한 요청을 사라지게 하지는 않는다. 요청에 대상 환경이 빠져 있거나 여러 범주에 속하는 작업을 설명할 수 있다. 분류가 불확실한 상태로 남을 때 시스템이 어떻게 대응할지 여전히 정의해야 한다.

핵심 구분은 불확실성이 드러나는가에 있다. 워크플로는 필수 필드가 누락돼 중단될 수 있다. 반면 범용 조정자는 그 필드를 추론해 계속 진행하면서, 중요한 가정을 감춘 채 겉보기 진전을 만들 수 있다.

중단에는 운영 비용이 따른다. 사용자는 다른 질문에 답해야 하고 완료까지 더 오래 걸린다. 하지만 눈에 보이는 중단은 변경 사항이 쌓인 뒤 발견되는 숨겨진 가정보다 평가하기 쉽다.

검증에도 유사한 구분이 있다. 전문 에이전트는 자신의 출력이 왜 올바른 것으로 보이는지 설명할 수 있지만, 그 설명이 자동으로 다음 단계를 승인해서는 안 된다.

별도의 검증에는 관찰 가능한 조건이 필요하다. 그 조건은 아티팩트의 존재, 빌드 결과 또는 필요한 승인의 존재와 관련될 수 있다. 이는 Meta의 구현에 관한 주장이 아니라 예시 검증 항목이다.

가치는 설득과 권한을 분리하는 데 있다. 유창한 성공 설명이 필요한 조건이 충족됐다는 증거를 대체해서는 안 된다.

이 경계는 더 작은 책임이 유지보수성을 높일 수 있는 이유도 설명한다. 워크플로가 실패했을 때 팀은 더 집중된 질문을 조사할 수 있다. 경로, 전문 에이전트의 작업, 수용 조건을 각각 검토할 수 있다.

이 이점은 인계 과정이 명확하게 유지되는 경우에만 성립한다. 불완전한 요청을 받은 전문 에이전트는 추측으로 보완할 수 있다. 모호한 완료 메시지를 받아들이는 조정자는 너무 일찍 다음 단계로 진행할 수 있다.

즉, 인터페이스는 지침만큼 중요하다. 수신 컴포넌트는 행동하기에 충분한 정보를 받아야 하며, 조정 컴포넌트는 완료를 인식할 신뢰할 수 있는 방법을 가져야 한다.

따라서 이 아키텍처는 엔지니어링 노력을 책임과 수용 조건의 정의로 옮긴다. 그 노력을 없애지는 않는다. 대신 이를 더 명시적으로 만들고, 잠재적으로 더 쉽게 점검할 수 있게 한다.

이 설계를 평가하는 독자에게 중요한 질문은 각 경계가 모호성을 줄이는가이다. 모든 인계가 여전히 자유 형식의 주장을 해석하는 데 의존한다면, 많은 전문 에이전트가 담긴 다이어그램도 거의 안심거리가 되지 못한다.

Anthropic이 사고하는 조정자가 여전히 적합한 지점을 보여주는 방식

가장 강력한 비교는 어느 회사의 에이전트 아키텍처가 더 나은지가 아니라 작업의 예측 가능성에 관한 것이다.

Anthropic은 이전의 agent workflow patterns 지침에서 미리 정의된 워크플로와 프로세스를 동적으로 제어하는 에이전트를 구분한다. Anthropic은 단순한 해법에서 시작해 작업이 요구할 때 복잡성을 더하라고 권고한다.

이 구분은 이 이야기를 해석하는 유용한 방식을 제공한다. 어떤 작업은 기술적 세부 사항은 달라도 알려진 순서를 따른다. 다른 작업은 그 순서 자체를 발견해야 한다.

Anthropic의 멀티 에이전트 리서치 시스템은 후자에 해당하는 사례를 보여 준다. 총괄 에이전트는 조사 전략을 수립하고, 조사를 위임하며, 결과를 종합한다. Anthropic 역시 여러 에이전트가 조정상의 어려움과 추가 리소스 사용을 초래한다고 경고한다.

조사 과정에서 발견되는 내용에 따라 연구의 방향은 바뀔 수 있다. 예상치 못한 출처가 출발 가정을 무효화하거나, 원래 질문이 관련 쟁점을 빠뜨렸음을 드러낼 수 있다.

이런 환경에서 모든 요청에 동일한 순서를 강제하면 정돈되어 보이지만 불완전한 결과가 나올 수 있다. 시스템에는 무엇을 더 조사할 가치가 있는지 판단할 수 있는 일정 수준의 역량이 필요하다.

범위가 정해진 운영 워크플로는 다른 요건을 제시한다. 그 순서는 이미 안전하게 재배열할 수 없는 의존성을 반영하고 있을 수 있다. 각 단계 안에서는 여전히 기술적 추론이 필요하지만, 순서 자체에는 유용한 즉흥적 조정의 여지가 적다.

따라서 이 비교는 중앙 지능에 관한 단순한 결론을 허용하지 않는다. 경로를 선택하는 일 자체가 문제의 일부라면 사고하는 조정자가 정당화된다. 경로가 이미 정해져 있다면 그 가치는 덜 분명하다.

Meta의 얇은 오케스트레이터가 계획 에이전트에 반대하는 포괄적 논거가 되어서는 안 되는 이유도 여기에 있다. 작업이 실제로 이를 요구할 때 계획은 정당한 책임이다.

실질적인 과제는 그 책임이 검토 없이 확장되는 것을 막는 데 있다. 처음에는 요청을 해석하기 위해 도입된 조정자가 점차 구현, 검증, 승인 업무까지 맡게 될 수 있다.

각 기능 추가는 단기적으로 해당 구성 요소를 더 편리하게 만든다. 그러나 이제 하나의 대화에 요청, 계획, 실행 이력, 성공 여부에 대한 판단이 모두 담기면서 실패 원인을 추적하기는 더 어려워질 수 있다.

하이브리드 설계는 합리적인 분석적 가능성을 제시한다. 계획 에이전트가 경로를 제안하고, 명시적 검사가 실제로 진행할 수 있는 작업을 통제하는 방식이다. 이 구성이 도움이 되는지는 대상 워크로드에서 평가해야 한다.

경쟁 측면에서 보면 공급업체는 자율성의 경계를 설명해야 한다. 구매자는 제품이 워크플로를 따르는지, 새로 만들어 내는지, 또는 두 행동 사이를 오가는지 이해해야 한다.

이러한 구분은 감독, 진단, 복구에 영향을 준다. 또한 성공적인 시연이 반복 가능한 운영 프로세스를 반영하는지, 아니면 개방형 작업에서 우호적으로 전개된 한 번의 시도인지를 좌우한다.

기업 비교는 이러한 선택을 명확히 할 때 유용해진다. 서로 다른 워크로드를 같은 성능 경쟁의 항목처럼 다룰 때는 오해를 낳는다.

보고된 속도는 중요한 신뢰성 의문을 남긴다

더 빠른 한 번의 성공 시도가 모든 시도에서의 안정적인 성능을 입증하지는 않는다.

보고된 결과는 모든 신뢰성 문제를 해결하지는 못하지만 긍정적으로 해석할 여지는 남긴다. 핵심 불확실성은 개선의 어느 정도가 조정 경계 자체에서 비롯되는가다.

아키텍처를 재설계하는 동안 여러 요인이 함께 바뀔 수 있다. 지침은 더 명확해지고, 문서는 개선되며, 작업 정의는 더 정교해지고, 승인 조건도 더 명시적이 된다.

이러한 변화는 모두 도움이 될 수 있다. 동시에 어떤 설계 결정이 개선을 가져왔는지에 관한 주장을 복잡하게 만든다. 유용한 평가는 더 좁은 조정 범위의 효과와 더 나은 작업 준비의 효과를 분리해야 한다.

Anthropic의 에이전트 평가 가이드는 실행 기록과 환경의 최종 상태를 구분한다. 에이전트가 성공했다고 말하는 것과 의도한 결과가 실제로 존재한다는 증거는 다르다.

여기에 이 원칙을 적용하면 조정자의 마무리 메시지보다 완료된 작업을 평가해야 한다는 결론이 나온다. 변경 사항은 완료된 것처럼 보이면서도 일관성 없는 구성이나 해결되지 않은 의존성을 남길 수 있다.

의미 있는 비교는 실패한 시도도 고려해야 한다. 성공한 실행만 측정하면 반복 재시도, 포기된 작업, 또는 엔지니어가 프로세스를 다시 시작해야 했던 작업을 가릴 수 있다.

사람의 노력도 마찬가지로 주목할 가치가 있다. 작은 최종 수정 전에 긴 조사 과정이 있었을 수 있다. 반대로 검토자가 문제를 이해하고 나면 더 큰 수정도 간단할 수 있다.

따라서 수정 규모는 감독을 측정하는 불완전한 지표다. 검토 시간, 진단 시간, 그리고 결과 변경 사항에 대한 신뢰도는 서로 다른 정보를 제공한다.

같은 주의는 리소스 사용에도 적용된다. 더 좁은 조정자는 불필요한 추론을 줄일 수 있지만, 여러 전문 에이전트는 실행 오버헤드를 추가할 수 있다. 그 균형은 이들이 얼마나 자주 실행되고 얼마나 많은 작업을 반복하는지에 달려 있다.

또 다른 불확실성은 경계를 넘는 오류와 관련된다. 전문 에이전트는 자신의 지역적 요구사항을 충족하면서도 다른 단계의 가정과 충돌하는 산출물을 만들 수 있다.

컨텍스트 격리, 즉 서로 다른 에이전트가 이용할 수 있는 정보를 분리하는 방식은 관련 없는 영향력을 줄일 수 있다. 하지만 상호작용을 감지하는 데 필요한 정보를 차단할 수도 있다.

따라서 적절한 평가는 구성 요소 간 관계가 포함된 사례를 필요로 한다. 각 전문 에이전트를 독립적으로 테스트하면 이러한 관계는 충분히 검토되지 않는다.

복구는 별도로 면밀히 살펴볼 필요가 있다. 예를 들어 어떤 워크플로가 구성을 변경한 뒤 후속 검사에서 실패한다고 가정해 보자. 요청을 다시 시작하면 원래 조건이 아니라 부분적으로 완료된 상태에 직면할 수 있다.

시스템은 그 상태에 대한 명확한 해석을 갖춰야 한다. 그렇지 않으면 재시도가 작업을 중복하거나 요청이 이미 완료되었다고 잘못 판단할 수 있다.

이러한 우려가 설계를 무효화하는 것은 아니다. 다른 조직이 이 패턴을 신뢰할 수 있는 기본 방식으로 채택하기 전에, 신뢰성 주장이 무엇을 포괄해야 하는지를 규정할 뿐이다.

신중한 결론은 더 좁은 권한 범위가 이해 가능한 엔지니어링 근거를 제공한다는 것이다. 다만 운영상 이점은 경계, 검사, 그리고 실패 전반에서 수집된 증거의 품질에 여전히 달려 있다.

아키텍처가 더 많은 워크로드로 확장될 때 주목할 점

다음으로 유용한 증거는 책임이 확대되어도 설계가 이해 가능한 상태로 유지되는지를 보여 줄 것이다.

향후 몇 달 동안 독자는 우선 워크로드 확장을 지켜봐야 한다. 익숙하지 않은 작업이 기존 책임 분담에 어떻게 들어맞는지 보여 주는 후속 사례가 나온다면 중요한 진전이 될 것이다.

재사용의 증거는 아키텍처 논거를 강화할 것이다. 도메인 관련 결정이 반복적으로 조정자에게 되돌아가는 예외가 발생한다면 그 논거는 약화될 것이다.

이 구분에는 지원되는 워크플로 수보다 더 자세한 정보가 필요하다. 늘어나는 목록은 광범위한 맞춤형 처리를 감출 수 있다. 독자는 새 작업이 기존 경계를 따르는지, 아니면 그 경계를 바꿔야 하는지를 알아야 한다.

두 번째 신호는 결과에 대한 더 완전한 평가다. 성공, 검토 노력, 실패한 시도, 리소스 사용을 아우르는 공개 비교가 있다면 보고된 이점을 더 쉽게 해석할 수 있다.

비교 가능한 출발 조건도 중요하다. 더 좁은 시스템이 더 정돈된 입력이나 더 나은 문서를 제공받는다면, 비교는 그 차이를 밝혀야 한다.

반복 시도는 성능이 안정적인지도 드러낼 것이다. 대체로 수용 가능한 수준으로 완료하는 시스템은 반복 개입 후에야 인상적인 결과를 내는 시스템과 다른 운영상 가치를 제시한다.

가장 강력한 증거는 중간 검사와 최종 결과를 연결하는 것이다. 그러면 조정자의 승인 조건이 실제로 사용 가능한 작업을 예측하는지 보여 줄 수 있다.

세 번째 신호는 다른 범위 제한형 워크플로에서 이루어진 독립적 재현이다. 별도의 조직이 같은 이점을 재현한다면 원래 배포 사례를 넘어서는 증거가 된다.

유용한 재현은 워크로드의 구조와 줄어드는 오류를 설명해야 한다. 전문 에이전트를 단순히 채택하는 것만으로는 더 좁은 조정이 더 나은 결과를 낳았음을 입증할 수 없다.

상반된 결과 역시 유익할 수 있다. 다른 팀에 광범위한 중앙 계획이 필요하다면, 그 경험은 이 패턴이 더 이상 적합하지 않은 지점을 분명히 할 수 있다.

이러한 관찰은 논의를 작업 구조에 계속 연결해야 한다. 중요한 질문은 조정이 경로를 발견해야 하는지, 아니면 의존성이 이미 알려진 경로를 집행해야 하는지다.

개발자에게 이 구분은 재작성에 착수하기 전에 아키텍처 검토의 방향을 정할 수 있다. 기존 실패 기록은 실수가 라우팅, 기술적 실행, 또는 성급한 승인 중 어디에서 비롯되는지 드러낼 수 있다.

엔터프라이즈 구매자에게는 제품 평가를 개선할 수 있다. 성공적인 자동화 사례와 함께 시스템이 불확실성과 부분 완료를 어떻게 처리하는지 보여 달라고 요청해야 한다.

지식 근로자에게 더 넓은 의미는 책임과 관련된다. 정보 수집, 그 정보의 해석, 행동 승인 사이를 구분하는 어시스턴트는 더 쉽게 평가할 수 있다.

팀이 이미 이해하고 있는 워크플로에서 시작한 뒤, 자동화된 결정이 어디에서 이루어지는지 살펴보라. 해석이 필요한 결정과 확립된 조건을 따르는 결정을 구분하라. 성공적인 실행, 실패한 시도, 사람의 검토 전반에서 결과를 비교하라. 자율성에 관한 광범위한 약속이 아니라 실제 작업에 증거를 연결해 두라. Meta의 얇은 오케스트레이터는 팀이 이러한 경계를 검토해야 할 구체적인 이유를 제공한다. 가장 유용한 기여는 모든 중앙 조정자에게 던지는 질문이다. 이 구성 요소는 자신의 업무를 수행하기 위해 어떤 판단을 내려야 하는가? 다음 아키텍처 검토에서 이 질문을 사용하고, 라우터에 부여되는 모든 책임에 대해 관찰 가능한 근거를 요구하라.

 
 

무료로 시작하세요

개인 지식 관리 기능을 갖춘 로컬 우선 AI 어시스턴트

더 나은 AI 경험을 위해

현재 remio는 Windows 10+ (x64) 및 M-Chip Macs만 지원합니다.

업무를 위한 AI 파트너
remio와 더 많은 일을 해내세요

계획하고, 만들고, 완성하세요
모든 일을 한곳에서

bottom of page