AI 에이전트에 신경계를 연결하는 맥락 설계

URL: https://www.youtube.com/watch?v=YNT7Plf9KIg 날짜: 2026-10-09 채널: aiDotEngineer

---

메타데이터

• 원문 제목: Your AI Agent Has No Nervous System — Matt Gibiec, Dynatrace
• 발표자: Matt Gibiec, Dynatrace AI Native 부문 Solutions Engineering Regional Director
• 영상 ID: YNT7Plf9KIg
• 발표 맥락: 컨퍼런스 마지막 날 오전 11시 10분 세션
• 주제: AI 에이전트(Agent)의 운영 맥락(Context), 관측성(Observability), 안전한 소프트웨어 개발 수명주기(SDLC)
• 정리 기준일: 2026-10-09
• 태그: #AI에이전트 #ContextEngineering #Observability #SDLC #Dynatrace #BlueBox

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트가 빠르게 코드를 만들고 업무를 자동화하려면, 에이전트 자체를 더 영리하게 만드는 것보다 에이전트가 실제 환경의 맥락을 보고 이해하도록 만드는 일이 먼저다.==

• 에이전트가 반복 루프에 빠지고 토큰만 소비하는 이유는 실패한 접근을 바꿀 만큼의 환경 맥락이 없기 때문이다.
• 서비스 의존성, 실제 사용자 사용 방식, 권한, 운영 데이터가 빠지면 에이전트의 결정은 그 순간에는 그럴듯해도 장기적으로 틀릴 수 있다.
• 맥락은 에이전트의 신경계이자 여러 서비스와 자동화 프로세스를 연결하는 결합 조직(Connective Tissue)이며, 이를 SDLC 전체에 공급해야 신뢰할 수 있는 코드를 프로덕션에 배포할 수 있다.

에이전트는 인간처럼 행동할 필요는 없지만 조직을 돕기 위해 충분한 입력과 추론(Reasoning) 능력이 필요하다. 따라서 배포를 서두르기 전에 에이전트가 어떤 가치를 만들어야 하는지 측정 기준을 세우고, 실제 프로덕션의 맥락을 개발·테스트·수정 과정에 연결해야 한다. Matt Gibiec은 Dynatrace의 Blue Box를 이 문제를 해결하는 맥락 제공 계층으로 제시한다.

1. 빠른 AI 에이전트가 놓치는 것

AI 에이전트의 속도만으로는 사람의 일을 안정적으로 대체할 수 없으며, 추론에 필요한 입력의 품질이 결과를 결정한다.

1.1. 제목의 역설: 에이전트에는 신경계가 없지만 맥락은 필요하다

1. AI 에이전트가 사람의 업무를 대체하는 상황

   1. 자동화를 넘어선 추론: 에이전트는 단순히 잘 작동하지 않는 기존 작업을 자동화하는 데 그치지 않고, 조직 안에서 무엇을 해야 하는지 판단해야 한다.
   2. 인간과 동일할 필요는 없음: 에이전트가 사람이 될 필요는 없지만, 업무를 이해하고 조직을 도울 만큼 충분한 입력을 받아야 한다.

2. 신경계라는 비유의 의미

   1. 시야가 아니라 연결된 맥락: 제목의 ‘신경계’는 생물학적 기관이 아니라 에이전트가 환경의 상태·관계·변화를 감지하고 판단에 반영하게 하는 정보 연결망을 뜻한다.
   2. 맥락이 핵심: 에이전트의 성능을 높이는 출발점은 모델을 무작정 바꾸는 것이 아니라 에이전트가 접근할 수 있는 환경 맥락을 확보하는 일이다.

1.2. 현장에서 던져야 할 질문

1. 개발자와 팀 리드의 운영 질문

   1. 반복 루프: Claude 같은 에이전트가 같은 작업을 계속 반복하고 토큰만 소모하면서 원하는 결과를 내놓지 못한 경험이 대부분의 팀에 있다.
   2. 인간의 대응과 에이전트의 한계: 사람이 조사에서 원치 않는 결과를 얻으면 다른 각도와 접근법을 시도하지만, 현재의 에이전트는 실패한 접근을 스스로 바꿀 만큼 똑똑하지 않다.

