Minssuy RSS Feed

0.1 + 1.1 == 1.2 는 True 이다.

Thu, 16 Apr 2026 00:00:00 GMT

편견

이 질문은, 소수점을 다루는 개발자라면 한번씩은 접해보는 문제입니다.
많은 사람들이 말하길, 0.1 + 1.1 == 1.2 는 False 라고 합니다.
그럼, 제가 질문을 살짝 바꿔 다시 여쭤보겠습니다.

0.1 + 1.1 == 1.2 는 False 가 확실한가요?

문제

본문은 Unity 엔진의 C# 문법을 기준으로 설명하겠습니다.

public class Test : MonoBehaviour
{
    float a = 0.1f;
    float b = 1.1f;

    void Start()
    {
        float c = a + b;
        Debug.Log(c == 1.2f); // result is true? false?
    }
}

잠시 스크롤을 멈추고, 코드를 보고 질문에 답해주시기 바랍니다.
위의 코드에서, Debug.Log(c == 1.2f) 의 출력은 True 와 False 중에 어떤 것으로 나오게 될까요?

5초 정도 시간을 드리겠습니다.

충분히 생각해보셨나요? 이 내용을 아는 분께선 5초라는 시간도 길었을 지도 모르겠습니다.
그럼 직접 실행시켜보겠습니다.

Result is True

그림의 아래쪽을 보니, 콘솔창에 True 라고 적혀있습니다.
최소한 저는 소수 + 소수 는 제대로 동작하지 않는다고 배웠기 때문에, False 라고 예측했습니다.

그렇다면, 컴퓨터와 그렇게 알려준 사람들 중 누가 거짓말을 하고있는걸까요?

저장

이러한 일이 일어난 이유를 알기 위해선, 컴퓨터가 어떤식으로 소수를 저장하는지 먼저 알아야합니다.

소수는 float 라는 자료형으로 값을 저장할 수 있고, 4 Byte 크기를 가집니다.
float는 아래의 그림과 같이 RAM 에 부호, 지수부, 가수부라는 공간으로 나누어 저장합니다.

Ram (4 byte, 32 bit)

32 bit 중 1 bit 는 값의 부호를, 8 bit 는 지수부, 남은 23 bit 는 가수부로 사용되는 모습을 확인할 수 있습니다. 부호는 알지만, 지수부와 가수부라는 어려운 단어를 보니 벌써부터 머리가 아픈 느낌이 듭니다.
머리와 눈이 조금 아플 수 있습니다만, 이것들을 순서대로 하나씩 알아보겠습니다.

예시

11.25 라는 소수가 있습니다. 이 숫자가 float 자료형에 어떻게 저장되는지 살펴보겠습니다.

1. 이진법 변환

현재 11.25 는 십진법으로 표기되어있습니다. 이것을 이진법으로 표현하겠습니다.

\begin{aligned} 11 \div 2 &= 5 \cdots 1 \\ 5 \div 2 &= 2 \cdots 1 \\ 2 \div 2 &= 1 \cdots 0 \\ 1 \div 2 &= 0 \cdots 1 \end{aligned} \quad \Rightarrow \quad 1011

\begin{aligned} 0.25 \times 2 &= 0.5 \quad \Rightarrow 0 \\ 0.5 \times 2 &= 1.0 \quad \Rightarrow 1 \end{aligned} \quad \Rightarrow \quad .01

11.25_{(10)} = 1011.01_{(2)}

2. 정규화

가장 왼쪽에 있는 1 을 기준으로 하여, 바로 뒤에 점을 찍고, 옮긴 칸 수 만큼 지수를 곱합니다.
이 과정을 정규화 Normalization 라고 하며, 앞부분 1.01101 을 가수부, 2³ 를 지수부 라고 부릅니다.

1011.01_{(2)} \;=\; 1.01101 \times 2^{3}

가수부(Mantissa) : 실제 수치를 담고 있는 중요한 부분 1.01101
지수부(Exponent) : 가수부에 얼만큼 곱할건지 결정하는 부분 2³

3. 값 저장

