비트윈에서는 서비스 초기부터 HBase를 주요 데이터베이스로 사용하였습니다. HBase에서도 일반적인 다른 NoSQL처럼 트랜잭션을 제공하지 않습니다. HBase, Cassandra와 MongoDB는 하나의 행 혹은 하나의 Document에 대한 원자적 연산만 제공합니다. 하지만 여러 행에 대한 연산들을 원자적으로 실행할 수 있게 해주는 추상화된 트랜잭션 기능이 없다면 보통의 서비스 개발에 어려움을 겪게 됩니다. 비트윈 개발팀은 이런 문제를 해결하기 위해 노력했으며, 결국 HBase에서 트랜잭션을 제공해주는 라이브러리인 Haeinsa를 구현하여 실제 서비스에 적용하여 성공적으로 운영하고 있습니다. VCNC에서는 Haeinsa를 오픈소스로 공개하고 이번 글에서 이를 소개하고자 합니다.Haeinsa란 무엇인가?Haeinsa는 Percolator에서 영감을 받아 만들어진 트랜잭션 라이브러리입니다. HAcid, HBaseSI 등 HBase상에서 구현된 트랜잭션 프로젝트는 몇 개 있었지만, 성능상 큰 문제가 있었습니다. 실제로 서비스에 적용할 수 없었기 때문에 Haeinsa를 구현하게 되었습니다. Haeinsa를 이용하면 다음과 같은 코드를 통해 여러 행에 대한 트랜잭션을 쉽게 사용할 수 있습니다. 아래 예시에는 Put연산만 나와 있지만, 해인사는 Put외에도 Get, Delete, Scan 등 HBase에서 제공하는 일반적인 연산들을 모두 제공합니다.HaeinsaTransaction tx = tm.begin(); HaeinsaPut put1 = new HaeinsaPut(rowKey1); put1.add(family, qualifier, value1); table.put(tx, put1); HaeinsaPut put2 = new HaeinsaPut(rowKey2); put2.add(family, qualifier, value2); table.put(tx, put2); tx.commit(); Haeinsa의 특징Haeinsa의 특징을 간략하게 정리하면 다음과 같습니다. 좀 더 자세한 사항들은 Haeinsa 위키를 참고해 주시기 바랍니다.ACID: Multi-Row, Multi-Table에 대해 ACID 속성을 모두 만족하는 트랜잭션을 제공합니다.Linear Scalability: 트래픽이 늘어나더라도 HBase 노드들만 늘려주면 처리량을 늘릴 수 있습니다.Serializability: Snapshot Isolation보다 강력한 Isolation Level인 Serializability를 제공합니다.Low Overhead: NoSQL상에서의 트랜잭션을 위한 다른 프로젝트에 비해 오버헤드가 적습니다.Fault Tolerant: 서버나 클라이언트가 갑자기 죽더라도 트렌젝션의 무결성에는 아무 영향을 미치지 않습니다.Easy Migration: Haeinsa는 HBase를 전혀 건드리지 않고 클라이언트 라이브러리만 이용하여 트랜잭션을 구현합니다. 각 테이블에 Haeinsa 내부적으로 사용하는 Lock Column Family만 추가해주면 기존에 사용하던 HBase 클러스터에도 Haeinsa를 쉽게 적용할 수 있습니다.Used in practice: 비트윈에서는 Haeinsa를 이용하여 하루에 3억 건 이상의 트랜잭션을 처리하고 있습니다.Haeinsa는 오픈소스입니다. 고칠 점이 있다면 언제든지 GitHub에 리포지터리에서 개선에 참여하실 수 있습니다.Haeinsa의 성능Haeinsa는 같은 수의 연산을 처리하는 트랜잭션이라도 소수의 Row에 연산이 여러 번 일어나는 경우가 성능상 유리합니다. 다음 몇 가지 성능 테스트 그래프를 통해 Haeinsa의 성능에 대해 알아보겠습니다.아래 그래프는 3개의 Row에 총 6개의 Write, 3개의 Read연산을 수행한 트랜잭션의 테스트 결과입니다. 두 개의 Row에 3Write, 1Read 연산을 하고, 한 개의 Row에 1Read 연산을 한 것으로, 비트윈에서 가장 많이 일어나는 요청인 메시지 전송에 대해 시뮬레이션한 것입니다. 실제 서비스에서 가장 많이 일어나는 종류의 트랜잭션이라고 생각할 수 있습니다. 그런데 그냥 HBase를 사용하는 것보다 Haeinsa를 이용하는 것이 더 오히려 좋은 성능을 내는 것을 알 수 있습니다. 이는 Haeinsa에서는 커밋 시에만 모든 변경사항을 묶어서 한 번에 반영하기 때문에, 매번 RPC가 일어나는 일반 HBase보다 더 좋은 성능을 내는 것입니다.HBase 클러스터가 커질수록 트랜잭션 처리량이 늘어납니다. HBase와 마찬가지입니다.HBase 클러스터의 크기에 따른 응답시간 입니다. HBase와 다르지 않습니다..아래 그래프는 2개의 Row에 각각 한 개의 Write, 나머지 한 개의 Row에는 한 개의 Read 연산을 하는 트랜잭션에 대해 테스트한 것입니다. 각 Row에 하나의 연산만이 일어나기 때문에 최악의 경우라고 할 수 있습니다. 처리량과 응답시간 모두 그냥 HBase를 사용하는 것보다 2배에서 3배 정도 좋지 않은 것을 알 수 있습니다. 하지만 이 수치는 DynamoDB 상의 트랜잭션과 같은 다른 트랜잭션 라이브러리와 비교한다면 상당히 좋은 수준입니다.HBase보다 처리량이 떨어지긴 하지만, 클러스터가 커질수록 처리량이 늘어납니다.HBase보다 응답시간이 크긴 하지만 클러스터 크기에 따른 변화가 HBase와 크게 다르지 않습니다.프리젠테이션Haeinsa에 대한 전반적인 동작 원리와 성능을 소개하는 프리젠테이션입니다. 좀 더 자세히 알고 싶으시다면 아래 프리젠테이션이나 Haeinsa 위키를 참고해주세요.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/2d4b2bd00fc201314ae312fe4cd13937?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">

블로그에 새 글이 올라올 때, naver에 사이트 등록을 한다. 네이버 신디케이션 API를 이용하면 자동으로 등록된다.Wordpress에는 네이버 신디케이션 plugin이 존재한다. Rails gem을 찾아보니 애석하게도 없었다. 직접 만들면서 알게 되었다. 딱히 gem을 만들 만한 일도 아니더라.네이버 신디케이션을 이용하려면 우선 네이버 웹마스터 도구를 이용해야 한다. 해당 url이 자기 것이라는 인증과정만 거치면 바로 사용할 수 있다.작동방법은 대강 이렇다.네이버 신디케이션 API를 이용해서, 새로운 글이 생성되었음을 알린다. (혹은 글이 지워졌음을)네이버 크롤링 봇, Yeti가 와서 크롤링 해간다.API를 이용할 때 미리 약속된 format으로 만들어야 되는데, ATOM feed와 구조가 거의 같다. 다만 네이버가 정한 룰 때문에 (꼭 이름/저자/업데이트날짜 이런 순서를 지켜야 한다.)Rails에서 제공하는 atom_feed helper를 그대로 이용할 수 없다. 그러나 format만 살짝 바꾸면 되기 때문에 atom_feed helper를 이용해서, feed를 만드는 방법을 알려주는 Railscast가 늘 그렇듯 엄청 도움이 된다.(요즘 새로운 episode가 안올라오고 있는데… 힘내시라는 의미에서 예전에 유료결제 해드렸다)atom_feed helper의 코드를 그대로 가져와서 formating만 바꾼 naver_atom_feed helper를 만들었다. 별다른 건 없고, feed option 초기화 부분과 제일 마지막에 나와야 되는 link 부분을 주석처리한게 전부다.module NaverSyndicationHelper def naver_atom_feed(options = {}, █) ... feed_opts = {} //feed_opts = {"xml:lang" => options[:language] || "en-US", "xmlns" => 'http://www.w3.org/2005/Atom'} ... xml.feed(feed_opts) do xml.id... // xml.link... // xml.link... yield ActionView::Helpers::AtomFeedHelper::AtomFeedBuilder.new(xml, self, options) end end end새로만든 naver_atom_feed helper를 이용해서, feed부분만 완성한 code이다.naver_atom_feed({xmlns: "http://webmastertool.naver.com", id: 'http://ikeaapart.com'}) do |feed| feed.title "이케아아파트" feed.author do |autor| autor.name("이케아아파트") end feed.updated Link.maximum(:updated_at) feed.link(:rel => 'site', :href => (request.protocol + request.host_with_port), :title => '이케아아파트')이제 entry쪽을 만들어야 되는데, 네이버가 지정한 순서에 맞아야지만 신디케이션 서버에 전달할 수 있다. 정말 이상한 형식이다. 아무튼 그래서 Rails에서 제공하는 entry method를 사용하지 못한다. 이번엔 AtomFeedBuilder class에 naver_entry method를 만들었다.#config/initializers/feed_entry_extentions.rbmodule ActionView module Helpers module AtomFeedHelper class AtomFeedBuilder def naver_entry(record, options = {}) @xml.entry do @xml.id... # if options[:published]... # @xml.published(...) # end # if options[:updated]... # @xml.updated(...) # end # @xml.link(..) ...이번에도 순서 때문에 주석처리 한 것 밖에 없다. naver_entry method를 이용해서 완성된 코드가 아래 코드이다.# views/links/show.atom.buildernaver_atom_feed({xmlns: "http://webmastertool.naver.com", id: 'http://ikeaapart.com'}) do |feed| feed.title "이케아아파트" feed.author do |autor| autor.name("이케아아파트") end feed.updated Link.maximum(:updated_at) feed.link(:rel => 'site', ...) feed.naver_entry(@link, {id: link_url(@link)}) do |entry| entry.title(@link.title) entry.author do |author| author.name("이케아아파트") end entry.updated(@link.updated_at.xmlschema) entry.published(@link.created_at.xmlschema) entry.link(:rel => 'via', :href => (request.protocol + request.host_with_port)) entry.content(@link.contents) end end이제 새 글이 만들어 질 때, 이 atom 파일 주소를 네이버 신디케이션 API로 보내주면 된다. 참고로 Rails에서는 어떤 view파일을 사용할지 알아서 해주니, controller에 따로 ‘response_to’ 를 이용해서 format을 나눠줄 필요는 없고, 이름만 잘 맞춰주면 된다. (위 파일명은 show.atom.builder 이다)네이버 신디케이션 API에 핑을 보내는 code이다. 네이버가 지정해 놓은 header를 설정해 줘야 되고, 신디케이션 인증 토큰을 받아서 header에 넣어줘야 된다. 신디케이션 토큰은 네이버 웹마스터 페이지에서 볼 수 있다.require 'net/http' ... header = {"User-Agent"=>"request", "Host"=>"apis.naver.com", "Progma"=>"no-cache", "Content-type"=>"application/x-www-form-urlencoded", "Accept"=>"*/*", "Authorization"=>"Bearer " + ENV["NAVER_SYNDICATION_TOKEN"]} uri = URI.parse('https://apis.naver.com/crawl/nsyndi/v2') http = Net::HTTP.new(uri.host, uri.port) http.use_ssl = true args = {ping_url: link_url(link_id, format: "atom")} uri.query = URI.encode_www_form(args)request = Net::HTTP::Post.new(uri.request_uri, header) http.request(request)네이버 신디케이션 페이지에서 핑이 제대로 도달하는지 바로 확인해 볼 수 있다.#티엘엑스 #TLX #BA #BusinessAnalyst #비즈니스애널리스트 #꿀팁 #인사이트 #조언

