스토리 홈

인터뷰

피드

뉴스

조회수 1344

스타트업 개발팀에서 일한다는 것

 대부분의 정보통신 분야, 특히 소프트웨어를 제작하는 "개발 조직"의 구성은개발,  디자인, 기획(또는 PM), QA가 팀으로서 분리되어있고, 규모 있는 회사들의 경우, 업무에 관련된 직군 간의 갈등 상황이나 문제가 생길 시, 파트장 또는 팀장님들(이하 중간관리자)이 중재를 하고 의사를 결정하는 정해져 있는 프로세스가 되어 있습니다. 그러나, 작은 규모의 스타트업이나, 업무에 책임을 지고 있는 인원이 단 한두명일 경우, 중간관리자들의 부재 때문에 개인 간 생기는 갈등 상황을 피할 수 없습니다. 그래서 오늘은 지금까지 제가 느낀 "정확하고 빠른 업무 진행을 위해 각 직군 간 인원들이 챙겨야 할 덕목들."을 말씀드리려 합니다. 그렇다면 무엇보다도, 왜 갈등 상황이 생기게 되는 걸까요?저는 "각 직군 간 종사자의 업무를 진행하는 과정과 목표가 다름에도, 이해보단 자신의 기준에서만 업무를 바라보는 경향"이 가장 큰 원인이라고 생각합니다. 저의 글(라고 적고 깨알 홍보라 읽는다...)에서 말씀드렸듯, 개발자, 디자이너, 기획자 들은 서로 일을 하는 방식도 다르고(심지어 개인차도 있지요), 각 직군마다 지향하는 부분들이 다르기 때문에 같은 방향을 보고 가더라도 서로가 서로 간에 집중하지 못하는 부분들이 분명히 존재합니다. 그리고 그런 부분들을 줄이기 위해선 업무 중 서로가 서로를 이해할 수 있도록 한 번씩 자신을 돌아보는 것들이 중요합니다. 그래서 아직 많이 부족하지만 각 직군에 종사하는 분들 그리고 공통적으로 업무 중에 한 번씩만 더 생각해 주셨으면 하는 것들과, 이유를 적어보려 합니다.기획 (또는 프로젝트 매니지먼트)1. 스펙 산정은 다 같이큰 회사라면 잘 모르겠지만, 작은 개발팀의 장점은 "많은 인원들이 비교적 짧은 시간 안에 많은 생각을 나누고 지향점을 찾아가는 과정을 같이 할 수 있는 것."이라고 생각합니다. 분명 기획자가 생각하고 만들어 내야 하는 스펙들이 있겠지만, 독단적으로 "이건 무조건 해야 하니 들어."라는 태도는 작은 팀일수록 업무의 동기를  꺾어버리는 일이 생길 수 있으니 항상 조심해야 합니다.2. 혼자서 "뭐... 개발이든 디자인이든 되겠지." 하는 추측은 절대 금물개발자 출신, 또는 디자이너 출신 또한 마찬가지라고 생각합니다. 몇 가지 예를 들자면, 1. 지금 개발자 또는 디자이너가 부딪힌 상황에 있지 않고, 2. 해당 직군에서 새롭게 화두 되는 트렌드에 덜 민감하고, 3. 각 개발자, 또는 디자이너가 생각하고 있는  스펙이나 디자인을 알지 못하고, 4. 어떤 라이브러리, 어떤 테마를 기반으로 작업할 지에 대한 기본적인 이해가 없으면서"이건 이렇게 되니깐 당연히 금방 될 거야."라는 생각은 절대 금물이라고 생각합니다.(디자이너나 개발자 분들이 그냥 "이거 간단하게 뭐 메뉴 만들어서 대충 어디 집어넣으면 되지 뭘 그리 어렵게 생각해?"라고 하면 피꺼솟 하는 거랑 마찬가지입니다ㅎㅎ) 3. 삼초 안에 정해진 내용도 항상 문서화 작은 개발팀일수록, 내용 저장과 공유, 그리고 의사 판단의 근거들이 약할 때도 있고, "우리 왜 이거 이렇게 가게 됐지?"라고 생각할 때가 많습니다. 적어도 "몇 월 며칠날 어떤 주제에 관해서 어떤 이유 때문에 어떤 방식으로 처리하기로 한다." 정도라도 항상 적어둘 필요가 있습니다. 디자이너1. 레퍼런스 자료 준비에 시간을 아끼지 말자 원하는 인터렉션, 원하는 디자인의 방향이 있다면, "왜 원하는지, 왜 이런 방향으로 개발을 해주었으면 하는지."에 대한 판단의 근거가 필요합니다. "이쁘잖아."는 상당히 설득력이 있지만 개발자 또는 기획자를 완전히 설득시킬 순 없어요... 특히 아직 개발이나 기획에 대한 로직을 잘 모르시는 디자이너 분들의 경우, 레퍼런스 자료를 찾을 때 드리블(Dribbble)이나 핀터레스트(Pinterest)도 좋지만, 스스로 프로토 타이핑 구현이 불가능하다면, 반드시 구동되고 있는 애플리케이션을 찾아보고 어떻게 작동하는지에 대해 면밀하게 파악해 주세요.2. 작은 부분이라도 시안에 변경이 있다면 반드시 공유하기 처음 팀 단위로 일을 하다 보면, "요거 내가 생각해보고 금방 슉 바꿔놔야지."라는 생각에 조용히 디자인을 바꿀 수 있습니다... 아? 아니에요 절대 안 됩니다.....  다 같이 협업하는 일을 하다 보면, 버전 관리와 변경내역 공유가 제작보다 더 중요한 상황이 올 수 있습니다. "내가 어디 부분을 변경했고, 변경한 이유는 이것 때문이다." 라는것 없이 홀로 조용히 변경한 디자인은 엄청나게 큰 갈등 상황을 부를 수 있어요!개발자1. 장애 발견 시 어디가 어떻게 안될 거 같은지에 대해서 설명하기 가장 힘든 줄 알지만, 할 수 있다면 가장 강점인 부분일 것 같아요. "개발하는 과정에서 이러한 부분은 지금 서비스에서는 이런 식으로 동작하는데, 원하시는 이런 부분은 이런 게 다르기 때문에 동작하는데 장애가 있을 수 있어요."를 설명해 줄 수 있는 개발자와 일한다는 것은 정말 같이 일하는 다른 직군들에게는 큰 축복이라고 할 수 있죠. "내가 백번 말해도 모르실 거예요."라고 말하는 건 결국, 무엇이 문제인지도 모르고, "다른데선 되는데 왜 우린 안돼?"라고 생각하는 다른 직군의 동료들에게 질타를 받을 수밖에 없습니다. 개발자는 소통이 잘 안 되는 사람이라는 고정관념을 깨고, 오래 걸려도 좋고, 다른 직군의 사람들이 당장 무슨 이야기를 하시는지 이해 못해도 좋아요. 같은 선상에서 고민한다는 것을 알려주는 것만으로도 큰 도움이 됩니다.전반적으로모든 작업의 종료는 내 결과물 발표가 아닌 다음 작업자의 업무 최적화입니다.기획자는 "문서 완료했을 때"디자이너는 "디자인 가이드 또는 산출물 나왔을 때"개발자는 "시킨 개발 다 했을 때"가 아니라,기획자는 "다음에 문서를 읽을 디자이너, 개발자가 스펙이 이해가 안돼서 업무를 진행하지 못하는 일이 없도록"디자이너는 "개발 중에 필요한 자료가 없어 업무를 진행하지 못하는 일이 없도록 "개발자는 "QA 중 개발에서 요구한 스펙에 미달되는 부분이 있어 업무를 진행하지 못하는 일이 없도록"하는 게 업무의 궁극적인 틀입니다. 결국, 일의 최종점은 결과물이 온전하게 나왔을 때 의미있는 것이기 때문에 최종 결과물이 나오는 과정에서 내 역할을 마지막까지 충실히 하는것이 업무의 종료라고 생각합니다. 분명, 모든 것들을 한 번에 모두 다 알고, 또는 모든 것들을 다 계산하면서 할 수는 없어요. 항상 실수는 할 수 있죠. 하지만, 실수가 아니라 이런 부분들을 알면서, 또는 이러한 고려를 하지 않고 업무를 지금까지 진행하셨다면, 말씀드린 부분은 분명히 한 번씩은 생각해 보아야 될 부분이라고 생각합니다. 굉장히 오랜만에 글을 쓰는 것 같네요! 다들 건강하게 잘 지내고 계시죠? 저는 마지막 글 이후 한 번의 이직과 다른 이런저런 일들에 치여 이제야 글을 쓰게 되네요. 이번글을 시작으로, 직군별로 하나하나 더 디테일하게 설명드리도록 할게요! 그리고 앞으로는 기획 업무 관련 뿐만이 아니라, 이번 글과 같이 각 직군 간의 이해관계나 업무를 진행하며 느끼는 것들에 대해 공유드리고, 서비스 기획 관련해서도 조금 더 자주 글 쓸 예정입니다. 앞으로도 자주자주 들러주세요, 감사합니다! :)#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트
조회수 1477

스타일쉐어에서 이미지 분류하기 (시작 편) feat.ML

안녕하세요.스타일쉐어에서 백엔드 개발을 하고 있는 김동현입니다.작년 11월 스타일쉐어에서 뷰티에 관련된 사진들을 따로 모아서 보여줄 피드.바로 뷰티피드 라는 것을 만들었습니다. 하지만 피드를 만드는 과정이 순탄치 만은 않았는데요.그간의 과정과 얻었던 경험들을 공유하고자 합니다.들어가기에 앞서혹시 설명을 하다 보면 스타일쉐어에서만 사용되는 단어가 있을 수 있다는 생각이 들어 단어에 대한 공유를 먼저 드리고자 합니다.스타일쉐어에서는 이를 “피드”라 칭합니다.스타일쉐어에서는 이를 “스타일”이라 칭합니다.여러 가지 카테고리 중에서 왜 뷰티인가요?기존의 서비스에서는 유저들이 올리는 스타일에 대한 카테고리가 없어서 유저들이 보고 싶어 하는 스타일들을 쏙쏙 뽑아서 보여줄 수 없는 상황이었지만 “내가 보고 싶은 것들만 볼 수 있었으면 좋겠다”라는 유저들의 니즈는 계속 올라가고 있었습니다.서비스 특성상 1020 유저들이 많이 있었고 하루 동안 올라오는 스타일에 대해서 사람이 직접 카테고리를 하나하나 나눠봤을 때 가장 활발하게 대화가 이루어지고 반응이 좋고 충성도도 높은 카테고리가 바로 뷰티였습니다.뷰티만이라도 따로 보여줄 수 있도록 해보자그럼 어떻게 뷰티에 관련된 게시물들을 뽑아낼 건가요?올라오는 스타일들 중에서 뷰티라는 속성을 찾아내어 분류하는 방법으로 두 가지의 제안이 나왔습니다.1. 사람이 직접 뽑아낸다.2. 요즘 뜨고 있는 딥러닝을 이용해서 뽑아낸다.처음엔 사람이 직접 모니터링 해볼까? 라는 이야기가 나왔었습니다.당장이라도 시작 할 수 있다는 점과 높은 정확도를 가졌다는 장점이 있기 때문이였죠.하지만 주말 관계없이 4000~6000개씩 올라오는 스타일들을 상시 모니터링하고 모두 검토해야 하는 상황이 너무 막막하게 느껴졌습니다. 관련 업무를 하시는 분의 업무 만족도는 낮을 것이 당연하기도 했지만 그럴만한 인적자원이 충분하지 않았습니다.그래서 요즘 뜨고 있는 딥러닝을 이용해보자는 방향으로 일이 진행되었습니다. 게다가 요즘 딥러닝으로 Image Classification 하는데에 있어서 정확도가 사람을 넘어섰다는 이야기도 결정에 한몫을 했답니다.딥러닝으로 분류하기로 결정했다! 근데 트레이닝 셋은?딥러닝을 하시는 분들이 애용하는 사이트인 캐글만 가보아도 문제와 트레이닝 셋이 잘 정리되어있기에 개발자는 어떻게 하면 잘 예측할 수 있을까에 대한 고민만 했으면 되었었습니다. 하지만 당연하게도 실제 필드에서 처리해야 하는 문제와 그에 대한 트레이닝 셋은 존재하지 않았습니다.우선 딥러닝으로 분류하기로 결정을 하였으니 서비스에서 뷰티라는 카테고리 안에 넣을 소카테고리를 나누었고 다음과 같았습니다.* 눈 화장 관련* 입술 화장 관련* 얼굴 화장 관련* 헤어* 화장품* 발색* 네일그래도 태양 아래 새로운 것은 없다 라는 말처럼 비슷한 것들이 존재할까 하고 찾아보았으나…https://www.kaggle.com/openfoodfacts/openbeautyfactshttp://www.antitza.com/makeup-datasets.htmlㅇ…없잖아?!그렇습니다. 공개된 것은 없던 새로운 것이었습니다. 위의 소카테고리들을 모으는 방법을 모색해야 했습니다.위에서 언급했듯이 잉여 인적자원이 없었기 때문에 몇만 개의 데이터를 모을만한 데이터를 모으는 일은 저를 포함해서 개발자 2명이서 진행을 했었습니다.그래서 결국 뷰티 피드는…성.공.적.다행히도 잘 마무리되었습니다. 화자 되고 있는 딥러닝 기술을 실제로 사용해볼 수 있어서 좋았고 팀원들도 이게 되는구나, 다른 것도 해볼 수 있겠다 라는 피드백을 많이 받았고 저 또한 개발을 하면서도 이게 된다고? 하는 반응이 제일 많았던 것 같습니다. 물론 앞으로 모델을 계속 개선해나가야겠지만요.사실 딥러닝을 거의 처음 공부하는 수준에 가까웠고 초반에 우왕좌왕 하기도 많이 했었는데 믿고 기다려줬던 스타일쉐어 팀원 분들 덕분에 잘 마무리될 수 있었던 것 같습니다.분류와 트레이닝 셋에 대한 좀 더 자세한 글은 다음 포스팅 (분류 편)에서 찾아뵙겠습니다.#스타일쉐어 #개발팀 #개발자 #개발후기 #경험공유 #인사이트
조회수 1670