가수부와 지수부로 분리하였으니, 이것을 램에 저장해보겠습니다.
첫번째 칸의 부호는, 양수일 땐 0 이고 음수일 땐 1 로 표기됩니다.

필드	계산값	저장값 (RAM)
부호 (1 bit)	`+`	`0`
지수부 (8 bit)	`3`	`10000010`
가수부 (23 bit)	`1.01101`	`01101000000000000000000`

잠깐! 여기서 읽는 것을 멈추시고, 표를 다시 한번 확인해보시기 바랍니다. 제가 숫자를 제대로 기입했나요?

저장된 가수부를 자세히 보면, 앞자리의 1 이 사라진 것을 알 수 있습니다.
지수부는 어떤식으로 계산이 된건지 모르겠지만, 10000010 라는 값으로 저장되어 있습니다.

컴퓨터는 왜 이렇게 저장했을까요?

지수부의 Bias

지수부는 소수점을 얼만큼 이동시킬지 결정하는 부분이라고 했습니다.
소수점을 오른쪽으로 이동하면 양의 지수, 왼쪽으로 이동하면 음의 지수가 필요합니다.

8 bit 로 표현할 수 있는 범위는 0 ~ 255 입니다.
그런데 음의 지수도 표현해야 하는데, 이 범위에는 음수가 없습니다.

그래서 127 을 기준점으로 정하고, 아래와 같이 나누어 사용합니다.

저장값	의미
`0`	특수값
`1 ~ 126`	음의 지수
`127`	0승
`128 ~ 254`	양의 지수
`255`	특수값 (∞, NaN)

0 과 255 는 특수값으로, 지금은 몰라도 됩니다.

핵심은, 실제 지수에 127을 더한 값 이 지수부에 저장된다는 것입니다. 이 기준값 127 을 Bias 라고 부릅니다.

\text{지수부 저장값} = \text{실제 지수} + 127

예시를 보면 더 쉽게 이해가 됩니다.

\begin{aligned} -7 + 127 &= 120 \quad \Rightarrow \quad 01111000_{(2)} \\ \phantom{-}0 + 127 &= 127 \quad \Rightarrow \quad 01111111_{(2)} \\ \phantom{-}3 + 127 &= 130 \quad \Rightarrow \quad 10000010_{(2)} \end{aligned}

아까 예시에서 지수부에 10000010 이 저장된 이유가 바로 이것입니다.
3 + 127 = 130, 그리고 130 을 2진법으로 변환하면 10000010 이 됩니다.

가수부의 Hidden Bit / Implicit Bit

이번엔 가수부가 1.01101 이 아닌 01101 로 저장된 이유를 알아보겠습니다.

정규화 과정에서 한 가지 패턴이 있습니다. 정규화된 이진수는 항상 1. 로 시작 한다는 것입니다.

\begin{aligned} 11.25 &\;\rightarrow\; 1011.01 \;\rightarrow\; \mathbf{1}.01101 \times 2^{3} \\ 0.40625 &\;\rightarrow\; 0.01101 \;\rightarrow\; \mathbf{1}.101 \times 2^{-2} \end{aligned}

맨 앞의 1 은 어떤 수를 정규화해도 반드시 존재합니다. 그렇다면, 굳이 저장할 필요가 없지 않을까요?
그래서 이 1. 부분은 있다고 약속 하고, 실제 메모리에는 소수점 이하만 저장합니다.
CPU 가 값을 읽을 때 자동으로 맨 앞에 1. 을 붙여 계산합니다.

이렇게 숨겨진 1 을 Hidden Bit 또는 Implicit Bit 라고 합니다.
덕분에 가수부는 23 bit 를 가지지만, 숨겨진 1 을 포함하면 실제로는 24 bit 의 정밀도 를 가집니다.
공짜로 1 bit 를 얻은 셈입니다.

계산

그렇다면 저희가 궁금한 0.1 + 1.1 은 실제로 어떻게 계산될까요?

10진법 의 0.1 을 2진법 으로 변환하면, 아래와 같이 무한히 반복되는 순환소수가 됩니다.

0.1_{(10)} = 0.000110011001100110011\ldots_{(2)}

