목차

Code Management

깃허브의 Code Management 기능은 간단하게 새로운 저장소(repository)를 만드는 기능입니다.

Public/Private로 나눌 수 있지만, 깃허브는 오픈소스를 지향하는 플랫폼이기에 Public repository에 더 많은 기능을 지원합니다.

GitHub Actions

깃허브 액션(GitHub action)은 깃허브에서 제공하는 CI/CD 자동화 도구입니다.

코드 커밋, PR, 이슈 생성 등 여러가지 이벤트에 반응하여 자동으로 반복적인 작업(빌드, 테스트, 배포)을 수행할 수 있습니다.

이 그림처럼 빌드와 배포의 작업을 매 push 작업마다 자동으로 실행시킬 수 있게 도와줍니다.

깃허브에서 기본적으로 제공하는 내용 뿐만 아니라 프로젝트마다 커스터마이징하여 사용하는 것도 가능합니다. 깃허브 액션의 워크플로우는 ".github/workflows" 의 디렉토리 안에 YAML 파일의 형식으로 정의됩니다.

이 그림은 워크플로우 커스터마이징의 한 예시입니다. 좋지 않은 PR이 발생할 경우에 처리하는 것에 대해 다루고 있습니다.

이러한 워크플로우 파일에서는 실행할 작업과 조건, 환경 등에 대해서 세밀하게 지정할 수 있습니다.

GitHub Packages

깃허브 패키지(GitHub package)는 깃허브의 패키지 호스팅 서비스로, 소프트웨어 패키지를 호스팅하고 공유하며, 버전을 관리하는데 사용됩니다. 깃허브 생태계 개발자들이 소스코드 뿐만 아니라 패키지를 함께 관리할 수 있도록 도와줍니다.

npm, nuGet, Maven, RubyGems, Docker 등 여러가지 패키지 관리 시스템과 통합됩니다.

가장 먼저 패키지를 호스팅할 원격 저장소를 설정해야 하고, 해당 패키지의 구성 파일에 저장소를 지정하고 인증하여 사용할 수 있습니다. 예를 들어, npm을 사용해서 게시하려면 다음과 같은 단계를 따를 수 있습니다.

원격 저장소를 만든 뒤, npm 프로젝트에서 package.json 파일을 찾습니다.

package.json 파일 안에 publishConfig 필드를 추가하여 어느 저장소에 배포할 것인지를 지정해줍니다.

깃허브에 인증하고, 마지막에 npm publish 명령어를 사용해 깃허브 패키지에 게시할 수 있습니다.

Code Review

코드 리뷰(code review)는 깃허브에서 제공하는 시각적인 기능입니다.

위 그림처럼 모든 커밋에 대해 시각적으로 도움을 제공합니다. 새로 추가되거나 변경된 사항들은 초록색, 변경되기 전 원래 사항들은 빨간색으로 표시됩니다.

이처럼 모든 커밋에 대해서 변동사항을 확인하여 개발자들끼리의 의사소통을 더 수월하게 진행할 수 있습니다.

Pull Request

PR(Pull Request)는 깃허브의 가장 중요한 기능 중 하나입니다.

여러 명이 협업하는 저장소의 경우에 프로젝트를 매니징하는 사람이 다른 개발자들이 작업한 코드들을 검토할 수 있도록 보낼 수 있는 기능입니다.

위 그림처럼 받은 PR에 대해서 처리할 수 있고, 완료된 PR은 Closed 상태로 변하여 저장됩니다.

Protected Branches

이 기능은 브랜치를 보호하는 기능입니다. 큰 규모의 프로젝트의 경우, 하나의 브랜치만 사용하는 것이 아니라 여러 개의 브랜치를 사용합니다.

주로 이슈마다 브랜치를 만들고, 각 브랜치를 main 브랜치에 merge하여 개발을 하는 방식을 많이 사용합니다.

각 브랜치마다 규칙을 지정하여 실수로 지워지는 것을 방지하거나, PR이 아닌 다른 방식의 커밋을 막아 코드리뷰를 방지하는 등 여러가지 규칙을 적용시킬 수 있습니다.

위 그림처럼 각 깃허브 저장소의 settings에 가면 브랜치 보호 규칙을 지정할 수 있습니다.

위 그림의 사진의 리스트처럼 여러가지 규칙을 적용하여 각 브랜치를 보호할 수 있습니다.

Code Owner

