안녕하세요. 언제 어디서나 함께하는 코딩 교실 엘리스입니다 :)아이디어만 좋다면 뭐든 실현해볼 수 있는 시대! 지금은 '프로그래밍'이라는 강력한 무기를 통해 원하는 세계를 실현할 수 있는 잠재적 가능성이 폭발적인 때입니다. 그리고 그 기회는 비단 '개발자'라는 특정 직업에 국한하지 않더라도 각계 분야에 펼쳐져 있는데요. 이미 마케터, 기획자, 디자이너, 콘텐츠 창작자, 금융업계 종사자, 지리학자, 연구원 등 다양한 분야의 많은 사람들이 프로그래밍을 통해 각자의 영역과 세계 곳곳을 새로운 곳으로 만들고 있습니다.높은 급여와 삶의 질을 보장하고 나의 꿈을 펼칠 수 있는 탁월한 수단인 프로그래밍.프로그래밍을 업으로 삼고 있는 사람들의 시작은 어땠을까요?이 글에서는 소프트웨어 엔지니어가 되고자 이제 막 마음먹은 분들을 위해 프로그래머가 되기 위한 다섯 가지 짚고 넘어가면 좋을 팁들을 알려드릴게요.STEP 1. 개발 친화적인 환경 찾아가기서당개 삼 년이면 풍월을 읊는다컴퓨터 공학 전공자와 비전공자가 가지게 되는 가장 큰 차이는 무엇일까요? 개발에 대한 이론 지식? 개발 능력?물론 모든 게 상대적인 것이겠지만 일반적으로 한 가지 큰 차이가 있다면 바로 '환경'이라고 할 수 있을 듯합니다. 내 주변에 개발과 관련된 자원이 얼마나 풍부한가 하는 점입니다.전공자가 개발을 시작하고자 마음을 먹으면 주위에서 좋은 리소스를 쉽게 찾을 수 있습니다. 한편 비전공자는 개발 공부를 시작하려고 할 때 레퍼런스로 삼을만한 좋은 예가 없으니 망망대해에 홀로 떠있는 기분이 들 수밖에 없겠죠! 그렇다고 해서 반드시 컴퓨터 공학 전공에서부터 다시 시작하거나 고액의 학원에 다닐 필요는 없습니다. 먼저 개발과 관련된 인적, 물적 자원이 풍부한 곳으로 적극적으로 다가가보세요. 작은 환경의 변화가 큰 변화의 시작점이 될 수 있습니다.엘리스가 추천하는 방법!온라인 커뮤니티 활동하기 : 코딩과 관련된 페이스북 그룹에 가입하여 많은 정보를 접하고 질문도 하면서 활동해보세요. 나와 비슷한 상황인 사람을 만나 서로 도움을 주고받을 수도 있고, 내 롤모델이 될만한 훌륭한 개발자를 만나 공부의 동력이 될지도요!개발 동아리, 스터디 등에 참여하기★ 엘리스 코딩 클래스 활용하기 : PC로도, 모바일 앱으로도 언제 어디서든 프로그래밍을 위한 환경에 접속하세요! 엘리스에 로그인하는 것만으로 공부하기 위한 모든 리소스를 얻을 수 있을 뿐만 아니라 과목별 채팅방을 통해서 함께 공부하고 있는 수강생들, 과목 튜터와의 활발한 대화에 참여할 수 있습니다. STEP 2. 강력한 동기와 조력자 만들기하늘은 스스로 돕는 자를 돕는다컴퓨터 공학 전공자라고 하면 모두 다 개발을 잘할까요? 적어도 아주 조금은 더 잘할까요? 대답은 NO!아무리 많은 이론을 배웠다고 해도 직접 개발을 하지 않는다면 아무런 소용이 없겠지요. 이해도가 다르기 때문에 배움의 속도는 조금 다를 수도 있겠지만 이런 차이보다는 개인의 학습 의지와 동기가 얼마나 분명하냐가 더 중요합니다.막연하게 '개발자'라는 너무 먼 목표만 보고 달리는 것보다는 보다 가까이에 있고 달성하기 쉬운 분명한 목표를 단계별로 설정해보세요. 그리고 '즐거움'을 느낄 수 있는 수단을 찾아 목표 달성을 위한 집중력을 높이세요. 동시에 내가 어려움에 처하거나 헤매고 있을 때 도와줄 조력자가 있다면 금상첨화!Photo by Mimi Thian on Unsplash엘리스가 추천하는 방법!동기 부여를 위한 작은 목표 설정 : 지식 습득 및 학습과 관련된 목표로 그룹 스터디 참여, 부족한 부분의 프로그래밍 강의 완강, 책 한 권 떼기 등이 있을 수 있고, 더 적극적인 형태의 개발 경험을 위해 공모전, 경진 대회 등 기간과 보상이 정해져 있는 대외 활동 참가 및 수상도 좋은 목표가 될 수 있을 거예요.★ 엘리스 코딩 튜터 활용하기 : 엘리스에는 학습을 도와주는 튜터가 있습니다. 엘리스 튜터는 답을 알려주는 사람이 아니라 답을 찾는 법을 알려주는 길잡이입니다. 공부하다가 막힐 때, 길을 잃은 것 같을 때 엘리스 튜터를 멘토로 삼아 보세요! 구독 및 트랙 이용 시 담당 튜터가 배정되어 개인 채팅방을 통해 1:1 튜터링을 받을 수 있고, 클래스 수강 시 단체 채팅방을 통해 언제든 질문할 수 있습니다.STEP 3. 원하는 개발 분야 탐색해보기  콩 심은 데 콩 나고 팥 심은 데 팥 난다개발에는 아주 숱~한 다양한 분야가 있습니다. 그리고 그 분야에 따라 특성도, 익혀야 하는 언어와 기술도 천차만별인데요. 아래 몇 개의 개발 분야와 사용 언어 및 기술에 대해서 적었으니 참고해보세요. 그리고 이보다 더 다양한 개발의 세계를 탐색해보면서 흥미가 가는 분야가 있다면 구체적으로 검색하고 공부를 시작할 계획을 세워보세요.Photo by Victoriano Izquierdo on Unsplash잘 모르겠다 or 코알못이다파이썬은 분야를 막론하고 많은 분야에서 사용되며 익히기에 쉬워 처음 코딩을 시작하는 입문자에게 가장 적합한 언어 중 하나입니다. 개발 언어부터 접해보고 싶다면 파이썬 언어 학습에서 시작해보세요!웹 개발 '콩 심은 데 콩 나고~'라는 속담을 인용했지만, 사실 다양한 개발 영역의 많은 지식들이 서로 겹치는 부분도 있고, 어느 한 분야를 잘할 수 있을 때 다른 분야로 전향하거나 옮겨가는 일은 보다 수월할 수 있습니다. 개발의 시작을 보다 쉽게 하고 싶다면 웹 개발부터 접근해보세요. 공부할 수 있는 자원이 풍부하고 추후 다른 개발 분야로의 전향도 가능하기 때문이에요.프론트엔드프론트엔드 개발은 주로 웹 환경에서 사용자와 맞닿는 가시적인 부분을 개발하는 영역입니다. 사용자가 코드를 작성하지 않고도 컴퓨터에게 명령을 내리는 등의 의사소통을 그래픽적으로 쉽게 할 수 있도록 가시적으로 만들어주는 것이 바로 프론트엔드 개발자의 역할이라고 할 수 있는데요. 예를 들어 엘리스에 로그인하고 싶을 때 '로그인 버튼을 클릭'하여 쉽게 로그인할 수 있는 인터페이스도 프론트엔드에 해당합니다. * 익혀야 하는 기본기 : HTML, CSS, JavaScript* 좀 더 나아가서 : JavaScript의 프레임 워크인 React.js 또는 Vue.js 또는 Angular.js 백엔드/서버백엔드 개발은 웹 환경에서 보통 사용자에게는 보이지 않는 서버(컴퓨터) 단의 개발을 의미하며, 사용자가 웹 상에서 활동함으로 인해 쌓이는 데이터가 모이는 DB(Data Base)를 다루는 영역을 개발합니다.* 익혀야 하는 기본기데이터베이스에 대한 지식 : MariaDB, PostgreSQL, MongoDB 등. 서버 쪽의 언어- 금융, 제약 등 전통적인 대기업 : Java의 프레임 워크인 Spring을 많이 사용- 과거 많이 쓰이던 기술 : Php(학습 속도와 개발 속도가 빠르며 무료!)를 많이 사용- 요즘 떠오르는 기술 : Python 기반 프레임 워크인 Django 또는 Flask. JavaScript의 프레임 워크인 Node.js* 좀 더 나아가서 : 클라우드 컴퓨팅 기술 Amazon AWS 또는 Azure에 대한 지식데이터 사이언스 - 데이터 분석가21세기에 가장 각광받는 직업 중 하나로 떠오른 '데이터 사이언티스트'에 대해서 모두 다 한 번쯤은 들어보셨을 거예요. 데이터 사이언스 분야에도 아주 복잡하고 다양한 영역들이 존재하는데요. 통상 데이터 사이언스라고 하면 수학 및 통계에 대한 지식, 컴퓨터 공학에 대한 지식, 인공지능 및 머신러닝과 관련된 기술을 사용하게 됩니다. 너무 많아 보이나요? 아래에는 데이터 사이언스의 많은 영역 중에서도 '데이터 분석가'로서 꼭 알아야 하는 내용을 적었습니다.* 익혀야 하는 기본기수학적 지식 : 통계, 선형대수학분석을 위한 언어 : Python, R* 좀 더 나아가서 : 머신러닝 기술임베디드 개발계산기, 에어컨, 자동차 등의 기계가 일정 기능을 컴퓨터처럼 수행할 수 있도록 기계 내부의 하드웨어 시스템을 구축하는 것이 임베디드 개발입니다. 사물 인터넷(IoT, Internet of Things)이나 하드웨어 부품과 관련된 분야에 관심이 간다면 임베디드 개발에 대해서 좀 더 알아보세요!* 익혀야 하는 기본기임베디드 개발 언어- 가장 많이 사용하는 언어 : C언어 - 국내 전통적인 대기업 : Java- 수요가 많은 언어 : Python (임베디드 분야에서도 빠지지 않고 자주 사용하는 언어! 국내 채용 사이트에서 임베디드 관련 개발 스택으로 많이 요구.)* 좀 더 나아가서 : 무선 통신 기술에 대한 지식*(공통) 개발자라면 익히고 있어야 할 기본기 : Git을 사용한 버전 관리 방법엘리스가 추천하는 실습 기반 과목HTML/CSS | JavaScript | 모바일 웹 코딩Git과 Git 버전 관리 (6월 오픈 예정)Python 기초 I | Python 기초 IIC 언어 | C++Java 기초 및 심화인공지능/머신러닝 기초 | 프로그래밍 수학데이터 분석 | Numpy, Pandas | 크롤링 | Kaggle 문제R 기초 |  R 패키지 | R 데이터 분석STEP 4. 실습, 프로젝트 기반으로 공부하고 개발 경험 쌓기구슬이 서 말이어도 꿰어야 보배다책을 사고 인강을 결제해도 직접 만들어보면서 익히지 않으면 절대 내 것이 될 수 없는 것이 또 개발!처음 언어를 익히는 단계에서부터 실습 기반으로 직접 코딩하고 그 결과를 확인해보면서 학습하는 것이 중요해요! 필요한 공부를 실습 단위로 쪼개어 직접 구현해보면서 익히고, 좀 더 나아가서는 프로젝트 단위로 구현하면서 실전 기술을 습득해보세요. 또한 실무에서는 혼자 개발하는 것이 아니라 뭐든 '협업'해야 하기 때문에 혼자 하는 프로젝트 외에도 여러 사람들과 함께하는 그룹 프로젝트의 경험이 큰 도움이 될 거예요. 자기소개서, 포트폴리오, 면접 시에도 어떤 프로젝트에서 내가 맡은 부분은 어느 부분이었고 어떻게 주도적으로 이끌었는지가 관건이 될 수 있습니다.엘리스가 추천하는 방법!★ 온라인 코딩 실습으로 기본기 다지기 : 엘리스는 별도의 코딩 환경 세팅 없이 온라인에서 바로 코딩 문제를 풀고 내가 짠 코드의 결과를 확인할 수 있어서 실습 기반으로 학습하기에 탁월한 플랫폼입니다. :) KAIST, SKT, 삼성 SDS 등에서도 활용하는 검증된 플랫폼에서 코딩 실습으로 기본기를 다지세요!프로젝트 단위로 혼자서 만들어보기 : 프로그래밍 언어의 기본에 익숙해졌다면, 직접 A to Z를 구현하는 작은 프로젝트를 통해 실제 필요한 기술이 뭔지 파악해가며 실전 기술을 익혀보세요. 그룹 프로젝트에 참여해서 협업 경험을 통해 익히기 : 취업을 위해서 중요한 것 중 하나인 '협업'능력! 그룹 프로젝트에 참여하여 비단 개발 실력뿐만 아니라 실무에 필요한 다양한 역량 또한 길러보세요.STEP 5. 포트폴리오, 시험 준비하고 개발 직군에 지원하기시작이 반, 그 이상이다!아시겠지만 개발자가 되면 끝인 그런 일은 없겠죠. (어떤 직무에서도 마찬가지일 거예요.) 끊임없는 공부, 새로운 기술 연마, 리팩토링, 문서화, 코딩 공부 코딩 공부!그러니 완벽에서 시작해야 한다는 생각은 버리고 지금까지 최선을 다해온 결과물을 가지고서 개발 직군에 지원하세요. 실제 개발자로 일하게 되면 그 속에서 배우고 성장할 수 있는 자원이 훨씬 더 많아집니다!'자리가 사람을 만든다'라는 말이 괜한 말이 아니니, 더 큰 성장과 가능성이 있는 곳으로 가기 위한 준비와 지원을 주저 없이 해보시길 바라요!Photo by Green Chameleon on Unsplash엘리스가 추천하는 방법!나를 잘 보여줄 포트폴리오 만들기 : (사용한 언어 / 프레임 워크 / 앞의 것을 적용하여 프로젝트에서 내가 한 역할) 별로 정리해두고 내가 커밋한 코드와 함께 보여주기.   블로그 쓰기 : 거창한 것이 아니어도 좋으니 공부하면서 느꼈던 것, 새로 알게 된 지식들, 프로젝트하면서 고민했던 것들을 블로그로 정리해보세요. 내가 구현한 것들을 이미지를 통해서 가시적으로 보여줄 수 있다면 금상첨화!★ 엘리스에서 알고리즘 시험 준비하기 : 이미 많은 수강생 분들이 엘리스 알고리즘 과목을 통해서 코드를 발전시키고 알고리즘 시험 및 취업에 성공하고 있습니다. :) 대기업 입사를 준비하시는 분이라면 엘리스 알고리즘 과목들을 꼭 수강해보세요.이다음의 6번째 스텝은 무엇이 될까요? 아마도 1~5 스텝을 계속 반복해나가면서 익숙해지고, 다른 역할로 각각의 스텝에 참여하게 되는 일이 아닐까요.엘리스는 누구나 프로그래밍을 통해 원하는 일을 할 수 있도록 좋은 강의 콘텐츠와 서비스, 플랫폼으로 여러분의 다섯 스텝에 함께하고자 합니다. :) 막막한 초심자 분들에게 앞으로의 방향성을 그려보는 데에 조금이라도 도움이 되길 바라며 글을 발행합니다.그럼 엘리스에서 만나요! >> 엘리스 아카데미 바로가기* 이밖에 조언, 첨언, 질문 등을 댓글로 남겨주시면 이 글의 독자분들에게 큰 도움이 됩니다.

