2021.11.05

기업 내 개방 원칙 '이너 소스', 드디어 모멘텀을 형성하다

Scott Carey | InfoWorld
팀 오라일리가 처음 만든 개념인 이너 소스(Inner source)는 독자적인 사설 소프트웨어를 만들 때 조직 내부에 오픈소스 방식을 도입하는 것이 목적인 엔지니어링 원칙이다. 오픈소스의 ‘개방성’을 여러 조직의 여러 기여자들이 아닌 조직 내 모든 팀으로 확대한다.

오픈소스 공동체는 이너 소스 원칙을 통해 공통된 기법과 도구를 이용하게 된다. 각자의 1차적 책임은 아니지만 많은 기여자들이 서로 협력해 코드를 개발하는 방식이다. 일반적으로 공유 코드 리포지토리, 풀 요청, 코멘트, 기타 광범위한 도큐멘테이션을 사용한다.

소프트웨어 개발 방식을 현대화하고, 코드를 팀 책임 하에서 기밀로 유지해야 하는 지적 재산이 아닌, 협력적이고 재사용이 가능한 자산으로 보기 시작한 기존 기업 사이에서 갈수록 인기가 높아지고 있는 방법론이다. 또한 이너 소스 방식은 안전하고 투명한 방법으로 개발자가 풀 요청을 통해 변화를 추진할 수 있도록 도우므로 업스트림의 장애물도 없앤다.
 
ⓒ Getty Images Bank

이너 소스를 도입하려면 조직 문화를 크게 바꿔야 하지만, 코드의 품질, 신뢰도, 보안 향상이라는 장점이 따라온다. 또 오랜 사일로를 없애 협업 수준과 개발 속도를 높인다. 특히 팬데믹 기간에 그 중요성이 더욱 커진 분야다.

이너소스 커먼스 파운데이션(InnerSource Commons Foundation)의 다네스 쿠퍼는 Infoworld에 “이너 소스가 입증한 한 가지는 이질적인 팀 전반에 걸친 광범위한 피어(동료) 기반의 협업은 같은 공간과 시간대에 위치한 통제된 팀만큼 효과적이라는 점”이라고 말했다. 이너 소스로 이루어진 협업은 코로나19 기간 업무 추진에 중요한 역할을 했으며, 효과성을 증명하고 도입 촉진에도 영향을 미치고 있다.

이너 소스 기법을 도입한 3개 업체에서 이너 소스가 적합한 이유와 개발자의 성과에 어떤 긍정적 영향을 미쳤는지 들어보자.
 

블룸버그(Bloomberg) : 엔지니어가 원하는 변화를 실현하는 역량

이너 소스가 정착한 산업 분야 중 하나는 금융 서비스 산업이다. 조직 사일로, 보수적이고 때로는 비밀스러운 방식으로 코드를 공유하지 않는 관행이 오랜 기간 기준처럼 적용됐던 분야다.

2021년 10월 런던에서 열린 오픈소스 전략 포럼(Open Source Strategy Forum)에서 US뱅크(US Bank)의 오픈소스 책임자인 질 에후다는 “전통적인 조직인 은행에서 이너 소스는 자기 레인 안에서만 수영하는 방식을 탈피하는 변화다. 코드를 공유하지 않는 방법으로 코드를 보호한다는 개념은 의존성과 종속성 때문에 현실적이지 않다. 모두가 혜택을 누릴 수 있는, 서로 공유하는 공동 자산으로 보는 것이 더 건강하다”라고 강조했다.

같은 날 또 다른 패널인 캐피털 원(Capital One)의 엔지니어 아서 몰트슨은 “현재 캐피털 원은 코드를 많이 공유하고 잇고, 여러 부서와 부문이 협력해 플랫폼에 기여하고 있다. 엔지니어가 성숙해지면 코드는 비즈니스 문제를 해결하는 수단이 되며, 이너 소스와 더 많은 개방성으로 문제를 효과적으로 풀어낸다. 협력하는 사람이 많을수록 더 효과적으로 문제를 해결할 수 있다. 엔지니어가 갖고 있는 과도한 소유 중심 문화를 극복해야 한다”라고 설명했다.

