Azure AI Foundry Threads: AI를 기업 환경에 맞게 준비하는 방법

Azure AI Foundry에 AI를 배포한다는 것은 거대한 모델 하나를 실행하는 데서 끝나지 않습니다. 관련된 모든 작업, 메시지, 도구 호출, 실행 단계가 기록되고 추적되는 관리형 런타임에 AI를 올리는 일입니다. 이 구조 덕분에 예측하기 어려웠던 AI가 감사 가능하고 관리 가능한 시스템으로 바뀝니다.

이 글에서는 에이전트를 구성하는 세 가지 요소, 대화 기록을 담는 스레드(Thread), 에이전트를 실제로 작동시키는 실행(Run)과 실행 단계(Run Step), 그리고 도구와 보안까지 차례로 살펴봅니다. 기업 환경에서 AI를 신뢰하고 도입하려면 무엇이 필요한지 정리해 보겠습니다.

Azure AI Foundry 에이전트: 모델, 지침, 도구의 세 요소

Foundry에서 에이전트를 설정하는 일은 단순히 채팅창을 여는 것과 다릅니다. 명확한 설계에 따라 임무를 수행하는 현장 지휘관을 임명하는 것에 가깝습니다. 그 설계는 모델, 지침, 도구 세 가지로 이루어집니다.

• 모델은 두뇌입니다. 추론과 언어를 담당하며 사람의 말을 분석하고, 단계를 계획하고, 응답을 작성합니다.
• 지침은 임무 명령입니다. 모델이 제멋대로 움직이지 않고 필요한 결과에 집중하도록 붙잡아 줍니다.
• 도구는 지휘관이 갖춘 장비입니다. 코드 실행, 검색 커넥터, 보고용 API, 연결된 타사 시스템 등이 여기에 속합니다.

이 세 요소가 없으면 재현 가능성도 감사 가능성도 확보할 수 없고, 근거 없는 텍스트 생성만 남습니다.

전장에 비유하면

모델은 지휘관이 받은 전투 훈련, 지침은 임무 브리핑입니다. "호송대를 보호하라", "계약서 세트에서 데이터를 추출하라", "결과를 특정 형식으로 보고하라" 같은 명령이 지휘관을 일관되고 예측 가능하게 만듭니다. 도구는 전문성을 더합니다. 벽을 오르는 갈고리가 분석을 실행하는 코드 인터프리터라면, 보안 무전기는 SharePoint나 사용자 지정 MCP 커넥터가 실시간 데이터를 계획에 공급하는 것과 같습니다. 이 셋이 합쳐지면 에이전트는 즉흥적으로 움직이지 않고 로그와 체크포인트를 남기며 임무를 수행합니다.

모델을 자유롭게 바꿀 수 있는 유연성

대부분의 채팅 API는 모델과 프롬프트만 제공합니다. 대화가 시작되면 명령이나 도구 오케스트레이션이라는 공식적인 개념이 없습니다. 반면 Foundry 에이전트 서비스는 세 계층이 모두 존재하도록 보장합니다. 하나의 모델에 묶이지도 않습니다. Foundry 카탈로그에서 복잡한 전략에는 GPT-4를, 가벼운 작업에는 더 효율적인 모델을, 필요하다면 Mistral이나 DeepSeek를 선택할 수 있습니다. 임무에 맞는 두뇌를 고르는 유연성이 획일적인 인턴과 상황에 적응하는 지휘관의 차이입니다.

구조가 없을 때의 위험: 자주 만나는 함정

이 계층들이 없으면 기업 환경에서 다음과 같은 문제가 생깁니다.

• 일관되지 않은 결과: 계약서 요약본 하나는 이렇게 읽히는데, 다음 요약본은 앞의 내용을 미묘하게 반박하기도 합니다.
• 추적성 상실: 답변이 어떻게 도출되었는지 기록하는 구조화된 로그가 없습니다.
• 추측에 의존하는 디버깅: 개발자가 추론 과정을 다시 따라갈 수 없어서 원인 분석이 추측 게임이 됩니다.

