스토리 홈

인터뷰

피드

뉴스

조회수 2089

Interview - Android App Developer 박형일님

크래커나인 팀에서는 사용자의 의견을 적극 반영하기 위해서 안드로이드 개발자 박형일님의 크래커나인 사용기 인터뷰를 해보았습니다.개발자 박형일님본인 소개를 부탁 드려요~저는 에이치나인에서 안드로이드 개발 파트를 담당하고 있는 박형일 입니다. 개발 경력은 12년 정도 됐구요.에이치나인에 입사한지는 4년 정도 됐습니다. 주로 외주 안드로이드 앱 개발 업무를 하고 있습니다.개발일을 꽤 오래 하셨네요. 시니어 개발자들은 코드를 직접 작성하는 것을 선호 하시는 것 같던데, 형일님은 어떠신가요?저도 코드를 직접 작성하는 것을 선호 하는 편입니다. 툴에서 생성되는 코드를 별로 신뢰하지 않아요. 제가 원하는 대로 안 나온다는 느낌을 많이 받거든요.그럼 크래커나인의 첫인상은 어떠셨나요? GUI 로 부터 코드를 생성해 주는 툴인데..처음엔 아이디어는 괜찮은데, 이게 과연 제대로 된 코드를 생성 해 줄까? 라는 의심이 들었죠. 꼭 사용 해 보고 싶은 프로그램은 아니었어요.크래커나인을 사용하신지는 얼마나 되셨죠?올해 6월쯤에 처음 접하여 2달 정도 된 같아요.어떤 프로젝트에 적용 해 보셨나요?회사에서 회의실 예약 시스템이 필요하다고 해서 회의실 예약 앱을 만들었어요.그 때 처음 사용 했죠. 공식 프로젝트가 아니라 디자이너 없이 웹에서 무료로 사용할 수 있는 Sketch 파일로 된 디자인 샘플을 받아서 혼자서 만들었어요.앱을 구성하는 화면은 대략 5~6개 정도로 간단한 프로젝트여서 가능 했죠. 지금은 외주 과제를 하고 있는데, 크래커나인을 사용 해서 하고 있어요.외주 같으면 주로 파워포인트로 작성된 GUI 가이드라인 문서를 보고 개발 하잖아요. 크래커나인을 사용하기 전에는 디자이너와 무엇을 통해서 개발에 필요한 디자인 정보를 얻으셨어요? 에이치나인에 있으면서 거의 대부분 GUI 가이드라인 문서를 보고 개발 했죠. 최근에 다른 프로젝트 팀에서 GUI 가이드라인 문서 없이 제플린을 쓰더라구요. 그래서 그것도 조금 써봤어요.제플린과 같은 기존의 유사 서비스와 비교해서 크래커나인은 어땠나요?GUI 가이드라인 문서를 보면서 개발을 하다 제플린을 써보니까 너무 편리하더라구요. 문서에서 원하는 정보 찾는게 불편했거든요.그래서 사실 처음 크래커나인을 사용 했을 때는 제플린과 큰 차이를 못 느꼈어요.근데 프로젝트를 진행 하다 보니 크래커나인의 코드 생성 기능이 있어서 좀 더 편리하다고 느껴지는 순간이 오더라구요. 제플린을 보고 개발 할 때는 코드나 수치를 직접 입력하다 보니 실수를 할 때도 있었고, 여전히 XML 작성하는 수고로움이 남아 있었거든요.근데 크래커나인의 레이아웃 코드 생성 기능을 사용해서 나온 XML 코드가 100% 는 아니지만 70~80%는 작업을 안해도 될 수준이더라구요. 그래서 XML 작성하는데 들이는 시간이 많이 줄어 들었어요.크래커나인을 익히는데 어렵지는 않으셨어요?타 서비스를 사용한 경험이 있어서 많은 부분 기능을 따로 매뉴얼로 보지 않아도 파악이 됐는데요.사용하는데 크게 문제는 없었던 거 같아요. 직관적으로 파악이 안 되는 기능은 사용하지 못한 것 같지만 따로 매뉴얼은 찾아보지 않았습니다.Cracker9의 어떤 기능이 가장 편리하셨나요?당연히 레이아웃 코드 자동 생성 기능이었습니다.손으로 직접 코딩 하지 않고 View들의 관계를 맺으면 자동으로 View의 관계와 속성을 xml 코드로 생성해주는 기능이 개발하는 데에 상당히 많은 도움이 되었습니다.Cracker9을 사용하면서 불편했던 점이나 개선했으면 하는 부분이 있었나요?Asset 이름이나 리소스(문자열, drawable) 이름이 해쉬값이나 text1, text2 이런 식으로 되어 있어 나중에 다 변경을 해 주어야 되었습니다. 이 부분은 개선이 되었으면 좋겠습니다.※ 위의 내용은 Cracker9 0.9.5 에서 개선되었습니다.Cracker9의 정식 버전으로 출시가 되면 사용할 의향이 있으신가요?네, 사용할 것 같아요. 가격만 너무 비싸지 않으면 전 무조건 사용하겠습니다.App을 만들거나 디자이너와 소통해야 하는 다른 개발자들에게 알려주고 싶은 Cracker9 사용 Tip이 있다면 알려주세요~디자이너가 텍스트나 이미지 단위로 View를 만드는데요. 개발자가 원하는 모든 View를 만들진 않기 때문에 Custom Layout 활용은 필수입니다.Custom Layout을 잘 활용하시면 원하시는 레이아웃 작업이 모두 가능합니다. 그리고, 오른쪽에 Tree Structure 패널이 있는데요.View의 트리 구조 순서로 레이아웃 xml 코드가 생성되기 때문에 어떻게 코드가 만들어질지 예상할 수 있어요. 물론 View의 순서나 부모/자식 관계는 마우스 드래그로 편집할 수 있습니다.마지막으로 Constraint Layout의 관계를 맺을 때, View가 작으면 정확하게 클릭하여 작업하기 어려울 수 있는데요. 당연하지만 View를 확대해서 연결 지으면 쉽게 작업할 수 있습니다.마지막으로 Cracker9에게 한 말씀해주세요~저는 안드로이드 App을 개발하면서 레이아웃 작업은 초반에 하는 시간 잡아먹는 노가다 작업이라고 생각을 했는데요.레이아웃을 자동으로 생성해주는 Cracker9을 사용하면서 더 이상 노가다라는 생각을 하지 않게 되었습니다. 아직은 Beta 버전이라 부족한 부분이 보이지만, 개선될 것이라고 믿고 계속 사용할 거 같아요.앞으로 발전하는 모습 기대하겠습니다 파이팅!#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑
조회수 2482

데이블 주니어 개발자 직무 인터뷰

