아래 글에 보충 설명의 리플을 적다가 뜬구름 잡는 식의 원리만 늘어 놓는다는 생각이 들어 자세히 적다보니.....리플의 형태를 벗어나게 되었습니다...OTL
적당히 읽어보시고 TU 문제가 발생하는 분들에게 조금의 도움이 되었으면 하는 바램이 있네요.
아래의 글 "오로라 TU의 이해와 프리스타일과의 상관관계" 는 해법으로는 충분히 훌륭합니다.
대부분의 경우와 대부분의 사람들에게 해당되기에 가치가 있겠지요.
허나 위의 사례로 도출된 "오로라와 프리스타일의 TU는 호환 불가능하다" 라는 귀납 공리는 맞다고 보기 어렵습니다....^^;;;;
기준이 될 공리가 잘못되었으니 그로 인해 연역 가능한 여러가지 방법론이 전부 부정 되기에 어떤 사례는 해결 가능해도 어떤 사례에는 힘을 쓰지 못하게 되죠.
- 그래서 이런 글은 그냥 지나치곤 하지만 잘못 이해되고 그것이 지식으로 굳어지면 일부 문제에 대응이 불가능하기에 도움 되시라고 딴지 비슷한 첨언을 붙이고 갑니다.....양해 하시길......ㅋ
(이전에 말씀드렸다시피 TU에 대해서 적어볼까 했지만 도저히 참을수 없는 가벼움의 귀찮음과 게으름이........ㅜㅜ)
TU 라는 것은 다들 아시다시피 타이틀 업데이트입니다.
이 업데이트는 MS에서 규정한 패킹 형식과 헤더만 갖추면 적용이 가능하게 설계되었기에 각 개발사가 어떻게 만들어도 무방합니다.
다만 스캔 및 빠른 적용을 위해 MS에서 지정한 위치가 있는데 콘솔용 업데이트 저장소인 내장하드 캐쉬폴더, 그리고 타이틀 업데이트용인 content/0000000000000000 폴더가 있지요.
이 둘은 용도에 따라 구분은 되어 있지만 어디에 두건 제일 먼저 스캔이 되는 곳이기에 각각별로 위치는 중구난방입니다.
- 맥 환경처럼 플랫폼 홀더가 강력하게 제재를 하면 되지만 MS는 태생이 항가항가한지라....ㅋ
콘솔 업데이트는 MS가 내놓는 것이기 때문에 당연히 캐쉬 폴더에 들어가지만 타이틀 업데이트는 둘 중 아무데서건 발견이 되지요.
뭐 중요한건 아니고.......자세한건 아래 글의 리플을 읽어보시고...
오로라와 프리스타일은 타이틀 스캔을 할때 위의 저장소에서 제일 먼저 헤더를 검색합니다.
그 후, 저장소에 있는 타이틀의 업데이트는 그대로 적용이 되고 업데이트가 존재하지 않는 다른 스캔된 게임은 지정된 사설 서버에서 푸쉬 요청을 하죠.
즉.....오로라건, 프리스타일이건 기본적으로 TU는 라이브 서버에서 다운되어진 개발사의 공식 TU를 추출한 것입니다. (rgloader 같은걸 쓰면 쉽게 추출이 가능하죠...)
호환이고 뭐고...같은 TU인데 어느쪽에서 사용이 불가능하다라는 공리는 성립하지 않습니다...^^
그런 TU 들을 유니티 같은 사설 서버에 모아두고 프리스타일이나 오로라가 푸쉬를 받아서 다운로드 되는 것입니다.
즉 둘이 받는 데이타는 조금도 틀리지 않은 같은 것들입니다.
- 물론 다음에 설명할 백업 매니저의 포맷 변경으로 인해 그걸 끄집어 내어 웹 상에 공유하는 경우엔 위의 기본 전제의 예외가 발생합니다.
허나 이건 극히 비정상적인 경우이고 공식 TU를 일부러 변형되어진 형태로 공유하는건 공식 TU를 추출할 능력이 안되는 사람들이 공유하기 위해 특정 매니저에서만 사용 가능한 형태로 공유하는 개인적인 일탈 사례이기도 하니...^^;;;;; 텍스트 문서를 HWP 포맷으로 전세계에 공유하는 꼴이랄까요......뭐 프리 스타일이나 오로라가 엑박씬에서는 십중 팔구 사용되긴 하지만...^^
문제는 프리스타일이건 오로라건 위의 TU를 그대로 사용하지 않는다는 것입니다.
여기에 간단히 적어놨지만.......정확히는 길게 적기 싫어서 (^^;;;) 단순하게 적은 것이고......프리스타일과 오로라는 그 TU의 처리 방식이 다릅니다.
프리스타일은 NXE 같은 환경과 호환을 위해서 초기에 설계되기를, 기본 360의 TU 경로에 사설 서버에서 받은 TU를 저장합니다.
그 후 데이타베이스에 빠른 적용과 호출을 위해 백업본을 프리스타일의 캐쉬 폴더에 저장을 하고 이를 사용합니다.
그러면 꼭 프리스타일을 사용하지 않더라도 다른 매니저들에서도 업데이트를 사용할 수 있는 장점이 있지요.
이 좋은 아이디어가 나중에는 악재가 됩니다.
누구도 기본 대쉬를 사용하지 않고 다른 매니저들은 꺼져............프리스타일로 대동단결의 대성공을 하자, TU의 중첩이라는 문제는 타이틀이 많아지면 많아질수록 감당이 안되는 사태가 된 것이죠.
그래서 프리스타일의 빌드가 올라가면서 TU를 받으면 프리스타일의 캐쉬폴더로 옮기면서 원본을 지우는 처리를 추가하게 됩니다.
이때 유니티 같은 사설 서버는 데이타 전송에 있어서 라이브 서버와 비교가 불가능하니 원본 무결성 검증을 위한 해쉬가 따라 붙게 되었고 그래서 원본 TU와 형태가 달라지게 되었지요.
어차피 프리스타일에서만 쓸거니까 별 문제는 없잖아....하는 가벼운 생각이었는데......ㅋ
설계와 기초가 부실한 집은 아무리 보강 공사를 해도 답이 안나오듯, 프리스타일은 나온지 몇해가 훌쩍 지나가면서 점점 그 한계가 드러나게 됩니다.
그 수많은 문제점 중 하나가 바로 TU의 문제입니다.
예전에도 제가 간간히 언급하곤 했지만 프리스타일의 가장 큰 문제는 데이타베이스의 비효율성과 IO의 비신뢰성입니다.
그 중에서 DB는 뭐 좀 느리면 어때, 하드가 미친듯이 헤드를 긁어대면 좀 어때.......수준이지만 파일 처리는 정말 악몽 중 악몽입니다.
360 자체는 정말 뜯고 씹고 살을 발라도 맘대로 주물럭 거리기엔 최고의 장난감이구나 싶어서 재밌게 공부했지만 프리스타일은 지금 생각해도 전세계 사람들이 몇년 동안 이 매니저를 꾸준히 써왔다는데 공포가 들 정도였지요....ㅋ
- 늘 프리스타일을 갈구는 얘기를 많이 하는거 같은데 사실 단순하게 자신의 소장 게임을 리핑해서 하드로더로 사용하기 위한 순수한 백업 유저들에게 있어서 프리스타일은 적극 권하고 싶은 좋은 물건이라 생각합니다....일단 이쁘고...^^
IO의 비신뢰성은 파일 작업에서 결과가 예측이 안된다는걸 의미합니다.
예를 들어 탐색기에서 파일을 삭제했는데, 헤더만 지우는 삭제의 문제가 아니라...말 그대로 파일이 하드에 그대로 남아 있다면 어떻게 탐색기를 사용하겠습니까...^^
그런데......또 어떨땐 잘 지워져요....ㅋ
이 문제는 TU 관리에 있어서도 계속 해결이 불가능한 악재로 남아서, TU 원본과 백업의 파일 관리에 있어서 어떨땐 존재하고 어떨땐 삭제되는 결과가 되었습니다.
NT 기반의 클로즈드 소스인 대쉬보드에서는 이런 상황에서 삭제되었지만 남아 있는 데이타에 심볼릭 링크나 정션이 상황에 따라 걸립니다.
아시다시피 정션은 파일에 해당되지 않고 폴더에만 해당되는 것인지라 폴더만 남아 있는 경우도 종종 생기고 폴더 때문에 파일이 삭제가 되지 않는 경우도 생기고.....프리스타일의 근본적인 문제는 이 문제라고 제 개인적으로 추측합니다 (뭐 저뿐만이 아니지만.....ㅋ)
결국 프리스타일은 TU 관리에 한해서만 말하자면 최적화에도 실패하고 불필요한 오버헤드만 붙었다라고 결론 지을수 있지요.
프리스타일의 이런저런 문제로 인해 프리스타일 개발팀들이 다시 이합집산해서 피닉스라는 팀을 만들고 오로라가 만들어졌습니다.
- 뭐 원래 인원들에 사람들만 추가된....^^
오로라에서 TU의 처리 방법은 개발자가 직접 밝힌 간단한 설명으로 대신합니다.
When Aurora boots up it scans all the possible valid TU locations on your connected devices. If it finds a TU, it adds it to the database and makes a backup copy in the Aurora\Data\TitleUpdates folder.
The next time Aurora boots, it does the scan again- it attempts to add it to the database- but it already exists, so it ignores it.
When you download a TU from within Aurora, it downloads directly to the backup cache and makes an entry in the data base using the selected device information you set prior to downloading the TU.
When launching a game, Aurora loops through all of the entries of scanned TUs in the database and finds where they should exist- and deletes them. Then it copies the "active" TU from the backup cache into the proper place. That's how a TU becomes activated.
- 공홈이나 어떤 곳에도 이딴 설명 따윈 없으니.....아무도 모르는건 당연합니다.....ㅋ
쉽게 말해 기존 TU가 360 지정 저장소에 존재할 때는 이전 그대로 이용하지만 새로 받을때는 360 TU 폴더들을 무시하고 전용으로 다이렉트 다운로드, 다이렉트 DB 구성 및 사용..........이게 제일 큰 차이점입니다.
-뭐 세세한 차이가 좀 있긴 하지만 다 알 필요도 없고 중요한 것도 아니고...
이로 인해 TU의 중복 문제는 해결 되었고 IO의 신뢰성이야 두말할 것도 없으니 냅두고 DB 최적화는 말할것도 없고...
여기서 문제는.......오로라의 TU 적용 방식을 보면 아시겠지만 공식 360의 지정 폴더들을 사용하지 않습니다.
즉 오로라는 오로라만을 위해 TU를 다운로드 합니다.
프리스타일에서 배운 경험으로 어차피 사람들은 이거다 싶으면 하나만 쓴다......이거저거 다 지원하지 말자 라는 가벼움의 철학이기에 이를 좋아하는 대부분의 사람들에게 환영 받았지만 프리스타일을 오래 써와서 익숙해진 사람들이나 얼마전 유니티 서버 TU 블럭 사건 이후로 오로라와 겸용을 해볼까......하는 사람들은 난관에 부딪히게 되죠.
프리스타일을 기존에 사용하고 그 내용물을 전부 삭제하지 않은 사람들 + 같이 한번 써볼까 하는 사람들 + 프리스타일 때문에 자신의 하드가 어떤 상태인지 모르는 사람들은 프리스타일에 맞춰서 포맷이 변경된 TU + 삭제했지만 남아 있거나 안남아 있거나 정션이나 심볼릭으로만 존재하거나....하는 TU들 + 기타 등등으로 인해 적용을 했는데 적용이 안되었다고 그러거나 표면적으로는 적용이 되었지만 실제 액티베이션이 안되거나......다양한 문제를 겪게 되죠.
물론 프리스타일과 오로라를 함께 사용하는 (TU를 공유하는...) 방법은 존재합니다.
그런데 그게 몰라도 될 정도로 수동 작업인데다가 x노가다입니다.
혹자는 게시판에서 이러이러하면 쓸 수 있다!......라고 하는 사람들도 있는데, 프리스타일 사용하면서 왜 그게 문제인지 몇년동안 몰랐던 사람들처럼 문제가 있음에도 당장 알지 못하거나 자신의 잘못 사용하는 탓으로 돌리거나 기타 등등으로 문제를 문제로 인식하지 못하기 때문입니다.
- 피닉스 팀도 RMS에서 피드백을 잘해주는 축에 속하는데 같이 사용하는 부분에 있어서는 알아서 해라~ 로 일관합니다....^^
장보는 남자님의 글에 오로라에서 TU 적용에 문제가 생기면 TU를 삭제하고 다시 다운로드 하면 대부분의 문제가 해결된다.라는 솔루션은 대부분의 경우에 정답입니다.
그 원인은 위에 열심히 적은 수많은 것들이 하나하나의 원인이 되지요. (쉽게 말해서 오로라에서 새로 받지 않고 기존의 존재했던 TU는 여러가지 이유로 정상이 아닌 TU로 존재할 가능성이 충분히 있다는 소리입니다....)
이것을 연역적으로 풀어 해석하면.......모든 360 TU를 싹 다 지우고 오로라를 먼저 인스톨해서 TU를 싹 정리한 후에, 그냥 그대로 쓰면 아무 문제가 없게 됩니다. 그게 피닉스 팀의 권장 FM입니다.
이런저런 문제가 있지만 프리스타일과 양립하고 싶으면 그 후에 프리스타일을 설치하고 TU를 수동 설치하는게 답입니다.
허나 그렇게 양립하면 후에 게임 타이틀 하나 추가할때마다 수동으로 체크해주고 TU만 놓고 보면 오로라용 하나, 프리스타일용 하나, NXE 용 하나.....하나의 타이틀에 TU를 세개나 가지고 있는 꼴이 되지요.....
어떤 방법이 좋고 나쁜지는 개개인의 선택이고, 뭐가 좋고 나쁘다는 말을 하고 싶지는 않습니다.
말 그대로 개인의 취향이니까요......
허나 원리를 알면 저마다 문제가 생길때 해결책이 보일터이니 그렇게 도움이 되시라고 쓸데없이 긴......설명이 너무 긴......글을 적어봅니다.
이해가 쉽게 되셨으면 하는 바램입니다...^^