70. 형상 관리 저장소 (Git) 및 지속적 통합(CI) 환경 감리

⚠️ 이 문서는 소프트웨어 개발 프로젝트에서 수십 명의 개발자가 작성한 소스 코드가 어떻게 저장되고 합쳐지는지(형상 관리), 그리고 합쳐진 코드가 버그 없이 제대로 빌드되는지(지속적 통합)를 통제하는 '개발 파이프라인의 안전성'을 평가하는 감리 지침을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: "소스 코드 파일 관리를 개발자들끼리 USB나 카카오톡으로 주고받고 있지 않은가?"를 점검하여, 단 하나의 진실의 원천(Single Source of Truth)인 중앙 저장소(Git)가 제대로 구축되고 룰에 맞게 통제되고 있는지 확인한다.
  2. 가치: 개발자가 퇴사해도 과거의 모든 소스 코드 변경 이력(History)이 영구히 보존되며, 두 명의 개발자가 같은 파일을 수정했을 때 덮어쓰기로 코드가 날아가는 대형 사고(Merge Conflict 패닉)를 미연에 방지한다.
  3. 기술 체계: 감리인은 형상 관리 브랜치 전략(Git Flow 등)의 존재 여부와, 코드가 합쳐질 때마다 젠킨스(Jenkins) 같은 로봇이 자동으로 테스트를 수행하는 CI(Continuous Integration) 환경이 제대로 구축되었는지 중점 점검한다.

Ⅰ. 형상 관리(SCM)의 기본 원칙 점검

코드는 회사의 핵심 자산이다. 누가, 언제, 왜 바꿨는지 기록되어야 한다.

  1. 중앙 저장소 구축 및 권한 통제:
    • 개발자의 로컬 PC에만 소스 코드가 있고 중앙 저장소(GitLab, Bitbucket 등)에 매일 푸시(Push)되지 않으면 최악의 보안/관리 리스크다.
    • 감리 포인트: 모든 소스 코드가 형상 관리 도구에 등록되어 있는지, 그리고 하청 업체 직원이 퇴사할 때 소스 코드 접근 권한(Repository Access)이 즉시 회수되는지 점검한다.
  2. 커밋(Commit) 메시지와 이력 관리:
    • 수정함, 진짜 최종, 1111 같은 무의미한 커밋 메시지는 감리 지적 대상이다.
    • 감리 포인트: 코드 수정 시 [JIRA-123] 결제 오류 버그 수정처럼 요구사항 추적 매트릭스(RTM)의 이슈 번호와 정확히 매핑되는 의미 있는 메시지를 강제하는 정책이 있는지 확인한다.
  3. 베이스라인(Baseline) 관리:
    • 통합 테스트가 끝난 시점, 고객 인수 테스트(UAT)가 끝난 시점 등 중요한 마일스톤마다 코드의 스냅샷을 찍어 "이 시점의 코드는 완벽하다"라고 태그(Tag)를 붙여 얼려두는(Freeze) 베이스라인 설정이 제대로 되고 있는지 점검한다.

📢 섹션 요약 비유: 도서관의 백과사전을 여러 명이 동시에 수정할 때, 각자 자기 집에 책을 들고 가 마음대로 고쳐오는 것(형상 관리 부재)을 막고, 반드시 중앙 열람실(Git)에서만 고치게 하되, "내가 몇 페이지 어느 줄을 왜 고쳤다(커밋 메시지)"라고 방명록에 남기게 하는 철저한 도서 관리 시스템 점검입니다.

Ⅱ. 브랜치(Branch) 전략 및 병합(Merge) 통제

코드가 합쳐질 때는 반드시 엄격한 문지기가 있어야 한다.

  1. 표준 브랜치 전략의 존재:
    • master(운영), develop(개발), feature(기능) 등 브랜치의 용도를 명확히 나눈 전략(예: Git Flow, GitHub Flow)을 문서화하고 팀원들이 이를 준수하고 있는지 검사한다.
    • 감리 포인트: 개발자들이 운영 서버용 코드인 master 브랜치에 직접 코드를 푸시(Direct Push)할 수 있는 권한이 열려있다면 즉각적인 '중결함' 처리 대상이다.
  2. 코드 리뷰(Code Review) 및 승인 절차:
    • feature 브랜치에서 다 짠 코드를 develop에 합칠 때, 개발자 혼자 맘대로 합치는 것은 금지된다.
    • 감리 포인트: 깃허브의 풀 리퀘스트(Pull Request, PR) 기능을 사용하여, 반드시 선임 개발자 1명 이상의 승인(Approve) 도장을 받아야만 코드가 병합(Merge)되도록 시스템적으로 락(Lock)이 걸려있는지 점검한다.

📢 섹션 요약 비유: 공장에서 부품을 각자 깎아오면(feature 브랜치), 조립 라인(main 브랜치)에 그냥 던져 넣고 조립하는 게 아닙니다. 반드시 검수관(동료 개발자)이 부품의 규격을 돋보기로 검사하고(코드 리뷰) 결재 도장을 찍어줘야만 컨베이어 벨트에 부품을 올릴 수 있게(Merge) 막아둔 깐깐한 품질 통제 시스템입니다.

Ⅲ. 지속적 통합 (CI, Continuous Integration) 환경 평가

사람의 눈을 믿지 마라. 로봇의 기계적인 테스트를 거쳐야 한다.

  1. 자동화된 빌드 환경 (Automated Build):
    • 코드가 병합될 때 누군가 수동으로 마우스를 클릭해 컴파일하는 것은 구시대적이다.
    • 감리 포인트: 젠킨스(Jenkins)나 깃허브 액션(GitHub Actions) 같은 CI 봇(Bot)이 설정되어 있어, 코드가 푸시되는 순간 백그라운드에서 자동으로 빌드(Build) 스크립트가 돌아가는지 확인한다.
  2. 자동화 단위 테스트 (Unit Test) 강제:
    • 단순히 코드가 컴파일되는 것(오타 없음)만으로는 부족하다. 비즈니스 로직이 제대로 작동하는지 검증해야 한다.
    • 감리 포인트: CI 파이프라인 중간에 단위 테스트(JUnit 등)가 100% 자동으로 실행되며, 만약 테스트를 하나라도 통과하지 못하면(Fail), 해당 코드의 병합과 배포가 시스템적으로 완전히 중단되게 막혀있는지 감리한다.
  3. 정적 코드 분석 (Static Analysis) 연동:
    • 코드에 하드코딩된 비밀번호가 있거나 SQL 인젝션 취약점이 있는 코드가 올라오면, 소나큐브(SonarQube) 같은 도구가 CI 파이프라인에서 이를 적발하고 퀄리티 게이트(Quality Gate)를 닫아 배포를 차단하는지 점검한다.

📢 섹션 요약 비유: 완성된 부품을 조립 라인에 올릴 때마다, 사람 대신 로봇 팔(CI 서버)이 튀어나와 부품을 사정없이 두드려보고 열을 가해봅니다(자동화 테스트). 만약 조금이라도 금이 가면 사이렌을 울리며 조립 라인을 멈춰버려, 불량품이 고객에게 출고(배포)되는 것을 공장 내부에서 원천 봉쇄하는 무인 품질 검사소입니다.