오후 두 시의 회의실. 개발자들의 스터디하는 소리로 뜨겁다. 국내 최고의 추천 기술을 보유했다는 데이블. 10년 이상의 경력을 가진 노련한 시니어 개발자들 사이에서, 스쳐 지나가는 단어 하나하나 놓치지 않으려 귀 기울이고 있는 주니어 개발자들을 만났다.안녕하세요? 간략한 소개와 두 분의 업무에 관해 설명해주세요.형주: 안녕하세요? 저는 데이블 개발팀 최형주입니다.저는 백앤드 개발팀의 신입 개발자로서 데이블의 인프라 관리, 백앤드 개발 그리고 가끔 데이터 분석을 하고 있습니다. 주로 사용하는 서버는 클라우드 플랫폼인 AWS(Amazon Web Service)과 Nodejs 이고, MySQL, Redshift, Python을 사용하여 데이터 처리와 분석을 하고 있어요.성현: 안녕하세요. 저는 데이블 개발팀 이성현입니다.제 메인 업무는 데이블 위젯의 스타일링과 관련 문제 해결입니다. 고객사 페이지를 분석해서 위젯 디자인을 만들고, 추천 결과가 안 나오는 경우에 문제를 수정하는 작업입니다. 특별한 기능이 필요한 위젯이 있으면 스크립트 작업도 하고요. 작업 도구는 회사 내부 시스템이 있어서 그 안에서 직접 작업하고, CSS로 작성합니다.위 업무가 메인이지만 다른 영역과 겹칠 때도 잦아서 회사에서 사용하는 여러 시스템을 만질 수 있어야 합니다. 도구는Html+CSS+js 외에 Node, gulp, react, angular angularJS, PHP, 젠킨스, AWS, MYSQL, git를 사용하고 있습니다.두 분 다 신입 개발자이신 만큼 회사를 선택하는 데 있어 신중했을 것 같아요.데이블을 선택한 이유는 무엇인가요?형주:  저는 대학원에서 빅데이터 처리관련 연구를 주로 했었어요. 졸업할 때쯤 제 전공과 관련된 회사에 지원했었고 많은 면접을 보았습니다. 여러 회사에서 면접을 봤지만 데이블에서 봤던 면접 경험이 만족스러웠고 특히 개발자들의 실력과 내공이 느껴져 신입으로서 많은 것을 배우고 싶어서 입사하게 되었습니다. 복지 또한 여느 알려진 회사들에 비해 부족하지 않아서 굉장히 만족하고 있습니다.성현: 처음 데이블에 호감을 느끼게 된 건 기술 중심 스타트업이라는 점이었습니다. 도전하는 자세, 유연한 사고, 성장 가능성, 복지 등 여러 가지 기준들이 있겠지만, 내가 재미를 느낄 수 있는가, 개발자로서의 성장 이 두 가지로 압축되었어요. 저 같은 경우에는 블로그를 보면서 회사 분위기를 대략 파악했던 것 같네요. 자유로운 분위기도 잘 느껴지고, 서로를 배려하면서 열심히 일하는 것을 간접적으로 경험할 수 있었어요. 면접 보러 갔을 때, 블로그에서 보던 사람들이 블로그 글과 비슷한 느낌으로 편하게 얘기하는 걸 보면서 마음을 굳히게 됐어요.데이블의 분위기는 어떤가요?형주: 분위기는 실제로 굉장히 수평적입니다. 서로 존댓말을 사용해서 존중받는 기분이 들어요.성현: 저는 데이블 오기 전에 잠시 다른 회사에 있었는데, 거기서는 과한 예절이나 눈치를 보는 분위기가 있었어요. 데이블은 수평적인 분위기이다 보니 스트레스 받지 않고 일에 집중할 수 있어 좋아요.형주: 저 같은 경우, 잠에 굉장히 민감한 편인데 출퇴근이 탄력적이어서 지각에 대한 스트레스가 없어서 좋아요. 그래서 저는 보통 9시 넘어서 일어나서 10시쯤 출근하고 7시쯤 퇴근하는 편입니다. 그리고 식대도 지원해주고 있어요~성현: 매일 4시쯤 회사가 지원하는 간식 타임이 있어요. 오랜 시간 앉아서 일하다 보면 집중력 떨어질 때 쯤 다 같이 모여 대화를 나누면서 간식을 같이 먹습니다. 만약 생일이 있으면 간식 타임과 더불어 생일 파티를 해요.형주: 간식과 음료수가 항상 냉장고에 갖춰져 있어서 먹을 것을 좋아하는 사람에게 최고인 것 같아요. 저는 살이 잘 안 찌는 체질인데 입사 후 2킬로가 쪘어요.성현: 거의 슬랙과 트렐로 위주로 업무를 하는데 간식 타임에는 여러 사람과 대화를 할 수 있어 좋습니다. 서로 대화도 같이하고, 같이 활동할 수 있는 시간을 마련하기 위해 ‘플레이 데이’ 도 2개월에 한 번씩 열고 있어요! 회사-집, 집-회사를 반복하다가 다 같이 뭔가를 하니 신선했어요. 업무 외적으로 같이 활동하면서 사람들과 친밀감을 느낄 수 있어서 좋았어요.데이블을 선택했던 이유 중 개발자로서 성장 가능성도 있었는데 이것은 어떻게 채워지고 있나요?성현: Dabler, Be The Expert 프로그램(이하 BTE 프로그램)이 있고 업무 관련 스터디도 활발히 진행하고 있어요.자세히 설명해주세요. 성현: BTE 프로그램의 경우 장기목표를 정하고 반기별로 관련 학습 계획을 세워요. 그 안에서 책도 사고 강의도 신청하고 하는 거지요. 스스로 목표를 잡고 자유롭게 계획을 세울 수 있어서 좋아요. 본인이 정말 원하는 것을 배울 수 있고, 필요한 자금은 회사가 지원하는 거죠. 단, 업무에 관련된 성장 계획이어야 한다는 가이드라인이 있어요.이 외에도 백엔드 개발자들과 함께 AWS 사용법을 주제로 스터디도 해요! 보통 프론트엔드를 담당하지만, 백엔드 영역도 경험할 수 있어요. 본인 스스로 영역을 넓히기 위해 공부하고 능력이 된다면 활동 범위가 굉장히 넓어져요. 회사 차원에서도 그런 시도를 장려해요. 빨리 성장해야겠다는 욕심이 있어요.형주: 전 회사에서 일주일에 2번 모여서 스터디도 하고 있고 MOOC 강의를 수강하거나 책을 사고 싶을 때 눈치 볼 필요 없이 신청하면 돼요. 그리고 반기별로 자기 개발을 잘한 직원에게 인센티브를 줘요.※BTE 프로그램이란?그럼 두 분은 BTE 프로그램을 통해 어떤 것들을 배우고 계시는가요?형주: 저는 Coursera에서 Recommender System 수업을 듣고 있어요. 아무래도 우리 회사의 핵심기술이 추천 기술이다 보니까 이쪽 분야를 깊게 공부해야겠다는 생각이 들었습니다.성현: 저는 웹을 능숙하게 다루고 싶어서 상반기에는 인프라, 자바스크립트, 웹 표준, node 등 기본을 다시 챙기고 하반기에는 웹 최신 기술을 공부하려고 해요.지금은 자바스크립트 관련 책 3권과 강의 2개를 신청해서 주로 퇴근 후 또는 주말에 듣고 있어요. 업무와 관련된 것을 공부하고 나서 코드를 작성하면 대충 넘어갔던 부분들이 보여요. 그 부분을 놓치지 않고 수정하고 개선하다 보면 예전보다 나은 결과물이 나오고 뭔가 아는 게 늘었구나! 하는 보람을 느낍니다.데이블에서 개발자로 일하며 느끼는 점형주: 저의 경우에는 신입 개발자 관점에서 경험 많은 개발자분의 피드백을 통해 노하우를 전수하는 점이 좋았어요. 그러면서 기존에 놓치고 있던 부분이나 실무와 이론 사이의 괴리감을 좁히는 경험이었습니다. 저도 학부, 대학원 시절 많은 코딩을 했지만 제가 작성한 코드가 잘 작성된 코드인지 잘 읽히는 코드인지는 스스로 공부하기 힘들었는데 이러한 피드백을 통해 성장함을 느꼈습니다.어려웠던 점은 우리 회사는 애드테크 회사이다 보니 광고 용어를 굉장히 많이 사용하는데 광고에 관해 얘기할 때 처음에는 광고 용어를 몰라 답답했었는데, 스터디를 만들어서 어려운 점을 조금은 해소할 수 있었어요.성현: 자기만 할 수 있으면 얼마든지 여러 프로젝트에 참여할 수 있는 문화가 좋아요. 예를 들면 저는 위젯 담당이지만, 위젯 업무 틈틈이 데이블 시스템 페이지 수정을 할 수도 있고 내부 DB를 이용해서 사업팀에게 도움이 되는 통계 페이지를 만들기도 해요. 얼마 전에는 커뮤니티에 데이블 추천 기능을 직접 넣는 프로젝트를 했습니다. 보통 추천 연동은 고객사가 하고 저는 위젯만 만들고 있었거든요. 이번에 고객사 입장에서 서버 쪽을 만져본 거죠.미래의 데이블은 어떤 모습일까요?형주, 성현: 세계 No. 1 콘텐츠 디스커버리 플랫폼! 경영진이 자기 개발 지원이나 복지에 신경을 많이 쓰고 있어서 계속 나아질 것 같아요.데이블의 개발자가 되기 위해 어떤 것들이 필요할까요?형주: 제가 생각하기에 시니어 개발자분들이 가장 중요하게 여기는 부분은 CS 분야의 기본기였던 것 같습니다. 이 기본기를 통해 자주 사용하는 툴이나 오픈 소스가 내부적으로 어떻게 구성되어 있고 동작하는지에 대한 공부를 하면 도움이 될 것 같습니다.성현: 저는 주도적인 자세요! 스스로 일하고 배우는 자세가 필요합니다. 다른 개발자와 소통하면서도 자기 일의 진행 관리나 조율은 스스로 해야 해요. 다음 일을 직접 찾아야 할 때도 있고요. 또 전부를 물어볼 수는 없으니 어느 정도 혼자 찾아 공부하는 습관도 필요해요. 그리고 자기가 지원하는 포지션에서 사용하는 핵심 기술 하나는 능숙하게 사용할 수 있어야 해요. #데이블 #팀원 #개발자 #개발팀 #개발 #팀원소개 #인터뷰 #기업문화
조회수 1427

샌프란시스코 테크 업계 인터뷰 2: Bleacher Report, Udemy, Intuit

