우선 EOS BP 투료를 한 번쯤 해보신 분들은 매번 새롭게 등장하는 BP 후보들은 넘쳐나고 그들의 이름과 공약을 확인하는 것이 귀찮다고 느끼셨을 수 있습니다.또한 어렵게 공약을 확인하고 정말 이 팀이 EOS를 위해 무엇을 할 수 있는지 다른 팀들과 어떤점이 다른지 꼼꼼하게 비교하여 선거한 여러분의 소중한 투표권 파워는 시간이 지날수록 가치가 줄어들게 됩니다.그렇다면 나 대신에 꾸준히 선거를 대신해줄 사람이 있다면 얼마나 좋을까요?사실 이런 문제에 대해 EOS도 알고 있었으며, 어떤 해결 방법이 있을지 생각해왔습니다.그래서 바로 만들어진 것이 EOS Proxy Voting입니다.Proxy란 ‘대리인’이란 의미를 갖고 있습니다.따라서 EOS Proxy Voting은 EOS BP 대리 투표 시스템을 뜻합니다.이 대리인 투표권을 신청하게 되면 여러분은 더 이상 투표에 대해 고민하실 필요가 없게 되는 거예요!이제 이 Proxy 시스템을 어떻게 이용하는지 방법을 소개하고자 합니다.1. 어떻게 Cleos를 통해 다른 사람에게 나의 투표 권한을 넘길 수 있나요?나의 투표 권한을 Cleos를 통해 다른 사람에게 넘기기 위해선 다음과 같은 명령어를 입력해야합니다.간단하지요? 이 명령어는 eosaccount12가 자신의 투표 권한을 proxyvoter34에게 넘기겠다는 의미를 갖고 있습니다.2. 어떻게 툴킷을 통해 다른 사람에게 나의 권한을 넘길 수 있는 건가요?대표적으로 https://eostoolkit.io/vote/setproxy에서 Proxy를 설정하는 방법을 안내해드릴게요! (참고로 https://www.myeoskit.com/#/tools/proxy/https://eosvoter.eosphere.io 에서도 가능합니다. )나의 proxy를 툴킷을 통해 다른 사람에게 넘기기 위해선 먼저 Scatter 구글 확장 프로그램을 설치해야 합니다.Scatter 설치 후 EOS 계정 및 접속 정보를 Scatter에 등록하셔야 합니다. (Scatter에 정보를 등록하는 방법은 곧 업데이트 하도록 하겠습니다.)그렇다면 등록을 다 하셨을 테니 다음으로 넘어가겠습니다.우선 EOStoolkit에 접속하셔서 스캐터 계정으로 로그인하셔야 합니다.로그인 하셨다면 이제 왼쪽 카테고리에서 [Manage Voting] 항목을 보실 수 있을거에요![Manage Voting]를 클릭하시면 Voting에 관한 여러 항목이 촤르르 나오게 되는데 그 중에 [Set Proxy]를 눌러주세요!자 그럼 아래 화면에 나온 대로 그대로 따라하신 후 저장만 해주시면 됩니다.드디어 투표 권한을 지정 Proxy에게 넘기게 되었습니다.3. 어떻게 내가 설정한 Proxy를 해제할 수 있나요?Proxy 지정을 하고 며칠동안 투표에 신경을 쓰지 않았다가 오랜만에 들어간 투표 사이트에서 내가 지정한 대리인이 행사하는 나의 투표권이 마음에 들지 않을 땐 어떻게 해야할까요?해제를 해야겠지요!그렇다면 지금 내가 지정한 Proxy가 마음에 안들어서 해제하고 싶을 때는 어떻게 할지도 알아보겠습니다.Proxy 설정을 했다면, 저 네모박스에 체크되어 있을겁니다. 그 체크를 해지 하면 간단하게 내가 설정한 Proxy를 해제하게 되는 것입니다.아주 간단하네요.그럼 이제 다음은 내가 직접 Proxy가 되기 위해선 어떻게 할 수 있을지 알아보겠습니다.그 방법도 마찬가지로 Cleos 또는 Toolkit 과 Scatter를 통해 할 수 있습니다.4. Cleos를 통해서 내가 직접 Proxy가 될 수 있는 방법은 어떤게 있나요?내가 직접 Cleos를 통해 Proxy가 되기 위해선 다음과 같은 명령어를 입력해야합니다.이 명령어는 proxyvoter34는 Proxy로 지정되었는 의미를 갖고 있습니다.5. 어떻게 툴킷을 통해 내가 직접 Proxy가 될 수 있는 건가요?우선 툴킷을 통해 Proxy로 등록하기 위해선 가장 먼저https://eostoolkit.io/vote/setproxy 에 나의 Scatter 계정으로 로그인해야 합니다.(참고로 https://www.myeoskit.com/#/tools/proxy/https://eosvoter.eosphere.io 에서도 가능합니다. )로그인 하셨다면 왼쪽 카테고리에서 [Manage Voting]을 찾아주세요!찾으셨다면 해당 항목의 아래 항목에서 [Create Proxy] 를 클릭해주세요. 그럼다음과 같은 화면이 나오게 됩니다.아래 나와있는 설명 그대로 적어주시고 저장해주시면 됩니다. 다 완료하셨으면 드디어 Proxy가 되셨어요!6. 더이상 Proxy로 활동하고 싶지 않으면 어떻게 해야 하나요?더 이상 Proxy로서 활동을 하고 싶지 않다면 마찬가지로 [Manage Voting]를 통해 Proxy 철회를 할 수 있습니다.[Manage Voting]를 클릭 후 아래 항목에서 [Resign Proxy]을 누르시면 됩니다. 첫 번째 Resign 버튼은 Proxy 등록을 해지하는 것이고 두 번째 Unregister 버튼은 등록한 정보를 삭제하는 버튼입니다.각각의 버튼을 눌러 그대로 진행하시면 Proxy 철회가 완료될 거예요!자 여기까지 이제 EOS Proxy Voting을 하기 위해Proxy 설정하는 방법을 알아보았습니다. 어렵게 보이지만 Scatter 연동만 하면 Proxy를 설정하거나 내가 직접 Proxy가 되는 것은 어렵지 않습니다!아 참고로, 현재 등록된 모든 Proxy 리스트를 Aloha EOS Proxy Research Portal에서 확인할 수 있습니다.또한 해당 사이트에서 Proxy들이 자신들이 Proxy로 활동하면서 어떻게 투표를 행사할 것인지에 대한 공약도 자세히 나와있으니 한 번쯤 들어가서 보시면 Proxy를지정하는 데에 있어서도, 내가 직접 Proxy가 됨에 있어서도 도움이 될 거예요!#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

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이 있으므로, 한 번쯤 찾아보며 공부해보시면 좋겠습니다.

