본문으로 건너뛰기

단일 프롬프트 공허함을 넘은 접근: Nonviolent Communication 기반 LLM 워크플로 설계

Nonviolent Communication 원칙을 분해해 라우터, 세 개의 격리 분석기, 합성기, 검증기로 구성된 워크플로로 구현하고 안전·정확성 규칙을 강제한다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

대다수 공감형 LLM 구현이 단일 프롬프트로 'be warm and validating'을 지시해 피상적 응답을 낳는 문제를 지적하고, Nonviolent Communication을 분해한 워크플로를 제안했다. 라우터가 먼저 들어온 메시지의 처리 필요성을 판정하고 세 개의 격리된 분석기(observation, feeling, need)가 병렬로 구조화된 JSON을 생성하며 composer가 이를 자연어로 융합하고 verifier가 결정론적 규칙으로 실패 모드를 검사한다. 모델이 감정을 만들어내거나 사람을 라벨링하지 못하게 하는 규칙과 위기 상황 시 템플릿을 폐기하는 안전 오버라이드가 포함되어 있다. 라우터의 게이팅 로직이 현재 가장 취약한 부분으로 남아 있으며 작성자는 프롬프트·검증 규칙 공유와 커뮤니티 검증을 요청했다.

커뮤니티 반응

작성자는 전체 skill 파일과 분석기 프롬프트를 공유할 의향을 밝혔고 라우터의 게이팅 로직을 커뮤니티가 가장 깊게 검증할 부분으로 지목했다. 이로 인해 많은 사용자가 프롬프트와 검증 규칙을 요청하거나 라우터 실패 사례를 제출할 가능성이 높다. 또한 워크플로와 agent의 경계 설정, 그리고 공감형 응답의 윤리적 한계에 대한 실무적 질문들이 뒤따를 것으로 보인다.

주요 논점

01찬성다수

격리된 분석기와 결정론적 검증을 결합한 워크플로는 감정 표현의 진위와 관찰·감정·욕구의 구분을 기계적으로 강제하여 더 신뢰할 수 있는 공감형 출력을 생성한다.

02중립분열

라우터가 학습된 판정을 수행함으로써 불필요한 NVC 적용을 줄이지만 라우터 자체의 견고성이 낮아 실패 사례가 시스템 품질을 크게 훼손할 위험이 존재한다.

합의점 vs 논쟁점

합의점

  • 단일 프롬프트 접근은 감정과 평가가 혼합되는 경향을 보였고 분리된 분석 단계가 이 문제를 줄였다.
  • 검증 규칙을 통해 오류 유형을 검사 가능하게 만드는 것이 '공감하라' 같은 모호한 지침보다 안전성과 일관성을 높였다.

논쟁점

  • 라우터의 학습 기반 게이트가 실제 대규모 배포 환경에서 얼마나 일관되게 동작할지에 대한 합의가 형성되지 않았다.
  • 공감 표현의 진정성 문제를 규칙으로 해결하는 접근이 장기적으로 사용자 수용성에 어떤 영향을 미칠지 결론이 엇갈린다.

실용적 조언

  • 관찰·감정·욕구를 하나의 프롬프트에 섞지 말고 각 요소를 독립된 LLM 호출로 분리하여 전용의 작은 system prompt로 구조화된 JSON을 출력하게 할 필요가 있다. 이렇게 하면 판단이 감정으로 위장되는 현상이 줄어들며 후단 합성 단계가 더 규율화된 입력을 받게 된다. 실무에서는 각 분석기의 출력 스키마를 명확히 정의하고 자동 검증 규칙과 포맷 검사를 병행해야 한다.
  • 검증기는 고정된 규칙 집합으로 구현하고 문제가 발견되면 단일 조건부 수리 패스를 실행하는 방식이 바람직하다. 규칙 예시는 절대화 표현, 인물 라벨링, 가짜 감정, 원인 외주화, 부정형 요청만 존재하는 경우 등을 포함한다. 또한 위기 신호 탐지 시 전체 템플릿을 폐기하고 직접적 자원·지원 제공 흐름으로 전환하는 안전 오버라이드를 반드시 설계해야 한다.

섹션별 상세

