같이 일하고 있는 직장 동료들에 대해 얼마나 알고 계시나요? 엑스브레인처럼 작은 팀의 경우에는 함께하는 한 분 한 분이 팀 전체 분위기에 끼치는 영향이 상당하답니다. 또한, 머신러닝 툴 ‘다리아’로 저희가 꿈꾸는 데이터 사이언스계의 변혁을 일으키려면, 이를 위해 일하는 팀 또한 서로 잘 알고, 협력할 줄 알아야겠죠.각각 개성이 넘치지만, 서로 모여 엑스브레인의 매일매일을 풍족하고 즐겁게 만들어가는 팀을 소개합니다! 각 멤버들의 일상과 엑스브레인에서의 직무에 대해서도 알아보고, 또 뉴욕타임즈에 실린 “상대방과 사랑에 빠질 수 있는 36가지 질문” 중 직장 동료에게 할 수 있을 만한, 가장 흥미로운 질문들을 추려서 진행한 인터뷰를 통해 엑스브레인 팀 멤버 개개인의 색다른 매력을 만나보세요.(그렇다고 진짜로 사랑에 빠지시면 곤란합니다…)가장 최근 엑스브레인 팀에 합류하신 정갑님은 따뜻하고 밝은 산타 클라라에서 서서히 동결 준비 중인 서울로 오셨답니다 (감기 조심하세요…). 그래도 석박사 시절을 이보다 훨씬 춥고 눈에 갇히기 일쑤인 미시건에서 보내셨다고, 추위에는 강하다고 하시네요. 머신러닝 엔지니어로서 다리아의 엔진을 위한 개발 작업을 하시는 정갑님은 여가시간엔 반려묘 졸리와 브래드와 함께하거나, 요리나 등산을 즐기시기도 한답니다. 정갑님을 만나보세요!Fun Fact: 정갑님은 팀 멤버 중 가장 아침 일찍 출근하신답니다안녕하세요 정갑님! 엑스브레인에서의 역할에 대해서 얘기해주세요정갑: 머신러닝 엔지니어로 입사를 했고, 머신러닝 엔진을 개발하는 것이 주요 업무입니다. 많은 사람들이 머신러닝을 쉽게 쓰기 위해서는 현 상황에서 어떤 기술들과 어떤 문제점이 있는지 알아내야 하고, 저는 그 문제들을 해결하기 위한 중요한 기술을 찾아서 연구를 하고 해결 방안을 찾는 역할을 하고 있습니다어떤 계기로 머신러닝 엔지니어가 되셨나요?정갑:대학원, 회사에서 연구를 하면서 머신러닝의 사용자 입장이었는데, 사용하고 이해하는 과정이 상당히 어려웠어요. 기존에 나와있는 툴들도 사용성이 좋지 않았고…이런 과정을 제가 직접 개선하면 좋을 것 같아서 머신러닝 엔지니어로서 엑스브레인 팀에 들어오게 되었습니다.왜 엑스브레인인가요?정갑: 일단 조직의 인력구성이 마음에 들었고, 팀원들의 역량과 조직문화가 제가 원하는 분위기여서 좋았습니다. 두번째는 엑스브레인이 추구하고자 하는 가치 — 머신러닝이란 기술에 대해서 갖고 있는 생각 — 이 제가 평소에 갖고 있던 생각과 일치해서요…머신러닝을 단순히 이윤 추구의 수단으로 생각하는게 아니라, 이걸 더 많은 사람들이 이용해서 가치를 찾게 하자는 뜻이 좋았어요. 또, 초창기 회사에서 한 번 어떻게 조직이 커가고, 함께 성장하는 경험을 해보고 싶기도 했고요. 그리고 주변 신뢰할 만한 분들에게서 엑스브레인에 대한 좋은 이야기도 많이 들었어요.보통 하루 일과가 어떻게 되나요?정갑:아침 9시 15분 쯤에 도착합니다. 밤새 와 있던 슬랙 메시지와 이메일을 체크하고, 커피 한 잔을 마십니다. 아침엔 집중이 잘 되니까 읽어봐야 될 논문이나 자료 등을 보고, 또 제가 머신러닝을 전공하지는 않았으니까 아직 따로 공부해야 될게 많기 때문에 그 부분에도 신경쓰고 있어요. 머리가 워밍업이 되면 기존에 짜여있던 코드를 보고, 개발할 부분이 있으면 개발을 합니다. 점심시간이 되면 점심을 같이 먹기도 하고요 (미국에 있을 때는 따로 점심 시간을 내서 팀원들끼리 대화할 기회가 없었기 때문에, 엑스브레인의 이런 문화가 좋습니다). 연구개발과 미팅의 연속이죠. 오늘은 현재 머신러닝 엔진에 문제가 있어서 그 이슈를 뜯어보았는데, 그 과정을 바탕으로 어떻게 해결할 것인지에 대한 아이디어를 구현하는 과정을 거쳤습니다. 구현과 테스팅과 trial and error을 앞으로 몇 주간 반복할 것 같아요.정갑님의 직무 중 가장 즐기는 일은?정갑:무언가를 향상시키는 것? 이렇게 고치면 좋아질 것 같은데…라는 생각을 가지고 일하는 게 좋습니다. 저희 기존 시스템을 향상시키는데도 관심이 있지만, 롱텀으로 봤을 땐 엑스브레인만의 유니크한 기술을 가져야 하기 때문에 그 기술이 뭔지 알아내고, 개발하고, 사용자들의 니즈를 파악하는 것에 관심이 있습니다. 그래서 시스템의 문제를 찾으려고 많은 시간을 생각하는데 투자하고 있죠.반대로, 가장 하기 싫거나 어려운 일은?정갑:어려워서 하기 싫다기보다는… 풀어야 할 문제를 찾는 거 자체가 어려운 것 같아요. 이럴 땐 네 가지 상황이 있는데, 이미 찾은 문제, 풀수 없는 문제, 너무 쉬워서 관심이 없는 문제, 그리고 풀수 있고 임팩트 있는 문제가 있죠. 저희는 그 마지막 예를 찾으려고 하는 거고요. 그 과정이 힘들긴 하지만 즐기고 있습니다.정갑님 책상에 있는 물건 중 정갑님을 가장 잘 대변한다고 생각하는 아이템은?정갑:딱히 책상에 물건을 두지는 않는데… 미국에서 일하던 시절 실리콘밸리에서 여러 유명한 회사들 (트위터, 링크드인 등등) 구경을 했는데 엔지니어들은 대부분 책상에 컴퓨터 하나만 있고 다른 장식이 없더라고요. 저는 그런 단순함이 좋았어요.엄청난 집중력을 발휘하시기도 하죠최근에 합류한 멤버로서, 정갑님이 생각하시는 엑스브레인의 비전을 말해주세요.정갑:비전이라기보다는 나아가야 할 방향 같은 건데, 지금은 머신러닝에 대해서 사람들이 굉장히 많은 이야기를 하지만, 차분하게 앉아서 연구와 기술개발을 해야 할 시점이라고 생각합니다. 롱텀으로 긴 안목을 갖고서 차근차근하게 기초단계를 밟아나가는, 유행에 휩쓸리지 않고, 기본에 충실한 엑스브레인이 되었으면 좋겠어요.씨네마 소사이어티 때 추천하고 싶은 영화가 있다면?정갑:맷 데이먼 주연의 Downsizing…개봉하면 팀 멤버들과 같이 보고싶네요. 끝나고 토론할 주제가 많을 것 같아서요.10년 뒤 지금, 정갑님은 어떤 모습일까요?정갑: 앞으로의 10년 동안 공부를 해서 제대로 된 머신러닝 엔지니어가 되고 싶어요. 지금은 초기 엔지니어지만, 그때는 좋은 개발자들을 발굴해 내서 성장하는데 도움도 줄 수 있는 시니어 급 엔지니어가 되고 싶습니다.내가 생각하는 엑스브레인의 “엑기스”를 세 단어로 말한다면?정갑:진지와 엉뚱함의 공존?엑스브레인의 어떤 멤버와도 저녁 식사를 할 수 있다면, 누구와 같이 먹고 싶나요?정갑:진영님. 같이 점심을 먹어본게 입사했을 때, 수요미식회 때 빼고는 없어서... 진영님과 대화할 기회가 별로 없었는데 재밌는 분일 것 같습니다.이 세상 어느 누구와도 저녁 식사를 할 수 있다면, 누구와 같이 먹고 싶나요?정갑:칼 세이건? 그분의 책을 읽고 어렸을 때 가졌던 우주에 대한 여러가지 동경을 되살려 보고 싶네요… 과학에 대한 열정을 다시 느끼고 싶기도 하고.유명해지고 싶나요? 어떤 방법으로요?정갑:아니요.정갑님에게 “완벽한” 날이란 어떤 날인가요?정갑:아직 오지 않은 내일이…아닐까요? 너무 엉뚱한 대답인가요?90살까지 살 수 있고 마지막 60년을 서른 살의 마음, 혹은 서른 살의 몸으로 살 수 있다고 해봅시다. 몸과 마음 중 어느 쪽을 택할 건가요?정갑: 몸. 마음은 성숙하지만, 몸은 퇴화하니까…정갑님의 인생에서 가장 감사하게 생각하는 것은 무엇인가요?정갑:건강함인 것 같아요.내일 아침 눈을 떴을 때 어떤 능력이나 특성을 가지게 된다면 어떤 것이었으면 좋겠어요?정갑:무언가를 읽고 이해하는데 오래 걸리는 편인데, 이해력이 빨라지면 좋겠습니다. 두뇌회전도 빨라지고…지금까지 정갑님 인생에서 가장 잘해낸 일은 무엇인가요?정갑:좋은 사람과 인연을 맺은 일인 것 같아요.엑스브레인에서 가장 기억에 남는 일이 뭔가요?정갑:오늘 인터뷰…? (하하하)혹시 농담의 대상으로 삼아서는 안 된다고 생각하는 것이 있다면 어떤 것들이 있을까요?정갑:듣는 대상에 따라 다르겠지만, 사람들의 약점에 대해서는 농담을 하지 말아야 한다고 생각합니다.정갑님의 모든 것이 있는 집이 불에 타고 있습니다. 가족들을 다 구한 후 마지막 한 가지를 가지고 올 수 있습니다. 어떤 것을 가지고 나올 건가요?정갑:하드 드라이브! 제 모든 사진과 파일이 담겨 있거든요.#엑스브레인 #팀원소개 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑 #머신러닝 #머신러닝엔지니어

[LG CNS 채용 시리즈 2]내 회사! LG CNS가 맘에 드는 이유!신입사원 이열정씨가 LG CNS에 빠진 이유는 무엇일까요?▶ LG CNS와 함께하고 싶다면?https://goo.gl/fAUEYo#LG #LG그룹 #LGCNS #IoT #IT #IT채용 #LGCNS블로그 #LGCNS신입채용 #LGCNS채용 #R&D #SW개발 #공채 #박사 #보안 #블록체인 #빅데이터 #석사 #스마트에너지 #스마트팩토리 #신입사원 #아키텍쳐 #인공지능 #인프라운영 #일터 #채용 #취업 #취직 #컨설팅 #클라우드 #플랫폼개발 #하반기공채 #하반기신입사원채용 #하반기채용 #학사

