Featured Post

20년 개발자가 Storybook에 AI 바이브 코딩을 붙여보고 느낀 진짜 편한 점들

작성자:
Storybook - UI 컴포넌트 관련 이미지

요즘 주변 개발자들이랑 커피 마시다 보면 AI 바이브 코딩 이야기가 꽤 자주 나와요. 처음엔 저도 “또 새로운 말 하나 생겼네” 정도로 넘겼거든요. 그런데 막상 제 업무에 조금씩 끼워 넣어보니까, 이게 생각보다 단순한 유행어가 아니더라고요. 특히 React 프로젝트에서 Storybook을 같이 쓰는 팀이라면, 이 조합은 진짜 한 번쯤 써볼 만합니다.

제가 개발을 20년 가까이 하면서 느낀 게 하나 있어요. 개발 생산성을 올려준다는 도구는 많았지만, 실제로 내 하루의 피로도를 줄여주는 도구는 그렇게 많지 않았거든요. 그런데 AI를 페어 프로그래머처럼 옆에 두고, Storybook 스토리 작성 같은 반복 작업을 맡겨보니 “아, 이건 좀 다르다” 싶었습니다. 물론 AI가 다 해주는 건 아니에요. 아직도 엉뚱한 코드를 만들 때가 있고, 가끔은 자신감 있게 틀립니다. 그게 좀 웃기기도 하고요.

그래도 잘만 쓰면 꽤 든든합니다. 오늘은 제가 실제 업무에서 AI 바이브 코딩과 Storybook을 어떻게 같이 쓰고 있는지, 버튼 컴포넌트 예제로 보여드리고, 몇 달 동안 삽질하면서 얻은 나름의 꿀팁도 편하게 풀어볼게요. 딱딱한 강의라기보다는, 친한 개발자 친구한테 “야, 이거 써봤는데 괜찮더라” 하고 이야기하는 느낌으로 봐주시면 좋겠습니다.

왜 하필 AI 바이브 코딩이랑 Storybook을 같이 쓰게 됐냐면요

요즘 제가 맡고 있는 프로젝트는 React 기반이고, 내부 UI 컴포넌트가 꽤 많습니다. 버튼, 모달, 드롭다운, 탭, 배지, 카드, 폼 필드까지 합치면 100개가 훌쩍 넘어가요. 처음엔 괜찮았습니다. 컴포넌트 하나 만들고 Storybook 스토리 하나 붙이고, 디자인팀이랑 확인하고, QA에서 보고. 뭐 늘 하던 일이니까요.

문제는 컴포넌트가 늘어나면서부터였어요. 컴포넌트 자체를 만드는 시간보다 스토리 파일을 만들고, props 조합을 챙기고, Controls 설정을 붙이는 시간이 은근히 많이 잡아먹더라고요. 버튼 하나는 별거 아닌데, 그게 30개, 50개가 되면 이야기가 달라집니다.

예전에는 버튼 컴포넌트 하나에 Storybook 스토리 파일을 제대로 붙이려면 대략 20~30분은 걸렸어요. 물론 복사해서 붙이면 더 빨리 할 수도 있죠. 그런데 복붙은 또 복붙대로 사고가 납니다. title 잘못 들어가고, argTypes 이전 컴포넌트 거 남아 있고, disabled 상태 빼먹고. 이런 건 아주 사소한데, 나중에 보면 참 귀찮습니다.

그래서 어느 날 퇴근 전에 조금 지친 상태로 AI한테 그냥 던져봤어요. “이 컴포넌트에 맞는 Storybook 스토리 좀 만들어줘.” 기대를 크게 안 했는데, 생각보다 그럴듯한 결과가 나왔습니다. 그때부터였던 것 같아요. 제가 AI를 코드 생성기가 아니라, 반복 작업을 같이 처리해주는 동료처럼 보기 시작한 게요.

제가 생각하는 AI 바이브 코딩은 이런 느낌입니다

사람마다 정의가 조금씩 다르겠지만, 제가 생각하는 AI 바이브 코딩은 AI에게 일을 한 번에 완벽하게 시키는 방식이 아니에요. 오히려 계속 대화하면서 방향을 잡아가는 방식에 가깝습니다.

예를 들면 이런 식이죠.

“이 버튼 컴포넌트에 대한 Storybook 스토리를 만들어줘.
variant는 primary, secondary가 있고
size는 small, medium, large가 있어.
disabled 상태도 Controls에서 바꿀 수 있게 해줘.”

