Plaid Labs AI 에이전트 Part. 2: 필요한 Context만 사용하는 방법

Plaiddy를 더 똑똑하게

챗봇을 만들면서 “필요한 컨텍스트만” 수집하게 된 기술 설계

왜 컨텍스트 수집이 핵심이었는가

• “이번 주 DSY 프로젝트 진행 상황 알려줘”는 프로젝트+이슈 상태가 필요합니다.

• “어제 내가 한 일 요약해줘”는 사용자 컨텍스트+EOD가 필요합니다.

• “JIRA-1234 상태만 알려줘”는 특정 이슈 필터 결과만 필요합니다.

왜 필요 컨텍스트만 수집했는가

• 입력 토큰이 빠르게 커져 핵심 정보가 잘리거나 요약 왜곡이 발생할 수 있습니다.

• 질문마다 불필요한 데이터까지 조회해 응답 지연과 비용이 함께 증가합니다.

• 현재 질문과 무관한 데이터가 섞이면 모델이 초점을 잃고 답변 정확도가 떨어집니다.

• 오래된 컨텍스트와 최신 데이터가 함께 들어가면 충돌 해석이 발생할 수 있습니다.

• 사용자/프로젝트 범위를 과하게 주입하면 권한 경계와 정보 노출 리스크가 커집니다.

• 문제 발생 시 어떤 컨텍스트가 답변에 영향을 줬는지 추적이 어려워집니다.

우리가 쓴 컨텍스트 기술 스택

• Slack Bolt + Slack Events API: 실시간 이벤트 수신/ack

• Redis: assistant thread 문맥 복원

• MongoDB: 컨텍스트 소스(유저/프로젝트/이슈/브리핑/EOD)

• LangSmith Prompt Router: 질의 의도와 슬롯 추출

• Langfuse tracing(invoke_with_langfuse): 체인 실행 추적 통일

• APScheduler + Celery: 배치성 컨텍스트(유저/프로젝트 context) 사전 업서트

핵심 설계: LLM 단독이 아니라 Hybrid Router

1) 이벤트에서 기본 요청(ContextRequest) 생성

# app/chat/context/request_builder.py
# Slack event에서 user/channel/thread 식별자를 추출하고
# 사용자 문서와 매핑해 base request를 만든다.
return ContextRequest(
    user_slack_id=user_slack_id,
    user_id=user_id,
    atlassian_id=atlassian_id,
    query=query,
    channel_id=channel_id,
    thread_ts=thread_ts,
    limit=limit,
)

2) Router LLM으로 의도/슬롯 보강

# app/chat/context/context_resolver.py
llm_payload = await _call_context_router_llm(conversation, text)
llm_request = _request_from_llm_payload(llm_payload)
merged_request = merge_context_requests(base_request, llm_request)

3) selector로 “필요한 타입만” 고정

# app/chat/context/selector.py
if target == ContextTarget.PROJECT:
    if _has_issue_filters(request):
        return [ContextType.JIRA_ISSUE_FILTERED]
    return [
        ContextType.PROJECT_CONTEXT,
        ContextType.JIRA_ISSUE_ACTIVE,
        ContextType.JIRA_ISSUE_DONE_TODAY,
    ]

4) registry/fetcher 패턴으로 타입별 수집 분리

# app/chat/context/collector.py
for context_type in select_context_types(...):
    fetcher = self.registry.get(context_type)
    item = await fetcher(request)
    if item and item.text:
        items.append(item)

컨텍스트를 실제로 어떻게 뽑았는가

프로젝트/유저 컨텍스트

• Mongo의 jira_projects.context, users.context에서 조회

• 사전 배치 업서트로 최신성 확보

Jira 이슈 컨텍스트

• active / done_today / filtered를 분리

• 상태 문자열 동의어를 normalize (done, 완료, to do 등)

• 날짜 필터를 YYYY-MM-DD, ISO datetime 모두 수용

# app/chat/context/fetchers/jira_context.py
statuses = _normalize_issue_statuses(request.issue_statuses)
date_filter = _build_date_filter(...)
issues_cursor = db.jira_issues.find(query).sort(sort_field, -1).limit(limit)

브리핑/EOD 컨텍스트

• 사용자의 최신 briefing/EOD를 별도 fetcher에서 조회

• EOD는 AI 입력 전 정규화(cleaning)

ChatFlow에서 수집 결과를 어떻게 사용했는가

# app/chat/orchestrators/chat_flow.py
context_result = await run_context_request_flow(...)
if context_result.resolution.action.confidence < confidence_threshold:
    await send_followup_question(event, say=say)
    return

info = format_context_info(context_result.resolution.bundle)
response_text = generate_chat_response(...)

구현 과정에서 얻은 실전 노하우

• 수신(ack)과 처리(chat)를 분리하면 Slack 타임아웃 리스크가 줄어듭니다.

• LLM 출력은 바로 쓰지 말고 merge/normalize 단계를 반드시 둬야 합니다.

• 컨텍스트 수집은 “많이”보다 “정확히”가 중요합니다.

• low-confidence는 에러가 아니라 정상 플로우로 설계해야 합니다.

• tracing 경로(invoke_with_langfuse)를 통일해야 디버깅이 빨라집니다.

• push(정기 브리핑)와 pull(실시간 질의응답)을 병행하면 전환 비용이 작습니다.

다음은 Slack 명령어 기반

• 팀의 AI CLI 도구와 책임 분리

• 기능 증가 시 고려 액션, 타겟, 필터 증가 및 경계의 모호

• 입력 스키마 고정으로 운영 편차 축소

마무리