기업에 합류하는 Agent에게는 노트북과 출입증이 필요합니다

AI로 생성한 개념 이미지입니다. 노트북과 출입증으로 실행 환경과 업무 접근 권한을 표현했습니다.

새 동료가 입사하면 회사는 보통 두 가지를 먼저 준비합니다.

하나는 컴퓨터입니다. 파일을 열고 소프트웨어를 실행하며 일할 수 있게 해 줍니다. 다른 하나는 계정과 권한입니다. 사내 업무 시스템, 프로젝트 문서, CRM에 접속해 담당 범위 안에서 데이터를 읽고 수정할 수 있어야 합니다.

노트북을 받아도 계정이 없으면 일을 시작하기 어렵습니다. 계정이 있어도 작업 환경이 갖춰지지 않으면 할 수 없는 일이 많습니다.

Agent가 기업에 들어올 때도 비슷한 조건이 필요합니다.

작업을 실행할 환경과 업무 시스템에 정당하게 접근할 방법이 있어야 합니다. 앞의 역할은 샌드박스가 맡을 수 있습니다. 뒤의 문제를 다루는 기반이 OpenConnector 같은 연결·권한 게이트웨이입니다.

이 두 기반은 유능한 Agent가 실제 회사 업무에 참여할 수 있는지를 좌우합니다.

질문에 답하는 단계에서 업무를 맡는 단계로

가치 있는 기업 업무는 여러 시스템에 걸쳐 있습니다.

Agent에게 내일 고객 미팅을 준비해 달라고 해 봅시다. 캘린더에서 참석자를 확인하고, 최근 주고받은 이메일을 읽고, CRM에서 고객 진행 상황을 정리한 뒤 회의 문서에 논의할 내용을 작성해야 합니다.

이해력과 판단력에 더해 실제 시스템 접근이 필요합니다. 어디에서 정보를 찾고, 누구의 계정을 쓰며, 어떤 내용을 읽고 어디에 결과를 저장할 수 있는지 알아야 합니다.

고객 상태 수정이나 초대장 발송까지 맡기면 권한 요구도 달라집니다. 고객 정보를 읽는 권한이 영업 기회 수정 권한을 뜻하지 않습니다. 이메일 열람 권한이 회사를 대신한 발송 권한을 주는 것도 아닙니다.

Agent 데이터 보안에 관한 글에서는 충분한 업무 맥락이 판단에 도움이 된다고 설명했습니다. 이제 기업이 그 정보와 실행 능력을 어떻게 제공할지 답해야 합니다.

직원은 계정, 역할, 권한을 통해 업무 시스템을 사용합니다. Agent에게도 분명한 접근 경계가 필요합니다.

샌드박스는 Agent의 업무용 컴퓨터입니다

직원이 컴퓨터에서 소프트웨어를 실행하듯 Agent도 실행 환경을 필요로 합니다.

코드를 실행하거나 스프레드시트를 처리하고, 파일을 만들거나 브라우저를 조작할 수 있습니다. 샌드박스는 프로그램이 접근할 수 있는 파일, 프로세스, 네트워크 자원을 제한하는 환경입니다. 실제 격리 범위는 구현과 설정에 따라 다릅니다. Anthropic의 샌드박스 기술 설명은 Agent 실행에서 파일 시스템과 네트워크 격리가 맡는 역할을 다룹니다.

회사가 컴퓨터를 지급하면서 도구와 사용 범위를 함께 정하는 것과 비슷합니다.

하지만 소프트웨어를 실행할 수 있다고 회계 시스템 권한이 생기지는 않습니다. 샌드박스에서 코드를 실행한다고 CRM이나 사내 업무 시스템에 정당한 접근 권한이 부여되는 것도 아닙니다.

샌드박스가 답하는 질문은 Agent가 어디에서 실행되고, 그 환경에서 무엇이 허용되는가입니다.

업무 시스템 접근에는 별도의 기반이 필요합니다.

게이트웨이는 출입증 뒤의 접근 통제 시스템입니다

출입증은 신원을 나타내고, 출입 통제 시스템은 열 수 있는 문을 결정합니다. 기업 소프트웨어의 계정, 역할, 권한도 비슷하게 작동합니다.

연결·권한 게이트웨이는 그중 일부를 Agent를 위해 처리합니다. 애플리케이션 연결과 자격 증명을 관리하고, 호출 권한을 확인한 뒤 허용된 작업을 대상 시스템에 전달합니다.

