스토리 홈

인터뷰

피드

뉴스

조회수 1568

냉철한 친절함으로 첫 문을 열어주는 사람들

와디즈의 따뜻한 매형와디즈에서 오픈하는 리워드 프로젝트는 처음과 마지막을 리워드 심사팀과 함께 합니다. 와디즈의 심사 기준에 맞는지, 제품군에 따라 필요한 인증이 있다면 모두 충족되었는지 그리고 서포터들에게 약속한 날짜에 잘 배송될 수 있는지를 확인하지요. 매의 눈빛으로 냉철하게, 때로는 메이커들이 와디즈에서 더 멋지게 데뷔할 수 있도록 메이커 입장에서 친절하게 심사를 도와드리는 리워드 심사팀의 하루를 소개합니다.09:00 - 두근두근, 신규 프로젝트 확인메이커분들이 밤새 열심히 프로젝트 페이지를 개설하여 검토 요청을 누르시면 제출된 순서대로 꼼꼼하게 확인합니다. 그리고 카테고리별로 심사 담당자들은 신규 심사를 진행하지요. 이렇게 검토 요청들어온 프로젝트 수가 놀라울 정도로 매일매일 늘어납니다. 돌고래 주파수로 행복한 비명을 질러요.10:00 - 기존 심사건 회신카테고리별로 신규 프로젝트 건수와 간략한 내용을 확인 후, 가장 먼저 하는 일은 기존에 저와 소통하는 메이커분들의 이메일에 회신을 하는 일이지요. 대체로 저희가 요청한 서류를 회신으로 보내주시거나 와디즈 프로젝트 심사기준에 맞게 수정했다고 회신을 주시는 경우지요.와디즈 메이커분들은 처음으로 사업을 시작하시는 스타트업이 많아요. 그래서 심사를 하다보면 저희가 제출 요청드리는 서류에 대해 문의하시는 메이커분들이 많아요. 법적으로 반드시 받아야 하는 인증서류이기 때문에 받는 경우도 있지만, 크라우드펀딩이기 때문에 받는 서류들도 많습니다. 쇼핑몰은 결제 즉시 로켓으로 쏘아올린 제품을 배송받지만, 크라우드펀딩은 펀딩 후 평균 1~2개월 후 리워드를 받습니다. 펀딩이 마감될 쯤 성공 여부에 따라 리워드를 만들 수 있기 때문이죠. 따라서 메이커분들을 믿고 펀딩하는 서포터분들에게 안전한 리워드를 제공하기 위해서 반드시 필요한 인증들이기 때문에 저희는 하나도 빠지지 않고 집착을 해서 모두 받아냅니다. 11:30 - 신규 심사건 회신기존에 소통하고 있던 예비 메이커님들과의 메일에 모두 회신을 했다면, 이제 새로운 프로젝트들을 하나하나 확인해 볼 차례예요. 리워드 심사 담당자로서 가장 어렵고도 흥미로운 때는 제가 지금까지 모르던 신기한 제품이나 서비스를 만나볼 때죠. 펀딩 욕구가 뿜뿜할 때도 있지만, 난생 처음 보는 테크 제품은 많은 리서치를 필요해요. 메이커님에게 들은 설명이 부족할 때는 관련 논문이나 기사도 찾아보고, 기관에 전화해서 여쭤보기도 하지요. 리워드로 제공하는 제품이나 서비스를 이해해야 심사도 진행할 수 있으니까요.와디즈는 이 제품이나 서비스가 얼마나 매력적인지에 대해 초점을 두고 심사하지 않아요. 매력도는 크라우드펀딩 플랫폼인 만큼 와디즈 서포터들이 집단 지성으로 판단하는 것이기 때문이니까요. 다만 이 제품이 생산되거나 서비스가 런칭되어 서포터에게 전달되었을 때, 위험성이나 사회적으로 이슈는 없을지 와디즈 자체 심사기준에 따라 심사하고 있어요.만약 당신이 이런 사람이라면,와디즈 리워드 심사 담당자입니다.- 얼리어답터 성향으로 다양한 제품이나 서비스를 만나보는 것에 설레시는 분- 새로운 지식에 대해 리서치하는 것이 재미있는 분- 어려운 내용을 알아듣기 쉽게 설명하는 재능을 가지신 분- 이슈답게 갑자기 발생해도 당황하지 않고 차분하게 대응하며 해결방안을 만드시는 분- 빠른 실행력과 꼼꼼함으로 중무장하신 분13:30 - 카테고리별 심사 가이드라인 정리이미 카테고리별 심사 가이드라인이 있지만 오늘 새롭게 들어온 케이스를 정리해 두어야합니다. 새로운 심사 담당분들이 입사했을 때도 참고하실 수 있는 자료가 되지만, CX담당자분들이 예비 메이커님에게 심사 기준에 대해 설명드릴 때도 유용하지요. 가장 큰 이유는 제가 찾아낸 노하우들이 사라져버리지 않도록, 오늘 한 고생 내일은 하지 않으리! 이는 와디즈가 일하는 방식에서 가장 중요한 부분이기도 합니다.15:00 - 메이커와 대면 심사 진행리워드 프로젝트 심사는 대부분 스토리의 사진과 영상, 보내주신 서류 등을 통해 서면으로 진행됩니다. 직접 대면으로 리워드를 확인해야 할 때도 있어요. 리스크가 높아보이거나 원리나 작동방법을 두 눈 부릅뜨고 확인해야 하는 제품군인 경우이지요. 메이커가 직접 리워드를 갖고 와디즈를 방문하시면, 심사 담당자들이 꼼꼼하게 확인하고 생산 계획 등 인터뷰를 진행합니다. 와디즈에서 가장 중요시하는 '신뢰'를 점검하는 절차입니다. 17:00 - 담당 리워드 콘텐츠디렉터 지정오늘은 모두 심사가 마무리되었어요. 와디즈에서 진행 승인을 받은 팀들은 메이커님이 선택하신 수수료방식과 카테고리에 따라 담당 CD나 퀵오픈 담당자를 배정합니다. 프로젝트 오픈을 도와드릴 와디즈 담당자와 메이커간 찰떡 궁합이길 바라면서요. 이 합이 펀딩 성공의 키는 절대 아니지만, 담당자들이 메이커와 즐겁게 프로젝트 오픈 준비를 하는 것을 보면 이상하게 뿌듯하답니다.와디즈 리워드 심사 담당자에게 물었습니다.Q. 어떤 성향의 사람에게 이 리워드 심사 업무가 적합할까요?A. 다양한 분야를 알아가는데 흥미를 가지고 있다면 즐겁게 일할 수 있을 거예요. 와디즈 펀딩 특성상 리워드 심사 담당자는 아직 세상에 선보이지 않은 아이디어 제품과 서비스들을 가장 먼저 만나볼 수 있는 어마어마한 기회가 주어지죠. 해당 제품/서비스가 와디즈 펀딩의 목적에 부합하는지, 실제 그 제품/서비스 실현 가능성은 있는지, 유통 시 국내 법에 저촉되진 않는지 등 다양한 배경지식을 습득할 수 있어요. 여기에 꼼꼼한 성격이 더해지면 금상첨화!Q. 어떨 때 힘드신가요?A. 워낙 다양한 제품이 들어오다보니 검토해야 할 내용이 많고 정말 많아요. 심사 업무를 하면서 매일매일 발전하는 와디즈를 보게 되지만, 여전히 생각지도 못했던 제품들이 쏟아져 리서치하는데 시간을 많이 써야한답니다. 하지만 새로운 것들은 늘 짜릿함을 동반합니다. Q. 업무하면서 가장 뿌듯했던 순간은요?A. 와디즈 펀딩의 가치를 메이커님께 전달해드려 공감을 이끌어내고 펀딩 성공까지 했을 때이죠. 이건 심사뿐 아니라 와디즈의 많은 직구들이 다 그럴 거예요. 펀딩 성공 후, 정식으로 제품/서비스를 출시하고 투자도 받으셨다는 소식을 들었을 때 가장 뿌듯해요.와디즈에서 서비스운영을 맡고 있는 장민영입니다.  와디즈에서 선한 자금 흐름을 만드는 일이라면 무엇이든 하고 있습니다. 좋은 사람들을 곁에 두고, 운영이라는 것이 얼마나 가치 있는지를 세상에 보여주고 싶다는 자부심으로 오늘도 씩씩하게 출근합니다.글 : 장민영편집 및 사진 : 차재영#와디즈 #기업문화 #기업소개 #조직문화 #팀소개
조회수 1010

회의실의 브랜딩: 브랜딩 회의만 7시간

