스토리 홈

인터뷰

피드

2019. 06. 17. 조회수 193

환상 속 브랜딩: 소비자들의 마음속엔 무엇이 있을까

비트코인캐쉬로 한 5만원 벌어서 기분이 겁내 좋았습니다. 자고 일어나보니 5만원이 시뻘겋게 깜박이고 있는 거죠. 이제 제가 어떻게 했을까요? 그 5만원을 뽑아서 카카오 적금에 차곡히 넣어놓았을까요? 음, 아마 누구도 그러지 않을 겁니다. 인생의 즐거움은 돈을 모으는 게 아니라 써버리는 탕진잼에서 비롯된다는 진리를 몸소 실천코자 냉큼 신발을 사버렸죠. 왜냐! 코인은 계속 오를 것 같았으니까! 기영이가 등장했으니까. (미친..) 일단 카드로 신발을 샀으니 지출한 건 코인이 메꿔주겠지~~ 라며 룰루랄라 하고 있었습니다. 기영이가 나타나면 오른!!!....(미친)다음 날 어떻게 되었을까요? 네 그렇습니다. 거래소 폐쇄! 중국발 악재! 선물옵션 종료! 큰손들 빠져나가기! 개미무덤! 그렇습니다. 나이아가라 폭포의 시원함을 맛보게 되었죠. 이렇게 모지리즘을 실현하고 나니, 문득 궁금해졌습니다. 도대체 소비자의 마음 속엔 무엇이 있는걸까.(응?...) 아니..정확힌 도대체 난 무슨 생각을 살고 있는걸까...난 왜 살지..하아.한강가즈아.... 여튼 오늘은 소비자들의 알 수 없는 마음에 대해 한 번 알아보고 싶어졌습니다. 저만 알아보면 재미가 없으니 여러분도 함께 알아보도록 합시다. 사람은 기똥찬 신상 조던이나 발색이 아름다운 틴트를 발견했을 때 두 가지 경로를 거쳐 판단을 합니다. 틴트를 보고 '저 틴트의 발색은 효과가 2시간밖엔 안갈거야. 난 또 알게 모르게 츄릅츄릅 틴트를 갈비탕과 함께 삼키고 말겠지.... 굳이 내 뱃속으로 들어갈 틴트를 32,000원이나 주고 살 필욘 없을거야. 차라리 그 돈이면 고기를 먹는 게 낫지 않을까?'라며 심사숙고하며 결정을 내리는 "중심경로 프로세스(central route processing)" 와 보자마자 어머 이건 사야돼! 라며 틴트 이름을 외우기도 전에 '저거 뭐지, 저거 주세요.' 라고 냉큼 사버리는 "주변 경로 프로세싱(peripheral route processing)"이 있습니다. 인간은 하루에 약 70번 정도의 결정을 하게 됩니다. 그런데 모든 선택에 심사숙고를 하게 되면 엄청 피곤해지고 배가 고파지겠죠? 그러니 효율적인 선택을 하기 위해 주변경로를 활용하려는 경향이 있습니다. 지인의 추천, 화려한 광고문구, 점원의 말발 등 환경적 요소와 필요하진 않지만 왠지 갑자기 필요한 이유를 만들어내는 알 수 없는 그 존재(=지름신)의 강림 등 말입니다.이러한 주변경로 활용은 두 가지의 장점이 있습니다. 일단 소비자입장에선 정신적 에너지를 아끼고 구매에 대한 책임 등에서 자유로워 질 수 있습니다. 사고 나서의 합리화나 편향기제가 작용하는 것도 훨씬 용이해지죠. 지름신이 시킨 일이니 나의 잘못은 별로 없다고 여겨지거든요. 예쁜 쓰레기는 예쁨으로서 역할을 다했다....는 식의 현명(?)한 사고가 사람을 지배하게 됩니다.나머지 하나는 빠른 결정입니다. 이건 기업 입장에서도 즐겁고 행복한 일이죠. 4일 밤낮을 공부하고 연구하며 저걸 살지말지 고민하는 것보다 보자마자 이거 주세요! 를 외치는 극단적 시원함(COOL) 속성 고객을 만나면 매우 즐겁지 않겠습니까. 제가 아디다스에서 신발팔때는 이런 고객님이 오면 왠지 양말이라도 하나 더 챙겨드리고 싶었.....하지만 이러한 주변경로 프로세싱이 항상 좋은 측면만 있는 것은 아닙니다. 인간의 선택을 너무 다각화시키고 충동/감정적으로 만들어서 예상치 못한 행동들을 만들어내는데 이 때문에 브랜딩이나 마케팅전략을 세우는 데 있어 꽤나 골치를 썩게 되죠.예를 하나 들어보죠. House-money effect 라는 이론이 있습니다. '꽁돈 효과' 라고도 하죠. 코인으로 5만원을 벌면 저축을 하지 않고 더 큰 돈을 써버리는 겁니다. 이스라엘의 경제학자인 랜즈버그(Michael Landsberger)가 진행한 '랜즈버그 조사'에선 한발 더 나아가 꽁돈이 소액일수록 그 이상의 지출을 쓰게 된다고 했습니다. 로또 정도의 거액에 당첨되면 오히려 그걸 저축하고 관리하려고들 하죠. 하지만 한 번에 구매할 수 있을 정도의 금액이라면 오히려 거기에 얼마를 더 얹어서 큰 지출을 하는 겁니다.  예를 들어볼께요. 오늘 길가다가 78만원을 주웠습니다. 근데 마침사고싶던 미러리스 카메라가 90만원인거예요. 그럼 12만원 얹어서 카메라를 사고 생각하겠죠. 우와 12만원에 카메라를 샀어!! 라고. 사실 그 돈이 없었다면 카메라가 필요없다고 느꼈을 지도 모릅니다. 몇 달 지나면 머릿속에서 지워질 충동이었을지도 모를 일이죠. 이는 '심적회계(mental accounting)'의 작동 때문입니다. 우리 마음 속엔 전혀 논리적이지도 정확하지도 않지만 꽤나 놀라운 성능의 계산기가 하나씩있죠. 말도 안되는 계산을 척척해내는 물건입니다. 1. 기프티콘은 현금지출에 비해 돈을 아끼는 듯한 기분이다.2. 다음 달에 낼 돈은 미래의 내가 알아서 하겠지.3. 오늘은 고생했으니 써도 된다.4. 나를 위한 선물이다.5. 왠지 다음달엔 돈이 들어올 것 같아.6. (당연한 돈을 받았는데) 내 계획에 없었으니 꽁돈이다.7. 오늘 기분이 개똥이므로 질러버리자!8. 다 먹고살자고 하는 건데 먹는 데 쓰는 건 괜찮아9. 할부로 내면 충분히 가능할 듯10. 비트코인골드 호재가 있으니 다음주엔 오를거야등등의.... 초자연적인 계산을 가능케하는 계산기죠.  하지만 놀라운 건 이 심적회계엔 하나의 스위치가 있습니다. '감정회계'라는 모드죠.우연히 구스다운 주머니를 뒤지다가 1만원 짜릴 발견하면 냉큼 치킨을 시켜버립니다.그러나 돌아가신 어머님의 유품을 정리하다  어머니 바지에 있던 1만원을 우연히 발견했다면 고이고이 평생 간직할지도 모릅니다.같은 돈이라도 감정에 따라 그 가치가 엄청나게 달라지게 되는 것이죠. 이러한 긍정적 공돈효과를 극단적으로 활용하는 곳이 바로 휴대폰 정책입니다. 18개월간 쓰고 중고폰을 반납하면 나머지 6개월분의 할부금은 없애줄께! 하는 등의 조금만 알고보면 호갱트랩인 정책들이죠. 왠지 지금 이것저것 할인을 붙여 왠지 싸게 사는 듯한 기분이 드는 겁니다. 백화점이나 뷰티브랜드의 '통합포인트 제도' 도 이와 비슷하죠. 잠자고 있던 포인트를 깨우라는 건 당신을 위한 배려가 아니라 올리브영에서만 쓸 수 있는 포인트가 꽁돈으로 생겼으니 어서 달려가서 질러라!! 는 얘깁니다.이러한 체제를 휴리스틱이라고 하며, 다양한 마케팅이나 인지편향을 활용한 브랜딩전략으로 자주 활용되고 있습니다. 인간이 기본적으로 지니고 있는 인지편향심리는 소비와 브랜드인지에 아주 크나큰 영향을 미칩니다. 몇 가지를 좀 알아보도록 할까요1. 가용 휴리스틱 (availability heuristic)사람들은 먼저 배운 정보를 과도하게 신뢰합니다. 특히 부정적인 정보를 제압할 때 많이 사용하죠. 우리 아부지는 술 매일 마셔도 건강하게 잘 지내시는데?? 하면서 과음의 폐해를 축소시켜 인지하는 등의 심리입니다.에베베베베베2. 선택 지원 편향 (choice-supportive bias)흔히 단레몬기제라고도 하는데, 일단 무언가를 지르고 나면 그 선택에 대해 잘했다고 생각합니다. 맥북을 질러버렸으면 고장나지 않을 거야! 설사 고장이 나더라도 오히려 비싼 돈을 주고 AS를 받는 것을 기꺼이 납득하는 경우입니다. 내 선택이 틀리지 않았다는 것을 강화시키고 싶으니까요.3. 클러스터 착각 (clustering illusion)그냥 운으로 이루어진 경우인데 뭔가 그 속에서 패턴을 찾아내려고 하는 겁니다. 이는 도박사의 심리와도 연관이 되어 있는데 동전의 앞면이 9번 나왔으니 10번째는 뒷면이 나올 것이다! 라거나, 고양이 3마리가 차트에 등장했으니 반드시 내일 고점 돌파한다!! 는 식의 말도 안되는 논리이죠.4. 최신 편향 (recency)사람들은 최신정보를 더 신뢰합니다. 항상 최신이라고 해서 옳은 정보가 있는 것은 아니죠. 마케팅에서 흔히 '지금까지 알던 것은 잊어라!!' 또는 '우리는 잘못 알고 있었습니다...' 는 등 심각하게 정보의 오류를 찝어내는 식의 문구를 쓰는 것은 이러한 최신편향에 기대는 전략입니다.5. 특징 효과 (salience)브랜딩에 특징효과는 매우 중요합니다. 사람들은 '행복한 것' 을 떠올릴 때 단순히 삼시세끼 잘먹고 잘 곳있으면 되지~는 식을 떠올리지 않습니다. '행복한 것 = 로또당첨' 등의 극단적인 이미지를 먼저 떠오리려고 합니다. 가끔 담백하고 솔직한 마케팅이 실패하는 이유 중 하나라고 할까요. 큰 특징을 잡기 힘든 평범한 이미지로 브랜딩을 하려고 해도 소비자들은 극단적인 정보로 인식하려고 합니다. 특히 보고들은 정보를 누군가에게 전달할 때 이는 아주 심해지죠.6. 제로 리스크 편향 (zero-risk bias)확실한 것! 을 추구하길 좋아합니다. 때문에 두 번 세 번 확인하는 절차도 기꺼이 감당하죠. 그리고 놀라운 건 이렇게 확실한 절차를 거치고 나면 그것은 변하지 않을 것이다! 라는 믿음을 가집니다. 흔히 금융/법률 서비스등이 여러가지 복잡하고 완고한 절차를 요구함에도 그러한 번거로움이 신뢰로 변환되는 경우가 이러한 제로리스크 편향의 좋은 예라고 할 수 있습니다.7. 현상유지 편향(status quo bias)몇몇의 요지부동 소비자들의 심리입니다. '이불밖은 위험해' 라는 생각이죠. 비슷한 개념으로 부작위 편향(omission bias), 손실 회피 편향(loss aversion bias)이 있는데, 이는 소비자보단 경영측면에서 더욱 많이 활용됩니다. '새로운 건 젊은 애들이나 하는 거야!' 는 식의 의견을 합리화하는 데 유용한 마인드입니다.8. 사후확증편향(hindsight bias)오....이것은 매우 흥미진진한 편향입니다. 어떤 일이 일어나고 나서 평가할 때 "내가 그렇게 될 줄 알고 있었어!" 라고 무릎을 탁 치는 거죠. 정말 알고 있었을까요? 노놉. 이는 누군가가 좋은 아이디어를 냈을 때도 마찬가지입니다. "그 정돈 나도 할 수 있겠다!" 는 식의 심리죠. 그럼 미리 하지 그랬어요. 누군가의 성공이 쉽게 이해되고 그 원인을 마구 분석할 수 있는 것도 이러한 사후확증 편향에서 비롯됩니다. 그러니 성공사례에 대한 분석을 너무 믿진 마세요.9. 내집단 편애(ingroup favoritism)코란도를 구매한 사람들은 구매한 사람들끼리의 커뮤니티가 있습니다. OO을 사랑하는 모임 등도 비슷한 원리죠. 팬클럽을 조직하거나, 간담회, 베타테스터를 만들려는 이유는 이러한 내집단 편애현상을 활용해서 소비자계층을 끈끈하게 만들려는 심리입니다. 내가 산 제품을 너도 샀다는 데에서 동질감을 형성하고 그것은 이 제품을 비난하는 사람들을 적으로 간주하여 대신 공격하는 경우도 있습니다.10. 임의적 추론이건 매우 .....이상한 심리입니다. 흔히 원인과 결과가 동일시 되는 경우가 이에 해당합니다. - 나는 이걸 사고싶다- 그러니 이걸 사겠다.....이해가 확 되시나요? 근거가 곧 결과가 되버리는 이상한 추론인데, 심적회계 못지않게 초월적인 논리력을 구사할 수 있습니다. 이런 임의적 추론은 브랜딩전략을 구축할 때 엄청난 노력으로 고객 타겟팅을 해서, 고민고민한 슬로건과 워딩, 소개콘텐츠등을 순식간에 바보로 만들어버릴 수 있습니다.- 이건 뭔가 맘에 안들어(뭔진 모름)- 그러니까 싫어(응????)흔히 이러한 편향과 오류들은 정보를 분석해야하는 경우에 많이 발생합니다. 내가 에너지를 쏟아서 뭔가를 판단해야 할 때 두뇌는 귀찮아져버리죠. 그래서 주변정보에 기대버리려고 합니다. 또는 지난 경험이나 습관에 의존하려는 성향이 있죠. 그렇다면 브랜드는 고객에게 어떤 워딩으로 어떤 정보를 줘야 할까요?ㅎㅎㅎ 이건 숙제입니다. 저는 스압이 강력해서 여러분들의 눈이 피곤해질 걱정으로 이만 글을 줄이도록 하겠습니다. 숙제검사는 17화에서 하도록 하겠습니다 :) 모두 감기조심하세요!
2017. 07. 27. 조회수 2013

