본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 20. 22:57

에이전트에게 '지금(now)'의 의미를 가르치려는 시도: 현재까지의 진행 상황

요약

AI 에이전트가 검색된 데이터의 시간적 신선도(freshness)를 인지하지 못하는 문제를 해결하기 위한 빌더의 로그입니다. 데이터의 유효성을 판단하는 'FreshContext' 계층을 통해 컨텍스트의 시간적 가치를 검증하고 강제하는 구조적 접근법을 다룹니다.

핵심 포인트

  • 에이전트는 검색된 데이터가 과거의 것인지 현재의 것인지 구분하지 못하는 한계가 있음
  • 단순 불리언(Boolean) 값은 하류 단계에서 조작되거나 무시될 위험이 있음
  • 판결(verdict)에 시간 정보와 디지털 서명을 포함하여 데이터의 신선도를 강제해야 함
  • FreshContext는 검색과 추론 사이에서 컨텍스트의 사용 여부를 결정하는 판단 계층 역할을 수행함

이것은 출시를 위한 글이 아니라 빌더의 로그(builder's log)입니다. 저는 현재 문제의 한복판에 있으며, 이에 대해 소리 내어 생각(think out loud)해보고 싶습니다. 왜냐하면 지난 포스트에 답글을 달아준 분들이 한 달간 혼자 작업했을 때보다 제 생각을 더 많이 진전시켜 주었기 때문입니다.

깨달음의 순간

지난주 Copilot은 6월 12일로 예정된 경기가 여전히 열릴 것이라고 말했습니다. 확신에 찬 미래 시제였습니다. 하지만 제가 그것을 읽고 있었던 것은 6월 20일이었습니다. 경기는 이미 끝난 상태였습니다.

데이터가 검색(retrieval)되었을 당시에는 틀리지 않았습니다. 데이터는 검색 시점과 저에게 도달한 시점 사이의 간극에서 신선함을 잃었습니다(stale). 그리고 파이프라인(pipeline) 내의 그 어떤 것도 이를 알아차리지 못했습니다. 에이전트(agent)는 "지금(now)"이라는 감각이 없었습니다. 에이전트는 8일 전의 사실을 8초 전의 사실과 똑같이 취급했습니다.

이것이 제가 계속 맞닥뜨리는 문제입니다. 우리는 에이전트에게 검색(retrieve)하고 추론(reason)하는 법은 가르쳤습니다. 하지만 지금이 몇 시인지는 가르치지 않았습니다.

배경: 제가 구축해 온 것

저는 검색(retrieval)과 추론(reasoning) 사이에 위치하는 판단 계층(judgment layer)인 FreshContext를 작업하고 있습니다. 어떤 검색기(retriever)(벡터 DB, 웹 검색, RAG, 도구 호출 등)든 후보 컨텍스트(candidate context)를 FreshContext에 전달합니다. 그러면 FreshContext는 컨텍스트가 모델에 도달하기 전에 "이것을 사용하라", "새로고침하라", "검증하라", "제외하라"와 같은 판결(verdict)을 반환합니다. FreshContext 자체는 아무것도 가져오지(fetch) 않습니다. 이 경계는 의도적인 것이며, 이 글의 뒷부분에서 중요하게 다뤄질 것입니다.

한동안 판결에는 safe_for_agent_handoff라는 불리언(boolean) 값이 포함되었습니다. 견고하다고 느꼈지만, 그렇지 않았습니다.

제 가정을 깨뜨린 댓글

ANP2 Network라는 댓글 작성자가 제가 반박할 수 없는 지점을 지적했습니다:

"주석(annotation)은 아무리 구조화되어 있더라도, 다음 에이전트가 존중할 것이라고 신뢰되는 대상일 뿐입니다. 인프라(infrastructure)는 다음 에이전트가 흔적을 남기지 않고는 우회할 수 없는 것입니다."

불리언(Boolean)은 객체(object) 상의 필드입니다. 하류(downstream)의 어떤 단계든 needs_verificationsafe_to_cite로 뒤집을 수 있으며, 아무런 흔적도 남기지 않을 수 있습니다. 구조화된 판결(structured verdict)은 이를 무시하는 비용을 높이지만, 조작을 가시화하지는 못합니다. ANP2는 Copilot 매칭 사례와 동일한 질병을 다른 관점에서 설명하고 있었습니다. 즉, 한때는 참이었으나 언제 만들어졌는지, 혹은 여전히 유효한지에 대한 기록 없이 영원히 신뢰되는 판단에 관한 것입니다.

두 가지 증상, 하나의 질병. 판결에는 시간 개념이 없으며 출처에 대한 증거도 없습니다.

내가 도달한 지점 (그리고 가장 확신이 없는 부분)

나는 두 가지 해결책을 검토했습니다.

첫 번째: 판단 계층(judgment layer) 자체가 검증기(verifier)가 되도록 하는 것입니다. 모든 파이프라인이 예/아니오를 확인하기 위해 이 계층을 거치게 합니다.

두 번째: 계층을 순수하게 유지하는 것입니다. 계층은 판결을 생성하고, 이에 서명하며(HMAC, 비밀값은 서버 측에 유지), evaluated_at을 찍어 판결이 자체적인 연령(age)을 갖게 합니다. 에이전트를 감싸는 얇은 래퍼(wrapper)가 서명을 확인하고 강제합니다. 하류의 어떤 에이전트라도 검증 엔드포인트(verify endpoint)를 호출하여 해당 판결이 실제로 계층에서 왔는지, 그리고 내용이 변경되지 않았는지 확인할 수 있습니다.

나는 두 번째 방식을 선택했습니다. 이유는 다음과 같습니다. 판단 계층이 판단(judging)하는 대신 심판(adjudicating)하기 시작하는 순간, 모든 파이프라인이 통과해야 하는 게이트키퍼(gatekeeper)가 되어버립니다. 이는 공격 표면(attack surface)을 넓히고, 도입을 어렵게 만들며, 솔직히 더 나쁜 제품이 됩니다. 가져오지 않고(no-fetch), 강제하지 않는(no-enforce) 경계야말로 다른 사람들이 제어권을 내게 넘기는 대신 자신의 스택에 이 기능을 바로 적용할 수 있게 해주는 핵심입니다.

이 모든 것을 시작하게 만든 두 가지 실패 사례에 대응하자면:

  • 조용한 뒤집기(The silent flip): 판결을 다시 쓰는 것은 서명을 깨뜨립니다. 검증(Verify) 단계에서 거부됩니다. 누락이 더 이상 보이지 않는 상태로 남지 않습니다.
  • 오래된 매칭(The stale match): evaluated_at은 판결이 자신이 얼마나 오래되었는지 알 수 있음을 의미합니다. 하류 단계는 맹목적으로 신뢰하는 대신, 유효 기간이 지난 판결을 거부할 수 있습니다.
  • 그리고 멀티 에이전트 사례 (지난 포스트 아래에서 누군가 직접 제기한 문제): 에이전트 B는 단순히 에이전트 A가 전달했다는 이유만으로 판결을 신뢰하지 않습니다. B는 서명을 검증합니다. 한 에이전트가 점수를 조작하더라도 다음 에이전트를 감염시키지 않습니다.

제가 여전히 확신하지 못하는 부분이며, 저보다 더 날카로운 시선이 필요한 지점은 다음과 같습니다:

  1. 래퍼 (wrapper)는 선택 사항 (opt-in)입니다. 이를 건너뛰면 다시 자문 (advisory) 단계로 돌아갑니다. "증명 가능하며, 당신이 선택할 때만 강제되는 (provable, enforced only if you choose to)" 것이 진정한 강제 (enforcement)일까요, 아니면 영수증이 첨부된 주석 (annotation with a receipt)일 뿐일까요?
  2. 상태 비저장 검증 (Stateless verify)은 모든 실제 결정 지점에서 네트워크 호출 (network call)을 발생시킵니다. 저렴하지만 공짜는 아닙니다. 지연 시간 (latency)이 가치를 상쇄하는 경계선은 어디일까요?
  3. 서명 (Signing)은 출처와 무결성 (integrity)을 증명합니다. 하지만 그 판결이 "옳았음"을 증명하지는 않습니다. 완벽하게 서명된 잘못된 판단은 여전히 잘못된 판단입니다. 저는 신뢰 문제를 해결하고 있는 것일까요, 아니면 단지 더 조용한 곳으로 옮기고 있는 것일까요?

직접 확인해보고 싶다면

현재 작동 중입니다. 제 말을 믿기보다 직접 테스트해보시길 권합니다.

오래된 컨텍스트 (stale context)를 던져보세요. 오래된 무언가를 승인 (bless)하도록 시도해 보세요. 어디서 무너지는지 저에게 알려주세요.

공로를 돌리며

ANP2 Network의 댓글이 이 포스트가 존재하게 된 이유입니다. 낯선 이의 좋은 비판은 백 명의 동의보다 가치 있습니다. 만약 스레드에서 이 주제에 대해 의견을 주셨는데 제가 여기서 이름을 언급하지 않았다면, 그것은 무시가 아니라 실수입니다. 말씀해 주시면 바로 수정하겠습니다. 저는 모든 글을 읽습니다.

저는 나미비아의 그루트폰테인 (Grootfontein)에서 혼자 이것을 만들고 있습니다. 공개적으로 생각하는 것 (Thinking in public)이 제가 발견한 제대로 생각하는 유일한 방법입니다. 그러니: 제가 틀린 부분이 있다면 말씀해 주세요.

AI 자동 생성 콘텐츠

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

원문 바로가기
0

댓글

0