스토리 홈

인터뷰

피드

뉴스

조회수 1640

Java의 json 라이브러리 google-gson

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

Next.js 튜토리얼 8편: 컴포넌트 스타일링

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기 2편: 페이지 이동 3편: 공유 컴포넌트4편: 동적 페이지 5편: 라우트 마스킹6편: 서버 사이드 7편: 데이터 가져오기 8편: 컴포넌트 스타일링 - 현재 글9편: 배포하기개요지금까지 컴포넌트를 스타일링 하는 것을 미뤄왔습니다. 그러나 이제는 몇 가지 스타일을 적용해볼만 합니다.React 애플리케이션에는 컴포넌트를 스타일링 할 수 있는 여러가지 기술들이 있습니다. 크게 두 가지 방법으로 분류할 수 있습니다:1. 전통적인 CSS 파일 기반의 스타일링 (SASS, PostCSS 등)2. CSS in Js 스타일링 결과적으로 전통적인 CSS 파일 기반의 스타일링(특히 SSR)은 실용적인 문제가 많아 Next.js에서 스타일을 지정할 때는 이 방법을 사용하지 않는 것이 좋습니다. 대신 CSS in JS 방법을 추천합니다. 이 방법은 CSS 파일들을 불러오는 것보다 개별적인 컴포넌트 스타일링 할 때 사용 할 수 있습니다.Next.js는 styled-jsx라는 CSS in JS 프레임워크를 미리 설치해두었습니다. 컴포넌트에 이미 익숙한 CSS를 작성할 수 있습니다. 이 CSS는 해당 컴포넌트에만 적용되며 심지어 하위 컴포넌트에도 적용되지 않습니다.이는 CSS가 범위가 있음을 뜻합니다.styled-jsx를 어떻게 사용할 수 있는지 살펴봅시다.설치이번 장에서는 간단한 Next.js 애플리케이션이 필요합니다. 다음의 샘플 애플리케이션을 다운받아주세요:아래의 명령어로 실행시킬 수 있습니다:이제 http://localhost:3000로 이동하여 애플리케이션에 접근할 수 있습니다.home 페이지 스타일링하기home 페이지(pages/index.js)에 스타일을 추가해봅시다.간단히 pages/index.js를 다음과 같이 변경해주세요:   <style jsx> 엘리먼트를 살펴봅시다. 이것은 CSS를 작성하는 곳입니다.코드를 바꾼 후 블로그 home 페이지는 다음과 같이 보일 것입니다:위의 코드에서 스타일 태그 안에 직접 스타일을 작성하지 않고 템플릿 문자열 안에 작성하였습니다.템플릿 문자열({``}) 없이 직접 CSS를 작성해봅시다:어떤 일이 일어날까요?- 아무 일도 일어나지 않는다.- 새로운 스타일이 적용된다.- "문법 에러: 기대되지 않는 토큰"이라는 에러가 발생한다.- "허용되지 않는 스타일 제공자"라는 에러가 발생한다.스타일은 템플릿 문자열 안에 위치해야 합니다styled-jsx는 babel 플러그인을 통해 동작합니다. babel 플러그인은 빌드 과정에서 모든 CSS를 분해하고 적용합니다. (스타일이 추가 시간 없이 적용됩니다)styled-jsx 내에 제약 조건을 제공합니다. 나중에 styled-jsx 안에 동적 변수를 사용할 수 있습니다. 이것이 스타일을 템플릿 문자열 ({``}) 안에 작성해야하는 이유입니다.스타일과 중첩된 컴포넌트home 페이지에 작은 변화를 만들어봅시다. 다음과 같이 링크 컴포넌트를 분리시켰습니다:    import Layout from '../components/MyLayout.js'   pages/index.js 안의 내용을 위와 같이 수정해봅시다.무슨 일이 일어나나요?- 아무런 일도 일어나지 않는다.- 링크가 아닌 h1만 스타일이 적용된다.- 페이지에 에러가 발생한다.- 콘솔에 에러가 발생한다.중첩된 컴포넌트에는 적용되지 않습니다위의 코드를 실행하면 다음과 같이 보입니다:보다시피 CSS는 하위 컴포넌트 내부의 엘리멘트에는 적용되지 않습니다.styled-jsx의 특징은 더 큰 애플리케이션에서 스타일들을 관리할 때 도움이 됩니다.이 경우에는 하위 컴포넌트에 직접 스타일을 적용해야 합니다. 지금 상황에서는 링크 컴포넌트에 직접 스타일을 적용해야 합니다:다른 방법로는 global selectors을 사용할 수 있습니다.전역 스타일때때로 하위 컴포넌트 안의 스타일을 바꿔야 합니다. 일례로 React에서 마크다운을 사용하는 경우가 있습니다. post 페이지(pages/post.js)에서 볼 수 있습니다.post 페이지는 전역 스타일이 유용하게 쓰일 수 있는 곳입니다. styled-jsx를 사용하여 몇 가지 전역 스타일을 추가해봅시다. pages/post.js에 다음과 같은 내용을 적용해주세요.다음 내용을 적용하기 전에 npm install --save react-markdown 명령어를 통해 react-markdown 컴포넌트를 설치해주세요. 무슨 일이 일어나나요?- 아무런 일도 일어나지 않는다.- 마크다운 컨텐츠에 스타일이 적용된다.- 페이지에 에러가 발생한다.- 콘솔에 에러가 발생한다.전역 스타일이 동작합니다전역적으로 스타일이 적용되므로 잘 동작합니다.이 기능은 매우 유용할 수 있지만 항상 전역 prop 없이 스타일을 작성하길 추천합니다.여전히 일반적인 스타일 태그보다 좋은 방법입니다. styled-jsx를 사용하면 필요한 모든 접두사와 CSS 유효성 검사가 babel 플러그인 내부에서 수행되어 추가적인 런타임 오버헤드가 없습니다.다음엔 무엇을 해야할까요이 편에서는 styled-jsx의 표면만 다루었습니다. 더 많은 것들을 할 수 있습니다. styled-jsx Github 저장소에서 더 많은 내용을 참고하세요.Next.js에서 꽤나 괜찮은 다른 스타일링 방법들이 있습니다. 이 부분도 같이 참고해주세요.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유
조회수 4866

신입 개발자를 위한 코드의 정석

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

타운어스 신규플랫폼을 오픈하며

