안녕하세요. 커뮤니티 서비스 Product Owner로 일하고 있는 marie입니다.
이 글에서는 제가 AI 요약 프롬프트를 직접 설계하면서, “게시글을 3줄로 요약해줘”에서 시작해 실제 서비스에 적용 가능한 프롬프트를 만들기까지의 과정을 담았습니다. 기획부터 배포까지 일주일이 걸렸는데요, 그 일주일간의 여정을 순서대로 공유해볼게요.
”게시글을 3줄로 요약해줘”로 시작했습니다
커뮤니티 서비스의 체류시간을 개선하기 위해, 게시글 상단에 AI 요약을 노출하는 기능을 기획했어요. 구글 디스커버에서 유입된 사용자가 10초 안에 “이 글을 읽을 가치가 있겠다”고 느끼도록 하는 게 목표였습니다.
처음에는 간단할 줄 알았어요.
게시글을 3줄로 요약해줘.
결과는 어떤 글이든 비슷한 톤의 밋밋한 요약이었습니다. 틀린 건 없는데, 읽어도 “그래서 뭔데?”라는 반응만 나왔어요.
여기서부터 프롬프트를 본격적으로 다듬기 시작했습니다.
Step 1. 목표부터 다시 정의하기
가장 먼저 한 건, 당근마켓 AI팀의 책 *《당근 서비스 AI는 어떻게 만들어지나》*를 읽은 거였어요. 이 책에서 가장 와닿았던 문장이 있었습니다.
“사용자 경험이 중요한 LLM 중심 서비스에서는 프롬프팅에 UX가 충분히 반영되어야 한다. 말투, 절대 사용하지 말아야 할 표현, 반드시 포함해야 할 정보, 글의 구조 등 세세한 가이드가 프롬프팅에 녹아있어야 한다.”
“3줄로 요약해줘”가 왜 안 됐는지 바로 이해됐어요. AI에게 뭘 만들지만 시켰지, 왜 만드는지, 누구를 위한 건지 알려준 적이 없었거든요.
그래서 목표를 먼저 명확히 정의했습니다.
| 질문 | 답변 |
|---|---|
| 무엇을 만드는가? | 게시글 본문 상단에 노출할 3줄 요약 |
| 왜 만드는가? | 10초 이내 “읽고 싶다” 동기 부여 → 이탈 방지 |
| 누구를 위한 것인가? | 구글 디스커버 유입 유저 (99% 모바일) |
이 3가지를 정의하고 나니, 프롬프트에 뭘 넣어야 하는지가 훨씬 명확해졌어요.
Step 2. 원칙과 금지 표현 만들기
목표가 잡히니까, “좋은 요약”과 “나쁜 요약”의 기준이 생겼어요. 이걸 구체적인 원칙으로 정리했습니다.
핵심 원칙 (일부):
| 원칙 | 체크 포인트 |
|---|---|
| 글의 핵심 주제 | 2초 만에 주제 전달되는가 |
| 독자가 얻을 가치 | ”나한테 도움 되겠다” 느낌이 드는가 |
| 스크롤 동기 | ”오 궁금하다” 느낌을 주는가 |
| 구체성 확보 | 숫자, 공식, 핵심 인사이트가 있는가 |
| 제목보다 구체적 | 제목 반복이 아니라 한 단계 더 깊은 정보인가 |
금지 표현도 구체적으로 정의했어요:
| 금지 유형 | 예시 | 이유 |
|---|---|---|
| 막연한 질문형 | ”~것이 뭔지 알 수 있어요” | 가치 전달 실패 |
| 어려운 전문 용어 | ”근저당권”, “GTX” | 신규 유저 이해 어려움 |
| 제목 단순 반복 | 제목과 똑같은 정보 | 요약의 존재 가치 없음 |
| 비유/은유 표현 | ”눈앞의 파도” | 직관적 이해 방해 |
| 본문에 없는 내용 | 허위 정보 | 기대-콘텐츠 불일치 |
여기서 중요했던 건 Bad → Good 예시를 함께 만든 것이에요.
| Bad | Good | 이유 |
|---|---|---|
| ”먼저 해야 할 단계가 있어요" | "10억 공식: ‘모으기 → 불리기’, 순서가 핵심이에요” | 글에 공식이 있으면 숨기지 말고 보여주기 |
| ”해지하면 돌려받을 수 없는 것이 뭔지 알 수 있어요" | "10년 쌓은 시간, 해지하면 0부터 다시예요” | 정답은 숨기되 힌트로 가치 전달 |
원칙만 나열하면 AI가 해석을 잘못할 수 있어요. “이건 안 되고, 이건 되는 거야”를 예시로 보여주는 게 훨씬 효과적이었습니다.
Step 3. 예시를 준비하니 바로 성공했습니다
당근AI 책에서 또 하나 배운 게 있었어요.
“좋은 예시를 함께 주면 AI가 프롬프팅의 의도를 훨씬 명확하게 이해하고 성능도 더 좋아집니다.”
그래서 콘텐츠 유형별로 Few-shot 예시를 준비했어요. 실제 게시글을 골라서 “이 글의 이상적인 요약은 이거야”라는 정답을 직접 만든 거예요.
집중분석 예시 (5개 준비):
제목: "의외로 잘 모르는 제2의 송파, 근데 무려 10억이나 싼 여기가 어디냐면"
• 송파 바로 옆 + 재개발 예정, '제2의 송파' 이 지역이 어딘지 알 수 있어요
• 송파보다 10억 넘게 싼 이유를 알 수 있어요
• 새 지하철 노선 3개 예정, 왜 지금 주목해야 하는지 알 수 있어요
최신이슈 예시 (3개 준비):
제목: "2026년 청약 유망단지 top 10"
• 2026년 서울 청약 유망단지 10곳, 반포 30억부터 신림 14억까지 가격대별로 정리했어요
• 단지별 실투자금과 입지 분석, 놓치면 후회할 정보가 한눈에 정리되어 있어요
• 보너스: 3기 신도시 5곳, 교산 13억~왕숙 10억 분양가까지 확인할 수 있어요
결과는 놀라웠어요. 집중분석과 최신이슈는 첫 시도에 성공했습니다. 예시를 보고 AI가 패턴을 바로 학습한 거예요.
“됐다, 이대로 전체 유형에 적용하면 되겠다” — 이때까지만 해도 그렇게 생각했어요.
Step 4. 경험담에서 같은 원칙이 안 통했습니다
문제는 경험담 유형이었어요.
같은 원칙, 같은 프롬프트 구조인데 경험담 글에서는 계속 실패했습니다. AI가 만든 요약을 볼 때마다 “핵심 메시지가 약하다”, “별로”라는 판단이 나왔어요.
실패한 요약 예시:
“재테크를 시작하기 전 준비해야 할 것들을 알 수 있어요” “투자 과정에서 마주할 현실을 알 수 있어요”
틀린 건 없어요. 그런데 클릭하고 싶지 않았습니다.
왜 안 되는 건지 한참 고민했는데, 결국 원인은 이거였어요.
정보 전달형 글과 경험 공유형 글은 요약의 목적 자체가 다르다.
| 유형 | 요약의 목적 | 핵심 패턴 |
|---|---|---|
| 집중분석/최신이슈 | ”이 글에 X 정보가 있다” 알려주기 | ”~을 알 수 있어요” |
| 경험담 | ”이 사람의 경험이 나와 연결된다” 느끼게 하기 | ”~했어요”, “~겪었어요” |
정보 전달형에서 성공했던 “~을 알 수 있어요” 패턴을 경험담에도 그대로 적용한 게 문제였어요. 경험담은 정보가 아니라 공감이 핵심인데, 정보 전달 톤으로 쓰니까 공감이 안 생겼던 거죠.
Step 5. 유형별로 원칙을 분리했습니다
그래서 경험담 전용 원칙을 새로 만들었어요.
경험담 3줄 구조:
| 줄 | 역할 | 패턴 |
|---|---|---|
| 1줄 | 경험의 핵심 결과 | ”~했어요” (구체적 숫자 + 결과) |
| 2줄 | 그 경험에서 배운 교훈 | ”~이 달랐어요” / “~이 핵심이었어요” |
| 3줄 | 독자가 적용할 수 있는 것 | ”~을 알 수 있어요” / “~까지 공유해요” |
이걸 적용하니 결과가 달라졌어요.
Before (정보 전달 톤):
“투자 경험담을 알 수 있어요”
After (경험 공유 톤):
“월급 200만원으로 3년 만에 종잣돈 5천만원을 만들었어요”
Before:
“성공하는 사람의 비결을 알 수 있어요”
After:
“3번 실패하고 4번째에 깨달은 ‘한 가지’가 달랐어요”
같은 글인데 톤만 바꿨을 뿐이에요. 그런데 “읽고 싶다”는 느낌이 확 달라졌습니다.
Step 6. 중간 과정을 출력해서 디버깅했습니다
마지막으로 중요했던 건 프롬프트 디버깅이에요.
요약 품질이 안 나올 때, “왜 이렇게 쓴 거지?”를 추측하는 게 가장 힘들었거든요. 이것도 당근AI 책에서 힌트를 얻었어요.
“중간 과정을 명확히 드러내고, 결과물에도 함께 출력하도록 했더니 어디에서 수선해야 하는지 쉽게 알 수 있었습니다.”
그래서 프롬프트에 중간 단계를 명시했어요.
1. 게시글을 읽고 핵심 메시지를 추출하세요 → <핵심정보>에 저장
2. 콘텐츠 유형을 판단하세요 (정보전달형 / 경험공유형) → <유형>에 저장
3. <유형>에 맞는 원칙을 적용해 요약을 작성하세요
이렇게 하니까, 요약이 이상할 때 어느 단계에서 문제인지 바로 알 수 있었어요.
- AI가 경험담을 정보전달형으로 판단했다면 → 유형 판단 기준을 수정
- 유형은 맞게 판단했는데 톤이 안 맞다면 → 해당 유형의 문장 패턴을 수정
최종 결과만 보면 블랙박스지만, 중간 과정을 보면 어디를 고쳐야 하는지 명확해집니다.
돌아보니, 전부 기획이었습니다
일주일간의 과정을 돌아보면, 제가 한 일은 이거였어요.
- 목표를 정의했고 (무엇을, 왜, 누구를 위해)
- 원칙을 세웠고 (좋은 요약 vs 나쁜 요약의 기준)
- 예시를 만들었고 (이상적인 결과물을 직접 작성)
- 실패하면 원인을 분석했고 (같은 원칙이 왜 안 통하는지)
- 유형별로 원칙을 분리했고 (한 가지 방법이 모든 상황에 통하지 않음)
- 디버깅 구조를 만들었습니다 (문제를 추적할 수 있게)
코드를 한 줄도 쓰지 않았어요. 전부 PM이 이미 하고 있는 일이었습니다. 요구사항 정의, 품질 기준 수립, QA 시나리오 작성, 피드백 기반 이터레이션 — 프롬프팅은 이걸 AI를 대상으로 한 것뿐이었어요.
결과: 실제로 지표가 움직였습니다
이렇게 만든 프롬프트를 실제 서비스에 적용하고, A/B 테스트를 돌렸어요.
결과는 체류시간과 가입전환율 모두 통계적으로 유의미한 개선이 나왔습니다. 특히 가입전환율은 예상 밖이었어요. “요약이 체류시간에는 도움이 되겠지만, 가입까지 영향을 줄까?” 반신반의했거든요. 그런데 좋은 요약이 “이 글 읽을 가치가 있겠다” → “더 보고 싶다” → “가입해야겠다”로 자연스럽게 이어지더라구요.
“3줄로 요약해줘”에서 시작한 프롬프트가, 6단계의 기획 과정을 거치니 실제 비즈니스 지표를 움직이는 결과가 되었습니다.
한계: 솔직히 안 되는 것들
물론 만능은 아니에요.
피드백은 사람이 줘야 합니다. 하지만 검증은 자동화할 수 있어요. 처음에는 “요약이 원문과 맞는지” 같은 정합성 검증을 매번 사람이 직접 해야 한다고 생각했어요. 하지만 어느 정도 원칙이 잡히면, “요약의 각 문장이 본문에 실제로 있는 내용인지 검증해줘”라는 규칙을 에이전트에게 맡길 수 있더라구요. 사람이 할 일은 원칙을 만드는 것이고, 그 원칙에 따른 검증은 AI가 대신할 수 있었습니다.
완벽한 프롬프트는 없어요. 프롬프트도 프로덕트처럼 계속 개선해야 합니다. 새로운 유형의 글이 들어오면 기존 프롬프트가 안 통할 수 있거든요. “한 번 만들어두면 끝”이라는 생각이 가장 위험했어요.
2번 실패하면 방법을 바꿔야 해요. 경험담에서 4번 연속 실패했을 때 같은 원칙으로 계속 시도한 건 시간 낭비였습니다. 성공 사례(집중분석)와 비교해서 “뭐가 근본적으로 다른지”를 먼저 찾았어야 했어요.
마치며
돌아보면 핵심은 간단했어요.
AI에게 추상적으로 시키면 추상적인 결과가 나옵니다.
“요약해줘” 대신, 목표를 정의하고, 원칙을 세우고, 예시를 보여주고, 실패하면 원인을 분석하고, 유형별로 전략을 나눠야 했어요. 이건 코딩이 아니라 기획이었고, PM이 매일 하는 일이었습니다.
시작은 어렵지 않아요. 지금 하고 있는 업무 중 하나를 골라서, 위 과정을 한번 따라가 보시면 돼요.
“회의록 정리해줘” 대신
“이 녹음 내용을 바탕으로 3문장 요약, 주요 키워드 5개, 액션아이템(담당자·기한 포함)을 표 형태로 정리해줘.”
이 한 줄의 차이가, “AI 별로네”와 “AI 없이 어떻게 일했지?”를 가르더라구요.