스토리 홈

인터뷰

피드

뉴스

조회수 3851

프롤로그: 커뮤니티 매니저, 들어본 적 있나요?

한 번쯤 이 단어를 들어본 적이 있나요? 여러분이 '커뮤니티 매니저(Community Manager)'라는 단어를 들어본 적이 있다면, 이런 공간들을 알거나 방문해본 적도 있을 겁니다. 코워킹 스페이스(co-working space), 공유 공간, 협업 공간, 청년 공간, 마을 공간, 거점 공간 등등 다양한 이름과 형태를 가진 ‘커뮤니티 공간’을 말이죠. 다양한 커뮤니티 공간에서는 '커뮤니티 매니저'를 직업으로 하는 사람들을 만나볼 수 있다. ⓒ wework, 마이크임팩트스퀘어, 아트업서울, 무중력지대G밸리최근 몇 년 간 서울을 비롯한 전국 각지에는 다양한 형태의 ‘커뮤니티 공간’이 빠른 속도로 새롭게 만들어지고 있습니다. 이 흐름은 자연스럽게 공간 운영과 관리를 담당하는 사람들의 등장으로 이어집니다. 바로 ‘커뮤니티 매니저’라고 불리는 사람들이죠.  이들은 때론 공간을 넘나들며 다양한 활동과 문화를 만들어나가며, 커뮤니티 회복과 활성화, 사회적 가치 창출 등을 지향하기도 합니다.물론 각 공간/직무 등에 따라 이들에 관한 호칭은 다양합니다. 하지만 광범위하게 자주 쓰이는 것은 아무래도 ‘커뮤니티 매니저’인 듯합니다. (과연 그 단어가 적절한지 혹은 더 멋진 새로운 단어는 없을지에 대한 고민은 일단 차치하고) 그 낯설고 생소한 이름으로 활동하는 사람들이 ‘커뮤니티 공간’의 양적 확대와 더불어 많아지고 있습니다.    그런데 '커뮤니티 매니저'가 뭐하는 사람이죠?체인지메이커들을 위한 공유주택 '디웰하우스'에도 운영와 커뮤니티를 담당하는 '커뮤니티 매니저'가 있다.  ⓒ 루트임팩트‘커뮤니티 매니저’의 정확한 뜻은 무엇일까요? ‘커뮤니티 매니저’라고 하는 사람들은 구체적으로 무엇을 하고, 어떤 공통적인 특성을 가질까요? 실제로 얼마나 많은 ‘커뮤니티 매니저’들이 어떻게 일하고 있을까요? ‘커뮤니티 공간’과 ‘커뮤니티 매니저’는 또 어떤 관계가 있는 걸까요? 로모는 이제부터 ‘커뮤니티 매니저’와 관련된 여러 다양한 질문들을 던져보려 합니다. 그리고 그 질문의 답을 찾는 여정을 여러분과 함께 시작해보려고 합니다.왜 로모는 ‘커뮤니티 매니저’를 화두로 꺼냈을까요?       최근 연재를 시작한 <처음 만나는 커뮤니티 공간 디자인>에 이어, ‘커뮤니티 매니저’에 관한 이야기를 꺼낸 데에는 이유가 있습니다.그저 하나의 공간(a place)이 아니라 의미를 가진 공간(the place)이 되기 위해서는 다양한 요소들이 필요하다. ⓒ Tim Mossholder on Unsplash물리적 공간뿐만 아니라 그 공간의 정체성과 문화를 만들어가는 ‘사람’에 대한 이야기가 동시에 함께 이루어져야, 새롭게 조성되는 공간이 그저 하나의 공간이 아니라 다양한 사람들과 여러 비물질적인 가치들이 ‘공존’하는 유기적인 공간으로 기능할 수 있기 때문이죠.어쩌면 너무도 당연한 말로 들릴지 모르겠네요. 하지만 로모의 팀원들이 그동안 여러 지역에 수십 개의 커뮤니티 공간들이 조성/운영되는 과정에 직/간접적으로 참여해온 경험을 돌이켜보면, 꼭 그렇지만은 않습니다. 대부분 기획과 조성의 단계 이후 '운영'의 차원으로까지는 논의가 밀도 있게 이어지지 못합니다. 또한 운영주체와 인력의 문제 역시 '인건비 부담' 등을 이유로 크게 축소되어버리기 쉽고, 그나마 배치된 각 공간의 매니저들이 무엇을 어떻게 해야 하는가에 대한 이야기는 제대로 다루어지지 못한 채 "각자 알아서 눈치껏"의 수준에 머물고 맙니다. 실제로 로모의 팀원들이 지난 몇 년간 '커뮤니티 매니저'로 경험했던 현장도 크게 다르지 않습니다. '커뮤니티 매니저'의 정의와 역할은 불분명한 채, 아니 그보다도 "커뮤니티 매니저가 도대체 뭐길래?"라는 질문이 제대로 던져지거나 다뤄지지 못한 채, 일단 '커뮤니티 매니저'라는 이름으로 역할이 주어졌고 잘 수행해야 했습니다.  그렇다면 결국 의지할 곳은 현장뿐입니다. 맨 땅에 헤딩하듯이 때론 조심스럽게, 때론 과감하게 다양한 시도를 이어나가며 끊임없이 데이터를 축적해나갔고, 그 과정에서 소위 '커뮤니티 매니저'에 관한 우리만의 그림을 그려나갈 수밖에 없었습니다. 문제는 수많은 '커뮤니티 매니저'들이 유사한 상황에 처해있거나, 그럴 것이라 추측된다는 것입니다. 관련된 체계적인 교육이나 활용할 수 있는 자원, 서로의 경험과 노하우를 나눌 수 있는 네트워크도 부족하니까요. 결국 공간 운영의 경험과 노하우는 공유되거나 축적되지 못한 채, 커뮤니티 공간이 늘어나면 늘어날수록, 각 공간에서 다시금 '0'에서부터 시작하듯 고군분투하는 매니저들이 늘어날 뿐이죠.  결국은 ‘커뮤니티 공간의 질을 어떻게 높일까?’의 문제   그렇다면 '커뮤니티 매니저'가 해답이 될 수 있을까요?모든 문제를 손쉽게 해결할 수 있는 해답은 존재하지 않습니다. 단순한 결론은 때론 효과적일 수 있지만, 때론 중요한 맥락을 가려버리기도 합니다.‘커뮤니티 공간’이 잘 운영되기 위해서도, 다양한 요소들이 필요합니다. ‘하드웨어(hardware)’, ‘소프트웨어(software)’, ‘휴먼웨어(humanware)’, 이 세 가지 요소들이 각자 제 역할을 다 하며, 조화를 이루는 게 필수적입니다. (이 부분은 로모의 또 다른 브런치 매거진 <처음 만나는 커뮤니티 공간 디자인>에서 좀 더 자세히 전할 예정입니다.)그리고 그중 '휴먼웨어'가 꼭 ‘커뮤니티 매니저’에만 국한된 것도 아닙니다. 수많은 이용자들, 공간문화를 만들어나가는데 적극적으로 동참하는 소위 '단골'들, 유관된 다양한 협력 주체 및 기관들, 이들 모두가 공간의 질을 높이는 데 일정한 역할과 책임, 영향력을 행사합니다. 그래서 커뮤니티 공간은 특정 주체에 지나치게 의존하기보단, 커뮤니티 공간을 제대로 이해하는 다양한 주체들의 활동력과 네트워크에 기반하였을 경우보다 지속 가능할 수 있습니다. 다만 그럼에도 중요하고 분명한 사실은 현장에서 '커뮤니티 매니저'들이 '휴먼웨어'의 핵심을 차지하며, 공간의 '하드웨어'와 '소프트웨어'에도 강한 영향을 미친다는 점입니다. "설계자, 시공자, 운영자가 명확히 구분됐던 과거와 달리 최근에는 설계자, 시공자, 운영자의 간극이 좁아지는 사례가 증가하고 있다. 공간의 성패는 어쩌면 설계자보다 운영자가 쥐고 있는지도 모른다. 운영자의 취향과 캐릭터가 고스란히 반영된 공간을 조성하고 그 공간을 완성시키는 다양한 운영전략을 갖출 때 비로소 건축설계가 완성된다고 볼 수 있다" - 윤주원, 김주원, 김수정 공저 (건축도시공간연구소),  7쪽 中그래서 '커뮤니티 매니저'의 정의와 역할, 필수적인 역량이 무엇인지에 대한 문제들은 "각자 알아서 눈치껏"의 차원을 넘어서서, "커뮤니티 공간의 질을 어떻게 높일 수 있을까?"라는 질문 아래 구체화될 필요가 있습니다. 새로운 직업(군)으로서 커뮤니티 매니저  로모는 이제부터 새로운 직업(군)으로서 커뮤니티 매니저를 바라보고, 그에 대한 이야기를 본격적으로 꺼내보려 합니다. 커뮤니티 공간 안팎에서 벌어지는 A to Z를 발로 뛰며 해결하는 '커뮤니티 매니저'들을 하나의 직업군으로서 접근해야, 각 현장에서 개인들이 부딪히는 문제들과 그를 풀기 위한 각종 시행착오들이 흩어지지 않고 의미 있는 경험 자원으로 재해석될 수 있고, 각 공간 혹은 기관의 장벽을 넘어서서 우리 삶 속의 커뮤니티 공간의 질을 높이는 데 필요한 공유재가 될 수 있습니다. <커뮤니티 매니저가 뭐길래>, 앞으로의 이야기 로모의 새로운 프로젝트 <커뮤니티 매니저가 뭐길래>는 앞으로 구체적으로 이렇게 진행될 예정입니다. 먼저, 현재 일하고 있는 커뮤니티 매니저들의 현장성 있는 이야기들을 수집하고 기록할 것입니다. 여러 이야기 조각들을 짜 맞추어보면, "도대체 커뮤니티 매니저가 뭐길래?"라는 질문에 대한 윤곽이 나오겠죠. 그와 함께 현장의 실무자들이 주요하게 마주치는, 다르게 말하면 앞으로 풀어나가야 하는 구체적인 이슈들도 추려볼 수 있을 겁니다. 각자의 이야기가 모여, 함께 나눌 수 있는 서사가 되는 것이 기본이자 핵심이다 ⓒ Headway on Unsplash이야기들을 모은 다음에는, 이제 제대로 된 판을 만들어볼 차례입니다. 다양한 제안과 대안을 생산해내기 위한 담론장을 열어나갈 예정입니다. 커뮤니티 매니저들을 심층 인터뷰하며 발견한 주요 이슈들을 중심으로, 더 많은 커뮤니티 매니저들과 함께, 혹은 굳이 커뮤니티 매니저가 아니더라도 커뮤니티 공간 운영과 이번 프로젝트에 공감하는 사람들이 모두 모여 상상하고, 제안하고, 토론하는 자리도 열어보려 합니다. 그렇게 얼마간 함께 이야기를 하다 보면, 우리는 어쩌면 함께 발견할 수 있을지도 모릅니다. "커뮤니티 매니저가 뭐길래?"라는 질문의 끝에는, '커뮤니티 매니저'라는 애매모호하고 한정된 언어의 틀을 넘어서서, 우리의 고민들과 방향성을 더 적절히 담은, 더 멋지고 새로운 언어를 말이죠. 언어의 힘은 크니까요. 그 발견의 여정을 이제 시작합니다!  이번 편에서는 매거진 <커뮤니티 매니저가 뭐길래>를 왜 시작했는가에 대한 이야기를 중심으로 솔직하게 풀어보았습니다. 앞으로는 커뮤니티 매니저들의 인터뷰 내용을 바탕으로, 좀 더 구체적인 이야기들을 전할 예정입니다. 다음 편을 기대해주세요 :) 커뮤니티 매니저 심층 인터뷰에 참여해주세요! 서울에서 활동하고 있는 '커뮤니티 매니저'들의 이야기와 생각을 수집하고 있습니다.   인터뷰를 희망하시거나, 주변에 관련 일을 하고 있는 사람이 있다면, 아래 링크를 클릭해주세요! http://bit.ly/whoisacommunitymanagerBY 나무  CCO & Co-Founder다양한 삶의 방식과 공존 사례를 연구하고, 실험합니다. 루시드폴의 노랫말을 좋아합니다.   #로모 #기업문화 #조직문화 #사내문화 #기업소개
조회수 2674