오전회의가 시작되었습니다. 일단은 졸립니다. 커피를 들고 출근을 하긴 했지만, 그 정도의 카페인으로는 아침잠 대악마를 이길 수가 없죠. 오늘의 회의 주제는 '우리 회사 브랜딩 뜯어고치기' 입니다. 침을 삼키며 긴장감이 어린 표정들이 가득합니다. 대표님의 표정은 사뭇 진지합니다. 이제부터 극한업무 '회의'가 시작됩니다. 회의라는 것은 모든 직장인들에게 점심메뉴 고르기만큼 어려운 업무입니다. 회의라는 것은 '모을 會 / 뜻 意', 즉 '뜻을 모은다.' 라는 뜻입니다. 회의가 어려워지는 것은 이 두 글자 때문입니다. 뜻을 내는 것과 그걸 모으는 일이지요. 생각보다 우리는 우리의 생각을 밖으로 표출하거나, 드러내 본 적이 없습니다. 당연히 모아본 경험도 그리 많지 않습니다. 경험의 부재는 자꾸 어긋난 방향의 회의를 만들고, 어긋난 결론에 도달합니다. 그런데도 회의는 필수불가결한 업무요소 중 하나입니다. 그 방식은 물론 다양합니다. 원탁의 기사 컨셉도 있고, 독재자놀이도 있고, 모란시장 컨셉도 있고, 취침시간, 헥소고지 전투 컨셉 등..뭐 직원들의 성향과 비즈니스의 특성에 따라 각각 달라집니다. 그러나 그 과정이 어떠하던 결론적으로 "행동을 만든다." 라는 것에는 변함이 없습니다.음? 행동을 만든다고? 그렇습니다. 일단 이 정의부터 잡고 들어가봅시다. 회의는 결론을 내거나 솔루션을 만드는 것이 아닙니다. 잘 생각해보세요, 국K-1이 멱살잡고 의사봉을 집어던지고 마스크를 쓰거나 연필을 책상에 세우는 등 다양한 행위를 통해 그렇게 치열한 논쟁을 벌이는 이유가 무엇인가요? 그렇습니다. 그들은 '표결'을 하기 위함입니다. 이것을 '진행할 것이냐, 아니냐.' 를 결정하기 위해 갑론을박을 하는 것이죠. 그러나 업무의 회의는 정책회의와는 다릅니다. 우리는 정해진 어떤 두 항목 중 택일을 하는 것이 아닙니다. 표결에 부쳐 가부를 결정하는 과정이 아니죠.(물론 아예 그런 회의라면 또 모르겠습니다만) 회의시간엔 말을 통한 솔루션을 내는 것이 아닙니다. 솔루션은 행동을 통해 만들어지는 것이죠. 회의에선 바로 "어떤 행동을 할 것이냐?" 에 대한 결정을 내리는 것 뿐입니다.어떤 행동을 할 것이냐? 에 대한 결정을 내리는 것 뿐입니다.이 포커스가 자꾸 어긋나서 '해결방안' 을 만드는 것에 초점이 맞추어지면 전설의 탁상공론이 탄생하게 되는데, 그 결과는 코엑스 앞에 말춤 손목동상같은 것들이라고 할 수 있습니다. 책상에선 아무것도 해결할 수 없습니다. 뜻을 모은다는 것은 서로의 현명함과 지식을 끌어모아서 자랑질을 하자는 것이 아닙니다. 또한 전문가집단이 아니므로 학술적인 결론을 내는 것도 아닙니다. 따라서 오늘은 '행위를 만드는 것'에 초점을 맞춰 회의의 프로세스를 한 번 정리해보도록 하겠습니다. 물론 이 프로세스는 그냥 예제에 가까운 가이드일 뿐입니다. 실제 클라이언트사에서 브랜딩회의를 진행할 때 주로 제가 사용하는 방법이기도 합니다. 폭망한 적도 있고, 꽤 좋은 결과를 낸 적도 있었죠. 그러니 각각의 회사 성향에 맞게끔 쏙쏙 자체 필터링을 하신다면 흥미진진하실거라 생각합니다.0. 회의하쟝회의하러 가쟝출근하자마자 회의실로 모이라는 건 잔혹한 일입니다. 이론적으로야 당연히 9시는 출근시간이 아닌 업무시작시간입니다. 그러나 9시가 딱 되었다고 해서 갑자기 정신이 또렸해지고 영혼이 깨어나면서 없던 인사이트가 폭발하는 것은 아닙니다. 여전히 졸립고 피곤하고 멍한 것은 사실 대부분 마찬가지입니다. 그러니 딜레이타임과 자료준비 시간은 어느정도 확보하는 것이 좋습니다.회의 당일날 실무자들은 일단 출근하자마자 5가지 일을 챡챡 하도록 합시다.1. 커피사오기커피는 알아서 사옵니다.2. 물티슈로 책상닦기왠지 정돈된 느낌을 받을 수 있습니다. 물티슈는 DC백화점에서 구매한 100매에 990원짜리 싼 것을 쓰도록 합시다. 키보드를 뒤집어 털어주면 거대한 드러움과 알 수 없는 쾌감을 느낄 수 있습니다.3. 간밤에 들어온 메일확인 및 첨부파일 정리CC걸린 메일도 확인합니다. 첨부파일은 다운받아서 각 프로젝트 폴더에 저장해놓도록 합시다. 파일명이 이상야리꾸리하면 바꿔줍니다.4. 금일 to do list 정리메일은 크게 보고/진행/요청으로 나뉘어지는데 업무 리스트도 보고할 것, 진행중, 요청받은 것으로 쪼개서 정리합시다. 보고는 회의전 모두 진행할 겁니다. 진행중인 것들은 루틴업무로 뺍니다. 요청받은 것들은 진행중인 것들과의 선후관계를 따져 우선순위를 설정합니다. 각 할 일 옆에는 이거 끝내는데 몇 분 걸릴 지 러닝타임에 기재해주고, 1~5순위까지 정해서 먼저 처리할 것들부터 나눕니다. 1. 양이 적고 급한 것2. 양이 많고 급한 것3. 양이 적고 안 급한 것4. 양이 많아 안 급한 것순서로 정리합니다.5. 회의자료 정리회의자료는 쓸데없이 복잡하게 만들지 말고, 숫자달아서 리스팅합시다. 1. 회의실에 앉아보쟈사실 서서하는 회의가 더 효율적이란 얘기도 있습니다. 15분안에 끝나고 졸림도 예방할 수 있고 뭐..등등. 원하신다면 한 번 시험삼아 해보시는 것도 좋겠습니다만 반발이 이만저만이 아닐 수 있습니다. 회의실엔 회의자료를 쨕 돌려놓습니다. 빔 당연히 켜져있어야 하고, 노트북 셋팅하고. 그리고 절대 간식을 빼놓지 맙시다. 간식은 생명이자 떡이요 구원입니다. 2. 회의시간을 지정합니다.사회자 : 오늘 회의는 60분안에 끝낼 겁니다팀원 : 뻥치시네.시간 지정 중요합니다. 한도 끝도 없이 모여서 논쟁만 나눈다고 될 일이 아닙니다. 그렇게 끝난 회의에게서 카타르시스를 느끼거나 오늘 하루 보람찼다!!라고 느끼는 건 변태입니다. 의사결정은 빠르게!! 행동은 디테일하게 하는 것이 더 중요합니다.3. 회의 주제를 던집니다.코난 말투로 회의주제를 던집니다. 사회자죠."내 이름은 코난, 사회자죠. 이 공간엔 모두 10명의 사람들이 있어요. 어젯밤 11시, 우리 회사 브랜드가 죽었습니다. 회사엔 외부인이 전혀 없었고 브랜드는 현망진창이 되어있었어요. 이건 완벽한 밀실살인이예요. 지금부터 브랜드를 죽인 범인을 찾아낼 때까지 다들 한 발자국도 못나갑니다."4. 현재 상황에 대해 짧고 간결하게 브리핑을 합니다.창업전설까지 거슬러 올라가며 오래 전 그 날을 끄집어내란 얘기가 아닙니다. 현상황이 더 중요합니다. '현재 저희와 유사한 업체가 3개 있는데 그 중 1개업체가 우리 점유율을 앞질렀습니다.''대외적 인지도도 훨씬 높습니다. 우리의 트래픽 자체는 크게 변하지 않았지만 SNS상에서 그들의 프로모션 이벤트가 크게 회자되면서 이미지를 선점하고 있어요.''현재 우리는 네이버연관검색어 등 유료마케팅을 통한 고정유입률만을 유지하고 있습니다. 늘지도 줄지도 않고 있죠. 그러나 현재 이 유입을 통한 전환이 굉장히 높은 편이라 유입율 자체에 대한 아젠다는 생략하도록 하겠습니다.''대신 오늘은 브랜드의 이미지구축과 시각화를 위한 방안회의를 할 겁니다.'5. 용어정의를 내립니다. 다들 이 부분을 굉장히 간과합니다. 용어정의. 회의란 것은 기본적으로 한 가지의 주제를 여러사람이 생각하는 과정입니다. '이미지' 란 단어를 듣고 김대리는 "로고?" 라고 생각하고, 박팀장은 "소비자의 니즈?", 김실장은 "우리의 컨셉?" 등 각각 다른 그림을 떠올리고 생각한단 말이죠. 다 좋은데 이런 식이라면 다각적인 인사이트가 아니라 그냥 아무말대잔치가 되버리고 맙니다. 영역을 쪼개는 것이 아니라, 한 영역에 대한 다양한 시각을 모으는 것이 회의예요. "여기서 이미지. 라고 함은 시장이 아닌, 우리가 우리를 규정하는 1인칭관점을 의미합니다. 따라서 시장의 평가보단 우리 비즈니스를 우리 입으로 먼저 정의내리도록합니다. 이것은 텍스트, 비쥬얼 두 가지 방향으로 나눌 것입니다. 텍스트는 한 단어, 한 문장, 간단한 보일러플레이트 제작 이렇게 3가지로. 비쥬얼은 '키비쥬얼, 로고시스템, 브랜드패턴' 이렇게 3가지로 나누도록 하겠습니다."일단 소비자의 원함이나 서비스의 편의성등은 차치하고, 우리 입으로 말하는 우리 이미지부터 정확하게 규정하잔 것이 아젠다군요. 그렇다면 일단 내부의 결을 맞추는 작업이니 내부 인원들의 얘기를 한 번 들어봐야 겠네요.6. 의견을 개진합니다.의견 있는 사람?항상 여기에서 폭망입니다. '자, 의견 있으면 얘기해보세요.' 라고 하면 모두가 예상하는 바로 그 장면이 등장하죠. 인간의 사고는 프레임에 의해 움직입니다. 프레임이 없이 너무 큰 자유를 선사하면 기뻐서 우주로 사라져버리고 말죠. 적당한 제한사항과 프레임을 하나하나 규정해주는 것이 엄청 중요합니다. 그래서 회의 진행자는 담날 회의를 위해 철저하게 기획하고 운영안을 짜서 움직여야 되요. 그냥 모여서 얘기해야지...라는 개념이 아니라 소규모 사내 행사운영한다는 생각으로 타임라인별 멘트, 회의운영안이 필요하단 말이죠. 에이 뭘..그런 것까지!!!....라고 고개를 가로젓는 순간 어제의 회의가 앞으로도 영원히 복붙되고 말거예요."일단 우리 브랜드를 색깔로 한 번 묘사해볼까요? 각자 우리 브랜드는 어떤 컬러에 가까운 지 1분간 생각후에 얘기해보도록 해요."이렇게 미장센과 코드가 존재해야 해요. '색깔' 이라는 코드를 주면 사람의 사고는 빨주노초파남보 등으로 한정되기 시작하고 한정된 정보안에선 각각의 유사성과 대조점을 발견하기가 굉장히 쉽습니다. 함수관계와 비슷해요. 일단 정의역을 제공하고, 공역을 제공해야 대응관계를 만들어낼 수 있죠. 정보는 단일로 존재할 땐 쉽게 인식되지 않습니다. 항상 어떤 것과 연결된 '유기성'을 지니고 있을 때 의미를 갖죠. 사회자의 질문은 엄청나게 중요합니다.7. 쳐내고 모으고 나누고 곱한다.각각의 의견들이 책상으로 쏟아지면 누군가는 그것들을 모두 기록하면서 하나로 모으고 있어야 해요. 사람들은 생각보다 남의 의견을 잘 듣지 않습니다. 그리고 '말해보라' 라고 했지 '들어보라' 라고 하지 않았기 때문에 '내가 담번에 무슨 말을 할지' 에만 크게 집중하고 있는 상태입니다. 제3자 입장에서 그 회의를 관찰하는 사람이 있어주어야 합니다. 흔히 서기같은 사람이 가장 적합하죠. 텍스트로 그걸 변환하면서 정리를 하는 것입니다. 각각의 의견들의 공통점과 논외의 주장들을 구별하고 헛소리는 빼고, 공통적인 것은 묶고 반대의견은 따로 대립시키는 거죠. 그래서 크게 3가지 정도의 의견으로 압축시킵니다. 1가지는 너무 단편적이고 2가지는 택일의 상황을 유발합니다. 3가지는 서로 견제하는 느낌이고 4가지는 너무 안정적이예요. 5가지 이상부턴 복잡하고 많아보입니다. 3가지의 의견이 나오면 A,B그리고 어느쪽에 힘을 더 실어줄 C로 나누어지면서 지금의 여당,야당,3당과 같은 느낌의 균형이 맞추어지게 됩니다. 이렇게 3가지의 안으로 압축시킨 뒤 일단 쉬는 시간을 갖습니다. 이 작업은 20분 이내에 빠르게 쳐내는 것이 좋습니다.8. 쉬는 시간쉬는 시간은 회의를 하며 계속 그림을 그렸던 두뇌를 정리하고 생각들이 가라앉힐 텀을 주는 과정입니다. 대부분의 사람들은 말하면서 생각하기 때문에 자기가 말해놓고도 정리가 안되어 있거나 내가 무슨 말을 했는지도 모르는 경우가 많습니다. 이것들을 정리하는 것은 계속 생각하는 것이 아니라, 생각을 하지 않는 것이예요. 더도 말고 5분정도가 좋습니다.9. 의견선택눈치보지 말고 명확하게이제 의견을 선택합니다. 당연히 어떤 안이 선택되면 나머지 2개안을 냈던 사람들의 의견은 묵살되는 형태입니다. 이것에 대한 동의함과 설득의 과정은 반드시 필요합니다. 대신 질질 매달리기 보단 인정함과 합당한 이유를 설명해주는 것이 좋아요."아 나머지 두 개 의견을 내신 분께 죄송합니다..조금만 양해부탁드리고 힘들더라도 따라와주시면 감사하겠습니다.." 가 아닙니다. 이렇게 죄송, 힘들, 따라와, 감사해버리면 부탁도 아니고 뭣도 아니고 그냥 아무 따뜻한 말로 엿먹이는 느낌이예요. 차라리 이렇게 말합시다."나머지 두 개 의견은 매우 훌륭하였으나 현재 주어진 예산과 업무량의 여건상 우선 A안을 먼저 시행해보도록 하겠습니다. 추후 이 프로토타입이 괄목할 만한 성과를 내지 못할 경우 2안으로 B안을 택하도록 하겠습니다."감정적인 위로나 그런 군더더기 없이 합리적인 선택의 이유을 설명해주고 그럼 나머지 의견은 짬시킬건지 아니면 쌩깔건지 나중에 쓸 건지 등등을 정확하게 얘기해주는 편히 훨씬 인정받는 느낌입니다.10. 실무회의이제 업무분장을 합시다. 쪼개고 나누는 겁니다. 구체적인 실행단계를 만드는 일이죠. 이것은 앞서 2화 브랜딩, 일의 시작편 에서 설명했던 아래의 내용과 같습니다.01.   어떤 방식으로 전달할 것인가? – 채널, 방식, 제작방식, 시기, 기간, 컨셉 등02.   누가 얼마나 담당할 것인가? – 업무분장시작03.   PM은 BM과 제일 비슷한 성향의 기획자가.04.   기획 서포트는 반대 성향의 담당자가05.   중재자는 관찰자 성향의 담당자가06.   실행과 운영은 모험가형 2명이07.   검토와 트래킹은 사색가1명이08.   기획안 도출과 프로토타입 제작은 언제까지09.   리브랜딩 제작물과 디자인 작업은 언제까지10.   사내 전체 공유와 적용 시기는 언제부터11.   대외노출과 공표는 언제12.   유지와 운영 점검의 1차 지점은 언제까지13.   해당 업무에 대한 각 팀 별 세부업무 관리는 어떤 식으로14.   총 예산은 어느 정도15.   1차 랜딩이 끝난 후 2차 유지보수비(고정비)는 어느 정도 책정16.   책임과 권한 부여각각의 업무분장과 행동화과정에선 모든 업무의 목표와 평가지표가 오늘 나온 주제로 합치되어야 합니다. 이 과정에서 각각의 업무로딩을 파악하는 것은 매우 중요합니다. 특히나 브랜딩업무는 뭔가 일을 만들고 늘리는 것이 장땡이 아니므로, 현재 업무 중 오늘 업무를 함에 있어서 걸림돌이 되거나 또는 필요없거나 이관, 지연해도 상관없는 것들을 분류해서 업무가 +a 로 과중되지 않도록 신경써야 합니다. 대부분 이 작업없이 그냥 일을 만들어서 뿌리기만 하니까 "회의실 = 일 만드는 공장" 이 됩니다. 항상 무언가를 뿌릴 때는 총량유지를 생각해보시는 것이 좋을 듯 합니다.11. 정리/조율회의안을 정리하고 전체공유합니다. 이 때 회의안은 그 자체가 곧 '업무목표'가 되므로 업무결과보고의 제일 앞장에 위치하는 것이 맞습니다. 그리고 짧은 회의시간에 미쳐 다 하지 못했던 각자의 개인사정 및 업무역량에 대한 조율은 실무자간에 따로 담배 or 커피타임을 통해 옥상에서 따로 처리하도록  재량권을 주는 것이 더 효율적입니다. 일단은 이렇게 11단계로 정리를 해보았습니다. 추상적인 의견들만이 난무하는 브랜딩회의는 시간 대비 성과가 굉장히 조악해질 위험이 있습니다. 결국 말로 시작해서 말로 끝나는 것이죠.망한 결론회의는 생각으로 시작해서 말로 그리고 행동으로 끝나야 합니다. 이 방점을 제대로 찍지 못하면 끝나고 나서도 뭘 해야할 지 모르고 구슬피 한맺힌 사내 지박령처럼 이리저리 영혼이 떠도는 상태가 된단 말이죠.생각보다 회의는 굉장히 어렵습니다. 치밀한 기획이 있어야 하고, 사회자의 역량도 중요합니다.  늘 보던 얼굴이라고 하지만 얘기하는 주제가 달라지면 갑자기 낯설어지는 것이 또 회사라는 곳입니다. 적절한 질문과 운영방식을 찾아내기 위해 정말 수도 없이 고민해야 하는 것이 회의죠. 단순히 즐겁고 웃고 떠들며 앙버터 치아바타를 나눠먹는다고 수평적인 회의실의 모습이 만들어지는 것은 아닙니다. 적막하고 졸음만 가득한 회의실도, 아무말과 별 대책없이 끝나는 회의실도 둘 다 그다지 좋은 모습이라고 할 수는 없죠. 회의는 속이 시원해야 하고 모두가 머릿속에 각자 어떤 일을 왜 하는지에 대한 그림을 그리고 나와야 합니다. 그래서 사실은 브랜딩을 위한 회의...라고 얘긴했지만. 이 회의실안의 모습이야말로 우리 회사의 문화와 역량을 가장 적나라하게 보여주는 Inner Branding 그 자체라고 하는 편이 더 좋을 것 같습니다.
조회수 1788

iOS Graphic Interface 살펴보기 (1/2)