우리는 고객이 무엇에 관심 있어 하고 무엇에 관심 없어하는지, 어떤 것을 보았을 때 클릭해 들어가고 어떤 것을 보았을 때 사이트에서 이탈하는지 궁금해 합니다. 이러한 정보를 얻기 위해 봐야 할 것은 역시 웹서버의 접속 로그입니다.처음에는 매일 생성되는 로그 파일을 일일이 파싱해서 원하는 정보를 DB에 쌓는 방법을 이용했지만, 이러한 방식은 한계가 있었습니다. 저장할 수 있는 데이터의 양에 심각한 제한이 있었고, 따라서 처음에 얻고자 했던 데이터 이상의 것을 새로 추출할 수도 없었습니다.그래서 지금은 웹서버 로그를 하둡(Hadoop) 클러스터에 쌓고 있습니다. Google Analytics 같은 외부 분석툴을 사용하기도 하지만, 아무래도 데이터를 우리 손에 직접 들고 있는 것이 더 유연한 분석을 제공할 수 있지요. 클러스터에서 로그를 분석하려면 가장 먼저 로그 수집 시스템을 만들어야 합니다.이번 포스팅에서는 이 로그 수집 시스템이 어떻게 만들어져 있는지, 그리고 그보다 더 중요한 시스템의 모니터링을 어떻게 하고 있는지 설명하려고 합니다.Flume 에이전트 설정하기Apache FlumeApache Flume은 로그와 같은 데이터의 흐름(streaming)을 제어할 수 있게 해주는 도구입니다. 단순하면서도 확장성 높은 구조로 되어 있기 때문에 많은 시스템에서 채택하는 도구가 되었고, 리디북스에서도 Flume 을 사용하게 되었습니다.Flume 의 기본 구조는 단순합니다.기본적인 에이전트 구성 (이미지 출처: Apache Flume 홈페이지)에이전트(agent)는 Source, Channel, Sink 로 이루어진 자바 프로세스이다.소스(source)는 외부에서 이벤트를 입력받아 채널(channel)로 전달하고, 채널은 이벤트를 저장하고 있다가 싱크(sink)로 전달한다. 싱크는 이벤트를 외부로 출력한다.한 에이전트의 Sink와 다른 에이전트의 Source가 같은 타입이면, 에이전트 간에 이벤트를 전달할 수 있다.굉장히 간단하지만 강력한 모델입니다. Flume 은 Avro, Thrift, Exec, HDFS, Kafka 등 다양한 라이브러리를 적용한 소스와 싱크를 미리 제공하고 있기 때문에, 사용자는 자기 입맛에 맞게 이를 조합해서 시스템을 구성할 수 있습니다.예를 들면 아래와 같습니다.좀 더 복잡한 에이전트 구성 (이미지 출처: Apache Flume 홈페이지)초기 에이전트 구성: Avro를 통해 클러스터에 로그 전송저희가 맨 처음 설정한 Flume 에이전트의 구성은 다음과 같습니다.초기 에이전트 구성각 웹서버ExecSource: exec 명령으로 실행된 프로세스의 표준 출력을 이벤트로 입력받음. (tail -F <로그파일>)MemoryChannel: 메모리상의 큐(queue)로 구현된 채널AvroSink: 클러스터에 상의 에이전트가 실행하는 Avro RPC 서버로 이벤트를 전송하둡 클러스터AvroSource: 웹서버의 에이전트가 Avro RPC 로 보내는 이벤트를 수신MemoryChannelHDFSSink: HDFS 상의 지정된 경로의 파일에 이벤트 내용을 출력각 웹서버에는 에이전트가 하나씩 실행되어서, 로그 파일에 새로 추가되는 로그를 클러스터에 전송합니다. 클러스터 상의 에이전트는 단 한 개 존재하는데, 웹서버로부터 전송받은 로그를 HDFS(Hadoop File System) 에 파일로 출력하는 역할을 합니다. 웹서버 에이전트와 클러스터 에이전트 간의 통신은 Avro RPC 로 하게 하였습니다. Flume 에서 기본적으로 AvroSource 와 AvroSink 를 구현하여 제공해 주는 것을 이용했습니다.사실은 클러스터 상의 에이전트가 Avro 서비스를 통해 데이터를 모아 주지 않고, 웹서버 상의 에이전트가 HDFSSink 를 이용해서 직접 클러스터에 파일을 쓰게 하더라도 대부분의 경우는 상관없습니다. 하지만 리디북스의 경우는 그렇게 할 수 없었는데, 왜냐하면 웹서버와 하둡 클러스터가 서로 다른 네트워크 상에 있기 때문입니다.리디북스의 웹서버는 국내 IDC에 존재하지만 하둡 클러스터는 Miscrosoft Azure 클라우드 내의 가상머신으로 실행되고 있습니다. 따라서 하둡의 네임노드(namenode)가 인식하는 각 노드의 사설 IP 주소를 웹서버들이 쉽게 접근할 수 없습니다. 이를 우회하는 다양한 방법을 시도해 보았지만 최종적으로는 Avro 서비스를 중간에 두어 해결하였습니다.모니터링 알람 설정하기JSON 리포팅 사용다음은 에이전트 프로세스를 모니터링하는 문제가 있었습니다. 예기치 않은 에러로 에이전트가 종료되어서 로그가 수집되지 않고 있는데 며칠 동안 모르고 있어서는 안되겠지요.Flume 에서는 모니터링 인터페이스도 여러가지를 제공하고 있는데, 그 중 가장 이용하기 간편한 것은 HTTP 를 통한 JSON reporting 이었습니다. 에이전트 자체가 HTTP 서비스로 작동해서, 특정 포트로 요청을 보내면 에이전트의 상태를 JSON 으로 정리하여 응답을 주게 되어 있습니다. 에이전트 실행시에 옵션 몇 개만 추가하면 바로 설정할 수 있기 때문에 매우 간단합니다.Health 페이지를 이용한 모니터링그런데 이 리포팅이 제대로 나오지 않으면 어떻게 알림을 받을 수 있을까요? 각 서버마다 JSON 리포팅을 요청해서 응답이 제대로 오지 않으면 이메일을 보내는 스크립트를 만들어서 cron 으로 5분마다 실행하는 방법도 있습니다. 하지만 이 스크립트가 제대로 동작하지 않거나, 이게 실행되는 서버가 다운되면?결국 스스로를 믿지 못하고 택한 방법은 외부 서비스 Pingdom을 이용하는 것이었습니다. 단, 외부 서비스가 각각의 웹서버에 직접 접근하여 리포팅을 요청하는 방식은 보안상 문제가 될 수 있어서 아래와 같이 보완하였습니다.웹 서비스 상에 health 페이지 구현. 이 페이지는 각 웹서버의 에이전트의 JSON reporting 포트로 요청을 보내서, 결과를 종합해서 다시 JSON 으로 보여줌.모든 에이전트가 정상적으로 리포트를 보내면 {“status”: “OKAY”} 를, 아니면 {“status”: “ERROR”} 를 보여줌.이 health 페이지의 내용을 모니터링하도록 Pingdom 설정. {“status”: “OKAY”} 가 응답에 없으면 알람 메일이 오도록 함.{ "status": "OKAY", "metrics": { "192.168.0.101": { "SOURCE.log_src": { ... }, "SINK.avro_sink": { "BatchCompleteCount": 562110, "ConnectionFailedCount": 294, "EventDrainAttemptCount": 56246850, "ConnectionCreatedCount": 31, "Type": "SINK", "BatchEmptyCount": 16, "ConnectionClosedCount": 30, "EventDrainSuccessCount": 56243927, "StopTime": 0, "StartTime": 1459135471379, "BatchUnderflowCount": 610 }, "CHANNEL.mem_channel": { ... } }, "192.168.0.102": { ... } } }Health 페이지의 Json내용JSON 리포팅의 문제이렇게 설정해 놓고, 며칠간 로그가 HDFS 상에 잘 수집되는 것을 확인하고 만족해 했습니다. 그런데 며칠간 신경을 쓰지 않은 사이, 다시 에이전트를 확인해 보니 모든 웹서버 에이전트가 죽어 있었습니다. HDFS에 로그도 쌓이지 않았구요.확인해 보니, MemoryChannel 의 설정 문제였습니다. byteCapacity 값을 실수로 너무 작게 설정해서, 채널 큐가 메모리 부족으로 터져나간 것이죠. 해당 문제는 byteCapacity 값을 늘려서 간단하게 해결했습니다.문제는 알람이 오지 않았다는 것이었습니다. 문제를 재현해 본 결과, 채널이 터져서 에이전트 실행이 중단되어도, 에이전트 프로세스는 죽지 않고 ExecSource 에서 실행한 자식 프로세스(tail -F)만 죽어 있었습니다. 이렇게 되면 JSON 리포팅도 정상적으로 나오기 때문에, 결국 JSON 리포팅으로는 이런 유형의 에러를 잡지 못한다는 결론이 나왔습니다.클러스터에 모니터링 설정하기결국 웹서버상에서 모니터링하는것 보다는 데이터를 최종 전달받는 하둡 클러스터 상에서 모니터링하는 것이 안정적이라 판단하였습니다. 다행히도, 하둡 클러스터에서 사용할 수 있는 꽤나 좋은 모니터링 도구가 이미 있었습니다.CDH 의 알람 트리거리디북스에서는 기본 하둡 패키지가 아닌, Cloudera에서 제공하는 하둡 배포판인 Cloudera CDH를 사용하고 있습니다. CDH는 클러스터 상에서 사용되는 서비스마다 각종 테스트를 자동으로 실행하여, 테스트가 통과되지 않을 때마다 메일로 알람을 보내줍니다. 그리고 웬만한 필수 테스트는 기본적으로 설정되어 있지만, 사용자가 커스텀 서비스를 직접 제작할 수도 있습니다. CDH가 각 에이전트의 소스, 채널, 싱크마다 초당 전송한 이벤트 개수 등의 측정치(metric)을 모두 기록하고 있기 때문에, 이 값들이 일정 수준 이상/이하가 될 때마다 알람이 트리거되도록 설정할 수 있습니다.CDH의 알람 트리거 편집 화면웹서버마다 알람 설정하기그런데 이것으로 끝이 아닙니다. 클러스터 에이전트는 각 서버에서의 트래픽이 모두 모이는 곳이기 때문에, 여기에서 모니터링을 하는 것은 웹서버 상에서 모니터링하는 것보다 기준이 애매해집니다.10대의 웹서버 중에 한 대만 문제가 생겼을 경우, 클러스터 에이전트가 받는 트래픽은 0으로 줄어드는 것이 아니라 90%로 줄어듭니다. 알람을 트리거하는 역치(threshold)를 평소 트래픽의 90%로 잡아야 한다는 것이지요. 그런데 트래픽이라는 것이 원래 날짜와 시간에 따라 달라지기 때문에, 이 역치값을 고정된 값으로 정할 수가 없습니다. 트래픽이 높은 때를 기준으로 하면, 트래픽이 낮아지는 새벽 시간마다 가짜 알람(false alarm)이 오게 되겠지요. 그렇다고 트래픽이 낮은 때를 기준으로 하면, 트래픽이 높은 때 웹서버 에이전트가 죽더라도 새벽이 될 때까지 알 수 없습니다.결국 클러스터 단에서도 각 웹서버마다 트래픽을 구분해 주어야 한다는 결론이 나옵니다. 다행히 한 에이전트가 여러 개의 채널과 싱크를 가질 수 있고, 이벤트 헤더의 내용에 따라 소스가 어느 채널로 이벤트를 보낼지 결정해 주는 채널 셀렉터 (Channel Selector)라는 것이 있습니다.웹서버 에이전트의 소스에서는 각 이벤트 헤더에 자기 호스트명을 달아 준다. (Interceptor 는 각 이벤트에 원하는 헤더를 달아주는 역할을 한다. HostInterceptor 이용)클러스터 에이전트는 1개의 소스와, 웹서버 대수만큼의 채널 및 싱크가 있다.클러스터의 소스는 이벤트의 host 헤더를 보고 그에 해당하는 채널로 이벤트를 전달한다. (MultiplexingSelector 사용)각 채널은 자신에게 대응되는 싱크에 이벤트를 전달하고, 싱크는 각자의 HDFS 경로에 이벤트를 파일로 출력한다.최종 에이전트 구성: 채널 셀렉터로 트래픽 나누기최종적으로 나온 에이전트의 구성은 다음과 같습니다.최종 에이전트 구성그리고 에이전트 설정 파일은 아래와 같이 작성했습니다.... log_to_avro.sources.log_src.type = exec log_to_avro.sources.log_src.command = tail -F /path/to/log/file log_to_avro.sources.log_src.restart = true log_to_avro.sources.log_src.channels = mem_channel log_to_avro.sources.log_src.interceptors = ts_ic host_ic # 호스트 인터셉터 설정 log_to_avro.sources.log_src.interceptors.ts_ic.type = timestamp # 이벤트 헤더에 timestamp 삽입 (날짜별 구분을 위해) log_to_avro.sources.log_src.interceptors.host_ic.type = host # 이벤트 헤더에 호스트명 삽입 (호스트별 구분을 위해) log_to_avro.sources.log_src.interceptors.host_ic.useIP = true # 호스트명 대신에 IP 사용 log_to_avro.channels.mem_channel.type = memory log_to_avro.channels.mem_channel.capacity = 10000 log_to_avro.channels.mem_channel.transactionCapacity = 10000 log_to_avro.channels.mem_channel.byteCapacityBufferPercentage = 20 log_to_avro.channels.mem_channel.byteCapacity = 10485760 log_to_avro.sinks.avro_sink.type = avro log_to_avro.sinks.avro_sink.channel = mem_channel log_to_avro.sinks.avro_sink.hostname = hostname.of.cluster.agent log_to_avro.sinks.avro_sink.port = 4141 ...웹서버 에이전트 설정파일... avro_to_hdfs.sources.avro_src.type = avro avro_to_hdfs.sources.avro_src.bind = 0.0.0.0 avro_to_hdfs.sources.avro_src.port = 4141 avro_to_hdfs.sources.avro_src.channels = c_101 c_102 avro_to_hdfs.sources.avro_src.selector.type = multiplexing # Multiplexing Selector 설정 avro_to_hdfs.sources.avro_src.selector.header = host # 호스트 이름으로 채널 나누기 avro_to_hdfs.sources.avro_src.selector.mapping.192.168.0.101 = c_101 # 192.168.0.101 에서 온 이벤트는 c_101 채널로 avro_to_hdfs.sources.avro_src.selector.mapping.192.168.0.102 = c_102 # 192.168.0.102 에서 온 이벤트는 c_102 채널로 # 채널 c_101 설정 avro_to_hdfs.channels.c_101.type = memory avro_to_hdfs.channels.c_101.capacity = 10000 avro_to_hdfs.channels.c_101.transactionCapacity = 10000 avro_to_hdfs.channels.c_101.byteCapacityBufferPercentage = 20 avro_to_hdfs.channels.c_101.byteCapacity = 10485760 # 싱크 k_101 설정 avro_to_hdfs.sinks.k_101.type = hdfs avro_to_hdfs.sinks.k_101.channel = c_101 avro_to_hdfs.sinks.k_101.hdfs.fileSuffix = .log.gz avro_to_hdfs.sinks.k_101.hdfs.path = hdfs://namenode/path/to/logs/dir/%Y%m%d/%{host} # 날짜별, 호스트별로 다른 디렉토리에 avro_to_hdfs.sinks.k_101.hdfs.rollSize = 104857600 avro_to_hdfs.sinks.k_101.hdfs.rollInterval = 7200 avro_to_hdfs.sinks.k_101.hdfs.rollCount = 0 avro_to_hdfs.sinks.k_101.hdfs.fileType = CompressedStream avro_to_hdfs.sinks.k_101.hdfs.codeC = gzip # 채널 c_102 설정 avro_to_hdfs.channels.c_102.type = memory avro_to_hdfs.channels.c_102.capacity = 10000 avro_to_hdfs.channels.c_102.transactionCapacity = 10000 avro_to_hdfs.channels.c_102.byteCapacityBufferPercentage = 20 avro_to_hdfs.channels.c_102.byteCapacity = 10485760클러스터 에이전트 설정파일p.s. Flume 설정 파일은 변수 또는 외부 파일 include 등을 지원하지는 않아서, 위와 같이 반복되는 설정을 여러 번 써 주어야 합니다.호스트마다 CDH 알람 트리거 설정그리고 CDH 상에서도 웹서버 호스트의 개수만큼 알람 트리거를 만들어 줍니다. 초당 이벤트 개수가 0에 가깝게 떨어지면 알람이 오도록 해 주면 됩니다. 채널/싱크 중 어느 것을 기준으로 해도 크게 상관은 없는데, 저희는 싱크가 초당 이동완료한 이벤트 개수를 기준으로 했습니다.CDH에서의 알람 트리거 상태 화면이렇게 해 놓으면 또 한가지 좋은 점은, CDH가 알아서 차트를 그려 주기 때문에, 웹서버마다 트래픽 추이를 한눈에 볼 수 있다는 것입니다.HDFSSink의 초당 이벤트 개수 그래프맺음말지금까지 Apache Flume 과 CDH 를 사용해 로그 수집 시스템을 구성하고 모니터링을 설정한 후기를 살펴 보았습니다. 이 과정에서 느낀 점들을 한번 정리해 보겠습니다.첫째, 일견 간단해 보이는 기능이었지만 의외로 많은 시행착오를 거쳐야 했습니다. 아무리 간단해 보이더라도 각자의 상황에 맞추어 시스템을 설계하는 데에는 그에 맞는 고민을 거쳐야 합니다.둘째, 처음에는 로그가 일단 수집되게 하는 것이 가장 중요하다고 생각했는데, 실제로 겪어보니 모니터링이 훨씬 어렵고 중요한 문제라는 것을 알게 되었습니다. 어떤 기능이 일단 실행되도록 설정을 해 놓더라도, 그것이 매일 문제없이 실행됨을 보장받는 것은 또 다른 문제입니다.셋째, Health 페이지와 Pingdom을 이용한 웹서버 측의 모니터링은 JSON 리포팅의 문제 때문에 큰 쓸모가 없게 되었습니다. 하지만 꽤 유용한 테크닉이라는 생각이 들고, 어딘가에서는 비슷하게 이용할 수 있을 것 같습니다.마지막으로 CDH 쓰면 좋습니다. 많은 것들이 편해집니다.P.S. 리디북스 데이터팀에서는 이러한 로그 시스템을 함께 고민하고 만들어나갈 분들을 찾고 있습니다. 많은 관심 부탁드립니다.#리디북스 #개발 #서버 #서버개발 #모니터링 #로그 #Flume #CDH #로그수정 #인사이트

