에이전트 구축은 쉬워졌지만, 다음 전선은 컨텍스트다

URL: https://www.youtube.com/watch?v=HvMyYLTfvhg 날짜: 2026-08-22 채널: aiDotEngineer 원문 제목: Building Agents Is Trivial Now, Context Is the Next Frontier — Jeff Ng, Unblocked 발표자: Jeff Ng, Unblocked founding engineer 재생 시간: 802초

---

📌 핵심 질문 / 이 발표를 관통하는 핵심 논점

==에이전트를 실제 서비스로 배포하는 기술적 장벽은 빠르게 낮아졌지만, 에이전트가 안정적으로 일하게 만드는 다음 장벽은 모델 지능이 아니라 조직의 컨텍스트(context)다.==

• 6개월 전만 해도 에이전트 하나를 생산 환경에 올리는 데 팀의 노력과 약 한 분기가 필요했지만, Cloudflare·Vercel·AWS 같은 인프라 제공자와 프레임워크가 상태 저장·샌드박스·관측성의 복잡성을 흡수했다.
• 에이전트는 코드와 현재 티켓만 보고서는 조직의 결정 이유, 과거 장애, 후속 조치를 알 수 없어서 자신 있게 틀린 답을 낸다.
• Slack 대화, 문서, 코드, 티켓과 같은 분산된 자료를 권한에 맞게 연결하고 충돌을 해소해 에이전트가 쓸 수 있는 합성된 답으로 바꾸는 컨텍스트 엔진(context engine)이 필요하다.

Jeff Ng의 결론은 에이전트의 실패 원인이 언제나 추론 능력 부족인 것은 아니라는 데 있다. 조직의 지식과 의도가 여러 시스템에 흩어져 있을 때, 사람은 그 사이를 연결해 주지만 자율 에이전트는 연결 고리를 갖지 못한다. 따라서 다음 경쟁력은 더 많은 모델 호출이 아니라 필요한 순간에 올바른 조직 지식을 좁혀 제공하는 컨텍스트 계층이다.

1. 에이전트 구축 난이도의 급격한 하락

에이전트의 핵심 모델 호출을 작성하는 일은 쉬워졌지만, 생산 서비스로 만들기 위한 주변 시스템은 오랫동안 별도의 큰 엔지니어링 과제였다.

1.1. 에이전트는 모델과 도구의 조합만이 아니다

1. 6개월 전의 개발 비용

   1. 약 6개월 전에는 에이전트 하나를 완성하는 데 팀의 노력과 사실상 한 분기(quarter)가 필요했다.
   2. 그 기간에는 모델을 고르고 도구를 연결하는 일뿐 아니라, 장시간 실행·상태 관리·보안 실행 환경·실패 추적까지 생산 서비스에 필요한 전부를 만들어야 했다.

2. 생산 에이전트의 실제 구성

   1. 에이전트는 모델(models)과 도구(tools)만으로 끝나지 않는다.
   2. 모델과 도구를 운영 가능한 서비스로 감싸는 모든 구성요소가 에이전트의 일부다.
   3. 당시 각 구성요소는 사실상 독립 회사이거나 최소한 회사 안의 독립 기능 하나에 해당할 정도로 규모가 컸다.

3. 개발자가 집중하고 싶은 핵심

   1. 주변 인프라가 해결되면 개발자는 팀에 실제 가치를 주는 에이전트의 핵심 로직에 더 많은 시간을 쓸 수 있다.
   2. Jeff Ng가 강조한 변화는 에이전트의 아이디어를 구현하는 난이도와 생산 환경에서 버티게 하는 난이도가 분리되기 시작했다는 점이다.

1.2. 생산 배포를 위한 세 가지 세금

에이전트의 능력을 직접 높이지 않으면서도 반드시 지불해야 했던 대표적인 비용은 체크포인트와 상태 지속성, 샌드박스 인프라, 관측성이다.