이 포스팅은 2개의 글로 구성된 시리즈 중 2번째 글입니다. 이전 글을 읽으려면 “샌프란시스코 테크 업계 인터뷰 1: Facebook, Fivestars”로 이동하세요.  안녕하세요, 스포카 프로덕트 매니저 옥지혜입니다.  제품을 담당하는 팀이 일하는 방식은 제품 그 자체에 영향을 줍니다. 어떠한 기능을 어떤 주기로 사용자에 배포할 것이냐에 대한 결정을 하는 과정이기 때문입니다. 그뿐만 아니라 정성적인 차원에서 새로운 기능을 개발하거나 운영하는 일 등을 조직이 어떻게 평가하느냐에 따라 작업자의 업무 만족도와 작업물의 품질에도 영향을 미칩니다.  구태의연한 말이지만 테크 업계에서 일하는 방식에 있어 정답은 없습니다. 제품과 조직은 끊임없이 변화하고 이에 맞추어 일하는 방식도 바뀌어야 하므로 지난해에 불합리하다고 여기던 방식이 올해는 검토해 볼 만한 것이 될 수도 있습니다. 일하는 방식 그 자체도 협의를 거쳐 지속적으로 개선하는 과정이 필요합니다.  일하는 방식과 함께 제품과 조직마다 프로덕트 매니저의 역할과 권한도 바뀝니다. 비즈니스에 제품이 기여하는 정도에서부터 조직 내 이해관계자와의 관계까지 제품과 조직의 모든 요소가 프로덕트 매니저가 일하는 방식에 영향을 미칩니다. 스포카 프로덕트 매니저의 경우, 서비스 백로그 관리의 역할도 담당하기 때문에 유동적으로 일하는 방식에 따른 결과는 제품에 다시금 반영됩니다.  이번 샌프란시스코 테크 업계 인터뷰는 위와 같은 가정하에 ‘스포카는 앞으로 어떤 방식으로 일할 것인가’라는 질문에 대한 참고할 사례를 수집하기 위하여 진행하였습니다. 닭과 계란 문제일 수 있지만, 이것은 ‘스포카는 어떤 제품을 만들고자 하는가’하는 고민과 맞닿아 있습니다.  인터뷰는 총 5회에 걸쳐 아래의 PM 분들과 진행하었습니다. 흔쾌히 인터뷰에 응해 주신 모든 분께 감사드립니다. 각 인터뷰이와 나눈 이야기 중 인상적이었던 부분을 발췌하여 2개의 포스팅에 걸쳐 공유하겠습니다. Stephanie Shum(Director Product Management at Facebook)   David Park (Refereum COO)Michael Hsu (Product Manager at FiveStars)Chris Nguyen (VP Product at Bleacher Report)홍성철 (Product Manager at Udemy)정대영 (Product Manager at Intuit)    Chris Nguyen (VP Product at Bleacher Report)        현재 담당하고 있는 팀은 어떻게 구성되어 있나요?  C: 초기에는 직무 단위로 팀을 구성하였다. 현재는 전략에 맞도록 제품 단위의 스쿼드로 구성을 변경했다. 제품 팀은 전체적으로 디렉터 2명, 시니어 PM 2명, 주니어 PM 2명과 디자이너 7명으로 구성되어 있다. PM 1명 당 디자이너 1.5명의 비율을 유지하려고 한다. 보다 구체적인 수준으로 아이디어를 디벨롭하기 위해서이다. 엔지니어는 50명 규모로까지 충원하는 것을 목표로 하고 있다.  PM은 팀에서 어떤 역할을 하나요?  C: 스프린트를 안정적으로 운영하기 위해서 말 그대로 할 수 있는 일은 모두 도맡아서 했다. 점차로 팀이 커지면서 제품과 팀이 어떤 우선순위를 가지고 움직일지 트래킹하는 데에 집중하려고 노력했다. 우선순위를 지킬 수 있도록 스프린트를 계획하고 계획대로 일이 진행될 수 있도록 챙기는 역할에 집중했다. 실제 배포를 위한 역할이 이와 같다면, 서비스 전략 관점에서는 중요한 결정사항이 타당했는가에 대하여 결정 이후에도 자주 점검했다. 또 제품 팀의 KPI를 정확하게 측정하고 제품 팀에서 하는 모든 일이 KPI를 달성하였는지 검토했다.  PM으로서 제품 팀에 동기부여를 어떻게 하나요?  C: PM의 가장 중요한 역할 중 하나는 ‘왜 이 일을 해야 하는가’에 대하여 끊임없이 설명하는 것이다. 목표와 이를 달성하기 위해 해야 하는 일을 문서화하고 이것이 실제로 팀에서 할 수 있는 일이라는 것을 다양한 방식으로 팀에 전파한다. PM이 주로 조직과 제품에 대한 다양한 정보를 취득하게 되므로 팀 내에 이를 지속적으로 공유하는 것 역시 중요하다. (운영 업무에 대한 동기부여는 어떻게 하나요?) 서비스가 성장하고 시간이 흐를수록 기술 부채가 쌓이기 마련이다. 신규 기능에 대한 요구사항과 기술 부채 삭감을 위한 작업의 무게를 맞추는 역할도 PM의 몫이다. 팀에서 담당하는 가시화되지 않는 업무를 지적하여 마땅한 보상을 받게 하는 것이 좋은 방법이라고 생각한다.    홍성철 (Product Manager at Udemy)        PM의 역할 중 무엇이 가장 중요할까요?  홍: PM은 완성도 있는 제품을 제때 배포할 수 있는지가 가장 중요하다. Udemy의 경우, 서비스에 기술적인 오류가 있을 때 책임을 PM이 지게 하여 제품의 기술적인 영역에 집중하도록 유도한다. PM은 제품의 연 단위 목표를 수립하고 분기 단위로 쪼개진 목표를 실제로 달성할 수 있도록 2주 단위 스프린트를 운영하는 사람이다. (제품 팀이 목표지향적으로 일하기 위해 어떤 장치를 두나요?) 모든 기능의 제안은 원 페이지 기획서로 시작한다. 이 기획서에 해당 기능을 왜 지금 만들어야 하는지에 관해서 설명하게 한다. 이외에도 반드시 팀 비전과 목표에 각각의 기능이 어떻게 기여하는지도 적도록 요청한다. 기능을 제안하는 모든 팀은 이 문서를 작성하여 그것을 기반으로 백로그 조정을 진행한다.  유관부서 요구사항의 우선순위 조율과 디벨롭에 있어서 팁이 있나요?  홍: 기능을 제안한 배경이 되는 문제를 명확하게 정의해야 불필요한 커뮤니케이션을 줄일 수 있다. 아울러 특정 기능의 진행 우선순위를 높이면서 다른 기능의 우선순위가 내려간다는 점을 강조하여야 한다. 모든 커뮤니케이션의 기본은 그것이 협상의 성격을 띤다는 점이다. 개발 팀과의 커뮤니케이션도 협상이다. 이를테면 커뮤니케이션 스킬이 뛰어난 프로그래머와 협업하는 경우, 어떠한 예외 케이스가 있는지와 이에 대하여 대응할 때 검토할 수 있는 옵션을 제시할 수 있어 효과적으로 일할 수 있다. 개발 팀 외부 조직은 제품의 기술적인 영역에 직접 관여할 수 없다. 따라서 어떤 프로그래머가 개발 팀의 리더인지에 따라 협의 결과에 큰 차이를 가져올 수 있다.  컴퓨터 공학에 대한 사전 지식의 유무 또는 한국인이라는 점이 샌프란시스코에서 PM으로 일하는 데 영향을 미친다고 생각하나요?  홍: 재학 중에 시스템 디자인 엔지니어링을 배웠다. PM으로서의 업무 경험이 쌓이면서 테크니컬 배경 유무에 따른 차이가 갈수록 작아진다. 경력 초반에 개발 팀의 업무에 공감할 수 있는 범위와 정도의 차이에 영향을 주었고 시간이 갈수록 차이가 작아졌다. 모바일 앱 시장 초기 단계에는 빠른 출시가 중요하므로 공학 배경이 있는 사람을 업계에서 선호했다. 시장 성숙도가 올라가면서 현재는 트렌드가 바뀌었다. 샌프란시스코에 일하는 한국인 PM은 MBA 출신이 대다수이고 다양한 문화적 배경을 가진 사람이 업계에 많으므로 이 또한 크게 문제는 되지 않는다. 적극적인 태도와 뛰어난 업무 능력이 있다면 적응하는 데에 어려움은 없다고 생각한다.    정대영 (Product Manager at Intuit)        기능에 대한 요구사항은 어떻게 발굴하나요?  정: 발의하는 주체에 따라 크게 2가지 카테고리로 구분할 수 있다. 외부에서 발생하는 요구사항의 경우, 사용자의 제안 또는 리서치를 통해 발굴할 수 있다. 내부에서 발생하는 요구사항의 경우, 사용자 관점에서 서비스 개선사항을 직접 찾아낸다. 이후에 프로젝트를 만들고 프로토타이핑하여 A/B 테스트를 진행한다. 제품 팀 - PM, 디자이너, 엔지니어 - 모두 개선사항을 찾는 과정에 참여한다. 제품의 목표는 탑다운으로 제시될 수 있으나 실제 액션 아이템에 대한 결정은 실무 단에서 가장 비즈니스 임팩트를 줄 수 있는 기능을 정한다. 기존 백로그의 우선순위에 영향을 주는 기능 요구사항이 있을 경우, 명확한 기준을 근거로 투명한 의사결정을 거쳐 우선순위를 결정한다. 이는 모든 요구사항이 협상 과정이라는 것을 강조한다는 점에서 유의미하다.  사내에서 제품 팀 또는 제품에 대한 피드백은 어떻게 받나요?  정: 모든 임원진이 참석하여 제품에 대한 피드백을 주는 미팅이 있다. 서비스에 대한 내부 피드백을 정확하게 받을 수 있는 계기가 된다. 이 회의를 통해 전략 미팅이 시작되기도 하며 구체적인 프로젝트 협의를 진행하는 미팅이 이어지기도 한다. 각기 다른 제품을 담당하는 PM이 모두 모이는 미팅도 있다. 미팅 이전에 어떤 피드백을 받고 싶은지에 대해 사전 요청을 하기도 한다. 반드시 ‘애자일’ 하게 일하는 방식이 옳다고는 생각하지 않는다. 방법론보다는 데이터 기반의 피드백과, 일반적인 경험에 대한 언급보다는 명확하고 직관적으로 상대방에게 구체적인 피드백을 주는 것이 중요하다.  제품 팀이 목표에 집중할 수 있도록 PM으로서 어떤 역할을 하시나요?  정: 비즈니스 목표와 제품 팀의 목표가 서로 연관되어야 하는 것은 당연하다. 다만 기술 부채 문제처럼 비즈니스 목표에서 포함하지 않는 제품 팀의 목표가 있을 수 있고, 이 또한 협상의 대상이다. 기술 부채의 범위와 정도에 따라 서비스 자체에 영향을 미칠 수 있기 때문이다. 이러한 문제를 해결하기 위해서 Hack day를 운영한다. 제품 팀이 특정 문제를 해결하기 위해, 정해진 시간 동안 다른 업무를 진행하지 않고 그 문제에만 집중할 수 있도록 유도하는 방식이다. 또한 PM은 업무 우선순위를 정함에 있어 신규 기능과 기존 기능 버그 패치를 함께 조율한다. 제품의 퀄리티는 제품 팀 또는 개발 팀만의 책임이 아니고 전사의 책임이다. 테스트와 클린업의 중요성에 대해 전사적인 공감대 형성이 필요하다.    총 5회에 걸친 인터뷰를 통해 얻을 수 있는 인사이트를 요약 하자면 다음과 같습니다. 비즈니스 목표와 제품 팀 목표가 연관될 수 있도록 업무 방식을 관리해야 한다.   요구사항 간의 우선순위를 조율하는 것은 협상의 과정이다. 협상의 주된 기준은 비즈니스 임팩트에의 기여도이며 기술 부채와 같이 가시화되지 않는 기준도 PM이 검토하여 반영해야 한다.제품 팀 자체도 제품이다. 팀원의 피드백을 취합해서 효과적인 동시에 행복하게 일할 수 있도록 업무 방식을 개선해 나가야 한다.  스포카에서는 위와 같은 인사이트를 기반으로 스포카 크리에이터(스포카 제품 팀)의 업무 방식을 지속적으로 개선하고 있습니다. 스포카 크리에이터는 우선 서비스 품질 차원의 기술적인 목표를 관리합니다. 동시에 제품이 비즈니스에 어떻게 기여하는지를 확인하고 보다 큰 임팩트를 낼 수 있는 기능을 탐색합니다. 이 결과로 제품에서 발생하는 매출 지표 혹은 이에 기여하는 부가 지표를 관리합니다. 아울러 제품 팀 외 유관부서의 요구사항을 취합하는 채널을 일원화하고, 스프린트를 구성하는 회의에서 이를 발의받아 우선순위를 정합니다. 이러한 협의체는 스포카 크리에이터가 가장 효과적으로 비즈니스와 제품에 기여할 수 있도록 업무를 조율하는 역할을 합니다.  마지막으로 스포카 크리에이터는 분기 단위로 동료 간 리뷰 및 조직장과의 면담을 거쳐 팀의 컨디션을 체크합니다. 피드백을 통해 각 팀원은 보다 성장할 수 있는 기회를 확인할 수 있습니다. 조직 차원에서는 각 팀원이 비즈니스 또는 제품의 목표에 대해 얼마나 공감하는지를 확인하고 기여하고자 하는 업무를 파악하여 팀이 보다 효과적으로 일할 수 있도록 조직 구성을 변경하기도 합니다.  스포카 크리에이터는 개인의 성장이 팀의 성장으로 이어지고 이는 곧 제품의 경쟁력과 연결된다고 믿습니다. 스포카와 함께 성장하실 수 있는 분은 언제나 환영합니다.
조회수 1953

입사 후 4개월, 나는 그동안 무엇을 했을까

