InnerSource를 정의한다는 것의 의미

질문 #

사람들은 자주 저에게 InnerSource의 정의가 무엇인지 묻습니다. 그렇다면 InnerSource란 무엇일까요? InnerSource와 그것이 저에게 의미하는 바에 대한 몇 가지 생각을 공유하고 싶습니다.

처음부터 명확히 하겠습니다: 이것들은 제 개인적인 의견이며, 공식적인 입장이 아닙니다. 현재 InnerSource Commons Foundation의 회장으로 재직하고 있지만, InnerSource는 제가 깊이 존경하는 많은 선구자들에 의해 형성되었습니다. 그들의 기여가 오늘날의 InnerSource를 만들어냈습니다.

InnerSource의 기초는 기업 관행, 학술 연구, 그리고 물론 오픈소스 자체의 진화가 서로 얽혀서 나온 것입니다. 이러한 풍부한 태피스트리를 고려할 때, 제가 개인적으로 InnerSource를 정의한다고 주장하는 것은 주제넘은 일이 될 것입니다. 현재 회장으로 재직한다고 해서 그 정의를 혼자서 만들 권한이나 지혜가 있다는 뜻은 아닙니다.

하나의 확정적인 답을 제공하기보다는, 이 질문에 대한 다양한 관점을 공유하고 싶습니다. 여러분이 자신만의 정의를 발견하고 InnerSource가 여러분의 상황에서 무엇을 의미하는지 이해하는 데 도움이 될 수 있는 관점들을 제공하겠습니다.


InnerSource로 가는 두 가지 경로 #

우리는 흥미로운 변곡점에 있습니다. 제가 의미하는 바를 더 명확히 설명해보겠습니다. 오늘날 InnerSource에 접근하는 사람들에게는 본질적으로 두 가지 유형이 있습니다:

첫 번째 그룹은 오픈소스를 실천해왔고, 그 협업 방법이 강력하다는 것을 발견하여 이러한 원칙을 내부적으로 자연스럽게 적용한 사람들로 구성됩니다. 그들에게 InnerSource는 단순히 이미 하고 있던 일에 주어진 이름이었습니다—오픈소스 협업의 우수성을 조직 내부로 가져오는 것 말입니다.

두 번째 그룹은 InnerSource를 명명된 방법론으로 발견했습니다. 그들은 광범위한 오픈소스 배경을 가지고 있지 않을 수도 있지만, 조직 방법론으로서의 InnerSource가 변혁을 위한 엄청난 가치를 제공한다는 것을 인식합니다. 그들은 오픈소스 실무자였기 때문이 아니라 InnerSource 자체가 조직적 이익을 약속하기 때문에 InnerSource를 채택하고 있습니다.

이러한 이중성은 우리 커뮤니티에 매혹적인 기회를 만들어냅니다. 첫 번째 그룹은 조직 내에서 InnerSource를 구현하는 것이 무엇을 의미하는지, 그리고 InnerSource와 오픈소스의 가치와 문화를 직관적으로 이해합니다. 따라서 그들은 InnerSource가 어떻게 정의되어야 하는지 숙고하고 오픈소스의 틀 안에서 그것에 대해 생각할 수 있습니다. 반면에 두 번째 그룹은 반드시 오픈소스와 관련이 있는 것은 아니므로, 그것이 실제로 무엇인지에 대한 더 명확한 아이디어를 추구하는 경향이 있습니다.

90%


DevOps에서 배우기: 명명의 힘 #

InnerSource의 정의적 도전을 이해하기 위해 DevOps를 살펴보겠습니다. 제가 그 진화를 이해하는 방식은 다음과 같습니다: Flickr 같은 회사의 실무자들이 혁신적인 일을 하고 있었습니다—개발과 운영 사이의 사일로를 허무는 것이었죠. 그들이 자신들의 경험을 공유하고 누군가가 그것에 이름을 붙였을 때—“DevOps”—마법 같은 일이 일어났습니다. 갑자기 모든 곳의 회사들이 자신들도 비슷한 일을 하고 있다는 것을 깨달았고, 모두가 자신들의 이야기를 공유하기 시작했습니다.