'마크업 개발자', 아직은 우리들에게 다소 생소한 직군이죠. '마크업 개발자'는 디자이너와 개발자 사이에서 '오작교' 같은 역할을 하는 아주 중요한 포지션이에요. 오늘은 코인원의 마크업 개발자로 활약 중인 혜진님과 이야기를 나눠보려 해요. 자신의 위치에서 묵묵히 유저 친화적인 웹 환경을 만들어나가고 있는 혜진님을 만나러 가보시죠!사실 이미 혜진님은 지난 4월 13일(토), 테크 업계 여성들의 목소리에 집중하는 소중한 행사 ‘Women Techmakers Seoul 2019’에서 ‘스타트업에서 마크업 개발자로 살아남기’를 주제로 자신의 이야기를 널리 알리고 왔답니다. 스타트업 그리고 코인원에서 마크업 개발자로 살아남는 혜진님만의 방법은 무엇일까요? :-)Q. 혜진님 안녕하세요, 자기소개 부탁드립니다.안녕하세요, 코인원 유저플로우셀에서 마크업 개발자로 일하고 있는 오혜진입니다. 유저플로우셀은 암호화폐 거래와 프로차트와 같은 트레이딩 영역을 제외한 전반적인 서비스 영역을 담당하고 있어요. 특히 ‘셀'이라는 목적조직으로 개편된 이후 PM, 디자이너, 개발자가 한곳에 모여 누구나 코인원에서 거래를 하고 싶은 마음이 들도록 매력적인 곳으로 탄생시키고 있답니다. 저는 셀안에서 마크업 개발자로 일하며 디자이너와 프론트엔드 개발자를 이어주는 다리 역할을 하고 있습니다.Q. 지난 ‘Women Techmakers Seoul 2019’에서 마크업 개발자를 널리 알리는 발표를 했다고 들었어요. 어떤 내용인지 소개해주세요!감사하게도 ‘스타트업에서 마크업 개발자로 살아남기' 라는 주제로 300명이 넘는 관중들 앞에서 발표를 하고 왔습니다. (사실, 많은 분들이 와주셔서 땀이 좀 나기도 했고요;) 마크업 개발자는 스타트업에서 발견하기 힘든 직군이기도 해요. 보통은 웹 에이전시에 많이 속해 있거든요. 제가 마크업 개발자로 일한지 6년이라는 시간 동안 스타트업에서 어떤 방식으로 일해왔는지 알리고 싶었어요. 그래서 지금까지 이런 일들을 해왔고, 앞으로도 더 활발하게 할 것이라고 속시원하게 말하고 왔습니다.Q. 마크업 개발자는 구체적으로 어떤일들을 하나요?마크업 개발자는 한마디로 디자인(Design)과 기술(Tech)의 오작교 같은 존재입니다. 디자인의 의도가 개발과 충돌하는 부분은 없는지 파악하고, 개발에 잘 녹아들 수 있도록 프론트엔드의 앞단을 맡고 있어요. 코인원 웹 서비스에서 제공하는 신규 기능의 마크업 개발을 담당하고, 운영하면서 생긴 이슈들을 처리합니다. 또한 마크업 레거시에 대한 유지보수 작업도 병행하죠.예를 들어, 코인원의 회원가입 페이지를 제작할 때 디자인 작업을 먼저 들어갑니다. 그럼 디자인 작업을 바탕으로 개발자들이 기능을 만들어 넣게 돼요. 이 때, 기능적인 개발을 제외하고 UI(User Interface)적인 부분을 제가 담당합니다. 회원가입 페이지에는 이메일 인증, 휴대폰 인증 등 여러가지 개발요소들이 많아요. 그래서 개발하기 전에 기능이 들어가는 기본적인 레이아웃을 만들어 개발자에게 전달합니다. 마크업 작업이 바탕이 되어 그 위에 기능 개발이 이뤄진다고 보시면 돼요.디자이너가 레시피를 만드는 사람이라면, 마크업 개발자는 레시피 재료를 세팅해 주는 사람이에요. 개발자들은 세팅된 레시피를 끓이고 버무려 요리를 완성시키고요. 저는 좋은 요리가 탄생할 수 있도록 중간과정을 도와주는 역할인거죠. ▲ 'Women Tachmakers 2019'에서 발표에 열중한 혜진님!Q. 디자인과 기술의 중간 역할을 담당하고 계시군요, 사실 중간자의 역할이라고 하면 이어주는 과정에서 고충(?)이 생길 것 같아요.아무래도 디자이너와 개발자, 양쪽과 다 소통해야하는 부분입니다. 디자이너 입장에서는 ‘왜 프론트엔드에서 이 디자인이 안되는걸까?’ 라는 불만이 생길때도 있고, 프론트엔드에서는 ‘왜 디자인이 이렇게 들어가야 하는걸까?’ 라고 이해를 못할 때도 있어요. 서로의 이해관계를 잘 전달해야 한다는 점이 나름의 고충이죠. 코인원에서는 ‘디자이너 - 마크업 개발자 - 프론트 개발자’의 협업 프로세스를 정립해서 각자가 맡은 분야에 집중 할 수 있는 초석을 다졌어요. 무엇보다도 배경이 다른 세 개의 직군이 원활하게 소통할 수 있는 체계가 잡혀 고충이 해결되고 있습니다 :) Q. 그렇다면 마크업 개발자는 어떤 부분을 기여한다고 볼 수 있나요?코인원 메인 화면에 기능 개발을 추가하지 않고도 마크업단에서의 처리만으로도 쉽게 변화를 줄 수 있습니다. 메인화면의 배너 이미지는 유저들이 코인원에 접속해 제일 먼저 마주하는 부분이죠. 그래서 유저들이 코인원의 시각화된 정보를 빠르게 접할 수 있도록 이미지를 교체합니다. 웹 페이지의 운영 측면에서 비주얼 개편을 빠르게 할 수 있는 환경을 만들어 놓고 대응하는거에요.곧 코인원 마이페이지 화면이 개편될겁니다. 웹 페이지를 새로 만든다는 것은 무에서 유를 창조하는 과정과 같아요. 제가 마크업 개발을 잘 해놓으면 다른 직군에게도 도움이 됩니다. 개발 속도도 더 잘 붙고, 디자인에서도 빈공간이 없는 페이지가 탄생하는거죠. 최대한 밑바탕을 꼼꼼하게 만들어 모두가 일에 더 집중할 수 있는 환경을 만든다고 보시면 돼요.Q. 코인원 마이페이지에서 새롭게 바뀌는 부분은?기존의 마이페이지는 유저들이 보기에 정리가 잘 안되어있다는 느낌이 있었어요. 어떤 인증과정을 끝마쳐야 하는지 한눈에 들어오지 않는 부분이 있었거든요. 이번에 개편될 마이페이지는 좀 더 명확해졌습니다. 이전의 인증페이지가 도돌이표의 느낌이었다면, 이번에는 UX(User experience)를 생각해서 flow 개선도 많이 이뤄졌습니다. 편리한 암호화폐 거래 경험을 코인원에서 느낄 수 있어요. (새롭게 바뀔 마이페이지 많은 기대 부탁드립니다! 물론 편리한 암호화폐 거래도 언제나 코인원!)Q. 유저들에게 편리한 거래경험을 선사하기 위해 어떤 가치를 가장 중요시 여기나요? 저는 중간자이므로 유저들 뿐만 아니라 개발까지 두 가지 측면을 모두 고려합니다. 유저의 입장에서 사용성과 접근성이 용이한 마크업을 짜려고 하고, 개발측면에서는 유지보수가 편리한 마크업을 최대한 짜려고 해요. 개발하기 편한것과 사용하기 편한 것은 다른 맥락이거든요. 요새는 코인원 디자인시스템을 적용하고 있어요. 디자이너 분들이 정리해주신 디자인 시스템을 잘 적용시켜서 코드적으로도 재사용성이 용이하게 관리가 되도록 하고, UI도 정돈이 되어가는 과정을 진행 중입니다. 이런 과정을 계속 거치면 유저들에게 편리한 거래 경험을 선사하는 부분은 놓치지 않을 것 같아요.▲ 마크업에 열중하고 있는 혜진님 (약간의 설정샷 +_+)Q. 코인원 크루로 일하면서 장점을 뽑자면?유저플로우셀은 코인원이 셀이라는 목적조직으로 개편되고나서 만족도가 높은 셀이라고 알고 있어요. 업무도 많은 편인데, 톱니바퀴처럼 잘 맞물린다는 느낌이거든요. 특히 일에 대해서 선긋지 않고, 이슈가 발생했을 때 해결할 수 있는 부분들을 빠르게 파악해주는 부분들이 정말 좋아요. 속도랑 효율성 측면에서 이만큼 해낼 수 있는 팀은 앞으로 만나지 못할 것 같아요. 항상 원활한 업무 소통을 위해 힘써주시는 셀원들에게 감사 드립니다!Q. 앞으로 이루고 싶은 목표가 무엇인가요?회사 안 뿐만 아니라, 바깥에서의 활동도 꿈꾸고 있어요. 마크업 개발자들이 모두 모여 이야기할 수 있는 CSS 컨퍼런스를 열어 좀 더 커뮤니티를 활성화 시키고 영향력을 높이고 싶습니다. 아직 마크업 개발자들만이 모여서 이야기 할 수 있는 곳이 부족하거든요. 저의 이야기도 차곡차곡 쌓아서 여러 창구를 통해 들려드리고 싶고요.코인원에서는 지금 하는 것 이상으로 마크업 개발도 열심히 할거에요. 우선 단기적인 목표로, 프론트엔드에서 사용하고 있는 angular에 대한 이해력을 높일 겁니다. 마크업 컴포넌트 단위에 최적화 된 CSS로 개편해서 사용하지 않는 스타일 리소스가 최소화가 되도록 만들거에요.▲ 마크업 개발자에 많은 관심 부탁드려요 :)디자이너가 디자인에 집중할 수 있게, 개발자가 개발에 집중할 수 있게 ‘일잘러’로 통한다는 혜진님. 혜진님의 인터뷰를 통해 ‘마크업 개발자’에 좀 더 친해지는 시간이길 바라봅니다. 그리고 이렇게 멋진 코인원 크루와 함께 성장하고 싶지 않으세요?  현재 코인원은 멋진 크루들과 함께 크립토갤럭시를 헤쳐나갈 분들을 기다리고 있습니다 :-)

