AI 글쓰기 프롬프트를 수정하는 것을 멈추세요. 그전에 이 5가지를 먼저 결정해야 합니다.
요약
AI 글쓰기 품질을 높이기 위해 프롬프트 수정 대신 5가지 핵심 요소가 담긴 편집 브리프를 작성할 것을 제안합니다. 독자, 핵심 메시지, 자료, 논점, 위임 범위를 먼저 결정함으로써 AI의 결과물이 공허해지는 문제를 해결할 수 있습니다.
핵심 포인트
- 단순 프롬프트 수정보다 명확한 편집 브리프 작성이 중요함
- 독자, 핵심 메시지, 사용 자료, 첫 논점, 위임 범위를 결정해야 함
- 프롬프트는 명령이지만, 브리프는 워크플로를 구축하는 과정임
- AI의 유창함이 편집적 결정의 부재를 가리지 않도록 주의해야 함
저는 예전에 더 나은 산문(prose)을 요구함으로써 품질이 낮은 AI 초안을 수정하곤 했습니다.
"더 명확하게 만들어줘." "더 설득력 있게 만들어줘." "덜 일반적인 느낌이 들게 해줘."
결과물은 조금 개선되었습니다. 하지만 곧 똑같은 지점에서 실패했습니다. 기사는 다듬어진 것처럼 보였지만, 정작 무엇을 말하려 하는지 아무도 기억하지 못했습니다.
요약(TL;DR): AI에게 글을 쓰라고 요청하기 전에, 독자(audience), 핵심 메시지(takeaway), 사용할 자료(material to use), 배치할 첫 번째 논점(first point to place), 그리고 AI에게 위임할 범위(scope delegated to AI)라는 다섯 줄의 편집 브리프(editorial brief)를 작성하세요. 의사결정 권한이 인간에게 돌아오기 때문에 프롬프트는 오히려 더 짧아집니다.
빠른 답변: AI에게 글을 쓰라고 하기 전에 무엇을 결정해야 하나요?
첫 초안을 작성하기 전에 다음 다섯 가지를 결정하세요:
- 독자는 누구인가?
- 그 독자가 무엇을 얻어가야 하는가?
- 어떤 자료를 사용하고, 어떤 자료를 삭제해야 하는가?
- 독자가 논지를 따라올 수 있도록 무엇이 가장 먼저 등장해야 하는가?
- 어떤 부분은 AI가 결정하도록 허용하고, 어떤 부분은 본인이 직접 유지할 것인가?
이것이 AI 글쓰기 프롬프트(prompt)와 AI 글쓰기 워크플로(workflow)의 차이입니다.
프롬프트는 "이것에 대해 유용한 기사를 써줘"라고 말합니다. 반면 워크플로는 "이 독자를 위해, 이 핵심 메시지를 전달하기 위해, 이 자료를 사용하여, 이 순서대로 작성하되, 이러한 결정 사항들은 건드리지 마라"라고 말합니다.
제가 초안을 작성하기 전에 사용하는 복사-붙여넣기용 버전은 다음과 같습니다:
cat > ai-writing-brief.md <<'BRIEF'
Audience:
Takeaway:
...
결과물: AI가 초안 작성을 시작하기 전에 인간의 의사결정을 가시화하는 다섯 줄의 브리프.
만약 이 다섯 줄이 비어 있다면, 더 나은 프롬프트도 대개 기사를 구원하지 못합니다. 그저 일반적인 답변을 더 예쁘게 만들 뿐입니다.
왜 다듬어진 AI 글쓰기가 여전히 공허하게 느껴지는가
AI는 당신이 주는 지시를 충족할 수 있습니다. 더 자세한 내용을 요구하면 세부 사항을 추가합니다. 더 쉬운 언어를 요구하면 전문 용어(jargon)를 제거합니다. 친근한 어조를 요구하면 말투를 부드럽게 만듭니다.
이 모든 것이 정확할 수 있지만, 여전히 쓸모없을 수 있습니다.
부족한 부분은 문법이 아닙니다. 바로 목적(aim)입니다.
초안에 제목(headings)이 있고, 깔끔한 문단(paragraphs)과 자연스러운 전환(transitions)이 있더라도, 독자에게 아무런 결정도, 다음 단계도, 기억할 만한 문장도 남기지 못할 수 있습니다. 이러한 실패는 초안이 망가져 보이지 않기 때문에 특히 더 좌절감을 줍니다. 수정해야 할 명백한 오타도 없고, 명백히 잘못된 문단도 없습니다. 그저 무게감이 없을 뿐입니다.
그때 많은 사람이 프롬프트(prompt)를 다듬기 시작합니다.
그들은 더 많은 제약 조건(constraints)을 추가합니다. 어조(tone)를 지정합니다. 예시를 요구합니다. 더 강력한 도입부를 요구합니다. 모델에게 "매력적으로 만들어줘(make it engaging)"라고 요청합니다. 초안은 더 유창해지지만, 핵심적인 문제는 그대로 남아 있습니다. 모델은 여전히 이 글을 통해 누가 변화해야 하는지를 알지 못합니다.
저에게 불편한 교훈은 이것이었습니다: 잘 다듬어진 AI 초안은 편집적 결정(editorial decision)의 부재를 숨길 수 있다는 것입니다.
모델이 수용 가능한 산문(prose)을 쓰는 능력이 좋아질수록, 이 글이 무엇을 위한 것인지 아무도 결정하지 않았다는 사실을 놓치기가 더 쉬워집니다.
결정 1: 독자는 누구인가?
"개발자"는 독자가 아닙니다. "AI에 관심 있는 사람들"도 독자가 아닙니다. "팀의 모든 구성원"도 독자가 아닙니다.
그러한 라벨들은 마케팅 스프레드시트에나 있는 타겟층(audiences)입니다. 문단을 안내하기에는 너무 광범위합니다.
사용 가능한 독자는 다음과 것에 더 가깝습니다:
- 내부 문서(internal docs)에 AI를 사용하기 시작했지만 계속해서 밋밋한 초안을 받고 있는 백엔드 개발자.
- 요점을 놓치지 않으면서 주간 보고서가 더 짧아지기를 원하는 팀 리드(team lead).
- 도구의 이름은 알지만 아직 팀의 어휘(vocabulary)는 모르는 새로운 팀원.
독자는 당신이 트레이드오프(tradeoffs)를 할 수 있을 정도로 충분히 구체적이어야 합니다.
독자가 초보자라면 용어를 정의합니다. 독자가 이미 프로젝트에 깊이 관여하고 있다면 배경 설명(setup)을 건너뜁니다. 독자가 서두르고 있다면 결론(decision)을 상단으로 옮깁니다. 독자가 회의적이라면 실패 사례(failure mode)를 먼저 보여줍니다.
그러한 독자가 없다면, 모델은 가능한 가장 안전한 선택을 합니다. 즉, 모호한 평균적인 사람을 위해 글을 쓰는 것입니다.
그 평균적인 사람이 바로 AI 글쓰기가 어디서 왔는지도 모르겠고 어디로 가는지도 모르겠다는 느낌을 주는 경우가 많습니다.
제가 사용하는 테스트는 다음과 같습니다: 이 초안을 통해 도움을 받을 수 있는 실제 인물 한 명을 이름으로 부를 수 있는가?
인구 통계학적 집단이 아닙니다. 한 사람입니다. 그 사람이 현재 겪고 있는 혼란을 단 한 문장으로 설명할 수 있는 누군가 말입니다.
만약 그렇게 할 수 없다면, 저는 아직 AI에게 초안 작성을 요청하지 않습니다.
결정 2: 독자가 무엇을 얻어가야 하는가?
포스트는 당신이 알고 있는 모든 것을 담는 컨테이너가 아닙니다. 그것은 하나의 유용한 아이디어를 전달하는 과정입니다.
제가 AI에게 일주일간의 업무를 요약해달라고 요청할 때, AI는 회의, 작은 수정 사항, 결정 사항, 미결 과제, 배경 맥락 등 눈에 보이는 모든 사실을 포함하는 경향이 있습니다. 반드시 틀린 내용은 없습니다. 하지만 독자가 "계속 진행해도 안전한가?"라는 단 하나의 답변을 원했다면, 그 결과물은 여전히 실패한 것입니다.
사실(Facts)은 핵심 요점(Takeaway)과 같은 것이 아닙니다.
이제 저는 초안을 작성하기 전에, 다음 문구를 완성하는 한 문장을 작성합니다:
이 글을 읽고 난 후, 독자는 ... 할 수 있어야 한다.
예를 들면 다음과 같습니다:
- 이 글을 읽고 난 후, 독자는 더 나은 AI 글쓰기 브리프 (Writing brief)를 작성할 수 있어야 한다.
- 이 글을 읽고 난 후, 독자는 자료 선정 (Material selection)과 산문 다듬기 (Prose polishing)를 분리할 수 있어야 한다.
- 이 글을 읽고 난 후, 독자는 AI 초안을 처음부터 다시 읽지 않고도 검토할 수 있어야 한다.
그 문장이 초안의 척추(Spine)가 됩니다.
또한 그 문장은 당신에게 좋은 내용을 삭제할 수 있는 권한을 부여합니다.
핵심 요점에 도움이 되지 않는 좋은 내용은 이 글에서 여전히 소음 (Noise)일 뿐입니다. 그것은 다른 글이나 각주, 후속 글, 또는 개인적인 메모에는 적합할 수 있습니다. 단지 그것이 사실이라고 해서 이 글에 포함되어서는 안 됩니다.
결정 3: 어떤 내용을 삭제해야 하는가?
사람들은 종종 AI를 더 큰 편지함처럼 취급합니다. 모든 메모를 집어넣고 초안을 요청한 뒤, 모델이 스스로 요점을 찾아내기를 기대하는 식입니다.
그런 방식이 정리 (Organization) 차원에서는 가끔 작동할 수 있습니다. 하지만 판단 (Judgment) 차원에서는 거의 작동하지 않습니다.
AI는 자료를 사용하는 데는 능숙합니다. 하지만 특정 자료가 왜 살아남을 가치가 있는지 결정하는 데는 신뢰도가 떨어집니다.
만약 당신이 10개의 회의록을 준다면, AI는 예의 바르게 그 10개를 모두 포함할 수도 있습니다. 만약 방대한 연구 자료 덤프 (research dump)를 준다면, 모든 소스를 동일한 비중으로 평탄화 (flatten) 해버릴 수도 있습니다. 만약 당신이 작업하는 동안 했던 모든 생각을 준다면, 그 혼란스러움을 그대로 보존하여 그 혼란이 마치 전문적인 것처럼 들리게 만들 수도 있습니다.
이것은 지능의 실패가 아닙니다. 기준 (criteria) 의 부재입니다.
무엇이 이 글을 위한 증거로 간주될지는 인간이 결정해야 합니다.
간단한 표가 도움이 됩니다:
| 자료 | 유지 여부? | 이유 |
|---|---|---|
| 포스트를 촉발한 사건 | 예 | 독자에게 구체적인 페인 포인트 (pain point) 를 제공함 |
| ... |
중요한 움직임은 표를 만드는 것이 아닙니다. 이유를 강제하는 행위 그 자체입니다.
"이것은 흥미롭다"는 것으로는 부족합니다. "이것은 독자가 핵심 요점 (takeaway) 을 믿거나 활용하는 데 도움이 된다"라고 해야 충분합니다.
때때로 저는 여전히 AI에게 먼저 엉망인 더미로부터 초안을 작성해 달라고 요청합니다. 더미 안에 무엇이 들어있는지 아직 모를 때는 그것이 유용할 수 있습니다. 하지만 저는 그 첫 번째 초안을 기사가 아니라 인벤토리 (inventory, 목록) 로 취급합니다. 그런 다음 수동으로 내용을 쳐냅니다.
첫 번째 초안은 "어떤 자료가 존재하는가?"에 답합니다.
인간의 편집은 "어떤 자료가 적절한가?"에 답합니다.
이것은 서로 다른 질문입니다.
결정 4: 무엇이 먼저 나와야 하는가?
어떤 일이 일어난 순서가 독자가 그것을 배워야 하는 순서인 경우는 드뭅니다.
작업은 시간 순서대로 진행됩니다. 이해는 종종 그렇지 않습니다.
회의는 맥락 (context) 으로 시작하여, 토론을 거쳐, 결정으로 끝납니다. 회의록의 독자는 보통 결정을 가장 먼저 알고 싶어 합니다. 버그 조사 (bug investigation) 는 혼란에서 시작하여, 막다른 길을 거쳐, 원인으로 끝납니다. 장애 보고서 (incident write-up) 의 독자는 보통 고고학적 추적 (archaeology) 을 하기 전에 영향과 해결책을 먼저 알고 싶어 합니다.
AI는 당신이 제공한 순서를 그대로 유지하는 경우가 많은데, 그것이 합리적인 행동이기 때문입니다. 당신의 노트가 연대기적이라면, 초안도 연대기적일 수 있습니다. 당신의 브레인 덤프 (brain dump) 가 배경 설명으로 시작한다면, 기사도 배경 설명으로 시작할 수 있습니다.
그것이 바로 독자들이 목적지에 도달하기 전에 로비에 갇혀버리게 되는 방식입니다.
초안을 작성하기 전에, 저는 첫 번째 움직임을 선택합니다:
- 독자가 고통을 느껴야 한다면 실패(failure)부터 시작하세요.
- 독자가 바쁘다면 결론(conclusion)부터 시작하세요.
- 독자가 이미 잘못된 것을 믿고 있다면 대조(contrast)부터 시작하세요.
- 독자가 워크플로 (workflow)를 복사하러 왔다면 체크리스트 (checklist)부터 시작하세요.
이 글의 경우, 첫 번째 움직임은 실패입니다. AI에게 더 잘 쓰라고 요청하는 것은 문제를 해결하지 못했습니다.
이것이 중요한 이유는 타겟 독자 또한 아마도 똑같은 해결책을 시도해 보았을 것이기 때문입니다. 만약 제가 "편집 브리프 (editorial brief)"에 대한 깔끔한 정의부터 시작했다면, 이 글은 이론처럼 느껴졌을 것입니다. 실패한 수리 과정부터 시작함으로써 이 워크플로 (workflow)가 노력 끝에 얻어진 결과라는 느낌을 줍니다.
순서는 장식이 아닙니다. 순서는 논증 (argument)의 일부입니다.
결정 5: AI에게 무엇을 결정하도록 허용할 것인가?
이것은 너무 당연해 보이기 때문에 사람들이 건너뛰는 결정입니다.
"나는 글을 쓰기 위해 AI를 사용한다." 좋습니다. 하지만 글쓰기의 어느 부분을 말인가요?
글쓰기는 문장 그 이상을 포함합니다. 독자를 설정하고, 주장 (claim)을 선택하며, 무엇을 삭제할지 결정하고, 논증 (argument)의 순서를 정하며, 예시를 선택하고, 톤 (tone)을 설정하며, 언어를 다듬는 과정이 모두 포함됩니다.
이러한 작업들은 위임 (delegate)하기에 똑같이 안전한 것이 아닙니다.
제가 현재 나누고 있는 기준은 다음과 같습니다:
| 작업 | 내가 유지함 | AI가 도울 수 있음 |
|---|---|---|
| 독자 선택 | 예 | 대안 제안 |
| ... |
핵심 문구는 "AI가 소유한다 (AI owns)"가 아니라 "AI가 도울 수 있다 (AI can help)"입니다.
저에게 강력한 의견이 있다면, 실행 (execution)을 위임할 수 있습니다. 하지만 아직 의견이 없다면, 위임은 대개 잘못된 것을 외주 주는 것을 의미합니다.
유용한 테스트 방법은 모델의 제안을 제가 빠르게 거절할 수 있는지 여부입니다.
만약 AI가 문장을 제안했을 때 제가 "아니요, 그건 너무 판매용 문구 (salesy) 같아요"라고 말할 수 있다면, 그 영역은 위임하기에 안전한 영역입니다. 저에게 기준 (standard)이 있기 때문입니다. 반면, AI가 글의 타겟 독자를 제안했을 때 제가 그것에 이의를 제기할 능력도 없이 "그럴듯하네"라고 생각한다면, 저는 아마 너무 일찍 위임해 버린 것입니다.
위임은 인간이 취향 (taste), 맥락 (context), 그리고 거절할 수 있는 능력을 갖춘 곳에서 가장 잘 작동합니다.
인간이 아직 내리지 못한 판단을 모델이 대신 내려주기를 바라는 곳에서는 제대로 작동하지 않습니다.
내가 사용하는 5줄 브리프 (five-line brief)
전체 버전은 다음과 같습니다.
대상 (Audience): 현재 겪고 있는 혼란을 포함한 특정 인물 또는 역할.
핵심 요점 (Takeaway): 독자가 글을 읽은 후 무엇을 할 수 있어야 하는지 또는 무엇을 믿어야 하는지를 나타내는 한 문장.
사용할 자료 (Material to use): 핵심 요점을 직접적으로 뒷받침하는 예시, 로그, 노트 또는 사실.
...
그리고 이 기사를 위해 작성된 예시 버전은 다음과 같습니다:
대상 (Audience): AI로 작성한 게시물이 세련되어 보이지만 일반적(generic)이라고 느껴지는 개발자 또는 팀 리드.
핵심 요점 (Takeaway): 더 나은 프롬프트는 더 많은 문구 기술이 아니라, 인간의 편집적 결정(editorial decisions)에서 시작된다.
사용할 자료 (Material to use): 실패한 세련된 초안, 주간 보고서 예시, 자료 편집 예시, 그리고 재사용 가능한 브리프.
...
이 내용 중 프롬프트 마법 (prompt magic)에 해당하는 것이 얼마나 적은지 주목해 보세요.
특별한 탈옥 (jailbreak)도 없습니다. 숨겨진 역할극 (roleplay)도 없습니다. 거대한 시스템 메시지 (system message)도 없습니다.
브리프는 의도적으로 지루하게 작성되었습니다. 이는 누락된 결정 사항들을 가시적인 텍스트로 강제하기 위함입니다.
그 이후에 프롬프트는 간단해질 수 있습니다:
아래의 브리프를 사용하여 dev.to 기사 초안을 작성하세요. 대상(audience)과 핵심 요점(takeaway)은 변경하지 마세요. 문구, 섹션 전환, 예시는 개선할 수 있지만, 먼저 명시하지 않고는 독자, 핵심 주장, 또는 자료 선택을 변경하지 마세요.
[여기에 브리프 삽입]
브리프를 더 명확하게 작성할수록, 프롬프트는 덜 극적이어도 됩니다.
전후 비교: 모호한 프롬프트 vs 편집 브리프
다음은 예전의 저에게 세련되지만 기억에 남지 않는 기사를 만들어 주었던 종류의 프롬프트입니다:
AI를 글쓰기에 활용하는 방법에 대해 이해하기 쉬운 기사를 작성하세요. 실용적이고 매력적으로 만드세요. 예시와 결론을 포함하세요.
이 프롬프트에는 잘못된 내용이 하나도 없습니다. 단지 결정 사항이 비어 있을 뿐입니다.
독자는 누구인가? 알 수 없음.
읽은 후에 무엇을 해야 하는가? 알 수 없음.
어떤 예시가 중요한가? 알 수 없음.
무엇이 먼저 나와야 하는가? 알 수 없음.
AI가 변경해서는 안 되는 것은 무엇인가? 알 수 없음.
이제 이를 브리프 기반 버전과 비교해 보세요:
대상 (Audience): 팀 업데이트 초안을 작성하기 위해 AI를 사용하지만, 계속해서 일반적인 보고서만 받는 개발자.
핵심 요점 (Takeaway): 초안을 작성하기 전에 독자, 핵심 요점, 자료, 순서, 그리고 AI의 범위를 정의해야 합니다.
사용할 자료 (Material to use): 주간 보고서 예시, 회의록 예시, 그리고 5줄 브리프 (five-line brief).
...
두 번째 프롬프트가 더 나은 이유는 더 길기 때문이 아닙니다. 판단 (judgment)이 이미 포함되어 있기 때문입니다.
AI는 더 이상 무엇이 중요한지 결정해 달라는 요청을 받지 않습니다. 이미 존재하는 결정을 표현해 달라는 요청을 받는 것입니다.
사후에 AI 초안을 검토하는 방법
동일한 다섯 가지 항목은 검토 속도 또한 높여줍니다.
브리프 (brief)가 없으면, 초안 전체를 다시 읽으며 "이게 좋은가?"라고 물어야 합니다. 그 질문은 너무 방대합니다. 그것은 검토를 취향 판정 (taste arbitration)으로 변질시킵니다.
브리프가 있으면, 다음과 같은 다섯 가지 작은 질문들을 확인할 수 있습니다:
- 의도된 독자를 위해 작성되었는가?
- 모든 섹션이 핵심 요점 (takeaway)을 뒷받침하는가?
- 모델이 삭제했어야 할 자료를 그대로 유지했는가?
- 도입부의 흐름이 선택된 순서와 일치하는가?
- 모델이 위임된 범위 (delegated scope) 밖의 결정을 내렸는가?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기