클라우드플레어 위에 차세대 Git 플랫폼을 만들어 주세요

We want you to build the next Git platform on Cloudflare

blog.cloudflare.com ▲ 160 댓글 138 geoffbp

요약

클라우드플레어가 AI 에이전트 시대에 맞는 차세대 Git 플랫폼을 공모전으로 찾습니다.

클라우드플레어의 디나 코즐로프와 제불론 피아세키가 10월 1일 블로그에 공모전을 알렸습니다. 사람이 브랜치와 풀 리퀘스트로 협업하는 기존 방식은 에이전트 수백~수천 개가 동시에 일하는 환경에 맞지 않는다고 봤습니다.

왜 중요한가

  • 지금의 GitHub에 에이전트를 얹는 것이 아니라, 여러 에이전트의 동시 작업을 전제로 협업 방식을 새로 짜자는 제안입니다.
  • 동시 변경 처리, 에이전트 맥락 보존, 대량의 에이전트 코드 검토가 새 플랫폼이 풀어야 할 과제로 제시됐습니다.
  • 공모전의 바탕이 되는 저장소 서비스 Artifacts가 오픈 베타로 나왔고, 10월 15일부터 과금이 시작됩니다.

핵심 내용

  • 1등은 크레딧 2만 5천 달러와 연사 만찬 초대를, 상위 3팀은 샌프란시스코 행사 초청을 받습니다.
  • 마감은 10월 14일이며, 5~10분 시연 영상과 MIT·Apache·BSD 라이선스의 오픈소스 코드를 내야 합니다.
  • Artifacts는 Git 명령으로 다루는 버전 관리 파일 시스템으로, 에이전트나 작업마다 저장소를 따로 만들 수 있습니다.
  • Workers 바인딩(Workers 코드에서 저장소를 직접 다루는 연결)으로 저장소를 만들고 포크할 수 있습니다.
  • 저장소 생성·푸시·삭제 이벤트를 구독할 수 있고, 데이터 저장 지역은 미국과 EU 가운데 고릅니다.

HN 반응

  • 1,250억 달러 규모 기업이 현금도 아닌 크레딧을 상금으로 건다는 비판이 많았지만, 해커톤에서 흔한 상품이라는 반론도 있었습니다.
  • 클라우드플레어가 단일 장애점이 되니 의존을 줄여야 한다는 의견에, 마땅한 대안이 없다는 반문이 나왔습니다.

댓글