Understanding node.js 글을 번역한 글입니다. 부족한 영어 실력이지만 공부를 위해 번역하여 틀린 내용이 있을 수 있습니다. 이런 부분이 있을 경우 댓글로 알려주시면 감사하겠습니다!! 글이 문답형으로 진행되니 감안하시고 읽어주세요!Node.js(이후 '노드'로 통칭)를 소개했을 때 사람들은 일반적으로 두 가지 반응을 보인다. 바로 알았다고 하는 반응 혹은 매우 혼란스러워 하는 반응이다.만약 너가 후자의 경우라면 노드를 설명하기 위한 내 시도가 있다.노드는 command line tool이다. 너는 파일을 다운로드하고 컴파일하고 소스를 설치한다.노드는 JavaScript(이후 '자바스크립트'로 통칭) 프로그램들을 터미널에 'node my_app.js'를 입력함으로써 실행하게 한다.자바스크립트는 V8 자바스크립트 엔진으로 실행된다. (구글 크롬을 빠르게 만드는 것이다.)노드는 네트워크와 파일 시스템에 접근하기 위한 자바스크립트 API를 제공한다.나는 내가 필요한 모든 것을 Ruby, Python, PHP, Java에서 구현할 수 있어!너의 말이 맞다! 미안하게도 노드는 너를 위해 오고 너의 일을 하는 별난 유니콘이 아니다. 이것은 단지 툴이고 적어도 지금은 너가 보통 사용하는 완벽한 툴들을 대체하지 않을 것이다.요점을 알려줘!ㅇㅋ. 기본적으로 노드는 같은 시간에 여러 가지의 일들을 해야할 때 매우 좋다. 코드를 작성하고 "나는 이것들이 동시에 작동했으면 좋겠어"라고 말해본 적 있니? 노드에서는 너의 코드를 제외한 모든 것들이 동시에 작동한다.엥??정말이다. 너의 코드를 제외한 모든 것들이 동시에 작동한다. 이것을 이해하기 위해 너의 코드는 왕이고 노드는 왕의 하인들이라고 상상해보자.한 하인이 왕을 깨워 왕이 필요한 것들이 있는지 물어보는 것으로 하루가 시작된다. 왕은 하인들에게 해야할 일 목록을 주고 다시 오랫동안 자러 간다. 하인은 이 할 일들을 동료들에게 나눠주고 그들은 일을 시작한다.하인이 일을 끝내면 그는 왕의 쿼터 밖으로 보고서를 나열한다. 왕은 한 하인씩 따로따로 들여보내고 그들의 보고서를 듣는다. 때때로 왕은 나가는 길에 하인에게 더 많은 일을 준다.인생은 좋다. 왕의 하인들이 동시에 왕의 모든 일들을 수행하는 동안 왕은 하나의 결과가 있는 보고서에만 따로따로 집중할 수 있다.짱이다! 하지만 그 어리석은 비유를 그만두고 컴퓨터적으로 말해줄 수 있니?ㅇㅋ. 간단한 노드 프로그램은 아래와 같을 것이다:너의 코드는 노드에게 파일을 읽고 쓰는 두가지 일을 주고 자러 간다. 노드가 일을 완료했을 때 이것을 위한 콜백이 실행된다. 하지만 그들은 동시에 실행되는 콜백이 될뿐이다. 콜백이 실행을 완료하는 동안까지 다른 모든 콜백들은 라인에서 멈춰있어야 한다. 게다가 그 콜백들이 실행될 것이라는 보장도 없다.그래서 나는 동시에 같은 데이터 구조에 접근하는 코드에 관해 걱정할 필요가 없지않아?맞다! 그것이 자바스크립트의 싱글 쓰레드와 이벤트 루프 디자인의 아름다움이다. 좋긴 하지만 내가 왜 노드를 써야해?한 가지 이유는 효율성이다. 웹 어플리케이션에서 너의 메인 응답 시간 비용은 대개 너의 모든 데이터베이스 쿼리들이 실행하는데 전력하는 시간들의 합이다. 노드에서는 제일 느린 쿼리를 실행하는 동안 응답시간을 줄이기 위해 너의 모든 쿼리를 즉시 실행한다.또 다른 이유는 자바스크립트다. 너는 노드를 브라우저와 백엔드 사이에서 코드를 공유하기 위해 사용할 수 잇다. 자바스크립트는 정말 다방면성의 언어다. 너가 과거에Python, Ruby, Java, PHP를 써왔다하더라도 아마도 어떤 자바스크립트를 선택해왔을 것이다.마지막 이유는 로우 스피드다. V8은 계속해서 행성에서 가장 빠른 동적 언어 인터프리터의 하나로 경계를 밀고 있다. 나는 자바스크립트만큼 적극적으로 속도를 위해 푸시되는 다른 언어를 생각할 수 없다. 게다가 노드의 I/O 설비는 정말 가볍고 너의 시스템의 가능한 많은 I/O 능력을 활용하게 다가가는 것이다.그러면 너는 내가 당장 내 모든 앱을 노드에서 구현하라고 말하는거야?그렇기도 하고 아니기도 하다. 너가 노드 망치를 휘두르기 시작하면 모든것들은 분명 손톱처럼 보이기 시작할 것이다. 하지만 만약 너가 데드라인이 있는 일을 한다면 너는 아래의 사항들을 기초하여 결정하고 싶을 수도 있다.- 적은 응답 시간과 높은 동시성이 중요한가? 노드는 이것에 정말 좋다.- 프로젝트가 얼마나 큰가? 작은 프로젝트는 괜찮다. 큰 프로젝트는 아마 신중하게 평가해야 한다. (이용가능한 라이브러리, 버그를 고치기 위한 리소스들, 투 업스트림 등)윈도우에서 노드가 실행되니?안된다. 만약 너가 윈도우라면 너는 리눅스와 함께 버츄얼 머신을 실행해야 한다. (VirtualBox를 추천한다.) 윈도우는 노드를 지원하는 계획이 있지만 그 포트와 함께 도와주기를 원하지 않는다면 앞으로 몇 달 동안 뜸들이지 마라.노드에서 DOM에 접근할 수 있니?좋은 질문이다! 접근할 수 없다. DOM는 물질적인 브라우저고 노드의 자바스크립트 엔진(V8)은 감사하게도 그 복잡한 모든것들과 분리했다. 그러나 사람들은 노드 모듈로써 DOM를 실행하여 일한다. 이것은 클라이언트 사이드 코드 유닛 테스트와 같은 매우 놀라온 가능성을 열어줄 것 같다. 이벤트 드리븐 프로그래밍은 어렵지 않니?그것은 너에게 달렸다. 만약 너가 juggle AJAX를 호출하는 방법과 브라우저에서 유저 이벤트들에 대해 이미 배웠다면 노드 사용 방법을 배우는게 큰 문제 아닐 것이다.그렇지 않다면 너가 유지 보수 디자인을 마련하는데 도움을 줄 수 있는 드리븐 개발을 테스트해라.노드는 누가 사용하고 있니?node wiki에 작고 불안정한 리스트가 있다. 야후는 YUI를 위해 노드를 경험중이고 Plurk는 거대한 comet을 위해 사용중고 Paul Bakaus(jQuery UI fame)은 노드 백엔드를 가지는 mind-blowing game engine을 빌드 중이다. Joyent는 노드 창시자인 Ryan Dahi를 고용하여 개발에 막대한 지원을 해주고 있다.아 그리고 Heroku는 실험적으로 hosting support for node.js를 발표했다.어디서 더 배울수 있니?Tim Caswell는 훌륭한 How To Node 블로그를 운영중이다. 트위터에서 #nodejs를 팔로우해라. 메일링 리스트를 구독해라. 그리고 IRC 채널 #node.js에서 시간을 보내라. 우리는 곧 200 lurker-mark에 도달해 간다. 또한 나는 계속 http://debuggable.com/에 글을 쓰고 있다. #트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유

본 포스팅은 아래 코드를 보시면 좀 더 이해하기 쉽습니다.build.gradledependencies-variable.gradledependencies-classpath.gradledependencies-app.gradleGradle 의 역할Gradle 은 이제 안드로이드 개발에 있어서 그 중심이 되는 빌드 환경입니다. 안드로이드 빌드에 대한 기본 설정 뿐만 아니라 빌드에 필요한 Task 를 지정하거나 의존성을 추가할 수 있습니다.특히 의존성에서 일반적인 서비스들은 다양한 오픈소스를 활용하게 됩니다. 네트워크 라이브러리, 이미지 라이브러리, DI 라이브러리, Support 라이브러리,Play-Service 라이브러리 등등 이젠 프로젝트를 시작함에 있어서 기본적으로 10개 이상의 라이브러리를 추가하게 됩니다. 이러한 라이브러리들이 많아질수록 필연적으로 빌드 스크립트가 길어지게 됩니다. 이는 나중에 빌드에 관련된 코드를 추가/수정할 때 유지보수에 영향을 끼치게 됩니다.Gradle 의존성 분리하기토스랩에서는 꽤 많은 숫자의 라이브러릴 사용하고 있습니다. 테스트용 라이브러리들까지 포함해서 60여개의 라이브러리를 쓰고 있습니다. 이러한 라이브러리 코드들이 1개의 빌드 스크립트 안에 포함되어 진다면 라이브러리의 버전을 변경하거나 수정하는 작업을 할 때에는 불가피하게 시간이 소요될 수 밖에 없습니다.그에 따라 Gradle 에서 라이브러리들을 변수화 해서 분리하는 작업을 하였습니다.1. 라이브러리 변수화 하기ext { retrofit = 'com.squareup.retrofit2:retrofit:2.1.0' retrofit2_gson = 'com.squareup.retrofit2:converter-gson:2.1.0' retrofit2_rxjava2 = 'com.jakewharton.retrofit:retrofit2-rxjava2-adapter:2.1.0' } 가장 간단한 변수화였습니다. 하지만 Retrofit 은 관련 라이브러리들이 함께 수반되기 때문에 버전명을 다시 분리하였습니다.2. 라이브러리 버전 변수화 하기ext { retrofit_version = '2.1.0' retrofit = "com.squareup.retrofit2:retrofit:$retrofit_version" retrofit2_gson = "com.squareup.retrofit2:converter-gson:$retrofit_version" retrofit2_rxjava2 = "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$retrofit_version" } 하지만 버전명과 라이브러리이름이 함께 있는 것이 깔끔해보이진 않습니다. 그래서 아래와 같이 바꿨습니다.3. 라이브러리 이름과 버전의 분리ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] 실제에는 다음과 같이 사용하면 됩니다.dependencies { compile rootProject.ext.dependencies.retrofit2 compile rootProject.ext.dependencies.retrofit2_gson compile rootProject.ext.dependencies.retrofit2_rxjava2 } 이제 라이브러리를 변수화 해서 분리를 하였습니다.이제 변수로 지정한 라이브러리들은 build.gradle 파일안에 존재하게 됩니다.// build.gradle ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] buildscript { // blah blah } 라이브러리가 3개뿐이니 깔끔해보이는군요. 하지만 토스랩의 라이브러리는 60여개 입니다. 변수명도 60여개라는 말이죠. 그래서 라이브러리 변수들만 파일을 분리하기로 했습니다.4. 라이브러리 변수를 파일로 분리하기// dependencies-variable.gradle ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] // build.gradle apply from :'dependencies-variable.gradle' buildscript { // blah blah } 이제 좀 교통정리가 되어가는 기분이네요.하지만 app 의 build.gradle 을 보았습니다.// app 의 build.gradle apply plugin: 'com.android.application' dependencies { // 라이브러리 60개 compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 } android { // 중략 } 뭔가 잘못되어 가고 있습니다. 여전히 dependencies 가 큰 부분을 차지하고 있습니다.5. app.dependencies 분리하기이제 dependencies 를 분리할 차례입니다.// dependencies-app.gradle repositories { jcenter() } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 compile rootProject.ext.dependencies.library.okhttp3 compile rootProject.ext.dependencies.library.okhttp3_logging compile rootProject.ext.dependencies.library.stetho_okhttp3 } // app 의 build.gradle apply from: 'dependencies-app.gradle' 이제 dependencies 와 관련된 스크립트가 분리되었습니다.하지만 저 apply from 이 항상 app 의 build.gradle 에 따라 붙어야 하는 것이 아쉽습니다. 그래서 buildscript 에 아예 추가하기로 하엿습니다.6. 빌드 스크립트에 dependencies 추가 동작하기먼저 빌드 스크립트용 스크립트를 만들겠습니다.// dependencies-classpath.gradle rootProject.buildscript.repositories { jcenter() } rootProject.buildscript.dependencies { classpath rootProject.ext.dependencies.classpath.android } 그리고 buildscript 가 시작될 때 모든 dependencies 스크립트가 인식할 수 있게 하겠습니다. 인식할 스크립트는 다음과 같습니다.dependencies-variable.gradle - 라이브러리 변수 저장dependencies-classpath.gradle - 빌드용 스크립트 저장dependencies-app.gradle - 라이브러리 추가 스크립트 저장rootProject 의 build.gradle 를 아래와 같이 변경합니다.// rootProject 의 build.gradle buildscript { apply from: "dependencies-variable.gradle" apply from: "dependencies-classpath.gradle" } apply from: 'dependencies-app.gradle' 위와 같이 변경을 하면 빌드스크립트가 동작하는 시점에 변수를 인식하고 빌드용 스크립트를 인식합니다.하지만 앱용 라이브러리 추가 스크립트는 아직 준비가 덜 되었습니다. “app” 프로젝트가 인식이 된 시점에 라이브러리가 추가되어야 하기때문에 처음 만들었던 스크립트로는 한계가 있습니다.그래서 아래와 같이 변경하겠습니다.// dependencies-app.gradle rootProject.allprojects { project -> if (project.name == 'app') { project.afterEvaluate { repositories { jcenter() } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 } } } } afterEvaluate 는 프로젝트의 인식이 완료되면 동작이 되는 함수이기 때문에 모든 것이 끝나고 dependencies 가 추가되는 것으로 이해하시면 됩니다.정리위의 과정을 거침으로써 gradle 파일은 좀 더 나뉘었지만 app 의 build.gradle 은 안드로이드 프로젝트 그 자체에 집중 할 수 있도록 하였습니다.이렇게 나누었던 본래의 목적은 의존성 라이브러리와 코드 품질 관리용 스크립트가 1개의 스크립트 파일에 담겨지면서 관리하는 데 있어서 큰 문제가 발생하게 되었습니다. 그에 따라 각각을 나누고 그 목적에 맞도록 각가의 파일 만들었습니다.라이브러리의 변수용 파일buildscript 용 classpath 를 관리하는 파일본 프로젝트의 라이브러리 의존성 관리 파일참고 소스Github : https://github.com/ZeroBrain/DataBind-MVVM-Sample#토스랩 #잔디 #JANDI #개발 #개발후기 #인사이트

