I really like Rust, and I have used it a lot. But when I think about which language to choose for developing with AI, I rank Go highest. It seems to strike the best balance for building a fast verification loop.

Bottlenecks in the iteration loop

AI works incredibly fast. That means even a slightly slow part of the iteration loop can quickly become a bottleneck.

Developing with AI does not mean that AI’s working time—the time when the GPU is running—accounts for an overwhelmingly large share of the total. There are builds to wait for and tests to run.

This is the main reason I rank Go highest. It builds faster than Rust, and it runs things like tests faster than TypeScript. Its runtime performance is also pretty good considering how little time it takes to build.

Fast execution also means less time spent running tests. I also find that Go’s support for parallelism means test times grow much less sharply than they do with TypeScript as a project gets larger.

These days, human QA is the biggest bottleneck for me, and fast builds matter there too. When a build is slow during PR verification, QA slows down with it. Even as someone who likes Rust, I find its build times costly here.

Rust’s checks are valuable, but expensive to pay for every time

Rust catches a lot of problems. Its checks cover far more than Go’s go test -race. As I organize my thoughts for this post, I keep coming back to the feeling that Rust is both good and a bit excessive.

For most projects, I think running concurrency-related tests separately at regular intervals is enough. For something like a database, I would run them routinely, but that would mean shortening the interval. Running them every single time still seems wasteful to me.

The separate checks I have in mind are things like go test -race. I do not mean that these are equivalent to Rust’s compile-time checks. Rust catches much more.

But even recognizing the value of those checks, Rust builds are too slow for me to want to pay that cost every time. I do not think the frequency at which verification is needed always matches the frequency at which a build is needed.

Even good type inference has a cost

Rust’s type inference is a great feature. But when I wrote the code myself, I sometimes struggled to work out the types. I had to look through many files to figure out the right type.

Things were somewhat better when rust-analyzer worked well. But I developed in Rust before it existed, and even after it became available, it did not always work reliably. I still had to work without its help at times.

AI agents are so fast that I expect them to figure out types faster and better than I could. Even so, I do not feel that this gives me a reason to choose Rust when Go is available.

How hard is it to get the performance?

Rust is certainly a language with excellent performance. But using it well is much harder than people tend to think.

Imagine a senior developer unfamiliar with each language being asked by their company to build a highly parallel program in Go, TypeScript, and Rust. I would expect the Go version to be the fastest.

Handling system calls such as file reads efficiently is not particularly difficult in Go, but it is very difficult in Rust.

The difference, as I see it, is in how system calls are handled. Rust is designed to be usable in kernels, and that applies to async Rust as well. I see this design as part of what makes automatically inserting hooks around system calls difficult. Go, meanwhile, provides handling for system calls out of the box.

Unless a highly skilled developer designs the system properly, I think it is difficult to beat the handling Go already provides.

Unfriendly error messages become an advantage

Some of Go’s choices used to make me wonder why the language worked that way. In the AI era, I find those same choices helpful. Build error messages are one example.

Rust and TypeScript helpfully show code snippets in the terminal to explain what went wrong. Go tells you which line has which problem, and that is it. It does not even print every error. When I was coding by hand, I found this really frustrating.

But from an AI agent’s perspective, builds are fast, and the error messages do not consume much context either. The output I once found unfriendly has started to look like an advantage.

When developing with AI, I care about how quickly I can run the whole iteration loop, including builds, tests, and human QA. Right now, Go strikes the best balance for me.

Update: The options are limited

This seemed so obvious that I forgot to mention it when writing this post, but you have to choose a language that AI writes well. That’s why this post focuses on Rust, Go, and TypeScript.

나는 Rust를 정말 좋아하고 많이 써봤다. 그런데 AI와 개발할 때 어떤 언어를 고를지 생각하면, Go를 가장 높게 평가하게 된다. 검증 루프를 빠르게 구성하기에 균형이 가장 잘 맞는 것 같다.

이터레이션 루프의 병목

AI는 작업 속도가 엄청나게 빠르다. 그래서 이터레이션 루프의 구성 요소가 조금만 느려도 금방 병목이 된다.

AI로 개발한다고 해서 전체 작업 시간 중 AI가 일하는 시간, 그러니까 GPU가 돌아가는 시간의 비중이 엄청나게 높은 것은 아니다. 빌드를 기다리고, 테스트 실행을 기다려야 한다.

내가 Go를 가장 높게 평가하는 이유가 여기에 있다. Rust보다 빌드가 빠르고, TypeScript보다 테스트 같은 것들의 실행이 빠르다. 빌드 시간이 엄청나게 짧은 것에 비하면 런타임 성능도 괜찮다.

실행 속도가 빠르다는 것은 테스트를 돌리는 시간도 짧다는 뜻이다. Go는 병렬 처리가 잘 되는 언어라 프로젝트가 커질 때 테스트가 느려지는 정도도 TypeScript보다 훨씬 덜하다고 본다.

요즘은 사람이 수행하는 QA가 가장 큰 병목인데, 이것 역시 빌드가 빨라야 한다. PR을 검증할 때 빌드가 느리면 QA까지 느려진다. Rust를 좋아하는 나도 이 부분에서는 빌드 시간이 부담스럽다.

Rust의 검증은 좋지만, 매번 부담하기에는 무겁다

Rust는 많은 문제를 잡아준다. Go의 go test -race와 비교할 수 없을 정도로 검증 범위가 넓다. 글을 쓰려고 생각을 정리하다 보니, Rust가 좋으면서도 지나치다는 느낌이 든다.

내 생각에는 대부분의 프로젝트에서 동시성 관련 테스트는 주기적으로 따로 돌리면 충분하다. 데이터베이스 같은 프로젝트라면 일상적으로 돌리겠지만, 그것도 주기를 짧게 잡는 것이지 매번 돌리는 것은 낭비일 것 같다.

여기서 별도로 돌릴 검사로 생각한 것은 go test -race 같은 것들이다. 이것이 Rust의 컴파일 시 검증과 동등하다는 뜻은 아니다. Rust는 훨씬 많은 것을 잡아준다.

다만 그 검증의 가치를 인정하더라도, 매번 빌드할 때마다 비용을 부담하기에는 Rust의 빌드가 너무 느리다. 검증이 필요한 주기와 빌드가 필요한 주기가 꼭 같지는 않다고 본다.

좋은 타입 추론에도 비용은 있다

Rust의 타입 추론은 정말 좋은 기능이다. 하지만 사람인 내가 직접 코딩할 때도 타입을 파악하는 데 애먹었다. 올바른 타입을 알기 위해 살펴봐야 하는 파일이 많았다.

rust-analyzer가 잘 작동할 때는 그나마 나았다. 하지만 나는 그것이 없던 시절에도 개발했고, 생긴 뒤에도 항상 제대로 작동하는 것은 아니라 도움 없이 개발하기도 했다.

AI 에이전트는 워낙 빠르니 나보다 타입을 빨리 파악하고, 더 잘할 것이다. 그래도 Go를 두고 굳이 Rust를 고를 이유는 없는 것 같다.

언어의 성능을 끌어내는 난이도

Rust가 성능이 엄청나게 좋은 언어인 것은 맞다. 하지만 사람들이 생각하는 것보다 Rust를 제대로 쓰는 것은 훨씬 어렵다.

예를 들어 각 언어에 익숙하지 않은 시니어 개발자가 회사의 요구로 Go, TypeScript, Rust를 사용해 병렬 처리가 아주 많은 프로그램을 만든다고 해보자. 나는 Go로 만든 프로그램이 가장 빠를 것이라고 예상한다.

파일 읽기 같은 시스템 콜을 고성능으로 처리하는 것이 Go에서는 그리 어렵지 않지만, Rust에서는 정말 어렵기 때문이다.

내가 보는 차이는 시스템 콜을 다루는 방식에 있다. Rust는 커널에서도 쓸 수 있게 설계됐고, async Rust도 마찬가지다. 나는 이런 설계가 시스템 콜에 자동으로 훅을 넣는 처리를 어렵게 하는 배경이라고 본다. 반면 Go는 시스템 콜에 대한 처리를 기본으로 제공한다.

엄청난 실력자가 제대로 설계한 것이 아니라면, Go가 제공하는 처리를 직접 설계해서 이기기는 어렵다고 생각한다.

불친절한 오류 메시지가 장점이 되다

직접 코딩할 때는 Go가 왜 이런 선택을 했나 싶었던 부분도 AI 시대에는 도움이 된다. 빌드 오류 메시지가 그중 하나다.

Rust나 TypeScript는 터미널에 코드 스니펫까지 보여주면서 어떤 오류가 있는지 친절하게 알려준다. Go는 어느 줄에 어떤 문제가 있는지 알려주고 끝이다. 심지어 오류를 전부 출력하지도 않는다. 직접 코딩할 때는 정말 짜증났다.

그런데 AI 입장에서는 빌드도 빠른데 오류 메시지로 컨텍스트를 많이 쓰지도 않는다. 내가 불친절하다고 느꼈던 출력 방식이 오히려 장점으로 보이기 시작했다.

AI와 개발할 때는 빌드, 테스트, 사람이 수행하는 QA까지 포함한 이터레이션 루프를 얼마나 빠르게 돌릴 수 있는지가 중요하다. 지금 내게는 Go가 그 균형이 가장 잘 맞는 언어다.

Update: 선택지는 제한되어 있다

너무 당연한 내용이라서 글 쓸 때 까먹었는데, AI가 잘 작성하는 언어 중에서 골라야 한다. 이 글이 Rust, Golang, TypeScript에 집중되어 있는 이유이다.

그중에서도 최근 가장 열심히 만드는 제품은 Labor0다. Labor0의 핵심 아이디어는 간단하다.

AI가 작업을 주도한다.

인간은 언제나 병목이다. 이것이 내 철칙이다.

물론 HITL(Human in the Loop)은 필수다. 제품과 기술에 관한 결정은 사람이 내려야 하고, PR도 사람이 최종 검토하고 머지해야 한다. 다만 AI가 작업하는 동안 사람을 호출하는 횟수는 가능한 한 줄여야 한다.

Labor0는 사람의 결정이 필요할 때 웹 푸시 등으로 질문을 보낸다. 사람이 한 PR을 검토하고 있는 동안에는 다음 작업을 자동으로 시작한다. 사람이 모든 과정에 계속 붙어 있는 대신, 꼭 필요한 결정 지점에만 참여하는 구조다.

AI에게 일을 시킬 때의 제1원칙

내가 AI에게 일을 시킬 때 가장 중요하게 생각하는 원칙은 언제나 같다.

작업을 충분히 작은 단위로 쪼개야 한다.

한 PR이 너무 크면 사람도 리뷰하기 어렵고 AI도 리뷰하기 어렵다. 결국 리뷰 품질이 떨어진다.

나는 AI가 등장하기 전부터 코드 리뷰를 아주 많이 했다. GitHub에 기록된 PR 리뷰 횟수가 1년에 5천 번을 넘을 정도였다. 그 경험을 통해 큰 PR에서는 제대로 된 리뷰가 어렵다는 것을 배웠다.

AI도 비슷하다. 컨텍스트 크기 같은 이유가 영향을 주는 것 같지만, 정확한 원인과 별개로 작업이 커질수록 결과를 검증하기 어려워지는 것은 분명하다.

