슬로우도파민

[겜만들기] 0. 겜만들기 시작

슬로우도파민 — Mon, 11 May 2026 00:02:32 +0900

N 번째 시도이지만, 다시 한 번 시도합니다.

저녁으로 엄청 매운 국물 닭발 먹어서,

지금 못할 게 없는 상태입니다.

이번에도 예전에 시도했던 방식처럼,

시작 - 목적 - 끝

이 있는 최소 단위의 버전을 먼저 구현해 놓고

이걸 더 재밌게 더 재밌게 업그레이드 하는 방식으로 해볼 생각입니다.

사실 이 방식은 제가 일할 때도 자주 떠올리는 방식입니다.

이유는...

저에게는 아주 작은 완벽주의자 성향이 있어서...

뭐 디자인이나 연출 같은거에 빠지면 다음 단계로 잘 못넘어가더라구요..

그래서 다른 분들께 보여줄 수 있는 최소 단위의 버전을 만드는 것을 먼저 목표로 하곤 합니다.

'이 버전 다른 사람들한테 보여줄 수 있어?' 를

작업 하면서 계속 스스로에게 묻는거죠.

이 질문을 계속 하다 보면
폰트 사이즈가 조금 어색한 것,
버튼 위치가 완벽하지 않은 것,
연출이 아직 덜 예쁜 것은 일단 넘기고

우선 기능부터 다 완성하게 됩니다.

뭐 그래서 이 방법론으로 게임을 하나 만들어볼 것입니다.

플랫폼은 모바일.
탑다운 액션으로

뱀서라이크 종류 게임으로 생각 중입니다.

뱀파이어 서바이버즈

일단은 캐릭터가 움직이고,
적이 등장하고,
목적지까지 도달하는 아주 작은 구조부터 만들어볼 예정입니다.

그럼 화이팅.

개발자는 코드나 쓰자.

슬로우도파민 — Sun, 3 May 2026 16:30:53 +0900

네.

저는 개발자입니다.

빅뱅이론 쉘든

AI가 과거(무려 1-2년 전) 개발의 많은 부분들을 감사하게도(ㅠㅠ?) 담당해주고 있어서

저는 이제 조금씩 코드가 아닌 글도 써보려고 합니다.

절대 코드를 잘 못써서는 아닙니다.ㅎㅎㅎㅎ

커서, 클로드 그리고 나 (by GPT)

아마도 앞으로 쓰게 될 글에는

AI와 함께 급변하는 시대에서
저와 같은 모든 청년들의 고민과 돌파구를 담은 내용들이 많을 것 같습니다.

일단 조금 더 제 소개를 하자면,

저는 Unity 개발자로 3년 정도의 경력이 있고요.

1년 넘게 원하지만 원하지 않는 백수 생활을 하다가

현재는 게임 회사에 재직하고 있습니다.

22년 말에 OpenAI의 ChatGPT가 공개되고,

몇년 있다가 희망퇴직을 통해 회사에서 정리(?)를 당했구요.

그간 겪었던 혼자만의 시간, 행복, 고통 모두 다

글에서 함께 공유해볼 수 있을 것 같습니다.

그럼 다음 글에서 봬요!

벡터 내적 활용 : 몬스터가 캐릭터 시야에 있는지 확인하기(Field of View)

슬로우도파민 — Sat, 3 Jan 2026 14:33:26 +0900

게임에서 캐릭터(또는 카메라)가 어떤 방향을 보고 있을 때, 특정 대상이 내가 보는 방향의 앞쪽 시야(FOV, Field of View) 안에 들어오는지 판단해야 하는 경우가 많습니다.

시야 안에 들어오는지 여부 판단

예를 들면:

적이 내 시야 안에 들어오면 경고 UI 띄우기
NPC가 플레이어를 “봤는지” 판정하기
자동 조준에서 “가장 내 정면에 가까운 대상” 찾기

이때 가장 간단하고 빠르게 쓰는 방법이 벡터 내적(Dot product) 입니다.

