한쪽에서는 작성자조차 읽지 않고, 공유하거나 패치를 받지도 않는 코드를 이야기함. 이런 코드에는 Git의 존재 이유 자체가 무의미해짐.
반면 하위 계층 도구는 단순하고 안정적이며 효율적이어야 하고, 여기서는 공유가 핵심임. 이 글의 작성자들도 Git에 점진적인 개선을 기여했으며, 이런 맥락에서는 확장성 이야기가 별 의미 없음. Git이 프로토콜로 변해 가고 있다고 봄. 하나의 제품으로 이 모든 용도를 감당하기는 어려움.
이 엄청난 양의 코드가 실제로 무슨 일을 하는지 설명해 줄 수 있나? 모델 아키텍처의 여러 변형, 학습·서빙 인프라, 앱 소스가 있다는 건 알겠음.
그런데 왜 그 코드가 기하급수적으로 늘어나는 건가? 모델 품질을 빼면 제품은 크게 달라지지 않는 듯한데, 엔지니어들은 모두 무엇을 하고 있나?
정작 느리고 불편하고 오류투성이가 아닌 chatgpt.com은 만들지 못하고 있음.
Astra를 써 보면 작동하는 듯한 코드는 작성하지만, 기능에 맞게 합리적으로 설계된 코드를 작성하는 것은 아님. 방금도 수천 줄을 대대적으로 수정하면서 기존 구조를 그대로 두고, 옛 코드가 새 의미로 동작하도록 어댑터를 억지로 끼워 넣는 걸 봤음.
이렇게 결과를 고민하는 수고 없이 변경 요청만 계속하면, 엉망인 코드가 기하급수적으로 늘어날 수 있겠음. 최근 Anthropic 모델은 써 보지 않아서, 그쪽은 더 나을 수도 있음.
소프트웨어의 제약은 언제나 수요가 아니라 공급이었기 때문임. 엔지니어 한 명이 주당 운영용 코드 100줄을 배포하던 시절에는 가장 필수적인 일만 할 수 있었음.
코드 생산 비용이 낮아지면 애매했던 프로젝트도 할 만해지고, 터무니없던 프로젝트도 검토할 만해짐. 모델이 저렴해지고 좋아지면서 경제성 있는 프로젝트의 범위가 빠르게 넓어지는 중임.
모델 품질을 제외하면 무엇이 달라졌냐는 질문은, 링컨 부인에게 “그 일만 빼면 연극은 어땠나요?”라고 묻는 격임.
우선 일반인은 접근할 수 없는 내부 모델이 있음. 또 머신러닝은 AI로 자동화하기 가장 쉬운 분야일 가능성이 큼.
현실 세계와 부딪힐 일 없이 모든 작업이 컴퓨터 안에서 이뤄지고, 공개 모델만으로도 이미 전체 과정을 수행할 수 있음. 경험적 검증이 핵심인 분야라 연산 자원과 실험 횟수를 늘리는 것만으로도 상당히 진전할 수 있음.
강화학습 환경임. 끝없이 많은 강화학습 환경을 만드는 것임.
주제 자체에는 별 관심 없지만 수치·차트·시각화로 깊이 있게 풀어낸 글이라 좋음. 걸핏하면 AI를 들먹이거나 불필요한 마케팅과 과장을 하지 않고, 엔지니어들이 자기 목소리로 설명함.
사람이 썼는지 미공개 모델이 썼는지 구분할 수 있다고 생각하는 건 순진함.
벤치마크가 보이지 않음. 초당 푸시를 몇 건 처리하고, 동시에 푸시하는 클라이언트는 몇 개까지 감당할 수 있나?
참고로 나는 https://juju.bi에서 코드 호스팅 플랫폼을 만들고 있음.
나도 eol.sh에서 코드 호스팅 플랫폼을 만드는 중이며, 지금은 임시 페이지만 있음. 기존 대안들이 죄다 GitHub 복제품처럼 보이는 게 가장 불만인데, 여기는 그렇지 않아서 좋음.
Jujutsu와 관련이 있나? 소개 페이지에는 언급이 없고, 이상하게 Git도 나오지 않음.
서버가 추가 팩을 별도로 다운로드할 링크를 반환하는 packfile-uri 를 Pando가 전면 활용하고, OpenAI가 이를 위해 여러 개선을 기여했다는 점이 좋음. 기존 시스템을 잘 응용하면서 오픈소스의 강점을 보여 줌.
Pando를 착수부터 운영 배포까지 10주 만에 Codex로 만들었다고 함. 핵심 설계는 엔지니어 한 명이, 구현은 에이전트 팀들이, 배포는 소수의 엔지니어가 맡았으며 올해 4월부터 운영 트래픽을 처리하기 시작했다고 함. 인상적인 건가!?
Linus가 Git을 개발하는 데 걸린 시간의 약 7배임.
정말 묘한 시대임. 지난 한 달 동안 수년간 만들고 싶었던 시스템들을 만들었고, 시간을 내서 급히 직접 만들었더라도 도달하기 어려웠을 만큼 훨씬 좋은 결과를 얻었음. 주변에서 본 몇몇 사람보다 자제하면서 더 신중하게 접근하려고 하는 편인데도 이 정도임.
Git 성능 문제는 늘 모노레포를 쓰는 쪽에서 겪는 듯함. 왜 그런지 궁금함.
Git의 한계를 넘어서는 것이 최고 수준의 기술 기업으로 성장했다는 졸업식처럼 보임. 과거에는 Google과 Facebook이 그랬고, 이제는 Anthropic과 OpenAI 차례임.
반면 대규모 소프트웨어 개발을 개척한 Microsoft 같은 회사는 여전히 Git을 사용함.
성장하면서 오히려 Git으로 옮겨 가는 회사도 있음.
이제야 최근 GitHub 인프라가 그렇게 고전한 이유를 이해하게 됨.
논쟁을 벌이려는 건 아니지만, 이건 Git이 아니라 모노레포의 문제처럼 들림.
별도 저장소의 비공개 패키지로 나누면 확장성이 더 좋아질까? 같은 문제를 겪을까, 아니면 다른 문제가 생길까?
다른 문제를 겪게 됨. 반대 극단을 상상해 보면, 최근 프로젝트의 파일마다 Git 저장소를 하나씩 만드는 것과 같음. 터무니없지만, 그렇게 쌓인 저장소를 다루려면 온갖 연결용 프로그램이 필요해짐. 파일마다 다른 브랜치는 어떻게 처리할까? 이를 조율할 도구가 필요함.
실제로 그렇게 하자는 게 아니라, Google·Facebook·OpenAI 규모에서 무엇이 어렵고 무엇을 최적화하려는지 이해하기 위한 사고 실험임. 여러 저장소를 조율하는 것은 전혀 다른 문제이며, 모노레포는 많은 문제를 해결하는 대신 다른 문제를 만듦. 그중에는 상대적으로 해결하기 쉬운 것도 있음.
모노레포에서 늘 두려웠던 부분임. 대형 기술 기업 규모에 도달할 일은 없겠지만, 언젠가 한계에 부딪힐 것 같은 불안이 계속 있었음. 작은 구성요소별 저장소라면 그럴 가능성이 더 낮고, 문제가 생겨도 해당 구성요소만 영향을 받음.