[QP크루의 항해일지] 해적선에 탄 신입 디자이너의 적응기

안녕하세요. 콘텐츠 지부 김현수입니다. 저는 4월에 해적선에 승선해서 열심히 항해하고 있는 디자이너입니다. 사실 QP에 첫 번째로 입사한 디자이너이기 때문에 어렵고 힘든 일도 있지만 그만큼 파란만장하고 재미있는 디자인 작업들을 해보고 있습니다. QP에서 진행한 크고 작은 작업들을 하나씩 소개해드리면서 공유해보고 싶었던 점들을 이야기해보려고 합니다.QP에 처음 승선한 디자이너였기 때문에 말하는 대로 이루어지고 곧바로 QP의 비주얼 아이덴티티가 돼버리는(!) 즐겁고도 책임감이 느껴지는 작업들을 해볼 수 있었습니다. 저의 제일 첫 번째 프로젝트였던 QP의 로고 만들기, 신입 크루들을 위한 웰컴키트와 스티커 제작, QP의 A부터 Z까지 담은 해적단 입문서 편찬까지 찬찬히 풀어보겠습니다.STEP 01. QP 로고 제작하기QP의 시각적 정체성을 확립하는 첫 번째 과정은 로고 제작하기였습니다. 로고는 외부에 우리를 알리는 역할을 하기도 하지만 내부 크루들의 회사에 대한 생각을 담고 소속감을 다지게 만듭니다. 그래서 로고를 제작하기 전, 크루들의 의견을 들어보기로 했습니다. 크루들은 퀀텀파이러츠의 로고에 어떤 이미지가 담겼으면 좋겠을지 자유롭게 남긴 의견들을 살펴볼까요?크루들이 주신 소중한 의견들적극적으로 의견을 전달해 주신 크루들 덕분에 디자인을 시작하는 데에 큰 도움이 될 수 있었습니다. QP 해적선이 찾고 싶은 보물 상자, 해적선을 상징하는 깃발, 배 등 다양한 답변과 이미지들이 나왔지만 여기서 일맥상통하는 지점을 찾아 힌트를 얻을 수 있었습니다. 이 힌트를 바탕으로 키워드 몇 가지를 정해 방향성을 가지고 디자인 시안을 제작해 보고자 했습니다. 첫 번째 키워드는 '해적선'입니다. 우리가 그저 표류하는 것이 아닌 거침없이 나아감을 보여줄 수 있는 해적선을 키워드로 선정했습니다. 두 번째는 '항해'입니다. QP의 해적선이 항해하는 모습이 저희의 심볼에도 표현되었으면 한다는 크루들의 의견들을 참고했습니다. 세 번째 키워드는 '방향'입니다. 어딘가로 나아가고 있는 우리의 방향성을 보여주고자 했습니다.그럼 이제 제작했던 시안들을 보여드릴게요!최종 시안을 결정하기 전까지 나온 다양한 시안들시안을 제작할 때는 틈틈이 오며 가며 크루들이 던진 시각적 모티브가 로고를 발전시키는 데에 도움이 될 수 있었습니다. 키워드에도 등장했던 해적선, 그리고 바다, 키 등 다양한 아이디어로 시안들이 완성될 수 있었습니다. 이 중에서 선정된 로고는 다음 나오는 친구입니다.최종 결정된 QP의 로고저희의 항해하는 모습과 길을 상징화했다는 의견으로 채택된 로고입니다. 로고라는 것이 아이덴티티의 시작이 되는 만큼 글에는 압축되었지만 긴 고민의 시간을 담아 완성이 되었습니다. 어떻게 보면 로고가 앞으로의 디자인 작업에서 전면으로 크게 등장하지는 않겠지만 어느 한 켠에서 우리를 알리며 존재감을 내뿜기를 바라며 마무리했습니다.+번외 이야기. QP의 롤링페이퍼입사한지 2일차 날의 이야기입니다. 갑자기 용희님이 급한 일이 있다며 저를 소환하셨습니다. 심각한 얼굴로 전한 이야기는.. 내일이 바로 세정님의 생일이라는 것이었습니다. 생일맞이 롤링페이퍼를 제작해서 전달하자는 것이었는데 이미 퇴근시간이 얼마 남지 않은 시간이었습니다. 15분 안에 롤링페이퍼를 완성해야 하는 미션이 주어진 것이죠. (용희님은 이때 "앞으로는 이렇게 데드라인이 급한 일을 전달하지 않겠다"라고 약속하셨죠.) 이렇게 만들어진 제작된 롤링페이퍼는 무사히 세정님께 전달될 수 있었고 QP의 작은 문화가 되었습니다.QP의 크고 작은 모든 이벤트들에는 롤링페이퍼가 함께 합니다.생일을 맞이하여 기쁜 QP의 아이돌 소영님STEP 02. 스티커와 웰컴키트 제작하기로고를 제작한 후 가장 손쉽게 만들 수 있는 굿즈를 먼저 제작해 웰컴키트를 구성해보기로 하였습니다. 그렇게 제작하게 된 것이 스티커입니다. 웰컴키트를 꾸밀 수 있는 타이포그래피 스티커와 로고 심볼 스티커를 제작해 회사 곳곳에 사용하기로 결정했습니다. 로고를 제작하면서 파란색이 QP의 키 컬러로 결정된 만큼 굿즈 제작에도 적극 활용해 디자인했습니다.QP의 스티커 시안들다양한 용도로 쓰일 수 있도록 3가지 시안으로 디자인을 마무리해 스티커를 제작했습니다. 제작한 후에 배포하고 실제 사용되고 있는 모습을 보니 회사 브랜딩에 작은 한 발자국을 내디딘 기분이었습니다. 또한 내부적으로도 자연스럽게 소속감을 높일 수 있게 되는 계기가 되기도 했습니다. 비록 작은 스티커로 시작했지만 이러한 굿즈가 쌓이다 보면 내부에서부터 단단하게 쌓을 브랜딩에 일환이 될 수 있겠다는 생각을 얻게 된 프로젝트였습니다.스티커를 활용하는 예스티커를 제작한 후 웰컴키트도 제작을 시작했습니다. 웰컴키트에는 우선 앞서 제작했던 스티커가 들어갑니다. 그리고 크루들이 신입 크루를 위한 환영의 말을 적은 롤링페이퍼가 들어가죠. 신입 크루들이 회사생활에 필요한 사무용품, 슬리퍼 등 필수품들 또한 준비합니다. 마지막으로 쿠폰이 들어갑니다. 살짝만 보여드리자면 점심 식대를 초과해서 지원해주는 "오늘 점심 주인공은 나야 나"쿠폰, 아직 궁금한 것이 많은 신입 크루들을 위한 "모든 바쁜 일은 제쳐두고 내 질문에 답해줘"쿠폰 등이 있습니다. 아직은 어색할 신입 크루들이 자연스럽게 크루들과 친해질 계기를 만들어 해적 생활에 적응할 수 있게 도와주죠. 신입 크루를 위한 웰컴키트STEP 03. 해적단 입문서 편찬하기웰컴키트를 제작하면서 신입 크루에게 전달할 입단 과정부터 근무에 필요한 모든 것을 적은 해적단 입문서의 필요성을 느끼게 되었습니다. 필요한 내용을 정리해 4개의 단원과 2개의 별책부록으로 나누어 편집했습니다. 2개의 별책부록은 QP에 간식이나 쉴 수 있는 곳을 소개하는 보물지도와 크루들의 자기소개가 담긴 크루 소개 페이지로 이루어져 있습니다. 이후에 내용은 주제에 따라 4단원으로 나누어져 있습니다. 첫 번째 단원은 <해적단 입단 심사>로 입사서류나 계정 생성등 입사 후 첫 번째로 해야 하는 필수 과정들에 대해 안내하고 있습니다. 두 번째 단원은 "해적 장비 안내"로 QP에서 사용하고 있는 툴들을 소개하고 어떻게 사용하는지 간략히 알려주는 단원입니다. 세 번째 단원은 "같이의 가치"파트입니다. 휴가를 어떻게 쓰는지부터 QP 크루들이 점심을 먹는 법까지 QP의 복지에 대해 소개하는 단원입니다. 마지막 단원은 해적 꿀팁으로 회의실 예약 방법이나 WIFI 정보 등 소소한 팁들을 안내하고 있습니다.입문서를 디자인할 때에는 처음부터 확실한 콘셉트를 가지고 있었습니다. 마치 해적들의 양피지를 펼쳐보는 듯한 책을 만들자는 방향으로 시작했습니다. 여타의 입사 가이드처럼 딱딱한 형식보다는 친근감 있고 재미있게 필수 정보들을 전달하자는 기획을 가지고 텍스트 작업과 디자인을 진행했습니다.해적단 입문서 내부를 살짝 보여드립니다!계속해서 키 컬러로 사용하고 있는 파란색을 포인트로 양피지 질감의 배경으로 콘셉트에 부합하는 비주얼을 만들었습니다. 다만 텍스트 양이 많다는 특성상 내지는 깔끔하게 흰 배경으로 작업을 진행했습니다. 완성된 입문서는 PDF로 새로 입사할 크루들에게 안내 메일로 배포되고 있습니다. 입사하기전 해적단 입문서를 읽으며 QP에 대한 낯섦을 조금 해소할 수 있기를 바라며 애정을 가지고 디자인 작업을 진행했는데요, 입문서를 제작하면서 저 또한 QP에 대해서 알았던 것을 정리하고 몰랐던 것을 새롭게 알아가는 시간이었습니다. QP_디자이너의_자리.jpg승선하고 처음 맡았던 작업들이 QP의 브랜딩에 관한 것이었기 때문에 디자이너로서는 책임감이 크게 느껴졌었습니다. 하지만 로고부터 시작해 회사의 아이덴티티를 다지는 작업을 하고 나니 회사 내부의 가치를 올리는 데에 일조한 것 같아 보람을 느낄 수 있었습니다. 또한 이번에 했던 프로젝트들이 회사의 문화와도 맞닿아 있는 부분이 많았기에 많은 크루들의 기대와 관심 속에 완성되었는데요, 그만큼 의견을 존중해주고 관심을 가져주는 크루들이 있었기 때문에 오히려 자유롭고 즐겁게 작업을 해볼 수 있었습니다. 이 모든 프로젝트를 함께 해주신 세정님께 특별한 감사드리며 해적단 입문서에 내용을 작성하시느라 고생하신 경모님께도 감사드립니다. 앞으로도 항해일지는 계속 이어질 예정이니 어떤 크루가 적어주실지 많이 기대 부탁드립니다!QP 크루들은 앞으로도 더 멋진 항해를 하기 위해 함께 노력하고 성장하고 있습니다. 현재 퀀텀파이러츠는 퍼포먼스 마케터, 검색광고마케터, 웹 개발자 직무의 크루를 기다리고 있습니다. QP 해적선에 승선해 함께 하고 싶다면 아래의 링크를 참고해주세요!https://blog.naver.com/haejeok_kwon/221566691682
조회수 1181