float 의 가수부는 24 bit (Hidden Bit 포함) 이므로, 24번째 자리에서 반올림하여 저장됩니다.

0.1 \;\approx\; 1.10011001100110011001101_{(2)} \times 2^{-4}

이를 다시 10진법으로 변환하면 아래와 같이 됩니다.

0.1 \;\approx\; 0.10000000149011612

같은 방식으로 1.1 도 정확히 표현할 수 없습니다.

1.1 \;\approx\; 1.10000002384185791

이 둘을 더하면 아래와 같이 됩니다.

0.10000000149\ldots \;+\; 1.10000002384\ldots \;=\; 1.20000002533\ldots

그런데 생각해보면, 수직선 위의 숫자는 무한히 존재하고, float 는 그 모든 값을 저장할 수 없습니다. 그래서 float 는 내부적으로 특정 값들만 미리 정해두고, 점처럼 띄엄띄엄 사용합니다.

계산 결과인 1.20000002533 은 float 가 정해둔 점들 중 하나가 아닐 수 있습니다.
예를 들어, C# 의 float 에선 1.20000004768 을 그 특정 값 중 하나로 두고 있다고 가정해봅시다.
그럴 경우 컴퓨터는 1.20000002533 에 가장 가까운 점인 1.20000004768 을 찾아서 저장합니다.

이 과정을 Rounding 이라고 합니다.

1.20000002533\ldots \;\xrightarrow{\text{Rounding}}\; 1.20000004768\ldots

그리고 1.2f 를 float 에 저장할 때도 동일하게 반올림이 일어납니다.

1.2_{(10)} \;\xrightarrow{\text{float 저장}}\; 1.20000004768\ldots

결국 두 값은 완전히 동일합니다.

\underbrace{0.1\text{f} + 1.1\text{f}}_{1.20000004768\ldots} \;==\; \underbrace{1.2\text{f}}_{1.20000004768\ldots} \quad \Rightarrow \quad \texttt{True}

우연의 일치?

앞서 살펴봤듯이, 0.1f + 1.1f 의 Rounding 결과는 1.20000004768 입니다.
그런데 공교롭게도, 1.2f 를 float 에 저장할 때 사용하는 값도 1.20000004768 입니다.

정리하면 아래와 같습니다.

0.1f + 1.1f 의 실제 계산 결과는 1.20000002533 입니다.
이 값이 Rounding 되어 가장 가까운 float 점인 1.20000004768 이 됩니다.
1.2f 의 실제 저장값도 1.20000004768 입니다.
결국 c == 1.2f 는 1.20000004768 == 1.20000004768 이므로 True 입니다.

float a = 0.1f;
float b = 1.1f;
float c = a + b;

// c     : 1.20000004768… (1.20000002533… 이 Rounding 됨)
// 1.2f  : 1.20000004768… (float 에 저장된 가장 가까운 점)
Debug.Log(c == 1.2f); // True

그렇다면, 이번 문단의 제목을 다시 읽어보겠습니다.
이건 정말 우연의 일치 일까요?

IEEE 754

IEEE (Institute of Electrical and Electronics Engineers)
IEEE 부동소수점 연산 표준(IEEE Standard for Floating-Point Arithmetic, IEEE 754)

지금까지 살펴본 float 의 동작방식은 버그나 우연이 아닙니다.
저희가 살펴본 이것들은 전부 IEEE 754 라는 국제 표준에 정의된 의도적이고 논리적인 동작입니다.

IEEE 754 는 1985 년에 제정된 부동소수점 연산 표준입니다.

32 bit 를 어떻게 나눌 것인지
Bias 의 값을 얼마로 할 것인지
반올림은 어떤 방식으로 할 것인지 (여러가지 방법이 있지만, 머리가 아프니 생략하겠습니다.)
Hidden bit 를 사용할 것인지

전세계의 99% 가 이 국제표준을 사용하고 있습니다. 이 표준의 목적은 어떤 언어에서든 동일한 부동소수점 연산에 대해 동일한 결과를 보장하는 것입니다. 그렇다면 C#, Python, C++, JavaScript 등의 언어들에서 float 연산을 하면 동일한 결과가 나오고, 0.1f + 1.1f == 1.2f 는 어느 언어에서든 True 일까요?

