스토리 홈

인터뷰

피드

뉴스

조회수 1350

나누고 싶은 이야기들...

지난 3년 7개월 동안 스타트업을 하면서 정말 많은 경험을 했고 좋은 분들을 많이 만났습니다.더 시간이 지나서 머리속의 기억이 잊혀지기 전에 그리고 지나온 시간들을 반성하고 되짚어보는 시간을 가지는 방법을 찾던 중 글로 남겨보자라는 생각을 했습니다.-노점상부터 시작된 창업-3번의 투자유치-실리콘밸리 엑셀레이터 참여-퇴사율 0% 특이한 조직-서비스 폐업-피벗팅-컨텐츠 서비스 시작-재투자유치와 팁스프로그램 선정-새로운 서비스의 매출 발생 시작다양하고 경험을 했고, 하면서 느꼈던 점 위주로 적어 볼까 합니다.  이 이야기들은 흔히 볼 수 있는 성공을 거둔 스타트업의 이야기가 아닙니다. 삽질에 삽질을 거듭하며 성공을 위해 달려가고 있는 현재 진행형의 어느 작은 스타트업의 이야기 입니다.1. 독한 녀석들 (실행)2. 문득 찾아온 첫사랑(첫번째 투자사 본엔젤스)3.회사가 전쟁터라고? 밖은 지옥이다.(창업을 말리는 이유)4.내가 창업을 선택한 3가지 진짜 이유(동기)5.학연 지연,그들만의 리그 (인맥)6. 우리가 세월호 현장에 간 이유 (실천)7. 구글 VS 노점상 (결정)8. 스타트업 초기멤버의 중요성 ( Co-founder )9. 내 통장과 회사 통장의 차이 ( 스타트업에게 투자금의 의미 )10. 스타트업 MVP 사례 ( 홍대의 초록색 오빠들 )11. 신내림 (두번째 투자사 IDG)12. 영어 유치원 보내자. (첫번째 팀빌딩)13.미친놈,이상한놈,특이한놈(두번째 팀빌딩)14.나가서 뭐라도 배워오자.(전시회,컨퍼런스,모임)15.까칠한 미국인(세번째 투자사 500Startups)16.거리의 스타트업 실리콘 밸리를 가다.(해외진출 준비하기)17.Tenderloin (생활하기)18.Tell me your number! (데이터,분석)19.I'm founder & CEO of Plugger. (피칭)20.좋은 회사? 나쁜 회사? ( 경력 )21.내깜댕이의 자위기구 (서비스 네이밍)22.유니콘들 (외부동료)23.반쯤 채워진 물컵(미국에서 얻은 것들, 잃은 것들)24.그래서 연봉이 얼만데? (처우,복지)25.어둠의 자식들 ( 멘탈 추스리기 )26.편집증 (양보하지 않는 것들)27.낮새와 밤쥐 (평판)28.사실과 진실의 차이 (의사소통)29.유료사용자 10만명 허와 실 (성장성)30.잘되면 팀원 탓 안되면 대표탓(대표의 역할)31.그만 두세요. 할만큼 했어요.(폐업권유)32.우리는 망했습니다. (내려놓기)33.퇴사율 0% 특공대들 (피벗팅의 시작)34.남이 하면 불륜 내가 하면 로맨스 (카피캣)35.엄친아 (벤치마킹)36.빠르게 망하기 ( 런웨이,타임라인 )37.라디오를 누가 들어요? (아이템선정)38.나는 한놈만 팬다.( 목표설정 )39.열심히 하기? 잘하기! ( KPI )40.주크버그가 잡스가.. (멘토,멘티)41.바닥 쳐봤잖아요.(네번째 투자사 엔텔스,넥스트랜스)42.연락처 좀 알려주세요.(좋은 투자사 찾기)43.노가다 (세번째 팀빌딩)44.살려면 뭔들 못해? (정부지원)45.글로벌? (다시 준비하는 해외진출)46.히든 챔피언(숨은 조력자들)47.매출이 깡패다.(회사의 본질)48.마음속으로만...(목표와 비전)49.프로와 아마추어 (성과)50.행복해지거나 현명해지거나 (Next)참고로 공돌이 개발자 출신이라 글재주가 부족한 점 양해의 말씀 드립니다.#스푼 #Spoon #개발자 #개발 #인사이트 #경험공유 #스타트업 #투자유치 #초기창업 #창업 #고민
조회수 3513

포스트맨 200% 활용하기

편집자 주 MAC OS 기준으로 작성했으며, 본문 내용 중 Proxy(또는 프록시)는 영문으로 통일하여 표기함. OverviewPOSTMAN은 API 테스트에 큰 도움을 주는 도구입니다. 강력한데다가 무료입니다. 안 쓸 이유가 없군요. POSTMAN은 사용하는 방법도 쉽습니다. 그래서 이번 글에서는 최근에 나온 POSTMAN native 버전 패킷캡쳐 방법을 공유하겠습니다.native App은 기존 크롬 플러그인 버전보다 깔끔하고 버그도 많이 줄었습니다. 하지만 원래부터 강력했던 postman interceptor가 아직 지원하지 않습니다.1)공식 블로그 답변입니다.이미 interceptor를 사용하고 있어서 native App에 대한 니즈는 없었는데요. 한글 패킷 캡쳐를 시도하고 생각이 완전히 바뀌었습니다. intetceptor로 캡쳐된 패킷테스트 중이던 공지사항 제목이 이상하게 변경됐습니다.Postman Proxy를 써보자!어쩔 수 없이 native App 을 써야겠다고 생각했습니다. 가장 먼저 postman interceptor에 연결할 방법이 필요했는데 위의 공식 블로그 답변처럼 지금은 안 된다고 합니다. 구글링을 했더니 아래와 같은 글이 보였습니다.스마트폰이나, 기타 기기들의 패킷을 캡쳐할 수 있기 때문에 매력적인 방법입니다. 웹을 사용할 땐 브라우저를 Proxy 태우면 결과는 비슷하게 나올 겁니다.native Appnative App은 여기에서 다운로드 받을 수 있습니다. nativeApp을 켜면 오른쪽 위의 메뉴에 interceptor 아이콘은 없고 위성안테나 모양의 아이콘이 있습니다. 이것은 Proxy Server 기능입니다. Proxy Server를 postman native가 구동해주고 사용하는 방식이죠.Proxy 설정 화면이 뜨는 기본 포트는 5555번입니다. 따로 할 건 없고, 캡쳐 위치는 기본 값인 History로 지정합니다. 만약 다른 컬렉션에 내용을 모으고 싶다면 그곳으로 지정하세요. Connect 버튼을 클릭하면Proxy가 구동됩니다.요청 내용을 긁어 모을 때다!Proxy 세팅을 마쳤으니 브라우저를 연결해야겠죠? 일반적인 방법으로는 연결되지 않습니다. 여기선 크롬 확장 프로그램인 Proxy SwitchyOmega의 도움을 받았습니다. 다운로드는 여기를 클릭하세요.이것은 Proxy 스위칭 프로그램입니다. 도메인 단위로 설정이 가능하기 때문에 on 또는 off 따로 하지 않고도 사용이 가능할 겁니다. 플러그인 설치를 마쳤다면 설정을 유도합시다.Server에는 localhost, Port에는 5555를 적어주세요.캡쳐하고 싶은 사이트에 들어가 Direct 옵션을 켭니다.Proxy를 활성시킵니다.브랜디 주요 도메인인 brandi.co.kr을 클릭해 Proxy를 활성시키면 ***.brandi.co.kr 도메인은 Local Proxy를 타고 넘어가는데요. 이제 받기만 하면 됩니다. (빵끗)진짜 긁어 모아보자!캡쳐하려고 했던 사이트에 접속해 요청을 발생시킵니다.내부 테스트 서버postman native App 캡쳐 내용와우! 발생한 요청 내용이 캡쳐되어서 들어오기 시작합니다.속이 뻥!!!속을 썩이던 한글도 깔끔하게 캡쳐되었군요. 이제 행복한 테스트만 남았습니다. 즐거운 시간 되시길 바랍니다.소소하지만 알찬 팁1: 필터 기능proxy 설정도구에서 필터 기능을 사용하면 원하는 것만 캡쳐할 수 있습니다.소소하지만 알찬 팁2: 테스트 기능스마트폰의 native App은 위와 같이 설정하면 테스트할 수 있습니다. 이제 휴대폰 테스트 결과를 PC로 수집할 수 있을 겁니다. 앱 테스트에 대한 상세 설명은 여기를 클릭하세요.소소하지만 알찬 팁3: 안 쓸 때는..proxy를 안 쓸 때는 System Proxy를 클릭해 끄도록 합시다.1) interceptor는 브라우저 요청을 postman에서 패킷을 캡쳐해주는 도구다.참고Capturing HTTP requests글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #Postman
조회수 821

