브라우저에서 입체 장면이 보이면 화면 뒤에서 계속 무언가 계산되고 있을 것 같습니다. 실제로 움직이는 장면이라면 그럴 이유가 있겠지만, 아무것도 바뀌지 않는 화면도 있습니다. 작은 재고 선반이나 제품 모형을 보여 주는 화면을 만든다면, 먼저 무엇이 달라질 때 다시 그려야 하는지 적어 볼 수 있겠습니다. 멋진 효과를 더하기 전에 정지해 있어도 되는 시간을 살피는 것입니다.
phoria2의 공식 소개는 WebGL 2 기반의 작은 자바스크립트 3D 라이브러리를 설명하며, 변화가 있을 때에만 화면을 그리는 방식을 내세웁니다. 옵션을 검증하고 수정에 도움이 되는 오류를 제공한다는 설명도 있습니다. 이는 제작자의 기능 안내이며, 여기서 라이브러리를 설치해 성능을 측정한 것은 아닙니다. 소개를 계기로 정적인 입체 화면의 갱신 조건을 생각해 보려 합니다.
참고 원문: Kevin Roast의 관련 원문
그림이 달라지는 사건부터 적기
가상의 재고 현황 화면을 하나 만들어 본다고 가정해 보겠습니다. 상자 몇 개를 선반 위에 놓고, 선택한 상자의 정보를 옆에 보여 주는 화면입니다. 카메라는 고정되어 있고, 재고 데이터도 사용자가 새로 불러올 때만 달라집니다. 이런 조건이라면 화면을 다시 그릴 이유가 무엇인지 문장으로 적을 수 있습니다. 데이터 변경, 선택 변경, 화면 크기 변경 같은 사건입니다.
처음부터 ‘항상 다시 그린다’고 정해 두면 이 사건들을 구분하지 않아도 됩니다. 구현은 편할 수 있지만, 나중에 불필요한 작업을 찾기 어려워질 수도 있습니다. 반대로 아무것도 그리지 않는 시간을 만들려면 무엇이 결과 화면에 영향을 주는지 알아야 합니다. 매번 그리기를 멈추는 작은 선택이 화면의 의존 관계를 살피는 질문으로 이어지는 셈입니다.
예시의 상자 색이 재고 상태를 나타낸다면 데이터가 바뀔 때 장면도 갱신해야 합니다. 사용자가 상자를 골랐을 때 테두리가 바뀐다면 선택도 갱신 조건입니다. 창의 크기가 바뀌어 장면의 비율이 달라진다면 그 역시 조건에 들어갑니다. 겉으로는 정적인 화면이어도 아무 조건 없이 한 번만 그리면 된다는 뜻은 아닙니다.
정지와 움직임을 같은 규칙에 넣지 않기
같은 화면에 천천히 회전하는 제품 모형을 추가하면 이야기가 달라집니다. 시간이 흐르는 것 자체가 그림을 바꾸는 원인이기 때문입니다. 카메라를 움직이는 동안과 사용자가 손을 뗀 뒤의 상태를 나누어 볼 수도 있습니다. 이런 차이를 놓친 채 갱신을 줄이면 효율을 얻기 전에 필요한 움직임이 끊길 수 있습니다.
간단한 가정으로 생각해 볼 수 있습니다. 1초에 60번 다시 그리도록 정한 코드가 1분 동안 실행되면 호출 기회는 3,600번입니다. 이 계산은 특정 라이브러리의 측정값이 아니라 호출 수를 이해하기 위한 산술 예시입니다. 호출을 적게 한다고 처리 시간이나 전력도 같은 비율로 줄어든다고 말할 수는 없습니다. 실제 작업의 내용과 브라우저의 동작을 따로 보아야 합니다.
그렇다면 확인할 항목도 호출 수 하나로 끝나지 않습니다. 필요한 순간에 새 내용이 나타나는지, 선택 표시가 뒤늦게 바뀌지 않는지, 창을 줄인 뒤 화면이 어긋나지 않는지 살핍니다. 갱신을 줄인 전후를 비교한다면 같은 장면과 같은 조작을 써야 합니다. 데이터와 기기를 함께 바꿔 놓으면 차이의 이유를 설명하기 어려워집니다.
이 글에서 제안하는 것은 모든 화면에 맞는 성능 기법이 아닙니다. 계속 움직여야 하는 시뮬레이션이나 게임에는 다른 판단이 필요할 수 있습니다. 정적인 화면이라는 처음의 가정이 유지되는지부터 확인하는 편이 좋겠습니다. 처음에는 고정된 선반이었어도 나중에 자동 카메라 이동을 붙였다면 갱신 규칙도 다시 보아야 합니다.
입력을 틀리게 주었을 때 알 수 있어야 할 것
라이브러리의 오류 설명을 읽기 쉽게 만드는 문제도 같은 맥락에서 볼 수 있습니다. 옵션 이름을 잘못 적었을 때 화면이 조용히 멈추는 것과, 어느 값을 고쳐야 하는지 알려 주는 것은 작업의 다음 단계를 다르게 만듭니다. 다만 설명이 친절하다는 소개만으로 실제 오류 처리 전체가 검증되었다고 적을 수는 없습니다. 사용하는 경로에서 직접 확인할 일입니다.
가상의 선반 화면을 검토한다면 정상 데이터만 넣어 보지 않을 것입니다. 상자 위치가 빠진 항목이나 지원하지 않는 색상 값처럼, 실제로 잘못 들어올 수 있는 입력도 적어 봅니다. 여기서 중요한 것은 오류 메시지의 길이보다 다음 행동을 알 수 있는지입니다. 입력을 고쳐야 하는지, 화면을 다시 열어야 하는지, 지원하지 않는 기능인지 구분할 수 있어야 합니다.
AI가 코드를 작성하는 과정에서도 같은 기준을 쓸 수 있습니다. 설명 가능한 오류가 있으면 다음 수정을 검토하기 쉬울 수 있지만, 에이전트가 메시지를 읽었다고 올바르게 고쳤다는 보장은 없습니다. 변경 뒤 실제 화면과 동작을 다시 확인해야 합니다. 도구가 에이전트를 지원한다는 말과 사람이 확인할 책임이 없어졌다는 말은 함께 가지 않습니다.
입체 장면 밖에서도 정보를 읽을 수 있게
재고 현황을 입체 장면으로 보여 주기로 했더라도 모든 정보가 그 장면 안에만 있을 필요는 없습니다. 같은 항목을 이름과 상태로 읽을 수 있는 목록을 옆에 두는 방법도 생각해 볼 수 있습니다. 그림을 잘 돌려 보아야만 필요한 숫자를 알 수 있다면, 입체 표현이 오히려 작업을 어렵게 만들 수 있으니까요. 어떤 표현이 독자의 과제를 돕는지부터 살피고 싶습니다.
예시에서는 상자를 선택하는 조작과 목록에서 항목을 고르는 조작이 같은 상태를 가리키는지 확인할 수 있습니다. 그 연결이 맞다면 한쪽 표현을 쓰기 어려울 때 다른 쪽에서 작업을 이어갈 여지가 생깁니다. 이것만으로 접근성을 모두 검증했다고 말할 수는 없습니다. 실제 입력 방법과 읽기 순서에 대한 확인은 따로 남아 있습니다.
작은 도구를 고를 때에도 기능 목록의 길이보다 내가 필요한 장면을 설명할 수 있는지가 먼저일 것 같습니다. 정지해 있는 시간, 데이터가 바뀌는 순간, 사용자가 움직이는 순간을 나누어 적어 봅니다. 그다음에야 어떤 기능이 도움이 되는지 비교할 수 있습니다. 선택한 도구의 이름이 이 질문들을 대신해 주지는 않습니다.
나는 화면이 부드럽게 움직인다는 인상과 필요한 때 정확히 바뀐다는 판단을 구분해서 보고 싶습니다. 지금 만들려는 화면에서 정말 시간이 흐르는 것만으로 달라져야 할 내용은 무엇일까요. 그 답이 많지 않다면, 계속 움직이는 장치보다 변화를 알아차리는 조건부터 설계해 볼 수 있겠습니다.
함께 읽기: 모여라! WebGL 데모들!
공개 원문을 참고하고 AI의 도움으로 구성한 글입니다. 자체 예시는 본문에 구분했으며, 원문의 제품이나 실험을 직접 실행한 후기가 아닙니다.
