AI Native DevCon 2일 차: 에이전트 데모에서 운영 모델로

요약 (TL;DR)

AI Native DevCon의 2일 차는 에이전트의 능력(capability)에서 운영 규율(operating discipline)로 중심이 이동했습니다. 가장 강력했던 세션들은 팀이 더 명확한 컨텍스트 파이프라인 (context pipelines), 측정 가능한 에이전트 행동 (measurable agent behavior), 더 안전한 실행 경계 (safer execution boundaries), 그리고 더 나은 조직적 소유권 (organizational ownership)을 통해 어떻게 AI 네이티브 전달 (AI-native delivery)을 수행할 수 있는지에 초점을 맞췄습니다.

규모 또한 수치로 나타났습니다. 이틀 동안 DevCon은 650명 이상의 오프라인 등록자와 약 2,000명의 온라인 등록자를 모았으며, 세션, 워크숍, 복도에서의 대화 및 실질적인 교훈들이 가득 찬 구성을 선보였습니다.

2일 차는 워크숍에 비중을 두었습니다. 이러한 변화는 중요했는데, 둘째 날은 에이전트가 유용한 작업을 할 수 있음을 증명하는 것보다 팀이 어떻게 그 작업을 반복 가능하게 (repeatable) 만들 수 있는지를 보여주는 데 더 집중했기 때문입니다.

안녕하세요, 다시 만나서 반갑습니다. DevCon 시리즈를 이어가는 Rohan Sharma입니다.

1일 차에서는 기술(skills)을 실제 소프트웨어 자산처럼 취급해야 한다는 Guy Podjarny의 핵심 논점을 포함하여 프레임워크를 제공했습니다. 2일 차는 거기서 시작하여 운영 세부 사항으로 넘어갔습니다. 에이전트가 일상적인 엔지니어링 작업에 도입되면, 플랫폼 및 제품 팀은 무엇을 먼저 변경할지, 누가 그 변경을 소유할지, 그리고 결과를 어떻게 측정할지를 결정해야 합니다.

2일 차를 형성한 강연들

코드 그 이상의 Harness 엔지니어링

Tessl의 Marc Sloan은 많은 팀이 직면하고 있는 다음 단계의 격차에 집중했습니다. 코드 컨텍스트 (Code context)는 점점 더 구조화되고 있지만, 제품 및 디자인 컨텍스트 (product and design context)는 여전히 Figma, Notion, Linear와 같은 외부 시스템에 존재합니다. 이러한 컨텍스트를 실시간으로 가져오는 것은 정보의 노후화를 줄일 수 있지만, 평가 (evals), 버전 관리 (versioning), 그리고 재현성 (reproducibility) 측면에서 드리프트 (drift)를 유발할 수 있습니다.

실질적인 교훈은 외부 제품 및 디자인 컨텍스트 (context)를 무작위 참조 자료로 취급하는 것을 중단해야 한다는 것이었습니다. 팀은 저장소 (repository)와 이러한 외부 시스템 사이에 명확한 버전 관리 (versioning)를 갖춘 정의된 레이어 (layer)를 구축해야 하며, 이를 통해 알려진 컨텍스트 스냅샷 (context snapshots)을 대상으로 평가 (evaluation)를 다시 실행할 수 있어야 합니다.

그렇지 않으면, 에이전트 (agent)는 기술적으로는 올바르게 보이지만 실제로 중요한 제품 제약 조건 (product constraint)을 놓친 결과물을 만들어낼 수 있습니다. 이는 '거의 맞지만 틀린' 매우 비용이 많이 드는 상황입니다.

느낌(vibes)에서 지표(metrics)로