유지 가능한 바이브 코딩을 하려면 작업을 나누는 과정이 필수다. Labor0는 이 과정을 플랫폼으로 만든다. 작업이 크면 여러 작업과 PR로 나누고, 작업 사이에 의존성이 있다면 그 순서에 맞춰 실행한다. 서로 독립적인 작업은 병렬로 진행한다.

다만 이렇게 많은 작업을 병렬로 돌리려면 입력부터 상세해야 한다. 내가 수십 개의 세션을 동시에 운영할 수 있는 중요한 이유도 이슈와 PRD가 매우 구체적이기 때문이다.

여기서 내가 항상 사용하는 것이 $add-issue와 Write PRD 스킬이다.

$add-issue는 확인된 버그를 재현 사례와 구현 범위가 포함된 상세한 GitHub 이슈로 만든다. Write PRD를 사용하면 필요한 결정을 둘러싼 대화가 이어진다. 결정은 모두 내가 직접 내리지만, 큰 프로젝트의 규모와 비교하면 사람이 내려야 하는 결정은 생각보다 많지 않다. 물론 프로젝트 자체가 크기 때문에 결정 횟수의 절대적인 수가 작은 것은 아니다.

오늘 첫 번째 작업: Labor0

오늘은 먼저 Labor0를 위한 PRD 세 개를 작성했다. PRD를 작성할 때는 GPT 5.6 Sol을 사용한다.

첫 번째는 Devin의 Knowledge 시스템과 비슷한 자동 학습 기능에 관한 PRD였다. 두 번째는 데스크탑과 Apple Watch 앱에서 사용할 음성 조작 기능에 관한 것이었다. 세 번째는 Slack과 Discord 연동을 강화하기 위한 비교적 큰 리팩터링이었다. Labor0의 작업 상태가 해당 메신저의 해당 스레드 안에서 자연스럽게 갱신되도록 만드는 작업이다.

이 가운데 메신저 연동 개선은 구현을 시작했고, 나머지 두 개는 아직 PRD만 작성했다.

Labor0는 24시간 돌아가는 소프트웨어 팩토리에 가깝다. 실제로 Labor0 자체 개발을 위한 세션만 평소 약 10개가 계속 실행되며 토큰을 사용한다. 그만큼 비용도 상당하다. 그래서 필요성이 확정된 작업부터 구현을 시작한다.

PRD는 단순한 문서가 아니다. 무엇을 만들지 결정하고, 아직 만들 필요가 없는 작업에는 토큰을 쓰지 않도록 경계를 세우는 역할도 한다.

두 번째 작업: Watchtower

그다음에는 Watchtower를 작업했다.

Watchtower는 Sentry와 호환되는 에러 모니터링 및 관측 시스템으로, 현재 Build in Public 방식으로 개발하고 있다. Watchtower 역시 Labor0와 마찬가지로 스펙 주도 개발 방식을 사용하며 Codex 자동 리뷰를 적극적으로 활용한다.

오늘은 Write PRD 스킬을 사용해 Watchtower 이슈 #13을 작성했다.

PRD를 만드는 과정에서 통신 방식에 관한 결정을 내려야 했다. 나는 강타입을 좋아해서 Connect RPC를 사용하고 싶었다. 그런데 대화 과정에서는 JSON과 HTTP 기반으로 가는 것이 권장됐다.

몇 차례 더 대화하면서 심각한 기술적 제약이 있는지 확인했다. 살펴보니 본질적인 문제라기보다 Protobuf와 관련 도구의 Rust 지원이 주된 이유였다. 그래서 필요한 것이 있다면 우리가 직접 구현하기로 하고, Protobuf와 HTTP를 사용하기로 결정했다. Connect는 스트리밍이 필요해지는 시점에 도입하기로 했다.

완성된 PRD는 Labor0를 통해 PR #31로 바뀌었고, 오늘 바로 검토해서 머지했다.

세 번째 작업: SWC

마지막으로 SWC를 작업했다.

Codex 데스크탑 앱에서 GPT 6 Astra를 사용해 ES minifier의 모든 파일을 검사하도록 요청했다. 실제로 사용한 프롬프트는 다음과 같다.

서브에이전트 적극적으로 활용해. ES minifier의 모든 파일 검사해줘. 할 일은 각 파일의 모든 분기 따져보고 각각에 대해서 혹시나 잘못된 조건이 있는지 검사하고, 혹시나 잘못된 조건이 있으면 예시 입력값 만들어서 $add-issue 해주는거야

Codex는 버그를 발견하면 $add-issue 스킬을 사용해 GitHub 이슈로 남겼다. 그 결과 오늘 하루 동안 46개의 버그를 찾았다.

그다음 Labor0에 한 문장을 입력했다.

오늘 kdy1이 만든 모든 es/minifier 이슈들 고쳐줘

46개 이슈는 45개의 Labor0 작업이 됐다. 스코프상 두 이슈를 함께 처리하는 편이 적절하다고 판단된 작업이 하나 있었기 때문이다.

45개 작업은 완전히 병렬로 실행됐고, 각각 하나의 PR을 만들어 총 45개의 PR이 열렸다. 작업이 진행되는 동안 나는 상황을 계속 지켜보지 않았다. 폰을 보고 게임을 하며 놀고 있어서, 모든 PR이 열리기까지 정확히 얼마나 걸렸는지도 모른다.

버그 탐색에는 GPT 6 Astra를 사용했지만, 45개 구현 작업을 전부 Astra가 처리한 것은 아니다. 간단한 작업이 많았기 때문에 GPT 5.6 Terra가 많이 사용됐고, 어려운 Premium 작업에는 Astra가 배정됐다.

이 글을 쓰는 시점에는 45개 PR 중 21개가 머지됐다. 닫아야 했던 PR은 없었다. 나머지는 Codex 자동 리뷰와 Labor0의 피드백 반영 루프를 기다리거나, 실패한 CI를 수정하는 중이다.

머지에 필수인 CI가 실패하면 Labor0가 수정한다. 머지 충돌이 생겨도 Labor0가 해결하고 다시 가져온다.

Codex의 +1을 기다린다

내가 작업하는 모든 저장소에는 공통된 리뷰 과정이 있다. SWC뿐 아니라 Labor0와 Watchtower에도 같은 방식을 사용한다.

Labor0가 수정 커밋을 올리면 Codex가 다시 자동 리뷰한다. 리뷰 항목이 발견되면 Labor0가 피드백을 반영하고 새 커밋을 올린다. 그러면 Codex가 그 커밋을 다시 리뷰한다.

이 과정은 Codex가 더 이상 리뷰 항목을 찾지 못할 때까지 반복된다. 충분히 리뷰했다고 판단하면 Codex는 PR에 +1 이모지를 남긴다.

저장소 설정에서는 chatgpt-codex-connector 봇이 남긴 리뷰를 자동으로 반영하도록 구성해 두었다. 이 설정 덕분에 리뷰가 나올 때마다 내가 승인하지 않아도 Labor0가 바로 후속 작업을 진행한다. 해당 설정이 없다면 Labor0는 프로젝트 권한이 있는 사람에게 리뷰를 반영할지 물어본다.

나는 +1이 달린 PR만 필터링해 최종 검토 대상으로 본다. 세션을 많이 실행하고 PR을 많이 만들다 보니, 이런 필터가 없으면 검토할 준비가 끝난 PR을 찾는 일 자체가 또 하나의 일이 된다.

SWC에서 머지한 21개 PR도 모두 Codex가 +1을 남긴 뒤 GitHub에서 코드를 직접 검토하고 수동으로 머지했다.

+1은 사람의 승인이 아니다

Codex가 +1을 남겼다고 해서 PR이 항상 올바른 것은 아니다. 정말 이상한 상태의 PR에도 +1이 달릴 때가 있다.

Codex는 내가 처음에 품었던 의도를 전부 알지 못한 채 리뷰를 시작한다. 그래서 코드만 보고 판단한 결과가 PR의 방향을 완전히 바꾸기도 한다.

한번은 내가 cut-over 마이그레이션을 하려던 PR이 있었다. Codex는 롤백하면 앱 데이터가 망가질 수 있다고 판단했고, 그 우려에 따라 PR의 방향을 바꿨다. Codex가 +1을 남겼을 때에는 그 잘못된 리뷰 내용이 Labor0를 통해 이미 PR에 반영된 상태였다.

나는 최종 검토에서 “이 작업은 cut-over이며 롤백하지 않을 것이니 해당 변경을 되돌려라”라는 리뷰를 남겼다. Labor0가 이를 반영했고, PR은 정상적으로 머지됐다.

그래서 +1은 머지해도 된다는 최종 승인이 아니다. 자동 리뷰 루프가 끝났고 사람이 검토할 차례가 됐다는 신호에 가깝다.

최종 리뷰에서는 AI가 테스트를 지나치게 추가하지 않았는지도 확인한다. AI가 스크립트의 텍스트를 하나씩 매칭하는 식으로 과도하고 취약한 테스트를 만들 때가 있기 때문이다. SWC PR에서는 Codspeed를 확인해 성능 문제가 생기지 않았는지도 꼭 본다.

AI는 자잘한 버그를 자동 리뷰 단계에서 많이 잡아준다. 덕분에 내가 받는 인지 부하는 예전에 혼자 모든 것을 검토하던 때보다 훨씬 작다. 그럼에도 원래 의도, 테스트의 적절성, 성능과 최종 머지 결정은 사람이 책임져야 한다.

토큰을 잔뜩 쓴 PR을 최종적으로 닫아야 할 때도 있다. 그래도 전체적인 효율은 지금 방식이 훨씬 높다. 엄청나게 빠르기 때문이다.

6개 세션에서 50개가 넘는 세션으로

예전에는 Claude Code CLI를 사용했다. 당시에는 세션을 6개만 돌려도 매우 피곤했다. 터미널은 원래 병렬 작업을 관리하기 위해 만들어진 UI가 아니어서, 여러 세션 사이를 계속 전환해야 했다.

Codex 데스크탑으로 옮긴 뒤에는 약 15개 세션까지 운영할 수 있었다.

지금은 특정 시점에 Labor0 세션이 50개를 넘어갈 때도 있지만 크게 힘들지 않다. SWC 작업 45개가 병렬로 실행되던 시점에는 Labor0 자체 개발 세션도 약 15개가 돌아가고 있었을 것이다. 두 프로젝트만 합쳐도 동시에 실행되거나 관리 중인 세션이 50개를 넘는다.

그 외에도 typescript-go를 typescript-rust로 포팅하는 프로젝트, Turborepo를 Effect 기반 TypeScript로 포팅하는 프로젝트, 여러 개인 프로젝트를 함께 진행하고 있다.

이 정도의 동시 작업이 가능한 것은 세션 수 자체보다 각 작업의 범위와 결정 사항이 상세하게 정리돼 있기 때문이다. $add-issue와 Write PRD가 큰 역할을 한다.

작업에 맞춰 모델을 배분한다

Labor0에서는 작업마다 하네스와 모델을 직접 지정하거나, AI가 난이도에 맞춰 선택하도록 설정할 수 있다. Cheap, Standard, Premium은 난이도에 따라 작업을 배분하기 위한 개념이다.