안드로이드 클라이언트 Reflection 극복기

비트윈 팀은 비트윈 안드로이드 클라이언트(이하 안드로이드 클라이언트)를 가볍고 반응성 좋은 애플리케이션으로 만들기 위해 노력하고 있습니다. 이 글에서는 간결하고 유지보수하기 쉬운 코드를 작성하기 위해 Reflection을 사용했었고 그로 인해 성능 이슈가 발생했던 것을 소개합니다. 또한 그 과정에서 발생한 Reflection 성능저하를 해결하기 위해 시도했던 여러 방법을 공유하도록 하겠습니다.다양한 형태의 데이터¶Java를 이용해 서비스를 개발하는 경우 POJO로 서비스에 필요한 다양한 모델 클래스들을 만들어 사용하곤 합니다. 안드로이드 클라이언트 역시 모델을 클래스 정의해 사용하고 있습니다. 하지만 서비스 내에서 데이터는 정의된 클래스 이외에도 다양한 형태로 존재합니다. 안드로이드 클라이언트에서 하나의 데이터는 아래와 같은 형태로 존재합니다.JSON: 비트윈 서비스에서 HTTP API는 JSON 형태로 요청과 응답을 주고 받고 있습니다.Thrift: TCP를 이용한 채팅 API는 Thrift를 이용하여 프로토콜을 정의해 서버와 통신을 합니다.ContentValues: 안드로이드에서는 Database 에 데이터를 저장할 때, 해당 정보는 ContentValues 형태로 변환돼야 합니다.Cursor: Database에 저장된 정보는 Cursor 형태로 접근가능 합니다.POJO: 변수와 Getter/Setter로 구성된 클래스 입니다. 비지니스 로직에서 사용됩니다.코드 전반에서 다양한 형태의 데이터가 주는 혼란을 줄이기 위해 항상 POJO로 변환한 뒤 코드를 작성하기로 했습니다.다양한 데이터를 어떻게 상호 변환할 것 인가?¶JSON 같은 경우는 Parsing 후 Object로 변환해 주는 라이브러리(Gson, Jackson JSON)가 존재하지만 다른 형태(Thrift, Cursor..)들은 만족스러운 라이브러리가 존재하지 않았습니다. 그렇다고 모든 형태에 대해 변환하는 코드를 직접 작성하면 필요한 경우 아래와 같은 코드를 매번 작성해줘야 합니다. 이와 같이 작성하는 경우 Cursor에서 원하는 데이터를 일일이 가져와야 합니다.@Overridepublic void bindView(View view, Context context, Cursor cursor) { final ViewHolder holder = getViewHolder(view); final String author = cursor.getString("author"); final String content = cursor.getString("content"); final Long timeMills = cursor.getLong("time"); final ReadStatus readStatus = ReadStatus.fromValue(cursor.getString("readStatus")); final CAttachment attachment = JSONUtils.parseAttachment(cursor.getLong("createdTime")); holder.authorTextView.setText(author); holder.contentTextView.setText(content); holder.readStatusView.setReadStatus(readStatus); ...}하지만 각 형태의 필드명(Key)이 서로 같도록 맞춰주면 각각의 Getter와 Setter를 호출해 형태를 변환해주는 Utility Class를 제작할 수 있습니다.@Overridepublic void bindView(View view, Context context, Cursor cursor) { final ViewHolder holder = getViewHolder(view); Message message = ReflectionUtils.fromCursor(cursor, Message.class); holder.authorTextView.setText(message.getAuthor()); holder.contentTextView.setText(message.getContent()); holder.readStatusView.setReadStatus(message.getReadStatus()); ...}이런 식으로 코드를 작성하면 이해하기 쉽고, 모델이 변경되는 경우에도 유지보수가 비교적 편하다는 장점이 있습니다. 따라서 필요한 데이터를 POJO로 작성하고 다양한 형태의 데이터를 POJO로 변환하기로 했습니다. 서버로부터 받은 JSON 혹은 Thrift객체는 자동으로 POJO로 변환되고 POJO는 다시 ContentValues 형태로 DB에 저장됩니다. DB에 있는 데이터를 화면에 보여줄때는 Cursor로부터 데이터를 가져와서 POJO로 변환 후 적절한 가공을 하여 View에 보여주게 됩니다.POJO 형태로 여러 데이터 변환필요Reflection 사용과 성능저하¶처음에는 Reflection을 이용해 여러 데이터를 POJO로 만들거나 POJO를 다른 형태로 변환하도록 구현했습니다. 대상 Class의 newInstance/getMethod/invoke 함수를 이용해 객체 인스턴스를 생성하고 Getter/Setter를 호출하여 값을 세팅하거나 가져오도록 했습니다. 앞서 설명한 ReflectionUtils.fromCursor(cursor, Message.class)를 예를 들면 아래와 같습니다.public T fromCursor(Cursor cursor, Class clazz) { T instance = (T) clazz.newInstance(); for (int i=0; i final String columnName = cursor.getColumnName(i); final Class<?> type = clazz.getField(columnName).getType(); final Object value = getValueFromCursor(cursor, type); final Class<?>[] parameterType = { type }; final Object[] parameter = { value }; Method m = clazz.getMethod(toSetterName(columnName), parameterType); m.invoke(instance, value); } return instance;}Reflection을 이용하면 동적으로 Class의 정보(필드, 메서드)를 조회하고 호출할 수 있기 때문에 코드를 손쉽게 작성할 수 있습니다. 하지만 Reflection은 튜토리얼 문서에서 설명된 것처럼 성능저하 문제가 있습니다. 한두 번의 Relfection 호출로 인한 성능저하는 무시할 수 있다고 해도, 필드가 많거나 필드로 Collection을 가진 클래스의 경우에는 수십 번이 넘는 Reflection이 호출될 수 있습니다. 실제로 이 때문에 안드로이드 클라이언트에서 종종 반응성이 떨어지는 경우가 발생했습니다. 특히 CursorAdapter에서 Cursor를 POJO로 변환하는 코드 때문에 ListView에서의 스크롤이 버벅이기도 했습니다.Bytecode 생성¶Reflection 성능저하를 해결하려고 처음으로 선택한 방식은 Bytecode 생성입니다. Google Guice 등의 다양한 자바 프로젝트에서도 Bytecode를 생성하는 방식으로 성능 문제를 해결합니다. 다만 안드로이드의 Dalvik VM의 경우 일반적인 JVM의 Bytecode와는 스펙이 다릅니다. 이 때문에 기존의 자바 프로젝트에서 Bytecode 생성에 사용되는 CGLib 같은 라이브러리 대신 Dexmaker를 이용하여야 했습니다.CGLib¶CGLib는 Bytecode를 직접 생성하는 대신 FastClass, FastMethod 등 펀리한 클래스를 이용할 수 있습니다. FastClass나 FastMethod를 이용하면 내부적으로 알맞게 Bytecode를 만들거나 이미 생성된 Bytecode를 이용해 비교적 빠른 속도로 객체를 만들거나 함수를 호출 할 수 있습니다.public T create() { return (T) fastClazz.newInstance();} public Object get(Object target) { result = fastMethod.invoke(target, (Object[]) null);} public void set(Object target, Object value) { Object[] params = { value }; fastMethod.invoke(target, params);}Dexmaker¶하지만 Dexmaker는 Bytecode 생성 자체에 초점이 맞춰진 라이브러리라서 FastClass나 FastMethod 같은 편리한 클래스가 존재하지 않습니다. 결국, 다음과 같이 Bytecode 생성하는 코드를 직접 한땀 한땀 작성해야 합니다.public DexMethod generateClasses(Class<?> clazz, String clazzName){ dexMaker.declare(declaringType, ..., Modifier.PUBLIC, TypeId.OBJECT, ...); TypeId<?> targetClassTypeId = TypeId.get(clazz); MethodId invokeId = declaringType.getMethod(TypeId.OBJECT, "invoke", TypeId.OBJECT, TypeId.OBJECT); Code code = dexMaker.declare(invokeId, Modifier.PUBLIC); if (isGetter == true) { Local<Object> insertedInstance = code.getParameter(0, TypeId.OBJECT); Local instance = code.newLocal(targetClassTypeId); Local returnValue = code.newLocal(TypeId.get(method.getReturnType())); Local value = code.newLocal(TypeId.OBJECT); code.cast(instance, insertedInstance); MethodId executeId = ... code.invokeVirtual(executeId, returnValue, instance); code.cast(value, returnValue); code.returnValue(value); } else { ... } // constructor Code constructor = dexMaker.declare(declaringType.getConstructor(), Modifier.PUBLIC); Local<?> thisRef = constructor.getThis(declaringType); constructor.invokeDirect(TypeId.OBJECT.getConstructor(), null, thisRef); constructor.returnVoid();}Dexmaker를 이용한 방식을 구현하여 동작까지 확인했으나, 다음과 같은 이유로 실제 적용은 하지 못했습니다.Bytecode를 메모리에 저장하는 경우, 프로세스가 종료된 이후 실행 시 Bytecode를 다시 생성해 애플리케이션의 처음 실행성능이 떨어진다.Bytecode를 스토리지에 저장하는 경우, 원본 클래스가 변경됐는지를 매번 검사하거나 업데이트마다 해당 스토리지를 지워야 한다.더 좋은 방법이 생각났다.Annotation Processor¶최종적으로 저희가 선택한 방식은 컴파일 시점에 형태변환 코드를 자동으로 생성하는 것입니다. Reflection으로 접근하지 않아 속도도 빠르고, Java코드가 미리 작성돼 관리하기도 편하기 때문입니다. POJO 클래스에 알맞은 Annotation을 달아두고, APT를 이용해 Annotation이 달린 모델 클래스에 대해 형태변환 코드를 자동으로 생성했습니다.형태 변환이 필요한 클래스에 Annotation(@GenerateAccessor)을 표시합니다.@GenerateAccessorpublic class Message { private Integer id; private String content; public Integer getId() { return id; } ...}javac에서 APT 사용 옵션과 Processor를 지정합니다. 그러면 Annotation이 표시된 클래스에 대해 Processor의 작업이 수행됩니다. Processor에서 코드를 생성할 때에는 StringBuilder 등으로 실제 코드를 일일이 작성하는 것이 아니라 Velocity라는 template 라이브러리를 이용합니다. Processor는 아래와 같은 소스코드를 생성합니다.public class Message$$Accessor implements Accessor { public kr.co.vcnc.binding.performance.Message create() { return new kr.co.vcnc.binding.performance.Message(); } public Object get(Object target, String fieldName) throws IllegalArgumentException { kr.co.vcnc.binding.performance.Message source = (kr.co.vcnc.binding.performance.Message) target; switch(fieldName.hashCode()) { case 3355: { return source.getId(); } case -1724546052: { return source.getContent(); } ... default: throw new IllegalArgumentException(...); } } public void set(Object target, String fieldName, Object value) throws IllegalArgumentException { kr.co.vcnc.binding.performance.Message source = (kr.co.vcnc.binding.performance.Message) target; switch(fieldName.hashCode()) { case 3355: { source.setId( (java.lang.Integer) value); return; } case -1724546052: { source.setContent( (java.lang.String) value); return; } ... default: throw new IllegalArgumentException(...); } }}여기서 저희가 정의한 Accessor는 객체를 만들거나 특정 필드의 값을 가져오거나 세팅하는 인터페이스로, 객체의 형태를 변환할 때 이용됩니다. get,set 메서드는 필드 이름의 hashCode 값을 이용해 해당하는 getter,setter를 호출합니다. hashCode를 이용해 switch-case문을 사용한 이유는 Map을 이용하는 것보다 성능상 이득이 있기 때문입니다. 단순 메모리 접근이 Java에서 제공하는 HashMap과 같은 자료구조 사용보다 훨씬 빠릅니다. APT를 이용해 변환코드를 자동으로 생성하면 여러 장점이 있습니다.Reflection을 사용하지 않고 Method를 직접 수행해서 빠르다.Bytecode 생성과 달리 애플리케이션 처음 실행될 때 코드 생성이 필요 없고 만들어진 코드가 APK에 포함된다.Compile 시점에 코드가 생성돼서 Model 변화가 바로 반영된다.APT를 이용한 Code생성으로 Reflection 속도저하를 해결할 수 있습니다. 이 방식은 애플리케이션 반응성이 중요하고 상대적으로 Reflection 속도저하가 큰 안드로이드 라이브러리에서 최근 많이 사용하고 있습니다. (AndroidAnnotations, ButterKnife, Dagger)성능 비교¶다음은 Reflection, Dexmaker, Code Generating(APT)를 이용해 JSONObject를 Object로 변환하는 작업을 50번 수행한 결과입니다.성능 비교 결과이처럼 최신 OS 버전일수록 Reflection의 성능저하가 다른 방법에 비해 상대적으로 더 큽니다. 반대로 Dexmaker의 생성 속도는 빨라져 APT 방식과의 성능격차는 점점 작아집니다. 하지만 역시 APT를 통한 Code 생성이 모든 환경에서 가장 좋은 성능을 보입니다.마치며¶서비스 모델을 반복적으로 정의하지 않으면서 변환하는 방법을 알아봤습니다. 그 과정에서 Reflection 의 속도저하, Dexmaker 의 단점도 설명해 드렸고 결국 APT가 좋은 해결책이라고 판단했습니다. 저희는 이 글에서 설명해 드린 방식을 추상화해 Binding이라는 라이브러리를 만들어 사용하고 있습니다. Binding은 POJO를 다양한 JSON, Cursor, ContentValues등 다양한 형태로 변환해주는 라이브러리입니다. 뛰어난 확장성으로 다양한 형태의 데이터로 변경하는 플러그인을 만들어서 사용할 수 있습니다.Message message = Bindings.for(Message.class).bind().from(AndroidSources.cursor(cursor));Message message = Bindings.for(Message.class).bind().from(JSONSources.jsonString(jsonString));String jsonString = Bindings.for(Message.class).bind(message).to(JSONTargets.jsonString());위와 같이 Java상에 존재할 수 있는 다양한 타입의 객체에 대해 일종의 데이터 Binding 기능을 수행합니다. Binding 라이브러리도 기회가 되면 소개해드리겠습니다. 윗글에서 궁금하신 점이 있으시거나 잘못된 부분이 있으면 답글을 달아주시기 바랍니다. 감사합니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 3562

Node 서버로 Slack 메신저 자동화하기

Overview백엔드 업무를 하면 데이터 요청과 CS문의를 자주 받습니다. 날짜만 다를 뿐 같은 유형의 문의가 대부분이죠. 결국 반복적인 업무를 효율적으로 처리할 수 있는 방법을 고민했고, 사내 메신저로 사용하는 Slack의 몇 가지 API를 사용하기로 했습니다.1. 알림봇 만들기비즈니스 로직을 만들다 보면 정해진 시간에 맞춰 작업을 해야 하는 경우가 발생합니다. Slack 메신저에 로그온한 상태에서 스케줄러를 이용해 지정한 시간에 Slack 메세지를 전송해보겠습니다.1)Slack API 유저토큰 받기Slack API에 사용할 해당 계정의 토큰을 받아야 합니다. Slack 가입 절차 및 채널 생성은 생략하겠습니다.https://api.slack.com/custom-integrations/legacy-tokens 접속합니다.Legacy tokens 메뉴에서 아래로 스크롤을 내려 토큰 생성버튼을 누릅니다.계정 패스워드를 입력하여 확인하면 토큰을 생성할 수 있습니다.생성된 토큰을 복사하여 저장합니다.2)Node.js를 이용한 알림봇 구현2-1.Node.js 설치Node.js 다운로드 해당 사이트에서 운영체제 환경에 맞는 파일을 다운받아 설치2-2.프로젝트 생성해당 프로젝트 폴더로 이동 후 명령어 실행$ npm init --yes // package.json 파일 생성2-3.Slack 연동2-3-1. slack-node 모듈 설치$ npm install slack-node --save2-3-2. 유저토큰을 이용하여 해당채널에 메세지 전송const Slack = require('slack-node'); // 슬랙 모듈 사용 apiToken = "발급받은 유저토큰"; const slack = new Slack(apiToken); const send = async(message) => { slack.api('chat.postMessage', { username: 'dev-test', // 슬랙에 표시될 봇이름 text:message, channel:'#general' // 전송될 채널 및 유저 }, function(err, response){ console.log(response); }); } send('메세지 내용'); 지정한 채널에 메시지가 발송됩니다. 하지만 이와 같은 방법은 유저 토큰이 공개 코드에 노출되기 때문에 보안이 취약할 수 있습니다. 유저 토큰이 필요 없어도 해당 채널에 URL을 생성하는 WebHooks API를 이용하여 메시지를 전송해보겠습니다.3) Incoming WebHooks APIWebHooks는 유저 토큰 대신 Webhook URL을 생성해 HTTP 통신으로 Slack 메세지를 전송할 수 있습니다. 다양한 메시지 형식을 지원하고 게시할 사용자 이름 및 아이콘 등을 통합적으로 관리할 수 있는 장점을 가지고 있습니다.3-2. Webhook URL 생성하기Slack 해당채널에서 Add an app 클릭검색필터에 WebHooks 검색Incoming WebHooks 추가채널 선택 후 Incoming WebHooks 생성생성된 Webhook URL 복사하여 저장해당채널에 생성되었는지 확인봇이름 및 아이콘등 기본 설정 변경하여 저장curl 사용 예제$ curl -s -d "payload={'text':'메세지 내용'}" "Webhook URL"Webhook URL 사용 중인 모든 메시지는 통합적으로 기본 설정이 변경된 걸 확인할 수 있습니다.다양한 형식의 메세지를 전송해보겠습니다.const Slack = require('slack-node'); // 슬랙 모듈 사용 const webhookUri = "Webhook URL"; // Webhook URL const slack = new Slack(); slack.setWebhook(webhookUri); const send = async(message) => { slack.webhook({ text:"인터넷 검색 포털 사이트", attachments:[ { fallback:"링크주소: ", pretext:"링크주소: ", color:"#00FFFF", fields:[ { title:"알림", value:"해당링크를 클릭하여 검색해 보세요.", short:false } ] } ] }, function(err, response){ console.log(response); }); } 다양한 형태의 메시지를 전송할 수 있습니다.4) Schedule 연동이제 스케줄러를 이용하여 지정한 시간에 메세지를 전송해보겠습니다.4-1. node-schedule 모듈 설치node-schedule는 Node.js 작업 스케줄러 라이브러리입니다.$ npm install node-schedule --savenode-schedule 코드 작성const schedule = require('node-schedule'); // 스케줄러 모듈 사용 // rule-style 사용 var rule = new schedule.RecurrenceRule(); rule.dayOfWeek = new schedule.Range(3,4); rule.hour = 19; rule.minute = 50; schedule.scheduleJob(rule, function(){ console.log('rule 방식'); }); // cron-style 사용 schedule.scheduleJob('50 19 * * *', function(){ console.log('cron-style 방식'); }); 취향에 맞는 스타일로 사용하면 됩니다.5) 지정 시간에 메세지를 전송하는 알림봇을 작성해보겠습니다.const Slack = require('slack-node'); // 슬랙 모듈 사용 const schedule = require('node-schedule'); // 스케줄러 모듈 사용 const webhookUri = "Webhook URL"; // Webhook URL const slack = new Slack(); slack.setWebhook(webhookUri); const send = async(message) => { slack.webhook({ text:message, attachments:[ { fallback:"구글드라이브: ", pretext:"구글드라이브: ", color:"#00FFFF", fields:[ { title:"[알림]", value:"해당링크로 접속하여 작성해 주세요.", short:false } ] } ] }, function(err, response){ console.log(response); }); } schedule.scheduleJob('5 19 * * *', function(){ send('업무보고 보내셨나요?'); }); 업무보고 시간을 미리 알려주는 알림봇2. 대화봇 만들기업무 문서는 주로 구글 독스와 같은 온라인 문서로 관리하고 있습니다. 하지만 매번 구글 드라이브에서 문서를 찾는 건 정말 귀찮은 일입니다. 번거로운 건 딱 질색입니다. Slack API를 이용해 관련된 키워드를 입력하면 링크 주소를 바로 받을 수 있는 대화봇을 만들어 보겠습니다.1) Slack API Bots 토큰 받기Slack API에 사용될 Bots 토큰을 받아야 합니다.https://{App Name}.slack.com/apps 에 접속합니다.Bots 추가Bots Api 토큰을 복사해 저장합니다.설정한 봇이름으로 Apps 영역에 자동으로 추가됩니다.2) 구글독스 대화봇 코드 작성2-1. botkit 모듈 설치$ npm install botkit --save2-2. 코드 작성const botkit = require('botkit'); // 봇 모듈 사용 const Slack = require('slack-node'); // 슬랙 모듈 사용 const controller = botkit.slackbot({ debug: false, log: true }); const botScope = [ 'direct_message', 'direct_mention', 'mention' ]; controller.hears(['업무보고'], botScope, (bot, message) => { bot.reply(message, '업무보고 링크주소'); }); controller.hears(['가이드', 'guide', '튜토리얼'], botScope, (bot, message) => { bot.reply(message, '가이드 링크주소'); }); controller.hears(['api', '명세서'], botScope, (bot, message) => { bot.reply(message, 'api명세서 링크주소'); }); controller.hears(['일정', '일정관리'], botScope, (bot, message) => { bot.reply(message, '일정관리 링크주소'); }); controller.hears(['비품', '비품정리'], botScope, (bot, message) => { bot.reply(message, '비품관리 링크주소'); }); controller.spawn({ token: '발급받은 봇 토큰' }).startRTM(); 지정한 키워드를 입력하면 해당 링크가 수신 됩니다.3) 데이터문의 대화봇 코드 작성데이터 요청 시 결과 데이터를 보내주는 대화봇을 만들어 보겠습니다. 일단 먼저 데이터문의 전용 Bots을 생성합니다.3-1. Python 연동 요청한 데이터는 Mysql 데이터를 조회해서 전송합니다. 그러면 Mysql 을 연동해야겠죠? Node.js에서도 직접 mysql 연결할 수 있지만, 기존 프로젝트가 Python으로 구현되어 있어 Python을 실행해 필요한 데이터를 추출해보겠습니다.3-2. python-shell 모듈 설치Node.js에서 Python 실행가능하도록 모듈을 설치$ npm install python-shell --save3-3. Mysql Sample Table3-4. 회원테이블에 저장된 가입일시 기준으로 몇일전에 가입한 회원을 추출하여 전송하는 코드 작성해 보겠습니다.const botkit = require('botkit'); // 봇 모듈 사용 const Slack = require('slack-node'); // 슬랙 모듈 사용 const ps = require('python-shell'); // 파이썬 쉘 모듈 사용 // 몇일 전 날짜 구하기 function getDaysAgo(dayNo = 0) { let nowDate = new Date(); let tempDate = nowDate.getTime() - (dayNo * 24 * 60 * 60 * 1000); nowDate.setTime(tempDate); let getYear = nowDate.getFullYear(); let getMonth = nowDate.getMonth() + 1; let getDay = nowDate.getDate(); if (getMonth < 10 xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed> 3-5. Python 코드 작성 # -*- coding: utf-8 -*- import sys import pymysql // mysql 접속 db = pymysql.connect('hostname', user='', passwd='', db='', charset='utf8') cursor_db = db.cursor() exe_query = "SELECT MEMBER_NAME FROM MEMBER_INFO WHERE MEMBER_REGIST_DETE >= '{}' ORDER BY MEMBER_NO ASC ".format(sys.argv[1]) cursor_db.execute(exe_query) all_rows = cursor_db.fetchall() for idx, row in enumerate(all_rows): print(row[0])     지정한 며칠 전에 가입한 회원 이름이 전송됩니다.   로그도 정상적으로 출력됩니다. 3. Node.js 프로세스 관리를 위한 pm2 모듈 설치 Node.js 는 비동기 I/O를 지원하며 단일 스레드로 동작하는 서버입니다. 비동기식 방식이지만 처리하는 Event Loop는 단일 스레드로 이루어져 있어 처리 작업이 오래 걸리면 전체 서버에 영향을 줍니다. 그래서 pm2를 이용해 프로세스별로 상태를 관리해야 합니다. 1) pm2 모듈 설치$ npm install pm2 -g2) 자주사용하는 pm2 명령어 pm2 list -> 실행중인 프로세스 확인pm2 start {node 파일} -> 시작pm2 stop {id or App name} -> 중지pm2 delete {id or App name} -> 삭제pm2 show {id or App name} -> 상세정보pm2 restart {id or App name} -> 재시작pm2 kill -> pm2 종료pm2 logs {id} -> id 앱의 로그 확인 3) pm2 실행화면$ pm2 start bot.js   프로세스별로 앱 이름, 버전, 상태, cpu 및 memory 사용량이 표시됩니다.$ pm2 show 0   해당 프로세스의 상세 정보를 확인할 수 있습니다. Conclusion 지금까지 Node.js 로 유용한 Slack 메신져 API를 알아봤습니다. 반복적인 업무를 하나씩 줄이다 보면 분명 일의 능률을 높아집니다. 하지만 무분별한 자동화는 서버의 부하를 증가시키기 때문에 꼭 필요한지 확인하고 선택하길 바랍니다. 오늘은 여기까지 글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만  
조회수 1131

