유저 반응을 볼 때가 즐겁다는 프론트엔드 엔지니어 인턴 Mino조이에서 소프트웨어 엔지니어 인턴으로 살아간다는 것이 어떤지 궁금해 하시는 분들이 많아 4개월차 소프트웨어 엔지니어 인턴 미노(본명 천민호)를 Zoyiful Talk 첫 번째 주자로 모셨습니다.ZOYI: 미노 안녕하세요! 인턴으로 조인하신지 벌써 4개월이 지나셨다면서요. 우선 간단한 소개부터 해주세요. 회사에서 무슨 일을 하고 있나요?MINO: 안녕하세요, 채널(Channel)이라는 조이 신규 서비스를 개발하고 있는 엔지니어 미노입니다. 채널은 소비자와 커머스 기업을 연결해주는 소통 창구 같은 서비스인데요, 저는 그 중에 웹 프론트엔드를 개발하고 있습니다.ZOYI: 프론트엔드가 뭔가요? 좀 더 설명해 주세요.MINO: 프론트엔드는 흔히 ‘웹 개발자’라 하는데요, 웹이나 앱에서 서비스 이용자가 경험하는 부분을 개발합니다. 이용자에게 더 좋은 시각적 효과를 주고, 더 편리한 경험을 제공하기 위해 기술을 이용하죠. 이를 구현하기 위해 자바스크립트라는 언어를 사용하고, react.js를 프레임워크로 사용하고 있습니다.ZOYI: 원래부터 프론트 개발을 많이 하셨었나요?MINO: 프론트엔드는 HTML 작성할 수 있는 정도? 아니면 레일즈로 간단한 홈페이지 게시판 만드는 정도였어요. 자바스크립트는 조이에서 처음 배워봤고요.사실 개발 시작한 것 자체가 작년 9–10월이니 이제 반 년 좀 넘었네요. 코딩은 2년 전부터 시작했었는데 거의 알고리즘 공부가 위주였고 최근에야 제대로 개발을 한 것 같아요ZOYI: 조이에는 어떻게 조인하게 되신 거예요?MINO: 대학 개발 동아리 회장을 할 당시 대회 후원사가 필요해서 레드(CEO)한테 컨택한 적이 있거든요. 후원을 받고 나서 레드의 권유로 회사에 한 번 놀러왔는데, 사무실이 생각보다 좋더라고요. (웃음)스타트업 하면 좁은 공간에 다닥다닥 붙어있는 모습을 생각했었는데… 깔끔한 공간이 인상깊었어요.높은 천장과 통유리 채광을 자랑하는 조이 사무실에 반했다고 합니다.ZOYI: ㅎㅎㅎ 직접 일해보니 어때요? 실제로도 깨끗하던가요?MINO: 레드의 책상이 좀 더럽긴 하지만…은 농담이고요, 실제로 일해보니 더 좋은 것 같아요. 책상도 넓고… 제가 이렇게 하얀 느낌을 좋아하거든요.ZOYI: 조이에서의 4개월을 지내보니 어때요?MINO: 음… 4개월 지나고 나니, 이제야 내가 뭘 모르고 뭐가 부족한지를 알 수 있게 된 것 같아요. 잘한다고 말하긴 아직 부끄럽지만, 적어도 구글링으로 뭘 찾아야 할지는 알 수 있게 됐어요.ZOYI: 안해본 것들을 했잖아요, 주로 어떻게 습득을 했어요?MINO: 사람마다 좀 다를 수 있는데 저는 그냥 시간 날때마다 조이 오픈소스 프로젝트들을 하나하나 열어보면서 이게 어떻게 동작하나를 봤어요. 그래도 모르면 물어보면서 Follow up 받고… 동료들한테 부담없이 물어볼 수 있어서 좋았어요. 촉진제같은 역할을 해 준 것 같아요.한 번은, 전혀 새로운 분야이고 처음 접해보는 언어를 다루는 거라 익숙치 못해 하루종일 구글링을 한 적이 있어요. 그런데도 오늘 커밋 했냐, 뭐했냐 이런 얘기가 없고… 당신의 성장을 그냥 지켜보겠다는 태도인 거예요. 처음엔 익숙하지가 않았는데, 그런 분위기 덕분에 결과적으로 리서치를 잘 하고 일을 성공적으로 마무리 할 수 있었어요.ZOYI: 동료들과 교류가 많은 편인가요?저는 프론트엔드를 하다보니 주로 개발팀 멤버들과 많은 시간을 보내는데요, 업무 외적으로도 되게 재미있어서 친하게 지낼 수 도 있고 그래요. 꾸준히 소통하려 하는 게 느껴져요. 나를 막연히 6개월 후 나가는 인턴이 아니라, 함께 성장해 가는 동료로 생각하고 있구나. 하는 기분이 들죠.ZOYI: 푸스볼 중독이라는데?MINO: 푸스볼도 ZOYI에서 처음 배웠는데, 이건 정말, 최고의 레져인 것 같습니다 (목소리 톤 올라감). 가격 대비 효율이 최고예요. 하루 한 번 이상 꼭 하고 있습니다.10분만 해도 맥박이 빨라진다는 엄연한 스포츠, 푸스볼ZOYI: 본인의 푸스볼 랭킹은?MINO: 글쎄요, 디케이(하드웨어 디자이너)보단 잘하지 않을까요? ㅎㅎZOYI: 인턴 끝나면 생각나겠어요, 그러고 보니 인턴도 이제 두 달 남았네요. 돌아가면 하고싶은 일이 있나요?MINO: 아직 고민중이예요. 사실 조이 들어오기 전에는 프론트, 웹 개발자는 정말 안하겠다고 생각했었는데 지금은 이게 재미있다는 생각이 들어요.초반에 누가 “잘 하게 되면 점점 재미있어 질거다”라고 말해준 적이 있는데, 그 말이 공감이 돼요. 점점 배워가면서 지금은 어느정도 의도한 대로 구현이 되니까…이젠 재미있는 거예요. 새로운 분야를 알게 된 느낌? 그래서 앞으로 프론트엔드 개발자로 일해도 좋고, 뭐든 최대한 많은 경험을 하고 많은 지식을 습득해 보고 싶어요.ZOYI: 좋은 계기가 되었네요, 인턴 생활은 만족스러워요?MINO: 네, 생각하던 것 이상으로 좋았어요. 주도적으로 일을 해 나갈 수 있다는 점과, 하나하나 해 나갈 때마다 내가 성장하고 있는 느낌이 좋아요. 사실 처음 입사할 땐 단순히 반복작업만 할 줄 알았거든요. ZOYI엔 뭔가 ‘네 꿈을 펼쳐봐라~’하는 태도가 있는데, 저는 거기에 잘 맞았던 것 같아요.ZOYI: 그렇다면 향후 ZOYI 지원을 고민하시는 분께 어떤 조언 한마디 해주시겠어요?MINO: 주변에 많은 친구들이 ‘난 안될거야’라고 생각하고 지원조차 안하는 경우가 많은데, 저는 일단 지원해 보라고 말해주고 싶어요. 저도 지원할 당시 굉장히 걱정을 했었거든요. 나는 알고리즘 공부밖에 못해봤고, 서버도 용어 하나도 모르는데 내가 잘 할 수 있을까?하는 생각.막상 회사에 들어오고 난 지금은 생각이 많이 달라졌어요. 인턴에게 중요한 자질은 완벽함보다 가능성인 것 같아요. 그 가능성이란 게 대단한 스펙이 아니라, 기초를 탄탄히 가지고 있는 거예요. 그리고 나면 회사에 와서 충분히 성장할 수 있어요.그 좋은 사례가 션(CTO)인 것 같아요. 함께 일하면서 CTO가 되어가는 모습을 곁에서 보는 게 참 좋았어요. 내부에서 우리가 성장해 더 큰 역할을 맡을 수 있는 조직이란 게 참 좋아요.ZOYI: 조언 감사합니다. 남은 기간 ZOYI에서 기대하는 점이 있다면?MINO: 이번 주부터 시작될 개발팀 위클리 세션이 기대돼요. 각자가 알고 있는 기술을 다른 멤버들과 공유하는 시간인데요, 조이가 워낙 다양한 기술을 다루다 보니 제가 담당하지 않는 분야에 대해서는 잘 모르는 게 많거든요. 같이 일하는 사람들은 어떤 분야에 대해 일하고 있는지 기술적으로 알아보고 싶어요.ZOYI: 좋은 시도네요. 마지막으로 글 읽으시는 분들께 한마디 하시겠어요?MINO: ZOYI는 잘하는 사람들이 와서 더 잘하게 되는 곳이 아니라 가능성 있는 사람들이 와서 잘하게 되는 곳이라고 생각해요. 누구에게나 열려 있으니 편히 찾아와 주셨으면 좋겠어요 ^^#조이코퍼레이션 #개발팀 #개발자 #개발환경 #업무환경 #팀원인터뷰 #팀원소개 #팀원자랑

