GitHub Foundations #9 Domain 7: GitHub 커뮤니티 + 시험 팁

마지막 도메인인 Benefits of the GitHub Community는 분량이 크지 않고, 묻는 방식도 대부분 정의를 그대로 확인하는 형태입니다. 개념의 이름과 한 줄 정의만 정확히 연결해 두면 빠르게 득점하고 지나갈 수 있는 영역입니다. 도메인 정리를 마친 뒤에는 시리즈 관례대로 시험 직전에 확인할 팁을 함께 묶었습니다.

오픈소스와 소스 공개는 다릅니다 #

시험이 가장 좋아하는 구분부터 시작합니다. 저장소를 public으로 바꾸는 것과 오픈소스는 같지 않습니다.

• 소스 공개(source available) — 코드를 누구나 볼 수 있는 상태입니다. 보는 것과 쓰는 것은 별개라서, 라이선스가 없으면 법적으로는 사용·수정·재배포 권한이 부여되지 않습니다.
• 오픈소스(open source) — 코드 공개에 더해, 사용·수정·재배포를 허용하는 라이선스가 부여된 상태입니다. MIT, Apache 2.0, GPL 같은 라이선스 파일이 그 권한의 근거입니다.

그래서 “public 저장소인데 LICENSE 파일이 없는 프로젝트"는 오픈소스가 아니라는 함정 선택지가 성립합니다. 라이선스별 차이(허용형과 카피레프트의 구분 등)는 Foundations 수준에서는 깊이 들어가지 않으므로, 라이선스가 권한을 정의한다는 원칙까지만 정확히 잡아 두면 됩니다.

커뮤니티 파일 — 프로젝트의 안내판 세트 #

건강한 오픈소스 프로젝트가 갖추는 표준 파일들입니다. 각 파일의 역할을 매칭하는 문제가 나옵니다.

이 파일들이 갖춰졌는지 한눈에 확인하는 화면이 이전 글에서 다룬 저장소 Insights의 Community Standards 체크리스트입니다. .github 저장소를 만들어 두면 조직의 여러 저장소가 이 파일들을 공통으로 상속할 수 있다는 점도 함께 기억해 둘 만합니다.

InnerSource — 오픈소스 방식을 조직 안으로 #

InnerSource는 오픈소스의 협업 방식을 조직 내부의 private 저장소에 적용하는 것입니다. 코드는 회사 밖으로 공개하지 않지만, 조직 안에서는 다른 팀의 저장소를 열람하고, 이슈를 열고, PR로 기여하는 오픈소스식 흐름을 따릅니다.

• 오픈소스와의 차이는 공개 범위입니다. 오픈소스의 대상이 전 세계라면 InnerSource의 대상은 조직 내부입니다.
• 효과는 사일로 해소입니다. 팀 사이의 중복 개발이 줄고, 잘 만든 내부 라이브러리에 조직 전체의 기여가 모입니다.

정의만 물어도, 시나리오(“사내 코드베이스에 오픈소스식 기여 문화를 도입하려 한다”)로 물어도 답이 InnerSource로 수렴하는, Domain 7의 대표 출제 지점입니다.

후원·확장·학습 — 나머지 커뮤니티 기능 #

이름과 용도만 연결해 두면 되는 항목들입니다.

• GitHub Sponsors — 오픈소스 개발자와 프로젝트를 금전적으로 후원하는 기능입니다.
• GitHub Marketplace — Actions와 앱 같은 확장 도구를 찾고 설치하는 장터입니다.
• GitHub Community — 사용자들이 질문하고 토론하는 공식 포럼입니다.
• GitHub Skills — 실습 저장소 기반의 무료 학습 코스 모음으로, 이 시험의 공식 준비 자료이기도 합니다.

오픈소스 기여의 표준 사이클 #

커뮤니티 도메인은 기여 절차를 시나리오로 묻기도 합니다. 다른 사람의 공개 저장소에 기여하는 표준 흐름은 다음 순서입니다.

1. 저장소를 내 계정으로 fork합니다. 원본에 push 권한이 없으므로 서버 측 복사본이 필요합니다.
2. fork를 clone해 브랜치를 만들고 변경을 커밋합니다.
3. fork에 push한 뒤, 원본 저장소를 향해 PR을 엽니다. fork의 브랜치가 compare, 원본의 브랜치가 base가 됩니다.
4. 리뷰를 반영하고, 머지는 원본 저장소의 관리자가 결정합니다.

