GPU가 없어도 초록불은 켜진다
vgpu의 mock 테스트를 보며, 명령을 확인한 초록불에서 실제 삼각형의 픽셀까지 남은 거리를 생각했다.
삼각형을 그렸다는 말
화면 가운데 작은 삼각형을 띄우는 기능을 만든다고 해보자. 코드를 올렸고, CI에 초록불이 켜졌다. 리뷰 화면에는 통과한 테스트 목록이 있다. 그런데 정작 삼각형 사진은 없다.
여기서 잠깐 멈추게 된다. 이 테스트는 무엇을 봤을까. 그리라는 명령을 보냈는지, 필요한 자원을 준비했는지, 아니면 화면에 나온 픽셀까지 봤는지. 모두 같은 기능 주변의 일인데, 답을 구하는 방법은 꽤 다르다.
vgpu 문서에서 눈에 들어온 것은 GPU 없이 실행하는 mock이었다. WebGPU를 다루는 이 TypeScript 라이브러리는 브라우저용 경로와 Dawn 기반의 Node 경로, 테스트용 mock 경로를 구분해 둔다. mock 어댑터 문서에는 용도가 더 짧게 적혀 있다. 명령과 자원 테스트에는 mock을, 실제 렌더링과 읽어 온 결과의 스냅샷에는 Node 경로를 쓰라고.
읽으면서 종이로 만든 무대 모형을 떠올렸다. 배우가 어느 문으로 들어오고 소품을 어디에 놓을지는 모형에서도 이야기할 수 있다. 조명이 켜졌을 때 얼굴에 그림자가 어떻게 떨어지는지는 무대에 가서 봐야 한다. 모형이 다룰 수 있는 질문이 있어서, 굳이 매번 극장을 빌리지 않아도 되는 것이다.
삼각형도 그럴 것이다. GPU를 쓸 수 없는 실행 환경에서 명령과 자원에 관한 테스트를 돌릴 수 있다면, 화면을 띄우기 전에도 고칠 수 있는 실수가 생긴다. 어느 검사가 실제로 무엇을 잡는지는 작성한 테스트의 단언을 읽어 확인해야겠지만.
다만 초록불 하나에 모형과 조명의 일을 전부 맡기고 싶어지기는 쉽다. 통과라는 단어는 짧고, 그 옆에 붙일 설명은 길다.
사진이 한 장 생긴 뒤에도
가상의 삼각형 기능으로 돌아가 보자. 자원을 만들고 정리하는 흐름에 관한 검사를 추가했다면, 그 결과에는 무엇을 검사했는지 남기면 된다. 예를 들어 작성한 검사에서 어떤 호출이나 상태를 기대했는지. 테스트 이름이 그 범위를 숨기지만 않아도 다음 사람이 초록불을 읽기 쉬워진다.
다음으로 실제 렌더링 경로를 실행하고 결과 픽셀을 읽어 스냅샷을 남겼다고 해보자. 이제는 이미지가 있다. 삼각형이 기대한 자리에 있는지, 배경색이 맞는지 같은 질문을 그 이미지에 할 수 있다. 어떤 차이를 실패로 볼지도 함께 정해야 한다.
이 글에서는 vgpu를 설치하거나 이 실험을 실행하지 않았다. 문서가 구분해 놓은 두 경로를 보고, 테스트 결과를 읽는 상황을 가정하고 있다. 특히 mock이 셰이더를 어느 범위까지 처리하는지는 여기서 판단하지 않는다.
이미지가 생긴 뒤에는 다른 질문이 남는다. 그 그림은 어떤 어댑터와 실행 환경에서 나왔을까. Node에서 픽셀을 읽었다는 사실만으로 특정 그래픽카드에서 실행했다고 적을 수는 없다. 물리적인 GPU를 확인하려면 그 실행 환경의 증거가 따로 필요하다.
성능 이야기는 한 번 더 떨어져 있다. 원하는 그림이 나왔다는 기록에 프레임 시간까지 들어 있는 것은 아니니까. 속도가 궁금하면 측정 조건과 결과를 남겨야 한다. 문서의 사용 예제를 읽은 것만으로 여기에 숫자를 붙일 수는 없다.
조금 번거롭다. 기능 하나에 질문이 여러 개 붙는다. 그래도 문제가 났을 때 돌아갈 자리가 생긴다. 자원 흐름의 검사인지, 결과 이미지의 차이인지, 특정 환경에서의 실행 문제인지 알면 다음에 무엇을 봐야 할지가 좁아진다.
반대로 모든 결과를 ‘GPU 테스트 통과’ 한 줄에 넣으면, 그 초록불을 만든 사람에게 다시 물어야 한다. 그때 무슨 GPU였나요. 혹시 GPU가 있기는 했나요.
리뷰에 붙이고 싶은 것
mock 테스트가 반가운 이유는 GPU를 준비하지 않아도 물어볼 수 있는 질문을 늘려 주기 때문이다. 장비가 생길 때까지 모든 검사를 미뤄 두는 것보다, 지금 확인할 수 있는 명령과 자원부터 다루는 편이 나아 보인다.
그다음 질문을 잊지 않게 하는 자리가 필요하다. 가령 이 삼각형 기능의 리뷰라면, 명령과 자원 검사의 결과 옆에 실제 렌더링 결과를 놓고 싶다. 실제로 실행한 환경도 적고. 아직 실행하지 못했다면 그 자리에는 이미지 대신 미실행이라는 상태가 있어야 한다.
빈칸은 신경 쓰인다. 그래서 나중에 볼 일도 된다. 초록불로 덮인 빈칸은 누가 다시 열어 볼지 잘 모르겠다.
모든 변경에 같은 장비와 같은 검사를 요구하자는 뜻은 아니다. 화면과 무관한 코드를 고친 날과 셰이더를 바꾼 날에는 필요한 증거도 달라질 것이다. 리뷰에서 바뀐 것과 확인한 것을 맞춰 보는 일이 먼저다.
처음의 리뷰 화면을 다시 생각한다. 초록불 옆에 작은 삼각형 이미지가 한 장 붙어 있다. 그 아래에는 이미지를 만든 환경이 적혀 있다. 적어도 이 그림을 어디에서 봤는지는 알 수 있다.
이제 남은 질문은 조금 구체적이다. 사용자가 열 브라우저에서도, 저 삼각형이 저 자리에 있을까.