GitHub가 오픈소스를 플랫폼으로 만든 사건 : 코드 저장소가 아니라 개발자의 SNS

GitHub 이전의 세계 — 오픈소스는 왜 어려웠는가

GitHub가 등장하기 이전의 오픈소스 세계는 지금 우리가 익숙하게 생각하는 모습과는 상당히 달랐다. 오늘날 개발자는 브라우저에서 몇 번의 클릭만으로 프로젝트를 탐색하고, 코드를 수정하고, Pull Request를 보내며 협업에 참여할 수 있다. 하지만 2000년대 초반까지 오픈소스 프로젝트에 기여하는 과정은 훨씬 더 복잡하고 폐쇄적인 구조를 가지고 있었다. 코드 자체는 공개되어 있었지만, 그 코드에 참여하는 과정은 결코 열려 있지 않았다. 이 모순적인 구조는 오픈소스의 확산을 가로막는 가장 큰 장벽 중 하나였다.

당시 개발자들은 주로 메일링 리스트를 통해 협업을 진행했다. 프로젝트에 기여하려면 먼저 코드를 수정한 뒤 patch 파일을 생성하고, 이를 메일로 전송해야 했다. 이후 프로젝트 유지관리자가 해당 patch를 검토하고 직접 코드에 반영하는 방식이었다. 이 과정은 단순히 기술적인 작업만 요구하지 않았다. 프로젝트의 규칙, 커뮤니케이션 방식, 그리고 때로는 암묵적인 문화까지 이해해야 했다. 즉, 코드를 잘 작성하는 것만으로는 부족했고, 그 프로젝트의 내부 문화에 적응해야만 기여가 가능했다.

문제는 이러한 구조가 자연스럽게 진입 장벽을 만들어냈다는 점이다. 처음 참여하려는 개발자에게 메일링 리스트는 낯설고 어렵게 느껴졌고, patch 기반 협업은 직관적이지 않았다. 또한 코드 변경 과정이 공개적으로 구조화되어 있지 않았기 때문에, 다른 사람이 무엇을 하고 있는지 파악하기도 쉽지 않았다. 결과적으로 많은 오픈소스 프로젝트는 소수의 핵심 개발자 중심으로 운영되는 구조를 유지할 수밖에 없었다.

이 시기의 협업 환경은 도구 또한 분산되어 있었다. 코드 저장소는 CVS나 Subversion에 있었고, 이슈 관리는 Bugzilla 같은 별도의 시스템에서 이루어졌으며, 토론은 메일링 리스트에서 진행되었다. 하나의 변경 사항을 이해하기 위해서는 여러 시스템을 오가야 했고, 이는 협업의 흐름을 단절시키는 요인이 되었다. 결국 오픈소스는 공개되어 있었지만, 실제로는 참여하기 어려운 반개방적 시스템에 가까웠다.

이러한 구조는 오픈소스가 성장하는 데 일정한 역할을 했지만, 동시에 한계를 명확하게 드러냈다. 코드가 공개된다는 것과 누구나 쉽게 참여할 수 있다는 것은 전혀 다른 문제였다. 그리고 바로 이 지점에서 하나의 질문이 자연스럽게 등장한다. 코드는 열려 있는데, 왜 협업은 여전히 닫혀 있는가. 이 질문은 이후 Git과 GitHub가 등장하게 되는 중요한 배경이 된다.

Git은 있었지만 협업은 여전히 어려웠다

이러한 문제를 해결하기 위한 시도 중 하나가 바로 Git의 등장이다. Git은 기존의 중앙집중형 버전관리 시스템과는 완전히 다른 접근 방식을 제시했다. 각 개발자가 전체 저장소를 가지고 작업할 수 있고, 브랜치를 자유롭게 생성하고 병합할 수 있는 구조는 당시로서는 매우 혁신적인 개념이었다. 특히 Linux 커널 개발 과정에서 드러난 협업 문제를 해결하기 위해 만들어졌다는 점에서, Git은 협업을 위한 기술적 기반을 제공하는 도구로 평가할 수 있다.

