💡 원래 devtocash.com에 게시되었습니다. — 이 가이드는 이곳에서 최신 상태로 유지됩니다. 저는 매주 실무 DevOps/SRE 심층 분석 글을 작성합니다.

창(Window)이 제품이다

온콜 AI 에이전트가 실패하는 이유는 모델 자체가 멍청해서가 아닙니다. 잘못된 8,000 토큰을 제공했기 때문에 실패하는 것입니다. 인시던트 에이전트에게 원본 알림 페이로드와 kubectl 도구를 주면, 이 에이전트는 자신이 'payment-service'가 4분 전에 배포되었는지, 이 정확한 5xx 패턴이 지난 화요일의 잘못된 config map이었는지, 또는 런북에

런북 (runbook) 슬롯은 대부분의 팀이 실수하는 지점입니다. 전체 인시던트 런북 (full incident runbook)은 3,000단어가 넘을 수 있으며, 이를 통째로 붙여넣으면 관련 문단이 묻혀버립니다. 대신, 런북과 사후 분석 (postmortem) 내용을 청크 (chunk) 단위로 나누고, 임베딩 (embed) 하여 현재 발생한 인시던트와 일치하는 섹션만 검색 (retrieve) 하세요.

def assemble_context(alert, budget):
    query = f"{alert.service} {alert.metric} {alert.summary}"

...

이 과정을 신뢰할 수 있게 만드는 두 가지 규칙이 있습니다. 첫째, 가공되지 않은 데이터가 아닌 구조화된 데이터를 검색 (retrieve structured, not raw) 하세요: 200개의 메트릭 (metric) 라인을 쏟아붓는 것보다 순위가 매겨진 5개의 시리즈를 반환하는 prom.top_anomalies()가 훨씬 낫습니다. 10MB의 로그보다 20줄의 에러 샘플이 더 효과적입니다. 에이전트는 자율 SRE 에이전트가 하는 방식과 같이, 순위가 매겨지고 라벨이 지정된 사실들로 사전 처리된(pre-digested) 실제 텔레메트리 (telemetry)를 읽습니다. 둘째, 도구 (tools)는 탈출구 (escape hatch) 역할을 해야 합니다: 필요할지도 모르는 모든 것을 미리 로드하지 마세요. 확률이 높은 컨텍스트 (context)를 로드하고, 에이전트가 추론 과정에서 필요할 때만 더 깊은 로그 쿼리나 특정 트레이스 (trace) 등을 요청할 수 있도록 범위가 제한된 MCP 서버 (MCP server)를 노출하세요.

최신성이 완전성보다 중요합니다

인시던트 상황에서는 신선도 (freshness)가 지배적입니다. 4분 전에 이루어진 배포는 1년 전에 작성된 완벽하게 관련 있는 런북보다 더 가치가 있습니다. 이에 따라 검색 (retrieval) 가중치를 조절하세요. 오래된 사후 분석 (postmortem)의 점수는 감쇠 (decay) 시키고, 모델이 가장 강력하게 주의 (attend)를 기울이는 윈도우 (window)의 상단 근처에 항상 "최근 변경 사항 (recent changes)" 슬롯을 배치하세요.

def score(doc, query_sim):
    age_hours = (now - doc.timestamp).total_seconds() / 3600
    recency = math.exp(-age_hours / 168)   # ~1주일 반감기
...

윈도우(window) 내의 순서 자체가 컨텍스트 엔지니어링 (context engineering)입니다. 모델은 긴 컨텍스트의 시작과 끝 부분에 가장 집중하는 경향이 있으므로(

• 컨텍스트 부패 (Context rot). 모델이 사용할 수 있는 윈도우(window)의 과거 ~50% 지점부터, 하드 리미트(hard limit)에 도달하기 전에 품질이 저하됩니다. 예산을 최대치보다 훨씬 낮게 설정하고 측정하십시오. 200K 윈도우가 있다고 해서 반드시 200K를 다 채워야 한다고 가정해서는 안 됩니다.
• 오염된 메모리 (Poisoned memory). 권위 있는 정보로 검색된 단 하나의 잘못된 "확인된" 근본 원인(root cause)이 향후 모든 유사한 인시던트를 잘못된 방향으로 유도할 수 있습니다. 쓰기 작업은 인간의 확인 절차를 거치도록 제한하고, 메모리 항목은 수정 및 취소가 가능하도록 유지하십시오.
• 오래된 런북 (Stale runbooks). 검색(Retrieval)의 품질은 코퍼스(corpus)의 품질에 달려 있습니다. 삭제된 서비스를 참조하는 런북은 없는 것보다 더 나쁩니다. 에이전트가 유령을 쫓게 만들기 때문입니다. 문서가 변경되면 다시 인덱싱(re-index)하십시오.
• 조용한 절단 (Silent truncation). trim_to_budget가 슬롯을 제거할 때는 반드시 로그를 남기십시오. 텔레메트리(telemetry) 슬롯을 소리 없이 잃어버린 에이전트는 자신감 있게 행동하지만 눈을 가린 채 비행하는 것과 같습니다. 이는 관찰 불가능한 자동화(unobservable automation)와 동일한 함정입니다.

모든 파이프라인처럼 측정하십시오

관찰할 수 없는 것은 튜닝할 수 없습니다. OpenTelemetry를 사용하여 모든 조사 과정을 추적하십시오. 어떤 컨텍스트 슬롯이 채워졌는지, 각 슬롯이 얼마나 많은 토큰을 소비했는지, 에이전트가 실제로 인용한 검색된 청크(chunk)는 무엇인지, 그리고 최종 결과는 어떠했는지를 기록하십시오. 두 가지 지표가 컨텍스트 엔지니어링의 작동 여부를 알려줍니다. 바로 검색 적중률 (retrieval hit rate) (관련 런북/사후 분석(postmortem)이 윈도우 내에 포함되었는가?)과 근거 기반 해결률 (grounded-resolution rate) (에이전트의 결론이 검색된 컨텍스트를 인용했는가, 아니면 스스로 지어냈는가?)입니다. 이 두 가지를 에이전트가 운영 환경(prod)에 투입되기 전에 실행하는 평가(evals)에 반영하여, 과거 인시던트를 재현함으로써 각 상황에 적절한 컨텍스트가 노출되는지 확인하십시오.

요약 (Takeaway)

온콜 에이전트의 지능은 컨텍스트 윈도우 (Context Window) 내에 존재하며, 이 윈도우는 단순히 채워 넣는 것이 아니라 엔지니어링 (Engineer) 해야 하는 대상입니다. 모든 슬롯을 예산(Budget)처럼 관리하고, 가공되지 않은 데이터를 밀어 넣는 대신 구조화된 사실 (Structured Facts)을 검색하며, 실시간 인시던트 (Live Incidents)를 위해 최신성에 가중치를 부여하십시오. 확인된 교훈만을 메모리에 기록하고, 튜닝이 가능하도록 전체 과정을 추적(Trace)하십시오. 컨텍스트를 올바르게 설정하면 평범한 모델도 유능한 조사를 수행할 수 있지만, 컨텍스트가 잘못되면 시장에서 가장 뛰어난 모델이라 할지라도 잘못된 것을 자신 있게 조사하게 될 것입니다.

📌 이 가이드의 최신 버전 — 그리고 DevOps, SRE, Kubernetes, 관측성 (Observability) 및 클라우드 비용 가이드 전체 라이브러리 — 를 devtocash.com에서 확인하세요.