[유니티] 난이도에 따른 배경 만들기

개발/유니티

[유니티] 난이도에 따른 배경 만들기

kimchangmin02 2025. 8. 14. 22:20

ArgumentException: An item with the same key has already been added. Key: Enemy 20
System.Collections.Generic.Dictionary2[TKey,TValue].TryInsert (TKey key, TValue value, System.Collections.Generic.InsertionBehavior behavior) (at <356d430fdcb04bbf8dc54776e1d3627f>:0) System.Collections.Generic.Dictionary2[TKey,TValue].Add (TKey key, TValue value) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
ObjectPooler.Start () (at Assets/Scripts/ObjectPooler.cs:53)
이거 무슨 오류인거지

프리팹 이름 같으면 그런가
근데 다른 폴더에 있어도 문제 생기는가

네, ArgumentException: An item with the same key has already been added. Key: Enemy 20 오류는 C#의 Dictionary 자료 구조에 동일한 키 값을 두 번 추가하려고 할 때 발생하는 문제입니다. 오류 로그를 보면 ObjectPooler.cs 스크립트의 Start() 함수 53번째 줄에서 이 문제가 발생하고 있습니다.

오류의 원인

사용자께서 추측하신 대로, 프리팹의 이름이 같아서 발생했을 가능성이 매우 높습니다. 일반적으로 오브젝트 풀러(Object Pooler)는 프리팹의 이름을 키(Key)로 사용하여 딕셔너리(Dictionary)에 등록하고 관리합니다.

다른 폴더에 있어도 문제가 생기는 이유

Unity에서 gameObject.name 속성은 파일의 경로와 상관없이 오브젝트 자체의 이름만을 가져옵니다. 따라서 서로 다른 폴더에 "Enemy 20"이라는 이름의 프리팹이 두 개 이상 존재하고, 코드에서 이 프리팹들을 이름(prefab.name)을 키로 사용하여 딕셔너리에 추가하려고 하면, 첫 번째 "Enemy 20"은 정상적으로 등록되지만 두 번째 "Enemy 20"을 등록할 때 이미 키가 존재하므로 ArgumentException 오류가 발생하는 것입니다.

해결 방안

프리팹 이름 변경: 가장 간단한 해결책은 중복된 이름의 프리팹 중 하나의 이름을 다른 것으로 바꾸는 것입니다. 예를 들어, "Enemy 20_Variant" 와 같이 고유한 이름으로 수정하면 키 충돌을 피할 수 있습니다.
고유한 키 생성: 프리팹의 경로를 포함한 전체 경로를 키로 사용하거나, 각 프리팹에 고유 ID를 부여하는 별도의 스크립트를 작성하여 그 ID를 키로 사용하는 방법도 있습니다. 하지만 일반적으로는 프리팹의 이름을 고유하게 관리하는 것이 더 직관적이고 편리합니다.

결론적으로, ObjectPooler가 프리팹 이름을 키로 사용하고 있다면, 다른 폴더에 있더라도 이름이 같은 프리팹이 존재할 경우 이와 같은 오류가 발생할 수 있습니다. 프로젝트 내의 모든 프리팹 이름이 고유한지 확인해 보시는 것을 권장합니다.

근데 배경을 넣고싶은데 왜 안보이는거지?
지금 create empty>컴포넌트에 이미지 추가햇는데

근데 지금 배경이 ui가 아니라, create empty로 생성햇는데 그러면 안되는건가

결론부터 말씀드리면, Image 컴포넌트를 사용하셨다면 해당 오브젝트는 반드시 Canvas의 자식으로 들어가야 합니다.

두 가지 배경 구현 방식

1. UI를 이용한 배경 (현재 시도하신 방법)

이 방법은 배경이 항상 화면에 고정되어 있고, 다른 UI 요소(점수, 버튼 등)들의 뒤에 깔리는 화면을 만들 때 사용합니다.

컴포넌트: Image 컴포넌트를 사용합니다.
위치/크기: Rect Transform으로 조절합니다.
필수 조건: 반드시 Canvas 오브젝트의 자식(하위)으로 존재해야 합니다. Canvas가 UI를 화면에 그리는 총괄 역할을 하기 때문입니다.

현재 문제의 결정적인 원인:
스크린샷의 Hierarchy 뷰를 보면 backGround1 오브젝트가 Canvas의 자식이 아니라 밖에 독립적으로 존재합니다. Image 컴포넌트는 Canvas 시스템의 일부로서만 렌더링될 수 있기 때문에, 지금 상태에서는 절대 화면에 나타나지 않습니다.

해결 방법:

Hierarchy 뷰에서 backGround1 오브젝트를 마우스로 드래그하여 Canvas 오브젝트 위로 가져가 자식으로 만들어 주세요.
Canvas의 자식이 된 backGround1이 다른 UI 요소들(예: New Text)보다 위에 오도록 순서를 조정하여 가장 배경에 깔리게 합니다.
이전 답변에서 설명드린 대로, backGround1의 Rect Transform에서 **앵커 프리셋(Anchor Presets)**을 이용해 화면에 가득 차도록 설정합니다. (Alt + Shift + 우측 하단 Stretch)

2. 2D 스프라이트를 이용한 배경

이 방법은 배경이 게임 월드의 일부일 때 사용합니다. 예를 들어, 플레이어가 배경 위를 걸어 다니는 횡스크롤 게임 같은 경우입니다.

컴포넌트: Sprite Renderer 컴포넌트를 사용합니다. (Image가 아닙니다.)
위치/크기: Transform으로 조절합니다.
렌더링 순서: Sprite Renderer 컴포넌트의 Sorting Layer와 Order in Layer 속성으로 다른 스프라이트(플레이어, 적 등)와의 앞뒤 관계를 정합니다.

만약 이 방식으로 배경을 만들고 싶으셨다면, backGround1에서 Image와 Canvas Renderer 컴포넌트를 제거하고, Sprite Renderer 컴포넌트를 추가한 후 Sprite 슬롯에 배경 이미지를 넣어야 합니다.

요약:
사용자께서는 UI 배경을 만들려고 하셨지만, 가장 중요한 "Canvas의 자식으로 만들기" 과정을 빠뜨리셨습니다. 지금 바로 backGround1을 Canvas 안으로 옮기시면 문제가 해결될 것입니다.

1. Create Empty와 Canvas 자식의 결정적인 차이

이 둘의 차이는 어떤 좌표계와 렌더링 시스템을 사용하느냐에 있습니다.

