6 TOPS짜리 NPU가 달린 보드 세 대를 평범한 이더넷으로 묶으면 18 TOPS가 될까요.

데이터시트의 산술은 그렇다고 합니다. 실제로 재 보면 그 질문 자체가 서로 다른
두 질문이 겹쳐 있는 것이었습니다.

NanoPi R76S(Rockchip RK3576, 6 TOPS) 세 대를 표준 2.5GbE와 평범한 gRPC로 묶어
요청 단위 데이터 병렬 추론 런타임을 Rust로 만들고, 2주 동안 421건을 실측했습니다.
보드는 개당 USD 110이었는데, 정작 스위치와 10G NIC이 보드값의 절반을 넘었습니다.
처리량은 112.9에서 338.4 inf/s로, 3.00배 거의 선형으로 확장했습니다.

그런데 이건 TOPS가 더해졌다는 뜻이 아닙니다. 이미 "클러스터로 묶이는 비용"을
치른 기준선에서 출발한 수치입니다. 발표의 앞부분은 이 둘을 분리하는 데 씁니다.

발표의 절반은 답이 아니라 답을 낸 과정입니다

421건을 재는 동안 결론의 부호가 뒤집힌 적이 네 번, 계기가 거짓말한 적이
여섯 번 있었습니다.

• 노드당 커넥션을 1에서 2로 늘리는 변경을 부하 c32에 고정해 쟀더니 p95가 46%
  나빠졌습니다. 그런데 포화 곡선을 다시 그려 보니 c32는 시험 대상 세 구성 모두
  이미 과부하 구간이었고, 운영점은 c12였습니다. c12에서 같은 변경을 다시 재니
  p95가 18.8% 좋아졌습니다. 두 측정 다 맞았고, 앞의 것은 쓸모가 없었습니다.
• 무팬으로 세 번 재는 동안 세 보드의 SoC 최고 온도는 거의 같았는데(약 86 °C)
  노드 간 지연 편차는 1.10배에서 2.40배까지 갈렸습니다. 최고 온도만으로는
  편차가 설명되지 않았습니다. 편차를 따라간 것은 보드 사이에서 클럭 스로틀링이
  얼마나 벌어지는가였습니다.
• 스케줄러가 낡은 상태를 보고 몰려다녔습니다. 부하 인지 정책이 단순 round-robin
  보다 처리량을 55~58% 무너뜨렸는데, 정책이 아니라 기본 설정의 버그였습니다.
• 계획서에 적어 둔 io_uring은 재 보고 나서 만들지 않기로 했습니다. 회수 가능한
  몫이 전송 비용의 약 8%였고, 여기서 CPU는 제약이 아니라 비용이었기 때문입니다.

여섯 번의 오측정은 전부 성공처럼 보였습니다. 숫자가 나왔고, 그럴듯했고,
아무도 멈추지 않았습니다. 네 건은 다른 측정과 대조해서, 두 건은 도구가 시끄럽게
굴어서 잡혔습니다. 그리고 그중 셋은 뿌리가 하나였습니다 — 계기가 틀렸고, 그 위에
설명이 세워졌고, 그 설명이 다른 문서로 번졌습니다.

틀린 것을 지우지 않았습니다

이 발표에서 제일 하고 싶은 이야기입니다.

철회한 주장, 잘못 잰 온도, 취소선 친 결론, 계기가 거짓말한 여섯 건의 목록까지
저장소에 그대로 남아 있습니다. 421건 원본 데이터도, 실험 보고서 12건도,
"이건 아직 설명하지 못했다"고 적어 둔 잔차 16.1%도 공개돼 있습니다.
발표에 쓰는 숫자는 전부 원본 데이터로 역추적되고, 각 숫자가 어떤 조건에서
나왔는지도 함께 공개돼 있습니다.

제 발표를 듣고 그 자리에서 반박하실 수 있습니다. 그게 이 프로젝트에서 제일
값어치 있는 부분이라고 생각합니다.

다루는 것

• Edge NPU Cluster가 무엇이고 무엇이 아닌지 — 요청 단위 데이터 병렬은 처리량을
  올리지 단일 요청을 빠르게 하지 않습니다. 모델 병렬과는 다른 문제입니다
• 3노드에서 3.00배가 나온 조건, 전송을 튜닝하면 처리량은 오르는데(387.2 inf/s)
  효율은 왜 떨어지는지(98.9% → 95.3%)
• 결론이 뒤집힌 네 번과, 계기가 거짓말한 여섯 번
• 저가 하드웨어에서 재현 가능한 측정을 하려면 무엇을 미리 정해 둬야 하는지