8월 18일에 입사하여 글을 쓰는 오늘까지 4개월이란 시간이 흘렀다. 트레바리는 4개월을 한 시즌으로 묶어 운영하는 멤버십 서비스이기 때문에 트레바리에서 4개월을 일했다는 건 한 시즌에 필요한 모든 시기를 거쳤다는 의미이다. 4개월을 함께 해야지만 비로소 트레바리를 한 번 했다고 말할 수 있게 된다. 나는 이제서야 트레바리에서 한 번 일했다.트레바리에서의 한 번을 보내며 나는 그동안 무엇을 했는지 정리해보려고 한다. 할 말이 많다 보니 이번 글에서는 기능적으로 무엇을 했는지만 이야기할 예정이다. 어떻게 일했는지, 잘했던 점은 무엇이었는지, 아쉬웠던 점은 얼마나 많았는지에 대한 건 아쉽지만 다음 글에 담기로 했다. 4개월 동안 내가 진행한 일 중 큰 단위의 작업 위주로 살펴보고자 한다.4개월 동안 내가 한 일은 크게 두 가지다. 첫 번째는 기존의 웹 서비스를 개선하는 일. 두 번째는 노가다로 했던 일들에 IT를 끼얹는 일. 두 가지 일에 대한 요구 사항들은 모두 추상적인 문장으로 주어졌고, 나의 역할은 그 추상적인 요구들을 정리하여 실질적인 기능으로 정의하고 구현하는 것이었다. 그동안 어떤 요구 사항들이 있었고 그에 대해 어떤 결과물을 내었는지 정리해보았다.1. 독후감을 활성화되게 만들어주세요.입사 후 최우선으로 개선이 요구됐던 부분은 독후감이었다. 독후감은 트레바리 서비스가 독특하다는 평가를 듣는 이유 중 하나이다. 아무리 돈을 내고 온 멤버일지라도 우리가 내어준 400자의 독후감이라는 숙제를 해오지 않으면 독서 모임에 참가하지 못한다. 우리 크루들은 독후감을 통해 자신의 생각을 한번 정리하고 참가한 독서 모임이 아무런 준비 없이 맞닥뜨리는 독서 모임보다 더 풍성해짐을 안다. 그렇기에 멤버들이 트레바리 홈페이지에서 더 열심히 독후감을 쓰고, 더 많이 다른 사람들의 독후감을 읽고, 더 다양하게 대화할 수 있도록 만들어야 했다.디자인 개선[이전 디자인]일을 시작하자마자 가장 먼저 갈아치우기 시작한 건 디자인이었다. 페이지에 보이는 정보들의 가독성이 나빴다. 독후감 정보와 관련 없는 이미지 배경을 가지고 있었고, 모바일에서는 본문을 포함하여 모든 요소들의 배열이 일정하지 않았다. 가장 문제였던 점은 좋아요 기능이 있음에도 불구하고 유저들이 좋아요 버튼이 있는지를 몰라 활성화가 되지 않는 것이었다.(대표님 얼굴과 우왕이라는 글자가 떡하니 자리 잡은 곳이 좋아요 버튼이다.) 답댓글 없이 한 줄로만 나열된 댓글도 불편했다.[변경한 디자인]전반적으로 컨텐츠가 더 잘 보일 수 있도록 변경했다. 불필요한 배경 이미지를 빼고 책 정보를 추가했다. 좋아요 버튼도 보다 쉽게 인지할 수 있도록 보편적인 모양의 하트로 바꾸었다. 한 줄로만 나왔던 댓글에는 대화하는 듯한 느낌의 UI로 변경하고 답댓글 기능을 추가했다. 특히 모바일에서 더 편하게 쓸 수 있도록 각 요소들을 일정하게 배열했고, 이미지로는 보이지 않겠지만 독후감을 읽고 목록으로 다시 갈 때마다 다른 모임 정보가 뜨는 이상한 시나리오도 개선했다.넛지 만들기더 나은 디자인만으로는 부족했다. 멤버들이 실제로 더 많이 좋아요를 누르고 댓글을 달고 싶게 만들어주는 넛지가 필요했다. 좋아요 수에 따라 재밌는 워딩이 나오고, 댓글 입력 창의 워딩이 항상 다르고 등의 디테일한 요소들을 살렸다. 페이스북 공유하기 기능도 추가했으며 우리 모임에 놀러 오는 멤버들을 보여주는 UI도 추가하는 등의 작업을 진행했다. 하지만 결정적인 한 방이 필요했고 그 한 방은 이달의 독후감 기능이었다.이달의 독후감 선정 기능홈페이지 밖의 운영에서 돌아가던 이달의 독후감이라는 시스템이 있었다. 매 모임마다 가장 좋았던 독후감을 선정하는 것이었는데 잘 알지 못하는 멤버들이 많아 좋아요 수 자체가 적었고, 선정된 독후감을 찾아보기 어려워 활성화가 되지 못했었다. 그래서 이달의 독후감 시스템을 홈페이지에 어워드 형태로 옮겨오면 동기부여와 동시에 별도의 안내 없이도 이달의 독후감 시스템을 학습시킬 수 있겠다고 생각했다.그래서 결과는?결과는 데이터로 나타났다. 디자인과 기능 개선 후 독후감 한 개 당 평균 좋아요/댓글 수가 대략 150% 증가했다. 크루들이 매번 이달의 독후감을 선정하고 하이라이트 구문을 뽑는 오퍼레이션도 줄일 수 있었다. 변경 후 독후감 쓰는 것이 더 즐거워졌다는 멤버 피드백도 종종 들을 수 있었다.2. 멤버십 신청 페이지를 개선해주세요.멤버십 신청 페이지는 트레바리 멤버가 아닌 유저들이 가장 많이 보게 되는 페이지다. 트레바리가 어떤 곳인지 어필하고 결제까지 진행하게 하는 가장 중요한 역할을 하고 있다. 흔히들 말하는 판매 페이지로 트레바리에서 가장 중요한 서비스인 독서 모임을 파는 곳이다. 그 중요성에 비해 디자인과 기능이 모두 엄청나게 부실했고 개선해야 했다.디자인 개선[이전 디자인]대체 트레바리가 어떤 곳인지 알 수 있는 부분이 하나도 없었다. 독서 모임에 대한 설명마저 줄글이 전부였다. 내가 트레바리 독서 모임에 가면 어떤 분위기를 즐길 수 있고 만나는 사람들은 어떨지 상상하기 어려웠다. 모바일에서는 특히 불편했고 필수적인 정보들만 보이는 곳에 불과했다.[변경한 디자인]각 독서 모임에 대한 소개가 풍성하지만 편하도록 변경했다. 이전과 다르게 사진을 많이 활용하여 트레바리 독서 모임이 어떤 분위기인지 보여주고 싶었다. 설명 글도 더 잘 읽힐 수 있도록 배치를 중점적으로 신경 썼고 포인트 컬러를 틈틈이 사용했다. 같은 모임이지만 다양한 시간과 장소가 있는 독서 모임인 경우에는 한 페이지에서 한 번에 볼 수 있도록 구성했다. 모바일 접속자가 압도적으로 많은 만큼 모바일 UI에 많은 시간을 들였다.결제 기능 추가멤버십 신청 페이지에서 가장 큰 문제는 결제였다. 실시간 결제가 아닌 계좌 이체로만 가능하게 되어있다 보니 엄청나게 불편했다. 유저들도 수동으로 이체를 해야 했고, 담당하는 대표님도 24시간 잠도 못자며 휴대폰을 붙잡고 있다가 계좌 이체 알림이 올때마다 등록 처리를 해주어야 했다.(매 시즌 대표님 혼자 몇천 명의 계좌 이체를 확인하고 등록해주셨다. 그래서 멤버십 신청 기간 때에는 제대로 자보신 적이 없다고...)그런데 트레바리는 작은 회사에다 무형의 서비스를 팔고 있다 보니 PG사를 통한 결제를 붙이는 게 어려웠다. PG를 제외한 편하게 결제할 방법을 찾다가 토스 결제를 찾아보게 되었다. 찾자마자 바로 미팅을 진행했고 토스 측에서도 트레바리의 가치를 잘 봐주셔서 미팅부터 결제 연동까지 빠르게 진행하여 구현했다.사랑해요 토스그래서 결과는?막상 개선하여 배포하니 예상보다 저조한 유저 반응이 나타났다. 물론 지난 시즌보다는 훨씬 더 많은 유저분들이 등록하시기는 하였으나 기대했던 목표치에는 못 미쳤다. 디자인이 좋아지고 이용하기 편해지면 당연히 등록 효율이 몇 배로 높아질 거라고 생각했으나 생각처럼 되지 않았다. 신청 기간 내내 저조한 이유에 대한 가설을 세우고, 변경하고, 데이터 보기를 반복했다. 그 과정에서 몇몇 유저분들과 인터뷰를 진행했고 막판에 등록에 영향을 미치는 것은 의외로 홈페이지 사용성이 아닌 다른 곳에 있음을 발견했다. 아쉽게도 늦게 원인을 찾아 더 많은 것을 해보기 전에 신청 기간이 끝나버렸지만, 다음 시즌에는 이번 시즌보다 뾰족하고 탁월하게 개선할 수 있겠다고 생각했다. 영훈님과 함께 공부도 시작해보기로 했다.결제 부분에서는 자세한 데이터를 공개할 수는 없지만 많은 유저들이 토스를 통해 결제를 진행했다. 원래도 트레바리는 N빵 할 일이 많아 토스 송금을 이용하는 유저들이 많았지만 이번 결제 연동을 덕분에 새로 쓰게 된 분도 많아진 것 같았다. 핀테크에 대한 막연한 불안감 때문에 쓰지 않았다는 유저들도 있었지만 막상 써보니 엄청나게 편해서 놀랐다는 피드백도 많이 받았다. 아마도 트레바리에서는 앞으로 계속 토스 송금/결제를 활발하게 사용할 것 같다.3. 트레바리가 어떤 곳인지 보여줍시다.위에서 말한 등록에 영향을 미치는 것은 서비스에 대한 설득이었다. 그동안 트레바리는 지인의 소개로 오는 유저들이 많았고, 기사를 보고 오는 유저들이 많았고, 소문을 듣고 오는 유저들이 많았다. 그래서 따로 트레바리가 어떤 곳인지 잘 설명할 필요성이 적었던 것 같다. 이제는 유저들이 점점 많아지면서 트레바리가 어떤 곳인지 적극적으로 보여줄 필요가 있었고 방치되어 있던 랜딩페이지를 끄집어냈다.[이전 랜딩페이지]이곳만 봐서는 트레바리가 어떤 곳인지 알 수 없었다. 트레바리가 얼마나 매력적인지 어필이 되지 않았고 어떤 활동을 할 수 있는지도 알기 어려웠다.[변경한 랜딩페이지]트레바리가 지향하는 가치들을 더 많이 설명했다. 중간중간 트레바리 사용설명서 영상을 볼 수 있는 곳을 추가했고 실제 멤버들의 후기도 담았다. 트레바리는 독서 모임을 제공하는 서비스이므로 대표적인 독서 모임이 무엇이 있는지도 보여주고 싶었다. 각종 미디어에서 이야기하는 트레바리와 멤버들만을 위한 혜택도 정리해두었다.그래서 결과는?급하게 만드느라 트레바리의 매력을 아직 반의반도 못담았다고 생각한다. 랜딩페이지만 봐도 트레바리가 어떤 곳이고 트레바리를 통해 당신이 얼마나 더 멋있어질 수 있는지를 보여주고 싶다. 랜딩페이지는 꾸준히 만지고 다듬어야 할 과제로 남겨두었다.4. 손에 잡히는 무언가를 주기(일명 손잡무)한 시즌을 끝낸 멤버들에게 각자가 한 시즌 동안 무엇을 해왔는지 쥐여주고 싶었다. 그래서 시즌 말 약 1700명의 멤버들 모두에게 개개인이 이뤄온 활동 데이터를 이미지로 재밌게 엮어 나눠주었다. 기발한 워딩과 이미지는 이 방면에 재능이 있는 세희님과 지현님이 함께해주셨다.[1705 시즌 손잡무][1709 시즌 손잡무]1700명 모두에게 개인화된 이미지를 노가다로 만들어주는 것은 불가능했다. 자동화를 하기 위해서 SQL 쿼리를 통해 필요한 로우 데이터를 추출하고, 스케치라는 디자인 툴을 활용해 이미지 생성을 자동화했다. 덕분에 모든 멤버들의 이미지를 한땀한땀 만드는 노가다를 피하면서도 개인화된 컨텐츠를 제작할 수 있었다. 이 방법은 이다윗님의 코드로 100명 이상의 네임택 한 번에 디자인하기 글을 보고 영감을 받아 가능했다.그래서 결과는?성공적이었다. 인스타그램에 #트레바리를 검색하면 손잡무를 나눠준 시점에 많은 멤버분들이 공유해주신걸 볼 수 있다.(개근상 받으신 분들이 제일 많이 공유해주셨다.) 이미지를 공유해주시면서 4개월 동안 얼마나 즐거웠고 많이 배웠는지에 대한 후기도 소상히 적혀있는 경우도 많아 더욱 뿌듯한 결과물이었다.5. 그 외 각종 버그/개선 요구 사항 해결도 해주세요.각종 UI 및 사용성 개선여러 페이지들의 UI를 개선하고 기능을 개선하여 배포하였다. 자잘한 기능 추가부터 페이지 통째로 갈아엎기까지 손을 댈 수 있는 리소스만큼 건들여보고 개선했다. 이 과정에서는 우선순위를 정하는 일이 중요했는데 우선순위에 대한 이야기는 후에 다시 해볼 예정이다.각종 버그/요구 사항 해결 + 그에 따른 CS내가 만든 것도 많았지만(…) 그거말고도 도대체 개발자가 없을땐 홈페이지가 어떻게 굴러갔지 싶을 정도로 버그가 많았다. 버그도 많고 요구되는 개선 사항도 많았다. 줄어들고는 있지만 아직까지도 버그 및 요구 사항에 응대하는 시간이 하루에 한 시간씩은 꼬박꼬박 들고 있다. 더 많이 줄여나가는 것을 목표로 하고 있다.자동화독서 모임을 이끄는 크루들이 노가다를 하느라 고생하는 시간이 많다. 위에서 이야기 했던 계좌 이체 확인이 가장 큰 사례이다. 그 외에도 개설되는 클럽 데이터 입력을 어드민에서 며칠동안 노가다로 진행해야하는 등의 낭비가 많았다. 이런 부분에서 IT를 끼얹어 공수를 덜 들이고 빠르게 끝낼 수 있도록 엑셀 import 등의 기능을 구현했다.트레바리의 한 번을 끝마치며 나는 그동안 무엇을 했는지 정리해보았다. 쓰다보니 만족스러운 것보다 아쉬운 것들이 눈에 더 많이 들어온다. 무엇이 아쉬웠나 하면 할말이 너무나도 많아 다른 글에 써보기로 하고 이번 글은 기능적인 이야기로만 마무리했다.돌이켜 생각해보면 트레바리에서 쓰이는 기술 스택인 루비도 레일스도, 서버 인프라도 하나 모르는 나를 믿고 이 모든걸 배우고 익힐때까지 기다려준 크루들이 새삼 대단하다고 느낀다. 그 과정에서 실수로 인한 버그도 엄청 많았고 그 버그 때문에 불필요하게 운영 코스트가 늘어났을 때도 있었지만 나무란 적 한 번 없이 격려와 함께 기다려주고 믿어주었다. 그래서 더 열심히 달릴 수 있었던 것 같다.아쉬움과 감사함 때문에라도 다음 4개월에는 일을 더 '잘'하는 사람이 되어야겠다고 다짐했다. 앞으로도 계속 성공하고 실패하고, 배우고 성장한 일들을 꾸준히 기록해나가며 일을 더 잘하는 사람이 되고 싶다. 다음 4개월은 지난 4개월보다 보다 더 실질적이고 큰 변화들을 만들 수 있는 사람이 되어야 겠다. 걱정반 기대반이지만 설레는 마음으로 새로운 시즌을 맞이하며 글을 끝맺으려 한다.어떻게 하면 더 잘할지 고뇌하는 모습의 크루들#트레바리 #기업문화 #조직문화 #CTO #스타트업CTO #CTO의일상 #인사이트
조회수 295

