Microsoft Foundry 실전 가이드: MCP 서버, LangGraph, 브라우저 자동화를 한 플랫폼에 올릴 때 먼저 정해야 할 운영 경계

발행일: 2026-05-02 | 카테고리: 개발정보

2026년 4월 Microsoft Foundry 문서 업데이트를 보면 메시지가 분명합니다. 이제 경쟁 포인트는 단순히 "에이전트를 만들 수 있느냐"가 아니라, 도구 연결, 그래프 오케스트레이션, 브라우저 실행, 안전 가드레일을 어디까지 플랫폼이 맡고 어디부터 팀이 책임질지를 나누는 일입니다. 이 글은 그 경계를 실무 기준으로 해설합니다.

1. 한 줄 문제 정의

핵심 요약: 에이전트가 도구를 많이 쓸수록 모델 품질보다 실행 경계와 승인 경계가 먼저 병목이 됩니다.

많은 팀이 에이전트 프로젝트를 시작할 때는 프롬프트나 모델 선택부터 고민합니다. 하지만 MCP 서버를 붙이고, LangGraph로 여러 단계를 조합하고, 브라우저 자동화까지 열기 시작하면 문제가 달라집니다. 어느 시점부터는 "잘 답하느냐"보다 "어디까지 실행하게 할 것인가"가 더 중요해집니다. 잘못 설계하면 에이전트는 도구를 많이 가진 대신 통제하기 어려운 자동화 계층이 됩니다.

이 글의 대상 독자는 Azure 환경에서 사내 업무용 에이전트, 운영 보조 에이전트, 개발 생산성 에이전트를 설계하는 개발자와 플랫폼 엔지니어입니다. 범위는 Microsoft Foundry Agent Service를 중심으로 MCP 연결, LangGraph 연동, 브라우저 자동화, Task Adherence 가드레일을 함께 보는 것입니다. 단순 챗봇이나 문서 검색만 필요한 경우에는 여기서 다루는 구성이 과할 수 있습니다.

2. 먼저 결론

핵심 요약: Foundry는 "에이전트 플랫폼"이라기보다 실행 책임을 계층화하는 운영 프레임으로 봐야 제대로 씁니다.

• 지금 잘 맞는 팀: Azure 안에서 에이전트를 운영해야 하고, 도구 승인·네트워크 경계·관측성을 같이 묶고 싶은 팀
• 아직 과한 팀: 단일 모델 호출 몇 번으로 끝나는 워크플로, 브라우저 실행이나 외부 도구 연결이 없는 팀
• 제 판단: 2026년 4월 업데이트의 핵심은 기능 수가 아니라, MCP는 도구 경계, LangGraph는 오케스트레이션 경계, Browser Automation은 실행 위험 경계, Task Adherence는 승인 경계를 명시적으로 나눴다는 점입니다.

따라서 Foundry를 도입할 때 제 추천 순서는 "에이전트를 하나 만든다"가 아닙니다. 1) 어떤 도구를 외부에 둘지, 2) 어떤 단계만 그래프로 조합할지, 3) 어떤 작업만 브라우저에 맡길지, 4) 어느 지점에서 사람 승인이나 차단을 넣을지를 먼저 고정해야 합니다.

3. 핵심 구조 분해

핵심 요약: 이번 업데이트는 기능이 흩어진 것이 아니라 네 개의 층으로 정리하면 이해가 쉽습니다.

1. 도구 연결 층: MCP 서버 연결, OpenAPI 도구, Foundry Toolbox 같은 외부 기능 연결 계층입니다. 여기서 핵심은 API 키를 코드에 박는 것이 아니라 project connection으로 인증을 분리하는 구조입니다.
2. 오케스트레이션 층: LangGraph와 Foundry Agent Service 연결입니다. Microsoft는 langchain-azure-ai 패키지와 AgentServiceFactory를 통해 에이전트를 그래프의 노드처럼 다루게 합니다.
3. 실행 층: Browser Automation, computer use, code interpreter처럼 실제 바깥 세계를 건드리는 도구가 여기에 들어갑니다. 이 층부터는 답변 품질보다 실행 권한이 중요합니다.
4. 가드레일 층: Task Adherence와 모니터링입니다. 에이전트가 사용자의 의도와 어긋난 도구 호출을 시도할 때 차단·승인·검토 흐름을 만드는 층입니다.

