wan의 개발일기

RoomCraft #22. Undo/Redo, 복제, 벽 스냅 - 세 기능 한 번에 넣고 본 버그들

wan_ — Sat, 11 Jul 2026 10:22:19 +0900

소스코드 → github.com/Jywan/RoomCraft

들어가며

레이아웃 비교(썸네일)까지 끝내고 나니, 정작 배치 자체를 만지는 손맛이 아쉬웠다. 가구 하나 잘못 옮기면 처음부터 다시 배치해야 하고, 비슷한 가구를 여러 개 놓으려면 매번 새로 만들어야 하고, 벽에 딱 붙여놓고 싶어도 픽셀(정확히는 미터) 단위로 손으로 맞춰야 했다. 이번엔 이 세 가지 — 실행 취소/다시 실행, 가구 복제, 벽 스냅 — 를 한 번에 밀어붙이기로 했다. 세 개를 한꺼번에 진행한 이유는 단순한데, 이 프로젝트에서 "기능 하나 추가 → 씬 연결 하나 빠뜨림 → 재검수" 패턴이 하도 많이 반복돼서, 차라리 작은 단위로 쪼개서 순서대로 빠르게 돌리는 게 낫겠다고 판단했기 때문이다. 그리고 실제로 이번 편에도 그 패턴이 여러 번 나온다.

1. 실행 취소/다시 실행 (Undo/Redo)

Ctrl+Z(맥은 Cmd+Z)로 되돌리기, Ctrl+Shift+Z로 다시 실행. 별도 버튼은 없고 RoomToolbar.Update()에서 키 입력을 감지해서 처리한다. Command 패턴으로 갔다. 동작 하나(생성/이동/회전/삭제)를 Execute()/Undo() 두 메서드를 가진 객체로 만들어서 스택에 쌓는 방식이다. 새 디렉토리 Scripts/UndoRedo/를 따로 파서 기존 Furniture/Room/UI 분류와 안 섞이게 했다.

public interface ICommand
{
    void Execute();
    void Undo();
}

public class UndoManager : MonoBehaviour
{
    private readonly Stack<ICommand> undoStack = new Stack<ICommand>();
    private readonly Stack<ICommand> redoStack = new Stack<ICommand>();

    // 지금 바로 실행하면서 기록 (예: 삭제)
    public void ExecuteCommand(ICommand command)
    {
        command.Execute();
        undoStack.Push(command);
        redoStack.Clear();
    }

    // 이미 실행된 동작을 기록만 함 (예: 드래그로 이미 옮겨진 가구)
    public void RecordCommand(ICommand command)
    {
        undoStack.Push(command);
        redoStack.Clear();
    }
}

ExecuteCommand와 RecordCommand를 나눈 이유는, 드래그 이동처럼 "이미 화면에서 벌어진 일"과 삭제처럼 "지금 이 순간 실행해야 하는 일"이 다르기 때문이다. 드래그는 매 프레임 위치가 바뀌다가 마우스를 뗀 시점에야 최종 위치가 확정되니, 그때 가서 "이만큼 움직였다"고 기록만 하면 된다. 반대로 삭제는 커맨드가 직접 파괴까지 담당해야 한다.

버그 1: 커맨드 추가하다가 드래그가 통째로 죽음

Undo 기록 코드를 HandleDrag()에 끼워넣는 과정에서, 실제 마우스를 따라 가구를 옮기는 로직(Raycast + MoveTo + 그리드 스냅 + 경계 검사)이 통째로 주석 처리되고 그 자리에 무조건 return이 들어가 버렸다. 게다가 Undo 기록 코드도 "마우스를 뗐을 때"가 아니라 매 프레임 실행되는 위치에 들어가 있었다. 결과적으로 가구를 클릭은 되는데 드래그는 전혀 안 되는 상태였다.

private void HandleDrag()
{
    if (!hasSelection || !isDragging) return;

    if (Input.GetMouseButtonUp(0))
    {
        isDragging = false;
        // ... 되돌리기 처리 ...
        return;
    }

    // 실제로 위치가 바뀌었다면 Undo 기록
    Vector3 finalPos = selectedFurniture.transform.position;
    if (hasUndoManager && finalPos != dragStartPosition)
        undoManager.RecordCommand(new MoveFurnitureCommand(...));

    return;   // 여기서 매 프레임 무조건 빠져나감
    // Raycast + MoveTo 로직은 전부 주석 처리되어 이 아래는 죽은 코드
}

원래 이동 로직을 복원하고, Undo 기록은 Input.GetMouseButtonUp(0) 블록 안, 되돌리기 처리 바로 다음으로 옮겼다. 마우스를 뗀 그 프레임에 딱 한 번만 실행되는 게 맞다.

버그 2: Redo 한 다음 Undo가 꼬임

Redo()가 실행한 커맨드를 redoStack에 도로 넣고 있었다. 되감기(Undo)로 스택을 옮겼으면 되돌리기(Redo)는 그 반대인 undoStack으로 다시 옮겨야 하는데, 복사하다가 변수명을 잘못 짚은 흔한 실수였다.

public void Redo()
{
    if (redoStack.Count == 0) return;
    ICommand command = redoStack.Pop();
    command.Execute();
    undoStack.Push(command);   // redoStack이 아니라 undoStack
}

버그 3: 생성 직후 Undo를 눌러도 반응 없음

가구를 새로 만들고 바로 Ctrl+Z를 누르면 아무 일도 안 일어났다. 원인은 CreateFurnitureCommand가 RecordCommand() 경로(이미 실행된 생성을 기록만 하는 경우)로 쓰일 때는 Execute()가 아예 호출되지 않는다는 점이었다. 그런데 파괴 대상 참조(created 필드)는 오직 Execute() 안에서만 채워지도록 짜여 있었다 — Undo()가 실행돼도 created가 계속 null이라 파괴할 대상이 없었던 것.

public CreateFurnitureCommand(FurnitureInteraction interaction, FurnitureData data,
    Vector3 position, float rotationY, FurnitureObject alreadyCreated = null)
{
    // ...
    this.created = alreadyCreated;   // 이미 생성된 오브젝트를 직접 받을 수 있게
}

생성자에 이미 만들어진 가구를 직접 넘길 수 있는 선택적 파라미터를 추가해서, RecordCommand 경로에서도 created가 채워지도록 했다.

버그 4: 선택된 가구를 지웠더니 콘솔이 폭주함

가장 재밌었던(사실 제일 무서웠던) 버그. 선택 중인 가구를 Undo/Redo가 Object.Destroy()로 직접 파괴하면, FurnitureInteraction이 들고 있던 "지금 선택된 가구" 참조는 아무도 정리해주지 않는다. Unity의 MonoBehaviour는 파괴돼도 C# 레퍼런스 자체는 null이 되지 않고 "죽은 오브젝트를 가리키는 참조"로 남는데, 매 프레임 이 참조에 접근하던 FurnitureToolbar.Update()가 MissingReferenceException을 계속 던지기 시작했다. 한 번이 아니라 Update()가 도는 한 영원히.

하필 1인칭 모드로 들어갈 때 눈에 띄었는데, 알고 보니 우연이 아니었다. 1인칭 진입 시 호출하는 DeselectAll()도 내부에서 이 죽은 참조에 접근하려다 예외를 던지고, 그 바람에 선택 상태를 지우는 코드 자체가 중간에 끊겨서 영원히 정리가 안 되는 상태로 남는 것이었다.

// FurnitureInteraction.cs
public void ClearSelectionIfMatches(FurnitureObject obj)
{
    if (hasSelection && selectedFurniture == obj)
        DeselectCurrent();
}

// DeleteFurnitureCommand.cs
public void Execute()
{
    interaction.ClearSelectionIfMatches(targetFurniture);   // 파괴 직전에 먼저
    Object.Destroy(targetObject);
}

가구를 파괴하는 두 지점(CreateFurnitureCommand.Undo(), DeleteFurnitureCommand.Execute()) 모두에서, 파괴하기 직전에 "이게 지금 선택된 애면 먼저 선택 해제"를 거치도록 했다.

2. 가구 복제 (Ctrl+D)

가구를 하나 선택한 상태에서 Ctrl+D(맥은 Cmd+D)를 누르면 복제된다. 선택된 가구를 원본에서 대각선으로 살짝(가로세로 각 0.3m) 띄운 자리에 복제하고, 복제본을 바로 선택 상태로 넘겨서 이어서 드래그할 수 있게 만들었다. 생성 로직은 Undo/Redo에서 이미 만든 SpawnFurniture() + CreateFurnitureCommand 조합을 그대로 재사용했다.

버그: 한 번 눌렀는데 수십 개가 복제됨

Ctrl+D를 눌렀더니 원본에서 대각선으로 가구가 줄줄이 늘어서는 진풍경이 벌어졌다. 범인은 macOS의 키 반복(OS auto-repeat)이었다. Input.GetKeyDown()은 원칙적으로 키가 눌리는 그 프레임에 딱 한 번만 true를 반환해야 하는데, OS가 키를 누르고 있는 동안 보내는 반복 입력에도 반응해서 매 반복마다 새로 "눌림"으로 잡혔다. 복제는 매번 직전 복제본을 기준으로 대각선으로 이동하니, 반복될수록 원본에서 점점 멀어지는 사선이 그려진 것이다.

private bool duplicateKeyHeld = false;

private void HandleDuplicate()
{
    if (!hasSelection) return;

    bool modifier = Input.GetKey(KeyCode.LeftControl) || Input.GetKey(KeyCode.LeftCommand) // ...;
    bool dKeyPressed = Input.GetKey(KeyCode.D);

    if (modifier && dKeyPressed && !duplicateKeyHeld)
    {
        DuplicateSelected();
        duplicateKeyHeld = true;
    }
    else if (!dKeyPressed)
    {
        duplicateKeyHeld = false;
    }
}

GetKeyDown 대신 GetKey(지금 물리적으로 눌려있는지 raw 상태)를 쓰고, 직접 관리하는 duplicateKeyHeld 플래그로 "키를 뗄 때까지 다시 실행 안 함"을 보장했다. OS가 몇 번을 반복해서 보내든 실제 복제는 딱 한 번만 일어난다.

회전(Q/E/R)이나 삭제(Delete)도 이론상 같은 문제가 있을 텐데, 결과가 눈에 덜 띄어서(회전 한 번 더 됐다고 표시가 확 나지는 않으니) 지금까지 아무도 못 알아챘을 뿐이다. 나중에 비슷한 증상이 보이면 같은 패턴으로 고치면 된다.

3. 벽에 스냅