Create Empty로 만든 일반 오브젝트:
- **월드 공간(World Space)**에 존재합니다. 우리가 흔히 보는 3D 공간, 즉 게임 세상 그 자체에 놓입니다.
- 화면에 보이려면 Sprite Renderer(2D)나 Mesh Renderer(3D) 같은 '렌더러' 컴포넌트가 필요합니다.
- 카메라에 찍혀야만 게임 화면에 보입니다. 카메라 시야 밖에 있거나 다른 물체에 가려지면 보이지 않습니다.
- 위치와 크기는 Transform 컴포넌트로 조절합니다.
Canvas의 자식으로 만든 UI 오브젝트:
- **스크린 공간(Screen Space)**에 존재합니다. 이는 게임 세상(월드)과는 별개로, 우리 모니터 화면 자체에 그리는 개념입니다.
- 화면에 보이려면 Image, Text, RawImage 등 '그래픽' 컴포넌트가 필요하며, 이들은 반드시 Canvas Renderer와 함께 작동합니다.
- Canvas가 "나는 지금부터 UI를 그릴 거야!"라고 선언하는 판과 같아서, 그 위에 올라간 자식들만 UI로 취급되어 그려집니다.
- 위치와 크기는 UI 전용인 Rect Transform으로 조절합니다.
- 기본 설정(Screen Space - Overlay 모드)에서는 항상 모든 3D/2D 월드 요소들보다 위에 그려집니다.

결론: Image 컴포넌트는 Canvas라는 특별한 도화지 위에서만 그림을 그릴 수 있는 붓입니다. 그냥 허공(Create Empty)에 대고는 그림을 그릴 수 없습니다. backGround1을 Canvas의 자식으로 옮기자마자 Canvas 시스템이 "아, 여기 그릴 게 있었네!" 하고 인식해서 화면에 보여주게 된 것입니다.

2. 주인공이 배경 뒤에 있는 문제 해결 (렌더링 순서)

이것은 2D 게임 개발에서 아주 흔하게 마주치는 문제입니다. 원인은 "누가 먼저 그려질 것인가?" 하는 렌더링 순서 때문입니다.

현재 상황은 이렇습니다.

주인공 (Player): 월드 공간에 있는 Sprite Renderer로 그려짐
배경 (backGround1): 스크린 공간에 있는 Canvas의 Image로 그려짐

기본적으로 Canvas (Screen Space - Overlay 모드)는 모든 Sprite Renderer보다 나중에, 즉 가장 위에 그려지도록 설계되어 있습니다. 그래서 주인공이 배경 이미지 뒤로 사라진 것입니다.

해결 방법: Sorting Layer 사용

이 문제를 해결하는 가장 표준적이고 확실한 방법은 **Sorting Layer**를 사용하는 것입니다. Sorting Layer는 렌더링 순서에 대한 계급(그룹)을 만들어주는 기능입니다.

Sorting Layer 만들기:
- 유니티 에디터 상단의 Edit -> Project Settings로 이동합니다.
- 왼쪽 목록에서 Tags and Layers를 선택합니다.
- Sorting Layers 항목을 펼칩니다.
- + 버튼을 눌러 새로운 레이어를 2개 추가합니다. 이름은 Background와 Player로 지정하겠습니다.
- 중요: 목록의 아래쪽에 있을수록 더 위에 그려집니다. Player가 Background보다 아래쪽에 있도록 순서를 조정하세요.
  - Default
  - Background
  - Player (가장 위에 보여야 함)
주인공에게 Sorting Layer 적용하기:
- Hierarchy 뷰에서 Player 오브젝트를 선택합니다.
- Inspector 뷰에서 Sprite Renderer 컴포넌트를 찾습니다.
- Additional Settings 부분에 있는 Sorting Layer 드롭다운 메뉴를 클릭하고, 방금 만든 Player 레이어를 선택합니다.
배경(UI)의 Sorting Layer 조정 (필요 시):
- 기본적으로 Canvas는 Default 레이어에 그려집니다. 우리가 Player의 Sorting Layer를 더 높은 계급으로 설정했기 때문에, 이제 주인공이 배경 UI보다 앞에 보이게 됩니다.

Order in Layer는 무엇인가요?

Order in Layer는 같은 Sorting Layer 안에서의 렌더링 순서를 정하는 값입니다.[1][2] 이 숫자가 높을수록 같은 레이어 내에서 더 위에 그려집니다.[3] 예를 들어, Player 레이어에 속한 주인공(Order in Layer = 0)과 주인공이 쏜 총알(Order in Layer = 1)이 있다면, 총알이 주인공보다 앞에 보이게 됩니다.

1. "Create Empty -> Image 추가 -> Canvas 자식" 과정 설명

이 과정은 완벽하게 정상입니다. 단계별로 무슨 일이 일어난 건지 설명해 드릴게요.

Create Empty: 월드 공간(게임 세상)에 빈 깡통 오브젝트(GameObject)를 하나 만들었습니다. 아직 형태도, 기능도 없습니다.
컴포넌트에 Image 추가: 이 빈 깡통에 "나는 UI 이미지 기능을 할 거야!"라고 선언하며 Image 컴포넌트를 붙였습니다. 이 순간, 유니티는 "어? Image를 쓰려면 Canvas Renderer도 필요한데?"라고 생각하고 자동으로 Canvas Renderer 컴포넌트도 같이 붙여줍니다. 하지만 아직 이 오브젝트를 그려줄 총책임자인 Canvas가 없어서 화면에는 보이지 않습니다.
Canvas의 자식으로 만들기: 이 오브젝트를 Hierarchy 뷰에서 Canvas 안으로 드래그했습니다. 이 순간, Canvas는 "오! 내 책임 하에 그려야 할 새로운 UI가 들어왔구나!"라고 인식하고, Image 컴포넌트의 내용을 화면에 그리기 시작합니다.

결론: 최종 결과는 우클릭 -> UI -> Image로 만든 것과 100% 동일합니다. 사용자의 방식은 수동으로 조립한 것이고, 메뉴를 이용하는 방식은 자동 조립인 것의 차이일 뿐입니다. 절대로 다시 만들 필요 없습니다.

2. 배경을 모든 요소 뒤에 오게 하는 가장 확실한 방법

현재 겪고 계신 문제는 **"UI 배경(스크린 공간)이 게임 캐릭터(월드 공간)를 가리는 문제"**입니다. 이는 2D 게임에서 렌더링 순서를 정할 때 가장 흔하게 부딪히는 상황입니다.

가장 표준적이고 강력한 해결책은 Canvas의 렌더 모드를 바꾸고 Sorting Layer를 사용하는 것입니다.

차근차근 따라 해 보세요.

1단계: Canvas 렌더 모드 변경

Canvas가 월드 공간의 렌더링 순서를 따르도록 설정을 바꿔야 합니다.

