스타트업을 4번 창업해보면서, 과연 투자, Funding이 갖는 의미에 대해서 이렇게 진지하게 생각해 본 적이 있었나 싶다. 어찌 보면 너무 어리고 모르기도 했었던 것 같기도 하고, 실제로 투자가 자금 그 이상도 이하도 아닌 생존을 위한 수단이었던 경험들이 더 많았던 것 같다. 그러나 이번에 핀다를 시작하고 투자를 2번 받게 되면서 이에 대해서 다시 생각해 볼 수 있는 계기가 되어 그 생각을 공유해보고 싶었다.(본격적으로 글을 쓰기 전에) 핀다(Finda) 를 시작한 지 1년도 되지 않았고, 아직은 초기 기업이기에, 다른 훌륭한 창업자들과 선배님들에 비하자면, 사실 많이 짧은 생각일 수 있다. 그래서 지극히 주관적이고 개인적인 생각임을 먼저 알리고 싶다.투자는 언제 받아야 할까?가장 많이 듣는 질문이다. 나 또한 스스로에게 그리고 초반 공동창업자인 홍민님과도 가장 많이 이야기했던 요소가 바로 '타이밍'이었다. 왜냐하면 피말리는 경험을 한 적이 있기 때문이다. 정말로 자금이 천만 원 이하로 떨어져서 두 달치 급여를 주지 못했을 만큼 투자 타이밍을 놓쳤을 때. 다시는 그런 경험을 하고 싶지 않을 만큼 힘들었다.개인적으로는 두 가지가 가장 중요하다고 생각한다. 1) 앞으로 1년 이상의 시간 동안 정말 우리 회사가 만들고 싶은 제품과 서비스 그리고 팀에 얼마나 자금이 필요할지, 2)그리고 그 자금을 어떤 방식, 즉 투자인지 매출인지 등으로 채워나갈 수 있을지가 어느 정도 자신 있게 그림 그릴 수 있을 때를 아는 것. 물론 초기에는 도화지에 스케치했던 것들을 여러 번 지우고 덧 그리기는 했었지만, 뼈대를 잘 살렸다면 계획도 잘 세우고 좋은 타이밍에 투자를 받았다고 평가해도 좋을 것 같다.하나의 부수적인 팁으로는 어느 정도 runway가 남았을 때 IR을 시작하는 것이 내게는 좋았던 것 같다. 우리 회사의 경우 약 8개월 정도 자금이 남았을 때 본격적으로 IR을 시작했는데, 그래서인지 마음이 덜 조급해지기도 했고, 결과적으로는 매우 운이 좋게도 빠르게 투자를 유치하는데 큰 도움이 되었다.투자는 누구에게 받아야 할까?창업자라면 한 번이라도 고민했을 부분이라고 생각한다. 예비창업자라도 부모님, 친구, 지인 등에게 작게라도 투자를 받고 시작할 수 있을 거라고 생각할 수 있으니 말이다. 사실 투자를 고민할 때 가장 먼저 생각이 드는 질문이기도 하다. 이에 대한 고민을 할 때마다 나는 주변에 창업 선배님들이나 예전 투자자분들 그리고 멘토분들에게 많은 조언을 구하고 있다.2014년 7월 투자자이자 스타트업멘토인 이택경대표님, 호창성대표님, 정세주대표님, Scrum Ventures 의 Tak, 류중희대표님, 임정욱센터장님 그리고 비석세스 정현욱 대표이에 대해서는 내 경험을 조심스럽지만 꼭 공유하고 싶다. 지금까지 투자자들은 적어도 내가 해결해나가는 문제에 크게 공감해 주셨던 분들이었던 것 같다. 그래서 만약 공감해주는 분들을 만난다면 그 ‘관계’가 매우 중요하다고 생각했다. 물론 투자를 받았던 ‘나의’ 투자자이든, 받지 못한 아쉬운 분들과의 관계 모두…모두에게 인정받을 수는 없지만, 하지만 관계가 없거나 안 좋다가도 다시 좋아질 수 있다. 그리고 다시 기회는 올 수 있다! 생각지도 못했지만 현재의 투자자가 된 퓨처플레이와의 첫 만남은 잊을 수가 없다. 정부 자금지원을 위한 후보자들의 IR이 있는 날인데, IR인 줄 모르고 참석해서 제대로 발표를 망쳤는데, 난 아직도 그 실망한 투자팀들의 표정을 잊을 수가 없다. 아직도 떠올리면 등에 땀이 날 정도다.그때 어떤 생각이었는지 1주일 이후에 다시 한번 기회를 달라고 사정했고, 아주 가까스로 1달 뒤 정부자금 지원에 성공했다. 그 날 이후로 주말 없이 미국과 한국팀과 함께 자료를 만들고, 최종 발표 전에는 선정릉 공원을 돌며 발표자료와 스크립트를 중얼거리며 준비했었다. 하지만 결론적으로는 본사가 미국에 있고 한국인 지분율이 크지 않아 최종 심의에서 떨어졌고, 그렇게 퓨처플레이와는 관계를 다하는 듯했다. 하지만, 생각지도 못하게 이번 창업 아이템에 대한 고민, 그리고 시작 그리고 두 번의 투자를 모두 류중희 대표님 그리고 퓨처플레이와 함께하게 되었고 그렇게 관계는 시간에 따라 바뀌어가지만 계속 이어지고 있다.그리고 두 번의 투자를 리드했던 500 스타트업, Tim Chae와 샌프란시스코, 500 Stratups, 500 Kimchi는 너무나 할 이야기가 많아, 다음 기회에 다시 하도록 하겠다.2015년 2월 500스타트업 데모데이 때 현 500 Kimchi 의 Tim Chae Partner와 Founding Partner인 Dave Mcclure와 함께 핀다는 투자를 통해 어떤 것들을 이루고자 하나?첫 번째, 제대로 된 프로덕트와 서비스의 구축이다. 현재까지 핀다는 풀어나가고 싶은 문제의 1/100 정도를 풀었다. 금융상품을 가입하고 개인의 자산을 관리하는데 개인들이 겪고 있는 문제점은 정말 너무나도 많다. 그러기 위해서는 이 문제를 함께 풀 수 있는 정말 좋은 팀이 필요하다. 프로덕트와 서비스를 기획하고 설계하고 개발하고 풀어나가는데 더 많은 사람들과 함께하고 싶다.둘째, 고객들에게 정말 유용한 콘텐츠를 많이 생산하고 전달할 예정이다. 학창 시절 소위 ‘경제’라는 과목을 배웠지만, 실제 ‘개인금융’과 직결되는 경제에 대해서는 정말 회사를 취직해서도 아무것도 아는 것이 없었다. 부모님에게로부터 독립하지 못했기에, 무지한 채로 돈을 벌게 되었고 버는 족족 나가기가 일 수였다. 엄마에게 통장과 알지 못하는 보험 등을 넘겨받았을 때 당황했던 그 순간을 아직도 잊을 수가 없는데, 그 이후로 제대로 된 교육은 아니었지만 내게 필요한 정보를 찾고 적용하는데 무려 10년이나 걸렸다. 특히 부모님과 다른 시대를 살고 있는 우리들에게 부모님과 같은 금융생활, 절약, 투자, 저축 이 모든 게 너무나 달랐기에 우리 밀레니얼들이 필요한 금융 정보는 정말 필요하다고 생각한다.       마지막으로, 우리 팀을 위해 쓰고 싶다. 늘 넉넉하지 못하더라도, 지금까지 최고의 팀원에게 주는 상, 그리고 두 번의 명절, 생일, 결혼, 돌과 같은 경조사 그리고 아주 가끔의 회식 등을 통해 격려와 축하를 나누려고 홍민 님과 노력했고 앞으로 더 노력할 예정이다.이 모든 것을 가능하게 만드는 데 우리 핀다의 선택은 투자였고, 앞으로도 투자와 그리고 매출을 통해 더 많은 꿈들을 이뤄내고 싶다. Build Things that Matter.#핀다 #스타트업 #창업자 #창업가 #투자유치 #자금유치 #자금조달

