달력

10

« 2017/10 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
  •  
2012.08.20 01:41

Strong, Weak, Assign 살펴보기 개발기술/iOS2012.08.20 01:41

ARC가 나오면서 새로운 Property로 strong, weak이 추가되었다. 알다시피 strong은 강한 참조, weak은 약한 참조라는 의미이다. iOS 4.x에서 썼던 retain, assign( unsafe_unretained)의 대체 개념이라고 알고 있는데 어떤 개념으로 쓰이는 것일까? 그리고 weak과 assign은 어떻게 다른 것일까? 이런 궁금증이 발동하여 테스트 코드를 작성해보았다. 아래 코드를 보자.


@interface SMViewController ()

@property (nonatomic, strong) NSObject *strongObj;
@property (nonatomic, weak) NSObject *weakObj;
@property (nonatomic, assign) NSObject *assignObj;

@end

@implementation SMViewController

- (void)printAddress {
    NSLog(@"strong addr : 0x%x", (unsigned int)self.strongObj);
    NSLog(@"weak addr   : 0x%x", (unsigned int)self.weakObj);
    NSLog(@"assign addr : 0x%x", (unsigned int)self.assignObj);
}

- (void)viewDidLoad
{
    [super viewDidLoad];

    NSLog(@"> init values");
    self.strongObj = [[NSObject alloc] init];
    self.weakObj = self.strongObj;
    self.assignObj = self.strongObj;
    [self printAddress];
    
    NSLog(@"> set strongObj to nil");
    self.strongObj = nil;
    [self printAddress];
}

- (void)viewDidAppear:(BOOL)animated {
    [super viewDidAppear:animated];
    NSLog(@"> move another stack");
    NSLog(@"> will die at assignObj");
    [self printAddress];
}


코드의 내용은 strong, weak, assign 값을 선언하고 strongObj에 Object을 할당한 다음 weakObj와 assignObj에 strongObj을 세팅하고 생명주기가 어떻게 되나 살펴보는 내용이다.


결과는 이러했다.


> init values
strong addr : 0x6a20320
weak addr   : 0x6a20320
assign addr : 0x6a20320
> set strongObj to nil
strong addr : 0x0
weak addr   : 0x6a20320
assign addr : 0x6a20320
> move another stack
> will die at assignObj
strong addr : 0x0
weak addr   : 0x0
== BAD ACCESS ==


처음 시작할 때는 strongObj의 강한 참조값이 살아 있어 weakObj, assignObj의 주소값이 모두 찍힌다. strongObj값을 날려버리고 난 후에는 strongObj의 주소는 0x0이 되고 다른 Obj들은 그대로이다. 


그런데 결과의 12라인을 보면 다른 스택으로 넘어가는 순간 weakObj의 주소값이 0x0으로 바뀐 걸 알수가 있다. 코드로 아무런 조치도 안 했는데 자동으로 값이 바뀐 것이다. weakObj의 약한 참조가 strongObj의 오브젝트가 메모리에서 사라지면서 풀려버린 것이다!! (ARC를 쓰면 오브젝트에 대한 BAD ACCESS의 위험이 대폭 줄어들 것이라는 예상을 할 수가 있다.)


그리고 그 다음 라인에서 assignObj의 주소값을 찍으려는 순간 앱은 BAD ACCESS 내뱉고 죽어버린다. assignObj가 가지고 있는 address의 오브젝트에 대한 잘못된 접근을 했다는 말인데 메모리에서 오브젝트가 사라지더라도 값은 그대로 남아있어 문제를 일으켰다는 것을 알 수 있다.


이 간단한 테스트로 weak과 assign의 차이를 알 수 있고, strong, weak의 쓰임, assign의 쓰임에 대해서도 얼핏 짐작할 수가 있다.


정리하면, strong, weak은 오브젝트을 참조할 때 쓰고, assign은 int, float, double 등과 같은 primitive type에 대해값을 할당할 때 쓰면 되겠다.


TestWeakAssign.zip


저작자 표시 변경 금지
신고

ARC, non-ARC 소스가 같이 있는 프로젝트에서 메모리 해제가 잘 될까?


