Palantir AI FDE 해부: Foundry를 대화로 조작하는 AI 포워드 배포 엔지니어

들어가며: "포워드 배포 엔지니어"를 에이전트로

Palantir에는 오래된 직군 하나가 있습니다. FDE(Forward Deployed Engineer, 포워드 배포 엔지니어) 입니다. 고객사 현장에 직접 들어가 도메인 문제를 이해하고, 데이터를 잇고, 파이프라인과 온톨로지를 세워 실제로 돌아가는 무언가를 만들어 내는 사람들입니다. Foundry 플랫폼의 손과 발에 해당하는 역할이라고 볼 수 있습니다.

AI FDE는 이 역할을 대화형 에이전트로 옮긴 기능입니다. 공식 문서의 정의를 그대로 옮기면, AI FDE는 "대화형 명령을 통해 여러분을 대신해 Foundry를 조작하는 상호작용형 에이전트"입니다. 자연어 요청을 Foundry 연산으로 번역해, 데이터 변환을 수행하고 코드 저장소를 관리하며 온톨로지를 만들고 유지합니다. 이 글은 Palantir가 공개한 AI FDE 공식 문서(Overview·Navigation·Modes and capabilities·Security and governance·Best practices) 다섯 장을 따라가며, 이 에이전트가 무엇을 하고 어떻게 통제되는지를 한국어로 정리한 기술 노트입니다.

주목할 점은 AI FDE가 단순한 "코드 생성 챗봇"이 아니라, 실제 플랫폼 연산을 직접 실행하는 에이전트라는 데 있습니다. 그래서 이 글의 절반은 "무엇을 할 수 있는가"가 아니라 "어떻게 안전하게 통제되는가"에 대한 이야기입니다. 권한, 승인, 감사(audit)라는 세 축이 에이전트의 자율성과 짝을 이루는 구조를 보게 될 것입니다.

시작 조건: AIP와 Global Branching

AI FDE를 쓰려면 두 가지 전제가 필요합니다. 첫째, 사용 중인 enrollment(엔롤먼트, 조직 단위 계약/테넌트)에 AIP(AI Platform) 가 활성화되어 있어야 합니다. 둘째, 온톨로지 편집을 지원하려면 Global Branching(글로벌 브랜칭) 을 켜는 것이 권장됩니다. 두 가지 모두 조직의 Palantir 관리자에게 요청해 활성화합니다.

Global Branching이 권장 사항으로 등장하는 이유는 뒤에서 반복해서 나옵니다. AI FDE의 기본 동작 원칙이 "곧바로 프로덕션을 바꾸지 않고, 브랜치 위에서 변경한 뒤 리뷰용으로 제안한다"는 것이기 때문입니다. 온톨로지 편집도 이 브랜치 모델 위에서 이뤄지므로 글로벌 브랜칭이 자연스럽게 짝이 됩니다.

AI FDE는 어떻게 동작하는가: 4단계 루프

자연어 요청이 들어오면 AI FDE는 다음 네 단계를 밟습니다.

1. 여러분의 의도(intent)와 제공된 컨텍스트를 분석합니다.
2. 실행할 적절한 Foundry 연산을 결정합니다.
3. 네이티브 도구(native tool) 지원을 통해 요청한 동작을 수행합니다.
4. 맥락에 맞는 설명과 문서를 되돌려 줍니다.

여기서 반드시 붙잡아야 할 원칙이 하나 있습니다. 모든 연산은 사용자의 기존 권한을 그대로 존중합니다. 애플리케이션 접근권과 데이터 접근권을 포함해서입니다. 게다가 사용자는 어떤 모델을 쓸지, 그리고 그 모델이 어떤 도구와 데이터에 접근할 수 있는지를 직접 선택합니다. 그 결과 AI FDE는 "요청한 작업에 필요한 능력만" 손에 쥐게 됩니다. 즉 4단계 루프는 권한과 도구라는 울타리 안에서만 돌아갑니다.

도구를 쓰는 에이전트: Customizable tools

