VCNC는 커플을 위한 모바일 앱 비트윈을 서비스하고 있습니다. 비트윈은 사진, 메모, 채팅, 기념일 등 다양한 기능을 제공하며, 오픈 베타 테스트를 시작한 2011년 11월부터 현재까지 연인 간의 소통을 돕고 있습니다. 그동안 비트윈 시스템 아키텍처에는 많은 변화가 있었으며 다양한 결정을 하였습니다. 비트윈 아키텍처를 발전시키면서 배우게 된 여러 가지 노하우를 정리하여 공유해보고자 합니다. 그리고 저희가 앞으로 나아갈 방향을 소개하려 합니다.소프트웨어 스택Java: 비트윈 API서버는 Java로 작성되어 있습니다. 이는 처음 비트윈 서버를 만들기 시작할 때, 서버 개발자가 가장 빨리 개발해낼 수 있는 언어로 프로그래밍을 시작했기 때문입니다. 지금도 자바를 가장 잘 다루는 서버 개발자가 많으므로 여전히 유효한 선택입니다.Netty: 대부분의 API는 HTTP로 호출되며, 채팅은 모바일 네트워크상에서의 전송 속도를 위해 TCP상에서 프로토콜을 구현했습니다. 두 가지 모두 Netty를 통해 사용자 요청을 처리합니다. Netty를 선택한 것은 뛰어난 성능과 서비스 구현 시 Thrift 서비스를 통해 HTTP와 TCP 프로토콜을 한 번에 구현하기 쉽다는 점 때문이었습니다.Thrift: API서버의 모든 서비스는 Thrift 서비스로 구현됩니다. 따라서 TCP뿐만 아니라 HTTP 또한 Thrift 인터페이스를 사용합니다. HTTP를 굳이 Thrift서비스로 구현한 이유는, TCP로 메세징 전송 시 똑같은 서비스를 그대로 사용하기 위함이었습니다. 덕분에 빠른 채팅 구현 시, 이미 구현된 서비스들을 그대로 사용할 수 있었습니다. 또한, 채팅 패킷들은 패킷 경량화를 위해 snappy로 압축하여 송수신합니다. 모바일 네트워크상에서는 패킷이 작아질수록 속도 향상에 크게 도움이 됩니다.HBase: 비트윈의 대부분 트랜젝션은 채팅에서 일어납니다. 수많은 메시지 트랜젝션을 처리하기 위해 HBase를 선택했으며, 당시 서버 개발자가 가장 익숙한 데이터베이스가 HBase였습니다. 서비스 초기부터 확장성을 고려했어야 했는데, RDBMS에서 확장성에 대해 생각하는 것보다는 당장 익숙한 HBase를 선택하고 운영하면서 나오는 문제들은 차차 해결하였습니다.ZooKeeper: 커플들을 여러 서버에 밸런싱하고 이 정보를 여러 서버에서 공유하기 위해 ZooKeeper를 이용합니다. Netflix에서 공개한 오픈 소스인 Curator를 이용하여 접근합니다.AWS비트윈은 AWS의 Tokyo리전에서 운영되고 있습니다. 처음에는 네트워크 및 성능상의 이유로 국내 IDC를 고려하기도 했으나 개발자들이 IDC 운영 경험이 거의 없는 것과, IDC의 실질적인 TCO가 높다는 문제로 클라우드 서비스를 이용하기로 하였습니다. 당시 클라우드 서비스 중에 가장 안정적이라고 생각했던 AWS 를 사용하기로 결정했었고, 지금도 계속 사용하고 있습니다.EC2: 비트윈의 여러 부가적인 서비스를 위해 다양한 종류의 인스턴스를 사용 중이지만, 메인 서비스를 운용하기 위해서는 c1.xlarge와 m2.4xlarge 인스턴스를 여러 대 사용하고 있습니다.API 서버: HTTP 파싱이나 이미지 리시아징등의 연산이 이 서버에서 일어납니다. 이 연산들은 CPU 가 가장 중요한 리소스이기 때문에, c1.xlarge를 사용하기로 했습니다.Database 서버: HDFS 데이터 노드와 HBase 리전 서버들이 떠있습니다. 여러 번의 테스트를 통해 IO가 병목임을 확인하였고, 따라서 모든 데이터를 최대한 메모리에 올리는 것이 가장 저렴한 설정이라는 것을 확인하였습니다. 이런 이유 때문에 68.4GB의 메모리를 가진 m2.4xlarge를 Database 서버로 사용하고 있습니다.EBS: 처음에는 HBase상 데이터를 모두 EBS에 저장하였습니다. 하지만 일정 시간 동안 EBS의 Latency가 갑자기 증가하는 등의 불안정한 경우가 자주 발생하여 개선 방법이 필요했는데, 데이터를 ephemeral storage에만 저장하기에는 안정성이 확인되지 않은 상태였습니다. 위의 두 가지 문제를 동시에 해결하기 위해서 HDFS multiple-rack 설정을 통해서 두 개의 복제본은 ephemeral storage에 저장하고 다른 하나의 복제본은 PIOPS EBS에 저장되도록 구성하여 EBS의 문제점들로부터의 영향을 최소화하였습니다.S3: 사용자들이 올리는 사진들은 s3에 저장됩니다. 사진의 s3키는 추측이 불가능하도록 랜덤하게 만들어집니다. 어차피 하나의 사진은 두 명밖에 받아가지 않고 클라이언트 로컬에 캐싱되기 때문에 CloudFront를 사용하지는 않습니다.ELB: HTTP는 사용자 요청의 분산과 SSL적용을 위해 ELB를 사용합니다. TCP는 TLS를 위해 ELB를 사용합니다. SSL/TLS 부분은 모두 AWS의 ELB를 이용하는데, 이는 API서버의 SSL/TLS처리에 대한 부담을 덜어주기 위함입니다.CloudWatch: 각 통신사와 리전에서 비트윈 서버로의 네트워크 상태와 서버 내의 요청 처리 시간 등의 메트릭을 CloudWatch로 모니터링 하고 있습니다. 따라서 네트워크 상태나 서버에 문제가 생긴 경우, 이메일 등을 통해 즉각 알게 되어, 문제 상황에 바로 대응하고 있습니다. Netflix의 Servo를 이용하여 모니터링 됩니다.현재의 아키텍처처음 클로즈드 베타 테스트때에는 사용자 수가 정해져 있었기 때문에 하나의 인스턴스로 운영되었습니다. 하지만 처음부터 인스턴스 숫자를 늘리는 것만으로도 서비스 규모를 쉽게 확장할 수 있는 아키텍쳐를 만들기 위한 고민을 하였습니다. 오픈 베타 이후에는 발생하는 트래픽에 필요한 만큼 여러 대의 유연하게 서버를 운영하였고, 현재 채팅은 TCP 위에서 구현한 프로토콜을 이용하여 서비스하고 있습니다.HTTP 요청은 하나의 ELB를 통해 여러 서버로 분산됩니다. 일반적인 ELB+HTTP 아키텍처와 동일합니다.채팅은 TCP 연결을 맺게 되는데, 각 커플은 특정 API 서버로 샤딩되어 특정 커플에 대한 요청을 하나의 서버가 담당합니다. 비트윈에서는 커플이 샤딩의 단위가 됩니다.이를 통해, 채팅 대화 내용 입력 중인지 여부와 같이 굉장히 빈번하게 값이 바뀌는 정보를 인메모리 캐싱할 수 있게 됩니다. 이런 정보는 휘발성이고 매우 자주 바뀌는 정보이므로, HBase에 저장하는 것은 매우 비효율적입니다.Consistent Hashing을 이용하여 커플을 각 서버에 샤딩합니다. 이는 서버가 추가되거나 줄어들 때, 리밸런싱되면서 서버간 이동되는 커플들의 수를 최소화 하기 위함입니다.클라이언트는 샤딩 정보를 바탕으로 특정 서버로 TCP연결을 맺게 되는데, 이를 위해 각 서버에 ELB가 하나씩 붙습니다. 어떤 서버로 연결을 맺어야 할지는 HTTP 혹은 TCP 프로토콜을 통해 알게 됩니다.Consistent Hashing을 위한 정보는 ZooKeeper를 통해 여러 서버간 공유됩니다. 이를 통해 서버의 수가 늘어나거나 줄어들게 되는 경우, 각 서버는 자신이 담당해야 하는 샤딩에 대한 변경 정보에 대해 즉각 알게 됩니다.이런 아키텍처의 단점은 다음과 같습니다.클라이언트가 자신이 어떤 서버로 붙어야 하는지 알아야 하기 때문에 프로토콜 및 아키텍처 복잡성이 높습니다.서버가 늘어나는 경우, 순식간에 많은 사용자 연결이 맺어지게 됩니다. 따라서 새로 추가되는 ELB는 Warm-up이 필요로 하며 이 때문에 Auto-Scale이 쉽지 않습니다.HBase에 Write연산시, 여러 서버로 복제가 일어나기 때문에, HA을 위한 Multi-AZ 구성을 하기가 어렵습니다.한정된 자원으로 동작 가능한 서버를 빨리 만들어내기 위해 이처럼 디자인하였습니다.미래의 아키텍처현재 아키텍처에 단점을 보완하기 위한 해결 방법을 생각해보았습니다.Haeinsa는 HBase상에서 트렌젝션을 제공하기 위해 개발 중인 프로젝트입니다. 구현 완료 후, 기능 테스트를 통과하였고, 퍼포먼스 테스트를 진행하고 있습니다. HBase상에서 트렌젝션이 가능하게 되면, 좀 더 복잡한 기능들을 빠르게 개발할 수 있습니다. 서비스에 곧 적용될 예정입니다.Multitier Architecture를 통해 클라이언트와 서버 간에 프로토콜을 단순화시킬 수 있습니다. 이 부분은 개발 초기부터 생각하던 부분인데, 그동안 개발을 하지 못하고 있다가, 지금은 구현을 시작하고 있습니다. 커플은 특정 Application 서버에서 담당하게 되므로, 인메모리 캐싱이 가능하게 됩니다. 클라이언트는 무조건 하나의 ELB만 바라보고 요청을 보내게 되고, Presentation 서버가 사용자 요청을 올바른 Application 서버로 릴레이 하게 됩니다.Multitier Architecture를 도입하면, 더 이상 ELB Warm-up이 필요하지 않게 되므로, Auto-Scale이 가능하게 되며, 좀 더 쉬운 배포가 가능하게 됩니다.Rocky는 API 서버의 Auto-Failover와 커플에 대한 샤딩을 직접 처리하는 기능을 가진 프로젝트입니다. 현재 설계가 어느 정도 진행되어 개발 중에 있습니다. 알람이 왔을 때 서버 팀이 마음을 놓고 편히 잠을 잘 수 있는 역할을 합니다.기본적인 것은 위에서 언급한 구조와 동일하지만 몇 가지 기능이 설정을 추가하면 Multi-AZ 구성이 가능합니다.특정 커플에 대한 모든 정보는 하나의 HBase Row에 담기게 됩니다.HBase의 특정 리전에 문제가 생긴 경우, 일정 시간이 지나면 자동으로 복구되긴 하지만 잠시 동안 시스템 전체에 문제가 생기가 됩니다. 이에 대해 Pinterest에서 Clustering보다는 Sharding이 더 낫다는 글을 쓰기도 했습니다. 이에 대한 해결책은 다음과 같습니다.원래는 Consistent Hashing을 사용하여 커플들을 Application 서버에 샤딩하였습니다. 하지만 이제는 HBase에서 Row를 각 리전에 수동으로 할당하고, 같은 리전에 할당된 Row에 저장된 커플들은 같은 Application 서버에 할당하도록 합니다.이 경우에, 같은 커플들을 담당하는 Application 서버와 HBase 리전 서버는 물리적으로 같은 머신에 둡니다.이렇게 구성 하는 경우, 특정 HBase 리전이나 Application 서버에 대한 장애는 특정 샤드에 국한되게 됩니다. 이와 같이 하나의 머신에 APP과 DB를 같이 두는 구성은 구글에서도 사용하는 방법입니다.이와 같이 구성하는 경우, Multi-AZ 구성이 가능하게 됩니다.AWS에서 같은 리전에서 서로 다른 Zone간 통신은 대략 2~3ms 정도 걸린다고 합니다.Presentation의 경우, 비동기식으로 동작하기 때문에 다른 리전으로 요청을 보내도 부담이 되지 않습니다.HBase에서 Write가 일어나면 여러 복제본을 만들게 됩니다. 하나의 사용자 요청에 대해 Write가 여러번 일어나기 때문에 HBase연산의 경우에는 서로 다른 Zone간 Latency가 부담으로 작용됩니다. Haeinsa가 적용되면, 한 트렌젝션에 대해서 연산을 Batch로 전송하기 때문에 AZ간 Latency 부담이 적습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