AI가 코드를 만들어주면 저는 그걸 그대로 믿지 않습니다. 일단 훑어봐요. import 경로 맞는지, Storybook 버전에 맞는 문법인지, 우리 팀 컨벤션이랑 맞는지, children 처리는 자연스러운지. 그러다 마음에 안 드는 부분이 있으면 다시 말합니다.

“AllSizes 스토리는 버튼들이 너무 붙어 보이니까 gap이 있는 wrapper로 감싸줘.
그리고 우리 프로젝트는 meta에 parameters.layout = 'centered'를 항상 넣어.”

이런 식으로 몇 번 주고받다 보면, 처음보다 훨씬 우리 프로젝트에 맞는 코드가 나옵니다. 이게 제가 말하는 바이브예요. 분위기 타고 대충 한다는 뜻이 아니라, 내가 방향을 잡고 AI가 속도를 붙여주는 방식이라고 보는 게 맞습니다.

기존 방식 AI 바이브 코딩 방식 제가 느낀 차이
스토리 파일을 직접 처음부터 작성 AI가 초안을 만들고 개발자가 다듬음 반복 작업 시간이 확 줄어듦
props 조합을 매번 손으로 구성 props 명세를 주고 여러 상태를 한 번에 생성 빠뜨리는 케이스가 줄어듦
팀 컨벤션을 계속 신경 써야 함 예제 파일을 주고 같은 형식으로 요청 초안 품질이 꽤 안정적임
단순 작업에도 집중력을 많이 씀 검토와 의사결정에 집중 퇴근 무렵 피로도가 조금 덜함

실제 예제: CustomButton Storybook 스토리를 AI에게 맡겨봤습니다

말로만 하면 좀 뜬구름 잡는 이야기 같으니까, 실제 예제를 하나 보여드릴게요. 프로젝트에서 자주 쓰는 버튼 컴포넌트가 있다고 해볼게요. 이름은 CustomButton입니다.

이 컴포넌트는 아래 props를 받습니다.

    • variant: 'primary' 또는 'secondary'
    • size: 'small', 'medium', 'large'
    • disabled: 버튼 비활성화 여부
    • children: 버튼 안에 들어갈 텍스트나 요소

예전 같으면 저는 CustomButton.stories.js 파일을 열고 하나씩 작성했을 거예요. 그런데 요즘은 일단 AI에게 이렇게 요청합니다. 실제로 제가 쓰는 프롬프트와 거의 비슷합니다.

// 프롬프트 예시
“다음 React 컴포넌트에 대한 Storybook 7 스토리 파일을 작성해줘.

조건:

  • 컴포넌트명: CustomButton


  • props:


  • variant: 'primary' | 'secondary'


  • size: 'small' | 'medium' | 'large'


  • disabled: boolean


  • children: React.ReactNode


  • 기본 스토리는 Default라는 이름으로 만들어줘.


  • Default는 variant='primary', size='medium', disabled=false로 설정해줘.


  • Disabled, LargeSecondary, AllSizes 스토리도 추가해줘.


  • CSF(Component Story Format) 형식으로 작성해줘.


  • meta의 title은 'Buttons/CustomButton'으로 해줘.


  • Controls에서 variant, size, disabled를 바꿀 수 있게 argTypes를 넣어줘.


  • Play function은 필요 없어.”

여기서 중요한 건 “버튼 스토리 만들어줘”라고 뭉뚱그려 말하지 않는 거예요. AI는 친절하긴 한데, 정보가 부족하면 자기 마음대로 상상합니다. 그래서 저는 props 타입, 원하는 스토리 이름, Storybook 버전, 필요 없는 기능까지 같이 말해주는 편이에요. 귀찮아 보여도 이게 나중에 손이 덜 갑니다.

AI가 만들어준 결과는 대략 이런 형태였습니다.

// CustomButton.stories.js
import CustomButton from './CustomButton';

export default {
  title: 'Buttons/CustomButton',
  component: CustomButton,
  argTypes: {
    variant: {
      control: 'select',
      options: ['primary', 'secondary']
    },
    size: {
      control: 'select',
      options: ['small', 'medium', 'large']
    },
    disabled: {
      control: 'boolean'
    }
  }
};

export const Default = {
  args: {
    variant: 'primary',
    size: 'medium',
    disabled: false,
    children: 'Button'
  }
};

export const Disabled = {
  args: {
    ...Default.args,
    disabled: true,
    children: 'Disabled Button'
  }
};

