[Plane] 직접 띄워서 쓰는 오픈소스 이슈 트래커
![[Plane] 직접 띄워서 쓰는 오픈소스 이슈 트래커](https://blog.kakaocdn.net/dna/dspWN1/dJMcagAlap2/AAAAAAAAAAAAAAAAAAAAANp-s-mUvIYxRGLBCfkpo6mBiT3kJUn0vHl69G8rj34o/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1790780399&allow_ip=&allow_referer=&signature=qZ0JlIOSp3eI8oq3j46M4%2Fp0sOo%3D)
개발자 도구 · 협업 & 이슈
[Plane] 직접 띄워서 쓰는 오픈소스 이슈 트래커
이슈 트래커를 남의 서버 말고 내 서버에 두고 싶을 때 후보로 올라오는 도구예요. AGPL v3.0으로 소스가 전부 공개돼 있습니다. Docker가 돌아가는 머신이면 스크립트 한 줄로 올라가요. 설치 방법과 에디션 차이, 작업을 나누는 구조, 운영 명령까지 공식 문서 기준으로 정리했어요.
대체하는 건 트래커 자체가 아니라 데이터가 놓이는 자리예요
Plane은 이슈 트래킹과 문서를 한 워크스페이스에서 다루는 프로젝트 관리 도구예요. 보드·스프레드시트·리스트·간트 네 가지 레이아웃, 기간을 끊어 진행률을 보는 사이클, 위키 형태의 문서가 제품에 들어 있습니다.
기능만 보면 시중의 SaaS 트래커와 크게 다르지 않아요. 차이는 어디에 설치하느냐에 있습니다. 클라우드 버전도 있지만, 이 도구가 이름을 알린 지점은 셀프호스팅 쪽이에요. 소스가 GitHub에 전부 열려 있고 라이선스는 GNU AGPL v3.0입니다.
구성 요소는 평범한 웹 스택이라 운영 부담을 가늠하기 쉬워요. 프런트엔드는 React와 React Router, Vite로 만들었고 백엔드는 Django와 Node.js입니다. 데이터는 PostgreSQL에, 캐시는 Redis에 들어가고 배포는 Docker 컨테이너로 묶여 있어요. 이슈 데이터가 내 Postgres 안에 그대로 남는다는 뜻이라, 외부 SaaS에 업무 데이터를 올리기 어려운 조직이나 홈랩 서버를 굴리는 쪽에서 후보로 올립니다.
에디션이 세 갈래인데 서로 다른 코드베이스예요
설치 문서를 열면 가장 먼저 걸리는 대목이 이 부분이에요. Plane은 Community, Commercial, Airgapped 세 가지 에디션을 따로 배포합니다. 공식 문서는 이 셋이 기능 토글이 아니라 별개의 코드베이스라고 못 박고 있어요. 그래서 나중에 갈아타려면 별도의 업그레이드 경로를 밟아야 합니다.
| 구분 | Community | Commercial | Airgapped |
|---|---|---|---|
| 라이선스 | AGPL v3.0 오픈소스 | 클로즈드 소스 | 클로즈드 소스 |
| 라이선스 키 | 필요 없음 | 온라인 활성화 | 오프라인 활성화 |
| 기능 범위 | 클라우드 Free 티어와 동일 | 클라우드와 동일 (키로 Pro·Business 해제) | Commercial과 동일 |
| 무료 사용 | 제한 없이 무료 | 워크스페이스당 12석 무료 티어 내장 | Commercial과 동일 |
| 업데이트 | 공개 릴리스 | 공식 레지스트리 | 자체 Docker 레지스트리 |
Community는 소스를 직접 뜯어보고 고칠 수 있는 대신 기능이 클라우드 무료 티어 수준으로 맞춰져 있어요. Pro나 Business에 들어가는 항목은 빠져 있습니다.
Commercial은 소스가 닫혀 있는 대신 워크스페이스당 12석까지 쓸 수 있는 무료 티어가 처음부터 들어 있어요. 유료 기능은 Prime 포털에서 받은 라이선스 키로 여는 방식인데, 이 키가 워크스페이스 하나와 머신 하나에 묶입니다. 서버를 옮길 계획이 있다면 미리 확인해 둘 항목이에요.
Airgapped는 바깥으로 나가는 네트워크가 막힌 환경용이에요. 라이선스 활성화를 오프라인으로 하고, 업데이트도 자체 Docker 레지스트리에서 당겨옵니다.
설치는 스크립트 한 줄인데, 에디션에 따라 명령이 달라요
Docker Compose 방식이 가장 단순한 경로예요. 문서가 밝힌 최소 사양은 x64/AMD64 또는 AArch64/ARM64 기준 2코어, 램 4GB이고 운영 환경은 8GB를 권장합니다. 운영체제는 Ubuntu, Debian, CentOS, Amazon Linux 2 또는 2023, macOS, WSL2를 켠 Windows를 지원해요. 사전 조건은 Docker가 설치돼 돌아가는 상태, 그리고 docker 서비스에 접근 가능한 사용자 계정입니다.
Community 에디션 (AGPL, 라이선스 키 없음)curl -fsSL -o setup.sh https://github.com/makeplane/plane/releases/latest/download/setup.shchmod +x setup.sh./setup.sh# Commercial 에디션 (Prime CLI, 12석 무료 티어 내장)curl -fsSL https://prime.plane.so/install/ | sh -
설치 과정에서는 두 가지 모드를 고르게 돼 있어요. Express는 기본 설정 그대로 올립니다. Advanced를 고르면 데이터베이스와 Redis, 스토리지 같은 항목을 따로 지정해요. 이미 운영 중인 Postgres나 S3 호환 스토리지가 있으면 후자로 붙이는 구성이에요.
포트는 plane.env 파일에서 정합니다. HTTP는 LISTEN_HTTP_PORT로 80번, HTTPS는 LISTEN_HTTPS_PORT로 443번이 기본값이에요. 같은 머신에서 웹 서버를 이미 돌리고 있다면 8080이나 4430처럼 다른 번호로 바꿔 두면 됩니다.
Docker Compose 말고도 경로는 여러 갈래예요. 프로덕션 규모라면 Helm을 쓰는 Kubernetes 배포가 있어요. 그 밖에 Docker AIO, Docker Swarm, Podman Quadlets, Coolify나 Portainer 같은 관리형 플랫폼도 문서에 올라와 있습니다.
작업은 Work Item 하나로 두고 사이클과 모듈로 묶어요
다른 트래커를 쓰던 사람이 처음 헷갈리는 지점이 이 구조예요. 개념 이름만 정리해 두면 화면이 훨씬 빨리 읽힙니다.
Work Item
가장 작은 작업 단위예요. 리치 텍스트 에디터로 본문을 쓰고 파일을 첨부합니다. 상태, 라벨, 타입, 커스텀 속성이 붙고 항목끼리 관계를 걸 수 있어요. 다른 도구에서 이슈나 티켓이라 부르던 자리입니다.
Cycle
기간을 끊어 작업을 담는 단위예요. 스프린트에 해당하는 개념입니다. 번다운 차트로 남은 양이 줄어드는 속도를 봅니다. 2주씩 끊어 도는 팀이면 사이클 하나가 스프린트 하나가 돼요.
Module
기간이 아니라 덩어리로 나누는 단위입니다. 큰 프로젝트를 기능 단위나 영역 단위로 쪼갠 다음 각 모듈 안에 관련 작업을 모아요. 사이클이 가로줄이면 모듈은 세로줄에 가깝습니다.
View
필터를 저장해 두는 화면이에요. 담당자나 라벨, 상태 조건을 걸어 두고 필요할 때 그 조합으로 바로 들어갑니다. 보드, 스프레드시트, 리스트, 간트 중 원하는 레이아웃으로 같은 데이터를 다르게 볼 수 있어요.
Intake
바깥에서 들어오는 요청을 한 곳에 받아 두는 입구예요. 무료 티어에도 들어 있습니다. 이메일과 폼으로 받는 형태는 상위 요금제에 배정돼 있어요.
Page와 Analytics
Page는 작업 항목과 같은 워크스페이스 안에 두는 문서예요. 회의록이나 스펙을 트래커 밖으로 내보내지 않고 옆에 붙여 두는 용도입니다. Analytics는 진행 상황을 집계해 보여주는 화면입니다. 속도와 업무량, 막힌 항목을 대시보드로 봅니다.
운영 명령은 Prime CLI에 모여 있지만 설치 방식을 탑니다
Commercial 에디션을 Prime CLI로 올렸다면 그 뒤 운영은 같은 CLI로 합니다. 서비스 단위로 start, stop, restart를 걸고, healthcheck로 각 서비스의 상태와 에러를 확인해요. monitor는 인스턴스 상태를 지켜보는 명령입니다. repair는 흔한 오류를 진단해 고치는 쪽이에요.
Prime CLI 주요 명령prime-cli healthcheck # 전체 서비스 상태·에러 확인prime-cli monitor # 인스턴스 헬스 모니터링prime-cli repair # 흔한 오류 자동 진단·복구prime-cli configure # 포트·업로드 용량·외부 Postgres/Redis/S3 설정prime-cli upgrade # 새 버전 확인 후 확인받고 업그레이드prime-cli update-cli # CLI 자체 최신화prime-cli uninstall # 데이터·로그 폴더는 남기고 제거
configure는 대화형 폼으로 뜨는 명령이라 편해요. 리스닝 포트, 파일 업로드 최대 용량, 외부 Postgres와 Redis, AWS S3 주소를 이 안에서 지정합니다. 업그레이드는 새 버전이 있는지 먼저 확인하고 사용자 확인을 받은 다음 내려받는 순서예요. uninstall은 데이터와 로그 폴더를 남긴 채 제거합니다.
API가 열려 있어서 바깥 시스템에 붙이기 좋아요
REST API가 공개돼 있습니다. 클라우드는 api.plane.so가 기준 주소예요. 셀프호스팅 인스턴스는 자기 도메인을 씁니다. 인증은 X-API-Key 헤더에 개인 액세스 토큰을 넣는 방식이에요. 토큰은 프로필 설정의 Personal Access Tokens에서 만듭니다. 앱 형태로 붙일 때는 OAuth 액세스 토큰을 Authorization 헤더에 Bearer로 넘기는 경로도 있습니다.
제한은 클라이언트당 분당 60회예요. 남은 횟수와 초기화 시점은 응답 헤더의 X-RateLimit-Remaining, X-RateLimit-Reset으로 돌아옵니다. 배치로 대량 이관을 돌린다면 이 숫자가 설계 기준이 돼요.
엔드포인트는 프로젝트, 작업 항목, 상태·라벨·타입 같은 메타데이터, 커스텀 속성, 항목 간 관계와 댓글·첨부, 사이클·모듈·페이지·에픽 같은 조직 단위, 워크스페이스 멤버와 초대 관리로 나뉘어 있습니다.
먼저 알고 들어가면 좋은 항목들이에요
- 에디션을 처음에 잘 고를 것. 셋이 별개 코드베이스라 나중에 옮기려면 별도 절차를 밟아야 해요.
- Commercial 라이선스 키는 워크스페이스 하나, 머신 하나에 묶입니다. 서버 이전이나 이중화 계획이 있으면 미리 확인해 둘 부분이에요.
- 포트 80과 443이 기본값이에요. 같은 호스트에 다른 웹 서버가 떠 있으면 plane.env에서 먼저 바꿔야 충돌을 피합니다.
- 램 4GB는 시작 기준이에요. 문서는 운영 환경에 8GB를 권합니다. Postgres와 Redis를 같은 머신에 얹는 구성이라 사양을 빠듯하게 잡으면 부담이 커요.
- 백업 대상은 결국 Postgres와 파일 스토리지예요. 컨테이너를 지웠다 다시 올리는 것과 데이터를 지키는 건 별개 문제입니다.
- AGPL 조건을 확인할 것. 사내 사용이 아니라 외부에 서비스로 제공할 계획이면 라이선스 검토가 먼저예요.
어떤 팀이 후보로 올려볼 만한가
업무 데이터를 외부 SaaS에 두기 어려운 조직이 1순위예요. 이슈 본문과 첨부가 통제 범위 안 Postgres와 스토리지에 남고, 네트워크가 완전히 막힌 환경까지 겨냥한 에디션이 따로 있습니다.
인원이 적은 팀이라면 클라우드 쪽 숫자도 같이 놓고 보면 판단이 빨라요.
| 플랜 | 가격 | 주요 조건 |
|---|---|---|
| Free | 0달러 | 최대 12명. 프로젝트·작업 항목·사이클·모듈·레이아웃·뷰·인테이크·추정치·프로젝트 페이지 |
| Pro | 사용자당 월 6달러 | 작업 항목 타입과 속성, 워크스페이스 위키, 시간 추적, 템플릿, 대시보드, 연동 |
| Business | 사용자당 월 13달러 | 프로젝트 템플릿, 반복 작업 항목, 이메일·폼 인테이크, 중첩 페이지, 워크플로 |
| Enterprise Grid | 별도 견적 | 전용 배포, 세분화된 접근 제어, 다중 워크플로와 승인, LDAP, 감사 로그 |
거꾸로 이런 경우엔 셀프호스팅이 이득이 아닐 수 있어요. 인원이 12명 안쪽이고 데이터 위치에 제약이 없다면 클라우드 무료 티어로 대부분 커버되니, 서버 한 대를 더 관리하는 비용이 순수한 추가 부담으로 남습니다.
시작 순서는 단순해요. 램 8GB짜리 서버에 Docker를 먼저 올립니다. 사내 전용이면 Community 스크립트로, 12석 무료 티어와 유료 기능 확장 여지를 두려면 Prime CLI로 설치해요. 포트를 먼저 정리한 다음 프로젝트 하나를 만들어 사이클과 모듈을 한 번 돌려보면 이 구조가 팀 방식에 맞는지 판단이 서요.
이 글은 직접 사용기가 아니라 공식 사이트·문서·저장소에서 확인한 내용을 객관적으로 정리한 자료예요. 버전과 요금제는 바뀔 수 있으니 설치 전 공식 문서를 다시 확인하시길 권합니다.
'개발자 도구 > 협업 & 이슈' 카테고리의 다른 글
| [Excalidraw] 다이어그램을 손그림으로 그리는 이유 (0) | 2026.07.29 |
|---|---|
| [Linear] 이슈 트래커에서 에이전트 작업대로 (0) | 2026.07.17 |
| [Slack] 잘 안 쓰는 단축키와 사이드바 정리법 (0) | 2026.06.29 |
| [Linear] Jira 대신 쓰는 키보드 우선 이슈 트래커 (0) | 2026.06.08 |
| Slack은 나홀로 운영자에게는 무거워요 — 자동화 알림은 Telegram (0) | 2026.05.19 |
📚 같이 보면 좋은
"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 일정액의 수수료를 제공받습니다."