AI에게 코드를 잘 시키는 프롬프트 작성법: 명세·제약·예시 3요소
AI 코딩 요청을 막연한 지시에서 실행 가능한 작업 지시서로 바꾸는 법을 정리합니다. 명세, 제약, 예시 3요소로 재작업을 줄이는 실전 프롬프트 구조입니다.
목차
이 글의 목차
왜 AI 코딩 프롬프트는 짧을수록 비싸질까

AI에게 “로그인 기능 만들어줘”라고 시키면 빠르게 뭔가를 만들어주긴 합니다. 문제는 그 “뭔가”가 내 서비스에 맞는지 알 수 없다는 점입니다. 어떤 인증 방식을 쓸지, 에러는 어떻게 보여줄지, 기존 폴더 구조는 따라야 하는지, 테스트는 필요한지 모두 비어 있기 때문입니다.
1인 빌더에게 AI 코딩의 핵심은 “많이 생성하기”보다 “덜 되돌리기”에 가깝습니다. 처음부터 완벽한 답을 기대하기보다, AI가 선택해야 할 범위를 줄여주는 방식이 보통 더 안정적입니다. 이때 프롬프트는 부탁 문장이 아니라 작은 작업 명세서가 되어야 합니다.
좋은 프롬프트는 대체로 세 가지를 포함합니다.
| 요소 | 역할 |
|---|---|
| 명세 | 무엇이 어떻게 동작해야 하는지 정의 |
| 제약 | 어떤 방식으로 구현해야 하는지 경계 설정 |
| 예시 | 입력과 출력, 성공과 실패를 구체화 |
1. 명세: “만들어줘” 대신 동작을 적는다
명세는 기능 이름이 아니라 사용자와 시스템의 행동을 설명하는 문장입니다. “북마크 기능”보다 “로그인한 사용자가 게시글을 저장하고, 저장한 게시글 목록에서 다시 확인할 수 있다”가 더 좋습니다.
명세를 쓸 때는 다음 질문을 채워보세요.
- 누가 이 기능을 쓰는가?
- 어떤 화면이나 API에서 시작되는가?
- 성공하면 무엇이 바뀌는가?
- 실패하면 사용자는 무엇을 보게 되는가?
- 기존 데이터와 어떤 관계가 있는가?
나쁜 예시는 이렇습니다.
게시글 저장 기능 만들어줘.
좋은 예시는 조금 더 길지만 훨씬 덜 위험합니다.
로그인한 사용자가 게시글 상세 페이지에서 저장 버튼을 누르면 해당 게시글이 내 저장 목록에 추가된다. 이미 저장한 게시글이면 중복 저장하지 않고, 다시 누르면 저장을 해제한다. 비로그인 사용자가 누르면 로그인 페이지로 이동시킨다.
이 정도만 적어도 AI가 임의로 “좋아요일까, 북마크일까, 장바구니일까”를 추측할 여지가 줄어듭니다.
2. 제약: AI가 건드려도 되는 범위를 정한다

AI는 요청을 해결하려고 넓게 움직이는 경향이 있습니다. 작은 버튼 하나를 고쳐달라고 했는데 라우팅 구조, 스타일 시스템, 패키지까지 바꾸는 일이 생길 수 있습니다. 그래서 제약은 “어떻게 하지 말아야 하는가”까지 포함해야 합니다.
실전에서는 아래 항목을 자주 적어두면 좋습니다.
- 사용하는 언어와 프레임워크
- 선호하는 라이브러리 또는 금지할 라이브러리
- 수정 가능한 파일 범위
- 기존 코드 스타일과 네이밍 규칙
- 테스트 추가 여부
- 성능, 접근성, 보안상 피해야 할 방식
예를 들어 이렇게 요청할 수 있습니다.
Next.js App Router와 TypeScript를 사용한다. 새 패키지는 추가하지 말고, 기존 Button 컴포넌트를 재사용한다. DB 스키마는 변경하지 않는다. 수정 범위는 app/posts/[id]와 관련 server action으로 제한한다. 에러 메시지는 기존 toast 패턴을 따른다.
제약은 AI를 괴롭히는 조건이 아니라, 나중에 사람이 리뷰해야 할 면적을 줄이는 장치입니다. 특히 운영 중인 제품이라면 “새 의존성 추가 금지”, “마이그레이션 금지”, “공개 API 응답 형태 유지” 같은 문장이 꽤 큰 사고를 막아줍니다.
3. 예시: 입출력으로 애매함을 없앤다
예시는 AI에게 가장 강한 힌트입니다. 자연어 설명이 조금 부족해도 입력과 출력 예시가 있으면 의도가 선명해집니다.
API, 파서, 변환 함수, 이메일 템플릿, 가격 계산 로직처럼 규칙이 있는 작업에는 예시를 꼭 붙이세요.
입력: "hello-world"
출력: "Hello World"
입력: "ai_prompt_guide"
출력: "Ai Prompt Guide"
예시에는 정상 케이스만 넣지 않는 편이 좋습니다. 경계 케이스를 함께 넣으면 재작업이 줄어듭니다.
- 빈 값이면 어떻게 할지
- 권한이 없으면 어떻게 할지
- 이미 존재하는 데이터면 어떻게 할지
- 너무 긴 입력이면 어떻게 자를지
- 외부 API가 실패하면 어떻게 할지
예시는 테스트 코드의 초안이 되기도 합니다. “이 입력이면 이 출력이어야 한다”가 명확하면 AI에게 바로 테스트 작성을 시킬 수 있고, 사람이 검토하기도 쉬워집니다.
바로 써먹는 프롬프트 템플릿

아래 템플릿을 복사해 작업마다 채워보세요. 처음에는 귀찮지만, 막연한 재요청을 여러 번 하는 것보다 대체로 빠릅니다.
목표:
- 무엇을 만들거나 고칠지 한 문장으로 설명
동작 명세:
- 사용자가 어떤 행동을 하면
- 시스템이 어떻게 반응하고
- 성공/실패 상태가 어떻게 달라지는지 설명
제약 조건:
- 기술 스택:
- 수정 가능한 파일:
- 새 패키지 추가 여부:
- 유지해야 할 기존 패턴:
- 하지 말아야 할 변경:
입출력/상태 예시:
- 예시 1:
- 예시 2:
- 예외 케이스:
완료 기준:
- 어떤 테스트 또는 수동 확인을 통과해야 하는지
프롬프트를 더 잘 쓰는 사람은 멋진 말을 많이 쓰는 사람이 아니라, AI가 추측해야 할 부분을 줄이는 사람입니다. 명세로 목표를 고정하고, 제약으로 작업 범위를 좁히고, 예시로 애매함을 제거하세요. 그러면 AI는 단순한 코드 생성기가 아니라, 꽤 쓸 만한 구현 파트너에 가까워집니다.
관련 글
같은 주제를 다룬 다른 글도 살펴보세요.