레일즈 기반의 프론트엔드(브라우저에서 서버 사이드 렌더링 계층까지)와 자바 기반의 백엔드(내부 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

아래 이야기는 실제 예비 신혼부부가 오피노의 고객사 부동산플래닛의 서비스를 사용하는 과정을 조금의 각색을 더해 재구성하였으며 이미지에 첨부된 지역은 임의로(하지만 희망이 담겨...) 캡처되었음을 미리 알려드립니다. #집 검색 예랑: 내가 낮에 xx 지역에 집 보고 카톡으로 공유 해 줬거든, 그 집 한번 볼래?. 내부는 괜찮은거 같던데.우측 상단의 공유버튼신부: 잠깐만…데스크탑 좀 키고... 집 볼때 로드뷰 봤어? 주차 공간은? 예랑: 로드뷰 봤지. 아이폰으로 볼 땐 지도 위쪽에 작은 크기로 있으니까 놓치지 말고 . 보고나서 일단 관심매물 등록 해놨어.빨간맛...아니 빨간색 관심매물 버튼이  사용자를 유혹한다신부: 그래? 데스크탑에선 로드뷰 메뉴 찾기 쉽게 되어있는데. 우선 옵션이랑 쭉 살펴볼게~주변 편의시설과 로드뷰 외에도 다양한 매물 정보를 확인할 수 있다# 실거래가 검색 신부: 오빠, 이제 전세자금 대출 준비도 해야겠다. 예랑: 그러게, 요즘 xx 지역 전세자금 대출 얼마나 받을 수 있으려나.신부: 전세자금 대출도 대출인데, 건물 종류가 뭔지에 따라 전세자금 대출 조건이 달라지니까 건물 종류를 같이 따져야 돼예랑: 집 종류는 아파트 아니면 빌라 같은거 아닌가? 신부: ......예랑: 바로 알아볼게 어떤 종류가 있는지! 다양한 부동산 종류에 압도되지 말자. 각자의 목적에 맞는 종류를 선택하면 된다예랑: 아파트 오피스텔은 알겠는데 연립/다세대랑 단독/다가구는 처음보네.신부: 우선 우리가 전세 계약한 집 볼거니까 아래쪽에 상가~토지 까지 전부 해제해 봐.예랑: 그럼 주거용만 보기 누를게.신부: 그리고...우리가 전세 계약한 단독/다가구... 34억 이거 클릭해봐.예랑: 역시. 로또 된거 맞네. 34억 지금 사면 얼마나 더 오를려나??? 신부: 쓸데 없는 소리하다 혼난다. 전세자금 대출 받으려고 건물가격 확인 하는 거야~예랑: 네...신부: 우선 건물주 몇명인지 정보 볼래? 예랑: 그건 왜 보는거야? 신부: 하나의 건물이라도 소유주가 여러명일 수 있어서 이런 요소를 다 알아야 전세자금 대출을 제대로 받을 수 있어. 여기 상세 정보 있네. 아 건물 주인이 한명이네. 아...나도 건물주 하고 싶다신부: 지금 이 건물의 시세랑 소유주가 왜 중요하냐면, 만약에 이 건물 주인이 잘못되면 ~~~$%^&* ~~~먼저 빼주고 우리 보증금을 줄거란 말이야. 그래서 건물 실거래가 정보가 중요해.예랑: ......?신부: 그래...우선 이 실거래가 정보도 일단 내 카톡으로 공유해줘..익선동 맛집 추천 받습니다#부동산 인사이드예랑: 나 부동산 공부 좀 해야겠다...방금전에 설명해 준 내용 하나도 이해 못했어신부: 우선 뉴스 보면서 부동산 용어를 우선 익혀봐. 여기 부동산 인사이드 눌러봐바구독을 유도하기 위한 팝업창예랑: 오호...이 기사 좀 봐….전셋값은 하락하는데 집주인이 보증금을 안준데. 이 기사 한번 읽어볼까? 우리도 나중에 보증금 못받으면 어떡하지? 신부: 응 그 기사 클릭해봐. 오 여기 구독도 되네. 이거 구독신청하고 계속 봐 틈날때 읽어. 나중에 제대로 봤는지 안봤는지 검사한다. 예랑: Yes, Sir! 글을 읽으면서 눈치채신 분들도 계실지 모르겠으나 볼드체로 표시한 기능과 행동들은 우리 서비스에 고객들이 다시 방문하게 유도하거나(관심매물 등록, 구독하기), 다른 사람도 쉽게 서비스로 유입시키는 기능(공유하기), 그리고 사용자들이 서비스를 사용하며 기대하는 정보(로드뷰, 매물 종류, 실거래가 정보 등)들과 이로 인해 발생하는 행동들이다.관심매물 등록, 공유하기, 로드뷰, 구독하기와 같은 버튼들이 고객들이 의식적으로 찾지 않아도 쉽게 인지할 수 있는 위치에 있고 고객의 사용 과정에 자연스럽게 녹아있다면, 혹은 다른 정보들보다 한눈에 돋보이는 색상과 디자인을 가지고 있다면, 고객들이 더 오랜시간 서비스에 머무르며 중요한 기능을 사용 할 것이라 추측할 수 있다. 그렇지만 이 기능이 얼마나 유효한 기능인지, 어떻게 바꿔야 고객들의 편리를 더 증가시키는 유의미한 결과를 유도할 수 있는지는 변경하고 시도하기 전까진 아무도 모른다. 설상가상으로, 만든 사람이 중요하다고 생각하는 기능과 고객이 사용하는 기능이 일치하는지, 모바일과 웹 환경에서 사용자의 행동이 얼마나 다른지 수치적으로 확인하지 않는다면? 내가 의도한 기능을 왜 사용하지 않는지, 어떻게 행동을 변화시킬 수 있을지 고민하는 것이 애초에 불가능하지 않을까?그래서 이 글을 읽고 계시는 분들에게 감각에 기반해 의사결정을 내리기에 앞서, 나의 서비스는 제대로 측정하고 있는지 먼저 파악해 보시기를 추천드립니다.퍼포먼스 마케팅 에이전시, 오피노 바로가기부동산 투자의 시작과 끝, 부동산플래닛 바로가기

 전 회사의 이야기로 시작을 해볼까 합니다. 저의 전 직장 A사의 제품중에는 커다랗고 복잡한 기계 C가 있습니다. A사의 창업과 역사를 함께 할정도로 제품 C는 회사의 브랜드나 인지도에 있어서 정말 중요한 역할을 했습니다. 따라서 아주 잘 만들어야 했지요. 기계 제품 C를 담당하는 팀은 굉장히 많았는데 그 중에 가장 핵심적인 팀은 바로 설계팀입니다. 설계팀은 기계 구조의 모든 것을 담당하는 팀이죠. 그래서 그 만큼 책임도 무거웠고 업무량도 많았습니다. 퇴사를 일주일 앞두고 설계팀장 D와 이야기를 할 기회가 생겼습니다. 이런저런 이야기를 하다가 서로의 잘못한 점을 하나씩 토로하는 시간이 주어졌습니다. 우리는 여러가지 이야기들을 했는데 가장 논란이 되었던 이야기는 바로 제품 C에 대한 이야기였습니다. 그 당시 제품 C는 굉장히 문제가 많았습니다. 핵심 기능을 하는 부분이 자꾸 고장나서 고치러 나가야했고(해외에 나가있는 제품을 고칠때는 정말 힘들었습니다...) 그것이 자꾸 반복되다보니 일부 고객들은 제품 C의 사용을 거부하기까지 했습니다. 우리에게 문의도 하지않고 제품의 전원을 끄거나 심지어 창고에 넣어두기까지 했지요. 이렇게 까지 된 이유는 우리가 제품 C의 MVP를 지키지 못했기 때문입니다. 그럼에도 불구하고 D는 팀장으로서 이 문제의 심각성을 인지하지 못한 것 같았습니다. 왜냐하면 설계팀은 뻔히 이 문제를 알고있으면서도 그들의 초점을 새로운 기능의 개발에 맞추고 있었기 때문입니다. 그들은 제품의 MVP가 아닌 부가적인 기능을 개발하는데 90%의 노력을 쏟고 있었고 기존의 문제점을 해결하는데 10%의 노력을 투자하고 있었습니다. 위에서 언급한 문제 이외에도 수많은 문제들이 있었지만 저는 가장 문제가 되는 점들을 지적하며 D에게 설명을 요구했습니다. D는 새로운 기능을 개발하는 것도 굉장히 중요하다고 말했습니다. 이번 투자 라운드에서 투자자에게 신기능의 개발 능력을 보여주어야한다, 이번 기능을 개발하면 몇천대를 팔 수 있을지도 모른다라며 이유를 댔지요. 그 말을 듣고 저는 잠시 침묵을 지켰습니다. 그리고 역으로 질문을 던졌습니다.너희 팀의 목표는 무엇인가?팀장으로서 너의 목표는 무엇인가? D는 말했습니다. "우리팀의, 그리고 우리의 목표는 새로운 요구사항(requirement)을 처리하는 것이야" 저는 그에게 말했습니다. "그러면 너희 팀원들도 새로운 요구사항을 처리하기 위해 매일 출근하고 일하고 있겠네?" "맞아"라고 D가 대답했습니다. 저는 그 점이 틀렸다고 그에게 지적했습니다. 새로운 요구사항을 처리하는 것은 목표가 될 수 없다, 그리고 네가 팀장으로서 잘못된 목표를 설정하였기 때문에 제품에 문제가 생기는 것이라고요. D가 물었습니다. "그럼 어떤 것이 목표가 될 수 있는데?" 우리는 겁나게 쿨하고 예쁜 제품 C를 만든다 저는 이렇게 말했습니다. (물론 이후에 "우리는 겁나게 쿨한 제품 C를 만든다"라고 목표를 설정하지는 않았습니다...) "이것은 목표가 될 수 있지" D는 생각에 빠졌습니다. 저는 생각에 빠진 D에게 몇가지 부연설명을 했습니다.저번에 너희 팀원중에 한명이 엄청나게 못생긴 다음 라인업의 제품 C를 만든 일을 떠올려봐. 우리 회사 전직원들은 그 디자인을 보고 엄청나게 실망했지. 다음 라인업으로 내세울 제품이 그 모양이었으니까.왜 그랬을까? 그건 바로 네가 "우리는 요구사항을 처리한다"는 목표를 세웠기 때문이야. 너희 팀원은 요구사항을 처리하는 목표를 달성하다보니 예쁜 제품을 만들지 못한거지. 이렇듯 우리는 목표를 설정하지 않거나 잘못 설정하는 실수를 범하곤 합니다. 대부분의 사람들은 오랜기간동안 그걸 깨닫지도 못하지요. 저또한 지난 30년동안 그런 실수를 반복해왔고 아래에서 수많은 실수 중 2가지를 살펴볼까 합니다.나의 학창 시절(~고등학교) 저는 연세대학교에 들어가려고 공부를 했습니다. 왜 연세대였냐 하면 아무런 이유도 없습니다. 아참, 엄마가 연세대에 입학하면 차를 사준다고 하셔서 일까요? 저는 고등학교를 입학하면서부터 서울 4년제 대학을 가기위해 공부하도록 훈련받았습니다. 아무런 희망도 꿈도(목표) 없이요. 그저 부모님이, 학교 선생님이, 학원 선생님이 저라는 존재가 좋은 대학을 가기를 원하니까 나도 그렇게 해야겠다고 생각한 것 뿐입니다. 그렇게 고등학교 3학년이 되었고 저는 대학 입시에 올인을 하게 되었습니다. 고3이 되면 수능 모의고사를 수없이 보는데 저의 성적으로는 원하는(남들이 원하는) 연세대 공대에 가기가 굉장히 어려웠습니다. 그래서 학교 선생님과 부모님이 수시를 넣으라고 권유해서 그러기로 했습니다. 연세대, 한양대 등등 쟁쟁한 대학들을 넣었지만 모두 면접에서 떨어졌습니다. 어차피 수시에서 떨어져도 정시가 남아있으니 그리 걱정이 되진 않았습니다. 그러나 점점 수능이 가까워지면서 초조해지는 겁니다. 저는 초조함에 못이겨 홍익대 건축학과에 수시 원서를 넣었습니다. 저는 저의 내신 성적이 어느 정도인지 굉장히 잘 알고있었고 홍익대 건축학과라면 붙을 확률이 높을 거라고 생각했습니다. 며칠 후 홍익대에서 면접을 보러오라고 연락이 왔습니다. 저는 기쁜 마음에 부모님께 같이가자고 이야기했습니다. 저는 제 목표가 그럴듯한 서울 4년제 대학에 들어가는 것이었고 심지어 홍익대 건축학과는 5년제였고 엄청 유명했기 때문에 부모님이 기뻐하실 거라고 생각했습니다. 그런데 부모님은 가지말라고 하셨습니다. 저는 무척이나 실망했고 홍익대에서 몇번이나 오라고 연락이 왔지만 가지 못했습니다. 왜 가지말라고 하셨는지 아직도 정확한 이유를 모르겠습니다. 드디어 수능날이 되었습니다. 저는 열심히 시험을 치뤘고, 시험이 끝난 후 인파에 휩쓸려 집으로 향하는 버스에 몸을 실었습니다. 아직도 그 순간은 생생하게 기억이 납니다. 온 몸에 힘이 하나도 없는겁니다. 버스 손잡이를 잡고 있는건지 손잡이가 저를 잡고있는건지 헷갈릴 정도로요. 고3이라는 인간은 원래 수능이 끝나면 신나게 놀아야 정상인데 힘이 없어서 아무것도 못하고 침대에 누웠습니다. 그리고 머릿속에 떠오르는 단 하나의 생각.이 다음은 뭐지? 저에겐 다음이 없었습니다. 저의 인생은 끝이 난 것만 같았습니다. 그렇게 저의 안타까운 십대가 끝나버렸습니다. 2007년에 육군 현역에 입대하였습니다. 그리고 2009년 여름에 멀쩡히 전역하였지요. 예비군 모자를 쓰고 돌아오는 버스 안에서도 똑같은 생각을 했습니다.이 다음은 뭐지?나의 학창 시절(대학교) 대학교 1학년을 무사히 마치고 이제는 전공을 선택해야하는 시기가 왔습니다. 이 시기는 굉장히 중요한데, 우리 정보통신계열의 모든 학생들은 자신이 들은 교양과목을 토대로 자신의 전공과 진로를 결정합니다. 전공은 두가지가 있었는데 전자전기 공학과 컴퓨터 공학이 있었습니다. 저는 컴퓨터와 프로그래밍을 좋아했으므로 컴퓨터 공학을 선택하려고 했지만 선배들의 만류로 선택하지 못했습니다.야, 컴공(컴퓨터 공학)은 취업률이 낮아. 전자전기로 오는게 좋아 사실 만류라기 보단 뭔가 억지같기도 했습니다. 하지만 저도 병신같은게 컴퓨터 공학을 전공해서 나중에 뭘 할지도 모르겠고 전자전기 공학을 전공해서 뭘 할지도 모르겠으니까 그나마 취업률 높은 걸 택하자고 생각했습니다. 우리 학교 전자전기공학과는 그 당시 우리나라에서 최고의 취업률을 자랑하고 있었지만 저는 저의 선택이 맞는지 잘 몰랐습니다. 그러나 저와 생각이 별반 다를바 없던 선배들이 차례로 우리나라 최고(?)의 대기업에 취직하는 모습을 보면서 저도 목표가 생겼습니다.대기업을 가자 그 당시 굉장히 혼란스러웠는데 왜냐하면 좋아하지 않는 전공을 택해서 공부는 너무나 하기 싫었고 학교도 가기 싫었는데 이 길을 따라서 가면 성공할거란 생각이 들어서였습니다. 그렇지만 저 목표를 달성하고 나면 더 이상 혼란스럽지 않을거라는 생각이 머릿속을 지배하기 시작하면서 더 이상 생각하지 않기로 했습니다. 그리고 이런 생각들을 하기도 싫었지요. 그리고 3년 뒤...이 다음은 뭐지? 글의 처음에서 말한 D처럼 여러분도 하루하루의 요구사항을 해결하기위해 살고있진 않나요? 저와 똑같이 막다른 골목에 도달하셨다구요? 그런 여러분을 위해 좋은 글을 하나 소개할까 합니다. 목표를 구체화하는 가장 독보적인 방법이라는 홍용남님의 글인데요. 제목만큼 거창한 방법은 아닙니다. 모든 내용이 제가 추구하는 방향과 다 들어맞지는 않지만, 목표는 항상 큰 것부터 작은 것으로 설계되어야한다는 말은 깊이 공감하고 있습니다. 글만큼 거창하지는 않더라도 참고해서 여러분만의 목표를 설정할 수 있다면 방향을 잃지 않고 계속해서 앞으로 전진할 수 있을거라고 확신합니다. 목표를 설정하셨다면 그 목표를 잘 실행하는 방법도 중요하겠죠? 다음 포스팅을 참고하시면 도움이 되실겁니다. 구글이 직원들을 평가하는 방법(목표와 핵심결과 설정법)#비주얼캠프 #인사이트 #경험공유 #조언

사무실 확장이전, 신사업(블로코어) 시작, 새로운 멤버들의 합류 등 많은 일들이 있었던 2018년을 마무리하는 망년회가 지난 2018년 12월 27일 게임베리 아래 있는 카페 '언더더베리'에서 진행되었습니다. 2019년도 회식권을 걸고 4개의 팀이 치열한 팀대항 게임을 하였는데요, 대망의 회식권을 가져간 팀은 과연 누구일지, 망년회는 어떻게 진행되었는지 같이 살펴보실까요?파티 입장을 하며 팀별로 포토타임을 가졌습니다. 사진으로만 봐도 각 팀의 분위기를 알 수 있겠죠? :)<팀별 입장사진_언제나 활발한 블로코어, 언제나 웃긴 ㅋㅋ 글로벌디맨드, 웃음이 끊이질 않는 깔깔 서플라이, 수줍수줍 로컬디맨드 : 시계방향>특별한 날인 만큼 반가운 얼굴도 등장하였는데요~<든든, 정신적 지주, 평화, 게임베리 비둘기>바로 전 최고권력자!! 고은님의 깜짝방문이 있었습니다~ 같은 사무실에서 근무했던 로컬디맨드팀과의 호흡을 뽐내며 팀대항 게임에서 대활약!!특히, 역시나 오늘도 지각하신 한 분이 계십니다.<우리동네 지각대장, ROJUN, 인스타판넬 지분 20%, 호준님, 제발 정시출근 기원>입장 포토타임이 끝나고 대표님 3초 건배사를 시작으로 파티가 시작되었습니다! <갈 곳 잃은 주먹, 3초 건배사 달려보즈아><게임베리 미니 bar 메뉴판>순식간에 사라진 많은 음식들, 배고픈 멤버들을 위해 양꼬치 100개와 족발 보쌈을 손떨면서 추가주문한 경영지원팀 가볍게 식사를 마친 후 대망의 회식권이 걸린 팀별 게임이 벌어졌는데요 ~총 4개의 게임이 진행되었습니다! 미방출 사진과 동영상이 많은데 이미지 보호를 위해 참겠습니다 ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ만약 게임베리에 합류하셔서 제 자리로 오시면 몰래 모여드릴께요 <회식권이 걸린 팀대항 게임 : 승패의 희비가 엇갈리고 있음을 볼 수 있다.>모든 게임이 종료되고 시상식이 이어졌습니다 ~ 드디어 공개되는 결과!<미니게임_다람쥐 빌런을 잡아라!, 다람쥐 헌터 7인>개별 게임도 빠질 수 없죠^^ 망년회 시작부터 끝까지 여기저기 다람쥐빌런이 숨겨놓은 도토리를 찾는 미니게임도 같이 진행되었는데요! 숨은 보물을 찾아낸 7명의 헌터에게는 건조함을 이겨낼 수 있는 미니가습기와 당분을 보충할 수 있는 사탕이 주어졌습니다ㅎㅎ 밝은 미소(1)<재미를 위해 기획된 총 80만원 상당의 상품권 수령자들_사진에서 그들의 주체못할 끼쁨을 느낄 수 있다.>대표님도 깜짝 놀랐던 경영지원팀의 깜짝이벤트.. 봉투를 열지말았어야했다.ㅠ : 밝은미소....(2)회식권을 가져간 2018년 최고의 팀은 ~~!!!! 바로바로SUPPLY팀이었습니다~2등과 3등을 오가던 서플라이팀, 찬스권을 통해 1등 글로벌디맨드팀의 점수를 뺏어오면서 단숨에 상위권도약!우승으로 화룡점정! 위기의 순간 찬스권으로전세를 역전한 서플라이 수장 황금손 이혜민님마무리는 역시나 단체샷이 빠질 수 없죠~2018년 안녕~2019년도 화이팅!