안타깝게도 그렇지 않습니다. 표준을 따른다고 해서 모든 환경에서 동일한 결과가 나오는 건 아닙니다. JavaScript 는 모든 숫자를 double (64 bit) 로 처리하기 때문에, float (32 bit) 를 사용하는 C# 과는 정밀도 자체가 다릅니다. 또한 컴파일러 최적화, CPU 아키텍처, 런타임 환경 등에 따라서도 결과가 달라질 수 있습니다.

stackoverflow 에 따르면, 변수에 저장하느냐 안하느냐에 따라서도 결과가 달라질 수 있다고 합니다.
직접 계산식을 비교하면 False 지만, 변수에 저장한 후 비교하면 True 가 나오는 경우가 있다는 것입니다.

결론

여러분께 다시 물어보겠습니다.
0.1 + 1.1 == 1.2 는 False 가 확실한가요?

제가 대신 대답을 해보자면, “일반적으로 False 가 맞다” 라고 말할 것 같습니다.
이 글에서 말하고자 하는 것은, 무조건 False 라고 대답하는 것이 항상 맞는 논리는 아니라는 점입니다.
사람들과 책이 알려주는 것을 한번쯤 의심해보는 자세도 나쁘지 않다고 생각합니다.

결론은, 소수를 쓸 땐 조건문을 조금 더 신경쓰고, 특히 == 연산은 쓰지 않는 것이 좋겠습니다.

Result is false, But this may be a bias.
Bias 는 컴퓨터에선 지수를 양수로 만드는걸 의미하지만, 일반적인 의미는 편견, 편향이라는 뜻.

Reference

Rigidbody - Interpolation

Fri, 27 Mar 2026 00:00:00 GMT

계산과 예측

여러분은 다음 날 아침에, 친구와 놀러 가기로 했습니다. 어떤 옷을 입을지 결정하기 위해 일기예보를 확인해봅니다. 내일 오전 9시는 10°, 10시는 14°라고 합니다. 오전에는 조금 쌀쌀하지만, 시간이 지나면서 기온이 오를 것으로 보입니다. 그래서 외투를 입을지 고민이 됩니다. 그런데 아쉽게도 일기예보는 10시까지만 제공되고 있습니다. 이제 우리는 주어진 정보만으로 판단해야 합니다.

현재 우리가 알고 있는 것은 다음과 같습니다.

오전 9시 : 10°
오전 10시 : 14°

그렇다면, 오전 9시 30분의 기온은 어느 정도일까요?
아마도 12° 정도로 예측을 해볼 수 있겠네요. 이건 꽤나 정확할 가능성이 높습니다.

이번에는, 오전 11시의 기온은 어느 정도일까요?
주어진 정보만으로 판단해보면, 9시에서 10시 사이에 4°가 상승했으므로, 같은 흐름이 이어진다고 가정했을 때 오전 11시는 약 18° 정도일 것으로 예상할 수 있습니다.

그럼 여기서 질문해보겠습니다.
오전 9시 30분의 예측 기온과, 오전 11시의 예측 기온 중 어떤 값이 더 정확할까요?

내삽과 외삽

아마도 여러분은 오전 9시 30분의 예측 기온이 더 정확할 것이라고 생각하셨을 것입니다.
그렇다면 우리는 왜 이런 판단을 내렸을까요?

그 이유는, 두 경우가 서로 다른 범위에 있기 때문입니다.

오전 9시 30분은 9시와 10시 사이, 즉 우리가 알고 있는 데이터의 범위 안에 있습니다.
반면, 오전 11시는 주어진 데이터의 범위를 벗어난 값입니다.

따라서 9시 30분의 경우는 기존 정보를 바탕으로 계산한 값이고, 11시는 그 흐름을 바탕으로 예측한 값이기 때문에 정확도에서 차이가 발생합니다.

앞의 예시를 기준으로 정리해보면 다음과 같습니다.

오전 9시 ~ 10시 사이의 값을 예측한 것 → 내삽(보간) Interpolation
오전 11시처럼 범위를 벗어난 값을 예측한 것 → 외삽 Extrapolation