다루지 않는 것

• LLM 추론 · 모델 병렬 · 텐서 병렬
• RDMA, 커널 우회, 전용 전송 계층 (안 썼습니다. 평범한 gRPC입니다)
• 4노드 이상 (측정하지 않았습니다)

이런 분께

엣지에서 추론을 굴리거나 굴릴 예정인 분, 저가 SBC와 NPU 생태계를 보고 계신 분,
그리고 벤치마크를 만들거나 남의 벤치마크 숫자를 믿어야 하는 모든 분.

NPU나 RKNN 사전 지식은 필요 없습니다. 필요한 만큼 앞에서 깝니다. 뒷부분의
측정 방법론 이야기는 NPU와 무관하게 성립하므로 도메인이 달라도 가져가실 수
있습니다.

런타임과 421건의 원본 데이터, 실험 보고서, 아키텍처 결정 기록은 모두
오픈소스로 공개돼 있습니다. 저장소와 프로젝트 페이지 주소는 요청하시면
바로 드리겠습니다.

Most people in Korea know that Korea could become the 3rd most advanced AI country in the world. In the EU, people say that the EU should be number 3. In Canada and Japan, they also talk about becoming number 3. But how can any of these become number 3 when they are each missing important pieces of the puzzle?

They're working together. Not many people know that. And they're going to use FOSS to make it work.

These countries have decided that collaboration is the winning strategy. The EU & South Korea Digital Cooperation Treaty was signed in 2022 and the EU-South Korea Digital Trade Agreement in 2026.

This presentation will show the deep connections that the EU and Korea have formed since 2022. The treaties are signed. When our countries work together, we have the data, the chips, the experts, and a market of customers. The last missing piece: who can organise massive international collaboration with transparency and trust? FOSS has the answer: we've been doing this for four decades.

This presentation will show that this is the biggest collaboration on AI, and that it is a real plan with real chances of success. There are funding opportunities and there are opportunities to help make this a success. This presentation shows why the FOSS communities of Europe and Korea should build connections and help both become the number 3, or 2, or the number 1 for AI, with freedom and openness.

There are many closed solutions for home automation like Google Home, Apple
Home, Alexa, Samsung SmartThings, etc. but they all want your data in their
cloud and they decide what devices you're allowed to use. If you want to be in
control, then you want to use one of the biggest open source projects on
GitHub: Home Assistant.

Jeena has been running three instances for the last ten years: in Poland at
his parents' summer house, in Germany at his parents' house, and here in Korea
in his own house. He also worked Home Assistant into his professional life by
consulting for Electrolux around it.

He will talk about how easy it is to set up, how difficult it is to keep
everything running, then about the community around it with podcasts,
YouTubers, forums, an add-on store built by volunteers, etc.

He will also talk about the interoperability, which is more difficult than it
would seem, because it goes against what especially the big companies are
after, so they sometimes make it very difficult for you to integrate their
things.

If you have thought about automating your home, this might be the talk to
finally convince you.

In this session, I will provide an overview of the student open-source community ecosystem in Taiwan, sharing how students independently built and sustained a large-scale open-source community from scratch, and how we introduce the next generation to open-source culture. We will also examine the core challenges faced by youth volunteer organizations and explore how open collaboration and community culture help address these hurdles.

I will talk about:

• Overview of student open source communities in Taiwan and why SITCON was founded.
• Introduce SITCON’s core activities and positioning, and provide an in-depth introduction to how we use open-source tools for organizational collaboration and knowledge transfer.
• Volunteer diversity, addressing the rising career anxiety among students, and sustaining engagement through human connections and participant-to-organizer transformation.
• Summary and open Q&A to facilitate mutual dialogue on student community engagement across borders.

이 발표에서는 LLVM 프로젝트에 Z80 백엔드를 새로 추가한 개발 과정과 기술적 도전, 그리고 AI를 활용한 오픈소스 프로젝트 운영 경험을 공유합니다. 오래된 CPU 위에 현대 컴파일러 기술을 접목하는 과정을 중심으로, 레트로 컴퓨팅이라는 취미와 오픈소스 생태계에 대한 기여가 맞닿는 지점을 소개하고자 합니다.

This talk shares the development process and technical challenges of adding a new Z80 backend to the LLVM project, along with my experience running an open-source project with the help of AI. The talk focuses on the process of bringing modern compiler technology to an old CPU, and aims to show where the hobby of vintage computing meets contribution to the open-source ecosystem.