# 이 광고 콘텐츠가 더 좋을 줄 알았는데'이 광고 콘텐츠 잘 먹힐 거 같애~' 퍼포먼스 마케터로 성장하는 과정 속에서 혼자 생각에 꽤나 괜찮은 디자인이 나오거나, 꽤나 괜찮은 카피가 나오거나, 꽤나 새로운 형태의 광고 콘텐츠를 제작했을 때 항상 속으로 위와 같은 말들을 내뱉는다. '이번 광고는 사이트 유입 단가가 낮을 거 같애, 내가 원하는 목표 전환당 비용이 꽤나 저렴해질 거 같애, 목표 전환율이 높아질 거 같애~' 라는 생각으로 광고를 집행해보면 막상 내가 예상했던 그림대로 안 움직이는 경우가 많다. 나의 감이 성과를 가져다 주지는 않았던 것이다. 주어진 시간 내에 빠르게 성과는 내야 하고 예산은 정해져 있고... 목표 전환율이 높은 광고 콘텐츠 형태를 찾기 위해서 광고 콘텐츠에도 A/B 테스트를 도입할 수밖에 없었다. 감이 아닌, 감 to the  검증을 위해서 말이다. # 광고 콘텐츠 A/B 테스트(페이스북과 인스타그램을 전제로)실험의 형태는 정말로 다양하다. 다양한 실험의 형태에서 브랜드의 서비스에 유효할 것 같은 실험 형태를 정해 놓고 보통 실험을 한다.(실험을 하는 주체에 따라서 많이 달라질 수 있을 것 같다.) 개인적으로 진행해봤던 실험들을 생각해보고 정리를 해보았다.(1) 광고 콘텐츠의 형태 단일 배너, 정사각 슬라이드, 간단한 영상, 콜랙션 광고, 인스타그램 스토리 광고 등 최초에는 리소스가 많이 들어가지 않는 선에서 실험을 진행하는 경우가 많다. 광고의 형태에 따라 광고 노출 영역이 다소 달라지긴 해서 리소스를 최소화하는 단일 배너 및 정사각 슬라이드, 소유하고 있는 영상이 있다면 영상까지 함께 집행한다. (영상이 잠재고객의 참여도가 좋다는 건 많이들 이야기 하지만, 기대하는 최종 kpi가 매체 효율뿐만 아니라 웹사이트에서의 특정 행동 전환율과 전환 단가 이기 때문에 크게 상관하지 않고 실험을 진행하는 편이다.)(2) 카피 베리에이션 동일한 디자인에서 배너에 들어가는 카피만 여러 개로 나눠서 실험을 진행하기도 한다. 그렇게 하는 이유는 광고를 집행하는 나도 어떤 메시지가 광고 매체 효율이 좋을지, kpi는 어떤 게 좋을지 사실 알 수 없기 때문이다. 실패의 확률을 줄이면서 리소스를 최소화해서 실험하는 방법 중의 하나이다. 보통 동일한 배너 디자인에 카피를 3개로 나누어 A/B/C 테스트를 한다.(3) 디자인 같은 카피 다른 디자인, 예를 들어 설명해주면 아기 화장품 제품을 광고하는데 소재에 들어가는 카피는 동일하되 디자인이 아기가 들어간 게 좋을지, 제품만 들어간 게 좋을지, 아기와 제품이 함께 들어가는 게 좋을지, 혹은 아기가 들어가는데 아기 실사가 들어가는 게 좋을지, 일러스트 느낌의 아기 이미지가 들어가는 게 좋을지를 실험해볼 수 있다. 매번 이렇게 진행할 수는 없지만, 우리에게 성과를 가져다주는 광고 콘텐츠의 형태를 찾는 단계에서 필수적이다.(4) 전면사진슬라이드 형태나, 영상 광고 집행할 때 많이 해봤던 것 같다. 영상이라 한다면 영상의 썸네일 이미지를 어떤 걸로 선택해서 하는 게 좋을지 실험을 해보는 것이고, 슬라이드 형태는 전면 슬라이드 이미지(첫 번째 카드 이미지)를 여러 개로 구분해서 실험을 해보는 것이다. 예를 들어 여성 쇼핑몰에서 여름휴가에 필요한 옷을 광고하는데 a 제품을 전면에 내세우는 게 좋을지, b 제품을 전면에 내세우는 게 좋을지 실험을 해보는 것이다.  총 5개의 카드 이미지가 있다고 가정하고, 그 중에서 전면에 배치하기에 좋은 카드 이미지가 3개가 있다고 한다면 아래 방법처럼 진행해볼 수 있다.a-b-c-d-eb-a-c-d-ec-a-b-d-e=> 초반 최적화 작업이 끝난 후에 광고 효율이 좋은 광고에 예산을 증액하고 나머지 광고는 off 하면 된다.(5) key 메시지앞서 언급했던 카피 베리에이션과 유사한 형태일 수도 있는데 조금은 다른 느낌의 실험이다. 우리 제품이나 서비스가 잠재고객에게 어필할 수 있는 요소가 다양한데 어떤 걸 보여주는 게 성과가 가장 좋을지 알아보는 것이다. 제품이나 서비스의 장점을 언급할까? 아니면, 이미 만족해서 사용하는 사용자의 후기를 보여줄까?, 아니면 할인에 대한 언급을 해줄까? 아니면 할인과 다른 내용을 합쳐서 보여줄까? 할인을 하면 할인하는 %를 보여줄까? 아니면 할인된 가격을 보여줄까 등등 카피 베리에이션과 비슷하면서도 조금은 다른 실험을 진행할 수도 있다. 예를 들어 후기의 형태로 광고를 한다면 이 것 또한 구분을 할 수 있을 것이다. 여러 명의 짧은 코멘트 후기를 나열해서 보여줄까? 아니면, 가장 괜찮은 후기 1개를 보여줄까? #실험의 전제 조건(1) KPI는 명확해야 한다. 그렇지 않으면 의사결정은 산으로 갈 수가 있다. 매체의 효율을 볼 것인가, 아니면 사이트에 유입된 후 회원가입률을 볼 것인가, 구매 전환율을 볼 것인가?, 다른 고객 행동 전환을 볼 것인가? 명확한 KPI는 정해져 있어야 한다. 광고주와 에이전시에 입장이라면 상호 간의 공유가 필요하고, 인하우스 마케터라 한다면 적어도 광고에 관여하는 누군가와는 명확한 kpi 공유가 이루어져야 한다. 그래야 데이터를 본 후 명확한 의사결정을 할 수 있고, 서로 얼굴 붉힐 일도 없을 것이다.(2) 분석할 수 있는 데이터 분석 툴이 필요하다 페이스북 픽셀을 설치해서 전환당 효과를 보든, 구글 애널리틱스로 광고 콘텐츠 별 성과 데이터를 보든, 광고 콘텐츠 A/B  테스트를 진행할 때에는 (개인적으로) 반드시 로그 분석 툴로 데이터 분석이 뒷받침 되어야 한다.(3) 상처받지 않는 기술 필요하다. 실험을 돌렸을 때 성과가 좋은 실험도 있고, 성과가 좋지 않은 실험도 있다. 반복적으로 좋지 못한 성과들을 마주할 수도 있는데 A/B 테스트에서 좋은 결과를 보기 전까지는 상처받지 않는 기술이 필요하지 않나 싶다. 퍼포먼스 마케터라면 광고를 집행하고 몇 시간마다 한 번씩 모니터링하는 경우가 많을 텐데 상처받지 말고 성공을 위한 실패로 받아들이는 기술이 필요할 것 같다. 그리고 실패에 대해서 이해할 수 있는 문화는 내부적으로나 에이전시와 광고주간에 꼭 필요하다. 개인적으로 성과가 좋지 못할 때는 잠시 이어폰을 꽂고 명상을 듣는다. 마음이 차분해진다. NEXT를 생각하게 된다. 쉽지 않지만 말이다^^광고 콘텐츠 A/B 테스트는 하면 할수록 유용하고 필수적이라는 생각이 든다. 적어도 퍼포먼서 마케터에게는 말이다. 최근에 진행해봤던 광고 콘텐츠 A/B 테스트, 그리고 A/B 테스트 후 다음 단계에서 유효한 타겟을 넓히는 작업을 진행해본 사례가 있는데 글이 너무 길어질 것 같아 다음에 다시 한번 정리를 해볼 생각이다. 누군가 이 글을 보고  광고 집행에 도움이 되길 바라는 마음이다. 그리고 추후엔 광고 콘텐츠 A/B 테스트뿐만 아니라 다양한 실험 사례들도 소개할 예정이다. 퍼포먼스 마케팅 에이전시, 오피노 바로가기

