스토리 홈

인터뷰

피드

뉴스

조회수 2023

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 버전이라 부족한 부분이 보이지만, 개선될 것이라고 믿고 계속 사용할 거 같아요.앞으로 발전하는 모습 기대하겠습니다 파이팅!#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑
조회수 1144

어제의 실수는 오늘의 노하우!

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]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1824

스켈티인터뷰 / 스켈터랩스의 잡학다이너마이트 변규홍 님을 만나보세요:)

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 잡학다이너마이트 변규홍 님을 만나보세요:)PART1. About Skelter Labs사진1. 스켈터랩스의 소프트웨어 엔지니어, 변규홍 님Q. 간단한 자기소개를 부탁한다.A. 이름은 변규홍. 스켈터랩스에서 소프트웨어 엔지니어로 일하며, 컴퓨터에게 열심히 한국어를 가르치고 함께 배우고 있다. 대충 20년 전부터 컴퓨터 공부를 시작해서 컴퓨터 관련된 일이라면 사족을 못쓰는 덕후이기도 하다.Q. 현재 스켈터랩스에서 어떤 업무를 맡고있는가.A. 스켈터랩스의 인공지능 대화 엔진 개발 팀인 헤르메스(Hermes)에서 흔히 ‘챗봇’이라 부르는 인공지능 대화 엔진을 만들고 있다. 우리가 만드는 인공지능 대화 엔진은 ‘챗봇을 만들고자 하는 사람들이 누구나 쉽게 챗봇을 만들도록 돕는 편리한 사용'을 목표로 한다. 때문에 비개발자도 이해하기 쉽도록 효율적이고 간편한 UI와 구조로 개발하고 있다. 거기서 나는 어떻게 하면 컴퓨터가 사람이 하는 말을 더 잘 알아듣고 잘 대답할 수 있는지 연구하고 있다. 어떤 처리를 해야하는지, 언어의 어떤 패턴을 인식하는지 등 ‘자연어 처리(Natural Language Processing,NLP)’ 혹은 자연언어처리라고 불리는 기술 전반에 대한 연구를 진행하고 있다.Q. 자연어 처리라는 부분이 생소하다. 언어의 분석이나 처리에 대한 얘기를 더 해줄 수 있나.A. 챗봇 위주로 설명해 보자. 우리가 한국어 문장을 컴퓨터나 스마트폰에 입력할 때, 특히 채팅할 때는 문장의 변화가 심한 편이다. 띄어쓰기를 실수할 수도 있고 급식체같은 축약어를 사용하기도 한다. 같은 의도를 담은 문장이 아주 다르게 표현되는가 하면, 비슷한 문장이 어순이나 표현 한 두 가지만 바뀌어도 전혀 다른 뜻이 되기도 한다. 이러한 인간의 언어를 컴퓨터가 잘 알아들을 수 있도록 분석하고 처리하는 것이다. 입력된 문장에서 어떤 부분이 명사고 어떤 부분이 동사인지를 찾거나, 문장 속에서 어떤 형태소에 집중해야 하는지 분석한다. 그리고 은행 계좌나 전화번호처럼 규칙에 맞는 숫자가 다양하게 입력될 수 있는 경우를 찾아내기도 한다. 이런 과정을 거쳐 사람이 어떤 의도를 갖고 입력한 문장인지, 어떤 정보가 담겨있는지 식별해낼 수 있다.Q. 들어보니 기술에 대한 지식뿐만 아니라 언어학에 대한 조예가 필요한 분야로 보인다.A. 맞다. 이 분야를 전산학(컴퓨터공학)에서는 ‘자연언어처리’라고 하고 언어학에서는 ‘전산언어학(Computational Linguistics)’ 혹은 ‘계산언어학’이라고 한다. 학제 간 학문으로서의 성격이 강한 분야다. 초창기에는 언어학자들이 찾아낸 인간 언어의 구조, 규칙을 컴퓨터공학자 / 전산학자들이 프로그램으로 구현하는 연구가 많았다. 그러다가 애초의 예상보다 인간의 언어 구조가 훨씬 더 복잡하다는 것을 인식한 이후부터는 인간의 언어에서 규칙성을 찾는 과정도 통계적 방법 등을 통해 컴퓨터의 힘을 빌리게 되었다. 최근에는 요즘 화두인 머신러닝 기법을 적극적으로 적용하면서 연구 트렌드가 조금씩 바뀌고 있다. 다양한 규칙에 따라 문장을 분석하기보다, 빅데이터로 정리된 방대한 언어생활 자료를 컴퓨터 스스로 학습하여 문장 속에서 필요한 정보를 찾아내는 식으로의 전환이랄까. 하지만 여전히 좀 더 좋은 결과물을 내려면 언어학에 대한 지식과 규칙성에서 찾아낸 정보들이 필요한 것도 사실이다. 그래서 스켈터랩스에서는 규칙 기반 기법들과 머신러닝 기법 모두를 하이브리드 형태로 결합하여 대화 엔진을 개발하고 있다.Q. 아무리 다양한 형태로 기법을 결합하여 사용하더라도, 엔지니어가 언어학에 대해 연구하기는 쉽지 않아 보인다. 언어학을 별도로 공부하거나 혹은 언어학에 대한 관심을 이전부터 가지고 있었는지.A. 언어학이라기보다는 사실 나는 대학교에서 문학 동아리 활동을 오랫동안 했다. 자연스럽게 다양한 활동을 통해서 문학에 대한 얘기를 하다 보니 언어에 대한 관심도 꽤 높았던 것 같다. 무엇보다 구글코리아의 번역기 개발팀에서 인턴을 하며, 컴퓨터로 인간의 언어를 다루는 것이 굉장히 흥미롭다고 생각했고 꾸준히 관심을 이어왔다. Q. 구글 코리아 인턴 경험이 규홍님에게 여러모로 지대한 영향을 끼친 것으로 알고 있다. 그 얘기를 듣고 싶다.A. 대학에 처음 입학했을 때, 사실 실망감이 더 컸다. 합리적인 의사소통은 막혀있었고, 당시 학교의 학사제도 개편으로 인해 여러모로 시끄러운 상황이었다. 그러던 차에 마침 학교에 구글코리아에서 캠퍼스 리쿠르팅을 왔는데, 선배 중 한 명이 ‘왜 구글은 한국에서 인턴을 채용하지 않습니까' 라고 꽤나 당돌한 질문을 던졌다. 그렇게 구글 코리아 인턴 채용이 열려 면접 기회를 얻게 되었다. 당시 내 이력서에는 대학교 입학 후의 경력이라고는 연극동아리 공연 이력이 전부였기 때문에 일종의 두려움도 컸다. 하지만 일본어로 된 만화책을 컴퓨터에 넣으면 한국어로 번역된 만화책이 튀어나오게 하고, 컴파일(COMPILE) 사의 게임 중 미처 한국어로 번역되지 못한 게임들을 컴퓨터가 알아서 번역해 즐길 수 있게 하는, 그런 컴퓨터 프로그램을 직접 만들고 싶다는 꿈이 더 컸다. 마침 나의 면접관들도 구글 코리아 번역기 개발팀 분들이었다. 그렇게 구글 코리아 번역기 개발팀 인턴으로 입사하게 되었고, 그때의 경험이 나의 꿈의 실현 가능성에 대한 일종의 확신을 주었다.Q. 스켈터랩스에는 어떻게 입사하게 되었나A. 인턴 할 당시의 구글 코리아 사장이 지금 스켈터랩스 창업자, 조원규 대표님이다. 그리고 구글 코리아 면접관이었던 분이 우리 팀의 테크 리더(Tech Leader)를 맡고 있는 이충식 님이기도 하다. 작년 충식 님으로부터 어려운 문제를 풀어야 하는데 같이 한번 풀어보자는 연락을 받았다. 그 문제가 너무 어려울 것 같아서 답장을 망설이고 있었다. 그러다 이전 직장에 대한 염증과 새로운 일에 대한 호기심 등의 마음으로 충식님을 다시 만나 뵈니, 스켈터랩스에서 내가 어렸을 적 꿈꾸던 챗봇을 만들고 계셨다.Q.  스켈터랩스에서의 업무는 이전에 일했던 혹은 알고 있는 다른 개발자의 업무랑 어떻게 다른가. A. 사실 인공지능을 기반으로 한 스타트업에는 뛰어난 사람들이 많은 것 같다. 그러나 스켈터랩스가 다른 회사와 다른 점은 ‘내 동료가 누구인가'에 대한 인식의 범위가 조금 더 넓다는 점이다. 가령 디자이너는 디자이너끼리, 기획자들을 기획자끼리만 협력하고 부서에 따른 책임이나 업무 범위에 대해서 선을 긋는 문화가 흔히 있지 않나. 어떤 직장들은 수직적인 위계 구조를 강요하고 모든 걸 서류로 보고하게 만들기 때문에 일의 효율이 떨어지기도 한다. 그러나 스켈터랩스는 팀 간에, 직무 간에 서로의 업무 영역을 자로 재듯 규정하지 않고 넘나들며, 좀 더 활발한 소통을 추구한다. 덕분에 ‘하나의 공동체'라는 인식을 자연스럽게 가질 수 있다. 서로와 함께 일한다는 것에 대해 우리 스스로 가지는 자긍심도 대단하다. 사내에는 지인을 신규 입사자로 추천하는 채용 제도가 있는데, 그간 내가 일해왔던 회사 중 우리 회사만큼 열심히 지인들에게 추천하는 회사도 없었다. 사실 내가 일하는 회사가 별로면 친구에게 추천도 못 하지 않겠나. 그만큼 서로 만족하고, 자부심을 가지고 일한다는 것을 방증하는 면모인 것 같다.또한 스켈터랩스는 불필요한 서류 업무를 배제하는 대신, 아주 엄격한 코드 리뷰 시스템을 가지고 있다. 내가 과거에 근무했던 회사들은 많은 경우 상대적으로 지금 당장 작동하는 코드를 만들어 내는 것에 집중했다. 물론 이러한 방식이 때로는 실용적이다. 그러나 기능이 잘 작동되는지만 살피다 보니, 숨겨진 버그(Software Bug)가 남겨지고 이것이 뒤늦게 발견되어 더 큰 문제를 일으키기도 했다. 때로는 버그의 존재를 코드 작성자만이 알고 있기도 했다. 이렇듯 단기간 눈앞의 기능에만 집중하다가 코드의 품질이 저해되는 방식으로 개발이 진행되어 언젠가는 다시 수정해야 하는 일거리가 남겨지는 것을 ‘기술 부채(Technical Debt)’라고 부른다. 스켈터랩스의 코드 리뷰 문화는 사소한 영역까지 기술 부채를 남기지 않는다. 궁극적으로는 짧은 기간 완성도 높은 프로그램을 만들 수 있게 해주는 문화다. 엄격한 코드 리뷰가 가능한 것은 스켈터랩스의 개발자 역량이 높기 때문이기도 하다. 개발자들이 모두 기술에 대한 근본적인 이해와 최신 기술에 대한 섭렵을 두루 갖추었기에 타인이 작성한 코드도 바로 이해할 수 있다. 수준 높은 동료와 함께 일하며 피드백 받고 성장할 수 있다는 것은 회사의 굉장한 강점이라고 생각한다.사진2. 규홍 님과 다른 팀원 간의 코드 리뷰 모습.Q. 코드 리뷰 문화가 유익하기도 하지만, 일종의 압박감도 있을 것 같다. A. 압박감으로 여겨본 적은 없다. 한국 사회에서 개발자의 커리어에 대한 얘기를 나누다 보면 자연스럽게 ‘회사 일을 하다 보니 공부할 시간이 없어서 최신 기술을 알지 못해 뒤처진다.'라는 볼멘소리가 나온다. 그러나 스켈터랩스에서는 개발자 모두가 엄격한 코드리뷰를 거치는 과정에서 자연스럽게 더 나은 성능의 코드, 동료가 더 잘 이해할 수 있는 코드, 예상치 못한 예외 상황을 고려하는 코드를 작성하는 법을 실시간으로 배우게 되고, 때로는 그 과정에서 자연스럽게 코드 리뷰자가 제안하는 최신 기술에 대해 공부하고 습득하며 실력을 늘려나간다. 덕분에 코드 리뷰를 마치고 나면, 다음에 어떻게 해야 개선된 코드를 짤 수 있을지에 더 집중할 수 있고 실제로도 더 나은 코드를 작성할 수 있게 된다.물론 이런 문화가 신규 입사자로서는 다소 답답할 수 있을 것 같다. 나 또한 초반에는 ‘굳이 이런 디테일까지 다 잡아가며 이렇게 리뷰를 남겨야 할까'라는 생각을 해본 적도 있다. 그러나 스켈터랩스와 함께하는 시간이 점점 길어질수록, 꼼꼼한 리뷰로 기술 부채를 최소화하는 것이 팀 전체에도, 나의 성장에도 도움이 된다는 걸 느낀다.Q. 아무리 뛰어난 개발자가 있더라도 코드를 작성하는 사람은 한 명인데, 이를 함께 리뷰하다보면 작성된 코드를 이해하지 못하는 경우가 발생하지는 않나.A. 물론 그럴 수 있다. 때문에 스켈터랩스에서는 코드의 공동 소유, 공동 이해 개념을 깊이 이해하고, 잘 지킬 수 있게 만든다. 나만 이해할 수 있는 코드를 작성하면 장기적으로 다른 개발자들의 수정과 응용이 어려워진다. 그래서 스켈터랩스에서는 각 프로그래밍 언어별로 코딩 스타일 가이드를 준수할 것을 권장하고, 코드 리뷰 이전에도 가이드 준수 여부를 점검하는 도구를 활용하고 있다.Q. 스켈터랩스를 자랑한다면.A. 스켈터랩스는 아직 성장 중인, 그래서 ‘함께 만들어 갈 여지가 많은 회사'다. 나는 개인적으로 대기업부터 창업 초창기 단계의 스타트업까지 다양한 회사를 경험했는데, 이러한 과정에서 구성원 한 명 한 명이 회사의 문화와 기술적 원칙을 만들어가는데 얼마나 큰 영향을 주는지를 느꼈다. 스켈터랩스는 다양한 배경을 가진 개발자와 서로 영감을 주고받으며 함께 성장해가는 곳이다. 개발자 직군의 동료들과 비개발자 직군의 동료들이 끊임없이 소통하며 시행착오와 함께 점점 더 나은 기업문화를 만들어가고 있다. 그리고 실제로 이런 문화가 완성도 높은 프로그램을 만드는 데에 긍정적인 기여를 하고 있고, 현재는 성공 경험을 조금씩 안겨주고 있는 단계다. 역량 있는 인재들과 최신의 기술을 활용하여 새로운 결과물을 창출하는 것에 관심 있는 이들이라면 입사를 추천하고 싶다.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #개발팀 #팀원인터뷰 #팀원소개 #팀원자랑
조회수 2145

왜 차세대 SaaS는 페이스북처럼 될 것인가.  