1976년에 발표된 CPU인 Z80은 C 언어가 널리 쓰이기 이전에 발매된 CPU로, 20세기부터 현재까지 다양한 PC, 게임 콘솔, 임베디드 시스템 등을 거쳐 현재까지도 사용되고 있는 CPU입니다. 저는 이러한 Z80을 대상으로 C, C++, Rust 등의 현대 언어를 컴파일할 수 있는 LLVM-Z80 프로젝트를 진행하고 있습니다.

LLVM의 최신 코드 생성 프레임워크를 기반으로 Z80 CPU 대상 코드 생성 백엔드를 구현한 경험을 공유함으로써, 오래된 아키텍처 위에서 현대 컴파일러 인프라가 어떻게 동작할 수 있는지, 그리고 그 과정에서 마주친 문제점들과 기술적 선택에 대해 다루고자 합니다. 더불어 LLVM-Z80과 같은 취미 프로젝트가 오픈소스 생태계에 어떻게 기여로 이어질 수 있는지도 함께 이야기합니다.

나아가, AI를 활용해 대형 오픈소스 프로젝트의 포크를 개발 관리하며 느낀 점을 공유합니다. 예전이라면 팀이나 기업 단위로나 가능했을 규모의 코드베이스를, 이제는 개인이 AI의 도움을 받아 혼자서도 들여다보고 관리할 수 있게 됐습니다. 이런 변화 속에서 개인 개발자가 오픈소스에 기여할 수 있는 방식 자체도 조금씩 달라지고 있다고 생각합니다.

레트로 컴퓨팅은 단순히 옛날 기기를 수집하고 전시하는 것을 넘어, 그 기기를 직접 써보고, 고치고, 그 위에서 새롭게 무언가를 만들어보는 활동입니다. 수십 년 전 하드웨어의 한계 속에서 코드를 짜보는 경험은 지금의 컴퓨팅 환경에서는 느끼기 어려운 재미를 줍니다. 이 발표를 통해 레트로 컴퓨팅에 관심을 갖는 분들이 더 늘어나기를 바랍니다.

The Z80, released in 1976, came out before the C language was in wide use. It has passed through PCs, game consoles, and embedded systems over the decades, and while it's no longer as widespread as it once was, it's still in use today.

I'll share my experience building a Z80 code-generation backend on top of LLVM's latest code-generation framework, covering how a modern compiler infrastructure can work on such an old architecture, and the problems I ran into and the technical choices I made along the way. I'll also talk about how a hobby project like LLVM-Z80 can turn into a contribution to the bigger open-source ecosystem.

I'll also share what I've learned from developing and maintaining a fork of a large open-source project with the help of AI. Codebases that used to need a whole team or company to manage can now be handled by one person with AI help. I think this is changing how individual developers can contribute to open source.

Retrocomputing is more than collecting and displaying old machines. It means actually using them, fixing them, and building something new on top of them. Writing code within the limits of decades-old hardware is fun in a way that's hard to get from today's computing environment. Through this talk, I hope more people get interested in retrocomputing.

2025년 OSSCA(오픈소스 컨트리뷰션 아카데미) 멘티로 Apache Zeppelin 오픈소스를 기여하기 시작했습니다. 그 당시 저는 Angular를 다뤄보지 않았던, 주로 React를 다루던 프론트엔드 개발자였는데요. 단축키 관련 이슈를 다루면서 파생되는 이슈를 직접 리포팅하고 해결했던 경험, E2E 테스트 추가, 마이크로프론트엔드를 활용해 Angular에서 React로의 마이그레이션을 제안하는 등 첫 기여부터 Apache Zeppelin 커미터가 되고, 2026년 OSSCA 멘토로 다시 참여하기까지의 과정을 소개할 계획입니다.

이 세션은 오픈소스 기여에 처음 참여하려는 개발자와 첫 PR 이후 무엇을 해야 할지 고민하는 기여자를 위한 발표입니다. 낯설고 방대한 오픈소스 리포지토리에서 자신이 이해할 수 있는 문제를 찾는 법, 재현 절차와 검증 근거를 갖춘 PR을 만드는 법, 통과하는 테스트가 실제 동작을 정확하게 커버하고 있는지 판단했던 방법을 다룹니다.

Zeppelin이나 Angular에 대한 사전 지식은 필요하지 않습니다.

When people hear “open source contribution,” they often imagine writing code, fixing bugs, and opening pull requests. But open source projects depend on far more than code: documentation, design, testing, translations, accessibility, issue triage, community support, tutorials, and project organization are all essential contributions.

