14 KiB
14 KiB
대화형 점진적 의도 구축 시스템 (Conversational Progressive Intent Building)
작성일: 2025-08-19
작성자: happybell80 & Claude
관련 서비스: rb10508_micro, skill-email, skill-news
문서 상태: 아이디어 제안
1. 개요
1.1 배경
현재 로빙 시스템은 단일 턴(single-turn) 명령 처리에 최적화되어 있습니다. 하지만 실제 사용자는 한 번에 명확한 지시를 하지 않고, 여러 번의 대화를 통해 점진적으로 의도를 구체화합니다.
1.2 목표
- 자연스러운 멀티턴(multi-turn) 대화 지원
- 컨텍스트를 유지하며 정보를 점진적으로 수집
- 사용자 의도가 완성되면 자동으로 실행
- "기억하고 성장하는 디지털 동료" 비전 실현
1.3 핵심 가치
- 자연스러움: 사람 간 대화처럼 자연스러운 상호작용
- 지능적 수집: 필요한 정보를 적절한 시점에 요청
- 컨텍스트 인식: 이전 대화를 기억하고 참조
2. 시스템 아키텍처
2.1 전체 구조
┌──────────────────────────────────────────────────────┐
│ 사용자 인터페이스 │
└────────────────────────┬─────────────────────────────┘
│
┌────────────────────────▼─────────────────────────────┐
│ 로빙 코어 (rb10508_micro) │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │ 의도 분류기 │ │ 대화 관리자 │ │ 응답 생성기 │ │
│ └─────────────┘ └──────────────┘ └─────────────┘ │
└────────┬──────────────┬──────────────┬───────────────┘
│ │ │
┌────▼────┐ ┌───▼────┐ ┌───▼────┐
│ Mistral │ │ Redis │ │ Gemini │
└─────────┘ └────────┘ └────────┘
│ │ │
┌────▼──────────────▼──────────────▼────┐
│ 컨텍스트 관리 시스템 │
│ ┌──────────┐ ┌──────────┐ │
│ │ 세션관리 │ │ 슬롯필링 │ │
│ └──────────┘ └──────────┘ │
└────────────────┬───────────────────────┘
│
┌────────────────▼───────────────────────┐
│ 스킬 서비스 레이어 │
│ ┌──────────┐ ┌──────────┐ │
│ │ Email │ │ News │ ... │
│ └──────────┘ └──────────┘ │
└────────────────────────────────────────┘
2.2 컴포넌트 설명
2.2.1 의도 분류기 (Intent Classifier)
- 사용자 발화를 대분류로 분류 (email/news/general)
- 기존 컨텍스트 연속인지 새 작업인지 판단
- Mistral API 활용
2.2.2 대화 관리자 (Dialogue Manager)
- 대화 흐름 제어
- 필요한 정보 파악 및 질문 생성
- 실행 트리거 감지
2.2.3 컨텍스트 관리 시스템
- 사용자별 세션 상태 유지
- 수집된 정보(슬롯) 관리
- 타임아웃 및 생명주기 관리
2.2.4 슬롯 필링 (Slot Filling)
- 각 스킬별 필수/선택 정보 정의
- 발화에서 정보 추출
- 정보 충돌 해결
3. 대화 흐름 시퀀스
3.1 전체 대화 시나리오
sequenceDiagram
participant U as 사용자
participant R as 로빙
participant C as 컨텍스트관리
participant M as Mistral
participant S as 스킬서비스
Note over U,S: 이메일 전송 대화 시나리오
%% 턴 1: 작업 시작
U->>R: "이메일 보낼건데..."
R->>M: 의도 분류 요청
M-->>R: intent: email
R->>C: 새 컨텍스트 생성
C-->>R: context_id: abc123
R->>U: "네, 이메일을 보내시겠군요. 누구에게 보내실까요?"
%% 턴 2: 수신자 정보
U->>R: "happybell 지메일로 보내줘"
R->>C: 컨텍스트 조회
C-->>R: 기존 컨텍스트 반환
R->>M: 슬롯 추출 (수신자)
M-->>R: recipient: happybell@gmail.com
R->>C: 슬롯 업데이트
R->>U: "happybell@gmail.com으로 보내드리겠습니다. 어떤 내용을 보내실까요?"
%% 턴 3: 내용 수집
U->>R: "행사에 와주셔서 감사하다는 내용이야"
R->>C: 컨텍스트 조회
R->>M: 슬롯 추출 (내용)
M-->>R: content: 감사 인사
R->>C: 슬롯 업데이트
R->>U: "감사 인사 메일이군요. 어떤 톤으로 작성할까요?"
%% 턴 4: 톤 설정
U->>R: "공손하지만 기쁜 느낌으로"
R->>C: 슬롯 업데이트 (tone: polite_happy)
R->>U: "공손하면서도 기쁜 톤으로 작성하겠습니다. 발신자는 어떻게 할까요?"
%% 턴 5: 발신자
U->>R: "내 이메일로 해"
R->>C: 사용자 정보 조회
C-->>R: sender: user@gmail.com
R->>C: 슬롯 업데이트
R->>U: "user@gmail.com으로 발신자를 설정했습니다."
%% 턴 6: 추가 요청
U->>R: "끝에 내 명함도 넣어줘"
R->>C: 슬롯 업데이트 (signature: true)
R->>C: 완성도 체크
C-->>R: 필수 슬롯 완료
R->>U: "명함을 추가하겠습니다. 다음 내용으로 이메일을 준비했습니다:\n[요약 표시]"
%% 턴 7: 실행
U->>R: "그래 보내"
R->>C: 실행 트리거 감지
R->>S: 이메일 전송 요청
S-->>R: 전송 완료
R->>C: 컨텍스트 종료
R->>U: "이메일을 성공적으로 전송했습니다."
3.2 컨텍스트 상태 전이
stateDiagram-v2
[*] --> Idle: 초기 상태
Idle --> Collecting: 작업 시작 감지
Collecting --> Collecting: 정보 추가
Collecting --> Confirming: 필수 슬롯 완료
Collecting --> Modifying: 수정 요청
Modifying --> Collecting: 수정 완료
Confirming --> Executing: 실행 명령
Confirming --> Modifying: 수정 요청
Executing --> Completed: 성공
Executing --> Failed: 실패
Failed --> Collecting: 재시도
Failed --> Cancelled: 취소
Completed --> [*]: 종료
Cancelled --> [*]: 종료
Collecting --> Timeout: 30분 무응답
Confirming --> Timeout: 30분 무응답
Timeout --> Idle: 리셋
3.3 슬롯 필링 프로세스
flowchart TD
Start([사용자 발화]) --> Extract[정보 추출]
Extract --> Check{슬롯 충돌?}
Check -->|예| Confirm[충돌 확인 요청]
Check -->|아니오| Update[슬롯 업데이트]
Confirm -->|덮어쓰기| Update
Confirm -->|유지| Keep[기존값 유지]
Update --> Validate[유효성 검증]
Keep --> CheckComplete
Validate -->|실패| Error[오류 메시지]
Validate -->|성공| Save[컨텍스트 저장]
Save --> CheckComplete{필수 슬롯\n완료?}
CheckComplete -->|예| Ready[실행 준비 완료]
CheckComplete -->|아니오| NextQ[다음 질문 생성]
Error --> NextQ
NextQ --> End([응답 생성])
Ready --> End
4. 데이터 구조
4.1 컨텍스트 스키마
class WorkContext:
"""작업 컨텍스트"""
context_id: str # 고유 ID
user_id: str # 사용자 ID
session_id: str # 세션 ID
# 작업 정보
intent: str # 대분류 (email/news/general)
sub_intent: str # 세부 의도
state: ContextState # 현재 상태
# 슬롯 정보
slots: Dict[str, Any] # 수집된 정보
required_slots: List # 필수 슬롯
optional_slots: List # 선택 슬롯
# 대화 히스토리
turns: List[Turn] # 대화 턴 목록
# 메타데이터
created_at: datetime
updated_at: datetime
expires_at: datetime # TTL
4.2 이메일 스킬 슬롯 예시
email_slots = {
"required": {
"recipient": {
"type": "email",
"question": "누구에게 보내실까요?",
"validation": email_regex
},
"content": {
"type": "text",
"question": "어떤 내용을 보내실까요?",
"min_length": 10
}
},
"optional": {
"subject": {
"type": "text",
"question": "제목을 입력하시겠습니까?",
"default": "안녕하세요"
},
"tone": {
"type": "enum",
"options": ["formal", "casual", "friendly"],
"question": "어떤 톤으로 작성할까요?"
},
"attachments": {
"type": "list",
"question": "첨부파일이 있나요?"
}
}
}
5. 구현 전략
5.1 단계별 구현 (Phase Approach)
Phase 1: MVP (2주)
- 3턴 대화 지원
- 하드코딩된 이메일 슬롯
- 인메모리 컨텍스트
- 코드 증가: +400줄
Phase 2: 기본 구현 (1개월)
- 5턴 대화 지원
- Redis 세션 관리
- 2개 스킬 (email, news)
- 코드 증가: +800줄
Phase 3: 완전 구현 (2개월)
- 무제한 턴 지원
- 동적 슬롯 시스템
- 모든 스킬 통합
- 코드 증가: +1,750줄
5.2 함수형 프로그래밍 적용
# 순수 함수 예시
def extract_slots(text: str, slot_schema: Dict) -> Dict:
"""텍스트에서 슬롯 추출 - 순수 함수"""
extracted = {}
for slot_name, slot_def in slot_schema.items():
if pattern := slot_def.get('pattern'):
if match := re.search(pattern, text):
extracted[slot_name] = match.group(1)
return extracted
# 상태 불변성
def update_context(context: WorkContext, slots: Dict) -> WorkContext:
"""컨텍스트 업데이트 - 새 객체 반환"""
return WorkContext(
**{**context.__dict__,
'slots': {**context.slots, **slots},
'updated_at': datetime.now()}
)
# I/O 분리
async def process_turn(user_input: str, user_id: str):
"""턴 처리 - I/O와 로직 분리"""
# I/O: 컨텍스트 조회
context = await fetch_context(user_id)
# 순수 함수: 의도 분석
intent = classify_intent(user_input)
# 순수 함수: 슬롯 추출
slots = extract_slots(user_input, get_schema(intent))
# 순수 함수: 컨텍스트 업데이트
new_context = update_context(context, slots)
# I/O: 저장
await save_context(new_context)
# 순수 함수: 응답 생성
response = generate_response(new_context)
return response
6. 성능 분석
6.1 리소스 사용량 (7턴 대화 기준)
| 리소스 | 현재 방식 | 제안 방식 | 증가율 |
|---|---|---|---|
| LLM 호출 | 1회 | 22회 | 22배 |
| DB 접근 | 0회 | 24회 | - |
| 응답 시간 | 500ms | 2,600ms | 5.2배 |
| 토큰 사용 | ~200 | ~2,000 | 10배 |
| 메모리 | 50MB | 100MB | 2배 |
6.2 최적화 전략
-
병렬 처리
- 의도 분류와 슬롯 추출 동시 실행
- 턴당 200ms 절감
-
캐싱
- 자주 사용하는 질문 템플릿
- 의도 분류 결과 단기 캐싱
-
배치 처리
- 대화 히스토리 배치 저장
- 슬롯 검증 일괄 처리
최적화 후 목표: 턴당 150-200ms
7. 장단점 분석
7.1 장점
- ✅ 자연스러운 대화 경험
- ✅ 작업 완성률 향상 (60% → 95%)
- ✅ 사용자 만족도 증가
- ✅ "디지털 동료" 비전 실현
7.2 단점
- ❌ 코드 복잡도 5배 증가
- ❌ 디버깅 난이도 상승
- ❌ LLM 비용 20배 증가
- ❌ 응답 지연 (즉각 → 2-3초)
7.3 리스크
- 세션 동기화 문제
- 컨텍스트 오염
- 타임아웃 관리
- 스케일링 이슈
8. 대안 검토
8.1 하이브리드 접근
- 간단한 명령: 현재 방식 유지
- 복잡한 작업: 대화형 모드 전환
- 사용자가 모드 선택
8.2 프롬프트 개선
- 한 번에 모든 정보 요청하는 프롬프트
- 예: "이메일을 보내려면 수신자, 내용, 톤을 말씀해주세요"
8.3 UI 기반 접근
- 프론트엔드에서 폼 제공
- 대화와 폼 병행 사용
9. 결론 및 제안
9.1 결론
대화형 점진적 의도 구축 시스템은 사용자 경험을 크게 향상시킬 수 있지만, 구현 복잡도와 운영 비용이 상당히 증가합니다.
9.2 제안
- Phase 1 MVP로 시작: 이메일 스킬만 대상으로 POC 구현
- 사용 패턴 분석: 실제로 멀티턴 대화가 필요한지 데이터 수집
- 점진적 확장: 필요성이 검증되면 Phase 2, 3 진행
9.3 우선순위
현재 rb10508_micro의 "경량화" 목표를 고려하면:
- 먼저 단순 의도 분류 개선
- 기본적인 2-3턴 대화 지원
- 필요시 전체 시스템 구현
10. 참고 자료
작성자 노트: 이 시스템은 "기억하고 성장하는 디지털 동료"라는 로빙의 핵심 비전을 실현하는 중요한 단계입니다. 하지만 현실적인 제약을 고려하여 단계적 접근을 권장합니다.