궁금해서 데이터 오브젝트를 하나 만들어 해제하는 간단한 테스트 프로젝트를 만들어 보았다.



TestARC.zip



프로젝트에 대해서 대충 설명하면, ARC을 사용하는 프로젝트를 만들고 ARC, non-ARC 소스 두개를 만든다.


@interface SMData : NSObject

@property (nonatomic, strong) NSData *data;

@end


@implementation SMData

- (id)init {
    self = [super init];
    if (self) {
        self.data = [NSMutableData dataWithCapacity:1024*1024];
    }
    return self;
}

@end

<ARC소스는 strong을 써서 1메가를 할당하는 오브젝트>


@interface SMData_noARC : NSObject

@property (nonatomic, retain) NSData *data;

@end

@implementation SMData_noARC

@synthesize data = _data;

- (id)init {
    self = [super init];
    if (self) {
        self.data = [NSMutableData dataWithCapacity:2*1024*1024];
    }
    return self;
}

- (void)dealloc {
  [_data release];
  [super dealloc];
}

@end

<non-ARC소스는 기존 방식대로 retain을 쓰고 2메가를 할당하는 오브젝트>



그리고 컴파일 에러가 나지 않게 non-ARC소스에는 -fno-objc-arc 플래그를 지정한다.



이제 Alloc, Release 하는 버튼을 만들어 데이터 오브젝트를 생성하고 해제할 수 있도록 만든다.


- (IBAction)onAlloc:(id)sender {
    self.data = [[SMData alloc] init];
}

- (IBAction)onRelease:(id)sender {
    self.data = nil;
}

- (IBAction)onAllocNoARC:(id)sender {
    self.data_noARC = [[SMData_noARC alloc] init];
}

- (IBAction)onReleaseNoARC:(id)sender {
    self.data_noARC = nil;
}


<실행화면>



이제 메모리를 생성하고 해제하는 동작이 잘 되는지 Instrument 을 통해서 확인한다.


Xcode 메뉴의 Open Developer Tool에서 Instrument을 실행한다.




Allocations을 선택한다.



Choose Target > Attach to Process 에서 TestARC을 선택한후 Record을 누르면 Allocations 모니터링을 할 수가 있다.




버튼을 누를때마다 그래프가 오르락 내리락 하는 걸 통해 정상적으로 메모리가 할당되고 삭제되는걸 확인할 수가 있고, 통계 수치를 통해서도 알 수가 있다. (Malloc 1.25MB는 ARC로 만든 데이터, Malloc 2.50MB는 non-ARC로 만든 데이터)





이로써 ARC, non-ARC 둘다 섞인 소스도 메모리 관리가 정상적으로 된다는 것을 알게 되었네요...

의심이 많다보니 오늘은 뻘짓을 좀 해봤습니다. ㅋㅋ



TestARC.zip



저작자 표시 변경 금지
신고
"나는꼼수다 봉주4회"에서 소개된 클루넷의 압수수색 소식을 들었다. 

검찰, ‘나꼼수’ 서버관리업체 클루넷 압수수색  <한겨레뉴스>


수사를 착수한 곳이 나꼼수 운영하는 서버관리업체일 줄은 몰랐다는 검찰 관계자의 이야기. ㅋㅋㅋ

오늘 이야기할 내용은 이게 아니고 클루넷 소식으로부터 개발자의 호기심이 다시 발동하여 Podcast 서비스 관련한 이야기를 해볼까 한다.

우선 과거 기사를  보자. 2011년 11월 6일.. 지금으로부터 3달 전의 기사다.

‘나꼼수’ 지속 가능할까 ‘무광고 원칙’ 고수 재정적 문제 심각 <한겨레뉴스>
 ‘나꼼수’를 연출하는 김용민씨는 6일 “해당 업체에서 일부 깎아준 금액인데도 지난달 2800만원의 서버 비용이 청구됐다”며 “재정적 문제가 이미 심각한 상황”이라고 밝혔다.
