AI 바이브 코딩하다가 Bun 써보니 진짜 편했던 이유와 실전에서 느낀 팁

요즘 퇴근하고 나서 커피 한 잔 내려놓고 Cursor 켜는 시간이 은근히 재미있더라고요. 예전 같으면 새 프로젝트 하나 시작하려고 폴더 만들고, 설정 잡고, 패키지 깔고, TypeScript 세팅하다가 기운이 빠졌는데요. 요즘은 AI한테 “이런 거 하나 만들어줘” 하고 툭 던지면 일단 뭔가 돌아가는 코드가 나오잖아요. 뭐랄까, 개발하는 리듬이 완전히 달라진 느낌이에요. 그런데 그렇게 AI 바이브 코딩을 하다 보니 의외로 발목을 잡는 게 있었습니다. 바로 실행 속도랑 세팅 시간이었어요. 그래서 이것저것 만져보다가 요즘 꽤 마음이 간 게 Bun입니다. 오늘은 제가 실제로 AI랑 코딩하면서 Bun을 어떻게 쓰고 있는지, 어디가 좋았고 어디서 삐끗했는지 편하게 풀어볼게요.

AI 바이브 코딩을 하다 보니 런타임 속도가 은근히 중요하더라

솔직히 처음에는 저도 “굳이 Bun까지 써야 하나? Node.js면 충분하지 않나?” 쪽이었어요. 20년 가까이 개발하면서 새 도구가 나올 때마다 너무 쉽게 갈아타는 것도 조심해야 한다는 걸 많이 봤거든요. 반짝 유행하다가 사라진 것도 많고요.

그런데 AI 코딩 도구를 쓰기 시작하니까 상황이 조금 달라졌습니다. 사람이 코드를 한 줄 한 줄 치는 속도보다 AI가 코드를 뽑아내는 속도가 훨씬 빠르잖아요. 그러면 병목이 어디서 생기냐면, 코드 작성이 아니라 실행하고 확인하는 단계에서 생겨요.

예를 들면 이런 흐름입니다.

Cursor나 Windsurf에서 “간단한 API 서버 만들어줘”라고 요청

AI가 TypeScript 코드와 테스트 코드를 한 번에 생성

패키지 설치

서버 실행

에러 확인

다시 AI에게 수정 요청

여기서 npm install이 오래 걸리거나, TypeScript 실행하려고 ts-node, tsx, nodemon 같은 걸 또 붙이고 있으면 흐름이 확 끊깁니다. 사실 개발할 때 이 흐름이라는 게 꽤 중요하거든요. 별거 아닌 것 같아도, 10초 기다리고 20초 기다리다 보면 방금 떠올랐던 아이디어가 살짝 식어요. 저만 그런지 모르겠지만요.

그 지점에서 Bun이 꽤 매력적으로 다가왔습니다. 패키지 설치가 빠르고, TypeScript를 거의 바로 실행할 수 있고, --watch도 기본으로 됩니다. 따로 이것저것 붙이지 않아도 되는 게 생각보다 큽니다. 특히 작은 프로토타입이나 개인 프로젝트 만들 때는요.

Node.js 대신 Bun을 써보게 된 진짜 이유

Bun을 처음 써본 건 사실 대단한 이유가 아니었어요. 어느 날 AI가 만들어준 예제 프로젝트를 돌리는데 패키지 설치가 너무 오래 걸리더라고요. 그날따라 인터넷도 살짝 버벅였고, 노트북 팬도 돌고, 제 마음도 같이 돌았습니다. 그래서 “아, 이거 좀 가볍게 갈 수 없나?” 하다가 Bun을 다시 꺼내봤어요.

설치는 간단합니다.

curl -fsSL https://bun.sh/install | bash

설치하고 나서 기존 Node.js 프로젝트에서 바로 이렇게 해봤습니다.

bun install

