스토리 홈

인터뷰

피드

뉴스

조회수 2569

적절한 이벤트 데이터(Event Data) 추출하기

이번 칼럼에서는 프로세스 마이닝의 Input 요소인 이벤트 데이터에 대해 살펴보겠습니다. 이벤트 로그를 어떻게 얻고 프로세스 마이닝 분석이 가능하도록 어떻게 전처리를 할까요? 이벤트 로그는 SAP와 같은 ERP 시스템, 미들웨어, 금융 정보시스템, 사물인터넷 데이터 등 다양한 정보 소스에서 얻을 수 있습니다. 정보 소스는 어디에나 있으며 대부분 수많은 DB 시스템으로 구성되어 있기 때문에 문제는 어떤 데이터를 추출하고 어떻게 프로세스 마이닝에서 사용할 수 있는 이벤트 로그로 변환하느냐는 방법입니다. 아래 그림은 프로세스 마이닝에 필요한 데이터를 설명하는 개념 모델입니다. 각각의 케이스는 이벤트로 이루어져 있고, 이벤트는 여러 속성을 가질 수 있습니다. 원본 소스로부터 이와 같은 형태의 데이터를 추출하고 변환하는 방법이 필요합니다.[그림 1] 이벤트 로그 개념예를 들어 SAP에서 데이터를 추출하는 경우를 보겠습니다. SAP에는 수천 개의 테이블이 있고 여기에는 많은 이벤트 관련 정보가 있습니다. 정확한 데이터를 추출하려면 분석하고자 하는 프로세스가 무엇인지 정의하고 어디가 시작 위치인지 어디가 종료 위치인지 찾아야 합니다. 이러한 데이터 식별, 위치 지정이 제대로 되어야 적절한 이벤트 데이터 수집과 범위 선정이 가능합니다. 병원 데이터도 환자와 관련된 정보가 담긴 1,000개 이상의 테이블을 볼 수 있습니다. 병원 데이터를 분석하려면 마찬가지로 분석 프로세스를 정의하고 분석 범위와 이벤트 데이터 속성에 대해 정의해야 합니다. 이는 중요하지만 어려운 일입니다. 프로세스 마이닝을 위해 필요한 데이터는 여러 정보 시스템에 산재되어 있으며 수집할 수 있는 데이터의 종류와 양도 어마어마합니다.  근본적인 데이터 모델 구조를 이해하고 적합한 이벤트 데이터의 종류와 범위를 산정해야 하며 수집한 데이터를 하나의 테이블로 정리할 수 있어야 프로세스 마이닝을 위한 적절한 이벤트 로그 수집과 준비가 되는 것입니다.티켓 예약 데이터를 통해 데이터 추출과 이벤트 매핑을 살펴보겠습니다. 다음 그림에는 티켓, 예약, 공연, 지불, 고객과 같이 다양한 엔티티(Entity)가 있으며 이러한 엔티티는 관련된 이벤트 또는 액티비티를 가지고 있습니다.[그림 2] 티켓 예약 데이터베이스 구조데이터 분석을 위해 우리가 가장 먼저 결정해야 할 것은 프로세스 인스턴스, 즉 케이스가 무엇인가입니다. 우리가 티켓의 수명주기를 설명하는 모델을 알고 싶다면 티켓을 케이스로 설정하고 이에 해당하는 액티비티를 찾아야 합니다. 예약, 공연, 지불 등의 액티비티가 필요하며 여러 티켓이 동일한 예약 기록이나 지불 이벤트를 가지고 있을 수 있습니다. 따라서 여러 개의 다른 프로세스 인스턴스가 하나의 예약에 연결되어 있을 수 있습니다. 또한, 프로세스 모델이 예약에 대해 설명한다고 하면 다른 액티비티를 찾아야 합니다. 이러한 과정이 명확하거나 쉽지 않기 때문에 어려움이 있습니다. 하나의 예약에 5장의 티켓, 2번의 지불과 같이 여러 이벤트가 연결될 수 있습니다. 예약 취소와 같은 이벤트는 티켓, 공연, 예약 등 여러 엔티티에 영향을 미치게 됩니다. 따라서 엔티티 간의 단순 일대일 대응은 없으며 원하는 이벤트 로그를 얻기 위해서는 데이터 전처리가 필요합니다.케이스 선정과 매핑 문제 외에도 정확한 데이터 추출을 위해서는 고려해야 할 다양한 문제가 있습니다. 케이스나 이벤트가 기록되지 않는 데이터 누락이 발생할 수 있습니다. 실제 수행자가 아닌 다른 수행자가 기록되는 것과 같이 데이터가 정확하지 않을 수 있습니다. 원하는 데이터 레벨이 아닐 수도 있습니다. 예를 들어 개별 작업자에 대해 확인하고 싶은데 부서 레벨이 기록되어 있을 수 있습니다. 또 다른 문제는 관련성이 없는 데이터가 많아 분석 항목을 찾기 어려울 수 있습니다.지금까지 프로세스 마이닝의 이벤트 데이터 관련 문제를 검토하였습니다. 이러한 문제점을 염두에 두고 데이터를 추출해야 프로세스 마이닝 분석을 제대로 수행할 수 있습니다. 프로세스 마이닝 분석을 위한 로그 생성 가이드라인 (https://blog.naver.com/prodiscovery/221160671117) 칼럼을 참조하시면 데이터 추출 문제 해결에 대해 도움을 얻을 수 있습니다.#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트
조회수 1091

만땅에서 스푼까지 함께 달려온 찰스를 소개합니다

스푼을 만드는 사람들 여덟 번째 이야기마이쿤의 초창기 멤버 중 한 명인 'Charles' 를 인터뷰해보았다.그래서, 영어 유치원은 보내셨나요?https://brunch.co.kr/@mirr5510/17내가(Sunny) 처음 마이쿤에 입사하게 된 계기는 바로 Neil(대표)의 브런치 글과 마이쿤 관련 인터넷 기사를 읽고 나서였다. 많은 글 둘 중에 가장 궁금하고 특이하다고 생각했던 글이 바로 '영어 유치원' 보내자 였다.영어 유치원 보내자? 무슨 말이지? 하고 클릭해서 읽어보았다. 스푼 라디오라는 서비스 전 '만땅'이라는 배터리 공유 서비스를 시작할 때 첫 팀 빌딩에 관한 이야기였다. 닐의 주변 지인, 학교 후배들에게 함께 서비스를 만들자고 제안했을 때 유부남 팀원들에게 이렇게 말씀하셨다고 한다."우리, 아이들 영어 유치원 보내자"즉, 그만큼 잘하자. 우리 같이해서 성공하자라는 의미로 이렇게 말씀을 하신 것 같다. 그래서 찰스를 인터뷰할 때 가장 먼저 물어본 질문이었다. 그래서 아이들 영어 유치원은 보내셨는지 말이다.찰스 특징: 모자 좋아함"하하하.. 이미 저희 아이들은 많이 커서 유치원은 벌써 졸업했어요. 이제 테드랑 빅터의 차례가 아닐까 싶네요"찰스가 가장 좋아하는 맥주 'Charles' 당신이 궁금합니다.Q. 본인을 한 마디로 표현한다면?'동네형 또는 오빠' 저는 어색한 걸 싫어하고, 친화력이 좋은 편이기도 하고요. 사람들과의 편한 관계를 좋아해요. 그래서 먼저 보통 말을 먼저 잘 거는 편이에요"Q. 찰스도 혹시 딸 바보세요?"네, 저는 딸 바보예요. 아빠들은 딸 바보가 된다는 건 사실인가 봐요. 딸은 일단 아들과는 정말 달라요. 되게 예쁘고요.. 되게 애교가 많고요..(이때 눈이 반짝반짝하셨습니다) 아들은 보통 엄마를 찾던데, 딸은 항상 아빠를 찾더라고요. 아! 그리고 자다가도 아빠 들어오는 소리 들리면 나와서 뽀뽀해주고 다시 자러 가요. 6살인데 아빠한테 잔소리도 하고요. 마지막으로 하나만 더 자랑해도 돼요? 오늘 5일 만에 딸 얼굴을 봤는데 (안 자고 있을 때) 아빠가 엄~청 보고 싶었다면서 일주일치 뽀뽀를 엄청 많이 해줬답니다.. 이래서 다들 딸 바보가 되나 봐요."Q. 밀가루를 정말 좋아하신다고 들었습니다 feat. 코젤 다크"제 생각에 저는 탄수화물 중독자인 것 같습니다. 탄수화물을 정말 좋아해요. 특히나 칼국수를 정말 좋아하는데요. 맑은 거 말고 찐한 국물의 칼국수 있잖아요. 그거 너무 맛있어요. 제가 추천하고 싶은 칼국수집은, 논현동 영동시장에 있는 이름이 기억이 안 나는데.. 거기 진짜 칼국수 진짜 맛있습니다."P.S: 테드가 옆에서 조용히 슬랙으로 보내주셨습니다. 바로 이 칼국수 집이라네요. '손국시' https://m.blog.naver.com/PostView.nhn?blogId=rldudal0070&logNo=220165610372&proxyReferer=https://www.google.com/당신의 회사생활이 궁금합니다Q. 마이쿤의 초장기 멤버가 되신 계기를 더 알고 싶어요"저는 마이쿤에 입사하게 된 계기가 제 인생에서 가장 큰 결정이었어요. 저는 이 전 회사에서 9년 4개월 정도 근무를 했었어요. 그러던 어느 날 Neil이 회사에 놀러 오라고 하더라고요? 그래서 놀러 갔더니 보니까 이미 Yong 도 함께 일하고 있었고, 갑자기 닐이 사업 기획서를 보여주는 거예요. 이런저런 이야기 함께 나누다가 함께 일을 하자고 제안을 하더라고요. 정말 고민 많았어요. 마침 그때 제가 이직을 생각할 때였거든요. 그렇게 고민하고 와이프와 함께 의논을 했는데 고맙게도 와이프가 저를 믿어주고 응원해주었어요. 그리고 이런 생각을 했어요. "어차피 이직할 거라면 한 번 밑바닥에서 도전해보자!" 그리고 제 손으로 서비스를 함께 만들 수 있다는 것이 가장 큰 메리트이었고요. 드디어 내가 원하는 일을 하게 되었구나 생각했었죠. 무엇보다 서비스가 잘되면 우리 아이들에게 더 나은 미래와 경험을 줄 수 있다고 믿었고요. 무엇보다 잘 되지 않아도 살아가면서 나에게 정말 좋은 경험으로 남아 미래에 발판이 될 것이라고 생각했어요. 그렇게 저는 마이쿤의 초창기 멤버가 되었어요. 무엇보다 서비스에 대한 아이디어와 매력도가 높다고 느꼈고, 닐이 "영어 유치원 보내자!"라는 말에 혹했죠"Q. 첫 서비스를 실패했을 때 떠나지 않고 남았던 이유는?"제가 처음에 입사를 하자마자 와이프가 둘째를 임신한 걸 알게 되었어요. 근데 정말 너무 바빠서 집에도 못 들어가고 일을 했었어요. 가장으로서 남편으로서도 잘하고 싶었고, 일도 잘하고 싶었는데 마음처럼 쉽지가 않더라고요. 경제적으로 힘든 부분도 있었지만, 저는 이대로 이 팀이 헤어지기엔 너무나도 아쉬워서 남는 선택을 했어요. 저희 정말 열심히 했거든요. 진짜 정말 열심히 했는데 이대로 서비스가 잘 되지 않았다는 게 아쉬웠고, 이 일로 이 팀이 해체되는 게 너무 싫었어요. 그때 우리는 모두 정말 열심히 했지만 잘하진 못했었어요. 어떻게 가야 하는지 방향도 몰랐어요. 그래서 더욱 아쉬웠죠. 팀이 해체된다 할지 언정 후회 없이 헤어지고 싶었어요. 근데 저뿐만 아니라, 모든 사람들이 동의를 했어요. 우리 이번엔 열심히 하지 말고 '잘' 하자라고. 그리고 저는 외벌이에 유부남이라 팀원들이 저를 많이 배려해줬었죠. 와이프에게 가장 고마운 점이 그때 와이프가 그랬어요. "떠날 때 떠나더라도 후회 없이 해"이 말이 정말 큰 힘이 됐던 것 같아요. 와이프에게 많이 미안하고 고맙습니다."Q. 6년 동안 함께 해올 수 있었던 원동력은?"저는 정말로 솔직하게 여태 마이쿤에서 다른 곳으로 이직을 해야겠다는 생각을 해본 적이 없어요. 첫 번째 서비스가 망하고도 자발적으로 남은 이유도 이 팀과 함께 후회 없이 가고 싶다는 마음 때문이었어요. 저는 아직도 제가 성장하고 많이 배우고 있고, 배워야 한다고 생각하거든요. 어떠한 사람들과 일하느냐가 정말 중요한 것 같아요. 무엇보다 함께 시작하여 함께 실패하고 또다시 함께 일어났다는 점과 성장했다는 점이 기쁘고 뿌듯하고 더 큰 책임감을 느끼게 해 주거든요. 하지만 언젠가 제가 회사에 도움이 되지 않는 날이 온다면 그때는 스스로 떠날 생각입니다 (웃음)"Q. 리더로서의 삶은 어떤가요?"팀에 동료가 많아지게 되고 각각 다른 성격의 동료들이 생겨났어요. 각자 다들 일을 열심하 하고 잘하지만 팀으로서 하나가 되어 한 마음으로 커 나가는 건 다른 문제라고 생각해요. 각자의 개성을 살릴 수 있는 방법이 있을까? 내가 어떻게 하면 좋은 리더가 되어 후배들을 이끌어 줄 수 있을까? 하고 고민도 많이 해보고, 함께 이야기도 해보기도 하고요. 진심을 담아서 늘 말을 해요. 제 진심이 닿아야 팀원들도 저를 더 잘 따라 줄 테니까요. 면담을 통해서 불편한 것들을 해소해주려고도 노력하고 무엇보다 저도 그 들에게 많이 배우고 있어요. 아무리 신입이라도 해도 제가 생각하지 못한 부분을 배울 수 있거든요. 각자 살아온 환경과 경험이 다르고 본인이 잘하는 것들은 다 제 각각 다르니까요. 그래서 많이 노력하고 배우려는 리더가 되려고 노력 중입니다."Q. 새로운 서비스가 성장하면서 변한 게 있다면?Sunny 曰: "지난 만 5년 동안 마이쿤의 실패 그리고 재 도전 및 성장 과정을 모두 봐오셨잖아요. 뭐가 가장 많이 달라졌을까요? 정말 많은 것들이 변했겠지만요."Charles 曰: "저는 일단 스푼이라는 서비스가 성장하면서 좋아진 점이 정말 많아진 것 같아요. 그중 가장 큰 건 회사에 점점 더 전문적이고 실력 있는 분들이 입사하셨다는 겁니다. 물론 분위기는 예전하고 같을 수 없겠지요. 그때와 지금의 인원 차가 크니까요.분위기나 문화를 그때가 똑같이 유지를 한다는 건 불가능하다고 생각해요. 서비스의 규모에 맞게 함께 성장해 나가야 하니까요. 다양한 사람과 다양한 시선으로 보고 느껴야 회사 서비스가 더 성장할 수 있거든요. 그리고 서비스가 성장해야 우리 모두에게 좋은 일인 것이고요. 새로 입사하신 분들은 굉장히 능력자가 많으세요. 그분들에게 많이 배우려고 하고 있고 있고요"찰스가 좋아하는 진라면 + 파송송 + 계란탁 당신의 사생활이 궁금합니다Q. 좋은 아빠란 어떤 아빠라고 생각하세요?"내가 생각하는 좋은 아빠란?처음에는 애들과 재미있게 잘 놀아주면 그것만으로도 좋은 아빠라고 생각을 했었어요. 알고 보니 그것만으로는 부족하더라고요. 잘 놀아주는 것은 기본이고, 아이의 시선에서 세상을 바라봐 주고, 아이와 눈높이를 맞춰 주는 자세를 가져야 하고 제일 중요한 것은 아이의 마음을 공감해줘야 한다고 생각합니다. 이렇게 해야 정말 좋은 아빠가 아닐까?라고 생각합니다. 잘 놀아주는 것은 누구보다 잘한다고 생각합니다만 아직까지도 아이의 마음을 공감해주는 부분에서는  많이 부족합니다. 저도 모르게 아이를 혼내고, 반성하고 이 패턴이 반복이에요. 한때는 뱃속에 있을 때는 건강하기만을 원했는데, 막상 세상에 나와보니 어쩔 수 없나 봅니다."Q. 자녀분들이 개발자를 꿈꾼다면 추천하시나요?“개발자는 굉장히 매력적인 직업입니다.누구나 개발자가 될 수 있고, 즐길 수 있는 지금의 문화라면 저는 아이들에게 개발자가 되는 것을 추천해주고 싶어요. 성취감이라는 걸 얻을 수 있는 직업이기에, 그런 걸 느껴보게 해주고 싶기도 하고요.나의 재능으로 나를 포함한 누군가의 삶이 달라질 수 있는 경험은 좋은 경험이라고 생각해요. 무엇보다 개발자는 스스로 만들고 싶어 하는 욕구가 있는데요. 내가 개발한 서비스나 상품을 누군가가 사용하고 좋은 피드백을 준다면 정말 보람찬 일이거든요. 물론 부정적인 피드백을 받으면 상실감을 느낄 수도 있지만, 그 과정에서 또 성장해나갈 수 있기 때문에!”Q. 나중에 개발해 보고 싶은 서비스가 있나요?"있어요. 라면 서비스요. 저는 라면을 정말 좋아하거든요, 라면 중에서도 진라면을 가장 좋아하는데 진라면에 파 넣고 마늘 넣고 콩나물 넣고! 끓여먹으면 전 일주일 내내 먹을 수 있습니다. 그래서 '우리 함께라면'이라는 라면 서비스를 해보고 싶어요. 라면에 특화된 서비스죠. 제가 그래서 예전에 회사에서 사람들 한 명 한 명한테 혹시 라면 일주일 내내 먹을 수 있냐고 물어보기도 했었어요."Q. 만약 개발을 하지 않았더라면 지금 뭐하시고 계셨을 거 같으세요?"글쎄요. 저는 원래 사실 개발자가 되려던 마음은 없었어요. 군대 제대하고 우연히 한 번 해볼까? 했는데 시작하게 되어 업이 되었네요. 저는 아마 개발자가 아니라면 지금 공무원? 하지 않았을까 싶어요. 원래 저의 옛날 성향은 뭔가 모나지 않고, 평범한 사람이었거든요. 이렇게 큰 도전을 하기 전까지는요"당신이 마이쿤에서 우리와 함께 일해야 하는 이유는요저희는 정말 많은 실패와 역경을 거쳐왔고, 쓰러질 때마다 '함께' 일어났습니다. 이제서야말로 정말 본격적으로 성장하기 위해 달려야 하는 시점이에요.  해야 할 것도 정말 많고요. 회사와 서비스가 성장하는 경험을 할 수 있다는 것은 어디서 돈 주고도 못할 경험이라고 생각합니다. 지금 이 기회에 저희와 같은 배를 타신다면, 개개인이 노력한 만큼 서비스 성장에 기여하실 수 있고 본인 스스로도 성장하는데 많은 도움이 될 것이라고 생각해요. 이미 성장한 곳에서 경험을 하는 것도 분명 가치 있는 일이지만, 나 스스로가 성장에 기여할 수 있는 회사의 구성원이 될 수 있는 건 흔한 일이 아니라고 생각합니다.서비스 플랫폼 팀원들이 Charles를 한마디로 표현한다면?Kyu 曰:  '동네형' - 사실은 동네 아저씨에 더 가깝지만 마치 동네 형인 듯 다가와주는 사람.Sam 曰:  '장군님' - 어디서 자꾸 전리품(티셔츠, 스티커 등 )을 가지고 오신다.P.S 저희 어머님께서 NewRelic 티셔츠 편하다고 너무 좋아하십니다.Mark 曰:  '언니' - 가끔 삐지시는 거 같지만 언제나 잘 챙겨준다.
조회수 3392

Next.js 튜토리얼 2편: 페이지 이동

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기2편: 페이지 이동  - 현재 글3편: 공유 컴포넌트4편: 동적 페이지5편: 라우트 마스킹6편: 서버 사이드7편: 데이터 가져오기8편: 컴포넌트 스타일링9편: 배포하기개요이제 간단한 Next.js 애플리케이션을 만들고 동작시키는 법을 알았습니다. 이 간단한 애플리케이션은 하나의 페이지를 가지고 있지만 원하는 만큼 페이지를 추가할 수 있습니다. 예를 들어 pages/about.js에 다음 내용을 추가하여 "About" 페이지를 만들 수 있습니다:그러면 http://localhost:3000/about를 통해 About 페이지에 접근할 수 있습니다.이제 이 페이지들을 연결시켜야 합니다. 이를 위해 HTML의 "a" 태그를 사용할 수 있습니다. 그러나 a 태그를 사용하면 클라이언트 사이드를 통해 이동하지 않습니다. 원하지 않게도 서버 사이드를 통해 페이지가 이동합니다.클라이언트 사이드 이동을 지원하기 위해 next/link를 통해 export된Next.js의 Link API를 사용해야 합니다.설치이번 장에서는 간단한 Next.js 애플리케이션이 필요합니다. 이전 편을 수행하거나 다음의 샘플 애플리케이션을 다운받아주세요:아래의 명령어로 실행시킬 수 있습니다:이제 http://localhost:3000로 이동하여 애플리케이션에 접근할 수 있습니다.Link 사용하기두 개의 페이지를 연결하기 위해 next/link를 사용할 예정입니다.pages/index.js에 다음과 같은 코드를 추가해주세요.next/link를 Link로 import하여 다음과 같이 사용하였습니다:http://localhost:3000에 방문해주세요.그런 다음 "About Page" 링크를 클릭하면 "About" 페이지로 이동합니다.이것은 클라이언트 사이드 이동입니다. 이 동작은 서버 요청없이 브라우저 안에서 수행됩니다.브라우저의 네트워크 상태 검사 툴에서 확인할 수 있습니다.자 지금 간단한 과제가 있습니다:- http://localhost:3000에 방문하세요.- 그런 다음 "About Page"를 클릭하세요- 브라우저의 뒤로가기 버튼을 클릭하세요.뒤로가기 버튼을 클릭했을 때 어떤 일이 일어나는지 가장 잘 설명한 것은 무엇인가요?- 뒤로가기 버튼이 동작하지 않았다.- 뒤로가기 버튼이 브라우저 콘솔에 에러를 발생시켰다.- 클라이언트 사이드를 통해 인덱스(home) 페이지로 이동했다.- "뒤로가기 버튼을 지원하기 위해 'next/back'를 import하세요"라는 알럿창이 띄워졌다클라이언트 사이드 히스토리 지원뒤로가기 버튼을 클릭하면 클라이언트를 통해 인덱스 페이지로 이동합니다. next/link는 모든  location.history를 처리합니다.클라이언트 사이드 라우팅에 대한 코드를 단 한 줄도 작성할 필요가 없습니다.간단하게 페이지들을 연결하세요. 그래도 잘 동작합니다!Link 스타일링하기대부분의 경우 링크에 스타일을 지정하고자 합니다. 스타일을 지정하는 방법입니다:위와 같은 코드를 추가하면 스타일이 올바르게 적용된 것을 볼 수 있습니다.위의 코드 대신 아래의 코드처럼 작성하는면 어떨까요?위의 코드처럼 변경했을 때 어떤 일이 일어났나요?- 원하던 스타일이 올바르게 적용되었다.- 링크에 어떤 스타일도 적용되지 않았다.- 전체 페이지가 다시 로딩된 후에 스타일이 적용되었다.- 스타일이 적용되었지만 콘솔에 에러가 나타났다.Link는 래퍼 컴포넌트입니다사실 next/link에 있는 스타일 prop는 아무런 효과가 없습니다. 왜냐하면 next/link는 단지 "href"와 다른 라우팅 관련 props만 받아들이는 래퍼 컴포넌트이기 때문입니다. 스타일을 적용해야 한다면 하위에 있는 컴포넌트에 지정해야 합니다.Button이 있는 Link링크의 앵커 대신에 "button"을 사용해봅시다. 다음과 같이 코드를 수정해야 합니다:인덱스 페이지의 버튼을 클릭하면 어떤 일이 일어날까요?- 아무 일도 일어나지 않는다- "링크 안에 버튼이 올 수 없습니다"라는 에러가 발생한다- 페이지가 다시 로딩된다- about 페이지로 이동한다Link는 어떤 것과도 동작합니다버튼과 같이 커스텀 React 컴포넌트나 div 등을 Link 안에 배치할 수 있습니다.Link 안에 있는 컴포넌트들의 유일한 요구 사항은 onClick prop를 받을 수 있어야 한다는 것입니다.Link는 간단하지만 강력합니다이번 편에서는 next/link의 기본적인 사용법을 살펴보았습니다. Link를 사용하기 위해  몇 가지 재밌는 방법들이 있습니다. 다음 편들에서 배울 예정입니다.그동안 Next.js Routing documentation를 살펴보세요. 유용합니다.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유
조회수 811

스토어의 브랜딩: 항상 문제는 인사에서 시작된다

기본적으로 브랜딩은 이미지입니다. 처음보든 여러번 보든 이미지란 건 3가지의 속성이 있죠.1. 딱봤을 때 아.2. 계속 보니 음.3. 알고 보니 헐.소개팅할 때 이성이 금체인목걸이를 걸고 팔자걸음으로 들어오면 3초안에 '도망가야한다...' 라는 것을 느끼게 됩니다. 인지심리학에선 이를 초두효과라고 하죠. 3초냐 11초냐 등등 가설이 많긴 하지만 어쨋든 때릉~하고 문열리고 의자에 앉기까지 대략 첫인상이 결정된다는 것은 변함이 없습니다.그렇게 금체인을 걸고 앉아서 얘기를 한참하는데 의외로 순수하고 인간적인 매력이 있으면 일단 뭐지....하는 호기심과 궁금증으로 좀 더 지켜보게 되긴 합니다.그러다가 알고보니 금체인이 돌아가신 어머니의 유품이었달 지 고대로부터 내려오는 차크라의 금술이 담겨진 유물이었달지 등의 진실을 알게되면 비로소 이해가 되면서 금체인목걸이를 건 그사람에 대한 재정의를 내리게 됩니다. 이런식으로 이미지는 구축되고 유지되고 변형되죠.브랜딩도 비슷한 프로세스를 거칩니다. 받아들이는 사람 입장에서 말이죠. 대부분 회사에서 내거는 캐치프라이즈나 슬로건, 키비쥬얼 따윈 별 신경을 쓰지 않습니다. 내가 구매하는 것을 보죠. 제 아무리 브랜딩이 잘되어 있어도, 배송받아 본 상품이 다 깨져있는데 고객센터는 전화도 안받고, 문의답변도 안달리면 세련되고 나발이고를 떠나서 그냥 싫은겁니다. 스토어도 마찬가지입니다. 오프라인 매장을 운영하는 곳에선 그 직원들을 바라봅니다. 앱서비스를 운영하는 곳에선 앱버그 대처를 보죠. 이상한 기사가 났을 때의 대응방식도 중요하구요. 브랜딩은 비즈니스 전체보단 오히려 디테일에서 판가름이 납니다.오프라인의 브랜딩에선 대표와 BX팀이 의도한 것과 다른 여러가지 요소들이 발생하곤 한답니다. 행사운영을 할 때도 마찬가지죠. 사람들이 다아아아 내 맘 같이 움직여주지 않기 때문에 이는 불가피한 요소긴 하지만, 브랜드를 망치는 여러가지 사례들이 공공연하게 보여지는 것을 보면 어쩔 수 없다는 핑계로 그냥 덮어두기만 하긴 어려운 일 같습니다.오프라인의 브랜딩은 스멀스멀 작은 사례로부터 망가지는 경우가 많습니다. 이를 잘 알고 미리 대응하는 사례가 이솝이라고 할 수 있겠네요.Aesop의 경우엔 자사제품이 납품된 곳에 일일이 전화 또는 방문하여 어떤 곳에 어떻게 제품들이 배치되고 활용되고 있는지 등등을 일일이 체크하고 있습니다. 2014년 가로수길에 오픈한 시그니쳐 매장도 이솝의 브랜드컨셉이 잘 드러나도록 미술관 느낌을 주는 공간과 배치를 활용하고 있죠.번거롭고 어렵지만 하나하나 제품들의 쓰임새와 활용을 체크하면서 관리하는 일은 이솝에게 매우 중요한 일이었습니다. 그들에겐 제품이 곧 브랜드였기 때문이죠. 물론 이솝은 손떨리는 금액과 그에 걸맞는 예쁜 패키징이 존재합니다. 시각적인 이미지에서도 그 성분과 생산의도에 맞게 의약품의 느낌을 한껏 살렸습니다. 비쥬얼적인 측면에서도 좋은 브랜딩을 진행했지만, 중요한 것은 시그니쳐 매장이나 제품관리를 위해 파견되는 직원들의 애티튜드였죠.개인적인 사례지만, 여의도 IFC몰에도 이솝 스토어가 있습니다. 얼마 전 그곳을 처음 지나쳤을 때는 넓은 스토어에 단정한 복장을 한 매니저가 제품을 닦으며 정리하고 있는 직원을 보았습니다. 스토어의 분위기가 분위기인지라 구석에서 히터 틀어놓고 핸드폰만 만지작거리긴 힘든 공간이었을 겁니다. 꽤나 고급스럽다라는 느낌을 받았죠. 사람도 스토어도 함께 말입니다. 다음에 지나쳤을 땐 멍 때리고 계시더군요. 뭐 그냥 웃으며 넘기긴 했습니다만, 이렇게 글쓰려고 보니 다시 떠오르는 걸 보면 사람의 기억이란 것은 꽤나 오묘한 것들을 조합해서 단정짓는 것을 좋아하는 것 같습니다. 아마 멍때리는 모습을 처음에 봤다면 어떤 이미지가 되었을 지는 잘 모르겠네요.반면에 예상치 못한 큰 이슈들이 터져서 후속대응을 해야하는 경우도 있습니다.얼마 전 어떤 업체에서 배송직원들의 태도에 대해 논란이 있었던 적이 있었습니다. 물론 그 행위들이 회사의 잘못이라고 할 순 없습니다. 개개인의 운전습관 또는 인성의 문제일 뿐이니까요. 하지만 의도치 않게 이러한 사건들이 터져버리면 회사입장에선 굉장히 난감할 수 밖에 없습니다. 이렇게 외부이슈가 발생해버리면 회사는 3가지 정도의 선택지를 지니게 됩니다.1. 빠르게 대처해서 사과문 등 해명을 한다.2. 버티다가 못이겨서 공지를 한다.(사과는 아님)3. 쌩깐다.1번의 좋은 케이스는 배민의 예를 들 수 있겠습니다. 오프라인 사례는 아니지만, 일전에 배달업체에 대한 개인정보 문제에 대해 누군가가 이의를 제기한 적이 있습니다. 물론 배민에 직접적으로 게재한 것은 아니었죠. 하지만 당시 배달앱의 대표주자였기 때문에 배민은 빠르게 이슈에 대한 대응책과 책임의 글을 올렸습니다. 결과적으론 이 문제를 중요하게 생각하고 있고 문제해결의 의지를 엿보였다라는 평가로 오히려 브랜드이미지를 상승시키는 계기가 되기도 했습니다.해당이슈 기사 링크 참조http://www.the-pr.co.kr/news/articleView.html?idxno=225602번은 요즘 애플의 배터리문제를 들 수 있겠네요. 최근 터진 인텔사의 CPU문제도 비슷하구요. 결코 '사과'라는 표현은 쓰지 않더군요. 해당 이슈에 대해 선심성정책을 그것도 한정적으로 제공하면서 그럴싸하게 프로모션 행사처럼 포장하는 건 진짜 사태의 중요성을 몰라서 그런건지, 아니면 그냥 그런 스타일을 좋아하는 건지 잘 모르겠습니다만 딱히 좋은 평가를 받고 있는 것 같진 않습니다. 인텔사의 CPU메모리에 대한 스펙터와 멜트다운 버그가 발견되면서 인텔사도 굉장히 난감할 것으로 생각됩니다. 하지만 성능저하는 어쩔 수 없으니 업데이트해라...라는 식의 공지는 사람들을 벙찌게 만들기에 충분하죠. 폭스바겐의 배출가스 조작으로 인한 리콜사태 등도 어찌어찌 버텨보다가 결국 백기를 든 케이스라고 할 수 있겠습니다. 3번은 전략적침묵에 가까운데, 사실 이를 좋은 방식이라고 하기엔 애매하지만 사측의 입장에서보면 효율적이긴 한 것 같습니다. '어차피 잊는다.' 라는 것이죠. 이는 사실 프레임탈출법이라고 해서 1970년대 맥도날드가 경험을 통해 배웠던 전략이기도 합니다. 패티에 지렁이고기를 쓴다는 루머가 돌자 맥도날드는 반박하는 자료와 제조과정등을 공개하며 대응에 나섰죠. 하지만 어찌된 일인지 사람들은 더욱 외면하기만 할 뿐이었습니다. 말을 하면 할 수록 오히려 부정적인 정보가 강화되는 인지편향 때문이었죠. 맥도날드는 그냥 침묵하기로 합니다. 놀랍게도 사람들은 얼마 지나지 않아 다시 맥도날드로 돌아오기 시작했고, 지렁이패티 논란은 언제 그랬냐는 듯 사라지고 말았죠. 대중들이 지닌 인지프레임을 깨는 방식은 반박보다 침묵을 통한 망각에 의존하는 편이 효과적이라는 것이 전략적으로 드러난 사례였습니다. 하지만 이것은 누명과 오해를 벗기위한 방식이지 잘못된 것을 덮고 잊으려는 수단으로 전락해서는 안될 일이죠.맥도날드 지렁이패티 루머 관련링크https://lukekimwork.wordpress.com/2016/03/07/맥도날드-패티를-지렁이로-만든다고/어디라고 말은 못하겠지만, 전 국민적 나쁜회사라고 할 지라도...아쉽지만 소비자들에겐 도덕성보다 생활과 습관이 우선이 되는 경우가 많았습니다. 지금 이순간에도 말이죠.어더오데요... 이러한 비즈니스적인 사례 이외에도 사실 우리 주변에도 일상적으로 일어나는 여러가지 사례들을 통해 브랜드이미지를 생각해볼 수 있습니다.매장에 딱 들어갔을 때 영혼 빠진 표정으로 나를 졸졸 따라다니는 점원에게서 풍기는 다크포스라던지, 요금제 바꾸려고 전화했는데 날 비웃거나 무시하듯 대충 말하는 콜센터 직원이랄지, 심지어 강의장이나 행사에 갔는데 정신도 없고 어리버리한 스탭을 마주했을 때의 당황스러움 등에서 말이죠. 지난 행사장의 브랜드 편에서도 얘기를 했듯, 현장에서의 경험은 쉽사리 지워지지 않습니다. 저 또한 스토어에 들어갔다가 부담스럽거나 불친절해서 나와버린 경험이 다수 있으니까요. 그리고 그 곳은 잘 가지 않게 되더군요. 페이스북에서 보여도 딱히 좋은 느낌을 받진 않는 달까요. 사실 그 회사에 대해선 잘 모릅니다. 제가 알 필요도 없구요. 제가 아는 사실은 단지"그 때 그 사람은 불친절했어."라는 단편적인 사실 뿐이죠. 일반화의 오류가 확실하고 확증편향임에도 틀림없지만, 소비자에게'그렇게 단정지어서 판단하는 것은 논리적으로 잘못된거야!! 전체를 보고 비판적으로 판단해야지!' 라고 꾸짖는 것이 무슨 의미가 있을까싶습니다. 소비자는 브랜드 하나하나를 신중하게 논리적으로 고민하고 생각해볼 의무도 필요도 없잖아요. 그냥 아니면 안사는 거고, 싫으면 안보는 것일 뿐. 때문에 의사결정단계에서도 항상 이성적이고 논리적인 브랜드전략만을 고집하는 것은 현실과 잘 맞지 않을 위험이 있어요. 사업단에선 전체적인 것을 보고 탑다운 형식으로 브랜딩을 구축하려고 하지만, 정작 소비자가 보는 것은 구석에 있는 그 한 명의 사원이거든요. 물론 모든 디테일을 관리하기엔 어렵습니다. 회사 측에서 기쁜 소식은 인간은 망각의 동물이란 것이죠. 사실 뭔 사건이 생기고 치명적인 난리가 나도 시간 지나면 잊혀지긴 합니다. 위에서 프레임탈출법에 대해서 언급했듯 사실 말하면 말할수록 사람들은 그 문제를 단편적으로 강화시키기 시작합니다. 그리곤 어느새 그 자극에 지치기 시작하죠. 그게 도덕적으로 큰 문제가 있는 것이었다고 해도, 나의 삶과 큰 연관이 없다면 '어휴, 저거저거 나쁜놈들 쯧쯧쯧.' 하면서 마는 것이죠. 생각해보세요. 이 글을 읽고계신 독자분들 중 폭스바겐 배출가스 조작사건때문에 잠 못 이루고 불매운동을 벌이신 경험이 있는 분이 계신가요? 정작 내 차가 폭스바겐이고 리콜대상이 되지 않으면 그 문제는 그냥 뉴스거리에 불과하죠.강의업체도 그렇습니다. 운영은 엉망진창에 준다하는 자료도 안주고, 환불소식도 3달이 넘도록 답변도 없고, 온풍기도 안되서 춥고, 멀티탭도 부족해서 강의시간도 한참 지연되는 등 불만이 가득해져도, 끝나고 나면 그냥 그것으로 끝인 경우가 많아요. 물론 나는 다신 듣지 않겠지만, 또 다른 사람들은 그런 사실을 알든 모르든 계속 신청을 하겠죠. '내 일이 아니니까요.'기억안남이러한 망각과 외부화를 통해 브랜드의 리스크들은 대부분 중화되거나 잊혀지곤 합니다. 그러니 모든 직원들의 인사를 철저하게 관리하거나 매장의 운영이 제대로 되는 지 밤잠 설치며 힘들어 할 필욘 없습니다. 네, 이건 사실이예요.하지만, 분명히 할 부분이 있습니다. 브랜딩은 새로운 뭔가를 자꾸 만들어서 벌리는 것이 아닙니다. 하던 일을 더 잘하는 것에 가깝죠. 브랜딩을 위해서 사원교육을 하거나, 매장관리를 하는 방식은 뭔가 주객이 전도된 느낌입니다. 브랜딩은 그 행위를 통한 영향력이라고 할 수 있죠. 그러니 브랜딩을 잘하려고 애를 쓰는 것이 아닌, 일을 잘하기 위해 노력하는 것이 오히려 리스크를 줄이고 고객들의 만족감을 높일 수 있는 핵심이라고 말하고 싶어요.매장사원들에게 인사를 잘하라고 교육을 시키기 이전에, 그럴 수 있는 환경을 만들어주고, 스스로 참여하고 매출을 높일 수 있는 방식들을 고민하게 만드는 것이 더 중요해요.운영스탭에게 기획안을 숙지하라고 으름장을 놓기 이전에 분명하게 업무분장을 해주고, 너무 업무로딩이 걸리지 않게 업무효율화를 시켜주는 것이 더 중요하죠.제가 늘 말하듯 브랜딩은 디테일에서 폭망합니다. 그들의 졸음과 지겨운 표정이 브랜딩을 무너뜨리기 시작하죠. 그러나 그 전에....혹시 매장의 온풍기 온도가 너무 높진 않은지, 휴식시간이 충분히 보장은 되고 있는지를 먼저 체크해보는 것이 브랜딩컨설팅을 받는 일보다 더 중요하지 않을까요?
조회수 2017

하드웨어 스타트업의 딜레마 (3)

아이템이 결정되었다면 이제 제품의 기획과 개발을 시작해야 한다. 그러기 위해서는 그걸 실행할 사람이 있어야 한다. 그럼 하드웨어 제품을 만들기 위해서 어떤 사람들이 필요한지 살펴보자. 만들고자 하는 제품에 따라서 조금씩 다르지만 내가 1편에서 언급한 4가지 부류의 하드웨어 스타트업 중에서 마지막 부류의 스타트업은 어느 정도 대동소이 할것으로 보인다. 1편에서 언급한것 처럼 4가지 부류중에서 마지막 부류에 초점을 맞추어서 이야기 해보고자 한다.첫번째, 상품기획을 할 사람이 있어야 한다. 비즈니스를 이해하고 어느정도 기술을 이해하면서 제품의 컨셉을 잡는 사람이다. 스타트업의 경우 이 역할을 대부분 창업자가 하는 경우가 많다.두번째, 제품을 디자인 하는 제품 디자이너가 있어야 한다. 제품의 외형을 디자인하는 사람인데, 최근에는 단순히 외형을 예쁘게 디자인하는게 아니라 사용자의 경험을 디자인 하는 방향으로 바뀌었다. 난 개인적으로 제품 디자인이 제품의 개발에 있어 정말 중요한 요소라고 생각을 한다. 그리고 그건 단순히 예쁘게 만드는게 아니라 제품의 본질을 이해하고 사용자의 경험을 극대화 시키는 방향으로 제품을 디자인을 하는건 중요하면서도 어려운 문제이다.세번째, 기구 설계를 하는 기구 엔지니어가 있어야 한다. 제품 디자이너가 만든 제품의 컨셉을 실제 양산 가능한 제품으로 설계를 하는 역할을 수행한다. 제품의 외형적인 품질은 대부분 기구 엔지니어의 몫이다. 내구성, 양산성, 사용 편리성을 고려한 기구 설계가 되어야 한다. 그리고 제품의 제조 원가와 금형 비용도 기구 엔지니어가 어떻게 설계하는지에 따라서 크게 차이가 날 수 있다. 그렇기 때문에 기구 엔지니어도 정말 중요하다.네번째, 회로 설계를 하는 회로 엔지니어가 있어야 한다. 제품의 기능을 구현하는 역할이라고 볼 수 있다. 상품기획이 구성한 제품의 기능을 구현할 수 있는 부품을 선정하고 회로를 설계하고 Firmware까지 구현하는 역할을 수행한다. 제품 원가의 대부분이 부품 비용이고 기능 상의 품질이 회로 설계와 Firmare에 기반하기 때문에 회로 엔지니어의 역할은 정말 중요하다. 동일한 성능을 좀더 값싸고 안정적인 부품을 통해서 구현하는게 노련한 회로 엔지니어가 할 수 있는 일이다.다섯번째, 최근에는 하드웨어와 SW가 융합하는 추세이기 때문에 SW를 만드는 팀이 필요하다. SW 개발자, UI/UX 기획자, GUI 디자이너가 필요하다. SW와 함께 움직이는 제품에서 SW 품질은 제품의 성공에 큰 역할을 수행하기 때문에 SW 팀 전체가 다 중요하다.위에 쓰다보니 안 중요한 역할이 없다. 결론은 다 중요하다. 이제 하드웨어 스타트업이 딜레마가 나온다. 이 많은 사람들을 다 내부에 채용할 수 있을까? 1명씩만 있어도 7명이다. 창업자가 1개 정도 역할을 멀티로 수행하고 UI/UX기획하는 사람이 GUI까지 하는 경우도 있으니 더 줄이면 5명이다. 초기 스타트업에게 5명은 적지 않은 숫자이다. 그럼 여기서 외주를 고민을 하게 된다. 어떤 역할을 외주로 할 수 있을까? 사실 상품기획말고는 다 가능하다. 제품 디자인을 하는 전문 회사도 있고 기구 설계를 해주는 회사, 그리고 회로 개발을 해주는 회사도 있다. 당연히 앱을 만들어주는 회사도 널려 있다.그런데 외주가 맞는 방법일까? 스타트업은 대부분 본인들이 만들어야 하는 내용을 정확히 모른다. 세상에 없던 제품을 만들고자 하는데 정확히 안다는게 더 이상하다. 계속 시행 착오를 할 수 밖에 없다. 그런데 외주를 하는 업체는 시행 착오를 극도로 싫어한다. 한번 계약을 하면 스펙을 결정하고 그대로 진행해서 결과물 전달하고 돈 받으면 끝이다. 만들었는데 이게 아닌것 같아 다시합시다. 이런 말을 극도로 싫어한다. 과연 시행 착오를 몇 번을해야할까? 그것도 알 수 없다. 스타트업은 사업도 제품도 모두 불확실하기만 하다. 극도로 제한된 예산만 가진 스타트업이 시행착오를 할때마다 외주 비용을 따로 주는건 쉽지 않은 일이다.외주? 내부 채용? 뭐가 답일까? 쉽지 않은 질문이다. 외주도 공짜가 아니고 채용도 공짜가 아니다. 물론 모든 역할을 수행할 수 있는 창업 팀을 구성해서 적은 연봉을 받아가면서 혹은 공짜로 일하면서 시제품을 만들 수도 있다 그렇게만 할 수 있다면 그게 제일 나은 선택지일 것이다. 쉽지 않은 일이다. 결국 결론은 창업자의 몫이다. 극단적인 외주도 옳지 않고 초기 스타트업이 모든 구성원을 내부 채용으로 보유하는 것도 쉽지 않다. 팀빌딩에 있어 내부 채용과 외주 사이의 딜레마를 어떻게 풀어낼지는 초기 하드웨워 스타트업 창업자의 중요한 의사 결정사항이다.#NEOFECT #스타트업창업 #초기창업 #창업자 #인사이트 #조언
조회수 977

[Tech Blog] Software architecture: The important stuff

마틴 파울러는 Software architecture 를 “무엇이건 간에 중요한 것들(The important stuff whatever it is)” 이라고 정의합니다. 조금은 재미있는 정의지만, 그 정의를 도출하기 위해 제시한 다른 정의를 들어보면 고개를 끄덕이게 합니다.  Software architecture 는 전문 개발자들이 같은 생각을 가지고 이해하는 시스템 디자인입니다. Software architecture 는 이른 시기에 정해져야 하는 디자인 결정들입니다. 혹은 여러분이 “아, 처음부터 좀 더 잘 생각하고 할 껄”이라고 후회하는 바로 그 결정들입니다. Software architecture 는 또한 바꾸기 어려운 결정들의 집합입니다.  결국 무엇을 중요하게 생각할 것인가, 그것이 Software Architecture 라는 의미입니다. Why is it important? 왜 중요한지 설득하지 못한다면 사실 중요하지 않은 것일지도 모르죠. 그래서 왜 Software Architecture 이 중요한지 짚어보고자 합니다. 쿠팡은 Microservice architecture 로 전환하는 여정을 글로 남겼는데요. 블로그 글의 제목을 “행복을 찾기 위한 우리의 여정” 이라고 지었습니다. (좋은 글이니 읽어보시길!) 다시 말해서, Software Architecture는 개발가자 더 좋은 제품을 만들 수 있는 길이기 때문에 중요하다고 말합니다. 그러나 좋은 Software Architecture를 만드는 일은 쉽지 않습니다. 블로그 글을 인용 해보겠습니다: “여기 저렴한 제품과 비싼 제품이 있습니다. 비싼 제품은 software architecture 가 잘 고려되어 있고, 저렴한 제품은 시스템 디자인에 대한 고민 없이 구현되어 있습니다. 하지만 두 제품은 겉으로 보기에 차이가 없습니다. 소비자가 보기에 똑같이 보이고, 똑같은 기능이 있으며, 성능 또한 같습니다. 어떤 제품을 사야할까요?” 소비자는 제품을 만든 개발자의 행복을 위해 더 비싼 제품을 선택하지는 않습니다. 개발자 역시 동료들에게 “내가 행복하려면 시간과 돈이 좀 더 들더라도 좋은 software architecture 를 구성해야 해.” 라고 주장하기엔 설득력이 부족하죠. Software architecture 가 왜 중요한지 모두가 공감하려면 경제적인 입장에서 그 중요성을 설득해야 합니다. “내부 품질을 좀 포기하더라도 이번 릴리즈에 더 많은 기능들이 들어가야 해.” 라는 의견에 “안돼 우리(개발자)는 더 전문적으로 구성해야 해.”라는 의견으로 대응하면 항상 질 수 밖에 없습니다. 장인 정신과 경제 논리 사이의 싸움에서는 경제 논리가 항상 이겨왔거든요.   Cumulative functionality over Time Software architecture 를 고려하지 않으면서 제품을 개발하면 초기에는 기능 추가 속도가 빠를 수 있지만, 시간이 흐름에 따라 제품의 기능 증가 속도는 점차 느려집니다. 이미 구현된 기능들과 코드가 새로운 기능을 추가하는데 걸림돌이 되기 때문입니다. 한편, 좋은 설계를 지속적으로 건강하게 유지하고, 주기적으로 리팩토링을 하고, 코드를 깨끗하게 유지한다면 시간이 흘러도 기능 추가가 느려지지 않을 수 있습니다. 오히려 기능을 추가하기 위해 수정해야 할 곳들이 명확하고 모듈화 또한 잘 되어있기 때문에 시간이 갈 수록 기능 추가가 더욱 빠르게 진행될 수 있습니다. 새로운 개발자가 참여하는 시점에도 시스템을 더욱 빠르게 이해하고, 더 빠르고 안전하게 기능을 추가할 수 있게 됩니다. 결국 장기적으로 더 많은 기능을 생산하고 빠르게 고객에게 전달하기 위해서 개발팀은 좋은 디자인과 설계에 대해 깊게 고민해야 합니다. What is the best software architecture? 옳은 software architecture 는 없습니다. 상황에 따라 해답은 다를 수 있습니다. Microservice architecture 가 좋다고 해서 모든 것에 대한 답이 microservice architecture 인 것은 아니고, 마찬가지로 어떤 시스템이 monolithic architecture 로 구현되어 있다고 해서 뒤쳐져 있는 것도 아닙니다. 모든 선택에는 Tradeoff 가 있기 마련이니까요. 유선 통신 시스템을 구성한다고 생각해 볼까요? 우리 나라처럼 인터넷이 잘 구성된 상황에서 Skype 로 할 수 있는 통화는 무료이고, 품질도 좋고, 영상 통화까지 됩니다. “Skype 만세! 인터넷을 통한 통신이 항상 옳습니다!” 라고 외치려던 시점에 정전이 되었습니다. 방금 외친 외침은 멀리 가봐야 옆집 정도 닿겠죠. 한편 기존 유선 전화 시스템은 느리고 화상 통화도 안되지만, 전화선 자체에 전원이 공급되고 있기 때문에 정전 시에도 통화가 가능합니다. 전쟁 상황이나 기타 재난 등에도 반드시 통신이 가능해야 하는 곳은 유선 전화 시스템이 꼭 필요할 것 같습니다. 은행 시스템도 적절한 예시가 될 수 있습니다. 비밀번호 입력, 전화 인증, OTP 확인하는 등 은행 업무는 왜이리도 복잡할까요? 그냥 비밀번호 기억해주고 로그인 유지해주면 참 편할텐데 말이죠. 안전하기 위해서겠죠. 여러분의 자산은 소중하니까요. 사용성(Usability)과 안전성(Security)은 종종 둘 사이를 조절해야 하는 Tradeoff 입니다. 만들려는 제품과 시스템, 환경, 시기와 조건 등에 따라서 적절한 architecture 는 달라집니다. 좋은 architecture 를 선택할때 개발자는 선택한 것의 대척점에 있는 무언가를 포기 해야합니다. 그렇기에 software architecture 는 기술적인 범주 안에서만 고려되면 안되고, 구현하고자 하는 비지니스를 매우 잘 이해하고 고려해서 적용해야 합니다. What are you going to do? 이미 구성된 software architecture 를 변경하는 것은 굉장히 어렵습니다. 이미 구성되어 있는 것들을 상세하게 알고 있어야 하고, 비지니스의 요구 사항을 수용해야 하며, 이미 존재하는 기능이 변경 도중 문제 없이 동작해야 합니다. 또한 기존 시스템에 기여한 개발자들과 변경 사항에 대한 공감대를 이뤄야 하며, 겉으로 보기에 당장 변화가 없는 것에 대한 비용에 대해 많은 사람들을 설득해야 합니다. 최근 Buzzvil 에서는 Architecture Task Force 팀을 구성하였습니다. 이를 통해 전체적인 설계를 정비하고 모든 개발팀이 구조적으로 같은 이해를 할 수 있도록 분석, 조사, 계획 수립, 실행에 옮길 예정입니다. 지속적인 공유를 통해 전사적인 공감대를 유지하고 체계적인 문서화와 가이드라인을 통해 모든 팀원이 함께 실행하며 성장할 수 있는 기반을 준비하게 될 것입니다. 궁극적으로 전사 프로젝트와 모든 팀이 더욱 빨리 움직일 수 있는 software architecture 를 구성하고, 이를 통해 더 많은 기능을 더 빠르게 전달할 수 있게 할 것입니다. 아직 해야할 일들이 많이 남아있지만 제대로 계획하고 빠르게 움직인다면 충분히 좋은 결과를 만들 수 있을 것 같습니다. 당장은 눈에 보이는 변화가 없을지라도, 좋은 디자인에 대한 고민과 실행이 우리가 궁극적으로 바라는 비전과 목표에 한 걸음 더 빠르게 다가가는 올바른 길이라고 믿습니다.   *버즈빌에서 개발자를 채용 중입니다. (전문연구요원 포함)작가소개 Whale, Chief Architect “Keep calm and dream on.”
조회수 1521

AWS 이사하는 날

오늘 8퍼센트의 AWS 인프라를 일본에서 한국으로 옮겼다. 기술적인 내용은 이사를 리드하신 세바님이 다뤄 주시기로 하셨고, 나는 그냥 오늘을 남겨두려고 한다.(세바님이 8퍼센트 서울살자에 기술적인 내용들을 다뤄주셨다.)올해 초 AWS 서울 리전이 열리면서 도쿄에서 옮겨 가야겠다 라고 생각한 것이 벌써 수개월이 지났다. 작업을 시작하면 얼마나 걸릴지 예상이 잘 되지도 않고, 인프라 전체를 예쁘게 정리해야 한다는 부담 때문에 쉽게 손이 가지 않았다. 하지만 새로 조인하신 세바님이 AWS 이사를 가지 못해 여러 가지 제약이 생기는 답답한 상황을 참지 못하시고 총대를 메셨다. 아마 나보다 좀 더 답답하셨나 보다. :)17시에 다 함께 모여 현재 작업 진행상황과 오늘 이전 계획을 검토한 후 바로 퇴근을 했다. 긴 밤이 되리라 생각해서 조금이라도 잠을 자려고 노력은 했지만 두 아이가 있는 집에서 쉬는 것은 역시 쉽지 않더라. 지하철을 타고 23시 30분에 이모작 근무를 위해 다시 회사에 들어섰다. 이미 몇몇 분이 모여서 오늘 작업에 대한 이야기를 나누고 있었다. 아침에 만나는 것보다 왠지 반갑다. 모두 모여서 파이팅을 외치고 기념사진을 하나 찍고 작업을 시작했다.(웃으면서 시작한 작업을 웃으면서 마칠 수 있을 것인가?)일단 서버 작업 공지를 띄우고 작업을 시작한다. 지난 회사에서는 모든 서비스가 24시간 운영되었어야 했기 때문에 서버 점검 시간을 따로 갖지 못해다. 그래서 큰 서버 업데이트 작업을 할 때마다 시간에 쫓기고, 장애 발생을 실시간으로 해결해 가며 작업을 했었다. 하지만 이번에는 시간을 확보해두고 작업을 하는 것이라 그래도 마음에 좀 여유가 있었다.이전 작업을 하기 위해 각 파트를 담당하는 시니어 개발자들만 있어도 충분한데, 서버 이전을 하는 것이 흔치 않은 경험이기 때문에 주니어들도 가능하면 참여를 요청했다.(꼬꼬마들이 세바님 뒤에 쪼르르 모여서 설명을 듣고 있다)코드를 이해하기에 가장 좋은 방법은 코드를 함께 짜면서 설명을 하는 것이고, 인프라를 이해하기에 가장 좋은 방법은 인프라를 설치하는 과정을 함께 하는 것이다. 하나하나 작업을 해가면서 이런저런 이야기들을 나누었다. 이전을 하는 서버의 역할, 더 나은 아키텍처,  AWS의 역사,  AWS의 여러 가지 서비스의 세부적인 옵션에 대해서도 이야기를 나누었다.  세바님이 꼼꼼하게 준비를 해주신 덕분에 1시 30분이 되니 기본적인 이전 작업이 끝났다. 야식을 먹고 맥주를 한잔 마시고 각각의 기능들에 대한 본격적인 테스트를 시작했다.(야식은 12시 전에는 치킨을 시켜야 하고 12시 후에는 족발을 시켜야 한다)드디어 세바님을 제외한 다른 잉여 인력들이 할 일이 생겼다. 체크리스트에 있는 항목들을 하나씩 테스트 하기 시작한다. 꼼꼼하게 준비를 했지만 역시나 예상하지 못했던 문제들이 드러난다. 다행히 이전 작업을 되돌려야 할 만큼 큰 문제는 아니었기에 적절히 대응을 하고 계속 테스트를 진행했다.어느덧 시간이 흘러 3시가 되었다. http://8percent.kr 의 도메인을 도쿄에 있는 서버에서 서울에 있는 서버로 변경했다. 이제 내부 시스템들을 추가적으로 점검해야 한다. 가능하면 끝까지 확인을 하고 자리를 뜨고 싶었지만 내일 오후 사무실을 지키면서 혹시 모를 장애에 대응을 해 줄 사람이 필요할 것 같아 먼저 퇴근을 했다.집에 돌아오면서 생각해 보니 오늘 내가 한 일이 거의 없었다. 기뻤다. 서버 이전 작업을 내가 해야만 하는 일로 생각하며 계속 들고 있었는데 세바님이 먼저 나서서 이 일을 진행해 주셨다. 중요한 작업 중에 자리를 뜨는데도 전혀 불안함 마음이 들지 않았다.아침에 일어나서 슬랙을 확인했다. 슬랙에 별다른 멘트가 없는 것을 보니 큰 문제는 없나 보다. 야호! 이전된 서버가 정상적으로 운영되고 있는지 확인을 위해 심사팀도 일찍부터 출근해서 테스트를 진행하고 있었다. 회사에 도착해 보니, 나를 제외하고는 모두 밤을 새워 일을 하고 계셨다. 다들 몽롱한 표정이다. 고맙다.하루에도 8시간씩 같이 일하는 동료들이지만 왠지 이렇게 같이 밤을 지새워서 작업을 하고 나면 동지애가 생긴다. 긴 밤을 고생해준 개발팀 멤버들에게 다시 한번 고마운 마음을 전한다. 앞으로도 잘 부탁드려요!(제가 따로 드릴것은 없어서 박수를!)#8퍼센트 #에잇퍼센트 #AWS #서버 #서버이전 #인프라 #개발팀 #팀워크 #조직문화
조회수 731