AI FDE의 핵심은 도구 사용(tool use) 입니다. 사용자가 플랫폼에서 직접 할 수 있는 연산 — object type 생성, transform 작성, build 실행 — 에 대응하는 도구를 에이전트가 호출합니다. 문서는 이 능력을 다소 강한 어조로 강조합니다. 도구를 쓸 수 있다는 것은 개발 도구·API·인프라와 실제로 신뢰성 있게 상호작용해야 하는 프로덕션 시스템에서 본질적으로 중요하다는 것입니다. 텍스트를 생성하는 것과 실제 연산을 실행하는 것은 다른 차원의 문제이고, AI FDE는 후자를 지향합니다.

투명성도 함께 설계되어 있습니다. AI FDE는 Foundry에서 어떤 도구를 써서 동작을 수행했는지 화면에 표시하고, 활성 세션 동안 사용된 모든 프롬프트와 도구 기록을 chat outline(챗 아웃라인) 에 보관합니다. 에이전트가 "무엇을 했는지"가 사후에 추적 가능한 형태로 남는 셈입니다.

컨텍스트를 통제하다: 최소에서 시작해 넓혀 간다

에이전트에게 무엇을 보여줄지는 결과 품질을 좌우합니다. AI FDE는 이 지점에서 독특한 기본값을 택합니다. 사용자가 모델이 접근할 수 있는 정보에 대해 완전한 권한과 가시성을 갖도록 하고, 초기 상태에서는 최소한의 컨텍스트만 로드합니다. 이 baseline(기준) 상태에서 모델은 Foundry 개념에 대한 일반 지식만 갖고 있을 뿐, 사용자 데이터에는 접근하지 못합니다. 매 상호작용이 깨끗한 상태(clean state)에서 출발하도록 만드는 설계입니다.

이 접근의 목적은 "context pollution(컨텍스트 오염)"을 막는 데 있습니다. 관련 없는 정보가 섞여 들어오면 모델의 추론 효과가 희석되는데, 통제된 baseline에서 시작하면 모델의 능력과 지식 경계에 대한 정밀한 거버넌스를 유지할 수 있다는 것입니다. 필요한 컨텍스트는 사용자가 능동적으로 넓혀 갑니다. 폴더·dataset·문서를 끌어다 놓는(drag and drop) 방식으로 관련 정보를 공급하는 식입니다. "적게 시작해서 필요한 만큼만 더한다"는 원칙은 뒤의 Best practices에서 다시 강조됩니다.

스스로 검증하는 폐쇄 루프(Closed-loop)

AI FDE는 폐쇄 루프(closed-loop) 동작 모델을 씁니다. 모델이 동작을 실행하고, 그 결과를 관찰하며, 그 피드백으로 다음 동작을 결정하는 방식입니다. 한 연산의 출력이 다음 결정의 입력이 되는 연속적 피드백 고리가 만들어지고, 이것이 여러 단계로 이어지는 복잡한 워크플로를 가능하게 합니다.

특히 중요한 것은 에이전트가 자신의 변경을 스스로 검증한다는 점입니다. 문서가 든 예시는 다음과 같습니다.

• transform 코드를 검증하기 위해 transform preview(변환 미리보기)를 실행합니다.
• 함수의 동작을 검증하기 위해 function preview(함수 미리보기)를 실행합니다.
• Code Repositories에 작성한 코드를 검증하기 위해 CI 체크를 확인합니다.

즉 "코드를 써 놓고 끝"이 아니라, 미리보기와 CI라는 플랫폼의 검증 장치를 에이전트가 루프 안에서 직접 돌려 자기 결과를 확인합니다. 이 검증 단계가 있기에 다단계 자동 작업이 신뢰성을 갖게 됩니다.

무엇을 할 수 있나: 능력의 지형

AI FDE는 자연어 설명만으로 폭넓은 작업을 수행합니다. Overview 문서가 나열하는 대표 작업은 다음과 같습니다.