사람들이 매일 사용하는 서비스 중 가장 유용한 것은 무엇일까?대부분의 경우에 있어, 그것은 Slack, Gmail 혹은 Excel 같은 SaaS 툴이 아닐 것이다. 그것은 바로 페이스북이다.페이스북으로 할 수 있는 모든 것들에 대해 생각해보자.친구들에게 메시지 보내기 영상 통화 하기 뉴스 보기 이벤트 기획하기 사진과 동영상 공유하기사람들은 페이스북에 얼마나 많이 의지하고 있는 지 종종 잊어버리지만, 페이스북은 이미 우리의 일상 생활에 아주 깊숙이 자리잡고 있다. 오늘날에는 수 백만 개의 서비스가 존재하지만, 그들은 그럼에도 만족할 줄을 모른다. 그리고 페이스북은 SaaS 회사들이 할 필요가 있는 것들을 정확히 집어서 하고 있다.On-premise(인하우스 서비스)에서 SaaS(클라우드 컴퓨팅)로SaaS는 “Software as a Service.” 의 약자이다. 페이스북은 사실 기술적으로 SaaS라기 보다는, 일종의 소비자 네트워크 서비스라고 할 수 있다. 하지만 페이스북만큼 많은 서비스를 제공하는 곳은 존재하지 않는다. 페이스북이 이렇게까지 성공한 것은 그 서비스 내에서 유저들의 이용률을 크게 늘렸기 때문이다. 다른 SaaS 기업들은 이 부분을 더 신경 써야 될 필요가 있다. 이용률이야말로 지금 SaaS 비즈니스의 생존에 있어 그 어느 때보다 중요하기 때문이다.그 이유는 다음과 같다. 예전에, 소프트웨어는 회사의 컴퓨터 네트워크에 실제 물리적으로 깔려야만 했다. 소프트웨어 판매업자들은 대기업에 라이선스를 팔기도 했고, 그런 기업들은 해당 소프트웨어 이용을 위해 Accenture나 CSC 같은 회사에 돈을 지불하기도 했다. 당시 판매업자들은 라이선스를 많이 팔기만을 원했지, 얼마나 많은 사람들이 그 소프트웨어를 쓸 지에 대해선 관심이 없었던 것이다.그리고 1999년, Salesforce의 공동 창업자인 Marc Benioff는 새로운 모델을 소개하며 다음과 같이 말했다.“설치하는 데만 수 개월이 걸리고 하드웨어와 네트워킹에 엄청난 투자를 요구하는 비싼 CD-ROM 소프트웨어를 기업들에게 파느니, 우리는 클라우드 컴퓨팅이라고 알려진 모델을 통해 Software-as-a-Service(SaaS)를 팔기로 했다. 기업들은 이제 유저의 수에 맞춰 서비스를 이용한 만큼 비용을 지불해야 할 것이고, 그런 서비스들은 인터넷, 클라우드를 통해 즉시 제공될 것이다.”구독 기반(subscription-based) 소프트웨어는 회사 내부의 데이터 센터가 아닌 웹 브라우저를 통해 제공된다. 이는 소프트웨어 개발자로 하여금 언제든지, 즉각적으로 그들의 고객에 접근할 수 있게 해주었다. 어느 순간, 유저를 만족시키는 일은 CIO(Chief Information Officer)나 시스템 통합업체의 책임이 아니게 된 것이다. 그 일은 이제 소프트웨어 판매업자가 하게 되었다.이러한 클라우드 컴퓨팅 방식은 SaaS 소프트웨어로 하여금 생존을 위해 끊임없이 자신들의 가치를 어필하게끔 만든다. 그리고 SaaS 회사들은 계속해서 자신들의 소프트웨어를 이용하는 소비자들을 확보하기 위해 많은 양의 돈을 쓰고 있다. 이는 과거 기업 고객들에게 소프트웨어 라이선스를 팔러 다니던 때와는 180도 달라진 상황인 것이다. 오늘날의 SaaS 회사들은 예전처럼 높으신 몇몇 분들을 만나 무언가를 사라고 설득할 필요가 없다. 그저 이용자들이 자신들의 제품을 계속 사용하게끔 유도하면 되는 것이다.페이스북은 SaaS의 새로운 모델이다이제 페이스북을 한 번 살펴보자. 페이스북은 클라우딩를 통해 지속적으로 서비스를 제공한다. 그들은 광고를 통해 돈을 벌기 때문에, 그들의 가장 중요한 목표는 사람들로 하여금 계속 서비스를 이용하게 하는 데 있다. CIO들을 만나서 큰 계약을 체결하는 데 시간을 쓸 바에야 그 100분의 1초도 안 되는 시간에 12억 명의 사람들에 서비스를 파는 것이 더 낫다는 것이다.페이스북이 딱 한 가지 신경 써야 될 것이 있다면 그것은 사람들이 지금보다 더 적극적으로 페이스북을 이용하게끔 만드는 것에 있다.“우리의 최우선 목표는 모바일 장치나 개인용 컴퓨터를 통해 사람들을 연결시켜주고 공유하게끔 하는 유용하고 매력적인 서비스를 창조하는 것에 있습니다.” – 미국증권협회 기업정보 페이지의 페이스북 파일에서페이스북이 사람들의 관심을 많이 받을수록, 그들은 더 많은 광고를 사람들에게 보여줄 수 있다. 페이스북에게 있어서, 그러한 관심은 아주 중요한 것이다. 더 많은 관심을 받는 다는 것은 더 많은 성장과 확장의 기회를 갖는 다는 것을 의미하기 때문이다. 이것은 드롭박스나 Slack과 같이 바텀업 방식으로 성장한 SaaS 기업들이 새겨들어야 할 점이다. 유저들이 서비스를 쓰는 시간이 많아진다면, 앞으로 그들에게 더 많은 다른 서비스를 쓰게 만들 수 있기 때문이다.앞으로 페이스북이 더 성장하고 발전하려면 유저의 관심이 필요하다. 그래야 여러 방면에서 이용률을 늘릴 수 있는 방법을 찾을 수 있기 때문이다. 이제 여기서 페이스북이 그들 서비스의 이용률과 성장을 이뤄낸 3가지 방법에 대해서 소개해 보도록 하겠다. 모든 SaaS 기업들은 비슷한 방법으로 자신들의 이용률과 성장을 이뤄낼 수 있을 것이다.페이스북은 이용률을 측정하여 현재 운영하는 서비스를 최적화 시켰다페이스북은 이용률을 늘리기 위해 새로운 서비스를 내놓는다페이스북은 다른 앱들과 통합하는 과정을 거쳤기 때문에 페이스북을 쓰지 않는 사람들조차 페이스북을 쓰게 되었다페이스북이 이용률을 어떻게 늘렸는지에 대해 좀 더 깊이 이야기해 보도록 하겠다. 그러고 나면 페이스북의 노하우를 다른 SaaS에 어떻게 적용할 수 있을 지 분명하게 보여줄 수 있을 것이다.이용률 측정을 통해 서비스의 최적화를 이뤄낸다지금 사람들이 어떻게 서비스를 이용하고 있는 지 모르고 있다면 그들에게 당신의 서비스를 사용하게 만들 수도 없을 것이다. 페이스북은 이용률을 늘리는 방법에 대해 집요하게 연구해왔기 때문에 좋은 사례로 들기에 적합하다.핵심은 사람들이 지금 하고 있는 것, 그리고 그들이 원하는 것을 정확하게 아는 것에 있다. 페이스북은 단순히 월 이용자 수나 일 이용자 수를 알아보려 애쓰지 않는다. 왜냐하면 그런 수치들은 사용자들이 그 서비스를 통해 무엇을 하는지를 전혀 설명하지 못하기 때문이다. 대신 페이스북은 서비스 이용의 질적인 부분에 집중한다. 사람들이 페이스북을 통해 무엇을 이루려고 하는 지와 그들이 실제로 그렇게 할 수 있는 지에 대해서 말이다.이 부분에 있어 페이스북의 대표적인 전략 중 하나가 바로 10일안에 친구 7명 만들기이다. 일찍이, 페이스북은 10일안에 7명의 친구를 만드는 사람은 페이스북을 계속 사용할 확률이 훨씬 더 높다는 사실을 알게 되었다. 일단 이것을 알게 되자, 그들은 신규 유저들이 7명의 친구를 만날 수 있게 하기 위해 가진 모든 수단을 쓸 수 있게 된 것이다.바로 지금도, 페이스북은 새로운 친구를 추가할 것을 사람들에게 계속해서 권장한다. 왜냐하면 이것이야 말로 네트워크를 이루는 데 있어서 가장 가치 있는 부분이기 때문이다.페이스북 계정을 만들자마자, 유저들은 뉴스 피드 상단에 새로운 친구를 추가하시겠냐는 메시지가 뜨는 것을 볼 수 있다.아래 사진은 유저들이 다른 페이지를 둘러 보는 동안 뜨는 사이드바인데, 보다시피 그들이 알 수 있을 법한 사람들을 친구로 추가하게끔 권장하고 있다.또한 페이스북은 뉴스 피드와 같이 그 기능을 최대한 활용하기 위해 더 많은 친구들을 추가할 것을 권장하고 있다.페이스북은 이런 전략을 앞으로도 고수할 것이다. 2017년, 페이스북은 “Discover people” 이라는 새로운 기능을 출시했다. 이는 당신으로 하여금 프로필을 업데이트 하게끔 유도하고 기존에 친구가 아니더라도 같은 이벤트에 참여하는 경우 서로를 연결시켜 준다.페이스북은 사람들이 자신들의 서비스를 계속 이용하게 만들기 위해 기나긴 세월 동안 노력해왔고 앞으로도 그럴 것이다. 그들은 친구 최적화를 빠르게 해줄 뿐만 아니라 흥미를 잃은 사람들도 쉽게 다시 돌아올 수 있도록 여러 요인들을 제공해준다. 페이스북의 성장 전담 부서를 이끌고 있는 Chamath Palihapitiya은 “당장의 단기적인 이익에만 집중하지 않기 위해서는 절제력이 필요하다.” 라고 말한다. 페이스북은 초창기부터 무엇보다 사람들의 이용률이야말로 그들의 성패를 좌우한다는 것을 알고 있었다. 사람들의 주된 목표를 파악해서 이용률을 장기적으로 늘리는 것이 그들의 제1과제 였던 것이다.Trello는 어떻게 유저들이 쉽게 직장 동료를 추가하도록 만들었는가페이스북과 똑같이, Trello는 유저들이 무엇을 하는지를 이해하고 그들이 원하는 걸 더 많이 하게 도와주는 방식으로 이용률을 올렸다. Trello의 핵심적인 가치는 사람들이 프로젝트를 협력하게끔 만드는 것이었기 때문에, 그들이 그렇게 하도록 도움을 줘서 자신들 서비스의 가치를 보여줘야 했다.그래서 Trello가 직장 동료를 추가하는 방식은 놀라울 정도로 쉽게 되어 있다. 이는 페이스북이 친구를 추가하는 방식과 정확히 똑같다. 페이스북이 사람들로 하여금 쉽게 친구를 추가하게 하여 소셜 네트워크의 가치를 입증했다면, Trello는 쉽게 동료들을 추가하게 하여 프로젝트 협업 툴로써의 가치를 입증했다.Trello는 유저들로 하여금 이름이나 이메일 주소로 아는 사람들을 등록할 수 있게 만들었다. 유저들은 코드나, ID, 링크 같은 것 없이도 사람들을 쉽게 추가할 수 있다. 심지어 다른 사람들이 Trello를 사용하는지도 알 필요가 없다. 어찌 됐든 Trello를 통해 사람들을 찾아보고 확인해 볼 수 있는 것이다.또 만약 Trello를 한 번이라도 썼던 사람이라면 더욱 쉽게 목록에 추가할 수 있다.이런 방식을 통해 이용자들은 아무런 마찰 없이 많은 동료, 협력자들을 통해 프로젝트를 공유할 수 있다. 즉, Trello의 핵심 가치를 이루게 되는 것이다. 이는 사람들에게 Trello가 얼마나 유용한 서비스인지를 빠르고 쉽게 이해시켰다. 또한 이는 더 많은 사람들이 더 많은 프로젝트를 하게끔 유도했고, 결국 모두가 Trello를 더 많이 이용하게 되었다.Slack은 어떻게 이용률을 늘려왔는가이렇게 사용자의 이용률에 집중해서 성장을 이루고 있는 유명한 SaaS 기업이 또 하나 더 있다. Slack이 바로 그 기업인데, Slack은 메시지를 매끄럽게 전송하는 역할 하나에만 전념하고 있다.Slack은 자신들의 서비스를 이용해 2000개 이상의 메시지를 보낸 적 있는 팀들은 Slack의 가치를 알고 있기 때문에 앞으로도 계속 서비스를 사용할 것이라고 예측한다. 왜냐하면 Slack의 통계에 따르면, 다른 요소들이 어떻든 간에, 2000개 이상의 메시지를 보낸 팀들 중 93%가 지금까지도 Slack을 사용하고 있기 때문이다. 그래서 이용률을 늘리기 위해선, 메시지를 보내는 것을 더 쉽게 만들어야 하는 것이다. Slack의 공동 창업자인 Stewart Butterfield 역시도 이 목표를 위해 사람들이 실제로 어떻게 Slack을 쓰고 있는가에 대해서 생각해보았다.“처음으로 Slack을 쓰려고 온 사람이 되었다고 생각해 보는 겁니다. 특히 진짜 사회생활을 하는 사람들 말이죠. 상사에게 Slack을 쓰라고 해서 쓰게 된 사람, 아침 먹을 시간도 없어서 짜증이 난 사람, 주말이 오기 전에 프로젝트를 끝낼 수 있을지 걱정하는 사람… Slack을 면밀히 살펴봐서, 이런 사람들에게 먹히지 않을 것 같은 요소들을 생각해 내는 겁니다. 냉정하게 보는 거에요. 최고의 서비스를 주기 위해서 말이죠.”Slack은 메시지 전송에 따르는 불편함을 개선하면서 이용률을 늘려왔다. 그러한 개선의 예를 들어 보자면, 누군가가 Slack에서 링크를 걸었다고 했을 때, Slack은 그 링크에 대한 간단한 정보를 미리 보여준다. 즉, 사람들은 링크를 보려고 앱에서 빠져나와야 될 필요가 없는 것이다. 나중에 다시 그것을 확인해보기도 편하고 말이다.이런 시스템상의 개선점들이 Slack을 성장하게 만들었다. 메시지를 보내는 것에 있어서 사람들이 원하는 부분을 아주 쉽게 할 수 있게 만들었기 때문이다.이렇듯 페이스북, Trello, Slack은 모두 실제 이용자들이 원하는 것을 이해하고 그들이 그것을 쉽고 빠르게 할 수 있는 서비스를 제공하고 있다. 아래에 이런 SaaS 기업들이 어떻게 자신들의 서비스를 통해 이용자들에게 도움을 줬는지 요약해보았다.페이스북의 10일안에 친구 7명 만들기, Slack의 2000개 이상의 메시지 보내기, Dropbox의 파일 한 개 업로드 하기 등과 같이 그들은 수치로 표시되는 목표를 세웠다. 이러한 목표는 당신의 팀으로 하여금 무엇이 가장 이용률을 끌어오는데 중요한 지를 확인시켜줄 뿐만 아니라 그들에게 목표 달성을 위한 구체적인 숫자를 알려준다.핵심적인 기능들을 사람들이 이용하게 하려면 그것을 직관적으로 만들어야 한다. Raymond Loewy(미국의 전설적인 산업 디자이너)에 따르면, 성공적인 서비스는 사람들이 당장 사용하기에 편해야 한다고 한다. 예를 들어, 페이스북이 처음 “On this day” 서비스를 도입한 것은 유저들로 하여금 무언가 새로운 것을 하는 걸 권하기 위해서였다. 하지만, 이 서비스는 여전히 유저들에게 친숙한 태그, 공유하기 기능들을 사용하고 있다.유저들의 참여를 막을 만한 요소들을 찾아서 없애야 한다. 사용자들이나 얼리 엑세스 베타 테스터 등과 이야기를 해봐서 무엇이 서비스에 있어 가장 짜증나는 요소인지 알아내야 한다. “이거 어떻게 하는 건지 모르겠어요” 라던가 “이게 좀 쉽게 됐으면 하는데…” 와 같은 불만들에 귀기울여야 한다. 이런 장애물들을 제거하면 유저들이 서비스를 이해하기 더 쉽고 그 서비스의 가치를 파악하는 것 역시 쉬워진다.즉, 현재 가지고 있는 서비스 내에서 이용률을 끌어올리려면 유저들에게 무엇이 가장 도움이 되고 의미가 있는지 파악하는 것이 가장 중요하다고 할 수 있다.이용률을 늘리기 위해 서비스를 추가한다이용률을 끌어올린다는 것은 단순히 사람들로 하여금 기존의 서비스를 계속 쓰게 만드는 것 만을 의미하지는 않는다. 당신은 끊임없이 실험을 해보고 새로운 서비스를 제공해서 유저들이 서비스를 통해 더 많은 것들을 얻을 수 있도록 해야 한다.페이스북은 기존에 그들이 가진 서비스가 수명이 다할 것을 걱정해서 계속 실험을 하고 이용자들이 앞으로 무엇을 원할지를 예상해왔다.페이스북의 직원 가이드북을 보면, 새로운 직원들은 그들의 팀이 계속 새로운 생각을 하게끔 자극 할 것을 권장하고 있다.그 결과, 페이스북은 끊임없이 혁신하고, 또 그만큼 실패를 경험하고 있다.페이스북은 스냅챗으로부터 이용자들을 뺏어오기 위해 2012년 별도의 앱인 Poke를 출시한다. 그런데 이 앱은 대실패작이 되었고 페이스북은 얼마 지나지 않아 앱스토어에서 이 앱을 삭제하게 되었다.2014년에 페이스북은 이용률을 늘리기 위한 일환으로 슬링샷이라는 앱을 출시했다. 이 앱은 사진과 함께 메시지를 보내면 스냅챗과 같이 몇 초안에 사라지는 것이 특징인데 불과 1년만인 2015년에 앱스토어에서 내려가게 되었다.또 페이스북은 2016년 Quick Update라는 것을 시도했다. 이는 스냅챗과 비슷한 기능을 페이스북 앱에 추가시키는 것이었는데, 이런 기능을 유저들을 대상으로 그룹테스트 해 본 결과 반응이 좋지 않아 결국 공식적으로는 출시되지 못하게 되었다.이런 좋지 않은 결과들은 페이스북이 혁신에서 실패하고 있다는 소문을 자아냈다. Jason Calacains 같은 논평가는 이에 대해 “페이스북의 앱 플랫폼은 망하기 위해서 혁신을 하는 것인가?” 라고 하기도 했다.하지만 페이스북의 이런 계속되는 시도는 결국 그들을 새로운 기회로 인도했다. 그들은 스냅챗의 스토리 기능을 페이스북과 인스타그램에 도입하려고 시도해 왔는데 이 과정에서 마침내 페이스북 라이브라는 새로운 서비스를 만들어냈다. 이 서비스는 대히트를 쳤고, 이제 회사, 미디어, 그리고 유명인사들까지 모두 페이스북의 라이브 스토리를 사용하고 있다.이렇듯 페이스북이 큰 성공을 거둘 수 있었던 이유는 그만큼 실패도 많이 해봤기 때문이다. 그들은 그저 사람들이 관심 가질 만한 새로운 무언가를 계속 만드는데 집중할 뿐이다. 왜냐하면 이런 시도야말로 궁극적으로 이용률을 더 많이 올릴 수 있는 방법이기 때문이다.드롭박스 역시 이용률을 높게 유지하기 위해 새로운 서비스를 만들고 있다SaaS 기업들은 현재의 서비스보다 한 걸음 더 앞선 서비스 제공을 통해 이용률을 끌어올릴 수 있다. 그들은 지금 하는 것 이외에 이용자들이 무엇을 더 원하고 더 신경 쓸까를 생각해 볼 필요가 있다.그 예로 드롭박스의 드롭박스 페이퍼를 들 수 있다. 드롭박스는 원래 파일 공유 서비스였다. 하지만 오늘날, 드롭박스는 파일을 공유하는데 있어 다양한 방법을 제공해준다. 만약 드롭박스가 처음 서비스 이외에 유저들이 뭘 더 원할 것인 지를 생각해보지 않았다면 결국 이용률을 올릴 방법이 바닥나서 망하게 됐을 것이다.즉 드롭박스는 단순한 파일 공유 서비스에서 사람들이 함께 일하는 걸 더 쉽게 만들어 주는 일종의 팀 협업 툴로 자신들의 브랜드를 쇄신한 것이다. 이러한 재브랜딩 과정과 함께, 드롭박스는 2015년에 “창조적인 업무를 위한 새로운 형태의 파일 편집 툴” 이라는 신규 서비스인 드롭박스 페이퍼를 런칭했다.드롭박스 페이퍼는 단순히 문서와 파일을 저장하는 데 드롭박스를 쓰는 것이 아니라, 이제 문서와 파일을 만드는 데에도 드롭박스를 쓸 수 있게 만들어 주었다. 드롭박스 페이퍼는 사람들이 더 많이 서비스를 이용하게 만들었는데, 이는 파일 공유를 넘어 사람들간의 협업을 더 쉽게 해준다는 추가적인 옵션을 제공해줬기 때문이다.드롭박스가 이렇게 새로운 서비스를 만들려는 이유는 생존하기 위해서이다. 이 산업에 있어 망하는 일은 너무나 쉽게 일어나기 때문이다. Intercom의 Des Traynor는 다음과 같이 이를 설명한다.“원래 이쪽 산업이란 게 이런 겁니다, 기술이란 것의 특성 자체가 이런 것이죠. 모든 서비스가 결국 다 죽어 없어지게 되어있습니다. 만약 내 말이 사실이 아니라고 생각한다면 저에게 그렇지 않은 경우를 알려주세요. 한때는 SaaS 비즈니스가 절대 안 망할 것 같은 시절도 있었습니다. 하지만 더 이상은 아니에요.”만약 당신이 유저들이 당장 원하는 것에 대해서만 생각하고 있다면, 이미 망하고 있는 것이다. 성공적인 SaaS 기업들은 항상 유저들이 미래에 뭘 원하게 될 지에 대해서 생각한다. 아래에 SaaS 기업들이 어떻게 소비자들의 미래 욕구와 새로운 서비스에 대해 예측하려 하는 지 정리해보았다.당신의 경쟁자들, 그리고 왜 유저들이 그들의 서비스를 이용하는지 이해하라. 온라인 포럼 등을 보고 사람들이 경쟁사의 서비스를 어떻게 평가하는지를 알아내라. 이를 통해 당신은 사람들이 무엇을 원하는지, 그 방향이 어디로 향하게 되는지에 대한 통찰력을 얻게 된다. 이런 과정은 서비스의 확장과 새로운 서비스를 실험해 볼 수 있는 기회도 제공해준다.당신의 서비스를 사용했을 때 유저들이 무엇을 할 수 있을지를 생각해 봐야 한다. 유저들이 당장 요구하는 것만 만드는 것이 아닌 그들이 앞으로 원할 것이 무엇인지를 한 발 앞서 생각해 보는 것이다. 예를 들어, 아마존이 최근 개시한 새로운 서비스인 “Your idea” 리스트를 보자. 이 서비스는 유저들이 쇼핑을 하면서 비록 구입 하진 않더라도 커뮤니티에 자신이 생각한 리스트를 보여주고 싶은 욕구를 미리 연구해서 나온 결과물이다.가장 효과적이면서도 남들이 쉽게 예상하기 힘든 기능들을 우선순위로 짜는 것이 좋다. Gusto의 Tomer London은 서비스를 만들고 그것을 개선시킬 때, 가장 좋은 기능은 타인이 예측하기 어려움에도 불구하고 사용자 경험을 개선시키는데 가장 효과적인 것들이라고 한다. 사람들이 서비스를 통해 무엇을 가장 하고 싶어하는 지를 이해하고 그들을 도와줄 더 쉽고 나은 방법들을 생각해본다면 가장 효과적인 기능에 대한 단서를 잡을 수 있다. 남들이 예측하기 어려운 방법들은 당신이 처한 경쟁 지형에 대해 이해함으로써 알아갈 수 있다. 서비스 이용률을 늘리기 위해 다른 서비스와 통합한다우물 안의 개구리처럼 서비스를 홀로 제공하려 한다면 최대한의 이용률을 얻기란 요원하다. 당신은 새로운 서비스를 내놓음으로써 이용률을 늘릴 수 있지만, 그것으론 충분하지 않다. 유저들은 항상 다른 서비스 역시도 사용하고 있다. 당신이 이길 수 있는 방법은 당신의 서비스를 다른 서비스에 포함시킴으로써 사람들이 그 서비스를 쓸 때, 당신의 서비스도 쓰게 만드는 것이다.당신이 페이스북 웹사이트나 앱을 통해 페이스북을 쓰고 있지 않더라도, 당신은 페이스북을 사용하고 있는 것이나 마찬가지이다.페이스북을 이용해서 다른 서비스에 로그인 할 수 있다당신은 다른 웹사이트의 컨텐츠를 페이스북에 공유할 수 있다당신이 작업하는데 쓰는 서비스를 페이스북에 연결시킬 수 있다.티켓마스터를 통해 공연 티켓을 구매하는 것 역시도 페이스북으로 할 수 있다.페이스북은 다른 서비스들과도 완전히 통합이 되었기 때문에 사람들은 페이스북 인터페이스를 다른 서비스에서 보더라도 전혀 이상하게 생각하지 않는다. 심지어 어떤 경우에는, 페이스북 계정이 없다면 다른 사이트에 가입하기 어려울 때도 있다.페이스북이 다른 서비스와 더 통합이 될수록 당신은 더 페이스북을 쓰게 되고 그것을 필요로 하게 된다. Social Capital LP의 공동 경영자인 Arjun Sethi는 이점에 대해 다음과 같이 말한다.“페이스북이 권장하는 행동들이 일종의 문화가 되고 있어요. 페이스북은 그냥 가만히 앉아서 다른 서비스가 자신의 특징들을 베끼는 걸 보고만 있지 않았습니다. 자신들의 서비스를 다른 곳에 아주 쉽게 통합될 수 있게 만들었고 그 과정에서 핵심적인 이득은 다 챙겨갔습니다.”이것은 페이스북의 신중한 성장 전략의 일환이다. 다른 서비스의 개발자들이 페이스북을 쉽게 그들의 서비스에 통합할 수 있게 만듦으로써, 그냥 자신들의 서비스 내에만 머물러 있는 것에 비해 훨씬 더 많이 사람들이 페이스북을 사용하게끔 만들었다.Slack 역시도 다른 툴과 쉽게 통합이 가능하다페이스북이 다른 소셜, 라이프스타일 서비스들과 통합해서 유저들을 끌어모은 것처럼, Slack 역시도 자신들의 서비스를 다른 관련된 툴들과 통합할 수 있게 만들었다.Front와 같은 이메일 클라이언트와의 통합은 사람들로 하여금 Slack에서 바로 이메일을 관리할 수 있게 하였다.Slack은 또 Stripe와 통합을 하였는데, 이로 인해 사람들은 Slack 내에서 고객 결제 데이터를 보고 관리할 수 있게 되었다.Google Docs와의 통합으로 Slack 앱을 나가지 않고도 구글 문서 활동들을 볼 수 있게 되었다.Slack은 서드 파티의 통합을 장려하기 위해 거대한 앱 생태계를 구축하고 있다. 2015년에, 그들은 앱과 관련해서만 8천만 달러의 벤처 펀드를 만들었다. 2016년에, Slack은 자신의 플랫폼 내에 600개 이상의 앱을 보유하게 되었다. 그래서 이메일을 관리하거나, 고객과 커뮤니케이션을 하거나, 제품 분석 결과를 보는 것 등을 하러 다른 곳으로 일일이 가는 대신에 Slack 유저들은 기존 자신들의 서비스를 통해서 그 모든 것들을 할 수 있게 되었다.페이스북과 Slack은 그들 서비스의 유저들이 사용할 만한 다른 서비스들과 통합을 통해 이용률을 올렸다. 당신 서비스의 이용자들도 알고 있는 이런 기술의 생태계 속에 당신의 서비스를 끼워 넣는 방법에 대해 아래에 정리해 보았다.당신의 서비스를 사용하는 유저들의 워크플로우 대해 생각해보고 그것을 개선시킬 수 있는 점들에 대해서 추측해보라. 예를 들어, HubSpot을 이용하는 기업들의 궁극적인 목적은 사람들을 광고로 유인해서 실제 고객으로 만드는 데 있다. 그래서 HubSpot은 그 목적을 더 잘 수행하기 위해 자신들의 CRM 툴을 페이스북의 광고 관리 프로그램인 Adespresso와 통합할 수 있 게 만들었다. 즉, 사람들이 페이스북 광고를 클릭하게 되면 그 유저의 정보는 자동으로 그들의 CRM에 업로드가 된다.다른 유명 서비스들과의 통합을 통해 그들의 규모가 가진 이점을 가져오는 것이 좋다. 눈에 잘 띄는 서비스와의 통합은 당신의 서비스 역시도 눈에 잘 띄게 만들어준다. 잠재적 유저들에게 당신의 서비스를 소개할 수 있는 기회를 더 얻을 수 있을 뿐만 아니라, 다른 유명 서비스가 가진 브랜드 신뢰성 역시도 가져올 수 있다. 만약 당신의 회사가 아직 작다면, 유명하고 접근하기도 쉬운 Slack이나 페이스북과 같은 서비스와 함께 시작하라.Zapier를 활용해서 다른 서비스들과의 통합을 도모해라. Zapier에 호환이 되도록 앱을 만든다면, 유저들로 하여금 당신이 아직 직접적으로 통합을 제안하기 어려운 다른 앱들과 통합할 수 있는 옵션을 제공해 주는 것과 다름이 없다. 이 방법은 당신의 서비스가 아무리 독특하다 할지라도 그것을 유저들의 워크플로우에 집어넣는 데 도움이 된다.서비스를 개선시키는 데 있어 한 가지 방법만 써서는 이용률을 끌어올리는 데 한계가 있다. SaaS 기업들이 정말로 유저들로 하여금 그들의 서비스를 계속 좋아하고 이용하게끔 만들려면, 할 수 있는 모든 방면에서 이용률 최적화를 해야 한다. 기존의 서비스 내에서 할 뿐만 아니라, 새로운 서비스, 다른 유저들에게 이미 필요한 다른 서비스와의 통합을 해서라도 말이다.차세대 SaaS를 만드는 것에 대해SaaS 서비스들은 점점 더 무용지물이 되어 가는 경우가 많고 사라지는 서비스들도 많다. 만약 SaaS 기업들이 왜 사람들이 그들의 서비스를 쓰는 지 이해하지 못한다면, 그들은 계속 성장할 수 없을 것이고 유저들도 이탈할 것이다.지금까지의 내용을 정리하자면 페이스북은 이용률과 성장을 도모할 수 있는 매우 포괄적이면서도 단순한 방법 3가지를 생각해냈다. 사람들이 현재의 서비스를 더 많이 사용하게 만드는 것, 새로운 서비스를 통해 더 많이 사용하게 만드는 것, 그리고 다른 서비스와의 통합을 통해 자신의 서비스를 더 이용하게 만드는 것. 이 3가지이다. 그리고 이렇게 이용률을 올린다는 것은 성공을 의미한다.미래에 가장 성공적인 SaaS 기업 역시 이용률에 중점을 두게 될 것이다. 지금까지 페이스북을 모델로 삼아 설명한 것처럼, 이것들이 SaaS 기업이 앞으로 더 나은 서비스를 만드는 방법이 될 것이다.원문 : 프로덕트해빗#더팀스 #THETEAMS #SaaS #인사이트 #페이스북
조회수 1071

