OSS 를 fork 해 내 제품으로 (1/2) — Plane 은 어떤 도구이고 왜 좋은가

요즘 OSS 프로젝트 관리 도구를 자체 호스팅으로 다시 끌어들이는 팀이 늘고 있다. 이유는 셋쯤이다. SaaS(Software as a Service: 서비스형 소프트웨어) 가격이 매년 오른다. 프로덕트 데이터를 외부에 두는 부담이 커진다. 무엇보다 그 위에 LLM(Large Language Model: 대규모 언어 모델) agent 를 얹어 일하는 방식을 직접 짜고 싶다는 욕구가 생겼다.

NeuTeam 도 같은 이유로 2년 전 Plane 을 자체 호스팅으로 올렸다. 그 사이 팀이 30명까지 늘었고, Plane 이 맡는 일도 점점 많아졌다. 이 글에서는 Plane 이 어떤 도구이고 Jira 같은 선택지와 비교해 어느 자리에 있는지를 짚는다. 다음 편에서는 이 코드를 fork 해 agentic-plane 으로 키워 가는 과정을 다룬다.

Plane 은 무엇인가

Plane 은 React 프런트엔드와 Django 백엔드, PostgreSQL/Redis/RabbitMQ 를 묶은 OSS 프로젝트 관리 도구다. AGPL(Affero General Public License: 어피로 일반 공중 라이선스)-3.0 으로 풀려 있고, 누구나 자체 서버에 docker-compose 한 번으로 올린다. 코드는 makeplane/plane 저장소 한 곳에서 관리된다 (GitHub 저장소).

핵심 모듈은 여섯 개다.

• Issues — 작업 단위. 리치 텍스트, 첨부, 이슈 간 참조.
• Cycles — 스프린트. 번다운 차트와 진행률.
• Modules — 큰 작업을 잘게 나눠 묶는 단위.
• Views — 리스트/칸반/캘린더/타임라인/테이블 다섯 가지 레이아웃과 사용자 정의 필터.
• Pages — 같은 워크스페이스 안의 위키. 이슈를 멘션으로 끌어다 쓸 수 있다.
• Analytics — 대시보드와 인사이트.

엔터프라이즈에서 흔히 찾는 SSO(Single Sign-On: 통합 인증), 감사 로그, 승인 워크플로, 에픽, 에어갭 배포는 EE(Enterprise Edition: 엔터프라이즈 에디션) 안에 있고 CE(Community Edition: 커뮤니티 에디션) 에서는 빠져 있다 (공식 비교 문서).

📸 캡처 자리 — capture-1.png 로 저장

Plane 자체 호스팅 인스턴스의 워크스페이스 대시보드 메인 화면. 사이드바에 Issues / Cycles / Modules / Pages 가 보이고, 프로젝트 한두 개에 실제 이슈가 들어 있는 상태가 좋다. 1280×720 권장.

비교군 정렬

검토 대상에 자주 오르는 도구들을 한 표로 늘어놓는다.

가격은 발행 시점 공식 가격표를 따랐고 부가 모듈/플러그인은 따로 잡힌다 (Atlassian 가격표, Linear 가격표, OpenProject 가격표).

포지셔닝 쿼드런트

가격표 하나로는 결정이 어렵다. 두 축을 더 얹어 본다. 가로축은 "폐쇄 ↔ 오픈", 세로축은 "단순(개인/소팀) ↔ 강력(엔터프라이즈)" 다.

• 우상단 (오픈 + 강력): Plane, OpenProject
• 우하단 (오픈 + 단순): GitHub Projects
• 좌상단 (폐쇄 + 강력): Jira
• 좌하단 (폐쇄 + 단순): Linear (기능 폭은 의도적으로 좁히고 UX 의 단순함을 우선한 쪽)

우리 기준으로 Plane 은 우상단에 놓인다. 자체 호스팅이 되고, 모듈 구성은 Jira 만큼 두꺼우면서, 화면 응답은 Linear 쪽에 붙어 있다. OpenProject 와 같은 사분면이지만 UX 결이 다르다(OpenProject 는 간트와 일정 운영 쪽에 무게가, Plane 은 이슈 트래킹과 사이클 운영 쪽에 무게가 실려 있다).

2년 써보고 남은 세 가지