풀스택 개발자, 그것은 환상..

풀스택 개발자라는 용어가 가끔 등장한다. 죄송하지만, 한국에서는 이 용어가 정말 잘못 이해된 상태로 사용되고 있다. 처음에 만들어진 의미와 뜻이 한국에 들어오면서 변한 것을 보는 것이 이번만도 아니다.언제나처럼, 이 '단어'가 의미하는 뜻은 '귤이 회수를 건너면서 언제나 탱자가 되는' 한국적인 환경에서는 매우 이상하게 와전된 의미로 사용되고 있다. 특히나 비개발자들인 경영진들이 그러하고, 개발자들도 가끔 잘못된 의미로 사용한다.와전된 의미의 '풀스택 개발자(Full Stack Developer)'는 프런트엔드와 서버 엔드를 넘나드는 모든 것을 다 아는 전지전능한 개발자인 것처럼 쓰인다. 죄송하지만, 풀스택 개발자의 의미는 프런트-엔드부터 서버-엔드까지 모든 것을 다룰 줄 아는 개발자를 의미하는 것이 아니다.이 '용어'가 쓰이는 분야를 조금은 국한시켜야 할 필요가 있다.그것은 '웹'환경의 프론트 영역으로 국한시키는 것이 매우 현명할 것이다. 다음의 링크를 참조하기를 권한다.http://www.sitepoint.com/full-stack-developer/위의 사이트에 있는 이미지와 단어를 차용한다. 아래의 그림을 살펴보라.[이미지출처 : http://www.sitepoint.com/full-stack-developer/ ]OS부터 Database, WebServer, Server Side Code, Browser, Client Side Code를 아우르는 능력을 가진 사람을 Full-Stack Developer라고 부를 수 있다.좀 더 쉽게 이야기하자면, 'Web'환경은 서버사이드 코드와 클라이언트 사이드 코드를 모두 이해하고 작성되어야 한다. 브라우저( 특히나 변덕스러운 호환성 문제들.. )의 스크립트 환경이 효과적으로 가동되기 위해서는 웹서버의 API를 적절하게 디자인하고 구현된 상태에서 동작되어야 하며, 대부분의 코드들은 직접 Database에 영향을 주는 경우가 많다. 더군다나, 소프트웨어 개발을 하려면 형상관리부터 배포 처리를 위한 기술도 할 줄 알아야 한다.맞다. 'Web'개발 환경에서는 Full-Stack Developer가 되지 않으면 제대로 된 개발이 어렵다. 그래서, '웹'에서는 풀스택 개발자를 지향해야 하고, 매우 당연하게 해당 스킬들을 익숙하게 다루어야 한다.풀스택 개발자는 Web의 개발환경에서는 어쩔 수 없이 매우 당연한 기술적인 한계이고 해야 할 업무를 위해서는 필연적인 형태 인 것이다.이렇게 '웹 환경에서의 풀스택 개발자'는 한국에도 많이 존재한다. 상당수의 PHP개발자 분들이 그러한 '풀스택 개발자'인 경우가 많다.그렇지만, 이 풀스택 개발자의 용어는 '개발'이나 '소프트웨어'를 잘 모르는 경영자의 머릿속으로 잘못 들어가서 마치, iOS나 Android APP도 개발하고 Rest API 디자인이나 구현도 하면서, AWS의 분산 환경에 대한 이해나 개발도 모두 가능한 '전지전능한 개발자'와 같은 의미로 잘못 사용되기도 한다.( 더군다나, 디자인능력이 극도로 필요한 자바스크립트나 능동형 웹-UI를 만들어 내는 능력은 전혀 다른 능력이다 )원래 의미의 '풀스택 개발자'는 '혼자서 웹서비스 하나를 만들 수 있는 개발자'라는 좁은 의미로는 맞다. 하지만, 이를 과도하게 해석하거나 아전인수격으로 해석하는 것은 매우 곤란하다. 그것은 바로 한국적인 특수한 환경 때문에 그러하다.슬프지만, 한국적인 의미의 풀스택 개발자가 존재하기는 하고 있다.프로그래머가 기획도 하면서, 서버 구입부터 설치까지 다진 행하고, DB도 일부 다룰 줄 알면서, 웹이나 클라이언트 프로그래밍의 일부도 할 줄 아는 매우 한국적인 풀스택 개발자가 존재하기는 한다. ( 근데, 그런 개발자들을 풀스택 개발자라고 표현하지 않는다. 거의 기업의 잡부(?)처럼 부려지는 경우다. )노가다 - dokata, 土方 -'막일'을 하는 노가다를 하는 잡부가 한국형 풀스택 개발자라고 표현하겠다.하지만, 그런 테크트리로 형성된 한국형 풀스택 개발자들의 실력은 매우 볼품이 없는 경우가 대부분이다. 필자가 공공 SI현장에서 만난 수많은 한국형 풀스택 개발자들이 그러했다.그들은 컴파일러가 만들어내는 에러 메시지에 대한 이해는 없지만, 10년 넘게 업무를 배운 경험과 대충 Linux나 Windows Server의 기본적인 경험과 온통 스파게티 식으로 구성되어진 소스로 만들어진 더 이상 시장이 커지지 않는 한계가 다다른 시장에서 소프트웨어 개발을 하고 있다.태생적으로 '잡부'가 될 수밖에 없는 작업현장에서 진정한 의미의 풀스택 개발자는 거의 형성되기 어렵다. 이런 한국형 풀스택 개발자들은 실제 하나하나의 스킬들을 확인하거나 체크해본다면 거의 대부분 매우 부족하거나, 특정 기능에만 적합한 일반적으로 쓸모없는 기술들이 대부분일 가능성이 크다고 단언하겠다.이런 경향은 게임업계도 비슷하다. 한국형 풀스택 게임 개발자는 게임 기획부터 스프라이트의 2D부터, 포토샵이나 일러스트레이트도 다룰 줄 알며, 3D Max로 3D도 만들고, Auto-Cad로 도면 데이터도 다루고, DirectX에 Unity도 다루며, 서버나 iOS의 앱까지 만들 줄 안다고 하지만, 정작 그 어느 하나도 제대로 못 다루는 경우가 태반이다.물론, 전부 다루는 사람이 없는 것은 아니다. 있기는 있지만... 그분들 굉장히 유명하거나 특정 기술하나 가 대가의 수준이기 때문에 자신이 가진 다른 기술들을 포함해서 자신을 '풀스택 개발자'라고 포장하지 않는다.하지만, 한국에서 유독 '개발자 구인 광고'를 보면 '풀스택 개발자'를 찾는 곳이 많은 이유는 무엇 때문일까?그것은, 무지한 경영진이나 무지한 비즈니스 모델, 무지한 리소스 활용이 난무하는 헬게이트의 주인들이나 그런 단어들을 주로 사용한다고 보면 된다.100% 단언컨대 한 사람의 개발자가 완벽한 풀스택 개발자라고 하더라도, 요구사항이 발생하고 유지보수업무가 존재하는 업무를 하드웨어적인 서버 관리부터 서버 API, 앱 프로그래밍, 웹 프로그래밍을 하기 위한 스킬은 알 수 있다고 하더라도 그 복잡하고 어지러운 업무량은 모두 다룰 수 없다.만일 그런 것이 가능하다고 이야기하는 경영진이 있거나 무지한 영업맨이 있다면 정신 차리라고 조언해주자. 심지어 그렇게 만들 수 있는 서비스는 존재하지 않고, 존재한다고 하더라도.. 어마어마한 '기술적 부채'가 존재하며, 대부분의 가장 비싼 개발자의 리소스를 그 기술적 부채를 해결하기 위해서 사용되고 있을 것이라고.물론, 그렇게 동작하는 허접하고 쓰레기 같은 코드라고 하더라도, 특정 조건과 특정 환경에서는 서비스가 가능한 경우가 한국에는 많이 존재한다. 경영진이나 영업, 기획은 고객들을 설득하고 고객들이 해당 제품과 서비스를 사용하기 위해서 일부를 희생할 것이다. 그리고, 분명 다른 영역에서 누수가 발생하거나 희생되고 있는 것을 잊지 말자.특히나 경쟁이 없는 제품이거나 더 이상 리소스를 투입하기 어려운 소프트웨어나 서비스의 경우에는 이런 형태로도 동작은 할 것이다. 하루에 한두 번 서버의 Oracle 커넥션을 모두 종료하는 유지보수 행위를 하는 전산실의 업무가 그러한 경우 때문에 벌어진다.중견기업이거나 제조업체, 병원의 전산실에 '야간 당직'업무가 있고, 시스템 모니터링에 민감하다면 대부분 '기술적 부채'를 안고 허접하게 만들어진 것뿐이라고 판단하면 된다.말 그대로, 헬조선의 헬게이트, 헬(!)한 업무환경으로 소프트웨어 개발자로서 비전이 없는 영역이라고 생각하면 된다. 하지만, 그럼에도 불구하고... 스타트업 경영진이나 대기업, 중소기업 경영진들은 '풀스택 개발자'의 환상에 대해서 이야기한다.'모든 것을 다 하는 개발자'가 있으면, 복잡한 커뮤니케이션 비용도 안 들고, 인건비도 적게 들것이라는 착각을 한다. 다만, 이 부분만큼은 명쾌하게 이야기하겠다. '그런 회사 가지 말라'는 것이다.'풀스택 개발자'를 구인하고 있는 회사는 개발자의 무덤이라는 것이다. 대부분 그러하다. 그 이유를 다음과 같이 정리하겠다. 그들이 '풀스택 개발자'를 뽑고 싶은 이유는 간단하다. '돈'이 없어서다. 그리고, 다음의 이유들이 있는 경우이다.하나. 경영진이 요구사항 정의도 제대로 못하므로 개발자와 의사소통에 자신이 없다. 그래서, 풀스택 개발자를 구하려고 한다. 한 명 하고만 이야기하면 될 것이라고 착각한다.둘. 개발자의 인력이 몇 명이 투입되는지에 대해서 평가나 정의가 불가능하므로, 풀스택 개발자를 구하려 한다.셋. 개발자가 두 명, 세명이 있다면 팀 리더도 있어야 하고, 관리자도 있어야 하므로 그 비용을 줄이기 위해서 풀스택 개발자가 필요하다. 한마디로, 돈이 없다.넷. 현대의 웹서비스들을 가동하기 위해서는 최소한의 비용과 인건비가 투여된다. 이 비용을 투자할 정도로 비즈니스 모델에 가치가 없기 때문에 여러 명의 개발자를 고용할 수 없기 때문에 풀스택 개발자를 구하려 한다.다섯. 풀스택 개발자라면 막연하게 다 해줄 것 같은 환상을 가진 경영진이 있는 경우이다. 슬프지만, 전설의 개발자인 '제프 딘'을 고용한다고 하더라도, 삽질을 할 것이다.물론, 스타트업에 초기에 합류하면서 CTO의 역할을 부여받았다면 조금은 입장이 달라진다. 정당한 지분을 받고, 미래의 가치에 대해서 나눌 수 있다면, 해당 롤을 가진 사람은 알아서 '풀스택 개발자'가 될 가능성이 크다. 그러므로, 매우 당연하지만 CTO는 풀스택 개발자에 근접되면 좋기는 할 것 같다. 하지만, 현실적으로는 그렇게 세팅하지 못하는 경우가 대부분이다.그리고, 냉정하게 초기 개발이나 Lab수준, 시리즈 A를 투자받기 전의 '소프트웨어'나 '서비스'는 대부분 비즈니스 모델을 증명하는 수준에서 끝내는 것이 바람직하다. 굳이, 환상의 개발자나 풀스택 개발자가 아니라도 비즈니스 모델을 검토하고 증명하는 모델을 구현하는 것은 충분하게 가능한 경우가 대부분이다.사용자가 수백만 명도 아니고, 구현된 기능들도 수백 가지가 아니며, 아직은 스파게티 식으로 구성하더라도 무방하기 때문이다. 해당 기술적 부채는 서비스의 증명 후에 해당 코드는 버려지고, 다시 개발팀을 제대로 세팅하여 구현하면 되기 때문이다. 더군다나, 대부분의 스타트업은 고속 개발을 해야 하기 때문에 '풀스택 개발'이 가능한 '웹'만으로는 모든 것을 커버하기 어려울 것이다.좌우지간, 간단하게 이야기해서 '풀스택 개발자'타령하는 구인광고를 보게 된다면, 그 회사나 팀은 무언가 잘못 생각하고 있거나, '돈'이 없는 조직이라고 생각하면 된다. 거기에, '기술'이나 '개발'에 대해서는 아무것도 모르는 사람이 사장이 존재하는 곳이라고 생각하면 된다.헬게이트에 입성하고픈 개발자라면 '풀스택 개발자'를 구인하는 곳으로 가면 된다. 엄청난 '일'의 쓰나미를 경험하고, 인성이 피폐해지는 것을 경험할 것이다.필자는 국내 최고의 개발자들을 여럿 알고 있다. 하지만, 그분들은 자신들을 '풀스택 개발자'라고 이야기하지 않는다. 그 용어가 의미하는 것 자체가 '날림'이라는 것을 너무도 잘 알고 있기 때문이다. 물론, 10년 20년을 소프트웨어 개발을 하다 보면 얻어지는 경험과 지식들이 있다.궁극적으로는 풀스택 개발자가 이야기하는 비슷한 테크트리를 대부분 알고는 있게 된다. 하지만, 경력 20년 되고 하나의 도메인에 익숙하며, 특정 분야의 대가인 분들을 스타트업에서 고용한다는 것은 거의 불가능에 가깝다. 간혹, 그런 분들이 직접 스타트업을 하는 것이라면 모를까 말이다.이제 이야기를 마무리하겠다.'웹 개발'을 하려면 '풀스택 개발'을 지향하는 것은 맞다. 하지만, 그것 자체가 완벽한 풀스택 개발을 의미하는 것이 아니라는 것을 생각하기 바란다. 그리고, 경영진이나 비개발자들에게도 다시 한번 이야기한다. '풀스택 개발자'를 구인하겠다는 환상을 버리기 바란다.그런 사람 없고, 있다고 하더라도... '풀스택 개발자'를 구인하겠다는 발상으로는 절대 초빙하거나 모실 수 없다는 것을... 깨몽 하기 바란다.물론, '풀스택 개발자'처럼 이것 저것 다하는 정성스럽고, 일에 애정 넘치는 개발자들을 제대로 대우해주시기를... 기술로써의 풀스택 개발자가 아니라, 그 기업이 원하는 일을 풀스택 개발자처럼 일할 뿐이다. 그들에 대한 애정 넘치는 말한마디... 경영진들에게 부탁드린다.갑자기, '풀스택 개발자'에 대한 환상에 대해서 정리하고 싶어서 한 번에 글을 써 내려갔다. ~.~
2019. 04. 05. 조회수 333

