완벽한 프롬프트를 먼저 쓰려다 멈춰 서기보다, AI와의 ‘벽타기’로 판단 기준을 만들고 결과에서 역으로 프롬프트를 추출·검증하는 사고 설계를 다룬 글.
URL: https://zenn.dev/recurrenthub/articles/1e0e30f7037dd9
Title: 해상도가 낮은데, 프롬프트 같은 걸 쓸 수 있을 리가 없다.
「그 프롬프트, 어떻게 만든 거예요？」
AI를 써서 아웃풋을 내고 있으면, 이런 질문을 받는 일이 있습니다. 마치 손에 ‘마법의 주문’이 적힌 두루마리가 있는 것처럼.
하지만 제 대답은 언제나 상대를 당황하게 만듭니다.
「프롬프트? 안 만들어요. 벽타기(벽에 대고 치듯이 대화)해서 결과가 나오면, 그걸 AI가 재현하도록 프롬프트를 역으로 생성하게 할 뿐이죠」
많은 사람은 이 ‘순서’가 반대입니다. 처음부터 완벽한 지시서(프롬프트)를 쓰려다 화면 앞에서 얼어붙습니다. 혹은 대충 지시를 던지고, 나온 평범한 답변을 보고 ‘AI는 이 정도인가’ 하며 실망합니다.
내 안에 답이 없는데, AI가 한 방에 원하는 답을 내줄 리가 없습니다.
이건 프롬프트의 기술론이 아닙니다. ‘사고의 설계’에 대한 이야기입니다.
왜 우리는 ‘한 번에 정답을 내려고’ 할까요? 그건 오랫동안 몸에 밴 ‘검색 엔진’의 습관이 빠지지 않았기 때문입니다. 검색창에 키워드를 넣으면 정답 페이지가 나온다. 우리는 AI에게도 이 ‘자동판매기’를 기대합니다.
하지만 생성형 AI는 검색 엔진이 아닙니다. 당신이 ‘무엇을 만들고 싶은지’의 해상도가 낮으면, AI는 가장 무난하고, 가장 지루한 ‘80점짜리 평균답’만 돌려줄 수밖에 없습니다.
일의 ‘조건’이나 ‘제약’(타깃, 글자 수, 톤)은 손에 쥐고 있습니다. 일반적인 프롬프트 해설서는 이 ‘상자 만드는 법’만 가르칩니다. 하지만 현장에서 진짜 괴로운 건, 「상자의 치수는 완벽한데, 내용물의 정답이 보이지 않는다」 는 상황입니다.
왜일까요? 당신 안에 「무엇을 ‘좋은 느낌’이라고 할지에 대한 판단 기준이 아직 존재하지 않기 때문」 입니다.
그리고 그건 부끄러운 일이 전혀 아닙니다. 아직 발견되지 않았을 뿐입니다.
그럼 판단 기준이 없는 상태에서 어떻게 해야 할까요? 답은 단순합니다. ‘답을 찾는 여행’ 을 떠날 수밖에 없습니다. 그게 ‘벽타기’입니다.
처음부터 홈런을 노릴 필요는 없습니다. 우선 배트를 휘두르는 겁니다. 내 머릿속에 있는 미완성이고 모순투성이인 생각을 그대로 AI에 부딪칩니다.
「지금 이런 기획을 생각 중인데,
뭔가 임팩트가 부족한 것 같아. 어떻게 생각해?」
「타깃을 A로 좁히고 싶지만 B의 요소도 버리기 아까워.
둘을 양립시키는 안이 있을까?」
당연히 첫 답변은 엇나갈 수도 있습니다. 하지만 그게 괜찮습니다. AI가 돌려준 ‘빗나간 답’ 자체가 당신의 사고를 갈기 위한 ‘숫돌’이 되기 때문입니다.
실제 벽타기를 봅시다. 사내 대상 AI 활용 세미나 기획을 고민하고 있다고 하겠습니다.
턴 1: 대충 던지기
당신：「사내에서 AI 활용 세미나를 하고 싶어.
뭔가 좋은 기획이 안 나올까?」
AI：「AI 활용 세미나 기획안입니다.
・ChatGPT 기본 조작을 배우는 핸즈온
・프롬프트 템플릿 배포
・업무 효율화 사례 소개…」
→ 나온 건 어느 회사나 하는 ‘입문 세미나’. 틀리진 않지만 재미도 없습니다.
턴 2: 위화감을 부딪치기
당신：「음… 그건 너무 평범해.
우리 회사는 AI 도입에 회의적인 베테랑 직원이 많거든.
그런 사람들이 ‘오, 재밌을지도’라고 생각할 만한 관점이 필요해」
→ 여기서 처음으로 ‘베테랑 직원’, ‘회의적’, ‘재밌을지도’라는 키워드가 나왔습니다. 처음부터 내 안에 명확히 있었던 게 아닙니다. AI의 무난한 답을 보고 ‘그게 아닌데’ 라고 느꼈기 때문에 나온 겁니다.
턴 3: 방향이 잡힌다
AI：「회의적인 베테랑층이 타깃이라면, 이런 관점은 어떨까요.
『AI에게 당신의 일을 빼앗게 해보자 챔피언십』
각 부서 베테랑이 자신의 업무를 AI에게 시켜보며,
AI가 할 수 있는 것/없는 것을 체감하는 워크숍 형태…」
당신：「아, 그거 재밌다. ‘빼앗게 해보자’라는 말이 도발적이라 좋네.
다만 톤은 조금 더 안심되는 느낌으로 하고 싶어.
‘빼앗길 공포’가 아니라 ‘내 강점이 보이는’ 방향으로」
→ 3턴째에 기획의 방향성이 명확해졌습니다. 처음 화면 앞에서 ‘완벽한 기획서’를 쓰려 했다면, 이 착지점엔 영원히 도달하지 못했을 겁니다.
AI 답변을 보는 순간, 당신은 이렇게 생각할 겁니다.
「아니, 그게 아닌데」
이 ‘그게 아닌데’가 벽타기의 핵심 포인트입니다. 다만 ‘그게 아닌데’로만 두면 앞으로 나갈 수 없습니다. 이걸 분해해야 합니다.
분해의 요령은 ‘무엇이’ ‘어떻게’ 다른지, 대비로 생각하는 것 입니다. 어렵게 생각할 필요 없습니다. AI 답변을 보면서 이렇게 자문하는 것만으로 충분합니다.
완벽한 언어화가 아니어도 됩니다. “너무 논리적이야. 더 점프하는 아이디어가 필요해” 이 정도면 충분합니다. AI는 이 애매한 피드백만으로도 놀랄 만큼 정확하게 방향을 수정해 옵니다.
여기까지 읽고 “아니, 그 ‘그게 아닌데’조차 안 나오는데”라고 생각한 분도 있을 겁니다. AI 답변을 읽어도 좋은지 나쁜지 판단이 안 서요. “뭐, 이 정도겠지” 하고 받아들여 버립니다.
그 감각은 정상입니다. 답변 하나만 보고 좋고 나쁨을 판단하는 건 프로도 어렵습니다.
그럴 때는 AI에게 자기 답변을 비판하게 하면 됩니다.
「지금 답변의 약점은 어디야?」
「이걸 읽은 클라이언트가 부족하다고 느낀다면 어느 부분일까?」
「이 기획서에서 가장 태클이 들어올 포인트는?」
AI의 자기비평을 읽는 순간 “아, 맞아 거기가 걸렸어”, “말하니 그렇네, 여기가 얇다”라고 깨닫습니다. 내 안에 흐릿하게 있던 위화감이 AI의 말로 윤곽을 갖는 겁니다.
즉, 벽타기란 ‘혼자서 언어화해야만 하는’ 게 아닙니다. 언어화조차 AI에게 도와달라고 해도 됩니다. 당신이 할 일은 AI가 지적한 약점 중에서 “맞다”와 “아니, 그건 괜찮다”를 가르는 것뿐입니다. 그게 ‘판단’이고, 그게 바로 인간의 일입니다.
이 순간이야말로 내 안에 잠들어 있던 ‘판단 기준’이 윤곽을 드러내는 순간입니다. 아무것도 없는 상태에서 ‘정답’을 그리기는 어렵습니다. 하지만 눈앞에 제시된 ‘오답’에 대해 “여기가 다르다”라고 지적하는 건 훨씬 쉽습니다.
인간은 ‘쓰기(생성)’보다 ‘고르기(판단)’에 압도적으로 더 능숙하니까요.
벽타기의 본질은 답을 내게 하는 것이 아닙니다. ‘그 답을 끌어내기 위한 질문’을 발견하는 것 에 있습니다.
당신이 “더 감정적으로!”라고 수정 지시를 내리고서야 만족스러운 답이 나왔다고 해봅시다. 그건 즉 “감정적으로”라는 지시가 이 케이스에서 정답으로 가는 열쇠였다는 뜻입니다.
많은 사람은 이 시행착오를 “AI가 쓸모없어서 시간이 걸렸다”고 한탄합니다. 하지만 그건 다릅니다. 당신은 그때 AI라는 벽을 이용해 ‘어떻게 물어야 이 문제가 풀리는가’ 라는 실험을 하고 있던 겁니다.
그리고 납득할 만한 답이 나왔을 때, 그 자리에 자동으로 ‘정답의 질문’ 재료도 갖춰집니다. 여기서 처음으로 AI에게 이렇게 명령합니다.
「지금 대화의 주고받음을 바탕으로, 이 최고의 아웃풋을
만들어내는 데 필요했던 ‘조건’과 ‘지시’를 분석해.
그리고 다음부터 한 번에 이걸 재현할 수 있는 프롬프트를 써줘」
이게 리버스 프롬프트 엔지니어링(역생성) 입니다.
앞의 세미나 기획 예시로 이어가 봅시다. 벽타기 끝에 “베테랑 직원이 자기 업무를 AI에게 시켜 보며 자기 강점을 재발견하는 워크숍”이라는 방향이 굳어졌다고 합시다. 여기서 AI에게 이렇게 의뢰합니다.
「지금 대화의 주고받음을 되돌아보고,
이 기획안에 도달하기 위해 필요했던 ‘조건’과 ‘지시’를 분석해.
다음에 다른 주제에서도 같은 퀄리티의 기획을 한 번에 뽑을 수 있는 프롬프트를 써줘」
그러면 AI는 이런 프롬프트를 생성합니다.
【AI가 역생성한 프롬프트 예시】
당신은 사내 연수 기획 담당자입니다. 아래 조건으로 기획안을 작성하세요.
・타깃: AI 도입에 회의적인 층(구체적 속성을 기재)
・톤: 도발적이되 안심감을 주는 표현. 공포가 아니라 ‘발견’을 축으로
・형식: 강의형이 아니라 체험형 워크숍
・목표: 참가자가 “AI가 못 하는 것 = 내 강점”을 실감할 수 있는 구성
・기획 제목은 타깃이 무심코 반응할 만한 캐치한 표현으로
이 프롬프트를 보면, 벽타기 중에 내가 무의식적으로 내놓고 있던 조건—‘회의적인 층’, ‘도발적이되 안심감’, ‘체험형’, ‘내 강점이 보인다’—이 전부 언어화되어 있습니다. 혼자서는 못 썼던 설계도가 대화의 발자국으로부터 자동으로 태어난 겁니다.
혼자 끙끙대며 쓴 프롬프트보다, AI와 씨름한 끝에 나온 ‘검증된 프롬프트’가 압도적으로 정확도가 높은 건 당연합니다.
프롬프트는 처음에 쓰는 ‘설계도’가 아닙니다. 헤매고, 벽에 부딪치며 골에 도달한 뒤에 남는 사고의 ‘발자국’ 입니다.
다만 여기서 한 가지 주의점이 있습니다. 역생성된 프롬프트가 한 번에 완벽히 작동하리라는 보장은 없습니다.
왜일까요? AI가 만든 프롬프트는 당신과의 대화 ‘문맥’에 의존하는 부분을 포함하는 경우가 많기 때문입니다. 대화 흐름 속에서는 자연스럽던 지시가, 프롬프트 단독으로는 의미가 안 통하거나 중요한 뉘앙스가 빠져 있을 수 있습니다.
그래서 역생성한 프롬프트는 반드시 ‘새 대화’에서 테스트 합니다. 같은 주제로, 제로에서 그 프롬프트만 던져 보는 겁니다.
테스트 결과 확인 포인트:
- 벽타기로 얻었던 ‘그 답변’과 동급의 품질이 나오는가?
- 의도치 않은 엇나감이 생기지 않았는가?
- 다른 주제나 소재에 적용해도 작동하는가?
엇나가면 이렇게 수정을 요청합니다.
「이 프롬프트로 해보니 ○○ 부분이 엇나갔어.
원래 대화에서는 잘 됐는데, 여기 재현이 안 된다.
원인을 분석해서 프롬프트를 수정해줘」
이 사이클을 2~3번만 반복해도 프롬프트의 정밀도는 극적으로 올라갑니다.
정리하면, 역생성의 올바른 플로우는 이렇습니다.
‘역생성하고 끝’이 아닙니다. ‘역생성 → 테스트 → 수정’의 루프를 돌릴 때 비로소 실전에 쓰는 프롬프트가 손에 들어옵니다.
여기까지는 ‘답이 없는’ 경우의 이야기였습니다. 반대로, 당신 손에 ‘명확한 이상형’이 이미 있는 경우는 어떨까요?
예를 들어 과거에 내가 쓴 완벽한 이메일이나, 이상적인 구성의 자료가 있는 경우입니다. 이때야말로 인간의 ‘언어화 능력’ 한계를 넘을 기회입니다.
“더 정중하게”, “비즈니스라이크하게” 같은 애매한 형용사를 늘어놓을 필요가 없습니다. 해야 할 일은 ‘소재(인풋)’와 ‘완성품(아웃풋)’을 둘 다 AI에게 보여 주는 것뿐입니다.
구체 예로 봅시다. 미팅 후 급히 적은 메모와, 그걸 바탕으로 쓴 보고 메일이 있다고 합시다.
인풋(휘갈겨 쓴 메모):
・A사 다음 주 금요일 방문 확정
・상대방 다나카 부장 동석
・견적 재제출, 전번보다 15% 낮춘 금액으로
・납기는 협의 필요, 3월 말은 어려울지도
아웃풋(실제로 보낸 보고 메일):
수고하십니다. A사 건, 진행 상황을 공유드립니다.
다음 주 금요일(2/21)에 A사를 방문하기로 결정되었습니다.
상대 측에서는 다나카 부장도 동석할 예정이라고 연락을 받았습니다.
견적은 이전 제시 금액에서 15% 인하한 금액으로 재제출하는 방향입니다.
또한 납기는 상대 측과 3월 말 이후로 재조정이 필요할 가능성이 있어,
방문 시 상세를 조율할 예정입니다.
사전에 확인할 사항이 있으면 알려주세요.
이 두 가지를 AI에 넘기고 이렇게 의뢰합니다.
「위는 원래 메모, 아래는 그걸 바탕으로 내가 쓴 보고 메일이야.
이 둘을 비교 분석해서, 내가 어떤 규칙으로
메모를 메일로 변환하고 있는지
그 ‘변환 로직’을 프롬프트로 정의해줘」
그러면 AI는 당신이 무의식적으로 하던 일을 언어화해 줍니다. 예컨대 “불릿의 사실을 시간순으로 재구성한다”, “불확실한 정보에는 ‘가능성이 있다’처럼 헤지를 넣는다”, “마지막에 상대에게 행동을 촉구하는 한 문장을 덧붙인다” 같은 식입니다.
당신 자신은 “그냥 늘 이렇게 쓰는데” 정도로만 생각했을 겁니다. 하지만 AI에게 분석시키면 그 ‘그냥’이 재현 가능한 규칙으로 바뀝니다.
이건 속이 안 보이는 상자를 분석하는 것과 같습니다. 사과를 넣었더니 애플파이가 나왔다면, 상자 안에는 “껍질을 벗기고, 졸이고, 굽는다” 같은 기능이 있을 겁니다.
인간이 그 절차를 잘 설명하지 못하더라도, AI는 인풋과 아웃풋의 차이에서 인간이 무의식적으로 수행하는 ‘암묵지’나 ‘나만의 규칙’을 자동으로 추출해 줍니다.
‘답이 있는’ 패턴은 실무에서 놀랄 만큼 자주 등장합니다.
공통점은 ‘내가 잘 설명은 못 하지만, 좋은 예와 나쁜 예는 구분할 수 있다’ 는 상황입니다. 그 구분을 AI에 언어화시키는 것. 그거 하나로 당신의 암묵지는 재사용 가능한 자산으로 바뀝니다.
이 두 가지 스위치만 구분해 쓰면, 당신이 제로부터 프롬프트를 쓸 필요는 없어집니다.
“프롬프트를 못 쓰겠다”고 고민하고 있다면, 그건 당신의 능력 부족이 아닙니다. 당신이 ‘아직 보지 못한 새로운 답’ 을 찾고 있다는 증거입니다.
답을 모르는데 정확한 지도를 쓸 수 있을 리가 없습니다. 그러니 쓰려고 하지 않아도 됩니다. 먼저 AI라는 광대한 황야에, 빈손으로 발을 들여 보세요.
“뭔가 다른데”, “이렇게 더 해줘”라고, 투박하게 대화를 거듭해 가는 것. 그 방황 끝에 반드시 “이거다!” 싶은 풍경을 찾게 됩니다.
지도(프롬프트) 같은 건 그곳에 깃발을 꽂은 다음에 AI에게 그리게 하면 됩니다. 그리고 그 지도가 맞는지, 다시 한 번 걸어 확인하면 됩니다.
「내 안에 답이 없다」
그 사실을 인정하는 순간부터, 진정한 의미의 AI와의 공창(공동 창작)이 시작됩니다.
이 글은 “프롬프트의 틀을 배우지 말라”는 이야기가 아닙니다. 오히려 프롬프트의 틀이나 데모 프롬프트를 배우는 건 매우 중요합니다.
훌륭한 프롬프트 구조(역할 지정, 제약 조건, 출력 포맷 등)를 알고 있으면, 벽타기의 시행착오도 훨씬 빨라집니다. 틀을 알고 있기에 “아, 여기에 컨텍스트를 더하면 정확도가 올라가겠네”라고 알아차릴 수 있는 겁니다.
다만, 틀을 100개 외워도 “내가 무엇을 원하는가”의 해상도가 낮으면 그 틀을 능숙히 쓰지 못합니다. 틀은 ‘도구’입니다. 도구 사용법을 알아도 “무엇을 만들고 싶은지”가 보이지 않으면 도구는 무용지물이 됩니다.
그래서 둘 다 필요합니다.
이 글에서 전하고 싶었던 건 “틀을 배워도 막힐 때는, 벽타기로 내 해상도를 올리는 것부터 시작하자”는 것입니다. 그리고 그 벽타기의 결과를 역생성시키면, 틀 학습으로 얻은 지식이 당신 전용으로 커스터마이즈된 실전형 프롬프트로 승화됩니다.