2. 운영·보안 질문

   1. 운영 이슈: 팀은 “에이전트의 운영 문제를 어떻게 처리할 것인가?”를 배포 전에 물어야 한다. 아직 ‘일단 배포하고 나중에 생각하자’는 분위기에만 머물러 있다면 위험하다.
   2. 보안 우려: AI 에이전트를 실제 환경에 연결할수록 보안 문제는 피할 수 없는 질문이 된다. 발표자가 보안 우려를 묻자 청중 대부분이 손을 들었고, 발표자는 이를 “레이업(layup)”처럼 당연한 질문이라고 농담했다.

3. 엔지니어링 리더의 가치 질문

   1. 사용자 가치: 애플리케이션이나 에이전트가 사용자에게 실제 가치를 주는지 확인해야 한다.
   2. 측정 기준: AI 열풍과 AI 에이전트 열풍 속에서 엔지니어링 리소스·시간·노력·비용을 투입하고도 성공을 측정할 지침이 없는 경우가 많다.
   3. 잠깐 멈추기: 빨리 달리고 싶은 욕구가 있어도 무엇을 달성하려는지, 에이전트의 성공을 어떻게 측정할지 먼저 정해야 한다.

2. “속도는 있지만 시야가 없다”

에이전트의 결정은 사용할 수 있는 데이터의 질과 맥락의 완전성에 제한된다.

2.1. CTO의 문장과 에이전트의 한계

1. 속도와 시야의 대비

   1. 빠른 실행: Matt은 CTO Bernd의 말을 인용하며 “에이전트는 속도로 작동한다(Agents operate at speed)”고 청중에게 동의를 구했고, 청중도 에이전트가 빠르다는 점에 동의했다.
   2. 부족한 시야: 바로 이어지는 “하지만 시야가 없다(without sight)”는 문장은 속도와 이해가 같은 것이 아님을 압축한다.

2. 데이터가 추론을 결정함

   1. 가용 데이터의 한계: 에이전트가 추론하고 결정을 내리는 수준은 에이전트가 사용할 수 있는 데이터만큼만 좋다.
   2. 빠진 정보의 종류: 환경의 맥락, 세부사항, 다른 도구에서 데이터를 가져올 수 있는 올바른 권한이 빠지면 에이전트의 판단 기반이 약해진다.

2.2. 맥락 부족이 만드는 잘못된 자동화

1. 환각(Hallucination)의 출발점

   1. 불완전한 입력: 데이터에 맥락·세부사항·권한이 부족한데도 에이전트가 결정을 내려야 하면, 흔히 말하는 환각이 나타나기 시작한다.
   2. 가치 없는 프로세스: 에이전트가 환경에서 프로세스를 실행하고 자동화하더라도 필요한 맥락이 없으면 조직에 가치를 가져오지 못할 수 있다.

2. 소프트웨어 개발 수명주기(SDLC)의 사례

   1. 의존성 이해 부족: Claude를 SDLC 안에서 사용하더라도 서비스 사이의 의존성을 이해하지 못하면 제안이 환경과 맞지 않는다.
   2. 사용자 관점 부재: 애플리케이션이 사용자를 위해 실제로 어떻게 사용되는지 모르면, 그럴듯한 결정과 조언을 내리더라도 장기적으로는 틀릴 수 있다.
   3. 장기적 부정확성: 순간적으로 맞아 보이는 조언도 환경 전체의 모습과 맥락을 파악하지 못하면 지속 가능한 답이 아니다.

2.3. 맥락은 에이전트의 신경계다

1. 핵심 정의

   1. 신경계 역할: 에이전트가 효율적이고 생산적이 되기 위해 반드시 인간의 신경계를 가질 필요는 없지만, 실제 환경의 맥락은 필요하다.
   2. “Context is king”: 발표자가 해당 슬라이드를 요약한 문장은 “맥락이 왕이다(Context is king)”였다.

2. 결합 조직으로서의 맥락

   1. 프로세스 연결: 에이전트가 서로 통신하고 자동화하고 새 프로세스를 만들 때, 맥락이라는 연결 조직이 그 모든 흐름을 움직인다.
   2. 환경과 판단의 연결: 맥락은 에이전트의 입력을 애플리케이션·서비스·사용자·변경 사항과 연결해 의사결정이 환경에 닿게 한다.

