응용 AI 엔지니어가 되는 방법

이 글은 제가 Applied AI Engineering(응용 AI 엔지니어링)으로 전환하기 전에 있었으면 싶었던 가이드를 직접 작성한 것입니다.

이 역할은 전통적인 소프트웨어 엔지니어링과 대체로 겹치지만, 대부분의 소프트웨어 엔지니어가 전환 과정에서 배워야 하는 몇 가지 중요한 개념을 추가합니다. 이 글을 핵심 주제에 대한 개요로 활용하고, 더 깊이 알아보고 싶을 때는 글 전체에 걸쳐 연결된 자료를 참고하시길 권장합니다.

이 글을 다 읽고 나면 Applied AI Engineering이 무엇인지, 실제 업무에 무엇이 필요한지, 그리고 이것이 전통적인 소프트웨어 엔지니어링을 어떻게 확장하는지 훨씬 더 명확하게 이해할 수 있을 것입니다.

Applied AI 분야에서 가장 흥미로운 문제들을 재능 있는 엔지니어링 팀과 함께 해결하는 데 관심이 있으시다면, 저희는 항상 채용 중입니다. varickagents.com 에서 지원하시거나, 추천하신 분이 채용되시면 $20,000 의 추천 보너스를 드립니다.

하지만 Applied AI Engineering을 이해하는 가장 좋은 방법은 소프트웨어를 구축하는 방식에 대한 사고의 전환에서 시작하는 것입니다.

소프트웨어 엔지니어링 vs AI 엔지니어링

SWE(소프트웨어 엔지니어)와 AI 엔지니어의 가장 큰 차이점은 전통적인 소프트웨어 엔지니어링이 결정론적( deterministic )으로 사고하도록 훈련하는 반면, 응용 AI는 확률론적( probabilistic )으로 사고하도록 강제한다는 점입니다.

일반적인 소프트웨어에서는 로직을 작성하고 실행하며, 문제가 생기면 대개 추적할 수 있습니다. 구조화된 입력이 결정론적으로 구조화된 출력을 제공하기 때문입니다.

응용 AI는 그렇게 작동하지 않습니다. 지능에 대한 비결정론적( non-deterministic ) API 호출을 중심으로 구축하기 때문에, 동일한 입력이 매번 다르게 반환될 수 있습니다. 이 때문에 작업은 단순히 소프트웨어를 구축하는 것을 넘어, 시스템이 실제로 의도한 대로 작동하는지 측정하는 것이 됩니다.

이를 수행하는 방법은 평가( evals )를 통해서입니다. 따라서 에이전트가 실수하지 않도록 보장하는 평가 스위트( evaluation suite )를 구축하는 방법을 설명하겠습니다. 우리가 하는 작업의 비결정론적 특성상, 이것이 응용 AI 개발자의 가장 중요한 기술 중 하나라는 것을 깨달았습니다.

이 글의 다음 부분에서는 AI 에이전트의 각 부분(물론 모델 자체는 제외)을 개발하는 방법을 다룹니다. 모델에 API를 호출할 수는 있지만, 다른 모든 것은 직접 구축해야 하기 때문입니다. 이를 하네스 엔지니어링( harness engineering )이라고 합니다.

마지막으로, 프로덕션 환경에서 하나의 에이전트에서 여러 에이전트로 전환하는 방법과 이것이 왜 분산 시스템( distributed systems ) 문제인지 다루겠습니다. 이 글의 끝까지 읽으신다면 Applied AI 엔지니어로 전환하지 못할 이유가 없습니다.

평가 (Evals)

응용 AI 엔지니어는 평가( evals )를 사용하여 불확실성을 측정된 확신으로 전환합니다. 전통적인 소프트웨어 개발에서는 로직을 직접 작성하고 코드를 테스트했기 때문에 시스템을 신뢰합니다. 응용 AI에서는 모델이 실행할 때마다 다르게 작동할 수 있기 때문에 그런 방식으로 시스템을 신뢰할 수 없습니다. 따라서 AI 엔지니어는 에이전트 주변에 측정 계층( measurement layer )을 구축해야 합니다.

평가( eval )는 에이전트에게 작업을 부여하고, 실행하게 한 후, 수행한 작업을 평가하는 과정입니다. 목표는 두 가지를 증명하는 것입니다: 에이전트가 작업을 올바르게 완료했는지, 그리고 에이전트가 주어진 경계 내에서 머물렀는지입니다.

