본문 바로가기
메이커로그

AI 프롬프트 잘 쓰는 사람 vs 못 쓰는 사람의 차이

by 고니누나 2026. 4. 27.
728x90
반응형

같은 AI를 쓰는데 누군가는 "이거 진짜 쓸 만하다"고 하고, 누군가는 "AI가 별로네"라고 한다.

AI가 다른 게 아니다. 프롬프트가 다른 거다.

 

프롬프트는 AI에게 보내는 지시문이다. 지시가 명확하면 결과가 좋고, 지시가 흐리면 결과도 흐리다. 당연한 말 같지만, 실제로 이 차이를 만드는 구체적인 습관은 따로 있다.

 

잘 쓰는 사람과 못 쓰는 사람의 차이를 하나씩 짚어봤다.

 

차이 1. 맥락을 주는가, 안 주는가

못 쓰는 사람:

"랜딩페이지 카피 써줘"

 

잘 쓰는 사람:

"내가 만드는 서비스는 프리랜서 개발자를 위해 견적서를 자동으로 만들어주는 웹앱이야. 타겟은 매달 3~5개 프로젝트를 받는 1인 개발자고, 가장 큰 페인포인트는 견적서 만드는 데 시간이 너무 오래 걸린다는 거야. 이 서비스의 랜딩페이지 히어로 섹션 카피를 써줘. 톤은 친근하고 간결하게."

 

AI는 맥락이 없으면 평균을 낸다. 맥락이 있으면 그 상황에 맞는 답을 낸다. 평균적인 랜딩페이지 카피와 내 서비스에 딱 맞는 카피는 완전히 다르다.

 

습관: 요청 전에 "AI가 나에 대해 뭘 알아야 좋은 답을 줄 수 있을까?"를 먼저 생각해보자.

 

차이 2. 역할을 부여하는가, 안 하는가

못 쓰는 사람:

"이 코드 리뷰해줘"

 

잘 쓰는 사람:

"너는 10년 경력의 시니어 백엔드 개발자야. 주니어 개발자가 작성한 코드를 리뷰하듯이, 개선할 점과 이유를 함께 설명해줘. 코드: [코드 붙여넣기]"

 

역할을 부여하면 AI의 응답 방식이 바뀐다. "시니어 개발자"라는 페르소나를 주면 단순히 버그를 찾는 게 아니라 설계 관점, 유지보수 관점까지 같이 봐준다.

 

역할 부여가 효과적인 상황:

  • 코드 리뷰 → "시니어 개발자"
  • 카피라이팅 → "전환율 전문 카피라이터"
  • 사업 피드백 → "냉정한 투자자"
  • 글 교정 → "독자 입장의 편집자"

습관: 요청 앞에 "너는 ~야"를 붙이는 것만으로 결과가 달라진다.

 

차이 3. 출력 형식을 지정하는가, 안 하는가

못 쓰는 사람:

"이 서비스의 기능을 정리해줘"

 

잘 쓰는 사람:

"이 서비스의 핵심 기능 5가지를 정리해줘. 형식은 이렇게 해줘: 기능명 (한 줄 설명) / 사용자 이점 한 문장. 마크다운 테이블로."

 

원하는 형식을 말하지 않으면 AI는 자기가 편한 형식으로 준다. 그걸 다시 원하는 형태로 가공하는 데 시간이 든다. 처음부터 쓸 수 있는 형태로 달라고 하자.

 

지정할 수 있는 것들:

  • 길이: "3줄로", "500자 이내로", "10개 항목으로"
  • 형식: "테이블로", "번호 목록으로", "마크다운으로"
  • 구조: "결론 먼저, 이유 나중에"
  • 톤: "격식체로", "친근하게", "전문적으로"

습관: 요청 끝에 "형식은 ~으로 해줘"를 항상 붙여보자

 

차이 4. 한 번에 다 요청하는가, 단계별로 나누는가

못 쓰는 사람:

"내 사이드프로젝트 기획부터 랜딩페이지 카피, 기술 스택 추천, 개발 태스크 목록까지 다 만들어줘"

 

잘 쓰는 사람:

1단계: "서비스 정의서 먼저 만들어줘"