스타트업은 말 그대로 아무것도 없는 상태이다. 제대로 된 제품도 없고, 사람도 없고, 그리고 돈도 없다. 스타트업 대표에게는 많은 임무가 있지만 그중에 하나가 돈을 구하는 것이다. 극단적으로 돈이 없어도 창업 멤버들이 허리띠를 졸라매고 제품을 만들어낼 수 있지만 그건 정말 쉽지 않은 일이다. 가끔 스타트업 모임에 가면 대표들의 여러 걱정 중에 많은 부분을 차지하는 것이 직원들 월급을 밀리지 않게 줄 돈을 구하는 것이다.   한국에서 스타트업이 돈을 구할 수 있는 방법은 크게 4가지가 있다. 매출, 투자, 정부지원금, 대출이다. 각각의 장단점이 있기 때문에 각 스타트업 대표는 그 상황과 전략에 맞게 돈을 구해서 팀원들이 걱정 없이 일 할 수 있는 환경을 만들어 주는 것이 중요하다.일단 스타트업이 돈을 구하는 가장 바람직한 방법은 스타트업이 추구하는 제품과 서비스를 통해서 매출을 얻어내는 것이다. 하지만 어떻게 보면 초기 스타트업에게 4가지 방법 중에서 가장 어려운 방법이다. 제품과 서비스를 통해서 매출을 얻어내고 손익 분기점을 돌파해서 외부의 도움 없이도 팀을 이끌어나가고 지속적인 성장을 위한 투자를 할 수 있는 재원을 얻어낸다면 이미 그 스타트업은 비즈니스 모델을 시장에서 검증했고 이미 성공했다고 볼 수 있다.하지만 위에서 설명한 경우는 정말 극히 드문 케이스이다. 대부분의 경우 제품과 서비스를 검증받고 손익 분기점에 도달하기 전까지 많은 시간과 노력이 필요하다. 그래서 일부 한국의 스타트업이 선택하는 방법 중에 하나가 외부 용역을 통해서 매출을 만들어내는 경우다. 많은 엔지니어 출신들이 창업한 기술 스타트업들이 자신들의 기술적 노하우와 노력을 대기업에 팔아서 매출을 만들어내고 직원들의 월급을 준다. 그리고 그 돈으로 자신들의 본업에 투자하는 계획을 세워놓는다. 하지만 현실은 그러하지 못하다. 주위에 많은 기술 스타트업들이 그렇게 대기업의 기술 용역 업체로 전락하고 자신들의 꿈과 비전은 사라져 버린 케이스를 많이 보았다. 그 이유는 현실에서는 대기업이 기술 용역 업체에게 꿈과 비전을 이룰 수 있을 만큼의 초과이익을 절대로 주지 않기 때문이다. 한국 대기업들은 기술 용역 업체에게   기술료는커녕 용역 비용조차 제대로 가치를 쳐서 주지 않는다. 한국의 IT 혹은 기술 용역 시장은 건설 막노동 시장과 다를 바 없는 구조로 되어 있기 때문에 여기서 돈을 벌어서 미래를 위한 투자 재원을 마련하겠다는 생각은 너무나 순진한 생각이다.나도 창업 초기에 이러한 순진한 생각을 했고 A사, B사와 같은 한국의 대기업으로부터 기술개발과제를 받아와서 매출을 만들어냈고 직원들의 월급을 주었다. 대부분의 직원들은 용역과제에 붙어 있고 일부 직원으로 미래를 위한 투자를 하겠다는 순진한 생각을 가지고 있었다. 하지만 현실 속에서는  초과이익은커녕 지친 몸과 정신으로 인해 꿈과 비전을 잊어버리고 창업에 대한 회의감만이 생겨났다. 꿈을 이루기 위해 창업을 한 것인지 나와 직원들의 월급을 위해 창업을 한 것인지에 대한 회의감이 생기고 내부의 직원들 또한 사기가 저하될  수밖에 없었다.그렇기 때문에 제품과 서비스를 통한 매출이 아닌 용역을 통한 매출을 통해서 스타트업이 돈을 구하는 것은 개인적으로 추천하지 않는다. 오히려 '사즉생 생즉사'의 자세로 꿈과 비전에 승부를 걸고 안된다면 깔끔하게 손 터는 것이 더 좋지 않을까 생각한다.다음번에는 '투자'를 통한 돈 구하기에 대해서 이야기해보고자 한다.#NEOFECT #스타트업 #스타트업창업 #창업자 #매출 #비즈니스모델 #BM #수익모델 #자금유치 #꿀팁 #인사이트

