이너소스(Innersource) 소개

소프트웨어 개발에 이러한 현대적인 접근 방식을 도입하면 혁신적인 변화를 만들 수 있습니다. 협업을 가능하게 하며 높은 품질의 코드를 만들 수 있는 환경을 조성할 수 있습니다. 그러나 성공적인 혁신을 이루기 위해서는 원칙과 잠재적인 과제를 이해하는 것이 필수적입니다.

많은 회사에서 엔지니어링 팀이 코드 작업을 함께 진행하는 방식을 '이너 소스(innersource)'라는 용어로 설명합니다. 이너 소스는 엔지니어가 Kubernetes 또는 Microsoft의 Visual Studio Code와 같은 대규모 오픈 소스 프로젝트의 모범 사례를 사용하여 기업 소유의 소프트웨어를 구축하는 개발 방법론을 의미합니다.

대규모 오픈 소스 프로젝트는 수천 명의 기여자 간의 협력과 팀워크를 필요로 합니다. 가장 성공적인 오픈 소스 프로젝트는 속도, 안정성, 기능 등 일상적인 사용자의 요구 외에도 미래에 대한 비전을 바탕으로 추진되기도 합니다. 이러한 대규모 프로젝트는 몇 가지 교훈을 주며, 여러분의 비즈니스에도 이너 소스를 사용해 더 나은 소프트웨어를 더 빠르게 구축할 수 있도록 도움을 줍니다.

이 문서에서는 팀이 일상적인 워크플로에서 이너 소스를 어떻게 사용하고 오픈 소스 실천 사항을 어떻게 적용하여 협력적이고 효율적으로 작업하는지에 대한 기본적인 내용을 다룰 것입니다.

오픈 소스 프로젝트의 정의는 무엇인가요?

GitHub는 세계에서 가장 큰 오픈 소스 커뮤니티의 본고장입니다. GitHub 커뮤니티는 수백만 명의 기여자들의 관심사와 다양한 기술 역량을 모두 아우르는 공간을 구축합니다. 기여자들은 Apple의 Swift와 같은 프로그래밍 언어나 Facebook의 React.js와 같은 프레임워크 작업에 협력하며, 단순히 코드만 작성하지는 않습니다. 데이터 세트, 법률 문서 등도 오픈 소스가 될 수 있습니다.

오픈 소스 소프트웨어는 누구나 사용할 수 있습니다. 또한 어떤 목적이든 오픈 소스 라이선스하에서 프로젝트를 보고, 수정하고, 배포할 수 있습니다. 마찬가지로 누구나 오픈 소스 소프트웨어 구축에 기여할 수 있습니다. 일반적으로 프로젝트는 코드, 피드백, 버그 보고서 등을 공유하는 분산된 기여자들로 이루어진 커뮤니티에 의해 개발됩니다.

이러한 유형의 개방적 협업에 대한 모범 사례가 이너 소스의 기반이 되며, 이 문서의 나머지 부분에서 몇 가지 주요 학습 사항, 도구, 용어에 대해 살펴보겠습니다.

사람들이 오픈 소스 프로젝트를 어떻게 시작하고 기여하는지 자세히 알아보려면 GitHub 오픈 소스 가이드를 참조하세요.

오픈 소스 커뮤니티에서 배우는 교훈

여러분의 팀이 소프트웨어를 구축하고 있다면 이미 다른 사람의 오픈 소스 프로젝트에 참여하고 있거나 이를 기반으로 구축하고 있을 것입니다. 오픈 소스 커뮤니티에는 시간대를 초월한 협업, 기여자를 모으는 방법, 대규모의 복잡한 프로젝트를 관리하는 방법에 대한 풍부한 교훈이 있습니다. 이너 소스 실천을 시작할 때 염두에 두어야 할 몇 가지 사항은 다음과 같습니다.

더 많은 기여를 장려하는 개방적 협업

더 많은 기여는 더 많은 기회를 의미합니다. 오픈 소스 프로젝트는 전 세계 누구든지 변경할 수 있습니다. 이는 프로젝트를 발전시키고, 사용자 요구를 충족시키며, 버그를 찾고 수정하는 데 많은 이들의 지식이 투입된다는 것을 의미합니다.

