움직이는 화면의 동작을 이해하려고 할 때, 코드부터 전부 읽으려 하면 금방 길을 잃는다. 무엇이 달라졌는지부터 한 장씩 비교하면 출발점이 작아진다. 물체가 옮겨 간 자리와 비워진 자리, 그 위에 다른 물체가 겹치는 순서를 따로 적어 보는 것이다.
Andrew Healey는 Fast Food Tycoon 2의 화면을 조사한 글에서 배경 그림과 움직이는 요소, 다시 그릴 영역, 빛의 처리를 나누어 설명한다. 원문은 작성자가 역공학으로 해석한 결과다. 내가 게임을 실행하거나 내부 구현을 재현한 것은 아니며, 그 수치와 해석을 다른 게임의 공통 구조로 일반화하지도 않는다.
내게 흥미로운 부분은 오래된 게임의 기능 목록보다 질문을 좁혀 가는 방식이다. 완성된 도시 화면을 한 번에 이해하려 하지 않고, 바뀌지 않는 부분과 움직인 부분을 분리한다. 이 관점을 빌려 작은 화면을 관찰하는 연습을 직접 구성해 볼 수 있다. 원작 그림이나 코드를 가져오지 않아도 가능한 일이다.
움직인 물체에는 이전 자리도 남는다
설명을 위한 가상 캔버스를 생각해 보자. 가로세로 200칸의 화면에 파란 사각형 하나와 주황 원 하나가 있다. 사각형이 오른쪽으로 이동했을 때 새 위치에만 다시 그리면 어떤 일이 생길까. 이전 자리에 그린 사각형을 지우지 않으면 두 개가 있는 것처럼 보인다.
그래서 변경 영역을 적을 때에는 새 위치뿐 아니라 이전 위치도 포함한다. 이 두 영역을 합친 범위에서 먼저 배경을 복원하고, 그 안에 보여야 할 요소를 다시 그리는 식으로 생각할 수 있다. 이것은 여기서 만든 단순한 설명 모형이며 모든 렌더러가 같은 절차를 사용한다는 뜻은 아니다.
주황 원이 그 영역과 겹쳐 있다면 질문이 하나 더 생긴다. 배경을 복원하면서 원의 일부도 지워질 수 있기 때문이다. 사각형만 다시 그려서는 충분하지 않다. 변경 영역과 만나는 다른 요소 중 무엇을 어떤 순서로 다시 보여 줘야 하는지 정해야 한다. ‘움직인 것은 하나’와 ‘다시 살펴야 할 것은 하나’는 같지 않다.
관찰 노트에는 이동 전 화면, 이동 후 기대 화면, 둘의 차이를 나란히 놓을 수 있다. 잘못 남은 자국은 이전 위치의 정리 문제인지, 다른 요소가 사라진 것은 재그리기 범위 문제인지 가설을 나눈다. 처음부터 하나의 원인으로 묶지 않으면 서로 다른 결함을 같은 수정으로 덮는 일을 줄일 수 있다.
앞뒤 순서를 바꾸면 장면의 뜻이 바뀐다
같은 사각형과 원도 그리는 순서에 따라 다르게 보인다. 원을 먼저 그리고 사각형을 나중에 그리면 겹친 자리에서는 사각형이 앞에 있다. 반대로 순서를 바꾸면 원이 앞에 온다. 화면에 같은 도형이 같은 좌표로 존재한다는 정보만으로는 최종 결과를 설명할 수 없다.
의자에 앉은 사람처럼 부분마다 앞뒤가 다른 경우라면 더 세밀한 단계가 필요할 수 있다. 다만 처음 연습에서는 복잡한 입체 장면을 만들기보다 두 물체의 순서를 고정하고 예상 결과를 적는 편이 낫겠다. 한 번에 위치, 색, 순서를 모두 바꾸면 무엇이 결과를 달라지게 했는지 찾기 어렵다.
색과 밝기도 따로 생각해 볼 수 있다. 원문은 빛의 정보를 별도로 다루는 구조를 설명한다. 여기서 내가 빌려 올 질문은 밤 장면의 구현법이 아니라, 화면이 어두워졌을 때 물체 자체의 정보가 바뀐 것인지 표시 과정이 바뀐 것인지다. 비슷한 결과를 만드는 경로가 둘 이상일 수 있다는 점을 남기는 것이다.
이런 구분은 프로그램을 읽을 때도 도움이 된다. 화면에서 하나의 증상을 찾았다면, 그 값을 만든 단계와 화면에 옮긴 단계를 바로 같은 것으로 취급하지 않는다. 기록된 상태는 맞는데 표시가 틀릴 수도 있고, 표시가 정확하게 잘못된 상태를 보여 줄 수도 있다. 어느 쪽인지 확인할 관찰 지점을 먼저 찾는다.
빠르게 만드는 일과 적게 그리는 일을 구별한다
바뀐 부분만 그리면 항상 더 빠를 것 같지만 비용을 나눠 봐야 한다. 변경 영역을 계산하고 겹치는 요소를 찾는 데도 일이 든다. 화면 대부분이 바뀌거나 요소가 매우 많으면 작은 영역을 관리하는 비용이 커질 수 있다. 실제 측정 없이 특정 전략이 언제나 낫다고 말할 수는 없다.
가상의 비교표에서는 전체 화면을 다시 그리는 방식과 변경 영역을 추적하는 방식을 같은 움직임으로 관찰한다. 요소가 거의 움직이지 않는 경우와 대부분 움직이는 경우를 나누고, 처리 시간뿐 아니라 사라진 요소나 잔상도 확인한다. 더 빠른 잘못된 화면을 성공으로 세지 않는 것이 비교의 시작이다.
여기서는 그런 실행 측정을 하지 않았다. 종이에 적은 기대 결과와 확인할 항목을 제안하는 데 범위를 둔다. 실제로 구현한다면 같은 입력과 환경을 유지하고, 재현할 수 있는 자료를 남겨야 한다. 성능 숫자를 얻은 뒤에는 그 숫자가 화면 전체의 반응을 뜻하는지 특정 함수만을 뜻하는지도 구분해야 한다.
작은 프로그램을 읽는 연습에서도 입력과 끝을 정해 놓으면 범위를 줄일 수 있었다. 화면을 읽을 때에는 여기에 한 가지를 더해 보고 싶다. 무엇이 그대로였고 무엇이 달라졌는지다. 모든 것을 한꺼번에 이해하려는 부담 대신, 변화 하나를 설명할 수 있는 메모를 남기는 것이다.
다음에 복잡한 화면을 만나면 일단 한 번의 이동만 골라 보자. 이전 자리, 새 자리, 겹친 요소, 그려진 순서. 이 네 항목을 적은 뒤에도 설명되지 않는 부분이 무엇인지 묻는다. 작은 관찰이 쌓이면 큰 코드 덩어리 속에서도 다음에 읽을 자리를 조금 더 분명하게 찾을 수 있을 것이다.
이어 읽기: 작은 프로그램을 읽는 연습, 줄 수보다 입력과 끝을 정해보기
공개 원문을 참고하고 AI의 도움으로 구성한 글입니다. 가상의 예시는 본문에 구분했으며 제품이나 원문의 실험을 직접 실행한 후기는 아닙니다.