왜 육각형인가요?

작년(2016년) 중순 즈음, 데일리호텔의 로고가 새롭게 리뉴얼되었습니다. 기존에 '데일리호텔'이라는 명칭에 맞게 손바닥 위에 호텔의 아이콘이 올라가 있는 심벌 형태였는데요. 점차 사업의 방향이 더 넓게 확장되고, 데일리가 가져가고자 하는 기업 이념을 보여주고자 기존 형태에서 많이 변형된 현재의 로고가 탄생했습니다.로고 탄생 이후에 계속 듣던 질문. '왜 육각형인가요?'지금부터 그 이유와 심벌에 담긴 데일리만의 철학을 소개합니다.데일리가 가고자 하는 길로고를 제작하기 이전에 우리는 데일리가 걸어온 길이 어디였으며, 나아가고자 하는 방향이 어디인지 확립해야 했습니다. 많은 데이터와 고객 경험 사례들을 분석해본 결과 결국 데일리는 '특별함'에 초첨이 맞추어져 있다는 걸 알게 되었어요.또 위와 같이 정의된 키워드들을 가지고 브랜드 이미지를 시각적으로 표현하기 위해 아래와 같이 디자인 키워드와 표현 원칙을 정의하였습니다.'문'을 통해 '특별함'으로 다가가다데일리의 철학 '언제든 특별해질 수 있다'.그렇다면 그 '언제든'의 정의 또한 필요했습니다. 우리가 언제든 일상 속에서 만나는 동일한 패턴은 무엇일까를 생각하기 시작했어요.추출한 답은 '문'이었습니다.아침에 일어나 방문을 열고 거실에 나와 세면을 하기 위해 화장실 문을 통해 화장실에 들어가고, 현관문을 열고 회사로 향하는 패턴. 우리는 이와 같이 항상 동일한 문을 드나들고 있었습니다. 해서 데일리는 '언제든'을 '문(Door)'으로 정의하여 그 형태를 형상화시켜 쉐입을 제작하였습니다.'일상적인 문'을 뜻하는 쉐입그 반대에는, 일상적인 패턴에서 벗어나서 어디론가 떠나고 싶고, 멋있는 식사를 즐기고 싶어 하는(곧, 데일리가 추구하는) '특별함'을 나타내는 '문(Door)'의 쉐입을 제작하였어요.데일리가 지향하는 '호텔/레스토랑의 문'을 뜻하는 쉐입또한, 우리가 접하는 일상적인 문과, 특별함을 상징하는 호텔/레스토랑 문의 높이를 비교해보면 라이프스타일을 즐기기에 시간적, 금전적 부담을 느끼고 있기 때문에 쉽게 마음을 열지 못합니다. 여기서 데일리는 고객이 느끼는 부담적 마음의 문 높이를 채워줌으로써 라이프스타일에 한층 더 가까워질 수 있도록 조력자 역할을 해줍니다. 곧, 데일리의 미션인 '더 나은 하루, 더 나은 삶을 위해'를 이루기 위한 길이기도 하죠.이로써 견고해진 데일리의 심볼또 이렇게 제작된 심벌은 Connect, Precious, Perfect를 뜻하기도 합니다. 무슨 뜻이냐구요?하나_Connect. 잘 보시면 심벌이 모든 선으로 서로 이어져 있음을 볼 수 있습니다. 이는 고객들에게 특별한 경험을 연결 지어준다는 뜻을 지니고 있습니다.둘_Precious. 문을 형상화하여 심벌을 제작하였지만 완성된 형태를 보면 마치 보석과도 같습니다. 이는 사람들의 하루, 삶에 대해 소중히 여긴다는 뜻을 지니고 있습니다.셋_Perfect. 데일리의 심벌은 안정적인 구조를 지닐 수 있도록 견고한 선으로 균형 있게 제작되었습니다. 이런 심벌에서부터 나오는 완벽함은 탐색부터 예약, 그리고 경험까지 플랫폼으로써 추구하는 완벽함을 뜻합니다.마치며.이제 궁금증이 조금 풀리셨나요?우리는 하루에도 수십 번 많은 CI(Corporate Identity)들과 마주하게 됩니다. 어찌 보면 흔한 것일 수 있지만, 그 안에는 기업의 이념과 철학, 그 외의 많은 것들이 담겨있습니다. 그리고 그 CI가 품고 있는 뜻을 이루고자 지금도 이렇게 열심히 달리고 있는 거고요. 이제, 주위를 둘러보시면 많은 CI들이 각기 다른 미션/비전으로 아우성치고 있을 거예요.(ㅎㅎ) 그럼 다음에 더 재미있는 글로 찾아뵙겠습니다!작성자 : Creative팀 Blair Ahn#데일리 #브랜드 #브랜딩 #디자인 #로고 #디자이너 #인사이트 #일지 #후기
조회수 1479

샌프란시스코 테크 업계 인터뷰 1: Facebook, Fivestars