[모바일 앱분석] Step3. CONVERSION (성과 분석)

모바일 앱 분석의 마지막 3단계 Conversion (성과분석) 에 대해 알아보겠습니다.[모바일 앱분석] Step1. MARKETING (마케팅분석)[모바일 앱분석] Step2. EXPERIENCE (사용자경험분석)마케팅 활동으로 아무리 많은 사용자를 확보하고, 좋은 경험을 제공해도 전환 최적화가 되어 있지 않다면, 투자 만큼의 결과(Outcomes)를 얻지 못해 지속적인 앱 운영의 어려움을 느끼게 됩니다. Conversion 단계의 분석 핵심은 사용자의 전환 트렌드를 이해하고, 전환 효율을 떨어뜨리는 문제점을 도출하여 더 많은 전환을 획득할 수 있도록 개선하는 데 있습니다. 앱 비즈니스 마다 목표 값이 다르겠지만, 이번 설명에서는 커머스 앱 기준으로 설명했습니다.# 전환 트렌드 이해먼저 사용자의 주문이 집중되는 시점(시간/요일/계절 등)을 인지하는 게 중요합니다.  주문이 집중된다는 건 그만큼 구매 욕구가 증가하는 시점으로 해석할 수 있기 때문에, 해당 시간을 활용한 이벤트로 높은 성과를 기대하거나 반대로 주문에 영향을 줄 수 있는 앱 업데이트, 서버 점검 등은 해당 시간을 피해서 작업하는 것이 좋습니다.데이터를 볼 때는 매크로 컨버전(거시적 전환) 지표가 중요하지만, 필히 마이크로 컨버전(미시적 전환)도 함께 봐야 합니다.  많은 주문을 얻기 위해선 당연하게도 ‘장바구니담기’, ‘바로구매시도’ 등의 전환이 많이 발생해야 하며, 주문까지의 연결율이 높아야 하기 때문에 이런 상황을 파악할 수 있는 마이크로 컨버젼 지표에 대한 관리가 중요합니다.( 와이즈트래커 > 커머스 > 주문/매출액 리포트 )# 타겟별 선호 상품 파악커머스 업계에서 가장 뜨거운 기술은 바로 개인화(personalization)입니다. 개인화의 목적은 범용적 컨텐츠 제공이 아닌 나만을 위한 컨텐츠를 제공함으로써 구매 확률을 높이고자 함입니다. 이 기술의 근간은 타겟팅이라고 볼 수 있습니다.저에게 원피스, 브라우스를 수백번 보여줘도 구매할 확률은 0%이겠지만, 시계, 운동화 등의 관심 상품을 제시한다면 앞선 상품보다 구매 확률은 크게 증가할 것입니다. 이처럼, 상품 구매 데이터를 성별, 연령대, 직업 등의 사용자 정보를 다차원으로 조합 후 세분화하면 타겟이 선호하는 상품이 무엇인지 알 수 있으며, 이를 바탕으로 상품 구매 의사가 높은 최적의 타겟을 설정하고 마케팅 전략을 수립한다면 매스 마케팅과는 차원이 다른 ROI를 경험할 수 있습니다.( 와이즈트래커 > 커머스 > 상품별 주문/매출에서 다차원 세그먼트 적용 후 리포트 ) # 전환 시나리오 분석사용자가 주문(전화)을 하기 위해 거쳐야 하는 일련의 프로세스를 전환 시나리오라고 합니다. 전환 시나리오는 전환 단계별 통과율/이탈률 데이터 제공으로, 전환을 방해하는 문제 화면을 도출하여 개선의 힌트를 얻을 수 있는 리포트입니다.아래 예시를 보면 사용자가 주문을 하기 위해 1) 상품 상세 > 2) 장바구니 > 3) 주문정보 입력 > 4)주문완료, 총 4단계의 스텝을 밟게 되는데요. ‘상품 상세’에서 ‘장바구니’로의 이탈률(92%)은 이해할 수 있습니다. 상품 조회 자체를 목적으로 온 사용자가 많기 때문입니다. 그러나 ‘주문정보 입력’까지 온 사용자는 구매의사가 매우 높은 사용자로, 81%의 높은 이탈률은 심각한 문제입니다.이를 통해 ‘주문정보 입력’의 통과율을 높이기 위한 폼 양식 리뉴얼, 결제 방식의 개선 등의 최적화 작업을 한다면 전체적인 주문율 향상을 기대할 수 있습니다(와이즈트래커 >  컨텐츠   > 화면이동경로 분석 리포트)앱 분석의 단계별 접근방법에 대해 살펴봤는데요, 모든 앱에는 개선이 필요한 부분이 존재합니다. 데이터는 개선의 방향을 알려주고, 실행(Action)은 성과 향상으로 답할 것입니다.
조회수 3360

어리석은 일잘러의 슬픈 착각 13가지