나는 Codex 리뷰 반영 작업을 Standard 티어로 실행한다. 여기에는 GPT 5.6 Terra나 GLM 5.3을 사용한다. CI 실패 수정과 머지 충돌 해결은 Cheap 티어로 두고 GPT 5.6 Luna의 high 또는 xhigh를 사용한다.

Premium 티어는 공급자에 따라 다르게 구성한다. Codex 기본 공급자에서는 GPT 5.6 Sol을 사용하고, OpenRouter를 연결한 Codex Custom Provider에서는 GLM 5.3 xhigh를 사용한다. SWC 프로젝트에서는 오늘 Astra를 써보고 싶어서 Premium 작업을 GPT 6 Astra로 설정했다.

Labor0와 Watchtower의 하네스도 Codex다. 다만 Labor0의 Codex Custom Provider 기능으로 OpenRouter에 연결하기 때문에 GLM 모델을 선택할 수 있다. 구현 작업은 GPT 5.6 Terra에서 더 가성비가 좋은 GLM 5.3으로 옮기는 중이다. Codex 데스크탑에서 직접 처리하는 잡다한 작업에는 GPT 5.6 Terra를 사용한다.

Labor0 세션은 AWS ECS Fargate의 격리된 환경에서 실행된다. 내 보안 모델에서는 이 격리 덕분에 오픈 모델 사용이 큰 위협이 되지 않는다고 본다.

모든 작업에 가장 비싼 모델을 사용할 필요는 없다. 작업을 충분히 작게 나누고, 상세한 스펙을 주고, 난이도에 맞는 모델을 배정하고, 자동 리뷰 루프를 거치게 하는 것이 내가 현재 사용하는 방식이다.

이 글은 현재 시점의 기록이다

Labor0가 더 발전하면 내 개발 프로세스는 또 바뀔 것이라고 생각한다. 그래서 지금의 방식을 기록해두고 싶었다.

나는 AI Native에 가까운 개발자로서 얻은 인사이트를 공유하고 싶다. 원래부터 사람을 돕고 지식을 나누는 일을 좋아했다. 어릴 때부터 후배들을 가르치고 코드를 리뷰하는 일을 많이 했다.

많은 사람이 이 글을 보고 AI 시대에 맞게 개발하는 방법을 각자의 환경에서 배울 수 있었으면 좋겠다.

지금 내가 도달한 결론은 명확하다.

사람은 언제나 병목이다. HITL은 필수지만, 루프에서 사람을 호출하는 횟수는 최소화해야 한다. AI가 작업을 주도하고, 사람은 의도와 결정을 책임진다. 그리고 이 방식을 유지 가능하게 만드는 첫 번째 조건은 언제나 같다.

작업을 충분히 작은 단위로 쪼개는 것.

I do not know exactly how long it took. While the work was running, I was looking at my phone and playing games. By the time I checked, the work had already moved on without me.

My name is kdy1. I created SWC, an open-source compiler project, and previously worked at Deno and Vercel. These days, I spend a lot of time building Labor0, along with Watchtower and theaiplatform.app at Zephyr Cloud IO.

My development workflow has changed dramatically over the past few years. I used to do nearly everything myself. Now, almost all of my development work involves Labor0 and Codex automatic review.

I have one rule that shapes the entire process:

Humans are always the bottleneck.

Human-in-the-loop is still essential. Decisions must be made by a human, and I still review and merge pull requests myself. But I want the AI to drive the work and call me into the loop as few times as possible.

When Labor0 encounters a decision, it can send me a question through something like a web push notification. Once I answer, it continues. When a PR is ready, I review and merge it, but Labor0 does not need to wait for me before starting the next independent task.

A day of AI-native development

On the day I wrote this, I worked on Labor0, Watchtower, and SWC, in that order.

For Labor0, I wrote three PRDs:

• An automatic learning feature similar to Devin’s Knowledge system

• Voice controls for desktop and Apple Watch apps

• A large refactoring of Labor0’s messenger integration, so that status updates appear naturally inside the corresponding Slack or Discord thread

I started implementing the messenger refactoring. The other two remain PRDs for now.

I always use my Write PRD skill when writing a PRD. I use GPT 5.6 Sol for this work.

The skill does not make decisions for me. I make every decision myself. What surprised me, though, is how few decisions I need to make relative to the size of the projects I run. The absolute number is not small because these projects are large, but it is still much lower than I would have expected.

The skill turns PRD writing into a conversation. It identifies decisions that need to be made, and I resolve them.

I saw this clearly while working on Watchtower, a Sentry-compatible error monitoring and observability system that I recently started building in public. Watchtower uses a spec-driven development process.

While writing PRD #13, I initially wanted to use Connect RPC because I prefer strongly typed systems. JSON over HTTP was recommended instead, so I spent a few rounds of conversation checking whether Connect had a serious limitation.

It turned out that the main concern was Rust support for Protobuf and its surrounding tooling. That was not a fundamental constraint for me. I decided that we could implement what we needed if necessary, so the PRD settled on Protobuf over HTTP. I considered introducing Connect immediately, but decided to wait until we actually need streaming.

That decision was captured in the PRD. Labor0 then turned the PRD into PR #31, which I reviewed and merged that day.

After Watchtower, I moved on to SWC.

Finding 46 bugs with GPT 6 Astra

I wanted to try GPT 6 Astra, so I opened Codex Desktop and gave it this prompt:

Use subagents aggressively. Inspect every file in the ES minifier. For each file, examine every branch and check whether any condition is incorrect. If you find an incorrect condition, construct an example input and use $add-issue to report it.

This produced 46 GitHub issues.

The $add-issue skill is an important part of the process. A large number of parallel sessions is only useful when every session receives a sufficiently detailed issue. The skill ensures that a bug is supported by evidence and turned into a self-contained, implementation-ready GitHub issue.

Once the issues existed, I gave Labor0 one prompt:

Fix every es/minifier issue created by kdy1 today.

Labor0 converted the 46 issues into 45 tasks. One task covered two issues because their scopes belonged together. A Labor0 task generally produces one PR, so those 45 tasks became 45 pull requests.

All 45 tasks ran in parallel. When tasks depend on each other, Labor0 runs them in dependency order, but these tasks could run concurrently.

GPT 6 Astra found the bugs, but it did not implement all 45 fixes. Labor0 assigns models according to task difficulty, and many of these fixes were simple enough to use GPT 5.6 Terra. I had configured the SWC project to use GPT 6 Astra for difficult, Premium-tier work.

At the time of writing, I had merged 21 of the 45 PRs. I had not closed any of them. The remaining PRs were still going through the Codex review loop or waiting for CI failures to be repaired. When a required CI check fails, Labor0 starts work to fix it. It also repairs merge conflicts when they appear.

AI reviews AI until it runs out of comments

Codex automatic review is part of my workflow across every repository, including SWC, Watchtower, and Labor0 itself.

Each time Labor0 pushes a fix commit, Codex reviews the PR again. If Codex finds another issue, Labor0 applies the feedback and pushes another commit. Codex reviews that commit, and the loop continues.

When Codex can no longer find another review item, it leaves a +1 reaction on the PR.

I configured these repositories so that reviews from the chatgpt-codex-connector bot are applied automatically. Without that setting, Labor0 asks someone with permission on the Labor0 project whether it should apply the review.

Because I run so many sessions and create so many PRs, the +1 reaction is also my review queue. I filter for PRs that received a +1 and review only those. Otherwise, finding which PRs are ready for final review would itself become a job.

The 21 SWC PRs I merged all went through this process. Codex left a +1, I inspected the code directly on GitHub, and then I merged each PR manually.

This reduces my cognitive load considerably. Codex catches many small bugs before I ever see the code. Compared with reviewing everything alone, I can focus on fewer and more important questions.

But a +1 does not mean the PR is correct. It means that Codex has run out of review comments.

Why a human still has to look

Codex begins its review without fully knowing my intent. Because of that, it can sometimes push a PR in a completely wrong direction.

In one migration PR, I wanted a cut-over migration with no rollback path. Codex was concerned that rolling the migration back could damage application data, so it changed the direction of the PR. Labor0 automatically applied that review, and Codex eventually left a +1 on the result.

When I performed the final review, the PR was no longer implementing what I wanted.

I left another review explaining that this was a cut-over migration, that we would not roll it back, and that the previous change should be reverted. Labor0 applied my feedback, and the PR was eventually merged successfully.

I also check whether the AI has added too many tests. It tends to go too far. I have seen it add tests that inspect a script by matching its text piece by piece. Tests like that add volume without necessarily improving confidence.

For SWC, I also use Codspeed during final review and always check whether a change introduces a performance problem.

My final review therefore focuses on things that automatic review can still miss:

• Whether the implementation matches the original intent

• Whether the PR has moved in an unnecessary or incorrect direction

• Whether the tests are excessive or overly tied to implementation details

• Whether an SWC change causes a performance regression

• Whether I am personally willing to merge the result

The AI can remove a great deal of routine review work, but the final judgment still belongs to me.

Small tasks are the foundation

My first rule when assigning work to AI is to split it into sufficiently small units.

Large PRs are difficult for both humans and AI to review, and review quality falls as the PR grows. Before AI coding tools existed, GitHub recorded more than 5,000 PR reviews from me in a single year. After doing that much review, I came to believe very strongly in keeping PRs small.

I suspect AI review quality also declines partly because of context size, although that is my guess rather than a confirmed explanation.

When Labor0 receives a large task, it breaks the work into smaller tasks and produces multiple PRs. It also represents dependencies between those tasks and executes them in the required order.

Detailed issues and PRDs make this possible. $add-issue produces well-defined bug reports. Write PRD helps me resolve decisions before implementation begins. Labor0 can then distribute those bounded tasks across many sessions.

This is the process I think maintainable vibe coding requires: small tasks, explicit decisions, detailed handoffs, independent PRs, and continuous review. Labor0 is my attempt to turn that process into a platform.

From six terminal sessions to more than fifty

I used Claude Code CLI in the past. Even six concurrent sessions made me very tired because a terminal was not designed as a UI for managing parallel work. I had to keep switching between sessions.

After moving to Codex Desktop, I could manage around 15 sessions.

With Labor0, there are moments when I have more than 50 sessions active across my projects without feeling particularly overwhelmed. Labor0 development alone commonly keeps around ten sessions consuming tokens around the clock. During the SWC run, I think Labor0 itself had around 15 active sessions. Combined with the SWC work, those two projects alone pushed the total beyond 50.

And those are not my only projects. I also run projects that port typescript-go to typescript-rust, port Turborepo to Effect-based TypeScript, and work on various personal projects.

The number of sessions is possible because the issues are detailed and the work is divided. Concurrency without clear scope would only create more things for me to untangle.

Routing models by cost and difficulty

Labor0 can assign a harness and model directly for each task, or allow AI to select them according to difficulty. Cheap, Standard, and Premium are the tiers Labor0 uses for this routing.

I currently use the Standard tier for applying review feedback, with GPT 5.6 Terra or GLM 5.3. CI repairs and merge-conflict resolution use the Cheap tier, with GPT 5.6 Luna at high or xhigh reasoning.

With the regular Codex provider, my Premium tier uses GPT 5.6 Sol. When I connect OpenRouter through Labor0’s Codex Custom Provider, Premium uses GLM 5.3 xhigh. Labor0 and Watchtower both use the Codex harness with this Custom Provider setup, which is how I can select GLM models.

