레일즈 기반의 프론트엔드(브라우저에서 서버 사이드 렌더링 계층까지)와 자바 기반의 백엔드(내부 API와 그 이후 계층)이 세션을 공유하기 위해 먼저 레일즈의 세션 처리 과정을 분석하고, 레일즈 세션 쿠키를 다루기 위한 자바 소스 코드를 공유합니다.여기저기 자랑하고 다녔으니 아시는 분은 아시다시피 레진은 구글앱엔진을 사용하고 있습니다. 지금이야 Java, Python, Node.js, Go 언어와 Flexible Environment 같은 다양한 선택지가 있지만, 레진이 입주할 당시만 해도 Java 7(subset), Python(subset)을 지원하는 Standard Environment라는 선택지 밖에 없었죠.최근 Saemaeul Undong 기술 부채 탕감의 일환으로 자바7, 스프링3.x, JSP(!) 기반의 백엔드에 포함되어 있던 프론트엔드를 레일즈 기반의 프론트엔드 서버(서버 사이드 렌더링을 담당하는 서버는 프론트일까요? 백엔드일까요?)로 분리하고 있습니다.서로 다른 세계의 존재들 - 자바와 레일즈의 세션을 공유해야하는 상황이 문제의 발단입니다.자바와 레일즈의 세션을 공유하는 여러가지 방법이 있겠지만, 가장 단순하고 효과적인 방법은 쿠키(cookie)라고 판단하고, 세션 encrypt/decrypt와 marshal/unmarshal을 동일한 방식으로 맞추기로 했습니다. (백엔드 API를 완전히 stateless하게 새로 만들면 좋겠지만, 코인은 벌어야 소는 키워야죠)이를 위해 레일즈의 세션 처리 과정을 분석하고 정리했습니다.레일즈의 actionpack의 action_dispatch/middleware/cookie.rb를 보면 EncryptedCookieJar 클래스의 초기화 과정은 다음과 같습니다(digest의 경우 따로 지정안하면 SHA1이 사용되는 듯):class EncryptedCookieJar < AbstractCookieJar # :nodoc: include SerializedCookieJars def initialize(parent_jar) super if ActiveSupport::LegacyKeyGenerator === key_generator raise "You didn't set secrets.secret_key_base, which is required for this cookie jar. " + "Read the upgrade documentation to learn more about this new config option." end secret = key_generator.generate_key(request.encrypted_cookie_salt || '') sign_secret = key_generator.generate_key(request.encrypted_signed_cookie_salt || '') @encryptor = ActiveSupport::MessageEncryptor.new(secret, sign_secret, digest: digest, serializer: ActiveSupport::MessageEncryptor::NullSerializer) end private def parse(name, encrypted_message) debugger deserialize name, @encryptor.decrypt_and_verify(encrypted_message) rescue ActiveSupport::MessageVerifier::InvalidSignature, ActiveSupport::MessageEncryptor::InvalidMessage nil end def commit(options) debugger options[:value] = @encryptor.encrypt_and_sign(serialize(options[:value])) raise CookieOverflow if options[:value].bytesize > MAX_COOKIE_SIZE end end key_generator는 EncryptedCookieJar에 포함된 SerializedCookieJars 모듈에 정의되어 있습니다:module SerializedCookieJars # ... def key_generator request.key_generator end end 흠… 좀 더 파보죠. request.key_genrator는 다음과 같습니다:class Request # ... def key_generator get_header Cookies::GENERATOR_KEY end #... end 흠… 좀 더 파야할 듯 ㅠㅠ.Cookies::GENERATOR_KEY는 다음과 같습니다:class Cookies #... GENERATOR_KEY = "action_dispatch.key_generator".freeze end action_dispatch.key_generator는 레일즈의 엔진 모듈에 해당하는 railties의 application.rb에 정의되어 있습니다:def key_generator # number of iterations selected based on consultation with the google security # team. Details at https://github.com/rails/rails/pull/6952#issuecomment-7661220 @caching_key_generator ||= if secrets.secret_key_base unless secrets.secret_key_base.kind_of?(String) raise ArgumentError, "`secret_key_base` for #{Rails.env} environment must be a type of String, change this value in `config/secrets.yml`" end key_generator = ActiveSupport::KeyGenerator.new(secrets.secret_key_base, iterations: 1000) ActiveSupport::CachingKeyGenerator.new(key_generator) else ActiveSupport::LegacyKeyGenerator.new(secrets.secret_token) end end # ... def env_config @app_env_config ||= begin validate_secret_key_config! super.merge( # ... "action_dispatch.key_generator" => key_generator, "action_dispatch.signed_cookie_salt" => config.action_dispatch.signed_cookie_salt, "action_dispatch.encrypted_cookie_salt" => config.action_dispatch.encrypted_cookie_salt, "action_dispatch.encrypted_signed_cookie_salt" => config.action_dispatch.encrypted_signed_cookie_salt, "action_dispatch.cookies_serializer" => config.action_dispatch.cookies_serializer, "action_dispatch.cookies_digest" => config.action_dispatch.cookies_digest ) end end 너무 깊이 판 느낌적느낌(?)이 있지만, 여기까지 왔으니 좀 더 파보겠습니다.핵심 알고리즘은 activesupport의 key_generator.rb, message_encryptor.rb, message_verifier.rb에 정의되어 있습니다.먼저, key_generator.rb의 핵심은 다음과 같습니다:class KeyGenerator def initialize(secret, options = {}) @secret = secret # The default iterations are higher than required for our key derivation uses # on the off chance someone uses this for password storage @iterations = options[:iterations] || 2**16 end # Returns a derived key suitable for use. The default key_size is chosen # to be compatible with the default settings of ActiveSupport::MessageVerifier. # i.e. OpenSSL::Digest::SHA1#block_length def generate_key(salt, key_size=64) OpenSSL::PKCS5.pbkdf2_hmac_sha1(@secret, salt, @iterations, key_size) end end 계속해서, message_encryptor.rb의 핵심은 다음과 같습니다:def initialize(secret, *signature_key_or_options) options = signature_key_or_options.extract_options! sign_secret = signature_key_or_options.first @secret = secret @sign_secret = sign_secret @cipher = options[:cipher] || 'aes-256-cbc' @verifier = MessageVerifier.new(@sign_secret || @secret, digest: options[:digest] || 'SHA1', serializer: NullSerializer) @serializer = options[:serializer] || Marshal end def _encrypt(value) cipher = new_cipher cipher.encrypt cipher.key = @secret # Rely on OpenSSL for the initialization vector iv = cipher.random_iv encrypted_data = cipher.update(@serializer.dump(value)) encrypted_data << cipher.final "#{::Base64.strict_encode64 encrypted_data}--#{::Base64.strict_encode64 iv}" end def _decrypt(encrypted_message) cipher = new_cipher encrypted_data, iv = encrypted_message.split("--".freeze).map {|v| ::Base64.strict_decode64(v)} cipher.decrypt cipher.key = @secret cipher.iv = iv decrypted_data = cipher.update(encrypted_data) decrypted_data << cipher.final @serializer.load(decrypted_data) rescue OpenSSLCipherError, TypeError, ArgumentError raise InvalidMessage end def encrypt_and_sign(value) verifier.generate(_encrypt(value)) end def decrypt_and_verify(value) _decrypt(verifier.verify(value)) end (Hopefully)마지막으로, message_verifier.rb의 핵심은 다음과 같습니다:def initialize(secret, options = {}) raise ArgumentError, 'Secret should not be nil.' unless secret @secret = secret @digest = options[:digest] || 'SHA1' @serializer = options[:serializer] || Marshal end def valid_message?(signed_message) return if signed_message.nil? || !signed_message.valid_encoding? || signed_message.blank? data, digest = signed_message.split("--".freeze) data.present? && digest.present? && ActiveSupport::SecurityUtils.secure_compare(digest, generate_digest(data)) end def verified(signed_message) if valid_message?(signed_message) begin data = signed_message.split("--".freeze)[0] @serializer.load(decode(data)) rescue ArgumentError => argument_error return if argument_error.message =~ %r{invalid base64} raise end end end def generate(value) data = encode(@serializer.dump(value)) "#{data}--#{generate_digest(data)}" end private def encode(data) ::Base64.strict_encode64(data) end def decode(data) ::Base64.strict_decode64(data) end def generate_digest(data) require 'openssl' unless defined?(OpenSSL) OpenSSL::HMAC.hexdigest(OpenSSL::Digest.const_get(@digest).new, @secret, data) end # ... # encode, decode는 base64사용 이제 레일즈가 쿠키 기반의 세션을 어떻게 처리하는지 조금 눈에 들어옵니다. 그러나 우리의 최종 목표는 레일즈의 내부를 공부하는 것이 아니라, 자바에서 동일한 처리를 하는 것입니다. 모듈 의존성 따위는 가볍게 무시하고 무한복붙(?)을 시전해서, 레일즈의 세션 처리 과정을 눈으로 확인할 수 있도록 재구성했습니다:require 'openssl' require 'base64' require 'concurrent/map' class Object def blank? respond_to?(:empty?) ? !!empty? : !self end def present? !blank? end end class Hash # By default, only instances of Hash itself are extractable. # Subclasses of Hash may implement this method and return # true to declare themselves as extractable. If a Hash # is extractable, Array#extract_options! pops it from # the Array when it is the last element of the Array. def extractable_options? instance_of?(Hash) end end class Array def extract_options! if last.is_a?(Hash) && last.extractable_options? pop else {} end end end module SecurityUtils def secure_compare(a, b) return false unless a.bytesize == b.bytesize l = a.unpack "C#{a.bytesize}" res = 0 b.each_byte { |byte| res |= byte ^ l.shift } res == 0 end module_function :secure_compare end class KeyGenerator def initialize(secret, options = {}) @secret = secret # The default iterations are higher than required for our key derivation uses # on the off chance someone uses this for password storage @iterations = options[:iterations] || 2**16 end def generate_key(salt, key_size=64) OpenSSL::PKCS5.pbkdf2_hmac_sha1(@secret, salt, @iterations, key_size) end end class CachingKeyGenerator def initialize(key_generator) @key_generator = key_generator @cache_keys = Concurrent::Map.new end # Returns a derived key suitable for use. def generate_key(*args) @cache_keys[args.join] ||= @key_generator.generate_key(*args) end end class MessageVerifier class InvalidSignature < StandardError; end def initialize(secret, options = {}) raise ArgumentError, 'Secret should not be nil.' unless secret @secret = secret @digest = options[:digest] || 'SHA1' @serializer = options[:serializer] || Marshal end def valid_message?(signed_message) return if signed_message.nil? || !signed_message.valid_encoding? || signed_message.blank? data, digest = signed_message.split("--".freeze) data.present? && digest.present? && SecurityUtils.secure_compare(digest, generate_digest(data)) end def verified(signed_message) if valid_message?(signed_message) begin data = signed_message.split("--".freeze)[0] @serializer.load(decode(data)) rescue ArgumentError => argument_error return if argument_error.message =~ %r{invalid base64} raise end end end def verify(signed_message) verified(signed_message) || raise(InvalidSignature) end def generate(value) data = encode(@serializer.dump(value)) "#{data}--#{generate_digest(data)}" end private def encode(data) ::Base64.strict_encode64(data) end def decode(data) ::Base64.strict_decode64(data) end def generate_digest(data) require 'openssl' unless defined?(OpenSSL) OpenSSL::HMAC.hexdigest(OpenSSL::Digest.const_get(@digest).new, @secret, data) end end class MessageEncryptor module NullSerializer #:nodoc: def self.load(value) value end def self.dump(value) value end end class InvalidMessage < StandardError; end OpenSSLCipherError = OpenSSL::Cipher::CipherError def initialize(secret, *signature_key_or_options) options = signature_key_or_options.extract_options! sign_secret = signature_key_or_options.first @secret = secret @sign_secret = sign_secret @cipher = options[:cipher] || 'aes-256-cbc' @verifier = MessageVerifier.new(@sign_secret || @secret, digest: options[:digest] || 'SHA1', serializer: NullSerializer) @serializer = options[:serializer] || Marshal end def encrypt_and_sign(value) verifier.generate(_encrypt(value)) end def decrypt_and_verify(value) _decrypt(verifier.verify(value)) end def _encrypt(value) cipher = new_cipher cipher.encrypt cipher.key = @secret # Rely on OpenSSL for the initialization vector iv = cipher.random_iv encrypted_data = cipher.update(@serializer.dump(value)) encrypted_data << cipher.final "#{::Base64.strict_encode64 encrypted_data}--#{::Base64.strict_encode64 iv}" end def _decrypt(encrypted_message) cipher = new_cipher encrypted_data, iv = encrypted_message.split("--".freeze).map {|v| ::Base64.strict_decode64(v)} cipher.decrypt cipher.key = @secret cipher.iv = iv decrypted_data = cipher.update(encrypted_data) decrypted_data << cipher.final @serializer.load(decrypted_data) rescue OpenSSLCipherError, TypeError, ArgumentError raise InvalidMessage end def new_cipher OpenSSL::Cipher.new(@cipher) end def verifier @verifier end end #key generate encrypted_cookie_salt = 'encrypted cookie' encrypted_signed_cookie_salt = 'signed encrypted cookie' def key_generator secret_key_base = 'db1c366b854c235f98fc3dd356ad6be8dd388f82ad1ddf14dcad9397ddfdb759b4a9fb33385f695f2cc335041eed0fae74eb669c9fb0c40cafdb118d881215a9' key_generator = KeyGenerator.new(secret_key_base, iterations: 1000) CachingKeyGenerator.new(key_generator) end # encrypt secret = key_generator.generate_key(encrypted_cookie_salt || '') sign_secret = key_generator.generate_key(encrypted_signed_cookie_salt || '') encryptor = MessageEncryptor.new(secret, sign_secret, digest: 'SHA1', serializer: MessageEncryptor::NullSerializer) value = "{\"session_id\":\"6022d05887d2ab9c1bad8a87cf8fb949\",\"_csrf_token\":\"OPv/LxbiA5dUjVsbG4EllSS9cca630WOHQcMtPxSQUE=\"}" encrypted_message = encryptor.encrypt_and_sign(value) #encrypted_message = encryptor._encrypt(value) p '-----------encrypted value-------------' p encrypted_message # decrypt encrypted_message = 'bDhIQncxc2k0Rm9QS0VBT0hWc3M4b2xoSnJDdkZNc1B0bGQ2YUhhRXl6SU1oa2c5cTNENWhmR0ZUWC9zN05mamhEYkFJREJLaDQ3SnM3NVNEbFF3ZVdiaFd5YXdlblM5SmZja0R4TE9JbDNmOVlENHhOVFlnamNVS2g1a05LY0FYV3BmUmRPRWtVNUdxYTJVbG5VVUlRPT0tLXd1akRqOU1lTTVneU9LTWszY0I5bFE9PQ==--b0a57266c00e76e0c7d9d855b25d24b242154070' p '-----------decypted value-------------' puts encryptor.decrypt_and_verify encrypted_message p '---------------------------------------' 이 과정을 자바로 구현한 소스는 생략 깃헙에 올려두었습니다. 이 코드를 이용해서 서블릿 세션과 연동하는 방법은 추후 사측(?)과 협의되는 대로 공유할 예정입니다. 물론, 그 전에 쿠키를 공유할 필요가 없어지면(or 공유할 쿠키가 없어지면) 더 좋겠죠 :D