간만에 일 얘기로 좀 돌아왔어요. 오늘은 일잘러 얘기랍니다. 브런치나 구글, 일분, 카카오채널, 블로그, 팟캐스트, 유튜브...등등 모든 채널에 '일' 에 대한 얘기가 가득해요. 대부분 두 가지 아젠다가 있더군요. 1. 일을 잘하는 방법2. 일을 못하는 이유이겁니다. 모두의 행복한 업무생활을 위한 좋은 콘텐츠들이지만, 이런 테마가 넘쳐나고 이래저래 공유되면서 모든 사람들이 일을 잘해야 하고, 일을 못하는 건 일종의 죄...? 처럼 여겨지는 부분도 생기는 듯 해요. 일정부분 동의해요. 일을 못하는 건 어떤 측면에서 민폐가 될 수 있겠죠. 개냉정한 말이지만, 결국 당신의 일못함은 다른 누군가의 피해와 희생을 요구하거든요. 그러니 업무적으로 여러가지 열폭 컨텐츠가 등장하는 것이 이해는 갑니다. 하지만 좀 불편한 부분이 있었어요. 소위 자칭 일잘러들의 미묘한 깔아봄이 있더라구요? 마치 일 잘하는 사람이 조금 더 나은 우성종자같은 행세를 하고 다닌다는 거죠. 그리고 자꾸 일손이 느리거나 실수가 잦은 누군가를 가르치려 들거나(기분나쁘게) 또는 깝깝하다는 듯한 제스쳐를 취하는 모습을 자주 보곤 했어요. 문득 그런 생각이 들죠. 뭐지 저 자의식은?... 어디서 일잘함 인증이라도 받아온 건가..싶은.물론 그럴 수 있죠. 진짜 일처리가 AI마냥 정확한 종족들이 있어요. 그럼 그냥 본인에게 좋은 일이죠. 빨리 끝내고 빨리 퇴근하고 쉴 수 있으니 부모님께 감사하면 될 일입니다. 그래요 이분들은 인정합니다.하지만 종종.. 아무리 봐도 일을 잘하지 않는데... 본인이 일을 잘한다고 착각하는 분들이 있더라구요.  오늘은 자칭 일잘러들의 슬픈 착각을 좀 까보려고 합니다. 1. 멋진 단어 VS 쉬운 단어일잘러는 중학생들도 블록체인을 이해할 수 있게 설명하는 분들입니다. 자칭 전문가라며 말도 안되는 영어와 약어, 전문용어를 마구 섞어서 말씀하시는 분들이 있는데 대충 느낌은 알겠습니다. 의사들의 처방전같은 전문성을 어필하고 싶었던 모양입니다. 하지만 그것은 파스타 속의 브로콜리마냥 굉장히 거슬리는 거에요. 빼고 먹고싶은데 자꾸 달팽이관에 걸려서 불편하달까요. (전 브로콜리를 싫어해요.)2. 말이 많은 것 VS 말을 잘하는 것LA들어간다 귀벌려본인의 주장을 설명하기 위해 수백마디의 근거와 예시가 필요하다면 이미 그 주장은 힘이 없는 거예요. 가끔 목소리 크고 또박또박한 발성으로 몇 시간 내내 트렌드와 동향, 방대한 자료와 근거를 들어 주절주절 멋진 일대일 강의를 하시는 분들이 있는데... 그건 '말을 잘 하는 것 처럼' 보여요. 하지만 귀에 남는 건 아무것도 없다구요. 계졀밥상에서 2시간 내내 계속 다른 메뉴먹는 느낌이야. 배는 부른데 뭘 먹었는지 모르겠어. 짧고 간결하지만 쏙쏙 이해되는 어휘로 명확한 근거 하나로 부연하는 게 능력이예욤.3. 냉철한 것 VS 싸가지없는 거일을 할 때 냉정한 것과 싸가지가 없는 건 다릅니다. 일을 하라고 했지 인격을 건들라고는 안했거든요. 가끔 '결과를 잘 내기 위해서' 냉정하고 사정 봐주지 않는 오더를 내리시는 분들이 있는데, 진짜 일을 잘 하시는 분들은 사람의 소중함을 먼저 캐치하시지 않을까요? 도깨비방망이마냥 사람을 갈아넣으면 어떤 일이든 할 수 있습니다. '다음'이 없을 뿐.4. 빨리 하는 것 VS 대충하는 것이렇게 빨리해도 잘해야지.빨리하라고 했지 대충하라곤 안했습니다. 쟈긴 막 일잘한다고 후다다닥 끝내놓고 커피 한 잔 마신다고 어디 나가있고 그러는데..막상 인수인계 받아서 작업해보면...빈 구석이 너무 많아서 다시 피드백 정리하거나 요청하고, 아님 내가 그냥 만드느라 더 느려져요. 성격급하고 빠르게 일처리 해놓고 딩가딩가하는 건 일을 잘하는 게 아닌 것 같아요. 빠르고 정확하게 해야죠.5. 완벽주의 VS 그냥 일손이 느린 타입'어우 저는 완벽주의 라서요!.. 꼼꼼하게 하나하나 보는 타입이예요.'꼼꼼하게 보고 완벽하게 하는 거 다 좋은데, 마감시간은 맞췄으면 합니다. 그냥 일손이 느린 거에 대한 묘한 변명같아요. 6. 프로다움 VS 그냥 드러운 성격거들먹거리는 말투로 '나랑 일하기 힘들 거야.' 이라고 자기어필 하시는 사수가 있더라구요. 뭐 어쩌라는 걸까요? 싸우자는 걸까요..오지말라는 걸까요. 그게 소위 프로다움이라고 여기시는 분들이 종종 있더라구요. 밑에 부사수를 조져서 일을 '가르쳐줄거다' 그러니 너가 내 속도에 따라와라.. 하는 건데. 여긴 군대가 아니에요. 그건 프로다운 게 아니라, 사람을 다루지 못하는 미숙함이고 그냥 성격이 더러운 게 아닐까 싶습니다.7. 빠른 의사 결정 VS 독선과 고집의사결정이란 건 일단 듣고 각 의견의 장단점을 구분해서 취사선택 또는 합의점을 도출하는 거에요. 팀원들이 20가지 아이디어를 내고 10가지 피드백을 냈는데 결국 피드백은 쌩까고 본인이 낸 아이디어를 선택했다면 그건 의사결정일까요? 종종 이런 독단을 '난 쿨하게 의사결정하는 편이야! 길게 끌지 않아.' 라고 생각하는 분들이 있는데 그거 아닙니다. 그냥 고집쟁이세요.8. 자기반성 VS 정신승리페북에다가 자꾸 자기반성 글 쓰시는 분들 있어요. 회고 비슷하게. 알겠는데, 자기반성은 개선점이 행동으로 드러나야 의미가 있는 겁니다. 페북에다가 의지만 불태우는 건 그냥 정신승리에요. 뭔가 문제가 있었고 갈등이 있었다면 재빨리 해결하고 당사자에게 사과를 구하고 행동으로 보여주면 될 일입니다. 9. 일잘러 VS 뒷담쟁이일을 잘 한다는 건 벼슬이 아닙니다. 누군가를 깔 일도 아니죠. 항상 내가 일 잘하는 것처럼 느껴질 때는 그런 생각이 든단 것 자체가 '지금 내가 좆밥이구나' 라는 걸 잘 기억해야 합니다.10. 이론쟁이 VS 재수탱이일을 어디 교과서로 배웠는지 자꾸 연습문제 뒷장에 '생각해봅시다.' 같은 질문들만 던지고는 팔짱을 끼는 분들이 있어요. 이런 사람들이 잘 팔아먹는 단어가 '기획'과 '전략' 인데.... 기획은 책상앞에서 펜대굴리면서 하는 게 아니더라구요. 이론만으로 하는 것도 아니고. 아이디어만(그것도 시덥잖은) 내놓고 자꾸 데카르트같은 딴지만 거는 분이 있다면 조용히 귓속에 집에 가라고 속삭여주세요. 지금 발로 뛰면서 현장서베이 다니고 레퍼런스 찾기도 바쁘니까.11. 인사이트 VS 헛소리인사이트..라는 단어가 21세기 멋진 단어 BEST5에 등극한 모양인데 인사이트라는 건 심도를 꿰뚫는 깊이와 다양한 근거를 바탕으로 내는 가설이자 관점입니다. 페북에서 공유해온 글3,4개 읽고 떠들고 다니는 '내 생각' 정도가 아니라고 생각해요. 어디서 복제해온 정보들을 내 것이라고 착각하면 안돼요. 12. 유도리 VS 가라일을 유연하고 상황에 맞춰 해결하는 능력은 매우 중요합니다. 우린 이걸 유연성 내지는 유도리라고 하죠. 근데 이게 모든 일을 그냥 대충 그때 그때 임시방편으로 처리하란 얘기가 아니에요. 가끔 말예요. 직급이 올라가고 권한이 생길 수록 이 유도리를 시도때도 없이 써먹는 분들이 있더라구요. '그냥 대충 해, 내가 잘 말할께!''아 그분 내가 아는 분이야, 그냥 그렇게 한다고 해''이번거 그냥 사, 내가 이사님한테 말할께. 술 사드리면 풀려.'직원입장에선 개쿨하고 능력쩌는 상사같아 보일 수도 있겠지만..결국 이런 식의 일처리는 어느 지점에선 터지게 되어있거든요. 가라와 유도리는 좀 다릅니다. 정상적인 절차 내에서도 효율적인 결론을 만들 수 있어야 레알 일잘러죠. 13. 용기있는 1인 VS 딴지쟁이모두가 YES라고 말할 때 NO라고 말하는 소신있는 일잘러분들이 있어요. 좋아요. 그런 자세. 모두에게 좋은 결과를 위해 전투적으로 리스트를 도출하고 어필하는 거 좋습니다. 뭐 한 편으론 '불평만 말하지 말고, 해결책을 가져와라' 라는 말도 있던데, 솔직히 해결책 안가져와도 됩니다. 리스크를 발견한 것만도 대단한 거에요. 문제는 그 리스크가 진짜 '유의미'한 리스크인가 하는거죠. 괜히 색이 맘에 안들고, 디자인이 어떻고, 뭔가 그냥 느낌적으로 별로인 것 같고, 사람들이 그냥 안좋아할 것 같고, 자기 친구들3명한테 물어봤는데 이거 아니라더라....이런식의 피드백은 졸라 그냥 딴지일 뿐입니다. 남의 말 잘라먹고 자기 주장 좋아하고 불평을 똑부러진 말투로 늘어놓는 것 뿐이죠.  일을 잘 하는 건 기획안을 몇 분안에 만들 수 있느냐..로 평가되는 게 아니라고 생각해요. 게다가 또박또박과 똑부러짐, 전문적이고, 말빠르고, 목소리크고, 성격급하고, 까칠하고, 고집있는 건 일잘러와는 사실 별 상관이 없어요. 그건 그냥 성격이나 성향문제일 뿐이죠. 회사와 동료 앞에는 모두 co- 접두어가 들어가잖아요. 일의 본질은 '함께' 하는 겁니다. 지가 못하는 게 있으면 도움을 빠르게 요청하고, 내가 잘 하는 게 있으면 부족한 분과 콜라보해서 빨리 끝내고. 일을 '돌아가게' 만드는 사람이 진짜 일잘러가 아닐까욤..
조회수 2908

GUI가이드라인 정의와 목적