마찬가지로 이너 소스는 더 많은 아이디어를 제시할 수 있습니다. 팀은 더 쉽게 혁신할 수 있으며, 더 많은 사람들이 코드의 오류와 불일치를 검사함으로써 더 안전하고 신뢰할 수 있는 소프트웨어를 구축할 수 있습니다. 문제는 부적절한 사람이 찾아내기 전에 발견되고 수정됩니다.

개발자가 항상 처음부터 시작할 필요 없음

누구나 거의 모든 목적으로 오픈 소스 프로젝트를 검색하고 재사용할 수 있습니다. 심지어 이를 통해 다른 것을 만들거나 자신의 특정 요구 사항에 맞게 수정하기 위해 오픈 소스를 사용할 수도 있습니다.

마찬가지로 이너 소스 코드는 팀이 기존 내부 프로젝트를 검색하고, 맞춤화하고, 재사용할 수 있도록 합니다. 또한 문서화��� 일련의 공유 프로세스를 수립하고 이를 기반으로 구축하여 회사가 소프트웨어를 배포하고 사용하는 방식을 최적화할 수 있습니다. 이는 비용 절감, 유연성 향상, 벤더 종속성으로부터 해방을 가져올 수 있습니다.

투명한 의사 결정으로 프로세스, 신뢰, 정렬 구축

성공적인 오픈 소스 메인테이너는 기본적으로 의사 결정을 문서화합니다. 각 대화에는 고유한 URL과 맥락을 파악할 수 있는 주석 기록이 있어 시간대의 차이가 덜 중요해지고, 개발자는 흐름 끊길 일 없이 비동기적으로 작업을 이어갈 수 있습니다.

프로젝트를 공개하면 조직에 새로운 수준의 투명성이 생깁니다. 코드뿐만 아니라 그 뒤의 프로세스와 의사 결정도 가시화됩니다. 잘 문서화된 대화는 분산된 팀의 개발자가 빠르게 상황을 파악하고 빌드를 시작할 수 있도록 도움을 줍니다. 또한, 공개된 환경에서 작업이 이루어지면 프로덕트 매니저, 디자이너, 보안 팀 등도 협업에 참여할 수 있습니다.

참여의 중요성

오픈 소스 프로젝트의 성공은 참여에 달려 있습니다. 기술을 향상시키거나 멘토를 찾거나 평판을 쌓기 위함 등 기여하는 데는 여러 가지 기본적인 이유가 있지만, 프로젝트 메인테이너 역시 참여를 환영하고 권장하는 커뮤니티 문화를 조성해야 합니다.

기업 내에서 각 개발자 개인은 자신의 관심사를 추구하고, 공평한 경쟁의 장 위에서 아이디어를 공유하며, 동료로부터 더 쉽게 배울 수 있습니다. 그러나 이너 소스는 문화적인 변화도 필요로 합니다. 팀의 문화는 지식 공유를 장려하고 조직 전체에 걸쳐 기여를 환영하는 분위기여야 합니다.

프로젝트의 프로세스를 강화하는 핵심 개발 팀

오픈 소스 프로젝트에는 수천 명의 기여자와 커뮤니티 구성원이 참여할 수 있지만, 프로젝트의 전반적인 방향을 책임지는 팀은 보통 훨씬 소규모입니다. 이로 인해 의사 결정이 신속해지고, 누군가 항상 책임지고 담당할 수 있도록 합니다.

이너 소스 프로젝트에서는 소수의 참여자 그룹에게 제어권을 분산시키면 승인과 검토가 더욱 효과적으로 이루어지는 경우가 많습니다. 의사결정권자로 이루어진 소규모의 교차기능적 팀을 구성하는 것도 팀이 품질 기준을 준수하고 경영진의 지원을 받는 데 도움을 줄 수 있습니다.

방화벽 뒤에 있는 오픈 소스 커뮤니티