앱에 연결하는 것은 시작입니다. 계속 사용할 접근 경로라면 다음 질문에도 답해야 합니다.

• 누구의 계정으로 누구를 대신해 작업하는가?
• 무엇을 읽고 어떤 쓰기 작업을 수행할 수 있는가?
• 외부 계정 자격 증명은 어디에 저장하고 누가 보호·갱신하는가?
• 호출 실패의 원인과 기록을 찾을 수 있는가?
• 작업이 끝나거나 역할이 바뀌면 어떻게 접근을 회수하는가?

모든 앱의 키를 Agent 환경에 직접 넣으면 관리할 사항이 스크립트, 설정, 배포 환경에 흩어집니다. 모델이나 환경을 바꿀 때마다 다시 정리해야 할 수 있습니다.

게이트웨이는 연결과 권한을 중앙에서 관리할 경계를 제공합니다. Agent는 허용된 인터페이스로 요청하고, 외부 서비스의 원본 자격 증명은 게이트웨이가 관리하며, 실행 시점에 작업을 검사합니다.

“데이터를 읽기만 하세요”는 지시문에 쓸 수 있습니다. “이 호출에는 쓰기 권한이 없습니다”는 시스템이 강제해야 합니다. 이 제약이 있어야 기업은 실제 업무를 단계적으로 위임할 수 있습니다.

두 경계는 서로 다른 곳을 보호합니다

샌드박스와 게이트웨이는 함께 사용할 수 있습니다.

게이트웨이를 거치는 호출의 개념도입니다. 각 계층은 다른 경계를 통제하며 실제 기능은 배포와 설정에 따라 달라집니다.

기반	직원 입사에 비유하면	핵심 역할
샌드박스	업무용 컴퓨터	코드 실행과 파일 처리를 수행할 환경
연결·권한 게이트웨이	출입증 뒤의 접근 통제	사용할 계정과 허용된 업무 작업 결정

프로그램은 샌드박스 안에 있으면서도 허용된 네트워크로 외부에 요청을 보낼 수 있습니다. 고객 기록을 삭제할 수 있는 자격 증명을 갖고 있다면, 샌드박스 자체는 그 삭제가 업무 역할에 맞는지 알지 못합니다.

반대로 앱 호출이 게이트웨이를 지나더라도 다운로드한 파일, 로컬 스크립트, 임시 산출물은 실행 환경에서 관리해야 합니다.

따라서 기업은 실행 환경과 업무 시스템 진입점을 함께 관리해야 합니다. 코드와 파일을 다루고 여러 앱에서 작업하는 Agent라면 특히 중요합니다.

실제 도입에는 신원 관리, 작업 조율, 승인, 결과 검증도 필요합니다. 통제된 API만으로 끝나는 작업에는 별도 샌드박스가 필요하지 않을 수도 있습니다. 노트북과 출입증의 비유는 실행 능력과 부여받은 업무 접근 권한이라는 두 기반을 보여 줍니다.

연결 기반을 장기적으로 봐야 하는 이유

데모에서는 성공한 호출 한 번으로 가능성을 보여 줄 수 있습니다. 지속적인 기업 사용에서는 역할과 계정이 다른 여러 Agent가 같은 시스템을 안정적으로 사용할 수 있는지가 중요해집니다.

오늘 고객 자료를 정리하던 도우미를 내일 다른 모델로 바꾸고, 이후 주문 전담 Agent를 추가할 수 있습니다. CRM, 문서, 이메일 시스템과 연결·권한 관리 작업은 계속 남습니다.

Agent마다 따로 연동하면 API 대응, 자격 증명 보관, 토큰 갱신, 작업 제한, 실패 분석을 반복합니다. 재사용할 기반이 있으면 새 Agent가 기존 연결을 활용하고 역할에 맞는 권한을 받을 수 있습니다. 개발자는 업무 흐름에 집중하고 기업은 일관된 접근 규칙을 유지하기 쉬워집니다.

Agent가 실제 업무를 맡을수록 연결과 권한은 지속적인 수요가 됩니다.

개발자에게는 함께 투자할 만한 공통 기술 기반입니다. 기업에는 미리 설계할 아키텍처 경계입니다. Agent 산업을 살피는 투자자에게도 연구할 가치가 있는 인프라 분야입니다. 장기 가치는 반복 연동 작업을 얼마나 줄이고, 여러 업무에서 재사용되며, 연결·권한·운영 책임을 계속 감당할 수 있는지에 달려 있습니다.

