각 단말기에는 해당 단말기를 식별하는 유일값인 UDID가 존재합니다. iOS 플랫폼의 경우 SDK 상에서 쉽게 이 UDID 값을 추출할 수 있었습니다. 이 UDID는 사용자의 직접적인 개인정보를 이용하지 않고 사용자의 패턴 분석에서부터 타겟광고 소스 등 여러 부분에서 이용하고 있었습니다만 현재 베타테스트가 진행 중인 iOS5에서는 이 UDID 의 이용은 제한될(deprecated) 예정입니다. 이에 따라 애플에서는 UDID보다는 UUID를 생성하여 이용하라고 권고하고 있습니다. UUID는 단말기의 고유값이 아닌 어플리케이션에서 생성한 유일값으로 생성할 때마다 변경되는 랜덤값입니다. 따라서 개발자분들은 이에 대한 대응을 미리 하시는 것이 좋을 것 같아서 정리해보았습니다. UDID는 단말기를 식별하기 위해 고유하게 할당된 40개의 숫자와 문자열입니다. 이런 고유값은 개인정보이다. 아니다 기기 식별값이므로 개인정보는 아니다라는 논란으로 잠시 인터넷이 뜨거웠던 적이 있습니다. (2011/05/10 서울경제 기사, http://economy.hankooki.com/lpage/it/201105/e20110510173640117700.htm) 이 UDID는 구글, 오픈페인트를 비롯한 여러 광고 및 트래픽 분석툴에 사용되고 있는 상황에서 애플이 드디어 칼질을 가하기 시작했습니다. iOS5 beta 6에서는 UDID를 가져올 때 사용하는 메소드를 없애겠다는 의지로 해당 메소드를 deprecated시키고 대신 Core 레벨에서 랜덤한 UUID를 생성하는 메소드를 이용하라는 권고를 내렸습니다. (Apple Sneaks A Big Change Into iOS 5: Phasing Out Developer Access To The UDID :http://techcrunch.com/2011/08/19/apple-ios-5-phasing-out-udid/). 실제로 iOS5 beta 6에서 [[UIDevice currentDevice] uniqueIdentifier]가 포함된 프로젝트를 빌드하면 아래와 같은 경고가 나타납니다. 애플에서는 UDID값이 아닌 UUID(Universally Unique Identifiers)를 이용하라는 권고를 내렸습니다. CFUUID Documentation을 참조하면 이 UUID는 128-bit 값으로 생성된 유일값이며 이는 시간과 공간값으로 생성된 유일값이므로 중복될 염려가 없다고 합니다. 유일값 생성 방법은 아래와 같으며, CFUUIDRef uuid = CFUUIDCreate(kCFAllocatorDefault); 생성되는 UUID는 아래와 같은 형태의 결과값을 가집니다. 이렇게 생성된 UUID를 NSUserDefaults 등을 이용하여 값을 유지시켜줌으로 UDID와 동일한 역할을 하도록 개발자들의 추가 구현이 필요하다라고 문서에는 나와있습니다. 어느 부분에서는 한 줄이면 가능한 유일값 추출을 이제는 개발자가 직접 신경을 써서 관리하라고하니 한숨이 나오는 건 사실입니다. 이렇게 생성된 관리를 위한 방법으로는 NSUserDefaults를 이용하여 앱 내부에서 관리하는 방법, 별도의 서버에 이 값을 저장하여 관리하는 방법, 또는 iOS5 이상의 iCloud를 이용하는 앱이라면 iCloud의 Key-Value Data Storage를 이용하는 방법을 생각해 볼 수 있습니다. 이도 문제가 된다면 Mac Address를 추출하고 이를 해쉬값을 이용(MD5)하는 방법도 최근 iOS 개발자분들이 관심을 가지고 있는 것 같습니다. (GitHub : http://github.com/gekitz/UIDevice-with-UniqueIdentifier-for-iOS-5). UDID는 Unique Device Identifier로 기기의 고유값입니다. 하지만 UUID는 앱 자체에서 생성되는 고유값으로 사용자가 사용하는 앱의 고유값으로 볼 수 있습니다. 즉, UUID를 사용하도록 권고하는 것은 단말기의 고유값을 사용하지 말고 앱마다 각자의 고유값을 이용하라는 풀이로 볼 수 있습니다. 이 두 유일값의 장단점을 간략히 살펴보면 아래 표와 같습니다. Deprecated 된 메소드는 아시다시피 현재 사용하지 못한다는 의미는 아니지만 앱스토어에 앱을 등록할 때 리젝 사유가 될 수 있습니다. 위에서 설명드린대로 경고가 항상 나타난다면 당장 대안을 찾아야하는 상황이지만 프로젝트의 Deployment Target을 5.0 이하. 즉, 4.x나 3.x로 한다면 메소드를 사용이 가능합니다. 물론 개발 상에서 사용가능하다는 것이며 정책상으로 어떻게 될지는 모르는 상황입니다. UDID를 활용하는 서비스나 앱이 많을 것으로 예상됩니다. iOS5가 정식으로 릴리즈되더라도 당장에 사용못하게 하지는 않을 것으로 예상되지만 미리 준비를 해두시는 것이 좋을 것 같습니다. 아래는 Deployment Target을 4.0으로 설정하는 화면과 설정 이후 빌드한 결과 uniqueIdentifier에 경고가 나타나지 않는 화면입니다. UUID가 아닌 유일값에 대해서는 애플에서는 아직 언급하고 있지 않습니다만 Ethernet의 MAC Address, Bundle identifier 등 여러 대안을 생각해볼 수 있습니다. MAC Address의 경우 Cocoa API에는 추출 메소드가 없어 직접 Core에 접근하여 추출을 해야하며, 해당값을 그대로 사용하는 것이 아닌 MD5나 SHA-1 등의 해쉬를 이용하여 보안이슈가 발생되지 않게 해야합니다. 이로 인해 작업 공수가 더 추가된다는 것, 또한 이후에 애플에서 해당값의 사용을 금지할 수도 있다는 잠재적인 위험요소가 있으므로 되도록이면 애플에서 권장하는 UUID를 이용하는 방법으로 문제를 해결하는 것을 추천해드립니다. - UDID를 얻어오는 메소드는 iOS5부터 사용할 수 없는, 삭제 예정인 메소드입니다.
NSString *string = (NSString *)CFUUIDCreateString(kCFAllocatorDefault, uuid);
- 프로젝트의 Deploy Target을 5.0이 아닌 그 이하 버전으로 설정하는 경우에는 UDID 추출 메소드 사용이 가능합니다.
- 정책상 결정된 부분은 아니지만 애플의 권고는 UUID를 이용하는 것입니다.
- 또한, iOS5가 정식으로 발표된 이후에는 반드시 고려되어야하는 이슈이므로, 미리 이에 대한 대비가 마련되어야 합니다.
- UUID도 단말기의 고유값이 아니므로 서비스의 특성에 따라서는 UDID가 아닌 단말기의 고유값으로 간주할 수 있는 MAC Address를 이용하는 방법 등을 고려할 수 있습니다.
- UDID를 사용하지 못하는 것과 동일하게 MAC Address도 사용이 불가할 수도 있다는 점은 고려하여 대책 마련을 하시는 것이 좋습니다.
- MAC Address를 해쉬처리한 문자열이 단말기의 고유값으로 보는 방안은 애플의 정책에 위배되지 않는다는 가정하에서 현재 단말기의 유일값으로 지정할 수 있는 최상의 방안으로 고려됩니다. (iOS5 정식출시가 되어봐야 알 것 같습니다.)
'영삼이의 IT정보' 카테고리의 다른 글
| 기본적인 문자열, 날짜, 배열 등 테스트 (0) | 2012.06.01 |
|---|---|
| NSUserDefaults 유용하고 빠른 파일저장 (0) | 2012.05.31 |
| ASIHttpRequest를 ARC와 함께 쓰기 (XCode 4.2) (0) | 2012.05.30 |
| iPhone NSURLRequest 사용법 (0) | 2012.05.29 |
| PCRE 정규표현식 기본기 (0) | 2012.05.29 |