사랑받지 않아도 되는 자유

누가 이로부터 자유로울 수 있을까?인간은 사회에서 관계를 맺기 시작하는 그 순간부터 그 대상자에게 사랑받고 싶어한다.누군가로부터 사랑받고 인정 받음으로써 성취감과 존재감을 느끼는 것은 어쩌면 너무 당연한 것이다.하지만 누군가의 애정을 얻는 다는 것은 쉬운 일이 아니다.경쟁과 갈등은 그렇게 사랑을 쟁취하기 위해 시작된다.부모의 사랑을 차지하기 위한 형제 자매사이의 본능적인 몸부림부터, 선생님의 애정을 차지하기 위한 친구들과의 성적 쟁탈전, 이성으로 부터 애정받기 위한 남녀간의 매력 발산 경쟁, 그리고 상사에게 사랑받기 위한 조직내 성과 쟁탈전에 이르기까지 인생 전체가 사랑과 인정을 갈구하는 쟁탈전이다.문제는 소수만이 누릴 수 있다는 것이다.누구에겐가 사랑받기 위해 지나치게 에너지를 쏟는 이들에 비해 '자존감'으로 무장하고 타인의 시선보다도 자신만의 길을 가는 이들을 보면 참으로 평화로워 보인다. 스스로를 사랑하고 인정함으로써 누군가에 기대어야 하는 '애정받기'이서 자유로울 수 있는 것이다.말 잘듣고 사랑받는 강아지는 늘 주인의 행동과 표정에 눈치보기에 쉼이 없다. 주인의 요구에 더 빨리 움직일 수록 먹이와 칭찬에 길들여지기 때문이다.연말이다.학교에서는 시험과 성적, 직장에서는 평가와 고과가 애정과 인정의 잣대가 된다. 특히 직정에선 자칫 인간의 비열한 모습이 드러나는 시기이다. 직장인의 숙명이다.직장으로부터의 탈출을 꿈꾸는 많은 이들은 이 비열함과 동의할 수 없는 사랑받기 게임에서 자유롭고 싶기 때문이다.사랑받지 않아도 되는 자유.타인의  평가로부터 자유로울 수 있는 용기.스스로 당당해지자
조회수 896

