Nov 212013
 

AD fresca는 실시간 데이터 처리 기술을 이용해서 실시간 Mobile Engagement 서비스를 제공하는 B2B 서비스 회사입니다. 저희는 고객사인 게임빌, 넥슨, 네오위즈게임즈, 아프리카TV 등의 모바일 게임 퍼블리셔들과 함께  새로운 모바일 세상을 만들기 위해 나아가고 있습니다.

Customer Advocate이란?

AD fresca에서 Customer Advocate은  “고객의 성공을 도와주는 데이터 과학자 (Data Scientist)“를 의미하며 자신이 담당하는 고객사에 대해 Operation의 총책임을 맡습니다. 대표적인 업무로는 신규 고객사를 대상으로 진행하는 First Step Program (FSP, 첫발 내딛기 프로그램)을 들 수 있습니다. 이 프로그램은 최초 데이터의 정의 단계부터 론칭 이후의 지표 관리까지 고객사 (주로 게임사)가 성공적인 데이터 기반의 게임 서비스 운영을 진행할 수 있도록 도와 줍니다.

“저는 아직 생소한 개념인 User Engagement를 고객사에 설명하고 고객사 분들 (PM, 마케터, 개발자 등)에게 동기를 부여하고 제안함으로써 고객사에서 보다 효과적인 캠페인을 통해 성공적인 결과를 거두도록 도와 주는 일을 합니다.

처음에는 한분 한분에게 User Engagement를 이해시키고 게임 하나에 저희 서비스를 붙이는 것도 어려웠는데 FSP를 진행하면서 고객사 내부에 저희 서비스를 이해하는 분들이 많아지고 저희 서비스를 내부팀에 전파해 주는 분 (Champion)이 생겨서 이제는 저희 서비스를 자발적으로 도입해 주는 사례들이 많아졌습니다. 이렇게 다양한 게임팀과 함께 캠페인을 실행해서 성공사례를 만들고 이를 전파함으로써 고객사와 함께 성장해 나가고 있습니다.

AD fresca가 게임 사용자의 행동 변화를 이끌어 내기 위한 모바일 인게이지먼트 서비스를 제공하듯이 Customer Advocate은 우리 고객사 분들의 행동 변화를 이끌어내기 위한 일 (Job)이고 그렇게 행동변화를 성공적으로 만들었을 때 정말 큰 기쁨과 재미를 느끼고 보람을 찾을 수 있습니다. “

– 권준호 팀장(AD fresca, Customer Advocate)

AD fresca의 Customer Advocate이 되시면 전세계 220개국 2,600만 사용자들의 앱 사용 데이터을 분석하여 앱 사용자들의 행태를 변화시킬 수 있는 캠페인과 관련 기술들을 기획하고 실제로 적용해 볼 수 있습니다. 또한 매월 6억개 이상의 API call을 처리하는 엔지니어링팀과 함께 일하면서  새로운 기능을 만들어 서비스를 만들어 나가게 됩니다.  말로만 듣던 ‘린 스타트업’ (Lean Startup)에서 직접 일할 수 있습니다.

이런 분을 찾고 있어요!

  • 모바일 서비스에 적합한 KPI를 설계할 수 있어야 합니다.
  • 숫자를 쉬운 이야기로 풀어서 설명하실 수 있어야 합니다.
  • 지속적인 커뮤니케이션으로 고객과의 장기적 관계를 만들어 나가고자 하시는 분
  • 수학, 통계 전공자면 +++
  • 게임 회사에 다녔다면 +++
  • 모바일 게임 또는 앱 운영을 해 봤다면 +++
공통조건
  • 학력, 경력 조건 없음
  • 병역의무 해제 필수 (성별로 해제하신 분은 우대!!)
  • 영어자료 독해능력 필수
  • 다른 사람들과 대화 능력 필수
  • 친근한 것과의 결별, 새로운 것으로의 도전을 마다하지 않는 열정
