무언가를 강제하고 통제하기 전에 생각하게 하는 것이 중요하다. 그 동안 '정책이요'  '제도요' '윤리요' 하는 미명하에 통보되는 것이 얼마나 많았던가. 오늘 사소한 사내 공지글을 보고 새삼 깨닫게 됐다. 그래서 감사하다.지금 이 회사는 물류사, 제조사, 에이전시를 막론하고 수많은 기업들과 협력관계에 있다.모두 파트너가 되어 CSV적 가치에 알맞게 공유가치를 창출한다. 지금 이 회사는 젊은 에너지로 탄력을 받고 있다. 실제 구성원들 대부분이 젊다. 다양한 경력과 전문성을 보유한 인재들이다. 하지만, 나를 포함한 모두가 우리의 아버지, 어머니에 버금가는 삶을 살지 못했다. 아직. 수많은 상황에서 빚어지는 고비를 겪어보지 못했을 수도 있다.이러한 상황을 인지해서 일까, 이 회사는 언제나 소통을 선택한다.풍성한 한가위가 다가오고 있다. 구성원들이 뜻하지 않게 선물을 받을 수도, 한순간 큰 호의를 경험할 수도 있는 상황이다. 이때 이 회사는 "이러한 규정을 따르시오"가 아니었다. 방향에 대해 함께 고민하고 생각해볼 수 있게끔 한다. 그리고 이내 모든 구성원들이 이해할 수 있게끔 한다. 이 회사의 아름다운 가치 중 하나 '상식이 통하는 회사를 만든다'이기 때문일까. 아래는 공지글 전문이다.<대외선물 게시판을 만들었습니다>by. 블랭크 피플유닛1. 우리는 모를 수도 있습니다.블랭크는 수많은 기업들과 함께 일합니다. 그러면서 좋은 관계를 맺고 서로에게 감사의 표시를 하기도 합니다.하지만 이는 물질적으로 이루어졌을 때 서로에게 큰 부담이 될 수 있습니다. 감사의 마음은 아름다운 글과 말로 자주 표현되길 바랍니다.그러나 명절, 담당자의 경조사, 연초/말에 관계사로부터 각종 선물이 오는 경우가 많이 있습니다. 기업에서는 선의로 주는 선물, 연례행사로 생각하실 수도 있지만, 어쩌면 우리가 주요한 고객사의 입장에 있는 만큼 부담을 느끼실 수도 있습니다. '안주면 서운해하지 않을까' '업무적으로 불편한 관계가 되지 않을까'불필요한 염려를 하실 수 있습니다. 그렇기 때문에 우리가 먼저 정중한 거절을 해야 합니다.선물을 보내기도 전에 절대 보내지 말아달라고 미리 이야기하면, 선물을 보내달라고 압박을 하는건가? 라고 오해하실 수 있습니다. 또한 정중한 거절을 하더라도 또 보낼 수도 있습니다. 이러한 경우라도 노력해야 합니다. 명절이나 개인의 경조사 등에 부담을 가지고 선물하지 않아도 되는 상식적인 회사가 되기 위해선 블랭커들의 지속적인 노력이 필요합니다.2. 좀 더 빠르게 상식적인 회사가 되는 방법많은 사람들이 '블랭크는 진짜 상식적인 회사'라고 생각할 수 있다면, 동등한 관계에서 함께 성장하는 협력관계라고 생각할 수 있다면 정중한 거절을 필요로 하는 상황을 앞으로 줄여나갈 수 있습니다. 다음의 방법들을 제안합니다.→ 모든 커뮤니케이션(전화, 이메일, 문자 등)에서 예의는 필수→ 격분, 서운함, 아쉬움 등 감정적인 반응은 배제 → 대응이 필요한 상황에서는 논리적이게, 그리고 매너있게→ 빈말은 농담이 아닌 부담, 빈말 NO→ 프로로서 모든 상황에서 객관적인 선택을 최우선으로3. 마음만 감사히 받겠습니다.'이번부터' 꼭 보내주시지 말아달라고 부탁하는 것을 잊지 말아야 합니다. 다음부터가 아닌 '이번부터' 인 이유는요결국 이번에는 받았기 때문에 다음으로 이어질 수 있는 상황이 있을 수 있기 때문입니다. 또, 우리의 정중한 거절이 단지 한 차례 웃으며 건내는 빈말이 될 수 있기 때문입니다.회사 윤리규정상 받을 수 없음을 분명하게 밝혀주시고 회사의 퀵서비스나 택배를 통해 최대한 빨리 돌려주세요. 그렇지만 정말 마음은 꼭 받으십시오. 그리고 보내주신 마음은 정말 감사하다고 말씀드립시다.4. 책임은 블랭크가 집니다.선물을 받고 이를 다시 돌려드렸지만, 우리의 뜻과는 달리 이야기가 와전되거나 반송의 문제, 예기치 못한 문제 등등 곤란한 상황이 발생할 수도 있습니다. 우선, 오해가 발생하지 않도록 선물과 관련된 사항들은 블랭크팀 전체에 공유해주시고 판단하기 어려운 상황은 언제든지 피플유닛으로 문의주세요. → 선물을 받고 정상적으로 돌려준 경우→ 커피한잔 등 돌려주기 애매한 선물을 받은 경우→ 반송할 경우 상하기 쉬운 생물의 경우→ 통상적으로 받을 수 있는 선물이라고 생각되는 경우→ 꼭 받아달라고 다시 보내는 경우→ 상황상 거절하기가 너무나 어려운 경우책임은 블랭크가 지겠습니다.판단이 어려운 모든 경우를 알려주시면 케이스별로 저희 피플유닛에서 자세히 안내드리겠습니다.Jason KH커뮤니케이션    기획자

이런 팀을 만나고 싶다고 쓴 적이 있다.- 한 팀으로서 끈끈한. 함께 추구하는 뚜렷한 목적을 가진-다같이 똘똘 뭉쳐 으쌰으쌰 응원하며 문제를 해결해나가는-각자가 할 일과 한 일을 공유하며 긴밀하게 협조해나가는-성장 목표를 세우고 주기적으로 다함께 결과를 체크해나가는-중간 중간 방향성에 대한 의견을 나누며 방향을 수정하고 전략을 수정하는-상호 존중하는, 인간적으로 수평적인 관계인-늘 즐겁게 일하려는 마음을 잃지 않고 살아가는-점점 성장하는 것이 눈에 보이는1년 전부터 경험을 하면서 내가 어떨 때 스트레스를 받고 어떨 때 가장 행복한지 순간순간 성찰했다. 글로 적었다. 시간이 갈수록 점점 또렷해졌다. 성찰했던 것을 바탕으로 이번에 구직을 하면서부터는 내가 원하는 팀, 나랑 잘맞는 팀이 어떤 팀인지 생생하게 그렸다. 그리고 적극적으로 찾아다녔다. 물론 모든 게 맞는 팀은 없을 수도 있다고 생각했다. 그러나 이번 연말까지는 포기하지 않고 찾겠다고 결심했었다. 연말로 기한을 설정해두었기 때문에 더 열정적으로 찾았는지도 모른다. 내년에 덜 맞는 팀에 지원할 때 미련 없이 지원하고 싶어서. 더 정확히는, 위에 써놓은 모든 게 맞는 이런 팀은 있다고 굳게 믿었다. 나랑 연이 안 닿을 순 있다하더라도.그래서 꼭 찾고싶었다.그리고 적극적으로 팀을 찾은지 두달 만에 감사하게도 정말 이런 팀을 만났다. -모든 사람들이 행복하게 일하는 대한민국을 만든다는 뚜렷한 목적을 함께 추구하며, 그 목적을 이루려는 과정에서 부딪치는 문제들을 똘똘 뭉쳐 해결해나가고 있다. 측정 가능한 목표를 세우고 매일 주간 월간 성과를 체크하며, 주간회의, 일일 작성, 또는 실시간으로 할 일과 한 일을 공유한다. 나아가는 방향성에 대해서 점검하며 누구나 의견을 꺼낼 수 있다. 필요할 경우 유연하게 방향과 전략을 수정한다. 지시와 요청은 있어도 성희롱, 사업놀이, 꼰대는 없다. 서로 이름을 부르며 함께 이런 저런 대화를 하며 밥먹는 시간이 즐겁다. 심지어 나의 유별난 입맛도 존중해준다. 모두가 자신이 하는 일을 통해 성장하겠다는 마음으로 일한다. 공허함은 없고 즐거움이 있다. 프로답게 일하게 되고, 성장할 수밖에 없게 된다.-일을 대하는 마음가짐과 일을 하는 방식이 잘 맞으니 회사생활이 즐겁고 행복하다. 마음이 든든하다. 앞으로 예상치못한 트러블들이 생길 것이다. 그러나 내게 가장 중요한 것들이 잘 맞으니 다른 부분들은 감안하고 감사할 생각이다 :) 슬기롭게 풀어나갈 수 있겠지. 감사하고 행복한 요즈음이다.