pluu 04 JUL 2018저는 야놀자 CX서비스실의 Android 파트에서 레이아웃 깎기와 Kotlin과 새로운 Android 기술을 전파하는 노현석입니다. 야놀자에 합류하고서 경험한 가장 독특한 케이스에 대해서 이야기해 보려고 합니다.시작은 물음표부터언제부터인가 야놀자앱을 설치하거나 업데이트하면 앱이 자동으로 실행된다는 리뷰가 들어오기 시작했습니다.네?! 그게 무슨 말이에요?안드로이드 개발을 시작한 이래로 처음 들어보는 내용이라, 원인도 정확한 해결책도 떠오르지 않는 그런 리뷰였습니다. 그래서 자연스럽게 브라우저를 켜서 구글에 검색을 먼저 해봤습니다. Android, Auto Start, Install 등 다양한 검색 결과로 일정한 패턴의 내용을 확인할 수 있습니다.  Intent Action 관련 내용android.intent.action.PACKAGE_ADDEDandroid.intent.action.PACKAGE_CHANGEDetc.Broadcast Receiveretc.일반적으로 안드로이드 앱이 설치 및 업데이트될 때 발생하는 이벤트(이하 Broadcast)를 받는 방법에 대한 설명이 많습니다. Broadcast는 배터리 변화, 전화 여부, 와이파이 등 시스템의 상태 변화를 감지하거나 서비스 내부적에서 이벤트를 전달하기 위해 사용합니다. ???? 실질적인 해결책은 되지 않지만, 범위를 좁혀서 찾아볼 포인트로 Intent 의PACKAGE관련 액션을 포커스로 잡았습니다. 하지만, 야놀자앱에서는 마케팅 성과 측정을 위해com.android.vending.INSTALL_REFERRER를 광고 트래킹 SDK에서 사용하는 것 이외에는 별도의 작업을 하지는 않습니다. 그러나, 이를 알 리가 없는 사용자는야놀자 앱이 일으키는 문제라고 인지하기 쉽습니다.  일차적으로, 어느 경로를 통해서인지는 모르지만 누군가가 야놀자 앱을 실행하는 것이라고 생각했습니다.야놀자 앱 사용자의 기기에 설치된 모든 앱 리스트를 받아올 수도 있고, 리퍼럴에 따른 앱 실행경로를 모두 수집할 수도 있지만, 단순히 버그를 찾기 위해 사용자의 동의 없이 정보를 수집할 수는 없기 때문에 장기전으로 돌입하게 되었습니다. 하지만 동일한 리뷰는 계속되었고 여전히 뚜렷한 해결책이 없는 채로 시간이 흘러갔습니다.  저 재현되는데요증상이 나타나지만 재현은 되지 않고, 재현 경로를 단기간에 파악하기는 어려운 과제였습니다. 한두 명에 불과하던 제보가 시간이 지날수록 Android 파트의 목을 조르듯이 점점 유입되는 횟수가 늘어만 갔습니다. 그런데 어느 날, 다른 팀의 분께서저 재현되는데요라는 한 줄기의 빛과 같은 언급을 해주셨습니다.믿고 싶지 않은 일이 현실이 되었다네? 그게 … 정말로 일어났습니다.이제부터가진짜시작역시버그는재현이되어야제대로잡을수있겠죠! 저에게는재현되는 단말이 있어요!Android에서 디버깅을 할 수 있는 다양한 수단이 있습니다. 이번 사례의 경우는Log혹은Dump를 확인해보는 선택지가 있습니다.Log민감한 정보라고 판단되는 부분은 모자이크했습니다.앱 설치 후 광고 SDK가 수집하는 것으로 보이는 Log에는 다양한 항목들이 나열되는 것을 볼 수 있습니다. 이때 설치한 앱의 정보가 SDK를 통해 특정 API로 전송되는 것도 확인할 수 있습니다. 하지만 Log는 Log일 뿐입니다.  Dumpsys이렇게 Log만으로 추적이 어려울 때, 추가적으로 시스템의 상태를 얻어내 디버깅 할 수 있는 방법이 있는데 바로dumpsys입니다. dumpsys는 Android 단말에서 실행되며 시스템 서비스에 대한 다양한 정보를 제공하는 도구입니다. ADB(Android Debug Bridge)를 사용하여 dumpsys를 호출 시 해당 단말에서 실행 중인 모든 시스템 서비스에 대한 정보를 가져올 수 있습니다. 간단하게 말하면 배터리의 잔량, 메모리 소비량, 네트워크 통신 상태 등을 명령어로 확인할 수 있습니다. dumpsys의 기능에 대해서는 방대한 설명이 필요하므로, 자세한 내용은 아래 링크로 대체합니다.  Android Developers ~ dumpsyshttps://android.googlesource.com/platform/frameworks/native/+/master/cmds/dumpsys/dumpsys.cppActivity DumpDumpsys 에서 좀 더 Activity 와 관련된 정보를 얻기 위해서는 아래의 명령어를 적용해볼 수 있습니다.// Activity Log Dump adb shell dumpsys activity activities 결과를 확인해봅니다. 아래와 같은 Activity 의 활동 이력을 얻을 수 있습니다.Activity Dump에 나타난mCallingPackage값으로 야놀자 앱을 시작시킨 앱의 패키지를 확인할 수 있습니다. 해당 패키지를 실제 Play Store에서 확인해본 결과, 사진 보정 필터앱으로 유명한카메라 앱중 하나였습니다.???? 야놀자와는 전혀 연관성이 없는 앱인데, 호출하고 있네요… ????Process ID// 애플리케이션의 Process ID 취득 adb shell ps Activity Dump에서 확인한mCallingUid는u0a423였는데, 이는 Activity를 호출한 uid 값을 가리킵니다. 실제로 Process 가 호출되는 Application ID도 카메라 앱에서 호출한 ID 정보와 일치합니다.대상 앱 자료 분석단순하게는 APK 를 분석하여 추측하는 방법이 있습니다. Android Studio 에서 제공되는Analyze APK기능을 이용하여 해당 앱에서 사용되는 서비스의 정보를 파악할 수 있습니다. 이 방법을 이용하여 문제의 앱이 사용하는 광고 SDK 서비스에서 패키지 설치/제거 관련 Broadcast Receiver를 수집하는 것을 확인 할 수 있습니다.패키지 관련 Broadcast인android.intent.action.PACKAGE_ADDED, android.intent.action.PACKAGE_REMOVED를 앱이 사용하는 것은 잘못된 것이 아닙니다. 예를 들어 런처 앱의 경우 단말기 내부의 앱 정보가 변경되었다는 이벤트를 이용하여 화면 렌더링 및 동작을 변경하는 처리를 할 수 있습니다 해당 광고 SDK의 경우에는 앱을 설치 및 실행하는 것으로 사용자에게 포인트 및 여러 혜택을 제공할 것이라고 예상할 수 있습니다.개인적인 의견으로는 사용자의 액션과 상관없이 동작하는 부분에 대해서는 분명히 Android 의 개선도 필요하다고 생각됩니다. 이런 정상 동작과 어뷰징은 아슬아슬한 경계에 있지만, 자칫 어뷰징으로 이어지는 경우 서비스의 품질이 떨어지게 되면서 사용자와 개발사 모두에게 좋지 않은 경험을 줄 뿐입니다.설마 이것도 되려나?동일 패키지명이번 포스팅을 작성하게 된 카메라 앱과 야놀자 서비스 사이에 특별한 관계가 없다면, 왜 이런 현상이 발생하는지 고민해봤습니다. SDK도 연결하지 않았다면, 앱을 추적할 수 있는 유일한 키는패키지명이지 않을까라는 생각으로 패키지명만 야놀자 앱과 동일한 샘플 앱으로 테스트해봤습니다.동일 재현 성공!!그럼… 해결… 끝?많은 사람들에게 이름이 널리 알려진 여러 서비스에서조차 이번 포스팅에서 다룬 내용과 같은 현상이 발생하고 있습니다. 발생 유무에 따른 차이점이나 현상의 인과 관계를 명확히 판단하기엔 아직 정보가 많이 부족합니다. 그리고 이번 분석에서 발견한 문제의 앱을 비롯하여 또 다른 제2, 제3의 앱들이 등장할 거란 가능성도 배제할 수 없는것이 현재 상황입니다. 슬프게도 아직 이 현상은 지금도 계속되고 있으며, 불편을 호소하는 리뷰가 등록되어 서비스 전체의 이미지와 평점을 갉아먹고 있습니다. 안드로이드 생태계가 사용자 및 서비스 제공자에게 더 유익한 방향으로 나아갔으면 하는 바람을 담아 작성했습니다.도움 주신 분동일 증상을 발견하고, 단말을 빌려주신 R&D SF팀 전호숙님같이 추적해주신 R&D CX 서비스실 유관종님Dump/Log 관련 조언을 주신 Wind River의 차영호님 (????????????)국어가 많이 부족한 저를 도와주신 리뷰어 ???????????? R&D CX 서비스실 강미경님, 송요창님, 유관종님, 유용우님, 이미혜님이번 현상 추적에 도움을 주신 분들에게 감사함을 전합니다.#야놀자 #개발자 #개발팀 #문제해결 #버그수정 #안드로이드 #인사이트 #경험공유

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 하드웨어팀 금손 이주현 님을 만나보세요:)사진1. 스켈터랩스의 하드웨어 엔지니어 이주현 님Q. 자기소개를 부탁한다.A. 스켈터랩스의 하드웨어 엔지니어로 일하고있는 이주현이다.Q. 스켈터랩스에서 구체적으로 어떤 일을 맡고 있는가.A. 현재는 스켈터랩스의 레고(L.ego)팀에서 곧 출시 예정인 스마트 미러, 샘(Samm)을 만들고 있다. 레고 팀은 스켈터랩스가 가진 원천 기술을 소비자가 쉽고 편하게 접할 수 있도록 디바이스(Device) 형태로 구현하는 팀이다. 우리의 원천 기술이 다양하다 보니, 이 기술을 어떻게 활용하여 어떤 제품을 만들어야 할지부터 고민한다.Q. 매번 새로운 기획을 하고 아이디어를 내는 것이 쉬운 일은 아닐 것 같다.A. 그래서 다양한 소스를 참고하고 많은 사람에게 의견을 구하려고 한다. 킥스타터(Kickstarter)나 와디즈(Wadiz)와 같은 크라우드펀딩 플랫폼을 들여다보거나 DIY 상품을 여러가지 찾아보며 영감을 얻는다. 최근에는 레고팀 PM(Product Manger)이신 아영님의 소개로 산업디자인과 수업을 청강했다. 산업디자인이 내가 일하는 분야와 아주 밀접한 것은 아니지만 학생들이 아이디어를 개진하여 그것을 발전시켜나가는 것을 보며 나 또한 아이디어를 얻을 수 있었다. 이런 과정을 통해 제품이 구체화되면 성공 가능성에 연연하지 않고 일단 개발을 시도하려 한다.Q. 실제로 제작하는 과정에서도 예기치 못한 문제에 많이 부딪히지 않나.A. 맞다. 참신해보였던 아이디어도 기능을 구체화하는 단계에 접어들면 자잘한 이슈가 생기기 마련이다. 사람마다 생각이 다르기 때문에, 고객에게 제품의 어떤 기능이 유용할 지 예상하기도 쉽지 않다. 때문에 소프트웨어 엔지니어와 디자이너, 마케터와 같은 다른 포지션의 동료들과 자주 미팅을 갖는다.제품의 구체화가 성공적으로 완료되더라도, 실제 구현이 녹록치 않다. 가령 곧 출시를 앞두고 있는 스마트 미러 제품, 샘(Samm)의 경우 사용자의 제스처(Gesture)를 인식하여 작동하는데 생각보다 카메라의 한계가 있더라. 그래서 요즘은 카메라 뿐만 아니라 다양한 센서를 활용하는 방법을 찾고있다.Q. 내가 상상했던 ‘일반적인 하드웨어 엔지니어'의 업무와는 조금 달라보인다. 기획자 역할까지 겸비하는 것으로 보이는데, 맞나.A. ‘일반적인 하드웨어 엔지니어'의 역할을 무엇이라고 정의하는지에 따라 다른 것 같다. 나는 오히려 스켈터랩스에서 하는 업무가 내가 생상했던 ‘하드웨어 엔지니어'의 업무다. 보통 엔지니어들은 직접 만들어보는 것을 좋아한다. 그렇지만 만들고 싶은 디바이스가 늘 회사의 방향성과 일치하는 것은 아니기 때문에, 집에서 홀로 개발하기에는 시간과 돈이 늘 부족하다는 하소연을 많이 듣곤 한다. 또한 회사의 규모가 커질수록 하드웨어 엔지니어는 하나의 제품을 깊게 들여다보기 때문에 전문가로 성장하는 반면, 내가 하고싶은 개발을 할 수 있는 기회는 줄어들기 마련이다. 하지만 스켈터랩스에서는 내가 상상한 디바이스를 구현하기 위해 각종 부품을 조립하여 테스트하고, 응용하여 새로운 디바이스를 만들고 있다. 그래서인지 이곳이 내게는 딱딱한 회사의 느낌이 아니다. 정확히 내가 꿈꾸고 하고싶었던 일을 할 수 있게 도와주는 곳이라고 느낀다.Q. 최근에는 어떤 디바이스를 만들고 있는가.A. 흔히 인공지능이라고 하면 일종의 어시스턴트를 많이 떠올리는 것 같다. 개인적으로는 이 ‘어시스턴트'라는 것이 너무 범위가 넓고 거대한 느낌이다. 나는 조금 더 작고 가벼운 기술, 그리고 특정한 범위 내에서 나의 일상에 정말 도움을 주는 제품을 개발하고 싶었다. 처음에는 방에 무드 조명이 있는데 ‘이 조명이 좀더 스마트하다면’이라는 생각을 가지고 확장시켜나갔다. 피터팬에 등장하는 “팅커벨”이라는 캐릭터가 생각이 났고 원하는 분위기에 따라서 혹은 알람을 제공하기 위해 예쁘게 불빛을 밝혀주는 것이 초기 모델이었다. 가정에서 인공지능 스피커를 사용하는 사용자들은 스피커를 실상 똑똑하게 쓰지 못하는 경우가 많다. 심지어 꺼놓는 경우도 많이 보았다. 나 또한 구매 초기에는 열심히 사용하다가 요즘은 알람 기능 만을 사용하고 있다. 개인적으로 인공지능 스피커를 잘 사용하지 않는 이유가 현재의 사용성과 음성으로 정보를 전달한다는 한계 때문이라고 생각했다. 스피커는 음성 명령을 잘 알아듣지도 못할 뿐더러, 내게는 스피커의 부자연스러운 음성이 시끄럽게 느껴지기조차 했다. 이런 불편함을 개선하기 위해 무드 조명의 색 조합을 통한 정보 전달을 구상했다. 조명의 색깔로 전달한다면, 스피커처럼 음성이 다 끝날 때 까지 기다리지 않아도 되고, 더욱 빠르고 덜 성가신 방법으로도 정보를 전달할 수 있다고 생각한다. 프로젝트를 구체화하며 조명과 사물인터넷(IoT)에 대해 공부하고, 컨셉을 발전시키다 보니 사물인터넷을 통한 조명 컨트롤이라는 새로운 방향성이 생겼다.사진2. 이주현 님은 다양한 실험을 통해 최적의 디바이스를 개발하고 있다.Q. 스켈터랩스에 어떻게 입사하게 되었는지.A. 어릴 때 부터 아이디어를 내고, 그것을 실제로 구현해보는 다양한 활동을 좋아했다. 학부 시절에는 아이디어를 발제하고 이를 직접 만들어보는 소모임에도 참여하였다. 학부 전공이 전자공학이지만 인공지능 기술에 대한 관심도 컸다. 사실 인공지능은 소프트웨어 분야 아닌가. 그래서 졸업작품을 인공 지능 관련 디바이스로 정했을 때도 소프트웨어 관련 강의를 찾아 들어야했다. 그러다 현재 우리회사 하드웨어 엔지니어 파트의 리더를 맡고 있는 재경님을 만나게 되었다. 처음에는 아이디어를 실현하기 위한 기술 자문을 구하기 위해 뵈었는데, 재경님이 근무하고 계신 회사 얘기를 들으면서 입사에 대한 꿈을 키우게 되었다. 그렇게 우연히 스켈터랩스에 대해 알게된 것 같다.Q. 자발적으로 인공지능 관련 공부를 했다지만, 스켈터랩스에서 일하며 인공지능 기술 회사에 하드웨어 엔지니어로 근무하기가 녹록치않을 것 같다.A. 인공지능 기술을 비롯한 소프트웨어 전반의 공부를 계속 해야하는 것은 맞다. 그렇지만 스켈터랩스는 자발적으로 공부하기 좋은 문화를 갖추고 있고, 자연스럽게 최신 기술을 접할 수 있는 기회도 많다. 너와 나의 일을 규정짓고 나누기보다는, 무엇이든 스스럼 없이 질문하고, 함께 답변을 찾아 가는 분위기가 조성되어있다. 그래서 기술 하나를 물어보면 열을 가르쳐주려고 한다. A를 물어볼 때, 시간이 된다면 A부터 Z까지는 알아서 답변해주는 분위기 같다. Tech-Talk와 같은 사내 세미나를 통해서 강의 형태로 인공지능 기술에 대해 접하기도 한다. 또한 하드웨어 팀 내부적으로도 공부에 대한 필요를 느끼고  자체 세미나를 진행한다. 거창한 것은 아니지만, 우리가 스켈터랩스 기술에 대해 알아야 할 부분을 각자 공부하고 공유하는 자리였다. 이러한 과정이 버겁기 보다는 좋아하는 분야를 더욱 심층적으로 접할 수 있어 좋다.Q. 스켈터랩스에서 일하며 느끼는 좋은 점을 자랑한다면.A. 스켈터랩스는 ‘일단 해보자'라는 분위기가 있다. 아이디어를 내면, 시간과 재화를 제공해주고 시도해볼 것을 권장한다. 작은 실패에 연연해 할 필요도 없다. 해보고 아니다 싶을 때, 그 때 가서 접어도 늦지 않다, 라는 쿨한 문화가 있다. 나와 같이 새로운 것을 생각하고 만드는 것을 좋아하는 이들이라면, 이곳이 정말 이상적이다. 집에서 혼자 하던 것을 ‘일'로서 지원받으며 할 수 있으니까 말이다. 그리고 정말 눈치보지 않는 문화라는 점을 강조하고 싶다. 일하다 지칠 때면 블루룸(스켈터랩스에서 가장 큰 룸인데, 게임방으로 활용되고 있다)에서 게임을 할 수도 있고, 쇼파로 편하게 자리를 옮겨 일하기도 한다. 입사 초창기에 휴가에 대해서 미리 양해를 구하곤 했는데, 그럴 때마다 들은 말은 ‘알아서 할테니 걱정하지 말아라. 휴가썼다고 말도 하지 말고 떠나라' 였다. 이처럼 자율적인 문화에서도 각자 알아서 제 몫을 톡톡히 해내고 있다는 것이 스켈터랩스의 가장 멋진 점이라고 생각한다.Q. 반대로 가장 힘든 점은.A. 아무리 하드웨어 엔지니어 파트에 대한 지원이 있더라도, 우리는 어디까지나 ‘인공지능 기술’ 회사다. 그렇기 때문에 소프트웨어 엔지니어가 훨씬 많고, 프로그램 개발이 회사의 메인 테스크(Main Task)로 인식될 때가 많다. 전자공학을 전공했는데 인공지능 회사에 다닌다고 하면 의아해 하는 엔지니어들도 많다. 하지만 최근 하드웨어 단에서 인공지능을 작은 저전력 디바이스에 옮기려는 연구는 계속해서 진행되고 있다. 소프트웨어팀이 멋지게 구현한 어플리케이션 등의 서비스를 100퍼센트 전달할 수 있는 디바이스를 만드는 것을 목표로 하고 있다.사진 3. 스켈터랩스의 블루룸에는 각종 게임이 구비되어있고 밴드부 연습실로 활용된다.Q. 스켈터랩스에서 업무 외에 어떤 활동을 하고 있나.A. 밴드, 축구, 헬스동아리까지 하고 있다. 취미가 음악이라 대학교 때부터 밴드부로 활동했는데, 그때마다 공간의 필요성을 절감했었다. 악기 대여비도 만만치않게 들지 않나. 스켈터랩스 밴드인 Terkels는 공간과 악기를 모두 갖추고 있다. 심지어 PA(Public Address) 앰프와 공연용 스피커까지 구비되어 있다. 축구 동아리에서 매주 1회 풋살 대결을 펼치고, 점심 시간마다 헬스 동아리원들과 함께 헬스장에 간다. 이렇다보니 부모님한테 ‘놀려고 회사가냐'라는 핀잔을 들을 정도다.Q. 많은 동아리와 업무를 병행하는 것이 힘들지는 않은가.A. 전혀. 오히려 동아리 활동으로 더욱 친해진 팀원과 함께 머리를 맞대고 하는 업무이다보니 ‘일'이 아니라 일종의 ‘놀이'처럼 인식될 때가 있다. 그리고 스켈터랩스 특유의 문화가 겉으로는 느릿느릿 여유롭더라도 내부적으로는 치열한 부분이 있다. 축구동아리에 처음 참여했을 때 동아리원들이 ‘살살 뜁시다' 하더니 막상 경기 시작되자마자 엄청나게 공격적이더라. 살살 뛰는 사람은 한 명도 없었다. 무섭게 뛰고 공격하면서 골이 계속 터졌다. 헬스동아리는 최근에 생긴 동아리다. 여름맞이 몸을 만들기 위해서 여럿이 뭉쳐서 헬스장을 함께 간다. 헬스 자체가 함께 할 수 있는 운동은 아니지만, 그래도 시간을 정해서 함께 이동하다 보니 ‘오늘은 좀 운동하지말고 먹을까' 싶다가도 다른 분들이 가면 자극을 받게 되고, 더 열심히 운동하게 되더라. 일도 마찬가지다. 처음에는 ‘회사가 이렇게 놀게 해줘도 되나'했지만, 내부적으로 탄탄하게 서로 함께 놀고 일하며 자극과 영감을 받는 문화다.회사는 딱히 데드라인을 촉박하게 주지도 않고, 압박을 하는 경우도 없다. 그런데 다들 게임방에서 신나게 게임을 하다가도 다음 날이면 개발을 마친 결과물을 들고 온다. 자율적이지만 확실하게 자신의 업무에 대해 책임을 지는 문화가 형성되어 있다. 그렇다보니 나 또한 자연스럽게 동아리 활동을 하다가도 오늘 하루 내가 끝내야할 일로 정해놓은 것들은 마치고 퇴근하려 한다.Q. 회사에 게임방이라니, 게임방 얘기를 듣고싶다.A. 게임을 좋아하는 사람들이 많다 보니 닌텐도를 비롯해서 엑스박스(Xbox), 플레이스테이션(Playstation)을 비롯한 각종 게임기가 마련되어 있다. 다트와 탁구대, 당구대까지 준비되어 있다. 사무실을 성수로 이사하면서 테드님(Ted Cho, 스켈터랩스의 대표인 조원규 님은 사내에서 테드님으로 불린다)이 ‘모두가 놀 수 있는 공간을 만들겠다'라고 했었는데, 정말 놀이터를 만들어주시더라. 덕분에 점심시간마다 삼삼오오 모여서 각종 게임과 탁구, 당구를 즐기고 있다.Q. 하드웨어 엔지니어로서 최종 목표가 있다면.A. 테드님이 우리에게 자주 하는 말 중 하나가 ‘Don’t be evil’이다. 이 말은 사실 구글의 모토인데, 스켈터랩스의 모두가 공감하는 얘기다. 기업이 이윤을 추구할수록 소수에 대한 외면이 발생하기도 하고, 기술 기업으로서 수익 창출 만을 목표로 하면 정작 일상을 어떻게 더욱 편리하고 윤택하게 만들어줄 수 있는지를 쉽게 망각하는 것 같다. 사악해지지 않으면서, 정말 우리의 삶을 나아지게 하는 방법을 계속해서 고민하고 싶다.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #팀원인터뷰 #팀원소개 #팀원자랑

