프롬프트 엔지니어링보다 중요한 작업 지시서 만들기

2026-08-27Views 10약 6분생성형 AI 활용

Summary

프롬프트보다 먼저 정해야 할 것

AI에게 일을 맡길 때 많은 사람이 먼저 '어떤 문장으로 물어볼까'를 고민한다. 물론 표현도 중요하다. 하지만 실제 제작에서는 멋진 문장보다 작업 조건이 더 중요하다. AI가 실패하는 이유는 대개 문장이 부족해서가 아니라, 목표와 제약, 입력 자료, 완료 기준이 빠져 있기 때문이다.

이 장에서 말하는 작업 지시서는 단순한 프롬프트가 아니다. AI가 어떤 프로젝트에서, 어떤 도구로, 어디까지 수정하고, 무엇을 건드리면 안 되며, 어떤 기준을 통과해야 완료인지 적은 작은 명세서다. 사람에게 일을 부탁할 때도 '상점 UI 좀 만들어 주세요'보다 '모바일 가로 화면 기준으로, 기존 버튼 컴포넌트를 사용해, 구매 확인 팝업까지 포함하고, 게임패드 포커스 순서를 유지해 주세요'가 훨씬 정확하다. AI도 다르지 않다.

작업 지시서는 특히 Figma, Unity, Unreal처럼 결과가 파일과 에디터 상태에 남는 도구에서 중요하다. 단발성 질문은 답변이 마음에 들지 않으면 버리면 되지만, 에디터 자동화는 잘못된 변경이 씬, 프리팹, 블루프린트, 에셋 참조를 망가뜨릴 수 있다. 그래서 AI에게 수정 권한을 줄수록 지시서는 더 구체적이어야 한다.

프롬프트 엔지니어링보다 중요한 작업 지시서 만들기 AI 생성 이미지

엔진 작업용 지시서의 기본 구조

좋은 작업 지시서는 길기만 한 문서가 아니다. 빠지면 안 되는 항목이 들어 있는 문서다. 다음 구조를 기본 템플릿으로 삼으면 Figma 화면 생성, Unity C# 구현, Unreal Blueprint 자동화에 모두 응용할 수 있다.

[역할]
당신은 이 프로젝트의 UI/게임플레이/엔진 자동화 보조자다.

[목표]
이번 작업에서 달성해야 할 결과를 한 문장으로 적는다.

[현재 상태]
이미 존재하는 파일, 씬, 프레임, 컴포넌트, 스크립트, 블루프린트 상태를 설명한다.

[입력 자료]
참고할 Figma 프레임, 디자인 토큰, 기획 문서, 기존 코드, 로그, 스크린샷을 적는다.

[사용할 도구]
Figma AI, Unity Assistant, Unity MCP, Unreal MCP, 코드 편집기 등 사용할 수 있는 도구를 제한한다.

[금지할 변경]
수정하면 안 되는 파일, 삭제하면 안 되는 오브젝트, 바꾸면 안 되는 네이밍과 API를 적는다.

[작업 절차]
먼저 계획을 제시하고, 승인 후 변경하며, 변경 후 요약과 테스트 결과를 보고하라고 지시한다.

[완료 기준]
어떤 화면, 기능, 테스트, 로그 상태를 만족해야 완료인지 적는다.

이 구조의 핵심은 AI가 추측해야 하는 부분을 줄이는 데 있다. 예를 들어 '인벤토리를 만들어 줘'라고 하면 AI는 UI 구조, 데이터 모델, 입력 방식, 아이템 정렬, 빈 슬롯 표시를 모두 추측한다. 반대로 '기존 ItemSlot 컴포넌트를 사용하고, 5열 그리드이며, 빈 슬롯은 disabled 상태로 표시하고, 클릭 시 ItemDetailPanel만 갱신한다'고 쓰면 결과가 훨씬 검토하기 쉬워진다.

여기서 중요한 점은 항목을 모두 길게 채우는 것이 아니다. 모르는 내용은 모른다고 적고, 확실한 제약은 분명하게 적는 것이다. 예를 들어 아직 디자인 토큰이 정해지지 않았다면 '기존 토큰을 우선 검색하고, 없으면 새 토큰을 만들기 전에 후보를 보고하라'고 지시할 수 있다. 이렇게 쓰면 AI가 빈칸을 마음대로 채우는 일을 줄일 수 있다.