올해 첫 신상으로 야심 차게 준비했던 스트레스컴퍼니의 감정카드가 인쇄사고가 났습니다... 두둥.... 보통 인쇄를 맡기면 감리를 가는데, 오래 거래하던 곳이기도 하고, 색감도 잘 맞춰주셨던 곳이라 독감의 여파로 그냥 믿고 맡기기로 했던 것이 화근이 되어버린 것입니다...원래 일정대로라면 월요일에 내 손에 들어왔어야 할 카드들인데, 총 50장 중 반이 앞뒤가 바뀌어버렸다고 합니다. 인쇄 끝났을 때 한 번만 확인했어도 알 수 있었을 문제를 코팅에 도무송까지 끝나고 나서야 인지하고 알려주신 사장님이 야속했지만;;; 아파서 정신없는 와중에 파일 체크를 제대로 하지 못했던 저의 탓이 더 크므로 남 탓은 하지 않기로 했습니다. 그렇지만 제 탓이라고 후회하지도 않을 겁니다. 자책한다고 이미 잘못된 인쇄가 다시 제대로 찍히는 것도 아니고, 기분이 나아지는 것도 아니기 때문입니다. 이미 벌어진 일에 자책은 짧게다음엔 더 철저하게 파일을 챙겨야겠다고 다짐하며 자책을 끝냈습니다. 어찌 됐던 카드는 다시 인쇄가 들어갔고, 어제저녁 다시 후가공을 마치고 나왔습니다. 대박이 나려고 액땜을 두세 번씩 하고 있는 것 같은 느낌적인 느낌입니다... 후덜덜 기존 내편 감정카드 10장기존 캐릭터들은 저작권 등록이 되어있었지만, 9개였던 카드를 50개로 확장하면서 늘어난 아이들을 어떻게 저작권 등록을 해야 하나 알아보다 보니, 개인이 직접 온라인에서 등록하면 1건당 2만 원에 할 수 있다는 사실을 알게 되었습니다. 이전에는 그걸 모르고 변리사 통해서 건당 30만 원에 했었...;;(다행히 등록비용을 지원받았었습니다만) 이번에는 그 작업을 직접 하기로 하면서 저작권위원회에 전화 상담을 자주 시도했는데, 그러다 이전의 제가 굉장히 중요한 실수를 했다는 사실을 알게 되었습니다... 2015년 첫 캐릭터의 저작권을 등록하던 당시에도 스트레스컴퍼니를 하고 있었는데, 어차피 내가 만든 거고, 또 내가 만든 회사니까 별다른 고민 없이 캐릭터의 저작권을 개인으로 등록했었는데요. 그런데 회사의 재산을 개인으로 저작권을 등록하면 허위등록으로 간주되어 보호를 받을 수 없다는 사실을 알게 되어 버린 것입니다. 그리고 저작권위원회에서는 그것을 바로 잡는 방법은 개인으로 등록한 저작권을 말소하고 다시 회사 이름으로 등록하는 방법뿐이라고 했습니다. 그렇게 하지 않으면 허위 등록으로 보호받을 수 없다고 하니 저로서는 다른 선택권이 없더군요..... 또르르. 왜 그 당시 변리사가 그 부분에 대해서 어떤 언급도 해주지 않았는지는 이해할 수 없었지만, 그 또한 지난 일.. 이 헛발짓 덕분에 고급 지식을 얻었다는 사실에 감사하며, 비싼 돈을 주고 등록했던 소중한 저작권들을 내 손으로 직접 말소 신청을 하고 다시 회사 계정으로 가입해서 다시 저작권을 신청했습니다. 휴우.. 한국저작권위원회  https://www.cros.or.kr이미 벌어진 일에 자책은 짧게어이없는 실수로 생각지도 못했던 비용이 들어가다 보니 정말 당황스러웠지만.. 그래도 지금이라도 알게 돼서 다행이라고 생각했습니다. 혹시나 저작권 분쟁이 생겼을 때, 그걸 알았다면 얼마나 땅을 치며 후회했을까요. 다음엔 좀 더 세심히 챙겨보겠다고 결심하며 두 번째 자책을 마쳤습니다. 그래도 직접 저작권을 등록하는 일은 간단하더군요. 이미지를 올리고 캐릭터에 대한 설명을 쓰고 비용을 결제하면, 신청이 완료되는데 설명이 부족하면 다시 보완하라고 예시까지 써서 알려주시더라고요. 친절한 저작권위원회. 그렇게 무사히 저작권 등록을 마쳤고, 감정카드도 제 손에 들어왔습니다. 반갑다 얘들아!!!저는 지금 행복해요!당신, 오늘 기분 어때요?모르겠는뒈?우리는 친구들에게 "밥 먹었니?"라는 인사는 하지만, 기분이 어떠냐고는 잘 묻지 않죠. 왜??? 어색해서. 쑥스러워서. 해본 적이 없어서... 등등의 이유는 많겠지만, 이제는 우리도 알고 있습니다. 우리의 감정이 얼마나 소중한지 말입니다. 앞으로는 스트레스컴퍼니의 감정카드로 당신과 나의 감정의 안부를 물어봐 주세요.  귀여운 50장의 카드는 11cm x 8cm 틴케이스에 포장될 예정입니다.오늘의 감정하루에도 몇 번씩 오르락내리락하는 내 마음. 자기 전까지 기억에 남아있는 감정들을 감정카드로 하나씩 꼽아보며 "오늘 내 마음이 이랬구나." 하고 감정을 읽어주세요. 힘든 감정이라고 회피하거나, 무시하지도 말고요. 분명히 있는 감정을 모른척하면 어느 순간 치밀고 올라올지 모르거든요. 감정을 받아들여야 흘려보낼 수도 있습니다. 인정하고 싶지 않은 감정일지라도 그 마음을 받아들이고, 내 마음이 이만큼 괴로웠구나 하고 인정하고 나면, 언제 그랬냐는 듯 그 감정은 더 이상 나를 괴롭히지 않을 거예요. 그렇게 해도 힘들다면, 감정 다이어리를 써보세요. 힘든 감정들을 글로 쓰는 만큼 감정을 비워낼 수 있습니다. 친구들에게 조차 내 마음을 터놓기가 어렵다면, 어느 순간 연인과 거리가 멀어진 것처럼 느껴진다면,  감정카드를 펼쳐놓고 이야기를 시작해보세요. 서로의 감정에 맞는 카드들을 골라보고 카드 뒷면에 적힌 질문을 함께 나누며 마음속 이야기들을 꺼내보세요. 미처 몰랐던 면을 이해할 수 있는 기회가 되어줄 거예요. 감정에 솔직한 당신, 감정을 책임질 줄 아는 당신이 정말 멋집니다.모든 감정에는 이유가 있다감정에 대한 상품들을 만들고 사람들과 프로그램을 진행하면서 정말로 좋아진 건 다름 아닌 바로 저의 성격입니다. 이전의 제가 화가 날 때 그 감정을 주체하지 못하고 쏟아냈었다면, 지금의 저는 그래도 잠시 멈추고 내가 화가 났구나 라는 사실을 인정하려고 노력합니다. 그리고 그 감정에서 벗어나 기분을 전환하려고 합니다. 그렇게 해서 감정이 좀 가라앉은 후에는 찬찬히 다시 감정들을 돌아보며 나의 화가 어디서 온 것인지를 생각해보는데요. 그때 많은 성찰이 일어나곤 합니다.이전의 저였다면, 인쇄사고 나다니 말도 안 된다며 끝도 없이 자책을 하고, 후회에 후회를 거듭했겠지만, 그런다고 달라지는 일은 없습니다. 내가 어쩔 수 없는 일은 그냥 그렇게 내려놓는 것이 정답입니다. 아무리 나를 괴롭힌다고 해도 달라지는 일은 없으니까요. 나란 놈의 실수를 응원해주세요. 그리고 그 실수를 통해 나를 더 키워나가는 기회로 삼읍시다. 우리는 죽을 때까지 성장해야 하는 불완전한 인간들이니까요. 그렇게 한 발짝씩 함께 나아갑시다. 우리.   스트레스컴퍼니의 2018년 신상인 감정카드 50장 세트는 와디즈를 통해서 펀딩에 참여하실 수 있습니다.  https://www.wadiz.kr/web/campaign/detail/17822 스트레스컴퍼니의 모든 상품은 스트레스컴퍼니샵에서 구매 가능합니다.ⓒ스트레스컴퍼니 - 무단 전재-재배포 금지#스트레스컴퍼니 #심리스타트업 #스트레스관리 #서비스소개 #제품소개