This talk is an introduction to the many ways people can participate in open source without being software developers. We will explore real-world contribution paths, how to find projects that need these skills, and how to turn everyday skills and interests into meaningful open source contributions.

We will also look at why these contributions are sometimes undervalued, how projects can make non-code contributions easier, and how welcoming contributors with different backgrounds can make open source communities stronger.

Whether you are a designer, writer, tester, translator, student, community organizer, or simply someone who uses open source software and wants to give something back, this talk will show that you don't need to write code to become an open source contributor.

Common Lisp의 SBCL이나 Scheme의 Chez Scheme은 동적 타입 언어이면서도 프로그램 전체를 미리 네이티브 코드로 컴파일해 수십 년째 프로덕션에서 쓰이고 있습니다. 반면 JavaScript는 여전히 인터프리터와 여러 단계의 JIT, 그 위에 얹힌 디옵티마이제이션 메커니즘 없이는 빠르게 돌아가지 못하는 언어로 여겨집니다. 왜 그럴까요? 이 질문에서 출발한 프로젝트가 Oseo입니다.

Oseo는 모든 함수를 두 겹으로 컴파일합니다. 언어 전체 의미를 구현하는 제네릭 경로가 하나 있고, 값의 종류나 형태에 대해 저렴한 런타임 가드를 걸 수 있는 곳마다 그 옆에 특수화된 경로를 나란히 둡니다. 가드가 실패하면 이미 바이너리 안에 컴파일되어 있는 제네릭 경로로 분기할 뿐입니다. 인터프리터로 떨어지지도, 디옵티마이즈하지도 않습니다. TypeScript의 타입 표기와 JSDoc은 이 특수화 경로를 선택하는 힌트로 쓰이지만, 결코 덮어놓고 신뢰하는 것은 아닙니다. any나 타입 단언, 순수 JavaScript와의 상호운용 때문에 : number라는 표기는 언제든 틀릴 수 있고, Oseo는 그 가능성을 가드로 방어합니다.

이 발표에서는 이 아이디어가 실제로 어떻게 동작하는지를 코드와 바이너리로 직접 보여드리려 합니다. Node.js나 Deno 없이, V8이 전혀 링크되지 않은 순수 네이티브 실행 파일이 어떻게 만들어지는지, --dump-mir와 --emit-c로 들여다본 생성 코드에서 가드 하나가 실제로 어떤 비교와 분기로 컴파일되는지를 보여드립니다. 타입 힌트가 실행 결과를 바꿔서는 안 된다는 원칙도 다른 프로젝트와의 비교를 통해 구체적인 예제로 함께 살펴봅니다.

Oseo는 아직 완성된 프로젝트가 아닙니다. 이 발표는 지금까지 증명된 것과 아직 남은 길을 함께 보여드리는 자리이기도 합니다. 네이티브 I/O, 가비지 컬렉터, 셀프 호스팅 부트스트랩까지, 시스템 프로그래밍에 관심 있는 분이라면 기여할 여지가 많은 지점들을 짚어보려 합니다.

SBCL for Common Lisp and Chez Scheme for Scheme are dynamically typed, yet both compile whole programs to native code ahead of time and have run in production for decades. JavaScript, meanwhile, is still assumed to need an interpreter, several tiers of JIT, and a deoptimization mechanism on top just to run fast. Why the difference? That question is where Oseo started.

Oseo compiles every function twice over. A generic path implements the full semantics of the language; wherever a value's kind or shape allows a cheap runtime guard, a specialized path sits beside it. When a guard fails, control simply branches to the generic path already compiled into the binary. Nothing falls back to an interpreter, nothing deoptimizes. TypeScript type annotations and JSDoc comments guide which specialized path gets picked, but they are never taken on faith: any, type assertions, and interop with untyped JavaScript mean a : number annotation can be wrong, and Oseo guards against that possibility rather than trusting it.

This talk shows the idea working, in code and in binaries. I'll walk through how a pure native executable gets built without Node.js or Deno, with no V8 linked in at all, and look at what a guard actually compiles down to by reading the generated code through --dump-mir and --emit-c. I'll also demonstrate, with a concrete comparison against another project in the same space, why a type hint must never be allowed to change what a program actually does.

Oseo is not finished. This talk is as much about what remains as what's already proven: native I/O, garbage collection, self-hosting. Anyone with an interest in systems programming will find plenty of open ground to contribute to.