Figma, Unity, Unreal 지시서는 서로 달라야 한다

AI에게 주는 지시서는 도구의 성격에 맞아야 한다. Figma는 화면 구조와 시각적 규칙이 중요하다. Unity C#은 코드 구조와 런타임 동작이 중요하다. Unreal Blueprint 자동화는 에디터 안의 에셋, 그래프, 컴파일 결과가 중요하다. 같은 '상점 화면 만들기'라도 지시서의 초점은 달라져야 한다.

Figma 화면 생성용 지시서

Figma에서는 AI가 화면을 그럴듯하게 만드는 것보다, 나중에 개발자가 읽을 수 있는 구조로 만드는 것이 중요하다. 그래서 지시서에는 플랫폼, 화면 목적, 핵심 정보, 컴포넌트 상태, 디자인 토큰, 레이어 정리 기준이 들어가야 한다.

역할: 게임 UI 디자이너로 작업한다.
목표: 모바일 가로 화면용 상점 메인 화면 초안을 만든다.
현재 상태: 프로젝트에는 Button/Primary, ItemCard, CurrencyBadge 컴포넌트가 있다.
입력 자료: 색상은 color.action.primary, color.surface.panel, color.text.default 토큰을 사용한다.
화면 구성: 상단에는 재화 영역, 중앙에는 4개 상품 카드, 하단에는 구매 버튼과 닫기 버튼을 배치한다.
제약: 새 버튼 스타일을 만들지 말고 기존 버튼 컴포넌트 변형을 사용한다. 텍스트는 한국어 기준으로 넣되 긴 문구에도 깨지지 않게 여백을 둔다.
완료 기준: 주요 레이어 이름은 역할 기반으로 정리하고, 상품 카드에는 default, selected, locked 상태를 구분한다.

이 지시서에서는 코드가 아니라 화면의 의미와 구조를 강조한다. AI가 만든 결과를 그대로 쓰기보다, 기존 컴포넌트와 토큰에 맞게 다시 정리할 수 있도록 기준을 제공하는 것이 목적이다. 화면을 빠르게 뽑는 것보다 나중에 구현으로 이어질 수 있는 구조를 남기는 데 초점을 둔다.

Unity C# 구현용 지시서

Unity에서는 시각적 결과보다 실행 흐름이 중요하다. 어떤 씬에서, 어떤 스크립트를 만들고, 어떤 컴포넌트와 연결하며, Play Mode에서 무엇을 확인할지 적어야 한다.

역할: Unity C# 개발 보조자로 작업한다.
목표: 상점 UI의 상품 선택과 구매 버튼 활성화 로직을 구현한다.
현재 상태: ShopPanel 프리팹에는 ItemSlot 4개, BuyButton, CurrencyText가 있다. ItemSlot은 OnClicked 이벤트를 가지고 있다.
수정 대상: Assets/Scripts/UI/ShopPanelController.cs 파일만 수정한다.
금지할 변경: 기존 ItemSlot.cs의 public API는 변경하지 않는다. 프리팹 이름과 계층 구조를 바꾸지 않는다.
구현 조건: 선택된 상품이 없으면 BuyButton은 비활성화한다. 선택한 상품 가격이 보유 재화보다 높으면 버튼은 disabled 상태가 된다.
작업 절차: 먼저 구현 계획을 제시한다. 승인 후 코드를 수정한다. 변경 후 수정한 메서드와 이유를 요약한다.
검증 기준: Play Mode에서 상품 선택, 재화 부족, 구매 가능 상태가 각각 올바르게 표시되어야 한다. 콘솔에 오류가 없어야 한다.

여기서 중요한 부분은 '수정 대상'과 '금지할 변경'이다. AI가 문제를 해결하려고 기존 API를 마음대로 바꾸면 당장은 컴파일되어도 다른 코드가 깨질 수 있다. 작은 기능일수록 수정 범위를 좁혀야 한다. 필요하다면 '새 파일을 만들지 말 것', 'SerializeField 이름을 바꾸지 말 것', '기존 저장 데이터 형식은 변경하지 말 것'처럼 프로젝트에 맞는 금지 조건을 추가한다.

Unreal Blueprint 자동화 지시서