• Data integration(데이터 통합): Python transform 또는 Pipeline Builder로 데이터 파이프라인을 만들거나 수정합니다.
• Data connection(데이터 연결): Data Connection 소스, egress policy(외부 전송 정책) 등을 생성·관리·디버깅합니다.
• Ontology editing(온톨로지 편집): 온톨로지를 이루는 object·link·action을 만들거나 갱신합니다.
• Functions editing(함수 편집): Logic·TypeScript·Python으로 Foundry 함수를 작성하고 AIP Evals로 테스트합니다.
• Exploration(탐색): 읽기 전용 조사 — 변경하기 전에 플랫폼에 무엇이 있는지 파악합니다.
• Governance(거버넌스): 권한·접근 제어·marking(마킹)·데이터 보호를 감사합니다.
• OSDK React: Foundry 데이터에 연결되는 React 애플리케이션이나 커스텀 위젯을 만듭니다.
• Platform Q&A: Foundry가 어떻게 동작하는지에 대한 일반 질문에 답합니다.

그리고 기본값으로 AI FDE는 모든 워크플로에서 브랜칭을 사용합니다. 변경 사항은 곧장 반영되지 않고 Global Branch proposal(글로벌 브랜치 제안)이나 Code Repository의 pull request 형태로 리뷰를 위해 제안됩니다. 앞서 시작 조건에서 Global Branching이 왜 권장되는지가 여기서 분명해집니다.

모델 지원

AI FDE에서 특정 모델을 쓰려면 그 모델이 enrollment에 활성화되어 있어야 합니다. 문서에 따르면 AI FDE는 Anthropic, OpenAI, Google, xAI의 모델을 first-class(일급) 로 지원하며, 네이티브 도구 API(native tool API)를 함께 지원합니다. 도구 사용이 이 에이전트의 핵심인 만큼, 모델 선택에서도 도구 호출을 네이티브로 지원하는지가 중요한 기준이 됩니다. 다만 AIP 기능의 제공 여부는 변경될 수 있고 고객마다 다를 수 있다는 단서가 붙습니다.

화면 둘러보기: 세션·컨텍스트·아웃라인

Navigation 문서는 실제 화면에서 무엇을 조작하는지 정리합니다. 큰 흐름은 세 가지입니다.

세션 시작. AI FDE 애플리케이션에 들어가면, 페이지 하단의 입력창에서 질문을 하거나 요청을 던지는 것으로 시작합니다. 세션은 상단 툴바에서 관리하는데, 여기서 새 세션을 만들거나 기존 세션을 관리할 수 있습니다.

컨텍스트 추가. 핵심 규칙은 앞서 본 대로입니다. AI FDE는 챗에 추가된 컨텍스트에만 접근합니다. 컨텍스트를 더하는 방법은 여러 가지입니다.

• 하고 싶은 작업을 서술하면, 에이전트가 프롬프트를 바탕으로 mode(모드)를 골라 주고 그에 맞는 컨텍스트와 도구를 결정합니다.
• 입력창 위의 Modes 메뉴에서 모드를 직접 고릅니다. 모드에 따라 추가 설정이 열리는데, 함수에 쓸 언어를 고르거나 Pipeline Builder 대신 transform을 쓸지 정하는 식입니다.
• 프롬프트 입력창 위의 리본(ribbon)에서 컨텍스트를 수동으로 추가합니다. 작업과 관련된 문서 번들을 붙이거나 미디어를 업로드할 수 있고, Foundry 리소스로 Dataset·Function·Branch·Interface·Action type·Object type을 선택할 수 있습니다.
• Foundry의 다른 애플리케이션에서 링크를 끌어다(drag and drop) AI FDE에 놓습니다.
• 관련 리소스를 에이전트가 스스로 찾도록 search tool(검색 도구)을 활성화합니다.

챗 아웃라인. 오른쪽의 접을 수 있는 패널이 chat outline이며, 세션에서 오간 프롬프트·응답·사용된 도구의 이력을 담습니다. 장시간 이어지는 세션에서 모델의 컨텍스트 윈도우(context window) 한계에 부딪히지 않도록, 메시지를 요약하거나 완전히 제거할 수 있습니다(메인 챗에서도, 아웃라인에서도 가능). 아웃라인은 각 메시지가 쓴 토큰 수도 함께 보여 줍니다. 컨텍스트가 곧 자원이라는 사실을 UI가 명시적으로 드러내는 셈입니다.

