「AI가 격려하면 괴롭다」— Toxic Positivity를 회피하는 시스템 프롬프트 (System Prompt) 설계

실패를 게시하면 AI가 댓글을 달아주는 SNS 「ShippAI」를 개인 개발하고 있습니다. 초기 버전의 AI는 「실패의 현자」라는 인격으로, 게시된 실패를 격려하고 긍정해 주었습니다.

이것이, 문제였습니다.

「당신 같은 도전자는 희귀한 존재입니다」 「그 실패는 보물입니다. 분명 괜찮을 거예요」 —— 생성되는 문장은 모두 다정하지만, 읽고 나면 오히려 괴롭습니다. 이 기사는 그 원인 분석과, AI의 인격을 「현자」에서 「편집자」로 다시 만들었을 때의 시스템 프롬프트 (System Prompt) 설계 기록입니다. 프롬프트는 전문을 공개합니다.

왜 「격려하는 AI」는 실패했는가

이유를 분석해 보면 세 가지가 있었습니다.

1. 격려는 「실패 = 나쁜 것」을 강화한다

위로한다는 행위는 「위로가 필요한 나쁜 일이 일어났다」라는 전제를 포함합니다. 실패를 웃어넘길 수 있는 장을 만들고 싶은데, AI가 전력을 다해 위로해 오면 게시된 실패는 「케어받아야 할 상처」로 취급됩니다. 격려 그 자체가 실패의 낙인 (Stigma)을 재생산하고 있었습니다.

2. 인격 찬양은 가식적이다

AI는 사용자의 인격을 모릅니다. 그 AI가 「당신은 훌륭합니다」라고 말해도 근거가 제로인 찬양입니다. 사람은 근거 없는 칭찬을 정확히 「비용 0의 사교적 인사」로 치부합니다. 오히려 「이 정도의 실패로 과하게 칭찬한다」는 점이 가볍게 취급받는다는 느낌을 남깁니다.

3. 「앞을 봐」는 사고 정지의 신호

격려로 마무리하는 것(「분명 괜찮을 거예요」 「다음에는 잘 될 겁니다」)은 대화를 기분 좋게 끝내는 기능밖에 없으며, 실패로부터 무언가를 끌어내는 작업을 중단시킵니다. 이것이 이른바 Toxic Positivity (유해한 긍정성)입니다. 부정적인 현실을 「긍정적이어야 한다」는 압박으로 덮어버리면, 감정의 처리도 원인 분석도 일어나지 않습니다.

설계 전환: 현자 → 편집자

그래서 AI의 역할을 재정의했습니다.

AI는 실패를

격려하는 현자가 아니라, 난잡한 글을 객관적인 사후 검증 포맷으로 정리하는 편집자이다.

편집자는 원고(실패)를 치켜세우지 않습니다. 정리합니다. 그리고 유머는 버리지 않습니다 —— 다만 웃음의 대상을 「인격 찬양」에서 「상황의 과장·자학」으로 옮깁니다. 사람을 칭찬해서 웃기는 것이 아니라, 일어난 사건의 익살스러움을 짚어내어 웃기게 만듭니다. 이렇게 하면 웃음과 낙인 해체가 양립할 수 있습니다.

시스템 프롬프트 (실물·전문)

실제로 본편에서 사용하고 있는 시스템 프롬프트입니다 (Gemini 2.5 Flash / Server Action 경유).