스타트업 브랜딩: 내가 보는 나와 너가 보는 나의 일치

** 본 글은 문돌이 PM의 마케터 따라하기 시리즈 입니다.** 1화 보기 - 초기에 할만한 ASO (앱스토어 최적화) 팁** 2화 보기 - 초보 PM이 알아야 하는 초기 모바일앱 분석 101브랜딩이라는 단어는 하도 많은 사람들이 얘기하다 보니 친숙해진 단어이지만, 사실 그 명확한 개념을 설명할 수 있는 사람은 손으로 꼽을 정도일 것이다. '브랜드' 자체의 역사는 기원전 1100년전 까지 올라갈 정도로 오래되었지만, 사실 단순히 내가 만든걸 구분하기 위한 스탬프 수준이였으며, 현대적인 의미의 브랜드와 '브랜딩'의 체계가 잡힌건 최근 50년간이라고 봐도 무방할 것이다.나처럼 학부전공을 어설프게 경영학을 하고, 거기다가 마케팅을 심화전공으로 졸업한 사람들이 브랜딩이라는 주제에 대해 이야기 하려면 대부분은 어버어버하다가 설명을 잘 못하는 경우가 많다. 이는 크게 두가지 이유가 있는데, 1/ 일단 브랜딩이라는 카테고리에 거론되는 개념이 너무나도 많고, 학자마다 합의도 잘 이루어지지 않아서 책마다 설명하는 방식이 다 다르기 때문이고, 2/ 심리학에 기반을 깊게 둔 분야이기 때문에, 나처럼 어설프게 경영만 전공한 사람이 한학기 브랜딩 개론 과목 듣는다고 그 심오한 세계를 이해하기란 불가능하기 때문이다.음.. 말이 나왔으니 브랜딩이라는 카테고리에 얼마나 많은 개념들이 열거되는지 한번 따져보고 넘어가도록 하자. (위키피디아 및 내 전공서적들을 좀 참고했다)Brand elements: name, logo, tagline, graphics, shapes, colors, sounds, scents, tastes, movements...)Brand identityBrand trustBrand parityBranding strategies: individual branding, mulpiproduct branding, subbranding, brand extension, co-branding, multibranding, private brandingBrand ImageBrand personalityBrand attitudeBrand perceptionBrand perceived qualityBrand loyaltyBrand value propositionsBrand awarenessBrand associationBrand powerRebranding뭐, 한 5분동안 열거해 본건데도 이만큼이나 나온다. 내가 오늘 논하고자 하는 본론의 주제는 바로, 스타트업을 운영하는 마케터로서 (또는 대표로서) 이런 무지막지한 분야인 '스타트업 브랜딩'이라는 것을 현업 수준으로 적용하기 위해서 어떻게 접근해야 하는지에 관한 것이다.브랜딩의 핵심 개념은 내가 보는 나와 너가 보는 나를 일치시키는 과정이다브랜드와 브랜딩의 정의를 전공서적에서 찾아보면 개념이 책마다 다 다른데, 그 이유는 위에서 설명한 바와 같이 아직 역사가 깊지 않아서 학계에서 통일되지 않았기 때문이다. 하지만 나름 이 영역의 대가라고 불리는 3인방이 있기는 하다. 바로 David Aaker, Kevin Lane Keller, Jean-Noel Kapferer 이 세명인데, (뭐, 코틀러 얘기도 많이 하지만 개인적으로 코틀러는 브랜딩보다는 마케팅의 전 영역에서 아버지처럼 불리는 인물이니 여기에는 들어가지 않는다고 생각함) 우선 이들이 말하는 브랜드라는 놈의 정체에 대해 한번 보도록 하자. (한글정의는 Daniel Park님의 블로그 글을 인용했음)아커: 브랜드란 상품이나 서비스가 기업과 그 기업의 고객에게 제공하는 가치를 증가시키거나 감소시키는 한 브랜드와 그 브랜드의 이름 및 상징에 연계된 자산과 부채의 총체이다.켈러: 브랜드는 판매자의 상품이나 서비스를 규정하고 경쟁자와 차별하기 위한 이름, 기호, 상징, 디자인 혹은 이들의 결합이다.캐퍼러: 브랜드라는 것은 구매자가 그 브랜드 상품, 유통 채널, 판매원, 그리고 커뮤니케이션을 접하면서 오랜 시간을 통해 생긴 긍정적 인상 또는 부정적 인상의 집합체이다.이 세명의 정의를 해체해서 개념화시켜보자. 우선 브랜드와 관련된 3가지 큰 영역은 내 제품/회사 영역 + 소비자가 인식하는 영역 + 그 둘을 연결시키는 채널/활동들 이렇게 개념화 시킬 수 있다. 즉, 브랜딩이라는 개념은 이러한 3가지 영역으로 완성되는 브랜드라는 존재를 전략적으로 운영하는 개념.. 이렇게 이해할 수도 있지만, 사실 현업에서 쓰기에는 전혀 명확하지 않은 개념이다. 여기에 내가 전 직장에서 같이 일하던 내 직속상사께서 개발한 Concept of Branding이라는 맵을 더해서 이해해보면 그 개념이 매우 명확해 진다.Concept of Branding - Illustrated by Young-Jin Oh이 맵을 보면, 결국 브랜딩이라는 활동의 정의를 앞서 구분한 브랜드의 3가지 영역에 끼워 맞추어 정의내려 보면 다음과 같다. (내 사이드)내가 정하는 브랜드의 아이덴티티와, (소비자 사이드)소비자가 받아들이는 브랜드의 이미지를, (채널/활동 사이드) 마주치는 모든 접점에서의 일관된 액션을 통해 인식시키는 행위조금 복잡해 보이는데, 사실 쉽게 얘기해서 '내가 보는 나 (내 제품/브랜드)의 아이덴티티를 소비자가 인식하는 이미지와 명확하게 일치시켜 나가는 일련의 활동들'을 브랜딩이라고 정의내릴 수 있는 것이다. 즉, 다시 말해서, 내가 정의하고 있는 제품의 코어 가치를 기반으로 한 '나는 무슨 존재인가'에 대한것과 소비자가 나를 인지하고 있는 '너는 뭐하는 존재인가'에 대한것을 나와 너가 만나는 채널들 (제품, 매장, 광고 등등)에서 일관되게 일시치켜 나가는 일련의 모든 행동들이 다 브랜딩인 것이다.아, 참고로 저 맵에는 사실 더 심오한 내용들이 담겨 있는데, 예를들면 소비자가 나를 인지하는 '이미지'부분은 브랜드의 awareness(인지), loyalty(충성), association(연상), perceived quality(지각된 품질)등이 총체적으로 모여서 만들어지는 것이라는 것과, 이를 화폐가치로 환산한 것이 brand equity (브랜드 자산), 그리고 소비자들의 이런 인식들이 곧 reputation(명성)이 되어 브랜드의 파워로 작용하게 되고, 이게 다시 브랜드 아이덴티티에 영향을 주는 일련의 순환고리를 형성하게 되는 내용들이라는 것, 그리고 저러한 이미지는 그냥 생기는게 아니라 구매전, 구매, 구매 후에 접하게 되는 모든 contact points에서 발생하는 소비자의 경험 (experience)에 의해 인식 (perceived)되는 것이기 때문에 고객접점 관리가 브랜딩에서는 핵심이라는 것 등이다. (소위 브랜딩하면 멋있게 컨셉 뽑고 광고만드는거 상상하는 사람들이 많지만 사실 가장 중요한 영역은 매장, 고객센터 등 소비자가 내 브랜드를 heavy하게 경험하는 곳에서 일관된 메시지를 전달하는 부분이고, 이는 전사적 접근이 필요하기에 가장 어려운 영역이기도 하다) 하지만, 초기 제품을 빌드하고 초기 고객에게 서비스하고 있는 스타트업 입장에서 저 방대한 영역을 미리 기획하고 고민하고 있을 필요는 없다. 스타트업이 브랜딩을 한다면 다음에 설명한 내용들만 명심하면 된다.내가 보는 나: 내 브랜드의 가치를 최대한 심플하고 명확하게 설정한 브랜드 아이덴티티 설계내가 보는 나, 즉 브랜드 아이덴티티는 역시 학문적으로는 이를 형성하고 있는 하위 개념들이 방대하지만, 스타트업에서는 다음 5가지를 정하는 과정이라고 이해하면 된다.1. 브랜드 미션: 브랜드의 약속2. 브랜드 가치: 소비자가 얻게 되는 것3. 브랜드 슬로건: 위의 가치가 표현된 문구4. 브랜드 페르소나: 내 캐릭터 정의5. 채널관리: 모든 접점을 일관되게 기획브랜드 미션이란, 내 브랜드가 제공하는 핵심 가치를 명문화 한 것을 의미하며, 내가 소비자에게 주겠다고 밝힌 일종의 약속같은거를 정의내리는 작업이다. 스타트업 담당자가 이 작업에 직면하게 되면 (나도 그랬었고) 많은 사람들이 흔하게 하는 행동들이 있다. 바로 브랜드 미션을 애매모호하고 다소 오글거리게 정하는 것이다. 이런 현상이 왜 발생하냐면, 우리가 브랜드 미션을 정할때 보통 대기업의 그것을 참고해 보기 마련인데, 보통 그런 큰기업들의 미션은 다소 장황하고 방대한 느낌이 있다. 그건 대기업의 경우 이미 발을 담그고 있는 사업도 많아지고 조직의 5년후, 10년후를 바라보는 미션을 정해야 하는 경우가 많기 때문에 미션이 애매모호해 질 수 밖에 없기 때문이다. 물론 페이스북처럼 한결같이 심플한 기업도 있기는 하지만, 보통 한 우물만 파는 대기업의 경우 미션이 심플한 편이고, 국내 대기업처럼 문어발식으로 운영되는 기업의 경우 미션이 애매모호한 느낌이다. (어디까지나 개인적인 의견임)아무튼, 이런 기업들의 미션들만 보다 보니, 내가 서비스하는 이 브랜드도 뭔가 웅대하지 않으면 안될것 같은 느낌이 들고, 그러다 보면 온갖 미사여구로 장식된 애매모호한 브랜드 미션이 만들어지는 경우가 많다. 꼭 명심해야 할 것은, 초기 스타트업의 초기 제품을 서비스하는 상황이라면 브랜드의 미션이 절대로 장황하거나 애매모호해서는 안된다. 미션이 명확해야 이를 기반으로 한 브랜드 가치 정의, 타겟, 페르소나, 채널관리 등등의 후속 작업들이 명확해 지고, 미션이 장황하면 그 후속작업들 역시 모두 뜬구름 잡는 얘기만 하다 끝날 가능성이 크기 때문이다. 또 하나, 브랜드의 미션은 길이가 중요하지 않다. 어차피 소비자에게 공개되는건 미션이 아니라 슬로건이기 때문이다. 미션의 길이가 길더라도 그 브랜드가 약속하는 바만 명확하다면 괜찮다.잘 된 스타트업의 사례를 들어보면 좋겠지만 사레 찾기가 쉽지 않아서, 개인적으로 좋아하는 김밥 프랜차이즈 브랜드인 '김선생'의 케이스를 들어서 이 부분의 예를 들어보도록 하겠다. 바르다 김선생은 유명한 '죠스 떡볶이'의 나상균 대표가 창업한 프리미엄 분식점 브랜드 이다.죠스떡볶이의 나상균 대표가 창업한 프리미엄 분식 브랜드 '김선생'이 김밥집의 브랜드 미션은 다음과 같다. (아예 미션이 매장에 붙어있다)photo by 똑똑이아빠내 블로그미션이 좀 길지만 브랜드가 약속하는 바는 매우 심플하고 명확하다. 즉, '멋부리지 않고 사명감과 도덕성으로 절대로 재료를 타협하지 않겠다.'로 요약할 수 있다. 이게 왜 잘 만들어진 브랜드 미션이냐면, 이 정의를 기반으로 2번부터 5번까지의 모든 후속작업을 아주 명확하게 만들어 주고 있기 때문이다.이런 미션을 바탕으로 한 김선생의 브랜드 가치는 '마음 놓고 먹을 수 있는 분식집'이 되는 것이며, 소비자는 저렴한 맛에 먹는 분식집에서 항상 고민되던 건강에 대한 문제를 걱정하지 않아도 된다는 브랜드 가치를 전달할 수 있다. 이를 토대로 나온 브랜드 슬로건은 바로 '바르다 김선생'이다 (사실 김선생은 브랜드 네임이 아예 슬로건이 포함된 '바르다 김선생'이다). '마음 놓고 먹을 수 있을 수준'이 완성되려면 재료만 고급이어서는 안되고, 매장의 청결, 직원들의 마음가짐 등등 모든 영역에서 거짓이 없어야 하기 때문에 이 모든 마음가짐을 '바르다'라는 말로 함축해서 만들어진 슬로건이다. 브랜드 페르소나는 말이 좀 어렵게 느껴지지만 사실 그냥 이 브랜드로 묘사가능한 어떤 사람, 인격체, 의인화 등등을 의미한다. 쉽게 얘기해서 '이 브랜드는 이런 사람을 떠올려 보세요' 정도로 요약 가능하다. 김선생의 페르소나는 위의 미션에도 설명된바와 같이 뭔가 꾸미기 좋아하고 화려하고 튀는 사람 보다는 우직하고, 믿을 수 있고, 정직하며 꾸밈없는 사람, 그리고 나이도 조금 있고 들뜨지 않는 인자한 아저씨 같은 사람으로 설명 가능하다.채널관리는 이렇게 정해진 브랜드 슬로건과 페르소나가 일관되게 소비자에게 인식되도록 모든 접점을 통제하는 것을 의미한다. 김선생 매장의 메인 컬러는 마치 절제되고 정직한 김선생 아저씨가 좋아할만한 컬러인 검정과 흰색, 베이지색을 혼합해서 사용하고 있고, 모든 폰트도 명조체로, 유니폼도 장식 하나 없는 검정색에 흰색 앞치마, 직원들의 움직임도 아무리 바빠도 막 뛰어다니거나 흥분하지 않고 항상 평온하고 온화해 보이는 톤을 유지하고 있다.   너가 보는 나: 소비자가 내가 정한 아이덴티티를 잘 인식하고 있는지 모니터링위의 아이덴티티를 기반으로 제품의 모든 접점 기획을 완성하고 실제 운영까지 하고 있다면 꼭 병행해야 하는 작업이 바로 '너가 보는 나' 즉, 소비자가 내 브랜드를, 내가 제공하고자 약속한 가치를 잘 인식하고 있는지를 모니터링 하는 것이다.예를들어 위의 김선생의 경우 매장을 이용하는 소비자들이 정말 재료에 대한 의심 없이 우리 음식을 안심하고 먹고 있는지, 김선생 하면 뭔가 바른사람 이미지의 중년 남성이 떠오르는지, 그 사람은 뭔가 절대로 뒷통수 칠 것 같은 사람이 아니다라는 믿음이 생기는지 등등 애초에 설계했던 브랜드 아이덴티티가 잘 인식되고 있는지를 소비자 인터뷰나 관찰을 통해서 파악해 보는 단계이다. 만일 나 처럼 소셜미디어 앱을 운영하고 있는 스타트업을 가정해서 이 단계를 모니터링 하는 방법을 간단하게 요약해 보면 다음과 같다.1) 앱 내에서 유저 행동 관찰을 통해 앱의 코어 가치가 잘 전달되고 있는지 체크하기다음과 같은 유저의 앱 내에서의 사용 행태를 분석해서 사용자들이 내가 의도한 앱의 코어 기능들을 잘 사용하고 있는지, 사용 목적이나 동기가 내가 의도한 바와 일치 하는지 등을 확인할 수 있다. - 앱 로그인 빈도- 앱 체류시간- 앱의 각 코어 기능 사용 빈도- 대화 내용 분석- 프로필 사진 분석- 상태 메시지 분석- 앱스토어 리뷰2) 인터뷰를 통해 이 앱이 어떤 앱인지 잘 인지하고 있는지 체크하기위의 관찰만으로는 얻기 어려운 유저의 앱 다운로드 동기, 목적, 이 앱을 통해 얻는 가치 등등을 인터뷰를 통해 확인 가능하다. 다음과 같은 질문들을 던져볼 수 있다.- 이 앱을 다운받게된 동기- 이 앱을 알게된 경로- 다운받을 당시 생각했던 '이 앱이 뭐하는 앱이지?'- 사용하고 나서 지금 생각하는 '이 앱이 뭐하는 앱이지?'- 이 앱을 켜보게 되는 순간들- 앱을 사용하는 빈도- 앱에서 주로 활용하고 있는 기능들- 앱에서 가장 마음에 드는 점- 위의 것을 제외한 기타 마음에 드는 점들- 앱에서 가장 불만족 스러운 점- 위의 것을 제외한 기타 불만족 스러운 점- 친구에게 추천하고 있는지- 추천하고 있지 않다면 왜 안하는지?- 추천하고 있다면 왜 추천하고 있는지?- 이 앱을 사람에 비유해 보면 어떤 캐릭터가 떠오르는지?- 이 앱을 주로 사용할 것 같은 사람들은 어떤 사람들?3) 위 유저가 앱을 사용하는 케이스를 실제로 관찰해 보기인터뷰 전-후에 실제로 이 유저가 앱을 켜서 어디를 먼저 들어가고 무슨 기능을 사용하는지를 관찰해 봄으로써 1번과 2번에서 놓쳤던 부분들을 모니터링 할 수 있다.브랜딩: 내가 보는 나와 너가보는 나를 끊임없이 일치시키기기많은 사람들이 실수하는 부분이 바로 이 단계에 있다. 흔히들 브랜드 아이덴티티를 설계하고 나면 왠만해서는 이걸 바꾸지 말고 일관되게 밀고나가야 한다고 생각한다. 물론 매우 맞는 말이다. 앞서 얘기한 바와 같이 모든 채널에서 메시지가 '일관되게 (consistent)' 전달되지 않으면 소비자에게 이미지가 잘 형성되지 않기 때문이다. 하지만, 초기 서비스의 경우 이렇게 일관성을 고수하는것은 대단히 위험한 일이다. 왜냐하면 내가 아무리 명확하게 아이덴티티를 설계한다 할지라도 소비자는 다르게 받아들일 수 있고, 내가 정한 코어 가치가 사실 소비자에게는 별로 중요하지 않은 가치일 수도 있으며, 소비자는 내가 전혀 예상하지 못했던 새로운 사용성을 발견할 수도 있기 때문에 '너가 보는 나'를 최대한 자세하게 모니터링 해서 이를 '내가 보는 나'에 반영해서 끊임없이 발전시켜 나가는 과정이 초기에는 필수적이다.이번에는 내가 서비스 중인 '바크' 앱을 예를 들어 보자. 사실 이 앱은 뭔가 원대한 비전을 가지고 기획된 앱이라기 보다는 해카톤에서 뭔가 기발하고 재미를 줄 수 있는 아이템의 일환으로 기획된 앱이기 때문에 위와같은 브랜드 아이덴티티에 대한 고민은 전혀 존재하지 않았다. 사실 지금도 아직 베타기간 중이라 iOS 유저들만을 대상으로 위의 아이덴티티를 계속 정립해 나가는 과정에 있다.바크 앱의 현재 Mission Statement 이다.이 앱의 초기 브랜드 슬로건은 'Don't Speak, Let's Bark!'에 있었다. 이 슬로건에 포함된 앱의 미션은 '굳이 복잡한 대화 없이도 모르는 사람들이 서로 자유롭게 대화할 수 있는 소셜공간을 만든다' 였다. 즉, 내가 모르는 사람들과 서로 소통하기 위해서는 서로 인사도 터야하고, 공통점도 찾아야하고, 관계를 형성하기 위해 복잡하게 오고가는게 많이 필요하기 마련인데, 바크에서는 모두가 개가되어 서로 짖는 것 만으로도 대화가 되기 때문에 언제 어디서나 모르는 사람들과 쉽고 재밌게 대화가 가능하다는 가치를 전달해 주는 것이다.하지만, 앱을 2개월정도 운영하면서 모니터링을 통해 발견한 사실은, 유저들이 이 앱의 목적성을 모르는 사람들과 대화하기 위한것에 두기 보다는, 서로 개처럼 짖고 짧은 메시지가 산발적으로 오가는 그런 공간 자체가 재미있어서 사용한다는 것이었다. 즉, 내가 굳이 모르는 사람들과 관계를 트기 위해 사용하는 SNS가 아니라 저런 약간 병맛같아 보이는 소통방식이 서로 통하는 커뮤니티와 같은 소셜 공간이 언제 어디서나 존재한다는 것에 재미를 느껴 사용한다는 것이다. 이를 토대로 새롭게 정립한 브랜드 슬로건이 위의 사진과 같은 'from No One to Someone'이다. 이 슬로건 속에 내포된 유저에게 주는 가치는 '언제 어디서나 저런 재밌는 소통방식이 통하는 누군가를 당신 주변에 만들어 준다' 이다.말하고자 하는 바는, 당신이 만일 필자처럼 초기 서비스를 운영중인 스타트업의 브랜딩을 하고자 한다면, 큰 기업에서 브랜딩 전문가들이 하는 방식과 같이 자세한 브랜드 아이덴티티 맵을 만들어서 전 펑션에 일관되게 전달되도록 메뉴얼을 만들고, 이게 잘 워킹되는지 체크하고 쪼는 방식으로는 절대로 안된다는 것이다. 내가 아직 나를 잘 모르는 상황에서 내가 잘못 판단한 나를 너에게 맹목적으로 주입시키고 있는 상황이나 마찬가지이기 때문이다. 초기 스타트업에게 소비자가 인식하고 있는 브랜드 아이덴티티를 모니터링해서 이를 토대로 내가 정립한 아이덴티티를 수정 보완시켜 나가는 과정이 결국 스타트업 브랜딩의 핵심인 것이다.상호작용: 내가 그의 이름을 불러줘야 하고 그도 내 이름을 불러줘야 한다김춘수의 유명한 시, '꽃'이 있다.내가 그의 이름을 불러주기 전에는그는 다만하나의 몸짓에 지나지 않았다.내가 그의 이름을 불러주었을 때그는 나에게로 와서꽃이 되었다.내가 그의 이름을 불러준 것 처럼나의 이 빛깔과 향기에 알맞는누가 나의 이름을 불러다오.그에게로 가서 나도그의 꽃이 되고 싶다.우리들은 모두무엇이 되고 싶다.너는 나에게 나는 너에게잊혀지지 않는 하나의 눈짓이 되고 싶다.이 시에서 김춘수는 너와 내가 서로 관계를 가질 때 비로소 존재할 수 있게 되는 존재성에 대해 노래하고 있다. 브랜딩도 마찬가지이다. 거창하게 정립된 브랜드 전략 기획서 같은건 그리 중요하지 않다. 특히 초기 스타트업에의 경우 너무 자세하게 정립된 브랜드 스테이트먼트는 짐만 되는 경우도 많다. 가장 중요한건 이 시처럼 '내가 너의 이름을 불러주는 것,' '너가 내 이름을 불러주는 것,' 이리하여 비로소 '서로에게 꽃이 되는 것' 이런 너와 나의 상호작용이 브랜딩의 핵심임을 명심해야 한다. 즉, 내 브랜드에 대해 정의하는것과, 소비자의 인식에 대한 것을 모니터링하는것, 그리고 채널에서 이 상호작용에 대해 모니터링하고 보완 발전하는 것, 이것이 바로 스타트업 브랜딩의 모든것이다.글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기#네이밍 #이름짓기 #브랜딩 #아이덴티티 #스타트업 
2019. 01. 31. 조회수 381