지루한 통근(학) 시간. 대중교통으로 이동하는 동안에는 자연스럽게 스마트폰을 찾게 되지 않나요? SNS로 다른 사람과 연락을 하거나, 재미있는 영상을 보기도 하죠. 이때 우리는 웹페이지에 있는 텍스트, 이미지, 영상 등 수많은 정보를 보게 됩니다. 웹페이지를 보기 위해 어떤 브라우저를 사용하시나요? 대부분 Chrome이나 Internet Explorer 등을 사용하실 거예요. 이 브라우저를 개발하다가 만들어진 언어에 대해 이야기해볼게요.움직이는 브라우저 ― 자바스크립트의 탄생지금은 대부분 Chrome이나 Internet Explorer와 같은 브라우저를 사용하지만 1990년대 초반만 해도 Mosaic(모자이크)라는 브라우저를 사용했어요.Mosaic 브라우저의 Yahoo! 페이지 (출처 : dweb3d.com on Pinterest)이 당시의 웹페이지는 대부분 흰색 바탕에 검은색 글씨, 그리고 파란색 글씨로 된 링크로만 구성되어 있었는데요. 지금의 웹페이지와 비교해보면 굉장히 지루하고 단조롭죠.아마도 같은 지루함을 느꼈던 것 같은 '브랜든 아이크'라는 사람이 새로운 브라우저를 개발했는데 단 10일 만에 웹페이지에 동작을 넣을 수 있는 언어를 뚝딱 만들어냈어요. 지금처럼 버튼을 눌렀을 때 안내 창이 뜨게 하는 등 좀 더 생동감 있는 웹페이지를 만들 수 있게 된 거예요.이때 만들어진 언어가 바로 JavaScript 랍니다!Java? Javascript! ― 이름의 유래Java와 [removed] 이름이 유사하네요!JavaScript라는 언어가 생소한 분들도 아마 Java라는 언어는 한 번쯤 들어보셨을 거예요. 이 두 언어는 이름이 비슷하지만 전혀 다른 언어예요. 마치 인도와 인도네시아처럼요!이와 관련해서 재밌는 일화가 있는데, 사실 지금의 JavaScript는 초창기에 Mocha(모카)라는 이름으로 개발되었어요. 그런데 당시에 Java 언어가 개발되어 큰 인기를 끌게 되자 Java를 만든 회사와 협약을 체결해 이름을 JavaScript로 변경했답니다. Java의 인기가 높아짐에 따라 덩달아 JavaScript의 인기도 높아지게 되었죠! Javascript 전성시대JavaScript의 인기가 높아지게 된 이유는 비단 Java의 유명세 때문만은 아니에요. 2000년대 중반에 들어서서 기술이 점점 더 발전함에 따라 웹페이지에서 시각적인 것이 중요해졌는데, 태생부터가 웹페이지를 생동감 있게 만들기 위해 개발된 JavaScript는 이런 상황에 활용되기 제격이었던 겁니다.많은 사람들이 웹페이지에 JavaScript를 사용하게 되고, 또 JavaScript를 잘 활용하기 위해 관련 정보들을 모은 라이브러리(자료집)가 발달하면서 활용 분야는 더욱더 넓어졌어요.Node.js : JavaScript의 변신!특히 node.js라고 하는 라이브러리는 JavaScript가 웹페이지를 표현하는 역할에 그치지 않고, 웹페이지와 웹페이지 사이를 연결해주는 연결고리(서버) 역할을 하게 해주었어요.이렇게 JavaScript를 사용하는 분야가 증가하면서 사용자 수도 폭발적으로 증가하게 되었고 현재 JavaScript는 웹 개발에 필수적인 언어로 자리매김하게 되었습니다.또 다른 장점 ― Javascript를 배우는 이유수많은 사람들이 JavaScript를 배우려고 하는 이유는 또 있어요. 우선 C언어나 Java보다 시작하기 쉽다는 점 때문인데요. 예를 들면 C나 Java는 변수를 선언할 때 숫자형, 문자형 등 자료의 유형을 명시해주어야 하지만 JavaScript는 그럴 필요가 없어요. 쉽게 이야기하면 앞의 두 언어는 자료를 상자에 담아서 관리할 때 반드시 자료의 크기에 맞는 상자를 준비해줘야 하지만 JavaScript는 그럴 필요 없이 마치 요술 상자처럼 하나의 상자에 모든 자료를 담을 수 있죠! 그래서 어떤 자료를 다룰 때 그 자료의 형태를 일일이 따져보지 않아도 된다는 편리함이 있어요.JavaScript는 앞서 이야기했던 것처럼 웹페이지를 꾸미거나 이들의 연결망을 만들고, 엄청 많은 자료들을 저장하는 저장소(데이터베이스)를 짓는 데에도 쓰이는 등 활용하는 분야가 무궁무진합니다.웹페이지를 보조하기 위해 탄생한 언어가 웹페이지를 만들기 위한 주류 언어가 되다니, 정말 놀랍지 않나요? 앞으로 JavaScript가 어떤 분야에서 활약하게 될지 더욱더 기대되는 이유입니다!>> 자바스크립트 과목 보기(참고 자료)Press release announcing JavaScript, "Netscape and Sun announce JavaScript", PR Newswire, December 4, 1995.Brendan Eich (3 April 2008). "Popularity". Retrieved 2018-07-06.              