블룸버그의 경우, 지난 10년 동안 이너 소스가 서서히 기준으로 정착됐다. 내부 개발자 도구부서에서 시작되어 지금은 크로스 애셋 거래와 다른 중요 애플리케이션에 활용되는 수용된 방식이 되었다.

블룸버그 팀 책임자인 조 파트라오는 올해 초 한 프레젠테이션에서 “과거 어느 때보다 전사적으로 엔지니어가 다른 팀 코드 베이스에서 원하는 변화를 볼 수 있게 역량이 부여되어 있다. 고객을 만족시키는 간단한 버그 픽스일 수도 있고, 여러 엔지니어의 생산성을 향상시키는 중요한 기능이 대상이 될 수 있다”라고 말했다.

현재 블룸버그의 모든 엔지니어는 깃허브 엔터프라이즈(GitHub Enterprise)를 이용해 코드를 확인하고, 동료와 협력한다. 또 기여와 테스트에 대한 명확한 기준이 있다. 블룸버그 소프트웨어 엔지니어링 팀 리더인 베키 플러머는 Infoworld에 “변경할 때 풀 요청과 코드 리뷰를 활용한다. 기대되는 기준은 팀별로 차이가 있다”라고 말했다. 예를 들어, 내부 도구 풀 요청에 적용되는 기준은 규제를 많이 받는 거래 애플리케이션에 적용되는 기준보다 낮을 수 있다.

이너 소스 기법을 도입하기 전, 블룸버그 엔지니어는 관련 제품 매니저에게 연락해 기능이나 통합을 요청해야 했다. 이러한 관행은 개발자의 속도를 늦추고, 팀을 아우르는 협력을 방해했다. 플러머는 “지난 몇 년 동안 이너 소스가 경이로운 학습 경험임을 깨달았다. 이너 소스는 가치를 제공하고 제품 배포를 가속화한다는 것을 알게 됐다”라고 말했다.
 

BBC : 기능 배포 속도를 앞당기는 코드 재사용

영국의 국영 방송사인 BBC는 지난 4년 간 이너 소스 문화를 유기적으로 발전시켰다. 이를 통해 내부 팀 관계가 더 밀접해졌고, 부서 간 협업 수준이 향상되었으며, 소프트웨어 개발 주기가 더 효율적으로 변했다.

인기 높은 아이플레이어 및 사운드 애플리케이션에 초점을 맞추고 있는 TV 애플리케이션 팀의 경우, 이미 오픈소스를 잘 이해하고 있는 상태였다. 2012년에 독자적인 TV 애플리케이션 레이어를 오픈소스한 팀이기 때문이다. 그러나 조직의 나머지 부문은 그러지 못했다.

BBC 아이플레이어 앤 사운드 애플리케이션 소프트웨어 엔지니어링 팀 책임자인 톰 새들러는 “이미 오픈소스를 많이 활용하고 있었다. TV 애플리케이션 레이어 같은 독자적 소프트웨어를 오픈소스화하면서 이너 소스 문화가 크게 견인됐다. 10개 팀이 TV 앱을 개발하기 위해 협력해야 했는데 이것이 정말 중요했다”라고 설명했다.

예를 들어, BBC는 2020년 3월 스마트 TV용 라디오 애플리케이션인 사운드 온 TV를 예상보다 빨리 시장화 할 수 있었다. 여러 팀이 처음부터 각각 시작하지 않고, 기존에 출시된 아이플레이어 TV 애플리케이션의 코드를 재사용하는 이너 소스 문화 덕분이었다.

모든 팀이 일관된 풀 요청과 지속적인 배포 프로세스를 활용하면서, 소프트웨어 개발에 이너 소스 방식을 활용하는 사례가 확산되기 시작했다. 새들러는 “항상 뭔가 해주는 팀을 필요로 하는 대신, 이들과 협력하는 방식으로 전환했다”라고 말했다.

BBC에서 변경이 처리되고 승인되는 방식의 경우, 중요한 변경인지 사소한 변경인지에 대한 내부 판단이 중요하다. 사소한 변경의 경우, 조직 신뢰 체계 및 요소가 있다. 중요한 변경이나 변화에는 러스트(Rust) 프로그래밍 언어 같은 대형 오픈소스 프로젝트와 유사하게 변경 요청(Request-for-changes) 프로세스를 적용한다. 변경이나 변화 전에 영향을 받는 모든 사람이 의견을 내고, 대안을 제시하는 프로세스다.