Semantic Versioning 소개Versioning?소프트웨어 개발 생태계는 수많은 사람들이 서로의 기술과 성과를 이어받아 오며 믿을 수 없는 수준의 협력 체제를 구축해오고 있습니다. 의존성은 이러한 협력체제에서 나오게 된 요소로, 다른 사람들이 만들어온 기능을 다시 만들 필요 없이 손쉽게 가져와서 재활용하는 방식으로 빠르게 소프트웨어를 만들 수 있게 되었습니다.하지만 이렇게 여러 사람에게 이용되는 패키지가 새롭게 업데이트될 때, 생각보다 다양한 문제에 직면하게 되었습니다. 기능의 사용법을 바꾸어버리거나 동작 방식의 변경 같은 변화들은 그에 의존하는 다른 소프트웨어를 의도대로 동작하지 못하게 하므로, 새로운 변화와 기존의 것을 구분할 필요가 생겼습니다. 버전이라는 개념은 이러한 패키지의 변화를 구분하기 위해 사용하기 시작하였습니다.Semantic Versioning?버전이라는 코드 형태의 구분방식은 많은 핵심 문제를 해결해주었지만, 아직 여러 과제가 남아있었습니다. 버전 명의 작성 방식에 관한 기준이 패키지마다 제각각 다른 것이 문제였습니다. 0.x와 1.x의 차이, 1.0.0 혹은 1.000. 선행 배포와 정식 버전의 구분 방법 등 모든 소프트웨어, 패키지는 저마다의 기준을 가지고 있었으며, 이는 어느 정도의 적당한 공통점이 있었지만, 그 점이 미묘하게 모두 차이가 있어 버전에 따른 의미 해석을 어렵게 하였습니다.Semantic Versioning은 Github의 공동창업자인 Tom Preston-Werner가 위의 문제를 해결하기 위해 기존의 현안을 모아 만든 제안입니다. 스펙 문서는 RFC 2119에 의해 규칙을 표기하여 의미적 엄격함을 높이고, 패키지 개발 생명주기에 발생할 수 있는 여러 상황을 포괄적으로 담아 일관성과 유연성을 균형 있게 갖추고 있습니다.규칙다음은 Semantic Versioning(v2.0.0-rc1)의 스펙을 한국어로 번역한 내용입니다.1. Semantic Versioning을 쓰는 소프트웨어는 반드시 공개 API를 정의해야 한다. 이 API는 코드 자체에 정의되어 있거나 명시적으로 문서화 되어있어야 한다. 이 과정은 포괄적이며 정확해야 한다.2. 일반 버전 명은 반드시 X.Y.Z 형태를 보여야 하며 X, Y, Z는 음이 아닌 정수이다. X는 주요한 버전이며, Y는 작은 버전, Z는 패치버전이다. 각 요소는 1씩 차례로 증가해야 한다. 예: 1.9.0 -> 1.10.0 -> 1.11.0.3. 주요 버전 숫자가 올라갈 때, 작은 버전 숫자와 패치 버전 숫자는 0으로 재설정되어야 한다. 작은 버전 숫자가 올라갈 때, 패치 버전 숫자는 0으로 재설정되어야 한다. 예: 1.1.3 -> 2.0.0, 2.1.7 -> 2.2.04. 버전 명이 주어진 패키지가 한번 공개되면, 해당 버전의 내용은 절대 수정되어선 안된다. 어떤 수정도 반드시 새로운 버전으로 공개되어야 한다.5. 주요 버전 0 (0.y.z)은 초기 개발을 위한 것이다. 언제든 변경될 수 있다. 공개 API는 안전하지 않다고 여긴다.6. 버전 1.0.0은 공개 API를 정의한다. 이 공개 이후의 버전 숫자가 바뀌는 방법은 공개 API와 변경 방법에 따라 결정된다.7. 패치 버전 Z (x.y.Zx > 0)는 하위호환을 하지만 버그 수정이 있을 때 올라간다. 버그 수정은 내부적으로 잘못 처리되고 있는 것을 고치는 것을 의미한다.8. 작은 버전 Y (x.Y.zx > 0)는 새로운 기능이 추가되었지만 기존의 공개 API가 하위호환되고 있을 때 올라간다. 공개 API가 하나 이상 deprecated될 시에도 올라가야 한다. 부가적인 새 기능이나 개선이 내부 코드 (private code)에 있을 시에도 올릴 수 있다. 이는 패치 수준의 변화를 포함할 수 있으나, 작은 버전이 올라가면 패치 버전은 꼭 0이 되어야 한다.9. 주요 버전 X (X.y.zX > 0)는 하위호환되지 않는 변화가 추가될 때 반드시 올라가야 한다. 이는 패치 수준과 작은 수준의 변화를 포함할 수 있으나, 주요 버전이 올라가면 작은 버전과 패치 버전은 꼭 0이 되어야 한다.10. 선행 배포 버전은 대시(-)와 점으로 나누어진 식별자들의 묶음을 패치 버전 뒤에 표시한다. 식별자들은 ASCII 영숫자와 대시로만 구성되어야 한다. [0-9A-Za-z-]. 선행 배포 버전은 연관된 일반 버전보다 낮은 우선순위를 가진다.11. 개발 버전은 더하기(+)와 점으로 나누어진 식별자들의 묶음을 패치 버전 뒤에 표시한다. 식별자들은 ASCII 영숫자와 대시로만 구성되어야 한다. [0-9A-Za-z-]. 빌드 버전은 연관된 일반 버전보다 높은 우선순위를 가진다.12. 우선순위는 주요, 작은, 패치, 선행 배포, 빌드 식별자 내 숫자 순으로 계산되어야 한다. 주요, 작은, 패치 버전은 항상 숫자로 비교되어야 한다. 선행 배포와 빌드 버전의 우선순위는 반드시 각 점으로 나누어진 식별자들이 아래 규칙에 따라 비교되어야 한다: 1. 숫자로만 이루어진 식별자는 숫자로 비교 (2) 문자와 대시가 포함된 식별자는 ASCII 정렬 순서대로 비교. 숫자 식별자는 숫자가 아닌 식별자보다 낮은 우선순위를 가진다. 예: 1.0.0-alpha < 1>응용여러 오픈소스 프로젝트들이 이미 Semantic Versioning에 따라 버전 명을 표기하기 시작하였으며, 해당 규칙에 기반을 둔 버전 비교 라이브러리도 만들어지고 있습니다.•node.js: https://github.com/isaacs/node-semver•PHP: https://github.com/GordonSchmidt/SemVer•Python: https://github.com/k-bx/python-semver•Ruby: https://github.com/iantruslove/SemverStringerseaport는 node.js 에서 서비스 클러스터들이 Semantic Versioning에 따라 버전 의존성을 가지게 설계할 수 있어 보다 안정적인 버전 협상이 가능하도록 하고 있습니다.server.js:var seaport = require('seaport');var ports = seaport.connect('localhost', 9090);var http = require('http');var server = http.createServer(function (req, res) {res.end('beep boop\r\n');});server.listen(ports.register('[email protected]'));client.js:var seaport = require('seaport');var ports = seaport.connect(9090);var request = require('request');ports.get('[email protected]', function (ps) {var u = 'http://' + ps[0].host + ':' + ps[0].port;request(u).pipe(process.stdout);});output:$ node server.js &[1] 6012$ node client.jsbeep boop마치며비록 작은 통일일지는 모르나, 버전 명을 작성하는 훌륭한 기준이 있다는 것은 장기적으로 개발 생태계를 더욱 빠르고 긴밀하게 협력하도록 도와줄 것이라 생각됩니다. 의미적 해석이 가능한 코드는 의존성 문제를 더 똑똑한 수준으로 자동화할 수 있기 때문이죠. 버전 명을 지으실 때 좋은 안내서가 되었으면 좋겠습니다.#스포카 #개발 #개발자 #개발팀 #꿀팁 #인사이트

