재미있는 건 Git 자체는 분산을 전제로 만든 도구라는 점입니다. 저장소는 복제할 수 있고, 어디로든 옮길 수 있게 설계됐죠. 그런데 협업은 대개 호스팅 서비스, 즉 플랫폼 한 곳에 중앙화되면서 락인(lock-in)이 생깁니다. 쉽게 말해, 기본 코드 작업은 분산돼도 내 일하는 방식은 한 플랫폼에 묶이는 겁니다.

그렇다고 불만이 크지는 않습니다. GitHub 자체가 워낙 잘 만든 곳이니까요.

그래도 속도가 느려 답답할 때, 비용이 갑자기 부담될 때, 결국 MS가 주도하는 플랫폼에 생태계가 종속된다는 감각이 불편할 때가 있죠. 그럴수록 중요한 건 막연한 탈출이 아니라 내가 원하는 ‘조건’을 먼저 정하는 일입니다. 그래서 이 글에서 정말로 하고 싶은 말은 “GitHub로부터 도망친 곳에 낙원은 없을까?”가 아닙니다. 오히려 “제대로 가려면 조건을 정해야 한다”에 가깝습니다.

대안을 기능표로 줄 세우지는 않을 겁니다. 대신 프로덕트 기준으로, “누가 어떤 상황에서 만족할지”를 정리해보려 합니다. 그리고 현실적으로는 GitHub를 당장 버리기보다 유지하면서도 백업이나 미러링 같은 플랜으로 의존성을 줄이는 방법도 함께 다룰 겁니다. GitHub 대안으로 자주 등장하는 Bitbucket, Codeberg, Gitea, Forgejo, GitLab을 그 맥락에서 꺼내 보겠습니다.

GitHub는 물론 천국이지만, 천국은 때로 지루하다

GitHub가 표준이 된 건 기능이 많아서만은 아닙니다. 협업할 때 필요한 경험을 한 번에 묶어줬기 때문입니다. 코드 리뷰, 이슈 관리, 자동화(액션), 온갖 연동 앱까지요. 팀이 커질수록 “다 여기서 되네”가 강력해집니다.

채용과 포트폴리오의 창구 역할도 간과할 수 없습니다. 개발자 입장에선 “내가 한 일을 보여주는 곳”이 필요합니다. 회사 입장에선 “검증할 창구”가 필요하죠. 이게 쌓이면 네트워크 효과가 생깁니다. 사람들이 많아서 더 표준이 되고, 표준이라서 더 사람이 모입니다.

그렇게 결국 GitHub는 단순한 코드 저장소가 아니게 되었습니다. 팀의 개발 일을 굴리는 개발 운영(OS) 같은 역할을 합니다. 일정, 협업, 자동화가 한 화면에 붙어 있죠. 그래서 코드 저장소를 다른 곳으로 옮긴다는 건, 단순히 파일만 옮기는 일이 전부는 아닙니다.

락인은 ‘기능’이 아니라 ‘흐름’에서 생긴다

결국 GitHub에 종속되었다는 느낌은 기능이 좋아서가 아니라, 흐름이 굳어서 생깁니다. 예를 들어 PR 템플릿이 팀 문화가 되고, 이슈 워크플로가 업무 규칙이 됩니다. 액션 파이프라인이 배포 습관이 되고, 앱 연동이 당연한 전제가 되죠.

이렇게 되면 이동 비용이 폭발합니다. 대체 서비스가 기능을 비슷하게 제공해도, 우리 조직의 방식까지 복제하긴 어렵습니다. 사람들은 새 도구를 배우는 게 아니라 새 흐름에 몸을 맞춰야 하니까요. 그래서 떠나고 싶어도 막상 손이 안 갑니다.

쉽게 비유하면 이사와 비슷합니다. 이런저런 여유가 있다면야 이사할 집은 많을 겁니다. 그런데 현재 집의 가구 배치와 동선이 몸에 붙어버린 상태라면 어떨까요? 새 집이 더 좋아 보여도 당장 생활이 어색해질까 봐 망설이게 됩니다.

언제 ‘대안’을 진지하게 봐야 하나