데이터 검증은 system error 또는 human error에 의해 garbage data가 쌓이고 있진 않은지, 정상적으로 데이터가 수집되는지 여부를 확인하는 매우 중요한 단계인데요. 오늘은 왜 데이터 검증 단계가 중요한지를 최근 경험을 통해 설명드리고자 합니다.한 고객사에서 데이터 검증 과정 중 GA(Google Analytics for Mobile Apps) 대비 저희가 공급한 툴(와이즈트래커)의 세션수(방문수)가 너무 낮다는 문의를 주셨습니다. 그 수치는 무려 3배 가량의 차이로 acceptable이 힘든 데이터였습니다.사실 세션은 설정이 요하는 분석 항목이 아니기 때문에 측정기준으로 비교해 봐야 했지만, 세션 기준 역시 30분으로 GA와 와이즈트래커와 동일했습니다. 이에 저는 GA에서 over counting되는 요인이 있을거라 생각하고 열심히 구글링 하다 흥미로운 아티클을 발견했습니다. GA SDK V4 적용했더니 세션수 2배 이상 증가했다?>> Link이 문의에 한 사람이 답변을 달기를, GA에는 activity auto tracking 기능이 있는데, 이를 사용할 경우 앱을 백그라운드에 내리거나 프로세스 킬하고 재실행하면 30분 세션 유지기간에 상관없이 세션이 증가한다는 내용이었습니다. 이 말인즉, 사용자가 앱과의 인터렉션이 없어도 GA SDK가 자동으로 새로운 세션을 발급한다는 건데요. 설마했지만 사실 확인을 위해 테스트를 진행했습니다.1) 테스트 앱 개발2) GA SDK v4 적용3) 앱 실행4) 앱 프로세스 종료 후 30분 이내 재실행 or 백그라운드 처리이는 불과 1분 안에 일어난 현상테스트 전 데이터는 사용자 1, 세션 6건이었고, 3단계 앱을 실행하는 시점에 사용자 2, 세션 7이 되었습니다. 정상적으로 사용자 1건, 세션 1건이 증가한 것입니다. 여기서 앱을 종료하고 바로 앱을 다시 재실행 해보았습니다. 그리고 데이터를 보니 오잉? 정말 세션이 증가했습니다. 정말인가 싶어 여러 번 했지만, 아래 캡쳐시간을 보시면 알겠지만, 불과 1분도 채 안되서 3건의 신규세션이 발생한 것입니다.그렇다면 도대체 왜 이렇게 처리한 것일까? 오류일까?정확히 알 수는 없지만 이 기준 자체는 데이터 해석에 큰 오해를 일으킬 수 있습니다. 우리는 보통 평균 값을 갖는 파생지표를 세션을 기준으로 산정합니다. 그래서 보시는 것 처럼, 평균 세션당 화면, 평균 세션 시간이 세션수를 기준으로 나눠진 것을 알 수 있습니다.평균 세션당 화면, 평균 세션 시간, 사용자당 방문횟수와 같은 지표는 사용자의 앱 인게이지먼트를 판단하는 척도로 활용하는 사용성 높은 지표인데, 사용자와 앱 간의 실질적인 인터렉션이 전혀 없는 허수의 세션이 증가하니 세션수와 연관있는 모든 파생지표 데이터가 실제보다 낮은 수치로 표기되고, 이를 가지고 잘못된 해석을 하고 잘못된 액션까지 취할 수 있다는 것입니다.해당 고객은 안타깝게도 세션 뿐만 아니라 세션과 관련된 파생지표 모두 잘못된 기준의 KPI를 보았다고 할 수 있는데요, 사실 아직까지 국내는 GA에서 추출하는 기본 데이터 수준으로 KPI를 활용하는 경우가 많고, 특히 GA의 activity auto tracking 기능을 대부분 true로 설정하여 활용하고 있을 것이기 때문에 데이터 해석의 문제는 생각보다 굉장히 범용적으로 발생하고 있을 것으로 예상됩니다.!! 데이터 검증은 선택이 아닌 필수 과정데이터 분석을 잘하기 위한 전제 조건은 좋은 데이터를 수집하는 것입니다. 하지만 보통 3rd party tracking 업체는 툴을 제공하는 것 까지만 수행하지, 클라이언트의 개발자가 제대로 적용했는지, 적용한 데이터가 정상 수집되고 있는지 등의 과정까지 support 하지 않습니다. 그럼 클라이언트가 직접해야 하는데 이건 현실상 더더욱 힘들 수 밖에 없습니다.그래서 툴을 선택할 때는 반드시 도입 단계에 데이터 검증을 지원하는지 여부를 확인해야 합니다. 2012년부터 빅데이터 분석 바람이 불고 있지만, 현실은 기업에 전문 분석가 1명이 없는 기업이 아직 대부분입니다. 또한 비전문가가 쉽게 배우고 커버할 수 있는 업무도 아니기 때문에 전문 업체의 지원을 받아야 합니다. 안해주면 해달라고 떼 써야 합니다. 초기 도입시에 말이죠. 그래야 이후에 자신감있게 데이터를 신뢰하고 분석하고 액션 플랜을 수립할 수 있습니다.오늘 당장 리포트의 데이터를 의심의 눈으로 한 번 다시 보시는 계기가 되면 좋겠습니다.