기업 환경에서 이것은 단순한 불편이 아니라 신뢰와 도입을 가로막는 실질적인 위험입니다. Foundry는 가드레일을 에이전트 내부에 구축해 이 문제에 대응합니다. 지침은 반드시 따라야 하는 고정된 규칙집 역할을 하고, 도구 세트는 사용 사례에 따라 범위를 좁히거나 넓힐 수 있습니다. 모델은 자유롭게 교체할 수 있지만, 언제나 책임을 강제하는 구조 안에서 교체됩니다.

스레드: 에이전트 대화의 감사 가능한 로그

Foundry에서 스레드는 닫으면 사라지는 일반 채팅창이 아닙니다. 사용자와 에이전트, 또는 멀티 에이전트 구성에서 에이전트끼리 주고받은 모든 교환을 저장하는 지속적인 대화 세션입니다. 채팅이 끝난 뒤에도 오랫동안 검토할 수 있는 상호작용 기록이 남습니다.

스레드는 정적인 대화록에 그치지 않습니다. 자동 절단(truncation)을 처리하는 구조화된 컨테이너여서, 모델의 제한 안에서 활성 컨텍스트를 유지하면서도 전체 감사 추적은 보존합니다. 에이전트는 진행 중인 대화를 계속 이해하고, 기업은 검토 가능한 기록을 유지합니다. 에이전트에게는 연속성을, 기업에게는 거버넌스를 주는 셈입니다.

메시지에 담기는 것

스레드의 항목은 메시지로 구성되며, 일반 텍스트만 있는 것이 아닙니다. 이미지, 스프레드시트 파일, 생성된 코드 블록도 포함할 수 있습니다. 각 메시지에는 타임스탬프가 찍히고 사용자 또는 어시스턴트라는 역할이 표시됩니다. 스레드를 열어 보면 누가 언제 무엇을 말했는지, 어떤 유형의 콘텐츠가 오갔는지 알 수 있습니다. 컴플라이언스 담당자가 어제 제출된 텍스트 요청과 에이전트가 만든 차트 이미지, 두 사건이 발생한 시각을 확인하는 장면을 떠올려 보세요. 단순한 기억이 아니라 완전한 장부입니다.

감사와 디버깅, 두 가지 용도

규제기관이나 내부 감사팀은 스레드를 열어 사용자 요청, 에이전트 응답, 사용된 도구, 각 사건의 시점까지 전체 시퀀스를 즉시 확인할 수 있습니다. 개발자에게는 같은 기록이 디버그 모드 역할을 합니다. 에이전트가 잘못된 코드를 생성했다면 요청 시점으로 돌아가 어떻게 그런 결과에 이르렀는지 확인하면 됩니다.

스레드가 없으면 스크린샷이나 희미한 기억에 의존해 동작을 추적해야 합니다. 컴플라이언스 팀이 증거를 요청하거나 지원팀이 버그를 재현해야 할 때 이런 방식은 도움이 되지 않습니다. 기록이 없으면 증거가 없고, 흔적이 없으면 수정도 어렵습니다. 스레드가 있으면 각 대화가 구조화된 증거가 됩니다. 에이전트 여러 개가 작업을 나눠 서로 대화할 때도 그 주고받음이 함께 기록됩니다.

실행(Run): 기록을 행동으로 바꾸는 트리거

스레드가 기억이라면 실행은 행동입니다. 스레드에는 대화의 백로그, 명령, 맥락이 담겨 있고, 실행은 에이전트가 그 맥락을 가져와 실제로 작업하도록 활성화하는 트리거입니다. 스레드에 "CSV를 분석해라" 또는 "선 그래프를 그려라"라고 적혀 있더라도, 에이전트가 모델과 지침, 도구를 통해 그 요청을 처리하는 순간은 실행입니다. 이때 에이전트는 추가 데이터를 가져오고, 수치를 계산하고, 코드 인터프리터를 호출해 아티팩트를 만들 수 있습니다.