1.intro: 애정하는 iOS, 애증의 Xcode프론트엔드 개발자가 가장 기쁠 땐 언제일까요? 여러 가지가 있죠. 직접 만든 스무스한 애니메이션을 볼 때, 고생해서 작업한 하드코어 고난도 레이아웃이 잘 작동할 때, 작업한 화면을 사람들이 ‘예쁘다ʼ고 말해줄 때 등등. 그러므로 iOS는 모든 프론트엔드 개발자가 동경하는 OS라고 말할 수 있습니다. 대부분의 굵직한 Transition들을 알아서 Animate해주고, 프레임레이트가 복잡한 레이아웃 효과도 부드럽게 표현해주기 때문에 ‘예쁘다ʼ, ‘쾌적하다ʼ는 말이 절로 나오는 OS이기 때문이죠. 물론 그만큼 손도 많이 갑니다. 사실 iOS는 신기한 점이 많습니다. Xcode를 사용하다 보면 Interface Builder에서 ctrl+드래그를 사용하여 Code로 Reference를 가져오는 방법부터 String값으로 찾아가는 Xib/StoryBoard 파일까지.. 다른 플랫폼 및 IDE에서는 겪어보지 못한 새로운 경험들을 만나죠. 덕분에 다년차 개발자의 멘탈도 Xcode-iOS를 만나면 탈탈 털립니다. 시간이 지나면 이 독특하고도 불편한 Xcode를 사랑하고, 저주하는 상황까지 생깁니다.그래서 오늘은 많은 iOS 루키들이 겁내고 괴로워하는 iOS의 Graphic Interface를 살펴보고자 합니다. 맨땅에 헤딩할 때 헬멧이라도 쓰고 있으면 그나마 덜 아프니까요.2.Point, PixelAndroid에서는 다양한 기종의 스크린을 지원하기 위해 자체적으로 dp라는 수치 개념을 만들어 사용합니다. 파편화된 디바이스들을 모두 지원하는 레이아웃을 구성하려고 고안한 효율적인 방법이죠. iOS에도 이와 같은 개념이 있습니다. 바로 포인트(Point)인데요. Xcode의 ImageAsset 파일을 열면 이런 것을 찾을 수 있습니다. 1X, 2X, 3X바로 이 화면에서 볼 수 있는 1x,2x,3x라는 문구가 포인트 개념을 설명하고 있습니다. 포인트는 디바이스의 물리적 픽셀을 2배, 3배로 압축해 사용하는 iOS 만의 독특한 단위입니다. 이 개념이 처음 쓰인 건 iPhone 4, 즉 레티나 디스플레이가 등장하면서부터 인데요, 기존의 iPhone 3Gs와 물리적 화면 크기는 동일한데, 4배의 픽셀 수를 가지는 레티나 디스플레이에 기존의 앱들을 그대로 보여주자니 픽셀 단위로 정의된 기존의 모든 이미지/레이아웃이 절반 크기로 줄어드는 문제가 발생했습니다. 따라서 별도의 작업 없이 디스플레이하기 위한 방법으로 고안된 게 바로 포인트입니다.포인트는 픽셀을 2배, 3배로 압축해 1포인트라는 단위로 규정하고, 그 단위를 Nib(Xib) 에디터 및 개발 과정에서 사용합니다. 앞으로 여러분이 iOS 개발을 하면서 접할 기본 단위는 바로 포인트가 될 겁니다. 2X 혹은 3X는 단어는 픽셀을 2배, 3배로 압축했다는 의미입니다. 개발자의 편의를 위해서 만들어진 개념이 오히려 개발자에게 혼동을 주는 아이러니한 상황이 펼쳐졌습니다. 사실 이 픽셀-포인트의 개념이 처음 등장했을 때는 꽤 편리했을 겁입니다. 당시만 해도 iPhone4와 iPhone3Gs의 해상도를 구분하지 않고 작업할 수 있는 획기적인 방법이었으니까요. 하지만 지금은 iPhone5, iPhone7 Plus, iPhone X 등 다양한 장비들이 등장했습니다. 그래서 iOS 개발자는 포인트를 단지, 픽셀의 또 다른 이름처럼 느낄 뿐입니다. 애플도 자신들이 이렇게 다양한 해상도의 iPhone을 출시하게 될 줄은 몰랐을 겁니다.애플의 해상도 춘추전국시대 / 출처: paintcodeapp3.Storyboard, Nib (Xib)iOS UI 디자인의 꽃이 무엇인지 묻는다면 그것은 단연 Storyboard와 Xib일 것입니다. Storyboard는 기획자들이 사용하는 그것과 유사한 개념입니다. 하나의 큰 틀에 화면 단위로 여러 장의 기획안을 놓고, 그것들의 시퀀스를 한 눈에 알아볼 수 있도록 하는 보드입니다.Storyboard는 Segue와 같은 시퀀스 설정을 직접 할 수 있고, 연결된 하나의 Flow를 시각적으로 펼치기 좋습니다. 프로토타이핑을 위한 적절한 툴인 셈이죠.UIStoryboard 예시 - 브랜디 iOS의 Main StoryboardNib(혹은 Xib, 이하 Xib로 지칭)는 조각조각 단위의 화면이나 재활용을 많이 하는 CollectionViewCell 등의 화면 작업에 적합합니다. 이 점이 Storyboard와는 다르죠. (CollectionViewCell에 대한 자세한 포스팅은 여기를 클릭하세요.)물론 Storyboard에서 할 수 있는 작업은 대부분 Xib로도 가능하지만, 각각의 용도를 다르게 해서 사용하는 경우가 많습니다. 예를 들어, 브랜디 iOS 프로젝트는 Storyboard에선 큰 틀의 화면을 다루고, Xib에서는 CollectionView Cell과 ReusableView, Custom Component등을 다루고 있습니다. UICollectionViewCell.xibStoryboard와 Xib로 인터페이스 작업을 할 때는 파일의 컨텐츠가 너무 비대해지지 않도록 조심해야 합니다. Storyboard가 비대해지면 많은 작업자가 동시에 파일을 수정할 수도 있는데, VCS를 사용하면서 Storyboard나 Xib 파일의 충돌이 발생하면 병합하는 과정이 매우 고통스럽습니다. 그러므로 Storyboard는 서로 충돌하지 않도록 더 큰 그림을 그리고, 해당 Storyboard를 Senior 개발자가 관리할 수 있도록 안전장치를 두도록 합시다. 야 이거 소스 건드린 사람 나와 Storyboard와 Xib는 기본적으로 XML 기반의 파일입니다. 혹시라도 충돌이 발생하면 UI로 확인이 불가능하기 때문에, Xcode에서 해당 Storyboard, Xib 파일을 우클릭한 후 Open As > Source Code 메뉴를 클릭하면 XML 형식으로 브라우징할 수 있습니다. 해당 충돌 부분을 찾아가서 수정하고 다시 확인하면 UI로 볼 수 있습니다.소스코드로 스토리보드 보기4.From Storyboard, to CodeStoryboard와 Xib에서 구현한 컴포넌트들을 ViewController의 SourceCode에서 다룰 일이 분명 생길 겁니다(언제나 그렇죠). 그럴 땐 Outlet이라는 개념을 이용해서 Storyboard 와 SourceCode를 연결하는데요.네, 코드가 아닙니다. 포토샵하는 기분으로 ctrl + 마우스 좌클릭 드래그를 해주시면 됩니 다. 이 기능은 다른 IDE에서 보기 힘든 건데요. 나름 쓸만합니다. 익숙해지면 여러 가지 컴포넌트, 유닛들을 Outlet으로 처리할 수 있습니다. 코딩을 자유롭게 할 수도 있고요. 예를 들어, LayoutConstraint를 Outlet으로 처리하면 해당 Constraint를 코드 시퀀스에 따라 자유자재로 변경할 수 있게 되는 것처럼 말이죠.물론 이보다 선행되어야 할 작업은 Storyboard에서 해당 ViewController가 연결될 ViewController를 지정하고, 해당 ViewController의 파일을 미리 만들어야 합니다.5.Extraction of ViewControllerStoryboard에서 ViewController A를 연결했는데, ViewController B 에서 ChildViewController로 ViewController A 를 사용하고 싶다면 어떻게 할 수 있을까요? (간장공장공장장) 당연한 이야기지만 코드를 통해 구현 가능합니다. 필요한 것은 Storyboard 파일명과, Storyboard에서 미리 지정한 ViewController A 의 Identifier, 두 가지입니다. Storybo/rd에서 ViewController A를 연결했는데, ViewController B 에서 ChildViewController로 ViewController A 를 사용하고 싶다면 어떻게 할 수 있을까요? 당연한 이야기지만 코드를 통해 구현 가능합니다. 필요한 것은 Storybo/rd 파일의 이름과, Storybo/rd에서 미리 지정한 ViewController A 의 Identifier, 두 가지입니다. instantiateViewController From Storyboard/**  현재 화면에 디스플레이중인 UIWindow 객체로부터 UITabBarController를 반환받는 메  소드  - parameter window: UIWindow  - returns: UITabBarController */ fileprivate func tabBarControllerFromStoryboard() -> BRTabBarController {  let storyBoard = UIStoryboard(name: "mainStoryboard", bundle: nil let viewController = storyBoard.instantiateViewController(withIdentifier: "mainTabBarController") return viewController as! BRTabBarController  // 잘못된 viewController를 추출한 경우 nil exception } 비슷한 방법으로 Xib에 작성된 View도 추출할 수 있습니다. Xib파일 하나에 여러 View가 정의되어 있다면, 각각의 View를 필요에 따라서 사용할 수도 있습니다.Extraction From Xiblet nib = UINib(nibName: NSStringFromClass(BRDropdownSelector.self) let components = nib.components(separatedBy: ".").last!, bundle: nil) let view = components.instantiate(withOwner: nil, options: nil).last as! BRDropdownSelector  // 잘못된 view를 추출한 경우 nil exception 6.LayoutConstraints For Flexible UI더 유연한 레이아웃 동작을 원한다면, Static하게 선언된 수치보다는 LayoutConstraint로 제한적 범위 안에서 유동적으로 동작할 수 있도록 View를 주물러 주는 게 좋습니다. 예를 들어, 어떤 두 컴포넌트 사이의 최대 너비를 100으로 지정하되, 컨텐츠 사이즈에 따라 더 작아질 수도 있도록 하려면, LayoutConstraints의 Less than or Equal기능을 사용하는 것처럼 말이죠.Less than or equalLess than or Equal뿐만 아니라 Greater than or Equal도 존재합니다. 상황에 맞게 사용하는 지혜가 필요하죠. LayoutConstraint에는 Multiplier라는 개념도 있습니다. 만약 컴포넌트 A 절반 너비의 컴포넌트 B를 작성하고 싶다면, 그리고 이 조건이 화면 크기와 관계없이 동일하게 적용되기를 원한다면, 컴포넌트 B의 너비를 컴포넌트 A와 동일하게 Constraint로 지정하고, Multiplier를 0.5로 지정하면 됩니다. Multiplier는 단어 그대로 ‘배수ʼ라는 의미입니다.이처럼 화면 해상도에 구애받지 않는 유연한 UI를 작성하고 싶다면 LayoutConstraint 의 사용은 필수입니다. 브랜디 iOS 앱이 다양한 해상도의 iOS 디바이스에서 동일한 비율 로 출력되는 것도 이러한 LayoutConstraint를 사용했기 때문이죠.7.View를 핸들링할 그곳앞서 정리한 방식들을 사용해서 Storyboard, Xib 파일을 훌륭하게 작성했다면, 이제는 ViewController의 소스코드로 돌아올 차례입니다. View Size를 이벤트에 따라 변경하거나, 숨겼던 View를 보여주는 등의 작업들을 할 차례입니다.Storyboard나 Xib에서 작업한 View를 코드 상에서 다룰 일은 많습니다. 99.78% 이상 ViewController에서 View를 다루어야만 하죠. 무조건입니다.viewDidLoad() 에서 View는 대부분의 초기화 작업을 합니다. 그것은 소스코드를 다루는 개발자에게도 마찬가지죠. Storyboard에서 연결한 Outlet들도 이 Function에서부터 nil값이 아니게 됩니다. 따라서 뷰에 필요한 초기화 작업 (Button의 Title 지정, ImageView의 이미지 지정 등) 을 viewDidLoad()에서 모두 하면 됩니다. viewDidLoad()는 그 이름처럼 ViewController가 생성되었을 때 단 한 번 호출됩니다. 다시 거치지 않는 코드이기 때문에 ViewController에서 사용할 변수들을 초기화하는 등의 작업도 이 자리에서 할 수 있습니다. viewDidLoadoverride func viewDidLoad() {      super.viewDidLoad()     /* do 초기화 in 여기 */ } 다만 여기서 아무리 해도 안 되는 작업이 있습니다. View 사이즈를 해상도에 맞게 변경하는 작업 같은 것 말이죠. LayoutConstraint를 통해 지정된 사이즈를 가져올 때, 화면을 꽉 채우도록 Constraint를 지정해도 로그를 찍으면 엉뚱하게 더 적은 값 이나 큰 값이 나올 수도 있습니다. 이런 경우에는 아무리 viewDidLoad()에서 열심히 Constraint의 값을 가져와도 결과가 똑같을 겁니다.개미지옥override func viewDidLoad() {      super.viewDidLoad()     // 백년동안 코딩해도 화면 해상도가 다르게 나와요 } viewWillAppear() 에서는 viewDidLoad()에서 작동하지 않던(?) 코드를 적용할 수 있는 자리입니다. Constraint들로 지정된 사이즈들은 viewWillAppear()에서부터 각 디바이스의 해상도에 맞게 적용됩니다. 여기서부터는 화면 크기에 맞춘 SubView들의 사이징이나 Constarint들로부터 추출한 값이 의미가 있습니다.viewWillAppearoverride func viewWillAppear() {     super.viewWillAppear()     // 이제 아마 화면이 나올 차례인가봐요 } viewDidAppear()는 출력된 화면에 실행할 코드를 작성하는 자리입니다. 화면이 등장한 이후 보여줄 팝업창이나, 튜토리얼을 출력하는 건 여기서 해야 합니다. viewWillAppear()는 예상되는 출력 화면에서 호출되기 때문에, 실제로는 화면이 없는 상황에서도 호출될 수 있습니다. 만약 해당 viewController의 출력이 확실히 완료된 후 에 실행되어야 하는 이벤트라면, 이 Function에서 코드를 작성해야 합니다. viewDidAppearoverride func viewDidAppear() {     super.viewDidAppear()     // 화면 출력이 끝났답니다. 마음껏 코딩하세요! } 네, 지금까지 루키들을 위한 GUI 만들기의 기본 과정은 다 알려드렸습니다. 많은 개념과 기능, 방법론이 존재하지만 일단 이 정도면 알아도 첫 번째 iOS 앱 UI를 만들 준비는 어느 정도 마친 겁니다. 그럼 마지막으로 UI를 구성하면서 유용하게 사용할 수 있는 팁을 알려드리겠습니다. 8.Little Tricks1) Clip it, or not Clip it.ImageView를 다루다 보면 자주 발생합니다. 지정된 ImageView의 사이즈보다 이미지가 크면 이미지가 ImageView의 영역을 빠져나가버리는 건데요. 이것은 Label이나 View에서도 동일합니다. 작성한 컨텐츠가 부모 View보다 큰 경우 부모 View의 프레임을 벗어납니다. 이런 경우, 재부팅하세요. clipsToBounds 값을 true로 지정해주면.. view.clipsToBounds = true 매-직! 이 작업은 코드뿐만 아니라 Storyboard상에서도 가능합니다. Xib에서도 동일합니다. Storyboard에서 클리핑2)Circular View요즘 많이 사용하는 동그라미 모양 프로필 이미지 때문에 고생하는 고심하는 개발자들이 많을 겁니다. iOS에서는 이 작업을 view의 Layer를 편집하는 방식으로 아주 간단하게 처리할 수 있습니다.self.layer.cornerRadius = self.frame.size/2.0 self.layer.masksToBounds = true self.clipsToBounds = true 위의 코드를 사용하면 아래와 같은 이미지를 출력할 수 있습니다.둥글게 클립핑된 최신 트렌드의 ImageView를 간단하게 출력했습니다. 물론 위에서 언급한 clipsToBounds 값을 true로 지정해주는 것도 잊지 마시고요. 이 코드를 응용하면 모서리가 둥근 직사각형 뷰도 만들 수 있습니다. 원하는 곡률을 적용할 수 있죠. view의 Layer를 다루는 방법을 공부한다면 다양한 상황에서 유용하게 사용할 수 있을 겁니다.3)NSAtrributedString 클라이언트가 다양한 형태의 Font, Color의 텍스트를 한 문장에 넣어달라고 한다면 어떻게 작업해야 할까요? 스타일마다 Label 묶음을 만들어서 각각의 단어를 지정해주는 방법이 있습니다. 하지만 텍스트 또는 문장 구성이나 스타일이 서로 다른 묶음으로 변경된다면 어떨까요? 또 다시 새로운 기준으로 Label 묶음을 만들어야 할까요? 이럴 때 사용하기 좋은 녀석이 바로 NSAttributedString입니다. 볼드체, 보통체가 혼합된 텍스트에 색상이 다른 텍스트가 혼재되어 있는 Attributed String이렇게 다양한 형태의 텍스트를 한 문장에 담을 수 있고, 변경되는 내용이 있더라도 코드로 간단하게 수정하면 됩니다. 브랜디 앱에서도 NSAttrributedString을 많이 사용하고 있습니다. 브랜디 iOS 앱의 간지나는 UI 속 요소요소를 차지하고 있는 중요한 녀석이죠. 4)Debug Wirelessly 각종 케이블이 난잡하게 널부러진 책상을 보면 한숨이 나옵니까? 걱정하지 마세요. 이제 하나는 줄일 수 있을 겁니다. Xcode로도 무선 디버깅을 할 수 있기 때문이죠. 먼저 디바이스를 맥에 연결하고, Xcode가 활성화된 상태에서 Window > Devices And Simulators 항목을 클릭합니다. Devices and Simulators그런 다음 출력된 화면에서 원하는 디바이스를 선택하고 Connect via Network를 체크 합니다. (디바이스에 암호가 설정되어 있어야 합니다.) 지구본 모양이 디바이스 오른쪽에 있다면 무선 디버깅이 가능한 상태입니다. 무선디버깅체크9.Outro: 긴 글을 마무리하며아장아장 걸음마 시절이던 첫 개발 프로젝트 작업이 생각납니다. 클라이언트는 끝도 없이 요구를 하는데 구현하는 방법을 몰라 막막했던 적이 많았습니다. 여러 실수를 겪고 나서야 많은 것을 알게 되었죠. 그때를 생각하면 이제 막 iOS 개발을 시작하는 분들께 하나라도 더 도와주고 싶답니다. 지금 막 iOS 개발자가 되었나요? 그렇다면 이 포스팅은 분명 당신의 검색 한 번, 실수 한 번을 줄여줄 수 있을 겁니다.글이정환 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #iOS
조회수 2583

AWS 서비스를 활용한 Kubernetes 클러스터 구축 - VCNC Engineering Blog

Kubernetes 클러스터를 상용 환경에서 운영하기 위해서는 몇 가지 추가 구성요소를 설치해야 합니다. 예를 들어 Ingress를 만들더라도 실제로 트래픽을 받아줄 Ingress Controller를 설치해두지 않았으면 소용이 없습니다. 그리고 모니터링을 위해 컨테이너의 로그나 CPU/메모리 사용량 등을 수집, 조회할 수 있는 서비스도 필요합니다.다행히 이러한 추가 구성요소 또한 Kubernetes 클러스터 위에서 일반 애플리케이션과 거의 같은 방식으로 작동하므로 설치하는 것이 어렵지는 않습니다. 다만 클러스터를 원하는 대로 구성할 수 있는 만큼 선택의 폭이 넓어서 여러 가지 해법을 놓고 고민하게 될 수 있습니다. 이 글에서는 타다 서비스를 위해 Kubernetes 클러스터를 구성할 때 어떤 선택을 했는지, 특히 AWS 환경에서는 어떤 서비스들을 활용할 수 있는지 공유합니다.서비스를 외부에 노출: NGINX Ingress Controller + NLBIngress Controller 고르기Kubernetes에서 클러스터 내부 서비스를 외부에 HTTP(S)로 노출할 때는 Ingress를 사용할 수 있습니다. TLS 암호화, 로드밸런싱, 호스트명/경로 기반 라우팅 등을 제공해서 상당히 편리한데, Ingress가 실제로 작동하기 위해서는 Ingress Controller가 필요합니다.시중에는 다양한 종류의 Ingress Controller 솔루션이 나와 있습니다. 그중 Kubernetes 프로젝트에서 공식 지원하는 NGINX Ingress Controller와 AWS ALB 로드밸런서를 이용하는 AWS ALB Ingress Controller를 두고 고민을 했습니다.타다에서는 클라이언트(모바일 앱)에 실시간 이벤트를 전달하기 위해 gRPC를 사용하고 있어서 gRPC를 지원하지 않는 ALB는 선택할 수 없었습니다. 그리고 AWS ALB Ingress Controller는 현재 Ingress 하나마다 ALB를 1개 생성하는 구조여서 앞으로 노출할 서비스 수가 늘어난다면 비용 효율이 떨어진다고 판단했습니다. 따라서 NGINX Ingress Controller를 선택하게 되었습니다.NGINX Ingress Controller는 NGINX 웹서버를 기반으로 하므로 gRPC 모듈을 비롯하여 다양한 NGINX 모듈을 통해 굉장히 세세한 부분까지 설정할 수 있습니다. NGINX Ingress Controller는 Ingress나 Ingress가 가리키는 서비스의 엔드포인트에 변화가 생길 때마다 동적으로 NGINX 설정을 업데이트하는 방식으로 동작합니다.NGINX Ingress Controller 로드밸런싱NGINX Ingress Controller를 사용해도 외부에서 오는 트래픽을 적절히 분배해 줄 외부 로드밸런서는 필요합니다. AWS의 로드밸런서는 Classic ELB, ALB, NLB가 있습니다. 앞서 설명했듯이 ALB는 gRPC를 지원하지 않아서 Classic ELB를 TCP 모드로 사용하거나 NLB를 사용해야 합니다. Classic ELB는 동시에 많은 연결을 처리하려면 웜 업이 필요한 단점이 있어 NLB를 사용하기로 하였습니다.최근 NLB가 TLS termination을 지원하기 시작했지만, HTTP/2와 gRPC를 사용하기 위해 필요한 ALPN 정보를 설정할 수 없어서 NGINX 수준에서 TLS 암호화를 처리하고 있습니다. NLB 수준에서 TLS 처리를 하면 무료로 자동 갱신되는 ACM 인증서를 사용할 수 있는 등 여러 가지 이점이 있어서 아쉽습니다.Kubernetes에서 LoadBalancer 타입의 서비스를 생성하면 알아서 AWS 로드밸런서를 만들어줍니다. 하지만 이렇게 해서 NLB를 생성하는 방식은 아직 알파 기능입니다. 따라서 먼저 NodePort 타입의 서비스를 생성하여 모든 노드의 특정 포트에 NGINX를 노출한 다음, 별도로 생성한 NLB에 노드들이 속한 오토스케일링 그룹을 연결해주는 방식으로 직접 설정하게 되었습니다.정리해보면 외부에서 오는 트래픽을 처리할 때는 다음과 같은 과정을 거칩니다.모든 서브도메인(*.tadatada.com)은 NLB를 가리킵니다.NLB의 443 포트로 암호화된 HTTP 또는 gRPC 요청이 들어옵니다. NLB는 적절한 Kubernetes 노드 중 하나의 특정 포트(예: 30000번)로 요청을 전달합니다.Kubernetes 노드에서는 포트 번호를 보고 NGINX 서비스로 향하는 요청임을 알 수 있고 NGINX 컨테이너 중 하나로 요청을 전달합니다.NGINX는 복호화를 한 다음 HTTP Host 헤더를 확인하여 요청을 전달할 Ingress를 알아냅니다. 그리고 해당 Ingress의 엔드포인트 중 하나로 복호화한 요청을 프록시합니다.애플리케이션 컨테이너가 요청을 처리합니다.트래픽 흐름: NLB → NodePort → NGINX Ingress Controller → 내부 서비스Pod에 IAM 역할 부여: kube2iamS3, SQS 등 IAM으로 인증하는 AWS 서비스에 접근하려면 인증 정보가 필요합니다. EC2에서는 액세스 키를 직접 넣는 대신 EC2 인스턴스 프로파일로 인스턴스에 IAM 역할을 부여할 수 있습니다. 하지만 하나의 Kubernetes 노드 (=EC2 인스턴스)에는 여러 Pod이 실행될 수 있기 때문에 Pod마다 다른 IAM 역할을 부여하기를 원한다면 인스턴스 프로파일을 활용할 수 없게 됩니다. (인스턴스 프로파일에는 하나의 IAM 역할만 부여 가능)kube2iam을 사용하면 다음과 같이 Pod 어노테이션으로 IAM 역할을 지정할 수 있습니다.apiVersion: v1 kind: Pod metadata: name: aws-cli labels: name: aws-cli annotations: iam.amazonaws.com/role: role-arn spec: ... 설치나 사용법은 문서를 참고하면 어렵지 않은데, 원리를 간단히 설명해 보겠습니다. EC2 인스턴스 안에서는 특정 IP 주소(169.254.169.254)로 접속하면 EC2 메타데이터 API에 접근할 수 있습니다. AWS SDK는 EC2 메타데이터 API를 통해서 인스턴스 프로파일에 붙은 IAM 역할과 IAM 역할에 해당되는 액세스 키 쌍을 받아오게 됩니다.kube2iam은 모든 노드에 실행되면서 Pod 내부에서 EC2 메타데이터 서버 주소로 나가는 모든 요청을 가로챕니다. 그리고 인스턴스 프로파일 정보와 액세스 키 발급 요청을 kube2iam 서버가 대신 처리합니다. 따라서 Pod 안에서는 인스턴스 프로파일이 부여된 EC2 인스턴스 내부에 있는 것처럼 느껴지게 됩니다.추후 AWS SDK에 EKS 지원이 추가되면 별도로 데몬을 설치하지 않고도 Pod에 IAM 역할을 줄 수 있게 될 것으로 보입니다.로그 수집: fluentd + CloudWatch LogsKubernetes의 컨테이너가 stdout/stderr로 출력하는 로그는 노드에만 쌓이고 컨테이너를 재시작하거나 삭제하면 함께 삭제됩니다. 또한 노드의 디스크가 꽉 차는 것을 방지하기 위해 일정 크기를 넘으면 오래된 로그는 없어집니다. 그러므로 로그가 사라지지 않도록 계속 어딘가에 모아두어야 합니다.AWS에서 활용할 수 있는 로그 저장 서비스에는 CloudWatch Logs가 있습니다. fluentd를 DaemonSet으로 노드마다 하나씩 실행해서 컨테이너 로그를 CloudWatch Logs로 전송할 수 있습니다.CloudWatch Logs에 저장한 로그는 최근 나온 CloudWatch Logs Insights로 검색, 분석할 수 있습니다. 아직 나온 지 얼마 되지 않아서 기능이 많지는 않지만, 간단히 조회하는 용도로는 충분합니다.CloudWatch Logs Insights 사용 예모니터링: PrometheusEC2 인스턴스 하나에 서비스 하나를 띄워서 사용할 때는 CloudWatch로 CPU 사용률 등의 지표를 측정할 수 있었습니다. 하지만 Kubernetes를 사용하면 여러 서비스가 하나의 인스턴스에서 동시에 실행될 것이므로 인스턴스 수준의 지표는 무의미합니다. 특히 최소 실행 단위인 컨테이너 수준의 CPU 사용률 같은 값을 측정해야 하는데, CloudWatch를 사용하기에는 과금 체계가 적합하지 않습니다.기본 제공되는 5분 간격의 EC2 지표는 무료지만 CloudWatch에 커스텀 지표를 올리게 되면 지표 당 비용을 지불해야 합니다. 이 때 '지표'는 지표 이름 + 고유한 차원(dimension)의 조합입니다. 예를 들어 CPUUtilization이라는 이름의 지표가 PodName=server-aaaaaaaa과 PodName=server-bbbbbbbb라는 다른 차원으로 올라온다면 각각을 다른 지표로 취급합니다. 따라서 지표 수가 너무 많아지지 않게 조정해야 하는데 그러면 상세하게 모니터링하기가 어렵습니다.비용 문제도 있고, Kubernetes의 여러 가지 정보를 CloudWatch로 내보내는 기존 도구가 없었기 때문에 다른 방법을 찾아보게 되었습니다. 그래서 Kubernetes 모니터링을 위해 많이 사용하는 Prometheus를 선택했습니다. Prometheus를 온전히 사용하기 위해서는 다양한 컴포넌트들이 필요한데, Prometheus Operator Helm 차트를 사용하면 비교적 쉽게 구축할 수 있습니다.Prometheus는 Kubernetes 클러스터 모니터링 외에 애플리케이션 모니터링에도 사용할 수 있습니다. 타다의 애플리케이션들은 Spring Boot로 작성되어 있는데 Spring Boot Actuator와 Micrometer의 Prometheus 지원을 사용해서 애플리케이션 수준의 지표도 Prometheus로 모니터링하고 있습니다. 특히 Prometheus Operator를 사용하면 모니터링 대상을 추가할 때 Prometheus 설정 파일을 수정하지 않아도 Kubernetes에 ServiceMonitor 리소스를 등록하기만 하면 되어서 편리합니다.Prometheus로 수집된 지표는 Grafana 대시보드로 시각화하고, 정해진 조건에서 Alertmanager를 통해 PagerDuty와 Slack에 알림을 보냅니다.Grafana 대시보드의 모습자동 처리량 확장: Cluster AutoscalerKubernetes에서 자동 처리량 확장은 크게 두 종류로 나눌 수 있습니다. 먼저 Horizontal Pod Autoscaler로 CPU, 메모리 사용량에 따라 Pod의 수를 자동으로 조정할 수 있습니다. HPA가 실제로 동작하기 위해서는 오토스케일링을 위한 지표를 제공하는 Metrics Server를 설치해야 합니다. 그런데 부하가 증가해서 HPA가 Pod 수를 늘리려고 할 때 워커 노드에 여유가 충분하지 않으면 새로운 Pod을 실행할 수 없어서 소용이 없습니다. 이 때 워커 노드의 수를 자동으로 조정해주는 것이 Cluster Autoscaler입니다. Cluster Autoscaler는 노드 수를 증가시키기만 하는 것이 아니라 여유가 생겼을 때 노드 수를 자동으로 줄여서 불필요한 비용이 발생하지 않도록 해줍니다.AWS 환경에서 Cluster Autoscaler는 EC2 API를 통해 EC2 오토스케일링 그룹의 Desired Capacity 값을 필요한 노드 수로 조정하는 방식으로 작동합니다. 따라서 Cluster Autoscaler에는 EC2 API를 호출할 수 있는 IAM 권한을 주어야 합니다. 이를 위해 위에서 소개한 kube2iam을 사용할 수 있습니다. 그리고 Cluster Autoscaler가 오토스케일링 그룹을 자동으로 발견할 수 있도록 미리 정해진 태그를 붙여야 합니다.한 가지 주의할 점은 노드의 오토스케일링 그룹이 여러 가용 영역(AZ)에 걸쳐있으면 안 된다는 것입니다. 오토스케일링 그룹이 여러 AZ에 속한 경우 AZ 간 인스턴스 수의 균형을 맞추려고 하는데 이 과정에서 인스턴스가 예기치 않게 종료될 수 있습니다. 이 때 해당 노드에 실행되어 있던 Pod이 안전하게 종료되지 않을 수 있기 때문에 AZ마다 오토스케일링 그룹을 따로 만들고 AZ 간 균형은 Cluster Autoscaler가 맞추도록 설정해야 합니다.도움이 되는 링크들위에서 소개한 컴포넌트들은 다음과 같은 Helm 차트를 통해 설치해서 사용하고 있습니다.stable/nginx-ingressstable/kube2iamincubator/fluentd-cloudwatchstable/prometheus-operatorstable/metrics-serverstable/cluster-autoscalerEKS Workshop: AWS 환경에서 Kubernetes 운영할 때 참고할 만한 정보가 많이 있습니다.Kubernetes Slack 채널: #eks 채널에는 AWS 직원들도 접속해 있어서 높은 확률로 답변을 받을 수 있습니다.
조회수 1852

우리는 비정상인걸까?

필자는 스팀헌트라는 스팀 블록체인 기반 댑 프로젝트를 진행하고 있다. 스타트업을 하면서 저마다의 관점과 철학이 다른 문제이겠으나, 내가 지금까지 약 1년간 경험해본 이놈의 "블록체인"이라는 업계는 뭔가 정상적이지 않다. 그간 나름 "스타트업"이라는 업계 전반의 경험에 비추어 봤을때 이바닥 관행들이 뭐가 내게는 비정상적으로 보이는지 간략히 살펴보면 다음과 같다.1.대부분의 "블록체인" 태그를 달고 나오는 프로젝트들은 가장 처음 하는 일이 펀딩이다. 아직 제품은 커녕 그냥 프로젝트 소개하는 랜딩페이지에 수십명의 팀원, 어드바이저 리스트, 현실성이 있을까 싶은 각종 기업 로고들이 파트너사로 나열되어 있다.2.그들에게 "제품"이란 마치 수십 수백페이지의 엄청난 공을 들인 "화이트페이퍼"인듯 하다. 왜냐하면 위에서 얘기한 랜딩페이지 맨 위에 항상 가장 대문짝 만한 자리를 차지하고, 이미 3개국어는 기본, 5개국어 버전까지 준비해 놨기 때문이다.3.이런 제품도 없고 요상한 랜딩페이지만 있는 프로젝트들이 수십, 수백억의 ICO, IEO, 프라이빗 세일 등등의 단어로 치장된 "토큰 세일"을 진행한다. 이들이 초기에 들이는 자원중 99% 이상은 카톡방 관리, 텔레그램방 관리, 코인판 (사이트 이름이다) 마케팅, 각종 밋업, 컨퍼런스 참여, 유투버들 마케팅 등등이다. 물론 이런 행동들은 성공적인 펀딩을 위해 필요한 일들이긴 하다. 다만, 일반적인 스타트업이라면 초기에 99%의 자원이 제품과 유저들에게 쏟아야 마땅한 단계에 그게 아니라는게 내겐 비정상적인걸로 보일 뿐.4.아직 제품도 없는 팀이 팀원 리스트를 꾸린걸 보면 거의 중견급 스타트업 레벨이다. 아직 유저도 없고 비즈니스도 없는 팀이 CEO, CTO, CMO, CSO, C.... 레벨이 5명은 기본, 개발자 5-6명을 리스트에 박아놓는다. 일반적인 스타트업에서는 MVP가 어느정도 검증되고 나서 스케일을 낼때 하는 일들이다. 마치 삽도 뜨기 전에 삽질할 사람들 수십명을 모아놓은 그림이다. 이 중 십중팔구는 삽을 뜨려고 보니 땅바닥이 콘크리트 바닥이라 팔 수가 없거나, 애초에 팔 의지도 없었던게 대부분이지만...5.어드바이저 리스트... 내가 가장 요상하게 여기던 관행인데, 어느 프로젝트를 들어가도 이력이 화려해 보이는 어드바이저들 5명 이상은 기본으로 갖고 들어가더라. 내가 맨 처음 이바닥 들어갈때는 나름 "뭐, 아무도 가본 길이 아니니 조언해줄 사람들이 많이 필요할수도 있겠지.."라고 착각했었다. 알고보니, 그들은 그저 위에 자리를 채워주는 역할과 아주 약간의 투자자+거래소 인맥을 소개시켜주는 역할을 하는 사람들이더라. 이렇게 이름만 팔아주고 대부분 총 발행량의 0.5 ~ 2, 3%까지 토큰을 받아가는데, 대부분 상장과 함께 가장 먼저 덤핑될 토큰들이라는게 업계의 공통된 시각이다. 사실, 이 바닥이 그리 넓지 않아서 거래소 인맥 소개시켜주는건 인맥이 넓으신 1-2명으로도 충분히 커버 가능하다. 아예 제대로된 엑셀러레이터 들어가면 그들이 백배는 더 전문적으로 잘 해주는 영역이기도 하다. 아무리 생각해도 삽도 안떠본 스타트업이 저 많은 어드바이저 리스트를 꾸려야 할 이유를 지금도 못찾았고, 앞으로도 모를것 같다.6.지금이야 STO니 해서 증권형 토큰들이 하나둘씩 나오지만, ICO하는 대부분의 코인들은 본인들이 "유틸리티" 코인이라고 주장한다. 뭐, 토큰 모델 디자인상 유틸리티 토큰일 수 있다. 그런데 문제는, 이를 배포할 때 초기 토큰 홀더들은 100% "투자자"라는데에 있다. 그들이 주장하는 토큰의 유틸리티, 유저 페르소나와 1도 관계 없는 사람들이 대부분 토큰을 갖게 되고, 시장 상장 후 차익 실현을 위해 보유하는 경우가 거의 백프로다. 마치 사탕 사먹으라고 발행한 백원짜리 동전을 손에 쥔 백명의 사람들이 사실 사탕 사먹으려는게 아니고 모두 이백원, 삼백원에 팔기위해 손에 쥐고 있는것과 같은 논리다. 이러니, "유틸리티" 토큰이라는게 작동할리가 없다.7.백서... 어드바이저와 함께 내가 가장 요상하게 여기는거다. 대부분의 프로젝트가 삽도 뜨기 전에 수십, 수백장짜리의 백서부터 쓴다. 읽어보면 완전 세상을 바꿀 의지가 넘쳐 흐르는 철학적 도입부 + 본인들의 기술이 세상에 없던, 혹은 현존하는 기술은 거의 쓰레기 수준이라는 설명 + 삽도 떠본적 없는데 3-5개년 중장기 계획이 세워져 있고, 3년후에는 이미 이 시장을 평정해 있는 이야기들로 점철되어 있다. 제품도 없고 유저도 없는 상태에서 쓰여지는 수십페이지짜리 백서라는건, 그냥 대학교에서 팀플 리포트 A학점정도 맞을 만큼 잘 써진 그냥 소설 페이퍼정도인데, 이걸 무슨 신주단지마냥 만들어서 돌리는지 도무지 이해할수가 없다.8.투자자 생태계가 진짜 엄청나게 요상하게 꾸려져 있다. 일반적인 스타트업에서 보통 시드펀딩을 위해 VC들을 만나보면, 그들은 이 제품이 진짜 어떤 문제를 해결중인건지, 그 문제 해결에 열광하는 유저들이 얼마나 존재하는지, 이게 스케일이 가능한 형태인지, 스케일 했을때 시장규모가 얼마나 될건지, 이놈들이 그중 얼마나 먹을 수 있는 팀원들인지... 보통 이런걸 본다. 이런걸 봐야 나중에 스케일에 성공해서 엑싯이 되든 상장이 되든 해서 투자 수익을 얻을 수 있기 때문이다. 한편, 이바닥 투자자들이 가장 중요시 여기는 것들을 나열해 보면 다음과 같다.1) 백서가 얼마나 있어빌리티하게 작성되어 있는지 (본인들이 잘 모르는 개념들이 잔뜩 들어가 있을수록 높은 점수를 받는다)2) 흥행성 - 이 프로젝트가 얼마나 "호재"를 잘 타서 토큰 가격 펌핑이 가능한 구조인건지. 파트너사들, 각종 MOU, 화려한 이력이 있는 팀, 어드바이저 등등이 보통 활용된다.3) 토큰 분배 - 프라이빗 세일에서 디스카운트 먹은 투자자들 규모가 얼마나 되는지, 팀/어드바이저들은 얼마를 던질 준비가 되어 있는지4) 토큰 상장 - 소위 "대형" 거래소에 처음부터 상장될건지, 얼마나 많은 거래소에서 유통될건지...이 어디에도 "제품"이나 "유저"와 관련된 내용은 하나도 없다. 즉, 투자자들이 진짜 그들 제품의 성공 가능성에 대해 점쳐보며 투자할 분위기도, 그럴 생태계도 아닌게 이 판이다.9.원래 비트코인도, 이더리움도, 이런 탈중앙화 퍼블릭 블록체인 프로젝트의 강점은 오픈소스 프로젝트라는데에 있다. 모든 소스코드가 깃헙에 투명하게 공개되어 있고, 누구나 개발에 기여할 수 있다. 그런데, 이 후에 쏟아진 수 많은 블록체인 프로젝트들이 개발이 이루어지지 않거나, 본인들 소스코드는 비공개라고 하는 경우가 허다하다. 심지어 깃헙 링크가 아예 없는 프로젝트도 수두룩 하다.10.글로벌 프로젝트라는데 물론 아직 "글로벌" 유저도 없고, 레딧이나 트위터 등의 활동도 전무하고, 공식 커뮤니케이션 채널은 카카오톡 오픈챗이나 텔레그램 채널이란다. 가끔 싱가포르나 어디 글로벌 컨퍼런스에서 머리 노란 사람들과 사진 몇방 찍고 이걸 블로그나 신문기사로 찍어내면 글로벌 프로젝트가 되는 분위기다.이렇게 요상한 관행들이 어떤 결과를 가져왔는지 한번 살펴보자. 뭐, 가격 폭락하고 거품 빠지고... 이딴걸 얘기하려는게 아니다. 일반적인 스타트업 업계에 비해 이바닥의 현 성적표가 얼마나 초라한지를 보는거다.1. 전체 ICO의 78% 이상은 스캠으로 판명, 7%는 실패하거나 프로젝트가 사멸하였다 (블룸버그).2. 가장 큰 네트워크 규모를 자랑하는 이더리움 블록체인에서 돌아가는 1,375개의 댑 (DApp - 블록체인에서 돌아가는 앱을 뜻하는 단어)들 중 86%는 유저가 단 한명도 없으며, 93%는 아예 온 체인 트랜잭션이 단 한 건도 발생하지 않은 댑이다 (크립토글로브).3. 이더리움 지갑 보유자 전체의 고작 2%만이 이더리움 댑을 사용하는 유저이다 (dapp.com)4. CoinGecko에 리스팅 되어 있는 전체 4,139개의 프로젝트 중 과거 30일 동안 단 한번이라도 개발 커밋이 이루어진 프로젝트는 단 64개 밖에 없다 (2019년 2월 28일 기준).이걸 스타트업 상황에 비교해서 설명해보면 이렇다.전체 스타트업 중 78%는 사기를 쳤고, 7%는 삽도 못떠보고 망했다. 86%는 유저를 1명도 못만들었고, 93%는 유저는 있는데 유저들의 사용 이력이 1도 없다. 특정 운영체제를 쓰는 스마트폰 보유자들의 고작 2%만이 실제 앱 스토어에서 앱을 다운받아 사용하는 유저이다. 전체 스타트업 중 고작 1.5%만이 과거 30일동안 단 한번이라도 개발 커밋이 이루어졌다. 정말 요상하지 않는가? 그런데 더 충격적인건... 이걸 요상하게 여기는 우리 팀이 더 비정상이라고 보는 이 업계 시각이다. 내가 하는 스팀헌트라는 프로젝트에 대해서는 다음 글에서 상세히 소개할 예정이지만, 우리는 처음에 제품부터 만들어서 유저를 모으고, 가설을 검증하고, 사업모델을 모색하고... 그 다음 펀딩을 추진하는, 지금까지 스타트업에서 있었던 아주 일반적인 트리를 타고 있었다.백서? 물론 없었다. 제품 운영도 안해보고 저런 소설을 내 스스로 쓰는거에 대한 오글거림도 있었고, 솔직히 수만명의 커뮤니티 유저들을 상대하다 보면 그런짓에 시간을 쓸 여유도 없었다.웹사이트에는 그냥 이렇게 끄적여 놨었다...ㅎㅎ그런데, 우리는 아주 일반적인 단계라고 여기며 요즘 펀딩을 준비하고 있는데, 거의 모든 관계자들이 그놈의 "백서"를 요구한다. 제품부터 열어봅시다, 유저부터 한번 봅시다 하고 말꺼내는 사람들이 거짓말 안보태고 10에 1명 찾아볼까 말까였다. 우리도 얼마전까지는 "우린 그런 소설책 쓸 시간이 없어요~~" 이랬었는데... 결국 우리도 백기를 들고 일주일만에 백서를 써버렸다. 근데 사실 써보고 나니, 우린 제품도 1년이나 운영하면서 나름 가설 검증을 많이 해 놓은 단계라 그런지 백서가 쉽게 써지긴 하더라. 로드맵도 3-5년 후 이야기는 있지도 않다. 1년 앞에 어떻게 될지 모르는게 일반적인데 굳이 3-5년후를 쓸 가치를 못느낀다.사실, 위에서 소개한 뭔가 이 바닥에서는 "비정상"처럼 여겨지는 일반적인 스타트업들이 타는 트리를 타고 있는 블록체인 프로젝트들이, 스팀헌트가 만들어진 스팀 블록체인에는 수두룩하게 많다. 아니, 스팀에서는 오히려 위에서처럼 백서만 들고와서 펀딩하는 프로젝트들을 더 까는 경향이 있다.스팀이 코인의 시총만 따지면 40-50위권 수준이라 유명새를 타지 못한 상태이지만, 그 블록체인을 기반으로 움직이는 60여개의 댑들은 이미 실제 유저들을 어마어마하게 거느리고, 이더리움이나 EOS마냥 메타마스크나 스캐터를 깔지 않으면 로그인조차 할 수 없는 상태가 아닌, 일반적인 앱을 쓰는것과 동일한 UX에 모바일에서도 100%로 돌아간다. 코인판의 수 많은 사람들이 거래소에서 pump and dump에만 열을 올리고 있는 사이 스팀에서는 실제 소셜 앱들을 만들기 위한 스타트업 다운 스타트업 생태계가 만들어지고 있던 거다.출처 - https://stateofthedapps.com (2019년 1월 7일 기준)https://stateofthedapps.com라고, 이더리움, EOS등 2,500개 이상의 댑들의 유저수, 트랜젝션을 기반으로 순위를 매기는 공신력 있는 사이트가 있다 (무슨 돈만내면 별점 매겨주는 ICO레이팅 그딴 사이트가 아니다). 거기 차트에 들어가보면 이미 스팀기반 댑들이 상위권을 차지하고 있다. 스팀헌트도 항상 상위 10-20위사이에서 왔다갔다 하면서 최상위권을 유지중이다. 또한, 대부분이 도박, 게임등인 이더리움/EOS와는 달리 스팀기반 댑들은 소셜 서비스라는게 엣지이다. 스팀헌트 역시 테크 얼리어답터들의 "커뮤니티" 플랫폼이다.오늘을 기점으로 다시 브런치 활동을 시작하려고 한다. 내가 직전에 연재하던 시리즈가 "기획돌이의 스타트업 고군분투기"였는데, 이건 일반적인 스타트업에서 좌충우돌하던 깨달음에 대한 글들이였다면, 오늘부터 연재할 글들은 이 "비정상"이 "정상"처럼 여겨지는 블록체인판에서 내가 스팀헌트 프로젝트를 운영하면서 겪게되는 좌충우돌에 대한 이야기들을 소개할 예정이니, 많은 관심과 구독 부탁드린다.글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기
조회수 4599