백엔드 서비스를 만들고 운영하는 개발자라면, 지금 바로 APM 서비스를 사용해 보세요. 와탭의 APM은 국내 수많은 Enterprise 기업에서 자사의 서비스를 분석하기 위해 사용되고 있으며 많은 효과를 보고 있습니다. 북미에서는 이미 수많은 스타트업이 DevOps의 기본 도구로 APM을 선택하고 있습니다. APM은 원래 대규모 서비스를 운영하는 분들이 전문적으로 사용하고 있었지만 최근 트렌드는 운영자에서 개발자로 이동하고 있는 서비스 이기도 합니다. 특히 와탭의 APM은 개발자 분들을 위한 스택 분석 기능이 있습니다. 개발자라면 와탭 APM 서비스가 제공하는 아래의 3가지 스택 분석 기능을 꼭 사용해 보세요. 유니크 스택탑 스택액티브 스택많은 개발자들이 자신이 만든 서비스가 어떻게 동작하는지 또는 웹 서비스에 어떤 영향을 주고 있는지 알지 못합니다. 하지만 와탭 애플리케이션 성능 모니터링(APM) 서비스를 사용하면 메소드가 애플리케이션에서 어떻게 사용되는지 얼마나 사용되는지 알수 있습니다. 와탭은 다른 APM 서비스와 다르게 10초에 한번씩 활동중인 트랜잭션을 검사하여 트랜잭션에 콜스택정보를 저장하고 있습니다. 그리고 이렇게 저장된 스택정보를 가지고 3가지 형태로 가공하여 보여주는데, 이 것이 유니크 스택 / 탑 스택 / 액티브 스택입니다. 먼저 유니크 스택은 가장 많이 사용된 스택 정보를 보여주는 방식입니다. 트랜잭션에서 실행되고 있는 메소드가 A 이고 이를 호출한 메소드가 모두 일치하는 스택을 유니크 스택이라고 합니다.1. A() ← C()2. A() ← C()3. B() ← D()4. B() ← E()5. B() ← F()위와 같은 경유 유니크 스택은 아래와 같이 통계를 내어 보여 줍니다. 40% A()    A()    C()20% B()    B()    D()20% B()    B()    E()20% B()    B()    F()이렇게 콜스택 정보 전체를 기준으로 분석을 하는 경우에는 성능에 영향을 주는 기능 단위의 분석이 가능합니다. 하지만 성능에 영향을 많이 주는 메소드를 알고 싶을 때가 있습니다. 이런 경우에 사용하는 것이 탑 스택 분석입니다. 아까와 같은 상황을 예를 들겠습니다.1. A() ← C()2. A() ← C()3. B() ← D()4. B() ← E()5. B() ← F()이런 상황에서 탑 스택 분석은 아래와 같이 가장 많이 사용되느 메소드를 알려줍니다. 60% B()    33% D()    33% E()    33% F()40% A()    100% C()유니크 스택에서는 A() ← C() 가 가장 많이 사용된 스택이라는 것을 알려주지만 탑 스택에서는 B() 메소드가 가장 많이 사용된 메소드라는 것을 알려줍니다. 이 두가지 내용을 통해 가장 많이 사용되는 메소드의 집합가 가장 많이 호출되는 메소드를 알아 낼 수 있습니다. 만일 서비스를 메소드 단위에서 개선하고 싶다면 이 정보를 기반으로 개선 작업을 진행하면 많은 도움을 받을 수 있습니다. 위에 화면에서 메소드를 선택하면 메소드를 호출한 스택들의 정보를 확인 할 수 있습니다. 마지막으로 액티브 스택입니다. 액티브 스택은 WAS 서버와 URL 그리고 발생 시간을 기준으로 저장된 콜스택의 정보를 보여줍니다. 서비스 성능이 떨어진 시간대의 콜스택 정보를 확인 함으로써 메소드 구간에서의 튜닝 정보를 제공합니다. 액티브 스택은 핵심 기능이 하나더 있습니다. 바로 서비스가 동작하는 스탭정보에 통합됨으로써 문제를 바로 확인할 수 있는 기능입니다. 와탭의 APM에서만 분석가능한 기능이며 특허로 등록되어 있습니다. 액티브 스택은 통계 관점이 아니라 실행 관점에서 문제를 바라보고 있습니다. 우리가 만든 웹 어플리케이션을 고객에 입장에서 보면 아래와 같이 동작합니다. 고객 → 웹 서비스 요청 → 서버 접속 → 서비스 접속 → 애플리케이션1 → 메소드 1 → DB 1접근 → Query 1 → Query 2 → 메소드 2 → 파일 접근 → 메소드 3 → 결과 취합 → WAS 통과 → 웹 서비스 결과 반환 일반적으로 애플리케이션 모니터링은 이런 상항을 아래와 같이 보여줍니다. 서비스 접속 → Query 1 → Query 2 → 파일 접근 → 트랜잭션 종료와탭의 애플리케이션 모니터링은 수집된 콜 스택 정보를 기반으로 아래와 같이 보여줍니다.  서비스 접속 → Query 1 → 메소드 2 → Query 2 → 파일 접근 →메소드 3 → 트랜잭션 종료위에 상황은 트랜잭션에서 메소드 2와 메소드 3이 수집된 경우에 트랜잭션의 스탭의 실행시간에 맞쳐서 정보를 재구성하는 것을 보여주고 있습니다. 이렇게 확인하게 된다면 메소드에서 발생하는 성능 문제를 확인 할 수 있습니다. APM 서비스는 와탭 / 뉴렐렉 / 데이터 독과 같은 서비스들을 통해서 2주에서 한달간 언제든 무료로 사용가능합니다. 다만 메소드에 대한 분석 기능은 와탭의 APM에서만 제공하는 기능들이 많습니다. 개발자라면 한번쯤 와탭의 APM 서비스를 통해 자신이 만들고 운영하고 있는 서비스에서 가장 많이 사용되는 메소드가 무엇인지 확인 해 보시기 바랍니다. Tip!! APM은 개발시에 사용하는 디버깅 도구라기 보다는 막대한 량의 트랜잭션이 발생하는 운영과정에서 사용되는 도구입니다. 트랜잭션 자체가 적다면 원하는 데이타가 안 나올 수 도 있습니다. 와탭으로 모니터링 하기 - 목차 바로가기#와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지 #서비스소개

