그동안 3대장 시리즈를 통해 수많은 서비스들을 소개해 드렸습니다. 창업 보육기관과 엑셀러레이터를 소개해드리기도 했고 스타트업을 주로 다루는 미디어들을 소개해드리기도 했지요. 이번에는 조금 더 특별한 서비스를 소개해드리려고 합니다."혹시 기부하고 계신가요?"2016년 '아름다운 재단' 산하 '기부문화연구소'의 발표에 의하면 2015년 대한민국 국민 중 기부를 하는 사람의 비율은 45.6%로 지난 2013년 조사 때 나왔던 48.5%보다 2.9%가량 낮아졌으며 2005년 조사에는 68.6%였으니 10년 사이에 무려 23%가 낮아진 겁니다.[출처] 기부문화연구소그렇다면 기부를 하지 않는 이유는 무엇일까요? 해당 연구소에서 발표한 자료에 따르면 가장 큰 이유는 경제적인 이유였습니다. 그다음으로 기부단체를 믿지 못한다는 답변과 기부에 관심이 없거나, 기부 방법을 알지 못해서라는 답변이 가장 많았습니다.[출처] 기부문화연구소그렇다면 이 문제를 해결할 수 있는 방법이 무엇일까요? 경제적인 어려움 없어도 기부를 할 수 있고, 신뢰를 얻을 수 있고, 기부에 관심을 유도할 수 있으며, 기부를 쉽게 접할 수 있게 할 방법. 이런 문제들을 해결하기 위해 나온 서비스가 있습니다.1. 네이버 해피빈2005년 7월에 시작된 해피빈은 네이버에서 운영하고 있는 기부 플랫폼입니다. 국내 최초의 공익 플랫폼이라고 자신들을 설명하고 있죠. 초기의 해피빈은 자사의 서비스를 이용하는 유저들에게 콩을 나눠주며 그 콩을 통해 기부를 쉽게 할 수 있도록 만들어졌습니다. 이후 미투데이 같은 서비스에도 도입하며 점점 더 큰 규모로 성장을 했죠. 현재는 자사의 서비스에서 받을 수 있는 방법들은 거의 사라졌고 해피빈 내에서 활동을 하면 받을 수 있는 해피에너지 스탬프를 통해 콩을 충전할 수 있습니다.2017년 현재 해피빈2017년 현재의 해피빈은 다양한 프로젝트를 할 수 있습니다. 나눔기부를 통해 도움이 필요하신 분들이 모금을 할 수 있으며 공감펀딩을 통해서는 일종의 리워드형 크라우드펀딩을 하고 있습니다. 정기저금은 기부를 위해 적금처럼 정기적으로 계좌이체를 통해 기부금을 모아두는 일종의 기부 저금통입니다. 마지막으로 캠페인은 해피빈의 파트너들과 참여형 봉사활동이나 제품 판매와 같은 다양한 형태의 프로젝트를 모아두었습니다.2005년 시작된 해피빈은 2017년 현재 누적 기부액이 674억에 달하며 누적 사용자는 1300만 명이 넘습니다. 우리나라 국민이 5천만 명이라고 보면 4명 중 한 명은 해피빈을 통해 기부를 해 본 적이 있다는 말이니 정말 대단하죠.그런 해피빈이지만 과거에 비하면 기부를 하는 방법이 어려워진 느낌이 있습니다. 콩은 한 개 당 100원의 가치를 가지고 있고 과거에는 콩을 지급해주었지만 현재는 스탬프로 바뀌었고 스탬프는 5개를 모아야만 콩 1개로 바꿀 수 있습니다.  그래서 사용자들은 서비스를 사용하며 얻은 콩으로 기부하던 간접기부에서 직접 충전한 콩으로 기부하는 직접 기부 형태로 발전하고 있습니다.실제로 서비스가 시작된 첫 해에 총 기부금액이 7억 8천만 원 정도였는데 후원콩과 기업 기부금이 6억 5천만 원 정도로 그 비중이 83%에 달했는데 12년이 지난 2016년에는 총 기부금액이 106억 정도였는데 63억이 후원콩과 기업 기부금이었습니다. 그 비중이 59%로 24%가 낮아졌죠. 그 추세는 계속될 것 같습니다. 아직 2달 정도 지난 2017년이지만 그 비중이 이제는 5:5까지 낮아졌네요. 어떻게 보면 기부에 관심을 가지는 사용자는 정해져 있고 그 사용자들은 더 많은 기부를 원하셔서 이런 흐름으로 왔다고 볼 수 도 있겠네요.실제 앞에서 언급했던 기부문화연구소의 자료에 따르면 기부를 하는 사람의 수는 줄었지만 인당 기부금액은 늘어났다고 합니다.[출처] 기부문화연구소 : 금액은 만원단위자료를 보면 인당 기부금액은 우상향을 하고 있으며 기부를 하고 계신 분들의 평균금액 증가는 더 큰 폭임을 알 수 있습니다. 그렇다고 하면 네이버의 정책이 어느 정도 이해는 됩니다. 하지만 더 많은 분들이 기부를 할 수 있는 방법은 계속 고민해서 이어나갔으면 하는 바람이 있네요.2. 같이가치 with 카카오네이버가 하면 다음도 해야겠죠? 2007년 12월 다음도 기부 관련 서비스가 생깁니다. 다음 아고라 내의 희망모금 메뉴로 시작되었죠. 아고라는 네티즌들이 각종 청원을 위해 만들어진 서비스인데 그 안에서 모금활동이 시작되었고 그걸 메뉴화 시킨 겁니다. 2011년 4월 희망해라는 이름으로 독립 서비스로 나왔고 카카오와의 합병 이후 2016년 3월 현재의 같이가치가 되었습니다.2017년 현재 같이가치모금활동으로 시작된 같이가치는 2017년 현재 같이기부라는 형태의 모금활동을 이어가고 있으며 같이타요라는 형태의 독특한 프로젝트를 진행하고 있습니다. 매거진은 같이가치의 소식이나 웹툰 같은 다양한 콘텐츠를 보실 수 있습니다.같이기부는 일반적인 기부활동이라고 한다면 같이타요는 조금은 독특한 형식입니다. 속마음버스는 서울시와 함께 하는 프로젝트로 말 그대로 속마음을 나눌 수 있도록 버스를 제공합니다. 그 안에서 1시간 40분가량의 드라이브를 즐기면서 소중한 사람과 그동안 나누지 못했던 속마음을 나누는 거죠.어떤버스는 미스테리봉사여행이라는 컨셉으로 약간은 진부할 수 있는 봉사활동을 미스테리여행이라는 이름으로 재미를 더했다고 볼 수 있습니다. 봉사활동에 대한 정보를 최소화시켜서 몇 가지 주어진 아이콘만으로 추측을 하고 봉사에 참여하고 싶다면 신청을 해서 낯선 사람들과 단체로 버스에 올라타고 봉사를 하러 가는 겁니다. 2월의 여행은 이미 끝이 났고 3월의 여행에 대한 정보는 아직 공개되지 않았습니다.네이버의 콩과 같은 소셜화폐가 과거에는 있었지만 같이가치로 개편된 이후에는 특별한 소셜화폐가 있지는 않습니다. 대신 SNS로 공유하거나 댓글과 응원을 통해 각 100원이라는 금액을 기부해주며 이를 참여기부라는 이름으로 부르고 있습니다.같이가치는 현재 누적 기부액이 146억을 넘었으며 누적 참여자는 2015년 기준으로 764만여 명이며 이후 자료는 찾기가 어려워 현재는 얼마나 누적되었을지 모르겠습니다.3. 쉐어앤케어지금까지 나왔던 서비스들은 모두 포털이라는 자산을 가지고 시작했다면 마지막으로 소개해드릴 쉐어앤케어는 유일한 스타트업 서비스입니다. 세상에서 가장 쉬운 기부 플랫폼이라고 칭하는 쉐어앤케어는 2015년 7월 베타 서비스를 시작했으니 이제 1년 반이 조금 더 되었네요.2017년 현재 쉐어앤케어쉐어앤케어는 페이스북을 기반으로 기부활동을 하고 있습니다. 도움이 필요한 곳과 도움을 주고자 하는 곳을 연결해주며 그 스토리를 캠페인으로 담아내면 사용자들이 자신의 페이스북으로 공유하여 기부를 할 수 있습니다. 그리고 그 사용자의 게시물을 사용한 사람들이 그 내용에 동감하여 좋아요를 누르면 그 역시 기부로 이어지는 말 그대로 소셜기부플랫폼이라고 할 수 있겠습니다. 앞에서 기부문화연구소의 발표에 의하면 경제적인 이유로 기부를 못한다는 답변이 가장 많았는데 현재 쉐어앤케어는 온전히 스폰서를 통해 기부금액을 모금하며 기부를 사용자들의 공유를 통해 만들어냅니다.실제 쉐어앤케어가 2016년을 결산하며 발표한 자료를 보면 2015년 대비 2016년에 큰 성장을 이루었음을 알 수 있습니다. 2017년 현재 누적 사용자는 41만 명이며 누적 기부액은 14억을 넘었습니다. 이게 작은 스타트업이 이루어낸 성과라고 생각하면 대단하다고 말하지 않을 수 없을 것 같네요.쉐어앤케어는 캠페인이 시작되면서부터 끝까지 모든 과정이 투명하게 나와있습니다. 모금되는 과정부터 모금된 금액이나 물품이 어떻게 전달되는지 후기를 통해 보이며 영수증과 같은 증빙자료들도 게시되어 있습니다. 이것 역시 기부문화연구소가 발표한 기부단체를 신뢰하지 못해서 기부를 안 한다는 답변에 대한 해답이 될 수 있겠네요.그리고 쉐어앤케어도 쉐케뉴스를 통해 자신들의 소식을 전하고 있습니다. 언론 기사나 진행했던 캠페인 관련된 이야기를 들려주네요. 예를 들어 최근 진행되었던 캠페인 눈길 시사회의 진행 소식이나 과거 초인종 의인 故안치범님을 기리는 소화기 기증식 같은 소식들이 눈에 띕니다. 이벤트에서는 자신이 기부했던 금액을 페이스북으로 공유하는 이벤트가 진행 중이네요.쉐어앤케어는 게이미피케이션을 적극적으로 활용하는 모습입니다. 매일, 그리고 매월 공유를 통해 가장 많은 좋아요를 얻은 사용자의 랭킹을 보여주고 있습니다. 가수나 정치인, 다양한 인플루언서들이 상위에 랭크되는 모습을 볼 수가 있네요.하지만 위의 두 서비스와는 달리 간접기부에만 묶여 있습니다. 해피빈과 같이가치를 보면 직접 기부의 비중이 점점 더 커지고 있다는 것을 알 수 있습니다. 쉐어앤케어도 분명 그런 부분에 대해 고민하고 있으러라고 생각이 드네요."그래서 제가 쉐어앤케어에 합류하였습니다."그동안 3대장 시리즈를 연재하면서 제가 몸담았던 서비스를 소개한 적이 없었지만 이번에는 꼭 소개해드리고 싶었습니다. 작은 스타트업이 강력한 인프라를 가진 회사들인 네이버와 카카오가 하고 있는 소셜기부플랫폼에 도전하여 사회공헌을 위해 힘쓰고 있다는 사실도 알려드리고 싶었고, 더불어 제 소식도 함께 알려드리고 싶었습니다.과거에 페이스북에 좋아요 1개당 1달러를 기부하겠다는 글들이 많이 돌았습니다. 쉬운 행동이라 많은 분들이 좋아요를 눌러주었지만 그게 정말 기부로 연결되었는지를 확인할 방법이 없었습니다.그런 사례로 사용되던 이미지그래서 좋아요가 무슨 도움이 되냐는 말이 있었습니다. 하지만 쉐어앤케어의 좋아요는 정말로 도움이 됩니다. 공유는 1,000원이 기부되고 내가 공유한 글에 좋아요가 눌릴 때마다 나의 이름으로 200원씩 기부가 됩니다. 그렇게 모인 기부금이 위에서 말씀드린 것처럼 14억이 넘었습니다.스타트업들이 가장 많이 하는 말이 '더 나은 세상을 만들겠다.'라고 하죠? 쉐어앤케어는 정말 더 나은 세상을 만들기 위해 노력하고 있습니다. 저와 쉐어앤케어 앞으로 지켜봐 주세요.#쉐어앤케어 #쉐케 #기업문화 #회사자랑 #사회공헌 #사회적활동

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