이런 문화는 개발자 팀이 물리적으로 멀리 떨어져있어 비 동시 협력이 아주 중요했던 팬데믹 기간에 큰 도움을 줬다. 새들러는 “풀 요청 사고방식, 슬랙과 팀즈에서의 대화, 여러 팀 간 의사결정 메커니즘은 팬데믹 기간 큰 도움을 줬다”라고 강조했다.
 

아소스(Asos) : PR에는 놀라움이 없어야 한다

온라인 의류 소매업체인 아소스는 4년 전 70여 엔지니어링 전반에 걸쳐 이너 소스를 도입 및 확립했는데, ‘레거시’가 거의 없다는 이점을 활용했다. 아소스의 아키텍처 및 엔지니어링 담당 디렉터인 데이브 그린은 “이들 팀은 디봅스, 애자일 팀이다. 상당한 자율성을 갖고 자신의 애플리케이션을 소유하고 있다. 우리는 ‘크로스-팀’ 배포에 박차를 가할 기회를 봤다”라고 말했다.

아소스는 팀 간 이너 소스 사고방식을 촉진, 조직 사일로 일부를 없애고, 코드 재사용을 장려하고, 더 많은 사람이 코드 작업에 참여해 품질을 높이도록 만들 수 있었다. 아소스의 수석 엔지니어인 토니 고먼은 “모든 사람이 다른 모든 사람을 볼 수 있도록 벽을 허물고 싶었다. 투명성과 좋은 커뮤니케이션을 통해 아소스 내부에 공동체를 구축할 수 있다”라고 말했다.

고먼은 이너 소스를 가리켜 “코드를 더 나은 코드로 만들고, 더 많은 기능을 구현하고, 그 코드의 소유자를 존중하는 개념이다(모든 사람이 어떤 식으로든 코드를 소중하게 여기는). 이를 위해서는 명확하면서 투명해야 한다”라고 설명했다.

하지만 모든 것이 순조로운 항해는 아니었다. 그린은 “이것은 여정이다. 내부에서만 이뤄지는 경우와 다르게, 다른 사람들이 보고 기여할 것이라는 것을 알면 코드를 쓰는 방법이 달라진다. 따라서 문서화와 자동화가 아주 중요한 역할을 한다”라고 강조했다.

그린과 고먼에 따르면, 초기에 실수는 많지 않았다. 그러나 화가 난 엔지니어가 휴가를 떠나기 전에 적절한 절차를 따르지 않고 새 기능을 배포하기로 결정한 일이 있었다. 고먼은 “이로 인해 격의 없는 대화를 하게 됐다. 그리고 이 여정으로 인해 아소스에 원칙 하나가 만들어졌다. 풀 요청에는 놀라움이 없어야 한다는 것”이라고 말했다. 아소스는 깃허브, 마이크로소프트 애저 리포(Azure Repos), 슬랙과 마이크로소프트 팀즈 같은 협업 도구로 이너 소스 원칙 아래 안전하게 협업하고 있다. 여기에서는 크로스 팀 협업이 ‘기준’으로 정착되어 있다.

이제 아소스는 내부 프로젝트가 다시 커뮤니티에서 오픈소스화할 만한 가치가 있는 방식으로 발전하고 있음을 확인하고 있다. 고먼은 “받은 만큼 커뮤니티에 돌려주고 싶은 열망이 있다”라고 말했다.
 

이너 소스의 출발점

많은 엔지니어가이 이너 소스를 시작하는 ‘기준’ 같은 회사로 페이팔을 예로 들었다.

또한 ‘이너 소스 시작하기(Getting started with InnerSource)’나 ‘이너 소스 도입(Adopting InnerSource)’ 같은 전자책도 참고할 수 있다.

활발히 활동하는 대표적인 이너 소스 커뮤니티로는 이너소스 커먼스(InnerSource Commons)를 들 수 있다. 그 외에도 블로그, 위키, 깃 리포지토리, 유튜브 학습 비디오 시리즈에서 사용례와 검증된 패턴 등을 확인할 수 있다. editor@itworld.co.kr 