제품을 담당하는 팀이 일하는 방식은 제품 그 자체에 영향을 줍니다. 어떠한 기능을 어떤 주기로 사용자에 배포할 것이냐에 대한 결정을 하는 과정이기 때문에 구체적인 결과물에 영향을 끼치기도 하지만 누가 기능을 만들고 디버깅 하고 그 업무에 대한 조직의 시각에 따라 결과적으로는 제품의 품질에도 영향을 미칩니다.구태의연한 말이지만 테크 업계에서 일하는 방식에 있어 정답은 없습니다. 제품과 조직은 끊임없이 변화하고 이에 맞추어 일하는 방식도 바뀌어야 하기 때문에 지난 해에 불합리하다고 여기던 방식이 올해는 검토해 볼 만한 것이 될 수도 있습니다. 일하는 방식 그 자체도 협의를 거쳐 지속적으로 개선하는 과정이 필요합니다.일하는 방식과 함께 제품 그리고 조직마다 프로덕트 매니저의 역할과 권한도 바뀝니다. 비즈니스에 제품이 기여하는 정도에서부터 조직 내 이해관계자와의 관계까지 제품과 조직의 모든 요소가 프로덕트 매니저의 일하는 방식을 바꿉니다. 스포카 프로덕트 매니저의 경우, 서비스 백로그 관리의 역할도 담당하기 때문에 유동적인 일하는 방식에 따른 결과는 제품에 다시금 반영됩니다.이번 샌프란시스코 테크 업계 인터뷰는 위와 같은 가정 하에 ‘스포카는 앞으로 어떤 방식으로 일할 것인가’라는 질문에 대한 참고할 사례를 수집하기 위하여 진행하였습니다. 닭과 계란 문제일 수 있지만 이것은 ‘스포카는 어떤 제품을 만들고자 하는가’하는 고민과 맞닿아 있습니다.인터뷰는 총 5회에 걸쳐 아래와 PM 분들과 진행 되었습니다. 흔쾌히 인터뷰에 응해 주신 모든 분들께 감사드립니다. 각 인터뷰이와 나눈 이야기 중 인상적이었던 부분을 발췌하여 2개의 포스팅에 걸쳐 공유하겠습니다.Stephanie Shum(Director Product Management at Facebook)David Park (Refereum COO)Michael Hsu (Product Manager at FiveStars)Chris Nguyen (VP Product at Bleacher Report)홍성철 (Product Manager at Udemy)정대영 (Product Manager at Intuit)Stephanie Shum(Director Product Management at Facebook) & David Park (Refereum COO)좌측에서부터 Stephanie Shum, 옥지혜, David Park제품팀에 대한 동기부여는 PM의 중요한 역할 중 하나입니다. 팀에의 동기부여를 어떻게 하나요?S: 모든 제품팀의 구성원은 실제 사용자가 사용하는 제품을 만들고 그것이 비즈니스 임팩트가 있을 때 신나게 일할 수 있다. 그리고 제품이 전달하는 가치가 유의미하고 수익을 창출할 때 즐거워한다. 실제 사용자를 만날 수 있는 기회를 제공하고 팀에서 작업한 내용의 비즈니스 임팩트를 지속적으로 공유해야 한다.D: 엔지니어로 일할 당시에 중요하다고 생각하지 않는 것을 만들고 심지어 배포도 하지 못했을 때 가장 의욕이 떨어졌다. 진행 중인 작업의 사업적인 의미를 알리거나 테스트를 진행하는 이유를 팀에 설명할 수 있어야 한다. 사람들은 똑똑하고 쓸모 없는 것을 만드는 일을 싫어한다. 엔지니어를 이해하는 것은 매우 중요하다. 모든 엔지니어와의 원온원 면담을 진행하여 팀의 상태를 알고 그들이 행복할 수 있도록 노력해야 한다.S: 사람을 움직이는 것이 무엇인지 알아야 한다. 어떤 사람은 제품에 대한 스토리텔링에 흥미를 가지기도 하고 데이터 기반의 설득이 효과적인 사람도 있고 신기술에 관심을 보이는 사람도 있다. 나는 각자의 자기효능감을 느낄 수 있도록 실제 사용자와 대면하는 경험을 주는 것이 중요하다고 생각한다.제품팀이 잘 하고 있는지에 대하여 어떠한 잣대로 평가하나요?S: 제품팀이 행복하고 제품이 목표를 달성하고 있다면 잘 하고 있는 것이다. 페이스북은 서로에 대한 피드백에 대하여 열린 편이라 의견 교환이 빠르게 자주 이루어진다. 제품팀의 직무 만족도에 있어 업무 외적인 부분도 PM이 관장하는 영역이다. 이를테면 모종의 이유로 팀의 분위기가 침체 되었을 때 팀 전체 티타임을 가지면서 휴식할 수 있도록 유도하는 것도 PM의 역할이다. 어찌 보면 PM의 역할은 파티 플래너와 같다.D: 제품팀의 모든 평가는 제품의 비즈니스 임팩트에 달려있다. 유능한 피엠은 적절한 시점에 제품에 필요한 기능을 배포하는 데에 있다.제품의 목표를 달성하지 못했을 때의 경험을 공유 해주세요.S: 목표 달성을 하지 못함으로 인해서 무엇을 얻었는지가 명확하다면 그것은 실패가 아니다. 이를테면 페이스북의 경우, 매해 안정적으로 셧다운 했거나 유의미한 실패를 한 팀의 PM에게 상을 준다. 특정 팀은 수립된 전략에 따라 제품을 만들었다. 결과적으로는 목표를 달성하지 못했는데 개발 과정에는 문제가 없었으나 수립된 전략의 재검토가 필요하다는 결론이 났다. 그 팀의 PM이 그 해의 수상자였다.기술 조직이 아닌 팀과의 커뮤니케이션은 쉽지 않습니다. 영업 조직과의 커뮤니케이션에 있어 팁이 있나요?S: 제품팀의 인원이 주기적으로 현장에서 실제 사용자와 주변환경을 마주할 수 있도록 하자. 영업 조직에게 제품팀이 영업환경에 대하여 진지하게 생각한다는 것을 보여줄 필요가 있다. 반대로 영업과 사업개발 조직은 사용자 피드백의 필터가 되어야 한다. 이들은 수많은 의견을 청취하지만 모든 내용을 제품팀에 전달하지 않아야 한다. 비즈니스상 필요하다고 생각하는 몇 가지를 추려 제품팀에 전달하고 제품팀은 이를 실행할 수 있는 계획을 세우는 일을 담당한다. 서로의 일에 대한 존중과 공감 그리고 제품과 사용자와의 밀접한 관계를 언제나 염두에 주는 것이 중요하다.D: 인정 역시 중요하다. 제품팀의 인원을 포함하여 기술 조직이 아닌 팀과의 협업이 있는 프로젝트가 런칭한 경우, 모두가 볼 수 있는 메일 등을 통해 감사를 전하는 것도 팁이다.Michael Hsu (Product Manager at FiveStars)Fivestars 인터뷰 진행을 위해 게스트 체크인 중스스로가 유능한 PM이라는 것을 어떤 잣대로 평가 하나요?M: PM의 역할과 권한은 제품마다 그리고 조직마다 모두 다르다. 과거의 경험을 미루어 볼 때, 회사의 규모를 불문하고 PM은 그 자신이 제품의 성공을 책임 지는 사람이다. 따라서 구체적으로 무슨 일을 하는지 보다는 제품이 성공하기 위해서라면 다양한 일을 해야 한다.나는 3가지를 중점적으로 생각한다 - “제품(팀)이 사업목표에 기여하고 있는가”, “제품(팀)이 각 고객에게 유의미한 가치를 전달하고 있는가”, “각 팀(원)이 자신이 이루고자 하는 바를 달성하고 있는가”. 자원이 한정적이라는 것을 언제나 잊어서는 안된다. 최대의 비즈니스 임팩트를 낼 수 있는 선택을 해야 하고 이를 하기 위해 업무에 우선순위를 부여함에 있어 단호 해야 한다.현재 담당하고 있는 팀의 구성은 어떻게 되어 있나요?M: 제품팀만 두고 보았을 때, 전체 인원 중 10%가 운영만을 전담하는 팀이다. 영업인원 대비 비율은 1:7 정도에 해당한다. 이외의 팀은 각자 새로운 기능을 만드는 업무를 담당한다. (서비스 특성 상 버그가 많을 수 밖에 없는데, 운영 팀의 동기부여는 어떻게 하는지?) 우리 조직의 경우 신규 기능 개발 보다 기존 서비스 유지보수에 엔지니어들이 관심이 많다. 실제 사용자가 사용하는 것을 보고 왔을 때는 더욱 그러한 편이다.조직 내 PM이 모자라는 상황일 때 어떤 방식으로 일할 수 있을까요?M: 권한을 위임한다. 유저 스토리 작성, 기능 요구사항 구체화 하는 일 등 가시화 되지 않는 일지만 반드시 진행해야 하는 일을 팀원에게 위임하는 방법이 있다. 이 때 각 기능의 개발을 위한 비용과 시간 계산 등에 대한 책임도 함께 질 수 있도록 하는 것이 좋다.기능에 대한 요구사항은 어떻게 수렴하나요?M: 각 팀 단위로 스프린트에서 진행할 티켓을 정하고 백로그 관리를 담당하게 된다. 이 절차는 기술적인 요구사항이 한정적인 자원 안에서 처리 된다는 점과 비즈니스 임팩트의 여하에 따라 우선순위를 정하는 협상의 과정이라는 것을 가시화 한다는 점에서 유효하다. 요구사항을 발의 하는 사람은 어떠한 배경에서 해당 기능을 제안을 하고 그것이 가져올 비즈니스 임팩트에 대한 내용을 포함하여 발의할 수 있어야 한다.우선순위를 결정함에 가장 중요한 잣대는 비즈니스 임팩트를 얼마나 발생시킬 수 있느냐이다. 운영팀이 대응할 버그를 결정함에 있어서도 데이터를 기반으로 한다. 신규 기능에 대한 요구사항은 이 회의체에 접근하기 이전에 필터링 되어 발의되며 마찬가지로 기존 업무와의 우선순위를 조정하여 스프린트 항목을 정한다.Chris Nguyen, 홍성철님과 정대영님의 인터뷰와 인터뷰를 통해 얻은 인사이트는 다음 포스팅에서 다룹니다. 마지막으로 스포카는 현재 제품을 함께 만들어 나갈 PM을 채용 중입니다. 관심 있으신 분들의 많은 지원 부탁 드립니다.#스포카 #기업문화 #조직문화 #팀원소개 #인터뷰 #회사소개
조회수 5198

