GitHub에도 피드(Feed)의 시대가 오고 있다

Reels/Shorts가 주류가 되기 전, 소셜 미디어에 대한 일반적인 합의는 해자(Moat)가 네트워크 효과(친구 그래프)에 있다는 것이었습니다. Facebook의 가치는 당신의 친구들이 그곳에 있다는 점이었고, 모든 프로필에 걸쳐 있는 '친구의 친구' 데이터는 누구도 대체할 수 없다고 생각했던 자산이었습니다. 당신은 앱을 열고 사람들의 프로필, 담벼락, 즉 네트워크로 이동했습니다.

그 후 피드(Feed, 알고리즘)가 등장했습니다. 처음에는 그래프 위에 얹어진 편의 계층으로 시작되었습니다. 오늘 무슨 일이 일어났는지, 무엇이 트렌드인지, 사람들이 무엇에 대해 게시물을 올리고 있는지를 한곳에서 보여주는 식이었죠. 하지만 몇 년에 걸쳐 그 관계가 역전되었습니다. 알고리즘이 제품이 되었고, 그래프는 알고리즘이 당신에게 무엇을 보여줄지 결정하기 위해 사용하는 여러 입력값 중 하나가 되었습니다. 그래프가 사라진 것은 아닙. 단지 가치가 머무는 곳이 아니게 되었을 뿐입니다. 당신의 프로필, 친구, 좋아요, 게시물, 댓글은 이제 내부 API 계층에서 소비됩니다. 알고리즘이 그들의 고객인 셈입니다.

많은 이들이 글을 쓰고 있듯이, 이러한 현상은 모두가 영구적이라고 가정했던 시스템들에서도 계속해서 일어나고 있습니다. 기업 환경에서 가장 명확한 사례는 CRM입니다. Salesforce와 HubSpot은 데이터베이스를 소유했기 때문에 승리했습니다. 모든 통화 기록, 모든 연락처, 거래가 지연된 모든 이유가 한곳에 저장되었고, 이를 떠나는 비용은 매년 높아졌습니다. 그 점은 변하지 않았습니다. 변한 것은 이제 그 위에 에이전트(Agent) 계층이 자리 잡았다는 것입니다. 통화 전에 영업 사원에게 브리핑을 해주는 리서치 봇, 회의 내용을 듣고 구조화된 노트를 CRM에 다시 작성하는 도구, 영업 사원이 무엇을 먼저 봐야 할지 결정하는 오케스트레이션 계층(Orchestration layer) 등이 등장했습니다. CRM이 죽은 것이 아닙니다. 영업 사원이 아침에 실제로 여는 서비스의 입력값이 된 것입니다.

저는 GitHub가 그다음 차례라고 생각합니다.

[

]

GitHub가 승리했던 이유

GitHub는 코드의 기록 시스템 (system of record)입니다. GitHub는 15년 이상 명백하고 논쟁의 여지가 없는 정답이었으며, 그 이유는 CRM을 고착화 (sticky) 시켰던 이유와 동일합니다. 코드가 그곳에 살고 있습니다. 풀 리퀘스트 (pull requests), 이슈 (issues), 리뷰 이력 (review history), CI 실행 (CI runs), CODEOWNERS 파일도 마찬가지입니다. 즉, 코드베이스가 어떻게 형성되었는지에 대한 수년간 축적된 운영 컨텍스트 (operational context)가 그곳에 있습니다. 오픈 소스 (Open source)가 GitHub를 점령했고, 이는 다른 모든 사람들을 끌어들였습니다. Microsoft는 2018년에 GitHub를 75억 달러에 인수했습니다. 전 세계의 코드가 살아있는 곳을 소유하는 것은 소프트웨어 분야에서 가장 위대한 프랜차이즈 중 하나이기 때문입니다.

그리고 GitHub는 모든 지배적인 플랫폼이 하는 일을 했습니다. 바로 데이터베이스로부터 외부로 확장하는 것입니다. Actions, Packages, Codespaces, Advanced Security; 각각의 새로운 모듈은 동일한 중추 (spine) 위에 구축되었으며, 각각은 이탈 비용 (cost of leaving)을 높였습니다. 마켓플레이스 (marketplace)의 모든 도구는 사실상 GitHub의 데이터에 연결할 수 있는 권리를 위해 임대료를 지불하고 있는 셈입니다.

