[NDC2018] 개발자를 위한 '좋은 이름, 나쁜 이름, 이상한 이름'

[넥슨개발자컨퍼런스(NDC) 발표자 소개] 전형규 개발자는 마비노기, 마비노기 XBOX360, 마비노기2, 링토스 세계여행, 마비노기 듀얼 프로젝트에 참여했으며 현재 프로젝트DH 팀에서 엔지니어링 책임을 맡고 있다.

개발자라면 프로그램을 작성하거나 게임을 디자인하면서 함수, 스킬을 어떻게 지어야 할 지 고민한 경험이 있을 것이다. 좋은 이름은 그 대상을 이해하고 관리하기가 쉽고, 새로 합류한 동료가 프로젝트에 금방 적응할 수 있게 한다. 반대로 나쁜 이름은 이해하기 어렵고 커뮤니케이션에 혼선을 가져와 프로젝트 관리 비용을 증가시킨다. 전형규 개발자는 NDC 2018에서 프로그래밍 작업에 도움 되는 작명법 노하우와 사례를 공유했다.

※ 기사는 편한 전달을 위해 강연자의 시점에서 서술했습니다

▲ 프로그래머라면 한 번쯤은... (이미지 출처: geek-and-poke.com)

---

네이밍은 어떤 개념이나 기능, 객체 등에 이름을 붙이는 행위를 말한다. 프로그래밍에서의 네이밍은 코드상의 변수나 타입, 함수 등의 식별자를 구분하기 위해 네이밍을 한다. 오늘 말하려는 네이밍은 약간 추상적인 내용일 수 있다. 구체적인 네이밍 컨밴션이나 방법 등에 대해서는 언급하지 않는다. 또, 좋은 게임 타이틀 짓는 법도 강연 내용 중에는 없다. 일단, 우리 게임(Project DH)도 아직 이름이 없으니까. 그래서 약간은 뜬구름 잡는 이야기를 할 수도 있다.

네이밍의 첫걸음은 대상을 이해하는 것이다. 대상을 정확히 이해해야만 좋은 이름을 지을 수 있다. 혹시 귤 알맹이와 껍질 사이에 있는 하얀 것의 이름을 아는 사람이 있을까? 나도 몰라서 찾아보니 '귤락'이었다. 락이 한자로 얽혀있다는 의미라고 하더라. 아마 귤락이라고 처음 네이밍한 사람도 어떻게 불러야 하나 고생했을 거 같다. 이렇듯 네이밍은 대상을 정확히 이해한 다음에 해야 하니 어려운 일이다.

개인적으로 전산을 전공해서 네이밍이 문제 풀기와 비슷해 보인다. 게임을 개발하다 보면 '매일 변경되면서도 하루 종일 지속되는 효과'를 만들 때가 있다. 이 효과를 어떻게 부를까 고민하다가, 동료 개발자가 '요일 효과'라고 부르더라. 직관적으로 내용이 와닿아서 그대로 사용했다. 또 추상적인 문제를 네이밍해야 할 때도 있다. 어느 커뮤니티에서는 '갖고 싶은 아이템이 유독 나오지 현상'에 대해 '물욕 센서'라고 부르는 것을 봤다. 기기 어딘가에 사용자의 물욕을 감지하는 센서가 있어, 갖고 싶은 아이템이 나오지 않는다는 것이다. 참 센스있는 네이밍이라 생각했다.


좋은 이름을 짓는 방법

좋은 네이밍이란 무엇일까? 우선 '가독성' 좋은 네이밍이 훌륭하다고 할 수 있다. 좋은 네이밍은 코드를 이해하기 쉽게 도와주고, 무슨 파일이 어디에 있는지 쉽게 알 수 있도록 한다. 네이밍 하나로 조직원 모두가 작업의 목표를 빠르게 파악하도록 이끌 수도 있다. 그래서 좋은 네이밍을 위해서는 팀원 간 원활한 의사소통이 필수다.