유명기업 채용 면접 전에 결산 보고서를 꼭 보아야 하는 이유

 오늘은 스타트업에서 약간 벗어나, 증권사 재직 시절에 느꼈던 것을 써보려고 한다. 증권사에 있던 시절, 취직을 준비하는 대학 후배들의 상담을 꽤 많이 받았었다. 그리고 나는 지망하는 기업이나 이유를 말해오는 후배들에게 늘 한 가지 질문만을 던졌다. '그래서 유가증권보고서는 읽어봤니?' 유가증권보고서, 한국식으로 하면 결산 리포트, 실적 보고서, 사업 보고서 등에 해당하는 이 자료들은, 사실 너무나도 '좋은' 것들이다. 지금부터 이것들이 왜 좋은지를 전하고자 한다.1. 사실 기업은 투자자에게 거짓말을 할 수 있다 우리는 '기업' 또는 '회사'라는 조직에 알게 모르게 부정적인 이미지를 투영하는 경향이 있다. 거짓말쟁이, 사기꾼, 돈에 눈이 멀어 인륜을 저버리는 집단. 우리가 "XX기업이..."라고 시작하는 뉴스가 나오면 "내 저런 놈들일 줄 알았어!"라고 외치는 이유다. 물론 기업은 거짓말을 할 수 있고, 자신의 이익을 위해서라면 얼마든지 거짓말을 하고싶어 한다. 그러나 그 거짓말이 들킬 경우, 목숨을 주고도 바꿀 수 없는 신용이라는 것을 가장 먼저 잃게 된다. 상장폐지나 벌금, 영업정지 같은 건 신용의 추락에 비교하면 사실 사소한 것이다. 그래서 제대로 된 기업은 거짓말을 할 수 있지만 하지 않는 쪽을 택한다. IR자료는 그 중에서도 가장 중요한 문서 중 하나이다. 투자자들, 달리 말하면 기업의 일부를 소유한 사람들에게 현재 기업의 상황이 어떤 지를 보고하는 자료이기 때문이다. 다시 바꾸어 말하면, IR자료에 거짓을 말하는 기업은 자기 가족을 속여 보증을 세우는 가장이나 다를 바 없다. 그래서 IR자료는 믿을 수 있다.2. 잠긴 빗장을 푸는 마법의 열쇠 당장 생각나는 기업 하나를 떠올려 보자. 만약 그 기업이 KOSPI, KOSDAQ, TOPIX, NYSE 등등, 어떤 증권시장에라도 상장되어 있다면, 그 기업은 한 겹 내지는 두 겹의 성문을 열 수 있는 열쇠를 던져놓은 것이다. 물론 그 성문을 열었을 때 눈앞에 지문인식 센서가 있거나 할 순 있지만, 대부분의 구직자들이 한 겹의 성문도 뚫지 못하고 나가떨어지는 걸 생각하면 굉장한 기회가 열린 것이라고 할 수 있지 않을까. 다소 과장된 표현이라고 생각할 수 있겠지만, 효과는 확실하다. 어떤 기업의 한 사업부가 적자를 냈다고 가정하자. 그 기업이 꽤나 유명하다면, 온갖 포털의 경제뉴스란에 원인을 말하는 기사들이 줄지어 올라올 것이다. 해외 경쟁업체 A사와의 가격경쟁에서 밀렸다, 국내의 수요가 준 것이 큰 영향을 끼쳤다, 중국과 미국의 무역전쟁에 따른 심리적 위축이 컸다....문제는 이 뉴스들이 다 맞을 수도 있고, 다 틀릴 수도 있다는 것이다. 오늘 내가 약속시간에 늦은 것은, 늘 같은 시간에 타던 버스가 그날만 늦게 와서일 수도 있고, 5분만 더 자겠다고 욕심을 부렸기 때문일 수도 있고, 유난히 화장이 안 받아서 눈썹만 30분째 그렸기 때문일 수도 있다. 여기서 중요한 건 남들이 어떻게 생각하느냐가 아니라, 내가 어떻게 생각하느냐이다. 사업 보고서, 결산 보고서 등을 보면, 결산 결과에 대한 그 기업의 관점이 어떤 지를 바로 알 수 있다. 국내 굴지의 대기업인 모 회사는, 5년째 마이너스 이익률을 기록하고 있는 XX 사업부에 대해 실적 발표 자료에서 다음과 같이 평하고 있다. '신모델의 출시 시기가 2분기로 결정됨에 따라 매출은 전년 동기 대비 감소' '신모델 부재에 따른 매출 감소, 재료비 압박 등 이슈에도 불구하고 OOO 디자인 강화를 통한 원가 구조 개선 노력 등으로 전분기 대비 적자폭 축소' 이 기업은 매출이 줄었지만 그 나름의 타당한 이유가 있었으며, 적자가 났지만 지난 분기보다 적자폭이 줄었으니 그래도 선방했다는 관점을 갖고 있는 것이다. 그리고 사업 보고서를 보면, 국내외의 시장 여건이나 원가 절감 요소, 경영 상황 등에 대해 회사의 입장을 말하고 있다. 다시 말하지만, 이 문서들에는 거짓말을 해선 안된다. 기업이 생각하는 시장 상황과 타개책이 적나라하게 드러나는 문서인 것이다. 그들 자신이 느끼는 그대로를 보는 만큼 상대를 깊게 이해할 수 있는 방법이 세상에 또 어디 있겠는가?3. 당신이 내일 만날 사람의 3/4은 '나와 같은 의견을 가진 사람은 없을까'하며 필사적으로 찾고 있다 앤드루 카네기의 말이다. 그리고 이 뒤에는 '이 염원을 들어주는 것이 남의 호의를 사는 비결이다'라는 말이 이어진다. 이 글을 읽는 당신이 위에서 언급한 국내 굴지의 대기업에, 하필이면 5년 연속 적자를 내고있는 XX 사업부에 지원하여 면접 기회를 얻었다고 하자. 그런데 면접관이 이런 질문을 한다. "본인의 경험이나 경력이 우리 회사가 겪고 있는 어려움에 어떤 도움이 될 수 있을까요?" 당신은 말한다. "XX 사업부가 5년 연속 적자라는 뉴스를 봤습니다. 저는 해외 원자재 가격의 상승이 그 원인이라고 생각하고, 저의 해외 유학이나 해외 생활 경험이 이러한 원자재 조달 루트의 다양화에 기여하여 가격 경쟁력 확보에 도움을 드릴 수 있을 것이라고 생각합니다." 당신이 '잘 대답한 것 같아'라며 안도의 한숨을 쉬고 있을 때, 갑자기 옆 자리에 앉은 친구가 손을 든다. "저는 XX 사업부의 적자가 지속되고 있지만, 전년 동기 대비 적자폭이 줄고 있는 점을 생각하면 개선이 가능하리라 생각합니다. 특히, 새 모델의 출시가 연기되었는데도 이런 성과라면, 새 모델이 출시될 경우 더 큰 효과가 있을 것 같습니다. 저는 대학시절 마케팅 동아리에 있던 경험을 살려서, 이 모델의 마케팅이나 기획 면에 도움을 드릴 수 있을 것으로 생각합니다." 축하한다. 당신은 지금 다른 회사에 가서 면접을 볼 수 있는 소중한 기회를 얻었다. '귀하의 능력은 뛰어나나 아쉽게도 당사의 방향과 맞지 않아...'라는 정성 가득한 메세지를 받게 되는 것은 덤이다. 물론 면접관의 생각이나 판단이 꼭 결산 자료에 나온 것과 일치하는 것은 아니고, 사실 자기 회사 IR자료를 꼼꼼하게 읽어보는 사람도 별로 없다. 하지만 대부분의 기업은 결산 결과가 나왔을 때 그것을 전 임직원에게 전파하고, 앞으로의 사업 방향이나 힘을 주어야 할 분야에 대해서 공유한다. 우리가 결산 보고서에서 읽은 그 내용은 면접관도 비슷하게나마 접했을 가능성이 매우 큰 것이다. '나는 당신과 같은 방향을 바라보고 있어요'라는 메세지를 심어주는, 아니 심어줄 수 있다는 가능성만으로도, 면접 전에 IR자료를 읽어볼 가치는 충분하다.4. 믿고 거르는 회사를 판별하는 방법 이건 조금 어려울 수도 있다. 대차대조표, 손익계산서, 캐쉬플로우의 의미를 읽을 줄 아는 정도의 지식이 필요하기 때문이다. 하지만 결산 보고서에서 발견한 숫자 하나가 당신의 커리어를 좌우할 수도 있다는 건, 일단 사실이라고 생각한다. 우선, 최근 3년간의 자료 정도는 죽 놓고 훑어보는 게 좋다. 연결재무제표는 어려울 수도 있으니, 단일 재무제표만 놓고 보아도 좋다. 중요한 건 흐름을 파악하는 것이다. 가정법을 너무 자주 쓰는 것 같은 느낌이 좀 들지만, 어쨌든 W라는 회사가 있다고 치자. W사는 지난해 영업이익이 적자로 돌아섰고, 올해에도 적자폭은 그다지 변하지 않았다. 대차대조표상 고정자산은 줄어들었고, 유동부채는 늘었으며, 캐쉬플로우에서 투자로 인한 현금흐름이 -2500백만원에서 +2500백만원이 되었다.  W사는 어떻게 될까? 길어봐야 3년 이내에 이 회사는 매각수순을 밟거나 도산하게 될 것이다. 사실 은행의 여신업무를 담당하는 사람들이 가장 집중적으로 보는 것이 이 세 가지 지표이다. 우리가 여신담당 은행원 수준의 지식을 갖출 순 없겠지만, 숫자의 흐름을 파악하는 것으로도 이런 불량기업을 피해가는 것은 충분히 가능하다. W사는 사실 설명을 위해 대충 지어낸, 아주 알기 쉬운 케이스이지만, 생각하는 방향은 크게 다르지 않다. 대차대조표상 고정자산이 줄고 유동부채가 늘었다는 말은 건물이나 땅, 설비를 팔아서 단기적으로 돈을 융통했다는 뜻이다. 투자로 인한 현금흐름이 0이거나 오히려 플러스라는 것은 새로운 설비 투자나 R&D에 전혀 돈을 쓰지 못하는 상황이라는 뜻이며, 영업이익의 적자폭은 변하지 않았다지만, 이 회사가 새로운 성장동력을 얻거나 기적의 한 수를 두어 회생할 확률은 한없이 0에 가깝다. 운도 노력하는 사람에게나 따라주는 것이다. 이 회사는 지금 억지로 숨만 붙여놓은, 굉장히 위중한 상태이다. 만약 당신이 W사에 채용되어(채용을 진행할 수나 있을 지 의문이지만) 출근하게 된다면, 어느 날 아침 사무실이 풍비박산나고 채권자들이 몰려들어 아우성을 치는 모습을 보게 될 것이다. 그 전에 슬슬 월급이 밀리기 시작하며 음습한 기운이 사무실에 감도는 것을 볼 수도 있다. 믿고 거르는 회사를 믿고 거르기 위해서도, IR자료는 큰 도움이 된다.5. 기업은 거짓말'은' 하지 못한다 다시 거짓말 이야기로 돌아왔다. 이 단락에서 말하는 것들을 실천할 수 있다면, 아마 금융업계 경력이 있거나 관련 자격증을 따기 위해 열심히 공부하는 사람 정도는 될 것이라고 생각한다. 사실 여기서부터는 사실을 판단하는 능력도 중요하지만 날카로운 감각이 조금씩 중요해지는 시점이다. 이 단락은 그냥 '이런 것도 하네' 정도로 보면 될 것 같다. 기업은 투자자에게 거짓말을 하지 못한다. 했다가 걸렸을 때 잃는 것이 너무 크기 때문이다. 하지만 세상엔 자기합리화라는 것이 존재한다. 저 위로 다시 올라가서, 국내 굴지의 대기업을 또 끌고 내려와 보자. 해당 회사는 '신모델의 출시가 늦어져 매출이 감소했다'고 말했다. 그런데 새 모델이 출시된다고 매출이 늘 거라는 보장은 사실 없다. 모 회사가 만약 가구 회사라면, 침대의 신모델이 나왔다고 폭발적인 판매량을 기록하는 일은 없을 것이다. 업계의 특성과 시장의 상황을 종합적으로 판단하여, 이 기업이 어떤 스탠스를 취하고 있는 지 살펴볼 수도 있다. '진실을 말하고 있다'와 '거짓을 말하고 있지 않다'는 전혀 다른 것이기 때문이다. 앞서 말한 대차대조표, 손익계산서, 캐쉬플로우 세 가지를 보며 보다 논리적이고 정확한 분석을 할 수도 있다. 증권사 재직 시절 연수를 받으러 갔을 때, 밑도 끝도 없이 재무제표를 던져주고 '이 기업에 대해서 논해라'라는 과제를 받은 적이 있다. 그리 큰 자랑은 아니지만, 대강 10개 중 8~9개의 기업을 이름까지 다 맞춰내었던 기억이 난다. 8개였나 9개였나는 잘 기억이 안 난다. 만약 9개라면 좀 더 내 콧대가 높아지겠지. 여튼 여기서 하고 싶은 말은 자기 자랑이 맞지만, 또한 숙련된 사람이라면 그것만을 가지고도 이 기업이 어떤 기업인가, 무엇을 하는가, 최근 상태는 어떤가를 알아낼 수 있을 정도로, 기업의 모든 것을 낱낱이 파악할 수 있는 것이 IR 자료라는 뜻이다. 더 팀스는 채용을 '끌리다, 만나다, 일하다'의 세 단어로 규정한다. 그리고 '채용에 설렘을 더하다'라는 캐치프레이즈도 즐겨 쓴다. 여태 신나게 복잡한 말 늘어놓고 갑자기 뭔 소리냐는 생각이 들겠지만, 난 이 캐치프레이즈들을 아주 좋아한다. 유가증권보고서를 앞에 놓고 기업에 대해 하나하나 알아가던 그 때의 설렘, 그 때의 흥분이 되살아나기 때문이다. 나는 스타트업이 아니더라도 채용에 설렘을 더할 수 있다고 생각한다. 마치 기업과 소개팅을 하듯이, 기업에 대해서 알아보고, 기업의 마음에 들기 위한 노력을 한다. 당연히 내가 마음에 안 드는 기업을 거절할 수도 있는 것이다. 그리고 IR자료는, 기업이 소개팅 상대라고 했을 때, 말하자면 어릴적 편식하던 음식이 무엇인가까지 시시콜콜하게 알아낼 수 있는 상당히 좋은 방법이다. 모든 IR자료는 딱딱하고 어려운 문장의 나열에, 알 듯 모를 듯한 단어와 수많은 숫자들이 어지러이 오간다. 처음 보는 사람은 대체 무슨 말을 하는 건지 이해도 제대로 못 할 정도다. 하지만 매력적인 사람들은 대부분 어렵지 않던가. 우리가 사람의 마음을 얻기 위해 그 사람을 연구하듯, 기업의 마음을 얻기 위해 기업을 연구하는 것도 그리 나쁘지 않을 것이다.#더팀스 #THETEAMS #IR자료 #면접 #꿀팁 #취업준비