핵심 아이디어: “각도” 대신 “코사인”을 비교한다

1) 두 방향 벡터를 준비한다

f: 내가 바라보는 방향(Forward)
d: 나에서 대상까지의 방향(Direction to target)

예시로는 보통 이렇게 만듭니다:

f = (내 forward 방향)
d = (대상 위치 - 내 위치)

2) 둘 다 정규화(normalize) 한다

정규화란 벡터의 길이를 1로 만드는 것입니다.

정규화된 벡터는 “방향”만 남습니다.
이 작업을 해야 내적 값이 각도의 코사인(cos) 이라는 깔끔한 형태가 됩니다.

정규화한 뒤에는 다음이 성립합니다.

Dot(f, d) = cos(θ)
(θ는 f와 d 사이의 각도)

Dot 값은 무엇을 의미할까?

정규화된 상태에서 내적은 “얼마나 같은 방향인가”를 나타냅니다.

Dot = 1 → 각도 0° (완전히 정면)
Dot = 0 → 각도 90° (옆)
Dot = -1 → 각도 180° (정반대)

즉, Dot 값이 클수록 정면에 가깝다는 뜻입니다.

FOV(시야각) 판정은 왜 cos(FOV/2) 인가?

시야각 FOV는 보통 “좌우로 벌어진 전체 각도”입니다.

예를 들어 FOV가 60°라면, 정면을 기준으로:

왼쪽 30°
오른쪽 30°

즉, 경계선은 정면 기준 ±(FOV/2) 입니다.

따라서 대상이 시야 안에 있으려면:

대상과 정면 사이의 각도 θ가 FOV/2 보다 작거나 같아야 합니다.

수학으로 쓰면:

θ ≤ FOV/2

그런데 게임에서는 보통 각도 계산(acos) 을 피합니다.

(acos는 상대적으로 비용이 크고, 불필요한 경우가 많습니다)

대신 코사인을 이용해 이렇게 바꿉니다:

cos(θ) ≥ cos(FOV/2)

정규화된 벡터에서 cos(θ)가 바로 Dot(f, d) 이므로 최종적으로:

Dot(f, d) ≥ cos(FOV/2)

이 조건이면 대상은 시야각 안에 있습니다.

직관적으로 이해하기

Dot(f, d)는 “대상이 내 정면에 얼마나 붙어있나” 점수입니다.
FOV가 좁을수록 경계( cos(FOV/2) )가 1에 가까워져서 조건이 빡빡해집니다.
FOV가 넓을수록 경계가 작아져서(예: 0.5, 0.0에 가까워짐) 더 넓게 허용됩니다.

예시:

FOV = 60° → FOV/2 = 30° → cos(30°) ≈ 0.866
- Dot이 0.866 이상이면 “시야 안”
FOV = 120° → FOV/2 = 60° → cos(60°) = 0.5
- Dot이 0.5 이상이면 “시야 안”

[C# 이해하기] 얕은 복사(Shallow Copy)와 깊은 복사(Deep Copy)

슬로우도파민 — Sat, 3 Jan 2026 10:45:35 +0900

“복사”라고 하면 보통 “완전히 똑같은 걸 하나 더 만든다”를 떠올립니다.

하지만 C#에서 복사는 생각보다 단순하지 않습니다. 왜냐하면 객체 안에 또 다른 객체(참조형)가 들어있을 수 있기 때문입니다.

그래서 복사에는 크게 두 가지가 있습니다.

얕은 복사(Shallow Copy): 겉은 새로 만들지만, 안쪽 참조는 그대로 공유
깊은 복사(Deep Copy): 안쪽 참조까지 새로 만들어 완전히 독립

1) 먼저, “복사 문제”가 왜 생기나?

값 형식(int, float 등)은 복사하면 그냥 값이 복사되니 직관적입니다.

문제는 참조 형식(class, 배열, List 등)입니다.