소개말안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 컨택틱의 이이삭 대표입니다. 오늘 여러분들에게 소개하고 싶은 내용은 '페이오니아로 VAT를 쉽게 납부하는 방법'입니다. 컨택틱은 아마존 전문 대행사이며, 미국뿐만 아니라 유럽 아마존 마켓 플레이스도 서비스를 지원하기 때문에 아래에는 저희 고객사 중에 한 분의 계정을 예시로 구체적인 절차를 보여드리고, VAT를 납부해야 할 일이 있으신 분들은 본 글을 보고 그대로 따라 하셔도 쉽게 VAT를 납부하실 수 있도록 도와드리고자 합니다.배경 설명페이오니아의 VAT 납부 기능은 2018년에 생긴 걸로 알고 있습니다 (정확히는 기억이 안 납니다). 이 기능이 생긴 게 얼마나 감사한 일인지, 애초부터 이 서비스를 사용하신 분들이라면 원래는 얼마나 VAT 납부하는 일이 귀찮고 번거롭고, 또 문제투성이가 많은 작업인지 절대 모르실 겁니다. 컨택틱은 페이오니아의 VAT 납부 기능이 생기기 전부터 세무대리인(ecommerceVAT)을 통해 영국 국세청 (이하 HMRC)에 아마존 영국, 독일, 프랑스, 이태리, 스페인의 매출에 대하여 VAT를 신고하고, 신고 완료된 내역을 기준으로 VAT를 납부까지도 했었는데요, ecommerceVAT처럼 일을 깔끔하고 정확하게 해주는 세무대리인의 덕분에 VAT 신고까지는 매우 쉽고 편리하게 할 수 있었으나, 문제는 확정된 VAT를 납부하는 과정에서 HMRC가 매번 말썽이었습니다... 대한민국 셀러의 입장에선 사실상 VAT를 납부할 수 있는 방법은 유일하게 카드밖에 없는데, 전 신용카드를 지극히 싫어하는 주의라 평소 회사 운영에 필요한 지출이 있을 때에도 체크카드만 쓰거든요. 그래서 당연히 VAT 납부도 체크카드를 사용하려고 했으나 제가 결제에 사용하려고 했던 체크카드가 비자나 마스터카드임에도 불구하고 계속 결제가 안되었던 문제가 있었습니다. 결국 어쩔 수 없이 신용카드를 사용하게 되었는데, 신용카드로 결제하는 경우 수수료가 추가적으로 발생하는 번거로움과 불필요한 지출이 일어났었습니다.페이오니아의 VAT 납부 서비스이런 번거로움과 불필요한 지출의 문제를 완벽하게 해결해준 게 바로 페이오니아의 VAT 납부 기능이었습니다. 페이오니아에 잔액만 있다면, 이젠 '무료'로 VAT를 납부할 수 있었으며, 한 방에 매우 쉽게 VAT를 납부하는 매우 편리한 기능인 것을 발견했습니다. 아래에 실제 예시를 보여드리고자 하오니, VAT를 납부하고자 하는 글로벌셀러는 꼭 페이오니아의 VAT 납부 기능 서비스를 사용해보실 것을 적극적으로 추천드립니다.페이오니아로 VAT 납부하기 (설명은 사진 밑에 기재되어있음)페이오니아로 로그인합니다. Pay 메뉴 중에 'Pay Your VAT' 버튼을 클릭합니다.그다음 화면에서는 위와 같이 어느 기관에 납부할지 선택합니다. 대부분 영국을 통해 distance selling (DE/FR/IT/ES)을 하고 계실 겁니다. 저 또한 그렇기 때문에 영국을 선택했습니다.다음 화면에서는 페이오니아 계정을 연동하기 위해 로그인 정보를 다시 제출하라고 나옵니다. 페이오니아 아이디와 비번을 기재하고 sign in 버튼을 클릭합니다.잠시 새로운 브라우저 탭을 열어서 gov.uk (HMRC) 사이트에 접속합니다 (내 VAT 번호가 뭔지, 그리고 납부해야 할 금액이 얼마인지 미리 숙지해두기 위함입니다). 사이트에서 Money and Tax 메뉴로 접속합니다.다음 화면에서는 VAT >>> VAT Returns 메뉴로 이동합니다.그다음 화면에서는 'submit your return online'을 클릭합니다.그러면 위와 같이 일단 gov.uk에 로그인부터 하도록 합니다.세무대리인을 통해 생성한 gov.uk 아이디와 비번을 입력하고 로그인합니다.HMRC도 보안에 철저해서 이렇게 2차 인증을 해주어야 합니다 (혹시 모르시는 분들이 있을까 봐 설명드리지만, 위 Access Code는 HMRC 어플을 깔면 확인할 수 있습니다. 이것 또한 gov.uk 계정을 처음에 생성할 때 다 세팅하는 것들입니다).휴대폰에서 보이는 모습입니다. HMRC 어플을 설치하면 위와 같은 화면이 보이는데, 아까 언급했듯이 Access Codes를 클릭합니다.컨택틱은 대행사이기 때문에 여러 계정을 관리합니다. 지금 예시에서는 맨 아래의 계정에 대한 VAT 납부를 하는 것이기 때문에 해당 코드를 기억했다가 (시간이 초과되어 갱신되기 전에) 빠르게 gov.uk 사이트로 돌아가서 코드를 입력합니다.코드를 입력한 뒤에 continue를 누릅니다.다음 화면에서 두 가지를 알 수 있습니다: (1) 내가 납부해야 할 VAT 납부액 (2) 내 VAT 넘버. 이 두 가지를 잘 기억했다가 이젠 다시 페이오니아 화면으로 돌아갑니다.아까 기억했던 두 가지를 각 란에 맞게 입력하고 '최종 확인' 버튼을 클릭합니다.마지막으로 이상 없는지 확인하시고 '결제' 버튼을 클릭합니다.VAT 납부가 완료됐습니다! 수고하셨습니다 :)그럼 오늘도 즐거운 글로벌 셀링 되세요!컨택틱   서울특별시 강남구 강남대로 62길 11, 8층 (역삼동, 유타워)   대표 전화: 02-538-3939   해외 부서: 070-7771-1727   영업 부서: 070-7771-1728   이메일: [email protected]   유튜브: https://www.youtube.com/channel/UC8OxbQGAnMqWGpGj5weLcZA  홈페이지: https://www.kontactic.com