Git의 가장 큰 특징은 분산형 구조였다. 중앙 서버에 의존하지 않고도 개발이 가능했고, 오프라인 상태에서도 모든 작업을 수행할 수 있었다. 또한 브랜치를 매우 가볍게 생성할 수 있었기 때문에, 다양한 실험과 병렬 작업이 가능해졌다. 이론적으로는 협업이 훨씬 더 유연해지고 확장 가능한 구조가 마련된 것이다. 하지만 현실은 조금 달랐다. Git은 강력했지만, 그 강력함은 사용자에게 복잡함으로 다가왔다.

Git은 명령어 기반 도구였고, 초기에는 사용하기가 쉽지 않았다. commit, rebase, merge 같은 개념은 직관적이지 않았고, 충돌 해결 과정도 상당한 이해를 요구했다. 더 중요한 문제는 Git 자체에는 협업을 위한 인터페이스가 부족했다는 점이다. Git은 어디까지나 버전관리 도구였을 뿐, 협업 과정을 시각적으로 보여주거나 토론을 지원하는 기능은 제공하지 않았다. 즉, Git은 협업을 가능하게 했지만, 협업을 쉽게 만들어주지는 않았다.

결국 Git을 사용하더라도 여전히 메일링 리스트와 patch 기반 협업이 유지되는 경우가 많았다. Git 저장소는 존재했지만, 코드 리뷰와 커뮤니케이션은 여전히 기존 방식에 의존했다. 이는 Git이 해결하지 못한 영역이 분명히 존재한다는 것을 의미한다. 기술적인 기반은 마련되었지만, 사람들이 협업하는 방식 자체는 아직 변화하지 않았다.

이 시점에서 중요한 전환점이 필요했다. 단순히 버전관리 기술이 아니라, 협업 자체를 재구성할 수 있는 새로운 접근 방식이 요구되었다. Git이 만든 기반 위에서, 그 위에 올라갈 새로운 협업 레이어가 필요했던 것이다. 그리고 바로 그 역할을 수행한 것이 GitHub였다.

GitHub의 등장 — 단순한 호스팅 서비스가 아니었다

2008년 등장한 GitHub는 처음에는 단순한 Git 저장소 호스팅 서비스처럼 보였다. 하지만 실제로는 그보다 훨씬 더 중요한 변화를 담고 있었다. GitHub는 Git이라는 도구 위에 협업을 위한 인터페이스와 경험을 얹은 서비스였다. 즉, Git의 복잡함을 감추고, 협업 과정을 직관적으로 만들기 위한 시도였다.

GitHub의 핵심은 코드 자체가 아니라 코드를 둘러싼 상호작용이었다. 누가 어떤 변경을 했는지, 그 변경이 어떤 맥락에서 이루어졌는지, 그리고 그 변경에 대해 어떤 논의가 있었는지를 하나의 공간에서 확인할 수 있었다. 기존에는 코드, 이슈, 토론이 각각 분리되어 있었지만, GitHub는 이를 하나로 통합했다. 이 변화는 단순한 편의성 개선이 아니라, 협업 구조 자체를 재정의하는 변화였다.

또한 GitHub는 웹 기반 인터페이스를 통해 Git을 훨씬 쉽게 사용할 수 있게 만들었다. 복잡한 명령어를 알지 못해도 브라우저에서 코드 변경을 확인하고, 비교하고, 리뷰할 수 있었다. 이는 Git의 진입 장벽을 크게 낮추는 역할을 했다. 더 이상 Git은 일부 숙련된 개발자만 사용하는 도구가 아니라, 누구나 접근할 수 있는 협업 도구로 확장되기 시작했다.

GitHub가 기존 서비스와 결정적으로 달랐던 점은 협업을 “기능”이 아니라 “경험”으로 만들었다는 것이다. 단순히 코드를 올리고 내려받는 것이 아니라, 그 위에서 사람들이 소통하고 협력하는 구조를 제공했다. 이 구조는 이후 Pull Request, Fork, Social Coding 같은 개념으로 확장되며, 오픈소스 생태계를 완전히 바꾸게 된다.

GitHub의 등장은 단순한 서비스 하나의 출현이 아니었다. 그것은 오픈소스 협업의 방식을 근본적으로 재구성하는 출발점이었다. 그리고 이제 그 변화는, 단순히 코드를 공유하는 수준을 넘어 코드를 중심으로 한 새로운 협업 문화로 이어지기 시작한다.

Pull Request — 코드 리뷰를 표준으로 만든 기능