그래서 대안은 더 분명하게 그것이 꼭 필요할 때 찾아봐야 합니다. “불편하다” 정도가 아니라 리스크가 비용과 일정으로 번질 때입니다. 그리고 아래 항목 중 하나라도 팀에 해당하면 비교를 시작할 신호입니다.

GitHub발 장애나 가용성 리스크가 매출·납기에 직결될 때입니다. 서비스가 멈추면 개발도 멈춥니다. 릴리즈가 밀리면 계약과 신뢰가 흔들립니다. 이때는 “편한 SaaS”라는 이유만으로 당위가 생기지는 않습니다.
저장소 위치, 접근 통제, 감사 로그 같은 규정 요구가 있을 때입니다. 쉽게 말해 “어디에 저장했는지”와 “누가 언제 뭘 했는지”를 증명해야 하는 겁니다. 컴플라이언스는 기능이 아니라 조건입니다. 조건을 못 맞추면 선택지가 사라집니다.
비용 예측 가능성이 중요해질 때입니다. 사용자가 늘면 요금도 늘 수밖에 없습니다. 특히 CI 러너 비용은 체감이 큽니다. “이번 달엔 왜 이렇게 나왔지?”가 반복되면 대안을 검토하게 됩니다.
오픈소스 철학이나 데이터 주권을 중시할 때입니다. “우리 데이터가 어디로 흘러가는지”를 신경 쓰는 팀이 늘고 있습니다. AI 학습 같은 이슈에 민감한 조직도 있습니다. 이 경우엔 Copilot 학습이 전제로 여겨지는 GitHub에 모든 코드를 공개하기가 꺼려지죠.

그래서 어떤 대안들이 있을까?

대안을 탐색할 때 고려할 부분 중 가장 먼저 “SaaS로 갈 건지”와 “운영을 감당할 건지”를 기준으로 삼았습니다. 아무래도 이는 단기간 해소하기 어려운 부분이라고 생각이 들었거든요.

“서버 관리는 힘들다”라면: SaaS 대안들

그냥 가입해서 쓰는 방식(SaaS)이 좋다면, 선택지는 의외로 명확합니다. GitLab, Bitbucket, Codeberg가 대표적입니다. 핵심은 “내가 뭘 제일 싫어하나”를 먼저 고르는 겁니다. 비용, 윤리, 기존 도구와의 궁합이 갈립니다.

성능과 확장성 좋은 엔터프라이즈급이 필요하면 GitLab을 봐야 합니다.
Jira 생태계 내에서 코드 자산을 관리하려면 Bitbucket이 후보가 됩니다.
AI 학습이 싫고, 윤리 기준이 중요하다면 Codeberg가 맞습니다. (형식은 SaaS, 철학은 Self-Hosted)

“서버를 운영할 수 있다”라면: Self-Hosted 대안들

서버를 직접 운영할 수 있다면, 말 그대로 성을 쌓을 수 있습니다. 이때 선택지는 Gitea, Forgejo, 그리고 GitLab Self-Hosted로 좁혀집니다. 중요한 건 기능 욕심보다 운영 현실입니다. 가볍게 굴릴 건지, 조직 요구를 다 담을 건지부터 정해야 합니다.

무조건 가볍고 빨라야 한다면 Gitea가 어울립니다.
가볍지만 기업 주도는 싫다면 Forgejo가 대안입니다.
기능이 많고 조직 요구가 크면 GitLab Self도 존재합니다.

대안은 많지만, 모든 팀에 정답이 하나로 떨어지진 않습니다. 그래서 “우리 팀이 진짜로 아픈 지점”과 연결해 생각하는 것이 빠릅니다. 본격적으로 하나씩 주요 대안들을 살펴 보겠습니다.

GitLab: 올인원 DevOps가 필요한 팀의 현실적인 대안

GitHub의 대안을 찾다 보면, 결국 “우리가 어디까지 한 제품에 맡길 것인가”라는 질문으로 돌아옵니다. 코드 저장소만 있으면 되는 팀도 있지만, 어떤 팀은 배포와 보안까지 한 흐름으로 묶어야 일이 굴러갑니다. 그럴 때 GitLab은 “여러 도구를 이어 붙이는 방식” 대신 처음부터 통합을 전제로 설계된 선택지입니다. 쉽게 말해, 개발에 필요한 부품을 따로 사서 조립하는 게 아니라 처음부터 한 세트로 들어 있는 공구함에 가깝습니다.