핵심 통찰은 다음과 같습니다: 실천이 이름보다 먼저 존재했지만, 명명이 커뮤니티를 만들어냈습니다. 그 커뮤니티와 함께 도구, 공유된 개념, 컨퍼런스, 그리고 폭발적인 성장이 왔습니다. DevOps는 발명된 것이 아니라 발견되고 명명된 것입니다. 명명이 다른 모든 것을 촉진했습니다.

InnerSource는 놀랍도록 유사한 패턴을 따릅니다. Tim O’Reilly가 2000년 블로그 포스트에서 언급했습니다. 2015년에 Danese Cooper와 동료들이 당시 PayPal에서 InnerSource Commons를 공식화하고, 나중에 재단으로 분리했습니다. 하지만 그들은 실천을 발명한 것이 아니라 사람들이 이미 하고 있던 일에 이름을 붙인 것입니다.

이 명명은 마법 같았습니다. 갑자기 고립된 실무자들이 자신들이 혼자가 아니라는 것을 깨달았습니다. “아, 우리가 내부 라이브러리로 하고 있던 그 일? 그게 InnerSource구나!” 커뮤니티는 패턴 공유로 폭발적으로 성장했고, 집단적 지혜를 포착하는 InnerSource Patterns 같은 자원으로 이어졌습니다.

오늘날 DevOps란 무엇인가? 여러 관점 중 하나 #

사람들은 DevOps를 수없이 많은 방식으로 정의하며, 저는 그 모든 것을 다룰 수는 없습니다. 다음은 그것이 어떻게 이해될 수 있는지에 대한 한 가지 예입니다:

  • 전통적으로 분리된 팀들 간의 협업 문화
  • 실천과 자동화 도구의 집합
  • 전통적인 폭포수 개발에 반대하는 철학
  • 방법론과 프레임워크의 모음
  • 전문 영역으로의 확장: BizDevOps, DevSecOps, 그리고 그 너머

이것은 단지 하나의 해석입니다. 열 명의 실무자에게 물어보면 열 가지 다른 강조점을 얻을 것입니다. 이러한 다양성은 약점이 아니라 진화적 강점입니다.

90%


“내부 오픈소스"의 다중 의미 #

“내부 오픈소스"라는 구문은 역설적으로 보이며, 이 역설은 InnerSource가 다른 조직들에게 다른 것을 의미하는 이유를 드러냅니다. 우리 커뮤니티 토론에서 나온 몇 가지 대표적인 예를 공유하겠습니다:

오픈소스 성숙도로 가는 경로로서의 InnerSource #

어떤 이들에게는 InnerSource가 오픈소스 참여와 디지털 변혁을 향한 유기적 경로를 열어줍니다. 이것은 단지 최종적인 오픈소스 기여를 준비하는 것이 아니라—조직이 진정한 소프트웨어 회사로 성장할 수 있는 환경을 만드는 것입니다. Microsoft와 Google 같은 회사들이 이러한 여정을 예시하며, 내부 실천이 자연스럽게 외부 실천을 반영하도록 진화하여 회사 내부와 외부 모두에서 원활한 협업을 만들어냅니다.

하지만 제조업체, 소매업체, 또는 금융 기관은 어떨까요? 그들이 대량의 오픈소스를 사용할 수도 있지만, 그들의 여정은 다릅니다. 그들에게 InnerSource는 더 긴 변혁의 첫 번째 단계일 수 있습니다—소프트웨어 역량 구축, 혁신 문화 조성, 그리고 아마도 결국 자신들의 비즈니스 모델에 맞는 오픈소스 참여의 고유한 방식을 찾는 것입니다.

조직 투명성으로서의 InnerSource #

많은 이들이 문화적 변혁을 위해 InnerSource에 끌립니다. 이것은 단지 풀 리퀘스트를 보내는 것이 아닙니다—그것도 일부이긴 하지만. 다음과 같은 일을 할 수 있는 유기적 투명성을 만드는 것입니다:

  • 다른 팀에 기능 요청 제출하기
  • 인접한 팀들이 무엇을 구축하고 있는지 보기
  • 더 넓은 조직의 기술 환경 이해하기
  • 협업을 방해하는 사일로 허물기
  • 정보가 자연스럽게 흐르는 더 개방적이고 숨 쉴 수 있는 조직 문화 만들기