버튼이나 단축키로 "실행"하는 기능이 아니라, 가구를 드래그하는 동안 자동으로 붙는다. 대신 B 키로 이 자동 스냅 자체를 켜고 끌 수 있게 RoomToolbar에 토글을 추가했다(그리드 스냅의 G키와 같은 자리). 동작 방식은, 드래그 중인 가구가 방 외곽선(벽)에 일정 거리 이내로 가까워지면 그 벽에 딱 붙는 위치로 옮기고 방 안쪽을 바라보도록 자동으로 회전시키는 것이다. 새 스크립트 WallSnap.cs가 방 외곽선의 각 변을 순회하면서 가장 가까운 변을 찾고, 거리가 임계값(0.3m) 이내면 그 변의 안쪽 법선 방향으로 가구를 밀어낸다.

버그 1: 벽 속으로 파고듦

테스트해보니 가구가 벽에 붙기는 하는데 절반쯤 벽 속에 파묻혀 있었다. RoomBuilder.CreateWallSegment()를 다시 들여다보니 원인이 명확했다.

wall.transform.localPosition = new Vector3(mid.x, data.height / 2f, mid.y);
wall.transform.localScale = new Vector3(length, data.height, wallThickness);

벽(Cube)이 방 외곽선 좌표를 중심선으로 삼아서 양쪽으로 벽 두께의 절반씩 퍼지는 구조였다. 즉 vertices는 벽의 "안쪽 면"이 아니라 "중심선"인데, WallSnap은 가구를 이 중심선에서 가구 반깊이만큼만 띄우고 있었다 — 벽 두께 절반만큼 실제 안쪽 면에 못 미친 셈이다.

public const float WallThickness = 0.1f;   // RoomBuilder, 외부에서도 참조

// WallSnap.cs
Vector2 snapped2D = alongWall + bestNormal * (halfDepth + RoomBuilder.WallThickness / 2f);

벽 두께를 RoomBuilder의 public const로 빼내서 한 곳에서만 관리하고, 스냅 위치 계산에 그 절반만큼을 추가로 반영했다.

버그 2: 코너에서 옆 벽으로 삐져나감

벽 두께는 해결됐는데, 방 코너(가로/세로 벽이 만나는 지점)에서 유독 가구가 옆 벽을 침범하는 게 보였다. 원인은 스냅 로직이 가구의 깊이(앞뒤) 방향만 벽에서 띄우고, 폭(좌우) 방향은 전혀 검사하지 않고 있었다는 것. 가구를 벽 하나에 딱 맞춰 세워도, 그 가구가 넓으면 옆쪽 끝이 코너를 넘어 인접한 벽 영역까지 뻗어나갈 수 있다는 걸 놓쳤다.

// 벽을 따라(가구 폭 방향) 코너를 넘어가지 않도록 위치를 세그먼트 안쪽으로 고정
Vector2 edgeDir = (bestB - bestA).normalized;
float segmentLength = Vector2.Distance(bestA, bestB);
float t = Vector2.Dot(point - bestA, edgeDir);
float margin = Mathf.Min(halfWidth, segmentLength / 2f);   // 벽이 가구보다 짧으면 가운데로
t = Mathf.Clamp(t, margin, segmentLength - margin);
Vector2 alongWall = bestA + edgeDir * t;

가구가 놓일 위치를 벽 세그먼트의 시작/끝 범위 안으로, 가구 반폭만큼 여유를 두고 클램프했다. 벽이 가구보다 짧으면 억지로 맞추는 대신 그 벽 가운데에 놓이도록 폴백을 뒀다. 코너 근처에서 다시 테스트하니 이제 옆 벽을 넘어가지 않는다.

정리

기능	핵심 구현
실행 취소/다시 실행	Command 패턴, ICommand + UndoManager(Stack 2개), ExecuteCommand/RecordCommand 구분
가구 복제	Ctrl+D, SpawnFurniture() 재사용, GetKey + 자체 플래그로 OS 키 반복 방지
벽 스냅	WallSnap.TrySnap(), 벽 두께 보정 + 폭 방향 코너 클램프
발견한 버그	드래그 로직 유실, Redo 스택 오류, 생성 직후 Undo 무반응, 파괴된 오브젝트 참조로 예외 폭주, 키 반복으로 인한 중복 실행, 벽 두께/코너 겹침
다음 단계	md 문서 정리 후 다음 기능 논의

RoomCraft #21. 저장 목록에 미리보기 넣기 - 레이아웃 비교의 첫걸음

wan_ — Fri, 10 Jul 2026 10:45:47 +0900

소스코드 → github.com/Jywan/RoomCraft
플레이 → jywan.github.io/RoomCraft

들어가며

가구 프리셋을 만들면서 README를 다시 훑다가, "여러 레이아웃 비교"도 아직 없다는 걸 확인했었다. 구현 방식을 세 가지로 놓고 저울질했다 — 화면을 분할해서 두 방을 동시에 렌더링하는 방식(제일 그럴듯하지만 카메라 2대에 공간 분리까지 손볼 게 많음), 단축키로 저장된 레이아웃을 빠르게 넘겨보는 방식(간단하지만 그때그때 다시 불러와야 함), 그리고 저장 목록에 미리보기 썸네일을 넣는 방식. 구현 난이도 대비 효과가 제일 좋아 보이는 세 번째로 정했다.

저장할 때 스크린샷도 같이

저장 버튼을 누르면 이름 입력 팝업이 뜨고, 확인을 누르면 JSON으로 저장되는 게 기존 흐름이었다. 여기에 스크린샷 캡처를 끼워 넣었는데, 타이밍이 생각보다 까다로웠다.

확인 버튼을 누른 그 즉시 ScreenCapture.CaptureScreenshotAsTexture()를 부르면, 방금 SetActive(false)로 꺼버린 저장 팝업이 스크린샷에 그대로 찍힌다. Unity의 화면 캡처는 "마지막으로 완전히 렌더링된 프레임"을 가져오는데, 오브젝트를 비활성화한 시점과 그 결과가 실제로 화면에 그려지는 시점 사이에 프레임 경계가 하나 끼어있기 때문이다.

private void OnConfirmSave()
{
    // ... 이름/방 데이터 확인 ...

    savePanel.SetActive(false);   // 팝업부터 숨기고
    StartCoroutine(CaptureAndSave(projectName, roomData));
}

private IEnumerator CaptureAndSave(string projectName, RoomData roomData)
{
    yield return new WaitForEndOfFrame();   // 팝업이 사라진 프레임이 실제로 그려질 때까지 대기

    Texture2D screenshot = ScreenCapture.CaptureScreenshotAsTexture();
    byte[] thumbnailPng = screenshot.EncodeToPNG();
    Destroy(screenshot);

    projectManager.SaveProject(projectName, roomData, thumbnailPng);
}

WaitForEndOfFrame() 한 프레임만 기다렸다가 캡처하면, 팝업이 사라진 깨끗한 화면이 찍힌다.

썸네일 파일은 어떻게 관리할까

기존 저장 로직은 {프로젝트이름}.json 하나만 썼는데, 여기에 같은 이름의 .png를 나란히 저장하기로 했다. 파일명 규칙만 맞추면 JSON을 찾을 때 옆에 있는 PNG도 바로 유추할 수 있어서 별도 매핑 테이블이 필요 없다.

public void SaveProject(string projectName, RoomData roomData, byte[] thumbnailPng = null)
{
    // ... 기존 JSON 저장 로직 ...

    if (thumbnailPng != null)
    {
        string thumbPath = Path.Combine(saveDirectory, SanitizeFileName(projectName) + ".png");
        File.WriteAllBytes(thumbPath, thumbnailPng);
    }
}

public static Texture2D LoadThumbnail(string jsonFileName)
{
    string dir = Path.Combine(Application.persistentDataPath, "Projects");
    string baseName = Path.GetFileNameWithoutExtension(jsonFileName);
    string filePath = Path.Combine(dir, baseName + ".png");

    if (!File.Exists(filePath)) return null;

    byte[] data = File.ReadAllBytes(filePath);
    Texture2D tex = new Texture2D(2, 2);
    tex.LoadImage(data);
    return tex;
}

LoadThumbnail()을 static으로 만든 게 포인트다. 썸네일을 보여줘야 하는 곳은 StartScene의 불러오기 화면인데, 거기엔 ProjectManager 인스턴스가 없다 — ProjectManager는 EditorScene에만 있다. 이미 GetSavedProjectFiles()가 인스턴스 없이 static으로 동작하고 있어서, 같은 패턴을 그대로 따라갔다.

목록에 붙이기

불러오기 목록의 각 항목 프리팹(FileItemButton)에 Thumbnail이라는 이름의 Image 자식을 추가하고, 코드에서 이름으로 찾아서 채워 넣었다.

Image thumbnailImage = item.transform.Find("Thumbnail")?.GetComponent<Image>();
if (thumbnailImage != null)
{
    Texture2D thumb = ProjectManager.LoadThumbnail(fileName);
    if (thumb != null)
        thumbnailImage.sprite = Sprite.Create(thumb, new Rect(0, 0, thumb.width, thumb.height), new Vector2(0.5f, 0.5f));
}

불러오기 목록 — 가운데 항목만 실제 썸네일이 찍혀있다

스크린샷을 보면 항목 하나만 진짜 썸네일이 있고 나머지 둘은 흰 사각형이다. 이 기능을 붙이기 전에 이미 저장해뒀던 프로젝트들이라 대응하는 PNG가 없어서 그런 건데, 일부러 손대지 않았다 — 예전 저장 파일도 여전히 문제없이 불러와지는 게 중요하지, 오래된 파일에 썸네일이 없다고 에러를 낼 이유는 없다.

삽질 기록

또, Layout Group

항목 프리팹 높이를 썸네일이 들어갈 만큼 키웠더니(40 → 70) 목록이 지저분해졌다. 이번엔 원인이 두 개가 겹쳐 있었다.

첫째, Content 오브젝트에 Content Size Fitter가 없어서 부모(스크롤 영역)가 자식들의 늘어난 높이를 반영 못 하고 있었다. 이건 이 프로젝트에서 셀 수 없이 반복된 패턴이라 바로 눈에 들어왔다.

둘째는 처음 보는 조합이었다. Vertical Layout Group의 Control Child Size는 Width가 꺼져있고, Child Force Expand는 Height가 켜져있었다. Control Child Size가 꺼진 축은 자식이 자기 프리팹 크기를 그대로 유지하고, Force Expand는 남는 공간을 자식들에게 나눠주는 것까지는 하는데 — 이 둘이 어긋난 축에 걸려있으니 가로는 리스트 폭에 안 맞고 세로는 스크롤 영역의 남는 공간만큼 제멋대로 늘어났다.

Control Child Size랑 Child Force Expand는 비슷해 보이지만 하는 일이 다르다. 전자는 "자식 크기를 내가 강제로 정한다", 후자는 "남는 공간이 있으면 나눠준다"에 가깝다. 리스트 형태로 고정 높이 항목을 나열하고 싶으면 Control Child Size Width만 켜고 Height 쪽은 Control/Force Expand 둘 다 꺼야 프리팹 높이가 그대로 유지된다.

