2부 9장. 프롬프트를 고치는 방법

프롬프트를 처음부터 완벽하게 쓰려는 사람은 자주 지칩니다. 한 문장을 몇 번씩 갈아엎고, 표현을 바꾸고, 강조 표시를 넣고, 길이를 늘려 보지만 결과는 생각만큼 좋아지지 않습니다. 그러면 이렇게 느끼기 쉽습니다. "나는 프롬프트에 소질이 없나 보다."

하지만 실전에서 잘하는 사람은 처음부터 완성형 프롬프트를 쓰는 사람이 아닙니다. 결과를 보고, 문제를 짚고, 한 번에 하나씩 고쳐 가는 사람입니다.

이 차이는 꽤 큽니다. 전자는 프롬프트를 한 번의 글짓기로 봅니다. 후자는 프롬프트를 초안이라고 봅니다. 초안은 고치는 것이 당연합니다. 보고서 초안도 첫 버전이 완벽하지 않고, 발표 자료도 한 번에 끝나지 않듯, 프롬프트도 마찬가지입니다.

앞 장에서는 실패하는 프롬프트의 공통점을 살펴보았습니다. 이제는 한 걸음 더 나아가야 합니다. 실패 원인을 아는 것만으로는 부족합니다. 그 원인을 실제 수정으로 연결하는 손놀림이 필요합니다.

이 장의 목표는 분명합니다. 당신이 프롬프트를 "작성"하는 사람에서, 프롬프트를 "개선"하는 사람으로 바뀌게 만드는 것입니다.

프롬프트는 작품이 아니라 작업 지시문이다

많은 초보자는 프롬프트를 멋지게 써야 한다고 생각합니다. 정교한 표현, 강한 어조, 길고 풍부한 설명이 필요하다고 믿습니다. 물론 그런 요소가 도움이 될 때도 있습니다. 하지만 대부분의 경우 더 중요한 것은 문장의 화려함이 아니라 작업의 선명함입니다.

프롬프트가 잘 안 될 때 문장을 더 멋있게 바꾸는 것부터 시작하면, 자주 엉뚱한 방향으로 갑니다. 예를 들어 결과가 산만하다고 해서 "아주 아주 명확하게 써줘"를 덧붙이는 것은 수정이 아니라 주문에 가깝습니다. 무엇이 산만했는지, 어떤 기준으로 정리되어야 하는지 드러나지 않기 때문입니다.

프롬프트를 고친다는 것은 문장을 예쁘게 다듬는 일이 아닙니다. AI가 헷갈린 지점을 찾아서, 그 부분의 구조를 바로잡는 일입니다. 그러니 프롬프트를 대할 때는 이렇게 생각하는 편이 좋습니다.

"이 문장이 멋진가?"보다 "이 지시가 실행 가능한가?"

이 질문 하나만으로 수정의 방향이 달라집니다.

먼저 할 일: 결과를 보고 바로 다시 쓰지 말 것

프롬프트가 기대와 다르게 나왔을 때 사람들은 대개 반사적으로 다시 씁니다. 표현을 바꾸고, 한두 줄을 더하고, 강조 문구를 붙입니다. 그런데 이 방식은 의외로 비효율적입니다. 왜냐하면 무엇이 문제인지 확인하지 않은 채 수정부터 하기 때문입니다.

결과가 마음에 들지 않을 때는 먼저 증상을 말로 붙잡아야 합니다. 예를 들면 이런 식입니다.

• 너무 일반적이다.

• 내가 원하는 독자 수준과 맞지 않는다.

• 빠지면 안 되는 정보가 빠졌다.

• 길이는 맞는데 구조가 마음에 들지 않는다.

• 문체는 괜찮은데 근거가 약하다.

이렇게 증상을 붙잡아야 다음 질문이 가능합니다. "왜 그렇게 되었지?"

이 과정을 건너뛰면 수정이 감에 의존하게 됩니다. 프롬프트 실력은 감으로 쌓이지 않습니다. 관찰과 수정의 연결로 쌓입니다.

프롬프트 수정의 기본 원칙: 한 번에 하나만 바꿔라

프롬프트를 고칠 때 가장 흔한 실수는 여러 문제를 한꺼번에 고치는 것입니다. 모호한 표현도 바꾸고, 형식도 추가하고, 예시도 넣고, 길이 제한도 조정하고, 역할도 새로 주는 식입니다.