이러한 투명성은 조직을 경직된 계층구조에서 살아있는 협업 네트워크로 변혁시킵니다.

궁극적으로, 이것들은 엔지니어, 제품 팀, 그리고 조직 내 모든 관련자들의 행복과 복지에 기여합니다. 지원적인 업무 환경에서 신뢰받는다고 느끼는 것—기본적으로 신뢰받는다고 느끼는 것—은 매우 중요합니다. 이것은 개발자 경험과 관련이 있으며, 결과적으로 인재 유지 개선으로 이어지는 동시에 채용에도 긍정적인 결과를 제공합니다.

자원 최적화로서의 InnerSource #

전통적인 계층적 프로젝트 관리는 모든 수준에서 마진을 추가합니다. 요구사항이 아래로 흘러가며, 각 층이 불확실성에 대한 버퍼 시간을 추가합니다. 작업이 구현에 도달할 때쯤에는 일정이 부풀어 오르고 엔지니어들이 압박을 받습니다.

InnerSource는 이것을 뒤집습니다. 문제에 가장 가까운 사람들이 그것을 가장 잘 이해합니다. 그들은 연쇄적인 회의와 승인 없이 우선순위를 정하고, 논의하고, 문제를 해결할 수 있습니다. 이것이 항상 옳지는 않습니다—현장 팀들은 자신들의 현장만 알죠—하지만 전략적 감독과 균형을 이룰 때 강력합니다.

하지만 자원 최적화는 인적 자원과 팀 자원을 넘어섭니다. 조직의 코드 자산, 지적 재산, 그리고 경쟁 우위를 활용하는 것이기도 합니다. 팀들이 서로의 도구, 라이브러리, 지식을 공유하고 구축할 수 있을 때, 사일로화된 구조에서는 존재하지 않았을 시너지를 만들어냅니다. 여러분 팀이 구축한 그 내부 머신러닝 라이브러리? 다른 팀이 여러분이 상상하지 못했던 방식으로 확장할 수도 있습니다. 여러분에게 경쟁 우위를 준 테스팅 프레임워크? 그것을 내부적으로 공유하는 것은 조직 전체에서 그 가치를 배가시킵니다. InnerSource는 조직들이 자신들의 코드와 지식 자산이 비축될 때가 아니라 공유될 때 더 가치 있게 성장하는 자원이라는 것을 깨닫도록 돕습니다.


정의의 딜레마: 상황이 모든 것이다 #

이러한 다중 의미의 도전은 InnerSource만의 것이 아닙니다. Open Source Program Office (OSPO) 옹호자들이 내부적으로 오픈소스를 홍보하는 방식을 생각해보세요. 그들은 각 활동이 다른 이해관계자들로부터 동의를 얻어야 하고, 조직의 각 층이 다른 관심사와 우려를 가지고 있기 때문에 다른 청중에게 절대적으로 다른 메시지를 사용합니다.

InnerSource 옹호를 위해서는 메시지가 다음과 같을 수 있습니다:

엔지니어들에게: “뛰어난 동료들과 협업하고, 최고의 코드에서 배우고, 즉각적인 팀을 넘어서는 흥미진진한 프로젝트에 기여하세요”

중간 관리층에게: “중복을 줄이고, 효율성을 높이고, 재사용과 협업을 통해 전달을 가속화하세요”

경영진에게: “비용을 줄이고, 혁신 속도를 높이고 최고 인재를 유지하세요”

동일한 InnerSource 이니셔티브가 이 모든 목표를 동시에 달성하지만, 다른 청중에게 다른 측면을 강조합니다. 이것은 기만이 아닙니다—InnerSource가 다른 변혁적 방법론과 마찬가지로 여러 수준에서 가치를 제공한다는 인식입니다.

여러분의 InnerSource 정의는 단지 청중에 따라 달라지는 것이 아니라 단계에 따라서도 달라집니다. 그리고 그것은 완전히 괜찮습니다.


여러분의 InnerSource 여정: 진화하는 정의 #

그렇다면 InnerSource란 무엇일까요? 그것은 여러분이 정의하는 것입니다.

