자체 호스팅형 Git 저장소 소프트웨어인 Gitea가 새 버전을 내놓으면서 눈에 띄는 변화를 함께 알렸다. 이번 릴리스는 그동안 붙어 있던 '1.' 접두사를 버리고 1.28.0이 아니라 28.0.0으로 표기된다. 겉으로는 사소해 보이는 이 변경은 사용자가 버전 정책을 어떻게 읽어야 하는지에 영향을 준다.
버전 표기 방식의 변화
기존 Gitea는 오랫동안 1.x.y 형식을 유지해 왔다. 앞자리가 계속 1에 고정돼 있다 보니, 메이저 자리가 제 역할을 하지 못하고 실질적인 세대 구분은 두 번째 숫자가 담당하는 구조였다. 이번에 접두사를 떼어내면서 그 두 번째 숫자가 그대로 앞으로 올라와 28이 됐다. 즉 번호 자체가 크게 뛴 것이 아니라, 표기 규칙을 정리해 실제 릴리스 흐름과 숫자를 일치시킨 셈이다.
실무자 입장에서 이 변화는 자동화 스크립트나 배포 파이프라인에서 버전 문자열을 파싱하는 부분을 점검해야 한다는 신호다. '1.28.0'과 같은 패턴을 정규식으로 걸러내거나 특정 자리를 기준으로 비교하던 로직이 있다면, 새 표기에서 오작동할 수 있다. 컨테이너 태그, 패키지 저장소, 업그레이드 조건문 등을 함께 확인해두는 편이 안전하다.
관리·보안 기능의 보강
원문이 꼽은 주요 항목은 감사 로그(audit logging), 봇 계정(bot accounts), HTTPS 배포 토큰(HTTPS deploy tokens), 그리고 관리자를 위한 사용자 가장(user impersonation) 기능이다. 세부 사양이 자세히 공개된 것은 아니지만, 네 가지가 공통적으로 향하는 방향은 분명하다. 여러 사람과 자동화 도구가 함께 쓰는 저장소 환경에서 '누가 무엇을 했는가'를 추적하고 통제하는 능력을 강화하는 쪽이다.
감사 로그는 조직 단위로 Gitea를 운영할 때 특히 의미가 크다. 저장소 설정 변경, 권한 부여, 계정 관리 같은 행위를 시간 순으로 남길 수 있다면, 보안 사고가 발생했을 때 원인을 되짚거나 내부 감사·컴플라이언스 요구에 대응하기가 한결 수월해진다. 그동안 자체 호스팅 Git 도구를 도입하려던 조직이 상용 서비스 대신 Gitea를 택하기 어려웠던 이유 중 하나가 이런 추적 기능의 부재였던 만큼, 방향성 자체는 반길 만하다.
봇 계정과 HTTPS 배포 토큰은 CI/CD 및 자동화와 맞닿아 있다. 사람이 쓰는 개인 계정을 자동화에 그대로 물려 쓰면 권한 범위가 지나치게 넓어지고 책임 소재도 흐려진다. 자동화 전용 계정과 토큰을 분리하면 최소 권한 원칙을 적용하기 쉽고, 사고 시 해당 자격 증명만 회수하면 되므로 운영 부담이 줄어든다. 배포 토큰을 HTTPS로 다룰 수 있다는 점은 SSH 키 배포가 번거로운 환경에서 실용적인 선택지가 된다.
관리자용 사용자 가장 기능은 지원과 디버깅 현장에서 유용하다. 특정 사용자에게만 나타나는 권한 문제나 화면 오류를 재현할 때, 관리자가 해당 사용자 시점으로 시스템을 살펴볼 수 있으면 원인 파악이 빨라진다. 다만 이 기능은 남용되면 그 자체가 심각한 보안 위험이 되므로, 앞서 언급한 감사 로그와 반드시 함께 운영해 누가 언제 누구를 가장했는지가 기록으로 남도록 설정하는 것이 바람직하다.
도입 전 확인할 점
주의할 대목은 이번 공지가 전하는 정보 자체가 하이라이트 수준에 머물러 있다는 것이다. 각 기능의 설정 방법, 세부 제약, 기존 데이터와의 호환성, 그리고 메이저 표기 전환에 따른 잠재적 파괴적 변경(breaking change) 여부는 별도의 공식 릴리스 노트와 문서로 확인해야 한다. 운영 중인 인스턴스라면 곧바로 올리기보다 별도 환경에서 백업 후 업그레이드를 검증하고, 파이프라인의 버전 처리 로직과 자동화 계정 구성을 함께 손보는 순서가 안전하다. Gitea는 오픈소스로 공개돼 있어 실제 동작과 세부 구현은 코드와 문서에서 직접 대조할 수 있다.