사내 GitLab 도입·운영

소스가 개인 PC 와 공유 폴더에 흩어져 있어 과제가 끝나면 어디에 무엇이 있는지 찾기 어려웠습니다. 사내망에 GitLab 커뮤니티 판을 직접 올리고, 코드와 문서를 한곳으로 모으는 것부터 시작했습니다.

쓰는 사람이 없으면 저장소만 생기고 끝나므로 교육을 함께 열었습니다. 버전관리 개념부터 계정·저장소 생성, 커밋과 브랜치 운용까지 사내 실무교육 과정을 만들어 진행했고, 가입 신청과 승인은 제가 받습니다.

그룹은 과제 단위로 두고 이름을 연도·발주처·과제명 순으로 짓는 규칙을 정했습니다. 회사 자체 자산은 별도 그룹에 모아, 저장소 이름만 보고도 어느 과제의 무엇인지 알 수 있게 했습니다.

변경은 브랜치에서 병합 요청으로 올리고 설명은 요청일과 핵심 내용만 적는 규약을 두었습니다. 태그를 밀면 빌드가 도는 파이프라인과 배포본을 올려 두는 패키지 저장소를 붙여, 사내 도구의 자동 업데이트가 여기서 배포본을 받아 가도록 했습니다.

협력사 개발자에게는 과제 그룹 단위로 권한을 주고, 접근 토큰은 자격 증명 관리자에만 두게 했습니다. 끝난 과제의 저장소는 이력을 묶음 파일로 뽑아 저장 장치에 보관하는 절차로 이어집니다.

교육 주제는 사내 실무교육과 스터디 수요조사에서 'Git & GitLab' 이 확정 교육으로 정해지면서 열렸습니다. 과정 구성안은 프로젝트와 버전관리 개념에서 시작해 GitLab 기초(계정·저장소 생성, 복제, 커밋·풀·푸시), 프로젝트 관리 1(README, 브랜치, 병합, 태그, 릴리스), 프로젝트 관리 2(이슈, 마일스톤, 코드 리뷰, 병합 요청, CI/CD 개념, 문서화)로 이어지는 네 단계였습니다. 교육 여섯 달 뒤인 2023년 2월에는 가입 신청부터 첫 병합 요청까지 혼자 따라 할 수 있는 이용 안내서를 따로 만들었습니다.

안내서와 규약에는 정한 이유를 함께 적었습니다. 프로젝트는 개인 소속(개인 소스)과 그룹 소속(사업·사내 프로젝트 단위)으로 나누고, 공개 범위는 생성자와 초대자만 보는 단계, 회사 소속 계정이 보는 단계, 외부 계정까지 보는 단계로 설명했습니다. 첫 커밋에는 저장소 목적과 동작 플랫폼, 외부 종속성, 개발·디버그 환경 구성 절차를 담은 README 와, 저장소에 올리지 않을 파일(빌드·테스트 캐시, 보안 토큰과 로그인 계정 정보, 구성 절차로 되살릴 수 있는 가상 환경)을 적은 .gitignore 를 반드시 넣게 했습니다.

브랜치 전략은 main 과 최소한의 개발 브랜치를 두고 병합 뒤 지우는 GitHub Flow 와, 역할별로 브랜치 여러 개를 두는 Git Flow 를 견주어 정했습니다. 제품 저장소는 main 과 개발 브랜치를 두고 개발 브랜치를 병합한 뒤 버전 태그를 붙여 배포 버전을 보관합니다. 병합 요청 양식은 제목과 설명, 담당자와 검토자, 마일스톤, 라벨, 병합 뒤 소스 브랜치 삭제와 커밋 합치기 옵션으로 정했고, 요청을 올리면 알림, 리뷰, 추가 커밋, 최종 병합 순서로 오가게 했습니다.

병합 전 절차도 정했습니다. 병합은 병합 요청으로만 하고, 요청을 올리기 전에 소스 브랜치에 대상 브랜치를 먼저 합쳐 충돌을 해소한 뒤 테스트를 통과시킵니다. 오래 방치된 브랜치는 이미 반영되었거나 더 나은 형태로 대체된 변경만 들고 있을 수 있어, 병합하면 오히려 되돌림이 되므로 실제로 더해지는 변경을 확인하고 없으면 브랜치만 지웁니다. 이미 병합된 요청의 설명도 코드와 커밋은 두고 문구만 규약의 섹션 순서에 맞게 고쳐 이력을 일관되게 만들었습니다.

종료 과제 보관에는 검증 단계를 두었습니다. 묶음 파일을 만든 뒤 검증을 통과해야만 저장소 이력을 지우고, 압축본은 전체 항목 무결성 시험과 파일 수 일치를 확인합니다. 정본 저장 장치와 클라우드 미러 두 곳에 복사한 뒤 원본과 두 사본의 해시가 모두 같을 때만 사용자 확인을 거쳐 원본을 지웁니다.

화면

더미 데이터로 채운 그림입니다. 실제 화면과 배치·문구가 다를 수 있습니다.

구조와 흐름