네이버플러스 멤버십 해지가 잘 안되어서 고객센터에 전화했다. 몇 차례의 좌절 끝에 비밀통로를 발견했다.

Fedify에 꽤 예전 버전부터 존재했던 보안 취약점(CVE-2025-54888)이 어제 저녁에 발견되어서 (Ghost 팀에서 보고해 줬다), 오늘 아침에는 각종 관련 소프트웨어에 모두 보안 패치를 적용하느라 푸닥거리를 엄청 했다.

• 일단 Fedify 1.3 버전 대부터 존재했어서, Fedify 1.3.20, 1.4.13, 1.5.5, 1.6.8, 1.7.9, 1.8.5 버전을 릴리스해야 했고…
• Hollo 0.4 버전 대부터 해당 취약점이 존재하는 Fedify 버전을 사용했어서, Hollo 0.4.12, 0.5.7, 0.6.6 버전을 릴리스해야 했다.
• BotKit도 첫 버전인 0.1 버전 대부터 해당 취약점의 영향을 받아서, BotKit 0.1.2, 0.2.2 버전을 릴리스해야 했다.
• Hackers' Pub의 Fedify 버전도 물론 업데이트해야 했다.
• Ghost를 비롯해 주변에 Fedify를 쓴다는 것을 내가 알고 있는 분들에게는 따로 사적으로 연락을 취했다.
• 각종 채널에 보안 패치 안내를 올리는 것도 일이었다…

다 하고 나니까 오전이 사라져 있었다.

With Linux 6.16 now out in the wild, it’s time for yet another progress report! As we mentioned last time, the Asahi and Honeykrisp Mesa drivers have finally found their way upstream. This has resulted in a flurry of exciting GPU-related work. And now we've got merch!

As always, we want to thank everyone who support us as none of this would be possible without your generous support.

https://asahilinux.org/2025/08/progress-report-6-16/

정보 리터러시 관련 의견을 보존하러 왔다. 우리는 흔히 영어 자료가 한국어 자료보다 낫다는 문화사대주의적 의견에 공감하곤 한다. 하지만 여기엔 숨은 의견이 여럿 있다. 하나씩 까보며 음미해보자.

영어 자료는 한국어 자료보다 낫다. => 왜 나을까? 도움이 되기 때문에. 왜 도움이 될까? => (진실에 가깝기 때문에, 다양한 경험이 전시되어 있기 때문에). 왜 진실에 가까울까? => 1차 출처에 가깝기 때문에. 왜 1차 출처에 가까울까? => 사용자가 다수이기 때문에 직접 사용하거나 번역되어 2차 출처로 기능하기 때문에. 왜 다양한 경험이 있을까? => 생산자가 자료 작성 시 영어를 선택할 확률이 한국어보다 높기 때문에.

그렇다면 우리는 영어 자료가 나은 이유를 구체적으로 표현할 수 있다.

• (일반적으로) 한국어 웹보다 영어 웹이 더 크기 때문에 원하는 자료를 구할 확률이 더 높다.
• (일반적으로) 한국어 웹보다 영어 웹에서 1차 출처에 가까운 자료를 구할 확률이 더 높다.

탐색 공간을 넓히고, 정보 전파 과정에서의 왜곡을 줄이기 위해서 영어 웹 탐색이 효과적이다. 다만 영어 웹이 "언제나" 좋은 건 아니다. 한컴오피스 자료가 미국에 많겠는가, 아니면 한국에 많겠는가? 1차 출처에 가까운 곳을 향해 왜곡을 줄이고, 그 안에서 탐색 공간을 최대한 효율적으로 넓혀야 한다.

영어 검색이라는 피상적인 행위에서 벗어나 정보 탐색의 본질을 좇는 것이 좋다.

Next Asahi Linux progress report is up. We're finally below 1000 downstream patches and have a a fully upstream (userspace) graphics stack :)

https://asahilinux.org/2025/08/progress-report-6-16/

#asahilinux

오랜만에 프로그래밍 언어 이야기하러 왔다. 오늘 주제는 타입스크립트의 핵심 가치다.