네이밍은 이름이 문제를 대표하기 때문에 중요하다. 변수, 함수, 클래스 이름은 코드를 이해하는 데 있어 가장 큰 단서다. 다른 사람은 물론 코드를 직접 짠 개발자 자신도 몇 년 전 코드를 보면 쉽게 기억나지 않을 때가 있다. 이때 좋은 네이밍으로 이름을 붙였다면 쉽게 작업을 다시 할 수 있다. 즉, 좋은 네이밍은 유지 보수에 큰 도움이 된다.

좋은 네이밍의 특징은 크게 네 가지로 나눌 수 있다. 명확성, 유일성, 일관성, 영속성이다. 명확성은 이름이 가르키는 대상이 뚜렷하거나 짐작할 수 있음을 의미한다. 코드에서는 Test()보다 TestTrue()라는 이름이 인자가 true인지 검사한다는 의미를 명확하게 표현한다. 또, FindEx() 보다는 FindOrAdd()라는 이름이 확장함수라는 표시보다 구체적인 동작을 의미하기 때문에 더 좋은 네이밍이라 할 수 있다.

유일성에 맞는 네이밍은 무엇일까? 대상을 표현하는 가장 적절한 단어를 찾는 것이다. 업계에서는 복잡하게 얽힌 소스 코드를 '스파게티 코드'라고 부르는데, 유일성에 적합한 예시라고 생각한다. 게임 모드에 많이 쓰이는 '데스매치' 역시 제한된 시간 내에 상대방을 더 많이 잡으면 승리하는 방식을 잘 드러낸다.

일관성 있는 네이밍은 규칙이 필요할 때에 적합하다. 타입과 크기를 char, shor, int, log으로 표현하는 것보다 int8, int16, int32, int64라고 표현하는 게 더 일관성 있는 네이밍이다. 일관성 있는 네이밍은 시스템이 커질수록 유용하다. 만약 타입의 크기가 128까지 늘어나면 int128을 추가하면 되니까. 앞선 경우였으면 verylong이라고 지었을 텐데... 이는 명확하지 않다.

영속성이 좋은 네이밍은 유행에 민감하지 않고 시간이 흘러도 뜻이 변하지 않는다. 영속성을 잘 표현하는 게 '게임엔진'이다. 엔진이 자동차의 핵심 부풋이듯, 게임 개발에도 핵심임을 잘 드러낸다. 나쁜 영속성의 예는 '웹2.0'이라고 생각한다. 1.0보다는 좋고 3.0보다는 나쁜 거 같은데, 의미가 와닿지 않는다.


나쁜 이름을 짓는 방법

반면, 나쁜 이름을 짓는 방법도 있다. 난해하고, 의존성이 높고, 비상식적이고, 비윤리적인 이름 짓기라고 할 수 있다. 난해한 이름은 외우기 어려운 전문 용어와 특정 그룹만 사용하는 언어가 대표적이다. 이런 이름은 규칙이 없어 그냥 외우는 수밖에 없다. 개인적으로 우리나라의 호칭이 난해하다고 생각한다. 결혼 후 남자가 부르는 호칭이 형수님, 자형, 제수씨, 매제 등이더라. 일단 외워서 써야 한다.

의존성이 높은 이름은 순환 논리에 빠진 경우다. 이름을 이해하려면 대상의 밖의 개념을 알아야 한다. 예를 들어 '논타겟팅'의 경우 '타겟팅'을 알아야 이해할 수 있다. 이해는 쉽지만 의존적이다. 이것은 책을 소설과 비소설로 분류하는 것과 같다. 세상에 다양한 책이 있듯이 타겟에 관한 시스템도 여러 가지다.