1. 체크포인트와 상태 지속성(checkpoint and state persistence)

   1. 에이전트 실행은 대체로 오래 지속되고(long-lived) 상태를 가진다(stateful).
   2. 반면 에이전트를 실행하는 인프라는 본질적으로 일시적(ephemeral)이다.
   3. 내구성(durability) 없이 프로세스가 충돌하면 메시지 기록, 도구 호출 기록, 현재 루프에서 어디까지 진행했는지와 같은 상태가 사라진다.
   4. 상태가 없으면 같은 세션을 이어서 재개할 수 없다.

2. 충돌 뒤 세션 재시작의 비용

   1. 가장 단순한 대안은 세션을 처음부터 다시 시작하는 것이다.
   2. 재시작하면 앞서 사용한 토큰을 잃으므로 비용이 커진다.
   3. 사용자가 이미 실행을 시작했는데 처음부터 다시 기다려야 하므로 지연시간(latency)과 사용자 경험도 악화된다.
   4. 기존 실행이 데이터 변경이나 다른 외부 효과(side effect)를 수행했다면, 재실행으로 같은 효과가 두 번 발생할 위험도 있다.

3. 샌드박스 인프라(sandbox infrastructure)

   1. 에이전트가 생성한 코드와 서드파티 코드가 점점 더 많이 조직의 인프라에서 실행된다.
   2. 실행 코드는 환경 변수에 들어 있는 비밀(environment secrets)을 불필요하게 읽거나, 필요 이상으로 네트워크에 접근할 수 있다.
   3. 격리된 샌드박스(isolated sandbox)는 이런 불필요한 비밀 읽기와 네트워크 접근을 막는 경계를 제공한다.
   4. 한 에이전트의 코드가 공유 호스트(shared host) 전체를 중단시키는 사고도 방지해야 한다.

4. 관측성(observability)

   1. 에이전트가 실패했을 때 “어디서 실패했는가?”라는 질문에 답해야 한다.
   2. 실제로는 약 6개 시스템에 걸친 로그와 트레이스(logs and traces)를 수집하고 서로 연결해야 원인을 찾을 수 있다.
   3. 이 작업은 에이전트의 추론 능력이나 업무 능력을 개선하지 않지만, 운영 가능한 서비스라면 빠질 수 없다.

5. ‘세금’이라는 성격

   1. 체크포인트, 샌드박스, 관측성은 에이전트가 더 똑똑해지도록 만드는 기능이 아니다.
   2. 생산 환경에 배포하기 위해 누구나 부담해야 하는 운영 세금에 가깝다.
   3. 과거에는 이 세금을 직접 내기 위해 팀 전체가 긴 시간을 투입해야 했다.

2. 인프라 프리미티브가 에이전트 구현을 단순화하다

클라우드 생태계가 성숙하면서 생산 배포의 공통 문제를 인프라 프리미티브(primitive)와 프레임워크가 대신 떠안기 시작했다.

2.1. 클라우드와 프레임워크의 역할 분담

1. 복잡성을 흡수한 인프라 제공자

   1. Cloudflare, Vercel, AWS 같은 클라우드 인프라 사업자가 에이전트 운영에 필요한 일부 복잡성을 공통 프리미티브로 만들었다.
   2. 상태가 있는 장기 실행, 격리된 코드 실행, 배포와 운영 같은 문제를 애플리케이션마다 처음부터 다시 구현할 필요가 줄었다.

2. 프레임워크의 조합

   1. Flue(자막에는 flu로 들림), Vercel 계열 도구, E2B, Mastra와 같은 프레임워크·실행 계층이 이런 프리미티브를 활용한다.
   2. 프리미티브와 프레임워크가 함께 제공되면 개발자는 공통 인프라가 아니라 에이전트의 업무 로직에 집중할 수 있다.
   3. Jeff Ng가 “생태계 전체가 꽤 성숙했다”고 말한 배경이 여기에 있다.

2.2. 에이전트 정의에 필요한 최소 요소

1. 코드 양의 변화

   1. Jeff Ng는 Flue와 Cloudflare를 직접 사용해 보면서, 예전에는 별도 시스템이었던 기능이 왼쪽의 인프라 계층에서 처리되는 모습을 보여 줬다.
   2. 프리미티브와 프레임워크를 조합하면 에이전트를 정의하는 코드는 생각보다 많지 않다.
   3. 문서를 처음 봤을 때 필요한 설정이 놀랄 만큼 단순하다는 인상을 받았다고 했다.