다음 중 몇 개나 해당하시나요?1~5명 규모의 작은 개발팀에서 일한다.DevOps 조직이다.우여곡절 끝에 서비스는 런칭했지만, 개발과 동시에 운영을 해야하는 상황이다.서버 인프라 지식이 별로 없다.무중단 서비스 운영 경험이 별로 없다.팀 내에 시스템 엔지니어(SE)와 데이터베이스 전문가(DBA)가 없다.하나라도 해당한다면 이 글이 도움이 될 지도 모릅니다.누구나 쉽고 빠르게 앱을 만들고 서비스를 런칭할 수 있는 시대가 되었지만 문제는 런칭 이후입니다. 런칭 이후에는 고객이 100명이라도 안정적인(High Availability) 서비스를 운영해야 하는 것이 백엔드 개발자의 임무이기 때문입니다.안정적인 서비스를 운영하기 위해서는 체계적인 모니터링 필수라고 하는데 그마저도 쉽지 않습니다. 가장 큰 문제는 (장애가 터지기 전까지) 무엇을 모니터링 해야 하는지조차 모른다는 것이고, 당장 개발해야할 것들이 산더미처럼 쌓여있는데 사람도 부족한 것도 문제입니다.그렇지만 누군가는 해야하는 일입니다. 리디북스 역시 모니터링이 전혀 없던 시절이 있었으나, 크고 작은 실패와 좌절을 겪으며 조금씩 경험을 쌓아가고 있습니다. 이번 글에서는 우리가 모니터링과 관련하여 고민해 온 내용들을 소개해볼까 합니다.어떻게 모니터링할 것인가시스템의 안정성을 높이기 위해 투입해야 하는 노력은 지수적으로 증가합니다. 아래 표에서 보듯이 SLA 를 99.999% 에서 99.9999% 로 높이려고 한다면 1년에 약 5분의 가용시간을 얻을 뿐이지만 이를 위해 수백시간 이상의 노력을 들여야 합니다.가용성연간 장애 시간주간 장애 시간99.995%26.28 분30.24 초99.999%5.26 분6.05 초99.9999%0.525 분0.6048 초완벽함을 추구하면 할 수록 얻을 수 있는 고객 만족은 미미한 것에 비해 이를 위한 개발자의 노력은 기하급수적으로 증가합니다. 따라서, 먼저 대응의 적정선을 찾고 효율적으로 움직이기 위한 계획을 세워야 합니다.리디북스에서는 해야할 일을 4가지로 분류하여 중요한 일부터 처리하는 아이젠하워 매트릭스에서 그 대응 원칙을 차용하였는데, 그 이유는 시사하는 바가 동일하기 때문이었습니다. 즉, 중요한 것은 대부분 긴급하지 않고, 긴급한 것은 대체로 중요하지 않다는 점입니다. 그리고 매트릭스의 두 축은 아래와 같습니다.얼마나 급한가?사무실의 무선 인터넷이 안된다면 서비스에 큰 문제는 아니지만, 당장 해결해야 하는 급한 일입니다. 반대로 백업 스크립트가 며칠째 동작하지 않아서 최근 데이터의 스냅샷이 없다면, 이는 당장 해결할 필요는 없겠지만 매우 중요한 일입니다.그리고 장애란, 단순히 “고장”을 의미하는 것이 아니라 서비스 이용에 지장이 없더라도 어떤 수치나 결과가 예상과 다른 상황을 의미해야 합니다. 예를 들어, 웹서버의 평균 CPU 사용률이 70%가 넘는다거나 네트워크 대역폭을 90% 이상 사용하는 상황은 정상이 아닙니다. 조금만 트래픽이 몰려도 문제가 발생할 가능성이 매우 높기 때문에 잠재적인 장애로 간주해야 합니다.우리는 급한 문제를 우선적으로 처리하는 경향이 있어서, 덜 급하지만 더 중요한 일을 놓치는 경우가 많습니다. 이를 피하려면 장애의 그 심각도에 따라서도 구분해야 합니다.얼마나 심각한가?심각도를 처음부터 너무 상세하게 구분할 필요는 없으며, 크게 서비스 이용에 치명적인 것과 그렇지 않은 것으로 나누어 생각하면 됩니다. “치명적”의 의미는 서비스마다 다를 수 있지만 대개 아래에 해당합니다.사업에 지장을 초래한다.고객을 잃는다.만약 웹페이지의 로딩 속도가 매우 느려서 나쁜 이미지를 준다면 이 역시 치명적일 수 있습니다. 실제로 아마존에서는 로딩 속도가 100ms 지연될 때마다 눈에 띄는 매출 하락이 발생했다는 테스트 결과가 있습니다. 따라서 속도에 대한 매트릭을 모니터링 지표에 추가하는 것은 좋은 선택입니다.이상을 토대로 장애 종류에 따른 대응 원칙을 정리하면 아래와 같습니다. 급함안급함심각함➀ 즉각 대응, 즉각 인지➁ 평소 보완, 항상 경계안심각함➂ 빨리 대응, 최소 대응➃ 대응하지 않기이 중에서 항상 의식하고 놓치지 말아야 하는 것은 안급하지만 잠재적으로 심각한 장애(➁)입니다. 그리고 모니터링은 한 번 시작하게 되면 관리를 위한 비용이 꾸준히 투입되어야 하기 때문에 사소한 문제(➂, ➃)를 굳이 파헤치는 것은 오히려 독이 될 수도 있습니다.모니터링 측면에서 본다면 발생중인 장애는 최대한 빨리 발견하는 것이 중요하며, 잠재적인 장애는 상태의 변화를 최대한 빨리 감지하는 것이 중요합니다. 예를 들어, 디스크의 여유공간은 완전히 바닥나기 전까지 어떠한 경고도 나타나지 않지만 부족한 상황이 발생하면 어떤 부작용이 생길지 예측할 수 없습니다.필수 모니터링 갖추기모니터링을 해야할 대상은 기술 스택과 코드 구현에 따라 달라지겠지만, 빼놓을 수 없는 것들이 몇 가지 있습니다. 리디북스에서는 서버의 프로비저닝과 동시에 아래 내용들을 함께 준비하고 있습니다.1. 리소스 및 시스템 모니터링각종 시스템 리소스 및 하드웨어 상태는 필수 모니터링 대상입니다. 모니터링 툴을 설치해보면 측정해주는 항목들이 너무 많아서 당황스러운 경험을 하게 되는데요. 그 중에서도 우리가 주목하고 있는 항목들은 아래와 같습니다.CPU UsageLoad AverageDisk UsageDisk Utilization (iowait, IOPS)Swap Memory Usage (사용시)Temperature (인프라 직접 구축시)RAID Status (인프라 직접 구축시)S.M.A.R.T Errors (인프라 직접 구축시)이 중 몇가지는 New Relic 에서 무료로 지원하므로 당장 여력이 없다면 이를 이용하는 것도 좋은 방법입니다.클라우드 환경이 아닌 데이터센터에서 인프라를 직접 구축하여 운영하고 있다면 좀 더 많은 노력이 필요합니다. 하드웨어적인 장애를 직접 신경써야 하기 때문입니다. 실제로 팬(fan)이 고장나거나 케이블이 환풍구를 막아서 서버의 온도가 비정상적으로 높아지다가 기기가 오동작하는 어처구니없는 상황도 발생합니다.Disk서버 환경에서 SSD 사용이 점점 대세가 되어가고 있는데, 최근 구글이 공개한 정보에 따르면 SSD에서 배드블럭이 발생하는 일은 매우 흔하며, 시간이 오래될 수록 안정성이 떨어진다고 합니다.따라서 디스크와 관련된 RAID나 S.M.A.R.T 오류는 가능한 빨리 대응해야 합니다. 특히 RAID 장비를 구성할 때에는 같은 공정에서 출하된 같은 벤더의 제품을 일괄적으로 구매해서 사용하기 때문에, 동일한 하드웨어 결함을 지니고 있거나 평균 수명도 비슷하므로 결코 안이하게 대응해서는 안됩니다.리디북스에서는 전자책 원본을 보관하는 스토리지에서 4개의 사본(replica) 중 3개가 연달아 깨지는 끔찍한 사고를 경험한 이후로, 디스크 오류는 1순위로 대응하고 있습니다. 참고로 스토리지 서버를 구축한지 3년째가 되는 해였고, 모두 S사의 제품이었습니다.iowait 은 CPU가 유휴(idle) 상태로 I/O를 대기하는 시간을 나타낸 수치입니다. 이를 통해 현재 시스템이 I/O 병목을 겪고 있는지 판단할 수 있기 때문에 중요합니다. 이 수치가 너무 높다면 블록 디바이스나 네트워크가 너무 느린 상황이거나 포화 상태일 수 있으므로, 더 높은 IOPS 장비로 업그레이드하거나 부하를 분산해야 합니다.단, CPU 성능에 영향을 받는 수치이므로 고성능 CPU를 사용할수록 평균 iowait이 높게 측정됩니다. (따라서 성능을 평가하기 위한 지표로는 IOPS도 함께 분석해야 합니다.)Load AverageLoad Average(평균 부하)는 마치 서버의 종합 성적표 같아서, 이 역시 주목할 필요가 있습니다. Load Average에 변동이 생긴다면 평소와는 다른 처리량(throughput)을 내고 있다는 뜻입니다. 요청량이 증가하여 수치가 올라갔다면 서버 증설과 튜닝에 대비해야 하지만, 그렇지 않다면 어딘가 병목이 발생하여 처리 효율이 낮아졌다는 신호입니다.아직 Load Average를 모니터링하고 있지 않다면 주요 서버군부터 아래 규칙을 참고하여 초기 기준치를 설정하기를 권장합니다. 물론 어디까지나 초기 설정 값이며, 실제 상황에 적합하지 않을 수 있습니다.Warning Level : 0.7 * number of cores Critical Level : 1.0 * number of cores간혹 커널 자체에 문제가 있거나, 커널 모드에서 예외가 발생하는 경우에는 syslogd 데몬이 남기는 로그를 파악해야 합니다. Papertrail, Splunk, Loggly 등의 서비스는 크리티컬 수준 이상의 syslog 에 대해 알림을 설정할 수 있을 뿐 아니라, 텍스트 형태로 남겨지는 모든 로그에 대한 관리를 쉽게 도와줍니다. 비록 유료지만 커널 모니터링 용으로만 사용한다면 비용이 많이 들지 않습니다.2. 응용프로그램 모니터링앱이나 서버에서 발생하는 크래시와 예외를 수집하는 도구 역시 장애 예방에 필수입니다. 해당 기능을 실시간으로 제공하는 다양한 서비스들이 존재하는데 많이 쓰이는 것으로는 Sentry, Rollbar, Airbrake, NewRelic APM 등이 있습니다. 대부분 5분만에 설정이 가능한데다 어느것을 선택하더라도 핵심 기능에는 부족함이 없습니다.단, 현재까지 가성비로는 Sentry가 제일 뛰어납니다. Python의 Flask와 Jinja의 개발자로 유명한 Armin Ronacher가 팀에 합류했기에 발전가능성 측면에서도 많은 기대가 됩니다.Sentry의 실시간 에러 대시보드3. 데이터베이스 모니터링팀에 DBA가 있나요? 모든 서버 개발자들이 인덱스와 스토리지 엔진의 특징에 대해 잘 이해하고, DB를 능숙하게 다루나요? 그것도 아니라면 개발자들이 작성한 모든 스키마와 쿼리에 대한 검증 과정을 거치고 있나요? 만약 그렇지 않다면 슬로우쿼리 모니터링은 필수입니다.우리가 서비스 초기에 겪은 문제의 대부분은 인덱스를 잘 다루지 못하거나 새로 도입한 ORM에 대한 이해도가 낮아서 발생한 문제였습니다. 그 중에서도 특정 쿼리가 너무 많은 I/O를 유발하던 것이 주된 원인이었으며, 작고 가벼운 쿼리가 너무 많이 호출되어 문제가 된 경우는 거의 없었습니다.잘못 설계된 스키마나 쿼리는 평소에는 드러나지 않다가 사용자가 몰리기 시작하면 큰 부하를 발생시켜서 기어이 서비스를 마비시키곤 합니다. 문제가 커지기 전에 그 조짐을 감지할 수는 없을까, 고민 끝에 우리가 시도한 방법은 “2초 이상 수행되는 쿼리에 대해서 로그를 남기고, 초당 3개 이상 로그가 발생할 경우 알림”을 받도록 하는 것이었습니다.MySQL에서는 아래 설정으로 로그를 활성화시킬 수 있습니다.[mysqld] long_query_time=2 # 2초 이상 수행되는 쿼리에 대해서 slow_query_log=1 # 로그를 남겨주세요 쿼리 분석에는 Percona의 pt-query-digest 를 추천합니다. VividCortext 혹은 MONyog 등의 솔루션은 시각적으로 화려하고 실제로도 강력한 기능을 갖추고 있지만, 유료라는 큰 단점이 있습니다.모니터링을 통해 알림을 받게 되면 문제가 더 커지기 전에 해당 기능을 수정하거나 중단시킬 기회가 생깁니다. 특히 새롭게 추가한 기능을 배포할 때 서비스가 불안해 질 수 있는데, 퍼포먼스 문제를 미리 발견하고 롤백을 서두를 수 있다는 것도 장점입니다.물론 가장 이상적인 상황은 n초 이상 수행되는 쿼리를 모두 없애는 것입니다. 하지만 현실은 튜닝을 포기하고 테이블을 풀스캔하도록 두는게 나은 선택일 수 있으며, OLAP/ETL 인프라가 별도로 구축되어 있지 않은 상황에서는 어쩔 수 없이 슬로우쿼리가 발생하게 됩니다. 우리가 초당 로그 갯수로 판단을 하게된 것도 이러한 이유 때문이었습니다.자동으로 슬로우 쿼리를 받아보면 문제해결에 도움이 됩니다.4. 배치 작업(scheduled task) 모니터링매일 백업 스크립트를 돌리고는 있는데, 백업이 정상적으로 완료가 되었는지는 어떻게 판단하면 될까요? 에러는 위에서 설명한 도구들로 확인이 가능하겠지만 스크립트가 수행도중 멈춰버렸거나, 서버의 전원이 꺼졌다면? 게다가 크론 작업(crontab)이 수십개가 넘어가면 이를 수동으로 체크하는 것도 일이므로, 반드시 자동화해야 합니다.이러한 상황에서 활용할 수 있는 유용한 도구가 PushMon 입니다. PushMon은 정해진 시간에 ping을 보내지 않으면 이메일이나 SMS로 알림을 주는 서비스로, 원리는 매우 단순하나 없어서는 안될 기능을 “무료”로 제공합니다.모니터링에 대응하기모니터링을 효율적으로 하기 위한, 즉 서비스 안정성을 높이기 위한 핵심 원칙은 “필요한 인원이 필요한 알림만 받는것”입니다.알림이 너무 많이 와서 음소거(Mute)를 하고 싶은 생각이 든다면 모니터링 체계에 문제가 있다는 신호입니다. 불필요하게 많은 경고는 안전 불감증을 낳을 뿐더러 정작 중요한 경고를 놓칠 확률을 높이기 때문입니다. 치명적인 알림은 모든 채널로 즉각 수신하고, 경고성 알림은 메일로 수신하되 정기 리포트나 메일함 자동분류 기능을 이용하여 중요한 정보를 놓치지 않는 습관이 중요합니다.불필요하게 많은 인원이 알림을 받는 상황도 문제입니다. 알림 수신자를 늘리면 모니터링의 퀄리티가 높아질 것이라고 생각하지만 절대 그렇지 않습니다. 오히려 방관자 효과가 발생하여 아무도 알림에 대응하지 않는 상황이 발생하게 됩니다. 따라서 알림이 발생했을 때에는 1차, 2차 담당자를 사전에 지정하고 운영할 필요가 있습니다.방관자 효과의 적절한 예팀에서 Slack을 사용한다면 기능 연동을 통해 실시간으로 이슈를 파악할 수 있고, 담당자 지정을 보다 쉽고 명확하게 할 수 있습니다. 특히, 별것 아닌 이모티콘(emoji) 만으로도 방관자 효과를 크게 줄일 수 있는데, 예를 들면 아래와 같습니다.👀 - 확인중 ✅ - 확인 완료 😱 - 확인은 하였으나 나는 해결을 못하겠음Sentry를 Slack에 연동한 모습또한, 모니터링 시스템에 대한 모니터링도 중요합니다. SaaS를 이용하는 경우에는 최악의 경우 해당 서비스의 점검기간에 대비할 수 없으며, 심지어는 점검중이라는 사실 조차 인지하지 못할 수 있습니다. 이에 대비하기 위해 리디북스에서는 Server Density로 모니터링을 모니터링하고 있습니다.맺음말장애를 얼마나 꼼꼼하게 예방하는지, 그리고 얼마나 즉각적으로 반응하는지는 팀 구성원의 실력으로 정해지는것이 아니라 팀의 문화와 원칙에 따라 정해집니다. 아직 팀에 뚜렷한 대응 원칙이 없다면 먼저 상황에 맞는 기준과 척도를 결정하고 공유해볼 것을 추천합니다.무엇보다 DevOps를 수행하는 것은 사람임을 잊지 말아야 합니다. 인간은 99.99% 가용성이나 24/7 을 보장하지 못하며, Uptime은 하루도 되지 않습니다. 최근 DevOps가 대세가 되어가지만 Ops에서의 인간적인 측면은 진지하게 고려되지 않고 있습니다. 이러한 환경을 개선하기 위한 HumanOps에 대한 소개와 함께 글을 마칩니다.     HumanOps 계명시스템을 만들고 고치는 것은 인간이다.인간은 지치고 스트레스를 받으며, 행복과 슬픔을 느낀다.시스템은 아직 감정이 없다. 오로지 SLA만 있다.인간은 스위치 온/오프 상태를 반복해야 한다.시스템을 운영하는 인간의 행복이 시스템의 안정성에 영향을 준다.빈번한 알림 == 인간의 피로최대한 자동화하고, 최후의 수단으로 인간에게 이관하라.문서화하고, 훈련하고, 시간을 아껴라.창피 주지 마라.인간의 문제는 시스템의 문제다.인간의 건강은 사업의 건강에 영향을 준다.인간 > 시스템#리디북스 #개발 #DevOPS #모니터링 #인사이트 #서버개발 #운영 #꿀팁