이 기사를 보고 '와 무슨 팟캐스트 방송하는데 비용이 저렇게 들어?' 라는 생각이 들었다. 나꼼수 듣는 중에도 트래픽 발생량이 어마어마하다고 강조를 했는데.. 과연 서비스 요금정책이 어떻길래 저런 비용을 댈까? 하는 생각이 들어 클루넷으로 찾아갔다. 홈페이지 둘러봤는데 요금정책 메뉴는 없었고, 이용약관 마지막 페이지에 표시된 걸 찾았다.


우와 쩐다~! 일반인인 나로서는 엄두도 못할 가격표! 역시 국내업체는 너무 비싸! 실패!

국내업체는 트래픽 초과에 따른 비용을 추가 지불하는 시스템이어서 나꼼수와 같은 인기서비스를 할경우 추가비용이 발생한다. 하지만, 외국서비스를 찾아보면 트래픽이 무제한이면서 무료이거나 저렴하게 CDN 서비스를 하는 곳을 찾을 수 있다.

사진,동영상의 경우 대표적으로 Picasa(2048x2048이하 사진, 15분 이하 동영상 무료, 단 1천만개 제한) 나 Flickr ($24.95/년 - 2만8천원/년, 무제한 용량, 무제한 트래픽)를 꼽을 수 있다.

> 웃찾소의 미디어 호스팅 서비스 조사  참고


미디어 서비스를 하려면 파일이 올라간 URL만 있으면 되기 때문에 파일이 어디에 올라가 있는지는 상관없다. 다만 미디어를 올린 관리업체의 서비스가 얼마나 안정적이고 저렴하냐가 문제다. 아무튼 이런 생각으로 오늘 찾아본 곳은 Podcast을 위한 음원 서비스를 하는 외국서비스를 찾아보았고 적당한 곳을 찾았다.

