게임 프로그래밍 패턴 | Chapter 01 구조, 성능, 그리고 게임

1. 구조, 성능, 그리고 게임

1.1 소프트웨어 구조

■ 1.1.1 좋은 소프트웨어 구조

 좋은 소프트웨어 구조란, 무언가를 고쳐야 할 때 그럴 줄 알았다는 듯이 코드가 준비되어 있는 것을 의미한다. 즉, 코드를 거의 건드리지 않고도 적당한 함수를 호출하면 원하는 작업을 할 수 있어야 한다. 먼저 구조는 변경과 관련이 있다. 얼마나 코드를 쉽게 변경할 수 있느냐가 코드 설계를 평가하는 척도가 된다.

 

■ 1.1.2 코드를 고치는 방법

 무슨 이유에서든지 코드를 고쳐야 한다면 먼저 기존 코드를 이해해야 한다. 머릿속에 코드에 대한 큰 그림을 그리고 나면 해결책을 금방 찾을 수 있다. 컴파일이 성공하고 원하는 대로 코드가 돌아가면 코드 리뷰를 요청하기 전에 코드를 정리해야 한다. 추가한 코드를 나머지 코드와 깔끔하게 통합하고 어느 정도 맞춰야 한다.

그림 1-1 프로그래머의 업무

 

■ 1.1.3 디커플링

 소프트웨어 구조의 많은 부분은 코드 파악 단계와 관련이 있다. 머릿속에 코드를 로딩하는 게 굉장히 느리기 때문에 작업에 들어가기 전에 알아야 할 지식의 양을 줄이는 것이 소프트웨어 구조의 핵심 목표다. 디커플링(decoupling)은 양쪽 코드 중에서 한쪽이 없어도 코드를 이해할 수 있는 것을 말한다. 커플링이 적은 코드일수록 어느 한 코드를 변경했을 때 다른 코드를 변경하지 않아도 되고 나머지 게임 코드에 미치는 영향이 적다.

 

1.2 비용

 구조화가 잘 이루어진 코드는 생산성을 크게 높여준다. 이러한 구조를 만들고 유지하려면 많은 노력과 원칙이 필요하다.  추상화 계층을 추가하거나 확장 가능성을 제공하는 것은 이런 유연성이 나중에 필요할 것이라고 예측했기 때문이다. 하지만 예측이 빗나가 만들어놓은 모듈을 써먹지 못한다면 작업해야 할 코드가 늘어난다. 보조 코드가 늘어나면 실제 작업 코드를 찾는 게 오래 걸리고 이해해야 하는 코드의 양이 늘어난다.

 

1.3 성능과 속도

 프로토타이핑을 빠르게 하기 위해 프로그램을 유연하게 만들면 성능상 비용이 발생한다. 코드를 유연하게 만드는 패턴이 어느 정도 런타임 비용을 요구하기 때문이다. 반대로 코드를 최적화하면 유연성이 떨어진다. 처음에는 코드를 유연하게 유지하다가 기획이 확실해지면 추상 계층을 제거하여 성능을 높이는 타협안도 있다.

 

1.4 나쁜 코드의 장점

 기획한 내용을 확인하기 위해 그 기능만 돌아가도록 코드를 대강 작성하는 프로토타입 기법은 아주 좋은 프로그래밍 실천법이다. 단, 임시 코드는 나중에 확실히 버릴 수 있게 해야 한다. 지속 가능한 상태를 유지할 수 없기 때문이다.

 

1.5 균형 잡기

 우리에게는 다음과 같은 목표가 있다. 이 목표는 서로 상반되기 때문에 트레이드 오프(trade off) 외에는 명쾌한 정답이 없다.

• 프로젝트 개발 기간 동안 코드를 쉽게 이해할 수 있도록 구조를 깔끔하게 만들고 싶다.
• 실행 성능을 최적화하고 싶다.
• 개발 중인 기능을 최대한 빠르게 구현하고 싶다.

 

1.6 단순함

 이러한 제약을 완화할 방법이 하나 있다면 단순함이다. 코드를 최대한 간결하게, 문제를 직접 해결하는 방향으로 작성하면 그 의도를 바로 알 수 있고 코드의 양도 줄어든다. 한편, 우리에게 주어지는 문제들은 대부분 우아하지 않고 수많은 유스 케이즈(use case)로 되어 있다. 이에 대한 해결책은 일반적인, 즉 적은 논리로 최대한 많은 유스 케이스를 처리할 수 있는 코드를 작성하는 것이다.