이렇게 하면 결과가 좋아져도 무엇이 효과가 있었는지 알기 어렵습니다. 반대로 나빠져도 어느 수정이 문제였는지 알 수 없습니다. 결국 배움이 남지 않습니다.

실전에서는 한 번에 하나의 가설만 검증하는 방식이 훨씬 강력합니다.

예를 들어 결과가 너무 두루뭉술했다면, 첫 번째 수정은 모호한 목표를 구체화하는 데만 씁니다. 그다음에도 부족하면 독자를 추가합니다. 그래도 아쉬우면 출력 형식을 지정합니다. 이런 식으로 차례로 바꾸면, 어떤 수정이 품질에 영향을 주는지 감이 생깁니다.

이 방법은 느려 보이지만, 장기적으로는 훨씬 빠릅니다. 한 번씩 정확하게 고치는 편이, 매번 처음부터 뒤엉킨 프롬프트를 만드는 것보다 낫기 때문입니다.

가장 실용적인 수정 루프

프롬프트를 고치는 데 특별한 재능은 필요하지 않습니다. 대신 반복 가능한 순서가 필요합니다. 다음 루프는 거의 모든 작업에 적용할 수 있습니다.

• 먼저 내가 기대한 결과를 한 문장으로 적는다.

• 실제 출력에서 무엇이 어긋났는지 표시한다.

• 원인을 하나만 고른다. 모호함인지, 정보 부족인지, 작업 과잉인지, 기준 부재인지 판단한다.

• 그 원인에 맞는 수정 한 가지를 적용한다.

• 다시 실행하고, 무엇이 나아졌는지 비교한다.

이 다섯 단계의 핵심은 간단합니다. 문제 하나, 수정 하나, 비교 하나입니다.

많은 사람이 여기서 놓치는 것이 있습니다. 바로 비교입니다. 프롬프트를 고쳤다면 이전 결과와 지금 결과를 나란히 보아야 합니다. 그래야 수정이 실제로 도움이 되었는지 알 수 있습니다. 막연히 "이번 게 좀 더 낫네" 수준으로 넘어가면 다음에도 같은 시행착오를 반복하게 됩니다.

어떤 문제를 어떻게 고칠 것인가

이제 구체적으로 보겠습니다. 결과가 이상할 때는 대개 몇 가지 대표적인 수정 방향으로 갈 수 있습니다.

목표가 흐리면, 목표를 줄이고 선명하게 만든다

예를 들어 이런 프롬프트가 있다고 해 봅시다.

이 주제로 글을 잘 정리해줘.

이 요청은 너무 넓습니다. 무엇을, 누구에게, 어떤 용도로 정리해야 하는지 보이지 않습니다. 이럴 때는 목표를 더 멋지게 쓰는 것이 아니라 더 좁게 써야 합니다.

예를 들면 이렇게 바꿀 수 있습니다.

AI 컨텍스트 엔지니어링을 처음 듣는 직장인을 대상으로, 800자 안에서 핵심 개념만 설명해줘. 정의보다 실무에서 왜 중요한지 먼저 말해줘.

이 수정의 핵심은 문장을 길게 만든 것이 아닙니다. 목표의 해상도를 높인 것입니다. 대상, 길이, 우선순위가 생기자 AI가 추측해야 할 빈칸이 줄어듭니다.

작업이 너무 많으면, 한 프롬프트를 여러 단계로 나눈다

다음 같은 요청은 자주 실패합니다.

이 인터뷰 내용을 읽고 요약하고, 인사이트를 뽑고, 기사 초안을 쓰고, 제목도 10개 만들어줘.

이 프롬프트는 AI가 못해서가 아니라, 일이 한 덩어리로 뭉쳐 있어서 흔들립니다. 이럴 때는 한 문장을 더 보태는 대신 작업을 분리해야 합니다.

첫 턴에서는 이렇게 묻습니다.

인터뷰에서 반복해서 등장하는 핵심 주장 3가지만 뽑아줘.

두 번째 턴에서는 이렇게 갑니다.

방금 뽑은 3가지 주장 각각에 대해 독자가 흥미를 느낄 만한 포인트를 한 문장씩 붙여줘.

세 번째 턴에서야 기사 초안을 요청합니다.