내가 하고싶은 행동의 첫스텝이 목표다매년 새해 목표를 세울때면 스스로 되뇌이는 말이다. 누구나 새해 목표가 있다. 그리고 목표들은 각양각색이다. 개중에는 높은 난이도 때문에 영웅적으로 들리는 목표가 있다. 가령 회사를 차리겠다거나, 책을 쓰겠다는 목표들이 그렇다. 이런 목표는 듣는 사람들의 탄성을 자아낸다. 나는 뭘하고 사는지 돌아보게 만들기도 하는 목표다. 반면 소소한 목표도 있다. 그저 건강하기만 하면 된다거나 회사에서 잘 버티겠다는 식의 목표가 나에게는 그렇다. 이런 목표는 경우에 따라 내심 말하는 사람의 소심함을 곱씹게 할 때도 있다.대학때까지 목표는 굉장히 자율적인 것이었다. 하지만 회사에서는 그렇지 않았다. 목표는 공적인 약속이고 매월 지표가 되어 돌아온다. 그럴싸한 목표와 그림을 안고 새해를 시작했지만 연말에 빈손으로 회사에 보고를 한 적도 있다. 반면 이것도 계획인가 싶은 정도의 발전없는 목표를 가지고도 조금의 성과를 이루어내 내실있는 연말을 맞은 적도 있다. 결과가 중요하다. 하지만 그렇다고 목표를 100% 달성할 수 있는 낮은 수준의 목표를 선정하자는 것은 아니다. 결과보다 더 중요한 것이 실행이라고 믿기 때문이다. 실행을 해야 성공도 실패도 한다. 가장 나쁜 목표는 실행의 가능성이 없는 듣기 그럴싸한 목표들이다. 누구나 한번쯤은 이런 목표를 세워봤을 것이다.- 매일 1시간씩 책읽기- 매일 팔굽혀펴기 100개하기흔한 목표다. 하지만 달성하는 사람은 손에 꼽는다. 대부분은 3일을 넘기지 못한다. 그 이유는 그럴싸한 결과 목표가 갖는 낮은 실행력 때문이다. 나는 새해 목표를 이렇게 세운다. 매일 팔굽혀펴기 50개가 목표라면, 나의 목표는 매일 엎드리기다. 매일 책 50쪽 읽기가 목표라면, 내 목표는 매일 책펴기다. 업무적으로 마케팅 아티클 하루에 하나 읽기가 목표라면, 나는 하루 1번 사이트 접속을 목표로 세울 것이다. 재밌고 즐길 수 있는 것을 목표로 정하는 경우는 흔치 않다. 애초에 활동도 힘든데 목표치를 높게 잡아서 스스로가 더 부담스럽게 느낄 이유는 없다. 매일 다이어리 쓰기가 목표라면 자기전 다이어리에 오늘 날짜 쓰기를 목표로 잡아야한다. 그렇다면 매일 성취감을 느낄 수 있고, 어쩌다 하지 않았을 때 메꾸고 정상궤도로 돌아오기가 쉽다. 영원히 지워지지 않는 to-do list 를 만들어 놓고 스스로 괴로워하지말자. 아직 새해 목표를 세우지 않았다면, 2019년에는 아주 작은 목표를 만들어보자. 행동을 여러 단계로 쪼개서 첫 스텝을 목표로 잡아보자. 매일 방청소를 목표로 세우지 말고 매일 청소기 들기를 목표로 세우자. 그 목표는 자연스럽게 다음 행동으로 이어질 것이다. 그리고 달성이 주는 성취감이 다시 한번 당신을 움직일 것이다.챌린저스, 확실한 목표달성 꾸준한 습관형성www.chlngers.com