30개 표시 · 전체 138개
  1. btown HN

    가끔 Google Wave를 떠올립니다. Angular도 Backbone도 나오기 전인 2009년에 발표된, 실시간 협업 캔버스의 아름다운 한 줄기 빛이었죠. 지금 생각하면 거의 20년 일찍 나왔다는 생각이 듭니다.

    https://en.wikipedia.org/wiki/Google_Wave

    https://youtu.be/v_UyVmITiYQ?t=3850

    https://www.usenix.org/legacy/event/lisa09/tech/slides/berlin.pdf

    지금 우리는 에이전트가 실시간으로 인터페이스를 만들고 곧바로 배포해 우리의 피드백을 받는 세상을 당연하게 기대합니다. 기존 SDLC 일정으로는 너무 느린 업무상 핵심 환경에서 말입니다. 그런데 그 규모에서 코드 품질을 관리하기는 점점 더 어려워지고 있습니다.

    Git의 핵심에는 동작이란 변경 불가능한 변경들이 이루는, 감사 가능한 트리라는 근본적인 발상이 있습니다. 참여자 누구든 자기 로컬 머신에서 이 순서를 재배열하고, 되감고, 리믹스해서 그 변경들의 잠정적인 조합을 보여 주고 직접 다뤄 볼 수 있습니다.

    Google Wave도 운영 변환(OT)과 연합(federation) 시스템을 갖췄다는 점에서 여러모로 비슷했습니다. 지금은 CRDT도 있고, 작업 흐름을 자동으로 병합하는 훨씬 나은 기법도 있습니다. 충돌을 똑똑하게 해결해 주는 에이전트 시스템까지 있고요!

    Wave의 밑바탕에는 사람들이 모여 단순한 채팅 인터페이스를 각자의 용도에 맞는 실시간 애플리케이션으로 키워 갈 수 있고, 그 과정이 실시간으로 일어나며, 데이터 와 동작이 모두 봇과 함께 협업 속에서 진화한다는 발상이 있었습니다. Git과 SDLC라는 더 넓은 개념이 어디로 가든, 이런 사고방식의 가장 좋은 부분을 이어받았으면 합니다.

  2. lucideer HN

    Wave 출시는 제가 구글의 엔지니어링 문화가 실제로 무엇을 만들어 내는지 다시 생각해 보게 된 계기였습니다. 저는 그때까지의 어떤 대형 혁신보다도 출시를 기다렸는데, 막상 나온 건 구현 면에서 순전히 쓰레기였습니다. 아이디어는 훌륭하고 개방적이어서 이론상 다른 누군가가 제대로 해낼 수도 있었지만, 구글이 그런 졸작을 내놓는 바람에 판 자체를 망쳐 버렸습니다.

    구글은 지금까지 엔지니어링 성과로 추앙받아 왔지만, 조금만 파고들어 보면 과잉 설계된 쓰레기라는 거대한 바다에 보석 몇 개가 떠 있는 정도입니다. k8s처럼 객관적으로 크게 성공한 오픈소스조차 지금도 "무겁고 과잉 설계되긴 했지만…"이라는 단서를 잔뜩 달고 소개됩니다. k8s를 우아하다고 하는 사람은 없습니다. 좋은 제품은 거의 다 인수한 것이고, 그중 상당수는 인수 후에 오히려 망가뜨렸습니다.

    거의 모든 대기업에 대해 같은 주장을 할 수는 있겠지만, 엔지니어링 품질에 대한 평판과 실제 사이에 이렇게 뚜렷한 간극이 있는 회사는 드물다고 생각합니다.

  3. al_borland HN

    저는 Wave를 비공개 베타로 독립 제품처럼 내놓은 것부터가 실수였다고 봅니다. 이메일을 재발명하고 싶었다면 애플이 iMessage로 한 것처럼 Gmail 안에서 했어야 합니다.

    Gmail은 지금까지처럼 다른 모든 이메일 클라이언트와 호환되는 이메일 클라이언트로 동작하면 됩니다. 다만 Gmail 사용자가 다른 Gmail 사용자(또는 여러 명)에게 메일을 보내면 그 스레드가 자동으로 Wave로 바뀌면서 Wave의 기능을 전부 쓸 수 있게 하는 겁니다. 그러면 사람들이 이미 있는 곳에 새 기능을 가져다 놓게 되고, 이메일을 Gmail로 옮길 유인도 생기고, 관리할 받은편지함이 또 하나 늘어나지도 않습니다.

    저는 이런 이유로 Wave를 엔지니어링의 실패가 아니라 사업의 실패로 봐 왔습니다.

  4. lucideer HN

    그랬다면 좋았겠지만, 맨바닥에서 시작한 프로젝트에서 그런 결과물을 내놓은 걸 보면 Gmail 안에서 했어도 UX와 디자인 면에서 질적으로 더 나빴을 거라는 의심이 강하게 듭니다. 그랬다면 Wave만이 아니라 Gmail 전체에서 사용자가 떠났을 수도 있고요. 일반 대중이 대체로 무시하고 지나간 불발탄 정도로 끝난 Wave와 달리, 대중의 반발을 샀을 겁니다.

    이상적인 세상에서는 말씀이 맞습니다. 그래도 저는 이게 엔지니어링의 실패였다고 생각합니다. 이론상 맨바닥에서 시작하는 프로젝트가 쓸 만한 것을 만들기 더 쉬워야 하는데, 결과는 끔찍한 엉망이었으니까요.

  5. toomuchtodo HN

    좋은 댓글이네요. 메타는 Muse를 출시할 수 있었는데 구글은 왜 못 했는가 하는 이야기입니다.

    메타가 Muse에서 제대로 한 것 - https://news.ycombinator.com/item?id=49946526 - 2026년 10월

  6. pjmlp HN

    AOSP 소스 코드를 여러 번 뜯어봤는데, 구글의 그 유명한 채용 과정을 통과한 최고의 엔지니어들은 대체 어디로 가는 건지 정말 궁금합니다.

    Java를 짜는 방식도 그렇고, 일부 영역의 C 스타일 C++도 그렇고, 안정 버전인데도 프리뷰 버전만큼 버그가 많은 Android Studio(안드로이드 개발자들 사이에서는 밈이 될 정도입니다)도 그렇고, 한둘이 아닙니다.

  7. switchbak HN

    Wave와 Google+의 실패가 구글의 전환점이었을지도 모릅니다. 그 뒤로 구글은 예전의 영광을 되찾지 못했습니다.

  8. goalieca HN

    Wave는 멋진 기술 시연이었고 저도 기대했습니다. 소개 영상은 마케팅으로도 탄탄했고요. 다만 저와 연구실 동료들은 이게 어떤 쓰임새를 해결하는 건지 도무지 알 수 없었습니다.

    Google+는 그야말로 쓰레기를 억지로 목구멍에 쑤셔 넣는 격이었습니다. 구글이 달라졌다는 아주 큰 신호였죠.

  9. lucideer HN

    Wave는 말 그대로 현대판 이메일이었습니다. 개념상 그 이상은 없어요. 이메일과 기본적으로 같은 필요를 채워 주는 새 프로토콜이면서, 우리가 이메일 위에 어설프게 덧붙여 왔거나 지금까지도 없는 기능들을 제대로 담을 여지를 남겨 뒀습니다. 제대로 된 스레딩, 추적 가능한 메시지 수정, MIME 꼼수가 아닌 리치 메시징과 멀티미디어 지원, 개선된 보안 같은 것들이요.

    Wave의 문제는 어쩌면 부차적인 데도 있었던 것 같습니다. 무슨 새로운 마법인 양 홍보했는데, 알고 보면 그냥 이메일 2.0이었기 때문에 못 하나를 찾아 헤매는 망치 같은 인상만 남겼습니다.

  10. vrc HN

    구글은 100일 안에 페이스북을 이기겠다고 호기롭게 선언하고, 소셜 문제를 해결하는 시늉만 해도 닥치는 대로 스타트업을 인수했습니다. 모든 팀이 G+ OKR을 하나씩 받았고요. 그러면서 구글답게 자기들이 가진 유일한 소셜 플랫폼 Orkut을 갈아 없앴고, AIM의 빈자리를 채우던 gChat도 거기에 흡수되면서 선두를 날려 버렸습니다. 잘 되고 제대로 돌아가던 화상 채팅에는 투자를 충분히 하지 않고, 대신 팀마다 똑같은 걸 새 버전으로 계속 내놓았습니다. GCP와 AI/Vertex/뭐시기 하는 이름 수프를 보면 달라진 게 별로 없어 보입니다.

  11. reilly3000 HN

    안드로이드 대신 Wave에 집중했다면 어땠을까요. 어쩌면 지금도 윈도 폰이 있었을지 모릅니다. 시간의 흐름이란 게 그런 거겠죠. 지금의 악성 영광이 재정적으로는 그때를 압도하겠지만, 낭만 면에서는 영영 따라가지 못할 거라고 봅니다.

  12. pjmlp HN

    윈도 폰을 잃은 건 안타깝게도 마이크로소프트 스스로 자초한 일입니다.

    모든 걸 접을 때만 해도 유럽 점유율이 10% 정도였습니다.

    아이폰을 살 형편이 안 되고 그렇다고 안드로이드는 쓰고 싶지 않은 사람들에게는 대안이었죠.

    그런데 윈도 7에서 8.0으로 넘어갈 때 개발자에게는 완전히 새로 시작하는 일이었고, 8.0에서 8.1도 또 한 번 갈아엎었고, 8.1에서 10도 마찬가지였습니다. 그러니 당연히 아무도 앱 품질에 신경 쓰지 않았습니다.

  13. stackghost HN

    대부분의 테크 유니콘이 이렇습니다. 저커버그는 병 속에 번개를 가둔 일을 딱 한 번 해냈고, 그 뒤로 직접 해 본 건 전부 별로였습니다. 인스타그램은 인수한 거고, Oculus와 WhatsApp도 그렇습니다. 그에 비해 자체 개발한 그다음 주력 상품은 짝퉁 Wii 아바타였고요.

    아마존은 Kindle 이후로 혁신적인 걸 만든 적이 없습니다.

    상장사라서 이런 회사들이 좋은 신제품을 개발하지 못하고 경쟁사를 인수하거나 과거의 성공을 되풀이하게 되는 거겠죠, 분명.

  14. riffraff HN

    상장사라서 그렇게 된다는 건 무슨 근거로요? 애플은 소유가 페이스북이나 구글보다 덜 집중돼 있는데도 새로운 제품을 훨씬 잘 만들어 왔잖아요.

  15. al_borland HN

    가진 게 없을 때는 위험이 싸게 먹힙니다. 일단 성공하고 나면 전략이 성장에서 방어로 옮겨 가기 마련이죠.

  16. david38 HN

    진심으로 하는 말씀이세요? AWS는 복잡도나 영향력 면에서 Kindle을 압도합니다. 기본 AWS는 2006년에 시작했고 Kindle은 2007년입니다.

    AWS 산하 제품 중에는 사회에 더 큰 영향을 주고 아마존에 더 큰 수익을 안겨 주는 것이 헤아릴 수 없이 많습니다.

  17. ceejayoz HN

    그런데 쓰인 단어는 "혁신적"이었잖아요.

  18. thayne HN

    구글이 지금 Wave를 내놓는다면 아무도 신경 쓰지 않을 겁니다. 아마 2년 안에 버려지고, 5년 안에 확실히 죽는다는 걸 다들 아니까요.

  19. arianvanp HN

    Zed의 Delta를 비공개 알파 때 써 봤는데, 제일 먼저 든 느낌이 "와, Google Wave 생각나네"였습니다.

  20. Dma54rhs HN

    놀라운 건 그때의 Wave가, 알파든 베타든 당시 상태 그대로, 저한테는 엔지니어링의 경이였는데, 지금은 AI 덕분에 하루 이틀이면 제가 출시할 수 있을 것 같다는 거예요.

  21. 0x696C6961 HN

    아뇨, 못 하실걸요.

  22. Animats HN

    우리는 클라우드플레어에 대한 의존을 늘리는 게 아니라 줄이고 싶습니다.

    기술적 장애에서든 정치적 장애에서든 단일 장애점이니까요.

  23. ivanjermakov HN

    클라우드플레어는 얻을 수 있는 모든 의존을 자기들한테 끌어오고 싶어 하거든요.

  24. bartread HN

    두 분 말씀에 다 동의합니다.

  25. iugtmkbdfil834 HN

    저도 그렇습니다. 그런데 진짜 문제는 방법이에요. 지금 그들이 내놓는 것들은 우리가 처한 환경에서 정말 쓸모가 있잖아요? 클라우드플레어 덕분에 비교적 수월해진 일들을 대신할 마땅한 대안이나 완화책 없이, 의존을 줄이는 걸 대체 어떻게 시작할 수 있을까요?

  26. gonzalohm HN

    클라우드플레어 없이 서비스를 구축하는 게 고통스러운 건 사실입니다. 하지만 클라우드플레어로 뭔가를 구축한 사람이라면 언젠가는 뭔가가 고장 나서든, 클라우드플레어가 본색을 드러내서든 한 번은 고생하게 될 날이 옵니다.

    그 고생을 지금 하시겠습니까, 나중에 하시겠습니까?

  27. simoncion HN

    의존을 줄이는 걸 대체 어떻게 시작할 수 있을까요...

    클라우드플레어가 이 최신 신기술 서비스를 내놓지 않던 그 긴 세월 동안에도 우리는 각자의 일을 잘 해 왔다는 걸 떠올리는 것에서 시작합니다.

    클라우드플레어가 인터넷 대부분의 바로 그 중간자(MITM)인 게 괜찮다면 이런 얘기는 전혀 상관없겠죠. 하지만 그 점이든 클라우드플레어가 사업을 하는 방식이든, 그들의 역량이 허용하는 어떤 부분이든 걱정이 된다면, 거기서부터 시작하는 겁니다.

  28. thayne HN

    그게 바로 클라우드플레어에 대한 의존을 더 늘리고 싶지 않은 이유 중 하나죠.

  29. baalimago HN

    세상일이 참 묘하게 돌아가네요. 저도 slivingdoc.dev라는 걸 만들었는데, 사실상 이거랑 똑같은 물건이거든요.

    제 아이디어가 정확히 맞았다는 걸 확인해서 기쁩니다. 물론 저는 경쟁력 있는 제품으로 키우는 데는 실패했지만요.

  30. camcil HN

    시가총액 1,250억 달러짜리 회사가 차세대 GitHub를 만드는 데 2만 5천 달러를 준다고요? 참 후하네요.

Hacker News에서 보기 ↗