스푼을 만드는 사람들 다섯 번째 이야기클라이언트팀의 유일한 여성 개발자 Julia를 소개하고자 한다.바나나 최대 몇 개까지 드세요?"마케팅팀 썸머에겐 아귀찜이 있다면, 저에겐 '바나나'입니다. 저는 바나나 우유도 좋아하고, 바나나 한 송이를 그 자리에서 혼자 다 먹을 만큼 좋아해요. 카카오톡 이모티콘도 바나나 이모티콘을 가장 많이 사용할 정도로요. 바나나는 맛도 있지만, 먹으면 기분이 좋아지는 과일이에요"(인터뷰 후, 줄리아에게 바나나 한 다발 선물해드렸습니다. 맛있게 드셨길 바라요)Q. 할머니 감성을 가지셨다고 들었는데, 사실인가요? "네, 모르시는 분들이 많으시겠지만 저는 친구들이 '할머니'라고 불러줘요. 이유인즉슨, 건강에 관심이 워낙 많아서 영양제도 잘 챙겨 먹고 꽃무늬 옷이 많거든요. 정확히 말하면 꽃무늬 치마! 그리고 사석에서는 고향(전라도) 사투리를 많이 써서 그런 것 같아요"줄리아 닮은꼴: 닥터 슬럼프 아리 '줄리아'를 더 알아가고 싶어요본인은 어떤 사람이라고 생각하세요?독한 사람 - 저는 웬만한 것에 있어서 타의적으로 절대 포기를 하지 않아요. 제 스스로가 싫증이 날 때까지는 꼭 끝까지 해내고 말거든요.그래서 전 제 스스로를 독한 사람이라고 말하고 싶어요. 이전부터 개발자로서 커리어를 쌓아오셨나요?"저는 원래 문과생이에요. 비전공자죠. 대학 때 독어를 전공했고, 개발과는 사실 거리가 먼 사람이었어요. 저는 이 전에 많은 경험들을 해왔어요. 세계일주를 하고 싶어서 해상 승무원 준비도 했었고, 중국에서 무역회사에서 근무도 했었고요. 통역도 잠시 했었고, 이 전에는 앱 공모전 기획자로서의 삶도 있었어요. 앱 공모전 기획자라는 건, 회사 및 대회를 홍보하기 위해 직원 대상 또는 시민을 대상으로 행사 및 공모전을 기획해서 행사업체를 고용하거나 직접 운영하는 업무랍니다. 그리고 현재는 안드로이드 개발자로 커리어를 쌓고 있습니다."많은 커리어를 거쳐 개발자가 되신 계기가 있다면?"저는 인생 계획을 짧으면 5년, 길게는 10년씩 잡고 살아가요. 20대 때는 해보고 싶은 게 너무 많았고, 지금도 여전히 많아요. 그래서 20대는 정말 하고 싶은 모든 걸 해보자라는 마음으로 살아왔어요. 30대가 되면서 조금 더 안정적으로 살고픈 마음이 생기기 시작했고 무엇보다 하나의 전문적인 직업을 가지고 싶단 욕구가 커졌어요. 그래서 개발을 선택하게 되었습니다."책상에 약이 굉장히 많네요?"제가 아까 할머니 감성이 있다고 했는데.. 저는 건강을 엄청 챙기거든요.. 그래서 탕비실에도 돼지감자 차 및 영양제 등 굉장히 뭘 많이 챙겨 먹습니다. 그래서 제 책상엔 비타민 등 영양제가 가득하답니다!"집에서 가져온다는 돼지감자 차 당신의 회사생활이 궁금합니다Q. 여성 개발자로 일하는 삶은 어떤가요?"사실 저는 '개발'을 하는 일을 성별로 나누고 싶지는 않아요. 남자 개발자가 많은 이유는 아무래도 공대에 남성 비율이 더 많기 때문이라고 생각이 들기도 하고, '여자' 이기에 특별히 다르다거나 불편한 점은 없어요. 아직은 신입 개발자이다 보니, 배우고 있는 시점이기도 하고요. 그저 열심히 배우는 단계라고 봐주시면 좋을 것 같습니다 :) 무엇보다 제 위로 8년 차, 14년 차 선배분들과 함께 일하면서 정말 많이 배우고 있습니다."Q. 일하면서 언제가 가장 뿌듯하세요?"개발을 하시는 분들은 공감하실 텐데.. 안되던 문제가 갑자기 될 때(?)에요. 분명히 어제는 안됐는데, 오늘은 되는 날이 있거든요. 반대인 경우도 있고요. 그때 정말 뿌듯(?)하고 행복해요. 또 다른 하나는, 보통 다른 곳은 신입 개발자는 보조만 하는 경우가 많거든요. 하지만 팀원들이 저를 믿어주셔서 제가 새로운 기능을 맡아서 짠 추가 코드가 프로덕트에 적용이 될 때가 정말 뿌듯해요."Q. 회사 다니면서 가장 기억에 남는 일이 있다면?"제가 입사 후 함께 처음으로 새로운 국가에 출시했을 때요. 저는 새로운 국가에 서비스를 출시할 때마다 너무 기대되고 업무가 더 즐거워져요. 조금 더 다양한 업무가 주어지고, 생각도 더 많이 하게 되거든요. 그리고 저는 건강에 정말 신경 많이 쓰는데, 저번에 Jun 이 막내 특집(?)으로 홍삼 음료를 주셨는데.. 너무 취향 저격인 거예요. 딱 제가 정말 좋아하는 건강한 맛! 그래서 그날도 너무 행복했어요."Q. 어떤 사람과 일하고 싶으세요?배울 점이 있는 사람이요. 저 또한 누군가에게 배울 점이 있는 사람이고 싶어요.줄리아 업무 공간 당신의 사생활이 궁금합니다Q. 안드로이드 개발자는 안드로이드만 사용하나요?"모두가 그런 건 아니겠지만, 저는 사실 여태 살면서 안드로이드 폰만 사용했었어요. 무엇보다 저는 안드로이드 캐릭터가 너무 귀엽다고 생각하기에.."Q. 주말에는 무엇을 하며 시간을 보내세요?"저는 지난 1년간은 매주 주말마다 코딩 스터디를 해왔어요. 아무래도 비전공자에 늦게 시작한 개발자다 보니 엄청난 노력이 필요하거든요. 지금도 스터디를 하고 있어요. 그리고 2019년부터 목표는 한 달에 한 번쯤은 리프레쉬하기 위해 가까운 곳이라도 여행을 가려고 노력하고 있어요."Q. 개발자가 된 후 삶에 있어 변한 점이 있다면?"예전에는 어떤 것을 설명하거나 표현할 때, 굉장히 문과적(?) 이게 표현을 했었던 것 같아요. 지금도 완전히 바뀌진 않았어요. 하지만, 무언가 문제가 있을 때 원인과 결과를 먼저 파악하는 성향이 생겼달까요? 그리고 편견일 수도 있지만 조금 더 프로페셔녈 해 보이고 싶어서 백팩이나 후디를 자주 입습니다!" 비전공자로서 개발자를 꿈꾸는 사람들에게 "먼저, 비전공자라 하여 못할 거라는 생각을 하지 않으셨으면 좋겠어요. 저도 여전히 배우고 있는 입장이지만 생각보다 비전공자 중에 개발자로서 훌륭하신 분이 굉장히 많거든요. 늦더라도 정말 하고 싶은 마음이 있다면 꼭 도전하라고 말하고 싶어요. 그리고 꼭 영어 공부하세요. 아무래도 문서들이 영어로 되어있으니, 영어를 배워두면 번역기의 도움이 없이도 되기에 큰 도움이 되고 시간이 절약되거든요! 아, 그리고 개발을 배우고자 만약 학원에 가서 수업을 들을 예정이시라면, 수업을 듣기 전에 혼자라도 미리 예습을 하고 가셨으면 좋겠어요. 학원을 다닌다고 해서 정말 모든 걸 알려주진 않거든요. 얼마나 열심히 하고 노력하느냐에 따라 성패가 달린다고 생각합니다."안드로이드 팀원들이 줄리아를 한마디로 표현한다면?Derek 曰:  “줄리아는 강한 사람이라고 생각합니다. 외부의 환경에 흔들리지 않고 자신의 꿈을 향해 계속 전진하는 강한 사람이라고 생각합니다.”Yong 曰:  "낯선 길에서 의지를 잃지 않고 가고자 하는 길을 걷는 사람, 그리고 미소가 예뻐서 꽃 같은 사람입니다" 