2. 에이전트 정의의 다섯 가지 결정

   1. 모델(model): 어떤 모델을 사용할지 결정한다.
   2. 지시사항(instructions) 또는 시스템 프롬프트(system prompt): 에이전트가 어떤 목표와 규칙으로 행동할지 지정한다.
   3. 도구(tools): 에이전트가 실제로 호출할 수 있는 기능을 정한다.
   4. 스킬(skills): 에이전트가 수행할 수 있는 작업 단위를 정한다.
   5. 샌드박스 위치(sandbox location): 코드와 작업이 어느 격리 실행 환경에서 수행될지 정한다.

3. 단순화의 의미

   1. 이 다섯 가지 결정이 핵심이 되면 개발자는 상태 저장·호스트 격리·실행 추적의 구현 세부사항에서 벗어날 수 있다.
   2. 에이전트를 배포하는 행위가 쉬워질수록, 사람의 감독 없이 에이전트가 맥락을 놓치는 문제가 더 선명하게 드러난다.

3. Linear 이슈 보강 데모가 드러낸 ‘자신 있게 틀리기’ 문제

코드와 티켓만 검색한 에이전트는 그럴듯한 계획을 만들 수 있지만, 과거 장애와 조직의 의사결정까지 알지 못하면 위험한 권고를 낸다.

3.1. 이슈 보강 시스템의 작업 흐름

1. 입력과 접근 권한

   1. Jeff Ng는 Linear용 이슈 보강(issue enrichment) 시스템을 직접 만들었다.
   2. 시스템은 Linear 티켓 하나와 코드 저장소 접근 권한을 입력으로 받는다.

2. 기본 분석 순서

   1. Linear에서 해당 티켓을 가져온다.
   2. 티켓이 기능(feature)인지 버그(bug)인지 판별한다.
   3. 코드 저장소를 검색해 관련 코드와 맥락을 수집한다.
   4. 수집한 정보를 에이전트에 전달하고 다음 단계의 실행 계획을 만들게 한다.

3. 문제의 출처

   1. 화면 왼쪽의 도구와 스킬은 티켓 가져오기, 코드 검색, 질의(query)를 수행한다.
   2. 검색 결과가 에이전트로 돌아오면 에이전트가 결과를 바탕으로 추론하고 Linear 티켓을 갱신한다.

3.2. QA 파이프라인 장애 사례

1. 티켓의 배경

   1. 동료 지원 엔지니어가 약 한 달 전에 올린 이슈가 출발점이었다.
   2. 에이전트 기반 QA 파이프라인(agentic QA pipeline)이 심각하게 느려지는 문제가 있었다.
   3. 첫 문자가 나타나는 시간(time to first character)이 현실적인 목표인 수백 밀리초가 아니라 3~4초까지 늘어나 있었다.

2. 코드와 티켓만 본 권고

   1. 에이전트는 주어진 스킬과 도구로 코드를 가져오고 검색하고 질의했다.
   2. 분석이 끝난 뒤 Linear 이슈를 갱신했다.
   3. 권고는 비동기 디스패치(async dispatch)를 다시 활성화하자는 것이었다.
   4. 비동기 디스패치를 켜면 한 대의 머신에서 QA 파이프라인을 더 많이 병렬로 실행할 수 있으므로, 코드와 현재 티켓만 놓고 보면 합리적인 권고였다.

3. 권고가 실제로는 틀린 이유

   1. 비동기 디스패치 재활성화는 며칠 뒤 실제 장애를 일으켰다.
   2. 지원 엔지니어는 해당 기능을 이미 명시적으로 비활성화해 둔 상태였다.
   3. 에이전트는 티켓이 만들어진 뒤 엔지니어들이 Slack에서 나눈 논의를 보지 못했다.
   4. 그 Slack 논의에는 실제 장애가 무엇이었는지, 무엇이 잘못됐는지, 어떤 수정이 이뤄졌는지, 다음 단계가 무엇인지가 담겨 있었다.
   5. 후속으로 만들어진 사후 분석(postmortem) Linear 티켓도 검색하지 못했다.
   6. 따라서 에이전트는 문제를 좁은 범위로만 이해했고, 과거 장애를 막기 위해 내려진 비활성화 결정을 되돌리려 했다.