2017년 7월 온 힘을 다해 개발한 삼분의일 매트리스가 출시되었다. 다행히 시장 반응은 뜨거웠고 8개월 동안 4,000개의 매트리스를 판매했다. 곧, 매트리스 보다도 완성도 높은 베개를 만들고 싶어 졌다.지름길은 없다. 한 걸음씩 나아가자<개발 프로세스>1. 100명의 인터뷰2. 원료 개발3. 첫 프로토 타입 디자인4. 고객 피드백받기5. 개선 제품 만들기 - (1)6. 고객 피드백받기7. 개선 제품 만들기 - (2)부피가 작아서였을까? 베개는 3번 정도의개선 작업을 거치면 마음에 꼭 드는 제품이 나올 줄 알았다. (매트리스는 총 10번의 프로토타입을 거쳐서 출시됨) 지금 생각하면 터무니없는 생각이었다. 베개는 매트리스보다 더 세심한 기획과 지겨울 정도로 반복되는 iteration이 필요한 제품이었다. 1. 100명의 인터뷰시작에 앞서 베개 개발에 도움을 주셨던 분들에게 감사의 인사를 올린다. 체험 방문하셨던 분들 중에서 유독 베개 얘기가 나오면 눈을 반짝이시면서 베개 관련 인사이트를 아낌없이 전달해주신 분들이 없었다면 지금 삼분의일 베개는 존재할 수 없었다. 우리는 가장 원초적인 방법을 택했다. 100명에게 현재 쓰고 있는 베개의 장단점, 앞으로 쓰고 싶은 베개에 대해서 물어보는 인터뷰를 진행했다. 정말 재밌는 인사이트를 많이 얻었지만 결국 좋은 베개는 다음  3가지로 귀결되었다. 1) 너무 단단하지도 않고, 너무 푹신하지도 않은 완벽한 원료 찾기2) 등으로 눕던, 옆으로 눕던 한결같은 편안함 유지하기3) 지금 쓰는 매트리스와 완벽한 궁합 맞추기위 3가지 문제를 풀어내야 했다. let's go!100인의 인터뷰2. 원료 개발완벽한 소재를 찾기 위해서 기성 폴리우레탄 폼 수백 가지로 베개로 만들어 테스트해봤지만 우리 마음에 꼭 드는 폼은 존재하지 않았다. '지름길은 없다!'를 되뇌면서 폴리우레탄 원료부터 완전히 새롭게 개발하기로 했다. 왜냐면 세상에 없던 완벽한 베개를 만들어야 했으므로...베개 원료 미션- 너무 푹 꺼지지 않고, 너무 통통 튀지 않아야함 (포근함/탱탱함의 황금비율)- 여름에도 너무 덥지 않게 통기성 확보- 겨울에도 단단해지지 않는 온도 둔감형3가지를 위한 원료를 개발한다고 선언했을 때 업계 관계자 분들은 하나같이 불가능하다고 했다. 본 적이 없다고 존재할 수 없는 건 아니잖아? 무조건 해낼 수 있다는 일념으로 원료 사장님과 하나씩 하나씩 잡아나갔다. 핸드 믹싱 해서 만들었다가 폐기한 베개만 500개가 훌쩍 넘어간다.. ㅠㅠ아무튼 꼬박 3달이 넘게 원료를 가지고 씨름했다. 잡힐 듯 말 듯.. 베개가 왜 이렇게 안 나오냐고 문의하신 고객분들 이제야 말씀드리자면 원료 개발에서 너무 많은 시간이 걸렸습니다 ㅠㅠ 3달 내내 한번 더 한번 더를 외치는 저희를 잘 견뎌주신 관계자분들에게 다시 한번 감사드립니다. 어렵게 메모리폼처럼 포근하지만, 적절한 지지력이 느껴지고 , 통기성과 물에 강한 성질을 가지고, 겨울에도 단단해지지 않는 온도 둔감형 폼이 세상에 처음 나왔다.3. 프로토타입 디자인앞서 삼분의일은 100인의 인터뷰를 통해서 삼분의일 베개의 지향점을 설정했었다. 1) 너무 단단하지도 않고, 너무 푹신하지도 않은 소재 --> 원료 개발을 통해 해결2) 등으로 눕던, 옆으로 눕던 한결같은 편안함--> 등으로 눕다가 옆으로 누우면 어깨 넓이만큼 베개의 높이가 높아져야 한다. 이를 위해 등 / 왼쪽/ 오른쪽 누울 때 세 가지 옵션을 가지는 베개를 구상했다. 프로토타입 이미지그 다음에는 등으로 누울 때 / 옆으로 누울 때 경추의 긴장도를 최소화 하면서 지지력을 확보할 수 있는 insert foam을 넣기로 했다. 아래 사진을 보시라.옆으로 누웠을 때는 좀 더 까다로운 상황을 해결해야 했다. 어깨의 넓이 때문에 폼이 깊숙하게 잠기고 이로 인해서 옆으로 누웠을 때 목의 각도가 수평이 되지 않는 문제가 있었다. 이 문제는 옆면의 insert foam 경사를 다르게 해서 옆으로 누웠을 때도 수평 각도를 유지할 수 있도록 했다. 3) 지금 쓰는 매트리스와 완벽한 궁합--> 삼분의일 베개는 너무 당연하게도 삼분의일 매트리스에 최적화될 수 있도록 개발했다. 삼분의일 매트리스가 잠기는 정도를 정확하게 계측해서 3면의 높이와 안에 들어가는 insert foam을 디자인했다. 삼분의일 매트리스를 사용하시는 분이라면 필수품이고, 등/옆으로 모두 주무시는 분들도 한 번쯤 사용해보시면서 우리의 고민을 느껴보시길 바란다. 4) 기타 디자인 특징 요약- 가운데는 낮고 , 양옆이 높다. (옆으로 누울 때는 어깨만큼 베개가 높아져야 함)- 등으로 누웠다가 옆으로 자세를 바꾸면, 자연스럽게 높은 곳에 벨 수 있게 디자인함.- 옆으로 누웠을 때 귀가 눌리지 않도록 '귓구멍'을 파냈다. - 등으로 누웠을 때는 완벽한 경추 지지를 위해 경도가 다른 insert foam을 넣었다.- 옆으로 누웠을 때는 목의 각도가 수평이 되기 위해 옆면에도 insert foam을 넣었다. 등등... 원료 개발이 예상보다 많이 늦어지면서 금형은 훨씬 이전에 다 만들어 두었고 원료가 완성되는 날 첫 번째 프로토타입 베개가 50개 태어났다.4. 고객 피드백받기첫 번째 프로토타입은 가장 도움을 많이 주셨던 '베개 현자'분들에게 먼저 보내드렸다. 프로토타입이 완성되자 이분들은 우리보다 100배 더 기뻐해 주셨다. 그리고 예상했던 대로 논문 수준의 깐깐한 피드백을 받을 수 있었다. 맙소사.. 이분들은 하루 종일 베개 생각만 하셨던 걸까?? mm 단위의 높이 수정, 인서트 폼도 직접 분해해서 새로운 디자인까지 제시해주셨다. 5개 정도만 고치면 되지 않을까 했는데 무려 30군데가 넘는 디테일을 덕분에 고칠 수 있었다. 금형도 최대한 손질해서 사용할 수 있지 않을까 했는데.. 모조리 다시 만들었다. (금형 제작 비용 350만 원 ㅠㅠ)그렇게 이번 수정이 마지막이 될 줄 알았다. BUT....5. 개선 제품 만들기 - 고개 피드백받기 반복두 번째 개선품은 매트리스를 가장 많이 사신 분들 순서로 보내드렸다. 최고 기록은 13개인데 아직까지도 깨지지 않고 있다. 아무튼 30여 군데를 개선하고 나서 이제는 더이상 수정될 부분이 없겠지 싶었다. 읭? 하지만 오히려 첫 번째만큼이나 수정될 포인트들이 나왔다. 수량을 늘려서 테스트를 해서인지 너무나도 다양한 개선안 아이디어들이 쏟아져 나왔다. 어떤 부분들이 하나씩 개선되었는지 써보고 싶지만.. 신비함 유지를 위해서 체험 예약을 하고 찾아오시는 분들에게는 상세히 알려드리도록 하겠다. 예약하고 체험 방문 해주세요!https://booking.naver.com/booking/10/bizes/117867 [네이버 예약] 삼분의일 체험하기바른 수면자세와 제품 선택 방법에 대해 매트리스 개발에 참여한 임직원이 직접 설명해드립니다. ※ 여러 명이 방문하시더라도 예약은 1개만 하시면 됩니다. ※ 체험 시간은 30분이며, 예약 시간에 늦게 도착하신 경우 다음 예약 유무에 따라 체험이 조기 종료될 수 있습니다.booking.naver.com 아무튼.. 이번에는 없겠지 싶을 때마다, 전혀 예상하지 못한 개선점들이 계속 줄줄이 나왔다. 매트리스의 10번 보다도 훨씬 많은 개선 작업 끝에 베개 스펙을 확정할 수 있었다. 베개 금형은 몇 개를 만들었는지는 기억도 나지 않는다.. 그리고 베개 원단을 찾아서 헤맸던 시간들도 모아 보면 50시간은 족히 넘을 듯...버전별로 일열 종대로 세워봤다. 참 많이도 만들었다.세상에 없던 세계 최고의 베개를 만들고 싶었다.'지름길은 없다'는 생각을 가지고 무식하게 100명을 인터뷰하고 원료 개발부터 10번이 넘는 프로토타입 개발과 테스트를 무사히 마치고 나니.....  뿌듯하고 감개무량하다. 자식이 태어났을 때가 이런 기분이 들지 싶다. 베개 개발 기를 정성스럽게 써놓고 보니, 차칫하면 삼분의 일이 베개 회사로 널리 알려질지도 모르겠다는 생각이 스친다. 베개 원단을 만들어 나가는 과정도 써보려고 했는데 지면관계상 사진 3개로 정리한다. 이번 글 반응이 좋으면 베개 원단 개발기도 써보려고 한다. 원단 본을 뜨고 하나하나 만들어 나가는 과정.by 전주훈삼분의일 대표#삼분의일 #매트리스 #베개 #제품개발 #제품기업 #문제해결 #인사이트

