Skip to main content

에이전트 설계 고려

Context Management에 대한 고민​

고민 포인트

  • Context pool 관리를 어떻게 하는가?
  • Clude code에서는 어떻게 진행 되었는가?

사용자의 후속질문에 대해서 langgraph 설계​

고민 포인트

  • context management을 어떻게 해야하는가?
  • langgraph의 어떤 상태까지 context에 넣어야 하는가?

LLM이 적절하게 응답을 해주는지 어떻게 진단하고 평가하며 개선할 수 있는가?​

  • LLM결과물에 대한 평가 알고리즘 작성, LLM이 1차 평가, 사람이 2차평가
  • 평가셋트를 만들기 ( 골든 데이터 셋 )
  • 평가 결과물을 바탕으로 프롬프트 및 시스템 개선하기 (반복)

Out of scope에 대한 질문을 처리하는 방법​

지원 언어 고려하기​

데이터 조회 관련 기능​

  • 데이터 조회 기간에 대해서 사전 validator (input validator & ux ) 고려
  • 타인의 데이터 조회가 불가능하도록 보안 레이어 두기

추천 팔로업 질문에 대한 설계​

포인트

  • 사용자에게 추천에할 수 있는 팔로업 질문 우선순위는 어떻게 결정되는가?
  • 이미 질문한것에 대해서 추천질문 중복제거는 어떻게 하는가?
  • 추천 질문 중 graph state와 관련된 질문도 같이 들어갈 수 있는가?
    • 추천 질문을 단순 생성이 아니라 현재 graph state 기반으로 만들 것인가?
    • 추천 질문의 목적을 나눌 것인가: 탐색, 비교, 다음 액션, 오류 복구, 설정 변경
    • 이미 답변한 질문, 권한상 불가능한 질문, out-of-scope 질문을 필터링할 것인가?

Security​

  • 프롬프트 인젝션 처리는 막을 수 있는가?
  • PII 마스킹처리가 필요한가?
  • BOLA이슈는 어떻게 하는가?
  • Low Level Security Layer 구축에 대한 설계는 어떻게 하는가?

Agent Boundary 설계​

  • 어디까지를 에이전트가 판단하고, 어디부터는 고정 워크플로우로 둘 것인가?
  • LLM이 자율적으로 결정하면 안 되는 영역은 무엇인가?
  • “답변 생성”, “데이터 조회”, “액션 실행”, “사용자 확인 요청”을 분리할 것인가?

State 설계 원칙​

  • LangGraph state에 넣을 값과 외부 DB에 둘 값을 어떻게 나눌 것인가?
  • state를 messages, user_intent, retrieved_data, tool_results, pending_action, metadata처럼 역할별로 분리할 것인가?
  • state schema 변경 시 기존 thread/checkpoint와의 호환성은 어떻게 보장할 것인가?
  • state에 민감정보를 저장하지 않기 위한 규칙은 무엇인가?

Memory 전략​

  • short-term memory와 long-term memory를 분리할 것인가?
  • 대화 전체를 계속 넣을지, 요약본 + 최근 N개 메시지만 넣을지?
  • 사용자의 선호, 권한, 조직 정보, 반복 요청 패턴을 장기 기억에 저장할 것인가?
  • 기억을 언제 업데이트할 것인가? 응답 중 즉시 저장할지, 백그라운드로 추출할지?

Checkpoint / Resume / 장애 복구​

  • 사용자가 중간에 나갔다 돌아왔을 때 어디서부터 이어갈 것인가?

  • tool 실행 직전/직후 checkpoint를 남길 것인가?

  • 실패한 node만 재시도할 수 있는가?

  • 이전 상태로 되돌려서 다른 경로를 실험할 수 있는가?

    공식 문서에서는 persistence/checkpointer를 human-in-the-loop, memory, time travel, fault tolerance의 기반으로 설명합니다: https://docs.langchain.com/oss/python/langgraph/persistence

