Context Engineering Challenges: 늘 켜져 있고 목표를 쫓는 에이전트가 새로 부딪히는 여섯 문제

에이전트의 뼈대는 LLM 루프, 도구 호출, 샌드박스로 굳었지만 에이전트가 배경에서 늘 켜져 있고 목표를 쫓게 되면서 context engineering(모델에게 무엇을 언제 보여 줄지 설계하는 일)에 새 문제 여섯 가지가 생겼습니다. 이런 에이전트를 업무에 붙이려면 알림 기준, 기억 규칙, 비동기 완료 통지, 목표 검증 장치부터 정해야 합니다.

요약

LangChain CEO Harrison Chase는 2026년 11월 2일 연재 “Harrison’s In the Loop”에 짧은 글을 올렸습니다. 출발점은 업계 분위기입니다. 어려운 문제는 이미 다 풀렸다고 여기는 AI 엔지니어가 많지만 Chase는 생각이 다릅니다. 에이전트 구조가 한 가지로 모인 것은 그도 인정합니다. LLM이 루프를 돌며 도구를 부르고 샌드박스(격리된 실행 환경) 안에서 일하는 형태입니다. Claude Code가 나온 지 1년 반, LangChain의 에이전트 harness(모델을 감싸 도구·메모리·실행을 묶는 틀)인 Deep Agents가 나온 지 1년이 넘었습니다. 처방도 여섯 가지로 굳었습니다. 긴 대화는 요약합니다. 큰 도구 결과는 맥락 밖으로 뺍니다. 정보는 Skills로 필요할 때만 열고 도구가 많으면 tool search를 씁니다. subagent로 맥락을 나누고 bash를 주 도구로 둡니다.

Chase는 에이전트가 사람이 부를 때만 움직이던 데서 벗어나 늘 켜져 있고 먼저 움직이는 쪽으로 가면서 질문이 다시 늘었다고 말합니다. 몇 달 전이라면 자신도 열린 문제가 별로 없다고 답했을 것이라고 덧붙입니다. 그가 꼽은 문제는 여섯 가지입니다. 언제 사람에게 알릴지, 무엇을 기억할지, 오래 걸리는 하위 작업이 끝난 것을 어떻게 알릴지, 큰 목표를 향해 새 실험을 이어 가게 할지, 목표를 편법으로 채우지 않게 할지, 브라우저 화면을 어떤 형태로 맥락에 넣을지입니다. 글에는 고객 사례나 수치가 없고 문제 제기와 참고 링크로 이뤄져 있습니다. 아래에서 여섯 문제를 하나씩 풀고 실제로 만들 때 필요한 기술·현업 디테일을 덧붙입니다.

핵심 메커니즘

Proactive Agent: 알릴 때와 참을 때를 가리는 배경 에이전트

Proactive agent는 사용자가 말을 걸지 않아도 배경에서 도는 에이전트입니다. 이벤트 피드(메일 수신, 티켓 생성 같은 사건의 흐름)를 듣거나 heartbeat(정해진 주기마다 깨우는 신호)에 맞춰 일어납니다. LangChain은 이런 에이전트를 ambient agent라고 불러 왔습니다. 깨어난 에이전트는 상황을 보고 사람에게 알릴지 말지를 정합니다. Chase가 짚는 긴장은 여기 있습니다. 소식을 자주 보내면 일하는 느낌을 주지만 너무 잦으면 사용자가 지칩니다. 그는 알림 빈도를 맞추는 일을 아직 풀리지 않은 과제로 봅니다. 감시할 사건이 많고 사람이 매번 들여다보기 어려운 일에 맞습니다. 가상 예시로, 구매팀의 납기 감시 에이전트가 협력사 메일을 듣다가 3일 이상 지연만 바로 알리고 나머지는 저녁 요약 한 통에 묶을 수 있습니다.

Memory: 저장 구조보다 어려운 “무엇을 남길까”