이너 소스는 다양한 방식으로 설명되어 왔으며, 이미 대규모 오픈 소스 커뮤니티와 협력하는 조직의 개발자들은 이너 소스라는 용어를 전혀 사용하지 않을 수도 있습니다. 대신 그들은 이너 소스에 대해 그저 오픈 소스 방법론을 방화벽 뒤에서 소프트웨어 개발에 적용하는 방식이라고 생각합니다.

이너 소스는 보안이나 개인 정보 보호가 약화된다는 것을 의미하지 않습니다. 반드시 기업 소유의 소프트웨어를 공개적으로 공유하거나 외부인을 초대하여 소스 코드를 열람하거나 이너 소스 프로젝트에 접근하도록 할 필요는 없습니다. 기업은 비공개 코드가 사내 환경에서 안전하게 유지되고, 적절한 권한을 가진 개발자만이 기여할 수 있다는 점을 통해 안심할 수 있습니다.

이너소스 관행 채택은 조직 내에서 오픈 소스 커뮤니티를 시작하는 것과 같습니다. 오픈 소스와 마찬가지로 투명한 협업은 커뮤니티의 공동 지식과 기술을 동원하여 더 나은 소프트웨어를 만듭니다. 이와 대조적으로 이너소스 커뮤니티에는 단일 엔터프라이즈 내의 사람과 도구의 지식, 기술, 능력이 포함됩니다.

기업에서 채택하는 이유

기업에서 소프트웨어 및 데이터로 제품과 서비스를 발전시키고 차별화하거나 소프트웨어 및 데이터가 해당 제품 또는 서비스임을 인식함에 따라 기존의 개발 방법과 도구화가 제대로 작동하지 않는다는 사실을 빠르게 깨닫게 됩니다. 요구 사항을 수집하고, 회의를 진행하며, 사일로에서 개발하는 느리고 체계적인 관행은 오늘날의 기술 속도는 물론 고객의 요구 속도에도 맞지 않습니다. 그렇다면 기업은 어떻게 따라갈 수 있나요?

이너소스는 팀에서 소프트웨어를 더 빠르게 구축하고 더 효율적으로 협력할 수 있도록 지원하여 더 높은 품질의 개발과 더 나은 문서화를 가능하게 합니다. 또한 다음을 통해 기업의 효율성을 높이도록 지원할 수 있습니다.

• 광범위한 코드를 쉽게 찾고 재사용하여 리소스 낭비와 중복 방지

• 회사 규모와 상관없이 빠른 개발 추진

• 팀과 부서 내부 및 팀과 비즈니스 라인 전반에 걸쳐 조직 전반의 사일로를 줄이고 협업 간소화

• 엔지니어와 경영진 및 관심 있는 모든 사용자 간의 명확성 향상

• 오픈 소스 참여의 전조인 개방 문화 조성

• 필요한 곳이면 어디든 지원하는 팀원들이 느끼는 자부심, 성장, 직업 만족도 강화

PayPal, Bloomberg, Walmart와 같은 선두 기업에서는 이너소스를 사용하여 팀과 고객을 위한 소프트웨어를 구축합니다. 이는 고유한 경쟁 우위를 제공하고 인정된 모범 사례를 채택하여 관련성을 유지하도록 지원합니다.

이너소스 프로젝트의 해부학

개인, 팀, 리소스를 올바르게 조합하면 프로젝트의 성공을 보장할 수 있습니다. 대부분의 오픈 소스 프로젝트는 유사한 조직 구조를 따르며, 이는 기업의 이너소스 프로젝트를 관리하기 위해 교차기능팀을 구성할 때 고려할 수 있습니다. 일반적인 오픈 소스 프로젝트에는 다음과 같은 유형의 사람들이 있습니다.

• 메인테이너: 프로젝트의 비전을 추진하고 조직적 측면을 관리할 책임이 있는 기여자입니다. 반드시 코드의 원래 소유자이거나 작성자일 필요는 없습니다.

• 기여자: 프로젝트에 기여한 모든 사람입니다.

• 커뮤니티 구성원: 프로젝트를 사용하는 사람입니다. 대화에 적극적으로 참여하거나 프로젝트 방향에 대한 의견을 표현할 수도 있습니다.