근무 조건
  • 역삼역 사무실
  • 식사 제공
  • 10시 반 ~ 7시반 (그 이전에 출근해서 미리 퇴근 가능)
  • 급여는 내부 가이드라인에 따라 협의 후 결정합니다.
지원 방법
  • 자신을 잘 설명할 수 있는 내용을 보내 주세요. 규격이나 양식은 없어요
  • 하지만 지원자가 어떤 사람인지 안 가르쳐 주고 뽑아 달라고 하시면 곤란하겠죠?
  • 이메일로 지원: dano@adfresca.com (이의정, CEO)
 Posted by at 5:12 PM
Nov 192013
 

안녕하세요.

저희 AD fresca 팀은 지난 주 SK Planet에서 주최한 Tech Planet 2013에 참가하여 부스를 마련하였습니다. 이번 행사를 통해 많은 개발자 분들과 만나 저희 시스템을 소개해 드렸고 더불어 즐거운 대화를 나눌 수 있었습니다. (부스에 참여할 수 있도록 배려해 주신 SK Planet과 지디넷 코리아에 감사의 말씀을 드립니다.)

tech planet booth

 

이 글에서는 저희가 현재 사용하고 있는 시스템의 구조에 대해서 이야기해 보려고 합니다. (2013년 10월말 기준으로 월 6억건의 API call을 실시간으로 처리하고 있습니다.)

Tech Planet 2013 Booth slides.002

저희 서비스는 모바일 앱에 설치된 SDK를 이용하여 사용자 데이터를 수집하고 그에 따른 사용자 프로화일에 맞는 마케팅 캠페인을 실시간으로 매칭하고 분석하는 서비스입니다. 위 그림에서는 저희 서비스가 어떠한 과정을 통해 작동하는지를 설명하고 있습니다.

SDK Data Collection

저희 SDK는 모바일 앱에 설치되어 사용자 데이터를 수집하고 서버에 전송합니다. iOS, Android, Unity 등 다양한 플랫폼을 지원하며 손쉽게 적용이 가능합니다. 기본적으로 SDK가 수집하는 디바이스의 기본 정보 (예: 고유아이디,  사용언어, 앱 버전 등) 외에도 앱마다 설정할 수 있는 각종 커스텀 파라미터 (예: 레벨, 스테이지, 스코어 등)와 마케팅 이벤트 (예: 레벨업,  아이템 구매, 스토어페이지 방문 등) 등을 정의하여 데이터 분석 및 마케팅 캠페인 매칭에 이용하게 됩니다. 이와 더불어 사용자에게 전달된 메시지에 대한 사용자의 반응 (예: 배너 클릭, 앱 설치, 푸시 메시지 클릭 등)을 기록하여 서버에 전송합니다.

Data Processing

SDK를 통해 전송되는 데이터를 실시간으로 수집하고 분석하여 통계 데이터와 메타데이터를 생성합니다. 이를 바탕으로 해당 사용자의 프로화일에 맞는 캠페인을 실시간으로 매칭 (targeting)합니다. 또한 사용자의 캠페인 반응 데이터 또한 실시간으로 처리하여 통계 서비스를 제공합니다.

SDK Messaging

매칭된 마케팅 캠페인의 컨텐츠를 사용자에게 표시합니다. 저희 서비스는 앱 실행 중에 메시지를 전달하는 인-앱 메시징과 앱을 사용하지 않고 있을 때 메시지를 전달하는 푸쉬 메시징 등을 제공합니다. 인-앱 메시징에서는 interstrial 형태의 이미지, 텍스트 공지사항, iFrame, 그리고 직접 사이즈 설정이 가능한 커스텀 배너 등의 형태로 메시지 전달이 가능하며 푸쉬 메시징에서는 APNS (Apple Push Notification Service), GCM (Google Cloud Messaging) 등을 통해 텍스트 형태의 푸쉬 메시지를 전달할 수 있습니다. 모든 메시지는 여러 개의 언어로 생성이 가능하며 단말의 주언어 설정에 따라 사용자별로 맞는 언어로 메시지가 전송됩니다. (예. 일본어 사용자에게는 일본어 메시지가, 한국어 사용자에게는 한국어 메시지가 자동으로 전달됩니다.)

