월별 글 목록: 2014년 5월월

왜 개발가이드라인을 읽어봐야 할까요

오늘은 우리가 놓쳐온 사소한 것들에 대해 이야기 해보려합니다.

우리 개발자들은 급변하는 개발환경 속에서 살아가고 있습니다. 하루가 멀다하고 변화되는 지옥같은 개발환경에서 변화를 따라잡기란 참으로 힘겹기 그지없습니다. 항상 그렇듯 우리는 가장 중요하지만 가장 사소한 것들을 놓치며 살아갑니다. 내 가족의 소중함, 내 옆자리의 동료, 매일같이 맛있는 밥을 해주는 식당 아주머니의 손길…  우리가 개발을 하면서 수도 없이 들여다보는 개발문서, 그러나 너무나 사소해 보여서 그냥 지나쳐 버리는 개발문서의 핵심들…! 무엇이 있을까요?

헬게이트를 열어봅시다

제가 한 번 들여다 보겠습니다.

# 처음 만나는 프레임워크

‘안녕, 코코아 프레임워크! 반가워. 앞으로 잘해보자’

설렘 반 두려움 반으로 마주한 새로운 프레임워크. 그 친구에 대해 알아보기 위해서 가장 먼저 할 일은 아마도 개발도큐먼트를 읽어보는 일이겠지요? 마치 RC카를 조작하기 전에 설명서를 먼저 보는 것 처럼 말이죠. 그런데 우리는 RC카를 빨리 몰아보고 싶은 나머지 설명서의 앞, 뒤 다 잘라먹고 ‘차량 조종법’만 읽고 조종을 시작합니다. 그 상태로 막상 조작을 하다보니 좀 더 안전하게 운전하려면 어떻게 해야하는지, 연료는 무엇을 넣어줘야 좋은지, 부품은 무엇무엇으로 이루어져 있는지… 도무지 알지 못합니다. 하지만 일단 굴러가니까 좋아합니다. 이건 마치 도로교통법과 차량 기본 정비법은 까마득히 모르고 운전만 할 줄 아는 난폭운전자와 다를바가 없습니다. 개발세계에서 우리는 이런 난폭운전자가 될 수는 없습니다.

너무나 교과서 같은 이야기지만 개발문서는 그 어느 한 글자라도 생각없이 쓰여지지 않았다는 것을 한 번 생각해 보아야 합니다. 여러분께서 라이브러리를 개발하여 개발문서를 작성한다고 생각해 봅시다. 그 얼마나 귀찮고 힘든 일인지… 상상해 보셨나요? 그런데 그 개발문서에 시간들이고 공들여서 쓰잘데기 없는 이야기들을 쓴다구요? 당치 않습니다 ㅎㅎ 시간이 없다면 개발문서에 강조되어있는 헤드라인이라도 쭈욱 훑어보는 습관을 들이는 것은 어떨까요?

 

# 아… 이런 삽질이…!

위에 RC카를 예로 들었을 때, ‘조작법만 먼저 본다’고 예시를 들었던 것은 API Reference를 이야기 했던 것입니다. 도큐먼트에는 많은 목차들이 있지만 그 분량의 98% 이상은 API Reference겠죠? 하지만 제가 강조하고 싶은 것은 나머지 2%의 내용들입니다. 그 나머지 2%를 잘 숙지하지 않아서 생기는 일들은 너무나도 많아 다 이야기하기 어렵지만 몇 가지 사례를 제시해 보고자 합니다.

난 아직 2% 부족해

난 아직 2% 부족해

  • 어…? 뷰가 동작하지 않아!

개발자 모모씨는 아이폰 앱을 만들기 위해서 한창 코딩중입니다.

‘눈누난나~ 역시 난 천재야! 냐하하. 실행해볼까? 어..! 이게 왜 동작이 이상하지? 왜 먹통이 된거야!!’

애플의 코코아 프레임워크를 위한 코딩 가이드라인을 살펴보면 ‘메소드 이름 짓기‘라는 챕터가 있습니다. 그 곳을 살펴보면 Private Methods 라는 섹션이 있는데, 한 번 훑어보면

  • Names of most private methods in the Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark them as private. From this fact follow two recommendations.
  • Don’t use the underscore character as a prefix for your private methods. Apple reserves this convention.

왜 제대로 된 동작을 하지 않았는지 감이 오시나요? 애플은 코코아 프레임워크에 숨겨진 Private Method 앞에 항상 언더바( _ )를 붙인다고 하는군요. 그런데 모모씨는 한 번도 이런 문서를 쳐다도 본 적이 없죠. 결국 모모씨는 3일 간의 삽질을 뒤로하고 자포자기하는 심정으로 주변 iOS 개발 고수님께 코드를 보여줍니다. 결론은요? 3분도 채 되지 않아 고쳤죠 🙂 저 메소드가 기존 프레임워크의 Private Method를 오버라이드 해 버린 것이었습니다.

p.s. 예를 들기 위하여 작성한 코드일 뿐, 실제 위의 코드로 오동작하지는 않습니다.

 

  • 아니… 왜 리젝된거지?