수많은 개발자 직군들개발자가 되기 위해서는 프로그래밍 언어만 배운다고 끝나는 것이 아닙니다. 자신이 배운 언어를 가지고 어떤 개발자가 될지 고민도 해야합니다. 실제로, 많은 분들이 내가 어떤 분야의 개발자가 되야 할지 고민을 많이 합니다. 그런데 이 고민에 앞서 어떤 개발자의 종류가 있고 직군이 있는지를 살펴보아야 합니다. 그래서 이번에 준비한 연재는 개발자 직군 파헤치기 시리즈입니다. 우리가 개발의 한 직군이라고 부를 수 있는 것들 중 관심이 많이 가는 직군들을 위주로 알아볼 것입니다. 일하는 분야에 대한 직군(게임 개발자)에 대한 이야기도 할 것이고, 지금 이야기할 프론트-엔드, 백-엔드처럼 개발의 영역에 대한 이야기도 할 것입니다. 다양한 관점에서 개발자의 영역들을 살펴볼 것입니다. 자, 그럼 지금부터 시작해 보죠!(※이 글은 유다시티 3Web Dev Careers Decoded: Front-End vs Back-End vs Full Stack을 번역한 것입니다.Front, Back and Full Stack우리가 매일같이 인터넷을 사용하는 과정을 떠올려봅시다. 새 브라우저 탭을 열고 URL을 입력 한 다음 Enter 키를 누르면 그 즉시 사이트가 로딩이 됩니다. 깔끔한 레이아웃, 잘 구성된 페이지, 그리고 화려한 시각적 효과들은 때로 감탄을 자아내죠.순식간에 일어난 이 모든 경험을 담당하는 사람들이 바로 웹 개발자들입니다.2018 년 4 월 현재 인터넷에 있는 페이지의 수는 45 억개가 넘습니다.  지금 이 순간에도 그 수는 계속 늘어나고 있습니다. 누군가 안정적인 직업을 찾고 싶다면 웹 사이트의 코딩, 설계, 분석 및 유지 관리를 담당하는 사람들, 곧 웹 개발자들을 찾아야 할 것입니다.웹 사이트는 이제 모든 비즈니스가 경쟁력을 유지하는 데 중요한 구성 요소입니다. 웹 개발의 트렌드와개발의 패러다임이 거의 매 시즌마다 바뀌는 상황에서, 개발자에 대한 수요는 부족함이 없습니다.그러나 웹 개발자의 범위는 매우 넓기 때문에 정확히 어떤 종류의 웹 개발자 채용 공고를 찾아보아야 하고, 그러한 개발자가 되기 위해 무슨 교육을 받아야 하는지를 판단하기는 쉽지 않습니다.  만약 구직 사이트를 둘러 보거나 온라인 강좌를 알아본 경험이 있다면, 프론트엔드, 백엔드, 그리고 풀스택 개발자라는 용어를 한번쯤은 들어보았을 것입니다.HTML, 자바 스크립트 또는 약간의 파이썬을 사용해 본 적이 있지만, 막상 개발자 직군에 대해서는 막막했다면 이 글이 매우 유용할 것입니다. Photo by Annie Spratt on UnsplashFront-End Developer프론트엔드는 웹사이트 중 사용자가 직접 상호작용을 하게 되는 부분입니다. 글꼴 부터 색상, 드롭 다운 메뉴 및 슬라이더에 이르기까지 인터넷에서 보게 되는 모든 것들은 브라우저의 제어를 받는 HTML, CSS 및 JavaScript의 조합입니다.SKILLS AND TOOLS프런트엔드 개발자는 웹 사이트에서 사용자가 직접 경험하는 부분과 그 경험의 아키텍처를 담당합니다. 이를 위해 프론트엔드 개발자는 HTML, CSS, Javascript 활용에 능숙해야합니다. 언어를 잘 다루는 것 외에도 프런트 엔드 개발자는 사용자의 도구에 따라 유연한 방식으로 컨텐츠를 보여줄 수 있게 하는 Bootstrap, Foundation, Backbone, AngularJS, EmberJS와 같은 프레임워크에 익숙해야합니다. 또한 jQuery, LESS와 같은 라이브러리를 사용할 수 있다면 더욱 유용하고 효율적인 코드를 작성할 수 있게됩니다. 프론트엔드 개발자를 채용할 때에는 Ajax 사용 경험을 요구하는 경우도 많습니다. 백그라운드에서 서버 데이터를 가져와 페이지를 동적으로 만드는 Javascript를 활용하는 데 있어서 Ajax는 보편적으로 사용되는 기술이기 때문입니다.프런트 엔드 개발자는 백엔드 개발자가 만든 집의내부 디자인을 담당합니다.프론트엔드 개발자는 이러한 기술을 사용하면서도, 목업(mockup) 혹은 와이어프레임(wireframe)의 개발에서 전달의 단계까지 디자이너 또는 사용자 경험 분석가와 긴밀히 협력합니다. 실력 있는 프론트엔드 개발자는 사용자 경험에서의 문제를 정확하게 발견하고, 디자인을 수정에 관한 조언과 문제 해결을 위한 코드를 제공합니다. 또한 목표와 필요, 기회들을 정확히 이해하고 수행하기 위해서는 다른 팀들과 유연하게 협력하는 능력이 중요합니다. 이처럼 프론트엔드 개발자의 작업은 여러 영역에 대한 책임을 동시에 감당하는 일이면서도 그만큼의 보람이 따라오는 것이기도 합니다. 8 년차 프론트엔드 개발자 인 Mikey Ilagan은 아래와 같은 이야기를 합니다.저는 기술적인 사람이면서도 시각적인 사람입니다.그래서 저는 자연스럽게 목업과 코드를 동시에 다루며 사람들이디지털 플랫폼과 상호작용하는 방식을 만들어 낼 수 있게 되었습니다.-Mikey Ilagan-종합해보자면, 프론트엔드 개발자는 백엔드 개발자가 만든 집의 내부 설계를 담당합니다. 집을 장식하는취향과 스타일은 집주인이 결정합니다. Apptix의 제품 마케팅 디렉터인 Greg Matranga는 "프론트엔드에서 작업하는 개발자는 자신의 창의성을 실질적으로 작업에 반영할 수 있기 때문에 때로는 자신이 하는 일에 대해 더욱 흥분한다"며 자신이 관리하는 프론트엔드 및 백엔드 개발자 팀 모두에게 말하기도 했습니다.HOW IT TRANSLATES지금 이 블로그에서 보고있는 모든 것은 프론트엔드 개발자의 손을 타지 않은 곳이 없습니다. 물론 로고와 그래픽은 디자이너가 만들고, 사진은 자신 작가가 찍었으며, 텍스트는 지금 글을 쓰고 있는 제가 작성합니다. 그러나 이 모든 조각들을 모아 웹으로 만들고, 각 페이지마다 사용자가 경험할 것을 설계한 것은 프론트엔드 개발자입니다.Photo by Lee Campbell on UnsplashBack-End Developer프론트엔드에서 일어나는 일을 이해했다면, 그것만으로는 웹사이트가 완성되지 않는 다는 것 역시 이해했을 것입니다. 그렇다면 프론트엔드 자체를 가능하게 만드는 것은 무엇일까? 데이터는 어디에 저장되는 것일까? 바로 백엔드입니다. 웹 사이트의 백엔드는 서버, 응용 프로그램 및 데이터베이스로 구성됩니다. 백 엔드 개발자는 이러한 구성요소들이 작동할 수 있게하는 기술을 만들고 유지하는 일을 합니다. 이러한 작업을 통해 비로소 사용자에게 보여지는 측면이 존재할 수 있게 됩니다.SKILLS AND TOOLS서버, 응용 프로그램, 데이터베이스가 서로 통신 할 수 있도록 만들기 위해 백엔드 개발자는 PHP, Ruby, Python, Java, .Net과 같은 서버 측 언어를 활용하여 응용 프로그램을 만듭니다. 또한 데이터를 검색, 저장 또는 변경하고 이를 프론트엔드 코드로 사용자에게 다시 제공하기 위해서는 MySQL, Oracle 및 SQL Server를 사용합니다. 백엔드 개발자에 관한 채용 공고는 그 외에도 1) Zend, Symfony 및 CakePHP와 같은 PHP 프레임 워크에 대한 경험, 2) SVN, CVS 또는 Git과 같은 버전 제어 소프트웨어 사용 경험, 3) 개발 및 배포 시스템으로서의 Linux 사용 경험을 요구하는 경우가 있습니다.백엔드 개발자는 이러한 도구를 사용하여 깔끔하고 모듈화가 가능한 코드로 웹 응용 프로그램을 만듭니다. 그러나 이와 같이 코드를 작성하기 전에 백엔드 개발자는 비즈니스 이해 관계자와 소통하면서 구체적인 요청 사항을 파악해야 합니다. 그런 다음 이를 기술적 내용으로 변환하여 기술 설계를 위한 가장 효과적이고 효율적인 솔루션을 제시할 수 있어야 합니다.나는 데이터를 다루는 것을 좋아하기 때문에항상 백엔드 개발을 선호 해 왔습니다.-JP Toto-오랫동안 백 엔드 개발자였던 JP Toto는 현재 와일 비트의 소프트웨어 개발자입니다. 그는 "최근 공개 및 비공개 API는 모바일, 웹 사이트를 포함한 여러 시스템간에 데이터를 교환하는 데 필수적인 부분이되었으며, 사람들이 유용하다고 생각하는 API를 만드는 것은 그에게 큰 만족감을 주는 일 중에 하나"라고 말한다.HOW IT TRANSLATES여러분이 코드스테이츠의 웹사이트를 찾아 들어오는 과정을 봅시다.  웹사이트의 서버는 여러분의 컴퓨터 또는 모바일로 정보를 보내고, 그 정보는 코드스테이츠 소개가 담긴 페이지로 보여집니다. 이 프로세스는 백엔드 개발자의 작업 결과입니다. 또한 회원가입을 할 때 저장되는 개인정보, 그리고 로그인을 할 때마다 각 계정의 정보가 불러와지는 과정 역시 백엔드 개발자 덕분입니다.Full Stack Developer프론트엔드 개발과 백엔드 개발 간에는 흑백 구분이 없는 경우가 종종 있습니다. 프론트엔드 개발자는 종종 추가 백엔드 기술을 습득해야하며 그 반대의 경우도 있습니다. 개발자는 여러 분야를 넘나들어야 할 때가 많아 종종 제너럴리스트가 되어야 합니다.  풀스택 개발자라는 역할은 7년 전 페이스북의 엔지니어링 부서에서 대중화되었습니다. 풀스택 개발자라는 호칭은 프론트엔드와 백엔드 모두에서 교차적으로 작업 할 수 있는 역할을 지칭하는 것에서 시작했습니다. 말 그대로 풀패키지(full package)를 제공하는 개발자라는 뜻입니다.서버와 클라이언트 측 모두에서 작업할 있는 전문성은더 많은 기회를 열어줍니다.-Federico Ulfo-Grovo의 풀스택 개발자인 Federico Ulfo는 이를 음식에 비유에 이야기합니다. "요리와 베이킹 중에 하나를 잘할 수는 있습니다. 그러나 두 가지를 모두 마스터하는 데에는 시간과 경험이 필요합니다. 마스터 한다는 것은 단지 레시피를 따라서 만드는 것을 말하는 게 아닙니다. 그건 누구든지 할 수 있습니다. 마스터 한다는 것은 직접 재료를 고르고 자신의 레시피로 훌륭한 음식을 만들어내는 것입니다."Photo by freestocks.org on UnsplashSKILLS AND TOOLS풀스택 개발자는 백엔드 개발자와 마찬가지로 웹 프로그래밍의 서버 측에서 작업하지만, 이와 동시에 사용자 측에서 콘텐츠가 보여지는 방법에 관해 프론트엔드의 언어로 능숙하게 소통할 수 있습니다. 아래의 이미지는 풀스택 개발이 얼마나 복잡해지고 있는지를 체감하게 해줍니다. 몇년 전까지만 해도 3-4가지의 기술의 종합으로 표현될 수 있었던 풀스택은 현재 7개의 기술이 종합된 형태로 훨씬 복잡해졌음을 알 수 있습니다.출처: Techrunch출처: Techrunch구체적인 기술의 종류는 프로젝트나 클라이언트에 따라 달라질 수 있지만, 풀스택 개발자는 기술의 종류와 상관없이 Linux 서버의 설정과 구성, 서버 측 API 작성, 클라이언트 측 JavaScript, 디자인을 맡는 CSS 등 웹이 작동하는 모든 차원에 있어서 해박해야합니다.풀스택 개발자는 이러한 기술들을 사용하여 클라이언트 측과 서버 측이 담당할 영역을 즉각적으로 구분해내고, 다양한 솔루션들의 장단점을 명확히할 수 있어야 합니다. HOW IT TRANSLATES풀스택 개발자는 로딩 시간부터 레이아웃, 그리고 사용자와의 상호작용성과 구조적 토대에 이르기까지이 게시물이 주는 경험의 전체적인 흐름을 책임집니다.The Bottom Line웹 개발에는 많은 면모가 있습니다. 그러나 당신이 어떠한 개발자가 되고 싶든지 디테일에 주의를 기울이는 능력, 빠르게 학습할 수있는 능력, 문제를 효율적으로 해결하는 능력, 그리고 커뮤니케이션 능력은 당신을 돋보이게 만들것입니다. 다행히 웹 개발 분야에서 경력을 쌓기 위해 이보다 더 좋은 시기는 없습니다. 웹 개발자의 고용은 2014 년에서 2024 년까지 10 년 동안 27 % 증가 할 것으로 예상되며 이는 모든 직종의 평균보다 빠릅니다. 지금까지 Front, Back, Full Stack 개발자에 대해서 알아보았습니다.다음 포스팅은 개발의 한 축을 담당하고 있기는 하지만 일반 개발 분와야는 다른 '게임 개발자'에 대해서 알아보도록 하겠습니다.