1월부터 4월까지 한 시즌에 걸쳐 트레바리 홈페이지를 다시 구현하였다. 겉으로 보이는 UI/UX 디자인 개편을 넘어, DB 설계와 서버 및 웹 페이지 개발까지 새롭게 진행했다. 기존의 홈페이지를 완전히 버리고, 새로운 아키텍처를 가진 홈페이지를 구현하여 데이터를 이전하는 일이었다.4개월 동안 반응형 웹 사이트 1개, 크루/파트너 어드민 사이트 2개와 함께 서버까지 구현했다..지난 시즌 동안 홈페이지의 여러 기능들을 개선하면서 변화가 필요하다고 생각했다. 단순히 '남이 짜둔 코드가 별로예요'에서 나온 불편 때문만은 아니었다. 회사가 겪는 빠른 성장에 발맞춰 시스템이 뒷받침이 되어줘야 하는데 기존의 아키텍처로는 그러기가 어려웠다. 적은 트래픽에도 툭하면 죽는 서버 덕에 접속이 몰리는 멤버십 신청 기간 동안에는 서버 비용을 배로 늘려야 했고, 푸시 알림의 필요성으로 모바일 앱을 구현하고 싶어도 별도의 API 서버가 존재하지 않아서 시도하기 힘들었다. 결국 지난 시즌 말, 홈페이지를 새로운 아키텍처에서 다시 구현하겠다는 호기로운 결정을 내렸다.처음 시작할 때만 해도 아주 큰 어려움은 없겠거니 했다. 트레바리 입사 이전에 여러 프로젝트를 턴키로 수주받아 진행했던 경험이 있었기 때문이었다. 그러나 몇천 명, 많게는 몇만 명이 접속하는 운영 중인 서비스를 만들어 이전하는 일은 새 서비스를 만드는 일과는 또 다른 일이었다.게다가 이전 글에서 이야기했던 것처럼 트레바리에는 풀타임으로 일하는 개발자나 디자이너가 나 혼자이기 때문에 해야 하는 일이 절대적으로 많았다. 개발 맨 아랫단부터 웹 페이지의 디자인까지 기간 내에 해내는 것은 쉽지 않은 일이었다. 덕분에 매일이 도전이었던 4개월을 보냈고, 런칭 3주 전쯤에는 잠시 슬럼프를 겪기도 했다. 하지만 트레바리가 한 번은 꼭 겪어야 하는 과제였기에 꾸역꾸역 해내면서 런칭까지 왔다. 오늘은 그 이야기를 정리해보려고 한다.리라이팅왜, 무엇을 했나요?1. 과도한 서버 비용과 느린 속도홈페이지를 다시 만들어야겠다는 생각을 가장 많이 하게 된 이유는 비용과 속도였다. 동시 접속 유저 수가 천 명이 안 되는 서비스에서 월 100만 원가량의 서버 비용이 나왔고, 평균 페이지 로딩 속도가 3초를 넘어갔다.그동안 트레바리 홈페이지는 여러 프리랜서 개발자들이 거쳐가며 유지되느라 DB나 쿼리 구조에 대한 고민을 장기적으로 해볼 기회가 없었다. 요청받은 기능을 구현하기 위해 필요한 테이블을 그때그때 만들고, 활용할 데이터가 다른 테이블에 있다면 조인을 해서 불러왔다. 그 결과 대부분의 데이터 요청에 n+1 쿼리가 존재했고, 한 명의 유저가 한 번의 접속만으로도 수많은 쿼리 요청을 하는 상황이었다.최대한 기존의 홈페이지에서 이를 해결해보려고 노력했다. 처음 입사했을 때만 해도 10초 이상의 시간이 들었던 독서모임의 리스트 요청을 3초까지 줄이고, 접속자 수가 40%가 늘어났어도 서버 비용을 늘리지 않을 수 있었다. 그러나 상대적으로 빨라졌을 뿐 느린 편이라는 점은 변함이 없었다. 매 시즌 멤버 수가 30~40% 씩 증가하는 추세대로라면 다음 시즌에도 비슷한 비용을 유지할 수 있을 거란 보장 또한 없었다.여기서 더 개선하려면 DB 구조를 변경하고, 수많은 코드를 갈아엎어야 했다. 필요하다면 하면 되는 일이었지만 기존의 아키텍처인 레일즈 웹 애플리케이션을 유지한다면 당장의 퍼포먼스를 개선하더라도 언제까지 높은 퍼포먼스를 유지할 수 있을지 의문이었다. 성장에 따라 요구되는 시스템들을 다 지원해줄 수 있을지도 미지수였다. 언젠가 아키텍처를 변경해야 한다면 최대한 빠른 시일인 지금 하는 것이 효율적이라 판단했다.Heroku에서 관리하던 서버를 AWS의 EC2로 변경하면서 DB 또한 PostgresSQL에서 AWS 의 DynamoDB로 이전했다. RubyOnRails를 사용하여 단일 웹 애플리케이션으로 구현했던 홈페이지를 Typescript를 기반으로 프론트엔드와 백엔드를 나눴다. React로 사용하여 웹사이트를 구현하였고, Node.js로 GraphQL을 적용하여 서버를 구현하였다.덕분에 월 100만 원가량이 들던 비용을 월 30만 원까지 낮출 수 있었다. 속도는 이전보다는 빨라졌으나 기대만큼 빨라지지는 않아 캐싱 등을 적용하여 차츰 줄여나가고 있다. 변경한 현재 아키텍처로는 트래픽이 늘어나더라도 이전처럼 비용을 배로 늘리지 않아도 되었으며, 다양한 방법으로 속도를 개선하는 작업도 시도해 볼 수 있게 되었다.2. 기술 부채기술 부채가 쌓인 모습 (...)이미지 출처: 스마트스터디앞서 말했던 것처럼 기존 홈페이지는 여러 프리랜서 개발자들이 거쳐간 터라 뻔하게도 기술 부채가 쌓였다. 홈페이지와 관련된 문서는 없고, 크루들은 사용하는 기능들을 부분적으로만 알고 있었다. 그런 상황에서 몇 명의 크루들이 퇴사와 입사를 거치니 그나마 구전으로라도 유지되던 홈페이지 정보가 점점 사라졌다.홈페이지에 대해 궁금한 점이 생기면 직접 코드를 뒤적이며 파악해보는 수밖에 없었다. 그래서 모든 크루들이 유일한 개발자인 나에게 물어보는 것 말고는 홈페이지에 대해 알 수 있는 다른 방도가 없었다. 이 외에도 새로운 기능을 구현했더니 미처 파악하지 못한 곳에서 버그가 터진다거나, 안 쓰는 줄 알고 삭제한 코드가 사실 어디선가 제기능을 하고 있거나 하는 때도 잦았다.이런 기술 부채를 청산하려면 1) 대부분의 기능들을 파악하고 있는 담당자가 있고 2) 지원하는 기능들을 잘 정리한 문서가 필요했다. 1번은 직접 처음부터 리라이팅을 진행했으니 자연스레 해결되었으나, 다른 크루들도 많은 기능들에 대해 파악하고 있으면 더 효율적일 거라 생각했다. 그래서 새로 구현되는 기능이나 변경 사항에 대해서 매주 주간 회의 때 공유를 하고 있으며, 배포를 할 때마다 실시간으로 에버노트와 슬랙의 배포 노트 채널을 통해 배포 내용을 공유하고 있다. 이전에도 하고 있었으나 더 잘, 자주, 자세히 해야겠다고 새삼 깨달았고 노력 중에 있다.2번을 위해서는 홈페이지 기능 설명에 대한 문서를 작성하기 시작했다. 아직 가장 효율적인 포맷이 무엇인지는 찾지 못해서 방황하고 있지만 최대한 쉽고 자세하게 쓰는 방향으로 진행 중이다.사랑과 따뜻함이 넘치는 우리 크루들 3. 복잡하고 이유 없는 UI기존의 홈페이지는 의외로(?) 다양한 기능들이 있었지만 유저들이 모르거나 사용하지 않는 경우가 많았다. 대부분의 기능들과 인터페이스들이 중요도에 대한 고민 없이 '있으면 좋을 것 같다'는 이유로 덕지덕지 추가되었다. 게시판이나 다이어리 같은 메뉴들은 사용률이 채 5%가 안되지만 상단 메뉴에 자리 잡고 있었고, 북클럽 리스트의 페이지에는 딱 한 번만 읽으면 되는 설명글이 화면의 반을 차지하고 있었다.멤버들이 트레바리에서 가장 활발하게 누려줬으면 좋겠다고 생각하는 활동은 독서모임과 이벤트다. 내 클럽이 아닌 다른 다양한 클럽에도 참여해보고, 살면서 해보지 못한 경험들을 이벤트를 통해 체험해봤으면 좋겠다. 그런 고민으로 상단 메뉴에는 독서모임과 이벤트, 내 활동 정보를 볼 수 있는 마이페이지만 배치하였고 FAQ나 공지사항과 같은 자잘한 것들은 하단의 footer로 내리거나 일부 기능들을 임시적으로 지원하지 않기로 했다.리라이팅 전리라이팅 후직관적인 UI는 파트너 어드민에서도 절실하게 필요했다. 기존의 어드민 UI는 따로 교육이 필요할 정도로 복잡했기 때문이었다. 한 명의 파트너에게 자신이 관리하는 클럽 외의 모든 클럽 정보가 노출되었다. 클럽 정보에서도 봐야 할 정보와 보지 않아도 될 정보가 혼재되어 보이고 있었다. 파트너의 수는 점점 늘어나는데 그때마다 홈페이지까지 교육까지 따로 해야 하는 것은 리소스가 많이 드는 일이었다.파트너가 자신의 모임을 이끌기 위해 정말 필요한 일에만 집중할 수 있도록 신경 써서 구현했다. 모임에 참석하는 멤버 리스트, 모임에서 읽을 책과 발제문 등을 등록하고 수정하는 페이지, 출석 체크를 할 수 있는 기능만으로 구성했다. 항시 봐야 하는 매뉴얼과 FAQ는 따로 메뉴로 빼두었다.파트너 어드민의 모임 정보 설정 페이지 리라이팅 전과 후4. 데이터로 소통하는 회사트레바리는 점점 데이터로 소통하는 회사가 되고 싶다. 어떤 유저가 어디에서 불편을 겪고, 어떤 부분을 좋아하는지 알고 싶다. 사람들이 독서모임에 만족하면 홈페이지에서 어떻게 활동하는지, 혹여 만족하지 않았다면 그때는 또 어떻게 활동하는지 궁금하다. GA와 A/B 테스트 등의 방법들을 통해 데이터를 보며 이를 파악하고 싶다.기존 홈페이지는 전통적인 페이지 단위로 돌아가는 레일즈 웹 애플리케이션이었으므로 따로 제이쿼리 등을 사용해야지만 이를 구현할 수 있었다. 그래서 페이지 단위의 웹을 벗어나 React를 활용한 컴포넌트 단위의 웹 사이트를 구축했다. 장기적으로 계획적이고 세밀한 트래킹이 가능하도록 기반을 닦았다.또 기존의 홈페이지에서는 유저에게 오류 제보를 받아도 이를 확인해보는 것이 어려웠다. 그래서 지금의 시스템에는 Apollo engine과 Cloud watch를 이용하여 여러 로그들을 트래킹 하기 시작했다.리라이팅 런칭 2주 차,아쉬웠던 점들리라이팅 한 홈페이지를 런칭한 지 2주일이 지났다. 런칭 후에 한참을 정신없이 보내다가 이제야 조금 숨을 돌릴 수 있게 되어 이 글도 쓰기 시작했다. 런칭만 하면 마음이 편해질 거라 예상했는데 막상 다가오니 그렇지도 않았다. 더 바쁘고 정신없던 것은 물론이요, 아쉬운 점들만 눈에 밟혀서 마음이 무거웠다. 잘한 것보다 아쉬웠던 점들이 나를 더 성장하게 만들어 줄 것이라는 생각으로 스스로를 위로하여 어떤 것들이 아쉬운지도 정리해보았다.1. 트래픽이 몰리는 피크타임에 대한 대비 미흡배달의 민족이 식사 시간마다 트래픽이 몰리는 피크타임이 존재하듯, 트레바리도 독후감 마감 시간이라는 피크타임이 존재했다. 유저들이 모든 시간 대에 일정하게 접속하는 하는 것이 아닌 특정 시간에 몰아서 접속하는 것을 고려하여 그때의 속도를 잘 잡았어야 했다. 이를 미리 고려하여 캐시와 같은 여러 대비책들을 세워두었다면 유저들이 느린 홈페이지가 주는 불편을 덜 겪었을 거라고 생각한다.2. 치밀하지 못한 안내런칭 직후 오는 많은 문의들이 실제 오류가 아닌 제대로 된 안내가 없어 오류로 인지하는 경우였다. 예를 들어 기존에는 있었으나 사라진 주소와 같은 404 페이지 접근 시에는 안내 후 메인 페이지로 보내버리거나 하는 안내가 있었으면 많은 문의들을 대응하지 않아도 됐을 것이다.3. 운영 크루 업무 이해도 낮음리라이팅을 할 때 다른 크루들과 커뮤니케이션을 하는 일에 많은 리소스를 쏟지 않았었다. 다른 크루들의 업무에 대해 꽤 잘 이해하고 있다고 생각했기 때문이었다. 내가 생각하기에 필요할 것 같은 기능들만 어드민에 담았고, 그 결과로 크루들이 런칭 직후에 엄청난 불편과 수고로움을 겪게 만들었다.4. 조급함리라이팅을 진행하는 기간 동안 마음이 급해서 눈앞에 보이는 기능들을 빨리 쳐내는 것에 급급했다. 그러다 보니 각 기술에 대한 문서들을 꼼꼼하게 읽어내지 못해 놓친 부분이 많았다. 특히 한 번도 경험해본 적 없는 각종 브라우저와 브라우저 버전, PC와 모바일 대응 등에서 많이 놓쳤다. 평소 웹 표준 관련 문서를 잘 읽어두었다면 이런 실수는 덜하지 않았을까 생각했다. 또 틈틈이 작성했던 코드를 되돌아보고 개선하는 시간도 가졌어야 했는데 조급함 때문에 그러지 못했다. 이런 부분들은 개발자가 평소에 항시 주의해야 할 모습이라 생각했다.이번 리라이팅을 시작으로 트레바리가 온라인의 경험까지 멋진 서비스가 될 수 있기를 희망한다. 아직은 부족한 점이 많지만 사람들이 독서모임에 참석하기까지 겪는 온라인에서의 경험을 멋지게 만들고 싶다. 필요한 기능들을 적재적소에 구현하고, 말보다는 UI로 커뮤니케이션을 잘하는 개발자가 되기 위해 계속 노력할 것이다.지난 4개월 동안 참 힘든 시간도 많았다. 그럼에도 불구하고 크루들과 주변의 개발자분들에게 여러 도움을 받으면서 어려운 난관들을 헤쳐나갈 수 있었다. 홈페이지 변경이 아니어도 바쁜 일이 많은 시즌 시작 시기에 홈페이지 관련 문의가 쏟아졌다. 그런 상황에서 나를 탓하기보다는 오히려 걱정해주고 격려해주는 동료들이 있었다. 새삼스레 좋은 사람들과 함께하고 있다는 생각을 하며 일을 더 열심히, 잘 하는 것으로 보답하고 싶다고 생각했다.#트레바리 #기업문화 #조직문화 #CTO #스타트업CTO #CTO의일상 #인사이트

 역삼 맛집▲ 금강산도 식후경이라 했던가? 맛있는 인터뷰가 맛있는 이유는 늘 음식과 함께 하기 때문이다오늘 온 맛집. 분위기가 심상치 않다. 어떤 곳인지 소개해달라. Hugo(이하 ‘휴’): 역삼역 근방에 있는 ‘산촌’이란 곳이다. 얼마 전 버디런치 장소 물색을 위해 ‘다이닝코드’로 역삼역 주변 한식집을 찾던 중 발견했다. 예로부터 어르신들이 찾는 곳은 맛집이라는 얘기가 있다. 보면 알겠지만 어르신들이 많다. 괜찮은 가격에 건강한 음식을 섭취할 수 있는 곳이라 많은 듯 하다. 그리고.. 우리도 건강을 챙겨야 하는 나이다. 몸에 좋은 곤드레밥, 메밀 전병을 먹으며 함께 하는 건강한 인터뷰가 되었으면 하는 바람에 이 곳을 선택했다.깔끔한 답변 고맙다. 이제 본인 소개를 부탁한다. 휴: 반갑다. 개발자 Hugo다. 잔디 그로스 팀(Growth Team)에서 로우 데이터(Raw data) 가공, 분석을 통해 유의미한 지표를 보여주는 데이터 분석 툴 ‘스프링클러’를 개발하고 있다. 잔디 멤버들 사이에서 유독 명성이 자자하다 휴: 여러분의 관심을 먹고 자라는 임무를 수행하다 보니 그런 듯 하다. Hannah, Jihoon, Jane 등과 함께 GWP 팀으로 활동해서 많이들 알아봐 주시고 격려해주시는 것 같다. * GWP 팀? GWP는 Great Working Place의 줄임 말이다. 단어 그대로 물리적+비물리적 최고의 업무 공간을 만들기 위해 TF팀 형태로 구성된 그룹이 다양한 활동을 한다. 예를 들면, 할로윈 파티 개최부터 탕비실 냉장고 음식 채우기 등 업무 환경 개선을 위해 크고 작은 일을 수행한다. ‘비선실세’라는 얘기도 돌던데? 휴: 천부당 만부당한 말씀이다. 그저 잔디를 사랑하는 멤버 중 한 명이다.스프링클러? 휴: 잔디 그로스 팀에서 자체적으로 만든 분석 툴이다. 쉽게 말하면 잔디 데이터 분석과 가공에 최적화된 잔디 전용 구글 어널리틱스(Google Analytics)로 보면 된다. 스프링클러를 통해 잔디 DAU(Daily Active User) 파악, 마케팅 채널 별 효율 측정, 유저 별 사용량 측정 등을 할 수 있다.  스프링쿨러▲ 잔디의 모든 데이터를 가공, 분석해 보여주는 스프링클러잠깐! 유저 별 사용량 측정도 스프링클러를 통해 가능하다고 했는데 잔디 팀이 유저의 모든 정보를 열람하는 건가? 휴: 많은 분들이 오해할 수 있을 것 같은데 그렇지 않다. 스프링클러에서 열람할 수 있는 유저 별 사용량 확인은 특정 채널을 통해 유입된 유저가 메시지를 몇 건 보내고, 파일 업로드를 얼마나 하는지 정도다. 유저가 어떤 메시지를 주고 받는지, 어떤 파일을 올리는지 등 개인 정보는 원칙적으로 잔디 팀이 접근할 수 없다.   스타트업은 시간과 리소스 관리가 생명이다. 구글 어널리틱스와 같은 훌륭한 툴이 있는데 굳이 자체 데이터 분석 툴을 만든 이유가 무엇인지? 휴: 날카로운 질문이다. 나도 처음에 왜 스타트업에서 데이터 관련 팀을 꾸려 분석 툴을 만들려고 하는지 이해가 가지 않았다. 하지만 좀 더 생각해보니 잔디에서 발생한 데이터에 특화된 분석 툴이 있어야 정확한 결과를 얻을 수 있고, 이를 통해 스타트업 특유의 린(Lean)한 개발이 가능할거란 결론에 도달하였다.   듣기엔 스프링클러의 사용성과 분석 능력이 뛰어나 독자 서비스로 나오는 것 아니냔 루머가 있었다. 사실인가? 휴: 하하. 루머일 뿐이다. 다만 그런 생각을 갖고 그로스 팀과 최선을 다해 스프링클러 개발을 하고 있다. 어쨌든 좋게 봐주셔서 이런 루머가 나온 것 같아 담당자로서 기쁘다.   스프링클러에 애정이 많을 것 같다 휴: 내게 잔디도 소중하지만 스프링클러도 무척 중요하다. 소박한 꿈이 있다면 스프링쿨러가 내가 없어도 100% 완벽히 잘 돌아가게 만들고 싶다. 물론, 분석 툴로서 멤버들이 원하는 결과를 보여줄 수 있도록 정교하게 만드는 것도 중요하다.   그로스 팀은 과거 ‘맛있는 인터뷰’의 Kevin을 통해 소개한 바 있다. 당시 개발자 중 몇 명을 차출해 그로스 팀에 합류시킨 걸로 알고 있는데 여러 개발자 중 Hugo가 차출된 이유가 있다면? 휴: 평소 데이터 마이닝 분야에 관심이 많아 대학원에서 관련 공부를 하기도 했고, 그로스 팀 초창기 모든 업무를 책임지던 팀장 겸 팀원 Kevin이 추천해 팀에 합류하게 되었다. 아, 그로스 팀 오기 전엔 백엔드(Back-end) 개발자 포지션으로 있었다. 팀을 옮길 땐 백엔드 개발자들로부터 ‘배신자’란 오명과 함께 모진 고문과 학대를 받았다. 하하.. 농담이다.   다른 얘기를 해보자. 잔디에 어떤 이유로 조인했는지 궁금하다 휴: 건방진 말일 수 있지만 내 의지대로 무언가 만들고 싶었다. 대한민국 수 많은 개발자들이 그렇겠지만 회사에서 내가 할 수 있는 건 생각보다 한정돼 있다. 아이디어를 내도 예산 때문에 혹은 기타 다른 이슈 때문에 반려되기 일쑤였다. 어떻게 보면 그런 현실에 대한 반발심으로 잔디를 선택한 게 가장 크다고 볼 수 있다.   잔디에서는 생활은 만족스러운가? 휴: 70% 정도?   왜 70%인가? 휴: 장-단점이 있지만 장점이 조금 더 크기 때문에?   그럼 장점부터 말해보자 휴: 합당한 이유가 있다면 내가 하고 싶은 일을 진행할 수 있다는 점이 큰 장점이다. 그 일을 실행하기까지 절차도 이전까지 다녔던 회사 대비 상당히 간소화되어 있어 부담감도 적다. 각 분야에서 두각을 드러낸 사람들과 함께 일하고 있다는 점도 매력적이다. 다들 자부심을 갖고 일하고 있어 자극을 받는다.   단점은? 휴: 장점이 때에 따라 단점으로 보일 때도 있다. 논리적인 어프로치가 필요할 때도 있지만 분명 전쟁터로 돌진하는 돌격병 같은 저돌성이 필요할 때도 있다. 그럴 땐 일부터 치고 보는 자세가 필요한데 그 때를 놓치는 경우가 눈에 보여 개인적으로 아쉽다.   스트레스는 어떻게 푸는지? 휴: 주말에 13시간 이상 잔다. 밤에 10시간, 낮에 3시간. 남는 시간엔 수영이나 등산을 한다.   등산? 휴: 집 바로 뒤에 나지막한 산이 있다. 평소 자연을 좋아하는데 등산을 하다 보면 산의 나무나 풀, 바람을 보고 즐길 수 있어 좋다.   생각보다 감성적인 남자라 당황스럽다 휴: ^^ ▲ 감성적인 남자로 보이는 그는 한 때 해병대 전우였다.수영은 시작한지 얼마 안됐다고 들었다 휴: 작년 10월부터 시작했다. 이제 갓 1년이 넘었다. 작년 초부터 체력적으로 처진 것 같은 느낌이 들어 이대론 안되겠다 싶어 수영을 시작했다. 등산과 함께 꾸준히 하는 운동 중 하나다.   꾸준히 운동하고 있는데 달라진 점이 있다면? 휴: 몸도 몸이지만 정신적으로 건강해졌다. 확실히 체력이 떨어지면 부정적인 생각을 하는 경향이 있는 것 같다. 운동을 시작하기 전과 후의 마음 상태가 정말 많이 다르다. 앞으로도 꾸준히 운동을 할 생각이다.   곤드레밥과 함께 한지 벌써 1시간 가까이 됐다. 인터뷰 질문도 다 소진되어 이전 맛있는 인터뷰 주인공이었던 David이 남긴 질문을 묻고 싶다 휴: 준비됐다.   잔디 멤버 중 전생에 공주나 왕자였을 것 같은 사람은? 휴: 왕자는 디자인 팀의 Ben. 도도하고 말수도 적고. 공주는 디자인 팀의 Yujin (A.K.A Summer)? 얘기는 많이 안 해봤지만 말도 고급스럽게 하는 것 같다. 두 사람 모두 괜찮은 사람들이라 이번 인터뷰를 통해 점수를 따보고 싶다.   전략적인 답변 감사하다 휴: ^^   마지막 질문이다. ‘맛있는 인터뷰’의 백미는 다음 인터뷰이에게 현재 인터뷰이가 질문을 남기는 것이다. 다음 사람에게 묻고 싶은 질문이 있다면? 휴: 잔디 멤버 중 내 주변 괜찮은 남자 사람이나 여자 사람을 소개시켜주고 싶은 사람은?   오늘 맛있는 곤드레밥 덕분에 잘 먹었다. 계산은 인터뷰이가 한다는 거 다시 한번 더 상기시켜 드리며 인터뷰 마무리하겠다 휴: …^^#토스랩 #잔디 #JANDI #개발 #개발자 #개발팀 #인터뷰 #팀원 #팀원소개 #팀원인터뷰 #기업문화 #조직문화

