AI Native DevCon 1일 차: AI 에이전트를 기업용으로 준비시키기

요약 (TL;DR)

AI Native DevCon의 첫째 날은 AI 네이티브 소프트웨어 개발에 대한 실질적인 현실 점검의 장이었습니다. 현장 티켓은 매진되었으며, 회의실은 650명 이상의 빌더(builders)들로 가득 찼습니다. 에이전트(Agents)는 이제 데모 단계를 넘어 이동하고 있으며, 팀들은 에이전트를 신뢰할 수 있게 만들기 위해 더 나은 기술(skills), 컨텍스트(context), 검증(verification), 보안(security) 및 활성화(enablement) 역량이 필요합니다.

안녕하세요! 다시 오신 것을 환영합니다. Rohan Sharma입니다 👋

DevCon의 첫날은 일반적인 개발자 컨퍼런스라기보다 업계가 집단적으로 중요한 무언가에 합의하는 자리처럼 느껴졌습니다. 코딩 에이전트(Coding agents)는 강력하지만, 단순히 강력하다고 해서 바로 프로덕션 준비(production-ready)가 되는 것은 아닙니다. 프로덕션 준비 상태는 단순히 인상적인 데모를 통해서가 아니라, 신뢰성(reliability), 테스트(testing), 그리고 거버넌스(governance)를 통해 획득되는 것입니다.

공통된 주제는 신뢰성이었습니다. 어떻게 하면 AI 네이티브 개발이 단순히 다듬어진 데모를 넘어 팀을 위해 실제로 작동하게 만들 수 있을까요?

Simon Maple은 프레임을 설정하며 DevCon의 포문을 열었습니다. 이제 질문은 AI가 소프트웨어 개발을 변화시키느냐가 아닙니다. 에이전트가 워크플로(workflow)의 일부가 된 지금, 팀, 플랫폼, 그리고 엔지니어링 문화가 어떻게 적응하느냐가 핵심입니다.

1일 차를 형성한 세션들

기술(Skills)이 새로운 코드(Code)다

Guy Podjarny의 기조 연설인 **“기술(Skills)이 새로운 코드(Code)다”**는 이날의 가장 강력한 초기 논제를 제시했습니다. 우리가 에이전트에게 제공하는 지침(instructions), 기술(skills), 그리고 컨텍스트(context)가 소프트웨어의 실제 단위(unit)가 되어가고 있습니다.

만약 스킬 (Skill)이 에이전트의 행동을 형성한다면, 그 스킬에는 의도 (Intent), 검토 (Review), 테스트 (Testing), 버전 관리 (Versioning) 및 유지보수 (Maintenance)가 필요합니다. 여러분의 SKILL.md 파일이 엔지니어링 프로세스의 혼란스러운 단체 채팅방이 되어서는 안 됩니다. 구조가 필요합니다.

팀들은 이미 에이전트 지침 (Instructions)에 의존하고 있습니다. 부족한 부분은 이러한 지침을 프로덕션 자산 (Production assets)처럼 취급하는 것입니다.

인간을 위해 구축된 플랫폼은 이제 에이전트를 위해 작동해야 합니다

Netlify의 Dana Lawson은 실질적인 플랫폼 과제에 집중했습니다. 대부분의 개발 도구 (Dev tools)는 여전히 인간이 로그 (Logs)를 읽고, 프리뷰 (Previews)를 확인하며, CLI 출력을 해석한다고 가정합니다.

에이전트는 다른 것이 필요합니다. 에이전트에게는 구조화된 신호 (Structured signals), 기계가 읽을 수 있는 피드백 (Machine-readable feedback), 그리고 명확한 다음 작업 (Next actions)이 필요합니다. 그렇지 않으면 에이전트는 추측하거나, 맹목적으로 재시도하거나, 아주 확신에 찬 상태로 무언가를 망가뜨릴 것입니다.

에이전트에게 인간 전용 로그만을 제공하는 것은 종종 불충분합니다. 데이터는 사용 가능할지 모르지만, 에이전트가 이를 효과적으로 사용하려면 구조화되고 기계가 읽을 수 있는 컨텍스트 (Context)가 필요합니다.

개인의 스킬 해킹에서 조직적 역량 강화로