초보 개발자 기준으로 쉽게 말하면, MCP는 멀티탭, LangGraph는 배선도, Browser Automation은 실제 전동 공구, Task Adherence는 차단기입니다. 멀티탭만 꽂아 놓고 차단기를 빼면 언젠가 사고가 납니다. 이번 Foundry 문서가 보여주는 방향도 정확히 그렇습니다.

4. 설계 의도 해설

핵심 요약: Microsoft는 "도구를 많이 붙이는 자유"보다 붙인 뒤 통제 가능한 기본값에 더 무게를 둔 것으로 보입니다.

MCP 문서에서 가장 중요한 부분은 공용 엔드포인트와 사설 엔드포인트를 분리하고, 사설 MCP는 Standard Agent Setup과 전용 서브넷을 요구한다는 점입니다. 이것은 단순 네트워크 옵션이 아닙니다. 도구 연결 자체를 보안 경계의 일부로 보겠다는 의도입니다.

Browser Automation 문서도 같은 철학을 보여줍니다. 문서는 브라우저 자동화가 큰 보안 위험을 가진다고 직접 경고하고, 민감 데이터나 핵심 시스템 접근 권한이 없는 저권한 VM에서만 쓰라고 적습니다. 즉 "쓸 수 있다"보다 "어디서만 써야 한다"를 먼저 말합니다.

LangGraph 연동 역시 흥미롭습니다. Microsoft는 직접 그래프 프레임워크를 새로 강요하기보다, 이미 팀이 쓰는 LangGraph를 유지하되 에이전트 노드를 Foundry 안으로 들여오는 방향을 택했습니다. 덕분에 팀은 오케스트레이션 코드는 계속 코드로 관리하면서도, 개별 에이전트의 버전·도구·관측성은 플랫폼에서 관리할 수 있습니다. 얻는 것은 중앙 통제와 추적성이고, 포기하는 것은 완전한 무상태 자유도입니다.

5. 근거 및 비교

핵심 요약: Foundry의 비교 대상은 다른 모델 API가 아니라, "직접 다 짜는 방식"과 "플랫폼에 일부 책임을 넘기는 방식"입니다.

근거도 분명합니다.

• MCP 연결 문서(2026-04-23 갱신): 공용/사설 MCP 서버를 구분하고, 사설 MCP는 전용 네트워크 구성을 요구합니다.
• Browser Automation 문서(2026-03-30 작성, 2026-04-14 갱신): Playwright 워크스페이스 기반의 격리 세션을 제공하지만, SLA 없는 프리뷰이며 저권한 환경 사용을 권고합니다.
• LangGraph 연동 문서(2026-03-04 작성, 2026-04-14 갱신): AgentServiceFactory로 기존 에이전트를 그래프 노드처럼 조합하게 합니다.
• Task Adherence 문서(2026-04-02): 도구 호출이 사용자 의도와 어긋나는지 탐지하고, 차단 또는 사람 검토 신호로 넘길 수 있다고 명시합니다.

이 자료들을 함께 보면 Foundry의 진짜 경쟁력은 "도구를 더 많이 준다"가 아닙니다. 실행 위험이 커질수록 통제 포인트를 플랫폼에 흩뿌려 두지 않고 계층화한다는 점입니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 시작은 브라우저 자동화가 아니라 MCP 연결 범위와 그래프 경계를 먼저 좁히는 것입니다.

1. 도구를 세 부류로 분리합니다.
   조회 전용 도구, 변경 가능 도구, 외부 실행 도구로 나누십시오. MCP로 붙일 서버도 이 구분을 따라야 합니다.
2. 공용 MCP와 사설 MCP를 나눕니다.
   GitHub 같은 공용 도구는 public endpoint로, 사내 시스템은 private MCP + Standard Agent Setup으로 분리하는 편이 안전합니다.