[인터뷰] Clara의 인턴 직무 인터뷰 제3화 _iOS developer 민트를 만나다

안녕하세요:)인턴들의 하루하루를 전해드리는 클라라입니다오늘은 저번 시간에 말씀드렸던 Tech unit의  미녀 인턴과의 인터뷰를 진행했습니다!그녀의 이름은 상쾌한 Mint!본명에 '박하'가 들어가서 민트라는 이름을 지었다고 하네요~센스 만점이죠?이름처럼 상큼한 민트와의 인터뷰바로 만나보시죠!고고고☞Q. 안녕하세요 민트, 간단한 자기소개와 요즘 어떤 일을 하시는지 소개해주세요~M.네! 안녕하세요~ 저는 iOS 개발을 하고 있는 개발자입니다. 많은 분이 개발자가 코딩을 하고 이런 것들은 어렴풋이 알고 계실 텐데, 지금 저는 iOS 앱에서 개선할 부분을 조사하고 더 잘 구현하고자 열심히 개발하고 있습니다. 아직은 주로 UX/UI 의 개선에 집중하고 있고, 하는 일보다 배우는 일이 더 많은 것 같네요!M.네! 안녕하세요~ 저는 iOS 개발을 하고 있는 개발자입니다. 많은 분이 개발자가 코딩을 하고 이런 것들은 어렴풋이 알고 계실 텐데, 지금 저는 iOS 앱에서 개선할 부분을 조사하고 더 잘 구현하고자 열심히 개발하고 있습니다. 아직은 주로 UX/UI 의 개선에 집중하고 있고, 하는 일보다 배우는 일이 더 많은 것 같네요!Q. 개발자는 그 안에서도 하는 일이 다양하다고 들었어요. 요즘 민트의 주 업무에 대해 더 자세하게 설명해주실 수 있을까요?M.그럼요~지금 저는 아이폰의 OS인 iOS에 특화된 방식으로 개발하는 네이티브 방식을 활용하고 있어요. 네이티브 방식이란 안드로이드나 iOS와 같은 특정 OS에 최적화된 방식으로 앱을 개발하고 있다는 뜻입니다. 그렇지 않은 개발 방식도 있거든요! 모바일 웹페이지를 앱처럼 꾸며서 보여주는 등 여러 방식이 있습니다.M.그럼요~지금 저는 아이폰의 OS인 iOS에 특화된 방식으로 개발하는 네이티브 방식을 활용하고 있어요. 네이티브 방식이란 안드로이드나 iOS와 같은 특정 OS에 최적화된 방식으로 앱을 개발하고 있다는 뜻입니다. 그렇지 않은 개발 방식도 있거든요! 모바일 웹페이지를 앱처럼 꾸며서 보여주는 등 여러 방식이 있습니다.iOS개발은 안드로이드 앱 개발과 비교했을 때 제약 조건도 많고, 생소한 스타일의 개발 언어를 써야 하는 게 어려워요. 하지만 동시에 iOS 특유의 사용감과 안정성이 매력이에요. 그리고 아까 UX/UI라는 용어를 사용했는데 이는 User Experience와 User interface의 약자, 즉 사용자 경험을 의미합니다. 저희는 사용자 경험을 더욱 편리하게 하는 쪽으로 앱을 유지 보수하는 일을 하고 있는 거예요. 미미박스는 고객을 소중히 여기기 때문에 이런 UX/UI에 있어서도 많은 신경 쓰고 있습니다.Q. 그럼 개발자로서 미미박스는 어떤 장점을 가지고 있나요? 저희 회사 자랑 좀 해주세요!!!M. Q. 그럼 개발자로서 미미박스는 어떤 장점을 가지고 있나요? 저희 회사 자랑 좀 해주세요!!!M. 음, 저는 미미박스가 개발자의 의견을 듣고 반영하고자 하는 회사임을 가장 말씀드리고 싶어요! 미미박스 개발팀에서는 디자인팀+앱 개발팀+PM 팀, 세 팀이 모여서 정기적으로 회의를 하고 있습니다. 이 회의를 스크럼이라고 하는데, 프로젝트와 관련된 모든 사람들이 모여서 계획하고 피드백하는 것이죠.이걸 하면 좋은 이유는 개발을 담당하는 사람이 직접 기획에도 참여할 수 있다는 거예요. 보통 한국에서 개발 직무는 보통 상명하달식으로 이루어진다고 해요. 위에서 개발이라는 직무를 이해하지 않고 일방적으로 일정을 정해서 던져주는 거죠. 그런데 미미박스는 그렇지 않고 자신의 생각을 내고 반영할 수 있어서 좋아요.   Q. 오오오~ 그렇군요! 민트와 저는 자리가 멀잖아요. 업무적인 것과 별개로, Tech 유닛의 분위기는 어떤가요??? M.저희 유닛 분위기 완전 좋아요! 그리고 저는 사수 분들이 똑똑하셔서 배울 점이 많다는 생각으로 회사를 다니고 있어요. 서로 돕고 정보를 공유하는 분위기여서 무려 시니어 분들이 제게 본인의 코드를 다 오픈해주세요. 근데 그 코드가 다 샘플 코드의 수준이고요!(샘플 코드란 일종의 '교과서'같은 존재로, 코딩의 수준이 아주 높다는 뜻입니다.)iOS 직무는 신입의 진입장벽이 높거든요. 사전 지식 없이는 독학으로 따라잡을 수 없는 부분이 많기 때문에 코드와 그에 대한 설명을 들을 수 있다는 건 엄청난 거죠. 마치 최고의 영업사원이 자신의 영업 비밀을 공개해주는 그런 경우라고 할까요? 애플 워치의 코드까지 알려주는 회사, 흔치 않습니다! (엄지 척)  민트에게 몰려든 고양이들~Q. 와우! 애플 워치도 코딩을 하는 거군요. 제겐 너무나 신세계인데요...!  이제 마지막 질문입니다. 여성 개발자로서 강점은 무엇일까요?M.저는 사실 특정 산업 군이나 성별에 구애받지 않는 작업을 한다고 생각해요. 그럼에도 화장품을 온라인으로 사 본 개발자과 그렇지 않은 개발자는 차이가 있다고 생각해요. 여성이 주 고객층인 뷰티 쇼핑몰에 대한 경험이 쌓이면 새롭고 좋은 UX에 대한 아이디어도 더 잘 나오지 않을까 싶네요.  민트와의 인터뷰 어떠셨나요?저 클라라처럼 컴알못이거나개발자의 하루가 궁금하셨던 분들은 이번 인터뷰가 큰 도움이 되셨으면 좋겠습니다.민트를 마지막으로 인턴의 생활을 엿볼 수 있는 클라라의 인터뷰가 마무리 되는데요 :)미미박서의 일과 삶에 대해서 조금이나마 더 알아가셨다면,그래서 '미미박스에서 일해보고 싶다'는 마음이 스멀스멀 생기셨다면!클라라는 그것만으로도 보람찰 것 같습니다.그럼 또 미미박스의 소식으로 찾아올게요~
조회수 1408