도구 설정과 승인 트리거

도구 접근은 커스터마이즈할 수 있습니다. 문서는 "모델은 작업에 필요한 도구 부분집합만 켰을 때 더 잘 동작한다"고 못 박고, 입력창 아래 tools 메뉴에서 어떤 도구를 켤지 고르게 합니다. 이는 앞의 컨텍스트 최소화 원칙과 같은 철학입니다.

작업을 시키다 보면 도구 사용 승인을 요구받을 수 있습니다. 기본값으로 다음 상황에서 도구 실행에 승인이 필요합니다.

• 도구가 default branch(기본 브랜치)를 변경하는 경우.
• 도구가 code repository 생성처럼 브랜치에 속하지 않는(unbranched) 변경을 하는 경우.
• 도구가 dataset build처럼 부수 효과(side effect)를 낼 수 있는 경우.

승인 정책은 tool selection panel에서 조정할 수 있습니다. 예컨대 특정 도구를 allowlist에 오른 브랜치·프로젝트에서는 자동 실행되도록 설정할 수 있습니다. "위험한 것에는 승인을, 안전한 반복 작업에는 자동화를"이라는 균형을 사용자가 직접 조율하는 구조입니다.

모드와 능력: 두 층으로 컨텍스트를 관리하다

Modes and capabilities 문서는 AI FDE의 통제 모델을 두 개념으로 정리합니다. mode(모드) 는 "지금 다루는 넓은 과제"이고(예: 데이터 통합, 온톨로지 편집), capability(능력) 는 "여러 모드에 걸쳐 쓰이는 세밀한 능력"입니다. 모드가 큰 맥락을 정하면, 능력이 그 안에서 구체적 행동을 담당합니다.

모드 — 과제의 종류를 알려 주는 스위치

모드는 에이전트에게 어떤 종류의 작업을 하는지 알려 줍니다. 직접 고를 수도 있고, 그냥 작업을 입력해 에이전트가 고르게 할 수도 있으며, 작업이 진행되며 성격이 바뀌면 에이전트가 작업 도중에 모드를 바꾸기도 합니다. 모드는 세 가지 방식으로 에이전트를 집중시킵니다. 알맞은 문서를 로드하고, 관련 도구에 접근을 열어 주고, 문제에 접근하는 방식을 그 과제에 맞게 조정합니다. 문서의 표현을 빌리면, Python transform을 쓰는 에이전트에게 거버넌스나 React 애플리케이션 도구는 필요 없으므로, 관련 문서와 도구만 제공한다는 것입니다. "필요한 것만 준다"는 원칙이 모드라는 형태로 구현된 셈입니다.

AI FDE의 모드는 다음과 같습니다. Overview에서 본 목록에 Machine learning이 더해진, 아홉 개의 모드입니다.

• Data integration: Python transform 또는 Pipeline Builder로 데이터 파이프라인을 만들거나 수정합니다.
• Data connection: Data Connection 소스·egress policy 등을 생성·관리·디버깅합니다.
• Ontology editing: 온톨로지를 이루는 object·link·action을 만들거나 갱신합니다.
• Functions editing: Logic·TypeScript·Python으로 Foundry 함수를 작성합니다.
• Exploration: 읽기 전용 조사 — 변경 전에 무엇이 있는지 파악합니다.
• Governance: 권한·접근 제어·marking·데이터 보호를 감사합니다.
• Machine learning: 머신러닝 모델을 학습·평가·배포·튜닝합니다. 분류·회귀·시계열 예측·커스텀 예측 모델링을 포괄합니다.
• OSDK React: Foundry 데이터에 연결되는 React 애플리케이션이나 커스텀 위젯을 만듭니다.
• Platform Q&A: Foundry의 동작에 관한 일반 질문에 답합니다.

일부 모드는 세부 설정을 조정할 수 있고, 에이전트는 그 선택으로 어떤 문서를 읽고 어떤 도구를 호출할지 정합니다.

능력 — 모드를 가로지르는 세밀한 행동