어트리뷰션 툴의 출현 배경과 어트리뷰션의 동작에 필요한 세 가지 축을 지난 글에서 살펴 보았습니다. 이번에는 어트리뷰션의 한 축을 이루는 트래킹 URL을 설명하며 내용을 이어 나가려 합니다. 트래킹 URL의 역할과 구조를 이해하게 되면 어트리뷰션 툴을 다루는 난이도가 크게 낮아집니다. 그만큼 실무에서 더욱 효과적으로 툴을 활용할 수 있게 되고 광고 성과 최적화에도 가속이 붙게 될 것입니다. 트래킹 URL을 사용하는 이유어트리뷰션이 가능하기 위해서는 전체 유저들 중에서 광고의 영향을 받은 유저를 구분해 낼 수 있어야 합니다. 누군가를 ‘광고의 영향을 받았다’고 평가하기 위해서는 확실한 근거가 필요한데요, ‘광고 클릭’이 바로 이 확실한 근거가 됩니다. 클릭은 유저의 능동적인 광고반응이기 때문입니다.이 ‘클릭’ 행위를 알아내기 위해 광고 클릭 시점에 동작(Fire)하는 장치를 활용할 필요가 있었고 랜딩 페이지 URL이 적합한 수단이라는 것을 알아내게 됩니다. 두 가지 이유가 있는데, 광고 클릭과 랜딩 페이지 URL 연결이 사실상 동일한 행위라는 것이 첫번째이며, URL을 통해 최종 페이지로 연결되는 중간에 어딘가를 경유하도록 설정할 수 있다는 것이 두번째입니다.트래킹 URL을 클릭하면 중간에 트래커 서버를 경유하게 된다. 트래커는 광고 클릭에 대한 정보를 기록하고, 유저를 랜딩 페이지로 리다이렉트한다.이 중간 경유지가 있음으로써 심도 있는 어트리뷰션이 가능해 집니다. 왜냐하면 광고를 클릭한 유저가 경유지를 거치면서 다양한 데이터를 알려주고 이동하기 때문입니다. 수집하는 데이터가 많을수록 당연히 더 정확한 어트리뷰션이 가능한데요, 더 많은 데이터를 수집하는 방법이 바로 어트리뷰션 툴에서 다양한 옵션을 추가하여 트래킹 URL을 생성하는 것입니다. 트래킹 URL은 낯선 것이 아니다트래킹 URL을 만들기 위해 어트리뷰션 툴을 처음 접하게 되면 복잡하고 어려운 느낌을 받기 쉽습니다. 입력해야 할 항목들이 다양해서 손이 많이 가고, 세부 옵션의 숫자에 압도당해 어떻게 사용해야 할지 판단하기 어렵습니다. 게다가 반신반의 하면서 만들어낸 트래킹 URL은 의미를 알 수 없는 문자로 가득해서 혼란스럽지요. 보는 사람으로 하여금 이 URL을 천천히 살펴보면서 의미를 알아내려는 시도 조차 하고싶지 않도록 만들기에 충분합니다.하지만 트래킹 URL을 만드는 프로세스를 구조적인 시각으로 바라보면 매우 익숙한 절차라는 것을 알게 되는데, Bitly로 단축 URL을 만드는 것과 어트리뷰션 툴로 트래킹 URL을 만드는 것이 절차상으로 다르지 않다는 것이지요. 단지 트래킹 URL 생성에는 생소한 옵션들이 많아서 어려워 보일 뿐입니다.원래의 URL을, 툴에 입력해서, 최종 URL로 변환하는 구조는 동일하다. 다만 툴에 입력하는 2번 과정에서 어트리뷰션 툴은 다양한 옵션을 지정해줘야 하기 때문에 할 일이 더 많은 것이다.결국 툴에 URL을 입력하는 2번 과정을 이해하게 되면 트래킹 URL을 자유자재로 다룰 수 있게 됩니다. 2번 과정에서 주로 사용하는 옵션들이 무엇이고 어떤 기능을 하는지에 대한 설명이 있다면 큰 도움이 될 것입니다. 트래킹 URL 톺아보기완성된 트래킹 URL을 살펴보면서 URL의 구조부터 세부 항목들의 역할까지 차근차근 알아보겠습니다.http://ads.wisetracker.co.kr/wa/wiseAdw.do?_wtno=502&_wthst=trk.wisetracker.co.kr&_wts=P1535606238444&_wtc=C1535606305460&_wtm=C0000013&_wtaffid={wff_id}&_wtbffid={wffsub_id}&_wtcid={clk_id}&_wtgpid={GAID}&_wtidfa={IDFA}&_wtdl=http://www.wisetracker.co.kr&_wtp=2위 예제 URL은 와이즈트래커 홈페이지 주소(http://www.wisetracker.co.kr)를 트래킹 URL로 변환한 결과물입니다. 구조를 파악하기 위해 URL을 두 가지 배경색으로 구분했습니다. 하늘색 부분은 Base URL, 회색 부분은 파라미터입니다.1. Base URL광고를 클릭한 유저가 경유하는 지점입니다. 유저는 이 곳에 단지 몇 밀리 세컨드 정도만 머무르는데, 이 때 파라미터가 담고 있는 정보들을 트래커가 수집하고 유저는 즉시 최종 목적지로 리다이렉트 됩니다. 비근한 표현을 빌리자면, Base URL은 ‘찍고 가는 곳’ 정도로 이해하면 좋습니다. 2. 파라미터어트리뷰션에 필요한 다양한 정보들이 담겨있는 부분입니다. 툴에서 트래킹 URL을 생성할 때 다양한 옵션들을 선택하게 되는데요, 선택하는 옵션의 숫자가 많아질수록 파라미터가 길어진다고 봐도 틀리지 않습니다. 더 많은 옵션을 사용할수록 더 많은 데이터를 트래킹 할 수 있고, 더 많은 데이터를 측정하기 위해 더 많은 파라미터가 필요하기 때문입니다.하나의 파라미터는 하나의 데이터를 의미합니다. 실무에서는 간혹 트래킹 URL이 측정할 수 있는 항목을 알아내기 위해 전체 URL에서 각각의 파라미터를 구분해낼 필요가 있는데, 이럴때는 앰퍼샌드(Ampersand, &) 단위로 끊어내면 됩니다. 앰퍼샌드가 보이면 ‘새로운 파라미터가 시작되는구나’ 라고 생각하면 되는 것입니다.와이즈트래커에서 주로 사용하게 되는 파라미터를 간략하게 정리하면 다음과 같습니다.파라미터 종류설명와이즈트래커 구현광고 매체광고가 게재된 매체 정보._wts광고 캠페인광고의 캠페인 정보._wtc하위 퍼블리셔DSP나 네트워크 매체에서 실제 광고가 나간 지면._wtaffid, _wtcffid…클릭 ID광고 클릭시 발생하는 고유 식별자._wtcid단말기 식별자광고 클릭이 발생한 단말기의 고유 식별자._wtgpid, _wtidfa랜딩 페이지리다이렉트 후 이동할 최종 목적지._wtdl룩백 윈도우성과 기여 인정기간. 룩백 윈도우 이후에 발생한 광고성과는 인정하지 않음._wtp3. 유저 에이전트유저 에이전트는 그 이름처럼 실제 유저를 소프트웨어 상으로 대신하는 역할을 합니다. 여기에서 말하는 소프트웨어란 일반적으로 브라우저, OS, 단말기 정보 등을 포함한 데이터를 의미합니다. 광고를 클릭한 유저가 트래커를 거쳐갈 때 서버는 접속자의 유저 에이전트 정보를 알 수 있으므로, 이런 값들은 파라미터에 포함시키지 않아도 분석이 가능합니다.유저가 광고를 클릭함으로써 트래킹 URL로 연결되고, 유저는 트래커를 거치며 파라미터에 포함된 다양한 데이터를 전달한 뒤, 앱을 다운로드 할 수 있는 최종 목적지로 연결됩니다. 이렇게 한 번의 클릭을 시작으로 어트리뷰션의 전체 여정이 전개되는 것입니다.지금까지의 내용을 정리하면 다음과 같습니다.유저가 광고에 반응했다는 것을 측정하기 위해 트래킹 URL을 사용한다트래킹 URL은 트래커 서버를 경유한 뒤 최종 랜딩 페이지로 유저를 이동시킨다유저의 트래커 경유 시점에 트래커는 파라미터에 포함된 데이터를 수집한다트래커는 수집한 정보를 바탕으로 어떤 유저가 어떤 매체의 광고를 언제 클릭 했는지를 알게 되었고 유저는 앱 다운로드 페이지로 이동 했습니다. 유저가 앱을 다운로드 했는지를 트래커는 어떻게 알 수 있을까요? 다음 글에서 설명하도록 하겠습니다.

안녕하세요. 매쓰플랫입니다 :)요즘 매쓰플랫 사내에서 조금은 특별한 모습을 볼 수있어요~!바로 콘텐츠팀에서 특별 프로젝트를 진행중이에요.과연 어떤 서비스가 업데이트 될 지 궁금하시죠?선생님들!매쓰플랫이 시중교재/교과서 연동 수가업계에서 압도적으로 많은 거 아시죠?현재 2015 개정 교육과정 포함약 800여권 교재 연동 서비스를 지원하고 있어요.현재의 교과과정에 맞는수학문제은행을 발빠르게 제공하기 위해서매쓰플랫 '콘텐츠팀'에서 열일해주고 계세요.여러명의 '수학 교육' 실력파 콘텐츠팀 멤버 중!두 분께서는 더 나은 서비스 제공을 위해서'특별히 마련된 자리'에서요새 아주 열심히 회의 또 회의를 하고 계세요.과연 무슨일을 하는걸까요?아직은★★사내 비밀★★분명히 선생님들이 좋아하실 무언가를서비스에 녹여내기 위한거는확실해요~!!궁금하셔도 조금만 더 참고,기대해주세요 :)매쓰플랫은콘텐츠팀을 비롯하여전체 팀에서 항상 더 나은 서비스 제공을 위해고민 또 고민 한답니다~!매쓰플랫에 주시는 관심에 걸맞는점점 더 좋아지는 서비스를 보여드릴게요.선생님들의 사랑항상 감사합니다 ♥오늘도 즐거운 하루 보내세요 :)click! click! 매일 매일 더 좋아지는 ♥ 매쓰플랫 7일 무료 체험하기 ♥http://bit.ly/2MczO25가장 빠르고 부담없이 문의하는 방법 요기!