정리

기능	핵심 API / 구조
저장 시 스크린샷 캡처	ScreenCapture.CaptureScreenshotAsTexture() + WaitForEndOfFrame()
썸네일 파일 관리	JSON과 동일한 파일명의 .png, ProjectManager.LoadThumbnail()(static)
목록에 썸네일 표시	FileItemButton 프리팹의 Thumbnail 자식 + Sprite.Create()
Layout Group 정리	Content Size Fitter 추가, Control Child Size/Force Expand 축 정리
다음 단계	WebGL 한글 입력 버그, Phase 6-2 모바일 배포(미정)

RoomCraft #20. 가구도 즐겨찾기가 되나요 - 프리셋 시스템

wan_ — Fri, 10 Jul 2026 08:36:55 +0900

소스코드 → github.com/Jywan/RoomCraft
플레이 → jywan.github.io/RoomCraft

들어가며

지난 편에서 README에 적혀만 있고 실제론 없던 1인칭 뷰를 발견해서 만들었는데, 같은 방식으로 다시 훑어보니 하나 더 나왔다. "저장/관리: 여러 레이아웃 비교, 가구 목록 재사용"이라고 적혀있는데, 프로젝트 저장/불러오기는 되지만 "레이아웃 비교"도 "가구 목록 재사용"도 실제로는 없었다. 레이아웃 비교는 여러 방을 동시에 띄우거나 스크린샷을 나란히 보여줘야 해서 작업이 커서 보류하고, 가구 재사용 쪽부터 만들었다.

프로젝트와 무관한 저장소

기존 저장 시스템(ProjectManager)은 방 하나 + 그 안의 가구들을 한 세트로 묶어서 저장한다. 근데 가구 프리셋은 성격이 다르다 — "이 침대 디자인이 마음에 들어서 다른 방 만들 때도 쓰고 싶다"는 요구라, 특정 프로젝트에 종속되면 안 된다. 그래서 완전히 별도의 전역 저장 파일을 하나 뒀다.

// FurniturePresetManager.cs
public class FurniturePresetManager : MonoBehaviour
{
    private string presetFilePath;

    private void Awake()
    {
        presetFilePath = Path.Combine(Application.persistentDataPath, "FurniturePresets.json");
    }

    public void SavePreset(FurnitureData data)
    {
        FurniturePresetList list = LoadAll();
        list.presets.Add(data);
        File.WriteAllText(presetFilePath, JsonUtility.ToJson(list, true));
    }
}

JsonUtility는 최상위 List를 바로 직렬화하지 못해서, FurnitureData 리스트 하나를 감싸는 FurniturePresetList 래퍼 클래스를 따로 만들었다. 이미 ProjectManager가 ProjectData를 이런 식으로 감싸서 저장하고 있어서, 그대로 패턴만 재사용했다.

생성 폼 재활용하기

가구 생성 팝업(FurnitureCreatorUI)은 원래 카테고리/이름/치수/색상을 입력받아서 FurnitureData를 만들고 바로 방에 배치하는 용도였다. 이 폼을 그대로 재활용해서, "생성"이랑 "프리셋으로 저장" 두 버튼이 같은 입력값을 서로 다른 곳으로 보내게 만들었다.

// 기존엔 OnCreateClicked() 안에 있던 파싱 로직을 헬퍼로 분리
private FurnitureData BuildFurnitureDataFromForm()
{
    // 이름/치수/카테고리/색상 파싱 (기존 로직 그대로)
    ...
    return data;
}

private void OnCreateClicked()
{
    FurnitureData data = BuildFurnitureDataFromForm();
    furnitureInteraction.CreateFurniture(data);
    panel.SetActive(false);
}

private void OnSavePresetClicked()
{
    FurnitureData data = BuildFurnitureDataFromForm();
    presetManager.SavePreset(data);
    RefreshPresetDropdown();
}

불러오는 쪽은 드롭다운 하나 추가했다. 프리셋을 고르면 그 값들이 폼 필드에 그대로 채워지고, 이후 "생성"을 누르면 그 값 그대로 가구가 만들어진다.

드롭다운에서 "프리셋 책상" 선택 → 카테고리/치수/색상이 자동으로 채워진 상태

저장은 됐는데 티가 안 남

처음 만들고 테스트해보니, "프리셋으로 저장" 버튼을 눌러도 실제로는 잘 저장되는데 화면상 아무 반응이 없었다. 드롭다운을 직접 열어봐야만 저장된 걸 확인할 수 있는 상태 — 사용자 입장에선 버튼이 눌렸는지조차 알 수 없다.

버튼 텍스트를 저장 직후 잠깐 바꿔서 눈에 보이는 피드백을 줬다.

private void OnSavePresetClicked()
{
    FurnitureData data = BuildFurnitureDataFromForm();
    presetManager.SavePreset(data);
    RefreshPresetDropdown();
    presetDropdown.SetValueWithoutNotify(currentPresets.Count); // 방금 저장한 항목을 선택 표시

    savePresetButtonLabel.text = "저장됨!";
    Invoke(nameof(ResetSavePresetButtonLabel), 1f);
}

버튼 텍스트가 "저장됨!"으로 잠깐 바뀌었다가 1초 뒤 원래대로 돌아오고, 드롭다운도 방금 저장한 항목을 자동으로 선택한 상태로 바뀐다. 둘 다 딱히 무겁지 않은 처리라 Invoke 하나로 충분했다.

삽질 기록

라이더 경고, 다 고칠 필요는 없더라

이번 편을 진행하면서 라이더가 계속 "'null'과의 비교는 비용이 높습니다"를 띄웠는데, 하나씩 따라가다 보니 두 부류로 나뉘었다.

진짜 고쳐야 하는 것 :
CameraController.HandleFirstPersonInput()의 characterController != null, FurnitureInteraction.Update()의 cameraController != null — 둘 다 가드 없이 매 프레임 그대로 실행되는 코드였다. hasCharacterController/hasCameraController bool로 캐싱했다.

안 고쳐도 되는 것 :
HandleSelection() 안의 clicked == null, StartTransition()의 roomBuilder != null 같은 것들. 전부 Input.GetMouseButtonDown이나 모드 전환처럼 "가끔만 실행되는" 코드 안에 있어서, 캐싱해도 체감 이득이 없었다. clicked처럼 애초에 클릭마다 값이 달라지는 것들은 캐싱 자체가 불가능하기도 했다.

기준을 하나로 정리했다: 라이더는 코드가 실제로 매 프레임 도는지 모르고 정적으로만 판단해서 경고를 띄운다. "이 코드가 가드 없이 Update()에서 매 프레임 무조건 실행되는가"만 확인하면 고칠 가치가 있는지 바로 판단된다.

내가 낸 버그 하나 더

예전에 GridSnap을 매 프레임 FindAnyObjectByType로 다시 찾던 걸 캐싱하자고 제안했었는데, 이번에 다시 보니 Start()에 대입문(gridSnap = FindAnyObjectByType<GridSnap>();)만 있고 정작 private GridSnap gridSnap; 필드 선언이 없어서 컴파일 에러가 나 있었다. HandleDrag()도 여전히 예전 방식(매번 새로 찾기) 그대로였고. 필드 선언 추가하고 HandleDrag()가 캐싱된 필드를 쓰도록 마무리했다.

정리

기능	핵심 API / 구조
전역 가구 프리셋 저장	FurniturePresetManager + FurniturePresetList (JsonUtility 래퍼)
생성 폼 재사용	BuildFurnitureDataFromForm() 공통 헬퍼
저장 피드백	버튼 텍스트 일시 변경 + 드롭다운 자동 선택
Rider 캐싱 완료	hasCharacterController, hasCameraController, GridSnap 캐싱 마무리
다음 단계	레이아웃 비교 뷰(보류), Phase 6-2 모바일 배포(미정)

RoomCraft #19. 있는 척했던 기능 만들기 — 1인칭 시점

wan_ — Thu, 9 Jul 2026 10:56:32 +0900

소스코드 → github.com/Jywan/RoomCraft | 플레이 → jywan.github.io/RoomCraft

들어가며

README를 다시 읽다가 뜨끔했다. "주요 기능" 목록에 "탑뷰 ↔ 3D 자유시점 ↔ 1인칭 뷰"라고 적혀있었는데, 정작 CameraController의 CameraMode enum엔 TopView, FreeView 둘뿐이었다. 1인칭은 있는 척만 하고 실제로는 없었던 것. 이번 편에서 진짜로 만들었다.

시작 위치를 어디로 잡을까

제일 먼저 걸린 문제는 "1인칭으로 전환했을 때 카메라를 어디에 놓을 것인가"였다. 제일 쉬운 방법은 방 꼭짓점들의 평균(중심점)을 쓰는 건데, 이러면 L자형이나 지난번 만든 오목한 커스텀 방에서 그 중심점이 방 밖(파인 부분)에 떨어질 수 있다. 방 안에서 시작해야 할 카메라가 벽 밖에서 시작하는 꼴.

대신 이미 갖고 있던 도구를 재활용했다. 바닥을 만들 때 Ear Clipping으로 삼각분할을 해뒀으니, 그 삼각형 중 아무거나 하나를 골라 세 꼭짓점의 평균을 쓰면 된다. 삼각형의 무게중심은 어떤 모양의 삼각형이든 항상 그 삼각형 내부에 있다 — 그래서 방이 아무리 복잡한 모양이어도 결과값은 항상 바닥 위의 유효한 한 점이 된다.

// RoomBuilder.cs
public Vector3 GetFirstPersonSpawnPoint()
{
    if (currentRoomData == null) return Vector3.zero;

    List<Vector2> outline = currentRoomData.GetVertices();
    List<int> triangles = PolygonUtils.Triangulate(outline);

    Vector2 a = outline[triangles[0]];
    Vector2 b = outline[triangles[1]];
    Vector2 c = outline[triangles[2]];
    Vector2 centroid = (a + b + c) / 3f;

    return new Vector3(centroid.x, EyeHeight, centroid.y);
}

WASD로 걸어 다니기

기존 탑뷰/자유시점은 둘 다 targetPoint를 중심으로 카메라가 공전하는 방식이라 "이동"이라는 개념 자체가 없었다. 1인칭은 완전히 새로운 조작 방식이 필요했다 — WASD로 걷고, 마우스 드래그로 시점을 돌리는 흔한 1인칭 조작.