OpenConnector가 만드는 기반

OpenConnector는 OOMOL이 유지·관리하는 오픈소스 연결 게이트웨이입니다. 앱 연결과 자격 증명을 관리하고 SDK, CLI, MCP, HTTP로 호출 가능한 작업을 제공합니다.

Agent나 신뢰할 수 있는 백엔드가 작업과 연결을 선택합니다. 게이트웨이는 호출 자격 증명과 작업 정책을 확인한 뒤 해당 계정으로 외부 서비스에 요청하고 결과를 반환합니다.

개발자는 작업 정의, 입력값, 필요한 권한 범위를 확인할 수 있습니다. 자체 호스팅 환경에서는 허용·차단 작업을 설정하고 민감 정보를 가린 실행 기록으로 문제를 조사할 수 있습니다. 공개 런타임과 작업 정의, 지원되는 작업의 로컬 실행 코드를 통해 호출 경로를 검토하고 확장할 수 있습니다. 자세한 내용은 OpenConnector 문서를 참고하세요.

게이트웨이 정책은 원래 앱의 계정 권한과 승인 범위와 함께 적용됩니다. 어떤 고객 기록을 볼 수 있는지는 원본 시스템의 규칙에도 달려 있고, 이메일 발송은 업무 절차상 사람의 승인이 필요할 수 있습니다. 기업 전체의 신원·승인 체계와 연계해야 합니다.

먼저 업무 연동을 검증하려면 OOMOL 호스팅을, 게이트웨이와 자격 증명을 직접 관리하려면 OpenConnector 자체 호스팅을 선택할 수 있습니다. 배포 방식 안내에서 선택 기준을 확인하세요.

함께 만들 가치가 있는 인프라

기업 앱 연동은 계속 유지·관리해야 합니다. 서비스마다 인증 방식, 매개변수, 오류, 사용 제한이 다릅니다. API가 바뀌고 토큰이 만료되며 새로운 앱과 내부 시스템도 추가됩니다.

이 작업 중 상당수는 함께 활용할 수 있습니다. 페이지 처리 오류를 수정하면 다른 팀도 혜택을 받습니다. 필요한 권한 범위를 명시하면 다음 개발자의 조사가 줄어듭니다. 실행 코드를 공개하면 검토와 수정을 거쳐 각자의 환경에서 사용할 수 있습니다.

오픈 게이트웨이의 의미는 회사마다 반복하는 연결 작업을 생태계가 함께 쓸 수 있는 능력으로 축적하는 것입니다.

개방된 연결 계층은 선택권도 유지해 줍니다. Agent와 모델이 바뀌어도 공개 인터페이스와 구현을 통해 연결을 계속 사용할 수 있습니다. 환경을 직접 통제할 팀에는 읽을 코드와 배포 경로가 있습니다.

오픈소스는 검토, 수정, 공동 유지·관리의 기회를 만듭니다. 보안을 위해서는 코드 검토, 올바른 설정, 지속적인 운영이 필요하고 외부 API의 이용 조건도 적용됩니다. 협업의 가치는 구체적인 작업을 완수하고 재사용하는 데서 나옵니다.

다음 “디지털 동료”의 입사를 준비하며

입사를 앞둔 동료라고 생각하면 먼저 물을 수 있습니다. 어디에서 일할까요? 어느 시스템에 들어갈 수 있나요? 무엇을 읽고 바꿀 수 있나요?

이 질문의 답을 시스템에서 실행할 수 있어야 더 가치 있는 업무를 맡길 수 있습니다.

우리는 OpenConnector가 그 입사 기반의 일부가 되기를 바랍니다. 매일 사용하는 앱에서 시작해 필요한 작업을 추가하거나, 권한 문제를 수정하거나, 매개변수 정의를 보완하거나, 배포 경험을 공유할 수 있습니다.

OOMOL 웹사이트에서 제품과 연동 방법을 살펴보세요. 먼저 업무를 검증하려면 OOMOL Console에서 앱 하나를 연결하고 범위가 명확한 읽기 작업부터 시작하세요.

기업에 들어오는 Agent에게는 일할 환경과 적절한 권한으로 통과할 업무 시스템의 문이 필요합니다. 우리는 그 문부터 커뮤니티와 함께 만들고 있습니다.