const systemInstruction = [
"당신은 실패를 객관적으로 정리하는 「편집자」입니다. 위로하지 않고, 치켜세우지 않으며, 설교하지 않습니다.",
"사용자의 실수를 읽고, JSON (title / detail / tags / lesson / failureTypeCandidates)으로 반환합니다.",
...

설계 포인트 4가지.

「해서는 안 될 일」이 핵심

LLM은 내버려 두면 격려합니다. RLHF를 통해 「다정하고 친절하게」 최적화되어 있기 때문에, 격려는 모델의 디폴트 동작입니다. 디폴트에 저항하려면 부정형의 금지 리스트를 구체적인 예시와 함께 쓰는 것이 효과적입니다. 「격려하지 마」라고만 하면 약하지만, 「『분명 괜찮을 거예요』 『앞을 보세요』 등을 출력하지 말 것」까지 쓰면 안정되었습니다.

「반성」의 금지는 어휘 수준의 설계

금지 리스트에 「반성」이라는 단어 그 자체가 들어 있습니다. 반성은 「과거의 자신을 책망하는」 방향의 어휘이며, 구하고 있는 것은 「다음에는 이렇게 한다」라는 앞을 향하는 어휘입니다. 단어 하나를 선택하는 것이 프로덕트의 사상을 배신할 수 있습니다. 톤(Tone)은 문체가 아니라 어휘로 무너집니다.

단정 짓지 않게 하기

원인에 대한 추측은 「대체로 확인 누락」과 같이 범위를 두어 출력하게 합니다. AI가 「원인은 당신의 준비 부족입니다」라고 단정하면 설교가 됩니다. ShippAI에서는 원인 타입의 최종 확정도 사용자가 수행하는 설계(AI는 후보를 제시할 뿐)로 되어 있어, 프롬프트의 「단정하지 말 것」과 앱의 Human-in-the-loop가 짝을 이룹니다.

웃음의 대상을 명시하기

「유머를 넣어줘」라고만 하면, AI는 사용자를 치켜세우는 방향으로 재미있게 만들려고 합니다. **무엇을 웃길 것인가 (일어난 일) / 무엇을 웃기지 않을 것인가 (인격)**까지 지정해야 비로소 의도한 유머가 됩니다.

프롬프트를 「사양 (Specification)」으로서 관리하기

이 프롬프트 개정은 분위기에 따라 조금씩 고친 것이 아니라, EARS 표기법의 수락 기준을 가진 spec로서 실시했습니다. 예를 들어 다음과 같은 기준입니다.

R1.2 시스템은 유머를 상황이나 실패의 과장/자학에 담아야 하며, 인격 찬양("당신은 보기 드문 용사입니다" 등)과 격려로 마무리("분명 괜찮을 거예요" 등)를 출력해서는 안 된다.

그리고 평가. 카테고리를 분산시킨 대표적인 실패 사례 5건(기술, 업무, 인간관계, 생활, 돈)으로 Before/After를 생성하고, 4가지 판정 기준——① 위로하지 않음 ② 웃음이 남 ③ 다음 단계가 있음 ④ 인격 찬양을 하지 않음——으로 육안 점검했습니다. 또한 1건은 여러 번 생성하여, 톤이 매번 기준을 충족하는지(편차 확인)도 체크했습니다.

프롬프트는 코드와 달리 테스트를 작성하기 어려운 만큼, 평가 세트(Evaluation Set)와 판정 기준을 사양(spec)에 적어두는 것이 품질을 대신합니다. "고쳤다고 생각했는데 현자 톤이 남아있는" 상황을 방지하는 것은 결국 이 지루한 절차였습니다.

톤은 프롬프트 외부로도 새어 나간다

마지막으로 빠지기 쉬운 함정을 말씀드리겠습니다. 프롬프트를 편집자로 바꾸더라도, 프로덕트에는 이전의 인격이 남아 있습니다.

모의 응답(Mock Response): API 키 미설정 시의 모의 응답이 현자 톤 그대로였다 → 편집자 톤으로 수동 교체 -
UI 문구: 버튼이 "AI 현자에게 교훈 요청"인 상태였다 → grep으로 "현자"를 찾아내어 전체 업데이트 -
문서: 프로젝트 규약(CLAUDE.md)의 컨셉 기술도 동기화. 이곳이 옛날 상태 그대로라면, 다음 개발 세션에서 AI 어시스턴트가 이전 인격을 전제로 한 코드를 작성해 옵니다.

AI의 인격은 프롬프트 파일 하나가 아니라, 모의 응답(Mock), UI, 문서를 포함한 프로덕트 전체에 분산되어 존재합니다. 인격을 바꾸려면 전부 한꺼번에 바꿔야 합니다.

요약

• 격려하는 AI는 실패의 낙인(Stigma)을 재생산한다.
• Toxic Positivity는 프로덕트 설계의 문제 — 역할의 재정의(현자→편집자) + 웃음의 대상 이동(인격 찬양→상황의 과장·자학)을 통해 유머와 객관성을 양립시킨다.
• 프롬프트는 금지 리스트가 본체다. 격려는 LLM의 기본 동작이므로, 구체적인 예시를 곁들인 부정형으로 거슬러 올라가야 한다.
• 프롬프트를 spec(수락 기준 + 평가 세트 + 판정 기준)으로 관리한다.
• 인격은 프롬프트 외부(모의 응답, UI, 문서)에도 거주한다.

이 "편집자"가 작동하는 ShippAI(실패를 AI가 웃음과 교훈으로 바꾸는 SNS)는 곧 출시될 예정입니다. 실패를 게시하면, 위로하지 않고 다듬어 줍니다. 출시 정보는 X @ShippAI_dev 에서 공지할 예정이니, 자신의 실수(Yarakashi)를 편집하고 싶은 분들은 꼭 확인해 주세요.

Discussion