첫 번째 단계는 결과(outcome)를 평가하는 것입니다. 이는 평가 과정에서 가장 쉬운 단계입니다. 제가 주로 작업하는 인보이스 에이전트의 경우, 인보이스가 올바른 위치에 도착했는지, 또는 중복 항목이 플래그( flag )되었는지 확인하는 것을 의미합니다. 최종 결과를 예상된 결과와 비교하기만 하면 됩니다.

두 번째 단계는 궤적(trajectory)을 평가하는 것입니다. 이는 에이전트가 해당 결과에 도달하기 위해 거친 경로, 즉 호출한 도구, 건드린 필드, 전달한 인수, 그리고 그 과정에서 시도한 작업을 의미합니다. 이것이 중요한 이유는 에이전트가 올바른 최종 답변에 도달하는 동시에 과정에서 위험한 일을 할 수 있기 때문입니다. 인보이스를 올바르게 분류하면서도 은행 정보를 변경하거나 승인 전에 결제를 보낼 수 있습니다.

궤적 자체는 단순한 로그( log )입니다. 에이전트가 호출한 모든 도구와 전달한 인수의 순서가 지정된 목록입니다. 이를 평가한다는 것은 해당 로그에 대해 검사( check )를 작성하는 것을 의미합니다.

일부 검사는 결정론적( deterministic ) 입니다. 예를 들어 send_payment 가 승인 호출 전에 절대 나타나지 않도록 하거나, 에이전트가 쓸 수 있도록 허용된 필드에만 기록되었는지 확인하는 것입니다. 다른 검사는 판단( judgment ) 호출입니다. 예를 들어 에스컬레이션( escalation )이 적절했는지, 추론이 행동을 정당화했는지 등입니다. 이러한 검사는 루브릭( rubric )과 함께 두 번째 모델로 전송됩니다.

따라야 할 일반적인 원칙은 결정론적 검사가 일반적으로 안전 위반을 포착하는 반면, 판단 모델( judge model )은 품질을 평가한다는 것입니다.

결과는 테스트 케이스당 두 가지 등급입니다: 에이전트가 올바른 답변을 얻었는지, 그리고 올바르게 행동했는지입니다. 이 두 가지는 별도로 보고되어야 합니다. 인보이스를 95% 정확하게 분류하지만 실행의 4%에서 금지된 필드를 건드리는 에이전트는 혼합 점수에서는 좋아 보이지만 프로덕션 환경에서는 심각한 비즈니스 문제를 일으키기 때문입니다.

이 글은 평가( evals ) 및 기타 모든 주제에 대한 소개 역할을 하므로, 더 깊이 알아보는 데 도움이 되는 다른 자료를 연결했습니다. 효과적인 평가를 구축하는 방법을 이해하는 데 도움이 된 자료는 다음과 같습니다.

• Anthropic 의 평가 과정
• Lenny 의 평가 완벽 가이드
• Hamel 의 평가 FAQ

각 자료를 모두 살펴보는 것을 권장하지만, Lenny 와 Hamel 의 자료를 먼저 보고 평가 과정(약간 더 실습 위주)을 진행하는 것이 좋습니다.

하지만 평가( eval )에는 여전히 테스트할 에이전트가 필요하며, 모델 주변의 모든 것은 직접 구축해야 합니다. 그 주변 시스템을 하네스( harness )라고 합니다. 다음 섹션에서는 도구 호출( tool calling )부터 컨텍스트 윈도우 최적화( context window optimization )에 이르기까지 하네스 엔지니어링 프로세스의 각 부분을 어떻게 생각해야 하는지 다룹니다.

하네스 엔지니어링 (Harness Engineering)

모델 자체만으로는 에이전트가 아닙니다. 모델은 추론하고, 분류하고, 작성하고, 결정할 수 있지만, 스스로 회사 내에서 작동할 수는 없습니다. 어떤 조치가 취해져야 하는지 말할 수는 있지만, 주변에 시스템을 구축하지 않으면 해당 조치를 안전하게 취할 수 없습니다. 그리고 그 시스템이 바로 하네스( harness )입니다.

하네스는 모델 주변의 모든 것으로, API 호출을 작동하는 에이전트로 전환합니다: 사용할 수 있는 도구, 보는 컨텍스트, 기억하는 상태, 제한하는 가드레일( guardrails ), 그리고 작업이 완료될 때까지 계속 작동하도록 하는 루프( loop ) 등입니다.

하네스의 첫 번째 부분은 도구 실행( tool execution )입니다.

모델은 텍스트만 읽고 쓸 수 있으므로, 모델이 무언가를 하기로 결정할 때 실제로 실행하지는 않습니다. 레코드를 업데이트하거나, 이메일을 보내거나, 데이터베이스를 검색하기 위해 구조화된 요청(JSON 문자열)을 내보냅니다.

