최근 내역 화면을 수정하면서 이상했던 점이 하나 있었다. 데이터에는 숫자 하나가 들어오는데 화면에서는 색도 다르고 문구도 다르고, 어떤 경우에는 아예 보이지 않았다. 처음에는 프리팹 연결이 잘못된 줄 알고 Inspector만 계속 열어 봤다.
실제로는 값이 화면에 도착하기 전에 여러 번 의미가 바뀌고 있었다. 원본 숫자는 통화 규칙에 맞춰 문자열이 되고, 결과 상태에 따라 부호와 색이 결정되고, 상품 유형에 따라 표시할 패널까지 달라졌다.
원본 값과 화면 값은 같지 않았다
예를 들어 12.5라는 값이 있다고 해도 화면에서 바로 12.5를 출력할 수는 없었다. 통화에 따라 소수점 자릿수가 달랐고, 손실이면 부호와 색을 바꿔야 했다. 값이 없음을 0으로 받은 경우와 실제 결과가 0인 경우도 구분해야 했다.
처음에는 UI 스크립트에서 하나씩 처리했다.
amountText.text = value.ToString("N2");
amountText.color = value < 0 ? lossColor : profitColor;
하지만 조건이 늘수록 같은 변환 코드가 여러 프리팹에 흩어졌다. 어느 화면은 두 자리, 다른 화면은 세 자리로 보이는 문제가 생겼고, 한쪽만 고치면 다른 쪽은 그대로였다. 그래서 원본 값을 받는 부분과 화면 문자열을 만드는 부분을 나눠 봐야 했다.
조건문을 지우기보다 위치를 옮겼다
당시에는 조건문이 많으면 나쁜 코드라고 막연하게 생각했다. 실제로 따라가 보니 조건 자체는 없어질 수 없었다. 상품이 다르면 표시 규칙도 달랐다. 필요한 건 조건을 감추는 게 아니라 비슷한 판단을 한곳에 모으는 일이었다.
string FormatAmount(decimal value, CurrencyRule rule)
{
return value.ToString($"N{rule.decimalPlaces}");
}
이렇게 화면용 문자열을 먼저 만들고 나니 프리팹은 전달받은 값을 표시하는 데 집중할 수 있었다. 색상과 노출 여부도 같은 방식으로 화면 모델에 담으면, 어떤 규칙 때문에 결과가 달라졌는지 찾기가 쉬워졌다.
안 보이는 것도 하나의 상태였다
가장 오래 헤맨 건 값이 안 보이는 경우였다. 텍스트가 비어 있으니 데이터가 없다고 생각했는데, 실제로는 특정 조건에서 부모 패널을 비활성화하고 있었다. 자식 텍스트를 아무리 수정해도 부모가 꺼져 있으니 보일 리가 없었다.
그 뒤부터는 화면 문제가 생기면 값만 확인하지 않고 다음 순서로 봤다.
원본 응답
-> 화면용 데이터 변환
-> 노출 조건
-> 프리팹 선택
-> 텍스트·색상 적용
한 단계씩 로그를 남기자 값은 맞는데 노출 조건이 틀린 경우와, 처음부터 변환이 잘못된 경우가 구분됐다.
UI는 데이터를 번역하는 곳이었다
이전에는 UI를 데이터를 예쁘게 배치하는 영역으로 생각했다. 이번 작업을 하면서 UI가 사용자가 이해할 수 있는 의미로 데이터를 번역하는 마지막 단계라는 걸 알았다. 같은 값도 맥락에 따라 다른 모습이 될 수 있고, 그 맥락을 코드 어디에서 책임질지 정하는 일이 중요했다.
큰 기능을 만든 건 아니지만 이후 화면 오류를 볼 때 “값이 왔나?”에서 멈추지 않고 “이 값이 어떤 단계를 거쳐 지금 모습이 됐나?”를 묻게 됐다. 복잡한 화면을 읽는 순서를 처음 만든 셈이다.