이승재, 강성훈, 내가 만든 언어의 개발환경을 Visual Studio Code로 빠르고 쉽게 구축하기 #1, NDC2017
전형규, 좋은 이름, 나쁜 이름, 이상한 이름, NDC2018
1. 넥슨 데브캣 스튜디오 프로젝트DH팀
전형규(henjeon@nexon.co.kr)
게임 개발에서의 네이밍 가이드라인
좋은 이름, 나쁜 이름, 이상한 이름
2. • 참여 프로젝트
• GEARS(2001)
• 마비노기(2004), 마비노기 XBOX360, 마비노기2
• 링토스 세계여행(2014)
• 마비노기 듀얼(2015)
발표자 소개
• 현재, 프로젝트DH팀 엔지니어링 책임자
• 주요 관심사: UE4, 육아
3. 발표 내용
• 게임 개발에서의 이름 짓기(Naming) 가이드라인
• 네이밍의 의미와 중요성
• 좋은 이름, 나쁜 이름, 이상한 이름의 특징
• 공통 네이밍 가이드라인
• 분야별 세부 네이밍 가이드라인
• 다루지 않는 내용
• 코딩 컨벤션
• 게임 이름 짓는 방법
• 절차적 이름 자동 생성
7. 네이밍이란 무엇인가
컴퓨터 프로그래밍에서 네이밍 컨벤션이란 소스 코드와 문서에 있는 변수 이름, 타입, 함수 등의 식별자에
사용되는 문자열을 선택하기 위한 여러 가지 규칙입니다.
프로그래머들이 네이밍 컨벤션을 사용하는 이유는 다음과 같습니다:
• 소스 코드를 읽고 이해하는데 필요한 노력을 줄이기
• 코드를 검토할 때 이름과 명명 기준에 대한 논쟁보다 더 중요한 주제에 집중하기
• 코드 품질 검토 도구들이 문법과 스타일 설정 이외의 중요한 사항들을 주로 보고할 수 있도록 만들기
위키백과. 네이밍 컨벤션
8. 네이밍이란 무엇인가
• 어떤 개념, 기능, 객체 등의 대상에 이름을 붙이는 행위
• 분야에 상관없이 누구나 매일 한다.
• 파일 이름
• 변수, 함수, 클래스 이름
• 아이템, 캐릭터 스킬 이름
• 신규 컨텐츠 이름
9. 네이밍이란 무엇인가
• 대상을 이해해야 이름을 붙일 수 있다.
• 제대로 이해하지 못하면 잘못된 이름을 붙이기 쉽다.
• 네이밍은 매우 어려운 일이다.
귤락( 橘絡): 귤에 붙어있는 ‘하얀 거＇
10. 네이밍이란 무엇인가
• 네이밍은 문제 풀기와 비슷하다.
• 주어진 대상을 가장 잘 표현하는 단어를 찾는 문제
• 예) 매일 변경되며 하루 종일 지속되는 효과 → 요일효과
• 네이밍은 문제 정의 이기도 하다.
• 추상적이고 관념적인 대상을 구체적이고 객관적인 무엇으로 바꾼다.
• 예) 갖고 싶은 아이템이 유독 나오지 않는 현상 → 물욕센서
11. 이름의 중요성
• 좋은 이름은 가독성을 높인다.
• 코드를 이해하기 쉽다.
• 무슨 파일인지, 어디에 쓰이는지 쉽게 알 수 있다.
• 작업의 목표를 금세 파악할 수 있다.
• 좋은 이름은 원활한 의사 소통의 필수 요소
• 이해하기 쉽고 전달하기 쉬운 단어를 사용하면 불필요한 대화 비용을 줄일 수 있다.
• 조직의 목표 설정 및 정렬에 도움을 준다.
12. 이름의 중요성
• 좋은 이름은 대화의 맥락을 쉽게 파악할 수 있게 도와준다.
씨디: 컴팩트 디스크 / 엠티: 자기 디스크 / 아이디씨: 인터넷 데이터 센터
13. 이름의 중요성
• 이름은 문제 영역을 대표한다.
• 변수, 함수, 클래스 이름은 코드를 이해하는 가장 큰 단서
• 도구와 규칙 이름에서 만든 이의 철학을 짐작할 수 있다.
• 조직에서 사용하는 이름을 살펴보면 조직 문화가 보인다.
15. 좋은 이름의 특징: 명확성
• 이름이 가리키는 대상이 뚜렷하다.
• 이름 자체로 설명이 충분하다.
• 모호하지 않고 하려는 일이 분명하다.
GetLength()
→ ComputeLength()
단순히 값을 반환하는 것이 아니라
수행시간이 필요함을 밝힌다.
16. 좋은 이름의 특징: 유일성
• 대상을 표현하는 가장 적절한 단어
• 독창적이고 기억에 오래 남는다.
스파게티 코드
복잡하게 얽혀 있는 소스코드
17. 좋은 이름의 특징: 일관성
• 개별 이름 보다는 이름이 속한 시스템의 특징
• 비슷한 것에 비슷한 이름이 붙어 있다.
• 이름을 붙이는 규칙이 일정하게 잘 정리되어 있다.
• 시스템이 커질 수록 일관성이 중요해진다.
DDD(Domain Driven Design)의
Ubiquitous Language 개념
18. 좋은 이름의 특징: 영속성
• 유행에 민감하지 않고 시간이 흘러도 그 뜻이 변하지 않는다.
• 대상의 속성이 변해도 계속해서 사용할 수 있다.
20. 나쁜 이름의 특징: 난해함
• 외우기 어려운 전문용어
• 특정 그룹만 사용하는 은어
• 규칙이 없고 그냥 외워야 함
21. 나쁜 이름의 특징: 의존성
• 순환 논리에 빠진 이름
• 이름을 이해하려면 대상 밖의 개념을 알아야 한다.
22. 나쁜 이름의 특징: 비상식적
장진호 전투는 한국전쟁 중 가장 참혹했던 싸움으로 꼽힌다. 동시에 미국 해병대 창설 이후 가장 치열했던 전투로
기억된다. 장진호 전투에서 있었던 일화 중 하나.
“지금 초콜릿 사탕이 떨어지기 일보 직전이다. 더 이상 남아 있는 초콜릿 사탕이 없다. 긴급하게 초콜릿 사탕을
지원해주기 바란다.”
중공군에 포위된 채 악전고투하던 미 해병대 제1사단 박격포 부대의 통신병이 다급하게 무전을 쳤다. 후방
지원부대의 통신병은 어리둥절해졌다. 적군에 포위된 부대에서 다급한 목소리로 보급을 요구하는 것이 겨우
초콜릿 사탕이었기 때문이다.
국방일보. 중공군 포위망서 美 해병대 구한 ‘초콜릿(투시 롤) 사탕’
23. 나쁜 이름의 특징: 비상식적
• 특정 문맥에 맞춰서 의미를 재정의
• 처음 들었을 때 오해하기 쉽다.
24. 나쁜 이름의 특징: 비윤리적
• 비속어, 불쾌한 표현
• 정치적으로 올바르지 않은 단어 사용
29. 공통 네이밍 가이드라인
• 좋은 이름이 없다면 대상에 문제가 있다는 신호
• 아이템, 오브젝트, 액터 등의 이름 밖에 떠오르지 않는다면 대상이 너무 추상적이다.
• 대상을 나누어서 단순화하는 것이 먼저
• 완전히 새로운 개념이면 이름을 발굴해야 한다.
출처: LINK
30. 공통 네이밍 가이드라인
• 이름의 용도를 고려
• 주로 사용하는 조직, 직군 등을 파악
• 분야마다 같은 이름을 다른 의미로 사용할 수 있다.
• 이름이 사용되는 범위가 넓다면 반드시 관련자들과 협의부터 할 것
고객이 설명한 요건
프로젝트리더의 이해
애널리스트의 디자인
프로그래머의 코드
영업맨의 표현, 약속
프로젝트 서류
실제 운용
고객에의 청구금액
제공받은 서포트
고객에게 정말 필요했던 것
31. 공통 네이밍 가이드라인
• 재미있고 기억하기 쉬운 단어를 사용
• 이름의 사용성을 높일 수 있도록 고민
• 일상 언어에서 이름을 발굴해보자.
32. 공통 네이밍 가이드라인
• 되도록 빨리 결정
• 좋은 이름 찾느라 너무 오래 고민하지 말자.
• 컨셉 증명 단계에서는 이름을 대충 붙여도 괜찮다.
• 고민 끝에 지은 이름은 정작 필요할 때 기억나지 않더라.
49% 병목 지점의 최적화가 필요하다.
33. 공통 네이밍 가이드라인
• 변경을 두려워하지 않는다.
• 나쁜 이름을 방치할 수록 프로젝트 관리 비용이 증가한다.
• 게임을 런칭하여 라이브 단계로 진입하면 이름 변경이 거의 불가능
UE4의 ‘F’ 접두사
‘Float’의 ‘F’.
에픽게임즈 팀스위니가 FVector 와 같이
수학 라이브러리 코드를 작성한 것에서
시작되어 코드 전체로 펴졌다.
35. 코드 네이밍 가이드라인
• 불필요하게 약자를 사용하지 않는다.
• 타이핑 비용 줄이려 대화 비용을 늘리지 말고 좋은 키보드를 사자.
• 이름이 너무 길어지면 대상을 나눠보는 것도 좋다.
• 부를 때 약자를 사용하는 것은 괜찮다.
36. 코드 네이밍 가이드라인
• 주석보다 이름이 중요하다.
• 이름을 이해하기 위해 주석을 달아야 한다면 이름을 다시 짓는 편이 낫다.
• 주석은 거짓말을 할 수 있기 때문이다.
37. 코드 네이밍 가이드라인
• 문법을 지켜서 네이밍한다.
• 맞춤법이 틀리면 가독성이 떨어지고 코드의 신뢰성을 의심받는다.
• 많이 쓰는 표현을 사용해야 코드를 검색하기 쉽다.
• 철자 오류가 너무 유명해져서 어쩔 수 없는 경우도 있다. 예) HTTP Referer
38. 코드 네이밍 가이드라인
• 한글 이름을 고려할 것
• 번역하기 힘들거나 잘 쓰이지 않는 영문 단어 보다는 한글을 쓰는 것이 좋다.
39. 코드 네이밍 가이드라인
• 이름으로 불변성(Immutable)을 강조할 것
• 불변 객체는 언제나 예측 가능하다(부작용이 없다).
• 불변 객체는 최적화하기 쉽다.
Immutable
mutableSet,
ImmutableSet
이름이 너무 길지 않다면
mutable을 붙이는 것도 좋다.
40. 코드 네이밍 가이드라인
• 반의어의 짝을 맞춰서 사용한다.
• 짝을 맞춰 이름을 붙이지 않으면 읽는 이에게 혼란을 줄 수 있다.
Begin / End
기능을 열고 닫을 때 사용한다.
왼쪽 괄호, 오른쪽 괄호라고도 함
Add / Remove
컨테이너 /컬렉션에 값을 추가,
삭제하는 메서드에 사용
41. 코드 네이밍 가이드라인
• ‘실행’을 의미하는 동사는 주의 깊게 사용
• ‘Do’는 웬만하면 쓰지 않는다.
• ‘Perform’은 Task나 Action 클래스의 메서드 이름으로만 쓴다.
• ‘Execute’는 전달된 인자를 실행하거나 할 때 쓴다.
• 그 외의 경우에는 ‘Run’을 쓴다.
42. 코드 네이밍 가이드라인
• 상태 변경을 의미하는 동사를 구별해서 사용
• ‘Advance’는 내부 로직을 한 프레임 증가시키거나 할 때 사용
• ‘Update’는 변경점을 내부에 반영해서 상태를 갱신할 때 사용
• ‘Process’는 일련의 동작을 순차적으로 실행할 때 사용
• ‘Handle’은 발생한 이벤트를 처리할 때 사용
HandleCharacterInput()
캐릭터의 조작 입력을 처리
44. 잡설
• ‘기획’ 대신 ‘디자인’ 이라고 부르자.
• 기획, 설계, 디자인 모두 디자인이라는 이름을 사용할 수 있다.
• ‘시스템 디자인’, ‘UX 디자인’ 과 같이 구체적으로 분야를 한정하는 것이 이해하기 쉽다.
• 개발자 ≠ 프로그래머
• 디자이너(기획자), 아티스트, 프로그래머, 프로젝트 매니저, QA 테스터 모두 개발자
• ‘저희’ 대신 ‘우리’를 사용하자.
• ‘우리 게임’, ‘우리 팀’, ‘우리 회사’, …
45. 디자인 네이밍 가이드라인
• 이름은 디자이너가 정하는 것이 좋다.
• 디자이너는 제작 중인 게임에 대해 가장 잘 알고있는 사람
• 여러 파트가 협업하는 작업은 대부분 디자이너의 발주로 시작된다.
• 이름을 투표로 정하면 무조건 망한다.
• 책 많이 읽고 대화와 타협에 능한 사람을 팀의 작명가로 정하자.
46. 디자인 네이밍 가이드라인
• 직교성이 중요하다.
• 직교성(Orthogonality): 한 가지 구성 요소를 변경해도 다른 구성 요소에 변화가 없는 성질
• 직교성이 높을 수록 시스템의 복잡도가 낮다.
• 직교적인 디자인은 자연스럽게 직교적인 이름을 유도한다. 디자인의 직교성부터 고민하자.
소환
파괴
공격
…
생물
요정
기계
건물
…
액션과 대상을 자유롭게 조합 다양한 파츠 조합에서 최적의 설정을 찾는 재미가 있다.
헬멧 갑옷
* * 무기* 방패*
47. 디자인 네이밍 가이드라인
출처: LINK
이건 스파4 짤이고 스파5 것은 못구함…
• 사례분석: “하단 펀치를 서서 막을 수 있나?”
48. 디자인 네이밍 가이드라인
• 답은 ‘있다’ 이다.
• 하단 공격은 앉아서만 막을 수 있다.
• 그런데 하단 펀치의 판정은 ‘특수 하단‘
• ‘특수 하단＇공격은 하단 공격이지만 서서 막을 수 있다.
• 그럼 ‘상단 공격＇이랑 뭐가 다른가?
• ‘하단’ 공격이므로 상대의 상단 공격을 피할 수 있다.
49. 디자인 네이밍 가이드라인
• 복잡하게 느껴지는 원인 중 하나는 판정 이름
• 상단, 중단, 하단, 특수 상단, 특수 중단, 특수 하단, …
• 방어와 회피를 동시에 표현하려고 했기 때문
• 판정을 방어와 회피로 나누어 직교적으로 표현해보자
항상 방어 가능
서서 방어 가능
앉아서 방어 가능
방어 불가능
*
항상 회피 가능
서서 회피 가능
앉아서 회피 가능
회피 불가능
50. 디자인 네이밍 가이드라인
• 답은 ‘있다’ 이다.
• 하단 공격은 ‘항상 방어 가능’, ‘앉아서 회피 가능’
• 따라서 서서 막을 수 있다.
• 사실, 모션 보고 직관적으로 알 수 있어야 한다.
• 상중하 판정 개념이 너무 낡은 탓
51. 디자인 네이밍 가이드라인
• 설명하기 어려운 대상에 코드네임을 사용
• 이름을 붙이기 어렵다면 숫자나 기호를 사용하는 것을 고려할 것
• 친숙한 단어를 사용하면 기억하기 쉬워서 전달력이 높다.
DESTINY 에러 코드. ‘beetle’이 ‘0x3949’ 보다 기억하기 쉽다.복잡한 디자인에 이름을 붙이려 고생하다가 문서 번호를 사용해서 행복해진 사례
52. 디자인 네이밍 가이드라인
• 개발 용어와 게임 내(In-Game) 용어를 구별
• 모든 개발 용어를 게이머에게 그대로 전달할 필요는 없다.
• 전문 용어, 게임 설정과 맞지 않는 용어는 게임에 그대로 노출하지 않는 것이 좋다.
• 부정적, 파괴적인 표현 대신 일상적인 표현을 사용할 것
53. 디자인 네이밍 가이드라인
• 커뮤니티 용어는 주의해서 사용
• 커뮤니티 용어 자체가 나쁜 것은 아니나 거칠고 자극적인 표현들이 많다.
• 범람하는 커뮤니티 신조어를 정제하는 역할은 업계에 있다고 생각
55. 어셋 네이밍 가이드라인
• 어셋에 임시 이름 같은 것은 없다.
• “이 파일 이름은 임시로 대충 정하고 나중에 바꾸지 뭐”
→ 이런 이름은 대부분 게임 출시할 때까지 사용된다.
• 어셋이 일단 배포되면 이름을 변경하기 대단히 어렵고 귀찮기 때문
• 어셋 이름은 처음부터 신중하게 결정한다.
56. 어셋 네이밍 가이드라인
• 엔진 및 플랫폼 특성을 고려
• 아무리 좋은 이름이라도 사용할 수 없다면 쓸모 없다.
• 일반적으로 알파벳과 숫자, 언더스코어(‘_’)만 사용하는 것이 안전: [0-9a-zA-Z_]
• 이름의 최대 길이, 대소문자 구별 여부 등을 미리 숙지
57. 어셋 네이밍 가이드라인
• 공백 문자 주의
• 이름 앞 뒤에 공백문자가 있는 파일이 있으면 매우 찾기 어려운 문제를 경험할 것이다.
• 공백 문자가 이름 중간에 있어도 문제되는 경우가 있다.
• 그냥 이름에 공백 문자는 쓰지 말자.
58. 어셋 네이밍 가이드라인
• 사전 순서를 고려
• 어셋들은 보통 이름순으로 정렬되어 리스트에 표시된다.
• 연관된 어셋끼리 인접하도록 이름을 붙여야 검색할 때 편하다.
• 중요한 단어를 앞쪽에 배치할 것
59. 어셋 네이밍 가이드라인
• 스크립트로 검사 자동화
• 앞서 언급된 내용을 자동으로 검사하는 도구를 만들 수 있다.
• ‘어셋 가져오기’, ‘빌드’ 등의 이벤트에 검사를 예약해 두면 삶이 편해진다.
• 구현 예제를 찾고 싶다면 “filename linter”로 구글링
61. 결론: 네이밍은 어렵다
• 이름의 중요성
• 네이밍은 대상을 이해하고 문제를 정의하는 작업이다.
• 가독성 높은 이름은 대화의 품질을 향상시킨다.
• 네이밍 가이드라인
• 간단명료하고 기억하기 쉬운 이름을 붙인다.
• 이름의 용도와 목적에 맞게 붙인다.
• 사용할 수 있는 단어인지 확인한다.
62. • 추천도서
• Dustin Boswell, Trevor Foucher. The Art of Readable Code. O’Reilly Media, 2011
• Evans, Eric. Domain Driven Design Tackling Complexity in the Heart of Software. Addison Wesley, 2003.
• Robert Cecil Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall, 2009.
• Steve McConnell. Code Complete. 2nd ed. Microsoft Press, 2004.
참고자료
• 코딩 컨벤션
• AOSP Java Code Style for Contributors LINK
• Coding Guidelines for Cocoa LINK
• Google Style Guides LINK
• Swift API Design Guidelines LINK
• Unreal Engine Coding Standard LINK
63. • 프로그래밍 관련
• 김주복. 『카메라 시스템을 통해 살펴보는 인터랙티브 시스템 개발의 문제점』. NDC2011 LINK
• Bool 변수 이름 제대로 짓기 위한 최소한의 영어 문법 LINK
• Django FAQ LINK
• Don’t go into programming if you don’t have a good thesaurus LINK
• Gamemakin UE4 Style Guide() LINK
• MVC Patterns and Django LINK
• New Programming Jargon LINK
• Software Complexity: The Art of Naming LINK
• Ubiquitous Language & the joy of naming LINK
• Unreal trivia: What does the ‘F’ prefix on classes and structs stand for? LINK
• What’s in a Name: Consistency LINK
• Wikipedia, First-class citizen LINK
• Wikipedia. lint(software) LINK
• Wikipedia. Michael Widenius LINK
• Wikipedia. Naming convention (programming) LINK
• Wikipedia. Orthogonality (programming) LINK
• Wikipedia, Spaghetti code LINK
• Wikipedia, Web 2.0 LINK
참고자료
64. 참고자료
• 디자인 관련
• Wikipedia. Flavor text LINK
• Gamespot. Destiny’s Error Codes and Their Solutions LINK
• Wikipedia. 대한민국의 인터넷 신조어 목록 LINK
• 어셋 관련
• Managing Assets – Part 2: Setting Naming Conventions LINK
• Naming Files, Paths, and Namespaces LINK
• Stanford. Best practices for file naming LINK
• Unity. Loading Resources at Runtime LINK
• Wikipedia. Comparison of file systems LINK
65. 참고자료
• 기타
• 귤에 붙어 있는 그거 뭐지? 이름 모를 ‘그거’를 알려주마 LINK
• 행복회로 어원 LINK
• 제목학원 레전드 모음 LINK
• 중공군 포위망서 美 해병대 구한 ‘초콜릿(투시 롤) 사탕’ LINK
• GoogleTrends. America’s most misspelled words LINK
• Squadhelp LINK
• 横展開 LINK
