원래 thousandcuts.ai의 가이드로 게시되었습니다. 설명된 툴킷은 오픈 소스입니다: Thousand-Cuts/wf-toolkit.

Workfront MCP와 Claude: 실제 운영 환경에서의 현장 보고서

현재 세 가지 서로 다른 것들이 "Workfront AI"라는 이름을 사용하고 있으며, 이들을 혼동하는 것은 평가 팀의 귀중한 시간을 낭비하게 만듭니다. 첫 번째는 Workfront 자체 인터페이스 내에 있는 AI Assistant입니다. 두 번째는 Adobe가 출시한 Workfront MCP 서버로, Claude나 ChatGPT와 같은 AI 플랫폼이 사용자의 인스턴스에 접근할 수 있게 해줍니다. 그리고 거의 아무도 실전에서 보지 못한 세 번째 범주가 있습니다. 바로 Claude 측에 존재하며 Workfront가 실제로 어떻게 작동하는지에 대한 검증된 지식을 자체적으로 보유한 스킬 툴킷 (skills toolkit)입니다.

우리는 세 번째 요소를 고객 테넌트(tenants) 전반에 걸쳐 매일 실제 운영 환경에서 실행하고 있습니다. 이 메모는 두 번째와 세 번째 요소에 대해 솔직하게 다룹니다. 즉, MCP 서버가 무엇인지, 무엇을 진정으로 잘하는지, 정확히 어디에서 한계가 발생하는지, 그리고 지식을 보유한 툴킷이 무엇을 다르게 수행하는지를 다룹니다. 시간 측정(timings) 데이터도 포함했습니다. 시간 측정 데이터가 없는 주장은 마케팅에 불과하기 때문입니다.

Workfront MCP 서버란 무엇인가

Workfront MCP 서버는 Adobe가 구현한 Model Context Protocol (MCP)입니다. 이는 Claude, ChatGPT, Copilot, Gemini와 같은 AI 플랫폼이 자연어 요청을 통해 사용자의 Workfront 인스턴스 내 객체를 검색, 생성 및 업데이트할 수 있도록 하는 커넥터 (connector)입니다. 이 서버는 프로젝트, 작업 (tasks), 이슈 (issues), 승인 (approvals), Planning 레코드 및 보고 쿼리 (reporting queries)를 다루며, 해당 사용자의 기존 권한을 가진 로그인된 사용자로서 동작합니다.

그 마지막 조항은 기능 목록보다 더 중요합니다. MCP는 AI에게 새로운 권한을 부여하는 것이 아니라, AI에게 당신의 권한을 빌려주는 것이며, 관리자가 그 범위를 결정합니다. 시스템 설정 (System Preferences)에서 두 개의 토글이 전체를 제어합니다: 읽기 전용 도구 (read-only tools, 기본적으로 켜짐)와 쓰기 도구 (write tools, 기본적으로 꺼짐). 평가 회의 전에 알아두어야 할 Adobe의 자체 문서에 기반한 두 가지 사실이 더 있습니다: 계획 도구 (Planning tools)는 Planning 패키지가 필요하며, 이 글을 쓰는 시점을 기준으로 서버는 AWS에 호스팅된 고객에게만 제공됩니다. 보드 (Boards) 지원은 곧 출시될 예정으로 기재되어 있습니다.

잘 작동하는 부분

공정하게 평가하자면 — MCP는 그것이 구축된 목적, 즉 업무 데이터에 대한 대화형 액세스 (conversational access)를 매우 잘 수행합니다.

"Spring 포트폴리오의 모든 프로젝트를 요약하고 위험 요소가 있는 항목을 표시해줘"라는 명령은 실제 가능한 기능이며, Adobe의 발표에서 설명한 대로 작동합니다. "Website Redesign 하위에 태스크를 생성하고, 나에게 할당하며, 마감일은 금요일로 설정해줘" 역시 마찬가지입니다. Anthropic의 Workfront 커넥터는 이 서버에서 실행되며, 상태 보고 회의(status meetings)가 일상인 프로젝트 매니저에게는 요약 및 플래그(summarize-and-flag) 루프만으로도 이 설정을 도입할 가치가 충분합니다.

만약 질문이 "Claude가 내 Workfront 인스턴스를 읽고 그에 대한 질문에 답할 수 있는가"라면 — 정답은 '예'입니다. 읽기 도구 (read tools)를 활성화하면 점심시간 전까지 대부분의 준비를 마칠 수 있습니다.

한계점: 사실 확인 결과

우리의 실제 운영 업무는 매일 Workfront의 API 및 인터페이스 표면을 통해 진행되며, MCP의 커버리지 경계는 일반적인 객체 액세스 (generic object access)의 경계와 일치하기 때문에 명확하게 정의할 수 있습니다. 다음 사항들은 단순히 MCP의 어휘(vocabulary)에 포함되어 있지 않습니다:

• TEXT MODE — 뷰(views), 필터(filters), 그룹화(groupings), 값 표현식(valueexpressions). 관리자들이 실제로 씨름하는 보고 언어(reporting language).
• CALCULATED FIELDS — 커스텀 폼(custom forms)에서 계산 구문(calculation syntax)을 작성하고 디버깅하는 작업.
• CUSTOM FORM STRUCTURE — 필드(fields), 섹션(sections), 표시 로직(display logic), 폼 간 감사(cross-form audits). MCP는 객체(objects)를 건드릴 수는 있지만, 폼 아키텍처(form architecture)를 알지는 못합니다.
• BUSINESS RULES — 설정(Setup) 하위의 저장 시 차단 검증 공식(block-on-save validation formulas).
• FUSION — 시나리오(scenarios), 블루프린트(blueprints), 에러 처리(error handling). 자동화 플랫폼(automation platform) 전체가 빠져 있습니다.
• REPORT DEFINITIONS — 데이터 쿼리(querying data)는 가능하지만, 보고서 객체(report objects) 자체를 구축하거나 수정하는 것은 불가능합니다.
• PERMISSIONS DIAGNOSTICS — MCP는 사용자의 액세스 권한(access level)을 따를 뿐, 특정 사용자가 왜 프로젝트를 볼 수 없는지 설명할 수는 없습니다.

그리고 단일 격차보다 더 중요하게 작용하는 하나의 구조적 한계가 있습니다: MCP는 한 번에 하나의 환경(environment)에만 연결됩니다. 하나의 테넌트(tenant), 하나의 연결. 다음 섹션을 위해 이 점을 명심하십시오. 왜냐하면 우리가 사용하는 가장 중요한 안전 패턴(safety pattern)이 이 환경에서는 불가능하기 때문입니다.

이 중 어느 것도 정확히 MCP의 결함은 아닙니다. 그것이 바로 "범용적(generic)"이라는 말의 의미입니다. API 브리지(API bridge)는 API가 라벨링한 것만을 제공할 수 있습니다. 그 라벨들을 가지고 무엇을 할 것인지에 대한 지식 — 즉, 어떤 구문이 실제인지, 문서가 잘못 설명한 열거형 값(enum values)은 무엇인지, 어떤 쓰기 순서(write orderings)가 실패하는지 — 에 대한 지식은 다른 어딘가에 존재해야 합니다.

대신 우리가 운영하는 것 — 그리고 병행하는 것

우리의 도구는 Claude 툴킷(toolkit)입니다. 위 목록을 다루는 12가지 기술(텍스트 모드, 계산 필드, 커스텀 폼, 비즈니스 규칙, Fusion 및 테스트 하네스, 보고서, 일괄 업데이트, 권한, 플랫폼 평가)로 구성되며, 검증된 Workfront 동작에 관한 약 96개의 지식 파일(knowledge files)을 기반으로 합니다. 이것은 다운로드할 수 있는 제품이 아닙니다. 이것은 이 실무진이 인도(delivery) 작업을 위해 구축한 툴링(tooling)이며, 아래의 수치들이 가능했던 방식입니다. "대신(Instead)"이라는 표현은 약간 불공평할 수도 있습니다. 이것은 MCP와 충돌하는 것이 없으며, 읽기 도구(read tools)를 활성화한 조직은 훌륭한 전송 계층(transport layer)을 갖게 되는 것이니까요. 차이점은 그 위에 무엇이 올라타느냐에 있습니다.

증거 A — 300개 필드의 폼

한 고객사 — 미국의 한 지역 은행 — 는 의도적으로 필수 입력 필드가 하나도 없는 접수 양식 (intake form)을 출시했습니다. 마찰 (friction)이 도입을 저해하므로, 요구 사항은 나중에 수집하겠다는 전략이었습니다. 몇 달 후, 그 "나중"이 찾아왔고, 300개가 넘는 필드 중 100개 이상의 필드를 필수 항목으로 전환해야 했습니다.

인터페이스를 통한 방식: 폼 빌더 (form builder)에서 각 필드를 찾아 열고, 체크박스를 선택하고, 저장합니다. 익숙해진 후에도 필드당 15초는 걸립니다. 100여 개의 필드를 처리한다면 동일한 클릭 패턴을 30분 동안 반복해야 하며, 그 과정 내내 오류율은 계속 상승합니다. 그 누구의 주의력도 80번째 필드까지 버텨낼 수 없습니다.