OverviewDB를 다뤄봤다면 SELECT문도 아실 겁니다. 가장 먼저 접하는 명령어 중에 하나이기도 하죠. 보통은 아래처럼 사용합니다. SELECT문SELECT     * FROM 테이블명  ; 명령을 주면 지정한 테이블에 저장된 모든 내용을 검색합니다. 이번 글에서는 테이블을 만들고 SELECT하는 과정을 다뤄보겠습니다. DB는 MySQL 5.6을 기준으로 하고, Tool은 MySQLWorkbench를 사용하겠습니다.Query, 너란 녀석테이블은 위와 같이 생성할 수 있습니다. 위의 내용은 MySQLWorkbench를 이용해 Model을 표시하면 아래와 같습니다. 구성원의 정보를 저장하도록 했고, 컬럼마다 의미를 갖게 됩니다. MBR_ID (구성원 아이디) : DB에서 구성원을 식별하는 아이디MBR_INDFY_NO (구성원 식별 번호) : 구성원을 실제 구별하는 번호로 과거에는 주민등록번호가 많이 사용되었고, 요즘은 e-mail 이 많이 사용됩니다.MBR_NM (구성원 명) : 구성원의 이름 테스트 데이터를 입력해 실행하면 어떤 결과가 나오는지 보겠습니다.가장 기본적인 SELECT문 실행계획을 보면 아래와 같이 나옵니다.실행 계획은 DB가 어떻게 Query를 수행할 건지 보여줍니다. Query가 복잡해지면 실행 계획을 보면서 Query가 올바르게 작성됐는지 확인하고 필요하다면 Query를 수정해야 합니다. DB를 시작할 때부터 실행 계획을 보는 습관을 기르는 게 중요한 이유입니다. 각 항목에 대한 설명id : SELECT 문에 있는 순차 식별자로 Query 를 구분하는 아이디select_type : SELECT의 유형SIMPLE : Subquery나 union 이 없는 단순한 SELECTtable : 참조되는 테이블의 명칭TB_MBR_BAS : 참조되는 테이블명type : 검색하는 방식ALL : TABLE의 모든 ROW를 스캔 위의 이미지는 임의로 만든 자료를 이용해 Query를 실행한 결과입니다. 실행 계획은 TABLE : TB_MBR_BAS 를 TYPE : ALL 전체 검색한다고 나옵니다. 실행한 내용도 같습니다. 여기서 MBR_NM 이 “나서영”인 자료를 검색해볼까요. WHERE 조건이 들어가자 실행 계획도 내용이 변경되었습니다. rows와 Extra에도 값이 있는데요. 두 항목을 잠시 짚고 넘어가겠습니다. rows : Query를 수행하기 위해 접근해야 하는 열의 수Extra : MySQL 이 Query 를 수행할때의 추가 정보Using where : Query 수행시 TABLE에서 값을 가져와 조건을 필터링 함 위의 결과처럼 전체를 검색해 필요한 자료만 추출하는 것을 FULL TABLE SCAN or FULL SCAN 이라고 합니다. 그러나 FULL SCAN은 성능이 좋지 않기 때문에 우선 꼭 필요한 Query인지 검토해야 합니다. 보통 MBR_NM에 INDEX를 추가해서 해결하는데요. INDEX를 추가해서 같은 Query를 수행하면 실행 계획은 어떻게 달라질까요. 분명 같은 Query였는데 INDEX에 따라 실행 계획이 변경된 걸 알 수 있습니다. INDEX를 추가해도 수행한 결과는 같지만 검색 속도에 많은 차이가 있습니다. 각 항목에 대한 설명type - ref : 인덱스로 자료를 검색하는 것으로 현재는 매칭(=) 자료 검색을 나타냄possible_keys : 현재 조건에 사용가능한 INDEX를 나타냄(인덱스가 N개일 수 있음) IX_MBR_BAS_02 : 현재 조건에 사용 가능한 INDEXkey : Query 수행시 사용될 INDEX (possible_keys 가 N 개일 경우 USE INDEX, FORCE INDEX, IGNORE INDEX 로 원하는 INDEX 로 바꾸어 수행할수 있음)key_len : 수행되는 INDEX 컬럼의 최대 BYTE 수를 나타냄152 : 수행되는 INDEX 컬럼의 BYTE 수가 152ref : INDEX 컬럼과 비교되는 상수 여부 or JOIN 시 선행 컬럼 constant : 상수 조건으로 INDEX 수행rows : 678 : 678 rows 접근하여 값을 찾음Extra : using index condition : INDEX 조건에 대하여 스토리지 엔진이 처리(MySQL의 구성에서 스토리지 엔진과 MySQL 엔진이 통신을 주고 받는데 스토리지 엔진에서 처리 하여 속도가 향상됨) ConclusionINDEX가 없으면 결과가 나오기까지 5초 정도 걸리지만, 반대로 INDEX가 있으면 1초 안에 결과가 나옵니다. 별거 아닌 것 같아 보이지만 실무에서는 엄청난 차이입니다. Query를 작성할 때 실행 계획을 확인하고 조금이라도 빨리 결과가 나올 수 있도록 하는 것이 중요하기 때문이죠. 다음 글에서는 단일 TABLE 을 SELECT하는 것을 주제로 이야기를 나눠보겠습니다. 무사히 SELECT하길 바라며.글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

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