[라이더소개 #15. '아름다운' 라이더, '자밀라']자밀라를 소개합니다! :)Q1. 자밀라, 어떻게 아띠인력거를 처음 시작하게 된거야?작년 아띠에서 열었던 욜로윈(Yoloween: YOLO + Halloween 아띠스타일의 할로윈파티) 파티에 온이 날 초대했는데 그때 이후로 시작하게 됐어. 그 전에도 아띠에 대해서 알고는 있었어~ 내가 그때 대학교에서 청강을 하는 수업 과제 주제로 ‘아띠인력거’나 ‘사직동 그 가게’로 하자는 의견이 있어서 아띠랑 그 가게에 둘 다 컨택을 하면서 IJ 인터뷰를 했었거든. 아띠에 대해 더 자세히 알게 됐고, 매력적이라고 느꼈지. 그래서 욜로윈 파티에 가는 것까지 이어진 거야. 모르는 사람들 만나는 낯선 자리였는데도 분위기도 정말 좋고, 아띠 애들도 너무 좋더라고~ 아띠인력거를 끄는 사람들을 처음 만났을 때 그 느낌 때문에 라이더에 도전하게 됐어.사실 그 전에 알고 있던 아띠는 그렇게 날 확! 끌어당기진 않았거든. 그런데 매력적이라고 생각이 들면 일단 해보라고 하더라고! 정말로 아띠의 진면목은 직접 해보지 않고서는 알 수 없는 것 같아.(웃음) 나도 아띠가 멋있다고 생각은 했지만, 그건 그냥 막연한 거였지, 진짜 마음으로 느끼지는 않았던 거야. 그런데 그 막연했던 것들이 구체적으로 변하게 된 계기는 IJ와 온을 통해서 아띠에 대해 계속 알아가고, 또 욜로인파티를 갔을 때 아띠 멤버들을 보고서 ‘와, 진짜 멋있다’라고 느낀 거였어. 그리고 직접 해보고 나니 더 매력적이었어.Q2. 첫 라이딩했을 때는 어땠어?아, 죽을 것 같았어.(웃음)힘들긴 되게 힘들더라구. 솔직히 말하면, 30분 코스는 할 수 있을 것 같은데1시간 라이딩하면1시간은 쉬어줘야 할 수 있을 것 같아.(웃음) 근데 나는 돈 때문에 시작한 게 아니었기 때문에 지금처럼 뉴비로 공짜로 태워드리든, R1이 되어서 돈을 받고 태우든 그건 나한테 그렇게 중요하진 않은 것 같아. 그냥 아띠 유니폼을 입거나,아띠인력거를 타고서 라이딩을 할 때 느낄 수 있는 그 자유로움이 있어. 왜 그런 거 있잖아.길을 가다가 아무 연고지도 없는데 옆 사람한테 말을 걸면 그건 이상한 사람이야!근데 아띠는 그 벽을 다 뛰어넘게 해줘.난 그게 되게 매력적이라고 느꼈어.아띠의 정체성에도 이게 포함되어있는 것 같아. 인력거를 타면 나이든 인종이든 제한 없이 길가는 사람한테 웃으면서 인사해도 ‘쟤 뭐야’ 이렇게 썩소를 날리지 않아.(웃음) 그런 게 되게 좋았어.사람과 사람 사이의 벽을 허물 수 있게 만들어주는 것 같아.인력거를 처음타고서 그런 느낌이 제일 좋았고,그래서 해보고 싶다는 생각이 계속 들었던 것 같아.Q3. 제일 기억에 남는 손님은 어떤 손님이이야?저번에 내가 업어줬던 남매! Q4. 아, 그 사진! 대체 왜 업었던거야?(웃음)한옥마을쪽으로 가는 길이 살짝 오르막길이잖아. 눈에 확 띄는 언덕보다 살짝, 길게 있는 오르막길이 더 힘들거든. 근데 다른 사람 눈에는 평지처럼 보이는 길이라 생색도 못내는 그런 오르막길.(웃음)아무튼 그때 그 오르막길을 오르면서 힘들게 겨우겨우 도착했는데, 남자 아이가 인력거를 더 타고 싶다고 너무 신이 나서 쌩쌩 날아다니는거야. 그래서 어떻게 할까 생각을 하다가, ‘우리 한옥마을까지 달리기 경주를 하자!’ 한거야. 이 아이들을 인력거에 태우고 달리는 것 보다, 달리기 경주하는 게 훨씬 수월하다고 생각이 들었던 거지! 그래서 신나게 달리기 경주를 하고나니까 그 아이가 이제 힘들다면서 못 걷겠다고 하더라고! 그래서 나한테 업어달라고 한거야. 그래서 업었지.(웃음)근데 업고나서 드는 생각은, ‘그래도 이 아이를 업는 게, 인력거 태우고 달리는 것 보다 가볍다!’였어(웃음)Q. 아이구~ 그 정도로 힘들었어?왜냐면, 일단 라이딩을 할 때는 다리만 쓰잖아. 근데 업고 걸을 때는 위쪽 몸을 써서 움직이니까 더 가볍게 느껴졌던 거야. 가볍다고 또 업고 뛰었어.(웃음)그렇게 잘 놀고 내려오는데, 갑자기 또 애가 쉬 마렵다고 바지를 아무대서 내리려고 하는 거야!(웃음) 한옥마을은 거주지잖아! 화장실 여기에는 없고 아래쪽에 식당이 있으니까 조금만 참아보라고 했는데도 못 참겠다고 그러더라고. 그래서 마침 한옥집 앞에 계신 아주머니한테 양해를 구해서 가까스로 화장실까지 찾아서 데리고 갔지.그런데 그 친구가 이번엔 자기가 인력거를 끌고 싶다고 하는거야. 그래서 끄는 건 안 되고, 사진 찍어 줄테니까 ‘끄는 척’하라고 하면서 안전장치 해놓고 사진도 찍어줬어.(웃음) 나중에는 그 아이 누나가 부모님 만나서는 동생이 이 언니 너무 괴롭혔다고 말하더라고. 걔라도 알아줘서 너무 고마웠어.(웃음)나도 남동생이 둘인데, 나도 어렸을 때 이랬겠구나 싶더라고. 남동생 케어하면서 주변에 피해주지 않으려는 누나가 짠하기도 하고. 여러모로 감회가 새로웠어. 워낙 말썽꾸러기였고, 최근이어서 그런지 가장 기억에 남아. 아무튼 좋았어. 아이러니하게도.Q5. 대단하다! 가장 힘들었을 때도 이때였겠네?응. 근데 또 있어.(웃음) 현아랑 초등학생 3명씩 태웠던 적이 있는데, 30분만 태우기로 했었는데 현아가 45분정도로 더 태워줬던 거야. 그때 4시까지 카페에 바톤터치하러 갔어야 됐는데, 거의 3시 50분까지 라이딩을 했던 것 같아. 애들은 빨리 달려달라고 하고, 카페에는 빨리 가야하고, 그래서 정신적으로, 육체적으로 힘들게 투어를 간신히 끝내고 미친 듯이 달려갔는데, 허벅지가 천근만근이더라고. 그 때 엄청 힘들었지.(웃음)초등학생 아이들 태웠을 때 제일 힘든 것 같아.내가 마치 말인 것처럼 애들이 나한테 체찍질하면서자꾸 빨리 달려달라고 하니까.(웃음)힘들긴 한데 그래도 나름 재미있어!Q6. 자밀라가 제일 좋아하는 길은 어디야?윤보선가에서 안국역까지 내려가는 길이 가장 좋아. 내리막길로 슝~ 내려가는 그 길! 그렇게 역까지 데려다주는 코스가 제일 좋아.(웃음) 코스라고 하기엔 좀 그런.. 그냥 길이지만. 외국에는 인력거를 이렇게 택시처럼 이용하는 경우가 되게 많아. 나한테는 매우 매력적인 길이야(웃음)Q7. 여자라서 힘든건 없었어?여자라서 그런 건 힘들지 않았어. 어차피 인력거를 타고 현장에 나가면 남자랑 가든 여자랑 가든 각자 따로따로 움직일 수밖에 없거든. 그래서 오히려 홀로 있는 데에 익숙해지고 뻘쭘해하지 않을 수 있어야 하는 것 같고, 여자건 남자건 그건 크게 중요치 않은 것 같아.유대감 같은 건 카페에 오거나, 점심을 같이 먹거나 뒷풀이할 때 생기는 것 같아. 인력거 끌면서도 친해질 수 있지만, ‘네가 힘들었던 그 코스를 나도 갔었다’라는 그런 공감대형성이라는 부분에서 오는 친밀함이 있는 것 같아.Q8. 자밀라 바쁘지만 라이딩 하고싶을 때는 언제든 나와!내 개인 스케쥴 상으로 마지막 순간, 그 ‘라스트 미닛’에 결정되는 일들이 많아서 미리 미리 사인업하는 게 조금 힘들더라구. 그렇다고 했다가 취소할 수는 없잖아. 갑자기 당일에 시간이 되는데 미리 사인업을 못해서 라이딩을 못할 때가 가끔 있었어. 그래서 드는 생각인데, '라스트 미닛'에도 참석할 수 있는 이벤트 같은 날이 있으면 좋을 것 같아! 그런데 그렇다고 기본적인 룰에 어긋나는 예외적인 상황을 만드는 건 안 좋은 것 같아. 이게 여러 번 쌓이다보면 장기적으로 봤을 때 아띠에게 좋지 않은 것 같아서 그런 부분은 최대한 내가 자제하려고 하지. 어쩌다 한 두 번은 괜찮을지 모르겠지만, 나도 사람인지라 그게 습관이 되면 무서운 거거든. 그런 예외가 한번 무뎌지는 순간이 와. 그래서 왠만하면 룰에 벗어나는 거는 안하고 싶은 거지. 난 아띠가 잘됐으면 좋겠어!(웃음) 그리고 오래가려면 기본에 충실해야하고, 조직화가 잘 되어있어야 돼. 그런데 어떤 조직이든지 그러다보면 딱딱해지거든. 아띠가 성장하는 만큼 아띠의 정체성을 잃지 않으려면 뭔가 끊임없는 반전이 한번 씩 필요한 것 같아! 그런 재미를 어떻게 만들어가느냐가 되게 중요한 Key가 될 것 같아.Q9. 마지막으로 아띠인력거 라이더에 관심이 있는 사람들에게 한마디 한다면? 주저하지 말고 해보고 싶다는 마음이 들었다면 도전해봤으면 좋겠어. 내가 봤을 때 아띠의 매력은 들어오지 않고는 느낄 수 없어! 그래서 겉으로 봤을 때 매력적이라고 느꼈으면 들어와서 직접 느껴봤으면 좋겠어. 그런데 누구에게나 아띠가 맞을 거라고 생각하지는 않아. 하지만 분명히 맞는 사람도 있어. 그러니까 들어와서 느껴보고 경험해봐! 일단 질러봐!(웃음)아띠인력거의 이웃사촌 & 아지트 '카사 자밀라'의 자밀라였습니다!언제나 열린마음으로 끊임없이 도전하는 자밀라를 응원하며 인터뷰를 마칩니다. :)#아띠라이더스클럽 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화 #사내문화

현대건설을 빛낼 슈퍼루키들이 등장했습니다!짧지만 알찼던 2주간의 입사 교육을 받으며 현대건설인이 되기 위해 만반의 준비를 다한 2019년 신입사원들. 열정과 패기 무엇 하나 빠지지 않는 신입들의 열정을 느껴보세요.현대건설 신입사원 인터뷰사회생활의 첫걸음을 뗀 현대건설 신입사원에게 현대건설은 어떤 의미인지 물어보았습니다. Q1. 현대건설은 내게 (      )이다.Q2. 현대건설에 입사해 가장 기대되고 이루고 싶은 것은?Q3. 첫 월급을 받으면 가장 먼저 하고 싶은 것은?공동욱 사원A1. 현대건설은 저에게 ‘평생의 반려자’ 입니다. 즐겁고 어려운 일을 함께하며 서로 배우고 성장하는 반려자처럼 현대건설과 평생을 함께하고 싶습니다.A2. 정년퇴직할 때까지 현대건설에서 일하고 싶습니다. 차근차근 경력을 쌓아가다 보면 회사의 미래와 방향을 정할 수 있는 중역의 위치까지 올라갈 수 있지 않을까요(웃음)?A3. 부모님의 선물을 직접 골라본 적이 없는데, 첫 월급으로 부모님께 좋은 선물을 사드리려고 합니다. 받고 기뻐하실 두분의 모습을 빨리 보고 싶어요.김경태 사원A1. 대학원에서 연구했던 분야를 업무로 계속 할 수 있게 해준 현대건설은 ‘기회’입니다. 현대건설이 제게 준 가능성을 헛되이 날리지 않기 위해 담당 분야 최고의 전문가로 거듭나겠습니다.A2. 건설 자동화 기술을 현장에 도움이 되도록 구현해 R&D의 중요성과 기술 혁신을 일으키고 싶습니다. A3. 첫 월급으로는 부모님께 용돈을 드리고 주식 계좌도 만들어 볼까 합니다. 세계 경제 흐름을 파악하면 현대건설에 필요한 기술과 미래 사업 영역도 가늠해 볼 수 있지 않을까요.김두현 사원A1. 저의 가능성을 알아봐준 현대건설은 ‘감사함’입니다. 입사통지서를 받았을 때 가족 모두가 함께 기쁨의 눈물을 흘렸던 순간이 생생합니다. 사회 구성원이 될 수 있는 기회를 준 현대건설은 저에게 정말 특별하고 소중합니다.A2. 회사에서 필요로 하는 인재로 거듭나고, 송·변전 분야에서 최고의 전문가가 될 수 있도록 커리어를 꾸준히 쌓아나가겠습니다.A3. 첫 월급의 기쁨은 가족들과 함께 나누려고 합니다. 힘들 때 옆에서 도움을 준 친구들에게도 맛있는 저녁을 사려고요.김소희 사원A1. 늦깎이 신입으로 입사한 현대건설은 저에게 ‘또 다른 시작’입니다. 레스토랑 창업, 디지털 광고 기획, 데이터 분석까지 남다른 이력을 가지고 현대건설 R&D센터에 입사하게 되었습니다.A2. 기존 컨설팅 회사와는 다르게 건설업에서는 어떤 대상과 자료를 분석할지 너무 기대되고 궁금합니다. 현대건설의 데이터 전문 분석가로 성장하겠습니다.A3. 월급은 계획을 세워 쓸 예정입니다. 엄마 용돈도 드리고 미래를 위해 다달이 100만 원씩 모으려고 합니다. 그동안 힘이 되어준 남자친구와 맛집 데이트도 할 예정입니다.박정재 사원A1. 저에게 있어 현대건설은 ‘인생의 전환점’입니다. 사회생활에 첫발을 내디딘 지금이 인생의 전환점이자 새로운 시작을 할 수 있는 시기라 생각합니다. 업무를 하며 스스로 정한 꿈과 목표를 달성하기 위해 끊임없이 도전하겠습니다.A2. 현장 근무를 통해 많은 경험을 쌓고 저의 손길이 닿아 완공되는 건축물들을 보며 보람을 느끼고 싶습니다.A3. 부모님과 할머니께 의미 있는 선물을 사드리고 싶습니다. 그리고 셀프 입사 축하 선물로 눈여겨 본 코트를 구매할까 고민 중입니다.손태희 사원A1. 저의 ‘제2의 인생’은 현대건설에서 막 시작됐습니다. 가장 입사하고 싶었던 현대건설의 입사통지서를 받았던 순간을 떠올리면 아직도 설렙니다.A2. 매일 배우고 성장하며 사람들에게 더 좋은 환경을 조성해 줄 수 있는 디벨로퍼가 되는 것이 제 최종 목표입니다. 빨리 현대건설 DNA를 체득해 업무 성과를 낼 수 있는 직원이 되겠습니다.A3. 첫 월급은 그동안 받은 부모님의 사랑에 작게나마 보답하는 마음으로 용돈을 드리려고 합니다.윤승욱 사원A1. 누구에게나 자신만의 드림카가 있고 한번은 꼭 타겠다는 꿈을 꿉니다. 토목공학인으로서 늘 현대건설 입사를 꿈꿔온 저에게 이 회사는 ‘드림카’입니다. 현대건설 드림카에 탑승했으니 주인 의식을 갖고 우리 회사가 발전하는데 기여하겠습니다.A2. 업무에 있어 가장 기대되는 부분은 지금까지 배운 지식을 현장에서 어떻게 활용할 수 있는지 직접 공사를 하며 확인해볼 수 있다는 점입니다.A3. 월급은 저를 키우시느라 고생하신 할머니와 부모님께 감사 선물을 드리려고 합니다. 곁에서 힘이 되어준 여자친구에게도 깜짝 선물을 준비하려고요.이양희 사원A1. 해외를 주무대로 일하고 싶었던 저에게 현대건설은 ‘Dreams Come True’입니다. 현대건설이 전 세계에서 프로젝트를 진행하며 주목받는 회사가 될 수 있도록 제 모든 역량을 다해 맡은 업무를 수행하겠습니다.A2. 입사 후 가장 기대되는 것도 대한민국 일등 건설사인 현대건설에서 책임감을 갖고 업무를 할 수 있게 된 부분입니다. 꼭 현장에 보탬이 되는 직원이 되겠습니다.A3. 첫 월급은 누구보다 현대건설 입사를 자랑스럽게 생각하시는 부모님께 드려 더욱 자랑스러운 딸이 되고 싶습니다.최시훈 사원A1. 건축공학을 전공해 현대건설이라는 대한민국 최고의 건설명가에 입사하게 된 것이 아직도 꿈만 같습니다. 오랫동안 건설 엔지니어를 꿈꿔온 저에게 현대건설은 ‘빛’과 같은 존재입니다.A2. 국내 건설업계의 정상에 있는 현대건설의 조직원이 되어 최상의 기술력을 지닌 선배님들께 직접 배울 수 있다는 점이 가장 기대됩니다. 하루가 다르게 성장해 최고의 건설 엔지니어가 되겠습니다.A3. 월급을 받으면 부모님을 모시고 소고기를 먹으러 가려 합니다. 서프라이즈로 준비한 용돈도 드리려고요.최호창 사원A1. 현대건설은 저에게 ‘새로운 출발’ 입니다. 사회 구성원으로서 첫발을 내딛는 곳이 바로 ‘현대건설’이기 때문입니다.A2. 데이터 분석을 공부하며 인생 처음으로 건설이라는 도메인을 접했습니다. 어떤 업무를 할지 마음이 설렙니다. 현대건설인이 갖춰야 할 아이덴티티를 체내화해 목표를 향해 질주하는 직원이 되겠습니다.A3. 첫 월급을 받으면 저만의 공간을 맘껏 꾸미고 싶습니다.원하는 디자인으로 인테리어를 하고 소품도 구매해 보기만 해도 편안한 힐링 공간으로 꾸미려 합니다.#현대 #현대그룹 #현대건설 #2019 #신입사원 #인터뷰 #건설회사 #건설회사취업 #사회생활 #HMG저널 #HMG_Journal #HMG #기업문화 #조직문화 #구성원인터뷰 #사내문화

여기까지 오신 여러분들께 수고 하셨다는 말씀을 먼저 드립니다. 우리는 지금까지 어트리뷰션 툴에 관한 모든 기본 지식을 다뤘으며, 이제는 툴을 이용해 가장 널리 사용하는 매체인 구글 애즈(Google Ads, Formerly Adwords)의 Universal App Campaign(이하 UAC)을 트래킹하기 위한 설정을 실습하려 합니다.이를 위해서는 구글 애즈 계정과 와이즈트래커 계정이 필요합니다. 두 계정 모두 무료로 생성할 수 있고, 특히 와이즈트래커는 1만 MAU까지 비용 없이 사용할 수 있습니다.아래 세 가지 단계를 진행하면 UAC 트래킹에 필요한 설정이 끝납니다.구글 애즈에서 Link ID 발급발급한 Link ID를 와이즈트래커에 입력구글 애즈에서 와이즈트래커와의 연결을 확인Link ID 발급Link ID는 구글 애즈와 어트리뷰션 툴을 연결하는 Key 역할을 합니다. Link ID가 없으면 구글의 데이터와 어트리뷰션 데이터가 연결되지 않기 때문에 반드시 Link ID를 가장 먼저 발급해야 합니다. Link ID를 발급하기 위해 아래 순서대로 진행합니다.구글 애즈에 로그인우측 상단 도구 메뉴에 있는 ‘설정’ -> ‘연결된 계정’을 차례로 선택타사 앱 분석을 찾아 ‘상세보기’를 클릭화면에 있는 ‘+’ 버튼을 눌러 Link ID 생성창을 활성화‘기타 공급업체’를 선택하고, 공급업체 ID에 와이즈트래커를 가리키는 1876468054를 입력플랫폼, 그리고 광고 대상인 앱을 선택위 과정을 따라 생성한 Link ID의 공급자가 아래 그림처럼 ‘WiseTracker’로 나오면 정상입니다. 이 Link ID는 가능한 한 빨리 와이즈트래커에 입력해야 합니다. Link ID를 복사해서 텍스트 파일 형태로 저장해 놓고 다음 단계로 이동하는 것을 추천합니다.Link ID를 와이즈트래커에 입력구글을 통한 광고성과를 트래킹 하기 위해 구글에서 발급한 Link ID를 와이즈트래커에 입력해야 합니다. 이 Link ID가 와이즈트래커에 입력됨으로써, 구글과 와이즈트래커는 공통된 Key를 기준으로 데이터를 통신할 수 있게 됩니다. 결과적으로 구글을 통한 광고성과를 확인할 수 있게 되는 것이지요. 와이즈트래커에 Link ID를 입력하기 위해서는 1) 와이즈트래커에 구글 UAC 채널을 생성하고, 2) 해당 UAC 채널에 Link ID를 등록하면 됩니다.와이즈트래커에 UAC 채널을 생성하기 위해서 다음과 같이 진행합니다.좌측 메뉴에서 ‘마케팅’ -> ‘광고채널 분석설정’을 클릭우측 가장자리에 있는 ‘광고 채널 설정’ 버튼을 클릭상단의 ‘광고 채널 등록’ 버튼을 클릭하여 광고 채널 생성창을 활성화아래 글과 이미지를 참고해 세부 설정을 입력하고 하단의 ‘저장’ 버튼을 클릭– 광고 채널: 잘 알아볼 수 있는 관리용 이름 입력 (ex. ‘UAC’ 또는 ‘Google UAC’ 등)– 채널 타입: Conversion Data Partner 필수 선택– 클릭 후 인스톨 / 인스톨 후 전환 기간: 마케팅 목적에 맞는 기여기간(Lookback Windows) 입력– 광고추적코드/패스워드: 입력하지 않음– Postback 설정: Universal App Campaign(Google) 필수 선택– Abusing 적용기간: 0일 선택– 제휴사 분석여부: 미사용 선택위 단계까지 잘 마무리 했다면 이제 와이즈트래커에 Link ID를 입력해 UAC 트래킹을 할 수 있게 됩니다. 아래 그림과 설명을 참고해 Link ID를 입력하고 설정을 마무리 합니다.좌측 메뉴에서 ‘마케팅’ -> ‘광고채널 분석설정’을 클릭우측 상단의 ‘광고 등록’ 버튼을 클릭하여 트래킹 URL 생성창을 활성화광고 채널에서 앞서 생성한 UAC를 선택광고 캠페인을 건너뛰고, 바로 아래쪽에 있는 Postback 사용여부에서 ‘Link ID 사용’을 선택하고 저장 버튼을 클릭생성한 URL의 수정 버튼을 클릭구글 애즈에서 Link ID를 만들 때 선택했던 플랫폼을 와이즈트래커에도 동일하게 선택한 후, 발급 받은 Link ID를 붙여넣고 ‘Link ID 이벤트 저장’ 버튼을 클릭Link ID가 입력된 것을 확인하고 저장 버튼을 클릭위 설정까지 마무리 하면 구글과 와이즈트래커가 Link ID를 기준으로 데이터를 통신할 수 있게 되는데요, 앱에 와이즈트래커 SDK가 삽입되어 있다면 구글 광고를 트래킹 하는데 전혀 문제가 없습니다. 그러나 아직 와이즈트래커 SDK를 앱에 삽입하지 않았다면 Link ID를 입력했다고 하더라도 아무런 데이터를 얻을 수 없습니다. Link ID는 구글과 와이즈트래커가 데이터를 주고 받는 방식에 대한 설정일 뿐이고, 실제로 주고 받아야할 데이터는 분석 SDK가 트래킹한 데이터이기 때문입니다.결과적으로 앱에 와이즈트래커 SDK를 삽입하지 않았다면, 앱 안에서 아무런 데이터를 수집하지 못하므로 구글과 통신할 수 있는 데이터도 없는 것입니다. 분석 SDK를 앱에 삽입하는 방법을 참고하여 이번 기회에 와이즈트래커를 사용해 보시길 바랍니다.구글 애즈에서 와이즈트래커 연결 확인* 본 단계를 진행하기 위해서는 반드시 앱에 분석 SDK가 삽입되어 있어야 합니다.UAC 트래킹을 위한 마지막 단계입니다. 와이즈트래커에 Link ID를 입력한 후 20분 ~ 30분이 경과한 시점에 이 마지막 설정을 끝낼 수 있습니다. 이 30여분의 시간 동안 구글과 와이즈트래커는 앱 내에서 측정할 수 있는 전환 액션의 종류가 무엇인지를 통신합니다. 앱에 와이즈트래커의 전환 측정 API가 많이 설정되어 있을수록, UAC를 통해 발생하는 다양한 전환 액션을 더 세밀하게 트래킹 할 수 있습니다.상단의 도구 아이콘을 클릭한 후 ‘측정’ -> ‘전환’을 선택‘+’ 버튼을 클릭하여 나타난 메뉴에서 ‘앱’ -> ‘타사 앱 분석’을 선택하고 계속 버튼을 클릭‘타사 앱 분석’을 선택하게 되면 Link ID를 통해서 연동된 어트리뷰션 툴이 앱에서 트래킹한 주요 전환 액션들의 목록이 나타납니다. 와이즈트래커와 Link ID로 연동 하였으므로 와이즈트래커를 통해 트래킹 할 수 있는 전환 액션들이 나타나면 정상입니다. 선택 가능한 모든 전환 액션들을 체크하여 ‘가져오기 및 계속’ 버튼을 클릭해 설정을 마무리 합니다. 참고로 와이즈트래커는 구글과 앱 설치, 앱 실행, 상품 조회, 장바구니 담기, 상품 구매, 그리고 기타 커스텀 이벤트에 대해서 연동 되어 있습니다.UAC 광고를 어트리뷰션 하면 위의 예시와 같은 데이터를 만나 볼 수 있게 됩니다. 룩백윈도우 기간 동안 UAC 광고로 인해 발생한 앱 설치부터 회원가입, 상품 조회, 주문 등을 측정할 수 있습니다.UAC 성과 최적화에는 어트리뷰션 툴의 역할이 상당히 중요합니다. UAC는 머신 러닝을 활용해 스스로 광고를 최적화 하는데, 이 머신 러닝에 공급되는 데이터에는 어트리뷰션 툴이 측정한 데이터가 주로 사용되기 때문입니다. 이렇게 공급되는 데이터의 양이 많고 질이 높을수록 최적화의 수준 역시 향상되므로 UAC와 다양한 데이터가 연동된 어트리뷰션 툴을 선택하는 것이 유리합니다.