툴킷 (toolkit)을 통한 방식: 총 30초가 소요됩니다. API를 대상으로 검토된 변경 사항을 적용하며, 모든 필드가 누락 없이 반영됩니다.

증거 B — 안전 사다리

이 수치를 보고 들려오는 반응은 이렇습니다: AI가 운영 환경의 양식 (production form)에 직접 쓰게 한다고요? 옳은 질문입니다. 그 신뢰를 얻기 위한 절차는 다음과 같습니다.

툴킷은 먼저 테넌트 (tenant)에 사용 가능한 비운영 환경 (non-production environment)이 있는지 확인합니다. 프리뷰 (preview) 또는 샌드박스 (sandbox)가 존재한다면, 변경 사항은 그곳에서 먼저 실행되며, 운영 환경에 반영되기 전에 사람이 결과를 검토합니다. 샌드박스가 없다면, 툴킷은 운영 환경을 대상으로 드라이 런 (dry run)을 수행합니다. 즉, 정확히 무엇이 변경될지에 대한 전체 보고서를 생성하고, 명시적인 승인이 있을 때만 실행합니다. 또한 모든 운영 환경 쓰기 작업은 먼저 이전 상태 파일 (previous-state file)을 캡처하므로, 나중에 문제가 발생하더라도 복구를 위한 정확한 이전 구성이 디스크에 존재하게 됩니다.

스테이징 환경 (staged environment), 드라이 런 (dry run), 명시적 승인, 기록된 롤백 경로 (rollback path). AI가 잘못된 행동을 할 기회는 전혀 없습니다. 프로세스가 모든 기회마다 AI를 통제하기 때문입니다. 증거 A에서 보여준 30초라는 시간은 이 네 가지 단계 위에 구축된 결과입니다.

증거 C — 모든 환경을 동시에

증거 B의 사다리에는 MCP가 충족할 수 없는 전제 조건이 있습니다. 바로 툴링 (tooling)이 동일한 세션 내에서 샌드박스 (sandbox)와 운영 (production) 환경 모두에 도달해야 한다는 점입니다. 이 툴킷 (toolkit)은 우리가 자격 증명 (credentials)을 보유한 모든 환경, 즉 각 클라이언트의 운영 및 프리뷰 테넌트 (preview tenants)에 연결됩니다. 이때 클라이언트별 자격 증명 격리 (credential isolation)가 이루어지며, 어떤 키 (key)도 대화 내용에 포함되지 않습니다. 한 번에 하나의 연결만 허용하는 MCP의 모델은 '테스트 후 승격 (test-then-promote)' 패턴을 완전히 차단합니다. 단일 테넌트를 관리하는 1인 관리자에게는 이것이 이론적인 문제일지 모릅니다. 하지만 운영 환경에 적용하기 전 리허설이 필요한 변경 사항을 책임지는 사람에게 이것은 승패를 결정짓는 핵심 요소입니다.

지식 계층 (knowledge layer)이 필요한 이유

이 툴킷이 존재하는 이유는 기본 Claude가 Workfront 문제를 해결하는 과정을 지켜보며 느꼈던 불편함 때문입니다. 때때로 Claude는 API 상호작용, 텍스트 모드, 계산된 필드 (calculated fields)를 정확하게 처리했습니다. 하지만 신뢰하기에는 너무 자주 틀렸고, 그 실패 방식은 비용이 많이 들었습니다. 깔끔한 오류를 내는 것이 아니라, 세션이 반복될 때마다 확신에 찬 태도로 헛바퀴만 돌 뿐이었습니다.

해결책은 AI를 줄이는 것이 아니었습니다. Workfront의 REST API는 자기 기술적 (self-describing)입니다. 메타데이터 엔드포인트 (metadata endpoints)를 통해 모든 객체 유형, 모든 필드, 모든 열거형 (enum) 값, 사용 가능한 모든 액션 (action)을 나열할 수 있습니다. 따라서 툴킷의 기반은 Claude를 해당 엔드포인트로 안내하여, 학습 데이터 (training data)가 아닌 소스 (source)로부터 API 전체를 스스로 학습하게 만드는 것에서 시작되었습니다.

