Paca, AI 동료를 보드 위에 올린 프로젝트 관리

Jira 대체제보다 흥미로운 것은 'AI 팀원' 모델이다

Paca GitHub 저장소는 자신을 Jira, Trello, ClickUp, Monday의 가볍고 무료인 오픈소스 대안이라고 소개한다. 2026년 6월 14일 기준 GitHub API에서 별은 400개대, 라이선스는 Apache 2.0, 기본 설명은 인간과 AI 에이전트가 같은 보드, 같은 스프린트, 같은 목표에서 협업하는 self-hosted 플랫폼이다.

중요한 지점은 "AI 기능이 있는 프로젝트 관리 도구"가 아니라는 점이다. Paca는 AI 에이전트를 사이드바 챗봇이나 자동화 버튼이 아니라 Scrum 팀의 참여자로 놓는다. README는 에이전트가 스프린트에 배정되고, 태스크를 집어 들고, BDD 스펙과 시스템 설계 문서에 기여하며, 같은 Scrumban 보드에서 상태를 업데이트한다고 설명한다.

Kanbots, 칸반 보드가 병렬 에이전트 런처가 되다가 보드를 에이전트 실행 표면으로 본다면, Paca는 그 표면을 팀 운영 체계로 확장한다. 티켓은 사람의 업무 요청서가 아니라 에이전트가 이해하고 실행하고 보고해야 하는 계약이 된다.

채팅형 AI PM 도구와 다른 점

많은 협업 도구는 이미 AI 요약, 자동 분류, 회의록 정리, 티켓 생성 기능을 붙이고 있다. Atlassian도 Jira 생태계에서 AI 기능을 강화하고, ClickUp과 Monday도 자동화와 요약 기능을 경쟁한다. Paca의 차별점은 AI를 도구 기능이 아니라 팀 구성원처럼 모델링한다는 데 있다.

Model Context Protocol은 외부 도구와 에이전트를 구조적으로 연결하는 표준으로 자리 잡고 있다. Paca가 MCP 서버를 제공한다는 점은 중요하다. 에이전트가 화면을 긁는 대신 프로젝트, 태스크, 스프린트, 문서에 API로 접근할 수 있기 때문이다. 이는 Open Envelope, 에이전트 팀 정의의 표준화 실험이 말한 팀 스키마 문제와도 닿아 있다.

self-hosted와 플러그인이 주는 현실적 의미

Paca는 self-hosted를 내세운다. 개발 조직 입장에서는 작업 보드에 고객명, 장애 기록, 로드맵, 보안 이슈, 소스 링크가 들어가기 때문에 데이터 위치가 중요하다. AI 에이전트를 연결하면 위험은 더 커진다. 에이전트가 티켓을 읽고 코드를 수정하고 배포 상태를 확인할 수 있다면 프로젝트 관리 도구는 사실상 권한 허브가 된다.

README는 WASM 기반 플러그인, 설정 중심 워크플로, OpenHands 기반 에이전트 실행을 언급한다. OpenHands는 에이전트가 개발 작업을 수행하는 오픈소스 프레임워크이며, Paca는 이런 에이전트를 보드와 연결하려는 방향을 택한다. 플러그인 샌드박스와 capability 기반 권한 모델은 아직 검증이 필요하지만, 방향은 맞다. AI 협업 도구는 확장성보다 권한 경계가 먼저다.

Distributed system testing, AI 에이전트 스킬의 다음 단위는 에이전트가 시스템 작업을 맡으려면 테스트와 관찰 가능성이 필요하다고 했다. Paca 같은 보드 중심 도구는 그 관찰 가능성을 업무 수준에서 제공할 수 있다. 누가 어떤 티켓을 잡았고, 어떤 증거를 남겼고, 어떤 리뷰를 통과했는지가 에이전트 운영의 기본 로그가 된다.

한국 개발 조직에는 더 엄격한 보드가 필요하다

한국의 개발팀은 Jira나 Notion, GitHub Issues, Slack 메시지가 섞인 상태에서 일하는 경우가 많다. 사람만 일할 때는 암묵지가 어느 정도 버틴다. 하지만 AI 에이전트가 들어오면 모호한 티켓은 곧 잘못된 실행으로 이어진다. "버그 수정"이라고만 써둔 티켓은 사람에게도 부족하지만, 에이전트에게는 위험하다.

그래서 Paca의 의미는 특정 제품 채택보다 운영 원칙에 있다. 티켓에는 수락 기준, 금지 영역, 테스트 명령, 관련 문서, 담당 리뷰어, 권한 범위가 있어야 한다. TDD 스킬, 코딩 에이전트 검증의 기본 단위가 말한 검증 루프를 프로젝트 관리 단계에서 강제해야 한다. AI 팀원이 늘수록 보드는 더 가벼워지는 것이 아니라 더 명시적이어야 한다.

자주 묻는 질문

Q1: Paca는 Jira를 바로 대체할 수 있나요?

A: 초기 오픈소스 프로젝트이므로 성숙도와 조직 요구사항을 확인해야 한다. 다만 AI 에이전트 협업을 중심에 둔 실험으로는 의미가 크다.

Q2: AI 에이전트를 보드에 올리는 장점은 무엇인가요?

A: 작업 배정, 상태 업데이트, 수락 기준, 리뷰 기록이 한곳에 남는다. 채팅창에서 흩어지는 지시보다 운영 추적이 쉽다.

Q3: MCP 서버가 왜 중요한가요?

A: 에이전트가 화면 자동화 대신 구조화된 프로젝트 데이터에 접근할 수 있다. 이는 오류와 권한 남용을 줄이는 기반이 된다.

Q4: self-hosted가 꼭 필요한가요?

A: 보드에는 민감한 제품 정보와 고객 정보가 많다. AI 에이전트까지 연결한다면 데이터 위치와 접근 권한을 직접 통제하려는 수요가 커진다.

Q5: 한국 팀이 지금 적용할 수 있는 원칙은 무엇인가요?

A: 에이전트용 티켓 템플릿, 명확한 수락 기준, 테스트 명령, 금지 파일 목록, 리뷰어 승인, 활동 로그를 먼저 만들면 된다.