export const LargeSecondary = {
  args: {
    variant: 'secondary',
    size: 'large',
    disabled: false,
    children: 'Large Secondary'
  }
};

export const AllSizes = {
  render: () => (
    <div>
      <CustomButton size="small">Small</CustomButton>
      <CustomButton size="medium">Medium</CustomButton>
      <CustomButton size="large">Large</CustomButton>
    </div>
  )
};

처음 나온 결과치고는 꽤 괜찮았습니다. argTypes도 잘 잡았고, Default, Disabled, LargeSecondary, AllSizes도 요청한 대로 만들어줬어요. 예전 같으면 제가 손으로 치면서 중간중간 문법 확인하고, 실행해보고, 오타 고치고 했을 텐데 말이죠.

다만 그대로 쓰진 않았습니다. 특히 AllSizes 쪽은 버튼들이 너무 붙어서 보였어요. 이런 부분은 AI가 잘 모릅니다. 우리 팀의 디자인 감각이나 Storybook에서 보기 좋은 간격 같은 건 결국 사람이 봐야 하거든요.

// 제가 살짝 다듬은 AllSizes
export const AllSizes = {
  render: () => (
    <div style={{ display: 'flex', gap: '12px', alignItems: 'center' }}>
      <CustomButton size="small">Small</CustomButton>
      <CustomButton size="medium">Medium</CustomButton>
      <CustomButton size="large">Large</CustomButton>
    </div>
  )
};

이 정도 수정이면 정말 가볍죠. 사실 이게 핵심입니다. AI가 만든 코드를 그대로 붙여 넣는 게 아니라, 초안을 빠르게 받고 내가 맥락을 입히는 것. 저는 이 방식으로 버튼 하나당 20~30분 걸리던 작업을 보통 5분 안쪽으로 줄였습니다. 컨디션 좋은 날엔 더 빨라요. 약간 옆에서 일 잘하는 인턴이 초안 만들어주는 느낌이랄까요. 물론 가끔 사고도 칩니다.

요청한 조건 AI가 만든 결과 제가 손본 부분
variant, size, disabled Controls 설정 argTypes에 select, boolean control을 잘 생성 거의 없음
Default, Disabled, LargeSecondary, AllSizes 생성 요청한 스토리를 모두 생성 스토리 이름과 children 문구만 약간 수정
AllSizes에서 여러 크기 비교 단순 div 안에 버튼만 나열 flex, gap, alignItems 스타일 추가
Play function 제외 요청대로 넣지 않음 없음

AI가 잘하는 일과 아직 맡기면 불안한 일이 있더라고요

몇 달 써보니까 감이 좀 왔습니다. AI한테 맡기면 아주 편한 일이 있고, 괜히 맡겼다가 내가 더 고생하는 일이 있어요. 이 선을 구분하는 게 생각보다 중요합니다.

정적인 Storybook 스토리 초안은 꽤 잘 만듭니다

Controls 기반의 기본 스토리는 AI가 정말 잘 만듭니다. props가 명확하고, 상태 조합이 단순한 컴포넌트일수록 결과가 좋아요. Button, Badge, Avatar, Tag, Alert 같은 컴포넌트는 거의 바로 쓸 수 있는 수준으로 나올 때도 많습니다.

예를 들어 이런 컴포넌트들은 AI에게 맡기기 좋았습니다.

    • Button처럼 variant와 size 조합이 명확한 컴포넌트
    • Badge처럼 color, label 정도만 바뀌는 컴포넌트
    • Avatar처럼 src, alt, size를 Controls로 확인하면 되는 컴포넌트
    • Alert처럼 type, title, description 조합을 보여주면 되는 컴포넌트

반대로 상태가 복잡하거나 외부 API, context, router, async 동작이 엮이면 이야기가 달라집니다. AI가 그럴듯하게 만들긴 하는데, 실제 프로젝트에서는 깨지는 경우가 꽤 있었어요.

Play function은 아직 조심스럽습니다

Storybook 7부터 Play function을 이용해서 상호작용 테스트를 할 수 있잖아요. 저도 처음엔 이 부분까지 AI에게 맡기면 좋겠다 싶었습니다. “버튼 클릭 테스트도 만들어줘”라고 요청했죠.

그런데 여기서 좀 고생했습니다. AI가 @storybook/test의 userEvent를 사용하긴 하는데, 클릭 대상 셀렉터를 이상하게 잡거나, 비동기 처리를 애매하게 하거나, canvas 접근 방식을 프로젝트 설정과 다르게 쓰는 경우가 있더라고요.