AI 스쿨 3주차에서는 K-means clustering(K 평균 군집화)에 대해 배웠어요. 이에 대해서 간략하게 정리해볼게요.K-means clustering클러스터링이란 군집화를 의미하는데요, K-means clustering은 비슷한 데이터끼리 묶어주는 머신 러닝 기법이에요. K-means clustering은 비지도학습(Unsupervised learning)의 일종이에요. 비지도 학습이란 데이터와 각각의 데이터가 무엇인지를 설명해주는 라벨이 없는 학습을 말해요. 따라서 우리는 주어진 데이터들을 가장 잘 설명하는 클러스터를 찾아 데이터를 분류할 수 있어요. 아래는 데이터를 2개의 클래스로 군집화한 것을 잘 나타내주는 그래프에요.K-means는 클러스터 내부에 속한 데이터들이 서로 가깝다고 정의해요. 그렇다면 같은 클러스터에 속한 데이터들은 서로 가까이 근접해 있겠죠? K-means는 클러스터의 중심으로부터 가까운 데이터들을 찾아서 묶어주는 알고리즘이에요. 데이터들은 가장 가까운 내부 거리를 가지는 클러스터를 고르게 되는데, 이를 위해서 각각의 클러스터는 중심(프로토타입)이 존재하고 각각의 데이터가 그 중심과 얼마나 가까운지를 Cost로 정의해요.위의 식은 같은 클러스터에 속하는 각각의 점들로부터 그 클러스터의 평균(프로토타입)과의 거리의 합을 제곱한 함수에요. - N : 데이터의 개수- K : 클러스터의 개수- uk : k 번째 클러스터의 중심(프로토타입)- rnk : n 번째 데이터가 k 번째 클러스터에 속하면 1, 속하지 않는다면 0을 가지는 이진 변수우리는 위 식에서 rnk, uk를 구해야 해요. 이때 반드시 잊지 말아야 하는 조건은 각 데이터가 한 개의 클러스터에 할당이 되어야 한다는 것이에요.K-means 알고리즘K-means algorithm을 구하는 방법은 아래와 같이 크게 2단계로 나누어져요. 먼저 uk에 랜덤 값을 사용하여 임의의 초깃값을 설정해요.1. Expectationuk를 고정시키면서 J를 최소화하는  rnk값을 지정해야 하는데,  rnk은 모든 데이터 n에 대해 각각 모든 클러스터 중에서 xn- uk가 가장 작은 클러스터에 할당해요.2. Maximization새롭게 얻어진 rnk를 고정하고 uk는 k 번째 클러스터의 mean을 계산해요. 두 값이 적당한 범위 내로 수렴할 때까지 계산을 반복해요, 위의 두 단계를 각각 E(expectation) 단계와 M(maximization) 단계라 하고, 이 두 단계를 합쳐서 EM 알고리즘이라고 해요.알고리즘 코드로 나타내기그럼 K-means algorithm을 코드로 어떻게 나타내는지 살펴볼게요!Step1. 데이터 만들기np.random.seed(42)digits = load_digits()  data = scale(digits.data)n_samples, n_features = data.shapen_digits = len(np.unique(digits.target))labels = digits.targetx_train, x_test, y_train, y_test = train_test_split(data, labels, test_size=0.25, random_state=42) - digits = load_digits(): load_digits 함수를 사용하면 data와 target이 반환되는데 이 데이터를 scale 함수를 사용하여 전처리해요.- data.shape을 사용하면 n_samples에는 1797, n_feature에는 64가 할당돼요.- n_digits에는 digits의 target의 중복된 값을 제외한 개수를 할당해요.- train_test_split() 함수를 이용하여 train_set과 test_set을 랜덤 시드를 42를 가지는 75:25의 비율로 나눠요.Step2. KMeans model 만들기sklearn 라이브러리를 사용하면 KMeans model을 아주 쉽게 구현할 수 있어요.kmeans = KMeans(init='k-means++', n_clusters=10, random_state=42)clusters = kmeans.fit_predict(x_train)- KMeans 함수를 이용하여 모형은 k-means++를 가지고, cluster는 10개를 가지며 랜덤 시드는 42를 가지는 K-means clustering을 만들어요.- x_train 데이터 셋을 중심으로 클러스터의 중심을 계산하고 각 샘플에 대한 클러스터의 인덱스를 예측할 수 있도록 fit_predict()를 사용해요.Step3. K-means clustering 결과 출력print('Clusters: ', clusters)위와 같이 출력하면 아래와 같은 결과가 나와요.Clusters: [1 3 2 ... 6 6 0]]그래프를 출력하면 아래와 같은 결과를 볼 수 있어요!이번 수업에 배운 K-means clustering의 개념은 1주차와 2주차 수업의 개념에 비해 어렵지 않았던 것 같아요. 이해하기에 큰 문제는 없었지만 코드로 직접 짜려고 하니 막히는 부분이 있어서 고생을 좀 했어요. 저는 과제를 하다가 에러가 나면 구글링을 통해서 에러를 해결하거나 도저히 못하겠다 싶으면 도움 요청을 해요. 목요일에는 조교분들께서 Multiple Regression에 대해 숙명여대에서 수업을 진행해주셨는데요. 1, 2주차에 배운 내용을 복습하고 3주차 수업에서 짧게 살펴본 Multiclassification을 더 자세히 알려주셔서 본 수업 때 이해가 되지 않았던 부분이 해결이 되었습니다! 목요일 수업은 정식 수업이 아닌 보충수업이었기 때문에 소수의 사람들이 강의에 참여했는데요. 시간이 된다면 참석을 꼭 해주시면 굉장히 큰 도움이 될 것 같아요. * 이 글은 AI스쿨 - 인공지능 R&D 실무자 양성과정 3주차 수업에 대해 수강생 최유진님이 작성하신 수업 후기입니다.