여기서 약간 놀랐어요. 진짜 빨랐습니다. 물론 프로젝트 규모나 환경마다 다르지만, 제가 테스트했던 작은 API 프로젝트 기준으로는 체감 차이가 꽤 컸어요. npm install 기다리던 느낌과는 많이 달랐습니다.

작업	Node.js 기반	Bun 기반	제가 느낀 체감
패키지 설치	`npm install`	`bun install`	작은 프로젝트에서는 Bun이 확실히 빠르게 느껴짐
TypeScript 실행	`tsx` 또는 `ts-node` 추가	`bun run server.ts`	세팅이 줄어서 마음이 편함
파일 변경 감지	`nodemon` 추가 사용	`bun --watch server.ts`	작은 서버 만들 때 아주 편함
테스트 실행	Jest, Vitest 등 별도 구성	`bun test`	간단한 테스트는 바로 돌리기 좋음

물론 이 표만 보고 “그럼 Node.js는 이제 끝났네?” 이렇게 말하면 곤란합니다. 저는 아직도 실무 운영 서비스에서는 Node.js를 더 신뢰하는 편이에요. 생태계가 워낙 단단하니까요. 다만 AI 바이브 코딩처럼 빠르게 만들고, 빠르게 실행하고, 빠르게 고치는 흐름에서는 Bun이 주는 장점이 꽤 선명했습니다.

실제로 AI에게 Bun API 서버를 만들어달라고 해봤다

제가 자주 하는 방식은 간단합니다. Cursor에서 새 파일 하나 열고 AI에게 이렇게 말해요.

Bun의 내장 HTTP 서버를 사용해서 TypeScript 기반 REST API 서버를 만들어줘.
GET /hello, POST /echo 엔드포인트를 포함하고,
별도 Express 없이 Bun 기본 기능만 사용해줘.

이렇게 요청하면 AI가 대체로 아래와 비슷한 코드를 만들어줍니다.

AI가 만들어준 Bun 내장 HTTP 서버 예제

import { serve } from "bun";

serve({
  port: 3000,
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === "/hello" && request.method === "GET") {
      return new Response("Hello, Vibe Coder!", {
        status: 200,
      });
    }

    if (url.pathname === "/echo" && request.method === "POST") {
      const body = await request.json();

      return new Response(JSON.stringify({ echo: body }), {
        headers: {
          "Content-Type": "application/json",
        },
      });
    }

    return new Response("Not Found", {
      status: 404,
    });
  },
});

console.log("Server running on http://localhost:3000");

그리고 실행은 이렇게 합니다.

bun run server.ts

여기서 좋은 건 TypeScript 파일인데도 별도 변환 과정 없이 바로 실행된다는 점이에요. Node.js였다면 보통 tsx를 설치하거나, 빌드 설정을 잡거나, 귀찮으면 그냥 JavaScript로 바꿨을 수도 있죠. 그런데 Bun은 이런 작은 예제를 다룰 때 아주 시원하게 갑니다.

브라우저에서 http://localhost:3000/hello를 열면 바로 응답이 옵니다.

Hello, Vibe Coder!

POST /echo는 이렇게 확인할 수 있고요.

curl -X POST http://localhost:3000/echo \
  -H "Content-Type: application/json" \
  -d '{"message":"안녕 Bun"}'

응답은 이런 식입니다.

{
  "echo": {
    "message": "안녕 Bun"
  }
}

사실 여기까지만 보면 별거 없어 보일 수도 있어요. 그런데 AI랑 주고받으면서 코드를 계속 바꾸는 상황에서는 이 간단함이 꽤 크게 다가옵니다. 파일 만들고, 실행하고, 테스트하고, 다시 수정하는 과정이 짧아지니까요.

AI가 Bun 코드를 항상 정확하게 만들어주지는 않는다

이 부분은 꼭 말하고 싶어요. AI가 코드를 잘 만들어주긴 하는데, 가끔 자신감 있게 틀립니다. 아주 당당하게요. 특히 Bun처럼 비교적 최신 도구는 AI가 오래된 문서나 Node.js 스타일 코드를 섞어서 내놓는 경우가 있습니다.