Code Owner 기능은 특정 파일이나 디렉토리에 대한 소유권을 지정한 사용자 혹은 팀에게 할당할 수 있는 기능입니다.

이 기능을 사용하게 된다면, 해당 파일이나 디렉토리에 대한 변경사항이 포함된 PR이 생성될 시, 자동으로 해당 코드 오너들을 리뷰어로 지정할 수 있습니다.

프로젝트의 루트 디렉토리, .github/, docs/ 디렉토리 내에 CODEOWNERS 파일을 생성하게 되면 깃허브에서 자동으로 인식을 하게 됩니다.

위 그림처럼 파일이나 디렉토리에 코드 오너를 설정해주는 것이 가능합니다.

이 기능을 사용한다면 코드 품질을 유지할 수 있고, 보안을 강화할 수 있습니다. 추가적으로 코드 오너의 승인이 있어야만 merge가 가능하게 설정할 수도 있습니다. 이는 저장소 설정에서 Require review from Code Owners 옵션을 활성화하여 구현할 수 있습니다.

Draft Pull Request

Draft PR은 정식으로 PR을 보내는 것이 아니라, 현재 자신이 마주한 문제를 코드와 함께 설명하기 위해 주로 사용됩니다.

깃허브의 개발자들은 이 Draft PR을 사용하여 해당 개발자의 현재 코드 상태와 문제점을 쉽고 빠르게 파악할 수 있습니다.

새로운 PR을 생성할 때, 위 그림처럼 생성하게 되면 Draft PR로 생성하여 다른 사람들과 코드를 나누는 것이 가능합니다.

Automatic Code Riview Assignment

이 기능은 자동으로 코드를 리뷰하는 사람을 할당해주는 기능입니다.

깃허브의 개발자들은 이 Draft PR을 사용하여 해당 개발자의 현재 코드 상태와 문제점을 쉽고 빠르게 파악할 수 있습니다.

기존에 소개된 CODEOWNERS 기능을 활용하여 구현하는 것이 가능합니다.

Environment Protection Rules

이는 깃허브 액션 워크플로우에서 특정 환경에 대한 배포를 보호하고 관리하기 위한 기능으로 사용됩니다.

이 규칙을 사용하여 배포 프로세스 중 특정 조건을 충족시키도록 요구함으로써, 민감한 환경의 안정성과 보안을 강화할 수 있습니다.

기존에 소개된 CODEOWNERS 기능을 활용하여 구현하는 것이 가능합니다.

깃허브 저장소의 Settings 탭을 통해 Environment 섹션을 찾을 수 있습니다.

그 이후 해당 상황에 알맞게 항목들을 추가하여 사용하는 것이 가능합니다.

특정 사용자나 팀에 리뷰를 요구하거나, 배포 전에 일정 시간 기다리는 것, 특정 브랜치에서만 배포가 가능하게 하는 것 등의 기능을 수행할 수 있습니다.

더불어 Environment에 대한 Secret을 추가하여 민감한 정보를 보호하는 것이 가능합니다. 워크플로우가 실행될 때만 이 값들에 접근할 수 있고, 저장소의 코드나 로그에 노출되지 않게 보호할 수 있습니다.

Projects

Projects는 오픈소스 프로젝트의 규모가 커질 수록 필수적으로 사용되는 기능입니다.

현재 진행 중이거나, 완료 혹은 진행 예정인 사항들을 여러가지 형식으로 표기해서 공유하는 것이 가능합니다.

깃허브의 각 저장소에서 Projects 탭을 눌러 접근이 가능합니다.

위 사진들처럼 3가지의 형식으로 표기가 가능하고, 새로운 이슈를 생성하는 것이 가능합니다.

Milestones

Milestone은 프로젝트의 이정표와 같은 역할을 수행합니다.

하나의 마일스톤은 여러 개의 이슈로 구성이 될 수 있고, 각 마일스톤은 프로젝트의 발전에 한 단계를 담당하게 됩니다.

깃허브의 Issues 탭을 눌러 새로운 마일스톤을 등록하는 탭으로 이동할 수 있습니다.

그 다음, 현재 진행 중인 마일스톤을 확인할 수도 있고 새로운 마일스톤을 등록할 수도 있습니다.

새로운 마일스톤을 등록하고 나면 마일스톤 탭에서 확인이 가능합니다. 여러 개의 이슈를 할당한 다음, 이슈가 할당되는 개수만큼 마일스톤의 퍼센트가 올라가게 됩니다.