For implementation through Labor0, I have been moving from GPT 5.6 Terra toward the more cost-efficient GLM 5.3. When I work directly in Codex Desktop, I still use GPT 5.6 Terra for miscellaneous tasks.

Labor0 sessions run in isolated environments on AWS ECS Fargate. In my security model, that isolation means using open models presents relatively little additional threat.

Cost still matters. Labor0 feels like a software factory that can operate 24/7, and a factory running 24/7 consumes a lot of tokens. That is why I do not immediately implement every PRD. Once I know that a feature is necessary, I start implementation. Until then, the detailed PRD is enough.

This workflow will change again

I expect my development process to change again as Labor0 improves. That is one reason I wanted to write this down: it is a record of how I work at this particular moment.

I also want to share what I have learned as someone getting closer to being an AI-native developer. I have always enjoyed helping people and sharing what I know. Since I was young, I have taught junior developers, reviewed their code, and helped in whatever ways I could.

I hope more developers can look at workflows like this and learn how development can work in this era.

The human is still the bottleneck. My goal is to spend that limited human attention on decisions, intent, and final judgment—and let the software factory handle as much of the rest as possible.

AI 에이전트 세션을 많이 실행하는 것 자체는 어렵지 않다. 내가 해결하고 싶었던 문제는 세션이 늘어날 때마다 사람이 모든 진행 상황을 확인하고 관리해야 한다는 점이었다.

사람을 병목에서 완전히 빼는 게 목표는 아니다. 사람은 여전히 병목이다. 대신 사람이 개입해야 하는 횟수를 줄이고, 실제로 결정이 필요한 순간에만 사람을 부르는 구조를 만드는 게 중요하다.

나는 이를 위한 작업 체계를 만들었고, 그 중심에 Labor0가 있다. 한때 50개가 넘는 세션이 돌아갈 때도 내가 느끼는 인지 부하는 거의 없었다.

큰 작업을 맡기면 AI가 먼저 적당한 크기로 나누고, 나뉜 작업의 진행을 주도했다. 작업을 적절한 크기로 나누는 것은 중요하다. PR이 너무 크면 제목만 보고 내용을 파악하기 어렵고, 사람이 직접 리뷰하기도 힘들다. Codex 자동 리뷰의 성능도 떨어진다.

나는 작업이 진행되는 모든 과정에 개입하지 않았다. 결정이 필요한 순간에만 호출받았고, Labor0의 PR 처리와 Codex 자동 리뷰가 모두 끝난 뒤에 PR을 확인했다.

여기서 PR 처리란 CI 실패 수정, 머지 충돌 해결, 리뷰 내용 반영을 말한다. 일부 PR은 나도 코드를 직접 리뷰했다.

안정성을 확보하기 위해 자동화 테스트에도 집중했다. 자동화 테스트에 빈틈이 없는지는 Codex를 활용해 다시 검증했다.

에이전트가 이어서 일할 수 있는 이슈 만들기

모든 프로젝트에서는 GitHub를 이슈 관리 도구로 사용했다. 이슈를 만드는 일도 에이전트에 맡겼다.

이를 위해 add-issue라는 전용 스킬을 만들었다. GitHub 이슈만 읽어도 문제를 고칠 수 있을 만큼 상세하게 작성하는 것이 이 스킬의 핵심이었다.

add-issue는 같은 내용의 이슈가 이미 있는지 확인하고, main 브랜치와 배포된 버전도 검사한다. 최신 main에서도 아직 고쳐지지 않은 문제일 때만 이슈를 남긴다. 개인정보 등이 이슈에 노출되지 않도록 가리는 기능도 넣었다.

이슈를 남길 때는 Codex 데스크톱 앱의 워크트리 기능을 활용했다. 여러 작업을 서로 다른 워크트리에서 병렬로 진행해 이슈를 동시에 만들었다.

이런 방식으로 작업 속도를 높이는 데에는 많은 토큰이 필요했다. 토큰 사용량은 상당했지만, 토큰 비용은 인건비와 비교하면 매우 저렴하다고 생각한다. 같은 업무를 사람만으로 처리했다면 비용이 30배는 더 들었을 것으로 본다.

프로덕션 장애로 확인한 차이

Labor0를 개발하다가 실수로 프로덕션을 중단시킨 적이 있다. 당시에는 어쩔 수 없이 로컬 Codex를 사용해 복구에 필요한 작업을 처리했다.

이 과정에서 Labor0로 일할 때가 로컬 Codex를 직접 사용할 때보다 작업 처리 속도가 훨씬 빠르다는 사실을 확인했다. 이제는 Labor0 없이 Codex만 직접 사용하던 방식으로 돌아가기 어렵다.

그만큼 Labor0의 프로덕션 안정성이 중요해졌다. 지금은 그래프 기반 작업 관리자와 러너처럼 Labor0의 기반을 이루는 구성 요소들의 안정성을 높이는 데 많은 투자를 하고 있다. E2E 테스트를 계속 추가하고 있으며, Codex를 활용해 테스트에 남아 있는 허점도 찾고 있다.

PR 기반 작업에서 보편적인 작업으로

현재 Labor0가 관리하는 세션은 PR 기반 작업 흐름에 묶여 있다. CodingTask의 성공 기준도 PR이다.

다만 내부 구조는 이미 CodingTask와 AgentTask로 나뉘어 있다. AgentTask는 아직 내부에만 존재하는 개념으로, 에이전트가 수행할 수 있는 모든 종류의 작업을 나타낸다. PR을 기준으로 하는 CodingTask와 달리 별도의 성공 조건을 가진다.

앞으로는 Labor0가 관리하는 세션을 PR 기반 코딩 작업에서 더 보편적인 작업으로 확장할 계획이다.

러너의 지원 범위도 넓히고 있다. 현재 클라우드에서 호스팅되는 Labor0 러너는 리눅스만 지원한다. 로컬 러너를 이용하면 이미 다른 운영체제의 러너를 사용할 수 있으며, 다른 운영체제를 기반으로 하는 클라우드 러너도 고려하고 있다.

시스템이 관리하는 작업 외에 직접 세션을 확인해야 하는 경우도 있었다. 이런 작업 때문에 Codex 데스크톱을 사용해야 했고, 이를 Labor0 안에서 처리하기 위해 Direct Task 기능을 만들었다.

Direct Task는 시스템이 관리하지 않는 세션을 직접 만드는 기능이다. 현재 알파 단계이며 아직 공개하지 않았다.

작업이 빠르게 진행되면서 그동안 무엇이 바뀌었는지 파악하기 위한 기능도 필요해졌다. 그래서 만든 것이 Catch-up이다.

Catch-up은 내가 마지막으로 업데이트를 확인한 시점부터 현재까지 무엇이 바뀌었는지를 AI가 요약해 주는 기능이다. 이 기능도 현재 알파 단계다.

사람이 입력하던 프롬프트까지 자동화하기

지금은 "labor0" 라벨이 붙은 모든 이슈를 고쳐줘 같은 프롬프트를 내가 반복해서 입력해야 한다.

다음 단계는 이런 프롬프트를 직접 입력하는 일까지 줄이는 것이다. 현재 구상하는 방식은 GitHub 이벤트를 감지하고, 특정 검색 조건을 만족하는 이슈를 Labor0의 작업 그래프에 자동으로 추가하는 것이다.

회사와 프로젝트마다 일하는 방식이 크게 다르기 때문에 특정한 작업 방식에만 맞추지는 않을 생각이다. 각 사용자가 자신의 작업 방식에 맞게 조정할 수 있도록 범용적인 형태로 설계할 계획이다.

이 구조는 GitHub 이슈 외의 신호에도 적용할 수 있다. Grafana나 Sentry 같은 런타임 모니터링 도구에서 문제가 발생하면 작업 그래프에 자동으로 작업을 추가할 수 있다.

슬로 쿼리 로그를 분석해 최적화 작업을 만들거나, 메인 브랜치의 CI가 깨졌을 때 이를 고치는 작업을 생성하는 기능도 추가할 예정이다. 필요한 문서 업데이트 작업도 자동으로 만들 계획이다.

이벤트가 발생했을 때뿐만 아니라 정해진 주기에 맞춰 작업을 반복 실행하는 기능도 있다. 이 기능은 현재 알파 단계다.

QA도 같은 흐름으로

회사 블로그에는 Codex Desktop으로 매시간 PR QA를 자동화한 과정을 정리한 글도 썼다.

Codex 데스크톱이 매시간 PR 하나를 골라 빌드하고, 실제 앱을 조작해 변경된 흐름을 검사한 뒤, 스크린샷과 함께 GitHub 리뷰를 남기도록 만든 작업이다. 이것도 Codex 데스크톱으로 직접 구성했다.

앞으로는 이런 QA 작업도 Labor0에서 더 쉽게 만들 수 있도록 지원할 예정이다. 이를 위해 준비하고 있는 기능이 Chatty QA다.

Chatty QA는 명백히 잘못된 부분을 발견하면 작업 그래프에 추가해 에이전트가 고치게 한다. 디자인에 관한 결정이 필요하면 스크린샷 등 판단에 필요한 자료와 함께 사용자에게 질문한다. 이 기능도 현재 알파 단계다.

목표

우선은 내가 해야 했던 일 가운데 디자인에 관한 결정을 제외한 나머지를 Labor0를 통해 자동화하는 것이 목표다.

더 장기적으로는 지금까지 Codex 데스크톱을 사용해야 했던 작업과 번거롭지만 직접 처리해야 했던 대부분의 작업을 Labor0 안에서 훨씬 편하게 처리할 수 있도록 만들 생각이다.

사람을 작업 과정에서 없애려는 것이 아니다. 에이전트가 처리할 수 있는 일은 계속 진행하게 하고, 사람의 결정이 필요한 순간에만 사람을 부르는 시스템을 만드는 것이 목표다.

원래 이런 작업은 리눅스에서 하는 게 맞다고 생각했다. 그런데 나는 계속 로컬에서 디버깅해야 했고, 개발 흐름상 맥에서 바로 돌릴 수 있어야 했다.

예전에도 자동 QA를 시도한 적은 있었지만 끝까지 제대로 굴러간 적은 없었다. 그러다가 지난주 중반쯤, “이건 로컬에서부터 디버깅하면 가능하겠다”는 감이 왔다.

실제로 작업을 시작한 건 목요일이었다.

타임라인

목요일 — 로컬 자동 QA 재시작

목요일부터 자동 QA를 다시 구성하기 시작했다.

Codex에게 로컬에서 실행 가능한 스크립트를 짜게 했고, 초기 접근 방식은 Midscene 기반이었다.

앱이 웹 기반이라 자동화 자체는 비교적 쉬운 편이었다.

문제는 Midscene 기반 접근 방식의 특성이었다.

테스트를 실행하면 실제 컴퓨터 화면을 점유했다. 클릭 이벤트를 수행하려면 실제 GUI를 건드려야 했고, 테스트가 도는 동안 컴퓨터를 사실상 사용할 수 없었다.

즉:

• QA는 자동인데

• 사람은 컴퓨터를 못 쓰는 상태

가 되어버렸다.

이 시점에서 자동 QA의 의미가 꽤 퇴색된다고 느꼈다.

⸻

금요일 — CDP 기반 백그라운드 자동 QA 성공