왜 이렇게 말하는 걸까. 업무용어 대혼종 BEST 20

세상에서 한국말이 제일 어려운 것 같아요. 특히 우리나라 사람의 얼굴을 하고 있지만 막상 일해보면 외국계기업에 다니는 듯한 묘한 착각이 들만큼 서로간의 커뮤니케이션은 어렵습니다. 대부분의 커뮤니케이션의 문제는 3가지의 원인이 있어요.1. 방향성이 다르다.나는 고객만족 우선이라서 CS쪽을 강조하고 싶은데, 저 사람은 내부시스템이 먼저여서 업무효율화를 먼저 얘기하고 있다. 이런 건 잘 대화로 풀거나, 설득을 하거나, 대장님 말에 따르던가, 암바를 걸면 해결이 돼요. 어려운게 아니죠. 상대적으로2. 방법론이 다르다.나는 정량적인 걸 중요시해서 숫자를 중심으로 얘기하는 걸 좋아하는데, 저 사람은 정성적인 만족감을 가지고 얘기해. 서로 얘기하는 부분은 같은 데 평가요소나 관점이 좀 다른 경우예요. 사실 이 경우는 크게 싸울 필요가 없어요. 둘이 합치면 되거든요.3, 뭔 말인지 모르겠다.이게 문제라구요. 이게. 1,2번은 기본적으로 상대가 뭔 말을 하는 지는 알아듣겠어요. 그러니 싸울 수가 있는거지. 근데 3번은 이게 무시무시해요. 언어의 주기능이 상실된 상태랄까요. 의미는 사라지고 소리만 남아있는 상태랄까요. 그래서 오늘은 3번에 대해 좀 알아보려고 해요.젤나가 맙소사..1. 영한중 합성명사 저그프로토스 혼종'콘텐츠기반 디스튜리뷰트형 AI모델.'= 명사와 명사가 붙은 걸 합성명사라고 하는데, 보통 단어란 것은 들었을 때 의미가 떠올라야 합니다. '논밭' 이라는 말을 했으면 대략적인 두 가지의 이미지가 다 떠오를 수 있어야 하죠. 그런데 위 단어는 어느 하나도 시각화가 되지 않습니다. 저건 그냥 갑골문자 같은거죠. 거북이 등껍질에 적어놓은 동물 피같은 느낌이예요. 단어를 합칠 땐 두 단어 모두 뜻이 명확해야 합니다.이것과 비슷함이다.2. 수동태에 한이 서림유통되어지게 만듭니다. / 기여되게 합니다. / 만족감이 제공되게= 우리나라 말에 이런 문법은 없습니다. 능동형으로 쓰는 걸 추천드려요. 유통하다. 기여하다. 제공하다.지금까지 ~~되어져왔다....3. 한영키 성애자A와 B의 내용을 shift 해서 이미지를 좀 더 roll up 했으면 합니다. 전반적인 tone-development 가 필요할 것으로 보입니다.= 이렇게 쓰면 안힘들까....싶어요. 뭐 어쩔 수 없이 영단어를 써야 하는 경우도 있습니다. 한글로 해석이 어려운 고유명사나 약어와 같은 것들은 영어를 쓰는게 맞죠. 하지만 그런 경우가 아닌데도 한영키를 저렇게까지 정성스레 사용한다면, 아무리 봐도 '한글단어가 잘 생각이 안나시나 보다..' 라고 생각할 수 밖에 없습니다. 한글을 사랑합시다..외국인도 이렇게 한글을 잘 쓰는데....4. 결투신청모서리 그부분을 좀 더 질감이 두드러진 느낌으로 해주시고 흰색 부분을 커브드해서 색감을 올렸으면 합니다.= 이런 단어/표현/묘사는 없어요.5. 이승철저희 기술이 추구하는 바는 콘텐츠 기반의 딥러닝 기술을 바탕으로 소비자들이 제공하는 일련의 온라인 콘텐츠를 학습하여 다양한 분야에 적용을 통해 생산성을 높이고 콘텐츠를 제공한 소비자들에게 그 보상이 돌아가게 하는 방식으로써 이더리움 기반의 어쩌고....= 숨을 쉬세요 숨을... 문장은 짧게 끊어주는 게 좋더라구요.. 읽다가 눈이 숨차면 안되니까.바끄로 나가버리고오오오오오오오오오오오오오오오오오오오오오오오오오..6. 그거 아닌데요.명도를 좀 더 진하게 해주시고 라운딩된 부분에 힘이 실렸으면 좋겠습니다.= 명도는 진해질 수 없고 라운딩엔 힘이 실릴 수 없습니다. 적합한 단어를 써주세요. 명도는 밝거나 어두운거고 채도는 진하거나 연한겁니다. 7. 궁예그거 알지? 그 있잖아= 몰라알겠느냐?8. 적(=enemy)색감적으로 좀 컨셉적인 부분이 잘 살아났으면 하는데, 심미적인 부분과 정성적인 부분이 잘 매칭되었으면 합니다. = 느낌적으로 이건 아닌 것 같아요. ~적으로 란 표현은 번역체인데 은근 자주 쓰입니다. 저도 많이 쓰기도 하구요. 정 써야겠다 싶으면 통상 알고 있는 어휘를 써주세요. 색감적....이런 말은 좀 애매하죠....9. 메아리로고의 재구성 부분에 있어서 다시 정리하는 것이 필요할 것 같습니다. 구성을 좀 더 다르게 해서 색다른 느낌을 낼 수 있을 것 같은데 이러한 구성의 develope은 디자이너분의 의견을 참고하여 arrange 해보겠습니다. = 로고의 재구성, 구성을 다르게, 구성의 디벨롭, 어레인지...다 똑같은 말입니다. 그냥 단순하게 '로고 다시 만들어주세요.' 란 말이잖아요. 주로 이렇게 같은 뜻의 말이 반복되는 건 지나치게 예를 차릴려고 하거나, 아니면 쓰면서 생각하면 이런 현상이 종종 나옵니다. 생각을 먼저 하고 잘 정리해서 쓰도록 해요.10. 종결어미 창의대장다른 파트로의 확장도 가능할 것으로 생각되어집니다. 기한 내에 마무리가 된다면 넥스트 단계로 넘어가는데 좀 더 수월하다고 보입니다. = 저렇게 쓰면 논설위원같고 기자가 쓰는 말 같고 그래서 그런가 봅니다. 종결어미는 깔끔하게! 11. 잠깐잠깐 뭐라고?몇 가지 질문이 있습니다. 우선 폰트배치에 있어서 적용이 어디부분에 어떤 내용으로 가능한지, 두 번째 현재 도드라지게 보이는 부분을 좀 더 소프트한 느낌으로 밸런스화 시킬 수 있는지, 마지막으로 가능하다면 내부팀의 의견이 수용된 피드백을 드려도 괜찮은지요?= 저..저도 질문이 있는데요!...질문은 넘버링을 하고 짧고 시원시원하게 질문해보아요.1. 제목에 폰트 변경 가능할까요2. 중간에 사람이미지 조금 부드러운 곡선으로 변경 가능할까요.3. 저희 측에서 나온 아이디어 취합해서 드리겠습니다.12. 전문용어 폭격DAC의 기본 원리를 적용하고 있는데 가변저항에 대한 이슈를 해결하기 위해 저항값의 병렬화를 통한 디지털 전송방식을 채택했습니다.ES링크와 USB-C타입을 모두 호환하며 동축이나 광입력시에도 동일한 음원을 유지할 수 있습니다.= 쉽게 설명하는 건 좋은 능력입니다. 일단 내 사업과 분야를 완전히 이해하고 있어야 비유나 묘사가 가능하거든요. 예시를 드는 건 생각보다 고급스킬이더라구요. 내가 하는 일을 먼저 잘 이해하도록 합시다.우두두두두두두....13. 개드립신규사업은 신대리가 신씨니까 잘할 것 같은데 크하하하하= 아눼...14. 시간을 달리는 소녀그 때 그러셨었는데, 그 왜 예전에 한 번 얘기했을 때 있잖아요.= 잊혀진 공허의 시간속에서 헤매지 말고 메일을 찾아보거나 슬랙을 뒤지도록 합시다. 15. 무효카드여튼, 그게 문제가 아니고.= 상대방의 모든 패를 무효로 하고 게임을 원점으로 돌립니다. 사수나 팀장급 이상의 플레이어가 사용가능하고 이에 대응할 수 있는 카드는 '사직서' 등이 있습니다.16. 푸른눈의 백룡 카드아니 근데 그렇게 하면 또 이게 문제잖아.= 상대방의 카드에 모두 반박하여 3,000의 데미지를 줍니다. 5턴이 지난 후 상대방은 마비되어 2턴간 카드를 꺼낼 수 없습니다. 언짢은 표정과 함께 발동할 시 효과는 배가됩니다. 자꾸 이렇게 딴지만 걸고 방법은 얘기안하면서 불평불만만 많은 분들이 가끔씩 복병처럼 존재합니다... 가급적 저런 사람과 안만나길 기도드리겠습니다..어떠한 상대라도 분쇄해버림17. 하나도 정리가 안됐음정리해드리자면 위 내용과 같은데, 일시나 과업내용, 비용등은 아직 미정인지라 업데이트 되는 대로 알려드리도록 하곘습니다.= 일시와 과업내용과 비용을 빼면 뭐가 정리가 된거죠?...18. 산파법넌 이게 맞다고 생각해? 타겟이 이 사람이 맞아? 이게 정말 괜찮은 거라고 보시나요?= 주로 갈굴 때 많이 사용되는 방법이죠. 소크라테스도 질문을 통한 자기성찰 방식을 주로 활용했다고 하는데 이 분이 맘 나쁘게 먹었으면 여러 명 멘탈 나갔을 겁니다. 차라리 이건 아닌것 같아. 라고 평서문으로 혼내세요. 자꾸 저렇게 물어보는 식으로 갈구면 시간만 길어지고 상처는 깊어집니다. 19. 도전장잘 정리하진 못했는데 일단 하는데까진 해봤습니다. 피드백 주세요.=  잘 정리해서 가져와야죠.20. 두괄식 통보내일 까지 해서 갖다 줘. 할 수 있지? = 문장의 순서가 바뀐 것 같지 않나요? 커뮤니케이션은 대부분 태도의 문제와 연결되어 있습니다. 
조회수 285