private void HandleFirstPersonInput()
{
    // 좌클릭 드래그로 시점 회전 (yaw/pitch)
    if (fpDragging)
    {
        Vector3 delta = Input.mousePosition - fpLastMousePosition;
        fpYaw += delta.x * lookSpeed * 0.1f;
        fpPitch -= delta.y * lookSpeed * 0.1f;
        fpPitch = Mathf.Clamp(fpPitch, -80f, 80f);
        transform.rotation = Quaternion.Euler(fpPitch, fpYaw, 0f);
    }

    // WASD 이동, Y는 고정해서 눈높이 유지
    Vector3 move = Vector3.zero;
    if (Input.GetKey(KeyCode.W)) move += transform.forward;
    if (Input.GetKey(KeyCode.S)) move -= transform.forward;
    if (Input.GetKey(KeyCode.A)) move -= transform.right;
    if (Input.GetKey(KeyCode.D)) move += transform.right;
    move.y = 0f;
}

탑뷰 ↔ 자유시점 ↔ 1인칭은 기존에 있던 T키 토글에 그대로 얹었다. 원래 2단 토글이던 ToggleView()를 3단 순환으로 바꿨다.

둘러보기 전용으로

1인칭에서도 가구를 선택하고 옮길 수 있게 할지 고민했는데, 마우스 드래그가 "시점 회전"과 "가구 드래그" 둘 다에 쓰이는 조작이라 겹치면 헷갈릴 게 뻔했다. 1인칭은 배치 결과를 둘러보는 용도로만 쓰고, 편집은 다시 탑뷰/자유시점으로 돌아가서 하는 걸로 정리했다.

// FurnitureInteraction.cs
private void Update()
{
    if (cameraController != null && cameraController.GetCurrentMode() == CameraMode.FirstPerson)
        return;

    HandleSelection();
    HandleDrag();
    HandleRotation();
    HandleDelete();
}

1인칭으로 들어가는 순간 기존에 선택되어 있던 가구도 강제로 선택 해제하도록 했다. 안 그러면 1인칭으로 걸어 다니는 동안에도 툴바에 회전/삭제 버튼이 떠 있는 상태로 남는다.

벽은 막고 가구는 통과 — CharacterController

처음엔 transform.position에 이동값을 그냥 더하는 방식으로 짰다. 당연히 벽을 그대로 뚫고 지나갔다. Unity의 CharacterController 컴포넌트를 카메라에 붙이고, 이동을 characterController.Move()로 바꿨다.

Vector3 delta = move.normalized * (moveSpeed * Time.deltaTime);
if (characterController != null)
    characterController.Move(delta);
else
    transform.position += delta;

재밌는 건 가구는 여전히 통과된다는 점이다. 가구 콜라이더가 선택/드래그 감지를 위해 isTrigger = true로 되어있는데, CharacterController는 트리거 콜라이더랑 충돌하지 않는다. 벽(일반 콜라이더)만 막고 가구는 통과되는 지금 상태가 결과적으로 딱 원하던 동작이라 그대로 뒀다.

1인칭 시점으로 본 방 구석 — 이제 진짜로 걸어 다닐 수 있다

삽질 기록

1인칭에서 영원히 못 빠져나옴

3단 순환으로 바꾸면서 조건 순서를 잘못 짰다.

else if (currentMode == CameraMode.FirstPerson)
    SwitchMode(CameraMode.FirstPerson);  // 자기 자신으로 전환

SwitchMode() 맨 앞줄이 "같은 모드면 무시"라서, 1인칭 상태에서 이 코드가 실행되면 아무 일도 안 일어난다. 즉 한번 1인칭에 들어가면 T키를 눌러도 계속 1인칭에 갇힌다. FreeView일 때 FirstPerson으로 가야 하는 걸 FirstPerson일 때 FirstPerson으로 가게 잘못 짠 것 — 조건 순서만 바로잡았다.

CharacterController 넣었는데 그래도 벽을 뚫음

코드도 고쳤고 컴파일도 되는데 여전히 벽을 통과했다. 씬 파일을 열어서 확인해보니 CharacterController 컴포넌트 자체가 Main Camera에 없었다 — 코드에 필드만 추가해뒀지, 실제로 Unity 에디터에서 컴포넌트를 추가하고 인스펙터 슬롯에 연결하는 걸 깜빡했던 것. characterController != null 체크가 조용히 폴백 경로(충돌 없는 예전 방식)로 빠지고 있었다.

코드가 컴파일된다고 기능이 다 붙은 게 아니다 — 특히 인스펙터에서 손으로 연결해야 하는 참조는 코드 리뷰만으론 못 잡는다.

Rider가 잡아준 것들

이번엔 라이더의 정적 분석 경고를 하나씩 따라가봤다. Camera.main을 Start()에서 캐싱(FurnitureInteraction에 이미 있던 패턴 재사용), 씬에 항상 존재하는 EventSystem.current의 불필요한 null 체크 제거, move.normalized * moveSpeed * Time.deltaTime처럼 벡터-스칼라 곱셈을 연쇄로 하던 걸 스칼라끼리 먼저 곱하고 벡터엔 한 번만 곱하도록(move.normalized * (moveSpeed * Time.deltaTime)) 순서를 바꿨다. 다만 자주 호출 안 되는 코드(모드 전환 시 한 번뿐인 StartTransition()의 null 체크 등)까지 전부 캐싱하지는 않았다 — 경고가 뜬다고 다 고칠 필요는 없고, 매 프레임 도는 코드인지가 기준이었다.

정리

기능	핵심 API / 구조
1인칭 시작 위치	RoomBuilder.GetFirstPersonSpawnPoint() — 삼각형 무게중심
WASD 이동 + 마우스룩	CameraController.HandleFirstPersonInput()
3단 시점 순환	ToggleView() — TopView → FreeView → FirstPerson
가구 상호작용 차단	FurnitureInteraction.Update() 모드 가드 + DeselectAll()
벽 충돌	CharacterController.Move() (가구는 트리거라 통과)
다음 단계	Phase 6-2 모바일 배포 (미정), WebGL 한글 입력 문제

RoomCraft #18. 첫 배포 — WebGL + GitHub Pages, 그리고 아직 못 고친 한글 버그

wan_ — Wed, 8 Jul 2026 18:40:25 +0900

소스코드 → github.com/Jywan/RoomCraft
플레이 → jywan.github.io/RoomCraft

들어가며

성능 정리까지 끝내고 나니 로드맵에 남은 게 배포뿐이었다. 지금까지는 전부 에디터 안에서만 돌아가던 걸, 이번에 처음으로 브라우저에서 아무나 접속해서 플레이할 수 있게 내보냈다. 무료로 되는 방법부터 찾다가 GitHub Pages로 정했고, 가는 길에 예상 못 한 버그를 두 개 만났다.

무료 배포처 고르기

WebGL 기준으로 무료 옵션 몇 개를 놓고 비교했다.

itch.io — 인디/하비 프로젝트 전시용으로 제일 무난한 선택지. zip만 올리면 끝
GitHub Pages — 이미 코드가 올라가 있는 repo에 그대로 붙일 수 있어서, 소스코드랑 플레이 가능한 데모가 한곳에 묶인다는 장점

소스코드 링크를 이미 포트폴리오에 걸어둔 상태라, GitHub Pages 쪽이 자연스러웠다.

WebGL로 내보내기

먼저 Unity Hub에서 WebGL Build Support 모듈을 설치해야 했다 (Player Settings에 WebGL 탭 자체가 안 보이면 이게 원인). 설치하고 나서 빌드 전에 설정 하나를 바꿨다.

Player Settings → Publishing Settings → Compression Format을 Disabled로 바꿨다. Unity WebGL 빌드는 기본적으로 압축(gzip/brotli)된 파일을 만드는데, 이걸 풀려면 서버가 Content-Encoding 응답 헤더를 붙여줘야 한다. GitHub Pages는 순수 정적 호스팅이라 그런 커스텀 헤더 설정이 안 되고, 압축 켠 채로 올리면 브라우저가 파일을 못 풀어서 게임이 그냥 안 열린다. 압축을 꺼서 용량은 좀 커지지만, 어떤 정적 호스팅에서도 별도 설정 없이 바로 동작한다.

빌드 결과물(index.html, Build/, TemplateData/)을 repo 루트의 docs/ 폴더에 넣고, GitHub repo 설정에서 Settings → Pages → Source를 main 브랜치의 /docs 폴더로 지정했다.

jywan.github.io/RoomCraft — 실제로 접속되는 화면

삽질 기록

배포했는데 404

설정 끝내고 접속했더니 흰 화면에 콘솔 에러만 떴다.

Failed to load resource: the server responded with a status of 404 ()
build.loader.js:1

git ls-files docs/로 확인해보니 docs/Build/ 폴더 자체가 커밋된 적이 없었다. 원인은 .gitignore에 있던 규칙 하나.

[Bb]uild/
[Bb]uilds/

Unity 프로젝트 템플릿에 원래 있던 규칙인데, 앞에 /가 없어서 경로 어디에 있든 이름이 Build/build인 폴더를 전부 무시해버린다. Unity 자체 빌드 산출물을 걸러내려던 규칙이 docs/Build/까지 같이 잡아먹은 것. 예외 규칙 한 줄로 풀었다.

!docs/Build/

덤으로 docs/Build/build.wasm이 55.64MB라 GitHub 권장 최대치(50MB)를 넘는다는 경고도 떴다. 차단 기준(100MB)보다는 작아서 일단 정상 푸시는 됐는데, 나중에 빌드가 더 커지면 Git LFS를 써야 할 수도 있다.

한글이 낱자로 깨져서 들어감

404를 고치고 다시 들어가서 방 이름에 "테스트방"을 입력했는데, 결과는 이랬다.

"테스트"라고 쳤는데 조합 전 낱자가 그대로 들어간다

에디터에서는 멀쩡히 되는데 WebGL에서만 이런다. 원인을 찾아보니 이건 내 코드 버그가 아니라 Unity WebGL 자체의 한계였다. 한글 입력은 자음/모음을 IME가 조합해서 완성된 글자를 넘겨주는 방식인데(compositionstart / update / end 이벤트), Unity WebGL의 키보드 입력은 브라우저의 keydown 이벤트를 그대로 받아서 처리한다. 조합이 끝나길 기다리지 않고 매 keydown마다 바로 글자를 넣어버리니, 조합 중이던 낱자가 그대로 노출되는 것.

제대로 고치려면 브라우저의 compositionend 이벤트를 직접 받아서 완성된 글자만 Unity로 넘기는 JS 플러그인이 필요해 보인다. WebGL 빌드 파이프라인에 커스텀 JS를 끼워 넣는 작업이라 이번 배포 범위에서 바로 끝낼 순 없었고, 일단 알려진 제약으로 기록해두고 다음에 시간 내서 방법을 찾아볼 생각이다.

정리