전세계적으로 1천만 유저를 확보한 SoundCloud (http://soundcloud.com/) 라는 소셜 음원 서비스를 소개하고자 한다.
( 1천만 유저에 대한 청취자는 훨씬 더 많다. 모바일앱은 5백만 다운로드, Open API로 파생된 앱 수도 1만개이고 새로운 앱이 계속 생겨나고 있음, http://mashable.com/2012/01/23/soundcloud-10-million-users/ )



SoundCloud를 통해서 자신의 음원을 올리고 사람들과 공유해서 들을 수 있는 서비스다.
1천만 유저를 상대로 서비스하는 업체이니 서비스 안정성은 보장할 것이고, 요금정책이 관건인데.. 한번 살펴보자.
(아~ 영어울렁증.. ㅠㅠ)

  • Free : 용량제한 120분, 트랙당 100 다운로드
  • Lite : 용량제한 240분, 트랙당 1000 다운로드, 29유로/년 (약 4만3천원/년)
  • Solo : 용량제한 12시간, 무제한 다운로드, 79유로/년 (약 11만8천원/년)
  • Pro : 용량제한 36시간, 무제한 다운로드, 250유로/년 (약 37만3천원/년)
  • Pro Plus: 무제한 용량, 무제한 다운로드, 500유로/년 (약 74만7천원/년)
용량제한에 걸리면 이전에 올린 파일을 삭제해야 새로운 걸 올릴 수 있다.
(트래픽제한이나 추가요금에 대한 정책은 찾을 수 없었는데 혹시나 그런 제한이 있으면 알려주시면 감사.)

아무튼 요금표를 보면 팟캐스트와 같은 음원서비스를 위한 서비스로 SoundCloud을 이용하면 저렴한 가격에 서비스를 할 수 있겠다. 나꼼수와 같은 인기서비스라면 더더욱 추천할 만한 요금이다. 월 2천만원이 가당키나 한 것인가!!!
비싸게 쳐도 한달 59유로 (8만8천원/월) 밖에 안하는데!!!

그리고 하나 더 SoundCloud는 Podcast 서비스를 위한 편의기능도 제공해준다.


단순히 체크만 하고 RSS만 올리면 끝나는 듯 하다. 자세한 설명은 여기에 친절하게 나와있다. 
"How to Podcast with SoundCloud"


나꼼수도 운영비에 허덕이지 말고 저렴한 해외 업체를 이용해보는 것이 어떨까 생각...

검찰이 수색하기도 쉽지 않을테고.. ㅋㅋ
나꼼수가.. 국내 업체를 이용하는 다른 이유라도 있다면 어쩔 수 없겠지만... !

끝!


저작자 표시 변경 금지
신고

'개발기술 > 분석' 카테고리의 다른 글

나꼼수, 클루넷, Podcast & SoundCloud  (2) 2012.02.04
미디어 호스팅 서비스 조사  (1) 2011.12.20
Posted by 웃찾소

iOS5의 ARC(Automatic Reference Counting)은 Objective-C 객체의 메모리 관리를 자동으로 관리하는 "Compiler" 속성이다. 이 속성을 사용하면 예전에 쓰던 retain, release, autorelease, dealloc 코드는 사용할 수 없게되며 이들이 하던 역할을 컴파일 시점에 알아서 처리해준다. ARC가 허용하지 않는 코드를 사용하면 아래와 같은 에러를 뿜어낸다.


그럼, ARC을 사용하게 되면 기존 오픈소스를 사용하는데 문제가 되지 않을까 걱정을 할 수 있는데 다음과 같이 해결하면 된다.
  • 이미 컴파일된 오픈소스 라이브러리 사용
  • ARC옵션을 끈 다른 라이브러리 프로젝트를 생성해서 사용
  • 오픈소스 파일별로 ARC옵션을 끄고 사용
ARC옵션을 끄는 방법은 프로젝트 생성할 때 옵션을 끄거나 


프로젝트 Build Settings에서 Objective-C Automatic Reference Counting을 NO로 바꾸거나


프로젝트 Build Phases에서 옵션을 끌 파일들을 선택한 후 엔터를 치고 "-fno-objc-arc" 옵션을 적용해주면 된다.


그런데, ARC을 사용하는데 있어서 제약사항이 전혀 없는건 아니다.
ARC is supported in Xcode 4.2 for Mac OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in Mac OS X v10.6 and iOS 4.
Xcode 4.2 for Snow Leopard does support ARC for iOS though, and Xcode 4.2 for Lion supports both Mac OS X and iOS. This means you need a Lion system to build an ARC application that runs on Snow Leopard.

Xcode 4.2 for Snow Leopard는 지원 안되고, OSX 10.6과 iOS4에서는 Weak 참조를 사용할 수가 없다. 결국 ARC을 제대로 사용하려면 Lion 시스템을 사용하고 iOS5 이상 되어야 Weak 참조를 포함해서 제대로 된 ARC을 사용할 수 있다.


사용해보기 이전에 제약사항에 대해서 먼저 알아본 것은 실컷 공부했는데 나중에 알고보니 어떤 제약이 있어서 쓸 수 없는 상황을 미연에 막기 위해서이다.

그럼 ARC란 무엇인가? retain/release하던 걸 빼고 app_code만 작성하게 해주는 컴파일 속성이다. 사람이 짜는 코드이다 보니 retain/release 쌍이 안 맞아 다양한 버그를 만들곤 하는데 이 걱정을 안하게 해주는 고마운 놈이다.


과거엔 이렇게 했다면, 
MyObj *o = [[MyObj alloc] init];
...
[o release];

ARC에서는 [o release]; 하지 않는다. release를 안 해도 컴파일러시에 자동으로 추가된다고 알면 된다.

@interface Person : NSObject
@property (nonatomic, strong) NSString *firstName;
@property (nonatomic, strong) NSString *lastName;
@property (nonatomic, strong) NSNumber *yearOfBirth;
@property (nonatomic, strong) Person *spouse;
@end
@implementation Person
@synthesize firstName, lastName, yearOfBirth, spouse;
@end
- (void)contrived {
    Person *aPerson = [[Person alloc] init];
    [aPerson setFirstName:@"William"];
    [aPerson setLastName:@"Dudney"];
    [aPerson:setYearOfBirth:[[NSNumber alloc] initWithInteger:2011]];
    NSLog(@"aPerson: %@", aPerson);
}
예전의 경험대로라면 aPerson 과 NSNumber 할당한 놈에 대해 메모리가 새는 걸 막을려는 충동을 느낄테지만 ARC에서는 위 코드가 정상이다. ARC에서는 release 짝 맞추려는 노력을 하지 않아도 된다는 것이다!

그런데, 혹자는 ARC를 사용할 경우 메모리해제가 정상적으로 되지 않는다고도 한다. aPerson = nil; 처럼 nil을 넣어줬더니 정상적으로 해제가 되더라는 사람도 있고, ... 아직 익숙하지 않아서 그렇게 느끼는 건 아닐지....

아무튼 ARC를 사용할 때 얻는 장점이 많기 때문에 앞으로 시작하는 프로젝트에 대해서는 ARC만 사용해서 쓰는 걸 추천한다. 더 자세한 내용은 아래 참고자료를 참고하고, ARC 기본설명은 여기에서 마무리한다.

* 참고자료
Transitioning to ARC Release Notes


저작자 표시 변경 금지
신고
앱개발 서버를 위해 이미지나 동영상, 파일을 저장할 곳을 조사해보았다. 클라우드 서버에 올려서 서버 프로그램이랑 함께 관리하면 편하긴 하지만 트래픽 증가에 따른 비용문제 때문에 다른 방법을 찾아보는 것이다. (국내 클라우드 서버는 왜 그리 비싼지.. 트래픽 제한도 있고... -_-)

찾으려는 미디어 호스팅 서비스의 요건은 다음과 같다.
  • 무료계정의 제한은 어떤게 있나?
  • 유료계정 전환시 저렴한가?
  • 속도는 빠르고 안정적인가? 
  • 저장가능한 미디어타입은?
  • 파일관리가 가능한가?
  • 파일업로드 방식은?
위 요건에 대해서 찾아본 곳은 4군데, ImageShack, Flickr, Picasa, 그리고 생뚱맞지만 Tistory 도 가능은 하더라. 그러나 원활한 블로그 서비스를 위해서 Tistory를 활용하는 건 좋지 않다. 편법으로 사용한다면 You are abuser !

아래는 4개 서비스에 대한 비교표이다.

   ImageShack  Flickr  Picasa  Tistory
무료계정  무제한 용량
 사진당 5MB
 파일 제한 200개
 업로드 제한 월 300메가
 사진당 15MB
 동영상 150MB
 사진당 20MB
 동영상 1GB
 총저장용량 1GB
 (단, 2048x2048 이하 및 15분 이하 동영상 제외) 
 앨범10,000개
 앨범당사진 1,000개
 10,000,000 (1천만개)
 무제한 용량
유료계정  무제한 대역폭
 사진당 10MB
 무제한 용량, 대역폭
 사진당 20MB 
 동영상당 500MB 
 용량 추가 구매   - 
가격  $68 / 년  $24.95 / 년  20GB - $5.00 / 년
 80GB - $20.00 / 년 ...
 1TB - $256.00 / 년 
 -
속도  느림 (무료)
 유료는 모르겠음 
 빠름
 업로드 느림 
 빠름
 업로드 느림 
 빠름
지원미디어  이미지, 동영상  이미지, 동영상  이미지, 동영상  이미지, 동영상, 파일
파일관리  계정 등록시 가능  가능  가능  글작성시 가능
 API 업로드시 불가능 
업로드 방식  API Key
 Token 없음
 POST & Multipart
 OAuth2, API Signature
 Token 획득 절차 필요
 POST & Multipart
OAuth2, Token Refresh
Token 획득 절차 필요
Token 갱신 필요 (1시간)
POST 
 OAuth2
 Token 획득 절차 필요
 POST & Multipart 

* 참고 사이트
- ImageShack : http://imageshack.us/content.php?page=faq
- Flickr : http://www.flickr.com/help/limits/#28 
- Picasa : http://support.google.com/picasa/bin/answer.py?hl=ko&answer=43879&topic=1689793&ctx=topic
- Tistory : http://notice.tistory.com/notice/1111

원래 4개 다 조사하려고 한게 아니라 이 중 하나를 선택해서 상태가 괜찮으면 그대로 쓸려고 했었다. 그런데, 하나씩 조사하다보면 요건 중 하나가 불충족해서 다른걸 찾다가 결국은 다 보게 된 것이다. -_-;

상황이 어떻게 된건지 순서대로 설명하면..

ImageShack

해외에서 유명한 이미지 호스팅 업체라 들은 ImageShack 부터 조사를 시작했는데, API Key 방식에 별다른 인증절차가 없이 바로 사용할 수가 있어서 업로드 스크립트를 짜는데는 별 어려움이 없었다. 다소 느린 감이 있었지만 무료인데다 용량제한이 없었기에 참을만 했다. 서비스 가입을 하면 자신이 올린 이미지를 관리도 할 수도 있다. (단, 이미지 올릴때 자신의 Registration Code을 함께 파라메터로 넣어줘야 한다.)

300여개의 이미지를 스크립트로 일괄 업로드한 뒤 실사용 테스트를 했는데 ... 이미지 내려오는 속도가 이전보다 2배~3배 정도 느려진 것이다. 대역폭 문제인지.. 유료가입시 대역폭이 무제한이라는 문구가 있었다.. 유료서비스 사용계획은 아직 없어서 다른 서비스를 찾아보기로 했다.

Tistory

ImageShack랑 씨름하던 와중에 Tistory로부터의 초대장이 도착했다. 와~ 블로그 시작해야지~ 블로그 개설하고 서비스 이용안내가 먼저 눈에 들어왔다.
무한한 용량과 강력한 멀티미디어를 만나보세요!
이미지, 동영상, 오디오, 파일까지! 다양한 멀티미디어들을 블로그에서 이용할 수 있습니다. 다양한 멀티미디어들을 용량 제한없는 티스토리에서 더욱 멋지고 풍성하게 만들어보세요!
'와 무제한이다. 파일까지 올릴 수 있구나' 라 생각하며 이것저것 살펴보던 중 Tistory Open API가 눈에 들어왔다. API중 또 눈에 들어온 것은 파일업로드 API였다. '뭐, 무제한 용량에 파일업로드 API까지 제공해?' 라고 생각이 든 순간 바로 사용테스트를 해보았다. OAuth2 인증인데 친절한 가이드 보고 인증토큰 받아놓고 ImageShack때 작성한 스크립트를 조금 수정해서 파일업로드 API를 이용해서 이미지 1개를 우선 업로드해보았다. 빠른 속도로 올라갔고, 결과값으로 아래와 같은게 내려왔다.
<?xml version="1.0" encoding="utf-8"?>
<tistory>
  <status>200</status>
  <url>http://cfile23.uf.tistory.com/image/%#@%$%@%@%@%@</url>
</tistory>
위 이미지 URL을 이용해서 응답속도 테스트를 했는데 굉장히 빠른 속도로 이미지가 내려왔다. 그다음 올라간 이미지가 계정에서 관리가 가능한지 찾아보는데 ... 아무리 찾아도 없다. 올릴 땐 마음대로지만 지우는 건 마음대로 할수 없단다.. 웹사이트에서 글작성할때도 파일관리가 안 될까 싶어 첨부파일 올려봤는데 관리가 된다. API로 올렸을때만 안되는 것이다.

아쉬워 하던 찰나 Tistory의 무제한 용량 서비스를 편법으로 이용하는 사람이 많을 것 같다는 생각에 구글링을 좀 해봤다. 역시나 다른 서비스를 이용하면서 Tistory를 미디어 호스팅용으로 이용하는 사람이 꽤나 있었다. 이런 상황이면 트래픽 발생 감당이 어려워 서비스 유지하기가 힘들다. "Tistory 서버 장애"를 검색해보면 최근 몇개월 전에도 서버가 불안하다는 기사가 보인다. 그래도 용케 서비스를 잘하고 있는 걸 보면 대단하다는 생각도 든다.

그렇지만... Tistory에 방금 둥지를 튼 나까지 여기에 동조하면 안된다는 생각에 아쉽지만 발걸음을 돌렸다. 원래 Tistory를 살펴볼 계획은 없었는데 우연하게 OpenAPI를 보고서 둘러본거..

Flickr

다음으로 찾아본 것은 Flickr와 Picasa 인데 '둘 중 무엇이 좋을까?' '이미 조사해본 사람이 있겠지?'라고 생각해서 Flickr vs Picasa 로 검색해보았다. 역시 꽤나 많은 자료가 나온다. 무료로 쓰기에 Flickr가 더 좋다. 구글이 서비스하는 Picasa도 발전가능성 많다. 등등.. 평가가 비슷비슷했다. 그 중 눈에 들어온 것은 Flickr는 무제한 용량이지만 한달에 300MB제한이 있고, Picasa는 1GB 용량제한에 용량은 추가구매해야 한다고 누군가가 이렇게 정리해 놓았다. 별 의심없이 이 정보를 믿고... 한달에 300MB씩 업로드 안할테니 무제한인 Flickr로 해야겠구나 하고 다음 단계로 들어갔다.

API 문서를 읽어보는데 인증토큰 가져오는 부분에서 OAuth을 쓰는것 같긴 한데 API Signature를 해야 한단다. 예전에 DRM(컨텐츠 보안)을 구현했던 경험이 있어서 서명 암호화 사용에 큰 거리낌은 없었다. Flickr는 보안을 강화하기 위해서 매 API 호출마다 API에 대한 서명을 붙여서 보내도록 되어 있다. Tistory에서 했던 방식으로는 인증토큰 획득은 어렵고 인증토큰 받는 부분을 코드로 구현을 해야 했다. 암호화 알고리즘을 손으로 계산할 수는 없으니.. 

삽질 끝에 인증토큰 받아오는 데까지 꽤 긴 시간을 투자했고 결국은 받아오는데 성공했다. 이전에 짰던 스크립트도 수정하고 서버에 이미지를 올리는 데까지도 성공했다. 업로드 속도는 약간 느린 느낌이었지만 실사용 테스트를 해보니 Tistory보다는 느리지만 비교적 빠른 편이었다. 올라간 사진은 계정에서 관리할 수 있었고, 스크립트를 돌려 300개의 이미지를 업로드했다. 그런데...


'으악' .. 이미지 업로드는 300MB 제한으로 마음대로 올릴 수 있지만 이미지 목록 요청이나 관리는 200개 밖에 안되는 것이었다. 결국 Flickr 도움말 뒤져서 무료 계정 한계 확인하고 허탈해 했지만 유료 이용료가 눈에 딱 들어왔다. 1년에 24.95달러(약 3만원) 밖에 안한다. 무제한 저장 공간, 무제한 대역폭에 서비스 품질도 좋은데 1년에 3만원이면 상당히 괜찮다. ImageShack보다 싸다!

후보 1순위로 점찍어 놓고.. 기왕 이렇게 된 김에 Picasa까지 알아보기로 했다.

Google Picasa

드디어 구글형님이 운영하는 Picasa ! 총저장용량이 1GB라고 검색에서 봤지만 이전같은 실수하지 않으려고 서비스 도움말을 직접 찾아봤다. 그런데, 어디에 꽁꽁 숨겨놨는지 찾기가 힘들다. 문서가 너무 많고 내가 찾으려는 정보가 쉽게 노출이 되지 않아서 한참 헤맨 끝에 찾았다.

Picasa 웹앨범에 더 많은 사진 및 동영상을 업로드할 때 다음과 같은 계정 제한을 염두에 두시기 바랍니다.

  • 최대 사진 크기: 각 이미지의 크기는 20메가바이트를 초과할 수 없으며 50메가픽셀 이하로 제한됩니다.
  • 최대 동영상 크기: 업로드된 각 동영상의 크기는 1GB 이하여야 합니다.
  • 최대 웹앨범 수: 10,000개
  • 웹앨범당 최대 사진 및 동영상 수: 1,000개
  • 총 저장용량: Picasa 웹앨범은 사진 및 동영상을 저장할 수 있도록 1GB의 용량을 제공합니다. 일정 크기 이하의 파일은 저장용량 한도에 반영되지 않습니다.
계정 업로드 제한이 위와 같이 나와 있는데 총 파일 개수 제한은 1천만개로 제한이 있었다. 그리고 마지막 항목에 흥미롭게도 '저장용량 한도에 반영되지 않습니다.' 에 밑줄이 그어져 있다. 링크 타고 들어가보면..
2048x2048픽셀 이하의 사진 및 15분 길이 이하의 동영상은 무료 저장용량에 반영되지 않습니다.
라고 되어 있다. 고해상도, 고용량 파일에 대해서만 1GB 용량 제한을 한다는 것이다. 일반크기의 파일에 대해서는 사실상 무제한 용량이라고 보면 되겠다. 역시 관대한 구글~!  1천만개 제한이 있어서 서비스용도로 사용하기엔 힘들고 개인용도로 쓰기엔 부족함이 없다.

다음 단계로 이미지 업로드를 위해 API문서를 찾아다녔다. 구글 문서들은 어떻게 된게 어디부터 봐야할지를 모르겠다. 시작이 어디에요~? 정말 많이 헤매고 다녔다. 나에게 안 맞는 문서 정리 방식 @.@
한참 헤맨 끝에 발견한 키워드가 Google API Console, OAuth2, GData 였다. Google API Console에서 Client ID 발급받고 OAuth2로 인증하고 GData API를 이용해서 서비스를 이용하는 방식이다. 이런 문서들이 서비스별로 따로 있었다. 

구글 OAuth2 인증도 Flickr의 API Signature처럼 독자적인 보안 체계를 가지고 있다. Refresh Token 방식인데 발급된 인증토큰의 생명주기가 무한한게 아니고 3600초 .. 1시간인거 같다. (1시간 맞을듯..)  1시간 마다 Token을 Refresh 해야 한다는 말이다. 보안유지는 강력하겠지만 개발자에게는 괴로운 일이다. Token Expire 될때마다 갱신해야 하니깐.. -_-; 

아래는 Token을 요청했을 때 내려오는 값이다.
{
  "access_token" : "ya29.AHES6ZSj3Gwgc4US5gBtINy_XXXXXXXXXXXXX",
  "token_type" : "Bearer",
  "expires_in" : 3600,
  "refresh_token" : "1/nGUBDSD-7ODA-t7xa4syzmoXXXXXXXXXXXX"
}
문서 찾고 절차 확인하느라 대부분의 시간을 허비하고 아무튼 인증토큰을 얻어냈다. 이제 API를 이용해 업로드를 구현하려는데..
https://picasaweb.google.com/data/feed/api/user/userID/albumid/albumID

이렇게 설명되어 있다. userID, albumID는 어디서 찾아와야 하는지 설명이 안 되어 있다. 관대한 구글이지만 문서는 대부분 알듯말듯 불친절하게 설명되어 있다. 이거 말고도 바로 설명 안 된 부분이 많은데 일일이 다 찾아다녀야 한다.

우여곡절 끝에 업로드에 성공했고, 300개의 이미지를 업로드한 뒤 응답테스트를 했다. Flickr보다 빠른 속도를 보였고, 개인용도로 쓰기엔 충분했다.

결론 (개발자 관점)

ImageShack는 무료로 쓰기엔 너무 느리고 유료로 쓰기엔 Flickr보다 비싸다. Flickr는 유료로 쓰면 좋은 장점이 많고 Picasa 는 무료로 쓰기에 정말 좋다.

그리고 위에서 언급은 안 됐지만 Flickr는 이미지 업로드로 돌려받는 결과값에서 이미지 URL을 바로 알 수 없는 단점이 있다. Photo ID로 조회를 한번 해야지만 URL을 알아낼 수가 있다. 반면, Picasa는 업로드후 돌려받는 결과값에서 이미지 URL을 추출해낼 수가 있다.

제한 없는 서비스 용도로 쓸거면 저렴한 Flickr 추천!
유한개의 사진서비스를 하려면 무료인 Picasa 추천!

신고

'개발기술 > 분석' 카테고리의 다른 글

나꼼수, 클루넷, Podcast & SoundCloud  (2) 2012.02.04
미디어 호스팅 서비스 조사  (1) 2011.12.20