참조 형식의 객체는 “겉(객체)” 안에 필드들이 있고, 그 필드 중 일부가 또 다른 객체를 가리킬 수 있습니다.

즉, 이런 구조가 가능합니다.

Player 객체
- Level (int)
- Inventory (int[] 배열) ← 또 다른 참조형

이때 “Player를 복사했다”는 말이 Inventory도 새로 복사했다는 뜻인지가 애매해집니다.

이 애매함을 정리한 개념이 얕은 복사/깊은 복사입니다.

2) 정의

얕은 복사: “겉 껍데기만 새로 만들고, 내부의 참조형은 같이 쓴다”
깊은 복사: “내부의 참조형까지 새로 만들어서, 완전히 따로 쓴다”

3) 얕은 복사 예시: 겉은 둘, 속은 공유

class Player
{
    public int Level;
    public int[] Inventory; // 참조형(배열)
}

var p1 = new Player { Level = 1, Inventory = new[] { 10, 20 } };

// 얕은 복사(의미): Player는 새로 만들었지만 Inventory는 공유
var p2 = new Player { Level = p1.Level, Inventory = p1.Inventory };

p2.Level = 99;         // p2의 값 필드만 변경
p2.Inventory[0] = 777; // 공유된 배열을 변경

Console.WriteLine(p1.Level);        // 1   (영향 없음)
Console.WriteLine(p1.Inventory[0]); // 777 (영향 있음)

왜 이런 일이 생길까?

Inventory는 배열이고(참조형), p1.Inventory를 그대로 넣으면 p2.Inventory도 같은 배열을 가리키게 됩니다.

4) 깊은 복사 예시: 내부까지 새로 만들어 독립

var p3 = new Player
{
    Level = p1.Level,
    Inventory = (int[])p1.Inventory.Clone() // 배열 자체를 새로 복사
};

p3.Inventory[0] = 123;

Console.WriteLine(p1.Inventory[0]); // 777 (p3와 무관)
Console.WriteLine(p3.Inventory[0]); // 123

여기서는 Inventory 배열도 새로 만들었기 때문에, p3는 p1과 독립적입니다.

5) 심화 : “Clone() 했는데도 공유가 남는 경우”

배열이 int[]처럼 값형을 담으면 Clone()이 꽤 안전합니다.

그런데 배열이 Item[]처럼 참조형 객체를 담는 배열이면 얘기가 달라집니다.

class Item { public string Name; }
class Bag  { public Item[] Items; }

var b1 = new Bag { Items = new[] { new Item { Name = "Potion" } } };
var b2 = new Bag { Items = (Item[])b1.Items.Clone() }; // 배열만 새로, Item은 공유

b2.Items[0].Name = "Elixir";

Console.WriteLine(b1.Items[0].Name); // Elixir (같이 바뀜)

여기서 Clone()은 “배열”은 새로 만들지만, 배열 안의 Item 객체까지 새로 만들지는 않습니다.

그래서 b1.Items[0]과 b2.Items[0]이 같은 Item 객체를 가리키는 공유 상태가 됩니다.

“진짜 깊은 복사”로 고치면 이렇게 됩니다

배열만 복사하지 말고, 각 Item도 새로 만들어 담아야 합니다.

var b3 = new Bag
{
    Items = b1.Items.Select(item => new Item { Name = item.Name }).ToArray()
};

b3.Items[0].Name = "Elixir";

Console.WriteLine(b1.Items[0].Name); // Potion  ← 안 바뀜
Console.WriteLine(b3.Items[0].Name); // Elixir

핵심은 이 한 줄입니다.

얕은 복사: Items = (Item[])b1.Items.Clone() (Item 공유)
깊은 복사: Items = b1.Items.Select(item => new Item{...}).ToArray() (Item도 복제)

“배열 요소가 값형이면?”

만약 Items가 int[] 같은 값형 배열이라면, Clone()만으로도 사실상 깊은 복사처럼 동작합니다.