이벤트 로그로부터 정확한 프로세스 모델을 도출하기 위해 고려해야 할 점은 무엇일까요?프로세스의 특성과 이벤트 로그에 맞는 적절한 알고리즘을 적용하는 것이 중요하지만 오늘은 좀 더 일반적인 사항에 대해 생각해 보겠습니다.프로세스 모델의 품질을 측정하는 4가지 기준은 Fitness, Generalization, Simplicity, Precision입니다.좋은 프로세스 모델을 발견하기 위해서는 이 4가지 기준 사이에서 균형을 잘 유지해야 합니다.[그림 1] 프로세스 모델 품질 측정의 4가지 기준Fitness(적합도)는 관찰된 이벤트 로그를 얼마나 잘 설명할 수 있는지를 나타냅니다. Fitness가 높을수록 모든 이벤트 로그의 경로를 표현하기 때문에 데이터 집합을 잘 설명할 수 있으나 수많은 경로가 프로세스 모델에 나타나게 되어 프로세스 모델이 복잡해지게 됩니다.Generalization(일반화)은 Overfitting을 피하는 것입니다. Overfitting된 모델은 모델 추출 대상이 되는 데이터(이벤트 로그)에 대해서는 정확도가 높으나 동일 프로세스에서 추출한 다른 데이터 집합에 대해서는 정확도가 낮고, 높은 오류율을 보여주게 됩니다. 따라서 Generalization 수준이 높을수록 다른 데이터에 적용했을 때의 적중률(설명 정도)이 높아져서 프로세스 모델을 다른 데이터에 적용하기가 좋습니다. 하지만, 지나치게 Generalization이 높을 경우 대상 데이터 집합에 대한 프로세스 모델 적중률만 높아지지 프로세스에 대한 의미 있는 정보를 전달하지 못하는 문제가 발생합니다.Simplicity(단순화)는 프로세스 모델을 단순하게 만드는 것입니다. 프로세스 모델이 단순할수록 쉽게 이해하고 한눈에 프로세스를 파악할 수 있으나 적합도가 떨어지게 됩니다. 적합도가 떨어지면 추출한 프로세스 모델로 설명할 수 없는 이벤트 로그가 많아지게 됩니다.Precision(정확도)은 Underfitting을 피하는 것입니다. Underfitting된 모델은 Overfitting과 달리 모델을 단순화하여 공통 경로만 표현하게 되어 프로세스를 정확하게 설명할 수 없게 됩니다. Precision이 높을수록 기존 데이터에 대해 정확하게 설명할 수 있으나 지나치게 높을 경우 다른 데이터 셋에 대한 오류율이 증가하는 문제가 생깁니다.4가지 품질 특성을 보면 Fitness와 Simplicity, Generalization과 Precision은 서로 반대되는 특성을 가지고 있습니다. 즉, Fitness가 너무 높으면 Simplicity가 낮은 문제가 생기고 Generalization이 높으면 Precision이 낮은 문제가 생기게 됩니다.Overfitting과 Underfitting 예제를 통해 좀 더 살펴보도록 하겠습니다.[그림 2] Underfitting과 Overfitting 그림[그림 2]에서 볼 수 있듯이 Underfitting은 데이터 분류 기준을 단순하게 구할 수 있으나 새로운 데이터 집합을 Underfitting된 모델에 대입하면 의미 있는 결과를 얻기가 힘듭니다. 이에 반해 Overfitting은 모든 데이터를 정확히 분류하고 있으나 데이터의 특성을 일반화시킬 수 없습니다. [그림 3] Underfitting 모델[그림 3]의 경우 모든 경로를 표현 가능하여 Fitness 만족, 다른 모델에도 적용 가능하여 Generalization 만족, 모델도 간단하여 Simplicity도 만족하지만 실제 프로세스가 어떻게 수행되는지 설명해 주지 못해 도출된 프로세스 모델에서 유의미한 정보를 얻을 수 없습니다. 즉, 모델이 Underfitting되어 Precision 조건을 만족시키지 못합니다.[그림 4] Overfitting 모델[그림 4]는 관찰된 이벤트 로그를 모두 나열한 프로세스 모델입니다. 이렇게 할 경우 모델을 도출할 때 사용한 이벤트 로그의 프로세스 패턴을 모두 나타내어 Fitness와 Precision은 만족하나 Simplicity와 Generalization은 만족하지 않습니다. Overfitting된 모델도 프로세스 모델에서 유의미한 정보를 얻을 수 없습니다.이상과 같이 Fitness, Generalization, Simplicity, Precision 4가지 기준을 잘 조화시켜야 정확한 프로세스 모델 도출이 가능합니다.#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트

 역삼 맛집▲ 금강산도 식후경이라 했던가? 맛있는 인터뷰가 맛있는 이유는 늘 음식과 함께 하기 때문이다오늘 온 맛집. 분위기가 심상치 않다. 어떤 곳인지 소개해달라. 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 #개발 #개발자 #개발팀 #인터뷰 #팀원 #팀원소개 #팀원인터뷰 #기업문화 #조직문화