지난 Part 1 포스팅에 이어 자바스크립트 기초 문법에 대해 정리해보았습니다. 이번 포스팅에서는 여러 객체와 그 객체에서 제공하는 각 메서드에 대해 정리하였습니다. 다루는 객체의 여러 메서드에 대해 정리하였기 때문에 전 포스팅처럼 간략하지는 않지만 이번 포스팅을 저장해 두고 자바스크립트로 개발하면서 필요할 때마다 참고하여 보기에는 좋을 것 같습니다. 다만, 메서드 사용 예의 코드는 넣지 않았으니 예제 부분이 필요하다면 필히 공식 문서를 참고해주세요. 익히는 것 자체도 공식 문서를 통하여 보는 것이 가장 좋지만 혹여 영어에 취약하신 분이라면 이 포스팅을 참고하는 것도 괜찮을 것 같습니다. :)내장 객체브라우저의 자바스크립트 엔진에 내장된 객체. String/Date/Array/Nath/RegExp Object 등이 있음.날짜 객체 DateDate 객체 생성new Date()new Date(milliseconds)new Date(dateString)new Date(year, month, day, hours, minutes, seconds, milliseconds)Date Get 메서드getDate() - 일 정보를 가져옴.getDay() - 요일 정보를 가져옴. 0(일요일)-6(토요일)getFullYear - 연도 정보를 가져옴. (yyyy)getHours() - 시간 정보를 가져옴.getMilliseconds() - 밀리초 정보를 가져옴. 0-999 (1/1000 초의 단위)getMinutes() - 분 정보를 가져옴.getMonth() - 월 정보를 가져옴. 현재 월에서 -1한 값으로 옴.getSeconds() - 초 정보를 가져옴.getTime() - 1970년 1월 1일부터 경과된 시간을 밀리초로 가져옴.Date Set 메서드setDate() - 일 정보를 설정.setFullYear() - 연도 정보를 설정. 원한다면 월과 일 정보도 설정할 수 있다.setHours() - 시간 정보를 설정.setMillseconds() - 밀리초 정보를 설정.setMinutes() - 분 정보를 설정.setSeconds() - 초 정보를 설정.setTime() - 1970년 1월 1일부터 경과된 시간을 밀리초로 설정.기타 Date 메서드now() - 1970년 1월 1일부터 지금까지의 밀리초를 반환.parse() - 날짜 형태의 문자열을 변환하여 1970년 1월 1일부터 입력한 날짜까지의 밀리초를 반환.toString() - Date 객체를 문자열로 변환.toJSON() - Date 객체를 JSON 데이터로 변환.valueOf() - Date 객체를 밀리초로 반환.숫자 객체 NumberNumber 생성var num = 1;      var num2 = new Number(1);Number 객체의 속성MAX_VALUE - 표현 가능한 가장 큰 수.MIN_VALUE - 표현 가능한 가장 작은 수.POSITIVE_INFINITY - 무한대 수 표기.NEGATIVE_INFINITY - 음의 무한대 수 표기.NaN - 숫자가 아닌 경우 표기.Number 객체 메서드toExponential(n) - 자수 표기법으로 소수점 n자리만큼 문자형 데이터로 반환.toFixed(n) - 소수점 n자리만큼 반올림하여 문자형 데이터로 반환.toPrecision(n) - 유효 숫자 n의 개수만큼 반올림하여 문자형 데이터로 반환.toString() - 숫자형 데이터를 문자형 데이터로 반환.valueOf() - 객체의 원래 값을 반환.parseInt(값) - 데이터를 정수로 변환하여 반환.parseFloat(값) - 데이터를 실수로 변환하여 반환.수학 객체 MathMath 메서드 및 상수Math.abs(숫자) - 숫자의 절댓값을 반환.Math.max(숫자1, 숫자2, 숫자3) - 숫자 중 최댓값을 반환.Math.min(숫자1, 숫자2, 숫자3) - 숫자 중 최솟값을 반환.Math.pow(숫자, 제곱값) - 숫자의 거듭제곱한 값을 반환.Math.random() - 0~1 사이의 난수를 반환.Math.round(숫자) - 소수점 첫째 자리에서 반올림하여 정수를 반환.Math.ceil(숫자) - 소수점 첫째 자리에서 무조건 올림에서 정수를 반환.Math.floor(숫자) - 소수점 첫째 자리에서 무조건 내림해서 정수를 반환.Math.sqrt(숫자) - 숫자의 제곱근 값을 반환.Math.PI - 원주율 상수를 반환.배열 객체 ArrayArray 생성var array = new Array();array[0] = 1;array[1] = 2;var array2 = new Array(1, "temp", true);var array3 = [1, true, "문자열도 가능"];Array 객체의 메서드 및 속성join(연결문자) - 배열 객체에 데이터를 연결 문자 기준으로 1개의 문자형 데이터로 반환.reverse() - 배열 객체에 데이터의 순서를 거꾸로 바꾼 후 반환.sort() - 배열 객체에 데이터를 오름차순으로 정렬.slice(index1, index2) - 배열 객체에 데이터 중 원하는 인덱스 구간만큼 잘라서 배열 객체로 가져옴.splice() - 배열 객체에 지정 데이터를 삭제하고 그 구간에 새 데이터를 삽입할 수 있음.concat() - 2개의 배열 객체를 하나로 결합.pop() - 배열에 저장된 데이터 중 마지막 인덱스에 저장된 데이터 삭제.push(new data) - 배열 객체에 마지막 인덱스에 새 데이터를 삽입.shift() - 배열 객체에 저장된 데이터 중 첫 번째 인덱스에 저장된 데이터를 삭제.unshift(new data) - 배열 객체의 가장 앞의 인덱스에 새 데이터를 삽입.length - 배열에 저장된 총 데이터의 개수를 반환.문자 객체 StringString 생성var str = "hello";      var str2 = new String("hi");String 객체 메서드 및 속성charAt(index) - 문자열에서 인덱스 번호에 해당하는 문자 반환.indexOf("찾을 문자") - 문자열에서 왼쪽부터 찾을 문자와 일치하는 문자를 찾아 최초로 일치하는 문자의 인덱스 번호를 반환. 찾는 문자가 없으면 -1 반환.lastIndexOf("찾을 문자") - indexOf와 동일하나 문자열의 오른쪽부터 찾음.match("찾을 문자") - indexOf와 동일하나 찾는 문자가 없으면 null을 반환.replace("바꿀 문자", "새 문자") - 문자열에서 왼쪽부터 바꿀 문자와 일치하는 문자를 찾아 최초로 찾은 문자를 새 문자로 치환.search("찾을 문자") - 문자열 왼쪽부터 찾을 문자와 일치하는 문자를 찾아 최초로 일치하는 인덱스 번호를 반환.slice(a, b) - a개의 문자를 자르고 b번째 이후에 문자를 자른 후 남은 문자를 반환.substring(a, b) - a 인덱스부터 b 인덱스 이전 구간의 문자를 반환.substr(a, 문자 개수) - 문자열에 a 인덱스부터 지정한 문자 개수만큼 문자열을 반환.split("문자") - 지정한 문자를 기준으로 문자 데이터를 나누어 배열에 저장하여 반환.toLowerCase() - 문자열에서 영문 대문자를 모두 소문자로 바꿈.toUpperCase() - 문자열에서 영문 소문자를 모두 대문자로 바꿈.length - 문자열에서 문자의 개수를 반환.concat("새로운 문자") - 문자열에 새로운 문자열을 결합.charCodeAt("찾을 문자") - 찾을 문자의 아스키 코드 값을 반환.fromCharCode(아스키 코드 값) - 아스키 코드 값에 해당하는 문자를 반환.trim() - 문자의 앞 또는 뒤에 공백 문자열을 삭제.브라우저 객체 모델(BOM)브라우저에 내장된 객체. window 객체브라우저 객체의 최상위 객체.window 객체 메서드open("url 경로", "창 이름", "옵션 설정") - 새 창을 열 때 사용.- open() 메서드 옵션 설정: width/height/left/top/location/status/scrollbars/tollbarsalert("메세지") - 경고 창을 띄움.prompt("질의 내용", "기본 답변") - 질의응답 창을 띄움.confirm("질의 내용") - 확인/취소 창을 띄움.- 확인 클릭시 true 반환, 취소 클릭시 false 반환.moveTo(x 위치값, y 위치값) - 창의 위치를 이동시킬 때 사용.resizeTo(너빗값, 높잇값) - 창의 크기를 변경시킬 때 사용.setInterval("스크립트 실행문", 시간 간격) - 일정 간격으로 반복하여 실행문을 실행시킬 때 사용.clearIntervar(참조 변수) - 참조 변수에 참조되어 있는 setInterval() 삭제.setTimeout("스크립트 실행문", 시간 간격) - 일정 간격으로 한 번만 실행문을 실행시킬 때 사용.clearTimeout(참조 변수) - 참조 변수에 참조되어 있던 setTimeout() 삭제.screen 객체사용자의 모니터 정보를 제공하는 객체.screen 객체 속성width/height/availWidth/availHeight/colorDepth(사용자 모니터가 표현 가능한 컬러 bit)location 객체사용자 브라우저의 주소 창에 url에 대한 정보와 새로 고침 기능을 제공하는 객체.location 객체 속성 및 메서드href - 주소 영역에 참조 주소를 설정하거나 URL 반환.hash - URL의 해시값을 반환.hostname - URL의 호스트 이름을 설정하거나 반환.host - URL의 호스트 이름과 포트 번호를 반환.port - URL의 포트 번호를 반환.protocol - URL의 프로토콜을 반환.search - URL의 쿼리를 반환.reload() - 새로 고침.history 객체사용자가 방문한 사이트 중 이전에 방문한 사이트와 다음 방문한 사이트로 다시 돌아갈 수 있는 속성과 메서드를 제공하는 객체.history 메서드 및 속성back() - 이전 방문한 페이지로 이동.forward() - 다음 방문한 페이지로 이동.go(이동 숫자) - 이동 숫자만큼의 페이지로 이동. 음의 값이면 이전 페이지로 이동.length - 방문 기록에 저장된 목록의 개수 반환.navigator 객체현재 방문자가 사용하는 브라우저 정보와 운영체제의 정보를 제공하는 객체.navigator 속성appCodeName - 방문자의 브라우저 코드명을 반환.appName - 방문자의 브라우저 이름 반환.appVersion - 방문자의 브라우저 버전 정보를 반환.language - 방문자의 브라우저 사용 언어를 반환.product - 방문자의 브라우저 사용 엔진 이름을 반환.platform - 방문자의 브라우저를 실행하는 운영체제를 반환.userAgent - 방문자의 브라우저와 운영체제의 종합 정보를 제공.문자 객체 모델(DOM)HTML 문서의 구조.선택자직접 선택자직접 문서에서 요소를 선택함. (id/class/폼 명/요소 명 등)document.getElementById("아이디 명") - 아이디를 이용해 요소를 선택.document.getElmentsByTagName("요소 명") - 요소의 이름을 이용해 요소를 선택.document.formName.inputName - 폼 요소에 name 속성을 이용해 요소를 선택.인접 관계 선택자직접 선택자를 사용해 선택해 온 문서 객체를 기준으로 가까이에 있는 요소를 선택함. (parentNode/childeNodes 등)parentNode - 선택한 요소의 부모 요소를 선택.childNodes - 선택한 요소의 모든 자식 요소를 선택. 선택한 모든 요소가 저장됨.firstChild - 선택한 요소의 첫 번째 자식 요소만 선택.previousSibling - 선택한 요소의 이전에 오는 형제 요소만 선택.nextSibling - 선택한 요소의 다음에 오는 형제 요소만 선택.문서 객체 이벤트 핸들러 적용하기onclick - 선택한 요소를 클릭했을 때 이벤트 발생.onmousevoer - 선택한 요소에 마우스를 올렸을 때 이벤트 발생.onmouseout - 선택한 요소에 마우스가 벗어났을 때 이벤트 발생.submit - 선택한 폼에 전송이 일어났을 떄 이벤트 발생.버튼document.getElementById("btn").onclick = function() {    alert("welcome");}일단은 참고하는 책을 기준으로하여 정리해보았는데 후에 시간이 될 때마다 공식 문서를 참고하여 번역한다는 생각으로 보다 세부적인 사항을 정리해도 좋을 것 같다는 생각이 드네요. 우선적으로는 빠르게 함수와 이벤트에 대해 배우고 객체에 대한 더 자세한 사항을 정리하도록 하겠습니다. 다음 포스팅은 자바스크립트의 함수와 이벤트에 대해 다룰 예정입니다!참고문헌:Do it! 자바스크립트+제이쿼리 입문 - 정인용JavaScript 튜토리얼 문서 (http://www.w3schools.com/js/default.asp)티스토리 블로그와 동시에 포스팅을 진행하고 있습니다.http://madeitwantit.tistory.com#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유

지난 2년 내내 투자자 미팅에서 귀에 박히도록 들었던 소리."캘린더앱은 돈이 되지 않아요."맞다. 캘린더앱은 돈이 되지 않는다.지난 몇 년간 다수의 회사들이 출시했던 화제의 캘린더 앱들의 말로를 함께 살펴보자.  1,000만 달러를 투자받은 캘린더앱 - Tempo지평만 열고 2015년에 인수 후 종료.  모두에게 사랑받던 캘린더앱 - SunriseMS가 1억 달러(1천억 원)에 인수를 해 화제가 된 후1년 만에 또 종료(2016년).뭐 바다 건너 이야기는 너무 멀게 느껴질 수 있으니, 국내의 사정을 살펴보자.참고로 아래 4개의 서비스 모두 종료 관련 공식 보도자료를 내지는 않았기에 가볍게 블로그나 커뮤니티를 통해서만 확인이 가능하다(그조차도 없는 서비스는 출시 정보로 대체했다).2015년 9월 다음카카오(현 카카오), 다음캘린더 서비스 종료.2017년 6월, SKT 썸데이 캘린더 종료(2016년 출시, 2017년 종료).2018년 12월, 네이버 타르트 종료.(네이버의 경우 오랫동안 유지 중인 '네이버 캘린더'가 있긴 하지만 사실 신규 '일정 관리 앱'을 실험적으로 출시했었다)위 3개 서비스는 다소 생소할 수 있지만 아래 쏠캘린더는 대부분 한번 정도 들어본 적 있으리라 생각한다.위 서비스들 중 가장 많은 사용자를 확보했던 쏠캘린더도 결국 2016년 가을 종료. (쏠캘린더는 다음과 카카오 합병 전 카카오에서 출시된 서비스라 다음캘린더와 쏠캘린더는 다른 서비스였다)위의 4개, 아니 3개 회사가 캘린더 서비스를 종료하게 된 이유는 각기 다를것이고, 공식 보도자료는 없지만 업계 관계자 및 당사자 분들이 남겨놓은 몇몇 자료들을 통해 소소하게나마 내막을 엿볼 수 있었다.다음캘린더 서비스 개발 비하인드 스토리SKT 모바일앱은 왜 거의 다 '단명'할까 네이버 타르트 - 연구 종료 일지결국 그렇게 국내 현 캘린더 시장은 구글 캘린더, (기존)네이버 캘린더, iOS 기본 캘린더, 삼성 / LG 등 안드로이드 내장 캘린더, 4개 캘린더가 4등분하고 있으며 그 외에도 다양한 커스터마이즈 캘린더와 아웃룩이 작은 포션을 차지하고 있다(물론 어디까지나 국내의 이야기로 나라마다 상황은 다르다).커스터마이즈 캘린더를 쓰는 대부분은 구글 캘린더 또는 iOS 기본 캘린더 서버를 연동해서 사용하기에 사실상 자체 캘린더 서버를 운영하는 기업은 구글과 네이버, 그리고 애플뿐이다. 그런데 또 iOS 캘린더 유저의 상당수는 구글 캘린더를 연동해서 쓰기에 여러모로 얽히고설키고 복잡한 시장이다. 아 원래 하려던 얘기로 돌아와서, 여하튼 카카오와 SKT가 시도하다 접었고 네이버, 구글, 애플이 꽉 잡고 있는 이 시장에,2017년 대학생 5명이 또 하나의 캘린더 기반 서비스를 들고 뛰어들었다.(그렇다. 그 얘기 하나 하려고 이렇게 글이 길어졌다.)이름하야 '받아보는 캘린더 - 린더'. 때는 바야흐로 2017년 1월, 졸업을 앞둔 대학생 5명이 학교 강의실에 모여 창업 아이템을 구상하던 그 시절, 공동창업자 중 한 명이 '일정'을 아이템으로 서비스를 만들어보자고 의견을 던졌다.당시 그는 몇 주 전 교내 '캠퍼스 CEO'라는 창업 수업에서 '일정 관리 및 추천' 기능을 가진 서비스 기획서를 과제로 제출했던 상황이었고 팀의 리더였던 나는 그 제안을 듣고 허탈하게 웃으며 "그런 건 구글이나 네이버가 하는 겁니다"라고 단칼에 거절했다(원래 형 동생이었던 우리 팀은 팀빌딩 시점부터 존댓말을 썼다).비록 나 또한 학생이었지만 다수의 공모전, 해커톤, 회사 근무를 통해 서비스를 출시해본 경험이 있었고 서비스의 기획, 개발, 출시, 마케팅, 운영까지 이어지는 프로세스를 몇 번 정도 겪어본 입장에서 또 하나의 '캘린더' 앱을 출시하는 건 미친짓이라고 생각했다(솔직히 이제와서 말하자면 아직 뭘 몰라서 그냥 하는 말이겠거니 했다).그런데 당시 그가 했던 말 한마디가 우리를 움직였다."그러니까 우리가 해야죠"그의 논리는 이러했다."구글이나 네이버가 할 정도의 아이템이니까 시장이 큰 건 이미 증명이 됐고, 근성과 패기, 실행력으로 그들을 이기면 되는 거 아닙니까? 그게 스타트업 아니에요?"그때 말렸어야 했다.그때 설득되지 말았어야 했다.그때는 몰랐다.'일정'이라는 분야를 기반으로 사업을 기획하고, 운영하고, 확장한다는 것이 이렇게 외롭고 힘든 일이 될 줄은.  앞서 언급한 바와 같이 해외 사례라고는 하나 같이 다 종료된 서비스밖에 없었고 국내 시장은 해외의 그 사례들을 몇 년 후 따라가다 종료되는 수준에서 그쳤다.그래서 우리는 판을 새로 짜기로 했다.우리가 만들고자 한 서비스는 캘린더를 기반으로 하거나, 캘린더처럼 생겼는데, 캘린더 앱은 아니어야 했다.캘린더의 메인 기능인 일정을 '입력'하거나 '수정'하는 기능은 다 빼고, 사이드 기능 중 하나인 '구독'을 핵심으로 뒀다.캘린더도 문제였지만 이미 포화된 앱 시장도 문제였다. 새로운 앱들이 하루에도 수십 개씩 출시된지도 모른 채 사람들의 기억 속에서 잊혀지고 있던 상황이었다.단순히 앱을 통해 돌파구를 찾기보다는, 다양한 판로를 찾아보기로 했다.몇 번의 시행착오를 거쳐,2017년 하반기 즈음 우리가 앞으로 가져가야 할 방향성이 명확해지기 시작했다.카카오, 네이버, SKT 같은 회사의 기라성 같은 업계 선배들이 몇십억을 쓰고도 캘린더 서비스를 종료할 수밖에 없었던 데는 분명 이유가 있었다.우리의 전략은 치밀해야 했고, 2017년 말 아래와 같은 3개년 로드맵을 구상하게 되었다.일정 구독 서비스 린더 - 3개년 로드맵(2017.12)(로드맵에 대한 자세한 내용은 https://brunch.co.kr/@five0203/33 에서 확인할 수 있다)위 로드맵을 바탕으로 지난해 하반기 출시된 모바일앱, 즉 관심 일정 구독 플랫폼:린더의 다운로드 수는 40만, MAU는 18만을 돌파했고 지금도 가파르게 상승하고 있다.  한 달에 린더를 통해 일정을 확인하는 횟수(PV)는 700만 건이 넘었고 린더 내 링크를 통해 웹사이트로 이동하는 전환 횟수는 하루 1만 건을 넘어서고 있다.지난 30일 간 약 10여 건의 광고 및 제휴 문의가 있었고 그중 몇몇은 실행으로 옮겨졌다.린더의 장점은 그동안 광고로만 인식되어오던 이벤트 정보들이 '유용한 정보'로 전달된다는 것이다.누군가에게는 광고인 일정이, 누군가에게는 정보가 될 수 있다는 이유로 린더는 사용자에게 '광고 없는 앱'으로 인식되고 있다.물론 광고의 비중이 올라갈수록 네이티브 광고마저도 거부감을 일으킬 수 있기에, 우리는 일정을 모아 놓치지 않도록 도와주는 최초의 목적을 지속적으로 잊지 말아야 한다.  광고 플랫폼 기업 DMC미디어가 발표한 '2018 DMC리포트 종합 보고서'에 의하면 광고를 의도치 않게 실수로 클릭한 사용자는 28.9%에 그치며, 사용자 10명 중 7명은 노출되는 광고에 관심 및 의도를 가지고 클릭하는 것으로 조사되었습니다.문자, 페이스북, 카톡 플러스 친구 등 기존 채널에 대한 피로도가 높아지고 있는 현시점에서 린더가 경쟁력을 가지게 된 이유는 캘린더 유형의 정보 전달이 현재까지 '유용한 정보'라는 인식이 강하기 때문이라 볼 수 있습니다.위에서 언급한 바와 같이 이미 다양한 유형의 수익모델을 준비 중인 린더이지만 보다 장기적 관점에서 서비스 가치를 보존하기 위해 노력해야만 하며, 서비스 수익화에 대한 사용자의 거부감을 '너무 빠르게' 증가시키지 않아야만 사용자 이탈을 사전에 방지할 수 있습니다.이는 우리가 발생시키고자 하는 수익의 총합이 사용자에게 전달되는 가치의 총합을 섣부르게 넘어서는 안된다는 것을 의미합니다.- 19년 3월 주주서한 중 -아직 우리의 목표 MAU에는 한참 미치지 못한 현 상황에서도 밀려드는 광고 제의를 보며, 팀을 최소한으로 유지하고 서비스 운영 비용을 낮춘다면 향후 서비스의 지속과 생존, 즉 ROI를 맞추어 나가는 것은 어렵지 않을 것 같다는 확신이 생겼다(물론 ROI를 맞추는 것과 BEP를 맞추는 것은 차원이 다른 얘기라 BEP를 달성하신 모든 회사를 진심으로 존경합니다).하지만 성장하지 않고 머무르는 조직은 도태하는 조직이기에, 우리 팀은 앞으로도 여러 무모한 시도를 멈추지 않을 계획이다.  "캘린더앱은 돈이 되지 않아요" 공식적인 투자 라운딩을 3주 전 처음으로 시작하게 됐는데, 작년까지만 해도 귀에 박히게 들리던 이 이야기를 올해는 단 한 번도 듣지 못했다. 애초에 중요한 건 돈이 되는 게 아니었다. 사람들에게 필요한 서비스를 만들고, 그를 통해 새로운 가치를 창출하는 것. 그게 우리가 해야 할 일이었다.다수의 불편함을 소수의 기술력을 통해 해결하며, 그것을 지속&확대하기 위해 수익을 만든다.돈은 수단이지 목적이 아니다.긴 글을 마치기에 앞서 우리의 시작을 잊지 않기 위해, 2017년에 남겼던 감성 페북글 하나와 최근에 진행된 린더의 기업 협업 사례 하나를 남겨본다.2017년 7월(법인설립 1달 후, 기보 대출 받은지 일주일 후), SKT 썸데이 캘린더, 여름 문자 서비스 종료 소회그로부터 약 1년 후인 2018년 10월, SKT NUGU 스피커 x 린더 - 데이터 협업 진행

안드로이드 개발을 하다보면 종종 OutOfMemory(OOM)에러를 만나게 됩니다. 이전에 올렸던 포스팅에서도 이 문제로 고생을 했는데요, 메모리 누수 관련 문제는 로직 에러와는 달라서 찾기가 매우 난감한 경우가 많습니다. 이러한 메모리 누수 관련 문제를 해결하기 위한 검사 기능을 제공하는 무료 툴이 있습니다. 바로 Eclipse MAT(Memory Analyzer)(MAT)입니다.Eclipse MATMAT은 사용자로 하여금 힙 메모리의 상황을 파악하게 해주어 메모리 누수 현상과 필요없는 메모리 할당을 감지할 수 있도록 도와줍니다. 또한 자동으로 보고서를 작성하여 어떤 객체들이 메모리 누수를 일으키는지에 대한 추측을 해주는 기능을 제공합니다. MAT은 Eclipse 플러그인이기 때문에 사용하려면 Eclipse가 깔려 있어야 합니다. MAT을 설치하려면 MAT 다운로드 페이지에서 자신의 Eclipse버전에 맞는 파일을 받으시면 됩니다.How to use MATMAT을 설치하였다면 Eclipse화면에서 MAT관련 탭이 뜹니다. 탭을 클릭 하고File -> Open Heap Dump 를 누르면 힙 상황이 기록 된 hprof파일을 읽어올 수 있습니다.탭이 뜨지 않는다면Window -> Open Perspective -> Other에서 Memory Analysis 를 누르면 탭이 뜨는 것을 볼 수 있습니다.hprof 파일을 읽어오면 분석을 시작하고 결과를 Overview 화면에 보여줍니다.파이 차트의 각 부분에 마우스를 갖다 대면 옆의 Inspector 화면에 해당 객체의 정보를 보여주는 것을 볼 수 있습니다.InspectorInspector 창에서는 선택된 객체의 내용을 볼 수 있습니다. 해당 객체의 클래스명과 패키지 명 그리고 해당 객체가 가지고 있었던 변수의 내용을 살펴볼 수 있습니다.유용한 기능들MAT에서 가장 중요하게 살펴볼 기능이라고 한다면 Leak suspoect report와 Dominator tree라고 볼 수 있습니다. Leak suspect와 Dominator tree 둘 다 가장 메모리를 많이 차지하고 있는 객체에 대한 정보를 제공합니다.Leak suspectLeak suspect는 가장 큰 용량을 차지하고 있는 객체들을 좀 더 세분된 파이 도표로 보여줍니다. Problem suspect 1을 보면 현재 이 스레드 객체의 크기가 전체 힙 메모리의 크기 중 19.73%를 점유하고 있다는 것을 알 수 있습니다. 전체의 20% 가까이 차지하고 있다는 것은 이 객체를 OOM의 범인(?)이라고 생각할 근거가 됩니다. 해당 객체에 대한 더 자세한 정보를 얻고 싶다면 Details을 클릭하면 됩니다.Dominator treeDominator tree를 띄우면 현재 덤프 된 매모리 스냅 샷 중 가장 큰 용량을 차지하고 있는 객체 순으로 정렬하여 보여줍니다. Leak suspect와 비슷해 보이지만 더 구체적인 정보를 제공한다는 점이 다릅니다. 따라서 Leak suspect로 현 상황에 대한 힌트를 얻은 후 Dominator tree에서 디테일하게 살펴보는 것이 시간을 절약하는 방법입니다.상위에 있는 몇몇 객체들이 가장 의심 되는 객체들이라고 볼 수 있겠습니다. 왼쪽의 화살표를 클릭함으로써 그 객체가 참조하고 있는 다른 객체들에 대한 정보들을 볼 수 있습니다. 각 객체를 클릭하면 옆에 Inspect창의 내용이 달라지는 것을 볼 수 있습니다.실제 이 스냅 샷은 이전 포스팅의 문제를 해결하려고 떠놓은 스냅 샷인데요, 이 결과를 보고 많은 메모리가 네트워크를 통해 받아오는 스트림을 처리하고 문자열로 가공하는데에 낭비되고 있다는 생각이 들어 다른 방법으로 우회하는 방법을 썼고 결과적으로 문제를 해결 할 수 있었습니다.Android에서 MAT사용법먼저 안드로이드 기기에서 힙 덤프를 수행하여 hprof파일을 생성해야 합니다. hprof파일을 생성하기 위해서 간단하게 취할 수 있는 2가지 방법이 있습니다.1. DDMS를 이용한 추출Eclipse의 DDMS를 이용하여 힙 덤프를 추출할 수 있습니다. 아 방법을 쓰려면 앱의 메니페스트 파일에 WRITE_EXTERNAL_STORAGE 권한을 부여해야 하며, sdcard에 쓸 수 있는 권한이 있어야 합니다. 이 방법을 통해 sdcard경로에 앱 패키지명의 hprof파일이 생성됩니다.2. Heap dump method안드로이드 API에서 제공하는 메서드 중에 hprof파일을 생성하는 메서드인 dumpHprofData가 있습니다. 이 메서드는 Debug 클래스의 메서드인 것을 알 수 있는데, 이 Debug 클래스에는 앱의 상태를 점검할 수 있는 여러 유용한 메서드가 있으므로 나중에 필요하면 사용할 수 있도록 익혀두면 좋습니다.Android hporf 파일 변환앞서 설명한 방법을 적용하여 hprof파일을 추출하였어도 안드로이드에서 추출한 hprof파일은 MAT에서 받아들이는 일반적인 hprof포맷과 다르기 때문에 먼저 변환하는 과정이 필요합니다. 이러한 기능을 제공하는 것이 기본 SDK에 포함된 hprof-conv유틸입니다. 이 유틸은 SDK폴더 내의 tools폴더 안에 있는데 사용하려면 콘솔에서$ hprof-conv <안드로이드용 hprof 파일> <변환할 hprof 파일> 를 치시면 됩니다. 이제 변환된 파일을 MAT에서 열면 분석을 하실 수 있습니다.More tipEclipse Memory Analyser (MAT) - TutorialMemory Analyzer BlogJava Performance blog상기의 사이트들은 MAT과 Java의 메모리 처리에 관련된 내용을 포스팅한 사이트들입니다. 한 번 들러보면 좋은 정보를 얻을 수 있을것입니다.#스포카 #꿀팁 #개발 #개발자 #스킬스택 #스택소개 #인사이트

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

1. Planning PokerStyleShare 개발팀에서는 스크럼을 활용하여 일을 진행하고 있습니다.1 스크럼에는 일감의 크기를 추정estimate하는 과정이 있는데요. 구성원들 모두가 일감에 대해 이해하고 일감의 크기가 어느정도인지 함께 논의하여 합의에 이르는 과정입니다. 스프린트 회의에서 일감을 등록한 사람(리포터)이 일감에 대해 설명하고 나서 전체 구성원들이 일감의 크기를 추정하는데, 이 때 사용하는 것이 바로 Planning Poker입니다.Planning Poker는 0.5부터 시작해서 1, 3, 5, 8, 13, 20, … 100과 같이 피보나치 수열로 증가하는 숫자를 가진 카드 덱입니다. 리포터의 설명이 끝난 뒤 스크럼 마스터가 하나, 둘, 셋을 외치면 각자 생각한 일감의 크기에 맞는 카드를 꺼내고, 스크럼 마스터는 구성원들의 추정치가 최대한 가까워지도록 부가설명이나 질문을 유도합니다.2▲ Planning Poker는 이렇게 생겼다. (출처: Control Group 블로그)하지만 개발팀이 커지면서 불편함이 생기기 시작했습니다. 회의에 참여하는 인원이 7-8명씩 되다 보니, 각자가 어떤 카드를 들고있는지 한눈에 보기가 어려워진 것입니다. StyleShare에서 자칭 아이디어 뱅크 역할을 담당하고 있는 저는 획기적인 방법이 필요하다고 생각했고, 굳이 카드를 꺼내들지 않아도 각자가 무슨 카드를 선택했는지를 쉽게 볼 수 있는 애플리케이션을 만들기로 결심했습니다.2. BLE (Bluetooth Low Energy)불편함을 덜기 위한 애플리케이션이므로, 사용자 경험이 굉장히 직관적이고 단순해야 했습니다. N:N 통신이 가능해야하고, 사용자를 귀찮게 하는 페어링Pairing이나 네트워크 접속 과정이 없어야 했습니다. 한마디로, 카드를 꺼내들고 눈으로 확인하는 것보다 더 편한 무언가를 만들어야 했습니다!처음에는 근거리 무선 통신을 위한 기술로 스타벅스에서 사이렌 오더 개발에 사용한 고주파 인식 기술을 생각했습니다.3 각자의 기기에서 선택한 카드에 맞는 소리를 내보내고, 다른 기기에서는 고주파를 읽겠다는 것이었는데요. Soundlly(구 aircast.me)와 같은 상업용 SDK를 쓰지 않는 이상, 사운드 프로그래밍을 한 번도 해본 적 없는 저에게는 데이터가 실린 고주파를 만드는 것부터 소리를 인식해서 데이터를 읽어내는 과정이 마치 화성에서 감자 키우는 이야기처럼 들렸습니다.그러다 문득 생각난 것이 바로 비콘Beacon입니다. 언젠가 소비자가 오프라인 매장에 방문하면 BLE를 이용해서 매장 위치를 파악하는 기술이 있다는 이야기를 들은 적이 있었습니다. 찾아보니 시중에 나와있는 대부분의 모바일 기기에서는 BLE를 위한 최소 조건인 블루투스 4.0을 지원했고, 페어링이나 네트워크 접속 과정도 불필요했습니다. 무엇보다, 화성에서 감자 키우는 것보다는 쉬워보였습니다.3. Swift로 BLE 개발하기그래서 BLE를 사용해서 개발하기로 했습니다. 컨셉은 간단했습니다. 내가 선택한 카드를 브로드캐스팅하고, 다른 사람들이 선택한 카드를 내 모바일 기기에 보여주면 되는 것이었습니다. BLE를 사용하면 정보를 브로드캐스팅할 수 있고, 다른 기기에서 브로드캐스팅하는 정보를 읽을 수 있습니다.BLE에서 데이터를 브로드캐스팅하는 것을 Advertising이라고 합니다. 정보를 advertising하는 주체는 Peripheral이고, advertising되는 정보를 스캔하여 데이터를 읽어들이는 주체는 Central이라고 합니다. Peripheral에서 정보를 advertising할 때에는 특정한 정보를 실어나를 수 있는데요. 이를 Advertising Data Payload라고 합니다. 이 정보에 카드 숫자와 이름을 실어서 전송하면 될 것 같습니다.BLE를 구현하기 위해서, iOS에서는 SDK에 기본적으로 포함돼있는 CoreBluetooth 프레임워크를 사용하면 손쉽게 개발이 가능합니다. CBPeripheralManager 클래스와 CBCentralManager 클래스를 쓰면 되는데요. BLE를 이용하여 제 이름 석자를 advertising하는 코드는 다음과 같습니다.Peripheralimport CoreBluetooth let serviceUUID = CBUUID(string: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX") let service = CBMutableService(type: serviceUUID, primary: true) /// 1. `CBPeripheralManager`를 초기화하고, self.peripheral = CBPeripheralManager(delegate: self, queue: nil) /// 2. 사용가능한 상태가 되면 특정 UUID를 가진 서비스를 추가한 뒤에 func peripheralManagerDidUpdateState(peripheral: CBPeripheralManager) { if peripheral.state == .PoweredOn { self.peripheral.addService(service) } } /// 3. 원하는 정보를 advertising합니다. func peripheralManager(peripheral: CBPeripheralManager, didAddService service: CBService, error: NSError?) { self.peripheral.startAdvertising([ CBAdvertisementDataLocalNameKey: "전수열", CBAdvertisementDataServiceUUIDsKey: [serviceUUID], ]) } 참고로, UUID는 커맨드라인 명령어를 통해 쉽게 만들 수 있습니다.$ uuidgen XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX 마찬가지로, Peripheral에서 advertising하는 정보를 스캔하는 Central 코드는 다음과 같이 작성할 수 있습니다. UUID는 Peripheral에서 advertising에 사용한 UUID와 동일해야합니다.Centralimport CoreBluetooth let serviceUUID = CBUUID(string: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX") let service = CBMutableService(type: serviceUUID, primary: true) /// 1. `CBCentralManager`를 초기화하고, self.central = CBCentralManager(delegate: self, queue: nil) /// 2. 사용가능한 상태가 되면 특정 UUID를 가진 서비스를 스캔합니다. func centralManagerDidUpdateState(central: CBCentralManager) { if central.state == .PoweredOn { // 이미 한 번 스캔된 정보라도 계속 스캔합니다. let options = [CBCentralManagerScanOptionAllowDuplicatesKey: true] self.central.scanForPeripheralsWithServices([serviceUUID], options: options) } } /// 3. Peripheral이 스캔되면 이 메서드가 호출됩니다. func centralManager(central: CBCentralManager, didDiscoverPeripheral peripheral: CBPeripheral, advertisementData: [String : AnyObject], RSSI: NSNumber) { print(advertisementData[CBAdvertisementDataLocalNameKey]) // "전수열" } 스캔을 시작할 때 CBCentralManagerScanOptionAllowDuplicatesKey 옵션을 true로 설정해서 한 번 스캔된 정보라도 중복으로 계속 스캔하도록 합니다.4. 원하는 정보를 실어나르기CBPeripheralManager을 사용하여 advertising을 할 때에는 Advertising Data Payload를 포함시킬 수 있는데, 이 정보 중 개발자가 원하는 값을 넣을 수 있는 곳은 CBAdvertisementDataLocalNameKey밖에 없습니다. 그마저도 길이가 제한돼있기 때문에, 패킷을 효율적으로 사용하기 위해서는 정보를 저장하는 프로토콜을 직접 정의해야 합니다.우선, 카드에 대한 정의는 enum을 사용해서 작성했습니다. 0부터 0xFF까지의 숫자를 가지도록 정의했습니다.public enum Card: Int { case Zero = 0 case Half = 127 case One = 1 case Two = 2 case Three = 3 case Five = 5 case Eight = 8 case Thirteen = 13 case Twenty = 20 case Fourty = 40 case Hundred = 100 case QuestionMark = 0xFD case Coffee = 0xFE case None = 0xFF } 그리고 제가 정의한 패킷의 프로토콜은 다음과 같습니다.영역길이예시설명Version200프로토콜 버전 (00~FF)Channel201BLE 커버리지 내에서 회의하는 팀이 여럿일 수 있으니, 채널로 구분합니다. (00~FF)Card2FE카드의 16진수 값 (00~FF)Name12전수열사용자 이름 (UTF-8 기준 한글 4글자)이렇게 하면 총 18바이트 내에서 필요한 정보를 모두 전송할 수 있습니다. 이제 이 "00", "01", "FE", "전수열" 값을 직렬화해서 CBAdvertisementDataLocalNameKey로 advertising하면 됩니다.Peripheralself.peripheral.startAdvertising([ CBAdvertisementDataLocalNameKey: "0001FE전수열", CBAdvertisementDataServiceUUIDsKey: [serviceUUID], ]) 그리고, Central에서 정보를 스캔할 때에는 이 값을 각 영역의 길이에 맞게 끊어서 읽을 수 있습니다.5. 마치며비록 적은 양의 정보지만, BLE를 사용해서 실시간으로 근거리 통신을 할 수 있게 되었습니다. 이제 남은 것은 카드를 선택할 수 있는 화면과, 다른 사용자가 선택한 카드를 화면에 보여주는 인터페이스입니다. UI 개발은 본 포스트에서 중점적으로 다루고자 하는 주제와는 조금 벗어난 이야기가 될 것 같아, 오픈소스로 공개된 코드로 대신하려고 합니다. 소스코드는 GitHub에서 볼 수 있으며, Estimator는 앱스토어에서 받아보실 수 있습니다.6. 참고 자료BLE(BLUETOOTH LOW ENERGY) 이해하기 - Hard Copy World스타일쉐어의 스크럼이 지나온 길 포스트에 보다 자세히 설명되어 있습니다. ↩구성원들의 추정치에 차이가 난다는 것은 해당 일감에 대해 서로가 이해하고 있는 정도가 다르기 때문입니다. 스크럼 마스터는 구성원들이 일감에 대해 모두 비슷한 생각을 가지도록 커뮤니케이션을 유도해야합니다. ↩http://www.bloter.net/archives/226643 ↩#스타일쉐어 #개발 #개발팀 #개발자 #인사이트

편집자 주: 함께 보면 좋아요!애플리케이션 개발부터 배포까지, AWS CodeStarCodeStar + Lambda + SAM으로 테스트 환경 구축하기AWS Lambda + API Gateway로 API 만들어보자목차1. CodeStar 프로젝트 생성2. 템플릿 선택3. 프로젝트 정보 입력4. 프로젝트 생성 및 자동 배포 확인5. CodeCommit 접속6. staging 브랜치 생성7. index.py 수정 및 Commit8. 람다 실행 권한 변경9. 스택 생성 및 템플릿 소스 복사10. 템플릿 소스 붙여넣기 및 S3 버킷 URL 생성11. staging 브랜치용 CloudFormation 스택 생성(1)12. staging 브랜치용 CloudFormation 스택 생성(2)13. 파이프라인 설정14. AWS CodeCommit 연결15. CodeBuild16. CodeDeploy17. staging 브랜치용 파이프라인 생성 및 자동 릴리즈18. 작업 그룹 추가19. 파이프라인 실행 및 배포20. API Gateway 접속 및 엔드포인트 확인21. index.py 배포 확인OverviewAWS는 유용한 서비스를 많이 제공하지만, 이것들을 조합하고 사용하는 건 꽤나 번거롭습니다. CodeStar는 이런 고충을 해결해주고자 등장한 서비스입니다. 버전 관리(CodeCommit)부터 빌드(CodeBuild)와 배포(CodeDeploy), 모니터링(CloudWatch)까지 한 번에 프로젝트를 구성해줍니다. 여기서 한 발 더 나아가 브랜치(master, staging)마다 자동으로 빌드, 배포되도록 구성했습니다. 이 포스팅에서는 AWS CodeCommit과 AWS Lambda(Python)을 사용했습니다. 물론 다른 스택을 사용해도 괜찮습니다.Practice1.CodeStar 프로젝트를 생성하겠습니다. CodeStar로 접속해 프로젝트를 생성합니다. CodeStar를 처음 사용한다면 서비스 역할을 생성하라는 창부터 나옵니다. 역할을 생성하고 진행합니다.2.왼쪽 필터에서 웹 서비스, Python, AWS Lambda를 클릭하고 프로젝트 템플릿을 선택합니다.3.프로젝트 정보를 입력하고 AWS CodeCommit을 선택, 프로젝트를 생성합니다. 코드편집 도구설정은 건너뜁니다. 나중에 다시 설정할 수 있습니다.4.조금 기다리면 프로젝트가 생성됩니다. 오른쪽 아래의 엔드포인트로 접속하면 자동으로 생성되는 예제 프로젝트가 잘 배포된 것을 볼 수 있습니다. 클릭 몇 번으로 자동 빌드, 배포에 모니터링까지 가능한 프로젝트가 구성되었으니 이제 staging 브랜치를 생성하여 똑같이 구성하겠습니다.5.먼저 브랜치를 생성하겠습니다. CodeCommit에 접속해 왼쪽의 브랜치 메뉴를 클릭하면 아래와 같이 master 브랜치가 생성된 것을 볼 수 있습니다.6.브랜치 생성을 클릭해 브랜치 이름은 staging, 다음으로부터의 브랜치는 master를 선택합니다.7.생성된 staging 브랜치를 클릭하면 파일 리스트가 보입니다. master 브랜치와 결과 페이지를 구별하기 위해 index.py 파일을 임의로 수정하겠습니다. index.py > 편집을 클릭해 output 문자열을 수정하고 Commit합니다.8.CodeStar는 CloudFormation 서비스로 인프라 리소스를 관리합니다. CloudFormation은 ‘스택’이라는 개념을 사용해 설정을 구성하고 있습니다. 지금은 master 브랜치의 template.yml 파일을 사용해 master 브랜치용 스택이 생성되어 있는 상태입니다.문제는 여기에 기본적으로 람다(lambda) 실행 역할이 구성되어 있는데, 이 역할의 리소스 접근 권한은 master 브랜치 람다로 한정되어 있다는 것입니다.1)이 글에서는 staging용 람다 실행 권한을 별도로 생성하는 방법으로 문제를 해결했습니다. staging 브랜치의 template.yml 파일을 열어 Resources: LambdaExecutionRole: Properties: RoleName을 임의의 값으로 수정합니다. 저는 뒤에 ‘-staging’을 붙였습니다.9.CloudFormation 스택도 따로 생성합니다. AWS CloudFormation에 접속하면 기본적으로 생성된 스택을 볼 수 있습니다. 기존의 스택 템플릿에서 조금만 수정해 스택을 생성하면 되니 템플릿을 복사해오겠습니다.awscodestar-testproject-lambda를 클릭해 오른쪽의 ‘Designer에서 템플릿 보기/편집’을 클릭하면 템플릿 소스를 볼 수 있습니다. 가장 아래의 템플릿 탭이 클릭되어 있는지 확인하고 그대로 복사합니다.10.다시 CloudFormation으로 돌아와 템플릿 디자인 버튼을 클릭하고 복사한 소스를 붙여 넣습니다. 여기서 마찬가지로 Resources: LambdaExecutionRole: Properties: RoleName을 조금 전의 이름과 같게 수정하고 저장합니다. 템플릿 언어를 YAML로 바꾸고 수정하면 보기 편합니다.Amazon S3 버킷에 저장하면 템플릿 파일이 S3 버킷에 저장되며 S3 버킷 URL이 생성됩니다. 잘 복사해둡니다. 템플릿 디자이너는 이제 닫아도 됩니다11.CloudFormation 창에서 스택 생성을 클릭해 Amazon S3 템플릿 URL에 복사한 URL을 입력합니다. 이후의 내용은 스택 이름만 다르게 하고, 나머지는 기본적으로 생성된 스택 정보와 동일하게 입력합니다. 기존에 생성한 스택 정보는 스택 상세 페이지 오른쪽의 스택 업데이트를 클릭하면 볼 수 있습니다.생성 페이지 마지막의 ‘AWS CloudFormation에서 사용자 지정 이름을 갖는 IAM 리소스를 생성할 수 있음을 승인합니다’를 체크하고 생성을 클릭합니다.12.staging 브랜치용 CloudFormation 스택이 생성되었습니다. 이 스택을 사용해 staging 브랜치용 파이프라인을 생성하겠습니다.13.CodePipeline으로 접속해 파이프라인 생성을 클릭하면 설정창으로 이동하는데, 아래 이미지와 같이 입력합니다.CodeStar프로젝트가 생성되며 IAM 역할과 S3 버킷이 자동 생성되는데, 동일한 역할과 버킷으로 설정하면 됩니다. 파이프라인 이름만 임의로 다르게 넣어줍니다.14.AWS CodeCommit을 연결해야 합니다. 아래와 같이 자동 생성된 리포지토리를 선택하고 미리 생성한 staging 브랜치를 연결합니다.15.CodeBuild를 알아보겠습니다. 기본 파이프라인에서 자동 생성된 프로젝트를 선택하고 다음을 클릭합니다.16.새 창을 열어 기존에 생성된 파이프라인 상세 페이지로 접속합니다. 편집을 클릭하고 Deploy 스테이지 편집을 클릭, GenerateChangeSet 편집 버튼을 클릭하면 설정값이 보입니다. 이 값을 참고해 다음 스텝을 아래와 같이 진행하면 됩니다.앞서 생성했던 staging 브랜치 파이프라인용 스택을 연결하고, 세트 이름을 임의로 다르게 넣습니다. ‘템플릿’과 ‘템플릿 구성 - 선택 사항’ 설정값도 다르니 주의합니다.17.다음으로 진행하면 staging 브랜치용 파이프라인이 생성되어 자동으로 릴리즈되고 있는 것을 볼 수 있습니다.18.여기서 master 파이프라인과 동일하게 Deploy 스테이지의 GenerateChangeSet 아래에 작업 그룹을 하나 추가해야 합니다. 마찬가지로 master 파이프라인을 참고해 작성힙니다. 작업이름, 새로 생성한 스택, staging용으로 임의 작성했던 세트 이름을 넣습니다.19.저장 후, 변경사항 릴리스를 클릭하면 파이프라인이 실행됩니다. 잠시 기다리면 완료와 함께 배포작업까지 이뤄집니다.20.모든 작업이 끝났습니다! 제대로 구성되었는지 엔드포인트로 접속해 확인해보겠습니다. AWS API Gateway로 접속해 staging 브랜치용 API Gateway를 클릭합니다.21.왼쪽의 스테이지 메뉴를 클릭하면 엔드포인트 URL을 볼 수 있습니다. 이 URL로 접속하면 위에서 편집한 staging 브랜치의 index.py가 배포된 것을 볼 수 있습니다. master 브랜치의 엔드포인트로도 접속해서 비교해보세요.ConclusionAWS의 서비스들은 강력하고 다양합니다. 그 수가 많아져 이제는 전부 다루기는커녕 나열하기도 어려울 정도입니다. 아마존에서도 이런 고충을 알기 때문에 여러 서비스를 묶어 간편하게 세팅하는 CodeStar를 제공하는 게 아닌가 싶습니다. 수가 많은 만큼 각각의 서비스를 정확히 이해하고 적절히 이용해 오버엔지니어링을 피하는 게 중요하겠습니다.참고1) IAM - 역할 - Permission boundary에서 확인 가능합니다글양정훈 사원 | R&D 개발3팀[email protected]브랜디, 오직 예쁜 옷만