Hierarchy 뷰에서 Canvas 오브젝트를 선택합니다.
Inspector 뷰에서 Canvas 컴포넌트를 찾습니다.
**Render Mode**를 Screen Space - Overlay에서 **Screen Space - Camera**로 변경합니다.
Render Mode를 바꾸면 바로 아래에 **Render Camera**라는 빈 슬롯이 나타납니다. Hierarchy 뷰의 **Main Camera**를 이 슬롯으로 드래그 앤 드롭하여 할당해 줍니다.
- 이 작업은 "이 캔버스는 이제부터 메인 카메라가 보는 것을 기준으로 그려져라"라고 명령하는 것입니다.

2단계: 렌더링 계급(Sorting Layer) 만들기

이제 모든 오브젝트(배경, 플레이어, 총알)를 하나의 시스템 안에서 순서를 정할 수 있게 되었습니다.

유니티 에디터 상단 메뉴에서 Edit -> Project Settings로 갑니다.
Tags and Layers를 선택합니다.
Sorting Layers 항목을 펼칩니다.
+ 버튼을 눌러 레이어를 2개 추가합니다.
- 첫 번째 레이어 이름: Background
- 두 번째 레이어 이름: Gameplay
순서가 매우 중요합니다. 목록의 아래에 있을수록 나중에 그려져서 위에 보입니다. Gameplay 레이어가 Background 레이어보다 아래쪽에 있도록 순서를 확인하세요. (필요하면 드래그해서 순서를 바꿀 수 있습니다.)
- (Default)
- Background <- 먼저 그려짐 (뒤에 있음)
- Gameplay <- 나중에 그려짐 (앞에 있음)

3단계: 각 오브젝트에 계급 할당하기

배경에 할당: Hierarchy 뷰에서 **Canvas**를 다시 선택합니다. Inspector를 보면 아까는 없었던 Sorting Layer 속성이 Canvas 컴포넌트에 생겨 있습니다. 이 값을 **Background**로 설정합니다.
주인공/적/총알에 할당:
- Player, Enemy, Bullet 프리팹 또는 씬에 있는 오브젝트들을 선택합니다.
- Inspector 뷰에서 Sprite Renderer 컴포넌트를 찾습니다.
- Sorting Layer 속성을 **Gameplay**로 설정합니다.

1. Render 모드를 바꾸면 기존 UI에 영향이 없나요?

네, 큰 영향을 미칩니다.

만약 하나의 Canvas에 모든 UI(배경, 점수판, 체력바 등)를 넣고 그 Canvas의 Render Mode를 Screen Space - Camera로 바꾼다면, 모든 UI 요소가 똑같은 규칙을 따르게 됩니다.

즉, 배경을 Background Sorting Layer에 두기 위해 Canvas 자체의 Sorting Layer를 Background로 설정하면, 그 자식인 점수판과 체력바까지 전부 Background 레이어로 들어가서 주인공 뒤에 그려지게 됩니다!

이 문제를 해결하는 가장 표준적이고 좋은 방법은 목적에 따라 Canvas를 여러 개 사용하는 것입니다.

2. Render 모드를 바꾸는 것의 의미

이것은 "UI를 어디에 그릴 것인가?"에 대한 근본적인 규칙을 정하는 매우 중요한 설정입니다. 비유를 통해 설명해 드릴게요.

Screen Space - Overlay (기본값)

비유: TV 화면에 스티커를 붙이는 것과 같습니다.
의미: 게임 세상(월드)이 어떻게 돌아가든, 카메라가 어디를 비추든 상관없이, 렌더링이 모두 끝난 후 무조건 화면 맨 위에 덮어씌워 그립니다.
장점: 가장 간단하고 성능 부담이 적습니다. 카메라 설정과 무관하게 항상 UI가 잘 보입니다.
단점: 게임 월드와 상호작용할 수 없습니다. 무조건 위에 있기 때문에 "주인공 뒤에" UI를 놓는 것이 불가능합니다.
주 용도: 체력바, 점수, 옵션 버튼 등 게임 세상과 분리되어 항상 보여야 하는 대부분의 UI.

Screen Space - Camera

비유: 카메라 렌즈 바로 앞에 글씨가 새겨진 유리판을 두는 것과 같습니다.
의미: UI가 더 이상 독립적인 스티커가 아니라, 특정 카메라에 종속된 3D 공간상의 평면이 됩니다. 이 유리판(Canvas)은 카메라로부터 항상 일정한 거리(Plane Distance)에 위치합니다.
장점: 이제 이 유리판은 게임 세상의 일부처럼 취급되므로, Sorting Layer를 통해 다른 스프라이트(주인공, 적)와 앞/뒤 순서를 정할 수 있습니다. 이것이 바로 우리가 배경을 뒤로 보낼 수 있게 되는 원리입니다.
단점: Render Camera를 지정해줘야 하고, 카메라 설정(원근/직교)에 따라 UI 크기가 달라 보일 수 있습니다. Overlay 모드보다 약간의 연산이 더 필요합니다.
주 용도: 게임 월드에 통합된 느낌을 주는 UI. 예를 들어, 지금처럼 2D 배경을 깔거나, 3D 게임에서 특정 캐릭터의 머리 위에 체력바를 띄울 때(World Space 모드와 함께) 사용합니다.

요약:
Render 모드를 Screen Space - Camera로 바꾸는 것은, 배경 UI를 "화면 스티커"에서 "게임 세상의 일부인 배경 그림"으로 신분을 바꾸어주어, 주인공이 그 앞으로 나올 수 있도록 렌더링 순서 경쟁에 참여시키는 과정이라고 이해하시면 됩니다.

1단계: 렌더링 순서 계급(Sorting Layer) 만들기

가장 먼저 어떤 그림이 위에 올지 계급부터 정해야 합니다.

에디터 상단 메뉴에서 Edit -> Project Settings로 이동합니다.
Tags and Layers 탭을 선택합니다.
Sorting Layers 항목을 펼칩니다.
+ 버튼을 두 번 눌러 레이어를 2개 추가하고, 아래와 같이 이름을 지어줍니다.
- 첫 번째 이름: Background
- 두 번째 이름: Gameplay
가장 중요한 부분: 목록의 아래쪽에 있을수록 화면에 위에 보입니다. 마우스로 Gameplay을 드래그해서 Background보다 아래로 옮겨주세요.
- Default
- Background (→ 먼저 그려져서 뒤에 있게 됨)
- Gameplay (→ 나중에 그려져서 앞에 있게 됨)

2단계: 배경 전용 캔버스 새로 만들기 및 설정