4. 문제의 일반화

   1. 지식과 의도는 한 조직 안의 여러 시스템에 흩어져 있다.
   2. 현재 티켓과 소스 코드에만 접근하는 에이전트는 그 지식과 의도의 연결 관계를 복원하지 못한다.
   3. “없는 정보”가 답변에 드러나지 않으면 에이전트는 불확실성을 표시하기보다 확신에 찬 잘못된 권고를 내릴 수 있다.

4. 사람이 담당하던 컨텍스트 계층과 새로운 실패 방식

로컬 개발에서 문제가 덜 보이는 이유는 인간 엔지니어가 매 턴마다 빠진 배경지식을 공급하고 오류를 잡아 주기 때문이다.

4.1. 인간이 맡아 온 숨은 역할

1. 사람이 연결하는 배경지식

   1. 엔지니어는 에이전트에게 질문을 던지고, 이상한 답을 찾아내고, 빠진 사실을 매번 보충한다.
   2. 사람은 코드가 현재 방식으로 작성된 이유를 알고 있다.
   3. 사람은 과거에 무엇이 고장 났는지 알고 있다.
   4. 사람은 그 문제를 두고 조직이 무엇을 하기로 결정했는지 알고 있다.

2. 에이전트가 실제로 보는 범위

   1. 에이전트는 지시사항과 도구·스킬, 접근이 허용된 코드, 눈앞의 티켓을 본다.
   2. Slack의 결정 과정, 문서의 운영 원칙, 과거 장애와 사후 분석은 명시적으로 연결하지 않으면 보이지 않는다.
   3. 사람과 에이전트가 함께 일할 때 사람은 방향을 조정하고(steer), 실수를 잡아내며, 맥락을 공급한다.

3. ‘베이비시팅’의 숨은 비용

   1. 인간이 루프 안에 있으면 에이전트의 틀린 결론이 외부 시스템에 반영되기 전에 차단된다.
   2. 그 결과 사람은 에이전트를 사실상 계속 돌보는(babysit) 역할을 맡는다.
   3. 에이전트 배포가 Flue와 Cloudflare 조합처럼 쉬워지고 사람 없는 실행이 늘어날수록, 사람이 대신 맡던 연결 작업이 사라진다.

4.2. 컨텍스트 부재가 만드는 조용한 실패

1. 자율 실행에서의 위험

   1. 사람의 감독이 없는 에이전트는 빠진 맥락을 스스로 알고 있다고 표시하지 않을 수 있다.
   2. 누락된 맥락은 오류 메시지가 아니라 조용한 실패(silent failure)로 나타난다.
   3. 에이전트가 조직의 직관과 경험을 대신해야 하지만, 코드와 티켓만으로는 그 역할을 수행할 수 없다.

2. 컨텍스트 엔진의 필요성

   1. 흩어진 지식과 의도를 운반할 별도의 계층이 필요하다.
   2. 그 계층이 바로 컨텍스트 엔진(context engine)이다.

4.3. 컨텍스트 엔진의 정의와 동작

1. 업무와 주체를 기준으로 정보 선택

   1. 컨텍스트 엔진은 사용자가 누구인지, 현재 무엇이 중요한지를 기준으로 작업과 관련된 정보를 제공한다.
   2. 사람마다 접근 권한이 다르듯 에이전트마다 허용된 접근 역할(access role)이 다르다는 사실을 반영한다.

2. 여러 데이터셋의 충돌 해소

   1. 서로 다른 데이터셋에서 상충하는 정보가 나오면 단순히 모두 전달하지 않고 충돌을 해소한다.
   2. 권한 범위를 넘어선 정보는 제공하지 않는다.
   3. 관련성이 낮은 기록을 무작정 붙이는 대신, 현재 작업에 필요한 정보만 남긴다.