User Behaviour (Response)

타겟팅된 사용자가 자신에게 전달된 메시지에 반응해서 앱을 더 많이, 더 오래 사용하도록 하는 것이 저희 시스템의 목적입니다. 마케터가 의도하는 긍정적인 방향으로 사용자들의 행동 변화를 일으키도록 하는 것이 바로 Engagement 서비스의 목표입니다. (예. 관심이 떨어진 사용자가 다시 앱을 사용하도록, 한번도 아이템을 구입하지 않은 사용자가 아이템을 구매하도록)

 

Tech Planet 2013 Booth slides.003

저희 시스템은 아마존 웹 서비스 (AWS) 상에서 운영되고 있으며 전세계로부터 들어오는 트래픽을 처리하기 위하여 Cloud Front, Route 53, EC2 Auto Scaling 등 다양한 AWS의 기능들을 적극적으로 활용하고 있습니다. (저희 시스템에 AWS를 어떻게 활용하고 있는지에 대해서는 이후 포스트를 통해 공개할 예정입니다.)

우선 SDK에서 API 서버로 request를 보내면서 수집한 사용자 데이터를 전달합니다. API 서버에서 실시간으로 데이터를 처리, 저장하는 동시에 캠페인 매칭을 처리하고 적합한 캠페인이 존재하는 경우 해당 컨텐츠의 metadata를 SDK로 전송합니다. SDK는 전송 받은 metadata를 이용해서 CDN (Cloud Front)으로부터 컨텐츠를 내려받아 앱 사용자에게 표시합니다. 사용자가 화면에 표시된 메시지에 대해 반응을 보이면 SDK는 Tracking Server로 해당 데이터를 전달합니다.

각 서버가 데이터를 저장하는 과정에서 실시간으로 처리할 수 있는 데이터와 그렇지 못한 데이터를 구분합니다. 실시간 처리가 가능한 데이터는 바로 데이터베이스에 그렇지 못한 데이터는 Message Queue를 통해 Data Processing Server와 Worker 들에게 전달됩니다. 이후 해당 데이터들은 각 특성에 맞게 SQL DB, No SQL DB, Hadoop Cluster 등의 데이터베이스에 저장됩니다. (Big Query는 위 그림에 없으며 AWS가 아닌, Google Cloud 상의 서비스입니다.)

마케터는 웹브라우저를 통해서 직접 캠페인을 설계하고 수정하고 실행할 수 있으며 통계 데이터를 실시간으로 확인할 수 있습니다. Application Server는 각종 데이터베이스 및 캐시를 조회하여 마케터에게 원하는 정보를 실시간으로 표시합니다.

Tech Planet 2013 Booth slides.004

실시간 데이터 수집

SDK에서 올라오는 request 중 반드시 저장되어야 하는 트랜잭션 데이터는 MySQL에 저장하고 그 데이터를 기반으로 가공되는 데이터는 각 특성에 맞는 데이터베이스에 저장합니다. 장애상황을 대비하여 시스템 이중화, Message Queue 등을 운영하고 있습니다.

실시간 캠페인 매칭

최신의 데이터를 사용하여 사용자 프로화일에 맞는 캠페인을 실시간으로 매칭합니다. 다양한 캐시 및 NoSQL 데이터베이스를 이용하여 보다 빠른 캠페인 매칭이 가능하도록 구현되어 있습니다. 주어진 조건에 가장 최적화된 쿼리를 생성하기 위해 Dynamic Query Builder를 구현하여 사용하고 있으며 다차원 조건을 조회하기 위한 캐시를 생성하여 이용하기도 합니다.

실시간 통계