출처: 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 #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

안녕하세요. 크몽 개발팀 입니다.오늘의 포스팅 주제는 "안드로이드 스튜디오" 입니다.안드로이드 스튜디오는 구글이 직접 만든 안드로이드 앱 개발 도구를 말하는데요.안드로이드 스튜디오는 2013년 5월 개발자 컨퍼런스를 통해 프리뷰 버젼을 처음 공개하였습니다.1년 6개월 정도의 기간동안 베타버전이였지만  지난달 8일에  안정화된 정식버전 1.0이 공개되었습니다.안드로이드 개발자 사이트에 가시면 공식적으로 다운받아서 안드로이드 앱을 개발 할 수 있습니다.( Eclipse로 앱을 개발중인데 개발자 사이트에 배포중인 ADT가 내려가서 당황했던 기억이 나네요^^ ) 안드로이드 스튜디오는 IntelliJ 기반으로 만들어 졌는데요.IntelliJ는 워낙 유명한 개발도구인지라 많은 개발자분들이 알고 계실겁니다.Eclipse 와 같이 통합개발툴인데 안정성과 속도면에서 Eclipse보다 뛰어나기때문입니다.하지만 Eclipse가 안드로이드 초기부터 개발자들이 이용해 왔기 때문에 대부분의 개발들에게 익숙하고현재 나온 가이드 or Tip 들이 Eclipse에 기준이 되어있어서 여러부분에서 시행착오를 겪을거 같습니다.그래서 그런지 안드로이드 스튜디오 정식버젼이 나왔지만 아직은 익숙한 Eclipse에 손이가는데요.앞으로 구글에서 공식적으로 ADT에 대한 지원을 끊었으니 조만간 안드로이드 스튜디오로 갈아탈려고 합니다.Android 개발자 사이트 링크 : http://developer.android.com/index.html----------------------------------------------------------------------------------------새롭게 나온 안드로이드 개발도구 "안드로이드 스튜디오"에 대하여  소개하는  포스팅 해보았습니다.다음에는 안드로이드 스튜디오를 직접 사용해보고 각각의 특징들에 대해좀 더 자세히 설명해드리겠습니다. ^_^#크몽 #개발팀 #인턴 #인턴생활 #팀원소개 #업무환경

EOS Smart Contract 를 위한 준비와 토큰 발행 그리고 C++를 활용해 토큰의 간단한 기능을 개발해 보겠습니다.환경 구성 및 지갑 생성은 SAM 님의 아래 2글을 참고해 주시기 바립니다.EOS — 설치 및 실행 (1/2)EOS — 동작구조 및 환경설정(2/2)지갑 생성하기SAM 님의 포스트를 참고 하셨다면 아마 다음과 같이 ‘default’ (별도의 이름을 지정하지 않았을 시) 지갑을 생성 하셨을 겁니다.이 지갑을 사용하여 계정을 Create 한 후 Key 를 Import 하겠습니다.Key 생성하기$ cleos create key위 명령을 실행 하시면 다음과 같은 화면을 얻을 수 있습니다.create key 명령의 결과**주의 : Private Key는 Public Key의 소유를 증명하는 중요한 개념으로 절대 타인에게 노출하면 안됩니다.AdditionalKey 생성 후 지갑에 import 하기 귀찮으시다면 생성된 지갑에서 바로 Key 를 생성하셔도 됩니다.$ cleos wallet create_key위와같이 key가 생성 됩니다. 하지만 public key 만 보이기 때문에 하단 명령 입력 후 지갑 key를 입력하면 private key를 확인할 수 있습니다.$ cleos wallet private_keys지갑에 Key import하기지갑은 Public Key — Private Key를 저장하는 저장소 입니다. 생성된 키를 지갑에 저장하기 위해 다음과 같은 명령어를 입력합니다.$ cleos wallet import-n : 옵션을 사용하면 지갑의 이름을 지정합니다. 지정하지 않는다면 기본 생성된 default 지갑으로 지정됩니다.위 명령을 입력 하면 key 가 임포트 되었다는 결과를 확인 할 수 있습니다.** 만약 지갑을 Unlock 한 상태가 아니라면 ‘private key: Error 3120003: Locked wallet’ Exception 이 나옵니다.unlock 을 위해 다음 명령을 실행한 후 wallet 생성시 저장했던 Key를 입력하여 Unlocked 상태로 만들어 줍니다.$ cleos wallet unlock password: Unlocked: default(Optional) 지갑에 저장된 Key 리스트 확인다음 명령어를 입력하여 지갑에 key 가 잘 import 됐는지 확인합니다.$ cleos wallet keys계정 생성eosio.token 이라는 이름으로 계정을 생성하도록 하겠습니다.** 지갑과 Key 그리고 계정에 관해서는 Hexlant 미디움에 게재될 예정입니다.$ cleos create account eosio eosio.token EOS63kstp8kthzJY3rAotp1LAxUDbWk4MywReG578R2ddbktrDHYKcreator : eosioaccount name : eosio.tokenowner key : 지갑에 import 된 keyAdditional본 포스팅은 local 환경에서 빌드 후 System Contract 들이 적용되지 않은 상황을 가정하였습니다. 만약 Public Network 환경에서 접속 시 eosio 와 eosio.token을 사용할 수 없습니다.또한 계정이름은 다음과 같은 규칙을 따릅니다.- 12문자- 12345abcdefghijklmnopqrstuvwxyz 만 사용 가능** 만약 ‘Error 3090003: provided keys, permissions, and delays do not satisfy declared authorizations’ 에러 발생 시 eosio 에 대한 key 를 지갑에 import 해야 합니다.eosio 에 대한 정보는 다음과 같습니다.public key: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CVprivate key: 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3위 과정을 모두 마쳤다면, EOS 지갑과 키 그리고 계정에 대한 권한을 모두 가지고 있는 상태가 됩니다. 다음 포스팅에서는 이 계정을 사용 하여 Token 을 발행하는 방법을 알아보도록 하겠습니다.감사합니다#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