Code without Limits

WWDC18 Review (1): Bring the Func! 보기 Introduction지난 글 Bring the Func! 에서 WWDC를 소개했습니다. Keynote와 Platforms State of the Union에서 인상 깊었던 경험도 소개했고요. WWDC 첫째 날은 애플에서 큰 이벤트를 진행했고, 둘째 날부터 마지막날까지는 세션과 랩스, 스페셜 이벤트를 진행했습니다. 이번엔 지난 글에서 미처 쓰지 못했던 것을 소개하겠습니다.SessionWWDC 하면 가장 먼저 떠오르는 건 대개 Keynote입니다. 하지만 다른 세션이나 랩스부터 생각나는 애플 개발자도 있을 겁니다. 저도 처음엔 Keynote만 기대했지만, 행사에 참여하면서 세션과 랩스의 매력(?)에 빠졌습니다.Apple Developer 웹사이트에서 수많은 기술 관련 영상을 볼 수 있다.애플 관련 애플리케이션 개발자는 문제에 부딪히면 Apple Developer 웹사이트에서 도움을 얻는데요. 특히 Development Videos 사이트에 들어가면 그해 발표한 WWDC 세션부터 시작해서 그 동안의 세션들을 모두 볼 수 있습니다. Topics에서는 주제별로 카테고리를 만들어, 해당 주제에 관한 동영상들을 모아서 볼 수 있고, Library에서는 찾고자 하는 내용에 대한 키워드를 검색해서 찾을 수 있습니다.Development Videos - Apple Developer 첫 화면Topics 에서는 주제별 동영상들을 볼 수 있다.Library 에서는 검색하는 키워드에 해당하는 동영상들을 볼 수 있다.WWDC 행사장은 Hall 1 ~ Hall 3, 그리고 Executive Ballroom까지 4개의 방으로 구성되어 있었습니다. 이곳에서 각각의 세션을 들을 수 있었는데요. 시간대별로 3~4개의 세션을 동시에 진행합니다. 듣고 싶은 세션은 해당하는 방에 들어가서 들으면 됩니다. 만약 같은 시간에 듣고 싶은 세션이 두 개 이상이라면 하나만 현장에서 듣고, 다른 세션은 developer 웹사이트 또는 WWDC 앱에서 업로드되길 기다려야겠죠. 물론 24시간이 지나면 세션 영상이 WWDC앱에 업로드됩니다. WWDC 앱에서 제공하는 행사장 지도세션이 진행되는 곳의 내부수많은 개발자의 똑똑한 머리와 지미집세션이 시작되자 개발자들은 무릎 위에 올려 놓은 맥북을 열심히 쳤습니다. 하나라도 놓치기 싫어서 열심히 타자를 치는 개발자들의 모습이 멋있었습니다. 마치 대학 영어 강의를 듣는 기분이었죠.아쉬운 점이 있다면, 에어컨을 너무 강하게 틀어 세션 행사장이 매우 추웠다는 겁니다. 며칠을 견디다 마지막 날엔 결국 행사장 밖에서 라이브로 시청했습니다. 그리고 세션을 진행하는 동안 빠르게 코딩을 하다 보니, 소스 코드를 다 작성하기도 전에 다음 장면으로 넘어가는 부분이 많았습니다. 실시간으로 같이 작업할 예제 소스 코드를 제공하거나 조금 더 효율적으로 세션을 들을 수 있게 해줬으면 좋겠다는 생각이 들었습니다.행사장에서 제공하는 아침 식사와 함께 맥북 프로에서 라이브로 세션 시청What’s new in ARTKit 2지금부터는 인상 깊었던 세션 세 가지를 소개하겠습니다. 첫 번째는 What’s new in ARTKit 2였습니다. 이 세션이 가장 인상 깊었던 이유는 애플이 AR에 중점을 두고 있다는 생각이 들었기 때문입니다. 실제로 Keynote 발표 중에 장난감용 블럭을 만드는 회사 관계자 두명이 AR을 활용한 앱을 실행해 노는 모습을 보여주기도 했습니다.Keynote 발표 중 한 장면. 크레이그 페더리기가 AR 파트에서 Shared experiences에 대해 발표하고 있다.가장 재미있었던 건 현실 공간을 저장해 다른 유저들과 공유할 수 있는 기능이었습니다. ARWorldMap Object를 이용해 사용자가 기기를 움직이면서 현실 공간의 모습을 저장합니다. 나중에 앱을 다시 실행하면 저장했던 현실 공간 맵이 그대로 유지되고, 이전의 모습도 나타나죠. 예를 들어, 노란 테이블 위에 가상의 물건을 올려 놓았다면, 나중에 테이블을 향해 기기를 움직였을 때, 그 자리에 놓여있던 가상의 물건이 다시 나타납니다. 또한, 저장한 맵을 근처의 다른 유저의 기기로 전송할 수 있습니다. 이렇게 하면 서로 다른 기기에서 같은 맵을 보면서, 같은 경험을 할 수 있게 됩니다. 개념을 확장하면 하나의 AR앱으로 다중 유저들이 게임을 함께 즐기거나 멀리 떨어져 있어도 같은 교육을 받을 수 있죠.SwiftShot AR게임을 즐기려고 기다리는 개발자들WWDC18 Keynote에서 잠깐 소개되었던 SwiftShot AR 게임이 이런 특징을 잘 나타난 앱입니다. 실제로 행사장 1층 안쪽에 이 게임을 즐길 수 있는 공간이 따로 마련되어 있었습니다. 개발자들이 직접 게임을 즐길 수 있었고, 마지막 날엔 개인전과 팀전을 진행해 1등에게 선물(AR뱃지)을 주었습니다. 옆에서 구경했는데 재밌었습니다. 아이패드가 있다면 여기를 클릭해 샘플 코드를 다운 받을 수 있습니다. 빌드해서 재미있는 AR 게임을 친구들과 함께 즐겨보세요. A Tour of UICollectionView브랜디 앱은 90% 이상 UICollectionView를 이용해 앱 화면을 만들었습니다. 많은 UICollectionViewCell을 다시 사용할 수 있고, 커스텀 레이아웃도 만들 수 있기 때문입니다. 이전에 포스팅한 ‘테이블이냐, 컬렉션이냐, 그것이 문제로다!’에서 UICollectionView를 공부했지만 더 배우고 싶어서 A Tour of UICollectionView를 들었습니다.이 세션은 UICollectionView에 대해 좀 더 깊은 내용을 다뤘습니다. UICollectionView와 UITableView의 가장 큰 차이점인 레이아웃에 초점을 두었는데요. 단순히 UICollectionView에서 선형 레이아웃 말고 그리드 형식의 레이아웃을 만들 수 있다는 것, 커스텀 레이아웃을 만들 때 고려할 것, 구현에 대한 가이드라인까지 제시했습니다. 애플에서 제공하는 레이아웃 중 하나는 UICollectionViewFlowLayout입니다. UICollectionViewFlowLayout은 line-based 레이아웃 시스템입니다. 일직선 상에서 최대한 많은 아이템들을 채운 후, 다음 행 또는 열로 넘어가 아이템을 채우는 형식으로 컨텐츠들을 배치합니다. 가장 흔한 레이아웃 모습이 바로 그리드 레이아웃입니다.그리드 레이아웃, 또는 UICollectionViewFlowLayout으로 구현할 수 있는 레이아웃Line-based 레이아웃이 아닌 다른 모습의 레이아웃이라면 어떤게 있을까요? 세션에서 예를 든 레이아웃이 바로 모자이크 레이아웃이였습니다. 브랜디 앱, 또는 다른 앱에서 볼 수 있는 모자이크 레이아웃은 일직선상에서 일렬로 정렬하지 않고, 그리드 레이아웃과 조금 다른 모습입니다. 아래의 스크린샷을 보면 어떤 레이아웃인지 감이 잡힐 겁니다.브랜디 앱, 인스타그램 앱, 세션 예제 앱의 모자이크 레이아웃모자이크 레이아웃은 line-based 레이아웃이 아니기 때문에 일반적인 UICollectionViewFlowLayout을 사용하지 않고, UICollectionViewLayout을 상속하여 커스텀합니다. 총 4개의 기본 메소드와 추가적으로 고려해야하는 메소드 하나를 이용하여 커스텀 UICollectionViewLayout을 만들 수 있습니다. 모든 컨텐츠를 담는 뷰의 크기, 레이아웃의 속성 2개, 그리고 레이아웃을 준비하는 기본 메소드들을 구현하고, 레이아웃이 변경해야하는 상황(기기를 가로로 눕히거나 레이아웃의 위치가 변경될 때 등)을 고려하여 메소드를 구현하면 됩니다.open var collectionViewContentSize: CGSize { get } func layoutAttributesForElements(in rect: CGRect) → [UICollectionViewLayoutAttributes]? func layoutAttributesForItem(at indexPath: IndexPath) → UICollectionViewLayoutAttributes? func prepare() func shouldInvalidateLayout(forBoundsChange newBounds: CGRect) → Bool 세션 강연자가 직접 소스를 작성하면서 메소드 구현과 퍼포먼스를 위한 팁을 설명했습니다. 이 세션을 통해서 UICollectionView의 핵심인 레이아웃에 대해 더 깊이 배울 수 있었죠. 레이아웃 말고도 멋진 애니메이션 효과 구현 방법을 설명해주었는데요, 여기를 클릭해 직접 동영상을 보는 걸 추천합니다! 영상을 보고 나면 분명 멋진 UICollectionView를 구현할 수 있을 겁니다.Build Faster in XcodeBuild Faster in Xcode 는 가장 인기 있었던 세션 중 하나였습니다. 한국 개발자들 사이에서도 추천할 세션 중 하나로 꼽혔죠. 물론 혁신적으로 빌드 타임을 줄일 수는 없지만, Xcode의 기능과 빌드 타임이 어떻게 연결되는지 알 수 있었습니다. 프로젝트 세팅과 가독성 있는 코드 작성, 이 두 가지가 빌드 타임과 관련되어 있었습니다. Xcode는 프로젝트를 구성(configure)할 때, 빌드할 targets(iOS App, Framework, Unit Tests 등)와 targets 사이의 종속 관계(dependency)를 따릅니다. Dependency에 따라서 target을 빌드하는 순서도 정해지는데, 순서대로 빌드하지 않고 최소한의 연결을 유지하면서 병렬적으로 빌드하게 됩니다.빌드 시간을 아름답게 줄일 수 있다.이것은 Xcode 10에서 Scheme Editor에서 설정할 수 있습니다. 프로젝트의 Target → Edit Scheme → Build → Build Options에서 Parallelize Build를 체크하면 됩니다.Xcode 10의 Parallelize Build또한 Xcode 10에는 빌드 타임을 계산하는 기능도 있습니다. 빌드할 때 어떤 부분에서 얼마나 걸렸는지 요약해서 보여주는 기능도 있습니다. Product → Perform Action → Build With Timing Summary를 선택하면 빌드 후 요약해서 Xcode에 나타납니다.Build With Timing Summary를 선택하여 빌드하면위 스크린샷처럼 요약해서 보여준다.Xcode 프로그램을 이용해서 빌드 타임을 관리하는 방법도 있고, Swift으로 작성한 소스 코드를 가독성 높은 코드로 바꾸는 방법도 알려줍니다. 또한 Bridging Header로 Objective-C와 Swift를 동시에 개발할 때 도움이 되는 방법도 설명해줍니다. 빌드 타임에 대해 관심을 가질 수 있는 계기가 될 겁니다. 한 번씩 영상을 보길 추천합니다!Labs세션을 듣고 궁금한 점이 생겼다면 Labs(랩스)에서 질문할 수 있습니다. 각 세부 분야별 애플 기술자들이 시간대별로 모여서 개발자의 질문을 받거나 문제점을 해결할 수 있도록 도움을 줍니다.Technology Labstechnology Labs 간판Labs 입구에 있는 부스별 주제짙은 남색 Engineer 티셔츠를 입은 애플 기술자들이 질문을 받고 있다.가장 인기가 많았던 랩스는 Auto Layout and Interface Builder, UIKit and Collection View, Building Your App with Xcode 10 등등이었습니다. 사람이 많아서 줄 서서 기다릴 정도였습니다. 내년에는 랩스 시간이 조금 더 길게 진행됐으면 좋겠다는 생각이 들었습니다.WWDC 기간 중에 랩스에서 시간 보낸 적이 있었습니다. iOS 프로그래밍을 시작한 지 1년도 되지 않아 궁금했던 것들과 새로운 Xcode 10에 대해서 질문했습니다. 아래는 질문했던 내용을 문답형식으로 작성했습니다.애플 기술자와의 문답문: iOS 프로그래밍을 개발한지 얼마 안 된 신입 개발자입니다. 어떻게 하면 프로그래밍 실력을 높일 수 있나요? 답: 앱 하나를 처음부터 끝까지 개발해보면 실력을 늘릴 수 있다. 또한, 애플에서 만든 스위프트 책 보는 걸 추천한다.문: WWDC 기간 동안에 테스팅(testing)에 관심을 가지게 되었습니다. 앞으로 상용하는 앱을 테스트하면서 개발하고 싶은데, 테스트는 어떻게 시작하면 좋을까요?답: 이것에 대한 세션 동영상 을 보는 걸 추천한다. 테스트는 중요한 것이기 때문에 이 동영상을 보면서 테스트에 대해 배우고 난 뒤, 직접 앱을 테스트해보길 권장한다.문: 새로운 Xcode 10에서 앱을 빌드해봤는데 에러가 났습니다. 이런 에러가 나타난 이유는 무엇인가요?답: Xcode 10에 있는 컴파일러 문제다. 소스를 수정하면 앱이 빌드될 것이다. 컴파일러에 대해서 Xcode 팀에게 전달하겠다. (Range 관련된 컴파일러 문제였습니다.)문: 빌드 시간을 줄일 수 있는 방법은 무엇인가요?답: 컴파일하는 소스 코드를 줄이거나 프레임워크를 만들어서 빌드할 때 마다 계속 빌드하지 않도록 하면 시간을 줄일 수 있다. 이와 관련된 세션을 들으면 조금 더 자세한 내용을 확인할 수 있다.Consultation Labs애플 기술자와 일대일 면담식으로 진행하는 랩스도 있었습니다. 예전에는 선착순으로 진행되었는데 올해는 신청을 받고 당첨된 개발자에게만 기회를 주었습니다. 당첨되면 30분 동안 신청한 분야(디자인, 앱 스토어, 마케팅 등)의 전문가와 질의응답을 할 수 있습니다. 가장 인기가 많았던 User Interface Design 랩스를 신청하고 당첨이 되었습니다. 디자인 전문가들과 시간을 보낼 수 있었는데요. 애플 디자이너들이 생각하는 최선의 디자인 가이드라인을 배울 수 있었고, 함께 앱을 관찰하면서 개선되었으면 하는 디자인 요소 등의 팁을 얻었습니다. 아쉽게도 촬영 및 녹음은 불가능했습니다. 시간도 짧게 느껴져서 아쉬웠습니다.Special EventsWWDC 기간 동안에는 세션과 랩스 위주로 진행되지만 중간에 가끔 스페셜 이벤트들도 진행합니다. 점심 시간에 유명 인사들을 초청해서 하는 짧은 강연, 아침 일찍부터 모여서 같이 달리면서 즐길 수 있는 이벤트(WWDC Run with Nike Run Club), 맥주와 함께 음악을 즐기는 이벤트 등 개발 외적인 이벤트들을 많이 진행했습니다. 저는 그 중에서 Bash 이벤트를 소개하고 싶군요.BashBash는 목요일에 진행한 뒤풀이 파티였습니다. WWDC 행사장 근처에 공원을 빌려서 맛있는 음식과 주류를 무료로 제공하고, 초청 가수의 공연도 볼 수 있었습니다. 초청 가수가 공연하기 전에 소개할 때 크레이그 페더리기가 무대에 나왔습니다. 개발로 지친 몸과 머리를 식히고 다른 개발자들과 어울려 놀 수 있는 공간이였습니다. 뒤풀이 파티가 끝나갈 때쯤 진짜로 WWDC가 끝나간다는 느낌이 들어서 괜히 아쉽기도 했었습니다.무대와, 맥주와, bash 입장권한국인 개발자들과 함께 즐긴 뒤풀이 파티초청 가수를 소개하러 무대에 올라온 크레이그 페더러기아름다운 노을!마치며이번 글에서는 WWDC의 세션, 랩스, 스페셜 이벤트를 설명했습니다. WWDC가 한 달 전에 끝났지만 지금 다시 생각하면 두근두근 설레고 또 가고 싶어집니다. 내년 WWDC에 또 갈 수 있을까요? 지금까지 애플 개발자들의 축제였던 WWDC의 Review를 마치겠습니다. 긴 글을 읽어주셔서 감사합니다!글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #이벤트참여 #이벤트후기 #미국
조회수 2279

리디북스 서버 스택 소개