모든 이슈가 해결이 될 경우, 그 마일스톤은 해결된 마일스톤으로 분류되어 다른 업무를 수행하게 됩니다.

Discussion

Discussion은 깃허브의 이슈보다 더 넓은 범위의 소통이 필요할 때 사용됩니다.

여러가지 방식으로 사용되며, 프로젝트와 관련한 아이디어나 질문, 인사이트를 나누는 공간으로 사용될 수 있습니다.

이 기능은 깃허브 저장소에서 자동으로 생성이 되는 것이 아니라 사용자들이 직접 기능을 열어야 사용할 수 있습니다.

깃허브의 저장소에 Settings 탭으로 들어가 Discussion 항목을 활성화 시켜줄 수 있습니다.

그 다음, 깃허브 이슈를 생성하는 것처럼 여러가지 글을 생성하여 다른 개발자들과 소통하는 것이 가능합니다.

Organization and Team Management

깃허브의 조직(Organization)은 하나의 그룹을 의미합니다. 하나의 Organization은 여러 개의 repository를 보유할 수 있습니다.

이러한 깃허브 조직 내에서도 개인의 권한을 세부적으로 나눌 수 있습니다. 이를 통해 코드의 잘못된 작성과 merge를 방지할 수 있습니다.

깃허브 조직의 설정의 내부에서 Member privileges 탭으로 이동하면 각 항목에 대해 수정을 진행할 수 있습니다.

또한 깃허브의 조직 내부에는 개인과 여러 개인으로 구성된 팀이 존재합니다. 이 팀은 다음과 같은 방식으로 지정해줄 수 있습니다.

깃허브 조직 내의 Team 탭으로 이동하고 난 다음에 위 사진과 같이 새로운 팀을 만드는 탭으로 이동할 수 있습니다.

위 방식대로 만들어진 Team은 하나의 공동체로 묶이게 되며, 코드 리뷰 할당 및 이슈 할당 등 여러가지 항목에 대하여 모든 팀원에게 같은 업무를 할당할 수 있습니다.

이러한 팀을 세부적으로 나누어 각 팀이 가지는 권한을 조정할 수 있고, 이를 통해 더욱 체계적인 코드 작성이 가능합니다.

Wiki

Wiki는 Repository의 설명을 담은 글을 의미합니다.

Wiki는 public repository에서만 사용이 가능합니다. 저장소를 공개로 설정할 경우, Wiki탭을 이용해 위 사진과 같은 페이지로 넘어갈 수 있습니다.

이동한 다음에는 새로운 위키를 만들 수 있습니다.

위키를 작성하여 업로드 할 경우에는, 위 사진처럼 생성된 위키를 확인할 수 있습니다.

이러한 위키는 HSF 생태계에서 새로운 프로젝트에 참여하려는 개발자들에게 유용하게 사용될 수 있습니다.

Multiple Issue Assignees

하나의 이슈에 대해서 여러 사람들을 할당할 수 있습니다.

이슈를 작성하는 페이지에서 오른쪽 상단에 위차한 Assignee 탭을 통해 여러 명의 사람들을 해당 이슈에 할당할 수 있습니다.

개인을 할당하는 것 뿐만 아니라 팀을 이슈에 할당하여 여러 사람을 한 번에 해당 이슈에 묶어서 할당할 수 있습니다.

Code Scanning & Secret Scanning

코드 스캐닝은 깃허브에서 제공하는 보안 관련 기능입니다. 해당 저장소의 코드를 분석하여 보안 취약성 및 코딩 오류를 찾는데 사용할 수 있습니다.

기존 문제에 대한 수정사항을 찾고 우선 순위를 지정하는 것이 가능하며, 개발자가 새로운 문제를 발생시키는 것을 방지합니다.

코드 스캐닝을 사용하면 날짜와 시간을 지정한 정기 검사를 진행할 수 있습니다. 깃허브 액션을 통해 이루어지고 기본적으로는 CodeQL 제품을 사용합니다.

코드 저장소의 Security 탭을 통해 Code Scanning 탭으로 이동할 수 있습니다.

이 페이지로 넘어가면, 코드 스캐닝을 어떻게 사용할 것인 지에 대해 설정 해주는 것이 가능합니다.

이 사진에 나와있는 것처럼, 어떤 제품을 사용할 것인지를 결정할 수 있습니다.