출근이 즐거워지는바로고의 복지 문화13가지안녕하세요, 바로고 입니다.바로고 직원들의 출근이 즐거워지는13가지 이유바로복지 문화 13가지가 있기 때문이죠^^[바로고 복지문화]바로고 복지 문화에 대해자세히! 알고 싶다면 클릭!뼈가 되고, 살이 되는외부 인사 초청 강연훌륭한 팀워크와 업무 효율을 높이는유익한 외부 인사 초청 강연!맛있는 음식과 함께 해봐요^^2017년 9월 7일외부 인사 초청 강연강연자헬로네이처 허광남 CTO뼈가 되고 살이 되는강연의 주제는고객 행동 데이터 보면서 개발하기강연은바로고 본사에서 진행되었습니다.강연을 본격적으로 시작하기 전프로젝터로 점검하고간단한 담소를 주고받으며편안한 분위기를 만들어주시는 허광남님뼈가 되고 살이 되는 강연이그동안 바로고에서 진행된 만큼오늘의 강연 또한 기대됩니다!고객 행동 데이터 보면서 개발하기Elastic Stack오늘 강연은1. 데이터 시각화의 가치2. 오픈소스 시각화 패키지 Elastic Stack3. 유용한 플러그인 소개4. ELK 적용 사례위의 같은 순서로 알차게 진행되었습니다.시작부터 집중하는바로고의 직원들업무에 바쁘다 보면다른 정보를 습득하거나다른 분야의 사람들과 의견을 공유할 여유가 없을 수도 있어요.이렇게 외부 인사 초청 강연을 통해다양한 의견을 공유하고리프레쉬 하는 기회가 생기는 것에바로고 직원들의 만족도가 높은 편입니다.이번 강연의 핵심이었던Elastic Stack 의 특징에 대해간단히 설명해보겠습니다강연의 내용을 함께공유한다는 것에도 의미가 있어요^^Elastic Stack 특징-Google Analytics(GA)의 데이터로사이트 접속 통계를 구할 경우원하는 대로 데이터를 획득하기 어렵다.-자체 서버의 모든 로그를 100% 수집할 수 있기 때문에데이터에 대한 신뢰성이 높다.-파라미터 값별로 통계를 볼 수 있기 때문에정확한 데이터 분석이 가능하다.-검색엔진(lucene)이 포함되어 있어빠르게 데이터를 검색할 수 있다.-모두 오픈소스이며 자유롭게 사용이 가능하다.자유롭게 질문을 주고받으며의견을 공유할 수 있었던 의미 있는 시간이 되었습니다.이번 강연에서도다양한 의견을 주고받고같은 문제에 대해다양한 시각이 존재한다는 것을알게 된 계기가 된 것 같습니다.바로고 직원 모두에게의미있는 시간이 되었으리라 생각합니다.오늘 열정으로 강의해주신허광남님께 진심으로 감사의 말을 전합니다.또 다른 시각에서 접근하는고객에 대한 접근 방법뼈가 되고 살이 되는알찬 시간이 되었습니다.감사합니다!바로고의 외부 강연이 끝날 시간 즈음그 시간이 바로 점심시간열심히 강의 들었으니에너지 충전이 필요합니닷!모두 수고하셨습니다.선택이 아닌 필수#배달 #배달대행바로고날씨 좋은 9월, 야외에서 오늘은 쉬는 날, 집에서누구와 함께 든 어디에서든내가 원하는 곳으로 배달!-전국 배송망을 갖춘바로고에서라면가능합니다.배달대행[바로고 공식 홈페이지]

