OpenOPC: 목표 하나로 조직도를 짜고 AI 직원을 채용해 일을 완료하는 멀티 에이전트 런타임 (feat. HKUDS)

9bow · 8월 29, 2026, 2:30오전

OpenOPC 소개

AI 코딩 에이전트에게 "이 기능을 만들어 줘"라고 요청하는 것과 "이 제품을 출시해 줘"라고 요청하는 것 사이에는 큰 차이가 있습니다. 앞의 요청은 한 세션 안에서 끝나지만, 뒤의 요청은 설계와 구현, 검토, 문서화, 배포 준비가 서로를 기다리는 여러 갈래의 작업으로 쪼개집니다. 단일 에이전트에게 긴 작업을 통째로 맡기면 중간에 문맥이 흐려지고, 반대로 사람이 작업을 잘게 나눠 에이전트에게 하나씩 던져 주면 결국 사람이 조율 담당자가 됩니다. 여러 에이전트를 동시에 실행하는 도구는 이미 많지만, 그 에이전트들이 서로에게 일을 넘기고 결과를 검토하며 막히면 사람을 부르는 절차까지 갖춘 경우는 드뭅니다.

OpenOPC는 홍콩대학교 데이터 인텔리전스 연구실(Data Intelligence Lab@HKU, HKUDS)이 공개한 멀티 에이전트 런타임으로, 이 조율 문제를 회사 조직이라는 형태로 해결합니다. 목표 하나를 입력하면 그 목표에 필요한 역할과 보고 체계를 담은 조직도를 먼저 그리고, 각 역할에 AI 직원을 배치한 뒤, 작업을 나눠 실행하고 검토하는 과정을 런타임이 직접 관리합니다. 저자들은 이 과정을 자체 구성(Self-Built), 자체 운영(Self-Run), 자체 성장(Self-Grown)이라는 세 축으로 설명하고 있습니다.

OpenOPC는 Python 3.10 이상에서 동작하는 파이썬 패키지이며, 터미널에서 쓰는 opc 명령과 브라우저에서 여는 Office UI를 함께 제공합니다. 실행 주체는 자체 런타임(OpenOPC Native)뿐 아니라 Codex, Claude Code, Cursor, OpenCode ( Opencode: 다양한 LLM을 사용할 수 있는, 터미널 기반의 오픈소스 AI 코딩 에이전트)와 같은 외부 코딩 에이전트 CLI를 역할별로 지정해 쓸 수 있습니다. 모델은 LiteLLM 및 OpenRouter 호환 엔드포인트를 통해 연결하므로 특정 제공자에 묶이지 않습니다.

기존 방식과 OpenOPC의 차이

OpenOPC가 참고했다고 밝힌 프로젝트들을 보면 이 프로젝트가 어느 자리를 노리는지가 드러납니다. 저장소의 Acknowledgements 섹션은 칸반 중심의 에이전트 작업 관리에서 Vibe Kanban ( Vibe Kanban: AI 코딩 에이전트 오케스트레이션 및 협업을 위한 오픈소스 플랫폼)의 영향을, 스킬 지향 에이전트 설계에서 같은 연구실의 nanobot ( nanobot: 홍콩대학교 데이터지능연구소(HKUDS)가 개발 및 공개한 초경량 개인용 비서 프로젝트 (feat. OpenClaw))의 영향을 받았다고 적고 있습니다. 인재 템플릿은 agency-agents 저장소에서 그대로 가져왔고, 픽셀 아트 오피스 시각화는 pixel-agents에서 착안했습니다.

즉 칸반 보드도, 스킬을 갖춘 에이전트도, 인재 템플릿도 이미 각자 존재하던 조각입니다. OpenOPC가 새로 얹은 것은 그 조각들을 묶는 조직 계층입니다. 작업을 누가 소유하고 누가 검토하며 막혔을 때 누구에게 올라가는지를 역할 관계로 정의해 두면, 사람이 매번 다음 단계를 지정하지 않아도 런타임이 다음에 깨울 에이전트를 고를 수 있습니다.

주요 항목별로 세 접근의 차이는 다음과 같습니다:

항목	단일 코딩 에이전트	Vibe Kanban 같은 작업 보드	OpenOPC
작업 분해	에이전트가 세션 안에서 자체 판단	사람이 작업을 만들어 배치	관리자 역할이 분해하고 의존 관계를 그래프로 구성
담당 배정	없음(단일 주체)	사람이 에이전트를 지정	역할과 고용된 직원에 자동 배정
결과 검토	사람이 최종 결과만 확인	사람이 작업 단위로 확인	검토 역할이 수용, 재작업, 상신 중 하나로 판정
막혔을 때	세션이 멈추거나 추측으로 진행	사람이 알아채야 함	팀 내부 메시지로 해결하거나 사람에게 상신
실행 주체	고정	에이전트별로 지정	역할마다 다른 외부 에이전트 지정 가능