incremental counting이 필요한 데이터의 경우 Redis를 이용함으로써 Dashboard를 통해 실시간 통계를 제공합니다. 또한 통계를 위해 필요한 metadata를 캐싱해서 보관함으로써 실시간 통계를 제공할 수 있습니다. Redis 데이터의 정합성을 보장하기 위하여 주기적으로 배치 프로세스를 실행하여 정합성 검사 및 보정 작업을 진행합니다.

준-실시간 통계

실시간으로 분석을 제공할 필요가 없는 데이터들은 모두 주기적인 배치 프로세싱을 통해 처리하고 있습니다. MySQL 또는 Couchbase에 저장된 데이터를 이용하여 통계 데이터를 추출하고 있으며 Big Query를 이용하여 이벤트 로그 분석 시스템을 구현하였습니다. 이렇게 1차로 분석된 데이터를 바탕으로 2차 가공하기 위해, 또는 빠른 데이터 조회를 위해 No SQL 서버들을 이용하고 있습니다.

 

Tech Planet 2013 Booth slides.005

저희 시스템이 작은 양의 데이터를 처리한다면, 그리고 실시간으로 처리할 필요가 없다면 이렇게나 다양한 데이터베이스를 운영할 이유가 없습니다. 실제로 저희도 서비스 초기에는 MySQL과 memcached만으로 실시간 분석 및 매칭 서비스를 제공하는 것이 가능하였고, 운영 비용도 훨씬 적게 구축할 수 있었습니다. 하지만 월 6억 건의 이벤트 request를 처리하고 수천만 건의 사용자 프로화일 데이터를 처리해야 하는 상황에서는 다른 방법을 찾을 수 밖에 없었습니다. SDK의 request를 실시간으로 처리하기 위해 각 데이터 처리에 최적화된 데이터베이스들을 선택해야 했고 많은 검증 과정을 거쳐 그에 맞는 데이터베이스를 선정하여 실시간 데이터 프로세싱을 구현하게 되었습니다.

MySQL

저희 시스템의 가장 기본이 되는 데이터베이스로써 정적인 데이터 (앱, 캠페인, 콘텐츠 정보 등)를 저장하며 SDK의 request인 트랜잭션 로그를 저장하는 데 이용합니다. 반드시 저장 및 조회가 보장되어야 하는 데이터들에 한하여 MySQL을 이용하고 있습니다.

memcached

각 서버 간의 공유되어야 할 기본적인 캐시 데이터들을 저장합니다. 업데이트 빈도가 그리 높지 않은 데이터에 한하여 in-memory cache를 이용한 빠른 데이터 접근을 위해 사용합니다.

Redis

카운팅이 되어야 하는 모든 레코드를 저장하고 조회하는 데 이용합니다. 그 외에도 업데이트가 빈번히 일어나는 데이터는 Redis를 통해 캐시를 생성하여 이용합니다. 이밖에도 SortedSet 형태의 데이터를 효율적으로 저장, 업데이트하기 위해 redis를 이용하고 있습니다.

Couchbase

사용자 프로화일 및 조건별 세그먼트 저장을 위해 이용하며 주요 사용자 프로화일 분석이나 실시간 캠페인 매칭에도 이용하고 있습니다. 또한 별도의 1차 데이터 프로세싱의 결과값을 저장함으로써  2차적인 데이터 가공 및 빠른 조회가 가능합니다.

Big Query

수집되는 이벤트 로그를 통해 준-실시간 배치를 제공하기 위하여 사용합니다. 구글 클라우드 플랫폼을 활용하여 대용량 데이터를 편리하게 분석할 수 있습니다. 특정 주기마다 수집된 이벤트 로그를 등록하고 배치 프로세싱을 통해 데이터를 가공하여 그 결과를 다른 데이터베이스에 저장합니다.