Observability is a buzzword. As is common with buzzwords, there’s a good reason why it is so successful, but people also often use it for just anything to sound cool and knowledgeable until the word starts losing its meaning.

Let’s go through the scientific definition of Observabilty, then though how humans have dealt with and optimized data since we have had written records, and then apply this knowledge in finding out how to get actionable insights from your data while keeping human effort and costs down.

Discuss on software developments for computers in the 1980s based on my personal experience of the first 10 years in Korea.

Korea was not ready to develop system softwares, then. My task is to lead development of the computers (컴퓨터 국산화 Project); microcomputer, minicomputer, and the mainframe computers at Korea Institute of Electronics Technology (1979-1982), followed by computer science professors at SNU and KAIST. I was thinking on portable software, open source software, free software,.. then. DOS for microcomputers, and UNIX for minicomputers as well as software tools were primary candidates in the 1980s. Richard Stallman visited KAIST in the 1980s. He is a super programmer, and was promoting "free software" such as GNU Project.

Will comment on AI and open software, next. Will also comment on the related topics including AI, Creative Commons, (Open Source) Hardware, and Software Maintenance.

기업 연구팀에서 오픈소스로 만든다는 것은 어떤 의미일까요?

저희는 기업 안의 독립적인 연구팀으로, 머신러닝을 기반으로 Computer Vision, Robotics, LLM, AI Accelerator 등 다양한 기술 영역을 탐색하고 있습니다. 그리고 “오픈소스를 기반으로 하는 머신러닝 기술로부터 지속 가능한 가치를 창출한다”는 미션 아래, 연구 과정에서 만들어진 과정 및 결과를 오픈소스로 공개해 왔습니다.

하지만 연구 과정 및 결과를 오픈소스로 공개하다 보면 몇 가지 질문을 만나게 됩니다.

전문적인 연구 소프트웨어는 사용자가 많지 않을 수도 있고, 큰 커뮤니티나 많은 기여자가 생기지 않을 수도 있습니다. 그러나, 누군가에게는 새로운 연구를 시작하는 도구가 되거나, 기존 연구를 검증하고 새로운 문제를 발견하는 계기가 될 수 있기 때문입니다.

최근 AI for Science와 같이 AI가 다양한 과학 분야의 연구 과정 자체를 변화시키려는 시도가 활발해지면서, 연구 결과를 어떻게 공유하고 다음 연구로 연결할 것인가도 더욱 중요해지고 있습니다. 다른 연구자가 결과를 재현하고, 활용하고, 새로운 문제로 확장할 수 있으려면 논문이나 결과뿐 아니라 그 과정에서 만들어진 소프트웨어와 기술 역시 중요한 연구 자산이 됩니다. 기업이 연구 과정에서 만들어진 기술을 오픈소스로 공개하는 것 또한 이러한 흐름에 기여할 수 있는 하나의 방법이라고 생각하고 있습니다.

하지만 저희는 연구기관이 아니라 기업 안의 조직입니다. 연구와 기술에 들어가는 시간과 자원 역시 언젠가는 조직이 추구하는 가치와 어떻게 연결되는지 설명할 필요가 있습니다.

그렇다면 연구 오픈소스가 외부에서 만들어내는 가치와 기업이 필요로 하는 비즈니스의 가치는 항상 같은 방향을 바라볼까요?

연구적으로 의미 있는 프로젝트가 비즈니스와는 거의 연결되지 않을 수도 있습니다. 반대로 비즈니스와 연결되기 위해서는 사용자, 기여자, 파트너, 실제 도입과 같은 또 다른 조건이 필요할 수도 있습니다. 그렇다면 모든 오픈소스를 같은 기준으로 바라보는 것이 맞을까요?

이 발표에서는 약 9년 동안 다양한 연구 결과를 오픈소스로 공개해 온 기업 연구팀의 경험을 바탕으로 이 질문들을 살펴봅니다. Star와 다운로드 같은 숫자를 넘어 누가 실제로 사용했고 무엇을 가능하게 했는지, 연구 오픈소스에서 말하는 가치와 비즈니스에서 말하는 가치는 어떻게 다른지, 그리고 각각의 프로젝트가 연구와 오픈소스, 비즈니스 사이에서 어떤 역할을 해왔는지 이야기합니다.

오픈소스를 많이 공개하는 것만으로 충분하다고 생각하지 않습니다. 그렇다고 모든 프로젝트에 직접적인 매출이나 사업 성과를 요구하는 것도 답이라고 생각하지 않습니다.