Tessl의 James Moss는 **“Using skills to pay the bills”**라는 주제를 통해 스킬에 대한 논의를 팀의 영역으로 확장했습니다. 개인용 에이전트는 실험하기 쉽습니다. 하지만 팀용 에이전트는 상황이 복잡해지는 지점입니다.

모든 개발자가 서로 다른 지침, 서로 다른 컨텍스트, 그리고 약간씩 다른 에이전트 행동을 갖게 될 수 있습니다. 만약 그 계층이 공유되고, 검토되며, 버전 관리되지 않는다면, 팀은 하나의 AI 워크플로우 (AI workflow)를 가진 것이 아닙니다. 그저 똑같은 후드티를 입고 있는 열 명의 혼란스러운 워크플로우를 가진 것뿐입니다.

Patrick Debois는 **“Coding Agents Don’t Scale Themselves. Neither Do Your Teams.”**에서 그 아이디어를 확장했습니다. 조직은 단순히 에이전트 도구 (Agent tooling)를 배포하고 일관된 결과를 기대할 수 없습니다. 도입을 위해서는 역량 강화 (Enablement), 거버넌스 (Governance), 플랫폼 사고 (Platform thinking), 공유된 관행 (Shared practices), 그리고 이러한 시스템이 실제로 성과를 개선하고 있는지 측정할 수 있는 방법이 필요합니다.

종합해 보면, 두 강연 모두 동일한 결론을 가리키고 있었습니다. 에이전트 도입의 성공 여부는 모델 자체보다는 팀이 이를 어떻게 운영화(operationalize)하느냐에 달려 있다는 점입니다.

기술(Skills) 또한 공급망 리스크입니다

Liran Tal의 “당신의 AI 에이전트가 SKILL.md가 시키는 대로 악성코드를 설치했습니다”라는 강연은 종종 간과되는 보안 과제에 집중했습니다. 만약 특정 기술(skill)이 에이전트의 행동에 영향을 미칠 수 있다면, 그것은 여러분의 공급망(supply chain)의 일부가 됩니다.

팀은 기술(skills)을 감사하고, 그것이 에이전트에게 무엇을 지시하는지 이해해야 하며, 단순히 유용해 보인다는 이유만으로 컨텍스트 파일(context files)을 맹목적으로 설치하는 것을 피해야 합니다. 이름은 귀엽지만, 권한은 위험합니다. 전형적인 사례죠.

하네스 엔지니어링(Harness engineering)은 에이전트 우선 개발을 진지하게 만듭니다

OpenAI의 Ryan Lopopolo는 에이전트 우선 개발(agent-first development)에 필요한 개념을 설명하기 위해 유용한 용어인 **하네스 엔지니어링 (Harness Engineering)**에 대해 논의했습니다. 에이전트에게는 적절한 컨텍스트 (context), 합리적인 도구 접근 권한 (tool access), 명확한 경계 (boundaries), 검증 루프 (verification loops), 그리고 무언가 잘못되었을 때의 피드백이 필요합니다.

[

]

한 가지 실질적인 교훈은 **"모델에게 전체 저장소(repository)를 주는 것은 배포 전략이 아니다"**라는 점이었습니다. 효과적인 에이전트에게는 신중하게 범위가 지정된 컨텍스트 (scoped context), 적절한 도구에 대한 접근 권한, 그리고 할 수 있는 일과 할 수 없는 일에 대한 명확한 경계가 필요합니다. 더 많은 컨텍스트가 항상 더 나은 컨텍스트인 것은 아닙니다.

Ryan은 또한 **검증 및 피드백 루프 (verification and feedback loops)**의 중요성을 강조했습니다. 에이전트는 코드를 빠르게 생성할 수 있지만, 프로덕션(production) 환경에서의 사용은 출력을 평가하고, 실수를 잡아내며, 성능을 지속적으로 개선할 수 있는 메커니즘을 요구합니다. 목표는 감독 없이 작동하는 자율 에이전트가 아닙니다. 에이전트가 독립적으로 작업하면서도 관찰 가능성(observable)과 책임성(accountable)을 유지할 수 있는 시스템을 구축하는 것입니다.

이러한 프레임워크는 에이전트 우선 엔지니어링 (agent-first engineering)을 덜 모호하게 느껴지도록 만들었습니다. 에이전트는 더 많은 것을 실행할 수 있지만, 인간은 여전히 운영 환경 (operating environment)을 설계해야 합니다. 모든 줄을 직접 타이핑하는 것은 줄이고, 시스템을 조종 (steering)하는 비중을 높이는 것입니다.

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