2021.11.05

기업 내 개방 원칙 '이너 소스', 드디어 모멘텀을 형성하다

Scott Carey | InfoWorld
팀 오라일리가 처음 만든 개념인 이너 소스(Inner source)는 독자적인 사설 소프트웨어를 만들 때 조직 내부에 오픈소스 방식을 도입하는 것이 목적인 엔지니어링 원칙이다. 오픈소스의 ‘개방성’을 여러 조직의 여러 기여자들이 아닌 조직 내 모든 팀으로 확대한다.

오픈소스 공동체는 이너 소스 원칙을 통해 공통된 기법과 도구를 이용하게 된다. 각자의 1차적 책임은 아니지만 많은 기여자들이 서로 협력해 코드를 개발하는 방식이다. 일반적으로 공유 코드 리포지토리, 풀 요청, 코멘트, 기타 광범위한 도큐멘테이션을 사용한다.

소프트웨어 개발 방식을 현대화하고, 코드를 팀 책임 하에서 기밀로 유지해야 하는 지적 재산이 아닌, 협력적이고 재사용이 가능한 자산으로 보기 시작한 기존 기업 사이에서 갈수록 인기가 높아지고 있는 방법론이다. 또한 이너 소스 방식은 안전하고 투명한 방법으로 개발자가 풀 요청을 통해 변화를 추진할 수 있도록 도우므로 업스트림의 장애물도 없앤다.
 
ⓒ Getty Images Bank

이너 소스를 도입하려면 조직 문화를 크게 바꿔야 하지만, 코드의 품질, 신뢰도, 보안 향상이라는 장점이 따라온다. 또 오랜 사일로를 없애 협업 수준과 개발 속도를 높인다. 특히 팬데믹 기간에 그 중요성이 더욱 커진 분야다.

이너소스 커먼스 파운데이션(InnerSource Commons Foundation)의 다네스 쿠퍼는 Infoworld에 “이너 소스가 입증한 한 가지는 이질적인 팀 전반에 걸친 광범위한 피어(동료) 기반의 협업은 같은 공간과 시간대에 위치한 통제된 팀만큼 효과적이라는 점”이라고 말했다. 이너 소스로 이루어진 협업은 코로나19 기간 업무 추진에 중요한 역할을 했으며, 효과성을 증명하고 도입 촉진에도 영향을 미치고 있다.

이너 소스 기법을 도입한 3개 업체에서 이너 소스가 적합한 이유와 개발자의 성과에 어떤 긍정적 영향을 미쳤는지 들어보자.
 

블룸버그(Bloomberg) : 엔지니어가 원하는 변화를 실현하는 역량

이너 소스가 정착한 산업 분야 중 하나는 금융 서비스 산업이다. 조직 사일로, 보수적이고 때로는 비밀스러운 방식으로 코드를 공유하지 않는 관행이 오랜 기간 기준처럼 적용됐던 분야다.

2021년 10월 런던에서 열린 오픈소스 전략 포럼(Open Source Strategy Forum)에서 US뱅크(US Bank)의 오픈소스 책임자인 질 에후다는 “전통적인 조직인 은행에서 이너 소스는 자기 레인 안에서만 수영하는 방식을 탈피하는 변화다. 코드를 공유하지 않는 방법으로 코드를 보호한다는 개념은 의존성과 종속성 때문에 현실적이지 않다. 모두가 혜택을 누릴 수 있는, 서로 공유하는 공동 자산으로 보는 것이 더 건강하다”라고 강조했다.

같은 날 또 다른 패널인 캐피털 원(Capital One)의 엔지니어 아서 몰트슨은 “현재 캐피털 원은 코드를 많이 공유하고 잇고, 여러 부서와 부문이 협력해 플랫폼에 기여하고 있다. 엔지니어가 성숙해지면 코드는 비즈니스 문제를 해결하는 수단이 되며, 이너 소스와 더 많은 개방성으로 문제를 효과적으로 풀어낸다. 협력하는 사람이 많을수록 더 효과적으로 문제를 해결할 수 있다. 엔지니어가 갖고 있는 과도한 소유 중심 문화를 극복해야 한다”라고 설명했다.