능력은 어떤 모드에서든 쓸 수 있는 개별 능력이며, 각 능력은 에이전트가 호출하는 하나 이상의 구체적 도구에 대응합니다. 능력은 agent capability(에이전트 능력) 와 domain capability(도메인 능력) 로 나뉩니다.

agent capability는 에이전트가 스스로를 관리하고 소통하는 방식입니다.

• Change mode: 작업 도중 필요하면 사용자가 수동으로 바꾸지 않아도 다른 모드로 전환합니다.
• Request clarification: 진행하기 전에 정보가 더 필요하면 질문합니다(객관식 또는 자유 서술).
• Generate plan: 행동에 앞서 검토용 계획을 초안으로 작성합니다. 모호하거나 여러 단계인 작업에 유용합니다.
• Load documentation: 필요할 때 Foundry 문서를 즉석에서 찾아봅니다.
• Manage context / Manage capabilities: 자신의 작업 기억을 정리하고, 작업이 진행되며 어떤 능력을 켤지 조정합니다.

domain capability는 에이전트가 Foundry에서 실제로 수행하는 행동입니다. 예시로는 다음이 있습니다.

• Filesystem: 폴더를 만들고, 리소스를 탐색하고, 이리저리 옮깁니다.
• Notepad: Notepad 문서를 읽고 만들고 갱신합니다.
• Solution design: 솔루션 설계 다이어그램을 만들고 편집합니다.
• Execute actions: 온톨로지 object에 대해 action을 실행합니다.

능력은 켜고 끌 수 있으며, Manage capabilities가 활성화되어 있으면 에이전트가 작업 도중 스스로 능력을 켜고 끄기도 합니다. 정리하면, 모드는 "무엇을 하는 상황인지"를, 능력은 "그 상황에서 할 수 있는 구체적 행동"을 결정합니다. 둘 다 컨텍스트를 좁혀 에이전트가 헤매거나 엉뚱한 도구를 쓰지 않게 하는 장치입니다.

보안과 거버넌스: 에이전트가 넘을 수 없는 선

여기부터가 AI FDE 설계의 진짜 무게중심입니다. 실제 플랫폼을 조작하는 에이전트에게 가장 중요한 질문은 "무엇을 할 수 있는가"가 아니라 "무엇을 할 수 없는가"이기 때문입니다. 문서의 핵심 주장은 한 문장으로 요약됩니다. AI FDE는 전적으로 여러분의 신원과 권한 아래에서 동작합니다. 별도의 service account나 봇이 아니라, 기존 Foundry 세션을 통해 여러분을 대신해 행동하며, 그 모든 동작은 여러분이 수동으로 할 때와 똑같은 권한 검사·거버넌스 통제·감사 로깅을 받습니다.

권한에 종속된다(Scoped to your permissions)

AI FDE의 모든 연산은 여러분의 인증된 Foundry 세션으로 실행됩니다. 별도의 자격 증명(credential)도, 서비스 계정도, 상승된 권한(escalated privilege)도 관여하지 않습니다. 그래서 에이전트는 정확히 여러분의 사용자 계정과 같은 제약을 받습니다.

• 여러분이 저장소를 만들 권한이 없다면, AI FDE도 만들 수 없습니다.
• 여러분이 어떤 object type을 편집하거나 action을 실행할 수 없다면, AI FDE도 할 수 없습니다.
• 권한 오류(permission error)는 여러분이 그 연산을 직접 했을 때 보게 될 것과 똑같습니다.

이 원칙은 OSDK 애플리케이션 생성, 온톨로지 편집, dataset build, 코드 저장소 연산 등 모든 능력에 예외 없이 적용됩니다. 즉 에이전트에게 권한을 "따로 주는" 것이 아니라, 에이전트가 여러분의 권한을 "빌려 쓰는" 구조입니다.

민감한 동작에는 사용자 승인이 필요하다