안녕하세요. 타운컴퍼니 R&D 파트의 백대현입니다.타운컴퍼니는 단체들를 위한 공동구매 플랫폼인 타운어스를 운영하는 스타트업입니다. 기술블로그를 시작하며 최근 오픈한 타운어스 2.0에 대한 소개, 타운컴퍼니 기술조직인 R&D 파트에 대한 소개를 드리려 합니다.타운어스는 대학생들이 학교 내에서 자주 진행하는 공동구매가 굉장히 복잡하고 만족하기 어렵다는 문제를 해결하기 위해 시작되었습니다. 수작업으로 진행하던 공동구매를 플랫폼화 시켜 편하게 공동구매를 진행할 수 있게 만들고, 전국단위로 공동구매를 진행하여 최저가로 구매할 수 있도록 하였습니다.2014년 9월 오픈베타서비스인 캠퍼스샵을 시작하였고 이어서 2015년 6월 정식서비스 타운어스를 런칭하여 2년 넘게 폭발적으로 성장해왔습니다.사실 그 동안 타운어스 사이트에 대한 아쉬움이 많았습니다. 사이트가 초기에 린(Lean)하게 만들어진 이후에 몇차례 업데이트를 거쳐 타운어스 비즈니스를 받쳐주고 있었지만 내부 개발팀의 부재, 인력부족으로 유지보수가 잘 되지 않고 있었습니다. 그 와중에 몇 차례의 비즈니스 전략 변경(Pivot)을 거치면서 기술과 비즈니스의 괴리가 점점 벌어지게 되었습니다.타운어스 신규플랫폼타운컴퍼니에서는 여러 고민을 거쳐 한층 업그레이드 된, 이제 대학생 뿐만 아니라 모든 단체를 위한 공동구매 커머스 플랫폼으로 거듭나고자 타운어스 2.0 프로젝트를 시작하며 기획팀, 디자인팀, 개발팀으로 이루어진 R&D 파트를 출범하고 기술조직을 구성하였습니다.새로 출범한 타운컴퍼니 R&D 파트에서는 물려받은 기존 코드베이스를 유지하며 플랫폼을 개선할 것인지, 부채를 청산하고 새로운 코드베이스를 쌓을 것인지 많은 고민을 했습니다. 결론적으로 새로운 코드베이스로 프로젝트를 진행하기로 하였는데 대표적인 이유는 아래와 같았습니다.타운어스 2.0에서 변경되어야할 기획이 상당히 많아 재설계가 필요함비즈니스적 전략 변경을 서비스에 반영하기 위해 변경해야할 기획이 상당히 많고 그 동안 기술에 반영되지 않은 비즈니스 요구사항이 많아 여려 요구사항이 복합적으로 고려되어야함서비스 아키텍처가 연속성이 없음초기에 MVP로 시작된 코드베이스가 연속적인 기술조직이 발전시키지 못하고 외주 개발과 인력 변경을 거치다 보니 일관적이지 않고 누수가 많음버그 빚더미인력부족으로 인해 그 동안 유지보수가 되지 않아 해결해야할 버그가 복합적으로 존재함 (해결되지 않은 리포팅된 이슈 450여개 OMG)위 외의 여러 이유로 타운컴퍼니 R&D 파트에서는 기술부채 파산을 선택하고, 새로운 코드베이스에서 프로젝트를 시작하기로 하였습니다.신규플랫폼 간략 소개결론적으로 타운어스 신규플랫폼은 전체적인 일정과 인력을 고려하여 우선 부분적으로 오픈하게 되었습니다. 가장 많은 사용자들이 사용하는 단체의류공동구매에 대한 서비스를 먼저 개발하게 되었고 그 외 카테고리의 공동구매는 기존플랫폼에서 서비스하고 있습니다.이렇게 시작한 타운어스 신규플랫폼의 현재 오픈한 변경 사항은 크게 아래와 같습니다.전체적인 UX/UI 업데이트공동구매를 더 편하게 시작하고 진행하고 마무리할 수 있도록 개선“공동구매방”을 친숙하게 사용할 수 있도록 유도하였습니다.단체의류 커스터마이징 기능 강화커스터마이징 의류 종류 확장 : 과잠, 코치자켓, 티셔츠 (점진적으로 확대할 예정)커스터마이징 예상가격 계산 기능편하게 단체의류 디자인을 미리 해볼 수 있는 서비스를 제공합니다.최근 오픈을 시작으로 타운컴퍼니 R&D 파트에서는 지속적으로 서비스를 발전시켜 세상 모든 단체활동을 위한 공동구매, 타운어스에 걸맞는 공동구매 커머스 플랫폼으로 만들어갈 예정입니다.기술 스택과 조직 문화타운컴퍼니 R&D 파트의 기술에 대해서는 꾸준히 소개를 드리려 합니다. 때문에 오늘은 조직 문화와 기술 스택에 대해서 간단하게 소개를 드리겠습니다.프로젝트 진행협업툴로 JIRA, Confluence, Slack을 사용하고 있습니다.프로젝트는 Agile Kanban 방식으로 테스트 주도 개발, 코드 리뷰, 페어프로그래밍을 통해 진행하고 있습니다.서비스에 대한 충분한 고민 이후에 개발을 진행하려 노력합니다.기술 스택Back-End는 Django 1.11 (DRF) 기반으로 개발하며, AWS, MySQL, Vagrant, Docker 같은 기술을 사용하고 있습니다.Front-End는 Angular 5.1을 사용해서 개발하고 있으며 Less, RxJS, Webpack 등의 기술을 사용하고 있습니다.UX/UI에 Sketch와 Zeplin을 주로 사용하고 있습니다.CI(Continuous Integration)로 Travis-CI, 배포 관리로 Fabric과 AWS CLI, 버그 리포팅으로 Sentry.io, 플랫폼 모니터링으로 ELK(ElasticSearch, Logstash, Kibana)를 사용하고 있습니다.지향하는 조직 문화 및 지원자유롭고 주도적인 조직 환경시간에 쫓겨 비루한 코드를 생산하지 않도록유연한 리모트 근무지시가 아니라 스스로 할 일을 찾는 자율 속에서 책임을 다하는 문화자유롭게 의견을 제시할 수 있는 편한 분위기건강한 비판과 토론을 장려하는 커뮤니케이션 문화이상을 추구하되 비즈니스에 기반한이상적인 기획, 디자인, 개발을 지향하지만 비즈니스 영역에 기반한 의사결정회사 모든 조직들이 더 부가가치가 높은 업무에 집중할 수 있는 환경 조성을 위해 노력TOY TIME매주 금요일 4시부터 7시까지 3시간 자유로운 주제로 프로젝트 진행세미나, 컨퍼런스 참가 적극 장려 및 도서 지원저희는 아직 성장하고 있는 만큼 개선할 점도 많고 배워야하는 부분도 많이 있습니다. 그 만큼 기술블로그를 통해 저희가 고민하고 겪었던 기술을 공유하고 소통하며 서로 성장할 수 있는 기회가 되었으면 합니다.잘 부탁드립니다.#타운컴퍼니 #서비스소개 #기업문화 #사내복지 #조직문화 #원격근무 #디지털노마드 #재택근무
조회수 1715

[QP크루의 항해일지] 해적선에 탄 신입 디자이너의 적응기

안녕하세요. 콘텐츠 지부 김현수입니다. 저는 4월에 해적선에 승선해서 열심히 항해하고 있는 디자이너입니다. 사실 QP에 첫 번째로 입사한 디자이너이기 때문에 어렵고 힘든 일도 있지만 그만큼 파란만장하고 재미있는 디자인 작업들을 해보고 있습니다. QP에서 진행한 크고 작은 작업들을 하나씩 소개해드리면서 공유해보고 싶었던 점들을 이야기해보려고 합니다.QP에 처음 승선한 디자이너였기 때문에 말하는 대로 이루어지고 곧바로 QP의 비주얼 아이덴티티가 돼버리는(!) 즐겁고도 책임감이 느껴지는 작업들을 해볼 수 있었습니다. 저의 제일 첫 번째 프로젝트였던 QP의 로고 만들기, 신입 크루들을 위한 웰컴키트와 스티커 제작, QP의 A부터 Z까지 담은 해적단 입문서 편찬까지 찬찬히 풀어보겠습니다.STEP 01. QP 로고 제작하기QP의 시각적 정체성을 확립하는 첫 번째 과정은 로고 제작하기였습니다. 로고는 외부에 우리를 알리는 역할을 하기도 하지만 내부 크루들의 회사에 대한 생각을 담고 소속감을 다지게 만듭니다. 그래서 로고를 제작하기 전, 크루들의 의견을 들어보기로 했습니다. 크루들은 퀀텀파이러츠의 로고에 어떤 이미지가 담겼으면 좋겠을지 자유롭게 남긴 의견들을 살펴볼까요?크루들이 주신 소중한 의견들적극적으로 의견을 전달해 주신 크루들 덕분에 디자인을 시작하는 데에 큰 도움이 될 수 있었습니다. QP 해적선이 찾고 싶은 보물 상자, 해적선을 상징하는 깃발, 배 등 다양한 답변과 이미지들이 나왔지만 여기서 일맥상통하는 지점을 찾아 힌트를 얻을 수 있었습니다. 이 힌트를 바탕으로 키워드 몇 가지를 정해 방향성을 가지고 디자인 시안을 제작해 보고자 했습니다. 첫 번째 키워드는 '해적선'입니다. 우리가 그저 표류하는 것이 아닌 거침없이 나아감을 보여줄 수 있는 해적선을 키워드로 선정했습니다. 두 번째는 '항해'입니다. QP의 해적선이 항해하는 모습이 저희의 심볼에도 표현되었으면 한다는 크루들의 의견들을 참고했습니다. 세 번째 키워드는 '방향'입니다. 어딘가로 나아가고 있는 우리의 방향성을 보여주고자 했습니다.그럼 이제 제작했던 시안들을 보여드릴게요!최종 시안을 결정하기 전까지 나온 다양한 시안들시안을 제작할 때는 틈틈이 오며 가며 크루들이 던진 시각적 모티브가 로고를 발전시키는 데에 도움이 될 수 있었습니다. 키워드에도 등장했던 해적선, 그리고 바다, 키 등 다양한 아이디어로 시안들이 완성될 수 있었습니다. 이 중에서 선정된 로고는 다음 나오는 친구입니다.최종 결정된 QP의 로고저희의 항해하는 모습과 길을 상징화했다는 의견으로 채택된 로고입니다. 로고라는 것이 아이덴티티의 시작이 되는 만큼 글에는 압축되었지만 긴 고민의 시간을 담아 완성이 되었습니다. 어떻게 보면 로고가 앞으로의 디자인 작업에서 전면으로 크게 등장하지는 않겠지만 어느 한 켠에서 우리를 알리며 존재감을 내뿜기를 바라며 마무리했습니다.+번외 이야기. QP의 롤링페이퍼입사한지 2일차 날의 이야기입니다. 갑자기 용희님이 급한 일이 있다며 저를 소환하셨습니다. 심각한 얼굴로 전한 이야기는.. 내일이 바로 세정님의 생일이라는 것이었습니다. 생일맞이 롤링페이퍼를 제작해서 전달하자는 것이었는데 이미 퇴근시간이 얼마 남지 않은 시간이었습니다. 15분 안에 롤링페이퍼를 완성해야 하는 미션이 주어진 것이죠. (용희님은 이때 "앞으로는 이렇게 데드라인이 급한 일을 전달하지 않겠다"라고 약속하셨죠.) 이렇게 만들어진 제작된 롤링페이퍼는 무사히 세정님께 전달될 수 있었고 QP의 작은 문화가 되었습니다.QP의 크고 작은 모든 이벤트들에는 롤링페이퍼가 함께 합니다.생일을 맞이하여 기쁜 QP의 아이돌 소영님STEP 02. 스티커와 웰컴키트 제작하기로고를 제작한 후 가장 손쉽게 만들 수 있는 굿즈를 먼저 제작해 웰컴키트를 구성해보기로 하였습니다. 그렇게 제작하게 된 것이 스티커입니다. 웰컴키트를 꾸밀 수 있는 타이포그래피 스티커와 로고 심볼 스티커를 제작해 회사 곳곳에 사용하기로 결정했습니다. 로고를 제작하면서 파란색이 QP의 키 컬러로 결정된 만큼 굿즈 제작에도 적극 활용해 디자인했습니다.QP의 스티커 시안들다양한 용도로 쓰일 수 있도록 3가지 시안으로 디자인을 마무리해 스티커를 제작했습니다. 제작한 후에 배포하고 실제 사용되고 있는 모습을 보니 회사 브랜딩에 작은 한 발자국을 내디딘 기분이었습니다. 또한 내부적으로도 자연스럽게 소속감을 높일 수 있게 되는 계기가 되기도 했습니다. 비록 작은 스티커로 시작했지만 이러한 굿즈가 쌓이다 보면 내부에서부터 단단하게 쌓을 브랜딩에 일환이 될 수 있겠다는 생각을 얻게 된 프로젝트였습니다.스티커를 활용하는 예스티커를 제작한 후 웰컴키트도 제작을 시작했습니다. 웰컴키트에는 우선 앞서 제작했던 스티커가 들어갑니다. 그리고 크루들이 신입 크루를 위한 환영의 말을 적은 롤링페이퍼가 들어가죠. 신입 크루들이 회사생활에 필요한 사무용품, 슬리퍼 등 필수품들 또한 준비합니다. 마지막으로 쿠폰이 들어갑니다. 살짝만 보여드리자면 점심 식대를 초과해서 지원해주는 "오늘 점심 주인공은 나야 나"쿠폰, 아직 궁금한 것이 많은 신입 크루들을 위한 "모든 바쁜 일은 제쳐두고 내 질문에 답해줘"쿠폰 등이 있습니다. 아직은 어색할 신입 크루들이 자연스럽게 크루들과 친해질 계기를 만들어 해적 생활에 적응할 수 있게 도와주죠. 신입 크루를 위한 웰컴키트STEP 03. 해적단 입문서 편찬하기웰컴키트를 제작하면서 신입 크루에게 전달할 입단 과정부터 근무에 필요한 모든 것을 적은 해적단 입문서의 필요성을 느끼게 되었습니다. 필요한 내용을 정리해 4개의 단원과 2개의 별책부록으로 나누어 편집했습니다. 2개의 별책부록은 QP에 간식이나 쉴 수 있는 곳을 소개하는 보물지도와 크루들의 자기소개가 담긴 크루 소개 페이지로 이루어져 있습니다. 이후에 내용은 주제에 따라 4단원으로 나누어져 있습니다. 첫 번째 단원은 <해적단 입단 심사>로 입사서류나 계정 생성등 입사 후 첫 번째로 해야 하는 필수 과정들에 대해 안내하고 있습니다. 두 번째 단원은 "해적 장비 안내"로 QP에서 사용하고 있는 툴들을 소개하고 어떻게 사용하는지 간략히 알려주는 단원입니다. 세 번째 단원은 "같이의 가치"파트입니다. 휴가를 어떻게 쓰는지부터 QP 크루들이 점심을 먹는 법까지 QP의 복지에 대해 소개하는 단원입니다. 마지막 단원은 해적 꿀팁으로 회의실 예약 방법이나 WIFI 정보 등 소소한 팁들을 안내하고 있습니다.입문서를 디자인할 때에는 처음부터 확실한 콘셉트를 가지고 있었습니다. 마치 해적들의 양피지를 펼쳐보는 듯한 책을 만들자는 방향으로 시작했습니다. 여타의 입사 가이드처럼 딱딱한 형식보다는 친근감 있고 재미있게 필수 정보들을 전달하자는 기획을 가지고 텍스트 작업과 디자인을 진행했습니다.해적단 입문서 내부를 살짝 보여드립니다!계속해서 키 컬러로 사용하고 있는 파란색을 포인트로 양피지 질감의 배경으로 콘셉트에 부합하는 비주얼을 만들었습니다. 다만 텍스트 양이 많다는 특성상 내지는 깔끔하게 흰 배경으로 작업을 진행했습니다. 완성된 입문서는 PDF로 새로 입사할 크루들에게 안내 메일로 배포되고 있습니다. 입사하기전 해적단 입문서를 읽으며 QP에 대한 낯섦을 조금 해소할 수 있기를 바라며 애정을 가지고 디자인 작업을 진행했는데요, 입문서를 제작하면서 저 또한 QP에 대해서 알았던 것을 정리하고 몰랐던 것을 새롭게 알아가는 시간이었습니다. QP_디자이너의_자리.jpg승선하고 처음 맡았던 작업들이 QP의 브랜딩에 관한 것이었기 때문에 디자이너로서는 책임감이 크게 느껴졌었습니다. 하지만 로고부터 시작해 회사의 아이덴티티를 다지는 작업을 하고 나니 회사 내부의 가치를 올리는 데에 일조한 것 같아 보람을 느낄 수 있었습니다. 또한 이번에 했던 프로젝트들이 회사의 문화와도 맞닿아 있는 부분이 많았기에 많은 크루들의 기대와 관심 속에 완성되었는데요, 그만큼 의견을 존중해주고 관심을 가져주는 크루들이 있었기 때문에 오히려 자유롭고 즐겁게 작업을 해볼 수 있었습니다. 이 모든 프로젝트를 함께 해주신 세정님께 특별한 감사드리며 해적단 입문서에 내용을 작성하시느라 고생하신 경모님께도 감사드립니다. 앞으로도 항해일지는 계속 이어질 예정이니 어떤 크루가 적어주실지 많이 기대 부탁드립니다!QP 크루들은 앞으로도 더 멋진 항해를 하기 위해 함께 노력하고 성장하고 있습니다. 현재 퀀텀파이러츠는 퍼포먼스 마케터, 검색광고마케터, 웹 개발자 직무의 크루를 기다리고 있습니다. QP 해적선에 승선해 함께 하고 싶다면 아래의 링크를 참고해주세요!https://blog.naver.com/haejeok_kwon/221566691682
조회수 1669