// AI가 가끔 만들어내는 애매한 예시
export const Clickable = {
  args: {
    children: 'Click me'
  },
  play: async ({ canvasElement }) => {
    const button = canvasElement.querySelector('button');
    await userEvent.click(button);
    expect(button).toHaveTextContent('Clicked');
  }
};

겉보기엔 그럴듯합니다. 그런데 실제 컴포넌트가 클릭 후 텍스트를 바꾸는 구조가 아니라면 이 테스트는 그냥 틀린 테스트예요. AI가 컴포넌트 내부 상태를 제대로 모른 채 “보통 이런 식이겠지” 하고 만든 겁니다. 이럴 때는 디버깅하는 시간이 더 들어요.

그래서 저는 기준을 정했습니다. 정적인 스토리와 Controls는 AI에게 맡기고, Play function은 내가 직접 작성한다. 이 기준을 세우고 나니 훨씬 편해졌어요. AI가 잘하는 일만 맡기면 됩니다. 사람도 그렇잖아요. 각자 잘하는 일이 있죠.

제가 실제로 쓰면서 정착한 프롬프트 방식

AI에게 일을 잘 시키려면 프롬프트를 너무 멋있게 쓰려고 할 필요는 없습니다. 대신 구체적으로 써야 해요. 개발에서 구체적이라는 건 결국 타입, 조건, 금지사항, 원하는 출력 형식을 말해주는 겁니다.

제가 자주 쓰는 프롬프트 구조는 거의 정해져 있습니다.

다음 컴포넌트의 Storybook 7 스토리 파일을 만들어줘.

[컴포넌트 정보]

  • 컴포넌트명:


  • import 경로:


  • props:


  • 기본값:


  • 사용 중인 스타일 방식:


[스토리 요구사항]

  • 만들어야 할 스토리 목록:


  • Controls 설정:


  • title:


  • parameters:


  • 제외할 기능:


[팀 컨벤션]

  • CSF 형식 사용


  • render가 필요한 경우에만 render 사용


  • Play function 작성하지 않음


  • 불필요한 설명 없이 코드만 출력

이렇게 틀을 만들어두면 매번 새로 고민할 필요가 없습니다. 저는 회사 개인 메모장에 이 프롬프트 템플릿을 저장해두고, 컴포넌트에 맞게 조금씩 바꿔 씁니다. 별거 아닌데, 이게 꽤 시간을 아껴줘요.

props 명세는 꼭 붙여주는 편이 좋습니다

AI에게 “알아서 추론해줘”라고 하면 정말 알아서 합니다. 문제는 그 알아서가 우리 프로젝트와 맞지 않을 때가 많다는 거예요. 그래서 저는 컴포넌트의 props interface나 JSDoc을 가능한 한 그대로 붙여줍니다.

// 프롬프트에 같이 붙이는 정보 예시
/**

  • @param {string} variant - 'primary' | 'secondary'


  • @param {'small'|'medium'|'large'} size


  • @param {boolean} disabled


  • @param {React.ReactNode} children

 */

TypeScript 프로젝트라면 interface를 그대로 넣는 게 더 좋습니다.

interface CustomButtonProps {
  variant: 'primary' | 'secondary';
  size: 'small' | 'medium' | 'large';
  disabled?: boolean;
  children: React.ReactNode;
}

이 정도만 넣어줘도 argTypes 품질이 확 좋아집니다. 특히 select options를 AI가 정확히 잡아줘요. 예전엔 제가 이런 부분을 하나씩 손으로 쓰다가 오타를 내곤 했는데, 이제는 AI가 초안을 잘 만들어주니 마음이 좀 편합니다.

기존 스토리 파일을 보여주면 결과가 훨씬 안정됩니다

팀 프로젝트에서 제일 무서운 건 코드가 제각각 되는 겁니다. 기능은 돌아가는데 파일마다 스타일이 다르면, 나중에 유지보수할 때 은근히 피곤해요. Storybook도 마찬가지입니다.

그래서 저는 AI에게 새 스토리를 만들게 할 때, 기존에 잘 작성된 스토리 파일 하나를 같이 보여줍니다.

“아래 스토리 파일의 스타일과 구조를 그대로 따라줘.
title 네이밍, parameters, argTypes 작성 방식도 동일하게 맞춰줘.
이제 같은 형식으로 CustomButton.stories.js를 만들어줘.”