서버 측 권한 검사에 더해, AI FDE는 변경성(mutating) 연산을 실행하기 전에 명시적 사용자 확인을 요구하는 도구 승인(tool approval) 시스템을 둡니다. 기본값은 최대한 보수적이어서, 프로덕션 워크플로에 영향을 줄 수 있는 것은 어느 것도 자동 승인되지 않습니다. 다만 세션 동안 특정 도구를 미리 승인해 둘 수 있고, 이는 관련된 브랜치나 프로젝트로 범위를 좁힐 수 있습니다.

핵심은 통제권이 사용자에게 남는다는 것입니다. AI FDE는 여러분의 동의 없이는 쓰기(write) 연산을 수행할 수 없으며, 동의는 동작마다 개별로 주거나 세션 단위로 미리 부여할 수 있습니다.

세션 접근과 보안

각 AI FDE 세션은 그것을 만든 사용자에게만 접근이 허용됩니다. 세션은 다른 사용자와 공유되거나 접근될 수 없습니다. 새 세션이 만들어지면 여러분이 접근 권한을 가진 marking(마킹)이 그 세션에 적용됩니다. 만약 세션에 적용된 어떤 marking에 대한 접근을 잃으면, 그 세션에 대한 접근도 사라집니다. 다시 그 marking에 대한 접근을 얻으면 세션 접근도 복구됩니다. 세션의 가시성이 데이터 보안 등급과 실시간으로 연동된다는 뜻입니다.

감사 로깅과 귀속(Attribution)

모든 활동은 표준 Foundry 감사 로그를 통해 온전히 감사 가능합니다. 모든 API 호출이 여러분의 신원을 실어 나르므로, 플랫폼 수준의 감사 로깅이 수동 동작과 똑같이 여러분에게 귀속된 모든 연산을 기록합니다. 여기에는 저장소 연산, 온톨로지 변경, dataset build를 비롯한 모든 플랫폼 상호작용이 포함됩니다. LLM 사용량 역시 여러분의 개별 사용자 신원에 귀속되어, 사용량 추적과 rate limit(사용률 제한)이 사용자별로 적용됩니다.

정리하면 보안 모델은 일곱 개의 통제로 요약됩니다. 신원(서비스 계정 없음, 여러분 자격으로 실행), 권한(모든 연산에 서버 측 강제), 사용자 승인(동작별 또는 세션 단위 사전 승인, 브랜치·프로젝트로 범위 한정), 세션 접근(생성자 전용, marking으로 보호), 감사 추적(AI FDE 세션 로그 + 표준 Foundry 감사 로그), LLM 귀속(개별 계정 단위 추적), 거버넌스(권한·브랜칭 통제·감사가 예외 없이 적용). 문서의 결론은 명료합니다. AI FDE는 여러분의 기존 Foundry 세션 안에서 동작하는 생산성 도구이며, 여러분의 권한을 넘어설 수 없습니다.

잘 쓰는 법: 다섯 가지 모범 사례

마지막 문서는 AI FDE를 효과적으로 쓰면서 시스템 무결성을 지키는 다섯 가지 지침을 제시합니다.

첫째, 리소스와 절차를 검증하라. 생성된 리소스를 프로덕션에 반영하기 전에 반드시 검증합니다. 생성된 코드가 올바른지, 조직 표준에 맞는지 검토하고, 대표성 있는 샘플 데이터로 변환 로직이 다양한 조건에서 기대대로 동작하는지 시험합니다. AI FDE는 기본적으로 브랜치 위에서 변경하고 그 변경을 Global Branch proposal이나 pull request로 제안하므로, 리뷰 지점이 자연스럽게 확보됩니다. 도구 승인을 요청받으면, 모델이 실행하려는 동작이 무엇인지 이해하고 어떤 도구가 쓰이는지 확인한 뒤 승인해야 합니다.

둘째, 도구와 컨텍스트를 제한하라. 주어진 작업에 꼭 필요한 컨텍스트와 도구만 모델에 제공하기를 권장합니다. 불필요한 컨텍스트나 도구는 최적이 아니거나 잘못된 동작을 낳을 수 있습니다. 필요한 것만 남기면 혼란과 오류 가능성이 줄고, 효율과 정확도가 오르며, 민감한 연산·정보에 대한 접근을 최소화해 보안도 강해집니다. 이는 앞서 본 컨텍스트 최소화·모드·도구 설정 원칙이 운영 지침으로 다시 나타난 것입니다.