이것이 이 포스트에서 다뤄볼 내삽과 외삽의 개념입니다.
한국, 일본, 중국 등 개발이나 그래픽스 분야에서는 내삽보다는 보간 이라는 표현이 더 일반적으로 사용됩니다. 지금부터는 보간이라는 용어를 사용하겠습니다.

그럼, 이 개념을 Unity 의 Rigidbody 와 연결해보겠습니다.

Rigidbody - Interpolation

Unity에는 매 프레임마다 실행되는 Update와, 고정된 간격으로 실행되는 FixedUpdate가 있습니다. 물리 연산은 FixedUpdate에서 처리되며, 기본값은 초당 50회입니다. 반면 Update는 프레임률에 따라 가변적으로 실행됩니다.

Update, FixedUpdate

이 두 루프는 항상 같은 타이밍에 실행되지 않습니다. 물리 위치는 FixedUpdate마다 갱신되지만, 화면에 그려지는 건 Update(렌더링) 타이밍입니다. 그럼 Interpolation 프로퍼티에 대해서 알아보겠습니다.

비교

백문이 불여일견입니다. 세 가지 옵션을 직접 비교해보겠습니다. 각 큐브의 Interpolation을 다르게 설정하고, TimeScale을 낮춰 슬로우모션으로 확인해보면 어떤 모습으로 보일까요?

TimeScale: 0.3, FPS: 60

차이점이 느껴지시나요? 제 눈으로 본 느낌을 그대로 말해보겠습니다.

None : 움직일 때 뚝뚝 끊겨 보이는 떨림이 발생합니다.
Interpolate : 부드럽지만, 다른 큐브들보다 살짝 늦게 도착하는 것처럼 보입니다.
Extrapolate : 부드럽지만, 바닥에 닿을 때 더 많이 찌그러지는 것처럼 보입니다.

왜 이런 차이를 보이게 되는 걸까요?

None

보정을 하지 않습니다. 렌더링 시점에서 가장 최신의 FixedUpdate에서 계산된 물리 위치를 그대로 렌더링합니다. FixedUpdate와 렌더링 타이밍이 어긋나면 오브젝트 위치가 불연속적으로 바뀌면서 떨림(Jitter) 이 발생합니다. 쉽게 말해서, 물리 위치 자체는 정확하지만, 렌더링 타이밍과 맞지 않아 위치가 뚝뚝 끊겨 보이는 겁니다.

None - Uses the latest FixedUpdate position

Interpolate

직전 두 FixedUpdate의 위치를 사용하여, 그 사이를 보간합니다.

Uses the previous two FixedUpdate results and renders one step behind

직전 두 FixedUpdate 위치를 A, B라 하면, A에서 B까지의 구간 중 렌더링 시점이 어디에 해당하는지 비율(α) 을 구하고, A와 B 사이의 위치를 보간하여 렌더링합니다. FixedUpdate가 초당 50번만 실행되더라도, 매 프레임마다 조금씩 다른 위치를 렌더링하기 때문에 움직임이 부드럽게 보입니다. 단, 항상 이미 완료된 과거 두 위치를 기준으로 보간하기 때문에, 렌더링 위치는 실제 물리 위치보다 한 FixedUpdate 스텝만큼 뒤처집니다.
왜 위의 영상에서 Interpolate 로 설정된 큐브가 늦게 떨어지는지 아시겠나요?

Extrapolate

현재 속도를 기반으로 다음 위치를 예측(외삽) 합니다. 일기예보에서 10시까지의 데이터로 11시 기온을 예측했던 것과 같습니다. 주어진 데이터 범위를 넘어서는 예측이기 때문에, 속도나 방향이 급격히 바뀌는 상황에서는 예측이 빗나가면서 오브젝트가 실제 위치를 넘어갔다가 되돌아오는 현상이 발생할 수 있습니다.

Predicts the next position based on current velocity and renders ahead

Extrapolate 로 설정한 큐브가 바닥에 닿았을 때, 왜 다른 큐브들 보다 더 찌그러져 보였는지 아시겠나요? 렌더러는 큐브가 계속해서 아래로 내려갈 것이라고 예측해서 그렸으나, 갑작스런 바닥과의 충돌에 미처 예상을 하지 않았다는 것입니다.