AI for Science가 연구의 방식과 속도를 바꾸어가는 지금, 연구에서 오픈소스의 역할 역시 다시 생각해볼 필요가 있습니다. 얼마나 많이 관심을 얻었다 보다는 그 오픈소스가 다음 연구와 기술을 무엇을 가능하게 했는지, 그리고 그 가치를 기업 안에서도 지속할 수 있는지가 더 중요한 질문이 될 수 있습니다.

이 발표는 정답이나 오픈소스 수익화 공식을 제시하지 않습니다. 약 9년간의 경험과 사례를 돌아보며 연구의 가치를 지키면서도 오픈소스와 비즈니스가 함께 지속되기 위해 우리는 무엇을 가치로 보고 무엇을 지속할 것인지, 그리고 앞으로의 연구 오픈소스는 어떤 역할을 할 수 있을지 함께 생각해보고자 합니다.

청중들과 이런 이야기를 해볼 수 있습니다.

• 기업의 연구팀은 왜 연구 과정/결과를 오픈소스로 공개하는가?
• Star나 다운로드를 넘어, 연구 오픈소스의 가치를 어떻게 바라볼 수 있을까?
• 연구의 가치와 비즈니스의 가치 사이에서 오픈소스를 어떻게 지속할 수 있을까?
• AI for Science 시대, 연구 오픈소스는 다음 연구와 기술에 무엇을 가능하게 할 수 있을까?

Something feels broken, confusing, or missing, and you say so. That's often where contribution starts, but a drive-by complaint rarely lands. Feedback stalls for all kinds of reasons: a message that didn't quite land, a maintainer too busy to follow up, or a reporter who never answered when asked for more detail.

I've seen small contributions such as a bug report, a translation fix, or a forum question turn into real improvements, especially for languages and cultures that core developers can't fully understand on their own. This talk shares what makes feedback actually land: observe first, keep it small but concrete, stay in the conversation, and know that AI can draft a report but a human still has to stand behind it.

Not every path starts with frustration. I'll share a case where self-interest brought in a contributor instead, and close with a few low-cost things any community can do to welcome newcomers.

A short introduction to AT protocol and Tangled. Every code host asks you to make a new account. Your username, your followers, your issues and your review history live on that host, and none of it comes with you when you leave. The AT Protocol, the protocol Bluesky is built on, takes a different position: your identity is an identifier you own, your data lives in a repository you control, and applications read from and write to it rather than owning it. Tangled is a git collaboration platform built that way. This talk covers what atproto does, how Tangled maps code collaboration onto it, and the parts of Tangled that have nothing to do with atproto at all.

이 발표에서는 웹 프론트엔드에서 인라인 스크립트를 고도화하고 확장성을 제공하기 위한 critical-script vite 플러그인의 개발 과정과 기술적인 도전, 그리고 유용하게 활용할 수 있는 사례를 소개합니다.

현대의 웹 프론트엔드는 webpack, vite 같은 거대한 번들러 생태계가 형성되면서, 번들이라는 개념이 보편화되었습니다. 모든 코드를 번들에 넣는 것을 자연스럽게 생각하는 시대가 되며, 번들의 바깥 세상인 인라인 스크립트를 고도화하기 위한 발상이나 오픈소스 도구는 아쉽게도 찾아보기 어려운 상태입니다.

인라인 스크립트는 웹 프론트엔드에서 로딩 성능(LCP) 개선과 스켈레톤 UI를 고도화할 때 유용합니다. critical-script 도구를 커뮤니티에 오픈소스로 공개함으로서 노하우를 공유하고, 웹 프론트엔드 생태계에 로딩 성능 개선 전략의 대안으로 제시합니다.

논문 및 문학 작품의 초고와 최종 출판물은 대학, 학회, 저널, 개인 홈페이지 등 여러 곳에서 공개됩니다. 하지만 그것들이 얼마나 오래 남을 수 있는지는 여전히 특정 기관의 서버와 운영 정책에 크게 의존합니다. 아카이브의 편의성과 신뢰성 역시 기관마다 다릅니다.

von (아이슬란드어로 "희망" 을 의미합니다) 은 이 문제에서 출발한 분산형 문서 아카이빙 프로젝트입니다. 중앙의 아카이빙 서버 하나가 문서의 존속과 접근을 결정하는 구조 대신, Nostr와 같은 개방형 프로토콜에 문서의 메타데이터를 기록하고 배포하며, 실제 파일은 IPFS를 비롯한 content-addressable network를 통해 보존하는 방식을 실험해 왔습니다. 여기에 OpenTimestamps를 이용한 시간 증명을 결합하여, 저자가 특정 웹 서비스나 기관을 신뢰하지 않고도 자신이 어느 시점에 문서를 공개했다는 사실을 남길 수 있도록 하는 것이 von의 목표 중 하나입니다.