안녕하세요 크몽 개발팀입니다.작년 12월 크몽파티때 기억나시나요? 프론트엔드개발자인 저 쿤이 그날 반응형웹을 1~2월달까지 시전하겠다! 라고 호언장담했었는데요.. 저도 그때당시에는 무조건 해보자라는 생각으로 얘길했던건데.. 팀원들의 반응이...이랬었더랬죠... 그때의 저의 심정은 가슴이 바운스바운스 두근대~... 넵 그랬었습니다...하지만!!! 1월달에 잠시했던 공부와 2월달에 잠시얻은 잉여로움을 발판삼아 전부는 아니지만 메인페이지만 해내었습니다. 처음의 도전은 험난하디 험난했습니다.여러 문서들을 보던가운데 반응형웹을 잘 소화하고 계시는 기업블로그의 포스팅을보게 되었는데요..출처: S사 기업블로그한마디로 이해가 쏙쏙되는 포스팅이었습니다.여기에 감명받은 저 쿤은 바로 연습에 들어갔더랬죠..하지만.. 각각 디바이스에대해 설정값을 넣어줘야하는반응형 웹은 쉽게 다가갈 수 없는 미저리같은 그런 녀석이었습니다아..그래도.. 다시 심기일전하는 마음으로 처음부터 모크업을 진행을 하였답니다. 처음 모크업은 이러하였어요...메인화면 소개를 거치면 짠하고 크몽홈페이지가뜨는!!!!그런 이미지였답니다. 하지만 여러분들도 알다시피 계획한일들이 안될경우도 있잖아유....저도 그러하였어요..물론 처음시작할때에만 하더라두 이것들을 다끝내겠어란활활 불타오르는 열정으로 시작했었죠!!처음작업을해서 뽑아낸 아이들의 사진이에요. 상단바를 각 디바이스크기에 맞게 하는 작업을 먼저 했었는데요..이 녀석이 은근 골치 아픈 녀석이었답니다.각 위치마다 고정폭이 정해져있어고 그녀석들을 반응형에 맞출려고 얼마나 고생했는지.. 가뜩이나 수학도 못하는데 퍼센트 계산만 했엇답니다.. 저에게 퍼센트도 이러했답니다.. 하.....수학공부를 열심히해야겠어요..그래도 꿋꿋이 계산하고 넣어보고 계산하고 넣어보고 계산하고 넣어보고 즐기고~그러다 보니 점점 하나하나씩 되기 시작했어요!!머리는 점점 잘 돌아가고 재능목록들이 자기자리로 돌아가고!!!!노력의 기적이 어떤것인지 보았습니다.. 이리하여 결국에는..이러한 결과를 낳았더랬죠!! 실은 작업한지 꽤나됬고 릴리즈된지도 꽤나되었지만..아마두.. 모르시는 분들이 많을거에요지금 여러분들이 가지고 계신 폰으로 크몽의 반응형메인을 만나실 수 있답니다~!!한번 보시고 따끔한 충고를 답글에 남겨주세요. 따끔하게 맞고 고칠 수 있는부분은 한번씩 잉여로울때 작업을 하도록하겠습니다. -----------------------------------------------------------------------그럼 지금부터는..제가 이번작업을 하면서 느꼇던 몇가지를 적어볼까합니다.바로바로바로 당신이 반응형웹을 하고싶다면!!  따단!!그 첫번째 규칙!! 절대 고정폭을 주지말아라-이것이 반응형웹할때는 가장 중요한 거십니다.반응형웹이라도 픽셀은 PC와 노트북에서 여러분의 눈에 보이는것과 마찬가지로 적용된다는점!!!만약에 고정폭으로 1200px를 주게되었다면 데스크탑이나 노트북에서는 보기좋게 보이지만모바일환경에서는 엄청확대되어보인다는 사실 아셨나요??! 그럼 "고정폭대신 CSS에 뭘 줘야되는건가요?"라고 묻는 당신께 퍼센트(%)를 바칩니다.. CSS에 픽셀(px)대신 퍼센트(%)를 넣으면 여러분이 브라우저크기를 낮출때마다화면이 가변적으로 늘어난답니다. 물론 퍼센트는 백분율이라 화면의 크기에 맞게크기를 지정해주면 된답니다.그 두번째 규칙!! 미디어쿼리를 활용하랏!!!-미디어쿼리... 과연 그거슨 무엇인것인가!!!쉽게 설명해드리겠습니다. 미디어쿼리란 여러분의 브라우저크기를 컴퓨터가 인식해그 크기에맡게 보여주는 그런 녀석입니다.여러분들이 딱히 할게 별거없어요..그냥 미디어쿼리를 CSS에 설정해주고 그 크기에맡게 어떻게 보여줄것인가에 대해작성해주시면 되는겁니다. 참 쉽죠오?? 으앗!!음.. 일단 자세한 내용은 저의 스승블로그의 포스팅을 보시면 쉬울거에요..http://readme.skplanet.com/?p=9739#s5반응형 웹 기술 이해 | READMEreadme.skplanet.com그 세번째 규칙!! 같은줄에 있는 컨텐츠가 다들어가기엔 모바일화면이 너무작다면 밑으로 내리여!!!-분명 여러분들의 홈페이지를 작업할때에 보면 PC사항에서 잘 자리잡혀 있던것이 모바일환경에선 왠지 좁아 터질 것같다라고생각이 드실수 있습니다. 그렇다면.. 밑쪽으로 내리는 것을 저는 추우천을 드립니다!!그렇담 그 컨텐츠가 내려간다면 배치는 어떻게 해야 이쁜가에대한 저의 답변은 "그건 디자이너님 너의 맘이야 God bless you"입니다. 그 네번째 규칙!! 부트스트랩 같은 녀석들을 사용하랏~!!!!-아마 직접 CSS와 js를 조작하라고해도 못하시는 분들이 있으실거에요..그런분들을 위해 태나났습니다아~!!!! 바로바로바로 부트스트랩과같은 것들인데요.이 녀석들은 자기들이 설정해놓은 CSS집단인 컴포넌트로 웹개발자들을위협(?)하는 그런 녀석이랍니다.이 뇬석들을 사용하면 반응형웹이고뭐고 멋진표던뭐던 다 뚝딱뚝딱 만들어내죠..저도 애용하고있는 아이들이랍니다.(실은.. 상단바작업은 제가 CSS로했고 컨텐츠들은 부트스트랩이란 도구로 작업을 하였는데요.. 그시간차이가 우와 할정도에요..)그 정도로 좋은 녀석이랍니다. 그 녀석을 찾으실려면 구글검색창에 "부트스트랩"이라고 쳐보세요.CSS무지식개발자라도 쓰실수있게 패키지가 구성되어있답니다. 아무 클래스나 골라담아요 골라담아~!!-----------------------------------------------------------------------음음.. 뭐 별거없었지만 제가 올린 포스팅글 잘보셨는지 궁금하네요..꼭 반응형웹에 도전하시는 분들이 봤을때 좋은 내용이었으면 좋겠다는 작은 바램이 생기네요그럼 저는 크몽에서 프론트엔드 개발자를 맡고있는 Kun이었구요.다음번에 더 좋은 포스팅으로 만나뵈요. 제발~#크몽 #개발자 #개발팀 #팀원소개 #인사이트 #스택도입 #일지

모니터링은 IT 운영의 핵심입니다. 장비의 활성화 상태에서 애플리케이션의 변화와 성능 이슈까지 언제나 실시간으로 인지와 대응이 가능해야 합니다. 서비스를 운영에 장애를 없앨 수는 없지만 좋은 모니터링 전략을 가지고 있다면 빠른 예방과 대응을 통해 고객이 불편함을 느끼지 못하게 할 수는 있습니다.  IT 운영에서의 비지니스 목표IT 서비스 모니터링 전략을 만들기 전에 우리는 우선 목표를 선정해야 합니다. 빠른 예방과 대응은 좋은 모니터링 전략의 기본 목표일 뿐입니다. 우리는 모니터링을 통해 아래와 같은 비지니스 목표를 이루어야 합니다. 브랜드 이미지 향상매출증대비지니스 개선비지니스 목표를 위한 모니터링그리고 이런 비지니스 목표를 위해서는 아래와 같은 일들을 모니터링을 통해 수행할 수 있어야 합니다. 안정적인 서비스 운영 (브랜드 이미지 향상, 매출증대)빠른 장애 대응 (브랜드 이미지 향상, 매출증대)장애 예방 (브랜드 이미지 향상, 매출증대)사용자 분석 (비지니스 개선)사용성 분석 (비니지스 개선)서비스 성능 개선 (브랜드 이미지 향상, 매출증대)현대 IT 서비스는 물리서버와 클라우드가 혼재되어 있는 인프라스트럭처 환경과 다양한 플랫폼에서 개발된 애플리케이션들이 작게 구성되어 있는 복잡한 구성을 가지고 있습니다. 뿐만아니라 서비스의 구성 또한 전 세계에 분산되어 있는 상황에서 우리는 효율적인 모니터링 전략을 만들어서 IT 서비스를 운영해야 합니다.비지니스 목표를 위한 모니터링 전략이런 체계적이고 효율적인 IT 서비스 모니터링 전략을 만들기 위해서는 아래와 같은 것들을 고려해야 합니다.1. 통합 모니터링 체계를 구축하세요.  인프라스트럭처와 애플리케이션을 모두 모니터링하여 전체 그림을 얻어야 합니다. 전체적인 그림을 모든 운영자들이 알수 있어야 체계적인 IT 서비스 운영이 가능합니다.2. 기준을 넘어서는 성능 변화가 생기면 알수 있도록 경고를 설정해야 합니다. CPU 부하율, 메모리 사용률, 누적 트랜잭션 등 다양한 상황에 대한 기준 값을 선정하고 이에 대한 알림을 받을 수 있어야 합니다. 초기 이슈 확인은 고객이 영향을 받기 저너에 문제를 해결할 수 있게 해 줍니다. 3. 사용자 관점에서 모니터링 해야 합니다. 예를 들어 TPS의 평균값만으로 서비스의 안정성을 판단해서는 안됩니다. 사용자 개개별 현황을 파악 할 수 있어야 합니다. 기업의 브랜드는 서비스 사용에 불편을 겪는 1%의 고객을 통해 내려갈 수 있습니다.4. 메트릭을 비지니스 목표와 맞출 수 있어야 합니다. 현재 서비스에 접속한 사용자 현황을 알 수 있어야 합니다. 예를 들면 동시 접속자 수를 기반으로 현재 서비스의 성능을 설명할 수 있어야 합니다. 5. 애플리케이션에서 특히 데이터베이스의 성능을 평가할 수 있어야 합니다. 많은 이슈들이 데이터베이스에서 발생합니다. 6. 애플리케이션의 코드 성능을 분석할 수 있어야 합니다. 많은 프로젝트에서 오픈소스 또는 서드파티 솔루션들이 사용되고 있습니다. 여기서 발생하는 문제들은 심각한 장애 상황을 유발할 수 있습니다.7. 모든 서비스를 분석 할 수 있어야 합니다. 몇몇 페이지가 아니라 전체 페이지를 분석 할 수 있어야 합니다. 우리는 항상 효율적인 IT 모니터링 전략을 재평가하고 새로 구축해야 합니다. 모니터링 전략을 만드는 것은 쉬운 일이 아닙니다. 하지만 모니터링 전략을 만드는 데 시간을 투자하는 것은 안정적으로 서비스를 운영하는데 있어서 매우 가치있는 일입니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