3. 합성된 결과 제공

   1. 컨텍스트 엔진의 목표는 원문 파일 더미를 반환하는 것이 아니라 합성된(synthesized) 업무 맥락을 전달하는 것이다.
   2. 에이전트는 수십 개 자료를 다시 읽고 서로 비교하는 대신, 권한에 맞게 정리된 이해를 받아 다음 행동에 집중할 수 있다.

5. 조직의 흩어진 지식을 에이전트가 사용할 수 있는 형태로 만들기

에이전트가 일상 업무에 필요한 것은 소스 코드만이 아니라 결정이 생성되고 보존되는 조직 전체의 정보 구조다.

5.1. 코드 바깥의 중요한 컨텍스트

1. 업무에 필요한 자료의 범위

   1. 사람의 일상 업무는 코드만 읽는 것으로 구성되지 않는다.
   2. Slack 대화에는 결정이 이뤄지는 과정이 남는다.
   3. 문서에는 팀이 따르는 모범 사례와 운영 방식이 정리된다.
   4. 티켓에는 문제의 요청, 진행 상황, 담당자와 후속 조치가 남는다.
   5. 코드에는 실제 구현과 현재 시스템의 동작이 남는다.

2. 에이전트에도 같은 범위가 필요하다

   1. 코드만 주고 조직의 대화·문서·티켓을 숨기면, 에이전트는 구현은 읽어도 결정의 이유는 읽지 못한다.
   2. 안정적인 업무 수행에는 docs, code, tickets, conversations를 함께 연결해야 한다.

5.2. 조직 모델과 권한 필터링

1. 조직과 시스템의 모델 구축

   1. Unblocked는 문서, 코드, 티켓, 대화를 연결한다.
   2. 연결된 자료를 바탕으로 조직의 모델과 시스템의 모델을 만든다.
   3. 각각의 자료가 서로 어떻게 연관되는지까지 모델에 포함한다.

2. 에이전트에게 전달되는 데이터의 범위

   1. 전체 조직 모델을 그대로 에이전트의 컨텍스트 창에 넣지 않는다.
   2. 현재 작업과 관련된 데이터의 한 조각(slice)만 추출한다.
   3. 그 조각은 여러 자료의 충돌을 조정하고(reconciled), 관련도에 따라 순위를 매기고(ranked), 접근 권한으로 범위를 제한한(scoped to permissions) 결과다.

3. 입력과 출력의 변화

   1. 입력에는 여러 시스템에 흩어진 컨텍스트(scattered context)가 들어온다.
   2. 출력에는 권한과 작업 관련성이 반영된 근거 있는 컨텍스트(grounded context)가 나온다.
   3. 핵심 변환은 “흩어진 컨텍스트가 들어오고, 근거 있는 컨텍스트가 나온다(Scattered context comes in, grounded context comes out)”로 요약된다.

6. MCP는 접근을 주지만 이해를 보장하지 않는다

Slack·Linear·GitHub를 MCP로 연결하는 것만으로는 에이전트가 조직의 의미와 우선순위를 자동으로 이해하지 못한다.

6.1. MCP 연결만으로 해결되지 않는 문제

1. 가능한 연결 구성

   1. Slack MCP, Linear MCP, GitHub MCP를 각각 연결하면 각 시스템의 데이터에 접근할 수 있다.
   2. MCP는 여러 도구를 에이전트 앞에 노출하는 훌륭한 접근 계층이다.

2. 접근(access)과 이해(understanding)의 차이

   1. MCP가 돌려주는 것은 대체로 원시 결과(raw result)다.
   2. 어떤 결과를 믿을지, 어떤 정보가 최신인지, 서로 충돌할 때 어느 결정을 따라야 할지는 여전히 에이전트가 판단해야 한다.
   3. 즉 MCP는 “데이터에 닿게 하는 것”을 해결하지만 “무엇이 중요한지 이해하는 것”을 보장하지 않는다.

3. 컨텍스트 창과 비용 문제

   1. 관련 없는 결과까지 에이전트에 전달하면 컨텍스트 창(context window)이 불필요한 자료로 채워진다.
   2. 입력 토큰이 늘어나면서 전체 컨텍스트 비용도 올라간다.
   3. 데이터가 많다고 이해가 깊어지는 것이 아니라, 오히려 에이전트가 무엇을 믿어야 하는지 판단해야 하는 부담이 커진다.