비상식적인 이름은 처음 들었을 때 오해하기 쉽다. 'sand witch sandwich'라는 브랜드는 처음 들었을 때 무엇인지 떠올리기 힘들다. 사막의 마녀 샌드위치라니? 특정 프로그램 언어에서도 비상식적인 경우가 있다. template를 view라고 부르거나 view는 controller라 쓰기도 한다. 비상식적이다.

비속어나 불쾌한 표현이 들어간 이름도 나쁜 네이밍이다. 서양권에서는 '들어오는 요청을 모두 수락하는 프로젝트'를 '프로젝트 매춘부'라 부르는데, 대표적인 비윤리적 네이밍이다. 또는 수술을 마친 의사에게 보호자가 "결과는요?"라 물을 때 의사가 "중요한 건 결과가 아니라 과정입니다"라 답한다고 생각해보자. 경우에 맞는 표현이 중요하다.


이상한 이름을 짓는 방법

좋은 것도 아니고 나쁜 것도 아닌 이름들이 있다. 앞서 언급한 논타겟팅이 그렇다. 나에게 "그럼 더 좋은 이름을 제시해봐"라고 하면, 딱히 떠오르지 않는다. 이상한 이름은 좋은 이름과 나쁜 이름의 특징을 함께 지니고 있다.

'젤다의 전설'도 대표적인 이상한 이름인 거 같다. 아니, 주인공이 링크면 '링크의 전설'이지. 왜 '젤다의 전설'인가? 젤다라는 이름이 멋있어서 그런가?

이상한 이름의 다른 특징은 중독성이다. 처음 들었을 때 재밌고 시스템 전체로 빠르게 전파된다. 지난해 히트친 '존버'라던가 '잠수함 패치'가 묘하게 중독성이 있다. '잠수함 패치'의 경우 "게이머에게 공지 없이 적용된 업데이트"라는 설명이 필요하지만, 의미를 잘 드러낸다.

우리 '프로젝트 DH' 팀에서 쓰는 중독성 있는 네이밍 중에 '불가래'라는 게 있다. '불가래'는 용이 발사하는 파이어볼을 뜻한다. 용이 퉤퉤 뱉는다고 '불가래'라 지었다. 하푼, 중푼, 상푼은 일반 작살, 대형 작살, 초대형 작살을 의미한다.


공통 네이밍 가이드라인

이름 짓기가 힘들다면, 대상에 문제가 있다는 신호다. 너무 추상적이면 네이밍이 힘들다. 이럴 때는 대상을 나누어서 단순화하는 게 먼저다. 만약 완전히 새로운 개념이면 이름을 발굴해야 한다.

▲ '키메라' 말고 다른 이름을 짓는다면, 지을 수 있을까?

네이밍이 필요하다면 먼저 용도를 고려하자. 주로 사용할 조직과 직군을 파악하는 게 중요하다. 분야마다 같은 이름을 다른 의미로 사용하는 경우가 있기 때문이다. 이름이 사용되는 범위가 넓다면 반드시 관련자들과 협의부터 해야 한다.

기본적으로 네이밍은 재미있고 기억하기 쉬운 단어를 사용하는 게 좋다. 그리고 되도록 빨리 결정하자. 모 프로그래머 모임에서 조사한 결과가 있는데, 전체 작업 시간 중에서 네이밍에 49%를 쓴다고 하더라. 만약 프로토타입 개발 중에 네이밍을 고민한다면, 아무렇게나 지어도 상관없으니 일단 빨리 짓자. 특히 고민 끝에 지은 이름은 정작 필요할 때 기억나지 않는 경우가 많다.

그리고 변경이 필요하다면, 과감하게 바꾸자. 나쁜 이름을 방치할 수록 프로젝트 관리 비용이 증가한다. 만약 게임을 런칭해 라이브 단계로 진입하면, 이름 변경은 불가능에 가깝다. 일례로 'TreasureBox'라는 소스코드 파일이 있다. 마비노기 듀얼의 소스코드 중 하나인데, 뭔가 굉장한 게 있을 거 같아 보였는지, 많은 개발자가 잡다한 코드를 쌓아두더라. 나중에 가서는 관리하기 힘들어졌다.