조회수 1386

8.22 근황

안녕하세요.집에서 공항까지, 공항에서 집까지 오가는 분들이 위한 카쉐어링 서비스 벅시 입니다.업데이트가 매우 뜸한 것이 아닌가 하는 의문이 드시겠지만, 사실 지난주는 매우 바쁜 나날이었습니다.몇몇 있었던 일들을 간략히 소개해드리고자 합니다. 업데이트도 곧 하겠습니다...1. 우리 앱의 기능 개선은 물론이고 전반적인 앱 기획을 맡아주실 기획자 분께서 새로 조인하셨습니다.그동안 내부에서 격렬한 회의를 통해 두서없이 진행되던 부분이 이제 각 잡고 진행이 되겠군요 후후후참고로 여자분입니다!!(...소곤)2. 명함을 새로 만들었습니다. 사실 실물이 막 나온건 아니고 디자인만 완료된 것이지만...저는 그동안 명함 없이 사람 만나고 일하고 막 그랬습니다. 그냥 회사 뛰쳐나가도 아무도 모를겁니다.사실 우리 대표님께서는 기존에 사용하던 명함을 보여주시며 '아...이건 좀 아니지 않나요...' 하며저에게 강제로 새로운 명함을 만들 것을 지시하셨습니다.하하하 시키면해야죠 뭐... 하하하 하하하3. 회사 홍보 영상 촬영이 있었습니다. 저희를 품어주시는 롯데엑셀레이터 분들의 지원으로 홍보 영상을 찍게 되었는데요.칙칙한 남자들 밖에 없어서 매우 걱정하였으나, 롯데엑셀 인턴분들이 흔쾌히(!) 모델을 지원해주셔서영상이 매우 잘 나올 것으로 기대됩니다.다만 회사 내부를 촬영하는 부분에서 손발이 오그라드는 연기를 보여주신 분들 때문에 걱정이네요.특히 막 대표님이 이상한 소리 하면서 촬영된 회의 씬은 현장에 있기 차마 힘들 지경이었습니다...다행히 음성은 영상에 추가가 안된다고 하니 불행 중 다행이랄까...촬영현장 미공개 컷 살포시 공유합니다.인터뷰 준비중이신 대표님, 참고로 저희는 대표님이 두 분이시며 명함과 이상한 연기를 하신 대표님은 다른 분입니다...야외촬영, 혹시라도 누가 방해할까봐 조마조마...저희는 더 좋은 서비스를 제공해 드리기 위해서 열심히 일하고 있습니다.언제나 낮은 자세로 여러분들의 말씀을 듣겠습니다.교통 플랫폼으로서 벅시가 성장하는 그날까지 화이팅~#벅시 #스타트업일상 #운영 #성장 #일지
조회수 732