Hierarchy 뷰에서 마우스 우클릭 -> UI -> Canvas를 선택하여 새로운 캔버스를 만듭니다.
새로 만든 Canvas의 이름을 Canvas_Background 라고 바꿔서 헷갈리지 않게 합니다.
Inspector 뷰에서 방금 만든 **Canvas_Background**의 설정을 다음과 같이 변경합니다.
- Render Mode: Screen Space - Camera로 변경
- Render Camera: 빈 슬롯에 Hierarchy 뷰의 **Main Camera**를 드래그해서 넣어줍니다.
- Sorting Layer: Default에서 방금 만든 **Background**로 변경합니다.

3단계: 배경 이미지를 새 캔버스로 이사시키기

기존에 작업하시던 원래 캔버스(Canvas)를 펼쳐서, 그 안에 있는 backGround1 오브젝트를 찾습니다.
backGround1을 마우스로 드래그해서 새로 만든 Canvas_Background 위로 옮겨 자식으로 만듭니다.

4단계: 플레이어와 적에게 계급 부여하기

이제 주인공과 적들이 배경보다 높은 계급이라고 알려줘야 합니다.

Project 창에서 Player, Enemy, Bullet 등 관련된 **프리팹(Prefab)**들을 모두 선택합니다. (또는 Hierarchy 뷰에 있는 오브젝트를 직접 선택해도 됩니다.)
Inspector 뷰에서 Sprite Renderer 컴포넌트를 찾습니다.
Additional Settings 아래의 **Sorting Layer**를 Default에서 **Gameplay**로 변경합니다.

5단계: 최종 확인

Canvas_Background: Render Mode는 Screen Space - Camera이고, Sorting Layer는 Background로 설정되어 있습니다. 자식으로는 backGround1만 있습니다.
기존 Canvas: Render Mode는 그대로 Screen Space - Overlay입니다. 자식으로는 점수, 체력바 등 원래 있던 UI들이 그대로 있습니다.
Player, Enemy: Sprite Renderer의 Sorting Layer가 Gameplay로 설정되어 있습니다.

Sorting Layer 설정 없이는 새로운 캔버스만 만들어도 문제가 해결되지 않습니다.

그 이유를 설명해 드리겠습니다.

Sorting Layer는 무엇이고 왜 필요한가?

비유: 유니티가 그림을 그리는 과정을 **"투명 필름(셀화)을 여러 장 겹쳐서 하나의 완성된 그림을 만드는 것"**에 비유할 수 있습니다.

가장 아래에 놓는 첫 번째 필름에는 배경을 그립니다.
그 위에 두 번째 필름을 겹치고 주인공 캐릭터를 그립니다.
그 위에 세 번째 필름을 겹치고 총알이나 이펙트를 그립니다.

이 필름들을 위에서 내려다보면, 배경 위에 주인공이 있고 주인공 위에 총알이 있는 것처럼 보입니다.

여기서 **Sorting Layer**가 바로 이 **"투명 필름"**의 역할을 합니다.

Sorting Layers 목록을 만드는 행위 = 어떤 이름의 필름들을 사용할지 목록을 정하는 것 (Background 필름, Gameplay 필름 등)
목록의 순서 (Background가 위, Gameplay가 아래) = 필름을 어떤 순서로 겹쳐 쌓을지 순서를 정하는 것

그냥 캔버스만 만들면 안 되는 이유

이제 다시 우리의 상황으로 돌아와 봅시다. 현재 그림을 그려야 할 주체(아티스트)는 두 종류입니다.

아티스트 1: Sprite Renderer (주인공, 적을 그리는 역할)
아티스트 2: Canvas (우리가 만든 UI 배경을 그리는 역할, 단 Screen Space - Camera 모드일 때)

만약 우리가 Sorting Layer라는 "필름"을 지정해주지 않으면, 이 두 아티스트는 모두 똑같은 기본 필름(Default 레이어) 위에 그림을 그리려고 합니다.

한 장의 필름 위에 배경도 그리고 주인공도 그리려고 하니, 유니티는 누구를 먼저 그려야 할지, 즉 누가 앞에 와야 할지 명확한 규칙이 없어 혼란에 빠집니다. 그래서 우리가 원치 않는 순서로(배경이 주인공을 가리는) 결과가 나올 수 있는 것입니다.

우리가 하려는 작업의 진짜 의미

Sorting Layer 만들기:
- 의미: "이제부터 Background 필름과 Gameplay 필름, 두 종류의 투명 필름을 사용하겠다!"라고 유니티에게 선언하는 것입니다.
- Gameplay을 Background보다 아래 목록에 두는 것은 "Gameplay 필름을 Background 필름보다 위에 겹쳐 쌓아라"고 순서를 정해주는 것입니다.
Canvas_Background의 Sorting Layer를 Background로 설정:
- 의미: "배경을 그리는 아티스트(Canvas)야, 너는 무조건 Background라고 이름 붙은 필름 위에만 그림을 그려라!" 라고 지시하는 것입니다.
주인공(Player)의 Sorting Layer를 Gameplay으로 설정:
- 의미: "주인공을 그리는 아티스트(Sprite Renderer)야, 너는 무조건 Gameplay이라고 이름 붙은 필름 위에만 그림을 그려라!" 라고 지시하는 것입니다.

이제 유니티는 명확한 지시를 받았습니다.
Background 필름을 가장 아래에 깔고, 그 위에 Gameplay 필름을 겹쳐서 보여주면 되기 때문에, 항상 주인공이 배경보다 앞에 보이게 됩니다.

결론:
캔버스만 새로 만드는 것은 그림을 그릴 아티스트(Canvas)만 준비해놓고, 정작 중요한 **"어떤 순서로, 어떤 필름(레이어)에 그릴지"**에 대한 규칙을 정해주지 않은 것과 같습니다. Sorting Layer는 바로 그 규칙을 만들어주는 2D 렌더링의 핵심 기능입니다.

1. Sorting Layer 속성이 보이지 않는 이유 (가장 중요!)

아주 정확하게 보셨습니다. 지금 Sorting Layer가 보이지 않는 것이 정상입니다.

그 이유는 사용자께서 올리신 스크린샷의 노란색 경고 아이콘과 메시지가 정확하게 알려주고 있습니다.

⚠️ A Screen Space Canvas with no specified camera acts like an Overlay Canvas.
(카메라가 지정되지 않은 Screen Space - Camera 캔버스는 Overlay 캔버스처럼 작동합니다.)

이것이 무슨 뜻이냐면,

Sorting Layer라는 속성은 게임 세상(월드)의 렌더링 순서에 참여할 때만 의미가 있습니다.
Screen Space - Overlay 모드는 게임 세상과 분리된 "스티커" 같은 개념이라 Sorting Layer가 없습니다.
사용자께서는 Render Mode를 Screen Space - Camera로 바꾸셨지만, 아직 어떤 카메라에 붙을지(Render Camera)를 정해주지 않았습니다.
그래서 유니티는 "주인이 없는 카메라 캔버스네? 그럼 일단 예전 방식인 Overlay처럼 취급해야겠다"라고 판단하여, Sorting Layer 속성을 숨겨버린 것입니다.