시작하는 사람들을 위한 특별한 점심약속

뜨거운 여름 오후, ZOYI 사무실에서 폭염보다 뜨거운 토론이 벌어졌다.‘채널팀 신입 개발자 ‘후드'의 닉네임의 의미는 뭘까?’세상 기발한 추측들이 쏟아져 나왔다. 로빈후드, 패스트후드, 후드티, 후드득, 후드리챱챱, 후드염(?)까지...다양한 추론드립들로 화이트보드가 꽉 차버렸다사무실에서 이런 (우리끼리만) 재밌는 놀이를 하게 된 건 ‘웰컴런치보드 (Welcome Lunch Board)' 가 생긴 후부터다. 신규 입사자와 점심 약속을 조율하기 위해 화이트보드를 활용하기 시작한 것이다. 생긴지 몇 달 되지 않았지만, ZOYI 사무실에 놀러왔다가 아이디어가 맘에 들어 내부에 도입한 회사도 생겼다고 한다. 장난으로만 가득해보이는 이 게시판은 어떻게 탄생했을까.역삼동 프리덤🤟ZOYI는 근무 분위기가 자유로운 편이다. 업무 능률을 높일 수 있도록 출퇴근 시간이 꽤 탄력적이며 부분적인 원격 근무도 가능하다. 쉬는 시간이면 탕비실 소파에 앉아 수다를 떨고, 팔굽혀펴기를 하기도, 기타 치며 노래를 하기도 한다.요즘 핫한 팔굽혀펴기 소모임(?)🏋🏻‍♀️ 활동중여유가 있을 땐 보드게임 한판 🎲누구나 시작은 어려워즐겁게 함께 어울리는 분위기가 ZOYI의 매력이지만, 신규 입사자 분들과 이야기하다 보니 이 자유가 조금 불편하게 느껴질 수 있다는 사실을 발견했다. 너무 자유로워서 점심시간에는 언제 엉덩이를 떼고 일어서야 할지도 모르겠고, 이미 친하게 지내는 기존 멤버들 사이에 갑자기 끼어들기도 어색하단 것.끄잉 부끄러...우리의 따뜻한 분위기가 이런 소외감을 낳을 수 있다니! 물론 혼자서 시간을 보내는 게 더 편한 사람들도 있지만, 자발적인 아싸와 인싸가 되지못한 아싸는 다른 법.운영팀 회의시간, 고민이 시작되었다. 어떻게 하면 신규 입사자들이 자연스럽고 즐겁게 회사에 적응할 수 있을까?운영팀 멤버 중 가장 최근에 입사했던 나의 경험을 회고하며 함께 실마리를 풀어 나가 보았다. 나 또한 ZOYI에서의 처음이 있었지만 적응이 크게 어렵진 않았다. 회사 안의 모든 팀과 두루두루 일을 하게되는 운영팀 특성상, 초반에 미리 다양한 팀원들과 점심 약속을 잡아 두었던 운영팀 동료들의 배려가 있었기 때문이다.입사 초기 1~2주간 나의 캘린더는 점심 약속으로 든든하게 채워져 있었다. 그 시간 동안 함께 밥을 먹으며 발견한 사소한 공통점이나 이야깃거리는 관계가 자라는 씨앗이 되었고, 잠깐이라도 얼굴을 익혔던 시간이 빠르게 회사에 적응하는 데 큰 도움이 되었다.반겨주셔서 감사합니다 (꾸벅)(_ _)밥이 답이다밥 얘기를 나누다보니, 신규 입사자의 어려움을 해결할 실마리가 보였다. 다른 신규 입사자들도 초반에 이와 같은 경험을 한다면 좀 더 편안하게 회사에 적응할 수 있지 않을까 하는 생각이 들었다. 일주일 정도, 회사가 신규 입사자와 함께 식사하는 사람들의 점심 식대를 지원해 주면 좋지 않을까? 그렇게 회사에서 신규 입사자의 일주일 약속을 미리 잡아주는 '웰컴런치(Welcome Lunch)'가 시작되었다.실행, 또 다른 고민신입 멤버를 환영하며 함께 식사하는 일주일(게다가 법카 지원도 된다!), 마다할 이유가 있을까? 하지만 기대와 달리, 예상치 못한 문제들이 발견되었다.우리는 웰컴런치 일정 조율을 호스트(신입 멤버가 회사에 잘 적응할 수 있도록 돕는 멤버) 멤버에게 요청했었다. 호스트가 다른 팀 멤버들과 일주일 간 점심 약속을 짜도록 한 것이다. 하지만 이렇게 하자 업무가 많았던 개발팀의 한 호스트 분이 부담감을 표출했다. 생각보다 일일이 점심약속을 잡는 것이 어렵다는 것이다.점심약속을 잡는게 이렇게 힘들 줄이야비즈팀에서도 설득력있는 이유(?)를 들고왔다. 자고로 비즈니스맨이라면, 동료들에게 먼저 연락하고 친해지는 것도 능력이라는 것이라 말했지만 역시나 호스트가 스케줄 짜는 데 부담을 느끼는 듯 했다.피드백을 받으니 내심 서운한 맘이 들었다. 함께 일할 동료를 환영하자는데, 이렇게 협조를 안해주다니!. 하지만 운영팀 동료들의 반응은 달랐다. 아무리 좋은 취지의 제도라도, 누군가에게 강요를 하거나 스트레스를 주면 지속가능한 제도가 될 수 없다(단호박)는 거였다.다시, 더 좋은 방법을 찾기로 했다.Welcome, Lunch Board!신입 멤버를 맘껏 환영해 주면서, 호스트도 부담을 느끼지 않을 수 있는 방법은 없을까? 고민을 거듭하다 모두가 오가며 볼 수 있는 화이트보드를 활용해 웰컴런치보드를 만들어 보기로 했다.날짜만 써놓으면 이렇게 알아서 약속이 잡힐터이니...점심시간을 맞추기 위해 호스트가 일부러 수십 개의 메시지를 보낼 필요 없이, 각자 식사하고 싶은 날짜에 자기 이름을 적으면 끝. 약 2주 동안 하루에 서너 명씩, 원하는 ZOYI 멤버 누구나 참여할 수 있게 했다. 화이트보드에 날짜를 쓰자마자, 관심이 생긴 멤버들이 우르르 다가와 이름을 남기기 시작했다. (어머 이렇게 빨리 흥할 줄이야🤗🤗🤗)화이트보드를 활용하니 이외의 이점도 생겼다. 원래는 이메일이나 채널로 내부에 공유하던 신규 입사자의 자기소개글과 사진을 화이트보드에 붙여놓으니, 자연스레 글도 읽고 얼굴도 보게 되면서 그 옆에 환영메시지도 적고 호기심이 발동한 드립까지 쏟아내기 시작했다.처음 들어와도, 다시 돌아와도 격하게 환영해요 :D호스트의 맘은 덩달아 가벼워졌다. 다른 팀 직원들과 식사할 일이 늘어난 기존 멤버들도 즐거워했다. 다음 웰컴런치에 대한 기대감이 생기면서 신규 입사자에 대한 기대감과 관심까지 올라갔다.웰컴런치는 진화중세번째 웰컴런치가 끝나갈 무렵, 겉으로 보기에는 반응이 나쁘지 않은 것 같은데 실제로도 제도가 잘 운영되고 있는지 궁금해졌다. 그래서 몇몇 팀원들에게 웰컴런치보드 제도에 대한 피드백을 들어보니 신규 멤버의 빠른 적응을 돕는다는 본래의 취지는 잘 지켜지고 있는 것 같았다.다만 직접 겪어보기 전에는 예상하기 어려웠던 문제점도 보였다. 하나는 입사 첫 2주 내내 다른팀 직원들과 밥을 먹다보니 정작 같은팀 직원들과는 초반에 친해질 기회가 적었다는 점. 우린 바로 의견을 반영해 처음 2~3일은 같은 팀원들과 식사하는 '팀런치'를 만들었다.편하게 지내던 기존 멤버들끼리 이야기하느라 신입 멤버를 제대로 챙기지 못했다는 고백도 나왔다. 이 문제에 대해 기존 멤버들과 부드럽게 의논을 해보고 있으며, 새로운 동료와 어떻게 대화를 해 나가야 할지 막막할 경우를 대비해 활용 가능한 대화 주제 세트나 미션(!)도 고민 중이다.나름대로 고민을 해가며 나온 결과물이지만, 여전히 완벽한 제도는 아닐테다. 앞으로도 동료들의 리얼생생후기를 양식 삼아 웰컴런치를 조금씩 더 성장시켜 나갈 예정이다. 솔직한 의견들은 언제나 웰컴!계속해서 발전하는 ZOYI를 꿈꾸며인사파트를 담당하고 있지만, 웰컴런치가 개선되는 과정을 경험하며 ZOYI의 조직문화를 맡으려면 아직 배울 점이 참 많다는 생각이 들었다. 우리가 원하는 건 포퓰리즘이 아니기에 모든 의견을 무조건적으로 반영할 수는 없겠지만, 이번처럼 내부에서 끊임없이 멤버들을 관찰하고 목소리를 들으며 즐겁게 일할 수 있는 ZOYI를 더 단단하게 다져나갈 계획이다.아, 혹시 ‘후드'의 의미가 궁금한 분이 계실까봐 알려드리자면, 닉네임을 정할 때 마침 후드티를 입고 있어서 그렇게 이름을 지었다고 한다^-^ (쿨해서 얼어버릴 뻔^_^;;;)후드처럼 우리의 궁금증을 막 자극하고 싶다면, ZOYI의 모든 사람들과 따뜻한 밥 한 끼 해보고 싶다면, 점심시간에 같이 운동하고 게임하면서 놀고 싶다면, 여러분도 과감하게 ZOYI의 문을 두드려보길!
조회수 7219