더 큰 프로젝트에는도구화, 분류, 커뮤니티 조정과 같은 다양한 작업에 초점을 맞춘 소위원회 또는 워킹그룹이 있을 수도 있습니다.

이너소스 프로젝트도 이와 비슷한 구조를 따를 가능성이 높습니다. 많은 엔지니어링 조직에서는 개발자를 애플리케이션 엔지니어링, 플랫폼 엔지니어링, 웹 개발과 같은 팀으로 분류합니다. 이러한 방식으로 조직을 구성하면 적격한 인력이 제외되는 사각 지대가 생길 수 있습니다. 조직 전반에서 팀이 지원하는 핵심 의사 결정 그룹을 구성하면 주어진 문제를 더 빠르게 해결하는 데 필요한 전문 지식을 통합할 수 있습니다.

엔터프라이즈 내에서 “기여자”는 기업 전반의 개발자이며, “메인테이너”는 프로젝트의 리더이자 주요 의사 결정자입니다.

• 메인테이너: 프로젝트 비전을 추진하고 일상적인 기여를 관리할 책임이 있는 회사 내 개발자, 제품 관리자 및 기타 주요 의사 결정자입니다.

• 기여자: 소프트웨어 발전을 지원하는 회사 내 개발자, 데이터 과학자, 제품 관리자, 마케터 및 기타 역할입니다. 기여자는 직접 프로젝트 팀의 속하지 않아도 되지만 코드 기여, 버그 수정 제출 등을 통해 소프트웨어 구축을 지원합니다.

트레이드 도구

GitHub에서 오픈 소스 개발을 주도하는 몇 가지 도구는 다음과 같습니다. 이는 모든 이너소스 프로젝트의 핵심 구성 요소가 됩니다.

• GitHub Issues: GitHub Issues는 개발자가 주제를 제기하고 대화를 시작하는 곳입니다. 버그를 발견하거나 새로운 기능에 대한 아이디어가 있는 경우 GitHub Issues를 시작하는 것이 가장 좋으며, 여기에 액세스할 수 있는 모든 사람은 GitHub Discussions에 참여할 수 있습니다. GitHub Issues에 대해 자세히 알아보세요.

• Pull requests: Pull requests는 개발자가 프로젝트에 적용하고자 하는 변경 사항에 대한 실시간 대화입니다. 사람들이 솔루션 작업을 시작하고 진행 중인 변경 사항을 검토하는 곳입니다. Pull requests에 대해 자세히 알아보세요.

• 동기식 채팅 채널: 팀은 때때로 빠른 결정을 내려야 합니다. Slack과 같은 동기식 채팅 채널은 GitHub의 토론 및 댓글을 보완하며 실시간 문제 해결에 적합합니다.

프로젝트 관리부터 지속적 통합 및 배포 서비스에 이르기까지 팀에서 더 효율적으로 작업할 수 있도록 GitHub에서 사용할 수 있는 수백 개의 도구가 있습니다. 모두 확인하세요.

우리 조직에 적합한가?

이너소싱은 기술적 변화뿐만 아니라 문화적 변화이기도 하므로, 일부 조직에게는 큰 도전이 될 수 있다는 점을 과소평가하지 않는 것이 중요합니다. 오픈 소스 프로젝트와 마찬가지로 이너 소스 프로젝트는 발견 가능성과 재사용성을 당연하게 중시하는 환경에서 성장할 수 있습니다. 또한 비슷한 관심사나 전문성을 공유하는 소규모의 교차기능적 커뮤니티가 조직 내에 있는 것도 도움이 됩니다.

일반적으로 이너소싱을 시작할지 여부를 결정하고 계획 프로세스를 시작하는 데 도움이 되는 몇 가지 요소는 다음과 같습니다.

• 회사의 프로젝트에 현실적이면서도 팀 전체가 공유하는 비전이 있어야 합니다. 프로젝트에는 해결해야 할 문제와 기회가 명확하게 정의되어 있어야 합니다.

• 이너 소스를 계획하는 프로젝트의 핵심 참가자(이니시에이터, 카탈리스트, 에반젤리스트)가 협업 경험이 있어야 합니다.