불필요하게 약자를 사용하는 것도 좋지 않은 습관이다. 예로 num_errors를 nerr로 줄이는 경우다. 다른 개발자가 nerr을 한 단어로 인지하면, 무슨 뜻인지 알 수 없다. 만약 이름이 너무 길다면, 그냥 나눠보는 것도 괜찮다.

이름은 간단히 짓고 주석에 공들이는 경우가 있다. 그냥 네이밍을 잘 하자. 이름을 이해하기 위해 주석을 달아야 한다면, 네이밍을 다시 하는 게 낫다. 주석은 거짓말을 할 수 있기 때문이다.

▲ 주석 없이도 이해할 수 있어야 좋은 이름이다

그리고 문법을 지켜서 네이밍하자. 맞춤법이 틀리면 가독성이 떨어지고 코드 신뢰성을 의심받는다. 많이 쓰는 표현을 사용해야 나중에 검색하기 수월하다. 철자 오류가 너무 유명해져서 어쩔 수 없는 경우도 있기는 하다. 예를 들면 'HTTP Refer' 같은 경우다. 웬만하면 문법을 지키면서 이름을 짓자.

이름 짓기가 너무 힘들다면, 한글 이름을 고려하는 것도 좋은 방안이다. 팀에서 볼록렌즈와 오목렌즈가 들어가는 게임을 만들 때가 있었다. 처음에는 convex(볼록), concave(오목)로 지을 때는 많은 사람들이 헷갈려서 고통받았다. 논의 끝에 그냥 bolok, omok으로 지으니 모두가 행복해졌다.

불변 객체는 이름에 불변성을 강조하자. 'MAX_COUNT' 같은 이름은 매크로 상수가 연상되므로, 런타임에 바뀌지 않을 것이라 기대할 수 있다. 불변 객체는 언제나 예측할 수 있어 최적화도 용이하다.

의미에 짝이 있는 단어는 맞춰서 사용하자. Begin을 사용했다면 End도 사용하고, Add를 사용했다면 Remove도 사용하는 게 좋다. 짝을 맞추지 않으면 코드를 읽는 이에게 혼란을 줄 수 있다.

실행을 의미하는 동사는 주의 깊게 사용해야 한다. 특히 Do는 웬만하면 쓰지 말자. 정말 사용하고 싶다면, 월급이라도 걸고 사용하자. Perform도 Task나 Action 클래스의 메소드 이름으로만 쓴다.

우리나라 프로그래머는 상태 변경에 Update만 쓰는 경향이 있다. 상태 변경을 의미하는 동사를 구별해 사용하는 것이 좋다. Advance는 내부 로직을 한 프레임 증가시킬 때, Update는 변경점을 내부에 반영해서 상태를 갱신할 때, Process는 일련의 동작을 순차적으로 실행할 때, Handle은 발생한 이벤트를 처리할 때 사용하자.


디자인 네이밍 가이드

주제와는 다소 다른 이야기인데, '기획' 대신에 '디자인'이라고 부르자. 기획, 설계, 디자인 모두 '디자인'이라는 이름을 사용할 수 있다. 구분하고 싶다면 '시스템 디자인', 'UX 디자인' 등 앞에 분야를 붙여 한정하는 게 이해하기 쉽다.

네이밍은 디자이너(기획자)가 정하는 게 좋다. 디자이너는 제작 중인 게임에 대해 가장 잘 알고 있는 사람이다. 여러 파트가 협업하는 작업은 대부분 디자이너의 발주로 시작된다. 그리고 절대, 투표로 이름을 짓지 말자. 평소에 책을 많이 읽고 대화와 타협에 능한 사람을 팀의 작명가로 정하는 게 좋다.