제가 겪었던 사례 중 하나는 이런 식이었어요. AI가 Bun 서버 코드를 만들어준다고 하면서 Node.js의 http 모듈과 Bun API를 어중간하게 섞었습니다.

실제로 봤던 애매한 코드

import http from "http";

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello");
  },
});

이 코드가 완전히 재앙이라는 뜻은 아닌데, 뭔가 방향이 애매하죠. http를 import 해놓고 쓰지도 않고, Bun 방식으로 갈 거면 깔끔하게 Bun 방식으로 가면 됩니다. 이런 코드는 그냥 실행은 될 수도 있지만, 프로젝트가 커지면 냄새가 납니다. 20년 개발하다 보면 이런 냄새에 좀 예민해져요. 괜히 예민한 게 아니라, 나중에 꼭 돌아오거든요.

그래서 저는 AI에게 다시 이렇게 요청합니다.

Node.js http 모듈은 사용하지 말고,
Bun의 내장 HTTP 서버 API만 사용해서 코드를 다시 정리해줘.
사용하지 않는 import도 제거해줘.

이렇게 한 번 더 말해주면 코드가 훨씬 깔끔해집니다. AI 코딩은 한 번에 완성본을 받는 느낌보다는, 옆자리 주니어 개발자와 대화하면서 점점 다듬는 느낌에 가깝습니다. 물론 그 주니어가 가끔 천재처럼 굴다가, 가끔 이상한 소리를 하는 그런 느낌이죠.

핫 리로드는 Bun에서 꽤 마음에 들었다

AI 바이브 코딩에서 제가 제일 중요하게 보는 건 즉각적인 피드백입니다. 코드를 바꿨는데 바로 확인이 안 되면 리듬이 끊겨요. 음악 듣다가 갑자기 블루투스 끊긴 느낌이랄까요.

Bun에서는 이렇게 실행하면 됩니다.

bun --watch server.ts

파일을 저장하면 자동으로 다시 실행됩니다. 간단한 API 서버나 CLI 도구를 만들 때 이게 정말 편해요. 예전에는 nodemon 설치하고, 스크립트 만들고, 설정 파일 살짝 건드리고 그랬잖아요. 물론 어려운 일은 아닌데, 귀찮습니다. 그리고 AI랑 빠르게 주고받는 상황에서는 그 귀찮음이 생각보다 크게 느껴져요.

제가 요즘 자주 쓰는 package.json은 대충 이런 느낌입니다.

{
  "scripts": {
    "dev": "bun --watch server.ts",
    "start": "bun run server.ts",
    "test": "bun test"
  },
  "dependencies": {}
}

이 정도만 있어도 작은 서버는 충분히 굴러갑니다. AI에게 “이 구조 기준으로 기능 추가해줘”라고 말하면, 대부분 이 흐름에 맞춰서 코드를 만들어줘요.

bunx는 npx 대신 꽤 자주 쓰게 된다

AI가 뭔가 설치하거나 실행하라고 알려줄 때 npx를 자주 씁니다. 예를 들면 이런 식이죠.

npx create-something my-app

Bun을 쓰는 중이라면 저는 보통 bunx로 바꿔서 실행합니다.

bunx create-something my-app

항상 100% 문제없이 되는 건 아니지만, 꽤 많은 경우 잘 됩니다. 속도도 빠른 편이고요. 다만 여기서 한 가지 조심할 점이 있습니다. AI가 알려준 명령어를 무조건 bunx로 바꾸면 안 되는 경우도 있어요. 특정 도구가 내부적으로 Node.js나 npm 동작을 강하게 가정하고 있으면 이상하게 꼬일 수 있습니다.

저는 이렇게 판단합니다.

간단한 생성기나 CLI 도구는 bunx로 먼저 시도