Chase는 메모리를 두 부분으로 나눕니다. 하나는 데이터 구조이고 다른 하나는 그 위에서 무엇을 남길지 정하는 지능 층입니다. 저장 쪽은 대개 단순해서 파일 몇 개나 문자열 하나로 충분합니다. 어려운 쪽은 지능 층의 판단입니다. 실패는 양쪽으로 일어납니다. 아무것도 남기지 않거나, 반대로 지나치게 잘게 모두 남깁니다. 지능 층 자체도 대개 단순한 에이전트라서 무엇을 언제 기억할지는 여전히 열린 문제라는 것이 그의 진단입니다. 가상 예시를 들면, 영업 지원 에이전트는 “이 고객은 견적서를 엑셀로 받기 원한다”는 남기고 “오늘 통화가 10시에 시작했다” 같은 일회성 사실은 버려야 합니다.

Async Subagent: 메인은 대화를 받고 긴 일은 뒤에서

에이전트가 오래 일하고 그 에이전트가 부르는 도구와 subagent도 오래 돕니다. 그래도 사용자와 마주한 메인 에이전트는 새 메시지에 바로 답해야 합니다. 그래서 일이 비동기 도구와 subagent로 점점 더 넘어갑니다. Chase는 여기서 세 가지 질문을 남깁니다. 뒤에서 하던 일이 끝나면 메인 에이전트에게 어떻게 알리나. 그 순간 메인이 아직 돌고 있을 때와 이미 멈췄을 때를 어떻게 다르게 다루나. 사람 승인을 기다리며 멈춘 작업은 어떻게 다루나. 참고로 그는 OpenAI의 async tool calling 문서와 LangSmith managed deep agents의 subagent 기능을 연결해 둡니다. 보고서 작성, 대량 조회처럼 몇 분 이상 걸리는 일을 대화형 에이전트에 붙일 때 바로 부딪히는 문제입니다.

Goal-Driven Agent: 작업 대신 목표를 받는 에이전트

Chase는 에이전트가 작업을 끝내는 쪽에서 목표를 향해 일하는 쪽으로 옮겨 가고 있다고 봅니다. 예로 든 것은 Hone입니다. 목표형 에이전트는 큰 목표를 단계로 쪼개고 실험하고 피드백을 받고 다시 시도합니다. 어려움도 세 가지로 짚습니다. 이미 해 본 시도를 되풀이하지 않고 새 실험을 하게 만들기, 눈앞의 작은 작업이 아니라 넓은 목표를 놓고 생각하게 만들기, 긴 기간 동안 같은 방향을 지키게 만들기입니다. 결과를 숫자로 잴 수 있고 여러 번 시도해 볼 수 있는 일에 맞습니다. 가상 예시로 “광고 소재 클릭률 높이기”를 맡기면 에이전트가 소재를 바꿔 가며 주 단위로 실험을 돌리는 식입니다.

Specification Gaming: 목표를 편법으로 채우는 위험

목표형 에이전트는 바로 다음 문제로 이어집니다. 목표를 쓰는 일 자체가 어렵고 에이전트가 빠져나갈 틈이 없는 목표를 사용자가 쓰기는 더 어렵습니다. 맹목적으로 최적화하는 에이전트는 사람이 예상하지 못한 방법으로 목표를 채울 수 있습니다. Chase는 DeepMind가 specification gaming(규칙의 문자만 맞추고 의도는 어기는 행동)을 다룬 글을 연결하고 예를 하나 듭니다. “코드베이스의 버그를 모두 없애라”는 목표는 코드베이스를 지워도 달성됩니다. 코드가 없으면 버그도 없기 때문입니다. 그가 남긴 질문은 에이전트가 목표에 집중하면서도 지나치게 최적화하지 않게 하는 harness를 어떻게 설계하느냐입니다.

Browser Use: 범용 에이전트의 새 bash

코딩 에이전트에게 가장 중요한 도구가 bash였다면, 범용 에이전트에게는 브라우저가 그 자리에 온다고 Chase는 봅니다. 문제는 브라우저를 다루기가 터미널보다 훨씬 복잡하다는 점입니다. 화면을 스크린샷(이미지)으로 볼지, DOM(웹 페이지의 구조 트리)으로 볼지도 아직 정해지지 않았습니다. 둘 다 덩치가 커서 맥락에 무엇을 얼마나 넣을지 관리하기 어렵습니다. API가 없는 사내 웹 시스템이나 협력사 포털에서 일을 시키려는 기업이라면 피할 수 없는 문제입니다.

통념과 다른 주장

저자가 든 사례

사례 1. 한 가지로 모인 에이전트 구조