"탈덕!! 호떡 사 줄게요!"해맑고 장난스러운 목소리가 사무실에 울려 퍼진다.주인공은 데이블의 잉끼 CTO 김성민. (그의 팬이 지어준 별명)데이블의 인기남답게 그의 모든 말은 고유명사가 된다."잉끼 CTO 패밀리"는 데이블 김성민의 팬클럽 이름이다.퇴근시간만 되면 그와 함께 퇴근하려는 팬들로 입구가 마비될 지경이다.어떻게 하여 그는 이렇게 열성적인 팬들을 모을 수 있었을까?그의 일상을 관찰하며 인기 비결을 분석해 보았다.| 그는 다가가기 쉬운 사람외모를 말하는 것이 아니다. 그를 만나면 안다.가만히 있어도 풍기는 아빠같은 편안함(귀여움)은 어쩔 수가 없다. (실제로 한 가정의 아버지)보통 그의 연세가 되면 나이 운운하며 꼰대질(?)하거나 어른인 척 하기 마련인데 그렇지 않다.그래서 다가가기 쉽다!어떤 질문이나 발언에도 친절하고 자세한, 질문자가 원하던 답변을 해준다.한 데이블러는 퇴근시간마다 질문을 하기 위해 성민님을 기다린다.그런 데이블러들을 위해 몰래 간식을 사주시기도 한다 ㅠㅠ(심쿵)그를 따라다니면 떡밥이 떨어진다는 소문이...성민님은 뇌섹남by 소희님| 그는 능력과 상반되는 겸손함을 지녔다그는 가히 데이블의 가정선생님이라 할 만하다.개발 인턴 창수님 자리에 찾아와 몇시간이 걸리든 최대한으로 설명을 해 주신다. (내가 매일 보고있음)개발자들 보고있나? 부러우면 개발자 지원 클릭.개발뿐만이 아니다. 회사와 관련된 모든 것이 그를 툭치면 툭 나온다.이쯤되면 거만하실 법도 한데, 말투와 행동에서 겸손함이 묻어나오는게 놀랍다!| 그는 유머러스하다업무적인 말만 하면 절대 친해질 수 없었겠지. 연륜에 어울리는 다양한 이야깃거리를 가지고있다.그리고 침묵이 오는 순간 풀어놓는다. 전혀 지루하지 않다는 게 신기할 정도.적절한 타임에 꺼내는 흥미로운 이야기는 사람들을 자석처럼 끄는 것 같다.거기다 유머감각까지 있다. 빵빵 터지는 것은 아니지만, 더 갖기 어렵다는 잔잔한 유머가...편하고 능력 있고 겸손하고 유머러스까지!이렇게 완벽한 성민님을 만나고 싶다면 데이블의 문을 두드려보라.인기남, 인기녀의 조건 정리- 편하고 친절해서 다가가기 쉽다- 일 잘하고 겸손하다- 유머감각이 있다#데이블 #CTO #팀워크 #팀문화 #스타트업 #스타트업문화 #스타트업CTO

