같은 프롬프트를 넣어도 결과가 갈리는 이유를 메이커 에반은 프롬프트 문장보다 Eval, 즉 결과를 판별하는 눈에서 찾는다. 더 강한 프롬프트를 찾아다니기보다 싫은 이유를 문장으로 쌓아 채점표 파일로 만드는 쪽이 실제 작업을 훨씬 빨리 앞으로 보낸다는 얘기다.
flowchart LR A[같은 프롬프트인데 결과물이 다르다] --> B[문제는 프롬프트보다 결과를 보는 눈이다] B --> C[싫은 이유를 문장으로 적어 Eval과 채점표를 만든다] C --> D[AI가 스스로 점검하고 고치는 루프가 빨라진다]
핵심 요약
- 같은 프롬프트를 써도 결과 차이가 나는 이유는 프롬프트보다 결과물을 판별하는 눈의 차이 때문이라고 짚는다.
- 디자이너 친구가 로고 10개를 30초 보고 3번이 제일 좋고 자간이 넓다고 말한 사례로, 먼저 필요한 것은 더 좋은 지시문이 아니라 고르는 기준이라고 설명한다.
- 프롬프트는 레시피이고 Eval은 맛보는 혀라는 비유로, 결과를 보고 좋고 별로를 말할 수 있어야 한다고 풀어낸다.
- 취향은 좋아하는 것을 먼저 찾는 게 아니라 “문장이 너무 길어”, “결론이 너무 뻔해”, “예시가 나랑 상관없어”처럼 싫은 이유를 지워 가며 선명해진다고 말한다.
- 같은 프롬프트로 결과물 3개를 뽑고 순위와 이유를 적은 뒤
eval.md같은 파일에 쌓아 AI와 함께 쓰는 3단계 루틴을 제안한다.
왜 지금 중요한가
영상에서는 AI 시대에 “만드는 건 이제 누구나 1인분”이라고 말한다. 그래서 남는 건 결국 만든 걸 고르는 능력이고, 프롬프트처럼 스크린샷 한 장으로 가져갈 수 없는 자산은 취향과 채점 기준 쪽에 더 가깝다. 개발자나 PM 입장에서도 결과 생성보다 평가 루프를 얼마나 빨리 돌리느냐가 실력 차이로 남는다는 얘기로 읽힌다.
주요 내용
프롬프트를 계속 바꾸기 전에, 왜 별로인지부터 적어야 한다
에반은 많은 사람이 “당신은 20년 경력의 전문가입니다”, “단계별로 생각하세요”, “예시를 세 개 들어 주세요” 같은 문장을 복사해 붙여 넣고도 결과가 마음에 들지 않는 경험을 한다고 말한다. 문장도 매끄럽고 구조도 깔끔한데, 좋은지 나쁜지 판단은 안 서니 다시 다른 프롬프트를 찾으러 가게 된다. 영상에서는 이 상태를 “프롬프트 맛집 순례”라고 부른다.
전환점으로 나온 사례는 AI 로고 10개다. 본인은 다 비슷해 보였는데, 디자이너 친구는 30초 만에 “3번이 제일 좋아. 근데 자간이 좀 넓어”라고 짚었다. 여기서 에반은 문제를 프롬프트가 아니라 자기 눈에서 찾는다. 열 개 중 뭐가 좋은지 모르면, 더 좋은 프롬프트도 방향 없이 쓰게 된다는 얘기다.
Eval은 결과를 고르는 기준이고, 취향은 훈련으로 쌓인다
영상은 Eval을 “평가”, 더 정확하게는 “취향”이라고 설명한다. 다만 AI 업계에서 말하는 어려운 성능 시험지가 아니라, 결과물을 보고 “이건 좋다”, “이건 별로다”라고 말할 수 있는 능력에 가깝다고 풀어낸다. 그래서 음식점 비유가 바로 이어진다. 주방장에게 레시피를 아무리 자세히 줘도 맛을 못 보면 가게가 안 굴러가듯, 프롬프트만으로는 원하는 결과에 도달하기 어렵다는 것이다.
이 취향은 타고나는 게 아니라 훈련된다고도 강조한다. 디자이너 친구가 10년 동안 로고를 만들고, 클라이언트에게 까이고, 자기가 봐도 별로여서 수천 번 지우고 버리는 동안 눈이 발전했다는 설명이 나온다. 복사 가능한 프롬프트와 달리 이런 판단 기준은 그대로 뺏기지 않는 자산이라는 점도 여기서 연결된다.
싫어하는 이유를 문장으로 만들면 루프가 돌기 시작한다
에반이 제안하는 방법은 꽤 실무적이다. 먼저 “내가 뭘 좋아하지?”보다 “이 부분이 왜 싫지?”를 한 문장으로 적으라고 말한다. 영상에 나온 예시는 세 가지다. “문장이 너무 길어”, “결론이 너무 뻔해”, “예시가 나랑 상관없어.” 이 정도만 적어도 Eval이 생기기 시작한다고 본다.
이 기준이 생기면 만들고, 판별하고, 고치고, 다시 만드는 루프가 생긴다. 농구 슛 연습 비유도 이 지점을 설명한다. 체육관 불이 켜져 있으면 100개를 던지며 100번 배울 수 있지만, 불이 꺼져 있으면 1000개를 던져도 들어갔는지조차 모른다. 그래서 영상은 프롬프트를 잘 쓰는 것보다 틀린 걸 얼마나 빨리 알아차리느냐가 더 중요하고, “루프가 도는 속도”가 실력이라고 정리한다.
채점표 파일을 AI에 같이 주면, 결과 수정이 자동화되기 시작한다
후반부의 핵심은 Eval을 머릿속 감각으로만 두지 말고 파일로 만들라는 제안이다. 싫었던 이유를 열 개쯤 모으면 그게 자기만의 채점표가 된다. 신입 직원에게 “알아서 잘해 봐”라고 말하는 대신 “이거 세 가지는 꼭 지켜 줘”라고 체크리스트를 주면 자기 결과물을 스스로 검사할 수 있는 것처럼, AI에게도 채점표를 주면 결과물을 스스로 채점하고 고칠 수 있다는 설명이다.
실행 순서는 3단계로 제시된다. 첫째, 같은 프롬프트로 결과물 3개를 뽑는다. 둘째, 1등·2등·3등을 정하고 “3등이 별로인 이유는 뭐뭐 때문이다”를 한 문장으로 적는다. 셋째, 그 이유를 eval.md 같은 파일에 쌓는다. 영상에서는 이런 문장이 열 줄만 쌓여도 그 파일을 AI와 함께 넣어 쓸 수 있다고 말하고, 다른 사람이 쌓아둔 채점표를 보는 것도 자기 취향을 찾는 데 도움이 된다고 덧붙인다.
원문 발화 하이라이트
- [01:18] “제 문제는 프롬프트가 아니었어요. 제 눈이 문제였어요.”
- [01:50] “레시피가 프롬프트예요. 맛보는 혀가 이벨이고요.”
- [02:05] “프롬프트는요. 복사 붙여 넣기 3초면 끝나요.”
- [03:29] “싫어하는 걸 하나씩 지워 나가는 거예요. 그러다 보면 남는 게 취향이에요.”
- [04:18] “루프가 도는 속도가 실력이에요.”
바로 실행해 보기
- 같은 프롬프트를 한 번만 돌리지 말고 결과물 3개를 먼저 뽑는다. 영상에서 말한 것처럼 비교할 게 있어야 좋은지 나쁜지 판단 기준이 생긴다.
- 3개 결과물에 1등, 2등, 3등을 매긴 다음 “3등이 별로인 이유는 뭐뭐 때문이다”를 한 문장으로 적는다. 시작은 영상 예시처럼 “문장이 너무 길어”, “결론이 너무 뻔해”, “예시가 나랑 상관없어” 정도면 충분하다.
- 메모장에
eval.md같은 파일을 만들고 그 문장들을 계속 쌓는다. 기준이 열 줄쯤 모이면 다음 작업부터는 프롬프트와 함께 그 파일도 같이 넣어 AI가 스스로 채점하고 고치게 해 본다.
참고
영상 메타
- 채널: 메이커 에반 | Maker Evan
- 제목: 프롬프트 아무리 잘 써도 결과물이 안 좋은 진짜 이유
- 게시 시각(원문): 2026-07-10T07:05:06+00:00
- 영상: https://www.youtube.com/watch?v=23XTmVJYiGk
- 썸네일: https://i3.ytimg.com/vi/23XTmVJYiGk/hqdefault.jpg
수집 품질
- 자막 세그먼트: 215개
- 자막 문자수: 3852자
- 챕터 추출: 16개
- 콘텐츠 생성: Subagent 기반
AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.