언제 GitLab을 보면 좋을까?

GitLab은 코드 호스팅부터 CI/CD, 보안, 릴리즈까지를 한 제품 안에서 끝내고 싶은 팀에 맞습니다. “저장소는 A, 빌드는 B, 배포는 C”처럼 나눠 쓰지 않고, 한 화면과 한 규칙으로 관리하려는 쪽에 가깝습니다. 특히 팀이 커질수록 “누가, 언제, 무엇을 배포했는지”를 한 흐름으로 남기는 게 중요해지는데, GitLab은 그 요구에 정면으로 대응합니다.

GitLab의 매력

GitLab의 매력은 “툴을 붙여서 조립”하는 방식이 아니라는 점입니다. 여러 제품을 연동하면, 연결 지점마다 설정이 늘고 책임도 흩어집니다. 반면 GitLab은 처음부터 하나의 파이프라인으로 이어지는 경험을 줍니다. 쉽게 말해, 여기저기 전선을 꽂아 만든 시스템이 아니라, 처음부터 배선이 정리된 분전반에 가깝습니다.

또 하나는 자체 호스팅(self-managed) 옵션입니다. 회사 입장에서는 데이터가 어디에 있고, 누가 접근할 수 있는지가 민감한 문제일 때가 많습니다. GitLab은 “우리 서버 안에 두고, 우리 규칙으로 통제한다”는 선택지를 제공합니다. 즉, 편의성만이 아니라 데이터/접근 통제를 우선하는 조직에 현실적인 카드가 됩니다.

선택 전에 알아야 할 것

다만 올인원은 장점만큼 부담도 큽니다. 한 제품 안에 기능이 많은 만큼, “학습해야 할 면적이 넓다”는 뜻이기도 합니다. 실제로 막히는 지점은 기능 자체보다 설정/운영 난이도, 권한 설계, 그리고 러너(Runner) 운영 같은 운영 영역에서 자주 나옵니다. 쉽게 말해, 버튼 몇 개 눌러 끝나는 도구가 아니라, 팀의 일을 담을 그릇을 먼저 설계해야 합니다.

그래서 소규모 팀이나 취미 프로젝트, 단순 협업이라면 올인원이 오히려 과투자일 수 있습니다. 당장 필요한 건 “가벼운 저장소와 이슈 관리” 정도인데, 큰 체계를 들여오면 유지 비용이 생깁니다. 또, GitHub처럼 “일단 만들어서 시작”하기는 어렵다고 느낄 수 있습니다. GitLab은 팀이 어느 정도 규모가 있고, 일하는 방식이 정리돼 있을수록 효과가 커집니다. 반대로 말하면, 팀의 성숙도가 낮은 상태에서 도입하면 “좋은 도구인데 왜 일이 더 어려워졌지?”가 될 수 있습니다.

이런 팀에 추천해봅니다

컴플라이언스/보안 요구가 있고, CI/CD까지 한 번에 통합 관리하고 싶은 팀이라면 GitLab이 잘 맞습니다. 특히 “감사 대응”처럼 기록과 통제가 업무의 일부인 조직이라면, 도구를 쪼개 쓰는 것 자체가 리스크가 됩니다. 이럴 때는 기능이 많은 게 부담이 아니라, 일을 지키는 장치가 됩니다.

또, 툴 체인이 흩어져서 관리 비용이 커진 팀에 추천합니다. 지금이 “젠가”처럼 하나 빠지면 전체가 흔들리는 상태라면, 문제는 도구의 성능이 아니라 연결 구조입니다. GitLab은 그 연결을 줄이고, 흐름을 단순하게 만드는 쪽에 가깝습니다. 반대로 비용을 줄이는 게 최우선이면 bitbucket, 윤리와 원칙이 중요하면 codeberg가 더 맞을 수도 있습니다.

Bitbucket: “Jira가 왕”인 조직을 위한 저장소