여러분은 중고 거래에 대해 어떻게 생각하시나요?혹시 '평화로운 그 곳'에서 물건을 사고 팔아본 경험이 있으신가요?꼭 익명의 인터넷 사이트 상이 아니라도 크고 작게, 누구나 한번쯤 해봤을 중고 거래.기억을 더듬어 보세요.오래 전 '아나바다'라는 슬로건이 성행하던 시절이 있었는데요. 단순히 아끼고 나누는 것 외에 같은 반 친구들, 한 동네 이웃들과 입지 않는 옷이나 사용하지 않는 물건 등을 바꿔 쓰고 다시 쓰는 알뜰살뜰하고도 가슴 따땃해지는 운동이었죠. 어디 그 뿐인가요? 매해 연말 '사랑나눔 바자회'라는 벼룩시장은 꿀같은 득템은 물론 수익금 일부가 사회 소외된 곳에 기부되어, 세상을 온화히 데우는 데에 동참할 수 있었던 좋은 장이었답니다.나에게서 의미를 잃은 것은 다른 이를 만나 가치를 되찾으며같은 방법으로 나 또한 누군가로부터 무의미해져 버린 것에서 새로운 가치를 찾는 것.도떼기마켓은 그 가치를 일깨우는 연장선 상에 있는 서비스입니다. 도떼기마켓은 보다 쉽고 편하며 안전한 중고 거래를 지향합니다. 당신 또한 우리를 통해 긍정과 호의의 중고 거래를 조우하길 소망합니다. 사람들로 하여금 새로운 라이프 스타일을 경험할 수 있도록 펼쳐진 너른 장이 되길 도떼기마켓은 기꺼이 자처합니다.지금부터 도떼기마켓의 탄생 비하인드 스토리들을 꺼내 들려 드리려고 합니다.이로써 당신의 생각 한켠에 자리한 중고 거래에 대한 인식이 이전보다 조금은 나아지길 기대해봅니다.' 중 고 '이거 지-인짜 좋은데... 뭐라 표현할 방법이 없거든요!1화 지극히 개인적인, 마켓 : '플리마켓'을 하다. '도떼기마켓'이 되다.도떼기마켓을 이야기하기 위해서는 플리마켓을 빼 놓을 수 없습니다.도떼기 플리마켓이 곧 도떼기마켓의 시작을 다지는 초석이었으니까요.# 도떼기마켓, 소박한 시작처음부터 계획을 갖고 시작된 서비스는 아니었습니다. 거창한 꿈이나 원대한 포부가 태초부터 존재했던 건 아니었죠.다만 옷장 속엔 입지 않는 옷이, 쓰지 않는 모자가, 메지 않는 가방이 있었습니다.흔히들 그렇듯, 인터넷 커뮤니티를 통해서 중고 거래를 추진했습니다. 사진을 찍고 가격을 고민합니다. 이래저래 토를 다는 상대방에 분노가 치밉니다. 택배비를 빼주네 마네 실갱이가 시작됩니다. 직거래 장소를 절충하는 과정에서 진이 빠집니다. 만나는 날과 시간을 정하는 것에서 혼이 나갑니다. 겨우 성사된 거래, 고대하던 택배 상자 안에 벽돌이 들어있습니다. 같잖은 물리적인 이유들로 용사의 정신력이 쇠퇴합니다.(-30)이럴바엔 차라리 직접 시장을 열어보면 어떨까하는 생각을 하게 됐죠. 곧장 마음 맞는 친구들을 불러 모아 작은 이벤트를 기획했습니다. 포스터도 만들어 붙이고, SNS와 자주 가는 인터넷 카페에 놀러오라는 글도 올리구요.# 제 1회 도떼기 플리마켓 in 이태원 경리단길2012년 10월 13일 토요일마음 맞는 친구들과 그 친구의 친구가 모여 11개의 노점을 펼쳤습니다. 이렇게 이태원 경리단길 골목에 '제 1회 도떼기 플리마켓'이 열리게 됐답니다.플리마켓을 열 장소를 물색하고 친구들을 불러 모으고 오고가는 손님들을 응대하며 내가 내놓은 물건에 담긴 사연을 누군가에게 들려주는 일. 새로운 상황을 경험하고 새로운 사람들과 이야기하는 것, 그 자체만으로도 충분히 즐거웠습니다. 필요없는 물건을 해치우겠다는 이글이글 불타는 완판의 욕망은 완전히 사라졌죠.단순한 재화의 거래가 전부인 시장통이 아니었어요.이건 페스티벌! yay!# 도떼기 플리마켓, 문화가 되다.플리마켓에 대한 반응은 예상보다 뜨거웠습니다.친구들과 그 친구의 친구, 또 그 친구의 친구 그리고 SNS와 커뮤니티에서 보고 놀러온 사람들까지... 많은 이들이 도떼기 플리마켓에 대한 관심과 지지를 보내주었습니다. 기대하지 못했던 열렬한 성원에 힘입어 한달 채 지나지 않은 같은 해 11월 3일, 같은 장소에서 제 2회 도떼기 플리마켓을 열게 됩니다. 물론 이번에도 거창한 의미는 없었습니다. 그저 즐겁게 모여, 유쾌한 교류와 소통을 꿰었습니다.몇 번의 플리마켓을 거치며 알게 된 중요한 사실. 도떼기 플리마켓에 방문하는 사람들은 단순히 옷만을 구입하러 오는 게 아니라는 거죠. 플리마켓 속 멈추지 않는 음악, 오가며 맛 볼 수 있는 달큰한 요깃거리, 좁은 골목을 오가는 이들 사이에 스치는 묘한 동지애, 텔레파시 같은 뭐 그런 거. 그런 짜릿함에 매료돼 플리마켓을 찾아오는 이들이 많다는 걸 알게 되었죠. 보다 더 즐겁고 유쾌한 플리마켓으로 거듭나기 위해 DJ 공연, 먹거리, 체험거리 등을 더해 갔습니다.이렇게 도떼기 플리마켓은 한 순간도 지루할 새 없는 옹골찬 축제로 거듭나게 됩니다.도떼기 플리마켓이 풍요로워지는 만큼, 이전엔 없던 새로운 목표를 하나 갖게 되었습니다.'플리마켓을 문화로 만들자!'다양한 트렌드와 스타일이 존재하고, 이를 기반으로 한 서로의 생각을 나누는 그 자체로의 문화. 플리마켓이 '당연'해진다면 중고 거래에 대한 세상의 시선도 변화할거라 믿고있고 이 생각은 지금도 변함없거든요.사사롭게 시작된 도떼기 플리마켓은 그렇게 도떼기마켓으로의 또 다른 걸음을 내딛기 시작하였습니다.다음 주, 도떼기마켓 비하인드 스토리 두 번째가 계속됩니다!#유니온풀 #도떼기마켓 #경험공유 #인사이트 #성장 #기업가치

Phase 21. 핵심에서 삐끗하다... 대안을 찾아야지!사실 원향(fragrance oil, 향수는 콜라와 같이 원액을 공급받아 bottling을 해야한다) 을 공급해주는 회사에 관련해서는, 내가 필요한 것을 잘 해주겠지라는 막연한 생각으로 지금까지 contact을 하지 않고 있었는데.... 그리고, 사실 다른 것들이 만들어지지 않았는데 향부터 이야기를 꺼내봐야 될 것이 없었다. 이제 패키지, bottle, 디자인 등등의 것들이 마무리되어 가는 상황이다 보니 향 회사(Drom Fragrance)에 연락을 하게 되었다. 대답은 부드러웠지만, 독일 특유의 원칙에 어긋나는 것은 할 수 없단다. MOQ(Minumum Order Quantity, 최소주문물량)가 25kg인데, 내가 부탁하는 양은 턱없이 적었고... 최근에 이런 작은 long-tail account를 본인(Drom AP 대표)이 정리하라고 했던 상황이라, 나에게도 동일한 기준을 적용행 하며, 특혜를 주기는 어렵단다. 단, 만약 AP HQ에 방문한다면 나에게 도움이 되는 것들은 최대한 지원해준다는 고마운 말을..ㅎㅎ 그래서 통화를 하면서 대안으로 고민한 것이, Trader를 활용하자는 것이었고 그 대안이 가격 측면에서는 조금 불리하겠지만 앞으로 나아갈 수 있는 길을 계속해서 만들어 갈 수 있는 유일한 방법이다.Phase 22. Harsh 한 부탁이었던가? 주변을 좀 살펴보았나?달성해야 할 목표와 타임라인이 있다 보니.. 맘이 급해진다. 대부분의 것을 혼자 해결해 가고 있지만, 그래도 주변 지인들에게 부탁해야 할 것들이 있었는데... 이런 부탁을 하면서 정말 정중했는지, 또한 그 사람들의 상황을 배려했는지? 에 대한 생각이 드는 시점이다. 일단 내 것을 만들기 위해 너무 harsh 하게 부탁한 것은 아닌지? 계속해서 push 하는 상황을 만들지는 않았는지를 돌아보게 되었다. 그렇게 생각하게 된 배경은.. 향 회사에서 내 메일에 답변이 며칠 간 없어서 이 친구들이 내가 너무 공격적으로 요청을 해서 화가 난 건  아닐까?라는 오해에서 시작되었지만, 암튼 다시 한번 돌아볼 수 있는 좋은 기회였다.Phase 23. 계속해서 사람들과 만나고 communication 하는 것의 중요성사실 새로운 기회를 발견하는 것은 혼자 조용히 앉아 사색하고 책을 읽고 하면서 만들어지는 경우가 많기도 하지만.. 그 생각의 시간에 기본적인 input이 있어야 하는데 그게 바로 다양한 사람들과 만나 이야기하는 것이  아닐까?라는 생각이 든다. 흙으로 뭔가를 혼자서 만드는 것보다, 다른 사람들과 논의하면서 그 안에 지푸라기를 넣어주어 보다 단단한 것을 만드는 것과 같은 효과가 나는 것이다. 이제 내 주변에서 career가 10년 정도는 된 분들인지라 본인의 영역에서의 내공이 나타날 시점이고, 새로운 기회를 포착하는데 눈이 뜨이게 되는 시점이라는 생각이 든다. 새로운 정보와 새로운 기회 하나하나가 모여 큰 것이 만들어지는 기반이 된다는 것! 특별한 목적이 없어도 몇 개의 keyword만 가지고서라도 사람을 만나러 나가 보는 것이 좋겠다.Phase 24. 직접 만나서 얼굴을 한번 보고 일하기3박 4일의 중국 출장은 정말 쉬는 시간 없이 거의 일만 하러 다녔는데, 그 목적 중에 하나는 나와 거래가 필요한 사람들과 만나서 얼굴을 보고 서로 신뢰감을 형성하는 일이었다. 그 와중에는 영어를 하나도 못하는 중국 trader도 있었고, 또 다른 소개를 받아 찾아간 bottle 제조업체에서는 "네가 그 친구의 친구라면 내 친구이기도 하지.. 최선을 다해  도와줄게"라고 말해주는 고마운 사람들도 있었다. 그렇게 얼굴을 한 번이라도 보고서 일을 시작하게 되니 서로에 대한 믿음과 의리가 생기는 듯한 느낌? 발품을 판다는 것이 새로운 것을 찾는 것만을 의미하는 것이 아니라.. 서로 간에 신뢰를 쌓아가는 과정이기도 하다.Phase 25. 최고의 partner를 만나다.Startup에 있어서 가장 중요한 사항중 하나는 역시나 팀을 구성하는 작업이라는 생각이다. 그런데 나에게 가장 필요로 했던 art director (visual designer 말고)를 찾는 쾌거를 거둘 수 있었는데. 바로 대학 동아리 1년 후배이자, 이탈리아에서 10년간 디자이너로 일한 my.yeo 와  함께할 수 있다는 것이었다. 혼자서 일을 만들어 오면서 가장 큰 고민은.. 내가 잘 하지 못하는 영역에서 나보다 뛰어난 사람이 그 고민을  함께해주고 실행해주면  어떨까?라는 것이었는데.. 큰 힘이 되어줄 친구가 조인을 한 것이다. 물론 아직 100% full time은 아니지만, 계속해서 involve 할 수 있도록 도움을 주는 것 또한 내가 해야 할 일이라는 생각이다.#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트