여러 인공지능 서비스가 우후죽순 생겨나고 있습니다. 그리고 각각의 '인공지능 비서'들이 내세우는 주요 기능 중 하나는 바로 일정 관리죠. 그럴만도 한것이 일정관리야 말로 인간이 가장 큰 보조를 받을 수 있는 영역 중 하나이기 때문이라고 할 수 있겠습니다.개인 비서가 없어봐서 모르겠지만 영화나 드라마를 보면 주로 훤칠하게 잘생긴, 또는 아름다운 비서가 회장님이 묻기도 전에 그의 다음 일정을 알려줍니다. 내가 언제, 어디서, 무엇을 해야 하는지 끊임 없이 기록하고 상기 시켜주는 사람이 옆에 있다면 나의 삶도 여러모로 편해질수 있지 않을까요.이러한 측면에서 볼 때 다양한 인공지능 서비스가 나오고 있다는 점은 환영 할 일이지만, 그 서비스들이 실질적으로 사람들의 삶에 도움이 되는 기능들을 갖추고 있느냐는 완전히 다른 차원의 질문이 될 수 있습니다. 이름만 인공지능일 뿐이지 할줄 아는 것이라고는 내가 입력한 일정을 당일 아침에 읊어주는 수준이라면, 그것을 '비서'라고 부르기에는 부족할지 모릅니다.대부분의 사람들이 일정을 놓치게 되는 이유는 주로 해당 일정을 기록해두지 않기 때문입니다. 바쁜 생활 속에서 모든 일을 일일히 기록하기는 매우 어렵고, 나중에 해야지라는 생각으로 묻혀두었던 일정들은 어느새 지나있기 마련이죠.진정으로 똑부러지는 일정 도우미라면 내가 일정을 직접 입력하기도 전에 내가 선호할 만한 일정들을 먼저 정리하여 제시할 수 있어야 합니다. 우리는 여러개의 일정 중 가장 끌리는 것을 선택하기만 하면 되는것이죠. 그렇다면 위와 같이 사용자가 일정을 입력하기 전 먼저 선택지를 제시하기 위해서는 무엇이 필요할까요?현재 히든트랙팀에서 제공하고 있는 일정구독서비스, 린더( https://linder.kr )는 화장품 세일일정, 학교 학사일정, 프로야구 경기 일정 등 다양한 일정들을 한데 모아 개인의 캘린더로 구독 받을 수 있도록 돕고 있습니다. 현재까지 약 2만명의 사용자가 7천개가 넘는 다양한 일정들을 받아보고 있죠.아직 린더의 데이터는 아이돌 스케줄, 학사일정, 프로야구 경기일정 등에 국한되어 있지만, 이후 공연 티켓팅, 쇼핑몰 세일 등 다양한 분야로 확장해나갈 계획입니다. 기존에 심한 건망증으로 매번 놓쳤던 티켓팅이나 세일 일정이 있다면 린더를 통해 해당 일정을 놓치지 않고 실행에 옮길수 있게 되는것이죠.내가 직접 기록하지 않더라도 내 캘린더의 표시 되어있는 일정을 통해 행사나 이벤트에 참여할 수 있으며 주요 일정들에 대해서는 푸시알림을 통해 일정 시작 전 행사 정보를 파악 할수 있습니다. 락페스티벌을 좋아하시는분이라면 주요 락페스티벌의 티켓팅 및 공연 일정을 받아볼수 있고, 마라톤을 좋아하시는 분이라면 연간 마라톤 일정을 미리 확인 할 수 있게 되는것이죠.현재 린더는 캘린더를 통해 일정을 제공하고 있지만 이는 어디까지나 린더가 정보를 제공하는 여러 채널 중 하나일뿐입니다. 포화 된 앱 시장에서 돌파구를 찾고자 일시적으로 캘린더 플랫폼을 사용하고 있지만, 저희가 확보하고 있는 일정 데이터는 캘린더 뿐만이 아닌 모바일앱, 챗봇, AI스피커 등 다양한 형태로 제공 될 수 있습니다.캘린더에 표시도 안 한 2학기 수강신청을 10분 전에 내게 먼저 알려줄수 있는 앱이 있다면 멋지지 않을까요. 아침에 일어나자마자 고대하던 신상 구두가 출시 되었음을 알려주는 스피커가있다면 사랑스럽지 않을까요.잊고 있었던 티켓팅, 화장품 세일, 축구 경기, 신상 출시를 알려주는 당신만의 비서를 만들기 위해 저희 팀에서는 지속적으로 서비스를 개선해나가고 있습니다.아직 써보지 못하셨다면 사용해보신후 가감없는 피드백 부탁드리며, 내가 만들어도 이것보다 잘만들겠다 싶으신분이 있으시면 제게 연락주세요 ( [email protected] ). 제가 잘 꼬드겨서 저희팀으로 모셔갈수 있도록 하겠습니다 :)2017년 8월 2일. 목을 다쳐 하루종일 침대에 누워있지만 더 이상 잠은 안오는 어느날 밤.#히든트랙 #챗봇 #기술기업 #개발자 #개발팀 #인사이트 #경험공유

구글의 데이터 시각화 도구 데이터 스튜디오(Data Studio)데이터 스튜디오는 올해 초 분석 스위트의 일부로 도입됐던 데이터 시각화 도구로, 구글 애드워드(AdWords), 구글 스프레드시트 및 다른 구글 제품의 데이터를 시각화할 수 있도록 다양한 데이터 커넥터가 포함되어 있다. 빅쿼리(BigQuery)가 통합되어 있으며, SQL 데이터베이스도 활용이 가능한 상태이다.각자 기업들이 추출하고 모아온 데이터를 복잡한 원본 데이터를 더 잘 이해할 수 있도록 시각화한 보고서를 만들어 내 외부로 공유할 수 있도록 한다. 이 보고서에는 그래프와 도표, 열지도 등이 포함된다.그래서 좋은 점은.SQL, GA 등 추출해서 보기 힘든 데이터를내 맘대로 요리조리 '마케팅 대시보드'를 작성하기 좋은 툴이다.그러면 어떻게 시작해야 할까?그래서 손쉽게 보실 수 있도록 캡쳐해봤습니당.구글 애널리틱스 메인 화면우선 구글애널리틱스에 접속해주세요.로그인을 해주시면 계정단에 이렇게 화면이 나오실 겁니다.오른쪽 상단 2번째에 있는 아이콘을 클릭해주세요.아이콘 클릭 후 '데이터스튜디오'를 클릭해주시면 됩니다.구글 데이터 스튜디오네! 들어오셨군요!그러면 대시보드는 이렇게 구성되어 있구요.보고서 작성을 원하시면 상단에 + 대시보드 / 하단 +링크를 눌러주시면 됩니다.들어오시면 뭐지? 하실거에요. 빈 화면이 나오는데보고서에 연동할 데이터소스를 선택해주시면 됩니다.커넥터 지원애드워즈클라우드 SQLDCM구글 애널리틱스구글 스프레드 시트MYSQLPostgreSQLYouTube 애널리틱스예로 들어 MYSQL을 커넥팅을 하신다면 데이터베이스에 관련 정보를 입력하시면 됩니다.애드워즈를 연결한다면 내가 볼 데이터를 선택하시고 보고서에 추가하면 됩니다.데이터 소스에 원하는 데이터를 선택하셨으면, 원하시는 데이터를 조합하세요그런데 혹시나 대시보드 작성이 번거로우시다면 탬플릿을 이용하시면 됩니다 (편집가능)이만 건포어였습니다 :)#오누이 #구글 #구글데이터 #데이터스튜디오 #구글데이터스튜디오 #데이터분석 #마케팅 #마케터 #꿀팁 #인사이트 #경험공유

안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 컨택틱의 이이삭 대표입니다.이번 성공사례 시리즈에는 우드래픽 (대표 이명섭)이라는 업체의 아마존 여정을 소개하고자 합니다. 이명섭 대표님은 글로벌셀러 창업연구소에서도 활발하게 활동하는 열정 회원이며, 컨택틱의 업무대행 서비스를 포괄적으로 받은 분이시기도 합니다. 우드래픽의 이명섭 대표님에 대한 간단한 소개를 해드리자면, 원래 대기업에서 근무를 하시다가 목공 쪽으로 열정이 있으셔서 사업을 하게 되신 분입니다. 원래는 취미 생활로 목공 쪽으로 관심을 가지셨는데, 기존 목공 제품들에 대한 개선점을 파악하고 직접 OEM을 의뢰하여 제조를 하게 된 케이스입니다. 국내 목공 커뮤니티에서도 판매를 해보셨는데 판매가 잘 되어서 아마존까지 진출하게 되셨죠.우드래픽의 아마존 여정은 꼭 순탄하다고만 할 수는 없었습니다. 컨택틱은 우드래픽의 아마존 입점에서부터, 최적화된 상품 등록, FBA 입고, 마케팅까지 관여를 했었는데, 아마존의 특성상 ‘상품’ 중심적인 시장이라, 첫 상품인 ‘도브 테일 가이드’를 출시했는데, 반응이 나쁘지 않은 편이었지만 그렇다고 만족할만한 매출을 내지는 못했습니다.그런 상황에서 우드래픽의 이명섭 대표님은 포기하지 않고 계속해서 후속 제품들을 출시하고 아마존에 론칭하면서 결국 전체적으로 매출이 상승하게 되는 흐름을 타게 되셨습니다. 현재는 대략 10개 정도의 MSKU (옵션형 리스팅까지 포함)를 가지고 아마존을 운영하고 계시며 정말 너무나도 멋지게도 ‘단 한 번도 성장하지 않은 날이 없는 판매 그래프’를 보이고 있습니다. 아래에 그 표를 함께 보셨으면 합니다:수많은 업체들을 대상으로 대행하고 컨설팅하면서 느낀 점 중에 하나는 ‘끈기와 열정을 가진 자는 아마존에서 성공할 수밖에 없다’입니다. 우드래픽의 이명섭 대표님의 시작은 소소했지만, 위에서 보이듯이 계속해서 성장하고 계시며, 제가 조심스레 예측하건대 우드래픽은 2019년에는 위보다 훨씬 더 큰 성장을 이룰 것이라고 확신합니다. 유통기한이 없는 목공제품이라는 뛰어난 카테고리에서, 대기업 제품들의 퀄리티와 견주어봐도 손색없는 퀄리티, 그리고 무엇보다 이명섭 대표님의 식지 않는 아마존에 열정이 반드시 우드래픽을 아마존의 독보적인 목공 브랜드로 거듭할 거라 믿습니다.컨택틱이 직접 대행하거나 컨설팅한 업체들 중 우드래픽과 같은 성공사례들이 매우 많습니다. 어떤 경우에 성적이 부진했는지, 어떤 경우에 성공적인 결과를 거두었는지 컨택틱은 데이터가 쌓일 때마다 분석하고 있습니다. 그리고 그 데이터를 기반으로 더 완성도 높은 대행 서비스와 교육 자료를 만들어내고 있습니다. 컨택틱은 글로벌셀러창업연구소와 손을 잡고 여러분들께서 궁금해할 만한 질문들에 대해 전부 답변해드리고, 더 나아가서 아마존 진출 전략을 구축할 수 있도록 아마존에 대한 기초와 심화 교육 과정들을 제공하고 있습니다. 아래 URL을 통해 아마존 교육이 필요하신 분들은 관심 가져주시길 바랍니다.오프라인 아마존 입문 과정온라인 아마존 입문 과정온라인 아마존 기초/심화 과정그럼 오늘도 즐거운 글로벌 셀링 되세요!감사합니다.컨택틱서울특별시 서초구 서초대로 356, 606호(서초동, 서초지웰타워)대표 전화: 02-538-3939이메일: [email protected]홈페이지: https://www.kontactic.com네이버 블로그: https://blog.naver.com/kontactic카카오 브런치: https://brunch.co.kr/@allaboutamazon

