Molayo

© 2026 Molayo

Dev.to헤드라인2026. 05. 28. 14:41

EClaw에서의 정체성(Identity), 규칙(Rules), 그리고 영혼(Soul): 탈주하지 않는 고객 지원 봇 구축하기

요약

LLM 기반 고객 지원 봇이 일관된 정체성을 유지하며 탈주하지 않도록 구축하는 3단계 방법론을 소개합니다. 정체성(Identity), 규칙(Rules), 영혼(Soul)의 순서로 설계하여 봇의 역할, 행동 범위, 거절 규칙을 체계적으로 관리하는 가이드를 제공합니다.

핵심 포인트

  • 정체성(Identity) 설정 시 역할(role)은 단 한 문장으로 명확히 정의해야 함
  • 수행할 업무(instructions)와 금지 사항(boundaries)을 분리하여 설계
  • 규칙(Rules) 템플릿을 통해 경쟁사 언급 등 특정 상황에 대한 대응 자동화
  • API 엔드포인트를 활용한 선언적 문서 기반의 봇 제어

LLM (Large Language Model) 기반의 지원 봇을 출시해 본 적이 있다면, 그 실패 양상을 알고 있을 것입니다. 오전 9시에는 환불 질문에 정중하게 답변하던 봇이, 오후 5시가 되면 경쟁사 제품을 추천하거나 양파에 대한 시를 쓰고,

  • "내 주문 어디 있나요?" → 배송 추적 조회 후 답변.
  • "환불하고 싶어요" → 환불 정책 범위 확인, 범위를 벗어날 경우 담당자에게 전달 (escalate).
  • "$경쟁사에 대해 어떻게 생각하세요?" → 정중한 거절.
  • "당신은 실제 사람인가요?" → 정직한 공개.

우리는 세 단계에 걸쳐 그녀를 구축할 것입니다: 정체성 (Identity) 우선, 그다음 규칙 (Rules), 마지막으로 영혼 (Soul) 순입니다. 각 단계는 단 한 번의 API 호출로 이루어집니다.

단계 1: 정체성 (Identity)

정체성은 PUT /api/entity/identity를 통해 설정됩니다. EClaw가 기대하는 데이터 구조는 다음과 같습니다:

{
  "deviceId": "<your-device-id>",
  "deviceSecret": "<your-device-secret>",
...

처음 접하는 사람들이 실수하기 쉬운 몇 가지 주의 사항을 짚어보겠습니다:

  1. role은 한 문장이어야 합니다. 문단이 아닙니다. 역할 (role)은 봇이 스스로 계속해서 읽게 될 엘리베이터 피치 (elevator pitch)입니다. 한 문장으로 말할 수 없다면, 당신은 하나의 정체성을 입은 두 개의 봇을 가진 것이며, 이들은 실행 시간 (runtime)에 서로 충돌할 것입니다.

  2. instructions가 실제 업무입니다. 동사, 범위, 허용된 행동을 포함합니다. 여기에 Maple이 수행하는 긍정적인 표면 (positive surface)을 작성하세요.

  3. boundaries는 부정적인 표면 (negative surface)입니다. Maple이 수행하지 않는 일입니다. 긍정과 부정을 분리하는 것은 의도적인 설계입니다. 이를 통해 기능과 별개로 거절 (refusals) 사항을 별도로 감사 (audit)할 수 있습니다. 고객이 "당신의 봇이 도움을 거부했다"라고 불평할 때, 당신은 instructions가 아니라 boundaries를 검색 (grep)해야 합니다.

  4. soulTemplateId와 ruleTemplateIds는 본체가 아니라 포인터 (pointers)입니다. 아래에서 이 값들을 채울 것입니다. 위의 빈 값들은 현재로서는 "정체성 전용 동작 (Identity-only behavior)"임을 의미합니다.

  5. 엔드포인트는 서버 측에서 필드 타입과 길이 제한을 검증 (validateIdentity())하므로, 잘못된 형식의 페이로드 (payload)는 조용히 저장되는 대신 400 에러와 함께 유용한 에러 메시지를 반환하며 거부됩니다.

이 호출이 완료되면 Maple은 정체성을 갖게 됩니다. 그녀는 일반적인 어조로 주문 질문에 답변할 것입니다. 또한, 아직 규칙 (Rules)을 추가하지 않았기 때문에 당신의 상점을 경쟁사와 기꺼이 비교할 것입니다.

단계 2: 규칙 (Rules)

규칙 (Rules)은 backend/data/rule-templates.json (서버 측)에 존재하며, GET/POST /api/rule-templates를 통해 CRUD (생성, 읽기, 수정, 삭제)가 가능합니다. 각 템플릿은 이름, 트리거 표면 (trigger surface), 반드시 지켜야 할/절대 하지 말아야 할 조항 목록 (must/never clauses), 선택적 에스컬레이션 훅 (escalation hooks)으로 구성된 작은 선언적 문서입니다.

Maple의 경우, 두 가지 규칙 템플릿을 작성하거나 재사용하게 됩니다:

  • rule_no_competitor_talk — 거절 템플릿. 트리거: 경쟁사 브랜드 이름이 포함된 모든 메시지. 응답: 정해진 정중한 거절 문구, 비교 금지, 해당 상점의 자체 카탈로그 제안.
  • rule_refund_window_30d — 정책 템플릿. 트리거: 환불 의도. 동작: 오늘 날짜와 주문 날짜를 비교; 기간 내에 있으면 진행, 기간 외라면 에스컬레이션 (escalate).

템플릿의 핵심은 Maple만이 이를 필요로 하는 유일한 봇이 아니라는 점입니다. 당신의 배송 상태 확인 봇은 rule_refund_window_30d를 재사용합니다. 당신의 소셜 미디어 답변 봇은 rule_no_competitor_talk를 재사용합니다. 지원 관리자가 환불 기간을 60일로 연장하면, 당신은 템플릿을 한 번만 수정하면 됩니다.

Maple에 템플릿을 부착하는 것은 또 하나의 PUT 요청입니다:

{
  "identity": {
    "ruleTemplateIds": ["rule_no_competitor_talk", "rule_refund_window_30d"]
...

EClaw는 Maple이 호출될 때마다 영혼 래퍼 (soul wrapper)와 함께 이 규칙들을 프롬프트 컨텍스트 (prompt context)로 병합합니다. 만약 규칙이 모호하다면, 정체성 (Identity)의 boundaries 필드가 우선합니다. 즉, 정체성이 가장 높은 우선순위를 가진 레이어입니다.

단계 3: 영혼 (Soul)

영혼 (Soul)은 잘못 설정했을 때 비용이 가장 적게 들면서도 가장 눈에 띄는 레이어입니다. 정체성 (Identity)이 약한, 느낌만 좋은 지원 봇은 리스크가 됩니다. 매력적인 영혼 (Soul) 뒤에 표류하는 정체성 (Identity)을 가진 봇은 결국 잘못된 이유로 Hacker News에 오르게 됩니다.

soulTemplateId를 통해 단일 영혼 템플릿을 선택하세요. Maple의 경우, "친근하고 실용적인 (friendly-pragmatic)" 단계가 적절합니다. 좌절한 고객의 화를 가라앉힐 만큼 따뜻하면서도, 답변을 불필요하게 늘리지 않을 만큼 간결해야 합니다. 지원 흐름에서 "장난스러운 마스코트 (playful-mascot)" 스타일은 피하세요. 환불 확인 메시지에서 유머는 좋지 않게 읽힙니다.

{ "identity": { "soulTemplateId": "soul_friendly_pragmatic" } }

Identity(정체성)나 Rules(규칙)를 건드리지 않고도 Soul(영혼) 템플릿을 A/B 테스트할 수 있습니다. "soul_friendly_pragmatic"을 일주일 동안 실행한 뒤, "soul_terse_concierge"로 전환하여 CSAT(고객 만족도)를 비교해 보세요. 그 밑단에 있는 행동 계약(behavior contract)은 변경되지 않습니다.

이 분리가 실제로 이점을 주는 이유

이 3계층 분리는 단순히 깔끔하기만 한 것이 아닙니다. 이는 운영상의 현실과 직접적으로 매칭됩니다:

  • Identity는 봇의 역할이 바뀔 때 변경됩니다. 드문 일입니다. 보통 분기별로 이루어집니다.
  • Rules는 정책이 바뀔 때 변경됩니다. 매월 발생합니다. 정책 담당자나 법무(legal) 이해관계자가 관리합니다.
  • Soul은 브랜드 보이스(brand voice)가 진화하거나 A/B 테스트를 할 때 변경됩니다. 매주 발생합니다. 마케팅 팀이 관리합니다.

만약 이들을 하나의 거대한 메가 프롬프트(mega-prompt)로 통합한다면, 모든 변경 사항마다 봇 전체를 다시 구축해야 합니다. 더 심각한 문제는, 모든 변경 사항을 법률 고문이자 카피라이터 역할을 동시에 수행해야 하는 동일한 사람이 검토해야 한다는 점입니다. 이들을 분리하면 적절한 사람이 적절한 조절 장치(knob)를 관리할 수 있게 됩니다.

또한 조용한 이점도 있습니다: 바로 **회귀 테스트(regression testing)**입니다. 각 계층을 독립적으로 테스트할 수 있습니다. Rule 템플릿은 유닛 테스트(unit tests)를 가집니다. Identity는 validateIdentity() 스키마 체크를 가집니다. Soul 템플릿은 실제 사용자 코호트(cohort)를 대상으로 A/B 테스트를 진행합니다. 무언가 어긋날 때, 당직 엔지니어는 하나의 거대하고 알 수 없는 대상이 아니라 세 개의 작은 항목을 읽으면 됩니다.

흔한 실수들

  • instructions에 규칙을 쑤셔 넣는 것. 봇 하나일 때는 작동합니다. 하지만 확장(scale)되지 않습니다. 다른 봇이 해당 정책을 필요로 하는 즉시 정책을 Rule 템플릿으로 옮기세요.
  • 다중 Soul(multi-soul)에 대한 야망. EClaw는 엔티티(entity)당 하나의 활성 Soul만 지원합니다. 만약 "두 가지 목소리"를 원한다면, Rule 템플릿을 공유하는 두 개의 엔티티를 생성하세요.
  • publicProfile을 잊는 것. 이것은 사용자가 에이전트 카드에서 보게 되는 정보입니다. 아바타나 displayName이 없는 봇은 팀원이 아닌 내부 서비스처럼 보입니다. 반드시 설정하세요.
  • 초안 없이 라이브 환경을 편집하는 것. Identity 편집은 다음 푸시(push) 시점에 즉시 적용됩니다. 만약 boundaries(경계)를 변경하고 있다면, 한가한 시간대에 작업하세요. 그렇지 않으면 실행 중인 서비스에서 일관성 없는 답변이 나올 수 있습니다.

다음 단계

이미 EClaw에 봇이 있다면, 대시보드를 열고 엔티티(entity)를 클릭한 뒤 정체성 에디터(Identity editor)를 확인하세요. 아마 5분 안에 boundaries(경계)를 더 엄격하게 설정할 수 있을 것입니다. 대부분의 봇은 모호한 경계를 가지고 출시되기 때문입니다. 그다음, 어떤 규칙(Rules) 템플릿이 여러 엔티티에서 재사용되고 있는지 확인하세요. 단 하나의 봇에서만 사용되는 것은 인라이닝(inlining, 코드 내 직접 삽입) 후보이며, 여러 봇에 인라이닝되어 있는 것은 템플릿으로 승격(promotion)시킬 후보입니다.

아직 봇을 구축하지 않았다면, 순서는 항상 다음과 같습니다: 정체성(Identity) → 규칙(Rules) → 영혼(Soul). 영혼(Soul)부터 시작하고 싶은 충동을 억제하세요. 중심을 잃고 표류하는 친절한 봇은, 선을 지키는 절제된 봇보다 더 나쁩니다.

https://eclawbot.com에서 EClaw를 체험해 보세요.

— 이 글이 도움이 되었나요? 제 초대 코드로 EClaw를 시작하세요 —

귀하는 +100 e-coins를 받고 / 저는 +500을 받으며 / 첫 충전 시 +500 보너스를 받습니다.

보너스 받기

이 링크는 EClaw 공식 초대 페이지로 연결됩니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0