셀프호스팅 에이전트로 부서 업무 연결하기

[!IMPORTANT] 한 줄 브리핑: OtoDock은 Claude Code·Codex CLI 에이전트를 부서 단위로 운영하는 셀프호스팅 앱을 표방한다. 도입 전 협업 방식과 보안 경계를 점검하고 작은 업무부터 검증하는 방법을 정리한다.
분야: IT/AI/Security

30초 요약

OtoDock은 개발자가 공개한 셀프호스팅 회사 운영 애플리케이션이다. 소개 자료에서는 이를 Claude Code, Cowork, 클라우드 세션을 한곳에 묶은 형태로 설명한다.
여러 사람이 회사 에이전트와 협업할 수 있도록 설계됐으며, 멀티테넌트 구조를 기본으로 한다. 멀티테넌트란 하나의 애플리케이션 안에서 여러 사용자나 조직 단위를 분리해 운영하는 방식을 뜻한다.
에이전트는 Claude Code 또는 Codex CLI 기반으로 실행할 수 있다고 소개되어 있다. Anthropic 또는 OpenAI 구독을 사용하거나, 로컬 모델을 연결하는 선택지도 제시된다.
핵심 업무 적용 포인트는 ‘AI에게 회사 전체를 맡긴다’가 아니라, 부서별 반복 업무를 에이전트 단위로 나누고 사람이 승인하는 흐름을 만드는 것이다.
다만 입력 자료만으로는 설치 명령, 지원 운영체제, 인증 방식, 권한 세분화, 데이터 암호화, 로그 보존 정책, 실제 성능을 확인할 수 없다. 도입 전 저장소의 최신 문서와 자체 보안 검증이 필요하다.

무슨 일인가

OtoDock은 개인용 챗봇보다는 조직 안에서 여러 AI 에이전트를 운영하는 작업 공간을 지향하는 프로젝트로 소개됐다. 여기서 에이전트는 단순히 질문에 답하는 모델이 아니라, 특정 업무 맥락과 실행 도구를 바탕으로 작업을 수행하도록 구성한 단위다. 예를 들면 개발, 문서 정리, 리서치처럼 역할이 다른 작업을 각각의 에이전트로 나누는 식이다.

프로젝트 소개에서 언급된 주요 요소는 다음과 같다.

셀프호스팅: 사용자가 자신의 환경에 애플리케이션을 설치해 운영하는 방식이다. 자료에서는 누구나 무료로 설치하고 셀프호스팅할 수 있다고 설명한다. 다만 무료라는 설명이 서버 비용, 모델 사용료, 운영 인력 비용까지 없다는 뜻인지는 확인되지 않았다.
부서 단위 구성: 에이전트를 부서에 배치하는 개념을 내세운다. 부서는 실제 조직일 수도 있고, 콘텐츠 제작·개발·고객지원처럼 업무 묶음을 의미할 수도 있다.
멀티테넌트 협업: 여러 사람이 회사 에이전트에서 협업할 수 있도록 설계됐다고 한다. 소개 자료에는 네 가지 협업 모드가 있다고 언급되지만, 각 모드의 이름과 권한 차이는 제공된 정보만으로 확인할 수 없다.
여러 실행 기반: 에이전트가 Claude Code 또는 Codex CLI에서 실행될 수 있다고 소개된다. 어떤 모델이 어떤 기능을 지원하는지, 두 실행 기반 사이의 차이가 무엇인지는 별도 검증이 필요하다.
모델 선택권: Anthropic 또는 OpenAI 구독을 사용하거나 로컬 모델을 사용할 수 있다고 설명한다. 실제 연결 절차와 호환 범위는 저장소 문서를 확인해야 한다.

이 프로젝트를 이해하는 가장 쉬운 방법은 ‘AI 직원’을 상상하는 것이 아니라, 부서별 작업 큐와 실행 세션을 한 애플리케이션에서 관리하는 구조로 보는 것이다. 중요한 것은 에이전트 수가 아니라, 어떤 입력을 받고 어떤 산출물을 만들며 어디에서 사람의 승인을 받는지다.

왜 중요한가

1. 모델보다 운영 구조가 업무 성패를 좌우한다

많은 팀이 AI 도입을 모델 선택 문제로 시작한다. 그러나 실제 업무에서는 프롬프트보다 다음 질문이 더 중요할 수 있다.

이 에이전트가 읽을 수 있는 자료는 어디까지인가?
결과물을 누가 검토하고 승인하는가?
실행 기록과 변경 사항을 나중에 확인할 수 있는가?
같은 작업을 여러 사람이 이어받을 수 있는가?
모델이나 공급자를 바꿔도 업무 흐름이 유지되는가?