Unreal에서는 Blueprint 그래프, Widget Blueprint, 액터 배치, 컴파일 상태가 작업의 중심이 된다. AI에게 MCP 기반 자동화를 맡길 때는 어떤 에셋을 열고, 어떤 노드를 추가하며, 컴파일과 Play In Editor, 즉 PIE 확인까지 어떤 순서로 할지 명확히 적어야 한다.

역할: Unreal Editor 자동화 보조자로 작업한다.
목표: WBP_ShopItem 위젯에 선택 상태 표시 로직을 추가한다.
현재 상태: WBP_ShopItem에는 ItemNameText, PriceText, SelectedBorder가 있다. SelectedBorder는 기본적으로 숨김 상태다.
수정 대상: WBP_ShopItem Blueprint만 수정한다.
금지할 변경: 다른 Widget Blueprint와 DataTable 구조는 변경하지 않는다. 기존 변수 이름은 바꾸지 않는다.
작업 조건: bIsSelected 변수를 기준으로 SelectedBorder의 Visibility를 변경한다. 외부에서 호출할 수 있는 SetSelected 함수를 만든다.
작업 절차: 먼저 현재 위젯 구조를 읽고 계획을 보고한다. 승인 후 함수와 노드를 추가한다. 컴파일 결과와 오류 로그를 보고한다.
검증 기준: 에디터에서 컴파일 오류가 없어야 한다. PIE에서 선택된 상품만 테두리가 보이는지 확인한다.

Unreal 지시서에서는 '컴파일'과 'PIE 확인'을 완료 기준에 포함하는 것이 좋다. Blueprint는 눈으로 보기에는 그럴듯해도 노드 연결이나 타입이 맞지 않으면 실행에서 실패할 수 있다. 또한 Blueprint 에셋은 참조 관계가 많기 때문에, 다른 위젯이나 DataTable까지 함께 바꾸지 않도록 수정 범위를 좁혀 두는 편이 안전하다.

파일 수정 권한을 줄 때의 안전한 순서

AI가 답변만 하는 단계와 파일을 수정하는 단계는 위험도가 다르다. 파일 수정이 포함되면 다음 네 단계를 지시서에 넣는 것이 좋다.

첫째, 먼저 계획을 제시하게 한다. AI가 어떤 파일을 읽고, 어떤 파일을 수정하며, 어떤 테스트를 할지 설명하게 한다. 이 단계에서 범위가 너무 넓으면 작업을 나누어야 한다.

둘째, 변경 전 확인을 받게 한다. '계획을 보고한 뒤 승인 전에는 파일을 수정하지 말라'는 문장을 넣는다. 특히 MCP나 에디터 자동화에서는 이 규칙이 중요하다.

셋째, 변경 후 diff를 요약하게 한다. diff는 변경 전후 차이를 뜻한다. AI에게 전체 코드를 다시 붙여 넣게 하기보다, 어떤 파일에서 어떤 메서드와 설정이 바뀌었는지 요약하게 하면 리뷰가 쉬워진다.

넷째, 테스트를 실행하고 결과를 보고하게 한다. Unity라면 컴파일 오류, 콘솔 로그, Play Mode 확인을 본다. Unreal이라면 Blueprint 컴파일, PIE 실행, Output Log를 확인한다. Figma라면 컴포넌트 연결, 상태, 오토 레이아웃, Dev Mode 정보가 맞는지 확인한다.

다음 문장을 지시서에 반복해서 넣어 두면 좋다.

파일을 수정하기 전에 먼저 작업 계획을 제시하라.
내 승인이 있기 전에는 파일을 생성, 삭제, 수정하지 마라.
변경 후에는 수정한 파일 목록, 핵심 변경점, 의도하지 않은 영향 가능성, 실행한 테스트와 결과를 요약하라.
테스트하지 못한 항목이 있으면 테스트하지 못했다고 명시하라.

마지막 문장이 중요하다. AI는 때때로 실제로 확인하지 않은 결과를 확인한 것처럼 말할 수 있다. 그래서 '모르면 모른다고 말하기', '테스트하지 못한 것은 구분하기'를 완료 보고 형식에 포함해야 한다. 이렇게 해야 제작자가 AI의 결과물을 믿어도 되는 부분과 직접 확인해야 하는 부분을 구분할 수 있다.