애플, 화제의 프로그래밍 언어 Swift 공개

안녕하세요. 크몽 개발팀 입니다!   지난주에는 개발하기 전 개발환경 셋팅에 필요한 개발도구들을 소개해 드렸습니다.그러나 개발환경을 셋팅하기 전에 먼저 결정해야 할 것이 있습니다.바로 어떤 프로그래밍 언어로 개발을 할것인가 하는 문제 인데요~언어의 종류가 많고 사용하는 언어마다 특성이조금씩 다르기 때문에 결정하는 것이 어려울 때가 많습니다. 오늘은 다양한 종류의 언어 중에서 요즘 개발자 분들사이에서 화제가 되고 있는 'Swift(스위프트)'라는 언어를 소개해보려고 합니다.    2014년 6월 2일 미국 샌프란시스코 모스콘웨스트컨벤션센터에서 열린애플 WWDC(WorldWide Developers Conference)에서발표 마지막에 새로운 프로그래밍 언어 'Swift(스위프트)'를 공개했습니다.Swift는 C와 Objective-C의 중간에 있는 언어로서iOS와 OS X 기반의 애플리케이션 개발을 위한 언어입니다. 간단하게 장점들을 말씀드리면 고성능 앱을 개발 하기 위하여LLVM의 발전된 코드 분석기를 이용해 컴파일과 최적화를 수행합니다. 이 결과 Python 기준으로 오브젝트 정렬 속도는 3.9배,RC4 인크립션 처리속도는 220배나 빠른 처리속도를 가지고 있습니다. 그리고 현대적인 언어에서 지원하는 주요 기능들을 대거 흡수하고,Cocoa 및 Cocoa Touch frameworks의 모든 부분에서 접근이 가능합니다.또한 C와 Objective-C에서 써오던 기존 방식 또한 그대로 도입할 수있기 때문에 기존에 개발하던 업무에 지장을 주지 않습니다.   마지막으로  읽고 쓰기 쉬운 문법으로 코드를 작성하기 때문에유시보수 시 적은 양의 코드가 사용됩니다.그리고 소스를 코딩한 후 그 결과를 실시간으로 볼 수 있습니다. [출처] 애플 스위프트 언어 (Swift) - 앱 개발을 위한 애플의 새로운 언어|작성자 마스터 현재 9월에 애플에서 Swift 정식버전이 출시 되었고Swift로 작성된 애플리케이션의 iOS 앱스토어 승인도 시작되었습니다.또한 Xcode 6 시험판을 내려받아서 사용할수 있고,iTunes Store와 App Store를 통해 Swift 프로그래밍 언어 전자책을 다운받을 수 있다고 합니다.  개발된지 오래 되지 않아서 아직 Objective-C를 함께 사용하고있지만 쉽게 접근할 수 있는 언어이기 때문에점점 Swift를 사용하는 개발자 분들이 많아질 것으로 보입니다 ^^ 이상 포스트를 마치겠습니다. #크몽 #개발팀 #신입개발자 #신입사원 #경험공유
조회수 2627

[인공지능 in IT] 네가 내 마음을 알아?