편집자 주 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

Overview서비스되는 프로젝트에 첫 커밋(Commit)했던 순간이 아직도 생생합니다. 직원이 10명 남짓이던 시절, 특정 데이터를 삭제할 때나 쓰던 관리자 페이지였는데요. 당시엔 MVC Pattern, Transaction 등 아무것도 몰랐기 때문에 실수를 반복했습니다. (팀장님으로부터 피드백도 많이 받았죠.) 어떤 실수였는지 궁금하시죠? 오늘은 두 번 다시 겪고 싶지 않은 실수들과 깨달은 몇 가지 이야기와 개발자가 꼭 지켜야할 것을 소개하겠습니다. 사용자를 생각하는 마음예전에는 로직을 짤 때 실패하는 케이스를 깊게 생각하지 않았습니다. 왜냐하면 “나는 기능을 만들고, 사용자는 내가 만든 기능을 쓴다.”고 생각했기 때문입니다. 요구 사항대로 동작하게 만들고, 예외 케이스는 사용자의 책임으로 돌렸습니다. 하지만 이런 태도로 개발하면 UI/UX는 발전할 수 없고, 서비스도 개선될 수 없으며, 사용자의 불만만 생긴다는 걸 곧 알게 되었죠. 작년 이맘때쯤 브랜디 앱에 진열될 상품 관리 페이지를 개발했습니다. 요건에 기재된 내용을 요약하면 아래와 같았습니다.제시된 요건등록 가능한 상품의 개수는 ‘무제한’이다.하나의 페이지에 여러 구좌를 관리하는 영역이 들어갔으면 좋겠다.상품 조회 화면에는 ‘누적 판매량’과 ‘7일 판매량’ 항목이 추가되어야 한다.우선 ‘무제한’이라는 단어에 각 관리 영역마다 max-height를 지정했는데요. 여러 관리 영역이 하나의 페이지에 들어가더라도 스크롤을 많이 하지 않아도 되게 작업했습니다. 이뿐만이 아닙니다. 중복된 상품을 등록할 수도 있기 때문에 그것에 대한 유효성도 추가했죠. 하지만 막상 프로덕션(production)에 배포되니 직원들의 피드백이 쏟아졌습니다.“상품을 등록하고 다시 관리 페이지에 진입하려니 시간이 오래 걸려요.”“상품이 중복됐다고 alert이 뜨는데 어떤 상품이 겹치는지 알 수는 없나요? 혹시… 일일이 찾아야 해요?” 2)“상품 setting 후에 등록을 했는데 다시 보니 안 되어있어요!”“아뿔싸, ’무제한’이라는 단어를 보고 max-height 값만 떠올리다니!” 드러난 이슈들을 수정하면서 반성하고 또 반성했습니다. 등록된 상품들을 가져와서 페이지에 렌더링(rendering)할 때, 상품 수가 많을수록 뷰 페이지의 로딩 속도는 느려진다는 걸 예측하지 않았습니다. 심지어 하나의 페이지에 여러 구좌를 관리할 수 있도록 개발했으니, 불러와야 할 상품은 수백, 수천 개였을 겁니다. 직원들은 하염없이 페이지만 바라보며 불만을 터트릴 수밖에 없었고요. 이후엔 페이지에 진입하자마자 상품 목록을 가져오지 않고, 특정 버튼을 눌렀을 때 ajax로 상품을 로딩하는 방식으로 개선했습니다.당시 개발했던 진열 관리 화면상품 등록이 잘 안 된다는 이슈는 로컬(local) 및 스테이징(staging) 서버에서 재현되지 않아 고개를 갸웃거렸는데요. 프로덕션(production) 정보를 보고 나서야 원인을 잡을 수 있었습니다. ajax를 이용해 POST로 전송할 수 있는 array의 최대 사이즈가 정해져 있다는 걸 알게 된 것이죠.1) 결국 JSON 형태로 바꾸어 데이터를 전송하고, 서버사이드에서 배열을 다시 변환해 로직을 수행하도록 개선했습니다. 팀장님의 질문도 기억에 남습니다. 팀장님은 단호하게 물었죠.“쿼리 돌아가는 건 확인했어?”일정이 급급하다는 이유로 쿼리를 확인하는 과정을 간과했습니다. 데이터는 당연히 0건으로 나왔지만 조건에 부합하는 데이터가 없어서인지, 잘못된 질의 때문인지는 의심하지 않았던 것이죠. 팀장님은 말했습니다.“네가 자꾸 실수하면 사용자는 우리 시스템을 신뢰할 수 없을 거야.”PRODUCT_REGIST_DATETIME BETWEEN NOW() AND NOW() - 7 나 : 7일동안 등록된 상품 데이터를 가져와주세요.데이터베이스 : …???주위를 관심 있게 둘러보는 눈지난 번에 쓴 신입개발자를 위한 코드의 정석을 보면 ‘모든 개발조직은 좋은 품질의 소프트웨어를 개발할 수 있는 개발자를 원한다’는 문장이 있습니다. 좋은 품질과 가치 있는 서비스를 만드는 건 개발자가 당연히 가져야 할 책임과 소신입니다. 서비스에 대한 이해도 어느 정도 필요하고요. 그렇지 않으면 엉뚱한 서비스가 나옵니다.재작년, 브랜디 커머스 웹 1.0 버전을 개발했을 땐 e-commerce에 대한 이해도가 거의 없었습니다. 유사한 서비스들의 레퍼런스를 진행하고 개발을 시작해야 했는데 그저 상상력에 의존한 채 UI/UX 개발을 진행했었습니다. 그때 느꼈던 걸 몇 가지 정리해보겠습니다. 유사한 서비스를 적극적으로 사용하자!사람들은 많이 쓰는 서비스의 UI/UX에 익숙합니다. 그러므로 유명하면서도 비슷한 목적을 수행하는 다른 서비스들을 사용해보세요. 그 분야에 대한 센스가 무럭무럭 커질 겁니다. 더 나아가서는 사람들이 익숙하다고 느끼는 것보다 훨씬 더 편한 UI/UX를 떠올릴 수도 있겠지요!다른 개발자의 생각도 물어보자!같은 문장을 보고도 다르게 해석하듯, 같은 서비스를 개발하는 개발자들도 저마다 솔루션은 다릅니다. 자신은 괜찮다고 생각하더라도 다른 개발자에게 꼭 물어보세요. 미처 생각하지 못했던 의견들이 나올 수 있습니다. 즉, 많은 커뮤니케이션이 더 좋은 개발을 돕는 것이죠.개발하기 쉬운 서비스 말고, 사용자가 쓰기 편한 서비스로 만들자!일정에 쫓기면 당장 개발하기 편한 방법을 선호할 수도 있습니다. 개발자의 주관적인 판단이 UI/UX를 망칠 수 있는데도 말이죠. 실수는 자신이 만회해야 합니다. 눈앞의 것을 생각하지 말고, 사용자를 생각하며 개발합시다. 사용자가 기분 좋게 서비스를 이용하는 게 훨씬 뿌듯하잖아요. Conclusion무수한 실패담 중에 기억나는 몇 가지만 추렸습니다. 과거의 코드나 실수의 이력들을 글로 써 보니 ‘전부 내 경험이 되었구나’라는 생각이 듭니다. 지금 이 글을 읽고 있는 당신은 어떤 실수를 해보셨나요? 손해 보는 경험은 없습니다. 분명 언젠가는 도움이 될 거예요. 주석1)이 때문에 상품을 등록할 때, 스크립트에서 array로 담아 전송하면 데이터가 누락되어 제대로 등록되지 않거나 에러가 발생할 수 있는 결함이 있었다.2)중복된 상품을 화면에 표시해주는 기능은 여러 상황으로 인해 개선하지 못했다. 이후에는 발생하는 문제의 사유를 사용자에게 친절히 알려주어서 원하는 결과를 얻도록 힘쓰고 있다. 참고개발자는 개발만 잘하면 된다?사용자는 결코 실수하지 않는다글김우경 대리 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