[바로고 x 더빅스터디] 바로고 인사 담당자가 직접 전하는 면접 꿀팁

barogo바로고취업을 준비하는 분들 사이에꿀팁 가득한 유용한 정보를 제공하는더빅스터디바로고 x 더빅스터디더빅스터디와 바로고의 인터뷰가 진행되었습니다.바로고의 인사담당자 강혁민님께서성심성의껏 대답해주신 인터뷰지금 시작합니다.▼▼▼Q1. 회사 소개 부탁드려요.'세상 모든 사업자와 고객을 이륜차로 연결한다.'는 미션을 가진 바로고는IT  물류 서비스를 운영하고 있는 스타트업 입니다.바로고는 유연한 근무 조건과 투명한 관계 속에서이륜 물류 시장의 선도적인 역할을 수행하고 있습니다.배달 음식 주문앱 시장이 크다 보니바로고 앱에서도 주문할 수 있다고 생각하시는 분들이 많은데요,저희는 주문 중개는 하지 않고배달대행 사업만을 전문으로 하고 있어요.프랜차이즈 본사 혹은 소규모 가맹점이 배달 직원을 직접 뽑아서 관리하는 대신바로고와 계약을 맺어서 바로고의 라이더들이 배달을 해주는 방식의 서비스 인것이죠.Q2. 직군 및 담당업무는?바로고에는 크게 전략기획본부, 물류사업본부, 경영지원본부, O2O 연구소가 있어요.전략기획본부는 크게 전략그룹과 크리에이티브그룹이 있고,전략그룹 안에는 신사업기획팀, 무브먼트팀이 있습니다.크리에이티브 그룹에는 마케팅팀, 커뮤니케이션팀, 크리에이티브랩이 있습니다.바로고의 마케팅, 디자인, 홍보 전략 등을 세우는 일들을 전담합니다.물류사업본부에는 물류전략팀, 직영허브 사업팀, 법인영업팀, 플랫폼운영팀, 인프라혁신팀 등이 있습니다.경영지원본부는 크게 재무그룹과 혁신지원그룹이 있고, 재무그룹 소속으로 재무팀이 있고, 혁신지원그룹 안에는 인사팀, 총무팀이 있습니다.마지막으로 O2O 연구소는 바로고의 배송 플랫폼을 개발하고더욱 효율적인 프로세스를 개발하기 위해 끊임없이 연구하는 팀입니다.Q3. 바로고 서비스의 강점은?전국적인 배송망을 가지고 있다는 게 가장 큰 강점이라고 생각합니다.경쟁 업체들은 주로 서울,특히 강남권에 국한해서 서비스를 하고 있는데요.바로고는 전국에 300개 이상의 허브 지역이 있고3만여 명이 넘는 라이더분들과 1만여 개 이상의 제휴사와 함께하고 있어요.Q4. 바로고의 기업문화는?직원들이 평균 연령이 33.3세 정도 되는데요.젊은 분들이 많다 보니 불필요한 제도나 형식을 강요하지 않고최소한의 룰을 지키면서 자유롭게 일하는 분위기에요.또, 바로고는 직원들 간 원활한 소통을 위해 노력해요.대표적으로 스파클링 데이, 비타민 데이가 있는데요.이날은 직원들끼리 간단한 다과를 즐기면서 자유롭게 이야기를 나눠요.Q5. 소개하고 싶은 복지제도한 달에 한 번 3시에 퇴근하는 조기 퇴근 제도,월 5만원 상당의 도서 지원비 등의 복지제도가 있어요.또, 패밀리 수당이라고 해서 자녀가 있는 직원에게는최대 2명까지 인당 5만 원씩 지급하고 있습니다.Q6. 회사의 장단점을 솔직히 말씀해주신다면?우선, 바로고 사옥이 있다는 게 큰 장점이라고 생각합니다사내에 휴게 공간 및 카페테리아, 샤워실 등이 갖춰져 있기 때문에보다 쾌적한 환경에서 근무할 수 있어요.또, 승진제도가 파격적이라는 점도 장점이에요.반면, 제도와 체계가 아직까지 확실히 잡혀 있지 않다는 게 단점이라고 할 수 있어요.이를 보완하기 위해 회의를 많이 함으로써 리스크를 줄이려고 노력하고 있어요.Q7. 채용 프로세스는?채용공고를 올리거나 내부 추천을 받는 방식으로 직원을 뽑아요.공고를 통한 채용의 경우서류 검토 -> 실무진 면접 -> 임원면접 순으로 진행해요.실무진 면접 같은 경우는 해당 팀의 팀장과 인사담당자가 들어가고,임원 면접은 필요한 경우에 진행하며인성 위주로 평가합니다Q8. 면접에서 꼭 하는 질문바로고에 지원하는 이유와 입사 후 포부가 무엇인지 꼭 물어봐요.경력직의 경우에는 이직 사유가 무엇인지도 추가로 질문해요.또, 바로고라는 회사를 잘 이해하고 있는지를 판단하기 위해주문중개와 배달대행의 차이를 알고 있는지 물어봅니다.Q9. 바로고 합격 팁!바로고는 스펙이나 경력보다는바로고를 얼마나 오고 싶어 하는지,바로고에 대해 얼마나 잘 알고  있는지를 더 중요하게 생각해요.즉, 열정적인 마인드가 가장 중요하죠.그렇기 때문에 회사에 대해 충분히 공부하고 오시면면접관에게 좋은 인상을 심어줄 수 있을 거예요.한 가지 더 말씀드리면,면접을 볼 때 지원자에게 바로고에 대해 질문할 수 있는 시간을 주는데요.궁금한 게 없다고 하는 지원자가 있는 반면적극적으로 물어보는 지원자가 있어요.면접관은 당연히 후자에게 눈길이 가요.여러분이 만약 바로고 면접을 보게 된다면이 시간을 그냥 날리지 마시고공부하면서 궁금했던 것들을 적극적으로 물어보세요.다음 인터뷰는바로고 법인영업팀 신입사원과 진행합니다.많이 기대해주세요^_^[바로고 공식 홈페이지]
조회수 1162