데이터베이스가 승리한 이유는 명확하게 말할 가치가 있습니다. 코드는 한 곳에 머물러야 했습니다. 왜냐하면 그 코드를 작업하는 인간은 한 번에 한 곳만 볼 수 있었기 때문입니다. 집중 (Concentration)은 하나의 기능이었습니다. 중력은 축적 (accumulation)에서 나왔습니다.

사용자가 에이전트 (agent)가 될 때 변하는 것

그 전제는 깨지고 있습니다. 코드를 작업하는 주체는 점점 더 한 번에 한 곳만 볼 수 있는 인간이 아니게 되고 있습니다. 그것은 동시에 모든 곳을 볼 수 있는 에이전트 (agent)입니다.

코딩 에이전트에게 GitHub는 데이터베이스입니다. 매우 훌륭한 데이터베이스입니다. 신뢰할 수 있고, 잘 통합되어 있으며, 10년 치의 컨텍스트를 가지고 있지만, 결국 데이터베이스일 뿐입니다. 에이전트에게는 PR 리뷰 UI, 이슈 보드, 머지 큐 (merge-queue) 인터페이스가 필요하지 않습니다. 에이전트에게 필요한 것은 낮은 마찰 (low friction)으로 읽고 쓸 수 있는 구조화된 상태 (structured state)입니다. 그 위에 정교하게 설계된 인간의 워크플로 (workflows)는 피드 (feed)가 등장한 이후의 오래된 프로필 페이지가 된 것과 같습니다. 여전히 존재하지만, 더 이상 핵심은 아닙니다.

그리고 에이전트 (Agent)는 GitHub, 이슈 트래커 (Issue tracker), Slack, 디자인 파일, CI 로그, 그리고 프로덕션 텔레메트리 (Production telemetry)로부터 동시에 정보를 가져온 뒤, 아무것도 수행하기 전에 이 모든 것을 가로질러 추론 (Reasoning)하는 데 아무런 어려움이 없습니다. 인간의 시대에는 데이터가 있는 곳에 가치가 모였습니다. 에이전트의 시대에는 추론이 일어나는 곳에 가치가 모입니다. 모든 소스를 읽고 무엇을 할지 결정하는 그 계층 (Layer) 말입니다. 그 계층은 GitHub를 인프라 (Infrastructure)로 취급합니다.

전환 비용 (Switching cost)도 그에 따라 이동합니다. "우리의 모든 코드는 GitHub에 있다"는 지난 15년 동안의 락인 (Lock-in)이었습니다. "우리의 모든 결정, 조정, 조직적 맥락은 우리의 에이전트 계층에 존재한다"는 향후 15년 동안의 락인이 될 것입니다. GitHub 역시 이를 명확히 인지하고 있으며, 이것이 바로 그들이 자체적인 장벽 안에서 지능 계층 (Intelligence layer), 이슈에서 머지 (Merge)까지 수행하는 코딩 에이전트인 Copilot, 그리고 MCP 레지스트리 (MCP registry)를 구축하기 위해 경주하고 있는 이유입니다. 이는 Salesforce가 했던 것과 동일한 움직임입니다. AI를 내부로 가져와 가치가 외부로 유출되는 것을 막는 것입니다. 그것이 그들의 장벽 안에 머물 수 있을지는 미지수입니다.

GitHub가 저장하지 않는 것

여기에 간극이 있습니다. GitHub는 결과물 (Artifacts)을 기록합니다: 디프 (Diffs), 머지된 PR (Merged PRs), 코드의 최종 상태 말입니다. 하지만 그것들을 만들어낸 결정 (Decisions)을 기록하지는 않습니다.

코드베이스를 조종하는 것은 코드가 아니라 결정입니다. "인증 (Auth)은 JWT이며, 만료 시간은 15분이다." "/login을 /session으로 이름을 변경했다." "해당 테이블에는 새로운 데이터를 쓰지 않는다." 이러한 결정들은 사람들의 머릿속에, 위로 스크롤되어 사라지는 Slack 스레드에, 작성된 지 일주일 만에 낡아버린 문서들에 존재하며—그 어떤 에이전트도 이 중 무엇도 읽지 못합니다. GitHub는 충돌하는 코드가 이미 머지된 후에야 결정이 내려졌음을 알게 됩니다. 그때는 이미 경고가 아니라 버그 (Bug)가 된 상태입니다.