안녕하세요! 이번 주 수업에서는 합성곱 신경망에 대해서 배웠어요. 제가 읽은 한 기사에 의하면 대장 내시경 검사에도 딥러닝을 이용하면 종양 식별 능력을 더 높일 수 있다고 해요. 딥러닝을 이용한 검사는 전문가 분석을 통한 대장 내시경 검사보다 종양을 9개 더 많이 발견했고 진단 정확도는 96%인 것으로 나타났어요. (원문 링크) 이 대장 내시경에 우리가 배운 CNN(Convolutional Neural Network), 이미지 기반 딥러닝 모델을 사용했다고 하는데요. 이 대장 내시경에 사용된 CNN에 대해 알아볼까요? (Cover image : Photo by Paul Carmona on Unsplash)CNN(Convolutional Neural Network, 합성곱 신경망) CNN(합성곱 신경망)은 Convolution(합성곱)연산을 사용하는 인공신경망의 한 종류에요. 합성곱 신경망은 주로 이미지 데이터를 다루는 문제에서 사용돼요. 쉽게 말해 합성곱 신경망은 이미지의 특징을 추출하고 잘 조합하여 문제를 해결하는데요.  예를 들어 왼쪽 이미지가 고양이인지 컴퓨터가 알아맞히기 위해서 합성곱 신경망은 고양이가 가져야 할 특징을 한 번에 파악하는 것이 아니라 부분부분 판단하여 종합적으로 결론을 내요. 합성곱 신경망은 사진에 고양이의 특징이 기묘하게 분포되어 있어도 정확하게 고양이의 특징을 찾아내는 높은 적응도를 갖고 있어요.이제 합성곱 신경망의 구조에 대해 알아볼까요?CNN의 네트워크 구조1. 합성곱 층 (Convolutional Layer)합성곱은 두 함수 중 하나를 반전하고 이동시켜가며 다른 하나의 함수와 곱한 결과를 적분해나간다는 아주 어려운 뜻을 가지고 있어요. 다음 예시를 보도록 할게요.여기에 2차원 배열 픽셀을 넣으면 X 인지 O 인지 알아내는 합성곱 신경망이 있다고 해봐요.이 합성곱 신경망은 똑바로 된 X와 O를 넣으면 X 인지 O 인지 정확하게 구분하는데,이렇게 크기가 바뀌고 회전되어 모양이 변형된 이미지를 보고도 X 인지 O 인지 정확히 구분할 수 있을까요?합성곱 신경망은 합성곱 신경을 이용하여 이미지의 특징을 매칭 시킨 결과가 같으면 같은 이미지라고 인식해요.‘X’ 이미지의 특징을 추출하면 위와 같은 매트릭스, 합성곱 필터(Convolution filter(=커널))가 나와요. (세 특징을 잘 조합하면 X 형태가 나오죠?)이제 제일 왼쪽의 합성곱 필터를 가지고서 이미지가 X 인지 알아볼게요. 합성곱 필터와 원본 이미지를 비교할 때는 곱셈을 이용해요. 합성곱 필터의 크기만큼 원본 이미지와 차례차례 곱해서 값을 채워나가요.위의 합성곱 정의에서 두 함수를 하나는 이미지, 또 하나는 필터라고 생각하면, 필터를 이동시켜가며 이미지와 곱한 결과를 적분 즉, 덧셈해 나간다는 뜻이 돼요.합성곱 필터의 크기만큼 값을 다 계산한 후, 계산한 원소를 다 더해서 합성곱 필터의 크기만큼 나눈 평균값을 또 다른 새 매트릭스에 채우게 되는데 이를 특징 맵(Feature map)이라고 불러요. 즉, 특징 맵은 기존의 이미지에 필터를 곱한 결과로 각 픽셀에 쓰여있는 값이 클수록 그 특징을 가지고 있다는 뜻이에요.이렇게 원본 이미지와 합성곱 필터의 곱한 결과로 특징 맵이 나왔어요.나머지 두 개의 합성곱 필터와 곱한 결과로 두 개의 특징 맵을 가질 수 있어요.한 개의 합성곱 층(Convolutional layer)에는 여러 개의 합성곱 필터가 있어요. 합성곱 층에서 기존의 이미지와 필터들을 합성곱한 결과, 처음 이미지는 필터 된 이미지(특징 맵)로 쌓이게 돼요.2. 풀링 층(Pooling Layer)풀링은 가로/세로 방향의 공간을 줄이는 연산으로 합성곱 층의 특징을 압축한 특징 맵을 형성해요. 풀링에는 최대 풀링(Max pooling)과 평균 풀링(Average pooling)이 있는데 이미지 인식 분야에서 주로 사용하는 것은 최대 풀링이에요. 그래서 보통 풀링이라고 하면 최대 풀링이라는 의미로 사용한다고 보시면 돼요.위의 예시는 2x2 최대 풀링을 적용한 예시에요. 아까 구한 특징 맵에서 2x2 픽셀에서 가장 큰 원소 값을 새로운 맵을 채워나가는데 이를 활성화 맵(Activation map)이라고 불러요. 최대 풀링을 사용하면 노이즈가 감소하고 속도도 빨라지며 영상의 분별력이 좋아진다고 해요. 마지막 출력 층은 최대 풀링의 모든 뉴런과 연결되어 출력값이 어떤 클래스에 해당하는지 파악되는데 사용돼요.이렇게 CNN을 이용하면 변형된 이미지라고 하더라도 원래 이미지의 특징을 가지고 있다면 정확히 구분할 수 있어요.코드로 연습해보기아래는 간단한 인공신경망 코드예요.Layer 1 - input:1x28x28 , output : 64x28x28 + Activation function - reluLayer 2 - input: 64x28x28 output:1x28x28Layer 3 - input: 1x28x28=784 output:10class MNIST_Net(nn.Module):    def __init__(self):        super(MNIST_Net, self).__init__() # nn.Module 생성자 호출         # an affine operation: y = Wx + b        layers = []        layers.append(nn.Conv2d(1,64,3,1,1))         layers.append(nn.ReLU())         layers.append(nn.Conv2d(64,1,3,1,1))         layers.append(nn.ReLU())         self.main = nn.Sequential(*layers)        self.fc = nn.Linear(28*28, 10)    def forward(self, x):        # x.view함수는 주어진 인자의 크기로 해당 데이터의 크기를 반환합니다. 즉, (Batch_size,1,28,28) --> (Batch_size,28*28)로 변환합니다.        x = self.main(x)        x = x.squeeze().view(-1, 28*28)        x = self.fc(x)  # 10 으로 10개의 Class에 대한 logit 값을 호출합니다.         return x합성곱 인공 신경망의 내용은 정말 배울 것이 많아서 수업 시간 내에 다 배우기가 조금 벅찼지만 다른 인공 신경망에 비해 재밌어서 집중할 수 있었어요. 이제 앞으로 1번의 이론수업만을 남겨두고 있어서 아쉽기도 하고 또 뿌듯하기도 해요. 앞으로 조원들과 함께 프로젝트를 진행하면서 지금까지 배운 이론을 적용해보게 되는데요. 프로젝트 주제를 정하는 것부터 벌써 쉽지가 않아요. 하지만 열심히 프로젝트를 해서 리쿠르팅 데이 때 실력을 뽐낼 수 있다면 좋겠네요!* 이 글은 AI스쿨 - 인공지능 R&D 실무자 양성과정 7회차 수업에 대해 수강생 최유진님이 작성하신 수업 후기입니다.