Summary:이 포스팅은 LSTM에 대한 기본 개념을 소개하고, tensorflow와 MNIST 데이터를 이용하여 구현해봅니다.LSTM1. 개념 설명LSTM(Long Short Term Memory)은 RNN(Recurrent Neural Networks)의 일종으로서, 시계열 데이터, 즉 sequential data를 분석하는 데 사용됩니다.기존 RNN모델은 구조적으로 vanishing gradients라는 문제를 가지고 있습니다. RNN은 기본적으로 Neural network이기 때문에 chain rule을 적용하여 backpropagation을 수행하고, 예측값과 실제 결과값 사이의 오차를 줄여나가면서 각 시간 단계의 gradient를 조정합니다. 그런데, 노드와 노드(시간 단계) 사이의 길이가 길어지다보면, 상대적으로 이전의 정보가 희석됩니다. 이 문제는 시퀀스 상 멀리 떨어져 있는 요소, 즉 오래 전에 발생한 이벤트 사이의 연관성을 분석할 수 없도록 만듭니다.LSTM은 RNN의 문제를 셀상태(Cell state)와 여러 개의 게이트(gate)를 가진 셀이라는 유닛을 통해 해결합니다. 이 유닛은 시퀀스 상 멀리 있는 요소를 잘 기억할 수 있도록 합니다. 셀상태는 기존 신경망의 은닉층이라고 생각할 수 있습니다. 셀상태를 갱신하기 위해 기본적으로 3가지의 게이트가 필요합니다. Forget, input, output 게이트는 각각 다음과 같은 역할을 합니다.Forget : 이전 단계의 셀 상태를 얼마나 기억할 지 결정합니다. 0(모두 잊음)과 1(모두 기억) 사이의 값을 가지게 됩니다. Input : 새로운 정보의 중요성에 따라 얼마나 반영할지 결정합니다. Output : 셀 상태로부터 중요도에 따라 얼마나 출력할지 결정합니다.게이트는 가중치(weight)를 가진 은닉층으로 생각할 수 있습니다. 각 가중치는 sigmoid층에서 갱신되며 0과 1사이의 값을 가지고 있습니다. 이 값에 따라 입력되는 값을 조절하고, 오차에 의해 각 단계(time step)에서 갱신됩니다.2. 응용 (MNIST data)MNIST는 손으로 쓴 숫자 이미지 데이터입니다. 하나의 이미지는 가로 28개, 세로 28개, 총 784개의 값으로 이루어져 있습니다.Many-to-One model는 여러 시퀀스를 넣었을 때 나오는 최종 결과물만을 이용하는 모델입니다. 이를 이용하여 784개의 input으로 1개의 output값(A) 을 도출합니다. 이 A를 하나의 층에 통과시켜 10개의 숫자 label중 하나를 할당합니다.784개의 입력값을 사이즈가 28인 벡터가 28번 이어지는 시퀀스(time step)로 보고, input의 크기를 28, 시퀀스 길이를 28로 각각 설정합니다. 28개의 input은 C라고 표현되어 있는 LSTM 셀로 순차적으로 들어가게 됩니다.output의 크기는 셀의 크기와 같으며, 64로 설정하였습니다. 셀크기가 너무 작으면 많은 정보를 담지 못하기 때문에 적당히 큰 값으로 설정합니다. 전체 output은 64개의 값을 가지고 있는 벡터 28개의 집합이 되고, 마지막 벡터만 사용합니다.1층의 fully connected layer를 이용하여 64차원 벡터를 10차원으로 줄이고 softmax를 이용하여 0부터 9까지 중 하나의 값을 예측합니다.LSTM으로부터 나온 예측값을 실제갑과 비교하여 cost를 개산합니다. cost function은 cross-entropy를 이용합니다. AdamOptimizer를 이용하여 cost를 최소화하는 방향으로 모델을 최적화 시킵니다.3. 토의구현 시 어려웠던 점을 중심으로 서술하였습니다. 전체 코드는 여기를 참고해주세요.batch sizebatch_size = 128 batch_x, batch_y = mnist.train.next_batch(batch_size) MNIST의 train data의 크기는 55,000개 입니다. 이는 (55000, 784) 크기의 데이터를 학습시켜야 한다는 것을 의미합니다. 이것을 한번에 학습시킨다는 것은 매우 어려운 일입니다. 전체 데이터를 메모리에 올리기 힘들뿐만 아니라, 너무 큰 data 한번에 학습시키면 가장 작은 cost값으로 수렴하기 힘들어진다는 문제가 있습니다. (너무 작아도 마찬가지입니다.) 그렇기 때문에 큰 덩어리를 일정크기의 작은 덩어리로 잘라서 모델에 넣어 학습시는데, 이 작은 덩어리의 크기를 batch size라고 합니다.작은 덩어리로 짜르는 것이 중요한 이유는, 작은 덩어리 단위로 모델에 밀어넣고(propagation) 네트워크의 파라미터들을 조정(update)하기 때문입니다. batch size는 분석하려고 하는 데이터가 어떻게 구성되어있는지에 따라 결정되는 경우가 많습니다. 어떤 수준의 batch size가 좋다고 이야기하기 어렵고, 아주 크지 않은 값으로 설정합니다.unstack모델 구현 시 static RNN을 사용하였습니다. Static RNN에서는 unstack을 해주지 않으면 TypeError가 발생합니다.unstack( value, num=none, axis=0, name=‘unstack’)unstack은 R차원(rank)의 데이터를 R-1 차원으로 줄여주는 역할을 합니다. value로부터 axis 차원을 기준으로 num개로 자른다고도 할 수 있습니다. 이 예제로 예를 들어보겠습니다.batch_x = batch_x.reshape((batch_size, input_steps, input_size)) x = tf.unstack(X, input_steps, axis=1) outputs1, states1 = tf.nn.static_rnn(lstm_cell, x, dtype=tf.float32) 실제 학습이 진행되는 순서로 보자면, batch size만큼 불러온 인풋 데이터는 (128, 784)에서 (128, 28, 28) 형식의 3차원 벡터로 reshape해 줍니다. 그리고 다시 unstack을 통해 time step을 기준으로(axis=1) 28개의 텐서를 만듭니다. 다시말해, (128, 28, 28)이라는 3차원 형식의 벡터는 (128, 28)이라는 2차원 벡터 28개로 변환되어 모델에 입력되게 됩니다. 이런 변환이 필요한 이유는 28*28의 크기를 가진input들을 차례로 넣게 되면 처리속도가 제한적이기 때문입니다. unstack을 이용하면 하나의 batch 안에 있는 input을 한꺼번에 한줄씩 병렬적으로 처리할 수 있게 됩니다.Dynamic RNN에서는 unstack을 해주는 과정이 필요 없습니다. Static과 Dynamic의 차이는 추후 포스팅에서 자세히 다루도록 하겠습니다.Training cycle참고한 다른 예제코드들은 서로 다른 스타일의 사이클로 학습시키고 있었습니다. 스타일은 크게 두가지로 나누어볼 수 있었습니다. 하나의 방법은 전체 학습 횟수를 정해놓고 while문을 통해 학습시키는 방법이었습니다. 다른 방법은 똑같은 데이터를 몇번 반복해서 학습시킬지 결정하는 것입니다. 이 반복 횟수를 epoch이라고 합니다. epoch의 사전적 의미는 ‘시대’ 또는 ‘세’이지만 예제 코드에서 만나는 epoch은 전체 데이터를 학습시키는 반복회수라고 이해하시면 되겠습니다. (이 두가지 방법은 스타일의 문제일 뿐입니다. 이것을 언급한 이유는 개인적으로 epoch을 처음 접했을 때 생소했기 때문입니다.for epoch in range(training_epochs): avg_cost = 0 total_batch = int(mnist.train.num_examples/batch_size) for i in range(total_batch): batch_x, batch_y = mnist.train.next_batch(batch_size) batch_x = batch_x.reshape((batch_size, input_steps, input_size)) c, _ = sess.run([cost2, optimizer2], feed_dict={X:batch_x, Y:batch_y}) avg_cost += c/total_batch 위의 코드는 두번째 스타일이고, 각 epoch마다 cost값과 test data로 예측의 accuracy를 계산하여 출력하였습니다. 당연하게도 학습이 반복 될수록 cost는 감소하고 accuracy는 증가하였습니다.4. 정리기본적으로 도식을 통해 input size, time step, hidden_size에 대한 개념을 이해하는 것이 도움이 됩니다.tensor의 shape을 이해하는 것이 중요하다고 생각합니다. input과 output의 형식(shape)을 머리속에 떠올릴 수 있다면 에러를 줄일 수 있고 해결하기도 수월합니다.batch size의 의미, unstack을 하는 이유, epoch의 의미를 알아두면 좋겠습니다.ReferenceDEEPLEARNING4J 초보자를 위한 RNNs과 LSTM 가이드Colah’s blog, Understanding LSTM Networks이태우, 엘에스티엠 네트워크 이해하기김성훈, 모두의 딥러닝 lec 9-2. Vanishing gadient

출처 : 구글 이미지 검색Just Hacks지난 몇 주간 저는 I/O의 devops문화 기반을 다지는 작업을 해왔습니다. 여전히 부족한 점이 많지만 그동안 일어난 변화를 지켜보면 첫 걸음은 비교적 잘 뗀듯 합니다. 지금부터는 이 devops문화가 제대로 자리잡는 일이 중요한 단계입니다. 다시말해, devops문화가 튼튼하게 뿌리내릴 수 있게 Hacking하는 것이 저의 당분간의 과제입니다.최근 devops를 연구하고 도입하는데 적잖은 시간과 노력을 쏟았기 때문에 실패할 경우 매몰비용이 만만치 않습니다. 꼭 성공시켜야하는만큼 실증적으로 엔진을 검증하기로했습니다. 그래서 지난 주부터는 저도 devops문화에 소속된 벡엔드 엔지니어로서의 일을 시작했습니다. 당분간 직접 코드를 만들어내야겠지요.설계에 그치지 않고 스프린트를 직접 참여해야만 현재 devops문화가 지닌 문제점이 무엇인지 제대로 볼수 있고 훌륭한 기술조직으로 거듭날 수 있다고 저는 믿습니다. 다시 개발자의 자세로 돌아가기 위해 가장먼저 좋은 코드를 작성하는 공부를 시작하였습니다.좋은 코드 만들기컴퓨터가 인식 가능한 코드는 바보라도 작성할 수 있지만, 인간이 이해할 수 있는 코드는 실력 있는 프로그래머만 작성할 수 있다. -마틴 파울러-SW엔지니어가 되기로한 이상, 제겐 감동까지는 아니지만 코드리뷰를 하는 짝꿍이 쉽게 이해할 수 있는 좋은 코드를 짜야할 의무는 있습니다. 그래서 지금까지 감명 깊게 읽은 고전 책들을 복습하기 시작했습니다. 그 첫 번째 책이 켄트백의 구현패턴입니다. 이 책은 설계나 디자인 패턴과 같은 추상적인 내용보다 키보드로 코드를 짜내는 순간에 고민해야하는 부분에서 교훈을 줍니다. 저는 이 책을 통해 코드를 바라보는 제 관점이 다음과 같이 바뀐듯 합니다.필드(현업)에서 생산된 코드는 코드를 작성하는데 드는 시간보다 읽는 시간이 압도적으로 많기 때문에 이를 감안해 봤을 때 읽기 “좋은 코드”를 짜는 노력이 가장 중요하다.돌이켜보면 학생 시절에는 왜 좋은 코드를 짜야하는지 당연히 모를 수 밖에 없었던 것 같습니다. 프로젝트성격의 코드만 짰기 때문에 종강하고나면 제가짠 코드를 다시는 들여다 볼일이 거의 없었거든요. 만약 대학교가 학생들의 취업경쟁력을 높이기 위해 CS 지식 뿐만아니라 Hacker 소양도 가르치고 싶다면 1학년부터 졸업할 때까지 서서히 발전되는 프로그램 하나를 만드는 4년짜리 과제를 두면 효과적일 것 같습니다.말씀드린 것처럼 필드에서 생성된 코드는 작성 시간보다 유지보수를 위해 읽혀지는 시간이 더 많은 편입니다. 특히 린스타트업을 충실하게 따르는 스타트업이라면 런칭기간이 극단적으로 짧기 때문에 제품(SW) 의 생애주기 중 99%의 시간이 유지보수 단계에 있을 것입니다. 이런 관점에 비춰보면 독자를 고려한 좋은 코드를 짜야한다는 사실은 더욱 중요해집니다.새로운 원칙지금까지 제가 견지하고 있는 좋은 코드를 만드는 원칙은 단순화와 중복제거였습니다. 이번 기회에 이 책을 다시 읽고 제 프로그래밍관에 새로운 원칙을 한 가지 더 추가하였습니다. 일관된 추상화인데요.좋은 코드는 일관된 추상화를 보여줍니다. 아래 예시 코드로 바로 확인하실 수 있습니다.void compute() { input(); flag |= 0x0080; // 나쁜 추상화 output(); }이 간단한 compute라는 함수는 제목처럼 입력(input)을 처리하고 이를 16진수 연산을 거친뒤에 출력(output)과정을 거치면서 마무리 됩니다. 그런데, 함 수 2번째 줄에 드러난 flag변수의 16진수 연산은 조금 쌩뚱 맞습니다. 암호처럼 느껴지네요. comput의 절차를 보여주는 input, output 사이에서 세부 구현사항을 친설하게 알려주려는 작성자의 배려는 되려 독자에게 혼란을 주기만 합니다. 이 혼란스러운 코드를 캡슐화를 통해서 일관된 추상화 수준으로 아래 코드처럼 리팩토링 할 수 있습니다.void compute() { input(); updateFlag(color.Brown); // 좋은 추상화 output(); }16진수 연산대신 의도가 드러나는 함수명과 인자전달을 통해 우리는 input을 처리하고 ouput을 갈색 텍스트로 출력시킨다는 사실을 자연스럽게 받아들일 수 있게 됩니다. 보시는 예제처럼 일관된 추상화는 문제해결 능력, 알고리즘 실력보다 코드를 작성하는 센스에 가깝습니다. 항상 독자를 배려하는 마음을 갖고 상대방에 입장에서 서서 코드를 작성하는 습관을 가져야 겠습니다. 이제 코드를 짜고 리뷰도 받으면서 구린내나는 코드를 신나게 리팩토링 할 일만 남았네요 :-)#스위쳐 #Switcher #DevOPS #데브옵스 #개발 #개발자 #DevOPS도입 #인사이트 #성장

ORDER BY 는 원하는 순서대로 자료를 출력하고 싶을 때 사용합니다. 편의를 위해 이전 글의 예제에서 MBR_NM 의 INDEX 인 IX_MBR_BAS_02 를 제거하고 진행하겠습니다. 이번 글에서는 이해-적용-출력-활용의 순서로 살펴볼게요. 지난 글 보기: 단일 TABLE을 SELECT하자!이해: ORDER BY의 오름차순과 내림차순SELECT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; 기본적인 ORDER BY는 위와 같이 사용합니다. 오름차순과 내림차순으로도 정렬할 수 있습니다. 오름차순일 때는 컬럼 뒤에 옵션을 넣지 않거나 ASC를 사용하고, 반대로 내림차순일 때는 DESC를 사용하면 됩니다.[오름차순]ORDER BY      MBR_NM ORDER BY      MBR_NM ASC [내림차순]ORDER BY      MBR_NM DESC 위의 Query(오름차순) 의 실행계획을 보면 아래와 같이 표시됩니다.결과는 다음과 같습니다. (수행시간 3초)내림차순 Query의 실행 계획을 보면 아래와 같이 표시됩니다.결과는 다음과 같습니다. (수행시간 3초)오름차순과 내림차순 정렬 Query를 보면 실행계획은 같고 결과는 다르게 나타납니다.실행계획을 보면 이렇게 표시됩니다.- table : TB_MBR_BAS - type : ALL - Extra : using filesort Extra의 using filesort는 DBMS에서 정렬을 한다는 의미로 퀵소트 알고리즘을 사용합니다. 실행계획의 내용을 풀어보면 “TB_MBR_BAS 을 전부(ALL) 읽은 후 정렬한다(using filesort)” 정도로 보면 됩니다.적용: INDEX와 정렬의 관계이번에는 삭제했던 MBR_NM의 INDEX인 IX_MBR_BAS_02를 다시 생성하고 수행해보겠습니다.CREATE INDEX IX_MBR_BAS_02 ON test.TB_MBR_BAS (MBR_NM); SELECT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; INDEX를 생성하고 실행계획을 보면 아래와 같이 표시됩니다.실행계획을 보면 몇 가지 달라진 게 눈에 띕니다.1. type : ALL -> index 2. key : 없음 -> IX_MBR_BAS_02 3. Extra : using filesort -> Using index 특히 Extra는 using filesort에서 Using index 로 바뀐 것을 알 수 있습니다. using filesort가 정렬을 한다는 것인데, 정렬을 하지 않고 어떻게 정렬해서 보여준다는 것일까요? INDEX를 이해하면 바로 알 수 있습니다. 일반적인 INDEX는 기본이 BTree INDEX 입니다. MySQL의 BTree INDEX는 오름차순 정렬 상태로 저장되어 있습니다. 이미 정렬한 상태로 저장되어 있는 INDEX를 사용하기 때문에 Query를 수행할 때 다시 정렬할 필요가 없죠. 그래서 using filesort가 나타나지 않는 겁니다.출력: Query 실행다음으로 성이 김 씨인 사람들의 이름을 순서대로 출력해보겠습니다. 여기서는 두 가지 Query를 이용해 비교해보겠습니다.예시 1)SELECT     MBR_NM FROM test.TB_MBR_BAS WHERE MBR_NM LIKE '김%' ORDER BY     MBR_NM  ; 예시 2)SELECT     MBR_NM FROM test.TB_MBR_BAS WHERE SUBSTR(MBR_NM,1,1) = '김' ORDER BY     MBR_NM  ; 예시를 보면 WHERE 절이 다릅니다. 예시1은 “MBR_NM이 ‘김’으로 시작하는 것을 오름차순 정렬해 보여주라는 것”이고, 예시2는 “MBR_NM의 첫 번째 글자가 ‘김’인 것을 오름차순 정렬해 보여주라는 것”입니다.이제 두 개의 Query 실행계획을 비교해보겠습니다.예시 1)예시 2)여기서 주의 깊게 봐야 할 컬럼은 type입니다. 다른 컬럼들은 TB_MBR_BAS의 테이블을 조회하면서 IX_MBR_BAS_02 INDEX만을 사용해 보여주겠다는 내용을 갖고 있습니다. IX_MBR_MAS_02 INDEX가 MBR_NM으로 정렬되어 있기 때문에 using filesort가 나타나지 않은 것입니다. 그렇다면 type에 range와 index는 어떤 차이가 있는 것일까요?range : where 조건에 조회하는 범위가 지정된 경우 나타납니다.예시1은 TB_MBR_BAS를 조회하는데 IX_MBR_BAS_02 INDEX의 MBR_NM에서 ‘김’이 시작되는 위치부터 끝나는 위치까지 조회해 보여주라는 의미입니다. IX_MBR_BAS_02 INDEX를 이용해 ‘김’이 시작되는 위치로 바로 접근할 수 있는 것이 핵심입니다.index : index를 처음부터 끝까지 읽는다는 의미입니다.예시2는 TB_MBR_BAS를 조회하는데 IX_MBR_BAS_02 INDEX를 순서대로 읽어서 MBR_NM의 첫 글자가 ‘김’인 것을 보여주라는 의미입니다.두 개의 차이점을 꼽자면, range는 원하는 범위로 바로 접근해 값을 가져올 수 있는 것이고, index는 처음부터 끝까지 읽어서 그 값이 조건에 맞을 경우 가져오라는 것입니다. 따라서 예시1이 휠씬 성능이 뛰어난 Query라고 볼 수 있습니다. 결과는 모두 아래와 같이 출력됩니다.수행시간은 차이를 보였습니다. 예시1은 0.0041초, 예시2는 0.5초였는데요. 예시에서는 건수가 적기 때문에 큰 차이가 없는 것처럼 보이지만, 자료가 10배 또는 100배 많아진다고 생각해보세요. 엄청난 차이겠죠.활용: Query를 만들고 DISTINCT !마지막으로 Query 하나를 만들어보겠습니다. 1) MBR_NM의 중복을 제거하고2) 김 씨이면서3) 이름이 ‘혜’로 시작하는 사람을 먼저 출력하고4) 이외의 사람은 그 다음부터 오름차순으로 출력하려면 어떻게 만들어야 할까요?중복을 제거할 때는 일반적으로 DISTINCT 와 GROUP BY 두 가지를 사용합니다. 이번 글에서는 DISTINCT를 사용하겠습니다. 다음으로는 오름차순 정렬할 때 김 씨를 먼저 출력하는 것인데 조건문을 사용하여 김 씨인 것과 아닌 것을 구별해 우선순위를 주겠습니다. 다른 것은 위의 Query를 이행하면 됩니다. 먼저 DISTINCT를 넣고 수행해 보겠습니다.SELECT     DISTINCT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; 실행계획은 다음과 같습니다.DISTINCT를 수행하면 Extra가 나타나며 group by로 표시됩니다. 여기서는 IX_MBR_BAS_02를 이용하여 gorup by(중복제거)하여 보여준다는 의미입니다. 수행하면 다음과 같은 값이 나옵니다.다음으로는 MBR_NM이 ‘김혜’로 시작하는 것을 먼저 보여주기 위해 ORDER BY 절에 CASE WHEN문을 사용하겠습니다.SELECT     DISTINCT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     CASE         WHEN MBR_NM LIKE '김혜%'    THEN 0         ELSE 1     END     ,MBR_NM  ; 실행계획은 다음과 같습니다.ORDER BY에 조건이 들어가면서 INDEX의 순서대로 정렬한 것을 그대로 보여줄 수 없기 때문에 Extra에 Using temporary, Using filesort가 나타납니다. Using temporary는 가상 테이블을 만들어 사용하는 것인데, 다시 말해 가상 테이블을 만들어 다시 정렬하는 것입니다. 이에 대한 출력값은 다음과 같습니다.‘김혜’로 시작하는 사람이 먼저 나왔군요.글을 마치며지금까지 ORDER BY와 연관된 조건 처리를 알아봤습니다. 데이터를 더욱 체계적으로 나타내고 싶으신가요? ORDER BY를 이용해서 원하는 목적을 달성해보세요.글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유

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