프로그래밍 수업의 모든 것.

안녕하세요 엘리스입니다. :)엘리스의 프로그래밍 수업은 누구에 의해서, 어떻게, 어떤 생각을 바탕으로 만들어질까요?미래를 이끌어나갈 컴퓨터 사이언스 기술과 그 근간이 되는 교육 사이에서 좋은 프로그래밍 수업을 만들기 위해 치열하게 고민하는 엘리스의 코스 매니저가 직접 이야기합니다! 마침 엘리스는 코스 매니저 채용 중에 있으니 관심이 있다면 눈여겨 봐주세요!코스 매니저가 관여한 프로덕트로 인하여 사용자가 성장을 하고 있다면 그것은 충분히 의미 있는 일.안녕하세요 저는,트라우마를 극복한 프로그래밍 수업 크리에이터.Q. 자기소개 부탁드려요.A. 엘리스의 프로그래밍 과목을 만드는 코스 매니저 이용희입니다.Q. 엘리스에서 일하게 된 이유는 무엇인가요?A. 원래는 프로그래밍에 대한 트라우마가 있었어요. 하지만 기술 창업에 대한 꿈이 있었기 때문에 프로그래밍은 극복해야 할 산이었죠. 엘리스는 가장 뛰어난 기술자들이 모여 창업한 스타트업이에요. 당연히 기술 창업을 가장 가까이에서 경험할 수 있는 매력적인 곳으로 느껴졌죠. 그리고 프로그래밍 교육을 제공한다는 것 역시 기회로 느껴졌어요. 저와 같이 프로그래밍을 미워하고 두려워하는 사람들에게 보다 쉽게 배울 수 있는 환경을 마련해주고 싶다는 기대로 일을 시작하게 되었습니다.Q. 두려운 대상을 향해 몸을 던지셨군요! 그런데 코스 매니저가 프로그래밍을 몰라도 되나요?A. 많이 알면 알수록 당연히 좋아요. 많이 알고 있을수록 시도할 수 있는 것도 많고 학생에게 전달해줄 수 있는 것은 더욱더 많기 때문에요. 하지만 최소한으로는 Class가 뭔지 알고 있으면 OK. 예를 들어서 코드를 보고 이 코드가 어떤 목적을 갖는지 알 수 있으면 직접 코딩을 하지는 못한다고 해도 괜찮아요.Q. 코스 매니징 외에도 라이브 수업 참여, 조교, 챌린지 사회자 등 많은 역할을 하셨는데 이유가 있나요?A. 좋은 수업을 만들기 위한 첫 번째 방법은 코스를 만드는 모든 과정에 참여하는 사람들의 역할을 직접 체험해 보는 것이라고 생각했어요. 학생으로서, 조교로서, 사회자나 라이브 어시스턴트로서. 이렇게 하니까 학생으로서 수업을 접할 때의 감상은 무엇인지, 조교로서 가르쳤을 때는 어떤 어려움이 있는지를 알 수 있었어요. 라이브 수업 어시스턴트로 참여했을 때는 방송하시는 선생님들의 애로사항을 알 수 있겠더라고요.코스 매니징의 정수.프로그래밍적 성장을 도움으로써 가치를 만들어 냅니다.Q. 코스 매니징의 A to Z는? 구체적인 업무 프로세스가 궁금해요.A. 크게 기획 - 모집 - 제작 - 분석의 네 단계로 이루어져 있어요. 1. 수업 기획 -  어떤 과목을 만들 것인가? 주차별로 무엇을 다룰 것인가? 흥미로운 콘텐츠는? 2. 선생님, 조교 모집 - 엘리스가 구상한 수업을 가장 잘 전달할 수 있는 선생님과 조교를 모집. 3. 수업 제작 및 운영 - 실습 문제, 강의 자료 등을 엘리스의 색깔로 제작하여 수업을 운영. 4. 데이터 분석 - 학생들의 피드백과 데이터를 다음 수업의 발전 및 교육자와의 관계 개선에 반영.Q. 업무 방식은? 어떤 메리트가 있나요?A. 처음부터 끝까지 모든 과정을 주도해나가는 방식이에요. 어떤 회사를 가도 프로덕트의 end to end 프로세스를 전부 경험하기는 어려운데 엘리스에서는 그 전 과정을 경험할 수 있어요. 저는 이러한 경험이 교육 업계나 특정 프로덕트에만 적용할 수 있는게 아니라 다른 업계에 간다고 하더라도 충분히 전환될 수 있는 좋은 경험이라고 생각해요.Q. 미래 산업의 근간이 될 교육을 직접 만든다는 중책을 맡고 계신다고 생각하는데요, 좋은 프로그래밍 수업을 만들기 위해 어떤 노력들을 하시나요?A. 그런 영향을 미칠 수 있다는 게 무서운 일인 것도 같아요. 어떤 사람들은 엘리스를 통해서 프로그래밍을 처음 접하는 것일 수도 있는데 그 경험이 불쾌했다면 앞으로 프로그래밍을 배울 생각이 전혀 들지 않을 수도 있는 거잖아요. 그래서 최대한 다양한 피드백을 받아서 수렴하려고 해요. 외적으로는 대학강의, 수많은 수업들을 참고해요. 여러 강의를 보다보면 좋은 예도 많지만 모든 수업이 재미있지는 않아요. 중간에 듣다 마는 경우도 있고요. 그럴 때마다 내가 왜 중단했고 어떤 요소를 바꾸면 엘리스에서는 학생들이 끝까지 들을 수 있을까 고민해서 반영하려고 하죠.Q. 언제 보람을 느끼나요?A. 내가 관여한 프로덕트가 누군가에게 임팩트를 만들어내고 나뿐만 아니라 프로덕트를 사용하는 사람들이 성장을 하고 있다면 그것은 충분히 가치 있는 일인 것 같아요. 저희 플랫폼에서는 대시보드를 통해서, 그리고 학생이 코드를 어떻게 짜고 있는지 보면서 그 결과를 가시적으로 확인할 수 있어요. 누군가 제가 만든 코스를 수강함으로써 실질적으로 성장하는 게 눈에 보일 때 가장 큰 보람을 느끼는 것 같아요.한 번은 한 선생님께서 학생으로부터 ‘선생님 덕분에 취업할 수 있었어요’라는 메시지를 받은 것을 엘리스와 공유해주셨는데 그때 정말 행복하더라고요. 이게 엘리스가 추구하는 거다,라는 생각을 했어요. 엘리스도 하나의 커뮤니티이고 싶거든요. 이 경우에는 학생-선생님-엘리스가 서로의 영향으로 좋은 결과를 만들어 낸 거죠. 이런 접점을 앞으로 더 많이 만들려고 생각하고 있어요.대시보드에 나타나는 학생들의 학습 현황 및 성취도.엘리스는 이런 팀.가치, 성장, 사람. 포기할 수 없는 세 가지가 있는 곳.Q. 함께 일하는 동료들은 어떤 사람들인가요? 총평을 하자면?A. 항상 내가 최고의 사람들과 함께하고 있다라는 확신이 있어요. 각자 자기 분야에서 최고의 실력을 가진 사람들과 함께 일한다는 것만으로도 큰 자극이 되죠. 프로그래밍이든 스타트업 생존 노하우든 항상 뭔가를 새롭게 배우고 성장하게끔 동기부여를 해주는 사람들이에요. 저는 트라우마가 있었을 정도로 프로그래밍을 두려워했지만 이들과 함께 일하며 작은 피드백을 하나 듣는 것만으로도 제 실력이 빠르게 성장한다는 것을 몸소 느낄 수 있었어요. Q. 엘리스의 분위기, 팀 문화는 어떤가요?A. 새로운 것에 도전하는 것을 환영하는 수평적이고 자유로운 팀. 인턴도 아이디어를 제시할 수 있어요. 이 다음이 더 중요한데, 아이디어에서 그치는 게 아니라 활발한 피드백이 오가요. 아이디어를 실행하기 어렵다고 판단하더라도 왜 그렇고 어떻게 발전시킬 수 있는지 이야기하죠. 실행하게 되었을 때는 아이디어를 제시한 사람에게 일에 대한 권한이 전적으로 주어지고요. 저도 처음엔 파트타임 인턴이었지만, 이런 팀문화 덕분에 계속해서 업무 범위를 확장하고 제 역량을 키울 수 있었어요.코스 매니저 채용.Generalist & Infinite LearnerQ. 현재 코스 매니저를 구인하고 있는데요. 코스 매니저에 적합한 성향이 있나요?A. 두 단어가 떠오르네요. Generalist, 그리고 Infinite Learner. 깊게 한 분야를 아는 사람보다는 얕고 넓게 아는 사람이 더 적합하다고 생각해요. 다르게 말하면 새로운 것을 시도하는 것을 좋아하고 새로운 것을 접할 때 포용력이 높은 사람이요. 두 번째로는 배움에 재미를 느끼는 사람. 엘리스는 교육 스타트업이고 코스 매니저는 직접 교육의 경험을 만드는 사람이니 스스로가 배움에서 행복을 느끼는 사람이라면 훨씬 더 재미있게 일할 수 있겠죠. 한 가지 덧붙이면, 데이터 분석을 배우고 싶은 분께 엘리스는 최고의 장소입니다.Q. 코스 매니저로서 갖추고 있으면 좋은 역량이나 자질이 있다면?A. 소통 능력과 균형 감각. 코스 매니저는 수업을 만드는 모든 단계에서 다양한 이해당사자들과 일하게 돼요. 이들과 원활하게 소통하고 의견을 공유하는 게 중요하죠. 그리고 다양한 사람들 사이에서 최고의 균형을 찾아내는 것도 중요해요. 예를 들어서 선생님의 경우 개발만 해왔고 교육이라는 것을 접해본 적이 없는 분들이 대부분이고, 학생은 프로그래밍을 처음 접하면 그 수업이 좋은 건지 아닌지 평가하기 어려워요. 때문에 코스 매니저가 이 둘 사이에 다리를 놓는 중재자의 역할을 하기 위해서는 다양한 시각에서 볼 수 있는 균형 감각이 필요하다고 생각해요.
조회수 3860

