[시드 시브랜디 깃랩 CEO]오픈코어 접근방식은 적절한 프로토콜과 인터페이스가 없기 때문에 확장 가능한 통합 에코시스템을 구현하기에는 상당히 까다로운 방법임이 분명하다. 그러나 누구든 코드 베이스에 추가적인 통합이 가능하고, 해당 코드 베이스를 필요에 따라 조정할 수도 있다.
그렇다면, 깃랩(GitLab)은 왜 이러한 ‘불완전한(Worse)’ 접근방식을 사용하여 오랫동안 큰 성공을 거둘 수 있었을까? 이는 리차드 가브리엘(Richard P. Gabriel)이 ‘불완전한 것이 낫다(Worse is Better)’라는 용어로 설명했던 것과 같은 이유다. 실제로는 가브리엘이 ‘불완전한 것이 낫다(Worse is Better)’라고 제시했던 것보다 이 ‘불완전한(Worse)’ 것은 사실상 훨씬 더 나은 것으로 밝혀졌다.
가브리엘의 원래 주장은 본질적으로 (약간) 불완전할 수 있지만, 보다 간단하고 쉽게 구현할 수 있는 소프트웨어는 잘 설계된 복잡한 소프트웨어보다 더욱 뛰어난 생존 특성을 가지고 있으며, 결국 시장에서 지속적으로 승리할 것이라는 내용이다.
깃랩은 이러한 논리가 기본적으로 사실이라는 점을 확인했으며, 이로 인해 해당 시나리오를 위한 최상의 솔루션이 아닐지라도 ‘보급형 기술(Boring Technology)’을 선호하고 있는 것이다. 그러나 이것 만이 아니다. 이러한 소프트웨어는 보다 성공적이었을 뿐만 아니라 결과적으로 품질 또한 향상되었다.
가브리엘의 원래 주장은 나쁜 소프트웨어가 승리한다는 뜻이 아니라는 점에 유의해야 한다. 사실, 그가 의미하는 ‘불완전한 것’과 ‘더 나은 것’은 모두 동일한 특성을 가지고 있다:
- 1. 인터페이스 및 구현의 단순성
- 2. 정확성
- 3. 일관성
- 4. 완성도
그러나 그가 말하는 ‘불완전한 것’과 ‘더 나은 것’은 이러한 특성에 부여된 가치 측면에서 약간 다른 가중치를 가지고 있다. 뉴저지 대학(New Jersey School)은 불완전한 것 측면에서 인터페이스단순성보다 구현의 단순성을 선호하는 반면, MIT 대학은 더 나은 것의 측면에서 더 복잡한 구현을 감당하더라도 인터페이스의 단순성을 더 선호한다.
간단한 구현으로 간단한 인터페이스를 얻을 수 있다면, 두 학교 모두 동의할 것이다. 차이는 절충을 해야 하는 경우 발생한다.
가브리엘이 불완전한 것이 더 나은 것이라고 제안한 뒤에 발표한 이후 버전에서도 고려하지 못했던 것은 바로 피드백 루프의 엄청난 가치다. 뉴저지 접근방식은 먼저 시장에서 승리할 수 있었을 뿐만 아니라 MIT 접근방식보다 훨씬 빠르게, 그리고 훨씬 더 앞서서 피드백을 수집할 수 있었다.
최초로 크레머(Kremer) 상을 수상한 폴 맥크레디(Paul MacCready)는 원래 최상의 인간동력항공기를 제작하고자 착수했던 것이 아니라, 피드백을 더 빨리 수집하기 위해 가장 쉽게 수리할 수 있는 항공기를 제작했다. 다른 팀들은 사고 시 복구하는데 1년 이상이 걸렸지만, 그의 비행기는 사고 당일에도 비행이 가능하기도 했다. 이처럼 그가 상에 집착하지 않았기 때문에 수상에 이르게 된 것이다.
거의 동일한 방식이지만, 훨씬 더 빨리 시작된 빠른 피드백 루프를 가진 ‘불완전한’ 접근방식은 결국 더 나은 제품으로 이어지게 된다.
플러그인의 문제
적절한 플러그인 인터페이스는 공급업체가 모든 기능을 자체적으로 제공하지 않아도 유용한 기능을 제공하는 제3자(Third-Party) 생태계를 조성함으로써 사용자에게 더 매력적이면서도 강력하게 유인할 수 있는 소프트웨어를 만들 수 있는 ‘올바른 방법(The Right Way )’으로 인식돼왔다.
이는 매우 성공적이었으며, 이후 오픈독(OpenDoc)과 같은 시스템들은 실제 호스팅 애플리케이션 없이 플러그인 세트 만으로 아이디어를 발전시켰다. 하지만 이러한 시스템 중 어느 것도 시장에서는 성공하지 못했다.
이유 중 하나는 우수한 플러그인 인터페이스 자체가 어렵다기 보다는 개발 자체가 상당히 복잡하기 때문이다. 기본적으로 무엇을 노출하고, 무엇을 숨길지, 그리고 어떻게 기능을 제공할 것인지에 대한 균형을 맞추기가 어렵다. 그러나 이것이 가장 큰 어려움은 아니다.
플러그인 API 개발에서 가장 골치 아픈 부분은 이러한 어려움을 처리하기 위한 작업들로 인해 난제들이 가중된다는 것이다. 더 신중하게 설계해야 하고, 더 안정적으로 인터페이스를 만들어야 하며, 천천히 반복하는 방법밖에 없다.
간단히 말하면, 닭이 먼저냐, 달걀이 먼저냐 라는 조기 추상화에 직면하게 된다. 우수한 플러그인 API를 만들기 위해서는 어떻게 사용되는지 알아야 하는데, 이를 위해서는 먼저 API가 있어야 한다. 이로 인해 초기 가용성이 지연되고, 피드백 주기가 느려지게 된다.
소프트웨어만이 이러한 문제에 직면하는 것은 아니다. 예를 들어, 공원에는 사람들이 실제로 가고 싶어하지 않는 길들이 공식적으로 설정된 경우가 많다. 한 조경 전문가 그룹은 자신들이 만든 공원에 산책로를 설정하지 않음으로써 이러한 문제를 해결했으며, 자신들의 작업도 경감시킬 수 있었다. 이 그룹은 사람들이 걷고 싶어하는 곳으로 걸어가게 함으로써 자연스럽게 산책로가 만들어지기를 기다렸다. 이러한 오솔길들이 구체화된 후에 산책로 포장공사를 하고, 이를 공식 산책로로 만들었다.
마지막으로 한 가지 더 언급하자면, 플러그인 인터페이스는 사용자가 이용하게 될 코어 애플리케이션과 모든 플러그인으로 구성된 최종 제품이 최상의 통합 상태가 아니라는 것을 의미하기도 한다. ‘여기 툴 상자가 있으니 즐겁게 이용하십시오!’라는 가치제안은 최종 사용자보다 개발자에게 훨씬 더 매력적으로 들릴 것이다. 이러한 툴 자체가 동급 최상의 제품이라 하더라도 마찬가지이다.
오픈 코어
반면, 오픈 코어는 정의된 블랙박스 경계가 없기 때문에 소프트웨어 엔지니어링 관점에서 보면 완전히 잘못된 접근방식으로 간주될 수 있으며, 실제 상호 보완적인 에코시스템이 없다면, 비즈니스 관점에서도 마찬가지일 것이다.
그러나 오픈 코어 접근방식은 최종 사용자, 즉 이를 그대로 활용하고자 하는 사용자와 적용사례에 맞게 시스템을 조정해야 하는 어댑터(개선자) 모두에게 적합하다. 그리고 결국 가장 중요한 것은 최종 사용자이다.
어댑터의 경우, 시스템을 즉시 구체화(Hackable)할 수 있다. 공급업체가 플러그인 인터페이스를 공급할 때까지 기다릴 필요가 없으며, 또한 공급업체가 미래의 언젠가 특정 애플리케이션에 필요한 기능을 제공하는 플러그인 인터페이스를 만들 때까지 기다릴 필요도 없다. 이는 코어 애플리케이션에 대한 변경이 필요한 경우에도 마찬가지이다.
또한 더 많은 개선 활동이 보다 신속하게 전개되기 때문에 시스템은 보다 유연하게 개선된 내용을 수용할 수 있으며, 계속해서 이러한 선순환을 이어갈 수 있다.
어댑터들은 여러 가지 이점을 얻을 수 있다.
무엇보다, 더 많은 기능을 보다 신속하게 시스템에 제공할 수 있다는 것은 항상 좋은 일이다. 또한 이러한 기능이 공급업체에 의해 통합되고, 전체적으로 통합된 상태로 제공된다는 것도 중요한 이점이다. 이는 단일 공급업체의 오피스 제품군이 성공한 이유이자 OpenDoc의 툴박스 접근방식이 실패한 이유이기도 하다.
다시 말해, 오픈 코어 접근방식은 견고한 엔지니어링과 우수한 아키텍처 및 지속적인 경계가 필요하다. 다른 글에서 언급한 적이 있지만, 루비 온 레일즈(Ruby on Rails)는 접근이 용이하고, 탁월한 구조의 견고한 모듈식 단일 솔루션으로 깃랩을 구현할 수 있는 훌륭한 출발점을 제공했다고 생각한다. 이러한 출발점을 통해 엄격한 API 바운더리를 시행하는 대신, 예제와 같은 모범적 설계가 권장된다. 또한 풀 리퀘스트(Pull Request)를 고려하고, 형성 및 승인 또는 거부함에 따라 보다 인간적인 형태로 시행된다.
따라서 바운더리는 여전히 존재하지만, 충돌되는 벽돌담은 아니다. 물론 낮은 울타리들은 분명 존재한다. 하지만 필요한 경우 언제든 넘어갈 수 있다. 비록 이러한 낮은 울타리들이 우리게 익숙한 ‘벽돌담’ 보다 ‘불완전한 것’으로 간주되곤 했지만, 실제로는 관련된 모든 사람들에게 더 나은 결과로 이어지고 있다.