3. Blue Box: 에이전트 사이에 맥락을 공급하는 계층

Dynatrace의 Blue Box는 개발 수명주기 한가운데 통합되어 AI 코딩 에이전트나 조직이 만든 자체 에이전트에 환경 맥락을 제공하는 제품으로 소개된다.

3.1. 로컬 테스트와 프로덕션의 연결

1. 개발자에게 익숙한 실패 시나리오

   1. 로컬에서는 성공: 개발자가 기능을 만들거나 에이전트용 스킬(skill)을 만들어 로컬에서 테스트하면 모든 것이 훌륭하게 작동한다.
   2. 메인 브랜치 병합 후 파급: 코드를 메인 브랜치에 병합하고 배포하는 순간, 다른 세 서비스가 깨지는 일이 발생할 수 있다. 로컬 테스트만으로는 에이전트·애플리케이션 사이의 영향 범위를 알기 어렵다.

2. 서비스·의존성 매핑

   1. 전체 AI 워크로드의 관계 파악: Blue Box는 각 에이전트와 각 AI 워크로드에 대해 서비스 및 의존성 매핑(Service and Dependency Mapping)을 제공하는 것을 목표로 한다.
   2. 프로덕션 맥락을 로컬로 이동: 개발자가 변경을 만들 때 로컬에서 기능이 동작하는지만 확인하는 것이 아니라, 프로덕션의 맥락을 로컬 테스트에 가져와 다른 연결 대상에 악영향을 주지 않는지 확인하게 한다.
   3. 검증 범위 확대: 기능이 개발자의 자동화 목표를 달성하는지와 동시에 연결된 에이전트·워크로드·애플리케이션을 깨뜨리지 않는지를 함께 검증한다.

3.2. 장애가 실제 문제가 되기 전에 감지하기

1. 관측성의 오래된 목표

   1. 사전 감지: Matt은 8년 동안 관측성(Observability)을 다뤘다고 밝히며, 고객에게 가장 자주 듣는 목표는 조직과 사용자에게 영향을 주기 전에 문제를 찾는 것이라고 설명한다.
   2. AI 에이전트에도 같은 목표 적용: Blue Box가 제공하는 맥락은 바로 이 사전 감지를 에이전트에 연결한다.

2. 정상 상태와의 비교

   1. 엔드투엔드 상호작용 이해: 에이전트가 애플리케이션·생태계·조직 안에서 어떻게 상호작용하는지 엔드투엔드(End-to-End)로 파악한다.
   2. 과거 데이터 활용: 환경의 과거 데이터와 과거 부하를 이용해 정상 상태(normal)를 학습한다.
   3. 이상 징후 조기 전달: 특정 서비스가 평소보다 느려지거나 전에는 내지 않던 오류를 내기 시작하면 정상에서 벗어난 변화를 앞서 감지한다.
   4. IDE 안의 개발자 알림: 감지 결과를 개발자의 IDE에 전달해, 개발자에게 속한 서비스에서 속도 저하나 신규 오류가 발생했다는 사실을 알려줄 수 있다.

3.3. 코드 변경과 운영 데이터를 겹쳐 원인을 찾기

1. 저장소와의 통합

   1. 코드 저장소 한가운데 배치: Blue Box는 코드 저장소에도 통합되어 어떤 변경이 생겼는지 파악한다.
   2. 변경 맥락 수집: 애플리케이션, 워크로드, 생태계에서 무엇이 바뀌었는지 운영 데이터와 함께 볼 수 있다.

2. 변경 원인 추적

   1. 원인 후보 좁히기: 운영 환경의 이상과 코드 저장소의 변경을 겹쳐 보면 현재 문제가 누군가가 푸시한 변경 때문에 발생했는지 파악할 수 있다.
   2. 병합 실패 포함: 원인은 성공하지 못한 병합(merge)일 수도 있으며, 운영 데이터만 보거나 코드만 보는 것보다 두 맥락을 함께 보는 편이 빠르고 정확하다.

4. 발견한 문제를 안전하게 수정하기

맥락을 수집하는 목적은 문제를 찾는 데서 끝나지 않는다. 수정이 다른 부분을 망가뜨리지 않도록 전체 환경의 의존성을 고려해야 한다.