지난 2018년 3월, 고용노동부는 10월부터 발효되는 '감정노동자 보호법 개정안'을 통과시켰다. 해당 개정안은 고객의 폭언이나 폭력으로부터 스트레스를 받는 감정노동자의 인권과 업무의 질을 개선시킬 사업주 조치를 의무화하는 내용을 담고 있다. 감정노동이란, 고객을 응대하며 자신의 본래 감정과는 상관없이, 업무상 정해진 감정 표현을 연기하는 것을 일상적으로 수행하는 노동을 말한다. 예로 콜센터, 백화점 안내, 텔레마케터 등이 있다.< 감정노동자 보호를 위한 5개 금융업법 개정안 주요 내용, 출처: 동아닷컴 >이제 정부는 감정노동자의 '적응 장애'와 '우울증' 등을 업무상 질병으로 인정한다. 세계보건기구(WHO)에서 정의한 건강은 '육체적, 정신적, 사회적, 영적으로 안녕한 상태'다. 즉, 감정노동자들은 육체뿐만 아니라 정신적, 사회적으로 고통받을 수 있다는 것이다. 그들은 자동으로 저장된 말을 내뱉는 음성 안내기가 아니고, 일반 사람들처럼 똑같이 울고 웃는 사람이다. 그렇지만, 아직까지 국내에서 심리상담에 대한 정서적인 장벽은 높고, 상담 받을 수 있는 인프라도 잘 갖춰지지 않다. 감정노동자들이 실질적인 상담 도움을 받기는 어렵다는 의미다.감정노동 소식 뒤, 국내 인공지능 기술 업체 중 한 곳이 심리상담 서비스를 출시했다는 기사를 접했다. 전문 심리 상담사들이 축적한 수많은 상담 시나리오 데이터를 수집하고 구축해, 개별적이고 정확한 서비스를 제공한다는 것이 취지다. 또한, 통화 목소리를 기반으로 이를 감정 데이터로 변환시켜 정신 건강에 대한 정보와 스트레스 관리 등을 위한 맞춤형 콘텐츠를 제공하는 것이 목적이다. 정확도는 알 수 없지만, 인공지능이 인간의 감정을 인지하고 생활에 도움을 줄 수 있다는 사실만으로도 큰 의미가 있다고 생각한다.사실 필자는 몇 년 전까지 매 순간 변하는 복잡한 인간의 감정은, 인간 고유의 것이라고 생각했다. 인간은 자신의 감정을 알지 못할 때도 있고, 긍정적인 감정과 부정적인 감정을 주체하지 못하기도 한다. 아직 우리 스스로 감정에 대해 확실하게 정의할 수 없고, 통제할 수 없다. 하지만, 그럼에도 불구하고, (앞서 언급한) 심리상담 서비스처럼 여러 분야에서 기계가 인간의 감정을 이해하고, 심지어 감정 표현을 돕는 연구는 거듭되고 있다.기계와 감정의 접목은 2000년대 이전부터 시작되었다. 1995년 MIT의 피카드(Rosalind Picard) 박사가 처음으로 감성컴퓨팅이라는 용어를 사용하며, 인간의 감성을 분석하고 해석하는 기술 개발을 시작했다. 감성 컴퓨팅은 인간이 느끼는 바를 인지, 해석, 처리할 수 있는 시스템을 설계하기 위한 인공지능 기술을 연구하고 개발하는 분야다. 감정 인식은 상상 이상으로 복잡하고, 아직까지 정확하게 구현하기 힘든 어려운 기술이지만, 조금씩 그 영역을 확장하며 다양한 분야에서 사용되고 있다.아무래도 사람의 감정을 드러내는 표면적인 수단 중 가장 눈에 띄는 것이 표정일 것이다. 얼굴에 드러나는 인간의 감정은 안면 근육의 움직임을 통해 여러 표정으로 나타나기 때문이다. 여기에 영상 처리 기술을 활용하면, 기계가 인간의 감정을 분류할 수 있다. 이를 기반으로 한 감정인식은 다음의 과정으로 이루어진다.먼저 영상이나 이미지 안에서 얼굴 영역을 찾는다. 일반적으로 스마트폰 카메라 앱에서 많이 볼 수 있듯, 네모 박스 형태로 얼굴을 인식한다. 그리고 해당 박스 안에서 눈, 코, 입 등 랜드마크라고 불리는 특징점들을 찾는다. 이어서 각 특징점을 바탕으로 각각의 위치나 배치를 파악하는 프로세스를 거친다. 마지막으로 학습을 거쳐 사람의 표정을 인식할 수 있다.일반적으로 감정 쪽을 연구하고 기술을 개발하는 업체 대다수는 이러한 딥러닝 방식을 적용한다. 그리고 미리 지정한 각각의 감정 메트릭에 사용자의 표정을 맵핑하는 식으로 결과값을 도출한다. 하나 주의해야 할 점은 표정과 비교하는 감정이라는 결과값을 '확률(%)'로 산출한다. 예를 들어, 눈썹을 찌푸리고 눈이 커지면서 입을 벌리고 있으면, 감정은 '화남 95%, 놀람 20%, 슬픔 5%...' 등으로 표현하는 방식이다.< EMOTION>이외에도 톤, 크기, 템포 등 감정 변화에 따라 변하는 목소리를 분석하는 음성 인식 기술이나 몸의 특정 움직임을 분석해 감정 상태를 인지하는 동작 인식 기술 등이 있다. 특히, 음성 인식은 CS(고객 응대) 영역에서 빛을 발할 수 있다. 실시간으로 고객의 감정을 분석해 소통방식을 바꾸거나, 그들의 구매 패턴을 예측하는 데 도움을 준다.최근에는 페퍼를 비롯한 가정용 휴머노이드 로봇이 여럿 출시되면서, 감정인식 기술의 적용사례를 쉽게 찾아볼 수 있다. 이들 로봇들은 인간과 대화할 때 억양이나 표정을 인식하며, 심지어 때로는 인간의 감정을 예측하고 묻기도 한다. 물론, 아직까지 우리의 머리 속에는 기계라는 생각 때문에 상호간 자연스러운 대화나 감정을 전달하기 어렵다. 하지만 문자, 음성, 시각 등 현재도 여러 영역에서 인공지능 기술은 발전을 거듭하고 있다.< 핸슨로보틱스(hansonrobotics)의 휴머노이드 로봇 소피아(Sopjia), 출처: 핸슨로보틱스 >인간의 감정이라는 것은 하나의 영적인 매개체가 아닌, 복합적인 것이다. 결국 각 영역별 인공지능 기술이 고도화될수록 감정 인식에 적용할 수 있는 기술 또한 정교해진다는 것을 의미한다. 언젠가는 기계가 인간의 말상대가 되어주고, 함께 어려운 문제에 대해 의논할 수 있는 단계까지 이르지 않을까? 감정 노동자의 마음을 어르고 달래는 로봇이 등장할지도 모를 일이다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업
조회수 2560

타다 시스템 아키텍처 - VCNC Engineering Blog