얼마 전부터 TV를 보다보면 아이유가 나와서 여리여리한 목소리로 '카카오톡 게임벼얼~' 하는 CF가 눈에 띄곤 했습니다. 처음엔 '카카오톡 게임별? 그게 뭐지?'라고 생각했는데 카카오톡을 새로운 버젼으로 업그레이드하고 나니 알겠더라구요.그것은 기존에 [친구 목록 - 채팅창 - 컨텐츠 - 설정] 로 구성되어있던 카카오톡의 메뉴 중 '컨텐츠와 설정' 아이콘 사이에 네번째로 새롭게 생긴 '게임' 메뉴였습니다! 들어가 보셨나요?새로운 것은 또 그냥 못 지나치는 마케터의 피곤한 특성상..! 이번에도 들어가보았습니다 +_+ 그리고 모든 게임을 다 해봤지요...ㅋㅋㅋ그 중에 제가 제일 좋아하는 게임은 (이라고 쓰고 잘 하는 게임이라고 읽는다) <라이언과 눈싸움 한 판> 이라는 게임이에요카카오톡 게임별에 있는 게임들은 다 가볍게 즐길 수 있는 '미니게임' 형태인데요 <라이언과 눈싸움 한 판>은 내가 라이언이 되어서 반대편에서 오는 튜브와 눈싸움을 하는 내용의 게임이에요!라이언을 꾹~ 누르면 게이지가 차오르면서 눈을 던질 준비가 되죠, 그런 다음 내 앞에 있는 튜브를 향해 눈덩이를 던져서 3번을 맞추면 그 튜브가 OUT 되는 쉬운 게임이랍니다!이 게임의 묘미는 처음에는 천천히 튜브가 한 마리 ~ 한 마리씩 등장하다가 시간이 지나면 점점 많이 등장하고, 튜브도 라이언에게 눈덩이를 마구마구 던지는 거에요!이 때 3번을 맞으면 튜브에게 지고 게임이 끝나요 ㅠ.ㅠ 우측 상단에 하트 ♥♥♥ 보이시죠? 이게 라이언의 목숨을 뜻함!오늘도 퇴근길에 스릴 넘치는 눈싸움을 하다가... 문득 좌측 하단 [겜톡하기] 버튼이 눈에 들어왔어요, 자랑하기는 내 카톡 친구들한테 내 레베루를 자랑하는 거라는 거 알겠꼬~ 겜톡은 도대체 뭐지? 싶었죠!그래서 들어가봤더니 눈싸움 게임을 하는 사람들이 모인 오픈 채팅방으로 연결이 되더라고요!으악...! 저는 이런 오픈채팅방에 익숙하지가 않아서 들어간지 한 1분만에 나왔는데요;; 주로 10대~로 보이는 어린 친구들이 게임과 상관 없는 이야기들도 마구마구 쏟아내고 있었어요 ㅠ.ㅠ그것을 보면서 '카카오톡은 왜 이런 게임, 오픈채팅방을 만들었을까?' 생각하게 되었죠 (서론이 매우 길었네요...)서비스의 본질, '유저들이 기꺼이 시간을 낼 수 있도록 만드는 것'무엇인가를 판매한다는 것은, 그게 서비스가 됐든 재화가 됐든 그 매개체와는 상관없이 '유저 (혹은 손님)들이 기꺼이 찾아오게 만드는 것, 그리고 그것에 시간을 쓸 수 있도록 만드는 것'이라고 생각해요.카카오톡의 경우 '스마트폰에서의 연락 수단'이 됨으로써 카카오톡 안에서 사람들이 시간을 최대한 많이 보내도록 유도하는 것이 서비스의 본질이겠죠?그러한 관점에서 카카오톡은 왜 '게임별'을 만들었을까? 조금이라도 더 오래 카카오톡 안에서 사람들이 머물길 바래서 게임별을 만든 게 아닐까요? (게임을 통한 과금은 그 다음으로 차치하고서요~)여러 종류의 미니게임들을 깔아놓고 사람들이 어떤 게임을 좋아하는지~ 어떤 게임에서 오랜 시간을 보내는지~그리고 게임을 즐기는 사람들끼리 이야기 할 수 있는 오픈 채팅방을 만들어서 그 안에서 한 번 더~ 오래~ 시간을 보낼 수 있도록 유도하고 싶은 게 아닐까? 하는 생각이 들었어요(카카오와 1도 연결고리가 없는 제 3자인, 순전히 저의 생각입니다)그렇다면 내가 제공하고 있는 서비스는 과연 어떨까?저는 지금 취업 준비생들이 자기소개서를 쓸 때 조금이라도 편하게 쓸 수 있는 기능들을 제공하고 있는 <자소설닷컴>에서 마케터로 일을 하고 있는데요, 우리의 서비스는 과연 어떤가!? 돌아보았죠어떤 기업에 서류 지원을 하려면 취업 포털 사이트에서 채용 공고를 확인한 다음에~ 회사 채용 홈페이지에 가입을 하고~ 이력서 내용을 다 채워넣고~ 한 3단계를 거쳐야 겨우 자기소개서 문항을 볼 수 있어요,그 문항 보고 워드 파일에 복+붙해 놓은 다음 자기소개서를 준비하고, 다시 1단계로 돌아가 로그인을 하고~ 이력서를 입력하고~ 다시 자기소개서 창으로 가서 다 쓴 자기소개서를 복+붙해서 지원을 해야하죠.저희 서비스는 이런 번거로운 절차를 없애기 위해 [채용 공고]에 여러 회사의 채용 공고를 한 번에 볼 수 있도록 해놨고, 채용 공고 옆에는 [자기소개서 쓰기] 버튼이 있어서 위 화면처럼 바로 자기소개서 문항을 확인할 수 있도록 했어요자기소개서 쓸 때에도 조금이라도 더 편하게 쓸 수 있게 여러가지 기능을 탑재해두었구요. 이렇게 '자기소개서 쓰는 행위'를 편하게 해주는 것이 우리 서비스를 찾는 사람들로 하여금 조금이라도 더 오래 우리 서비스에 머무르게 하는 방법이라고 생각한 것이죠.자기소개서를 쓸 때 활용하는 기능 외에 더 줄 수 있는 건 없을까?그러나 앞에서 말했듯이 '서비스를 제공한다'는 것은 '유저들이 기꺼이 찾아오게 만드는 것, 그리고 그것에 시간을 쓸 수 있도록 만드는 것'!우리의 서비스 역시 자기소개서 작성 행위에서 오는 편리함 그 이상의 가치를 제공할 수 없을까? 고민을 했습니다그 고민 끝에 나온 것이 위에 보이는 [자소서 연구소]에요! 쉽게 말하자면 블로그처럼 컨텐츠를 쌓아두는 기능을 사이트 내에 탑재한 것이죠.누구보다 더 자기소개서에 대해 고민하고, 연구해서 컨텐츠를 만들어 '유저들이 조금이라도 더 오래 우리 서비스에 머물렀으면 좋겠다'고 생각해서 만들어졌어요~스타트업 마케터로서 "서비스 마인드"란 무엇일까?(이미지: 요새 저의 페이보릿 이모티콘 오버액션 토끼)결국 스타트업 마케터로서 가져야 할 서비스 마인드란 '되도록 유저들이 오랜 시간 머무를 수 있는 서비스를 만들어야겠다' 라는 생각과 더불어 '우리 서비스에 머물러주는 유저들의 귀한 시간을 헛되이 만들지 말아야겠다' 라는 사명감인 것 같아요!이를 위해서 개발팀과 디자인팀 모두와 함께 으쌰으쌰하여 더 좋은 서비스를 만들기 위해 노력해야겠죠!그렇다면 카카오톡은..?다시 처음으로 돌아가, 카카오톡 게임별은... 그런 의미에서 서비스의 본질에 맞는 기능일까요? 확실히 유저들로 하여금 카카오톡에 오래 머무를 수 있도록 해주는 것 같긴 해요!그런데 그 다음은...?흠~ 이것은 아마 모든 서비스 제공자들이 평생 풀어나가야 할 숙제 같아요! 너무나도 어렵죠! 특히 사업, 돈을 벌어야 하는 측면과 같이 생각하면 더더욱요!생각을 결론 짓다보니 우리 서비스도 유저들의 시간을 헛되이 쓰지 않으면서 돈도 더 잘 벌 수 있는 방법을 빨리 찾아야겠다는 생각이 듭니다! 아아~대한민국 스타트업 마케터의 하루는 길고도 기네요!(그런 의미에서 고생하는 취업 준비생 친구들의 시간을 헛되이 쓰지 않는 뜻에 함께 해주실 광고, 제휴 제안이 있다면 대환영입니다 ㅋㅋㅋㅋㅋㅋ 기승전영업... 끄아)#앵커리어 #마케터 #마케팅 #마케팅팀 #브랜드 #분석 #인사이트

