성공적인 InnerSource 프로그램을 관리하는 방법
여기서는 소프트웨어 개발 조직 내에서 오픈 소스 패턴을 최대한 활용할 수 있도록 InnerSource 프로그램을 설계하는 방법을 설명합니다.
InnerSource란?
누구나 오픈 소스 소프트웨어를 자유롭게 사용하고, 수정하고, 공유할 수 있습니다. 오픈 소스 소프트웨어를 사용하면 누구나 코드를 공유하면 더 나은 신뢰할 수 있는 소프트웨어로 이어진다는 생각으로 모든 용도로 프로젝트를 보고 수정하고 배포할 수 있습니다.
InnerSource는 대상 그룹이 제한된 프로젝트에 오픈 소스 패턴을 적용하는 방식입니다. 예를 들어 회사에서 직원만 액세스할 수 있다는 점만 제외하고 일반적인 오픈 소스 프로젝트의 구조가 반영된 InnerSource 프로그램을 설정할 수 있습니다. 사실상 회사 방화벽의 보호를 받는 오픈 소스 프로그램입니다.
InnerSource 이점
InnerSource 프로그램은 기존의 폐쇄된 소스 모델보다 많은 무수한 이점을 제공할 수 있습니다.
먼저 ‘투명성을 향상합니다’. 개발자는 다른 회사 프로젝트의 소스 코드에 액세스하여 담당 프로젝트를 진행할 때 생산성을 높일 수 있습니다. 당면하고 있는 비슷한 문제를 다른 팀은 어떻게 해결하는지 참조할 수 있으며, 다시 사용할 수 있는 코드와 기타 자산을 찾기도 합니다. 팀 이슈, 끌어오기 요청 및 프로젝트 계획에 액세스하면 프로젝트의 진행 속도와 방향을 파악하는 데 유용한 데이터도 얻을 수 있습니다.
다음으로 ‘충돌을 줄입니다’. 소비자 팀이 다른 팀이 소유한 프로젝트의 버그 수정이나 새로운 기능에 의존한다고 가정해 보겠습니다. InnerSource 프로그램에는 필요한 변경을 제안할 수 있는 채널이 있습니다. 그리고 어떤 이유로 인해 이러한 변경 내용을 병합할 수 없는 경우 소비자 팀은 필요에 맞게 프로젝트를 포크할 수 있습니다.
마지막으로 ‘방식을 표준화합니다’. 개발 조직이 겪는 일반적인 문제 중 하나는 팀마다 운영 방식이 다른 경우가 자주 있다는 것입니다. InnerSource 프로그램을 구축하면 동일한 방식을 따르진 않더라도 모든 개발 팀에서 활용할 수 있는 표준 규칙을 채택할 좋은 기회가 생깁니다. 예를 들어 두 팀이 기여를 수락하는 데 서로 다른 절차를 선호할 수 있습니다. 두 팀이 서로 다른 프로세스를 전달하는 방식을 표준화하도록 하면 어느 팀에든지 누구나 더욱 쉽게 참여할 수 있습니다.
이러한 예는 InnerSource 프로그램으로 누릴 수 있는 몇 가지 이점에 불과합니다. 자세히 알아보려면 An introduction to InnerSource(InnerSource 소개)를 참조하세요.
GitHub에서 InnerSource 프로그램 설정
리포지토리 표시 유형 및 사용 권한 설정
세 가지 수준의 표시 유형으로 GitHub 리포지토리를 구성할 수 있습니다. 표시 유형 요구 사항을 충족하지 않는 사용자가 리포지토리에 액세스하려고 하면 “찾을 수 없음” 페이지가 표시됩니다. 수준은 다음과 같습니다.
- 퍼블릭 리포지토리는 모든 사용자에게 표시됩니다. 실제로 오픈 소스이고 조직 내외부의 사용자에게 액세스 권한을 제공하는 프로젝트에서는 이 표시 유형을 사용합니다.
- 내부 리포지토리는 소유 조직의 구성원에게만 표시됩니다. InnerSource 프로젝트에는 이 표시 유형을 사용합니다.
- 프라이빗 리포지토리는 소유자 및 소유자가 추가하는 팀 또는 개인에게만 표시됩니다. 특정 사용자 및 그룹만 액세스해야 하는 프로젝트에는 이 표시 유형을 사용합니다.
리포지토리 표시 유형을 설정한 후에는 개인 또는 팀별로 사용 권한을 구성할 수 있습니다. 5가지 사용 권한 수준이 있습니다.
- 읽기 수준은 프로젝트를 보거나 논의하려는 비코드 참여자에게 사용하는 것이 좋습니다.
- 심사 수준 - 이슈와 끌어오기 요청을 사전에 관리해야 하는 참여자에게 사용하는 것이 좋으며 쓰기 권한이 없습니다.
- 쓰기 수준 - 프로젝트에 적극적으로 푸시하는 참여자에게 사용하는 것이 좋습니다.
- 유지 관리 수준 - 리포지토리를 관리해야 하는 프로젝트 관리자에게 사용하는 것이 좋으며 중요하거나 안전하지 않은 작업에 대한 액세스 권한은 없습니다.
- 관리 수준 - 보안 관리 또는 리포지토리 삭제와 같은 중요하고 안전하지 않은 작업을 포함하여 프로젝트에 대한 모든 권한이 필요한 사용자에게 사용하는 것이 좋습니다.
자세한 내용은 repository access permissions by level(수준별 리포지토리 액세스 권한)을 참조하세요.
검색 가능한 리포지토리 만들기
InnerSource 프로그램이 진행됨에 따라 리포지토리 수가 크게 늘어날 수 있습니다. 이러한 모든 자산을 조직에서 사용할 수 있도록 하는 것이 좋지만, 콘텐츠를 효율적으로 찾기 어려워질 수 있습니다. 이 문제를 사전에 해결하려면 팀에서 리포지토리를 다른 사용자가 더 쉽게 찾고 사용할 수 있도록 하기 위해 무엇을 할 수 있는지 고려하는 것이 가장 좋습니다.
몇 가지 모범 사례는 다음과 같습니다.
warehouse-api또는supply-chain-web과 같이 설명이 포함된 리포지토리 이름을 사용합니다.- 간결한 설명을 포함합니다. 한두 문장이라도 잠재적 사용자가 필요에 맞는 프로젝트인지 파악하는 데 도움이 됩니다.
- 고객이 소프트웨어를 사용, 변경 및 배포하는 방법을 알 수 있도록 리포지토리에 라이선스를 부여합니다.
- 리포지토리에
README.md파일을 포함합니다. GitHub는 사용자가 리포지토리를 방문할 때 방문 페이지로 이 파일을 사용합니다.
README 파일 추가
추가 정보 파일은 프로젝트에 대한 기대치를 전달하고 기여를 관리하는 데 도움이 됩니다. 추가 정보 파일은 다음을 포함할 수 있습니다.
- 잠재적 소비자가 필요에 맞는지 파악할 수 있도록 프로젝트의 목적과 비전을 명확히 표현합니다.
- 프로젝트를 실제로 보여 주는 스크린샷 또는 코드 샘플과 같은 시각적 보조 기능을 제공합니다.
- 검토를 위해 앱의 프로덕션 또는 데모 버전으로 연결되는 링크를 포함합니다.
- 필수 조건 및 배포 절차에 관한 기대 수준을 설정합니다.
- 종속된 프로젝트에 대한 참조를 포함합니다. 이러한 참조는 다른 사용자의 작업을 승격하는 좋은 방법입니다.
- Markdown을 활용하여 독자에게 올바른 형식의 콘텐츠를 안내합니다.
README 파일을 리포지토리의 루트 디렉터리나 숨겨진 .github 또는 docs 디렉토리에 넣으면 GitHub는 README를 인식하여 리포지토리 방문자에게 자동으로 표시합니다. 리포지토리에 둘 이상의 추가 정보 파일이 포함된 경우 표시된 파일은 .github 디렉터리, 리포지토리의 루트 디렉터리, 마지막으로 docs 디렉터리 순으로 선택됩니다.
몇 가지 Awesome README examples(유용한 추가 정보 예)를 확인하세요.
프로젝트가 시작되면 전자 메일 및 기타 네트워킹 채널을 사용하여 프로젝트를 홍보합니다. 적절한 대상 그룹에 접근하면 프로젝트 참여를 크게 늘릴 수 있습니다.
GitHub에서 프로젝트 관리
프로젝트가 관심을 받게 되면 급증하는 사용자와 참여를 관리하기 위해 많은 작업이 필요할 수 있습니다. 프로젝트에 따라 프로젝트 참가자의 기대 수준을 관리하는 데에만도 상당한 양의 작업이 필요할 수 있습니다.
이를 사전에 해결하기 위해 GitHub에서는 리포지토리의 루트(또는 /docs나 /.github)에 있는 CONTRIBUTING.md 파일을 확인합니다. 이 파일을 사용하여 프로젝트의 참여 정책을 설명합니다. 정확한 세부 정보는 다를 수 있지만 잠재적 기여자에게 프로젝트가 따르는 규칙을 알려주는 것이 좋습니다. 예를 들어 팀에서 끌어오기 요청을 찾고 있는 경우, 버그 보고서에 대해 요청되는 세부 정보 등을 알려줍니다.
CONTRIBUTING.md가 있는 경우 GitHub에서는 사용자가 이슈 또는 끌어오기 요청을 만들 때 이 파일을 따르도록 관련 링크를 제공합니다.
몇 가지 Awesome CONTRIBUTING.md examples(유용한 CONTRIBUTING.md 예)를 확인하세요.
또한 코드 수정을 검토할 책임이 있는 개인 또는 팀을 정의하기 위해 리포지토리에 CODEOWNERS 파일을 추가하는 것이 좋습니다.
이슈 및 끌어오기 요청 템플릿 사용
GitHub에서는 새로운 이슈 및 끌어오기 요청을 위한 시작 템플릿을 지원합니다. 이러한 템플릿을 사용하여 새로 만드는 이슈나 끌어오기 요청의 초기 설명 텍스트를 제공합니다.
예를 들어 프로젝트에 .github/ISSUE_TEMPLATE.md가 있으면 사용자가 이슈를 만드는 프로세스를 시작할 때마다 이 콘텐츠가 표시됩니다. 따라서 필요한 정보를 CONTRIBUTING.md에서 계속 참조하는 대신 템플릿 텍스트를 양식처럼 사용하여 이슈를 작성할 수 있습니다.
끌어오기 요청도 경로가 .github/PULL_REQUEST_TEMPLATE.md인 점만 제외하고 똑같습니다.
몇 가지 Awesome GitHub issue & pull request templates(유용한 GitHub 이슈 및 끌어오기 요청 템플릿)를 확인하세요.
워크플로 정의
외부 참여를 권장하는 프로젝트의 경우 프로젝트에서 따르는 워크플로를 지정해야 합니다. 워크플로에는 버그와 기능에 분기를 어디서 어떻게 사용해야 하는지에 대한 세부 정보가 포함되어야 합니다. 또한 끌어오기 요청을 여는 방법과 리포지토리 팀 외부 사람들이 코드를 푸시하기 전에 알아야 할 기타 세부 정보도 포함해야 합니다. 아직 워크플로를 염두에 두고 있지 않는다면 GitHub 흐름을 고려해야 합니다.
릴리스 및 배포를 관리하기 위한 전략을 전달해야 합니다. 워크플로의 해당 부분은 일상적인 분기 및 병합에 영향을 주므로 참가자에게 전달하는 것이 중요합니다. Git branching strategy(Git 분기 전략)와 어떤 관련이 있는지 자세히 알아보세요.
프로그램 성공 측정
InnerSource를 추진하는 모든 팀은 프로그램의 성공을 측정하기 위해 추적할 메트릭의 종류에 대해 생각해야 합니다. “출시 시간” 및 “보고된 버그”와 같은 기존 메트릭은 여전히 적용 가능하지만 InnerSource를 통해 얻는 이점을 설명하지 못할 수도 있습니다.
대신, 외부 참여가 프로젝트 품질을 얼마나 개선했는지를 보여주는 메트릭을 추가하는 것이 좋습니다. 리포지토리에서 버그를 수정하고 기능을 추가하는 끌어오기 요청을 외부 출처를 통해 받고 있습니까? 프로젝트 및 미래의 성과와 관련된 논의에 적극 참여하는 참가자가 있습니까? InnerSource 확장을 장려하며 조직의 다른 곳에서 이점을 향상하는 프로그램이 있습니까?
간단히 말해 개인과 팀 참여의 가치와 영향을 측정하는 것과 관련된 메트릭은 특히 까다롭습니다. 잘못 사용될 경우 메트릭은 문화와 기존 프로세스를 손상시키고 조직이나 리더십 팀을 향한 집단 정서를 약화시킬 수 있습니다. InnerSource 채택을 측정하는 방법을 고려할 때 메트릭에 대한 다음 지침을 고려합니다.
- 측정 결과가 아닌 측정프로세스
- 코드 검토 소요 시간
- 끌어오기 요청 크기
- 진행 중인 작업
- 열 시간
- 절대값이 아닌 대상에 대한 측정
- 개인이 아니라 팀 측정
- 프로젝트의 고유한 참여자 수
- 코드를 다시 사용하는 프로젝트 수
- 팀 간 @mentions 수
이 InnerSource 사례 연구에서 다른 사람들이 즐기는 성공에 관해 알아봅니다.