개발자, 디자이너, 기획자의 온도차

 아마 가장 많은 분들이 생각하시기에 가장 걱정되는 부분이라고 생각이 듭니다.그래서 저 역시도 이 이야기를 하는 것에 좀 조심스럽습니다. 이야기는 바로 "업무를 대하는 개발자, 기획자, 디자이너 간의   온도차."입니다. (다시 한번 말씀드려요! 제가 사용한 방법이 백프로 모두에게 맞는 말은 아닙니다!!) 스타트업은 큰 기업처럼 디자인팀, 개발팀, 기획팀이 갈려서 서로의 팀장에게 허가를 받고, 기획을 시작하고, 개발을 시작하고, 디자인하는 그런 상하관계의 구조가 아닙니다. 서로서로들 비슷한 경력들과 환경에서 서비스를 제작하는 사람들이 많죠. 특히, 젊은 스타트업 기업들은 대학생들이나 대학원생 등 아직 본격적인 사회생활을 해보지 않은 인원들이 더 많을 것으로 알고 있습니다. 아시다시피, 다들 맞춰진 직무를 기반으로 개발자는 개발자의 생각과 계산에 따라서 일을 진행하고 있고, 기획자는 기한에 맞춰 예상했던 진행대로 일을 진행하고 싶어 하고, 디자이너들은 보다 다은 디자인으로 서비스를 보이려 다양한 자료들을 모으고 분석하여 제작자의 아이디어를 입혀 새로운 콘텐츠를 제작하려 노력합니다.문제는 서로가 서로의 일에 대하여 모른다는 것입니다. 스타트업의 팀원들 간의 커뮤니케이션은 마치 연애와 같아서 서로 이야기해주지 않으면 모를 수밖에 없고, 서로 어떻게 일을 하는지, 얼마나 시간이 걸릴 것이다 등 일정에 대한 공유나, 업무를 하는 절차를 이야기 해주짖 않으면, 원치 않는 감정의 골이 생기기 마련입니다. 이런 문제를 해결하기 위해, 기업은 매일매일 아침시간에 진행하는 Scrum이라든지, Jira, Taskworld, Trello 등 다양한 프로젝트 매니지먼트 툴을 사용하고, 스크럼 마스터나, 다양한 서비스를 제작해 보신 PM(Project Manager), 또는 PO(Product Owner)님들이 각부서의 현황들을 파악하고, 다양한 부서를 총괄하고 관리합니다.그러나, 기본적으로 국내 스타트업 상황은업무자들의 수가 절대적으로 부족하고,젊은 개발자나 디자이너 같은 경우는 생업(또는 학업)과 스타트업을 동시에 하는 인원이 많고,젊은 창업자들과 직원들의 경우, 프로젝트 경험이 없어 이러한 분업구조를  낯설어하고,개발자와 디자이너 역시 자신이 작업하는 프로젝트가 언제쯤 끝날지 가늠할 수 없는 상황이 생기고,적은 인원들이 많은 프로젝트를  진행하느라 예민한 구조가 되어 남을 이해하기 힘든 상황등의 다양한 이유들 때문에 각 직군 간의 갈등 상황이 큰 기업에 대비하여 많이 생기고 있습니다(물론 큰 기업도 문제가 없진 않다고 합니다.).이 전설의 짤을 보신적이 있으신 분들도 많으실듯... (출처: http://9gag.com/) 이러한 갈등 해결 방안은 다음에 더  디테일하게 설명드리도록 하고, 이번 글에서는 간단히 저가 생각하는 발전방향에 대하여  이야기해보도록 하겠습니다. 앞서 말씀드린 것과 같이, 스타트업 팀원들의 관계는 마치 연예와 비슷하다고 생각합니다. 말하지 않으면 모를 수밖에 없는 노릇이고, 말을 해줘도 이해할 수 없는 일들이 수두룩 합니다(그런 이유로 저는, 스타트업에서 근무하시는 분들은 서로의 업무에 대하여 어느 정도의 배경지식을 배우는 게 필요하다고 생각합니다.). 그럼에도 불구하고 우리는 항상 이야기를 해야 해요. 연애를 할 때도 말이 안 통해도 될 때까지 이야기하듯이. 스타트업에서의 업무는 끊임없이 피보팅을 진행하고, 하루하루 떠오르는 처리해야 할 일들이 생깁니다. 그리고, 그러한 변경사항들에 관하여  이야기할 때, 서로가 서로의 말을 이해해 주지 못한다면, 더 큰 갈등 상황들을 야기하기 마련이지요. 그러나, 만약 각 직군의 전문가들이 서로의 업무에 대한 배경이나, 아주 기본적이더라도 기초사항을 알고 있다면, 서로의 업무량에 대한 불만이 아무래도 적을  수밖에 없다고 생각합니다. 제가 스타트업을 진행할 당시를 말씀드리자면, 저는 창업 당시 기획자로서 서비스를 기획하고, 프로젝트를 관리하고, 투자 또는 공모전 등에 쓰일 기획서 등을 제작하는 업무를 주로 하였습니다. 디자인에 관하여는 무엇을 논할 수 있는 실력도 아니고, 개발에 관하여는 더더욱 그렇습니다. 그러므로 기획서를 작성할 때나, 어떤 계획을 할 때 “원하는 시간”을 개발자나 디자이너에게 요청하고, 그러한 요청 사안과 당사자들과의 이야기를 통해 조정하고 계획을 진행하는 것이 주  업무였습니다. 그리고 나름 생각하기에는 "개발이나 디자인을 하나도 모르는 사람이 일의 진행 정도를 스스로 보고 판단하고, 기한을 준다는 것은 올바르지 않다."라고 생각하여 아주 기초적일 수 있지만 웹 공부와 포토샵 일러스트 디자인 등의 디자인과 개발 툴 공부를 꾸준히 하면서 개발과 기획에서 어느 정도  서포트할 수 있는 실력을 기르기 위해 많은 시간을 투자했었습니다. 그리고 이러한 노력 덕분에 서로의 직군과 업무에 대한 고충을 이해할 수 있어서 많은 이점을 가질 수 있었지만, 그럼에도 불구하고, 자주자주 일이 딜레이 되는 상황이 발생하였고, 그러함에 따라서 개발자와 디자이너와 기획자들이 조금씩 소원해지고  섭섭해지는 상황이 발생하였던 것 같습니다. 그래서 하나 더 생각했던 것이, "일을 처음 시작하는 초보들에게도 바로 적용해서 업무에 도입할 수 없는 어려운 프로젝트 매니지먼트 툴이 아닌 서로의 작업현황이나, 상태 정도를 가늠할 수 있는 PM 툴을 만들어 보자." 하는 것이었습니다. 그래서 창업 당시 사용한 아주 간단한 툴이 있는데, 이 프로젝트 메니지 방법은 내일 이미지로 보여드리면서 설명드릴게요. :) 그리고 지금은 Taskworld나 Jira 같은 더 전문적인 툴을 사용하고 있지만, 해당 툴에 대한 전문전 지식이 아직 없는 분들은 엑셀 등으로 서로의 일을 정리해서 공유하는 것도 좋을 것 같네요! 기회가 되면, 요즘은 제가 어떤 식으로 툴을 사용하는지 설명하는 글도 적도록 하겠습니다! 마지막으로 긴 글을 세줄 정리하자면, 1. 개발자, 기획자, 디자이너는 달라요. x나 달라요.... 2. 다르면 잘 들어보고 뭘 하는지 아는 것이 중요하다고 생각합니다. 3. 그리고 서로가 어떤 일을 하고 있는지 현황을 파악할 수 있다면 더 좋겠죠?오늘도 읽어주셔서 감사합니다! 좋은 하루들 되세요:)#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트
조회수 1614

PyCon2017 첫번째날 후기

아침에 느지막이 일어났다. 어제 회사일로 피곤하기도 했지만 왠지 컨디션이 좋은 상태로 발표를 하러 가야지!라는 생각 때문에 깼던 잠을 다시 청했던것 같다. 일어나 아침식사를 하고 아이 둘과 와이프를 두고 집을 나섰다. 작년 파이콘에는 참가해서 티셔츠만 받고 아이들과 함께 그 옆에 있는 유아교육전을 갔었기에 이번에는 한참 전부터 와이프에게 양해를 구해둔 터였다.코엑스에 도착해서 파이콘 행사장으로 가까이 가면 갈수록 백팩을 메고, 면바지를 입고, 영어 글자가 쓰인 티셔츠를 입은 사람의 비율이 높아지는 것으로 보아 내가 제대로 찾아가고 있구나 라는 생각이 들었다.                                               늦게 왔더니 한산하다.지난번에는 입구에서 에코백과 가방을 나눠줬던 것 같은데 이번에는 2층에서 나눠준다고 한다. 1층이 아무래도 복잡해지니 그런 것 같기도 하고, 2층에서 열리는 이벤트들에도 좀 더 관심을 가져줬으면 하는 것 같기도 하다. 우선 스피커 옷을 받고 싶어서 (솔직히 입고 다니고 싶어서) 2층에 있는 스피커방에 들어갔다.                         허락 받지 않고 사진찍기가 좀 그래서 옆방을 찍었다.첫 번째 키노트는 놓쳤지만 두 번째 키노트는 꼭 듣고 싶었기에 간단히 인사만 하고 티셔츠를 들고 나왔다. (외국에서 오신 연사분과 영어로 대화를 나누고 있어서 자리를 피한것은 아니다.) 나가는 길에 보니 영코더(초등학교 5학년 부터 고등학생 까지 파이썬 교육을 하는 프로그램)을 진행하고 있었다. 의미있는 시도를 하고 있다는 생각이 들었다.                          이 친구들 2년 뒤에 나보다 잘할지도 모른다.키노트 발표장에 갔더니 아웃사이더님이 뒤에 서 게셨다. 지난 파이콘 때 뵙고 이번에 다시 뵈었으니 파이콘이 사람들을 이어주는 역할을 하는구나 싶었다.키노트에서는 현우 님의 노잼, 빅잼 발표 분석 이야기를 들을 수 있었다. 그리고 발표를 통해 괜히 이것저것 알려줘야만 할 것 같아 발표가 부담스러워지는 것 같다는 이야기를 들었다. 나 또한 뭔가 하나라도 지식을 전달해야 한다는 압박감을 느끼고 있었던 터라 현우 님의 키노트 발표를 듣고 나니 좀 더 오늘을 즐겨야겠다는 생각이 들었다.                                              오늘은 재미있었습니다!현우님 키노트를 듣고 같은 시간(1시)에 발표를 하시는 경업님과 이한님 그리고 내일 발표이신 대명님, 파이콘 준비위원회를 하고 계신 연태님과 함께 식사를 하러 갔다. 가는 길에 두숟갈 스터디를 함께 하고 계신 현주님과 희진 님도 함께했다. 사실 이번에는 발표자도 티켓을 사야 한다고 해서 조금 삐져 있었는데 양일 점심 쿠폰을 주신다고 해서 삐진 마음이 눈 녹듯이 사라졌다.                                                  부담 부담식사를 하고 발표를 할 101방으로 들어가 봤다. 아직 아무도 없는 방이라 그런지 괜히 긴장감이 더 생기는 느낌이다. 발표 자료를 열어 처음부터 끝까지를 한번 넘겨 보고 다시 닫았다. 처음에는 가장 첫 발표라 불만이었는데 생각해보니 발표를 빨리 마치고 즐기는 게 훨씬 좋겠다는 생각이 들었다. 발표 자료를 다듬을까 하다가 집중이 되지 않아 밖으로 나갔다. “열린 공간” 현황판에 충동적으로 포스트잇을 하나 붙이고 왔다. 어차피 발표는 나중에 온라인으로도 볼 수 있으니까 사람들과 이야기를 나눠 봐야 겠다 싶었다. (내 발표에는 사람이 많이 왔으면 하면서도, 다른 사람의 발표는 온라인으로 보겠다는 이기적인 생각이라니..)                                            진짜 궁금하긴 합니다다시 발표장으로 돌아왔다. 왠지 모르는 분들은 괜찮은데 아는 분들이 발표장에 와 계시니 괜히 더 불안하다. 다른 분들은 발표자료에 짤방도 많이 넣으셨던데.. 나는 짤방도 없는 노잼 발표인데.. 어찌해야 하나. 하지만 시간은 다가오고 발표를 시작했다.                                            얼굴이 반짝 반짝리허설을 할 때 22분 정도 시간이 걸렸던 터라 조금 당겨서 진행을 했더니 발표를 거의 20분에 맞춰서 끝냈다. 그 뒤에 몇몇 분이 오셔서 질문을 해주셨다. 어리버리 대답을 한 것 같다. 여하튼 내 발표를 찾아오신 분들께 도움이 되었기를. 그리고 앞으로 좀 더 정확한 계산을 하시기를.대단히 발표 준비를 많이 하지도 못하면서 마음에 부담만 쌓아두고 있는 상황이었는데, 발표가 끝나니 아주 홀가분한 마음이 되었다. 발표장을 나가서 이제 부스를 돌아보기 시작했다. 매해 참여해 주고 계신 스마트스터디도 보이고 (정말 안 받고 싶은 ‘기술부채’도 받고 말았다.) 쿠팡, 레진 등 친숙한 회사들이 많이 보였다. 내년에는 우리 회사도 돈을 많이 벌어 여기에 부스를 내고 재미있는 이벤트를 하면 좋겠다는 생각이 들었다.부스를 돌아다니다가 이제 파이콘의 명물이 된 내 이름 찾기를 시작했다. 이름을 찾기가 쉽지가 않다. 매년 참여자가 늘어나서 올해는 거의 2000명에 다다른다고 하니 파이썬 커뮤니티의 성장이 놀랍다. 10년 전에 파이썬을 쓸 때에는 그리고 첫 번째 한국 파이콘이 열릴 때만 해도 꽤 마이너 한 느낌이었는데, 이제 주류가 된 것 같아 내 마음이 다 뿌듯하다. (그리고 내 밥줄이 이어질 수 있는 것 같아 역시 기쁘다)                                          어디 한 번 찾아보시라다음으로는 박영우님의 "Django admin site를 커스텀하여 적극적으로 활용하기” 발표를 들으러 갔다. (짧은 발표를 좋아한다.) 알고 있었던 것도 있었지만 커스텀이 가능한지 몰랐던 것들도 있어서 몇 개의 기능들을 킵해 두었다. 역시 컨퍼런스에 오면 내게 필요한 ‘새로운 것’에 대한 실마리를 주워가는 재미가 있다.                                     익숙하다고 생각했지만 모르는 것이 많다4시가 되어 OST(Open Space Talk)를 하기로 한 208B 방으로 조금 일찍 갔다. 주제가 뭐였는지는 잘 모르겠는데 주식 투자, Tensor Flow, 비트코인, 머신러닝 등등의 이야기들이 오가고 있었다. 4시가 되어 내가 정한 주제에 대해 관심 있는 사람들이 모였다. 괜히 모일 사람도 없는데 큰방을 잡은 것이 아닐까 하고 생각하고 있었는데, 생각보다 많은 분들이 오셨다.각 회사들이 어떤 도구를 사용하는지 설문조사도 해보고, 또 어떤 개발 방법론을 사용하는지, 코드 리뷰, QA는 어떻게 하고 있는지에 대한 이야기를 나눴다. 다양한 회사에서 다양한 일을 하는 사람들이 모여 있다 보니 생각보다 꽤 재미있게 논의가 진행되었다. 사실 내가 뭔가 말을 많이 해야 할 줄 알았는데, 이야기하고 싶은 분들이 많이 있어서 진행을 하는 역할만 하면 되었다. 마지막으로는 “우리 회사에서 잘 사용하고 있어서 다른 회사에도 추천해 주고 싶은 것”을 주제로 몇 가지 추천을 받은 것도 재미가 있었다.                                  열심히 오간 대화를 적어두긴 했다5시에 OST를 마치고는 바로 집으로 돌아왔다. 오늘 저녁에 아이들을 잘 돌보고 집 청소도 열심히 해두어야 내일 파이콘에 참여할 수 있기 때문이다. 기대된다. 내일의 파이콘도.그리고 정말 감사드린다. 파이콘을 준비해주시고 운영해주고 계신 많은 분들께.                                                   #8퍼센트 #에잇퍼센트 #이벤트 #참가후기 #파이콘 #개발자 #개발 #파이썬 #Python #Pycon
조회수 5652

Next.js 튜토리얼 1편: 시작하기

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기  - 현재 글2편: 페이지 이동3편: 공유 컴포넌트4편: 동적 페이지5편: 라우트 마스킹6편: 서버 사이드7편: 데이터 가져오기8편: 컴포넌트 스타일링9편: 배포하기개요요즘은 싱글 페이지 JavaScript 애플리케이션을 구현하는게 꽤 어려운 작업이라는 것을 대부분 알고 있습니다. 다행히도 간단하고 빠르게 애플리케이션들을 구현할 수 있도록 도와주는 몇 가지 프로젝트들이 있습니다.Create React App이 아주 좋은 예시입니다.그렇지만 여전히 적당한 애플리케이션을 구현하기까지의 러닝 커브는 높습니다. 클라이언트 사이드 라우팅과 페이지 레이아웃 등을 배워야하기 때문입니다. 만약 더 빠른 페이지 로드를 하기위해 서버 사이드 렌더링을 수행하고 싶다면 더 어려워집니다.그래서 우리는 간단하지만 자유롭게 설정할 수 있는 무언가가 필요합니다.어떻게 PHP로 웹 애플리케이션을 만드는지 떠올려봅시다. 몇 개의 파일들을 만들고, PHP 코드를 작성한 다음 간단히 배포합니다. 라우팅에 대해 걱정하지 않아도 됩니다. 그리고 이 애플리케이션은 기본적으로 서버에서 렌더링됩니다.이것이 바로 우리가 Next.js에서 수행해주는 일입니다. PHP 대신에 JavaScript와 React를 사용하여 애플리케이션을 구현합니다. Next.js가 제공하는 유용한 기능들은 다음과 같습니다:기본적으로 서버 사이드에서 렌더링을 해줍니다.더 빠르게 페이지를 불러오기 위해 자동으로 코드 스플릿을 해줍니다.페이지 기반의 간단한 클라이언트 사이드 라우팅을 제공합니다.Hot Module Replacement(HMR)을 지원하는 Webpack 기반의 개발 환경을 제공합니다.Express나 다른 Node.js HTTP 서버를 구현할 수 있습니다.사용하고 있는 Babel과 Webpack 설정을 원하는 대로 설정할 수 있습니다.설치하기Next.js는 Windows, Mac, Linux와 같은 환경에서 동작합니다. Next.js 애플리케이션을 빌드하기 위해서는 Node.js가 설치되어 있어야 합니다.그 외에도 코드를 작성하기 위한 텍스트 에디터와 몇 개의 명령어들을 호출하기 위한 터미널 애플리케이션이 필요합니다.Windows 환경이라면 PowerShell을 사용해보세요.Next.js는 모든 셀과 터미널에서 동작하지만 튜토리얼에서는 몇 개의 특정한 UNIX 명령어를 사용합니다.더 쉽게 튜토리얼을 따르기 위해서는 PowerShell 사용을 추천합니다.맨 먼저 다음 명령어를 실행시켜 간단한 프로젝트를 생성하세요:$ mkdir hello-next$ cd hello-next$ npm init -y$ npm install --save react react-dom next$ mkdir pages그런 다음 hello-next 디렉토리에 있는 "package.json" 파일을 열고 다음과 같은 NPM 스크립트를 추가해주세요.이제 모든 준비가 끝났습니다. 개발 서버를 실행시키기 위해 다음 명령어를 실행시키세요:$ npm run dev명령어가 실행되었다면 브라우저에서 http://localhost:3000 페이지를 여세요.스크린에 보이는 출력값은 무엇인가요?- Error No Page Found- 404 - This page could not be found- Hello Next.js- Hello World404 Page다음과 같은 404 페이지가 보일 것입니다.첫 번째 페이지 생성하기첫 번째 페이지를 생성해봅시다.pages/index.js 파일을 생성하고 다음의 내용을 추가해주세요:이제 http://localhost:3000 페이지를 다시 열면 "Hello Next.js" 글자가 있는 페이지가 보일 것입니다.pages/index.js 모듈에서 간단한 React 컴포넌트를 export 했습니다. 여러분도 React 컴포넌트를 작성하고 export 할 수 있습니다.React 컴포넌트가 default export 인지 확인하세요.이번에는 인덱스 페이지에서 문법 에러를 발생시켜봅시다. 다음은 그 예입니다: (간단하게HTML 태그를 삭제하였습니다.)http://localhost:3000 페이지에 로드된 애플리케이션은 어떻게 되었나요?- 아무일도 일어나지 않는다- 페이지를 찾을 수 없다는 에러가 발생한다- 문법 에러가 발생한다- 500 - Internal Error가 발생한다에러 다루기기본적으로 Next.js는 이런 에러들을 추적하고 브라우저에 표시해주므로 에러들을 빨리 발견하고 고칠 수 있습니다.문제를 해결하면 전체 페이지를 다시 로드하지 않고 그 페이지가 즉시 표시됩니다. Next.js에서 기본적으로 지원되는 웹팩의 hot module replacement 기능을 사용하여 이 작업을 수행합니다.You are Awesome첫 번째 Next.js 애플리케이션을 구현하였습니다! 어떠신가요? 마음에 드신다면 더 많이 배워봅시다.마음에 들지 않는다면 우리에게 알려주세요. Github 저장소의 issue나 Slack의 #next 채널에서 이야기 할 수 있습니다.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유
조회수 1730

IT 서비스 모니터링 제대로 잘하기

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

AWS CodeCommit. 배포 자동화 환경 만들기(브랜치별 Pipeline 구성)

편집자 주: 함께 보면 좋아요!애플리케이션 개발부터 배포까지, 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]브랜디, 오직 예쁜 옷만
조회수 1419