2대의 서버로 시작한 리디북스는 각 기능의 요구사항에 최적인 솔루션들을 채용하고, 고가용성(High Availability)을 지향하면서 매우 복잡하고 다양한 구성으로 변모해왔습니다. 이 글에서는 리디북스가 어떤 스택에서 서비스를 제공하고 있는지 간략히 소개하려고 합니다. 각 스택의 선택 이유나 문제에 부딪히며 배운 노하우 등은 차차 포스팅하겠습니다.대략적인 구조리디북스 백엔드 구조도로드 밸런싱로드 밸런싱은 소프트웨어 로드 밸런서인 HAProxy를 이용하고 있습니다. HAProxy는 L4, L7 스위치의 기능 및 로드 밸런싱을 제공하고 구성 역시 매우 간편합니다. 리디북스는 고가용성을 위해 Active - StandBy 서버 한 쌍이 가상 IP를 공유하고, keepalived를 통해 서로의 상태를 확인하며 자동 failover 됩니다. 각 서버군이 사용하는 네트워크 트래픽에 따라 스위치와 연결되어 있는 네트워크의 속도가 다른데, 이를 효율적으로 사용하기 위해 HAProxy 서버 쌍을 2개 구성하여 DNS를 통해 HAProxy로 들어오는 트래픽도 분산하는 방식으로 네트워크 효율화를 이루었습니다.웹 서버Ubuntu 14.04 LTS 기반에 웹서버로는 Apache, Nginx를 사용하고 있습니다. 서점 용 웹 서버, 정적 파일 서버(CSS, JS 등), 통계용 서버, 책 파일에 DRM을 씌워 전송하는 다운로드 서버 등 여러 개의 웹 서버 그룹을 나누어 관리하는데, 각 서버가 하는 역할이나 테스트를 통해 확인한 병목 지점을 고려해 웹서버를 채택합니다.API 서버리디북스는 서점이나 앱에서 이용하는 수많은 API가 존재하는데 종류에 따라서는 초당 수만 개의 호출이 발생하는 경우도 있습니다. 이러한 트래픽을 감당하기 위해 비동기 처리가 필요한 경우 Node.js를 주로 이용하여 구현하고 있습니다. Node.js 프로세스는 PM2를 통해 클러스터 모드로 실행되어 요청을 처리합니다. 클러스터 모드는 프로세스에 대한 로드 밸런싱을 지원하며 프로세스를 순차적으로 재시작할 수 있어 무정지로 서비스를 재시작할 수 있습니다데이터베이스서비스 초기에 MySQL을 사용했고 현재는 MariaDB로 변경한 상태입니다. 한때 DB가 SPOF(Single Point Of Failure)였던 시기를 겪으면서 read/write의 분산을 위해 많은 노력을 들였습니다. 리디북스에서 실행하는 대부분의 데이터 연산은 읽기 동작이므로 애플리케이션 레벨에서 읽기/쓰기 접근을 구분하여 1차적으로 부하를 분산하고, HAProxy를 통해 여러 대의 slave로 분배해 2차적으로 부하를 분산합니다. 쓰기 동작이 빈번하거나 데이터 성격상 NoSQL이 필요한 경우 Couchbase와 Redis를 적극적으로 사용하고 있으며, MariaDB 상에서도 쓰기 동작의 분산 필요성이 대두됨에 따라 상반기에 샤딩을 준비하고 있습니다. 사용자 행동, 트랜잭션 로그 등 하루에도 방대한 양이 쏟아지는 데이터의 경우 Azure 내에 구성한 Hadoop 클러스터에 보관하며, Hive 저장소를 BI(Business Intelligence) 시스템 기반으로 활용하고 있습니다.파일 시스템리디북스에서 다루는 책 파일은 매우 방대하고 중요한 데이터입니다. 어떠한 일이 있어도 데이터 유실이 발생해서는 안되며, 일부 하드웨어 혹은 노드에 장애가 발생하더라도 서비스 장애 없이 파일을 서빙할 수 있어야 합니다. 저희는 GlusterFS로 6대의 노드를 클러스터를 구성하고 이를 파일 접근이 필요한 서버에서 NFS-like 형태로 마운트하여 사용하고 있습니다. 동일 데이터는 여러 노드(3 replica)에 분산 저장되며, 각 노드에도 RAID 구성을 하여 빠른 장애 대응 및 데이터 유실 방지에 노력하고 있습니다.검색리디북스의 책/저자 검색 등은 ElasticSearch를 통해 이루어집니다. 형태소 분석기는 오픈소스인 은전한닢에 따로 정의한 dictionary를 조합해 사용하고 있고, 2대의 노드로 클러스터가 구성되어 있습니다. 추가/변경되는 도서 정보는 증분 색인을 통해 실시간으로 검색 서버에 반영됩니다.작업큐이메일 발송, PUSH 발송 등의 작업들은 웹 애플리케이션이 직접 실행할 경우 페이지 응답속도를 떨어뜨리고, 진행상황 파악이나 실패 시 재시도하는 등의 실행 관리가 어렵습니다. 이런 문제를 해결하기 위해 Beanstalk라는 Work Queue에 작업을 일단 쌓아두고, 여러 대의 서버에서 실행되고 있는 컨슈머들이 작업을 가져와 순차적으로 진행하는 형태로 구성되어 있습니다.모니터링장애 발생 포인트와 시점을 예측할 수 없는 만큼 장애 발생의 빠른 인지를 위해 모니터링은 매우 중요합니다. 리디북스는 99.999%의 고가용성(High Availability)을 목표로, 버그와 장애 없는 안전한 운영을 위해 아래와 같이 다양한 오픈소스 및 유료 솔루션을 도입하여 활용하고 있습니다.30+ 이상의 서버 리소스를 모니터링하기 위한 Munin(On-Premise) 및 NewRelic(SaaS)서버에서 발생하는 각종 오류와 예외를 모니터링하기 위한 Sentry로그인, 결제 등 서점의 핵심적인 기능의 정상 여부를 모니터링하는 Pingdom각종 배치작업과 주기적으로 실행되는 스크립트를 모니터링하기 위한 PushMonNode.js 프로세스나 Redis 상태 모니터링을 위한 Keymetrics(SaaS)데이터의 무결성을 주기적으로 감지하는 각종 In-house 스크립트#리디북스 #서버 #서버개발 #스택 #백엔드 #node.js #개발자 #개발언어 #스킬스택 #소개
조회수 911

조건문을 긍정적으로!

Overview“나 혼자 프로젝트를 하니 주석은 안 달아도 무방해요” 이렇게 말하는 개발자는 그 코드를 가장 많이 보는 것도 자신이라는 사실을 잊고 있을지도 모릅니다. 구린 코드를 보고 욕했는데 3개월 전 자신이 작성한 코드란 걸 알면 그제서야 얼굴이 붉어지기 일쑤죠. 작은 습관이지만 약간의 변화만 준다면 분명 즐겁고 생산적인 개발을 할 수 있을 겁니다. 얼굴 붉어질 일도 없고요. 오늘은 그 노하우를 전해드립니다. 혼돈을 피하는 여섯 가지 코드 작성법조건문은 긍정적으로 쓰자조건문의 성능은 생각하지 말자조건 검증을 깔끔하게 하자주석은 적절하게, 적당하게 하자상수를 활용하자복잡한 코드는 풀어서 쓰자과거의 나 자신아, 넌 나에게 똥을 줬어1.조건문은 긍정적으로 쓰자”쟤가 그 아이가 아니지 않지 않나?!” 프로그램 코드를 마지막으로 실행하는 건 컴퓨터지만 코드를 작성하고 관리하는 건 결국 사람입니다. 수많은 조건문이 존재하는 프로그램에서 조건이 부정적이라면 한 번 더 생각해야 합니다. 반대로 조건문을 긍정적으로 작성하면 보다 편리하게 개발을 진행할 수 있습니다. 가능하다면 긍정적인 마인드로 조건문을 적어봅시다.<?php // 예제는 PHP로 작성 되었습니다. $title = $_POST['title']; // 공지사항 제목 if (empty($title)) {     echo '제목을 입력해주세요';    return; } // 위의 경우보다 한번 더 생각해야한다. if (!isset($title)) {     echo '제목을 입력해주세요';    return; } cf)비슷한 사례 for 증감식을 i– 처럼 적는 경우 꼭 필요한 경우가 아니라면 삼가는 것이 좋다. for로 작성 가능한 반복을 while로 구현하는 경우 for는 끝이 명확하지만 while은 언제나 불안하다. 2.조건문의 성능을 생각하지 말자간혹 조건문에 성능을 고민해 줄여보려는 개발자가 있습니다. 10개의 and 조건을 2개로 줄인다면 얼마나 이득일까요? 하지만 이것은 티도 나지 않는 적은 양입니다.1) 조건문을 압축하지 마세요. 시간이 지나면 자신의 코드가 마치 보물지도처럼 보일 수도 있습니다. 조건문을 최적화하려고 하기보다는 보기 좋고 읽기 편하게 변경합시다. 3.조건 검증을 깔끔하게 하자만약 게시물에 글을 쓰는 프로그램을 제작한다면 요청된 값들이 정상인지 확인해야 합니다. ‘게시물 제목이 있고, 글 내용이 있고, 글 분류가 정상이고, 뭐뭐 하면 등록!’이라고 작성하면 논리적인 접근으로 보이지만 코드의 상태는 그렇지 않습니다.<?php $title = $_POST['title']; // 공지사항 제목 $content = $_POST['content']; // 공지사항 내용 $category = $_POST['category']; // 공지사항 분류 if (!empty($title)) {     if (!empty($content)) {         if (!empty($category)) {             // 게시글을 등록한다.!         } else {             echo '카테고리를 선택해주세요';         }     } else {         echo '내용을 입력해주세요';     } } else {     echo '제목을 입력해주세요'; } if문 블럭이 중첩되어 가로 스크롤 압박에 시달릴 것이기 때문입니다. 또한 나중에 수정하려면 많이 고생해야 합니다. 조건 검증을 하는 코드라면 아닌 경우를 체크하는 것이 더 좋습니다. 아래와 같은 형태로 작성하는 게 깔끔하고, 유지 보수에도 도움이 됩니다. 게시물 제목이 없으면 오류 출력글 내용이 없으면 오류 출력글 분류가 정상이 아니면 오류 출력그 외 등등…<?php // 예제는 PHP로 작성 되었습니다. $title = $_POST['title']; // 공지사항 제목 $content = $_POST['content']; // 공지사항 내용 $category = $_POST['category']; // 공지사항 분류 if (empty($title)) {     echo '제목을 입력해주세요';     return;  } if (empty($content)) {     echo '내용을 입력해주세요';     return;  } if (empty($category)) {     echo '카테고리를 입력해주세요';     return;  } // 게시글을 등록한다.! 4.주석은 적절하게, 적당하게 하자주석이 많아야 좋을까요, 아니면 적어야 좋을까요? 이 논제는 여전히 개발자 사이에서 뜨거운 감자입니다. 다양한 의견이 있지만 저는 ‘적당한게 좋다’고 생각합니다. 주석이 없어서 고생한 적도 있지만, 주석이 너무 많거나 쓸모없었던 적도 겪어봤기 때문입니다. 가끔 “코드 한 줄마다 주석을 달아”라는 미친 선임도 있었고 “주석이 필요 없게 깔끔하게 짜”라고 말하는 기괴한 선임도 있었습니다. 사고의 최종 결과물인 프로그램 코드가 아무런 설명 없이 다른 사람 혹은 미래의 자신을 이해시키는 건 불가능한 일이라고 생각합니다. 다양한 테크닉과 아름다운(?) 코딩으로 주석을 줄여나갈 수는 있겠지만 꼭 필요한 곳엔 적어야 한다고 생각합니다. 4-1) 주석이 꼭 필요하다고 생각할 때 깊은 사고의 결과를 코드로 작성하였고, 다음에 왜 그렇게 작성했는지 헷갈릴 것 같을 때함정 카드가 발동되어 헤맬 것 같은 코드일 때코드가 길어져 기능의 단위별로 나눠서 보는 게 좋을 때기술된 함수나 클래스가 이름과 다르게 동작하는 코드일 때한참 디버깅 후에 허무함을 안겨준 코드일 때함수 클래스 파일에 대한 주석일 때변수가 특이성을 가지고 있거나, 타입별로 세팅되는 값일 때플러그인이나 라이브러리 사용법을 공유할 때 4-2) 주석을 줄여 나가야 한다고 생각할 때 조건문의 내용을 한글로 다시 기술하고 있을 때프로그램과 관계 없는 내용일 때변수명으로 설명이 가능한 내용을 기술하고 있을 때4-3) 주석이 잘못 되었다고 생각할 때 나만 이해할 수 있는 단어나 문장으로 기술된 주석일 때주어가 없는 주석일 때5.상수를 활용하자코드값에 따라 분기를 작성 중이라면 상수를 활용하는 게 좋습니다. ‘F’보다는 FACEBOOK_SERVICE 가 더 직관적이기 때문입니다.<?php // 예제는 PHP로 작성 되었습니다. if ($userAccountType == 'F') {     // 페이스북 유저 처리 로직 } /** 유저 구분 값 페이스북 */ define('ACCOUNT_TYPE_FACEBOOK', 'F'); // 코드는 좀 더 길어보이지만 별다른 주석 없이도 어떤 코드인지 알 수 있다. if ($userAccountType == ACCOUNT_TYPE_FACEBOOK) {     // 페이스북 유저 처리 로직 } 상수는 프로그램마다 다양한 형태로 지원되기 때문에 선언 후 참조해서 쓴다면 주석을 줄이는 데에 많은 도움이 될 것입니다.6.복잡한 코드는 풀어서 쓰자여러 가지 사고의 결정이 다시금 엮여서 또 다른 결과를 만들어야 하는 복잡한 코드입니까? 우선 서술형 문장으로 먼저 정리하십시오. 그 다음 오류가 없다면 이어서 작성하는 것이 좋습니다. 2)// 기획전이 시작 되면 세팅한 값으로 할인을 하고 // 기획전이 끝나면 원래의 할인율로 돌아오게 하는 프로그램 이다. 1. 대상 기획전을 찾는다.     * 기획전 시작일이 오늘인가? 종료일이 오늘인가? 2. 트랜잭션을 연다. 3. 대상 기획전 건수 만큼 루프를 돌며     1. 조건 체크         case 1. 시작일이 오늘이면             1. 상품 상태를 기획전 데이터로 업데이트         case 2. 종료일이 오늘인면             1. 상품 상태를 시작일 이전 히스토리 데이터로 변경     2. 상품 히스토리를 남긴다. 4. 커밋한다. 저는 사고의 결과를 주석 형태로 작성하고, 순번을 달아서 진행을 정리합니다. 다음으로 정리된 내용을 검증하고, 주석을 중간 크기로 작성해 쪼갭니다. 그 밑에 코드를 작성하면 두 마리 토끼를 잡을 수 있습니다. 중간 크기의 주석은 프로그램의 진행 단위를 나눠서 보기 편하고, 단계별로 검증할 때에도 유용합니다.<?php /***************************************************** * 1. 대상 기획전을 찾는다. *     - 기획전 시작일이 오늘인가? 종료일이 오늘인가? **************************************************** */ // 세부 로직은 생략함 $list = getPlainedPromotionList(); /*****************************************************  * 2. 트랜잭션을 연다. **************************************************** */ beginTransaction(); /*****************************************************  * 3. 대상 기획전 건수 만큼 루프를 돌며 *****************************************************/ foreach ($list as $obj) { /*****************************************************  *        case 1. 시작일이 오늘이면  *            1. 상품 상태를 기획전 데이터로 업데이트 *****************************************************/     if ($obj['startDate'] == $today) {         updateProductDistRate($obj['productNo'], $obj['distRate']);    } /*****************************************************  *        case 2. 종료일이 오늘인면  *            1. 상품 상태를 시작일 이전 히스토리 데이터로 변경  *****************************************************/     if ($obj['endDate'] == $today) {        recoveryProductFromHistory($obj['productNo']);    } /*****************************************************  *    2. 상품 히스토리를 남긴다. *****************************************************/     addProductHistory($obj['productNo']); } /*****************************************************  * 4. 커밋한다. *****************************************************/ commit(); Conclusion영화 <인터스텔라(Interstellar, 2014)>의 주인공 쿠퍼(매튜 맥커너히)가 책장 너머 다른 차원에서 과거의 자신에게 신호를 보냈던 명장면이 생각납니다. “ STAY” 그의 메시지는 분명 후회의 몸부림이었을 겁니다. 마찬가지로 당신이 조건문을 부정적으로 만들고 있다면 잠시 키보드에서 손을 떼는 게 좋습니다. 다른 차원의 자신이 어딘가에서 메시지를 보내고 있을지도 모르니까요. “STOP….” 참고 1) 1초에 수백억 번 이상 연산이 가능한 컴퓨터에선 10회와 2회의 차이가 거의 없다. 2) 동료에게 정리한 문장을 이해시킬 수 있다면 정리가 잘 되었을 확률이 높다. 글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 523

SaaS 클라우드 서비스를 이용하여 성공적인 기업문화 만들기