설치 중 에러가 나면 바로 고집하지 않고 npx로 전환

회사 프로젝트나 운영 배포와 연결된 작업은 팀 표준 도구를 우선

개인 실험 프로젝트는 Bun으로 과감하게 시도

도구는 종교가 아니라고 생각합니다. 좋으면 쓰고, 불편하면 바꾸면 됩니다. 이게 나이 먹고 개발하면서 생긴 나름의 철학이에요. 예전엔 저도 어떤 기술 하나 좋아지면 끝까지 밀어붙였는데, 요즘은 좀 유연해졌습니다. 무릎도 유연해야 하는데 그건 잘 안 되네요.

Bun과 Node.js를 AI 바이브 코딩 관점에서 비교해보면

제가 몇 주 동안 개인 프로젝트와 작은 테스트 서버에 써보면서 느낀 걸 조금 현실적으로 정리해봤습니다. 공식 벤치마크 같은 거창한 얘기보다는, 실제로 책상 앞에서 삽질하면서 느낀 쪽에 가깝습니다.

항목	Bun	Node.js
패키지 설치 속도	대체로 빠름. 작은 프로젝트에서는 체감이 큼	안정적이지만 프로젝트에 따라 꽤 기다림
TypeScript 실행	기본으로 바로 실행 가능해서 편함	추가 도구를 붙이는 경우가 많음
AI 생성 코드와의 궁합	프롬프트를 잘 쓰면 좋지만 가끔 API가 섞임	AI 학습 예제가 많아서 결과가 안정적인 편
핫 리로드	`--watch` 내장이라 간단함	`nodemon`, `tsx watch` 등 선택지가 많음
라이브러리 호환성	많이 좋아졌지만 일부 패키지는 확인 필요	생태계가 워낙 넓고 안정적임
프로토타입 제작	빠르게 시작하기 좋음	무난하고 예측 가능함
운영 서비스 적용	팀 경험과 라이브러리 검증이 필요	여전히 가장 안전한 선택지 중 하나

제 기준에서는 이렇습니다. 새로운 아이디어를 빠르게 검증할 때는 Bun이 좋고, 팀 단위로 오래 운영할 서비스라면 Node.js를 먼저 생각합니다. 물론 팀에 Bun 경험자가 많고 사용하는 라이브러리가 충분히 검증되어 있다면 Bun도 좋은 선택이 될 수 있고요.

특히 Prisma, Puppeteer, 네이티브 모듈이 얽힌 패키지들은 아직 한 번 더 확인하는 편이 좋습니다. 예전보다 많이 나아졌지만, “Bun이 Node.js 호환이라며?” 하고 덥석 믿었다가 반나절 날릴 수 있습니다. 저도 한 번 그랬습니다. 조용히 커피만 두 잔 더 마셨죠.

AI에게 Bun 코드를 요청할 때 제가 쓰는 프롬프트

AI에게 그냥 “Bun으로 만들어줘”라고 하면 결과가 들쭉날쭉할 때가 있습니다. 이건 AI가 나빠서라기보다, Bun으로 할 수 있는 방식이 여러 가지이고 Node.js 방식과 섞이기 쉽기 때문이에요.

그래서 저는 프롬프트를 조금 더 구체적으로 씁니다.

Bun 런타임 기준으로 작성해줘.
Node.js의 express, http 모듈은 사용하지 말고 Bun 내장 HTTP 서버만 사용해줘.
TypeScript와 ESM 문법을 사용해줘.
테스트는 bun test 기준으로 작성해줘.
실행 명령어와 폴더 구조도 함께 알려줘.

이렇게 말하면 결과가 훨씬 낫습니다. 특히 “Express 쓰지 말고”라고 명시하는 게 꽤 중요해요. AI는 습관처럼 Express 코드를 뱉어내는 경우가 많습니다. 워낙 예제가 많으니까요.

제가 자주 쓰는 폴더 구조

작은 API 서버를 만들 때는 이런 구조를 자주 씁니다.