이 글은 "친구끼리 쓰는 라이브 스트리밍 앱, 라이비오(LIVEO)"의 앱 출시 과정을 담는 글입니다. 어디까지나 현재 겪고 있는 과정을 기록하는 것으로, 최선의 방법이 아닐 수도 있으니 더 좋은 방법이 있다면 언제든지 소개 부탁드립니다.앱을 출시하게 되면서 가장 먼저 준비하게 되는 것 중에 하나. 웹사이트이다.지난 사업인 위제너레이션이나 오드리씨 모두 웹 사이트 자체가 중심이 되는 사업이었기에, 팀 내에 웹 개발자가 있었고 직접 사이트 제작을 건드려야 할 일은 따로 없었다.그러나 라이비오라는 앱 서비스를 준비하게 되면서, 팀 내 개발자들은 앱 서비스 개발에 바쁘고 웹 사이트는 기본적인 소개의 역할만 담당하면 되기 때문에, 직접 사이트를 만들게 되었다.이렇게 가장 기본적인 소개의 역할만을 담당하는 한 페이지짜리 웹 사이트를Promotional Landing Page, 혹은 랜딩 페이지라고 줄여서 부른다.우리는 총 세 가지 과정을 거쳐 웹 사이트를 만들어왔는데, 순서대로 아래와 같다.[1] 시중에 떠도는 HTML5 템플릿을 활용해 앱 개발자분께 부탁하여 간단하게 직접 만들었다[2] IMXPRS 라는 서비스를 이용하여 직접 만들었다[3] Instapage 라는 서비스를 이용하여 직접 만들었다결론만 말하자면 IMXPRS 는 내가 어떻게 알았는지 모르지만 완전 비추인 서비스이다.직접 만드는 것도 돈은 들지 않지만 그 때 그 때 커스텀이 안되기 때문에 불편하다.알아본 결과 랜딩페이지 제작으로는 주로 wix(바로가기) 나 Instapage(바로가기)를 추천하는데, 두 서비스가 유사하지만 개인적으로 Instapage 의 디자인이 더 마음에 들어서 선택하게 되었다.*wix의 경우 한글 버전이 있고, 이후 결제를 붙이는 것이 좀 더 용이하다고 알고있다.각각의 템플릿과 기능을 보고 적절한 것으로 선택하면 될 것이다.Instapage 사용 경험의 경우 개인적으로 10점 만점에 9.5점을 줄 정도로 아주 높다.당연히 직접 개발하는 것 만큼이야 커스텀이 안되겠지만, 매우 쉽게, 꽤 높은 수준으로 커스텀이 가능하다.예를 들어, 애초에 사용한 템플릿은 위의 템플릿이었는데, 아래와 같이 커스텀했다                                                  애초의 템플릿                                                   최종 결과물거의 다른 모습임을 알 수 있는데 그만큼 커스텀이 정말 쉽다는 뜻이다.- 기본적인 디자인은 모두 템플릿에서 제공하며- 핵심이 되는 Headline 및 본문 글꼴을 수정할 수 있고- 원하는 이미지 등을 손쉽게 원하는 위치에 삽입하고, 요소를 원하는 위치에 원하는 크기로 넣는다- 배경 사진 또한 유료 사진을 즉석에서 보고 어울리는 것을 쉽게 결제할 수 있다- 모바일 페이지도 자동 생성되며 별도로 변경할 수 있다(!)이러한 기능들 덕택에 개발자나 디자이너가 아니더라도, 30분~1시간만에 어느 정도 수준의 랜딩페이지를 손쉽게 완성할 수 있다.가장 마음에 들었던 부분은 외부 서비스와의 연계인데, 특히 이메일 주소를 받는 등의 추가기능이 필요한 경우 Integration 탭에서 정말 쉽게 넣을 수 있다. (라이비오의 경우 현재 이메일 주소를 받는 부분은 Mailchimp 라는 타 서비스와 연결되어있다.)                        Edit > Integration 탭에 가면 볼 수 있는 수많은 서비스들향후에는 좀 더 공식 사이트스러운 것들이 필요하겠지만, 초반 몇 달간 사용하기에 손색이 없는 서비스라고 생각한다. 일정 기간동안 무료로 제공되며, 향후 이용료를 낸다. (위의 사이트 수준이면 월 $29 정도)완성된 홈페이지: http://liveo.me랜딩 페이지는 이 정도로 하고, 이후 스마트 앱 배너를 추가할 계획이다.모바일로 랜딩페이지에 접속하면 앱 설치로 유도하는 배너이다.이 부분은 SDK 연동 등도 필요해서 개발자분들의 바쁨이 조금 잦아들면 출시 직전이나 직후에 넣으려고 한다. 관련 서비스는 branch.io 등이 있다.                                Smart App Banner 사례: 맨 위에 저거...사실 처음에는 랜딩 페이지(Promotional Landing Page)니, 스마트 앱 배너(Smart App Banner)니 하는 용어 자체를 몰라서 관련 서비스를 찾기가 어려웠다. 하지만 일단 용어를 알고나니 관련하여 이용할만한 좋은 서비스들이 많았다.혹시 앱 출시를 처음 해 보는 팀이 있다면 앱 출시 마케팅 자체에 대한 조사를 먼저 하고 큰 그림을 그려둔 후 가지를 쳐가며 준비하기를 추천한다. 개인적으로 어떤 부분을 모르는지, 어떤 부분을 알아야 할지를 알 수 있어 훨씬 수월했던 것 같다.하나 하나 완성된 모습으로 채워가는 과정이 왠지 괴롭고도(?) 재미있다.앞으로 소셜미디어와 프레스킷을 만들어가는 과정도 담아보기로 한다.+ 여담: 배경색 선정은 페이스북 '포토샵 완전정복' 디자이너 그룹의 힘을 빌었다.  투표의 힘!정말 많은 분들이 투표에 참여해주셨고 그 중 아는 언니가 준 의견 덕분에 지금의 검은 색상 옵션을 추가하게 되었다.사실 내가 처음 밀었던 색상은 아래의 보라색이었고 우리 팀도 대표님 제외하고 모두 보라색을 택했다 ㅋㅋㅋ 그러나 디자이너들의 의견은 가차없이,검은색 > 민트색 > 보라색 이었다.역시 기술만 있는 나에게 디자이너의 안목을 기르기란 끝없는 과제이다.이 글은 "친구끼리 쓰는 라이브 스트리밍 앱, 라이비오(LIVEO)"의 앱 출시 과정을 담는 글입니다. 어디까지나 현재 겪고 있는 과정을 기록하는 것으로, 최선의 방법이 아닐 수도 있으니 더 좋은 방법이 있다면 언제든지 소개 부탁드립니다.#라이비오 #경험공유 #출시 #업무프로세스 #인사이트