2018년에는 VCNC에 큰 변화가 있었습니다. 오랫동안 비트윈 기반의 서비스들을 개발하고 운영했지만 2018년 10월에 기사 포함 렌터카 서비스를 포함한 종합 모빌리티 플랫폼인 타다를 기획하고 출시하였습니다. 변화가 많은 모빌리티 시장에서 신규 서비스를 성공적으로 출시하기 위해 많은 고민을 하였습니다. 이번 글에서는 타다의 시스템 구성과 이를 위해 사용한 여러 기술을 소개하면서, 타다 개발팀의 기술적 결정을 공유해보고자 합니다.타다에서 사용하는 기술들의 로고. 왼쪽부터 Kotlin, Spring Boot, Kubernetes, Terraform, gRPC, Redis.기존과 다른 선택비트윈의 경우 Netty를 이용해 인하우스 네트워크 라이브러리를 만들기도 하였고, 메인 데이터베이스로 NoSQL인 HBase를 사용하는 등 남들이 통상적으로 사용하지 않는 기술 스택을 선택한 경우가 많았습니다. 그 배경에는 나름대로 이유가 있었지만, 서비스 초기에는 안정성에 어려움을 겪기도 하였고 서버 배포 과정이 느리고 복잡하여 쉬운 길은 아니었습니다. 여러 문제를 해결하기 위해 Haeinsa 등 라이브러리와 소프트웨어를 직접 만들기도 하였습니다.타다는 이슈가 많은 모빌리티 시장을 타겟으로 하고 있기 때문에 Time to Market이 특히 중요했습니다. 개발하는 기간 동안 시장 상황에 따라 기능의 우선순위가 변하기도 하였습니다. 이에 따라 서비스를 빨리 출시하고 외부의 변화에 유연하게 대처할 수 있도록, 완성도 있게 만들어져 있는 프레임워크나 라이브러리를 선택하였고, AWS에서 이미 잘 관리되고 있는 서비스를 적극적으로 활용하였습니다.사용 중인 기술들Kotlin: Java는 불편한 점이 많지만, JVM에 대한 경험을 무시할 수는 없어 비교적 새로운 JVM 기반 언어인 Kotlin을 사용하기로 하였습니다. 다른 여러 JVM 기반의 대안 언어들이 있지만, Spring Boot에 쉽게 적용할 수 있고 커뮤니티에서 적극적으로 권장하고 있는 점 등 여러 이유로 Kotlin을 선택하게 되었습니다.Spring Boot: 널리 쓰는 웹 프레임워크이며 이미 지원하는 기능 또한 많기 때문에 보일러 플레이트 코드 작성을 줄이고 서비스 개발에 집중할 수 있습니다. SQS 메시지 처리, HTTP 요청 및 응답으로 Protocol Buffers 메시지 사용 등 프레임워크에서 제공하는 기능을 많이 활용하고 있습니다.Kubernetes: 컨테이너 오케스트레이션 플랫폼으로 배포 자동화와 스케일링 등 여러 가지 운영적인 편의성을 제공합니다. 처음에는 kops를 이용해 클러스터를 직접 띄웠지만, 지금은 EKS를 이용하고 있으며 직접 object를 만들기보다 helm을 이용하고 있습니다.gRPC: 실시간성이 중요한 차량 위치나 운행 상태 변화 등은 Streaming을 이용하여 전달하고 있습니다. 직접 개발할 수도 있었지만, 서비스 개발에 집중하고 앞으로의 관리 오버헤드를 줄이기 위해 gRPC를 이용하기로 하였습니다.Redis: 서버 간 메시징을 위해 Redis의 Pub/Sub 기능을 사용하고 있습니다. 메시지 브로커 기능을 제공하는 RabbitMQ, ActiveMQ, Kafka 등 여러 옵션이 있었지만, 개발을 시작하던 당시에는 Redis만이 ElastiCache를 이용하여 쉽게 띄우고 관리할 수 있어 Redis를 선택하게 되었습니다.Protocol Buffers: gRPC 뿐만 아니라 HTTP/2로 주고받는 메시지를 정의할 때도 이용하고 있습니다. 덕분에 따로 문서화 하지 않고 proto파일을 공유하여 더욱 명확하고 편리하게 API 명세를 공유할 수 있었습니다.Terraform: HCL을 이용해 인프라스트럭처 프로비저닝 및 관리를 편하게 해주는 도구입니다. AWS 서비스의 생성 및 관리를 콘솔에서 직접 하지 않고 Terraform을 이용하고 있습니다.사용 중인 AWS 서비스들AWS는 개발팀이 오랜 기간 사용하여 가장 익숙한 클라우드 플랫폼이기 때문에 큰 고민 없이 선택할 수 있었습니다.EKS: Kubernetes 클러스터의 마스터 노드들을 쉽게 띄우고 관리해주는 서비스입니다. 서울 리전에 EKS가 출시된 후에는 관리 오버헤드를 줄이기 위해 EKS로 옮겼습니다.ECR: 타다 서버를 배포할 때는 Docker Gradle Plugin을 통해 docker 이미지를 만들고 ECR에 푸시합니다. 그 후 helm 명령을 통해 Kubernetes에 배포합니다.SQS: 배차 요청을 처리하기 위해 SQS를 이용합니다. 배차 요청을 구현하는 방법에는 다양한 옵션이 있었지만 AWS 서비스를 최대한 활용하여 빠르게 개발할 수 있었습니다.RDS: 타다의 대부분 데이터는 Aurora에 저장하고 있습니다. RDS를 이용하면 DB의 배포와 관리가 쉬우며, Aurora는 MySQL과 호환될 뿐만 아니라 같은 비용이면 성능이 더 좋습니다.Kinesis: 실시간 차량 위치 정보 및 로그를 수집하기 위해 사용하고 있습니다. 다른 오픈소스 소프트웨어를 직접 이용하기보다는 AWS에서 제공하는 서비스를 최대한 이용하고 있습니다.Firehose: 비트윈에서는 KCL를 활용해 Acheron이라는 프로그램을 직접 만들어 로그들을 S3에 저장하였지만, 이제는 서울 리전에서 Firehose를 사용할 수 있으므로 큰 고민 없이 사용하기로 하였습니다.시스템 구성타다에서는 필요에 따라 서비스를 여러 종류로 분리하여 운영하고 있습니다. 일반적인 모바일 앱 API와 실시간 차량의 위치 정보를 바탕으로 사용자의 요청에 대해 적합한 차량을 배차하는 기능이 필요했습니다. 핵심적인 역할을 하는 일부 서비스와 시스템 구성에 대해 간단하게 소개합니다.라이더 앱: 아이폰은 Swift, 안드로이드는 Kotlin으로 작성하였으며 여러 오픈소스 라이브러리를 적극적으로 활용하였습니다. 서비스 특성상 RIBs라는 아키텍처를 사용하여 개발하였습니다.드라이버 앱: 아이폰과 안드로이드를 모두 지원하려면 기술적, UX적으로 고려해야 할 점들이 많고 불특정 다수의 유저를 대상으로 하는 앱도 아니었기 때문에 안드로이드 버전으로만 개발하게 되었습니다.서버: 모바일 앱의 요청을 대부분 처리하며 Spring Boot로 작성된 HTTP/2 API 서버입니다. Protocol Buffers로 정의된 메시지를 JSON 형태로 주고받습니다.gRPC 서버: 서버에서 발생하는 이벤트를 실시간으로 전달하기 위한 서버입니다. Redis Pub/Sub을 통해 받은 이벤트 메시지들을 클라이언트들에게 전달합니다.Dispatcher: 배차 요청을 처리하는 서버입니다. 주변 차들의 ETA 계산을 위해 외부 API를 이용하는데, Reactor를 이용해 비동기적, 동시적으로 요청하여 쓰레드 점유 없이 효율적으로 처리되도록 구현하였습니다.Tracker: 차량 위치 정보 수집 서버입니다. KCL를 이용해 위치 정보 레코드를 읽어 들여 TrackerDB에 기록합니다.Redis: 서비스 초기에는 차량의 최신 위치 등을 저장하기도 했지만, 지금은 주로 서버 간 메시징을 위해 Pub/Sub 기능을 이용하고 있습니다.DB: 운행 기록, 사용자 데이터 등 대부분 데이터를 기록합니다. 비트윈에서는 HBase를 이용했지만 타다의 경우 아직 절대적인 트래픽이 많지 않기 때문에 트랜잭션 등 다양한 편의 기능을 제공하는 RDB를 이용하고 있습니다.TrackerDB: 차량 운행 정보 및 차량의 최신 위치 등을 저장합니다. Aurora를 이용하며 대부분의 요청이 차량 위치 정보 업데이트이므로 안정성을 위해 별도의 인스턴스를 띄워 사용하고 있습니다.Kinesis Log Stream: 타다의 여러 서비스에서 로깅을 위해 이용합니다. Firehose를 통해 S3에 기록됩니다.Kinesis Tracker Stream: 드라이버의 실시간 위치 정보는 Kinesis를 통해 Tracker로 전달됩니다.서비스 플로우차량 위치 업데이트차량 위치 업데이트는 요금 계산, 차량 위치 제공 등 서비스에서 가장 많이 일어나는 요청입니다. 드라이버 앱에서 안드로이드 Foreground 서비스를 이용해 GPS 정보를 수집하고 일정 주기마다 서버로 현재 위치를 전송합니다. 이렇게 전송받은 GPS 위치 정보는 데이터 크기를 최소화하기 위해 Protocol Buffers로 직렬화되어 Kinesis 레코드로 만들어지게 됩니다. Tracker에서는 전달된 Kinesis 레코드를 읽어 간단한 처리를 한 후에 TrackerDB에 삽입합니다.서비스 초기에는 차량의 마지막 위치에 대한 정보만 Redis에 적었습니다. 그러나 차량의 이동 경로를 효율적으로 조회해야 할 일이 생겼는데, 당시 차량 이동 경로는 로그로만 저장되고 있었습니다. S3 Select나 Athena를 이용해 조회하는 방안도 고려했지만, 일단은 Aurora에 저장하기로 하였습니다. 당분간은 Aurora로도 충분했고 RDB를 쓰는 것이 가장 쉽고 편한 방법이었기 때문입니다.차량 배차차량 배차는 서비스의 가장 기본적인 기능으로 배차 요청에 가장 적절한 주변 차량을 할당하는 플로우입니다. 라이더 앱에서 유저가 배차를 요청하면 서버가 배차 요청 정보를 DB에 기록하고 배차 요청 메시지를 SQS 대기열에 집어넣습니다. Dispatcher가 배차를 처리하는 로직을 수행하여 차량이 매칭되면 드라이버 앱으로 이벤트가 전달됩니다.드라이버가 배차를 수락하면 서버로 수락 요청이 전송되고 서버에서는 DB의 배차 요청 상태를 수락 상태로 변경합니다. 배차 요청이 수락되었다는 이벤트는 결과적으로 gRPC 서버를 통해 해당 이벤트를 구독하고 있던 유저에게 전달됩니다.Dispatcher에서 배차를 처리하는 로직은 여러 옵션이 있었지만 가장 간단하고 효율적으로 개발하기 위해 SQS의 기능을 최대한 활용하였습니다. Dispatcher 수를 늘리는 것만으로도 처리량 확장이 가능하며 Dispatcher가 갑자기 종료되어도 한 대라도 살아있다면 결국에는 잘 처리가 됩니다. Dispatcher가 배차 요청을 받으면 다음과 같은 로직을 수행합니다. 종료 조건을 만족하지 않았다면 일정 시간 후 동일한 로직을 다시 반복합니다.배차가 가능한 상태라면 배차 로직을 수행합니다. 이동 경로와 교통정보를 고려하여 적합한 주변 차량을 찾습니다.만약 적합한 차량이 있다면 배차 요청을 해당 드라이버에게 할당되었다는 정보를 DB에 적고 배차 할당 이벤트를 전파합니다. 드라이버의 수락을 기다리기 위해 일정 시간 후 로직을 재시도합니다.만약 적합한 차량이 없다면 일정 시간 후에 로직을 재시도합니다.배차 요청이 드라이버의 수락을 기다려야 하거나 타임아웃이 남아있는 상태라면 적절한 시간 후 재시도합니다.배차 요청이 수락되어 완료된 상태거나 취소되었거나 타임아웃이 지난 상태라면 SQS에서 메시지를 삭제합니다.못다 한 이야기타다를 런칭하는 날, 기사 간담회에서 쏘카의 VCNC 인수 이후 짧은 기간 동안 타다를 만들 수 있었을 리 없으니, 실제 개발 기간은 어느 정도냐는 질문이 있었습니다. 짧은 기간 내 서비스를 성공적으로 런칭할 수 있었던 것은 상황에 맞는 올바른 기술적 선택들뿐만 아니라 훌륭한 팀원들이 있었기에 가능했던 일이었습니다. 타다는 개선해야 할 부분도 많고 앞으로 새로운 기술적 도전들이 많이 있을 것입니다.네 그렇습니다. 결론은 기술적 난제들을 고민하면서 좋은 팀과 서비스를 함께 만들고 키워나갈 좋은 분들을 기다리고 있다는 것입니다.
조회수 1624