개발자의 경력관리란?

경력이 아닌 업력이 되는 단계에 이르러야 가능한 것 아닌가 합니다.대부분의 경력은 '어느 회사의 누구'라는 표현에서 만들어진 것이 아닙니다.진정한 경력의 결과는 '자신의 이름'이 곧 브랜드화 되는 것입니다.매우 당연하게,하루 이틀, 한 두해 한다고 해서 얻어지는 것이 아닙니다."10년 경력!"10년 이상 한 분야나 하나의 도메인, 하나의 테크, 하나의 경력, 하나의 경험을 꾸준하게 파고들었을 때에 얻어지고, 그러는 경험속에서 인사이트, 통찰력이 생기게 됩니다.물론. 그래서, 20대에도 명성을 얻을 수 있는 '경력관리'가 가능하다고 이야기합니다.(실제 얻은 사람을 많이 봤습니다. 그들은 10대에 시작했죠. )회사의 테두리 내에서 얻을 수 있는 '경력'은 '경험'일뿐입니다.자신의 이름을 중심으로 기술할 수 있을 때에 '경력'이라고 이야기할 수 있습니다.개발자라면...글을 써서도 얻을 수 있고,강연을 해서도 얻을 수 있고,GitHub에 오픈소스를 공개하면서도 얻을 수 있습니다.현재 30대와 그 이전의 개발자라면...10대와 20대도 똑같습니다.40대, 50대 이후를 준비하세요.반복적인 일, 똑같은 일, 회사의 프로세스의 하나인 일만 하는 '사람'이라면...그냥, 그 회사의 톱니바퀴가 되는 것입니다.대부분 '경력관리'가 잘 안됩니다.앞으로 50대 이후에도 '브랜드'를 얻을 사람이 되려면...자신의 '경력'관리를 잘 해야 얻을 수 있습니다.나중에 닭 튀기거나 치킨 배달할 것이 아니라면...관리를 잘해야 합니다.경력관리가 가능하려면 어떤 회사를 찾아야 할까요.다음을 기억하세요.1. 구루급 개발자가 있는 회사를 찾으세요.2. 자신이 주도적으로 무언가를 만들 수 있는 권한과 책임을 줄 수 있는 회사를 찾으세요.3. 커뮤니티나 외부 강연, 외부 오픈소스 개발 행사에 적극 참여할 수 있는 기회를 주는 회사를 찾으세요.4. 반복적인 업무와 정체된 마켓에서만 반복적으로 서비스를 하는 회사는 회피하세요.5. 우리 도메인은 원래 이래, 이 일은 원래 이래... 이런 식으로 이야기하는 '상급자'가 있는 회사를 피하세요.6. 쉽게 설명할 수 있도록 준비하고, 리뷰를 할 수 있는 기회와 시간이 주어지는 회사를 찾으세요.그리고, 마지막으로...비전은 누가 주거나 만들어 주지 않습니다.결국, 자기 자신이 찾아야 하는데...이것도, 주변에 이야기가 통하는 '구루급 개발자'가 있어야 그나마 방향성을 찾기 좋습니다.혼자 고민하거나,주변에 비슷한 사람들끼리 고민해봐야 답이 안 나옵니다.꼭, 기억하세요!'구루급 개발자'와 상의하세요.그분들은 실패와 성공, 포기와 단념, 선택과 집중에 대해서 알고 있답니다.퇴근시간이라면..구루급 개발자에게 치맥 한잔 하자고 하세요!
조회수 1600

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