정리

영상을 다시 보겠습니다. 이번엔 최종 결과에 초점을 잡아봅시다.

TimeScale: 0.3, FPS: 60

Physics 실제로 바닥과 충돌한 시간

Extrapolate Cube : 0.920s
None Cube : 0.920s
Interpolate Cube : 0.920s

Render 그림이 바닥에 닿은 시간

Extrapolate Cube : 0.893s
None Cube : 0.904s
Interpolate Cube : 0.914s

여기서 주목할 점은 실제 물리 충돌은 세 큐브 모두 동일한 시간에 발생했다는 것입니다. Interpolation 설정은 물리 연산 자체에는 영향을 주지 않습니다. 그렇습니다. 차이가 나는 것은 렌더링 타이밍 뿐입니다.

물리 충돌은 동일한데, 렌더링 도착 시간이 다른 이유를 정리하면 이렇습니다.

Extrapolate : 미래를 예측하므로 실제보다 앞서 그려짐. 이에 따라 바닥을 많이 관통함.
Interpolate : 과거 두 위치를 보간하므로 실제보다 뒤처져 그려짐.
None : FixedUpdate 위치를 그대로 사용하므로 그 중간.

그렇다면 우리는 언제, 무엇을 써야 할까요?

옵션	상황
None	물리 오브젝트가 카메라에 보이지 않거나, 떨림이 눈에 띄지 않는 경우
Interpolate	플레이어 캐릭터, 카메라가 추적하는 오브젝트 등 부드러운 움직임이 중요한 경우
Extrapolate	Interpolate의 약간의 지연조차 허용하기 어려운 경우. 단, 급격한 방향 전환 시 오차가 발생할 수 있음

대부분의 경우 Interpolate를 사용하면 됩니다. 연산이 걱정이라면 괜찮습니다. Interpolate의 핵심 연산은 선형 보간(Lerp)입니다.

result = A + (B - A) \cdot \alpha

이전 위치 A, 직전 위치 B, 진행 비율 α만 있으면 덧셈과 곱셈 몇 번으로 끝나는 O(1) 연산입니다. Rigidbody 하나당 렌더링 프레임마다 한 번만 실행되므로, 물리 시뮬레이션 자체의 비용에 비하면 무시할 수 있는 수준입니다. 특별한 이유가 없다면 Interpolate를 기본값으로 두는 것이 좋습니다.

Reference

Unity Documentation - Apply interpolation to a Rigidbody

디자인 패턴을 시작하기에 앞서

Mon, 09 Mar 2026 00:00:00 GMT

프로그래밍을 입문하신 분이라면 나중에 방문해주세요.

이것은 제가 게임개발을 공부하면서 느낀 점 입니다. 지금의 저도 실력이 좋은 편은 아니지만, 프로그래밍을 입문했던 시기에는 욕심이 많았습니다. C#의 문법과 Unity 의 기능들이 어떤 것이 있는지 샅샅이 알아보려고 노력했었고, 그 중 알고리즘 이라던가 디자인 패턴 도 포함되어 있었습니다.

프로그래밍 입문자가 디자인 패턴을 공부하고 직접 적용을 시키려고 하면 어렵습니다. 어려울 뿐만 아니라, “이게 뭔지는 알았는데, 이걸 대체 왜 사용하는거지?” 라는 의문만이 생깁니다. 왜냐하면 단순히 필요한 지식처럼 보여 공부하려 했을 뿐, 실제로 답답함이나 불편함을 겪어본 적이 없기 때문입니다.

공부를 하다보면, 지식을 공유해주시는 분들께서 꽤 많이 사용하는 말이 있습니다.
“이러한 것을 하고싶을 때가 있을텐데, 그때 그러한 것을 사용해주시면 됩니다”

입문자였던 저는 위와 같은 말을 많이 보고 들었으며, 그렇게 하고 싶은 순간이 대체 언제 오는지부터 의문이였습니다. 똑같은 의문이 들었다면 해당 지식은 여러분에게 당장 필요없는 공부일 가능성이 높습니다.