둘 이상의 에이전트(Agent)가 개입하는 순간 이 문제는 심각해집니다. 두 명의 개발자가 Claude Code, Codex, 혹은 Gemini와 같은 두 개의 에이전트를 동일한 시스템에 투입한다고 가정해 봅시다. 에이전트 A가 엔드포인트(Endpoint)의 이름을 변경합니다. 에이전트 B는 이를 전혀 모른 채 기존 엔드포인트를 계속 호출하며 코드를 배포합니다. 에이전트 A가 토큰 스킴(Token scheme)을 결정하면, 에이전트 B는 다른 스킴을 만들어냅니다. 조율할 수 있는 장소가 없었기에 아무도 협력하지 않았습니다. 기록 시스템(System of record)은 코드를 보유하고 있지만, 에이전트들이 행동하기 전에 서로 동기화(Sync)될 수 있게 해주는 정보는 전혀 가지고 있지 않습니다.

이것이 가리키는 방향: Lockstep

이것이 바로 제가 구축하고 있는 레이어(Layer)입니다. Lockstep은 모든 에이전트가 어떤 작업을 수행하기 전에 읽게 되는 공유된 결정 기록(Shared decision record)입니다.

에이전트가 세션을 시작할 때 가장 먼저 받는 것은 브리핑(Briefing)입니다. '당신이 마지막으로 여기 있었을 때 이후로 변경된 사항은 이것이며, 구속력이 있는 사항은 이것입니다'라는 내용이죠. 이때 영향 범위(Blast radius)가 가장 큰 것부터 우선순위를 둡니다. 따라서 세 개의 다운스트림(Downstream) 서비스를 망가뜨리는 변경 사항은 먼저 드러나고, 단순한 외관상의 이름 변경은 뒤로 밀려납니다. 에이전트는 오직 그 후에야 코드 한 줄을 작성합니다. AGENTS.md와 같은 규칙 파일(Rules files)이나 ADR(Architecture Decision Records)과 같은 결정 문서(Decision docs)도 도움이 되지만, 이들은 한 번 작성되면 거의 읽히지 않습니다. 두 방식 모두 두 번째 에이전트가 행동하기 전에 한 에이전트의 최신 결정을 다음 에이전트에게 전달하지 못합니다.

이 설명이 익숙하게 들린다면, 당연한 결과입니다. 그 브리핑이 바로 피드(Feed)입니다. 영업 부사장(VP of Sales)이 이제 가공되지 않은 고객 명단 대신 열어보는, 우선순위가 지정된 단일 확인 지점(One-place-to-look surface)과 같습니다. 다만 사용자가 에이전트이고, 입력값이 고객이나 신호(Signals) 대신 결정 사항과 계약 변경 사항이며, 출력값이 충돌하지 않는 코드라는 점이 다를 뿐입니다. Lockstep은 어떤 MCP(Model Context Protocol) 호환 에이전트와도 함께 작동합니다. 피드가 어떤 친구가 게시물을 올렸는지 상관하지 않는 것과 마찬가지로, 조정 레이어(Coordination layer)는 어떤 벤더가 타이핑을 하고 있는지 신경 쓸 이유가 없기 때문입니다.

GitHub은 기존에 그랬던 모든 이유로 코드를 계속 유지합니다. 하지만 가치는 한 단계 위로, 즉 전체 기록을 읽고 다음에 어떤 일이 일어날지를 결정하는 요소로 이동하고 있습니다. 친구 그래프 (Friend graph)는 결코 사라진 적이 없습니다. CRM (Customer Relationship Management) 또한 어디로 가지 않습니다. GitHub 역시 마찬가지입니다. 그것들은 입력값 (Inputs)이 되어가고 있습니다.

개발자 도구 (Developer tooling)의 향후 10년은 한 단계 위에서 구축될 것입니다.