오프라인 고객 분석 솔루션 워크인사이트를 개발해 온 조이는 최근 온라인 접객 서비스 채널을 런칭했습니다. 이 글은 채널과 관련된 기술 블로그의 첫번째 글로 채널 데스크 프론트엔드(웹, 윈도우, 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로 배포됩니다.마무리이상으로 채널 데스크 프론트엔드의 기술 스택을 소개해드렸습니다. 앞으로 각 부분 별로 저희 팀이 고민해 온 문제들과 해결 방법을 공유하고자 합니다. 뛰어난 개발자 분들의 많은 관심과 피드백 부탁드립니다!
조회수 1077

오토 레이아웃(Auto Layout), 넌 누구냐!

OverviewiOS 프로그래밍을 하면서 많이 접했던 단어 중 하나는 오토 레이아웃(Auto Layout) 입니다. 스토리보드에서 화면을 만들 때 오토 레이아웃을 이용해서 뷰와 컨트롤의 크기와 위치를 지정합니다. 이미 잘 사용하고 있지만 문득 정확하게 오토 레이아웃은 무엇인지 궁금해져 이번 기회에 써 보기로 했습니다. 오토 레이아웃(Auto Layout)은?오토 레이아웃(Auto Layout)은 제약 조건(Constraints)을 이용해서 뷰의 위치를 지정하는 것입니다. 다시 말하면, 두 뷰 사이의 관계를 제약 조건이라는 것을 이용해서 뷰의 크기와 위치를 지정하는 것입니다. 너와 나의 연결 고리!오토 레이아웃은 여러 해상도를 지원하려고 이 세상에 나왔습니다. 아이폰의 크기가 다양해지면서 해상도도 달라졌는데, 다른 크기에서도 같은 화면을 똑같이 보여주기 위해 오토 레이아웃을 사용합니다. 세로 보기 화면뿐만 아니라 가로 보기 화면까지도 지원합니다. 아이폰SE 혹은 아이폰8 Plus에서도 같은 비율의 화면을 볼 수 있도록 오토 레이아웃을 사용하는 것입니다. 만약 오토 레이아웃을 사용하지 않는다면, 아이폰 기종마다 스토리보드를 만들어야 하죠. 이렇게 되면 스토리보드 파일이 많아집니다. 앱을 실행할 때 아이폰 기종을 확인하고, 그에 맞는 스토리보드를 찾아 화면을 보여주는 번거로움도 생깁니다. 위의 이미지를 보면 아이폰SE와 아이폰8, 아이폰8 Plus 브랜디 앱 화면. 기종이 달라도 보여지는 화면이 똑같다는 것을 볼 수 있습니다. 오토 레이아웃을 이용해서 하나의 스토리보드에서 모두 대응할 수 있는 것이죠.Frame Layout vs Auto Layout전통적으로 앱은 유저 인터페이스를 각 뷰의 프레임(frame)을 프로그래밍 방식으로 계산해 배치합니다. 유저 인터페이스를 배치하려면 뷰 계층의 모든 뷰에 대한 크기와 위치를 계산해야 합니다. 그리고 변경이 발생하면 영향을 받는 모든 뷰에 대해 프레임을 다시 계산합니다.Frame Layout뷰의 프레임을 프로그래밍 방식으로 정의하면 유연해집니다. 어떤 변화가 생겨도 대응할 수 있기 때문입니다. 그러나 모든 변경 사항을 직접 관리해야 하기 때문에 많은 노력이 필요합니다. 설계부터 시작하여 디버그 및 유지 관리까지 많은 것을 관리해야 합니다. 가장 효과적인 방법이지만 난이도도 많이 어려워집니다.이와 달리 오토 레이아웃은 일련의 제약 조건을 사용하여 유저 인터페이스를 정의합니다. 제약 조건은 앞서 말한 것 처럼, 일반적으로 두 뷰 간의 관계를 나타냅니다. 그런 다음 오토 레이아웃은 이러한 제약 조건을 기반으로 각 뷰의 크기와 위치를 계산합니다.Auto Layout화면에 배치하는 모습이 같기 때문에 프레임 방식을 사용해도 되고, 오토 레이아웃을 사용해도 됩니다. 둘 다 스위프트와 오브젝티브 C를 지원하기도 합니다. 각각 장단점이 있지만 가장 많이 사용하는 방법이 오토 레이아웃입니다. 빠르게 적용할 수 있고 많은 시간을 줄일 수 있기 때문입니다.스토리보드에서의 오토 레이아웃iOS 앱 개발은 스토리보드를 이용해서 화면을 만듭니다. 그래서 스토리보드가 익숙한 개발자들이 많은데, 사실은 뷰를 배치하면서 썼던 툴이 오토 레이아웃과 관련된 것이었습니다.스토리보드 오른쪽 하단에 있는 메뉴핀(Pin) 메뉴는 버튼 또는 레이블과 같은 UI 요소에 새로운 제약 조건들을 추가할 수 있습니다. 시계 방향으로 Top, Trailing, Bottom, Leading 제약 조건의 값을 입력할 수 있고, 화살표를 누르면 어떤 뷰와 관계를 가질 것인지 선택할 수 있습니다. 두 뷰와 핀 메뉴를 선택하면 같은 너비와 높이를 설정할 수 있습니다.Pin 메뉴정렬(Align) 메뉴는 다른 뷰와의 가로, 세로 정렬과 같은 정렬 제약 조건들을 추가할 수 있습니다. 정렬하고 싶은 두 뷰를 선택하여 수직 정렬, 수평 정렬을 추가할 수 있습니다.Align 메뉴맨 오른쪽 메뉴인 오토 레이아웃 이슈 툴은 오토 레이아웃 관련된 이슈들을 해결하는 옵션들을 제공합니다. 오토 레이아웃을 현재 설정된 상태로 재설정하는 옵션들입니다. 상단은 선택된 뷰와 관련된 것이고, 하단은 모든 뷰와 관련된 것입니다.Resolve Auto Layout IssuesAlign 옆에 있는 Stack 메뉴는 복잡한 제약 조건 없이 오토 레이아웃의 기능을 쉽게 뷰를 배치할 수 있도록 스택에 쌓아서 묶어주는 스택뷰를 생성합니다. 하나의 묶음으로 만들 뷰들을 선택하여 Stack 메뉴를 선택하면 스택처럼 그룹으로 됩니다. 여기서 뷰 사이의 공간과 정렬들을 설정할 수 있습니다.Stack View로 만든 간단한 뷰, 오른쪽 메뉴에 정렬과 뷰 사이의 공간을 선택할 수 있는 곳이 있습니다.스토리보드에서 뷰를 배치하고 오토 레이아웃 메뉴들을 이용하면 아래 스크린샷과 같이 제약 조건들을 볼 수 있습니다. 어떤 값을 지정하는 것이 아닌 같다는 뜻의 “=“를 이용하여 제약 조건들을 표현합니다.스토리보드에서 많이 볼 수 있는 제약 조건들(Constraints)프로그램 상의 제약 조건들스토리보드에서만 제약 조건들을 설정할 수 있는 건 아닙니다. 프로그램 상에서도 제약 조건들을 설정할 수 있습니다. 스토리보드에서 뷰를 배치한 다음, 제약 조건들을 소스 파일과 연결해서 값을 지정할 수 있습니다. 주로 어떤 변화가 일어나면 제약 조건들을 다시 설정할 때, 프로그램 상에서 값을 다시 설정합니다. 예를 들어, 데이터가 있을 땐 해당 뷰를 보여줍니다. 만약 데이터가 없으면 그 뷰가 사라지면서 그 뷰와 관련되어 있는 다른 뷰의 제약 조건들을 다시 설정하여 화면에 재배치하는 것입니다.func hideTag(_ hide: Bool) {         if hide {             self.labelTag1.isHidden = true             self.labelTag2.isHidden = true             self.constLabelTag1Top.constant = 0.0             self.constLabelTag1Height.constant = 0.0         } else {             self.labelTag1.isHidden = false             self.labelTag2.isHidden = false             self.constLabelTag1Top.constant = 15.0             self.constLabelTag1Trailing.constant = 5.0             self.constLabelTag1Height.constant = 20.0         }     } 위 소스에서 hide 값에 따라 레이블의 숨김을 설정하고 레이블의 제약 조건의 값을 재설정하는 메소드가 있습니다. 데이터가 있으면 숨김을 해제하고 제약 조건들의 값을 설정하지만, 데이터가 없으면 레이블을 숨기고 제약 조건들의 값을 0으로 설정합니다.스토리보드에서 연결한 제약 조건들을 가지고 설정할 수 있는데, 프로그램 상에서 직접 제약 조건들을 생성하여 사용할 수 있습니다. 아래의 예시는 뷰의 높이를 60으로 설정하는 코드입니다.NSLayoutConstraint(item: self.testView, attribute: .height, relatedBy: .equal, toItem: nil, attribute: .notAnAttribute, multiplier: 1.0, constant: 60) Conclusion애플에서는 개발자가 다양한 해상도에 대응할 수 있게 오토 레이아웃이라는 시스템을 개발했습니다. 스토리보드에서 쉽게 화면에 뷰를 배치할 수 있고, 별다른 기능을 추가하지 않아도 다양한 아이폰 크기에 맞춰서 대응해줍니다. 오토 레이아웃을 이용하여 멋지게 모든 아이폰과 아이패드에 대응하는 앱을 개발해보세요! 곧 산호세로 떠나 설레는 마음으로 글을 마치겠습니다. 감사합니다. :)글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유
조회수 1430