이러한 방향은 최근의 IndieWeb 운동과도 맞닿아 있습니다. 저자와 작은 공동체가 자신의 출판물과 배포 수단에 대한 통제권을 유지하면서도, 공개 프로토콜을 통해 발견, 배포, 보존을 가능하게 하는 구조를 지향합니다. 이상과 구인회처럼 소수의 작가들이 자발적으로 모여 글을 발표하고 하나의 출판 공동체를 만들어 가던 동인 문학의 전통을 이어가는 것은 이 프로젝트의 중요한 원동력입니다.

von을 만들면서 뜻을 함께하는 서울과 요코하마의 작가, 개발자들과 DMRG(Digital Metaphysics Research Guild)라는 작은 문학/기술 그룹을 만들었고, 프로젝트의 개발뿐 아니라 서버 운영, 문서 출판, 비용 분담과 의사 결정까지 함께 고민하게 되었습니다. 이 과정에서 nrpl.dmrg.io에 von 인스턴스를 구축하고, 이를 바탕으로 DMRG의 문예지 N. R. P. L.을 만들어 가기 시작했습니다. 몇 사람이 시작한 소프트웨어가 공동의 프로젝트가 되고, 다시 그 프로젝트를 중심으로 작은 작가와 연구자 공동체를 연결하려는 구상으로 발전하는 과정을 겪었습니다.

이 과정에는 FOSS for All도 영향을 주었습니다. 이전 컨퍼런스에서 다른 오픈소스 프로젝트들의 발표를 들으며 얻은 아이디어를 von의 구조와 운영 방식에 적용하기도 했고, 프로젝트를 공개적으로 설명하는 과정에서 우리가 무엇을 만들고 있는지 다시 생각하게 되기도 했습니다.

이번 세션에서는 von이 왜 중앙집중형 아카이브를 문제라고 보았는지, Nostr와 content-addressable storage, OpenTimestamps를 어떤 방식으로 조합했는지 소개합니다. 동시에 DMRG가 von을 개발하고 운영하면서 겪은 시행착오와 의사 결정, 오픈소스 프로젝트에 사람들이 모이고 때로는 떠나는 과정, 그리고 하나의 소프트웨어를 소규모 작가 공동체들의 연맹을 위한 기반으로 발전시키려는 현재의 구상도 함께 이야기하고자 합니다.

Drafts and final publications of academic papers and literary works are hosted across many different places, including universities, academic societies, journals, and personal websites. How long they remain available, however, still depends heavily on the servers and operational policies of individual institutions. The accessibility and reliability of archives therefore vary considerably from one institution to another.

von, which means “hope” in Icelandic, is a distributed document archiving project that began from this problem. Instead of relying on a single centralized archive server to determine the continued existence and accessibility of documents, von uses open protocols such as Nostr to store and distribute metadata, while leaving file preservation to content-addressable networks such as IPFS. By combining this with timestamp proofs through OpenTimestamps, von also aims to let authors establish that a work was made public at a particular point in time without having to trust or operate a specific web service or institution.

This direction also aligns with the recent IndieWeb movement. We aim for a structure in which authors and small communities can retain control over their publications and means of distribution, while open protocols enable discovery, distribution, and preservation. Another important driving force behind the project is the tradition of literary circles, in which small groups of writers, such as Yi Sang and Guinhoe, gathered voluntarily to publish their work and build their own publishing communities.

While developing von, we formed a small literary and technical group of like-minded writers and developers in Seoul and Yokohama called DMRG, the Digital Metaphysics Research Guild. Our work gradually expanded beyond software development itself to include server operations, publishing, cost sharing, and collective decision-making. As part of this process, we set up a von instance at nrpl.dmrg.io and began using it to build N. R. P. L., DMRG's literary magazine. What began as software built by a few people developed into a shared project, and eventually into an attempt to connect small communities of writers and researchers around that project.

FOSS for All has also influenced this process. Ideas from sessions at previous conferences have found their way into von's architecture and operating model, and the process of presenting the project publicly has often forced us to reconsider what exactly we are trying to build.

In this session, we will explain why von treats centralized archives as a problem, and how it combines Nostr, content-addressable storage, and OpenTimestamps. We will also discuss the experiments, setbacks, and decisions we encountered while developing and operating von, the process by which people join and sometimes leave an open source project, and DMRG's current attempt to develop von into infrastructure for a federation of small writer communities.