필요한 공부를 합시다.

혹시 이 글을 보고 계시는 분이 입문자라면, 이렇게 물어보고 싶습니다. 게임개발에 필요한 공부가 뭐라고 생각하시나요? C#, C++, 자료구조, 알고리즘, 디자인 패턴, CS, 게임엔진 일까요? 이것들을 전부 마스터 해야할까요?

단순히 캐릭터를 움직이는 간단한 기능을 만들고 싶다고 가정해봅시다. 캐릭터의 이동을 구현하기 위해 수학, 물리 법칙부터 시작하여, 어떤 자료구조를 사용해야하고, 어떤 디자인 패턴을 사용해야하며, 구현했을 때 CPU 와 GPU, RAM 에선 어떤 일이 일어나는지 공부해야할까요?

깊이 있는 이해는 개발에 있어서 당연히 유리합니다. 하지만 깊이 있는 이해가 있다고 해서 재미있는 게임을 만들 수 있다는 것은 아닙니다.

일단 구현하세요. 궁금증이 생기면, 깊이 있는 이해를 원한다면 그때 알아보셔도 전혀 문제되지 않습니다.

코드를 마음껏 작성하며 망쳐보세요.

디자인 패턴은 공부하는 것이 아니라, 경험하는 것입니다. 코드를 마음대로 작성하며 망쳐보는 것은 디자인 패턴을 가장 빠르게 배우는 방법입니다. 코드가 점점 지저분해지고 관리하기 어려워지면 자연스럽게 답답함과 불편함을 느끼게 됩니다. 그때 스스로 코드를 정리해보시기 바랍니다. 깔끔하게 정리가 되었다면, 여러분께선 은연 중에 디자인 패턴을 사용하셨을 지도 모릅니다.

디자인 패턴은 반드시 지켜야 하는 수칙 같은 것이 아닙니다. 그리고 누군가가 디자인 패턴을 “이런 것이 디자인 패턴이다!” 라고 먼저 정의하고 만들어 낸 것이 아닙니다. 이전 세대의 개발자들이 코드를 작성하며 “이렇게 작성하는게 관리가 수월하고 편하더라” 라고 느꼈던 설계를 디자인 패턴 이라고 이름을 붙여 공유한 것입니다.

이 이야기는 디자인 패턴뿐만 아니라 대부분의 개발 지식에도 적용됩니다. 여러분께서 게임을 만드려고 하는 이유는 무엇인가요? 아마도 재미있는 게임을 만들어 이 경험을 다른 사람에게도 공유하고 싶기 때문일 것입니다.

Silksong Code Review: Optimization, Code Quality, Hidden things

Today, we'll review the reverse-engineered C# code of Silksong.We'll look at the code improvements, bugs, optimization techniques, etc.👉 How to code a mod f...

https://www.youtube.com/watch?v=uVnd5rK_VUw

위의 유튜브 영상은, 유명 인디게임인 할로우 나이트: 실크송 에 대한 코드리뷰입니다.
이 영상을 보면, 이 게임의 로직은 객체지향 프로그래밍 OOP 의 5가지 원칙인 SOLID 원칙을 전혀 지키지 않는 모습을 볼 수 있습니다. 이전 작인 할로우 나이트 는 코드품질이 더욱 좋지 않습니다. 그렇다면 여러분께 질문해보겠습니다. 할로우 나이트 는 실패한 게임인가요?

본질

게이머들은 ‘이 게임이 재미있는가?’ 를 판단하는 고객입니다. 게이머들은 저희가 작성한 코드를 보며 아름다움을 느끼고 감탄하지 않습니다. 물론, 설계라던가 SOLID 원칙 등 각종 개발 지식은 중요합니다만, 탄탄한 설계, 아름다운 코드에 집착하지 않으시길 바랍니다.

‘게임은 재미가 있어야 한다.’ 라는 본질을 잊지 않는 것이 중요하다고 생각합니다.
공부는 잠시 내려두고, 코드를 망쳐보세요.

Reference

Howdyツ’s Youtube - Silksong Code Review: Bugs, Code Quality, Optimization