4. 충돌 판단의 전가

   1. Linear MCP와 Slack MCP가 서로 다른 결과를 반환할 수 있다.
   2. 이때 어떤 기록이 원인이고 어떤 기록이 후속 결정인지 정리되지 않으면 에이전트가 그 판단을 즉흥적으로(ad hoc) 내려야 한다.
   3. 조직 차원의 지식 정리 문제를 로컬 에이전트의 한 번의 추론에 맡기는 방식은 QA 파이프라인 사례와 같은 오류를 반복시킬 수 있다.

6.2. 컨텍스트 엔진을 연결한 같은 Linear 이슈

1. 연구 단계의 변경

   1. 같은 파일과 같은 에이전트를 유지한 채 Unblocked에 티켓을 연구하고 관련 컨텍스트를 제공하라고 요청한다.
   2. 에이전트는 Linear 티켓을 가져오는 기본 흐름에 더해 Unblocked 컨텍스트 엔진을 호출한다.

2. 추가로 발견된 근거

   1. 컨텍스트 엔진은 관련 Linear 사후 분석(postmortem) 티켓을 찾았다.
   2. 장애 원인과 해결 과정이 논의된 엔지니어링 팀의 Slack 대화도 찾았다.
   3. 여러 원문을 단순히 나열하지 않고 그 자료들에서 도출한 이해를 요약해 에이전트에 전달했다.

3. 권고의 질적 변화

   1. 에이전트는 더 이상 여러 문서를 처음부터 스스로 읽고 근거를 조합할 필요가 없었다.
   2. 비동기 디스패치를 다시 켜서 성능을 높이자는 위험한 권고가, 해당 기능을 다시 활성화해 또 다른 장애를 일으키지 않도록 막는 권고로 바뀌었다.
   3. 컨텍스트 엔진은 모델을 바꾸지 않고도 같은 에이전트의 결론을 “또 다른 장애를 유발하는 방향”에서 “또 다른 장애를 예방하는 방향”으로 전환했다.

7. 컨텍스트 계층의 확장 가능성

티켓 보강은 하나의 예시일 뿐이며, 조직의 제도적 지식과 암묵지(tribal knowledge)가 필요한 모든 업무가 적용 대상이 된다.

7.1. 코딩과 계획 수립

1. 개발 도구와의 결합

   1. 청중이 사용하는 코딩 에이전트로 Claude Code와 Codex가 언급됐다.
   2. 컨텍스트 엔진으로 에이전트의 계획(plan)을 미리 채우거나 수분 공급(hydrate)하면, 코드만 보고 계획을 시작하는 것보다 조직의 배경을 반영할 수 있다.

2. 토큰과 컨텍스트 절약

   1. 관련 문서와 결정 과정을 에이전트가 매번 원문 그대로 검색하도록 하지 않는다.
   2. 필요한 조직 지식을 정리해 계획에 넣으면 컨텍스트 사용량과 토큰을 절약할 수 있다.
   3. 적은 토큰으로 더 정확한 계획을 만들고, 사람의 수정·재질문 횟수도 줄일 수 있다.

7.2. 코드 리뷰와 운영 지원

1. 코드 리뷰(code review)

   1. 팀의 과거 결정과 관례를 반영한 컨텍스트가 있으면 에이전트가 작성하는 PR 리뷰가 해당 팀의 전문가가 검토한 것처럼 보일 수 있다.
   2. 팀마다 다른 품질 기준과 금지 패턴을 코드만으로 추측하지 않고, 실제 조직 지식으로 보완할 수 있다.
   3. Jeff Ng는 “누가 그것을 좋아하지 않겠는가?”라는 가벼운 농담으로 이 이점을 강조했다.