이렇게 하면 AI가 프로젝트의 리듬을 어느 정도 따라옵니다. 물론 100%는 아니에요. 가끔 갑자기 새로운 패턴을 들고 옵니다. 그럴 땐 한 번 더 말해주면 됩니다.

“방금 만든 코드는 우리 기존 패턴과 조금 달라.
render를 기본 스토리에 쓰지 말고 args 중심으로 다시 작성해줘.”

이런 대화를 몇 번 해보면, AI와 협업하는 감각이 생깁니다. 완벽한 자동화라기보다는, 빠르게 초안을 만들고 방향을 바로잡는 느낌이에요. 저는 이 정도가 오히려 좋더라고요. 모든 걸 맡기면 불안하고, 아무것도 안 맡기면 아깝고요.

조금 삽질했던 부분도 솔직히 이야기해볼게요

좋은 이야기만 하면 좀 재미없죠. 실제로 쓰면서 짜증났던 부분도 있었습니다. 특히 Storybook 설정 파일이나 글로벌 데코레이터 쪽은 조심해야 합니다.

.storybook/preview.js는 함부로 맡기지 않습니다

AI에게 “우리 Storybook에 ThemeProvider 적용해줘”라고 하면 .storybook/preview.js를 수정해주긴 합니다. 그런데 문제는 import 경로를 자기 마음대로 만들거나, 실제 프로젝트에 없는 파일을 가져오기도 한다는 거예요.

// AI가 종종 만드는 위험한 예시
import { ThemeProvider } from '../src/styles/theme';
import GlobalStyle from '../src/styles/GlobalStyle';

우리 프로젝트에 저 경로가 있으면 괜찮죠. 그런데 없으면 바로 깨집니다. 더 난감한 건, 경로는 비슷한데 실제 export 방식이 다른 경우예요. 이런 건 에러 메시지도 살짝 애매하게 나옵니다.

그래서 저는 전역 설정은 직접 관리합니다. 대신 AI에게는 이렇게 말합니다.

“preview.js는 수정하지 말고,
이미 ThemeProvider와 GlobalStyle은 전역으로 적용되어 있다고 가정해줘.
스토리 파일만 작성해줘.”

이 한 줄을 넣으면 쓸데없는 설정 변경을 많이 막을 수 있습니다. 경험상 AI에게 권한을 어디까지 줄지 정해주는 게 정말 중요합니다. 사람한테 일 맡길 때도 마찬가지잖아요. “이건 건드리지 말고 이것만 해줘”가 필요합니다.

MDX 문서는 생각보다 괜찮게 만듭니다

반대로 AI가 의외로 잘하는 부분도 있었습니다. 바로 Storybook의 Docs용 MDX 문서예요. 컴포넌트 사용 예시나 주의사항을 정리하는 데는 꽤 쓸만했습니다.

예를 들어 버튼 컴포넌트 문서를 만들 때 이렇게 요청하면요.

“CustomButton 컴포넌트의 Storybook MDX 문서를 작성해줘.
내용은 사용 목적, variant 설명, size 설명, disabled 사용 예시 정도만 넣어줘.
문장은 너무 길지 않게 2~3줄 중심으로 써줘.”

결과가 꽤 괜찮습니다. 다만 AI는 설명을 조금 과하게 친절하게 쓰는 경향이 있어요. 컴포넌트 하나 설명하는데 갑자기 철학을 이야기할 때가 있습니다. 그럴 땐 짧게 말하면 됩니다.

“설명은 줄이고, 실제 사용 예시 중심으로 다시 작성해줘.”

이렇게 요청하면 훨씬 실무 문서에 가까워집니다. 저는 요즘 팀 내부 컴포넌트 문서를 만들 때 MDX 초안은 AI에게 맡기는 편이에요. 사람이 처음부터 빈 화면을 보는 것보다, 뭔가 초안이 있는 상태에서 고치는 게 훨씬 편하거든요.

제가 정착한 AI 바이브 코딩 체크리스트

지금은 Storybook 작업할 때 거의 습관처럼 확인하는 체크리스트가 있습니다. 거창한 건 아니고, 사고를 줄이기 위한 작은 습관들이에요.

    • props 타입을 AI에게 반드시 보여준다. 추론에 맡기면 이상한 prop이 생길 수 있습니다.
    • Storybook 버전을 명시한다. Storybook 6 방식과 7 방식이 섞이면 은근히 귀찮습니다.
    • Play function은 필요할 때만 직접 작성한다. AI 초안은 참고만 합니다.
    • 기존 스토리 파일을 예제로 준다. 팀 컨벤션 유지에 도움이 됩니다.
    • .storybook 설정 파일은 조심한다. 전역 설정은 가능하면 사람이 직접 봅니다.
    • AI가 만든 코드는 반드시 실행해본다. 그럴듯한 코드와 돌아가는 코드는 다릅니다.
    • 한 번에 너무 많은 걸 시키지 않는다. 스토리 작성, 문서 작성, 테스트 작성은 나눠서 요청하는 게 낫습니다.