GitHub가 만들어낸 가장 결정적인 변화 중 하나는 바로 Pull Request라는 개념의 정착이었다. 이전까지 코드 변경은 patch 파일을 만들어 전달하거나, 저장소 접근 권한을 가진 일부 개발자만 직접 반영하는 방식으로 이루어졌다. 이 구조에서는 코드 리뷰가 체계적으로 이루어지기 어려웠고, 변경 사항에 대한 논의 또한 단편적으로 흩어지기 쉬웠다. 그러나 Pull Request는 코드 변경을 하나의 명확한 단위로 묶고, 그 위에 토론과 리뷰를 자연스럽게 얹을 수 있는 구조를 제공했다. 이 변화는 단순히 기능 하나의 추가가 아니라, 코드 협업의 기본 단위를 재정의한 사건이었다.

Pull Request의 핵심은 변경 사항을 “보여주는 것”과 동시에 “논의할 수 있게 만드는 것”이었다. 어떤 코드가 추가되었고, 어떤 코드가 삭제되었는지를 시각적으로 비교할 수 있었으며, 특정 라인에 직접 코멘트를 달 수 있었다. 이는 코드 리뷰를 추상적인 개념에서 구체적인 인터랙션으로 끌어내린 변화였다. 이전에는 리뷰가 메일이나 문서 형태로 이루어졌다면, 이제는 코드 자체를 중심으로 한 대화가 가능해졌다. 이 구조는 자연스럽게 리뷰의 품질을 높였고, 동시에 협업의 속도 또한 개선했다.

더 중요한 변화는 Pull Request가 협업을 “과정”으로 드러내기 시작했다는 점이다. 어떤 기능이 어떻게 추가되었고, 그 과정에서 어떤 논의가 있었는지 모든 기록이 남았다. 이는 단순한 변경 이력 이상의 의미를 가지며, 프로젝트의 맥락을 이해하는 데 중요한 자산이 되었다. 결국 Pull Request는 코드 리뷰를 단순한 검토 과정이 아니라, 협업과 학습이 동시에 이루어지는 구조로 바꾸었다.

이러한 변화는 점점 더 많은 프로젝트에서 Pull Request를 표준 협업 방식으로 채택하게 만들었다. 이제 코드를 작성하는 것만큼이나 중요한 것은, 그 코드를 어떻게 공유하고 검토하는가였다. Pull Request는 바로 그 질문에 대한 가장 직관적인 답이었고, 이후 오픈소스뿐 아니라 기업 내부 개발 프로세스에도 깊이 자리 잡게 된다.

Fork 버튼 — 참여의 장벽을 무너뜨린 순간

Pull Request가 협업의 방식을 바꾸었다면, Fork 버튼은 협업의 진입 자체를 바꾸었다. GitHub 이전에도 코드를 복제하고 수정하는 것은 가능했지만, 그 과정은 명확하게 구조화되어 있지 않았고 심리적인 장벽 또한 존재했다. 특히 원본 프로젝트에 직접 영향을 줄 수 있다는 부담은 많은 개발자들에게 기여를 망설이게 만드는 요소였다. 하지만 Fork는 이 문제를 단순하면서도 강력하게 해결했다. 버튼 하나로 프로젝트 전체를 자신의 저장소로 복제할 수 있었고, 그 이후의 모든 작업은 완전히 독립적으로 이루어졌다.

이 구조는 개발자에게 중요한 자유를 제공했다. 원본 프로젝트를 건드리지 않고도 새로운 아이디어를 실험할 수 있었고, 실패에 대한 부담 없이 다양한 시도를 할 수 있었다. 이러한 환경은 자연스럽게 더 많은 참여를 유도했다. 이전에는 기여를 위해 프로젝트의 규칙과 문화에 적응해야 했다면, 이제는 자신의 방식으로 먼저 시도하고, 이후에 공유하는 방식이 가능해졌다. 이는 오픈소스 참여의 패러다임을 근본적으로 바꾸는 변화였다.

Fork의 또 다른 중요한 의미는 프로젝트의 분화를 가능하게 했다는 점이다. 하나의 프로젝트가 여러 방향으로 발전할 수 있었고, 때로는 완전히 새로운 프로젝트로 이어지기도 했다. 이는 단순한 코드 복제가 아니라, 생태계 확장의 메커니즘으로 작동했다. MySQL에서 파생된 MariaDB나 OpenOffice에서 갈라진 LibreOffice 같은 사례는 이러한 구조가 어떤 결과를 만들어낼 수 있는지를 보여준다.