Tool 설계​

  • tool input/output schema를 엄격하게 둘 것인가?
  • tool call 전에 validator를 둘 것인가?
  • tool 실패 시 retry, fallback, 사용자 재질문 중 무엇을 선택할 것인가?
  • tool은 idempotent해야 하는가? 같은 요청이 두 번 실행되어도 문제가 없는가?
  • 조회 tool과 변경 tool을 명확히 분리할 것인가?
  • tool 결과를 LLM에 그대로 줄지, 요약/마스킹해서 줄지?

Human-in-the-loop​

  • 어떤 액션은 사람 승인 없이는 실행하지 못하게 할 것인가?

  • 예: 데이터 삭제, 외부 전송, 결제, 권한 변경, 민감 데이터 조회

  • 승인 UX는 approve, edit, reject, ask user 중 어떤 패턴을 쓸 것인가?

  • 사람이 수정한 tool input을 audit log에 남길 것인가?

    LangGraph/LangChain 문서에도 민감한 tool call 전에 interrupt로 실행을 멈추고 승인/수정/거절할 수 있는 패턴이 소개되어 있습니다: https://docs.langchain.com/oss/python/langchain/human-in-the-loop

관찰성 / 디버깅​

  • 각 node의 input/output을 어떻게 로깅할 것인가?
  • LLM prompt, retrieved context, tool result, final answer를 추적할 수 있는가?
  • 사용자가 “왜 이런 답이 나왔어?”라고 물었을 때 근거를 재현할 수 있는가?
  • graph 실행 경로를 시각화하거나 trace로 남길 것인가?

Cost / Latency 관리​

  • 매 turn마다 어떤 LLM을 쓸 것인가? 큰 모델과 작은 모델을 나눌 것인가?
  • context 압축, 캐싱, tool result 재사용 전략은?
  • 응답 streaming을 지원할 것인가?
  • 긴 작업은 비동기 job으로 넘길 것인가?

안전한 응답 정책​

  • 모르는 경우 어떻게 말할 것인가?
  • 불확실한 답변에는 confidence/source를 붙일 것인가?
  • 데이터 기반 답변과 일반 추론 답변을 시각적으로 구분할 것인가?
  • 사용자가 잘못된 전제를 깔고 질문할 때 정정할 것인가?

권한 / 테넌트 격리​

  • user_id, org_id, role, scope를 graph state와 tool layer 중 어디서 검증할 것인가?
  • LLM이 만든 query를 그대로 실행하지 않도록 정책 레이어를 둘 것인가?
  • row-level security, audit log, rate limit을 어떻게 둘 것인가?

배포 / 운영​

  • prompt와 graph 버전을 어떻게 관리할 것인가?
  • 특정 버전에서 만든 checkpoint를 새 버전 graph가 처리할 수 있는가?
  • 실험군별 prompt/model/tool routing을 할 것인가?
  • 장애 시 사용자에게 “작업이 중단됨”, “재시도 가능”, “관리자 확인 필요”를 어떻게 보여줄 것인가?

가드레일 설계​

  • 프롬프트 인젝션, 공격과 탈옥을 방어하는 방법
  • 데이터 프라이버시 보호, PII, 기밀 데이터 누출
  • 콘텐츠

LLM guard 용도로는 보통 이렇게 쓰는 게 실용적이야.

  • 1차: regex / 금칙어 / PII rule
  • 2차: 한국어 toxicity classifier
  • 3차: 애매한 케이스만 SLM 또는 LLM judge

Token limit 설계​

  • 1회 요청당 최대 토큰
  • 1개 작업당 최대 토큰
    • max_output_tokens
    • agent loop 횟수
    • tool call 최대 횟수
    • 대화 history 길이
    • 재시도 횟수
  • 사용자당 일/월 토큰 quota
  • 조직/테넌트당 quota

사용자 등급별 정책

  • Free: 하루 50k tokens, 작업당 8k tokens
  • Pro: 하루 500k tokens, 작업당 64k token