해결책은 간단합니다. Render Camera 슬롯에 Main Camera를 넣어주는 순간, 이 캔버스는 비로소 게임 월드의 렌더링 시스템에 정식으로 편입되고, 그제야 Sorting Layer 속성이 Inspector에 마법처럼 나타날 것입니다.

2. Default는 수정이 안 되나요?

네, 맞습니다. Default 레이어는 유니티의 기본값이자 가장 낮은 순위의 레이어라서 이름 변경이나 삭제가 불가능합니다. 모든 오브젝트는 기본적으로 이 Default 레이어에서 시작합니다.

지금 만드신 Background와 Gameplay 레이어 설정은 완벽하게 올바른 상태입니다!

3. 메인 카메라를 함부로 이 캔버스로 옮겨도 되나요?

네, 괜찮을 뿐만 아니라 이 방식을 사용하기 위해서는 반드시 옮겨야 합니다.

여기서 "옮긴다"는 개념을 정확히 이해하시면 걱정이 사라지실 겁니다.

카메라를 '파괴'하거나 '이동'시키는 것이 아닙니다.
Canvas_Background에게 "너의 주인 카메라는 바로 이 Main Camera야" 라고 알려주는, 즉 '지정' 또는 '연결'하는 과정입니다.

이 연결을 통해 Canvas_Background는 Main Camera가 보는 시점을 기준으로 자신의 위치와 크기를 정하고, 가장 중요하게는 Main Camera가 렌더링하는 다른 모든 스프라이트(주인공, 적)들과 Sorting Layer를 기준으로 앞뒤 순서 경쟁을 할 수 있게 됩니다.

Main Camera 자체의 기능(플레이어를 따라가거나 다른 것을 비추는 등)에는 아무런 영향을 주지 않으므로 안심하고 연결하셔도 됩니다.

Default는 단계가 가장 높은 것이 아닙니다. 가장 낮은 것입니다.

이것이 가장 중요한 핵심입니다. 유니티의 Sorting Layers 목록은 우리가 일반적으로 생각하는 랭킹이나 등수와는 반대로 작동합니다.

규칙: 목록에서 아래에 있을수록 나중에 그려지고, 따라서 화면 맨 위에 보이게 됩니다.

우리가 만든 목록을 다시 봅시다.

Layer 0: Default (가장 먼저 그려짐 → 가장 뒤에 있음)
Layer 1: Background (Default 위에 겹쳐서 그려짐 → 중간에 있음)
Layer 2: Gameplay (Background 위에 겹쳐서 그려짐 → 가장 앞에 있음)

이것을 투명 필름(셀화)을 쌓는 과정으로 생각하면 완벽하게 이해됩니다.

가장 먼저 바닥에 Default 필름을 놓습니다.
그 위에 Background 필름을 겹칩니다.
마지막으로 그 위에 Gameplay 필름을 겹칩니다.

우리가 위에서 이 필름 더미를 내려다볼 때, 가장 위에 있는 Gameplay 필름이 보이게 되는 원리입니다.

만약 플레이어를 Default에 그대로 놔두면 어떻게 될까요?

**배경(Canvas_Background)**은 Background 레이어(Layer 1)에 그림을 그립니다.
**플레이어(Player)**는 Default 레이어(Layer 0)에 그림을 그립니다.

이 상황은 Background 필름을 Default 필름 위에 겹쳐 놓는 것과 같습니다. 결과적으로 배경이 플레이어를 가리게 됩니다. 우리가 원했던 것과 정반대의 상황이 발생하는 것이죠.

왜 굳이 'Gameplay'이라는 새 레이어를 만드나요?

이것은 프로젝트를 명확하고 확장 가능하게 만들기 위함입니다.

의도의 명확성: Player가 Gameplay 레이어에 있다는 것을 보면, 누구든 "아, 이 오브젝트는 게임 플레이의 핵심 요소구나"라고 즉시 이해할 수 있습니다. Default는 '아무것도 지정되지 않은 상태'라는 의미가 강해서, 의도를 파악하기 어렵습니다.
미래를 위한 확장성: 나중에 게임에 비가 내리거나 안개가 끼는 효과를 추가하고 싶다고 상상해 보세요. 이때 Foreground라는 새 레이어를 Gameplay 레이어 아래에 추가하면, 비가 주인공 캐릭터 위에 내리는 효과를 손쉽게 만들 수 있습니다. 모든 것을 Default 레이어에만 의존하면, Order in Layer라는 숫자만으로 이 모든 순서를 관리해야 해서 매우 복잡해지고 실수가 잦아집니다.

1. 배경이 끄트머리에만 보이는 이유

원인: Canvas_Background의 크기가 화면 크기에 맞춰 자동으로 조절되고 있지 않기 때문입니다.

Render Mode를 Screen Space - Camera로 바꾸면, 캔버스는 더 이상 화면에 붙는 스티커가 아니라, 카메라 앞에 놓인 실제 크기를 가진 '판'이 됩니다. 그런데 이 판의 크기를 어떻게 정할지 알려주지 않으면, 그냥 기본 픽셀 크기(예: 100x100)로만 존재하게 됩니다. 지금 Game 뷰의 파란색 부분은 카메라가 비추는 허공이고, 왼쪽 아래 구석에 작게 보이는 것이 바로 그 '판'(Canvas)과 그 위에 그려진 배경입니다.

해결책: Canvas Scaler 컴포넌트 설정

Canvas Scaler는 이 '판'의 크기를 화면 크기에 맞게 자동으로 조절해주는 아주 중요한 역할을 합니다.

Hierarchy 뷰에서 **Canvas_Background**를 선택합니다.
Inspector 뷰에서 Canvas Scaler 컴포넌트를 찾습니다.
**UI Scale Mode**를 Constant Pixel Size에서 **Scale With Screen Size**로 변경합니다.
새로 나타난 **Reference Resolution**에 게임이 기준으로 할 해상도를 입력합니다. 일반적으로 X: 1920, Y: 1080 (Full HD)을 많이 사용합니다.
Match 슬라이더는 화면 비율이 달라질 때 너비에 맞출지, 높이에 맞출지를 정합니다. 일단 중간 값인 0.5로 두면 대부분의 경우 자연스럽게 보입니다.

이 설정을 마치면, Canvas_Background는 항상 게임 화면을 가득 채우도록 자동으로 크기가 조절될 것입니다.