리디북스 서버 스택 소개

2대의 서버로 시작한 리디북스는 각 기능의 요구사항에 최적인 솔루션들을 채용하고, 고가용성(High Availability)을 지향하면서 매우 복잡하고 다양한 구성으로 변모해왔습니다. 이 글에서는 리디북스가 어떤 스택에서 서비스를 제공하고 있는지 간략히 소개하려고 합니다. 각 스택의 선택 이유나 문제에 부딪히며 배운 노하우 등은 차차 포스팅하겠습니다.대략적인 구조리디북스 백엔드 구조도로드 밸런싱로드 밸런싱은 소프트웨어 로드 밸런서인 HAProxy를 이용하고 있습니다. HAProxy는 L4, L7 스위치의 기능 및 로드 밸런싱을 제공하고 구성 역시 매우 간편합니다. 리디북스는 고가용성을 위해 Active - StandBy 서버 한 쌍이 가상 IP를 공유하고, keepalived를 통해 서로의 상태를 확인하며 자동 failover 됩니다. 각 서버군이 사용하는 네트워크 트래픽에 따라 스위치와 연결되어 있는 네트워크의 속도가 다른데, 이를 효율적으로 사용하기 위해 HAProxy 서버 쌍을 2개 구성하여 DNS를 통해 HAProxy로 들어오는 트래픽도 분산하는 방식으로 네트워크 효율화를 이루었습니다.웹 서버Ubuntu 14.04 LTS 기반에 웹서버로는 Apache, Nginx를 사용하고 있습니다. 서점 용 웹 서버, 정적 파일 서버(CSS, JS 등), 통계용 서버, 책 파일에 DRM을 씌워 전송하는 다운로드 서버 등 여러 개의 웹 서버 그룹을 나누어 관리하는데, 각 서버가 하는 역할이나 테스트를 통해 확인한 병목 지점을 고려해 웹서버를 채택합니다.API 서버리디북스는 서점이나 앱에서 이용하는 수많은 API가 존재하는데 종류에 따라서는 초당 수만 개의 호출이 발생하는 경우도 있습니다. 이러한 트래픽을 감당하기 위해 비동기 처리가 필요한 경우 Node.js를 주로 이용하여 구현하고 있습니다. Node.js 프로세스는 PM2를 통해 클러스터 모드로 실행되어 요청을 처리합니다. 클러스터 모드는 프로세스에 대한 로드 밸런싱을 지원하며 프로세스를 순차적으로 재시작할 수 있어 무정지로 서비스를 재시작할 수 있습니다데이터베이스서비스 초기에 MySQL을 사용했고 현재는 MariaDB로 변경한 상태입니다. 한때 DB가 SPOF(Single Point Of Failure)였던 시기를 겪으면서 read/write의 분산을 위해 많은 노력을 들였습니다. 리디북스에서 실행하는 대부분의 데이터 연산은 읽기 동작이므로 애플리케이션 레벨에서 읽기/쓰기 접근을 구분하여 1차적으로 부하를 분산하고, HAProxy를 통해 여러 대의 slave로 분배해 2차적으로 부하를 분산합니다. 쓰기 동작이 빈번하거나 데이터 성격상 NoSQL이 필요한 경우 Couchbase와 Redis를 적극적으로 사용하고 있으며, MariaDB 상에서도 쓰기 동작의 분산 필요성이 대두됨에 따라 상반기에 샤딩을 준비하고 있습니다. 사용자 행동, 트랜잭션 로그 등 하루에도 방대한 양이 쏟아지는 데이터의 경우 Azure 내에 구성한 Hadoop 클러스터에 보관하며, Hive 저장소를 BI(Business Intelligence) 시스템 기반으로 활용하고 있습니다.파일 시스템리디북스에서 다루는 책 파일은 매우 방대하고 중요한 데이터입니다. 어떠한 일이 있어도 데이터 유실이 발생해서는 안되며, 일부 하드웨어 혹은 노드에 장애가 발생하더라도 서비스 장애 없이 파일을 서빙할 수 있어야 합니다. 저희는 GlusterFS로 6대의 노드를 클러스터를 구성하고 이를 파일 접근이 필요한 서버에서 NFS-like 형태로 마운트하여 사용하고 있습니다. 동일 데이터는 여러 노드(3 replica)에 분산 저장되며, 각 노드에도 RAID 구성을 하여 빠른 장애 대응 및 데이터 유실 방지에 노력하고 있습니다.검색리디북스의 책/저자 검색 등은 ElasticSearch를 통해 이루어집니다. 형태소 분석기는 오픈소스인 은전한닢에 따로 정의한 dictionary를 조합해 사용하고 있고, 2대의 노드로 클러스터가 구성되어 있습니다. 추가/변경되는 도서 정보는 증분 색인을 통해 실시간으로 검색 서버에 반영됩니다.작업큐이메일 발송, PUSH 발송 등의 작업들은 웹 애플리케이션이 직접 실행할 경우 페이지 응답속도를 떨어뜨리고, 진행상황 파악이나 실패 시 재시도하는 등의 실행 관리가 어렵습니다. 이런 문제를 해결하기 위해 Beanstalk라는 Work Queue에 작업을 일단 쌓아두고, 여러 대의 서버에서 실행되고 있는 컨슈머들이 작업을 가져와 순차적으로 진행하는 형태로 구성되어 있습니다.모니터링장애 발생 포인트와 시점을 예측할 수 없는 만큼 장애 발생의 빠른 인지를 위해 모니터링은 매우 중요합니다. 리디북스는 99.999%의 고가용성(High Availability)을 목표로, 버그와 장애 없는 안전한 운영을 위해 아래와 같이 다양한 오픈소스 및 유료 솔루션을 도입하여 활용하고 있습니다.30+ 이상의 서버 리소스를 모니터링하기 위한 Munin(On-Premise) 및 NewRelic(SaaS)서버에서 발생하는 각종 오류와 예외를 모니터링하기 위한 Sentry로그인, 결제 등 서점의 핵심적인 기능의 정상 여부를 모니터링하는 Pingdom각종 배치작업과 주기적으로 실행되는 스크립트를 모니터링하기 위한 PushMonNode.js 프로세스나 Redis 상태 모니터링을 위한 Keymetrics(SaaS)데이터의 무결성을 주기적으로 감지하는 각종 In-house 스크립트#리디북스 #서버 #서버개발 #스택 #백엔드 #node.js #개발자 #개발언어 #스킬스택 #소개
2019. 06. 14. 조회수 134