2. 고객 성공과 영업

   1. 고객 성공(customer success) 팀에는 제품 동작과 과거 대응 기록을 바탕으로 정확한 답을 제공할 수 있다.
   2. 영업(sales) 팀에는 조직이 승인한 제품 지식과 고객별 맥락을 권한 범위 안에서 제공할 수 있다.
   3. 지원과 영업의 답변 품질을 높이면서도 엔지니어가 매번 동일한 배경을 구두로 설명하는 부담을 줄일 수 있다.

3. 제도적 지식과 암묵지

   1. 조직의 제도적 지식(institutional knowledge)은 문서화된 정책과 공식 기록을 포함한다.
   2. 조직의 암묵지·부족 지식(tribal knowledge)은 팀이 실제로 무엇을 믿고 어떤 방식으로 일하는지에 해당한다.
   3. 에이전트가 이 두 종류의 지식을 업무 맥락에 맞게 얻을 수 있는 곳이라면 코딩 외에도 컨텍스트 계층이 유용하다.

8. 결론 및 실용적 시사점

1. 구축 난이도와 신뢰성 난이도를 분리하라

   1. 모델·지시사항·도구·스킬·샌드박스만으로 빠르게 에이전트를 만드는 일은 이제 가능하다.
   2. 장기 실행 상태, 격리, 로그와 트레이스를 직접 운영하는 부담은 클라우드 프리미티브와 프레임워크가 상당 부분 줄여 준다.
   3. 그러나 배포가 쉬워진 만큼 “사람이 대신 알고 있던 것”을 어떤 계층으로 전달할지 별도로 설계해야 한다.

2. 코드와 티켓만으로 자동화를 승인하지 말라

   1. 현재 코드가 어떤 상태인지와 왜 그렇게 되었는지는 다른 질문이다.
   2. 과거 장애, Slack의 결정 논의, 사후 분석 티켓, 다음 단계가 연결되지 않은 상태에서 에이전트의 권고를 자동 실행하면 같은 장애를 재현할 수 있다.
   3. 조직의 기록이 분산되어 있다면 에이전트가 모든 원문을 무작정 읽게 하는 방식보다, 관련성·최신성·권한을 기준으로 합성하는 계층을 먼저 둬야 한다.

3. MCP를 컨텍스트 엔진과 구분하라

   1. MCP는 데이터와 도구에 접근하는 표준적인 경로다.
   2. 접근 가능성이 곧 조직에 대한 이해를 뜻하지는 않는다.
   3. 원시 결과를 정리하고 충돌을 해결하고 권한을 적용하는 책임은 별도로 해결해야 한다.

4. 자율성은 컨텍스트 품질과 함께 확장하라

   1. 인간이 매 턴 오류를 잡는 구조에서는 에이전트의 누락이 외부 결과로 이어지기 전에 드러난다.
   2. 인간의 감독을 줄이고 실행 범위를 넓히려면, 사람의 배경지식과 의사결정 이력을 에이전트가 재사용할 수 있어야 한다.
   3. 에이전트의 다음 도약은 모델 지능을 조금 더 높이는 것만이 아니라, 올바른 조직 컨텍스트를 적시에 제공하는 것이다.

주요 발언 모음

“Building agents has actually gotten pretty easy, but unfortunately they still get things confidently wrong.”

“에이전트를 만드는 일은 실제로 꽤 쉬워졌지만, 안타깝게도 에이전트는 여전히 자신 있게 틀린다.”

“MCP is great at access, but access isn't understanding.”

“MCP는 접근에는 훌륭하지만, 접근이 곧 이해는 아니다.”

“Scattered context comes in, grounded context comes out.”

“흩어진 컨텍스트가 들어오고, 근거 있는 컨텍스트가 나온다.”

“The gap isn't intelligence, it's context.”

“간극은 지능이 아니라 컨텍스트다.”

핵심 데이터 & 수치