최근 Xcode 9.3 버전이 배포되었습니다. 이 버전에는 가장 최신의 Swift 4.1 버전이 포함되어 있습니다. Swift 4.1에는 여러 흥미로운 개선사항들이 많지만, 치명적인 버그도 존재합니다. 바로 딥링크를 통해 앱을 여는 경우 크래시가 발생하는 문제입니다. StyleShare에서는 QA 과정을 통해 문제를 발견할 수 있었습니다.만약 여러분의 애플리케이션이 아래 조건을 모두 충족할 경우 문제가 발생합니다:Swift 4.1 버전을 이용해서 빌드한 경우Deployment Target이 iOS 11.0 미만인 경우AppDelegate에서 application(_:open:sourceApplication:annotation:) 메서드를 구현한 경우문제를 재현하기에 가장 좋은 방법은 Safari 앱을 이용하는 것입니다.1. iOS 기기 또는 사뮬레이터에서 Safari 앱을 구동합니다.2. 주소 입력란에 앱이 지원하는 딥링크 URL을 입력한 뒤 이동합니다. (e.g. myapp://)3. 앱이 구동됨과 동시에 강제 종료됩니다.이 버그는 Swift 이슈 트래커에 SR-7240 티켓으로 이미 등록되어 있습니다. Resolved 상태로 표시되지만 이번 Xcode 9.3 버전에는 포함되지 않은 것으로 보입니다. 다행히 댓글에 한 개발자가 문제를 해결할 수 있는 workaround를 공유해두었는데요. 이 방법을 이용하면 당장의 문제는 해결할 수 있습니다. AppDelegate 메서드의 annotation 파라미터의 타입을 Any에서 Any?로 변경하는 것입니다.- func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool + func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any?) -> Bool<iframe width="700" height="250" data-src="/media/0ce1fe8c63fca7a6c953233b94406d02?postId=ed495077c36" data-media-id="0ce1fe8c63fca7a6c953233b94406d02" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/0ce1fe8c63fca7a6c953233b94406d02?postId=ed495077c36" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 100px;">UIApplicationDelegate에 정의된 메서드 시그니쳐와 다르기 때문에 컴파일러가 경고를 표시하지만 무시하셔도 됩니다.만약 새로운 버전의 앱을 릴리즈 할 계획을 가지고 계시다면 이 이슈를 꼭 확인하시길 바랍니다. 이 버그는 페이스북 로그인 등 다른 앱을 이용한 로그인이나, 카드 결제 후 주문서로 돌아오는 흐름에서 큰 문제를 일으킵니다. 이 글이 여러분들께 도움이 되길 바랍니다.Swift Korea 그룹에서 Xcode Release Notes에도 같은 내용이 있다는 것을 제보해주셨습니다. Swift Compiler 섹션의 Known Issues 4번째 항목입니다.#스타일쉐어 #개발팀 #개발자 #개발후기 #경험공유 #인사이트

2018년은 정말 클라우드가 일반화되는 해가 될듯 합니다. 클라우드 이전 사업 소식이 이곳저곳에서 들리는 요즘입니다. 스타트업 생태계는 이미 클라우드로 넘어갔지만 올해에는 엔터프라이즈 기업에서 대규모 IT 기업들까지 모두 클라우드로 넘어가고 있습니다. 와탭이 클라우드 최적화를 목표로 하는 모니터링 서비스이다보니 클라우드로 전환하는 시점에 있는 많은 기업들을 만나는데요. 클라우드를 적용하려고 준비중이거나 최근 클라우드로 이전한 기업의 운영팀들은 현업에서 사용하는 과정에서 클라우드 안정성에 대한 불안을 토로하기도 합니다. IT 운영자들이 느끼는 클라우드에 대한 불안감IT 운영의 핵심은 안정화입니다. 클라우드 이전까지 IT 인프라는 변화를 관리하는 대상이 아니였습니다. IT 인프라는 운영중에 변화하지 않으며 초기 설계에서도 최대 부하를 견디기에 충분한 여지를 남겨서 구성하였습니다. 하지만 클라우드에서는 IT 인프라가 운영중에도 변화 가능한 요소가 되면서 IT 인프라 규모 산정에서 부터 커다란 변화가 발생합니다. 최대 부하가 아닌 최소 부하가 규모 산정 기준이 되다. 여지껏 IT 인프라의 구성 기준은 언제나 최대 부하를 견딜수 있도록 설계되어왔습니다. 하지만 IT 인프라를 클라우드로 시작한 스타트업들이 IT 인프라를 구성하는 방법은 기존의 규칙을 무시하기 시작합니다. IT 인프라를 규모를 최소 부하에 맞춰서 구성하는 것입니다. 단지 실시간으로 확장 가능한 서비스 구조와 Auto Scailing을 통해 규모를 맞춰갑니다.IT 인프라 평균 부하의 기준이 높아지다. 클라우드 이전까지 우리는 IT 인프라의 CPU 부하율을 평소 20% 아래로 유지해 왔습니다. 하지만 이 또한 변화가 생깁니다. 제가 만나는 많은 클라우드 기반 서비스 기업들이 CPU 부하율을 50%에서 70%까지 유지하고 있었습니다. 일반적은 운영관점에서 IT 서비스 운영에 익숙하지 않은 기업의 운영 미숙이라 생각할 수 있습니다. 하지만 클라우드에 익숙한 운영팀은 서비스 성능에 문제가 발생하지 않는 범위에서 인프라의 규모를 실시간으로 조절합니다. 기존의 상식으로는 매우 위험해 보이지만 클라우드를 정말 잘 쓰는 기업들은 성능과 안정성을 해치지 않으면서 인프라 자원의 여유를 최대한 줄이는 방법들을 내재화하고 있습니다. IT 인프라 장애를 해결하지 않는다.  모든 IT 인프라는 장애가 발생합니다. 인프라의 장애는 이벤트성으로 발생하지만 운영팀은 장애를 반복 해결해 나가는 과정에서 패턴을 인지하고 대처해 나갑니다. 클라우드에서도 장애는 어쩔수 없이 발생하지만 운영팀은 장애를 인지할 뿐 장애를 물리적으로 해결하지는 않습니다. 대신 클라우드를 사용하는 IT 운영팀은 빠르게 서비스 구성과 환경을 전환하여 서비스를 원활하게 동작시킵니다. 운영자들이 갖는 불안감이 현실이 되다.다시 운영자들의 불안감에 대해서 이야기 해보죠. IT 인프라의 규모를 줄이고 자원 사용률이 평소에서 50%를 넘기는 급박한 사용 환경에서 클라우드 인프라에 장애가 발생해도 할 수 있는 일이 없다는 것은 정말 큰 스트레스를 주는 일입니다. 물론 위에서 설명한 것처럼 클라우드 네이티브한 서비스라면 문제없이 돌아갈 수 있겠지만 기존 레거시를 운영하면서 클라우드로 전환한다면 IT 운영자 입장에서는 앞에 이슈들이 불안감이 아닌 현실이 됩니다. 넷플릭스 7년만에 클라우드 이전을 완료하다.넷플릭스가 클라우드 이전을 결정한것은 2007년이지만 이전을 완료한것은 2016년이였습니다. 이렇게 긴 시간은 투자한 이유에 대해 넷플릭스는 "기존 IDC 기반의 인프라가 가진 문제들을 클라우드로 가져가지 않기 위해서"라고 했지만 다른 한편으로는 클라우드에서 발생하는 문제들을 해결할 수 있는 시스템 구조를 만들기 위해서였습니다. 그렇기 때문에 넷플릭스에서는 클라우드 네이티브 방식을 택하여 사실상 모든 기술을 재구축하고 운영 방식을 근본적으로 바꿨다. 아키텍처 면에서 넷플릭스는 거대한 앱을 수백 개의 마이크로 서비스로 마이그레이션하고 NoSQL 데이터베이스를 사용하여 데이터 모델을 반정규화했다. 예산 승인, 중앙화된 릴리스 관리, 몇 주에 걸친 하드웨어 프로비저닝 주기를 도입해 지속적인 콘텐츠 전달이 가능해졌으며, 느슨하게 결합된 개발운영(DevOps) 환경에서 엔지니어링 팀이 셀프서비스 툴로 독립적인 결정을 내릴 수 있게 되면서 혁신이 가속화되었다. 이 과정에서 새로운 시스템을 여럿 구축해야 했으며, 새로운 기술도 배워야 했다. 넷플릭스가 클라우드 네이티브 기업으로 변신하는 데는 많은 시간과 노력이 필요했지만, 클라우드 마이그레이션을 통해 글로벌 TV 네트워크로서 지속적인 성장을 이뤄나갈 밑거름을 마련할 수 있었다.https://media.netflix.com/ko/company-blog/completing-the-netflix-cloud-migration결론기존의 레거시를 바탕으로 클라우드 마이그레이션을 진행하는 기업들은 클라우드에서 발생하는 다양한 운영 이슈들을 겪을 수 밖에 없습니다. 대부분 클라우드 이전 사업을 진행하는 데 있어서 이전 서비스 성능을 맞추는 데만 집중하다보니 이전 후 운영과정에서 발생하는 많은 문제들은 운영팀이 짊어지게 됩니다. 하지만 이 문제들은 개발팀과 운영팀이 함께 지속적으로 개선해 나가야 합니다. 최종적으로 클라우드 네이티브 구조가 완성되기 위해서는 시스템과 조직 문화 모두가 변화해야 합니다. 클라우드 마이그레이션은 엄청 고난한 일입니다. 만일 클라우드를 도입했는데, 아직 불안함이 있다면 아직 클라우드 마이그레이션이 끝나지 않은것입니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

애플리케이션의 성능 개선은 웹 트랜잭션의 응답시간을 분석을 통해 이뤄집니다. 와탭의 응답시간 분포도는 대규모 트랜잭션 분석이 가능한 Heatmap 형태로 제공되고 있습니다. 와탭을 사용하는 사용자는 응답시간 분포도를 통해 웹 서비스의 응답시간이 느려지는 것을 알 수 있을 뿐만 아니라 패턴 분석을 통해 느려진 원인을 예측할 수도 있습니다. 와탭의 응답시간 분포도Y 축: 트랜잭션 응답시간을 의미합니다. 10s는 트랜잭션이 시작에서 종료까지의 시간이 10초가 걸렸다는 것을 의미합니다.X 축: 트랜잭션이 종료된 시간을 의미합니다.■: 트랜잭션이 발생한 위치에 색이 칠해집니다. 청색 계열은 정상적인 트랜잭션을 의미합니다. 노랑색과 붉은 색 계열은 에러가 발생한 트랜잭션을 의미합니다. 색상의 농도는 해당 영역에 발생한 트랜잭션의 밀도를 상대적으로 표시합니다.  와탭의 응답시간 분포도는 트랜잭션의 응답시간을 시각화하는 것입니다. 웹 서비스의 트랜잭션을 시각화 할 뿐만 아니라 추적하고자 하는 영역을 드래그하여 트랜잭션의 진행상황을 추적하는 것도 가능합니다.  추적하고 싶은 트랜잭션을 드래그 하는 모습와탭의 응답시간 분포도에서 트랜잭션을 선택하면 분석 화면으로 넘어갑니다. 해당 애플리케이션 서버 정보를 통해 선택된 트랜잭션이 어느 애플리케이션 서버에서 발생했는지 알 수 있습니다.애플리케이션과 선택된 트랜잭션 정보 화면분석하고 싶은 애플리케이션 서버를 클릭하면 해당 애플리케이션 서버에서 발생한 트랜잭션 목록을 확인 할 수 있습니다. 최종적으로 APM을 통해 확인하고 싶은 내용이 트랜잭션의 디테일한 정보일 것입니다. 와탭의 APM은 트랜잭션을 시각화하고 시각화된 트랜잭션을 선택하면 선택된 트랜잭션의 목록을 애플리케이션 서버 별로 분류하여 선택할 수 있는 구조를 가지고 있습니다. 이것은 능동적으로 웹 애플리케이션을 분석할 수 있는 최적화된 흐름이라고 생각할 수 있습니다. 사용자가 응답속도 분포도를 통해 선택한 트랜잭션 목록#와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

Activity는 화면의 기본 구성단위 입니다. 예전엔 하나의 Activity를 SubActivity 단위로 사용하려고 ActivityGroup으로 여러 Activity를 하나의 Activity로 묶어 사용했습니다. 이 방법은 장점보다 유지 관리 및 Lifecycle 관리 등의 이슈가 더 많았죠. 이제는 사용하지 않습니다.관리 이슈를 보완하기 위해 나온 것이 바로 Fragment입니다. View에는 없는 Lifecycle이 존재합니다. 이것을 이용해 Activity에서 할 수 있는 작업을 Fragment에서도 처리할 수 있습니다.더 이상 ActivityGroup을 이용해서 화면을 재활용하거나 Activity를 관리하지 않아도 됩니다. 대신 FragmentActivity를 이용해 여러 Fragment를 한 화면에서 보여주고 관리할 수 있게 되었습니다.브랜디에서 운영하는 하이버 앱은 위와 비슷하게 설계되어 있습니다. 화면의 기본이 되는 Activity에 실질적인 View를 담당하는 Fragment를 사용합니다. 여기에는 fragment layout이 있죠. 이런 설계 방식은 Activity 영역에선 보통 Toolbar 기능과 Bottom Menu Button을 만들 때 사용합니다. 실질적인 뷰는 Fragment 영역에서 보여주죠.하이버 앱은 Endless 기능을 포함한 RecyclerView가 80% 이상의 화면 비율을 차지합니다. 상품을 나열해서 보여주거나 스토어 목록을 보여주는 리스트 화면이 대부분이어서 RecyclerView에서는 다양한 api를 요청하고, 응답받은 데이터를 Adapter에서 View로 나누는 것이 주된 작업이었습니다.생각한 것과는 다르게 설계되고 말았습니다. 다양한 화면을 재활용하려고 사용한 Fragment들은 API 요청 URL만 바뀌었을 뿐, 화면의 재활용은 Lifecycle 기능이 없는 Adapter에서 관리했기 때문입니다.대부분의 Activity layout의 fragment는 fragment_default_f_adapter.xml 을 이용했습니다.더불어 Fragment를 사용하면서 제일 많이 접한 Fragmentmanager Transaction 버그 때문에 다양한 트릭을 써야 했습니다. 특히 비동기로 생기는 결함이 가장 큰 문제였습니다.문제점이 있어도 View에서는 가질 수 없는 Lifecycle 때문에 결국 Fragment를 사용해야 했습니다.이것은 모든 안드로이드 개발자가 가지고 있는 고민입니다. 하이버 앱은 리펙토링은 끝난 상태이기 때문에 더 이상 리펙토링에 시간을 쓸 수 없었습니다. 그래서 이번에 진행할 브랜디 리펙토링에서는 이 문제점을 고치려고 합니다. 저는 여기에서 도움을 많이 받았습니다.이전에도 이러한 라이브러리가 있다고 알고 있었지만 하이버를 리펙토링하면서 문제를 직접 마주하니 라이브러리가 왜 나왔는지 새삼 느꼈습니다. (역시 사람은 위기를 맞이할 때 큰 깨달음을 얻나 봅니다.)다음 화에서는 이러한 Fragment 문제를 극복하는 방법을 알아보겠습니다.글고재성 과장 | R&D 개발1팀gojs@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #안드로이드

오늘 만나본 앵커리어의 팀원은!바로 앵커리어의 숨겨진 하드캐리어 개발자 노선빈(a.k.a 메-쓰:수학)군 입니당!컴퓨터와 대화하는 것을 가장 좋아하는 줄 알았던 그와인터뷰를 빌미로 오랜시간 이야기를 나누었습니다!그 결과... 의외로 수다떨기를 좋아하는 타입의 선빈씨!(나 촉 되게 좋아~~~ 선빈씨 다 들켰어~~~)그럼 앵커리어랩 네번째 인터뷰 시작합니다!(ps. 내일(10월 13일)이면 예비군을 떠나시는 선빈씨에게 이 포스팅을 바칩니다! 예비군 화이팅!)INTRO. 인사밍케터) 간단한 자기소개 부탁드려요^^메-쓰) 자기소개? 이럴 수가.어려워요. 아무렇게나 하면 되나요? 양식이..? 음….팀에서 개발을 하고 있으며, Front-end를 맡고 있고, 아주 약간의 Back-end를 맡고 있습니다.밍케터) 임하는 각오는요?메-쓰) 각오는… 각오라기보다는 지금의 마음 상태가 무섭네요.밍케터)) 마케팅팀이 무서우신 건가요?!메-쓰) 아니 아니 아닙니다.인터뷰가 무서운 거죠.아시다시피 저는 말을 많이 하는 사람이 아니라서. 이런 자리가 익숙하지 않죠. 제1장. 안경_★po코딩wer★밍케터) 하시는 일 소개 부탁드려요.메-쓰) 앵커리어에서의 저의 업무!위에서 한 것 같지만, 다시 하죠. 조금 더 구체적으로.웹 사이트를 만들고, 페이지를 구성하는 일을 합니다.디자이너께서 결과물을 만들어 냈을 때,실제로 웹 사이트를 그렇게 보이게 만드는 일을 하고 있습니다. 밍케터) 선빈 씨는 코딩 언제부터 시작하셨나요?메-쓰) 음. 그게 초 6 때죠.대표께서 초 5 때부터 혼자 코딩을 했었어서, 근데 제가 친구 였어서, 저를 꼬셔서,'같이 해보지 않을래?' 해서 하게 됐죠?(선빈씨 음성지원 中)6학년 때 정보 올림피아드 나가고 하면서 컴공과에 가서 프로그래머를 해야겠다라고 생각했었는데, 고등학생때 수학이 재미있어서 물리학과로 진학했습니다.그런데 올해 초에 새해를 맞아 오랜 친구인 대표께 전화를 했는데, ‘새해 복 많이 받아라’라는 말씀과 함께 '개발자 필요한데 같이할래?' 이러셨죠.그래서 올해부터 갑자기 다시 직업으로 삼게 되었습니다.   밍케터) 공백기가 길었는데 감을 잃지는 않으셨나요?메-쓰) 예전이랑 컴퓨터 언어도 다르고 분야도 달라서 “완전 능숙해” 이 정도는 아닙니다.밍케터) 코딩이 가장 즐거운 순간은 언제인가요?메-쓰) 1. 버그 없이 잘 돌아갈 때.2. 어떻게 해야 할지 바로 떠올랐을 때.3. 알 수 없는 버그가 날 괴롭히지 않을 때.밍케터) 물리 vs 코딩. 어떤 것이 더 재미있나요?메-쓰) 물리가 재밌습니다…아 각각의 재미가 다르죠(다급).물리는…..네이쳐를 알아가는 것은 흥미롭잖아요? 안 그렇습니까?밍케터) (.....전 아닌 것 같습니다만….)메-쓰) 개발은 문제를 해결해 나가는 재미가 있습니다. 이런 방식으로 하고 싶은데 이럴 때는 어떻게 해야 할까 같은 문제들이요. 둘 다 재미있습니다. 흥미롭죠. 밍케터) 게임 좋아하신다고 하던데, 인생게임 있나요?메-쓰) 인생게임이라…. 도타라는 게임이 있는데, warcraft3 라는 게임의 mod 같은 건데…밍케터) 그럼 이 인터뷰는 어떠세요? 핵심을 찔러서 평가해주세요.메-쓰) 분위기는 좋습니다. 굉장히 자유롭네요. 자유분방. 편한 분위기. 밍케터) 모드요? 모드…???메-쓰) 스타크래프트를 해봤으면 유즈맵이라고 하면 딱 아실텐데… 뭐 어쨌든.DOTA(‘디-오-티-에이’라고 친절하게 풀어서 읽어주는 선빈 씨)라는 게임이 있습니다. 지금 롤과 같은 장르의 AOS의 시초가 된 게임입니다. 밍케터) 가장 자랑하고 싶은 코딩 결과물 알려주세요.메-쓰) 없으면 안 되는 거죠?밍케터) 웬만하면 있으시면 좋겠습니다.메-쓰) 제가 솔로로 만든 것 중에 ‘오 굉장해. 오 훌륭해’ 이런 것은 없고, 참여한 것 중에 훌륭한 것은 지금 만든 자소설닷컴이죠?개인 작업물 중에 생각나는 것은…예-엣날에 코딩 처음할 때. 야구게임이라고 아시나요?야구게임 프로그램 예시(feat.다른 개발자).jpg고1 때 굉장히 유행했는데 옛날에 하던 코딩이 생각나 심심할 때 만들어서 학교에서 풀었죠.사실 코딩하는 사람들이 보면 굉장히 별거 아닌데 학생들이 “오 신기해. 쩔어. 있어보여” 이랬던 기억이 나네요. 밍케터) 대표님과 친구인지 얼마나 되셨죠?메-쓰) 18년 이죠.밍케터) 네 그리고 초, 중, 고 계속 같이 다니셨고 한 공간에서 코딩하시고...혹시 라이벌 의식…?메-쓰) 아, 전혀 없습니다.저는 예전부터 라이벌 의식 뭐 이런 것을 가져본 적이 없어서. 좀 있었어야 할 것 같은데.밍케터) 근데 굳이 필요가 없어 보이네요. 다 잘하시니까…알아서 좋은 학교에 입학하시고...(...조용히 먼 산을 바라보며 반성하는 마케터들)제2장. 입_난 핵심만 찌른다밍케터) 팀원들이 선빈 씨에 대해 핵심을 찌른다는 평가를 했습니다. 혹시 본인만의 남다른 기준이 있으신가요?메-쓰) 팀에 합류했을 때, 대표님이 저에게 날카로운 평가를 많이 기대하는 것 같았는데... 합류하고 보니 이미 굉장히 잘하는 분이 있으셔서. (조용히 pm님을 쳐다본다.) 서로 뿌듯해하는 하드캐리어들.jpg메-쓰) 하드캐리어 이십니다. 굉장히 날카로운 분이세요.상위 호환이 가능합니다.밍케터) …...네? 상위호환이요? 그게 뭐죠?메-쓰) 음…..밍케터)(상위호환을 이해하지 못하는 것은 나의 잘못일까, 선빈씨의 잘못일까, 고급언어를 사용할 줄 아는 능력의 차이인가….또 다시 먼 산을 바라보는 밍케터...)메-쓰) 여기저기서 쓸 수 있는 성격이라는 말입니다. 더 나으신 분이죠.상위 호환이 가능한 pm님) 선빈씨 시사잡지도 계속 주기적으로 사서 보시잖아요?메-쓰) 주기적이진 않지만 내킬 때…?상위 호환이 가능한 pm님) 주변에 보면 시사 잡지를 구독하는 이공계생을 본 적이 별로 없어요.시사에 관심이 많으신가요? 나아가서 정치 사회적인 부분까지 관심이 많으신가요?메-쓰) 음, 관심이 없진 않죠. ...왜 관심이 생겼을까요?시사주간지는 딱히 주기적으로 사진 않지만 내킬 때 사는데...지하철 편의점 지나다니다 보면 ‘이번 주는 저런 이슈가 있군.. 사볼까?’ 이럴 때 삽니다.뭔가 인생, 삶에 있어서 충실함이 떨어지거나 나태함이 차오를 때?열심히 사는 사람의 느낌을 낼 때 사는 것 같네요.밍케터) 그럼 이 인터뷰는 어떠세요? 핵심을 찔러서 평가해주세요.메-쓰) 분위기는 좋습니다. 굉장히 자유롭네요. 자유분방. 편한 분위기.제3장. 피카츄_개발팀의 핵심멤버밍케터) 선빈 씨 방에는 피카츄 친구들이 많잖아요? 혹시 피카츄가 최.애.캐(최강 애정 캐릭터)인가요?메-쓰)  캐릭터로 말할 것 같으면... 딱히 딱 떠오르는 것은 없습니다.밍케터) (당황… 최.애.캐인줄 알고 질문을 준비했는데…!)메-쓰) 피카츄는 포켓몬에서 상품 제작이 많이 되고 프로모션이 많잖아요?그래서 가보니까 귀여워서 사온거죠.밍케터)그럼 질문을 좀 바꿔서 드립니다.만약 살아있는 피카츄를 얻을 수 있다면 대표님과 피카츄 중 누구를 선택하시겠어요?세상에 단 하나 뿐이고, 100만 볼트도 쓸 줄 아는 피카츄라면?그런데 살아있는 피카츄를 얻으려면 대표님과 연을 끊어야 한다면?메-쓰) 이게 직장이 걸린 문제라서 다른 직장을 찾을 수 있는가가 문제인데요.밍케터) 그럼.. 대표님 자리에 앉아서 일하다가 퇴근할 때면 고개를 돌려 “피카!!!”하고 인사를 해주는 피카츄라면요?퇴근하는 직원들에게 인사하는 대표님_피카츄.jpg상위 호환이 가능한 pm님) 전 피카츄요.인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 아 저도 피카츄로 하겠습니다. (대표님보다 피카츄)메-쓰) 음… 대표님이 양산에서 잘 살고 계시는 상태에서 연을 끊는 거라면…. 제4장. 마요 시리즈_에너지의 원천밍케터) 선빈 씨의 점심엔 항상 빠지지 않는 것이 있습니다. 한솥 마요네즈 시리즈.특별히 좋아하시는 이유가 있나요?메-쓰) 좋아해서가 아니라 싸서 먹고 있습니다.밍케터) (당황… 마요 시리즈를 좋아하는 줄 알고 질문을 준비했는데…이 인터뷰 호락호락하지 않다)그래도 가장 베스트 마요 하나만 말씀해주세요.인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 그러지 마요.메-쓰) (무시) 제가 먹어본 것들이 치킨, 치킨샐러드, 닭가슴살 샐러드 등이 있는데 다 그놈이 그놈입니다.재료가 아니라 마요 맛이에요.싼 것을 먹어야 돈을 모을 수 있으니까 싼 걸 먹는 거죠.그래야 건물을 사서 임대를 줄 수 있고 ‘난 이렇게 돈이 많은 남자다’ 이러면서 사치도 부리는 거죠.빅치킨마요를 사 먹는다던가.밍케터) 그럼 우리 점심시간때 빅 치킨마요 사 먹는 분들은 선빈 씨 기준에서 사치 하는 사람이네요? ㅋㅋㅋㅋㅋ인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 주연 씨? ㅋㅋㅋㅋㅋ상위 호환이 가능한 pm님) 선빈씨 “쟤는 건물 있나?”이러겠네요. ㅋㅋㅋㅋㅋ메-쓰) 최신게임도 풀 옵션으로 돌리고, 뭐 농담이고 돈 많으면 좋잖아요?   밍케터) 평소 과자 간식, 마요 시리즈, 콜라 등등 고칼로리를 즐겨 드시는데 날씬한 몸매 유지 비결이 무엇이죠?메-쓰) 마요가 고칼로리인가요? 먹을 때 칼로리 생각 안 하는데, 왜 살이 안 찔까...많이 안 먹어서 그런 것 아닐까요?저는 사실 먹을 만큼 먹는데 옆에서는 잘 안 먹는다 이런 평이 있긴 하더라고요.메-쓰) 그리고 저는 신체와 관련해서 그런 것을 해보고 싶긴 해요. 마사지? 교정? 교정이겠네요.요가라던가. 필라테스?이것들을 하면 나의 오랜 신체 불균형이 좀 개선되지 않을까 이런 생각이 있습니다.어멋_뒷사람을 못가렸네.jpg  제5장. 키. 손. 팔. 속눈썹… 메이비 전신_가장 자신 있는 부위밍케터) 마지막으로 가장 자신 있는 부위 알려주세요.메-쓰) 부위? 신체? 허….글쎄요.저는 막 몸이 이렇게 자신있는 스타일은 아닌데…그런데 살면서 들어본 신체에 대한 칭찬이 몇 가지가 있는데.밍케터) 몇 가지? (분명 몸이 자신 있는 스타일은 아니라 해놓고 천역덕스러우시군) 메-쓰) 네 몇가지는 누구나 있죠.우선, 키가 크다. 근데 이건 부위라고 하기엔 뭐하네요.왠지 전신을 이야기하는 것 같아서. "너는 손이 이쁘네. 손가락이 이쁘네. 손톱이 이쁘네."이런 이야기도 좀 들어 봤구요. 팔이… 이건 칭찬인지 모르겠지만, "여자들이 원하는 팔 형태네." 아니면 "속눈썹이 기네."  상위 호환이 가능한 pm님) 맞아요. 선빈씨 속눈썹 꼭 찍어야 해. 진짜 길어요. 장난 아니죠.메-쓰) 중학교 때 부터 여자애들이 “어우 속눈썹 굉장하다.” 이런 이야기를 몇 번 들었습니다. 메-쓰) 추가로 다리가 길다 정도?결론. 앵커리어 공식질문 1. 나에게 앵커리어란?뭐. 직장이죠.2. 자소설닷컴을 한 마디로 표현하자면?뭐. 우리 회사 서비스죠.#앵커리어 #팀원소개 #인터뷰 #팀원자랑 #기업문화 #조직문화