왜냐하면 요소 자체가 값이라 “참조 공유”라는 문제가 없기 때문입니다.

int[] → Clone()이면 요소 값이 그대로 복사(안전)
Item[] → Clone()이면 요소 “참조”가 그대로 복사(공유 위험)

6) 언제 얕은 복사가 문제이고, 언제 괜찮나?

얕은 복사가 “나쁘다”가 아니라, 공유가 의도와 맞는지가 중요합니다.

얕은 복사가 위험해지는 경우

복사본을 수정했는데 원본도 같이 바뀌면 버그가 되는 상황

얕은 복사가 오히려 좋은 경우

큰 데이터를 매번 복사하면 비용이 커서, 읽기 전용으로 공유하는 게 합리적인 상황
내부 객체가 불변(immutable)이거나 수정되지 않는다고 보장되는 상황

[C# 이해하기] 값형식(Value Type)과 참조 형식(Reference Type)

슬로우도파민 — Sat, 3 Jan 2026 10:36:08 +0900

C#에서 변수를 만들 때, 우리는 보통 “변수에 값이 들어간다”고 생각합니다.

그런데 자료형에 따라 변수 안에 들어가는 것이 두 가지로 갈립니다.

값 형식(Value Type): 변수에 데이터 그 자체가 들어간다
참조 형식(Reference Type): 변수에 **데이터가 있는 곳을 가리키는 정보(참조)**가 들어간다

이 차이는 단순 개념이 아니라, 실제 코드에서 대입했을 때, 수정했을 때, 함수에 전달했을 때 동작을 완전히 바꿉니다.

ValueType vs ReferenceType

1) “복사되는 게 다르다”

값 형식: 대입하면 “내용”이 복사된다

int a = 10;
int b = a;  // a의 값(10)이 b로 복사됨
b = 20;

Console.WriteLine(a); // 10
Console.WriteLine(b); // 20

b를 바꿔도 a는 그대로입니다.

왜냐하면 처음 대입할 때부터 서로 다른 값을 가지고 있기 때문입니다.

참조 형식: 대입하면 “주소표(참조)”가 복사된다

int[] arr1 = { 1, 2, 3 };
int[] arr2 = arr1; // arr1이 가리키는 "같은 배열"을 arr2도 가리킴

arr2[0] = 999;

Console.WriteLine(arr1[0]); // 999
Console.WriteLine(arr2[0]); // 999

arr2를 수정했는데 arr1도 바뀐 것처럼 보입니다.

정확히는 arr1과 arr2가 같은 배열(같은 객체)을 공유하고 있기 때문입니다.

2) “변수 = 상자” 비유로 이해하기

값 형식 변수: 상자 안에 물건 자체가 들어있음
참조 형식 변수: 상자 안에 물건이 있는 창고 주소가 적힌 쪽지가 들어있음

그래서 참조 형식은 상자를 복사해도 “쪽지”만 복사되고, 창고(객체)는 그대로 하나라서 함께 영향을 받습니다.

3) 대표적인 값 형식 / 참조 형식

값 형식(Value Type)

int, float, double, bool, char
struct (구조체)
enum

참조 형식(Reference Type)

class로 만든 타입
string
배열(int[], char[] 등)
List<T>, Dictionary<TKey, TValue> 같은 컬렉션

여기서 가장 많이 헷갈리는 게 string입니다.

string은 생김새는 값처럼 보이지만, 분류는 참조 형식입니다.

4) “참조 형식인데 왜 string은 안전해 보일까?”

배열이나 List는 수정이 가능합니다(“mutable”).

하지만 string은 불변(immutable) 입니다.

string s1 = "hi";
string s2 = s1;
s2 = "bye";

이때 s2를 바꾼 게 아니라, s2가 새 문자열을 가리키게 된 것입니다.

그래서 “참조 형식인데도 값 형식처럼” 느껴질 수 있습니다.

핵심만 정리하면:

string은 참조 형식
다만 문자열 내용 자체를 바꾸는 방식이 아니라 새 문자열을 만든다(불변)
그래서 공유로 인한 사고가 상대적으로 덜 보인다

5) 함수에 전달될 때(매개변수)도 핵심은 “무엇이 복사되나”

C#의 기본 전달 방식은 값 전달(call by value) 입니다.

여기서 중요한 포인트는 “값 전달”이 항상 값 형식만 의미하는 게 아니라는 점입니다.

값 형식을 전달하면: 데이터 자체가 복사
참조 형식을 전달하면: 참조(주소표)가 복사

즉, 참조 형식도 기본은 “값 전달”인데, 그 값이 ‘참조’인 것입니다.

void ChangeFirst(int[] a)
{
    a[0] = 777; // 배열 내용 수정 (공유된 객체에 반영)
}

int[] x = { 1, 2, 3 };
ChangeFirst(x);
Console.WriteLine(x[0]); // 777

6) 가장 중요한 실전 결론 3가지

값 형식은 복사해도 독립적이라 예측이 쉽다.
참조 형식은 “공유”가 기본이어서, 한쪽 수정이 다른 쪽에 영향을 줄 수 있다.
“내가 지금 바꾸는 게 변수 자체인지, 변수 너머의 객체인지”를 구분하면 실수가 줄어든다.

[2D-Platformer] 3. 점프 구현하기 (Jump)

슬로우도파민 — Sat, 27 Dec 2025 11:28:37 +0900

이번에는 점프 기능을 추가하였다.

점프 기능 추가

점프는 Update에서 점프가 가능한 상태인지를 구분해주고

FixedUpdate에서 실행해 주었다.

    void Update()
    {
        if (isGrounded && !isClimbing && Input.GetKeyDown(KeyCode.Space))
        {
            jumpRequest = true;
        }
    }



    private void FixedUpdate()
    {   
        // jump
        if (jumpRequest)
        {
            Jump();
            jumpRequest = false;
        } 
    }


    private void Jump()
    {
        rb.linearVelocity = new Vector2(rb.linearVelocity.x, 0f);
        rb.linearVelocity = new Vector2(rb.linearVelocity.x, jumpPower);
    }

Jump 함수에서 0을 한번 줬다가 jumpPower를 주는 이유는 모든 점프를 일정하게 하기 위해서이다.

점프 파워, 높이 등을 일정하게 맞춰준다.

근데 그러다가 이런 버그를 발견했다.

Jump Bug

점프를 하면서 벽을 밀쳤을 때 마찰력 때문에 서로 계속 밀어서 움직이지 않았다.

중력이 엄청 세지 않아서 그런 것도 같았다. (gravity scale 10)

결국 마찰력을 0으로 한 Physics Material 2D를 만들어 Player Collider에 연결해줌으로써 문제를 해결했다!

[2D Platformer] 2. 사다리 로직 구현 (Climbing Ladder)

슬로우도파민 — Fri, 26 Dec 2025 14:11:27 +0900

오늘은 사다리 타기 로직을 구현해봤다.

체크해야할 것도 많고, 올라가는 것 뿐 아니라 다시 내려오는것까지 구현해야해서

뭔가 은근 까다로웠다.

다음은 결과물이다.

메이플 스토리 사다리 타는것 기준으로 구현했는데 뭔가 느낌이 괜찮은 것 같다.

사다리 로직 구현 결과물

1. 사다리가 옆에 있는지 체크

일단 사다리 로직을 구현할 때 내가 가장 먼저 생각해야하는 조건이

사다리가 옆에 있는가??

였다.

그래서 이런식으로 Near 사다리 조건을 체크해줬다.

사다리에 Ladder 스크립트를 넣어서 어떤 사다리를 타고 있는지도 가져와줬다. (나중에 필요할 것 같아서)

    private void OnTriggerEnter2D(Collider2D other)
    {
        if (other.gameObject.name == "ladder")
        {
            isNearLadder = true;
            ladder = other.GetComponent<Ladder>();
        }
    }

    private void OnTriggerExit2D(Collider2D other)
    {
        if (other.gameObject.name == "ladder")
        {
            isNearLadder = false;
            ladder = null;
        }
    }

