안드로이드 개발자인 내가 항상 필요하다고 갈구하는 부분은 백엔드 개발이었다.기획에서부터 디자인, 안드로이드 개발까지는 혼자 진행하지만 대부분의 서비스에서 필요로 하는 서버를 전혀 다루지 못했기 때문에 혼자서 진행할 수 있는 프로젝트는 유틸성 어플리케이션까지로 굉장히 한정적이었다.그래서 매번 개인 프로젝트를 기획할 때마다 백엔드 개발의 필요성을 느꼈고 이제야 시작해보려고 한다.'안드로이드는 앱을 개발하기 위해서 배워야 하는 언어와 개발 툴은 Java와 Android Studio다.'라고 말할 수 있을 정도로 선택의 폭이 넓지 않은 것에 비해 (최근에서야 코틀린이나 리엑트 등이 생겨나 선택권이 많아 지긴 했지만 웹이나 서버에 비한다면..) 서버는 너무나 방대한 선택지에서부터 어려웠다. 그래서 검색과 주변의 추천을 통해 선택지를 추려나갔는데 주변에 물어보는 족족 Node.js(이후 '노드'로 통칭)를 언급하길래 어느 정도 노드로 가야겠구나 마음먹고 어떤 언어인지 알아보았다.먼저 노드의 장점이다.1. 노드의 가장 특징적인 부분인 이벤트 기반 비동기 방식으로 단 하나의 스레드만 생성하여 일을 처리한다. 그러므로 메모리와 같은 시스템 리소스 사용량에 큰 변화가 없어 대규모 네트워크 프로그램을 개발하기 적합하다.-> 사실 이 장점에 있어서는 아직 내가 서버 개발을 했던 사람이 아니기에 얼마나 큰 장점인지 체감되지는 않는다.2. 자바스크립트를 사용하여 개발할 수 있다.-> 이 부분이 내가 노드를 택하게 한 가장 큰 이유다. 이게 왜 큰 이유냐고 할 수 있겠지만 최근 자바스크립트 언어를 이용한 굉장히 다양한 프레임워크들이 등장하고 있다. 어차피 웹 개발이나 하이브리드 어플리케이션 개발을 시작할 때 배워야 하는 언어이기에 이왕 배울 거 활용성 높은 언어가 좋지 않은가. 효율을 가장 중시하는 나에게는 가장 큰 장점으로 느껴졌다.3. 노드는 구글이 만든 자바스크립트 엔진인 V8을 사용한다.-> 브라우저들끼리 경쟁하며 자바스크립트 엔진 속도를 발전시키는 과정에 있으며 구글 또한 V8 자바스크립트 엔진 속도를 위해 노력하고 있다. 이번엔 노드의 단점이다.1. 하나의 스레드만을 사용하기 때문에 하나의 작업이 지연된다면 시스템 전체의 성능이 저하된다.2. 에러가 발생할 경우 프로세스 자체가 죽어버리므로 주의해야 한다.아직 잘 모르기 때문에 얼마나 크리티컬 한 단점인지는 잘 실감이 나지 않는다. 단점에 대해서는 직접 개발해보면서 느껴봐야 할 것 같다.아무튼 이러한 이유로(사실 자바스크립트의 이유로) 노드를 택해서 공부하기로 했다.이번 주 주말부터 마음 맞는 몇몇의 개발자분들과 같이 스터디도 시작!빠르게 노드를 배워나가면서 AWS로 서버 구축하는 방법까지 익히면서 실무 프로젝트를 진행할 수 있도록 방향을 잡았다.배워나가는 것과 과정들을 꾸준하게 포스팅할 예정이다. 화이팅하자!참고문헌:모던 웹을 위한 Node.js 프로그래밍 - 윤인성개발자로 살아남기 (http://118k.tistory.com/197)티스토리 블로그와 동시에 포스팅을 진행하고 있습니다.http://madeitwantit.tistory.com#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유

설레는 마음으로 출근한 회사 첫 날. 프론트의 안내에 따라 자리에 앉았더니 낯선 두 책자가 놓여있습니다. 게임 회사라 그런지 오자마자 퀘스트* 시작!  입사 퀘스트라고 쓰여 있는 게임회사스러운 작은 종이 뭉치와 입사자를 위한 작은 책이 있습니다. 좀 더 재미있어 보이는 입사 퀘스트를 한장 한장 살펴 봅니다. 드디어 실감이 나네요. 전 게임 회사에 취업을 했군요!!!사무실 곳곳을 투어하고 입사 구비서류를 제출하면 첫번째 퀘스트 완료!때묻은 임시출입카드를 획득할 수 있습니다. 입사 퀘스트는 하나하나 퀘스트를 클리어하면서 회사에 필요한 물건들을 획득해 나가는 과정입니다. 각 퀘스트의 보상을 획득해야 다음 보상으로 넘어갈 수 있습니다. 첫번째 퀘스트, 어렵지 않죠?입사자를 위한 작은 책이 바로 입사 키트 입니다. 처음에 두꺼워 보이는 낯선 이 책을 낭랑한 목소리로 친절하고 자세하게 설명해 주는 영상이 바로 입사 키트 영상입니다.입사 키트에는 에이스프로젝트 소개 및 각 팀 소개, 디테일한 업무가이드, 생활 가이드, 복리후생, 행사, 그리고 중요한 보상까지!! 아주 아주 디테일하고 친절하게 안내되어 있어요.  A부터 Z까지 낯선 에이스프로젝트가 점차 가까이 다가오는게 느껴지시나요?  가이드에 나와 있는 대로 그대로 따라하기만 하면 됩니다 질문이 있으면 언제든 프론트로 와서 물어봐주시면 되구요! 약 40분간의 영상을 듣고 Q&A를 마치면 퀘스트 2번째도 완료!업무 보조 아이템이 가득한 웰컴박스를 받을 수 있습니다. 에이스프로젝트에 꼭 필요한 기본 중의 기본템들! 슬랙, 컨플루언스, 구글 캘린더, 프린터 드라이버를 모두 장착했다면 퀘스트 클리어!기획팀이라면 기획팀 스킬을, 그래픽팀이라면 그래픽팀 스킬이 필요합니다. 각 팀에서 사용하고 있는 툴을 장착해 주세요!기획팀, 프론트 QA팀이라면 마이크로소프트 계정 스킬을, 그래픽팀이라면 포토샵, 일러스트레이터, 에프터이팩트 등의 스킬을 꼭 장착해야 합니다.  스킬을 모두 잘 달았다면 없는 것 빼고 다 있는 에이스 박스 1개를 획득하였습니다. 이제 도착점에 거의 다 와 갑니다.  컴투스프로야구 for 매니저, 9이닝스GM, 직봉총교두를 설치해 봅니다. 에이스프로젝트에서 만든 게임을 잘 안다면, 일도 더 잘 할 수 있겠죠?  본 퀘스트는 모두 완료하였습니다. 그런데 한가지  더! 본 퀘스트보다 더 재미있는 서브 퀘스트가 기다립니다.  본 퀘스트보다 더 재미있는 서브 퀘스트. 사내 엔터테인먼트 시설인 다트, 플스, 오락기, 탁구대를 두루두루 경험하면서 자연스럽게 다른 팀원들과도 즐겁게 얘기할 수 있습니다. 커피 내기에서 이긴다면, 커피는 덤!!!!(하지만 신규입사자에게 자비없는 에이스 다트와 오락기 ㅠㅠ)하나 하나 클리어하는 재미가 있는 입사 퀘스트와 그 안에 들어있는 친절한 입사 키트!자 이제 당신은 진짜 에이스인이 되었습니다.  *퀘스트(Quest): 게임을 원활하게 진행하기 위해 이용자가 수행해야 하는 임무 또는 행동*파밍(Farming): 게임에서 캐릭터의 능력을 상승시키기 위해 아이템 등을 모으는 행위를 농사에 빗대 파밍이라고 부른다.

Hello world!저는 CX서비스실에서 기획을 담당하고 있는 강미경입니다. R&D 그룹의 기술 블로그, 그 영광의 첫 포스트로 개발의 보람을 대신할 수 있어 기쁩니다. 오늘은 ‘기획자가 어쩌다가’ 기술 블로그를 만들게 되었는지 얘기해보려고 합니다.왜 기술 블로그인가제가 야놀자에 입사한 지 만 1년이 되었습니다. 입사하면서 가진 개인적인 목표 중의 하나는 블로그를 운영하는 것이었습니다. 저는 오래전부터 개인 블로그를 운영하고 있고, 외부 커뮤니티 활동에서도 팀 블로그를 운영합니다. 그래서 개발자에게는 기술 블로그에 쓸 글을 작성하는 것보다 코딩을 하는 게 더 쉬울 정도로, 글 쓰는 고통이 남다르다는 것도 알고 있지요.하지만 ‘알고 있다’고 생각하는 정보를 정리하고 그것이 잘 전달될 수 있도록 하는 것은 개발실력과는 약간은 다른 영역의 것이기도 합니다. 그래서 테크 스웩이 넘치는 블로그가 아니더라도, 꾸준히 스토리를 전달하면 그게 개인과 조직의 히스토리로써의 가치가 충분하다고 생각했습니다. 무엇보다 조직 자체의 성장에 큰 밑거름이 되고요.블로그를 시작해보자기술 블로그를 하자는 말에, 놀랍게도 한결같이 ‘관심만’ 주더군요(…) 평소 업무가 많고 바쁨을 떠나서, 보람보단 책임만 남아 유지보수 대상이 되어버릴 가능성이 무궁하지 않겠습니까. 하지만 목마른 사람이 우물을 파라고, 개발자의 도움 없이 블로그를 만들 각오를 하기에 이르렀습니다.(과거의 나를 규탄…#야놀자 #개발팀 #블로그 #인사이트 #경험공유

React + Decorator + HOC = Fantastic!!지난 포스팅에서는 ES7의 Decorator 문법을 이용해 선언된 클래스와 그 프로퍼티들을 디자인 시간에 변경하는 법을 알아보았습니다. 그렇다면 리액트 컴포넌트와 Decorator가 만나면 어떤 시너지가 발생할까요?만약 ES7의 Decorator에 대해 모르신다면 지난 포스팅을 읽고 오시는 걸 권장합니다. 이 포스팅은 독자들이 Decorator에 대해 이미 알고 있다고 가정하고 작성됐습니다.Higher Order Component리액트 공식 문서를 보면 Higher Order Component(이하 HOC)를 다음과 같이 설명하고 있습니다.리액트 컴포넌트 로직을 재활용할 수 있는 고급 기법리액트에서 공식적으로 제공하는 API가 아니라 단순히 아키텍쳐이 설명으로는 HOC가 어떤 역할을 하는지 이해하기는 역부족이기 때문에 간단한 예제를 통해 HOC를 어떻게 작성하는지 알아보겠습니다.function withSay(WrappedComponent) {     return class extends React.Component {     say() {       return 'hello'     } render() {       return (                   {...this.props}           say={this.say} />       )     }   } } withSay 함수는 WrappedComponent를 인자로 받아 원하는 속성들을 결합해 새로운 컴포넌트를 반환합니다. 이렇게 만들어진 withSay 함수는 아래와 같이 사용 가능합니다.@withSay class withOutSay extends React.Component {     render() {     return (               {this.props.say()}           )   } } withOutSay 컴포넌트는 say 메소드를 가지고 있지 않습니다. 하지만 withSay 함수를 사용하니 say 메소드를 사용할 수 있게 됐습니다. 이처럼 컴포넌트를 인자로 받아 입맛에 맞게 바꾼 뒤 새로운 컴포넌트로 반환하는 기법을 HOC라고 부릅니다.그렇다면 HOC는 리액트에서 어떻게 사용을 해야 효율적일까요?Cross Cutting Concerns개발을 하다 보면 다음과 같은 상황에 직면하는 경우가 종종 있습니다.개발 전반에 걸쳐 반복해서 등장하는 로직그럼에도 불구하고 모듈화가 쉽지 않은 로직예를 들어 방명록 작성, 게시글 작성, 게시글 스크랩을 하는 컴포넌트들에서 유저 인증과 에러 처리의 과정이 필요하다고 했을 때 어떻게 코드를 디자인해야 할까요? 컴포넌트와 직접적으로 연관이 없는 기능들이 컴포넌트와의 결합이 너무 강해 쉽게 모듈화를 시키지 못합니다.그림 1. Cross Cutting Concerns의 예시이렇듯 코드 디자인적인 측면에서 공통적으로 발생하지만 쉽게 분리를 시키지 못하는 문제를 Cross Cutting Concerns라고 합니다. 이 문제를 끌어안고 가면 프로젝트의 코드는 쉽게 스파게티가 되고 나중에는 유지 보수를 하기 힘들어집니다.하지만 우리게에는 HOC와 Decorator가 있고 이를 이용해 이 문제를 쉽게 해결할 수 있습니다.유저 인증 문제를 HOC로 해결아래는 인증이 안된 유저에게 다른 페이지를 보여주는 코드입니다.class TeamChat extends React.Component {     constructor() {     super()     this.state = {       unAuthenticated: false     }   } componentWillMount() {     if (!this.props.user) {       this.setState({ unAuthenticated: true })     }   } render() {     if (this.state.unAuthenticated) {       return     }     return I'm TeamChat   } } 유저 인증을 전통적인 if-else 구문으로 구현했습니다. 당장 이 컴포넌트를 본다면 문제가 없어 보입니다. 어떻게 보면 정답처럼 보이기도 합니다. 하지만 유저 인증이 필요한 컴포넌트가 많아지면 상황이 달라집니다.100개의 컴포넌트에서 위와 같은 방식으로 유저 인증을 하고 있는데 유저 인증을 하는 로직이 변경된 상황을 생각해 봅시다. 100개의 컴포넌트 모두 유저 인증 코드를 바꿔야 하는 상황에 직면하게 됩니다. 전부 다 바꾸는 것도 일이지만 실수로 몇 개의 컴포넌트를 수정하지 않을 확률이 농후합니다. 당장에는 간단하지만 잠재적 위험을 안고 있는 위 코드는 아래와 같이 수정되어야 합니다.function mustToAuthenticated(WrappedComponent) {     return class extends React.Component {     constructor() {       super()       this.state = {         unAuthenticated: false       }      } componentWillMount() {       if (!this.props.user) {         this.setState({ unAuthenticated: true })       }     } render() {       if (this.state.unAuthenticated) {         return       }       return     }    } } HOC를 이용해 확장이 용이한 유저 인증 로직이 탄생했습니다!! 이렇게 만들어진 HOC는 아래와 같이 적용이 가능합니다.@mustToAuthenticated class TeamChat extends React.Component {     render() {     return I'm TeamChat   } } @mustToAuthenticated class UserChat extends React.Component {     render() {     return I'm UserChat   } } 기존의 코드와 비교했을 때 코드가 훨씬 간단해진 것을 확인할 수 있습니다. 비단 코드만 간단해진 것뿐만 아니라 아래와 같은 추가 효과를 기대할 수 있습니다.유저 인증 로직이 컴포넌트와 분리가 되어 자신이 맡은 역할에만 집중할 수 있습니다.유저 인증 로직이 바뀌어도 코드를 수정해야 할 곳은 하나의 컴포넌트뿐입니다.예시로 작성한 HOC는 최소한의 코드로만 작성된 예시입니다. 실제 제품에서 사용되기 위해서는 몇 가지 고려해야 할 사항이 있는데 이는 리액트 공식 문서를 참고해주세요.i18n 컴포넌트를 HOC로 작성채널 서비스는 한국어, 영어, 일본어를 지원하기 때문에 번역 기능이 필요했습니다. 초기에는 번역 서비스를 아래와 같이 구현했습니다.@connect(state => ({   locale: getLocale(state) }) class Channel extends React.Component {     render() {     const local = this.props.locale     const translate = TranslateService.get(locale)     return (               {translate.title}         {translate.description}           )   } } 처음에는 위와 같은 방식으로 번역 서비스를 구현하는 것이 괜찮았습니다. 하지만 번역을 제공해야 하는 컴포넌트가 많아지면 많아질수록 중복되는 코드가 많아지는 것을 보고 아래과 같이 HOC를 이용해 코드의 중복을 제거했습니다.function withTranslate(WrappedComponent) { @connect(state => ({     locale: getLocale(state)   }))   class DecoratedComponent extends React.Component {     render() {       const locale = this.props.locale       const translate = TranslateService.get(locale) return (                   {...this.props}           translate={translate} />       )    }   } } 이렇게 작성된 HOC는 아래와 같이 사용이 가능합니다.@withTranslate class Channel extends React.Component {     render() {     const translate = this.props.translate     return (               {translate.title}         {translate.description}           )   } } HOC의 작성 방법은 예시로 작성한 두 개의 HOC에서 크게 벗어나지 않습니다. 이를 응용해 자신의 프로젝트에 맞는 코드를 작성해보세요.중첩 가능한 HOCHOC는 여러 개를 중첩해서 사용할 수 있습니다.. 예를 들어 유저 인증과 i18n 서비스를 동시에 제공하고 싶을 때 두 HOC를 중첩해서 사용하면 됩니다.@mustToAuthenticated @withTranslate class Channel extends React.Component {     render() {     return (               {`Hello!! ${this.props.user.name}`         {translate.title}         {translate.description}           )   } } 마무리이상으로 리액트에서 HOC를 사용할 수 있는 상황과 작성 방법을 알아보았습니다. 본 포스팅에서 다루지는 않았지만 만능처럼 소개한 HOC에도 몇 가지 단점은 존재합니다.Component Unit Test를 할 때 문제가 있을 수 있습니다.HOC를 몇 개 중첩하면 디버깅이 힘들 수 있습니다.WrappedComponent에 직접적으로 ref를 달 수 없어 우회 방법을 사용해야 합니다.비동기 작업과 같이 사용하다 보면 예상치 못한 결과를 만날 수 있습니다.하지만 이러한 단점에도 불구하고 상속을 제공하지 않은 리액트에서 HOC는 많은 문제를 효율적으로 해결해주는 단비와 같은 존재입니다. 유명한 리액트 라이브러리들(react-redux, redux-form 등)은 이미 예전부터 HOC를 사용해 사용자들에게 편의를 제공해 왔습니다. 이러한 라이브러리들과 자신의 프로젝트가 직면하고 있는 문제에 맞는 HOC를 작성해 같이 사용한다면 우아하고 아름다운 설계에 한층 더 다가간 프로젝트를 발견할 수 있습니다.마지막으로 한 문장을 남기고 본 포스팅을 마치도록 하겠습니다.React + Decorator + HOC = Fantastic!!본 포스팅은 2017 리액트 서울에서 발표한 내용입니다. 발표 자료와 발표 영상을 확인해보세요.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지

옐로모바일 최고의 프로라이어 Y가 선정한 직장인이 자주하는 거짓말 BEST 8!(※주의: 여기 나온 거짓말 이제 못씀!)

세상은 외로움을 회피하는방향으로 움직인다"왕따가 왜 무서운 건지 아니?""인간은 혼자일 때가 가장 두렵기 때문이야"사람들이 스마트폰과 SNS에 집착하는것은 누군가의 소식이 궁금해서도 아니고 재미있는 것을 찾기 위해서도 아니다. 외로움이 두렵기 때문이다. 외롭게 보이고 싶지 않기 때문이다.어딘가 소속되고 싶어하는 마음도, 누군가와 사랑하고 싶은 욕망도 그 처절한 외로움을 회피하고 싶어하기 때문이다.사랑은 세상에 나를 이해해주는 누군가가 존재한다는 위안감 때문에 가치가 있는 것이다.남들과 다른 것을 두려워하고, 어딘가 울타리를 벗어난 것에 불안함을 느끼는 것도 그렇게 함으로써 무리에서 벗어난 느낌을 무서워하기 때문이다.공유 경제의 현상으로 공간을 공유하고, 커뮤니티를 강화하는 것도 궁극적으로는 점차 핵가족화 되어가는 사회에서 나 혼자 남겨지는 것에 대한 반대급부 때문이다.모든 현상의 이면에는외로움에 대한 두려움이 숨어있다앞으로는 개인의 전문성만으로도 사회 생활이 가능해지는 1인 기업, 프리랜서, 원격 업무들이 늘어남에 따라 점차 외로움을 벗어나게 해주는 산업이 발달할 수 밖에 없다.애완동물 산업이 엄청난 속도로 커지고 있다는 것과 소규모 모임들, 데이트 만남 서비스가 확대 되어가는 것도 이것을 입증하는 현상들이다.이미 세상은 1인 가구가 보편적인 가정 형태의 하나인 시대가 되었다. 노인뿐만 아니라 비혼의 성인들, 그리고 결혼 생활을 중단한 많은 이들이 곳곳에 1인 가구를 이루고 있다. 인류 역사상 유래 없는 현상이다. 한번도 겪어보지 않은 일들을 마주하고 있기 때문에 사회 시스템은 아직 이 현상을 어떻게 대처해야 할지 준비가 되어있지 않다.그래서 뭐?그렇다.그래서 어쩌라구에 대한 답을 찾아야 한다.스마트폰은 외롭고 고립된 인간에게 무한한 연결을 가능하게 해준 빛이 되었던 것이다. 장소와 시간에 상관없이 누군가와 연결되어 있다는 심리적 소속감에 거리를 거닐면서도 밤에 잠을 이루기 전에도, 사회에서 인정받지 못한 스스로를 가상의 게임 공간에서 강인한 캐릭터로 위안 받는 세상을 이해해야 한다.지하철에서 하루 일과에 찌든 중년의 아주머니조차 줄맞춰 터트리는 모바일 게임에 빠질 수밖에 이유는 허무한 일상과 혼자라는 두려움을 벗어나는 간편한 탈출구이기 때문이다. 세상이 어떤 방향으로진화할 것인지에 대한 해답세상이 빠르게 변하더라도 인간의 본질적 욕망은 변하지 않는다. IT기술을 개발해야 하는 기업이나, 소셜 서비스를 발굴하는 스타트업들이나, 제도를 마련해야하고 정책을 펼치는 정치인들 모두 우리가 한번도 경험해보지 못한 형태의 새로운 고독을 직면해야할 인간의 문제를 심각하게 고민해야 할 것이다.모든 것의 중심에는 인간이 있어야 한다.명백한 것은 행복은 외로움의 반대 방향일 것이라는 것이다.외롭지 말자.

이 포스팅은 총 4부로 이어지며 현재는 4부입니다.1부 : Android, MVC, MVVM, MVP2부 : Android 와 Annotation3부 : AndroidAnnotations 과 MVC4부 : AndroidAnnotations 과 테스트앞선 3개의 포스팅을 통해 AndroidAnnotations 과 MVC 가 view 에 관여하는 동작들이 모두 View 로 분리된 것을 확인할 수 있습니다.이러한 구조덕분에 Model 에 대한 테스트와 View 에 대한 테스트가 명확히 구분지어지게 되었습니다.Test 코드를 작성함에 있어서 View 에 대한 테스트가 다소 어려움이 있다는 것을 감안한다면 Model 에 대한 테스트만 집중할 수 있는 구조가 테스트에 대한 접근을 더욱 쉽게 해줍니다.다음은 앞선 포스팅에서 정의된 코드 중에서 Model 에 대한 테스트입니다.※ 테스트코드는 Robolectric 을 이용하여 작성하도록 하겠습니다.Model Test@RunWith(RobolectricGradleTestRunner.class) public class MainModelTest { private MainModel mainModel; @Setup public void init() { mainModel = new MainModel(Robolectric.application); } @Test public void testGetReleaseState() { // given String version = "3.19" // not yet released // when boolean isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(false)); // given version = "3.18" // released // when isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(true)); } }위와 같이 Model 만 별도로 테스트가 용이해졌습니다.Presenter TestPresenter 에 대한 테스트는 Model 에 대한 테스트와 다릅니다.Activity 에 커플링이 높기 때문에 해당 Activity 를 직접 바인딩해야 합니다.@RunWith(RobolectricGradleTestRunner.class) public class MainViewTest { private MainActivity mainActivity; private MainView MainView; @Setup public void init() { mainActivity = Robolectric.buildActivity(MainActivity.class).create().start().resume().get(); MainView = mainActivity.mainView; } @Test public void testGetVersionText() { // given String version = "3.19" // when MainView.versionEditText.setText(version); // then assertThat(MainView.getVersionText(), is(equalTo(version)); } }Jandi Team은 View 를 테스트하기 위해서 Presenter 와 Activity 의 패키지 Level 을 같은 Level 로 유지하고 있습니다.AndroidAnnotations 에서 DI 를 설정하기 위해서는 해당 변수나 메소드는 최소 Package Scope 로 정의해야하기에 위와 같은 형태의 Field 접근을 볼 수 있습니다.정리AndroidAnnotations 를 활용한 MVC 패턴의 전환의 또다른 이점은 이와 같이 테스트를 명확히 분리할 수 있다는 장점을 주었습니다. 물론 이 방법은 MVVM, MVP 로 구현하였을때보다 나은 형태라 할 수는 없으나 View 에 대한 테스트가 좀 더 용이해진 것이라 생각합니다.※ Activity 는 왜 테스트하지 않나요?MVP 패턴에서 Activity는 Controller 의 모습을 지니고 있습니다. 이는 Unit Test 가 아닌 Behavior 테스트에 가까운 모습이며 다른 방식으로의 테스트코드 구현이 필요하다고 생각합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #개발팀 #기술스택 #일지 #후기 #꿀팁 #인사이트

들어가기전 그냥 생각페이스북은 자전거와 같이 한번 배웠다고해서 평생 잘 할 수 있는게 아닌것 같다.사람들에게 도달되는 방식(알고리즘)도 변하고 유저들이 사용하는 방식도 바뀌는것 같다.과거 사람들의 소식을 알기 위해 페이스북을 사용했다면 지금은 매거진? 원하는 정보 스크랩북? 정도로 사용한다고 한다.목적이 달라지면 그 목적에 맞는 컨텐츠를 제공해야 경쟁속에서 살아남을 수 있겠지.. 고객을 항상 생각하는 마음을 잊지 않아야겠다.상황 설명3월15일 포스팅한 컨텐츠1주2차 어플리케이션 포스팅은 기존 W에 비해 M의 어플리케이션이 어떻게 변했는 지 소개하였다.해당 컨텐츠를 포스팅 하기 전 가설은 "'댓글'이 '좋아요' 보다 도달률(reached)이 더 높을 것!"이다. 이를 확인하기 위해 '댓글'을 더 많이 달 수 있도록 설계를 하였다. 그 요소가 바로 베타테스터 모집이었다. 포스팅에 댓글을 달면 추첨을 통해 무료체험을 진행하는 것이다.컨텐츠 기획지난 포스팅 (제품 디자인)의 독자를 확인하였다. 기존 스위처를 사용하는 사람의 비율이 비사용자 보다 '3배' 더 많았다. 이에 독자는 기존 스위처를 사용하는 사람이라 생각하였다.  "기존 스위처를 사용하면서 사용상 문제점을 얘기했었고, 페이스북에서 새로운 스위처가 출시된다는 소식 을 듣고 기존제품에 비해 달라진 외관을 본 상태에서 달라진 앱 소개를 기다리고 있다."이라고 TPO를 설정하고 고객의 목소리를 상기하니 다음 4가지 내용을 다뤄야겠다는 결론이 나왔다.1.  설치과정 삭제2. 2개의 전원 버튼3. 배터리 용량 상시 확인 가능4. 타이머 기능이번에는 문제 없이 기획을 마무리한 것 처럼 생각했지만 아니었다!문제점1. 목표가 "댓글 늘리기"이면 '누가', '왜' 댓글을 달았는 지 확인하지 않았다. 독자와 TPO를 절실히파악해야 하는데.. 기본이 안되어있다.2. 기획 단계에서 비효율적인 시간이 많다.why? 독자를 파악하는데 시간이 너무 오래 걸린다. 매번 포스팅 마다 고객의 목소리 확인을 0부터 시작하 는 느낌? 해당 내용은 불변하니깐, 자료를 자주 들여다 보고 그루밍하여 고객의 목소리를 통해 얻어진 '감'을 잃지 않도록 하자.컨텐츠 제작이번에도 '카드뉴스' 형식으로 컨텐츠를 만들었고, 다음에는 이러한 부분을 좀 더 신경써서 컨텐츠를 제작하려고 한다.1. 이미지 퀄리티카드뉴스 이미지 중이미지의 상하좌우 부분에 하얀 테두리가 생긴다. 왜인지 모르겠다.. 사소한 부분이라 많은 시간을 투자하지 않아도 괜찮다. 하지만 눈에 계속 거슬려서 확실한 Frame 을 하나 만들어 놓고 앞으로 사용할 이미지를 그 안에 넣어서 깔끔하게 포스팅을 해야겠다.2. 컨텐츠 제작은 1시간내로.컨텐츠 제작은 하면서 점점 빨라질 것으로 믿는다. 그리고 기획이 확실하면 컨텐츠에서 낭비하는 시간이 줄어든다. 3시간내로 기획부터 포스팅까지 마무리 할 수 있도록 시간 단축에 신경쓰자.3. 카드뉴스에 사용하는 PPT form 만들기카드뉴스에서 사용하는 이미지 제작 방식은 그렇게 많지 않다. PPT로 기본 Form을 만들어 놓고 그냥 가져다 쓰면 시간 단축에 도움이 되겠지!결과1. "전 보다 더 많은 댓글을 유도하자!" 라는 목표는 달성하였다. (지난 포스팅 대비 3배 상승) 하지만, 도달률은 훨씬 낮아 우리의 가설은 잘못되었음을 알게 되었다.2. 난 '좋아요'를 누르고 '댓글'도 남길 줄 알았는데, 전혀 달랐다. 좋아요 '50명' .. 댓글 '60명'.. '좋아요'를 누르는건 습관적인 행동이라고 생각했는데, 아닌가 보다.3. '제품 디자인' 포스팅과 '어플리케이션' 포스팅 둘 다 참여한 인원은 16명이다. (어플리케이션 포스팅 전체 인원 중 31% 밖에 안됌) 생각보다 독자 이탈률이 많아 문제 인것 같다. 앞으로의 포스팅은 기존 독자들의 지속적인 참여를 이룰 수 있게 해야할 듯 하다.그 방법은 무엇일까? :)#스위쳐 #Switcher #마케팅 #마케터 #SNS마케터 #SNS마케팅 #인사이트 #페이스북 #페이스북마케팅

안녕하세요. 스타일쉐어에서 서버사이드 개발을 하고있는 김현준입니다. 스타일쉐어의 엔지니어링 블로그의 첫 글에서는 저희 서비스의 스택을 소개하도록 하겠습니다. 사실은 Instagram의 스택과 유사한 면이 많아 글 또한 많이 유사할 것 같네요.서버먼저 스타일쉐어는 서버의 운영 체제로 Ubuntu 12.04 (Precise Pengolin)를 사용합니다. 모든 서버는 아마존 웹 서비스(Amazon Web Services)의 Elastic Compute Cloud(EC2) 위에서 돌아가고 있습니다. 스타일쉐어는 EC2 이외에도 Simple Storage Service(S3)와 같은 AWS의 다양한 서비스를 사용하고 있는데요, AWS를 사용하는 가장 큰 이유는 유연한 확장성(Scalability)이라 말할 수 있을 것 같습니다. EC2의 서버는 모두 가상 머신이기 때문에 관리 콘솔에서의 쉬운 조작으로 서버를 끄고 켤 수 있을 뿐만 아니라, 장애가 생겼을 때도 간편하게 장애가 생긴 서버를 내리고, 새로운 서버로 대체할 수 있는 이점이 있습니다. 이 모든 기능은 API로도 제공되고 있기 때문에, 자동화도 가능합니다. 실제로 스타일쉐어에서도 웹 요청을 처리하는 웹 서버들과 작업을 처리하는 워커들에 대해서 오토-스케일러를 구현해 사용하고 있습니다.로드 밸런싱스타일쉐어의 웹 서버들은 AWS의 Elastic Load Balancing(ELB)에 등록되어 있어서 ELB가 수많은 요청들을 여러 서버들에게 차례로 나누어 보냅니다. 보내어진 요청들은 각각의 서버에서 nginx를 거치며 또 한번 여러 개의 프로세스로 분배되어 처리됩니다.웹 어플리케이션스타일쉐어의 웹 어플리케이션은 Werkzeug 기반의 웹 프레임워크 Flask와 ORM 프레임워크인 SQLAlchemy 위에서 Python으로 구현되어 있습니다.데이터스타일쉐어의 대부분의 데이터는 PostgreSQL에 저장되고 있습니다. 여러 대의 PostgreSQL 인스턴스의 풀링(Pooling)을 하기 위해서 pgpool을 사용합니다. 서비스의 성능 향상을 위한 캐싱 도구로는 Memcached를 사용합니다.스타일쉐어에 올라오는 사진들을 비롯한 대부분의 이미지들은 Key 기반의 스토리지인 AWS S3에 저장하고, 관리합니다. S3의 가장 큰 장점은 사용자가 용량 제한과 파티셔닝에 대해 신경쓰지 않아도 된다는 점일 것입니다. 앞으로도 무한히 많은 사진이 올라올 서비스를 만드는 저희로서는 아주 유용하답니다. 이미지 뿐만 아니라, 서비스를 배포할 때마다 만드는 패키지와 매일매일 데이터베이스 백업 모두 S3에 저장되어 있습니다.작업 관리대부분의 서비스와 마찬가지로, 스타일쉐어도 웹 어플리케이션 서버와 별개로 무거운 작업(Task)을 처리하기 위한 워커(Worker) 서버를 따로 구동하고 있습니다. 여기서 작업이란 계속해서 쏟아지는 웹 요청을 처리하기도 벅찬 웹 어플리케이션에서 처리하기에는 비교적 오래걸리는, 예를 들면 알림(푸시)과 메일을 보내거나, 이미지 프로세싱과 같은 일들을 이야기합니다. 이러한 작업들을 비동기적으로 처리하기 위해 저희는 Celery와 RabbitMQ를 사용합니다. Celery는 Python으로 구현된 비동기 작업 워커이고, RabbitMQ는 워커로 넘길 작업을 관리하는 AMQP 프로토콜 기반의 브로커(Broker) 큐입니다.오픈 소스?스타일쉐어 서버는 비동기 네트웍(asynchronous I/O)을 구현하기 위해서 gevent를 사용합니다. 그 외에 배포(deploy)를 위한 Fabric과 boto나, 내부 문서화를 위해 사용하는 Sphinx 등이 스타일쉐어에서 주로 사용하는 라이브러리/프로젝트 입니다.오픈 소스.위에 적은 것처럼, 스타일쉐어의 구현의 많은 부분이 오픈 소스 프로젝트에 크게 의존하고 있습니다. 훌륭하고 건강한 오픈 소스 생태계 덕분에 우리는 스타일쉐어를 훨씬 더 수월하게 만들고 지탱할 수 있었습니다. 그래서 저희도 도움을 받은 만큼 기여하고, 구성원으로서 더 나은 생태계를 만드려 합니다. 그 중 하나가 바로 이 스타일쉐어 엔지니어링 블로깅 활동이고, 다른 하나가 저희 팀의 오픈 소스 프로젝트 활동입니다. 스타일쉐어 팀의 오픈 소스 활동들은 StyleShare’s GitHub에서 살펴보실 수 있답니다. 여러분들의 관심어린 피드백과 기여도 언제나 감사히 환영합니다.그 외의 도구들스타일쉐어 실 서비스에서 발생하는 오류와 버그를 추적하기 위해 사용하는 Exceptional도 매우 유용합니다. Flask 프레임워크에서 Exceptional 서비스를 쉽게 이용할 수 있도록 도와주는 Flask 확장 모듈인 Flask-Exceptional이 공개되어 있습니다.함께해요저희와 비슷한 환경에서 개발하시는, 같은 도구를 사용하시는, 저희에게 도움을 주고 싶으시거나, 저희에게 (저희가 도와드릴 수 있다면) 도움을 받고 싶으신, 또는 그저 많은 이야기를 나누고 싶은 분들까지 많은 분들과의 소통과 교류가 많았으면 좋겠습니다. IRC를 하시는 분들은 오징어 네트워크(irc.ozinger.org)의 #styleshare-tech 채널로 놀러오세요.#스타일쉐어 #개발 #서버개발 #서버환경 #업무환경 #개발자 #인사이트

[라이더소개 #14. 아띠의 화석라이더(그리고 초통령), 잭슨]잭슨을 소개합니다! :)Q1.간단한 자기소개 부탁해!안녕하세요.아띠인력거를 사랑해주시는 여러분,라이더 잭슨이라고 합니다.반갑습니다.    이인재 대표(IJ)와 친구이기도 하고 아띠인력거라는 이름이 없을 때부터 함께해온 라이더이기도 해.그것때문에 어떤 라이더들은‘화석 라이더’라고 하는데 그럴 때마다 참 부끄러워지더라구(웃음).    본업은 프로그래머라 주중에는 회사에서 프로그래밍 일을 하고,주말에는 자주자주 북촌에 나와서 손님을 만나고 있는 중이야.Q2.잭슨이 라이딩을 시작한지 벌써 햇수로 한3년정도 된 것 같은데,인력거 처음 탔을 때는 어땠어?그리고 현재와 비교하면?   인력거 처음 탔을 때는 지금보다는 더운8월이었는데,예전 원남동 사무실의 그 풍경이 기억나.종묘 옆이라 그런지 고요하고 평화로운 느낌과 다른 서울과 달리 이 곳에서 시간은 느리게 가는듯한 느낌이었어.그런 사무실에서 인력거를 끌고 북촌에서 왔을 때는 그 풍경들과 인력거 주위에 돌아가는 모든 것들이 비슷했었어.인력거를 직접 모는 나의 생각과 인력거를 처음 마주하는 사람들과 언제 봐도 좋은 북촌의 모습들이 너무 조화로웠었지.    물론 첫 손님을 태우고 나서는 그런 느낌들은 사라지고 지옥이 시작되었지만 말이야(웃음).아무 생각 없이 건장한 커플을 태우고 계동길을 올라가는데 갈수록 힘들어져서 중간쯤 가니깐 말도 못하겠더라고.결국 그 손님께서는 중간에 내리셨어(웃음).   아무튼, ‘육체의 힘듦’과‘정신의 힐링’이 묘한 조화를 이룬다는 게 인력거를 처음 탔을 때의 나의 가장 큰 느낌이었어.물론 지금도 그 생각은 변함이 없지.아띠인력거가 회사로서의 체계를 잡기도 하고 라이더도 훨씬 많아지고 북촌에 사람들도 더 많아지고 내가 소개할 수 있는 코스들도 더 많아지고 참 많은 것들이 좋아졌는데 인력거를 처음 탔을 때의 그 즐거움도 그대로야.너무 다행스럽게도!Q3.그렇게 오랫동안 꾸준히 나올 수 있는 비결?내지는 원동력은 뭐야?인력거 타는 거 자체가 너무 재미있어서 계속 나올 수 있는 것 같아.그리고 라이더로 만나는 사람들 모두 너무 재미있고 착하고 나에게 많은 영감을 주고 있어.사람이 나이가 들고 시간이 흐를수록 친구 사귀기가 어려워지는데,나는 아띠인력거에 와서는 그 흐름이 역행하고 있지.그리고 손님들과 만나는 시간도 어찌나 소중한지 몰라.솔직히 길가던 사람에게 인사하면 무슨 취급 당할지는.. 대충들 알지? ‘쟤는 외국에서 살다 왔나?정신이 좀 이상한가?’이런 생각들 할 텐데, 인력거에 타고 길가던 사람들에게 인사해도 모두 웃으면서 받아줘. 그래서 낯선 사람을 대하는 자신감도 매우 높아지고 처음 보는 손님과도 웃고 떠드는 게 가능해지니, 나에게 인력거는 마치 마르지 않는 보물상자 같은 존재야.이런 보물상자를 쉽게 포기 할 순 없다 보니 계속 나왔는데, 그러다 보니 벌써3년이나 지났네!Q4. 잭슨은아띠인력거의 초통령으로 불리는데..ㅎㅎㅎ이유가 뭐야?난 교회에 다니는데 매주 교회에서 유년부(초등학교1~2학년)에서 교사를 하고 있어.그 나이 때 애들이 나는 제일 귀엽더라고.피부도 뽀얗고 애기 같은데,또 말도 잘하고 자기 생각도 있고 하니까.근데 또 장난도 잘 치고 하니 그 나이 때 초등학생들 다루는 스킬이 해가 갈수록 늘었었는데 인력거 타러 와서 실력발휘를 좀 하니 자연스럽게 초통령이라는 별명을 얻게 된 거 같아.내가 정신연령이 좀 어린지 애들이랑 얘기도 잘 통하고(또 초등학생 농담을 매우 잘 받아줌),같이 노는데 어려움이 없으니 좀만 더 있으면 초통령이 아니라 '초황제'가 될 것만 같아.나라라도 하나 세워야 하나?하하하.Q5.어린이 친구들과 함께 투어할 때 잭슨만의 노하우가 있다면?우리 초등학생들을 대할 때는 다른 거 없이 그 아이들의 눈높이에 맞춰 주는 게 나의 비결이야.초등학생들이 자기 생각도 있고 말도 잘하긴 하지만 어른들이랑은 확실히 달라.아직 맘도 많이 여리고 하고 싶은 것도 많고 그렇거든.혹은 속으로는 그렇지 않은데 겉으로는 센척한다거나 짓궃은 장난치는 경우도 있고 보통 그럴 땐 따듯한 관심을 바라는 거거든.그럴 때는 어른의 생각으로 대화하면 서로 맘만 상하니, 먼저 아이들의 시선으로 먼저 생각하고 대화하면 아이들과 자연스럽게 대화할 수가 있어.아이들이 감정적이라고 어른이 똑같이 그러면 너무 어른스럽지 못한 거 같지 않아?그리고 아이들에게 어떤 설명을 해줄 때는 최대한 아이들이 이해하기 쉽게 하는 나의 스킬이 있지.말투도 매우 달라지고(초딩 빙의). 진짜 궁금하면 모두들 애기들 데리고 제가 모는 인력거 타보세요!!(웃음)Q6.가장 기억에 남는 손님은?처음 투어를 해드렸던 모녀가 제일 기억에 남아. 30분 투어였는데 나도 그때는 북촌을 잘 모를 때였는데 둘이서 어디 갈지도 모르고 쩔쩔 매고 있어서 인력거에 태우게 되었어.앞에도 말했듯이 나도 잘 몰랐지만IJ랑 돌아다니면서 들었던 지식에 나의 상상력을 더해서1시간 정도 태워드렸지. 요령 없이 태워드려서 중간에 퍼질 뻔 했었지만 두 분 다 너무 좋아하고 나도 만족스러웠던 첫 투어였어. 기부나 선행을 하고 드는 기분과 비슷한 기분이 들었었어.물론 돈을 받고 태워드린 거지만,모녀에게 남들과 다른 조금은 특별한 저녁을 선물할 수 있었거든.Q8.아띠인력거가 어떤 모습으로 나아갔으면 해?지금의 모습을 먼저 꾸준히 잃지 않고 이어나갔으면 좋겠어.물론 여러 가지 보완하고 고치고 또 발전해 갈 것들이 산더미 같이 있지만, IJ같은 창업자나 나 같은 라이더나 그리고 우리를 이용해왔던 손님들이 공유해왔던 가치는 아띠인력거라는 이름이 남아있을 때까지 지키고 싶거든. 인력거와 함께하면 누구나 행복하고 즐거울 수 있다는‘절대 가치’,이걸 잃어서는 안 된다고 생각해.포인트는‘재미있을 것’과‘행복할 것’이야!Q9.잭슨에게 아띠인력거란 어떤존재야?이제는 나의 삶의 일부분과도 같지. 20대의 후반과30대의 초반을 함께 하고 있으니 잊을 수 없는 기억이 될 거기도 하고,북촌과 옛 서울에 대한 것들도 알게 되었고 등한시 했던 역사도 배울 수 있었어.친구들도 사귀고 여러 좋은 멘토 같은 사람들도 많이 알게 되었지.와 너무 많다(웃음).또,언제나 타러 오면 주중에 쌓인 스트레스를 풀 수 있고 말이지.힘 닿는 데까지 함께 하고 싶어.Q10.미래의 아띠라이더들에게 한마디 한다면?먼저 인력거를 끌러올 라이더들 모두 환영하고 잘 부탁해!몸은 조금 힘들지 몰라도 아마 정말 소중한 기억들을 얻어가게 될 거야.그리고 우리가 이어가고 싶고자 했던 것들을 와서 이어가겠다고 하니 너무 고마워!!아띠인력거의 살아있는 역사, 잭슨의 두번째 인터뷰였습니다!잭슨의 '재미있고, 행복한' 라이딩이 계속되길 응원하며 인터뷰를 마칩니다. :)#아띠라이더스클럽 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화 #사내문화

[자서전1#]간혹 또래 친구들, 동생들, 주변 사람들을 보면 과연 본인 스스로 자신의 인생을 정의하고 있는지 부모님이 시키는 로봇처럼 인생을 살아가는지 헷갈릴 때가 많다. 그 선택의 요소가 직업일 때도 있고 사소한 의사결정일 수도 있고 결혼일 때도 있고.그러한 것들을 가만히 보고 있자면 자신의 선택에 대해 용기가 없는 것을 부모님 둘러대는 것도 있는 것 같다. 나 또한 한국 사회에서 한국의 전형적인 부모님의 잔소리에서 벗어날 수 없다. 굉장히 안정지향적인 얘기들과 돈 중심적인 얘기와 단기 성과 지향적으로 얘기를 한다. 그런 점들을 보면 답답할 수 밖에 없다. 솔직히 한심하게 생각하는 경우도 많다. 부모로서 지금 이 상황에서 본인 스스로 생각이라는 것은 좀 하고 말하는건가..? 이런 생각이 들 때도 있고.. 근데 어쩔 수 없는 부분도 있는 것 같다. 살아가는 목적(목표) 자체가 달랐기 때문이라고 생각한다. 부모님들 세대는 상대적으로 먹고 살기 위해 일을 했고(꿈과 목표를 가졌고) 우리는 다소 꿈이라는 것을 이루기 위해 목적 의식을 가지고 일을 하는 젊은이들이 많아졌기 때문이다. 우리에게 필요한 것은 기성 세대의 지혜와 경험이라는 아름다운 언어로 포장된 것이 앞으로의 우리 선택의 마냥 옳은 근거가 될 것이다라는 논리로 받아들일 것이 아니라 그 속에서도 무엇이 잡음이고 무엇이 잡음이 아닌 양질의 피드백이 되는지 구별할 줄 아는 스스로의 힘을 가지고 있어야 한다. 이때 '힘'이란 스스로의 사고력이며 스스로의 힘으로 생각할 줄 아는 상상력이다.인생은 자기 스스로 목적 의식을 만들고 더 큰 것을 꿈꿔나가며 비현실적인 환경을 설계하고 거기에 끊임없이 스스로 적응시키면서 그렇게 불편한 상태에 자꾸 적응할 수 있도록 자아 동기부여시키며 이런 일련의 과정들을 통해 더 큰 우주의 세계로 한걸음씩 나아간다. 우리의 인생은 우리 스스로 정의하고 증명해야된다. 의미와 메세지는 내가 만드는 것이고 내가 만들어야되는 세상과 하고 싶은 이야기를 할 수 있는, 단 한번만 주어지는 시간이 바로 인생이다. 내 가슴을 정말 뜨겁게 만들고 아침에 일어났을 때 설레게하고 두근거리게 하는 그것이 무엇인가.돈돈돈 거리며 단기 성과 지향적이며 안정 지향적인 얘기를 하기에는 이미 시대가 많이 바뀌었다.우리의 꿈을 짓밟는 그 누군가가 있다면 왜 그것을 불가능하다고 말하는지 다시 역으로 강하게 물어볼 것이다. 왜 불가능한지 증거를 대보라고. 그들은 우리의 꿈을 담을만큼 그릇이 크지 않다. 그 이유뿐이니 자기의 길을 묵묵히 해낼때까지 걸어나가는 것이 정도의 길이다.장담한다.열정적으로 꿈꾸고 꾸준하게 행동하며 성공할 때까지 포기하지 않는 놈이 결국 증명한다.#페오펫 #peopet #열정 #스타트업 #운영 #창업가 #마인드셋 #인사이트 #신념

상품은 브랜드를 입증할 증거일 뿐일반적으로 좋은 아이디어라고 생각하는 상품을 만들고, 거기에 훌륭한 디자인과, 마케팅을 잘 하면 성공할거라 믿는다.아니, 성공할 수도 있다.단 거기까지만...브랜드는 상품이나 서비스를 알리는 것이 아니라, 나만의 얘기를 전달하는 것이다. 남들과 다른, 그리고 기억할만한 이야기를 전달하는 것이다.딱 하나이면 충분하다.딱 한 줄이면 충분하다.브랜드는 상품이 아니라, 메시지대단한 이야기가 아니라, 명확한 메시지면 된다. 그리고 그 메시지가 현재의 특정 문제를 해결할 수 있으면 된다. 공감 할만한 문제, 그리고 모두를 만족시키는 것이 아니라, 특정한 누군가의 문제를 풀어줄 수 있으면 된다. ONE CLEAR BENEFIT누군가 세상에 직면한 하나의 문제를 단 한 발짝이라도 해결해줄 수 있다면, 그것은 기억될 수 있다. 기억 될만 하다. 가치가 있다.시장이 작다고 단정하지 않아도 된다.공감은 생각보다 위대하다.그것이 브랜드가 된다. 그 메시지는 하나로 충분하고, 한 문장으로 충분하다.대부분 이 한 문장을 정의하지 않은 채, 채 1년도 버티질 못할 상품을 알리기 위해 에너지를 소모한다. 백날 큰 돈 들여서 마케팅 해봤자, 밑 빠진 독에 물 붓는 격이다.딱 한줄, 딱 한 문장이면 된다.그리고 그걸 상품으로 증명하면 된다.단순한 것만큼 강력한 것도 없다.브랜드는 거기서 사작하는 것이다.