금요일에는 실행 구조를 바꿨다.

핵심은:

• 화면을 점유하지 않고 백그라운드에서 돌리는 것

이었다.

여기서 Midscene 기반 접근에서 CDP 기반 구조로 전환했다.

앱이 웹 기반이었기 때문에 CDP를 사용하는 게 잘 맞았고, 브라우저를 직접 제어하면서 백그라운드 실행이 가능해졌다.

다만 단순 브라우저 제어만으로는 부족해서, 판단과 플로우 제어에는 Claude Code를 사용했다.

결과적으로:

• 로컬 디버깅 가능

• 백그라운드 실행 가능

• 화면 점유 없음

• 실제 사용자 시나리오 기반 QA 가능

상태까지 도달했다.

그리고 금요일에 처음으로 자동 QA를 끝까지 완주시키는 데 성공했다.

토요일 — CI 연결

토요일에는 이 QA를 CI에서 실행되도록 연결했다.

아직 레거시 이미지 기반이긴 했지만, 중요한 것은 PR 단위 자동 QA 가 가능해졌다는 점이었다.

현재 구조

현재 흐름은 아래처럼 구성되어 있다.

1. PR 작성

PR 본문에는 원래 사람이 수동 QA를 할 때 필요한 가이드라인을 적는다.

예를 들면:

• 어떤 기능을 확인해야 하는지

• 어떤 시나리오를 검증해야 하는지

• 어떤 동작이 기대 결과인지

같은 내용이다.

⸻

1. QA 라벨 부착

'needs ai qa' 라벨을 붙이면 깃허브 액션이 이를 감지한다. 그리고 라벨이 붙으면 자동 QA가 시작된다.

⸻

1. CI에서 자동 QA 수행

CI 환경에서 자동으로:

• 브라우저 실행

• 시나리오 수행

• 화면 분석

• 결과 판별

을 수행한다.

그리고 이 구조의 장점 중 하나는 병렬 처리였다.

PR이 여러 개 열려 있어도 각각 독립적으로 QA를 수행할 수 있다.

사람이 수동 테스트를 하는 구조였다면:

• 여러 PR 동시 처리 어려움

• 컨텍스트 스위칭 발생

• 반복 작업 증가

문제가 생겼을 텐데, 지금은 그런 부담이 많이 줄었다.

⸻

1. 결과 댓글 작성

QA가 끝나면 PR에 댓글을 남긴다.

결과는 항목별로:

• PASS

• FAIL

• INCONCLUSIVE

형태로 정리된다.

그래서 실제로 사람이 확인해야 하는 건:

• 실패 항목

• 애매한 항목

정도로 줄어들었다.

⸻

스크린샷 / 비디오 기록

자동 QA 과정에서:

• 스크린샷 저장

• 비디오 녹화

도 함께 수행한다.

비디오 녹화 기능은 이번 주 수요일(5월 13일)에 추가했다.

기왕 하는 김에 영상도 있으면 좋을 것 같아서 넣었나

주제는

• 개발 지식 / 전공 지식이 필요한가

• AI 시대에 필요한 역량

• 개발 직군의 미래

가 될 것이다.

한국 기준으로, 학벌은 사람을 볼 때 꽤나 유용한 지표이지만, 절대적이지는 않다. 경험적인 얘기일 뿐이지만, 성균관대학교 자퇴생으로서 느낀 것들이 몇 가지 있다.

대학까지 간 사람의 학벌은 학습 능력 x 성실함 에 대체로 비례한다. 그래서 의미가 있는 것 같다. 나도 대학교 덕분에 사람들 큰 걱정 없이 편하게 만날 수 있었다. 근데 대체로가 함정인데, 내가 학교를 다니던 시절 기준으론 성대 정도의 학교도 쉽게 들어올 방법이 꽤나 있었고, 그런 경우 저 곱셈식이 어그러져서인지 대체로 문제가 살짝 있었다.

지금 생각해보면 성대의 특성일 수도 있다. 성대생들은 대체로 저 곱셈식에서 성실함의 비중이 꽤 되는 사람들이기 때문이다. 제대로 노력을 해 본 적 없는 사람들은 자기의 주제를 전혀 모르는데, 내 친구들 중엔 그런 사람이 거의 없었다.

I recently gave a short presentation about how I use AI. The first part of the slides overlaps with a previous blog post. In this article, I’ll focus on topics that weren’t covered in that post.

Error Messages and Logging

Using Concrete Types and Schemas

The any type is dangerous even for humans—but it’s even more dangerous for AI.

The same applies to things like:

• Unconstrained parsing such as JSON.parse

• Loose interfaces

• Implicit or undocumented data structures

These patterns force AI to make too many assumptions.

The real problem is that once an assumption is wrong, all subsequent reasoning can spiral out of control.

So I try to follow these principles as much as possible:

• Use the most concrete types possible instead of any

• Prefer schema-based parsers over simple parsing
  (e.g., Zod or Yup instead of JSON.parse)

With this approach, even if the AI makes assumptions:

• The probability of those assumptions being wrong is lower

• When they are wrong, the system fails fast

In other words, this prevents AI from carrying incorrect reasoning all the way to the end.

Leveraging GitHub Actions

If you look closely, GitHub Actions has some surprisingly strong properties:

• Completely isolated environments

• Easy to configure

• A large collection of well-prepared examples

Instead of using it only for CI, I started treating it as a development virtual machine.

The same idea applies to AI.

“Whatever a developer can do locally,
AI should be able to do in exactly the same way.”

Setting Up a Development Environment for Claude Code

• Actual code: https://github.com/delinoio/delidev/blob/abed0d02fd30524bfb2f77f7227bf9560092e949/.github/workflows/claude.yml

name: Claude Code

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]
  pull_request_review:
    types: [submitted]

jobs:
  claude:
    if: |
      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
      actions: read # Required for Claude to read CI results on PRs
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1

      # Setup pnpm
      - name: Setup pnpm
        uses: pnpm/action-setup@v4.2.0

      - uses: actions/checkout@v4

      - name: Install Tauri dependencies
        run: |
            sudo apt-get update
            sudo apt-get install -y \
              libwebkit2gtk-4.1-dev \
              libappindicator3-dev \
              librsvg2-dev \
              patchelf

      - name: Setup Rust
        uses: dtolnay/rust-toolchain@stable

      - name: Run Claude Code
        id: claude
        uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

          # This is an optional setting that allows Claude to read CI results on PRs
          additional_permissions: |
            actions: read

          claude_args: |
            --allowed-tools Bash,WebFetch,WebSearch,Skill
            --model opus

With GitHub Actions, you can set things up so that:

• Package managers are installed

• Build commands are executed (pnpm build, cargo build, etc.)

• Tests are run

Once configured this way, Claude Code effectively operates in an environment that’s almost identical to a local development setup.

When the environment is this complete, the quality of AI output improves dramatically:

• It stops guessing

• It reasons based on actual execution results

• It produces “code that actually runs,” not just “code that should work in theory”

Managing Clean Commit Messages with AI

Preventing PR Description Spam

• Actual code: https://github.com/delinoio/delidev/blob/abed0d02fd30524bfb2f77f7227bf9560092e949/.github/workflows/claude-code-review.yml#L34-L55

name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      issues: read
      id-token: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - name: Dismiss old Claude bot comments
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          REPO="${{ github.repository }}"
          PR_NUMBER="${{ github.event.pull_request.number }}"

          gh api "repos/$REPO/issues/$PR_NUMBER/comments" --jq '.[] | select(.user.login == "claude[bot]") | .node_id' | while read -r comment_node_id; do
            if [ -n "$comment_node_id" ]; then
              gh api graphql -f query='
                mutation($id: ID!) {
                  minimizeComment(input: {subjectId: $id, classifier: OUTDATED}) {
                    minimizedComment {
                      isMinimized
                    }
                  }
                }' -f id="$comment_node_id"
            fi
          done

      - name: Run Claude Code Review
        id: claude-review
        uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          allowed_bots: '*'
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Please review this pull request and provide feedback on:
            - Code quality and best practices
            - Potential bugs or issues
            - Performance considerations
            - Security concerns
            - Test coverage

            Use the repository's CLAUDE.md for guidance on style and conventions. Be constructive and helpful in your feedback.

            Use `gh pr comment` with your Bash tool to leave your review as a comment on the PR.

          claude_args: '--allowed-tools "Bash(gh issue view:*),Bash(gh search:*),Bash(gh issue list:*),Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr list:*)"'

There’s one bug in the Claude Code GitHub review action: it leaves too many review comments.

This can easily result in PRs being flooded with AI-generated comments.

How to Use AI Reviews Effectively

Core Assumptions

Let’s be explicit about the premises:

• Human reviews are slow

• Human reviews are expensive

Therefore, the goal is to minimize human involvement.

The strategy I chose is:

1. Run AI reviews and CI first

2. Humans do not intervene until AI gives an OK

3. Only when tests and automated reviews pass

4. A human performs the final review

In short:

Humans act only as the “final approver.”

1. Using a GitHub App

By integrating AI reviews as a GitHub App, reviews start automatically as soon as a PR is opened.

At this stage, AI filters out:

• Code style issues

• Obvious bugs

• Structural problems

2. Applying Changes via GitHub Actions

Using tools like the Claude Code GitHub Action makes parallel processing much easier. Checking out code locally should be reserved for situations where human, local testing is truly required.

3. Using CI as a Gatekeeper

The key is to treat CI not just as a testing tool, but as:

A barrier between AI and humans

If AI-generated changes can’t pass CI, they never reach human reviewers. That alone significantly reduces review costs.

Q&A

Why MCP Is Unnecessary for This Use Case

Imagine there is a CLI that provides the exact same capabilities as a specific MCP server. Anything you can do through MCP could also be done through that CLI. This is why Vercel chose to improve its CLI instead of building an MCP server.

AI 활용법 관련해서 간단하게 발표를 했다. 발표 자료 앞쪽은 전에 블로그에 올린 글이랑 같은 내용이다. 이 글에서는 기존 글에서 다루지 않은 내용들을 다루겠다.

에러 메시지 및 로깅

구체적 타입 및 스키마 활용

any 타입은 사람에게도 위험하지만, AI에게는 더 위험하다.

마찬가지로,

• JSON.parse처럼 아무 제약 없는 파싱

• 느슨한 인터페이스

• 암묵적인 데이터 구조

이런 것들은 AI가 너무 많은 가정을 하게 만든다.

문제는 그 가정이 틀리면, 이후의 모든 판단이 연쇄적으로 꼬인다는 점이다.

그래서 가능한 한 다음을 지향한다.

• any 타입 대신 최대한 구체적인 타입 사용

• 단순 파싱 대신 스키마 기반 파서 사용
  (예: JSON.parse 대신 Zod, Yup 같은 라이브러리)

이렇게 하면 AI가 가정을 하더라도,

• 그 가정이 틀릴 확률이 줄어들고

• 틀렸을 경우 즉시 실패하도록 만들 수 있다

즉, AI가 잘못된 추론을 끝까지 끌고 가는 상황을 예방할 수 있다.

GitHub Actions 활용

GitHub Actions를 잘 보면 꽤 괜찮은 특징을 갖고 있다.

• 완전히 격리된 환경

• 구성하기 쉬움

• 이미 잘 구성된 예제가 많음