실행은 블랙박스가 아닙니다. 모니터링되고 상태가 추적되는 과정이며, 보통 다음과 같은 상태를 확인할 수 있습니다.

• 대기 중
• 진행 중
• 작업 필요
• 완료 또는 실패

SDK 샘플은 루프 안에서 이 상태를 반복 확인(폴링)하는 방식을 자주 사용합니다. 그러면 무엇이 완료되는지뿐 아니라 언제 일어나는지도 파악할 수 있습니다.

실행 단계(Run Step): 추측을 없애는 단계별 기록

답변이 그럴듯해 보여도 세부 정보가 없으면 에이전트가 외부 API를 호출했는지, 코드를 작성했는지, 아니면 텍스트를 그럴듯하게 지어냈는지 알 수 없습니다. 이런 불투명함은 기업 환경에서 위험합니다. 실행 단계는 이 문제를 해결합니다. 모든 실행에서 어떤 모델 출력이 생성되었고, 어떤 도구가 호출되었으며, 어떤 계산이 이루어지고, 어떤 메시지가 만들어졌는지를 단계별로 기록하기 때문입니다.

체스 기보에 비유할 수 있습니다. 10시 2분에 파일 가져오기, 10시 3분에 코드 블록 실행, 10시 4분에 그래프 아티팩트 반환처럼 각 동작이 순서대로 남고, 나중에 다시 재생해 볼 수 있습니다.

개발자와 컴플라이언스 팀에 주는 이점

실행 단계가 없으면 최종 답변만 보고 과정을 짐작해야 합니다. 검색 쿼리가 잘못되었는지, 수학적 오류가 끼어들었는지 알 수 없습니다. 실행 단계가 있으면 타임라인을 훑어 정확한 오류 지점을 찾아 고칠 수 있습니다. 디버깅이 추측이 아니라 포렌식이 됩니다.

감사인이 "이 요약은 어떻게 생성되었나요?"라고 물어도 모델의 추론을 추상적으로 설명할 필요가 없습니다. 도구 호출, 인터프리터 단계, 구성된 답변까지 모두 타임스탬프가 찍힌 증빙이 있기 때문입니다. 이야기를 지어내는 대신 증거를 제시하는 것이고, 위험이 책임으로, 약속이 증명으로 바뀌는 지점입니다. 워크플로를 다시 실행해야 하거나 결과에 이의가 제기될 때도 같은 순서를 따라 재현할 수 있습니다.

정리하면 스레드는 일기, 실행은 활성화, 실행 단계는 동작 기록입니다. 이 셋이 즉흥적인 AI를 추적하고 테스트하고 방어할 수 있는 책임감 있는 팀원으로 바꿔 줍니다.

도구 모음과 보안: 말하는 AI에서 일하는 AI로

도구는 에이전트를 말만 하는 존재에서 실무자로 바꿉니다. 문서를 확인하는 방법이나 계산을 실행하는 방법을 설명하는 대신, 에이전트가 직접 수행하고 결과물을 돌려줍니다. Foundry의 기능은 세 범주로 나뉩니다.

1. 내장 도구

코드 인터프리터, SharePoint와 Microsoft Fabric 커넥터, Azure AI Search 등이 포함됩니다. 에이전트는 이를 통해 데이터를 분석하고, 파일을 가져오고, 기업 콘텐츠를 검색하고, 차트나 보고서까지 만들 수 있습니다. 결과는 대화형 응답을 넘어 검토하고 재사용할 수 있는 작업 결과물이 됩니다.

2. 맞춤형 도구: OpenAPI와 MCP

Microsoft가 제공하는 기능에만 머무를 필요는 없습니다. OpenAPI 사양이나 MCP(Model Context Protocol)로 맞춤형 도구를 등록할 수 있습니다. MCP는 AI 도구를 위한 USB-C와 같은 역할을 합니다. 에이전트를 원격 MCP 서버에 연결할 때마다 래퍼를 직접 작성할 필요 없이 시스템이 도구 검색, 버전 관리, 호출을 자동으로 처리합니다. 수십 개의 시스템을 연결해야 하는 환경에서는 통합 부담이 크게 줄어듭니다.