2단계: (결과 확인 후) "이 정의서 기반으로 기술 스택 추천해줘"

3단계: (확정 후) "이 스택으로 개발 태스크 목록 뽑아줘"

 

한 번에 너무 많이 요청하면 AI는 각 항목을 얕게 처리한다. 단계를 나누면 각 단계에서 집중도가 올라가고, 중간에 방향을 수정할 수 있다. 이전 단계 결과를 다음 요청에 붙여넣으면 일관성이 생긴다. "위 정의서를 기반으로"라는 한 줄이 전체 결과물의 통일성을 만든다.

 

습관: 큰 요청은 3단계 이상으로 쪼개자. 각 단계 결과를 확인하고 다음으로 넘어가자.

 

차이 5. 피드백을 주는가, 새로 시작하는가

못 쓰는 사람: 

결과가 마음에 안 들면 → 새 대화 창 열고 처음부터 다시 요청

 

잘 쓰는 사람:

"좋은데 두 가지만 수정해줘. 첫째, 톤이 너무 딱딱해. 좀 더 친근하게. 둘째, 세 번째 항목은 타겟 고객 관점에서 다시 써줘."

 

결과를 버리고 새로 시작하면 좋은 부분도 같이 버린다. AI와의 대화는 조각을 다듬는 과정이다. 마음에 드는 부분은 유지하고, 안 드는 부분만 구체적으로 지적해라.

 

구체적인 피드백의 구조:

  • 좋은 것: "~는 좋아"
  • 바꿀 것: "~는 ~하게 바꿔줘"
  • 이유: "왜냐하면 ~이기 때문이야"

이유를 붙이면 AI가 다음 수정에서 같은 실수를 반복하지 않는다.

 

습관: "다시 써줘" 대신 "이 부분만 이렇게 바꿔줘"라고 해보자.

 

차이 6. 검증을 요청하는가, 그냥 받아쓰는가

못 쓰는 사람: 

AI가 준 코드를 바로 붙여넣는다.

 

잘 쓰는 사람:

"이 코드에서 잠재적인 버그나 엣지 케이스가 있으면 말해줘" "이 기획에서 내가 놓친 게 있으면 지적해줘" "반대 의견도 있어? 이 방향의 단점은 뭐야?"

 

AI는 요청한 것을 준다. 검증을 요청하지 않으면 검증해주지 않는다. 결과물을 받은 다음 "이거 문제 없어?"라고 한 번 더 물어보는 습관이 품질을 크게 올린다. 특히 코드는 동작한다고 끝이 아니다. "이 코드 보안 문제 있어?", "성능 개선할 수 있어?", "더 읽기 쉽게 리팩토링하면?"을 추가로 물어보자.

 

습관: 결과물을 받으면 "이거 문제없어?"를 항상 한 번 더 물어보자.

 

 

프롬프트 템플릿 — 바로 쓸 수 있는 구조

아래 구조를 복사해서 쓰면 된다.

[역할]
너는 [전문가 유형]이야.

[맥락]
내 상황은 이래: [서비스/프로젝트/상황 설명]
타겟은: [구체적인 사용자]
목표는: [이 요청으로 얻고 싶은 것]

[요청]
[구체적인 요청 내용]

[형식]
결과물 형식: [마크다운/테이블/번호 목록 등]
길이: [간결하게/상세하게/몇 줄로]
톤: [친근하게/전문적으로/직접적으로]

 

처음엔 번거롭게 느껴지지만, 이 구조에 익숙해지면 첫 번째 결과물부터 쓸 수 있는 수준으로 나온다.


 

프롬프트 실력은 AI 실력이 아니라 커뮤니케이션 실력에 가깝다.

명확하게 말하는 사람이 좋은 결과를 얻는다. 맥락 없이 짧게 던지면 AI도 짧게 돌려준다. 구체적으로 원하는 걸 말하면 AI도 구체적으로 준다. 

 

 

[함께보면 좋은글]

2026.04.21 - [메이커로그] - 클로드 vs ChatGPT, 개발할 때 뭐가 다를까? - 둘 다 써본 1인 개발자의 솔직한 비교

 

2026.04.21 - [메이커로그] - AI 시대의 1인 개발, 코딩보다 기획이 먼저다

 

728x90
반응형