Tessl의 Simon Obstbaum과 Rob Willoughby는 현재 많은 엔지니어링 리더들이 직면하고 있는 과제에 초점을 맞춘 세션을 진행했습니다. 이들이 구분한 출력 평가 (output evals)와 궤적 평가 (trajectory evals)는 운영 측면에서 매우 중요합니다. 에이전트가 위험한 도구 (tools)를 사용했거나, 필수 체크 과정을 건너뛰었거나, 정책 단계 (policy steps)를 무시했다면 단순히 좋은 답변을 내놓는 것만으로는 충분하지 않습니다.

유용한 측정 모델은 활성화 (activation), 궤적 (trajectory), 그리고 결과 (outcome)로 요약되었습니다. 올바른 기술 (skill)이 트리거 (trigger)되었는가? 에이전트가 올바른 단계를 따랐는가? 최종 결과가 실제로 유용하고 정확했는가? 하는 점들입니다.

긍정적인 부분은 부분적 준수 (partial compliance)를 강조했다는 점입니다. 에이전트 워크플로 (workflow)에 대해 합격(pass) 또는 불합격(fail)으로만 나누는 것은 너무 투박합니다. 만약 워크플로가 중간에 저하된다면, 팀은 단순히 무언가 잘못되었다는 느낌을 받는 것이 아니라 정확히 어디에서 문제가 발생했는지 알아야 합니다.

모델을 넘어선 벤치마킹 (Benchmarking)

Amit Kushwaha는 왜 현재의 많은 벤치마크 (benchmarks)들이 실제 에이전트의 동작을 놓치고 있는지 강조했습니다. 에이전트 시스템은 도구 호출 (tool calls), 컨텍스트 축적 (context accumulation), 그리고 지연 시간 병목 현상 (latency bottlenecks)이 포함된 긴 트레이스 (traces)를 실행하며, 이는 단발성 (one-shot) 벤치마크 수치로는 포착할 수 없습니다.

인프라를 선택하는 팀들에게 경고는 명확했습니다. 모델 속도(model speed)만을 위해 최적화하지 마십시오. 실제 에이전트 워크로드(agent workloads)에는 도구(tools), 메모리(memory), 캐시(caches), 재시도(retries), 그리고 장시간 실행되는 트레이스(long-running traces)가 포함됩니다.

더 나은 벤치마크는 멀티 턴 작업(multi-turn tasks), 도구 지연 시간(tool latency), 꼬리 지연 시간(tail latency), 그리고 시간에 따른 캐시 동작(cache behavior)을 포함하여 실제 운영 환경(production reality)에 더 가깝습니다. 그렇지 않으면 팀들은 차트상으로는 훌륭해 보이지만 실제 워크플로(workflow)에서는 고전하는 시스템을 선택하게 될 위험이 있습니다.

에이전트를 위한 안전한 실행 경계 (Safe execution boundaries for agents)

Docker의 Oleg Šelajev는 모든 플랫폼 팀이 결국 마주하게 되는 문제를 다루었습니다. 제약이 없는 에이전트는 잘못된 환경에서 영향력이 큰 변경을 일으킬 수 있습니다. 에이전트에게 실행 권한이 허용되는 순간, 샌드박싱(Sandboxing)은 선택이 아닌 필수입니다.

실질적인 교훈은 환경 정책(environment policy)을 하네스(harness)의 일부로 취급해야 한다는 것이었습니다. 에이전트에게 행동 능력을 부여하기 전에 파일 시스템 액세스(Filesystem access), 네트워크 액세스(network access), 비밀 정보(secrets), 그리고 권한(permissions) 모두에 명확한 경계가 필요합니다.

이것이 팀들이 폭발 반경(blast radius)을 줄이는 방법입니다. 에이전트가 착하게 행동하기를 바라는 것이 아니라, 에이전트가 움직일 수 있도록 허용된 공간을 설계하는 것입니다.

프롬프트를 작성하지 말고, 소프트웨어를 작성하십시오