추가적으로 어떤 날짜에 어떤 작업을 수행할 것인지를 해당 사진처럼 설정하여 프로젝트마다 지정하여 적용시킬 수 있습니다.

Secret Scanning은 깃허브에서 제공하는 다른 보안 관련 기능 중 하나입니다. 해당 저장소의 코드를 분석하여 유출된 정보를 저장소 개발자들에게 알리는 기능을 담당합니다.

보안 관련 알림을 받을 사람을 지정하여 설정할 수 있고, git history를 사용하여 코드를 분석해 브랜치 커밋마다 코드를 분석하고 검사를 진행하는 것이 가능합니다.

Dependency Review & Dependabot Alerts

소프트웨어 개발 중에서 의존성은 중요한 항목 중 하나로 작용합니다. 이 의존성 중에서 안전하지 않아 수정된 버전이 배포되고, 이 이전 버전을 사용할 경우 프로젝트에 좋지 않은 영향을 끼칠 수 있습니다.

Dependency Review는 PR 중에서 해당 프로젝트의 종속성이 변경된 PR에 적용하여 안전하지 않은 의존성 목록을 파악할 수 있습니다.

의존성 리뷰를 사용하기 위해서는 Insight 항목에서 의존성 그래프를 활성화 시켜줘야 합니다.

그 이후 의존성이 변경된 항목에서 Files changed 탭을 선택하여 종속성의 변경사항과 보안 취약점을 확인할 수 있습니다.

Dependabot Alerts는 깃허브에서 저장소가 보안에 취약한 저장소를 사용하는 것을 감지하면 알림을 보내주는 기능입니다.

대부분의 저장소에서 기본적으로 활성화 되어있는 기능으로, 새로운 취약점이 발생할 때마다 자동으로 저장소 보유자와 보안 경고를 구독한 사용자에게 알림이 전송됩니다.

하지만 활성화 되어있지 않다면, Settings로 이동하여 활성화 시켜줄 수 있습니다.

활성화 되어있다면, Security 탭에서 Dependabot alerts 섹션을 선택하여 현재까지 발생한 모든 보안 경고를 확인할 수 있습니다.

이 기능은 비공개 저장소에서도 사용할 수 있으며, 저장소 소유자와 접근 권한을 가진 사용자만 경고를 볼 수 있습니다.

추가적으로 .github/dependabot.yml 파일을 통해 dependabot의 동작을 더욱 세밀하게 조정할 수 있습니다. 예를 들어, 업데이트할 의존성 유형, 업데이트 빈도 및 대상 브랜치 등을 지정할 수 있습니다.

이 Dependabot은 Security update와 Version update 2가지 주요한 기능을 가지고 있습니다.

Security update는 Settings의 Security & analysis 탭에서 Dependabot security updates를 활성화 시켜주면 사용할 수 있는데, 보안적으로 취약한 의존성이 발생할 경우 안전한 버전으로 업데이트하는 PR을 자동으로 생성해주는 기능입니다.

Version updates는 프로젝트의 의존성을 자동으로 최신 상태로 유지합니다. 의존성이 업데이트 될 때마다 자동으로 PR을 생성하게 되고, dependabot.yml 파일을 통해 해당 기능을 사용할 수 있습니다.

GitHub Security Advisories

이 기능은 오픈소스 프로젝트 관리자들이 보안 취약점을 신고하고, 이에 대한 공지 및 대응 방안을 작성하며, 커뮤니티와 안전하게 공유할 수 있도록 돕는 기능입니다.

보안 취약점이 공개되기 전에 비공개로 논의를 할 수 있고, 보안 취약점이 해결된 이후에는 공개적으로 공지하여 사용자들이 알맞은 조치를 취할 수 있도록 도와줍니다.

Security 탭에서 Advisory로 이동하면 위와 같은 화면이 나오게 됩니다.

새로운 Draft를 만들게 되면 위 사진과 같이 보안과 관련해 어떤 이슈가 발생했는지 구체적으로 기술할 수 있게 되어있습니다.

작성이 완료된 이후에 마지막 버튼을 누르게 되면 보안 신고글 작성이 완료됩니다.

작성된 게시물은 아직 사람들에게 공개되지 않은 비공개 형식으로 업로드 됩니다. 이 게시물을 통해 해당 프로젝트 관계자들은 해결 방안을 논의하여 보안 문제를 다룰 수 있습니다.

문제가 해결되어 Publish가 될 경우, 모든 사용자들이 이 문서를 열람할 수 있게 되고 취약점에 대해 알맞은 대응을 취할 수 있게 됩니다.