어딘가로 떠나는 퇴사 로망을 꿈꾸던 내게, 스타트업 행이라는 기회가 열려버렸다. 그리고 에이전시 UI 디자이너였던 내가, 스타트업 UX 디자이너가 됐다."괜찮아요? 지낼만해요?"라는 질문에는"후하, 심호흡 좀 하고 말할게요."라고 답하고 싶다.4달이 지난 이 시점에서, 어떤 변화가 있었는지 풀어 보려 한다.괜.찮.아.요?역할을 바꿨더니 모든 역할(기획자, 디자이너, 개발자)의 마음이 이해되기 시작했다.1. 기획자 입장수정을 해야 했던 기획자의 그 마음이 이해되더라이전에는 UI만 담당했기에 종종, 기획을 틀어버리는 기획자가 원망스러웠다. 사용자 경험을 고려해 전체 플로우를 짜 놓은 상태에서, 부분적으로 바뀐 기획안을 보고 있자면 물음표 투성이었다. 또한 약 200여 장 넘는 문서를 다루면서 바뀐 기획을 반영하는 데는 꽤 많은 공수가 들기도 했었기에 너그럽지 못했다.그런데 기획부터 UI까지 함께 하다 보니 기획자의 마음과 그 과정이 이해된다.막상 디자인(image)과 개발된 것(interaction)을 보면  더 나은 방향이 떠오르기에,머리는 하나지만 고민할 케이스는 수십 가지기에,어제의 내가 정답이 아니기에, 등등(문제는 오늘의 나도 정답이 아닐 수 있다)2. 디자이너-개발자 입장수정을 마주하는 그 마음도 이해되더라수정에 민감했던 나의 과거를 생각하며... 이제는 막을 수 없다면 줄이자 ^*^ 기획 단계에서 최대한 많은 파이의 고민을 하고, 구현 전에 디자이너-개발자와 함께 검토하는 시간을 가져야 오류를 최소화할 수 있다. (무려 시행착오 끝에... 오늘에서야 깨달았다!)고상하게 표현했지만, 후폭풍을 막기 위해서는 기획서를 두고 서로를 설득하기 위한 치열한 논의가 필요하다.3. UX 디자이너 입장나의 다음 스텝(진화과정)이 이해되더라이전에는 여러 프로젝트를 병행했기에 기획 쪽 이슈는 팀 내 시니어에게 전달받았고, 디자인-개발의 이슈의 경우엔 이슈 리스트로만  주고받았다. 또한 디자이너들과 소통할 일이 90%였고, 눈빛만 봐도 척하면 척이었기에 나의 역할을 잘 수행하는 것이 가장 큰 목표였다.하지만 이제는 '기획-디자인-개발' + 운영팀의 흐름을 항상 놓치지 않아야 할 역할이 되었다.이전에는 디자인 팀을 관리하는 PM(프로젝트 매니저)이 다음 스텝이었다면, 스타트업에서는 프로덕트를 관리하는 PO(프로덕트 오너)가 다음 스텝이라는 것.(지난해 함께 합류하게 된 개발자 호성님께서 '스크럼'이라는 프로젝트 방법론을 제시하셨다. '스크럼'을 실행한 지 2달 여째, 나는 나의 역할이 조금씩 이해되고 있다.)아우, 쓰고 보니 한참 멀었다.변화의 묘미근래에 스타트업 생활을 하면서 와 닿았던 두 대표님의 이야기가 있다." 지금까지도 그래 왔고, 앞으로도 새로운 것을 만들어나가는 사람들이기에 어려운 문제들과 상황들을 잘 해결하려고 부담 갖기보다 조금 더 즐기며 도전하는 마음가짐으로 맞이 합시다 "  8퍼센트 이효진 대표님" 스타트업 생활을 하면서 '이렇게 세상을 빠르게 변화시킬 수 있는 사람들과 함께 일을 할 수 있다는 것'이 큰 힘이 되었습니다. "패스트캠퍼스 이강민 대표님아직은 이해하는 단계지만, 이 무지막지한 모든 변화들이 스타트업에서만 겪을 수 있는 묘미인 것 같다.핀테크를 꿈꾸며... 열일중인 인(人)테크의 현장#8퍼센트 #에잇퍼센트 #협업 #사내문화 #조직문화 #팀플레이 #팀워크

첫 직장을 그만두고(2012년 2월),두 번째 직장을 다니다가 결심을 하고 나오게 되었다.(2013년 11월)몇 번이고 사표를 내려다가도날 믿고 결혼한 아내 생각에 꾸~욱 참았던 순간이 얼마나 많았더냐.좀 더 버티자!좀 더 참자!좀 더 견디자!군 전역하고 창업한 적도 있고,대학생활 내내 사업할 거라고 꿈꾸던 나에게직장생활은 꼭 거쳐야 하는 관문이었다.기술도 배워야 하고,조직도 배워야 하고,돈도 모아야 하고...사실 월급이 가장 큰 이유였지 뭐.카드 대금은 밀리지 않아야 하니까.그리고 치솟는 물가와 전세금!직장생활로는 또이또이가 어렵다는 단순 계산!첫 직장과 두 번째 직장의 대표들에게 배울 점이 많았다.직원으로서 불만이 없던 것은 아니지만,역으로 경영진으로써 본받을 점들도 있었고,고민할 점들도 체크할 수 있었다.그렇게 탈출을 결심했다.