• 6개월 전: 에이전트 하나를 생산 환경에 구축하는 데 팀의 노력과 약 한 분기가 필요했다.
• 약 6개 시스템: 실패 원인을 추적하려면 여러 시스템의 로그와 트레이스를 연결해야 했다.
• 3~4초: Linear 데모의 agentic QA pipeline에서 첫 문자가 나타나기까지 실제로 측정된 지연시간이었다.
• 수백 밀리초: 해당 QA pipeline이 목표로 삼아야 할 현실적인 time to first character였다.
• 약 한 달 전: 동료 지원 엔지니어가 성능 저하 이슈를 Linear에 등록한 시점이었다.
• 며칠 뒤: 에이전트가 비동기 디스패치 재활성화를 권고한 뒤 실제 장애가 발생했다.
• P16: 발표 후 Jeff Ng와 Unblocked 팀을 만날 수 있다고 안내한 부스 번호였다.
• 802초: 제공된 영상 길이였다.

Q&A 및 후속 안내

• 현장 질의응답의 구체적인 문답은 자막에 포함되지 않았고, Jeff Ng는 질문이 있으면 P16 부스에서 자신과 팀을 만날 수 있다고 안내했다.
• 다음 날 추가 브레이크아웃 세션에서 컨텍스트 엔진이 실제로 작동하는 방식과 활용 방법을 더 깊이 다룰 예정이라고 전했다.
• 발표 직후의 후속 행동은 컨텍스트 엔진의 내부 구현, 권한 필터링, 자료 간 관계 모델링이 실제 에이전트 계획에 어떻게 반영되는지 확인하는 것이다.

핵심 요약 (20줄)

에이전트 구축은 6개월 전보다 훨씬 쉬워졌지만 안정적인 생산 서비스에는 여전히 운영 인프라가 필요하다.

장기 실행 에이전트는 메시지 기록과 도구 호출과 루프 위치를 내구성 있게 저장해야 한다.

상태를 잃고 세션을 재시작하면 토큰 비용과 지연시간이 늘고 외부 효과가 중복될 수 있다.

격리 샌드박스는 에이전트 코드의 비밀 접근과 불필요한 네트워크 접근과 호스트 장애를 줄인다.

관측성은 여러 시스템의 로그와 트레이스를 연결해 실패 지점을 찾게 한다.

Cloudflare와 Vercel과 AWS의 프리미티브는 이런 운영 복잡성을 애플리케이션에서 덜어 냈다.

모델과 시스템 프롬프트와 도구와 스킬과 샌드박스만 지정하면 에이전트의 기본 형태를 만들 수 있다.

Linear 이슈 보강 에이전트는 티켓과 코드만 보고 비동기 디스패치 재활성화를 권고했다.

그 권고는 과거 장애를 막기 위해 비동기 디스패치를 끈 결정을 몰랐기 때문에 위험했다.

Slack의 장애 논의와 사후 분석 Linear 티켓이 빠지면서 에이전트의 문제 이해가 지나치게 좁아졌다.

사람은 코드의 이유와 과거 장애와 조직의 결정을 연결하는 숨은 컨텍스트 계층으로 일한다.

사람의 감독이 사라지면 누락된 지식은 조용한 실패와 자신감 있는 오답으로 나타난다.

컨텍스트 엔진은 주체와 업무에 맞는 정보를 권한 범위 안에서 선택한다.

컨텍스트 엔진은 여러 데이터셋의 충돌을 해소하고 관련 자료를 순위화해 합성된 결과를 만든다.

문서와 코드와 티켓과 대화는 조직과 시스템의 모델로 연결된 뒤 필요한 조각만 에이전트에 전달된다.

MCP는 Slack과 Linear와 GitHub에 접근하게 하지만 원시 결과의 의미와 충돌까지 해결하지는 않는다.

컨텍스트 엔진을 붙인 같은 데모는 과거 장애를 반복할 권고를 또 다른 장애를 막는 권고로 바꿨다.

코딩 에이전트의 계획을 조직 지식으로 채우면 컨텍스트와 토큰을 절약할 수 있다.

코드 리뷰와 고객 성공과 영업도 팀의 제도적 지식과 암묵지를 활용할 수 있다.

에이전트의 다음 경쟁력은 더 높은 지능만이 아니라 필요한 순간에 제공되는 올바른 컨텍스트다.

📁 /Users/flowkater/Obsidian/flowkater/flowkater/Study/YouTube다이제스트/2026-08-22-aiDotEngineer-에이전트구축은쉬워졌고컨텍스트가다음전선.md