InnerSource는 거짓말이다 - 일반적인 오해에 대한 반박
YouTube에서 “InnerSource"를 검색하면, 가장 먼저 만나게 될 결과 중 하나는 “InnerSource는 거짓말이다"라고 주장하는 동영상일 것입니다.
(링크: https://youtube.com/shorts/53jEP3mPP3E)
이러한 관점은 많은 사람들이 InnerSource에 대해 처음 배울 때 빠지는 전형적인 함정을 나타냅니다.
저는 이 동영상을 사례 연구로 활용하여 어떤 종류의 오해를 불러일으키는 결론을 촉진하는지 설명하고자 합니다. 이는 제가 과거에도 저질렀던 실수이며, 이 분야를 깊이 탐구하지 않은 많은 사람들이 쉽게 빠질 수 있는 함정입니다. 그래서 저는 자기 성찰과 함께 이를 살펴보고, 이러한 함정을 풀어내어 다른 사람들이 올바른 길을 찾을 수 있도록 돕고자 합니다.
첫 번째 오해: “다른 사람들이 기여할 수 있도록 React를 사용하라” #
먼저 이 사례의 논증을 분석해보겠습니다. 이 동영상은 내부 애플리케이션에 React를 사용하는 것을 제안하며 “React를 사용하라 다른 사람들이 기여할 수 있도록"이라고 말합니다. 이런 종류의 논리는 실제 InnerSource 논의에서는 거의 들어볼 수 없습니다.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
이 논증은 세 가지 핵심 문제로 분석할 수 있습니다:
- InnerSource가 실제로 무엇을 의미하는지에 대한 근본적인 오해
- InnerSource 적용을 위한 잘못된 도메인 선택
- 개인 대 팀 관점의 혼동
InnerSource가 실제로 의미하는 것 #
InnerSource는 회사 내에서 오픈 소스 원칙을 실천하는 것입니다. 이는 단순히 “기여하는 것” 또는 “기여를 받는 것"이 아닙니다.
오픈 소스와 상호작용하는 대부분의 사람들은 단순히 “사용자"입니다. 일부는 단순한 소비자이고, 다른 일부는 버그 리포트를 제출하며, 실제로 풀 리퀘스트를 제출하는 사람은 극소수에 불과합니다. InnerSource는 오픈 소스 학습을 내부적으로 적용하여 개방적이고, 광범위하게 접근 가능하며, 투명한 의사결정과 소유권과 멘토십을 통한 신뢰에 기반한 팀 관계를 가진 조직을 만듭니다. 이는 투명성과 협업의 문화를 창조합니다.
이것이 “오픈 소스를 내부적으로 실천하는 것"의 의미입니다 - 이는 단순히 “풀 리퀘스트를 받는 것"이 아닙니다. 풀 리퀘스트는 이러한 문화의 한 결과일 뿐이며, 주요 목표가 아닙니다.
InnerSource 적용에 덜 최적화된 도메인 #
두 번째 문제는 이 논증이 InnerSource와 오픈 소스가 특별한 도전에 직면하는 도메인에서 전개된다는 것입니다.
“풀 리퀘스트를 받고” 싶거나 “많은 사람들이 코드를 사용하여 품질을 개선하도록” 하고 싶다면, 이는 제품의 특성에 의해 제한될 수 있습니다. 최종 사용자 애플리케이션보다는 “높은 의존성을 가진 컴포넌트"나 플랫폼 수준의 도구를 공유하는 것이 더 많은 가치를 창출할 것이라는 것은 명백합니다. 스트림 정렬 팀들도 유익할 때 오픈 소스 관행을 채택해야 하지만, 협업 역학은 상당히 다릅니다.
엔터프라이즈 회사들과 일한 제 경험에서, 최종 사용자가 “비엔지니어"인 프로젝트 수준의 이니셔티브에 InnerSource를 사용하는 것은 독특한 도전을 제시합니다. 왜일까요? 궁극적으로 이러한 제품들은 개발 기술과 개발 팀과의 직접적인 소통 채널이 부족할 수 있는 “최종 사용자” 또는 “비즈니스 사용자"의 요구를 충족해야 하기 때문입니다. 이는 복잡하고 개별화된 요구사항과 더 긴 소통 리드 타임을 만듭니다.
InnerSource 구현은 공유 라이브러리, 플랫폼 컴포넌트, 개발 도구, 인프라 코드에 적용될 때 상대적으로 잘 작동하는 경향이 있습니다. 이는 “사용자"가 주로 협업적 개발 관행에 의미 있게 기여하고 혜택을 받을 수 있는 다른 개발자들인 영역입니다.
사용자 대면 애플리케이션에 InnerSource 관행을 적용하는 것은 투명성과 개선된 이슈 추적과 같은 가치 있는 혜택을 가져올 수 있습니다(이것만으로도 가치가 있습니다).
개인 대 팀 관점 #
세 번째 문제는 “당신"이 개인을 가리키는지 팀을 가리키는지에 관한 것입니다.
InnerSource가 반드시 회사 내에서 누군가가 “당신의 개인 프로젝트"에 기여하기를 기다리는 것은 아니라는 점을 주목하는 것이 중요합니다. InnerSource가 적용될 때, 빅테크 기업들처럼 20% 시간 동안 개발된 프로젝트에 사람들이 기여하는 경우가 있을 수 있지만, 그것이 반드시 주류 접근법은 아닙니다.
InnerSource는 주로 비용 절감, 바퀴의 재발명 방지, 시너지 창출, 품질 보증, 계층적 의사결정의 소통 오버헤드 제거를 통해 ROI를 생성하기 때문에 도입되고 유지됩니다. 이는 일반적으로 공유 내부 라이브러리, 독점적 경쟁 우위 컴포넌트, 또는 엔터프라이즈 내에서 틈새이지만 높은 의존성을 가진 것들을 포함합니다. 그리고 이러한 “비즈니스 혜택"은 일반적으로 대부분의 경우 “팀 운영"으로 다시 흘러갑니다. 궁극적으로, 이는 모두 팀과 조직의 ROI에 관한 것입니다. 팀에 대해 생각하지 않으면, 누군가가 프로젝트에 기여하는 것을 막을 것입니다. 단기적이든 장기적이든 ROI를 정당화해야 합니다.
InnerSource의 독특한 점은 근본적으로 팀 간 협업에 관한 것이라는 점입니다. 이것이 대부분의 구현이 궁극적으로 도달하는 지점입니다. 이는 개인들이 편리한 개인 프로젝트에 무작위로 기여하는 것이 반드시 아닙니다. 일반적으로 호스트 팀과 게스트 팀 관계를 통해 구현되며, 게스트 팀이 호스트 팀이 유지하는 부분과 함께 진행합니다. 대부분의 엔터프라이즈는 정의된 역할과 책임을 가진 직원들을 보유하고 있으며, 협업은 이러한 구조 내에서 발생하는 경향이 있습니다.
따라서 InnerSource는 플랫폼 팀과 스트림 정렬 팀(게스트 팀과 호스트 팀) 간의 관계가 확립될 때 특히 효과적입니다. 스트림 정렬 팀 간의 적극적인 공동 창조나 개인들은 자연스럽게 성공할 가능성이 더 불확실합니다.
작동할 가능성이 낮은 시나리오를 바탕으로 InnerSource 전체를 비판하는 것은 논리적으로 말이 되지 않습니다.
두 번째 오해: “실제 회사에서는 절대 일어나지 않는다” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
실제로, 이것은 일어나고 있습니다. 사례 연구가 이를 증명합니다. 끝.
세 번째 오해: “InnerSource 프로젝트의 99.69%는 실패할 것이다” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
이는 “InnerSource"를 어떻게 정의하느냐에 따라 맞을 수도 있습니다. 앞서 언급했듯이, InnerSource는 “PR 기여를 받는 것"이 아닙니다.
하지만 고려해야 할 세 가지 중요한 점이 있습니다:
- InnerSource는 특히 전략적 컴포넌트에 적용됩니다 - 모든 컴포넌트에 필요한 것은 아닙니다
- 혜택은 적극적인 기여를 넘어 확장됩니다
- 오픈 소스도 동일한 “실패율” 문제를 가지고 있습니다
InnerSource는 기업 전략입니다 #
사람들이 InnerSource에 대해 생각할 때, 때때로 “엔터프라이즈 내의 모든 코드 공유” 또는 “모든 사람이 모든 것에 기여"와 같은 급진적인 아이디어를 상상합니다. 회사 내에 수백 개의 공유 저장소가 있고 모든 사람이 적극적으로 기여를 교환하는 것을 상상할 수도 있습니다. 오픈 소스가 회사의 전략인 것처럼, InnerSource도 우선순위를 가진 기업 전략입니다. 회사들은 “공유할 가치가 있는 것"을 먼저 공유합니다.
따라서 팀 간에 코드가 적극적으로 흐르고 활발한 팀 간 협업이 일어나는 코드베이스의 실제 수는 상대적으로 적습니다. 이는 실제로 한 자릿수 퍼센트일 수 있습니다. 하지만 적극적인 팀 간 협업 없이도, 많은 프로젝트가 개방적이고 투명한 것으로부터 혜택을 받을 수 있습니다. 이런 의미의 InnerSource에서, 엔터프라이즈는 종종 훨씬 더 많은 경우에서 가치를 공유할 수 있습니다.
InnerSource는 개인 기여를 포함하지만, 주로 팀 간 협업에 초점을 맞춥니다. 따라서 InnerSource를 통해 공유되는 것은 엔터프라이즈 내에서 상대적으로 틈새이거나, 특정 요구를 위한 포크된 Linux 배포판과 같은 목적별 항목인 경향이 있습니다. 또는 GitHub이 모든 직원에게 Ruby on Rails 코드를 공유하는 것처럼 단순히 오픈 소스와 같은 개발 문화일 수도 있습니다.
적극적으로 협업하고 공통 요구사항으로 유지되는 InnerSource에 이 퍼센트 논의를 조건화하면, 퍼센트는 실제로 상대적으로 낮을 수 있습니다. 하지만 게스트 팀과 플랫폼/호스트 팀 간의 문서 풀 리퀘스트나 사소한 구성 변경(작은 패치 전송)과 같은 작은 협업은 상대적으로 자주 발생합니다. 이러한 마이크로 협업과 중복 노력을 방지하는 투명성 혜택을 포함하면, 이러한 수치는 상당히 증가합니다.
오픈 소스도 동일한 “문제"를 가지고 있습니다 #
반면에, 그렇게 정의한다면, 오픈 소스도 “거짓말"이 될 것입니다. 왜냐하면 “오픈 소스 프로젝트의 99.69%는 실패할 것"이기 때문입니다. 오픈 소스로 게시된 대부분의 코드는 기여를 받지 못합니다. 하지만 그 때문에 아무도 “오픈 소스는 거짓말이다"라고 말하지 않습니다. 사람들은 기여를 받는 것 이상의 혜택이 있기 때문에 오픈 소스를 추구합니다.
다시 말해, “기여받는 것"이 InnerSource의 유일한 가치가 아닙니다. 그리고 오픈 소스 가치에도 동일하게 적용됩니다.
투명성의 진정한 혜택 #
내부 코드를 숨기기보다는 개방적으로 유지하는 것 - GitHub에서 수익 팀의 아키텍트나 솔루션 엔지니어가 소스 코드를 검토하여 관련 정보를 찾을 수 있고, 고객 요청과 매우 가까운 세부 사항을 찾을 수 있어 더 원활한 지원 대화를 촉진하고, 이슈에서 더 정확한 정보를 추출할 수 있습니다. 저는 도쿄에 살고 있는데, 때때로 변경 사항과 그 배경에 대한 구현 질문을 하기 위해 SF 기반 제품 팀이 깨어나기를 기다리기보다는 Ruby 코드를 보고 구현을 확인하거나 이슈로 가서 변경의 배경을 확인하는 것이 더 빠릅니다.
git blame 명령을 사용하여 코드의 “실제” 이해관계자를 식별하고 결정의 배경에 대해 질문할 수 있습니다.
말할 필요도 없이, 다른 개발 팀에도 동일하게 적용됩니다. 의존성을 만들 수 있는 컴포넌트에 대한 정보를 쉽게 사용할 수 있다는 것은 명백히 소통 오버헤드를 줄입니다.
InnerSource는 오픈 소스 원칙을 내부적으로 실천하는 것입니다. InnerSource는 단순히 풀 리퀘스트를 주고받는 것이 아닙니다 - 투명성을 보장하고 오픈 소스 스타일 협업을 통해 혜택을 얻는 것입니다. 이러한 혜택은 적극적으로 유지되는 저장소의 몇 퍼센트를 훨씬 넘어 더 광범위한 문화적 구현 혜택으로 확장됩니다.
네 번째 오해: “떠날 때 다시 연락받을 것이다” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
리소스가 때때로 유지되지 않을 수 있지만, 이는 InnerSource 자체에 대한 적절한 비판이 아닙니다 - 이는 InnerSource를 제대로 구현하지 못한 것에 대한 비판입니다. 이는 InnerSource에 대한 비판이 아니라, 아무도 코드를 유지하지 않는 유지보수 문화의 부족에 대한 비판입니다. 이는 InnerSource를 제대로 구현하지 못하거나 전혀 고려하지 않은 결과입니다 - 소유권 부족의 결과입니다.
DevOps 유추 #
이는 InnerSource를 하지 못한 것에 대한 비판이지, InnerSource 자체에 대한 비판이 아닙니다. 때때로 이것이 논리를 혼동시킵니다. 이를 DevOps 용어로 표현하면: “회사들이 결국 몇 달의 느린 검토 주기나 감사를 채택하거나, 릴리스 결정을 위한 프로세스를 추가하여 릴리스가 분기별 또는 연 2회만 이루어진다. 따라서 빠른 릴리스를 가능하게 한다고 주장하는 DevOps는 좋지 않다"라고 말하는 것과 같습니다. 그것은 DevOps 방법론이 나쁘기 때문이 아니라, 단순히 “DevOps를 구현할 수 없었던 경우들이 있었기” 때문입니다.
비즈니스 프로세스를 깨는 것은 극도로 어렵고, 많은 회사들이 DevOps는 불가능하다고 말했습니다. 하지만 사람들이 불가능하다고 생각했을 때도, 문화를 바꾸기 위해 열심히 노력하고 DevOps를 달성한 용감한 개척자들이 있었습니다. InnerSource에서도 동일한 일이 일어날 수 있습니다.
다섯 번째 오해: “모든 것을 100% 소유해야 한다” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource는 코드 소유권을 포기하는 것을 의미한다"는 것은 틀렸습니다. InnerSource는 실제로 팀이 코드를 소유하도록 요구합니다. 이는 일반적인 실수입니다. 이는 유지보수 책임을 포기하고 “오픈 소스로 만들자"고 말하는 사람들과 같습니다. 그것은 작동하지 않습니다.
개인 대 팀 소유권 - InnerSource는 강한 코드 소유권인가? #
먼저, 이 “당신"은 개인인가 복수인가? 조직에서 개인이 CODEOWNERS 파일에 나열될 수 있지만, 팀이 궁극적으로 코드에 대한 책임을 집니다. 문맥상, 이는 강한 코드 소유권에 대해 이야기하는 것 같습니다. 하지만 조직적 유지보수를 고려할 때 이는 좋지 않습니다. 직원들이 그만둘 수 있기 때문입니다.
InnerSource는 강한 코드 소유권이 아닙니다. 최소한 여러 사람이 책임을 공유해야 합니다. 그렇긴 하지만, 강한 코드 소유권이 단기적으로 나타날 수 있고, 프로젝트의 초기 단계에서 강한 개인 의지가 자연스럽게 그러한 배치로 이어질 수 있다는 것을 인정하지만, 장기적 성공을 달성하고 싶다면, 조직이 집단적으로 유지보수를 처리할 수 있도록 권한을 위임하는 것이 필요합니다.
팀 소유권의 유형 - InnerSource는 집단 코드 소유권인가? #
이런 종류의 논증은 때때로 집단 소유권을 언급할 수 있습니다. 이 경우, 논증은 또한 InnerSource가 집단 소유권을 의미한다고 제안하는 것 같지만, 그것은 실제로 다릅니다. InnerSource는 집단 코드 소유권이 아닙니다 InnerSource는 호스트 팀이 궁극적으로 유지보수를 처리하는 것을 포함합니다. InnerSource는 약한 코드 소유권입니다. 따라서 유지보수 책임은 100% 맞지만, “100% 소유해야 하고 InnerSource는 다르다"고 말하는 것은 완전히 비논리적입니다. 이는 실제로 잘못된 의견입니다.
Martin Fowler가 코드 소유권에 대해 유명하게 논증했듯이, 모든 사람이 코드를 100% 소유하는 것(집단 소유권)은 때때로 아무도 책임을 지지 않는 상황을 만듭니다. 그것은 매우 문제가 됩니다 - 책임이 불분명해지고 프로젝트가 궁극적으로 실패합니다.
약한 코드 소유권 모델 #
약한 코드 소유권에서, 유지보수자가 존재하고, 호스트 팀이 프로젝트를 유지하며, 특정 부분은 다른 팀의 신뢰받는 커미터/유지보수자를 데려올 수 있습니다. 누군가는 기여할 수 있고, 누군가는 유지할 수 있지만, “당신” 또는 “당신의 팀"이 100%가 아닙니다 - 꽤 다를 수 있습니다. 예를 들어, 코드의 98%는 당신의 팀이 소유하고, 2%는 다른 팀이 소유할 수 있습니다.
이 경우, 조직에서 개인이 코드 소유자로 할당되더라도, 팀이 궁극적으로 코드에 대한 책임을 진다는 것을 기억하세요. 팀이 소유해야 하며, 이 중요한 점을 잊지 마세요.
여섯 번째 오해: “누군가가 7000줄을 당신에게 던질 것이다” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
7000줄 풀 리퀘스트가 갑자기 나타나는 것 자체가 InnerSource 문화 도입의 실패입니다 - 이는 InnerSource를 함으로써 일어나는 것이 아닙니다. 이 경우는 InnerSource를 도입하면 그러한 협업이 일어날 것을 걱정할 수 있지만, 그것은 완전히 틀렸습니다.
진짜 문제 #
이 논증은 InnerSource 문화와 협업 관행을 구현하지 못한 것을 나타내며, InnerSource 자체가 아닙니다. 7000줄 구현은 매우 제한적인 경우입니다. 이는 7000줄이 어떤 알림도 없이 갑자기 풀 리퀘스트로 제출되는 협업 문화의 실패를 나타냅니다 - 조직은 InnerSource 이전의 이러한 근본적인 문화 문제를 해결해야 합니다.
이를 방지하고 싶다면, 해결책이 있습니다. 조직 내에서 InnerSource 문화를 육성하세요:)
현실: InnerSource가 실제로 무엇인가 #
InnerSource는 문화적 구현입니다 - 오픈 소스 협업 관행을 사용하여 오픈 소스가 협업을 통해 받는 다양한 혜택을 누리는 것입니다. InnerSource의 궁극적인 목적은 단순히 기여(풀 리퀘스트)를 받는 것이 아니라, 이슈를 통한 기능 요청, 지원 조정, 그리고 다양한 다른 혜택, 그리고 의사결정의 투명성과 실용적인 문화 촉진을 포함합니다.
따라서 저는 “풀 리퀘스트를 받기 위해 InnerSource 모범 사례를 구현하는 것은 거짓말이다"라는 주장을 단호히 거부합니다.
기여 현실 이해하기 #
“아무도 기여하지 않을 것이다”
오픈 소스 협업에서, 기여자들은 실제로 극소수입니다. 1000명의 사용자 중에서, 아마도 대다수는 단순한 사용자이고, 20명 정도가 이슈나 기능 요청을 제출하고, 5명이 풀 리퀘스트를 보내고, 아마도 1명만이 유지보수자가 됩니다.
다시 말해, InnerSource 모범 사례가 1000명 모두를 기여자로 만들지는 않을 것입니다. InnerSource는 그러한 협업을 유도하는 데 도움이 되지만, 궁극적으로는 엔터프라이즈 사일로를 깨뜨리고, 전통적인 조직적 제약에 의해 방해받는 협업을 개선하고, 정보 사일로로 인한 리드 타임을 줄이고, 오픈 소스 관행을 사용하여 조직 자원 할당을 최적화하는 것을 목표로 합니다.
결론 #
이 사례의 논증들이 일부 실제 도전을 다루고 있지만, 이들은 많은 사람들이 InnerSource에 대해 처음 배울 때 마주치는 일반적인 오해에 기반하고 있습니다. 이들은 커뮤니티에서 잘 알려진 함정이며, 이 분야를 더 깊이 탐구하지 않고서는 누군가가 이러한 결론에 도달할 수 있다는 것은 이해할 만합니다.
핵심 통찰은 InnerSource가 오픈 소스 관행을 경직된 프레임워크에 강제로 밀어넣는 것이 아니라는 점입니다. 대신, 이는 근본적인 질문으로 돌아가는 것입니다: 우리가 오픈 소스에서 배울 수 있는 것은 무엇인가? 오픈 소스를 더 넓은 렌즈로 검토함으로써, 우리는 이러한 원칙들을 내부적으로 더 잘 적응시킬 수 있습니다.
당신은 이 대화에 참여하고 새로운 관점을 가져올 수 있습니다. 이 논의를 발전시키고 싶든, 더 구체적인 구현 세부사항을 탐구하고 싶든, 또는 이러한 논증들에 완전히 도전하고 싶든 - 모든 접근법이 환영받습니다. 가장 중요한 것은 오픈 소스 학습과 그것이 내부 조직 맥락으로 어떻게 번역되는지에 대한 그 넓은 관점을 유지하는 것입니다.
InnerSource에 대한 포괄적인 정보를 원한다면, InnerSource Commons Foundation을 확인해보시기 바랍니다. 그들은 다양한 관점과 오픈 소스 원칙이 조직 내에서 어떻게 가치를 창출할 수 있는지에 대한 지속적인 대화를 환영합니다.