이 방식의 장점은 단지 품질 향상만이 아닙니다. 중간에 방향이 틀어지면 그 자리에서 바로잡을 수 있습니다. 한 번에 끝내려 할수록 오히려 멀리 돌아갑니다.

중요한 정보가 빠졌다면, 입력을 보강한다

프롬프트를 고칠 때 많은 사람이 출력 문장만 손봅니다. 하지만 실제 문제는 입력 부족인 경우가 많습니다.

예를 들어 이런 요청이 있습니다.

우리 제품 소개 문구 써줘.

제품의 특징, 고객층, 경쟁 제품과의 차이, 피하고 싶은 표현이 하나도 없다면 AI는 평균적인 소개문을 만들 가능성이 큽니다. 그러면 "뻔하다"는 느낌이 듭니다.

이때는 "더 창의적으로"를 붙일 것이 아니라 입력을 보강해야 합니다. 예를 들어 제품이 무엇인지, 어떤 문제를 해결하는지, 주요 고객이 누구인지, 어떤 인상을 주고 싶은지를 함께 적습니다.

좋은 출력은 좋은 문장에서만 나오지 않습니다. 좋은 재료에서도 나옵니다. 프롬프트를 고친다는 말은, 필요하면 입력 자체를 더 채운다는 뜻이기도 합니다.

기준이 없으면, 평가 기준을 먼저 만든다

다음 요청을 보겠습니다.

더 좋은 버전으로 바꿔줘.

여기서 "좋은"은 무엇일까요. 더 짧은 것인지, 설득력이 높은 것인지, 전문적인 것인지, 친근한 것인지 알 수 없습니다. 이런 경우에는 프롬프트를 고치기 전에 기준부터 세워야 합니다.

예를 들어 이렇게 바꿀 수 있습니다.

아래 문장을 더 좋은 버전으로 바꿔줘. 여기서 좋은 버전의 기준은 세 가지다. 첫째, 첫 문장에서 핵심이 바로 보여야 한다. 둘째, 초보자도 이해할 수 있는 쉬운 표현을 쓴다. 셋째, 분량은 원문보다 20퍼센트 이내로만 늘어난다.

이렇게 되면 결과를 보고 다시 고치기도 쉬워집니다. "첫 문장이 여전히 약하다"처럼 구체적으로 피드백할 수 있기 때문입니다.

지시가 충돌하면, 우선순위를 적는다

프롬프트가 이상한 이유는 조건이 너무 많아서가 아니라, 조건의 순서가 없어서인 경우가 많습니다.

예를 들어 "짧게 쓰되 자세하게 설명해줘"는 둘 다 중요해 보이지만 실제로는 긴장 관계에 있습니다. 이럴 때는 어느 쪽이 더 중요한지 적어야 합니다.

가능한 한 짧게 쓰되, 핵심 개념 3개는 반드시 포함해줘. 세부 사례는 필요하면 생략해도 된다.

이 한 줄이 들어가면 AI는 무엇을 지키고 무엇을 포기해야 하는지 알 수 있습니다. 프롬프트 수정에서 우선순위는 의외로 강력한 도구입니다.

"다시 써줘"보다 좋은 피드백의 말투

프롬프트를 고칠 때는 새 프롬프트를 처음부터 다시 만드는 방법도 있지만, 이전 출력에 피드백을 주는 방식도 아주 유용합니다. 특히 멀티턴 대화에서는 이 방법이 효율적입니다.

문제는 많은 사람이 피드백을 너무 추상적으로 한다는 점입니다. "별로야", "좀 더 좋게", "아니 이런 느낌 말고" 같은 말은 사람에게도 어렵고 AI에게도 어렵습니다.

피드백은 가능하면 결과의 특정 부분과 수정 방향이 함께 들어가야 합니다.

예를 들어 이런 식이 좋습니다.

• 첫 문단이 너무 길다. 결론을 첫 두 문장 안에 넣어줘.

• 내용은 괜찮은데 대상 독자가 너무 전문가처럼 가정되어 있다. 비전공자 기준으로 다시 풀어줘.

• 정보는 충분한데 바로 복사해서 쓰기 어렵다. 이메일 형식으로 바꿔줘.

• 어조가 너무 홍보 같다. 차분하고 신뢰감 있는 문체로 조정해줘.

이 피드백들의 공통점은 막연한 평가가 아니라, 어디가 문제인지와 어떻게 바꾸고 싶은지가 함께 있다는 것입니다.

예시로 보는 수정 과정