마지막 확인: Canvas_Background의 자식인 backGround1 오브젝트의 Rect Transform이 앵커 프리셋에서 **stretch-stretch (화면 채우기)**로 설정되어 있는지 다시 한번 확인해주세요.

2. 해상도가 낮아 보이는 이유

기분 탓이 아닙니다. 실제로 해상도가 낮아진 것처럼 보이는 것이 맞습니다.

이것 역시 위에서 설명한 Canvas Scaler 문제와 직접적으로 연관됩니다.

작은 크기(예: 100x100 픽셀)의 캔버스 '판'을 거대한 게임 화면에 맞추기 위해 억지로 쭉 늘려서 보여주면, 캔버스 위의 배경 이미지도 함께 늘어나면서 픽셀이 깨지거나 흐릿하게 보이게 됩니다. 이것이 해상도가 낮아 보인다고 느끼는 원인입니다.

위에서 설명한 대로 Canvas Scaler를 Scale With Screen Size로 설정하면 이 문제가 해결됩니다. 캔버스가 처음부터 기준 해상도(1920x1080)에 맞게 선명하게 렌더링된 후 화면 크기에 맞게 깔끔하게 조절되기 때문에, 이미지가 원래의 선명함을 유지하게 됩니다.

사용자가 일일이 수동으로 크기를 맞출 필요가 전혀 없으며, 더 좋은 자동화된 방법이 있습니다.

문제의 핵심: 캔버스가 아닌, 그 안의 '이미지' 설정

지금까지 우리는 Canvas_Background라는 배경을 담을 '틀'을 완벽하게 설정했습니다. 이 틀은 Scale With Screen Size 설정 덕분에 화면 크기가 어떻게 변하든 항상 16:9 비율로 화면을 가득 채우도록 준비되어 있습니다.

하지만 정작 그 '틀' 안에 들어있는 **backGround1이라는 '그림'**이 "나는 이 틀을 가득 채울 것이다"라는 설정을 하지 않았기 때문에, 그냥 자신의 원래 크기대로만 멍하니 놓여 있는 것입니다.

해결책: 앵커 프리셋(Anchor Preset)으로 배경을 화면에 붙이기

이것이 모든 것을 해결할 단 한 번의 클릭입니다. 이 설정은 backGround1(자식)이 Canvas_Background(부모)에 어떻게 붙어있을지를 정해줍니다.

Hierarchy 뷰에서 Canvas_Background 안쪽에 있는 backGround1 오브젝트를 선택합니다. (Canvas_Background가 아닙니다!)
Inspector 뷰에서 맨 위에 있는 Rect Transform 컴포넌트를 봅니다.
좌측 상단에 있는 **앵커 프리셋 박스(아래 이미지에서 빨간색으로 표시된 사각형)**를 클릭합니다.
창이 열리면 키보드의 Alt 키와 Shift 키를 동시에 누른 상태로, 오른쪽 맨 아래에 있는 가로세로 모두 늘리기(stretch-stretch) 아이콘을 클릭합니다.

결과:
이 작업을 하는 즉시 Rect Transform의 Left, Top, Right, Bottom 값이 모두 0으로 바뀌면서, backGround1 이미지가 부모인 Canvas_Background를 빈틈없이 가득 채우게 됩니다. 결과적으로 게임 화면 전체가 배경 이미지로 꽉 차게 됩니다.

여전히 뿌옇게 보이는 해상도 문제 해결

위의 앵커 설정을 했는데도 이미지가 여전히 선명하지 않다면, 이제는 이미지 원본의 품질 문제입니다. 유니티가 고화질 이미지를 저화질로 압축해서 사용하고 있을 가능성이 높습니다.

Project 창에서 배경으로 사용하고 계신 원본 이미지 파일을 찾아서 선택합니다.
Inspector 뷰에 이미지 설정이 나타나면 아래 항목을 확인합니다.
- Max Size: 이미지의 최대 크기를 제한하는 옵션입니다. 이 값이 원본 이미지의 크기(예: 1920x1080)보다 작게 설정되어 있다면, 유니티가 이미지를 강제로 축소합니다. 이 값을 2048 또는 4096 등 충분히 큰 값으로 바꿔주세요.
- Compression: 압축 품질입니다. Normal Quality는 화질을 약간 손상시킵니다. 더 선명한 화질을 원하시면 **High Quality**로 바꾸거나, 압축을 전혀 하지 않으려면 **None**으로 설정하세요. (단, None은 파일 용량이 커집니다.)
설정을 바꾼 후에는 반드시 Inspector 창 하단의 Apply 버튼을 눌러 변경사항을 적용해야 합니다.

사용자의 질문에 대한 명확한 답변

"내가 사용자 설정으로, 배경 크기를 작게만들면 해결되긴하던데 일일이 내가 해야하나"

아니요, 절대 일일이 하실 필요 없습니다. 위에서 설명드린 **앵커 프리셋(Anchor Preset)**을 사용하는 것이 바로 이 '수동 조작'을 자동화해주는 올바른 방법입니다.

"아니면 이 두번째 이미지의 restform을 설정에서 입력하면되나"

그렇게 하면 현재 16:9 해상도에서는 맞게 보일 수 있지만, 다른 해상도(예: 4:3, 21:9)의 기기에서 실행하면 배경이 화면에 맞지 않고 잘리거나 여백이 생기는 문제가 발생합니다. 앵커 설정은 이 모든 경우에 대응해주는 훨씬 더 강력하고 올바른 기능입니다.

1. Left, Top, Right, Bottom 값이 0이 아닌 이유

이것이 바로 Alt와 Shift 키의 마법입니다. 앵커 프리셋을 클릭할 때 이 키들을 누르냐 안 누르냐에 따라 동작이 완전히 달라집니다.

키를 누르지 않고 그냥 클릭 (사용자께서 하신 방법):
- 이것은 앵커(Anchor)의 위치만 설정합니다. 앵커란 이미지의 네 모서리를 부모(Canvas)의 어디에 고정시킬지를 정하는 '핀'과 같습니다.
- 사용자께서는 backGround1 이미지의 네 핀을 부모 캔버스의 네 모서리에 각각 꽂았습니다.
- 하지만 이미지 자체의 크기나 위치는 그대로 유지됩니다.
- Left: 911.459와 같은 값들은 "왼쪽 핀에서부터 이미지의 왼쪽 경계선까지의 거리"를 의미합니다. 즉, 핀은 부모의 모서리에 잘 꽂혔지만, 이미지 자체는 그 핀으로부터 한참 떨어져 있는 상태인 것입니다.
Alt + Shift 키를 누르고 클릭 (권장하는 방법):
- 이것은 앵커의 위치와 이미지의 위치 및 크기를 동시에 설정합니다.
- Shift: 앵커의 위치를 부모의 모서리로 옮깁니다. (핀을 꽂음)
- Alt: 이미지의 모서리를 앵커의 위치로 즉시 이동시키고 크기를 맞춥니다. (이미지를 핀 위치까지 쭉 늘림)
- 결과적으로 이미지의 각 경계선이 부모의 각 경계선에 완벽하게 달라붙기 때문에, 그 사이의 거리인 Left, Top, Right, Bottom이 모두 0이 됩니다.