문화는 매일 우리가 보고 느끼는 것입니다. 우리는 국가, 학교, 회사, 가족, 심지어는 친한 친구들의 모임과 같은 많은 사회의 구성원으로서 문화를 경험합니다. 조직이 특정 방식으로 행동하고 회사 내부와 외부에서 탁월한 능력을 발휘할 수 있도록 확고한 정체성을 부여하는 것은 기업문화보다 강력한 것은 없습니다. 기업은 명확한 비전, 사명 선언문 및 핵심 가치를 확정하고 이를 모두가 공유하고 경험할 수 있도록 조직의 최 하위 부서까지도 전해 내려와야 합니다. 이를 달성하기 위해서는 인적 자원 및 자본, 그리고 변화 관리의 역할이 매우 중요합니다. 오늘날 인적 자본 관리 IT 솔루션 및 어플리케이션은 급속히 성장하고 있으며 많은 조직에서 이를 이용하여 직원 간의 커뮤니케이션과 참여를 돕고 기업의 가치와 정책들이 스며들어 모두가 공유할 수 있는 장이 되고 있습니다.이메일 메모를 통한 공지, 모든 불필요한 서류 작업을 통한 복리후생 처리, 중앙 집중식 프로젝트 관리 및 보고 시스템은 과거에서나 많이 찾아볼 수 있는 모습입니다. 스마트폰과 많은 클라우드 기술이 발전된 지금은 바로 클라우드 기반 그룹웨어, 협업툴의 춘추전국시대라고 할 수 있습니다. 기존 아날로그에서 디지털로 변화하는 지금의 인간은 집중력을 발휘할 수 있는 시간이 점차 줄어들고 있습니다. 뉴욕 타임즈의 티모시 이건 (Timothy Egan)은 ‘The Eight-Second Attention Span’에서 ‘마이크로소프트(Microsoft)가 진행한 캐나다 미디어 소비에 대한 설문조사에서 사람의 평균 관심 시간은 8 초로 줄어들었다’고 결론지었습니다. 요즘 우리는 기업의 이메일 메모를 읽을 시간도 없을 뿐더러 항상 다양한 종류의 정보와 알림에 노출되고 있습니다. 요즘 가장 선호되는 통신 수단과 업무 수단은 랩탑과 스마트폰입니다. 그리고 많은 직원들이 재택근무, 외근, 유연근무 등으로 기업의 체질이 변화하고 있습니다. 조직의 리더인 우리는 구성원의 행동과 취향을 반영하여 기존 시스템을 변화시켜 직원의 니즈를 충족, 훌륭한 문화를 조성하고 전사적으로 보급하려는 노력이 필요합니다.직원 개개인을 생각한 훌륭한 시스템은 조직 전체의 효율성을 극대화합니다.직원들이 업무외의 다른 요소에 방해받지 않고 더 집중할 수 있도록 활용될 수 있는 새로운 커뮤니케이션 툴은 무엇이 있을까요? 어떻게 직원들의 성과를 인정하고 그에 대한 보상과 감사표시를 할 수 있을까요? IT 서비스를 접목함으로써 제거될 수 있는 불필요한 업무 절차는 어떤 것들이 있을까요? 기업 내에서 조직의 효율성을 극대화하며 각 직원 개개인의 만족도와 성취감을 높여줄 수 있는 많은 방법이 있습니다.1. 조직 내에서 직원들이 소통할 수 있는 가장 좋은 방법을 선택하십시오.효과적인 커뮤니케이션은 구성원 간의 좋은 관계와 신속한 업무 진행으로 이어집니다. 조직과 그를 구성하는 직원들도 마찬가지입니다. 새로운 방향, 일정 발표, 또는 기타 공지 사항 등 어떤 종류의 커뮤니케이션이든 소통은 명확하고 목적이 뚜렸해야 합니다. 일주일 전에 받았던 공지를 찾느라 공지 메일을 검색하거나 채팅방 내에서 위 아래로 스크롤하는 작업은 직원의 많은 시간을 낭비하게 됩니다. 조직 내에서 사용할 기업용 커뮤니케이션 채널을 정하십시오. 직원이 이메일, SMS 또는 일반 메신저에 묻혀 있는 메시지들 중 업무관련 메시지들을 매번 골라내야 한다면 조직의 관점에서 굉장한 손실을 떠안게 될 수 있습니다.기업에서 사용할 수있는 SaaS 커뮤니케이션 및 협업 툴의 몇 가지 예:slack : 메시징 및 타서비스 연동JANDI : 메시징 및 서비스 연동collabee : 협업, 타임라인 및 프로젝트 칸 반BeeCanvas : 시각적 작업 공간 및 실시간 협업GRAP : 기업용 소셜 네트워크, 타임라인위의 모든 서비스들은 기업 데이터, 정보를 암호화하여 높은 보안 수준의 클라우드 저장소에 제공합니다. 이 같은 서비스를 사용하면 직원이 그룹, 부서 또는 프로젝트를 만들 수 있으며 관련 구성원만 참여하도록 초대하여 협업할 수 있습니다. 이러한 도구 중 일부는 업무 또는 프로젝트 승인/결재 체계을 갖추고 있으므로 누가 언제 어떤 작업을 승인하였는지 추적 할 수 있습니다.기업내에서 구성원들이 사용하는 커뮤니케이션 툴을 정하고 나면 보다 명확한 의사소통과 업무진행으로 인해 조직 전체의 효율성이 높아지게 됩니다. 또한 보안이 확실하지 않은 매개체를 통해 업무 관련 통지 및 소통할 시 데이터 손실의 위험이 있으며 해커가 정보 유출을 시도할 시 취약한 구조를 가지게 됩니다. 다시 말하지만, 안전한 통신 채널을 정하여 소통을 명확하게 유지하고 혼란을 최소화하십시오. 그렇다면 인간 상호 작용을 장려하는 것입니다.2. 직원들이 서로의 성과와 업적을 인정할 수 있도록 칭찬 및 보상 시스템 사용모든 직원은 기업의 스타입니다. 조직의 구성원은 자신의 업적과 성과에 대해 인정 받을 자격이 있으며 자신이 하는 일을 자랑스럽게 여길 수 있어야 합니다. 시간 안에 프로젝트를 끝내도록 동료가 도움을 주었거나 다음 번에 더 잘 할 수 있도록 매니저가 과거 프로젝트에 대한 귀중한 피드백을 주었다면 어떤 경우이든 상관없이 이를 인정해 주고 감사의 마음을 표하게 됩니다. 때로는 말로는 충분하지 않기도 하죠. 어떤 회사는 기업내에서 모든 사람이 서로를 인정할 수 있도록 칭찬 및 보상 시스템을 사용하기도 합니다. 칭찬을 많이 받은 직원의 경우 모인 칭찬을 백화점 기프트 카드와 같은 보상의 형태로 전환하여 사용할 수 있습니다. 귀사가 이미 오프라인에서 열심히 일하는 직원을 인정하며 보상 시스템을 운영하고 있다면, 이제는 동일한 작업을 수행 할 수 있는 더 나은 방법이 있습니다. 실질적인 효과를 볼 수 있는 직원 복지 시스템을 도입하여 직원들의 동기부여와 사기를 극대화하고 서로에게 용기를 북돋아줄 수 있는 문화를 만들어보세요.위에서 언급한 피어 투 피어 (peer to peer) 칭찬과 보상 플랫폼을 제공하는 많은 신생 스타트업과 기존 기업들의 서비스들이 있습니다:kudos : ‘직원 인정 시스템 및 기업 소셜 네트워크’Redii : ‘가장 큰 자산(팀)의 힘을 활용하여 훌륭한 비즈니스를 성장시키고자 하는 중소 기업을 위해 설계된 간단한 직원 성과 인정 소프트웨어’globoforce : ‘사회적 인정 : 감사의 힘’평범한 휴가나 보너스를 주는 전통적인 방법에 비해서 온라인으로 서로가 서로를 인정해주고 이에 대한 보상 시스템을 이용하면 누가 어떤 이유로 누구를 위해 고맙게 여기는가에 대한 투명성이 높아집니다. 동료가 성공을 달성할 수 있도록 서로 돕고 응원하는 문화를 만들어보세요. 보상 및 인식 시스템을 구현하여 모두가 윈-윈하는 문화를 육성할 수 있습니다.3. 기업의 직원 복지와 의료 혜택 또는 개인 지출 트래킹 프로세스가 더 우수하고 스마트해질 수 있습니다.당신의 기업은 사용자 경험(UX)을 극대화해야한다고 생각하십니까? 기업내 직원의 경험도 고려해 보세요.커뮤니케이션 도구와 마찬가지로 모든 HR 이나 재무 관련 서류 및 승인 절차는 복잡하고 지루하지 않아도 됩니다. 기업의 많은 직원들은 업무를 처리하기 위해. 불필요한 절차에 더 많은 시간을 할애합니다. 정확히 말하면 실제로 일을 끝내는 것보다 보고서 작성과 결재를 기다리는 데에 많은 시간을 보내고 있습니다. 이제는 대부분의 불필요한 절차 및 서류 작업은 IT 기술로 대체 될 수 있습니다. 이러한 지루한 서류 작업과 승인 사례를 들어 보겠습니다.휴가를 승인받기 위해 휴가신청서를 문서로 제출하여 서명 받거나 신청서를 스캔하여 이메일로 결재를 받는다.지출 보고서를 엑셀로 작성하여 영수증을 첨부하고 관리자의 결재를 받고 느린 업무 처리로 인해 늦게 환급 받는다.기업에서 제공하는 특별 직원 복지인 헬스장 비용 지원금을 이용하기 위해 신청서를 문서로 제출하고 결재를 받는다.위의 모든 결재된 문서는 서류함에 보관되어 공간을 많이 차지하며 접근성이 떨어진다.휴가 요청, 건강 및 복지 혜택 및 비용 보고와 같은 일상적인 재무와 HR 업무에 대해 기업내부에 명확하고 투명한 승인 체계를 클라우드 시스템으로 적용하면 직원과 관리자의 많은 시간을 절약하고 요청이 승인되었는지 이메일을 보내거나 개인적으로 물어봐야 하는 절차를 없애줍니다. 이러한 시스템은 많은 프로세스가 자동화되어 모든 관련 당사자가 열람 및 관리가 가능합니다. 모든 직원들이 편의를 느낄 수 있는 훌륭한 시스템을 도입해보세요.Workday Benefits : 기업의 복지 시스템 운영 툴.Expensify : ‘영수증 스캐닝에서 승인 및 환급까지, Expensify는 비용보고 프로세스의 모든 단계를 자동화합니다.’Gusto : 급여, 복리 후생 및 인사SaaS 클라우드 컴퓨팅 서비스를 사용한다는 것기업에서 업무 효율성을 위한 전통적인 소프트웨어들은 대부분 개별 컴퓨터에 설치된 독립형 소프트웨어로 제한되어 있었습니다. 예를 들어, Office 365가 출시되기 전의 Microsoft Office를 기억해 보십시오. 모든 Microsoft Office는 모든 직원들의 컴퓨터에 개별적으로 설치되어 오프라인으로만 작업할 수 있었습니다. 지금은 클라우드에서 모든 문서작업이 가능하며 동료 혹은 협력사의 담당자와도 협업이 가능하게 되었습니다. 이를 보면 우리의 일상에 클라우드 컴퓨팅은 그 어느 때보다도 널리 보급되어 있습니다. 이러한 솔루션의 대부분은 SaaS (Software as a Service)로 제공됩니다. Google 드라이브, Office 365, Salesforce CRM 및 Dropbox는 우리가 사용하는 주요 클라우드 기반 서비스의 예이며 많은 기업들이 클라우드 시스템으로 전환하고 있습니다. 왜 클라우드 서비스가 급성장하고 있을까요? 이유는 다음과 같습니다.1. 접근성. 조직의 데이터를 자체 서버에 저장하는 대신 클라우드 서비스 활용하여 데이터에 접근하고 원격으로 작업도 할 수 있습니다. 스마트폰과 노트북은 우리 일상과 업무처리를 하는 매개체로서 많은 비율을 차지하고 있으며 이제는 누구나 인터넷에 접속할 수 있습니다. 이제는 업무용 프로그램을 오프라인 상태로 제한할 이유가 없습니다.2. 비용 절감. 비즈니스 및 개인 간 클라우드 컴퓨팅의 출현은 우리의 상당한 비용을 절감케 했습니다. 기존의 무거운 프로그램과 데이터베이스를 운영하는 전통적인 방식은 서버 유지 관리, 데이터 저장, 백업, 개발 등의 상당한 비용을 발생시킨 데에 비해, 클라우드형 서비스는 앞의 비용이 발생하지 않습니다.3. 유연성. 클라우드 기반 서비스는 대역폭, 사용자수 등의 니즈가 증가하거나 변동하는 비즈니스를 위해 다양한 옵션을 제공합니다. 예를 들어, CRM 시스템을 이용해야 하는 직원이 많아졌다면 사용자를 추가한 만큼 요금이 변동됩니다. 간단하게 말하면, SaaS 서비스의 가장 큰 장점 중 하나는 기업의 니즈가 변화할 때마다 확장 및 축소가 쉽다는 점입니다.자유, 권한, 생산성한 명의 특별한 사람이 모든 문제를 결정하고 해결할 수 있을까요? 마이크로 매니징은 팀 운영에 있어 많은 악영향을 끼칩니다. 업무의 부담을 나누고 책임과 권한을 알맞은 담당자에게 위임하는 것은 기업의 관점에서 상당한 효율성을 발휘합니다. 조직 계층 구조의 각 직원이 스스로 결정할 수 있도록 하고, 자신이 내리는 의사 결정에 수반되는 책임을 느낄 수 있도록 한다면 직원들의 오너십을 키울 수 있습니다.당신의 비즈니스 운영에 맞도록 클라우드 시스템을 도입한다면 앞서 언급된 권한 위임과 의사결정을 내릴 수 있으며 부하직원의 프로젝트를 결재하는 기능은 필수라고 볼 수 있습니다. 그렇지 않으면 모든 승인 절차는 이메일이나 서류 절차 같이 시스템의 외부에서 이루어집니다. 새로운 시스템이 기업의 권한/승인 절차와 부합되는지, 조직의 운영적 니즈를 얼마나 수용하는지 확인해 보아야합니다.체크리스트 예:시스템에 여러 개의 액세스 레벨이 있습니까?특정 액세스 권한만 승인 할 수 있습니까?승인자의 이름과 시간을 기록해줍니까?직원에게 더 많은 자유를 부여하십시오. 직원들이 스스로 결정을 내리고 스스로의 동기부여와 생산성을 높일 수 있도록 알맞은 권한을 부여하세요. 우리는 리더로서 직원들의 자유와 권한을 허용하는 동시에 책임을 지어주고 합리적인 규칙과 지침, 그리고 성과 측정 방식을 이용하여 모두가 기업과 함께 성장할 수 있는 방향성을 제시할 수 있어야 합니다. 이렇듯 기업문화를 형성하고 그에 걸맞는 기술을 부합하여 기업과 구성원 모두의 이익을 극대화해보세요.#시프티 #기업문화 #혁신 #SaaS #조직문화 #기업소개 #시스템구축 #원격근무 #리모트 #디지털노마드
조회수 1434

린더를 만들고 있는 이유 2.0