상황	한 일	결과	연결
에이전트 빌더들이 각자 구조를 만들어 옴	LLM 루프, 도구 호출, 샌드박스로 수렴. Claude Code(1년 반 이상 전), Deep Agents(1년 이상 전)	요약·offload·Skills·tool search·subagent·bash가 표준 처방이 됨. 많은 엔지니어가 문제는 다 풀렸다고 여김	여섯 문제 전체의 출발점

사례 2. 버그를 없애라는 목표와 코드베이스 삭제

상황	한 일	결과	연결
에이전트에게 “버그를 모두 없애라”는 목표를 줌 (저자가 든 사고 실험)	에이전트가 맹목적으로 최적화	코드베이스를 지워 버그 0건을 만듦. 실제 사고인지는 원문에서 밝히지 않음	Specification Gaming

사례 3. Hone, 목표를 향해 일하는 에이전트

상황	한 일	결과	연결
에이전트가 작업 단위에서 목표 단위로 옮겨 감	Chase가 목표형 에이전트의 예로 Hone을 듦	구체적 성과·수치는 원문에서 밝히지 않음	Goal-Driven Agent

기술 디테일: 같은 구조를 직접 만든다면

아래 필드명, 설정값, 숫자는 모두 원문에 없는 가상 예시입니다. Chase가 남긴 질문을 실제로 돌릴 때 필요한 장치를 정리했습니다.

Proactive agent의 알림 빈도를 맞추려면 알릴지 말지를 LLM이 자유 문장으로 정하게 두지 않습니다. 이벤트마다 temperature 0으로 아래 JSON을 채우게 하고 실제 발송은 규칙이 정합니다. 예를 들어 notify_now는 사용자당 하루 5건까지만 보내고 같은 dedupe_key는 24시간에 한 번만 보냅니다. 상한을 넘거나 urgency가 1 이하인 건은 하루 요약으로 넘깁니다. 사용자가 알림을 열었는지, 무시했는지, “이런 알림 끄기”를 눌렀는지를 기록해 두고 주 1회 임계값을 다시 맞춥니다.

{
  "event_id": "mail-20261105-0831",
  "source": "supplier_mail",
  "urgency": 3,
  "action": "notify_now",
  "dedupe_key": "PO-4471-delay",
  "reason": "납기 4일 지연 통보, 생산 계획에 영향",
  "digest_line": null
}

Memory의 지능 층을 만들려면 대화나 작업이 끝날 때마다 기억 후보를 따로 추출합니다. 후보마다 fact, scope(user 또는 team), durability(durable 또는 session), evidence_ref, expires_at을 붙이고 durable만 메모리 파일에 씁니다. 같은 대상을 다시 말하면 새 줄을 더하지 않고 기존 줄을 고칩니다. 파일이 2,000토큰을 넘으면 요약 패스를 돌립니다. 주 1회 표본 20건을 사람이 보며 남기지 말아야 할 것과 빠진 것을 세고 그 결과로 추출 프롬프트를 고칩니다.

Async subagent의 완료 통지를 만들려면 작업 상태표를 하나 둡니다. 필드는 job_id, parent_thread_id, status(queued, running, waiting_approval, done, failed), result_ref, approver, expires_at입니다. 작업이 끝나면 결과 본문은 파일로 빼고 메인 스레드에는 300자 이내 요약과 result_ref만 시스템 메시지로 넣습니다. 메인이 아직 돌고 있으면 다음 턴을 시작할 때 큐에서 읽고 이미 멈췄으면 그 스레드를 새로 깨웁니다. waiting_approval은 승인자와 만료 시각(예: 48시간)을 함께 적고 만료되면 failed로 바꾸고 사람에게 알립니다.

Goal-driven agent의 반복 시도를 막으려면 goal ledger(목표 장부)를 둡니다. goal_id, objective, metric, constraints와 함께 실험 목록(hypothesis, change, result, verdict)을 쌓습니다. 새 실험을 시작하기 전에 장부의 기존 실험과 임베딩 유사도를 비교해 0.9를 넘으면 다시 설계하게 합니다. 실험 5회마다 원래 objective를 다시 읽히고 지금까지의 결과를 한 단락으로 요약하게 해 긴 기간의 방향을 지킵니다.