모니터링은 IT 운영의 핵심입니다. 장비의 활성화 상태에서 애플리케이션의 변화와 성능 이슈까지 언제나 실시간으로 인지와 대응이 가능해야 합니다. 서비스를 운영에 장애를 없앨 수는 없지만 좋은 모니터링 전략을 가지고 있다면 빠른 예방과 대응을 통해 고객이 불편함을 느끼지 못하게 할 수는 있습니다.  IT 운영에서의 비지니스 목표IT 서비스 모니터링 전략을 만들기 전에 우리는 우선 목표를 선정해야 합니다. 빠른 예방과 대응은 좋은 모니터링 전략의 기본 목표일 뿐입니다. 우리는 모니터링을 통해 아래와 같은 비지니스 목표를 이루어야 합니다. 브랜드 이미지 향상매출증대비지니스 개선비지니스 목표를 위한 모니터링그리고 이런 비지니스 목표를 위해서는 아래와 같은 일들을 모니터링을 통해 수행할 수 있어야 합니다. 안정적인 서비스 운영 (브랜드 이미지 향상, 매출증대)빠른 장애 대응 (브랜드 이미지 향상, 매출증대)장애 예방 (브랜드 이미지 향상, 매출증대)사용자 분석 (비지니스 개선)사용성 분석 (비니지스 개선)서비스 성능 개선 (브랜드 이미지 향상, 매출증대)현대 IT 서비스는 물리서버와 클라우드가 혼재되어 있는 인프라스트럭처 환경과 다양한 플랫폼에서 개발된 애플리케이션들이 작게 구성되어 있는 복잡한 구성을 가지고 있습니다. 뿐만아니라 서비스의 구성 또한 전 세계에 분산되어 있는 상황에서 우리는 효율적인 모니터링 전략을 만들어서 IT 서비스를 운영해야 합니다.비지니스 목표를 위한 모니터링 전략이런 체계적이고 효율적인 IT 서비스 모니터링 전략을 만들기 위해서는 아래와 같은 것들을 고려해야 합니다.1. 통합 모니터링 체계를 구축하세요.  인프라스트럭처와 애플리케이션을 모두 모니터링하여 전체 그림을 얻어야 합니다. 전체적인 그림을 모든 운영자들이 알수 있어야 체계적인 IT 서비스 운영이 가능합니다.2. 기준을 넘어서는 성능 변화가 생기면 알수 있도록 경고를 설정해야 합니다. CPU 부하율, 메모리 사용률, 누적 트랜잭션 등 다양한 상황에 대한 기준 값을 선정하고 이에 대한 알림을 받을 수 있어야 합니다. 초기 이슈 확인은 고객이 영향을 받기 저너에 문제를 해결할 수 있게 해 줍니다. 3. 사용자 관점에서 모니터링 해야 합니다. 예를 들어 TPS의 평균값만으로 서비스의 안정성을 판단해서는 안됩니다. 사용자 개개별 현황을 파악 할 수 있어야 합니다. 기업의 브랜드는 서비스 사용에 불편을 겪는 1%의 고객을 통해 내려갈 수 있습니다.4. 메트릭을 비지니스 목표와 맞출 수 있어야 합니다. 현재 서비스에 접속한 사용자 현황을 알 수 있어야 합니다. 예를 들면 동시 접속자 수를 기반으로 현재 서비스의 성능을 설명할 수 있어야 합니다. 5. 애플리케이션에서 특히 데이터베이스의 성능을 평가할 수 있어야 합니다. 많은 이슈들이 데이터베이스에서 발생합니다. 6. 애플리케이션의 코드 성능을 분석할 수 있어야 합니다. 많은 프로젝트에서 오픈소스 또는 서드파티 솔루션들이 사용되고 있습니다. 여기서 발생하는 문제들은 심각한 장애 상황을 유발할 수 있습니다.7. 모든 서비스를 분석 할 수 있어야 합니다. 몇몇 페이지가 아니라 전체 페이지를 분석 할 수 있어야 합니다. 우리는 항상 효율적인 IT 모니터링 전략을 재평가하고 새로 구축해야 합니다. 모니터링 전략을 만드는 것은 쉬운 일이 아닙니다. 하지만 모니터링 전략을 만드는 데 시간을 투자하는 것은 안정적으로 서비스를 운영하는데 있어서 매우 가치있는 일입니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

