스토리 홈

인터뷰

피드

뉴스

조회수 880

프로그래밍에는 왜 창의성이 필요하다고 할까요?

왜 프로그래밍에는 창의성이 필요하다고 할까요? 실제로 프로그래밍을 하다 보면 복잡한 문법을 이해하고, 암호 같은 에러를 차분히 해결해야 하니, 오히려 수학적이며 논리적인 사고가 더 필요해 보입니다. 그런데도 프로그래밍이 창의적이어야 하는 이유는 하나의 프로그램을 만드는 답이 여럿이기 때문입니다.답이 하나여도 가르치기 어려운데, 다양한 방법을 어떻게 가르쳐야 하는 걸까요? 또, 기상천외한 학생들의 코드를 보며 이해하고 교육하는 것이 얼마나 긴 시간이 필요하며 어려운 일인가요? 어디서부터 해결해나가야 할지 막막합니다.Elice 리서치 팀에서 하는 일 중 하나는 학생들의 수많은 코드 중 비슷한 타입들을 추려내는 것입니다. 코드를 몇 가지 타입으로 추려내고 나면, 선생님은 학생 하나하나의 코드를 보고 교육하는 것이 아니라, 비슷한 형태의 코드를 작성한 학생 그룹 전체에게 적절한 피드백을 줄 수 있습니다. 이렇게 그룹 전체에게 피드백을 준다면 선생님은 같은 시간에 더 많은 학생을 교육할 수 있을 것입니다.그럼 이제, 비슷한 코드를 어떻게 찾아내서 분류할지 이전 연구를 보며 알아봅시다. (현기증이 날 수 있으며, 다 이해할 수 없어도 괜찮으니 걱정하지 마세요!)지프의 법칙과 숙제 제출 패턴자연어 처리(Natural Language Processing;NLP)를 배울 때 자주 거론되는 사람이 있습니다. 바로 미국의 언어학자인 조지 킹슬리 지프George Kingsley Zipf인데, 이 사람이 만든 지프의 법칙은 자연적으로 일어나거나 생성되는 특정 정보들이 일정하게 나타내는 경향을 나타낸 것입니다. 지프는 영어로 된 텍스트를 분석하던 도중, 자주 쓰이는 단어를 순서대로 나열하면 각 단어의 빈도는 그 단어의 출현 순위에 반비례함을 찾아냈습니다. 영어에서 가장 많이 사용되는 단어 1~3위가 “the”, “of”, “and” 인데, “the”는 “of”의 약 두 배, “and”의 약 세 배의 빈도를 보입니다.이것을 수학적으로 표현하면, 일정 크기 이상의 영어 말뭉치(corpus)에 들어 있는 단어들의 개수를 전부 세서 그 단어들을 가장 많이 쓰이는 것부터 순위를 1위부터 나열했을 때, 특정 단어의 순위가 k 라면 (즉 전체에서 k번째로 많이 쓰인 단어라면) 그 단어가 말뭉치에서 쓰인 개수는 1/k에 비례한다는 것입니다. 이것을 그래프로 그려보면 다음과 같습니다. 재미있는 사실은, 여기에서 x축과 y축에 log를 씌워 보면 (이것을 log-log scale로 변환한다고 합니다.) 다음과 같은 직선 형태로 변환된다는 것입니다.이것이 도대체 숙제 제출과 무슨 관계가 있길래 이렇게 장황한 설명을 한 것일까요? 위에서 나온 지프의 법칙을 기억하시나요? 학생이 낸 숙제를 채점하다 보면 꽤 많은 학생이 비슷한 방식으로 숙제를 푸는데, 제출된 풀이 방식들을 비슷한 것끼리 묶어 분석해 보니, 이것 또한 지프의 법칙을 따른다는 것이 발견되었습니다. 예를 들어 가장 인기 있었던 풀이 방식으로 100명이 숙제를 제출했다면, 두 번째로 인기 있는 풀이 방식으로는 약 50명이 숙제를 제출했다는 뜻입니다.여기서 우리가 찾아낼 수 있는 인사이트는 무엇일까요? 첫째, 학생들의 숙제들을 비슷한 것끼리 묶을 수 있다면, 그리고 이 분류를 컴퓨터로 자동으로 할 수 있다면 조교가 채점하거나 코멘트를 할 때 써야 할 시간이 상당히 줄어들 것입니다. 둘째, 방법 서너 개에 대해서만 어떻게 채점할지 혹은 어떻게 코멘트할지에 대해 준비를 해놓으면, 그걸로 숙제 대부분을 채점/코멘트할 수 있을 것입니다. 대다수의 숙제는 몇 가지 인기 있는 풀이방식으로 만들어졌을 것이기 때문입니다.그러면 이제 다음 문제는, ‘비슷한 풀이 방식으로 푼 프로그램 코드’를 어떻게 찾아낼 것인가? 를 고민해봅니다. MIT의 Elena Glassman은 이에 대한 해법으로 Overcode를 제시했습니다.Overcode뉴스 기사나 책, 블로그 글 등 자연어로 이루어진 텍스트 데이터를 분석하고, 여기에 어떤 주제가 들어있는지 밝혀내는 연구는 많이 진행 됐습니다. 이를 위한 머신러닝 알고리즘 중 하나가 토픽 모델, Topic model 입니다(토픽 모델에 대해서는 다른 글에서 자세히 다룰 예정입니다). 그러나 토픽 모델링을 프로그래밍 문제에 실제로 적용하기는 쉽지 않습니다. 코드에 사용되는 문법이나 키워드가 자연어와 1:1로 매칭되지 않기 때문에, 기존에 자연어에서 사용되던 모델을 그대로 사용할 수 없기 때문입니다. 가령, 슬쩍 보면 무척 달라 보이는 아래 두 파이썬 코드는 사실 완전히 같게 동작합니다. 이 두 코드를 (사람들이 일상생활에서 사용하는) 자연어를 분석하는 모델로 분석한다면 제대로 된 결과를 낼 수 없는 건 당연합니다.def fibonacci(): parents, babies = (1, 1) while babies < 100 xss=removed>fibonacci()def fib(parents, babies): ‘’’ parents = 1 babies = 1 ‘’’ while True: print ‘This generation has {0} babies’.format(babies) parents = babies # set parents as babies babies = parents + babies # recursively add number of babies if babies >= 100: break fib(1, 1)Elena Glassman이 제시한 Overcode의 목적은 비슷한 로직으로 만들어진 프로그래밍 코드들을 모으는 것입니다. 이제 Overode가 어떻게 작동하는지 간단하게 소개하도록 하겠습니다. 가장 먼저 수행되어야 하는 것은 서로 다른 형식으로 쓰인 소스 코드들을 정리하는 것입니다. 소스코드 정리에는 주석 제거, 줄 및 공백/들여쓰기를 일정하게 맞추는 작업 등이 포함됩니다.Image from Overcode하지만 이 작업만으로는 충분하지 않습니다. 거의 같아 보이는 코드도 실제로 프로그램을 실행하기 전까지는 같은지 알 수 없고, 꽤 달라 보이는 코드도 실제로는 완전히 같게 동작할 수 있기 때문입니다 (여기서 같게 동작한다 함은, 결과를 같게 내는 것 이상으로 결과를 내는 중간과정이 완전히 같다는 것을 의미합니다). 다시 위로 돌아가, fibonacci() 함수와 fib(parents, babies) 함수를 살펴봅시다. 위 두 코드는 기존의 자연어 처리 기법에 따르면 완전히 다른 프로그램일 것입니다. 변수명이 달라서가 가장 큰 이유일 텐데, 사실 컴퓨터의 입장에서 변수는 어떤 값을 할당하는 공간에 불과하며, 그 공간에 어떤 이름을 붙이느냐는 중요하지 않습니다. 코드를 작성하는 것이 사람이기 때문에 공간에 편하게 이름을 붙이는 것뿐입니다. 서로 다른 프로그램에서 어떤 변수가 서로 같은 역할을 하는지, 컴퓨터가 알아내려면 어떻게 해야 할까요? (컴퓨터는 창의적이지 않습니다!)Image from OvercodeElena가 제시한 방법은 프로그램을 실행하면서 변수의 값이 어떻게 바뀌는지를 추적한 것입니다. 아래 두 코드를 보고, 한번 머릿속으로 프로그램을 실행해 봅시다. 학생 B의 코드는 for문으로 5의 3승을 계산했고, 학생 C의 코드는 while문으로 5의 3승을 계산한 것입니다. 학생 B의 코드가 실행됨에 따라 r이라는 변수가 어떻게 변하는지, 학생 C의 코드에서 result가 어떻게 변하는지 확인해보면 둘 다 1 → 5 → 25 → 125 의 값을 가지게 됩니다. 그렇다면 컴퓨터는 이렇게 판단할 수 있습니다. “B의 코드에서의 변수 r과 C의 코드에서의 result가 완전히 같은 방식으로 변하니, 같은 의미로 사용된 것이다.”Image from Overcode이제 같은 의미를 가지는 변수들을 알아냈다면, 컴퓨터는 쉽게 가장 “흔한” 이름으로 변수의 이름을 바꿔치기 합니다. 그러면 처음에 서로 다르게 보였던 코드들도 이제 같아질 것입니다.물론 이것이 다는 아닙니다. 예를 들어, 간단한 테스트 케이스들을 통해 결과를 비교함으로써 변수를 분석하기 전에 먼저 거르는 방법, 너무 흔한 변수들을 처리하는 방법 (예를 들어 완전히 다르게 동작하는 코드들에서도 반복문에서 사용되는 인덱싱 변수들은 같이 변화할 것입니다), 한 변수가 다른 의미론적으로 두 번 사용되는 경우 처리하는 방법… 등이 논문에는 더욱 자세히 적혀있습니다. 궁금한 독자들은 한번 논문을 읽어보도록 합시다.남은 문제들Elena가 제시한 방법은 위에서 보여준 예제와 같은 간단한 코드에서 꽤 잘 동작합니다. 예를 들어, 다음과 같은 문제들이 있습니다.a의 b승을 구해서 리턴하는 프로그램N번째 피보나치 숫자를 리턴하는 프로그램다항식의 미분 결과를 리턴하는 프로그램하지만 대학교에서 1학년만 넘어가더라도 이런 간단한 프로그램 과제는 내지 않습니다. 예를 들어 Elice에서 교육 중인 기초 프로그래밍/ 프로그래밍 유치원 수업을 듣는 학생들은 매우 많은 실습문제를 풉니다. 여기에서 푸는 과제들은 초반 몇 주가 지나면 이 정도의 간단한 프로그래밍 수준을 뛰어넘기 때문에, 코드가 꽤 길어지고 다양성이 생기게 되는데 이런 경우 이 방법은 잘 동작하지 않습니다.또 다른 문제는, 이 방법이 “동작하는” 코드에서만 작동한다는 것입니다. 예를 들어, 수강생들이 아직 기초 문법을 배우고 있다면? 제대로 실행도 되지 않는 코드를 만들었을 때, 비슷한 실수를 한 사람들끼리 묶어주고 싶다면? 아쉽게도 Elena가 제시한 방법은 이렇게 에러가 나는 코드에서는 동작하지 않습니다. 코드가 실행되지 않는다면 변수의 값의 변화를 추적할 수 없기 때문입니다.마치며이번 포스트에서는 학생의 제출 코드를 비슷한 것끼리 묶는(Clustering하는) 방법에 대해 간단하게 살펴 보았습니다. 학생이 낸 비슷한 답안을 모아주는 솔루션은 수학 문제 같은 단답식 문제, 혹은 영어 에세이같은 자연어에 대해서는 이미 상용화가 되어 있습니다. 영어 에세이의 경우 여러분들이 가장 친숙할 만한 상용화된 솔루션은 아마 copy detector일 것입니다.하지만 프로그래밍 코드의 클러스터링은 연구가 계속 진행되고 있습니다. 앞서 말했듯 코드에서 한 글자 한 글자가 가지는 의미가 자연어에서 가지는 알파벳과는 완전히 다르기 때문이기도 하고, 정말 실행을 해 보기 전까지는 어떻게 동작하는지 예측하는 것이 매우 어렵기 때문이기도 합니다. Elice 리서치 팀에서도 프로그래밍 코드에 대한 분석을 자동으로 수행하는 머신러닝 연구를 수행하고 있습니다. 이러한 기술을 통해 선생님이나 조교가 학생을 더욱 효율적으로 지도하고, 컴퓨터의 도움으로 지도에 아낀 시간을 한 단계 더 개인화된 도움을 주도록 하는 것이 Elice의 목표 중 하나 입니다.글쓴이김수인: KAIST 전산학부 박사과정 / Research Lead, Elice김재원: KAIST 전산학부 박사과정 / The Lead, Elice배휘동: KAIST 전산학부 박사과정 / Frontend Lead, Elice#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개
조회수 5152

REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁

최근의 서비스/애플리케이션의 개발 흐름은 멀티 플랫폼, 멀티 디바이스 시대로 넘어와 있습니다. 단순히 하나의 브라우저만 지원하면 되었던 이전과는 달리, 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응해야 합니다. 그렇기 때문에 매번 서버를 새로 만드는 수고를 들이지 않기 위해선 범용적인 사용성을 보장하는 서버 디자인이 필요합니다.REST 아키텍처는 Hypermedia API의 기본을 충실히 이행하여 만들고자 하는 시스템의 디자인 기준을 명확히 확립하고 범용성을 보장하게 해줍니다. 이번 글에선 현대 서비스 디자인을 RESTful하게 설계하는 기초적인 내용에 대해 정리하려고 합니다.REST란 무엇인가?REST는 Representational state transfer의 약자로, 월드와이드웹과 같은 분산 하이퍼미디어 시스템에서 운영되는 소프트웨어 아키텍처스타일입니다. 2000년에 Roy Fielding에 의해 처음 용어가 사용되었는데, 이 분은 HTTP/1.0, 1.1 스펙 작성에 참여했었고 아파치 HTTP 서버 프로젝트의 공동설립자이기도 합니다.REST는 HTTP/1.1 스펙과 동시에 만들어졌는데, HTTP 프로토콜을 정확히 의도에 맞게 활용하여 디자인하게 유도하고 있기 때문에 디자인 기준이 명확해지며, 의미적인 범용성을 지니므로 중간 계층의 컴포넌트들이 서비스를 최적화하는 데 도움이 됩니다. REST의 기본 원칙을 성실히 지킨 서비스 디자인은 “RESTful 하다.” 라고 흔히 표현합니다.무엇보다 이렇게 잘 디자인된 API는 서비스가 여러 플랫폼을 지원해야 할 때, 혹은 API로서 공개되어야 할 때, 설명을 간결하게 해주며 여러 가지 문제 상황을 지혜롭게 해결하기 때문에 (버전, 포맷/언어 선택과 같은) REST는 최근의 모바일, 웹 서비스 아키텍처로서 아주 중요한 역할을 하고 있습니다.중심 규칙REST에서 가장 중요하며 기본적인 규칙은 아래 두 가지입니다.URI는 정보의 자원을 표현해야 한다.자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.1번 사용자에 대해 정보를 받아야 할 때를 예를 들면, 아래와 같은 방법은 좋지 않습니다.GET /users/show/1 이와 같은 URI 방식은 REST를 제대로 적용하지 않은 구 버전의 Rails에서 흔히 볼 수 있는 URL입니다. 이 URI은 자원을 표현해야 하는 URI에 /show/ 같은 불필요한 표현이 들어가 있기 때문에 적절하지 않습니다. 본다는 것은 GET이라는 HTTP Method로 충분히 표현할 수 있기 때문이죠. 최근의 Rails는 아래와 같이 변경되었습니다.GET /users/1 자원은 크게 Collection과 Element로 나누어 표현할 수 있으며, 아래 테이블에 기초한다면 서버 대부분과의 통신 행태를 표현할 수 있습니다.ResourceGETPUTPOSTDELETERESTful Web Service HTTP methodsCollection URI, such as http://example.com/resources/컬렉션에 속한 자원들의 URI나 그 상세사항의 목록을 보여준다.전체 컬렉션은 다른 컬렉션으로 교체한다.해당 컬렉션에 속하는 새로운 자원을 생성한다. 자원의 URI는 시스템에 의해 할당된다.전체 컬렉션을 삭제한다.Element URI, such as http://example.com/resources/item17요청한 컬렉션 내 자원을 반환한다.해당 자원을 수정한다.해당 자원에 귀속되는 새로운 자원을 생성한다.해당 컬렉션내 자원을 삭제한다.이 외에도 PATCH 라는 HTTP Method에도 주목하시기 바랍니다. PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있습니다. Rails도 4.0부터 PATCH가 update 이벤트의 기본 Method로 사용될 것이라 예고하고 있습니다.입력 Form은 어떻게 받아오게 하지?위의 예시를 통해 많은 행태를 표현할 수 있습니다만 새로운 아이템을 작성하거나 기존의 아이템을 수정할 때 작성/수정 Form은 어떻게 제공할지에 대한 의문을 초기에 많이 가집니다.정답은 Form 자체도 정보로 취급해야 한다는 것입니다. 서버로부터 “새로운 아이템을 작성하기 위한 Form을 GET한다”고 생각하시면 됩니다. Rails 에선 기본적인 CRUD를 제공할 때 아래와 같은 REST 인터페이스를 구성해줍니다.HTTPVerbPathactionused forGET/photosindexdisplay a list of all photosGET/photos/newnewreturn an HTML form for creating a new photoPOST/photoscreatecreate a new photoGET/photos/:idshowdisplay a specific photoGET/photos/:id/editeditreturn an HTML form for editing a photoPUT/photos/:idupdateupdate a specific photoDELETE/photos/:iddestroydelete a specific photo모바일 환경에 따라 다른 정보를 보여줘야 한다면?접속하는 환경에 따라 다른 정보를 보여줘야 할 때가 있습니다. 가령 모바일 디바이스에서 볼 때 다른 사용자 인터페이스를 제공한다든지 하는 경우인데요. 일부 애플리케이션은 독립적인 모바일 웹서비스를 개발한 후 단지 이를 이동시켜주기만 할 때가 있는데, 이는 어떤 경우에 좋지 못한 사용성을 보여줍니다. 모바일 뷰와 일반 웹페이지 뷰의 URI가 달라서 같은 정보를 공유할 때 각 환경에 적절한 디자인과 인터페이스로 보이지 않기 때문입니다.모바일에서 블로그를 구경하던 도중, 컴퓨터를 이용하고 있는 친구에게 자신이 보고 있는 내용을 보내주고 싶을 때가 있습니다. 티스토리 블로그는 모바일 뷰의 URI가 기존 URI와 달라서, 친구가 해당 URI를 데스크탑에서 열어도 모바일에 최적화된 정보를 받을 수밖에 없게 됩니다. 이 URI를 데스크탑에서 열어보시기 바랍니다.REST 하게 만든다면 URI는 플랫폼 중립적이어야 하며, 정보를 보여줄 때 여러 플랫폼을 구별해야 한다면 Request Header의 User-Agent 값을 참조하는 것이 좋습니다. 예를 들어 iPhone에서 보내주는 User-Agent 값은 아래와 같습니다.Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 대부분 브라우저, OS 플랫폼은 HTTP Request를 보낼 시 보내는 주체에 대한 설명을 User-Agent에 상세하게 포함하여 통신하고 있기 때문에 요청자의 환경을 정확히 알 수 있습니다.버전과 정보 포맷을 지정할 수 있게 해야 한다면?오픈 API를 제공하거나, 클라이언트가 항상 최신 버전을 유지할 수 없는 환경이라면 서버에서 버전 협상을 지원해야 합니다. 서버가 버전 협상을 지원한다면 최신 버전으로 업데이트가 되더라도 구 버전의 정보 요청에 하위 호환하게 하여 서비스 적용범위를 넓게 유지할 수 있습니다. 이와 함께 클라이언트가 html로 정보를 받을지, json으로 받을지, xml로 받을지 선택할 수 있다면 더욱 좋을 것입니다.Header의 Accept 헤더를 이용해서 요청 환경에서 정보의 버전과 포맷을 지정할 수 있게 합니다. 아래는 Github API에 요청 시 쓰는 Accept 헤더입니다.application/vnd.github+json vnd.는 Vendor MIME Type으로, 서비스 개발자가 자신의 독자적인 포맷을 규정할 수 있게 HTTP 표준에서 제공하는 접두어입니다. vnd. 이후에 서비스 제공자 이름을 쓴 후, +로 문서의 기본 포맷을 표현해줍니다.이에 더해, Accept 헤더는 파라미터를 받을 수 있습니다. 많은 REST 지지자들은 이 파라미터를 이용해 버전 명을 지정하는 것을 권장합니다.vnd.example-com.foo+json; version=1.0 Ajax와 REST최근 빠른 속도의 웹서비스를 구현하기 위해 서비스 전체를 Ajax 통신으로 구동되게끔 HTML5 애플리케이션을 만드는 일이 많습니다. 서비스 전체를 Ajax 기반으로 구동되게 개발한다면 중복된 콘텐츠를 여러 번 전달하지 않아도 되고, 브라우저 렌더링 과정이 간소화되므로 더욱 빠른 서비스를 구축할 수 있습니다. 하지만 Ajax 기반의 서비스는 초기에 URL에 관련된 문제가 있어 REST한 서비스를 만들 때 애로사항이 있었습니다. 콘텐츠가 바뀌어도 URL은 그대로여서 친구에게 내가 보고 있는 콘텐츠를 보여줄 방법이 불편했기 때문이죠.최근엔 두 가지 방법으로 이를 보완할 수 있습니다. 첫 번째는 #! 기법으로, 구형 브라우저에서도 # 이하의 URL을 Javascript로 자유자재로 변경할 수 있다는 점을 이용한 방법입니다. 방법은 아래와 같습니다.Ajax 통신을 통해 이동되는 페이지의 URI는 현재 URI의 #! 이후에 붙인다.페이지가 처음 열릴 때, #! 이후로 URI가 붙어있다면 해당 URI로 redirect를 해준다.이와 같은 방법으로 Ajax 서비스를 만들면, 페이지를 이동한 이후에 URL을 친구에게 복사해서 전달해주어도 친구가 내가 보고 있는 콘텐츠를 볼 수 있으며, 구글에서 수집할 때 해당 #! 이하의 URL을 판별해서 제대로 수집해주기 때문에 검색엔진에도 성공적으로 노출될 수 있습니다.하지만 위 방법의 단점은 1. 상대방이 Javascript를 지원하지 않는 브라우저를 이용하거나 Javascript 기능을 꺼 놓았을 때 제대로 된 콘텐츠를 볼 수 없다는 것이며, 2. URI가 몹시 보기 지저분해진다는 것입니다. 두 번째 방법은 pushState라는 새로운 표준을 이용한 방법으로, javascript의 pushState를 통해 Ajax 통신 후에 변경된 컨텐츠의 URI을 제대로 바꿔줄 수 있습니다. 하지만 최신 표준을 지원하는 브라우저에서만 정상적으로 구동되기 때문에, 하위 호환에 신경을 써야 한다는 단점이 있습니다. pjax같은 프로젝트들이 하위 호환을 포함하여 이런 구현을 쉽게 하도록 도와주고 있습니다.언어언어별로 다른 URI의 서비스를 가지는 서비스들을 종종 볼 수 있습니다. 역시 좋지 못한 설계입니다. 한국어로 작성된 컨텐츠를 보고 있는 중 해당 콘텐츠를 미국인 친구에게 보여줄 일이 생겼다고 가정해봅시다. 단순히 URI를 복사해서 주는 것으로는 미국인 친구에게 내가 보고 있는 정보를 제대로 전달해줄 수 없다면 아주 불편할 것입니다.Request Header의 Accept-Language는 받고자 하는 언어를 명시하고 있습니다. 대부분 브라우저, OS 플랫폼은 사용자가 즐겨 쓰는 언어를 이 Header에 포함하여 요청을 만들고 있기 때문에, 해당 Header를 참조하여 그에 걸맞은 언어를 제공해주는 것이 가장 정확한 서비스를 제공해줄 수 있습니다.물론 이 방법만으로 부족한 점이 있습니다. 자신의 주 언어와 다른 언어의 세팅을 가지고 서비스를 이용하는 사용자도 있으며, 몇 가지 이유 때문에 해당 사이트만, 해당 순간에만 다른 언어로 정해서 보고 싶을 수 있기 때문입니다. 아쉽게도 일반적인 브라우저에서 언어 변경을 하는 인터페이스는 매우 불편하고 찾기 어렵게 되어있기 때문에, 서비스에서 이에 대한 추가 인터페이스를 제공해주지 않으면 일부 사용자를 잃거나 불편하게 할 수 있습니다. 보통은 Accept-Language보다 우선해서 적용하는 언어 옵션을 세션에 저장할 수 있게 하고, 이에 대한 변경 인터페이스를 서비스에서 제공해주는 식으로 문제를 해결할 수 있습니다.마치며REST는 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해주고, HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줍니다. 이번 글에서는 REST하지 않은 서버 설계를 통해 생길 수 있는 실질적인 문제들을 제시하고 REST 아키텍처가 이를 어떻게 해결해주는지 함께 보았습니다.‘REST가 완전한 정답이냐?’라고 한다면 이에 대해서는 아직 논의가 남아있습니다. 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 분명히 있으며 (PUT, DELETE를 사용하지 못하는 점, pushState를 지원하지 않는 점) 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값은 왠지 더 어렵게 느껴지기도 합니다.만일, 만들고 있는 서비스의 API가 널리 쓰여야 한다면 REST를 완전하게 적용한 디자인이 더 독이 될 수 있습니다. 많은 개발자는 별로 똑똑하지 못하며, HTTP 프로토콜에 대한 이해가 부족하여서 API가 어렵게 느껴질 수 있기 때문입니다. 그러므로 Google을 포함한 많은 기업의 서비스 API가 REST 스타일을 완전히 따르고 있진 않습니다.하지만 그럼에도 REST가 중요한 점은, 이를 제대로 구현하는 것이 서비스 디자인에 큰 부가이익을 가져다 줄 수 있으며, 많은 현대의 API들이 REST를 어느 정도로 충실하게 반영하느냐를 고민할 뿐이지 REST를 중심으로 디자인되고 있다는 점은 분명하기 때문입니다. REST를 얼마나 반영할 지는 API가 어떤 개발자를 범위에 두는지, 개발 기간이 얼마나 되는지, 함께 하는 동료의 역량은 어떠한지 등을 고려해서 집단마다 다르게 반영하게 될 것입니다.#스포카 #개발 #개발자 #개발팀 #꿀팁 #인사이트 #REST
조회수 5823