Role-based Access Control(RBAC)

RBAC는 깃허브에서 조직 및 저장소 수준에서 사용자에게 다양한 역할과 권한을 할당하여 접근을 관리하는 기능입니다. 이를 통해 프로젝트의 보안을 강화하고 필요한 작업을 수행하는 사용자를 정밀하게 제어할 수 있습니다.

조직 수준에서 RBAC는 Owner, Member, Billing Manager 3가지로 분류됩니다.

Owner는 모든 설정을 변경할 수 있는 가장 높은 권한을 가집니다. 조직 내의 모든 프로젝트와 멤버를 관리할 수 있습니다.

Member는 기본적으로 조직 내 저장소에 접근할 수 있으며, 특정 권한이 부여된 저장소에서 작업을 수행할 수 있습니다.

Billing Member는 조직의 결제 관련 설정을 관리할 수 있는 권한을 지닙니다.

위 사진처럼 조직의 메인 페이지로 이동한 후, People 탭을 선택하여 사용자 목록에서 변경하고자 하는 사용자의 드롭다운을 클릭한 후에 적절한 역할로 변경해줄 수 있습니다.

저장소 수준에서 RBAC는 Admin, Maintainer, Write, Triage, Read 5가지로 나뉩니다.

Admin은 저장소의 설정을 변경하고, 보호된 브랜치 규칙을 설정하는 등의 모든 권한을 가집니다.

Maintainer는 저장소 설정을 관리할 수는 있으나, 저장소를 삭제하거나 공개/비공개 설정을 전환하는 등의 행동은 할 수 없습니다.

Write는 저장소에 코드를 푸시하고, 이슈 및 PR을 관리할 수 있습니다.

Read는 저장소를 볼 수 있으며, 이슈와 PR에 코멘트를 작성할 수 있습니다.

저장소의 Settings - Collaborators & Teams 섹션으로 이동하면 Collaborators의 Access 버튼을 활용하여 사용자의 권한을 수정해줄 수 있습니다.

조직 및 저장소의 권한을 설정해줄 때에는 개인의 작업 범위와 역할을 고려하여 설정해주어야 합니다.

Required 2FA

이 기능은 깃허브 조직의 보안을 강화하기 위해 2단계 인증(2FA)을 필수로 설정할 수 있는 옵션을 제공합니다.

조직 내의 모든 사용자들은 2FA를 활성화해야만 조직의 저장소에 접근할 수 있도록 이 설정을 적용할 수 있습니다.

깃허브 조직의 Settings 내부의 Security 섹션으로 이동한 후, Authentication Security 탭을 클릭하게 되면 위 사진과 같은 화면이 나오게 됩니다.

여기서 Two-factor authentication을 설정해주게 되면 해당 조직은 2FA 보안이 적용되게 됩니다.

이 때, 2FA를 설정하지 않은 멤버들을 보여주는데, 만일 그대로 진행하게 된다면 이 멤버들은 접근 권한을 잃게 됩니다. 따라서 2FA를 설정하기 전에 모든 사용자가 2FA를 활성화할 수 있도록 충분한 안내와 시간을 제공해야 합니다.

2FA를 활성화할 때, 깃허브는 2FA 설정으로 인해 권한을 잃은 사용자가 다시 접근할 때 사용되기 때문에 안전한 곳에 저장해야 합니다.

Audit Log

Audit Log는 조직의 이벤트와 활동에 대한 상세한 기록을 제공합니다.

이 기능을 통해 관리자는 이벤트, 멤버십 변경, 저장소 설정 변경 등 다양한 활동을 추적하고 검토할 수 있습니다. 이는 조직의 투명성을 높이고 보안 문제를 식별하는 데 도움을 줄 수 있습니다.

조직 설정으로 이동한 후, 우측 상단에 위치한 Settings로 이동합니다.

그 이후 위 사진과 같이 Audit log 탭으로 이동합니다.

그렇게 되면 위 사진과 같이 모든 이벤트와 활동의 로그를 볼 수 있습니다. 특정 기준으로 검색하고 필터링 하는 것이 가능하고, csv 파일의 형태로 내보내기가 가능합니다.

Audit log의 접근 권한은 Owner에게만 주어지고, 제한된 기간 동안만 보존합니다. 이 기간은 깃허브 조직의 요금제에 따라 차이가 발생합니다.