실패한 결과를 다시 입력하는 방법

AI 작업에서 첫 결과가 실패하는 것은 흔하다. 중요한 것은 실패한 결과를 버리지 않고 다음 입력으로 바꾸는 것이다. 좋은 반복 대화는 '다시 해 줘'가 아니라 '무엇이 어떻게 달랐는지'를 알려 주는 방식이다.

실패를 재입력할 때는 네 가지를 함께 제공한다.

기대 결과: 원래 의도한 화면이나 동작
실제 결과: AI가 만든 결과 또는 실행된 상태
증거 자료: 로그, 스크린샷, 에러 메시지, diff, 재현 단계
수정 범위: 이번에 고쳐도 되는 파일과 건드리면 안 되는 파일

예를 들어 Unity에서 버튼이 눌리지 않는다면 다음처럼 말할 수 있다.

기대 결과: ShopPanel에서 ItemSlot을 클릭하면 BuyButton이 활성화되어야 한다.
실제 결과: 클릭해도 BuyButton 상태가 바뀌지 않는다.
증거: 콘솔 오류는 없지만 ShopPanelController의 OnItemSelected 로그가 출력되지 않는다.
현재 확인한 내용: ItemSlot 오브젝트에는 Button 컴포넌트가 있고, Inspector의 OnClick 이벤트는 비어 있다.
수정 범위: ShopPanelController.cs와 ShopPanel 프리팹 연결만 확인하라. ItemSlot.cs의 public API는 바꾸지 마라.
요청: 원인을 3가지 이하로 추정하고, 먼저 확인할 순서와 필요한 수정 계획을 제시하라.

이런 입력은 AI가 문제를 좁히는 데 도움이 된다. '안 돼'라고만 말하면 AI는 코드를 크게 다시 만들 가능성이 높다. 반대로 로그와 실제 결과를 주면 연결 누락, 이벤트 바인딩 실패, 상태 갱신 순서 문제처럼 원인을 단계적으로 볼 수 있다.

Unreal에서도 같은 방식이 통한다. Blueprint 컴파일 오류가 있다면 오류 메시지의 노드 이름, 변수 타입, 발생한 Blueprint 이름을 함께 제공한다. Figma에서는 스크린샷과 함께 어떤 레이어가 오토 레이아웃에서 깨졌는지, 어떤 컴포넌트 상태가 누락되었는지 적는다. 핵심은 AI에게 다시 큰 자유를 주는 것이 아니라, 실패한 지점을 중심으로 수정 범위를 더 좁혀 주는 것이다.

작업 지시서를 팀 자산으로 남기기

좋은 지시서는 한 번 쓰고 버릴 문장이 아니다. 팀의 제작 방식이 담긴 자산이다. 자주 반복하는 작업은 템플릿으로 저장해 두는 것이 좋다. 예를 들어 다음과 같은 파일을 프로젝트에 둘 수 있다.

AI_Briefs/Figma_UI_Generation.md
AI_Briefs/Unity_CSharp_Task.md
AI_Briefs/Unity_MCP_Editor_Change.md
AI_Briefs/Unreal_Blueprint_Task.md
AI_Briefs/Bug_Reproduction_Report.md

이 문서에는 팀의 네이밍 규칙, 금지된 변경, 테스트 기준, 승인 절차를 넣는다. 그러면 새 팀원이 와도 AI를 어떻게 써야 하는지 빠르게 이해할 수 있다. 또한 같은 실수를 줄일 수 있다. 프롬프트를 개인의 요령으로 남기지 않고, 팀의 작업 규칙으로 바꾸는 것이다.

작업 지시서의 목표는 AI를 더 자유롭게 만드는 것이 아니다. 오히려 안전하게 제한하는 것이다. 목표가 분명하고, 입력 자료가 충분하며, 변경 범위가 좁고, 검증 기준이 명확할수록 AI는 더 유용한 결과를 낸다. 제작자는 그 결과를 검토하고, 필요한 부분을 고치고, 다음 반복에 반영한다. 이 루프가 자리 잡으면 AI는 단발성 답변 도구가 아니라 프로젝트 흐름 안에서 반복 작업을 줄이는 협업 도구가 된다.

책 목록

Figma AI와 Unity·Unreal AI 워크플로

전체 목차 보기