셋째, 문제를 분해하고 반복적으로 개발하라. 복잡한 작업은 더 작고 다루기 쉬운 단계로 쪼갭니다. 기본 구조부터 시작해, 각 구성요소가 검증될 때마다 점진적으로 복잡도를 더합니다. AI FDE는 특히 빠른 프로토타이핑(rapid prototyping)에 강해 여러 접근을 신속히 탐색할 수 있습니다. 다만 프로덕션 품질의 구현에는 AI가 만든 토대에 사람의 수동 개발을 더해 미세 조정·최적화하는 조합이 권장됩니다.

넷째, AIP Evals로 성능을 추적하라. AI FDE가 만들거나 고친 함수의 성능을 AIP Evals로 평가하고 추적합니다. LLM 기반 함수에 대한 평가 스위트(evaluation suite)를 만들어 두면 시간에 따른 변경의 영향을 측정하고 여러 접근을 비교할 수 있습니다. 반복적 함수 개발에서 특히 값진데, 변경이 성능을 개선했는지 악화시켰는지에 대한 정량적 피드백을 주기 때문입니다.

다섯째, 인프라 제약을 고려하라. 이 지침은 AI 에이전트만의 새로운 운영 특성을 짚는다는 점에서 눈여겨볼 만합니다. 사람 개발자는 보통 한 번에 한 연산을 하고 그 사이에 생각하며 멈추지만, AI FDE는 몇 초 간격으로 연산을 잇달아 실행합니다. 수십 개의 연산이 몇 분 만에 촉발되고, 작업이 끝날 때까지 쉼 없이 돌아갈 수 있습니다. 게다가 여러 AI FDE 세션이 병렬로 돌면 인프라에 가해지는 부담이 배가됩니다. 사람의 느리고 순차적인 페이스에서는 드러나지 않던 인프라 병목이 이때 표면화될 수 있습니다. 그래서 세 영역을 특히 살펴야 합니다. 스토리지 읽기/쓰기, 컴퓨트 자원(특히 GPU), 스토리지 용량입니다. AI FDE 사용은 고빈도 병렬 연산, 지속적 컴퓨트 부하, 증가한 네트워크 활동, 확장된 스토리지 수요를 감당할 수 있는 인프라를 요구할 수 있습니다.

마치며: 자율성과 통제가 짝을 이루는 설계

AI FDE를 다섯 장의 문서로 관통해 보면, 하나의 일관된 설계 철학이 드러납니다. 이 에이전트는 자연어로 실제 Foundry 연산을 실행하는 자율적 행위자이지만, 그 자율성은 언제나 통제 장치와 쌍을 이루도록 설계되어 있습니다.

핵심을 다시 정리하면 이렇습니다. AI FDE는 의도 분석 → 연산 결정 → 도구 실행 → 설명 반환의 4단계 루프로 동작하고, 미리보기·CI로 자기 결과를 검증하는 폐쇄 루프를 돕니다. 컨텍스트는 최소에서 시작해 사용자가 필요한 만큼만 넓히며, 모드와 능력이라는 두 층으로 에이전트가 볼 것과 할 것을 좁힙니다. 무엇보다 에이전트는 사용자의 신원과 권한 안에서만 움직입니다. 서비스 계정 없이 여러분의 세션으로 실행되고, 민감한 동작에는 승인이 필요하며, 모든 행동은 여러분에게 귀속되어 감사 로그에 남습니다. 그리고 기본값은 늘 브랜치 위에서 제안하고 리뷰받는 방향으로 보수적으로 설정됩니다.

결국 "필요한 것만 준다"는 원칙 — 최소 컨텍스트, 필요한 도구만, 권한 안에서만, 승인받은 것만 — 이 컨텍스트 관리·모드·보안·모범 사례를 하나로 꿰는 실입니다. 실제 시스템을 만지는 AI 에이전트를 조직에 들일 때 무엇을 함께 설계해야 하는지를, AI FDE의 문서는 구체적인 형태로 보여 줍니다.