본문은 2017년 8월 작성한 린더를 만들고 있는 이유 1.0 의 후속편입니다.히든트랙이 해결하고자 한 문제히든트랙팀은 '린더'라는 일정을 받아보는 경험을 만들어가고 있습니다. 2018년 4월 기준 약 16만명의 사용자가 린더를 통해 일정을 받아보고 있으며, 린더가 존재하기 전 사람들을 일일히 자신들이 필요로 하거나 궁금한 일정들을 검색하여 확인해야만 했습니다. 우리가 문제를 해결한 방식은 매우 간단합니다. 매번 필요할 때마다 검색해봐야 했던 일정을 우리가 대신 기록하여 그것을 받아볼수 있도록 제공 하는것, 다시 말해 다수가 공통적으로 안고 있던 귀찮음을 소수의 노력으로 해결하고자였으며 이와 같은 문제 해결 방식은 명함 수기 입력 앱 - 리멤버 또는 전단지 모음 앱 - 배달의 민족이 접근한 방식과 유사합니다.첫 번째 선택, 캘린더 기반 일정 구독 ( https://linder.kr/ )일정을 받아보는 경험은 모바일앱, 챗봇, AI 스피커 등 다양한 방식으로 구현될 수 있습니다. 그중에서도 히든트랙팀이 선택한 첫 번째 방식은 이미 다수가 활용중인 캘린더 앱의 구독 기능을 활용한 것입니다. 스마트폰 기본앱인 캘린더를 하나의 정보 전달 채널로 활용함으로써 거부감 없이, 낮은 진입장벽으로 출시 반년 만에 15만명이 넘는 사용자를 확보할수 있었습니다.캘린더 기반 일정 구독의 한계하지만 캘린더를 기반으로 한 일정 구독에는 명확한 한계가 몇 가지 있었습니다. 1) 구독 캘린더의 특성상 리마인더 기능이 매우 제한적이었으며  2) 각 플랫폼 별 다른 동기화 시간으로 인해 실시간 업데이트가 불가했습니다. 3) 또한 기존 캘린더에 입력되어있던 개인 일정과 받아보는 일정이 혼재되어 분류가 어려웠으며 4) 일정을 삭제하거나 메모를 입력할 수 없었습니다.캘린더의 한계를 극복할 수 있는 자체 앱 제작 ( http://bit.ly/2EB41TW )이에 히든트랙팀은 지난 2017년 말 진행한 다수의 유저 인터뷰를 바탕으로 2018년 1월부터 약 3개월 간 일정을 받아보는 경험에 최적화된 모바일 앱을 개발하였습니다. 모바일의 핵심은 필요한 일정을 정확한 시점에, 검색 없이도 쉽게 받아 볼 수 있는데 초점을 두고 있습니다.린더 : 받아보는 캘린더 - Google Play 앱play.google.com 일정을 받아보는 경험에 대한 사용자와 이해 관계자히든트랙팀이 캘린더 기반의 일정 구독자와 모바일앱 사용자 모두에게 공통적으로 제공하고자 하는 것은 사용자가 자신에게 필요한 일정을 보다 쉽고 확실하게 소비할 수 있도록 돕는 것입니다. 사람들에게 필요한 일정은 아이돌 스케줄부터 화장품 세일, 학사일정에서부터 마트 휴무일까지 다양한 분야에 존재합니다. 일정을 받아보는 경험을 만들어가는 과정에서 우리가 일반 사용자 외에도 고려해야 할 나머지 두 종류의 이해 관계자는 일정을 공급하는 공급 파트너와 유통을 돕는 유통 파트너가 있습니다.망하기 딱 좋은 일정 데이터 생산 비즈니스일정을 받아보는 경험을 만들어가는 과정은 여느 타 서비스에 비해 매우 소모적입니다. 일정 데이터는 리뷰(왓챠)나 댓글(크리마), 연락처(리멤버) 등 과는 다르게 데이터의 휘발성이 매우 강하며 변동성 또한 매우 크기 때문에 다수의 기업들이 기피하는 데이터 형태라고 볼 수 있습니다. 일례로 2016년부터 2017년 중순까지 운영되었던 SKT의 Someday(썸데이)는 내부 조직장 교체와 비효율적인 ROI로 서비스가 종료된 바 있습니다.같은 실수를 저지르지 않기 위한 일정 데이터 서비스 전략 로드맵히든트랙팀은 2017년 1월부터 다수의 일정 관련 서비스 개발을 진행해왔으며 이 과정에서 습득한 노하우를 바탕으로 일정 데이터 생산 및 공급망을 구축할 수 있는 3단계 계획을 세우게 되었습니다.STEP.1 린더 파트너스 - 데이터 공급 파트너 확보캘린더 기반 일정 마케팅 솔루션 '린더 파트너스'는 해외 eCal, CalendarX, Eventable 등 다수의 캘린더 마케팅 업체를 벤치마킹하여 국내 인터넷 환경에 맞추어 최적화시킨 아시아 유일의 캘린더 마케팅 솔루션 입니다. 2018년 3월 기준 롯데자이언츠, 두산베어스, 수원삼성FC, 아디다스 코리아 등 20여 개의 데이터 공급 파트너를 확보한 린더 파트너스를 기반으로 히든트랙팀은 공식적인 데이터 공급 파트너를 확보함과 동시에 데이터 생산을 위한 초기 자본을 조달할 수 있게 되었습니다. 파트너스 영업은 현재 영업팀을 주축으로 이루어지고 있으며 2018년 말까지 현 20여 개의 파트너를 50여 개 수준으로 늘리는 것을 목표로 하고 있습니다.STEP.2 린더 모바일앱 - 일반 사용자 확보린더 파트너스를 통해 확보한 자금과 일정 생산력을 바탕으로 모바일앱 데이터의 정확도와 품질을 향상하고 사용자 중심의 서비스를 구축합니다. 기업 친화적인 린더 파트너스와는 다르게 린더 모바일앱은 오로지 일반 사용자를 위한 서비스로서 사용자 친화적인 인터페이스와 일정 콘텐츠 소비 경험을 핵심으로 합니다. 다수의 일반 사용자를 확보함으로써 제보 기능(크라우드소싱)을 활용하여 데이터의 정확도와 유저별 선호 캘린더 데이터를 파악할 수 있게 됩니다.  2018년 4월 안드로이드/iOS 앱 출시가 예정되어 있으며 2018년 연말까지 5만 이상의 MAU 확보를 목표로 하고 있습니다.STEP.3 린더 데이터헙 - 데이터 유통 파트너 확보글의 서두에서 언급한 바와 같이 일정을 받아보는 경험은 단순히 캘린더나 모바일앱 외에도 다양한 방식으로 제공될 수 있습니다. 확보한 데이터 공급 파트너와 일반 사용자 제보를 바탕으로 일정 데이터량과 품질을 향상하고, 더 나아가서는 보유한 유저 Pool을 바탕으로 사용자들의 선호도를 사전에 파악할 수 있게 됩니다. 이러한 다양한 종류의 데이터를 기반으로 현재 스피커 및 기타 AI 서비스를 제공 중인 네이버, 카카오, 삼성, SKT, KT 등의 유통 파트너를 대상으로 영업을 진행, 협력을 통해 다양한 방식으로 사용자들에게 일정 정보를 전달할 수 있게 됩니다.히든트랙의 3가지 비즈니스 모델위 언급한 3단계의 전략 로드맵을 통해 히든트랙은 3가지 수익창출 기회를 확보할 수 있습니다. 1) 캘린더 마케팅 솔루션 - 린더 파트너스의 Enterprise SaaS 형태 공급 및 데이터 관리 용역을 통한 수익2) 린더 앱 내 확보한 사용자 선호도를 바탕으로 일정 기반의 마케팅 광고주들에게 제공하여 창출하는 수익 3) 그리고 유통 파트너들에게 일정 데이터를 제공하는 대가로 받는 데이터 판매 및 용역에 대한 수익 이 바로 그 3가지 입니다.'린더' 하다 = 일정을 받아보다다각적인 비즈니스 모델과 단계가 존재하지만 결과적으로 이를 통해 확보한 매출의 재투자와 회사의 방향성은 하나로 일원화 될 수 있습니다. 그것은 바로 사람들의 소중한 일정을 놓치지 않도록 도와주는것. 자동차 네비게이션과 같이 서비스가 삶에 완벽히 녹아들어 그것이 부재하던 시절의 삶을 상상할 수 없게 되는 것이야 말로 가장 높은 수준의 서비스 구현이라 할 수 있습니다. 과거에 지도에만 의존하여 길을 찾던 시절 소수의 사람들이 네비게이션의 가능성을 보고 그것을 만들어왔던 것처럼, 사람들이 린더를 통해 그들의 소중한 일정을 놓치지 않도록 도와주는 것이 우리의 최종 목표입니다.#히든트랙 #챗봇 #기술기업 #개발자 #개발팀 #인사이트 #경험공유
조회수 4122

서버 비용을 70%나 줄인 온디맨드 리사이징 이야기

비트윈의 서버에는 사용자들이 올리는 수많은 사진이 저장되어 있습니다. 2016년 3월 기준으로 커플들이 데이트에서 찍은 사진, 각자의 프로필 사진, 채팅을 나누며 올린 재미있는 짤방까지 약 11억 장의 사진이 저장되어 있습니다. 비트윈에서는 이러한 사용자들의 소중한 추억을 잘 보관하고, 사용자들의 요청을 빠르고 비용 효율적으로 처리하기 위해서 많은 노력을 기울이고 있습니다. 이번 포스팅에서는 비트윈 개발팀이 사용자들의 사진 처리를 보다 효율적으로 하기 위해서 어떠한 노력을 하였는지 공유하고자 합니다.기존의 아키텍쳐¶비트윈 사용자가 채팅창이나 모멘츠 탭에서 사진을 업로드 할 경우, 해당 사진은 업로더 서버라고 불리는 전 세계 각지에 퍼져 있는 사진 업로드 전용 서버 중 가장 가까운 서버를 자동으로 찾아서 업로드 됩니다. 업로더 서버는 사진을 해당 AWS Region의 S3 bucket에 적재하고, 미리 지정된 크기의 썸네일을 자동으로 생성하여 역시 S3에 저장합니다. 그리고 Tokyo Region에 있는 비트윈 메인 서버에 이 결과를 토큰 형태로 전송하여 DB에 그 정보를 저장하도록 합니다. 이러한 과정을 통해서 일반 HTTP request보다 훨씬 큰 용량을 가지고 있는 사용자의 사진이 최대한 적은 지연시간을 가지고 업로드되도록 합니다.사용자가 올린 사진은 원본이 S3에 저장됨과 동시에 미리 정해진 사이즈로 썸네일을 생성해서 저장된다.하나의 사진이 대략 5장에서 6장의 서로 다른 크기의 썸네일로 리사이징이 되는데, 이는 클라이언트의 디스플레이 크기에 따라서 최적화된 이미지를 내려주기 위함이었습니다. 예를 들어서 아주 작은 썸네일이면 충분한 채팅 프로필 표시 화면을 그리기 위해서 사용자가 올린 3백만 픽셀이나 되는 원본 사진을 받아서 클라이언트가 리사이징 하는 것은 지연 시간뿐 아니라 과도한 데이터 사용이라는 측면에서 효율적이지 않기 때문에 작게 리사이징 해놓은 사진을 내려주는 것이 더 바람직합니다.비트윈 사용자들의 넘치는 사랑(?)에 비트윈은 출시 후 5년 동안 약 11억 장, 썸네일을 모두 합치면 66억 장의 사진을 저장하게 되었습니다. 이 사진은 전부 AWS S3에 저장되어 있으며, 썸네일을 합친 총 용량은 2016년 3월 기준 무려 738TB였습니다. 이에 따라 사진을 저장하기 위한 S3 비용이 전체 인프라 운영 비용에서 상당 부분을 차지하게 되었습니다.기존 아키텍쳐의 비효율성¶비트윈 팀은 어느 날 위와 같은 기존의 사진 전송 아키텍쳐에 의문을 가지게 되었습니다. 비트윈 서비스가 다른 서비스와 가장 다른 특징 중의 하나는 커플 간의 데이터는 그 둘 사이에서만 공유된다는 점입니다. 일반적인 웹사이트 같은 경우, 하나의 게시물 혹은 이미지가 수천 수 만명의 유저에게 전달되지만 비트윈에서는 그렇지 않습니다. 즉, 개별 사진의 Fan-out이 작다는 점을 특징으로 가지고 있습니다.그리고 클라이언트에서 LRU를 기반으로 한 파일 캐쉬를 사용하고 있는데, 이를 통해서 위에서 말씀드린 채팅창 프로필 사진 같은 경우 클라이언트에서 캐쉬될 가능성이 매우 커지게 됩니다. 그리고 CDN으로 사용하고 있는 AWS의 CloudFront에서도 약 30~40%의 추가적인 Cache hit을 얻을 수 있었습니다. 즉, 이미 Fan-out이 낮은 리소스가 높은 Cache hit rate를 가지는 사용패턴을 가지고 있는 셈이 됩니다.더군다나 사용자의 디바이스 사이즈에 따라서 미리 리사이징 해놓은 썸네일 중 일부는 아예 사용하지 않는 사용패턴이 나타나기도 합니다. 아이패드와 같은 큰 디스플레이를 가진 클라이언트를 쓰는 사용자와 아이폰4를 사용하는 사용자가 필요로 하는 썸네일의 크기는 다를 수밖에 없기 때문입니다.아래의 그래프는 S3 접근 로그를 분석해서 파악한 특정 기간 내에 같은 해상도를 가지는 썸네일을 클라이언트가 한 번 이상 재요청 하는 비율을 나타내는 그래프입니다. 하루 내에 같은 해상도의 사진을 요청하는 경우는 10% 가 되지 않으며, 한 달 안에도 33% 정도에 불과한 것을 알 수 있습니다.특정 기간 내에 S3에 저장된 썸네일이 다시 요청되는 비율결국 비트윈 팀은 미리 여러 해상도의 썸네일을 준비해서 저장해 놓은 아키텍쳐보다는 사용자가 요청할 때 그 요청에 알맞게 리사이징된 썸네일을 새로 생성해서 내려주는 게 훨씬 비용 효율적이라는 결론에 도달하게 됩니다.새로운 아키텍쳐¶Skia¶하지만 이러한 온디맨드-리사이징 아키텍쳐로의 변환에 가장 큰 걸림돌이 있었습니다. 바로 사진의 리사이징에 오랜 시간이 걸린다는 점이었습니다. 비록 아키텍쳐 변화를 통해서 저희가 얻을 수 있는 비용 이득이 크더라도, 비트윈 사용자 경험에 느린 사진 리사이징이 방해가 되어서는 안 되었습니다.이때 저희가 찾은 것이 바로 Skia 라이브러리였습니다. Skia 라이브러리는 Google에 의해서 만들어진 2D 그래픽 라이브러리로써, 크롬이나 안드로이드, 모질라 파이어폭스 등에 사용되고 있었습니다. 그리고 이 라이브러리는 CPU 아키텍쳐에 따라서 인스트럭션 레벨로 매우 잘 최적화가 되어 있었습니다. 저희가 기존에 쓰고 있던 ImageMagicK에 비해서 거의 4배 속도로 이미지 리사이징을 처리할 수 있었으며, 총 CPU 사용량도 더 적었습니다. 저희는 이 라이브러리를 Python으로 wrapping한 PySkia라는 라이브러리를 내부적으로 만들어서 사진 리사이징에 사용하기로 하였습니다.WebP¶저희는 여기서 한발 더 나아가 보기로 했습니다. 단순히 리사이징만 Skia로 대체하는 것이 아니라, 원본 사진의 저장도 더 효율적으로 할 방법을 찾게 되었습니다. 그 결과 자연스럽게 떠오른 것이 비트윈 스티커 시스템에서 사용되었던 WebP 방식이었습니다. WebP 역시 구글이 만든 이미지 인코딩 방식으로써, 비슷한 화질을 가지는 JPEG에 비해서 약 26% 정도의 용량이 절약된다는 점에서 장점이 있습니다.온디멘드-리사이징¶위에서 언급한 대로 Skia 리사이징과 WebP 원본 저장을 합하여 아래와 같이 필요한 해상도의 사진을 그때그때 리사이징 하는 온디멘드-리사이징 아키텍쳐로 옮겨가게 되었습니다.사용자가 올린 사진은 원본이 WebP로 변환되어 S3에 저장된다. 클라이언트의 요청이 있을 때는 그때그때 요청한 사이즈로 리사이징한 썸네일을 생성해서 내려준다.리사이저 서버가 사용자의 요청을 받아서 원하는 해상도의 사진을 리사이징해서 내려주기까지 채 100ms가 걸리지 않는데, 이 정도면 사용자의 경험에 영향을 주지 않는다고 판단하였습니다. 리사이저 서버는 업로더 서버와 함께 세계 각지의 AWS Region에 배포되어 있으며, 이는 사용자가 요청한 사진을 최대한 빨리 받아가기 위함입니다.기존 사진 마이그레이션¶위와 같은 아키텍쳐 전환을 통해서 새롭게 업로드 되는 사진들은 원본만 WebP로 변환되어 저장한 후 요청이 들어올 때만 온디멘드 리사이징이 되지만, 그동안 비트윈 사용자들이 축적해 놓은 11억 장의 사진은 여전히 여러 사이즈의 썸네일로 미리 리사이징이 되어 있는 비효율적인 상태였습니다. 저희는 이 사진들도 마이그레이션하는 작업에 착수했습니다.11억 장이나 되는 원본 사진들을 전부 WebP로 변환하고, 나머지 50억 장의 미리 생성된 썸네일 사진을 지우는 작업은 결코 간단한 작업이 아니었습니다. 저희는 이 작업을 AWS의 Spot Instance와 SQS를 통해서 비용 효율적으로 진행할 수 있었습니다.Auto Scaling with Spot instance¶마이그레이션 작업은 크게 다섯 단계로 이루어져 있습니다.커플 단위로 작업을 쪼개서 SQS에 쌓아놓습니다.Worker가 SQS로부터 단위 작업을 받아와서, 해당 커플에 존재하는 모든 사진을 WebP로 변환하고 S3에 올립니다.S3로의 업로드가 확인되면, 그 변경 사항을 DB에 적습니다.기존 썸네일 사진들을 삭제합니다.기존 썸네일이 삭제되었다는 사실을 DB에 적습니다.작업을 하는 도중에 얼마든지 Worker가 중단되거나 같은 커플에 대한 작업이 두 번 중복되어서 이루어질 위험이 있습니다. 이를 위해서 마이그레이션 작업을 멱등적으로 구성하여서 사용자의 사진이 손실되는 등의 사고가 발생하지 않도록 하였습니다. 중간마다 DB에 접근해서 변경된 내용을 기록해야 하는 작업의 특성상, 작업의 병목 구간은 비트윈 DB였습니다. 그리고 사진 인코딩을 바꾸는 작업의 특징상 많은 CPU 자원이 소모될 것으로 생각하였습니다.DB에 부담이 가지 않는 범위내에서 많은 CPU 자원을 끌어와서 작업을 진행해야 할 필요성이 생긴 것입니다. 이 조건을 만족하게 하기 위해서 SQS를 바라보는 Worker들로 Auto-scaling group을 만들었습니다. 그리고 이 Auto-scaling group은 c3.2xlarge와 c3.4xlarge spot instance로 구성되어 있으며, DB의 CPU 사용량을 메트릭으로 하여 Scaling이 되도록 하였습니다. 작업은 주로 DB의 부하가 적은 새벽 시간에 집중적으로 이루어졌으며, 이 인코딩 작업은 대략 4일 정도가 소모되었습니다. 작업 과정에서 Tokyo Region에 있던 c4.2xlarge와 c3.4xlarge spot instance를 최대 140대를 사용했고, 총 사용 시간은 6,767시간이었습니다. 사용한 instance의 계산 능력을 ECU로 환산하면 총 303,933 ECU · hour를 작업에 사용하였습니다. 마이그레이션에 사용된 EC2 비용을 바탕으로 계산해 보면, 백만 장의 WebP 인코딩을 위해서 사용한 비용이 $1.8 밖에 되지 않았다는 것을 알 수 있습니다.작업 과정에서 AWS 서비스에 의외의 병목 구간이 있다는 것을 알게 되었는데, S3 단일 버킷에 1분당 1천만 개 이상의 object에 대한 삭제 요청이 들어오면 Throttling이 걸린다는 사실과 SQS의 in-flight message의 개수가 12만 개를 넘을 수 없다는 것입니다.결과¶위의 아키텍쳐 변화와 마이그레이션 작업 후 저희의 S3 비용은 70%가 넘게 감소했으며 전체 인프라 비용의 상당 부분이 감소하였습니다. 온디멘드 리사이징으로의 아키텍쳐 변화는 Storage 비용과 Computation 비용 사이의 교환이라고 볼 수 있는데, 아래 그래프에서 볼 수 있듯이 확연한 비용 절감을 달성할 수 있었습니다.총 마이그레이션 비용¶항목사용량비용 ($)EC2 spot instance6,767 hrs1,959.11SQS188,204,10489.59S3 Put/Get Requests2,492,466,8605,608.34총비용7,657.04마이그레이션 결과¶항목Before MigrationAfter Migration감소량 (%)S3 # of objects6.65 B1.17 B82.40S3 storage738 TB184 TB75.06비용 감소¶사진 저장과 리사이징에 관련된 비용이 68% 감소하였음못다 한 이야기¶이번 포스팅에서는 최근에 있었던 비트윈 사진 아키텍쳐의 변화에 대해서 알아보았습니다. 주로 사용자의 경험을 방해하지 않는 조건에서 비용을 아끼는 부분에 중점을 두고 저희 비트윈의 아키텍쳐 변화에 대해서 설명해 드렸습니다. 하지만 이 글에서 미처 언급하지 못한 변화나 개선 사항들에 대해서는 다루지 못했습니다. Tokyo Region에서 멀리 떨어져 있는 사용자를 위해서 전 세계 여러 Region에 사진 저장/전송 서버를 배포하는 일이나, 사진을 로딩할 때 낮은 해상도로부터 차례대로 로딩되도록 하는 Progressive JPEG의 적용, 사진을 아직 받아오지 못했을 때 Placeholder 역할을 할 수 있는 사진의 대표색을 찾아내는 방법 등이 그것입니다. 이에 관해서는 후에 자세히 다뤄보도록 하겠습니다.정리¶비트윈 개발팀에서는 많은 인프라 비용을 소모하는 기존 썸네일 저장 방식을 개선하여 70%에 가까운 비용 절감 효과를 보았습니다. 기존의 썸네일을 미리 생성해놓는 방식으로부터 클라이언트가 요청할 때 해당 크기의 썸네일을 리사이징해서 내려주는 방식으로 변경하였고, WebP와 Skia등의 새로운 기술을 적용하였습니다. 이를 통해서 사용자 경험에는 거의 영향을 주지 않은 상태로 비용 절감 효과를 볼 수 있었습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 1744

[인터뷰]미미박스의 TECHNOLOGY를 이끄는 CTO KAY를 만나다

안녕하세요. Ava입니다.여러분에게 더 건강하고, 아름다운 라이프스타일을 제공하기 위해 노력하는 미미박스 뒤에는여러분의 니즈를 만족시키고 안정된 서비스를 제공하기 위한 개발이끊임없이 진행되고 있습니다.오늘은 미미박스 TECHNOLOGY UNIT를이끌고 계신 김종광 CTO(이하 KAY) 님을 소개해드리겠습니다.KAY는 대기업과 IT기업에서 앱 개발과 웹 개발을 진행했던 커리어를 갖고 계신데요. 경력과 전문성 뿐만 아니라 개발자들이 상상할 수 있는 문화를 강조하며 만들어나가고 있습니다.항상 푸근한 아빠 미소로 미미박서의 질문과 제안을 받아주고,열린 리더의 모습을 보여주시는 KAY를 소개합니다.김종광 (Kay) 한국기술교육대학교 전기전자공학 석사전) NC소프트전) SK communicationsUNIT1. KAY를 소개해주세요.Q. 안녕하세요. 항상 아빠 미소를 짓고 계신 KAY~KAY를 소개해주세요.A. 처음에 미미박스에 모바일 앱 개발 총괄로 입사했어요. 지금은 개발 UNIT 전체를 맡고 있고요. 세 가지의 주 업무가 있는데요. 개발 전체 프로젝트를 leading 하고 다른 팀과 연관된 업무에 대해서 지원하는 일과, 새로운 개발자를 충원하는 업무를 하고 있습니다.Q. 미미박스에 입사하시게 된 계기는 무엇인가요? A. 처음에는 지인이 추천해서 미미박스를 알게 되었어요. 그 후에 미미박스에 대해 조사를 해봤죠. 비즈니스 모델, 성장 가능성을 봤을 때 '될 것 같다'는 생각을 가졌어요. 그리고 몇 번 찾아갔었는데 회사 분위기가 활기차고 재밌었어요. 그리고 일하는 사람들 중에 아는 사람들이 4~5명 정도 더 있었어요. 이분들과 다른 구성원들을 보면서 '이 친구들이랑 같이 일하면 즐겁게 일할 수 있겠다'라는 생각이 들었죠.Q. 여러 조직에서 있으셨던 만큼 개발 업무 자체에 대한 이유도 있을 것 같아요. A. 보통 기업에서는 개발자의 역할이 상당히 제한되어있어요. 업무에 대한 의사결정 권한이 거의 없죠. TOP-DOWN 방식으로 내려온 것들을 그냥 해야 하는 경우가 많거든요. 개발자들은 다들 알 거예요. 만들면서 '이거 안될 것 같다.'라는 감이 있는데, 느낌상으로 안될 것 같은 것을 만드니까 의욕이 생기지 않는 경우가 있었어요. 효과성보다는 어떤 서비스를 오픈했다는 것 자체가 실적이 되는 경우가 많거든요. Q. 그런 경우가 있군요. 그렇다면 미미박스 내에서는 개발 업무에 대해 어떤 식으로 의사결정이 이루어지나요?A. 업무에 대한 의사결정은 반반인 것 같아요. 우선 TECHNOLOGY UNIT 내부에서 프로젝트를 진행하는 것이 있어요. '이렇게 하면 회사와 서비스에 도움이 되겠다. 매출도 좋아질 것 같다. 사람들도 좋아할 것 같다'이런 의견을 내고 직접 만들 수 있고요. 서비스를 같이 진행하는 마케팅팀이나 플랫폼 운영팀에서 요청이 들어오면 그 요청에 대해 저희가 납득하고 하면 좋겠다고 생각하는 업무에 대해서 일정을 짜고 진행해요. 각 요소 별로 개발 측면의 논의도 많이 하고 실제 만드는 사람의 의견이 많이 반영됩니다. Q. 직접 만들고 구축하는 사람들의 의견은 정말 중요한 것 같아요.TECHNOLOGY UNIT을 이끌고 있는 UNIT 장님으로서 KAY의 하루 스케줄은 어떻게 되나요?A. 출근 후, 오전에는 집중 개발 업무를 하고 있어요. 제가 플랫폼 개발 팀장도 겸임하고 있거든요. 오후부터는 대부분 팀미팅이나 프로젝트 미팅을 많이 합니다. 프로젝트의 진행사항을 체크하고, 개발이 어려운 부분과 개발하면서 중요하게 생각하는 부분에 대해서 토론하죠. 그리고 새로운 개발 인력들 채용을 위해 면접을 많이 봅니다.Q. TECHNOLOGY UNIT 내부에서 소통과 역량 강화를 위해 주기적으로 여는 세션이 있다고 들었는데 소개해주세요!A. 일주일에 한 번씩 주니어 개발자를 대상으로 스터디를 진행하고 있습니다. 저는 스터디를 leading 하고 멘토 역할을 하고 있고요.이런 시간을 만들게 된 이유는 소통의 장을 만들고 개발자들의 역량을 키우기 위해서입니다.주니어 개발자들이 시니어 개발자들 앞에서 의견을 내는 것에 대해서 소극적인 면이 있어요. 틀릴까 봐 의견을 쉽게 못 내죠. 그래서 주니어 개발자들끼리 모여서 얘기할 공간을 만들어 주는 것이 중요하다고 생각했어요. 서로 의견을 내고 토론하면서 개발에 대한 역량도 쌓고 의견을 내는 훈련도 할 수 있죠.그리고 DATA UNIT의 협조를 받아서 빅데이터 관련 스터디를 진행하고 있어요. 그래서 개발자들 중 관심 있는 사람이들 모여서 빅데이터 관련 LOGIC을 만들어보고, 아이디어를 실현시켜보는 작은 프로젝트를 그룹별로 진행하고 있어요.앞으로는 이런 세션들을 발전시켜 세미나를 열 예정이에요. 그래서 각 개발자들이 적어도 1년에 2번 이상은 주제 발표할 수 있도록 환경을 만들려고 합니다. 개발 업무는 집중도가 높아서 건조해질 위험이 있어요. 집중하다 보면 일에 치여서 자기계발이 어려워질 수 있기 때문에 계속 자기계발하는 분위기를 만들어가려고 합니다. 전사적으로도 그런 분위기가 계속 만들어지면 좋겠어요.Q. 건조하긴요! 제가 보기엔 개발팀들이 가장 활발하고 참여도도 높은 것 같은데요! 열려있는 분들도 많고요.A. 개발팀이 아닌 팀들이랑 많이 소통하라고 조언을 많이 해요. 미미투게더(2개 이상 팀이 함께 회식하면 회식비를 지원해주는 기업문화 제도)를 할 때도 개발팀 내부에서만 하지 말고 무조건 다른 팀들과 함께하라고 하고 있어요. 새로운 아이디어를 나눌 수 있고 인간관계가 힘이 될 때가 많기 때문에 다른 팀들이랑 얘기를 많이 나누는 게 필요하죠. UNIT2. TECHNOLOGY UNIT을 소개해주세요.Q. TECHNOLOGY UNIT을 소개해주세요.A. TECHNOLOGY UNIT에서는 지금 미미박스에서 서비스하는 모든 PRODUCT, 플랫폼, 모바일 앱, PC 웹, 내부 직원들이 쓰는 모든 것들을 개발하고 있습니다. 대부분의 기업에서는 계약직이나 파견직의 고용형태로 진행하는 경우도 있는데, 저희는 모든 구성원이 정직원으로 개발 업무를 하고 있습니다.Q. TECHNOLOGY UNIT의 분위기는 어떤가요?A. 개발자라는 직무를 하는 사람들은 생각 자체가 자유로워야 합니다. 경직되어있으면 좋은 아이디어가 떠오르지 않죠. 그래서 TECHNOLOGY UNIT은 최소한의 규제나 룰을 두고 자유롭게 활동하게 하고 있어요. 특별한 일이 아니면 회의 소집도 지양하고 있어요.다양하게 상상하려면 경직되지 않고, 룰에 집착하지 않는 문화를 만들어야 하기 때문이에요. 그래야 본인의 의견도 편하게 이야기할 수 있죠. 구성원들을 보면 시니어 개발자들은 적응을 잘해요. 주니어 개발자들이 아직 조금 경직되어있긴 해요.지금 신입 공채 2기를 뽑고 있는데요. 보통은 스타트업에서 입사 후 바로 투입될 수 있는 사람을 뽑아요. 하지만 저는 확신이 있어서 저희 미미박스의 DNA를 가지고 처음부터 함께할 수 있는 신입을 뽑고 싶어요. 미미박스의 DNA를 가지고 더 성장하게 되면 저희 개발 조직에 기둥이 될 수 있을 거라고 생각합니다. <채용공고 보러 가기 클릭>Q. KAY와 함께 하는 구성원들이 점점 부러워지네요. 정말 구성원들의 성장에 많은 비중을 두고 여러 계획을 실천하는 것 같아요. 미미박스에는 여성 개발자도 점점 많아지는 것 같은데 재미있는 에피소드 있나요?A. 먼저 여성 개발자들의 비중이 점점 늘어나고 있어요. 우리가 여성 고객을 위한 서비스를 많이 하고 있잖아요. 그 감성을 같이 공유할 수 있는 사람이 많아지면 기술적인 부분뿐 아니라 감성적인 부분에서도 큰 시너지가 나죠. 실제로 웹페이지에 제품 가격이 잘못 올라간 적이 있어요. 저희 남성 개발자들이 그 데이터를 먼저 보는데 '이게 맞는 가격인가' 의심하는 사람이 아무도 없었어요. 그때 여성 개발자분이 '이 제품이 이 가격이 아닐 텐데? 문제를 제기했고 다행히 수정할 수 있었죠. Q. 그래도 남성 개발자들의 화장품 가격에 대한 감이 점점 정확해질 것 같아요. 호호KAY 님이 UNIT을 운영하시면서 가장 보람을 느끼신 적은 언제인가요?A. 고객들이 많이 와서 저희 서비스를 이용해 주실 때 보람을 느낍니다. 저희 UNIT 자체에서도 무언가를 만들어가고 있다는 것을 느끼고, 실제로 좋은 반응을 얻었을 때 기분이 정말 좋아요. Q. 점점 더 많은 분들이 미미박스를 찾아주신다는 게 느껴져요! 앞으로의 목표는 무엇인가요?A. 첫 번째는 글로벌로 플랫폼을 옮기는 것입니다. 저희 내부에서 개발한 플랫폼과 서비스가 점점 확대돼서 미미박스가 해외에 진출할 때마다 플랫폼을 그대로 이동시켜 글로벌화하는 것이 첫 번째 목표고요. 두 번째는 앞으로 온라인을 넘어 오프라인에 대한 서비스도 진행할 예정이에요. 현재 미미박스 플랫폼과 오프라인 요소의 연계성을 찾고 최고의 고객 경험을 만드는 것이죠. 일반적인 O2O 서비스를 넘어 대부분의 고객이 여성이기 때문에 IT 기술 자체가 숨어있고, 알아서 돌아가게 만드는 서비스를 만들 것입니다.미미박스는 뷰티에 대해서 많은 강점과 다양성을 가지고 있기 때문에 이런 것들을 통해 저희만 할 수 있는 서비스를 만들고 싶어요. 마지막은 Data-driven 방식을 더욱 견고히 가져가는 것이에요. 축적되어있는 경험과 데이터를 통해서 고객 맞춤형 서비스에 대한 역량을 강화하는 것이죠. Q. 글로벌 플랫폼, O2O 서비스, Data-driven 앞으로의 TECHNOLOGY UNIT이 만들어낼 것들이 기대돼요. 두근두근. 마지막으로 KAY가 TECHNOLOGY UNIT을 리드하면서 가장 집중하는 3가지가 무엇인지 궁금합니다. A. 가장 중요한 것은 우리 개발자들의 커리어를 관리해주는 것이에요. 이분들이 미미박스에 와서 자기의 역량이 발전하지 않고 정체되다면 제가 역할을 제대로 못했다는 뜻이거든요.그래서 구성원들이 고생을 하든 뭘 하든 해가 갈수록 성장할 수 있도록 관리하는 것에 집중하고 있어요. 두 번째는 우리가 TECH 조직이기 때문에 서비스가 아주 정상적으로 운영되는 것이 목표에요. 단순한 장애를 없애는 것뿐만 아니라 계속 플랫폼이 발전하면서 문제가 없게 만들어야 하죠. 매출, 데이터가 계속 쌓이면서 안정적인 서비스를 만드는 것, 기본적인 것 같지만 가장 중요한 것 같아요. 마지막으로는 Align이에요. 개발팀이 성장할 수 있는 서비스, 개발 역량을 강화시키다며 보면 회사의 목표에 Align 되는 것을 놓칠 수 있어요. 그렇기 때문에 개발자들이 관심 있는 것들과 회사의 목표를 Align시켜서 시너지 효과를 낼 수 있도록 집중하고 있습니다.UNIT2. TECHNOLOGY UNIT으로서 어떤 사람과 일하고 싶나요?Q. TECHNOLOGY UNIT에서 일하기 위하여 갖추어야 할 역량은 어떤 것이 있나요?A. 첫 번째로 성장 가능성을 봅니다. 성장 가능성에는 여러 가지 의미가 있지만 적극적이고, 새로운 지식에 대한 욕구가 항상 강한 사람이어야 합니다. 배우고 싶은 열망, 해보고 싶다는 열망을 가지고 실제 구체적으로 실행해본 경험이 있고, 뭔가를 해본 사람이 성장 가능성이 있는 사람이라고 생각합니다. 제가 면접을 볼 때마다 항상 물어보는 것이 '5년 후 계획, 5년 후 모습은 어떨 것 같아요?'에요. 면접자가 적극적으로 대답하면 '그것을 위해 어떤 실행계획이 있는지' 물어보죠.두 번째로는 스타트업 마인드 FIT이 맞는 것이에요. 저도 미미박스에 처음 왔을 때 힘들었어요. 갖춰져 있는 게 없었거든요. 하나부터 열까지 하려면 뭔가 어디서 걸리는 거예요. 큰 회사는 세팅이 다 되어있는데 말이죠. 그래서 뭔가를 하려면 그 업무뿐 아니라 처음부터 다 찾고 만들어야 해요. 이렇게 만들어가는 걸 좋아하는 사람이 있어요. 준비가 안되어있다고 불평하는 것이 아니라 부족한 환경에서 할 거리가 많은 것을 반기는 사람들. 이런 사람들은 '이것저것 해봐야지~' 신나있어요. 이런 마인드 FIT을 많이 봅니다.Q. 스타트업 마인드 FIT 정말 공간되는 말인 것 같아요. 저도 갖춰져있는 틀에서 무언가를 하는 것보다 이것저것 찾아서 만드는 걸 좋아하거든요! 그런 분들이 많이 오시면 재밌는 일이 많이 벌어질 것 같아요. 우리 미미박스의 비전은 'Beautify the people'인데요. 혹시 취업이나 이직을 준비하는 분들께 이것만은 아름답게 관리하라고 조언하고 싶은 게 있나요?A. 이력서와 경력기술서를 아름답게 해야 해요. 개발자들 중에 '내 역량만 좋으면 되지'라고 생각하시는 분들이 있는데 자신의 커리어 패스를 만드는 것도 중요하거든요. 회사에서 처음에 서류전형을 진행하는 게 많은 내용을 내포하고 있어요. 경력기술서의 내용이 부실하면 회사도 본인도 FIT이 맞는 곳을 찾기가 어려워지죠. 어디서든 인정받는 사람이 되려면 자신의 업무와 역할을 충실하게 표현한 경력기술서를 작성하라고 말씀드리고 싶네요.Q. 정말 실질적인 조언이네요. 누구보다 깊게 고민하고 집중한 일일수록 경력기술서와 이력서를 잘 쓸 수 있고 자신의 경력도 잘 전달할 수 있을 것 같아요.마지막으로 함께 일하고 있는 미미박서분들께도 한마디 해주세요!A. 제가 여기 처음 와서 한 이야기가 있어요. "여기가 제 마지막 회사입니다."그렇게 이야기한 이유는 미미박스의 성장 가능성, 발전 가능성을 보았고 믿음이 있기 때문이죠. 모두가 같이 노력한다면 원하는 것을 이룰 수 있을 거라 생각해요. 다 같이 파이팅!

기업문화 엿볼 때, 더팀스

로그인

/