문제 상황안드로이드 어플리케이션을 개발하다 보면 주소록을 다루는 일이 종종 있습니다. 어플리케이션에서 주소록에 관련된 정보를 접근할 일이 있는 어플이라면 ContentResolver를 통해 단말의 주소록에 접근해서 필요한 정보를 가져오게 됩니다.그런데, 최근 개발하고 있는 스포카 어플을 통해 아주 많은 사람의 연락처가 저장된 주소록을 가지고 이런 저런 로직을 실행하는 상황을 테스트 하다보니, OutOfMemory(OOM)에러가 발생하는 현상을 볼 수 있었습니다. 모바일 디바이스들은 PC와 다르게 자원이 제한적이기 때문에 어떻게 하면 OOM을 일으키지 않을 수 있을까 라는 고민을 해야 하는 상황이었습니다.대강 문제가 되었던 클라이언트 사이드의 로직을 살펴보면 이렇습니다.단말의 주소록에 접근하여 필요한 정보를 추출 후 서버에 전송서버에서 정보를 가공하여 필요한 json 문자열을 생성 후 반환, 이 문자열은 주소록에서 보낸 정보의 양에 비례해서 늘어나게 됩니다.클라이언트 측에서 서버 측에서 보낸 json 문자열을 이용하여 JSONObject객체를 만든 후 이 JSONObject를 이용 리스트 완성eclipse의 MAT(Memory Analyzer)을 이용하여 어느 시점에서 OOM이 일어나는지를 추측해보았습니다. 서버에서 보내준 json형식의 문자열을 HttpURLConnection을 통해 전달받고 이를 StringBuilder를 이용하여 완전한 문자열으로 만들던 도중에 OOM이 일어나는 것으로 의심되었는데 이 때문에 JSONObject의 생성자에 json 문자열을 전달하기도 전에 메모리가 가득 차 버리니 매우 난감한 상황이었습니다.대게 주소록에 사람이 그렇게 많지 않으므로 (200~500명 정도) 아무런 문제가 없었지만 10000명 정도의 더미데이터를 주소록에 저장하고 테스트하다 보니 append 메서드를 호출하다 OOM에러를 뱉으면서 어플이 종료되었습니다. 문제는 append 메서드를 호출 시 StringBuilder의 capacity를 넘을 경우 내부적으로는 메모리 재할당과 copy과정이 일어난다는 것이었습니다. 그렇다고 초기 StringBuilder생성시 capacity를 무작정 높게 잡기도 애매한 상황이었습니다.gsongson은 Java객체를 json형식으로 변환하고 그 역으로도 변환할 수 있도록 도와주는 라이브러리입니다. gson의 사용법이 궁금하다면 gson user guide를 읽어보면 되고 api가 궁금하다면 gson api document를 참조하면 됩니다.gson 적용대략 이런 방식으로 프로젝트에 gson라이브러리를 적용하였고, HttpURLConnection을 통해 받아온 InputStream을 이용 바로 객체를 생성할 수 있었습니다. 이전에 StringBuilder를 이용할때 생기는 오버헤드가 사라진 셈이죠. 위와 같은 방식으로 OOM이 생기는 문제 상황을 해결 할 수 있었습니다.위의 예는 상황을 최대한 단순화하여 설명하려고 작성한 예제이고 이 사이트를 통해 더 상세하게 설명된 사용예를 보실 수 있습니다.#스포카 #개발 #개발자 #GSON #Java #인사이트 #google_gson

Overview대학을 수석으로 졸업했지만, 정작 회사에서는 A부터 Z까지 제대로 할 줄 아는 게 없었습니다. 실수를 남발할 때마다 느꼈던 좌절감은 아직도 생생하지만 되돌아보면 그때의 삽질이 소중한 피와 살이 되었지요. 오늘은 헤매고 있는 신입 개발자를 위한 글을 쓰려고 합니다. 신입 개발자, 당신! 내 이야기를 편하게 듣고 가지 않으실래요? 남을 위한 코드, 클-린 코드“너랑 같이 일하는 사람은 어떻게 보라는 거야?” “한 명이 짠 코드인데, 어째 한 사람이 짠 것 같지가 않다..” “이게 네 스타일이냐?” 대학생이었을 땐, 대부분 혼자서 프로젝트를 진행했습니다. 다른 사람이 제 코드를 보는 일도 거의 없어서 띄어쓰기나 들여쓰기 등에 통일이 없었고, 함수의 네이밍도 전혀 고려하지 않았습니다. 이게 나쁜 습관이었다는 걸 입사하고 알게 되었죠. 이 습관을 고치려고 코딩 컨벤션(coding convention)을 지키는 것에 꽤 오랜 시간을 들여야만 했습니다. 우리는 협업을 하는 사람들입니다. 사람들이 더러운 방보다 깨끗한 방을 좋아하는 것처럼, 당신과 협업하는 개발자도 보기 어려운 코드보다 깨끗한 코드를 더 좋아합니다. 클린 코드를 작성하기 위한 세 가지 기본 원칙을 잠시 소개합니다. 클린 코드를 위한 세 가지 기본 원칙 코드를 최초로 작성한 사람이 끝까지 유지보수를 한다는 보장은 없다.이미 잘 정리된 코드는 효율성이 증가한다. 정리할 시간에 코드 한 줄을 더 분석할 수 있으니까!리팩토링은 미루었다가 한꺼번에 하는 것이 아니다. 코드를 작성하는 매순간 함께 하는 활동이다.작은 것 하나부터 습관을 들여보세요. 분명 깔끔하고 보기 좋은 코드를 만드실 수 있을 겁니다. 머지 않아 “남을 위한 코드는 곧 나를 위한 코드”라는 것도 알게 될 거고요. 책의 한 구절이 떠오르네요. “우리는 저자이다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통해야할 책임이 있다.”⌈Clean Code⌋의 저자, Robert C. Martin 설마가 사람 잡는다, 철저한 검증만약 누군가 검증 단계에서 잊지 말아야할 것이 뭔지 묻는다면 이렇게 대답하고 싶습니다. “절대 사용자가 입력한 값을 신뢰하지 말라. 프론트엔드에서도, 백엔드에서도.” 모든 사용자가 각 항목에 맞게 올바른 정보만 입력해준다면 얼마나 좋을까요? 세상에는 다양한 사용자가 있습니다. 너무 바빠서 얼른 회원가입을 해야하는 사용자는 항목을 채우지도 않고 신청 버튼을 누를 수도 있습니다. 영어로 입력해야 하는 항목엔 한글을 입력한 사용자도 있을 겁니다. 이런 휴먼 에러(human error)뿐만 아니라 의도적으로 비정상적인 요청을 시도하는 사용자도 분명 있습니다. 이 때문에 개발자는 기능에 대해 항상 검증해야 합니다. 바로 이렇게요!그런데 프론트엔드에서 유효성 검사를 하면, 백엔드에는 유효한 값만 넘어온다고 보장할 수 없습니다. 자바스크립트는 브라우저 엔진에 따라 다르게 동작할 수도 있습니다. 또 자바스크립트에서 다루는 값들은 크롬의 개발자도구(option + command + i)를 이용하면 얼마든지 값을 변조하거나 검증을 회피할 수 있습니다. 또 불온한 시도가 아니더라도 다양한 예외 케이스들이 존재하기 때문에 백엔드에서도 무조건 검증해야 합니다.페이스북 페이지의 개발자 도구를 열었을 때 노출되는 화면입니다. 얼마나 나쁜 사람들이 많으면 경고화면까지 만들었을까요?누군가 질문할 수도 있겠군요. “프론트엔드의 검증이 의미가 없다면, 백엔드에서만 검증을 해도 되지 않을까요?” 네, 아닙니다.(단호) 많은 양의 일을 한꺼번에 하는게 힘든 것처럼 무분별한 요청이 서버에 쏟아지면 서버도 사람처럼 지치고 말 겁니다. 응답이 느려지는 등의 문제가 생길 수도 있고, 결국 사용자가 불편해질 것입니다. 그러므로 가장 좋은 검증 방식을 3단계로 정리하면 아래와 같습니다. 고수가 되는 검증 방식 3단계프론트엔드에서 먼저 값 검증을 하여 빠른 사용자 경험을 제공한다.백엔드에서 다시 한 번 더 검증을 거쳐 상황에 적절한 응답 코드를 내려준다.프론트엔드는 상황에 맞게 적절한 UX와 메시지를 보낸다. 동작 그만! 정리는 하고 코딩하자!예전에는 요구사항이 있으면 바로 키보드 위에 손부터 올렸습니다만, 그건 좋은 태도가 아니었습니다. 팀장님이 “이 경우엔 어떻게 하지?”라고 질문하면 아무 대답도 하지 못했기 때문이죠. 팀장님은 늘 “항상 먼저 생각하고 코딩하자!“라고 조언하십니다. 맞습니다. 최대한 모든 경우의 수를 머릿속에 정리하고 코딩을 시작해야 합니다. 시간이 없다는 핑계로 무작정 시작하면 분명 문제가 발생합니다. 또 구현할 기능만 몰두하지 말고, ‘이 기능이 다른 기능에 영향을 미칠 수 있을까?’를 고민하면 훨씬 좋은 코드를 만들 수 있을 겁니다. “이런 거 다 생각하고 짜면 도대체 코딩은 언제 하라고?” “얼른 선임 분들에게 코딩하는 내 모습을 보여줘야 하는데!” “당장 코드 안 짜고 있으면 노는 것처럼 보이지 않을까?” 혹시 이런 생각을 하고 계신가요? 나도 그런 생각을 했던 적이 있습니다. 하지만 요구사항을 확실하게 정리한 후, 코드를 짜는 게 더 효율적입니다. (그렇지 않으면.. ‘수정’이란 이름 아래 모든 것을 뒤엎고 처음부터 다시 시작해야할 수도 있습니다.) ‘더 나은 개발자가 되는 8가지 방법(8 Ways to Become a Better Coder)’이란 글에는 이런 내용이 있습니다. “동작하는 코드는 끝이 아니라 시작이다.” 신입 개발자는 종종 요구사항에 따라 동작하는 코드만 짜면 된다고 여길 때가 있습니다. 물론 사회생활에 적응하느라 정신 없는 와중에 그나마 자신의 코드가 요구사항대로 동작하면 무척 뿌듯할 겁니다. 하지만 동작만 한다고 절대 지나치지 말아주세요. 위에서 언급한 것처럼 깨끗한 코드가 되도록 리팩토링을 하고, 검증하고, 동작이 제대로 되는 것인지 의심하면서 꾸준히 노력해야 합니다. 마지막으로 항상 중요하게 생각하는 문장 하나를 남기고 글을 마치겠습니다.“진정으로 훌륭한 프로그래머는 적극적으로 어디가 잘못되었지를 찾는다. 자기가 놓친 결함은 결국 ‘사용자’가 발견하게 된다는 것을 알고 있기 때문이다.” Esther SchindlerConclusion지금까지 다룬 내용은 결국 같은 맥락입니다. 모든 개발조직은 좋은 품질의 소프트웨어를 개발할 줄 아는 개발자, 협업할 줄 아는 개발자를 원합니다. 누군가 “당신은 잘 지키고 있는가”라고 질문한다면, “저 또한 노력하고 있습니다.”라고 답변하고 싶습니다. 같은 자리에 머무르는 개발자가 될 것인지, 부족함을 알고 항상 배우고 나아가는 개발자가 될 것인지는 스스로의 몫이라고 생각합니다. 이 글을 끝까지 읽은 신입 개발자 당신! 같이 노력하지 않으실래요? :-) 참고 Robert C. Martin, 「Clean Code」, 케이엔피북스(2010)Esther Schindler, 8 Ways to Become a Better Corder, New Relic, 2018.03.02.유석문, 「프로그래머 철학을 만나다 - 소프트웨어를 사랑하는 기술」, 로드북(2014)임백준, 「읽기 좋은 코드가 좋은 코드다」, 한빛미디어(2012)팀장들이 꼽은 신입 PHP 개발자가 가급적 빨리 알았으면 하는 것들프론트에서”만” 유효성 검사가 문제인 경우남을 위한 코드 만들기 - 클린코드글김우경 대리 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