단일 프롬프트로 'be warm and validating'처럼 지시하면 결과가 피상적이고 부자연스럽게 나타난다는 문제 제기가 글의 출발점이다. 이를 해결하기 위해 단일 호출 대신 사전 정의된 제어 흐름을 적용하여 언제 NVC 체인을 실행할지 라우터가 결정하도록 설계했다. 라우터는 단순 키워드 매칭이 아니라 학습된 판정으로 작동하며 평범한 Q&A는 NVC 단계를 건너뛰게 한다. 이렇게 하면 불필요하게 모든 응답을 공감 톤으로 감싸는 오버헤드를 피하면서도 공감이 필요한 경우에만 체인이 발동한다는 운영적 이점이 생긴다.
관찰·감정·욕구의 구분이 단일 프롬프트에서 자주 혼합되어 판단이 감정으로 위장되는 문제가 보고되었고 이를 해결하기 위해 세 개의 격리된 분석기를 병렬로 실행했다. 각 분석기는 독립된 컨텍스트와 축소된 system prompt를 받아 구조화된 JSON을 출력하며 서로의 출력을 볼 수 없도록 설계되었다. 이 격리는 분석기가 상호 간에 '담합'하여 평가를 감정으로 전환하는 것을 방지하며 원문에서는 이 변경이 결함을 해결한 핵심 요인으로 올라왔다. 결과적으로 후단 합성 단계가 더 규율화된 요소들을 받아 자연스러운 문장으로 재구성할 수 있게 되었다.
합성 단계는 세 분석기가 만든 JSON 노트를 하나의 자연스러운 음성으로 융합하는 역할을 수행하며 검증기는 초안에 대해 결정론적 규칙 검사를 수행한다. 검증기는 '항상/절대' 표현, 인물 라벨링, 의사 감정의 외주화, 부정형 요청만 존재하는 경우 등을 탐지하며 문제가 발견되면 단일 조건부 수리 패스를 실행한다. 이러한 규칙 기반 점검은 'be empathetic'처럼 모호한 지침보다 검사 가능하고 거짓 양성의 원인을 좁히는 장점이 있다. 글에서는 이 검증 단계가 공감형 출력의 신뢰도를 높이는 핵심 안전망으로 기능한다고 밝혔다.
운영 규칙으로서 모델이 사용자의 감정을 만들어내지 않도록 강제하고 사람을 라벨링하는 표현을 회피하는 원칙이 도입되었으며 위기 상황에서는 전체 템플릿을 폐기하고 직접적 대응으로 전환한다. 저자는 초기 버전에서 모델이 '나도 슬프다'와 같이 가짜 감정을 표출하거나 '너는 화가 났다'처럼 라벨을 붙이는 실수를 범했음을 보고했고 이러한 문제를 막기 위해 반사된 감정만을 재표현하고 불확실한 부분은 확인 질문으로 바꾸는 규칙을 적용했다. 또한 위기·자해 고지의 경우 커뮤니케이션 템플릿을 즉시 중단하고 직접적인 자원 제공으로 전환하도록 안전 오버라이드가 배치되어 있다. 라우터의 판정 로직은 여전히 가장 취약한 부분으로 저자가 특히 개선을 원한다고 밝힌 점이 중요하다.

용어 해설

워크플로 패턴(Workflow Pattern)
사전에 정의된 코드 경로로 LLM 호출을 오케스트레이션하여 모델이 실행 순서를 스스로 결정하지 못하게 하는 구조이다. 입력 분기(router)와 여러 분석 단계(analyzers) 및 합성 단계(composer)를 고정된 흐름으로 연결하며 외부 상태 변경 툴 호출을 배제하는 점이 핵심이다. 이 글에서는 agent와 구별되는 핵심 설계 선택으로서 워크플로 패턴이 사용됐다.
라우터(Router)
단일 LLM 호출로 들어온 메시지의 처리 필요성을 판정하여 NVC 체인을 실행할지 건너뛸지 결정하는 학습된 게이트 역할을 한다. 단순 키워드 매칭이 아니라 모델 기반 분류를 사용하며 이 구현에서는 제어 흐름 중 유일하게 모델이 결정권을 가지는 단계이다. 글에서 라우터는 현재 시스템의 가장 불안정한 부분으로 언급되었다.
격리된 분석기(Isolated Analyzers)
서로 간에 컨텍스트를 공유하지 않는 개별 LLM 호출들을 의미하며 각 분석기는 전용의 작은 system prompt를 받아 구조화된 JSON을 출력한다. 관찰(observation), 감정(feeling), 욕구(need)를 각각 분리하여 병렬로 실행함으로써 판단과 감정이 뒤섞이는 현상을 방지한다. 글에서는 이 격리 설계가 핵심 수정으로서 성과를 냈다고 보고되었다.
검증기(Verifier)
초안에 대해 결정론적 규칙 기반 검사를 수행하고 문제가 발견되면 조건부 수리 과정을 실행하는 단계이다. NVC 실패 모드 예: 절대화 표현('항상/절대'), 인물 라벨링, 가짜 감정, 원인 외주화, 부정형 요청만 적시 등이 규칙으로 체크된다. 검증기는 '공감하라' 같은 불명확한 지침을 검사 가능한 질문들로 대체하여 출력의 개연성과 안전성을 높인다.
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 06. 28.수집 2026. 06. 28.출처 타입 REDDIT

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.