이걸 단순히 CI 용도로만 쓰지 않고,
개발용 가상 머신처럼 사용하는 접근을 했다.

AI에게도 마찬가지다.

“로컬에서 개발자가 할 수 있는 걸
AI도 똑같이 할 수 있게 만들어준다”

라는 관점이다.

Claude Code를 위한 개발 환경 구성

• 실제 코드: https://github.com/delinoio/delidev/blob/abed0d02fd30524bfb2f77f7227bf9560092e949/.github/workflows/claude.yml

name: Claude Code

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]
  pull_request_review:
    types: [submitted]

jobs:
  claude:
    if: |
      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
      actions: read # Required for Claude to read CI results on PRs
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1

      # Setup pnpm 
      - name: Setup pnpm
        uses: pnpm/action-setup@v4.2.0

      - uses: actions/checkout@v4

      - name: Install Tauri dependencies
        run: |
            sudo apt-get update
            sudo apt-get install -y \
              libwebkit2gtk-4.1-dev \
              libappindicator3-dev \
              librsvg2-dev \
              patchelf

      - name: Setup Rust
        uses: dtolnay/rust-toolchain@stable

      - name: Run Claude Code
        id: claude
        uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

          # This is an optional setting that allows Claude to read CI results on PRs
          additional_permissions: |
            actions: read

          claude_args: |
            --allowed-tools Bash,WebFetch,WebSearch,Skill
            --model opus

GitHub Actions에서:

• 패키지 매니저 설치

• 빌드 명령 실행 (pnpm build, cargo build 등)

• 테스트 실행

까지 모두 가능하게 구성해두면,
Claude Code는 사실상 로컬 개발 환경과 거의 동일한 조건에서 동작한다.

이렇게 환경이 갖춰져 있으면 AI의 작업 품질이 눈에 띄게 좋아진다.

• 추측으로 답하지 않고

• 실제 실행 결과를 기반으로 판단하고

• “이론상 맞는 코드” 대신 “실제로 도는 코드”를 만든다

AI로 커밋 메시지 예쁘게 관리하기

PR 본문 스팸 방지

• 실제 코드: https://github.com/delinoio/delidev/blob/abed0d02fd30524bfb2f77f7227bf9560092e949/.github/workflows/claude-code-review.yml#L34-L55

name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]
    # Optional: Only run on specific file changes
    # paths:
    #   - "src/**/*.ts"
    #   - "src/**/*.tsx"
    #   - "src/**/*.js"
    #   - "src/**/*.jsx"

jobs:
  claude-review:
    # Optional: Filter by PR author
    # if: |
    #   github.event.pull_request.user.login == 'external-contributor' ||
    #   github.event.pull_request.user.login == 'new-developer' ||
    #   github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR'

    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      issues: read
      id-token: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - name: Dismiss old Claude bot comments
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          # Get PR comments from claude[bot] and hide them as outdated
          REPO="${{ github.repository }}"
          PR_NUMBER="${{ github.event.pull_request.number }}"

          # Get issue comments (gh pr comment creates issue comments, not review comments)
          gh api "repos/$REPO/issues/$PR_NUMBER/comments" --jq '.[] | select(.user.login == "claude[bot]") | .node_id' | while read -r comment_node_id; do
            if [ -n "$comment_node_id" ]; then
              echo "Hiding review comment: $comment_node_id"
              gh api graphql -f query='
                mutation($id: ID!) {
                  minimizeComment(input: {subjectId: $id, classifier: OUTDATED}) {
                    minimizedComment {
                      isMinimized
                    }
                  }
                }' -f id="$comment_node_id"
            fi
          done

      - name: Run Claude Code Review
        id: claude-review
        uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          allowed_bots: '*'
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Please review this pull request and provide feedback on:
            - Code quality and best practices
            - Potential bugs or issues
            - Performance considerations
            - Security concerns
            - Test coverage

            Use the repository's CLAUDE.md for guidance on style and conventions. Be constructive and helpful in your feedback.

            Use `gh pr comment` with your Bash tool to leave your review as a comment on the PR.

          # See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md
          # or https://code.claude.com/docs/en/cli-reference for available options
          claude_args: '--allowed-tools "Bash(gh issue view:*),Bash(gh search:*),Bash(gh issue list:*),Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr list:*)"'

Claude Code GitHub 리뷰 액션에는 버그가 하나 있다. 리뷰 코멘트를 너무 많이 남긴다.

이 때문에 PR이 리뷰 댓글로 도배되는 문제가 생긴다.

AI 리뷰 활용법

기본 접근

전제부터 분명히 하자.

• 인간 리뷰는 느리다

• 인간 리뷰는 비싸다

그래서 인간 리뷰를 최소화해야 한다.

이를 위해 선택한 전략은 다음과 같다.

1. AI 리뷰 + CI를 먼저 통과시킨다

2. AI가 OK를 내릴 때까지는 인간이 개입하지 않는다

3. 테스트와 자동 리뷰가 모두 통과된 경우에만

4. 사람이 최종 리뷰를 한다

즉,

인간은 “최종 승인자” 역할만 맡는다

1. GitHub 앱 활용

AI 리뷰를 GitHub 앱 형태로 붙이면, PR 생성과 동시에 자동 리뷰가 시작된다.

이 단계에서는:

• 코드 스타일

• 명백한 버그

• 구조적인 문제

같은 것들을 AI가 먼저 걸러낸다.

2. GitHub Actions를 사용해서 반영

   

   스크린샷과 같이 Claude Code GitHub Action등을 사용해서 반영해야 병렬 처리가 쉽다. 로컬에 체크아웃하는 것은 사람의 테스팅처럼 로컬에서 해야만 하는 상황에만 하는 것을 추천한다.

3. CI 활용

중요한 건 CI를 단순한 테스트 도구가 아니라,

AI와 인간 사이의 방파제

로 사용하는 것이다. AI가 통과시키지 못한 변경사항은, 인간에게 도달하지 않게 만드는 것만으로도 리뷰 비용은 크게 줄어든다.

Q&A

MCP가 필요없는 스펙인 이유

특정 MCP 서버랑 똑같은 기능을 가진 CLI가 있다고 생각해보자. MCP를 통해서 수행할 수 있는 모든 건 CLI를 통해서도 수행할 수 있을 것이다. Vercel이 MCP를 만들지 않고 CLI 명령어를 개선한 것은 그래서이다.

Intuitive API is a must.

Everything should work intuitively, based on the name. AI tends to avoid digging into the lower layer unless you explicitly instruct it to fix it. For example, if enabled: false does not work in the code below, AI will fail to fix it most of the time because it assumes that the option works as expected.

Subagents may reduce context window usage.

Use subagents proactively.

You can utilize subagents to reduce the usage of the main context window. The only thing you need to do is saying Use subagents proactively in the prompt. It’s useful when you need to do a very large task. It makes Claude Code less intelligent for tasks that require the organic analysis of multiple clues, though.

Note: I didn’t define any subagents in my repository. General subagents are enough for this trick.

The API reference document reduces the guess-and-grep loop.

If you don’t specify the name of the method you want to fix, the AI agent will guess the method/variable/module name and grep for it repeatedly until it finds the relevant code.

This means that if you can provide an API reference document listing all method names, the coding agent will be much more efficient. As a side note, the best thing is an RPC API specification file that lists all method names and only the RPC message name.

syntax = "proto3";
package delino.appcore.v1;
option go_package = "github.com/delinoio/cloud/rpc/appcore";

import "appcore/auth.proto";

service AppCore {
  rpc UpdateUserProfile(UpdateUserProfileRequest) returns (UpdateUserProfileResponse);
}

Mentioning this file would give the AI agent

• the name of RPC methods to grep for

• the names of RPC message types to grep for

so the AI agent will never need to repeatedly guess the names.

Provide the design document, and ask the AI agent to update it.

The source of truth was the code. And yeah, the primary source of truth is still code. But you can’t feed the whole code into AI agents, and updating code requires lots of tokens. I’m not talking about the token cost. It’s about the context window size. That’s why we need a specification document that is up-to-date with the codebase and committed to the repository.

Luckily, having one is easy. You don’t need to update it manually. Instead, instruct the AI agent to read the design document before any task, and update it as required.

You may start building in a separate session after creating a plan.

• Applies to: Claude Code.

The plan mode is great. It’s a really wonderful feature that allows you to create a comprehensive task input prompt that mentions all the relevant files. But sometimes, Claude Code runs compaction nearly immediately after approving the plan because it does not clear the context before executing the plan. If you want, you can instruct it to write the comprehensive task prompt as a Markdown file, and /clear the context window, and paste it there.

In this way, Claude Code will run with a fresh context window, reading referenced files as required. It’s useful if you've done a lot of ping-pong with the planning agent.

Provide project structure.

You can provide the project structure using the instruction file (CLAUDE.md/AGENTS.md) or a custom command. Giving the project structure also reduces the number of tokens wasted to guess the project structure.

Personally, I prefer a monorepo, so I have commands like /work-on-devbird that mentions the relevant frontend/backend directory, the RPC definition, and the design documents.

Mention the filepath or the names of utility functions.

This is a good fit for the instruction files, like CLAUDE.md and AGENTS.md. The AI agent has limited knowledge of the project, so it may repeat the same code over and over. It isn’t good. If you instruct it to read the utility file beforehand, it will reuse the existing function.

If you don’t understand something, throw the whole text to the Plan Mode.

You don’t need to understand everything, seriously. You don’t need to give it a perfect prompt. Instead, you can use plan mode to expand your thoughts within the project context. Sometimes I didn’t understand some requirements because they are specific to the project, but Claude Code's plan mode expanded them into a concrete plan prompt. You can even ask Claude Code to ask you back. You can do clarification based on the questions the Claude Code asks.

2025년은 나한테 롤러코스터 같은 한 해였다. 많은 일들이 있었고 환경의 변화도 많았다. 미국과 한국을 오갔고, 소속된 곳이 바뀌었으며, 새로운 사람들을 만났다. 지난 1년을 타임라인을 따라 정리해 본다.

커리어 변화

4월 16일: Vercel 본사 근무를 위한 Relocation

Vercel 본사 근무를 위해 미국으로 이동했다. 짧지 않은 기간 동안 현지에서 일하며, 이전과는 다른 환경과 문화 속에서 일을 하게 됐다.

6월 16일: 귀국

두 달 정도의 미국 생활을 마치고 한국으로 돌아왔다. 이 시점까지도 이후의 방향이 명확하게 정해져 있던 것은 아니었다.

7월: Vercel 퇴사

어쩌다 보니 Vercel을 퇴사하게 됐다. 당시에는 회사가 지나치게 무례하다고 느꼈고, 더 이상 같이 일하고 싶지 않다는 감정이 컸다. 분노와 피로가 동시에 있었다. 말해봤자 무슨 소용이 있을까 싶을 정도였다.

시간이 조금 지난 뒤, 미국 기업 문화에 대해 미국에 거주하는 분들의 이야기를 듣고, 또 인공지능을 통해 정리해보면서 그 상황을 다시 바라보게 됐다. 미국 정서 기준으로 보면 회사 쪽이 특별히 잘못했다고 보기는 어려웠다. 한국 기준으로는 쉽게 받아들이기 힘든 방식이었지만, 억울함을 말하고 싶은 건 아니다. 그 당시의 나는 그렇게 느꼈고, 그게 전부였다.