작업	핵심 내용
배포처	GitHub Pages (docs/ 폴더 기반)
WebGL 빌드 설정	Compression Format → Disabled (정적 호스팅 헤더 제약 회피)
404 버그	.gitignore의 [Bb]uild/ 규칙이 docs/Build/까지 무시 → 예외 규칙 추가
한글 입력 버그	Unity WebGL이 IME 조합을 못 기다림 — 알려진 제약으로 남김
다음 단계	Phase 6-2 모바일(Android/iOS) 빌드 배포

RoomCraft #17. 매 프레임 도는 코드 최적화하기 — 그리고 최적화하다 만든 버그

wan_ — Wed, 8 Jul 2026 13:28:50 +0900

소스코드 → github.com/Jywan/RoomCraft

들어가며

커스텀 방 편집이 end-to-end로 돌아가는 걸 확인하고 나니, 코드 여기저기 미뤄뒀던 게 눈에 밟혔다. 특히 가구를 드래그하는 동안 매 프레임 도는 코드들 — 처음 짤 때는 동작만 확인하면 됐지만, 쌓이고 보니 손볼 곳이 많았다. 이번 편은 화면엔 아무 변화도 없는 성능 정리 편이다. 그리고 최적화하다가 버그를 하나 새로 만든 이야기도 같이 있다.

안 쓰는 코드부터

Phase 5-3에서 그리드 셀 토글 방식을 버리고 점 클릭 방식으로 갈아탔었는데, 그 흔적인 CustomShapeEditorUI.cs, GridOutlineExtractor.cs, GridCell.prefab이 어디서도 참조되지 않은 채로 남아있었다. 씬/스크립트 전체를 검색해서 진짜 아무 데서도 안 쓰는 걸 확인하고 지웠다.

Unity의 == null은 공짜가 아니다

UnityEngine.Object를 상속한 타입(대부분의 컴포넌트)은 ==/!= 연산자가 오버로딩되어 있다. 단순 참조 비교가 아니라 네이티브 오브젝트가 실제로 살아있는지까지 확인하는 연산이라, 어쩌다 한 번이면 상관없는데 매 프레임 반복되면 쌓인다. 가구를 드래그하는 동안 이 비교가 한 프레임에 여러 번씩 실행되고 있었다.

FurnitureInteraction에서 selectedFurniture != null을 매번 계산하는 대신, 선택이 바뀌는 시점(선택/해제/삭제)에만 갱신되는 bool 하나를 두기로 했다.

private FurnitureObject selectedFurniture = null;
private bool hasSelection = false;

public bool HasSelection => hasSelection;

private void HandleDrag()
{
    if (!hasSelection || !isDragging) return;
    // ...
}

선택 여부를 밖에서(FurnitureToolbar, DimensionDisplay) 확인해야 할 때도 GetSelectedFurniture() != null 대신 이 HasSelection 프로퍼티를 읽도록 바꿨다. 값이 필요할 때만 GetSelectedFurniture()로 실제 레퍼런스를 가져오는 식이다.

같은 이유로 FurnitureBounds.IsOverlapping()에서 씬의 다른 가구와 자기 자신을 구분하려고 쓰던 other == furniture도 ReferenceEquals(other, furniture)로 바꿨다. 둘 다 null이 아닌 진짜 오브젝트끼리 비교하는 상황이라도, Unity의 ==는 여전히 오버로딩된 채로 호출된다 — ReferenceEquals는 그 오버로딩을 건너뛰고 순수 참조 비교만 한다.

매 프레임 씬을 통째로 뒤지고 있었다

== null 비용을 살펴보다가 더 큰 게 눈에 띄었다. FurnitureBounds.IsOverlapping()이 드래그 중 매 프레임 FindObjectsByType<FurnitureObject>()로 씬에 있는 가구를 전부 다시 찾고 있었다. 겹침 검사 하나 하려고 매 프레임 씬 전체를 스캔하는 셈이다.

FurnitureObject에 정적 리스트를 두고, 컴포넌트가 활성화/비활성화될 때 스스로 등록·해제하도록 바꿨다.

public static readonly List<FurnitureObject> All = new List<FurnitureObject>();

private void OnEnable() { All.Add(this); }
private void OnDisable() { All.Remove(this); }

IsOverlapping()은 이제 FindObjectsByType 대신 이 리스트를 순회한다. 생성/삭제 시점에만 리스트가 갱신되니 매 프레임 검색할 필요가 없다.

GetComponent 계열도 같은 문제였다. FurnitureBounds가 가구의 Collider, Renderer를 매번 GetComponent/GetComponentInChildren로 새로 찾고 있었는데, FurnitureObject.Initialize() 시점에 한 번만 찾아서 캐싱해두고 GetBounds()/GetRenderers()로 꺼내 쓰도록 바꿨다. 드래그 중 매 프레임 필요하던 컴포넌트 탐색이 전부 사라졌다.

가비지 컬렉션도 한번 보자

여기까지 하고 나니 할당 쪽도 궁금해졌다. 두 군데가 걸렸다.

첫째, IsInsideRoom()이 매 프레임 4칸짜리 Vector2[] 배열을 새로 만들고 있었다. 크기가 항상 고정이니 재사용 버퍼로 바꿨다.

private readonly Vector2[] cornerBuffer = new Vector2[4];

// 매번 새 배열을 만드는 대신, 기존 버퍼의 값만 갱신
cornerBuffer[0] = new Vector2(bounds.min.x, bounds.min.z);
cornerBuffer[1] = new Vector2(bounds.max.x, bounds.min.z);
cornerBuffer[2] = new Vector2(bounds.max.x, bounds.max.z);
cornerBuffer[3] = new Vector2(bounds.min.x, bounds.max.z);

둘째, DimensionDisplay.ShowInfo()가 가구 선택 중 매 프레임 문자열 보간($"...")으로 이름/치수/위치 텍스트를 다시 만들고 있었다. 위치가 그대로인 프레임에도 매번 새 문자열을 할당하고 있었던 것. 선택된 가구가 바뀔 때만 이름/치수를 갱신하고, 위치가 실제로 바뀔 때만 위치 텍스트를 갱신하도록 바꿨다. 가만히 선택만 하고 있으면 문자열 할당이 아예 없다.

기능 하나 끼워넣기: 높이 경계 검사

겸사겸사 미뤄뒀던 것도 하나 처리했다. FurnitureBounds.IsInsideRoom()이 지금까지 가로/세로(X/Z) 발자국만 검사하고, 가구 높이가 천장을 넘는지는 아예 체크하지 않고 있었다. SetRoomShape()가 방 높이도 같이 받도록 파라미터를 추가하고, 가구 콜라이더의 최고점이 천장을 넘으면 무효 처리하도록 했다.

public void SetRoomShape(List<Vector2> vertices, float height)
{
    roomOutLine = GetInsetPolygon(vertices, wallTickness);
    roomHeight = height;
}

public bool IsInsideRoom(FurnitureObject furniture)
{
    if (roomOutLine == null) return true;

    Bounds bounds = furniture.GetBounds();
    if (bounds.max.y > roomHeight) return false;
    // ...
}

삽질 기록

최적화하다가 만든 버그

위의 cornerBuffer 재사용 버퍼로 바꾸는 과정에서, 네 줄을 복사해서 인덱스만 바꾸다가 실수를 냈다. 인덱스 2, 3이 bounds.max.z를 써야 하는데 각각 인덱스 1, 0과 똑같은 bounds.min.z를 그대로 쓰고 있었다.

// 버그가 있던 버전
cornerBuffer[0] = new Vector2(bounds.min.x, bounds.min.z);
cornerBuffer[1] = new Vector2(bounds.max.x, bounds.min.z);
cornerBuffer[2] = new Vector2(bounds.max.x, bounds.min.z);  // bounds.max.z 여야 함
cornerBuffer[3] = new Vector2(bounds.min.x, bounds.min.z);  // bounds.max.z 여야 함

결과적으로 모서리 4개 중 2개가 나머지 2개랑 완전히 같은 값이 되어버려서, 가구 바운딩 박스의 실제 모서리는 2개만 검사되는 상태였다. 방 안쪽으로 튀어나온 모서리가 있어도 못 잡아내는 조용한 버그 — 겉으로는 잘 도는 것처럼 보이니 더 위험했다.

코드를 직접 적용하고 나서 다시 한 번 훑어보다가 발견했다. 반복되는 값을 손으로 네 줄 옮겨 적을 땐 항상 이런 실수가 나온다 — 다음부턴 이런 고정 크기 좌표 목록은 배열 리터럴을 유지하고 인덱스만 바꾸는 대신, 애초에 실수하기 어려운 형태로 짜는 게 나을 것 같다.

정리

작업	핵심 변경
미사용 코드 정리	박스 클리커 방식 잔재 3개 파일 삭제
Unity Object 비교 캐싱	hasSelection/hasBounds bool, ReferenceEquals
씬 검색/컴포넌트 조회 캐싱	FurnitureObject.All 레지스트리, GetBounds()/GetRenderers()
GC 할당 감소	버퍼 재사용, 값이 바뀔 때만 문자열 갱신
높이 경계 검사	FurnitureBounds.SetRoomShape(vertices, height)
다음 단계	Phase 6 WebGL/모바일 빌드 배포

RoomCraft #16. 방 모양 편집을 일반/커스텀 탭으로 - 그리고 버그 네 마리

wan_ — Tue, 7 Jul 2026 22:16:37 +0900

소스코드 → github.com/Jywan/RoomCraft

들어가며

지난 편에서 사각형/L자형 같은 프리셋 방 모양을 골라 쓸 수 있게 됐다. 근데 프리셋만으론 부족하다 — 어차피 사람마다 방 구조는 다 다르게 생겼으니까. 이번 편은 사용자가 원하는 모양을 직접 그리는 기능을 붙였는데, 이번 Phase는 유독 설계를 두 번이나 갈아엎었다. 그 과정이랑 최종적으로 잡은 버그 넷을 정리한다.

그리드 셀이냐, 점 클릭이냐

처음 떠올린 방식은 엑셀 표 만들듯이 N×M 그리드에서 원하는 칸을 켜고 끄는 거였다. 직관적이긴 한데, 만들다 보니 대각선으로만 맞닿은 두 칸을 어떻게 처리할지가 발목을 잡았다. 대각선 인접은 "붙어있다"고 봐야 할지 "떨어져있다"고 봐야 할지 애매하고, 그 경계선을 다각형 외곽선으로 뽑아내는 로직도 따로 필요했다.

그래서 방향을 바꿨다. 셀을 켜고 끄는 대신, 사용자가 꼭짓점을 순서대로 직접 클릭하게 하면 애초에 "외곽선을 추출하는" 단계 자체가 사라진다. 사용자가 찍은 점이 곧 꼭짓점이라 대각선 인접 문제도, 자기교차 방지도 훨씬 단순해진다. 대신 그리드 셀 토글용으로 만들어뒀던 CustomShapeEditorUI.cs, GridOutlineExtractor.cs는 그대로 미사용 코드로 남았다 (정리는 다음 과제).

