모니프렌의 맞춤 캐릭터를 Mac과 Windows에서 함께 제공하려면 제작 결과가 두 앱에서 같은 의미로 읽혀야 합니다. 플랫폼이 늘어날 때마다 서버와 제작 과정을 따로 만들면 수정할 곳도 늘어납니다. 현재는 공통 결과물의 기준과 플랫폼별 처리를 나누는 방향을 검토하고 있습니다. 이 글은 그 경계를 정리한 설계 기록이며, 전체 구현이나 배포가 끝났다는 보고는 아닙니다.
제작 결과의 의미를 공통으로 정하고 화면 처리는 각 앱에 남기기
같은 파일을 받는 것에서 한 걸음 더
맞춤 캐릭터의 이미지가 같아도 두 앱이 같은 결과를 보여준다고 보장할 수는 없습니다. 어떤 이미지가 정면인지, 눈을 감은 상태인지, 어느 영역을 표시해야 하는지 해석하는 기준이 필요합니다. 파일을 전달하는 단계와 화면에서 그 의미를 읽는 단계를 함께 살펴봐야 합니다.
가상의 상황으로, 같은 묶음을 받은 두 앱이 방향의 의미를 다르게 읽는 경우를 생각할 수 있습니다. 이미지 자체는 정상이어도 한쪽에서는 예상한 자세가 나오고 다른 쪽에서는 다른 자세가 나올 수 있습니다. 이런 차이를 막으려면 파일이 존재하는지에 더해 각 자산이 어떤 역할을 하는지 두 앱이 같은 기준으로 이해해야 합니다. 이는 설명을 위한 예시이며 실제로 발생한 오류를 기록한 것은 아닙니다.
공통으로 정할 의미
검토 중인 방향은 형식 버전, 자산 목록, 방향과 상태의 의미를 공통 결과물에 담는 것입니다. 형식 버전은 앱이 받은 결과물을 어느 기준으로 읽어야 하는지 구분하는 데 필요합니다. 자산 목록은 무엇이 들어 있어야 하는지 확인하는 기준이 되고, 방향과 상태는 화면에서 어떤 이미지를 선택할지 연결해줍니다.
공통 기준이 있으면 제작 과정에서 내보내는 결과와 앱이 기대하는 내용을 맞춰볼 수 있습니다. 변경이 필요할 때에도 어느 의미가 달라졌는지 설명할 자리가 생깁니다. 다만 기준을 문서로 정했다고 해서 모든 앱이 곧바로 같은 방식으로 처리하는 것은 아닙니다. 실제로 읽고 표시하는 동작은 별도로 확인해야 합니다.
공통화의 범위는 두 앱이 함께 이해해야 할 캐릭터의 의미를 중심으로 정하려 합니다. 모든 처리를 하나로 합치려 하면 플랫폼의 차이까지 같은 규칙으로 설명해야 할 수 있습니다. 어디까지 일치해야 하는지 먼저 정하면, 각 앱에 남겨도 되는 차이도 더 분명하게 볼 수 있습니다.
각 앱에 남겨둘 차이
화면 배율과 저장 위치처럼 실행 환경에 영향을 받는 처리는 각 앱에 남기는 방향입니다. 같은 캐릭터를 표현하더라도 실제 화면에 배치하고 필요한 파일을 다루는 과정은 플랫폼의 조건을 고려해야 합니다. 공통 의미를 받아 화면에 맞게 처리하는 경계를 두면 역할을 나누어 검토할 수 있습니다.
결제와 로그인도 별도의 문제입니다. 스토어마다 규칙이 있는 부분을 캐릭터 형식과 함께 묶으면, 파일을 읽을 수 있다는 사실과 사용할 권한이 있다는 사실이 혼동될 수 있습니다. 같은 형식을 쓴다고 구매 권한까지 자동으로 공유되는 것은 아닙니다.
따라서 두 앱에서 캐릭터를 제공한다는 목표에는 서로 다른 확인이 포함됩니다. 결과물의 의미가 같은지, 각 앱에서 올바르게 표시되는지, 해당 환경에서 사용할 권한이 확인되는지를 나누어 봐야 합니다. 이 구분은 사용자에게 모든 내부 차이를 설명하기 위한 것이 아니라, 개발 범위를 빠뜨리지 않기 위한 기준입니다.
기존 Mac 결과물도 읽을 수 있도록
새 기준을 도입할 때에는 기존 Mac 캐릭터를 다시 만들지 않아도 되는지 살펴봐야 합니다. 이전 형식의 결과물을 새 기준으로 읽을 수 있게 하는 변환 계층이 필요한 이유입니다. 새로 만들어진 결과물만 정상 동작하면, 이미 제작된 캐릭터가 빠지는 문제가 남습니다.
호환을 검토할 때에는 이전 정보로 확실히 알 수 있는 것과 알 수 없는 것을 나누어야 합니다. 새 기준에 필요한 항목이 없다고 해서 임의로 의미를 붙여 통과시키면, 파일을 읽는 데 성공해도 잘못된 모습으로 표시될 수 있습니다. 변환할 수 없는 항목은 부족한 정보를 알리는 쪽으로 다루어야 합니다.
어떤 이전 결과물을 지원할 수 있는지, 무엇을 추가로 확인해야 하는지 드러나면 호환의 범위도 설명할 수 있습니다. 모든 옛 형식을 지원한다고 넓게 말하기보다 실제로 확인한 대상을 기준으로 말해야 합니다. 현재 글은 이 필요성을 정리한 것으로, 기존 결과물의 호환 검증이 모두 끝났다는 뜻은 아닙니다.
정상 입력과 잘못된 입력을 함께 확인하기
다음 확인에서는 정상 묶음뿐 아니라 방향 누락, 지원하지 않는 버전, 자산 손상 같은 예제를 두 앱에서 살펴봐야 합니다. 정상 사례만으로는 결과물이 불완전할 때 앱이 어떻게 반응하는지 알기 어렵습니다. 어느 단계에서 문제를 알리고 어떤 내용을 설명하는지도 확인 대상입니다.
가상 검증 사례로는 필요한 방향 이미지가 빠진 묶음을 두 앱에 전달해보는 방법이 있습니다. 두 앱이 동일한 문제를 인식하는지, 누락을 다른 자세로 오해해 표시하지는 않는지 볼 수 있습니다. 오류 문구가 완전히 같아야 하는 것은 아니지만, 사용자가 이해하는 문제와 다음 행동은 일관될 필요가 있습니다. 이 역시 앞으로 사용할 수 있는 검증 예시입니다.
공통 형식 설계, 서버 반영, 기존 결과물 호환, 실제 표시, 배포는 서로 다른 단계입니다. 어느 하나의 완료로 나머지까지 끝났다고 판단하지 않으려 합니다. 지금의 설계에서 남긴 핵심은 제작 결과의 의미를 함께 정하고, 각 환경의 처리는 그 의미를 유지하도록 나누는 것입니다. 두 플랫폼의 실제 표시와 배포 상태는 이후 검증으로 확인해야 합니다.