하루가 멀다 하고 신기술이 쏟아지는 요즘 자바스크립트 또한 계속해서 새로운 모습으로 바뀌고 있습니다. ECMAScript 2015(이하 ES6)에 새롭게 등장한 Arrow function, Class, Generator 등이 그중 하나라 할 수 있습니다. 오늘은 ECMAScript 2016(이하 ES7)에서 새롭게 제안된 Decorator에 대해 알아보려 합니다.Decorator란?ES7 스펙 명세(링크)에는 Decorator를 아래와 같이 설명하고 있습니다.선언된 클래스와 그 프로퍼티들을 디자인 시간에 변경할 수 있는 편리한 문법위 문장만 봐서는 도대체 Decorator가 어떤 역할을 하는지 감이 오지 않습니다. 백문이 불여일견이라고 예제를 통해 Decorator를 어떻게 활용할 수 있는지 알아보겠습니다. 아래 코드는 Decorator를 이용해 설계한 클래스 코드의 일부입니다.@withSuperEngine class Car {     ...   @readOnly  manufacturer = 'ZOYI'   ... } 클래스와 클래스의 프로퍼티가 어떤 성질을 가지고 있는지 한눈에 보이시나요? Car는 슈퍼 엔진을 가지고 있고 manufacturer는 변경할 수 없는 값이라는 것을 소설을 읽는 것처럼 쉽게 이해할 수 있습니다. 이처럼 Decorator를 이용하면 코드를 우아하게 작성할 수 있습니다. 그렇다면 어떻게 Decorator를 정의하고 사용할 수 있을까요?Decorator는 최종적으로 채택된 스펙이 아니기 때문에 babel과 함께 사용해야 합니다. babel 설정은 링크에서 확인할 수 있습니다.Decorator의 선언 및 사용방법Decorator는 사실 함수입니다. 함수를 선언한 뒤 ‘@’ 키워드를 이용해 선언된 함수를 Decorator로 사용할 수 있습니다. @withSuperEngine, @readonly, @say.hello, @hello(...) 등이 사용 가능한 Decorator의 호출 형태입니다. Decorator는 클래스를 꾸밀지, 클래스의 프로퍼티를 꾸밀지에 따라 선언하는 방법이 달라집니다.클래스 프로퍼티의 Decorator먼저 클래스 프로퍼티의 Decorator를 정의하고 사용하는 방법에 대해 알아보겠습니다. 이 경우에는 프로퍼티의 descriptor를 인자로 받아 새로운 descriptor를 반환하는 형태를 가집니다. (descriptor에서 설정할 수 있는 여러 값은 링크를 확인해주세요.)그럼 이제 readonly 역할을 하는 Decorator를 작성하고 테스트를 해 보도록 하겠습니다.function readonly(target, property, descriptor) {     descriptor.writable = false   return descriptor } class Car {     @readonly   manufacturer = 'ZOYI' } const myCar = new Car()   myCar.manufacturer = ‘JOY’ // 새로운 값을 할당하려고 한다면 에러가 납니다. 또 다른 예제로 클래스의 프로퍼티를 열거할 때 열거 대상에서 제외하는 Decorator를 작성해 보겠습니다.function nonenumerable(target, property, descriptor) {     descriptor.enumerable = false   return descriptor } class Car {     @nonenumerable  acceleration = 10 manufacturer = 'ZOYI' } const myCar = new Car()   for (let key in myCar) {     console.log(key)  // manufacturer 만 출력이 된다. acceleration는 열거 대상에서 제외된다. } 단 몇 줄만으로 우리는 클래스의 프로퍼티를 읽기 전용으로 만든다던지 열거 대상에서 제외했습니다. 참 편리하지 않나요? Decorator의 활용은 여기서 끝나지 않습니다. 메모이제이션을 하는 메서드를 만들수 있고 클래스에 자동으로 바인드된 메서드로 만들 수도 있습니다.Decorator는 제안된 지 얼마 안 됐지만 많은 사람들이 활발히 연구 중입니다. github에는 지금도 계속해서 Decorator에 관련된 라이브러리들이 올라오고 있습니다. 그중 core-decorators.js는 미리 정의된 유용한 Decorator 패키지를 제공합니다.클래스의 Decorator클래스의 Decorator는 타겟 클래스의 생성자를 인자로 받습니다. 사용자는 인자로 받은 생성자를 입맛에 맞게 바꾼 뒤 반환을 해 주면 됩니다.function setAnimalSound(sound) {     return (target) => {     target.prototype.sound = sound     return target   } } @setAnimalSound('oink') class Pig {     say() {     return this.sound   } } @setAnimalSound('quack') class Duck {     say() {     return this.sound   } } const pig = new Pig()   console.log(pig.say()) // ‘oink’ 출력 const duck = new Duck()   console.log(duck.say()) // ‘quack’ 출력 위 코드처럼 오리나 돼지의 울음소리를 클래스 내부에서 정의하지 않고 클래스 Decorator를 사용해서 정의할 수 있습니다.(사실 이런 코드는 설계 관점에서 봤을 때 바람직하지 않지만 Decorator를 사용할 수 있는 여러 방법 중에 하나라고 봐주시면 감사하겠습니다.)클래스 Decorator는 클래스의 생성자를 바꾸는 것에 국한되지 않고 완전히 다른 클래스의 생성자로 바꿔치기도 할 수 있습니다. 아래 코드는 그 예제를 보여줍니다.function withBus(target) {     return class Bus {     say() {       return 'I am bus'     }   } } @withBus class Car {     say() {     return 'I am car'   } } const car = new Car()   console.log(car.say()) // ‘I am bus’ 출력 이런 구현 방식은 특정 상황에서 클래스 자체를 하이재킹 함으로써 전통적인 분기문 예외 처리가 아닌 보편적인 프로그래밍을 할 수 있게 도와줍니다.클래스 Decorator는 Cross-Cutting-Concern(전체 설계에서 빈번하게 나오는 관심사를 쉽게 모듈화 시키지 못하는 상황)이나 React에서 컴포넌트 하이재킹을 쉽게 해결해줄 수 있는 방법을 제공합니다. 이런 상황을 어떻게 효율적으로 처리하는지에 대해서는 Decorator를 소개하는 글의 취지에 맞지 않아 다음에 연재할 글에서 다룰 예정입니다.마무리이상으로 ES7에 새롭게 제안된 클래스 및 클래스 프로퍼티에 사용할 수 있는 Decorator에 대해서 알아봤습니다. Decorator는 Java, Python과 같은 언어에서 이미 존재하는 문법이기 때문에 이런 설계가 기존에 없던 새로운 방법은 아닙니다. 하지만 오랫동안 ES5에 머물던 자바스크립트가 ES6, ES7 그리고 최근에는 ES8까지 빠르게 변하고 있는 스펙 속에 다른 언어의 장점을 품는 것은 그 자체로 상당히 도전적인 변화라 생각합니다. Decorator 문법은 클래스와 그 파라미터를 꾸밀 수 있는 것에 멈추지 않고 함수의 파라미터에도 꾸밀 수 있게 드래프트 버전이 나온 상태입니다. 자바스크립트에서 Decorator를 이용한 우아한 설계가 어디까지 발전할 수 있는지, 그리고 향후 자바스크립트의 행보가 기대됩니다.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지