블룸버그의 경우, 지난 10년 동안 이너 소스가 서서히 기준으로 정착됐다. 내부 개발자 도구부서에서 시작되어 지금은 크로스 애셋 거래와 다른 중요 애플리케이션에 활용되는 수용된 방식이 되었다.

블룸버그 팀 책임자인 조 파트라오는 올해 초 한 프레젠테이션에서 “과거 어느 때보다 전사적으로 엔지니어가 다른 팀 코드 베이스에서 원하는 변화를 볼 수 있게 역량이 부여되어 있다. 고객을 만족시키는 간단한 버그 픽스일 수도 있고, 여러 엔지니어의 생산성을 향상시키는 중요한 기능이 대상이 될 수 있다”라고 말했다.

현재 블룸버그의 모든 엔지니어는 깃허브 엔터프라이즈(GitHub Enterprise)를 이용해 코드를 확인하고, 동료와 협력한다. 또 기여와 테스트에 대한 명확한 기준이 있다. 블룸버그 소프트웨어 엔지니어링 팀 리더인 베키 플러머는 Infoworld에 “변경할 때 풀 요청과 코드 리뷰를 활용한다. 기대되는 기준은 팀별로 차이가 있다”라고 말했다. 예를 들어, 내부 도구 풀 요청에 적용되는 기준은 규제를 많이 받는 거래 애플리케이션에 적용되는 기준보다 낮을 수 있다.

이너 소스 기법을 도입하기 전, 블룸버그 엔지니어는 관련 제품 매니저에게 연락해 기능이나 통합을 요청해야 했다. 이러한 관행은 개발자의 속도를 늦추고, 팀을 아우르는 협력을 방해했다. 플러머는 “지난 몇 년 동안 이너 소스가 경이로운 학습 경험임을 깨달았다. 이너 소스는 가치를 제공하고 제품 배포를 가속화한다는 것을 알게 됐다”라고 말했다.
 

BBC : 기능 배포 속도를 앞당기는 코드 재사용

영국의 국영 방송사인 BBC는 지난 4년 간 이너 소스 문화를 유기적으로 발전시켰다. 이를 통해 내부 팀 관계가 더 밀접해졌고, 부서 간 협업 수준이 향상되었으며, 소프트웨어 개발 주기가 더 효율적으로 변했다.

인기 높은 아이플레이어 및 사운드 애플리케이션에 초점을 맞추고 있는 TV 애플리케이션 팀의 경우, 이미 오픈소스를 잘 이해하고 있는 상태였다. 2012년에 독자적인 TV 애플리케이션 레이어를 오픈소스한 팀이기 때문이다. 그러나 조직의 나머지 부문은 그러지 못했다.

BBC 아이플레이어 앤 사운드 애플리케이션 소프트웨어 엔지니어링 팀 책임자인 톰 새들러는 “이미 오픈소스를 많이 활용하고 있었다. TV 애플리케이션 레이어 같은 독자적 소프트웨어를 오픈소스화하면서 이너 소스 문화가 크게 견인됐다. 10개 팀이 TV 앱을 개발하기 위해 협력해야 했는데 이것이 정말 중요했다”라고 설명했다.

예를 들어, BBC는 2020년 3월 스마트 TV용 라디오 애플리케이션인 사운드 온 TV를 예상보다 빨리 시장화 할 수 있었다. 여러 팀이 처음부터 각각 시작하지 않고, 기존에 출시된 아이플레이어 TV 애플리케이션의 코드를 재사용하는 이너 소스 문화 덕분이었다.

모든 팀이 일관된 풀 요청과 지속적인 배포 프로세스를 활용하면서, 소프트웨어 개발에 이너 소스 방식을 활용하는 사례가 확산되기 시작했다. 새들러는 “항상 뭔가 해주는 팀을 필요로 하는 대신, 이들과 협력하는 방식으로 전환했다”라고 말했다.

BBC에서 변경이 처리되고 승인되는 방식의 경우, 중요한 변경인지 사소한 변경인지에 대한 내부 판단이 중요하다. 사소한 변경의 경우, 조직 신뢰 체계 및 요소가 있다. 중요한 변경이나 변화에는 러스트(Rust) 프로그래밍 언어 같은 대형 오픈소스 프로젝트와 유사하게 변경 요청(Request-for-changes) 프로세스를 적용한다. 변경이나 변화 전에 영향을 받는 모든 사람이 의견을 내고, 대안을 제시하는 프로세스다.