사실 이 체크리스트만 지켜도 AI 때문에 생기는 삽질이 꽤 줄어듭니다. AI가 틀렸다고 화내기보다는, 내가 애매하게 시킨 건 아닌지 한 번 보는 것도 필요하고요. 물론 AI가 그냥 틀릴 때도 있습니다. 그땐 조용히 다시 시키면 됩니다. 감정 소모할 필요 없어요.

실무에서 느낀 가장 큰 장점은 속도보다 여유였습니다

많은 분들이 AI를 이야기할 때 생산성, 속도, 자동화 같은 단어를 먼저 떠올리잖아요. 저도 처음엔 그랬습니다. 그런데 몇 달 써보니 제일 크게 와닿은 건 의외로 여유였어요.

반복적인 Storybook 스토리 작성에서 조금 벗어나니까, 컴포넌트 자체를 더 오래 보게 되더라고요. 이 props 이름이 진짜 맞나, disabled 상태 디자인이 어색하진 않나, 디자이너가 봤을 때 이 variant 구성이 이해하기 쉬울까. 예전에는 스토리 파일 만들다가 힘이 빠져서 이런 걸 대충 넘긴 적도 있었거든요.

AI가 제 일을 빼앗는다기보다는, 귀찮은 초벌 작업을 덜어주니까 제가 더 중요한 판단에 에너지를 쓰게 됐습니다. 40대 개발자로 일하다 보면 체력도 예전 같지 않아서요. 농담 같지만 진짜입니다. 밤 10시에 argTypes 오타 잡고 있으면 인생이 살짝 허무해집니다.

그런 의미에서 저는 AI 바이브 코딩을 무조건 찬양하진 않지만, 잘 쓰면 꽤 괜찮은 동료라고 생각합니다. 단, 기본기가 있어야 더 잘 씁니다. AI가 만든 코드가 맞는지 틀린지 판단하려면 결국 개발자가 알아야 하거든요.

이 글은 이런 분들이 읽으면 특히 도움이 될 것 같아요

Storybook을 도입했는데 스토리 작성이 귀찮아서 자꾸 미루는 개발자라면 한 번 써보셔도 좋습니다. 버튼 하나, 배지 하나처럼 작은 컴포넌트부터 시작하면 부담이 없어요.

React 컴포넌트 라이브러리를 관리하는 시니어 개발자에게도 꽤 잘 맞습니다. 반복적인 파일 작성은 AI에게 초안을 맡기고, 본인은 구조와 품질을 보는 쪽에 집중할 수 있으니까요.

주니어 개발자에게도 괜찮습니다. 다만 그대로 복붙하지 말고, AI가 만든 Storybook 스토리를 읽어보면 좋아요. props가 어떻게 Controls로 연결되는지, 상태별 스토리를 왜 나누는지 이해하는 데 도움이 됩니다.

저는 앞으로도 이 조합을 계속 쓸 생각입니다. 다만 모든 걸 AI에게 맡기지는 않을 거예요. 제 기준은 분명합니다. 반복적이고 구조가 명확한 일은 AI에게 맡기고, 맥락과 판단이 필요한 일은 사람이 한다. 이 정도 균형이면 지금 단계에서는 꽤 건강한 방식이라고 봅니다.

혹시 아직 안 써보셨다면, 거창하게 시작하지 마세요. 그냥 지금 프로젝트에 있는 버튼 컴포넌트 하나만 AI에게 Storybook 스토리를 만들어달라고 해보세요. 그리고 나온 코드를 살짝 고쳐보세요. 그 정도만 해도 “아, 이래서 사람들이 AI 바이브 코딩 이야기하는구나” 하는 느낌이 올 겁니다.

늦은 밤에 Storybook 켜놓고 컴포넌트 하나씩 확인하는 개발자분들, 다들 고생 많습니다. 우리 너무 열심히만 하지 말고, 쓸 수 있는 도구는 적당히 잘 써가면서 오래 개발합시다. 그게 요즘 제가 가진 작은 개발 철학입니다.

댓글

댓글 쓰기