그룹웨어 도입, 오픈소스로 시작했다가 자체 개발로 바꾼 이유

2026년 7월 19일, 사내 협업툴 파일럿의 출시 점검표에서 완료 칸이 모두 채워졌습니다. 한국어 번역 약 1,700개와 회사 로고를 입힌 화면, 모바일 푸시와 백업까지 들어간 상태였습니다.

다음 날 저는 그 파일럿을 접었습니다.

결재 하나를 올리려면 로그인을 한 번 더 해야 했기 때문입니다. 화면도 쓰는 사람 마음에 들지 않았습니다.

직원 수십 명이 쓰는 그룹웨어를 오픈소스로 시작했다가 자체 개발로 옮기기까지의 판단을 적습니다. 같은 갈림길에 선 총무·경영지원 담당자분이 쓸 수 있게 끝에 판단표를 붙였습니다.

9종을 줄 세운 기준

처음 조건은 단순했습니다. 게시물과 댓글이 흐르는 피드가 있어야 했고, 직원들이 휴대폰 앱으로 알림을 받아야 했습니다.

서버는 사무실 NAS였습니다. 저사양 CPU에서 돌아가야 했고, 후보 모두 무료로 쓸 수 있어야 했습니다.

셀프호스팅 협업툴 9종에 이 조건을 대 봤습니다. 아래 표는 그중 기록에 사유가 남은 8종입니다.

후보	걸린 지점
Huly	컨테이너 15개, 메모리 8GB 요구
Plane, OpenProject	채팅 없음, OIDC 로그인 연동은 유료
Colanode	한국어 불가
Worklenz	한국어 로케일 삭제
Mattermost	무료판에서 SSO 제거
Nextcloud	2순위, 피드 구조가 약함
HumHub	1순위

조사 시점은 2026년 7월입니다. 각 제품의 정책은 그 뒤에 바뀌었을 수 있습니다.

1순위 오픈소스를 고른 근거

HumHub는 게시물과 댓글 피드를 갖춘 유일한 후보였습니다. 공식 모바일 앱과 무료 푸시가 있었습니다.

앱과 DB 컨테이너 2개면 돌아갔고, 컨테이너 크기는 약 700MB였습니다. 약한 NAS에 올리기에 맞는 무게였습니다.

라이선스는 AGPL이었습니다. 고쳐서 패키지로 독점 판매하는 길은 막힙니다.

대신 고객 서버에 구축해 주고 유지보수를 받는 방식은 충돌이 없습니다. 구축형으로 일하는 저에게는 받아들일 만한 조건이었습니다.

파일럿에 들어간 손

번역부터 했습니다. 덮어쓰기 파일 약 33개에 문자열 약 1,700개를 넣어 관리자 화면까지 한글로 바꿨습니다.

그래도 오류 화면과 위젯 쪽에 27개가 남았습니다.

화면에서는 'Powered by' 문구와 유료 마켓 광고를 지우고 회사 이름과 로고를 입혔습니다. 테마 색은 흑백으로 바꿔 다시 컴파일했습니다.

회원 가입은 잠가서 관리자가 계정을 만드는 방식으로 바꿨습니다. 이메일 OTP 2단계 인증은 전 직원에게 걸었습니다.

모바일 앱 연동과 푸시, 메일 발송, 7일치를 돌려 보관하는 백업 사이드카까지 붙였습니다. 점검표 결론 칸에는 직원 온보딩 준비가 끝났다고 적었습니다.

결재 버튼 앞의 두 번째 로그인

막힌 곳은 오픈소스에 원래 없던 기능이었습니다. 이 제품에는 한국식 전자결재가 없었고, 회의실 예약도 없었습니다.

그래서 두 기능을 별도 웹앱으로 만들어 옆에 붙이기로 했습니다. 설계 문서에는 이 구조를 "얇은 연결, 두꺼운 외부"라고 적었습니다.

메뉴만 오픈소스 쪽에 걸고, 로그인은 나중에 통합 인증 서버를 하나 더 세워 묶을 계획이었습니다.

그 '나중'이 오기 전까지 직원은 피드에서 결재를 누르면 새 로그인 창을 만납니다. 캘린더도 같았습니다.

통합 인증 서버를 세우면 로그인은 한 번으로 줄어듭니다. 그래도 관리할 서버가 하나 늘고, 두 앱의 화면 문법은 계속 다릅니다.

매일 가장 많이 누를 버튼이 협업툴 바깥에 있다는 구조도 그대로 남습니다. 저는 이 점을 인증 설정으로 메울 수 없는 문제로 봤습니다.

하루 전에 쓴 반대 결론

사실 하루 전 저는 정반대 결정을 문서로 남겼습니다. 오픈소스를 척추로 두고 새 기능만 바깥에 붙이자는 결정이었습니다.

근거는 무거웠습니다. 전부 새로 만들면 기존 기능을 같은 수준으로 맞추는 데 6~18개월이 걸리고, 그동안 새 가치가 0이라고 봤습니다.

무료 네이티브 앱과 푸시를 잃는 것도 가장 아픈 손실로 꼽았습니다. 웹으로 옮기면 iOS 푸시 제약이나 앱 심사를 따로 떠안게 됩니다.

반대쪽 근거도 같은 문서에 있었습니다. 이 오픈소스는 유지보수 모드에 들어간 Yii2 위에 있었고, 화면은 풍부한 UI에 맞지 않는 jQuery로 짜여 있었습니다.