경험 부족한 스타트업의 devops 도입기 2편

출처 : 구글 이미지 검색그 동안 테스트코드작성, 코드리뷰를 집중적으로 수행했는데요. 아직은 엔지니어 모두가 걸음마 단계여서 실무리듬에 코드리뷰와 TDD를 끼워넣진 않았습니다. 대신 각자 리서치를 수행하고 매주 수요일 SW 세미나에서 lesson&learn 공유하는 식으로 devops를 공부했습니다.회고2주를 되돌아보고 느낌점을 한 문장으로 요약하면 다음과 같습니다.기술부채의 이자율은 고정 값이 아니다. 시간이 흐를수록 점점 더 높아진다.코드리뷰부터 말씀드리겠습니다. android와 iOS의 경우 앱 개발기간 3개월 동안 커밋한 어떠한 코드도 리뷰하지 않은 상황이었습니다. devops를 계기로 두 프로젝트 간의 코드리뷰를 드디어 시작했는데요. 방대한 코드를 빠르게 이해하기 위해 코드리뷰에 앞서 시각화된 자료를 준비해 아키텍쳐리뷰부터 수행하였습니다. 아니나 다를까 두 클라이언트의 유저스토리가 완벽하게 똑같음에도 불구하고 클래스 설계며 구현상의 코드며 개발 상의 내용이 완전히 갈라져 있음을 목도했습니다.출처 : 구글 이미지 검색iOS, android 환경적 차이로인해 어쩔 수 없이 코드의 다름이 나타나는 경우도 있었지만 대다수의 차이는 코드리뷰를 하지 않아서였습니다. 코드리뷰를 진행하면서 조금 신기했던 사실은 아주 간단한 요구사항(기능)도 개발자 개성에따라 구현법이 각양각생이라는 점입니다. 한 가지 문제에도 다양한 해결법이 존재하는만큼 각 구현법 마다 강점과 약점이 존재하기 때문에 코드리뷰의 필요성이 생각보다 더 크다는 점을 깨달았습니다. 앞으로 클라이언트에는 고도화된 유저스토리가 계속 추가될 예정인데 두 클라이언트간 갈라진 구현상의 설계는 분명히 피처 딜리버리에 병목지점으로 작용될 것입니다. 두 갈래로 나뉜 클라이언트를 어떻게 설계적으로 통합시켜 나갈지 지속적으로 고민해봐야 겠습니다. 또한 더 이상 차이가 벌어지지 않도록 지금부터 추가되는 피쳐들이라도 코드리뷰를 수행하는 환경에서 개발되도록 해야할 의무감도 느꼈습니다.테스트 코드도 마찬가지로 기술부채가 생각보다 많이 쌓였음을 깨달았습니다. 스위처의 클라이언트의 기술적 난이도는 낮은 편입니다. 그런데 그럼에도 불구하고 기존 코드에 테스트코드를 입혀 SUT로 만드는 일은 여간 까다로운 일이 아니었습니다. 기존 코드는 비즈니스로직과 I/O(DB,Network, BLE), UI 코드간의 커플링이 높아서 막상 어느것 하나 테스트코드를 입히기 쉽지 않았습니다. 테스트코드를 작성하기 위해서는 논리단위의 클래스들을 떼어내는 리팩토링이 병행되어야만 했습니다. 테스트코드 없이 작성한 코드는 시간이 지날 수록 테스트코드가 비집고 들어갈 틈 또한 점점 없애는듯 합니다. 그래도 이러한 현상들은 몸소 체험하면서 확신을 갖게된 사실도 있었습니다.테스트코드가 존재함으로서 SUT의 설계는 옳은방향으로 향한다.기존 코드에 테스트코드를 입히려고 이리저리 애쓰다보면 무관한 기능들이 뭉쳐있는 비대한 클래스는 발견하게 됩니다. 테스트코드를 입히기 까다로운 이 거대한 클래스를 쪼개야할 필요성을 느끼게 되는데요. 이 시점에서 개발자는 테스트코드가 있기 전에 절대 하지 않던 리팩토링 고민을 하게 됩니다. 치열하게 고민하는 과정에서 리팩토링에 실패하면 제대로된 테스트코드를 작성하기가 불가능해집니다. 즉, 테스트코드를 작성 했다면 분명히 설계상의 리팩토링이 일어 났을 확률이 높습니다.스위처 어플리케이션의 내 주변의 스위처 목록 페이지를 예를 들어보겠습니다. 해당 스크린에서는 유저가 여러개의 스위처를 확인하기 때문에 몇 가지 비즈니스 룰에 의해 스위처들의 정렬 순서가 결정됩니다. 그래서 유저는 여러개의 스위처가 검색되어도 내가 가장 사용할 확률이 높은 스위처를 최상단에서 만나는데요. 그 정렬 역할을 맡은 클래스가 switcher sorting(이름이 잘 기억안나네요..) 입니다.저희 안드로이드 개발자는 이 클래스를 첫 SUT로 만들기로 결정했고 일 주일간 테스트코드를 작성하려고 노력했습니다. 그러나, 생각보다 쉽지 않았습니다. SW세미나때 코드를 리뷰하면서 발견한 사실인데 swithcer sorting는 단순히 비즈니스룰에 사용되는 정보 뿐만 아니라 꽤나 무거운 무거운 switcher 클래스도 의존하고 있었습니다. 정작 sorting 우선순위를 결정하는데 필요한 정보는 switcher 클래스가 갖고있는 정보들 중 극히 일부분이었는데 말이죠. 이렇게 큰 클래스 때문에 테스트 코드를 짜려면 안드로이드 라이브러리인 BluetoothDevice와 Context 인스턴스를 공급하는 목업 클래스가 필요한 상황이 벌어질 수도 있었습니다. 더 큰 문제는 비대한 클래스로 인해서 test의 fixture를 구성하는데 수십 줄의 코드가 필요 했다는 사실입니다. 자연스럽게 테스크코드를 작성하면서 리팩토링의 필요성을 느끼게 되었습니다. 가까운 미래에 스위처 개발자가 성공적으로 switcher sorting 클래스를 SUT로 만들었다면 이 클래스의 설계 또한 분명 리팩토링을 거쳐 더 좋은 방향으로 거듭 났을 것 입니다.앞으로 2주간 할 일어떠한 일이든 균형이 중요하다고 생각합니다. 마냥 기술부채를 털어낸답시고 리서치와 공부만 하고 있을 수는 없습니다. 동아리가 아닌 회사이기 때문에 시장의 니즈에 맞춰서 분명히 다시 피쳐를 개발하는 속도를 높이는 가속 패달을 밟아야 할 시점이 올 것입니다.출처 : 구글 이미지 검색너무 이르지도 않게 그렇다고 너무 느리지도 않게 적절한 시점에 고객이 불만을 터뜨리지 않을 정도의 SW 안정성을 보장하는 최소한의 devops 수준을 달성해야합니다. 어느정도까지가 devops를 도입해야 오버엔지니어링이 아닌 기술부채를 탕감하면서 동시에 I/O 초중기 목표를 달성할 수 있는지 치열하게 고민하고 부딪혀보며 기민하게 대응해야 겠습니다.앞으로의 2주간 할 일은 다음 질문 두 가지에 대한 대답을 하면서 자연스럽게 도출될 것 같습니다.테스트코드 작성을 위한 TDD를 어떻게하면 엔지니어가 효과적으로 학습할 수 있을 것인가?코드리뷰를 스프린트 일과에 어떻게 자연스럽게 안착시킬 것인가?#스위쳐 #Switcher #개발 #개발팀 #문제해결 #인사이트 #DevOPS #데브옵스
조회수 1603