우리에게 보이기 시작한 세상

무지몽매하고,좁은 시각으로 지금 당장 닥치는 앞날만보였는데...조금은 세상이 다르게 해석되고,안 보이던 것들이 보이기 시작했다.넓은 모래사장에서 작은 조개껍데기 하나를 발견한 수준이지만공유하고, 나누고자 글을 남긴다.1. 멀티태스킹이 아니라, 멀티인프라!잘하는 것을 특화하고,못하는 것은 잘하는 놈에게 맡겨라.내가 알고 있는 것보다,우리가 알고 있는 것이 많고내가 모르는 것보다우리가 모르는 것이 적다.따라서,우리는 다재다능보다다양한 사람, 다양한 기업과협력할 수 있는 인프라가 중요하다.일면식이 없던 사람을 설득하기보다알음알음 통해서 알게 된 사람을 설득하기가 쉽다.2. 신기한 나라의 엘리스의 빨리 달리는 여왕에게 배운다이제는 생산공장이 수요처로 갈 것이다.딜리버리가 중요해진다.스마트 팩토리 다음에는 스피드 팩토리고...지금 그렇게 흘러간다.개인의 맞춤형 시대, 신속함의 시대가 도래할 것이며, 다품종 소량 생산을 어떻게 빠르게 제공할 것인가가 관건이다.작은 기업의 강점은 스피드!남들과 같은 속도가 아니라 그보다 빠른 속도여야 앞서게 된다.지구가 돌아가는 속도보다 빠르게 달리는 여왕처럼시장이 변화하는 속도보다 빠르게 리드해야 한다.(물론 너무 빠르면 역으로 gap이 발생하니까 약간 더 빨리)3. B+프리미엄의 시대보편적이고 합리적인 가격에서 익숙한 기존의 것에 추가의 가치가 더해지는 형태가소비의 주축이 될 것이다.같은 값이면 다홍치마가 되어야 한다.디자인/콘텐츠의 중요도가 높아지고,고객의 눈높이는 첫눈에 반하는 제품으로 좁혀 들고 있기에 본질은 기본이고,디테일에 더 집중해야 한다.따라서,"No frills chic"가격은 저렴하지만 디자인이 매우 우수하여 럭셔리한 이미지를 풍기는 제품으로 나아가자.장식이 많이 없지만 멋진 제품들은 벤치마킹하자.설레지 않으면 버린다.그래서 정리하고 버리고 사지 않는 소비패턴이미니멀리즘의 증명이다.4. 구매 결정은 내가 한다.지금까지 구매 결정은 타인의 후기, 제품 추천정보에 의한비중이 컸으나 이제는 데이터의 축적으로 인해나만의 데이터 풀이 형성되고 있다.그리고 그러한 데이터를 기반으로고객 스스로 구매 결정을 내릴 수 있는 시대가 곧 열릴 것이다.예를 들어,내가 구매했던 이력들과 구매 제품의 정보들이중복/추출/정제되어 자료에서 정보로 탈바꿈될 것이며,가격대, 소요자금, 구매시기 등의 정보들과 연관되어나에게 맞추어진 구매 범위가 산출될 것이다.여기에 더 필요한 것은 신뢰도!그 신뢰도를 어떻게 확보하느냐를제품에 녹여야 한다.4차 산업혁명이다, 6차 산업이다,O2O, O4O, IoT 등 여러 그럴듯한 단어로정의하고 있지만그냥 쉽게 생각해서데이터를 통해 얼마나 고객의 입맛대로제품을 공급할 것이냐가제조업의 해결해야 할 문제이다. 5. 노동력의 종말? 섣부른 단정은 금물많은 사람들과 언론은 인공지능의 시대에는대규모 실업사태와 노동력의 드라마틱한 감소를 예단한다.과연 그럴까?어느 정도 동의는 하지만,그것이 모든 것을 바꾸진 않으리라.농업과 가내수공업 등으로 사람 손이 절대적인 시대에서증기기관과 화석연료로 인한 산업화로 넘어가던 시절에직업의 변천은 있었지만, 여전히 노동력이 필요했다.오히려 많은 인구는 도시로 몰려들었고,다양한 직업이 발생하였다.인터넷이 발달하고, 컴퓨터의 발전으로 급격한 세상의 발전이 되었을 때도업무의 양은 늘어났고, 이동속도도 빨라지고,서비스업의 발달을 통해 더 많은 직업이 탄생하였다.굴뚝청소부가 사라지고,보일러 수리공이 나타났다.은행 지점이 줄어들지만,수많은 인터넷 은행, P2P 거래업체가등장하게 되었다.자율주행차가 나오면 자가 소유 차량이 감소할 것이지만,차량 대여/공유 중개사들이 생길 것이다.사물인터넷을 적용한 공장자동화로많은 생산직 자리가 사라지겠지만,공장을 유지/보수/관리하는 자리가 늘 것이다.물론 기존의 직업에서 새로운 직업으로 바뀌는 양보다사라지는 양이 더 많아질 것임은 분명하지만,각 국의 정부들이 그 충격을 그대로 받아들이게놔두지는 않을 것이고, 서서히 연착륙하도록제도를 만들어갈 것이다.(기초소득제, 맞춤형 복지, 기계에 대한 세금 논의 등)인공지능으로 대체될 수많은 직업이 있음은 나 역시 공감하지만그로 인해 직업은 더 세분화하고, 새로이 만들어질 직업의규모와 사이즈가 어느 정도 될 런지 알 수 없다.다만, 인공지능이 세상 전부를 덮지는 못 할 것이다.아직도 인터넷과 모바일이 덮지 못하는 세상과 시장이 존재하고,그 간격은 새로운 니즈를 발생하며그 안에서 비즈니스와 가치가 창출되고 있다.6. 다른 분야를 관찰하라.다양하게 남의 기술을 적용해서 내 것으로 만들어라.하늘 아래 새롭게 창조되는 것은 없지만새롭게 변형되고, 조합되는 것은 있다.초기에는 획기적인 기술개발보다익숙하지만 무언가 다른 것이 더 낫다.공들이고,시간을 들이고,비용을 들여야 하는 진짜 핵심기술은 오늘을 살아내야 하는 스타트업에게는큰 부담이다.이번에는 급하게 쓰다 보니좀 글이 러프하다.세상이 어떻게 흘러가고 있는지예의 주시해야 바다 위에 돛단배 같은 우리가살아남을 수 있다.문득 뉴스 기사들을 보다가 생각난 김에 휘갈겨보았다. 
2017. 10. 17. 조회수 552