1.18은 Bootstrap 5 전환으로 기존 화면 수정이 깨지는 버전이었고, 1.19에는 위젯·인증·파일 구조 개편이 예고돼 있었습니다. 고쳐 쓴 만큼 메이저 업그레이드 때마다 다시 손봐야 했습니다.

돌아보면 6~18개월의 기준은 오픈소스가 가진 기능 전체였습니다. 우리 조직이 매일 여는 메뉴 목록과는 길이가 달랐습니다.

매몰 비용을 기록으로 남기기

전환을 정하면서 번역 약 1,700개와 화이트라벨, 푸시 작업은 매몰 비용으로 적었습니다. 컨테이너는 멈추고 데이터 디스크는 그대로 보존했습니다.

네이티브 앱은 만들지 않기로 했습니다. 모바일은 반응형 웹으로 받습니다.

들인 작업을 지우지 않고 기록으로 남긴 이유가 있습니다. 나중에 다시 꺼낼 때 무엇이 끝나 있었는지 알아야 하기 때문입니다.

꼭 필요한 것만 남긴 기준

자체 개발을 정한 날 한국 협업툴을 다시 조사했습니다. 국내 그룹웨어 설문(2025년 12월)에서 실사용 1위는 전자결재였고, 메일과 메신저, 근태·연차가 뒤를 이었습니다.

기성 제품도 모양이 갈렸습니다. 한 제품은 전자결재를 유료 플러그인으로 본체와 따로 팔았고, 다른 제품은 13개 모듈을 같은 높이로 늘어놓았습니다.

여기서 원칙을 하나 세웠습니다. 수십 명 조직에는 보기 방식 네 종류와 자동화, 플러그인 마켓까지 갖춘 풀셋이 과잉이라는 것입니다.

그래서 업무 보드는 담당자와 마감, 상태만 남겼습니다. 결재 흐름은 처음부터 한국식으로 넣었습니다.

회수는 다음 결재자가 결재를 시작하기 전까지만 됩니다. 반려된 문서는 고쳐서 재기안합니다.

문서함은 미결·진행·완료·반려/회수·참조·임시저장의 6칸으로 나눴습니다(반려와 회수는 한 칸). 한국 그룹웨어 문서함의 표준 이름을 따랐습니다.

전환한 날 조직도와 결재 문서함, 근태·휴가, 업무 보드, 파일을 차례로 붙였습니다. 회의실 예약과 결재 기본형은 그 전에 만들어 둔 상태였습니다.

이제 모두 왼쪽 사이드바 하나 안에 있고, 로그인은 한 번입니다. 가상 조직 데이터로 옮긴 그룹웨어 시연 화면에서 결재에서 회의실 예약으로 넘어갈 때 로그인 창이 다시 뜨는지 확인해 보세요.

맞춤 개발이 맞지 않는 회사

자체 개발에도 대가가 있습니다. 무료 앱과 푸시를 내려놓았고, 보안 점검과 업데이트는 이제 만든 사람이 책임집니다.

매일 쓰는 기능이 기성 제품의 기본 기능 안에 다 있다면 그쪽이 쌉니다. 계정 하나로 모든 메뉴가 열린다면 더 그렇습니다.

반대로 결재 양식이 회사마다 특이하거나, 정산·고객관리처럼 기성 제품에 없는 업무가 붙어 있다면 맞춤 개발이 이 표 위로 올라옵니다. 이 판단을 우리 회사 요구사항으로 직접 채워 보고 싶다면 업무 시스템 도입 교육에서 4시간 동안 후보 비교표까지 함께 만듭니다.

후보를 이미 두세 개로 좁혔다면 도입 상담에서 아래 표만 같이 채워 보는 방법도 있습니다.

기성·오픈소스·맞춤 판단표

제가 파일럿 전에 이 표를 그렸다면 번역부터 시작하지는 않았을 겁니다. 왼쪽 질문에 답하고 오른쪽 칸과 비교해 보세요.

질문	제 경우	막혔을 때 생기는 일
매일 쓰는 기능 상위 3개가 기본 기능인가	전자결재가 본체에 없었음	별도 앱이나 유료 추가가 붙음
그 기능까지 로그인이 몇 번인가	결재·캘린더마다 한 번 더	통합 인증 서버가 하나 더 필요
회수·반려·재기안이 되는가	직접 만들어야 했음	결재 개발이 사실상 본업이 됨
라이선스상 고쳐 쓰고 되팔 수 있는가	AGPL, 구축형만 가능	판매·배포 계획을 다시 짬
들인 커스터마이징을 매몰 비용으로 볼 수 있는가	번역 약 1,700개를 기록만 남김	아까워서 구조 문제를 미룸

앞의 두 줄에서 막히면 커스터마이징으로 메우기 어렵습니다. 번역과 화면은 고칠 수 있었지만, 결재가 협업툴 바깥에 있다는 사실은 설정으로 바뀌지 않았습니다.

첫 줄을 채울 때는 직원 두세 명에게 지난주에 가장 많이 누른 메뉴를 물어보세요. 그 목록을 후보 제품의 기본 기능표와 나란히 놓으면 위의 두 줄이 먼저 채워집니다.

세 번째 줄은 데모 계정에서 직접 확인하세요. 기안을 올린 뒤 결재 전에 회수해 보고, 반려된 문서를 고쳐 다시 올려 보면 됩니다.