또한 참조하세요:

• DMRG의 von 인스턴스 (Webzine)
• https://tangled.org/0xlet0.dmrg.yokohama/von
• https://dmrg.nrpl.xyz/

널리 사용되는 오픈소스 프로젝트에 기여하는 것은 즐거운 일이지만 막상 시작하려면 여러 진입 장벽과 매끄럽지 않은 온보딩 경험 등으로 마찰열이 발생해 소중한 운동에너지가 손실됩니다. Rust 컴파일러 팀 구성원인 발표자가 개인적인 경험을 바탕으로 독자 연구한, 이러한 비효율을 줄일 수 있을지도 모를 각종 민간요법을 소개합니다.

프론트엔드에서 데이터를 다루는 일은 여전히 불편합니다. localStorage는 5MB짜리 문자열 창고이고, IndexedDB는 JOIN 한 번 하려면 커서를 돌려야 하며, 진짜 데이터베이스는 늘 서버 너머에 있습니다.

이 발표에서는 브라우저 안에 숨어 있는 파일시스템(OPFS) 위에 오픈소스 Rust 임베디드 DB를 얹어, 프론트엔드를 위한 SQL 데이터베이스를 만든 과정을 공유합니다. GlueSQL.js에 기여하며 실제로 배포까지 마친 이야기입니다. 쓰는 쪽에서는 import 한 줄과 SQL이 전부입니다.

다루는 내용

오프닝 — 일단 보여드립니다 (3분)

• 발표를 데모로 시작합니다. 브라우저에서 SQL로 테이블을 만들고, 새로고침과 브라우저 재시작 후에도 데이터가 남아 있는 것을 보여드립니다. 서버는 없습니다.

Sector 1 — 왜 만들었나 (4분)

• localStorage와 IndexedDB로 데이터를 다루면서 아쉬웠던 점들을 짚어봅니다. 데이터에 관계가 생기는 순간 조회 코드가 금방 복잡해집니다.
• 같은 일을 SQL로 하면 GROUP BY 한 줄이면 됩니다. WASM으로 브라우저 SQL이 부활하고 있는 흐름도 짧게 소개합니다.

Sector 2— GlueSQL.js로 할 수 있는 것들 (12분)

• gluesql/opfs — 오프닝에서 본 영속성입니다. import 한 줄이면 되고, 용량은 GB 단위, 쿼리는 Worker에서 돌아 UI를 막지 않습니다. namespace 옵션으로 앱마다 DB 파일을 분리할 수도 있습니다.
• gluesql/opfs/shared — 탭을 몇 개 열어도 하나의 DB입니다. 내부에서는 리더 선출과 failover가 돌아가지만, 코드는 import 한 줄만 바꾸면 됩니다.
• 라이브 데모: 탭 3개가 하나의 DB에 쓰다가 리더 탭을 강제 종료해도, 옆 탭이 이어받아 계속 동작합니다.
• 스토리지 선택 가이드 — 데이터 성격에 따라 memory / localStorage / opfs / opfs/shared를 골라 쓰고, 서로 다른 스토리지의 테이블을 JOIN으로 묶을 수도 있습니다. SQL은 전부 동일합니다.
• 백엔드가 생겨도 같은 파일 포맷이라 파일 복사로 옮길 수 있습니다. Node.js에서도 같은 SQL이 돌아 테스트 코드에 그대로 쓸 수 있습니다.
• npm install gluesql로 바로 시작할 수 있습니다.

Sector 3 — 어떻게 만들었나 (8분)

• OPFS는 동기 API인데 Worker에서만 쓸 수 있습니다. 이 제약을 Worker 프록시 구조로 풀어낸 과정을 설명합니다.
• 스토리지 엔진을 직접 구현했다가 걷어낸 이야기도 합니다. 로그 포맷과 리플레이 복구까지 만들었지만, 유지 비용을 생각해 Rust 임베디드 DB(redb)를 조합하는 쪽으로 바꿨습니다. 어댑터는 메서드 5개면 충분했습니다.

대상 청중

• localStorage와 IndexedDB가 아쉬웠던 프론트엔드·웹 개발자
• 서버 없이 사이드 프로젝트나 프로토타입, 사내 도구를 만들고 싶은 개발자
• OPFS와 WASM 기반 브라우저 DB가 궁금한 개발자
• SQL 기초만 있으면 충분합니다. Rust나 WASM 지식은 필요 없습니다.