CONTRIBUTING 문서가 이 절차의 프로젝트별 규칙(브랜치 이름, 커밋 규약, 테스트 요구 사항)을 정의하므로, 기여 전에 가장 먼저 읽어야 할 파일을 물으면 답은 CONTRIBUTING입니다.

프로필과 발견 기능 #

• 프로필 README — 계정 이름과 같은 이름의 저장소에 README를 두면 프로필 상단에 자기소개로 표시됩니다.
• 스타(star) — 저장소를 북마크하는 기능이며, 스타 수는 프로젝트의 인지도를 가늠하는 신호로 쓰입니다.
• 팔로우와 트렌딩 — 다른 사용자의 활동을 피드로 받아 보고, Explore와 트렌딩에서 주목받는 저장소를 발견합니다.

여기까지가 일곱 도메인의 마지막 조각입니다. 이제 시험장으로 가기 전에 확인할 것들을 정리합니다.

시험 팁 — 문제 유형별 접근 #

Foundations의 문제는 크게 세 유형으로 나뉩니다.

• 정의 매칭형 — “조직 내부에 오픈소스 방식을 적용하는 것은?” 같은 직접 확인 문제입니다. 이 시리즈의 표들을 뒤집어 놓은 형태이므로, 각 표를 양방향(이름→정의, 정의→이름)으로 읽어 두면 됩니다.
• 기능 경계형 — 비슷한 두 기능 중 시나리오에 맞는 쪽을 고르는 문제입니다. 플랜 차이, 저장소 role, Dependabot 세 기능처럼 경계가 있는 곳이 전부 후보입니다.
• UI 위치형 — “이 정보를 어디에서 확인하는가"를 묻는 문제입니다. Insights의 탭 구성, 설정 화면의 위치를 떠올릴 수 있어야 합니다.

자주 틀리는 패턴 #

• fork vs clone — fork는 GitHub 계정에 만드는 서버 측 복사본이고, clone은 내 컴퓨터로 받는 로컬 복사본입니다. “다른 사람의 공개 저장소에 기여하려면"의 첫 단계는 fork입니다.
• Issue vs Discussion — Issue는 추적해서 닫아야 할 작업·버그이고, Discussion은 결론이 열려 있는 질문·아이디어 대화입니다.
• github.dev vs Codespaces — github.dev는 브라우저 에디터일 뿐 코드 실행 환경이 없고, Codespaces는 클라우드에서 돌아가는 완전한 개발 환경입니다. “터미널에서 빌드까지 하려면"의 답은 Codespaces입니다.
• Write vs Maintain vs Admin — push와 머지는 Write부터, 저장소 설정은 Maintain부터, 보안 설정과 삭제는 Admin 전용입니다.
• Git vs GitHub — Git은 로컬에서 동작하는 버전 관리 도구이고, GitHub는 그 위에 협업 기능을 얹은 호스팅 서비스입니다. PR처럼 GitHub 쪽 기능을 Git 명령으로 착각하게 만드는 선택지를 걸러냅니다.

시간 관리와 응시 환경 #

• 120분에 75문항 안팎이므로 문항당 90초 이상의 여유가 있습니다. 막히는 문제는 플래그를 걸고 넘어간 뒤 마지막에 재검토하는 편이 전체 득점에 유리합니다.
• 온라인 프록터(PSI) 응시라면 신분증, 웹캠, 화면 공유가 되는 조용한 공간을 미리 점검하고, 시험 프로그램의 시스템 체크를 하루 전에 돌려 봅니다. 책상 위 소지품 제한 같은 규정도 사전 안내를 따릅니다.
• 합격 기준과 도메인 가중치는 변동될 수 있으므로, 응시 직전에 공식 study guide의 최신 판을 한 번 확인하는 것이 안전합니다.

마무리 #

이번 글의 핵심은 세 가지입니다.

• 오픈소스는 공개된 코드가 아니라 라이선스로 사용·수정·재배포 권한이 부여된 코드이고, InnerSource는 그 협업 방식을 조직 내부에 적용한 것입니다.
• Sponsors, Marketplace, Skills 같은 커뮤니티 기능은 이름과 용도의 일대일 매칭으로 출제됩니다.
• 문제 유형은 정의 매칭, 기능 경계, UI 위치 세 가지로 수렴하며, 경계가 있는 표들을 양방향으로 읽어 두는 것이 최선의 준비입니다.

다음 글 “GitHub Foundations #10 보너스 — 풀스케일 객관식 모의고사"가 시리즈의 마지막입니다. 일곱 도메인 전체를 실제 시험과 같은 형식의 50문항으로 점검하고, 각 문항에 해설을 붙였습니다.