Tessl의 Baruch Sadogursky와 Macey Baker는 운영 환경에서 계속해서 유용함이 증명되고 있는 아이디어를 강조했습니다. 하나의 거대한 프롬프트를 유지하는 대신, 동작을 모듈식 기술(modular skills)로 분리하십시오. 이렇게 하면 에이전트의 동작을 테스트, 검토 및 재사용하기가 더 쉬워집니다.

그들의 메시지는 "더 나은 메가 프롬프트(mega prompt)를 작성하라"가 아니었습니다. 반복 가능한 동작을 실제 워크플로 단계에 부합하는 조합 가능한 기술(composable skills)로 전환하라는 것이었습니다. 이를 통해 팀은 검토, 테스트, 개선하고 여러 리포지토리(repos)에 걸쳐 공유할 수 있는 결과물을 얻을 수 있습니다.

이번 워크숍에서 한 가지만 시도해 본다면, 제공된 자료와 기술 템플릿(skill templates)을 시작점으로 삼으십시오. 이 패턴을 모든 리포지토리에 확장하려고 하기 전에, 여러분의 환경에서 작은 기술 파이프라인(skill pipeline) 하나를 먼저 프로토타입으로 만들어 보십시오.

하루 종일 반복해서 등장한 주제들

1. 컨텍스트 품질(Context quality)은 이제 플랫폼의 책임입니다

Marc Sloan, Shaun Smith, 그리고 John Groetzinger는 서로 다른 각도에서 이 문제에 접근했지만, 운영 측면에서의 메시지는 일관되었습니다. 컨텍스트 전달 (Context delivery)은 단순한 문서 관리의 위생 문제를 넘어 하나의 엔지니어링 시스템이 되어가고 있습니다. 팀들은 인간과 에이전트(Agent) 모두를 위해 예측 가능한 컨텍스트 파이프라인 (Context pipelines)을 갖춰야 합니다.

다음 단계는 소유권 (Ownership)입니다. 팀은 누가 컨텍스트 소스를 유지 관리하는지, 얼마나 자주 새로고침되는지, 그리고 변경 사항이 어떻게 버전 관리 (Versioned)되는지를 알아야 합니다. 또한, 팀이 어떤 입력값이 에이전트의 결정을 형성했는지 추적할 수 있도록 컨텍스트에 대한 관측 가능성 (Observability)도 필요합니다.

2. 에이전트 성능에는 프로덕션급 텔레메트리 (Telemetry)가 필요합니다

Tessl의 Simon Obstbaum과 Rob Willoughby, 그리고 NVIDIA의 Amit Kushwaha와 Docker의 전 CTO인 Justin Cormack의 세션은 이 점을 매우 구체적으로 제시했습니다. 팀들은 에이전트가 무엇을 반환했는지뿐만 아니라, 에이전트가 어떻게 작동했는지를 측정해야 합니다.

궤적 지표 (Trajectory metrics)는 기존의 품질 신호 (Quality signals)와 나란히 배치되어야 합니다. 만약 여러분의 대시보드에 이미 테스트 상태, 릴리스 상태 또는 장애 트렌드가 표시되고 있다면, 에이전트 워크플로 품질 (Agent workflow quality)도 동일한 운영 뷰 (Operational view)에 포함되어야 합니다.

벤치마크 시나리오 또한 실제 업무와 유사해야 합니다. 멀티 턴 (Multi-turn), 도구 중심적 (Tool-heavy), 약간은 무질서하며, 여러분의 팀이 매일 직면하는 것과 동일한 제약 조건들로 가득 차 있어야 합니다. Justin의 관측 가능성 (Observability)에 대한 지적도 이 지점과 깔끔하게 연결됩니다. 팀에는 에이전트로 인한 드리프트 (Drift)가 더 큰 프로덕션 문제로 발전하기 전에 이를 드러낼 수 있는 런타임 신호 (Runtime signals)가 필요합니다.

3. 도입은 도구의 체크박스 문제가 아니라 조직 설계의 문제입니다