이 글에서는 데이터의 특성을 기준으로 저희가 사용 중인 데이터베이스들을 정리하였지만, 데이터의 특성 이외에도 데이터가 어떠한 형태로 해당 서버에 저장되는지, 얼마나 최적화된 쿼리를 이용하는지 등 다른 많은 요소들이 데이터베이스의 성능에 크고 작은 영향을 끼치고 있습니다. 이러한 점들을 잘 고려하여 알맞은 데이터베이스를 선택하여 이용하는 것이 중요합니다. 그 과정에서 데이터를 다른 서버로, 다른 데이터베이스로 옮기는 마이그레이션 작업이 빈번하게 일어납니다. 그 날은 Sleepless in Seoul이 되겠죠.

 

마치며…

최근 국내외에서 데이터 처리 기반의 서비스들이 다수 나오면서 여러 팀들이 자신들의 경험을 공유해 주셨습니다. 저희도 이러한 포스팅들을 통해 많이 배워 가고 있으며 작지만 저희들의 경험과 생각도 함께 공유하고자 이 글을 쓰게 되었습니다. 아무쪼록 다른 분들에게도 도움이 되었으면 합니다.

어떤 시스템의 구조가 다른 목적을 가진 서비스에 100% 적합할 수는 없다고 생각합니다. 자신들이 만들고 있는 Product를 완벽히 이해하고 그에 가장 적합한 구조를 설계하고 구현해 나가는 것이 정답이 아닐까 합니다.

그런 의미에서 저희 팀은 다양한 시각에서 Product에 대해 고민하고 그에 맞는 시스템을 구축하기 위해 노력하고 있습니다. 최근 저희 트래픽이 급증하는 추세를 보이면서 이러한 고민도 점점 늘어나고 있는데요, 함께 고민하고 함께 문제를 해결해 나갈 엔지니어분들을 찾고 있으니 많은 관심을 부탁드립니다.

 Posted by at 5:30 PM
Nov 102013
 

최근에 지인분께서 저희 구인공고 포스팅을 공유해 주셨는데 그 글에 이런 코멘트가 달렸습니다.

Screen_Shot_2013-11-10_at_8.00.47_PM

 

 

코멘트하신 분 입장에서는 아마도 의아하셨을 것 같습니다.  Rails?? Backend??

다른 분들도 비슷한 의문을 가지실 것 같아서 그런 선택을 한 이유에 대해  적어 보려고 합니다.

 

웹서비스를 만드는 데 최적화된 Rails

잘 아시겠지만 스타트업은 6개월 이후를 보고 엔지니어링을 할 수 없습니다. (대개는 그렇습니다.) 우리가 지금 만드는 것이 내일도 가치가 있을지 확신이 없습니다. (있다면 그건 검증되지 않은 자기 확신이겠지요.) 그 가치는 고객의 판단에 의해 인정되고 그런 다음에야 우리는 그 다음 가치를 구현해 나갈 수 있습니다. 그래서 빠르게 구현하고 검증을 받는 것이 가장 중요한 일입니다. 그게 Lean Startup이 일을 하는 방법입니다.

저희는 3년 전 가장 빠른 웹서비스 구현을 위해 Ruby on Rails를 선택했습니다. 덕분에 빠르게 프로토타잎을 만들 수 있었고 중간에 Pivot 또한 빠르게 할 수 있었습니다. 1) RESTful 서비스로 모바일 SDK와 통신을 하고 2) Dashboard가 서비스 가치의 핵심 중 하나인 저희 서비스에서는 올바른 선택이었다고 생각합니다.

언젠가 저희도 Javascript 기반의 Front-end로 넘어간다면 Rails의 가치가 급격히 떨어지겠죠? 그렇게 만들어 주실 Front-end Engineer를 구하고 있습니다.

 

Rails의 성능과 한계

twitter는 Rails로 구현된 전세계에서 가장 큰 서비스였습니다. 그들도 처음 (2006년)에 Rails로 서비스를 시작해서 상당히 오랜 기간 동안 그 첫 선택을 유지해 왔습니다. 그러다 2010년부터 Scala로의 이전을 시작으로 2011년  Java로 이전 등을 통해 점진적으로 이전해 갔습니다. 2011년 3월 11일, 하루에 1.7억개의 트윗이 포스팅될 때에도 서비스의 상당부분은 Rails였습니다. InfoQ의 기사를 읽어 보시면 그들이 어떤 도전을 겪었고 왜 Rails에서 다른 언어, 프레임워크로 이전했는지를 확인하실 수 있습니다.