점을 찍어서 방을 그린다

가로/세로를 입력하면 그 범위 안에 점 그리드가 깔린다. 점을 순서대로 클릭하면 이전 점과 선으로 이어지고, 3개 이상 찍은 다음 시작점 근처를 다시 클릭하면 도형이 닫힌다.

private void OnPointClicked(Vector2 pos)
{
    if (isClosed) return;

    if (clickedPoints.Count >= 3 && Vector2.Distance(pos, clickedPoints[0]) < snapCloseRadius)
    {
        DrawLine(clickedPoints[clickedPoints.Count - 1], clickedPoints[0]);
        isClosed = true;
        return;
    }

    if (clickedPoints.Count > 0)
        DrawLine(clickedPoints[clickedPoints.Count - 1], pos);

    clickedPoints.Add(pos);
}

점 간격은 처음엔 고정 픽셀값으로 계산했는데, 방 크기를 크게 입력하면 그리드 전체가 그리는 영역 밖으로 삐져나가는 문제가 있었다. 영역 크기에 맞춰 간격이 알아서 줄어들도록 고쳤다.

// 그리드가 GridArea보다 커지지 않도록 점 간격을 자동으로 축소
effectiveCellPx = cellPixelSize;
if (cols > 1)
    effectiveCellPx = Mathf.Min(effectiveCellPx, gridArea.rect.width / (cols - 1));
if (rows > 1)
    effectiveCellPx = Mathf.Min(effectiveCellPx, gridArea.rect.height / (rows - 1));

점을 실제 좌표(미터)로 변환하는 쪽도 똑같은 간격값을 써야 한다는 게 포인트였다. 그리드는 동적 간격으로 그려놓고 변환은 고정값을 쓰면 방 모양이 미묘하게 어긋난다 — 그려진 그대로의 비율을 유지하려면 변환식도 같은 기준을 따라가야 한다.

탭으로 통합하기

처음엔 "커스텀 방 만들기"를 메인 화면의 독립 버튼으로, 그리기 패널도 완전히 별개 팝업으로 만들었다. 그런데 애초 요청은 "새 프로젝트" 패널 안에서 일반 / 커스텀 탭으로 전환하는 구조였다 — 만드는 중에 그 방향을 놓쳤다가 다시 확인하고 구조를 되돌렸다.

탭 버튼 2개를 두고, 기존 입력 필드들은 NormalTabContent라는 컨테이너로 묶어서 한 번에 켜고 끌 수 있게 했다. 그리기 패널(CustomRoomPanel)은 별개 오브젝트로 두고 탭 전환 시 둘 중 하나만 보이도록 스크립트로 제어했다.

private void ShowNormalTab()
{
    normalTabContent.SetActive(true);
    customRoomPanel.ClosePanelExternally();
}

private void ShowCustomTab()
{
    normalTabContent.SetActive(false);
    customRoomPanel.OpenPanel();
    customRoomPanel.transform.SetAsLastSibling();
}

CustomRoomPanel은 원래 자기 완결적인 독립 패널로 설계해서 취소 버튼을 누르면 자기 자신만 닫히게 되어 있었다. 근데 탭 구조로 들어오면서 "커스텀 탭에서 취소를 누르면 새 프로젝트 패널 전체가 닫혀야" 자연스럽다. CustomRoomPanel 내부 로직은 그대로 두고, 버튼 레퍼런스만 밖으로 노출해서 StartSceneUI가 리스너 하나를 더 얹는 방식으로 풀었다.

// CustomRoomPanel.cs — 취소 버튼을 밖에서도 구독할 수 있게 노출
public Button CancelButton => cancelButton;

// StartSceneUI.cs — 새 프로젝트 패널을 통째로 닫는 리스너를 추가로 등록
customRoomPanel.CancelButton.onClick.AddListener(CloseNewProjectPanel);

새 프로젝트 패널의 일반 / 커스텀 탭

오목한 모양도 그대로

제일 확인해보고 싶었던 건 오목한(볼록하지 않은) 모양도 제대로 방이 되는지였다. 지난 편의 L자형은 미리 정해둔 6꼭짓점이었지만, 이번엔 사용자가 아무 모양이나 찍을 수 있으니 오목한 도형이 나오는 게 당연하다.

ㄷ자 모양으로 점을 찍어 도형을 닫은 상태

이 좌표를 그대로 EditorScene으로 넘겨서 방을 생성해봤다. Phase 5-1에서 만들어둔 Ear Clipping 삼각분할이 오목한 다각형도 처리하도록 짜여 있어서, 별도 예외 처리 없이 바로 파인 모양 그대로 방이 나왔다. 미리 구조를 다각형 기반으로 잡아둔 보람이 여기서도 나왔다.

실제로 생성된 방 — 그린 모양 그대로 파여 있다

삽질 기록

또 그 Layout Group

탭 구조로 바꾸면서 기존 입력 필드들을 NormalTabContent로 옮겼는데, NewProjectPanel에 예전부터 붙어있던 Vertical Layout Group + Content Size Fitter가 새 자식의 선호 크기를 0으로 계산해버렸다. NormalTabContent는 Layout Group이 없는 그냥 빈 컨테이너라 부모한테 보고할 크기가 없었던 것 — 결과적으로 패널 높이가 0으로 찌부러졌다.

이 패턴 벌써 몇 번째인지 모르겠다. Layout Group 자식 구성이 바뀔 때마다 똑같은 이유로 똑같이 터진다. 이번엔 애초에 필요 없어진 두 컴포넌트를 통째로 떼어내고 크기를 수동으로 되돌렸다.

첫 클릭은 무시당한다

커스텀 탭을 처음 열 때, 첫 클릭은 아무 반응이 없고 두 번째 클릭에야 패널이 떴다. 에러도 안 나서 한참 헤맸는데, 원인은 Unity의 Awake() 생명주기였다.

CustomRoomPanel 오브젝트를 씬에 비활성 상태로 저장해뒀었는데, 비활성 오브젝트는 Awake()가 호출되지 않는다. 첫 클릭에서 SetActive(true)를 부르는 순간이 바로 그 오브젝트가 태어나서 처음 활성화되는 시점이라, Unity가 그 자리에서 즉시 Awake()를 실행한다. 근데 그 Awake() 마지막 줄이 하필 panel.SetActive(false) — 방금 켠 걸 자기가 그 자리에서 바로 꺼버리는 거였다. 두 번째 클릭부턴 Awake()가 이미 실행된 뒤라 정상 동작했다.

해결: CustomRoomPanel을 씬에서 기본 활성화 상태로 저장. NewProjectPanel/LoadPanel도 원래 이렇게 활성 상태로 시작해서 런타임에 스스로 숨기는 방식이었는데, 유독 이 오브젝트만 미리 꺼둔 게 문제였다.

뒤에서 비쳐 보이는 메인 화면

커스텀 탭을 열면 뒤에 있던 타이틀 화면이랑 탭 버튼이 은은하게 비쳐 보였다. 그리는 순서(sibling order)와 배경 알파, 두 가지가 겹친 문제였다 — CustomRoomPanel이 형제 오브젝트들보다 먼저 그려지고 있었고, 배경 알파도 완전 불투명이 아니었다.

해결: 탭을 열 때 SetAsLastSibling()으로 맨 앞에 그리게 하고, 배경 알파를 1로 올렸다.

버튼이 패널 밖에 있었다

되돌리기/초기화/확인/취소 버튼을 처음 배치할 때 좌표를 감으로 넣었더니, 패널 높이(600)를 훌쩍 넘는 위치(-520, -560)에 놓여 있었다. 그리드 영역도 패널 경계를 살짝 벗어나 있었고. 결과적으로 버튼 4개가 화면에 아예 안 보이는 상태였다.

해결: 그리드 영역과 버튼들을 패널 안쪽 좌표로 재배치하고, 패널 자체 높이도 내용물에 맞춰 키웠다. 겸사겸사 그리드 영역을 패널 상단에 크게 두고 입력창/버튼을 그 아래로 내려서, 그리는 공간이 잘 보이게 레이아웃도 다시 짰다.

정리

기능	핵심 API / 구조
설계 방식 결정	그리드 셀 토글 방식 폐기 → 점 클릭 방식 채택 (대각선 인접 문제 회피)
점 클릭으로 다각형 그리기	CustomRoomPanel.OnPointClicked() + DrawLine()
그리드 오버플로우 방지	effectiveCellPx — 영역 크기에 맞춰 간격 동적 계산
일반/커스텀 탭 전환	StartSceneUI.ShowNormalTab() / ShowCustomTab()
오목한 커스텀 방 생성	기존 Ear Clipping 삼각분할 재사용, 별도 처리 불필요
다음 단계	미사용 잔재 코드(그리드 셀 클리커 흔적) 정리, 최적화 작업

RoomCraft #15. 방 모양 프리셋 — 사각형 넘어 L자형까지

wan_ — Sun, 5 Jul 2026 21:14:52 +0900

소스코드 → github.com/Jywan/RoomCraft

들어가며

지난 편에서 방을 다각형 기반으로 재구성했다. 겉으로는 사각형 방이 예전과 똑같이 나왔지만, 속은 "꼭짓점 리스트 하나만 던져주면 어떤 모양이든 만들어주는" 구조로 바뀌어 있었다. 이번 편은 그 구조 위에 실제로 L자형을 골라 쓸 수 있는 UI를 얹었다. 드디어 사각형이 아닌 방이 화면에 나온다.

방 모양 프리셋

모양 하나마다 "가로/세로를 받아서 꼭짓점을 어떻게 배치할지"만 정의하면 된다. 사각형은 원래 있던 대로, L자형은 우측 상단 사분면을 절반씩 잘라낸 6꼭짓점으로 만들었다.

public static List<Vector2> GetVertices(RoomShape shape, float width, float depth)
{
    switch (shape)
    {
        case RoomShape.LShape:
            return LShapeVertices(width, depth);
        default:
            return RectangleVertices(width, depth);
    }
}

// 우측 상단 사분면을 잘라낸 L자형 (6꼭짓점)
private static List<Vector2> LShapeVertices(float width, float depth)
{
    float halfW = width / 2f;
    float halfD = depth / 2f;
    return new List<Vector2>
    {
        new Vector2(-halfW, -halfD),
        new Vector2(halfW, -halfD),
        new Vector2(halfW, 0f),
        new Vector2(0f, 0f),
        new Vector2(0f, halfD),
        new Vector2(-halfW, halfD),
    };
}

이 리스트를 지난 편에 만든 RoomBuilder에 그대로 넘기면, 삼각분할이랑 벽 생성이 알아서 6개짜리 다각형에 맞춰 동작한다. 새로 만든 모양 하나 추가하는데 RoomBuilder 쪽은 한 줄도 안 건드렸다 — 지난 편에서 구조를 미리 바꿔둔 보람이 여기서 나왔다.

