태그 보관물: ium

Jo SeongGyu

2014/12/29

Apple_Swift_LogoSwift 로고
[출처 : Wikipedia – http://en.wikipedia.org/wiki/File:Apple_Swift_Logo.png ]

그렇습니다. Swift는 정말이지 뜻밖의 출현이었습니다.

무제

iOS 8과 더불어 새로운 기기가 발표될 거라고 생각했던 올 여름, 당황스럽게도 Swift 라는 아주 생소한 언어가 발표되었습니다. 힘차게 하강비행하는 듯한 칼새의 모습을 형상화한 로고가 나오는 순간, ‘저건 뭐지?’ 싶었는데, 새로운 언어라는 말에 저는 충격과 공포에 잠시 정신을 잃었던 것 같습니다. 이내 정신을 차렸지만 그 충격과 공포는 쉽사리 사라지지 않았습니다. ‘프로그래밍 언어라는 것이 뚝딱 만들어져 나올 수 없는데, 어떻게 저렇게 새로운 언어를 비밀리에 개발해서 내놓은거지?’ 등등 별별 생각이 다 들었어요. 어쨌거나 저쨌거나 언어에 종속될 수 밖에 없는 클라이언트 개발자는 눈물을 머금고 새로운 언어에 다가서 봤습니다.

첫 만남

Swift와의 첫만남은 ‘이게 뭐야’였어요. 스크립트 언어도 아닌 것이, 그렇다고 기존에 쓰던 Objective-C를 닮은 것도 아닌, 자바 비스무리한 새로운 변태같은 언어의 느낌. 딱 이런 느낌이었어요. 처음에는 당연히 Xcode 베타버전이라 크래쉬도 많이 나고, 불안정한 요소도 많았구요. 지금과는 문법도 조금씩 다른것들이 있었습니다. 여튼, 새로운 언어와의 첫만남은 한 마디로 ‘별로’ 였어요.

더 좋아진

Swift는 새로 출시된 언어답게 조금 더 발전된 기능들로 무장을 하고있습니다. 애플에서는 Swift의 특징을 Safe, Power, Modern으로 꼽았는데요, 새로나온 언어인 만큼 Modern함은 충분히 갖추고 있구요, Optional이라는 기능을 통해 Safe를 충족시키려 노력한 것을 볼 수 있습니다. 그러나 아직은 Power에 대한 의문은 남아있습니다. 기존 Objective-C 보다 성능면에서 대체적으로 떨어지기 때문인데요, 이 부분은 차후에 어떻게 개선되어 나갈지 지켜봐야 겠습니다.

그러나 더 발전해야할

물론 새로운 언어에서 좋아진 점들이 많지만, 아직은 부족한 부분들도 남아있습니다. 캡슐화가 아직 완벽히 지원되지 않고 있기 때문에 반(Half) 객체지향 언어라는 느낌이 강합니다. 애플에서는 앞으로 캡슐화를 할 수 있는 방안을 마련하도록 하겠다고 하였으나 이는 추후 지켜봐야 할 숙제라고 생각합니다. 또한 아직은 Swift를 완벽히 서포트 해주지 못하고 있는 Xcode도 발전에 조금 더 시간이 필요할 것 같습니다. 정식 배포버전이 베타버전에서 발전하여 문법도 조금씩 바뀌고, 불편한 점들을 개선한 것을 보면 위의 문제들은 시간이 해결해 줄 것이라고 생각합니다.

그래서..?

개인적으로 지극히 주관적인 입장으로 Swift는 2014년 말, 현 시점에서 아직까지 큰 프로젝트에 적용하기는 부담스럽다는 느낌입니다. Objective-C와 한 프로젝트 내에서 혼용하여 쓸 수 있다지만, 저는 그다지 그 연결에 흡족하지 못한 상태입니다. 그래서 현업 프로젝트에는 아직 적용하지 못하고 있어요. 그렇지만 iOS 또는 Mac OS 어플리케이션을 개발하는 사람이라면 꼭 배워두어야 할 것 같다는 생각입니다. 언젠가는 많은 발전을 통해 Swift가 대세가 될 날이 올 것 같기도 하거든요. 개인적으로는 생각보다 굉장히 파격적이고, 강력한 언어라고 생각합니다. 기본적으로 다른 언어 몇 가지를 익숙하게 다룰 줄 아는 프로그래머라면 Swift를 이해하는 첫 걸음은 Optional과 기존 Objective-C에서와는 조금 확장된 nil 이라는 개념이라고 생각하는데요, 여기(http://goo.gl/8VD1Rf)에 좋은 설명이 있어서 링크를 남겨둡니다. Optional과 nil 이라는 개념만 잘 이해해 두어도 Swift를 1/3은 정복했다고 생각합니다.

 

글을 끝까지 읽어주셔서 감사합니다. 아마 대부분 이 글을 읽으신 분들의 표정은 이러실거 같아요. 그래서 어쨌다고? 뭐라는겨?
스크린샷 2014-06-24 오후 6.51.15
사실 Swift의 실제 사용 후기에 대해 이것저것 말해보려고 했습니다만, 아마도 이정도로 충족하지 못하실거라 생각해요. 궁금한 점에 대해서 덧글 주시면 성심성의껏 답변드리도록 하겠습니다!

 

 

참고서적

Objective-C 개발자를 위한 Swift – 김근영 저
기존 Apple 어플리케이션 개발자들을 대상으로 썼지만, 다른 언어를 알고있는 프로그래머라면 충분히 이해하기 쉽게 설명된 Swift 기본 언어 책입니다.

만들면서 배우는 Swift: 스위프트로 시작하는 iOS 개발 – 야곰 저

기존 프로그래머가 아니더라도 아주 간단하게 Swift의 굵직한 특징들을 살펴볼 수 있고 간단한 iOS 앱을 따라 만들어 볼 수 있습니다.

 

[알림] 이 글은 이음소시어스와 그 개발팀의 견해와 일치하지 않을 수 있으며 지극히 주관적인 글임을 알립니다.

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

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

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

헬게이트를 열어봅시다

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

# 처음 만나는 프레임워크

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

설렘 반 두려움 반으로 마주한 새로운 프레임워크. 그 친구에 대해 알아보기 위해서 가장 먼저 할 일은 아마도 개발도큐먼트를 읽어보는 일이겠지요? 마치 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 라이브러리) 제공자들의 한 마디 한 마디를 놓치지 말자구요~

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

Xcode Bots 적용

테스트는 프로젝트에서 빠질수 없는 부분입니다. 테스트를 위해 변경된 앱을 설치해야 합니다. 설치 방법에는 여러가지가 있습니다. 여러가지 방법 중 Hey 프로젝트에서 적용한 방법을 공유하려고 합니다.

Hey?

Hey는 글로벌 버전 소셜데이팅 서비스입니다. 매일 오전 10시 3명의 이성의 프로필을 확인하고 서로 호감이 있으면 채팅을 할 수 있습니다.

Hey_Timeline Hey_Profile Hey_Chat

테스트 버전 배포

앱스토어에 업로드가 아니라 테스트를 위해 사내에 배포할때 어떤 방법을 사용하시나요?
이음에서는 두가지 방법을 이용했습니다.

  1. 디바이스를 연결하고 Xcode에서 직접 실행해서 앱를 설치해준다.
  2. Adhoc을 이용하여 사내 메일로 공유한다.

1번 방법은 작업중에 설치해줘야 할 경우 방해를 받게 됩니다. 그리고 테스트 디바이스로 등록되지 않은 디바이스때문에 Provisioning을 새로 생성해야 하는 문제가 발생합니다. Debug/Release로 빌드했는지 확인해야 합니다.

adhoc adhoc2 adhoc3

2번 방법은 1번 보다 더 효과적입니다. 한번 메일을 공유하면 앱을 설치해주느라 방해받지 않아도 됩니다. 하지만 불편한 배포과정이 남아 있습니다. Archive -> Distribute -> Adhoc 이런 방법으로 Adhoc버전으로 바이너리를 만듭니다. 그리고 생성된 ipa, plist 파일을 미리 입력한 url에 맞게 서버에 업로드합니다. 여기까지가 끝이지만…. 제대로 올렸는지 확인하기 위해 직접 다운로드해봐야 합니다.

두가지 방법 다 만족스럽지 못합니다.

그래서 새로운 기능인 Bots에 관심이 생겨서 직접 적용해 보았습니다.

Bots ?

Xcode BotsXcode5에 새로 추가된 기능입니다. Bots은 Xcode만을 위한 CI입니다. Bots은 간편하게 설정할 수 있습니다. XCTest를 사용할 경우 실제 등록된 디바이스에서 테스트를 실행하고 결과를 리포트해주는 기능도 있습니다.

bot_viewer-summary_2x 지속적인 통합을 위한 Bot

Bots 설치방법

http://meetkei.com/?p=3196

프로젝트 적용

HeyRelease Bot 생성

createHeyReleaseBot1

Hey Scheme 의 Bot을 생성합니다.

createHeyReleaseBot2

일일 빌드를 위해 매일 오후 5시에 빌드되도록 일정을 설정합니다.

createHeyReleaseBot3

빌드 성공시 프로젝트원 모두 메일을 받을 수 있도록 설정합니다.
실패시 개발자들만 메일을 받도록 설정합니다.
Create Bot 클릭하면 바로 통합이 진행됩니다.

HeyReleaseBuildError HeyReleaseBuildSuccess

통합 결과에 맞게 실패, 성공 메일을 받습니다.
디바이스에서 성공 메일을 확인한 후 제품 다운로드를 클릭하면 설치가 진행됩니다.

이제 통합을 매일 하는 일만 남았습니다!

문제 발생

통합메일에서 다운로드받은 앱을 실행해보니 서비스중인 서버(RealServer)로 접속하고 있었습니다. 테스트를 위해서 RealServer와 테스트 서버(TestServer) 모두 테스트가 가능해야 합니다. 이대로면 TestServer에서 테스트하기 위해서는 기존 방법을 이용해야 합니다.

RealServer로 접속하는 이유

Bot은 통합과정에서 Release build를 하게 됩니다. Build Settings 와 Server Host를 결정하는 Macro때문에 HeyRelease는 RealServer로만 접속됩니다.

HeyRelease_preprocessor

Build Settings > Preprocessor Macros 의 설정을 보면 Debug 에서 DEBUG=1 이 존재합니다. Release 에는 DEBUG가 존재하지 않습니다.

Header 에 적용한 Macro입니다. DEBUG가 존재하면 TestServer로 아니면 RealServer로 API_HOST가 정해집니다. 통합 중에는 Release 로 빌드가 되므로 API_HOST는 TestServer가 됩니다.

그럼 테스트 서버로 연결하려면?
Release에서도 DEBUG를 설정하면 됩니다.

그럼 RealServer, TestServer 를 모두 테스트하고 싶으면?
음…..

Hey에 적용한 방법

여러가지 방법을 생각해본 결과 제가 선택한 방법은 Target을 하나 더 생성하는 것입니다. HeyRelease는 RealServer로 HeyDebug는 TestServer로 접속하도록 하였습니다. Bot을  2개 생성해서 필요할때 둘중 하나를 배포합니다.

  1. 현재 Target을 복사해여 새로운 Target을 만듭니다.
  2. Preprocessor Macros 를 설정합니다.
  3. HeyDebug 이름으로 Bot을 생성합니다.

HeyDebug_preprocessor

createHeyDebugBot1 createHeyDebugBot2 createHeyDebugBot3

단점

  • build settings이 변경되면 두개의 Target 에 적용해야 함
  • 파일 생성 및 추가시 두개의 Target 을 지정해야 함

targets

언급한 단점이 있지만 Bots을 빠르게 적용할 수 있는 방법입니다. 개선된 방법은 조금 더 고려해 볼 예정입니다.

Bots Error

처음 Bots을 사용하면 많은 오류들과 만나게 됩니다. 몇가지 오류 해결 방법을 정리하였습니다.

Provisioning Profile 관련 오류

ProvisioningProfileError

iOS Team Provisioning Profile 을 사용하면 문제가 해결됩니다.

GeneralIdentity

그래도 해결되지 않는 경우 Target > General > Identity 에 위와 같이 Provisioning Profile 오류로 인한  Fix Issue버튼이 표시되는 경우가 있습니다. 이 버튼을 클릭하고 수정된 상태에서 통합을 진행해 보세요.

Reason: XCSCredentialSSHKey: private key is missing from the credential

http://stackoverflow.com/questions/5525436/xcode-could-not-find-a-valid-private-certificate-valid-key-pair-for-this-profile

xcode bots User interaction is not allowed.

  • Open the Keychain Access
  • Right click on the private key
  • Select “Get Info”
  • Select “Access Control” tab
  • Click “Allow all applications to access this item”
  • Click “Save Changes”
  • Enter your password

http://stackoverflow.com/questions/577750/running-xcodebuild-from-a-forked-terminal

Bots 오류 모음

  • Repositories that require an SSH key to access
  • Code Signing and Provisioning Profiles
  • Submodules
  • I made a mistake and now I can’t fix the repository from Xcode!

http://ikennd.ac/blog/2013/10/xcode-bots-common-problems-and-workarounds/

Profile

아파치 모듈로 개발된 API 서버, 이음 베이론을 소개합니다.

안녕하세요. 저는 이음소시어스에서 서버사이드 개발을 하고 있는 오영식(다람)입니다. 개발팀 블로그의 첫 글로 우리의 새로운 API 서버 마개조 프로젝트, 이음 베이론을 소개해 드리려고 합니다.

Introduction

2년쯤 전, 카카오톡에서 “겁나빠른황소” 프로젝트를 적용하였습니다. 초반에는 빠르게 작동하던 카카오톡이 사용자가 늘어남에 따라 속도 또한 느려져 전체적으로 시스템을 개편한 것입니다. 이전부터 카카오톡을 사용해 보신 분들은 아시겠지만, 메시지 전송을 할 때 항상 보이던 바람개비가 그 이후에는 구경조차 어렵게 바뀌었습니다.

이와 비슷하게, 이음 또한 사용자가 많이 늘어나면서 수많은 데이터가 쌓여감에 따라 빠릿빠릿하게 작동하던 어플리케이션이 점점 느려져 사용에 불편함을 느낄 정도가 되었습니다. 또한, 기존에 개발되어 있는 소스코드에 계속해서 기능을 추가하다 보니 소스코드의 양이 너무 방대해져 유지보수가 어렵게 되어, 전면적인 소스코드 개편을 고려하게 되었습니다. 그 결과로 만들어진 것이, 이름하여 베이론 프로젝트입니다.

베이론?

먼저 전혀 중요하지 않지만 베이론이라는 이름은 매우 빠른 서버를 만들자는 취지에 따라 구글에서 자동차 제로백 순위로 검색해 나름 있어 보이는 이름으로 지었습니다.

 

1

실제로 소스코드 저장소 위키에도 이렇게 써 있습니다.

 

베이론은 아파치 웹 서버의 모듈로 개발이 되어 있습니다. 물론 C로 개발하고 있고, 이 때문에 기존의 Spring framework를 사용한 서버보다 훨씬 빠르고 더 적은 리소스로 구동이 가능합니다.

맨 처음 개편을 고려할 때 많은 언어들을 고려했습니다. Rails, PHP, Python, Node.js, Java로 다시만들기(!) 등 많은 선택지가 있었는데, 아파치 모듈(C)를 선택한 이유 몇 가지를 추려보면:

  1. 웹 개발 언어가 많은 연산을 필요로 하지는 않고 대부분의 병목이 DB에서 남에도 불구하고, 생각보다 많은 속도 저하가 웹 어플리케이션 내부에도 존재합니다. C는 (잘 짜면)매우 좋은 성능을 보장해줍니다.
  2. 좋은 성능에도 불구하고 메모리 관리와 같이 컨트롤하기 까다로운 문제도 존재하고, 데이터 저장 및 수정이 타 언어에 비해 불편한 것이 사실입니다. 하지만 아파치가 내부적으로 사용하는 라이브러리(APR)이 매우 강력해 C로도 충분히 빠른 시간 안에 좋은 퍼포먼스의 웹 어플리케이션을 개발 할 수 있습니다.
  3. 스프링, 레일즈와 같은 프레임워크는 웹 개발자에게 매우 편리한 강력한 기능들을 많이 제공하고 있습니다. 하지만 프레임워크는 아무리 좋은 성능을 내더라도 프레임워크 없이 잘 짜여있는 어플리케이션보다 느린 것이 사실이고, 처음에 익히는데 시간이 드는 것이 단점입니다. 따라서 프레임워크에 의존하지 않는 방식으로 개발을 하게 되었습니다. 언젠가 스프링 배치의 퍼포먼스와 개발속도에 분노해 아예 바닥부터 짜버린 배치의 사연도 소개하게 되겠지요.
  4. 사실 C로 API를 구현한다는 사실이 매우 생소하긴 하지만, (NHN에서 통합검색 서버를 개발하신 제 옆의 모 개발자님께서 말씀하시길) 수많은 트래픽을 감당하고 있는 네이버 검색 웹 서버 또한 대부분 아파치 모듈로 개발되어 있어, 이는 충분히 사용할만하고 검증되어 있는 방식이라고 할 수 있습니다.

벤치마크

베이론 서버와 기존 Java로 개발된 서버는 많은 부분에서 퍼포먼스 차이를 보여줍니다. 이 글에서는 두 가지 관점에서 비교를 해 보겠습니다. 첫 번째는 사용자가 직접 체감하게 되는 Latency이고, 두 번째는 서버 개발자들이 항상 전전긍긍하며 바라보게 되는 CPU 사용률입니다. 먼저, Latency를 비교해 보도록 하겠습니다.

(1)   Latency

    1. Java 서버
2

Java 서버의 Latency

 

대체로 평소에는 0.1~0.2초대의 응답속도를 보여줍니다. 그렇지만 우리 서비스의 특성상 특정 시간에 매우 많은 트래픽이 발생하는데, 이 시간대에는 0.7초까지 응답속도가 늦어지는 것을 볼 수 있습니다.

      1. 베이론 서버
3

베이론 서버의 Latency

전체적으로 응답속도가 0.1초 아래로 나온다는 점도 훌륭하지만, 주목하셔야 할 점은 서비스 이용자가 몰리는 시간과 그렇지 않은 시간의 차이가 전혀 없다는 사실을 보아주세요. 어떠한 서비스던 그렇겠지만, 우리처럼 특히 특정 시간에 많은 트래픽이 몰리는 서비스의 경우에는 이러한 항상성(?)은 서비스의 큰 안정성을 보장하게 됩니다.

(2)   CPU 사용률

      1. Java 서버
4

Java 서버의 CPU 사용률

기본적으로 차지하는 CPU 사용률도 최소 5%이고, 이용자가 몰리는 시간에는 특히 30~40%대의 CPU 사용률을 가지고 있습니다. 따라서 안정적인 서비스 제공을 위해서는 좋은 CPU를 가진 인스턴스를 이용할 수 밖에 없습니다.

      1. 베이론 서버
5

베이론 서버의 CPU 사용률

굉장히 들쭉날쭉한 것 같아 보이지만, 평소에는 거의 0%대의 CPU 점유를 하고 있다가 사용자가 몰리는 시간에는 무려 3%까지(!!!) 차지하고 있습니다. 사실상 CPU는 거의 놀고 있습니다. Java서버와 비교하면 정말 큰 차이가 드러나고 있습니다.

(3)   기타

위 벤치마크 자료에는 드러나 있지 않지만 더 무서운 사실이 존재합니다. Java서버는 이용자가 몰리는 시간에 자동으로 인스턴스가 4대로 변경되며, CPU사용률에 따라 6대까지 늘어납니다만, 베이론 서버는 단 2대로 운영이 되고 있습니다. 이 사실까지 감안한다면, 베이론 서버의 압승이라고 볼 수 있겠지요.

단점도 있지 않을까요?

음, 사실 저도 베이론 프로젝트를 맨 처음 들었을 때 복잡한 C로 작성한다는 것이 매우 두려웠는데, 막상 진행을 하다 보니 아파치에서 제공하는 라이브러리를 통해 정말 쉽게 작성할 수 있었습니다. 그나마 있는 단점이라고 하면, 조금 생소하다는 점이 있겠네요. 아파치 모듈로 API를 작성하는 경우는 거의 없으니까요. 또, 필요한 기능이 있으면 직접 구현(!)해야 한다는 단점도 존재합니다.

그러나, 여전히 C는 API를 구현함에 있어 정말 좋은 언어입니다. 이 글에서는 단순히 아파치 모듈의 설명과 벤치마킹 자료만 올려 놓았지만, 나중에 추가로 기본적인 아파치 모듈의 작성 방법에 대해 글을 작성할 수 있을 것 같습니다.

기타

C로 개발하면 API는 몰라도 웹은 어렵지 않을까? 하는 생각을 하실 수도 있겠다는 생각이 들었습니다. 우리는 API를 C로 개발한 뒤에, Front는 Ruby 혹은 Python처럼 빠르고 간결하게 작성할 수 있는 언어로 개발한 뒤 API를 호출하여 결과값을 얻어내는 방식을 고려하고 있습니다. 이 부분은 레진코믹스의 경우와 비슷한데요, 위의 링크를 참고하시면 좋을 것 같습니다. 이렇게 작성하면 C의 빠른 속도와 스크립트 언어의 빠른 개발 속도를 모두 취할 수 있다는 장점이 있습니다. 물론, 웹에서도 API를 이용하기 용이하도록 잘 설계했다는 전제조건이 있어야겠지요.

결론

 

 …Write in C

Q: 모바일 api가 느린데 어떻게 하면 좋을까요?
A: C로 짜면 됩니다.

11