데일리호텔에 리뷰 노출하기

Background현재 데일리호텔의 업장(호텔 또는 레스토랑) 상세화면에서 실제 이용자 중 몇퍼센트가 이용에 만족하였는지를 보여줍니다. 이는 사용자들이 구매를 결정하는데에 중요한 요소가 됩니다.AS-IS 만족도 표시사용자들이 실제로 작성한 리뷰를 볼 수는 없습니다.이는 데일리호텔의 쉽고 간단한 예약서비스의 컨셉에서 비롯된 정책이었습니다. 사용자가 리뷰 내용을 하나하나 보는 수고를 덜고, 확실한 측정 결과(만족도)를 제시하여 고민하는 시간을 줄여주고자 했습니다.서비스 규모가 커짐에 따라, 리뷰를 꼭 읽어보고싶어하는 적극적인 유저가 많아지고, 비교적 고가의 지출에 대한 근거를 제시해야 하는 니즈가 커지고 있습니다. 이를 최대한 만족시킬 수 있도록, 점진적으로 리뷰시스템을 구축하여 리뷰를 앱에 노출시키고 고도화할 예정입니다.Insights1. 63% 유저는 리뷰를 읽고 제품을 구매 한다.2. 50개의 리뷰는 CVR을 4.6% 상승시킬수 있다.3. 구매자는 공급자의 상품 설명보다 리뷰 내용을 더 신뢰한다.4. 평가 점수 보다는 리뷰의 텍스트 내용이 중요하다.5. 나쁜 리뷰가 나쁜 것만은 아니다. — 서비스 개선의 기회가 될 수 있다.출처:https://conversionxl.com/user-generated-reviews/https://www.groovehq.com/support/deal-with-bad-online-reviewsPurpose & Mission우리는 리뷰 노출에 앞서, 리뷰 작성 화면을 정비하기로 하였습니다. ‘리뷰의 질과 양 늘리기’라는 목표를 가지고 아래 세가지 기준에 맞추어 개선하기로 하였습니다.Before 리뷰 작성 화면리뷰 항목을 정량 분석할 수 있도록 구조를 변경하여, 리뷰 결과를 데이터화 할 수 있도록 함텍스트 리뷰 입력을 지금보다 많이 받을 수 있도록 함유저가 리뷰를 입력할 수 있는 기회를 보다 많이 부여함리뷰의 질을 높이고자 하니 리뷰 항목이 많아졌고, 필수 입력 처리로 리뷰 완료까지의 조건이 까다로워졌습니다. 이에 따라 최대한 많은 양의 리뷰(텍스트 리뷰 포함)를 받는 것이 중요한 과제가 되었습니다. 이 과제의 포인트는 유저가 리뷰 작성팝업을 접했을 때의 거부감을 줄이고, 리뷰를 끝까지 작성하도록 encourage하는 것이었습니다.Action Items먼저, flow에 대해 많은 고민을 하였습니다. 매 항목 선택 후 화면이동을 할 것인가, 한 화면에서 스크롤하여 모든 항목을 선택하게 할 것인가를 두고 프로토타입을 만들어 사내 유저 테스트를 진행하기도 하였습니다.Flow AB Test그리고 유저의 감성을 자극하는 컴포넌트로 유저의 참여를 유도하였습니다. 귀여운 이모티콘 디자인에 애니메이션과 인터랙션까지 더하여 재미요소를 부여했습니다.<meta charset="utf-8">GUI & Animation+Interaction리뷰 입력 시에는 상황에 맞는 피드백을 제공하여, ‘리뷰가 곧 끝나겠지’하는 막연한 기대와 실망을 최소화하고자 했습니다.FeedbacksResults아직 확실한 결과를 보기에는 기간이 충분히 지나지 않았지만, 텍스트 리뷰까지 입력하는 유저의 비율이 어느정도 늘어나고 있는 것 같습니다. 강제 업데이트를 하지 않았고, 아직은 구/신 버전의 UI가 동시에 노출되고 있습니다.텍스트 입력까지 모두 완료한 유저 비율 변화 (만족도 입력 대비/전체 리뷰 입력 대상 대비)기대했던 결과가 나오는 것도 중요하지만, 그 결과를 기반으로 또 다른 개선을 이끌어내고 조금씩(그리고 계속) 이전보다 나아지는 것이 더욱 중요할 것입니다.끝. 디자인 관점에서 계속...#데일리 #데일리호텔 #기획 #기획자 #개발 #개발자 #인사이트 #후기 #일지
2019. 06. 17. 조회수 163

블록체인 진짜 하나도 모르는 디자이너의 독학일기(1)

독학을 시작했습니다. 스터디를 가려고 했는데 수많은 전문용어들이 제 영혼을 피폐하게 만드는 바람에 정신건강이 염려되었거든요. 포토샵도 혼자 배웠으니 이것도 못할까! 라고 자신있게 책을 폈는데 못할 것 같습니다.......그래도 산 책 값이 아까우니 읽고 공부한 내용들을 하나하나 정리해보고자 합니당! 블록체인 전문가님들이 혹시 이 글을 보신다면 노잼과 지루함내지는 유치함을 느끼실 수 있으니 엄빠미소로 지켜봐주시면 감사하겠습니다. 잘못된 부분이 있다면 바로 잡아주세요!!글을 쓰면서 5가지 원칙을 지킬겁니다.1. 꼭 써야하는 고유명사가 아닌 이상 어려운 단어는 쓰지 않습니다. 중학생 정도가 이해될 수준이길 제발 바랍니다...저는 블록체인을 이제 이틀 째 공부하고 있거든요.2. 가급적 팩트체크된 내용만 쓸겁니다.3. 제대로 공부하려면 경제사, IT기술, 코딩 등등..수많은 요소가 복잡하게 들어가지만 여기선 꼭 필요한 쏘옥 뽑아서 얘기할 겁니다. 4. 짧게 쓸 겁니다.5. 가끔 쓸 겁니다.(자주 쓰기 힘든 주제임..)시작합니당 :)블록체인이 왜 태어났는지 얜 뭔지부터 알아야 할 것 같아요. 그러자면 시간을 조금 되돌려서 우리는 어떻게 사고파는 경제활동을 해왔는지 살펴볼께요.1. 아주 오래전 = 기억하기종이란게 나타나기도 전 우리는 사과5개를 빨간집에서 해가 질 무렵에 씨앗10개와 교환했다. 는 걸 기억해야 했어요. 문제는 서로가 잘못 기억하거나 한 쪽이 다르게 우겨버리면 할 말이 없다는 거죠..철저히 신뢰와 기억에 의존한 거래였어요.2. 오래 전 = 나무나 가죽에 새기기원래 사람은 두 발로 직립보행 하기 전부터도 그림을 좋아했어요. 동굴에도 그리고 돌에도 그리고, 나무나 땅에도 곧잘 그림을 그렸죠. 뭔가 주고받는 물품이 많아지면서 기억하기가 힘들어지자, 이젠 가죽이나 나무 등등에 갯수를 남기기 시작했죠. 문제점은 그 가죽이나 나무가 훼손되거나 도난당하면 증명할 방법이 없다는 거에요.'동쪽 언덕 마을에서 온 또박이가 가죽3개를 사갔다.'3. 조금 오래전 = 종이에 적기(단식부기)종이가 발명되고 아라비아 숫자와 알파벳, 한글, 한자, 인도어 등등이 발달하기 시작하면서 문서를 남길 수 있게 되었어요!!! 문서를 남긴다는 건 굉장했죠!!!오랜 시간이 지나도 기록들을 잘 보관할 수 있었어요!! 거래를 할 때에도 수입과 지출을 한 번에 (가계부처럼) 적으면서 작은 종이에 많은 내용을 남길 수 있었답니다. 하지만..여전히 문제는 사람이었어요. 이를 위조하거나 없애버리면...? 또는 불에 다 타서 없어지면??4. 얼마 전 = 적은 걸 나눠가지기(복식부기)그래서 서로 함께 같은 내용을 공유하기로 했어요. 너 하나 나 하나. 그리고 그 과정을 감시하는 회계사. 이런 과정은 우리 조선시대에서도 아주 엄격했답니다. 특히 계문화가 발달했던 우리나라는 다양한 장부를 기록했는데 '용하기'라는 계의 장부기재는 정말 엄격한 원칙이 있었답니다!!1. 임시장부를 2부 작성해요. 이 때 회계담당자 이외 심지어 2명이 더 감시하고 있어요.2. 기재를 시작해요.3. 계원들이 다 모여야 하고 적은 내용을 크게 읽어요. 이 때 의심스러운게 있으면 이의제기나 수정을 해요.4. 계장과 두 명의 감시원이 있는 상태에서 최종수정해요. 그리고 계장이 서명해요.5. 중복된 장부가 있는지 확인하고 새 장부를 넣어 보관해요.엄청나죠???..놀라운 건 현재의 블록체인의 원리도 위와 비슷해요!! 다만 사람이 일일이 적고 감시하는 게 아니라 명령어에 의해 챡챡 처리되는 것 뿐이랄까요. 하지만 이것도 결국 '물질' 이다 보니....화재나 전쟁으로 인해 소실되어 버리면 그걸로 끝이었어요.5. 요즘 = 기관이나 중앙에 맡기기왕정체제가 아니라 민주주의와 시장경제가 도입되면서 은행이나 보험사, 카드사와 같이 경제활동을 담당하는 기업과 중앙기관이 생겨나기 시작했어요! 엄청나게 거대한 정보를 크으으은 서버나 금고에 보관할 수 있었어요. 그것은 영원해보이고 사람들은 오래도록 보관할 수 있다고 생각하니 관심을 끄기 시작했죠. 내 돈은 금고에 잘 있을 거니까요.하지만, 자본주의는 그런게 아니었어요. 은행은 내 돈을 다른 사람에게 대출로 빌려주고 그 이자로 돈을 벌어요. 그리고 다른 사람이 갚은 돈으로 다시 내 예금을 채우죠. 졸라 돌려막기인 거에요. 사람들이 끊임없이 돈을 빌리고 다시 갚을 수 있게 다양한 상품들을 만들어요. 이 방식은 굉장히 효율적이고 아무 문제가 없을 것 같이 보였어요.하지만, 해킹을 당했어요.은행을 털렸어요서브프라임 모지기론 사태처럼, 무리한 상품의 실패는 수백개의 기업을 무너뜨렸어요. 수많은 사람들의 돈이 한 순간에 날아갔어요.서버가 먹통이 되어 거래가 안되는 경우도 있어요.지진 등의 천재지변이 나면 내 기록은 사라지고 말아요.단순히 큰 사옥을 지닌 곳이니까 영원불멸할 것 같았던 중앙기관도 하루 아침에 무너질 수 있단 사실을 우린 수 차례 경험했어요. 그럼에도 우린 뭘 어떻게 해야할 지 몰랐어요. 우리가 할 수 있는 건 사고가 터지면 변호사를 써서 소송을 하는 것 뿐이었어요. 우린 은행의 상품이 정확히 어떤건지, 보험약관이 뭔지... 카드사는 어떤 원리로 움직이는지...내 세금은 어떻게 쓰이고 있는지...우리 돈이 어떻게 거래되고 내 돈을 가지고 그들이 무엇을 하는지 하나도 몰라요. 그냥 속수무책으로 그들만 믿고 있는 거예요. 6. 블록체인의 탄생 = 모두가 장부를 가질 수 있게그래서 생각해봤어요. 한 곳에 모여있으니 문제가 생긴다면, 쪼개면 되지 않을까? 은행 한 곳을 터는 것은 쉽지만 1,000여명을 한꺼번에 터는 것은 불가능할테니까. 계모임에서 쓰던 그 장부를 엄청나게 많이 만들어서 모두가 가지면 어떨까? 누굴 못 믿거나 위조하거나 털리거나 불나서 사라질 일이 없을 거 아냐?? 라는 생각을 말이죠. 그런데 친구가 질문을 하네요!!친구 : 그런데 어떻게??나 : 인터넷이 있잖아!! 내가 온라인상에서 거래하면 그 기록이 남잖아~ 그걸 모두가 공유하는거지! 친구 : 모두가 누군데?나 : 응 그건 이제부터 모아야해!!친구 : 그럼 어쨌든 모인 사람들에게 모두 공유하면 내가 어제 김치한포기 시킨것도 다른 사람이 알게 되는거야??나 : 아니지;;; 니가 뭘 시켰는지 그딴 건 관심없어..그냥 얼마 거래를 언제 몇시몇분몇초에 어떻게 했는가만 기록에 남는거야! 그리고 다른 사람은 그걸 직접 눈으로 볼 수 있는 게 아냐.생각해봐. 넌 브런치 로그인한 기록을 눈으로 다 볼 수 있어? 며칠 몇시에 얼마나 로그인했는지 알 방법이 없지? 하지만 그 기록이 있을까 없을까? 그렇지, 반드시 있다구. 범죄수사할때도 그러자나. 우리 화면에는 시간/내용밖엔 안뜨는 문자메시지지만, 실제로 서버에는 발신위치, 수신위치, 번호정보 등등이 모두 숨겨져 있잖아. 또 하나! 너가 네이버에서 틴트를 검색하면 나중에 페북에서 틴트광고가 뜨지 않아? 우리의 방문기록이나 클릭한 기록들이 모두 남아있기 때문이야.이렇게 우리가 눈으로 보는 화면 뒤에는 수많은 정보들이 컴퓨터만의 전기신호로 저장되어 있어. 우리가 말하는 장부도 이런 식으로 저장되어 있는거라구.  물론 필요하다면 그걸 화면으로 띄울 수 있는 명령어를 만들 수도 있겠지.친구 : 그건 이해했어, 내가 직접 볼 순 없지만 마치 사이트 방문기록처럼 어딘가에 거래내역이 다 남아있다는 얘기지?... 그런데 아까 지금부터 모아야 한다는 사람들은 어떻게 모으는거야??나 : 그건!!..바로!!!! 다음에 설명해줄께!!또 공부해서 돌아올께용!!
2019. 04. 15. 조회수 346