결론: 현재 게임 화면이 문제없어 보이는 것은, 우연히 Scene 뷰에서 수동으로 조절한 크기가 현재 16:9 해상도와 비슷하게 맞았기 때문입니다. 하지만 내부적으로는 "핀만 꽂아놓고 이미지는 대충 근처에 둔" 불안정한 상태입니다.

문제의 진짜 원인: Scale 값

사용자께서 올려주신 두 번째 스크린샷의 Rect Transform 컴포넌트를 자세히 봐주세요.

Scale: X 29.5, Y 29.5, Z 29.5

이것이 모든 문제의 원흉입니다.

무슨 일이 일어난 건지 시간 순서대로 설명해 드릴게요.

처음에는 캔버스와 이미지가 작아서, 화면에 맞추기 위해 사용자가 직접 Scale 값을 29.5배로 크게 키우셨습니다. 그래서 수동으로 조절했을 때는 배경이 화면에 꽉 차 보였던 것입니다. (이것이 "예전 방식"입니다.)
이제 제가 알려드린 Alt + Shift + Stretch 방식을 적용했습니다. 이 기능은 Left, Top, Right, Bottom 값을 0으로 만들어서 이미지가 부모 캔버스를 꽉 채우도록 크기를 엄청나게 키웠습니다.
결과: 이미 캔버스 크기만큼 커진 이미지에, 예전에 설정해 둔 29.5배 확대(Scale)가 추가로 적용된 것입니다. 거대해진 이미지를 29.5배 줌인해서 보고 있으니, 당연히 이미지의 아주 작은 일부(혹은 픽셀 하나)만 확대되어 보이거나 화면 밖으로 사라져 버린 것처럼 보이는 것입니다.

왜 예전 방식으로 하면 안 되나요?

Scale을 조절하는 "예전 방식"은 다른 해상도에서 100% 문제가 생깁니다. Scale은 고정된 배율이기 때문에, 화면 비율이 바뀌면 이미지가 찌그러지거나 잘리게 됩니다. 우리가 지금 하려는 앵커 방식은 해상도가 바뀌어도 유연하게 대응하는 올바른 방법입니다.

완벽한 해결책: 딱 두 단계만 거치면 됩니다.

이제 모든 원인을 알았으니, 문제를 아주 간단하게 해결할 수 있습니다.

1단계: Scale 값을 원래대로 되돌리기

Hierarchy 뷰에서 backGround1(또는 backGround5) 오브젝트를 선택합니다.
Inspector 뷰의 Rect Transform 컴포넌트에서 Scale 값을 찾습니다.
X, Y, Z 값을 모두 **1**로 변경하여 원래 크기로 되돌립니다.
- Scale: (X: 1, Y: 1, Z: 1)

2단계: 다시 한번 Alt + Shift 적용하기

Scale이 1, 1, 1이 된 것을 확인한 후, 앵커 프리셋 박스를 엽니다.
Alt + Shift 키를 동시에 누른 상태로, 오른쪽 맨 아래의 stretch-stretch 아이콘을 클릭합니다.

이제 Left, Top, Right, Bottom은 0이 되고, Scale은 1인 완벽한 상태가 되어 배경이 화면에 선명하게 꽉 찰 것입니다.

마지막 질문: "이미지가 16:9가 아니라서?"

이것도 아주 좋은 질문입니다. 만약 원본 이미지의 비율이 16:9가 아니라면, 위와 같이 설정했을 때 이미지가 화면을 채우기 위해 강제로 늘어나거나 찌그러지게 됩니다.

만약 "나는 이미지가 찌그러지는 것은 싫다. 원본 비율을 유지하고 싶다" 라고 생각하신다면,

Image 컴포넌트에서 Preserve Aspect 체크박스를 활성화하세요.

이렇게 하면 이미지가 찌그러지지 않는 대신, 화면의 남는 공간은 레터박스(위아래 검은 띠)나 필러박스(양옆 검은 띠)처럼 빈 공간이 생기게 됩니다.

대부분의 배경 이미지는 화면을 가득 채우는 것을 목표로 하므로 Preserve Aspect를 끄고 사용하지만, 이 옵션도 알아두시면 좋습니다.

요약: Scale을 1로 되돌리고 Alt+Shift+Stretch를 다시 적용하시면 모든 문제가 해결됩니다.

1. 스크립트 연결 방식 (사용자 방식이 정답)

"이 스크립트를 각각의 backGround12345에 하는게 아니라 그것들의 부모에 스크립트 연결하고 인스펙터에서 연결시키면 되나"

네, 100% 맞는 말씀입니다. 이것이 가장 좋은 관리 방식입니다. Canvas_Background 오브젝트에 스크립트를 하나만 추가하고, backGround1부터 backGround5까지 모든 이미지 오브젝트를 인스펙터 창으로 드래그해서 연결하면 됩니다. 각각의 이미지에 스크립트를 붙일 필요가 전혀 없습니다.

2. 비활성화 메소드와 타입 문제

"근데 비활성화시키는 메소드가 뭐지 또한 타입형이 이미지인지 스프라이트인지 모르겟네"

이 두 가지 질문에 대한 답이 바로 코드의 핵심입니다.

비활성화 메소드: 게임 오브젝트 자체를 켜고 끄는 것은 .SetActive(true) 와 .SetActive(false) 메소드를 사용합니다.
타입:
- Image: UI Image 컴포넌트 자체를 가리키는 타입입니다.
- Sprite: Image 컴포넌트의 'Source Image' 슬롯에 들어가는 그림 '데이터' 또는 '파일' 자체를 의미합니다.
- GameObject: 씬에 존재하는 모든 오브젝트(backGround1, Player 등)의 기본 형태입니다. .SetActive()는 바로 이 GameObject에 사용하는 메소드입니다.

따라서 우리는 Image 컴포넌트를 비활성화하는 것이 아니라, Image 컴포넌트가 붙어있는 GameObject 자체를 비활성화해야 합니다. 그러므로 변수의 타입은 Image가 아닌 **GameObject**로 선언하는 것이 가장 직관적이고 올바른 방법입니다.