저희 AD fresca가 twitter가 겪었던 그 변화의 시점에 도달한 것 같지는 않습니다. 그렇다면 저희가 US$10M 펀딩을 받았겠죠?!?! 🙂

twitter가 그랬듯이 저희도 언젠가는 Scala로 넘어가고 언어도 Java로 변경해야만 하는 시기가 올 거라고 생각합니다. 하지만 현재 (한달에 6억개의 API call을 처리하는 지금은)로서는 많은 개발 자원을 투자해야 하는, 더 효율적인 언어/프레임워크 등으로의 이전하기보다는 클라우드 상에서 인스턴스 몇 대를 더 사는 게 더 저렴한 선택이라고 생각합니다. Again, 역시 저희 시스템을 새롭게 바꿔 주실 Back-end Engineer도 구하고 있습니다.

 

하나의 ORM

저희 시스템의 기술적, 비즈니스적 요구사항 중 하나가 ‘1) 데이터 모델을 지속적으로 빠르게 변경해야 하고 2)  하나의 데이터 모델을 여러개의 서로 다른 어플리케이션 서버 (다양한 API 서버, Dashboard, workers 등)에서 사용할 수 있어야 한다‘입니다. 즉 2개 이상의 ORM을 이용해서 데이터 모델을 관리하는 것은 저희 팀이 감당할 수 있는 수준을 넘어섭니다. (최소한 저희 크기의 조직에서는 그렇습니다.) 저희도 초기에 twitter가 Scala로 이전하는 것을 보고 고민을 많이 하다가 하나의 ORM이 훨씬 효율적이라고 판단해서 프로젝트를 드랍했던 적이 있습니다.

하나의 데이터 모델을 여러 어플리케이션에서 사용하기 위해서 저희는 데이터 모델에 대부분의 코딩을 하고 독립된 리파지토리에 별도로 저장, 관리합니다. 그리고 그 리파지토리를 git의 submodule 기능을 이용하여 모든 어플리케이션에서 공용으로 사용하고 있습니다.

 

Rails Forever!

저희는 빠르게 프로토타이핑을 하고 빠르게 서비스를 만드는 데 Ruby on Rails만한 언어-프레임워크 조합도 없다고 생각합니다. 아직은요. 물론 영원한 것은 아무 것도 없으니 Forever는 아닙니다. Rails, we still love you though. 😉

저희가 빨리 성장해서 멋진 기술을 써서 여러분들로부터 환호(!)를 받을 수 있는 날이 오기를 기대합니다.

 

Update: 알고보니 원래 코멘트를 해 주신 분께서는 한국에서 Backend와 Rails를 잘 아는 사람은 구하기 어렵겠다라는 의미로 하신 말씀이었다고 합니다. 저는 Rails 콤플렉스가 있나 봅니다. 흑흑흑. 🙂

Nov 082013
 

AD fresca는 실시간 데이터 처리 기술을 이용해서 실시간 Mobile Engagement 서비스를 제공하는 B2B 서비스 회사입니다. 저희는 고객사인 게임빌, 넥슨, 네오위즈게임즈, 아프리카TV 등의 모바일 게임 퍼블리셔들과 함께  새로운 모바일 세상을 만들기 위해 나아가고 있습니다.

slide_img_2

빅데이터?!

요즘 빅데이터 기술에 대한 관심이 높지만 실제로 빅데이터를 처리해 본 사람은 별로 없습니다. 더 나아가  실시간 프로세싱을 위해 빅데이터 기술과 다양한 컴퓨팅 기술을 활용해서 상용 서비스를 제공해 본 사람은 더더욱 없습니다. 저희 시스템은 한달에 약 6억개의 API 콜을 처리하고 있으며 현재까지 약 30억개의 데이터를 처리해 왔습니다. 성장속도가 보이시죠?