4.1. 감지에서 선제적 대응으로

1. 맥락 기반 파이프라인
   1. 환경 맥락 확보: Blue Box는 프로덕션 데이터를 로컬 테스트와 개발자의 IDE로 가져온다.
   2. 에이전트에 내장: AI 코딩 에이전트에 Blue Box를 결합해 개발·테스트 과정 자체가 환경 맥락을 사용할 수 있게 한다.
   3. 선제성: 문제를 조기에 감지하면 문제가 사용자와 조직에 영향을 준 뒤 수습하는 대신 생산적으로 먼저 대응할 수 있다.

4.2. 한 줄 수정의 연쇄 효과

1. 수정 제안에 필요한 저장소 지식

   1. 변경자와 변경 내용: 문제가 감지되고 저장소에 대한 지식이 있으면 누가 코드를 푸시했는지, 무엇이 바뀌었는지 알 수 있다.
   2. 구체적 다음 단계: 문제가 있는 서비스·에이전트·워크로드에 어떤 단계를 밟아 수정할 수 있는지 개발자에게 안내한다.

2. 국소적 해결과 전역적 안전성의 균형

   1. 한 줄의 코드: 버그를 일으킨 문제는 한 줄만 바꿔 고칠 수 있다.
   2. 남은 환경의 영향: 그 한 줄을 바꾼 뒤 애플리케이션과 주변 서비스에는 무슨 일이 생기는지 별도로 확인해야 한다.
   3. 수정의 정의: 손에 잡힌 이슈만 고치는 것이 아니라, 다른 환경 문제를 새로 만들지 않는 것까지가 수정이다.
   4. 의존성의 중요성: 전체 서비스 의존성을 모르면 국소적 수정이 또 다른 장애를 만들 수 있으므로 환경의 맥락과 의존성은 매우 중요하다.

5. 프롬프트 전에 에이전트를 브리핑하기

새 기능을 만들기 전에 실제 사용자 가치와 기존 환경의 맥락을 에이전트에게 먼저 전달해야 한다.

5.1. 기능을 바로 개발하지 않는 이유

1. 흔한 개발 흐름

   1. 기능 제안: 누군가 새로운 기능을 제안하면 개발자가 바로 구현을 시작하는 일이 자주 있다.
   2. 사전 조사 생략: 그 기능이 사용자에게 무엇을 전달해야 하는지, 무엇을 달성하려는지 충분히 조사하지 않은 채 개발로 들어간다.

2. 개발 전에 확인할 질문

   1. 사용자 결과: 해당 기능이 사용자에게 실제로 어떤 결과를 제공해야 하는가?
   2. 달성 목표: 이 특정 기능으로 조직과 제품이 실제로 무엇을 이루려 하는가?
   3. 기존 환경: 현재 애플리케이션과 에이전트들이 어떤 상태이며 새 기능이 어디에 연결되는가?

5.2. “프롬프트 전에 계획하기(Plan before you prompt)”

1. 계획에 맥락 주입

   1. 에이전트·애플리케이션 구축: 자체 에이전트나 애플리케이션을 만들 때, AI 코딩 에이전트를 사용할 때도 먼저 환경 자료를 확보한다.
   2. 기존 자산 포함: 현재 애플리케이션과 이미 환경에 존재하는 모든 에이전트의 맥락을 모아 새 릴리스나 기능 계획에 반영한다.

2. 기능 범위의 현실화

   1. 충분한 데이터: 새 기능이 실제로 포함해야 할 범위를 이해할 만큼의 데이터를 계획 단계에서 확보한다.
   2. 구현 전 검증: 기능을 만든 뒤 문제가 드러나는 것이 아니라, 프롬프트와 구현 전에 목표·영향·필요 범위를 검증한다.

6. 관찰에서 인간 통제형 자동화까지

맥락은 자동화를 더 밀어붙일 수 있게 하지만, 최종 배포 결정은 인간이 통제해야 한다.

6.1. Human in the Loop의 필요성

1. 자동화의 위험

   1. 모든 것을 에이전트에게 맡기기: 에이전트가 모든 일을 하도록 두면 환경은 “꽤 엉망인 세상”이 될 수 있다고 발표자는 농담 섞어 경고한다.
   2. 통제권 유지: 조직은 환경에서 실제로 무슨 일이 일어나는지 통제할 수 있어야 한다.