Activation Function(활성함수)인공신경망을 공부하다보면 활성함수(activation function)라는 것을 만나게 됩니다. 대부분의 분들은 처음 공부를 시작할 때, 저와 마찬가지로 활성함수는 그냥 이런 거구나 하신 뒤에 넘어가고 있을 거라 생각합니다. 하지만 딥러닝을 좀더 공부하다보면 어떤 활성함수를 사용했는지, 혹은 사용하지 않았는지로 인해 다양한 문제가 발생하곤 합니다. 특히 요즘 핫한 deep neural network 에서는 활성함수가 어떤 것인가에 따라서 vanishing gradient 문제로 인해 학습의 정도가 달라지기도 합니다. 이러한 이유에서 이번 포스팅에서는 활성함수를 자세히 이해해보도록 하겠습니다.인공신경망이 사람의 신경구조를 모방하여 만들어졌다는 사실은 다들 알고 계실겁니다. 인공신경망의 가장 기본 개념은 단일 퍼셉트론에서 출발했습니다. 관련된 포스팅에서도 설명했지만 퍼셉트론은 여러 개의 신호가 들어오면 이를 조합하여 다음으로 신호를 보낼지 말지를 결정합니다(0 또는 1). 이것을 발전시킨 feed forward multiple layer neural network는 하나의 단일 뉴런에 여러 신호가 들어오면, 다음 뉴런에 보낼 신호의 강도를 결정하게 됩니다. 즉, 단일 퍼셉트론이 multi layer perceptron으로 발전해나가는 과정에서, 뉴런은 신호의 전달유무가 아닌 전달 강도를 정하게 되었습니다. 이때 전달하는 신호의 세기를 정하는 방법이 활성함수입니다.많은 분들은 대표적인 활성함수로 sigmoid를 떠올리실 것입니다. 활성함수의 개념을 잡기에는 이만큼 좋은 함수가 없기 때문입니다. 그럼 우선 활성함수의 가장 기본적인 개념을 sigmoid를 통해 알아보도록 하죠. 그 전에 여러분의 이해를 돕기 위해 로지스틱 회귀분석에 대해 먼저 알아보겠습니다.로지스틱 회귀분석(logistic regression)로지스틱 회귀분석은 generalized linear model입니다. 정확히 말하자면 generalized linear model이라는 큰 개념의 여러 케이스 중 하나라고 볼 수 있겠네요. 로지스틱 회귀분석의 목적은 독립변수의 선형결합으로 종속변수인 ‘어떠한 사건이 발생할 확률’을 알고자 하는 것입니다. 어렵죠..? 쉬운 예시를 하나 들어보겠습니다.우리는 어떠한 연구를 통해 1일 흡연량과 폐암 발생 여부의 관계를 알고싶습니다. 이때 가장 쉬운 방법은 1일 흡연량{x}과 폐암 발생확률{p(y)}이 선형 관련성이 있다고 보고, 선형 회귀 분석(linear regression)을 시행하는 것입니다. 그 결과, p(y)=0.02x+0.1<math>p(y)=0.02x+0.1</math> 이라는 식이 도출되었다고 생각해보죠. 이 식은 담배를 전혀 안 피우는 사람은 10%의 확률로 폐암에 걸리고, 하루에 담배를 1개비씩 더 피울 때마다 폐암에 걸릴 확률이 2% 증가한다는 의미입니다. 표면적으로 보았을 때는 꽤나 합리적으로 보입니다. 하지만 과연 이 식을 실제 예측에 활용해도 전혀 문제가 없을까요? 예상하셨겠지만, 그렇지 않습니다.담배는 한 갑에 20개비가 들어있고, 3갑이면 60개비가 들어있습니다. 따라서 하루에 담배를 3갑 피우는 사람은 0.02∗60+0.1=1.3<math>0.02∗60+0.1=1.3</math>, 즉 130%의 확률로 폐암에 걸린다는 결론이 도출됩니다. 이는 확률의 공리에 어긋나는 결론입니다. 따라서 과거의 수학자들은 선형이라는 이해 및 계산이 쉬운 방법을 그대로 유지하면서 확률의 공리에 어긋나지 않는 방법을 찾고자하였고, 다양한 방법들 중 가장 보편적으로 사용하게 된 방법이 로지스틱 함수를 연결함수로 사용한 로지스틱 회귀분석입니다.로지스틱 함수는 아래와 같이 생겼습니다.g(x)=ex1+ex<math>g(x)=ex1+ex</math>이것을 연결함수로 적용한 generalized linear model, 즉 logistic regression의 수식은 아래와 같은 형태가 됩니다.P(y|x)=eβx1+eβx<math>P(y|x)=eβx1+eβx</math>위 식을 이용하면 비로소 선형이라는 직관적인 성질을 띄면서, 결과값의 범위가 0~1로 제한되어 확률값의 예측에 사용할 수 있는 회귀식이 도출됩니다. 이 때, 위에 사용한 로지스틱 함수가 바로 우리가 활성함수로 사용하는 sigmoid function입니다. 따라서 sigmoid를 활성함수로 사용할 경우, 필연적으로 로지스틱 회귀분석과 관련이 있을 것이라고 예상할 수 있습니다. 둘 간의 관련성을 아래 그림을 통해 알아보겠습니다.여러분의 이해를 돕고자 hidden layer가 없는 가장 단순한 형태의 feed forward neural network 형태를 그려보았습니다. 위 그림을 수식으로 나타내볼까요?P(Y|X)=exp(∑2i=0wixi)1+exp(∑2i=0wixi)=11+exp(−∑2i=0wixi)<math>P(Y|X)=exp(∑i=02wixi)1+exp(∑i=02wixi)=11+exp(−∑i=02wixi)</math>즉, 위처럼 sigmoid를 활성함수로 사용한 간단한 neural network는 logistic regression과 일치합니다. 물론 계수(weight) 추정 방법은 통계학에서 기존에 행하던 방법과는 차이가 있지만, 결과적으론 비슷한 값이 추정될 것입니다. 우리는 이 그림을 통해 아래와 같은 직관을 얻을 수 있습니다.input과 weight를 곱해서 더하는 과정은 linear combination(선형 결합)이다.인공신경망의 학습은 각 뉴런에 곱해지는 ‘weight’라는 모수(parameter)를 추정(estimate)하는 과정이다.이제 눈치 채셨나요? Sigmoid를 활성함수로 사용하는 multi layer perceptron neural network의 hidden layer의 각 뉴런은 로지스틱 회귀분석을 하는 것과 정확히 일치합니다. 따라서 학습 과정에서 각 layer의 weight라는 모수를 학습을 통해 추정하는 것입니다.mlp 적용그럼 이제 위에서 배운 로지스틱 회귀분석을 mlp에 적용해보겠습니다. 우리는 단층 퍼셉트론 에서 아래와 같은 그림을 보았습니다.위처럼 선형으로 깔끔하게 분류가 가능한 문제는 활성함수가 계단함수인 단층 퍼셉트론으로도 충분히 해결할 수 있습니다. 하지만 아래와 같은 경우는 문제가 달라집니다.이러한 분류 문제는 선형으로는 불가능하며, 비선형적인 분류를 하여야 합니다. 이처럼 우리가 원하는 비선형의 분류를 하기 위하여 크게 두 가지가 필요합니다.1개 이상의 hidden layer(2개 이상의 뉴런을 포함하여야 함)비선형의 활성함수먼저 비선형의 활성함수가 필요한 이유부터 간단하게 생각해보겠습니다. 만약 활성함수가 비선형이 아니라면, 각 뉴런의 결과값은 선형결합의 선형결합이 됩니다. 따라서 아무리 multiple layer를 쌓는다고 하여도, 결과적으로 출력값은 입력값들의 선형결합이 됩니다. 즉, 층을 여러 개 쌓는 의미가 퇴색되는 것입니다.다음으로 hidden layer와 뉴런의 갯수에 대한 정의가 왜 필요한지 생각해보겠습니다. 위에서 언급하였듯이 logistic regression은 generalized linear model입니다. 여기서 ‘linear model’에 주목해주세요. 즉, logistic regression도 결국은 선형 모델이라는 것입니다. 왜일까요? Logistic regression을 이항분류 문제(결과의 범주가 0 또는 1)에 적용하여, 결과값이 특정값 이상이면 1로 분류한다고 생각해보겠습니다. 이것은 결국 기존의 단일 퍼셉트론에서 활성함수로 sigmoid를 사용한 뒤, 다시 계단함수를 적용한 것과 같습니다. 비록 우리가 sigmoid라는 비선형의 활성함수를 사용했지만, 로지스틱 함수의 지수를 풀어내면 결국 선형 결합의 결과값에 대한 분류이므로 우리가 원하는 비선형의 분류를 할 수 없습니다. 따라서 위와같은 문제를 해결하기 위하여, 비선형의 활성함수를 쓰되, 다수의 뉴런을 갖는 hidden layer를 사용하는 것입니다. 이 때, hidden layer의 뉴런 갯수가 늘어날 수록 좀더 비선형으로 데이터에 적합한 분류가 가능해지지만 overfitting 문제가 발생하게 됩니다. 따라서 hidden layer의 뉴런 갯수를 과제마다 적절히 지정해주는 것이 중요합니다.activation function의 종류마지막으로 activation function의 종류 및 특징에 대해 정리해보겠습니다.1. Sigmoid functionBy Qef (talk) - Created from scratch with gnuplot, Public Domain, Link<특징>수식 : σ(wx+b)=ewx+b1+ewx+b<math>σ(wx+b)=ewx+b1+ewx+b</math>범위 : (0,1)시그모이드 함수는 완전히 값을 전달하지 않거나(0) 혹은 완전히 전달한다(1)는 특성 때문에 실제 인체의 뉴런과 유사하다고 생각되어 널리 사용되었으나, 현재는 점차 사용하지 않는 추세입니다. 그 이유는 아래와 같습니다.Vanishing Gradient :sigmoid 함수는 뉴런의 활성화 값이 0 또는 1에 매우 가깝다면(saturate), 해당 편미분 값이 0에 매우 가까워지는 특성이 있습니다. 인공신경망의 back propagation에서 가장 일반적으로 사용되는 gradient descent의 경우 chain rule을 이용하는데, 이 과정에서 0에 매우 작은 값이 계속 곱해진다면 그 값은 0으로 점점 더 수렴합니다. 즉, 학습의 결과가 back propagation 과정에서 전달되지 못하고 이에 따라 weight 값의 조정이 되지 않습니다. 이것은 학습의 과정뿐만 아니라, 초기 weight 값을 임의로 줄 때에도 문제가 됩니다. f=σ(wx+b)<math>f=σ(wx+b)</math> 를 통해 확인해보죠. 만약 w의 값이 매우 커서 σ(wx+b)<math>σ(wx+b)</math>의 값이 1에 매우 가까워 진다면, weight값은 초기 값에서 크게 변하지 않고 학습이 되지 않을 것입니다. 그럼 우리의 신경망 모델의 정확성도 감소하겠죠. 이것이 vanishing gradient problem입니다.중심값이 0이 아니다 :Sigmoid function의 결과값은 그 중점이 0이 아니며, 모두 양수입니다. 이 경우 모수를 추정하는 학습이 어렵다는 단점이 있습니다. 하지만 이것은 다른 방식으로 모델 내에서 극복이 가능하기 때문에 vanishing gradient 에 비해 큰 문제는 아닙니다.2. tanh function<특징>수식 : tanh(x)=e2x−1e2x+1<math>tanh(x)=e2x−1e2x+1</math>범위 : (-1,1)tanh(hyperbolic tangent) function은 sigmoid 처럼 비선형 함수이지만 결과값의 범위가 -1부터 1이기 때문에 sigmoid와 달리 중심값이 0입니다. 따라서 sigmoid보다 optimazation이 빠르다는 장점이 있고, 항상 선호됩니다. 하지만 여전히 vanishing gradient 문제가 발생하기 때문에 대안이 등장하게 됩니다.3. Relu(Rectified Linear Unit)<특징>수식 : y=max(0,x)<math>y=max(0,x)</math>범위 : (0,∞<math>∞</math>)Relu는 위 그림처럼 선형그래프를 한 번 꺾은 형태입니다. 이 간단한 함수는 오랫동안 인공신경망의 발목을 잡던 vanishing gradient 문제를 해결했습니다. 하지만 여전히 장점과 단점이 존재합니다.장점기존의 sigmoid, tanh에 비해 converge되는 속도가 빠릅니다. 이것은 그래프의 형태가 선형이고, saturate problem이 발생하지 않기 때문으로 보여집니다.x값이 0을 기준으로 선형발현/미발현 이라는 간단한 형태이기 때문에 상대적으로 연산량이 많은 exponential을 사용하지 않아, 컴퓨터의 연산에 대한 부담을 줄여줍니다.단점“dying Relu problem”이 발생합니다. 만일 학습 과정에서 weight가 특정 뉴런이 activate되지 않도록 바뀐다면, 해당 뉴런을 지나는 gradient도 0이 됩니다. 따라서 training 과정에서 해당 뉴런이 한 번도 발현하지 않게 될 수도 있습니다. 심한 경우에는 네트워크 전체 뉴런의 40%가 죽어있는 경우도 발생한다고 합니다(출처 : http://cs231n.github.io/neural-networks-1/). 이것을 막기 위해서는 learning rate를 크지 않게 조절하는 것이 중요합니다. 또 다른 해결 방안으로는 leaky relu와 같은 activation function을 사용할 수도 있습니다.정리이번 포스팅을 통해 우리는 activation function이 무엇이고, 왜 필요한 것인지 알아보았습니다. 또한 어떠한 activation을 어떻게 사용해야하는지도 배웠습니다. 제가 위에 소개한 것 이외에도 다양한 activation function이 있으므로, 한 번쯤 찾아보며 공부해보시면 좋겠습니다.

오랜만에 돌아온 크로키닷컴 인터뷰!요즘 채용이 활발하게 진행 중인 크로키닷컴의 [프론트엔드 개발자] 에 관해 궁금해하시는 분들을 위해, Dev.팀에서 근무하고 있는 프론트엔드 개발자 두 분! 영준님, 케빈님을 모셨습니다.Chapter 1. 저를 소개합니다!Q. 영준님, 케빈님 반갑습니다! 간단하게 자기소개 부탁드릴게요.영준 저는 프론트엔드 개발자 김영준이고요, 지그재그의 또 다른 신사업 서비스를 만들어가고 있습니다. 프론트엔드 개발은 5년 정도 했고, 요즘은 신사업 서비스에 새로운 기능이 들어갈 예정이라 그 작업을 열심히 하고 있습니다! 참, 원래 저는 공대 출신은 아니고 디자인과를 졸업했어요.(우와.. 디자이너에서 개발자로 전향하신 특별한 계기가 있으셨나요?)그때 당시 어도비 플래시가 잘 되던 시기였는데, 플래시가 좋아서 그쪽 수업을 많이 들었거든요. 그때부터 관심을 갖게 돼서 첫 회사에는 플래시 개발자로 입사했었어요. 이후에 플래시 사용률이 점차 줄어들면서 프론트엔드 개발 쪽으로 전향하게 되었습니다.케빈 어.. 제 본명은 성훈이고요.(웃음) 저는 원래 풀스택 개발자로 2년 정도 일을 했었어요. 본격적으로 프론트엔드 쪽으로 전향한 지 2년 정도 된 것 같아요. 저도 영준님이랑 비슷하게 공대는 아니고 영상그래픽을 전공했어요. 3D나 특수효과 같은 거? 교양수업으로 HTML 수업을 듣다가 개발에 관심이 생겨서 시작하게 됐습니다!(그렇군요! 케빈님 곧 있으면 입사 100일을 맞이하시게 되는데 소감이 어떠신가요?)프론트엔드 포지션에 온전히 집중해서 일을 해본 건 처음이에요. 이전에 바라 왔던 업무환경에 많이 근접한 것 같고 점차 적응 중에 있습니다.Q. 어떠한 연말을 보내고 계신가요?영준 어! 저 얘기할 거 있어요. 얼마 전부터 회사에서 전세자금 대출 이자를 지원해주기 시작한 덕분에 난생처음으로 독립을 하게 됐거든요. 이자를 지원받게 되니 집도 더 잘 구하게 된 것 같아요! 그래서 요즘은 자취 초년생으로서 이것저것 해보고 있어요. 요리도 해보고 그동안 해보고 싶었던 것들? 하지만 집에서 부모님이 해주시는 게 얼마나 감사한 지도 알게 됐어요. (그래도 다시 돌아가긴 싫으시겠죠?)영준 네, 독립해서 진짜 좋아요. 그래서 요즘 일하는 시간 외에는 인테리어 고민을 많이 하고 있어요. 지금 집에는 아무것도 없거든요. 곧 영준님만의 감성으로 채워질 집!케빈 아.. 저는 딱히 뭐가 없는데..영준 아 아직 입양 안 받았어요?케빈 아! 맞아요. 제가 동물을 입양하려고 준비하고 있어요. 그 동물에 대해서 공부 먼저 하고 제대로 알게 된 다음 입양하려고요. (입양이요? 강아지? 고양이?!) 케빈 페럿이라고 아세요? 페럿을 입양하려고 공부하고 있어요. 돈도 많이 든다고 해서 모으고 있기도 하고요. 그것 빼고는 하는 게 없어요 아직.키우는 분이 별로 없는 희귀한 동물, 페럿! 애교가 많은 동물이라고 하네요 :-)Chapter 2. 직잭러가 되어가는 과정Q. 지그재그로 이직하고 싶었던 특별한 계기나 이유가 있었나요?영준 이직할 때 개발자로서 성장이 가능한 회사를 찾으려고 했어요. 이전 회사가 에이전시이다 보니 코드 리뷰 문화가 없었거든요. 코드 리뷰는 프로덕트에도 좋은 영향을 끼치지만 개발자 개개인의 성장에 더 영향을 많이 끼친다고 생각했거든요.(실제로 겪어본 이후로는 확신합니다!)프로덕트에 대한 이해를 높이는 것은 물론 양질의 코드를 실컷 볼 수 있고, 또 어느 코드 하나 허투루 작성할 수 없어요. 그래서 꼭 코드 리뷰가 있는 회사로 가려고 했는데, 지그재그가 딱 그랬습니다!케빈 저도 코드 리뷰 문화에 한 표! 저는 프론트엔드 분야에서는 늦게 공부를 시작했기 때문에 배울 수 있는 환경이 매우 중요하다고 생각했거든요. 아 그리고 저는 이직을 고려할 때, 그 회사에 대해서 미리 프레스나 github을 다 찾아보는데, 그러다 보면 이 회사는 '이렇게 근무를 하는구나'가 어느 정도 보이더라고요. 근데 지그재그 팀을 찾아보면서 여기서 꼭 같이 일해보고 싶다고 생각했어요. 찾아보시면 지그재그 개발 문화와 관련된 소스코드나 오픈소스 프로젝트가 공개되어 있는데요, 왜 이런 코드를 썼고 이런 규칙을 정했는지 오픈해두고 같이 생각해볼 수 있게끔 되어 있어요.영준 저는 기술 블로그도 재밌게 봤어요.케빈 맞아요. 특히 주니어의 입장에서는 발전에 대한 욕망이라고 해야 하나?(웃음) 욕심이 클 수밖에 없는데 기술 블로그가 지그재그 팀에 대한 궁금증을 풀어주는데 많은 도움이 됐어요.나름 활발한 (?) 지그재그 기술 블로그에도 놀러 오세요! https://devblog.croquis.com/ko/Q. 입사 전 인터뷰 때 가장 인상 깊었던 질문이나 에피소드가 있으신가요?영준 일단 면접 절차 진행이 너무 친절해서 당시 기억이 엄청 좋았어요. 또 정해진 질문지에 대한 뻔한 대답보다, 저에게 fit된 인터뷰를 진행했던 것도 좋았고요. 전 회사에서는 인터렉션 관련된 작업을 많이 했었는데, 쟈니님(CEO)이 인터렉션이 프로덕트에 어떤 도움을 줄 수 있을까에 대한 질문이 되게 참신하고 좋게 다가왔습니다. 물론 제가 답한 것 들 이외에도 어떤 영향을 끼칠 수 있는지 말해주어서 더 좋았어요! 아, 재밌는 에피소드가 하나 있는데.. 쟈니님이 '영준님은 친구들 사이에서 어떤 사람이에요?'라고 질문을 하셔서 '먹는 것 좋아하는 사람이요.'라고 대답했더니, 쟈니님이 '그럼 안 되겠네요. 저희는 밥을 다 사드리기 때문에 영준님이 오시면 거덜 날 것 같아요'라고 하셨어요.(빅웃음) 쟈니님은 워낙 장난이 많으신 분이라 재밌었어요.케빈 저는 2차 인터뷰 때 엄청 떨었어요. 그래서 어떤 질문이 나왔고 어떻게 대답을 했었는지 하나도 기억이 안 나네요. 입사 후 수습기간이 끝나갈 즈음에 쟈니님과 미팅을 한 번 더 했었는데, 쟈니님이 제가 인터뷰 때 떨었던 것과는 너무 다르게 업무 커뮤니케이션을 잘한다는 팀원들의 반응이 많아서 놀랐다고 하셨어요.영준 케빈님 1차 인터뷰 때에도 엄청 긴장되시지 않았어요?케빈 맞아요. 그땐 그래도 기술적인 질문이 많아서 나름 덜 떨었답니다.(?) 그리고 아까 영준님이 답해주셨듯이, 저도 마찬가지로 제가 경험한 것을 중심으로 질문을 많이 해주셔서 수월하게 대답할 수 있었던 것 같아요. 입사한 지 얼마 되지 않아 interviewer로 몇 번 참석했었는데, 지원자분의 경험을 중심으로 대화를 나누는 게 실제로 지원자분에 대해서 더 잘 알아갈 수 있는 좋은 방법인 것 같아요!Q. 입사 전 기대했던 지그재그의 모습과 실제 겪어본 지그재그의 모습은 어때요? 많이 다른가요?케빈 저는 기대했던 것과 크게 다르지 않았어요. 많은 개발자들이 기술적으로 더 성장할 수 없다고 느껴질 때 상실감을 크게 느낄 거예요. 전 직장에서도 서로 토론하고 의견을 공유하는 문화가 있었는데 바쁘다 보니 그 문화가 점점 사라지게 되어 많이 안타까웠죠. 그래서 지금은 지그재그 개발팀의 좋은 문화가 유지될 수 있게, 계속 활발하게 운영이 될 수 있도록 적극적으로 참여하려고 노력하고 있어요. 영준 사실 전 지그재그 팀이 딱딱한 분위기에서 업무를 할 거라고 생각했었어요. 워낙에 빠르게 성장하고 있는 회사이다 보니? 근데 막상 들어와 보니 이만큼 같이 일하는 게 재밌고 캐릭터가 독특한 사람들이 많은 회사는 처음이에요. 그리고 저희가 매주 월요일에 전 직원이 모여서 주간 미팅을 하잖아요. 거기서 팀별로 프로젝트 진행상황을 공유하는데 정확한 데이터 수치를 기반으로 꼼꼼하게 분석하고 리뷰하는 모습에 놀랐어요. 추가적으로 개발에 대한 열정이 있는 동료들이 많았으면 하는 소망도 있었는데, 실제로 만난 지그재그는 개발 욕심 가득한 사람들의 모임이라 매일매일 자극받으며 근무하고 있어요.매주 월요일 전직원이 참여하는 주간 미팅!Q. 지그재그 팀에 들어온 후에서야 비로소 알 수 있었던 좋은 문화나 제도가 있을까요?영준 사내 스터디가 많은 거? 아마 우리 회사가 다른 어떤 회사보다 스터디가 많을걸요? 원한다면 누구든 만들어서 모집할 수 있거든요. 다들 매우 적극적입니다.(그럼 영준님은 몇 개의 스터디에 참여하고 계세요?) 저는 1월에 새로 시작할 스터디까지 하면 두 개요!케빈 개발자들에겐 스터디도 큰 요소일 거예요. 다양한 스터디가 지속적으로 운영되는 게 쉬운 일은 아니라, 기술 블로그를 보면 '진짜 이만큼이나 공부한다고?'라고 의문이 들 수밖에 없으니까요. 아! 그리고 스터디는 아니지만 개발 미식회라는 프로그램이 있어요. 다른 사람들과 함께 의논해보고 싶은 코드가 있거나 혹은 본인이 만든 코드를 공유하고 싶은 사람이 자발적으로 신청자를 받아서 점심을 함께 먹으면서 발표도 하고 의견도 나누는 시간이에요. 한 달에 1-2회 정도 진행이 되고 있어요. 다음 주에 저도 발표하기로 했거든요. 신청자가 없어서 못하게 되면 안 되는데..영준 그리고 발표를 했던 사람은 다음 개발 미식회의 점심 메뉴를 선정할 수 있는 특혜가 주어집니다.(웃음)케빈 오! 그건 몰랐어요. 그리고 저는 저번에 영준님이 발표하실 때에도 신청해서 들었어요. 영준 다들 서로 발표를 하고 싶어서 바쁜 와중에도 열심히 공부해요. 바쁠 땐 듣는 게 좀 부담스러울 텐데도, 다들 적극적으로 들어주려고 하니 고맙죠.영준 님의 개발 미식회 모습! 제가 더 떨리네요 @.@Chapter 3. Dev. 팀은 이런 분을 찾아요!Q. 먼저 Dev. 팀은 어떤 방식으로 일을 하나요?영준 백엔드에 계시는 분들도 그렇고 다른 포지션에 계신 분들도 프론트엔드에 관심이 많으셔서 도와주실 때가 많이 있어요. 아무래도 다들 공부를 많이 하다 보니 그런 것 같아요. 그러다 보니 업무 할 때 같이 고민할 수 있어서 좋죠. 그리고 프로젝트를 일정에 맞추어 진행하다 보면 포기해야 될 부분이 생기기 마련인데요, 지그재그 팀은 유저의 사용성 향상을 위해 기획했던 것들을 최대한 포기하지 않고 가져갈 수 있는 방향을 모색하는 편이에요. 포기하면서 잃는 것도 생각하고 얻게 되는 것도 생각해야 하니 항상 신중해야 합니다.케빈 프로젝트를 진행하면서 문제가 생기면 다 같이 의논해서 풀려고 해요. 그리고 그 과정에서 여러 가지 다른 의견이 나오면 합의점을 찾으려고 하고요. 이건 팀 내에서 뿐만 아니라 유관부서랑 함께 일할 때도 같아요. 팀원들 모두가 개인적인 관점이 아닌 product 관점과 사용자 관점으로 생각하려고 하기 때문이죠. 또 프로젝트를 통해 유저분들에게 더 좋은 경험을 전달해주고자 노력하고 있어요. 그래서 유저분들의 기대에 부응한 부분과 그렇지 못한 부분이 무엇인지에 대해 사용자 데이터를 기반으로 회고하는 과정도 함께 진행하고 있습니다.Q. 회사 안에서 해보고 싶은 특별한 프로젝트가 있으신가요?영준 저는 직잭버디를 뽑는 시스템을 만들고 싶어요. 그리고 의류, 패션에 관련된 새 프로젝트도 해보고 싶네요. (*직잭버디는 신규 입사자의 빠른 적응을 도와드리는 멘토링 프로그램입니다!)케빈 저는 개인적으로 점심시간 메뉴 고르는 룰렛을 만들고 싶어요. 회사 주변에 밥집이 너무 많아서 오히려 메뉴를 고르기가 어려워요. 만들면 잘 쓰지 않을까요? 의견을 받아서 다 같이 만들어봐도 재밌을 것 같아요.Q. 요즘 [프론트엔드 개발자] 채용이 한창인데요, 어떤 분과 함께 일하고 싶으신가요?케빈 개발 환경을 기반으로 여러 개발 항목들을 유저의 관점에서 대조해 봤을 때, 깊게 생각해보고 경험해 본 분이면 좋겠어요. 유저의 관점에서 더 생각해보고 적용하시는 분이라면 지그재그 서비스에 대해 애정을 가지고 일할 수 있을 것 같아요.영준 요구사항에 맞게 동작하는 프로그램을 만드는 것은 물론, 유저의 사용성을 생각하는 개발자였으면 좋겠어요. 예를 들면 모바일 기기에서의 최소 터치 영역을 생각한다든지... 유저를 직접 만나는 최접점에 있는 개발이다 보니, 사용성에 관해서는 가장 관심이 많아야 한다고 생각하거든요. 또 프론트엔드 개발 자체가 빠르게 발전하고 있는데, 왜 이렇게 바뀌고 있는지를 생각하는 개발자면 좋을 것 같아요. 그리고 회사가 커지면서 여러 가지 새로운 서비스들도 생기고 새로운 경험도 많이 하게 될 텐데요, 새로운 걸 만들어 보고 겪어보고 싶은 분이라면 지원해주세요!케빈 평소에 업무를 하실 때 깊이 있게 고민하면서 선택하신 본인의 라이브러리, 도구들에 대해 왜 이런 선택을 했는지.. 또 코드 한 줄 한 줄을 어떤 의도로 작성했는지에 대해 생각해보신 분이라면 어렵지 않게 인터뷰를 진행하실 수 있을 거예요. 또, 그런 분들이 계시다면 저희도 꼭 모시고 싶어요!Chapter 4. 마무리Q. 올해 지그재그 팀에 합류하면서 개인적으로 성장한 부분, 그리고 2020년의 목표나 버킷리스트가 있으신가요?영준 지그재그 서비스가 이커머스가 되어가는 과정을 함께 하면서 성장했다고 느꼈어요. 내년 목표는 신사업 성공시키기! 업무 외적으로는 운동을 열심히 해서 바다에서 사진 찍는 거예요. (몸짱 영준)케빈 저는 Z결제 서비스가 오픈되면서 마케팅 이벤트를 위한 개발을 많이 했는데요, 이벤트에 대한 유저의 반응이 폭발적인 걸 보면서 더 유저의 입장에서 생각하려고 하는 스스로를 보며 성장하고 있다고 느꼈어요. 더 공부하려고 하기도 하고요. 그리고 개인적으로는 내년에 영어공부를 열심히 하고 싶어요. 제가 즐겨하는 PC게임이 있는데, 외국인 유저와 더 편하게 대화하면서 게임하고 싶어서요.(웃음)Q. 다음 인터뷰는 어느 팀에서 하면 좋을까요? 그 팀에 특히 궁금한 것이 있다면요?영준 저는 서버 개발자 또는 데이터 팀이요! 지그재그 서비스의 서버 개발자들은 각자 태스크를 부여받아서 진행하는 방식으로 업무를 한다고 들었는데, 구체적으로 R&R이나 업무 프로세스가 어떤 방식으로 이루어지는지 궁금해요. 그리고 데이터 팀에는 수많은 데이터들을 앞으로 지그재그 서비스의 발전을 위해 어떻게 활용할 수 있을지, 그리고 데이터팀에 계시는 인성님께 어떻게 그렇게 매일 웃으며 즐겁게 지내실 수 있는지 여쭤보고 싶어요.케빈 저는 디자인 팀! 지그재그의 다양한 디자인들을 작업하고 의사결정을 내리기까지의 논의 방식이 궁금해요. 그리고 디자인 팀에도 인원이 늘었는데, 그로 인해 어떠한 변화가 생겼는지도 궁금합니다.지그재그에서는 웹 프론트엔드 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [웹 프론트엔드 개발자] 포지션을 소개합니다!이런 일을 합니다.이런 분을 모십니다.이 중 하나라도 가능하시다면 더더욱 좋아요 :)지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기

