Jest 만든 사람이 새 도구를 짤 때, 처음 16분을 LLM에 맡기는 이유 — Codiff 워크플로

핵심 요약 (TL;DR)

Jest·Metro·Yarn을 만든 Christoph Nakazawa(cpojer)가 5/17 macOS 로컬 diff 리뷰 툴 Codiff v0.1.0을 공개했습니다. 본인이 LLM에 reference 사이트를 던지고 16분 만에 받은 첫 프로토타입 위에, 파일 필터·검색·LLM walkthrough 모드·코멘트 paste-back을 본인이 폴리시한 결과예요. 20년차 OSS 메이커가 LLM scaffolding을 부끄러워하지 않는 워크플로, 그대로 따라할 수 있는 3단계로 정리해드릴게요.

cpojer는 누구인가요

이름이 낯설어도 그가 만든 도구는 익숙합니다. Jest(JS 테스트 표준), Metro(React Native 번들러), Yarn(패키지 매니저), MooTools(2000년대 초 JS 프레임워크). Facebook에서 JavaScript Infrastructure 리드와 React Native 매니저를 했고, 지금은 도쿄에서 Nakazawa Tech의 CEO를 맡고 있습니다. GitHub 5,000+ 팔로워의 시니어 OSS 메이커예요.

그런 그가 5/17 KST 14:30경 Show HN에 올린 글의 첫 문장이 이렇습니다. "I review code written by LLMs and found existing tools limiting." LLM이 짠 코드를 잘 보고 싶어서 직접 짰는데, 그 시작이 LLM이었던 거예요.

16분의 워크플로 — 3단계

cpojer가 직접 묘사한 첫 16분을 단계로 풀면 이렇습니다.

1단계 — Reference 사이트 던지기

본인이 마음에 들어 하는 UI를 LLM에 그대로 던졌습니다. 사이트 URL 또는 스크린샷, 그게 입력의 전부였어요. "이런 사이트 보고 만들어봐" 수준의 자연어 지시 + 시각 자료.

여기서 핵심은 prompt가 짧다는 점입니다. 요구사항 명세서가 아니라 "이거랑 비슷한 거"가 입력이에요. 시니어가 LLM을 쓰는 방식이 오히려 더 간결한 거죠.

2단계 — 16분 안에 첫 빌드 받기

LLM이 받은 입력을 토대로 첫 동작하는 앱을 16분 만에 내놨습니다. 폼팩터·기본 인터랙션·diff 표시까지 포함된 동작 가능한 결과물이에요. 이 단계의 가치는 완성도가 아니라 존재입니다. 빈 종이에서 시작하는 게 아니라 깎을 덩어리를 받은 거죠.

3단계 — 시니어가 폴리시

여기부터가 본인 손입니다. cpojer가 직접 추가한 기능을 보면 — 파일 필터, 검색, 멀티 레포 지원, -w LLM walkthrough 모드(README상 Codex 명시 — "Run codiff -w to ask Codex to walk through the diffs"), 라인별 review comment, 코멘트를 Markdown으로 export해 LLM에 paste-back. 즉 시니어가 가치를 더 얹는 자리는 "LLM과의 연결 지점" 입니다. LLM이 짠 앱에, LLM과 어떻게 상호작용할지를 사람이 설계한 거예요.

이게 왜 시니어다운가요

신입이 LLM 쓰는 방식과 시니어가 쓰는 방식의 차이는 prompt 길이가 아니라 무엇을 위임하고 무엇을 본인이 잡는지에 있습니다. cpojer는 (1) UI/UX 폼팩터의 초안을 위임하고, (2) 도구 자체의 LLM 통합 지점을 본인이 설계했습니다. 후자가 더 어렵고 가치 있는 부분이에요.

게다가 cpojer의 다른 동시 운영 프로젝트들 — Athena Crisis(오픈소스 전략 게임), fate.technology(React+tRPC data client), fbtee — 을 같이 보면 이 패턴이 일관됩니다. LLM을 도구로 받아들이되 핵심 설계는 본인이 잡는 방식이죠.

따라할 수 있나요

가능합니다. 다음 도구를 만들 때 이 흐름을 그대로 적용해보세요.

1. 좋아하는 reference UI 2개를 캡처/URL로 LLM에 던지기
2. "이런 폼팩터로 [내 기능]을 만들어봐" 지시
3. 16분 안에 동작하는 첫 결과물 받기
4. 그 위에 본인만의 통합 지점·차별화 기능 추가

핵심은 첫 빌드의 완성도를 기대하지 않는 것입니다. 깎을 덩어리를 받는 게 목적이지, 출시 가능한 결과물을 받는 게 목적이 아니에요. Codiff v0.1.0이 5/17 출시 다음 날 277스타를 찍은 것도 첫 16분이 아니라 이후의 폴리시가 만든 숫자입니다.

자주 묻는 질문

Q. cpojer가 사용한 LLM이 뭔지 알 수 있나요?
A. Show HN 본문에서는 "LLM"으로만 표기됐고 모델명은 공개되지 않았습니다. 단 Codiff의 walkthrough 모드 자체는 Codex를 명시하고 있어서, 본인이 평소 Codex와 Claude를 같이 쓰는 워크플로일 가능성이 큽니다.

Q. Codiff는 어디서 받나요?
A. nkzw-tech/codiff 리포지토리에서 v0.1.0 macOS 빌드를 받을 수 있습니다. MIT 라이선스이고, 5/17 기준 277스타로 빠르게 늘고 있습니다.

Q. 신입 개발자도 같은 워크플로를 쓸 수 있나요?
A. 가능하지만 한 가지 단서가 있습니다. cpojer가 첫 16분 빌드를 빠르게 폴리시할 수 있었던 건 본인이 도메인을 깊게 알기 때문이에요. 신입은 "16분 빌드 → 폴리시" 사이에 학습 단계가 더 들어갑니다.

전체 흐름이 궁금하시면 바이브코딩 완전 가이드 2026에서 더 자세히 보실 수 있어요. LLM scaffolding의 첫 16분을 부끄러워하지 않는 게 시니어의 새로운 표준입니다.