my-bun-api/
  src/
    server.ts
    routes/
      hello.ts
      echo.ts
    utils/
      json.ts
  tests/
    server.test.ts
  package.json
  tsconfig.json

처음부터 너무 복잡하게 나누지는 않습니다. AI가 만들어준 코드도 처음엔 단일 파일로 받고, 기능이 2~3개 넘어가면 그때 분리하는 쪽을 좋아합니다. 괜히 처음부터 아키텍처를 크게 잡으면, 작은 프로젝트가 갑자기 회사 레거시처럼 보이기 시작하거든요. 그러면 하기 싫어집니다.

AI에게 폴더 구조까지 같이 요청하면 좋은 점이 하나 더 있습니다. 나중에 “이 구조를 유지하면서 인증 기능 추가해줘”라고 말하기가 쉬워요. AI도 맥락을 잡기 편해지고요.

bun test도 AI 코딩이랑 궁합이 괜찮다

AI가 코드를 만들어줄 때 테스트까지 같이 만들어달라고 하면 꽤 쓸만합니다. 물론 테스트 품질이 늘 좋은 건 아니에요. 가끔은 구현 코드를 그대로 따라가는 의미 없는 테스트를 만들기도 합니다. 그래도 없는 것보다는 낫습니다. 특히 빠르게 기능을 바꾸는 상황에서는 작은 안전망이 됩니다.

Bun에서는 이렇게 테스트를 실행합니다.

bun test

예를 들어 간단한 유틸 함수가 있다고 해볼게요.

export function toJson(data: unknown) {
  return new Response(JSON.stringify(data), {
    headers: {
      "Content-Type": "application/json",
    },
  });
}

AI에게 테스트를 만들어달라고 하면 이런 식으로 나올 수 있습니다.

import { expect, test } from "bun:test";
import { toJson } from "../src/utils/json";

test("toJson returns JSON response", async () => {
  const response = toJson({ message: "hello" });

  expect(response.headers.get("Content-Type")).toBe("application/json");

  const body = await response.json();
  expect(body.message).toBe("hello");
});

이 정도 테스트는 금방 돌릴 수 있고, AI가 리팩터링하면서 뭔가 깨뜨렸을 때 바로 알 수 있습니다. 저는 바이브 코딩을 할수록 테스트가 더 중요하다고 느껴요. AI가 빠르게 고쳐주는 건 좋은데, 너무 빠르게 고치다가 멀쩡한 걸 같이 건드릴 때가 있거든요.

제가 Bun을 쓰면서 정한 작은 기준들

요즘 제 개인적인 기준은 꽤 단순합니다. 모든 프로젝트에 Bun을 무조건 쓰지는 않습니다. 대신 이런 경우에는 Bun을 먼저 꺼내봅니다.

개인 토이 프로젝트를 빠르게 시작할 때

AI로 API 서버 프로토타입을 만들어볼 때

TypeScript 설정에 시간을 많이 쓰고 싶지 않을 때

테스트를 가볍게 붙여보고 싶을 때

패키지 설치와 실행 속도가 개발 리듬에 영향을 줄 때

반대로 이런 경우에는 아직 Node.js 쪽을 더 선호합니다.

회사 운영 서비스처럼 안정성이 가장 중요한 경우

팀 전체가 Node.js 기반 워크플로우에 익숙한 경우

특정 라이브러리의 Bun 호환성이 검증되지 않은 경우

배포 환경이나 모니터링 도구가 Node.js 중심으로 잡혀 있는 경우

이렇게 나눠놓으면 마음이 편합니다. Bun이 좋다고 해서 모든 걸 Bun으로 바꿀 필요는 없어요. 반대로 Node.js가 안정적이라고 해서 새로운 도구를 아예 안 만져볼 이유도 없고요. 개발자는 결국 도구를 잘 고르는 사람이라고 생각합니다. 망치가 좋다고 나사까지 두드리면 안 되잖아요.