AD fresca에서는 매일매일이 데이터와의 전쟁이고 트래픽과의 싸움이지만 그 짜릿함을 맛볼 수 있습니다.

글로벌 서비스

현재 저희 SDK는 전세계 220개국 2,600만명 사용자들의 스마트폰에 탑재되어 데이터를 수집하고 있습니다. 전세계인을 상대로 하는 서비스를 직접 기획하고 개발하고 운영할 수 있는 기회, 흔하지 않죠?

AD fresca에서는 자신이 개발한 코드를 통해 전세계 사용자들의 삶에 영향을 끼칠 수 있습니다.

저희가 하는 일은
  • Big Data 처리를 위해 데이터 모델링을 하고 실제 DB를 구성, 구현,  관리, 운영합니다. noSQL, SQL 가리지 않습니다.
  • Lean Startup으로서 서비스를 기획하고 구현하고 고객으로부터 피드백을 받아 빠르게 학습합니다.
  • 스크럼을 도입하여 2주 sprint를 실천하고 있습니다. 빠르게 개발하고 빠르게 배우고 빠르게 개선함으로써 지속가능한 혁신을 만들어 나갑니다.
  • 클라우드와 다양한 최신 기술들을 이용하여 모든 서비스를 자동화함으로써 24/7 무중단 시스템을 운영하고 있습니다.

AD fresca에서는 ‘선수’들과 함께 ‘린 스타트업’ (Lean Startup)을 실천할 수 있습니다.

이런 분을 찾고 있어요!

저희와 함께 멋진 글로벌 서비스를 만들어서 세상에 자랑하고 싶은 분을 찾고 있습니다.

저희는 Front-end, back-end, mobile SDK 등 다양한 분야의 기술을 조합해서 복합 서비스를 만들고 운영합니다. 자신이 잘하는 하나의 분야가 있고 기본기와 열정이 있다면 지원해 주세요.

현재 최우선적으로 찾고 있는 분야는 아래와 같습니다.

Front-end engineer
  • CSS, HTML, jQuery를 잘 다룰 수 있어야 합니다.
  • UI와 전체 워크플로우에 대한 고민(!!)을 가지고 있어야 합니다.
  • Rails를 잘 아신다면 +++
  • Database (SQL, noSQL)에 대해 잘 아신다면 +++
  • 모바일 게임 또는 앱을 만들어 봤다면 +++
Back-end engineer
  • 최소한 자신만의 언어 한가지는 우물 파신 분이어야 합니다.
  • 다양한 Database (SQL, noSQL)를 잘 다룰 수 있어야 합니다.
  • API 개발에 대한 이해도가 높으면 +++
  • 모바일 환경에 대한 이해도가 높으면 +++
  • Rails를 잘 아신다면 +++
  • 모바일 게임 또는 앱을 만들어 봤다면 +++
공통조건
  • 학력, 경력 조건 없음
  • 병역의무 해제 필수 (성별로 해제하신 분은 우대!!)
  • 영어자료 독해능력 필수
  • 다른 사람들과 대화 능력 필수
  • 친근한 것과의 결별, 새로운 것으로의 도전을 마다하지 않는 열정
근무 조건
  • 역삼역 사무실
  • 식사 제공
  • 10시 반 ~ 7시반 (그 이전에 출근해서 미리 퇴근 가능)
  • 급여는 내부 가이드라인에 따라 협의 후 결정합니다.
지원 방법
  • 자신을 잘 설명할 수 있는 내용을 보내 주세요. 규격이나 양식은 없어요
  • 하지만 지원자가 어떤 사람인지 안 가르쳐 주고 뽑아 달라고 하시면 곤란하겠죠?
  • 이메일로 지원: dano@adfresca.com (이의정, CEO)
 Posted by at 9:01 PM