Jira를 중심으로 일이 굴러가는 조직이라면, 대안이 아니라 정합성을 따져볼 수 있습니다. GitHub가 아무리 좋더라도, 업무가 흐르는 길과 코드 흐르는 길이 어긋나면 매일 삐걱거릴 겁니다. Bitbucket은 코드 저장소 자체의 화려함보다 업무 관리(Jira)와의 결속으로 힘을 내는 선택지입니다. 쉽게 말해, 개발 도구를 하나 더 늘리는 게 아니라 이미 있는 업무 흐름에 코드를 붙이는 방식입니다.

언제Bitbucket을 보면 좋을까?

Bitbucket은 “코드 저장소”라기보다, Jira가 표준인 팀에서 업무 티켓과 코드를 한 덩어리로 맞춰주는 도구에 가깝습니다. 코드가 어디에 있는지보다 “이 일이 지금 어디까지 왔는지”가 먼저 보이게 만듭니다. 그래서 개발자만 편한 도구가 아니라 협업 전체가 덜 흔들리는 쪽으로 기울어집니다.

Bitbucket의 매력

핵심은 Jira 이슈 ↔ 브랜치/커밋/PR 연결이 자연스럽게 스며든다는 점입니다. “이 브랜치는 어떤 이슈를 위한 건가요?” 같은 질문이 줄어듭니다. 티켓을 열면 관련 코드 변화가 따라오고 코드를 보면 연결된 업무 맥락이 같이 보입니다. 일이 “코드 밖”에서 따로 관리되지 않게 됩니다.

이 연결이 특히 빛나는 순간은 코드 리뷰입니다. bitbucket을 쓰면 “코드 리뷰”가 “업무 티켓의 일부”로 흘러가게 만들기 쉽습니다. 리뷰가 끝났는지 막혔는지, 다음 액션이 뭔지가 티켓 흐름에서 같이 움직입니다. 리뷰가 개발자들만의 채팅방에 갇히지 않을 공산이 있죠.

선택 전에 알아야 할 것

반대로, Atlassian 생태계에 이미 깊이 들어가 있지 않다면 매력은 빠르게 반감됩니다. Jira가 약하거나, 팀이 티켓 중심으로 일하지 않는다면, 굳이 Bitbucket을 선택할 이유가 줄어듭니다. 이 경우엔 GitHub 대안으로서의 장점이 “Jira 연결”만큼 선명하지 않을 수 있습니다.

또 여기도 문제는 결국 락인(lock-in)입니다. 결국 또 다른 락인이 될 수 있으니, 먼저 “Jira가 이미 표준인가?”를 자문해야 합니다. Jira가 조직의 언어라면 이겨볼만 하죠. 하지만 Jira가 아직 논쟁 중인 도구라면, 저장소 선택이 조직을 한쪽으로 고정할 수도 있습니다. 결국 의존성은 도구가 아니라, 우리가 만드는 구조에서 생깁니다.

이런 팀에 추천해봅니다

이미 Jira로 스프린트/이슈/리포팅이 굴러가고 있다면, Bitbucket은 선택이 단순해집니다. 특히 개발-비개발 협업이 Jira 중심인 조직일수록 효과가 큽니다. 기획, QA, 운영이 “티켓”으로 대화하는데, 개발만 GitHub에서 따로 놀면 연결 비용이 커집니다. 이럴 때 Bitbucket은 “툴 추가”가 아니라 “흐름 정리”로 작동합니다.

Codeberg: 오픈소스를 찾는 사람을 위한 답안지

GitHub에는 기능도 많고, 사람이 모여 있고, 웬만한 워크플로는 다 돌아갑니다. 다만 시장을 지배하는 프로덕트는, 그 의존성만으로도 새로운 문제를 만들기 쉽습니다. 느린 속도나 비용 청구 같은 표면 이슈를 넘어, 결국 MS라는 기업이 주도하는 플랫폼에 생태계가 종속된다는 감각이 남습니다. 그래서 기업 기반 플랫폼의 대안을 찾는다면, Codeberg가 꽤 괜찮은 선택지로 올라옵니다.

언제 Codeberg를 보면 좋을까?

Codeberg는 상업 SaaS의 성장 논리보다, 오픈소스 친화적 운영 원칙을 우선하는 곳입니다. 쉽게 말해 플랫폼이 돈을 더 벌기 위해 내 프로젝트를 흔들 가능성을 낮추려는 방향에 가깝습니다. GitHub처럼 거대한 기능 경쟁을 하기보다, 오픈소스 커뮤니티가 불편하지 않게 지키려는 기준이 먼저 보입니다. 대안을 찾는 이유가 윤리나 운영 철학이라면, 출발점부터 결이 맞습니다.