AI 바이브 코딩에서 Bun을 잘 쓰는 제 나름의 꿀팁

몇 가지는 실제로 써보면서 생긴 습관입니다. 별거 아닌데, 이런 작은 것들이 쌓이면 개발 흐름이 꽤 좋아집니다.

프롬프트에 “Bun 런타임 기준”이라고 꼭 적기

Express를 쓰지 말라고 명시하기

테스트는 bun test 기준으로 요청하기

AI가 만든 API가 최신 Bun 문서와 맞는지 한 번 확인하기

패키지 호환성 문제가 나면 오래 붙잡지 말고 Node.js로 전환하기

프로토타입에서는 단일 파일로 시작하고, 커질 때 폴더를 나누기

실행 스크립트는 package.json에 바로 정리해두기

저는 특히 “오래 붙잡지 않기”가 중요하다고 봅니다. 새로운 도구를 쓸 때 가장 위험한 게, 도구를 쓰려고 프로젝트를 하는 건지 프로젝트를 하려고 도구를 쓰는 건지 헷갈리는 순간이에요. Bun 때문에 30분 이상 막히면 일단 Node.js로 돌려보고, 그래도 Bun이 필요하면 나중에 다시 봅니다. 이게 정신 건강에 좋습니다.

이런 분들은 Bun을 한 번 써봐도 좋겠다

제 느낌으로는 Bun은 지금 당장 모든 걸 대체하는 도구라기보다, AI 바이브 코딩 시대에 꽤 잘 어울리는 빠른 작업 도구에 가깝습니다. 특히 빠르게 만들고, 바로 실행하고, AI에게 다시 수정시키는 흐름에서는 장점이 분명해요.

이런 분들에게는 한 번 써보라고 말하고 싶습니다.

Cursor, Windsurf 같은 AI 코딩 도구를 자주 쓰는 개발자

새 프로젝트 시작할 때 세팅 시간이 아깝다고 느끼는 분

TypeScript 기반 작은 API 서버를 자주 만드는 분

Node.js는 익숙하지만 새로운 런타임도 가볍게 경험해보고 싶은 분

개인 프로젝트나 프로토타입을 빠르게 굴려보고 싶은 분

반대로 회사 핵심 서비스에 바로 적용하려는 분이라면 조금 천천히 가셔도 됩니다. 라이브러리 호환성, 배포 환경, 팀원 숙련도까지 같이 봐야 하니까요. 실무는 늘 멋보다 안전이 먼저입니다. 이건 오래 해보니 더 확실히 느껴요.

그래도 개인 프로젝트라면 이야기가 다릅니다. 한 번 설치해서 bun run, bun --watch, bun test 정도만 써봐도 감이 옵니다. “아, 이래서 사람들이 빠르다고 하는구나” 싶은 순간이 있어요.

저는 요즘 새로운 아이디어가 떠오르면 일단 Bun으로 작게 시작해봅니다. 안 맞으면 Node.js로 돌아가면 되고요. 그 정도 가벼운 마음으로 쓰기에는 정말 괜찮은 도구입니다. AI가 코드를 만들어주고, Bun이 빠르게 돌려주고, 저는 옆에서 방향만 잡는 느낌. 솔직히 이 조합, 꽤 재미있습니다.

개발 오래 하다 보면 새 기술에 무덤덤해질 때도 있는데요. Bun과 AI 코딩 도구를 같이 쓰면서는 오랜만에 조금 설렜습니다. 예전 밤샘 코딩하던 시절의 그 느낌이 살짝 돌아온다고 해야 하나요. 물론 이제 밤새면 다음 날 회복이 안 되니 적당히 해야 합니다. 아무튼, AI 바이브 코딩을 더 빠르고 가볍게 해보고 싶은 분이라면 Bun은 한 번쯤 꼭 만져볼 만합니다.

🔍 관련 정보 더 보기

Iros

이 블로그 검색

Featured Post