7월: Delino 창업

나는 원래 창업이 하고 싶었다. 아이템도 여러 개 생각해두고 있었다. 마침 퇴사를 하게 되었고, 결과적으로는 잘 된 선택이었다고 생각한다. 감정과는 별개로, 방향을 바꾸기에 적절한 시점이었다.

8월 9일: Real Prompter 런칭

Claude Code를 활용해 여러 서비스를 만들면서 한 가지를 계속 느꼈다. LLM을 제대로 활용하는 것은 생각보다 어렵다는 점이었다. 많은 사람들이 “프롬프팅은 어떻게 하느냐”고 물어봤고, 나는 반복해서 비슷한 답을 해왔다.

Roo Cline 등을 사용해 내가 실제로 하던 작업 방식들을 블로그와 SNS를 통해 여러 번 공유했고, 이를 반복하다 보니 서비스화하는 편이 낫겠다는 생각이 들었다. 그렇게 Real Prompter를 만들게 됐다.

10월 14일: AutoDev 런칭

LLM을 잘 사용하는 것이 요령이나 감각의 문제인 것은 맞지만, 시스템적인 방식으로 근본적으로 해결할 수 있는 문제라고 생각했다. AI 덕분에 그 요령이나 감각조차 자동화가 가능한 시대라는 것이다.

AutoDev는 내가 이전부터 계속 이야기해오던 작업 방식을 자동화한 도구였다. 내가 강조해온 핵심은 몇 개 더 있지만, 가장 핵심적인 것은 세 가지였다.

1. 복잡한 작업을 적절한 단위로 쪼개는 것

2. 여러 세션에 걸쳐 반복적으로 검증하고 피드백을 받는 구조

3. CI와 자동 테스트를 활용한 회귀(regression) 방지

이건 새로운 아이디어라기보다는, 내가 계속 해오던 방식이었다. AutoDev는 그 방식을 도구로 옮긴 결과였다.

10월 15일: 인프런 멘토링

돈을 받고 진행한 내 인생 첫번째 멘토링이라서 적기로 했다. 인프런을 통해서 진행한 것이었고, AI 활용법 및 오픈소스 관련 전략에 대해서 많은 얘기를 나누었다. 가격이 한국 기준으론 상당한 가격이었기에 감사한 마음으로 사전 질문들 및 추후 추가 질문들도 답변해드렸다.

10월 23일: AutoDev → DevBird 리브랜딩

Microsoft에서 만든 AutoDev와 이름이 겹치면서 SEO가 사실상 불가능했다. 결국 DevBird로 리브랜딩했다. 제품의 방향이나 철학이 바뀐 것은 아니었다.

10월 27일: Zack과 미팅

Zephyr Cloud의 CEO인 Zack과 미팅을 가졌다. 네트워킹으로 분류할 수도 있었지만, 이후의 커리어와 연결되는 지점이 있어서 이 글에서는 커리어 이벤트로 남긴다.

11월 1일: Zephyr Cloud 업무 시작

많은 여행

이번 해엔 나답지 않게 여행을 많이 다녔다.

4월 16일 ~ 6월 16일: 미국 Vercel 근무

미국에서 Vercel과 함께 일한 이 두 달은 즐거움과 떨림이 공존했던 시간이었다.
낯선 환경에서 일한다는 점에서 긴장도 됐지만, 좋은 친구들을 만나 덕분에 생각보다 빠르게 적응할 수 있었다. 새로운 사람들과 함께 일하며 많이 배웠다.

10월 초: 속초 가족 여행

힐링의 시간이었다. 맛있는 음식을 함께 먹는 시간이 특히 좋았지만, 집에 두고 온 고양이가 계속 마음에 걸려서 조금 일찍 돌아와야 했던 점은 아쉬움으로 남았다.

10월 중순: 부산 여행

동생이랑 부산 여행을 갔다왔다. 열심히 걸었지만 맛있는 음식을 너무 많이 먹었는지 갔다와서 재보니까 체중이 조금 늘었다. 그리고 갈 때 ITX를 탔다. 깨끗하긴한데 너무 느렸다. 그래서 올 때는 KTX 탔다.

해동 용궁사 같은 곳도 보고 왔고, 이재모 피자 같은 맛집도 많이 찾아다녔다.

11월 16일 ~ 23일: 미국 출장 (for Zephyr Cloud)

너무 재밌었다. 일주일간 한 customer onsite였는데 업무 시간엔 일을 엄청나게 많이 했고, 어쩌다보니 앞에 나가서 데모 발표도 했다. 그리고 업무 외 시간에는 대표분이 렌트하신 차로 같이 놀러다녔는데 이게 정말 재밌었다. 재밌는 여행을 할 수 있게 해주신 대표분께 감사드린다.

11월 말 ~ 12월 초: 일본 도쿄 여행

동생이랑 일본 도쿄로 짧은 여행을 갔다왔다. 도쿄 디즈니랜드 가서 재밌게 놀았고, 미녀와 야수라는 가장 인기 많은 놀이기구에 충격을 받았다. 그래도 디즈니랜드에서 다른 건 다 재밌었어서 만족스러웠다.

근데 숙소 위치를 조금 잘못 잡았던 것 같다. 신주쿠 가부키초 쪽이었는데 저녁엔 무서워서 안 나갔다.

12월 중순: 속초 가족 여행

홈캠 등의 장비들을 설치하고 가서 고양이 걱정을 덜 한 재밌는 여행이었다. 좋은 숙소에 묵고 맛있는 음식을 많이 먹은 여행이었는데, 숙소에서 일도 꽤 많이 했다.

많은 네트워킹과 발표

여러 자리에서 사람들을 만나며 느낀 건, 생각보다 많은 사람들이 비슷한 고민을 하고 있다는 점이었다.
“AI를 어떻게 잘 써야 할까?”라는 질문이 반복해서 나왔고, 나는 여전히 AI가 버블이라고 생각하지 않는다. 다만 AI를 제대로 쓰기 위해서는, 마법 같은 도구를 기대하기보다 구조와 시스템이 먼저 필요하다고 느꼈다.

1월 말: Vercel 최지원과 페어코딩

Vercel의 최지원님과 진행한 페어코딩은 협업 자체가 굉장히 재미있었던 경험이었다.
미국 회사에서 일하면서 한국인 동료와 함께 코드를 짜는 시간이어서 더 편안하고 즐겁게 느껴졌다.

3월 1일: 팀 스파르타(항해) 손윤주 씨와 커피챗

손윤주 씨와의 커피챗에서는 그분이 정말 성실하게 일하는 분이라는 인상을 받았다.
대화 중에는 내가 AI 이야기를 많이 했고, 노트북까지 꺼내 직접 데모를 보여주며 이야기를 이어갔다.

3월 11일: 항해 AI 웨비나

이 웨비나는 개인적으로 정말 즐거운 경험이었다.
평소 주변 사람들에게 “AI는 이제 무조건 써야 한다”고 이야기하고 다녔는데, 그 메시지를 웨비나라는 공식적인 자리에서 정리해 전달할 수 있어서 좋았다. AI 도구들을 소개하며 내가 계속 강조해오던 이야기를 꺼낼 수 있었던 시간이 오래 기억에 남는다.

3월 27일: 성균관대학교 강연

원래는 긴장을 안 할 거라고 생각했지만, 교수님들이 지켜보고 계셔서 생각보다 긴장이 됐다.
그럼에도 불구하고 교수님들이 흥미롭게 들어주시고 질문까지 해주셔서 강연을 마치고 나서는 꽤 뿌듯한 기분이 들었다.

8월 6일: 오픈소스 밋업

오픈소스 밋업에서는 다양한 이야기를 들을 수 있었지만, 한편으로는 아쉬운 지점도 있었다.
오픈소스 기여를 마치 개인의 성과나 이력서 한 줄처럼 이야기하는 분위기가 있었는데, 오픈소스는 결국 문제를 함께 해결하기 위해 모이는 공동체라는 점을 다시 생각하게 됐다.

9월 16일: 크래프톤 정글 팟캐스트

이 자리에서는 Vercel에서의 경험과 실리콘밸리에서의 일하는 방식, 그리고 AI 시대에 개발자가 어떤 자세를 가져야 하는지에 대해 많이 이야기했다.
전하고 싶은 메시지가 많다 보니 조금 정리가 덜 된 채로 이야기를 한 점은 아쉬움으로 남았다.

9월 18일: Marco Ippolito 님의 서울 방문

• https://x.com/satanacchio/status/1968670634885500997

Marco Ippolito 님과의 만남은 서로의 경험을 나누며 굉장히 유익한 시간이었다.
Node 컨트리뷰터분이신데 인사이트가 매우 깊었고, 개인적으로도 많은 것을 배울 수 있었다.

9월 30일: HOCO 팟캐스트

크래프톤 정글 팟캐스트와 비슷한 주제를 다뤘지만, 이번에는 미리 블로그 글로 생각을 정리해 둔 상태에서 이야기를 풀어갈 수 있었다.
덕분에 훨씬 정돈된 흐름으로 설명할 수 있었고, 스스로도 잘했다고 느낀 자리였다.

10월 24일: 토스 프다클

토스 프다클에서는 사람들이 AI를 사용하는 수준이 생각보다 크게 다르다는 걸 실감했다.
그 경험을 통해 내가 앞으로 무엇을 해야 할지, 또 어떤 방식으로 사람들을 도울 수 있을지 감을 잡게 됐다. 동시에 개인적으로도 많은 인사이트를 얻은 의미 있는 시간이었다.

10월 30일: 항해 AI 웨비나 2

기타 이벤트

2월 중순: 수면 문제 해결

내가 원래 잠을 되게 못 자는 사람이었다. 어느 날 우연히 상추차를 접하게 되었는데, 상추차를 마시니까 잠이 잘 왔다. 며칠 실험해보고 이건 진짜라는 것을 깨달았다. 그리고 지금은 상추환으로 정착했다. 상추차를 농축해서 환으로 만들어놓은 것인데, 상추차는 차의 특성상 우리거나 마시는 데에 시간이 걸리고, 물을 많이 마시다보니 아침에 자꾸 깨서 상추환이 훨씬 나았다. 상추환을 꾸준히 먹다보니 수면에 관련된 호르몬 자체가 선순환으로 들어간건지 이제는 낮 시간에도 졸리면 낮잠을 잘 수 있게 됐다. 삶의 질이 아주 높아져서 행복하다.

11월 초: 사촌동생 결혼식

사촌동생 결혼식에 참석했다. 놀랍게도 이게 내가 가 본 첫번째 결혼식이다. 나보다 어린 나이에, 오랜 시간 함께한 연인과 결혼하는 모습을 보니까 부러웠고, 나도 원래 한명하고 오래 연애하다가 27살 쯤에 결혼하고 싶었던 사람이라서 여러 가지 생각이 들었다. 이 이벤트가 나한테 꽤나 큰 변화를 남겨서 회고록에 적는다.

마치며

2025년을 지나온 지금, 예전보다 자유롭고 행복하다. 내 일을 충분히 잘 해내고 있는 것 같아서 뿌듯하기도 하다. 여전히 실험 중이고, 여전히 복잡한 문제를 풀고 있지만, 지금의 상태는 나쁘지 않다고 느낀다.

