해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 30 - How GitHub delivers GitHub using GitHub
1. GitHub 개발 철학과 GitHub CodeSpace
깃허브의 핵심 마스터플랜은 '행복한 개발자를 만드는 것'이다.
개발자가 행복해야 진정한 생산성이 발휘된다는 철학에 기반하여 '개발자 경험 (DevEx, Developer Experience)' 을 최우선으로 둔다.
해당 철학의 핵심 증거는 "Day Zero 배포" 문화이다. 깃허브의 모든 엔지니어는 입사 첫날인 Day 0에 프로덕션 환경에 실제 코드를 Push하고 배포한다.
해당 방식이 가능한 이유는 전통적인 로컬 개발 환경을 사용하지 않기 때문이다.
-
과거 로컬 환경의 문제점
-
github/github의 거대한 모놀리스 코드베이스는 로컬 머신에 Clone하는데만 45분이 소요되는 상황
-
로컬 머신의 자원 한계로 인해 대규모 테스트 실행 시 시스템이 다운되는 문제 발생
-
노트북 도난이나 분실 시 소스 코드가 유출될 수 있는 심각한 보안 위협 존재
-
개발 환경 구성을 위한 업데이트, 의존성 설치 등으로 인하여 실제 코딩 시작까지 불필요한 시간이 소요됨.
-
-
깃허브의 해결책: 깃허브 코드스페이스 (GiHub CodeSpaces)
-
Github는 클라우드에서 직접 실행되는 '컨테이너화된 보안 개발 환경인 코드스페이스'를 표준으로 사용
-
이를 통하여 환경 준비 시간이 1분 미만으로 단축됨.
-
모든 개발 환경은 리포지토리 내의 devcontainer.json 파일을 통해 정의되고 관리됨.
-
프리빌드(Pre-build) : 코드와 의존성이 많은 환경을 미리 빌드하여 코드스페이스 실행 속도를 더욱 가속화
-
컴퓨팅 사양 : 개발에 필요한 CPU, 메모리 자원을 명시
-
포트 포워딩 : 웹 개발에 필요한 80번 포트 등 필요한 포트를 자동으로 설정
-
VS Code 확장 기능 : 루비 (Ruby), 린터 (Linter), 테스트 도구 등 개발에 필요한 모든 확장 기능을 사전에 정의하여, 개발자가 개별적으로 설치할 필요 없이 환경 구성 시 자동으로 설치
-
-
GitHub CodeSpace는 GitHub가 제공하는 클라우드 기반 개발 환경으로 브라우저나 로컬 VS Code를 통해 원격의 VM에 접속하여 코딩할 수 있다.
각 CodeSpace는 Docker 컨테이너에서 실행되며, 모든 팀원이 동일하게 구성된 개발 환경을 사용하게 되어 일관성을 유지할 수 있다.
해당 사진은 GitHub CodeSpace의 아키텍처이다.
1. 오른쪽: Codespace (호스팅 환경)
실제 개발 환경이 실행되는 클라우드 측
-
Azure (Hosting): 개발 환경이 호스팅되는 클라우드 플랫폼 (GitHub는 Microsoft 소유).
-
Virtual Machine (VM): Codespace에 할당된 가상 하드웨어(Linux)
해당 VM은 CPUs와 Disk storage 같은 격리된 리소스를 제공 -
Container (컨테이너): VM 내부에서 실행되는 Docker 개발 환경 (Codespace의 실체)
-
A clone of your repository: 사용자의 GitHub 저장소 소스 코드가 복제
-
Languages: 개발에 필요한 언어 런타임 (Python, Ruby 등) 이 설치
-
Tooling: VS Code 확장 프로그램, 린터(linter), 디버거 등 개발 도구들이 설치
-
2. 왼쪽: Code editor (사용자 접속 방식)
사용자가 원격 Codespace에 접속하는 클라이언트 도구들
-
VS Code Desktop: 사용자의 로컬 PC에 설치된 VS Code 편집기
('Remote - Containers' 확장과 유사하게 원격 Codespace에 연결하여 사용) -
VS Code Browser: 웹 브라우저 (Chrome, Safari 등)에서 바로 VS Code 인터페이스를 열어 Codespace에 접속 방식
-
Command line: GitHub CLI (gh codespace ssh)를 통해 터미널에서 SSH로 원격 Codespace에 직접 접속할 수 있음.
2. 계획부터 실행까지의 통합 Workflow
깃허브는 계획 단계부터 코드 실행까지 모든 개발 라이프사이클을 플랫폼 내에서 통합하여 컨텍스트 스위칭(Context Switching) 비용을 최소화한다.
-
계획: 깃허브 프로젝트 (GitHub Projects)
-
모든 작업은 '깃허브 프로젝트' 보드를 통해 시각적으로 관리됨.
-
작업은 Initiatives(이니셔티브, 분기/반기) → Epics(에픽, 3-6주) → Batches(배치, 수일-3주) → Tasks(태스크, 수시간-1일)의 위계질서를 가짐.
-
프로젝트 보드의 모든 작업 항목은 깃허브 이슈(GitHub Issues)와 직접 연결되어, 계획부터 코드 변경, 배포까지 강력한 추적 가능성(traceability)을 보장한다.
-
-
실행: E2E(End-to-End) 워크플로우 April Edwards가 시연한 실제 워크플로우
-
작업 선택: 'GitHub Project' 보드에서 CI/CD 지연 연구 태스크를 선택하고 자신에게 할당
-
브랜치 생성: 이슈 페이지 내에서 "브랜치 생성" 버튼을 클릭
-
코드스페이스 실행: 생성된 브랜치를 기반으로 "코드스페이스에서 열기"를 클릭
-
AI 기반 코딩: 코드스페이스 (VS Code 환경) 내에서 깃허브 코파일럿 챗 (Copilot Chat)을 열어, "이 테라폼 코드를 더 간단하게 만들어줘" 와 같이 자연어로 코드 수정을 요청하고 즉시 적용
-
풀 리퀘스트(PR) 생성: 코드 변경 후 PR을 생성할 때, 코파일럿을 사용해 변경 사항에 대한 상세한 Summary을 자동으로 생성 ("PR의 절반은 설명이 부실하다"는 고질적인 문제를 해결)
-
3. GitHub Actions
PR이 생성되는 순간, 깃허브의 핵심 자동화 엔진인 깃허브 액션 (GitHub Actions)이 즉시 동작한다.
GitHub Actions는 단순한 CI/CD를 넘어, 코드의 품질과 보안을 강제하는 '자동화된 게이트키퍼(Gatekeeper)' 역할을 수행한다.
-
모든 자동화 워크플로우는 리포지토리 내 .github/workflows 폴더 안의 YAML 파일에 정의된다.
-
April이 시연한 PR에서 실행된 워크플로우 예시는 다음과 같다.
-
terraform-check.yml: Terraform 코드의 유효성을 검사하고 린터 (Linter)를 실행하여 코드 스타일 표준을 강제한다.
-
docker-build-push.yml: 변경 사항을 기반으로 Docker 이미지를 빌드하며, 이 과정에서 이미지 내 보안 취약점을 스캔한다.
-
codeql-workflow.yml: 코드큐엘(CodeQL)을 실행하여 코드 자체의 잠재적 보안 결함을 분석한다.
-
-
깃허브의 핵심 배포 정책은 "모든 검사가 초록불(All Green)이어야만 머지(Merge)가 가능하다"는 것이다. 단 하나의 테스트나 검사가 실패하더라도 PR은 즉시 차단되어 프로덕션 환경을 보호한다.
4. 개발 워크플로우에 내장된 보안 (GHAS)
깃허브 어드밴스드 시큐리티 (GHAS, GitHub Advanced Security)를 통해 개발 속도를 저해하지 않으면서 강력한 보안을 워크플로우 전반에 내장시킨다.
-
시크릿 스캐닝 (Secret Scanning):
-
개발자가 실수로 코드에 구글 API 키나 비밀번호 같은 Secret을 하드코딩하고 커밋하는 순간, 깃허브가 이를 즉시 탐지
-
탐지된 키는 즉시 무효화되도록 관련 서비스 제공자에게 통보되고, 개발자에게는 키를 교체하고 깃허브 시크릿 기능을 사용하도록 경고
-
-
디펜다봇 (Dependabot):
-
코드베이스가 의존하는 오픈소스 라이브러리 (Dependencies)의 보안 취약점을 지속적으로 스캔
-
단순히 경고만 보내는 것이 아니라, 발견된 취약점을 해결하는 PR을 자동으로 생성한다.
(개발자는 이 PR을 검토하고 Merge하기만 하면 됨)
-
-
코드 스캐닝 (CodeQL):
-
'코드를 데이터로(Code as Data)' 분석하는 정적 분석 엔진
-
SQL 인젝션, 크로스 사이트 스크립팅 (XSS), 로직 오류 등 컴파일 단계에서 잡기 어려운 복잡한 보안 결함을 개발자가 코드를 작성하는 단계에서 탐지하고 수정 방안을 제시
-
5. 피드백 루프와 Single Pane of Glass
깃허브의 데브옵스 라이프사이클은 배포로 끝나지 않고, 피드백 루프로 이어진다.
-
리포지토리의 '인사이트(Insights)' 탭은 커밋 빈도, 상위 기여자, 트래픽 통계, 의존성 그래프 등 프로젝트 활동에 대한 모든 데이터를 시각화하여 제공
-
해당 Insights 데이터는 다시 '깃허브 프로젝트' 보드로 피드백되어, 다음 스프린트나 이니셔티브를 계획하는 객관적인 근거 자료로 활용됨.
결론적으로 깃허브는
[계획(Projects) → 개발(Codespaces/Copilot) → 검증/배포(Actions) → 보안(GHAS) → 모니터링/피드백(Insights)]
에 이르는 개발의 모든 과정을 개발자가 다른 도구로 이동할 필요 없이 '단일 창 (Single Pane of Glass)'에서 완결할 수 있는 통합 플랫폼이다.