새 프로젝트 화면에 모양 선택 Dropdown을 추가하고, 선택한 값을 SessionData에 담아 EditorScene으로 넘겼다.

새 프로젝트 화면의 방 모양 Dropdown — 사각형 / L자형

경계 검사도 다각형 기준으로

모양을 실제로 노출하려니 미뤄뒀던 문제가 튀어나왔다. 가구가 방 밖으로 나갔는지 검사하는 FurnitureBounds가 아직도 사각형 바운딩 박스로만 검사하고 있었다 — 이대로면 L자형의 파인 부분에도 가구를 놓을 수 있게 된다. 눈으로는 L자인데 판정은 사각형인 셈.

점이 다각형 안에 있는지 판정하는 Ray Casting 알고리즘을 추가하고, 가구의 바운딩 박스 네 모서리가 전부 다각형 안에 있어야 유효하다고 판정하도록 바꿨다.

public static bool PointInPolygon(Vector2 point, List<Vector2> polygon)
{
    bool inside = false;
    int n = polygon.Count;

    for (int i = 0, j = n - 1; i < n; j = i++)
    {
        Vector2 pi = polygon[i];
        Vector2 pj = polygon[j];

        bool intersects = ((pi.y > point.y) != (pj.y > point.y)) &&
            (point.x < (pj.x - pi.x) * (point.y - pi.y) / (pj.y - pi.y) + pi.x);

        if (intersects)
            inside = !inside;
    }

    return inside;
}

"점에서 오른쪽으로 반직선을 그었을 때 다각형 변과 홀수 번 만나면 내부, 짝수 번 만나면 외부"라는 원리다. 벽 두께 보정도 사각형일 땐 그냥 가로/세로 절반에서 빼면 됐는데, 다각형은 그렇게 간단히 안 돼서 중심점 기준으로 각 꼭짓점을 살짝 안쪽으로 당기는 방식으로 근사했다.

실제로 만들어진 L자형 방 — 파인 부분엔 가구를 놓을 수 없다

삽질 기록

드롭다운 목록만 한글이 깨짐

Dropdown을 새로 만들고 옵션을 한글로 넣었는데, 접혀있을 때 보이는 글자는 멀쩡한데 펼쳤을 때 나오는 목록 글자만 깨져 나왔다. TMP Dropdown은 평소 보이는 라벨이랑 펼침 목록(Template)의 텍스트가 서로 다른 컴포넌트라, 목록 쪽(Item Label)이 한글 미지원 기본 폰트를 그대로 쓰고 있었던 것.

해결: Template → Viewport → Content → Item → Item Label까지 들어가서 폰트를 프로젝트에서 쓰는 한글 폰트로 교체.

메서드는 만들어놓고 호출을 안 함

Dropdown 옵션을 코드로 채워 넣는 SetupShapeDropdown()을 작성해놓고, Start()에서 호출하는 걸 깜빡했다. 그래서 Play 모드에서도 계속 Unity 기본 템플릿 옵션(Option A/B/C)이 나왔다 — 코드 리뷰할 때 함수 본문만 보고 "잘 짰네" 하고 넘어갔는데, 실제로 불려지는지까지 확인했어야 했다.

null 체크 방향이 반대로 됨

FurnitureBounds.IsInsideRoom()에 "방 모양 정보가 아직 없으면 일단 유효하다고 봐준다"는 안전장치를 넣으려다가, true 대신 false를 반환하게 잘못 타이핑했다. 이러면 정보가 없는 동안 모든 가구가 무조건 경계 밖으로 판정된다 — 의도랑 정반대인 코드.

다행히 실제 플레이 흐름에서는 방 생성 직후 바로 값이 채워져서 눈에 띄는 증상은 없었지만, 나중에 타이밍이 조금만 달라져도 바로 터질 수 있는 코드였다.

정리

기능	핵심 API / 구조
방 모양 프리셋	RoomShape enum + RoomShapePresets.GetVertices()
다각형 내부 판정	PolygonUtils.PointInPolygon() — Ray Casting
다각형 기준 경계 검사	FurnitureBounds.SetRoomShape() + 바운딩 박스 네 모서리 판정
모양 선택 UI	StartSceneUI의 ShapeDropdown → SessionData → EditorSceneLoader
다음 단계	Phase 5-3(커스텀 편집)은 그리드 셀 선택 방식으로 진행 예정

RoomCraft #14. 방을 다각형으로 - 사각형을 넘어서기 위한 첫걸음

wan_ — Sun, 5 Jul 2026 18:09:10 +0900

소스코드 → github.com/Jywan/RoomCraft

들어가며

지난 편에서 버그 두 개 잡고 가구 정보 패널을 통합했다. 이번엔 로드맵 순서를 좀 바꿨다 — 원래 다음 순서는 WebGL/모바일 배포였는데, 아직 최적화도 안 끝난 상태에서 배포부터 준비하는 게 이상해서 그건 맨 뒤로 미루고, 대신 L자형 방 같은 다양한 방 모양 지원을 먼저 하기로 했다.

근데 이게 생각보다 큰 작업이라, 세 단계로 나눴다.

다각형 기반 방 생성 (이번 편) — 바닥/벽을 사각형 전용이 아니라 어떤 모양이든 처리할 수 있게 구조 변경
프리셋 모양 선택 — 사각형/L자형 같은 미리 정의된 모양을 UI에서 고르기
커스텀 편집 — 사용자가 직접 꼭짓점을 찍어서 모양 만들기

이번 편은 1번만 다룬다. 겉으로는 사각형 방이 예전이랑 똑같이 나오는데, 속은 완전히 갈아엎었다.

사각형 전용 구조의 한계

원래 RoomData는 가로/세로만 갖고 있고, RoomBuilder는 그 값으로 바닥 큐브 하나 + 벽 4개를 축에 맞춰 딱 찍어내는 구조였다. L자형이나 커스텀 모양을 넣으려면 이 자체를 바꿔야 했다 — "사각형"도 "L자형"도 결국 꼭짓점 리스트 하나 던져주면 바닥+벽을 만들어주는 함수 위에서 처리하는 게 맞다.

RoomData — 꼭짓점 리스트 추가

기존 저장 파일이랑 호환되게, vertices가 없으면 width/depth로 사각형을 자동 생성하는 GetVertices()를 만들었다.

public List<Vector2> GetVertices()
{
    if (vertices != null && vertices.Count >= 3)
        return vertices;

    float halfW = width / 2f;
    float halfD = depth / 2f;
    return new List<Vector2>
    {
        new Vector2(-halfW, -halfD),
        new Vector2(halfW, -halfD),
        new Vector2(halfW, halfD),
        new Vector2(-halfW, halfD)
    };
}

Ear Clipping — 다각형을 삼각형으로 쪼개기

바닥을 렌더링하려면 다각형을 삼각형들로 쪼개야 한다(GPU는 삼각형만 그릴 수 있으니까). 사각형이야 대각선 하나 그으면 끝이지만, L자형 같은 오목한 모양은 그렇게 간단하지 않다. Ear Clipping이라는 표준 알고리즘을 직접 구현했다 — 원리는 "다른 꼭짓점을 포함하지 않는 볼록한 삼각형(귀, ear)을 하나씩 잘라내면서 다각형을 줄여나간다"는 것.

public static List<int> Triangulate(List<Vector2> polygon)
{
    List<int> indices = new List<int>();
    List<Vector2> points = new List<Vector2>(polygon);

    // Ear Clipping은 반시계방향(CCW) 기준이라, 시계방향이면 뒤집는다
    if (SignedArea(points) < 0f)
        points.Reverse();

    List<int> remaining = new List<int>();
    for (int i = 0; i < points.Count; i++)
        remaining.Add(i);

    while (remaining.Count > 3)
    {
        // 볼록하고, 다른 점을 안 품고 있는 삼각형(귀)을 찾아서 잘라낸다
        // (본문 생략, 전체 코드는 PolygonUtils.cs 참고)
    }

    return indices;
}

삼각형 판정에 외적(cross product)을 두 군데 쓴다 — 세 점이 볼록한지 확인할 때, 그리고 어떤 점이 삼각형 안에 있는지 확인할 때. 둘 다 같은 Cross() 함수 하나로 처리했다.

RoomBuilder — 바닥은 메쉬, 벽은 변마다 하나씩

바닥은 삼각분할한 결과로 커스텀 Mesh를 만든다. 벽은 예전처럼 앞/뒤/좌/우 4개를 하드코딩하는 대신, 꼭짓점을 순서대로 돌면서 변(edge)마다 벽 하나씩 자동으로 생성한다.

private void CreateWalls(RoomData data, List<Vector2> outline)
{
    float wallThickness = 0.1f;
    for (int i = 0; i < outline.Count; i++)
    {
        Vector2 start = outline[i];
        Vector2 end = outline[(i + 1) % outline.Count];
        CreateWallSegment($"Wall_{i}", data, start, end, wallThickness);
    }
}

사각형이면 꼭짓점 4개라 벽 4개, L자형이면 꼭짓점 6개라 벽 6개가 자동으로 나온다. 벽 하나의 회전각은 시작점→끝점 방향 벡터로 계산한다.

float dx = end.x - start.x;
float dz = end.y - start.y;
float angle = Mathf.Atan2(-dz, dx) * Mathf.Rad2Deg;

Unity의 Y축 회전은 로컬 X축을 월드 (cosθ, 0, -sinθ)로 매핑한다. 벽의 "긴 방향"(로컬 X)을 변의 방향과 맞추려고 이 관계를 거꾸로 풀어서 각도를 구했다.

삽질 기록

엉뚱한 Vector2를 참조해서 난 컴파일 에러

PolygonUtils.cs 맨 위에 using System.Numerics;를 썼는데, 이러면 Vector2가 Unity 타입이 아니라 .NET의 System.Numerics.Vector2로 잡힌다. 그 타입은 필드가 X/Y(대문자)라서, 코드에 있던 .x/.y가 전부 존재하지 않는 멤버가 돼서 컴파일이 안 됐다.

해결: using UnityEngine;으로 수정. using문 하나 잘못 쓴 걸로 타입 전체가 바뀌어버리는 걸 직접 겪어봤다.

사각형이 나비 모양으로 꼬임

GetVertices()의 사각형 기본값을 만들 때 꼭짓점 순서를 잘못 넣어서, 테두리를 따라 도는 게 아니라 대각선으로 교차하는 형태가 됐다. Ear Clipping은 자기교차 없는 단순 다각형을 전제로 하는 알고리즘이라 이대로면 바닥이 이상하게 나온다.

해결: 꼭짓점을 테두리 순서(좌하→우하→우상→좌상)대로 나열하도록 수정.

바닥이 마젠타로 렌더링됨

