회사 코드가 아주 조금 익숙해질 무렵에는 Unity 화면에 서버 데이터를 연결하는 일을 보기 시작했다. 처음에는 버튼을 누르면 요청을 보내고, 응답을 받으면 화면에 보여 주면 된다고 생각했다. 말로만 들으면 세 단계라서 금방 할 수 있을 것 같았다. 실제로 해보니 요청을 보내는 부분은 오히려 시작에 가까웠다.
서버에서 값이 왔는데 화면이 바뀌지 않는 일이 있었다. 반대로 화면은 바뀌었지만 이전 값이 잠깐 보이기도 했다. 응답 데이터의 모양과 Unity에서 쓰는 데이터의 모양이 달랐고, 성공했을 때와 실패했을 때 지나가는 코드도 달랐다. 화면이 이미 닫혔거나 다른 탭으로 옮겨 간 뒤 응답이 도착하는 경우도 생각해야 했다. 당시에는 이런 상황이 왜 생기는지 바로 이해하지 못해서 로그를 찍고 같은 동작을 여러 번 반복했다.
가장 힘들었던 건 문제가 어느 쪽에 있는지 판단하는 일이었다. 요청이 잘못된 건지, 응답을 잘못 읽은 건지, 아니면 화면을 갱신하는 순서가 꼬인 건지 처음에는 전부 비슷해 보였다. 그래서 한꺼번에 고치려는 대신 기존 코드의 흐름을 따라 작은 부분부터 확인했다. 요청을 보낸 시점, 응답이 들어온 시점, 화면에 값을 넣는 시점을 나눠 보니 그제야 어긋난 지점이 보였다.
응답을 담는 C# 데이터도 처음에는 필드만 맞으면 된다고 생각했다. 그런데 값이 없을 때의 기본 상태나 실패했을 때 남아 있는 이전 화면도 함께 봐야 했다. 데이터 한 줄을 추가하는 일이 화면의 표시 조건까지 이어질 수 있다는 걸 이때 알았다. 작은 수정이었지만 서버와 화면 사이에 생각보다 많은 단계가 있다는 사실이 신기하면서도 부담스러웠다.
이 경험 이후로 API 작업을 볼 때 요청 주소부터 찾기보다 전체 흐름을 먼저 적어 보게 됐다. 누가 요청하고, 어떤 모양으로 응답을 받고, 그 결과를 누가 화면에 반영하는지를 차례대로 본다. 아직 내가 전체 구조를 설계할 정도는 아니었고 기존 코드를 따라가며 배운 수준이었지만, 화면 밖의 흐름을 보기 시작한 첫 경험이었다.