박문수 이야기

출근 첫날 이효진 대표님으로부터 입사 지원 메일을 하나 전달받았다. 이력서를 살펴보니 컴퓨터를 전공하지도 않았고, 현재 개발을 하고 있지도 않았지만 개발자로 일하고 싶다고 적혀 있었다. 개발을 할 수만 있다면 인턴부터 시작해도 좋다고 말했다. 남들이 부러워하는 삼성에 다니고 있는데 어떤 이유로 개발자가 되고 싶어 할까? 궁금한 마음에 한 번 만나보기로 했다. (뽑을 생각은 없었다)첫인상은 그냥 수수한 시골 청년이었다. 나도 입사한 지 얼마 안 되어 회사 주위 식당을 몰라 그냥 눈에 띄는 식당으로 들어갔다. (생각해 보니 그 식당을 그 이후로는 한 번도 가지 않았다) 지난 회사에서 어떤 일들을 했고, 왜 개발에 대한 목마름을 느꼈는지를 들었다. 개발자가 되기 위해 어떤 것들을 포기할 수 있는가에 대한 각오도 들었다.나는 앞으로 일 년 동안 인턴 월급을 받아야 할지 모른다고 이야기했다. 정말 열심히 하지 않으면 그저 그런 개발자가 되어 인생이 꼬일지도 모른다고 경고했다. 그런데도 흔쾌히 도전해보고 싶다고 말했고, 나는 배움의 기회를 제공하겠다는 약속을 했다. 좋은 대학을 나와 어렵게 얻은 직장을 포기하고 다시 새로운 길을 선택하려는 용기를 높이 샀다. 입사일은 3주 뒤로 정했다. 파이썬 책과 웹 프로그래밍 기본 책을 던져주고 모두 읽어 오라고 했다.입사 후 정신없이 3주가 지나고 문수님이 입사를 했다. 첫날 개발 환경을 셋업 하는 것을 도와주었다. 나에게는 너무나도 자연스러운 많은 것들이 그에게는 생소한 것이고 설명을 해야 했다. 문수님이 이해할 수 있는 간단한 것만 설명하고 나머지는 더 크면 알게 된다고 설명을 미루었다.(첫날 전체를 대상으로 자기소개를 하는 문수님. 우리 회사에는 입사자가 전체를 대상으로 자기소개를 하는 문화가 있다. 이 문화의 유래에 대해서는 다시 한 번 이야기해 보겠다.)내가 모든 것을 알려 줄 수는 없으니 코세라 수업을 같이 들어 보자고 이야기했다. 내 기준으로는 너무 쉬운 강의였지만 나는 회사 내에서 공부하는 분위기를 만들어 가고 싶었고 문수님께는 회사에서 필요한 기술 스택을 맛보는 기회가 될 수 있으리라 생각했다. (현재 시점으로 3달째 코세라 강의를 이어서 듣고 있다.)첫 강의인 HTML5를 들으면서 간단한 버그 수정부터 문수님께 요청을 하기 시작했다. 오자를 고치거나 박스의 위치를 조정하는 일부터 시작했다. 입사하고 3일이 지나서 첫 번째 배포를 했다. 처음이 어려웠을 뿐 간단한 수정을 하는 것에는 일주일이면 충분했다. 그때부터는 git과 git flow를 알려주기 시작했다. 착한 신입은 마음이 열려 있어서 불만 없이 모든 것을 따라 했다. 어느 정도 이해를 했는지는 알 수가 없다. 하지만 프로그래밍을 배우는 길에는 머리보다 손이 먼저 익히는 것들도 많다.3주가 지난 시점에는 첫 번째 데모를 전체 앞에서 보였다. (우리는 스크럼을 하고 있어서 매번 스크럼이 끝나는 날에 개발자가 스스로 자신이 개발한 것을 전 직원 앞에서 데모를 보인다.) 지금은 잠깐 문을 닫은 채권 거래소에서 채권 판매자가 손쉽게 채권을 팔 수 있는 기능이었다. 그것을 만들기 위해 일주일 넘게 꽁꽁 머리를 싸매고 있었고, 결국은 결과물을 내놓았다.(첫 번째 데모를 보이는 문수님. 긴장한 모습이 느껴진다. 데모를 마치고 다들 뜨거운 박수를 보내주었다)내가 만들면 2시간이면 끝났을 기능이라 일주일간 고생하는 것을 옆에서 지켜보는 것은 상당한 인내를 필요로 했다. 하지만 최대한 혼자만의 힘으로 첫 번째 과제를 해내기를 원했기에 최소한의 도움만을 주었다.이제 문수님이 입사한 지 만 3개월이 되었다. 그동안 많은 변화가 있었다. 회사에서 조그마한(점점 커지고 있다) 수정/기능들은 대부분 맡아 주고 있기에 다른 개발자들은 좀 더 어려운 문제를 풀 수 있게 되었다. 처음에는 코드 리뷰를 온라인으로 할 수가 없었다. 옆에 앉아서 어떤 부분을 어떻게 고쳐야 하는지를 구체적으로 알려 주어야 했고, 이해하지 못하면 관련된 지식을 얻을 방법을 알려 주어야 했기 때문이다. 하지만 이제 github의 PR을 보고 코멘트를 다는 것 만으로 코드를 적절히 수정할 수 있게 되었다. 얼마 전에는 하루에 1억이 넘는 이체를 하는 내부 시스템을 80% 이상 만들기도 했다. (내가 뼈대는 잡아 주기는 했다.)개발자라 부를 수 있는 기준이 따로 있겠냐만은 나는 이제 그를 개발자라 부를 수 있을 것 같다. 아마도 오늘의 문수님에게는 “개발자 박문수 님”이 가장 듣고 싶은 호칭이 아닐까 생각한다.  마지막으로 전공하지도 않았고, 첫 직장과도 관련 없는 새로운 도전을 하는 문수님의 용기에 박수를 보낸다. 내게 말하지는 않았지만 수많은 주위의 걱정과 우려를 이겨내기 위해 최선을 다하고 있으리라 생각한다. 나는 앞으로 그에게 “문수님은 지금 어디로 가고 있나요?"를 종종 물어봄으로 내 역할을 해야겠다.8퍼센트는 멋진 저희 팀과 함께 할 분들을 찾고 있습니다. 특히 저보다 개발을 잘 하시는 시니어 개발자, 그리고 3년 뒤에는 저 보다 잘하게 되실 주니어 개발자는 제가 모시러 갑니다. [email protected]로 연락 주세요.박문수 님이 이체 시스템 개발을 할 때 Toss의 이체 대행 API를 사용했습니다. 정말 간편합니다. 관련 개발을 하시는 분들은 사용해 보세요.#8퍼센트 #에잇퍼센트 #채용 #채용후기 #개발자 #개발자채용 #인턴 #인턴채용 #스타트업CTO
조회수 6343

[SQL 데이터분석] 증감율 구하는 간단한 방법

sql에서는 = 등호가 비교연산자로 사용됩니다.대신 := 이렇게 콜론(:)과 등호(=)를 같이 쓰면 대입연산자로 쓸 수 있어요.select @prev := users.id // @prev 라는 임시변수에 users.id 값을 넣어라. from users가입일자로 사용자수를 구해보면, 아래처럼 가입일로 group_by 를 해서 구하죠.select date(created_at) as '가입일' , count(1) as '가입자수' from users group by 1 order by 1 desc;// 가입일 | 가입자수 // --------------------------- // 2017-08-02 100 // 2017-08-01 50그럼 전일 대비 증감율을 구하려면 어떻게 할까요?select date(created_at) as '가입일' , @prev as '전일 가입자수' , (count(1) - @prev) / @prev as '증감율' , @prev := count(1) as '가입자수' from users group by 1 order by 1 desc;// 가입일 | 전일 가입자수 | 증감율 | 가입자수 // -------------------------------------------------------- // 2017-08-02 50 1.0 100 // 2017-08-01 50 0 50증감율을 계산하는 count(1) / @prev까지는 @prev 에 전일 가입자수가 저장되어 있구요.@prev := count(1) 에서 당일 가입자수로 할당이 됩니다.저는 := 이 연산자를 알기 전엔 self-join 형태로 증감율을 구했는데데이터를 가오는 속도는 := 이 연산자가 훨씬 빠른것 같습니다.다음엔 self-join 으로 증감율을 구하는 법도 한 번 올려볼께요.#티엘엑스 #TLX #개발 #개발팀 #개발자 #꿀팁 #인사이트 #조언
조회수 1090