OtoDock의 소개는 이런 운영 문제를 부서와 협업 모드라는 단위로 다루려는 방향을 보여준다. 이는 AI를 개인 생산성 도구에서 팀 프로세스의 일부로 옮길 때 참고할 만한 관점이다.

2. 셀프호스팅은 통제권과 책임을 함께 가져온다

셀프호스팅의 장점은 조직이 자신의 인프라에 애플리케이션을 두고 운영 방식을 통제할 가능성이 있다는 점이다. 특히 업무 데이터가 외부 서비스의 기본 저장소에 남는 것이 부담스러운 팀이라면 검토 이유가 생긴다.

반대로 운영 책임도 사용자에게 돌아온다. 서버 보안, 계정 관리, 백업, 업데이트, 장애 대응, 모델 API 키 보호를 직접 설계해야 할 수 있다. ‘내부에 설치된다’는 사실만으로 데이터가 자동으로 안전해지는 것은 아니다. 에이전트가 외부 모델이나 CLI를 호출한다면 어떤 정보가 외부로 전달되는지도 확인해야 한다.

3. 공급자 선택을 업무 흐름과 분리할 수 있다

자료상으로는 Anthropic, OpenAI, 로컬 모델을 선택할 수 있다. 이 선택이 실제로 작동한다면 팀은 하나의 업무 절차를 유지하면서 모델 실행 환경을 바꿔 비교할 수 있다. 다만 이것은 가능성에 대한 관찰이지, 동일한 품질이나 기능이 보장된다는 뜻은 아니다.

실무에서는 모델 성능을 막연히 비교하기보다 업무별 평가 기준을 먼저 정하는 편이 안전하다. 예를 들어 문서 요약은 누락률과 인용 확인을, 코드 변경은 테스트 통과와 변경 범위를, 고객지원 초안은 정책 위반 여부와 사람의 수정 시간을 기준으로 삼는다.

업무에 어떻게 쓸까

처음부터 전사 운영을 시도하지 말고, 자료 범위가 좁고 결과를 사람이 검토할 수 있는 반복 업무 하나로 시작하는 것이 좋다. 아래 절차는 OtoDock의 구체적인 설치법이 아니라, 제공된 기능 설명을 실제 업무 검증으로 연결하기 위한 도입 방법이다.

1단계: 부서가 아니라 업무 한 가지를 고른다

다음 조건을 만족하는 업무를 우선 후보로 둔다.

입력 자료가 일정한 형식으로 들어온다.
결과물의 품질 기준을 문장으로 설명할 수 있다.
최종 승인자가 명확하다.
잘못된 결과가 나와도 즉시 외부에 자동 배포되지 않는다.
첫 검증에 민감정보를 넣지 않아도 된다.

예를 들어 ‘매주 회의록에서 결정 사항과 후속 작업을 추출해 검토용 문서로 만들기’처럼 범위를 좁힌다. 반대로 ‘마케팅 전체 자동화’나 ‘개발팀의 모든 변경 자동 승인’처럼 목표가 넓은 업무는 첫 실험에서 제외한다.

2단계: 부서별 에이전트의 책임을 한 문장으로 정의한다

에이전트 이름보다 책임 문장이 중요하다. 다음 형식을 사용하면 된다.

이 에이전트는 [입력]을 받아 [검토 가능한 결과물]을 만들며,
[금지된 행동]은 하지 않고, [승인 담당자]의 확인 전에는 외부에 공유하지 않는다.

예시는 다음과 같다.

이 에이전트는 회의록과 프로젝트 메모를 받아 결정 사항, 담당자, 기한의 초안을 만들며,
사실을 추정해 채우지 않고, 팀 리더의 확인 전에는 공식 일정으로 등록하지 않는다.

이 문장은 모델에게 주는 지시이면서 팀의 운영 규칙이다. 특히 자동 발송, 파일 삭제, 코드 반영, 외부 공유처럼 되돌리기 어려운 행동은 초기 단계에서 금지하거나 사람 승인 뒤에만 허용한다.

3단계: 협업 모드를 이름이 아니라 통제 지점으로 비교한다

자료에는 네 가지 협업 모드가 언급되지만 세부 정의는 확인되지 않는다. 따라서 실제 화면이나 문서를 확인할 때 다음 항목을 기록한다.

확인 항목	점검 질문
작업 시작	누구나 에이전트를 실행할 수 있는가?
입력 공유	다른 사용자의 자료와 세션을 볼 수 있는가?
결과 수정	에이전트 결과를 누가 편집할 수 있는가?
승인	승인 전 결과가 외부 시스템으로 나갈 수 있는가?
이력	프롬프트, 결과, 변경 기록을 추적할 수 있는가?
중단	실행 중인 작업을 누가 멈출 수 있는가?