그리고 생각해보니, 사다리 탈때는 중력을 없애야겠다고 생각했다.

그래서 update 문에서 Near사다리 이면 중력을 없애버렸다.

    void Update()
    {
        // gravity setting
        if (isNearLadder)
            rb.gravityScale = 0;
        else
            rb.gravityScale = gravityScale;
    }

2. Climbing 상태 체크

Climbing 중일 때, 좌우 이동을 막기 위해 Climbing 조건을 정의해봤다.

Climbing 이 시작될때

- Near Ladder true

- horizontal 입력 true

Climbing 상태가 끝나는 조건

- IsClimbing true

- isGrounded true (항상 위든 아래든 땅에 닿아야 클라이밍이 끝난다.)

    void Update()
    {      
        // judge climbing
        if (isNearLadder && vertical != 0)
            isClimbing = true;
        else if (isClimbing && isGrounded)
            isClimbing = false;
    }

3. IsGrounded 체크

ground 체크는 상용화 된 방법을 사용했다.

Player 바닥 밑에 EmptyObject를 깔아주고 Physics2D.OverlapCircle을 통해 체크해준다.

    private void FixedUpdate()
    {
        // judge isGrounded
        isGrounded = Physics2D.OverlapCircle
			(groundCheck.position, groundRadius, groundLayer);
    }

GroundCheck는 물리 상태이기 때문에, FixedUpdate에서 하는게 가장 안전하다.

4. 맵 조정

초록 부분 - Ground

갈색 부분 - Ladder

맵 특징 1

사다리 부분은 ground가 끊겨있다.

사다리 부분의 Ground는 isTrigger 조건만 넣어서 Player가 막힘없이 통과할 수 있도록 하였다.

처음에는 사다리 부분의 ground가 없었는데, 있어야 다 올라갔다는 체크를 해줄 수 있어서 추가하였다.

맵 특징2 - 사다리 2d collider

윗부분을 길게 뽑아서 윗층에서 돌아다닐때도 Player가 사다리랑 Trigger를 감지할 수 있도록 하였다.

또한, 어느 정도 사다리 중앙에 와서 위아래 입력을 해야 사다리를 이용할 수 있도록, 콜라이더의 좌우 폭을 줄여주었다.

맵 2d Collider

맵 특징3

사다리 양 옆 초록 ground의 collider는 조금 줄여준다.

딱맞게 콜라이더를 설정해버리면 플레이어가 끼어서 내려갈 수가 없기 때문에 콜라이더를 조금 줄여준다.

5. 이동 로직

이제 Climb 상태에 따라,

Climbing 일때는 좌우 이동을 막고, x position을 사다리 중앙으로 고정시켜 줬다.

Climbing 중이 아닐 때는 좌우 입력을 반영시켜주었다.

    private void FixedUpdate()
    {
        // Player Move (Climb / not Climb)
        if (isClimbing)
        {
            float newX = ladder.transform.position.x;
            float newY
            = Mathf.Clamp
            (rb.position.y + vertical * climbSpeed * Time.fixedDeltaTime, 
                ladder.bottom.position.y, ladder.top.position.y);
            
            rb.MovePosition(new Vector2(newX, newY));
        }
        else
        {
            rb.linearVelocity 
            = new Vector2(horizontal * moveSpeed, rb.linearVelocity.y);
        }
    }

Climb 상한/하한 위치 설정

코드 중간에 Mathf.Clamp를 넣어, 위 아래 포지션의 상한, 하한선을 제한시켜준 이유는

저 코드를 넣지 않았더니 플레이어가 사다리에 도착했을 때 심하게 진동을하고 상태가 꼬여버려서

안전하게 사다리 top, bottom 위치까지만 움직이도록 제한해주었다.