자체 호스팅으로 24개월 굴려 본 끝에 가장 먼저 손에 익은 부분 세 가지를 적는다. 각 항목 끝에는 커뮤니티에서도 같은 의견이 주류인지 확인해 붙였다.

저장 버튼이 없다. 제목, 설명, 라벨, 담당자 배정 같은 동작이 전부 입력 즉시 저장된다. 작성하다 멈춰서 다른 사람을 불러 같이 보고 돌아와도 입력이 그대로 살아 있다. Plane 의 마케팅에서는 자주 강조되지만, GitHub Issues 나 Hacker News 댓글에서 "save 버튼이 없는 것" 자체를 칭찬한 사례는 의외로 드물었다. 실사용 시간이 어느 정도 쌓여야 비로소 체감되는 차이로 보인다.

위키가 같은 워크스페이스에 있다. Plane Pages 는 이슈와 같은 사이드바에서 열린다. 회의록을 쓰다가 그 자리에서 작업 이슈를 만들고, 거꾸로 이슈의 의사결정 기록을 Pages 로 끌어 올린다. Notion 과 Jira 를 따로 굴리는 팀에 비해 컨텍스트 스위칭이 한 단계 줄어든다. 공식 블로그에서도, 사용자 리뷰에서도 자주 언급되는 강점이다 (Plane 블로그).

화면이 빨리 뜬다. Jira 의 화면 전환은 곧잘 초 단위로 늘어진다. 커뮤니티에서 가장 자주 회자되는 대비 항목이다. Hacker News 의 한 댓글은 "Jira 의 로딩 시간은 커피 한 잔 단위로 잰다" 고 표현했고, 같은 스레드에서 Plane 과 Linear 가 함께 빠른 대안으로 묶여 거론됐다 (Hacker News 토론).

한계와 트레이드오프

같은 커뮤니티에서 자주 지적되는 약점도 함께 적어 둔다.

• SSO 가 EE 한정이다. 자체 호스팅 CE 만 쓰는 조직은 SSO 를 직접 붙이거나 EE 로 갈아타야 한다. 보안 기능이 유료라는 비판이 반복된다 (Hacker News 토론).
• 커스텀 필드와 리포트가 얕다. Jira 의 자동화 규칙이나 JQL(Jira Query Language: 지라 질의 언어) 만큼의 깊이는 아직 못 따라간다(여러 사용자 리뷰에서 반복적으로 지적된다).
• 모바일이 약하다. iOS 동기화가 곧잘 수동 새로고침을 요구한다.
• Jira → Plane 마이그레이션이 베타 수준이다. 큰 워크스페이스 전환은 데이터 손실 위험을 끌어안고 가야 한다.
• Linear 의 UI(User Interface: 사용자 인터페이스) 를 닮았다는 비판. 호불호가 갈린다.

📸 캡처 자리 — capture-3.png 로 저장

Plane Pages(내장 위키) 화면. 페이지 안에 이슈를 멘션(@) 으로 연결한 흔적이 보이면 더 좋다. 본문이 어느 정도 채워진 페이지 한 장.

30인, 2년, 절감액

가격을 우리 환경에 맞춰 다시 계산해 봤다. 30명, 24개월, 자체 호스팅 인프라는 4 vCPU + 8GB RAM VM(Virtual Machine: 가상 머신) 한 대와 같은 사양의 PostgreSQL 인스턴스로 잡았다.

Standard 기준으로 24개월 동안 4,500달러쯤이 직접 비용으로 남았고, Premium 기준으로는 9,200달러쯤이 남았다. 다만 더 큰 이득은 비용 그 자체가 아니다. 이슈 데이터가 우리 인프라 안에 있고, 그 위에 우리가 원하는 자동화를 직접 얹는다는 점이 진짜 무게다.

그래서 fork 한다

여기까지가 우리가 Plane 을 쓰는 이유다. 다음 편은 이 코드를 어떻게 fork 해 agentic-plane 이라는 우리 제품으로 키워 가는지를 다룬다. 라이선스를 어떻게 검토했는지, 원작자에게 무엇을 알려야 하는지, 우리 수정분과 upstream 의 변화를 어떻게 같이 끌고 가는지에 대한 운영 매뉴얼이다.

(시리즈 1/2 — 다음 편: "OSS 를 fork 해 내 제품으로 (2/2) — Plane 을 agentic-plane 으로 키우는 전 과정")