OpenOPC가 맞는 팀과 맞지 않는 팀

여러 단계가 서로를 기다리는 긴 작업을 반복적으로 돌려야 하고, 그 과정을 눈으로 확인하며 개입할 여지를 남겨 두고 싶은 팀에게 OpenOPC는 살펴볼 만한 선택지입니다. 조직도와 칸반, 실행 진행 상황이 모두 화면에 드러나 있어 어느 역할이 무엇을 붙들고 있는지를 추적할 수 있고, 승인 정책으로 위험한 명령만 사람에게 올라오도록 조절할 수 있기 때문입니다.

반대로 터미널만으로 모든 것을 처리하려는 팀에게는 아직 이른 선택지입니다. 저장소의 Roadmap 섹션이 CLI 동등성(CLI parity)을 앞으로의 과제로 올려 두면서 "The CLI is functional today, but the Office UI remains the more complete surface"라고 현재 상태를 밝히고 있습니다. 조직 편집과 Company 모드 점검, 실패 복구 같은 기능은 아직 브라우저 UI 쪽이 앞서 있습니다. 단발성 작업 하나를 빠르게 끝내려는 경우에도 조직을 구성하는 과정이 부담이 되므로, 그때는 Task 모드를 쓰거나 코딩 에이전트를 직접 쓰는 편이 낫습니다.

OpenOPC의 세 가지 동작 축

1. 자체 구성(Self-Built): 조직도를 그리고 사람을 채웁니다

OpenOPC는 작업을 시작하기 전에 목표에서 필요한 역할과 보고 구조를 도출해 조직도를 만듭니다. 그다음 채용 담당 에이전트가 각 역할을 채우는데, 이때 이전 프로젝트를 거치며 문맥이 쌓인 기존 직원을 재사용할지 인재 풀에서 새로 채용할지를 고릅니다. 경력이 있는 직원은 누적된 문맥을 가지고 오고, 새로 채용한 직원은 백지 상태로 시작한다는 것이 이 선택의 기준입니다.

위 그림은 목표 하나에서 만들어진 조직도의 예시로, 각 상자에 역할명과 그 자리에 배치된 직원의 특성이 함께 표시됩니다. 인재 템플릿은 opc talent import 명령으로 외부 라이브러리에서 가져올 수 있고, 완성된 조직 전체를 .opcpkg 패키지로 내보내 다른 프로젝트에서 다시 쓰거나 공유할 수 있습니다.

2. 자체 운영(Self-Run): 작업 항목 상태 기계가 협업을 굴립니다

실행 단계의 어려움은 작업 자체가 아니라 불확실한 상황에서의 협업이라고 OpenOPC는 보고 있습니다. 이를 위해 작업 항목(Work Item) 상태 기계를 두고, 각 항목이 어느 단계에 있느냐에 따라 세 가지가 함께 정해집니다: 칸반의 어느 열에 놓이는지, 그 단계에서 누가 소유자인지, 지금 진행할 수 있는 상태인지입니다.

관리자 역할은 항목을 분해하고 배정한 뒤 결과를 검토해 수용하거나 재작업을 지시하거나 위로 상신합니다. 이 과정은 실행(execute), 위임(delegate), 검토(review), 통합(integrate), 재작업(rework)의 다섯 가지 모드로 이뤄집니다. 분해 결과는 의존 관계를 나타내는 방향성 비순환 그래프(DAG, Directed Acyclic Graph)를 이루므로 독립적인 항목은 병렬로 진행되고, 선행 항목이 있는 항목은 그것이 해결될 때까지 대기합니다.

위 화면에서 각 카드에 붙은 3 dep, 2 dep 표시가 선행 항목의 개수이고, 카드 안의 역할 이름이 그 단계의 소유자입니다. 오른쪽 실행 진행 패널에는 CEO에서 시작해 CTO와 CMO를 거쳐 실무 역할로 내려가는 위임 경로가 그대로 나타납니다.

작업 도중에 생기는 장애물은 두 층위에서 처리됩니다. 팀 안에서 해결할 수 있는 것은 차단 메시지(blocking message)로 처리되어 보낸 쪽이 일시 정지하고 해결에 가장 적합한 역할이 활성화됩니다. 팀의 권한을 넘어서는 것은 런타임이 사람 소유자에게 상신하므로, 사람의 판단이 필요한 시점에만 개입 요청이 올라옵니다.

3. 자체 성장(Self-Grown): 실행 기록을 역할별 교훈으로 남깁니다

실행이 끝나면 그 경험을 다음 실행에 쓸 수 있는 형태로 정리합니다. OpenOPC는 사용자 피드백을 직원 단위 평가로 분해하고, 해당 작업 항목을 소유했던 역할만 갱신합니다. 회사 전체에 공을 돌리면 아무것도 학습되지 않는다는 것이 이 설계의 근거입니다.