Codeberg의 매력

Codeberg의 매력은 심리적인 안정감에서 시작합니다. “내 프로젝트가 플랫폼의 수익모델 실험대가 되지 않길 원한다”는 사람에게, 이건 생각보다 큰 장점입니다. 특히 AI 학습이나 데이터 활용 같은 이슈에 민감한 팀이라면, 일단 올려두고 나중에 걱정하는 흐름을 줄일 수 있습니다. 같은 SaaS라도 운영 원칙이 주는 신뢰는 체감이 큽니다.

또 하나는 커뮤니티 신호입니다. 공개 프로젝트를 두기 좋은 공간으로 인식되기 쉬운 편입니다. 즉 “여긴 오픈소스 하려는 사람이 모이는 곳”이라는 분위기가 먼저 깔립니다. 프로젝트 소개를 할 때도, 플랫폼 선택 자체가 메시지가 되곤 합니다. GitHub에서의 ‘노출’과는 다른 종류의 신호입니다.

선택 전에 알아야 할 것

다만 GitHub처럼 거대한 생태계를 그대로 기대하면 실망할 수 있습니다. 앱 마켓, 각종 연동, 채용 노출 같은 플랫폼 효과는 GitHub가 압도적입니다. Codeberg는 그 게임을 같은 방식으로 하려는 곳이 아닙니다. 그래서 “GitHub랑 똑같은데 더 싸고 더 윤리적”을 기대하면 어긋납니다.

도입 전에는 팀이 원하는 기능을 먼저 정의해야 합니다. 예를 들어 SSO, 세밀한 엔터프라이즈 정책, 특정 CI 통합 같은 요구가 있는지 확인해야 합니다. 쉽게 말해 “우리가 정말 필요한 건 저장소인가, 아니면 조직 운영 도구까지 포함한 세트인가”를 구분하는 일입니다. 이 정리가 없으면, 대안을 찾다가 다시 GitHub나 GitLab로 돌아가게 됩니다.

이런 팀/개인에 추천해봅니다

Codeberg는 오픈소스 프로젝트 운영자에게 특히 잘 맞습니다. 또한 데이터/플랫폼 주권을 중요하게 보는 개인이나 단체라면, 선택의 이유가 분명해집니다. 다른 옵션과 비교할 때도 Codeberg는 “가치 기준”으로 고르는 카드에 가깝습니다. 결국 의존성은 도구가 아니라, 우리가 만드는 구조에서 생깁니다. 그러니 떠날지 말지보다 왜 옮기는지부터 선명하면 됩니다.

Gitea vs Forgejo: 직접 가볍게 호스팅하겠다

GitHub처럼 PR, 이슈, 위키를 기본으로 갖춘 가벼운 자체 호스팅 Git 서버를 찾는다면, 보통 후보는 gitea와 forgejo로 모입니다. GitHub 대안이라고 부르지만, 결은 조금 다릅니다. 이쪽은 새 서비스로 갈아타기가 아니라 ‘내가 직접 호스팅해서 운영하기’에 가깝습니다. 쉽게 말해, 남의 아파트로 이사 가는 게 아니라 내 땅에 집을 짓는 선택입니다.

언제 Gitea/Forgejo를 보면 좋을까?

Gitea와 Forgejo는 GitHub에서 익숙한 협업 기능을 작게 담아둔 도구입니다. PR(코드 리뷰 요청), 이슈(할 일/버그 관리), 위키(문서)를 한곳에서 굴릴 수 있습니다. 대신 모든 걸 대신해주는 SaaS가 아니라 내 서버에 설치해 쓰는 방식입니다. 그래서 속도, 접근 정책, 데이터 보관을 내가 정할 수 있습니다.

두 가지 대안의 매력

이 선택은 기능 욕심보다 운영 철학에서 시작하는 경우가 많습니다. 예를 들어 내부망/폐쇄망이라 외부 SaaS를 못 쓰거나, 비용을 매달 예측 가능하게 통제하고 싶을 수 있습니다. 또는 “이 저장소는 5년 뒤에도 여기 있어야 한다”처럼 장기 보존이 목표일 수도 있고요. 한마디로, Git 저장소를 외부 서비스가 아니라 내 인프라의 한 조각으로 두고 싶을 때입니다.