내가 보낸 이메일이 스팸메일로 분류된다면?

이메일 뉴스레터를 발송하다보면 스팸메일함으로 직행하는 경우로 인해 어려움을 겪곤 합니다. 아쉽지만 꼼수는 없습니다. 스팸메일함을 피하기 위해서는 스팸메일이 무엇인지, 스팸 필터가 어떻게 작동하는지에 대한 이해가 필요합니다.스펨메일이란?스팸메일은 수신자가 원하지 않는데도 일방적으로 전송되는 이메일입니다. 발신자가 아무리 유용하다고 생각하는 정보일지라도 수신자의 동의가 없다면 스팸메일이 될 수 있습니다.정보통신망 이용촉진 및 정보보호 등에 관한 법률은 스팸메일과 구분되는 합법적인 광고성 이메일이 지켜야 하는 의무사항으로 수신자의 동의, 발신자 정보 제공, 즉각적인 구독해지 기능 제공 등을 규정하고 있습니다. 이를 지키지 않으면 과태료 부과 및 형사처분의 대상이 될 수 있습니다.하지만 의무사항을 지켜야 하는 이유가 법적 강제성 때문만은 아닙니다. 스팸 필터나 수신자에 의해 스팸메일로 분류되면 장기적으로는 이메일 뉴스레터의 도달률 자체가 나빠지게 됩니다.스팸 필터는 어떻게 작동하나요?스팸 필터란 이메일 서비스 제공자(예: 구글, 네이버, 다음 등)가 정해진 규칙에 의해 스팸메일로 규정한 이메일을 미리 걸러내는 것을 말합니다.스팸 필터를 통과하려면 기술적인 조치가 필요합니다. 예를 들어, 구글은 DKIM 서명, SPF 레코드 게시, DMARC 게시를 통한 이메일 인증을 권장하고 있습니다. 네이버는 이메일 인증 외에도 KISA WHITE DOMAIN에 발신자 등록을 하도록 권장하고 있습니다.스팸 필터는 수신자의 행동을 학습하기도 합니다. 수신자가 어떤 이메일을 스팸으로 분류했다면 스팸 필터는 그 이메일의 특성을 기억하고, 이후에 유사한 이메일 또한 스팸으로 분류합니다.어떻게 하면 스팸 필터를 피할 수 있을까요?기술적 조치들은 대부분 서버 관리자나 이메일 발송 서비스에 의해 이루어집니다. 스팸 필터를 피하기 위해 마케팅 담당자가 할 수 있는 것들은 없을까요?콘텐츠를 제작하고 발송하는 단계에서 주의해야 하는 것들은 다음과 같습니다.스팸메일로 오해할 수 있는 자극적인 표현(예: “무료”, “공짜”, “100%”, “!!!!!” 등)은 사용하지 않습니다.본문을 텍스트 없이 한 장의 큰 이미지로만 구성하지 않습니다. 이미지를 불러오지 못한 스팸 필터가 본문이 비어있다고 인식하고 스팸메일로 분류하게 될 수 있습니다.유효하지 않은 수신자는 발송 대상에서 제외합니다. 이메일 발송을 반복적으로 실패하면 스팸메일로 분류될 수 있습니다.답장을 받을 수 있는 진짜 이메일 주소를 사용합니다.스팸 필터를 통과했다면 그 다음 스팸 여부를 판단하는 것은 수신자입니다. 반대로 어쩌다 스팸 필터로 인해 스팸으로 분류됐더라도 수신자가 스팸이 아니라고 다시 분류(예: ‘스팸해제’, ‘차단해제’ 등)하거나 발신자를 주소록에 등록하면 더 이상 스팸으로 분류되지 않습니다. 나아가 이런 데이터가 쌓이면, 다른 수신자의 편지함에서도 스팸으로 분류될 확률이 줄어듭니다.결국 스팸 필터를 피하는 근본적인 방법은 수신자가 좋아할만한, 신뢰할만한 콘텐츠를 전달하는 것이고, 이는 모든 이메일 뉴스레터의 조건이기도 합니다.참고구글 대량메일 발신자 가이드라인네이버 대량메일 발송 가이드다음 대량메일 발송 가이드Mailchimp, How to Avoid Spam Filters#슬로워크 #스티비 #마케터 #마케팅 #메일링 #꿀팁 #인사이트
조회수 1416