[Buzzvil Culture] Buzzvil FUN Club

 “All work and no play make Jack a dull boy.”  이 격언은 사람이 온전히 성장하는데 있어서 열심히 배우는 것 만큼이나 잘 노는것도 매우 중요하다는 의미인데요. 이를 회사에 적용해보면 개개인이 주어진 업무에 최선을 다하는 것 만큼이나 회사에서 즐겁게 생활 하는 것이 개인과 회사의 성장에 중요한 역할을 한다는 의미로 볼 수 있습니다. 하지만 회사는 본질적으로 업무를 하는 곳이기에 직원들이 즐거워하는 회사를 만드는 것은 어쩌면 직원들이 열심히 일하는 회사를 만드는 것보다 더 어려운 일일지도 모릅니다. 버즈빌에는 그 쉽지 않은 일을 스스로의 손으로 이루어 가는 직원들이 있습니다. 직원의 입장에서 좀 더 즐거운 회사를 만들기위해 노력하는 버즈빌 펀클럽을 소개합니다! 버즈빌 펀클럽은 2014년 어느 날, “더 즐거운 버즈빌을 만들어 보자”라는 생각으로 5명의 버즈빌리언들이 의기투합하여 자생적으로 만들어졌습니다. 그 이후로 매달 있는 전체 회식의 다양한 프로그램은 물론 해외 오피스 직원들과 모두 함께 떠나는 글로벌 워크샵, 버즈빌리언들의 열정을 확인 수 있는 운동회, 한해를 마무리하는 송년회까지 다양한 행사들을 직접 기획하고 실행하며 더 즐거운 버즈빌을 만들기 위한 활동들을 계속해 오고 있습니다. 그동안 수많은 버즈빌리언이 펀클럽을 거쳐갔고 2018년 6월 현재에는 소속된 팀도, 하는 업무도 각양각색인 8명의 버즈빌리언들이 펀클럽의 멤버로 활동하고 있습니다.[Image] 이번달 회식 결정을 위한 펀클럽 회의   매달 1~2회 진행되는 펀클럽 회의는 더 새롭고 즐거운 버즈빌을 위한 다양한 의견들이 오가는 자리입니다. 이 회의가 더욱 의미가 있는 점은 회의 결과가 단순히 의견 제시에서 끝나는 것이 아니라 회사의 의사결정으로 이어지기 때문입니다. 매 달 진행하는 전체회식은 펀클럽회의에서 결정된 컨셉과 방향대로 진행하고 있고 지난 3월에 있었던 2018년 해외워크샵의 경우에도 워크샵 장소부터 숙소, 세부 일정, 단체 액티비티 등 다양한 부분에 펀클럽 회의에서 나온 의견들이 반영되었습니다. 이처럼 버즈빌리언들이 함께 어울리고 즐거운 경험을 할 수 있는 다양한 일들에 대한 고민들을 해나가는 곳이 바로 펀클럽이라고 할 수 있습니다. [Image] 야외 회식을 위한 장보기도 펀클럽의 몫   하지만 누군가를 즐겁게 한다는 것이 늘 좋은 일만은 아닙니다. 개성가득한 70여명의 버즈빌리언들이 모여있는만큼 모두가 즐거워 할 만한 행사를 기획하는 것도 쉽지 않은데다가 펀클럽 활동에 대한 특별한 혜택이 있는 것도 아니기 때문입니다. 그럼에도 불구하고 펀클럽이 계속해서 유지되는 이유는 무엇일까요? 그 이유의 중심에는 버즈빌 문화에 대한 주인의식이 있는게 아닐까 합니다. 우리가 원하는 버즈빌의 문화를 우리의 손으로 만들어 간다는 생각, 즐거운 회사는 누군가에 의해 만들어지는 것이 아니라 스스로 만들어 가야한다는 생각, 정말 좋은 사람들과 함께 더 재미있는 일들을 해보고 싶다는 생각들이 모여서 지금의 펀클럽을 그리고 지금의 버즈빌의 문화를 만들어 왔다고 생각합니다. 그렇기에 편클럽의 활동이 가지는 의의는 더 큽니다. 멤버들 스스로가 모여서 회사를 단순히 업무의 공간이 아닌 즐거움의 공간으로 만들어 나가려는 시도이기 때문입니다. 그리고 이런 시도들은 버즈빌 전체에 에너지를 불어넣는 일이기도 합니다. 앞으로도 적극적인 지원을 통해 펀클럽이 버즈빌의 문화로서 잘 정착되어 나가기를 바라봅니다. 다가오는 여름에도, 뻔하디 뻔한 회사생활을 Fun하게 만들어 가려는 버즈빌 펀클럽의 활약을 기대해 주세요 ! 
조회수 3945

트렐로를 이용한 브랜디 통합관리

Overview언제나 그렇듯 글을 쓰는 건 가장 어려운 것 중에 하나다. 평소에 글을 쓸 기회가 있는 것도 아닌 데다, 재밌게 쓸 재주도 없기 때문이다. 게다가 원고 마감만 다가오면 ’개발자가 아닌데 기술 블로그에 무엇을 써야 하나’ 하는 정체성의 혼란도 겪는다. 그래도 마감은 지켜야 하는 법! 고민 끝에 PMBOK(Project Management Body of Knowledge, 프로젝트관리지식체계)를 기준으로 브랜디에서 프로젝트 매니징하는 방법을 이야기하고자 한다. 브랜디에서는 어떻게 할까?브랜디에서 통합관리(Project Integration Management)는 트렐로(Trello)로 진행한다. 통합관리에 대한 자세한 설명은 이전 포스팅인 PM, 대충하면 큰일납니다(1)의 1번 항목을 참고하면 되므로 생략하겠다. 브랜디는 R&D본부를 제외하고 15개의 팀으로 구성되어 있다. 각 팀은 저마다의 KPI를 달성하기 위해, 개발을 요청하는데 생각해보라. 팀마다 하나씩만 요청해도 R&D본부는 15건의 개발 업무를 진행해야 한다. 아찔하다. 자칫 헷갈릴 수도 있다. 그렇기 때문에 각 팀의 요청은 무엇인지, 언제까지 진행해야 하는지 등 한눈에 보이도록 정리하는 건 당연한 일이다. 트렐로는 소리 없는 아우성으로 가득한 통합관리를 완벽히 정리해주는 도구다. 트렐로 화면 일부우선 위의 이미지처럼 각 팀별로 중요한 개발 요건들을 카드로 만든다. 요청한 개발 내용과 건수를 한 번에 파악할 수 있다. 하지만 더 중요한 건 요청에 대한 우선순위를 지정하는 것이다. 빨리 요청한 업무가, 빨리 처리되는 건 아니다. 어느 회사나 개발 자원은 한정되어 있기 때문에 조직은 가장 효율적으로 운용할 수 있는 방법을 찾아야 한다. 그 방법 중에 하나가 우선순위를 지정하는 것이다. PM팀은 매주 월요일마다 팀별 개발 요건 카드들을 나열하고 우선순위를 정한다. 그리고 그 다음에 프로젝트 계획서를 만든다.[정리]효율적인 통합관리를 위하여1) 요청한 개발 내용들을 카드로 만들자, 이쪽저쪽 옮기기 쉽게!2) 가장 중요한 업무를 파악해 우선순위를 지정하자.3) 프로젝트 계획서를 만들자.정리, 정리, 또 정리서두에서는 15건의 개발 요건만 예로 들었지만, 세상 일이 그리 호락호락하진 않다. 하루에도 수십 개의 요청카드가 쌓이는 걸 보면 이따금씩 타노스의 능력으로 삭제 버튼을 클릭하고 싶은 마음이 굴뚝같다. 그래도 어쩌랴. 이왕 하는 거 깔끔하게, 그리고 가능한 헷갈리지 않게 해야 한다. 여러 팀이 함께 쓰는 보드인 만큼 PM팀의 역할이 중요하다.1. 프로세스를 잡자!여러 팀과 미리 약속을 잡아두지 않으면 혼선이 생기기 마련이다. 개발 요건 카드는 이리저리 날아다닐지도 모른다. 트렐로를 세팅할 때, PM팀은 카드들이 날아다니지 않도록 List를 설정해야 한다. 브랜디에서 세팅했던 초기 List는 아래와 같다.1) 팀별 요건 List팀마다 List가 있다. 트렐로에 참여한 직원들은 각자가 속한 팀의 List 외에는 건들지 않아야 한다. R&D본부에서 요건을 처리할 때마다 카드가 이동되기 때문에 처음 카드를 만들 때 요청자의 팀명과 중요도 등을 정확히 기재하면 좋다. 더 나아가 아예 카드에 적을 양식을 미리 정하면 다른 팀과 R&D본부 모두 평화롭게(?) 지낼 수 있다. 트렐로 카드 양식 예시* 우선순위(사용빈도수)* 요건위치 : 앱/관리자 페이지 위치* 이슈내용 : Why?! 개발요건 발의의 목적* 요건 상세 내용* 신청자(팀)* 관련 이미지, 파일 첨부 여부2) PM팀 우선순위 ListPM팀은 요건을 발의한 각 팀장님들과 머리를 맞대고 수많은 요청 카드 중 우선적으로 처리해야 할 업무들을 PM팀의 우선순위 List에 옮긴다. 어느 조직이든 자신의 조직 업무가 가장 중요하다고 여기므로 PM팀은 이를 잘 중재하고, 관리할 수 있어야 한다. 이 List로 옮길 수 있는 권한은 당연히 PM팀에게만 있어야 한다.3) 기획 중 List우선순위 List로 옮긴 요건들에 대한 기획을 진행한다. 이때 기획 진행 상황을 알 수 있도록 PM팀은 별도의 List를 생성해 관리하면 좋다. 4) 개발 진행 / 상용 반영 List배달 앱에서 ‘주문 접수 중-조리 중-배달 중’의 프로세스가 보이는 것처럼 요건 처리 과정을 확인할 수 있는 List로 활용한다. 5) 보류 / 확인 List 모든 카드에 대해 무작정 개발을 진행할 수는 없다. 개발 시 이슈가 있거나 우선순위에서 누락된 카드는 사유 Comment를 달고 보류시킨다.2. 과감히 버리자!PM의 인재상은 머리부터 발끝까지 미니멀리즘으로 무장을 해야 한다는 거다. 굳이 나중을 위해 카드를 남겨둘 필요는 없다. 어차피 미뤄진 요건은 (언제가 될지 모르는) 훗날 개발을 시작할 때 상황에 맞게 다시 정리해야 한다. 다시 말해, 보류된 카드들이 다시 빛을 보는 일은 거의 없다는 것이다. R&D본부에 요청한 분들에겐 잔인한 이야기지만 PM팀은 미련을 가질 여유가 없다. 필요 없거나, 중복되는 카드는 삭제하는 것이 좋다. 언제든지 Archive를 클릭할 준비를 하자. 물론 Archive는 카드 생성자가 직접 하는 것을 원칙으로 하되, 함께 있는 자리에서 사전 협의를 거쳐 진행하는 게 에티켓이다.브랜디에서는 매주 카드 정리하는 시간을 갖는다. 요청했던 팀과 요청을 파악하는 R&D본부의 팀원이 한자리에 모여 카드를 정리하면 핵심 파악이 빨라지고, 현재 브랜디에서 진행해야 할 우선순위가 눈에 보이기 시작한다. 3. 모르면 물어보자!너무 당연한 이야기라고 생각하겠지만 의외로 질문을 쉽게 하는 사람은 드물다. 다들 바쁜데 질문하면 괜히 눈치 보이고, 미안하다는 등등의 이유로 혼자 고민하는 사람들이 많다. 이 행동이 반복되면 결국 트렐로는 망가지고 업무는 산으로 갈 것이다. PM팀은 지속적인 회의를 통해 다른 팀과 호흡을 맞추면서 개발 요건을 파악해야 한다. 분명 더 좋은 결과물이 나올 수 있을 것이다.[정리]트렐로를 관리하는 PM의 역할1) List와 규칙을 만들어 개발 프로세스를 구축하자.2) 보류된 개발 요건은 미련 갖지 말고 당당하고 과감하게 버리자.3) 모르면 질문하자. 다른 팀은 경쟁자가 아니라 함께 호흡을 맞춰야 할 대상이다.Conclusion정리하면 짧은 내용이지만, 실은 트렐로를 세팅하기까지 많은 혼선이 있었다. 협업을 거치면서 브랜디 업무에 가장 최적화된 List를 구축하고 나니 업무 History관리도 쉬워졌고, 요청자 파악도 명확해졌다. 게다가 이미지나 파일을 첨부할 수 있어 트렐로는 통합관리도구로 적절하다고 생각한다.다만 통합관리 이외의 일정관리나 품질관리까지 트렐로로 관리하긴 어렵다. 브랜디에서는 다른 관리는 다른 툴을 사용하고 있다. 무엇인지 궁금하다면? 다음 포스팅을 기대해주시길 바란다.글문경민 팀장 | R&D PM팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #트렐로 #Trello #협업툴
조회수 1469