• 새로운 '기여자'와 다른 참가자를 프로세스에 온보딩하고 적응시키기 위한 계획이 있어야 합니다.

• 팀에 개방적으로 소통할 수 있고 일관성 있게 구축할 수 있는 도구 및 프로세스가 있어야 합니다.

• 명확히 정의된 공동의 목표를 가진 조직 내 사람들로 구성된 그룹으로 시작할 수 있어야 합니다.

이너 소스는 개인이 자기 자신과 자신의 책임을 바라보는 방식에 변화를 줄 수 있기 때문에 조직 구조를 중요하게 고려해야 합니다. 효과적인 이너 소스 프로세스는 격식에 얽매이지 않고, 멘토가 있으며, 자율적으로 선택할 수 있어야 하고, 참가자들을 지원해야 합니다.

이너 소스 실천을 효과적으로 도입하려면 기여자들이 사일로와 다른 조직 부서를 쉽게 넘나들며 작업할 수 있어야 합니다. 조직이 지식 공유 이니셔티브를 지원하는 정도가 조직이 이너 소스에 얼마나 잘 적응할 수 있을지를 보여주는 좋은 지표가 됩니다.

실제 사례를 보려면 Booz Allen Hamilton의 이너 소스 문화 구축을 참조하세요.

다음은 팀이 이너소싱을 받아들이는 데 얼마나 준비되어 있는지 평가할 수 있는 몇 가지 질문입니다. 이 중 많은 항목에 '예'라고 답했다면 회사에서 이너 소스 프로그램을 시작할 준비가 된 것입니다.

• 우리 조직은 개방적이고 투명한 문화를 가지고 있는가?

• 우리는 단일 오픈 플랫폼에서 소프트웨어를 개발하는가?

• 우리의 엔지니어링 이니셔티브는 리더십 팀의 자원을 충분히 지원받고 있는가?

• 우리 조직의 개발자들은 자신의 팀을 넘어 다른 프로젝트에 기여할 수 있는 자율성을 가지고 있는가?

• 우리 회사는 오픈 소스 커뮤니티에 참여하고 있는가?

• 우리 엔지니어링 팀은 지속적 통합 도구를 사용하고 있는가?

• 우리 회사에는 팀 간 협력하는 교차기능적 커뮤니티가 이미 있는가?

• 만약 있다면, 그 커뮤니티에는 리더십이 이미 형성되어 있는가?

모든 회사의 상황은 다르므로, 이 질문들 중 어느 것도 이너 소스를 도입하기 위한 필수 조건으로 생각해서는 안 됩니다. 일반적으로 다른 팀의 작업을 보고, 기여하며, 피드백을 줄 수 있을 만큼 조직 내 팀들 간에 충분한 신뢰가 있다고 느껴질 때 이너 소스 실천을 시작해야 합니다. 많은 회사들은 이너 소스를 파일럿 프로그램으로 시작한 후 회사에 가장 적합한 방식을 결정합니다.

시작할 준비가 되었나요?

기업은 소규모로 시작하여 이너소스 프로그램을 시작하는 경우가 많습니다. 파일럿 프로젝트는 팀에서 이너소스를 더 광범위하게 적용하기 전에 더 개방적인 프로세스를 실험하고, 코드에 대한 액세스를 민주화하며, 모범 사례를 문서화할 수 있도록 지원합니다. 작은 성공을 통해 내부 개발자 커뮤니티에 코드를 최대한 활용하고 더 나은 소프트웨어를 더 빠르게 출시하는 방법을 보여줄 수 있습니다.

소프트웨어를 구축하는 방식은 10년 전과 근본적으로 다릅니다. 이너소스는 프로세스를 현대화하고, 개발 속도를 높이며, 조직의 장벽을 극복하고, 소프트웨어 ��질을 개선하는 한 가지 접근 방식입니다. 세계 최대 오픈 소스 커뮤니티인 GitHub는 오픈 소스 모범 사례가 시작되는 곳입니다. 함께 팀 구축 방식을 바꿀 수 있습니다.