개발자 직군 파헤치기 1 | 프론트(Front), 백(Back), 풀스택(Full-Stack) 개발자

수많은 개발자 직군들개발자가 되기 위해서는 프로그래밍 언어만 배운다고 끝나는 것이 아닙니다. 자신이 배운 언어를 가지고 어떤 개발자가 될지 고민도 해야합니다. 실제로, 많은 분들이 내가 어떤 분야의 개발자가 되야 할지 고민을 많이 합니다. 그런데 이 고민에 앞서 어떤 개발자의 종류가 있고 직군이 있는지를 살펴보아야 합니다. 그래서 이번에 준비한 연재는 개발자 직군 파헤치기 시리즈입니다. 우리가 개발의 한 직군이라고 부를 수 있는 것들 중 관심이 많이 가는 직군들을 위주로 알아볼 것입니다. 일하는 분야에 대한 직군(게임 개발자)에 대한 이야기도 할 것이고, 지금 이야기할 프론트-엔드, 백-엔드처럼 개발의 영역에 대한 이야기도 할 것입니다. 다양한 관점에서 개발자의 영역들을 살펴볼 것입니다. 자, 그럼 지금부터 시작해 보죠!(※이 글은 유다시티 3Web Dev Careers Decoded: Front-End vs Back-End vs Full Stack을 번역한 것입니다.Front, Back and Full Stack우리가 매일같이 인터넷을 사용하는 과정을 떠올려봅시다. 새 브라우저 탭을 열고 URL을 입력 한 다음 Enter 키를 누르면 그 즉시 사이트가 로딩이 됩니다. 깔끔한 레이아웃, 잘 구성된 페이지, 그리고 화려한 시각적 효과들은 때로 감탄을 자아내죠.순식간에 일어난 이 모든 경험을 담당하는 사람들이 바로 웹 개발자들입니다.2018 년 4 월 현재 인터넷에 있는 페이지의 수는 45 억개가 넘습니다.  지금 이 순간에도 그 수는 계속 늘어나고 있습니다. 누군가 안정적인 직업을 찾고 싶다면 웹 사이트의 코딩, 설계, 분석 및 유지 관리를 담당하는 사람들, 곧 웹 개발자들을 찾아야 할 것입니다.웹 사이트는 이제 모든 비즈니스가 경쟁력을 유지하는 데 중요한 구성 요소입니다. 웹 개발의 트렌드와개발의 패러다임이 거의 매 시즌마다 바뀌는 상황에서, 개발자에 대한 수요는 부족함이 없습니다.그러나 웹 개발자의 범위는 매우 넓기 때문에 정확히 어떤 종류의 웹 개발자 채용 공고를 찾아보아야 하고, 그러한 개발자가 되기 위해 무슨 교육을 받아야 하는지를 판단하기는 쉽지 않습니다.  만약 구직 사이트를 둘러 보거나 온라인 강좌를 알아본 경험이 있다면, 프론트엔드, 백엔드, 그리고 풀스택 개발자라는 용어를 한번쯤은 들어보았을 것입니다.HTML, 자바 스크립트 또는 약간의 파이썬을 사용해 본 적이 있지만, 막상 개발자 직군에 대해서는 막막했다면 이 글이 매우 유용할 것입니다. Photo by Annie Spratt on UnsplashFront-End Developer프론트엔드는 웹사이트 중 사용자가 직접 상호작용을 하게 되는 부분입니다. 글꼴 부터 색상, 드롭 다운 메뉴 및 슬라이더에 이르기까지 인터넷에서 보게 되는 모든 것들은 브라우저의 제어를 받는 HTML, CSS 및 JavaScript의 조합입니다.SKILLS AND TOOLS프런트엔드 개발자는 웹 사이트에서 사용자가 직접 경험하는 부분과 그 경험의 아키텍처를 담당합니다. 이를 위해 프론트엔드 개발자는 HTML, CSS, Javascript 활용에 능숙해야합니다. 언어를 잘 다루는 것 외에도 프런트 엔드 개발자는 사용자의 도구에 따라 유연한 방식으로 컨텐츠를 보여줄 수 있게 하는 Bootstrap, Foundation, Backbone, AngularJS, EmberJS와 같은 프레임워크에 익숙해야합니다. 또한 jQuery, LESS와 같은 라이브러리를 사용할 수 있다면 더욱 유용하고 효율적인 코드를 작성할 수 있게됩니다. 프론트엔드 개발자를 채용할 때에는 Ajax 사용 경험을 요구하는 경우도 많습니다. 백그라운드에서 서버 데이터를 가져와 페이지를 동적으로 만드는 Javascript를 활용하는 데 있어서 Ajax는 보편적으로 사용되는 기술이기 때문입니다.프런트 엔드 개발자는 백엔드 개발자가 만든 집의내부 디자인을 담당합니다.프론트엔드 개발자는 이러한 기술을 사용하면서도, 목업(mockup) 혹은 와이어프레임(wireframe)의 개발에서 전달의 단계까지 디자이너 또는 사용자 경험 분석가와 긴밀히 협력합니다. 실력 있는 프론트엔드 개발자는 사용자 경험에서의 문제를 정확하게 발견하고, 디자인을 수정에 관한 조언과 문제 해결을 위한 코드를 제공합니다. 또한 목표와 필요, 기회들을 정확히 이해하고 수행하기 위해서는 다른 팀들과 유연하게 협력하는 능력이 중요합니다. 이처럼 프론트엔드 개발자의 작업은 여러 영역에 대한 책임을 동시에 감당하는 일이면서도 그만큼의 보람이 따라오는 것이기도 합니다. 8 년차 프론트엔드 개발자 인 Mikey Ilagan은 아래와 같은 이야기를 합니다.저는 기술적인 사람이면서도 시각적인 사람입니다.그래서 저는 자연스럽게 목업과 코드를 동시에 다루며 사람들이디지털 플랫폼과 상호작용하는 방식을 만들어 낼 수 있게 되었습니다.-Mikey Ilagan-종합해보자면, 프론트엔드 개발자는 백엔드 개발자가 만든 집의 내부 설계를 담당합니다. 집을 장식하는취향과 스타일은 집주인이 결정합니다. Apptix의 제품 마케팅 디렉터인 Greg Matranga는 "프론트엔드에서 작업하는 개발자는 자신의 창의성을 실질적으로 작업에 반영할 수 있기 때문에 때로는 자신이 하는 일에 대해 더욱 흥분한다"며 자신이 관리하는 프론트엔드 및 백엔드 개발자 팀 모두에게 말하기도 했습니다.HOW IT TRANSLATES지금 이 블로그에서 보고있는 모든 것은 프론트엔드 개발자의 손을 타지 않은 곳이 없습니다. 물론 로고와 그래픽은 디자이너가 만들고, 사진은 자신 작가가 찍었으며, 텍스트는 지금 글을 쓰고 있는 제가 작성합니다. 그러나 이 모든 조각들을 모아 웹으로 만들고, 각 페이지마다 사용자가 경험할 것을 설계한 것은 프론트엔드 개발자입니다.Photo by Lee Campbell on UnsplashBack-End Developer프론트엔드에서 일어나는 일을 이해했다면, 그것만으로는 웹사이트가 완성되지 않는 다는 것 역시 이해했을 것입니다. 그렇다면 프론트엔드 자체를 가능하게 만드는 것은 무엇일까? 데이터는 어디에 저장되는 것일까? 바로 백엔드입니다. 웹 사이트의 백엔드는 서버, 응용 프로그램 및 데이터베이스로 구성됩니다. 백 엔드 개발자는 이러한 구성요소들이 작동할 수 있게하는 기술을 만들고 유지하는 일을 합니다. 이러한 작업을 통해 비로소 사용자에게 보여지는 측면이 존재할 수 있게 됩니다.SKILLS AND TOOLS서버, 응용 프로그램, 데이터베이스가 서로 통신 할 수 있도록 만들기 위해 백엔드 개발자는 PHP, Ruby, Python, Java, .Net과 같은 서버 측 언어를 활용하여 응용 프로그램을 만듭니다. 또한 데이터를 검색, 저장 또는 변경하고 이를 프론트엔드 코드로 사용자에게 다시 제공하기 위해서는 MySQL, Oracle 및 SQL Server를 사용합니다. 백엔드 개발자에 관한 채용 공고는 그 외에도 1) Zend, Symfony 및 CakePHP와 같은 PHP 프레임 워크에 대한 경험, 2) SVN, CVS 또는 Git과 같은 버전 제어 소프트웨어 사용 경험, 3) 개발 및 배포 시스템으로서의 Linux 사용 경험을 요구하는 경우가 있습니다.백엔드 개발자는 이러한 도구를 사용하여 깔끔하고 모듈화가 가능한 코드로 웹 응용 프로그램을 만듭니다. 그러나 이와 같이 코드를 작성하기 전에 백엔드 개발자는 비즈니스 이해 관계자와 소통하면서 구체적인 요청 사항을 파악해야 합니다. 그런 다음 이를 기술적 내용으로 변환하여 기술 설계를 위한 가장 효과적이고 효율적인 솔루션을 제시할 수 있어야 합니다.나는 데이터를 다루는 것을 좋아하기 때문에항상 백엔드 개발을 선호 해 왔습니다.-JP Toto-오랫동안 백 엔드 개발자였던 JP Toto는 현재 와일 비트의 소프트웨어 개발자입니다. 그는 "최근 공개 및 비공개 API는 모바일, 웹 사이트를 포함한 여러 시스템간에 데이터를 교환하는 데 필수적인 부분이되었으며, 사람들이 유용하다고 생각하는 API를 만드는 것은 그에게 큰 만족감을 주는 일 중에 하나"라고 말한다.HOW IT TRANSLATES여러분이 코드스테이츠의 웹사이트를 찾아 들어오는 과정을 봅시다.  웹사이트의 서버는 여러분의 컴퓨터 또는 모바일로 정보를 보내고, 그 정보는 코드스테이츠 소개가 담긴 페이지로 보여집니다. 이 프로세스는 백엔드 개발자의 작업 결과입니다. 또한 회원가입을 할 때 저장되는 개인정보, 그리고 로그인을 할 때마다 각 계정의 정보가 불러와지는 과정 역시 백엔드 개발자 덕분입니다.Full Stack Developer프론트엔드 개발과 백엔드 개발 간에는 흑백 구분이 없는 경우가 종종 있습니다. 프론트엔드 개발자는 종종 추가 백엔드 기술을 습득해야하며 그 반대의 경우도 있습니다. 개발자는 여러 분야를 넘나들어야 할 때가 많아 종종 제너럴리스트가 되어야 합니다.  풀스택 개발자라는 역할은 7년 전 페이스북의 엔지니어링 부서에서 대중화되었습니다. 풀스택 개발자라는 호칭은 프론트엔드와 백엔드 모두에서 교차적으로 작업 할 수 있는 역할을 지칭하는 것에서 시작했습니다. 말 그대로 풀패키지(full package)를 제공하는 개발자라는 뜻입니다.서버와 클라이언트 측 모두에서 작업할 있는 전문성은더 많은 기회를 열어줍니다.-Federico Ulfo-Grovo의 풀스택 개발자인 Federico Ulfo는 이를 음식에 비유에 이야기합니다. "요리와 베이킹 중에 하나를 잘할 수는 있습니다. 그러나 두 가지를 모두 마스터하는 데에는 시간과 경험이 필요합니다. 마스터 한다는 것은 단지 레시피를 따라서 만드는 것을 말하는 게 아닙니다. 그건 누구든지 할 수 있습니다. 마스터 한다는 것은 직접 재료를 고르고 자신의 레시피로 훌륭한 음식을 만들어내는 것입니다."Photo by freestocks.org on UnsplashSKILLS AND TOOLS풀스택 개발자는 백엔드 개발자와 마찬가지로 웹 프로그래밍의 서버 측에서 작업하지만, 이와 동시에 사용자 측에서 콘텐츠가 보여지는 방법에 관해 프론트엔드의 언어로 능숙하게 소통할 수 있습니다. 아래의 이미지는 풀스택 개발이 얼마나 복잡해지고 있는지를 체감하게 해줍니다. 몇년 전까지만 해도 3-4가지의 기술의 종합으로 표현될 수 있었던 풀스택은 현재 7개의 기술이 종합된 형태로 훨씬 복잡해졌음을 알 수 있습니다.출처: Techrunch출처: Techrunch구체적인 기술의 종류는 프로젝트나 클라이언트에 따라 달라질 수 있지만, 풀스택 개발자는 기술의 종류와 상관없이 Linux 서버의 설정과 구성, 서버 측 API 작성, 클라이언트 측 JavaScript, 디자인을 맡는 CSS 등 웹이 작동하는 모든 차원에 있어서 해박해야합니다.풀스택 개발자는 이러한 기술들을 사용하여 클라이언트 측과 서버 측이 담당할 영역을 즉각적으로 구분해내고, 다양한 솔루션들의 장단점을 명확히할 수 있어야 합니다. HOW IT TRANSLATES풀스택 개발자는 로딩 시간부터 레이아웃, 그리고 사용자와의 상호작용성과 구조적 토대에 이르기까지이 게시물이 주는 경험의 전체적인 흐름을 책임집니다.The Bottom Line웹 개발에는 많은 면모가 있습니다. 그러나 당신이 어떠한 개발자가 되고 싶든지 디테일에 주의를 기울이는 능력, 빠르게 학습할 수있는 능력, 문제를 효율적으로 해결하는 능력, 그리고 커뮤니케이션 능력은 당신을 돋보이게 만들것입니다. 다행히 웹 개발 분야에서 경력을 쌓기 위해 이보다 더 좋은 시기는 없습니다. 웹 개발자의 고용은 2014 년에서 2024 년까지 10 년 동안 27 % 증가 할 것으로 예상되며 이는 모든 직종의 평균보다 빠릅니다. 지금까지 Front, Back, Full Stack 개발자에 대해서 알아보았습니다.다음 포스팅은 개발의 한 축을 담당하고 있기는 하지만 일반 개발 분와야는 다른 '게임 개발자'에 대해서 알아보도록 하겠습니다.
조회수 1493