3. LangGraph에는 긴 흐름만 올립니다.
   모든 요청을 그래프로 만들지 말고, 승인·분기·재시도가 필요한 흐름만 올리십시오. 예를 들어 "고객 문의 분류 → 내부 문서 조회 → 초안 생성 → 사람 승인" 같은 흐름이 적합합니다.
4. 브라우저 자동화는 마지막에 붙입니다.
   로그인, 예약, 양식 제출처럼 실패 비용이 큰 작업은 초기에 붙이지 마십시오. 먼저 read-only 탐색과 상태 확인부터 제한적으로 여는 편이 낫습니다.
5. Task Adherence를 승인 게이트로 둡니다.
   사용자 요청과 도구 인자가 어긋나면 차단하거나 사람 검토로 넘기도록 합니다. 브라우저·메일·외부 전송 도구는 특히 이중 게이트가 필요합니다.

from azure.identity import DefaultAzureCredential
from langchain_azure_ai.agents import AgentServiceFactory

factory = AgentServiceFactory(
    project_endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

triage_node = factory.get_agent_node(name="support-triage-agent", version="latest")
policy_node = factory.get_agent_node(name="policy-check-agent", version="latest")

# LangGraph에서는 위 노드들을 승인/분기 흐름 안에 조합

MCP 연결 예시는 더 단순합니다. 중요한 것은 URL보다 인증과 승인 구조입니다.

{
  "type": "mcp",
  "server_label": "github-tools",
  "server_url": "https://api.githubcopilot.com/mcp",
  "require_approval": true
}

초보 개발자 기준으로 정리하면, 도구를 붙이는 순서는 조회 → 제한적 변경 → 브라우저 실행이어야 합니다. 반대로 가면 테스트는 빨라 보여도 운영 안정성은 늦게 옵니다.

7. 실수/함정(Pitfalls)

핵심 요약: Foundry에서 흔한 실패는 기능 부족이 아니라 경계 없이 기능을 한꺼번에 여는 데서 나옵니다.

• 실수 1: MCP를 단순 함수 호출 확장으로만 봄
  예방: 공용/사설 엔드포인트, 인증 보관 위치, 승인 여부를 문서화합니다.
  복구: 이미 붙인 MCP 서버를 조회 전용과 변경 가능 서버로 다시 분리합니다.
• 실수 2: LangGraph로 모든 흐름을 과하게 감쌈
  예방: 사람 승인, 장기 상태, 실패 재시도가 필요한 흐름만 그래프로 올립니다.
  복구: 단일 턴 요청은 일반 에이전트 호출로 되돌리고, 그래프는 긴 워크플로에만 남깁니다.
• 실수 3: Browser Automation을 운영 환경에 바로 연결
  예방: 저권한 Playwright 워크스페이스와 민감 자원 분리를 기본으로 둡니다.
  복구: 브라우저 도구 권한을 축소하고, 제출형 액션은 일시 차단한 뒤 read-only 시나리오만 남깁니다.
• 실수 4: Task Adherence를 평가 도구로만 생각함
  예방: 실제 차단·승인 조건에 연결합니다.
  복구: 외부 전송·구매·삭제 같은 고위험 도구 앞에 adherence 점검 단계를 추가합니다.
• 실수 5: project connection 대신 코드에 비밀값을 넣음
  예방: MCP 인증과 API 키는 project connection으로 보관합니다.
  복구: 코드 저장소의 비밀값을 회전하고 연결 구성을 플랫폼으로 옮깁니다.

8. 강점과 한계

핵심 요약: Foundry의 강점은 계층화된 통제이고, 한계는 모든 자유도를 공짜로 주지 않는다는 점입니다.

• 강점: Azure 안에서 인증, 도구, 네트워크, 관측성을 함께 설계하기 쉽습니다.
• 강점: LangGraph를 버리지 않고도 Agent Service 노드를 그래프에 넣을 수 있어 코드와 플랫폼의 역할 분담이 선명합니다.
• 강점: Browser Automation과 MCP처럼 위험한 도구를 문서 단계부터 경고와 제약 중심으로 다룹니다.
• 한계: Browser Automation, 일부 도구, 일부 연결은 프리뷰라 SLA와 기능 제약을 감수해야 합니다.
• 한계: 완전한 클라우드 중립 구성을 원하는 팀에는 Azure 전용 개념이 부담일 수 있습니다.
• 반례: 단순 FAQ나 내부 문서 검색 챗봇은 Foundry의 전체 구성을 쓰기보다 더 얇은 조합이 나을 수 있습니다.

제 의견은 명확합니다. Foundry는 모든 팀의 기본값은 아니지만, 도구 실행 경계가 중요한 팀에게는 매우 현실적인 선택지입니다. 특히 사내 시스템 연결과 승인 흐름이 핵심인 경우에 강합니다.

9. 더 깊게 공부할 포인트

핵심 요약: 다음 단계는 모델 비교보다 도구 위험 등급과 승인 정책을 설계하는 일입니다.

• 사설 MCP 서버를 Azure Container Apps 내부 전용 ingress로 둘 때 운영 비용과 장단점은 무엇인가
• LangGraph 노드 중 어떤 것은 Foundry agent로, 어떤 것은 로컬 코드 노드로 남겨야 하는가
• Browser Automation의 read-only, form-fill, submit 액션을 위험 등급별로 어떻게 나눌 것인가
• Task Adherence 결과를 사람 승인 UI나 티켓 시스템과 어떻게 연결할 것인가
• Foundry Toolbox를 단일 MCP 엔드포인트처럼 쓸 때 변경 관리와 감사 로그를 어떻게 남길 것인가

10. 참고자료

• Microsoft Learn - Microsoft Foundry docs: What's new for April 2026 (작성일: 2026-04-01, 업데이트: 2026-04-17)
• Microsoft Learn - Connect to MCP Server Endpoints for agents (작성일: 2026-04-23, 확인일: 2026-05-02)
• Microsoft Learn - Use LangGraph with the Agent Service (작성일: 2026-03-04, 업데이트: 2026-04-14)
• Microsoft Learn - Automate browser tasks with Foundry agents (작성일: 2026-03-30, 업데이트: 2026-04-14)
• Microsoft Learn - Agentic Workflows Task Adherence (preview) (작성일: 2026-04-02, 확인일: 2026-05-02)
• Microsoft Foundry Blog - What's New in Microsoft Foundry Fine-Tuning | April 2026 (확인일: 2026-05-02)

11. 실행 체크리스트 + 작성자 관점

핵심 요약: Foundry 도입 전에는 기능 목록보다 실행 경계를 먼저 문서화해야 합니다.

• MCP 서버를 조회 전용/변경 가능/고위험 실행용으로 위험 등급화했다
• 사설 시스템 연결은 private MCP + Standard Agent Setup 필요 여부를 검토했다
• LangGraph에는 승인·분기·재시도가 필요한 흐름만 올리기로 했다
• Browser Automation은 저권한 워크스페이스에서 read-only 시나리오부터 시작한다
• 외부 전송·삭제·구매류 도구 앞에는 Task Adherence 또는 사람 승인 게이트를 둔다
• project connection으로 인증 정보를 분리하고 코드 저장소에는 비밀값을 남기지 않는다
• 도구 호출 로그, 승인 이력, 실패 복구 절차를 운영 문서에 남긴다

Definition of Done: 팀이 어떤 도구를 어느 네트워크 경계에서 쓰는지, 어떤 단계에서 사람 승인 또는 차단이 필요한지, 그래프 흐름과 일반 에이전트 호출을 어디서 나누는지 문서화되어 있고 테스트 시나리오로 검증되면 1차 도입 완료로 봅니다.

제 추천은 이렇습니다. Foundry를 기능 카탈로그로 보지 말고 실행 책임을 나누는 프레임으로 보십시오. 그 관점으로 접근하면 MCP, LangGraph, Browser Automation, Task Adherence가 각각 왜 필요한지 정리가 됩니다. 반대로 이 경계 없이 한꺼번에 붙이면, 플랫폼이 많아질수록 팀 통제력은 오히려 줄어듭니다.