2017 NDC 리뷰) 크립돈 퓨처 미디어와 하츠네미쿠

 이번글은 덕력이 솟구친다는!!!은 아니고요(진짜 아니에요), 혹시 "하츠네 미쿠"라는 캐릭터를 보신 적 있으신가요?하츠네 미쿠! 설마 처음보는 분들이 계신가요?? 출처: https://ec.crypton.co.jp/pages/prod/vocaloid하츠네 미쿠는 VOCALOID(보컬로이드)로서, 간단히 설명하면, 야마하에서 만든 음성 엔진입니다(자세한 내용은 링크를 확인!). 해당 엔진을 기반(자세히는 VOCALOID2인데... 아, 저는 잘 몰라요 진짜예요...)을 기반으로 크립톤 퓨처 미디어사가 아티스트를 만들고, 이를 지적 재산권(이하 IP라고 하겠습니다)으로 창출해 낸 사례입니다! 해당 세션은 이 보컬로이드가 성공할 수 있게 된, 창작자들에게 프로그램 번들 시디를 팔던, 크립톤 퓨처 미디어사가 새로운 미디어와 아트의 중심에 설 수 있게 된 이유를 들을 수 있게 된 좋은 시간이었습니다. 앞으론 말이 매우 딱딱하니 이점 히해해 주세요~! 시작하겠습니다!씨디파는 회사가 인터넷 시대를 맞이하며 겪게 된 위기, 그리고 해결방안. 앞서 말씀드렸든, 크립톤 퓨처 미디어(이하 크립톤이라고 하겠습니다)는 창작자들을 위한 서비스(또는 프로그램)를 번들 또는 디스크 형식으로 판매하는 회사였습니다. 그리고 새로운 세대로 들어서면서, 해당 사업이 사양되고 있고(디스크 판매> 콘텐츠 다운로드의 변화), 특히 음악 제작 서비스의 경우, 작은 시장의 규모 때문에 비즈니스에 대한 한계를 느끼고, 새로운 사업 영역을 펼쳐나가기 위해 방향 모색하기 시작했다고 합니다. 그리고 크립톤이 생각할 수 있는 "자사가 가장 잘할 수 있는 것"을 생각해 보았을 때, "소리"라는 콘텐츠를 방점으로 서비스를 응용해 나가면서 스팩트럼을 넓히자!라는 생각을 했다고 합니다. 그래서 시작한 것이 바로, 보컬로이드!라는 것이었죠.보컬 합성 기술(보컬로이드) + IP의 도입은 처음부터 성공적이진 않았습니다. 처음 크립톤은 야마하의 보컬로이드 기술을 기반, Leon과 Lola라는 소프트웨어를 제작,  당사에서 유통을 시작했을 때에는, 타깃 유저를 잡는데 실패해 매출에 전혀 도움이 되지 않았다고 합니다(아래 사진을 보면 왠지 알 거 같...)첫 보컬로이드 레온과 로라입니다..... 음... 입술이 매력적 이네요.... 출처: http://vocaloid.wikia.com/wiki/Forever_(Zero-G_song) 그 이유는 해당 서비스를 사용할 것이라고 타게팅한 아티스트들의 경우, 목소리에 관해 리얼함을 추구하는 데, 해당 소프트웨어는 하드웨어로 조정하는 음과 음성들이 리얼함이 다소 떨어져 전혀 니즈가 없었던 것이죠.그래서 트립톤은"해당 서비스를 진짜 사용하는 유저들은 어떤 사람들 일까?"에 대한 고려를 기반으로,"메이코"라는 일본어로 노래하는 보컬로이드를 제작, 흥미를 끌 수 있도록 캐릭터를 모티브로 하는 커버 디자인 작업 시작(안드로이드 아니 보컬로이드 이니깐요!)이제는 버전 쓰리가 된 메이코! (출처:http://vocaloid.wikia.com/wiki/MEIKO) 첫 출시 당시, 거부감도 있었지만, 당시 KPI 목표인 500개를 훌쩍 넘어 3,000개의 판매 성공을 거뒀고, 성공의 요인은 패키징 디자인과 단순한 아티스트뿐만이 아닌, 다양한 콘텐츠에 관심을 가지는 다양한 유저들을 유저들을 이끌 수 있는 요소들이 있어서 라고 판단하였다고 합니다. (서비스를 사용할 것이다 라는 사용자의 경험에 대한 고려를 더 많이 한 포인트라고 생각되는 부분이지요!)메이코 이후 드디어 그분을 만들어 내는 것을 준비합니다.크립톤은 이때부터 정말로 사용자들이 무엇을 원하는가에 대한 생각을 많이 한 것 같다고 보이는 포인트입니다. 메이코의 등장 이후, "하츠네 미쿠"라는 캐릭터 산업으로 만들어 내는 것을 준비합니다. 그리고 해당 캐릭터를 하나의 "사업전략"으로 생각해 낸 이유는 메이코의 KPI달성도 있겠지만, "사람의 목소리와 극히 다른 목소리로 노래를 부르게 된다면, 이상하지 않을까?라는 부분을 오히려 역으로 기획, "인간이 아닌 다른 안드로이드가 하는 노래"라는 새로운 존재로서 IP를 만들어 버린 것이죠!또,  캐릭터를 기반으로 다양한 성격을 가질 수 있도록 "성우"라는 시스템을 집어넣어 "특별한 존재"라는 특징 성을 추가하였고, 기존의 보컬로이드는 "인간의 가수를 대체하는 것"이었으나, 하츠네 미쿠는 "안드로이드 가 부르는 진짜 보컬로이드"라는 접근을 통해 새로운 존재를 만들고, 메이코 디자인을 기반으로, "아이돌 라이즈 된 새로운 사이버 가수"를 만든 것이죠!아아.... 이제 고인이 되신 사이버 가수 아담... (http://beautinaru.tistory.com/196 또한, 해당 콘텐츠를 기반으로 음악을 만들었던 유저들에게 레트로 한 마크들을 집어넣어서 예전에는 이랬었지 라는 향수를 불러일으키고, 해당 콘텐츠를 기반으로 다시 작업을 할 동기를 줄 수 있도록 유저들의 의견을 듣고 반영하는 일들을 굉장히 많이 했다고 합니다!그리고 하츠네 미쿠의 진정한 아이덴티티를 생성합니다. 그것은 바로 Chain of Co-creation!!!하츠네 미쿠가 이렇게 성장할 수 있었던 이유는 저는 하나만 꼽으라 라고 한다면 이쁘잖아요! 가아니라... "확산 가능 여부"에 대한 많은 고려가 있었기에 가능했다고 생각합니다.인터넷 덕분에 음악 등을 만드는 사람들이 쉽게 업로드하고 공유할 수 있는 많은 플랫폼들이 생성되는 현실.덕이 많은 분들이 공유를 통해 자아실현을 하는 공감대를 형성할 수 있는 움직임이 확산.콘텐츠가 콘텐츠를 만들고 퍼져나가는 순기능적인 부분들이 늘어나는 현상들을 확인하고,2차 3차 저작물을 통한 확산> Chain of co-creation의 순선환 적인 기능들이 생겨나는 것이죠!! 그리고 그런 상황을 기반으로, 궁극적으론,모든 사람들이 제작자가 될 수 있는 현실 상황을 받아들이고,제작할 수는 있지만,  저작에 관련한 법률 등에서 막히는 상황을 막기 위해, 창작자들의 창작활동을 돕고, 실제 업로드된 콘텐츠를 기반으로, 실제 사업이 일어날 수 있는 방향으로 전개합니다!그리고 수익화를 통해서 창작자들이 창작활동 = 수익활동이 될 수 있도록 플랫폼 화를 추진한 것이죠!그래서 처음 하츠네 미쿠가 나온 2007년부터 10년이 지난 지금까지도 "보컬로이드"의 선두 주자로 전 세계적으로 콘서트를 다니며 성공적인 투어를 하고 있습니다.투어는 계속된다. (출처: http://mikuexpo.com/) 저는 하츠네 미쿠가 단지 덕후들의 승리라고 요만큼도 생각하지 않습니다.하츠네 미쿠를 성장시킬 수 있었던 건 "우리가 제공하는 서비스가 어떤 유저들에게 더 많은 강점이 있고, 해당 유저들은 어떤 행동을 통해서 자아를 성찰할 수 있을까? 그리고 해당 행동을 통해 유저가 얻는 궁극적인 이익들이 잇을까?"를 생각했던, 크립톤의 유저를 생각하는, 유저의 직접적인 경험을 서비스에 반영하려고 하는 강한 의지가 해당 서비스를 성공시킬 수 있게 한 요인이라고 생각해요. 그런 의미에서 저에겐 정말로 뜻깊고 즐거웠던 세션이었습니다!P.S.: 이제 슬슬 NDC2017 영상들이 올라오기 시작하네요! 관심 있는 분들은 https://ndc.nexon.com/main에서 확인해 보세요~오늘도 긴 글 읽어주셔서 감사합니다! 다소 글이 엉망진창이라도 이해해 주세요! #코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트
조회수 1021