이메일 뉴스레터를 보낼 때 가장 먼저 생각해야 하는 것은 보내는 목적입니다. 왜 보내는지, 받는 사람에게 기대하는 것은 무엇인지 등에 대해 생각해봐야 하죠.스티비 뉴스레터의 첫 번째 목적은 이메일 마케팅이 대한 팁을 공유하는 것이고 두 번째 목적은 스티비를 알리는 것입니다.이메일 뉴스레터를 왜 보내시나요?이 질문이 중요한 이유는 목적에 따라 이메일 본문의 디자인이 달라지기 때문이에요. 목적에 따라 길이가 달라지고 강조해야 하는 부분도 달라집니다.이메일 뉴스레터를 보내는 목적에 따라 크게 행동 유도하기, 소식 전하기, 소개하기의 3개 유형로 나눌 수 있습니다. 훨씬 다양하지만 디자인이 어떻게 달라지는지 알아보기 위해 단순하게 나눠봤습니다.행동 요청하기하나의 메시지에 집중하여 후원이나 구매와 같은 행동을 요청합니다. 행동 요청의 꽃은 CTA(Call-To-Action) 버튼입니다. 버튼을 클릭해야 후원이나 구매를 하게 할 수 있죠. 그래서 행동을 요청하는 이메일은 버튼을 크고 선명하게 만들어 강조합니다.소식 전하기여러 콘텐츠를 엮어 회사나 단체의 소식을 주기적으로 전달합니다. 콘텐츠의 내용을 간략하게 전달하는 대표 이미지와 3–4줄의 요약 텍스트를 반복하죠. 관심있는 콘텐츠에 대한 상세한 내용을 볼 수 있는 ‘더 읽기’, ‘자세히 보기’ 등의 버튼을 넣어도 좋습니다.소개하기새로운 제품이나 기능 등 알리고 싶은 정보를 전달합니다. 제품이나 기능에 대한 헤드라인, 대표 이미지를 가장 먼저 강조하여 전달하고 세부적인 내용은 그 아래에 이미지와 텍스트를 적절히 조합하여 전달하죠. 제품 구매나 앱 다운로드를 유도하는 CTA 버튼을 넣어도 좋습니다.모든 이메일 뉴스레터를 이 3개 유형으로 설명할 수 있는 건 아닙니다. 스티비 뉴스레터도 소개하기에 가깝긴 하지만 딱 들어맞진 않아요. 이메일 마케팅이라는 제한된 주제를 자세히 다루다 보니, 위에서 소개한 이메일들과 달리 텍스트나 이미지의 양이 많아지곤 합니다.보내고 계신 이메일 뉴스레터가 어떤 유형에 해당하는지, 목적에 맞게 디자인 된 템플릿을 사용하고 있는지 한 번 확인해보세요.참고: Really Good Emails#슬로워크 #스티비 #마케팅 #마케터 #인사이트 #꿀팁

 DevOps의 시작언제나 그랬듯이 소프트웨어 개발 트렌드는 계속 변화하고 있다. A부터 Z까지 모든 것을 새롭게 개발했던 것과 달리 아키텍처나 사용하는 용도에 따라 개방형 플랫폼이나 오픈소스 등을 활용하여 원하는 소프트웨어를 쉽게 개발할 수 있게 되었다. 또한 클라우드로 인해 애플리케이션과 서비스 개발에 대한 새로운 패러다임이 나타나고 있다. 기존의 온-프레미스 환경에서는 물리적 서버 준비, 운영체제 설치, 서비스 배포 등에 수많은 시간이 걸렸지만, 클라우드를 활용하면서 단시간에 원하는 자원을 준비하고 배포할 수 있게 되었다.이러한 변화로 개발자의 영역이 좀 더 넓어지는 계기가 되었다. 이는 전통적인 비즈니스 환경에서 개발, 빌드, 테스트, 배포, 운영에 이르는 프로세스를 효율적으로 운용할 수 있게 되어 고객의 요구사항을 빠르게 반영할 수 있게 되었다. 이것이 바로 DevOps의 시작이다. 하지만 다양한 오픈소스의 탄생과 클라우드 환경의 확산 등으로 인해 정말로 새로운 기능에 대한 개발이 빨라졌을까? 그렇다면 이에 따른 문제는 없을까? 개발 프로세스의 병목 구간DevOps의 필수 조건인 테스트 및 배포의 자동화가 이뤄지면 운영 단계에서는 반영된 사항들에 대해 주기적으로 모니터링을 해야 한다. 만약에 반영된 소스코드에 장애를 발생시킬 수 있는 잠재적 버그가 존재한다면 이를 어떻게 운영 단계에서 찾을 수 있을까? 예를 들어 특정 서비스의 피크타임에 부하가 급증한다면 앞서 말한 상황에 대한 버그가 발생할 확률이 상대적으로 높아진다. 하지만 장애의 원인이 될 수 있는 요소는 매우 다양하기 때문에 단순히 트래픽 문제로 속단할 수는 없다.직접 개발한 소프트웨어만의 문제가 아닐 수도 있으며, 제품 개발시 생산성 향상을 위해 도입된 다른 종류의 오픈소스에서 문제가 될 수도 있다. 실은 이런 류의 프로젝트들은 상용 제품이 아니므로 문제가 발생하면 상당히 곤란한 경우가 생기곤 한다. DevOps를 위한 환경이 구성되고, 고객의 요구사항을 빠르게 반영할 수 있는 시스템이 갖춰졌더라도 결국에는 앞서 말한 다양한 종류의 잠재적, 환경적인 문제들로 인해 병목이 발생할 수 있다.  모니터링 단계에서 APM의 역할개발 프로세스의 마지막 관문인 모니터링 단계는 DevOps에서 매우 중요한 역할을 한다. 하지만 안타깝게도 이미 반영된 실제 서비스에서 모니터링을 성공적으로 마치고 피드백 수집 단계로 넘어가기 위해서는 앞서 말했던 장애의 원인을 빠르게 진단해야 한다. 경우에 따라 많은 시간이 소모되기도 하기도 하며, 이는 바로 생산성 저하로 이어진다. 또한 새로운 프로세스 진행을 더욱더 보수적으로 만드는 원인이 된다.DevOps를 완벽하게 실현하기 위해서는 모니터링 단계에서 서비스 배포 이후의 서버에 들어오는 트랜잭션에 대한 상태를 배포 전과 비교할 수 있어야 하며, 응답을 지연시킬만한 요소들을 빠르게 인지할 수 있어야 한다. 그리고 배포된 소스코드로 인해 서비스 장애가 발생하는 상황이 온다면 이를 처리하기 전까지 어떻게든 서비스 장애를 지연시켜야만 한다. 이러한 이유로 DevOps 진영에서는 APM의 역할은 매우 중요한 이슈이다. 우리는 제니퍼를 통해 앞서 말한 기능들을 활용하는 방법에 대해 알아볼 것이다. 모니터링 프로세스모니터링 단계는 아래 그림과 같이 문제의 발견 및 조치, 문제해결시 재배포 단계로 나눌 수 있다.  제니퍼 대시보드를 통해 액티브서비스 상태와 트랜잭션 변화 추이를 모니터링 할 수 있는데, 만약에 새로 배포된 소스코드에 문제가 있다면 처리 중인 액티브서비스가 쌓이게 되고 , 트랜잭션 분포도 차트는 기존에 그려졌던 패턴과 다르게 보여지게 된다.이런 시점에 운영에서는 설정 여부에 따라 이벤트를 발생 시킬 수 있다. E-Mail이나 SMS, Slack과 같은 메신저 등으로 각각의 담당자들에게 서비스 상태를 알려줄 수 있으며, 담당자에게 이벤트 메시지가 전달되었다면 제니퍼를 통해 두가지 조치를 할 수 있게 된다. 먼저 개발자는 스마트 프로파일링 기능을 통해 원인분석을 하고, 운영에서는 서비스가 최악의 상태가 되기 전에 트랜잭션 유입을 차단하여 다른 화면으로 리다이렉트 시켜주는 PLC 기능을 사용할 수 있다.제니퍼에서는 서버에서 하나의 요청에 대한 처리가 끝나면 곧바로 수집되는 데이터를 트랜잭션이라하며, 현재 수행 중인 상태에 대한 실시간 데이터를 액티브서비스라고 정의한다.   모니터링 기준 값 설정서비스를 배포하기 전에 모니터링 단계를 원활하게 수행하기 위해서는 제니퍼 관리 화면에서 몇가지 설정을 해야한다. 먼저 서비스 장애 발생시 이벤트 알림 및 서비스 부하량 제어 설정의 기준이 되는 값인 전체 에이전트의 평균 액티브서비스 개수를 알아야 한다. 하지만 서비스가 운영되는 환경에 따라 기준 값이 너무 다르기 때문에 어느 정도 안정적으로 서비스가 운영되고 있다고 생각하는 시점에 대략적으로 기준 값을 정하면 된다.에이전트란 모니터링 대상 애플리케이션에 기생하여 성능 데이터를 수집하고, 이를 서버로 전송하는 역할을 하는 모듈을 말한다. 참고로 모니터링 대상 애플리케이션은 플랫폼 환경에 따라 차이가 있을 수 있는데, 일반적으로 WAS(Web Application Server)나 웹 서버를 말한다.  액티브서비스는 처리가 완료되지 않은 상태이므로 서비스 장애의 원인분석을 위한 데이터로는 적합하지 않다. 그렇기 때문에 액티브서비스 개수는 기준 값이 될 수 없으며, 개발자는 처리가 완료된 트랜잭션 데이터의 응답시간을 기준 값으로 제니퍼의 프로파일링 관련 설정을 해야 한다. 설정된 값을 기준으로 트랜잭션 분포도 차트에서 가상의 선을 긋고, 그 선 위에 있는 트랜잭션을 대상으로 스마트 프로파일링 기능을 수행할 수 있다.  본문에서는 모니터링 단계에서 직면하게 되는 문제점과 이를 해결하기 위한 APM의 역할과 필요성 대한 이야기를 했다. 다음 편에서는 본격적으로 제니퍼를 활용하여 모니터링 프로세스를 어떻게 수행하는지에 대해 알아볼 것이다.2편에서 계속...