센스 없는 사람은 정말이지... 참을 수 없어나는 '박치'이다.음의 높낮이를 구별 못하는 ‘음치’보다 더 드물다는 박자를 맞추지 못하는 ‘박치’이다. -_-;;; 어릴 때 피아노를 배웠던 적이 있었는데, 번지수를 잘 못 찾았던 것이다. 메트로놈도 나의 엇박을 교정할 수 없었던 기억이 아직도 생생하다. (노래방이라는게 생기면서 그나마 노래라는 것도 가능해 진 것에 감사할 뿐이다)학습으로 도저히 안되는 것이 있는 것 같다. 상대적으로 나는 운동신경이 꽤 좋은 편이다. 야구를 하던,테니스를 치던 왠만한 운동들은 남들보다 빠르게 익히고, 어렵지 않게 따라하는 편이다. 정식으로 레슨을 받지 않고도 쉽게 선수들의 자세를 흉내낼 수 있고, 레슨을 받더라도 진도가 빠른 편이다. 반면에 똑같은 레슨을 받더라도 도무지 습득하지 못하거나, 아예 따라하지 못하는 '몸치'도 종종 볼 수 있다.옷 입는 센스가 뛰어나거나, 말 빨을 타고난 사람, 미감이 풍부한 사람, 눈치가 재빠른 사람, 음악적 재능을 타고난 사람이거나 타고난 미적 감각을 가진 사람들... 불공평할지도 모르지만, 태어날 때부터 타고난 감각은 분명히 존재하는 것 같고, 아쉽지만 사람마다 각각 다른 것 같다.센스란 무엇인가?센스란 '고해상도의 체화된 지식의 총체'이다.KAIST의 뇌과학자 김대식 교수의 이야기 중에 "우리가 여러가지 색과 패턴을 가진 사과를 보고 '빨간 사과' 라고 표현할 수밖에 없는 것은 언어의 해상도가 생각의 해상도보다 더 낮기 때문이다" 라는 표현이 상당히 인상적이었다. 센스라는 것도 인간이 지식이라는 형태로 표현할 수 없을 만큼 촘촘한 고해상도의 감각 또는 지식이라는 표현이 적절할 것 같다.센스는 고해상도의 체화된 지식타고난 능력의 해상도의 차이 때문에, 누구는 어렵고 복잡한 지식을 쉽게 체득하지만, 어떤 사람들에게는 굉장히 고생스러운 과정이 되기도 한다. 뛰어난 미감을 가진 사람은 맛의 해상도가 굉장히 높기 때문에 미묘한 맛의 차이를 쉽게 구분해 낼 수 있지만, 짜고 맵고 달고 쓰고 정도의 구분만 가능한 사람들에게는 맛있거나 맛없거나 정도의 차이만 느껴질 수밖에 없다.결국 감각의 해상도가 얼마나 촘촘하냐에 따라서, 동일한 지식을 습득하거나, 발휘하는 역량에 차이가 나는 것이다.패션 감각이 꽝인 당신의 남자친구가 어느 순간 센스 쩌는 모습으로 바뀔 수 있다고 믿는가?또한, 센스는 굉장히 복합적이고 미묘하게 작동하게 때문에 이것을 분절하여 나누어 표현하는 것도 상당히 어렵다. 말 재주가 뛰어난 사람에게 '어떻게 하면 당신처럼 말을 잘 할 수 있어요?'라고 물어본다면, 아마 뛰어난 화술의 비법을 몇 가지 원칙으로 쉽게 설명하기도 어려울 뿐만 아니라, 원칙을 익히더라도 그 사람처럼 모든 상황을 능수능란하게 대처할 수도 없다. 그 만큼 복잡하고, 자신에게 체화되어 있지 않으면 발휘되기 어려운 능력이다.센스, 과연 학습될 수 있을까?천재는 노력하는 자를 이길 수 없고, 노력하는 자는 즐기는 자를 이길 수 없다?10,000 시간의 법칙을 알고 있을 것이다. 충분히 많은 시간을 투입하여 노력하면 선천적 재능을 따라 잡을 수 있다는 '노력하면 된다' 라는 믿음의 표현이다. 투입하는 노력이 성과에 어느정도 비례 상관관계를 가질 수 있다고 생각한다. 하지만, 핵심은 어느 분야에 10,000시간을 투입할 것이냐의 문제이다.잭 햄브릭 미시간주립대 교수 연구팀은 노력과 선천적 재능의 관계를 조사한 88개 논문을 대상으로 연구를 진행했고, 국제적 권위의 심리학 학술지인 ‘심리과학’에 최근 과학계의 해묵은 논쟁을 잠재울 수 있는 연구 논문을 발표했다. 연구 결과 학술 분야에서 노력한 시간이 실력의 차이를 결정짓는 비율은 4%에 불과한 것으로 나타났다. 음악·스포츠·체스 등의 분야는 실력의 차이에서 차지하는 노력 시간의 비중이 20~25%였다. 어떤 분야든 선천적 재능이 없으면 아무리 노력해도 대가가 될 수 있는 확률은 그리 높지 않다는 결론이다. 햄브릭 교수는 “한 분야에서 최고가 되기 위해서는 꾸준한 노력이 필수적이지만 선천적 재능과 비교했을 때 대부분의 사람이 생각하는 것만큼 절대적인 요소는 아니다”고 설명했다.[출처: 중앙일보] 노력하면 된다? … '1만 시간의 법칙' 틀렸다우울한 이야기일 수 있지만, 한편으로는 현실을 직시해야 할 좋은 포인트일 수 있다는 것이다.고해상도 재능 발견이 교육의 시작나는 모든 사람에게 타고난 재능이 있다고 믿는다. 그 재능이 어느 영역인지 발견하지 못할 뿐이다. 아이들에게 타고난 재능이 있더라도, 그것을 발견할 수 있는 안목이 없는 부모라면, 또는 재능과 무관하게 부모의 희망 분야에 아이들의 1만 시간을 투입하게 하는 무모한 노력뿐이라면, 아이들은 힘겨운 인생을 살아가게 될 것이다.음악에 재능이 있는 아이가 공부가 아닌, 슈퍼스타 K에서 자신의 재능을 발견하는 모습을 보는 것은 정말 행운인 것이다. 예술적인 감각 뿐만이 아니라, 사람과 잘 어울리는 social 능력도 중요한 재능이 될 수있고, 셈이 뛰어나고 흥정에 능한 재능이 뛰어난 사업가의 싹이 될 수도 있다. 내성적이지만 정교한 손재주로 세계적인 헤어디자이너가 될 수 있으며, 시니컬하지만 냉철한 관찰력을 가진 아이가 훌륭한 비평가로 성장할 수도 있는 것이다.10년이나 20년 후면 현재 각광 받는 직업들의 위상이 많이 달라져있을 것이다. 인공지능에 의해 사라질 직업들도 많다고 한다. 직업의 귀천을 떠나서, 100시간으로 1만 시간의 효과를 낼 수 있는 분야에 노력을 기울일 것인지, 10만 시간으로도 100시간의 성과밖에 이룰 수 없는 일에 자신의 인생을 소모할 것인지에 대해서 스스로 선택해야 한다. 이미 늦었다고 생각한다면, 자녀들에게는 그런 선택이 주어져야 한다.부모가 해야 할 일은 자신이 원하는 것을 자식에게 대리 투영하는 것이 아니라, 자식이 잘 할 수 있는 재능을 찾아 주는 것이다. 최소한 아이들이 무엇을 잘하는지 기다려주고 지켜봐주는 것이다. 부모 스스로 자녀의 재능을 발견하지 못한다면, 영어 수학 학원이 아니라 다양한 종류의 분야의 전문가에게 그것을 판별할 수 있게 기회를 마련해줘야 한다.이 나라가 이 모양인 것도 어찌보면 사람을 보는 '센스'가 없기 때문일지도 모른다. 쩝...

스티비를 운영하다 보면 이런 질문을 가끔 받습니다.“이메일에 수신거부 링크를 꼭 삽입해야 하나요?”“수신거부 링크를 아주 작게, 잘 안 보이게 해도 될까요?”수신거부 링크가 거슬리는 것, 이해합니다. ‘수신거부 링크가 잘 보이고 누르기 편할수록 수신거부하는 구독자가 늘어나지 않을까?’하는 고민이 생길 수밖에 없습니다.일반 상식과는 약간 다른 접근법을 제안해 드립니다. 수신거부보다 스팸신고가 더 큰 재앙이기 때문입니다. 스팸신고를 막기 위해 수신거부를 적절히 이용할 필요가 있습니다. 왜 스팸신고가 재앙인지, 스팸신고를 막기 위해 수신거부를 어떻게 활용할지 알아보겠습니다.1. 스팸신고가 왜 재앙인가?수신거부는 이메일 수신을 중단하고 싶은 의사가 있는 구독자 1명에게만 영향을 미칩니다. 구독자 A가 수신거부를 했다고 해서 다른 구독자들에게 미치는 영향은 전혀 없습니다.그러나 스팸신고는 다릅니다. 만약 Gmail을 사용하는 구독자 A가 스팸신고를 한다면, Gmail을 사용하는 모든 구독자들에게 영향을 미칠 수 있습니다. Gmail과 같은 메일박스 프로바이더(Mailbox Provider; 이메일 주소를 생성하여 이메일을 보내고 받고 보관하게 해 주는 서비스)는 스팸신고가 많이 들어온 이메일 발신자를 학습해서 스팸 필터링에 활용합니다. 즉 Gmail을 사용하는 구독자가 특정 이메일의 스팸신고를 많이 한다면, 스팸신고를 하지 않은 다른 Gmail 사용자에게도 이메일이 도달하지 않고 스팸편지함에 빠질 수 있는 것입니다. 이렇듯 한명 한명의 스팸신고가 누적되면 발신자의 평판이 낮아져서 원래 이메일을 잘 받아보고 있던 구독자에게도 도달하지 못할 수 있습니다.Gmail이 스팸을 인식하는 방법2. 점점 쉬워지는 수신거부스팸신고라는 재앙을 피하기 위해 다양한 해결책이 등장하고 있습니다. Gmail과 iOS10 기본 메일앱 등에서는 일부 이메일에서 ‘수신거부’ 또는 ‘구독 취소’ 기능을 이메일 상단에서 쉽게 사용할 수 있도록 제공합니다. 스팸신고보다 수신거부를 유도하기 위해서입니다. (자세한 내용 보기: 9 Things You Need to Know About Email in iOS 10)Gmail에서 ‘수신거부’ 기능을 제공한다iOS10의 기본 메일앱에서 ‘구독 취소’ 기능을 제공한다3. 수신거부 문구도 색다르게아무리 스팸신고라는 대재앙을 피했다 하더라도, 설레는 마음으로 이메일을 보냈는데 수신거부가 되돌아오면 마음이 아픕니다. 이럴 때 “수신을 원치 않으면 수신거부를 클릭하세요”처럼 딱딱하고 건조한 문구로는 아쉬운 마음을 전할 수 없습니다. 아쉬운 마음을 담은 부드럽고 진지한 수신거부 문구를 소개합니다.“이메일을 그만 받고 싶으면, 수신거부 하세요. 서로 감정 상하지 않기로 해요.” NextDraft“떠나는 게 아쉽긴 하지만, 언제든 바로 수신거부 할 수 있어요.” Hitne’s SaaS Weekly“만약 도움이 되지 않는다 생각하시면 구독해지를 해주세요.” 오픈서베이수신거부를 확인하는 랜딩페이지에서는 더 많은 메시지를 전달할 수 있습니다. 동영상을 활용하는 것도 좋은 방법입니다.“가까웠던 우리 사이가 벌써 그리워요.” HubSpot (클릭하면 동영상을 확인할 수 있습니다.)스팸신고를 막기 위해 수신거부가 왜 중요한지 알아봤습니다. 중요한 내용만 요약하면 아래와 같습니다.수신거부가 편해야 더이상 관심없는 구독자를 떨궈내고 핵심 구독자에게 집중할 수 있다.수신거부 링크를 못 찾은 구독자가 귀찮은 마음에 스팸신고를 눌러버리면 그것이야말로 진정한 재앙이다.한명 한명의 스팸신고가 누적되면 발신자의 평판이 낮아져서 핵심 구독자의 메일함에서도 스팸처리되는 재앙이 생길 수 있다.더 읽어보기: Why an Unsubscribe is Better Than Being Marked as Spam ― Litmus#슬로워크 #마케팅 #마케터 #마케팅팀 #꿀팁 #조언