2. 자동화의 목표

   1. 더 많은 자동화: 충분한 맥락은 에이전트의 자동화 범위를 넓힌다.
   2. 결정권의 보존: 자동화가 제안·수정·배포까지 이어져도 사람이 마지막에 무엇을 실행할지 결정해야 한다.

6.2. Blue Box가 제시하는 SDLC 흐름

1. Observe — 관찰

   1. 환경 관측: 조직의 환경을 관찰하고 에이전트·서비스·애플리케이션의 현재 상태를 파악한다.
   2. 의존성 맵 구축: 관찰 결과로 서비스와 워크로드 사이의 의존성 매핑을 만든다.

2. Contextualize — 맥락 제공

   1. 개발자에게 전달: 프로덕션 데이터와 필요한 프로덕션 세부사항을 로컬 테스트 중인 개발자에게 제공한다.
   2. 신뢰 가능한 테스트: 개발자는 코드가 자기 환경에서만 작동하는지가 아니라 실제 운영 환경과 연결된 상태에서도 안전한지 테스트한다.

3. Detect and Suggest — 감지와 제안

   1. 문제 감지: 정상 상태에서 벗어난 변화를 조기에 감지한다.
   2. 맥락 있는 수정 제안: 문제가 있는 특정 지점만 겨냥하지 않고 모니터링 중인 애플리케이션과 에이전트, 주변 환경의 맥락을 사용해 수정안을 제시한다.

4. Human Decision — 인간의 최종 결정

   1. SDLC 구동: 제안된 수정 사항을 제공해 전체 SDLC를 더 자동화한다.
   2. 배포 여부 결정: 기능이나 수정 사항을 실제로 푸시할지 말지는 사람에게 맡긴다. 자동화는 실행을 대신할 수 있어도 배포 권한을 무조건 가져가서는 안 된다.

주요 발언 모음

“에이전트는 속도로 작동한다. 하지만 시야는 없다.” — CTO Bernd의 말 인용

“맥락이 왕이다(Context is king).”

“맥락은 에이전트에 제공할 수 있는 신경계다.”

“프롬프트하기 전에 계획하라(Plan before you prompt).”

“우리는 에이전트가 신뢰할 수 있는 코드를 프로덕션으로 배포하도록 돕고 싶다.”

핵심 데이터 & 수치

• 11시 10분: 컨퍼런스 마지막 날 세션이 공식적으로 시작된 시각이다.
• 18분: 발표 초반 남은 시간이 18분뿐이라 모든 질문을 다 다루지는 않겠다고 안내했다.
• 8년: Matt이 관측성 분야에서 일해 온 기간이다.
• 3개 서비스: 로컬에서는 잘 작동한 기능을 메인 브랜치에 병합한 뒤 다른 세 서비스가 깨지는 대표적인 파급 사례를 들었다.
• 5분: Blue Box 소개 후 질의응답에 사용할 수 있다고 안내한 남은 시간이다.
• 정량 성능 지표 부재: Blue Box의 구체적인 정확도·지연시간·장애 감소율·비용 절감 수치는 발표에서 제시되지 않았다. 핵심 제안은 제품 벤치마크가 아니라 프로덕션 맥락을 SDLC와 에이전트에 연결하는 방식이었다.

결론 및 시사점