3. 관찰 가능한 도구 호출

Foundry의 모든 도구 호출은 ID, 입력, 출력, 타임스탬프와 함께 단계별로 기록됩니다. 무엇이 호출되었는지 정확히 확인하고, 적절한 권한을 따랐는지 검증하고, 규정 준수를 위한 기록을 유지할 수 있습니다.

퀵 스타트 예시와 엔터프라이즈 통합

스레드 메시지로 CSV 파일을 업로드하면, 에이전트가 실행 단계 안에서 코드 인터프리터를 호출해 파일을 처리하고 차트를 생성합니다. 결과물은 첨부 이미지로 반환되어 스레드 로그에서 바로 볼 수 있습니다. 파서나 시각화 도구를 직접 작성하지 않아도 되며, 이는 SDK 샘플에 문서화된 동작입니다.

도구를 Logic Apps와 연결하면 온프레미스 커넥터를 포함해 1,400개 이상의 기존 커넥터에 접근할 수 있습니다. CRM, ERP, ITSM 플랫폼용 어댑터를 새로 코딩하는 대신 이미 비즈니스에서 운영 중인 커넥터를 구성하면 됩니다.

사용자 위임 인증으로 권한 유지

보안은 핵심에서 다뤄집니다. 도구가 SharePoint나 Fabric 같은 기업 시스템에 연결될 때는 Microsoft Entra를 통해 중계되는 사용자 위임 인증을 사용합니다. 사용자가 어제 파일을 읽을 권한이 없었다면 에이전트도 오늘 그 장벽을 우회할 수 없습니다. 아이디와 권한이 그대로 유지되므로 규정 준수팀이 승인할 수 있고, 누가 호출했는지, 무엇이 전송되고 수신되었는지까지 추적할 수 있습니다.

실무 적용을 위한 핵심 정리

• 에이전트는 모델(두뇌), 지침(임무 명령), 도구(장비)의 세 요소로 설계하세요.
• 임무에 맞게 Foundry 카탈로그에서 모델을 선택하고, 필요하면 교체하세요.
• 스레드를 감사와 디버깅의 기본 기록으로 활용하세요. 메시지에는 역할, 타임스탬프, 콘텐츠 유형이 남습니다.
• 실행은 상태(대기 중, 진행 중, 작업 필요, 완료, 실패)로 모니터링하세요.
• 실행 단계로 모델 출력, 도구 호출, 계산, 메시지를 순서대로 확인해 오류 지점을 찾으세요.
• 내장 도구로 시작하고, 확장이 필요하면 OpenAPI나 MCP로 맞춤형 도구를 등록하세요.
• 기업 시스템 연동에는 Microsoft Entra 기반 사용자 위임 인증으로 기존 권한을 그대로 유지하세요.
• 테스트 프로젝트에서 기본 에이전트를 만들고 스레드를 실행한 뒤, SDK나 포털에서 실행 단계를 검사해 로그가 실제 기록과 일치하는지 확인하세요.

결론

Azure AI Foundry는 모델에 프롬프트를 던지는 수준을 넘어, 두뇌와 규칙과 툴킷을 갖춘 에이전트를 반복 가능한 방식으로 구축하게 해 줍니다. 에이전트가 수행하는 모든 작업은 스레드, 실행, 실행 단계로 기록되므로 재현과 감사가 가능합니다. 개발 리드에게는 디버깅의 명확함을, 컴플라이언스 담당자에게는 증거를 주며, 전체 라이프사이클에 대한 통제와 가시성을 확보하게 해 줍니다. 기업 환경에서 AI를 신뢰할 수 있게 만드는 힘은 모델의 크기보다 이런 구조와 기록에서 나옵니다.