네 가지 모드가 실제로 어떤 권한을 제공하는지 확인하기 전에는 ‘협업 가능’이라는 표현을 권한 분리로 확대 해석하지 않는다. 테스트 계정 두 개를 만들어 같은 에이전트, 같은 작업, 다른 역할로 접근해 차이를 확인하는 방식이 실용적이다.

4단계: 모델과 실행 기반을 하나씩 비교한다

처음부터 여러 공급자와 로컬 모델을 동시에 붙이면 문제가 생겼을 때 원인을 찾기 어렵다. 다음 순서를 권한다.

테스트용 비민감 데이터로 기본 실행을 확인한다.
한 가지 실행 기반에서 결과 형식과 승인 절차를 고정한다.
같은 입력 세트로 다른 실행 기반 또는 모델을 시험한다.
결과의 정확성만이 아니라 비용, 지연, 재현성, 검토 시간을 기록한다.
업무에 맞지 않는 모델을 자동으로 대체하지 말고 담당자가 선택할 기준을 정한다.

Anthropic 또는 OpenAI 구독 사용이 가능한지, 로컬 모델이 어떤 조건에서 연결되는지는 실제 저장소 문서와 환경에서 확인해야 한다. 입력 자료에는 모델별 성능 비교나 비용 수치가 없으므로, 특정 선택이 더 우수하다고 단정해서는 안 된다.

5단계: 작은 평가표로 1주일을 관찰한다

업무 결과를 다음처럼 기록하면 도입 판단이 쉬워진다.

작업명:
입력 자료 유형:
선택한 에이전트/실행 기반:
사람이 수정한 항목:
누락 또는 잘못된 항목:
검토에 걸린 시간:
외부 공유 여부:
다음 실행에서 바꿀 규칙:

평가의 목적은 ‘AI가 얼마나 똑똑한가’를 묻는 것이 아니라, 기존 방식보다 전체 처리 시간이 줄었는지, 검토 가능한 결과를 꾸준히 만들었는지 확인하는 데 있다. 오류가 발견되면 프롬프트만 고치지 말고 입력 형식, 책임자, 승인 지점도 함께 조정한다.

한계와 주의점

확인되지 않은 기술 세부사항

제공된 자료만으로는 다음을 알 수 없다.

설치에 필요한 운영체제, 런타임, 데이터베이스, 배포 방식
실제 설치 명령과 업데이트 절차
네 가지 협업 모드의 명칭과 권한 차이
사용자 인증, 조직 분리, 관리자 권한의 구체적인 구현
에이전트가 접근하는 파일과 도구의 범위
API 키와 대화 기록의 저장·암호화 방식
감사 로그, 백업, 삭제, 복구 기능
모델별 비용, 응답 속도, 정확도, 안정성
동시 사용자 수나 운영 환경에서의 성능

따라서 이 글의 ‘멀티테넌트’, ‘셀프호스팅’, ‘여러 모델 지원’은 프로젝트 소개에 포함된 설명을 정리한 것이며, 독립적인 보안·성능 검증 결과가 아니다. 실제 도입 전에는 저장소의 README와 설정 문서, 이슈, 릴리스 정보를 확인하고 테스트 환경에서 재현해야 한다.

보안 경계부터 정한다

에이전트에 회사 문서나 소스 코드를 연결하기 전에는 최소 권한 원칙을 적용한다. 최소 권한은 작업에 꼭 필요한 자료와 실행 권한만 부여하는 방식이다.

처음에는 공개 자료 또는 비식별화한 샘플만 사용한다.
운영 계정의 API 키를 개발·테스트 환경에 그대로 넣지 않는다.
읽기 전용 자료와 변경 가능한 자료를 구분한다.
외부 전송이 발생하는 모델인지 확인한다.
자동 삭제, 자동 배포, 자동 발송은 별도 승인 없이는 켜지 않는다.
사람별 접근 범위와 세션 기록이 실제로 분리되는지 테스트한다.
장애나 잘못된 변경에 대비해 원본과 백업을 유지한다.

‘회사 OS’라는 표현을 기능 보증으로 읽지 않는다

‘회사 OS’는 프로젝트가 지향하는 운영 개념을 설명하는 표현이다. 이 표현만으로 인사, 회계, 고객관리, 프로젝트관리 같은 업무 시스템이 포함된다고 볼 수는 없다. 현재 확인되는 정보의 중심은 부서별 에이전트, 협업, 실행 세션, 셀프호스팅이다.

결론적으로 OtoDock은 AI 에이전트를 개인별로 따로 사용하는 대신, 부서와 협업 단위로 묶어 운영하려는 접근을 보여준다. 바로 도입할 때는 기능 목록보다 한 가지 반복 업무의 입력·출력·승인·로그를 먼저 설계하고, 비민감 데이터로 실행을 검증하는 것이 안전하다. 그 검증에서 권한 분리와 기록성이 확인될 때만 더 중요한 업무로 범위를 넓히는 편이 합리적이다.