1. 속도보다 입력을 먼저 설계해야 한다: AI 에이전트가 빠르게 실행해도 서비스 의존성·권한·사용자 행동·운영 상태가 없으면 그 속도는 반복 루프와 잘못된 자동화를 빠르게 만들 뿐이다.
2. 맥락을 플랫폼 기능으로 취급해야 한다: 맥락은 일회성 프롬프트가 아니라 환경을 감지하고 연결하고 변화시키는 신경계이자 결합 조직이다.
3. 프로덕션 데이터를 개발 단계로 가져와야 한다: 로컬 테스트와 실제 운영 환경 사이의 간극을 줄이려면 서비스·의존성 매핑과 과거 정상 상태를 개발자의 IDE와 AI 코딩 에이전트에 제공해야 한다.
4. 관측성과 코드 변경을 함께 봐야 한다: 운영 이상을 코드 저장소의 변경·푸시·병합 정보와 겹쳐야 원인을 빠르게 좁히고, 수정 이후의 연쇄 영향도 검토할 수 있다.
5. 프롬프트보다 계획이 먼저다: 새 기능을 구현하기 전에 사용자 가치, 조직의 목표, 기존 애플리케이션과 에이전트의 관계, 필요한 범위를 조사하고 에이전트에 브리핑해야 한다.
6. 자동화에는 인간의 마지막 승인 지점이 필요하다: 관찰→맥락 구축→로컬 테스트→문제 감지→맥락 기반 수정 제안→인간의 배포 결정이라는 흐름이 에이전트 시대의 안전한 SDLC 모델이다.
7. 제품 소개와 실행 권유: Matt은 발표를 “에이전트가 신뢰할 수 있는 코드를 프로덕션에 배포하도록 돕고 싶다”는 문장으로 마무리했다. 관심 있는 청중은 bluebox.ai에서 프리뷰를 신청할 수 있으며, 발표자는 현장에서 스캔할 수 있는 자료도 나눠주겠다고 했다. 마지막에 질문을 받았지만 청중의 질문은 없었다.

핵심 요약 (20줄)

1. AI 에이전트의 속도는 충분하지만 실제 환경을 볼 수 있는 맥락이 없으면 신뢰할 수 있는 판단을 내리기 어렵다.
2. 에이전트가 사람의 업무를 대체하려면 단순 자동화보다 추론에 필요한 입력이 먼저 갖춰져야 한다.
3. Claude가 같은 작업을 반복하며 토큰만 소비하는 현상은 실패한 접근을 바꿀 환경 맥락이 부족하다는 신호다.
4. 사람은 원치 않는 조사 결과를 얻으면 다른 각도로 접근하지만 현재 에이전트는 스스로 전략을 바꾸지 못한다.
5. 에이전트 운영에는 반복 루프, 운영 장애, 보안, 사용자 가치 측정이라는 질문이 따라온다.
6. AI 에이전트에 엔지니어링 리소스와 비용을 투입하려면 성공을 측정할 기준을 먼저 정해야 한다.
7. CTO Bernd의 표현처럼 에이전트는 속도로 작동하지만 시야가 없다.
8. 에이전트의 추론 품질은 이용 가능한 데이터와 권한, 환경 세부사항의 품질을 넘을 수 없다.
9. 맥락과 권한이 빠지면 환각이 늘고 조직에 가치 없는 자동화가 실행될 수 있다.
10. “맥락이 왕이다”라는 원칙은 에이전트에 실제 환경의 연결 조직을 제공하라는 뜻이다.
11. Blue Box는 AI 코딩 에이전트와 자체 에이전트에 서비스·의존성·프로덕션 맥락을 공급하는 계층으로 소개됐다.
12. 로컬에서 성공한 기능도 메인 브랜치 병합 뒤 다른 세 서비스를 깨뜨릴 수 있다.
13. 프로덕션 맥락을 로컬 테스트로 가져오면 개발자는 연결된 워크로드에 미칠 영향을 미리 확인할 수 있다.
14. 과거 부하와 운영 데이터를 이용해 정상 상태를 만들면 이상 징후를 사용자 영향 전에 감지할 수 있다.
15. 운영 데이터와 코드 저장소 변경을 함께 보면 문제를 만든 푸시나 실패한 병합을 추적할 수 있다.
16. 한 줄의 버그 수정도 주변 서비스에 새로운 장애를 만들 수 있어 전체 의존성 확인이 필요하다.
17. 새 기능은 개발에 들어가기 전에 사용자에게 전달할 가치와 실제 달성 목표를 조사해야 한다.
18. “프롬프트 전에 계획하라”는 원칙은 기존 애플리케이션과 에이전트의 맥락을 계획 단계에 넣으라는 뜻이다.
19. 관찰·맥락 제공·감지·수정 제안으로 자동화를 확장하되 최종 배포 결정은 인간이 내려야 한다.
20. Blue Box의 최종 약속은 에이전트가 신뢰할 수 있는 코드를 프로덕션에 배포하도록 돕는 것이다.