S/W 개발자가 디자인대로 화면을 구현할 때, 어떻게 디자인 요소 위치를 잡아야 하는지 정확한 정보가 필요합니다. 이런 정보는 GUI 디자이너가 포토샵과 같은 디자인 툴을 사용하여 개발자가 사용 가능한 형태로 사이즈 정보와 리소스를 만들어 전달하는 작업을 GUI 가이드라인 제작 작업이라 합니다.GUI 가이드 문서 상에는 화면상에 표현되는 모든 GUI 요소들의 정보가 표시가 됩니다. 화면상의 위치 X/Y 좌표값, 디자인 요소의 폭/높이 사이즈 정보, 이미지 파일 리소스명, 폰트 타입, 폰트 크기 등 다양한 그래픽 요소의 정보를 정확하게 수치화 하여 기재한 것입니다.가이드 문서의 양식은 딱 정해진 틀은 없지만, 소위 대기업의 경우 표준 템플릿을 이용합니다. 단말 하나에 탑재되는 앱 별로 수십 벌의 문서를 제작하여 관리해 왔습니다. 현재 과도기적인 단계라 스케치(.sketch) 파일과 가이드라인 문서를 함께 운영하는 곳도 있을 정도입니다.기존에 GUI 가이드 문서 제작을 위해서는 아래와 같은 일련의 순서로 작업을 하였습니다.디자인 시안 작업 > 디자인 시안 확정 > 개발 가능성 리뷰 > 최종 수정 >GUI 가이드라인 문서 제작 & 이미지 파일 리소스 작업이 중에서 가이드 문서 제작 과정을 초점에 두고 살펴보면, GUI 디자이너가 직접 이미지를 자르고 위치와 크기 정보를 확인하여, 파워포인트 문서로 정보를 입력하는 일련에 단순 노가다를 반복적으로 진행하게 됩니다.대부분의 에이전시 신입 디자이너들이 중국집 요리사 탱크트리와 유사하게 최소 2년 정도 GUI 가이드라인 작업을 하고 난 뒤에 시안 디자인 작업을 참여할 수 있는 구조였습니다. 크리에이티브를 위해 디자인 작업에 시간을 일주일 중 3일을 쓰고, 4일은 가이드를 쳐야 할 정도의 노력과 시간이 드는 노동 집약적 작업이었습니다.이렇듯 GUI 가이드라인 문서 제작은 모든 디자인 요소 정보들을 일일이 확인한 후, 파워포인트로 옮겨 적어야 하는 야근의 헬게이트를 열어주는 대표적인 업무였습니다.디자인 완료 후 개발자에게 “디자인을 이렇게 구현해 주세요.” 라고 말하면 얼마나 쉽나요? 근래에는 야근의 대부분을 차지하는 이러한 업무들로부터 스케치 툴이 많은 디자이너를 구해준 셈입니다.업무의 프로세스상 디자이너가 가이드라인 문서와 이미지 리소스 파일들을 넘겨줘야 개발자들이 개발진행을 할 수 있기에 디자이너들은 타이트한 데드라인에 쫓기듯 업무할 수 밖에 없었습니다.이러다 보니, GUI 가이드라인 문서 제작 중 휴먼에러(크기 정보 오타, 이미지 파일 누락 등)로 개발자가 작업하던 도중 디자이너에게 가이드라인 문서 업데이트 요청을 해오는 경우가 매우 빈번했습니다. 또한, 대규모 프로젝트 일수록 가이드라인 문서, 이미지 리소스 파일, PSD 디자인 파일 등 관리해야 할 대상이 많아서 개발자와 디자이너 사이의 커뮤니케이션 빈도수도 잦아지고 많은 비용이 필요했습니다.비단 3년 전만해도 GUI 디자인을 개발자가 구현하기 위해 필요한 정보를 수천 페이지나 되는 파워포인트 문서로 전달했지만, 요즘은 스케치를 활용한 제플린이나 심플리 등과 같은 가이드 정보를 제공해주는 여러 서비스를 이용하여 가이드 문서 제작은 거의 하지 않고 있습니다. 조만간 가이드 문서가 완전히 사라지는 날이 오지 않을까 싶습니다.그 끝에 크래커나인이 일조하는 날이 오기를 바라며 글을 마칩니다.#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업
조회수 2122

당신이 고민해야 할 성능 분석 요소

IT 서비스는 더욱 복잡해지고 어플리케이션과 인프라의 경계도 클라우드 환경과 함께 허물어지고 있습니다. 많은 기업들이 가상화를 넘어 컨테이너로 가고 있으며 서버리스도 더이상 낮설지 않습니다. 인프라의 변화와 함께 아키텍처의 변화도 다양하게 만들어져 가고 있습니다. 복잡성이 아무리 높아져도 우리는 서비스의 성능을 보장해야 합니다. 서비스의 성능을 보장하기 위해 우리가 체크해야 할 중요 요소들을 알아보려고 합니다. 1. 인프라스트럭처와 클라우드서비스의 성능은 코드 밖에서도 만들어집니다. 그중에서도 인프라스트럭처는 매우 중요한 요소입니다. 국내에서 인프라스트럭쳐 분야는 클라우드로 전환하는 과도기적인 상황에 있습니다. SMB 시장에서 클라우드는 익숙한 환경이지만 국내 엔터프라이즈 기업의 클라우드 도입 비율은 20%가 되지 않습니다. 특히 클라우드를 도입하려는 엔터프라이즈 기업들은 데이터 센터, 퍼블릭 클라우드, 프라이빗 클라우드를 모두 사용하는 상황으로 넘어가면서 클라우드에 대한 모니터링 체계를 구성하는데 많은 어려움을 겪고 있습니다. 특히 기존의 자원 사용량을 설계하고 운영하던 방식에서 스케일의 변화를 통해 서비스의 성능을 실시간으로 조절하는 클라우드 서비스 운영 방법은 조직의 구조 변화를 동반하기 때문에 더욱 어려운 작업이기도 합니다. 이렇듯 클라우드의 전환은 최근 웹 서비스의 성능에 많은 영향을 미치고 있으며 데이터독이나 뉴렐릭 그리고 와탭 같은 성능 분석 서비스들은 클라우드 기반의 인프라 모니터링 기능들을 강화하고 있습니다. 2. 데이터베이스어플리케이션 성능 이슈의 80% 이상이 데이터베이스 레이어에서 발생합니다. 대부분의 엔터프라이즈 기업들은 자사의 어플리케이션을 성능 분석을 위해 DBA 포지션을 마련하거나 필요에 의해 컨설팅을 받고 있지만 아쉽게도 스타트업은 DBA포지션을 마련하는 경우가 거의 없습니다. 웹 서비스의 규모가 커지기 시작하면 데이터베이스로 인한 지연 장애가 매우 심각해 지기 시작합니다. 레거시로 인한 이슈까지 추가되면 서비스의 성능은 지속적으로 낮아지게 되므로 데이터베이스는 꾸준히 관리해야 하는 요소입니다.데이터베이스의 비중이 높다보니 어플리케이션 분석 서비스 중에서도 데이터베이스만 집중적으로 분석하는 도구들이 있습니다. 국내에서는 엑셈과 티맥스에서 데이터베이스 분석 솔루션을 제공하고 있습니다.  3. 오픈 소스와 써드파티 소프트웨어최근 두가지 형태의 트렌드가 서비스 성능에 영향을 주고 있습니다. 하나는 오픈 소스이고 다른 하나는 써드 파티 소프트웨어 입니다. 안정화 된 오픈 소스를 사용하더라도 설정 이슈 또는 사용 환경 이슈로 성능에 영향을 주는 상황이 많이 발생합니다. 위젯, 광고플랫폼, 플러그인등의 써드파티 또한 웹 서비스의 성능에 영향을 주는 요소입니다. 최근 써드 파티의 사용은 점점 늘어나는 추세로 인해 장애 발생에 대한 위험도는 더욱 높아가고 있습니다. 특히 써드 파티는 시간이 흐르면서 성능에 조금씩 부하를 누적시키기도 하므로 충분히 주의를 기울여야 합니다. 이런 환경에서도 서비스의 성능을 유지하기 위한 방법으로 통계 기반의 메소드 분석 기법 모니터링의 중요한 요소가 되어 가고 있습니다. 와탭의 Java 모니터링이 메소드 분석 서비스를 제공하고 있습니다. 4. 모바일구글 이 운영하는 더블클릭(https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/)에 따르면 북미에서 3G에서의 모바일 페이지 로딩까지 소요되는 시간은 평균 19초입니다. 한국은 이미 4G를 넘어가고 있기도 하고 모바일 기기의 성능도 매우 높아서 북미와 상황이 다르지만 모바일 기반의 웹 서비스 성능을 분석할 수 있는 방안의 필요성은 높아져 가고 있습니다. 이와 함께 다양한 환경을 지원하는 end-to-end 모니터링의 중요성이 점점 대두되고 있는 상황입니다.  5. 컨테이너최근 인프라스트럭처의 새로운 흐름은 컨테이너 입니다. 한국은 리눅스 기반의 서비스 구축 시스템이 잘 발달한 덕분에 클라우드 도입이 다른 나라보다 늦은 편입니다. 하지만 최근 국내에 컨테이너 기반의 인프라스트럭처 도입 기업들이 많아지고 있습니다. 우리나라는 가상화를 건너뛰고 컨테이너부터 활성화 될수도 있을 거라 생각됩니다. 컨테이너 환경은 가상화보다 더 많은 인프라를 더 유동적으로 사용하게 되므로 기존의 규모를 뛰어 넘는 관리 체계를 만들어 나가야 합니다. 데이터독과 뉴렐릭 같은 SaaS 기반의 모니터링 서비스들은 이미 컨테이너의 대한 지원을 하고 있으며 와탭 또한 단순 지원을 넘어 컨테이너 전용 서비스를 준비중에 있습니다. 6. 마이크로 서비스많은 기업들이 클라우드와 함께 Micro Service Arichtecture를 도입하고 있기 때문에 독립적인 어플리케이션을 기반으로 하는 서비스 구조는 계속 발전해 나갈 것입니다. 마이크로 서비스와 클라우드의 조합은 커져가는 서비스의 규모를 독립적인 작은 단위로 나눌 수 있어서 매력적이긴 하지만 과거와 다른 운영 조직과 프로세스를 만들어야 하는 숙제를 만들었습니다. 예를 들면 기존에는 하나의 임계치를 사용하여 서비스의 위험도를 관리했다면 이젠 독립적으로 동작하는 서비스들의 임계치를 각각 어떻게 설정하고 관리할 것인지 고민해야 합니다. 독립된 마이크로 서비스의 성능 이슈가 전체 서비스 성능 이슈로 확대되지 않더라도 작게 발생하는 이슈들을 관리하지 못한다면 지속적으로 발전해야 하는 서비스의 미래도 흔들리게 될 것입니다. 7. 서버사이드 코드정상적인 상황이라면 서버사이드 코드에서 발생되는 지연시간은 찰나에 가깝지만 장애 상황에서의 지연은 서버사이드에서 발생하는 경우가 많습니다. 특히 방어가 되어 있지 않은 코드들은 물리적 요소의 작은 변화에 대처하지 못하고 웹 서비스 전체에 영향을 미치게 됩니다. 스타트업의 경우 개발팀이 운영을 함께 맡고 있는 경우가 많기 때문에 서버사이드의 코드를 직접 분석하곤 합니다. 하지만 서비스의 성능이 느려지는 상황 자체를 파악하지 못하는 경우가 많습니다. 서버 사이드에서 평균 응답시간을 체크하는 경우 10초 평균 응답시간이 0.5초를 넘는 경우는 거의 없습니다. 하지만 0.5초의 평균 응답시간을 같는 서비스라 할지라도 하루 동안 10초이상 걸린 고객의 숫자는 규모에 따라 1,000명이 넘을 수도 있습니다. 서비스에 규모가 있다면 꼭 APM을 사용해야 합니다.8. 네트워크 지연네트워크의 지연으로 인한 고객 불만은 예상외로 많이 발생합니다. 인프라스트럭처 이슈로 볼 수도 있겠지만 서비스를 운영한다면 항상 체크하고 있어야 하는 요소입니다. 해당 이슈를 확인 하려면 웹서비스 모니터링을 사용하시면 됩니다. 웹서비스 모니터링을 통해 네트웍상태를 포함한 서비스의 응답시간을 체크해 볼수 있습니다. 와탭의 경우 내부적으로 웹서비스 모니터링을 개발하여 사용하고 있지만 아직 서비스 하고 있지는 않습니다.  9. 자원 사용률자원 사용률은 최근 새로 떠오르는 이슈입니다. 이전에는 인프라스트럭쳐가 고정값이였기 때문에 자원 사용률이 모자라는 경우 서비스 성능을 포기하고 초과되는 고객의 요청을 앞단에서 버리거나 대기시키는 기법들을 사용해왔습니다. 클라우드 환경에서는 자원 사용량의 임계치가 넘어가면 자동으로 스케일을 조정하는 환경이 마련되면서 성능을 유지하는 것이 가능합니다.  클라우드 환경에서 과부하 상태에 접근하면 자동으로 인프라의 규모가 확장되고 과부하 상태는 정상으로 돌아갑니다. 이렇게 환경이 바뀌면서 자원 사용률의 중요 이슈가 성능에서 비용으로 전환되고 있습니다. 부하에 따른 스케일링 정책을 어떻게 정하는지에 따라서 성능과 비용 모두가 영향을 받기 때문에 Auto Scale에 대한 모니터닝이 관심을 받고 있습니다.  마무리웹 서비스의 성능에 영향을 주는 요소는 정말 많습니다. 와탭랩스 IT 기업의 어플리케이션을 모니터링 하기 때문에 기업의 IT 어플리케이션 성능 문제에 대해 항상 고민하고 있습니다. 해당 내용은 매달 또는 분기별로 트렌드를 반영하여 업데이트하고 할 생각입니다. 많은 분들에게 도움이 되었으면 좋겠습니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1994