'구루급' 개발자란...

'구루'라는 단어는 이제 '수준급'을 넘어선 분들에게 부여되는 의미 있는 호칭이다. 특히, 개발자 사회에서는 비공식적으로 '구루급'이라고 불리는 개발자들이 있다. 이 정의에 대해서 누가 명확하게 옳다고 이야기할 수 있는 것은 아니다.다만, 30년 동안 소프트웨어 개발자로 살아오면서 만난 수많은 개발자들과 해외 유수의 개발자들과 만나고 소통하면서 느낀 개인적인 경험을 바탕으로 '구루급'에 대해서 정의를 해보겠다.매우 당연하게 이 정의는 전적으로 객관화된 것이 아닌, 매우 주관적인 기준이다.보통, '구루'급 개발자라고 불리는 분들을 보면, 오픈소스로 한 획을 그었거나, 그의 뜻을 따르는 후배들이 많거나, 특정 분야의 경험이 매우 풍부한 분들을 대상으로 이야기한다.다만, 이 기준에 '돈'을 많이 벌었거나, 특정 제품이나 게임, 서비스를 잘 만들었다는 식의 기준은 들어가는 것은 일부 논외로 하겠다. 이것은 전적으로 개인적인 기준이다. 이런 분들은 '구루급'개발자가 되기보다는, 산업적이거나 경제적으로 크게 성공한 기준이 더 높기 때문이며, 금전적으로 성공한 분들이 '후배'들에게 개발자로서의 영향력을 주는 것이 사실상 어렵기도 하거니와, 이미 비즈니스의 단계로 넘어간 분들이기 때문에 '구루급'개발자라고 이야기하기에는 모호하다고 개인적으로 이야기한다.그렇다면, 내가 생각하는 구루급 개발자의 최소한의 필요조건을 나열해 보자. 전적으로 개인적인 기준이니 너무 주관적이라고 비판하지 마시기를... 그 이유는 정말 주관적이기 때문이다.하나. 하나의 소프트웨어나 도메인을 10년 이상 장기간 개발 및 연구하고 있는가?둘. 자신만의 개발 문화에 대한 철학과 그 기준을 가지고 실행하고 있는가?셋. 자신이 소유하거나 만들어낸 개발 도구나 방법, 기술에 대해서 후배 개발자들에게 전파하고 있는가?넷. 후배 개발자들에게 존경받는 개발자로서의 기본적인 성품을 가지고 있는가?다섯. 후배 개발자들에게 자신의 롤을 양보하거나, 팀과 조직을 위해서 자신의 자리를 포기할 줄 아는가?여섯. 자신의 먹을거리를 위해서 비용을 싸게 부르지 않고, 후배들도 대우를 받을 수 있도록 너무 싸게 일하지 않아야 한다는 것을 실천하는가?제가 생각하는 '구루급'개발자의 조건입니다.분명, 이렇게 활동하는 '구루급'개발자들이 주변에 존재하고 있으며, 이를 위해서 개발자의 처우에 대해서 노력하기도 하고, 불합리한 경영자들과 논쟁을 벌이기도 합니다. 자신의 개인적인 이익만을 위해서 움직이지도 않는 그들이야말로 '구루급'개발자 아닐까요?그리고.대부분의 구루급개발자들은 충분한 대우와 보수를 받고 일하고 있습니다.그것이, 후배 개발자들의 처우와 미래를 위해서 매우 필요하다고 생각하고 있기 때문이죠.저는 '구루급'개발자를 그렇게 생각합니다.ps.최고의 개발자, 슈퍼개발자 등에 대한 호칭도 있을 수 있습니다. 제가 생각하는 '구루'급 개발자는 후배들에게 존경을 받고, 후배들의 처우나 개발자들의 미래에 대해서도 고민하고 실천하는 분들에 대해서 정의해 본것입니다.
조회수 2239

