가장 낮은 사양이 기준이 되는 세계

LG ThinQ에 들어간 WebGL 엔진의 핵심을 개발하며 저희가 상대한 환경은 최신 스마트폰이 아니었습니다. 몇 년 전에 출시된 TV였습니다. 메모리는 빠듯하고 연산은 느리고, 그런데 화면은 거실에서 제일 큰 기기였습니다. MAU 150만이라는 숫자의 실제 뜻은, 가장 사양이 낮은 사용자의 기기에서도 어김없이 돌아가야 한다는 것입니다.

그 환경이 가르쳐 준 것은 최신 기법이 아니라 그 반대였습니다.

화려한 코드부터 죽습니다

개발자들이 좋아하는 것들, 그러니까 우아한 추상화, 트렌디한 패턴, "나중을 위한" 유연한 구조는 저사양 환경에서 가장 먼저 무너집니다. 추상화는 계층마다 비용을 내고, 유연함은 오늘의 메모리를 잡아먹으면서 오지 않을 내일을 기다립니다.

반대로 끝까지 살아남은 코드는 민망할 만큼 지루했습니다. 단순한 데이터 흐름. 화면에 그리는 횟수(드로우콜)를 세고 줄이는 원시적인 최적화. 어떤 입력에도 예측 가능하게 움직이고, 문제가 나면 원인을 바로 짚을 수 있는 구조.

영리함은 데모에서 이기고, 단순함은 운영에서 이깁니다. 150만 명 앞에서는 후자만 남습니다.

측정이 취향을 이깁니다

또 하나 배운 것이 있습니다. 최적화 논쟁의 답은 언제나 계측기에 있었습니다. "이 방식이 더 빠를 것 같다"는 시니어의 직감도 프로파일러 앞에서 자주 틀렸습니다. 그래서 저희에게 성능 작업이란 코드를 다시 쓰는 일이 아니라 측정하고, 병목을 찾고, 그것만 고치는 일입니다. 기기별 성능 예산을 정하고 그 안에서 노는 것. 화려하지 않지만 이게 전부입니다.

발주자가 코드를 못 봐도 확인할 수 있는 것

이 이야기가 발주자에게 왜 중요할까요. 코드 리뷰를 못 해도 이렇게 물을 수 있기 때문입니다.

• "가장 낮은 사양의 대상 기기가 뭐고, 거기서 어떻게 확인하나요?"
• "성능 목표가 숫자로 있나요? 측정은 뭘로 하나요?"
• "1년 뒤 다른 개발자가 이 코드를 이어받을 수 있나요?"

세 질문에 담백하게 답하는 팀이라면, 그 팀의 코드는 아마 지루할 겁니다. 그리고 그게 칭찬입니다. 저희가 이런 방식으로 일한 결과물들은 WebGL 프로젝트에서 보실 수 있습니다.