Kaneo는 가볍게 시작하는 셀프 호스팅 프로젝트 관리 도구예요
Kaneo는 가볍게 시작하는 셀프 호스팅 프로젝트 관리 도구예요
프로젝트 관리 도구가 복잡해질수록 팀은 일을 기록하는 데 더 많은 시간을 써요. Kaneo는 칸반과 이슈 추적에 집중하고, 데이터를 직접 보관할 수 있게 만든 오픈소스 도구예요. Docker Compose부터 Kubernetes, MCP 연동까지 배포와 자동화 선택지도 갖췄어요. 2
핵심 요약
| 구분 | 핵심 | 왜 볼 만한가요 |
| 제품 방향 | 칸반과 이슈 관리에 필요한 흐름을 단순한 화면에 담았어요 | Jira나 Linear의 기능이 팀 규모에 비해 무겁게 느껴질 때 비교할 수 있어요 |
| 데이터 운영 | 애플리케이션과 PostgreSQL을 직접 운영할 수 있어요 | 프로젝트와 업무 데이터를 외부 서비스에 맡기지 않는 구성이 가능해요 |
| 배포 방식 | drim CLI, Docker Compose, Coolify, Helm 차트를 제공해요 | 시험 설치와 운영 환경 배포를 서로 다른 방식으로 시작할 수 있어요 |
| 자동화 연결 | 인스턴스마다 HTTP MCP 엔드포인트를 제공해요 | Claude나 Cursor 같은 MCP 클라이언트에서 작업과 프로젝트를 다룰 수 있어요 |
1. 기능 수보다 실제 작업 흐름을 줄이는 데 집중했어요
Kaneo는 기능이 많은 프로젝트 관리 플랫폼에서 벗어나려는 도구예요. 공식 설명은 알림과 버튼, 복잡한 절차가 늘어나면 팀이 제품을 만드는 일보다 관리 화면에 더 오래 머물 수 있다고 봐요. 그래서 모든 기능이 실제 문제를 해결해야 한다는 기준을 내세워요. 칸반 보드와 이슈 관리, 추적처럼 일상적인 개발 업무에 필요한 흐름을 중심에 뒀어요. 1
이 선택은 기능이 적다는 말보다 운영 규칙을 단순하게 가져가려는 방향에 가까워요. 작은 팀은 Jira의 세밀한 권한과 워크플로를 모두 쓰지 않는 경우가 있어요. 그래도 설정 항목과 관리 절차는 계속 이해해야 해요. Kaneo는 팀이 당장 쓰는 보드와 이슈 흐름부터 시작하고, 필요한 연결을 나중에 붙이는 방식을 택했어요.
화면이 간단하다고 도입 비용까지 저절로 낮아지는 건 아니에요. 기존 Jira나 Linear에 쌓인 이슈, 사용자, 자동화 규칙을 옮길 때는 별도 검토가 필요해요. 승인 단계와 감사 기록이 많은 조직이라면 현재 기능이 내부 규정을 충족하는지도 확인해야 해요. 처음부터 전사 도구로 바꾸기보다 작은 프로젝트에서 실제 흐름을 재현해 보는 편이 안전해요.
데이터를 직접 보관할 수 있어요
Kaneo는 MIT 라이선스로 공개됐고 셀프 호스팅을 지원해요. 기본 Docker Compose 예시는 Kaneo 컨테이너와 PostgreSQL 16을 함께 구성해요. 프로젝트 이름, 이슈 내용, 담당자 정보처럼 업무 맥락이 담긴 데이터를 자체 서버에 둘 수 있어요. 외부 SaaS의 저장 위치나 요금제 정책에 맞추기 어려운 팀에는 분명한 선택지가 돼요. 2
셀프 호스팅은 데이터 소유권과 함께 운영 책임도 가져와요. 팀이 데이터베이스 백업, 버전 업데이트, 장애 복구, 접근 제어를 맡아야 해요. 자동 HTTPS와 데이터베이스 설정을 처리하는 drim CLI가 초기 작업을 줄여 주지만, 운영 중인 서버의 보안 패치와 모니터링까지 대신해 주지는 않아요. 도입 전에는 누가 서비스를 관리하고 복구할지 정해 두는 게 좋아요.
배포 선택지는 비교적 넓어요. 빠르게 시험하려면 Docker Compose를 쓸 수 있어요. Coolify용 구성 파일과 Kubernetes용 Helm 차트도 제공해요. Helm 문서에는 TLS와 프로덕션 구성을 위한 예제가 포함돼 있어요. 소규모 서버에서 시작한 뒤 기존 Kubernetes 환경으로 옮기려는 팀도 같은 프로젝트를 검토할 수 있어요.
MCP로 프로젝트 업무를 연결해요
각 Kaneo 인스턴스에는 `/api/mcp` 경로의 HTTP MCP 엔드포인트가 들어 있어요. stdio 방식이 필요한 클라이언트는 공식 `@kaneo/mcp` 패키지를 쓸 수 있어요. Claude와 Cursor 같은 MCP 클라이언트에서 작업, 프로젝트, 라벨을 다루는 구성이 가능해요. 개발 중 발견한 할 일을 대화형 도구에서 바로 등록하거나 기존 이슈를 조회하는 흐름을 만들 수 있어요. 2
MCP 연결에는 권한 범위를 먼저 정해야 해요. 개인 테스트 환경과 팀의 실제 프로젝트는 다르게 다뤄야 해요. 쓰기 권한을 가진 클라이언트가 어떤 작업을 생성하거나 수정했는지 추적할 방법도 필요해요. 편리한 연결보다 토큰 보관, 사용자별 권한, 변경 기록을 먼저 확인하면 운영 중 혼선을 줄일 수 있어요.
기술 구성은 React, Hono, TypeScript를 중심으로 짜였어요. 공개 저장소는 설치 방법과 개발 환경, 기여 지침을 함께 제공해요. GitHub 저장소에는 2026년 8월 21일 확인 기준 약 8,400개의 별이 달려 있어요. 관심이 빠르게 늘고 있지만, 별의 개수가 장기 유지보수나 조직용 기능의 완성도를 보장하지는 않아요. 릴리스 주기와 미해결 이슈, 백업·복구 문서를 함께 확인해야 해요.
왜 중요한가요
프로젝트 관리 도구를 고를 때 기능표만 비교하면 실제 운영 비용을 놓치기 쉬워요. 팀이 쓰지 않는 기능도 설정과 교육, 권한 관리 비용을 만들어요. Kaneo는 보드와 이슈 추적부터 시작하는 선택지를 보여 줘요. 현재 절차가 단순한 팀이라면 도구에 맞춰 업무를 복잡하게 만들 필요가 있는지 다시 점검할 수 있어요. 2
셀프 호스팅과 간단한 화면을 함께 제공한다는 점도 눈여겨볼 만해요. 데이터 보관 정책 때문에 SaaS를 쓰기 어렵지만, 무거운 협업 플랫폼을 직접 운영할 여력도 부족한 팀이 있어요. Kaneo는 그 사이에서 검토할 후보예요. 다만 백업과 업데이트를 맡을 사람이 없다면 관리형 서비스보다 총비용이 더 커질 수 있어요.
도입 검토는 작은 프로젝트 하나로 시작할 수 있어요. 현재 쓰는 보드의 상태값과 담당자 규칙을 그대로 옮겨 봐요. 이슈 생성부터 완료까지 걸리는 시간과 관리 화면을 오가는 횟수를 비교해요. MCP를 연결한다면 처음에는 조회 권한만 열고, 변경 기록을 확인한 뒤 쓰기 범위를 늘리는 편이 좋아요. 이런 시험을 거치면 단순한 화면이 실제 팀의 작업을 줄이는지 판단할 수 있어요.
Kaneo는 Jira나 Linear의 모든 기능을 그대로 복제하려는 제품은 아니에요. 복잡한 포트폴리오 관리와 세밀한 조직 권한이 필요한 팀에는 기존 도구가 더 맞을 수 있어요. 반대로 칸반, 이슈 추적, 자체 데이터 보관이 핵심인 팀이라면 비교 비용이 크지 않아요. Docker Compose로 별도 환경을 만들어 실제 업무 한 주를 운영해 보면 적합성을 빠르게 확인할 수 있어요.
참고 자료
- Kaneo - 필요한 것만 담은 오픈소스 프로젝트 관리 도구 — GeekNews
- usekaneo/kaneo — GitHub