1. 제목

H1 제목

H2 제목

H3 제목

H4 제목

H5 제목

H6 제목

2. 텍스트 강조

굵게 / 기울임 / 굵은 기울임
취소선 / 인라인 코드
마크 하이라이트 / 밑줄 / 작은 글씨

물 분자는 H₂O, 제곱은 x² 입니다.

복사는 Ctrl + C, 붙여넣기는 Ctrl + V.

3. 줄바꿈

이 블로그는 kramdown.hard_wrap: true 라서
줄 끝에 공백 두 개를 안 넣어도
이렇게 줄이 바뀝니다.

여기는 빈 줄을 넣었으므로 새 문단입니다.

4. 목록

순서 없는 목록

• 첫 번째 항목
• 두 번째 항목
  • 중첩 1단계
  • 중첩 1단계
    • 중첩 2단계
• 세 번째 항목

순서 있는 목록

1. 첫 번째
2. 두 번째
   1. 중첩 1단계
   2. 중첩 1단계
3. 세 번째

혼합 목록

1. 순서 있는 항목
   • 그 안의 순서 없는 항목
   • 또 하나
2. 다음 항목

작업 목록

• 체크 안 됨
• 체크 됨

정의 목록

장3도

반음 4개만큼 떨어진 음정

단3도

반음 3개만큼 떨어진 음정

5. 링크

인라인 링크
제목이 붙은 링크
참조 링크
자동 링크: https://thereisnofate.takecontr.lol
같은 페이지 앵커: 9번 항목으로
사이트 내부 링크: 게시물 목록

6. 이미지

기본 이미지:

figure include (캡션 + 클릭 시 확대):

7. 인용문

기본 인용문입니다.
두 번째 줄입니다.

첫 번째 문단입니다.

빈 줄로 나눈 두 번째 문단입니다.

바깥 인용문

중첩된 인용문

2단계 중첩

인용문 안의 목록:

• 항목 하나
• 항목 둘

인용문 안의 인라인 코드.

8. 구분선

위쪽 문단입니다.

아래쪽 문단입니다.

9. 코드

인라인 코드는 fdisk -l 처럼 씁니다.

언어 없는 코드블록:

언어를 지정하지 않은 블록입니다.
들여쓰기도    그대로    유지됩니다.

bash 하이라이팅:

#!/bin/bash
# 디스크 확인
fdisk -l | grep "^/dev"
for i in {1..3}; do
  echo "count: $i"
done

ruby 하이라이팅:

class Chord
  attr_reader :root, :quality

  def initialize(root, quality = :major)
    @root, @quality = root, quality
  end

  def to_s = "#{@root}#{@quality == :minor ? 'm' : ''}"
end

yaml 하이라이팅:

title: "서원근양학블로그"
kramdown:
  hard_wrap: true
plugins:
  - jekyll-feed
  - jekyll-sitemap

들여쓰기(4칸) 코드블록:

이것도 코드블록입니다.
백틱 없이 4칸 들여쓰기로 만듭니다.

10. 표

기본 마크다운 표

정렬 지정 (기본 문법)

fancy-tables — 정렬

| 코드 | 표기법 | 구성음 |
| --- | --- | --- |
| C Major | CM, C | 도-미-솔 |
| C minor | Cm, C- | 도-미♭-솔 |
| C augmented | Caug, C+ | 도-미-솔♯ |
```alignment
LCR

fancy-tables — colspan

셀 뒤에 백슬래시(\)를 붙인 개수 + 1 만큼 옆 칸과 합쳐집니다.
합쳐지는 칸은 아예 적지 않고 행을 짧게 끝냅니다.

| 구분 | 장3도 | 단3도 |
| --- | --- | --- |
| 아래는 두 3도를 쌓은 결과 \\ |
| 장3도 | augmented | Major |
| 단3도 | minor | diminished |
```alignment
CCC

fancy-tables — rowspan

아래 칸을 ^^ 로 시작하면 위 칸과 세로로 합쳐집니다.

| 조성 | 조표 | 으뜸음 |
| --- | --- | --- |
| 올림표 계열 | ♯ 1개 | G |
| ^^ | ♯ 2개 | D |
| ^^ | ♯ 3개 | A |
| 내림표 계열 | ♭ 1개 | F |
| ^^ | ♭ 2개 | B♭ |
```alignment
CCC

fancy-tables 원본 문법

```table
| 헤더1 | 헤더2 |
| --- | --- |
| 셀 | 셀 |
```alignment
LC
```

alignment 블록의 글자는 열 순서대로 L(왼쪽) · C(가운데) · R(오른쪽) 입니다.

11. 접기 (details)

12. 각주

각주를 다는 방법입니다¹. 두 번째 각주도 달아봅니다².

13. 약어

HTML 과 CSS 위에 마우스를 올려보세요.

14. 알림 상자 (minimal-mistakes)

기본 알림 상자입니다.

primary 알림 상자입니다.

info 알림 상자입니다.

warning 알림 상자입니다.

success 알림 상자입니다.

danger 알림 상자입니다.

15. 버튼 (minimal-mistakes)

기본 버튼
primary
success
warning
danger
info
큰 버튼
작은 버튼

16. 정렬 클래스 (minimal-mistakes)

가운데 정렬된 문단입니다.

오른쪽 정렬된 문단입니다.