수많은 개발자 직군들개발자가 되기 위해서는 프로그래밍 언어만 배운다고 끝나는 것이 아닙니다. 자신이 배운 언어를 가지고 어떤 개발자가 될지 고민도 해야합니다. 실제로, 많은 분들이 내가 어떤 분야의 개발자가 되야 할지 고민을 많이 합니다. 그런데 이 고민에 앞서 어떤 개발자의 종류가 있고 직군이 있는지를 살펴보아야 합니다. 그래서 이번에 준비한 연재는 개발자 직군 파헤치기 시리즈입니다. 우리가 개발의 한 직군이라고 부를 수 있는 것들 중 관심이 많이 가는 직군들을 위주로 알아볼 것입니다. 일하는 분야에 대한 직군(게임 개발자)에 대한 이야기도 할 것이고, 지금 이야기할 프론트-엔드, 백-엔드처럼 개발의 영역에 대한 이야기도 할 것입니다. 다양한 관점에서 개발자의 영역들을 살펴볼 것입니다. 자, 그럼 지금부터 시작해 보죠!(※이 글은 유다시티 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 개발자에 대해서 알아보았습니다.다음 포스팅은 개발의 한 축을 담당하고 있기는 하지만 일반 개발 분와야는 다른 '게임 개발자'에 대해서 알아보도록 하겠습니다.

Kubernetes을 활용한 분산 부하 테스팅동명의 글이 Google Cloud Platform에도 있으니 여기서는 여태까지 한 삽질과 교훈에 집중한다.첫 시도 ngrinder처음에는 ngrinder로 부하 테스트 환경을 구축하려 했다. 몇 달 전에 부하 테스트를 진행할 때 잠시 쓴 적이 있었기 때문에 굳이 다른 솔루션을 찾을 이유가 없었다. 하지만 결국 후회하고 다른 솔루션으로 넘어갔는데 그 이유를 중요한 순으로 꼽자면로컬 개발환경과 실제 환경이 차이가 많다. 로컬에서는 JUnit 기반으로 개발과 디버깅이 가능하다. 하지만 이렇게 작성한 코드를 ngrinder에 넣으려 하면 외부 라이브러리가 문제가 된다. .jar 등 패키지 파일을 업로드하는 방식이 아니라 Groovy 스크립트 따로 스크립트에서 사용하는 라이브러리 따로 업로드를 해야 하는데 상당히 번거롭다.웹 UI를 통해 설정한 내용이 내장 데이터베이스에 바이너리로 들어가기 때문에 ngrinder 데이터를 관리하기가 힘들다.개발이 활발하지 않다. 주력 개발자가 Naver를 떠났다는 이야기도 있긴 한데 아무튼 커밋 히스토리를 보면 개발이 정체되어 있는 건 분명하다.설계가 진보적이지 않다. 예를 들어 현재 쓰레드의 ID를 시스템이 직접 계산해서 주입하지 않고 개발자가 주어진 코드 스니펫을 Copy & Paste 해야 하는 이유를 모르겠다.등이 있다. 이런 까닭에 좀더 간단한 솔루션을 찾아보았다.대안몇 가지 대안을 살펴보았는데Artillery는 테스트 스크립트를 yaml로 기술하기 때문에 얼핏 쉬워보이지만 이런 식의 접근 방법은 매번 실망만 안겨주었다. 조금만 테스트 시나리오가 복잡해지면 일반적인 코딩보다 설정 파일이 훨씬 짜기가 어렵고 이해하기도 어렵다.config: target: 'https://my.app.dev' phases: - duration: 60 arrivalRate: 20 defaults: headers: x-my-service-auth: '987401838271002188298567' scenarios: - flow: - get: url: "/api/resource"Gatling은 아직 분산 서비스를 지원하지 않아서 제외했다. 팀 내에 Scala 개발경험이 있는 사람이 극소수인 점도 문제였다.Locust로 정착이런 까닭에 Locust로 넘어왔다. 장점은파이썬 스크립트로 시나리오를 작성하니 내부에 개발인력이 충분하다.로컬환경과 실제 부하테스팅 환경이 동일하다. 즉, 디버깅하기 쉽다.Locust 데이터를 Dockerize하기 쉽다.한마디로 ngrinder에서 아쉬웠던 점이 모두 해결됐다. 반면 ngrinder에 비해 못한 면도 많긴 하다.통계가 세밀하지 않다.테스트 시나리오를 세밀하게 조정하기 힘들다.현재로썬 그때그때 가볍게 시나리오를 작성해서 가볍게 돌려보는 게 중요하지 세밀함은 그리 중요하지 않아서 Locust가 더 나아 보인다. 시나리오는 몰라도 통계의 경우, DataDog 같은 모니터링 시스템에서 추가로 정보를 제공받기 때문에 큰 문제도 아니긴 하다.결과물Locust on KubernetesGoogleCloudPlatform/distributed-load-testing-using-kubernetes에 있는 소소코드를 참고로 작업하면 된다. 단지 Dockerfile의 경우, 테스트 스크립트만 바뀌고 파이썬 패키지는 변경사항이 없는 경우에도 파이썬 스크립트 전체를 새로 빌드하는 문제가 있다.# Add the external tasks directory into /tasks ADD locust-tasks /locust-tasks# Install the required dependencies via pip RUN pip install -r /locust-tasks/requirements.txt 그러므로 이 부분을 살짝 고쳐주면 좋다.ADD locust-tasks/requirements.txt /locust-tasks/requirements.txtRUN pip install -r /locust-tasks/requirements.txtADD locust-tasks /locust-tasksngrinder on Kubernetesngrinder를 Kubernetes v1.4.0 위에서 돌리는데 사용한 설정은 다음과 같다. 참고로 dailyhotel/ngrinder-data는 ngrinder의 데이터만 따로 뽑아서 관리하는 도커 이미지이다.ControllerapiVersion: v1 kind: Service metadata:  name: ngrinder  labels:  app: ngrinder  tier: middle  dns: route53  annotations:  domainName: “ngrinder.test.com” spec:  ports:  # the port that this service should serve on  — name: port80  port: 80  targetPort: 80  protocol: TCP  — name: port16001  port: 16001  targetPort: 16001  protocol: TCP  — name: port12000  port: 12000  targetPort: 12000  protocol: TCP  — name: port12001  port: 12001  targetPort: 12001  protocol: TCP  — name: port12002  port: 12002  targetPort: 12002  protocol: TCP  — name: port12003  port: 12003  targetPort: 12003  protocol: TCP  — name: port12004  port: 12004  targetPort: 12004  protocol: TCP  — name: port12005  port: 12005  targetPort: 12005  protocol: TCP  — name: port12006  port: 12006  targetPort: 12006  protocol: TCP  — name: port12007  port: 12007  targetPort: 12007  protocol: TCP  — name: port12008  port: 12008  targetPort: 12008  protocol: TCP  — name: port12009  port: 12009  targetPort: 12009  protocol: TCP  selector:  app: ngrinder  tier: middle  type: LoadBalancer  — - apiVersion: extensions/v1beta1 kind: Deployment metadata:  name: ngrinder spec:  replicas: 1  template:  metadata:  labels:  app: ngrinder  tier: middle  spec:  containers:  — name: ngrinder-data  image: dailyhotel/ngrinder-data:latest  imagePullPolicy: Always  volumeMounts:  — mountPath: /opt/ngrinder-controller  name: ngrinder-data-volume  — name: ngrinder  image: ngrinder/controller:latest  resources:  requests:  cpu: 800m  ports:  — containerPort: 80  — containerPort: 16001  — containerPort: 12000  — containerPort: 12001  — containerPort: 12002  — containerPort: 12003  — containerPort: 12004  — containerPort: 12005  — containerPort: 12006  — containerPort: 12007  — containerPort: 12008  — containerPort: 12009  volumeMounts:  — mountPath: /opt/ngrinder-controller  name: ngrinder-data-volume  volumes:  — name: ngrinder-data-volume  emptyDir: {}AgentsapiVersion: extensions/v1beta1 kind: Deployment metadata:  name: ngrinder-agent spec:  replicas: 5  template:  metadata:  labels:  app: ngrinder-agent  tier: middle  spec:  containers:  — name: ngrinder-agent  image: ngrinder/agent:latest  imagePullPolicy: Always  resources:  requests:  cpu: 300m  args: [“ngrinder.test.com:80”]구 블로그 시절의 댓글#데일리 #데일리호텔 #개발 #개발자 #개발팀 #기술스택 #도입후기 #일지 #Kubernetes #인사이트

데일리의 Java 백엔드 개발자는 Docker 기반의 CodeShip Pro를 애용하는데 최근에 빌드가 급격히 느려지는 문제를 겪었다. 빌드가 느려진 원인은 다양하지만 그 중 일부는 CodeShip Pro의 캐싱 방식, 더 정확히는 도커의 캐싱 방식과 관련이 있다.CodeShip Pro는 pom.xml 또는 build.gradle 을 보고 빌드에 필요한 라이브러리를 미리 가져와서 캐싱하기를 권장한다.# We're using the official Maven 3 image from the Docker Hub (https://hub.docker.com/_/maven/). # Take a look at the available versions so you can specify the Java version you want to use. FROM maven:3 # INSTALL any further tools you need here so they are cached in the docker build WORKDIR /app # Copy the pom.xml into the image to install all dependencies COPY pom.xml ./ # Run install task so all necessary dependencies are downloaded and cached in # the Docker image. We're running through the whole process but disable # testing and make sure the command doesn't fail. RUN mvn install clean --fail-never -B -DfailIfNoTests=false # Copy the whole repository into the image COPY . ./예전에는 이 방식이 문제가 안 됐는데 최근 들어 캐시 적중률이 급격히 낮아졌다. 여러 애플리케이션이 공유하는 라이브러리를 몇 개 추가했는데 그 중 하나가 빈번히 업데이트되는 게 문제다. pom.xml 파일을 자주 수정하는데 그 말인즉 COPY pom.xml ./ 줄부터 다시 빌드해야 한다는 뜻이다. 그러므로 RUN mvn install clean --fail-never -B -DfailIfNoTests=false 을 실행하는 횟수가 많고 평균 빌드시간이 장난 아니게 늘어난다.CodeShip Pro에서 이 문제를 해결하는 방법은 비교적 간단하다. pom.xml 파일을 둘로 쪼개면 된다. 자주 수정하는 `pom.xml` 파일부터 빌드하면 빌드 시간을 종전처럼 끌어내릴 수 있다.COPY pom-not-frequently-changed.xml ./ RUN mvn -f=pom-not-frequently-changed.xml install clean --fail-never -B -DfailIfNoTests=falseCOPY pom.xml ./ RUN mvn install clean --fail-never -B -DfailIfNoTests=false하지만 CodeShip Pro가 이와 유사한 문제로 여러 번 문제가 된 터라 Travis-CI로 옮기면 어떤 장단점이 있는지 확인해보았다.장점Travis-CI는 커밋과 푸시를 한 해당 브랜치 뿐 아니라 머징할 브랜치 등에서도 빌드를 돌린다.CodeShip보다 캐싱 정책을 수립하기 쉽다.캐시 적중률 문제가 덜하므로 빌드 시간이 좀더 안정적으로 유지된다.현재 머신 사양으로는 약 1분 가량 빌드가 빠르다.빌드 과정을 한 눈에 이해하기 쉽다.Cron 빌드를 지원한다. 시간이 지나면서 의존성 문제 등으로 빌드가 깨졌을 때 조기에 조치할 수 있다.단점Travis-CI는 로컬에서 CI 환경과 동일한 빌드환경을 제공하지 않는다..travis.yml 파일을 수정하고 테스트하려면 git push 를 반복해야 한다.테스트를 돌리는 리눅스 환경과 실제 서버가 작동하는 도커 리눅스 환경이 같지 않다.돈으로 더 좋은 머신을 도입할 수 없다.빌드 환경을 이전하기는 그리 어렵지 않다. 하지만 장단점이 명확하다 보니 어느 게 꼭 좋다 말하기 힘들다. 상황에 따라 결정하는 수밖에.#데일리 #데일리호텔 #개발 #개발자 #개발도구 #도입후기 #일지 #인사이트 #조언

비트윈 팀은 지난달 비트윈에 Android Wear 앱 기능을 릴리즈했습니다. 즐거운 개발 경험이었지만, 힘들었던 점도 많았습니다. 어떤 과정을 통해서 개발하게 되었고, 내부 구조는 어떻게 되어 있는지, 신경 쓰거나 조심해야 할 점은 어떤 것들이 있는지 저희의 경험을 공유해보려고 합니다. 이 글을 통해 Android Wear 앱 제작을 고민하는 개발자나 팀이 더 나은 선택을 하는 데 도움이 되고자 합니다.Android Wear에 대해Android Wear는 최근 발표된 구글의 새 웨어러블 플랫폼입니다. 공개된 지 얼마 되지 않았음에도 불구하고 완성도 있는 디바이스들이 출시된 상태이며, 기존의 웨어러블 기기보다 기능과 가격이 매력 있다는 평가를 받고 있습니다. 또한, 2014 Google I/O에서 크게 소개되고 시계를 참가자들에게 나눠주는 등, 구글에서 강하게 밀어주고 있기 때문에 상당히 기대되는 플랫폼입니다.Android Wear의 알림 기능은 연결된 mobile1 기기와 연동됩니다. 예를 들어 메시지를 받았을 때 mobile과 wear에서 모두 알림을 받아볼 수 있고, Google Now와 연동하여 교통, 날씨 등 상황에 맞는 알림을 제공합니다.또, 여러 가지 앱들의 다양한 기능을 음성으로 제어하도록 하여 사용자에게 기존의 시계와는 완전히 다른 경험을 주고 있습니다.한국에서는 Google Play Store의 기기 섹션에서 구매가 가능합니다.Android Wear 개발하기Android Wear는 Android 플랫폼을 거의 그대로 사용하기 때문에, Android 개발 경험이 있는 개발자라면 아주 쉽게 개발을 시작할 수 있습니다. 비트윈에서는 구글의 80:20 프로젝트를 패러디한 100+20 프로젝트를 통해 개발을 진행하게 되었습니다. (하던 일을 다 해내면서 시간을 내어 진행한다는 의미로 100+20 프로젝트입니다. 하지만 가끔은 '20' 부분에 너무 몰입하여 0+20이 되기도 한다는 게 함정입니다...)Activity, Service 등 Android의 기본 component들을 모두 그대로 사용 가능하며, 손목에 찰 수 있는 크기의 화면에서 유용하게 사용할 수 있는 WearableListView, GridViewPager 같은 새 widget들이 추가되었습니다. 구글 개발자 사이트의 wearable training 섹션에서 자세한 안내를 볼 수 있습니다.비트윈의 아이디어비트윈 Android Wear 기능의 컨셉은, 항상 몸에 착용하는 Wear의 특징을 살려, '커플이 떨어져 있더라도, 항상 함께 있는 느낌을 주기' 였습니다. 그래서 아래와 같은 기능들이 기획되었습니다.Feel His/Her Heart (그대의 심장박동 느끼기): 상대방의 심장박동을 진동으로 재현해주기Where He/She Is (그/그녀는 어느 방향에 있을까?): 상대방의 위치를 나침반과 같은 형태로 보여주기 (안심하세요. 여러분. 방향만 알려주고 정확한 위치는 알려주지 않습니다!)Feel Memories (메모리박스): 언제든 추억을 떠올릴 수 있도록 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현하지만 이 아이디어들은 하루 만에 망하게 됩니다.메인 아이디어였던 심장박동 느끼기는 사용자가 요청하면 상대방의 시계에서 심장박동이 측정되어 사용자에게 상대방의 심장박동을 진동으로 재현해주는 멋진 기능이었습니다. 하지만 이 아이디어를 낼 때 심박센서가 탑재된 Android Wear 기기가 없었던 게 함정이었습니다.다음날 Android Wear Bootcamp에 참가하여 심박센서가 작동하는 삼성 Gear Live 기기를 사용해 볼 수 있었습니다. 결과는 충격이었습니다. 생각과는 달리 심박박동 측정 결과가 나오는데 10~20초가 걸리고, 그나마도 측정되는 동안은 올바른 위치에 시계를 차고 가만히 있어야 했습니다. 결국, 이러한 제약 때문에 사용자들이 실제로 유용하게 사용할 수 있는 기능이 될 수 없었습니다.그래서 계획을 수정하여 현실적으로 구현 가능한 기능들을 먼저 만들어 보기로 했습니다.목소리로 답변하기: 상대방에게 온 메시지에 Android Wear Framework에서 제공하는 음성인식을 이용하여 목소리를 텍스트로 바꾸어서 답장하기이모티콘 답변하기: 이모티콘을 사용자가 선택하여 이모티콘으로 답장하기비트윈 메모리박스: 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현처음의 원대한 계획에서 뭔가 많이 변경된 것 같지만, 기분 탓일 겁니다.내부 구현비트윈 Android Wear 앱은 크게 두 가지 기능을 가지고 있습니다. 하나는 상대방에게 메시지를 받았을 때, 메시지 내용을 확인하고 여러 가지 형태로 답장할 수 있는 Notification 기능이고, 다른 하나는 Wear에서 원래 Application의 일부 기능을 시작 메뉴를 통하거나 목소리로 실행시킬 수 있게 해주는 Micro App입니다. 해당 기능들의 스크린샷과 함께 내부 구조를 설명하겠습니다.우선 Notification 부분입니다. 앱 개발사에서 아무 작업도 하지 않더라도, 기본적으로 Android Wear Framework이 스크린샷 윗줄 첫 번째, 네 번째 화면과 같이 예쁜 알림화면과 Open on phone 버튼을 만들어 줍니다. 여기에 추가적인 기능을 붙이기 위하여 WearableExtender를 이용하여 목소리로 답장하기, 이모티콘 보내기 버튼을 덧붙였습니다.비트윈 Android Wear 스크린샷 - Notification둘째로는 Micro App 부분입니다. 여기에는 이모티콘 전송과 메모리박스를 넣었습니다. 이 부분은 일반적인 Android 앱을 만들듯이 작업할 수 있습니다비트윈 Android Wear 스크린샷 - Micro App화면을 보면 무척 단순해 보이지만 내부 구조는 간단하지가 않습니다. 연결된 화면들을 만들어내는 코드가 한곳에 모여있지 않고, 각기 다른 곳에 있는 코드들을 연결하여야 하기 때문입니다. Notification 하나를 만들 때에 Framework에서 만들어주는 1, 4번째 화면, Notification에 WearableExtender를 이용하여 덧붙이는 2, 3번째 화면, 그리고 다시 Framework에서 만들어주는 목소리로 답장하기 화면, 그리고 Wear 쪽의 Micro App을 통해 구동되는 이모티콘 선택 화면과 같이 여러 군데에 나누어 존재하는 코드가 연결됩니다.하나의 앱처럼 느껴지는 화면이지만 각각 다른 곳에 코드가 쓰여있습니다.그러면 이번에는 각 화면이 어떻게 연결되는지 알아보겠습니다.사용자가 상대방으로부터 받은 메시지를 Android Wear의 Notification으로 확인하고, 답장으로 이모티콘을 보내고자 하는 상황을 가정해 봅시다. 사용자가 Send Emoticon 버튼을 눌렀을 때 이모티콘 선택화면을 보여주고 싶은데, 이 행동에 대한 pending intent를 wear 쪽의 micro app이 아닌, mobile 쪽에서 받게 되어 있습니다. 이 때문에 아래의 표와 같이 mobile 쪽에서 pending intent를 받은 뒤 다시 wear 쪽으로 이모티콘 선택 화면을 보여주라는 메시지를 전송해줘야 합니다.이모티콘 전송 과정이번에는 메모리박스를 보겠습니다. 메모리박스도 단순한 화면이지만 mobile 쪽과 통신하여 내용을 불러와야 하므로 생각보다 해야 하는 일이 많습니다. Android Wear Message API와 Data API를 이용하여 데이터를 주고받아 사진을 화면에 보여줍니다.메모리박스를 보여주는 과정개발 시 신경 써야 하는 점개발하면서 주의 깊게 신경 써야 하는 점들이 있습니다.첫 번째로 코드 퀄리티입니다.Android Wear는 아직 성숙하지 않은 플랫폼이기 때문에 많은 사람이 받아들인 정형화된 패턴이 없습니다. 앞서 살펴보았듯이, 간단한 기능을 구현하려고 해도 상당히 복잡한 구조를 가진 앱을 만들게 되기에, 코드 퀄리티를 높게 유지하기 어려웠습니다비트윈 팀에서는 EventBus를 활용하여 코드를 깔끔하게 유지하려고 노력하였습니다. 이러한 문제를 해결할 수 있는 Guava의 Concurrent 패키지나, RxJava 등의 도구들이 있으니 익숙한 도구를 선택하여 진행하는 것을 추천합니다. 또한, 구글의 Android Wear 코드랩 튜토리얼의 내용이 매우 좋으니, 한번 처음부터 수행해 보면 좋은 코드를 만들 수 있는 아이디어가 많이 나올 것입니다.두 번째로는 원형 디바이스 지원 및 에러 처리입니다.처음부터 원형 디바이스를 신경 쓰지 않으면 마무리 작업 시 상당한 고통을 받게 됩니다. 원형 디바이스에 대한 대응법은 Android 개발자 트레이닝 사이트의 wearable layout 섹션에 자세히 나와 있습니다. 현재는 원형 디바이스를 처리하는 프레임웍에 약간 버그가 있지만, 곧 수정될 것으로 생각합니다.사용자 입력이 있을 때, 그리고 에러가 났을 때 적절하게 처리해주는 것은 제품의 완성도에 있어 중요한 부분입니다. Android Wear Framework에서 제공하는 ConfirmationActivity등을 활용하여 처리하면 됩니다.마지막으로 패키징입니다.자동 설치 패키징은 비트윈 팀에서도 가장 고생했던 부분입니다. Android Wear는 본체 앱을 설치하면 자동으로 함께 설치되는데, 앱이 정상작동하기 위해서는 몇 가지 까다로운 조건이 있습니다.build.gradle 의 applicationId 를 wear와 mobile 양쪽 모두 똑같이 맞춰야 합니다.Wear app의 AndroidManifest에 새롭게 선언한 permission이 있다면 mobile 쪽에도 포함해 주어야 합니다.기본적으로, 똑같은 key로 서명합니다. 다른 key로 sign 하는 경우는 문서를 참고해서 신경 써서 합니다.위 항목들은 아주 중요한 내용이지만 아직 문서화가 완벽하지 않으니 주의 깊게 진행해야 합니다.후기개발 과정에서 여러 가지 어려움이 있었지만, 무척 즐거웠던 프로젝트였습니다!우선 새로운 플랫폼에서 새로운 제품의 아이디어를 내고 만들어내는 과정이 많은 영감과 즐거움을 주었습니다.두 번째로는 Android Wear를 포함한 버전 출시 이후 구글플레이의 Android Wear 섹션 및 추천 앱 섹션에 올라가게 되어 홍보 효과도 얻을 수 있었습니다. 또한, 구글의 신기술을 적극적으로 사용하고자 하는 팀에게는 구글 쪽에서도 많은 지원을 해주기 때문에 도움도 많이 받았습니다.세 번째로는 기존의 Android 개발과 비슷하여 접근하기 쉬우면서도, 원하는 것을 구현하려면 상당히 도전적이어서 재미있었습니다.다만 조심해야 할 점은, 구글에서 적극적으로 밀고 있는 프로젝트라고 해서 다 성공하는 것은 아니라는 점입니다. 얼마만큼의 시간과 자원을 투자할지는 신중하게 생각하면 좋겠습니다.정리Android Wear는 새로운 기술과 플랫폼에 관심이 많은 개발자, 혹은 팀이라면 시간을 투자해서 해볼 만한 재미있는 프로젝트입니다. 하지만 완성도 있는 좋은 제품을 만들기 위해서는 생각보다 할 일이 많으니 이를 신중하게 고려하여 결정해야 합니다.끝으로 2014 GDG Korea Android Conference에서 같은 주제로 발표하였던 슬라이드를 첨부합니다.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/a1415af04644013234cf7a3f7c519e69?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">구글의 튜토리얼 등에서 지칭하는 것과 마찬가지로, 이 글에서도 Android Wear와 연결된 휴대폰을 mobile이라 하겠습니다.↩

 안녕하세요. 크몽개발팀 입니다.오늘 포스트 주제는 Android Studio JCenter 이용하기입니다.JCenter????  JCenter에 대해 처음 들으시는분들도 있을거같은데요.JCenter는 라이브러리들이 모여있는 저장소라고 보시면 되겠습니다.그렇다면 JCenter를 이용하여 무엇을 할까요?바로 외부 라이브러리들을 가져와서 프로젝트안에 Import 할려고 합니다. JCenter 사이트 링크 : https://bintray.com/bintray/jcenterJCenter 페이지에 접속하시면 위와 같은 페이지를 볼 수 있는데요.여기서 사용하고 싶은 라이브러리를 검색해보겠습니다.제가 검색한 라이브러리는 ImageLoder 라이브러인 'Glide'를 검색했습니다.빨간색으로 표시되있는게 제가 찾던 라이브러리 입니다.검색한 라이브러리를 클릭하면 위와 같이 상세페이지를 볼 수 있는데요.라이브러리 Github 주소 와 버젼에 대한 정보를 확인할 수 있습니다.그럼 이제 검색한 라이브러리를  Android Studio Gradle에 Import 하겠습니다. Android Studio에서 프로젝트를 생성하게 되면 위와 같이 3개의 그래들 파일을 볼 수 있는데요.자주 사용할 그래들 파일은 app폴더에 있는 그래들 파일입니다.그래들 파일을 열어보면 낯익은 코드들이 보이는데요.ADT에서는 매니페스트에서 버젼관리를 햇었는데 Studio에서는 그래들로 빠진거같습니다.그리고 빨간표시를 해둔곳이 바로 JCenter에서 검색한 라이브러리를 Import 하시면 되겠습니다.  위에 JCenter에서 찾은 라이브러리명을 입력하고 뒤에 버젼번호도 같이 입력합니다.그리고 Sync 버튼을 눌러주면 라이브러리가 Import 됩니다. External Libraries를 확인해보시면 라이브러리가 추가된걸 확인할 수 있습니다.---------------------------------------------------------------------------------------이렇게 JCenter를 이용하여 간단하게 라이브러리들을 Import를 할 수 있습니다.그리고 그래들 과 JCenter를 이용하여 라이브러리를 적용할때 가장 좋은점은'com.github.bumptech.glide:glide:3.+' 이런식으로 버젼에대한 값을 주면라이브러리 상위버젼이 나올경우 자동으로 최상위 버젼으로 라이브러리를 Import 해준다는 점입니다.이로써 라이브러리 버젼관리도 많이 편해질거 같습니다.이것으로 Android Studio JCenter 이용하기 포스트를 마치겠습니다.#크몽 #개발팀 #인턴 #인턴생활 #인사이트