권한을 찾아서: GitHub Team을 이용하여 Kubernetes 계정 인증하기 (1)

“Numerous padlocks on a bridge railing” by Benjamin Bortels on Unsplash안녕하세요, Rainist의 DevOps 엔지니어 유희철입니다.요즘 컨테이너 기술의 사용이 확대되면서 Kubernetes(이하 k8s), Docker Swarm, Mesos 와 같은 컨테이너 오케스트레이션orchestration 툴의 사용도 필수적으로 자리 잡고 있는 것으로 보입니다.2015년 즈음에 서버 앱 배포 및 운영에 대해 본격적으로 관심을 가지기 시작하면서, 처음으로 Docker와 k8s를 접하게 되었습니다.Docker의 매력에 먼저 빠져들어 이런저런 서버 앱을 모두 도커화 (Dockerize) 하였는데 막상 실제 프로덕션에서 운영하기에는 고민되는 지점이 한둘이 아니었습니다. 오히려 도커화되지 않은 네이티브 앱을 다루는 것 보다 훨씬 더 골치가 아팠습니다. 특히나 Rainist같은 스타트업에서는 제품이 언제 빠르게 성장할지 모르기 때문에, 늘 서버의 클러스터링, 동적 스케일 아웃scale-out, 클러스터 내의 서비스 디스커버리 등이 요구되는데 그러한 것들을 모두 처리하기에는 어려움이 너무 컸습니다.이 모든 복잡한 과정을 수동으로 직접 관리한다는 건 조금만 장기적인 관점으로 봐도 그 한계가 분명히 보였기에, 이런 과정을 자동으로 관리할 수 있는 도구를 찾아야겠다는 생각을 했습니다. 그 당시 사실상 Ops 분야의 뉴비였던 저에게 적합한 툴을 찾는 리서치가 버거웠지만 적합한 후보가 나올 때마다 실제로 적용해보면서 옥석을 가려갈 수 있었습니다. 그러한 과정에서 Deis, Flynn, Dokku와 같은 툴을 살펴보거나 세팅을 시도했고, 대부분 원하는 바를 달성하기에는 적합하지 않아 절망했던 기억이 있습니다. 절망의 가운데 k8s를 발견하고 당시 알파 또는 베타였던 GKE(지금의 Kubernetes Engine)를 이용해본 뒤, k8s의 철학에 크게 공감하여 언젠가 꼭 유용하게 사용하리라 다짐했습니다. (그때는 제가 전문적인 백엔드 또는 Ops 엔지니어가 아니었기에 실제로 k8s를 활용하기에는 기회가 한정적이었습니다.)그런 아쉬움을 가지고 있던 와중에, 2017년에 Rainist에 DevOps 엔지니어로 합류하게 되었습니다. 회사에서도 DevOps 전담 엔지니어는 처음이었고 DevOps의 대한 니즈가 마침 필요하였기에 전폭적인 지원을 받으며 드디어 k8s 를 십분 활용하기 시작했고, 서서히 뱅크샐러드의 마이크로서비스들이 하나둘씩 k8s 위에서 운영되기 시작했습니다. 다행히 그동안 k8s도 기능과 이용자 규모의 측면에서도 폭발적으로 성장하여 점점 더 프로덕션에서 활용하기에 충분한 도구로 발전하고 있었습니다.제가 Rainist 엔지니어링 블로그에 처음으로 글을 작성하다 보니 서두가 약간(?) 길었네요. 이제 이 글의 진짜 목적에 대해서 집중해보도록 하겠습니다.k8s는 한 번 세팅만 잘 되어 있다면 사용하는 입장에서는 아주 편한 툴이지만 사실 클러스터를 처음에 구성할 때는 부분에서는 마냥 쉽다고 말하기 힘듭니다.가장 쉽고 편하게 클러스터를 구성하고 운영하는 방법은 GCP의 Kubernetes Engine을 사용하는 것이지만 여러 가지 이유로 AWS를 사용해야 할 경우가 있습니다.Rainist도 현재는 AWS에서 k8s 클러스터를 구성하는 게 유리하다는 판단으로 EC2를 활용하여 클러스터를 운영하고 있습니다. k8s 클러스터를 처음부터 일일이 구성하는 것이 불가능하지 않지만, 기술적인 어려움, 많은 시간 소요, 올바르게 설정되지 않을 수 있는 리스크등이 있기 때문에 세팅을 도와주는 도구가 많이 존재합니다. 저는 개인적으로 CoreOS에서 만든 Tectonic을 사용 해본 적이 있었고, 당시에 Rainist에서는 kops를 사용하고 있습니다. kops를 사용하면 비교적 쉽게 클러스터를 구성하고 바로 사용할 수 있지만 모든 것이 다 원하는 대로 준비가 되어있는 것은 아닙니다.kops 의 기본적인 구성을 사용하면서 아쉬운 부분을 몇 가지 나열해보면Networking — 기본 kubenet의 경우 노드를 50개 까지만 지원Ingress — AWS Console에 접속하여 Security Group의 설정을 따로 변경해줘야 함Authn/Authz (이하 Auth) — 관리자, 개발자별 아이디 발급 및 권한 설정하는 부분이 굉장히 까다롭거나 손이 많이감등이 있는데요, 그중에서 Auth는 모든 팀에게 상당히 중요합니다. 왜냐하면, k8s 활용을 극대화하기 위해서는 다양한 개발자들이 목적에 필요한 권한을 필요로 하는 즉시 바로 얻을 수 있어야 하기 때문입니다. 권한이 없어서 서버 앱을 배포하지 못하는 것만큼 시간 낭비가 없겠죠? 또 나중에 시간이 지나서 팀원이 퇴사한 경우에는 서버의 보안을 위해서 그 즉시 해당 팀원이 가지고 있는 권한을 삭제할 수 있어야 합니다.이런 기능은 팀에서 GitHub 을 사용해 보셨다면 아주 간단하게 Member를 추가하고 권한을 부여하고 또 손쉽게 삭제하는 경험을 해보셨을 겁니다.하지만 k8s 클러스터에는 이런 기능을 손쉽게 사용할 수 있는 UI는 커녕 CLI 명령어조차 없다시피 합니다. 결국, 시스템 설정을 건드리는 등의 작업을 해야 하는데 문서를 보고 바로 적용할 수 있는 수준과는 거리가 있고 막상 작업하더라도 손이 많이 가죠. Kubernetes Engine이나 Tectonic 또는 앞으로 출시될 AWS EKS 를 사용한다면 이런 기능은 지원이 되겠지만 저희는 현재 저희가 직접 설치한 클러스터를 사용하고 있으니까요.결국, 이런 어려움으로 인해, 일반적으로 권장되지 않는 practice인 /.kube/config 파일 등을 공유하여 사용하게 되는 일들이 종종 있을 수 있겠죠. 그렇게 되면 누가 어떤 액션을 취했는지 (프로덕션 서버에서는 아주 중요한 정보이죠) Auditing이 불가능해질 뿐더러 퇴사자가 생길 때마다 인증 정보를 변경해야 하며 모든 사람이 같은 권한 (cluster-admin) 을 가지고 있는 불편하고 또 불안한 상황을 마주할 수 밖에 없게 되겠죠?이러한 상황을 k8s 공식/비공식 개발팀에서도 인지하고 있으며, 관련하여 여러 가지 방안을 내놓고 있습니다. 그중의 하나가 k8s 의 인증방식 중 하나인 OIDC 를 이용한 dex 를 이용하는 방식입니다. (참고 — 데일리 호텔의 사례)하지만 OIDC 를 쉽게 사용할 수 있도록 도와주는 dex 조차도 설치해서 운영하는데 만만치 않은 기술적인 도전과 복잡도가 있었기 때문에 썩 내키지는 않았습니다.그러다 얼마 전에 Webhook Token Authentication 방식을 이용하는 AppsCode의 Guard라는 오픈소스 툴을 발견하고서 희망을 품어보았습니다.그래서 바로 시도해본 결과, 결론부터 말씀드리면 아주 만족스럽게 k8s cluster 의 Auth 이슈를 해결할 수 있었습니다!실제로 어떤 과정을 거쳐서 적용했는지는 이어지는 다음 포스트에서 확인해보세요!#Github #Kubernetes #개발 #경험공유 #레이니스트 #Rainist #엔지니어링블로그 #레이니스트개발자
2019. 08. 05. 조회수 457

슬라운드 브랜드 아이덴티티(B.I)개발기 - 2화

