런던 AI 엔지니어 서밋 2026은 진전의 축제가 되어야 했습니다. 대신, 그것은 신경 쇠약의 중간에 있는 직업을 비추는 거울처럼 느껴졌습니다.
4월 초 사흘간 수백 명의 AI 엔지니어, 플랫폼 빌더, 연구원들이 모여 자신들이 배운 것을 공유했습니다. 나타난 패턴은 다음과 같습니다: 모두가 에이전트로 구축하고 있고, 아무도 그들을 제어하는 방법을 파악하지 못했으며, 업계는 빠르게 이동할지 신중하게 생각할지에 대해 분열되어 있고, AI가 우리를 더 생산적으로 만들 것이라는 전체 전제가 더 어두운 것으로 뒤집혔습니다.
이것이 우리가 실제로 배운 것입니다.
AI 엔지니어들이 통제할 수 없는 에이전트로 왜 코딩하고 있나요?
서밋에서 가장 솔직한 대화는 무대가 아닌 복도에서 일어났습니다. 중간 규모 핀테크 회사의 엔지니어는 문제를 이렇게 설명했습니다: “프롬프트를 시작하고 3시간 후 내 에이전트가 코드베이스의 절반을 다시 작성했고, 내가 요청하지 않은 기능을 추가했으며, £800의 컴퓨팅을 소비했습니다. 나는 내 책상을 떠날 수 없습니다.”
이것이 FOMAT입니다: 주의 시간 상실에 대한 두려움. 농담이 아닙니다. 이것은 2026년 AI 엔지니어링의 정의하는 불안입니다.
오케스트레이션 병목
서밋의 모든 사람이 에이전트를 사용하고 있었습니다. GitHub Copilot, Claude, 커스텀 에이전트 프레임워크. 도구는 성숙했습니다. 하지만 오케스트레이션은 그렇지 않습니다. “에이전트가 있다"와 “내 에이전트가 내가 의도한 것을 하고 그 이상 아무것도 하지 않는다” 사이의 간격은 거대합니다.
문제는 세 가지 방식으로 나타납니다:
토큰 폭주. 에이전트는 자연적인 정지점이 없습니다. 명시적인 보호 장치 없이 계속 반복합니다. “단지 한 번 더 리팩토링”, 에이전트는 생각하고, 갑자기 당신은 월간 예산을 다 태워버렸습니다.
범위 확대. “오류 처리 개선"이라는 요청이 “전체 오류 처리 시스템 다시 작성, 관찰성 추가, 로깅 계층 리팩토링, 분산 추적 구현"이 됩니다. 에이전트가 잘못된 것이 아니라 철저했습니다. 하지만 그것은 당신이 요청한 것이 아니었습니다.
예측 불가능한 지연. 에이전트 작업이 얼마나 오래 걸릴지 알 수 없습니다. 에이전트가 생성하기로 결정한 하위 작업의 수, 직면한 실패의 수, 재시도할지 아니면 피할지에 따라 달라집니다. 이것은 에이전트 기반 워크플로우를 프로덕션 시스템에서 스케줄하는 것을 불가능하게 합니다.
서밋 합의가 있었던 것(그리고 없었던 것)
해결책에 대한 합의는 없었습니다. 일부 팀은 하드 토큰 제한을 사용하고 있습니다. 다른 팀은 “에이전트 체크포인트"를 구현하고 있습니다. 진행하기 전에 에이전트를 일시 중지하고 허가를 요청하도록 강제합니다. 일부는 “관리자 에이전트"가 워커 에이전트를 감독하고 중단할 수 있는 계층적 에이전트 시스템으로 이동하고 있습니다.
FlowHunt의 접근 방식은 에이전트 노드, 오류 핸들러, 분기 로직이 있는 명시적 워크플로우 정의였으며, 잠재적 패턴으로 여러 번 언급되었습니다. 아이디어: 에이전트가 워크플로우 구조를 결정하도록 하지 마세요. 미리 정의하고 에이전트가 개별 단계를 실행하도록 하세요.
하지만 그것도 밴드에이드처럼 느껴졌습니다. 실제 문제는 에이전트 동작이 본질적으로 확률적이라는 것입니다. 분산을 줄일 수 있지만 제거할 수는 없습니다.
OpenAI-Anthropic 분열이 “좋은 코드"의 의미를 어떻게 재형성했나요?
월요일 아침, OpenAI의 Ryan Lopopolo가 무대에 올라 다음과 같이 요약할 수 있는 기조 연설을 했습니다: 코드 읽기를 멈추세요. 토큰 억만장자가 되세요.
그의 주장: 에이전트 세계에서 코드 볼륨이 중요한 지표입니다. 당신의 에이전트는 하루에 수천 줄을 생성해야 합니다. 당신의 일은 출력 사양을 정의하고 에이전트가 처리량을 최대화하도록 하는 것입니다. 모든 줄을 읽고 이해하는 것은 병목입니다. 테스트를 신뢰하세요. 에이전트를 신뢰하세요. 빠르게 이동하세요.
수요일까지 Anthropic의 Mario Zechner는 반박 기조 연설을 했습니다: 속도를 늦추고 코드를 읽으세요.
그의 주장: 속도는 함정입니다. 당신의 에이전트가 작성하는 모든 코드 줄은 책임입니다. 당신은 그것을 이해하고, 추론하고, 유지할 수 있어야 합니다. 5년 후 승리할 팀은 속도보다 명확성과 의도를 우선시하는 팀입니다. 에이전트는 무의미하게 코드를 생성하는 도구가 아닌 생각하기 위한 도구여야 합니다.
스펙트럼
서밋은 대략 세 진영으로 나뉘었습니다:
| 입장 | 옹호자 | 접근 | 위험 |
|---|---|---|---|
| 토큰 극대주의자 | OpenAI, 일부 스타트업 엔지니어 | 에이전트가 공격적으로 생성하도록 하고 테스트를 통해 출력 품질에 집중 | 유지 불가능한 코드베이스, 보안 부채, 기술적 취약성 |
| 의도적 중간 | 대부분의 엔터프라이즈 엔지니어 | 스캐폴딩에 에이전트 사용, 인간이 아키텍처와 취향 제공 | 더 느린 속도, 하지만 더 안정적인 시스템 |
| 코드 우선 | Anthropic, 일부 연구 엔지니어 | 에이전트가 인간 사고를 강화, 인간이 대부분의 코드 작성 | 낮은 처리량, 하지만 최고의 코드 품질 |
어느 쪽도 틀리지 않았습니다. 불일치는 실패가 무엇처럼 보이는지에 관한 것입니다. Lopopolo는 반복 속도를 최적화하고 있습니다. Zechner는 지속 가능성을 최적화하고 있습니다. 2026년에 팀은 둘 다 최적화할 수 없다는 것을 배우고 있습니다.
인터뷰 문제
한 구체적인 결과: 채용이 망가졌습니다. 토큰 극대주의자라면 후보자가 코드를 잘 짤 수 있는지 신경 쓰지 않습니다. 그들이 효과적으로 프롬프트를 할 수 있고 에이전트 출력을 평가할 수 있는지 신경 씁니다. 코드 우선이라면 깊은 기술적 추론을 보고 싶습니다.
그래서 후보자가 인터뷰에 들어갈 때, 면접관도 후보자도 어떤 프레임워크로 평가되는지 모릅니다. 한 서밋 참석자는 그것을 “안개 속에서 인터뷰하는 것"이라고 설명했습니다.
IDE가 죽고 있는데 GitHub 트래픽이 폭발하는 이유는 뭔가요?
GitHub는 연간 전년 대비 15배의 트래픽 증가를 보고했습니다. Cloudflare는 유사한 급증을 보고했습니다. 한편, 전통적인 IDE들(VS Code, JetBrains, Sublime)은 AI 네이티브 팀 사이에서 사용이 감소하고 있습니다.
이것은 실제로 무슨 일이 일어나고 있는지 이해할 때까지 모순적으로 보입니다.
IDE는 로컬 사고 도구였습니다
IDE는 단일 개발자가 로컬에서 코드를 작성하도록 설계되었습니다. 구문 강조, 자동 완성, 디버깅 도구, 파일 트리가 있었습니다. 자체 포함된 환경이었습니다.
당신의 “개발자"가 에이전트일 때 그 모델은 무너집니다. 에이전트는 구문 강조가 필요하지 않습니다. 디버거가 필요하지 않습니다. 그것은 필요합니다:
- 동시에 여러 파일에 액세스
- 코드를 실행하고 결과를 볼 수 있는 능력
- 버전 관리와의 통합
- 협업 기능 (에이전트와 인간이 함께 작업하기 때문에)
이 모든 것은 이제 브라우저에 있습니다. GitHub Codespaces, VS Code Web, 및 유사한 도구는 로컬 IDE를 대체하고 있습니다.
실제로 성장하고 있는 것
GitHub의 트래픽 급증은 개발자가 브라우저에서 코드를 작성하는 것이 아닙니다. 개발자가 에이전트가 생성한 코드를 검토하고, 댓글을 달고, 병합하는 것입니다. 편집 계층이 아닌 협업 계층이 폭발하고 있습니다.
이것이 Cloudflare도 트래픽 급증을 보고 있는 이유입니다. 개발자들은 클라우드 인프라를 사용하여 에이전트를 실행하고 워크플로우를 오케스트레이션하고 있습니다. “로컬 IDE + 로컬 개발 환경” 모델이 “클라우드 네이티브 에이전트 오케스트레이션 + 브라우저 기반 검토"로 대체되고 있습니다.
L33T C0d3는 죽었습니다
한 세션의 제목이 정확히 그것이었습니다. 요점: 자신의 키보드에서 우아한 코드를 만드는 훌륭한 엔지니어라는 낭만적인 개념은 끝났습니다. 코드는 이제 인간과 에이전트 사이의 협력적 산출물입니다. 중요한 기술은:
- 프롬프트 엔지니어링 (당신이 원하는 것을 지정하는 방법)
- 출력 평가 (에이전트의 코드가 좋은가?)
- 아키텍처 사고 (에이전트가 어떤 구조 내에서 작업해야 하는가?)
- 통합 (에이전트가 생성한 코드가 기존 시스템에 어떻게 맞는가?)
우아한 코드를 작성하는 것은 더 이상 주요 기술이 아닙니다. 에이전트가 하는 일입니다. 인간은 다른 모든 것을 합니다.
MCP에서 정말로 무슨 일이 일어나고 있나요? 죽었나요 아니면 번성하고 있나요?
이것은 서밋에서 가장 혼란스러운 논쟁이었습니다.
한편으로, 개별 AIE와 에이전트 프레임워크 유지보수자들은 다음과 같이 말하고 있었습니다: “MCP는 죽었습니다. 우리는 그것이 필요하지 않습니다. 우리의 에이전트는 API를 직접 호출할 수 있습니다.”
다른 한편으로, 엔터프라이즈 아키텍트와 보안 팀은 다음과 같이 말하고 있었습니다: “MCP 채택이 우리가 도구를 구축할 수 있는 것보다 빠르게 가속화되고 있습니다.”
두 진술 모두 참입니다. 그들은 서로 다른 인구를 설명하고 있습니다.
AIE가 MCP가 죽었다고 생각하는 이유
간단한 에이전트를 구축하는 솔로 개발자의 경우 MCP는 마찰을 추가합니다. 당신은 다음을 해야 합니다:
- 도구에 대한 MCP 서버 정의
- 프로토콜 오버헤드 관리
- 인증 및 권한 부여 처리
- 서버 배포 및 유지보수
API에 직접 액세스를 제공하고 에이전트가 나머지를 파악하도록 하는 것이 더 쉽습니다.
엔터프라이즈가 MCP를 빠르게 채택하는 이유
프로덕션에서 에이전트를 실행하는 조직의 경우 MCP는 갑자기 필수적입니다. 이유는 다음과 같습니다:
보안 격리. 에이전트가 데이터베이스, 결제 시스템, 또는 고객 데이터에 직접 액세스하기를 원하지 않습니다. MCP를 사용하면 에이전트가 기본 시스템을 노출하지 않고 호출할 수 있는 제어된 인터페이스를 만들 수 있습니다.
감사 가능성. 모든 에이전트 작업은 MCP 서버를 통해 진행되며, 이는 로깅합니다. 에이전트가 무엇을 했고 왜 했는지에 대한 완전한 기록이 있습니다.
자격 증명 관리. API 키를 에이전트 프롬프트나 환경 변수에 포함시키는 대신 MCP 서버가 자격 증명을 안전하게 관리합니다.
속도 제한 및 할당량 강제. 에이전트가 리소스를 얼마나 많이 소비할 수 있는지 제어할 수 있습니다.
CData Software에 따르면 2026년 초 현재 포춘 500대 기업의 80%가 주로 이러한 이유로 MCP를 평가하거나 구현하고 있습니다.
해결
서밋 합의: MCP는 죽지 않았습니다. 실험적이고 솔로인 AI 개발의 80%에만 관련이 없을 뿐입니다. 하지만 프로덕션이고 멀티팀인 20%의 경우 MCP는 필수 조건이 되고 있습니다.
이것이 MCP 앱이 증가하는 이유입니다. Anthropic, OpenAI, 제3자 공급업체는 일반적인 도구(Salesforce, Slack, Jira, 데이터베이스)에 대해 미리 구축된 MCP 서버를 구축하고 있습니다. 엔터프라이즈는 커스텀 서버를 구축하지 않고 이를 채택할 수 있습니다.
뉴스레터 가입
최신 팁, 트렌드 및 특가 정보를 무료로 받아보세요.
AI가 우리를 더 생산적으로 만들고 있나요, 아니면 더 과로하게 만들고 있나요?
여기서 서밋이 어두워졌습니다.
AI는 힘의 배수가 되어야 했습니다. 일상적인 작업에 더 적은 시간을 소비하고 전략적 사고에 더 많은 시간을 소비할 것입니다. 생산성이 급증할 것입니다.
대신, 생산성은 급증했고 업무량 기대도 급증했습니다.
실시간 Jevons 역설
Jevons 역설은 원래 석탄 소비에 적용되었으며, 다음과 같이 말합니다: 리소스가 더 효율적이 되면 총 소비가 증가합니다. 왜냐하면 리소스가 더 저렴하고 더 매력적이 되기 때문입니다.
AI 용어로: 에이전트가 코드 생성을 더 저렴하고 빠르게 만들었으므로 관리자는 이제 각 엔지니어가 다음을 기대합니다:
- 10배 더 많은 산출물 제공
- 포괄적인 문서 작성
- 전체 테스트 스위트 구축
- 국제화(i18n) 지원
- 엣지 케이스 처리
- 모두 혼자서 하기
생산성 향상은 부풀려진 기대에 의해 소비되었습니다.
엔지니어들이 말한 것
런던 기반 스타트업의 엔지니어: “나는 하루에 500줄의 코드를 작성했고 생산적이라고 느꼈습니다. 이제 하루에 5,000줄을 작성합니다. 에이전트가 생성했고, 모두 검토하고, 테스트하고, 문서화하고, 이해관계자에게 설명해야 하기 때문에 피곤합니다. 나는 주당 60시간을 일합니다.”
또 다른: “내 관리자가 ‘이제 에이전트가 있으니 두 배나 많은 프로젝트를 처리할 수 있어야 해’라고 말합니다. 나는 더 생산적이지 않습니다. 나는 더 바쁠 뿐입니다.”
한 연구원: “에이전트는 코드 생성에는 능하지만 생성할 코드를 결정하는 데는 능하지 않습니다. 그 의사 결정 부담이 완전히 인간으로 이동했습니다. 우리는 어려운 부분을 자동화하지 않습니다. 우리는 쉬운 부분을 자동화하고 인간이 더 많은 생각을 하도록 만듭니다.”
생산성 맹점
UC Berkeley의 California Management Review는 2026년 1월 이 현상을 문서화한 연구를 발표했습니다. 핵심 통찰: AI 배포는 일을 줄이지 않습니다. 일의 성질을 바꿉니다.
이전 일: 코드 작성. 새로운 일: 에이전트 지시, 출력 평가, 품질 유지, 범위 확대 관리.
새로운 일은 더 적은 타이핑이지만 인지적으로는 더 어렵습니다.
유럽이 AI 엔지니어링에 대해 왜 그렇게 주저하나요?
서밋에는 강한 유럽 대표단이 있었고, 그들의 메시지는 일관되었습니다: 유럽은 AI 엔지니어링 채택에서 미국만큼 빠르게 움직이지 않고 있습니다.
규제 오버행
EU AI 법이 아직 구현되고 있습니다. 회사들은 책임에 대해 불확실합니다. AI 에이전트가 고객에게 해를 끼치는 결정을 내리면 누가 책임이 있습니까? 회사? 모델 공급업체? 엔지니어?
그 불확실성은 마비시킵니다. 많은 유럽 회사는 첫 번째 소송이 어떻게 진행되는지 보기 전에 심각한 에이전트 시스템 구축을 기다리고 있습니다.
기술 격차
유럽의 전통적인 소프트웨어 엔지니어들은 미국만큼 빠르게 AI 엔지니어로 변하지 않고 있습니다. 기술이 전이되는지에 대한 회의론이 있습니다. 많은 유럽 엔지니어들은 AI 엔지니어링이 실제 경력 경로인지 아니면 과대 광고 사이클인지 보기 위해 기다리고 있습니다.
개인정보 보호 우려
유럽은 데이터 처리에 대해서도 더 신중합니다. 에이전트가 유용하려면 데이터에 액세스해야 합니다. 하지만 유럽 회사들은 MCP 보호 장치가 있더라도 에이전트에게 고객 데이터에 대한 액세스를 제공하는 것을 꺼립니다.
앞으로의 길
서밋의 유럽 엔지니어들은 AI에 반대하지 않았습니다. 그들은 신중함을 지지했습니다. 감정: “미국은 빠르게 움직이고 있고 물건을 깨뜨리고 있습니다. 우리는 더 천천히 움직이고 가능한 한 많이 깨뜨리지 않으려고 노력할 것입니다. 5년 후에 누가 맞는지 알 수 있을 것입니다.”
AI 엔지니어링 역할은 실제로 어떻게 변하고 있나요?
서밋이 끝날 무렵 패턴이 나타났습니다: 전통적인 소프트웨어 엔지니어링 역할은 공동화되고 세 가지 새로운 원형으로 대체되고 있습니다.
세 가지 역할
| 역할 | 책임 | 기술 |
|---|---|---|
| AI PM | 에이전트 동작, 성공 지표, 제약 조건 정의 | 제품 사고, 프롬프트 설계, 평가 프레임워크 |
| 에이전트 베이비시터 | 실행 모니터링, 오류 포착, 필요할 때 개입 | 디버깅, 관찰성, 오류 처리, 사건 대응 |
| 취향 설정자 | 출력 품질 평가, 피드백 제공, 개선 가이드 | 코드 검토, 아키텍처 사고, 미적 판단 |
이 역할 중 어느 것도 전통적인 의미에서 코드 작성을 포함하지 않습니다. 모두 에이전트 동작을 지시하고, 평가하고, 개선하는 것을 포함합니다.
사라지는 것
“주니어 엔지니어” 역할이 압축되고 있습니다. 더 이상 “간단한 코드를 쓸 수 있습니다"에서 “시스템을 설계할 수 있습니다"로의 명확한 경로가 없습니다. 중간 단계가 자동화되고 있습니다.
이것은 기술 절벽을 만듭니다: 당신은 프롬프팅과 평가에 능하거나(이 경우 가치 있음) 그렇지 않습니다(이 경우 에이전트와 경쟁하고 있습니다).
성장하는 것
취향, 판단, 아키텍처 사고가 필요한 역할이 성장하고 있습니다. 깊은 도메인 전문성이 필요한 역할도 성장하고 있습니다(에이전트가 올바른 문제를 해결하는지 평가하기 위해 인간이 필요하기 때문에).
서밋은 이것이 좋은지 나쁜지에 대한 합의가 없었습니다. 일부는 그것을 일상적인 코딩으로부터의 해방으로 봤습니다. 다른 사람들은 그것을 직업에 대한 위협으로 봤습니다.
2025년 12월과 2026년 2월 사이에 무엇이 변했나요?
서밋의 한 섹션은 특정 변곡점에 전념했습니다: AI 에이전트 생태계에서 뭔가 새해 즈음에 변했습니다.
자가 개선 소프트웨어가 현실이 되었습니다
OpenClaw 및 유사한 프레임워크는 에이전트가 지속적인 인간 프롬프팅 없이 자신의 결과물을 반복적으로 개선할 수 있게 하기 시작했습니다. “에이전트, X를 계산하는 함수를 작성하세요"에서 “에이전트, X를 계산하는 함수를 작성하고 모든 테스트를 통과하고 엣지 케이스를 처리할 때까지 개선하세요"로 변했습니다.
핵심 통찰, 여러 연구원이 표현한: 에이전트에게 사소한 조언을 요청하는 것을 멈추세요.
대신 에이전트에게 목표를 제공하고 해결책을 개선하도록 하세요. 에이전트는:
- 테스트 작성
- 엣지 케이스 찾기
- 명확성을 위해 리팩토링
- 오류 처리 추가
- 로직 문서화
각 단계를 요청받지 않고도.
이것은 정신 모델을 “도구로서의 에이전트"에서 “자율적 기여자로서의 에이전트"로 바꾸었습니다. 그리고 작업 동역학을 바꾸었습니다: 에이전트가 인간 일을 줄이는 대신, 그들은 그것을 증가시켰습니다(인간이 훨씬 더 정교한 에이전트 출력을 평가해야 하기 때문에).
우리가 함께 살고 있는 모순들
서밋은 해결책 없이 끝났으며, 이는 솔직하게 느껴졌습니다. 2026년 4월의 AI 엔지니어링을 정의하는 모순들은 다음과 같습니다:
모순 1: 에이전트는 위험할 정도로 강력합니다(FOMAT는 실제입니다), 하지만 감독 없이 신뢰할 만큼 강력하지 않습니다.
모순 2: 속도와 품질이 반대로 취급되지만 둘 다 필요합니다.
모순 3: MCP는 동시에 죽었습니다(개인용) 그리고 번성하고 있습니다(엔터프라이즈용).
모순 4: AI는 우리를 더 생산적으로 만들었지만 더 과로하게도 만들었습니다.
모순 5: 모두가 에이전트로 구축하고 있지만 아무도 그들과 잘 구축하는 방법을 파악하지 못했습니다.
모순 6: AI 엔지니어링은 실제 경력 경로이지만 중요하다고 생각했던 기술(코드 작성)은 더 이상 중요하지 않습니다.
이것들은 해결할 문제가 아닙니다. 관리할 긴장입니다. 2026년에 승리할 팀은 이러한 모순이 존재하지 않는 척하는 대신 인정하는 팀입니다.
자주 묻는 질문
우리가 얻은 것
런던 서밋은 전환 중인 직업의 스냅샷이었습니다. AI 엔지니어링은 실제이지만, 그것은 우리가 생각했던 것이 아닙니다. 과대 광고가 시사한 것보다 더 복잡하고, 더 모순적이고, 더 인간에 의존합니다.
서밋에서 최고의 엔지니어들은 가장 정교한 에이전트를 가진 사람들이 아니었습니다. 그들은 에이전트가 생각의 대체물이 아닌 생각하기 위한 도구라는 것을 이해한 사람들이었습니다. 그들은 에이전트 동작을 관리하고, 출력을 평가하고, 품질을 유지하는 프로세스를 구축한 사람들이었습니다. 그들은 생산성 향상이 더 적은 일이 아닌 새로운 종류의 일을 가져온다는 것을 받아들인 사람들이었습니다.
2026년에 AI 시스템을 구축하고 있다면, 서밋의 교훈은 명확합니다:
오케스트레이션이 에이전트 기능보다 더 중요합니다. 좋은 오케스트레이션을 가진 평범한 에이전트는 제어 없는 훌륭한 에이전트를 이깁니다.
명확성이 속도보다 더 가치 있습니다. 빠르게 움직이고 물건을 깨뜨리는 것은 그렇지 않을 때까지 작동합니다. 규모에서는 작동하지 않습니다.
엔터프라이즈 채택은 실제이지만 개인 채택은 여전히 실험적입니다. 솔로 개발자라면 빠르게 움직일 수 있습니다. 팀이라면 보호 장치가 필요합니다.
중요한 기술이 변했습니다. 프롬프트 엔지니어링, 출력 평가, 아키텍처 사고가 새로운 핵심 역량입니다.
더 쉽지 않고 더 열심히 일할 것을 기대하세요. AI는 생산성 배수이지만 이득은 더 높은 기대에 의해 소비되고 있습니다. 그에 따라 계획하세요.
서밋은 “AI 엔지니어링은 무엇처럼 보이는가?“라는 질문에 답하지 않았습니다. 그것은 우리에게 답을 보여주었습니다: 실시간으로 파악하려고 노력하는 우리처럼 보입니다.
{{ cta-dark-panel heading=“에이전트를 수동으로 오케스트레이션하는 것을 멈추세요” description=“FlowHunt의 워크플로우 빌더를 사용하면 에이전트 동작을 정의하고, 보호 장치를 설정하고, 다단계 AI 작업을 자동화할 수 있습니다. 더 이상 FOMAT가 없습니다. 더 이상 에이전트가 무엇을 하는지 추측하지 않습니다.” ctaPrimaryText=“FlowHunt 무료로 시도하기” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“데모 예약” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