애플리케이션 개발부터 배포까지, AWS CodeStar

OverviewAWS CodeStar를 이용하면 애플리케이션의 개발-빌드-배포까지 빠르게 진행할 수 있습니다. CodeStar는 몇 가지 장점을 가지고 있는데요. 오늘은 간단한 Python App Service Tutorial을 통해 CodeStar를 사용하는 방법을 알아보겠습니다. CodeStar의 장점통합된 UI로 한 번에 여러 활동 관리 가능Continuous Delivery 도구 체인을 구성해 신속한 코드 배포 가능소유자, 기여자 및 최종 사용자 추가로 안전한 협업 가능Dashboard를 사용해 전체 개발 프로세스의 진행 상황 추적 가능CodeStar 사용하기1-1. 처음 CodeStar를 실행하면 나오는 화면입니다. ‘Start a Project’를 누르면 프로젝트 템플릿을 선택할 수 있습니다. 1-2. 이것은 아직 지원되지 않는 지역(Region)에서 노출되는 화면입니다. 2-1. ‘Start a Project’를 클릭하면 프로젝트 템플릿을 선택할 수 있습니다. 2-2. Python과 AWS Lambda를 이용해 Web service를 구현해보겠습니다. 3. Project Name을 지정하고 repository를 선택합니다. 여기서는 AWS CodeCommit으로 선택하여 진행해보겠습니다. CodeCommit의 경우 Repository name을 따로 지정할 수도 있습니다. Repository name까지 지정했다면 Next를 클릭합니다. 4. 아래의 화면은 프로젝트의 흐름입니다. CodeCommit에 소스가 저장되고 AWS CodeBuild를 통해서 Build와 Test가 진행됩니다. 그리고 AWS CloudFormation을 통해서 Deploy가 진행되며 Monitoring은 Amazon Cloud Watch를 통해 진행합니다. CodeStar의 경우 IAM 사용자에 AWSCodeStarFullAccess 관리형 정책을 적용합니다.1) 5. Create Project를 클릭하면 프로젝트가 생성되고, CodeStar 유저 설정을 할 수 있습니다. 6-1. 이제 editor를 선택해봅시다. Command line tools, Eclipse, Visual Studio 등을 고를 수 있습니다. 툴은 언제든지 바꿀 수 있으니 여기서는 Eclipse를 이용하여 프로젝트를 진행하겠습니다. 6-2. See Instructions를 클릭하면 Eclipse를 다운로드 받아 설정하는 방법을 볼 수 있습니다. 6-3. 이제 Eclipse를 설치하고 AWS Toolkit for Eclipse를 설치해보겠습니다. Eclipse의 종류는 Eclipse IDE for java EE Developers 에디션을 설치하겠습니다. 다른 버전은 AWS Toolkit 설치할 때 의존성 문제가 발생할 수 있습니다. 7. Eclipse를 설치하고 Eclipse Marketplace에서 AWS Toolkit for Eclipse 2.0를 설치합니다. 8-1. import를 클릭하고 8-2. AWS -> AWS CodeStar Project를 선택합니다. 8-3. 지역(Region)을 선택하면 해당 지역의 CodeStar 프로젝트를 import 할 수 있습니다. 이 때 CodeCommit의 HTTPS Git credentials를 입력해야 합니다. 9. IAM -> Users -> 사용 계정을 선택해 HTTPS Git credentials for AWS CodeCommit에 가면 User Name과 Password를 Generate 할 수 있습니다. (아래 이미지에 민감한 정보는 삭제했습니다.) 10. CodeStar에서 Project를 Eclipse에 import한 모습입니다. buildspec.yml, index.py, README.md, template.yml이 clone 된 것을 확인할 수 있습니다. 11. 브라우저의 Eclipse 설치 설명 화면에서 back을 클릭해 에디터 선택 화면으로 돌아갑니다. 12. 도쿄 지역에 아직 출시되지 않은 Cloud9은 선택을 마치면 자동으로 셋업이 완료됩니다. 그러나 Eclipse는 Skip을 클릭해야 CodeStar Dashboard로 이동할 수 있습니다. 13. CodeStar Dashboard에 진입하였습니다. IDE는 이미 설정이 끝났으므로 I have already done this를 선택합니다. 화면 하단에 파란색 직육면체가 계속 그려지면 deploy가 완료된 상태가 아니므로 조금 기다렸다가 refresh를 해줍니다. 14-1. deploy가 완료되면 위와 같이 Team wiki tile, Application endpoints, Commit history, Continuous deployment, Application activity등이 나타납니다. 14-2. JIRA를 연동해서 사용할 수도 있는데, 그 내용은 다음에 다루겠습니다. ???? 15. 우선 첫 deploy가 완료된 것을 자축하며 Application endpoints를 클릭합니다. 개발자들에게 굉장히 익숙한 “Hello World”가 나옵니다! 간편하게 소스를 deploy 하여 AWS Api-Gateway와 연결했습니다. 이제 각 파일의 용도에 대한 설명과 새로운 method를 추가하는 작업을 진행해보겠습니다. 16. 이미지처럼 sample.py 파일을 추가하고 아래 코드를 추가합니다. import json import datetime def handler(event, context):     data = {         'output': 'Sample! pathParameters test = ' + event["pathParameters"]["test"]     }     return {'statusCode': 200,             'body': json.dumps(data),             'headers': {'Content-Type': 'application/json'}} 17. 그리고 template.yml에는 아래 내용을 추가합니다. — template.yml —  Sample:     Type: AWS::Serverless::Function     Properties:       Handler: sample.handler       Runtime: python3.6       Role:         Fn::ImportValue:           !Join ['-', [!Ref 'ProjectId', !Ref 'AWS::Region', 'LambdaTrustRole']]       Events:         GetEvent:           Type: Api           Properties:             Path: /sample/{test}             Method: get — 18-1. 이제 수정한 내용을 CodeStar에 반영해보겠습니다. 프로젝트에서 오른쪽 클릭을 해 Team -> Commit을 선택하고 Commit합니다. 18-2. 수정한 파일을 Commit하고 Push합니다. 18-3. Dashboard를 보면 Commit history에 Commit 내용이 반영되었습니다. 19-1. Dashboard에 Continuous deployment를 보면 Source -> Build -> Deploy를 통해서 수정한 내용이 반영되는 것을 실시간으로 확인할 수 있습니다. 이 작업은 생각보다 시간이 많이 소요됩니다. Deploy까지 Succeeded로 완료가 되면 새로 만들어진 URL을 클릭합니다. 19-2. 아래와 같이 pathParameters가 정상적으로 출력되는 것을 확인할 수 있습니다. 20. 이어서 새로 만든 API에 단위테스트를 추가해보겠습니다. sample_test.py라는 파일을 만들고 아래 코드를 추가합니다. — sample_test.py — from sample import handler   def test_sample_handler():         event = {         'pathParameters': {             'test': 'testMessage'         }     }         context = {}         expected = {         'body' : '{"output": "Sample! pathParameters test = testMessage"}'         ,'headers': {             'Content-Type': 'application/json'         },         'statusCode': 200     }         assert handler(event, context) == expected  — 21. 그리고 buildspec.yml 파일을 아래와 같이 수정합니다. — buildspec.yml —  version: 0.2 phases:    install:     commands:       - pip install pytest    pre_build:     commands:       - pytest    build:     commands:       - pip install --upgrade awscli       - aws cloudformation package --template template.yml --s3-bucket $S3_BUCKET --output-template template-export.yml artifacts:   type: zip   files:     - template-export.yml  — 22-1. Commit을 진행합니다. 그리고 다시 Source -> Build -> Deploy 를 거쳐서 Succeeded가 되면 Build 부분의 CodeBuild로 들어가서 Build 결과를 확인합니다. 22-2. 맨 마지막에 Build 결과를 클릭하면 Build 상세 내역을 확인하실 수 있습니다. 22-3. Build logs부분을 보면 sample_test.py를 이용한 단위테스트가 정상적으로 진행된 것을 확인할 수 있습니다. Conclusion지금까지 CodeStar를 이용한 간단한 튜토리얼을 진행했습니다. 다음 화에서는 다양한 방법으로 CodeStar를 활용할 수 있는 방법을 소개하겠습니다. CodeStar에 대한 자세한 내용은 여기를 참조하세요. 참고 1) AWS CodeStar 설정글윤석호 이사 | 브랜디 [email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #CTO
조회수 1274

트위터의 이메일 디자인 원칙 3가지

지난 주 트위터의 공식 블로그에 “Designing with constraint: Twitter’s approach to email”이란 글이 올라왔습니다. 글에서 언급하고 있듯이 트위터라고 하면 왠지 이메일과는 거리가 멀 것 같은 느낌이지만, 트위터에서도 이메일은 큰 역할을 하고 있습니다.그렇다면 트위터는 어떤 방식으로 이메일을 디자인 하고 있을까요? 트위터의 이메일 디자인 원칙 3가지를 소개합니다.가볍고 간결하게 (Keep it light, keep it concise)이메일을 확인하는 상황은 사람마다 다릅니다. 어떤 사람은 버스에서 모바일로 확인하기도 하고, 어떤 사람은 사무실에 앉아 확인하기도 합니다.이 모두를 만족시키려면, 이메일의 문구와 콘텐츠를 가능한 짧고, 유용하고 가치있는 것으로 만들어야 합니다. 타이포그래피, 색상, 문단 구조 등을 적절하게 사용하면 중요한 내용을 더 효과적으로 전달할 수 있습니다.문장 표현도 중요합니다. 쉽게 이해되려면 문장 표현이 간단명료해야 합니다. 전문적인 카피라이터의 도움이 있다면 훨씬 쉽겠죠.트위터의 즐겨찾기 알림 메일의 BEFORE(왼쪽)와 AFTER(오른쪽): 문단 구조를 개선하고, 문구를 더 짧게 바꾸고 CTA 버튼을 더 명확하게 바꿨습니다.많은 사람들이 이메일 전체를 읽지 않고 제목, 헤드라인, CTA 버튼만 확인다는 것을 확인한 트위터는 제목, 헤드라인, CTA 버튼 외의 다른 요소를 최소화 했습니다. 트위터가 추구하는 효과적인 이메일 디자인은 이렇게 필요한 요소를 강조하고, 필요하지 않은 요소를 제거하는 것입니다.다양한 사용 환경에 대응하기 (Meet a person where they)수많은 디바이스, 플랫픔, 애플리케이션 환경에 대응해야 합니다. 트위터가 사용자에게 보내는 모든 이메일은, 모든 환경에서 동일한 메시지를 전달할 수 있어야 하기 때문입니다.친구들의 소식을 모아서 보여주는 트위터의 주간 메일은 다양한 디바이스 환경에 대응하도록 디자인되어있습니다.행동 유도하기 (Help a person do something)트위터의 마지막 디자인 원칙은, 사용자를 트위터 서비스로 유입시키기 위해 어떤 의미있는 행동을 유도하는 것입니다.이메일은, 다른 알림 메시지와 마찬가지로, 사용자가 관심있어 할 만한 정보를 빠르게 전달하고, 그와 관련된 행동을 쉽게 할 수 있게 해야 합니다.행동을 유도할 수 없는 메시지는, 보내봤자 의미가 없습니다. 이메일도 마찬가지입니다.원본: Designing with constraint: Twitter’s approach to email#슬로워크 #마케팅 #마케터 #마케팅툴 #인사이트 #꿀팁

기업문화 엿볼 때, 더팀스

로그인

/