태그솔루션의 투명디스플레이 이야기 (2)

안녕하세요! 태그솔루션의 대표 박승환입니다! 먼저 앞선 글(링크: https://brunch.co.kr/@rr5ys5s/9 )을 통해 태그솔루션의 전체적인 이야기와 밑그림을 보셨다면 이번에는 말씀드렸던 제품 개발 및 양산에 대한 제조의 이야기를 해보려고 합니다! 태그솔루션의 투명디스플레이 이야기 (1)왜 기술기반의 하드웨어 창업인가? | 안녕하세요. 중장거리용 투명디스플레이 패널을 만들고 있는 4년차 하드웨어 스타트업 태그솔루션의 대표 박승환입니다. 위 영상은 2016년, 2017년에 설치 및 전시한 태그솔루션의 모노컬러 제품 영상입니다! 현재는 더 높은 해상도의 풀컬러 패널 개발이 완료된 상태이며, 2018년 올해 하반기 다양한 건물 유리에 풀컬러 패널 제품 설치를 진행할 예정입니다.brunch.co.kr/@rr5ys5s/9 이 글을 통해서 기술기반의 제조 창업이라는 분야에 대한 거부감이나 어려움을 조금이나마 덜어 드릴 수 있으면 좋겠습니다. 참, 사람을 뽑고 있습니다! (채용링크: https://brunch.co.kr/@rr5ys5s/8 ) 태그솔루션 콘텐츠 디렉터 채용 공고채용기간 : ~ 10월 중순까지 | 안녕하세요. 하드웨어 제조 스타트업 태그솔루션 입니다. 저희에 대한 자세한 소개글은 아래 링크를 통해 확인할 수 있습니다!^^ https://brunch.co.kr/@rr5ys5s/9 태그솔루션 시작 그리고 비전 태그솔루션은 2015년 1월 사업을 시작한 하드웨어 스타트업입니다. 투명한 유리에 다양한 기술을 융합하여 부가가치를 창출하는 것을 목표로 하는brunch.co.kr/@rr5ys5s/8 시작은 미약하지만 끝은 창대하리라!2015년 만든 시제품들의 모습위 사진을 보라. 엄청난 퀄리티(?)의 시제품이다. 이걸 시제품이라고 부르기도 민망할 정도의 제품이지만 처음 시작은 이러했다. 정녕 이것이 기술을 가진 스타트업의 모습인 것일까? 정말 솔직해지자면, 나는 공대생이긴 하지만 투명 디스플레이와 정말이지 1도 관계없는 삶을 살았다. 위 제품 모습을 보면 알 수 있을 것이다. 저 미친듯한 배선과 제품의 퀄리티를 보라.... 지금 보면 조금 민망하지만 그 당시에는 최선이었다. 하지만 어떻게 완제품에 가까운 훨씬 높은 퀄리티의 제품을 개발하고 이를 양산이 가능한 제품으로 만들 수 있었을까?  일단 위 제품에서 변신한 우리 제품의 모습을 살펴보자.최근 풀컬러 제품 라스베가스 전시회 영상... 설치된 패널 수가 적어서 아쉽다...위 사진과 발전된 제품의 모습을 보시면 아시겠지만, 실제로 제품을 만드는 과정은 만만치 않다. 과거에 제가 썼던 양산부터 제품의 판매 및 유통까지 적은 글이 있는데 이 글을 읽기 전에 한번 보시고 오시는 걸 추천한다!https://brunch.co.kr/@rr5ys5s/3시제품부터 양산 그리고 유통까지(1)태그솔루션 조명 브랜드 코스모블랑 생존기 | 하드웨어 기술창업에 관심을 가진건 2014년 6월부터였다. 사실 스타트업이라는 단어도 그때 인생에서 처음 들었던 것 같다. 그 후 2015년 1월 태그솔루션을 만들고 지금은 만 3년이 지나고 나 자신과 태그솔루션 모두 죽음의 고개를 넘어가고 있는 시점이다. 지금의 태그솔루션이 있기까지 나 자신의 무지함으로 겪은 어려움이 굉장히 많았고, 지금도 그 문제를brunch.co.kr/@rr5ys5s/3 처음 프로토타입부터 시제품 그리고 제품까지 가는 과정은 온전히 제조 인프라에 대한 이해가 큰 비중을 차지한다. 단적으로 "지금 내가 손에 들고 있는 일상 제품은 어떤 과정(공정)을 거쳐서 어떻게 만들어졌는지 이해하는 것" 이 제품을 만드는 것의 핵심이다. 실제 태그솔루션의 공정이 진행되는 모습위 영상에서는 우리 투명LED패널이 만들어지는 일부 공정들을 실제 촬영한 영상이다. 아마 일반적으로 공정에 대한 이해도가 없으신 분들은 정확히 어떤 원리로 저 공정이 이루어지고 있는지 파악하기는 쉽지 않은 게 사실이다. 또 공정에 대해서 조금 알더라도 직접 제품을 만드는 과정을 겪지 않으면 정확히 어떤 조건에 어떤 물질을 활용한 것인지는 절대 알 수 없다. 유일하게 해당 기술과 노하우는 제품을 만드는 회사의 노하우로 남는 것이다.이렇게 이제 막 하드웨어 스타트업에 뛰어든 사람이 제품이 만들어지는 공정에 대한 이해를 하고 있는 건 거의 불가능하다고 할 수 있다. 금형, 사출, 압출, 프레스, PCB, SMT, 에칭, Fpcb, 스퍼터링, 임프린팅, 스크린인쇄, 솔더링, 마스크 등등 공정과 관련된 접하기 쉽지 않은 단어가 많이 존재한다. 사실 어떤 공정이던 구글링을 하면 친절한 설명들을 찾아볼 수 있다. 그 원리와 용도 또한 인터넷이라는 바다에 넘쳐난다.그. 러. 나.저런 단어나 검색어 조차 모르는 상황에... 어찌... 찾을 수 있냔 말이다!!! 그리고 글로만 배운 것은 항상 98% 정도 부족함을 느낀다. 그렇다면 어찌 접근하는 게 좋을까? 일단 어떤 제품이든 좋으니(만들고 싶은 제품과 비슷하면 더 좋을 것 같다.) 구매해서 해체하는 것부터 시작해보자. 여러 제품을 뜯어보자면, 공통된 구성을 확인할 수 있다.제품은 대부분 바디(사출 및 가공부) + 제어부(PCB - 초록색 기판) + 전원부(배터리, SMPS 등)로 구성된다. 특정 용도에 따라 추가되는 부분이 있지만 원리는 간단하다. 제어부인 PCB에 제품의 제어에 필요한 펌웨어(코드)를 라이팅하면 제품은 원하는 대로 작동한다.그럼 이 공통된 각자의 부분에 맞는 제조와 기술들에 대한 이해를 하면 빠르게 제품을 만들 수 있는 부분이 아닌가!?! 그럼 한번 우리 제품을 뜯어보면서 맞는지 확인해보도록 하자!! 다시 투명 디스플레이 패널로 돌아와서, 우리 제품 역시도 구성은 기본적인 구성대로 바디( 패널부 + 패널 기구부 ) + LED 제어부 ( 드라이버보드 + 컨트롤보드 -> 다 초록색 기판들) + 전원부 (SMPS -> 파워서플라이를 저렇게 부른다)로 구성된다. 이 구성부에 대한 내용은 다음 편에서 좀 더 자세히 다뤄보도록 하자!  사실 수년간 제조업계에서 우리 제품을 만들면서 가장 크게 느낀 것은 하드웨어 창업에서의 핵심은 위에서 언급한 세 가지 구성(바디+제어부+전원부)을 만들거나 확보하기 위한 기술 및 제조 인프라 확보라고 할 수 있다. 제조라는 것이 나만 뛰어나서 잘할 수 있는 분야가 절대 아니라는 것이다. 아무리 개발을 잘해도, 좋은 인프라의 알맞은 공정 방식을 택하지 않으면, 가격과 품질 등의 다양한 제품의 핵심적인 요소에 영향을 주게 된다.결국 무수히 많은 공장을 돌고 눈으로 공정을 확인하고 새로운 기술에 대한 이해도와 빠른 습득력으로 하고자 하는 하드웨어 분야의 제조 부분을 익히는 것이 가장 올바른 방식이라고 할 수 있다. ( 발품을 미친 듯이 팔아야 한다. 필자는 만 3년이 넘는 기간을 경기도권 충청도권에 있는 공장은 정말 엄청나게 돌아다니고 눈으로 익히고 실무자들과 이야기했다. )다음 편에는 구성부 중에 바디에 해당하는 패널부와 기구부에 대해서 구체적으로 이야기해보도록 하겠다!3편에서는 패널부에 쓰이는 투명한 전극(투명 회로), 기구부를 만들기 위해 쓰이는 공정들을 에 대해 살펴보도록 하자! 과연 투명한 회로는 어떻게 만들어지는가!?!?마지막 편인 4편에서는 제어부와 전원부를 동시에 이야기해보도록 하겠다! 미리 이야기하자면 제어부는 LED로 영상을 구현할 수 있도록 도와주는 초록색 기판인 PCB! 그리고 전원부는 말 그대로 전기를 공급하는 장치에 대해서 언급할 예정이다.주위에 좋은 콘텐츠 디렉터 소개 부탁드리겠습니다.꾸벅.태그솔루션 박승환 씀.#태그솔루션 #TAGSOLUTION #제품소개 #인사이트
조회수 1622

채널 데스크 프론트엔드 기술 스택

오프라인 고객 분석 솔루션 워크인사이트를 개발해 온 조이는 최근 온라인 접객 서비스 채널을 런칭했습니다. 이 글은 채널과 관련된 기술 블로그의 첫번째 글로 채널 데스크 프론트엔드(웹, 윈도우, OSX)의 기술 스택 및 개발 환경을 소개하도록 하겠습니다.React채널 개발을 처음 시작할 당시 (지금으로부터 1년 전) 에 워크인사이트 대시보드 및 기타 사내 툴에서는 AngularJS 1을 사용하고 있었습니다. 비교적 적은 코드로 복잡한 애플리케이션을 빠르게 만들 수 있는 점에는 만족했지만 퍼포먼스면에서는 아쉬운 부분이 많았습니다. 따라서 새로운 프레임워크 및 라이브러리를 리서치 했고 매우 가볍고 렌더링 퍼포먼스 면에서 AngularJS 1 대비 우위에 있던 React 를 사용하기로 결정했습니다.컴포넌트의 설계 패턴은 Redux를 만든 Dan이 제안한 Container 와 Presentational 컴포넌트를 구분하는 방식으로 설계하고 있습니다. 따라서 Container 가 data fetch 및 update 등의 액션을 실행하고 Presentational 컴포넌트들을 조합하여 렌더링을 하게 됩니다.React를 실제 1년째 사용해 본 결과 저를 비롯한 팀원들은 매우 만족하고 있습니다. 구조, 스타일, 동작을 한 컴포넌트로 묶어 재사용성이 매우 높아졌으며 React의 휴리스틱한 Dom diff algorithm 덕분에 렌더링 퍼포먼스에서도 많은 이득을 얻을 수 있었습니다.Facebook Flux Utils아키텍쳐는 페이스북이 제안한 flux 철학에 따라 설계되었습니다. flux를 구현하기 위한 기본적인 유틸리티 기능을 제공하는 Flux Utils을 사용합니다. Flux의 많은 구현체 중에 요즘 가장 인기인 Redux도 고려했었습니다. 저희가 프로젝트를 시작할 당시에 Redux는 5~6개월밖에 되지 않은 프로젝트였고 거의 Dan의 1인 프로젝트였기 때문에 향후 메인터넌스를 장담할 수 없다고 판단했습니다. 그보다는 페이스북이 만든 Flux Utils가 그런 면에서는 더 안전할 거라고 생각했던 것이죠.약 1년 정도 Flux Utils로 개발해오며 몇 가지 문제를 겪게 되었습니다. 애플리케이션이 커지면서 관리해야할 State가 많아지고 그들 사이의 의존성 관리 때문에 Store의 복잡도가 빠르게 증가했습니다. 그에 따라 테스트가 어려워지고 올바른 유닛테스트를 위해서는 테스트 코드 역시 매우 복잡해지는 문제가 있었습니다.그래서 Redux를 다시 리서치하게 되었고, 결론적으로 “단일 Store, 다수Reducer” 라는 Redux의 철학을 통해 State 관리 로직(Reducer)을 단순하고 테스트도 쉽게 유지할 수 있겠다는 생각을 하게 되었습니다. 뿐만 아니라 그 동안 설계와 관련되어 고민하고 필요한 경우 저희 스스로 개발해서 사용하던 많은 부분이 Redux의 서브 프로젝트 형태로 (redux-actions, redux-thunk, reselect 등) 개발되어 사용되고 있는 것을 발견해서 Redux로의 마이그레이션을 결정했고 현재 진행 중에 있습니다.Electron이 글의 도입부에서 이야기한 것처럼 채널 데스크는 윈도우용, OSX용 애플리케이션으로도 제공됩니다. 채널 개발 초기 당시 윈도우, OSX 각각 네이티브로 만들 리소스가 부족했기 때문에 웹 기술 기반으로 네이티브 앱을 만들 수 있는 다양한 솔루션들을 리서치했고 그 중 Electron을 선택하게 되었습니다.Electron은 제가 정말 좋아하는 제품인 Slack, Simplenote에서 사용하고 알려져 있고 국내에서는 Remember 등에서 사용하고 있습니다. 초기 개발 당시에는 안정성에 의문을 제기하는 개발자들도 많았고 저희도 여러 문제와 삽질(인증, 패키징, 이슈 레포팅의 어려움, 메모리릭 등등)을 많이 겪긴 했습니다만 개인적으로는 충분히 프로덕션에 쓸 수 있을 정도 수준이라고 생각합니다. 무엇보다 프론트엔드 개발자가 매우 적은 노력으로도 네이티브 데스크탑 앱을 만들 수 있는 장점이 다른 모든 문제점을 상쇄하고도 남습니다.언어개발 언어로는 자바스크립트 ES6를 사용합니다. 언어를 선택할 당시에도 여러 옵션이 있었는데 가능하면 실험적이지 않고 표준을 사용하는 것이 미래 유지보수에 안전하다고 판단했습니다. 또한 다른 자바스크립트 대안 언어를 사용하지 않더라도 ES6 (일부 ES7 포함) 스펙도 충분히 효율적인 개발이 가능하다고 생각했습니다.코딩 스타일은 기본적으로 Airbnb의 코딩 스타일 가이드라인을 따르며 조이의 상황과 맞지 않는 부분은 엔지니어들과 상의 후 수정해서 사용하고 있습니다. 스타일 체크는 ESLint로 자동화한 뒤 Circle CI와 붙여서 모든 풀리퀘스트에 대해 점검하고 있습니다.테스트초기 개발할 때는 테스트 코드를 별도로 붙이지 않았습니다. 고객의 요구와 기타 상황에 따라 기획과 설계가 크게 변경되기도 했고 그 때마다 기민하게 반응하기 위해서, 어느 정도 확립된 제품이 되기 이전에는 테스트 코드는 작성하지 않는 것이 좋다고 판단했습니다. 이제는 많은 부분이 확정되었고 안정성이 중요해지기 시작했으며 애플리케이션이 커지면서 자동화된 테스트는 필수가 되기 시작했기에 최근에 도입을 하고 있습니다.테스트를 위한 도구는 Jest, Enzyme 등을 사용합니다. Presentational 컴포넌트에 대한 테스트는 props에 따라 원하는 형태로 렌더링이 이루어지는지, 이벤트에 따라 콜백이 잘 실행되는지 등의 Spec 을 작성합니다. Container 컴포넌트에 대한 테스트는 각종 이벤트 및 동작을 시뮬레이션하고 그에 따라 Action이 잘 발생하는지 또는 내부 state가 잘 변경되는지를 테스트합니다. 또한 Store (또는 Reducer), Action Creator, Model, Util 등 모든 구성 요소에 대한 테스트를 붙이려고 노력하고 있습니다. 유닛 테스트가 아닌 e2e 테스트 혹은 css 스타일 테스트 등은 하지 않고 있습니다.빌드 및 배포현재 채널 데스크는 Client-side rendering을 합니다. 초기 로딩 속도가 느리다는 단점이 있어서 Server-side rendering으로의 전환도 고려하고 있습니다. 이미 Node.js 를 사용하고 있어서 Isomorphic Javascript의 형태로 어렵지 않게 전환이 가능합니다.작성된 자바스크립트는 Babel로 컴파일되고 Webpack으로 번들화됩니다. css를 포함한 각종 리소스들 역시 Webpack을 통해 처리됩니다. 웬만한 작업은 npm과 Webpack으로만 자동화하려고 했으며, Electron과 관련된 작업(패키징, 인증 등)들만 gulp를 이용해 자동화됩니다. 모든 리소스들은 Node.js + express 서버로 Serving 되고, Node.js 앱은 Docker로 빌드되어 AWS EC2로 배포됩니다.마무리이상으로 채널 데스크 프론트엔드의 기술 스택을 소개해드렸습니다. 앞으로 각 부분 별로 저희 팀이 고민해 온 문제들과 해결 방법을 공유하고자 합니다. 뛰어난 개발자 분들의 많은 관심과 피드백 부탁드립니다!
조회수 1764

HBase 설정 최적화하기

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다.hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다.HBASE_HEAPSIZE = 61440 #(60GB)HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 3482

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를 통해 한층 쉽게 걸어갈 수 있었으면 좋겠다.

기업문화 엿볼 때, 더팀스

로그인

/