Sketch App 도입은 Zeplin을 활용하여 효율적으로 개발자와 소통하기 위해 시작되었습니다. 도입하는 과정에서 안드로이드 UI를 담당하게 되었고, 심볼의 구조화와 적절한 플러그인의 사용을 통한 작업의 효율, 가지고 있던 문제점들을 해결하는 것에 중점을 뒀습니다.기존 작업방식과 문제점디자인 작업 패턴디자인 작업 패턴을 분석했을 때, 기존의 PSD 파일들에서 컴포넌트를 가져와 재조합하는 경우가 가장 많았습니다. 디자이너간 협업 시 최근 릴리즈된 디자인이 맞는지, 요소간 간격 같은 디테일한 부분에 대해 묻는 경우가 많았으며, 개발자와의 협업 시 지칭하는 용어가 달라서 생기는 커뮤니케이션 미스가 종종 발생했습니다. 구조화에 앞서, 분석하고 내린 작업의 키포인트는 다음과 같습니다.1. 최근 릴리즈된 디자인이 영향을 받는 모든 화면에 동기화되어야 합니다.2. 개발자와의 협업 시, 심볼의 네이밍을 기준으로 커뮤니케이션합니다.3. 디자이너가 사용 시, 시안 작업을 빠르고 편하게 할 수 있어야 합니다.4. 컴포넌트, 디자인 요소들이 서로 유기적으로 연결되어있어야 합니다.5. 시안 작업 시, 유저 데이터를 사용하기 편리해야 합니다.심볼 생성 기준심볼로 만들어야 하는 경우는 다음과 같이 정의했습니다.1. 다양한 상태값을 가진 요소2. 같은 크기의 영역 안에서 다양한 형태를 가진 요소3. GNB처럼 자주 쓰이는 컴포넌트4. 카드 형태의 디자인5. 아이콘Overrides 예시심볼 폴더 구조심볼 폴더 구조디자이너들이 사용하기 때문에 첫 번째 분류는 보이는 형태, 디자이너끼리 자주 사용하는 용어로 합니다. 두 번째 분류는 원활한 커뮤니케이션을 위해 목적 혹은 개발자분들이 사용하는 용어로 지정하며, 세 번째 분류까지 해야하는 경우 2 Column, 3 Column(스타일쉐어 내부에선 Grid라는 용어를 주로 사용합니다.)과 같은 다양한 변화에 대한 것이므로, 똑같이 커뮤니케이션에 용이하게 판단하여 결정합니다.Elements 폴더는 심볼을 구성하는 심볼들이 있는 폴더입니다. 직접 심볼 폴더트리를 타고 들어가 생성하는 경우는 없으므로, 분류에 더 목적을 두고 폴더 구조가 복잡해지는 것을 감수했습니다.그리고 Overrides를 대비하여 이해하기 쉬운 용어로 작성합니다.심볼의 활용자주 쓰는 컬러들을 심볼화하고 마스크 기능을 활용하면, 아이콘들의 색상을 더 편하게 변경할 수 있습니다. 추후에 브랜드 컬러, 그레이스케일이 변경되는 경우에도 컬러 심볼만 수정하면 큰 문제없이 바로 적용할 수 있습니다.플러그인의 활용작업에 주로 사용하는 플러그인은 Auto Layout, Button, Clipboard Fill입니다.Auto Layout의 Stacked Group 기능으로 심볼이나 요소들을 유기적으로 연결시킵니다. Button은 Tag, List item 등에 사용하며 짜잘한 수정작업을 줄여 시안작업에 더 집중할 수 있도록 합니다. Clipboard Fill은 스타일쉐어 특성때문에 활용 가치가 높은 플러그인입니다. 유저 이미지, 게시글의 사진을 스타일쉐어 웹에서 복사하여 시안을 작업할 때 활용합니다. 실 데이터를 사용하기 때문에 설득력이 높아지고, 조금 더 객관적으로 작업할 수 있다는 장점이 있습니다.플러그인 사용 Gif페이지 구성모든 화면이 모여있는 Master_Android.sketch 파일에서는 페이지로 분류합니다. 이 분류와 구글 드라이브 폴더 구조를 일치시켜 빠르게 파일을 찾을 수 있도록 하였으며, 탐색이 용이하기때문에 새로운 디자이너가 오더라도 쉽게 파악가능합니다.디자인 작업 프로세스시안 작업 시, 실제 데이터를 사용하여 설득력을 높이는 것을 가장 큰 목표로 합니다.1. 디자인 작업 전, 사용할 심볼들을 모두 Detatch합니다.2. 문제해결에 맞게 컴포넌트를 디자인합니다.3. 플러그인을 활용하여 웹에서 실제 데이터들을 가져와 채웁니다.4. 시안 작업이 끝난 후, 정리하여 Zeplin으로 내보냅니다.5. 심볼을 만들어야 한다면, Master파일 Symbols에 업데이트합니다.6. Master파일에 심볼을 사용하여 화면을 정리합니다.이 과정에서 생기는 큰 문제점은 모든 작업자가 심볼 구조화에 같은 기준을 가지고 있어야 한다는 점입니다. 생성 여부, 심볼 이름을 정하는 규칙 등에 대해 문서화하여 공유해도 익숙하지 않기때문에 실수가 생기기 마련입니다. 그래서 안정화되기까지 첫 구조를 잡았던 담당자가 정기적으로 확인하여, 다듬어나가는 것으로 결정했습니다. 비효율적인 방법일 수도 있지만, 동시에 구조화를 더 탄탄하게 하는 기회였습니다.잘가 포토샵.Sketch App의 업데이트에 따라 해결할 수 있는 방법이 달라지는 경우가 많았습니다. 그에 대비하여 의존성을 줄여나가는 고민을 계속하고 있으며 UI 뿐만 아니라, 작업툴 사용에 제약이 없다는 조건 하에 Overrides 기능과, Clipboard Fill, Auto Layout을 활용하여 다양한 템플릿 작업에도 사용할 수 있다고 생각합니다.#스타일쉐어 #개발팀 #개발자 #개발환경 #인사이트