결국 Fork 버튼은 기술적인 기능을 넘어, 개발자에게 심리적 안전을 제공하는 장치였다. 누구나 쉽게 시작할 수 있고, 실패해도 문제가 되지 않는 환경은 참여를 폭발적으로 증가시켰다. 그리고 이 변화는 오픈소스가 소수의 영역에서 벗어나, 대규모 참여형 생태계로 확장되는 결정적 계기가 되었다.

Social Coding — 개발이 공개 네트워크가 된 순간

GitHub가 만들어낸 또 하나의 근본적인 변화는 개발을 사회적 활동으로 전환시켰다는 점이다. 이전까지 개발은 주로 개인 혹은 소규모 팀 단위로 이루어지는 작업이었고, 그 과정은 외부에 잘 드러나지 않았다. 물론 오픈소스 프로젝트는 공개되어 있었지만, 그 내부의 활동이 실시간으로 공유되거나 네트워크 형태로 연결되지는 않았다. GitHub는 이러한 구조를 완전히 뒤집었다. 코드 작성과 협업 과정이 모두 공개되었고, 개발자들은 서로의 활동을 실시간으로 확인할 수 있게 되었다.

GitHub에서는 단순히 코드를 올리는 것 이상의 다양한 상호작용이 가능했다. 다른 개발자의 프로젝트를 “Star”로 표시하고, 관심 있는 개발자를 “Follow”하며, 활동 피드를 통해 변화 과정을 추적할 수 있었다. 이러한 기능은 개발을 하나의 콘텐츠로 만들었고, 개발자는 그 콘텐츠를 통해 자신의 역량을 드러낼 수 있었다. 이는 개발을 더 이상 폐쇄적인 작업이 아니라, 공개되고 연결된 네트워크 활동으로 변화시키는 계기가 되었다.

이러한 변화는 개발자의 정체성에도 영향을 미쳤다. GitHub 프로필은 단순한 계정이 아니라, 개발자의 활동 기록이자 포트폴리오가 되었다. 어떤 프로젝트에 기여했는지, 어떤 코드를 작성했는지, 어떤 문제를 해결했는지가 모두 공개되었고, 이는 개발자의 실력을 평가하는 중요한 기준으로 작용하기 시작했다. 기업 또한 GitHub 활동을 통해 개발자를 평가하는 사례가 늘어나면서, GitHub는 사실상 개발자의 경력을 증명하는 플랫폼으로 자리 잡았다.

결국 Social Coding은 단순한 기능의 집합이 아니라, 개발을 바라보는 관점 자체를 바꾸었다. 코드는 더 이상 개인의 산출물이 아니라, 공유되고 확장되는 네트워크의 일부가 되었다. 그리고 이러한 변화는 GitHub를 단순한 도구가 아니라, 개발 생태계의 중심 플랫폼으로 성장하게 만드는 기반이 된다.

GitHub는 왜 플랫폼이 되었는가

Pull Request와 Fork, 그리고 Social Coding이라는 흐름이 하나로 결합되면서 GitHub는 단순한 코드 저장소의 역할을 넘어가기 시작했다. 처음에는 Git을 편하게 사용할 수 있는 호스팅 서비스로 출발했지만, 점점 더 많은 프로젝트와 개발자가 모이면서 GitHub는 자연스럽게 개발 생태계의 중심점으로 이동했다. 이 변화는 의도적으로 설계된 것이라기보다는, 기능과 사용자가 서로를 끌어당기며 만들어낸 결과였다. 코드가 있는 곳에 사람이 모였고, 사람이 모인 곳에 다시 더 많은 코드가 쌓였다.

이러한 구조는 전형적인 플랫폼의 성장 방식과 유사하다. GitHub는 단순히 코드를 저장하는 공간이 아니라, 코드를 중심으로 상호작용이 발생하는 공간이 되었다. 개발자는 프로젝트를 올리고, 다른 개발자는 그것을 Fork하고, Pull Request를 보내며 협업한다. 이 과정에서 코드뿐 아니라 지식과 경험이 함께 공유된다. 결국 GitHub는 “코드의 저장소”가 아니라, 코드를 매개로 한 네트워크 플랫폼으로 진화하게 된다.