버즈빌에서는 미국과 일본을 비롯한 전 세계 30개국에서 1,700만 이상의 유저의 행동에 대한 데이터를 수집하고 있습니다. 이 데이터에는 유저들이 잠금화면에서 어떤 Action을 수행하는지부터 잠금화면에 어떤 광고가 노출되고 유저들이 어떤 광고를 클릭 하는 지 등의 정보들이 포함되는데요. 이러한 데이터는 여러 종류의 다른 소스로부터 오고 각기 다른 종류의 DB (MySQL, DynamoDB, Redis, S3 등등) 에 저장됩니다. 하지만 데이터를 분석하고 활용하기 위해서는 이렇게 흩어져서 저장된 데이터들을 한 곳으로 모으는게 필수적입니다. 그래서 저희 팀에서는 이렇게 다양한 소스로 부터 발생해서 다양한 DB에 저장된 데이터를 어떤 과정을 통해 한 곳으로 모을 것인가에 대해서 고민하게 되었습니다. 그리고 고민 끝에 각각의 DB에 저장된 데이터를 하나의 큰 데이터 스토리지에 모을 수 있는 ‘데이터 파이프라인’을 구축하는 계획을 세우게 되었습니다. 하지만 다양한 소스로부터 수집된 수많은 데이터들을 잘 유지해가며 하나의 큰 DB에 모을 수 있는 데이터 파이프라인을 구축하는 것이 쉽지 않았는데요. 이 포스팅을 통해서 버즈빌에서는 어떻게 각각의 데이터들을 수집하고 저장하는지 또 이런 데이터들을 통합하기 위한 파이프라인을 어떻게 구축했는지 공유하고자 합니다. 본격적인 이야기에 앞서 현재 버즈빌에서 모든 데이터가 모이는 데이터 스토리지로 사용 중인 RedShift에 대해 이야기하고 싶습니다. 개인적으로는 정말 쓰면 쓸수록 감탄이 나오는 데이터 스토리지라고 생각합니다. Redshift는 AWS에서 관리하는 SQL기반의 열기반 스토리지(SQL based columnar data warehouse)이며 복잡하고 대규모의 데이터 분석에 적합합니다. 고객들로부터 생성된 수많은 종류의 데이터를 기반으로 다양한 인사이트를 얻고자 하는 많은 기업들(Yelp, Coursera, Pinterest 등)이 사용하고 있는 솔루션 이기도 합니다. 버즈빌에서는 여러가지 특징을 고려하여 Redshift를 도입하게 되었는데요. 그 이유는 아래와 같습니다.  Performance Performance Performance.     Column 기반 스토리지 -> 필요한 Column에만 접근한다.   Join이나 aggregation이 많은 복잡한 쿼리도 쉽게 계산할 수 있다.   분산 저장 방식 (Distributed Storage)   Date Ingestion이 빠르다. (Ingest first, index and clean later)     Horizontal Scalability   sharding이나 clustering에 추가적인 complexity가 필요하지 않다. 데이터가 원래 노드에 저장되기 때문에 horizontal scaling을 위해서는 그냥 추가적인 노드만 붙이면 된다. 다른 AWS서비스들과 쉽게 연동이 가능하다. (장점 이자 단점)    하지만 몇 개의 아쉬운 점들도 있습니다. :  다른 RDBMS와 달리 Mutilple indice를 지원하지 않는다.  1 Distribution Key and 1 Sort Key   MySQL이나 다른 RDBMS처럼 uniqueness나 foreign key constraint를 걸 수 없다.     모은 데이터를 어떤 방식으로 Redshift로 옮겨야 할까요? 버즈빌이 구축한 데이터 파이프 라인은 크게 3갈래의 메인 루트가 있습니다.   1) Athena Preprocessing Batch job을 통해서 (잠금화면 활동, 광고 할당) Why? 전처리 작업(Preprocessing)이 필요한 가장 큰 이유는 들어오는 데이터의 어마어마한 크기 때문입니다. 또 어떤 데이터들은 너무 raw하기 때문에 애널리스트나 데이터 사이언티스트가 분석에 활용할 수 있는 형태로 바꾸기위해 전처리가 필요하기도 합니다. 버즈빌에서는 이런 데이터들을 처리하기 위해서 AWS Athena를 사용하고 있습니다. Athena는 과금 방식이 Athena 쿼리로 읽은 데이터의 사이즈를 기반으로 하기 때문에 다른 EMR이나 MapReduce solution들을 사용했을때보다 상대적으로 적은 비용으로 활용할 수 있다는 장점이 있습니다. How?  먼저 S3로 데이터를 보냅니다. 그 후, Athena를 활용하여 데이터를 가공/처리합니다. 가공된 데이터를 읽어서 Redshift로 보냅니다. (COPY command 활용)  Pros?  서버를 따로 가질 필요가 없습니다. (EMR 클러스터나 서버를 관리할 필요가 없음) 경제적입니다. (S3에서 1TB를 읽을때마다 $5 정도의 비용)  Cons?  사용량이 몰리는 시간대 (12:00 AM UTC)에는 일부 쿼리가 실패할 수 있습니다. -> 중요하고 필수적인 데이터는 Athena가 아닌 다른 방법을 통해 처리하는것이 적합합니다. PRESTO DB의 기능을 (아직은) 온전히 활용할 수 없습니다.     2) Firehose를 통해서 (Impression, Clicks, Device, Events) Why? Kinesis Firehose는 Redshift, Elasticsearch, S3와 같은 최종 목적지까지 다양한 데이터들을 안정적으로 옮길 수 있는 파이프라인을 제공할 뿐 아니라 Fluentd와 매끄럽게 잘 연동된다는 점에서 굉장히 뛰어난 서비스 입니다. Fluentd는 서버로부터 firehose까지 데이터가 안정적이고 꾸준하게 전달 될 수 있도록 도와줍니다.  따라서 firehose와 fluentd의 연동을 통해서 따로 두개의 파이프라인 ( SERVER -> S3, S3 -> Redshift) 을 관리할 필요 없이 데이터 소스부터 최종 저장소까지 이어지는 하나의 파이프 라인만 관리할 수 있게 됩니다. How?  (https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)  적절한 data format과 원하는 ingestion period를 설정하여 Firehose delivery stream을 만듭니다.   conf["user_activity"] = { "DataTableName": "user_activity", "DataTableColumns": "user_id, app_id, activity_type, timestamp", "CopyOptions": "FORMAT AS JSON "s3://buzzvil-firehose/sample/user_activity/jsonpaths/user_activity_log-0001.jsonpaths" gzip TIMEFORMAT AS "YYYY-MM-DDTHH:MI:SS" ACCEPTINVCHARS TRUNCATECOLUMNS COMPUPDATE OFF STATUPDATE OFF", "jsonpaths_file": "buzzvil-firehose/sample/user_activity/jsonpaths/user_activity_log-0001.jsonpaths", } configuration = { "RoleARN": "arn:aws:iam::xxxxxxxxxxxx:role/firehose_delivery_role", "ClusterJDBCURL": "jdbc:redshift://buzzvil.xxxxxxxxx.us-west-2.redshift.amazonaws.com:5439/sample_db", "CopyCommand": { "DataTableName": sample_table, "DataTableColumns": conf[type]["DataTableColumns"], "CopyOptions": conf[type]["CopyOptions"], }, "Username": db_user, "Password": db_password, "S3Configuration": { "RoleARN": "arn:aws:iam::xxxxxxxxxxxx:role/firehose_delivery_role", "BucketARN": "arn:aws:s3:::firehose_bucket", "Prefix": "buzzvil/user_activity/", "BufferingHints": { "SizeInMBs": 64, "IntervalInSeconds": 60 }, "CompressionFormat": "GZIP", "EncryptionConfiguration": { "NoEncryptionConfig": "NoEncryption", } } }  2. Fluentd docker containers을 각각의 서버에서 세팅하고 실행합니다.  @type tail path /var/log/containers/buzzad/impression.json pos_file /var/log/containers/td-agent/impression-json.pos format none tag firehose.impression @type kinesis_firehose region us-west-2 delivery_stream_name "prod-buzzad-impression-stream" flush_interval 1s data_key message  3. Firehose에서 데이터를 잘 모아서 Redshift 문제없이 보내고 있는지 모니터링 합니다.  Pros?  빠르고 안정적인 데이터 전송이 가능합니다. 모니터링이 편합니다.  Cons?  Schema가 자동으로 바뀌지 않습니다.( Redshift의 Schema를 수동으로 일일히 변경해주어야 합니다.)     3) MySQL Asynchronous Loads를 통해 (Ads, Contents, Ad Provider, Ad Publishers) Why? 여러대의 RDS MySQL DB로부터오는 데이터간의 sync를 맞춰가며 Redshift로 데이터를 복제하기 위해서는 3가지의 테크닉을 활용해야만 합니다. (이 방법은 소개하고 있는 세 메인 루트 중에서 가장 매력도가 떨어지는 방법입니다..) How?  FULL_COPY  MySQL 테이블 전체를 복사해서 SQL insert를 통해서 Redshift에 복사합니다.     INCREMENTAL_COPY  이전에 복사한 가장 마지막 Primary key부터 시작해서 새로생긴 row들을 읽어서 Redshift로 복사합니다.     UPDATE_LATEST_COPY  이전에 복사한 가장 마지막 타임스탬프부터 시작해서 새로 생성되거나 업데이트된 row들을 Redshift로 복사합니다.(중복된 값은 삭제).    Pros?  데이터의 특징에 맞게 잘 조정된 방법입니다. binary log를 통한 Replication보다 훨씬 다루기 쉽습니다.  Cons?  MySQL을 잘 조정하기 위해 여러대의 서버나 lambda를 다루어야만 합니다. -> Redshift sync task를 위해서 안정적인 schema altering을 할 수 있을 만큼 Redshift의 ORM이 발전된 상황은 아닙니다..    어떤 데이터를 다루는지에 따라서 위에서 소개한 3가지 방법 중 어떤 방법을 활용해야할지가 달라진다고 할 수 있습니다. 예를 들어 Transactianl log 같은 데이터들의 경우에는 firehose를 통해 전달하는 방법이나 먼저 aggregate하는 과정을 거친 후에 Redshift에 저장하는 식으로 처리를 해야 합니다. 그리고 MySQL에 저장된 fact table같은 데이터들은 CDC (change data capture) sync method를 통해서 Redshift에 데이터를 전달하고 동기화를 하는 과정이 필요합니다. 버즈빌에서는 위에서 소개해드린 3가지 방법을 적절히 조합해가면서 BD 매니저나 애널리스트들이 서비스간 플랫폼간의 데이터분석을 쉽게 할 수 있는 데이터 환경을 구축하기 위해서 노력하고 있습니다.

디버깅(Debugging)은 오류가 발생했을 때 발생 위치를 확인할 수 있는 방법입니다. 앱이 일시 중지된 상태에서 변수를 검사하고 식을 평가해 런타임 오류 원인을 판별할 수 있죠. 중단점 걸기우선 확인하고 싶은 라인에 중단점을 걸어 앱 실행을 일시 중지합니다. 중단점을 거는 방법은 라인 옆의 빈공간을 클릭 하거나 단축키 (Command+F8 / Control+F8)를 클릭합니다. 아래 이미지의 라인 옆의 빨간 점이 중단점입니다.앱이 실행 중일 때오른쪽 상단의 Attach debugger to Android process를 클릭해 디버깅 모드를 실행할 수 있습니다.앱이 실행 중이지 않을 때Debug ‘app’ 버튼 또는 단축키(^D)를 클릭해 디버깅 모드를 실행합니다.앱이 실행되다가 단점을 만나면 아래와 같이 앱은 일시중지될 겁니다.이때 디버깅 탭의 도구들을 사용해서 앱의 상태를 확인할 수 있습니다.만약 Variables 영역이 보이지 않으면, 1번 영역에서 Restore Variables View를 클릭합니다. 이 영역은 변수의 객체 트리를 확인할 수 있습니다.변수 위에 마우스 커서를 올리면 Variables 영역을 보지 않고도 변수를 확인할 수 있습니다. + 를 누르면 더 자세한 객체 트리도 확인할 수 있습니다. 객체는 왼쪽의 화살표를 누르면 객체에 속한 필드도 확인할 수 있습니다.객체 트리 확인객체에 속한 필드 확인2번 영역은 현재 어느 메서드에 멈춰있는지 알려줍니다. main에서 시작해 run, invoke… onCreateView에 일시중지한 것을 보여줍니다.1번 영역의 Restore Watches View를 클릭하면 아래 화면이 보입니다.Watches는 break 된 상태에서 코드를 실행할 수 있는 창입니다. 모든 코드를 사용할 수 있는 것은 아니고 현재 라인에서 사용 가능한 코드만 쓸 수 있습니다. + 버튼을 눌러 확인하고 싶은 코드를 입력하면 결과를 바로 확인할 수 있습니다.아래 이미지는 디버깅 탭입니다. 각 버튼의 기능을 알아볼까요?디버깅 탭중단점을 만나 일시중지된 상태에서 Step Over 버튼을 클릭해 다음 줄로 이동합시다.Step Into 버튼을 클릭해 getContents() 메서드의 첫 라인으로 이동합니다.Step Out 버튼을 클릭해 getContents() 메서드 밖의 다음 줄로 이동합니다.Step Over 버튼을 눌러 코드의 다음 줄로 이동합니다.지금까지 안드로이드 디버깅 방법을 알아봤습니다. 기능이 많아서 처음부터 다 활용할 순 없겠지만 계속 기능을 사용하다 보면 점점 익숙해지지 않을까요? 참고앱 디버깅  |  Android Developers급식어플 블로그 : 네이버 블로그글김보예 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #안드로이드 #Android #디버깅 #문제해결

제대로 된 기업용 서비스라면 의례 다중 계정과 권한 제어 기능을 함께 제공하기 마련이다. 그래서 공용 계정을 굳이 만들 이유가 하나도 없다. 하지만 일부 서비스(그리고 대부분의 한국의 기업 서비스)는 단일 계정만 지원하는데다 AWS 같은 서비스도 root 계정이 따로 있어서 계정 관리 이슈가 불거지기 마련이다. 계정 아이디와 암호의 경우는 LastPass 같은 기업용 계정 관리 서비스를 사용하거나 팀 공용 계정 비밀번호 관리하기에서 소개된 방식과 같이 약간은 불편하지만 비용이 들지 않는 수단을 도입하여 관리하면 된다. 그런데 MFA 또는 2FA(2-Step Verification)라고도 부르는 OTP로 계정을 보호할 때는 OTP 정보를 공유하기가 쉽지 않다. 일반적으로 MFA 계정은 Google Authenticator 같은 앱을 설치해 관리한다. OTP 정보와 계정 암호를 한 계정에서 관리하지 않아야 한쪽이 노출되어도 보안을 유지할 수 있기 때문이다. 문제는 Google Authenticator와 Authy 같은 도구를 특정 휴대폰에 설치하면 여러 사람이 OTP 정보를 공유하기 힘들다는 것이다. 그래서 몇가지 솔루션을 찾아보았는데 “이거다!” 싶은 건 없어도 gauth라는 명령줄 기반 도구에 안착하게 되었다.gauth.csv라는 파일에 OTP 정보를 아래와 같이 입력하고AWS: ABCDEFGHIJKLMNOPQRSTUVWXYZ234567ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 Airbnb:abcd efgh ijkl mnop Google:a2b3c4d5e6f7g8h9 Github:234567qrstuvwxyzgauth를 실행하면 아래와 같이 OTP 토큰을 확인할 수 있다.$ gauth prev curr next AWS 315306 135387 483601 Airbnb 563728 339206 904549 Google 453564 477615 356846 Github 911264 548790 784099 [======= ]이제 gauth.csv 파일만 라스트패스 등으로 제한된 사용자에게 안전하게 공유하면 된다.개선 사항DailyHotel/gauth는 pcarrier/gauth를 개선한 tuxmartin/gauth를 Docker 이미지로 감쌌다. 그래서 Golang 개발환경을 갖추고 소스코드를 빌드하지 않아도 바로 사용할 수 있다. 자세한 사용법은 README 문서에 적어두었다.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트 #꿀팁

[맛있는 인터뷰] 잔디의 헬스보이, 안드로이드 개발자 Steve를 만나다                                         미소, 승리의 V, 로맨틱, 성공적                                       삶은 생각보다 심플한 것 같아요.                              인생은 결국 생각하는 대로 풀리게 되더라고요.                                     잔디에서 제 목표를 이뤄가고 있어요.                                      – Steve, 잔디 안드로이드 개발자편집자 주: 잔디에는 현재 40명 가까운 구성원들이 일본, 대만, 한국 오피스에서 일하고 있습니다. 국적, 학력, 경험이 모두 다른 멤버들. 이들이 어떤 스토리를 갖고 잔디에 합류했는지, 잔디에서 무슨 일을 하고 있는지 궁금해하시는 분들이 많았습니다.  이에 잔디 블로그에서는 매 주 1회 ‘맛있는 인터뷰’라는 인터뷰 시리즈로 기업용 사내 메신저 ‘잔디’를 만드는 사람들의 이야기를 다루고자 합니다. 인터뷰는 매 주 선정된 인터뷰어와 인터뷰이가 1시간 동안 점심을 함께 하며 다양한 이야기를 나누며 진행됩니다. 인터뷰이에 대해 궁금한 점은 댓글 혹은 이메일([email protected])을 통해 문의 부탁드립니다.오늘의 ‘맛있는 인터뷰’ 장소는 어디인가요?‘롱브레드’라는 빠니니집이에요. YB와 같이 버디런치할 때 갔었는데 맛있었어요. 강남이라는 위치 특성 상 보통 식당들이 혼잡한데 여긴 조용한 편이에요.                                       빠니니 앞에 우리는 겸손해진다.잔디 블로그가 유명해지면 그리되겠죠? 자기소개 좀 부탁드릴게요안녕하세요? 스타트업을 동경해 안정적인 삶을 뒤로 하고 잔디에 조인한 안드로이드 애플리케이션 개발 담당자 Steve입니다.안드로이드 개발 중에서 어떤 일을 맡고 계신가요?지금은 전체적인 부분을 다 하고 있어요. 안드로이드 쪽으로 가장 먼저 입사한 사람이라 요즘 들어오는 개발자분들 OJT도 하고, 주요 개발 포인트에도 열심히 참여하고 있습니다.그렇군요. 헬스 트레이너 자격증을 갖고 계신단 얘길 들었어요.사실 운동을 전문적으로 하려 그런 건 아니었고, 옷 맵시를 잘 살리고 싶어 운동을 시작했어요. 제가 과거에 개그 콘서트 ‘헬스보이’에 나오는 김수영 같았담 몸매였다면 믿기시겠어요? 인생의 암흑기였던 그 시절, 어떤 옷을 입어도 멋있지 않았어요. 딱 한 번이라도 좋으니 뭘 입어도 간지가 났으면 좋겠단 생각을 했어요. 그게 제 생활 습관을 바꾼 계기였어요.트레이너 자격증 따는 게 쉽지 않을 것 같아요트레이너 자격증 준비할 당시엔 장기적으로 꾸준히 운동했어요. 아침 6시에 일어나 운동하고 오전, 오후 일과를 보낸 뒤 오후 5시부터 다시 운동하고 11시에 자곤 했어요. 식단은 하루에 5끼를 한 가지 종류의 메뉴로 구성해 1년 동안 먹었는데요. 정말 힘들 때는 한 달에 한 번 피자를 먹기도 했습니다.참기 힘든 유혹의 순간이 있진 않았나요?음.. 실기 시험 일주일 전이었어요. 여긴 특이하게 짧은 바지만 입고 몸을 보여주는 테스트를 통과해야 필기 시험을 볼 수 있었는데요. 실기 시험 전 참석했던 친한 동기 생일에서 술을 마다하고 최대한 절제하고 있었어요. 근데 친구가 자기 생일인데 왜 안 마시냐 핀잔 아닌 핀잔을 주더라고요. 그 때 조금 마셨는데 순간 고삐가 풀리더라고요. 이후 3시간 동안 미친 듯이 술과 안주를 먹었어요. 정말 다행히 실기 시험에 통과했지만 그때 한번 제대로 이성을 잃었던 적이 있습니다.헬스를 하면서 얻은 수확이 있다면?1년 정도 운동을 하니 규칙적인 생활이 몸에 뱄어요. 언제, 무엇을 할지 계획을 세워 생활하다 보니 어떻게 하면 효율적으로 시간을 사용할 수 있을지 알게 되었는데요. 운동을 통해 스스로 인내하고 제어하는 방법을 그 때 다 배웠어요.그 습관이 업무에 도움이 되셨나요?업무 관련 이야기는 아니지만 잔디에 합류하기 전 이직 준비를 1년 넘게 했어요. 이직에 필요한 사항을 정리해 최선을 다해 준비해보자 마음먹었어요. 이때 운동을 통해 다진 규칙적인 생활 습관이 큰 도움이 되었는데요. 꼬박 1년 동안 밤낮을 가리지 않고 개발 공부에 매달렸어요. 덕분에 ‘함께 일해볼 생각이 없냐?’는 제의를 많이 받았어요.                                 일할 땐 진지 모드, 밥 먹을 땐 샤방 모드.그런 제의를 고사하고 잔디를 선택하신 이유가 있다면?몇 가지 이유가 있는데요. 스타트업에 계시는 다른 분들을 보고는 비전이 있는 곳으로의 이직을 결심했어요. 5년 차 엔지니어로서 1년이라는 시간을 가지고 승부수를 던진 거예요. ‘생각하면서 살면 생각한 대로 살지만, 살면서 생각하면 사는 대로 생각하게 된다.’는 말을 인상 깊게 봤어요. 이 말대로 실천하려고 노력해 온 게 시간이 지나니 확실히 남들과 차이가 커지더군요.  그래서 생각하면서 사는 게 얼마나 중요한지 알고 있어요. 그중에서도 직장은 하루에 큰 부분을 차지하니까 신중하게 직장을 선택하는 건 인생의 중요한 전환점이죠.잔디에서의 생활은 만족스러우세요?기대했던 모든 게 다 잔디에 있는 것 같아요. 업무에 대한 자율성과 책임감이 적절히 섞여 있어요. 일반 회사의 수직적 구조도, 팀장급 이상에게만 주어지는 의사 결정권도 잔디에선 찾아볼 수 없어요. 덕분에 다양한 시각과 방법으로 개발 업무를 할 수 있기 때문에 전 개인적으로 만족하며 일하고 있습니다.쉬는 날에는 보통 어떤 활동을 하세요?업무 관련 공부를 하거나 친구들을 만나곤 해요. 개인적으로 회사 근처에 사는 걸 선호해 현재 강남 쪽에 살고 있는데요. 덕분에 친구들과의 약속이 잦아졌어요. 약속이 없는 날에는 주로 혼자 공부하고 있어요.이전 인터뷰이인 Jay님이 오늘 인터뷰이에게 ‘좋은 프로덕트란 어떤 것인지’ 물어봐달라고 하셨는데요. 이 질문에 대한 Steve의 답변은?좋은 프로덕트란 ‘복잡한 설명이 없어도 모든 동작을 깔끔하게 작동할 수 있게 만드는 것이다’ 라고 정의하고 싶습니다. 이를 위해선 개발자들이 모든 프로세스를 다 자동화해야겠죠? 생각보다 매우 꼼꼼한 업무가 필요한 과정이라 개발자들에게는 스트레스가 될 수 있을 거에요. 하지만 이건 개발자의 몫이고 사용자에게는 ‘편리함’과 ‘익숙함’을 제공해야 한다고 생각합니다. 제품 사용을 위한 프로세스를 최대한 단순화시켜 사용자가 자신이 원하는 동작 이외의 행동에 대해 생각하지 않게 만드는 게 최고의 프로덕트인 것 같습니다.미리 준비하셨나요? 인상적인 답변이네요. 마지막으로 다음 인터뷰를 위한 릴레이 질문이 있으시다면?다음 인터뷰이 분에게 ‘일과 사랑 어느 쪽이 우선인지’ 꼭 물어봐 주셨으면 좋겠습니다. 보통 스타트업을 다니면 연애하기 힘들다고 하잖아요. 왠지 다음 분께서 어떤 대답을 하실지 궁금하네요.열정적인 Steve와의 인터뷰 이후 ‘잔디의 안드로이드 개발 부분은 걱정 없겠구나’ 란  생각을 하게 되었습니다. 앞으로도 잘 부탁해요 Steve! 다음 주 인터뷰도 많은 기대 부탁 드려요.#토스랩 #잔디 #JANDI #개발자 #앱개발자 #애플리케이션 #모바일 #팀원 #팀원소개 #팀원인터뷰 #인터뷰 #사내문화 #조직문화 #기업문화 #팀원자랑