iOS5에서는 Twitter가 iOS 내부에 framework로 자리잡았고, iOS6에서는 Facebook이 자리를 잡았다.
이 서비스들의 계정을 담당하는 ACAccount framework가 확장이 가능한 형태였고 다른 서비스들이 여기에 자리잡지 않을까란 생각을 했었는데 역시나였다.
한국에서는 사용빈도가 거의 없는 중국 SNS인 웨이보도 이번 iOS6에 통합되었다.
앞으로 또 어떤 서비스가 ACAccountType으로 자리잡을지…
이 부분에서 궁금점이 하나 생긴다.
기존의 web-based 서비스에 Twitter와 Facebook의 연동은 일반적으로 서버에서 이루어졌었다.
따라서 클라이언트에서는 연동 페이지를 서버측에서 받아서 보여주는 행위만 하였고, 더불어 공유 시 공유를 할 것인가 말 것인가를 서버측에 전달했었다.
하지만 여기서의 단점은 서버측 네트워크 비용이다. 예상 외의 네트워크 비용이 들어간다는 것이다.
그리고 공유 시점이다. 서버 DB에 데이터가 입력이 성공했을 경우 서버측에서는 다시 이를 공유하게 되는데 순차적으로 처리되어야 하기 때문에 사용자는 이 처리가 끝날 때까지 기다려야 했다.
문제는 공유 시점에서 오류가 났을 경우에 클라이언트에서는 오류 메시지를 보내게 되고 사용자는 retry를 했을 때 서버에서는 이를 처리하기 위한 로직이 필요한 상황이 된다.
중복 자료라고 등록을 안하거나 공유만 따로 수행하거나 기타 등등…
만약 이를 클라이언트에서 한다면?
일단 네트워크 비용은 줄어들 것이다. 서버에는 현재 사용자가 생성한 데이터만 입력이 될 것이고,
이를 Twitter나 Facebook에 공유하는 것은 클라이언트 기준에서 이루어져 서버 네트워크 비용이 아닌 유저비용으로 산정이 될 것이기 때문이다.
또한,
서버 측에서의 response를 참조하여 단말기에서는 공유 유무를 판단하기 때문에 컨텐츠 생성 시 많은 로직을 거칠 필요가 없다.
더불어 위에서 예로 든 공유 시점에서의 오류가 나타날 경우에도 공유만 retry 하도록 구현하기가 비교적 쉬운 편이다.
그렇다고 무조건 좋은 것은 아닌 듯 하다.
서버측에서는 공유가 되었는지 아닌지를 판단할 근거가 없고, (물론 공유 이후 서버 API를 호출하지 않는 경우..)
또 클라이언트 측의 변경이 필요할 때는 클라이언트를 업데이트 해야 한다는 점이다.
앱스토어의 경우 업데이트에 보통 3~7일정도 소요되기 때문에 그 사이 처리가 서버에 비해서 시간이 많이 걸린다.
하지만 이보다 더 큰 단점은,
Twitter는 iOS5 이상에서 Facebook은 iOS6 이상에서 시스템에 통합되어 있으므로,
이전 iOS에서 처리를 위해 외부 모듈 삽입으로 분기 처리를 해야한다는 것이다. 여기서는 사실 복잡해질 수밖에 없을테니까…
어떤 방법이 최선일까?
SNS 프로젝트를 수행하면서 사실 Twitter나 Facebook으로의 컨텐츠 혹은 컨텐츠URL을 전송하는 것은 현재 거의 기본인 상황에서
어떤 방법이 최선일지는 생각과 실행을 더 해봐야 할 것이지만,
개인적으로는 클라이언트에서 하는 것이 옳지 않을까라는 생각이다.
서버가 타 SNS로의 공유주체가 된다고 했을 때는 비용문제가 큰 단점이다.
물론 클라이언트 개발자분들 중에서는 서버에서 처리하는 것이 간단하고 수정도 쉽기 때문에 서버에서 해야한다고 생각하시는 분들도 있겠지만,
비용 측면에서는 유저가 이를 감당하는 것이 옳지 않을까? (사실 나도 분기처리는 고달프다…)
그리고 클라이언트가 공유주체가 되었을 경우 이득도 무시는 못할 것이다.
(Facebook의 경우는 다방면으로 활용이 가능하니.. Facebook의 경우 캘린더, 주소록 등 다방면으로 시너지를 내고 있다.)
어떤 측이 공유 주체가 되어야 좋다라는 것은 좀 더 지켜봐야할 것이고 프로젝트 성향에 따라서도 trade-off 인 의견이니..
결론은 상황에 따라 알아서 주체가 되면되고,
지금까지 수행한 프로젝트를 회상했을 때 굳이 서버에서 할 필요가 있냐는 생각이다.
