선임 엔지니어가 AI 에이전트를 구축할 때 어려움을 겪는 이유는 무엇일까요? @philschmid는 흥미로운 역설을 공유했습니다. 숙련된 시니어 엔지니어가 AI 에이전트를 개발할 때 주니어 엔지니어에 비해 왜 더 느리고 어려운 진전을 보이는 것일까요? Schmid는 근본 원인이 기존 소프트웨어 엔지니어링이 결정론과 모호성 해소를 강조하는 반면, 에이전트 엔지니어링은 본질적으로 확률론적이어서 엔지니어가 비선형 프로세스와 자연어 입력을 처리하기 위해 LLM(Local Level Models)을 "신뢰"하는 법을 배워야 한다는 사실에 있다고 생각합니다. 그는 이러한 사고방식 전환의 어려움을 다섯 가지 주요 과제를 통해 분석하고, 엔지니어가 이러한 패러다임에 적응할 수 있도록 실질적인 통찰력을 제공합니다. 핵심 요점: 결정론에서 확률론으로의 패러다임 전환. 기존 소프트웨어 개발은 예측 가능성을 우선시합니다. 고정된 입력, 결정론적인 출력, 그리고 예외 처리를 통한 오류 격리가 그 예입니다. 이와 대조적으로, 지능형 에이전트는 LLM을 "두뇌"로 삼아 자연어를 통해 의사 결정을 내리고 다중 턴 상호작용, 분기 및 적응을 가능하게 합니다. 그러나 시니어 엔지니어는 본능적으로 "불확실성을 코딩에서 배제"하려는 경향이 있는데, 이는 아이러니하게도 지능형 에이전트의 잠재력을 저해합니다. 슈미트는 주니어 엔지니어가 불확실성을 더 직관적으로 받아들이고 작동하는 프로토타입을 더 빨리 제작할 수 있는 반면, 시니어 엔지니어는 수년간 축적된 습관을 극복해야 한다고 지적합니다. 다섯 가지 핵심 과제는 기존 엔지니어링 방식과 에이전트 개발 간의 다섯 가지 갈등 요소를 간략하게 설명합니다. 각 과제에는 설명과 예시가 함께 제공되어 더욱 유연한 접근 방식으로 전환하는 방법을 강조합니다. 1. 텍스트는 새로운 상태입니다 기존 시스템은 상태를 표현하기 위해 구조화된 데이터(예: `is_approved: true/false`와 같은 부울 값)를 사용하여 불연속성과 예측 가능성을 보장합니다. 그러나 실제 의도는 "이 계획은 좋아 보이지만 미국 시장에 집중해 주세요."와 같은 사용자 피드백처럼 자연어의 미묘한 차이에 묻혀 있는 경우가 많습니다. 시스템에 이진 구조를 강제로 적용하면 이러한 미묘한 차이를 놓치게 되어 에이전트가 동적으로 대응할 수 없게 됩니다. 통찰력: 원본 텍스트를 상태로 보존하여 LLM이 맥락에 맞춰 해석할 수 있도록 합니다. 예를 들어, "날씨는 섭씨를 선호하지만 요리는 화씨를 사용합니다"와 같은 사용자 선호도를 단순한 부울 값 대신 저장할 수 있습니다. 이를 위해 엔지니어는 "구조 우선"에서 "의미적 유연성"으로 전환해야 합니다. 2. 통제권 이양 마이크로서비스와 같은 기존 아키텍처는 고정된 경로와 API 엔드포인트를 사용하여 프로세스를 제어합니다. 그러나 에이전트는 단일 자연어 진입점만 가지며, LLM은 도구와 컨텍스트를 기반으로 다음 단계를 결정합니다. 잠재적으로 루핑, 백트래킹 또는 리디렉션이 발생할 수 있습니다. 예를 들어, "구독 취소" 인텐트는 "에이전트 유지를 위한 할인 제공"이라는 협상으로 이어질 수 있습니다. 이러한 프로세스를 하드코딩하면 에이전트의 적응력이 저하됩니다. 통찰력: LLM이 제어 흐름을 처리하고 전체 맥락에 대한 이해를 활용할 수 있도록 신뢰하십시오. 엔지니어는 모든 분기를 미리 설정하는 대신 이러한 "비선형 탐색"을 지원하는 시스템을 설계해야 합니다. 3. 오류는 단지 입력일 뿐입니다. 기존 코드에서는 변수 누락과 같은 오류가 예외를 발생시켜 충돌이나 재시도로 이어집니다. 그러나 에이전트가 실행될 때마다 시간과 리소스가 소모되므로 완전한 실패는 용납될 수 없습니다. 저자들은 오류를 새로운 입력으로 처리하여 에이전트에 피드백함으로써 자가 복구를 가능하게 해야 한다고 강조합니다. 통찰력: 오류를 격리하는 대신, 복구를 위해 LLM으로 다시 연결하는 복원력 있는 메커니즘을 구축하세요. 이는 확률론적 사고를 반영합니다. 실패는 끝이 아니라 반복의 기회입니다. 4. 단위 테스트에서 Evals로 단위 테스트는 결정론적 출력에 적합한 이진 단언(합격/불합격)에 의존합니다. 그러나 에이전트의 출력은 확률적입니다. 예를 들어 "이 이메일을 요약해 주세요"라는 명령은 수많은 유효한 변형을 생성할 수 있습니다. LLM을 시뮬레이션하는 테스트는 구현 세부 사항만 검증할 뿐, 전체적인 동작은 검증하지 않습니다. 통찰력: 신뢰성(45/50 통과와 같은 성공률), 품질(LLM을 평가 기준으로 유용성과 정확성을 평가), 그리고 추적(지식 기반 참조 여부와 같은 중간 단계 확인)을 포함하는 "평가"로 전환하십시오. 목표는 100% 확실성이 아니라 높은 신뢰도의 성공 확률입니다. 5. 에이전트는 진화하지만 API는 그렇지 않습니다. API는 인간 사용자가 맥락을 추론할 수 있다는 가정 하에 설계되었지만, 지능형 에이전트는 "문자 그대로 해석하는" 존재입니다. get_user(id)의 "email"을 UUID로 잘못 해석하면 잘못된 응답을 받을 수 있습니다. API의 모호성은 LLM의 한계를 더욱 심화시킵니다. 통찰력: 상세한 의미 유형(예: delete_item_by_uuid(uuid: str))과 docstring을 사용하여 "완벽한" API를 설계하세요. 지능형 에이전트는 API 변경 사항에 즉시 적응하여 기존 코드보다 더욱 유연하게 사용할 수 있습니다. 해결책과 시사점 슈미트는 엔지니어링 원칙을 완전히 포기하는 것을 옹호하지 않고, 오히려 "신뢰하되 검증하라"는 균형점을 추구합니다. 즉, 확률적 관리를 평가하고 추적하여 복원력 있는 시스템을 구축하는 것입니다. 동시에 그는 에이전트가 전능하지 않다는 점을 인지하고 있습니다. 즉, 단순한 선형 작업이 에이전트보다 워크플로에 더 적합합니다. 예를 들어 사용자 피드백의 텍스트 상태 보존, 오류 기반 복구 루프 허용, 평가를 사용하여 에이전트 성과 정량화(예: 90% 성공률, 4.5/5 품질 점수) 등이 있습니다. 블로그 주소:
