생성형 AI를 처음 사용할 때는 한 번의 질문으로 원하는 결과가 바로 나오기를 기대하기 쉽다.
프롬프트를 충분히 자세하게 작성했으니 답변도 거의 완성된 형태로 나와야 한다고 생각하는 것이다.
하지만 실제로 AI를 문서 작성이나 아이디어 정리 같은 작업에 사용하다 보면 첫 번째 결과가 70~80% 정도는 괜찮지만 나머지 부분이 마음에 들지 않는 상황을 자주 만난다.
내용은 좋은데 너무 길 수도 있고, 전체 구성은 괜찮은데 구체적인 예시가 부족할 수도 있다. 반대로 설명은 충분하지만 같은 표현이 반복되어 글이 늘어진 것처럼 느껴질 수도 있다.
이럴 때 처음부터 프롬프트를 새로 작성하는 것보다 더 실용적인 방법이 있다.
바로 현재 결과에서 무엇이 부족한지 찾아 그 부분만 수정하도록 요청하는 것이다.
생성형 AI 활용에서 중요한 것은 완벽한 첫 질문보다, 결과를 보고 다음 질문을 더 정확하게 만드는 능력에 가깝다.
“다시 써줘”보다 무엇이 문제인지 알려준다
AI의 답변이 마음에 들지 않을 때 가장 쉽게 입력할 수 있는 문장은 다음과 같다.
“다시 써줘.”
물론 이렇게 요청하면 새로운 답변이 나온다.
하지만 어떤 부분이 마음에 들지 않았는지 알려주지 않았기 때문에 새 답변에서도 비슷한 문제가 반복될 수 있다.
예를 들어 AI가 작성한 블로그 도입부가 지나치게 추상적이었다고 가정해보자.
단순히,
“도입부 다시 써줘.”
라고 하는 대신,
“현재 도입부는 ‘AI가 빠르게 발전하고 있다’는 일반적인 설명이 길어. 이 부분은 줄이고, 직장인이 긴 회의록을 정리해야 하는 구체적인 상황에서 시작하도록 바꿔줘.”
라고 요청할 수 있다.
두 번째 방식에는 문제가 무엇인지와 원하는 수정 방향이 함께 들어 있다.
AI에게 수정 요청을 할 때는 다음 두 가지를 구분하면 편하다.
현재 결과에서 무엇이 부족한가?
그리고,
어떤 방향으로 바꾸고 싶은가?
이 두 가지가 명확하면 불필요하게 전체 내용을 다시 생성하는 일을 줄일 수 있다.
답변을 평가할 기준을 먼저 정한다
좋고 나쁨을 막연한 느낌으로만 판단하면 수정 요청도 모호해지기 쉽다.
“뭔가 별로야.”
“조금 어색해.”
“더 잘 써줘.”
이런 표현은 사람이 느끼는 감정으로는 자연스럽지만 AI에게는 정확한 수정 기준이 되기 어렵다.
그래서 결과물을 확인할 때는 몇 가지 기준으로 나누어 보는 것이 좋다.
예를 들어 정보형 블로그 글이라면 다음과 같은 항목을 확인할 수 있다.
첫째, 독자가 이해하기 쉬운가?
둘째, 주제에서 벗어난 내용이 없는가?
셋째, 설명만 있고 구체적인 사례가 부족하지 않은가?
넷째, 같은 이야기를 반복하고 있지 않은가?
다섯째, 근거 없이 지나치게 단정한 표현이 없는가?
여기에 글의 목적에 따라 다른 기준을 추가할 수 있다.
업무 보고서라면 핵심 결론이 앞에 있는지 볼 수 있고, 회의록이라면 담당자와 일정이 명확하게 구분되어 있는지 살펴볼 수 있다.
이렇게 평가 기준을 먼저 갖고 있으면 “전체적으로 마음에 들지 않는다”는 느낌을 실제 수정 작업으로 바꾸기가 쉬워진다.
AI에게 평가만 먼저 시키는 것도 방법이다
긴 결과물을 받았는데 어디서부터 수정해야 할지 모르겠다면 AI에게 바로 새로 작성하게 하지 않고 현재 결과를 평가만 하도록 요청할 수 있다.
예를 들어 다음처럼 사용할 수 있다.
“아직 글을 수정하지 말고 현재 초안을 먼저 평가해줘. 초보자 이해도, 내용 중복, 구체적인 예시의 충분함, 설명 흐름의 자연스러움 네 가지 기준으로 문제점을 찾아줘.”
여기서 중요한 문장은 “아직 수정하지 말고”다.
평가와 수정을 한 번에 요청하면 AI가 문제점을 충분히 분석하기 전에 바로 새로운 문장으로 바꿀 수 있다.
반대로 평가 단계와 수정 단계를 분리하면 어떤 문제를 해결하고 있는지 확인하기 쉽다.
평가 결과가 나온 뒤에는 사용자가 실제로 동의하는 항목만 골라서 반영할 수 있다.
예를 들어 AI가 다섯 가지 문제를 제안했다고 해보자.
그중 두 가지는 실제로 수정할 필요가 없다고 판단할 수도 있다.
그러면,
“2번과 4번 지적은 반영하지 말고, 1번·3번·5번만 수정해줘. 글의 전체 소제목 구조는 유지해줘.”
라고 요청하면 된다.
AI의 검토 결과까지 사람이 선택적으로 사용하는 방식이다.
수정 요청은 가능한 한 작은 단위로 나눈다
긴 글에서 한꺼번에 여러 부분을 고치려고 하면 예상치 못한 변화가 생길 수 있다.
예를 들어,
“글을 더 짧고 자연스럽고 전문적으로 바꾸고, 예시도 추가하고 소제목도 바꿔줘.”
라고 요청했다고 해보자.
한 번에 여러 요소를 변경하기 때문에 결과가 좋아질 수도 있지만, 원래 마음에 들었던 부분까지 크게 달라질 가능성도 있다.
이럴 때는 수정 범위를 작게 나누는 것이 좋다.
먼저,
“현재 정보는 유지하면서 반복되는 설명만 줄여줘.”
라고 요청한다.
그 결과가 괜찮다면 다음으로,
“이제 두 번째 소제목에 실제 업무 예시 하나만 추가해줘.”
라고 한다.
마지막으로,
“전체 문체를 확인해서 지나치게 딱딱한 표현만 자연스럽게 바꿔줘.”
라고 진행할 수 있다.
이 방식은 조금 번거롭게 느껴질 수도 있다.
하지만 중요한 문서나 긴 콘텐츠를 다룰 때는 어떤 수정이 어떤 변화를 만들었는지 확인할 수 있다는 장점이 있다.
사람이 문서를 편집할 때도 한 번에 모든 문제를 해결하기보다 구조를 먼저 보고, 내용을 수정하고, 마지막에 문장을 다듬는 경우가 많다.
AI를 사용할 때도 비슷한 순서를 적용할 수 있다.
유지해야 할 부분을 함께 지정한다
AI에게 수정을 요청할 때 자주 생기는 문제가 있다.
고쳐달라고 한 부분은 좋아졌는데, 원래 괜찮았던 부분까지 바뀌는 것이다.
예를 들어 본문의 한 사례만 수정하고 싶었는데 제목과 소제목까지 달라질 수 있다.
이를 줄이려면 변경 사항뿐 아니라 유지할 사항을 함께 알려주는 것이 좋다.
예를 들어,
“제목과 소제목 구조는 그대로 유지하고 세 번째 소제목의 예시만 수정해줘.”
라고 할 수 있다.
또는,
“핵심 주장과 정보는 바꾸지 말고 문장 길이만 줄여줘.”
“첫 번째 문단은 그대로 유지하고 두 번째 문단부터 중복되는 내용을 정리해줘.”
“현재의 차분한 문체는 유지하고 전문 용어에 설명만 추가해줘.”
처럼 사용할 수 있다.
이런 요청은 특히 이미 결과의 상당 부분이 마음에 들 때 유용하다.
전체를 다시 작성하는 것보다 필요한 부분만 고치는 편이 결과를 안정적으로 관리하기 쉽다.
막연한 표현을 구체적인 수정 행동으로 바꾼다
수정 프롬프트의 품질을 높이는 쉬운 방법은 추상적인 표현을 실제 행동으로 바꾸는 것이다.
예를 들어,
“좀 더 읽기 좋게 해줘.”
라고 요청하는 대신,
“한 문장이 너무 길게 이어지는 부분은 둘로 나누고, 같은 의미가 반복되는 문장은 하나로 합쳐줘.”
라고 요청할 수 있다.
“더 전문적으로 써줘.”
대신,
“막연한 강조 표현을 줄이고, 개념 설명 뒤에 실제 적용 상황을 덧붙여줘.”
라고 할 수 있다.
“좀 더 친근하게 써줘.”
대신,
“공문체 표현을 줄이고 초보자에게 설명하듯 자연스러운 정보형 문장으로 바꿔줘. 반말이나 과도한 감탄사는 사용하지 말아줘.”
라고 정리할 수 있다.
핵심은 ‘좋게’, ‘자연스럽게’, ‘전문적으로’ 같은 평가형 표현만 쓰지 않고 어떤 문장을 어떤 방식으로 바꾸면 되는지 설명하는 것이다.
좋은 결과가 나오면 왜 좋았는지도 기록한다
AI 활용에서 수정해야 할 문제만 기록하는 경우가 많다.
하지만 반대로 마음에 들었던 결과에서 무엇이 좋았는지를 확인해두는 것도 도움이 된다.
예를 들어 어떤 블로그 초안이 특히 잘 읽혔다면 이유를 살펴볼 수 있다.
도입부가 실제 상황에서 시작했는지, 소제목이 구체적이었는지, 전문 용어 뒤에 바로 예시가 붙었는지, 한 문단이 짧게 유지됐는지 확인하는 것이다.
이런 특징을 다음 프롬프트에 반영할 수 있다.
“이전 결과에서 사용한 ‘개념 설명 → 짧은 업무 사례 → 주의점’ 흐름은 유지해줘.”
또는,
“앞서 작성한 글의 문장 길이와 정보 밀도는 적절했어. 같은 수준을 유지하되 이번에는 다른 사례를 사용해줘.”
처럼 활용할 수 있다.
반복적인 AI 활용에서 중요한 것은 좋은 프롬프트 문장 하나를 발견하는 것이 아니라, 내가 어떤 결과를 좋은 결과라고 판단하는지 기준을 쌓는 것이다.
이 기준이 쌓이면 다음 작업에서도 수정 횟수를 줄이기 쉬워진다.
버전을 구분하면 수정 과정을 관리하기 쉽다
하나의 문서를 여러 번 수정하다 보면 어떤 결과가 가장 좋았는지 헷갈릴 수 있다.
예를 들어 1차 결과에서 내용은 좋았지만 문장이 길었다.
2차에서는 문장이 좋아졌지만 중요한 설명이 빠졌다.
3차에서는 설명을 다시 추가했더니 글이 또 길어졌다.
이런 상황에서는 무조건 가장 최신 결과가 가장 좋은 결과라고 볼 수 없다.
그래서 중요한 작업이라면 버전을 구분해서 생각하는 것이 좋다.
“첫 번째 버전의 내용 구성을 기준으로 하고, 두 번째 버전에서 개선된 문장 길이만 반영해줘.”
처럼 요청할 수 있다.
또는,
“현재 버전을 수정하기 전에 변경할 부분만 먼저 알려줘.”
라고 요청해 예상되는 변화를 확인할 수도 있다.
생성형 AI의 장점은 다시 만들기가 쉽다는 것이지만, 동시에 쉽게 다시 만들 수 있기 때문에 좋은 결과를 놓치기도 쉽다.
마음에 드는 결과가 있다면 별도로 보관해두고 그 버전을 기준점으로 사용하는 것이 안전하다.
‘더 좋게’보다 비교를 요청하면 차이를 보기 쉽다
수정 과정에서 결과가 실제로 개선됐는지 판단하기 어려운 경우도 있다.
이럴 때는 이전 버전과 수정 버전을 비교하도록 요청할 수 있다.
예를 들어,
“수정 전 문단과 수정 후 문단을 비교해서 달라진 점을 세 가지로 설명해줘. 정보가 빠진 부분이 있는지도 함께 확인해줘.”
라고 요청할 수 있다.
블로그 글이라면,
“두 버전 중 AI 초보자가 읽기에 더 쉬운 쪽이 어느 것인지 판단하고, 그 이유를 전문 용어 사용량, 문장 길이, 예시의 구체성 기준으로 설명해줘.”
처럼 기준을 설정할 수도 있다.
AI의 판단을 그대로 따를 필요는 없다.
중요한 것은 두 결과의 차이를 눈에 보이게 만들어 사용자가 선택하기 쉽게 하는 것이다.
실제로 수정 작업에서는 ‘더 좋아졌는가’보다 무엇이 달라졌는가를 확인하는 것이 더 유용할 때가 많다.
반복 수정이 끝없이 이어지지 않도록 종료 기준을 정한다
AI는 요청할 때마다 새로운 수정안을 만들 수 있다.
그래서 반대로 언제 수정을 멈춰야 할지 애매해질 수 있다.
한 문장을 고치면 다른 표현이 눈에 들어오고, 다시 고치면 또 다른 버전이 나온다.
이런 과정을 계속하다 보면 실제 사용보다 수정 자체에 더 많은 시간을 쓰게 된다.
따라서 작업을 시작하기 전에 간단한 종료 기준을 만들어두는 것도 좋다.
예를 들어 블로그 글이라면 다음 네 가지가 충족되면 최종 검토 단계로 넘어갈 수 있다.
주제와 직접 관련된 내용으로 구성되어 있는가
초보자가 이해하기 어려운 표현에 설명이 있는가
같은 내용이 지나치게 반복되지 않는가
확인되지 않은 구체적인 사실이 없는가
이 기준을 충족했다면 문장을 계속 바꾸기보다 사람이 마지막으로 읽어보고 게시 목적에 맞는지 확인하는 편이 낫다.
완벽한 문장을 끝없이 찾는 것보다 목적을 충족하는 충분히 좋은 결과를 만드는 것이 실제 활용에서는 더 중요하다.
바로 활용할 수 있는 반복 개선 프롬프트
AI 답변을 받은 뒤 무엇부터 수정해야 할지 모르겠다면 다음과 같은 구조를 활용할 수 있다.
“아래 초안을 바로 다시 작성하지 말고 먼저 평가해줘.
평가 기준:
주제에서 벗어난 내용이 있는지
반복되는 설명이 있는지
초보자가 이해하기 어려운 부분이 있는지
구체적인 예시가 부족한 부분이 있는지
사실 확인이 필요한 표현이 있는지
각 문제를 ‘문제 위치 → 이유 → 수정 방향’ 순서로 정리해줘.”
평가 결과를 확인한 뒤에는 다음처럼 이어갈 수 있다.
“평가 결과 중 1번, 2번, 4번 문제만 수정해줘. 제목과 소제목 구조, 핵심 정보는 그대로 유지하고 새로 확인되지 않은 사실은 추가하지 말아줘.”
이렇게 평가와 수정을 나누면 막연하게 “더 잘 써줘”라고 반복하는 것보다 훨씬 관리하기 쉽다.
마무리
생성형 AI에서 좋은 결과를 얻는 방법은 완벽한 프롬프트를 한 번 작성하는 것만이 아니다.
첫 번째 결과를 확인하고, 무엇이 부족한지 구체적으로 판단한 뒤, 필요한 부분만 수정하도록 요청하는 과정도 중요한 프롬프트 활용법이다.
특히 “다시 써줘”, “좀 더 자연스럽게 해줘”처럼 막연한 요청보다 현재 문제와 원하는 수정 방향을 함께 알려주는 것이 좋다.
긴 결과물에서는 평가와 수정을 분리하고, 한 번에 너무 많은 부분을 바꾸기보다 작은 단위로 수정하면 결과의 변화를 확인하기 쉽다.
또한 변경할 부분만큼 유지할 부분도 명확하게 지정해야 원래 괜찮았던 내용이 불필요하게 달라지는 일을 줄일 수 있다.
결국 반복 개선의 핵심은 AI에게 계속 새로운 답을 요구하는 데 있지 않다.
현재 결과를 보고 다음 요청을 더 정확하게 만드는 것에 있다.
이 과정을 반복하다 보면 자연스럽게 자신만의 평가 기준도 생긴다. 그리고 그 기준은 다음번 프롬프트를 작성할 때 다시 활용할 수 있다.
다음 글에서는 생성형 AI에 업무 자료를 입력할 때 놓치기 쉬운 부분인 개인정보와 회사 내부 정보, 민감한 자료를 프롬프트에 넣기 전에 확인해야 할 기본적인 데이터 관리 습관을 살펴본다.
FAQ
Q1. 첫 번째 AI 답변이 마음에 들지 않으면 새 대화를 시작하는 것이 좋은가요?
반드시 그럴 필요는 없다. 전체 방향이 잘못된 것이 아니라 일부 표현이나 구성만 문제라면 같은 대화에서 수정 범위를 구체적으로 지정하는 편이 효율적이다. 반대로 목표 자체가 완전히 바뀌었거나 이전 지시가 지나치게 복잡하게 섞였다면 핵심 조건을 정리해 새 대화에서 시작하는 방법도 있다.
Q2. AI에게 글을 평가하게 한 뒤 그 평가를 그대로 따라도 되나요?
그대로 따를 필요는 없다. AI의 평가는 수정 후보를 찾는 참고 자료로 활용하는 것이 좋다. 사용자가 글의 목적과 독자를 기준으로 실제 필요한 수정인지 판단하고, 동의하는 항목만 선택해서 반영하는 방식이 더 적절하다.
Q3. 몇 번 정도 수정하면 충분한가요?
정해진 횟수는 없다. 수정 횟수보다 글이 실제 목적을 충족하는지가 중요하다. 핵심 내용이 정확하고, 독자가 이해할 수 있으며, 불필요한 반복이 없고, 중요한 사실을 확인했다면 계속 문장만 바꾸기보다 최종 검토 후 사용하는 편이 효율적이다.
0 댓글