데일리호텔(DAILYHOTEL) 사내 이미지 촬영기

스타트업에서 '브랜딩'이란 어디까지 포함되는 개념일까요? 흔히 비(非) 디자이너의 경우 '브랜딩'이라 하면 기업의 로고를 제작하는 정도로 생각하시는데요. 사실 기업 안에서의 '브랜딩'작업이란 A부터 Z까지 모든 영역을 포괄적으로 다루는 일을 말합니다. 기업을 표현하기 위해 손 안의 작은 휴대폰 속 콘텐츠를 제작하기도 하고, 사내 인테리어나 채용 컨퍼런스에 필요한 시각적 요소를 제작하는 등 온/오프라인 디자인을 넘나드죠.그런 의미에서 채용채널을 관리하는 것 또한 브랜딩 차원에서 매우 중요합니다. 채용채널은 예비 데일리어에게 우리의 모습과 기업문화를 보여줄 수 있는 창구가 되어주는 역할일뿐더러, 그를 통해 기업 브랜딩 또한 다잡을 수 있기 때문이죠.당시 '채용채널 비주얼 개선'프로젝트가 진행되기 이전에 채용사이트에서 노출되던 이미지들입니다. 데일리의 어떤 부분을 보여주어야 할지 기획도 없었고, 전문 포토그래퍼의 작업이 아닌 휴대폰으로 촬영된 이미지였어요. 해서 신뢰를 얻을 수 있는 사내 이미지 촬영을 진행하고자 '채용채널 비주얼 개선'프로젝트가 진행됩니다.01 모델 선정세세한 기획에 들어가기 앞서, 이미지를 통해 전달하고자 하는 바를 키워드로 구체화시킵니다. 이 과정은 앞으로 데일리가 어느 방향성을 가지고 가고자 하는지 까지 고려해야 하는 부분이었죠.키워드가 도출된 이후에는 그를 표현하기 위해 적합한 사내 촬영 장소, 모델, 의상 톤, 소품, 구도 등을 선정하는 작업을 했습니다. 물론 모델은 데일리어분들을 실제로 섭외했죠. 상상해 봤을 때 위 키워드와 부합하며 서로서로 잘 어울리는 비주얼이 나올 수 있도록 모델셀렉을 하였습니다.섭외 요청을 드렸을 때 반응도 제각각이었어요. 기대에 부풀어 기뻐하시던 모델분들(!) 섭외가 완료된 후에는 모델들이 함께 모였을 때의 톤을 생각하며 의상의 종류와 색상 또한 지정하여 알려드렸습니다.02 장소 선정모델이 정해진 후에는 장소를 선정하는 작업을 했습니다. 우리에게 필요한 컷은 회의 컷, 핸드폰 컷, 카페테리아 컷, 업무 컷, 인테리어, 전사회의 컷이었어요. 해서 이 컷들을 촬영하기 위한 (햇빛이 잘 드는) 회의실, (항상 전문적이게 보였던) UI/UX Flow Board, (예쁜 선인장이 포인트였던) Sunny의 책상 등 장소들을 촬영 전 지정해두었어요.그리고 이 장소들에 맞는 소품을 준비하는 과정을 거칩니다. 만약 회의실이라면 노트북과 노트, 그리고 노트북에 띄어놓을 자료도 따로 준비를 했죠.03 기획 및 레퍼런스 이미지 전달디자이너에게 무작정 'OO를 제작해주세요!'라고 하면 쉽사리 멘붕에 빠지기 일쑤입니다. 해서 기획자에게 요청을 받을 때는 작업물의 의도와 표현하고자 하는 포인트, 삽입 문구 등을 함께 전달받는데요. 포토그래퍼 또한 마찬가지입니다. 무작정 'OO를 찍어주세요!'라고 하기보다 'A장소에서 3명의 인원과 ppt를 띄워놓고 회의하는 모습을 찍을 예정이에요!'라고 말하는 게 포토그래퍼 분도 파악이 잘 될 뿐더러 결과물 또한 의도한 대로 받아볼 수 있죠.04 촬영 진행기획 및 레퍼런스 이미지를 포토그래퍼, 모델분들께 다시 한번 알려드린 후 촬영을 진행합니다. 촬영 현장에서 저의 주 역할은 모델분들이 어색하지 않도록 계속 말을 걸고 최대한 자연스러운 표정과 모습이 나올 수 있도록 유도하는 것이었어요. 또한 현장에서 준비한 소품을 가지고 구도를 짜고 세팅을 하는 일은 포토그래퍼 분께서 담당해주셨죠. 셀카 100장에 인생 샷 1장이 나온다는 마인드로 찍고 또 찍습니다. 그리고 실시간으로 포토그래퍼 분과 확인하며 원하는 이미지에 가까워질 수 있도록 조율을 합니다.05 보정 및 적용촬영된 이미지는 톤 보정을 거칩니다. 한 명의 포토그래퍼분께서 촬영해주셨다고 해도 조명, 햇빛 등이 모두 같게 갖춰진 상황이 아니었기에 통일시키는 작업이 필요했죠. 그럼 잠시 감상해보실까요?!보정이 끝난 후에는 각 채널별로 적용되는 사이즈에 맞게 가공하여 적용을 합니다.데일리 채용사이트 -> careers.dailyhotel.co.kr마침 데일리호텔 채용이 진행중이네요. (깨알 홍보 맞아요)이렇게 촬영이 마무리가 됩니다. '채용채널 비주얼 개선'프로젝트는 새로운 이미지 촬영뿐만 아니라, 각 사이트에 적용되는 회사 정보와 연혁 등 모든 내용을 새롭게 업데이트 및 통일하는 과정을 함께 거쳤습니다. 예전과 비교하여 데일리가 전달하고자 하는 바를 예비 데일리어 및 유저분들께서 더 잘 느끼고 있을까요? 궁금하네요 :)그럼 다음번에도 재미있는 프로젝트로 찾아뵙겠습니다!기획/진행 : Creative팀작성자 : Creative팀 Blair Ahn포토그래퍼 : Loco Lee모델 : Troy Kim, Sunny Oh, Ashlee Shim#데일리 #데일리호텔 #마케터 #디자이너 #인사이트 #경험공유 #일지
조회수 1338