빠르게 성장하는 옐로모바일, 이익을 내는 기업이 되자

CFO인터뷰어제 옐로모바일의2015년 실적 발표가 있었죠.약3,200억원의 매출과470억원의 영업손실을 기록하며 한 해를 마무리했는데요,연 단위의 적자이긴 했으나 마지막4분기에 매출1,000억원과 소폭이지만 영업이익 흑자전환을 이루어낸 것에 대해서는 긍정적인 여론이 형성되고 있는 것 같습니다.국내외 다양한 유니콘 및 독보적 스타트업들이 수익성 확보에 어려움을 겪고 있는 것을 감안할 때,이 정도 규모의 분기 매출 및 흑자전환은 옐로모바일의 재무 성장성 및 건전성에 대해 새로운 시각을 갖게 하는 기회가 될 수도 있을 것 같다는 생각이 들었는데요,이와 관련하여 이상훈CFO와 간단하게 몇 마디 나누어 보았습니다.드디어 분기 영업이익이 흑자로 돌아섰는데요,감회가 새로우시겠어요.하하 실은 예상된 시나리오대로 진행 중이라 실적에 대한 긴장과 감동이 있지는 않습니다만, 그래도 영업적자대신 영업이익이라는 단어를 쓰게 되니 기분은 좋네요 :) 많은 분들께서 잘 모르고 계시는 사실이 있는데요, 옐로모바일은 2014년 상반기까지 영업이익 흑자를 기록하던 회사입니다. 2014년 하반기부터 사업 규모 확장 및 성장 촉진을 위해 다방면의 투자를 시작했고, 2014년 포메이션8 (Formation8)의 투자 이후 2015년 상반기에는 투자 규모를 보다 확대했죠. 이로 인해 2014년과 2015년 각각 영업손실로 한 해를 마무리하긴 했지만,애당초 옐로모바일은 수익을 충분히 낼 수 있는 체력을 확보한 상태였습니다. 수익의 규모를 늘리는 것이 관건이었죠.특히 이번 2015년 연말 실적은 3분기까지 회사 자체적으로 진행했던 가실적 발표가 아닌 금융감독원이 지정한 지정 감사인의 공신력 있는 감사를 통과한 성과라 더 의미가 있습니다. 감사인의 판단 기준에 따라기존 발표내용보다 분기별 영업손실 기준이 조정되어 4분기 영업이익이 20억원대 후반 수준까지 갈 수 있었는데 가지 못한 점은 좀 아쉽지만요.그럼2016년은 영업이익 흑자를 기록할 수 있을 것으로 보시나요?물론입니다. 2015년 투자의 많은 부분이 쿠차에 집행되었는데,쿠차는 이미 월 단위의 흑자전환을 이루었고,계속해서 성장할 플랫폼입니다.또 다른 집중 투자 대상이 미디어 사업을 이끌고 있는 피키캐스트인데,피키캐스트는 올해부터 본격적으로 수익화를 준비하고 있습니다.올 해 안에 연 단위의 흑자 달성은 무리일 수 있지만,적어도 연 내에 월 단위의 흑자는 낼 수 있을 것으로 기대하고 있습니다.이에 더해 광고,여행, O2O사업은 원래도 흑자를 내 온 사업들이기에, 2016년은 무리 없이 연 단위의 영업이익 흑자를 기록할 것으로 예상되며, 2017년이 되면 다섯 개 사업 그룹 모두가 각자 흑자를 달성할 것입니다.그렇군요.그럼 조금 다른 방향에서 질문을 드려볼까 합니다.실은 옐로모바일은 아직 스타트업이고 비상장사인데,왜 이익을 내는데 집중하고 계신가요? 여타의 주목받는 스타트업들도 아직 적자를 기록하고 있는 것으로 알고 있지만 여전히 이익보단 성장에 초점을 맞추고 있는 것 같은데 말이죠.저희가 이익에만 집중하고 있는 것은 절대 아닙니다.성장하는 회사에게는 어찌 보면 매출 성장(Top-line Growth)이 더 중요할 수 있고,그렇기에 저희도 지속적으로 외형적 성장을 이어가고 있습니다.네이버, 카카오, 옐로모바일의 2015 분기별 매출 비교다만,결국 외형적 성장의 끝에 있는 목표는 수익이죠. 국내의 주요 스타트업들 역시 궁극적으로 훌륭한 수익 기반을 마련하기 위해 전략을 수립하고 실행하고 있을 것이라 생각합니다.유니콘의 단계를 넘어선 기업이 수익성을 확보하지 못했을 때 생기는 문제가 조금씩 드러나고 있는 곳이 오늘날의 실리콘밸리인 것 같아요.최근 타임지(TIME)에서도트위터(Twitter)의 수익성 문제를 지적한 적이 있죠.트위터는 상장 이전에 이미4억 달러 이상의 누적 적자를 기록하고 있었고,상장 이후 상황이 극적으로 호전되지 못하고 있는 실정입니다.최근3년 연속 영업손실을 기록하고 있죠.옐프(Yelp)역시 고전을 면치 못하고 있는데요, 2015년4분기에2,200만 달러의 적자를 보이며 네 분기 연속 적자를 기록,주가 관리에 어려움을 겪고 있습니다.물론 상장사이기 때문에 이러한 문제에 더 노출되어 있는 것은 맞습니다.그렇다고 해서 비상장 기업이 성장을 위해 수익성을 간과해도 된다고 생각하지는 않습니다.제가 꼭CFO여서 그러는 것이 아니라,안정적인 수익에 기반하여 성장할 수 있는 회사가 가장 이상적이지 않을까요?그런 의미에서 옐로모바일은 오늘도 성장과 수익이라는 두 마리 토끼를 잡는 쉽지 않은 길을 계속해서 걸어가고 있습니다.기업의 존재 이유가 이윤 추구만은 아닐 것입니다.그러나 동시에 기업의 생존과 지속 가능성을 위해 필수적인 요소가 수익인 것은 부정할 수 없는 사실이죠.스타트업이 언제부터 수익을 내야 하는지에 대한 정답은 없는 것 같습니다.또한 성장성과 수익성이 항상 상반되는 개념도 아닌 것 같고요.빠르게 성장하는 회사가 이익까지 낼 수 있다면,정말 더할 나위 없는 상황이겠지만,설령 둘 중 하나가 조금씩 정체되더라도 꾸준히 나아지는 모습을 보이는 것이 가장 중요한 것이 아닐까 싶습니다.옐로모바일이 어제보다 오늘,오늘보다 내일이 나은 회사가 될 수 있기를 기대해 보며,이상Y였습니다.
조회수 1207

화장실의 브랜딩: 업무분장의 함정