이름 짓기에 중요한 것은 '직교성'이다. 직교성은 한 가지 구성 요소를 변경해도 다른 구성에 변화가 없는 성질을 의미한다. 직교성이 높을수록 시스템 복잡도는 낮아진다. 직교적인 디자인은 자연스레 직교적인 이름을 유도한다. 디자인의 직교성부터 고민하자.

행동을 소환, 파괴, 공격으로 나눈 이름과 대상을 생물, 요정, 기계, 건물로 나눈 게 직교적인 이름 짓기다. 행동과 대상을 자유롭게 조합할 수 있다. 헬멧, 갑옷, 무기, 방패라는 이름도 다양한 부분에서 최적의 설정을 찾는 재미를 가져다준다.

너무 설명하기 어려운 경우라면, 코드네임을 붙이는 것도 방법이다. 게임 데스티니의 에러코드 0x3949는 beetle로 명명됐다. 만약 에러를 해결하기 위해 검색할 경우, 0x3949보다 destiny beetle erorr라 검색하는 게 훨씬 쉽다.

▲ 데스티니는 에러 코드를 인지하기 쉽게 네이밍 했다

그리고 개발 용어와 인게임 용어를 구별하자. 모든 개발 용어를 그대로 게이머에게 전달할 필요는 없다. '세션 생성'은 '방 만들기'로, '소유권 이전 불가'는 '획득 시 귀속'으로, '404 Not Found'는 '대상을 찾을 수 없습니다'로 바꾸는 게 좋다. 특히 404는 게이머에게 아무런 정보를 주지 않는다.

이어서, 커뮤니티 용어는 주의해서 사용하자. 게임 장르인 MOBA를 AOS라 부르는 경우가 있다. AOS는 유저 컨텐츠 이름이다. 장르를 설명하는 단어가 더 낫다. 커뮤니티 용어 자체가 나쁜 것은 아니나 거칠고 자극적인 표현이 많다. 업계는 신중하게 사용할 필요가 있다.

어셋의 경우 임시 이름을 짓지 말자. 어셋이 일단 배포되면 이름을 변경하기 대단히 어렵기 때문이다. 일례로 MonsterAYAYA라는 이름이 있다. 몬스터 피격 이벤트를 뜻하는데... 그대로 쓰기에는 프로답지 못한 이름이라고 생각한다. 또는 XXX_TEST, XXX_imsi라는 이름도 종종 보인다. 안타깝다.

일반적으로 네이밍은 알파벳과 숫자, 언더스코어(_)만 사용하는 게 안전하다. 게임 엔진이나 플랫폼에 따라 이름의 최대 길이나 대소문자 구별 여부 등이 있으니 미리 숙지하자.

'분명히_있는데_로딩이_안됨 .txt' 이런 파일이 있다고 가정해보자. 작동이 안 될 텐데 이유가 뭘까? 이름의 뒤에 공백이 있기 때문이다. 특히 이런 경우는 문제를 찾기 굉장히 힘들다. 공백은 그냥 쓰지 말자.

사전 순서를 고려하자. 어셋은 보통 이름순으로 정렬되어 리스트에 표시된다. 만약 item1이라 지었을 경우 item10을 지어야 할 때 곤란해진다. 기기에 따라 item10을 item2보다 앞선다고 여기는 경우가 생긴다. 그리고 중요한 단어를 앞쪽에 배치하자. 'a_b_c_d_char' 보다는 'char_a_b_c_d'가 바람직하다.

마지막으로, 네이밍은 어렵다. 그리고 중요성은 여러 번 말해도 지나치지 않는다. 네이밍은 대상을 이해하고 문제를 정의하는 작업이다. 가독성 높은 이름은 대화의 품질을 향상시킬 수 있다. 좋은 이름 짓기를 위해 간단명료하고 기억하기 쉬운 이름을 붙이자. 그리고 이름의 용도와 목적에 맞게 사용하자.