어플리케이션 성능 분야에서 평균 응답 시간은 어플리케이션 서버가 사용자에게 요청 결과를 반환하는 데 걸리는 시간을 말합니다. 어플리케이션 서버의 응답시간은 일반적으로 밀리세컨드에 가깝지만 부하량에 따라 많은 시간이 걸리기도 합니다. 고객이 기다리는 시간 3초인터넷 초창기인 1999년 전자 상거래 사이트의 최적로드 시간은 8초 였습니다. 2006년도에 들어서는 4초까지 줄어들었습니다. 그리고 지금은 3초를 고객을 떠나게 만드는 시간으로 이야기 합니다. 구글 이 운영하는 더블클릭(https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/)은 모바일 페이지가 로드되는데 3초가 지나면 사용자의 절반 이상이 서비스를 포기한다고 조사결과를 발표했습니다. 3초라는 시간 속에는 웹페이지의 렌더링 시간과 네트웍이 사용하는 시간등이 포함되어 있기 때문에 웹 어플리케이션이 소모해야 하는 시간은 실제로 밀리세컨드에 가깝습니다. 하지만 실제 서비스의 장애가 발생하면서 웹 어플리케이션의 평균 응답시간은 점점 길어지게 됩니다. 성능분석에서 평균 응답시간부하가 늘어나면서 임계치가 넘어가면 초당 처리량은 더이상 증가하지 않게 됩니다. 논리적으로 생각 해보면 초당 처리량이 더이상 증가하지 않은 상태에서 사용자만 늘어나면 TPS와 인지시간이 상수처럼 동작하므로 응답시간이 사용자에 비례하여 늘어나게 됩니다. [응답시간(Respons Time) = [동시사용자수 / 초당 요청수(TPS)] - 인지시간(Think Time)하지만 일반적인 상황에서 응답시간은 밀리세컨드 단위의 값이데 비해 인지시간은 3초에서 10초 이상의 값을 가지고 됩니다. 그럼 이번에는 성능을 분석하는 스토리를 만들어 보겠습니다. 우리가 영어 문장을 한글로 번역하는 웹 서비스를 만든다고 해 보겠습니다. 우리는 동시 사용자 100명을 예상하고 서비스를 만들고 있습니다. 여기서 서비스 특성상 사용자가 한번 번역을 요청하고 다음번 요청을 보내는데 평균 30초의 시간이 걸립니다. 마지막으로 최대 응답시간은 0.5초를 넘지 않도록 설계하려고 합니다. 이런 경우 우리가 목표로 하는 초당 요청수는 서비스를 동시에 사용하는 사람들의 요청을 시간으로 나누므로 계산식은 동시사용자수(100명)/(응답시간(0.5초) + 인지시간(30초)) 이고 결과값은 약 3.27이 됩니다.     초당 요청수(TPS) = 동시사용자수 / [응답시간(Respons Time) + 인지시간(Think Time)]이렇게 성능을 계산하는 과정에서 서비스의 처리시간 즉 응답시간은 인지시간에 비해 매우 적기 때문에 인지시간이 커지면 커질수록 TPS에 관여하는 비율이 0에 수렴하게 됩니다. 결론적으로 성능을 설계하는 시점에서 응답시간은 별로 중요한 이슈가 아니게 됩니다. 대신 인지시간이 중요해 집니다.인지시간(Think Time)이란?웹 서비스를 사용하는 사용자는 자신의 요청을 확인하는 시간이 필요합니다. 이렇게 이전 요청과 다음 요청 사이의 시간을 인지 시간이라고 합니다. 인지 시간은 사용자나 서비스 유형에 따라 다릅니다. 예를 들어 시스템 간 상호 작용은 사람이 관여하는 웹 서비스 상호작용에 비해 매우 낮은 인지 시간을 포함합니다. 또는 블로그 서비스에 비해 사전검색 서비스의 인지시간은 매우 짧을 것입니다. 서비스의 도메인을 분석하여 인지 시간을 결정하는 것은 매우 중요합니다. 인지시간을 사용하여 분당 완료해야 하는 요청 수는 물론 시스템에서 지원할 수 있는 동시 사용자 수를 계산할 수 있습니다. 튜닝 지표로서의 평균 응답시간현실에서 웹 서비스의 응답시간은 수식과 다르게 나타나게 됩니다. 그래서 많은 성능 분석 도구가 평균 응답시간을 보여주고 있습니다. 실제 성능 분석 도구들이 알려 주는 평균 응답시간은 수집 주기 동안에 수집된 트랜잭션의 응답 시간을 합산하여 평균한 값입니다.와탭의 서비스는 5초 간격으로 트랜잭션의 평균 응답시간을 계산합니다. 응답시간이 성능 지표보다 튜닝지표로서의 의미를 가집니다. 예를 들어 사용자가 적은 밤 시간에 배치잡과 같은 일부 응답시간이 길어짐으로써 사용자가 많은 낮보다 평균 응답시간이 더 길수도 있습니다. 하지만 실제 성능을 올리기 지표로써 응답시간은 매우 직접적입니다. TPS와 상관없이 평균 응답시간이 길어지는 요소가 있다면 주변 요소와 함께 평균 응답시간을 살펴봐야 합니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

전기 공무와 전문건설 공무 합 1년 경력의 커뮤케이션 능력자 안병섭입니다. 언론사 2년 6개월 스크랩 업무 부터 사무보조 및 기타 업무kb카드 도급사 7년 재직 각종 스캔업무와 서버 등록 및 각종 간단한 공사업무엔텍월드 3개월 재직, 하도급 신고, 현장관리, 출역현황표 작성, 내역서 작성 견적 등한신안전산업 2018년 11월~현재 재직중 기성, 퇴직공제작성과 신고 키스콘 등록 및 원, 하도급 관리 및 기성 검토와 실적신고작성 물량 산출 등

가슴이 뛰어분다 어째쓰까잉작년 청와대 만찬주로 유명세를 얻었던 '강서맥주', '달서맥주'에 이어 출시한 '전라맥주'의 카피 문구이다.'대동강', '해운대', '제주위 에일', '서빙고', '강남'... 바야흐로 수제맥주 풍년이다.맥주매니아 '맥덕'의 입맛과 혼술, 홈술 트렌드에 맞춘 각종 수제맥주가 핫플레이스뿐 아니라 편의점과 마트까지 장악하고 있다. 맥주 하면 떠올랐던 3대 맥주 브랜드 중 하나를 골랐던 시대는 이미 먼 산을 넘어섰다. 실로 다양성의 시대이고, 취향 만발의 시대이다.로컬 로망올해 CJ에서 진행했던 <올리브콘>이라는 식문화 트렌드 컨벤션 행사의 주제가 '로칼 로망(Local Roman)'이었다. 강릉에서 스톡홀름까지 지역을 기반으로 자신만의 스타일을 추구하는 로컬 브랜드를 소개함으로써 소비자의 선택이 다양화, 세분화되었음을 널리 알리는 행사였다. 아이러니하게도 대형 F&B 프랜차이즈 브랜드를 운영하는 기업에서 스스로 로컬 브랜드 시대의 도래를 선언하는 장면을 연출하였다.연남동, 경리단길, 해방촌, 가로수길 등 이른바 핫플레이스를 방문해보면 작은 골목에 크지 않은 점포이지만 개성이 한껏 풍기는 상점과 카페들이 즐비하다. 힙한 젊은이들과 개성 넘치는 중년들까지 획일화되지 않은 문화와 컨셉을 즐기는 것에 시간과 돈을 아끼지 않는다. 어딜 가나 동일한 메뉴에 비슷한 인테리어, 유사한 서비스를 제공하는 대형 프랜차이즈가 한편으론 멋대가리 없는 기성복처럼 느껴지기까지 한다. 대형 프랜차이즈의 유일한 장점은 접근성이 좋다는 것과 적어도 평타 치는 품질 정도라고 볼 수 있다. 씁쓸하게도 이런 대형브랜드들은 아마도 직원들의 최저임금 인상률을 걱정해야 하는 편의점 정도의 가치만을 소구 할 수밖에 없을지도 모른다. 더 이상 '혁신'하지 않는다면 말이다.미디어 혁신이 다양성 촉발유투브는 소비자들의 정보 습득 방식을 철저하게 바꾸었다. Z세대의 85%가 유투브로 영상을 시청하고, 이들은 매일 평균 57분을 유투브에 소비한다. 더 중요한 핵심은 유투브에는 다루지 않는 주제가 없다는 것이다. 그야말로 자신이 관심 있어하는 모든 것을 생생한 영상으로 접할 수 있는 것이다. 프로를 넘보는 덕후들이 유투브를 통해서 확산되고, 나름의 고정 팬덤이 생기고, 또 다른 덕후들을 만들어낸다. 과거 미디어가 만들어낸 획일화된 관점과 일방적인 주입은 여기엔 있을 수 없다. 모든 것이 소비자가 선택할 수 있기 때문이다. 소수의 취향도 무시할 수 없으며, 메인스트림과 언더의 차이도 유투브에서는 모호해질 수밖에 없다. 그야말로 인디 브랜드 창궐의 시대이다.대중에서 별종으로유투브 크리에이터 J.Fla는 다른 가수의 원곡을 리메이크해서 부르는 커버 음악 장르에서 이미 세계적인 유명인이다. 자신만의 스타일로 커버 음악을 유투브에 꾸준히 올리면서 현재 구독자 800만 명으로 국내 유투버 1위이자, 전 세계 유투버 아티스트 중 26위에 올랐다. 누군가에겐 커버 음악이라는 장르 자체가 생소하기도 하겠지만, 대중 미디어에서는 잘 알려지지 않은 J.Fla는 1인 브랜드라는 스몰브랜드가 세상에 어떻게 영향력을 미치고 있는지 여실히 보여주고 있다. 과거 대중 문화와 인디문화가 보편성과 양적 규모로 구분되었다면, 이제는 그 경계가 모호해지고 있고, 어디까지가 대중이고 어디서부터가 별종인지 가늠하기 어려워졌다. 기준 자체가 무의미해지고 있다. 누구나 세상의 중심이 될 수 있으며, 차별화할 수 있다면 또한 선택될 수 있다는 믿음을 이미 많은 사례들이 입증해주고 있다.언제까지 숫자로 세상을 볼 것인가?범생이 말고 똘끼가 필요대기업 또는 경쟁률이 높은 기업일수록 좋은 학벌, 즉 범생이의 입사 확률이 높다. 상대적으로 빠른 두뇌회전, 높은 성실성, 게다가 인내심과 근면함까지 갖추고 있다. 특히나 정해진 규범을 잘 준수하고, 내적 동기보다는 외적 동기에 더 민감하게 반응하는 성향을 가지고 있어서, 정해진 트랙과 룰을 가진 무대에서는 뛰어난 성과를 낸다. 하지만 변화가 심한 격변기에, 앞날이 불투명한 시대에는 어떻게 대응해야 할지 어려워한다. 공식에 익숙한 이들에게 창의적인 사고는 익숙해질 수 없기 때문이다. 틀에서 벗어나는 것이 두렵기 때문이다.더군다나 세상을 자신들의 잣대로 판단하려고 한다. 브랜드 가치를 숫자로 읽는다. 좋은 브랜드는 TOM 지표로 측정하고, 광고비 지출을 높이면 인지도와 함께 선호도까지 올라간다고 믿는다. 사업적으로는 무엇을 하더라도 1등을 해야 하고, 규모도 최대, 매출도 최고, 매장 수도 제일 많아야 하는 것을 목표로 한다. 숫자에 민감한 목표 지향적 성향까지 갖추고 있다. 규모의 경제를 통해서 이윤을 최대화해야 하고, 효율성과 표준화를 통해 낭비를 최소화해야 목표를 달성할 수 있다고 믿는다. 브랜드도 그렇게 이해한다.이들의 사적 취향이란 대중이 쉽게 접근할 수 없는 명품 브랜드 중 하나를 선택하는 것뿐이고, 그마저도 가장 유행하는 것을 선택함으로써 가장 안전한 표준편차 범위 안에 들어야 안심이 되는 찌질함까지 갖추고 있다. 대기업에서 엣지 있는 브랜드가 출현하지 못하는 이유가 여기 있다고 본다. 의사결정자의 많은 비율이 이(범생이 부류) 출신들이 차지하고 있기 때문이다. 이래서는 살아남기 어렵다. 궤도를 조정해야 한다.브랜드는 정답이 아니라 선택을 제공하는 것사회가 양극화되면서 계층의 이동이 쉽지 않은 시대에 우리는 살고 있다. 소확행의 실천이 소시민들의 유일한 삶의 위안인 안타까운 시대이다. 한 인간이 각박한 인생에서 한 명의 주체로서 선택할 수 있는 유일한 것이 '브랜드'이다. 브랜드는 소시민에게 소비자로서 '갑'의 권력을 안겨줄 수 있는 유일한 대상인 것이다. 따라서 소비자의 선택지가 많아질수록 결정의 쾌감이 커질 것이며, 자신의 존재 역시 이를 통해 체감할 수 있다.나는 선택한다, 고로 존재한다바야흐로, 선택을 통해 살아있음을 느낄 수 있는 시대이다.스몰 브랜드는 그것 자체로 매우 철학적이다.