안녕하세요 협업툴 플로우입니다.디지털 전환! 코로나로 인해 매출에 타격이 있거나 업무가 마비된 경험을 한 기업이라면, 어떻게 해야 비대면 상황에서도 비즈니스 연속성을 가질 수 있을지 심각하게 고려해 봤을 것입니다. 그렇지 않더라도 대부분의 기업에서 디지털 전환은 한 번 쯤 고민해보셨을텐데요.성공적인 디지털 전환은 어떻게 시작해야 할까요? 선두 기업들은 디지털 전환의 첫 시작으로 협업툴을 선택하고 있습니다. 협업툴을 기존 시스템에 빠르게 적용할 수 있기 때문입니다. 아직도 '디지털 전환, 협업툴로 시작해도 될까?' 에 대한 고민이 있는 분이라면 지금 소개해드리는 ‘협업툴을 사용해 본 1429명의 설문 리포트 자료’를 참고하세요.ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서협업툴 필요성 및 이유ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서1429명의 직장인들은 무려 93%의 응답자가 협업툴이 회사에 필요하다고 답변했습니다. 회사에서 협업툴이 필요한 이유는 ‘1위 팀 소통’ ‘2위 업무 일정 관리’ ‘3위 자료 ·파일 보관’ ‘4위 목표달성’ ‘5위 조직의 생산성’의 순서로 이유를 선택했어요! 특히 팀 소통과 업무 일정 부분이 압도적인 선택을 받았는데 응답자들이 협업툴을 사용해 보다 원활한 소통을 해야할 필요성을 느끼고 있다는 점을 알 수 있었습니다.협업툴 도입 시 중요한 선택 기준ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서63%는 내가 의사결정권자라면, 회사에 협업툴이 도입을 적극적으로 제안한다고 답변했습니다. 협업툴 선택 시 중요한 기준은 ‘1위 사용성’ ‘2위 제품의 기능’ ‘3위 가격 합리성’ ‘4위 보안 안전성’ ‘5위 개발사 신뢰’의 순서로 이유를 선택했습니다. 전 직원이 빠르게 적응하여 사용할 수 있는 쉬운 사용성이 협업툴 선택 시 가장 중요한 기준이 된다는 것을 확인할 수 있었습니다.ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서 플로우를 사용하면서 이메일, 단톡방을 대신 해 하루 55분 아낄 수 있었다고 답하였습니다. 시간을 낭비하게 만드는 요인으로 꼽았던 업무 진행 상황 체크, 업무 기록 찾기, 자료 검색 등의 4가지가 모두 개선되었다고 답했으며 재택근무, 원격 회의 등 장소의 제약을 개선한 점이 좋았다고 답한 응답자도 413명 있었습니다.ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서 이 글은 포스팅 중 일부를 발췌하였습니다.여러분이 회사의 성공적인 디지털 전환과 협업툴 도입 결정을 하는데에 조금이나마 도움이 되길 바랍니다. 원문 링크 :https://post.flow.team/tip/6392👉플로우 리포트 신청하기