일을 할 때는 반드시 업무분장이란 것을 합니다. 각자 일정파트의 업무를 담당하고 그것에 책임을 진다는 얘기이지요. 매우 행복하고 아름다운 얘기입니다. 그 큰 업무를 어떻게 다 해. 그러니 너는 디자인, 너는 발표, 너는 자료조사, 나는 글을 쓰는 것이죠. 어디서 많이 본 그림입니다. 그렇죠. 조별과제.조별과제전 대학교를 중퇴하고 때려쳤으니, 1년 좀 넘게 경험했고 여러분들은 4년 내내 경험하셨으니 더욱 잘 아시리라 생각됩니다. 조별과제. 공산주의가 망한 이유를 몸으로 체득할 수 있는 또 하나의 교양과목이자, 모두의 할머니 할아버지가 여러 번 돌아가시는 예토전생의 술법이죠. 이 조별과제가 나이를 좀 먹고 장소를 직장으로 옮기게 되면 '업무분장'이라는 이름으로 재탄생하게 되는데, 자꾸 지난 4년간 겪었던 호구의 추억이 되살아나는 듯한 기시감은 떨쳐내기가 힘듭니다.  오늘은 이 업무분장에 대해 알아보도록 하겠습니다. 브랜딩업무는 혼자 할 수 있는 수준의 업무량이 아닙니다. 게다가 그래서도 안되는 것이구요. 브랜딩은 기획단계부터 디자인, 실행, 회계까지 다양한 팀과 업무영역을 아우르게 됩니다. 그도 그럴 것이 브랜딩은 전사적인 단위의 액션이고, 단기적인 프로모션 따위가 아니기 때문입니다. 정체성에 관련된 문제이니 모두가 각 영역에서 하나의 가지를 담당해야 합니다. 그러니 전체직원이 30명이라면 30명이 함께하는 조별과제라고 볼 수 있겠네요. 우리의 경험상 4,5명만 단톡방에 있어도 그 중 한 두명은 반드시 잠수를 탑니다. 더불어 다른 한 명은 도무지 속도를 못 따라오고, 그나마 괜찮은 아이는 자꾸 집안에 무슨 일이 생깁니다. 나를 제외한 모두의 집안에 큰 우환이 생기는 무시무시한 프로젝트죠. 일단 이러한 집안의 큰 변고가 어째서 생기는 지 알아보도록 합시다.업무분장은 왜 항상 폭망인가.1. 방관자이론은 어디에나 적용된다. 내가 아니어도 누군가는 할 겁니다. 이거 못해도 월급은 받습니다. 혼나면 됩니다. 우리 중에 마피아가 있는거야..날로 먹2. 업무역량이 제각각이다.내 기대만큼 일을 잘하는 사람은 세상에 그리 많지 않습니다. 그리고 내가 생각하는 수준의 프로일잘러들은 이미 개인적으로 다 사업을 하고 있거나, 재야에 숨어있거나, 일하느라 바빠서 찾기 힘듭니다.고수들은 산 속에 숨어있다. 채용공고는 비둘기로 날리자.3. 누가 무슨 일을 하는 지 몰라.분명 회의시간엔 서로 나눈 것 같긴 한데 누가 무슨 일을 어떻게 맡고 있는 지를 정확하게 모릅니다. 옆 사람의 업무진행이 어디까지 되었고, 거기에 맞춰 나는 어느 수준까지 해야하는 지 등, 분장의 목표는 집단지성과 다수의 분업을 통해 효율적이고 높은 수준의 결과물을 내는 데에 있지만, 대부분 목표와는 다르게 집단게으름과 한 사람이 만든 것보다도 못한 혼란스럽고 괴이한 혼종이 탄생하는 경우가 많습니다. 느와르 영화 찍는 것도 아니고 도대체 왜 다들 자기 일을 숨기는 걸까요?그래서 나오는 괴이한 혼종...4. 사실은 커뮤니케이션을 못한다.사실은 숨기는 게 아니라, 말을 못하는 겁니다. 어떻게 말해야 할 지도 모르고, 서로 보고하는 것도 눈치보입니다. 솔직히 수평적관계라고 톰, 제임스, 하비 등 영어이름을 붙였지만 몸에 밴 수직적 마인드는 어쩔 수 없습니다. 1년차와 5년차인 내 명함에 똑같이 manager 라고 되어있는데다가 1년차가 자꾸 자기와 동등한 수준의 프로젝트를 맡는다면? 5년 차인 선배의 입장에선 각자의 역량의 차이가 있으니 당연하다. 라고 받아들이기는 여간 어려운 일이 아닐 것입니다. 그런데 자꾸 밖으로는 쿨한 척 해야하고, 속으론 '내가 니 위야' 라는 모순이 발생하면 입은 닫히고 가면만 늘어갑니다. 자꾸 가벼운 얘기들만 오고가고 진지한 싸움과 논쟁을 피하게 됩니다. 화를 내면 진다라는 묘한 명제는 분노의 진실성을 역설하고 있습니다. 먼저 진실을 내비친 사람이 패배하는 것이다라는 체면과 격식의 아이러니죠.눈치만 보는게지.5. 업무분장의 기준이 엉망이야.업무는 케이크쪼개듯 정확히 몇 등분으로 쪼개지지 않습니다. 반드시 많은, 중요한, 급한 일들이 발생하고 누군가는 그것을 떠맡아야 합니다. 업무분장의 기준은 대부분의 회사에서 '잘 하는 사람' 에게 집중되고, '손 빠른 사람'에게 과중됩니다. 직급높은 사람에게 책임직을 맡기고, 일 없는 사람들에게 자잘한 업무들을 던집니다. 그냥 상식선에서 이루어지는 분장이죠. 분장과정에서 이 사람의 역량이나 성향, 관심사나 이전 경험, 인맥과 인사이트가 고려되지 않습니다. 조장님 말씀6. 하던 사람이 계속 하는일이란 것이 참으로 그렇습니다. 사람뽑기가 세상에서 가장 힘든 것이 사업이죠. 그래도 회사에 나를 제외한 내 오른팔과 같은 존재가 한 명 정도는 있기 마련입니다. 대표도 사람인지라 당연히 열 손가락 깨물면 더 아픈 것이 있기 마련입니다. 그런데 대부분 그 아픈 손가락이 굉장히 일을 잘하는 사원이고 믿음이 간단 말이죠? 그러면 배려해주고 쉬게 해주는 것이 아니라, 더욱 많은 일을 맡깁니다. 이것은 상대적인 불신때문입니다. 이 사람이 잘하니까 일을 줘야지! 라고 생각하기 보단 실상 다른 직원에게 주려고 하다보니...고려할 사항이 너무 많습니다. 검증되지도 않았고 애매한 거죠. 그런데 일은 매번 중요한 것들입니다. 그르치면 손해가 막심할 것 같으니 믿음직한 사람에게 고개를 다시 돌립니다. 아이러니하게도 그 믿음직한 사람은 일이 과중되고 지쳐가기 시작합니다. 곧 그 믿음은 실수와 사고로 이어지기 마련이죠.7. 이해를 못함일을 잘하고 못하고를 떠나서 이것은 업무이해도의 문제입니다. 전체그림을 볼 수 있느냐의 문제죠. 브랜딩에 대해 얘기할 때 1화에서 '모든 직원이 내용을 알고 있어야 한다' 라고 꼭 찝었던 것은 이 때문입니다. 업무이해도가 떨어지면 레시피만 보고만든 믹스호떡처럼 괴생명체가 탄생하거나 도무지 처치곤란한 혼종이 등장하게 됩니다. 기껏 일은 일대로 하고 손해는 손해대로 보는거죠.뭐라는 거지...?8. 편가르기, 편애, 미운털, 관계가 망치는 업무특수한 경우라고 믿고싶지만, 은근히 많더군요. 이해는 갑니다. 사람 모인 곳에 어찌 당파가 없을 수 있겠습니까. 라인도 있고, 야당도 있고 여당도 있고 제3당도 있고 많죠. 문제는 자꾸 이러한 인간적관계가 업무에 영향을 미친다는 것입니다.  예를 들어 우리 팀장이 좀 호구같다고 칩시다. 난 오히려 옆 팀의 이사겸 팀장님이 더 좋습니다. 그래서 우리 팀장이 준 일은 미뤄놓고 옆 팀에서 부탁한 일 먼저 처리하고 있습니다. 우리 팀장이 나를 혼냅니다. 난 빡쳤습니다. 그래서 옆에 이대리랑 옥상에서 담배를 피며 말했죠."아 진짜 존나 일도 못하면서 성깔은..아놔"이대리는 거듭니다. 왜냐면 나와 친하니까요"진짜 저 사람은 어떻게 일할려나 모르겠음.. 이번 것도 분명 말아먹을 기센데." 우린 한 당파가 되어 팀장을 깝니다. 그리고 그의 지시를 자꾸 누락하고 미루고 안하죠. 대강하거나. 취합해야 하는 입장에선 자꾸 공백이 생긴 결과물들이 올라옵니다. 하지만 일을 만들긴 만들어야 하니 또 야근을 해야하죠. 야근을 하고 혼자 취합을 하게 되면 실수가 생깁니다. 실수는 문제를 야기하고 문제는 손해로 이어지죠. 손해의 책임은 간부가 1차 타격을 입습니다. 이것도 어불성설입니다. 사실. 수평적 문화라면 책임도 동등하게 가져가야 하는 것이 이치상 맞습니다.  내 기여도만큼의 보상을 받는 만큼, 내 손실분에 대한 타격을 입는 것 또한 수평적 문화의 특징입니다. 특히 성과지표가 분명한 프로젝트 기반의 업무에선 더욱 그러하죠. 어쨋든 팀장은 멘붕이 되고 윗 선에게 심하게 깨집니다. 직원들은 그걸 또 팀장의 탓으로 돌립니다.  물론 이 과정에서 팀장이 잘했다는 얘긴 아닙니다. 애시당초 팀 관리에 문제가 있기도 했겠죠. 하지만 그것을 마냥 팀장이나 간부에게 당신의 리더쉽 탓입니다라고 전가시키기엔 직원들도 결국 마찬가지 수준이었습니다.  업무분장은 어떻게 할까.업무분장의 문제가 해결된다면 전세계 모든 대학교의 조별과제의 악몽이 해결되는 기적이 일어날 수 있을 것입니다. 또한 대부분의 기업의 효율성이 개선되고 생산성이 극대화되어 이 지긋지긋한 장기침체가 끝날 지도 모르겠습니다. 심지어 저도 팀원들과 일을 했을 때, 직원이 있었을 때, 협력업체와 일할 때 등등... 여러 케이스를 겪어봤지만 정확한 정답을 찾지 못했습니다. 다만 소기의 성과와 부작용들을 체험하면서 이건 이럴 때 좋고 이럴 때 좋지 않구나...라는 정도를 짐작할 따름입니다. 그러니 업무분장의 옳은 방법이라기 보단, 뻔하지 몇 가지 유의사항을 중심으로 적어보겠습니다.1. 적어도 분장회의는 심각하게.프로젝트플랜을 짜고, 각자 업무를 나누는 회의를 할 텐데. 전 개인적으로 이 회의를 대충하지 말자는 주의입니다. 조금 과장해서 하루 전체를 그 업무분장 회의에만 써도 괜찮습니다. 하루는 정말 고생하겠지만, 이 후의 확인, 취합, 업무상황 진행 등 모든 전반의 업무효율이 극단적으로 올라갑니다. 다들 그 시트의 데드라인을 맞추기위해 노력하고, 모두가 어떤 상황이 어떻게 돌아가는 지 이해하고 있는 상황이 됩니다. 단, 그 하루동안 해야 할 일이 있습니다. 직원들의 성향파악현재 업무 재정리각자 업무속도 계산프로젝트 기간 내 개인사, 사내일정 스케쥴링정/부 인원 지정보고체계 확립프로젝트 개괄 프레젠테이션상세 업무공유개인별 목표설정 및 평가지표 설정개인별 업무일정 짜기취합 후 프로젝트 플랜시트 제작완성된 플랜시트 피드백적어도 이 부분들은 순서대로 아주 치밀하게 결론을 내는 회의시간이었으면 합니다. '너 일 뭐 있지? 너가 이거 할래?' 이런 식의 분장이 되지 않았으면 좋겠습니다.2. 미달성의 책임은 분명히실무자를 위한 것이기도 합니다. 방관자의 심리의 주된 원인은 책임의 분산입니다. 다수가 존재하는 만큼 해당 이슈에 대한 책임이 분산되며 나에겐 피자 위에 뿌려진 올리브만큼의 책임감만이 스윽 주어지게 되는데 그 정도는 그냥 자기합리화나 집안일핑계로 거뜬히 쳐낼 수 있는 수준의 것들입니다. 이런 식으론 어떤 것도 이루어지지 않습니다. 위 회의에서 개인별 목표설정, 평가지표 설정은 정말 중요한 데 해당목표의 미달성시 어떤 핸디캡을 받고 어떤 책임을 질 것인지도 명확하게 지정하는 것이 좋더군요. '반드시 해내야 한다'는 적당한 압박감은 실패시의 합리화나 책임전가를 막고 외부요인으로 부터 그 핑계를 찾는 사태를 줄여줍니다. 아킨(R.M.Arkin)과 바움 가드너(A.H.Baumgaerdener)의 셀프핸드캐핑 실험에서 증명된 것과 같이 말이죠.3. 업무량은 내 처리수준의 +15%, 데드라인은 항상 -1일긍정적인 마인드와 열정, 화이팅, 돈독한 애사심은 훈훈한 분위기에는 좋을 지 몰라도 업무처리능력과는 별개의 문제입니다. 업무를 완성시키고 직원들을 고무시키고 싶다면 편하고 쉬운 일을 주는 것이 아닙니다. 항상 내가 해결할 수 있는 한계치의 적당량 이상의 어려운 과제, 적당히 급한 데드라인의 선을 지키는 것이 중요합니다. 일의 속도감과 성취감은 '일을 끝냈다!' 에서 오는 것이 아니라 '그 일을 해냈다!' 에서 오는 것이기 때문이죠. 에드워드 데시와 리차드 라이언의 자기결정이론중 인지평가이론(Cognitive Evaluation Theory)을 참조해보면 좋을 듯 합니다.4. 일관성!!1번에서 그렇게 심각하게 회의를 했으면, 중간에 그걸 엎지마세요. 회사 일이란 게 워낙 심각하고 급박하게 돌아가는 것이 많으니 변동과 이슈가 많은 것은 사실입니다. 하지만, 급하니까 너 그거 다 멈추고 이것부터 해! 라고 하는 것은 그냥 파국급행열차 티켓을 끊어 손잡이에 매달린 채 목적지까지 달려가렴. 이라는 소리와 같습니다. 어차피 업무분장회의에서 나왔던 그 일도 해야 하잖아요?? 중간에 일이 들어오면 차라리 경매를 붙여서 스스로 업무량을 조절할 수 있게 하던가, 아니면 다시 전사회의를 거쳐 양해를 구하고 전체플랜에 대한 수정을 전사공지합니다. 정보의 제한과 이해의 부족은 아주 사소한 실수와 그냥 던지는 작은 일조차도 '불신의 씨앗'으로 변하게 합니다. 적어도 우리가 그 날 열심히 만들었던 그 회의는 결코 변하지 않는다라는 일관성과 고집이 있어야 추후에 평가, 책임, 보상 때도 신뢰감이 있는 것입니다. 중간에 자꾸 말바뀌고, 일 틀어버리고, 맡기겠다고 했으면서 계속 간섭하고, 불필요한 과정을 자꾸 삽입해서 보고를 위한 보고를 만들어내면 추후에 그 모든 책임은 다 관리자 본인이 지셔야 합니다. 5. 모든 과정은 결과후에 복기한다.불만이 쌓이는 것은 무서운 일입니다. 그러나 그 불만을 그 때 그 때 터뜨리는 것도 업무에선 그리 좋은 방향은 아닙니다. 물론 순간순간 해결될 수 있는 사안이라면 당장 커피와 함께 멱살을 잡든 엎어치면 되겠지만 대부분의 업무방향은 시스템적인 수정을 필요로 합니다. 때문에 실시간으로 문제해결을 하다간 일이고 나발이고 흐르는 물 막느라 아무것도 못하는 상황이 됩니다. 일단 프로젝트를 끝내는 게 급선무입니다. 단, 일 하나가 끝나고 업무분장된 결과물이 등장하고 난 후 반드시 평가회의를 하시길 추천드려요. 그리고 그간의 모든 일들을 하나하나 정리하면서 복기하셔야 합니다. '아 모두 수고했구요, 참치먹읍시다아~' 이게 아니고... 처음에 하루종일 회의하듯 정말 냉철하고 싸울 듯한 회의가 되어야 해요. 단 회의의 결과는 뭔가 명확한 솔루션을 들고 끝나야겠죠. 안 그러면 감정싸움만 될테니까요.업무분장은 대표입장에서도, 실무자입장에서도 정말 어려운 일입니다. 서로가 서로에 대한 이해가 없이는 일을 할 수도 나눌 수도 합칠 수도 없으니까 말이죠. 자유롭게 서로의 일을 그냥 알아서 하면 얼마나 좋을까요? 각자 일을 찾아서 하는 유토피아같은 사무실 말입니다. 인간은 자유라는 환경이 주어졌을 때 함께 공포를 느낀다고 합니다. 아무런 책임이 없는 상태에선 본능이 가장 먼저 튀어나오고, 애사심이나 업무에 대한 객관적인 판단보단 내 자존심과 타인에 대한 경계심, 심리적관계가 더 먼저입니다. 회사에 들어와서 책상에 앉아 일을 하고 있다고 해서 뭔가 갑자기 일하는 로봇이 되는 것은 아니니까요. 업무분장은 이러한 사람들의 특성을 충분히 고려해야 합니다. 배려할 부분을 배려하고 억압할 부분은 강력하게 억압해야 합니다. 책임과 도전에 따른 보상과 벌도 있어야 합니다. 납득할 만한 이해와 협의도 거쳐야 하며 먼 발치에서 어떤 식으로 누가 무슨 일을 하는 지 확인도 종종 해야합니다. 그냥 '너가 화장실 청소 해.' 라며 던진다고 끝날 문제는 아니라는 것이죠.우리 사무실의 화장실청소는 어떻게 분장되어 있나요? 누가 하고 있나요? 어떻게 그것을 담당하게 되었나요. 만약 그 사람이 청소를 하지 않는다면 한 달 뒤 화장실의 모습은 어떻게 될까요. 회사와 비즈니스는 모두의 손을 거쳐 만들어집니다회사와 비즈니스는 모두의 손을 거쳐 만들어집니다. 사무실부터 작은 앱아이콘, 메뉴텍스트까지 누구 하나의 손이 닿지 않은 곳이 없죠. 모두가 사람이 만들어야 하는 것입니다. 과연 우리 회사엔 누구의 어떤 손길이 얼마나 닿아있는 지 한 번쯤 돌아보는 시간을 가져보는 것도 의미있을 것 같습니다. :)
조회수 3584

Good Developer 1 | 좋은 개발자의 5가지 기준