많은 사람들이 정적 타입 언어를 도입하는 이유로 안전성(Soundness)를 이야기한다. 맞는 말이다. 하지만 타입스크립트에서 안전성은 2등 가치다. 그럼 1등 가치는 뭘까?

바로 개발 경험 개선이다. 구체적으로, 오류 나기 쉬운 구문을 적당히 줄이고 자동 완성을 개선하며 큰 규모 리팩토링 시 심리적(그리고 any 같은 기능을 안 썼다는 가정하에 런타임에도 유의미한 수준의) 안정성을 얻겠다는 거다.

타입스크립트 공식 위키 문서에도 안전성은 목표가 아니라고 나와있다 (#). 우리는 때때로 도구의 목적에 들어맞지 않는 불필요한 기대를 하곤 한다. 하지만 도구 개발자와 싸우는 건 사용자로서 좋은 전략이 아니다.

조건부 타입과 재귀 타입, 템플릿 문자열 타입, infer 등을 보라. 정적 분석 난이도가 지수적으로 올라가는 희한한 기능들이 언어에 계속 추가되는 이유가 무엇인가. 추론을 포기하고 any가 나오곤 하는 이유가 무엇인가.

그들이 추구하는 게 안전한 세계가 아닌 실용적인 세계이기 때문이다.

We're thrilled to announce Fedify 1.8.1, a mega release made possible through the incredible efforts of contributors from South Korea's #OSSCA (Open Source Contribution Academy). This release marks a significant milestone in #Fedify's development, bringing major architectural changes, new packages, and numerous enhancements across the board.

Note: Version 1.8.0 was skipped due to a versioning error.

🎉 Major Milestone: Monorepo Architecture

Fedify has been restructured as a #monorepo, consolidating all packages into a single repository with unified versioning. This change streamlines development and ensures all packages are released together with consistent version numbers.

Consolidated Packages

All existing Fedify packages now live under one roof:

• @fedify/fedify — Main library
• @fedify/cli — CLI toolchain
• @fedify/amqp — AMQP/RabbitMQ driver
• @fedify/express — Express integration
• @fedify/h3 — h3 framework integration
• @fedify/postgres — PostgreSQL drivers
• @fedify/redis — Redis drivers

🆕 New Packages

This release introduces four new packages to the Fedify ecosystem:

• @fedify/elysia — Elysia integration for Bun-powered applications
• @fedify/nestjs — NestJS integration for enterprise Node.js apps
• @fedify/sqlite — SQLite driver compatible with Bun, Deno, and Node.js
• @fedify/testing — Testing utilities with mock Federation and Context classes

@fedify/fedify

Custom Collection Dispatchers

A powerful new feature that allows you to create custom collections beyond the standard ActivityPub collections. This enables implementation of domain-specific collections while maintaining federation compatibility.

Contributors: ChanHaeng Lee [#310, #332]

• Added comprehensive types and interfaces for custom collection handling
• New methods on Federatable interface: setCollectionDispatcher() and setOrderedCollectionDispatcher()
• Added getCollectionUri() method to the Context interface
• Full support for paginated custom collections

Compare-and-Swap (CAS) Support for KV Stores

Key–value stores now optionally support CAS operations for atomic updates, enabling optimistic locking and preventing lost updates in concurrent environments.

• Added optional KvStore.cas() method
• Implemented in MemoryKvStore and DenoKvStore
• Useful for implementing distributed locks and counters

Fediverse Handle Utilities

New utility functions make working with #fediverse handles more convenient.

Contributors: ChanHaeng Lee [#278]

• parseFediverseHandle() — Parse handles into components
• isFediverseHandle() — Validate handle format
• toAcctUrl() — Convert handles to URLs
• FediverseHandle interface for type safety

Enhanced HTTP Request APIs

Contributors: Lee ByeongJun [#248, #281], Hyunchae Kim [#51, #315]

• Added LookupWebFingerOptions.maxRedirection option for controlling redirect behavior
• APIs now support AbortSignal for request cancellation
• New DocumentLoaderOptions interface
• Added signal options to LookupObjectOptions, LookupWebFingerOptions, and DoubleKnockOptions

@fedify/cli

New Commands and Enhancements

The CLI has received significant improvements thanks to our OSSCA contributors:

fedify webfinger Command

Contributors: ChanHaeng Lee [#260, #278], KeunHyeong Park [#311, #328]

Look up WebFinger information for any fediverse resource:

• Supports handles (@user@server) and URLs
• --user-agent option for custom User-Agent headers
• --allow-private-address for local testing
• --max-redirection to control redirect following

fedify nodeinfo Command

Contributors: Hyeonseo Kim [#267, #331, #168, #282, #304]

Replaces the deprecated fedify node command with improved terminal rendering.

Enhanced fedify lookup Command

Contributors: Jiwon Kwon [#169, #348, #261, #321]

• Terminal-specific image display for Kitty, WezTerm, Konsole, Warp, Wayst, st, and iTerm
• -o/--output option to save results to files

Improved fedify inbox Command

Contributors: Hasang Cho [#262, #285], Jang Hanarae [#191, #342]

• --actor-name and --actor-summary options for customizing temporary actors
• Now displays object types contained in activities

fedify init --dry-run

Contributors: Lee ByeongJun [#263, #298]

Preview project initialization without creating files.

Better Terminal Support

Contributors: Cho Hasang [#257, #341]

Correctly handles color output based on TTY detection and NO_COLOR environment variable.

@fedify/elysia

Contributors: Hyeonseo Kim [#286, #339]

New Elysia integration brings Fedify to Bun-powered applications with a simple plugin interface:

import { Elysia } from "elysia";
import { fedify } from "@fedify/elysia";

const app = new Elysia()
  .use(fedify(federation, { /* options */ }))
  .listen(3000);

@fedify/nestjs

Contributors: Jaeyeol Lee [#269, #309]

Enterprise-ready NestJS integration with dependency injection support:

import { FedifyModule } from "@fedify/nestjs";

@Module({
  imports: [
    FedifyModule.forRoot({
      kv: new MemoryKvStore(),
      queue: new InProcessMessageQueue(),
      origin: "https://example.com",
    }),
  ],
})
export class AppModule {}

@fedify/sqlite

Contributors: An Subin [#274, #318]

SqliteKvStore implementation compatible across all major JavaScript runtimes:

import { SqliteKvStore } from "@fedify/sqlite";

const kv = new SqliteKvStore("./fedify.db");

@fedify/testing

Contributors: Lee ByeongJun [#197, #283]

Comprehensive testing utilities with mocking support for Fedify applications:

import { MockFederation, MockContext } from "@fedify/testing";

const mockFederation = new MockFederation();
const mockContext = new MockContext();

// Track sent activities with full metadata
// Support custom path registration
// Multiple activity type listeners

🙏 Acknowledgments

This release represents an extraordinary community effort, particularly from the participants of South Korea's OSSCA (Open Source Contribution Academy) (Note: page in Korean). We extend our heartfelt thanks to all contributors:

Core Contributors

• ChanHaeng Lee (@2chanhaeng이찬행) — Custom collections, fediverse handles, WebFinger command
• Lee ByeongJun (@joonnotnotJoon) — WebFinger redirections, dry-run, testing utilities
• Hyunchae Kim (@r4bb1t) — AbortSignal support
• Hyeonseo Kim (@gaebalgom개발곰) — Elysia integration, nodeinfo command
• Jaeyeol Lee (@kodingwarriorJaeyeol Lee) — NestJS integration
• An Subin (@nyeongAn Nyeong (安寧)) — SQLite driver
• Jiwon Kwon (@z9mb1wwj) — Terminal image display, output options
• Hasang Cho (@crohasang크롸상) — Color output handling, actor customization
• Jang Hanarae (@meneleHanal Ae) — Activity object type display
• KeunHyeong Park (@w8385박근형) — WebFinger redirect options

Test Infrastructure Contributors

• Oh Daeun (@ooheundaoed) — Fixed PostgreSQL test race conditions [#346, #350]
• Song Hanseo (@songbirds) — Test stability improvements for Redis and code generation [#344, #347]
• Kim Jonghyeon (@woaol벨) — CLI version management and documentation fixes [#306, #329, #330, #343]

Your contributions have made Fedify stronger and more versatile than ever. The OSSCA program's support has been instrumental in achieving this milestone release.

Migration Guide

Updating from Previous Versions

If you're using separate Fedify packages, update all packages to version 1.8.1:

{
  "dependencies": {
    "@fedify/fedify": "^1.8.1",
    "@fedify/cli": "^1.8.1",
    "@fedify/express": "^1.8.1"
  }
}

All packages now share the same version number, simplifying dependency management.

Breaking Changes

There are no breaking changes in this release. All existing code should continue to work without modifications.

What's Next

With the monorepo structure in place and new integrations available, we're excited to continue improving Fedify's developer experience and expanding its capabilities. Stay tuned for more updates, and thank you for being part of the Fedify community!

For detailed technical information about all changes, please refer to the full changelog.

Fedify is an open-source project that helps developers build federated server applications powered by ActivityPub. Join us on GitHub or Discord to contribute or get help!

#opensource #fedidev

Kosmo: @robin 님께서 만들고 계시는 차세대 연합우주 SNS 👀

그나저나 Hackers' Pub 마스코트 고양이에 아직 이름이 없는데, 어떤 이름을 지어 주면 좋을까요? 🤔

맥 마이그레이션을 할 땐 썬더볼트 케이블을 사용하기로 해요.

를 더 명확하게 관리하기 위해서라도 Relay같은 물건이 필수적으로 보이는데, React 바깥에서 제대로 사용하기 좀 어려워서 고민임

srvx에 기여했다!

https://github.com/h3js/srvx/releases/tag/v0.8.3

DBMS 같은 데에서 파일을 관리 할 때엔 항상 4096 바이트 단위의 페이지 형태로 관리합니다. 왜그럴까요? 여러가지 이유가 있는데, 보통은 OS도 4096 바이트 단위로 파일 시스템을 관리하기 때문입니다. 그래서 캐시 같은 OS의 여러 가속 장치들의 도움을 받을 수 있죠.

근데 정말로 그럴까요?

그게 궁금해서 직접 한번 페이지 파일 매니저를 구현해서 실험해봤습니다. 통계적으로 유의하게 빠르네요.

Fedify를 활용하여 제가 만드는 텍스트 전용 블로깅 플랫폼인 타이포 블루에 연합우주 기능을 구현했습니다. 많은 관심 부탁드립니다!

요즘 gemini-cli를 많이 쓰고 있는데 이게 TUI라서 복붙 같은 것도 미묘하게 잘 안 되고 텍스트도 깨지고 하는 게 짜증난 나머지 내 코딩 에이전트를 만들겠답시고 Angel이라는 걸 만들기 시작했다. https://github.com/lifthrasiir/angel

소프트웨어 스택은 Go + TypeScript + React. 프론트엔드를 내가 만들어도 되지만 사실 React에 그렇게 자신이 있는 건 아니라서 100% 바이브 코딩을 해 보겠다는 목표로 하고는 있는데 결국 디버깅은 내가 다 하고 있다는 함정이 있다. 이를테면 사진에 나와 있는 코드는 JS에서 String.prototype.split이 받는 limit 인자의 해석 관련된 질문인데 이거랑 관련된 버그로 2시간 정도를 날렸다. (JS는 놀랍게도 'a,b,c'.split(',', 2) 하면 ['a','b']가 나온다. ['a','b,c']가 아니라!!!! 그럼 왜 처음에 그렇게 짜 줬는데???)

참고로 전면 개편 중인 Hackers' Pub 프런트엔드도 SolidStart 기반입니다!

Hackers' Pub의 로고 디자인이 완료되었습니다! 디자인은 박은지 님(@murinono무리노노)께서 해주셨습니다.

연합우주라는 콘셉트에 맞게 고양이의 입 주변을 별 모양으로, 목 아래에도 고리(orbital ring) 모양으로 디자인했습니다. 고양이를 고른 이유는 소프트웨어 프로그래머 커뮤니티에서 다른 동물보다 유독 고양이가 사랑 받기 때문이기도 하고, 고양이가 호기심이 강하기 때문이기도 합니다.

로고 디자인은 CC-BY-SA 4.0 라이선스로 배포됩니다.

SMC made it just in time for the merge window! Now it's finally possible to reboot M1/M2 with an upstream kernel ;)

This also allows to enable the power gpios for e.g. wifi and allows us to upstream drivers for the power button, hardware sensors, battery status and RTC next.

https://lore.kernel.org/asahi/175334693659.1935861.13683239351116261977.b4-ty@kernel.org/

#asahilinux

한창 개발중인 다음 버전의 Hackers' Pub입니다. 프런트엔드를 전면 개편하고 있습니다. 프레임워크도 Fresh에서 SolidStart로 아예 바꿨습니다.

Hackers' Pub 전면 개편 준비하며 배우는 Relay. 배울 가치가 있는 기술 같다. 모바일 네이티브 앱 개발에도 Relay가 생겼으면.

I switched from IBus to Kime (https://github.com/Riey/kime — a Korean IME written in Rust 🦀). I can now input Korean flawlessly in Wayland + Niri + Flatpak. #kime #ibus #ko #linux

제가 꾸준히 개발하고 운영하는 서비스들을 소개합니다.

• 나루: 한국의 Geocities/Neocities를 지향하는 개인 웹사이트 호스팅 플랫폼
• 오이카페: 2000년대 인터넷 감성을 느낄 수 있는 오에카키 커뮤니티
• 타이포 블루: 메일링 리스트 기능을 지원하는 텍스트 전용 블로깅 플랫폼

모두 공익을 위한 비영리 프로젝트이며, AGPLv3 하에 소스 코드가 공개되어 있습니다.

이와 비슷하게 청개구리 스택 경로라는 것도 생각해 볼 수 있겠다. 예를 들어 Deno를 선택했으면 Fresh는 청개구리 스택 경로가 아니다. 그런데 Deno를 선택한 다음 Next.js를 선택하면 오히려 청개구리 스택 경로가 된다.

여성향 커미션 중개 플랫폼 크레페를 운영하는 쿠키플레이스에서 시니어 백엔드 엔지니어 채용을 진행중입니다. 채용공고에 해당 직무 소개, 복지, 연봉, 회사문화의 내용이 포함돼 있습니다. 많은 관심 부탁드립니다. Node.js, TypeScript, GraphQL에 대한 높은 숙련도 및 지식으로 팀에 기여해주실 분을 쿠키플레이스에서 극진히 기대하고 있습니다.

크레페에서는 이런 기술스택을 사용합니다

• Node.js, TypeScript, Vitest, Fastify
• GraphQL 　- Yoga, Relay, Pothos, Prisma
• ElasticSearch, MongoDB, FCM
• Docker, Github Actions
• AWS 　- ElasticBeanstalk, CloudWatch, Aurora PostgreSQL, Lambda, SES, S3, ElastiCache (Redis)
• Grafana, Sentry

구성원의 성장과 덕질을 지원해요

• 희망 도서 구매 (만화책 및 TRPG 룰북 포함)
• 워크샵 및 교육 프로그램 지원
• 전시, 공연 및 각종 행사 티켓 지원
• 월 5만 크레페 포인트
• 전동작탁 AMOS JP-EX COLOR
• 6인용 TRPG/보드게임 테이블

지원자님이 예상하실 수 있는 처우는 이래요

• 연봉: 최소 8000만원 ~ 최대 2억원 (주 40시간)
• 스톡옵션 부여에 열려있는 포지션

Node.js 커뮤니티는 환경 변수를 너무 좋아하는 것 같다. 거의 라이브러리 API의 일부로 생각하는 듯?

Deno만 해도 환경 변수는 --allow-env 플래그를 통해 명시적으로 허용하지 않으면 접근 못하고, Haskell에서도 getEnv는 String이 아니라 IO String을 반환하게 되어 있다.

반면 Node.js에서는 process.env로 너무 쉽게 접근 가능해서 그런가, 환경 변수 접근이 입출력이라는 생각을 아예 안 하는 모양이다.

JS Error 클래스에

class Error {
  ...
  throw() {
    throw this
  }
}

이런 메소드 있으면 편할 것 같은데 왜 없지? 예를 들면:

# 현재
const user = findUser();
if (!user) {
  throw new Error("Not found user");
}

# `throw` 메소드
const user = findUser() ?? new Error("Not found user").throw();

이렇게 쓸 수도 있고 이름 별로면 raise 써도 되고 TC39 에 한번 제안해볼까...

Fresh 못 써먹겠는 많은 이유 중 하나: 가끔 빌드 결과가 Chromium 계열 브라우저에서 하이드레이션이 실패하는 형태로 나온다. 골 때리는 건 빌드 자체도 비결정적이라서 똑같은 소스 코드 그대로 다시 빌드하면 해결된다는 것…

Biome 2.1 has been released!

It's a relatively minor maintenance release, but still has some goodies:
* Faster scanner
* Improved type inference
* New rules
* Many fixes!

https://biomejs.dev/blog/biome-v2-1/

아는 친구한테 들은 얘기인데, 최근 이직한 회사에서 Python을 쓰는데 린트나 포매터 같은 것도 전혀 설정을 안 해놓고 살고 있기에 도입하자고 했더니 “그런 거 쓸 거면 Python 안 쓰죠”라는 말과 함께 제안을 거절 당했다고 한다. Python에서도 린트나 포매터는 물론이고 타입 체커까지 붙여서 살려면 살 수 있지만, 어쩐지 그런 거 신경 쓸 사람들은 최근 10년 사이에 다들 다른 언어로 넘어가 버리고 그런 거 신경 안 쓰는 사람들만 Python을 계속 쓰게 된 게 아닌가 싶은 생각이 들었다.

@hongminhee洪 民憙 (Hong Minhee)

그런 거 쓸 거면 Python 안 쓰죠

프로그래밍 언어의 언권?투사가 되게 만드는 발언이군요. 어떤 프로그래밍 언어든 저런 취급을 받아선 안됩니다. 설령 PHP, 아니 Brainfuck이라고 하더라도 린터와 포매터는 갖추고 살아야합니다.

슬프게도 한국의 일정이상 연차 FE 인재들은 두개의 대타트업들이 다 빨아간 것으로 판단이 된다.

deno bundle이 돌아온 건 좋은데, 어째서 Rust로 만든 Rolldown 기반이 아니라 esbuild 기반인 걸까? 🤔

이전에 다녔던 회사들에서 채용이 무너지면 회사도 무너지는 것들을 몇번 경험해서 채용에 상당히 신중한 편인데, 신중하게 뽑은 분은 역시 모셔오기 어려웠다. 그야말로 양극화의 시대다.

최근 한 달 동안 분석한 이슈의 결론이 물리 세계 때문이라는 결론이 나기 직전입니다. 측정값이 예상보다 오차가 훨씬 크게 날 수 있다 + 랜덤 생성기가 사실 충분히 랜덤이 아니었다의 환장의 콜라보... 모든 것이 예상 가능하게 돌아가는 컴퓨터 세상에서 살고 싶어요... 🤬🤬

I think the @fedifyFedify: an ActivityPub server framework project has now reached full maturity. What this means is that all the low-hanging fruit has been addressed, and only the difficult problems remain. 😂

요즘 트위터에 하스켈 관련 계정들보면 Go를 가장 싫어하는 언어로 꼽는 경우를 자주 본다. C/C++/Java 등은 역사적인 맥락을 고려해 예우해주고, Python/JS 등등의 이상한 기능은 뭘 몰라서 잘못 만들었다고 이해해주는 반면, Go는 하스켈러들이 중요하게 여기는 가치들을 일부러 다 무시하고 만들기 때문에 괘씸가중치 x10 정도를 적용받는 듯하다.

잘 못만든 선언형 인터페이스보다는 잘 못만든 명령형 인터페이스가 낫다. 후자는 피똥싸면서 뭔가를 어찌저찌 해낼순 있는데, 전자는 아예 뭔가를 하는게 불가능한 경우가 많다.

Bun이 자꾸 웹 표준 API 사이에 슬쩍 비표준 API 추가하는 게 마음에 안 든다.

Javascript Weekly 뉴스레터에 @hongminhee洪 民憙 (Hong Minhee) 님의 Logtape가 소개되었습니다

나는 리액트에서 성능 자체가 떨어지는 부분보다(제대로 체감한적 없음), 성능을 고려해서 컴포넌트를 일부러 나눠야하는 점이 더 맘에 안든다.

오픈소스 프로젝트에 여러분의 gemini cli(등등)의 무료 사용량을 기여하세요

오픈소스 소프트웨어라는 소프트웨어 개발 방법은 그동안 대성공을 거두어 오고 있습니다. 여기에는 여러 요인이 있지만, 중요한 요인 중 하나는 이것입니다. 상업 소프트웨어든 오픈소스 소프트웨어든 공평하게 프로그래머의 시간을 들인 만큼 개발된다는 것이지요. 능력 있는 소프트웨어 개발자가 시간을 기여하면 오픈소스 소프트웨어는 상업 소프트웨어만큼이나 빠르게 성장할 수 있었습니다.

하지만 AI 프로그래밍의 시대가 빠르게 다가오고 있습니다. 앞으로 소프트웨어 개발은 프로그래머의 시간만으로 개발되지 않습니다. 상업소프트웨어는 AI 프로그래밍을 적극적으로 사용하여 이전과 다른 생산성으로 개발되기 시작할 것입니다. 상업 소프트웨어와 달리 오픈소스 소프트웨어는 언제나 그럴 수는 없습니다. 프로젝트의 성장과 유지를 위해 훌륭한 프로그래머들의 시간을 들이는 것을 넘어서, 훌륭한 프로그래머들이 시간에 더해 비용까지 들여야 한다면요.

상업 소프트웨어와 오픈소스 소프트웨어 사이의 불균등한 생산성의 시대가 코앞까지 다가오고 있습니다.

새로운 기여자 확보의 문제

문제는 여기서 그치지 않습니다. 오픈소스 프로젝트는 새 기여자를 얻기 더 힘들어져가고 있습니다. 왜냐하면 이제 'good first issue'라는 것은 의미가 없기 때문입니다. 그 정도로 쉬운 일은 새로운 기여자 대신 로봇이 해결할 가능성이 높고, 그 로봇은 새로운 기여자의 로봇일 수도 있습니다. 결국 AI 프로그래밍으로 기여하는 새 기여자는 이 프로젝트에 대해 거의 배우지 못하게 됩니다.

전통적인 오픈소스 생태계에서 'good first issue'는 단순히 쉬운 문제를 해결하는 것이 아니었습니다. 새로운 기여자가 프로젝트의 코드베이스를 이해하고, 개발 프로세스를 익히며, 커뮤니티와 소통하는 법을 배우는 학습 과정이었습니다. 하지만 AI가 이런 단순한 작업들을 대신 처리하게 되면, 새로운 기여자들은 진입 기회를 잃게 됩니다.

AI 프로그래밍의 현재 위치

AI 프로그래밍은 완벽하지 않습니다. 숙련된 전문가가 숙련된 도메인에서 작업하는 것만큼 잘하지는 못합니다. 하지만 비숙련된 프로그래머가 처음 보는 프로젝트에서 작업하는 것보다는 잘할 때가 많습니다.

그러나 많은 오픈소스 소프트웨어는 바로 이런 비숙련 기여가 성장의 한 축을 차지합니다. 처음 프로젝트에 참여하는 개발자들의 작은 기여들이 모여 거대한 프로젝트가 됩니다. 그리고 이런 비숙련 기여의 일부는 손쉽게 AI가 대체할 수 있는 기여입니다.

다행히도 지금은 AI 프로그래밍의 초창기입니다. Gemini CLI가 무료 사용량을 제공하듯이, 앞으로 여러 회사들이 비슷한 기회를 제공할 것입니다. Claude, ChatGPT, Copilot 등 다양한 AI 도구들이 개인 사용자에게 무료 크레딧을 제공하고 있습니다.

이것은 오픈소스 프로젝트에 기여할 새로운 기회로 삼을 수 있을까요?

주의: 이 글은 아무 프로젝트에나 방문해서 AI로 적당한 코드를 생성한 다음 패치를 보내라는 뜻이 아닙니다.

AI 프로그래밍은 (아직은) 마법이 아닙니다. "이 프로젝트를 겁나 멋지게 만들 기능을 추가해주세요"라고 한다고 해서 그런 패치가 나오는 식으로는 동작하지 않습니다.

이상적인 경우: AI 친화적 프로젝트

가장 좋은 방법은 프로젝트가 AI 친화적으로 준비되는 것입니다. 바로 작업할 수 있을 만큼 잘 정의된 이슈들이 있는 프로젝트라면, "nnn 번 이슈에 대해 작업해 주세요"라는 요청만으로도 누구나 기여할 수 있을 것입니다.

하지만 (적어도 아직은) 그런 프로젝트가 많지는 않을 것입니다.

현실적인 접근: AI가 잘하는 일들에 집중

대신 AI는 인간과 비대칭적으로 잘하는 기능이 있습니다.

이를테면 이슈에 minimal reproducible case가 보고되어 있지만 아직 구체적으로 발생하는 원인이 밝혀져 있지 않은 경우를 생각해봅시다. 버그를 고치는 사람이 해야하는 지루한 작업 가운데 하나는, 이 문제를 어떻게 수정할지를 생각하기에 앞서 이 문제가 어디서 발생하는지 찾는 것입니다. 디버거를 써야 할 수도 있고, 코드에 많은 trace log를 남겨야 할 수도 있습니다.

하지만 AI 코딩 에이전트는 테스트가 재현 가능하기만 하다면, 문제를 발생시키는 정확한 줄을 찾아내는 데 탁월합니다. 지치지 않고 정석적인 지루한 방법으로 꾸준히 로그를 추가하고 테스트를 다시 실행하면서 문제를 찾아내거든요.

어쩌면 문제의 원인이 아주 단순해서, 문제를 바로 수정할 수 있을지도 모릅니다! 그렇다면 패치를 제출해도 좋겠지요. 하지만 바로 수정하기까지는 어렵더라도 괜찮습니다. 버그 리포트와 실제 코드의 문제를 매핑하는 것은 그 자체로 지루하고 시간이 걸리는 일입니다. 이것을 대신하는 것으로도 큰 작업을 대신하는 것입니다.

주의: 모든 프로젝트가 AI 기여를 환영할 리는 없습니다. 충분히 유용하게 다듬어지지 못한 유형의 AI 기여는 스팸처럼 느껴질 가능성이 있음을 유의해야 합니다.

미래

사실 누구나 자기 라이브러리를 뚝딱 만들어낼 수 있게 되었다는 점에서 오픈소스 프로젝트에 참여하는 사람들의 동기와 기여 방식 자체가 크게 뒤바뀔 가능성이 높습니다.

AI 프로그래밍을 누구나 거의 무료로 사용할 수 있는 시대가 올까요? 아마 어느 정도의 사용량까지는 그럴 것입니다. 그것이 얼마나 많은 양일지에 따라서 오픈소스 프로젝트의 미래는 크게 바뀌겠지요.

만일 정말로 AI 프로그래밍을 누구나 무제한적으로 사용할 수 있다면, 대규모가 아닌 대부분의 오픈소스 프로젝트에는 더이상 협력이 필요하지 않을 것입니다. 진정으로 '어떻게'보다 '무엇을'이 더 중요한 시대가 온다면, 프로젝트의 목표를 확고하게 가진 사람이 극한의 완성도까지 프로젝트를 밀어붙이는 편이 훨씬 좋은 결과를 만들겠지요.

그런 시대가 올지 오지 않을지 모르겠습니다. 하지만 그 전까지는, AI 프로그래밍이 누구에게나 주어지는 기회이지만 프로젝트를 단숨에 완성할만큼 주어지지는 않는 시대가 유지되는 동안에는, 다음 세대의 오픈소스 기여의 방법은 AI 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

클플 뭐 서비스 낼때마다 리전 맨날 Earth 요따구로 해두니까 우주진출 뒤의 클플을 상상하게 됨

#bevy 0.17 is shaping up to be a really exciting release: hot patching, widgets, observers, tilemaps, light textures, transform overhaul... :) Community-driven open source is really wild like that: folks just come along and upset all your plans. Mostly for the better even!