어제도 챗GPT한테 회의록 요약을 시켰다가 세 번을 다시 시켰다.
처음엔 “이거 요약해줘” 하고 회의록을 통째로 붙여넣었다. 돌아온 건 내가 이미 아는 내용을, 그것도 뭉텅뭉텅 뭉개서 다시 말해주는 열 줄이었다. 나는 결정 사항이랑 누가 뭘 하기로 했는지가 궁금했는데, 답에는 “여러 안건에 대해 논의가 이루어졌다” 같은 말만 얌전히 앉아 있었다. 화면을 보다가 한숨이 났다. 또 이거네.
프롬프트를 다시 쓰는 일은 이제 내 일과의 절반쯤 된다. 예전 웹기획자 시절엔 요구사항 정의서를 붙들고 살았는데, 요즘은 프롬프트 창을 붙들고 산다. 그러다 알았다. 답이 안 나오는 건 대개 모델이 멍청해서가 아니라, 내가 뭘 원하는지 제대로 안 밝혀서였다.
답이 뭉개져 나오는 건 대부분 내 탓이었다
한동안은 모델 탓을 했다. 이 모델이 아직 부족한가, 유료로 바꿔야 하나, 이런 생각을 진지하게 했다.
아니었다. 세 곳(OpenAI·Anthropic·Google)의 공식 프롬프트 가이드를 뒤늦게 하나씩 읽어보니, 답이 안 나오는 흔한 원인은 “모델이 멍청해서”가 아니라 “지시가 모호해서”였다. Anthropic은 공식 가이드에서 AI를 “똑똑하지만 우리 회사 관행은 전혀 모르는 신입사원”이라고 부르라더라. 그 표현을 보고 좀 뜨끔했다. 나는 신입한테 배경 설명도 없이 “알아서 요약해줘”라고 던져놓고, 왜 내 마음을 모르냐고 답답해하던 사람이었다.
읽고 나서야 정리가 됐다. 답이 뭉개지는 건 대개 세 가지 중 하나였다. 뭘 원하는지 안 밝혔거나, 내 상황을 안 알려줬거나, 어떤 형식으로 달라고 안 정해줬거나. 이 세 개만 채워도 답이 달라졌다.
요구사항 정의서 쓰듯, 빈칸을 채워 넣었다
기획할 때 요구사항 정의서에는 빈칸이 정해져 있다. 누가 쓰는 기능인지, 왜 필요한지, 어떤 화면에서 어떻게 동작하는지. 그 칸이 비면 개발자가 되묻는다. 프롬프트도 똑같더라. 되묻는 대신 엉뚱한 답을 낼 뿐이지.
그래서 회의록 요약을 이렇게 다시 썼다. “너는 회의록을 정리하는 프로젝트 매니저야. 아래 회의록에서 결정된 사항, 담당자와 마감일, 다음 회의까지 확인할 것, 이 세 가지만 뽑아줘. 각 항목은 한 줄씩, 담당자 이름을 앞에 붙여서.” 이번엔 내가 원하던 게 나왔다. 논의가 어쩌고 하는 말은 사라지고, 누가 뭘 언제까지 하는지가 줄줄이 정리됐다.
바꾼 건 딱 네 가지였다. 역할을 줬고(“프로젝트 매니저야”), 초점을 좁혔고(결정·담당·확인할 것), 형식을 정했고(한 줄씩), 뺄 것을 알려준 게 아니라 넣을 것을 알려줬다. Anthropic은 “마크다운 쓰지 마” 대신 “부드럽게 이어지는 문단으로 써줘”처럼 하지 말라는 말보다 이렇게 하라는 말이 잘 먹힌다고 짚는데, 정말 그랬다.
Google Gemini 가이드도 비슷한 걸 예시로 든다. “캠핑에 대해 알려줘”는 뭉뚱그린 답을 부르지만, “캠핑 갈 때 꼭 챙길 5가지만 간단한 목록으로 줘”는 딱 떨어지는 답을 부른다고. 그러니까 “좋게”, “길게” 같은 주관적인 말을 “3문장 이하로” 같은 숫자로 바꾸라는 거다. 나는 이걸 읽고 내 프롬프트에서 “잘”, “적당히”, “깔끔하게” 같은 말부터 지웠다. 그 단어들이야말로 모델을 헤매게 하는 말이었다.
이미지 만들 때도 같은 걸 겪었다. 예전에 AI 이미지 생성 도구를 무료로 이것저것 써봤을 때도, “예쁘게 그려줘”로는 매번 밋밋한 게 나왔고 배경·구도·분위기를 못 박아야 원하는 게 나왔다. 글이든 그림이든 원리는 같았던 셈이다.
예시 하나 붙였더니 톤이 잡혔다
형식까지 정했는데도 톤이 안 맞을 때가 있다. 결과물이 너무 딱딱하거나, 반대로 너무 들뜬 광고 문구처럼 나오거나.
이럴 땐 예시를 붙인다. 내가 원하는 결과물과 비슷한 문장 두어 개를 프롬프트 안에 넣어주는 거다. Anthropic은 예시가 출력 형식과 톤을 가장 확실하게 잡는 방법 중 하나이고 3~5개가 적당하다고 본다. Google은 한발 더 나가서, 예시 없는 프롬프트는 효과가 떨어질 가능성이 높으니 되도록 항상 예시를 넣으라고 한다.
블로그 소개 문구를 뽑을 때 이걸 써봤다. 그냥 “소개 문구 써줘”로는 “혁신적인 인사이트를 제공합니다” 같은, 내가 절대 안 쓰는 말이 나왔다. 그래서 내가 예전에 쓴 문장 두 개를 붙여놓고 “이런 톤으로 세 개만 뽑아줘”라고 했더니, 그제야 내 말투에 가까운 게 나왔다. 예시는 설명 열 줄보다 강했다. 말로 “친근하게”라고 백 번 하는 것보다, 친근한 문장 하나를 보여주는 게 빨랐다.
여기서 하나 덧붙이면, 예시는 내 실제 상황과 비슷해야 하고 조금씩 다양한 게 좋다더라. 다 똑같은 예시만 넣으면 모델이 그 하나에만 갇힌다는 거다.
몇 번을 고쳐도 그대로면, 통째로 다시 쓴다
가장 오래 걸려서 알게 된 게 이거다. 답이 마음에 안 들 때 나는 늘 뒤에 한 줄씩 덧붙였다. “아 그거 말고”, “조금 더 짧게”, “아니 그 부분은 빼고”. 채팅창이 지저분해질수록 답도 같이 지저분해졌다.
이 방식이 왜 비효율적인지도 자료에서 확인했다. 사용자들이 흔히 빈 인사로 시작해 뒤에서 의도를 찔끔찔끔 덧붙이는데, 이건 원본을 통째로 다시 쓰는 것보다 못하다는 거다. Anthropic이 소개하는 대표 패턴은 오히려 “자기 교정”에 가깝다. 초안을 받고 → 어디가 부족한지 기준을 정해 짚고 → 그 기준으로 다시 요청하는 루프. 나는 이걸 알고 나서, 대화가 세 번 이상 꼬이면 미련 없이 첫 프롬프트로 돌아가 처음부터 새로 쓴다.
참, 복잡한 문제에서 자꾸 틀리면 “바로 답하지 말고 단계별로 따져본 다음 결론을 내줘”를 붙이는 것도 효과가 있다. 이건 체감이 아니라 연구로도 얼추 확인된 부분인데, 예시 없이 “단계별로 생각해보자”는 한 줄만 붙여도 추론 정확도가 올라간다는 결과가 있다더라. 다만 만능은 아니라서, 어떤 경우엔 오히려 편향을 키운다는 반론도 있고 아주 작은 모델에는 효과가 약하다고 한다. 그래서 나는 이걸 복잡한 계산이나 비교 판단이 필요할 때만 꺼내 쓴다.
정리하고 보니, 내가 프롬프트를 고칠 때 밟는 순서는 매번 비슷했다. 무엇을 원하는지 → 어떤 역할로 → 어떤 상황에서 → 어떤 형식으로. 요구사항 정의서의 빈칸이랑 거의 같은 순서다.
| 답의 증상 | 채워 넣은 칸 |
|---|---|
| 두루뭉술하다 | 초점·길이를 숫자로 못박기 |
| 톤이 안 맞는다 | 역할 주기, 예시 붙이기 |
| 내 상황과 동떨어졌다 | 배경·목적 알려주기 |
| 형식이 제멋대로다 | 표·목록·문단 중 하나로 지정 |
| 몇 번 고쳐도 그대로다 | 첫 프롬프트로 돌아가 통째로 새로 쓰기 |
처음 “요약해줘” 한 줄과, 조건을 채운 프롬프트를 나란히 놓고 보면 길이는 세 배쯤 길어졌다. 귀찮아 보이지만 실제론 세 번 다시 시키는 것보다 빨랐다. 손이 프롬프트 창 위에서 덜 헤매는 게, 요즘 내가 느끼는 가장 확실한 변화다.