HBase 설정 최적화하기 - VCNC Engineering Blog

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다. hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다. HBASE_HEAPSIZE = 61440 #(60GB) HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.
조회수 1683

프론트엔드 개발자라면!

Angular의 A마크를 알아본 프론트엔드 개발자님!이 글은 새로운 플랫폼을 개발하고 있는 타운컴퍼니 개발팀으로 당신을 모셔보려는 글이에요.이들이 당신과 함께 일하고 싶은 동료입니다..타운컴퍼니팀은 알고 있습니다.잘 만들어진 편리한 앱과 고객의 이탈률이 얼마나 밀접한 관계가 있는가를요.1%의 스타트업에는 1% 개발자가 필요하며 그들이 1%의 플랫폼을 만든다는 것을요.자율적이며 열정이 넘치는 팀으로 즐겁게 높은 수준의 개발을 할 수 있는 환경이죠!당신에게 즐거운 회사, 좋은 동료가 되어 줄 수 있습니다.급여는 협의 후 결정이니 원하는걸 말해봐요!좋은 동료를 얻을 수 있다면 그정도가 어렵겠어요 ; )우리는 현재 플랫폼(townus.co.kr)이 많이 부족하다는걸 알고 있어요.그래서 완전 멋있게 새롭게 만들고 있는 중입니다 :)일단 우리는 협업툴 JIRA와 Confluence, Slack을 사용하고 있어요.우리팀은 Agile 칸반을 바탕으로 테스트 주도 개발, 코드 리뷰, 페어프로그래밍으로 프로젝트를 진행하고 있죠.도메인이 잘 분석된 명세서가 Confluence에 정리되어 있고 사용자를 위한 깊은 고민이 녹아있는 디자인이 Zeplin에 올라가고 있어요.- Back-End는 Django(DRF) 기반으로 개발되고 있고, AWS, Vagrant, Docker같은 기술을 사용해요.- Front-End는 Angular 5를 사용해서 개발하고 있고, Less, RxJS, Webpack 등의 기술을 사용하고 있어요.Angular 상용 프로젝트 개발 경험이 있다면 격하게 환영하며 모십니다. 리엑티브 프로그래밍, Ionic 경험이 있다면 더 좋구요!엥 이거 완전 나 아니냐!? 라는 생각이 들었다구요? 그렇다면 얼른 지원해야지 뭐해요!무엇보다 개발을 즐기고 오픈소스활동을 좋아하는 사람이라면,종종 맛있는것도 먹으면서 많은 대화를 나눌수 있지 않을까요? :>우리 개발자는 맥주제조도 할 줄 알거든요 (겁나 맛이 좋더라구요)물론 당신에 대해 알 수 있는 Github 주소와 이력서를 보내준다면 우리가 연락하기 더 쉬울거에요!아! 참고로 보충역 산업기능요원 편입도 가능하니 문의가 필요하다면 언제든 환영이에요!타운컴퍼니팀에게 연락하고 싶다면 02–561–0950 잊지말아요,hr@towncompany.co.kr로 메일 보내준다면 언제든 답변줄게요 :D#타운컴퍼니 #개발자 #채용 #팀빌딩 #조직문화
조회수 1032