다음은 점프를 추가해볼 것이다!

[2D Platformer] 1. START & 좌우 이동 구현

슬로우도파민 — Mon, 22 Dec 2025 10:12:35 +0900

다시 게임 만들기 프로젝트를 시작했다-!-!-!

2D 플랫포머 게임

플랫폼은 발판을 이야기하는데, 캐릭터가 발판을 밟고 다니면서 플레이하는 종류의 게임들을 말한다.

요즘 메이플랜드를 많이 하기도 했고 2D 게임을 만들어보고 싶어서 이 장르를 택했다.

개발 규칙

게임 개발은 이전에도 해본 적이 있지만,

이번에는 조금 더 체계적이고 효율적인 방식으로 해보고 싶었다.

그래서 GPT의 도움을 받아

아주 단순한 규칙 두 가지를 정했다.

항상 시작 – 목표 – 플레이 – 끝이 있는 상태를 유지한다
아트는 타인에게 보여줘도 될 정도로 플레이가 안정된 이후에 넣는다

완성도가 낮아도 상관없고,

일단 게임처럼 켜서 플레이하고 끝낼 수 있는 상태를 유지하는 게 목표다.

꼭 구현해보고 싶은 기능

진짜 간단한데, 메이플 사다리 타는 기능을 꼭 구현해보고 싶다. (심플하죠?)

여유가 된다면

NPC 다이얼로그도 한 번 붙여보고 싶다.

메이플월드 - 메이플랜드

First Day

Day 1에서는 목표를 아주 작게 잡았다.

왼쪽에서 시작해서
좌우로 움직여서
흰색 네모에 도달하면 끝

그래서:

플레이어 좌우 이동을 만들고
목표를 흰색 네모로 정하고
도달하면 Success 가 뜨도록 했다

아트는 전부 square로 처리했다.

결과적으로 지금은

“게임을 켜면 → 움직일 수 있고 → 끝낼 수 있는 상태"가 됐다.

아래는 현재 상태의 플레이 영상이다.

마무리

시작 – 목표 – 플레이 – 끝이 명확하니까

개발하는 입장에서도 뿌듯함이 두 배인 것 같다.

예전에는 도트만 찍다가 끝난 경우도 많았는데,

이 방식은 꽤 마음에 든다.

다음 목표는 사다리 타기 구현이다~!

비트 연산으로 이해하는 2의 거듭제곱 - Math.Pow 대신 1 << n을 사용하는 이유

슬로우도파민 — Fri, 12 Dec 2025 14:33:01 +0900

Math.Pow(2, n) 대신 1 << n 을 쓰는 이유

2048 게임

알고리즘 문제를 풀다 보면 2ⁿ 형태의 값이 자주 등장한다.

C#에서는 흔히 다음과 같이 작성하기 쉽다.

int x = (int)Math.Pow(2, n);

하지만 이 경우, 더 적절한 표현은 다음이다.

int x = 1 << n;

비트 관점에서의 의미

정수 1을 이진수로 표현하면 다음과 같다.

1 = 0001

왼쪽 시프트 연산(<<)은 비트를 왼쪽으로 이동시키는 연산이다.

1 << 1 = 0010 (2)
1 << 2 = 0100 (4)
1 << 3 = 1000 (8)

즉, 비트를 한 칸 이동할 때마다 값은 2배가 된다.

1 << n == 2ⁿ

Math.Pow가 적절하지 않은 이유 - 부동소수점 연산

Math.Pow와 MathF.Pow는 각각 double, float 기반의 연산이다.

Math.Pow(2, n)   // double
MathF.Pow(2, n)  // float

정수 연산이 필요한 상황에서 불필요한 부동소수점 계산과 캐스팅이 발생한다.

정리

2의 거듭제곱을 표현할 때 1 << n이 더 적절하다.
정수 연산이며, 비트마스크 문제와 의미적으로 잘 맞는다.
Math.Pow는 부동소수점 연산이므로 이런 상황에서는 피하는 것이 좋다.