Thoughtworks의 Tammuz Dubnov와 Birgitta Böckeler의 강연에 따르면, 도구의 변화에 맞춰 검토 구조 (Review structures), 소유권 경계 (Ownership boundaries), 그리고 팀의 의례 (Team rituals)가 함께 진화할 때 도입이 성공합니다.

이는 AI 보조 변경 사항에 대해 명시적인 기여 경계 (Contribution boundaries)를 설정하고 검토 기준 (Review criteria)을 업데이트해야 함을 의미합니다. 차이점 (Diff)은 여전히 중요하지만, 에이전트가 이를 생성하기 위해 거친 경로 또한 중요합니다. Birgitta의 도입 데이터는 속도가 유일한 지표가 될 때 발생하는 검토 부하 (Review load), 기술 부채 (Technical debt), 유지보수성 (Maintainability)을 포함한 숨겨진 비용이 어디에서 나타나는지를 보여줌으로써 이 점을 특히 현실적으로 뒷받침했습니다.

4. 워크숍을 통해 아이디어를 실무에 적용하다

Tessl의 Baruch Sadogursky와 Macey Baker, 그리고 Nearform의 Alfonso Graziano는 2일 차의 더 큰 아이디어들을 팀이 실제로 시도해 볼 수 있는 무언가로 바꾸는 데 도움을 주었습니다. 워크숍 중심의 구성 덕분에 이날은 이론보다는 실습에 더 가까운 느낌을 주었습니다.

Derek Ashmore의 밀도 높은 워크숍인 **“AI 에이전트 테스트 피라미드 (The AI Agent Testing Pyramid)”**는 에이전트 시스템에 필요한 다양한 테스트 단계에 초점을 맞췄습니다. 집에서 시청 중인 분들은 이 리포지토리 (this repo)를 따라 직접 시도해 볼 수 있습니다.

[

]

Anthropic의 Aashrey Tiku는 관리형 에이전트 (Managed agent)를 배포하는 실습 세션을 진행했습니다. 이는 에이전트 개념과, 적절한 경계를 갖춘 에이전트를 패키징, 관리 및 운영하는 실제 작업 사이를 이어주는 유용한 가교 역할을 했습니다.

이는 AI 네이티브 개발 (AI-native development)이 여전히 매우 초기 단계에 있어, 사람들이 단순히 고개를 끄덕이며 동의할 수 있는 개념이 아니라 직접 테스트할 수 있는 패턴을 필요로 하기 때문에 중요했습니다. Alfonso의 명세 기반 (spec-driven) 접근 방식은 여기서 매우 적절했는데, 프롬프트 (prompts)가 테스트 가능하고 운영 준비가 된 명세 (specifications)로 변환될 때 훨씬 더 유용해지기 때문입니다.

5. 에이전트 활성화 (Agent enablement)에는 실질적인 소유권이 필요합니다

Meta의 Ian Thomas와 Nearform의 Katie Roberts는 활성화 (enablement) 측면을 실무적으로 다루었습니다. 플랫폼의 안전장치 (safeguards)가 업데이트된 팀의 의식 (rituals), 명확한 소유권 (ownership), 그리고 기존 시스템 (brownfield systems)에 대한 현실적인 가이드와 결합될 때 배포 (rollouts)가 더 원활하게 이루어집니다.

Katie의 레거시 (legacy) 관련 조언은 특히 유용했습니다. AI는 이미 유지보수가 어려운 시스템 위에 또 다른 취약한 계층을 생성하는 것이 아니라, 팀이 점진적으로 현대화할 수 있도록 도와야 합니다.

1일 차를 놓치셨다면, 여기서 시작하세요

2일 차는 워크숍 위주로 진행되었습니다. 만약 1일 차 가상 스트림 (Day 1 virtual stream)을 놓치셨다면, 워크숍 주제를 깊이 파고들기 전에 이 강연들부터 시청하시기 바랍니다.