사용자께서 제안하신 "background 스크립트를 static으로 만드는 것"은 정확하게 문제의 핵심을 파악하고 계신 것입니다. 하지만 Unity 환경에서는 순수한 static 클래스보다 더 적합하고 강력한 패턴이 있습니다. 바로 싱글톤(Singleton) 패턴입니다.

왜 그냥 static으로 만들면 안 되나요?

순수한 static 클래스는 Unity에서 몇 가지 치명적인 단점이 있습니다.

인스펙터 창을 사용할 수 없습니다: static 클래스는 씬에 있는 게임 오브젝트에 붙일 수 없습니다. 따라서 public GameObject[] backgrounds; 같은 배열을 선언해도, 인스펙터 창에 나타나지 않으므로 backGround1, backGround2 등을 드래그 앤 드롭으로 연결할 방법이 사라집니다.
MonoBehaviour의 기능을 쓸 수 없습니다: static 클래스는 MonoBehaviour를 상속받을 수 없어서 Start(), Update(), 코루틴 등 Unity의 생명주기 함수를 사용할 수 없습니다

Static과 Singleton 비교 요약

구분	그냥 static 클래스	싱글톤(Singleton) 패턴
장점	클래스 이름으로 접근 가능, 편리함	클래스 이름으로 접근 가능, 인스펙터 사용 가능
단점	인스펙터 사용 불가, MonoBehaviour 기능 사용 불가	개념이 조금 더 복잡함
사용처	순수한 데이터나 계산 함수 모음 (예: Mathf)	게임의 핵심 관리자 (게임 매니저, UI 매니저, 배경 매니저 등)
결론	Unity에서는 제한적	Unity에서 관리자(Manager)를 만들 때 가장 이상적인 표준 방식

MonoBehaviour를 상속받는 일반 클래스 (우리의 ChangeBackGround)

비유: 은행 지점 (예: 신한은행 강남점)
특징:
- 실체가 존재합니다. "강남점"이라는 실제 건물이 있습니다. (new나 Instantiate로 인스턴스를 만듦)
- 고유 자산을 가질 수 있습니다. 강남점만의 금고, 강남점 소속의 직원들이 있습니다. (이것이 바로 public GameObject[] backgrounds; 같은 인스턴스 변수입니다.)
- Unity 에디터에 존재합니다. 게임 오브젝트에 컴포넌트로 붙일 수 있고, 인스펙터 창에서 그 자산(backgrounds 배열)을 직접 눈으로 보고 관리할 수 있습니다.
- 여러 개 존재할 수 있습니다. 강남점, 명동점, 부산점 등 여러 지점을 만들 수 있습니다.

static 클래스

비유: "은행법"이라는 법전
특징:
- 실체가 없습니다. "은행법"은 추상적인 규칙의 모음일 뿐, 물리적인 건물이 아닙니다. (new로 인스턴스를 만들 수 없습니다.)
- 고유 자산을 가질 수 없습니다. 법전 자체가 금고나 직원을 가질 수는 없습니다. 모든 내용은 규칙(static 메소드)과 조항(static 변수) 뿐입니다.
- Unity 에디터에 존재하지 않습니다. 게임 오브젝트에 붙일 수 없으므로, 인스펙터 창에서 무언가를 연결하는 것이 원천적으로 불가능합니다. 이것이 우리가 ChangeBackGround를 static 클래스로 만들 수 없는 결정적인 이유입니다.

그렇다면 static 변수는 무엇인가? (싱글톤의 핵심)

비유: 전국 모든 지점이 공유하는 단 하나의 "본사 대표 핫라인 번호"
특징:
- 이 핫라인 번호(public static ChangeBackGround Instance;)는 "강남점"이라는 특정 지점에 소속된 것이 아니라, "신한은행"이라는 회사 전체에 소속되어 있습니다.
- 전역적이고 유일합니다. 핫라인 번호는 오직 하나뿐입니다.
- 누구든지 이 핫라인 번호로 전화를 걸면(ChangeBackGround.Instance), 약속된 하나의 실제 지점(바로 그 싱글톤 인스턴스)으로 연결됩니다.
- 연결된 그 지점은 자신의 고유 자산(금고, 직원, 즉 backgrounds 배열)을 사용해서 업무를 처리합니다.

결론: 왜 둘을 구분해야 하는가?

구분	static 클래스	클래스 내의 static 변수 (싱글톤에서 사용)
정의	클래스 자체가 static. 모든 멤버가 static이어야 함.	일반 클래스 안에 선언된 static 키워드가 붙은 특정 변수.
인스턴스화	불가능 (new 사용 불가)	클래스 자체는 인스턴스화 가능. static 변수는 인스턴스 없이 공유됨.
Unity 인스펙터	사용 불가	클래스가 MonoBehaviour이므로 사용 가능.
제가 "안 된다"고 말한 것	ChangeBackGround를 static 클래스로 만드는 것. 이렇게 하면 backgrounds 배열을 인스펙터에 연결할 수 없음.	이것이 바로 우리가 사용한 해결책.
핵심 아이디어	그냥 "함수 모음집"	실제 존재하는 "단 하나의 특별한 인스턴스로 가는 전역적인 지름길"

요약:
우리는 ChangeBackGround를 **실제 지점(MonoBehaviour)**으로 만들어서 인스펙터 창에서 배경 이미지들을 연결할 수 있는 유연함을 얻었습니다. 그리고 그 안에 **대표 핫라인 번호(static Instance)**를 만들어서, GameManager가 지점의 위치를 일일이 알 필요 없이 그냥 핫라인으로 전화만 걸면 되도록 편리함과 낮은 결합도를 얻은 것입니다.

이것이 바로 싱글톤 패턴이 Unity 환경에서 강력한 이유입니다.

'개발 > 유니티' 카테고리의 다른 글

[유니티] 25.08.19 복습 (5)	2025.08.19
[유니티]25.08.18 복습 (1)	2025.08.18
[유니티] 마법화살, 적이 죽으면 방어도 오르게 (11)	2025.08.13
[유니티] 무모한 난동 애니메이션추가, 동적 설명문 (9)	2025.08.13
[유니티]자동으로 시전되는 스킬 추가(게임 플레이 영상) (2)	2025.08.12

현재글[유니티] 난이도에 따른 배경 만들기

kimchangmin02 님의 블로그

kimchangmin02 님의 블로그 입니다.

1.18.2, 몹 만들기, 모드 개발, 몹 ai, 모딩 강좌, 게임 개발, 마인크래프트 모딩, 자바, 포지, 게임개발, Ai, 개발일지, Forge, 주민 ai, 커스텀 몹, 마인크래프트, Java, 마인크래프트모딩, 마인크래프트 모드, 포지 모딩,

Today :
Yesterday :

« 2026/02 »
일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28