좋은 개발자 소개해주세요.많은 기업 관계자분들을 만나면서 항상 듣는 말이다. 스타트업에 있어서 인재 채용이 항상 문제기는 하지만, 이것은 비단 스타트업에만 국한되지는 않은 것 같다. 지난 코드스테이츠 데모데이 때는 카카오와 SK텔레콤 같은 대기업과 더불어 스마트스터디, 데일리호텔 기업 관계자분도 참여해 주셨다. 이것을 보면 대기업이든, 규모가 꽤 있는 기업이든 좋은 개발자를 찾는 것은 어려운 것 같다.기업들이 이런 말을 하는 것을 보면 개발자를 찾는 수요는 빠르게 증가하고 있는데, 기업들의 입맛을 맞추면서 개발을 할 수 있는 '좋은 개발자'는 많이 없는 듯하다. 이런 상황에서 코딩 교육 스타트업 코드스테이츠가 많은 기업 관계자분과 개발자분들을 만나고 코딩 교육을 하면서 느낀 점을 통해 어떤 개발자가 좋은 개발자인지에 대하 포스팅을 하려 한다.이것을 통해 좋은 개발자라는 개념을 구체화할 것이다. 좋다는 개념을 명확히 해서 어떤 것들이 좋아야 좋은 개발자인지, 또 소위 말하는 좋은 개발자가 되기 위해서 어떤 노력들을 해야 하는지 글로 풀어갈 것이다. Good Developer 시리즈 첫 번째 포스팅, 좋은 개발자의 5가지 기준좋은 개발자의 5가지 기준좋은 개발자에 대한 생각은 개인마다 또 기업마다 다를 것이다. 아래의 기준들은 많은 기업 관계자분들과 개발자분들을 만나고, 코드스테이츠가 교육을 하면서 느낀 좋은 개발자의 기준들이다. 아래의 조건들이 좋은 개발자의 충분조건이라고 할 수는 없지만, 필요조건이라고는 할 수 있을 것 같다. 코드, 생산성, 커뮤니케이션, 학습, 관리 능력 이 5가지 관점을 통해 어떤 개발자가 좋은 개발자인지 알아보자.1. 코드의 리딩과 라이팅좋은 코드를 짤 수 있는 역량은 좋은 개발자가 되기 위한 필수적인 기준이다. 하지만, 대부분의 개발자들에게 어떻게 하면 좋은 코드를 짤 수 있는지 물어보면 쉽게 답하는 사람은 많지 않다. 그래서 구체적으로 어떤 능력이 있어야 좋은 코드를 짤 수 있는지, 코드의 리딩과 라이팅의 관점에서 살펴보고자 한다.많은 주니어 개발자들이 처음 회사에 입사해서 해야 하는 것 중 하나는 코드의 리딩(reading)이다. 자신이 처음으로 개발을 시작하지 않는 이상 이미 개발된 소스들을 보고 어떻게 동작하는지 또 변수, 함수, 메서드들의 네이밍(Naming)은 어떤 식으로 하고 있는지 파악해야 한다.코드의 리딩 능력은 업무 환경에 적응하는 능력과는 별개로 자신의 업무를 파악하고 또 다른 사람과 커뮤니케이션할 때 매우 중요하다.  그리고 코드를 잘 읽으면 어디가 잘못되어 있는지, 어떻게 고쳐야 하는지 쉽게 파악할 수 있다. 그리고 이것이 코드를 잘 짤 수 있는 역량으로도 직결된다.리딩 능력과 더불어서 중요한 것이 바로 코드 라이팅(writing) 능력이다. 라이팅은 코드를 잘 짜는 것과 별개로 네이밍(Naming)을 잘하고 이해하기 쉽게 코드를 쓰는 것을 의미한다. 코드 리딩 능력이 뛰어나지 않은 개발자라도 잘 정돈되고 직관적으로 네이밍 되어 있는 코드들을 보면 쉽게 읽을 수 있다.코드 라이팅 능력은 협업하고 코드를 구조화하는 과정에서 매우 중요하다. 코드 라이팅 능력이 떨어진다면 다른 사람이 자신의 코드를 이해하는데 오랜 시간을 소모하게 만들 뿐만 아니라 나중에 가서는 자신조차 자신의 코드를 이해하는데 오랜 시간이 걸릴 수 있다. 이렇기 때문에 안정된 코드, 돌아가는 코드를 짜는 것과 별개로 다른 사람과 자신이 이해하기 쉬운 코드를 짜는 능력은 매우 중요하다.좋은 코드를 짜기 위해서는 다른 사람이 어떤 코드를 짰는지 알아야 하고 내 코드를 다른 사람들이 쉽게 읽을 수 있도록 해야 한다. 개발자는 결국 코드로 말한다. 코드 라이팅 능력이 떨어진다는 것은 코드로 '잘' 말하지 못한다는 것을 의미한다. 또 코드 리딩 능력이 떨어진다는 것은 다른 개발자가 코드로 말하는 것을 '잘' 듣지 못한다는 것을 뜻한다. 좋은 개발자의 조건으로 항상 따라붙는 좋은 코드를 짜는 방법은 코드 리딩과 라이팅 능력이 선행되었을 때 가능할 것이다.2. 빠른 생산성좋은 코드를 짜는 것이 좋은 개발자가 되는데 중요한 조건이기는 하지만 유일한 조건은 아니다. 개발은 필연적으로 시간과의 싸움이다. 그래서 좋은 개발자의 조건 중 하나가 바로 생산성이다. 우리나라의 많은 개발자들이 야근에 시달리는 것도 결국은 생산성과 연결되어 있다.(물론 조직문화도 크게 작용한다. 그리고 CEO의 마인드도...)안정적이고 완벽한 코드를 짜는 것도 중요하지만 때로는 시간과 타협해서 돌아가는 코드를 짜는 것만으로 만족해야 할 때가 있다. 특히, 리소스가 부족한 스타트업에서는 시간이 생명이다. 환상적인 코드를 짤 수 있는 개발자라 할지라도 그 시간이 천년만년 걸린다면 당장 돌아갈 수 있는 코드를 돌릴 수 있는 개발자 보다 좋은 개발자라고 하기 힘들 것이다.투입한 시간 대비 얼마만큼의 코드 생산성이 나오는가? 시간이 생명인 많은 스타트업에서는 안정적이고 완성도 높은 코드를 짜는 개발자보다 생산성 높은 개발자를 선호할 가능성이 크다. 첫 번째 기준인 코드 리딩과 라이팅 능력에서 자신이 없다고 걱정할 것 없다. 자신의 코드 생산성이 좋다면 좋은 개발자로서의 중요한 기준을 하나를 충족한 셈이니까.3. 원활한 커뮤니케이션위의 두 가지 기준이 개발 자체에 대한 능력이었다면, 커뮤니케이션 능력은 다른 사람과 협업하는 능력에 대한 기준이다. 혼자서 개발하는 개발자는 극히 드물다. 코딩 = 개발이 아니다. 코딩은 개발의 한 과정이며 개발을 할 때에는 다른 구성원들과 수많은 상호작용을 해야 한다. 왜냐하면 개발자는 결국 사람들과 일하기 때문이다.그래서 많은 기업들이 개발자를 채용하는 기준에서 '원활한' 커뮤니케이션을 내세운다. 개발과 관련 없을 것 같은 커뮤니케이션은 사실 엄청나게 중요하다! 커뮤니케이션 문제로 발생하는 비용 문제(단순히 돈이 아니다.)는 상당하다.어느 정도 개발 경험이 있는 사람은 누구나 공감할 수 있을 것이다. 같이 일하고 싶은 개발자와 아닌 개발자가 있다는 사실을 말이다. 단지 사람이 좋고 나쁨을 떠나서, 대화를 하는데 숨이 턱 막히는 사람이 있고 대화를 하면 할수록 막혔던 부분이 풀리거나 새로운 아이디어를 떠오르게 만다는 사람이 있다.원활한 커뮤니케이션은 사실 어느 직군에나 해당되는 말이지만, 개발처럼 한 가지 테스크에 여러 사람이 집중적으로 달려드는 업무에 있어서 그 중요성이 더 부각된다. 당신은 원활한 커뮤니케이션 능력을 가지고 있는가?4. 업무 관리, 사람 관리 능력업무 관리와 사람 관리는 사실 개발자 직군에 국한된 역량이 아니라 모든 직군에서 필요로 하는 역량이다. 개발에 치중해야 할 개발자가 좋은 개발자가 되기 위해 이런 것들까지 신경 써야 할 이유는 무엇일까? 위에서도 언급했지만, 개발 = 코딩이 아니다. 개발을 한다는 것은 테스크를 나눠 할당하고 기간에 맞춰 완성시키는 일이다. 이 과정에서 필요한 상호작용, 업무 관리, 생산성이 모두 개발의 과정이다.업무 관리와 사람 관리를 잘 하는 사람은 막말로 그냥 일 잘 하는 사람이다. 좋은 코더가 아니라 좋은 개발자가 된다는 것은 일을 잘하는 사람이 되어야 한다는 뜻이다. 업무 관리는 테스크를 나누고 할당하고 데드라인을 설정하는 일이 아니더라도 나에게 주어진 테스크에 대해 스스로 관리하는 능력까지 포함한다. 결국 자신의 업무 관리를 잘하는 사람은 생산성에서 두각을 나타내리라.주니어 때 좋은 개발자로 인정받고 연차가 쌓이면 시니어가 되고 관리자 직급으로 올라갈 가능성이 크다. 이때 주니어 때 좋은 개발자였다고 시니어 개발자일 때도 좋은 개발자일 거란 보장은 없다. 시니어가 돼서도 좋은 개발자가 되고 싶다면 업무 관리와 사람 관리하는 능력이 필수적이다. 특히, 한국에서는 개발자의 종착지는 관리자일 정도로 연차가 많은 사람이 개발을 하고 있는 경우는 극히 드물다. 이런 상황에서 좋은 개발자로 인정받아 마지막까지 살아남기(?) 위해서는 이 두 가지 능력이 필수적이다.5. 지속적인 학습위에서 제시한 네 가지 능력이 모두 없다고 실망할 것 없다. 좋은 개발자가 되기 위하 마지막 조건, 지속적인 학습이 있기 때문이다. 지속적인 학습은 좋은 개발자가 계속해서 좋은 개발자로 남을 수 있게 만들어주고 일반 개발자가 좋은 개발자가 될 수 있게 만들어주는 중요한 조건이다.개발은 빠르게 변한다. 모든 직군 중에서 가장 학습을 많이 해야 하는 직군을 뽑으라면 자신 있게 개발자라 말할 수 있다. 빠르게 변화하는 환경 속에서 지금 좋은 개발자라 해서 몇 년 후에도 좋은 개발자라고 단정 지을 수 없다. 개발자는 숙명적으로 끊임없이 배워야만 한다. 좋은 개발자가 되기 위해서는 더더욱.지속적으로 배운다는 것이 단순히 새로운 것을 익히고 지식의 지평을 확대해 나간다는 것만을 의미하지 않는다. 지금 현재 소위 나쁜 개발자(코드 퀄리티, 생산성, 커뮤니케이션, 관리능력 모두 떨어지는 개발자)가 블록체인 신기술을 배운다고 해서 좋은 개발자가 되겠는가? 즉, 코딩 지식에 대한 고민뿐만 아니라 위에서 언급한 네 가지 기준에 대한 학습도 필요하다.학습에 측면에서 많은 분들이 간과하고 있는 것이 지식의 질이다. 단순히 지식의 양적인 측면에만 매몰되면 깊이 있는 지식을 얻기 힘들기 때문이다. 물론, 현재의 시대적 흐름을 읽고 최신 트렌드 기술을 습득하는 것은 중요하다. 하지만 그보다 더 중요한 것은 자신이 알고 있는 지식들을 깊이 있게 아는 것이다. 끊임없는 학습, 그리고 깊이 있는 학습만이 좋은 개발자를 계속해서 좋은 개발자로 만들어 준다.좋은 개발자를 위해지금까지 좋은 개발자를 위한 5가지 조건에 대해 알아 보았다. 코드 리딩과 라이팅, 생산성, 커뮤니케이션, 사람과 업무 관리 그리고 지속적인 학습. 이외에도 중요한 조건들이 많지만 많은 개발자를 만나고 교육해오면서 가장 필요하다고 생각하는 5가지 조건을 적어보았다.개발자가 되는 것은 쉽지 않다. 좋은 개발자가 되는 것은 더더욱 쉽지 않다. 좋은 개발자를 양성하기 위해 노력하는 교육 스타트업으로써 어떤 개발자가 좋은 개발자인지 파악하기 위해 항상 노력 중이다. 이 노력을 코드스테이츠만 알고 있는 것이 아니라 다른 분들에게도 공유드리고 싶다. Good Developer 포스팅을 통해 어떤 개발자가 좋은 개발자인지 또 좋은 개발자가 되기 위해서는 어떻게 해야 하는지 이야기할 예정이다. 좋은 개발자의 길은 멀지만 Good Developer를 통해 한층 쉽게 걸어갈 수 있었으면 좋겠다.
조회수 961

협업툴 플로우의 새로운 사무실 … 랜선 집들이 😊

2021년 8월, 플로우팀은 새로운 사무실 공간으로 이사를 했어요. 😉 새로운 사무실은 플로우가 가진 협업 철학을 가득 담아 설계되었는데요! 이 포스팅을 통해 플로우팀의 공간이 어떤 모습으로 변화했는지 소개해드릴게요!플로우 뉴 사무실 투어! 지금 시작합니다.🚗🚀1. 같이 경험하고 성장하는     전사 타운홀 미팅 🚀플로우는 한 달에 한 번 전직원이 모여 그간의 성공담과 실패담을 공유는 📅'월간 경영 포럼' 이라는 특별한 사내 문화가 있어요. 서로의 경험과 고민을 함께 공유하며 자신의 업무 외 다양한 분야에 대한 안목을 넓히는 플로우만의 협업 문화에요! 넓은 타운홀 미팅 공간은 플로우 팀의 전직원 소통을 위한 홀로 꾸며져 더 자유로운 회사 분위기를 연출했어요!2. 뻥 뚫린 회의실에서    자유로운 소통중 🙋‍♀️🙋‍♂️통유리를 활용한 뻥 뚫린 폴딩도어 인테리어가 돋보이는 플로우의 회의실입니다. 덕분에 답답하고 권위적인 분위기를 탈피하고 개방된 의견을 표현할 수 있는 자유로운 회의 공간이 되었어요! 구글 시계로 유명한 '⏲타임타이머'를 활용해서 회의시간을 정해 놓고 집중력 있게 시간 관리를 하고 있답니다! 회의 공간에서 플로우의 팀원들은 자신의 생각을 다른 팀원에게 공유하고 의견을 듣으면서 함께 성장하는데, 그 분위기가 얼마나 즐거운지 직접 경험해 보신다면 놀라실거에요!3. 휴식이 필요할 때 떠나요 ~     플로우 제주도🛫누구나 때때로 일에 집중하기 어려운 날이 있죠. 플로우에서는 그런 날 억지로 책상에 앉아 끙끙거릴 필요가 없어요. 점심 시간 등 쉬는 시간을 모두에게 허용된 휴게 공간에서 무한 힐링🌵하며 다시 집중력을 되찾을 수 있죠! 2층으로된 휴식 침대와 안마의자까지 1인용으로 프라이빗하게 사용할 수 있어요! 휴게실이라는 곳은 시설도 중요하지만 눈치 보지 않아도 되는 편안한 분위기가 정말 중요한데요! 그런 의미에서 플로우 휴게실은 “진짜” 랍니다.* 잠시 글쓴이 맘대로 소개하는 PPL 보고 가겠습니다.수면 전문 브랜드 '삼분의일'에서 플로우팀을 위해 메트리스를 협찬해주셨습니다. 꺄. 💕 딱 10분만 자려고 누웠는데 어젯밤 집 보다 회사에서 더 딥슬립하게 만들어 준다는 소문이...감사 표현에 진심인 편...♥침대와 내가 한 몸이 되는 물아일체의 경지를 느끼고 싶으신 분들이라면.. 삼분의일 4. 플로우가 만들어 지는 곳.      업무 공간 💻출근을 해서 가장 오랜 시간 앉아있는 공간인 업무 공간! 가장 중요하겠죠?팀 별 성향에 맞게 자율적으로 업무 공간을 꾸밀 수 있답니다. 공간'이 사람에게 미치는 영향은 어마어마하다고 해요. 왠지 더 크리에이티브한 상상력이 넘쳐날 것 같다는 기대감이 드는, 플로우의 업무 공간! 또한 개개인이 작업에 완전히 몰두 할 수 있는 넉넉한 개인 책상 공간과 타팀과 분리된 자리 배치로 플로우팀은 더욱 더 발전하고 있답니다!5. 작은 1%까지 마음써주는      배려 공간 🙏어쩌면 다른 회사에서는 창고로 사용되었을 수도 있는 작은 공간들, 플로우에서는 그런 장소까지 직원들을 위한 중요한 공간으로 활용되고 있어요. 공동 휴게실이 부담될 수 있는 여성 직원들을 배려한 여성 전용 휴게실, 업무의 기한을 지키기 위해 집중이 필요한 때 필요한 1인 업무 집중 공간을, 동료들의 집중력을 위한 매너있는 폰부스까지!여기까지 플로우의 새로운 오피스를 소개해드렸어요!플로우는 업무에 100% 몰입하여 역량을 발휘할 수 있는 환경을 만드는데 힘쓰고, 임직원이 함께 얻은 성과를 바탕으로 한 재원을 다시 더 좋은 일터를 만드는데 사용하고 있어요! 앞으로 변화된 사무실에서 더 큰 꿈을 이뤄가는 플로우팀을 지켜봐주세요. 협업툴 플로우 바로가기
조회수 664

경계를 지우자

당신이 디자이너라면디자인의 경계를 넘어서야 뜻을 이룰 수 있으며,당신이 마케터라면마케팅의 영역을 벗어나야 진짜 마케팅을 할 수 있다.자신의 영역을 고수하면 그냥 고립될 뿐이다명함에 새겨져 있는 당신의 분야는 그저 관념일 뿐이며,실존하는 구분이 아니다. 컨베이어 벨트에서 편의상 내 일과 당신의 일을 구분하기 위한 경계선일 뿐이다.지금의 구분이라면,레오나르도 다빈치는 무엇을 하는 사람으로 구분할 것인가?당신이 숫자를 다루는 회계사에 머문다면,그냥 기능인으로 살뿐이며,당신이 변호사의 틀 안에서만 일 한다면,기술인일 뿐이다. 그저 전문적인 기술인일 뿐이다.법을 도구로 세상을 새롭게 기획할 수 있다면,위대한 정치인이 될 것이며,디자인을 도구로 새로운 생각을 표현할 수 있다면,뛰어난 크리에이터가 될 것이다.당신이 현재 가지고 있는 직함과 직종은요리의 재료일 뿐이다. 그 재료로 무엇이든 만들 수 있다.대학 4년간 배운 것에 한계를 두는 것만큼 우둔한 것이 없으며, 자신이 사회생활을 시작한 그 영역을 벗어날 수 없어서 몸부림친다면, 그 또한 관념의 경계에 발목을 잡힌 것일 뿐이다.엔지니어가 디자이너가 될 수 있으며,마케터가 철학자가 될 수 있어야 하며,교사가 창작자가 되어야 한다.댄서가 프로듀서가 될 때 세계적인 히트 그룹을 만들어내고,시각디자이너가 건축가가 될 때 세상에 없던 위대한 공간이 만들어진다.요리사가 패션을,바리스타가 큐레이팅을,개그맨이 슈퍼레이싱을,건축가가 음악을 넘나들을 때세상은 서로 다른 영역을 이해하고 새로운 것을 접목할 수 있으며, 창의성이 발휘될 수 있다.문과, 이과는 우리에게만 있는 구분이다.고2 때의 결정이 인생의 족쇄가 되어서도 안되며,도대체  누가 '문'과 '이'로 세상을 나누어 이해하는가?세상에 문과와 이과의 구분은 없다모든 경계를 넘나들 수 있는 용기가 있을 때새로운 것이 보인다.어쩌면, 그 영역 안에서만 고민하기 때문에인생이 답답한 것일 수 있다.경계를 지우자.그러면 새로운 세계가 보일 것이다.순간, 몇 사람이 떠오른다.그게 당신일지도 모른다.

기업문화 엿볼 때, 더팀스

로그인

/