Semantic Versioning 소개

Semantic Versioning 소개Versioning?소프트웨어 개발 생태계는 수많은 사람들이 서로의 기술과 성과를 이어받아 오며 믿을 수 없는 수준의 협력 체제를 구축해오고 있습니다. 의존성은 이러한 협력체제에서 나오게 된 요소로, 다른 사람들이 만들어온 기능을 다시 만들 필요 없이 손쉽게 가져와서 재활용하는 방식으로 빠르게 소프트웨어를 만들 수 있게 되었습니다.하지만 이렇게 여러 사람에게 이용되는 패키지가 새롭게 업데이트될 때, 생각보다 다양한 문제에 직면하게 되었습니다. 기능의 사용법을 바꾸어버리거나 동작 방식의 변경 같은 변화들은 그에 의존하는 다른 소프트웨어를 의도대로 동작하지 못하게 하므로, 새로운 변화와 기존의 것을 구분할 필요가 생겼습니다. 버전이라는 개념은 이러한 패키지의 변화를 구분하기 위해 사용하기 시작하였습니다.Semantic Versioning?버전이라는 코드 형태의 구분방식은 많은 핵심 문제를 해결해주었지만, 아직 여러 과제가 남아있었습니다. 버전 명의 작성 방식에 관한 기준이 패키지마다 제각각 다른 것이 문제였습니다. 0.x와 1.x의 차이, 1.0.0 혹은 1.000. 선행 배포와 정식 버전의 구분 방법 등 모든 소프트웨어, 패키지는 저마다의 기준을 가지고 있었으며, 이는 어느 정도의 적당한 공통점이 있었지만, 그 점이 미묘하게 모두 차이가 있어 버전에 따른 의미 해석을 어렵게 하였습니다.Semantic Versioning은 Github의 공동창업자인 Tom Preston-Werner가 위의 문제를 해결하기 위해 기존의 현안을 모아 만든 제안입니다. 스펙 문서는 RFC 2119에 의해 규칙을 표기하여 의미적 엄격함을 높이고, 패키지 개발 생명주기에 발생할 수 있는 여러 상황을 포괄적으로 담아 일관성과 유연성을 균형 있게 갖추고 있습니다.규칙다음은 Semantic Versioning(v2.0.0-rc1)의 스펙을 한국어로 번역한 내용입니다.1. Semantic Versioning을 쓰는 소프트웨어는 반드시 공개 API를 정의해야 한다. 이 API는 코드 자체에 정의되어 있거나 명시적으로 문서화 되어있어야 한다. 이 과정은 포괄적이며 정확해야 한다.2. 일반 버전 명은 반드시 X.Y.Z 형태를 보여야 하며 X, Y, Z는 음이 아닌 정수이다. X는 주요한 버전이며, Y는 작은 버전, Z는 패치버전이다. 각 요소는 1씩 차례로 증가해야 한다. 예: 1.9.0 -> 1.10.0 -> 1.11.0.3. 주요 버전 숫자가 올라갈 때, 작은 버전 숫자와 패치 버전 숫자는 0으로 재설정되어야 한다. 작은 버전 숫자가 올라갈 때, 패치 버전 숫자는 0으로 재설정되어야 한다. 예: 1.1.3 -> 2.0.0, 2.1.7 -> 2.2.04. 버전 명이 주어진 패키지가 한번 공개되면, 해당 버전의 내용은 절대 수정되어선 안된다. 어떤 수정도 반드시 새로운 버전으로 공개되어야 한다.5. 주요 버전 0 (0.y.z)은 초기 개발을 위한 것이다. 언제든 변경될 수 있다. 공개 API는 안전하지 않다고 여긴다.6. 버전 1.0.0은 공개 API를 정의한다. 이 공개 이후의 버전 숫자가 바뀌는 방법은 공개 API와 변경 방법에 따라 결정된다.7. 패치 버전 Z (x.y.Zx > 0)는 하위호환을 하지만 버그 수정이 있을 때 올라간다. 버그 수정은 내부적으로 잘못 처리되고 있는 것을 고치는 것을 의미한다.8. 작은 버전 Y (x.Y.zx > 0)는 새로운 기능이 추가되었지만 기존의 공개 API가 하위호환되고 있을 때 올라간다. 공개 API가 하나 이상 deprecated될 시에도 올라가야 한다. 부가적인 새 기능이나 개선이 내부 코드 (private code)에 있을 시에도 올릴 수 있다. 이는 패치 수준의 변화를 포함할 수 있으나, 작은 버전이 올라가면 패치 버전은 꼭 0이 되어야 한다.9. 주요 버전 X (X.y.zX > 0)는 하위호환되지 않는 변화가 추가될 때 반드시 올라가야 한다. 이는 패치 수준과 작은 수준의 변화를 포함할 수 있으나, 주요 버전이 올라가면 작은 버전과 패치 버전은 꼭 0이 되어야 한다.10. 선행 배포 버전은 대시(-)와 점으로 나누어진 식별자들의 묶음을 패치 버전 뒤에 표시한다. 식별자들은 ASCII 영숫자와 대시로만 구성되어야 한다. [0-9A-Za-z-]. 선행 배포 버전은 연관된 일반 버전보다 낮은 우선순위를 가진다.11. 개발 버전은 더하기(+)와 점으로 나누어진 식별자들의 묶음을 패치 버전 뒤에 표시한다. 식별자들은 ASCII 영숫자와 대시로만 구성되어야 한다. [0-9A-Za-z-]. 빌드 버전은 연관된 일반 버전보다 높은 우선순위를 가진다.12. 우선순위는 주요, 작은, 패치, 선행 배포, 빌드 식별자 내 숫자 순으로 계산되어야 한다. 주요, 작은, 패치 버전은 항상 숫자로 비교되어야 한다. 선행 배포와 빌드 버전의 우선순위는 반드시 각 점으로 나누어진 식별자들이 아래 규칙에 따라 비교되어야 한다: 1. 숫자로만 이루어진 식별자는 숫자로 비교 (2) 문자와 대시가 포함된 식별자는 ASCII 정렬 순서대로 비교. 숫자 식별자는 숫자가 아닌 식별자보다 낮은 우선순위를 가진다. 예: 1.0.0-alpha < 1>응용여러 오픈소스 프로젝트들이 이미 Semantic Versioning에 따라 버전 명을 표기하기 시작하였으며, 해당 규칙에 기반을 둔 버전 비교 라이브러리도 만들어지고 있습니다.•node.js: https://github.com/isaacs/node-semver•PHP: https://github.com/GordonSchmidt/SemVer•Python: https://github.com/k-bx/python-semver•Ruby: https://github.com/iantruslove/SemverStringerseaport는 node.js 에서 서비스 클러스터들이 Semantic Versioning에 따라 버전 의존성을 가지게 설계할 수 있어 보다 안정적인 버전 협상이 가능하도록 하고 있습니다.server.js:var seaport = require('seaport');var ports = seaport.connect('localhost', 9090);var http = require('http');var server = http.createServer(function (req, res) {res.end('beep boop\r\n');});server.listen(ports.register('[email protected]'));client.js:var seaport = require('seaport');var ports = seaport.connect(9090);var request = require('request');ports.get('[email protected]', function (ps) {var u = 'http://' + ps[0].host + ':' + ps[0].port;request(u).pipe(process.stdout);});output:$ node server.js &[1] 6012$ node client.jsbeep boop마치며비록 작은 통일일지는 모르나, 버전 명을 작성하는 훌륭한 기준이 있다는 것은 장기적으로 개발 생태계를 더욱 빠르고 긴밀하게 협력하도록 도와줄 것이라 생각됩니다. 의미적 해석이 가능한 코드는 의존성 문제를 더 똑똑한 수준으로 자동화할 수 있기 때문이죠. 버전 명을 지으실 때 좋은 안내서가 되었으면 좋겠습니다.#스포카 #개발 #개발자 #개발팀 #꿀팁 #인사이트
조회수 1039