1. 컨텍스트 (Context)가 인프라가 되고 있다

Guy Podjarny의 기조 연설, James Moss 팀의 워크플로우 강연, Mozilla.ai의 cq, 그리고 Robert Overweg의 공유 브레인 (shared-brain) 세션 전반에 걸쳐 논의의 명확한 흐름이 있었습니다.

컨텍스트는 더 이상 단순한 배경 정보가 아닙니다. 그것은 인프라 (infrastructure)입니다.

에이전트로부터 진정한 가치를 얻는 팀은 프롬프트 (prompt)가 가장 긴 팀이 아닐 것입니다. 그들은 인간과 에이전트 모두가 신뢰할 수 있는, 재사용 가능하고 유지 관리되며 구조화된 컨텍스트를 가진 팀이 될 것입니다. 여러분의 에이전트 컨텍스트가 다운로드 폴더처럼 보여서는 안 됩니다. 그것이 어떤 모습인지 우리 모두 잘 알고 있으니까요. 😅

2. 검증 (Verification)이 새로운 병목 현상이다

Shachar Azriel, Simon Martinelli, May Walter, 그리고 Dave Farley는 모두 서로 다른 각도에서 동일한 문제를 지적했습니다. 코드를 생성하는 것은 점점 쉬워지고 있습니다. 하지만 그 코드가 정확한지, 안전한지, 의도와 일치하는지, 그리고 유지 관리 가능한지를 아는 것이 어려운 부분입니다.

만약 AI 워크플로우가 출력 속도만을 최적화한다면, 그것은 매우 빠른 혼란 생성기 (confusion machine)가 될 뿐입니다.

3. AI 네이티브 개발은 팀 설계의 문제이다

조직 관련 강연들은 논의를 일반적인 "모두가 10배의 생산성을 갖게 된다"는 식의 이야기보다 더 성숙한 단계로 이끌었습니다. AI는 리뷰 프로세스 (review processes), 팀의 경계, 제품 워크플로우, 릴리스 안전성 (release safety), 그리고 아이디어가 프로덕션 (production)으로 넘어가는 방식 등을 변화시킵니다.

더 나은 조언은 가장 좋은 의미에서 지루했습니다. 사람들을 제대로 교육하고, 워크플로우 (workflows)를 자주 재검토하며, 인간은 판단과 아키텍처 (architecture)에 집중하게 하고, 도구 채택률 (tool adoption) 대신 결과 (outcomes)를 측정하라는 것이었습니다.

4. 보안은 나중에 덧붙일 수 없습니다

GitHub의 Joseph Katsioloudes와 Snyk의 Liran Tal은 보안의 시급함을 일깨워 주었습니다. AI는 보안 지식을 확장하는 데 도움을 줄 수 있지만, 안전하지 않은 생성 코드 (unsafe generated code), 악성 스킬 (malicious skills), 공급망 노출 (supply-chain exposure), 프롬프트 인젝션 (prompt injection), 그리고 컨텍스트 유출 (leaky context)과 같은 새로운 실패 모드 (failure modes)를 생성하기도 합니다.

다시 말해, 여러분의 에이전트 (agent)가 똑똑할 수는 있지만, 제발 에이전트에게 프로덕션 키 (production keys)와 레드불을 동시에 건네주지는 마십시오.

시청을 추천하는 몇 가지 강연

실험 단계에서 실제 AI 네이티브 (AI-native) 관행으로 넘어가려는 팀이라면, 다음 세션들을 우선순위에 둘 가치가 있습니다:

Guy Podjarny, Tessl - 스킬이 새로운 코드다 (Skills are the new Code)
Dana Lawson, Netlify - 인간을 위해 만들어졌다. 이제 에이전트가 왔다. (Built for Humans. Now Agents Are Here.)
James Moss, Tessl - 스킬을 사용하여 비용을 지불하기 (Using skills to pay the bills)
Liran Tal, Snyk - SKILL.md가 시켰다는 이유로 당신의 AI 에이전트가 멀웨어를 설치했습니다 (Your AI Agent Installed Malware Because a SKILL.md Told It To)
Ryan Lopopolo, OpenAI - 하네스 엔지니어링 (Harness Engineering)
Patrick Debois, Tessl - 에이전트 인에이블먼트 (Agent Enablement)의 부상
Shachar Azriel, Baz - 실행 가능한 명세 (Executable Specs)
May Walter, Hud - 지속적인 에이전트 성능 최적화를 위한 런타임 인텔리전스 (Runtime Intelligence for Continuous Agentic Performance Optimization)
Dave Farley - 바이브 코딩 (Vibe Coding) - 이것이 정말 우리가 할 수 있는 최선인가?

이러한 조합은 컨텍스트 (context), 스킬 (skills), 하네스 (harnesses), 검증 (verification), 런타임 피드백 (runtime feedback), 보안 (security), 그리고 팀 인에이블먼트 (team enablement)라는 이날의 핵심적인 모습을 강력하게 보여줍니다.

파티 시간

에이전트, 컨텍스트, 그리고 약간은 무서운 보안에 관한 이야기로 가득 찬 하루를 보낸 후, 저녁 파티는 좋은 재설정 (reset)의 시간이 되었습니다. 사람들은 복도에서의 대화를 이어가고, 연사들을 만나며, 하루를 정리할 수 있었습니다.

솔직히 말해서, 컨퍼런스에는 이런 시간이 꼭 필요합니다. 최고의 아이디어 중 일부는 세션룸 안에서 탄생하지 않습니다. 누군가가 “잠시만요, 저희도 똑같은 문제를 겪었는데요”라고 말할 때, 그리고 그 대화가 새로운 아이디어, 해결책 또는 연결로 이어질 때 비로소 탄생합니다. 😄

2일 차에 대한 짧은 전망

2일 차에도 동일한 주제가 이어지며, 더 많은 핸즈온 세션 (hands-on sessions)과 노트 작성이나 녹화본을 통해 팔로우업할 가치가 있는 몇 가지 집중 강연들이 예정되어 있습니다:

코드 그 이상의 하네스 엔지니어링 - 에이전트를 위한 제품 및 디자인 제약 조건 (Harness engineering beyond code - product & design constraints for agents) - Tessl의 Marc Sloan
에이전트 시대의 벤치마킹: LLM을 넘어선 성능 측정 (Benchmarking the Agent Era: Measuring Performance Beyond the LLM) - NVIDIA의 Amit Kushwaha
컨텍스트 연결 - 미래의 전송 방식 탐색 (Connecting Context - Exploring Future Transports) - Hugging Face의 Shaun Smith
당신 말이 전적으로 맞아요, 그건 당신의 홈 디렉토리였어요! (You’re absolutely right, it was your home directory!) - Docker의 Oleg Šelajev
프롬프트를 작성하지 말고, 소프트웨어를 작성하세요 (Don’t Write Prompts, Write Software) - Tessl의 Baruch Sadogursky 및 Macey Baker

1일 차가 프레임 (frame)을 제공했다면, 2일 차는 하네스 (harnesses), 기술 (skills), 벤치마킹 (benchmarking), 컨텍스트 (context), 그리고 에이전트 안전성 (agent safety)에 대해 더 깊이 파고듭니다.

앞으로 몇 주에 걸쳐 2일 차의 더 많은 하이라이트, 핵심 요점 및 세션 내용을 공유할 예정입니다.

핵심 요점

1일 차는 한 가지 사실을 명확히 했습니다. AI 네이티브 개발 (AI-native development)이 성장하고 있다는 것입니다.

가장 강력했던 강연들은 개발자를 대체하거나 최신 모델 출시를 쫓는 것에 관한 것이 아니었습니다. 그것은 에이전트를 둘러싼 엔지니어링 작업, 즉 기술 (skills), 컨텍스트 (context), 하네스 (harnesses), 검증 (verification), 보안 (security), 그리고 팀 역량 강화 (team enablement)에 관한 것이었습니다.

그리고 맞습니다, 여러분의 코딩 에이전트는 여전히 커밋 문제 (commitment issues)를 겪고 있습니다. 하지만 1일 차를 거치며, 적어도 업계에는 더 나은 커플 상담 계획이 생겼습니다.

현장에 계셨든 가상으로 참여하셨든, AI Native DevCon에 함께해주셔서 감사합니다.