한화정밀기계의 협동로봇 HCR-5 / 출처 - 한화정밀기계　이제 번거로운 작업은똑똑하고 안전한 협동 로봇에게 맡기세요!　제조 산업의 다양한 과정들이 점차 기계화되어가고 있습니다. 기계화의 과정에서도 사람이 개입되어야 하는 번거로운 과정들이 남아있기 마련인데요. 사람이 꼭 필요한 섬세하고 동적인 역할까지 수행하면서 기계의 편리성을 살릴 수 있는 ‘협동 로봇(코봇)’의 탄생으로 그 고민이 해결되었습니다.머지않은 미래에 협동 로봇의 춘추전국시대가 예상되는 가운데, 2017년 시장에 진입한 한화정밀기계의 HCR 시리즈 협동 로봇은 뒤늦게 시장에 합류했지만, 유려한 디자인과 다양한 기능, 안전성을 고려한 특색 있는 제품 생산으로 전 세계 고객들의 사랑을 받으며 점유율을 확대해가고 있습니다. 협동 로봇의 발전으로 개발과 연구를 전문으로 하는 직업도 탄생했는데요. 한화정밀기계에는 협동 로봇 전문가집단인 로봇사업부가 존재합니다. 이 부서의 수장인 장우석 로봇사업부장에게 자세한 이야기를 들어보겠습니다.　Q. 안녕하세요. 우선 협동 로봇에 대해 간단히 설명 부탁드립니다!한화정밀기계 장우석 로봇사업부장 / 출처 - 한화정밀기계안녕하세요. 한화정밀기계 로봇사업부의 장우석입니다. 산업 현장에서 사람들을 돕기 위해 만들어진 로봇이 바로 협동 로봇입니다. 이들은 정확성과 일관성이 요구되는 반복적인 업무들을 처리하는데요. 기존의 반복적인 업무를 대신하고, 작업자는 주관적인 판단이나 유연성이 요구되는 일을 할 수 있도록 돕는 것이죠. 현재의 협동 로봇 이전에 주로 사용했던, 기존의 산업용 로봇은 굉장히 한정적인 업무만을 수행할 수 있었습니다. 가령 물건을 하나 옮긴다고 가정하면, 그에 맞는 고난도의 컴퓨터 프로그램을 입력해야 그 일을 할 수 있습니다. 만약 다른 장소로 물건을 옮기려고 한다면 조립공정을 멈추고 중장비를 사용해 옮겨야 합니다. 따라서 시간과 비용이 굉장히 많이 듭니다. 반면 협동 로봇은 이러한 번거로운 과정들을 한 번에 해결해줍니다. 특히, 한화정밀기계의 HCR 협동 로봇은 사용자 친화적인 인터페이스를 갖추고 있어서 작업자가 작동법을 익히는데 하루도 채 걸리지 않습니다. 또한, HCR 협동 로봇의 워크플로를 세팅하거나 변경할 때는 단순히 필요한 항목들만 클릭해 바꾸면 됩니다.싱가포르 합자법인 공장에서 HCR-5를 생산하고 동남아시아 시장에 공급할 예정인 한화정밀기계 / 출처 - 한화정밀기계　Q. 한화가 로봇 산업에 진출하게 된 계기는 무엇인가요?한화그룹은 4차 산업혁명의 일환으로 로봇 산업을 시작했습니다. 다양한 분야 중 저희는 협동 로봇에 초점을 맞췄고, 작년에 국내 최초의 협동 로봇인 HCR 시리즈를 출시했습니다.한화그룹은 항공엔진, 에너지, 산업 장비, CCTV 카메라와 같이 다양한 산업 분야에 관심을 두고 있습니다. 이러한 시장을 키우고 선두가 되기 위해, 한화는 정밀기계, 동작 조종 기술, 사물 인식 소프트웨어, 자동 내비게이션과 같은 분야에서 전문성을 높이고 있습니다. 이러한 모든 것의 중심이 바로 로봇 산업입니다.이렇게 다양한 산업 지식, 경험 그리고 기술을 바탕으로 로봇사업부를 키울 수 있었고, 지금의 HCR 시리즈 같은 제품을 시장에 내놓을 수 있게 된 것입니다. 특히 로봇 공학 분야와 소프트웨어 개발에 매우 높은 전문성을 가진 인력을 보유하여 협동 로봇 기술 개발(R&D)을 빠르게 진전시킬 수 있었습니다.　한화정밀기계와 싱가포르 정밀 엔지니어링 전문 업체인 PBA 그룹의 합자법인 "PBA-Hanwha Robotics"의 개소식 모습 / 출처 - 한화정밀기계　　Q. 한화 협동 로봇의 제품 현황과 고객 반응은 어떤가요?한화정밀기계의 협동로봇 HCR-5 / 출처 - 한화정밀기계한화정밀기계는 현재 세 종류의 협동 로봇(HCR)을 출시하였으며, 각각 3kg, 5kg, 12kg의 무게를 들 수 있습니다. 이 세 종류의 협동 로봇은 크기가 작고, 옮기기 쉬우면서 방대한 범위의 업무를 진행할 수 있기 때문에 다양한 업무 지원이 필요한 중소 제조 기업에 이상적인 모델이라 할 수 있습니다. HCR 시리즈의 시장 내 고객 반응은 매우 호의적입니다. HCR 시리즈만이 가진 가장 큰 장점은 사용자가 단일 제어 장치에서 두 개의 HCR 협동 로봇을 실행할 수 있다는 점입니다. 그렇기 때문에 운영비가 최대 10%까지 절감되는 효과가 있죠. 거기에 HCR 시리즈 조작이 쉽다는 점까지 장점으로 작용하면서 시간을 절약하고 생산성을 더욱 높일 수 있습니다.　　기능과 안정성을 모두 잡은 HCR 시리즈만의 디자인　또한, 고객들은 HCR 협동 로봇의 수려한 디자인을 가장 크게 평가합니다. 보통 산업용 기계는 튀어나온 부분들이 있어서 긁히거나 부딪힐 위험이 있는데 HCR은 부드러운 곡선 모양으로 제작되어 안전하고 디자인이 뛰어납니다. 산업 디자인은 보이는 게 전부가 아닙니다. 사람들이 협동 로봇과 같이 일할 때 실제로 안정감을 느낄 수 있어야 합니다. 그런 이유로 더 안전하고 부드럽게 보이도록 곡면을 살려 디자인했습니다. 디자인과 기능 면에서도 HCR 시리즈는 매우 안전한 제품입니다. HCR 협동 로봇은 작업자의 옆에서 업무를 보조하는데, 자동 충돌 감지 기능이 있어서 부딪히면 즉각적으로 작동을 멈춥니다.　2017 iF 디자인 어워드, 제품 디자인 부분에서 본상을 수상한 HCR 협동 로봇 / 출처 - 한화정밀기계　Q. 협동 로봇의 미래에 대한 예측과 향후 개발하고자 하는 협동 로봇은?미래에는 AI와 딥러닝, IoT 등 4차 산업혁명을 대표하는 기술들이 접목된 협동 로봇이 시장을 주도할 것이라 예측합니다. 특히 AI와 딥 러닝 기술로 인해 조만간 로봇 산업에는 큰 지각 변동이 있을 것이라 예상합니다. 원래는 5년이나 10년 주기로 일어날 것으로 생각했는데, 이제는 그것보다 더 앞당겨질 것 같네요. 예전에는 몇 년 더 걸릴 것으로 생각했던 기술들이 AI와 딥러닝 기술이 접목된 지 2년 반 만에 이미 구현되고 있으니까요!그래서 한화정밀기계에서는 앞으로 생산될 제품에 AI나 빅데이터, IoT를 어떻게 접목하고, 실제로 어떻게 적용될 수 있을지에 대해 연구하고 있습니다. AI가 접목된 협동 로봇은 어떠한 상황이나 조건에서도 최대한 쉽게 일을 수행할 수 있습니다. 특히 기술 접목 분야에서 한화그룹은 다양한 산업군과 계열사가 있다는 것이 매우 큰 장점인데요. 다양한 계열사에 자문하면서 실제로 협동 로봇이 어떻게 업무에 적용이 되고, 앞으로 어떻게 발전시킬지 논의하고 있습니다.　협동로봇 합자법인 공장 투어 모습 / 출처 - 한화정밀기계　한화정밀기계의 장우석 부장은 피처폰에서 스마트폰 시대로 바뀌었듯이, 로봇 시장도 향후 몇 년 이내로 큰 패러다임 전환이 일어나리라 전망했습니다. 단순히 몇 개의 일을 수행하는 로봇에서 거의 모든 일을 처리할 수 있는 로봇으로 변화하는 것입니다. 협동 로봇 시장은 아직 초기 단계에 있으며 시장 규모도 매우 작지만, 앞으로의 사업 성장 가능성이 매우 큰 분야입니다.한화정밀기계는 현재 유럽과 동남아시아 시장의 큰 성장 가능성을 두고 사업에 박차를 가하고 있는데요. 단기적인 목표는 시장점유율을 매년 두 배로 늘리는 것이며, 장기적인 목표는 협동 로봇 분야에서 세계적인 선도 기업이 되는 것이라고 합니다.4차 산업혁명에 힘입어 자동차와 스마트 팩토리를 중심으로 기술 트렌드를 이끄는 기업을 목표로, 글로벌 로봇 시장을 선도하는 기업이 되기 위해 끝없는 노력을 거듭하고 있습니다. 점차 확대되는 협동 로봇 시장을 선도하는 한화정밀기계의 미래를 함께 응원 부탁드립니다!#한화 #한화그룹 #한화정밀기계 #구성원인터뷰 #직무정보 #기업정보 #기업문화 #비전 #목표 #채용정보 #공채정보