GitHub가 플랫폼이 된 또 다른 이유는 확장성에 있다. GitHub 위에서는 단순한 라이브러리뿐 아니라 프레임워크, 운영체제, 심지어 전체 인프라 수준의 프로젝트까지 운영될 수 있었다. React, Kubernetes, TensorFlow와 같은 프로젝트는 GitHub를 기반으로 빠르게 성장했고, 전 세계 개발자들이 동시에 참여하는 구조를 만들었다. 이는 특정 기업이나 조직이 아닌, 글로벌 협업 네트워크 위에서 기술이 발전하는 구조를 가능하게 했다.

결국 GitHub는 단순한 서비스가 아니라, 개발자와 프로젝트를 연결하는 플랫폼 레이어가 되었다. 그리고 이 플랫폼 위에서 수많은 기술이 탄생하고 확산되면서, GitHub는 사실상 현대 소프트웨어 생태계의 핵심 인프라로 자리 잡게 된다.

개발자의 포트폴리오가 GitHub로 이동한 이유

GitHub의 확장은 단순히 프로젝트 협업 방식에만 영향을 준 것이 아니었다. 그것은 개발자 개인의 경력과 정체성에도 직접적인 변화를 가져왔다. 과거에는 개발자의 실력을 평가하기 위해 이력서와 면접이 주요 수단이었다. 그러나 GitHub가 등장한 이후, 개발자는 자신의 코드를 공개하고, 그 코드가 실제로 어떻게 사용되고 있는지를 보여줄 수 있게 되었다. 이는 개발자의 능력을 보다 객관적으로 드러낼 수 있는 새로운 방식이었다.

GitHub 프로필은 단순한 계정이 아니라, 개발자의 활동 기록이 축적된 공간이 되었다. 어떤 프로젝트에 기여했는지, 얼마나 지속적으로 활동했는지, 어떤 문제를 해결했는지가 모두 공개적으로 드러났다. 이 과정에서 개발자는 단순히 “무엇을 할 수 있는 사람”이 아니라, 실제로 무엇을 만들어온 사람인지로 평가받기 시작했다. 이는 개발자의 평가 기준을 근본적으로 바꾸는 변화였다.

또한 GitHub는 개발자 간의 연결을 강화했다. 다른 개발자의 코드를 보고 배우거나, 직접 기여를 통해 관계를 형성하는 것이 가능해졌다. 이러한 구조는 개발자의 성장을 개인적인 경험에 의존하는 것이 아니라, 네트워크를 통해 확장되는 과정으로 변화시켰다. GitHub는 단순한 협업 도구를 넘어, 개발자의 커리어를 형성하는 플랫폼으로 자리 잡게 된다.

이러한 변화는 기업의 채용 방식에도 영향을 미쳤다. 많은 기업이 GitHub 활동을 참고하여 개발자를 평가하기 시작했고, 오픈소스 기여 경험은 중요한 이력으로 인정받게 되었다. 결국 GitHub는 개발자의 커리어와 평가 구조를 재편하며, 개발자라는 직업의 의미 자체를 확장시킨 플랫폼이 되었다.

GitHub 이후 — 오픈소스는 어떻게 달라졌는가

GitHub의 등장은 오픈소스 생태계 전체의 변화를 가속화했다. 이전까지 오픈소스 프로젝트는 제한된 참여 구조를 가지고 있었지만, GitHub 이후에는 누구나 쉽게 참여할 수 있는 환경이 만들어졌다. 이 변화는 단순히 참여자의 수가 늘어난 것을 넘어, 프로젝트의 성장 방식 자체를 바꾸었다. 더 많은 사람이 더 빠르게 기여할 수 있게 되면서, 기술의 발전 속도 또한 눈에 띄게 빨라졌다.

또한 오픈소스 프로젝트는 더 이상 특정 조직이나 커뮤니티에 종속되지 않게 되었다. GitHub 위에서 프로젝트는 독립적인 존재로 운영될 수 있었고, 전 세계 개발자가 동시에 참여하는 구조가 가능해졌다. 이는 기술이 특정 기업의 내부 자산이 아니라, 글로벌 협업을 통해 발전하는 공공 자산으로 변화하는 흐름을 만들어냈다. GitHub는 이 흐름을 가능하게 만든 핵심 인프라였다.

