한글날에 손봐놓은 코드를 우 대리님께 보여드렸다. 역시 텍스쳐 바인드 함수를 루프에서 계속 부르는 게 맞았다. 메모리 누수는 다시 확인해 봐야겠다. 스택오버플로우에선 glTexSubImage()를 곁들여 써줘야 한다는 이야기가 있었기 때문이었다. 프레임이 재차 돌기 시작할 때 잠깐 화면이 깜빡이는 현상은 우 대리님이 프레임값 조건부를 수정하시는 것으로 금방 잡혔다. 왜 난 바보같이 프레임값에 중단점 걸어놓고 살펴볼 생각을 하지 못했을까.
애니메이션 옆에 새로 보내주신 파일들을 출력해 보라는 오더가 떨어졌다. 뷰포트 입력값 받도록, 그리고 새로운 경로값 받도록 기존 멤버 함수들을 수정해서 금방 해결할 수 있었다. 하지만 만약 파일이 48개가 아니라 24개라면? 경로값 받아서 폴더의 PNG 읽는 부분에 파일 카운트를 생성시켜 해결하려는 고민이 시작된 와중 우 대리님께서 내 코드를 살펴보셨는지 다시 오셔서 리팩토링을 지시하셨다. 클래스별 할일이 너무 뭉뚱그려져 있다는 말씀이었다. 정확한 지적이었다. OpenGL은 멀티플랫폼 지향의 스테이트머신이므로 프레임워크도 C 스타일의 나열형으로 돼있었다. 여기에 나는 요구사항의 변화에 따라 그때그때 코드 더미들을 클래스로 잡아 빼는 일만 했을 뿐이다. 이런 식으로 요구사항이 더해질 때마다 클래스의 할일을 임기응변으로 잘게 분할하다 보면 종래에는 눈물의 리팩토링을 마주하게 될지도 모를 일이다. 우 대리님 말씀대로 애초에 클래스 설계를 좀 더 신경써서 해놓을 필요가 있다.
하지만 새로운 설계와 이 설계에 맞게 리팩토링 하는 일은 - 코드의 복잡도가 그리 높지 않음에도 - 쉽게 되지 않았다. 설명을 듣기로는, 예를 들자면 '다리를 두껍게 해서 무게를 지탱하면 몸뚱이가 올라가니까 여기서 코를 길게 빼고 코를 손처럼 쓰면 편하다'는 이야기였는데 애초에 나는 코끼리를 보거나 만들어 본 경험이 없으므로 맨땅에서 코끼리 비스무리한 동물을 만들어 보려 애쓰는 꼴이 되는 것이다. 여기에 더해 클래스끼리 자료를 주거니 받거니 변형하는 등 확인 작업이 뒤따라야 하므로 - 뻔히 돌아가던 코드를 개념적으로 분할해 이해하는 것과 실제적 결과물로 만들어내는 것의 차이가 생기게 마련. 이러나저러나 변명은 필요 없다. 최대한 빠르게 결과물을 만드는 수밖에. 나의 쓰레기 같은 퍼포먼스를 좀 고치고 싶지만 어차피 실력에 비례해 올라가는 것이므로 조급할 필요가 없음에도 이상하게 조급하다.