[Buzzvil Culture] 개발팀의 모바일 스터디 그룹이란?

 버즈빌 개발팀의 모바일 스터디 그룹이란? 모바일 잠금화면 미디어 플랫폼 ‘버즈빌’의 개발팀이 진행하는 모바일 스터디 그룹이란, 모바일이라는 큰 주제를 핵심으로 하여 크고 작은 연관된 기술을 리뷰하고 토의하는 스터디 모임입니다. 2018년 7월에 처음 개설되어 현재까지 매주 진행하고 있으며 특정한 기한 없이 지속적으로 진행할 예정입니다. 모바일이라는 핵심 주제를 고지하기는 했지만 사실상 개발에 관련된 모든 주제가 이야기될 수 있으며, 개발 언어, 특정 라이브러리 및 프레임워크, 개발 관련 툴, Google I/O와 같은 각종 컨퍼런스 등 거의 모든 것이 저희의 관심사입니다. 심지어 한 번은 자주 쓰는 단축키에 대해서도 토의한 적이 있습니다. 어떤 목적을 갖고 만들어졌는가? 개발이라는 일은 특히나 최신 이슈에 민감한 분야인 것 같습니다. 빈번하게 일어나는 OS 업데이트와 그에 따른 이슈 처리, 주요 컨퍼런스 내용에 따른 개발 트렌드 변화, 갑작스레 혜성처럼 등장한 개발 라이브러리… 저희 개발자들은 이러한 이슈에 항상 귀를 기울여야 하며, 그에 대해 생각을 정리할 필요가 있습니다. 또한 이러한 기술 습득은 저희 직원들의 커리어에도 중요한 지표가 될 것은 자명하지요. 그러나 실제 업무에 집중하다 보면 자칫 이러한 이슈에 대해서 멀어지게 되고는 합니다. 숲을 보지 못하고 나무만 보는 꼴이랄까요. 모바일 스터디 그룹은 바로 이러한 점을 해결해보기 위해서 개설됐습니다. 적어도 1주일에 한 번씩은 업무에서 잠시 떨어져 다양한 개발 주제로 생각을 정리해보자는 게 이 스터디의 목적이며, 다재다능한 그룹원들의 참여 아래 훌륭하게 진행되고 있습니다. 어떻게 진행되고 있는가? 우선, 매주 월요일 점심마다 스터디가 진행되고 있습니다. (스터디를 할 경우 회사에서 점심을 제공하고 있어 회사의 모든 스터디 모임이 더욱 활성화되는 것 같습니다.) 스터디 주제는 1주일 전에 그룹원들과 이야기를 통해서 정하고 있고, 주제가 정해지면 자발적으로 주제에 대해 학습하며 자료를 공유합니다. 스터디 당일에는 일정 시간을 개별 학습하는 용도로 사용하고, 그 후에 각자 공부한 내용을 바탕으로 자기 생각을 이야기합니다. 기본적으로 상황에 맞게 자유롭게 진행되기 때문에 꼭 위와 같은 방식을 고수하지는 않습니다. 때로는 특정 주제에 대해서 스터디원이 세미나를 희망하기도 하는데, 이 경우 발표자가 자료를 만들어서 세미나를 진행하기도 합니다. 한 번 했던 주제에 대해서 다수가 흥미를 가질 경우 다음 주에 조금 더 깊이 있는 이야기를 나누거나 실제 실습을 해보는 시간을 갖기도 합니다. 아직 시도하지는 않았지만, 주요 컨퍼런스 영상을 보는 시간으로도 활용할 생각입니다. 어떤 주제를 진행했는가? 모든 주제를 나열할 수는 없지만, 대표적인 사례에 대해서 전달하겠습니다.  RxJava : Reactive 진영의 자바(Java) 라이브러리. 그 내부 원리와 구조 학습 Unit Test : JUnit 4, Mockito, Robolectric의 활용과 실전 예제 학습 Kotlin(코틀린) : 안드로이드(Android)에서의 Kotlin 트렌드 확인. Kotlin의 장단점 분석 MVP / MVVM : 안드로이드(Android) 아키텍쳐로 바라보는 MVP / MVVM의 내용 및 차이 학습  이 외에도 여러 주제에 대해서 지속해서 스터디를 진행했지만, 위 내용은 스터디원이 전체적으로 공감하고 도입 의지를 이끌었다는 점에서 인상적이었던 것 같습니다. 특히 코틀린과 같은 경우는 실험적으로 프로젝트에서 도입을 진행하고 있고, 코드 간결화, Null-Safety 측면에서 큰 장점을 느끼고 있습니다. 이처럼 저희 스터디는 학습하게 된 내용을 단순히 지식으로 놔두지 않고 실제 프로덕션에 도입까지 충분히 진행 할 수 있으며, 반대로 실제 프로덕션에 더 좋은 기술을 도입하기 위해서 다양한 주제를 찾아가고 있습니다.버즈빌의 스터디는 무엇이 다른가? 개인적으로 꽤 많은 스터디에 참여해 봤다고 생각합니다. 다양한 주제는 물론 강의형, 토론형 등 여러 방식으로 진행해본 경험이 있습니다. 그중에는 1년 넘게 유지되면서 다양한 지식을 습득한 모임도 있었고, 몇 번 해보지도 못하고 와해한 안타까운 케이스도 있었습니다. 덕분에 좋은 스터디란 무엇인가에 대해 꽤 고민을 해봤고 어떤 부분이 중요한지 나름대로 생각하고 있는 부분이 있습니다. 그리고 그러한 측면에서 버즈빌의 스터디는 좋은 스터디라고 분명히 말씀드릴 수 있습니다. 그렇다면 구체적으로 어떤 점이 버즈빌의 스터디를 좋게 만드는 것일까요? 그 이유는 다음과 같습니다. 첫째, 버즈빌의 수평적인 문화 버즈빌의 사내 문화는 수평적이고 자율적인 문화로 유명합니다. 소위 고루한 잔소리꾼 문화가 없기 때문에 자신의 의견을 누구나 자유롭게 이야기합니다. 사내문화가 스터디와 무슨 상관이 있냐 하실 수 있지만, 수직적인 조직의 사내 스터디와 비교했을 때 큰 차이를 볼 수 있었습니다. 버즈빌의 스터디에서는 여러 사람이 어떠한 권위에 눈치 보지 않고 자유롭게 자신의 의견을 제시하며, 듣는 이 또한 어느 의견이든 함부로 가늠하지 않고 진지하게 받아들입니다. 이는 단순히 스터디 토론에서만 적용 되는 것이 아니라, 스터디 시스템에 대해서도 불합리하거나 개선하고 싶은 점을 여과 없이 이야기합니다. 그리고 그들의 의견을 피드백하여 시스템이 지속적으로 개선되고 있습니다. 결국은 버즈빌의 수평적인 문화가 스터디 문화 자체도 현실적이고 합리적으로 바꿔나간다고 할 수 있습니다. 둘째, 뛰어난 구성원 스터디에서 구성원은 분명 굉장히 중요한 요소입니다. 구성원의 역량과 열정에 따라서 스터디의 질과 지속력이 결정됩니다. 그런 측면에서 버즈빌은 상당히 축복받은 조직임에 틀림없습니다. 당장 제 옆만 둘러봐도 어디서 이런 분들이 나왔을까 싶을 정도로 뛰어난 역량의 소유자가 많으니까요. 아마 인사팀에서 일을 잘하고 있나 봅니다. 여하튼, 버즈빌에는 다재다능한 인재가 정말 많습니다. 각종 분야에 있어서 상당한 지식을 보유하신 분도 굉장히 많으시고, 무엇보다 개발을 좋아하고 새로운 기술을 배우는 것에 긍정적입니다. 열정이 넘친 나머지 스스로 일정을 잡아서 기술 세미나를 진행하기도 하지요. 이런 분들과 함께 하는 스터디, 안 좋을 수가 없습니다. 셋째, No 강제, No 의무 제가 생각하는 좋은 스터디의 중요한 요소는 지속력입니다. 아무리 좋은 스터디라도 무리한 일정과 과제의 압박이 있다면 지속되기 힘들다고 생각합니다. 단발성으로 집중하여 어떤 지식을 습득하려는 게 아닌 이상은, 결국 얼마나 꾸준히 스터디원이 참여하고 공부를 할 수 있는지가 중요합니다. 그러한 측면에서 볼 때 참가를 강제하고, 어떠한 의무성인 과제를 부여하는 것은 지양해야 합니다. 공부는 스스로의 의지에 의해서 수행되어야 하며, 스터디 시스템에서 이를 강제 해봤자 결국은 보여주기 식의 활동밖에 되지 않습니다. 사람이 어떻게 모든 주제에 항상 열정적으로 공부를 하겠습니까. 그렇기에 스터디라는 시스템보다는 사람이 우선이어야 하며, 공부는 본인의 자유입니다. 위와 같은 요소로 인해 전 결론을 내봅니다. 버즈빌에서 굉장히 좋은 스터디를 하게 되었다고. 결론 버즈빌에서 스터디는 CEO 분들을 비롯하여 많은 구성원이 장려하고 권장하는 부분입니다. 그들은 직원의 역량 강화가 곧 회사 역량의 강화라는 인식을 바로 갖고 있으며, 이를 위해 정책적으로 지원하는 방안을 마련해주고 있습니다. 스터디 제도뿐만 아니라 각 개인이 성장할 수 있도록 동아리 지원, 자기개발비 지원 등은 물론 읽고 싶은 책은 무제한으로 제공 해주고 있습니다. 어쩌면 이러한 사소한 점 하나하나가 버즈빌의 소중한 자산이 아닐까 생각하며, 이만 글을 마무리 짓습니다. 감사합니다.작가소개 Ethan Yoo, Software Engineer (Android) 안녕하세요. 버즈빌에서 안드로이드 부분 개발을 담당하고 있는 Ethan (이든)입니다. 개발이라는 주제로 다양한 곳에 관심사를 갖고 있고, 동료와 함께 개발 이야기를 하는 것을 좋아합니다. 메인 언어는 자바(Java)를 사용하고 있지만, 코틀린(Kotlin) / 파이썬(Python) / 자바스크립트(JavaScript) / 하스켈(Haskell) 등 다양한 언어에 대해 경험이 있습니다. 최근에는 시스템 아키텍쳐에 관심을 갖고 반응형 프로그래밍, 함수형 프로그래밍 등이 안드로이드와 어떤 구조로 표현 될 수 있을지 고민하곤 합니다. 제가 만든 서비스가 세상을 바꿀 수 있기를 희망하고, 이를 위해 버즈빌에서 오늘도 열심히 개발을 하고 있습니다.
