# Epic Games, 오픈소스 버전 관리 시스템 Lore 발표 > Clean Markdown view of GeekNews topic #30586. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30586](https://news.hada.io/topic?id=30586) - GeekNews Markdown: [https://news.hada.io/topic/30586.md](https://news.hada.io/topic/30586.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-18T09:07:57+09:00 - Updated: 2026-06-18T09:07:57+09:00 - Original source: [lore.org](https://lore.org/) - Points: 9 - Comments: 2 ## Topic Body - Epic Games가 유지관리하는 **Lore**는 코드와 대형 바이너리 자산을 함께 다루는 프로젝트를 겨냥한 차세대 오픈소스 버전 관리 시스템임 - 로컬에서 빠르게 시작한 뒤 필요에 따라 확장할 수 있고, **공유·재사용 데이터**와 필요한 시점의 다운로드로 대규모 저장소와 팀을 지원함 - 중앙집중형 **콘텐츠 주소 기반 저장소**를 사용하며, Merkle tree와 불변 revision chain으로 저장소 상태와 변경 이력을 표현함 - 대형 파일은 재사용 가능한 **청크**로 저장되고, sparse workspace와 on-demand hydration으로 처음부터 모든 데이터를 내려받지 않아도 됨 - MIT 라이선스로 공개됐으며 CLI, C/C++, C#, Rust, Go, Python, JavaScript API와 여러 **SDK 저장소**를 제공함 --- ### 코드와 대형 자산을 함께 다루는 버전 관리 - **Lore**는 Epic Games가 유지관리하는 차세대 오픈소스 버전 관리 시스템임 - 데이터 규모, 팀 규모, 팀 분산, 저장소 규모에서 높은 확장성을 목표로 설계됨 - 코드와 대형 바이너리 자산을 함께 사용하는 프로젝트에 최적화됨 - 게임 및 엔터테인먼트 산업 프로젝트가 예시로 제시됨 - 개발자와 아티스트의 협업 요구를 함께 다룸 - 로컬 모드에서 몇 분 안에 시작할 수 있고, 이후 필요에 따라 확장 가능함 - 팀이 빠르고 직관적이며 실용적인 협업 워크플로를 구축할 수 있는 기반을 제공함 ### 확장성과 대형 파일 처리를 위한 구조 - ## 공유 데이터와 API - 주요 기능은 **확장성**과 대형 자산 처리에 맞춰 구성됨 - 공유·재사용 데이터와 필요한 시점의 다운로드로 속도 저하 없이 확장하는 것을 목표로 함 - 브랜치를 빠르게 만들고 관리하며 동기화할 수 있음 - CLI를 통해 Lore 전체 기능에 일대일로 접근 가능함 - C/C++, C#, Rust, Go, Python, JavaScript용 API로 확장, 커스터마이즈, 통합을 지원함 - ## 콘텐츠 주소 기반 저장소 - 저장소 구조는 중앙집중형 **content-addressed** 버전 관리 시스템임 - 저장소 데이터는 콘텐츠 해시로 저장·참조되며 Merkle tree로 표현됨 - 빠른 비교, 무결성 검사, 이력과 브랜치 간 데이터 재사용을 지원함 - revision의 해시 서명은 부모 revision 해시와 포함된 데이터 해시를 포함한 revision 상태에서 파생됨 - 이 구조는 암호학적 무결성을 가진 불변 체인을 형성함 - ## 청크 저장과 필요한 시점의 다운로드 - 대형 파일과 워크스페이스 처리는 **청크 저장**과 on-demand hydration을 사용함 - 파일은 재사용 가능한 청크로 저장되고 인덱스 기반 조회를 사용함 - 중복을 줄이고 대형 바이너리 자산의 업데이트와 전송을 효율화함 - workspace는 필요한 파일 데이터만 가져와 가볍게 유지될 수 있음 - sparse workspace를 통해 처음부터 모든 데이터를 다운로드하지 않아도 됨 - ## 서버와 브랜치 모델 - 서버 구조는 캐싱을 포함한 서비스 기반 아키텍처임 - durable storage 앞단의 캐싱으로 대형 팀과 대형 저장소의 처리량 확장을 지원함 - 브랜치는 가벼운 mutable reference로 동작해 생성과 전환 비용이 낮고, 기본 데이터 중복이 없음 ### 공개 저장소와 문서 - Epic Games는 Lore를 **MIT 라이선스**로 완전 오픈소스 공개함 - [Lore Library, Server & CLI](https://github.com/EpicGames/lore) - [Javascript SDK](https://github.com/EpicGames/lore-js) - [Python SDK](https://github.com/EpicGames/lore-python) - [C# SDK](https://github.com/EpicGames/lore-dotnet) - [Go SDK](https://github.com/EpicGames/lore-go) - 문서와 시스템 설계 문서는 [Lore docs](https://epicgames.github.io/lore/)와 [system design doc](https://epicgames.github.io/lore/explanation/system-design/)에서 제공됨 ## Comments ### Comment 59847 - Author: neo - Created: 2026-06-18T09:17:52+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48571081) - 게임을 해본 적 없는 HN 독자를 위한 맥락을 보태면, 이건 일반 소프트웨어 개발에서 Git과 경쟁하려는 도구가 아니라 게임 개발에서 **Perforce**와 경쟁하려는 도구임 Git은 코드처럼 텍스트 기반 파일에는 괜찮지만, 텍스처, 3D 모델, 오디오 파일 같은 비텍스트 파일 협업에는 매우 약함. 예를 들어 두 아티스트의 비동기 수정본을 합칠 합리적인 방법이 없으니, 한 아티스트가 편집 중인 에셋에 **배타적 잠금**을 걸어야 할 수 있음 이 영역의 사실상 선두는 독점 시스템인 Perforce([https://www.perforce.com/products/helix-core]())임. 게임 개발자 친구들 말로는 Perforce가 잘 돌아갈 때는 훌륭하지만, 도구 엔지니어가 관리하고 가끔 수동으로 고쳐야 할 정도로 걸림돌도 충분히 많다고 함. Git LFS도 대안이지만, 3~4명 이상 팀 프로젝트에서는 다들 Perforce를 더 선호한다고 함 - Git이 약한 또 다른 부분은 **권한 관리**임. 게임 개발에서는 특정 사용자에게만 공개해야 하는 독점 작업물이 있을 수 있음 P4에서는 필요한 NDA에 서명한 사람만 특정 디렉터리에 접근하도록 제한할 수 있지만, Git에서는 전부 주거나 전부 막는 식임. 서브모듈로 뭔가 구성할 수는 있겠지만, 처음부터 그렇게 설계하지 않았다면 저장소 구조를 크게 뒤엎게 됨 - 게임 개발에서 `git clone`, 즉 `p4 sync`는 **테라바이트 단위**가 될 수 있다는 점을 이해해야 함 Git은 이런 규모의 바이너리 에셋, 텍스처, 모델, 사운드 등을 다루는 데 약함 - Git LFS에서 싫은 점은 **아주 오래된 이력 삭제**가 안 된다는 것임. 이력을 지우지 못하게 하는 게 Git 정신일 수는 있지만, LFS 맥락에서는 끔찍하게 들림. 특히 Github를 쓰면 더 그렇다 개발 초기 단계에서 자주 업데이트되는 에셋이 있으면, 저장소 수명 내내 그 저장공간 비용을 부담하게 됨. 게임 개발에서는 이런 일이 흔함. 대부분의 에셋은 초반에 여러 번 오가다가 완성되면 다시는 건드리지 않음 - 지금은 2026년임. 예전에는 Git에서 큰 바이너리를 다루는 방법이 **git LFS**였지만, 이제는 그냥 Git 자체가 그 방법임 - P4는 “최첨단”이라기보다는 **업계 표준**에 더 가까움. 그래도 대용량 파일과 부분 체크아웃을 덧붙인 기능처럼 느껴지지 않게 처리함 - 오늘 Github에 변경사항을 푸시하면서도 Git의 UI가 얼마나 사용자 친화적이지 않은지 생각했음 `Enumerating objects`, `Counting objects`, `Delta compression`, `Writing objects`, `pack-reused`, `Resolving deltas` 같은 출력은 골수 Git 사용자에게는 뭔가 전달하겠지만, 대부분의 사람에게는 완전한 횡설수설임. “델타 압축”이 대체 뭐고, 스레드를 몇 개 쓰는지 왜 알아야 하며, “객체”나 “local” 객체, “pack-reused”가 무슨 뜻인지 알기 어려움 문서를 보면 Lore는 이 부분을 조금 더 낫게 처리하는 듯함. `Pushing 1 fragment(s)`, `Pushed 1 fragment(s), 124.00 bytes`, `Pushed revision 1 -> a3f8c2d1... to branch main`처럼 보임 - 이런 정보는 `-v` 같은 **상세 출력 옵션** 뒤에 있어야 한다는 데 다들 동의할 수 있을 듯함. 아마 아무도 손대지 않았던 것일 뿐이고, 수십 년 동안 그냥 무시하는 법을 배웠음 - 객체는 파일임. Git의 밑바탕은 **내용 주소화 파일시스템**임 객체는 트리가 참조하고, 트리는 그냥 디렉터리임. 트리는 다시 커밋이나 태그가 참조해서 DAG를 이루며, 그 여러 지점을 가리키는 이름 붙은 포인터가 브랜치와 태그 참조임: [https://git-scm.com/book/en/v2/Git-Internals-Git-Objects]() 느슨한 객체를 잔뜩 두는 건 매우 비효율적이므로 Git은 주기적으로 객체들을 팩으로 묶음. 공간을 아끼기 위해 팩 안에서 객체끼리 서로 비교해 압축하는데, 이게 **델타 압축**임: [https://git-scm.com/docs/git-pack-objects](), [https://github.com/git/git/blob/master/Documentation/technic...]() 푸시나 풀을 할 때 Git 전송 프로토콜은 양쪽이 어떤 객체를 갖고 있는지 열거해서 차이만 전송함. 거기에 더해 아직 팩으로 묶이지 않은 객체들을 양쪽에서 델타 압축해 공간을 절약함: [https://github.com/git/git/blob/master/Documentation/technic...]() Git은 괴짜들이 만든 오픈소스 프로젝트라 이런 정보를 전부 보여줌. 그냥 무시해도 됨. 정말 알고 싶다면 위에 링크한 Git 책과 문서 디렉터리에 모두 문서화되어 있음 - 요즘 **JJ 버전 관리 시스템**을 쓰기 시작했음. 사람들이 좋다고 하는데 처음엔 잘 이해가 안 됐기 때문임 점점 납득이 가고 있음. UI 관점에서는 Git보다 큰 개선임. 다만 브랜치 작업 흐름은 익숙해지는 데 시간이 좀 걸림 - 내가 일했던 모든 회사에는 신규 직원이 Git 내부 동작을 배우는 **Git 입문 교육**이 있었음. 1시간이면 되고, 주니어 개발자들이 무작정 명령어를 외우는 걸 멈추고 실제로 이해하기 시작함 `.git` 디렉터리를 직접 들여다보는 걸 강력히 추천함. 그러면 신규 직원에 대한 Git 지원 수요가 사실상 0에 가까워짐 - 이 발표는 특히 **Unreal 게임 개발**에는 매우 유망함. 다른 용도라면 그렇게까지 관심이 가지는 않음 Perforce에는 확실히 경쟁자가 필요함. Perforce가 기존 강자인 이유는 사용이나 관리가 유난히 단순해서가 아님. 예를 들어 브랜치 작업만 보면 Git이 실제로 훨씬 단순함 게임 개발에서 P4가 자주 선호되는 이유는 다른 댓글들에서도 이미 나온 대형 프로젝트 지원, 권한, 파일 잠금 등임. 또 하나의 핵심 이유는 P4가 Unreal Engine 안에서 매우 잘 지원된다는 점임. 완벽하진 않지만 Epic이 내부에서 쓰는 도구라 가장 잘 지원되는 버전 관리 시스템임. Git 플러그인은 Epic이 내부에서 쓰지 않기 때문에 고통스러울 정도로 미완성임 그래서 Lore는 1급 지원을 받을 것으로 기대함. Unreal의 지원이 더 좋았다면 Git을 훨씬 더 많이 추천했을 것임. 배경을 말하자면 거의 20년 동안 게임 개발을 해왔고, 2명부터 200명 규모 회사, 온갖 엔진과 버전 관리 시스템을 겪었음. 쓸 수 있는 곳에서는 Git을 선호하지만, Unreal에서는 소규모 프로젝트이거나 기술에 밝은 팀원일 때 정도임. 일과 팀에 맞는 도구를 고르면 됨 - 참고로 그 플러그인을 조금 다듬고 있었음. 다만 오늘 이후로 머지될 가능성은 더 낮아졌을 듯함 [https://github.com/EpicGames/UnrealEngine/pull/14630]() - 이전 게임 스튜디오에서 Perforce, 정확히는 **Helix Core Cloud**를 써야 했는데, 창작 직군 대부분이 이미 익숙한 사실상의 업계 표준임. 프로그래머들은 좋아하지 않지만, 게임 업계에서 주도권을 쥐는 쪽은 프로그래머가 아님. Unreal Engine 5와 함께 쓰기에도 안전하고 검증된 기본값임 다만 오래된 티는 남. 우리는 작고 자체 호스팅을 원치 않아서 Perforce 클라우드 서비스를 초기에 쓴 편이었는데, 경험이 꽤 삐걱거렸음. 서비스에 접근하려면 Azure 계정을 등록해야 했고, 트리거 같은 것을 바꾸려면 지원팀에 요청해야 했음. GitHub나 다른 SaaS 제품 세계에서 오면, 오래된 모델에 새 껍데기를 씌우려 한 시도라는 게 느껴졌음 Git LFS 경로도 비공식 지원은 좀 있지만, 일이 꼬이면 알아서 해결해야 함. Epic은 거기에 큰 도움을 주지 않음. 특히 엔진에서 완전한 공식 지원을 목표로 한다면 이 영역의 경쟁은 환영할 만함 텍스트 기반 개발에서 온 사람들을 위해 게임 개발 세계에서 파일 병합이 흔하지 않은 이유를 글로 썼음: [https://www.kuril.in/blog/why-game-devs-dont-merge-files/]() - UE5를 Perforce가 아닌 것으로 쓰는 건 고통을 배우는 과정임 방금 Git을 쓰던 팀을 맡았는데, Git이 모두가 좋아하는 버전 관리 시스템이라는 건 알지만 게임에는 거의 최악의 선택에 가까움. Git으로는 아트 리뷰 시간을 시간 단위로 재야 했고, Perforce로는 초 단위가 됨. 농담이 아님 UE5가 쓰는 흥미로운 도구들, 예를 들어 Horde나 UBA 같은 것들은 Perforce를 요구함 하지만 Perforce는 업계 지위를 가지고 아무것도 하지 않았음. 엄청 비싸고 호스팅 운영 비용도 들지 않음. 직접 호스팅해야 하고, 성능상으로도 직접 하는 편이 좋지만 첫 설치 이후 유지보수는 정말 고통스러움. 뭔가 시도하는 흔적은 있지만 뚜렷한 방향이 없고, 해온 거의 모든 일이 상식이나 사용자층과 어긋남. 핵심 제품은 계속 이름만 바뀌고 실제 개선은 없음 독점 소프트웨어가 어떻게 감옥이 되는지 보여주는 교훈임. Swarm보다 나은 코드 리뷰 도구를 쓰고 싶고, 내 장비에서 세그폴트를 일으키는 이상한 LUA 훅 없이 SSO를 통합하고 싶으며, 거대한 SSD와 저널 백업에 의존하는 대신 분산 저장 백엔드를 돌리고 싶음. 심지어 라이선스가 메인 서버 IP 주소에 묶여 백업 복구도 안 됨 잊힌 기술이고, 그 회사를 운영하는 곳은 좀비 같음 - Git LFS와 Git의 비교적 새로운 **희소 클론** 기능이 이런 문제에 대한 답일 수도 있다고 봄. 다만 이해하기로는 일반적인 모노레포 운용에 더 초점이 맞춰져 있었음 권한 문제가 정리됐는지, 또는 파일 단위 체크아웃이 전통적인 브랜치 기반 작업과 상호작용하는 이런 혼합형 분산/중앙집중 버전 관리 모델이 정리됐는지는 잘 모르겠음 - 글이 정말 좋았음. 기술적 차이뿐 아니라 그 차이가 주변 **개발 문화**에 어떤 영향을 주는지도 잘 설명함 - FAQ를 보면 실제로는 완전히 새 제품이 아니라 이제야 오픈소스로 공개한 것임 “이전에 Unreal Revision Control이라고 불렸던 Lore는 UEFN(Unreal Editor for Fortnite)에 내장된 버전 관리 시스템이며, 크리에이터들이 자신의 섬 버전을 관리하는 데 사용해 왔다. Epic 내부 팀에서도 점진적으로 채택되고 있고, UEFN의 cook 파이프라인 백엔드 저장소로 구현 중이며, 기존 중간 저장 계층을 대체해 중복 파일 전송을 없애고 변경사항 게시 후 플레이 가능해지기까지의 시간을 크게 줄인다”는 설명이 있음 Epic C++나 Verse가 아니라 **Rust**인 점이 놀라움. 이유가 궁금함 - C++ 대신 Rust를 쓴 건 Simon Peyton Jones와 Lennart Augustsson, 둘 다 Haskell로 유명한 사람들이 Epic에서 일하고 있어서 함수형 프로그래밍 기능이 있는 언어로 하자는 내부 압박이 있었기 때문일 수 있다고 봄 Verse가 아닌 Rust인 이유는 그 일이 Verse에 맞지 않았을 가능성이 크기 때문임. Simon이 Verse를 작업하더라도 마찬가지임. Haskell이 아닌 Rust인 이유는 아마 성능 때문일 것임. DARCS도 성능 문제 때문에 널리 자리 잡지 못한 면이 있음 - Unreal Engine과는 별도 도구이므로 엔진의 관례에 스스로를 묶을 필요가 없음. 순수 버전 관리 도구에서 UObjects, 리플렉션 계층, 직렬화 같은 것들을 쓸 이유도 없음 게다가 엔진의 온갖 문제와 느림에 자신을 묶게 됨. Epic은 Epic Games Launcher에서 이 실수를 했음. 사실상 엔진 인스턴스를 실행하는 형태라 여러 문제의 큰 원천임 Verse와 Rust를 비교하면, Verse는 UEFN 경험 안에서 쓰이지만 아직 프로덕션 상태와는 거리가 멂. 또한 본질적으로 UEFN에 묶여 있음. 독립 실행 컴파일러나 REPL을 내려받을 수 있는 것도 아님 - 실제로 한동안 사용되던 도구가 이제 공개 사용을 위해 나온다는 점은 오히려 더 신뢰감을 줌 물론 개발을 중단하기로 해서 공개하는 것이라면 예외지만, 여기서는 그런 경우로 보이지 않음 - **Full-surface API**는 여기서 아무도 언급하지 않은 기능임. Git이 의도적으로 링크 가능한 라이브러리를 제공하지 않는 점을 겨냥한 말인지 궁금함. 전에 이 글을 봤음: [https://news.ycombinator.com/item?id=48470604]() - Git을 겨냥한 말인지는 모르겠음. Git에는 프로그램과 상호작용하기 위한 `porcelain`이 있음. 링크 가능한 형태는 아니지만 그래도 API임 - 전제는 Git-LFS가 별로라서 새 **데이터 버전 관리 시스템**을 Rust로 처음부터 만들어야 한다는 것임. 이 전제에는 대체로 동의하지만, 내부적으로 같은 요령을 쓰는 성숙한 기존 데이터 버전 관리 시스템도 이미 꽤 많음 Pachyderm(Go): [https://github.com/pachyderm/pachyderm]() XetHub(HuggingFace가 인수): [https://huggingface.co/blog/xethub-joins-hf]() LakeFS(Go): [https://github.com/treeverse/lakeFS]() Oxen(Rust): [https://github.com/Oxen-AI/Oxen]() 요즘은 AI 덕분에 누구나 Rust로 내용 주소화, 청크 단위 중복 제거, 버전 관리 시스템을 바이브 코딩할 수 있는 시대인가 봄 농담은 제쳐두고 Lore는 정말 멋져 보임. 흥미로운 건 서로 다른 도메인과 산업이 비슷한 문제를 갖고 있는데도 아이디어 교류가 많지 않아 보인다는 점임. 이 경우 AI와 게임 모두 대규모 **대형 바이너리 파일 버전 관리** 저장 시스템이 필요함. 아이디어를 공유할 기회가 많아 보이고, 현재 공유가 부족하다는 점 자체가 기회를 만들 수도 있음 - AI 쪽과 게임 개발 쪽의 필요가 정확히 같지는 않다고 봄. AI에서는 큰 바이너리 파일이 보통 한 번 쓰이고 끝나는 반면, 게임 개발에서는 계속 업데이트됨 이 차이만으로도 서로 다른 저장소 아키텍처가 필요해질 수 있음 - git-annex와 iterative DVC도 있음. xethub를 꽤 많이 써봤고 사실 초기 사용자였는데, git-annex, git-lfs, DVC보다는 낫다고 생각했지만 어느 규모를 넘어서자 여전히 버거워지기 시작했음 문제의 일부는 Git 자체와 하이브리드 저장소를 유지하려면 필요한 타협이었다고 봄. 그래서 이 버전 관리 시스템이 Git을 쓰지 않는다는 점이 반가움. xethub도 Git을 쓰지 않는 버전의 제품을 내기 시작했지만 써볼 기회는 없었음 oxen도 써봤고 처음엔 나쁘지 않았지만, 곧 저장소 상태와 관련된 이상한 문제를 만났고 깊게 디버그하진 않았음. 이런 시스템들을 모두 겪어보니, 어느 것도 100% 만족스럽지 않았고 **데이터를 위한 Git**은 사소한 문제가 아니라는 게 분명해짐 - 어떤 회사가 실제로 이 시스템을, 예를 들어 **2년 안에 배포**할지 의문임 Helix와 Perforce는 수십 년 동안 이 일을 해왔고 핵심 사업의 일부이기 때문에 신뢰할 수 있음. 앞으로도 제품을 한동안 유지보수할 거라는 걸 알 수 있음 하지만 Epic은 내일 이 프로젝트를 포기해도 사업에는 아무 일도 일어나지 않음. 오히려 개발 리소스를 돌려받아 사업에 도움이 될 수도 있음 Cloudflare가 EmDash에 장기적으로 계속 투자할 거라고 왜 믿겠느냐는 문제와 비슷함. Cloudflare는 CMS에 관심이 없음. 독자, 작성자, 사이트 소유자에게 최고의 경험을 제공하는 게 그들의 사업이 아님. 본업과 거의 무관한 부업에 가까움 - 이 영역에는 예전부터 지금까지 **PlasticSCM**이라는 꽤 괜찮은 경쟁자가 있었음. 몇 년 전 Unity가 인수했지만, Unity는 좋은 관리자가 아니었음 Epic이 하는 것처럼 오픈소스로 공개했어야 했는데, 대신 손익 책임을 지우는 쪽을 택했음. Unity 재무에 얼마나 기여하고 있는지 궁금함 ### Comment 59846 - Author: neo - Created: 2026-06-18T09:07:58+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/r9fmgk/epic_games_announces_lore_version) - 코드와 대형 바이너리 자산을 함께 다루는 게임/엔터테인먼트 프로젝트에 최적화했다니, 드디어 누군가 **Perforce의 수십 년 독점**에 질려서 뭔가 만들었나 봄 - 처음 봤을 때는 아니었던 것 같은데, 왜 이제 **vibecoding** 태그가 붙었는지 궁금함 - [설계 문서](https://epicgames.github.io/lore/explanation/system-design/)에 **LLM 흔적**이 꽤 많아 보임. 관련 없는 세부사항에 집착하거나, 대안 검토가 빠져 있어서 자기 결정의 근거를 더 강하게 만들 기회를 놓친 부분들이 있음 예를 들어 “Mercurial과 Sapling은 텍스트 이력 중심이고 Lore는 바이너리 우선”이라는 식의 설명은 틀렸음. Mercurial도 바이너리 객체 모델 위에 텍스트 기능이 얹힌 구조임 Mercurial/Sapling 개발에 참여했던 입장에서, LLM이 팀이 놓친 대안을 짚어 주는 식으로 엄밀성을 높일 수 있다고 믿지만 이 문서는 실망스러웠음. 결정 자체에는 장점이 많지만, 훨씬 더 **엄밀하게 쓰인 문서**였으면 했음 - **vibecoded 태그**의 신호 강도가 점점 약해지는 것 같음 - [modlog](https://lobste.rs/moderations)를 보면 사용자 제안으로 태그가 자동 변경됐음 2026-06-17 12:56 (Users) Story: Epic Games announces Lore version control system Action: changed tags from "release vcs" to "release vcs vibecoding" Reason: Automatically changed from user suggestions - 혹시 이게 Epic Games가 공개적으로 만든 첫 **Rust 프로젝트**인가? - [their debugger](https://github.com/EpicGamesExt/raddebugger), 예전 이름으로 RAD debugger가 더 오래 공개 개발된 것 같음 - 이것과 Cursor의 최신 버전 관리 시스템 소식을 보니, 요즘은 다들 **VCS**를 만들려는 분위기 같음 - Lore는 꽤 다른 문제를 푸는 프로젝트임. 정체된 데다 요즘은 상대적으로 비싼 **Perforce 대체재**가 되려는 쪽에 가까움 - 처음 든 생각이 “이거 **lore 위에 호스팅**돼야 하는 거 아닌가?”였던 건 나뿐인가? - 커밋 아래쪽에 전부 이런 내용이 붙어 있음 ``` Lore-RevId: 227 Lore-Signature: 212796af157a853238b32df89a978cadc5e0e358d88ad80233bc53351285de0f ``` 그래서 어떤 식으로든 **미러링**이 돌아가는 것 같음 - 비디오 게임 자산처럼 큰 블롭이 있는 저장소를 겨냥한 도구라서, 자기들 소스 코드는 여전히 **git으로 관리하고 GitHub에 호스팅**하는 게 어느 정도 말이 됨