오늘 발표에서 얘기할 내용들입니다.

기본 태도

• 적극적으로 사용해야 함. 모든 도구를 사용해볼 필요는 없지만, 좋은 평을 받는 도구는 시도해볼 것.

• AI를 적극적으로 활용하는 기업 기준, 현 시점에서 이미 프론트엔드/백엔드 같은 것은 안 중요함.

• 모든 것을 다 알아야한다는 태도는 반드시 버릴 것. 이것은 개발 씬에서 원래도 문제임. 솔직하게 말하면 개발 소질 이슈. 애매한 중상위권의 특징임.

  • 원리 이해 같은 경우, 난이도가 훨씬 낮지만 효율적인 방법은 아님.

    • 자기가 국소적 이해 기반의 코딩을 할 수 없다면 전체 설계를 이해해서라도 코딩을 해야함.

  • 큰 프로젝트 여러 개를 동시에 해야하는 경우 국소적 이해로 코딩하는 능력이 필수임.

    • 이 능력을 습득하고 싶으면 규모가 꽤 있지만 본인은 잘 모르는 오픈소스에 기여하는 것이 최고라고 생각.

    • 오픈소스에서 이것이 특히 중요한데, 규모가 큰 프로젝트 여러 개에 각각 패치를 보내야하는 일이 생각보다 자주 있는데 물어볼 사람도 없고, 문서도 내부 구현에 대한 것은 없는 경우가 대부분인데 각 프로젝트를 제대로 이해하고 작업하려고 하면 작업 시간이 지나치게 늘어남.

바이브코딩의 문제 해결책

• 바이브 코딩의 단점을 막을 가장 중요한 해결책은 테스트

• 스펙 문서는 항상 넘겨주고 적절한 수정을 요청할 것.

• 바이브 코딩 이후 작업에 대한 설명이 명확하게 이해가 안 간다면 관련 개념을 공부하는 것을 추천. 그 뒤에도 이해가 안 가면 컴퓨팅적 사고력의 문제.

AI 시대의 능력

• 1인 창업이 맞는 시대라고 보지만 (당연히) 자기 능력 검증은 필수.

• AI 없이 처음부터 끝까지 개발하기 위한 능력은 필요치 않음.

• 다시 말해, 코딩하는 능력 자체는 이제 의미가 없음.

• 하지만 AI 를 활용해서 학습하고 코딩하는 능력은 매우 중요함.

  • 바이브 코딩 이후 AI의 설명이 이해가 안 간다면 복사해서 다른 인공지능 챗봇에 붙여넣은 뒤 어떤 개념을 공부해야 이 설명을 이해할 수 있는지 물어보고 공부할 것.

이 시대의 문제 해결 능력은 2가지

• 새로운 문제를 만들지 않는 것

  • 핵심은 테스트의 활용

• 주어진 문제를 고치는 것

  • AI를 활용해보고, 문제가 생겼을 때 AI를 활용해서 해결한 경험이 많은 것이 중요함.

  • 어떻게 하면 해결되는지는 본인이 전부 기억하고 있어야 함.

지능 vs 지식

• 원래 시대가 빠르게 바뀔수록 순수 지능이 중요함. 근데 지능이란 건 함수 같은 것이고 쓰던 사람이 잘 씀. 공부할 때도 머리를 많이 쓰는 방식을 사용하는 것이 좋음.

  • 바이브 코딩하는 방법을 책이나 강의로 배울 생각을 한다면 바이브코딩 관련 재능 중 제일 중요한 것이 없는 것. 공부 방법을 근본적으로 바꿔야 함.

  • 강의나 책은 자기의 사고력을 덜 쓰는 방법이라서 편하지만 이 시대에 최악인 습관임.

• CS 지식 자체는 중요하지 않음. 중요한 건 컴퓨팅적 사고. 이게 처음부터 자유자재로 되는 사람이 있는데 그런 사람은 AI 적극적으로 쓴다는 전제 하에 CS 지식 따로 안 배워도 됨. 근데 이 애기는 천재에 대한 얘기가 아니고 생각보다 이것이 처음부터 되는 사람이 많음. 코테는 컴퓨팅적 사고가 안 되는 사람을 거르는 역할을 함.

• 코딩하는 능력 자체도 마찬가지로 코딩하는 능력이 없어도 거의 모든 개발이 가능함. 그래서 프로덕트 엔지니어라는 직군으로 바뀌는 것.

• 메타인지가 오히려 더 중요. 자기가 메타인지가 있는지 확인하는 방법:

  • 안다고 생각했는데 시험 때 생각 안 났다라는 경험이 한번이라도 있으면 메타인지가 없다고 치고 공부 계획을 짜야함.

  • 자기가 모르는데 안다고 착각하면 해결책 없는 교착 상태가 생김. 안다고 전제하지 말 것.

기타 정보

• 실리콘밸리의 새로운 변화는 보통 1~2달 정도의 시차를 두고 한국에 들어옴.

  • 프로덕트 엔지니어 직군 / AI 네이티브 인재 채용 (카카오) 등

• 코테는 허수 (컴퓨팅적 사고 안 되는 사람들) 거르기 + 면접에 드는 품 줄이기.

• 사람 급 나누기에 미친 사람들

• 중범죄자

  • 음주운전 등.

• 자기의 조그만 이익을 위해 남들한테 큰 피해를 주는 걸 아무렇지 않게 생각하는 사람들.

  • 예를 들어 우회전 할 때 반드시 지나가야하는 위치에 차 세워놓는 사람들.

• 자기 잘못은 어떻게든 합리화하는 사람들.

• 남들한테 피해주면서까지 돈 벌려는 사람들.

• 각종 망상이 심각한 사람들.

• 나 이용하려는 게 너무 티나는 사람들.

• 자기 잘못을 이해하는 능력이 글러먹은 사람들.

• 윤리의식이 나랑 너무 안 맞는 사람들.

• 쓰레기 짓 해놓고 지가 머리 잘 썼다고 생각하는 사람들.

• 자신의 이익을 위해 상황을 변조하는 사람들.

  • 일부 사실만 공개하는 것은 제외.

• 남의 돈으로 생색내는 사람들.

이렇게 늘어놓으면 인생 피곤하게 사는 것처럼 들릴 수도 있는데 이 사람들한테 공통점이 있어서 피하는 것이 그리 어렵지는 않은 것 같다.

I configured Claude Code GitHub Action correctly. You should add setup steps to emulate a real development environment before anthropics/claude-code-action@beta. The setup steps depend on the repository, but I’ll provide my Claude Code Action Setup as a reference.

.github/workflows/claude.yml:

name: Claude Code

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]
  pull_request_review:
    types: [submitted]

jobs:
  claude:
    if: |
      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
    runs-on: ['self-hosted', 'linux']
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
      actions: read # Required for Claude to read CI results on PRs
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - name: Install Protoc
        uses: arduino/setup-protoc@v3
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

      - name: Setup Node.js
        uses: ./.github/actions/setup-node

      - name: Configure environment
        run: pnpm install

      - name: Run Claude Code
        id: claude
        uses: anthropics/claude-code-action@beta
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

          # This is an optional setting that allows Claude to read CI results on PRs
          additional_permissions: |
            actions: read

          # Optional: Specify model (defaults to Claude Sonnet 4, uncomment for Claude Opus 4)
          # model: "claude-opus-4-20250514"

          # Optional: Customize the trigger phrase (default: @claude)
          # trigger_phrase: "/claude"

          # Optional: Trigger when specific user is assigned to an issue
          assignee_trigger: "claude-bot"

          # Optional: Allow Claude to run specific commands
          allowed_tools: "Bash,WebFetch,WebSearch"

          # Optional: Add custom instructions for Claude to customize its behavior for your project
          # custom_instructions: |
          #   Follow our coding standards
          #   Ensure all new code has tests
          #   Use TypeScript for new files

          # Optional: Custom environment variables for Claude
          # claude_env: |
          #   NODE_ENV: test

Note allowed_tools: "Bash,WebFetch,WebSearch". You need it to allow Claude Code to run bash commands.

Usage

Mention @claude from issues or PRs to instruct it to resolve issues.

Example:

@claude Implement comprehensive unit tests

Pro Tip: You can use local Claude Code to create a handful of issues quickly

However, there is another method, and this one is the most convenient and free. It involves using a virtual private network (VPN) service called Tailscale. After logging in and registering your device, each device is assigned an IP address.

After running the server on your development laptop, you can check the IP address of the device in the Tailscale app and connect to it using that IP address, as shown in the screenshot, to access the development server.

This is also the best option when creating a service that only you can access, as you don't need to set up complex external access settings. Install Tailscale on the specific device, deploy the service, and connect. Installing Tailscale on the server can also be done with a single line of script, making it very convenient.

As you can see on the left side of the screenshot, chats can be organized like folders, and there are features such as setting different system prompts for each folder. For example, you can set it to only use official documents for matters related to law or taxation.

With LLM models, connecting OpenRouter allows you to utilize a huge number of models freely. The models shown in the screenshot are ones that I have selected and activated. Since my family also uses it, I thought it might be unclear if there were too many.

When you turn on the web search function in the chat feature, it searches for information and organizes it for you. When the image feature is enabled, it generates images. When numbers appear during the inference process or there is a lot to manage, it uses LLM to code, executes it, and then uses the results to provide answers.

Since it supports PWA, you can add it to the home screen on mobile devices or use the app installation feature in desktop Chrome to use it like a native app.

The number of concurrent GitHub Action runners is determined by the plan of the GitHub Org to which the repository belongs, regardless of whether the repository is public. Even though GitHub Actions are unlimited and free for public repositories, they are still affected. Because of this, SWC uses the Enterprise plan.

If you're running a large open-source project and are having issues with GitHub Actions only running 20 jobs at a time, you can upgrade your plan to Team or Enterprise.

• Documentation link: https://docs.github.com/en/actions/reference/limits#job-concurrency-limits-for-github-hosted-runners

Service XXX is for ...

If anything is ambiguous or you are not sure about it, do not infer but ask me.

After spending a handful of times for clarifying everything and describing entity relations, I ask it to store it as a markdown file. Typically, it generates a very, very long text. I then follow getting started step of the framework I want to use. The latest one I used is tauri. I do this step manually just because typically it's just a few CLI commands. After creating a directory, I ask Claude Code to

Implement app in @apps/xxx.

[Paste the design markdown file content]

You'll get a bare minimum prototype that works with dummy data. Even after getting the initial version, I ask Claude Code for all modifications.

tl;dr:

I forked rayon to allow switching parallelization library or disable parallelization. See par-iter and par-core.

I'm the creator of the SWC project. I've been using chili the SWC Minifier. chili is a parallelization library with a heartbeat scheduling algorithm. I found that it performs far better than rayon for my usecase. But it lacks an API like parallel iterators of rayon. Additionally, I need to use different parallelization libraries for next.js or rspack and disable parallelism for Wasm targets. So I forked rayon and named it par-iter. par-iter is based on par-core, which allows selecting rayon or chili for parallelism or even disabling parallelism using cargo features.

I prefer to get it merged back to rayon , so I filed an issue on the rayon issue tracker to ask if they are open to PR for it, but I don't think it's likely, considering the package name.

Any ideas, thoughts, and feedback are welcome!