오전 6시 30분. 휴대전화 알람이 울리기 시작한다. 부랴부랴 샤워를 끝내고, 나갈 채비를 하고 있으니, 5분 후 집 앞 버스 정류장에 회사로 향하는 100번 시내버스가 도착한다는 메세지가 나타났다. 버스에 몸을 싣고 사무실 근처 정류장에 내려서 걸어가는 도중, 필자가 즐겨 마시는 커피를 맛있게 내린다는 동네 카페에 대한 정보를 받았다. 어느새 다가온 점심시간에는 어제 이태원에서 과음한 것을 어떻게 알았는지, 휴대폰 잠금화면에 주변 해장국집 추천이 뜬다.그저 영화 속 이야기가 아니다. 실제 사용자의 취향과 행동 등을 분석하고, 시간, 날씨, 교통 등과 같은 외부적 환경요소를 정교하게 더한 시나리오다. 각 개인에게 필요하고, 일상을 윤택하게 만들 수 있는 유의미한 정보를 제공하는 것. ‘맥락인식’ 혹은 ‘상황인지 기술’이라고 불리는 ‘Context Recognition’의 궁극적인 목표 중 하나다.맥락인식 기술은 여러 센서로부터 수집한 데이터를 통해 사용자의 상황을 인지하고, 실시간으로 맥락을 이해하는 데 초점을 맞춘다. GPS, 와이파이, RFID, 모션 센서, 소리 등 여러 시그널을 수집해 분석하며, 사용자의 일정, 문자 메시지나 행동 정보 등을 가져와 ‘사용자가 어떤 사람인지’, 그리고 ‘현재 어떤 상황인지’ 등을 추론한다. 이와 같은 맥락인식 기술을 구현하기 위해 필요한 몇 가지 주요기술은 다음과 같다.1. 상황정보 수집사용자 인터페이스 또는 센서, 센서 네트워크 등를 통해 사용자의 위치, 활동, 생활 패턴 등 다양하고 복잡한 정보를 수집하는 기술.2. 상황정보 모델링상황정보를 가공, 저장 및 공유하는 모델링 기술.3. 상황정보 융합 및 추론사용자의 상황정보를 다른 기술과 융합해 높은 수준의 추론 기능을 제공하는 기술.4. 상황정보 교환센서, 장치 및 객체와의 상호작용을 지원하기 위해 이벤트 기반의 통신 메커니즘을 제공하는 기술.5. 지능형 에이전트사용자의 단순한 의도뿐만 아니라 감정이나 감성을 고려해 전체 상황을 자율적으로 판단, 사용자에게 적합한 서비스를 제공하는 기술.기업 입장에서 생각했을 때, 맥락인식 기술은 소비자 개인에게 특화된 서비스를 제공할 수 있는 날카로운 검이다. 간단한 예로 맥락인식을 활용한 맞춤형 광고에 대해 알아보자. 소비자 A와 소비자 B는 서울에 사는 30대 남성이고 스포츠를 좋아한다. 일반적인 검색이나 구매 히스토리에 기반한 광고와 달리 맥락인식 기술을 활용하면, 이들의 라이프스타일이나 행동패턴을 바탕으로 더 깊은 디멘션까지 분석해 세분화된 광고를 제공할 수 있다. 두 소비자 모두 스포츠를 좋아한다고 가정했을 때, A는 한강 근처에서 매일 저녁 7시 정도에 조깅하는 것을 좋아할 수 있고, B는 남산에서 새벽 6시부터 등산하는 것을 좋아할 수 있다. 미묘한 차이겠지만, 분명 다른 카테고리의 소비자로 정의할 수 있는 것이다.스켈터랩스에서 진행하고 있는 맥락인식 기술 프로젝트를 예로 들어보자. 앞서 언급한 것처럼 다양한 기기로부터 측정하는 저레벨 데이터를 수집하는 것으로 맥락인식 프로세스는 시작된다. 측정 데이터는 서버에 전송되어 시간 순으로 변경 및 취합되고, 기계학습을 통해 필터링 후 수집되며, 고레벨의 맥락으로 추상화된다. 시간, GPS, 와이파이, 모션센서, 소리, 문자메시지, 일정 등 여러 데이터를 처리해 사용자의 맥락을 이해한다. 이러한 일련의 과정 역시 맥락인식 기술의 한 부분인지라 메시지 스트림 프로세서를 기반으로 확장할 수 있는 인프라를 설계, 구축했다.실시간으로 데이터를 처리할 수 있는 파이프라인이다. 처리한 데이터는 좀 더 상위 레벨의 이벤트와 행동으로 인식되어 ‘의미‘를 지니는 데이터로 표현되는데, 예를 들어 GPS 정보를 와이파이 및 시간 등과 같은 다른 데이터와 결합하고, 방문 장소와 행동반경 등을 포함해 사용자의 장소를 식별하는 방식이다. 이러한 사용자의 행동 히스토리는 패턴인식 기술을 활용해 사용자 특정 행동을 학습하고, 이를 기반으로 ‘언제 집으로 돌아갈지‘, 혹은 ‘언제 식사를 하는지’ 등 행동을 예측할 수 있다. 결국, 맥락인식을 통해 사용자의 다음 활동을 예측할 수 있는 기술을 개발, 사용자에게 필요하고 유용한 정보와 서비스를 제공하는 것이 목표다.< 맥락인식 기술을 적용한 큐 앱 화면, 출처: 스켈터랩스 한지예, 이해연 디자이너 >얼마 전, 스켈터랩스의 맥락인식 기술 프로젝트 팀은 해당 기술을 활용해 사용자들이 일상 속에서 가볍게 사용할 수 있는 서비스가 무엇일까 고민하고, ‘큐(Cue)’라는 앱을 개발했다. 큐는 사용자가 직접 명령할 필요가 없다. 큐가 먼저 사용자의 생활을 돕기 때문이다. 날씨를 예를 들면, 사용자가 날씨를 알아보기 전에 비가 올 것 같으면 우산을 챙기라 알려주고, 덥거나 미세먼지가 많을 경우 도움 되는 정보를 알려준다. 사용자에게 전달하는 정보는 카드 메시지를 통해 잠금화면으로 표시된다.큐 프로젝트의 이민학 시니어 프로덕트 매니저는 큐를 통해 사용자가 ‘내'가 누구인지 파악할 수 있을 것이라고 말한다. 예를 들어, 나는 내가 운동을 좋아하는 액티브한 라이프스타일을 살고 있는 줄 알았는데, 실제로는 집에 누워서 영화보는 것을 더 좋아하는 사람에 가깝다는 것. 개인의 삶이 매우 중요해지는 시대이지만, 정작 내가 누구인지 확인하기 어렵기 때문에 맥락인식 기술은 다양한 용도로 사용될 수 있다.< 사용자 패턴을 분석한 유형 결과 예시, 출처: 스켈터랩스 한지예, 이해연 디자이너 >이민학 매니저는 맥락인식 기술에 대해 이렇게 말한다. 그는 “누가, 언제, 어디서, 무엇을, 어떻게, 왜로 구성된 사용자의 육하원칙을 파악하고, 더 나아가 ‘Next-육하원칙’을 파악하는 것이 진정한 맥락인식 기술입니다. 앞으로 기업 특히, 마케터들은 타겟 고객을 잡는데 굉장히 유용하게 사용할 것이라고 생각합니다”라며, “소비자 입장에서는 일상, 문화, 생활 등 세분화된 영역에서 자신의 삶을 더 윤택하게 영위할 수 있습니다. 맥락인식 기술이야말로 인간에게 정말 도움될 수 있는, ‘피부에 와닿는' 인공지능 기술이 아닐까 생각합니다”라고 설명했다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업