테이블이냐, 컬렉션이냐, 그것이 문제로다!(KOR)

편집자 주 외래어 표기법에 따르면 ‘원어에서 띄어 쓴 말은 띄어 쓴 대로 한글 표기를 하되, 붙여 쓸 수도 있다.’고 규정하고 있다.(제3장 제1절 영어의 표기, 제10항과, 컴퓨터 전문어, 전기 전문어 등) 즉 ‘원칙’과 ‘허용’이 모두 가능하다는 의미다. 이를 바탕으로 여러 표기 용례를 참고한 결과, TableView는 ‘테이블뷰(원칙)’로 표기해야 하나, 본문에서는 독자의 가독성을 높이기 위해 ‘테이블 뷰(허용)’로 표기한다. 응용하여, CollectionView는 ‘컬렉션 뷰’로, TableViewCell은 ‘테이블 뷰 셀’ 등으로 띄어 쓴다. Overview앱에서 데이터를 사용자에게 보여줄 땐 여러 가지의 모습으로 나타납니다. 설정 앱처럼 목록으로 보여줄 때도 있고, 사진 앱처럼 그리드(grid) 형식으로 보여줄 때도 있습니다. 이처럼 데이터를 보여줄 때 많이 사용되는 뷰는 테이블 뷰(UITableView) 또는 컬렉션 뷰(UICollectionView)입니다. 각자 특징이 있기 때문에 앱의 성격에 따라 적절한 뷰를 사용해야 합니다. 왜냐하면 목록을 보여주는 디자인을 바꿀 때, 다시 개발해야 하는 수고를 덜 수 있기 때문입니다. 이번 글에선 각각의 뷰를 간략하게 알아보겠습니다. 목록 형식의 설정 앱과 그리드 형식의 사진 앱 스크린샷테이블 뷰(UITableView)단일 열에 배열된 행을 사용해 데이터를 표시하는 뷰입니다. 수직 스크롤만 가능하며, 테이블의 개별 항목을 구성하는 셀은 테이블 뷰 셀(UITableViewCell) 객체입니다. 테이블 뷰는 이 객체들을 이용해 테이블에 표시되는 행을 그립니다. 여러 행은 하나의 섹션 안에 구성될 수 있으며, 각 섹션은 헤더(header)와 푸터(footer)를 가질 수 있습니다. 섹션과 행은 인덱스 번호로 구별하는데, 번호는 0부터 시작합니다. 테이블 뷰는 plain과 grouped 스타일 중 한 가지의 스타일을 가질 수 있습니다. Plain 스타일은 보통 목록 스타일입니다. 섹션의 헤더와 푸터는 섹션 분리기(inline separators)로 표시되고 스크롤을 할 때 해당 섹션 안에 있는 콘텐츠 위에 나타납니다. Grouped 스타일은 시각적으로 뚜렷한 행 그룹을 표시하는 섹션이 있습니다. 섹션의 헤더와 푸터는 콘텐츠 위에 나타나지 않습니다. 아래와 같은 사진을 보시면 확연히 차이를 볼 수 있습니다. plain 스타일의 연락처 앱과 grouped 스타일의 설정 앱테이블 뷰의 많은 메소드들은 인덱스패스(NSIndexPath) 객체를 매개변수 또는 리턴 값으로 사용합니다. 테이블 뷰는 해당하는 행의 색인 인덱스와 섹션 인덱스 값을 가져올 수 있게 인덱스패스의 범주를 선언합니다. 또한 색인 인덱스와 섹션 인덱스 값을 가지고 인덱스패스를 만들 수 있습니다. 특히 여러 섹션이 있는 테이블 뷰는 섹션 인덱스 값이 반드시 있어야 행의 인덱스 번호로 구별할 수 있습니다.override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> AttractionTableViewCell {         // Table view cells are reused and should be dequeued using a cell identifier.         let cellIdentifier = "AttractionTableViewCell"              guard let cell = tableView.dequeueReusableCell(withIdentifier: cellIdentifier, for: indexPath) as? AttractionTableViewCell else {             fatalError("The dequeued cell is not an instance of AttractionTableViewCell.")         }                 let attraction = attractions[indexPath.row]                 cell.attractionLabel.text = "\(indexPath.row). \(attraction.nameWithDescription)"         cell.attractionImage.image = attraction.photo                 cell.attractionImage.tag = indexPath.row                 attraction.indexPath = indexPath                 ...                 return cell     } 위의 코드는 데이터 소스(data source) 메소드로, 테이블 뷰의 특정한 위치에 셀을 추가합니다. 다시 말해, 이 메소드는 테이블 뷰가 ‘표시할 새로운 셀이 필요할 때마다’ 특정 행에 노출할 정보가 있는 셀을 만들고 리턴하는 걸 말합니다. 매개변수로 필요한 셀 객체의 행을 가리키는 indexPath 값을 전달합니다. 그리고 indexPath의 row 값을 이용해서 attraction이라는 배열 인덱스로 활용하고, 셀에 표시할 정보들을 설정합니다. 여기서 attraction 배열은 관광 명소들의 정보들이 담고 있는 배열인데, 1행은 첫 번째로 저장한 관광 명소, 2행은 두 번째로 저장한 관광 명소 등 순서대로 설정하도록 indexPath.row 값을 이용하는 것입니다. indexPath의 row 값과 배열의 인덱스 값은 0부터 시작하기 때문입니다. 해당 예제는 섹션이 1인 경우이기 때문에 섹션 인덱스 값이 없지만, 섹션이 여러 개 있다면 반드시 섹션 인덱스 값을 이용해서 설정해야 합니다.테이블 뷰 객체는 데이터 소스(data source)와 델리게이트(delegate)가 필요합니다. 데이터 소스는 UITableViewDataSource 프로토콜을 구현해야 하고, 델리게이트는 UITableViewDelegate 프로토콜을 구현해야합니다. 데이터 소스는 테이블 뷰가 테이블을 만들 때 필요한 정보를 제공하고 테이블의 행이 추가, 삭제 또는 재정렬할 때 데이터 모델을 관리합니다. 델리게이트는 화면에 보이는 모습과 행동을 담당합니다. 예를 들어 표시할 행의 수, 사용자가 특정 행을 터치했을 때, 행의 재정렬 등과 같은 것입니다.override func numberOfSections(in tableView: UITableView) -> Int {         // #warning Incomplete implementation, return the number of sections         return 1     }      override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {         // #warning Incomplete implementation, return the number of rows         return attractions.count     } 위의 두 소스는 데이터 소스가 필수적으로 구현해야 하는 메소드입니다. 하나는 섹션의 개수를 리턴하고, 또 하나는 한 섹션 안에 있는 행의 개수를 리턴합니다.테이블 뷰는 수정 모드에서 행을 추가, 삭제, 재정렬할 수 있습니다. 각 행은 테이블 뷰 셀에 연관된 editingStyle에 따라서 추가, 삭제, 재정렬을 할 수 있는데, 예를 들어 editingStyle이 insert라면 추가하는 메소드를 실행하고, delete면 삭제하는 메소드를 실행합니다. 행의 showsReorderControl 속성이 true라면, 재정렬하는 메소드를 실행할 수 있습니다.// Override to support editing the table view.     override func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCellEditingStyle, forRowAt indexPath: IndexPath) {         if editingStyle == .delete {             // Delete the row from the data source             ...                 // delete rows and attractions and reload datas             attractions.remove(at: indexPath.row)             tableView.deleteRows(at: [indexPath], with: .middle)             tableView.reloadData()         } else if editingStyle == .insert {             // Create a new instance of the appropriate class, insert it into the array, and add a new row to the table view         }     } 위 소스는 editingStyle이 delete일 때 셀을 삭제하고 테이블 뷰를 다시 로드하는 기능을 구현한 것입니다.테이블 뷰를 만드는 가장 쉽고 권장하는 방법은 바로 스토리보드에서 테이블뷰컨트롤러(UITableViewController)를 이용해서 만드는 겁니다. 런타임에 테이블뷰컨트롤러는 테이블 뷰를 만들고 델리게이트와 데이터 소스를 자기 자신으로 할당합니다.컬렉션 뷰(UICollectionView)컬렉션 뷰는 테이블 뷰에서 할 수 있는 모든 것을 할 수 있습니다. 섹션을 가질 수 있고, 인덱스패스 값을 이용해서 셀을 구별합니다. 이 셀들은 컬렉션 뷰 셀(UICollectionViewCell)의 서브 클래스이며 데이터 소스(UICollectionViewDataSource)와 델리게이트(UICollectionViewDelegate)가 필요합니다. 셀을 추가, 삭제, 재정렬하는 기능도 구현할 수 있습니다. 그렇다면 컬렉션 뷰와 테이블 뷰를 구분하는 특징은 무엇일까요? 바로 레이아웃입니다. 컬렉션 뷰는 여러 개의 열과 행으로 셀을 표현할 수 있습니다. 예를 들어, 그리드(grid) 형태로 아이템의 목록을 보여줄 수 있습니다. 그래서 수직 스크롤뿐만 아니라 수평 스크롤도 할 수 있습니다.스토리보드에서 디자인한 테이블 뷰 셀과 컬렉션 뷰 셀위 스크린샷에서 테이블 뷰와 컬렉션 뷰의 가장 큰 차이는 바로 셀입니다. 테이블 뷰에서는 하나의 열에 여러 행을 표시하는 형식이기 때문에, 셀의 모습을 행에 맞춰서 디자인합니다. 하지만 컬렉션 뷰는 열과 행을 만들 수 있기 때문에, 꼭 행의 모습이 아니더라도 다양한 모습으로 셀을 디자인할 수 있습니다. 컬렉션 뷰 셀의 가장 큰 특징이기도 하죠. 위처럼 셀을 디자인하고 앱을 실행하면 아래의 화면이 나타납니다.테이블 뷰와 컬렉션 뷰의 앱 화면 차이또한 컬렉션 뷰는 레이아웃 객체가 있습니다. 기존에 제공하는 flow layout을 사용해도 괜찮지만, 본인이 원하는 레이아웃 모양을 custom layout을 만들어서 사용합니다. 이를 담당하는 프로토콜은 UICollectionViewDelegateFlowLayout 입니다.func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {         let fullWidth = collectionView.frame.size.width - (self.CGFLOAT_INSET_WIDTH * 3) - (self.CGFLOAT_ITEMSPACING * 3)         let width = fullWidth/3         return CGSize(width: width, height: width + self.CGFLOAT_HEIGHT_ATTRACTIONCELL_DEFAULT)     }         func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, insetForSectionAt section: Int) -> UIEdgeInsets {         return UIEdgeInsetsMake(self.CGFLOAT_LINESPACING_VERTICAL, self.CGFLOAT_INSET_WIDTH, self.CGFLOAT_LINESPACING_VERTICAL, self.CGFLOAT_INSET_WIDTH)     } 위 소스에서 collectionView(:layout:sizeForItemAt:) 메소드는 해당하는 셀의 사이즈를 설정하고, collectionView(:layout:insetForSectionAt:) 메소드는 섹션 안에 margin을 설정합니다.여러 모양의 셀을 이루어 하나의 뷰 화면을 구현할 수도 있습니다. 섹션마다 셀을 만들어 각각 다른 모습의 셀을 설정하고, 한 화면에 다양한 모습의 셀을 가진 뷰를 만드는 것입니다. 예를 들어, 헤더, 메뉴, 본문, 푸터 각각 셀을 만들어서 원하는 모양으로 만들고, 하나의 뷰 컨트롤러에 셀을 조합해서 한 화면에 나타나게 할 수 있습니다. 이 방법을 사용하면 자주 사용하는 셀을 재활용할 수 있습니다. 똑같은 헤더와 푸터 셀을 여러 번 만들지 않고 기존의 셀을 재활용하면 시간도 절약하고, 훨씬 깔끔한 소스를 만들 수 있을 겁니다.브랜디 앱 스크린샷 일부위의 스크린샷처럼 여러 화면에서 보여줘야 할 똑같은 뷰가 있을 때, 셀 xib 파일을 만들고 컬렉션 뷰에서 셀을 섹션별로 설정 및 사용하면 재활용하기 좋습니다.Conclusion지금까지 테이블 뷰와 컬렉션 뷰의 특징들을 살펴봤습니다. 한마디로 정리하면 테이블 뷰는 가장 간단한 목록을 만들 수 있습니다. 컬렉션 뷰는 다양한 모습의 목록으로 커스터마이징(Customizing)할 수 있습니다.그렇다면 우리는 어떤 것을 선택해야 할까요? 구현할 목록이 얼마나 복잡한지에 따라 선택은 달라집니다. 테이블 뷰는 간단하고 보편적인 목록을 만듭니다. 반면에 컬렉션 뷰는 특정한 모습의 목록을 만들 수 있습니다. 그래서 테이블 뷰는 목록이 간단하고 디자인 변경이 없을 때만 사용하길 권장합니다. 하지만 나중에 디자인이 바뀔 수도 있다면 컬렉션 뷰를 사용하는게 더 좋겠죠.Simple is the best! 간단하게 구현할 수 있는 건 테이블 뷰를 사용합시다. 테이블 뷰에서 구현하기 힘들다면 컬렉션 뷰를 이용해 개성 있는 목록을 마음껏 만들어봅시다!참고UITableView - UIKit | Apple Developer DocumentationUICollectionView - UIKit | Apple Developer Documentation 글김주희 사원 | R&D 개발1팀kimjh3@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1596

[인터뷰]미미박스의 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. 제가 여기 처음 와서 한 이야기가 있어요. "여기가 제 마지막 회사입니다."그렇게 이야기한 이유는 미미박스의 성장 가능성, 발전 가능성을 보았고 믿음이 있기 때문이죠. 모두가 같이 노력한다면 원하는 것을 이룰 수 있을 거라 생각해요. 다 같이 파이팅!
조회수 12400

Jekyll을 이용하여 github에 블로그 만들기

티스토리에서 여러 불편함들을 느껴 깃헙 블로그로 갈아타려고 한다. 자유도가 높아보여 티스토리에 블로그를 개설했으나 오히려 글이 노출되는 디자인이나 (줄간격, 글씨 크기 등등) 기존 테마를 변경하기에 불편했다. 결정적으로 gist 스크립트를 삽입했을 때 미리보기가 안돼서 고민 끝에 깃헙 블로그를 선택했다. 워드프레스도 개설해봤지만 왠지 모르게 마음에 안들어서 깃헙 블로그로 갈아타기로 마음먹었다. 그 후에 이것저것 알아보니 내 마음에 쏙 드는 요소들이 많았다.마음에 드는 부분git을 이용해 커밋, 푸시로 글을 포스팅함. 그 덕분에 블로그에 대한 모든게 로컬에 있고 모든 글들을 로컬에서 관리 할 수 있음.마크다운을 이용하여 글 작성. 글과 html을 마음대로 오갈 수 있어서 좋음. 마크다운 에디터가 없었다면 불편했겠지만 세상은 넓고 좋은 에디터는 많다..! 다만 이미지 삽입에서는 좀 불편.다른 웹 프로젝트처럼 웹스톰에서 블로그 관리 가능. 인텔리 제이를 사랑하는 나로서는 이 부분 또한 큰 장점.아무튼 이런 이유로 깃헙 블로그로 갈아타기로 결정. 구글링을 통해서 깃헙 블로그를 개설하는 방법에 대해 잘 정리해놓은 블로그를 찾았다. 놀부 블로그를 참고하여 깃헙 블로그를 개설했다. 아래에는 내가 보기 편하도록 더 간략하게 정리해보았다.깃헙 블로그 만들기 (Mac OS X)1. Jekyll 설치터미널에서 아래 명령어 입력으로 설치. $ sudo gem install jekyll2. 설치한 Jekyll을 이용하여 블로그 생성블로그를 만들고자 하는 위치에서 아래 명령어로 생성.$ jekyll new [github사용자명].github.com블로그 생성후 생성된 위치로 이동하여 아래의 명령어 실행 후 브라우저에서 http://localhost:4000으로 접속하면 로컬에 생성된 블로그를 볼 수 있음.$ jekyll serve --watch3. github에 온라인 저장소 만들기위에서 생성한 블로그 이름과 동일한 이름([github사용자명].github.com)으로 github에 온라인 저장소를 생성. 그 후 로컬에 있는 블로그와 만들어준 저장소를 remote 해주면 끝.$ git init$ git remote add origin [저장소URL]$ git add .$ git commit -m "Initialize Blog"$ git push origin master생성된 블로그는 http://[github사용자명].github.com으로 접속하면 볼 수 있다. 처음 생성하는 경우 몇 분의 시간이 걸리는 경우도 있다고 함.포스팅하기글은 _post 파일 안에 YYYY-MM-DD-[글 제목].markdown 형식으로 파일명을 지정하여 생성한 후 커밋, 푸시하면 업로드됨.테마 적용하기테마를 직접 만들기에는 시간이 너무 많이 소요되니 인터넷에 공유되어있는 테마를 사용하면 좋다. 테마를 적용하는 부분에서 여러모로 애를 먹었는데 제일 쉬운 방법은 테마가 올라가있는 저장소를 포크하여 [github사용자명].github.com으로 이름을 바꾸는게 제일 쉽다. 내 블로그는 심플한 테마를 적용하였다.다른 테마들은 Jekyll Themes 사이트에서 찾아볼 수 있다. 훨씬 이쁘고 좋은 테마들도 많음.Jeykll 더 알아보기Jeykll 공식 번역 사이트에서 몇 개의 문서를 읽어보면 더 다양하게 활용해 볼 수 있다. _config.yml파일이나 _post, _include, _layout 파일 정도는 기본으로 살펴보아야 함.#트레바리 #개발자 #안드로이드 #앱개발 #Jeykll #백엔드 #인사이트 #경험공유
조회수 1075

클라우드와 운영자의 불안함.

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

조건문을 긍정적으로!

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

CSS animation으로 프로토타이핑하기

들어가며Framer, Flinto, Origami, Invision. 많은 프로토타이핑 도구가 존재합니다. 디자인에 활력을 불어넣고 개발팀과의 커뮤니케이션을 위해 필수라고 하는 프로토타이핑. 어떻게 하기는 해야겠는 데 어려운 도구나 코드르 공부하기엔 시간이 없고, 막상 열심히 공부하면 새로운 버전이 나오고, 더 좋은 도구가 나오고. 이런 경험을 많이 하셨을 겁니다. 프로토타이핑 도구로 멋지고 완결된 시나리오를 가진 결과물을 만들 수도 있습니다. 하지만 우리에게 당장 필요한 것은 지금 당장 떠오르는 아이디어를 보여줄 수 있는 아이콘의 간단한 모션, 쓱 움직이는 화면 전환 같은 것이 아닐까요? 오늘 배워서 바로 쓸 수 있는 CSS animation으로 하는 간단한 프로토타이핑 방법을 소개합니다.https://codepen.io/yunkimoon/embed/preview/BZEYgY?default-tabs=css,result&embed-version=2&height=600&host=https://codepen.io&referrer=https://blog.stibee.com/media/c7c8adfdea76b3b98829ecce41fee7d7?postId=e5bb1630afb5&slug-hash=BZEYgY<iframe data-width="800" data-height="600" width="700" height="525" data-src="/media/c7c8adfdea76b3b98829ecce41fee7d7?postId=e5bb1630afb5" data-media-id="c7c8adfdea76b3b98829ecce41fee7d7" data-thumbnail="https://i.embed.ly/1/image?url=https://s3-us-west-2.amazonaws.com/i.cdpn.io/1370087.BZEYgY.small.f06b1cb1-09d2-4285-b8b5-eb8f5b9cea7a.png&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://blog.stibee.com/media/c7c8adfdea76b3b98829ecce41fee7d7?postId=e5bb1630afb5" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 525px;">어디서, playground코딩을 공부하려면 텍스트 에디터도 설치해야 하고, 각종 패키지도 설치해야 합니다. 또한, 결과물이 담길 파일도 생성해야 하고, 여러 파일이 연결되니까 폴더 구조도 고민해야 하죠. 이런 고민을 하다 보면 시작조차 하기 싫어집니다. 그래서 브라우저에서 바로 작성하고 확인하고 공유할 수 있는 온라인 코딩 플레이 그라운드가 있습니다. 대표적으로 jsbin과 codepen이 있습니다. 그냥 해당 서비스에서 가서 각 섹션(html 또는 css)에 맞게 코드를 입력하기만 하면 됩니다. 우리는 html과 css섹션만 사용할 예정입니다. js와 같은 다른 섹션은 최소화(minimize)해주세요.codepen.io어떻게 시작할까html에 내용을 담고, css에 디자인(스타일)을 담을 겁니다. 당장 직접 작성하기는 어려우니 예제(https://codepen.io/yunkimoon/pen/BZEYgY)의 html과 css코드를 그대로 복사합니다. 코드의 주석(회색글씨)을 확인해 봅니다. 요약하면 아래와 같습니다.가장 바깥의 파란 배경 상자이미지와 그걸 담고 있는 상자파란 배경 상자에 hover(마우스 오버 이벤트)를 하면,left 포지션을 2%에서 80%로 변경여기서 중요한 건 .box상자에 설정된 transition이라는 속성입니다. transition은 딱딱한 움직임을 부드럽게 해줍니다. 여기서는 position left를 2%에서 80%로 부드럽게 바꿔주었습니다. 위치뿐만 아니라 색상(color, background), 크기(width, height)도 자연스럽게 바꿔주는 속성입니다. “all 3s”라는 값을 가지고 있는데 “모든 변경사항에 대해 3초 동안 움직여라”라는 의미입니다.꼭 알아야할 3가지css 애니메이션의 맛을 잠깐 보았습니다. transition을 통해 부드러운 움직임을 줄 수 있습니다. 하지만 더 복잡하고 멋진 움직임을 위해서는 많은 속성들을 이해하고 응용할 수 있어야 합니다. 하지만 모든 속성을 다 알아볼 수는 없으므로 가장 중요한 3가지를 알아보도록 하겠습니다. 미리 살펴본 transition과 transform, keyframe(s) 입니다.1. transition위에서 살펴본 것처럼 대상의 위치, 크기, 색상 등에 부드러운 움직임을 줍니다.2. transform대상의 위치, 크기, 방향 등을 상대적으로 변경합니다. 예제를 통해 알아보겠습니다.<iframe data-width="800" data-height="600" width="700" height="525" data-src="/media/43617ca3eab01b6f86f50b25a362c5a1?postId=e5bb1630afb5" data-media-id="43617ca3eab01b6f86f50b25a362c5a1" data-thumbnail="https://i.embed.ly/1/image?url=https://s3-us-west-2.amazonaws.com/i.cdpn.io/1370087.BZErpP.small.5ebe332d-41b1-4a16-8253-6e2df7b347d0.png&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://blog.stibee.com/media/43617ca3eab01b6f86f50b25a362c5a1?postId=e5bb1630afb5" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 525px;">2.1. rotate대상에 각도 값을 설정합니다. 즉, 주어진 값만큼 회전합니다. 첫 번째 예제와 조금 다른 부분은 :hover { }에 작성된 내용입니다. transform:rotate(360deg)에서 rotate는 회전을 뜻하고, 360deg는 각도입니다. 즉, 360도(한 바퀴)만큼 회전하라는 의미입니다. 미리 transition이 걸려있었기 때문에 부드럽게 회전하는 모습을 볼 수 있습니다.2.2. translate대상의 이동 값을 설정합니다. 주어진 값만큼 이동합니다. 값은 좌푯값으로 x축, y축 값을 나눠서 줍니다. transform: translate(100px, 100px)에서 translate는 이동을 뜻하고, 이후에 나오는 값은 순서대로 x축의 이동값, y축의 이동 값입니다. 그런데 y축 이동 값이면 위로 올라가야 할 것 같은데, 그림은 아래로 이동합니다. 그 이유는 스크린에서 좌측 위가 기준점이기 때문입니다.2.3. scale대상의 크기를 설정합니다. 즉, 주어진 값만큼 늘어나거나 줄어듭니다. 값은 가로 값, 세로 값을 차례로 줍니다. transform:scale(1.5, 2)에서 scale은 크기를 뜻하고, 1.5와 2는 각각 가로값, 세로값을 뜻합니다. 가로는 1.5배가 늘어나고 세로는 2배가 늘어납니다. 그래서 그림은 세로로 긴 비율로 보입니다.이제 우리는 css만으로 대상의 위치, 크기, 회전 애니메이션을 줄 수 있습니다 :)3. keyframes마우스 오버 액션에 대한 애니메이션을 보아왔습니다. 이렇게 사용자의 특정 반응(마우스 오버)이 없어도 자동으로 움직이도록 할 수는 없을까요? 앞의 두 예제보다 조금 복잡하지만 keyframes를 사용하면 가능합니다. keyframes는 미리 움직임을 지정해두고, 대상에 해당 애니메이션의 속성을 부여하는 방식으로 작성됩니다. 예제를 확인해 보겠습니다.<iframe data-width="800" data-height="600" width="700" height="525" data-src="/media/fc6ef62f3a79def6442479e60dcba75d?postId=e5bb1630afb5" data-media-id="fc6ef62f3a79def6442479e60dcba75d" data-thumbnail="https://i.embed.ly/1/image?url=https://s3-us-west-2.amazonaws.com/i.cdpn.io/1370087.vZMRdd.small.22bea369-dda5-4454-9f16-f5ad68f9b292.png&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://blog.stibee.com/media/fc6ef62f3a79def6442479e60dcba75d?postId=e5bb1630afb5" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 525px;">3.1. spin앞서 살펴 본 transform의 rotate를 미리 애니메이션을 만들어 놓고 대상에 animation이라는 속성을 설정했습니다.@keyframes spin 처름 spin이라는 애니메이션을 설정합니다. 그 안에는 from과 to가 있는데 각각 시작과 끝을 뜻합니다. 즉, 시작할 때는 회전이 0(rotate(0deg))이고 끝날 때는 회전이 360도(rotate(360deg))입니다.대상과 keyframes를 연결할 때는 대상에 animation: spin 8s infinite linear;와같이 애니메이션 속성을 줍니다. spin은 keyframes의 이름, 8s는 8초 동안, infinite는 무한 반복을 뜻합니다. 여기서 linear는 easing을 나타내는데, 우선은 조금 딱딱한 애니메이션이라고 해둡시다.3.2. leftAndRighttransform의 translate를 활용해서 우측으로 이동했다 돌아오는 애니메이션을 반복시키는 예제입니다. from과 to대신 조금 상세한 타임라인을 가지고 있습니다. 0%, 50%, 100%는 타임라인을 구성하는 속성들로 전체 애니메이션 시간 동안 해당하는 타이밍에 맞게 속성이 변경됩니다. 역시 infinite 속성이 있어 계속 반복되고 있습니다. 그리고 마지막에 linear대신 ease라는 속성을 넣어서 조금 부드러운 움직임 표현했습니다.3.3. hideAndShow앞서 다루지 않은 opacity(투명도)를 활용했습니다. 1이 100%이고 0은 보이지 않는 상태입니다. 1 → 0 → 1을 반복하며 보였다 안 보였다 하는 애니메이션을 보여줍니다.이제 우리는 css만으로 대상의 위치, 크기, 회전 애니메이션 반복적으로 사용할 수 있게 되었습니다. 그리고 무한 반복 애니메이션도 만들 수 있습니다.마무리 예제<iframe data-width="800" data-height="600" width="700" height="525" data-src="/media/f95d4317209e7a3488242568bbdcd5a3?postId=e5bb1630afb5" data-media-id="f95d4317209e7a3488242568bbdcd5a3" data-thumbnail="https://i.embed.ly/1/image?url=https://s3-us-west-2.amazonaws.com/i.cdpn.io/1370087.OgeMEY.small.ab075079-b3bb-443e-a11e-d707c5a6a198.png&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://blog.stibee.com/media/f95d4317209e7a3488242568bbdcd5a3?postId=e5bb1630afb5" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 525px;">앞서 살펴본 예제들을 활용한 마무리 예제를 만들어 보았습니다. 앞서 공부한 내용을 바탕으로 소스를 분석해 보시기 바랍니다. 각 버튼에는 transiton으로 부드러운 hover 전환 효과를 주었고, 녹색의 메시지는 keyframes를 주어 상하로 계속 움직이도록 했습니다. frame에 마우스가 올라가면 메시지는 프레임 바깥으로 밀려나고 사용자 메뉴가 프레임 안으로 이동하도록 했습니다. 메뉴는 하위 메뉴가 펼쳐지는 인터렉션을 가지고 있습니다.마치며전문 프로토타이핑 도구보다 결과물이 투박하고, 지금 당장 만들 수 있는 장면도 제한적입니다. 자바스크립트 같은 동적 언어가 들어가 있지 않아 표현할 수 있는 화면도 많지 않습니다. 기본적으로 제공되는 템플릿이나 자원이 없으므로 하나하나 html로 코딩하거나 공개 소스를 넣어가면서 만들어야 하는 수고로움도 존재합니다.하지만 실행만 해도 막막한 도구들을 바라보며 “언제 한 번 해보나”하는 생각을 할 시간에 간단히 익혀 한 번이라도 써먹을 수 있다면 그 자체로 의미가 있지 않을까요? 물론 탄탄한 시나리오와 설계를 가지고, 제대로 만든다면 전문 프로토타이핑 도구보다 절대 뒤쳐지지 않을 것입니다. 그리고 우리가 만든 코드들은 커뮤니케이션을 위한 전달용이 아니고 실제로 쓰일 수도 있는 코드라는 점에서도 의미가 있습니다. 간단한 프로토타이핑이라도 지금 시작해 보면 어떨까요?참고https://www.w3schools.com/css/css3_animations.aspttps://www.w3schools.com/css/css3_transitions.asphttps://www.w3schools.com/css/css3_2dtransforms.asphttp://report.stibee.com/2017 by 조은지 디자이너#슬로워크 #스티비 #CSS #퍼블리셔 #개발 #디자인 #인사이트 #꿀팁 #조언
조회수 1456

박문수 이야기

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

기업문화 엿볼 때, 더팀스

로그인

/