현대오일뱅크 선배들의 이야기 - "자기 자신에 대한 고민이 먼저" 글로벌사업본부 운영최적화팀 전성배

현재 담당하고 있는 업무에 대해 소개해 주세요.운영최적화팀은 원유 도입에서부터 제품 판매까지 전사의 밸류체인을 최적화하는 역할을 맡고 있습니다. 또한 정제 마진 및 원가 변동에 따른 리스크를 분석하고 관리함으로써 회사의 수익성을 높이고 있습니다. 저는 이 중에서 각 제품 마진의 변동성을 관찰하고 그 리스크를 적정 수준으로 관리하는 업무를 담당하고 있습니다. 국제 시장의 변화를 분석하여 대응함으로써 회사의 손익을 증진시키고 안정적인 경영이 가능하도록 도움을 주고 있습니다.입사를 준비하고 있는 후배들에게 해주고 싶은 말은?흔히 말하는 ‘취준생’의 기간이 저에게는 자신을 돌이켜 볼 수 있는 가장 좋은 시간이었습니다. 나의 장점은 무엇인지, 내가 다른 사람들에게 어떻게 비춰질지 등 자기 자신에 대해 가장 고민을 많이 하고 해답을 찾으려 애썼습니다. 이를 통해 자기소개서와 면접에서 제 장점을 충분히 어필 할 수 있었고 그것이 좋은 결과를 만들었습니다.후배님들 모두 20년 이상의 긴 시간 동안 정말 열심히 살아왔을 것입니다. 이제는 그것을 다른 사람들에게 어떻게 보여주냐의 싸움입니다. 여러 측면에서 자신을 한 번 더 돌아보고 어떻게 어필 할 수 있을 지 고민해 보시기 바랍니다. 이를 위해 친구, 가족 등 가까운 사람들에게 본인에 대해 물어보는 것을 추천하고 싶습니다. 후배님이 모르고 있던 후배님의 장점을 알 수 있을 것입니다. 이를 통해 다른 지원자와 차별화되는 자신만의 이야기를 풀어낼 수 있다면 반드시 원하는 결과를 얻게 될 것입니다. 마지막으로 어떠한 상황에서도 자신감을 잃지 않으신다면 분명 좋은 결과를 얻을 수 있을 것입니다. 화이팅!#현대 #현대그룹 #현대오일뱅크 #운영최적화팀 #직무정보 #직무소개 #선배들의이야기 #현대오일뱅크채용 #현대오일뱅크공채 #구성원인터뷰
조회수 5077

AWS Instance Scheduler Bot 적용기

이 포스팅은 총 2부로 이어지며 현재는 2부입니다.1부 : AWS 비용 얼마까지 줄여봤니?2부 : AWS Instance Scheduler Bot 적용기1부에서 AWS 비용을 절감하기 위한 Instance Scheduler에 대한 소개를 하였습니다. 2부에서는 Instance Scheduler의 설정을 손쉽게 변경하기 위한 Bot을 적용한 사례에 대해서 소개합니다.Bot의 필요성Instance Scheduler의 설정을 변경하기 위해서는 정보를 담고 있는 Dynamo DB 의 데이터를 변경해야 합니다. AWS Console을 이용하여 직접 수정할 수도 있지만 여전히 불편하고 느립니다. 더군다나 이를 이용하는 사용자가 DB Table의 구조와 AWS Console 사용법을 알고 있어야 하고 비 개발자라면 더 쉽지 않은 문제입니다. 하지만 Bot을 이용하면 사용자는 어려운 DB Query나 구조를 알아야 할 필요도 없고 손쉽게 채팅 메시지를 통해 Bot에게 질의하고 처리 결과를 응답받을 수 있습니다.Outgoing WebhookJANDI에서는 Incoming Webhook과 반대되는 개념으로 Outgoing Webhook을 제공합니다. 특정 키워드로 시작하는 메시지가 있을 경우 내용을 설정된 URL Endpoint에 POST로 Webhook을 보내줍니다. Webhook을 수신한 곳에서는 일련의 처리 후 메시지 데이터 형식을 맞춰 응답하게 되면 채팅창에 메시지를 표시하게 됩니다. 이를 통해 다른 외부 시스템과 연동할 수 있습니다.POST Data예를 들어 날씨 키워드로 Outgoing Webhook을 생성했다면 /날씨 메시지가 시작될 때 다음과 같은 데이터가 Webhook으로 발송됩니다.{ "token": "YE1ronbbuoZkq7h3J5KMI4Tn", "teamName": "Toss Lab, Inc.", "roomName": "토스랩 코리아", "writerName": "Gloria", "text": "/날씨 서울", "keyword": "날씨", "createdAt": "2017-07-19T14:49:11.266Z" } token을 이용하여 요청의 유효성 체크를 할 수 있고 text를 적절히 파싱 하여 요청에 부합하는 처리를 할 수 있습니다.ResponsePOST Data를 적절히 처리 후 결과를 채팅창에 응답 메시지를 표시하고 싶다면 아래와 같은 JSON Data를 Response body에 넣어주면 됩니다.{ "body" : "서울의 현재 날씨", "connectColor" : "#FAC11B", "connectInfo" : [{ "title" : "온도", "description" : "최고:28.00, 최저:24.00, 현재: 24.30" }, { "title": "날씨", "description": "흐리고 비" }] } 이를 이용하여 Instance Scheduler에도 적용해봤습니다.Schedule BotSchedule Bot은 Instance Scheduler의 Lambda 함수에 함께 포함되어 작동하며 스케쥴 조회 / 예외 설정, 서버 강제 시작/중지, 서버 상태 조회 등의 기능을 수행합니다.API Gateway와 Lambda 함수를 연결하여 Endpoint URL을 생성하고 Outgoing Webhook URL로 설정하여 Webhook으로 Lambda 함수가 실행될 수 있도록 하였습니다. Lambda 함수는 Cloudwatch를 통해서 실행되면 Scheduler가 작동되고 API Gateway를 통해 실행되면 Schedule Bot이 작동됩니다.Schedule Bot 명령어Schedule Bot은 다음과 같은 명령어를 수행합니다./서버 help : 도움말 /서버 [스케쥴명] status : 현재 서버 상태 조회 /서버 [스케쥴명] info : 오늘의 스케쥴 조회 /서버 [스케쥴명] info [YYYY-MM-DD] : 특정일 스케쥴 조회 /서버 [스케쥴명] exception info : 오늘의 스케쥴 예외 조회 /서버 [스케쥴명] exception info [YYYY-MM-DD] : 특정일 스케쥴 예외 조회 /서버 [스케쥴명] exception set [YYYY-MM-DD] [start|stop] [h:m] : 예외 설정 /서버 [스케쥴명] exception del [YYYY-MM-DD] [start|stop] : 예외 삭제 /서버 [스케쥴명] force_start : 서버 강제 실행 /서버 [스케쥴명] force_stop : 서버 강제 중지 Schedule Bot 작동 화면Schedule Bot은 서버병이라는 컨셉으로 인격화(?)에 힘썼습니다.스케쥴 정보 조회서버 상태 조회서버 강제 시작/중지명령어 오류마무리AWS 기반의 서비스를 운영하는 스타트업이라면 더욱더 현실적으로 부딪히는 비용 문제에 대해서 저희가 고민한 내용과 솔루션에 대해서 공유하였습니다.아직 적용기간이 길지 않아 절감비용에 대해 수치적인 데이터를 언급하기는 힘들지만 많은 금액이 절감될 거라 예상하고 있습니다.저희와 같은 고민을 하고 있다면 Instance Scheduler를 적극 권장합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #AWS #도입후기 #일지 #인사이트 #경험공유
조회수 1837