실전 감각을 위해 하나의 프롬프트를 단계별로 고쳐 보겠습니다.

처음 프롬프트는 이렇습니다.

회의 내용을 정리해줘.

이 프롬프트로도 뭔가는 나옵니다. 하지만 실제로는 너무 많은 가능성이 열려 있습니다. 단순 요약인지, 액션 아이템 정리인지, 상사 보고용인지, 참가자 공유용인지 알 수 없습니다.

첫 번째 수정은 용도를 추가하는 것입니다.

아래 회의 내용을 팀원 공유용으로 정리해줘.

조금 나아졌지만 아직 부족합니다. 팀원 공유용이라도 어떤 형식인지 모릅니다. 그래서 두 번째 수정으로 출력 형식을 더합니다.

아래 회의 내용을 팀원 공유용으로 정리해줘. 형식은 결정 사항, 미해결 사항, 다음 액션으로 나눠서 써줘.

이제 훨씬 쓸 만해집니다. 그런데 결과를 보니 액션 아이템에 담당자와 일정이 빠졌다고 해 봅시다. 그러면 세 번째 수정은 이것입니다.

다음 액션 항목에는 담당자와 마감 시점을 함께 적어줘. 회의 내용에 없는 경우에는 추측하지 말고 '미정'이라고 표시해줘.

이 짧은 수정만으로 결과의 실용성이 크게 달라집니다. 여기서 중요한 점은, 처음부터 완벽한 프롬프트를 쓴 것이 아니라는 것입니다. 출력을 보고 필요한 기능을 한 겹씩 추가해 갔다는 데 의미가 있습니다.

이것이 프롬프트를 잘 고치는 사람의 방식입니다.

AI에게 프롬프트 진단을 맡길 수 있을까

가능합니다. 다만 맡기는 방식이 중요합니다. "왜 결과가 별로야?"라고 물으면 대답도 애매해지기 쉽습니다. 대신 AI에게 평가자의 역할을 분명히 주는 편이 좋습니다.

예를 들면 이렇게 말할 수 있습니다.

아래 프롬프트가 원하는 결과를 잘 만들지 못했다. 원인을 세 가지 범주로 나눠 진단해줘. 1) 목표의 모호함 2) 입력 정보 부족 3) 출력 기준 부재. 각 항목마다 어떤 부분이 문제인지 짚고, 최소 수정안도 제안해줘.

이렇게 하면 AI는 단순히 새 문장을 뽑아 주는 것이 아니라, 수정의 관점을 제공할 수 있습니다. 물론 이 진단도 무조건 믿으면 안 됩니다. 하지만 사람이 놓친 문제를 발견하는 데는 꽤 도움이 됩니다.

특히 초보자에게는 이 방식이 좋습니다. 무엇을 봐야 할지 모를 때, AI에게 먼저 진단 틀을 제시하게 하면 수정의 감각을 빨리 익힐 수 있기 때문입니다.

프롬프트 버전을 남겨 두면 실력이 빨리 는다

많은 사람은 프롬프트를 고치면서 이전 버전을 지워 버립니다. 그러면 무엇을 어떻게 바꿨는지 기억에만 의존하게 됩니다. 그런데 기억은 생각보다 부정확합니다.

실력이 빨리 느는 사람은 작은 버전 기록을 남깁니다. 꼭 거창한 문서가 아니어도 됩니다. 예를 들어 이런 식이면 충분합니다.

• v1: 대략적인 요청만 함

• v2: 대상 독자 추가

• v3: 출력 형식 추가

• v4: 금지 사항과 평가 기준 추가

이 기록이 왜 중요할까요. 나중에 비슷한 작업을 할 때 다시 출발점으로 쓸 수 있기 때문입니다. 프롬프트를 잘 쓰는 사람은 매번 처음부터 쓰는 사람이 아니라, 이전의 수정 경험을 재사용하는 사람입니다.

결국 프롬프트 실력은 손재주보다 축적에 가깝습니다. 어떤 작업에서 어떤 수정이 먹혔는지 기억하고 꺼내 쓸수록, 점점 더 빠르고 정확하게 개선할 수 있습니다.

어느 순간에는 고치는 것을 멈추고 다시 설계해야 한다

모든 프롬프트가 끝없이 고쳐서 좋아지는 것은 아닙니다. 어떤 경우에는 문장을 더 만지는 것보다 작업 자체를 다시 나누는 편이 낫습니다.