모모씨는 뼈저린 아픔을 뒤로하고 계속 앱 개발을 진행합니다. 물론, 가이드 문서를 다시 읽어봤을 턱이 없죠 ^^ 그래도 문제가 하나 해결되었으니 가뿐한 기분으로 계속 개발을 진행해 나갑니다. 모모씨가 개발하고 있는 앱은 추억의 똥피하기 게임. 하하 드디어 완성했습니다! 앱스토어에 올려야죠? 당당히 애플에 리뷰신청을 합니다. 드디어 리뷰 결과가 나왔군요!

추억의 똥피하기 게임

추억의 똥피하기 게임

당신의 앱은 부적절 컨텐츠로 반려되었습니다. 앱스토어 리뷰 가이드라인 16을 참고하세요.

아니 이게 무슨말이지? 모모씨는 너무나 황당합니다. 대체 뭐길래 이게 안된다는거야! 버그도 없고 동작도 잘 한단말야!

앱스토어 리뷰 가이드라인을 살펴보러 가봤습니다.

16. Objectionable content

16.1 Apps that present excessively objectionable or crude content will be rejected

16.2 Apps that are primarily designed to upset or disgust users will be rejected

하… 이번에도 가이드라인을 제대로 숙지하지 못해 빅삽질을 하게 되었군요. 애플은 일부 사용자들이라도 불쾌감을 느낄 수 있는 앱은 허용하지 않는다는군요. 프로젝트를 아예 폐기해야 할지도 모르는 상황입니다..! 결국 모모씨는 똥피하기의 컨셉을 버리고 빗방울 피하기 게임으로 컨셉 자체를 변경하게 됩니다.

아아... 가슴이 아파..

아아… 가슴이 아파..

  • 실제 예시를 몇가지 더 소개합니다
  1. Private Method 및 Private Variable을 자신도 모르는 사이에 재정의 해버려서 원인을 알아내는데 수 일이 걸린 경우
  2. 앱 내에 사진 업로드를 포함한 성 상담 익명 게시판을 만들었지만 가이드라인에 위배된다며 반려되어 서비스 기획부터 다시 해야 했던 경우
  3. IAP(In-App Purchase) 아이템의 성격이 애플의 가이드라인에 맞지 않아 과금 정책을 변경해야 했던 경우
  4. 앱스토어에 게재되는 스크린샷에 안드로이드 이미지가 일부 포함되어 있어서 반려된 경우
  5. 프레임워크에 맞게 재정의된 자료형을 사용하지 않아 아키텍쳐에 따라 상이한 결과 및 메모리 접근 오류가 발생하여 일일히 수정해 주어야 했던 경우(64bit 프로세서 전환 때 멘붕 겪으신 분들이 종종 있죠)
  6. 가이드라인에 제시된 프레임워크 구조를 모두 파악하지 못한 채 프로젝트를 진행하여 후임자가 구조를 모두 변경하여야 하는 경우
  7. 더 좋은 퍼포먼스를 지원할 수 있는 번들 리소스를 알지 못해 이미지 및 사운드 리소스를 모두 교체해야 하는 경우

 

등등등…

# 마치며

간단한 예시를 통해 개발문서의 가이드라인을 숙지하지 않아 발생하는 불상사를 알아봤습니다. 물론 위의 예는 아주 극히 일부분이고, 어쩌면 애플 프레임워크 위에만 해당하는 문제일 수 있습니다. 하지만, 실제 현업에서 지켜본 결과 저런 일들은 비일비재하게 일어나고 있으며 그 원인은 가장 기본을 놓쳤기 때문입니다. 개발에 걸리는 몇 십, 몇 백 시간을 저 가이드라인 하나를 놓쳐서 몽땅 말아먹는 경우도 생길 수 있다는 이야기입니다.

무시하기 쉬운 프레임워크(or 라이브러리) 제공자들의 한 마디 한 마디를 놓치지 말자구요~

다른 의견 또는 실제 사례가 있으면 덧글로 남겨주세요 🙂 기다릴게요~!

이상형 오디션 on AWS

2013년 11월 말… 새로운 프로젝트 개발을 시작하게 되었습니다. 이름하여 ‘본격대결, 이상형 오디션’ 입니다. 5개월여의 시간이 흘러 4월말 오픈 베타를 시작으로 5월 7일에 정식 런칭을 하게 되었습니다.

idealmate

 

현재 <안드로이드앱>을 스토어에서 만나볼 수 있습니다. 또한 이상형 오디션의 기획 이야기에 관심이 있으시다면 <게임과 네트워킹의 만남, 본격 대결 ‘이상형오디션’ 기획 이야기>를 읽어보시기를 추천합니다.

 

이 포스팅에서는 이상형 오디션이 인프라로 선택하고 사용한 AWS 서비스에 대해서 소개를 해보려고 합니다. 사용한 서비스를 간략히 나열해보면 아래와 같습니다.

  • EC2
  • RDS
  • S3
  • CloudFront
  • Route53
  • SNS
  • SQS

 