이와 함께 오픈소스의 역할도 확장되었다. 단순히 무료로 사용할 수 있는 코드가 아니라, 새로운 기술이 실험되고 검증되는 공간이 되었다. 스타트업과 대기업 모두 GitHub를 통해 기술을 공개하고, 커뮤니티와 함께 발전시키는 방식을 선택하게 되었다. 이는 기술 개발의 중심이 기업 내부에서 외부로 확장되는 것을 의미한다.

결국 GitHub 이후의 오픈소스는 단순한 개발 방식이 아니라, 하나의 문화이자 산업 구조로 자리 잡게 된다. 그리고 이러한 변화는 다음 단계로 이어진다. 개발자는 더 이상 혼자 코드를 작성하는 존재가 아니라, 플랫폼 위에서 협업하고 성장하는 네트워크의 구성원이 된다. 이 흐름은 이어지는 이야기에서 더욱 분명해진다.

결론 — GitHub는 도구가 아니라 개발 문화를 바꾼 사건이었다

지금까지의 흐름을 따라오면 하나의 공통된 패턴이 보이기 시작한다. GitHub는 새로운 프로그래밍 언어를 만든 것도 아니고, 기존에 존재하지 않던 완전히 새로운 기술을 발명한 것도 아니었다. Git이라는 강력한 버전관리 도구는 이미 존재했고, 오픈소스라는 개념 또한 오래전부터 이어져 오고 있었다. 그럼에도 불구하고 GitHub는 “사건”이라고 불릴 만큼의 변화를 만들어냈다. 그 이유는 GitHub가 기술을 바꾼 것이 아니라, 기술 위에서 사람들이 협업하는 방식 자체를 재구성했기 때문이다.

GitHub 이전에도 코드는 공유되고 있었지만, 그 공유는 제한적이고 불완전한 형태였다. 참여는 어려웠고, 협업은 단편적이었으며, 기록은 분산되어 있었다. 그러나 GitHub는 이 모든 과정을 하나의 흐름으로 연결했다. 코드 작성, 변경, 리뷰, 토론, 그리고 배포까지 이어지는 과정이 하나의 플랫폼 위에서 자연스럽게 이어지기 시작했다. 이 변화는 단순히 편리함을 넘어, 개발이라는 행위의 구조 자체를 바꾸는 변화였다. 이제 개발은 개인의 작업이 아니라, 플랫폼 위에서 이루어지는 협업 프로세스로 재정의되었다.

또한 GitHub는 개발을 “보여지는 활동”으로 만들었다. 코드와 커밋, 리뷰와 토론이 모두 공개되면서, 개발자는 더 이상 보이지 않는 곳에서 작업하는 존재가 아니게 되었다. GitHub 프로필과 활동 기록은 개발자의 정체성을 형성하는 요소가 되었고, 이는 곧 커리어와 연결되었다. 이처럼 GitHub는 단순한 협업 도구를 넘어, 개발자라는 직업의 사회적 구조까지 변화시키는 플랫폼으로 작동했다. 기술이 아니라 사람을 중심으로 변화가 일어났다는 점에서, GitHub의 영향력은 더욱 깊고 넓게 확장되었다.

결국 GitHub가 만든 가장 중요한 변화는 “누구나 참여할 수 있는 개발 환경”이었다. Fork와 Pull Request를 통해 기여의 장벽은 낮아졌고, Social Coding을 통해 개발자는 서로 연결되었다. 이 구조는 오픈소스를 단순한 코드 공유 방식에서, 글로벌 협업 생태계로 확장시키는 기반이 되었다. 그리고 이 생태계는 지금도 계속 확장되고 있으며, 새로운 기술과 프로젝트가 그 위에서 탄생하고 있다.

이제 개발은 특정 조직이나 기업의 내부에서만 이루어지는 활동이 아니다. GitHub와 같은 플랫폼 위에서, 전 세계 개발자가 동시에 협업하며 기술을 만들어간다. 이 변화는 단순한 도구의 진화가 아니라, 개발이라는 행위 자체가 네트워크 중심으로 이동한 사건이었다. 그리고 이러한 흐름은 여기서 멈추지 않는다. 다음 장에서는 또 다른 중요한 변화가 등장한다. 코드 자체보다 “지식”이 중심이 되는 순간, 개발 문화는 다시 한 번 재편되기 시작한다.