예를 들어 이런 상황입니다. 자료가 너무 길어서 자꾸 핵심을 놓친다거나, 한 번의 요청에 분석과 창작이 너무 많이 섞여 있다거나, 애초에 입력 정보가 거의 없어서 맞춤형 결과가 불가능한 경우입니다.

이때 계속 프롬프트만 덕지덕지 붙이면 비대해지고, 오히려 불안정해집니다. 그런 프롬프트는 커진다고 강해지는 것이 아니라, 커질수록 흔들립니다.

이런 순간에는 과감하게 물러서야 합니다. 그리고 질문해야 합니다.

"이건 프롬프트 한 번의 문제가 아니라, 작업 설계의 문제 아닌가?"

이 질문이 나오는 순간부터 사용자는 한 단계 올라갑니다. 프롬프트를 잘 쓰는 사람에서, 작업을 잘 설계하는 사람으로 넘어가기 시작하기 때문입니다. 이 감각은 뒤에서 다룰 멀티턴 대화와 워크플로 설계의 기초가 됩니다.

고칠수록 좋아지는 사람의 습관

프롬프트를 잘 고치는 사람에게는 공통된 습관이 있습니다. 특별한 비법이라기보다, 계속 품질을 올리게 만드는 태도에 가깝습니다.

• 첫 결과가 별로여도 능력 부족으로 받아들이지 않고, 수정할 재료로 본다.

• 문제를 막연히 느끼지 않고 증상으로 말해 본다.

• 한 번에 하나의 수정만 적용해 본다.

• 출력만 탓하지 않고 입력과 기준도 함께 점검한다.

• 비슷한 작업에서 잘된 수정 패턴을 다시 사용한다.

이 습관은 사소해 보여도 차이를 크게 만듭니다. 프롬프트를 한 번의 승부로 보는 사람은 실패할 때마다 새로 흔들립니다. 반면 프롬프트를 개선 대상으로 보는 사람은 실패할수록 데이터가 쌓입니다.

그래서 실전에서는 재능보다 습관이 더 중요합니다.

프롬프트를 고친다는 것은 결국 무엇인가

결국 프롬프트 수정은 한 문장을 더 잘 꾸미는 일이 아닙니다. AI가 어디서 헷갈렸는지 찾아내고, 그 혼란을 줄이는 일입니다.

목표가 흐리면 선명하게 만들고, 작업이 과하면 나누고, 정보가 부족하면 보강하고, 기준이 없으면 평가 규칙을 세우고, 지시가 충돌하면 우선순위를 정합니다. 이것이 프롬프트를 고치는 핵심입니다.

이 관점이 생기면 프롬프트는 더 이상 감으로 건드리는 신비한 주문이 아닙니다. 결과를 보고 구조를 조정하는 작업 도구가 됩니다.

그리고 바로 여기서 중요한 변화가 일어납니다. 당신은 이제 "무슨 말을 써야 하지?"만 고민하는 사람이 아니라, "어떻게 개선하지?"를 생각하는 사람이 됩니다. 이 차이가 쌓이면 AI 활용 수준도 달라집니다.

이 장의 핵심 정리

프롬프트는 처음부터 완벽하게 쓰는 대상이 아니라, 결과를 보며 반복적으로 고쳐 가는 대상입니다. 잘 안 될 때는 곧바로 다시 쓰지 말고, 먼저 무엇이 어긋났는지 관찰해야 합니다. 그다음 원인을 하나 정하고, 수정도 하나만 적용해 봐야 합니다.

목표가 흐리면 더 선명하게, 작업이 많으면 더 작게, 정보가 부족하면 더 풍부하게, 기준이 없으면 더 평가 가능하게, 지시가 충돌하면 더 우선순위 있게 바꾸면 됩니다.

프롬프트 실력은 멋진 문장을 떠올리는 능력보다, 실패를 읽고 수정하는 능력에서 나옵니다. 잘 쓰는 사람보다 잘 고치는 사람이 결국 더 멀리 갑니다.

다음 부부터는 이 수정 감각을 더 넓은 관점으로 확장해 보겠습니다. 프롬프트 한 줄을 넘어서, AI가 왜 어떤 맥락에서는 잘하고 어떤 맥락에서는 흔들리는지 이해하려면 이제 컨텍스트를 알아야 합니다.