모니터링 하지 않는 DevOps 조직은 없다.

출처: https://www.pagerduty.com/blog/devops-monitoring-tools/DevOps 와 모니터링 사용자의 변화DevOps는 이제 너무나 익숙해진 용어입니다. 이미 아마존, 넷플릭스, 페이스북과 같은 우리가 사용하는 많은 서비스들이 DevOps 조직을 가지고 있으며 우리나라에서도 엔터프라이즈 IT 기업들의 운영 조직들은 DevOps로 조직이 변화해가고 있습니다. 그리고 이와 함께 모니터링 서비스에도 변화가 생기고 있습니다. DevOps 이전까지 모니터링 서비스들은 운영팀의 소유였습니다. 개발자들이 서비스를 개발하고 나면 서비스의 안정화까지 운영팀에서는 어플리케이션 성능 분석 모니터링을 위주로 사용하고 어플리케이션이 안정화 되고 나면 급박한 이상 상황에 대비하여 인프라 모니터링을 사용하게 됩니다. 이 모든것은 운영팀의 업무였습니다.  하지만 비지니스의 변화 속도가 빨라지고 서비스의 업데이트가 더이상 이벤트가 아닌 일상이 되어 가면서 기업의 운영팀은 모니터링을 통해 개발 내역을 확인하고 개발팀은 모니터링을 통해 피드백을 받아들이는 구조로 변화해 가고 있습니다. 결국 DevOps에서는 운영팀과 개발팀 모두가 모니터링에 관심을 가지게 됩니다.  DevOps ToolchainDveOps Toolchain은 PLAN - CREATE - VERIFY - PACKAGE - RELEASE - CONFGURE - MONITOR의 연속입니다. 그리고 MONITOR 는 다음번 PLAN을 위한 데이터를 제공해 줄 수 있어야 합니다. 기업이 DevOps를 구체화된 프로세스로 정립하기 위해서는 다양한 도구들을 도입해야 합니다. Toolchain의 모든 스테이지에는 개발과 운영이 의견을 나누고 자동화해나갈 수 있는 다양한 도구들이 제공 되고 있습니다. 이는 모니터링에서도 마찬가지 입니다. 출처: http://blog.launchdarkly.com/devops2/DevOps for MonitoringDevOps에서 모니터링은 인프라스트럭처에서 어플리케이션 뿐만 아니라 로깅과 비지니스까지 매우 넓은 범위를 모니터링 하게 됩니다. DevOps 팀은 인프라와 어플리케이션의 상관관계를 알 수 있어야 하며 지나간 데이터는 물론이고 현재의 데이터를 실시간으로 분석할 수 있어야 합니다. DevOps 조직에서 사용하는 모니터링은 크게 아래와 같이 나눌 수 있습니다.Infrastructure and Network Monitoring서버, 라우터, 스위치를 포함한 Infrastrucre와 Network 전반에 대한 모니터링을 제공합니다. Nagios, Zabbix 와 같은 오픈소스 기반의 솔루션이 많이 제공되고 있습니다. 해외 서비스로는 DataDog 이 유명하며 국내에서는 WhaTap 이 Infrastructure 모니터링을 제공하고 있습니다. DataDog은 대규모 서버를 한눈에 볼수 있는 벌집 구조의 데시보드로 유명합니다. Application Performance Monitoring어플리케이션  성능 모니터링은 고객의 트랜잭션을 분석하는 동적 분석 도구 입니다. 웹 서비스를 운영하는 과정에서 성능 이슈가 발생하는 경우 해당 지점을 찾는 용도로 사용됩니다. 신속한 버그 추적과 재발 방지를 위해서도 사용될 수 있으며 최소 응답시간을 지속적으로 유지하기 위한 필수 서비스입니다. 좀더 능동적으로 APM을 사용한다면 발생 빈도가 높은 메소드를 분석하여 코드 리팩토링에 사용 할 수도 있습니다. 오픈소스로는 네이버의 핀포인트 와 와탭의 CTO가 커미터로 참여하고 있는 스카우터 가 있습니다. 해외에서는 New Relic, AppDynamics 가 유명하며 국내에는  WhaTap 이 APM 서비스를 제공하고 있습니다. 와탭의 트랜잭션 분포도는 APM 서비스중 데이터 분석 간격이 가장 짧은 것으로 알려져 있습니다.Log Analysis로그 분석은 플랫폼에서 제공하는 시스템 로그를 분석하거나 커스터마이징된 로그 데이터를 분석하는 도구입니다. 로그 분석을 통해 시스템의 결함을 미리 알아낼 수도 있으며 비지니스 데이터를 분석할 수 도 있습니다. Splunk, Elastic, PaperTrail, Logstash,  Loggly,  Logentries,  SumoLogic 과 같은 벤더를 통해 서비스를 제공받을 수 있습니다. 결론DeveOps는 개발과 운영이 만들어 가는 문화이기도 하지만 많은 도구의 도움을 받아서 진행해야 하는 프로세스이기도 합니다. 모니터링 서비스는 개발과 운영이 함께 서비스를 개선할 수 있게 해주는 중요한 도구입니다. 많은 모니터링 도구들이 DevOps를 지원하고 있습니다. 다양한 모니터링 도구와 서비스를 잘 이용한다면 DevOps 조직을 더욱 탄탄하게 만들고 비지니스도 빠르게 성장시킬수 있을 것입니다. 출처: https://blog.appdynamics.com/engineering/5-challenges-for-a-successful-enterprise-devops-model/관련 글https://techbeacon.com/10-companies-killing-it-devops10 companies killing it at DevOpsTop companies have made the move to DevOps and serve as the framework for others ready to make the move. Is your company ready for a DevOps...techbeacon.com https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr10+ Deploys Per Day: Dev and Ops Cooperation at FlickrCommunications and cooperation between development and operations isn't optional, it's mandatory. Flickr takes the idea of "release early, release often" to an…www.slideshare.net https://en.wikipedia.org/wiki/DevOps_toolchainDevOps toolchain - Wikipediaen.wikipedia.org http://blog.launchdarkly.com/devops2/DevOps 2.0Decoupling feature rollout from code deployment and the rise of user-centered deploymentsblog.launchdarkly.com https://aws.amazon.com/ko/devops/what-is-devops/데브옵스란 무엇입니까? – Amazon Web Services(AWS)aws.amazon.com #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

기업문화 엿볼 때, 더팀스

로그인

/