하네스는 해당 요청을 수신하고, 검증하며, 실제 작업을 실행하고, 결과를 텍스트로 모델에 다시 보냅니다.

두 번째 부분은 컨텍스트 관리( context management )입니다. 모든 지침, 도구 메뉴, 도구 결과 및 이전 메시지는 모델의 컨텍스트 윈도우( context window )에서 공간을 차지합니다. 하네스는 모델이 지금 무엇을 봐야 하는지, 무엇을 요약해야 하는지, 무엇을 제거해야 하는지 결정해야 합니다. 이것이 없으면 에이전트는 관련 없는 기록 속에서 길을 잃습니다.

하네스 개발 프로세스의 각 부분을 더 자세히 다루는 포괄적인 기사를 별도로 작성할 예정이지만, 지금은 에이전트를 위한 지속적인 학습 플랫폼인 Arize 의 엔지니어가 컨텍스트 관리에 대한 그들의 사고 과정을 깊이 있게 설명하는 이 강연을 들어보시길 권장합니다.

에이전트에 효과적인 컨텍스트 관리를 실제로 적용하는 방법에 대해 더 자세히 알아보려면 다음 블로그를 읽어보세요.

• OpenAI 의 컨텍스트 관리 문서
• 컨텍스트 관리 실용 가이드
• Anthropic 의 컨텍스트 엔지니어링 가이드

하네스 엔지니어링의 세 번째 부분은 상태( state )와 메모리( memory )입니다. 모델은 호출 간에 상태를 유지하지 않으므로( stateless ), 에이전트가 기억해야 하는 모든 것은 모델 외부(일반적으로 데이터베이스, 파일 저장소 또는 작업 레코드)에 있어야 합니다. 컨텍스트는 모델이 지금 보고 있는 것입니다. 상태는 에이전트가 알고 있지만 현재 보고 있지 않은 모든 것입니다.

네 번째 부분은 가드레일( guardrails )입니다. 모델이 올바른 작업과 동일한 확신으로 잘못된 작업을 요청할 수 있기 때문에, 하네스는 권한을 확인하고, 입력을 검증하며, 안전하지 않은 작업을 차단하고, 위험도가 높은 단계를 사람에게 라우팅( routing )해야 합니다.

마지막으로, 이 모든 것은 에이전트 루프( agent loop )에서 함께 연결됩니다: 컨텍스트를 구축하고, 모델을 호출하고, 응답을 검사하고, 허용되면 도구를 실행하고, 결과를 저장하고, 컨텍스트를 업데이트하고, 작업이 완료될 때까지 반복합니다.

하네스 엔지니어링은 Applied AI 엔지니어로서 하게 될 작업의 대부분을 차지하므로, 이 섹션을 천천히 살펴보시기 바랍니다. Applied AI 엔지니어로서 당신의 전체 업무는 확률론적 시스템이 결정론적 소프트웨어 내에서 작동할 수 있도록 하는 운영 환경을 구축하는 것입니다.

하지만 프로덕션 환경은 대개 하나의 에이전트에서 끝나지 않습니다.

워크플로우가 커짐에 따라 자연스러운 본능은 작업을 분할하는 것입니다. 하지만 두 번째 에이전트를 추가하면 시스템 설계가 변경됩니다.

에이전트가 하나일 때는 대부분의 복잡성이 하나의 루프 내에 존재합니다. 여러 에이전트가 있을 때는 이제 동일한 환경에서 작동하는 여러 개의 루프가 생깁니다. 각 에이전트는 다른 에이전트가 방금 변경한 상태를 읽거나, 다른 에이전트가 의존하는 메모리에 쓰거나, 전체 워크플로우에 영향을 미치는 결과를 생성하는 도구를 호출할 수 있습니다.

이 시점에서 어려운 부분은 더 이상 프롬프팅( prompting ), 평가( evals ), 또는 하네스 설계만이 아닙니다. 분산 시스템( distributed systems ) 문제가 됩니다: 어떤 상태를 누가 소유하는지, 누가 메모리에 쓸 수 있는지, 어떤 도구를 재시도( retry )해도 안전한지, 그리고 두 개의 합리적인 에이전트가 잘못된 순서로 작업을 수행하면 어떻게 되는지 등입니다.

멀티 에이전트 배포는 분산 시스템 문제입니다

첫 번째 에이전트가 작동하고 워크플로우가 커지면, 새로운 Applied AI 엔지니어는 자연스럽게 작업을 역할로 분할하려는 본능을 갖게 됩니다. 하나의 에이전트는 조사하고, 하나는 계획하고, 하나는 실행하고, 하나는 검토하는 식입니다.

