환경 준비가 먼저인 이유
AI 제작 워크플로는 프롬프트보다 환경 설정에서 먼저 막히는 경우가 많다. AI가 아무리 좋은 답을 내도 파일을 읽지 못하거나, 에디터와 연결되지 않거나, 권한이 부족하면 실무 작업으로 이어지지 않는다. 반대로 권한을 너무 넓게 열어 두면 API 키, 상용 에셋, 내부 기획 문서가 외부 도구에 노출될 수 있다.
따라서 이 장의 목표는 "AI 기능을 켠다"가 아니다. Figma, Unity, Unreal에서 AI가 접근해도 되는 범위를 정하고, 같은 팀원이 같은 방식으로 재현할 수 있는 작업 환경을 만드는 것이다. 실습용 프로젝트는 가능하면 실제 상용 프로젝트와 분리한다. 저장소도 별도로 만들고, 더미 데이터와 테스트용 에셋을 사용한다. 처음부터 운영 프로젝트에 AI 클라이언트를 연결하지 않는 것이 좋다.
AI 생성 이미지
Figma: 디자인 파일과 개발용 정보를 구분하기
Figma에서 먼저 구분해야 할 것은 Figma Design과 Dev Mode다. Figma Design은 화면을 만들고 수정하는 디자인 작업 공간이다. 프레임, 컴포넌트, 오토 레이아웃, 변수, 스타일을 편집한다. 반면 Dev Mode는 개발자가 디자인을 구현하기 위해 필요한 정보를 확인하는 공간이다. 레이어 구조, 치수, 컴포넌트 속성, 코드 스니펫, 변경 비교, 개발 상태, 외부 개발 리소스 연결 등을 확인할 수 있다1.
AI를 디자인 초안 생성에 사용할 때는 Figma Design의 구조가 중요하다. 반대로 AI에게 "이 화면을 Unity UI로 옮기기 위한 구조를 설명해 줘"라고 요청할 때는 Dev Mode의 정보가 더 중요하다. Dev Mode는 사람이 디자인을 구현 가능한 단위로 읽는 공간이며, AI에게도 같은 역할을 한다. 즉, AI가 디자인을 잘 이해하게 하려면 예쁜 화면보다 정리된 레이어명, 컴포넌트명, 변수명, 상태 정보가 필요하다.
팀 파일 접근 권한도 확인해야 한다. AI 기능이나 플러그인은 사용자의 계정 권한을 따라 파일을 읽는 경우가 많다. 사용자가 특정 팀 파일에 접근할 수 없다면 AI도 그 파일을 제대로 읽지 못한다. 반대로 사용자가 접근 가능한 파일이 너무 많다면 AI 도구가 예상보다 넓은 범위의 문맥을 다룰 수 있다. 실습 전에는 다음을 확인한다.
실습 파일이 개인 Draft가 아니라 팀이 합의한 위치에 있는가
편집자, 보기 전용, Dev Mode 접근 권한이 역할에 맞게 나뉘어 있는가
AI 플러그인이나 Dev Mode 플러그인이 조직에서 허용되어 있는가
코드 스니펫 기본 언어와 단위가 팀 개발 환경에 맞는가
자동 실행 플러그인이 있다면 어떤 데이터를 읽는지 확인했는가
조직 관리자는 Dev Mode 플러그인을 고정하거나, 기본 코드 언어를 지정하거나, 특정 플러그인을 파일 열기 시 자동 실행하도록 설정할 수 있다2. 이 설정은 작은 차이처럼 보이지만 팀의 AI 핸드오프 품질에 영향을 준다. 예를 들어 웹 중심 스니펫이 기본값인 상태에서 Unity UI 구현을 요청하면, AI는 엔진에 맞지 않는 구조를 제안할 가능성이 높다.
Unity에서 Figma 파일을 직접 참조하려면 별도의 접근 토큰이 필요할 수 있다. Unity Assistant의 Figma UI 생성 흐름에서는 Figma 개인 액세스 토큰을 만들고, file_content:read 권한을 부여한 뒤 Unity Editor의 AI 설정에 저장한다3. 이 권한은 말 그대로 파일 내용을 읽게 해 주는 권한이다. 토큰은 비밀번호처럼 다뤄야 하며, 저장소에 커밋하지 않는다. 만료 기간을 짧게 잡고, 실습이 끝나면 폐기하는 습관을 들인다.
Unity 6: AI 기능이 작동하기 위한 기본 조건
Unity에서 AI를 사용하려면 먼저 에디터 버전과 패키지를 확인한다. Unity AI 기능은 Unity 6.0 이상을 전제로 하며, 프로젝트에 AI 관련 패키지가 설치되어 있어야 한다. 또한 로컬 프로젝트가 Unity Cloud 프로젝트와 연결되어 있어야 하고, 계정의 AI 사용 조건이나 구독 상태도 확인해야 한다4.
여기서 용어를 정리하자.
Unity AI: Unity Editor 안에서 프로젝트 문맥을 활용해 질문 답변, 작업 제안, 일부 에디터 작업을 돕는 AI 기능의 큰 범주다.
Agentic Assistant: 단순히 답을 말하는 수준을 넘어, 프로젝트 상태를 보고 여러 단계의 작업을 수행하려는 에이전트형 도우미로 이해하면 된다.
AI Gateway: Unity 안에서 승인된 외부 AI 도구나 모델을 연결하는 통로다. 팀이 이미 사용하는 AI 서비스를 Unity 작업 흐름에 붙일 때 중요하다.
Unity MCP Server: Cursor, Claude Code, Windsurf 같은 MCP 호환 클라이언트가 Unity Editor의 도구를 호출할 수 있게 해 주는 연결 계층이다.
MCP는 AI가 에디터를 직접 마음대로 조작하게 하는 기능이 아니다. 정해진 도구 목록을 통해 씬 계층, GameObject, 컴포넌트, 콘솔 로그, 빌드 설정 같은 정보를 읽거나 일부 작업을 수행하게 하는 방식이다. Unity MCP는 Unity 6 이상, AI Assistant 패키지, MCP 호환 클라이언트를 전제로 한다. 설정 위치는 Edit > Project Settings > AI > Unity MCP Server이며, 이곳에서 Unity Bridge가 실행 중인지 확인한다5.
Unity MCP 연결은 보통 다음 순서로 점검한다.
Unity 6 프로젝트를 연다.
AI Assistant 패키지가 설치되어 있는지 확인한다.
프로젝트가 Unity Cloud와 연결되어 있는지 확인한다.
Project Settings > AI > Unity MCP Server에서 Unity Bridge가Running상태인지 본다.사용하는 클라이언트가 Claude Code, Cursor, Windsurf, Claude Desktop 등 MCP를 지원하는지 확인한다.
Integrations 설정에서 자동 구성을 사용하거나, 수동으로 Unity relay 실행 파일을 MCP 서버로 등록한다.
처음 연결되는 클라이언트는 Unity 설정 화면에서 승인한다.
클라이언트에서 "Unity 콘솔 경고를 읽고 요약해 줘"처럼 읽기 중심 명령으로 테스트한다.
처음부터 "씬을 전부 정리해 줘"라고 지시하지 않는다. 먼저 읽기 작업으로 연결을 검증하고, 다음에 작은 쓰기 작업을 시도한다. 예를 들어 빈 GameObject 하나를 만들고 이름을 바꾸는 정도가 적당하다. 실패하면 프롬프트를 고치기 전에 버전, 패키지, Bridge 상태, 클라이언트 설정 파일, 프로젝트 경로를 먼저 확인한다.
Unreal: 공식 MCP와 브리지 방식 이해하기
Unreal Engine에서도 MCP 연결은 "AI 클라이언트가 에디터 기능을 도구처럼 호출한다"는 점에서 Unity와 비슷하다. 다만 구현 방식은 다를 수 있다.
공식 Unreal MCP는 Unreal Editor 프로세스 안에 MCP 서버를 포함하는 구조다. MCP 호환 클라이언트는 로컬 HTTP 연결로 에디터에 접속한다. 기본 주소는 http://127.0.0.1:8000/mcp이며, 기본적으로 같은 컴퓨터에서 들어오는 연결만 받도록 설계되어 있다. 인증 계층이 없고 원격 노출을 전제로 하지 않으므로, 포트를 외부 네트워크에 열어서는 안 된다6.
공식 흐름은 개념적으로 다음과 같다.
Unreal Editor에서 Unreal MCP 플러그인을 활성화한다.
Editor Preferences의 Model Context Protocol 설정에서 자동 시작 여부와 포트를 확인한다.
필요하면 콘솔 명령으로 서버를 시작한다.
Claude Code, Cursor, MCP Inspector 같은 클라이언트 설정 파일을 생성한다.
AI 클라이언트를 프로젝트 루트에서 실행한다.
액터 생성, 조명 설정, 머티리얼 인스턴스 생성, 자동화 테스트 실행 같은 도구 호출을 작은 범위로 검증한다.
책의 실습에서는 공식 플러그인 방식과 함께 브리지 방식도 개념적으로 다룬다. 브리지 방식은 보통 세 부분으로 나뉜다. 첫째, Unreal Editor 안에서 동작하는 C++ 플러그인이 있다. 둘째, 로컬 컴퓨터에서 Node.js 또는 TypeScript 기반 MCP 서버가 실행된다. 셋째, Claude나 Cursor 같은 MCP 클라이언트가 이 서버에 연결한다. 일부 구현에서는 로컬 MCP 서버가 C++ 브리지 플러그인과 WebSocket, JSON-RPC 같은 방식으로 통신하고, 프로젝트 파일 일부를 디스크에서 직접 읽기도 한다7.
이 구조의 장점은 확장성이다. 팀 고유의 액터 배치 규칙, 네이밍 규칙, 테스트 실행 명령을 MCP 도구로 만들 수 있다. 단점은 책임 범위가 넓어진다는 점이다. 공식 플러그인보다 설정 요소가 많고, C++ 플러그인, Node.js 런타임, 포트, 클라이언트 설정, 프로젝트 파일 접근 권한을 모두 관리해야 한다. 따라서 초보자는 먼저 공식 MCP 또는 읽기 전용 도구로 연결을 검증한 뒤, 필요한 경우 브리지 방식으로 확장하는 편이 안전하다.
AI 클라이언트 준비: Claude, Cursor, 그리고 로컬 설정
AI 클라이언트는 모델을 호출하는 앱인 동시에 프로젝트 도구에 연결되는 실행 환경이다. Cursor는 코드 편집기 안에서 작업하기 좋고, Claude Code나 Claude Desktop은 대화형 작업 지시와 MCP 도구 호출에 적합하다. 어떤 도구를 쓰든 공통 원칙은 같다.
첫째, 프로젝트 루트에서 실행한다. MCP 설정 파일이 프로젝트 루트에 생성되는 경우가 많고, 상대 경로도 이 위치를 기준으로 해석된다. 둘째, 클라이언트가 어떤 MCP 서버를 실행하는지 확인한다. Unity는 relay 실행 파일을 --mcp 인자로 실행할 수 있고, Unreal 공식 MCP는 로컬 HTTP 주소에 연결할 수 있다. 셋째, 같은 포트를 여러 서버가 동시에 쓰지 않는지 확인한다.
연결 오류가 날 때는 프롬프트를 바꾸지 말고 아래 순서로 본다.
에디터가 실제로 실행 중인가
프로젝트가 올바른 경로에서 열려 있는가
MCP 서버가 시작되었는가
포트가 충돌하지 않는가
클라이언트 설정 파일이 현재 프로젝트를 가리키는가
첫 연결 승인 절차를 놓치지 않았는가
회사 방화벽이나 보안 프로그램이 로컬 연결을 막지 않는가
프로젝트를 열기 전 보안 체크리스트
AI에게 프로젝트 파일을 열어 주기 전에는 다음 항목을 확인한다. 이 체크리스트는 팀 실습, 사내 프로젝트, 외주 협업 모두에 적용할 수 있다.
계정과 권한
실습용 Figma 파일, Unity 프로젝트, Unreal 프로젝트가 운영 프로젝트와 분리되어 있는가
AI 클라이언트에 로그인한 계정이 개인 계정인지 회사 승인 계정인지 확인했는가
Figma 팀 파일 접근 권한이 필요한 범위로 제한되어 있는가
Unity Cloud 프로젝트 연결 대상이 올바른가
Unreal 프로젝트 루트에 민감한 문서가 함께 들어 있지 않은가
API 키와 토큰
Figma 개인 액세스 토큰을 저장소에 커밋하지 않았는가
OpenAI, Anthropic, Google, 기타 모델 API 키가
.env나 비밀 저장소로 관리되는가만료 기간이 없는 장기 토큰을 실습용으로 사용하지 않는가
화면 공유나 녹화 중 토큰 값이 노출되지 않는가
사용하지 않는 토큰을 폐기했는가
로컬 서버와 포트
MCP 서버가
127.0.0.1또는 localhost에만 바인딩되어 있는가Unreal MCP 같은 인증 없는 로컬 서버를 외부 네트워크에 노출하지 않았는가
기본 포트가 다른 개발 서버와 충돌하지 않는가
포트 변경 시 클라이언트 설정도 함께 수정했는가
방화벽 예외를 만들었다면 범위를 최소화했는가
저장소와 파일 접근
AI 클라이언트가 전체 홈 디렉터리가 아니라 프로젝트 폴더만 열고 있는가
.gitignore에 빌드 산출물, 캐시, 비밀 파일이 포함되어 있는가상용 에셋 원본, 라이선스 문서, 계약서가 AI 문맥에 들어가지 않도록 분리했는가
생성된 코드와 에셋을 사람이 리뷰하는 절차가 있는가
AI가 수정한 파일을 커밋하기 전에 diff를 확인하는가
상용 에셋과 라이선스
Asset Store, Fab, Marketplace, 폰트, 사운드 라이브러리의 사용 조건을 확인했는가
AI에게 상용 에셋 원본을 재가공하거나 유사 에셋을 대량 생성하도록 요청하지 않는가
외부 공유가 금지된 파일을 클라우드 AI에 업로드하지 않는가
결과물을 배포하기 전 출처와 라이선스 기록을 남겼는가
실습용 표준 환경 만들기
처음 실습 환경은 단순해야 한다. Figma에는 로그인 화면, 버튼 컴포넌트, 색상 변수 정도만 있는 파일을 만든다. Unity에는 빈 씬과 기본 UI Canvas를 둔다. Unreal에는 빈 레벨과 테스트용 액터 하나만 둔다. AI 클라이언트는 하나만 연결한다. 여러 도구를 동시에 켜면 문제가 생겼을 때 원인을 찾기 어렵다.
권장 순서는 다음과 같다.
Figma에서 실습용 팀 파일을 만들고 권한을 정리한다.
Dev Mode에서 레이어명, 컴포넌트명, 변수명이 읽기 쉬운지 확인한다.
Unity 6 프로젝트를 만들고 AI Assistant와 MCP 연결을 읽기 작업으로 검증한다.
Unreal 프로젝트에서 MCP 서버를 로컬로만 실행하고 MCP Inspector 또는 선택한 클라이언트로 연결을 확인한다.
API 키와 토큰을 별도 파일에 두고 저장소에는 올리지 않는다.
AI가 만든 변경 사항은 항상 diff, 실행 결과, 화면 결과로 검증한다.
환경 준비는 한 번만 하는 일이 아니다. 프로젝트가 커질수록 권한, 포트, 토큰, 플러그인, 클라이언트 설정이 계속 바뀐다. 그래서 좋은 팀은 "프롬프트 모음"보다 "환경 재현 문서"를 먼저 만든다. 어떤 버전의 에디터를 쓰는지, 어떤 MCP 서버를 켜는지, 어떤 권한으로 파일을 읽는지, 실패하면 어디를 확인하는지 문서화한다. 이 기반이 있어야 다음 장에서 Figma AI로 만든 아이디어를 실제 화면과 엔진 구현으로 안정적으로 이어 갈 수 있다.
참고
2Figma Dev Mode organization settings
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.