컴파일 에러 다 잡고 실행해봤더니 바닥이 새빨간 마젠타색으로 나왔다. Unity에서 마젠타는 "머티리얼(셰이더)이 없다"는 에러 표시다.

바닥이 마젠타로 렌더링된 모습 — Unity의 "머티리얼 없음" 표시

알고 보니 Floor Material/Wall Material이 애초에 할당돼 있지 않았다. 예전엔 GameObject.CreatePrimitive(PrimitiveType.Cube)로 바닥/벽을 만들어서, Unity가 자동으로 기본 머티리얼을 붙여줬던 것 — 그래서 머티리얼을 안 넣어도 티가 안 났다. 이번에 바닥을 커스텀 Mesh + AddComponent<MeshRenderer>() 방식으로 바꾸면서, 그 자동 할당이 없어져서 진짜 "머티리얼 없음" 상태가 그대로 드러난 거였다.

해결: URP Lit 셰이더로 머티리얼을 새로 만들어서 Floor Material/Wall Material에 연결. 벽도 사실 지금까지 "우연히" 기본 머티리얼로 굴러가고 있었던 거라, 이 참에 제대로 된 머티리얼로 교체했다.

바닥과 가구가 겹치는 곳에서 깜빡임

머티리얼까지 고치고 나니 이번엔 바닥 위에 가구를 올려둔 자리가 지지직거리며 깜빡였다. Z-파이팅이라는 현상인데, 바닥 메쉬와 가구 밑면이 둘 다 Y=0에 정확히 겹쳐서 렌더러가 어느 게 앞인지 매 프레임 헷갈려하며 생기는 깜빡임이다. 예전 큐브 바닥은 두께(0.1m)가 있어서 잘 안 드러났는데, 지금은 두께 없는 평면이라 바로 티가 났다.

해결: 바닥을 Y = -0.01로 살짝 내려서 가구 밑면이랑 안 겹치게 했다.

정리

기능	핵심 API / 구조
꼭짓점 기반 방 데이터	RoomData.vertices + GetVertices() (하위호환용 사각형 fallback)
다각형 삼각분할	PolygonUtils.Triangulate() — Ear Clipping
바닥 메쉬 생성	Mesh + MeshFilter/MeshRenderer/MeshCollider
벽 자동 생성	꼭짓점 순회하며 변마다 CreateWallSegment() 호출, Atan2로 회전각 계산
마젠타 버그 수정	URP Lit 머티리얼 생성 후 Floor/Wall Material 연결
Z-파이팅 수정	바닥 Y 위치를 -0.01로 오프셋

RoomCraft #13. 버그 두 개 잡고 가구 정보 패널 통합하기

wan_ — Sun, 5 Jul 2026 15:33:01 +0900

소스코드 → github.com/Jywan/RoomCraft

들어가며

지난 편에서 룸/가구 툴바를 나누고 색상 피커를 만들었다. 이번엔 새 기능보다 버그 두 개를 잡는 게 메인이었고, 그 김에 가구 선택했을 때 뜨는 정보 패널들(치수 표시, 회전/삭제 버튼)을 하나로 합치고 회전도 더 세밀하게 조절할 수 있게 슬라이더를 추가했다.

버그 1 — 방 크기를 바꿔도 예전 경계로 검사됨

테스트로 가로 10m, 세로 5m짜리 방을 만들고 침대를 옮겨봤는데, 벽 근처에 가지도 않았는데 가구가 빨갛게(경계 이탈 경고) 변했다.

벽까지 한참 남았는데 이미 경계 이탈로 판정된 모습

원인을 찾아보니 어이없게도 FurnitureBounds.SetRoomSize()가 코드 어디에서도 호출되지 않고 있었다. RoomBuilder.BuildRoom()은 바닥/벽을 실제로 만들어주지만, 그거랑 별개로 FurnitureBounds한테 "방 크기가 이거다"라고 알려주는 코드가 빠져있던 것. 그래서 항상 인스펙터에 박제된 기본값(4m×3m) 기준으로 경계 검사가 되고 있었다. 기본값이랑 다른 크기로 방을 만들 때만 재현되는 버그라 여태 못 보고 지나갔던 거였다.

private void UpdateFurnitureBounds(RoomData roomData)
{
    FurnitureBounds bounds = FindAnyObjectByType<FurnitureBounds>();
    if (bounds != null)
        bounds.SetRoomSize(roomData.width, roomData.depth);
}

EditorSceneLoader의 HandleNewProject(), HandleLoadProject() 양쪽 다 방 생성/복원 직후 이 메서드를 호출하도록 고쳤다.

참고로 SetRoomSize는 가로/세로만 받는다. IsInsideRoom()이 X/Z 평면(탑뷰 기준 발자국)만 검사하고 높이(Y)는 아예 체크 안 하기 때문 — 가구가 항상 바닥(Y=0)에 고정이라 지금까진 필요 없었다. 나중에 천장 높이 검사도 넣고 싶으면 그건 완전히 새로 추가해야 하는 부분이라 일단 추후 예정으로 남겨뒀다.

버그 2 — 3D 뷰에서 가구 드래그하면 카메라도 같이 돎

FreeView(3D 자유시점)에서 가구를 클릭+드래그해서 옮기면, 화면(카메라)도 같이 회전해버리는 문제가 있었다. CameraController가 좌클릭 시작할 때 EventSystem.IsPointerOverGameObject()로 UI 위 클릭인지만 체크하고 있었는데, 가구는 UI가 아니라 3D 오브젝트라 이 체크에 안 걸렸던 것. 그래서 가구를 클릭하면 FurnitureInteraction은 가구를 옮기고, 동시에 CameraController도 카메라 회전을 시작해버렸다.

private bool IsPointerOverFurniture()
{
    Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition);
    return Physics.Raycast(ray, 100f, furnitureLayer);
}

FurnitureInteraction의 선택 상태를 참조하는 대신, CameraController가 자체적으로 Raycast를 쏴서 확인하게 했다. 두 스크립트의 Update() 실행 순서가 보장 안 되기 때문에, 서로 상태를 참조하면 프레임에 따라 타이밍이 꼬일 수 있어서다.

가구 정보 패널 통합 + 회전 슬라이더

가구를 선택하면 뜨는 UI가 치수 표시 패널, 회전/삭제 버튼 패널로 따로 떨어져 있었는데 이번에 하나로 합쳤다. 화면 우측 중앙에 고정해두고, 이름/치수/위치 텍스트 + 카테고리 아이콘 + 회전 슬라이더 + 회전/삭제 버튼이 전부 한 패널에 뜨도록 만들었다.

절대각 회전 — 슬라이더로 0~360도 자유롭게

기존 Q/E 키는 45도씩 상대회전만 됐는데, 정밀하게 원하는 각도로 맞추고 싶을 때가 있어서 슬라이더를 추가했다. 상대회전(RotateBy)이랑 별개로 절대각을 지정하는 메서드가 필요했다.

public void SetRotationY(float angleY)
{
    transform.rotation = Quaternion.Euler(0f, angleY, 0f);
}

public float GetRotationY()
{
    return transform.eulerAngles.y;
}

슬라이더를 드래그하면 이 각도로 바로 회전시키고, 반대로 Q/E나 회전 버튼으로 돌렸을 때도 슬라이더가 그 각도를 따라가도록 매 프레임 동기화했다.

private void Update()
{
    FurnitureObject selected =
        furnitureInteraction != null ? furnitureInteraction.GetSelectedFurniture() : null;

    bool hasSelection = selected != null;
    panel.SetActive(hasSelection);

    if (hasSelection)
    {
        UpdatePreview(selected);
        rotationSlider.SetValueWithoutNotify(selected.GetRotationY());
    }
}

SetValueWithoutNotify라서 무한루프(슬라이더→회전→슬라이더…) 걱정은 없다. 참고로 슬라이더를 360도 끝까지 밀면 핸들이 다시 0으로 스냅되는데, 이건 버그가 아니라 정상이다 — 360도랑 0도는 같은 방향이라 transform.eulerAngles.y가 항상 0~360 범위로 정규화돼서 그렇다.

우측 중앙에 고정된 통합 패널 — 치수/미리보기/회전 슬라이더/버튼이 한 곳에

삽질 기록

가구 선택 즉시 텍스트가 한 프레임 안 보임

치수 표시 패널을 회전/삭제 버튼 패널이랑 합치는 과정에서, 가구를 선택한 첫 프레임에 이름/치수/위치 텍스트가 안 보이는 현상이 있었다. 아이콘, 버튼, 슬라이더는 다 뜨는데 텍스트 줄만 사라진 것처럼 보였다.

원인은 Content Size Fitter 타이밍 문제였다. 텍스트를 담은 DimensionRow가 Content Size Fitter로 내용 길이에 맞춰 자동 크기 조절되는데, panel.SetActive(true)로 막 활성화된 그 프레임에는 아직 텍스트가 실제로 반영되기 전이라 크기가 0으로 계산돼버렸다. 그래서 첫 프레임엔 접혀서 안 보이고, 다음 프레임부터 정상 크기로 나왔던 것.

해결: 텍스트 설정 직후 LayoutRebuilder.ForceRebuildLayoutImmediate(panel.GetComponent<RectTransform>())를 호출해서 레이아웃을 그 자리에서 강제로 다시 계산시켰다.

다른 패널이랑 스타일이 안 맞음

회전/삭제 버튼 패널이 원래 배경 없는 빈 오브젝트였는데, 다른 팝업들(가구 생성 패널, 하단 툴바)은 다 어두운 배경 박스가 있어서 통일감이 없었다. Image 컴포넌트를 추가하고 색상/스프라이트를 다른 패널이랑 맞췄는데, 그러고 나니 내용물(텍스트+슬라이더+버튼)이 배경보다 커져서 잘리는 문제가 또 나왔다. Layout Group은 자기 크기를 안 키워준다는 그 교훈이 여기서도 그대로 적용됐다 — Content Size Fitter를 이 패널에도 추가하고 나서야 배경이 내용물 크기에 맞춰 자동으로 늘어났다.

정리

기능	핵심 API / 구조
방 크기 반영 버그 수정	EditorSceneLoader.UpdateFurnitureBounds() — 방 생성/복원 직후 FurnitureBounds.SetRoomSize() 호출
카메라-가구 드래그 충돌 수정	CameraController.IsPointerOverFurniture() — 가구 레이어 Raycast로 선체크
절대각 회전	FurnitureObject.SetRotationY() / GetRotationY()
회전 슬라이더 동기화	Slider.SetValueWithoutNotify()로 양방향 동기화
가구 정보 패널 통합	FurnitureToolsPanel 하나로 치수/미리보기/회전/삭제 통합, 화면 우측 중앙 고정
레이아웃 첫 프레임 버그 수정	LayoutRebuilder.ForceRebuildLayoutImmediate()