실행 기록 자체는 그대로 두기에는 잡음이 많으므로, 역할별 작업을 신호가 높은 교훈으로 증류(Distillation)해 그 역할의 개인 경험 프로필에 저장합니다. 반복해서 나타나는 교훈은 공유 플레이북으로 승격되어 새로 채용된 직원이 처음부터 물려받습니다.

OpenOPC의 Office UI

OpenOPC의 브라우저 인터페이스는 세 개의 페이지로 나뉩니다: 세션과 칸반, 대화, 진행 상황을 다루는 Workspace, 에이전트를 캐릭터로 배치하는 Office, 회사 구조와 채용을 다루는 Org입니다.

Office 페이지는 실행 중인 조직을 애니메이션 오피스로 보여줍니다. 각 캐릭터를 누르면 상태와 현재 도구, 현재 작업, 역할, 좌석을 확인할 수 있고 자리를 옮길 수도 있습니다. 오른쪽 패널에는 사무실별 인원과 활성 에이전트 목록, 각 에이전트가 지금 쓰고 있는 도구가 나열됩니다.

OpenOPC의 승인 정책과 작업 공간 신뢰

에이전트가 셸 명령을 실행하는 도구인 만큼 권한 조절이 별도 설정으로 분리되어 있습니다. system_config.yaml의 autonomy 절에 있는 max_auto_approve_risk가 자동 승인 가능한 최대 위험 수준을 정하며, 기본값은 medium입니다.

모든 네이티브 도구 호출은 실행 전에 위험도가 분류됩니다. rm -rf, drop table, 강제 푸시처럼 알려진 파괴적 명령과 자격 증명, 배포 관련 키워드는 high 또는 critical로 분류되어 항상 사람에게 올라오고, ls, git status처럼 허용 목록에 있는 접두어는 low로 분류됩니다. 그 사이의 나머지는 medium으로 분류되어 자동 승인 전에 LLM 검토를 한 번 거칩니다. 각 도구를 처음 쓸 때는 설정과 무관하게 항상 확인을 받습니다.

프로젝트 로컬 설정 파일이 실행 파일 경로와 원격 엔드포인트, 자격 증명 출처를 지정할 수 있기 때문에, OpenOPC는 기존 프로젝트의 설정을 불러오기 전에 작업 공간 신뢰를 요구합니다. 파일을 검토한 뒤 opc trust add /path/to/workspace로 승인하며, 비대화형 명령은 신뢰가 없으면 실패하도록 되어 있습니다. 신뢰는 보안 관련 소스 파일의 지문에 묶여 있어 시스템이나 LLM, 에이전트, 채널 설정이 바뀌면 갱신이 필요합니다.

OpenOPC 설치 및 사용법

저장소는 uv를 이용한 설치를 권장합니다. 다음은 macOS 기준 절차입니다:

brew install uv

cd /path/to/OpenOPC
uv python install 3.12
uv venv --python 3.12
source .venv/bin/activate

# OpenOPC 설치
uv pip install -e .

# 브라우저 도구용 Chromium (선택)
uv run python -m playwright install chromium

# 로컬 설정, 메모리, 스킬, 프로젝트, 작업 공간 폴더 초기화
uv run opc init

opc init 이후 .opc/config/llm_config.yaml에 API 키를 적거나, api_key_env에 키를 담은 환경 변수 이름을 지정합니다. 설정이 끝나면 uv run opc ui로 브라우저 UI를 띄우고 기본 주소인 http://localhost:8765에 접속합니다.

터미널에서 바로 실행할 수도 있습니다:

# 대화형 CLI
uv run opc chat -p demo

# 단발 작업(Task 모드), 실행 에이전트를 codex로 지정
uv run opc chat -p demo --mode task --agent codex "Refactor this module and run focused tests"

# 회사 모드(Company 모드), 내장 Corporate 조직 사용
uv run opc chat -p demo --mode company --company-profile corporate "Plan, implement, review, and document this feature"

# 스크립트, CI 형태의 비대화형 실행
uv run opc exec -p demo --mode task --agent native --json "Summarize the current repo status"

세션과 작업 항목, 통신 상태를 들여다보는 명령도 함께 제공합니다:

opc runtime status -p demo
opc work-item list -p demo
opc comms state <task_id> -p demo

opc chat 안에서는 /mode company corporate, /agent codex, /org, /talent list와 같은 슬래시 명령을 쓸 수 있으며, 전체 명령표는 저장소의 docs/cli-chat-slash.md에 정리되어 있습니다.

OpenOPC의 라이선스

OpenOPC는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

OpenOPC 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

이 도구를 직접 설치해 사용해보셨다면, 파이토치 한국 사용자 모임 회원들을 위해 경험이나 팁을 댓글로 남겨주세요!