AI를 활용한 코드 생성

코드 생성 품질은 모델보다 지시의 구조에 더 크게 좌우됩니다.

좋은 지시의 네 요소

1. 무엇을 — 만들 대상
2. 어디에 — 파일 경로나 모듈
3. 어떤 제약으로 — 사용할 라이브러리, 지켜야 할 패턴
4. 어떻게 확인할지 — 성공 기준

네 가지를 담은 예시입니다.

components/ui/toast.tsx 에 토스트 알림 컴포넌트를 만들어줘.
- 기존 button.tsx 와 같은 스타일 컨벤션을 따를 것
- 성공/오류/정보 3가지 종류
- 3초 후 자동 사라짐, 수동 닫기 버튼도 있음
- 접근성: role="status", 키보드로 닫을 수 있어야 함
만든 뒤 npm run typecheck 로 타입 오류가 없는지 확인해줘.

기존 코드를 기준으로 삼기

가장 효과적인 한 문장은 이것입니다.

"기존 xxx.tsx와 같은 방식으로 만들어줘."

새 컨벤션을 설명하는 것보다 참조할 실물을 주는 게 훨씬 정확합니다.

테스트를 먼저 시키기

formatPrice 함수의 테스트를 먼저 작성해줘.
0, 음수, 소수점, 아주 큰 수를 포함해서.
그 다음 테스트를 통과하는 구현을 만들어줘.

테스트가 먼저 있으면 Claude가 스스로 검증하며 진행합니다. 결과 신뢰도가 크게 올라갑니다.

단계를 나누기

큰 기능을 한 번에 시키면 뭉뚱그려진 결과가 나옵니다.

한 번에 (X)

회원가입 기능 만들어줘.

나눠서 (O)

1단계: 회원가입 폼 UI만 만들어줘. 제출은 아직 console.log만.
2단계: 입력 검증 규칙을 추가해줘. 이메일 형식, 비밀번호 8자 이상.
3단계: API 라우트를 만들고 폼과 연결해줘.

각 단계마다 확인하고 넘어가면 방향이 크게 어긋나지 않습니다.

생성된 코드를 검토하는 눈

돌아간다고 좋은 코드는 아닙니다. 다음을 확인하세요.

• 예외 상황 처리 — 빈 값, 실패, 타임아웃
• 기존 유틸 재사용 — 이미 있는 함수를 새로 만들지 않았는가
• 불필요한 추상화 — 한 번만 쓰는데 인터페이스를 만들었는가
• 보안 — 사용자 입력이 검증 없이 쓰이는 곳은 없는가

안 될 때 쓰는 문장

지금 접근이 잘 안 되는 것 같아. 
왜 이 방식을 선택했는지 설명해주고, 다른 방법 두 가지를 제안해줘.

같은 방향으로 계속 밀어붙이는 것보다 훨씬 빨리 풀립니다.

연습 문제

1. 기존 컴포넌트 하나를 지목하고 "이것과 같은 스타일로 새 컴포넌트를 만들어줘"라고 해 보세요.
2. 테스트를 먼저 작성하게 한 뒤 구현을 시켜 보세요. 결과 차이를 비교해 보세요.

다음 레슨

디버깅 지원 기능