LeetCode 136. SingleNumber — XOR 연산 응용

슬로우도파민 — Thu, 11 Dec 2025 18:03:05 +0900

LeetCode 136번 Single Number

— Dictionary 풀이 vs XOR 풀이 완전 비교

LeetCode 136번 Single Number 문제는 매우 유명한 비트 연산 문제다.

“배열에서 단 한 번만 등장하는 숫자를 찾아라”라는 단순한 요구지만, 효율성과 공간 복잡도에 따라 풀이의 난이도가 크게 달라진다.

이 글에서는 직관적인 Dictionary 풀이와 가장 빠르고 메모리 효율이 좋은 XOR 정석 풀이를 비교하여, 어떤 방식이 더 좋은 선택인지 자세히 분석해보겠다.

https://leetcode.com/problems/single-number/description/

문제 요약

정수 배열 nums에서
오직 한 번만 등장하는 숫자를 찾기.
나머지 숫자는 모두 두 번씩 등장한다.

예:

입력:  [2,2,1]
출력:  1

1. Dictionary(해시맵) 풀이 — 직관적이지만 비효율적인 이유

아래는 내가 처음에 풀었던 방식인 Dictionary를 이용한 풀이:

public int SingleNumber(int[] nums)
{
    Dictionary<int, bool> dict = new Dictionary<int, bool>();

    foreach (var i in nums)
    {
        if (dict.ContainsKey(i))
        {
            dict.Remove(i);
        }
        else
        {
            dict[i] = true;
        }
    }

    return dict.Keys.First();
}

✔️ 장점

① 직관적으로 이해가 쉽다

한 번 나오면 담고, 두 번째 나오면 삭제한다.

결국 마지막에 딱 하나 남는다.

② 논리적으로 오류가 없다

문제 조건(단 한 숫자만 1회 등장)과 정확히 일치한다.

❌ 단점

① 공간 복잡도 O(n)

짝으로 등장하는 숫자들은 결국 지워지지만,

중간 과정에서 dict에는 여러 숫자가 저장된다.

→ 큰 입력에서는 불필요한 메모리 사용이 커진다.

② 성능이 XOR보다 느리다

ContainsKey, Remove는 평균 O(1)이지만,

해시 연산과 리사이징이 일어나기 때문에 실제 실행 비용은 XOR보다 훨씬 크다.

③ LeetCode가 의도한 풀이와 다르다

이 문제는 원래 O(1) 공간으로 해결하는 비트 연산 문제이다.

2. XOR 정석 풀이 — 가장 빠르고 메모리 효율 최고의 방식

LeetCode 토론에서도 공식 인터뷰에서도 가장 많이 언급되는 풀이가 바로 XOR 풀이다.

처음에 이 풀이 보고 미쳤다고 생각했다..(positive)

public int SingleNumber(int[] nums)
{
    int result = 0;
    foreach (var n in nums)
    {
        result ^= n;
    }
    return result;
}

✔️ XOR이 가능한 이유 (핵심 성질 3개)

1) a ^ a = 0

같은 숫자는 서로 지워진다.

2) 0 ^ b = b

0은 XOR에 영향을 주지 않는다.

3) 교환/결합 법칙이 성립한다

순서 상관 없이 모든 숫자를 XOR 해도 된다.

결국 “짝수 번 등장하는 숫자는 모두 사라지고 한 번 등장한 숫자만 남는다.”

XOR 연산

✔️ 장점

① 공간 복잡도 O(1)

추가 메모리가 필요 없다.

② 시간 복잡도 O(n)

한 번만 순회하면 된다.

③ 가장 빠르고 가장 짧다

컴퓨터가 가장 좋아하는 연산: 비트 연산.

✔️ 단점

① 초보자에게는 직관적이지 않다

사람이 “왜 XOR이 되지?” 하고 이해하는 데 시간이 걸린다.

하지만 일단 이해하면 비트 문제에서 자주 응용된다.