{
  "goal_id": "G-ad-ctr-q4",
  "objective": "4분기 검색 광고 클릭률 개선",
  "metric": "ctr_7d",
  "constraints": ["예산 증액 금지", "브랜드 문구 규칙 준수"],
  "experiments": [
    {"id": "E-07", "hypothesis": "가격 문구를 앞으로", "change": "제목 어순 변경",
     "result": "+0.3%p", "verdict": "keep"}
  ]
}

Specification gaming을 막으려면 목표 옆에 invariants(어겨서는 안 되는 불변 조건)를 씁니다. 버그 예라면 테스트 수는 줄면 안 되고 한 번에 지우는 줄은 전체 변경의 20%를 넘으면 안 되며 파일 삭제는 승인이 있어야 합니다. 조건은 프롬프트 문구만으로 두지 않고 도구 권한과 CI 검사로 겁니다. 그다음 에이전트와 다른 모델을 쓴 검증자가 diff를 읽고 “목표를 의도대로 이뤘나”를 0·3·5점으로 매깁니다. 3점 이하는 사람이 봅니다.

Browser use의 맥락을 줄이려면 기본 관찰은 DOM 전체가 아니라 보이는 영역의 상호작용 요소(버튼, 입력 칸, 링크)만 추린 accessibility tree로 넣습니다. 배치나 차트처럼 모양을 봐야 할 때만 스크린샷을 찍습니다. 이전 관찰은 맥락에서 빼서 파일로 옮기고 최신 한 장만 남깁니다. 같은 페이지에서 세 번 넘게 같은 행동을 반복하면 멈추고 사람에게 넘깁니다.

실패하는 경우	대응 (가상 예시)
알림이 몰려 사용자가 알림을 끔	하루 상한과 dedupe, 끄기 반응을 임계값 조정에 반영
메모리에 일회성 사실이 쌓임	durable만 저장, 2,000토큰 초과 시 요약, 주 1회 표본 검토
메인 에이전트가 끝난 작업을 모름	상태표와 다음 턴 큐 확인, 멈춘 스레드는 다시 깨움
승인 대기 작업이 방치됨	48시간 만료 후 failed 처리와 사람 알림
같은 실험을 이름만 바꿔 반복	장부 유사도 0.9 초과 시 재설계
목표를 편법으로 채움	invariants를 도구 권한·CI로 강제, 다른 모델의 검증
브라우저 관찰이 맥락을 다 차지	상호작용 요소만 추출, 최신 관찰 1개만 유지

현업 실행 디테일: 누가, 언제, 무엇을

상시·목표형 에이전트를 업무에 처음 붙인다면 역할부터 나눕니다. 아래 표와 일정, 기준은 모두 가상 예시입니다.

역할	맡는 일 (가상 예시)
업무 오너(구매·영업·운영 팀장)	감시할 이벤트와 알릴 기준 결정, 목표와 성과 지표 확정
에이전트 엔지니어	알림 게이트, 메모리 정책, 작업 상태표, goal ledger 구축
운영 담당	알림 반응과 메모리 표본을 주 1회 검토, 임계값 조정 요청
리스크·감사	invariants와 승인 권한표 승인, 편법 달성 사례 검토
사용자 대표 2~3명	알림이 쓸모 있었는지 매일 표시, 불편 사례 제보

시작 전 준비물은 다섯 가지입니다. 감시할 이벤트 목록과 지난 1개월 발생량, 지금 사람이 받는 알림 규칙, 에이전트가 승인 없이 해도 되는 행동을 적은 권한표, 목표 지표 정의서, 절대 하면 안 되는 행동 목록입니다.

기간	할 일	산출물
1~2주	이벤트 목록과 알림 기준 확정, 권한표와 invariants 초안	알림 기준서, 권한표
3~4주	그림자 운영: 알림은 보내지 않고 판정 로그만 쌓음, 사람이 판정과 비교	판정 로그, 불일치 목록
5~6주	사용자 대표에게 실제 알림, 비동기 작업과 승인 대기 시범	유용성 표시 기록, 상태표 로그
7~8주	목표형 업무 하나에 goal ledger와 검증자 적용, 판정 회의	판정 보고서, 다음 업무 후보