2014년, 3월 비캔버스 개발을 시작했다. 약 2년이 넘게 시간이 지나면서 많은 방향 전환이 있었다. 단순한 포스트잇 기록 가능한 메모 도구로 시작했지만 이후, 온라인 화이트보드, 프로젝트 관리 툴, 비주얼 블로깅 툴 등 약 4번 이상의 크고 작은 방향 전환이 있었던 것 같다. 작년에 이미 국가와 기업으로부터 3억 원 이상의 자금을 투자받은 상태였기 때문에 조급함만 쌓였던 것 같다. 그런데, 일을 하면서도 전혀 그 분야에 대해 박식해지는 것과 같은 느낌이 들지 않았고 비전도 명확하지 않았다. 하고 싶지 않은 일이라서가 아니었다. 이 분야의 한계가 명확하게 머릿속에 들어왔기 때문이었다. 지금 그러한 경험을 공유하고자 한다. 내 경험으로 협업툴. 특히 프로젝트 관리 툴 시장은 매우 포화상태이며 미래가 없고, 인류를 위해서 조금도 도움이 되지 않는다는 결론에 도달했다.다만, 이런 프로젝트 관리 툴을 만들면 전 세계에서도 경쟁력 있는 회사가 될 수 있겠다.개별 기업 혹은 팀이 자신과 팀이 일하는 워크플로우를 간단하게 A4용지나 액셀등으로 정리하면 그것에 딱 맞게 커스터마이즈 된 툴을 제공한다. 혹은 이제까지 일한 정보들을 바탕으로 그에 최적화된 툴을 만들어준다.  이유는 간단하다. 회사마다 일하는 플로우가 너무나도 다르다. 그렇기 때문에 프로젝트 관리 툴의 최고봉은 아직도 액셀일 수밖에 없다. 전 세계적으로 이름이 조금 알려진 것만 해도 1,000여 개가 넘는 프로젝트 관리 툴이 있는데, 그들 대부분이 작게나마 수익을 올리고 있는 이유도 이와 같다. 워크플로우가 너무 다양하기 때문에 Needs가 매우 파편화 되어 있다. 트렐로, Asana, 스마트시트와 같은 탑 3 프로젝트 관리 툴은 매우 보편적인 형태의 기능을 제공함으로써 시장을 골고루 나눠먹고 있다. 트렐로는 보드 형태의 직관성을, ASANA는 체크리스트 방식, 스마트시트는 액셀 방식으로 서비스를 제공한다. 프로젝트 관리에는 역시 액셀이 짱이다. 다양한 회사가 자신의 워크플로우에 맞게 개인화할 수 있다.컴퓨터라는 도구가 생긴 이래로 우리가 일할 때 해오던 방식은 저기서 끝났다고 봐도 과언이 아니다. 여기에 더해서 페이스북과 같이 SNS를 기업형으로 만든 케이스가 있는데, 써보면 알겠지만 쓰면 쓸수록 불편하다. 애초에 정보의 영속성이 요구되는 기업현장에서 정보를 망각 가능한 말랑말랑한 객체 로보고 두뇌처럼 관리하는 타임라인 방식은 도통 맞지 않는 셈이다.그렇다면, 왜 나는 프로젝트 관리 도구가 미래를 제시하지 못한다고 결론 내렸을까? 그 이유는 매우 간단한데, 툴과 사람의 주객이 전도돼가고 있는 것이 느껴졌기 때문이다. 실제로, 협업 툴을 도입하면 사람들은 그 툴에 모든 워크플로우를 다시 맞춰야 하고, 툴을 배워야 하며 그 툴에 이제까지의 정보를 넣는 등 필요 없는 작업들을 해야 한다. 그저, 검색과 관리의 용이성을 위해 우리는 인간 개개인이 가진 힘을 전체 속에 껴넣는데 불필요한 리소스를 낭비한다고 판단했다. 그리고 올해 초, 한창 힘들었을 시기에 도구에 대해 매우 깊고 조용하게 생각할 시간을 갖게 됐다. 역사적으로, 도구는 인간이 생물학적인 한계를 넘어서게 만들어, 더 나은 세상을 만드는데 기여해왔다.포클레인은 작은 아이도 거대한 힘을 발휘할 수 있도록 만들었고, 자전거는 인간이 맹수보다도 빠르게 이동할 수 있는 힘을 줬다. 애플의 스티브 잡스, 워즈니악이 발명한 개인 컴퓨터는 인간이 신체뿐 아니라 정신적 한계까지 넘어설 수 있는 힘을 줬다. 이렇게 언제나, 인간은 도구를 이용해 한계를 넘고 가치를 창출해왔다. 그것이 인간만이 가진 초월적인 힘이다.결국 도구는 '초월'을 의미하는 것이 아닐까?그런데, 갑자기 모든 것이 달라졌다.도구들의 비약적 발전과 함께 일어난 것은 사람들이 일하는 방식의 변화였다. 작은 공방, 상점 등에서 일해왔던 인류는 무언가를 수행하기 위해 언젠가부터 100명. 200명. 수 천명. 매우 거대한 조직을 만들기 시작했다. 조직의 비대함과 함께 개인의 역량에 대한 기대와 요구는 떨어졌고, 그들을 전체적으로 관리하고 통솔하는데 관리자는 몰두하기 시작했다. 우리는 이미 알고 있다. 나 자신도 누군가의 '관리의 대상'이라는 것을 말이다. 사람 한 명, 한 명은 아마존이나 Ebay에 배치된 상품처럼 DB화 되어 HR관리자에 의해 관리된다. 인터넷 시대로 접어들면서 모든 기업은 종이에 쓰인 아날로그 정보들을 디지털로 옮겨오기 시작했다. 아날로그식 업무를 디지털로 옮겨오면서 발생하는 손실을 막기 위해 ‘관리’가 곧 생산성의 척도가 됐다. 지금 존재하는 생산성 툴의 80%가 이런 방향을 향해가고 있다고 보면 된다.나는 이것이 이미 깨진 항아리를 막기 위한 고군분투인 것으로 보였다. 깨진 항아리를 막아달라는 '니즈'는 분명히 존재하기 때문에, 누군가 달려들어 깨진 항아리를 운 좋게 한번 잘 막을 때마다 시장으로부터 돈을 버는 형태로 사업이 이어지고 있다고 판단했고, 이 분야에선 발전적인 미래가 없다고 생각했다. 그때였다. 간디의 말은 내 심장을 뿌리 깊게 파고들었다.그렇다. 대부분 협업 툴은 물론 우리가 향했던 방향은 '행동'을 만드는 일이었다. 사람들이 일하는 방식을 만들고 우리의 방향을 강요해서 습관으로 만들고, 그 습관의 관성을 유지시키는 것이 비즈니스 모델이었던 것이다. 그 습관을 유지하는 것 자체가 '가치'라는 착시로 보일 것이 분명했다. 이때, 이 방향이 인류를 위해 조금도 도움이 되지 않는다고 강하게 확신이 들었다.그래서, 간디의 말에 더욱 귀를 기울였다. '믿음과 생각.' 이 근본적인 단계에 접근하는 것을 목표로 정했다.평범한 사람의 잠재성도 끌어낼 수 있고 더 나아가 그것 자체로 사람들이 자신의 한계를 넘어선 가치를 만들 수 있는 도구를 만들자. 그들이 평소 내지 못할 법한 생각도 낼 수 있게 만드는, 그런 도구를 만들자.루트번스타인의 '생각의 탄생'을 다시 읽어보기 시작했고 아인슈타인이나 다빈치 등 천재들이 사고하는 방식에 대한 중요한 내용이 담긴 책 초반 부분을 소프트웨어로 옮기기 위해 설계를 시작했다. 위대한 업적을 남긴 사람들은 '개인'이었고 그들은 관리의 대상이 아니었다. 그리고 그들이 사고하는 방식에는 일정한 패턴이 있었는데 그것은 매우 조직화된 사고방식이 아닌 방사형 사고방식을 갖고 있었다는 것이었다. 간단한 예로, 싸이월드를 꾸밀 때의 창의성은 페이스북을 시작한 순간 사라졌다. 배경음은 무엇으로 할까, 다이어리엔 무엇을 쓸까? 아바타는 뭘 입고 있을까. 어디에 꾸며놓을까. 대문글은 비밀글로 할까? 방명록은 비밀글로 할까? '비밀로 써줘~' 멘트는 무엇으로 쓸까? 이런, 우리의 크고 작은 창의적인 수많은 고민들은 어디로 갔을까? 사람들이 '어떻게 느낄지'에 대해 깊이 고민하며, 첫사랑에 빠진 초등학생의 창의성까지도 끌어냈던 우리의 과거는 어디 간 걸까? '개인'이라는 인간 자체의 의미는 '페이스북'이라는 거대한 집단 속으로 들어가 개성을 잃고 그저 거대한 네트워크 속, 한 줄의 DB로 영원히 전락한 것일까?비캔버스는 그러한 고민을 하게 만드는 도구로 만들기로 결심했다. 링크를 단순히 즐겨찾기 할 때도, 별 모양 하나를 눌러 어디에 저장되는지도 모르고 Keep 해놓는 것이 아니라, 자신의 감성과 생각에 맞게 자유롭게 배치하고, 그것을 배치하기 위해 고민하게 만들었다. 자신의 생각, 자신의 관념을 시각화할 수 있는 툴. 하지만 개념적으로 어렵지 않게 파워포인트와 매우 유사한 사용성을 가진 직관적인 툴. 그것이 우리의 방향이 됐다. 대충 만들었지만, 정성과 미묘한 감성이 느껴지지 않는가?이 글을 쓸 때도, 비캔버스로 초안을 잡았다. 내 생각을 포스트잇에 마음껏 적어 뿌려놓고 순서를 배열해보면서 어떤 순서가 나을지를 고민했다. '관리되고 있는 나'에 집중하는 것이 아닌 '생각하고, 일하고, 아이디어를 내는 나'에 온전하게 집중할 수 있는 툴을 만드는 것을 목표로 한 순간, 모든 것이 명확해졌고 일에 속도감도 생기고 재미도 붙었다. 하지만 함께 일하는 협업 툴로 쓰기 위해서는 나의 세계에만 흠뻑 빠져있는 것이 아니라, 다른 사람들에게 내 생각이 담긴 캔버스를 공유했을 때도 누구나 이해하기 쉽고 그 정성이 느껴져야만 한다. 그것을 디자인적으로 풀기 위해 노력해왔다. 위 캔버스를 만드는데 약 1분 30초가 걸렸다. 정확히 구조적인 텍스트로 풀어보자면, 유튜브 영상 2개, 웹 링크 1개, 이미지 7개, 포스트잇 3개가 들어갔다. 하지만 저 캔버스 안에는 단순한 텍스트로 표현할 수 없는 뭔가가 느껴진다. 정보를 모으고 그룹화하는 사람의 심리와 그 정성! 제 아무리 싸이월드를 못 꾸미는 사람의 홈피에 들어가도 그 사람의 정성이 느껴질 수밖에 없듯 말이다. 그리고 그 정성이 담긴 캔버스는 한눈에 직관적으로 이해될 수 있다. 파워포인트와 크게 다르지 않기 때문이다.지금 이 순간, '흠... 비캔버스라... 재미는 있는데, 딱히 필요는 없겠네. 비즈니스 모델이 뭐지?'라고 생각하고 있는 사람들이 있을 것이라 확신한다.그런데 나는 앞으로의 도구는 이러한 방향이 아닐까 진지하게 고민해본다. 도구는 서비스와 다르기 때문에 먼저 가치를 주고 그 가치를 고객이 강하게 받아들이는 역방향의 사업 진행이 가능하다고 판단했다. 비타민과 진통제의 비유를 역으로 들어보자면 지금의 사업개발 풍토라면 사람들은 비타민을 만들지도 않았을 것이고 아무도 먹어볼 수 없다. 비타민을 만들겠다고 말한다면, 사람들이 사업을 할 줄 모른다며 다른 마약성 진통제를 개발하라고 할지도 모른다. 물론 비타민이 필요하다고 말하는 '니즈'는 강하지 않을 것이다. 누구나 돈 되고 니즈 명확하고 시장이 검증된 진통제만을 만들 것이고 결국 우리 인류는 비타민 부족으로 각종 질병에 시달려 명확한 '시장'과 '니즈'가 생길 때까지 비타민을 만나지 못할 것이다.피아노는 어떤가? 피아노를 왜 만드나? 악기를 왜 만드나? 그게 돈 되나? 누가 사나? 피아노라는 도구가 없었다면 모차르트도 베토벤도 쇼팽도 아무도 없다. 더 무서운 것은 우리 인류가 그것에 대한 불편이나 적막함을 전혀 느끼지 못했을 것이라는 것이다. 적막한 세상 속에 살면서도 우리 인류는 그 세상이 적막한지도 모르는 채 살아갔을 것이다. 자본주의의 가장 큰 약점이 여기 있다고 본다. 당장 가시적으로 돈이 보이는 곳이 아니면 누구도 모험을 하지 않는다. 말을 조금 바꾸면 니즈가 없으면 제품도 없다. 인류는 모든 정답과 자신의 욕망, 필요성을 명확히 인지하고 주머니 바깥으로 돈을 빼놓고 기다려야만 한다. 그러면 기업가들이 제품을 만들어 줄 것이다. 세상을 바꾸는 것은 단순한 니즈가 아니다. 자본주의 사회에서 니즈란 돈을 뜻하는데 우리 인류가 살아가는 이유가 돈이 아니다. 주객이 전도되면 안 된다. 그래서, 나에게 가장 무서운 말은 '위대한 생각이고 뭐고 그딴 거 필요 없을 것 같은데. 비타민 말고 진통제 같은 걸 만들어야지, 당신은 진짜 사업 초짜군요!'가 아니다. 그런 이야기를 들을 때마다 인생의 덧없음과 인류를 위해 온전하게 걸어야 할 길에 대해 진지하게 고민해보지 않은 사람이라고 밖에 생각이 안 든다. 우리에게 매우 중요한 순간은 '필요 없을 것 같은데'가 아니라 진짜 필요 없을 때다. 그것이 우리의 실패를 의미한다.'비캔버스 한 달 써봤는데, 너무 쓸모가 없어서 그냥 안 쓰기로 했어요'이 얼마나 공포스러운 말인가? 익숙하지 않은 제품을 의식적으로 쓰기 위해 노력했음에도 쓸모가 없다고 판단을 내릴 정도로 끔찍한 제품을 만들었다니... 이것이 컨저링 2보다도 무서운 진정한 공포다. 하루 종일 도구만 만드는 사람들에게 너무나도 가혹하면서도 강한 자극을 줄 수밖에 없다.다행히, 비캔버스의 고객은 어느새 3만 명이 넘어가고 있고 매일 아침만 되면 사용자들이 들어와 자신만의 비주얼 세계를 구축하기 시작한다. 정말 아름다운 순간이다. 밤에는 북미와 남미에서 유저들이 들어와서 무언가 프로젝트를 진행한다. 가슴이 벅차다는 말은 이럴 때 쓰는 것이 아닐까 심각하게 고민해본다.비캔버스를 이용해 보면 알겠지만, 우리는 고객지원을 장인(개발자)이 직접 하고 있다. 그 이유는 매우 간단한데, 개발자는 개발에 집중을 하다 보면 그저 텍스트로만 이뤄진 제품이 실제 살아 숨 쉬고 그것과 고객과 만나는 생명력을 갖는다는 것을 이해하기 힘들다. 버그가 생기면 버그를 고쳐야겠다는 생각만 가득하지, 그것을 왜 고쳐야 하는지 등에 대한 고민을 하기 힘들기 마련이다. 이 때문에 장인이 직접 고객지원을 함으로써 고객은 자신이 요구한 피드백이나 문제점을 빠르게 해결할 수 있고 장인은 제품이 실제 살아 숨 쉰다는 것을 지각하는 것은 물론 자신이 만든 제품에 대한 사명감과 자부심이 깊어진다.한 가지 더 이득이 있다면, 나도 한 때 개발을 할 때 느꼈지만 개발자들이 Java, Javascript나 Objective-C와 같은 언어에 집중을 하다 보면 인간의 언어로 소통을 하는데 큰 어려움을 겪기 마련이다. 이것이 바로 기계와 인간의 주객이 전도된 대표적인 비극이 아닐까 싶다. 우리 장인들도 고객지원 초기에는 인간의 언어를 구사하는 것에 큰 어려움을 느꼈다. 하지만, 이제는 인간의 언어를 자연어처럼 자유롭게 구사하며 감성을 가진 개발자로서 그 영역을 넓혀가고 있다. 이처럼, 장인의 직접적인 고객지원은 장인정신을 강화하는데도 매우 중요한 역할을 해왔다.도구를 만드는 많은 장인들처럼, 우리 또한 장인정신을 갖고 서비스를 만들고 있다.우리는 협업 툴과 생산성을 넘어선 도구를 만들고 있고, 앞으로도 계속 그럴 것이다. 화이트보드와 마인드맵이 우리의 생각의 폭을 넓혀주는 것처럼, 우리는 그런 도구를 만들고 싶다. 사람들이 자신의 한계를 초월한 가치를 폭발적으로 만들어낼 수 있게 돕는 도구. 인류의 발전적 미래를 고민했을 때 우리의 사업, 우리의 서비스와 그 방향이 일치하는 그런 길을 걷고 싶다.그러한 뜻과 사명이 없다면 조그마한 위기나 상처에도 굴복하고 포기할 것 같다. 수많은 위기를 지금 우리 회사의 장인들과 함께 견뎌왔고 앞으로도 견딜 것이다. 그것을 견디고 우리가 장인정신을 갖게 해주는 비결이 바로 위와 같은, 인류의 발전적 미래를 향한 방향과 우리의 사업적 방향이 일치한다는 그러한 사명의식에서 나온다.사람들의 가치를 끌어올려주는 도구를 만드는 길. 그것이 가시적으로 드러나는데 조금 시간이 걸리더라도 차근차근 조바심 내지 않고 그것을 달성하는데 온 집중을 다할 것을 진심으로 다짐해본다. 비캔버스는 웹사이트 beecanvas.com 에서 만나볼 수 있으며, 아이폰, 아이패드를 위해 아름답게 디자인된 앱을 앱스토어에서 만나볼 수도 있다.고객님들의 위대한 생각과 성과를 위해 어지러운 세상 속에서도 언제나 파이팅할 것을 약속드린다. 마지막으로 아인슈타인의 명언이다.  