EC2

EC2는 AWS의 기본이 되는 서비스이며 가상 서버입니다. 사용자의 요청을 처리하는 API 서버와 서비스 운영, 통계 등을 담당하는 어드민 서버, 아직 AWS의 서비스로는 지원하지 않는 mongoDB 서버를 EC2 상에서 운영하고 있습니다. API 서버의 경우 ElasticLoadBalancer, AutoScaling 연동을 해서 자동으로 scale-out 이 되도록 해두었으나 아직 서비스 규모가 크지 않아서 효과를 보지는 못했네요.(얼른 트래픽이 많아져서 AutoScaling 이 빛을 발하는 모습을 보고 싶습니다.) MongoDB 의 경우 2014년 4월에 추가된 memory optimized instance인 r3 instance 를 사용하여 가격대비 높은 메모리를 쓰고 있으며 I/O 성능을 높이기 위해 Provisioned IOPS EBS volume을 붙여서 mongoDB 의 storage로 사용하고 있습니다. 참고로 r3 instance의 경우 HVM(Hardware Virtualization) AMI 만을 지원하므로 instance 생성시에 주의해야 합니다.

RDS

개발 시작 즈음부터 RDS에서 PostgreSQL을 사용할 수 있게 되었습니다. 이음에서 MySQL을 사용하면서 겪었던 문제들 중 하나가 table에 새로운 column을 추가할때 table에 lock이 걸려서 해당 table에 대한 요청을 처리할 수 없는 것이었습니다. PostgreSQL의 경우 column 추가가 매우 빨라서 기획이 바뀌거나 기능을 추가하는 경우에 좀 더 유연하게 대처할 수 있을 것으로 판단을 해서 선택하게 되었습니다. 또한 PostgreSQL의 안정성을 믿기로 했습니다. PostgreSQL 또한 Provisioned IOPS를 설정해서 안정적인 성능이 나오도록 했습니다. 역시나 아직까지 트래픽이 많지 않아 매우 안정적이며 여유롭습니다.

S3

S3는 다양하게 활용할 수 있는 매우 좋은 서비스입니다. 서비스를 위한 이미지와 사용자가 직접 업로드하는 프로필 사진 모두 S3에 업로드하여 서비스를 하고 있으며 각종 로그도 저장하고 있습니다. 또한 API 서버 배포시에 S3를 저장소로 사용하고 있습니다.

CloudFront

서비스용 이미지와 사용자 프로필의 경우 S3를 origin으로 하여 CloudFront를 통해 서비스를 하고 있습니다. CDN를 따로 계약할 필요없이 트래픽만큼만 비용을 지불하면 되니 정말 최고의 서비스가 아닌가 싶습니다. 참고로 사용자 프로필의 경우는 무분별한 크롤링을 방지하기 위해 signed URL을 사용하고 있습니다.

Route53

서비스용 도메인인 idealmate.kr의 DNS 서비스로 Route53을 사용하고 있습니다. 4월 10일부터 유료화된 DNSever 대신 사용하게 된 것이 그나마 이야깃거리네요. DNSever의 경우 standard DNS가 도메인당 월 천원(부가세 별도)이고 Route53의 경우 0.5달러여서 조금 더 저렴하기도 합니다.

SNS

모바일앱 Push nofitication을 사용하고 있습니다. 이상형 오디션의 경우 현재는 안드로이드앱만 출시된 상태지만 iOS앱도 출시를 위해 심사중입니다.(애플과의 밀당은 그만하고 싶네요ㅠㅠ)  SNS Push notification의 경우 APNS, GCM을 모두 지원하고 월 최초 백만건이 무료이며 추가 백만건당 0.5달러로 매우 저렴합니다. Push nofitication외에도 CloudWatch에서 설정한 alarm을 받는 용도로도 사용하고 있으며 alarm을 email과 http 연동을 통한 SMS로도 받고 있습니다.

SQS

이상형 오디션의 기능 중 랭킹 기능이 있습니다. 랭킹의 경우 사용자의 연승 갱신, 승리 추가, 채팅 요청, 채팅 수락 등의 액션에 따라서 랭킹 포인트가 증가해야 하는데 API 서버가 바로 랭킹 포인트를 갱신하기에는 부담스러운 작업입니다. 그래서 SQS를 사용해서 랭킹 포인트를 비동기로 증가시키도록 했습니다. 물론 SQS에 쌓인 job을 읽어서 처리하는 worker는 별도로 구현을 했습니다.

 

맺음말

이번 프로젝트를 하면서 AWS 서비스를 다양하게 사용해보았습니다. 이음에서는 아직 사용하지 않는 CloudFront, SNS Push notification을 사용하면서 비용도 절약하고 개발도 편하게 할 수 있었습니다. 프로젝트를 진행하는 동안 AWS도 RDS PostgreSQL 지원, EC2 r3 instance 추가, 가격 인하 등의 변화가 있었고 프로젝트에도 많은 도움이 되었습니다. 앞으로도 AWS가 더 발전하기를 바라면서 이만 마치겠습니다.