그 위에 메타데이터 엔드포인트(metadata endpoint)가 제공하지 못하는 부분이 자리 잡고 있습니다. 바로 라이브 테넌트(live tenants)를 대상으로 검증하고 날짜와 함께 기록된 '발견 사항(findings)'입니다. 이 분야의 한 가지 예로, 폼 업데이트 (form-update) API 호출 중 특정 클래스가 있는데, 각 행의 복합 ID (composite ID)를 포함할 경우 전체 쓰기 작업이 유효성 검사 오류 (validation error)로 실패하는 경우가 있습니다. 이는 Workfront가 API를 통해서는 읽을 수조차 없는 필드 스키마 (field schema)를 다시 검증하기 때문입니다. 해결 방법은 행의 키 (key)를 다른 방식으로 지정하고 ID를 생략하는 것입니다. 그 어디에도 이 내용에 대한 문서화 (documentation)는 되어 있지 않습니다. 한때 이 문제로 오후 시간을 통째로 허비한 적이 있었고, 이를 증명하는 요청 (request)과 함께 기록되었기에, 다시는 오후 시간을 허비하는 일은 없을 것입니다. 이를 96개의 파일로 곱해본다면, API 접근 권한만 가진 AI와 디버깅을 수행한 사람으로부터 경험을 빌려온 AI 사이의 차이가 무엇인지 알 수 있습니다.

이 모든 것이 대체할 수 없는 것

Workfront의 일부 기능은 API로 전혀 접근할 수 없습니다. 끊임없이 언급되는 레이아웃 템플릿 (Layout Templates)이 대표적인 예로, 이는 인터페이스 (interface)에서만 생성할 수 있으며 엔드포인트 (endpoint), 툴킷 (toolkit), 예외 상황 모두 존재하지 않습니다. AI 벤더의 슬라이드 덱 (slide deck)이 무엇을 암시하든 간에, 실제로 작동하는 Workfront 실무에는 여전히 인간 관리자 (human admin)가 필요합니다. 이 모든 도구에 대한 솔직한 설명은, 도구가 '판단력 (judgment)'을 삭제하는 것이 아니라 '30분 단위의 자잘한 작업들'을 삭제한다는 것입니다.

또한 모든 조직에 적합한 것도 아닙니다. 정책이나 컴플라이언스 (compliance) 문제로 인해 AI 도구를 운영 테넌트 (production tenant)에 연결하는 것이 불가능하다면, 그것은 정당한 답변이며 위의 계산법도 그에 반박하지 않습니다.

FAQ

Adobe Workfront를 위한 MCP 서버가 있나요?
네. Adobe는 사용자의 인스턴스를 Claude, ChatGPT, Copilot, Gemini를 포함한 AI 플랫폼에 연결하는 공식 Workfront MCP 서버를 제공합니다. 관리자는 두 가지 토글 (toggle)로 이를 제어합니다: 읽기 전용 도구 (read-only tools, 기본값 On) 및 쓰기 도구 (write tools, 기본값 Off). 현재는 AWS 호스팅 고객으로 제한됩니다.

Claude가 Adobe Workfront에 연결할 수 있나요?
네, 두 가지 방법이 있습니다. 프로젝트, 작업(tasks), 승인(approvals)에 대한 대화형 접근을 위해 Anthropic의 Workfront 커넥터(MCP 서버 기반 구축)를 사용하는 방법, 또는 이 메모에서 설명하는 작업 방식처럼 Workfront API와 직접 연동되는 Claude 측 스킬(skills)을 사용하는 방법입니다.

AI가 Workfront 운영(production) 환경에 데이터를 쓰는 것을 허용해도 안전한가요?
프로세스가 뒷받침될 때만 안전합니다. 저희의 방식은 다음과 같습니다: 샌드박스(sandbox) 환경이 존재할 경우 그곳에서 테스트하고, 없을 경우 운영 환경을 대상으로 드라이 런(dry-run)을 수행하며, 명시적인 인간의 승인이 있을 때만 실행하고, 수정된 모든 항목의 이전 상태를 캡처하여 복구할 수 있도록 합니다. 단계별 경로와 롤백(rollback) 기록이 없는 AI의 쓰기 작업은 워크플로(workflow)가 아니라 리스크입니다.

Workfront MCP가 텍스트 모드(text mode)나 Fusion을 지원하나요?
아니요. MCP의 도구는 객체 작업(projects, tasks, issues, approvals, Planning records) 및 데이터 쿼리(queries)를 다룹니다. 텍스트 모드 보고 구문(reporting syntax), 계산 필드(calculated-field) 작성, 커스텀 폼(custom-form) 구조, 비즈니스 규칙(business rules), 그리고 Workfront Fusion의 모든 기능은 범위 외(outside its scope)에 있습니다.

만약 귀하의 팀이 사용하는 300개 필드 규모의 폼이 현재 누군가의 리스트에 머물러 있다면, 30분간의 해체 분석(a 30-minute teardown)을 통해 그 비용이 얼마나 발생하는지 확인할 수 있습니다. 그리고 만약 귀하의 고유한 작업에 맞춰 이러한 스킬을 직접 구축하고 싶다면(귀하의 워크스페이스에서 실시간으로 구축하고 이후에는 귀하의 소유가 되는 방식), 스킬 세션(the Skill Session)이 그 해답입니다.