이런 문화는 개발자 팀이 물리적으로 멀리 떨어져있어 비 동시 협력이 아주 중요했던 팬데믹 기간에 큰 도움을 줬다. 새들러는 “풀 요청 사고방식, 슬랙과 팀즈에서의 대화, 여러 팀 간 의사결정 메커니즘은 팬데믹 기간 큰 도움을 줬다”라고 강조했다.
 

아소스(Asos) : PR에는 놀라움이 없어야 한다

온라인 의류 소매업체인 아소스는 4년 전 70여 엔지니어링 전반에 걸쳐 이너 소스를 도입 및 확립했는데, ‘레거시’가 거의 없다는 이점을 활용했다. 아소스의 아키텍처 및 엔지니어링 담당 디렉터인 데이브 그린은 “이들 팀은 디봅스, 애자일 팀이다. 상당한 자율성을 갖고 자신의 애플리케이션을 소유하고 있다. 우리는 ‘크로스-팀’ 배포에 박차를 가할 기회를 봤다”라고 말했다.

아소스는 팀 간 이너 소스 사고방식을 촉진, 조직 사일로 일부를 없애고, 코드 재사용을 장려하고, 더 많은 사람이 코드 작업에 참여해 품질을 높이도록 만들 수 있었다. 아소스의 수석 엔지니어인 토니 고먼은 “모든 사람이 다른 모든 사람을 볼 수 있도록 벽을 허물고 싶었다. 투명성과 좋은 커뮤니케이션을 통해 아소스 내부에 공동체를 구축할 수 있다”라고 말했다.

고먼은 이너 소스를 가리켜 “코드를 더 나은 코드로 만들고, 더 많은 기능을 구현하고, 그 코드의 소유자를 존중하는 개념이다(모든 사람이 어떤 식으로든 코드를 소중하게 여기는). 이를 위해서는 명확하면서 투명해야 한다”라고 설명했다.

하지만 모든 것이 순조로운 항해는 아니었다. 그린은 “이것은 여정이다. 내부에서만 이뤄지는 경우와 다르게, 다른 사람들이 보고 기여할 것이라는 것을 알면 코드를 쓰는 방법이 달라진다. 따라서 문서화와 자동화가 아주 중요한 역할을 한다”라고 강조했다.

그린과 고먼에 따르면, 초기에 실수는 많지 않았다. 그러나 화가 난 엔지니어가 휴가를 떠나기 전에 적절한 절차를 따르지 않고 새 기능을 배포하기로 결정한 일이 있었다. 고먼은 “이로 인해 격의 없는 대화를 하게 됐다. 그리고 이 여정으로 인해 아소스에 원칙 하나가 만들어졌다. 풀 요청에는 놀라움이 없어야 한다는 것”이라고 말했다. 아소스는 깃허브, 마이크로소프트 애저 리포(Azure Repos), 슬랙과 마이크로소프트 팀즈 같은 협업 도구로 이너 소스 원칙 아래 안전하게 협업하고 있다. 여기에서는 크로스 팀 협업이 ‘기준’으로 정착되어 있다.

이제 아소스는 내부 프로젝트가 다시 커뮤니티에서 오픈소스화할 만한 가치가 있는 방식으로 발전하고 있음을 확인하고 있다. 고먼은 “받은 만큼 커뮤니티에 돌려주고 싶은 열망이 있다”라고 말했다.
 

이너 소스의 출발점

많은 엔지니어가이 이너 소스를 시작하는 ‘기준’ 같은 회사로 페이팔을 예로 들었다.

또한 ‘이너 소스 시작하기(Getting started with InnerSource)’나 ‘이너 소스 도입(Adopting InnerSource)’ 같은 전자책도 참고할 수 있다.

활발히 활동하는 대표적인 이너 소스 커뮤니티로는 이너소스 커먼스(InnerSource Commons)를 들 수 있다. 그 외에도 블로그, 위키, 깃 리포지토리, 유튜브 학습 비디오 시리즈에서 사용례와 검증된 패턴 등을 확인할 수 있다. editor@itworld.co.kr 


X