하지만 두 번째 에이전트는 설계 단위를 에이전트에서 시스템으로 변경합니다. 이제 여러 루프가 동일한 환경에서 작동합니다. 한 에이전트가 고객 상태를 업데이트하는 동안 다른 에이전트는 업데이트되기 전의 상태를 기준으로 계획을 세우는 중일 수 있습니다. 두 에이전트 모두 합리적인 결정을 내렸지만, 시스템이 이러한 결정이 잘못된 순서로 상호 작용하도록 허용한 것입니다.

이것은 분산 시스템( distributed systems ) 문제입니다. 좋은 소식은 분산 시스템 엔지니어들이 수십 년 전에 이러한 실패를 해결했다는 것입니다. 당신의 임무는 이러한 해결책을 LLM을 포함하는 루프에 적용하는 것입니다. 다음은 AI 엔지니어링에 적용되는 분산 시스템의 솔루션 목록입니다.

단일 작성자 원칙 (Single-writer principle). 모든 중요한 상태에는 정확히 하나의 에이전트만이 쓸 수 있습니다. 다른 에이전트는 해당 상태를 읽거나 변경 요청을 제출합니다. 이를 도구 수준에서 적용하십시오. 실행 에이전트만이 CRM에 쓸 수 있다면, 조사 에이전트는 아무리 추론을 잘못하더라도 CRM을 손상시킬 수 없습니다.

멱등성 키 (Idempotency keys). 에이전트는 무언가 실패하거나 시간 초과( timeout )될 때 도구 호출을 재시도( retry )하지만, 도구가 실제 세계에서 무언가를 변경할 때 재시도는 위험할 수 있습니다. 첫 번째 요청이 실패한 것처럼 보였다고 해서 에이전트가 동일한 결제를 두 번 보내는 것을 원하지 않을 것입니다. 해결책은 모든 변경( mutating ) 도구 호출(즉, 외부 시스템의 데이터를 변경하는 모든 작업)에 고유 키를 첨부하는 것입니다. 도구가 동일한 키를 다시 보게 되면 작업을 두 번째로 실행하는 대신 원래 결과를 반환해야 합니다. Stripe 의 API가 이런 방식으로 작동하며, 이는 결제, 이메일 등을 처리할 때 에이전트 개발에도 적용됩니다.

쓰기 전 조건 (Preconditions on writes). 에이전트는 종종 세계의 오래된 관점을 바탕으로 행동합니다. 에이전트가 계획을 세운 시점과 외부 시스템을 업데이트하려고 시도하는 시점 사이에 무언가 변경되었을 수 있습니다. 오래된 쓰기를 방지하기 위해, 변경 도구는 변경을 수행하기 전에 조건을 요구해야 합니다. 예를 들어, "상태가 여전히 '보류 중(Pending)'인 경우에만 '승인됨(Approved)'으로 설정하십시오." 상태가 이미 변경된 경우, 도구는 최신 상태를 조용히 덮어쓰는 대신 명확하게 실패해야 합니다.

명시적 핸드오프 (Explicit hand-offs). 오케스트레이터( orchestrator )에 의해 순서가 지정된 정의된 스키마( schema )를 가진 메시지로 작업을 전달하십시오. 에이전트는 작업을 발견하는 것이 아니라 할당받아야 합니다.

요약 (TLDR)

이 글은 제가 Applied AI 엔지니어로서 배운 가장 중요한 주제인 평가( evals ), 하네스 엔지니어링( harness engineering ), 그리고 멀티 에이전트 시스템 설계( multi-agent system design )에 대한 개요를 제공합니다.

만약 이 글에서 한 가지라도 얻어가신다면, 이것을 기억해 주십시오. 모델은 지능을 제공하지만, 그것을 신뢰할 수 있게 만드는 모든 것(측정 계층, 운영 환경, 조정 규칙)은 여러분이 엔지니어링합니다. 이것들을 이해하면 소프트웨어 엔지니어링에서의 전환은 이미 가지고 있는 기술의 확장이 됩니다.

이런 종류의 작업에 관심이 있고 재능 있는 엔지니어링 팀과 함께 Applied AI 분야에서 가장 흥미로운 문제들을 해결하고 싶다면, 저희는 항상 채용 중입니다. varickagents.com 에서 지원하시면 최대한 빨리 시작하실 수 있습니다. 또한, 지원자를 추천하셔서 채용되시면 $20,000 의 추천 보너스를 드립니다.