조회수 1416

잉여와 SW 개발의 관계...

IoT의 관점과 함께 최근에 주목을 받는 시계열 DB들이 있다. OpenTSDB나 인플럭스 DB, Graphite와 같은 것들이다. 신기한 것은 최신의 기술이나 플랫폼이라고 불리는 것들은 국내에서는 거의 등장하지 않는다. 대부분 미국이나 유럽, 이제는 중국이나 러시아에서 등장한다. 물론, 일본에서는 새로운 언어도 많이 등장했다.집안의 전기 사용량을 측적하건, 공기 측정이 되었건 1초에 한번 측정하는 센서에서 만들어지는 데이터를 자세하게 분석하려면 이 데이터를 수집하고 모아야 한다. 그리고, 최소 연단 위 정도는 모아서 무언가를 분석하거나 추이를 살펴보아야 할 것이다.더군다나, 센서가 하나가 아니라 여러 개 라면 모여지는 데이터의 량은 상당할 것이다. 기존의 RDB에 축적하는 것은 이런 경우에 좀 맞지 않는다. 데이터가 계속 용량을 늘려나가는 구조이기 때문에 NoSQL형태의 데이터 스토어를 생각하게 된다. 코치이건 하둡이건 몽고이건 여러 가지가 생각난다. 실시간으로 추적 분석하려면 Apache Storm이나 spark도 생각날 것이다.일단, 센서가 시간의 추이에 따라서 데이터를 모으는 형태에 적합한 시계열 DB에 적합한 방법들에 대해서 나름 적합한 형태로 개발되는 구조를 가진 DB들을 어렵지 않게 찾아볼 수 있다. 이 글 가장 앞에 언급한 것들이다.관련 자료를 찾아보고 싶으면, OpenTSDB는 http://opentsdb.net , InfluxDB는 https://influxdb.com을 찾아보라. 나름 매력적으로 시계열 형태의 데이터를 모으기 좋은 구조로 디자인되는 설루션을 만날 수 있다.오늘 글에서 언급하고 싶은 것은... 이러한 특정 요점에 맞는 설루션들이 왜? 국내에서는 나타나지 않는가에 대해서 끄적거려 보고 싶어서이다. 과연, 이러한 태도와 행동, 행위가 특정 개발자의 탁월함 때문일까? 아니면, 국내에 있는 개발자들이 게으르고, 자신의 이익만을 위해서 일하는 것 때문일까?삐딱한 아키텍트는 그 부분을 이렇게 해석한다.하나. 잉여가 없는 부가가치가 적은 일을 매번 수행하는 국내의 경영자들의 문제.둘. 반복적인 작업이나 자신의 일의 미래에 대해서 큰 관심 없는 개발자의 자세셋. SI형태로만 진행되는 국내 프로젝트이기 때문에 만들어진 플랫폼이나 유틸리티 성의 서비스를 외부에 오픈하지 못하는 경우가 빈번함.이 3가지의 가장 큰 이유 때문에 국내에서는 특정 용도나 특정 의미의 환경에 잘 어울리는 설루션들이 오픈소스로 발전되고, 더 넓게 쓰이는 플랫폼까지 진화하지 못한다고 생각한다. 하나씩 나름대로 이유를 이야기해보자.하나. 잉여가 없는 부가가치가 적은 일을 매번 수행하는 국내의 경영자들의 문제일단, 부가가치가 높은 소프트웨어나 서비스를 개발한다면, 적절하게 배분되어진 팀과 일정, 부가가치가 높기 때문에 피드백을 통해서 품질을 높이기 위한 시도들이 반복되어진다. 하지만, 대부분 1회성으로 끝나거나, 단기적인 일거리를 해결하기 위해서 소프트웨어를 개발하는 경우가 대부분이기 때문에 사소한 잉여도 발생하기 어렵다.고품질을 지향하는 소프트웨어 개발을 추구한다면 매우 당연하게 잉여시간과 잉여 일정, 잉여인력이 투입되는 것이 정상이다. 매우 당연하게 소프트웨어 개발자들은 게으르기 때문에 반복적인 일을 싫어하고, 게으르기 때문에 소프트웨어의 품질을 높이기 위해서 공을 들인다.이런 게으른 소프트웨어 개발자들이 품질 높이기를 포기하는 이유는 간단하다. 그 소프트웨어가 재사용될 가능성이 거의 존재하지 않고, 또다시 요구사항에 따라서 난도질을 해야 하는 경우에 품질 높이기를 시도하지 않는다.결론적으로 소프트웨어 개발자들이 고품질을 만들지 않는 이유는 처음부터 비즈니스 기획과 부가가치에 대한 이윤과 투입되는 비용에 대해서 잘못된 비즈니스 모델을 만든 기획자나 경영자가 그 책임을 져야 한다. 물론, 그런 환경을 주었더라도 잘못된 개발자를 뽑은 '인력관리'의 미스에 대해서도 그 역시... 경영자가 책임져야 한다.대부분 고품질의 소프트웨어가 나타나지 않거나, 잉여가 만들어지지 않는 이유는 경영자가 미 숫하고, 비즈니스 모델을 잘못 디자인해서 그러하다.둘. 반복적인 작업이나 자신의 일의 미래에 대해서 큰 관심 없는 개발자의 자세하지만, 경영자의 잘못과 거의 비슷한 수준의 개발자의 관심 없는 자세인 경우가 문제가 되는 경우도 많다. 잉여가 주어졌음에도 빈둥거리거나, 자신만의 놀이를 위해서 그 시간과 비용을 투자하는 경우도 간혹 있다. 하지만, 필자가 만나본 대부분의 개발자들은 그런 자세가 된 소프트웨어 개발자의 행태 또한 그 소프트웨어 개발자가 걸어온 그 전회사의 경영자의 문제라고 지적하고 싶다.반복적인 일을 줄이고, 미래의 코드에 대해서 신경 쓰는 자세는 소프트웨어 개발자가 기본적으로 갖추어야 하는 자세임에도 불구하고, 이러한 자세를 파괴하는 형태의 업무 구조와 생각 자체를 파괴하는 형태로 일을 구성하는 경영진과 같이 일한 개발자들은 슬프게도 잉여를 빈둥거리게 하는데 익숙하게 된다.필자가 개발자 구인 시에 가장 주목하고, 관심을 가지면서 걸러야 하는 개발자는 그러한 회사를 거쳐왔거나 그러한 프로젝트에 매몰되었던 사람들은 피하는 것이다. 한번, 그런 자세가 파괴된 개발자는 다시 자세를 정상으로 복구하는데 엄청난 리소스와 시간이 투입된다.냉정한 사람들이라면 이러한 사람들을 '동료'로 받아들이는 것을 싫어할 것이다.셋. SI형태로만 진행되는 국내 프로젝트이기 때문에 만들어진 플랫폼이나 유틸리티 성의 서비스를 외부에 오픈하지 못하는 경우가 빈번함.슬프지만, 3번째의 경우가 사실은 한국에서는 50% 이상 의미 있는 형태로 개발되었음에도 불구하고, 사장되거나 외부에 노출될 수 없는 형태가 되는 경우를 빈번하게 경험했다. 필자 역시, WebService개발 초기에 3 Tier개발에 어려움을 겪는 개발자들을 위해서 SQL 문장을 그대로 WebService에서 CRUD형태로 전송하고 데이터셋과 DB커서를 2 Tier의 형태로 손쉽게 개발할 수 있는 플랫폼과 컴포넌트를 개발했지만, 이 역시, SI에 종속된 결과물이 되면서 외부에 오픈할 수 없는 경우가 되는 것을 빈번하게 경험했다.슬프지만... 이 3가지의 큰 이유 이외에도 '잉여'가 없는 개발 일정이나 개발자에게 여유가 없어지면서, 정말 더럽게 재미없는 소프트웨어 개발이 반복되는 경우를 많이 보았다. 하지만, 필자의 경험은 그럼에도 불구하고 개발을 총괄하고 있다면, 자신의 팀에 있는 개발자에게 약간의 잉여와 고품질을 위한 리소스에 대한 배려를 취하면서 동료직원이 오픈소스를 창출하거나 외부에 오픈할 수 있는 정도의 다듬는 여유를 만들어 줄 수 있다고 생각한다.가장 훌륭한 CTO나 개발 총괄의 역할은 그 시간을 정말 즐겁다고 생각하는 동료 개발자에게 약간의 잉여와 여유를 허가하는 것이며, 그 잉여가 결론적으로 자신이 속한 개발 조직의 효율이 향상되고, 개발 문화가 부드러워지는 아주 의미 있는 개발 조직으로 완성되어가는 첫 번째 단추라는 것을 알기를 바란다.현재 훌륭한 개발 조직일수록, 카페와 같은 공간만을 만드는 것만으로 끝나는 것이 아니라, 개발 공정이나 개발 프로세스 상에 리뷰와 의미 있는 문서화 작업, 피드백과 리팩터링과 같은 시간을 배분하는 이유도 그 때문이라는 것을 잊지 않기를 바란다.훌륭한 하드웨어 적인 공간 위에 재미를 추구하고 의미를 추구하는 잉여가 존재하는 개발 공정을 탑재한 개발 조직이야말로 성공할 수 있는 전제조건을 하나 더 갖춘 곳이라는 것을...

기업문화 엿볼 때, 더팀스

로그인

/