TPS 지표 이해하기

많은 초창기 스타트업들은 성능에 관심이 없습니다. 제품 만들기도 바쁜데 성능이 무슨 의미가 있을까 생각이 들죠. 당장 서비스에 사용자가 몰리면 아마존 오토스케일이 해결해 줄테니까요. 맞습니다. 빠르게 가치를 증명하는 스타트업이라면 서비스 초창기부터 성능에 관심을 가질 필요는 없습니다. 하지만 한달에 아마존 서비스 비용이 천만원이 넘어가기 시작하면 슬슬 우리 서비스가 합리적으로 인프라를 사용하고 있는지 고민하게 됩니다. 인프라 비용의 근거도 만들고 싶어지기 시작하죠. 시스템의 성능 지표를 확인 하고 싶어진다면 지금이 TPS 지표를 보실 때입니다. Whatap Application TPS MetricTPS 계산하기Transaction per second(TPS)는 초당 트랜잭션의 개수입니다. 실제 계산하는 방식은 일정 기간동안 실행된 트랜잭션의 개수를 구하고 다시 1초 구간에 대한 값으로 변경합니다. 와탭의 경우 5초 구간으로 값을 수집하기 때문에 단위시간 동안 집계된 트랜잭션의 수를 5로 나눈 값이 표시됩니다. 위에 그림에 두번째 행을 보시면 5개의 트랜잭션이 실행완료된 것을 볼수 있습니다. 이런 경우 TPS를 구하는 방법은 5 transaction / 5 sec 이므로 결과값은 1 TPS 가 됩니다. (와탭의 TPS 지표는 좀더 복잡하게 계산합니다. 와탭은 챠트의 추세를 보여주기 위해 5초 간격으로 30초 평균 TPS를 보여주고 있습니다.)Saturation Point 와 TPS서비스에 사용자가 지속적으로 늘어나면 어느순간부터 TPS가 더이상 증가하지 않는 상황이 발생합니다. 이렇게 증가하지 않는 지점을 Saturation Point라고 합니다. 위 그림은 서비스의 이상적인 상황입니다. 제대로 튜닝이 되지 않은 서비스는 Saturation Point를 지나면 오히려 TPS가 떨어지기도 합니다. 위 그림을 보면 서비스를 사용자는 300명이 넘어가면 TPS가 고정되면서 상대적으로 트랜잭션의 응답시간이 길어 질것을 예상할 수 있습니다.  좀더 스토리를 만들어 보면 이렇게 이야기를 할 수 있습니다. 위 그림을 보면 동시 접속 사용자가 300명이 넘어가면 TPS는 더이상 올라가지 않으므로 서비스의 정체 시간은 증가하기 시작할 것입니다. 300명의 요청사항에 대한 TPS가 50이라면 해당 요청 사항을 다 처리하는데 6초가 걸린다고 생각할 수 있습니다. 이렇게 TPS와 동시접속자를 미리 선정해봄으로써 서비스의 성능을 상상해 볼 수 있습니다.요점 정리TPS는 초당 트랜잭션의 갯수를 말합니다. TPS는 서비스 성능의 기준이 됩니다.평소 TPS 지표를 체그하세요. TPS를 통해 무슨 요일에 또는 몇시에 최대치가 되는지 확인하세요.  TPS가 더 이상 증가하지 않은 지점을 Saturation Point라고 합니다. Satuartio Point가 넘으면서 사용자가 몰리면 TPS가 고정된 상태에서 응답시간이 길어지게 됩니다.   #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 968

Team Profile: Meet Yonghyun

Read In KoreanAs a yet minuscule startup, each member holds a significant power over the overall atmosphere of the team. And in our ultimate quest to make big waves in the data world, we need to make sure that the people at the helm are at least kind of cool. We think we’ve done a pretty good job so far in assembling a society of unique but equally driven members.So we bring you this seven-part series, one of each devoted to interviewing each of our members in detail, to give you an in-depth glimpse into the people responsible for bringing you the future of machine learning with Daria. Plus, we peppered the interviews with questions from Dr. Aron’s “The 36 Questions that Lead to Love”*, cherry picked to make work appropriate and concise, but interesting.(*actually falling in love with our members highly discouraged)Yonghyun joined the XBrain team in August as a software engineer, and has worked closely with other members in constructing the software that Daria runs on. But his interests run beyond just making sure that Daria become the future star of machine learning and data science — Yonghyun is also an avid soccer player, and an enthusiastic dabbler of virtual and artificial reality. Learn more about him here!Yonghyun saves a few minutes of his day for some introspection/staring broodily out the windowHi Yonghyun! Start by telling us about your role.YH: I work with JM as a software engineer at XBrain, developing and testing our software infrastructure.How do you usually spend a work day?YH: I usually come to work around lunchtime, and devote my time to whatever needs to be done for the day. Today we worked on tests involving transferring data from MS SQL. I enjoy afternoon walks sometimes, and usually head home after working a little post-dinner.Tell us about the parts of your job that you most enjoy.YH: I enjoy transforming machine learning modules into Spark to fit with the cloud system, and looking at the code Suzin’s written in order to understand the process.What about the aspects that you least enjoy or find challenging?YH: Setting up the environment to test our systems is something I least enjoy. It’s frustrating, because you can follow all the steps and still go the wrong way.Pick one item on your desk that tells us something about you.YH: I don’t have a whole lot on my desk…so I would probably have to say my laptop. The very very big laptop provided to me by the company.Laptop in photo is larger than it appearsWhat made you want to become a software engineer?YH: I was originally majoring in History in college, but I was struck by how computer science could help you create something tangible. Programming helps turn your ideas into reality on the screen, which is something I was really drawn to.So why XBrain?YH: As an incoming programmer, you don’t really come across the opportunity to participate in the making of a product that’s still under development. It’s a good learning experience for me to watch Daria’s progress. Furthermore, because I started programming at a relatively later stage, I still need help with my mathematical background, which working here allows me to do.As the one of the newest additions to the team, tell us about your vision for XBrain.YH: I think my vision is one of becoming a household name for a machine learning tool that a lot of people use on the daily — Daria doing useful things in every facet of the world, big or small.What is your go-to work playlist?YH: When I’m coding, I usually prefer EDM, so stations like Hardwell On Air, and hip-hop as well.Recommend a movie for our next Cinema Society, please.YH: Watchmen (2009). Its protagonist Rorschach is an anti-hero, and the plot line is complex and interesting to follow.Where do you see yourself 10 years from now?YH: Career-wise, honestly I wouldn’t mind what I have right now — working a job that I love without getting too swamped with deadlines, with plenty of time for exercise and socializing, playing soccer with my friends.Given the choice of anyone in the world, whom would you want as a dinner guest?YH: Mark Zuckerberg, maybe? I’d like to hear about his ideas for the future.If you had to have dinner with one XBrain member, who would it be and why?YH: JP, our new machine learning engineer. I’d like to get to know him better, and he seems like an interesting person.Would you like to be famous? In what way?Nope.What would constitute a “perfect” day for you?YH: A day productive enough that I could go to bed without worrying about the next day.If you were able to live to the age of 90 and retain either the mind or body of a 30-year-old for the last 60 years of your life, which would you want?YH: The body of a 30 year old… I don’t think that youth isn’t everything when it comes to minds.For what in your life do you feel most grateful?YH: The privilege to have been able to learn and achieve everything I’ve wanted is something I’ll always be thankful for, and also the flexibility to be able to change directions I’m headed in.If you could wake up tomorrow having gained any one quality or ability, what would it be?YH: I’ve always wanted more drive to carry out the projects I’ve devised in my head, the ability to see things through no matter what.Is there something that you’ve dreamed of doing for a long time? Why haven’t you done it?YH: I’ve always wanted to learn how to cook. I lived in a dorm in college so I didn’t have the opportunity then, but now would be a good time as any.What is the greatest accomplishment of your life?YH: I would say my greatest accomplishment is putting my best efforts into learning and improving my mind, inside and outside of school.What is your most memorable XBrain moment?YH: My fondest memories are usually of events we held outside — the hike we went on in September, or the soccer game we had. I like that we got to bond as a team and get some exercise.If you knew that in one year you would die suddenly, would you change anything about the way you are now living? Why?YH: I haven’t been able to get decent sleep recently, so I’d probably give myself some time to rest.If you were going to become close friends with someone, please share what would be important for him or her to know.YH: I don’t have very strong likes or dislikes, so I usually get along with most people.What, if anything, should never be joked about?YH: You should never joke about the disadvantaged, or others’ insecurities.If you could sum up XBrain in three words or less?YH: Freedom. Consideration. Learning…. Is that too serious?#엑스브레인 #팀원소개 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑

기업문화 엿볼 때, 더팀스

로그인

/