Agent Engineering 당신은 어떤 능력의 단점을 보완하려고 노력하고 있나요?
많은 개발자들이 Agent를 처음 접하게 되면 "그냥 LLM API만 조정하는 것 아닌가? 기껏해야 ReAct 루프만 추가하면 되지 않나"라고 생각합니다. 그러나 첫 번째 프로덕션 수준 에이전트를 출시한 후 우리는 문제가 모델 호출 그 이상임을 발견했습니다.
먼저 실제 시나리오를 살펴보겠습니다. 코드 검토 에이전트를 만들고, PR diff를 읽게 하고, Lint 도구를 호출하고 결과를 저장소 주석 영역에 출력하려고 합니다. 직관적인 해결책은 Python 스크립트를 작성하는 것입니다. OpenAI SDK를 사용하여 gpt-4를 호출하고 프롬프트에 diff를 삽입한 다음 반환 값을 구문 분석합니다. 프로토타입은 2시간 만에 실행되었지만 팀의 PR 프로세스에 투입되자 즉시 문제가 발생했습니다. 에이전트가 Lint 도구를 호출했을 때 구문 분석 결과가 모델 출력 형식과 충돌하고 오류 주석이 생성되었습니다. 도구가 시간 초과를 반환한 후 모델이 무작위로 추측하여 코드가 일치하지 않게 되었습니다. 권한 측면에서 에이전트는 모든 분기에 액세스할 수 있었고 민감한 분기에 대한 수정 사항도 검토되었습니다.
이러한 문제는 "모델 조정"으로는 해결할 수 없지만 Agent Engineering에서 다루는 일반적인 문제는 다음과 같습니다.
도구와 모델 간의 상호작용 경계: 에이전트가 외부 도구(Linter, 컴파일러, Git API)를 호출할 때 입력과 출력을 엄격하게 검증해야 합니다. 모델에 의해 "구성된" 반환 값은 거부되어야 하며 도구에 의해 반환된 구조화된 데이터는 모델에 직접 공급될 수 없습니다. 그렇지 않으면 다음 결정을 오염시킬 것입니다. 실제 엔지니어링에서는 모델과 도구 사이에 스키마 확인 및 오류 재시도 논리 계층을 추가하거나 도구마다 별도의 어댑터를 작성해야 합니다.
컨텍스트 관리 및 토큰 예산: 에이전트의 여러 라운드 상호작용을 통해 컨텍스트가 빠르게 축적됩니다. 코드 검토 시나리오에서 각 대화 라운드에는 차이점, 도구 출력 및 모델 사고 체인이 포함됩니다. 3라운드 후에는 컨텍스트가 32K를 초과할 수 있습니다. 관리되지 않는 에이전트는 초기 주요 정보(예: PR 설명)를 잃거나 토큰이 한도를 초과하여 오류를 직접 보고하게 됩니다. Agent Engineering 개발자는 컨텍스트 압축 전략을 설계해야 합니다. 즉, 중복된 중간 추론을 삭제하고, 최종 도구 출력 요약만 유지하고, 슬라이딩 창으로 기록을 정리합니다.
보안 및 권한 경계: 에이전트가 도구 권한을 얻은 후 무단 작업을 수행할 수 있습니다. 위의 예에서 에이전트는 모든 브랜치에 접근할 수 있는데, 이는 과도한 권한입니다. 올바른 접근 방식은 최소 권한 원칙을 따르고, 에이전트에 읽기 전용 토큰을 할당하고, 해당 작업을 웨어하우스 목록 및 화이트리스트 분기로 제한하는 것입니다. 에이전트가 쓰기 작업을 수행하기 전에 다시 확인하세요. 이는 모델 자체로는 판단할 수 없으며 엔지니어링 수준에서 강력하게 제한되어야 합니다.
개발자 혁신에서 가장 과대평가되거나 과소평가되기 쉬운 부분
과대평가된 부분: 모델 이해 및 오류 수정 능력
개발자들은 "모델이 매우 똑똑해서 가장 적절한 결정을 내릴 것"이라고 생각하는 경향이 있습니다. 실제로 에이전트는 도구 사용 중에 도구 출력을 잘못 해석하는 경우가 많습니다. 예를 들어 Lint 도구가 lint_error_count: 5를 반환하는 경우 모델은 이를 "5개의 심각한 오류가 있습니다"로 해석할 수 있지만 실제로는 5개의 경고만 있습니다. 또한 에이전트는 도구 호출이 실패할 때 자체 결과를 구성합니다. 모델은 시간 초과 후 반환 값("성공")을 상상하여 후속 논리 오류를 발생시킵니다. 이를 위해서는 명확한 입력 및 출력 스키마, 시간 초과 재시도 및 각 도구 호출에 대한 예외 처리를 설계해야 합니다.
과소평가된 부분: 상황 관리 및 시스템 프롬프트 디자인
많은 사람들은 "프롬프트를 명확하게 작성하면 된다"고 생각합니다. 그러나 도구를 여러 번 호출하면 에이전트의 컨텍스트 풍선이 표시되고 시스템 프롬프트는 대화 기록에서 손실됩니다. 명시적인 컨텍스트 관리가 없으면 에이전트는 원래 목표를 "잊습니다". 예를 들어, 코드 검토 에이전트는 처음에는 "코드 품질 확인"에 중점을 두었지만 사용자가 관련 없는 질문을 했기 때문에 몇 라운드 후에 "서버에 로그인하는 방법"에 대한 답변을 시작했습니다. 깨지지 않는 시스템 프롬프트 앵커 포인트를 설계하고 컨텍스트 압축 전략을 중첩하는 것이 Agent 프로젝트의 핵심입니다.
또 다른 과대평가: 코드 재사용성
개발자는 일반 모듈을 작성하는 데 익숙하지만 에이전트 프로젝트에서는 도구 호출 로직이 특정 시나리오에 강하게 묶여 있는 경우가 많습니다. 코드 검토를 위해 설계된 Lint 도구 어댑터로, 데이터 정리 에이전트로 전환할 때 매개변수가 완전히 다릅니다. 직접 재사용하면 에이전트가 도구를 잘못 호출하게 됩니다(예: SQL 문을 Lint 도구에 전달). 초기 단계에서는 Agent별로 별도의 툴 어댑터를 작성하고, 충분히 축적한 후 공통 레이어를 추상화하는 것이 좋습니다.
어떤 실제 연습부터 시작하는 것이 좋을까요?
**"에이전트를 호출하는 단일 도구 + 보안 제한 사항"**으로 시작하는 것이 좋습니다. 목표: 외부 도구만 호출할 수 있고 도구 작업의 결과로 인해 시스템이 영구적으로 수정되지 않는 에이전트를 구축합니다.
구체적인 단계:
- 읽기 전용 도구(예: 검색 엔진 API, 로컬 파일 grep, Git log --oneline)를 선택합니다.
- LangChain 또는 기본 함수 호출을 사용하여 도구의 입력 및 출력 스키마를 정의합니다. 예를 들어 검색 도구는
query: string만 허용하고results: [{title, url, snippet}]을 반환합니다. - 시스템 프롬프트에 다음과 같은 확실한 규칙을 추가합니다. "검색 도구만 사용할 수 있으며 잘못된 결과를 생성할 수 없습니다. 검색 결과가 없는 경우 '찾을 수 없음'이라고 진실하게 답해야 하며 구성할 수 없습니다."
- 경계 테스트: 모델이 의도적으로 여러 번(5회 이상) 검색하여 컨텍스트가 통제를 벗어났는지 확인합니다. 모델이 제작되었는지 확인하기 위해 빈 결과를 도구에 반환합니다. 대화 중간에 관련 없는 질문을 삽입하여 한도를 초과했는지 확인하세요.
- 컨텍스트 관리 추가: 각 라운드에서 최근 3개의 검색 결과 요약만 유지하고 원본은 삭제하고 JSON을 반환합니다.
왜 이것을 먼저 할까요? 단일 도구 에이전트는 위험이 가장 낮기 때문에 엔지니어링 문제(도구 출력 남용, 컨텍스트 인플레이션, 모델 우회 제약 조건)의 80%를 노출할 수 있습니다. 이 단계를 완료한 후 도구 수를 늘리십시오.
연습 중 가장 많이 실패하는 방법
실패 사례 1: 컨텍스트 오버플로로 인해 에이전트 기억 상실이 발생함
한 개발자가 검색엔진 Agent를 실습할 때, Agent에게 10개의 키워드를 연속적으로 검색해 달라고 요청했습니다. 6번째 이후에는 에이전트가 시스템 프롬프트를 무시하고 요약을 생성하는 대신 검색 결과의 원본 텍스트 조각을 그대로 반복적으로 출력하기 시작했습니다. 그 이유는 컨텍스트 창이 가득 차서 모델이 최근 대화만 반복할 수 있기 때문입니다.
해결 방법: 기록을 명시적으로 자릅니다. 시스템 프롬프트와 마지막 2회의 전체 대화가 유지되며, 초기 검색 결과의 상위 3개 요약 결과만 유지됩니다.
실패 사례 2: 도구 반환 형식 변경으로 인해 에이전트가 충돌함
연습에는 공개 날씨 API가 사용되었습니다. 어느 날 API가 JSON에 새로운 alerts 필드를 추가했습니다. 에이전트의 구문 분석 코드는 새 필드를 처리하지 않고 오류를 직접 보고합니다. 설상가상으로 에이전트의 성능이 정상적으로 저하되지 않았습니다. 대신 3번 연속 재시도 끝에 포기하고 "날씨를 알 수 없다. 우산을 가지고 외출하는 것이 좋다"고 답했다.
해결 방법: 도구 호출은 스키마 확인을 수행하고 허용/거부 목록을 사용하여 모델이 볼 수 있는 필드를 지정해야 합니다. 새로 추가된 필드는 기본적으로 무시되며 로그에 경보가 발생합니다.
실패 사례 3: 에이전트가 승인되지 않은 작업을 수행하도록 유도되었습니다.
연습에서 에이전트는 파일 읽기 도구(읽기 전용)로 구성되었지만 시스템 프롬프트에는 삭제 작업이 금지되었다는 내용이 표시되지 않았습니다. Agent는 대화에서 "파일 경로가 있으면 내용을 출력해주세요"라는 말을 들었으나 사용자가 "그 로그 파일을 삭제해 주실 수 있나요?"라고 했고, Agent가 파일 삭제 API를 호출하려고 했으나(노출되지 않음), 모델은 오류 보고 후 "파일이 삭제되었습니다"라고 조작했습니다. 이로 인해 권한 사각지대가 노출됩니다. 도구가 읽기 전용이더라도 모델이 작업 결과를 조작할 수 있습니다.
해결 방법: 시스템 프롬프트에 "할 수 있는 작업"과 "절대 할 수 없는 작업"을 명시적으로 나열하고 도구 호출 계층에서 화이트리스트 확인을 수행합니다. 외부 입력 명령은 실행되기 전에 정의된 스키마와 일치해야 합니다.
언제 체계적인 학습이나 강좌로 업그레이드해야 할까요?
다음 시나리오 중 하나를 구축해야 하는 경우 산발적인 연습만으로는 더 이상 충분하지 않습니다.
- 다중 도구 오케스트레이션: 에이전트는 작업에서 3개 이상의 도구를 지속적으로 호출해야 하며 도구 간에 종속성이 있습니다.
- 영구 메모리: 에이전트는 세션 전반에 걸쳐 사용자 기본 설정이나 기록 결과를 기억해야 합니다.
- 인간-에이전트 협업: 에이전트의 제안은 실행 전에 상태 머신 관리와 관련된 수동 확인이 필요합니다.
- 보안 규정 준수: 에이전트는 민감한 데이터(예: 사용자 이메일, 코드 웨어하우스 토큰)를 처리하고 감사 로그가 필요합니다.
- 성능 최적화: 에이전트 응답 지연은 2초 미만이어야 하며 병렬 호출, 캐싱 및 사전 로드가 필요합니다.
이러한 시나리오에는 루프 제어, 오류 격리, 요금 측정 등을 포함한 보다 복잡한 엔지니어링 설계가 포함됩니다. 체계적인 과정(예: 원본 유료 기사 및 AI 고급 프로그래밍 과정)은 모든 함정을 피하기 위한 완전한 디자인 패턴, 코드 프레임워크 및 테스트 방법을 제공합니다.
아직 댓글이 없습니다