Instinctus Co., Ltd. 는 ‘누구나 안전하게 사랑할 권리가 있다’는 비전을 바탕으로 보다 더 건강하고 안전한 성문화를 만들어나가기 위해 노력하는 소셜벤쳐입니다. 자연에서 영감을 얻은 EVE의 로고는 나뭇잎의 잎맥을 연상시키는 그래픽을 통해 친환경성에 대한 EVE의 철학을 고스란히 담고 있습니다.What we believe누구나 안전하게 사랑할 수 있어야 한다고 믿습니다. 당연한 말일지도 모르지만, 현실은 그렇지 못할 때가 많습니다. 모르는 사이 유해물질에 노출되어온 소비자, 편견으로 콘돔을 구매하는 것조차 쉽지 않은 청소년, 타인의 왜곡된 시선 때문에 피임에 참여하기도 어려운 여성, 사랑할 권리마저 지탄 받는 성소수자까지도 – 숨기고 감추는 것은 오히려 우리를 더 해칠 뿐입니다. 청소년이든 성인이든, 여성이든 남성이든, 성소수자든 성다수자든, 장애인이든 비장애인이든, 누구나 안전하게 사랑할 권리가 있습니다.안전한 사랑은 비단 protected sex 뿐만이 아니라, 안심하고 쓸 수 있는 성분의 안전성을 의미하기도 합니다. 생식건강을 가장 먼저 생각하기에, 자연을 닮은 제품을 지향하기에, 소비자의 권리와 기업의 양심을 잃지 않기에 – 그래서 EVE는 성인용품이 아닌 섹슈얼 헬스케어(Sexual Healthcare) 브랜드 입니다.

내가 좋아하는 것을 할 것인가남이 좋아하는 것을 할 것인가내가 잘 하는 것을 만들어서 팔 것인가남이 못하는 것을 만들어서 팔 것인가내 뜻을  따를 것인가남의 뜻을 따를 것인가내가 해야 하는 일을 하면서 살 것인가남이 해야 하는 일을 하면서 살 것인가내가 시켜서 할 것인가남이 시켜서 할 것인가내가 하라는대로 할 것인가남이 하라는대로 할 것인가내 일을 할 것인가남 일을 할 것인가나를 위해 할 것인가남을 위해 할 것인가내 생각인가남의 생각인가나를 표현한 것인가남을 흉내낸 것인가내가 선택할 것인가내가 선택 받을 것인가내 인생이었나남의 인생이었나나를 위한 한 해였나남을 위한 한 해였나2017년 아듀

프로세스 모델 도출은 프로세스 마이닝의 출발점이며, 매우 유용합니다. 원본 데이터로부터 프로세스 흐름 모델을 자동으로 구성하여 실제 프로세스를 알 수 있습니다. 이렇게 도출된 프로세스 모델과 이벤트 로그를 비교하는 것이 적합도 검사(Conformance checking)입니다. 적합도는 이전에 말씀드린 정확도(Precision)와는 다른 개념입니다. 정확도(Precision)는 Underfitting을 피하여 데이터를 정확하게 설명할 수 있으나 정확도가 높을수록 프로세스 모델이 대체로 복잡해지게 됩니다. 하지만 적합도가 높다고 하여 프로세스 모델이 복잡해지는 것은 아닙니다.적합도 검사의 기본 아이디어는 프로세스 모델 위에 이벤트 로그를 재생하는 것입니다.아래 예제 모델에 이벤트 로그 a → c → e → g를 재생하여 적합성 검사를 해보겠습니다.[그림 1] 프로세스 모델 예제먼저 a 이벤트를 수행하였습니다.[그림 2] a 이벤트 수행 후다음으로 c 이벤트를 수행했습니다.[그림 3] a, c 이벤트 수행 후이벤트 로그에서는 다음에 e를 수행해야 합니다. [그림 3]을 보면 e를 수행하기 위해서는 d가 먼저 수행되어야 합니다. 하지만 실제 로그에서는 d 수행 없이 e가 수행되었기 때문에 d를 무시하고 e를 수행합니다.마지막으로 g 이벤트 수행하여 프로세스를 마칩니다.이벤트 로그 재생이 완료되면 액티비티 d에 실행되지 못한 토큰이 남아있게 됩니다. [그림 5] 이벤트 로그 재생 후 남아 있는 토큰프로세스 모델 위에 이벤트 로그를 재생하는 동안 얼마나 많은 토큰을 사용하고(이벤트 수행 횟수) 어떤 이벤트를 생략하고 추가했는지 기록합니다. 이를 통해 기록된 이벤트 로그와 모델의 적합도를 비교할 수 있습니다. 적합도가 1이면 모든 로그가 프로세스 모델에 잘 맞는다는 뜻이고, 0에 가까우면 적합도가 매우 낮다는 의미입니다.적합도 검사는 어디에 활용할 수 있을까요? 사람들이 표준 프로세스와 달리 행동하는 이유를 찾을 때 활용 가능합니다. 왜 사람들이 기존 프로세스를 벗어나는지, 벗어나는 부분에 대해서는 잘 보고되었는지 확인할 수 있습니다. 일반적인 감사(Audit and compliance) 절차에도 활용 가능합니다.다른 사례는 도출된 프로세스 모델의 품질을 측정하기 위해 활용할 수 있습니다. 여러 알고리즘을 사용하여 프로세스 모델을 도출했을 경우 어떤 모델이 가장 적합하고 좋은 모델인지 비교해 볼 수 있습니다.마지막으로 프로세스 설명이 제대로 되어 있는지 실제 행동을 기반으로 확인할 수 있습니다. 예를 들어 어떤 서비스를 제공하는 경우 서비스 실행 방법 매뉴얼과 실제로 제공되는 서비스를 비교하여 일치하는지 확인할 수 있습니다.※ 본 블로그에 사용된 그림은 Van der Aalst 교수님 강의자료를 사용하였습니다.#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트

디자이너란 사람들은 참으로 다양한 개성은 지닌 새럼입니다. 숨길 수 없는 어떤 세계가 가득하죠. 물론 일을 하는 사람이니 그것들을 잘 봉인하고 있습니다. 하지만 스멀스멀 어쩔 수 없이 흘러나오는 미지의 어떤 힘을 막기에는 역부족입니다. 저만 해도 그래요. 지금 이 글을 쓰는 시간은 정확히 밤12시05분입니다. 지금 전 화장실에 가고싶지만 참고 있습니다. 왜냐면 여기서 화장실을 가게 되면 제 손 끝의 어떤 요정님이 사라져버릴 것 같은 느낌때문이죠. 변태적 성향으로 보일 수도 있겠지만 여러분들이 좋아하는 크리에이티브함은 대부분 이러한 변태성에서 비롯됩니다. 1픽셀만 틀려도 막 소름돋는 예민함이랄지, 화장실을 참아가서 아랫배에 머무는 요정님을 지키려는 노력, 책상정리가 안되어 있으면 모든 것을 포기해버리는 강박증 등... 말이 좋아 크리에이티브지, 그 이면의 진실은 기괴할 때가 많습니다.제목에 디자이너의 종류라고 해놓으니 많은 분들이 UX디자인, 웹디자인, 편집디자인..뭐 이런 디자인영역에 대해 이야기하려나보다.....하시겠지만 그건 함정카드입니다. 우리가 알아볼 디자이너의 분류는 조금 달라야 합니다. 왜냐면 전 실무와 현장감, 디테일에 미쳐있는 디테일변태이기 때문이죠.일에는 기본적으로 지켜야할 언어와 행동과 체계가 있습니다. 디자이너가 아무리 미지의 힘을 지니고 있는 존재라고 해도 이것을 어겨서는 안됩니다. 그래서 표준 안에서 어떻게 다양한 행동들을 취하는 지 그것을 보려고 합니다. 그러고 이러한 디자이너와 어떻게 협업할 지도 생각해보도록 합시다.1. 은둔형 구석자리 디자이너(feat. 후드티)조용합니다. 하루종일 말이 없을 때도 있습니다. 입을 열어도 모기모기한 소리로 말하고 크게 의견을 막 내세우지 않습니다. 이 분들은 관찰자처럼 모든 상황을 관망합니다. 그리고 말보단 시안으로 얘기하는 타입입니다. 안듣는 것 같아도 다 듣고있으니 대답소리가 작다고 막 뭐라하면 안됩니다. 커뮤니케이션을 능숙하게 잘한다고 다 일을 잘하는 건 아니니까요. 이런 분들은 챠근챠근 일을 정리하고 깔끔하게 정리하는 걸 좋아합니다. 속도가 좀 늦고 답답해 보일 수는 있지만, 퀄리티 면에서 필살기를 보여줄 때가 많습니다.2. 이건 싫어!! 이건 좋아!! 호불호대장맥주 좋아!! 유아콘텐츠 싫어!!! 테크쪽 몰라!!! 행사 디자인 좋아!! ..이렇게 영역에 대한 호불호가 아주 분명해서 손가락 베일 것 같은 분들도 있습니다. 이런 분들은 취향도 아주 명확해서 좋아하는 디자인이 땋! 있더라구요. 그리고 그 범주 내의 프로젝트를 맡으면 각성하여 지력과 전투력이 상승합니다. 반면 노잼극혐 플젝을 주면 지연 핸디캡을 받거나 HP가 빨리 떨어지는 저주에 걸릴 수 있습니다. 그렇다고 현실적으로 일을 가려받을 순 없습니다. 그러니 노잼극혐 플젝에 합류시킬 때는 적당한 동기부여를 전달해줄 필요가 있습니다. 나중에 포폴로 활용할 수 있게 저작권을 일부 인정해준다거나.맥주와 간식으로 HP를 채워준다거나.이 다음 괜찮은 플젝으로 딜을 본다거나.용모가 수려한 팀원들로 구성을 한다거나...뭐 등등등3. 조증아이디어가 떠오르거나 맘에 드는 시안이 탄생하면 흥분을 감추지 못합니다.1시간 정도 뒤에 얘기하도록 합니다. 밥먹고 졸린 3시 정도에 다시 오라고 합시다.4. 투머치토커디자이너는 평균적으로 조용하고 자기만의 세계가 있다고 하지만, 그게 꼭 그런 것만은 아닙니다. 종종 말을 좋아하는 성향의 사람들도 있기 마련이죠. 이런 분들은 회의시간이나 시안PT때 그 광역필살기를 시전합니다. '이 시안으로 말씀드릴 것 같으면, 우선 제가 LA에 있을 때 이야기를 하지 않을 수 없는데....'로 시작된 봇물은 어느새 1,2시간이 되버리고 말죠. 이렇게 넘나 말이 많은 것이 꼭 좋은 것은 아닙니다. 뭐든 과유불급이죠. 적당히 중간에 자르고 핵심만 얘기하라고 합시다. 핵심이란 건 이런 거예요. 이 디자인이 어떤 의도와 어떤 철학, 스토리, LA이야기를 담고있는지는 사실 중요치 않습니다. 그건 브랜드가이드에 몇 줄이면 될 사연들이죠. 중요한 건 이걸 보는 사람은 누구고그 사람들에게 이 시안이 어떤 행동(또는 사고,감정)을 유발시키는지.이 2개예요. 그것만 짧게 얘기하라고 합시당. 5. 픽셀장인책상도 일렬종대, 마우스와 키보드는 무선, 포스트잇 하나없이 깔끔하고 정돈된 걸 좋아하는 분도 있습니다. 약간의 오차나 틀어짐도 용납하지 못하는 픽셀변태들이죠. 마트에 가서 정돈된 과일을 보면 이너피스를 얻는 부류입니다. 이런 분들과 일할 때는 생각보다 난관이 많습니다. 사실 손의 빠르기에 따라 일속도는 천차만별이지만 퀄리티는 항상 완벽을 추구하기 때문에 스트레스는 매한가지입니다. 오래 일을 잡고있으면 그만큼 피곤해지고, 빨리하면 빨리해야하니까 또 스트레스..그래서 이런 픽셀장인님들은 센서티브한 성향이 있습니다. 크릉거리기도 하고 으르렁대기도 하고 뭐 그렇습니다. 업무분장을 할 때 프론트 엔드를 나눌 수 있다면 이런 분들은 엔드작업에 배치하면 좋습니다. 6. 탱커타입반면에 그냥 밀어부치는 거친 탱커타입의 전사도 있습니다. 빠른 시안! 대충 챡챡!! 이런거요? 샥샥 이거요? 이렇게요? 하면서 순식간에 진도를 촥촥 빼는 부류죠. 최대장점은 역시 속도와 실행력입니다. 고민보다 손이 앞서는 타입인지라 기획회의 하면서도 바로 시안을 대강 만들어서 '이런 거 말씀하시는 거예요?' 라고 보여주기도 합니다. 하지만 단점도 존재하죠. 종종 실수가 생기거나, 빠른 속도를 활용해서 양으로만 밀어부치거나 하는 등의 문제가 생길 수도 있습니다. 이러한 탱커타입은 프론트단계에서 시안을 빠르게 나열하고 선택, 디벨롭 시켜야 하는 시기에 적절합니다.7. 멀티플레이어분명 디자이너인데 마케팅도 알고있고, 데이터도 다룰 줄 알고 퍼블리싱도 하고 기획력도 있는데다가 맛집도 잘 알고 있고 경영도서도 곧잘읽고, 시사지식까지 뛰어난 하이엘프들도 있습니다. 이들은 귀는 둥글지만 그에 맞먹는 민첩과 순발력이 쩔죠. 그래서 이런저런 방면의 인사이트로 소비자행동을 관찰하고 적절한 문제해결능력을 보여줍니다. 막 주변에선 오오오..능력쨔아! 여윽시! 와 같은 감탄사가 튀어나옵니다. 사실 이런 분들은 자기가 잘난 걸 알고있습니다. 그래서 부끄러워하지만 그런 인정을 좋아라하죠. 배움에 대한 호기심과 인정욕구가 있어서 살짝살짝 어려운 과제를 던져주면 동기부여를 느끼곤 각성합니다. 오히려 너무 쉽고 단순한 일에 지쳐버리는 타입이랄까요.8. 눈표범고독한 늑대와 같은 타입이죠. 멀티플레이어와는 반대성향입니다. 하나에만 겁나 집중하고 나머지엔 신경을 안써요. 그래서 보통 업무에 열중하면 다른 것을 동시에 하지 못합니다. 이런 분들은 딱! 특정한 일을 맡기는 게 좋아요. 100개의 콘텐츠카드를 만들어!, 상세페이지 템플릿 만들어!, 이거 지도 이미지 제작해줘! 이렇게 혼자 끝낼 수 있는 1인1업무가 적절합니다.9. 손그림장인아티스트 성향과 디자이너 성향이 반반 섞인 데미갓입니다. 회화전공자였을 수도 있고 원래 그림을 좋아할 수도 있습니다. 손그림 아트웍을 곧잘 만들어냅니다. 아기자기한 성향이나 또는 프랑스 만화같은 독특한 자기세계가 있을 수도 있습니다. 대부분 강력한 예술적 차크라를 숨기면서 살지만, 종종 새벽이 되면 폭발할 수 있습니다. 새벽 이전에 퇴근해야 합니다.10. 아이소메트릭능력자노가다에서 쾌감을 느끼는 장인입니다. 손목연골이 빨리 닳을 수 있으니 보호대가 필요합니다.11. 레이어정리집착증인수인계 받는 사람에게 축복이 있을지니. 12. 파일이름작명가개발자들의 사랑을 그대 품안에.13. 간식대마왕디자인은 많은 두뇌활동을 필요로 합니다. 두뇌는 당과 케톤체로 움직입니다. 당은 말그대로 포도당의 당분해로 충전되고, 케톤체는 지방분해를 통해 생성됩니다. 그래서 우린 달달한 것과 기름진 고기를 먹어야 합니다. 14. 소심한 타입자꾸 자긴 디자인을 못한다고 수줍어서 양쪽 검지를 만지작 거립니다. 흔히 엄지나 검지 손톱 옆 살을 뜯거나 손톱을 깨물깨물하기도 합니다. 근데 지는 못했다고 해서 가보면 엄청 잘해놨을 경우가 많습니다. 놀리는건가...보통 이런 분들의 '제가 잘..못해서....' 라는 말은 '기분은 못할 것 같은데 이미 내 몸은 만렙이다.' 는 소리와 비슷합니다.15. 투덜이스머프뭐만 하면 이건 안되고 저건 안되는 타입도 있습니다. 공격력이 현저하게 높아서 일단 일이 많아지는 걸 극딴적으로 싫어합니다. 까칠하고 까다로워서 사람들이 어려워하는 부류긴 하지만 츤데레기질도 있어서 투덜대면서도 또 급한 건 해줄때가 많습니다. 하지만 진짜 투덜만 대고 일도 안하고 솔루션도 없다면 음.... 문제가 좀 있죠?16. 머리가 손을 지배하는 타입디자이너라고 하면 막 감성충만한 파랑새가 마음속에 날아다닐 것 같지만...의외로 그렇지 않습니다. 꽤나 기능과 논리를 중요하게 생각하는 분들이 많습니다. 디자인은 목적성과 목표가 뚜렷하기 때문에 더 그런 것 같습니다. 그래서 생각보다 논리와 상식적인 알고리즘을 중요하게 생각하는 분들이 많아요. 이런 부류 중에선 본인이 납득이 가지 않으면 손이 움직이지 않는 분들도 계시죠. 설득시키기가 난감할 때가 있지만, 한번 설득되면 또 무슨 휴머노이드마냥 일을 하기도 합니다. 17. 광전사승부욕 폭발하는 타입입니다..... 주변에 있는 능력자들을 다 뛰어넘고 인정받고 싶은 욕구가 온몸에 열기처럼 불타오릅니다. 가끔 모든 사람을 이겼다 싶으면 어제의 자신과 싸웁니다. 더 강해져야해!!!! 슈퍼파워가 있었다면 지구최강의 빌런이 되었을지도...일을 시키는 입장에선 막 능력자같고 세상 애사심이 넘치는 사람같아 보이지만 이 광전사 버프가 끝나고 나면 번아웃이 와버리기도 합니다. 자기관리가 필요합니다. 보통 이런 광전사모드일 때는 몸이나 마음을 돌보지 않고 일을 하거든요. 뭐..사실 말린다고 말려지지도 않습니다. 시간이 지나야 하죠...18. 환자손목터널증후군, 일자목, 거북목, 척추측만, 골반틀어짐, 위경련, 위궤양, 대장염, 안구건조증, 허리디스크, 고관절통증, 성인여드름, 소화불량, 가스차고 더부룩, 원형탈모, 이유없는 두통, 불면증....19. 독립운동가프리랜서를 꿈꾸는 부류입니다. 언젠간 내 것을 할꼬야!!! 라는 굳은 의지가 있어요. 하지만 아직 돈이 없어서 레퍼런스를 쌓고있는 타입이죠. 일을 하면서 투잡을 뛰는 경우도 있어요. 본인이 스스로 의뢰받아서 클라이언트 비즈니스도 하고 회사일도 하는거죠. 종종 회사에서 연봉많이 못 줄때 이렇게 겸업을 허락하는 곳도 있더라구요. 독립의지가 강해서 일을 배우고자 하는 열정이도 있습니다. 이래서 일잘하고 똘똘한 사람들은 다들 나가서 회사차린다는게 이런 말입니다.20. 야망의 바다DISC검사하면 D성향이 극단적으로 높은 스타일. 숨길 수 없는 리더쉽과 승진욕망이 있는 부류입니다. TF팀이나 프로젝트 리더 맡는 걸 막 좋아해버리고 뭔가 조정하고 조율하고 디렉션하길 좋아합니다. 네임밸류있는 큰 플젝를 선망하기도 하고, 얼른 선임달고 주임달고, 수석되서 마인드컨트롤 풀업을 꿈꾸기도 합니다. 내면의 칼갈이들이죠. 부작용이 생기면 직급놀이에 심취해버리기도 하지만, 리더로써의 인성과 자질이 동반될 경우엔 연차에 상관없이 업무 전체의 밸런스를 맞추고 카리스마있게 프로젝트를 이끌어나가는 군주가 되기도 합니다.