양쪽 정렬된 문단입니다. 길이를 채우기 위해 문장을 조금 더 이어 붙입니다. 이 정도면 두 줄은 넘어갈 것 같습니다.

17. 영상 임베드

YouTube:

niconico:

vimeo · bilibili · google-drive 도 같은 방식으로 씁니다.
bilibili 는 danmaku="1" 로 탄막을 켤 수 있습니다.

18. 여백 (spacer)

아래에 32+16 픽셀 여백이 들어갑니다.

여백 뒤의 문단입니다.

19. 수식 (MathJax)

인라인 수식: $E = mc^2$ 입니다.

디스플레이 수식($$):

디스플레이 수식(대괄호 표기):

[
\sum_{n=1}^{\infty} \frac{1}{n^2} = \frac{\pi^2}{6}
]

위 대괄호 표기는 kramdown이 \[ 를 이스케이프로 먹어버릴 수 있습니다.
head/custom.html 의 MathJax 로딩 조건이 \[ · \] 포함 여부라서, 이 항목이 안 나오면 조건 자체를 $$ 기준으로 바꿔야 합니다.

행렬:

20. HTML 직접 삽입

<p align="center"> 로 가운데 정렬한 문단입니다.

21. 이스케이프

별표를 그대로 쓰려면 *이렇게* 백슬래시를 붙입니다.
백틱은 ` 이고, 우물 정은 # 입니다.
HTML 엔티티: © & < >   … —

Unity에서 개발을 하다 보면 오브젝트가 파괴되었는 지를 확인하기 위해서 null과 비교를 하는 경우가 있다.

Destroy(myObject);

//

if (myObject == null)
    Debug.Log("Destroyed");

이건 예상대로 동작한다. 문제는 C#에서 지원하는 null을 체크하는 다른 방법들을 사용했을 때 발생한다.

DestroyImmediate(myObject);

Debug.Log(myObject == null);                                    //True
Debug.Log((myObject as UnityEngine.Object) == null);            //True
Debug.Log((myObject as System.Object) == null);                 //False
Debug.Log(myObject?.name);                                      //MissingReferenceException
Debug.Log((myObject ?? yourObject) == myObject ? false : true); //False
Debug.Log(myObject is null);                                    //False

같은 객체에 대한 null 체크인데 방법에 따라 결과가 다르다. 유니티 오브젝트와의 == null은 파괴된 걸 감지하지만, 나머지는 전부 아직 살아있다고 판단한다. null이면서 null이 아닌 것이다.
이것이 Unity의 Fake Null이다.

원인

이걸 이해하려면 Unity가 C# 코드를 어떻게 실행하는지부터 알아야 한다.
Unity에서 게임 로직은 C#으로 작성하지만, 엔진의 핵심은 C++로 되어 있다.
이 구조 때문에 GameObject, Transform 같은 것들은 실제 데이터는 C++ 네이티브 메모리에 존재하고, C# 쪽에는 그 네이티브 객체를 가리키는 래퍼 객체가 있는 구조가 된다.

[C# 래퍼 객체] -> [C++ 네이티브 객체]

Destroy()를 호출하면 C++ 쪽 네이티브 객체는 파괴되지만, C# 쪽 래퍼 객체는 가비지 컬렉터가 수거할 때까지 메모리에 그대로 남아 있다. C# 관점에서 그 변수는 여전히 유효한 참조를 들고 있는 상태가 된다.
C# 기준으로는 살아있지만 C++에서는 이미 죽은 객체. 이것이 Fake Null이다.

해결책

Unity는 이 문제를 처리하기 위해 UnityEngine.Object에서 == 연산자를 오버로드했다.

public static bool operator ==(Object x, Object y)
{
    return CompareBaseObjects(x, y);
}

private static bool CompareBaseObjects(Object lhs, Object rhs)
{
    bool flag = (object)lhs == null;
    bool flag2 = (object)rhs == null;
    if (flag2 && flag)
    {
        return true;
    }

    if (flag2)
    {
        return !IsNativeObjectAlive(lhs);
    }

    if (flag)
    {
        return !IsNativeObjectAlive(rhs);
    }

    return lhs.m_InstanceID == rhs.m_InstanceID;
}

주소가 비어있는지만 보는 게 아니라 래퍼 객체 내부의 네이티브 포인터가 유효한지를 확인해서, 파괴된 객체에 대해 == null이 true를 반환하도록 만든 것이다.
!=과 !도 오버로드 되어 있고 덕분에 != null이나 !myObject 같은 코드도 직관적으로 동작한다.

한계

?., ??, is null은 오버로드할 수 있는 연산자가 아니기 때문에 포인터가 유효한지에 관계없이 주소가 비어있는지만 확인하고, Destroy()가 호출된 이후에도 객체를 null로 인식하지 못한다.
System.Object로의 형변환 이후의 == 연산자를 이용한 비교 역시 유니티가 오버로드한 연산자를 거치지 않기 때문에 마찬가지이다.

대안?

여기까지 글을 읽었으면 일견 Destroy 시점에 래퍼 객체를 가리키는 변수에 null을 넣어주면 모든 문제가 해결되는 게 아닌가 하는 생각이 들 수 있다. 하지만 이것도 문제가 있다.

GameObject myObject = new GameObject();
GameObject yourObject = myObject;

이런 코드를 실행한 후의 참조 관계를 간단한 도식으로 표현하면 이렇게 된다.

[MyObject: 0xABCD] -> [GameObject (0xABCD)] <- [YourObject: 0xABCD]

이런 상태에서 myObject를 Destroy하면서 null로 값을 바꿔주어도 메모리에 있는 값은 그대로 남아있고 그 메모리를 참조하는 다른 변수도 그대로 남아있다.
C# 런타임에는 “이 객체를 참조하는 모든 변수를 찾아라” 같은 기능이 없기 때문에, 흩어져 있는 모든 변수를 null로 바꿔줄 방법이 없다.

그래서 Unity는 어쩔 수 없이 Destroy()를 호출할 때 메모리의 네이티브 객체 주소만 null로 설정하고 연산자를 오버로드해서 주소까지 확인하는 방식을 채택한 것이다.

[MyObject: 0xABCD] -> [GameObject (0xABCD) nativePtr: 0x0000] <- [YourObject: 0xABCD]

이 과정에서 네이티브 객체의 파괴 여부와 상관없이 변수의 값만 확인하는 ?., ??, is null에서는 Fake Null 문제가 발생하게 된다.

결론

//안전한 방법
if (myComponent == null)
if (myComponent != null)
if (!myComponent)

//위험한 방법
myComponent?.DoSomething();
var ourComponent = myComponent ?? yourComponent;
if (myComponent is null)

Unity 오브젝트의 null 여부를 확인할 때는 ==이나 !=, !를 사용하고, ?., ??, is null은 사용하지 말자.

TMP 폰트의 Underlay, Outline 등의 효과를 사용할 때 시각적 오류가 발생한다면, 폰트의 Padding을 Sampling Point Size의 10% 정도로 맞추자.

문제

유니티에서 현지화 관련 작업을 하면서 다른 언어를 지원하는 폰트를 추가하고 적용한 뒤 테스트를 하고 있는데 귀찮은 일이 생겼다.

텍스트는 문제없이 나오는데 뒷부분에 검은 상자가 생겼다.
TMP 텍스트에 Underlay를 통해서 아웃라인을 구현한 상태인데 이걸 비활성화하면 문제가 사라지는 걸로 봐서 이게 어떤 식으로든 관여하고 있다는 것까지는 알겠는데, 일단 정확한 원인을 알기 위해 더 조사해보기로 했다.

원인

문제의 근원은 TTF 폰트 파일을 Font Asset Creator를 이용해서 TMP 폰트로 변환하는 과정이었다.
여기서 Sampling Point Size와 Padding 그리고 SP/PD Ratio에 대해 간단히 짚고 가겠다.

Sampling Point Size는 각 글자가 아틀라스에서 어느 정도의 공간을 차지할지를 결정한다. 값이 크면 더 많은 공간을 사용하게 되고 더 또렷한 글자를 표현할 수 있게 된다.
Padding은 각 글자 사이의 빈 공간을 결정한다. 이 공간은 Outline 같은 효과가 렌더링될 때 사용하는 여유 영역이기도 하다.
SP/PD Ratio는 단순히 이 두 값의 비율이다. 이름만 보면 SP / PD처럼 보이지만, 실제로는 PD / SP로 계산된다.
이 값의 비율을 적절하게 유지해야 하는데 너무 커지면 Padding이 너무 많은 공간을 차지하고 있다는 것이고 글자가 사용할 수 있는 공간이 줄어들게 된다.
반대로 값이 작아지면 글자 간의 여유 공간이 적어지는데 이런 경우에는 다른 글자가 섞여서 표현될 수 있다.

필자의 경우에는 Underlay를 통해서 아웃라인 효과를 구현하던 것과 Padding이 너무 작은 것이 문제였다.
Underlay는 아틀라스의 UV를 오프셋만큼 이동시킨 위치의 값을 읽고 사용하는데, 패딩이 글자 크기에 비해 너무 작으면 다른 글자 부분의 데이터를 읽게 되고 오작동하는 것이다.

해결

Font Asset Creator에서 TMP 폰트를 만들 때 Sampling Point Size와 Padding의 비율을 적절하게 조절하자.
Sampling Point는 기본적으로 Auto Sizing 모드이지만 값을 설정할 수 있게 바꿀 수 있고, Padding은 값을 직접 수정할 수 있다.
일반적으로 10% 정도가 적절하다고 여겨지는 것 같고, 필자의 경우에도 그 정도로 조절하니 문제가 해결됐다.

제목: 残灯花火
작곡: Orangestar
작사: Orangestar
가수: 初音ミク

2015년 7월 25일, Orangestar가 하츠네 미쿠를 보컬로 하여 투고한 곡으로,
첫 앨범 미완성 에이트 비트에 5번째 트랙으로 수록된 노래이다.

감상

반주 부분은 기타가 중심을 잘 잡고 있고 그 위에 드럼과 하이햇이 얹히면서 곡이 단조로워지지 않게 잡아줘서 반주만으로도 충분히 좋다.
보컬도 가사를 끊지 않고 이어가면서도 곳곳에 감정을 실어 포인트를 주는데 이 완급 조절이 좋은 반주와 맞물려서 이 노래를 위대하다고 표현하는 데 부족함이 없다.

5/5

해석

Orangestar는 보컬로이드 씬에서 유명한 프로듀서이면서, 인터뷰에서 기독교적 가치를 노래에 담아낸다고 말한 적이 있을 만큼 가사에 의미를 두는 프로듀서이기도 하다.
그럼에도 가사를 본격적으로 분석한 글은 찾기 어렵고, 대부분이 단순한 번역에 그쳤다.
개인적으로 좋아하던 프로듀서이기도 해서, 직접 한 번 깊이 있게 해석해보기로 했다.

가사 해석에 앞서 먼저 제목부터 짚고 넘어가면
“잔등”은 꺼져가는 등불, “불꽃”은 불꽃놀이. 합치면 ‘꺼져가는 불꽃놀이’다.
불꽃놀이에서 가장 아름다운 순간은 터지면서 하늘에 빛이 퍼지는 순간이고, 동시에 그 순간은 사라지기 시작하는 순간이기도 하다.
이 곡에서 두 사람의 관계와도 같은데, 함께 있는 지금이 가장 아름다운 순간이지만 그 아름다움은 이미 헤어짐을 품고 있다.

夜焦りの暗がり 去りし夏の宵
요아세리노 쿠라가리 사리시 나츠노 요이
초조한 밤의 어둠 떠나가는 여름 저녁
二人眺めてるの
후타리 나가메테루노
둘이서 바라보고 있어
闇空に放たれるほど儚く
야미조라니 하나타레루호도 하카나쿠
어두운 하늘에 퍼질 정도로 덧없이
降らせ今この静に 灯りはまだ遠く
후라세 이마 코노 세이니 아카리와 마다 토오쿠
내리는 지금 이 고요함에 불빛은 아직 멀어
揺らぎ揺らがれるほど
유라기 유라가레루호도
흔들려 흔들릴 정도로
ただ浮かべば消える空を見上げた
타다 우카베바 키에루 소라오 미아게타
그저 떠오르면 사라지는 하늘을 올려다봤어

도입부부터 이미 그 구도가 선명하다.
“둘이서 바라보고 있어”라고 하면서도 “초조한”, “떠나가는” 같은 표현이 겹겹이 깔려 있다.
그리고 가장 핵심적인 한 줄은 “그저 떠오르면 사라지는 하늘을 올려다봤어”다.
떠오르면 사라진다는 이 구조는 곡의 맨 끝, 꿈에서 상대를 만나지만 결국 사라져버리는 장면과 정확히 겹쳐진다.

あなたに問いかける
아나타니 토이카케루
당신에게 물어봤어
寂しさと別れは切り離されぬのか
사비시사토 와카레와 키리하나사레누노카
외로움과 이별은 떼어놓을 수 없는 걸까
響る空花火の散るを見遣って
나루 소라 하나비노 치루오 미얏테
퍼지는 하늘 불꽃이 흩어지는 걸 바라보며

화자는 상대에게 “외로움과 이별은 떼어놓을 수 없는 걸까”라고 묻는다.
이 질문은 답을 기대하는 것보다는 이미 답을 알고 있는 사람의 체념에 더 가깝다.
화자는 이별 후에 외로움이 올 것을 이미 확신하고 있으면서도, 그 감정을 질문이라는 형식 뒤에 숨겨서 넌지시 말할 뿐이다.
그걸 상대에게 내비치면서도 위로받기를 바라는 것이 아니라 그저 스스로 되뇌고 있을 뿐이다.

夏が僕らを染め上げる光になって
나츠가 보쿠라오 소메아게루 히카리니 낫테
여름이 우리를 물들이는 빛이 되어
またねを言わさぬまま
마타네오 이와사누마마
다시 보자고 말하지 못한 채로
君が僕の手を強く握れる
키미가 보쿠노 테오 츠요쿠 니기레루
네가 나의 손을 세게 쥐는
微かな意味を探すのかな
카스카나 이미오 사가스노카나
희미한 의미를 찾게 되는 걸까

상대는 손을 세게 잡는 행동으로 마음을 표현하고 있는 반면,
화자는 다시 볼 수 없다는 것을 알기 때문에, 평범한 “다시 보자”는 말조차 하지 못하고
화자는 그 행동의 “의미”만 분석하고 있다.

夜風に凪を見る 話は無いのに
요카제니 나기오 미루 하나시와 나이노니
밤바람에 잔잔한 바다를 바라봐 이야기는 없지만
二人眺めてるの
후타리 나가메테루노
둘이서 바라보고 있어
ただ浮かぶ月夜灯りの下
타다 우카부 츠키요아카리노 시타
그저 떠오른 달밤의 불빛 아래
もう行かなきゃじゃあねまた明日ね
모오 이카나캬 자아네 마타 아시타네
이제 가야해 그럼 내일 또 보자
なんて言い出すことですら儘ならぬ今の
난테 이이다스 코토데스라 마마나라누 이마노
라고 말하는 것조차 뜻대로 되지 않는 지금
二人頭上に輝けるほど満たしている
후타리 즈조오니 카가야케루호도 미타시테이루
두 사람의 머리 위에서 빛날 정도로 채워져있어

시간이 멈춘 듯한 고요한 바다를 둘이서 가만히 바라보고만 있다.
화자는 “이제 가야해 그럼 내일 또 보자”라는 평범한 인사조차 꺼내지도, 그렇다고 먼저 자리를 뜨지도 않는다.
이별을 알면서도 이 순간을 한 초라도 더 끌고 싶은 화자의 심리가 이 정적 속에 고스란히 녹아 있다.

らら君が嘘を語り出して
라라 키미가 우소오 카타리다시테
라라 네가 거짓말을 하기 시작해
またねを言わんとするなら
마타네오 이완토스루나라
다시 보자고 말할 거라면
忘れないでと涙声語り合っても
와스레나이데토 나미다고에 카타리앗테모
잊지 말아달라고 울먹이며 서로 이야기를 나눠봤자
意味など無いのかな
이미나도 나이노카나
의미 따윈 없는 걸까

화자의 모순이 가장 선명하게 드러나는 부분이다.
직전까지 화자는 “내일 또 보자”는 말을 꺼내고 싶었지만 꺼내지 못한다.
그런데 정작 상대가 그 말을 꺼내자 화자는 그것을 “거짓말”이라 부르고,
서로 울먹이며 이야기하고 있지만 “의미”가 없을지도 모른다고 생각한다.
화자는 지킬 수 없는 약속을 거짓말이라고 생각해서 “다시 보자”는 말도,
아무 말도 하지 않고 헤어지는 것도,
이러지도 저러지도 못 한다.

夜焦りの暗がり 去りし夏の宵
요아세리노 쿠라가리 사리시 나츠노 요이
초조한 밤의 어둠 떠나가는 여름 저녁
二人眺めてるの
후타리 나가메테루노
둘이서 바라보고 있어
響る空花火の散るを
나루 소라 하나비노 치루오
퍼지는 하늘 불꽃이 흩어지는 걸
笑って
와랏테
웃으며
夏が僕らを染め上げる光になって
나츠가 보쿠라오 소메아게루 히카리니 낫테
여름이 우리를 물들이는 빛이 되어
またねを言わさぬまま
마타네오 이와사누마마
다시 보자고 말하지 못한 채로
闇夜を最後に飾らせる光に
야미요오 사이고니 카자라세루 히카리니
어두운 밤을 마지막으로 장식하는 빛에서
僕らは意味を探すのかな
보쿠라와 이미오 사가스노카나
우리들은 의미를 찾는 걸까

이 곡에서 “意味”는 세 번 등장한다.
그리고 등장할 때마다 둘의 연결이 점점 약해진다.
첫 번째는 손을 잡는 직접 접촉, 두 번째는 같이 울며 감정을 나누는 것,
세 번째에서는 말도 접촉도 없이 단지 같은 불꽃놀이를 바라보는 것 뿐이다.
가장 강한 연결이었던 첫 번째에서조차 “희미한” 의미밖에 찾지 못했는데, 그보다 훨씬 약한 이 마지막 단계에서도 여전히 의미를 묻고 있다.
이게 마지막이라는 걸 알기 때문이다.
이번에는 혼자가 아닌 “우리들은” 의미를 찾는 걸까 라고 묻는다. 마지막 순간에서야 상대도 같은 마음이기를 바라고 있는 것이다.

夢を見たんだ君がまた大人になって
유메오 미탄다 키미가 마타 오토나니 낫테
꿈을 꿨어 네가 다시 어른이 되어
またねも言わさぬまま
마타네모 이와사누마마
다시 보자는 말도 하지 못한 채로
忘れないよとかすれて
와스레나이요토 카스레테
잊지 않을게라는 말이 흐릿해지며
消えてしまうけど
키에테시마우케도
사라져버리겠지만
それは未来の話
소레와 미라이노 하나시
그것은 미래의 이야기

“またねを”(다시 보자는 말을)가 곡에서 세 번 반복되었는데, 마지막에서 “またねも”(다시 보자는 말도)로 바뀐다.
처음에는 하고 싶었지만 하지 않은 것이, 마지막에는 하고 싶어도 할 수 없게 된 것이다.
곧 “잊지 않을게”라고 뱉은 말도 흐릿해지며 사라져버린다.
이 곡 내내 화자는 항상 생각하는 사람이었다.
손을 잡으면 거기서 의미를 찾고, 울면서 말해봤자 소용없다고 생각하고, 같이 하늘을 봐도 의미를 되묻고.
마지막까지도 거짓말이 될 수 있는 “다시 보자”는 말은 하지 않고 거짓말이 되지 않는 “잊지 않을게”라는 말만 입 밖으로 뱉는다.
하지만 화자는 마지막에 더 이상 생각하려 하지 않는다. 전부 사라질 거라는 걸 알지만, 지금은 그걸 받아들이지 않기로 한다.
“그것은 미래의 이야기”니까.

블루아카이브나 명일방주 등 서브컬쳐 게임을 보면 가챠라는 시스템이 있고, 유저는 3성 학생이나 6성 오퍼레이터같은 본인이 원하는 캐릭터를 뽑기 위해서 가챠를 한다.
원하는 캐릭터가 쉽게 나오면 과금할 이유가 없으므로 게임사는 돈을 벌 수 없기 때문에 이러한 캐릭터들은 나올 확률이 낮게 설정되어 있고 대부분은 낮은 등급의 캐릭터가 나온다.

이 때 이러한 희귀한 캐릭터가 포함되어 있을 때 블루아카이브의 “분홍 봉투”나 명일방주의 가방에서 나오는 빛의 색 변화처럼, 높은 등급의 캐릭터가 포함되어 있으면 연출이 달라진다.
필자는 이 연출을 보고, “이러한 연출이 없어야 갑자기 희귀한 캐릭터가 나왔을 때의 쾌감이 커지고 뽑은 목록을 보기도 전에 실망하는 경우가 없지 않을까?”와 같은 의문이 들었고, 그럼에도 불구하고 대부분의 서브컬쳐 게임에서 연출이 바뀌는 시스템을 채용하는 이유를 고민해보았다.
대부분의 게임사가 넣고 있으니 연출을 넣는 쪽이 이득이라는 건 뻔하겠지만, 그 이유가 궁금했다.

생각

생각 끝에 다다른 결론은 “가챠는 가챠이기 때문이다”였다.
가챠라는 것은 당첨보다 꽝이 훨씬 많을 수밖에 없다. 슬롯 머신이든 지금 주제인 게임에서의 뽑기이든. 그래야 도박장이든 게임사든 돈을 벌테니까.
하지만 뽑기를 하는 유저입장에서는 꽝이 나오면 실망하고 좌절하게 되고 결국 뽑기를 멈출 수밖에 없다. 그리고 그렇게 되면 게임사는 돈을 벌지 못한다.
그러면 꽝을 많이 줘도 유저가 계속해서 뽑기를 하게 만들어야 하고, 그렇게 하려면 꽝을 뽑았을 때 실망감을 줄여야 한다.
기대가 크면 실망도 큰 법이니 이러한 연출을 넣음으로써 미리 6성이 나오지 않았다는 걸 유저가 알 수 있고 꽝이 나왔을 때의 실망감 또한 줄어들 것이다.

물론 이런 장치가 없을 때의 쾌감도 있겠지만, 전술했듯이 가챠라는 것 자체가 꽝이 많고 돈을 벌기 위한 수단으로써 계속 뽑기를 하게 만들어야 하기 때문에, 쾌감보다는 피로감을 줄이는 게 합리적일 것이다.

또한 유저가 가챠를 뽑기 버튼을 누르는 순간부터 결과를 확인하기까지의 과정 자체를 하나의 컨텐츠로 의식하고 즐길 거리로 느낄 수 있다. 커뮤니티의 디시콘이나 아카콘을 보면 이런 것을 소재로 한 콘이 한두 개 정도는 있고 2차 창작에서도 소재로 사용되기도 한다.

거기에 더해 유저들이 가챠 결과를 공유할 때 연출이 있어야 스크린샷이나 영상이 볼거리가 된다.
텍스트로 “6성 나왔다”고 말하는 것과 영상을 올리는 것은 전달력이 다르다. 게임사 입장에서는 이것이 곧 유저가 자발적으로 만들어주는 홍보가 된다.

결론

대부분의 게임사가 채용하고 있는 데는 이유가 있다. 꽝이 대부분인 가챠의 특성상 피로감을 줄이는 쪽이 더 합리적이다.

거기에 더해 이러한 연출은 뽑기 버튼을 누르는 순간부터 결과를 확인하기까지의 과정 자체를 하나의 컨텐츠로 느낄 수 있게 해주며 밈이나 2차 창작의 소재가 되기도 한다.
유저들이 자발적으로 가챠 영상이나 스크린샷을 공유하면서 게임에 대한 관심을 끌어오는 것 역시 연출이 있기에 가능한 일이다.

물론 결과를 전혀 모른 채 갑자기 6성이 나왔을 때의 짜릿함은 연출이 있을 때는 느끼기 힘들다.
하지만 일부 게임에서는 일반 연출로 시작했다가 도중에 고등급 연출로 바뀌는 장치를 두어, 피로감을 줄이면서도 연출이 없는 방식의 장점까지 챙기고 있다.

제목: しあわせになんてならないで
작곡: Aiobahn
작사: ナナヲアカリ
보컬: ナナヲアカリ

감상

노래 가사의 처음과 끝 부분의 대비 구조가 좋은데,

오랫동안 함께했던 사람이 시간이 흐르면서 다른 길을 걷게 되고, 더 이상 곁에 있을 수 없게 된다.
화자는 아쉽지만, “평생 아이일 수는 없기” 때문에 겉으로는 아무렇지 않은 척 하지만 속으로는 “행복해지지 말아줘”라고 말한다.

그러면서도 화자는 “앞으로도 더 변해 가겠지”, “당연한 거였어 전부 다”라고 말하면서,
변해가는 것이 자연스러운 일이라는 것을 조금씩 받아들인다.

그러다 결국 마지막에는 그 사람의 행복을 진심으로 빌게 된다.
“평생 아이일 수는 없기” 때문에, 이번에는 마음속으로 “행복해줘”라고 말한다.
같은 이유를 대면서 완전히 반대되는 결론에 도달하는 구조가 좋다.

특히 마지막 부분에서의 “행복해줘”는 “이젠 강한 척하지 않아도 돼”, “지금까지와는 다른 두 사람으로”라는 가사와도 맞물리면서,
각자 다른 모습의 두 사람으로서 각자의 자리에서 행복해지자는, 상대에게 들려주는 인사이자 동시에 자기 자신을 설득하는 의미로도 해석 가능해서 중의적으로 해석 가능한 게 인상적이다.

음악적으로는 Aiobahn의 곡답게 반주에 사용되는 소리와 리듬이 좋고,
거기에 맞춰 가사를 끊어 부르는 것도 반주와 잘 어울린다.

본인이 홈서버 겸 장난감으로 사용하는 미니PC에 VMware를 설치하고 CentOS7을 설치하여 사용하고 있었다.
처음에는 가상머신의 저장공간을 128GB로 설정했었는데, 시간이 지나면서 다양한 파일들을 저장하다 보니 저장공간을 늘릴 필요가 생겼다.
VMware 가상머신 설정에서 저장공간을 늘려주는 건 어렵지 않았지만 CentOS7에서도 추가로 작업을 해줘야 했다.

문제 상황

총 128GB 중에 120GB는 주 파티션(sda1)으로 사용하고 있었고 8GB는 스왑 파티션(sda2)으로 사용하고 있었는데 스왑 파티션이 주 파티션의 뒤쪽에 위치하고 있었고, 그래서 단순히 주 파티션의 크기를 확장하는 방법은 불가능했다.

당시의 파티션 배치인데 파티션은 연속된 공간에 위치해야 하므로 남은 공간을 사용하려면 중간에 끼어있는 스왑 파티션의 뒤쪽에 새로운 파티션을 만들어야 한다.

이와 같이 파티션을 하나 추가하는 방안이 가장 간단하겠지만 파티션이 두 개로 나눠져 있는 것은 곤란하다.
필자는 파티션의 개수를 최대한 적게 유지하고 싶었고, 스왑 파티션을 디스크의 맨 뒤로 이동시키고 기존의 파티션을 확장하기로 했다.

해결 과정

먼저 VMware에서 저장공간을 늘려주기 전에 상태를 확인해봤다.

fdisk -l # 파티션 확인

Disk /dev/sda: 137.4 GB, 137438953472 bytes, 268435456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000937ae

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   251660287   125829120   83  Linux
/dev/sda2       251660288   268435455     8387584   82  Linux swap / Solaris

Disk bytes 부분을 보면 현재 디스크 크기인 137,438,953,472 / 1024 ^ 3 = 128GiB를 확인할 수 있다.
(VMware에서는 128”GB”로 표기되는데 적용은 GiB 단위로 되는 차이가 있다.)

이제 VMware에서 저장공간을 늘려준 후 같은 명령어를 실행해봤다.

fdisk -l # 파티션 확인

Disk /dev/sda: 2117.4 GB, 2117418876928 bytes, 4135583744 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000937ae

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   251660287   125829120   83  Linux
/dev/sda2       251660288   268435455     8387584   82  Linux swap / Solaris

이전과 다르게 디스크 크기가 2,117,418,876,928 / 1024 ^ 3 = 1972GiB로 늘어난 것을 확인할 수 있다.
하지만 sda1과 sda2를 비롯한 파티션의 크기는 달라지지 않았다.

이제 파티션 크기를 수정해보겠다.

fdisk /dev/sda # 파티션 편집 도구 실행


d # 파티션 삭제
2 # 2번 파티션(스왑 파티션) 삭제

n # 파티션 생성
p # 주 파티션 선택
2 # 파티션 번호 2로 지정
4118808576 # 시작 섹터 위치 ->각자 환경에 맞게 설정<-
4135563743 # 끝 섹터 위치 ->각자 환경에 맞게 설정<-

t # 파티션 유형 변경
2 # 2번 파티션 선택
82 # Linux 스왑 파티션 유형 코드


d # 파티션 삭제
1 # 1번 파티션(루트 파티션) 삭제

n # 파티션 생성
p # 주 파티션 선택
1 # 파티션 번호 1로 지정
2048 # 시작 섹터 위치 ->각자 환경에 맞게 설정<-
4118808575 # 끝 섹터 위치 ->각자 환경에 맞게 설정<-

a # 부트 플래그 설정
1 # 1번 파티션에 부트 플래그 설정


w # 저장 및 종료


reboot # 재부팅

재부팅이 끝나고 파티션과 파일 시스템을 확인해봤다.

fdisk -l # 파티션 확인

Disk /dev/sda: 2117.4 GB, 2117418876928 bytes, 4135583744 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000937ae

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048  4118808575  2059403264   83  Linux
/dev/sda2      4118808576  4135583743     8387584   82  Linux swap / Solaris


df -h # 파일 시스템 확인

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        7.8G     0  7.8G   0% /dev
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           7.8G   13M  7.8G   1% /run
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda1       120G   92G   29G  77% /
tmpfs           1.6G   20K  1.6G   1% /run/user/1000
/dev/sr0        4.4G  4.4G     0 100% /run/media/CentOS7/CentOS 7 x86_64

파티션의 크기는 확장되었지만 파일 시스템의 크기는 그대로인 것을 확인할 수 있다.

아래 명령어를 이용해서 파일 시스템을 확장시킬 수 있다.

xfs_growfs / # 파일 시스템 확장

같은 명령어를 다시 실행해보면 디스크 크기, 파티션 크기, 파일 시스템 크기 모두 정상적으로 나오는 것을 확인할 수 있다.

fdisk -l # 파티션 확인

Disk /dev/sda: 2117.4 GB, 2117418876928 bytes, 4135583744 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000937ae

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048  4118808575  2059403264   83  Linux
/dev/sda2      4118808576  4135583743     8387584   82  Linux swap / Solaris


df -h # 파일 시스템 확인

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        7.8G     0  7.8G   0% /dev
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           7.8G   13M  7.8G   1% /run
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda1       2.0T   92G  1.9T   5% /
tmpfs           1.6G   20K  1.6G   1% /run/user/1000
/dev/sr0        4.4G  4.4G     0 100% /run/media/CentOS7/CentOS 7 x86_64

영어로는 Tornality.
하나의 으뜸 음을 기준으로 다른 음들이 위계질서를 이루는 체계이다.

조표

영어로는 Key signatures.
악보에서 조성을 나타내기 위해 사용된다.
♯를 이용하는 7종류, ♭을 이용하는 7종류, 총 14종류이다.

♯는 파 도 솔 레 라 미 시 순서로 붙는다.
♭은 ♯의 역순인 시 미 라 레 솔 도 파 순서로 붙는다.

조

영어로는 Key.
조성을 원리라고 한다면 그 원리를 어떤 으뜸음과 음계로 실현되었는지를 나타내는 이름이다.
하나의 조표에 두 개의 조가 해당한다.
장조(Major Key): 장음계를 사용한 음악
단조(minor Key): 단음계를 사용한 음악

장조 조이름 판별

♯조는 조표의 마지막 ♯에서 단2도(반음) 높은 음이 조이름(으뜸음)이 된다.

C♯ -> D -> D Major key

B♯ -> C♯ -> C♯ Major key

♭조는 조표의 마지막 ♭에서 하나 이전의 ♭음이 조이름이 된다.

A♭ -> E♭ -> E♭ Major key

원칙적으로는 완전4도 아래음이 조이름이 되지만 하나 이전의 ♭음을 이용하는 것이 더 간편하다.
B♭ -> F Major key

단조 조이름 판별

단조의 경우에는 장조의 으뜸음의 단3도 아래 음이 조이름이 된다.

D -> B -> b minor key

E -> C♯ -> c♯ minor key

영어로는 Chord.
두 개 이상의 음들이 동시에 내는 소리이다.

3화음

가장 아래의 음에서 3도 음정을 2번 쌓은 화음이다.
아래 음부터 근음, 3음, 5음이라고 부른다.

3화음의 4가지 분류

3화음은 두 개의 3도 음정으로 이루어져 있으며, 3도 음정은 포함된 반음의 개수에 따라 장3도와 단3도로 나눌 수 있다.
따라서 3화음은 4가지로 분류할 수 있다.

| 첫 번째 음정 / 두 번째 음정 | 장3도 | 단3도 |
| --- | --- | --- |
| 장3도 | augmented | Major |
| 단3도 | minor | diminished |
```alignment
CCC
CCC
CCC
CCC

아래는 각 음의 Major 코드

Major triad의 소리는 정직하고 딱 떨어지는 느낌.
minor triad의 소리는 우울하고 슬픈 느낌.
augmented triad의 소리는 상승하는 느낌.
diminished triad의 소리는 뭉쳐있는 느낌.

각각 다양한 표기 방법이 있다.

| 코드 | 표기법 |
| --- | --- | --- |
| C Major triad | CMajor, CM, C |
| C minor triad | Cminor, Cm, C- |
| C augmented triad | Caugmented, Caug, C+ |
| C diminished triad | Cdiminished, Cdim, C° |
```alignment
CC
CC
CC
CC
CC

3화음 코드들의 관계

♯나 ♭과 같은 임시표를 3음과 5음에 적절히 붙임으로써 다른 화음으로 변환시킬 수 있다.

| --- | --- | --- | --- | --- | --- | --- |
| aug | → 5♭ | Major | → 3♭ | minor | → 5♭ | dim |
| ^^ | ← 5♯ | ^^ | ← 3♯ | ^^ | ← 5♯ | ^^ |
```alignment
CCCCCCC
CCCCCCC
CCCCCCC
CCCCCCC

sus4 코드

Major 코드 기준으로 3음 위로 단2도(반음) 차이가 나는 4음을 추가하고 3음을 제거한 화음.

Csus4

Fsus4

3화음의 자리바꿈

3화음의 가장 낮은 음을 근음이 아닌 3음이나 5음으로 바꾸는 것. 전위라고도 부름.
근음이 올라가서 3음이 마지막이 되는 경우 1전위, 근음과 3음이 올라가서 5음이 마지막이 되는 경우 2전위라고 한다.
표기는 G♯m/D♯ 이런 식으로 하고, 원래의 코드를 왼쪽에, 가장 낮은 음을 오른쪽에 적는다.

Caug/G♯

개발

특정 범위 사이의 값 정규화

개발을 하다 보면 특정 범위의 값을 0과 1 사이로 변환해야 할 일이 있습니다.
예를 들어 7은 0으로 28은 1로, 중간값인 17.5는 0.5로 이런 식으로요.
일견 쉬워보이지만 막상 구현하려고 하면 생각보다 어렵습니다.
이럴 때는 연립일차방정식을 이용해서 해결할 수 있습니다.

이런 꼴의 연립일차방정식의 y에 0과 1을 x에 7과 28을 대입하고 방정식을 풀어줍니다.
a와 b의 값을 알아내고 그 값을 이용해서 이런 방정식을 만들 수 있습니다.

예시로 들었던 값을 대입해보면 원하는 값이 나오는 것을 확인할 수 있습니다.

이런 식은 Min-Max Normalization(최소-최대 정규화) 공식을 사용해서 더 쉽게 구해낼 수도 있습니다.

여기서 x는 정규화할 값, min은 범위의 최소값, max는 범위의 최대값입니다.

이 공식에 예시로 사용되었던 값을 대입하면:

위에서 연립방정식으로 유도한 것과 동일한 결과가 나옵니다.