함께 일하고싶은 좋은 동료들을 찾았다. 그리고 함께 일하게 되었다!_그동안 나를 파헤쳤던 시간들의 의미있는 결실이다. 나한텐 취업 정도의 의미가 아니다. 너무 이상적이라는 말을 들었던 내 방식이 틀리지 않았다는 걸 증명해낸 셈이다._갑과 을의 수직적인 구조에서 고용 당하는 게 아니라, 인간 대 인간의 수평적인 관계에서 합류하는 것._스스로 만든 질문으로 나라는 사람을 자유롭게 소개하고, 포트폴리오로 나의 경험과 역량을 보이고, 캐주얼하게 미팅을 하며 서로의 핏이 맞는지 맞춰보는 것_때로는 나 스스로도 너무 이상적인거 아니야? 라고 의심했다. 아니! 그래도 나랑 비슷한 생각하는 사람들 있을거야. 이번 년도까진 다 해볼거야 라고 생각하며 찾아다니고 있었는데 생각보다 빨리 이런 생각을 가진 분들과 함께하게 되었다._고통스럽고 무서워 포기할까 생각했던 순간을 생각하니 울컥한다. 내 신념을 지키며 일을 시작할 수 있게 되어 진심으로 기쁘고 세상에 감사하다.

일하다가 중간에 멈추고 쓰는 글입니다. 손목이 시큰거려가꼬 도저히 1400번째 레이어를 만들수가 없었거든요. 가끔 이런 생각이 듭니다. 아니 세상이 이렇게나 좋아져서 지금 자동차가 날라다니고 우주엘리베이터가 만들어지는 시대에 도대체 우리 어도비 사람들은 왜 자동 레이어 정렬 따윌 만들 생각을 못하는 건지 (안하는 건지) 막 답답하고 애꿎은 마우스를 바꿔봐도 결국 내가 내 손가락으로 레이어를 눌러야 한단 사실은 변함이 없고 스크롤이 부드러워져도 어차피 알트키는 눌러야하고...말입니다.아놔.... 디자이너에 대한 개념은 많이 변해왔습니다. 디자이너는 웹용으로 이미지를 저장하고 가우시안 필터만 주는 기능사가 아닙니다. 디자인이란 단어 자체가 기획과 프로세스 전반과 동의어가 되기도 했고, 일종의 사고방식이나 비즈니스를 다루는 프레임으로 여겨지는 만큼 디자이너는 논리적인 이미지를 통해 정보를 시각화하고 철학을 실체화하는 존재가 되어가고 있습니다. 이것은 분명 팩트예요.  하지만 그런 멋진 말들 뒤에는 여전히 손목터널증후군이 자리하고 있습니다. 여전히 디자이너의 최대위협은 프로그램이 응답하지 않는 것이죠. 그 멋진 철학과 정체성을 그려내는 것은 결국 검지와 중지손가락입니다. 클릭과 스크롤, 커서이동 딸깍딸깍으로 만드는 거죠. 손그림이나 생각만 하면 자연스럽게 그려지는 마법같은 호그와트 비밀병기가 있었으면 하는 생각이 듭니다. 툴을 다루고 몸으로 일하는 디자이너에겐 여전히 필요한 것들이 넘치는 것 같아요.그래서 문득 생각해봤습니다. 뭔가 이런거 있으면 내 두 눈과 손목이 조금은 편해지지 않을까 싶은 것들 말이죠. 물론 사심 가득하고 쓸데없고 병맛스러운 것들이 잔뜩이니 그냥 웃자는 느낌으로 읽어주시면 감사하겠습니다.1. 정렬선 좀 한 번에 지워줘.저 퍼런것좀..포토샵은 왜 정렬선을 일일이 하나씩 밀어 없애야 하는 건지 미쳐벌임. 내가 툴을 못다루는 건가요...혹시 누가 방법 좀 알고있으면 알려주세요. 컨트롤+; 이걸로 안보이게 만드는거 말고. 그리드 관련 확장프로그램에서 all clear 하는 거 말고.. 다른 방법은 없나요.2. 한국사진이 필요하다고. 흑인말고.뭔가...외국계기업같고 그러긴 하지만...언스플래쉬같은 게티이미지 이런 곳에도 물론 좋은 사진은 넘쳐납니다만... 가끔 제안서나 회사소개서 만들다보면 한국사진이 필요할 때가 겁나 많아요. 흑인이 일하는 거 말고 제발 적어도 중국인이나 일본인 스러운 느낌이라도 있어도 좋으니 얼추 위화감안드는 사진을 찾아 헤맬 때가 많더라구요. 도시 이미지도 맨하탄이랑 베이징말고. 여의도였음 좋겠다구....강변북로 나오라고 제발.그나마 디자인에 쓸만한 사진들은 얼라우투(http://www.allowto.com) 랑 클립아트코리아가 전부인데....얼라우투는 지금 힘들다고 유료로 전환 계획중이라고 합니다.ㅠㅠ...아놔.... 3. 예쁜 명조나눔명조와 조선일보명조, 정조체를 제외하고 뭔가... 예쁜 명조체 찾기가 꽤나 어렵더라구요. 고딕체는 이제 HG꼬딕씨가 우주를 지배해버린 터라 거의 넘사벽이 되어버렸는데 명조체는 사실 본명조를 뛰어넘기 쉽지 않은 것 같기도 하고. 엄청나게 예쁜 역대급 명조체가 있다면 좋을 것 같아요. 여러분들이 쓰고계신 명조체 중에 와씨 이건 진정 훈민정음의 정신을 이어받아 겨레의 얼이 녹아있는 아트적 명조다!!! 싶은게 있다면 소개해주세요.4. 컴터요. 컴터 하앍!!붕붕붕!!!!Xeon 플래티넘까진 바라지 않을께요. i9-7980에 2TB SSD, GTX1080ti, 64기가램 셋팅해주시고 파워서플라이가 막 엄청나고..근데 트랙패드는 있었으면 좋겠고... 기왕이면 겁내 큰 4K모니터....그런데 가볍고.. 그게 노트북이면 더 좋..-그런 거 없음-5. 흰 턱수염을 쓰다듬을 것 같은 팀장님네 녀석의 시안엔 '한'이 없다아아!좋은 피드백과 제대로 된 인간의 언어로 디렉션을 전달해 줄 팀장님 내지는 사수가 필요하죠. 요즘들어 더 느끼고 있는 생각인데, 사수가 있었으면 좋겠다는 생각이 들더라구요. 개인사업 4년차인데... 하면 할수록 더 모르겠고, 이게 맞는 건지 확신이 서지 않을 때가 더 많아요. 제 디자인에 대해 점점 의심의 눈초리를 품게되죠. 심지어 공부해오고 배워왔던 것들에 대해서도 다시 생각해보게 되는 게 또 현장의 현실이니까요. 늘 이론은 그저 기준에 불과하고 현실에선 타협과 조율만이 살 길인지.... 아니면 현실에 필요한 이론이 따로 있는건지 등등.. 여러가지 생각이 많아지는 요즘입니다. 가끔은 상사가 있었으면 하는 바람입니다. 아니면 교수님이라도...6. 시대가 어느 땐데 아직도 레이어가 챡챡...응?좀 지가 알아서 챡챡 정리되면 얼마나 좋을까... 그래 뭐 그런거까진 아니더라도, 적어도 무한 스크롤 방식말고, 그룹별로 횡으로 정렬이 되거나... 뭔가 한 번에 볼 수 있음 좋겠다는 생각입니다.7. 체력거대빨간물약 같은거 필요함. (일반 구급상자로 안됨)8. 사진보정이 샥! 챡! 응 그런거 없어.. 그런데 있었으면 좋겠는.9. 포토샵도 대지 밖에서 편집좀..사실 포토샵은 디자인용이 아니라 사진편집용 프로그램인지라 단일화면에서 편집할 수 밖에 없는 태생적 한계가 있습니다. 이해해요. 그래도...그 가상캔버스를 만들던가, 아니면 확장프로그램을 설치해도 좋으니 일러처럼 대지 밖에서 편집해서 가져올 수 있게 뭔가 방법이 있다면 한결 다양한 것들을 쉽게 할 수 있겠다는 생각이 들더라구요.10. 손가락만 움직여도 1,500kcal 막 이런거였음 좋겠다. 가만히 앉아서좌클릭할 때마다 20kcal, 스크롤2번에 30kcal, 새끼손가락을 컨트롤에 올리고 j를 누를 때마다 50kcal 씩 쭉쭉 소모되는. 창의적인 이미지를 고민하고 머리를 쥐어짤 때마다 지방(특히 내장지방)이 연소되는 몸이었으면 좋겠다. 김치찌개 먹고 다시 앉아서 가만히 일하다가 소화안되서 막 부대끼고 뱃살만 성장하는 그런거 말고.11. 협업툴인데 타블렛으로 그릴 수 있는...사실 이미지를 줬는데 피드백이 텍스트로 오는 건 쓰는 사람도 읽는 사람도 힘든 일이 아닐 수 없어요. 그냥 동그라미를 치면 될 일을 굳이 '좌측 상단에 작은 글씨로 쓰여진 부분' 이라고 길게 써야 하니까 말이죠. 그냥 보낸 시안에 실시간으로 쓱쓱 그려서 피드백하고 체킹할 수 있는 그런 캔버스형 협업툴 있으면 좋겠다요.12. 바다누가 우리 집 창문 앞에 바다 좀 만들어줬으면. 출렁이는 파도소리, 빛나는 은빛물결, 드넓은 수평선을 바라보며 포토샵을 켠다면...........(놀고싶지 않을까?)13. 고장안나는 외장하드새벽 두시.자니?...외장하드야. 미디어를 안전하게 제거하지 못하고 급한 성격에 몇 번 뽑았어.... 하지만 그렇다고 그렇게까지 맴을 찢는 날카로운 소리를 내며 두 번 다시 움직이지 않을 이윤 없었잖아.... 미안해 다시 돌아와줬음 좋겠어.. 그동안 수리기사님과 복원센터도 찾아가면서 많이 반성했어. 다시 돌아와준다면 항상 안전하게 널 제거해줄께.. 떨어뜨리지도 않고 항상 추가전원선에 연결해서 빵빵한 에너지를 줄 거라고 약속할꺼야. 그러니 내 파일들 다시 내놔 (이 자식아....)14. 12시간 간대매.내가 분명 올데이 뉴그램을 산 것 같은데 왜 올데이 아닌데. 15. 툴신되고싶다...그냥 누가 내 머리 열고 조그마한 어도비 프로그램 메뉴얼 다 들어가 있는 D형램 하나 전두엽에 꽂아줬으면 좋겠다. 유튜브 찾아보면서 하나하나 스페이스바로 멈춰가며 따라하는 것도 손가락 아프고...16. 컬러매칭 사륜안디자이너라고 모두 컬러를 다 잘 만지는 건 아니더라구요. 특히 제가 그래요. 컬러조합을 챡챡 해줄 수 있는 뭔가 그런거 있으면 좋겠더라구요. 물론 어도비쿨러도 있고, 구글에 color combination 치면 많이 나오기도 하지만, 내가 원하는 건 지금 내 작업과 가장 잘 매칭되는 컬러구성이니까....더불어서 행사장 조명이나 거리, 환경 같은거 입력해주면 대비, 가시성, 혼합정도 등등도 파악해 줄 수 있는 그런거 있으면 은총앤성은17. 오탈자필터 백안그 운명은 발주 후 오탈자발견!음... 왜 인쇄소에 보내고 난 후엔 항상..오탈자가....18. 죄다 무선이었음 좋겠다아아아아.아..일단 컴퓨터가 없어야 하는구나책상에 선이 하나도 없었으면 좋겠다아아아아아... 그래서 사실 아이맥을 살까싶기도 했는데, 사실 딱히 아이맥이 디자인에 엄청 좋다거나 이런걸 잘 못느끼겠어서 사실 이것저것 겸용으로 쓰려고 데탑을 쓰고 있지요. 하지만 아이맥뽐뿌가 자꾸 올라오는 건 다른 거 아무것도 없이 그놈의 트랙패드와 전원선 하나밖에 없는 초 심플함 때문이 아닐까 싶습니다. 안그래도 우린 책상에 커피, 홈런볼, 포스트잇, 업무일지, 피드백받은거, 현미녹차 같은것도 잔뜩 올려놔야 하잖아요...19. 밤이었음...내가 일하는 그 순간 갑자기 밤이었음 좋겠어요. 아니면 새벽감성 주사 또는 드링크같은게 있으면 좋겠어. 마시는 순간 새벽감성에 젖어버리는 거지....20. 일관성있는 눈...오늘 만든 거 내일봐도 예뻐 보일 수 있는 눈 삽니다.