Backbone이란?Backbone은 자바스크립트 프레임워크로 MVC 패턴을 적용하여 웹 애플리케이션 개발할 수 있도록 돕는 유용한 프레임워크입니다. MVC 패턴에 대해서는 밑에 더 자세히 설명하기로 하고 간단히 Backbone을 적용한 후의 장점을 소개하면 깔끔하게 뷰와 로직을 분리할 수 있어 코드를 유지 보수하는데 드는 시간이 줄며 기능 수정 혹은 기능 확장이 쉬워진다는 점등을 들 수 있습니다.또한, Backbone에서는 Underscore 라이브러리를 사용하는데, 이 라이브러리에서 제공하는 템플레이트 기능을 통해 뷰의 재사용과 설계를 쉽게 할 수 있다는 점도 장점입니다.만약 서버 측에서 RESTful한 URL을 제공한다면, Backbone을 사용하여 얻을 수 있는 이점이 더 확실해집니다. 모델에 RESTful한 URL을 제공하면, 간단하게 서버와 동기화하면서 그에 따르는 뷰의 변화 따위를 손쉽게 구현할 수 있습니다.RESTful한 인터페이스 설계에 대해서 궁금하시다면 이전에 올라온 글을 참조해보세요. Backbone 기반으로 설계된 여러 웹 애플리케이션 중에는 여러분이 잘 알고 있을만한 서비스들도 있을 것입니다.MVC 패턴?이미 MVC라는 용어에 익숙하신 분들도 많겠지만, 생소하신 분들을 위하여 간단히 정리해보면 MVC 패턴은 디자인 패턴 중의 하나로 모델(실제 쓰일 데이터)과 모델을 보여줄 뷰(인터페이스) 그리고 사용자로부터의 입력을 받아 모델과 뷰를 중재하는 컨트롤러로 나누어서 구현을 해나가는 방식을 말합니다. GoF 책에도 이 패턴이 소개되어 있지요.모델은 뷰나 컨트롤러와 무관하게 작성되는데 그런 모델을 뷰가 관찰하고 있다가 모델의 변화에 따라 적절히 뷰의 모습을 바꾸게 되므로 서로 투명하게 작동하게 됩니다. 즉 모델만 잘 설계해서 만들어주고 그에 따르는 뷰의 모습만 정의하면 그다음부터는 지저분하게 모델의 상태에 따르는 코드를 직접 처리할 필요가 없다는 장점이 있습니다.Backbone이 MVC 패턴을 적용하기 위한 프레임워크라고 하였지만, 실제로 Backbone에서는 MVC 패턴의 변형인 MVR 패턴을 사용합니다. 컨트롤러 대신 Router가 쓰이는 형식인데, 이 링크에서 Backbone의 Router에 대한 자세한 설명을 제공하고 있습니다. 하지만 Router가 컨트롤러의 역할을 대행하는 것은 아니고, 대부분의 Backbone 예제를 살펴보면 실제로 컨트롤러가 담당하는 업무들을 뷰에 이관하여 처리하는 것을 볼 수 있습니다. MV* 패턴 중에는 MVP 패턴이나 MVA 패턴 같은 MVC 패턴의 변형들이 존재합니다만 그 바탕을 이루는 Model-View의 관계는 변하지 않는 것을 볼 수 있습니다.Simple code snippet간단한 예제를 통해 실제 코드 상에서 어떤 식으로 Backbone을 적용하는지 알아보겠습니다.모델먼저 모델을 정의해야 합니다. 가령 밑의 코드에서는 사각형 모델을 정의하고 있는데요, 기본값을 지정해 줄 수 있고, 사각형 모델과 관련된 함수들을 정의해놓은 것을 볼 수 있습니다.var Shape = Backbone.Model.extend({ defaults: { x:50, y:50, width:150, height:150, color:'black' }, setTopLeft: function(x,y) { this.set({ x:x, y:y }); }, setDim: function(w,h) { this.set({ width:w, height:h }); }, });이렇게 Backbone.Model.extend 함수를 통해 모델의 청사진을 구성하게 됩니다. 이 모델을 이용하여 뷰를 구성할 수 있습니다.콜렉션Backbone.Collection.extend({ model: Shape });많은 상황에서 복수의 모델을 다루게 될 일이 생깁니다. 가령, 게시판에 올라온 글들은 게시물의 집합이라고 볼 수 있겠죠. 콜렉션을 통해서 이러한 복수의 모델의 집합을 만들어낼 수 있습니다. 위의 코드에서는 앞서 소개한 Shape 모델의 콜렉션을 정의한 것을 볼 수 있습니다. 모델과 마찬가지로 콜렉션도 뷰에 바인딩할 수 있고, 콜렉션에 관련한 이벤트(change, add, remove)를 뷰과 관찰하게 할 수 있습니다. 또한, Underscore 라이브러리에서는 콜렉션과 밀접하게 관련된 여러 함수를제공합니다.뷰var DocumentRow = Backbone.View.extend({ tagName: "li", className: "document-row", initialize: function() { this.model.bind('change:name', this.render); }, events: { "click .icon": "open", "click .button.edit": "openEditDialog", "click .button.delete": "destroy" }, render: function() { // render or update something } });기본적으로 뷰에 뷰와 관련된 모델이나 콜렉션을 바인딩하게 되는데요, 이 바인딩을 통해 뷰는 모델이나 콜렉션의 상태를 관찰하고 변화를 감지하여 바인딩 시 전달한 핸들러를 통해 적절한 행동을 수행할 수 있게 됩니다. 위의 예제를 보면 모델의 name 속성 변경 시 render 함수를 호출하도록 바인딩한 것을 알 수 있습니다. 또한, 뷰에 관련한 이벤트와 그에 관련된 핸들러를 events에 정의해놓을 수 있습니다. 보통 render 함수 내에서 뷰를 구성하거나 혹은 바인딩 된 모델, 콜렉션의 변화에 따르는 뷰의 변화를 적용하게 됩니다.뷰에 관련된 더 자세한 사항은 뷰 문서를 참조하시기 바랍니다.템플레이트var compiled = _.template("hello: <%= name %>"); compiled({name : 'moe'}); => "hello: moe"Underscore에서 제공하는 템플레이트 기능을 이용하여 문자열을 곧바로 html 요소로 만들어낼 수 있습니다. 또한, 템플레이트 내에 자바스크립트 함수 등을 삽입하는 기능도 제공합니다. 기본적으로 Underscore에서 템플레이트 기능을 제공하지만, 그 외에도 여러 라이브러리가 있습니다.가령 mustache를 이용해서도 똑같은 기능을 할 수 있습니다. 필요에 따라 유연하게 템플레이트 라이브러리를 바꿀 수 있다는 점이 매력이라고 볼 수 있습니다. Backbone 공식 사이트에서도 이러한 템플레이트 라이브러리를 이용하는 것을 권장하고 있습니다.Ember.jsBackbone이 나름의 역사가 있는 프레임워크이기 때문에 많이 쓰이고 있지만, 그 외에도 비슷한 기능을 제공하는 프레임워크가 많습니다. 그 중의 하나인 Ember.js가 있습니다. Ember.js의 장점이라면 기본적으로 Handlebars라는 템플레이트 라이브러리를 지원함과 동시에 Backbone보다 심화된 여러 기능을 제공하는 점이 있습니다.그러면서도 사용의 꼴이 Backbone과 비슷하므로 만약 Backbone을 사용해 본 적이 있다면 적응하기도 쉽습니다. 참고로 아래에 여러 MVC프레임워크를 소개하고 장/단점을 분석한 사이트의 링크를 달아두었는데 여타의 프레임워크보다 더 좋은 점수를 받기도 하였습니다.Backbone 말고 다른 MVC프레임워크를 원한다면, 특히 자체 템플레이트 라이브러리를 지원하는 프레임워크를 원한다면, Ember.js 사용을 고려해 보는 것이 어떨까요?더 읽어볼 만 한 것An Intro to Backbone.jsBackbone.js by exampleBackbone Tutorials위의 사이트들은 제가 Backbone을 공부하면서 참고한 사이트들입니다. 영문 사이트이지만 코드만 훑어 봐도 그 의도와 얼개는 파악할 수 있을 것으로 생각합니다. Backbone 공식 사이트에서 제공하는 튜토리얼 사이트도 방문해볼 가치가 있습니다. Backbone을 이용하여 개발한 간단한 서비스의 소스코드를 공개해 놓았습니다.The Top 10 Javascript MVC Frameworks ReviewedJourney Through The JavaScript MVC Jungle위 두 사이트에서는 앞서서 소개한 Backbone과 Ember.js 외의 여러 MV*패턴 프레임워크를 소개하고 장단점에 대하여 분석해놓았습니다.마치며이상으로 Backbone 도입과 그에 따르는 장점을 살펴보았습니다. 일반적인 홈페이지와 제작과는 약간 양상이 다른 웹플리케이션(웹 + 애플리케이션)개발자 분들은 프로젝트에 MVC 패턴 프레임워크를 적용해 보면 어떨까 하는 생각이 듭니다. 프로젝트의 생산성에 크게 이바지할 수 있으리라 생각됩니다.#스포카 #개발 #개발자 #인사이트 #Backbone #일지 #개발팀

“매일매일 새로운 도전으로 채워지는 자리” – 패스트캠퍼스에서 일하는 콘텐츠 마케터 이야기“마케팅 중 유효한 것은 콘텐츠 마케팅 뿐이다.” – 세스 고딘<보랏빛 소가 온다>를 쓴 세계적인 마케팅 구루 세스 고딘의 말처럼 콘텐츠 마케팅은 마케팅의 주류로 자리잡으며 전통적인 광고의 입지를 위협하고 있습니다. 그런데 콘텐츠 마케팅은 범주가 넓어 기업 특성에 따라 실무에서 담당하는 업무가 다양한데요. 이번 글에서는 패스트캠퍼스의 콘텐츠 마케터들은 무슨 일을 어떻게 하는지 자세히 알려드리고자 프로그래밍팀 시니어 콘텐츠 마케터 김하림님과 파이낸스팀 콘텐츠 마케터 이유나님을 모시고 인터뷰를 진행했습니다.안녕하세요 하림님 유나님, 오늘 인터뷰에 응해 주셔서 감사합니다. 간단하게 자기소개 부탁드려도 될까요? 안녕하세요, 프로그래밍팀 시니어 콘텐츠 마케터 김하림입니다. 지난주에 막 입사한 지 1년이 되었어요.안녕하세요, 저는 파이낸스팀 콘텐츠 마케터 이유나라고 합니다. 패스트캠퍼스에서 일한 지 이제 9개월 째고요. 두 분께서는 패스트캠퍼스에 합류하기 전 무슨 일을 하셨는지, 어떤 계기로 패스트캠퍼스 콘텐츠 마케터로 입사하게 되셨는지 궁금합니다. 패스트캠퍼스에 오기 전에는 웹디자인 일을 하고 있었는데, 회사 규모가 작아 세금계산서 발행부터 제안서 작성까지 회사 운영의 전과정에 참여해야 하다 보니 웹디자인에만 몰두할 수 있는 환경은 아니었어요. 전문성을 가지고 한 가지 일에 좀 더 집중하고 싶어 회사를 그만두었습니다. 그러다 채용공고를 살펴보던 중 패스트캠퍼스의 콘텐츠 매니저(지금은 콘텐츠 마케터로 직함이 바뀌었죠) 자리를 발견하게 되었고요. 제가 할 수 있는 다양한 일들을 업무 역량으로 발휘할 수 있을 것 같아 지원했어요. 저는 지금 마지막 학기를 보내고 있는 대학생이에요. 경영을 전공했고, 교육 분야에도 관심이 있어 국어교육학과를 복수전공하고 있었어요. 제가 흥미를 느낀 이 두 분야를 접목해 할 수 있는 일을 찾다 교육업에 있는 마케터 일이 저에게 딱 맞을 것 같아 지원서를 넣었던 기억이 납니다. 인턴으로 입사했다 정직원으로도 계속해서 함께하는 중이예요. 유나님께서는 인턴 기간이 종료된 후에도 이곳에서 일하고 계신데, 패스트캠퍼스를 선택하신 이유가 무엇일까요? 패스트캠퍼스에서는 인턴이라도 정직원과 같은 일을 하면서 눈치 보지 않고 자기 의견을 낼 수 있던 것이 좋았어요. 저에게는 자기발전을 계속할 수 있는지가 직업을 선택할 때 중요한 기준인데 여기에 맞고, 사회 초년생으로서 일을 배우기에도 좋은 환경인 것 같아 정직원으로 계속 일하고 있습니다. 제가 막 입사했을 때, 당시 팀장님께서 제 직무에 대해 설명해주셨던 것이 기억에 남아요. “프로덕트 매니저가 오프라인에서 기획을 하는 사람이면 콘텐츠 마케터는 온라인에서 기획을 하는 사람이다”라는 말이었는데 저희는 고객분들이 온라인에서 접하는 모든 콘텐츠를 기획·제작하고 글을 쓰는 만큼 일리가 있는 것 같아요. 기획자, 제작자, 에디터의 역량을 모두 발휘해야 하는 사람이 콘텐츠 마케터라고 생각합니다. 하림님의 말씀에 더해, 우리 회사 콘텐츠 마케터가 맡는 특별한 일 중 하나는 상세페이지를 기획 및 디자인해 고객을 설득하는 글쓰기를 한다는 것이에요. 마케터라 하면 광고 크리에이티브를 제작하는 데 업무의 초점이 맞춰져 있다는 느낌이지만, 여기서는 기획 역량까지 발휘해야 하는 점이 특징이죠. 콘텐츠 마케터로서 다양한 일을 하고 계시는데, 어느 정도 정해진 일과가 있을까요? 하루 일과를 딱 잘라서 말하긴 어렵습니다. 그때그때 담당하는 일의 중요도가 달라져서요. 우선 프로덕트 매니저 분이 새로운 강의 기획을 완성하시면 신규 상세페이지를 제작하고, 기존 강의를 업그레이드해 오시면 그에 맞게 기존 상세페이지의 내용을 수정합니다. 홍보 진행이 원활하지 않으면 팀원들과 트러블 슈팅을 통해 상세페이지나 광고 크리에이티브를 손보기도 하고 강사 인터뷰, 수강생 인터뷰 혹은 블로그 게시물이나 카드뉴스 형태의 오가닉 콘텐츠를 발행하기도 합니다. 업무 진행에 있어 큰 틀은 있겠지만 그때그때 업무의 우선순위가 달라져요. 일이 많아 야근할 때도 종종 있고요. 패스트캠퍼스 콘텐츠 마케터 직무, 입사 전 생각했던 것과 실무를 진행하는 것에 차이가 있나요? 저는 비슷한 것 같아요. 간단한 퍼블리싱, 마크업(HTML/CSS로 코딩을 하는 것)을 할 수 있는 사람으로서 이런 스킬들이 상세페이지 제작 업무에 도움이 될 거라고 생각했거든요. 입사 전 필수적으로 갖춰야 할 스킬은 아니었지만 업무를 진행하다 보니 마크업을 알아서 더 도움이 되는 게 많았어요. 그런데… 트러블 슈팅이 이렇게 많을 줄은 몰랐네요. 하하. 저는 하림님과 반대예요. 콘텐츠 마케팅이 이렇게까지 다양한 능력을 요구하는 일인 줄 전혀 몰랐어요. 업무 스킬은 물론 담당하는 강의에 대한 지식적인 부분까지도요. 깊게 파고들 필요는 없지만 얕고 넓은 지식이 필요한 일이더라고요.물론 하림님처럼 업무와 관련된 스킬을 가지고 입사하시면 실무에 확실히 도움 되는 부분이 있어요. 포토샵이나 HTML/CSS 같은 것들요. 하지만 저의 경우에는 포토샵도 못 다룰 만큼 아무것도 모르는 상태로 일을 시작했는데도 필요한 것들을 배워 가며 일할 수 있는 환경이라 괜찮았어요. 그 과정에서 성장하고 있는걸 스스로도 느낄 정도에요.지금 패스트캠퍼스에서는 프로그래밍, 데이터 사이언스, 마케팅, 외국어 등 다양한 팀에서 콘텐츠 마케터를 채용 중인데요. 팀별로 콘텐츠 마케터가 갖춰야 할 배경지식, 선호하는 스킬셋이 다를까요? 크게 차이는 없는 것 같아요. 합류하는 팀에 따라 만들게 되는 콘텐츠의 성격은 달라질 수 있지만 배경지식이 필수는 아니거든요. 프로덕트 매니저 분들이 작성하신 기획 문서를 읽고 핵심이 되는 부분을 짚어 콘텐츠로 만들어낼 수 있으면 됩니다. 이해하기 어려운 부분은 프로덕트 매니저 분들께 물어보면 어느 팀에서건 친절하게 알려주실 거예요. 맞아요. 저도 파이낸스 분야를 공부하며 콘텐츠를 만들고 있는데, 아는 게 점점 많아지고 있는 것 같아 뿌듯합니다. 콘텐츠 마케터는 끊임없이 새로운 것들을 배워야 하는 직무 같은데요. 패스트캠퍼스에서 콘텐츠 마케터로 일하며 가장 힘든 점은 무엇인지 솔직하게 말씀해 주신다면? 하나의 콘텐츠에 오랜 시간을 투입할 수 없는 점? 일주일에 새로운 상세페이지를 세 개씩 만들 때도 있다 보니 한 가지 업무만 집중해서 파고들 시간적 여유가 없어요. 특히 트러블 슈팅이 많이 발생하다 보면 업무 시간이 절대적으로 부족하죠. 유나님 말씀에 더해, 강의마다 특징을 가장 잘 보여줄 수 있는 상세페이지를 만들기 위해 고민하는 게 재밌으면서도 어려운 일 같아요. 이런 부분에 대해 어떤 도움을 드릴 수 있을까 다른 시니어 분들과 함께 고민 중이고요. 그리고 솔직히 말하자면, 일이 정말 많아요. 그게 제일 힘들죠. 업무 과다로 고생이 많으신데, 힘든 점들이 있음에도 이 일을 계속하게 만드는 원동력은 무엇인가요? 일은 많지만 업무 방식에 제한은 없어서 이것저것 새로운 시도를 해 볼 여지가 있다는 게 좋아요. 상세페이지를 수정했거나 새로운 광고 크리에이티브를 만들었는데 효율이 좋다거나, 오가닉 콘텐츠를 발행했는데 커뮤니티 등에 업로드되는 등 좋은 반응을 얻었다거나 하면 보람도 있고요. 틀에 박힌 일을 하지 않는다는 점이 재밌어요. 맞아요. 새로운 시도에 대한 제재가 없으니 할 수 있는 게 많아서 좋죠. 성과에 따른 연봉협상도 유연하게 이뤄지고요. 어떤 콘텐츠 마케터를 동료로 맞이하고 싶으신지 궁금합니다. 새로운 시도에 대한 거리낌이 없으신 분. 새로운 일이 주어졌을 때 ‘저는 이거 못하겠어요’가 아니라 ‘이것도 저것도 해 볼게요’라고 말할 수 있는 분! 팀원들과 협업을 잘할 수 있는 분. 프로덕트 매니저, 퍼포먼스 마케터의 의견을 반영해 콘텐츠를 제작하고 배포하기 때문에 커뮤니케이션 능력이 좋다면 일을 잘할 수 있을 것 같아요. 거기에 하나 더, 자신의 의견만 고집하기보다 다른 사람의 의견을 잘 받아들일 수 있는 분. 서로의 잘잘못을 따지기보다 더 나은 방향을 위해 협업하고 있다는 걸 잊지 않는 분이면 좋겠어요. 쓰는 걸 두려워하지 않는 분이면 정말 좋고요. 맞아요. 포토샵이나 워드프레스 스킬들은 모르셔도 괜찮아요. 저희가 알려드릴게요! 마지막 질문입니다. 두 분께 패스트캠퍼스란 어떤 곳일까요? 매일매일 변화무쌍한 곳. 틀에 박힌 일을 하지 않아요. 오늘, 지금입니다. 오늘이 쌓여서 내일이 되고 매일이 되는데, 그 오늘이 매일매일 새로워요.* 패스트캠퍼스 콘텐츠 마케터는? *  패스트캠퍼스 고객들이 접하게 되는 모든 접점을 컨트롤하는 역할을 담당합니다. 기획 과정에 참여하는 것은 물론 교육 콘텐츠 상세페이지를 제작하고, 매력적인 광고 크리에이티브를 만들고, 강사와 수강생들의 목소리를 전달하기도 합니다. 즉, 패스트캠퍼스에서 만들어지는 모든 콘텐츠의 외모를 결정하고 그 톤앤매너를 관리합니다.