졸업했다. 2010년 3월부터 2016년 8월까지. 군 휴학을 제외한다면 4년간의 전공 교육과정이 드디어 끝이 났다. 솔직히 4.5 만점에 겨우 3점을 소수점으로 겨우 넘기는 성적으로 졸업했지만, 성적에 있어 아쉽다는 생각은 들지 않는다. 그냥 4년 내내 해왔던 다른 프로젝트(뻘짓)들과의 등가교환이라 생각한다. 물론 전공과목들은 매우 뜻깊었고, 큰 도움이 되었지만 어릴 때부터 희박했던 경쟁의식은 나를 시험과 출석 점수와 같은 줄 세우기 방식보다 프로젝트 수업이나 과제의 디테일에 더 빠지게 하였던 것 같다. 물론 단순한 자기관리 미약이다. 스스로도 자기관리에 스탯을 더 찍어야 한다고 생각(만)한다. 예를 들어 생활 패턴이나, 체중 관리와 같은 것들. 나는 나를 너무 소중히 대하지 않는 듯한 경향이 있다. 막상 졸업하고 하고 나니 신기하리만큼 학교 생각이 나지 않는다. 안동 촌놈 상경 후 대부분 시간을 학교에서 먹고 자고 지낸 만큼 졸업하게 되면 굉장히 허전하고 생각이 많이 날 줄 알았건만, 앞가림하기 바빠서 그런가. 학교 앞에 살고 있음에도 불구하고 별로 생각이 나진 않는다. 다만 후배들에게 대학교에서 가르쳐주지 않는 것, 내가 아는 것 하나라도 더 전해주고 왔어야 하는데.. 이 아쉬움 하나가 진하게 남는다. 유독 내가 챙겨줬던 몇 놈들이 눈앞에 아른거린다. 그러니깐 앞으로 시험 기간 때마다 소주를 한 짝씩 학회 방으로 보내야겠다. 취업했다. 학교와 일을 병행했던 전 직장을 퇴사한 지 7개월 만이다. 물론 마지막 학기에도 어느 정도 면접을 보러 다녔지만 '라인플러스'와 '스마트스터디'를 제외하고 그다지 열과 성을 다해 취업을 준비했던 기억이 없다. 어느 정도로 열과 성이 없었냐면 서류 합격을 하고도 인적성이나 필기시험을 위해 판교로 9시까지 오라는 메일을 받고 질색하여 가지 않았던 회사가 몇 군데 있었다. (왕복 4시간.. 물론 지금 생각해보면 정신이 나간 게 분명하다) 아무튼 앞의 저 두 회사는 매우 아쉽지만, 그저 인연이 아니었다 생각한다. 어딘가의 면접에 떨어지고 나서 반드시 보내는 회신 메일에 수고하셨다는 멘트와 함께 쓰는 말이 있다. '언젠가 좋은 인연으로 다시 만날 수 있으면 좋겠습니다.' 그저 딱 이말 그대로의 심정이다. 마지막 학기가 끝나고 약 두 달간 이 회사 저 회사에 지원을 꽤 했었다. 주로 Node.js를 사용하는 스타트업 몇 군데에 Back-end Developer로 서류를 넣었고 두 군데 정도를 제외하고는 면접까지 다 본 것 같다. 면접 보고 빠르게 포기 의사를 밝힌 한 군데를 제외하면 최종적으로 세 군데의 회사에서 출근해줬으면 좋겠다는 의사와 오퍼를 받았다. 하지만 비루한 몸 뚱아리가 하나뿐이라 반드시 한 곳을 선택해야 했다. 세 군데 중 한 곳은 지인 찬스로 면접을 본 곳이었지만 나와 개발 분야가 맞지 않는 회사였다. 신입 연봉 수준은 매우 훌륭했지만 빠르게 오퍼 거절 의사를 밝혔다. 남은 두 회사에서 꽤 심각하고 오랜 기간(==일주일) 동안 고민했다. 한 곳은 6년 정도 된 기술력 있는 정예 멤버 느낌의 소규모 소프트웨어 개발사. 신입 멤버를 뽑은 게 몇 년 만이라 매우 감사하면서도 좋은 기회라 생각했다. 그리고 분명히 내가 개발자로서 폭넓게 성장하는 데 있어 두 번 다시 없을 좋은 회사라 생각했다. 다른 곳은 창업 1년 정도의 폭발적으로 성장 중인 나름 핫한 스타트업. 아직 개발과 서비스를 동시에 하고 있었고, 내가 할 수 있는(벌일 수 있는) 일이 매우 많아 보였다. 결국, 나와 인연이 된 회사는 이제 막 창업 1년의 스타트업이다. 사실 면접 당시 첫인상이 별로였지만 지속해서 메일로 컨택을 하다 보니 나름의 사정이 있었고 결과적으로는 이렇게 되었다. (무엇보다 재밌어 보였다.) 최종 오퍼 수락이 확정된 어제. 페이스북에 취업 소식을 공유하고 참 많은 연락을 받았다. 대부분 축하의 연락이었지만 간간이 섞여 있는 아쉬움의 언어들은 나를 참으로 심경 미묘하게 만들었다. '축하는 하는데 좀 아쉽다.', '너 정도면 더 좋은데도 갈 수 있을 텐데', '하반기 시작했는데 좀 더 있어 보는 게 어떻냐' 등. 물론 그들의 말도 일리가 있다고 생각했고, 나도 별다른 반박을 하지 않았다. 나도 당연히 큰 회사를 경험해보고 싶고, 큰 회사에서만 느낄 수 있는 것과 배울 수 있는 것이 있다고 생각을 한다. 다만 한 살이라도 더 어릴 때 스타트업을 경험해보는 것이 좋다고 생각하며, 당장 뭐라도 찍어낼 수 있을 정도의 역량이 되고(기초적인 개발 소양을 갖췄고), 일 벌이는 것(사고 치는 것)을 좋아하는 안 좋은 습관이 있다면 비록 연봉이 적더라도 자신의 개발 역량을 최대한 뽑아낼 수 있고 의사 반영이 가능한 곳이 좋다고 생각했을 뿐이다. 물론 너무 조건이 안 좋은 곳은 걸렀으며, 나중에 후달리면 그 때가서 생각하자. 라는 매우 안일한 생각을 가지고 있다. 대기업이 좋니, 중소가 좋니, 스타트업이 좋니 왈가왈부할 생각은 없다. (당연히 대기업이 좋겠지..) 다만 몇 년 전 모 대기업 인턴 채용 진행 중 최종 탈락까지 2개월이나 걸렸을 때 느꼈던 질색이나 왜 물어보는지 의중을 전혀 파악할 수 없는 자기소개서 항목, 인적성을 다시 경험하고 싶지는 않다. 모 대기업 지원할 때 반드시 필요하다는 토익도 필요성을 느끼지 못해 대학생활 6년 반 동안 쳐다보지도 않았다. 필요성을 스스로 이해하지 못하면 뇌와 몸이 따라가질 않는 성격이다 보니 그저 개인의 취향에 따른 문제라고 생각한다. 물론 나의 졸업 후 첫 회사 선택에 있어 경험 부족으로 인한 잘못된 판단을 정신 자위하는 것일 수도 있고, Node.js를 한동안은 계속 써보고 싶은 철없는 생각에 실수한 것일 수도 있으며, 스스로 부족하다고 생각하는 개발 실력의 도피처일 수도 있다. 언젠가 사주를 봤을 때 '참 평탄한 인생을 살 팔자'라는 얘기를 들었는데, 그 아저씨가 틀린 것 같다. 스스로 생각해도 앞으로도 참 고생을 사서 하지 않을까 하는 생각이 든다.내가 이 포스트에 뭘 쓰려고 했는지 까먹었다. ...마무리#플레이팅 #스타트업 #스타트업창업 #경험공유 #인사이트 #스타트업경험