Gitea vs Forgejo

차이는 뭘까요? Gitea는 기업 중심이고, Forgejo는 이러한 기업 중심 운영에 반발해 나온 프로젝트라는 점입니다.

그래서 Gitea는 보통 “가볍고 설치가 쉽다”는 기대치로 많이 선택됩니다. 복잡한 체계보다, 필요한 기능을 빠르게 갖추고 바로 쓰고 싶은 팀에 잘 맞습니다. 특히 소규모 팀이나 사내 프로젝트에서 “딱 필요한 만큼”으로 시작하기 좋습니다. 쉽게 말해, 거대한 플랫폼을 들이기 전에 작은 사내 GitHub를 먼저 만들어보는 느낌입니다.

당연하게도 Forgejo도 같은 계열이라 사용 경험은 크게 낯설지 않습니다. 다만 매력 포인트는 성능 스펙보다 프로젝트 운영의 독립성/거버넌스에 있습니다. 즉 “이 도구의 미래 방향을 누가 결정하나?”를 중요하게 보는 사람에게 더 끌립니다. 같은 ‘자체 호스팅’이라도, 결국 장기 운영에서는 기능보다 의사결정 구조가 더 큰 변수가 됩니다.

두 도구를 고를 때는, 화면 캡처 비교보다 먼저 현실 질문을 던져야 합니다. 서버를 세우는 순간, 개발 도구가 아니라 운영 업무가 함께 따라오기 때문입니다. 작고 가벼운 도구임에도 self-hosted 임에는 분명하니, 아직 이른 신호일 수 있다는 겁니다.

그래서 지금 나한테 필요한 대안은 뭘까?

비교적 강점이 분명합니다. 정리하면 이렇습니다.

마치며

GitHub는 여전히 천국에 가깝습니다. 협업 상대가 모여 있고, 내 커리어에 끼칠 영향도 무시하기 어렵죠. 다만 한 곳에 오래 머무를수록 생활 방식은 굳어집니다. 워크플로, 자동화, 앱 연동이 쌓일록 떠나기가 무서워지고요. 그래서 대안 탐색은 더 좋은 천국 찾기가 아니라 내 조건에 맞는 거처 고르기에 가깝습니다.

첫 단계는 감정이 아니라 구조를 보는 것입니다. 우리 팀이 GitHub에 “묶인 지점”을 한 장으로 정리해 보세요. 아래 네 가지만 이해해도 종속성이 분명해질 겁니다.

Actions: 배포·테스트가 어디까지 자동화돼 있나
Issues/Projects: 업무 흐름이 얼마나 붙어 있나
권한/조직: 팀·외부 협력 권한이 어떻게 설계돼 있나
앱 연동: Slack, CI, 보안 도구가 무엇에 기대나

한편 목표는 처음부터 “완전 이주”로 잡지 않아도 됩니다. 대부분은 떠나기 전에 “보험”부터 드는 게 더 안전합니다. 예를 들면 미러(동기화)나 백업처럼, 최악의 상황에서도 코드를 잃지 않는 장치를 먼저 두는 겁니다. 또는 세컨드 포지처럼, 보조 거처를 만들어 두는 방식도 좋습니다.

이제 그 다음이 진짜 비교입니다. 조건이 정리됐다면 후보를 넓게 늘리지 말고, 한 곳만 골라 2주 파일럿을 해보세요. GitLab, Bitbucket, Codeberg, Gitea, Forgejo 중에서요. 이때는 “가장 쉬운 저장소”가 아니라, 가장 어려운 저장소 1개로 테스트해야 합니다. 그 저장소가 넘어가면, 나머지는 대체로 따라옵니다.

결국 낙원은 플랫폼에서 나오지 않습니다. 운영 원칙과 그 원칙을 지키는 리스크 관리에서 나옵니다. 어떤 도구를 고르든 의존성은 생기니 문제는 “의존성을 만들지 말자”가 아닙니다. “무심코 의존성을 키우지 말자”가 핵심입니다.