아마도 미래에 InnerSource Commons Foundation이 InnerSource가 무엇인지 즉시 명백하게 만드는 더 명확하고 소통 가능한 정의를 개발할 것입니다. 개인적으로 저는 그날을 기대하지만, 이러한 다양성 속에서 그런 정의를 만드는 것이 매우 어려운 과제라는 것을 인식합니다.

더욱이, 여러분의 정의는 진화할 수 있고 진화해야 합니다. 여러분의 여정을 시작하는 데 도움이 되는 InnerSource는 3년 후에 실천하는 InnerSource와 다를 수 있습니다. 여러분의 조직이 성숙해지고, 도전이 변하고, 이해가 깊어짐에 따라 여러분의 정의가 바뀔 수 있습니다.

여러분은 자신의 정의를 커뮤니티에 가져와서 관점을 공유하고, 우리 모두가 이러한 질문들을 함께 생각해보도록 도울 수 있습니다. 이러한 집단적 탐구가 우리가 결국 공유된 이해에 도달하는 방법입니다—하향식 명령이 아니라 협업적 발견을 통해서 말입니다.

90%


행동 촉구 #

완벽한 정의를 찾기보다는, 저는 여러분이 InnerSource를 경험해보기를 권합니다:

  • 여러분이 보는 문제를 설명하는 이슈 제출하기
  • 문서를 수정하는 풀 리퀘스트 보내기
  • 다른 팀에 기능 요청하기
  • 동료들과 코드 공유하기
  • 다른 팀들이 무엇을 구축하고 있는지 탐색하기
  • 조직 경계를 넘어 협업하기

실천을 통해 여러분은 InnerSource가 여러분의 조직에 무엇을 의미하는지 발견할 것입니다. 여러분은 우리 나머지가 배울 수 있는 새로운 패턴을 발명할 수도 있습니다.

대화에 참여하기 #

2025년, AI가 우리가 코드를 작성하고 협업하는 방식을 변혁시키면서, InnerSource 원칙들이 더욱 관련성을 갖게 됩니다. AI가 수천 줄을 즉시 생성할 수 있을 때 어떻게 품질을 유지할까요? 코드 생성이 자동화될 때 어떻게 지식 공유를 보존할까요? 어떻게 인간의 판단이 소프트웨어 개발의 중심에 남아있도록 보장할까요?

이 문제에 대해서는 AI 시대의 협업 방법론을 다루는 기사를 참조해주세요.

음, 이러한 질문들은 아직 답이 없지만, 개방성, 투명성, 우선순위가 부여된 멘토십, 그리고 자발적 코드 기여를 강조하는 InnerSource가 이것들을 탐구하기에 독특하게 위치해 있다고 믿습니다.

InnerSource는 많은 맛이 있습니다. 여러분은 자신만의 것을 추가할 수 있습니다. 존재하지만 명확히 표현되지 않은 패턴들에 이름을 붙일 수 있습니다. 이것이 InnerSource가 흥미진진한 이유입니다: 그것은 커뮤니티가 성장하고, 진화하고, 혁신을 퍼뜨리는 깃발입니다.

InnerSource Commons Foundation은 이러한 토론을 환영합니다. 우리 커뮤니티 구성원들은 매일 이러한 질문들을 탐구하고, 경험을 공유하고, 내부 협업의 미래를 구축하고 있습니다.

그래서 저는 여러분에게 묻습니다: 여러분의 InnerSource는 무엇입니까? 여러분의 조직을 위해 어떻게 정의하시겠습니까? 어떤 패턴을 발견하고 공유하시겠습니까?

이러한 질문들을 함께 탐구해봅시다. 여정은 이제 막 시작되었습니다. *innersourcecommons.org*에서 대화에 여러분을 환영하기를 기대합니다.

Yuki Hattori

Yuki Hattori

President of the InnerSource Commons Foundation
Sr. Architect at GitHub
Open Source Technical Advisor at IPA (Japanese government administration)
Author of two books on AI and GitHub
O’Reilly books translator for Prompt Enginnering for LLMs and two InnerSource books[1][2]
 
Opinions expressed here are my own and do not represent any organization I am affiliated with.