편집자 주-PHP 기반의 서비스를 기준으로 설명했다.-서버의 프로그램은 ‘서버 스크립트’로 표기했다.-HTML/html: 약어로 사용할 경우엔 대문자, 파일명으로 사용할 경우엔 소문자로 표기했다.목차jekyll이 어렵게 느껴지는 이유 jekyll은 모든 화면을 미리 만들어둔다.서버 스크립트 없이 검색 기능을 어떻게 만들까?이미지 캡션 추가이미지 사이즈 대응부록: 글 반영 과정, 도메인 연결 방법, 추가 옵션에 대하여Overview기술 블로그인 브랜디 랩스를 관리하기에 jekyll은 안성맞춤인 도구입니다. 1년 넘게 탈 없이 잘 사용하고 있죠. 물론 커스터마이징을 하려면 고생이 이만저만이 아닙니다. 그 과정은 jekyll을 이용한 Github 블로그 만들기에도 잘 나와있습니다. 도대체, jekyll은 왜 이리도 어려운 걸까요? 브랜디 랩스를 사례로 설명하겠습니다.jekyll이 어렵게 느껴지는 이유일반적인 웹서비스는 정적 리소스와 동적 스크립트의 조합으로 이뤄집니다. 예를 들어 PHP 서비스에서는 정적인 부분을 아파치 웹서버로, 동적인 부분을 PHP 스크립트로 작동합니다.하나의 게시글이 생기면 PHP 스크립트가 데이터베이스에 row 생성을 요청합니다. 게시글 등록 요청을 마치고, 글 목록 화면 요청을 한다면 데이터베이스에서 등록된 글목록을 정리해 HTML 양식으로 응답값을 만들어줄 것입니다.PHP 기반의 블로그 프로그램하지만 jekyll은 컨셉부터 다릅니다. 아주 생소한 메커니즘을 갖고 있습니다. 파일 기반의 데이터를 정적인 리소스로 빌드해서 서비스하죠. 게시글마다 md 파일이나 html 파일을 생성합니다. 글을 작성하고 배포하기 위한 빌드를 진행하면 응답할 html 화면을 만들고, 파일로 저장해 준비합니다. 이 상태에서 유저가 특정 화면을 요청하면 미리 생성한 html 파일을 찾아 꺼내주기만 하면 되죠. 다시 말해, 데이터베이스를 조회하고 HTML 양식으로 응답값을 만드는 과정이 생략되는 것입니다.실제로 Github page가 아파치 서버를 쓰는지는 알 수 없지만 개념 설명을 위해 동일하게 그렸다.jekyll은 모든 화면을 미리 만들어둔다.jekyll은 유저가 요청할 수 있는 모든 화면을 미리 빌드하는 방식을 씁니다. 앞서 다뤘던 브랜디 랩스의 gnav 영역의 회사소개, 채용 화면도 미리 빌드해둬야 합니다. 저자를 소개하는 프로필 페이지도 마찬가지죠. 글이 많아지면서 점점 길어지는 글 목록 화면도 예외는 아닙니다. 글 목록을 보여주는 화면이 많아지만 페이지 수만큼 미리 만들어야 합니다.위의 이미지는 jekyll이 동작하는 메커니즘을 간단히 정리한 것입니다. jekyll을 커스터마이징하려면 완전히 새로운 관점으로 접근해야 합니다. 지금부터는 브랜디 랩스의 검색 기능 구현 과정을 살펴보면서 커스터마이징을 자세히 알아보겠습니다.서버 스크립트 없이 검색 기능을 어떻게 만들까?검색을 하려면 작성된 모든 글의 제목과 내용에 원하는 키워드가 있는지 찾아야 합니다. 하지만 검색어는 변동값이므로 미리 빌드하는 방식으로는 커버할 수 없습니다. 검색어마다 화면을 미리 만들 수 없기 때문입니다.이럴 때는 클라이언트 스크립트는 활용해야 합니다. 서버 스크립트를 쓸 수 없기 때문에 어쩔 수 없는 선택이기도 합니다. 검색에 필요한 정보를 json 파일로 빌드시키고 자바 스크립트를 이용해서 검색하도록 했습니다.먼저 최상위 경로에 search.json을 만듭니다. 파일 시작점에 아래와 같은 패턴이 있다면 빌드 대상으로 인식됩니다.--- --- 이전에 쓴 jekyll 문서를 PDF로 배포하기에서 pdf.html 파일을 만들 때도 비슷한 방법을 사용했습니다.--- --- [ {% for post in site.posts %} { "title" : "{{ post.title | escape }}", "category" : "{{ post.category }}", "tags" : "{{ post.tags | join: ‘, ’ }}", "url" : "{{ site.baseurl }}{{ post.url }}", {% if post.author %}{% for author in site.data.authors %}{% if post.author == author.name %} "author" : "{{author.koname}}", "email" : "{{author.email}}", {% endif %}{% endfor %}{% endif %} "date" : "{{ post.date }}", "content" : "{{ post.content | strip_html | replace: "\", ‘’ | replace: ‘"’, ‘\"’ | replace: ' ‘,’ ' | replace: ' ‘, ’ ' }}" } {% unless forloop.last %},{% endunless %} {% endfor %} ] ▲서머리 데이터를 만드는 json 파일search.json은 모든 페이지의 제목과 내용을 정리해 json으로 만들어야 하기 때문에 site.posts변수를 이용해 만들었습니다. post내용에는 글의 저자, 작성일, 제목, 내용 등 필요한 정보가 있으니 출력하면 됩니다. json을 만드는 것이므로 내용에 “가 들어가면 안되 "으로 치환시켰습니다. 마지막으로 HTML 태그는 검색에 필요하지 않기 때문에 luqid strip_html 함수를 이용해 제거했습니다.http://labs.brandi.co.kr/search.json위의 URL을 클릭하면 브랜디 랩스에서 검색에 사용하는 json을 볼 수 있습니다. 빌드하면 search.json이 만들어지는 것을 확인할 수 있습니다. 이제 json을 로딩하고 해당 키워드를 가진 글을 찾아내기만 하면 됩니다. json 내에 제목과 내용에 입력한 키워드가 있을 때 아래와 같은 UI로 표현했습니다. 기능 구현은 Simple-Jekyll-Search를 이용했습니다. 1)이미지 캡션 추가블로그는 이미지를 많이 사용하고, 상황에 맞게 노출도 해야 합니다. 아래 이미지는 최종적으로 적용한 이미지와 캡션의 결과 화면입니다. {% include figure.html file="/assets/20190415/05.png" alt="05" caption="커스터마이징한 gnav 영역" width="fitcontent" border="true" %} 위와 같이 구성하려고 html과 css를 다음과 같이 구성했습니다. 커스터마이징한 Gnav영역 ▲캡션 html 소스figure { margin: 1em auto; } figcaption { text-align: center; font-weight: bold; color:#999; } ▲캡션에 관련된 css 소스이미지는 가운데 정렬했고, 캡션 텍스트도 옅은 회색으로 가운데 정렬했습니다. 하지만 편집을 담당하는 장근우 대리는 개발자가 아니므로 태그를 입력해달라고 하기엔 무리가 있었습니다. 좀 더 편리한 방식이 없을지 고민하다가 liquid 템플릿의 include 기능을 쓰면 되겠다는 생각이 들었죠. 아래는 브랜디 랩스 원고에 이미지를 넣을 때 쓰는 liquid 문법입니다.{% include figure.html file="/assets/easydebug/5.png" alt="07" caption="커스터마이징한 Gnav영역" %} liquid 템플릿 엔진에서 include할 때 추가 파라미터를 전달할 수 있습니다. file, alt, caption은 파라미터로 전달하고, include되는 파일에서 전달할 내용을 바탕으로 프로그램을 구현할 수 있습니다. {{include.caption}} ▲ /_includes/figure.html이미지 사이즈 대응작은 이미지를 확대하면 이렇게 된다.대부분은 이미지는 화면에 꽉 차지만, 어떤 이미지는 사이즈가 너무 작아 원래의 사이즈로 보여줘야 했습니다.{% include figure.html width="fitcontent" border="true" file="/assets/easydebug/5.png" alt="07" caption="커스터마이징한 Gnav영역" %} ▲사이즈와 외곽 테두리 선에 스펙을 추가했다.추가 전달 인자를 넣고, figure.html 파일에서도 사이즈 대응을 했습니다. {{include.caption}} ▲완성된 /_includes/figure.html 파일figure { margin: 1em auto; } figure.percent100 { width: 100%; } figure.percent90 { width: 90%;} figure.percent80 { width: 80%;} figure.percent70 { width: 70%;} figure.percent60 { width: 60%;} figure.percent50 { width: 50%;} figure.percent40 { width: 40%;} figure.percent30 { width: 30%;} figure.percent20 { width: 20%;} figure.percent15 { width: 15%;} figure.percent10 { width: 10%;} figure.percent5 { width: 5%;} figure.fitcontent { width: fit-content;} figcaption { text-align: center; font-weight: bold; color:#999; } ▲완성된 css이제 원하는 사이즈를 지정해 이미지 상황별 적절한 대응을 할 수 있게 되었습니다.Conclusionjekyll은 브랜디 랩스를 운영하기에 아주 유용한 도구입니다. 기본 템플릿도 훌륭하지만 상황과 편의에 맞게 변경하면 개성 있는 기술 블로그를 만들 수 있을 겁니다. 물론 커스터마이징이 어려울 수 있지만 jekyll의 메커니즘을 이해한다면 금방 적응할 수 있을 겁니다. 이제 블로그를 만들 모든 준비가 끝났습니다. 자, 도전해봅시다!부록1.글 반영 과정jekyll을 이용해서 글을 작성했나요? 이제 Github 저장소에 push하면 글이 반영될 겁니다. push하는 과정을 보면 빌드된 파일을 push하는 게 아니라, 원본에 해당하는 md파일 또는 html 파일을 push하는 걸 알 수 있습니다. push하면 Github page에 바로 반영되지 않고, 몇 분 정도 걸립니다. 이것을 통해 작성한 글이 저장소에 push되면 스케줄러나 트리거에 의해 빌드된다는 걸 유추할 수 있습니다. 아마도 빌드 결과를 위한 저장소가 따로 있고, 빌드된 결과가 저장되는 것이라 예상합니다.2.도메인 연결 방법jekyll 서비스에서는 구매한 도메인을 간편하게 연결할 수 있습니다. 프로젝트의 가장 위쪽에 CNAME 파일을 만들고 push하면 금방 적용됩니다.CNAME 파일3.추가 옵션에 대하여자료를 조사하던 중에 공식 사이트의 빌드 추가 옵션을 찾았지만 0.2초 정도로 큰 차이가 없었습니다. 만약 별도의 옵션이 없다면 빌드 결과는 _site 폴더로 모일 겁니다.공식 사이트 빌드 옵션옵션을 넣어 빌드옵션을 넣지 않고 빌드참고1) GitHub - christian-fei/Simple-Jekyll-Search: A JavaScript library to add search functionality to any Jekyll blog.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만