급하게 기획해서 진행한 스트리밍 강좌라 그런지 아쉬운 점이 많네요. 다음엔 좀 더 잘 준비해서 해보겠습니다. 그리고 아쉬운 소식으로는 지난 1년간 저와 함께 열심히 90여편의 영상을 제작해왔던 마이크가 수명이 다해간다는 겁니다. 그래서 강좌 중간에 사운드가 나간 부분이 많아서 다시 녹음해서 올린 부분이 조금 있습니다. 거기에 무려 한 시간 짜리 영상이라 자막은 언제 제작할 수 있을지 눈 앞이 깜깜하네요 ㅜㅜ
여러분들과 함께 2-3년간 블로그를 통해서 유니티나 언리얼 엔진 등으로 게임 개발하는 방법을 공부하고 기능들을 소개해온 베르입니다.
이 블로그를 처음 개설한 이유는 인터넷에서 개발과 관련된 자료를 찾아서 공부하고, 나중에 다시 그 자료를 찾으려고 했을 때, 없어진 자료들이 너무나 많아서 느낀 답답함과, 자료를 공유해주신 고마운 분들이지만, 너무 본인 위주의 간략한 설명으로 자료를 따라서 공부하기 어려운 점을 누가 보아도 쉽게 이해할 수 있게 글을 써보자는 욕심이었습니다.
의도한 대로 잘되어 왔는지는 아직 확신할 수는 없지만, 많은 분들이 찾아주신 결과로 현재까지 약 40만여 회의 방문수를 기록하고 있습니다.
하지만, 아직도 아쉬운 점은 게임 개발은 변화가 많고 움직임이 많은 것이기 때문에 순수한 글로써는 제가 의도한 바를 100% 전달하고 있는지 확신할 수 없었습니다. 그래서 처음에는 글에 이미지를 넣고, 이미지에 빨간 박스나 화살표로 강조하는 등의 표시를 해왔고, 개발된 결과로 움직이는 것을 보여드리기 위해서 gif로 찍어서 올리기까지 했습니다.
그렇게까지 해왔지만, 아직은 모자란 점이 많다고 생각하여, 백 번 듣는 것보다는 한 번 보는 것이 났다는 옛 말에 따라 좀 더 확실하게 보여드리고 알려드리기 위해 유튜브 채널을 개설하게 되었습니다.
지난 한 달간 최소한의 콘텐츠를 만들기 위해서 열심히 새로운 영상을 만들고 쌓아온 끝에 드디어 오픈하게 되었습니다.
아직은 기초적인 내용의 영상 밖에 없지만, 지금 블로그에 적힌 다른 포스트 역시 차근차근 영상화해서 찾아뵙겠습니다.
그리고 이 블로그 역시 차근차근 글로 보고 배우는 과정을 따라오시기를 위한 분들을 위해서 업데이트를 계속해서 이어나갈 예정입니다.
이게 무슨 의미인가 하면, 작업할 당시에는 내가 아는 코드였지만 시간이 지나면 자신도 본인의 코드를 이해하지 못하게 되는 경우가 있다는 뜻이다. 혼자서 하는 작업도 이럴진데, 타인과 하는 작업은 어떨까? 사람마다 코드 작성 타입은 각양각색이라 다른 사람의 코드를 읽어내기가 몇 배는 더 힘들어진다.
특히 혼자서 프로그래밍을 공부하던 사람이 다른 학생와 조별 프로그래밍 과제를 한다거나, 다른 개발자나 협업을 하게 되었을 때 자신의 평소 코딩 스타일과 다른 스타일의 코드를 만나게 되면 격렬한 동공지진을 일으키게 된다. 거기에 주석까지 없다면 혼란은 가중된다.
그럼 이제 읽기 좋은 코드를 만들기 위한 고민을 시작해보자.
코드 블럭 중괄호 스타일 { }
프로그래머들 사이에서 가장 뜨겁고 격렬한 이슈인 중괄호 문제부터 들어가보자. 중괄호 스타일 문제는 해외에서는 SVN[각주:1]에 코드 전체가 커밋되었길래 봤더니 중괄호 스타일을 전부 바꾸고 커밋했더라 "작업자를 찾아서 가만두지 않겠다" 라는 밈이 나올 정도이다.
이 문제는 크게 두 가지 계파로 나누어지는데 다음과 같다.
조건문이나 반복문 아래로 중괄호를 내리는 스타일 :
if (bCondition)
{
// Todo
}
else
{
// Todo
}
for (int i = 0; i < length; i++)
{
// Todo
}
while (bCondition)
{
// Todo
}
조건문이나 반복문 옆으로 중괄호를 붙이는 스타일 :
if (bCondition) {
// Todo
} else {
// Todo
}
for (int i = 0; i < length; i++) {
// Todo
}
while (bCondition) {
// Todo
}
아래로 중괄호를 내리는 스타일의 경우, 줄 수는 늘어나지만 코드 블럭의 시작과 끝을 명확히 알 수 있다는 장점이 있고, 옆으로 붙이는 스타일은 코드 시작과 끝을 명확하게 보기는 어렵지만 코드의 라인 수가 줄어서 한 눈에 더 많은 코드를 볼 수 있다는 장점이 있다.
사실 이 문제는 어떤 것이 옳다라고는 단정내려버리기 어려운 문제이지만, 딱 한 가지 나쁜 경우가 있다. 바로 이 두 가지 스타일을 섞어서 쓰는 것이다. 이 두 가지 스타일을 섞어서 쓰는 경우, 개발자들이 코드 블럭의 시작점을 쉽게 놓치게 되는 경우가 상습적으로 발생할 것이다. 이런 경우가 자주 발생한다면, 조건문이나 반복문 내부에 코드를 넣으려다 밖에다 써버린다든지, 그 반대의 경우가 쉽게 발생하고, 두 스타일을 사용하는 모든 개발자가 함께 고통받는 헬코딩이 열린다.
그렇기 때문에 이 중괄호 스타일 문제는 일반적으로 팀 내에서 다수를 차지하는 파의 스타일을 따라가든지, 아니면 프로젝트 관리자가 익숙한 스타일을 따라가게 된다.
조건문에 관련해서 중괄호 스타일 문제는 하나 더 있다. 그것은 조건문 내부 코드가 한 줄일 때, 중괄호를 생략하는 스타일이다.
if (bCondition)
{
// Todo
}
else
{
// Todo
}
if (bCondition)
// Todo
else
// Todo
컴파일러는 조건문 내부 코드가 한 줄일 때, 중괄호를 생략하는 것을 허용하는데, 다른 스타일은 대부분 취향에 따라 갈리는 것이라 팀의 규칙에 따라 정해진 스타일을 따라가기를 권하지만 이 스타일만큼은 반드시 지양하라고 권하고 싶다.
그 판단의 근거는 한 줄 짜리 조건문을 치면서 중괄호 { } 두 번을 안치고 "라인 두 줄을 아꼈다.", "코드 치는 속도가 더 빠르다"는 자그마한 이점을 취하기에는 그로 인해서 발생할 문제의 리스크가 훨씬 크기 때문이다. 이런 스타일은 조건문 내부에 코드를 추가할 일이 발생하면 생략했던 중괄호를 다시 추가해야할 뿐만 아니라, 중괄호를 추가하면서 라인을 이리저리 재정렬해야하는 번거로움이 발생하고, 정말로 기초적인 실수지만 조건문 블럭 안에 들어가야할 코드를 블럭 밖으로 빼버리게 만드는 실수를 일으키게 만드는 경우가 잦다.
그리고 이 문제는 신텍스 에러가 아닌 논리적인 버그를 발생시킬 확률이 매우 높으며 발견하기가 굉장히 까다로울 확률이 높다. 앞서 이야기 했듯이 조건문 블럭 안에 들어가야할 코드를 블럭 밖으로 빼버리는 실수는 간단한 실수지만, 인간은 무언가 문제를 찾을 때, 자신이 당연한 곳에서 실수하지 않을 것이라는 가정을 하는 경향이 강하기 때문에 문제를 찾으려고 코드를 훑는 와중에 이 "간단한 실수"를 몇 번이나 스쳐보고 지나갈 확률이 높다. 그리고 문제를 찾다 찾다 못찾아서 코드를 한 줄씩 검토하면서 나아갈 때 결국에 이 문제를 마주치게 된다.
네이밍 스타일
두 번째 이슈는 바로 변수와 함수, 클래스 등의 네이밍 스타일이다. 변수와 함수의 이름은 간단하게는 각 변수와 함수의 구별을 넘어서 무엇을 담는 변수인지, 무슨 일을 처리하는 함수인지를 알려주는 역할을 한다. 프로그래머는 개발을 진행하면서 무수히 많은 변수와 함수, 클래스 등을 만들며, 그 이름을 정해야 한다. 오죽하면 프로그래머의 가장 큰 고민이 변수 이름을 짓는 것이라는 말이 나왔겠는가?
절대 하지 말아야할 네이밍 스타일
중괄호를 다루는 법은 일반적으로 기호에 가까운 것이라 절대 금지한다라고 할 만한 방법이 크게 없지한 이름 짓기에서는 반드시 금지할 게 있다.
무성의한 네이밍
int i;
float f;
string a, b, c;
void foo();
bool function();
변수나 함수의 이름을 무성의하게 대충 짓는 것은 최악의 행위이다. 앞에서 이야기 했듯이 변수나 함수의 이름은 그 변수가 어떤 값을 담을 것인지, 그 함수가 어떤 작업을 처리할 것인지를 알려주는 역할을 한다. 하지만 대충 지어진 이름은 이 변수나 함수가 어떤 역할을 할 것인지를 명확하게 알 수 없게 만들기 때문에 코드의 흐름을 파악하기 위해서 모든 코드와 주석을 일일이 읽어야만 되게 만들어버린다. 그 코드를 작성한 본인이라고 하더라도 시간이 지나면 코드의 흐름을 까먹게 될 확률이 매우 높기 때문에 유지보수가 어려워지게 만든다.
그리고 기억하라 int i, int j가 허용되는 곳은 반복문의 인덱스로 사용되는 임시 변수뿐이다.
혼란스러운 네이밍
bool isCantMove;
뜻이 모호하거나 혼란스러운 네이밍 역시 피해야 한다. 특히 bool이나 boolean 같은 논리 변수에서 이러한 혼란을 피해야 하는데, 쉽게 혼란이 발생하는 경우는 논리 변수로 부정을 정의하는 경우이다. 위의 bool 변수의 경우 is Can't Move, 움직이지 못하는가? 를 정의하는데 이를 조건문에서 구현할 때는 아래와 같이 된다.
if (isCantMove)
{
// To do
}
if (!isCantMove)
{
// To do
}
이를 해석해보면 위 조건문은 "움직이지 못하는가?"이고 아래 조건문은 "움직이지 못하지 않는가?"가 된다. 이런 식으로 부정 조건을 정의하면 사람이 해석하는 과정에서 실수가 발생할 수 있다.
bool isMoveable;
이런 문제를 발생시키지 않기 위해서는 예시처럼 is Moveable, 움직일 수 있는가? 라고 정의하는 게 좋으며, 이는 조건문으로 :
if (isMoveable)
{
// To do
}
if (!isMoveable)
{
// To do
}
와 같이 구현되며, "움직일 수 있는가?", "움직이지 못하는가?"와 같이 자연스럽게 해석된다.
한글리쉬 네이밍
일부 개발자들은 아는 영어 단어가 많지 않거나 필요한 단어를 찾기 힘들다는 이유로 그냥 한국어 단어를 발음이 나는대로 영어로 적어서 변수를 만든다.
string juso;
int oNuelNalJja;
string yoil;
이러한 네이밍은 뭔가 굉장히 난독화된 코드처럼 보이며, 코드를 읽는 사람이 발음해보기 전에는 무슨 변수인지 알기가 어렵다. 한글 로마자 표기는 생각보다 읽기 어렵고 불편한 방식이다. 차라리 무슨 단어를 써야될지 모르겠다면 시간을 조금 더 써서 영어사전을 뒤져봐라.
권장하는 네이밍
변수나 함수, 클래스의 이름을 명확하게 짓는 것만으로도 코드의 가독성은 상당히 올라가며 유지보수 역시 쉬워진다.
변수 이름
변수 이름을 작성할 때는 기본적으로 명사를 사용한다.
int num;
숫자를 세는 변수를 예로 들어보자. 이러한 변수에는 num이라는 이름이 쉽게 붙여진다.
int count;
갯수를 세는 변수라면 조금 더 명확하게 count라는 이름을 써보자.
int itemCount;
여기서 더 명확하게 무엇의 갯수를 세는 변수인가?를 추가하면 itemCount가 된다.
public class Item
{
public int itemCount;
}
하지만 역으로 멤버 변수일 때는 또 다르다. Item 클래스에 같은 아이템을 여러 개 가질 수 있다고 했을 때, 같은 아이템의 갯수를 표현하는 itemCount 변수는 어떤가? 적절해보이는가?
Item item = new Item();
ShowItemCount(item.itemCount);
하지만 실제로 itemCount 변수를 사용할 때는 item.itemCount로 이름이 중복 표현된다.
public class Item
{
public int count;
}
Item item = new Item();
ShowItemCount(item.count);
이럴 때는 count라는 이름만 써줘도 무엇의 갯수인지 명확하게 표현된다.
List<Item> itemList = new List<Item>();
itemList.Count;
이와 같은 맥락으로 C#에서 리스트를 사용할 때도 리스트 안에 들어있는 요소의 갯수를 반환받을 때, Count라고 하지 ListInElementsCount라고 일일이 길게 변수이름을 정하지 않는 것과 같다.
함수 이름
함수는 기본적으로 어떤 일을 처리하는 행위이기 때문에 함수가 처리하고자 하는 행위를 이름으로 만드는 것이 기본이다. 이름을 짓는 방법은 동사, 동사+명사, 동사+부연 설명 혹은 반대로 명사+동사, 부연 설명+동사 방식으로 지어진다. 이른바 두괄식이냐 미괄식이냐 하는 것인데, 대부분 영미권에서는 동사가 앞으로 오는 두괄식을 선호한다. 선호 이전에도 두괄식이 이 함수가 어떤 행위를 하는지 빠르게 알 수 있기 때문에 보통은 자주 사용된다.
클래스 이름 역시 그 클래스 주로 하는 행위에 따라 지어지며 주로 명사로 이름을 짓는다. 게임에서 플레이어를 컨트롤 하는 클래스라면 PlayerController, 입력을 관리하는 클래스라면 InputManager와 같은 방식이다.
public class SendData { }
다만, 이런 방식으로 클래스가 처리하는 일을 이름으로 짓다보면 실수로 클래스의 이름을 함수 형식으로 짓는 경우들이 있다. 위의 예시처럼 데이터를 보내는 클래스를 정의하려고 할 때, "이 클래스는 데이터를 보내는 역할을 하니까 SendData로 지어야겠다"라고 하는 경우다. SendData라는 이름은 동사+명사의 형태로 클래스 작명법보다는 함수 작명법에 가까운데 클래스는 행위가 아닌 행하는 객체이기 때문에 이러한 동사+명사의 작명법이 어울리지 않으며, 함수와 헷갈릴 가능성이 크다.
public class DataSender { }
그렇기 때문에 데이터를 보내는 클래스의 이름을 정의하고자 할 때는 위의 예시처럼 이름을 명사화해서 DataSender, 데이터 전송자와 같이 네이밍해주는 것이 좋다.
이름 표기법
대표적인 이름 표기법
중괄호를 다루는 방법에도 여러 가지 방법이 있듯이 변수, 함수, 클래스 이름을 표기하는데도 여러 가지 방법이 있다. 그 중에 대표적인 표기법으로는 카멜 표기법, 파스칼 표기법, 스네이크 표기법이 있다.
카멜 표기법(Camel Casing)
int itemCount;
float moveDirection;
string errorMessage;
카멜 표기법은 변수명으로 사용되는 여러 단어 중에 제일 첫 단어는 소문자로, 그 뒤로 새 단어가 등장할 때마다 그 단어의 첫 문자는 대문자로 표기하는 방법이다. 새로운 단어가 나타날 때마다 대문자가 튀어오르는 모양이 낙타의 등 모양 같다고 해서 카멜 표기법이라고 부른다. 이 방법은 새로운 대문자가 나타날 때마다 끊어 읽으면 되기 때문에 상당히 가독성이 좋은 편에 해당한다.
파스칼 표기법(Pascal Casing)
int ItemCount;
float MoveDirection;
string ErrorMessage;
파스칼 표기법은 카멜 표기법과 비슷하지만 제일 첫 단어의 첫 문자 역시 대문자로 표기한다. 가독성 자체는 카멜 표기법과 비슷하다.
스네이크 표기법(Snake Casing)
int item_count;
float move_direction;
string error_message;
스네이크 표기법은 새 단어마다 언더바( _ )를 삽입하는 형식의 표기법이다. 팟홀 표기법(Pothole Casing)이라고도 불린다. 가독성은 좋은 편에 속하지만 이름이 길어질 수록 넣어야 하는 언더바가 늘어날 뿐만 아니라 언더바를 치는 과정 역시 매우 불편한 면이 많다.
그 외의...
int nItemCount;
float fMoveDirection;
string strErrorMessage;
대표적인 위 세 가지 표기법 이 외에도 여러 가지 표기법이 존재하는데, 변수의 타입을 선행표기하는 헝가리안 표기법(Hungarian Casing)이 있고,
int itemcount;
float movedirection;
string errormessage;
그냥 모든 문자를 소문자로 표기하는 플레인 표기법(Plain Casing) 역시 존재한다.
일반적인 표기법 사용
프로그래밍에서 사용되는 표기법은 종류가 매우 다양하다. 하지만 하나의 표기법을 모든 코드 전체에 적용시키는 경우는 없고, 분류에 따라서 적절하게 여러 가지 표기법을 혼합해 사용하는 경우가 대다수이다. 각 분류에 따라 자주 사용되는 표기법은 아래와 같다.
클래스와 함수의 이름 표기
public class Monster
{
public void Attack() { }
public void Move() { }
public bool FindEnemy() { }
}
클래스와 함수의 이름을 표기할 때는 주로 파스칼 표기법을 사용한다.
변수 이름 표기
변수 이름의 표기법은 변수의 종류에 따라서 사용하는 방법이 많다.
클래스 멤버 변수
// Camel Casing
public class Monster
{
public float moveSpeed;
public float attackSpeed;
}
// Pascal Casing
public class Monster
{
public float MoveSpeed;
public float AttackSpeed;
}
// m_
public class Monster
{
public float m_moveSpeed;
public float m_attackSpeed;
}
// _
public class Monster
{
public float _MoveSpeed;
public float _AttackSpeed;
}
특히 변수에 관련된 쪽에서 표기법이 굉장히 의견이 분분한 편인데, 기본적으로는 카멜 표기법과 파스칼 표기법이 자주 사용되고, 멤버 변수와 다른 매개 변수나 임시 변수와 구분하기 위해 m_나 _를 앞에 붙이는 경우가 많다.
함수 매개 변수
// 1
public class Monster
{
public float moveSpeed;
public void SetMoveSpeed(float moveSpeed) { this.moveSpeed = moveSpeed; }
}
// 2
public class Monster
{
public float moveSpeed;
public void SetMoveSpeed(float movespeed) { moveSpeed = movespeed; }
}
// 3
public class Monster
{
public float moveSpeed;
public void SetMoveSpeed(float _movespeed) { moveSpeed = _movespeed; }
}
// 4
public class Monster
{
public float m_moveSpeed;
public void SetMoveSpeed(float moveSpeed) { m_moveSpeed = moveSpeed; }
}
// 5
public class Monster
{
public float m_moveSpeed;
public void SetMoveSpeed(float a_moveSpeed) { m_moveSpeed = a_moveSpeed; }
}
// 6
public class Monster
{
public float _moveSpeed;
public void SetMoveSpeed(float moveSpeed) { _moveSpeed = moveSpeed; }
}
함수의 매개 변수의 경우 멤버 변수와 이름이 같아서 덮어씌워지는 경우가 많기 때문에 굉장히 많은 방법이 사용된다. 1번 경우처럼 그냥 같은 타입을 사용하고 this 키워드를 사용하는 방법부터, 매개 변수(argument)임을 명시하기 위해서 a_를 붙이는 방법까지 사용되기도 한다. 멤버 변수 표기법과 겹치지 않는 것이 우선이기 때문에 멤버 변수 표기법을 회피한 표기법을 선택한다.
함수의 임시 변수
public void ChangeMoveSpeed(float movespeed)
{
float prevSpeed = moveSpeed;
}
함수 안에서 생성되는 임시 변수의 표기법은 비교적 자유로운 형태를 띈다. 네이밍 규칙만 정상적으로 지켜지면 알아보기 쉽고, 멤버 변수나 매개 변수와 이름이 겹치지 않게 이름 짓기 쉽기 때문에 표기법에 크게 연연하지 않고 적당하게 작성되는 편이다.
주석(Comment)
프로그래밍을 처음 배울 때 주석을 습관적으로 달도록 배우는 경우가 많다. 하지만 과한 주석이 오히려 가독성을 해치기도 한다.
불필요한 주석 쓰기
// 아이템 리스트를 아이템 리스트 길이만큼 순회한다.
for (int i = 0; i < itemList.Count; i++ /*반복마다 i에 1을 더한다.*/)
{
var item = itemList[i]; // 이번 반복 횟수의 아이템을 가져온다.
if (item.type == ItemType.Equipment) // 아이템의 타입이 장비라면 ...
{
// 내구도에 0.9를 곱한다.
item.duration *= 0.9f; // 아이템의 내구도를 감소시키기 위해서
}
}
위의 예시 코드를 보라. 한 눈에 훑어보기만 해도 알 수 있을것 같은 코드에 매 라인마다 주석을 달아둠으로써 오히려 읽기가 어려워졌다. 주석을 다는 습관은 좋은 것이지만, 불필요한 주석까지 다는 습관이라면 나쁜 것이다.
주석을 다는 경우는 최적화 작업이 진행되어서 로직을 한 눈에 읽는 것이 불가능해졌을 때, 어떤 방식으로 코드가 작동하는지를 설명하기 위해 주석을 추가하는 것과, 해당 지점에서 어떤 작업을 해야하는지 To do를 작성하는 경우, 해당 코드를 수정할 때 다른 작업자가 어떤 작업에 유의해야 하는지 등의 경고를 남기는데 사용하는 것으로 한정하는 것이 좋다.
그 이외의 경우에는 주석을 최대한 자제하고 코드를 읽는 것으로 프로그램을 이해할 수 있게 클래스, 변수, 함수 이름을 작성하고 코드의 흐름을 적절히 하는 것이 좋다.
이전 코드 남겨놓기
프로그래머라면 아마 대부분이 어떤 코드에 대해서 수정사항이 발생했을 때, 그 부분을 완전히 지워버리지 않고 주석 처리만 해놓고 새로운 코드를 작성한 경험이 있을 것이다.
바로 이 코드처럼 말이다. 이처럼 띄엄띄엄 이전 버전의 코드를 남겨두게 되면 코드를 한 눈에 읽기 힘들어지고, 특히 여러 버전의 코드가 겹겹이 쌓이게 되면 나중에 복구하려고 하는 시점에는 어떤게 어떤 버전인지도 헷갈리게 된다. 만약 이전 버전으로 되돌아가야할 일이 있다면 버전이 바뀔 때마다 SVN같은 버전 관리 툴에 업데이트를 한 뒤, 차라리 롤백을 하라. 혼자서 하는 작업이라 SVN을 쓰기 귀찮은 상황이라도 차라리 귀찮음을 무릅쓰고 SVN을 쓰는 것이 최선이며 차선은 백업 폴더에 버전 별로 백업을 해두고 원본에서는 지난 코드를 지우는게 최선이다.
개발을 진행하다보면 프로그램을 개발하는 것보다 주석을 아름답게 꾸미는 것에 더 관심이 많아보이는 개발자들이 있다. 이러한 작업을 아스키아트라고 한다. 위 예시는 아주 간단한 아스키아트이다(더 멋진 아스키아트를 그릴 수 있었으나 웹페이지에 여백이 부족해 그리지는 않겠다). 아름답지 않은가? 지금이라도 당장 코드를 꾸미러 가고 싶지 않은가? 로망이란 멋있지만 쓸모없는 것을 가리킨다.
/* ------------------------------------------------------------------- *
* Code Writer :: WERGIA *
* Last Modifier :: SOMETHING-WHO *
* Last Modified :: 2019/11/5 *
* Version :: 1.1 *
* ------------------------------------------------------------------- */
코드 파일의 버전과 작성자 수정일자 등을 표시하는 것은 좋다. 나쁜 것은 끝 라인에 붙은 *들이다. 작성자는 완벽한 사각형을 만들었다고 좋아하겠지만 나중에 버전이 바뀌거나 수정자가 바뀌는 경우, 안의 내용을 수정해야 하는데 이 과정에서 마지막 끝 줄의 *은 엉망진창이 될 것은 필연적인 일이다. 이 라인을 맞추는 작업에 수정자가 쓸데없는 시간을 쏟느니 그냥 저 *들을 지워버리는게 낫다.
읽기 좋은 코드를 작성하기 위한 방법들은 여러 가지가 있지만 그것들이 지향하고자 하는 목표는 모두 같다. 코드의 가독성을 상승시키고 유지보수를 하기 쉽게 만드는 것이다. 개발자는 하나의 코드 스타일에 너무 매몰되지 않아야하고 팀의 협업 시스템에 맞춰 스타일을 변경할 수 있어야 한다. 그러면서도 실수를 최대한 줄일 수 있는 스타일을 유지해야만 한다.
만약, 지금 당신에게 사고 싶은 게임이 두 개가 있고 그 중 하나의 게임만을 구매할 기회가 있다고 가정해보자. 이 두 개의 게임은 비슷한 수준의 재미를 가지고 있으며, 당신이 이 두 게임에게 가진 흥미 또한 비슷하다면 이 두 개의 게임 중에 어떤 게임을 사야할지 깊은 고민에 빠지게 될 것이다.
그런데 깊은 고민에 빠진 당신이 두 게임의 평점을 살피던 중에 게임 B의 평가에서 "이 게임은 너무 용량을 많이 잡아먹는다", "이 게임은 메모리를 너무 많이 사용한다", "이 게임은 프레임 드랍이 너무 심하다"와 같은 평가를 발견하게 된다면 당신의 마음은 어느 쪽으로 기울겠는가? 당연히 마음은 게임 A를 구매하는 쪽으로 기울게 될 것이다. 게임 B의 구매를 완전히 포기하지는 않더라도 "다음에 세일할 때"라던가 "최적화 되었다는 소식이 들리면" 사야되겠다는 쪽으로 마음을 굳히게 될 것이다.
유저가 구매를 결정하는 단계라면 위의 이야기처럼 구매 의사를 접거나 후로 미루게 될 것이지만, 불안정한 최적화(이후에는 간단하게 "발적화"라고 부르도록 하자)에 대한 소식을 듣지 못했거나, 다른 누군가가 발적화에 대한 소식을 올리기도 전에 누구보다 빠르게 게임을 구매한 유저라면 게임사에 격렬하게 항의를 하거나 게임에 대해서 안좋은 평가를 내리게 되고 그 평가는 앞서 말한 구매를 결정하는 단계의 유저들의 발목을 잡게 된다.
위와 같은 순환을 거쳐서 최적화는 유저가 게임을 구매를 결정하는데 생각보다 많은 영향을 미친다(물론 아무리 최적화가 잘 되어있다고 해도 게임 자체가 재미가 없다면 아무런 의미가 없다).
그에 대한 좋은 예시가 바로 PC판 배트맨 : 아캄 나이트다. PS4판이나 XBox One판은 시리즈 전체에 비하면 낮지만 평범한 수준의 평가를 받았지만 PC 판은 심각한 수준의 발적화로 인해 초토화에 가까운 낮은 평가를 받아들어야만 했다.
이러한 최적화는 한마디로 표현하자면, "더 적은 자원으로 높은 효율을 보여주는 것"이다. 더 적은 리소스로 더 좋아보이게, 복잡해 보이는 처리를 더 빠르게 하는 것이 최적화다.
최적화는 개발자의 경험이 미치는 영향이 아주 커서 최적화를 많이 해본 개발자가 그렇지 못한 개발자보다 더 최적화를 잘 진행하는 편이다.
경험이 많지 않은 초보 개발자들의 경우에는 주로 뒤에서 돌아가는 것보다는 눈 앞에 보이는 것을 우선하는 경향과 일단 만들어보자 하는 면이 있기 때문에, 한 장면만 놓고 봤을 때는 와 그래픽이 좋다라는 평가가 나올 수 있지만, 실제로 게임을 작동했을 때는 메모리를 과다하게 잡아먹거나 프레임이 뚝뚝 떨어지는 현상을 쉽게 목격할 수 있는데, 초보 개발자는 여기서 혼란에 빠지게 된다. 지금 보이는 화면의 퀄리티가 떨어지는 것을 최대한 막으면서 성능을 나아지게 하려면 어느 부분을 덜어내고 어느 부분을 남겨놔야 할지, 어느 부분을 개선해야 최적화가 될지에 대한 감이 전혀없기 때문이다.
최적화 할 수 있는 부분들
최적화를 하는 부분은 대부분 정해져있다.
1. 비효율적인 알고리즘
최적화의 전제 조건은 효율적인 알고리즘이다. 비효율적인 알고리즘을 사용하는 상태에서는 어떤 최적화 기법을 사용한다고 해도 성능은 획기적으로 개선되지 못한다. 예를 들어 컨테이너 안에 든 자료들을 정렬하는 모든 작업에 버블 정렬을 사용한다고 가정해보자. 과연 그 프로그램이 다른 부분을 개선한다고 해서 얼마나 빨라질 수 있을까? 하지만 정렬 알고리즘을 버블 정렬보다 효율적인 알고리즘으로 교체하는 것만으로도 굉장한 성능 개선을 보일 수 있을 것이다.
2. 병목현상 제거
대부분의 프로그램은 모든 부분이 느리다기 보다는 어느 특정한 시점에서 굉장히 느려지는 등의 병목이 발생하는 경우가 많다. 병목 현상이란 특정한 시점에 계산이나 데이터 전송이 몰려서 처리하는 속도보다 요구가 쌓이는 속도가 더 빨라서 느려지는 것을 의미한다. 이러한 병목 현상을 제거해주는 것만으로도 상당한 성능 개선을 기대할 수 있다.
3. 레벨 디자인과 그래픽
게임을 제작할 때, 좋은 그래픽을 보여주기 위한 욕심으로 고화질의 텍스처, 많은 버텍스를 가진 모델, 레벨에 과다하게 배치된 사물들 역시 많은 성능을 잡아먹는 요소가 된다. 최적화를 위해서는 어쩔 수 없이 유저의 시선이 잘 닿지 않는 곳이나 먼 곳 등은, 텍스처의 해상도를 낮추거나 버텍스를 줄이고, 적절한 수의 사물을 배치하는 것 역시 좋은 최적화 요소가 된다.
4. 기획 덜어내기
기획자들은 항상 욕심이 많다. 기획자들은 하나의 게임 내에서 더 많은 것들과, 더 다양한 시스템들을 보여주고 싶어한다. 하지만 프로그래머가 최적화하는데도 한계가 있을 수 밖에 없기 때문에, 과도한 연산이 필요한 시스템이나 과도한 스케일의 기획은 덜어내는 수 밖에 없다. 일반적인 기획자들은 덧붙이기만 하지만 뛰어난 기획자들은 덜어낼 줄 안다.
최적화, 비용과 그 결과의 딜레마
최적화 과정 역시 프로그램 개발 과정의 일부로서 당연히 비용과 시간이 소모된다. 최적화 작업은 초기에는 들인 비용에 비해 개선되는 성능이 높은 편이지만, 과정이 진행되면 진행될 수록 개선되는 성능의 폭이 기하급수적으로 감소한다. 즉, 들인 시간과 비용에 비해서 성능 개선이 너무 적게되는 순간이 반드시 온다는 것이다.
분명 최적화는 하면 할 수록 낮은 사양의 유저들까지 수용할 수 있게 되지만, 그것도 어느 정도의 한계선은 분명히 존재하며, 최고의 성능 개선을 하는데 드는 비용과 시간은 굉장한 수준이다. 그렇기 때문에 최적화 작업에 들어갈 때는 항상 어느 정도 수준까지 개선할 것인지 목표를 잡되, 그 목표가 비현실적이어서는 안된다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
An exception has been encountered. This may be caused by an extension. 에러 발생시 해결 방법
유니티에 비주얼 스튜디오(Visual Studio)로 스크립트 작업을 하려고 스크립트 파일을 더블 클릭해서 열었는데 비주얼 스튜디오가 실행된 이후에 위와 같은 에러 메시지가 떴다. 이 현상은 비주얼 스튜디오를 켤 때마다 지속적으로 반복되었다. 유니티 작업을 하는데는 큰 문제가 없었지만 비주얼 스튜디오를 실행할 때마다 메시지 박스가 팝업되니 여간 불편한게 아니었다.
에러 로그를 검색해보니 이 문제는 캐시 충돌 문제로 발생하는 것이라고 한다. 이 문제를 해결하는 방법은 아래의 경로 아래에 있는 캐시 파일들을 삭제하고 비주얼 스튜디오를 재실행 해주면 캐시 파일들이 새로 생성되면서 문제가 해결된다고 한다.