[Buzzvil People] Ben Yoo, Software Developer

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다.  안녕하세요 저는 버즈빌에서 Server engineering 을 맡고 있는 유병우입니다. 회사에서는 Ben 이라는 닉네임을 쓰고 있고 저와 아내 사이에 아기가 하나 있는데 회사에서는 벤, 벤처, 미니벤이렇게 부르고 있습니다. 성격은 매우 Active 해서 웬만한 스포츠는 다 좋아하고 회사에서는 Rock band도 하고 있습니다. 프로그래머! 어린 시절 Basic 이라는 언어로 시작한 프로그래밍이 너무 재밌기도 했고 가능한 많은 사람들에게 유익을 끼치고 싶다는 생각에 Software Engineer 가 되었습니다. 10년 전 병역특례 시절 카카오톡 이전에 존재했던 m&Talk 이라는 무료 메신저 개발을 시작으로 삼성의 Chat@n, 그리고 Line, Naver 외 여러 앱에 들어가는 push notification platform 을 개발한 경험이 있습니다. 전 세계에서 억 단위가 넘는 유저들에게 서비스하고 그 유저들에게 좋은 경험을 선사하는 것이 저에게 더욱 Software 의 매력에 빠지게 만들었던 것 같습니다. 새로운 기능이나 개선사항을 배포하고 나면 유저들의 Feedback 을 보는 것이 아침에 눈을 뜨면 가장 먼저 하는 일이었습니다. (늘 즐겁기만 한 건 아니었습니다. 특히 버그를 배포한 다음 날엔.. -_-a)  2. 어떻게 버즈빌에 오시게 되셨나요?  Infobank 에서의 인연 Infobank 에서의 병역특례를 하면서 m&Talk이라는 메신저를 개발할 때 Product Team의 Jay 는 iPhone 쪽 개발을 주도하고 있었고 저는 Android 쪽 개발을 주도하고 있었습니다. 함께 하나의 Product 을 만들면서 여러 가지 의견을 주고받기도 했고 서로 부족한 부분을 잘 보완해주는 친구이자 동료라는 생각을 많이 했습니다.  창업을 결심 나중에 Jay가 미국에서 함께 잠금화면 서비스를 만들어보자고 절 찾아왔고 그렇게 해서 Slidejoy 라는 회사를 함께 공동창업하게 되었습니다. 당시 좋은 회사에서 만족하며 생활하고 있었고 한 가정의 가장으로서 불안정한 길을 선택하는 것에 대한 두려움이 있었지만 좋은 사람들과 함께 창업이라는 기회는 자주 오지 않는다는 것과 다음의 단순한 생각이 창업의 길로 저를 이끌었습니다.  “뭐, 굶어 죽지는 않겠지.” 버즈빌로 합병 많은 위기들을 헤쳐나가며 Slidejoy 는 계속 성장했고 좋은 기회에 한국에서 비슷한 서비스를 하고 있던 저희보다 규모가 큰 회사인 버즈빌로 합병을 하게 되었습니다.  3. 버즈빌에서 어떤 업무를 담당하고 계신가요?  신기술 & Refactoring  제가 Software 를 개발하면서 가장 중요하게 생각하는 것은 효율 / 훌륭한 Design 을 가지고 있는 프로젝트 설계인데요, 효율을 올리기 위해 Go 와 Kubernetes 등의 기술을 회사에 도입했고 MVP, MVC 와 같은 Design pattern 들을 도입해서 코드를 읽기 쉽고 서로 분리하고 재사용 가능한 구조로 만드는 것에 노력 중입니다.    Go server engineering 실제 업무는 BuzzScreen / HoneyScreen 에서 광고 및 콘텐츠 할당과 Slidejoy 라는 서비스의 API 서버 개발을 맡고 있으며 Slidejoy 클라이언트를 개발했어서 클라이언트 쪽도 조금씩 참여하고 있습니다. 새로운 기술에 관심이 많다 보니 BuzzScreen 과 HoneyScreen 할당 로직을 전부 Go 언어로 포팅했고 비약적인 성능 향상이 있었습니다. (Go 서버 개발하기)  4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요?  사람 > 회사 대기업에서의 경험과 다르게 스타트업에서는 한 사람 한 사람이 일당백인 경우가 많은 것 같습니다. 그리고 그런 한 사람에 의해서 회사가 좌지우지 할 수 있는 곳이 스타트업입니다. 회사가 겪는 크고 작은 성장과 위기 모두 그대로 직원들에게 전달 되다 보니 그만큼 Buzzvil 식구들 모두 함께 만들어가는 서비스의 성공에 초점을 맞출 수 있습니다.  모바일 광고 저는 사실 미디어에 큰 흥미가 없고 광고는 더더욱 관심이 없었습니다. 하지만 Mobile 이라는 Big wave 안에서 0에서 출발해서 수억 명이 사용하게 된 급속도로 성장하는 Messenger 를 개발을 몸으로 체험할 수 있었고 모바일 광고 역시 Buzzvil 을 성장시킨 Big wave 였다고 생각합니다. 이렇게 급속도로 변하고 성장하는 시장에서 스타트업에 분명히 가치를 계산할 수 없는 엄청난 기회가 있다고 생각합니다.  5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요?  밝고 명랑한 문화 회사 회식 중에서 저는 “친해지길 바래” 라는 테마를 정말 좋아하는데요. 그야말로 정해진 예산 안에서 소수의 사람들끼리 마음껏 놀 수 있습니다. 지난번 친해지길 바래 때는 간단히 막국수 먹고 그 외의 모든 예산을 사격 및 방탈출 등의 액티비티에 쏟아부었습니다. 회식 날 밤에 배가 고픈 건 태어나서 처음이었던 것 같아요. 올해 초에 다녀왔던 전 직원들과 함께 다녀온 Bali 에서의 워크숍도 빠질 수 없습니다. 워낙 서로 친하게 지내다 보니 밤잠을 아껴가며 놀았던 기억이 납니다. 휴양지를 다녀왔는데 한국 돌아와서 1~2주 체력적으로 정말 힘들었던 기억이 나네요. 어느 Slack 채널에서나 난무하는 아재개그와 어처구니없는 3행시, 직원들의 표정이 담긴 얼굴로 만든 이모티콘 등 직원들 사이에서 주고받는 대화에는 늘 위트가 넘칩니다. 다크할거야! 라고 생각할 틈을 주지 않습니다. 비록 웃기지 않더라도 응원해줍니다. 노력은 언젠가 결실을 맺을 것이라 기대하기 때문이죠. 같이 놀고 같이 공부하는 회사 마음껏 교육이나 운동을 할 수 있도록 지원해주는 프로그램이나 무제한 도서구매를 지원하고 다양한 주제의 동아리나 스터디 모임 등이 있고 이걸 회사 차원에서 장려하는 것이 빼놓을 수 없는 Buzzvil 의 특징인 것 같습니다. 머신러닝, 영어스터디, 통기타 등의 스터디 모임과 밴드, 축구, 배드민턴, 테니스, 필라테스 등의 동아리 모임 등 대부분 직원들이 하나 이상의 프로그램에 참여하고 있습니다.  6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요?  많은 사람들에게 편리함을 제공 잠금화면이라는 대부분 사람들이 기존에 크게 활용되지 않고 있던 공간에 Value 를 만드는 것이 버즈빌에서 더 열심히 프로그램을 개발하게 만드는 원동력입니다. 위에도 기술 했지만 저는 가능한 많은 사람들에게 유익을 끼치고 싶어서 Programming 을 하게 되었고 대부분의 다른 산업과 달리 제가 하는 개발 작업은 하나의 복제품을 생성하는데 Ctrl+C / Ctrl+V 만으로 충분하니까 좋은 제품을 만들면 더욱 발전돼서 긍정적인 영향을 더 널리 끼칠 수 있을 것 같습니다.  다른 개발자들이 읽기 쉬운 코드 실제 제가 일을 하면 할수록 기존의 코드를 구조화하고 모듈화하고 사용하지 않는 코드를 지우는 일에 열심을 가지고 있다는 사실을 알게 되었어요. 확장이나 활용이 가능한 Core 나 Library 쪽 개발을 주로 하면서 어떻게 짜면 제 코드를 사용하는 사람이 덜 혼란스럽고 잘 활용할 수 있는지와 어느 곳에 어떤 설계가 어울리는지도 많이 고민해왔던 것 같습니다 버즈빌에서 버즈스크린이라는 상품을 통해서 저의 이런 성향을 마음껏 발휘하고 있습니다. 여러 Publisher 가 쉽게 사용할 수 있어야 하고 SDK 등을 사용할 때 쉽게 Integration 되어야 하기 때문이죠. ‘내가 짠 코드를 인수인계 받을 사람이 연쇄살인범이고 그 사람은 너의 주소를 알고 있다고 생각하고 코딩하라.’ 라는 말이 있는데요. 누구에게도 부끄럽지 않은 코드를 짜려고 항상 노력합니다. 갈 길이 아직 멀지만 연쇄살인범이라도, 어떻게 이렇게 코드를 (잘?) 설계했는지 의논하러 오게 만드는 것이 저의 꿈입니다.     *고성장 스타트업 버즈빌의 채용공고(전문연구요원 포함)를 확인하고 싶으면 아래 버튼을 눌러주세요!
조회수 1119

Vue, 어디까지 설치해봤니?

Overview새로운 사용환경 구축에 도전하는 건 개발자의 운명과도 같습니다. 오늘은 여러 장점을 가지고 있는 Vue (프론트엔드 자바스크립트 프레임워크)를 도전해보겠습니다. Vue는 다른 프레임워크에 비해 가볍고, 개발하기에 편합니다. 그럼 우선 Vue를 설치합시다! Vue 설치CDNhttps://unpkg.com/vue 주소를 script 태그에 직접 추가 Vue.js 파일다운개발용, 배포용 버전을 다운 받아 script 태그에 추가개발용 버전은 개발에 도움이 되는 모든 경고를 출력하기 때문에 개발 중에만 사용하고, 실제 서비스에서는 배포용 버전으로 사용해야 한다. NPM 설치규모가 큰 프로젝트 경우 컴포넌트별 독립적으로 관리할 수 있는 싱글 파일 컴포넌트 방식 추천 Vue를 설치하는 방법은 여러 가지가 있습니다. 각자 특성에 맞게 편리한 방법으로 설치해주세요. 이번 글에서는 싱글 파일 컴포넌트 방식을 사용할 것이므로 NPM vue-cli 를 설치해 프로젝트를 구성하겠습니다. # vue-cli 전역 설치, 권한에러시 sudo 추가 $ npm install vue-cli -global vue-clivue-cli를 사용하면 뷰 애플리케이션을 개발하기 위한 초기 프로젝트 구조를 쉽게 구성할 수 있습니다. 다만, 싱글 파일 컴포넌트 체계를 사용하려면 .vue 파일을 웹 브라우저가 인식할 수 있는 형태의 파일로 변환해 주는 웹팩(Webpack)이나 브라우저리파이(Browserify)와 같은 도구가 필요합니다. vue-cli 설치 명령어 vue init webpack : 고급 웹팩 기능을 활용한 프로젝트 구성 방식. 테스팅,문법 검사 등을 지원vue init webpack-simple : 웹팩 최소 기능을 활용한 프로젝트 구성 방식. 빠른 화면 프로토타이핑용vue init browserify : 고급 브라우저리파이 기능을 활용한 프로젝트 구성 방식. 테스팅,문법 검사 등을 지원vue init browserify-simple : 브라우저리파이 최소 기능을 활용한 프로젝트 구성 방식. 빠른 화면 프로토타이핑용vue init simple : 최소 뷰 기능만 들어간 HTML 파일 1개 생성vue init pwa : 웹팩 기반의 프로그레시브 웹 앱(PWA, Progressive Web App) 기능을 지원하는 뷰 프로젝트여러 설치 명령어 중에 특성에 맞는 초기 프로젝트를 생성하세요. 1) vue init webpack 실행# 해당 프로젝트 폴더에서 실행 $ vue init webpack   # 현재 디렉토리에서 프로젝트 생성 여부 ? Generate project in current directory? (Y/n) # 프로젝트 이름 ? Project name (vue_ex) # 프로젝트 설명 ? Project description (A Vue.js project) # 프로젝트 작성자 ? Author (곽정섭 ) # 빌드 방식 ? Vue build (Use arrow keys) # vue-router를 설치 여부 ? Install vue-router? (Y/n) # 코드를 보완하기 위해 ESLint를 사용 여부 ? Use ESLint to lint your code? (Y/n) # ESLint 사전 설정 선택 ? Pick an ESLint preset (Use arrow keys) # 단위 테스트 섧정 ? Set up unit tests (Y/n) # 테스트 러너 선택 ? Pick a test runner (Use arrow keys) # Nightwatch로 e2e 테스트를 설정 여부 ? Setup e2e tests with Nightwatch? (Y/n) # 프로젝트가 생성 된 후에`npm install`을 실행해야합니까? ? Should we run `npm install` for you after the project has been created? (recommended) (Use arrow keys) 2) 고급 웹팩 기능을 활용한 프로젝트 구성 방식으로 설치3) 설치완료4) package.json 파일에 설정된 라이브러리 설치$ npm install 5) 개발모드 실행# 해당 프로젝트 폴더에서 실행(소스수정시 자동 새로고침) $ npm run dev 6) http://localhost:8080/ 브라우저 실행7) Yeah, You got it!!!!추가 도구: Vue Devtools(크롬 확장 플러그인)Vue Devtools(크롬 확장 플러그인)은 Vue를 사용할 때, 브라우저에서 사용자 친화적으로 검사하고 디버그할 수 있습니다.크롬 개발자 도구에 Vue 탭이 추가됨ConclusionVue를 설치하는 여러 방법 중 고급 웹팩 기능을 활용한 프로젝트 구성을 알아봤습니다. 다음 글에서는 Vue 인스턴스 및 디렉티브(지시문) 사용법을 다뤄보겠습니다.참고설치방법 — Vue.js 글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #Vue

기업문화 엿볼 때, 더팀스

로그인

/