1. 브랜딩 대체 무엇?요즘 어디에나 브랜딩이 적용되지 않는 곳이 없습니다.자기자신까지 브랜딩 해야 한다고 말하는 시대입니다.브랜딩 대체 정체가 뭐죠?그런데 대체 브랜딩이 뭘까요?일반적으로 특정 브랜드의 로고나 심볼 등 시각요소들을 만드는 것이라고 생각하기도 하고,학교에서 공부하는 브랜딩의 정석과 같은 서적은 브랜딩을 위한 전략을 6단계로 나누어 약 300페이지에 달하는 방대한  내용으로 설명합니다.요약하면,- 브랜드에서 디자인은 매우 핵심적인 요소이기 때문에 전략적으로 디자인계획을 수립해야 한다.  (중요한거 알죠..)- 브랜드는 사용자의 마음 속에 존재하며, 그들의 경험을 통해 형성된다.  (마음에 존재한다..?)- 디자이너의 일은 사용자가 가치를 느낄 수 있는 경험을 만드는 것이다.  (경험을 만든다..?)이런 내용들인데, (중요하단 말을 300페이지로..) 너무 맞는 말인데 실제로 어떻게 적용할 수 있을까요?사실 너무 어렵게 생각하는 성격이 아닌데도, 브랜딩을 공부할수록 단순히 로고랑 패키지만 만드는 작업이절대  아니라는 생각에 더욱 어려워지는 것 같아요..그래서 좀 더 브랜딩에 쉽게 접근하기 위한 질문들을 몇가지 던져 보았습니다. 우리가 고민해야 할 것들 !!너무 많은 욕심을 부리지 않고 이러한 질문들을 바탕으로 슬라운드가 지향하는 가치를 브랜드 기본요소 (logo, graphic, color, typeface, space 등)들에 하나씩 녹여내 보기로 했습니다.2. 첫번째 단계 : 브랜드 기본요소 점검본격적인 브랜드 아이덴티티 개발에 앞서  먼저 슬라운드의 최초 브랜드 기본요소들을 점검해보았습니다.진단 1현재 Brandon Grotesque 라는 서체로 만든 워드마크 타입의 로고를 사용하고 있어요.모서리가 둥글둥글한게 메모리폼 매트리스의 포근함을 반영하려 했던거 같기도 하고..(추측)진단 2슬라운드 로고들이 독립적으로 사용될때고 있고, 네모박스 안에 갇혀있을 때도 있어요.일관성과 위계질서 있는 로고 사용 규칙을 정해야할 것 같아요.진단 3기본 컬러는 '파랑' 또는 '군청색'이라고 불리는 색을 사용하고 있는데, 상황에 따라 진한파랑, 밝은 파랑 등 자유분방하게 적용되어 있어 어떤 색이 브랜드 컬러인지 명확하게 알수가 없네요.3. 두번째 단계 : 슬라운드 브랜드 철학과 가치 살피기브랜드 기본요소들 현 상태를 진단을 완료했으니, 이제 이 요소들에 실질적으로 녹여낼 슬라운드의 브랜드 철학과 가치를 다시한번 살펴보기로 했습니다. 앞서 1화에서 이야기했듯이 스타트업이지만,브랜드 가이드라인을 토대로 창업자들이 슬라운드가 추구하는 가치와 철학은 어느정도 방향성이 있는 상태였는데요. 가이드 설정 이후 그동안 몇개월의 시간이 흐르면서 점점 더 많은 고객들이 슬라운드 매트리스를 사용하게 되었고, 새로운 팀원들도 합류하게 되면서 초기에 창업자들이 설정한 브랜드 철학에서 조금씩 변화한 부분들도 생겼고 고객들이 새롭게 만들고 인식하는 슬라운드의 이미지들도 드러나고 있었습니다.브랜드 철학 :장인적신, 배려심, 실험정신브랜드 아이덴티티 : 전문적인, 센스있는 (배려심있는), 친근한, 고급스러운, 새로운 것을 시도하는그리고 무엇보다 최초에 설정된 8가지의 키워드를 모두 담기에는일관성 있는 하나의 이미지를 만드는데어려움이 있었기 있었습니다. 예를들어 전문적이면서 센스있는? 정도의 아이덴티티는 상상이되지만, 고급스러우면서 새로운 것들 시도하는?은 직관적으로 인상을 떠올리기가 쉽지 않죠.그래서  팀원들과 함께 슬라운드의 철학과 가치를 다시한번 살피고 방향성 재설정하기로 했습니다.팀원들에게 슬라운드에 담고 싶은 철학과 가치(키워드) 들을 여러단계에 걸려 질문하고, 브랜드 생성 과정과 핵심적인 제품 개발 과정을 꼼꼼히 관찰해보았어요.슬라운드 열심히 관찰중..팀원들과 함께 모은 슬라운드 키워드들 !생각보다 너무 많은 키워드들이 모여서 브랜드 철학과 가치를 정리할 수 있는까하는걱정이 되었지만, 시간을 들여 관찰을 하다 보다 같은 이야기를 하는공통된 입장의 키워드들이 묶이기 시작했습니다.그리고 최종으로 4개의 키워드로 브랜드 철학이 정리되었습니다.최종으로 정리된 슬라운드의 철학. (2018.10.05)- 제대로 만드는- 솔직한- 기본의 방식을 답습하지 않는- 합께하는이 4가지 철학을 장인정신 / 진정성 / 신뢰 라는 핵심가치들로 묶어서브랜드 기본요소들이 녹여내기로 했습니다.이렇게 점검하기와 관찰하기 2단계의 준비과정 통해  앞으로 진행할기본적인 브랜드 아이덴티티 개발 방향을 설정했습니다.1) 슬라운드 브랜드 철학과 가치를 좀 더 효과적으로 담아낼 것2) 네이밍에 담긴 Sleep Soundly 라는 의미가 로고에서 좀 더 전달 되었으면! (컬러나 서체 등)3) 이름이 유사한 S 사와는 이미지가 명확히 구분되도록 할 것이어서 3화에서는 3가지 개발방향을 토대로 계획한 슬라운드의 브랜드 기본요소들을 하나씩 소개할 예정입니다.
2019. 01. 31. 조회수 382

날짜 변환, 과연 그리 간단할까?

안드로이드에서는 입력한 날짜를 변환 및 검증하는 로직을 간단하게 구현하기 위해 SimpleDateFormat 클래스를 종종 활용하게 되는데 이 클래스는 규칙에 관대하다(lenient)는 재미난 특성이 있습니다. java.text.SimpleDateFormat 클래스의 근간이 되는 java.text.DateFormat 클래스의 다음 API 문서를 살펴봅시다.By default, parsing is lenient: If the input is not in the form used by this object’s format method but can still be parsed as a date, then the parse succeeds. Clients may insist on strict adherence to the format by calling setLenient(false).파싱 기본 동작은 관대합니다. 이 객체의 날짜 포맷과 일치하지 않는 입력이 주어지더라도 날짜 형태만 유지한다면 파싱이 성공합니다. 클라이언트 코드에서는 setLenient(false) 메소드를 호출해 파싱 규칙을 여전히 엄격하게 가져갈 수 있습니다.lenient 라는 흔하지 않은 단어 때문에 의미가 잘 와닿지 않습니다만, 캠브릿지 영영사전에 따르면 ‘관대하다’ 라는 뜻이 있다고 하네요.lenient /ˈliː.ni.ənt/ ▶ adjective ▶ Level C2(Mastery Proficiency)A lenient punishment is not severe.Thesaurus: allowing, forgiving, merciful, permissive, tolerant하지만 규칙에 관대하다는 말이 무슨 의미인지 여전히 와 닿지 않습니다. 잠시, 아래의 소스코드를 읽고 그 결과를 한번 예측해 볼까요? parse 메소드는 기본적으로 lenient 하다는 특성에 주의합시다./* * 2017년 13월 32일 이라는 입력에 대해 어떤 결과가 나타날까? * 1. 2017-13-32 * 2. 2018-02-04 * 3. 2017-01-01 * 4. 2018-01-01 * 5. ParseException 이 발생 */ val userDate = "2017-13-32" val date = SimpleDateFormat("yyyy-MM-dd").parse(userDate) val localDate = LocalDateTime.ofInstant(date.toInstant(), ZoneOffset.UTC) println ("사용자의 ISO-8601 Date 입력 결과는 ${localDate.year}년-${localDate.month}월-${localDate.dayOfMonth}일 입니다.") lenient 라는 사전 hint 없이 바로 문제를 낼 경우 사람들이 제일 많이 선택한 결과는 ParseException 이 발생한다 였습니다. 하지만 lenient 한 특성으로 인해 실행 결과는 의외로 두번째, 즉 2018년 2월 4일 입니다. 막상 글로 풀어 쓰려니 별 것 아닌 내용처럼 보입니다만, 필자가 담당하는 서비스에서 이 특성을 제대로 파악하지 못해 특정 사용자의 생년월일을 제대로 인식하지 못한 문제가 있었습니다.또한 우리가 흔히 아는 달력을 쓰지 않는 국가도 있다는 점 까지 고려한다면 날짜 변환이라는 것이 간단한 문제가 아니게 됩니다. 즉, 한국인의 관념 속의 ‘달력’ 이란 Gregorian calendar 를 기반으로 한 ISO-8601 달력 입니다. 그런데 이 달력을 쓰지 않는 문화권도 있습니다(한국도 흔하진 않지만 ‘단기’ 라는 별도의 달력을 쓰기도 합니다). 이런 문제 때문에, 글로벌 서비스를 준비하고 계신다면 날짜 변환 문제를 꼭 점검해 보셔야 합니다.Android 에는 이 문제를 해결해 주는 클래스가 있습니다만 불행히도 API Level 이 26이나 되어 2018년 현재에는 제대로 쓰긴 어렵습니다. 다행히도 이 문제를 보완한 joda-time 라이브러리의 안드로이드 포팅 버전도 있으니 이 라이브러리의 도입을 검토해 보는 것도 좋은 문제 해결 방법이 될 것입니다.#개발 #인사이트 #하이퍼커넥트 #개발자 #안드로이드 #개발후기
2018. 05. 25. 조회수 832

콜라보 꼭 필요한가요?

파펨은 “콜라보(Collaboration)”라는 일종의 유행을 따라 콜라보를 하는 것은 아니다. 오히려 이런 유행스러운 것들에 대해서는 "지양" 하는 성향이 강하고.. 남들이 하지 않는 것을 우리가 한다!라는 나름 도도한 스타트업이다.^^;;그래서 콜라보를 진행하는 것에 대한 나름의 원칙을 가지고 있는데.. 그것은 1) 서로의 약점을 보완해줄 수 있어야 하고, 2) 서로 함께 했을 때 시너지가 날 수 있어야 한다. 거기에 추가하여 파펨에게 콜라보의 이유를 묻는 다면..생존을 위한 것것이라고 답할 수 있겠다.  파펨은 시즌 7까지는 자체적으로 매 시즌의 이미지 카드를 직접 디자인, 편집하였으나.. 물리적인 한계에 봉착하게 되었다. (파펨은 매달 4가지의 향수를 출시하고, 그 향별로 이미지카드 하나씩을 만들어내는 작업을 한다.) 지금의 인력 구조로는 우리가 모두 직접 하는 것이 생각보다 힘들었다. 매달 마감을 하는 기분이랄까?파펨의 이미지 카드 : 향을 나타내는 이미지, 스토리, BGM 등으로 향을 공감각적으로 즐길 수 있도록 기획또한 파펨은 광고비 지출을 하지 않기 때문에, 파펨을 알려줄 수 있는 contents와 채널을 가진 다른 entity와의 협업을 통해 파펨을 알리기 필요했다 .파펨은 매달 네가지의 새로운 향기가 출시되는데, 기존의 제품들(재고)에 대한 추가 판매 방법을 찾아야 하는 것도 하나의 고민이었다. 이러한 생존 때문에 콜라보를 진행하기도 하지만.. 파펨은 처음 서비스를 기획하는 시점부터 콜라보를 하는 것에 유연하게 대응할 수 있는 사항들을 고민하고, 반영하여 서비스를 design 하였기 때문이다. 첫 번째로, 많은 상품/서비스들이 "후각"의 영역이 비어있음. 후각이라는 것이 우리 주변에 어디든지 있지만, 그러한 것들을 상품에 담기는 쉽지 않다. fashion, 영화, 음악, 일반 상품 등등은 대부분 "시각" 혹은 "청각"의 영역에 집중하고 있기 때문에, 파펨과의 콜라보를 통해 서로 부족한 점을 매우기 쉽기 때문이다.두 번째로, 다양한 design을 소량 생산하기 적합. 어떤 제품/서비스를 콜라보 파트너와 진행하기 위해서는 customization 작업이 필요한데, 파펨은 파트너와 다양한 영역에서 조정 작업이 가능하다. 향을 표현하는 image card의 경우도 쉽게 인쇄를 통해 변경 가능하고, 또한 30ml 제품의 경우는 각인 기계를 직접 구매하였기 때문에, 우리가 원하는 메시지를 쉽게 각인하여 넣을 수 있다. 아래 사진은 우리와 함께 작업하였던 브랜드 예시위와 같은 이유로 다양한 콜라보 사례를 만들 수 있었는데....자동차 회사, 패션 브랜드, 영화 그리고, 계속해서 artist들과의 향기를 표현하는 협업까지 다양한 경험을 할 수 있었다.  BMW mini clubman launching : Gentleman의 컨셉을 강조하고 싶었던 mini에게 그 느낌을 표현한 향수로 협업 진행Fashion brand, ROCKET X LUNCH 2016 FW season : 열반(Nirvana)라는 컨셉에 맞는 향을 함께 선택하고 패션위크 참석자 분들에게 선물Movie, A Bigger Splash : 영화 촬영의 배경인 지중해의 느낌을 살린 향수로써 영화와 향수를 동시에 홍보Image card with Many Artists (백두리, Autistar, 윤만세, 윤군, 쿠밍 등) : 매달 발행되는 파펨의 향기와 어울리는 이미지, 스토리, BGM등의 작업을 작가들과 공동 진행파펨이 생각하고 있는 브랜드 identity 표현하는 하나의 방법으로써 향기를 사용하는 것 (예를 들면, 아베크롬비 매장 및 의류 상품에 짙게 배어 있는 그 향수) 사업 영역 또한 파펨이 생각하고 있는 콜라보라는 범주안에 들어갈 수 있을 것이다. 앞으로도 기대해 주시길~~#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트

기업문화 엿볼 때, 더팀스

로그인

/