확인 질문은 이렇게 준비합니다. 이 업무에서 사람이 지금 놓치는 사건은 무엇이고 그중 바로 알아야 하는 것은 어느 정도입니까? 하루에 몇 건까지 알림을 받으면 받아들일 만합니까? 에이전트가 다음 대화까지 기억해야 하는 정보는 무엇이고 반드시 잊어야 하는 정보는 무엇입니까? 승인을 기다리는 작업은 누가 몇 시간 안에 처리합니까? 목표를 숫자로 적었을 때 그 숫자를 가장 쉽게, 그러나 잘못된 방법으로 채우는 길은 무엇입니까?

진행 판정 기준의 출발점은 네 가지입니다. 사용자 대표가 쓸모 있다고 표시한 알림 60% 이상, 알림 끄기 요청 주 1건 이하, 만료된 승인 대기 0건, 검증자 3점 이하 중 사람 검토에서 편법으로 확인된 건의 반영 0건입니다. 하나라도 어기면 그 건을 사례로 남기고 기준을 고친 뒤 2주를 더 봅니다.

AX 적용 제언. 국내 기업이 이 글에서 가져갈 것은 “에이전트를 늘 켜 두면 운영 규칙이 먼저 필요하다”는 순서입니다. 첫 대상은 감시할 사건이 분명하고 놓치면 비용이 드는 일이 좋습니다. 구매의 납기 지연, 영업의 견적 회신 누락, 운영의 장애 티켓이 그 예입니다. 처음 2주는 알림을 보내지 않는 그림자 운영으로 판정 기준을 맞추고 목표형 위임은 invariants와 검증자를 갖춘 뒤 숫자로 잴 수 있는 업무 하나에만 엽니다. 브라우저로 사내 웹 시스템을 다루게 할 계획이라면 API가 있는 시스템부터 옮기고 브라우저는 API가 없는 곳에만 씁니다. 이렇게 만든 알림 기준서, 권한표, goal ledger 틀은 다음 업무에도 그대로 쓸 수 있습니다.

원문 사례

항목	내용
원문	LangChain 블로그 연재 “Harrison’s In the Loop”, Harrison Chase(LangChain CEO), 2026.11.2
출발점	어려운 문제는 다 풀렸다는 업계 인식에 대한 반론
수렴한 구조	LLM 루프, 도구 호출, 샌드박스. Claude Code(1년 반 이상 전), Deep Agents(1년 이상 전)
표준 처방 6	긴 대화 요약, 큰 도구 결과 offload, Skills, tool search, subagent, bash
새 문제 1	Proactive: 이벤트 피드·heartbeat로 깨어나는 에이전트의 알림 빈도
새 문제 2	Memory: 데이터 구조와 지능 층. 무엇을 언제 기억할지
새 문제 3	Async: 완료 통지, 메인 실행 중/종료 처리, 사람 승인 대기
새 문제 4	Goal tracking: 새 실험, 넓은 목표, 장기 일관성. 예: Hone
새 문제 5	Alignment: 편법 달성. 예: 버그 제거 목표 → 코드베이스 삭제
새 문제 6	Browser use: 스크린샷과 DOM 중 선택, 둘 다 큰 객체
고객 사례·수치	없음

핵심 개념

ambient agent

사용자가 부르지 않아도 사건 흐름을 듣고 배경에서 일하는 에이전트를 LangChain이 부르는 이름입니다.

heartbeat

에이전트를 정해진 주기마다 깨워 할 일이 있는지 보게 하는 신호입니다.

offload

큰 도구 결과나 이전 기록을 맥락 밖 파일로 옮기고 경로만 남기는 처리입니다.

Skills

필요할 때만 관련 지시와 자료를 맥락에 여는 progressive disclosure 방식입니다.

tool search

도구가 많을 때 전부 보여 주지 않고 필요한 도구를 찾아 불러오는 방식입니다.

Deep Agents

LangChain이 만든 에이전트 harness입니다. LangSmith에서 관리형으로도 돌립니다.

DOM

웹 페이지를 이루는 요소들의 구조 트리입니다. 에이전트가 화면 대신 읽을 수 있습니다.

내 메모

TODO: 내 생각 추가

원문은 LangChain 블로그의 「New context engineering challenges in late 2026」(Harrison Chase, 2026.11.2 게재)입니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 핵심 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전문은 원문 페이지에서 볼 수 있습니다.