비트윈에서는 HBase를 메인 데이터베이스로 이용하고 있습니다. 유저 및 커플에 대한 정보와 커플들이 주고받은 메시지, 업로드한 사진 정보, 메모, 기념일, 캘린더 등 서비스에서 만들어지는 다양한 데이터를 HBase에 저장합니다. HBase는 일반적인 NoSQL과 마찬가지로 스키마를 미리 정의하지 않습니다. 대신 주어진 API를 이용해 데이터를 넣기만 하면 그대로 저장되는 성질을 가지고 있습니다. 이런 점은 데이터의 구조가 바뀔 때 별다른 스키마 변경이 필요 없다는 등의 장점으로 설명되곤 하지만, 개발을 쉽게 하기 위해서는 데이터를 저장하는데 어느 정도의 규칙이 필요합니다. 이 글에서는 비트윈이 데이터를 어떤 구조로 HBase에 저장하고 있는지에 대해서 이야기해 보고자 합니다.비트윈에서 HBase에 데이터를 저장하는 방법Thrift를 이용해 데이터 저장: Apache Thrift는 자체적으로 정의된 문법을 통해 데이터 구조를 정의하고 이를 직렬화/역직렬화 시킬 수 있는 기능을 제공합니다. 비트윈에서는 서버와 클라이언트가 통신하기 위해 Thrift를 이용할 뿐만 아니라 HBase에 저장할 데이터를 정의하고 데이터 저장 시 직렬화를 위해 Thrift를 이용합니다.하나의 Row에 여러 Column을 트리 형태로 저장: HBase는 Column-Oriented NoSQL로 분류되며 하나의 Row에 많은 수의 Column을 저장할 수 있습니다. 비트윈에서는 Column Qualifier를 잘 정의하여 한 Row에 여러 Column을 논리적으로 트리 형태로 저장하고 있습니다.추상화된 라이브러리를 통해 데이터에 접근: 비트윈에서는 HBase 클라이언트 라이브러리를 직접 사용하는 것이 아니라 이를 래핑한 Datastore라는 라이브러리를 구현하여 이를 이용해 HBase의 데이터에 접근합니다. GAE의 Datastore와 인터페이스가 유사하며 실제 저장된 데이터들을 부모-자식 관계로 접근할 수 있게 해줍니다.트랜잭션을 걸고 데이터에 접근: HBase는 일반적인 NoSQL과 마찬가지로 트랜잭션을 제공하지 않지만 비트윈에서는 자체적으로 제작한 트랜잭션 라이브러리인 Haeinsa를 이용하여 Multi-Row ACID 트랜잭션을 걸고 있습니다. Haeinsa 덕분에 성능 하락 없이도 데이터 무결성을 유지하고 있습니다.Secondary Index를 직접 구현: HBase에서는 데이터를 Row Key와 Column Qualifier를 사전식 순서(lexicographical order)로 정렬하여 저장하며 정렬 순서대로 Scan을 하거나 바로 임의 접근할 수 있습니다. 하지만 비트윈의 어떤 데이터들은 하나의 Key로 정렬되는 것으로는 충분하지 않고 Secondary Index가 필요한 경우가 있는데, HBase는 이런 기능을 제공하지 않고 있습니다. 비트윈에서는 Datastore 라이브러리에 구현한 Trigger을 이용하여 매우 간단한 형태의 Secondary Index를 만들었습니다.비트윈 HBase 데이터 구조 해부페이스북의 메시징 시스템에 관해 소개된 글이나, GAE의 Datastore에 저장되는 구조를 설명한 글을 통해 HBase에 어떤 구조로 데이터를 저장할지 아이디어를 얻을 수 있습니다. 비트윈에서는 이 글과는 약간 다른 방법으로 HBase에 데이터를 저장합니다. 이에 대해 자세히 알아보겠습니다.전반적인 구조비트윈에서는 데이터를 종류별로 테이블에 나누어 저장하고 있습니다. 커플과 관련된 정보는 커플 테이블에, 유저에 대한 정보는 유저 테이블에 나누어 저장합니다.각 객체와 관련된 정보는 각각의 HBase 테이블에 저장됩니다.또한, 관련된 데이터를 하나의 Row에 모아 저장합니다. 특정 커플과 관련된 사진, 메모, 사진과 메모에 달린 댓글, 기념일 등의 데이터는 해당 커플과 관련된 하나의 Row에 저장됩니다. Haeinsa를 위한 Lock Column Family를 제외하면, 데이터를 저장하기 위한 용도로는 단 하나의 Column Family만 만들어 사용하고 있습니다.각 객체의 정보와 자식 객체들은 같은 Row에 저장됩니다.또한, 데이터는 기본적으로 하나의 Column Family에 저장됩니다.이렇게 한 테이블에 같은 종류의 데이터를 모아 저장하게 되면 Region Split하는 것이 쉬워집니다. HBase는 특정 테이블을 연속된 Row들의 집합인 Region으로 나누고 이 Region들을 여러 Region 서버에 할당하는 방식으로 부하를 분산합니다. 테이블을 Region으로 나눌 때 각 Region이 받는 부하를 고려해야 하므로 각 Row가 받는 부하가 전체적으로 공평해야 Region Split 정책을 세우기가 쉽습니다. 비트윈의 경우 커플과 관련된 데이터인 사진이나 메모를 올리는 것보다는 유저와 관련된 데이터인 메시지를 추가하는 트래픽이 훨씬 많은데, 한 테이블에 커플 Row와 유저 Row가 섞여 있다면 각 Row가 받는 부하가 천차만별이 되어 Region Split 정책을 세우기가 복잡해집니다. RegionSplitPolicy를 구현하여 Region Split 정책을 잘 정의한다면 가능은 하지만 좀 더 쉬운 방법을 택했습니다.또한, 한 Row에 관련된 정보를 모아서 저장하면 성능상 이점이 있습니다. 기본적으로 한 커플에 대한 데이터들은 하나의 클라이언트 요청을 처리하는 동안 함께 접근되는 경우가 많습니다. HBase는 같은 Row에 대한 연산을 묶어 한 번에 실행시킬 수 있으므로 이 점을 잘 이용하면 성능상 이득을 얻을 수 있습니다. 비트윈의 데이터 구조처럼 특정 Row에 수많은 Column이 저장되고 같은 Row의 Column들에 함께 접근하는 경우가 많도록 설계되어 있다면 성능 향상을 기대할 수 있습니다. 특히 Haeinsa는 한 트랜잭션에 같은 Row에 대한 연산은 커밋시 한 번의 RPC로 묶어 처리하므로 RPC에 드는 비용을 최소화합니다. 실제 비트윈에서 가장 많이 일어나는 연산인 메시지 추가 연산은 그냥 HBase API를 이용하여 구현하는 것보다 Haeinsa Transaction API를 이용해 구현하는 것이 오히려 성능이 좋습니다.Column Qualifier의 구조비트윈은 커플들이 올린 사진 정보들을 저장하며, 또 사진들에 달리는 댓글 정보들도 저장합니다. 한 커플을 Root라고 생각하고 커플 밑에 달린 사진들을 커플의 자식 데이터, 또 사진 밑에 달린 댓글들을 사진의 자식 데이터라고 생각한다면, 비트윈의 데이터들을 논리적으로 트리 형태로 생각할 수 있습니다. 비트윈 개발팀은 Column Qualifier를 잘 정의하여 실제로 HBase에 저장할 때에도 데이터가 트리 형태로 저장되도록 설계하였습니다. 이렇게 트리 형태로 저장하기 위한 Key구조에 대해 자세히 알아보겠습니다.Column Qualifier를 설계할 때 성능을 위해 몇 가지 사항들을 고려해야 합니다. HBase에서는 한 Row에 여러 Column이 들어갈 수 있으며 Column들은 Column Qualifier로 정렬되어 저장됩니다. ColumnRangeFilter를 이용하면 Column에 대해 정렬 순서로 Scan연산이 가능합니다. 이 때 원하는 데이터를 순서대로 읽어야 하는 경우가 있는데 이를 위해 Scan시, 최대한 Sequential Read를 할 수 있도록 설계해야 합니다. 또한, HBase에서 데이터를 읽어올 때, 실제로 데이터를 읽어오는 단위인 Block에 대해 캐시를 하는데 이를 Block Cache라고 합니다. 실제로 같이 접근하는 경우가 빈번한 데이터들이 최대한 근접한 곳에 저장되도록 설계해야 Block Cache의 도움을 받을 수 있습니다.비트윈에서는 특정 커플의 사진이나 이벤트를 가져오는 등의 특정 타입으로 자식 데이터를 Scan해야하는 경우가 많습니다. 따라서 특정 타입의 데이터를 연속하게 저장하여 최대한 Sequential Read가 일어나도록 해야 합니다. 이 때문에 Column Qualifier가 가리키는 데이터의 타입을 맨 앞에 배치하여 같은 타입의 자식 데이터들끼리 연속하여 저장되도록 하였습니다. 만약 가리키는 데이터의 타입과 아이디가 Parent 정보 이후에 붙게 되면 사진 사이사이에 각 사진의 댓글 데이터가 끼어 저장됩니다. 이렇게 되면 사진들에 대한 데이터를 Scan시, 중간중간 저장된 댓글 데이터들 때문에 완벽한 Sequential Read가 일어나지 않게 되어 비효율적입니다.이렇게 특정 타입의 자식들을 연속하게 모아 저장하는 묶음을 컬렉션이라고 합니다. 컬렉션에는 컬렉션에 저장된 자식들의 개수나 새로운 자식을 추가할 때 발급할 아이디 등을 저장하는 Metadata가 있습니다. 이 Metadata도 특정 Column에 저장되므로 Metadata를 위한 Column Qualifier가 존재합니다. 이를 위해 Column Qualifier에는 Column Qualifier가 자칭하는 데이터가 Metadata인지 표현하는 필드가 있는데, 특이하게도 메타데이터임을 나타내는 값이 1이 아니라 0입니다. 이는 Metadata가 컬렉션의 맨 앞쪽에 위치하도록 하기 위함입니다. 컬렉션을 읽을 때 보통 맨 앞에서부터 읽는 경우가 많고, 동시에 Metadata에도 접근하는 경우가 많은데, 이 데이터가 인접하게 저장되어 있도록 하여 Block Cache 적중이 최대한 일어나도록 한 것입니다.Datastore 인터페이스비트윈에서는 이와 같은 데이터 구조에 접근하기 위해 Datastore라는 라이브러리를 구현하여 이를 이용하고 있습니다. HBase API를 그대로 이용하는 것보다 좀 더 쉽게 데이터에 접근할 수 있습니다. GAE의 Datastore와 같은 이름인데, 실제 인터페이스도 매우 유사합니다. 이 라이브러리의 인터페이스에 대해 간단히 알아보겠습니다.Key는 Datastore에서 HBase에 저장된 특정 데이터를 지칭하기 위한 클래스입니다. 논리적으로 트리 형태로 저장된 데이터 구조를 위해 부모 자식 관계를 이용하여 만들어 집니다.Key parentKey = new Key(MType.T_RELATIONSHIP, relId); Key photoKey = new Key(parentKey, MType.T_PHOTO, photoId); // 특정 커플 밑에 달린 사진에 대한 키 Datastore는 Key를 이용해 Row Key와 Column Qualifier를 만들어 낼 수 있습니다. Datastore는 이 정보를 바탕으로 HBase에 새로운 데이터를 저장하거나 저장된 데이터에 접근할 수 있는 메서드를 제공합니다. 아래 코드에서 MUser 클래스는 Thrift로 정의하여 자동 생성된 클래스이며, Datastore에서는 이 객체를 직렬화 하여 HBase에 저장합니다.MUser user = new MUser(); user.setNickname("Alice"); user.setGender(Gender.FEMALE); user.setStatus("Hello World!"); Key userKey = new Key(MType.T_USER, userId); getDatastore().put(userKey, user); user = getDatastore().get(userKey); getDatastore().delete(userKey); 또한, Datastore는 Key를 범위로 하여 Scan연산이 할 수 있도록 인터페이스를 제공합니다. Java에서 제공하는 Try-with-resource문을 이용하여 ResultScanner를 반드시 닫을 수 있도록 하고 있습니다. 내부적으로 일단 특정 크기만큼 배치로 가져오고 더 필요한 경우 더 가져오는 식으로 구현되어 있습니다.try (CloseableIterable> entries = getDatastore().subSibling(fromKey, fromInclusive, toKey, toInclusive)) { for (KeyValue entry : entries) { // do something } } Secondary Index 구현 방법HBase는 데이터를 Row Key나 Column Qualifier로 정렬하여 저장합니다. 이 순서로만 Sequential Read를 할 수 있으며 Key값을 통해 특정 데이터를 바로 임의 접근할 수 있습니다. 비트윈에서는 특정 달에 해당하는 이벤트들을 읽어오거나 특정 날짜의 사진들의 리스트를 조회하는 등 id 순서가 아니라 특정 값을 가지는 데이터를 순서대로 접근해야 하는 경우가 있습니다. 이럴 때에도 효율적으로 데이터에 접근하기 위해서는 id로 정렬된 것 외에 특정 값으로 데이터를 정렬할 수 있어야 합니다. 하지만 HBase에서는 이와 같은 Secondary Index 같은 기능을 제공하지 않습니다. 비트윈 개발팀은 이에 굴하지 않고 Secondary Index를 간단한 방법으로 구현하여 사용하고 있습니다.구현을 간단히 하기 위해 Secondary Index를 다른 데이터들과 마찬가지로 특정 타입의 데이터로 취급하여 구현하였습니다. 따라서 Index에 대해서도 Column Qualifier가 발급되며, 이때, Index에 해당하는 id를 잘 정의하여 원하는 순서의 Index를 만듭니다. 이런 식으로 원하는 순서로 데이터를 정렬하여 저장할 수 있으며 이 인덱스를 통해 특정 필드의 값의 순서대로 데이터를 조회하거나 특정 값을 가지는 데이터에 바로 임의 접근할 수 있습니다. 또한, Index에 실제 데이터를 그대로 복사하여 저장하여 Clustered Index처럼 동작하도록 하거나, Reference만 저장하여 Non-Clustered Index와 같이 동작하게 할 수도 있습니다. Datastore 라이브러리에는 특정 데이터가 추가, 삭제, 수정할 때 특정 코드를 실행할 수 있도록 Trigger 기능이 구현되어 있는데, 이를 통해 Index를 업데이트합니다. 데이터의 변경하는 연산과 Index를 업데이트하는 연산이 하나의 Haeinsa 트랜잭션을 통해 원자적으로 일어나므로 데이터의 무결성이 보장됩니다.못다 한 이야기각 테이블의 특정 Row의 Column들에 대한 Column Qualifier외에도 Row에 대한 Row Key를 정의 해야 합니다. 비트윈에서는 각 Row가 표현하는 Root객체에 대한 아이디를 그대로 Row Key로 이용합니다. 새로운 Root객체가 추가될 때 발급되는 아이디는 랜덤하게 생성하여 객체가 여러 Region 서버에 잘 분산될 수 있도록 하였습니다. 만약 Row Key를 연속하게 발급한다면 특정 Region 서버로 연산이 몰리게 되어 성능 확장에 어려움이 생길 수 있습니다.데이터를 저장할 때 Thrift를 이용하고 있는데, Thrift 때문에 생기는 문제가 있습니다. 비트윈에서 서버를 업데이트할 때 서비스 중지 시간을 최소화하기 위해 롤링 업데이트를 합니다. Thrift 객체에 새로운 필드가 생기는 경우, 롤링 업데이트 중간에는 일부 서버에만 새로운 Thift가 적용되어 있을 수 있습니다. 업데이트된 서버가 새로운 필드에 값을 넣어 저장했는데, 아직 업데이트가 안 된 서버가 이 데이터를 읽은 후 데이터를 다시 저장한다면 새로운 필드에 저장된 값이 사라지게 됩니다. Google Protocol Buffer의 경우, 다시 직렬화 할 때 정의되지 않은 필드도 처리해주기 때문에 문제가 없지만, Thrift의 경우에는 그렇지 않습니다. 비트윈에서는 새로운 Thrift를 적용한 과거 버전의 서버를 먼저 배포한 후, 업데이트된 서버를 다시 롤링 업데이트를 하는 식으로 이 문제를 해결하고 있습니다.

 이 포스트는 제가 개발팀에게 했던 세미나를 정리한 것입니다. 개발자와 기획자, 개발자와 디자이너 사이에 의사소통에 대해서 얘기하는 글이 너무나 많습니다. 디자이너(기획자)가 개발자와 일하기 위해 알아야하는 최소한의 개발 용어, 기획자와 개발자가 절대 하지 말아야 할 말들 등등 재밌는 포스트들이 인터넷에 떠돌고 여러 담당자들의 공감과 비판을 사고 있지요. 언제 이야기해도 농담을 주고 받으며 할 수 있는 좋은 주제인 것 같습니다. 그러나 그런 글들은 해당 개발자 또는 기획자가 쓴 글이기 때문에 바이어스가 걸리기 마련이지요. 우스갯소리로 넘기기에는 껄끄럽고 진지하게 받아들이기에도 껄끄럽죠. 왜 이런 말들이 이렇게 많이 나올까요? 왜냐하면 실제로 그들이 대화하는 방식이 너무나 다르고 서로가 하는 일을 이해하기 힘들기 때문입니다. 서로간에 말이 정말 잘 통했다면 그럴 일이 없겠지요. 심지어 화성에서 온 개발자 금성에서 온 기획자라는 말이 한 때 많이 나돌아 다녔지요.UI/UX도 모르면서...결국 게시판 만들라는 거잖아요이런걸 기획서라고 써오다니...아니 그걸 다 된다고 하면 어떡해요이거 하나 바꾸는게 그렇게 어려운가요?언제까지 가능한지만 얘기해주세요여기서는 되는데 우리는 왜 안되나요?개발 공부 할거에요! 공감 하시나요? 저는 개발자이지만 한번 기획자의 입장에서 왜 그렇게 할 수 밖에 없었는지 핑계를 대보겠습니다. 도대체 기획자는 저딴 방구인지 말인지 모를 말들을 할까요? 와이컴비네이터의 폴 그래햄의 유명한 에세에인 Do things that don’t scale의 한국어 요약본입니다. 영어가 싫고 1분1초가 아까운 여러분을 위해서 준비했습니다 :) 읽어보시면 스타트업에서 처음부터 규모가 큰 작업을 하거나 그것을 자동화하는 일이 얼마나 위험한 일인지 간접적으로 느끼실 수 있을것 같아요. 그 중에 일부만 발췌하여 말씀드리면1. 모집 : 사람들은 많은 선택권을 가지고 있기 때문에 우리 제품을 써야할 필요가 없음그들을 선택하려면 빠른 프로토타입이 필요하고 요구사항에 맞춰 변화할 필요가 있음2. 황홀감 : 모든 유저들에게 황홀한 수준의 경험을 제공해야하는데 엔지니어 교육과정중에 유저 만족에 기울어야한다는 내용이 없어서 생각하기 힘듬3. Meraki : 하드웨어 벤처의 경우 수동으로 기계를 생산/조립하면서 기존에는 알지못했던 핵심 요인들을 발견할 수 있음4. 수동 : 초기에는 소프트웨어가 할일을 사람이 직접하는게 좋을 수도 있음.수동으로 해결하다가 해결책을 자동화하는 것은 확실한 고객을 확보할 수 있지만, 처음부터 자동화된 해결책으로 아무런 문제도 해결하지 못한다면 확실한 실패로 이어짐5. 대형 : 처음부터 큰 스케일로 일을 벌인다고해서 성공으로 이어지는 건 아님. 수동을 싫어하기 때문에 크게 일을 벌리는 것은 큰 실패로 이어짐.큰 버그가 아니고 시장 진입 타이밍이 중요하다면 바로 출시할 수도 있다 이 중에서도 저는 4번의 수동이라는 덕목을 가장 중요하게 생각합니다. 개발자라는 족속들이 수동을 굉장히 싫어하는 경우가 많습니다. 수동은 쿨하지 않거든요. 그래서 모든 것을 자동화시키려고 하죠. 자동은 쿨하니까요. 어떤 포털사이트의 랜딩 페이지를 개발해야하는 프로젝트가 생겼다고 예를 들어봅시다. 개발자는 생각합니다.매일매일 갱신되는 랜딩페이지를 만들자. 좋아요와 댓글이 많은 글들을 최신순으로 정렬하여 보여주는데 매일 자정에 랜딩 페이지가 새로운 내용으로 갱신되는게 좋겠다. 이미 한번 게시되었던 글은 다시는 게시되지 않도록 구성해야겠군. 좋아요와 댓글의 가중치는 1:2 정도가 좋겠지? 이렇게 랜딩 페이지를 하나 구성하는데 엄청난 노력과 시간을 투자합니다. 기획자 또는 마케터는 왜 이렇게 일이 오래걸리는지 답답해하죠. 빨리 출시해서 고객들의 반응을 보고 싶은데 개발이 늦어지니까요. 사실 고객들은 포털 사이트의 메인 컨텐츠가 자동으로 구성되던 수동으로 구성되던 관심이 없어요. 그건 기획자 또한 마찬가지지요. 그들에게 어떤 컨텐츠를 보여줘야 좋아할까 고민하지요. 심지어 그전에 랜딩 페이지라는 기능이 유효한지 증명되지도 않았지요. 실제로 이전에 제가 만들었던 시크릿차트라는 서비스에서 병원의 랭킹을 계산하여 유저들에게 보여주는 기능을 만들 때도 비슷한 일이 있었습니다. 병원 랭킹 기능이란 각 병원이 언급된 블로그와 카페 글을 스크레이핑하여 몇 개인지 세고 데이터베이스를 쌓고 블로그와 카페 글이 많은 순서대로 정렬하여 보여주는 기능입니다. 처음에 저도 욕심이 생기는 겁니다. 검색 포털의 API를 이용하여 스크레이핑 봇을 만들고 데이터베이스를 구축해주는 프로그램을 만들고 싶었습니다. 그 프로그램을 만드는데는 테스팅까지 약 1주일이라는 시간이 꼬박 들겠지요. 그래도 굉장히 쿨하고 재밌어 보였습니다. 그러나 그 욕망을 꾹 참고 수동으로 세서 데이터베이스를 구축하기로 결심합니다. 검색 포털에서 검색하여 나온 숫자를 눈으로 직접 보고 데이터베이스에 직접 접근하여 수동으로 입력하는 방식입니다. 저는 기획자와 다른 개발자에게도 입력하는 것을 도와달라고 협조를 요청했습니다. 그렇게 2일만에 우리는 데이터베이스를 구축했고 빠르게 배포하여 고객의 반응을 살폈습니다. 고객의 반응을 살펴보던 기획자들은 그 기능이 정말 잘 작동하고 고객들이 좋아한다는 것을 증명해냈고 저는 그제서야 API를 이용하여 모든 것을 자동화했지요. 우리는 자동화의 욕심을 버려야합니다. 물론 시간과 비용, 효율을 따져서 해야겠지요. 효율을 따지는 것은 여러분이 더욱 능숙하실거라고 생각합니다. 우선은 간단한 예로 비개발자들이 왜 요상한 말과 행동을 하는지 알아보았습니다. 그러면 개발자인 우리는 그들에게 어떻게 이야기해야할까요? 어떻게 해야 싸우지 않고 일할 수 있을까요? 애자일 개발방법론 중에 하나인 익스트림 프로그래밍에서도 이야기하듯이 지식 섬 현상(Islands of Knowledge)은 굉장히 위험한 요소입니다. 서로가 이해하는 것이 다르기때문에 계속적인 커뮤니케이션을 통해 지식 섬을 없애야합니다. 저는 그 지식섬을 없애기 위한 실질적인 방법을 소개하려고 해요.조카에게 설명하듯이1. 훈민정음 아시겠지만 개발 용어는 절대 금지입니다. 정말로 필요한 경우가 아니면 절대 개발 용어를 쓰지마세요.2. ABC 제목만 보면 훈민정음 룰과 반대되는 내용인 것 같죠? 예를 들어서 설명할게요. 태그 기능을 만든다고 합시다. 그런데 거기서 기획서에 나오지 않은 허점을 우리는 발견했습니다. 손가락을 이리저리써가며 태그가 여러개가 되었을 때 꼬이는 현상을 설명하려 하지마세요. 태그A, 태그B, 태그C 이렇게 설명하세요, 또는 "가나다"도 좋겠군요.3. 연필 & 종이 미팅을 할때 무조건 연필과 종이를 챙겨가세요. 그리고 말보다는 그림을 그려가며 설명하세요. 종이를 아끼지 말고 최대한 자세하게요. 또는 미리 정리한 문서를 준비해가세요. 문서를 보면서 설명하면 빼먹지않고 더 잘 설명할 수 있지요.4. 메타포를 사용하라 익스트림 프로그래밍에도 나오듯이 시스템 전체 또는 기능 전체를 하나의 메타포로 정의하여 설명하는 방법입니다. 현재 제가 만들고있는 IoT 관제 솔루션의 뒷면에는 기획자 또는 디자이너가 절대 이해하지 못할 프로토콜이라고 불리는 부분이 있습니다. 우리는 프로토콜을 어떻게 개발자가 아닌 사람에게 설명해야 할까요? 저는 커피머신을 메타포로 사용하여 설명하겠습니다. 우리는 제품으로부터 raw data라는 가공되지 않은 커피빈을 받습니다. 그냥 겉으로만 보면 어떤 유용한 데이터를 가지고 있는지 전혀 모르죠. 커피빈을 볶고 갈아서 사람이 마실만한 에스프레소를 만듭니다. 거기에 우유, 크림, 초콜릿 등을 더해서 다른 사용자가 좋아할 만한 또다른 커피도 만들 수 있겠죠. 데이터베이스를 모르는 사람들이 보는 깔끔한 그래프가 나오는 화면은 아메리카노, 라떼 등으로 비유할 수 있겠군요. 정말 조카에게 설명하듯이 쉽게 친절하게 설명하시면 됩니다. 그럼 다음으로 여기서 한발짝 더 나아가서 심화학습을 해보죠. 우리는 개발자로서 비개발자인 그들에게 어떻게 해주면 더 좋을까요?1. 기획의도를 이해하기 왜 이렇게 기획했는지 이해하면 좋습니다. 유저의 요구사항이 무엇이고 왜 그런 요구를 했는지 Back-log를 알면 개발이 더 쉬울 뿐만 아니라 빠르게 배포할 수 있을지도 모릅니다. 예를 들어 배포 30분전에 버그가 발견되었습니다. 개발자는 "헉, 버그다."이러면서 열심히 고치겠지요. 그러면서 기획자에게 배포를 내일해도 되냐고 물어봅니다. 기획자는 안된다고 하고 또 싸우겠죠. 만약 기획의도를 이해한다면 이 싸움이 필요하지 않을지도 모릅니다. 해당 기능을 작동시키는데 있어서 크리티컬한 것이 아니면 서비스를 우선 배포하고 이 후에 고쳐도 되겠지요. 또는, 마케팅이나 시장은 타이밍이 중요하기 때문에 기능 구현의 우선순위를 기획자가 잡아줄 수도 있습니다.2. 프로토타입을 빠르게 개발자는 코드로 이야기합니다. 그러나 비개발자는 이해 못합니다. 움직이는 프로토타입은 고객뿐만 아니라 동료의 이해도를 드라마틱하게 높일 수 있지요.3. 계속해서 점검받기 점검받는다고 그들의 아래에 있는 것이 아닙니다. 우리는 프로젝트를 완수하기 위해 각자 다른 역할을 수행하고 있는 동등한 존재임을 잊지맙시다. 개발자는 비개발자에게 계속해서 움직이는 프로토타입을 보여주고 피드백 받으면서 지식의 섬을 없애나가야 합니다. 고객들이 원하는대로, 기획자들이 기획한대로, 디자이너 디자인한대로 구현하는 것이 프로젝트에서는 무엇보다도 중요하니까요.4. 데드라인은 꼭 지키기 데드라인을 지키는 것은 개발자와 비개발자간에 신뢰관계를 높이는 방법 중에 개발자가 할 수 있는 가장 효과적인 방법입니다. 또한 고객과도 마찬가지죠. 약속을 지키지 못하는 회사의 제품을 사가는 사람은 없습니다.  우리는 서로에 대해 너무 조금만을 알고 있습니다. 그래서 서로의 입장을 모르고 문제가 생기기 마련이지요. 당연히 서로에 대해 자세히 알 필요는 없지요. 우리팀에서 프로젝트를 망치고 싶어하는 사람은 없습니다. 그러나 상황이, 그리고 오해가 프로젝트를 망치게 하지요. 그리고 누구나 똥을 쌉니다. 서로 부족한 점이 있으니 부족한 점을 욕하기보다는 부족한 부분을 채우기위해 영역을 넓혀가는 건 어떨까요? 저건 내 일이 아니니 알아서 되겠지라는 태도보다는 다 같이 고민하며 빈 공간을 채우는 편이 좋다고 생각합니다. 서로를 비난하면서 프로젝트를 할 것인가, 서로를 이해하는 마음가짐으로 즐겁게 프로젝트를 할 것인가... 선택은 당신의 손에 달렸지요.#비주얼캠프 #인사이트 #경험공유 #조언 #개발자 #개발팀 #협업 #팀워크

들어가기 전: 실제로 프로젝트와 팀원들과의 작업 환경을 구축한 경험을 바탕으로 작성했습니다. 한마디로 실화. Overview소스를 수정할 때마다 지속적인 테스트를 하기 위해 AWS lambda 로컬 테스트 환경, SAM을 결합해서 환경을 구축했습니다. 이번 글에서는 팀원을 추가하고 CodeCommit을 리포지토리로 사용하는 것도 소개하겠습니다. 예상 구성도테스트 환경 구축, 도저언!1. 팀원 추가하기 IAM 서비스를 이용해서 프로젝트를 같이 사용할 유저를 추가합니다. IAM에 유저를 추가하면 AWS 콘솔을 같이 사용할 수 있습니다. 사용자 추가를 클릭해 유저를 추가합니다. 팀원마다 한 개의 계정을 추가해야 합니다. 사용자 세부 정보 설정 > 엑서스 유형에서 ‘프로그램 방식 엑서스’와 ‘AWS Managrment Console 엑서스’를 체크합니다. 여기에서는 개발2팀 팀원인 강원우 과장의 계정을 생성했습니다.1) 비번은 귀찮으니 미리 세팅해둡시다. 유저 계정은 그룹을 생성해서 관리하면 편합니다. 그룹을 사용하면 보다 편리하게 계정 권한을 제어할 수 있기 때문입니다. 이번 예제에서는 그룹 이름을 codeStarGroup으로 만들었습니다. AWSCodeStarFullAcess를 정책으로 설정하고 ‘그룹생성’을 클릭해 그룹을 추가합니다. 2) codeStarGroup에 체크한 후, ‘다음: 검토’를 클릭해 진행합니다.‘사용자 만들기’를 클릭해 생성을 마무리합니다.계정 추가를 완료했습니다.사용자 이름(위의 예시에서는 kanggw)을 클릭하고, 뒤이어 ‘보안자격 증명’ 탭을 클릭합니다.콘솔 로그인 링크를 공유합시다. 링크를 입력하고 들어가면 그룹 로그인이 활성화가 되어있다는 걸 볼 수 있습니다.2. CodeStar 설정하기 프로젝트 인원을 무사히 추가했습니다. 이제 프로젝트를 만들어 봅시다. CodeStar 프로젝트 세팅 방법은 R&D본부 윤석호 이사님이 쓴 ‘애플리케이션 개발부터 배포까지, AWS CodeStar’를 참고해주세요.새 프로젝트를 생성합니다.python AWS Lambda를 선택합니다.프로젝트 이름은 ‘admin-lambda-API’로 입력하겠습니다. 그 후에 ‘다음’을 클릭합니다.‘프로젝트 생성’을 클릭합니다.우리는 Git을 이용해 로컬에서 직접 관리할 것이므로 ‘명령행 도구’를 선택한 후, ‘건너뛰기’를 클릭합니다.3분 만에 프로젝트가 생성되었습니다. 참 쉽죠?3. 프로젝트에 팀원 추가하기프로젝트를 같이 하려면 팀원을 추가해야겠죠. 팀원 추가는 codeStar 대시보드 좌측의 ‘팀’ 탭을 클릭하면 됩니다.‘팀원 추가’ 클릭IAM에서 등록한 팀원의 정보를 불러옵니다. ‘추가’를 클릭해 팀원을 추가합니다. 여기에서 중요한 사실 하나! 프로젝트의 소유자로 지정해야 소스 접근 및 코드 변경이 가능합니다.4. 코드 체크 아웃앞서 설명한 것처럼 직접 Git으로 소스를 받아야 하기 때문에 codeCommit으로 이동합니다. codeStar 대시보드 왼쪽 ‘코드’ 탭을 클릭하면 코드 내역들을 확인할 수 있습니다.‘URL 복제 > HTTPS’를 클릭해 경로를 복사합니다. 소스를 클론하기 전에 계정에 깃허용을 먼저 해주세요. IAM 돌아와서는 계정 설정을 변경해야 합니다.사용자 > kangww > 보안 자격 증명 탭 클릭 > HTTPS Git 자격 증명 > 생성Git에서 사용할 ID와 비밀번호를 받았습니다. 해당 정보를 팀원에게 전달합니다. 이제 workspace로 이동해 체크아웃을 시작합니다.git clone [복사한 경로] [id 입력] [pw 입력] clone이 완료 되었습니다. 이제 기본 프로젝트가 들어있기 때문에 바로 실행할 수 있습니다. 미리 설치된 SAM으로 실행해보겠습니다.이제 해당 경로에 이동해 SAM을 돌려서 정상적으로 구동되는지 확인해봅시다. (SAM설치 방식은 부록에서 소개합니다.) sam local start-api -p 3333 성공적으로 SAM이 구동되었습니다. (짝짝) http://localhost:3333 으로 접근해 결과를 확인할 수 있습니다. 이제 로컬에서 작업을 진행하면서 바로 바로 확인이 가능해졌습니다. 만약 동료와 함께 개발한다면 아래처럼 구동해야 자신의 IP에 접근할 수 있습니다.sam local start-api -p 3333 -host [자신의아이피] 글을 마치며CodeStar의 관리와 배포 기능은 강력합니다. 많은 부분을 알아서 해주니 고마울 뿐입니다.3) 이제 Lambda의 local 테스트 환경인 SAM을 이용해서 배포 전 과정까지 간편하게 테스트를 해보세요. 배포의 복잡함을 codeStar에서 해결하고 테스트를 하거나 개발을 할 때는 SAM을 이용해 효율적으로 업무를 진행합시다.글 쓰면서 발견한 다섯 가지1) codeDeploy > executeChangeSet 에 구동될 때 cloundFormation 이 자동 세팅 됩니다. 엄청 편합니다. API 배포가 진행되면 lambda에서 바로 수정하는 게 편합니다.2) codeCommit은 https 보다 ssh방식을 권장하며, https방식으로 하다가 꼬이면 여기를 클릭해 해결하세요.3) codeStar는 다음과 같은 추가 구성을 자동 세팅합니다.codeStar 용 S3 버킷codePipeLine용 S3 버킷cloundFormation 세팅lambda 세팅4) IDE를 cloud9을 사용하면 EC2 및 EBS가 생성되니 주의하세요. 그리고 생각보다 느립니다.5) 로컬에서 Git push를 하면 약 5분 정도 뒤에 최종적으로 배포됩니다.부록1)SAM을 설치하기 전, 여기를 클릭해 docker를 미리 설치하세요.2)SAM 설치 안내는 여기를 클릭하세요. ( npm install -g aws-sam-local )참고1)강원우 과장은 귀여운 두 달팽이, 이토와 준지의 주인이기도 하다. 2)AWSCodeStarFullAcess는 codestar 접근에 대한 권한을 부여한다.3)자동 배포까지 2~5분 정도 걸리는 게 어렵게 느껴질 수 있다.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유