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 부담이 적습니다.프리젠테이션다음은 2월에 있었던 AWS 유저 그룹 세미나에서 발표했던 자료 입니다. 비트윈 서버 아키텍처에 대해서 배포 방법을 중심으로 설명이 되어 있습니다. 비슷한 내용이 많이 있으니 살펴보시기 바랍니다.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/e4af60d05bb6013025f71231381b23b3?" 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;">

OverviewiOS 프로그래밍을 하면서 많이 접했던 단어 중 하나는 오토 레이아웃(Auto Layout) 입니다. 스토리보드에서 화면을 만들 때 오토 레이아웃을 이용해서 뷰와 컨트롤의 크기와 위치를 지정합니다. 이미 잘 사용하고 있지만 문득 정확하게 오토 레이아웃은 무엇인지 궁금해져 이번 기회에 써 보기로 했습니다. 오토 레이아웃(Auto Layout)은?오토 레이아웃(Auto Layout)은 제약 조건(Constraints)을 이용해서 뷰의 위치를 지정하는 것입니다. 다시 말하면, 두 뷰 사이의 관계를 제약 조건이라는 것을 이용해서 뷰의 크기와 위치를 지정하는 것입니다. 너와 나의 연결 고리!오토 레이아웃은 여러 해상도를 지원하려고 이 세상에 나왔습니다. 아이폰의 크기가 다양해지면서 해상도도 달라졌는데, 다른 크기에서도 같은 화면을 똑같이 보여주기 위해 오토 레이아웃을 사용합니다. 세로 보기 화면뿐만 아니라 가로 보기 화면까지도 지원합니다. 아이폰SE 혹은 아이폰8 Plus에서도 같은 비율의 화면을 볼 수 있도록 오토 레이아웃을 사용하는 것입니다. 만약 오토 레이아웃을 사용하지 않는다면, 아이폰 기종마다 스토리보드를 만들어야 하죠. 이렇게 되면 스토리보드 파일이 많아집니다. 앱을 실행할 때 아이폰 기종을 확인하고, 그에 맞는 스토리보드를 찾아 화면을 보여주는 번거로움도 생깁니다. 위의 이미지를 보면 아이폰SE와 아이폰8, 아이폰8 Plus 브랜디 앱 화면. 기종이 달라도 보여지는 화면이 똑같다는 것을 볼 수 있습니다. 오토 레이아웃을 이용해서 하나의 스토리보드에서 모두 대응할 수 있는 것이죠.Frame Layout vs Auto Layout전통적으로 앱은 유저 인터페이스를 각 뷰의 프레임(frame)을 프로그래밍 방식으로 계산해 배치합니다. 유저 인터페이스를 배치하려면 뷰 계층의 모든 뷰에 대한 크기와 위치를 계산해야 합니다. 그리고 변경이 발생하면 영향을 받는 모든 뷰에 대해 프레임을 다시 계산합니다.Frame Layout뷰의 프레임을 프로그래밍 방식으로 정의하면 유연해집니다. 어떤 변화가 생겨도 대응할 수 있기 때문입니다. 그러나 모든 변경 사항을 직접 관리해야 하기 때문에 많은 노력이 필요합니다. 설계부터 시작하여 디버그 및 유지 관리까지 많은 것을 관리해야 합니다. 가장 효과적인 방법이지만 난이도도 많이 어려워집니다.이와 달리 오토 레이아웃은 일련의 제약 조건을 사용하여 유저 인터페이스를 정의합니다. 제약 조건은 앞서 말한 것 처럼, 일반적으로 두 뷰 간의 관계를 나타냅니다. 그런 다음 오토 레이아웃은 이러한 제약 조건을 기반으로 각 뷰의 크기와 위치를 계산합니다.Auto Layout화면에 배치하는 모습이 같기 때문에 프레임 방식을 사용해도 되고, 오토 레이아웃을 사용해도 됩니다. 둘 다 스위프트와 오브젝티브 C를 지원하기도 합니다. 각각 장단점이 있지만 가장 많이 사용하는 방법이 오토 레이아웃입니다. 빠르게 적용할 수 있고 많은 시간을 줄일 수 있기 때문입니다.스토리보드에서의 오토 레이아웃iOS 앱 개발은 스토리보드를 이용해서 화면을 만듭니다. 그래서 스토리보드가 익숙한 개발자들이 많은데, 사실은 뷰를 배치하면서 썼던 툴이 오토 레이아웃과 관련된 것이었습니다.스토리보드 오른쪽 하단에 있는 메뉴핀(Pin) 메뉴는 버튼 또는 레이블과 같은 UI 요소에 새로운 제약 조건들을 추가할 수 있습니다. 시계 방향으로 Top, Trailing, Bottom, Leading 제약 조건의 값을 입력할 수 있고, 화살표를 누르면 어떤 뷰와 관계를 가질 것인지 선택할 수 있습니다. 두 뷰와 핀 메뉴를 선택하면 같은 너비와 높이를 설정할 수 있습니다.Pin 메뉴정렬(Align) 메뉴는 다른 뷰와의 가로, 세로 정렬과 같은 정렬 제약 조건들을 추가할 수 있습니다. 정렬하고 싶은 두 뷰를 선택하여 수직 정렬, 수평 정렬을 추가할 수 있습니다.Align 메뉴맨 오른쪽 메뉴인 오토 레이아웃 이슈 툴은 오토 레이아웃 관련된 이슈들을 해결하는 옵션들을 제공합니다. 오토 레이아웃을 현재 설정된 상태로 재설정하는 옵션들입니다. 상단은 선택된 뷰와 관련된 것이고, 하단은 모든 뷰와 관련된 것입니다.Resolve Auto Layout IssuesAlign 옆에 있는 Stack 메뉴는 복잡한 제약 조건 없이 오토 레이아웃의 기능을 쉽게 뷰를 배치할 수 있도록 스택에 쌓아서 묶어주는 스택뷰를 생성합니다. 하나의 묶음으로 만들 뷰들을 선택하여 Stack 메뉴를 선택하면 스택처럼 그룹으로 됩니다. 여기서 뷰 사이의 공간과 정렬들을 설정할 수 있습니다.Stack View로 만든 간단한 뷰, 오른쪽 메뉴에 정렬과 뷰 사이의 공간을 선택할 수 있는 곳이 있습니다.스토리보드에서 뷰를 배치하고 오토 레이아웃 메뉴들을 이용하면 아래 스크린샷과 같이 제약 조건들을 볼 수 있습니다. 어떤 값을 지정하는 것이 아닌 같다는 뜻의 “=“를 이용하여 제약 조건들을 표현합니다.스토리보드에서 많이 볼 수 있는 제약 조건들(Constraints)프로그램 상의 제약 조건들스토리보드에서만 제약 조건들을 설정할 수 있는 건 아닙니다. 프로그램 상에서도 제약 조건들을 설정할 수 있습니다. 스토리보드에서 뷰를 배치한 다음, 제약 조건들을 소스 파일과 연결해서 값을 지정할 수 있습니다. 주로 어떤 변화가 일어나면 제약 조건들을 다시 설정할 때, 프로그램 상에서 값을 다시 설정합니다. 예를 들어, 데이터가 있을 땐 해당 뷰를 보여줍니다. 만약 데이터가 없으면 그 뷰가 사라지면서 그 뷰와 관련되어 있는 다른 뷰의 제약 조건들을 다시 설정하여 화면에 재배치하는 것입니다.func hideTag(_ hide: Bool) {         if hide {             self.labelTag1.isHidden = true             self.labelTag2.isHidden = true             self.constLabelTag1Top.constant = 0.0             self.constLabelTag1Height.constant = 0.0         } else {             self.labelTag1.isHidden = false             self.labelTag2.isHidden = false             self.constLabelTag1Top.constant = 15.0             self.constLabelTag1Trailing.constant = 5.0             self.constLabelTag1Height.constant = 20.0         }     } 위 소스에서 hide 값에 따라 레이블의 숨김을 설정하고 레이블의 제약 조건의 값을 재설정하는 메소드가 있습니다. 데이터가 있으면 숨김을 해제하고 제약 조건들의 값을 설정하지만, 데이터가 없으면 레이블을 숨기고 제약 조건들의 값을 0으로 설정합니다.스토리보드에서 연결한 제약 조건들을 가지고 설정할 수 있는데, 프로그램 상에서 직접 제약 조건들을 생성하여 사용할 수 있습니다. 아래의 예시는 뷰의 높이를 60으로 설정하는 코드입니다.NSLayoutConstraint(item: self.testView, attribute: .height, relatedBy: .equal, toItem: nil, attribute: .notAnAttribute, multiplier: 1.0, constant: 60) Conclusion애플에서는 개발자가 다양한 해상도에 대응할 수 있게 오토 레이아웃이라는 시스템을 개발했습니다. 스토리보드에서 쉽게 화면에 뷰를 배치할 수 있고, 별다른 기능을 추가하지 않아도 다양한 아이폰 크기에 맞춰서 대응해줍니다. 오토 레이아웃을 이용하여 멋지게 모든 아이폰과 아이패드에 대응하는 앱을 개발해보세요! 곧 산호세로 떠나 설레는 마음으로 글을 마치겠습니다. 감사합니다. :)글김주희 사원 | R&D 개발1팀kimjh3@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유

시작영화 ‘캡틴 아메리카: 시빌워’를 본 사람이라면 작은 ‘앤트맨’의 존재감이 누구보다 컸다고 말할 수 있습니다. 앤트맨은 가장 중요한 전투 신에서 자유자재로 신체 크기를 바꾸며 맹활약을 한 히어로인데요.안드로이드에도 이런 앤트맨처럼 크기를 자유자재로 바꾸되, 해상도를 그대로 보존하여 앱을 구현하는데 큰 도움을 주는 이미지 저장방식이 있습니다. 바로 나인패치입니다. 포스팅을 통해 나인패치를 이해해보고자 합니다.나인패치 이해하기#사이즈는 바뀌지만 내용은 그대로영화 속 앤트맨은 핌입자를 통해 분자보다 더 작은 양자 사이즈만큼 작아졌다가, 비행기보다 더 큰 사이즈로 변하는 히어로인데요. 핌 입자를 사용시 질량에는 변화가 없어 작아진 크기에서도 정상 어른의 펀치와 같은 위력을 줍니다.나인패치 역시 앤트맨과 같은 특징을 가지고 있는데요. 우리가 사용하고 있는 핸드폰의 해상도는 제각각 입니다. 하지만 이미지를 그 해상도에 전부 맞춰서 제작하기에는 무리가 있죠. 그렇기 때문에 디바이스에 표현되는 아이콘이나 버튼 등에 확대 되는 영역을 지정해줍니다. 그러면 큰 해상도에 이미지를 적용 하여도 픽셀이 깨지지 않고 확대된 이미지를 사용 할 수 있습니다.좀 더 정확하게 설명하자면, 이미지를 9분할 하여 확대되는 영역과 아닌 영역을 구분하여 저장하는 방식이며 이미지 확장자는. 9.png가 됩니다. 아래의 그림에서 살펴보면 빨간색 화살표 영역은 늘어나고 흰색 영역은 늘어나지 않게 됩니다.나인패치 이미지가 어떤 구조를 가지고 있는 어떻게 동작하는지에 대해 추가적으로 설명해보겠습니다.우선, 나인패치는Stretchable area와 Padding box 두가지의 영역으로 나뉩니다.Stretchable area는 늘어나는 영역은 이미지를 늘려주는 구간을 설정해주는 나인패치 영역입니다. 그래서 가로, 세로 어떤 크기로 늘어나도 형태가 깨져 보이지 않습니다.Padding box는 이미지 위에 어떠한 내용물을 어느 위치에 표시할지 정의 하는 영역입니다.버튼 크기가 변경되어도 정보 표시 영역을 나인패치로 잡아 좌우,상하 여백은 그대로 두고 이미지 확대/축소에 따른 텍스트가 정리되어 보여집니다.나인패치는 1px 검정색 선의 길이와 여백을 이용해서 늘려주고 싶은 이미지 영역과 표현하고 싶은 텍스트의 영역을 지정할 수 있는 것입니다.조금은 복잡해 보이지만, 나인패치로 지정하는 과정이 필요한 이유는 모바일은 한정된 용량을 가지고 있기 때문에 용량을 줄여서 하나의 이미지로 다양하게 사용할 수 있도록 하기 위해서 입니다.나인패치 만들어보기#만드는 방법나인패치를 만드는 방법에는 여러가지가 있습니다.   1. 포토샵으로 만들고, 확장자를 name.9.png으로 저장   2. 안드로이드 sdk 도구를 다운로드하여 만든다.       https://developer.android.com/studio/?hl=ko   3. Android Asset Studio 활용       http://romannurik.github.io/AndroidAssetStudio/nine-patches.html그중에서 툴 설치도 필요 없고 쉽게 만들 수 있는 3번의 방법을 활용하여 간략하게 나마 만들어보겠습니다.#우리는 그저 감사하게 사용할 뿐세상은 넓고 금손이 많은 것 같아요. 빠르게 만들수 있는 방법을 선택하겠습니다. 위 3번의 주소를 타고 사이트에 접속하면 아래와 같은 화면이 보여집니다.나인패치를 만들 수 있는 웹 툴인데, 저 사이트에는 나인패치 뿐만 아니라 안드로이드 디자인을 위한 다양한 툴을 제공하니 한번 참고해보시면 좋을 것 같습니다. 언제 이런걸 만들 생각을 하셨는지 한번 더 자괴감과 감사함을 느끼며 샘플 버튼 이미지를 불러옵니다.왼쪽 패널을 보면 이미지의 리소스 해상도를 지정하는 부분과 Drawable 이름을 편집할 수 있는 기능이 있습니다. 이름을 변경하게 되면 zip파일로 다운 받았을 때 변경된 이름으로 다운로드 됩니다.자 그럼 불러온 이미지가 가운데 화면에 보여집니다. Stretch Regions는 늘어나게 되는 부분을 설정하는 것입니다. 화면에 보이는 얇은 검은 선으로 Stretch Regions을 지정하면 됩니다.위와 같이 설정하게 되면 해상도에 따라 붉은색 부분이 늘어나게 됩니다.Contetns Padding은 안에 들어가는 텍스트가 들어가는 여백을 설정해줍니다.오른쪽 패널에서 Preview로 텍스트가 들어가는 것을 확인하면서 설정 할 수 있습니다.With content를 체크해주셔야 텍스트가 보여집니다.완성되면 Assets 탭에서 zip파일을 다운로드 받아주세요.다운로드가 완료되면 drawable name.9.zip으로 다운로드 되고 zip파일을 압축해제 하면 해상도 별로 나인패치 파일이 생성됩니다.부족하지만 나인패치에 대해 알아가는 시간이 되었기를 바라며, 이번 글은 여기서 마무리 하겠습니다.#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업

IT 서비스는 장애가 발생할 수 밖에 없습니다. 현대의 서비스는 지속적으로 커지고 복잡해지고 있습니다. 이를 해결하기 위한 MSA 구조는 장애의 규모를 줄여줄수 있지만 장애는 여전히 발생합니다. 그렇기 때문에 최근 애플리케이션 운영은 장애의 규모를 줄이고 장애를 빠르게 해결하는데 집중하고 있습니다.  그런데 이미 오래전부터 장애를 빠르게 해결하는 문화를 가진 지역이 있습니다. 바로 우리가 살고 있는 대한민국 서울입니다. 2000년에 엔터프라이즈의 IT 서비스가 태동될 때, 경험많은 해외 IT 기업들이 5년이 걸릴것이라 예상하는 ERP 시스템 통합을 한국의 기업들은 2년에서 3년만에 이뤄내는 기적(IT 지옥의 시작)을 이뤄냅니다. IT 기술이 전혀 없던 나라에서 빠르게 엔터프라이즈 IT 서비스들을 만들어 나가다보니 많은 문제들이 생겼습니다. IT 엔지니어의 혹사도 문제였지만 급하게 만들어진 IT 서비스들을 운영하는 것도 쉽지가 않았습니다. 2000년 중반의 어렵던 프로그래머의 삶을 대표하는 이미지이 때, 국내에 APM(Application Performance Mangement, 애플리케이션 성능 관리) 솔루션들이 혜성처럼 나옵니다. APM 솔루션을 통해 서비스 장애 원인을 알아낼 수 있었기 때문에 국내 엔터프라이즈 서비스를 운영하던 기업들에게 APM 솔루션은 단비와 같았습니다. 그리고 국내 APM 솔루션들은 해외 솔루션들과 비교되는 몇몇 특징을 가지고 있었는데, 그 중 하나가 실시간 어플리케이션 분석이였습니다. 그 중에서도 대표적인 실시간 분석 기능이 액티브 트랜잭션입니다. 액티브 트랜잭션애플리케이션 성능 분석 솔루션은 종료된 트랜잭션을 분석하는 기술입니다. 고객의 요청에서 응답까지의 과정을 트랜잭션이라고 합니다. 이렇게 완료된 고객의 요청을 하나 하나 분석하면 애플리케이션의 성능을 알아낼 수 있습니다. 그리고 액티브 트랜잭션은 종료되기 전의 트랜잭션을 분석하는 것입니다. 아직 완료되지 않은 트랜잭션을 분석하기 때문에 액티브 트랜잭션은 장애를 가장 빠르게 볼 수 있는 선행지표가 됩니다. 이해를 돕기 위해 아래에 벤더별 액티브 트랜잭션을 보여드립니다. 제니퍼소프트의 Active Service트랜잭션의 요청건수, 진행건수(Active Service), 완료건수가 상단에 나옵니다. 하단에는 다양한 방법으로 진행건수Active Service)를 보여주고 있습니다. 액셈의 Active Transaction트랜잭션의 요청건수, 대기건수(Active Service), 완료건수가 상단에 나옵니다. 하단에는 대기건수만(Active Transaction)를 보여주고 있습니다.와탭랩스의 Active Transaction트랜잭션의 진행건수를 원형으로 보여주고 있습니다. 와탭의 서비스는 대용량 분석을 위해 기존의 이퀄라이즈를 원형으로 보여주는 특징을 가지고 있습니다. 액티브 트랜잭션은 서비스를 오픈하는 과정에서 큰 효과를 보입니다. 아직 서비스가 완벽하지 않은 상태에서 부하 테스트를 하게 되면 서비스에 락이 걸리면서 트랜잭션이 연속으로 홀딩되면서 서비스 전체가 다운되기도 하는데, 이렇게 되면 종료된 트랜잭션으로는 분석이 불가능하기 때문입니다. 장애 상황에서의 액티브 트랜잭션장애 상황이 되면 일반적으로 액티브 트랜잭션의 양이 증가하게 됩니다. 아래는 와탭의 성능추이에서 볼수 있는 엑티브 트랜잭션의 건수를 표현하는 지표입니다. 평소 액티브 트랜잭션이 10건 이하였다면 아래와 같은 상황은 장애 상황일 확률이 높습니다. 마무리애플리케이션 성능을 분석하는 기준은 트랜잭션입니다. 데이터 분석 기준으로는 종료된 트랜잭션을 추적하는 것이 가장 중요합니다. 하지만 액티브 트랜잭션은 선행지표로서의 의미와 함께 종료된 트랜잭션으로 분석할 수 없는 상황을 알아낼 수 있는 중요한 지표이기도 합니다. 여러분이 사용하는 애플리케이션 성능 분석 도구가 있다면 액티브 트랜잭션 지표도 잘 활용하시기 바랍니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

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

유저 반응을 볼 때가 즐겁다는 프론트엔드 엔지니어 인턴 Mino조이에서 소프트웨어 엔지니어 인턴으로 살아간다는 것이 어떤지 궁금해 하시는 분들이 많아 4개월차 소프트웨어 엔지니어 인턴 미노(본명 천민호)를 Zoyiful Talk 첫 번째 주자로 모셨습니다.ZOYI: 미노 안녕하세요! 인턴으로 조인하신지 벌써 4개월이 지나셨다면서요. 우선 간단한 소개부터 해주세요. 회사에서 무슨 일을 하고 있나요?MINO: 안녕하세요, 채널(Channel)이라는 조이 신규 서비스를 개발하고 있는 엔지니어 미노입니다. 채널은 소비자와 커머스 기업을 연결해주는 소통 창구 같은 서비스인데요, 저는 그 중에 웹 프론트엔드를 개발하고 있습니다.ZOYI: 프론트엔드가 뭔가요? 좀 더 설명해 주세요.MINO: 프론트엔드는 흔히 ‘웹 개발자’라 하는데요, 웹이나 앱에서 서비스 이용자가 경험하는 부분을 개발합니다. 이용자에게 더 좋은 시각적 효과를 주고, 더 편리한 경험을 제공하기 위해 기술을 이용하죠. 이를 구현하기 위해 자바스크립트라는 언어를 사용하고, react.js를 프레임워크로 사용하고 있습니다.ZOYI: 원래부터 프론트 개발을 많이 하셨었나요?MINO: 프론트엔드는 HTML 작성할 수 있는 정도? 아니면 레일즈로 간단한 홈페이지 게시판 만드는 정도였어요. 자바스크립트는 조이에서 처음 배워봤고요.사실 개발 시작한 것 자체가 작년 9–10월이니 이제 반 년 좀 넘었네요. 코딩은 2년 전부터 시작했었는데 거의 알고리즘 공부가 위주였고 최근에야 제대로 개발을 한 것 같아요ZOYI: 조이에는 어떻게 조인하게 되신 거예요?MINO: 대학 개발 동아리 회장을 할 당시 대회 후원사가 필요해서 레드(CEO)한테 컨택한 적이 있거든요. 후원을 받고 나서 레드의 권유로 회사에 한 번 놀러왔는데, 사무실이 생각보다 좋더라고요. (웃음)스타트업 하면 좁은 공간에 다닥다닥 붙어있는 모습을 생각했었는데… 깔끔한 공간이 인상깊었어요.높은 천장과 통유리 채광을 자랑하는 조이 사무실에 반했다고 합니다.ZOYI: ㅎㅎㅎ 직접 일해보니 어때요? 실제로도 깨끗하던가요?MINO: 레드의 책상이 좀 더럽긴 하지만…은 농담이고요, 실제로 일해보니 더 좋은 것 같아요. 책상도 넓고… 제가 이렇게 하얀 느낌을 좋아하거든요.ZOYI: 조이에서의 4개월을 지내보니 어때요?MINO: 음… 4개월 지나고 나니, 이제야 내가 뭘 모르고 뭐가 부족한지를 알 수 있게 된 것 같아요. 잘한다고 말하긴 아직 부끄럽지만, 적어도 구글링으로 뭘 찾아야 할지는 알 수 있게 됐어요.ZOYI: 안해본 것들을 했잖아요, 주로 어떻게 습득을 했어요?MINO: 사람마다 좀 다를 수 있는데 저는 그냥 시간 날때마다 조이 오픈소스 프로젝트들을 하나하나 열어보면서 이게 어떻게 동작하나를 봤어요. 그래도 모르면 물어보면서 Follow up 받고… 동료들한테 부담없이 물어볼 수 있어서 좋았어요. 촉진제같은 역할을 해 준 것 같아요.한 번은, 전혀 새로운 분야이고 처음 접해보는 언어를 다루는 거라 익숙치 못해 하루종일 구글링을 한 적이 있어요. 그런데도 오늘 커밋 했냐, 뭐했냐 이런 얘기가 없고… 당신의 성장을 그냥 지켜보겠다는 태도인 거예요. 처음엔 익숙하지가 않았는데, 그런 분위기 덕분에 결과적으로 리서치를 잘 하고 일을 성공적으로 마무리 할 수 있었어요.ZOYI: 동료들과 교류가 많은 편인가요?저는 프론트엔드를 하다보니 주로 개발팀 멤버들과 많은 시간을 보내는데요, 업무 외적으로도 되게 재미있어서 친하게 지낼 수 도 있고 그래요. 꾸준히 소통하려 하는 게 느껴져요. 나를 막연히 6개월 후 나가는 인턴이 아니라, 함께 성장해 가는 동료로 생각하고 있구나. 하는 기분이 들죠.ZOYI: 푸스볼 중독이라는데?MINO: 푸스볼도 ZOYI에서 처음 배웠는데, 이건 정말, 최고의 레져인 것 같습니다 (목소리 톤 올라감). 가격 대비 효율이 최고예요. 하루 한 번 이상 꼭 하고 있습니다.10분만 해도 맥박이 빨라진다는 엄연한 스포츠, 푸스볼ZOYI: 본인의 푸스볼 랭킹은?MINO: 글쎄요, 디케이(하드웨어 디자이너)보단 잘하지 않을까요? ㅎㅎZOYI: 인턴 끝나면 생각나겠어요, 그러고 보니 인턴도 이제 두 달 남았네요. 돌아가면 하고싶은 일이 있나요?MINO: 아직 고민중이예요. 사실 조이 들어오기 전에는 프론트, 웹 개발자는 정말 안하겠다고 생각했었는데 지금은 이게 재미있다는 생각이 들어요.초반에 누가 “잘 하게 되면 점점 재미있어 질거다”라고 말해준 적이 있는데, 그 말이 공감이 돼요. 점점 배워가면서 지금은 어느정도 의도한 대로 구현이 되니까…이젠 재미있는 거예요. 새로운 분야를 알게 된 느낌? 그래서 앞으로 프론트엔드 개발자로 일해도 좋고, 뭐든 최대한 많은 경험을 하고 많은 지식을 습득해 보고 싶어요.ZOYI: 좋은 계기가 되었네요, 인턴 생활은 만족스러워요?MINO: 네, 생각하던 것 이상으로 좋았어요. 주도적으로 일을 해 나갈 수 있다는 점과, 하나하나 해 나갈 때마다 내가 성장하고 있는 느낌이 좋아요. 사실 처음 입사할 땐 단순히 반복작업만 할 줄 알았거든요. ZOYI엔 뭔가 ‘네 꿈을 펼쳐봐라~’하는 태도가 있는데, 저는 거기에 잘 맞았던 것 같아요.ZOYI: 그렇다면 향후 ZOYI 지원을 고민하시는 분께 어떤 조언 한마디 해주시겠어요?MINO: 주변에 많은 친구들이 ‘난 안될거야’라고 생각하고 지원조차 안하는 경우가 많은데, 저는 일단 지원해 보라고 말해주고 싶어요. 저도 지원할 당시 굉장히 걱정을 했었거든요. 나는 알고리즘 공부밖에 못해봤고, 서버도 용어 하나도 모르는데 내가 잘 할 수 있을까?하는 생각.막상 회사에 들어오고 난 지금은 생각이 많이 달라졌어요. 인턴에게 중요한 자질은 완벽함보다 가능성인 것 같아요. 그 가능성이란 게 대단한 스펙이 아니라, 기초를 탄탄히 가지고 있는 거예요. 그리고 나면 회사에 와서 충분히 성장할 수 있어요.그 좋은 사례가 션(CTO)인 것 같아요. 함께 일하면서 CTO가 되어가는 모습을 곁에서 보는 게 참 좋았어요. 내부에서 우리가 성장해 더 큰 역할을 맡을 수 있는 조직이란 게 참 좋아요.ZOYI: 조언 감사합니다. 남은 기간 ZOYI에서 기대하는 점이 있다면?MINO: 이번 주부터 시작될 개발팀 위클리 세션이 기대돼요. 각자가 알고 있는 기술을 다른 멤버들과 공유하는 시간인데요, 조이가 워낙 다양한 기술을 다루다 보니 제가 담당하지 않는 분야에 대해서는 잘 모르는 게 많거든요. 같이 일하는 사람들은 어떤 분야에 대해 일하고 있는지 기술적으로 알아보고 싶어요.ZOYI: 좋은 시도네요. 마지막으로 글 읽으시는 분들께 한마디 하시겠어요?MINO: ZOYI는 잘하는 사람들이 와서 더 잘하게 되는 곳이 아니라 가능성 있는 사람들이 와서 잘하게 되는 곳이라고 생각해요. 누구에게나 열려 있으니 편히 찾아와 주셨으면 좋겠어요 ^^#조이코퍼레이션 #개발팀 #개발자 #개발환경 #업무환경 #팀원인터뷰 #팀원소개 #팀원자랑

제니퍼는 기업 내부망에 설치되는 On-Premise 방식의 소프트웨어 제품이다. 12년 넘게 국내 점유율 1위를 지키고 있는 제품이다보니 그만큼 고객의 요구사항도 다양하다. 대부분의 솔루션 회사는 제품 개발 초기에 단일 소스코드를 유지하며 개발하는 것을 추구했을 것이다. 하지만 비즈니스를 하다보면 특정 고객을 위한 기능을 추가할 수 밖에 없는 상황이 오게 된다. 보통 이런 경우에는 숨겨진 기능으로 개발하거나 고객사 별로 소스코드를 다르게 가져가기도 한다.기존의 제니퍼를 사용하는 고객들은 애플리케이션 모니터링만이 아닌 브라우저나 스마트폰 같은 클라이언트 영역과 데이터베이스 관리 시스템까지 연계된 통합 모니터링을 하고자하는 요구사항을 오랫동안 요청했었다. 모니터링 제품 간의 연계를 생각하면 약간 생소하게 생각할 수 있는데, 특정 데이터를 수집하고, 이를 가공하여 사용자에게 보여주는 단순한 매커니즘의 하나라고 생각하면 이해가 쉬울 것 같다.즉, 다른 종류의 데이터를 하나의 화면에서 볼 수 있는 통합 환경을 제공해야 한다. 그래서 최근에는 오픈소스로 배포되고 있는 엘라스틱서치나 상용 제품인 스플렁크 같은 로그분석 솔루션이 주목받고 있다. 하지만 위와 같은 제품들을 사용하여 제니퍼 성능 데이터와 연계하여 통합 환경을 구축한다는 것은 말처럼 간단하지 않다. 제품을 구매하고 학습하는 비용이 생각보다 크고, 통합을 위한 별도의 시스템이 갖춰져야 한다는 것은 고객의 입장에서 큰 부담이 된다. 이러한 부담을 덜어주기 위해서 제니퍼는 실험실이라 불리우는 확장 기능을 제공한다. 실험실은 워드프레스의 플러그인과 비슷한 성격을 가지며 코드 레벨 영역에서 확장될 수 있다. 실험실은 처음부터 다른 모니터링 제품과의 연계를 위해 개발된 것은 아니었다. 기획 초기에는 방대한 제니퍼 데이터를 좀 더 다양한 형태의 화면으로 제공하기 위함이었는데, 아무래도 실험적인 요소가 강하다보니 기존의 대시보드나 분석 같은 범주로 들어가기에는 완성도 측면이나 제니퍼의 방향성에 영향을 미칠 수 있다는 판단에 별도의 범주로 만들게 되었다.  실험실이란 이름은 구글 메일의 실험실에서 따온 것인데, 아직 개발 중인 실험적 기능을 위한 테스트 공간이고, 언제든지 변경 또는 중단되거나 사라질 수 있다. 그리고 모든 실험실 소스코드는 깃허브를 통해 공개하는 것이 기본 정책이다. 제니퍼소프트 깃허브에 가보면 실제로 다수의 실험실 프로젝트가 존재한다는 것을 알 수 있다. 그 중 한가지만 간략하게 소개하자면 사용자 관점의 웹 서비스 모니터링 제품인 아르고스와 연계하여 브라우저나 스마트폰 같은 사용자 관점의 성능 데이터를 제니퍼 트랜잭션 데이터와 연계하여 분석할 수 있는 기능을 제공한다. 실은 그동안 고객들에게 사용자 관점의 성능 모니터링에 대한 요구사항이 많았지만 제니퍼 본연의 영역과 확연하게 다른 측면이 있어서 요구사항을 수용하는데 많은 고민이 필요했다. 그래서 우리는 관련된 솔루션 업체를 찾았고, 상호 간의 비즈니스 협력을 통해 서로의 부족한 부분을 보완하기로 결정했다. 실험실은 제니퍼가 시도하고 있는 새로운 기능을 미리 체험해 볼 수 있을 뿐만이 아니라 오픈소스나 관련된 솔루션과의 연계를 하기 위한 화면을 제공할 수 있다. 뿐만 아니라 코드 레벨 영역에서 확장을 하는 것이다보니 제품의 커스터마이징 범위가 넓어진다. 즉, 화면에 대한 고객의 요구사항이 제니퍼의 방향성과 크게 다르더라도 많은 고민을 하지 않고 충분히 원하는 것을 구현해줄 수 있다. 과거와 달리 동일한 데이터라도 좀 더 시각적인 화면을 요구하는 요즘같은 시기에 실험실은 이러한 시도를 하기에 좋은 방법이 된다.제니퍼는 화면 단위의 확장 기능인 실험실 뿐만이 아니라 트랜잭션 데이터가 수집되는 시점이나 특정 이슈가 발생할 때, 생성되는 이벤트 데이터를 어댑터를 통해 전달받을 수 있다. 어댑터도 실험실과 마찬가지로 코드 레벨 영역에서 확장할 수 있다. 실시간으로 전달받은 트랜잭션 데이터는 별도의 스토리지에 저장하여 목적에 맞게 조회해서 사용할 수 있다. 특히 이벤트 관련 어댑터는 가장 많이 사용되는 제니퍼 확장 기능이며, 고객사의 관제시스템 연동에 주로 사용된다.  실험실은 어댑터와 달리 제니퍼 서버에서 전달받은 데이터를 처리만 하는 단순한 구조가 아니었다. 제니퍼와 독립적인 화면 구성에 필요한 모든 요소들을 갖춰야했기 때문에 고려해야할 것들이 너무 많았다.  그럼에도 불구하고 만들게 된 이유는 단순히 필자의 편리함을 위해서였다. 평소에 데이터 시각화에 관심이 많았기 때문에 이미 존재하는 방대한 제니퍼 데이터를 다양한 방식으로 표현하기 위한 시도를 했었다.하지만 상용 솔루션인 제니퍼에 테스트 코드를 필자 임의로 추가해서 배포하거나 숨긴 기능으로 만들기에는 꽤 부담스러운 일이었다. 그렇다고 별도의 소스코드로 다르게 가지고 가기에는 관리 측면에서 어려움이 있다. 그렇기 때문에 기존의 제니퍼 소스코드를 참조만 하되 서로 독립적으로 개발하는 형태를 생각하게 되었다. 이렇게 필자의 편리함을 위해 시작한 실험실이지만 오픈소스나 다른 솔루션과의 연동을 위한 화면을 제공하고, 새로운 제니퍼 기능에 대한 비전을 시사하거나 고객의 피드백을 수용하는 용도로 확장되었다.소프트웨어 개발을 하다보면 제품이 추구하는 방향과 달라서, 또는 구현은 가능하지만 소모되는 리소스 비용이 부담이 될 경우, 그리고 특정 사용자를 위한 특화된 기능을 구현할 때, 모두가 만족할만한 기능이라는 확신이 없다면 제대로 진행하기가 어려운게 현실이다. 사실 새로 시도하는 기능은 시기와 때에 따라 앞에서 고려했던 것들과 다르게 평가되는 경우도 있다.그래서 아무리 작은 아이디어라도 시도를 해보는 것 자체만으로도 큰 의미가 있으며, 새로운 가능성을 발견하는 계기가 될 수 있다. 다만 현재는 제니퍼 기능 확장에 대한 기반 정도만 갖춰진 시작 단계라서 관련된 API 문서나 개발 도구에 대한 지원이 미흡한 것이 아쉬움으로 남는다. 다음 편에서는 자바 개발자 대상으로 실험실을 직접 구현하는 방법에 대해 알아볼 것이다.

* 이 글은 MobX의 MobX and React 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!개요MobX은 간단하고 확장 가능하며 테스트를 거친 상태 관리 솔루션입니다. 이 튜토리얼은 10분 안에 MobX의 중요한 컨셉들을 모두 소개합니다. MobX는 독립적인 라이브러리지만 대부분의 사람들은 React와 함께 사용합니다. 그래서 이 튜토리얼은 MobX와 React의 조합에 중점을 두고 설명합니다.The core idea상태는 각 애플리케이션의 핵심입니다. 버그를 만드는 관리가 되지 않는 애플리케이션을 만드는 가장 빠른 방법은 주변의 로컬 변수들과 동기화 되지 않는 상태나 일관성 없는 상태를 만드는 것입니다. 그래서 많은 상태 관리 솔루션들이 상태를 변할 수 없게 만드는 식으로 상태를 수정할 수 있는 방법들을 제한하려고 합니다. 하지만 이 방법은 새로운 문제들을 생성합니다. 데이터를 표준화 해야 하고 참조 무결성이 보장되지 않으며 프로토타입과 같은 유용한 컨셉들을 활용하지 못하게 됩니다.MobX는 일관성 없는 상태를 만들 수 없도록 주요 문제를 해결하여 상태 관리를 간단하게 만들었습니다. 이를 위한 전략은 간단합니다. 애플리케이션 상태로부터 파생될 수 있는 모든 것들을 자동으로 파생되도록 하는 것입니다.개념적으로 MobX는 애플리케이션을 스프레드시트로 간주합니다.1. 가장 먼저 애플리케이션 상태가 있습니다. 애플리케이션의 모델을 채우는 객체, 배열, 원시, 참조의 그래프입니다. 이 값들은 애플리케이션의 "데이터 셀"입니다.2. 둘째로 파생 값이 있습니다. 기본적으로 애플리케이션으로부터 자동으로 계산될 수 있는 모든 값들입니다. 이 파생 값이나 계산된 값들은 완료되지 않은 todo들의 수와 같이 간단한 값부터 todo의 시각적 HTML 표현과 같은 복잡한 내용까지 다양합니다. 스프레드시트 용어로는 애플리케이션의 공식이나 차트가 있습니다.3. 리액션은 파생 값과 매우 비슷합니다. 주된 차이점은 값을 생성하지 않는 함수라는 점입니다. 대신 자동으로 특정 작업들을 수행시킵니다. 대체로 I/O와 관련된 작업입니다. 리액션은 적당할 때에 자동으로 DOM이 업데이트되거나 네트워크 요청을 하도록 만듭니다.4. 마지막으로 액션이 있습니다. 액션은 상태를 변경하는 모든 것들을 말합니다. MobX는 모든 사용자의 액션으로 발생하는 상태 변화들이 전부 자동으로 파생 값과 리액션으로 처리되도록 합니다. 동기화되고 결함이 없습니다.간단한 todo store이론은 충분합니다. 위의 내용을 유심히 읽는 것보다 실제 예시를 보는 것이이해하기 아마도 더 쉽습니다. 아주 간단한 ToDo store을 가지고 시작해봅시다. 아래의 모든 코드 블록들은 수정이 가능하므로 run code  버튼을 클릭하여 실행시킬 수 있습니다. 아래의 코드는  todo 목록이 포함된 매우 직관적인 TodoStore입니다. MobX는 아직 포함되지 않았습니다.우리는 todos 목록이 있는 todoStore 인스턴스를 이제 막 만들었습니다. 어떤 객체들로 todoStore을 채울 시간입니다. 변경 사항들을 보기 위해 각 변화 이후에 todoStore.report를 호출하고 로그를 남깁니다. 레포트는 의도적으로 항상 첫 번째 할 일만 출력합니다. 이 때문에 예시가 좀 인위적이지만 아래에서 볼 수 있듯이 MobX의 의존성 추적이 동적임을 잘 보여줍니다.결과:반응형으로 만들기지금까지 이 코드에서 특별한 것은 아무것도 없었습니다. 그러나 report를 명시적으로 호출할 필요가 없다면 어떨까요? 각 상태가 변할 때마다 report가 호출되길 원한다고 선언할 수 있습니까? 그러면 report에 영향을 줄 수도 있는 모든 코드에서 report를 호출해야 합니다. 최신의 report가 출력되기를 원하지만 그것을 모두 작성하고 싶지는 않습니다.운이 좋게도 이것은 MobX가 여러분을 위해 동작하는 것입니다. 자동으로 상태에 연관되어 있는 코드를 실행합니다. 그래서 report 함수는 스프레드시트의 차트와 같이 자동으로 업데이트 됩니다. 이를 위해 TodoStore를 관찰할 수 있어야 MobX가 모든 변경 사항들을 추적할 수 있습니다. 이를 수행하도록 클래스를 변경해봅시다.또한 completedTodosCount 속성은 자동으로 todo 목록에서 파생될 수 있습니다. @observable과 @computed 데코레이터를 사용하여 객체에서 관찰할 수 있는 속성들을 생성할 수 있습니다.이게 끝입니다! 시간에 따라 변할 수 있는 값들을 MobX에게 알려주기 위해 @observable를 표시했습니다. 계산은 상태로부터 파생될 수 있는 것들을 확인하기 위해 @computed를 사용하여 표시됩니다.pendingRequrests와 assignee 속성들은 지금까지 사용되지 않았지만 앞으로 이 튜토리얼에서 사용됩니다. 이 페이지의 모든 예시들을 짧게 만들기 위해 ES6와 JSX 그리고 데코레이터를 사용합니다. MobX의 모든 데코레이터들은 ES5 부분들을 가지고 있으니 걱정하지 마세요.생성자에 report를 출력하는 작은 함수를 만들고 autorun으로 감쌌습니다. Autorun은 한 번 동작되는 리액션을 만들고 함수 안에서 사용되는 관찰 가능한 모든 데이터들이 변경될 때마다 자동으로 다시 실행합니다. report는 관찰 가능한 todos 속성을 사용하기 때문에 적절할 때 레포트를 출력합니다. 이것은 다음 리스트에서 설명됩니다. 실행 버튼을 눌러보세요:report은 자동으로 동시에 중간 값을 빼먹지 않고 출력하였습니다. 유심히 로그를 보면 새로운 로그에서는 4번째 줄이 없는 것을 발견할 수 있습니다. 뒤의 데이터가 변경되는 것으로 report가 실제로 변경되지 않기 때문입니다. 반면에 첫 번째 할일의 이름이 바뀐 것은 report에서 실제로 사용되는 이름이기 때문에 report를 업데이트 하였습니다. 이것은 todos 배열이 autorun에 의해 관찰되는 것이 아니라 todo 아이템들 안에 있는 개별적인 속성을 관찰하고 있다는 것을 잘 설명해줍니다.반응형 React 만들기지금까지 바보 같은 report를 반응형으로 만들었습니다. 이제 이 store에서 반응형 유저 인터페이스를 만들 시간입니다. React 컴포넌트들은 이름값을 못하고 반응형이 아닙니다. mobx-react 패키지의 @observer 데코레이터는 React 컴포넌트 render 함수를 autorun으로 감싸 자동으로 상태에 따라 컴포넌트가 동기되도록 만듭니다. 개념적으로 이전에 report를 가지고 했던 것과 다르지 않습니다.다음 코드는 몇 개의 React 컴포넌트를 정의합니다. 이 안의 MobX는 @observer 데코레이터 뿐입니다. 이것으로 충분히 데이터가 변경될 때 각 컴포넌트가 개별적으로 다시 렌더링하도록 만들 수 있습니다. 더이상 setState를 호출할 필요가 없으며 설정이 필요한 셀렉터나 상위 컴포넌트를 사용하는 상태의 적절한 부분을 찾을 필요도 없습니다. 기본적으로 모든 컴포넌트들은 더 똑똑해졌지만 아직 부족합니다.아래의 코드를 보기 위해 run code 버튼을 클릭하세요. 코드는 수정이 가능하므로 자유롭게 동작시킬 수 있습니다. 예를 들어 @observer 호출을 모두 지우거나 TodoView의 데코레이터만 지워보세요. 오른쪽의 미리보기에서 숫자들은 컴포넌트가 렌더링될 때마다 표시합니다. 다음 코드는 다른 작업을 수행하지 않고 데이터를 변경해야 한다는 것을 잘 보여줍니다. MobX는 자동으로 store의 상태에 따라 유저 인터페이스의 적절한 부분들을 다시 파생하고 업데이트합니다.참조 사용하기 지금까지 관찰가능한 객체(프로토타입과 일반 객체 둘 다)와 배열, 원시를 만들었습니다. MobX에서 참고를 다루는 방법에 대해 궁금하지 않나요? 상태가 그래프를 형성할 수 있나요? 이전 코드에서는 todos의 assignee 속성이 있는 것을 알았을 것입니다. 또 다른 "store"을 생성하여 assignee에 포함되는 사람들의 값을 전달하고 그들에게 할일이 할당해줍시다.두 개의 독립적인 store이 있습니다. 하나는 사람들이 있고 하나는 할 일들이 있습니다. 사람 store의 사람을 assignee에 할당하기 위해 참조를 할당했습니다. 변경사항들은 TodoView에 의해 자동으로 선택됩니다. MobX를 사용하면 데이터를 표준화할 필요가 없고 업데이트될 컴포넌트들을 지정하기 위해 셀렉터를 작성할 필요가 없습니다. 실제로 데이터가 어디에 저장되는지는 중요하지 않습니다. 오랫동안 객체들은 관찰가능하게 만들어졌고 MobX는 그것들을 추적할 수 있습니다. 실제 JavaScript 참조가 동작합니다. MobX는 파생과 관련이 있으면 자동으로 그것들을 추적합니다. 테스트 해보기위해 다음의 인풋 박스에 이름을 변경해보세요. (먼저 위의 Run code 버튼을 클릭했는지 확인해보세요)위의 인풋 박스의 HTML은 간단합니다:비동기 액션작은 Todo 애플리케이션에 있는 모든 것들은 상태로부터 파생되기 때문에 언제 상태가 변화하는지는 중요하지 않습니다. 비동기 액션을 만드는 것은 매우 수월합니다. 새로운 할일 아이템을 비동기적으로 로드하려면 아래의 버튼을 여러번 클릭하세요.코드는 매우 직관적입니다. UI가 현재 로딩되는 상태를 반영하도록 store의 pendingRequests 속성을 업데이트하는 것으로 시작합니다. 로딩이 끝날 때 store의 todos를 업데이트하고 pendingReqeust 카운터를 증가시킵니다. 이 스니펫을 이전 TodoList 정의와 비교하여 pendingRequests 속성이 어떻게 사용되는지 확인하세요.개발자 도구mobx-react-devtools 패키지는 화면의 오른쪽 최상단에서 찾을 수 있고 모든 Mobx+ReactJS 애플리케이션 내에서 사용할 수 있는 개발자 도구를 제공합니다. 첫 번째 버튼을 클릭하면 각 다시 렌더링되는 @observer 컴포넌트가 표시됩니다. 두 번째 버튼을 클릭하고 미리보기에서 해당 컴포넌트 중 하나를 클릭하면 해당 컴포넌트의 종속성 트리가 표시되므로 주어진 순간에 관찰중인 데이터 조각을 정확하게 검사할 수 있습니다.결론끝났습니다! 관용구는 없습니다. 완전한 UI를 형성하는 간단하고 선언적인 컴포넌트들입니다. 그리고 상태로부터 완전하고 반응형으로 파생됩니다. 여러분의 애플리케이션에서 mobx와 mobx-react를 사용하기 시작할 준비가 되었습니다. 지금까지 배운 것들을 짧게 요약하였습니다:1. MobX가 객체들을 관찰할 수 있도록 @observable 데코레이터 또는 observable(객체 혹은 배열)을 사용하세요.2. @computed 데코레이터는 상태로부터 자동으로 파생되는 함수를 만들기 위해 사용될 수 있습니다.3. 관찰 가능한 상태에 의존하는 함수들을 자동으로 실행하기 위해 autorun을 사용하세요. 로깅하거나 네트워크 요청하기에 유용합니다.4. React 컴포넌트를 진짜 반응형으로 만들기 위해 mobx-react 패키지의 @observer 데코레이터를 사용하세요. 자동으로 효율적으로 업데이트합니다. 심지어 많은 양의 데이터가 있는 아주 복잡한 애플리케이션에서도 사용됩니다.위의 수정 가능한 코드 블록을 사용하여 조금만 더 만져보면 MobX가 모든 변경 사항에 어떻게 반응하는지 기본적인 느낌을 얻을 수 있습니다. 예를 들어 언제 호출되는지 보기 위해 report 함수에 로그를 추가하거나 report를 출력하지 않고 이것이 TodoList 렌더링에 어떤 영향을 주는지 확인하세요. 아니면 특정 상황에서만 출력하세요...MobX는 상태 컨테이너가 아닙니다사람들은 종종 MobX를 Redux의 대안으로 사용합니다. MobX는 기술적인 문제를 해결하는 라이브러리일 뿐이며 아키텍처나 상태 컨테이너가 아닙니다. 그러한 의미에서 위의 예시들이 고안된 것으로 메서드에서 로직을 캡슐화하거나 store나 컨트롤러에서 구성하는 것과 같은 적절한 엔지니어링 기법을 사용하는 것이 좋습니다. 또는 HackerNesw의 누군가는 이렇게 말했습니다:"MobX는 많은 곳에서 언급되었지만 나는 마냥 좋다고 말할 수 없습니다. MobX로 작성하는 것은 컨트롤러/디스패처/액션/슈퍼바이저 또는 다른 형태의 데이터 흐름을 관리하여 애플리케이션의 요구 사항을 패턴화할 수 있습니다."#트레바리 #개발자 #안드로이드 #앱개발 #MobX #React #백엔드 #인사이트 #경험공유

지난 토요일 매우 더웠던 어느 여름밤, 관심일정 구독 서비스: 린더가 앱스토어 라이프스타일 16위에 올랐다.물론 출시에 맞추어 마케팅을 진행하다 보면 초기에 순위 상승 효과가 다소 있기 마련이고, 요즘 같은 시대에 앱스토어 순위 좀 올랐다고 그게 그리 큰 대수냐랴고 말하는 사람도 있겠지만서도, 이 앱을 스토어에 올리기까지의 험난했던 과정을 누구보다도 잘 아는 사람으로서 비록 잠깐이지만 한여름밤의 꿈 같았던 이 과정과 결과를 글로 간직하고 싶었다.모든 스타트업, 아니 작은 중소기업이 그렇겠지만 우리는 매우 소수의 인력으로 구성되어있고, 그 소수의 인원 하나하나가 정말 많은 일을 담당하고 있다. 관심일정 구독 서비스: 린더는 다소 독특한 서비스 구조 특성상 사업 초기부터 B2B, B2C 모두를 대상으로 운영이 되고 있으며, 하루하루 예상치 못한 새로운 일들의 연속이 이어진다. 혹자는 이를 도전적이고 진취적인 경험이라 포장할 수도 있겠지만, 당장 어제는 한 번도 해본 적 없는 B2B SEO 작업을 하다가 오늘은 또 ASO 전문가가 되어야 하는 우리 당사자들 입장에서는 이러한 일련의 과정이 매우 가혹할 수밖에 없다.린더를 만들어 가는 과정에서 정말 많이 다퉜다(물론 앞으로도 많이 다투겠지만). 앞서 말한 가혹한 과정 속에서 여유를 가지고 서로가 서로를 대하기는 쉽지 않았기에, 당장 회사가, 서비스가 몇 달 후에도 계속 존재할지 아무도 모르는 상황에서 희망을 품고 모두가 함께 서비스의 미래를 바라보기는 정말 쉽지 않았다. 하지만 그 다툼의 근간에는 제품에 대한 기대와 열망이 있었다는 것을 모두가 알고 있었고, 기능 하나하나 쉽게 양보하지 않았지만 결국 하나의 공통된 목표 하에 조금씩 타협해나갈 수 있었다. 그렇게 우리는 현재 '린더'라는 이름을 달고 세상에 태어난 총 5개의 서비스를 운영하고 있다.'린더웹'으로 불리우는 기본 캘린더 연동 서비스는 작년 6월에 출시되어 현재까지 약 20만 명의 사용자를 확보하였고, 올해 4월, 7월에 각각 출시된 '린더안드로이드앱'과 '린더iOS앱'은 현재까지 총 2만여 다운로드와 1만 MAU를 확보하였다. 이 과정에서 우리와 협업을 희망하는 기업들을 위해 별도의 관리툴을 솔루션 형태로 제작, '린더 파트너스'라는 기업용 일정 마케팅 솔루션을 바탕으로 롯데자이언츠, 두산베어스, 아디다스 코리아 등 20여 개의 기업과 함께 협업하고 있으며, 빠르고 정확한 일정 데이터 생산을 위해 일정 데이터 형태에 최적화된 데이터 관리툴 '린더 CMS'를 개발하여 최소한의 인력과 비용으로 일정 데이터 생산이 가능케 했다.일정 구독 플랫폼: 린더지난 1년간 우리 팀은 사용자들의 구독 니즈를 충족시키기 위해 밤낮으로 다양한 일정들을 찾아 헤맸고, 어느덧 300여 개가 넘는 여러 캘린더를 운영하게 되었다. 그리고 지속적으로 높은 일정 데이터 생산 비용을 감당해야 했었던 이전에 비해 이제는 20만 명이 넘는 사용자들의 빗발치는 일정 제보와 20여 개가 넘는 파트너들의 일정 공급을 바탕으로 보다 효율적인 운영이 가능해졌다. 밤낮으로 일정을 찾아 헤매던 기존의 과정은 체계화된 시스템 덕분에 상당 부문 개선되어 변동성 높은 일정 데이터의 정확도를 지속적으로 향상 시켜나가고 있다.일정 제보 화면이제 우리는 감히 린더를 단순 구독 '서비스'를 넘어 국내 유일의 일정 구독 '플랫폼'이라고 부를 수 있는 자신감이 생겼다. 사용자들은 하루에도 몇 번씩 새로운 일정을 제보하는 동시에 구독을 희망하는 새로운 캘린더를 요청하고, 마찬가지로 '입점'을 희망하는 기업의 니즈 또한 지속적으로 증가하여 지난주에만 스포츠, 학교, 공연 3개의 각기 다른 분야에서 '일정 구독 제공'에 대한 문의가 들어왔다. 이들은 '일정'이라는 공통된 포맷 하에 각자 자신들의 일정을 팬, 학생, 또는 고객들에게 제공하기를 희망하였다.린더와 VUX(음성 기반 사용자 경험)   최근 AI 스피커 시장이 확장됨에 따라 각 회사들은 VUX기반 컨텐츠 확보에 열을 올리고 있다. 카카오가 NUGU를 운영하는 경쟁사 SKT에 멜론뮤직의 음악 컨텐츠를 공급하지 않을 것은 불 보듯 뻔한 사실이고, 결국 SKT는 자체 음악 서비스인 '뮤직메이트'를 새로이 시작했다. 역으로 네이버에게 배달의민족과의 협력 기회를 뺏긴 카카오는 '주문하기' 기능을 확대하여 자체 배달 서비스를 시작했다. '음악 컨텐츠'가 되었건, '배달 컨텐츠'가 되었건, 날씨 알려주는 것 외에 딱히 할 줄 아는 게 없는 현시대의 인공지능들에게 린더의 일정 컨텐츠는 높은 활용 가치가 있을 수 있다.단순히 내 캘린더와 연동되어 내가 어제 입력했던 일정들을 읊어주는 것이 아니라, 내가 좋아할 만한, 필요로 할만한 일정들을 미리 찾아서 알려줄 수 있다면 정말 멋지지 않을까. 캘린더에 표시도 안 한 2학기 수강신청을 10분 전에 내게 먼저 알려줄 수 있는 앱이 있다면, 아침에 일어나자마자 고대하던 신상 구두가 출시되었음을 알려주는 스피커가 있다면 분명 그 사용자 경험은 어디에서도 쉽게 경험할 수 없는 수준일 것이다.린더의 타이밍 타이밍은 중요하다. 비트, 풀러스 등 높은 제품 퀄리티 및 운영 능력에도 불구하고 시대가 받아들일 준비가 되지 않은 서비스들의 말로를 먼발치에서 지켜보았다. 약 1년 전 내부적으로 우리의 타이밍에 대해 논의를 진행했던 적이 있었고, 당시 우리가 내린 결론은 린더의 타이밍이 결코 늦으면 늦었지 빠르지는 않았다는 것이었다. 이미 사람들은 일정을 받아보는 경험을 받아들일 준비가 되어있으며, 1년 간 린더를 통해 일정을 받아보는 경험을 누리고 있는 20만의 사용자가 이를 방증한다.우리가 생각한 그 '타이밍'이 틀리지 않았다면, 꼭 '린더'라는 이름이 아니더라도 '일정을 받아보는 경험'을 만들어가는 것은 반드시 누군가가 성공해야만 하는 일이다. 지도로 길을 찾으며 불편함을 느끼지 못했던 세상에 누군가가 네비게이션을 선사한것처럼, '일정을 받아보는 경험'은 근 미래에 없어서는 안 될 선물이 될 것이다.    일정 구독 플랫폼은 분명 많은 이들의 삶에 변화를 줄 수 있다. 작게 보면 좋아하는 공연의 티켓팅을 놓쳐 매번 공연에 참여하지 못할뻔한 어느 팬의 하루를 행복하게 바꾸어 놓을 수 있고, 크게 보면 복수전공 신청 기간을 깜빡하고 놓쳐 복수 전공을 하지 못할뻔한 어느 대학생의 삶을 송두리째 바꾸어 놓을 수 있다.이 일은 반드시 누군가가 해내야만 한다. 그냥 있어 보이고 싶어서, 스타트업다워 보이고 싶어서 내뱉는 말이 아니라, 진심으로, 사력을 다해 누군가는 반드시 이 일정 구독 플랫폼을 만들어 내야만 한다. '일정을 받아보는 경험'이 일상화 되었을때 비로소 우리의 삶은 조금 더 질적으로 풍요로워질 수 있다.린더가 앱스토어 10위권에 오른 이번 사건이 완전히 새로운 형태의 일정 구독 플랫폼의 시작을 알리는 출발선이 되었으면 한다. 다시 또 높은 순위권으로 올라오기 위해서는 아마 한동안 많은 노력들이 필요로 될 것으로 예상되기에, 우리는 앞으로도 화장품 세일, 아이돌 스케줄, 대학교 학사일정, 스포츠 경기, 마트 휴무일, 공연, 전시 등을 넘어 사람들이 필요로 하는 새로운 일정 컨텐츠를 찾아 헤맬것이다.세상 사람 모두가 일정을 받아보는 날이 오기를 꿈꾸며, 와, 근데 이번 여름밤은 정말 더워도 너무 덥다.#히든트랙 #챗봇 #기술기업 #개발자 #개발팀 #인사이트 #경험공유

와탭랩스는 IT 서비스를 운영하는 개발팀과 운영팀에 도움이 되는 솔루션과 서비스를 만드는 스타트업입니다. IT 서비스를 잘 운영하게 위해서는 Infrastructure의 전반적인 상황을 항시 체크할 수 있어야 하는데요. 이런 기능을 하는 대표적인 화면이 대시보드 입니다. 최근 와탭랩스는 Infrastructure 모니터링 서비스에 대시보드를 넣는 작업을 진행하고 있는데요. 와탭랩스는 대시보드를 통해 Infrastructure를 운영하는 개발팀과 운영팀에 어떻게 도움을 줄 수 있도록 할 것인지 소개하겠습니다. 1. IT 서비스 운영에 사용된 인프라 자산 현황을 알아보자지금 회사에서 사용하는 서버의 대수를 알고 계신가요? 현재 동작하는 서버는 몇대인지 혹시 죽어있는 서버가 있는지 등에 대한 정보는 운영팀에서 항상 체크하는 정보입니다. 하지만 개발팀에서는 잘 모르는 정보이기도 하죠. 이런 기본적인 정보가 대시보드에 나온다면 평소 서비스를 운영하는 감을 잡는데 도움이 됩니다. 이런 정보들은 간략한 수치로도 표현할 수 있는데요. 우리는 아래와 같은 데이터를 수집할 수 있습니다. 서버 기본 정보 (inactive servers / all servers)우리가 사용하는 총 서버의 수자와 비활성화된 서버의 숫자는 우리가 항상 알고 있어야 하는 정보입니다.운영체계별 서버 정보 (Linux / Windows / Unix)운영체계를 섞어 사용하는 경우에는 운영체계에 따라프로젝트가 나눠지기도 합니다. 그렇기 때문에 운영체계별로 서버의 총량과 비활성화된 서버 정보를 알면 도움이 됩니다. 프로세스 수프로젝트의 프로세스 수는 일정한 경우가 많습니다. 전체 프로세스의 숫자가 변경된다면 서비스의 운영 상황에 대해 의문을 가져야 합니다. 이벤트 개수24시간동안 발생한 전체 이벤트의 개수와 아직 해결하지 못한 이벤트의 개수를 보여줍니다. 하루동안 얼마나 많은 이벤트가 발생하는지 그리고 아직 해결하지 못한 이벤트가 있는지 알수 있습니다. 디스크 사용량/전체 용량디스크 사용량은 일반적으로 큰 변화를 가지지 않습니다. 디스크 사용량이 평소와 다르다면 서비스의 장애가 발생했거나 발생할 가능성이 높습니다. 메모리 사용량 / 전체 용량메모리 사용량은 일반적으로 큰 변화를 가지지 않습니다. 메모리 사용량이 평소와 다르다면 서비스의 장애가 발생했거나 발생할 가능성이 높습니다. 수치 데이터의 예 2. 서비스를 구성하는 인프라의 CPU 흐름 전체를 알아보자 CPU 사용량은 변화량이 많은 지표입니다. 변화량을 비교하는 챠트로는 라인 차트가 가장 많이 쓰이지만 라인 차트는 개수가 많아지면 전체 상황이 보이지 않는 문제점을 가지고 있습니다. 또한 실시간으로 추가되거나 삭제되는 인프라가 생기는 클라우드 인프라 상황에서 라인챠트는 표현의 한계를 가지고 있기도 합니다. 이런 문제를 해결하기 위한 방법으로 아래와 같은 온도 차트를 사용할 수 있습니다. 온도 차트는 단위 영역에 밀도에 따라 색상으로 깊이를 표현하는 방식입니다. 최근 많은 양의 데이터를 표현하는 방식으로 많이 사용되고 있습니다. 온도 차트의 예3. 경고가 발생했는지 또는 해결 되었는지 알고 싶다.  CPU 사용량이 설정치 이상으로 높아지거나 디스크 사용량이 높아지거나 프로세스가 사라지는 등 다양한 상황에 대한 이벤트가 발생할 수 있습니다 이런 상황을 쉽게 확인할 수 있다면 서비스 운영 상황에 도움이 됩니다. 이벤트 관리의 예이런 스토리를 기반으로 와탭랩스에서 대시보드를 기획하고 있습니다. 개발자와 디자이너가 함께 토론하고 논의하면서 화면과 스토리를 더 다듬게 되면 첫번째 화면이 나올 예정입니다. 아래는 기획과정에서 나온 화면 리소스 입니다. 아직 기획 단계이기는 하나 첫번째 대시보드가 완성되면 이 페이지가 메인으로 올라갈 예정입니다. 대시보드는 데이타의 종류와 위치등을 수정할 수 있으면 좋지만 우선은 고정형으로 개발하여 제공할 예정입니다. 이번 대시보드는 서비스 첫번째 의미가 강한 메인 화면의 성격에 더 초점을 맞추고 있습니다. 아직 몇몇 논의되는 사항이 많은 화면이지만 빠르게 개발하여 가능한 이른 시일에 소개드리도록 하겠습니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

블록체인에서 PoW는 Proof of Work, 즉 작업증명을 말합니다. 블록체인의 암호화된 작업에 대해 참여자가 암호를 풀면, 보상을 제공받는 것이죠.오늘은 코인원의 PoW에 대해서 이야기 해보려고 합니다. '코인원 PoW'의 PoW는 블록체인을 기반으로 금융을 혁신하는 기업답게 블록체인 용어에서 차용했어요. :-)  코인원 크루들이 스스로와 동료들의 회고를 진행하고 피드백을 주고 받는 과정을 통해, 업무 개선과 성과에 대한 보상을 제공받도록 만들어진 일종의 성과관리 시스템이죠. 코인원 피플팀은 코인원 PoW 과정을 다음과 같이 설명하고 있습니다.크루들이 자신들의 업무 성과에 대해 투명하게 풀어놓는 회고를 우선적으로 진행해요. 그 후 함께 업무를 진행한 페어 그룹(pair group)끼리 서로 잘된 업무와 지원이 필요한 부분에 대해 대화를 진행하며, 이를 통해 개선점과 방법을 찾아 업무에 적용합니다.코인원 PoW의 특별한 점은, 대부분의 과정이 정성적으로 진행된다는 것에 있습니다. 물론 숫자로 보이는 결과도 중요하지만, 모든 일은 결과 못지 않게 과정도 중요하다고 판단했기 때문이에요. 그 과정에 충실함을 보인 크루들을 선별해 ‘슈퍼크루'로 지정하고 보상을 제공하는 과정도 여기에 포함됩니다. 이 변화무쌍한, 그리고 결코 쉽지 않은 크립토(crypto) 세계에서 ‘정도'를 걸어가고 있는 ‘코인원스러운' 성과관리 시스템이 아닐까 생각합니다. :-) 우선 코인원 PoW가 어떤 과정으로 진행되는지 한 번 살펴볼까요? 코인원 PoW는 아래와 같은 5가지 단계로 진행됩니다.Self mining셀프마이닝은 지난 6개월 동안 자신이 진행한 업무와 그 과정에 대해 에세이를 작성하는 단계입니다. 에세이를 작성할 때는 자신이 진행한 업무와, 업무를 진행하는 과정에서 본인이 생각하는 잘한 부분 및 아쉬웠던 점들 등에 대해서 작성합니다. ‘잘한 부분'의 경우, 성과가 좋았던 점 외에 성과는 좋지 않았어도 최선을 다한 것에 대해 상세히 작성합니다. Peer mining피어마이닝은 업무적으로 연관된 동료 크루의 셀프마이닝을 토대로 그 동료에 대한 의견을 작성하는 단계입니다. 함께 일했을 때 동료 크루의 좋았던 점, 훌륭한 점, 배워야 할 점 등을 서술하고, 앞으로 더 효율적인 협업을 위해 동료가 개선하면 좋을 것 같은 점도 함께 작성해요. Segwit세그윗 단계에서는 위 두 단계에서 도출된 자기 평가와 동료 평가를 토대로 각 셀의 리더들과 1:1 면담을 진행합니다. 이때 셀 리더들이 꼭 염두해야 하는 것은, 코인원 PoW를 통해 우리가 이끌어내고자 하는 것은 '평소의 관심과 피드백, 그리고 동반 성장'이라는 것이죠. Blue paper세그윗을 통해 최종 작성되는 것이 바로 블루페이퍼에요. 크루들의 면담을 진행한 각 셀의 리더들이 작성하죠. 이 내용은 크루들이 지난 6개월 동안 한 일에 대한 자기 자신과 동료, 그리고 셀 리더의 피드백이 담긴 한 장의 문서죠. Consensus마지막으로 컨센서스 단계에서는 최종 완성된 블루페이퍼를 바탕으로 본부별 슈퍼크루를 선정합니다. 그리고 이렇게 선정된 슈퍼크루에 대해 전체 크루가 동의 가능한지에 대한 적절성 심사가 한 번 더 진행됩니다. 현재 코인원에는 약 120명의 크루들이 일하고 있어요. 사실 모든 크루들의 정성적인 분석 과정을 진행하는 것이 쉬운 일은 아니에요. 코인원 PoW는 셀프마이닝부터 블루페이퍼 작성 및 슈퍼크루 선정까지 약 5주에 걸쳐 진행되는, 길지만 자연스러운 평가와 이를 통한 성장의 과정이라고 생각합니다.이 과정에서 코인원 피플팀 여러분들이 정말 많은 노력과 정성을 기울여주고 계시죠!그렇게 10월의 어느 날, 2018년 상반기의 코인원 PoW가 성공적으로 마무리가 됐습니다. :-)코인원의 모든 크루들이 지난 상반기의 업무에 대해 작업증명을 진행했죠! 그리고 또 다른 6개월 동안 앞으로 다시 힘차게 나아가기 위해 자신의 어떤 좋은 점을 강화하고, 어떤 점은 보완하면 될지를 나 자신, 그리고 동료 크루들과 공유하는 시간이었습니다.또, 이렇게 진행된 2018년 코인원 PoW를 통해 여섯 명의 슈퍼크루가 탄생했어요!2018 코인원 슈퍼크루를 소개합니다 :-)올 한해도 모든 크루가 각자의 분야에서 최선을 다했어요.슈퍼크루는 그 중에서도 특히 다른 크루들에게 좋은 영향을 준 크루들을 선정한 것인데요, 이 분들에게는 코인원의 특별한 추가 보상이 제공될 예정이랍니다. :-)코인원은 앞으로도 크루들이 즐겁게 일하면서 성장할 수 있는 여러가지 재밌고 유익한 도전들을 해보려고 합니다. 코인원이 크립토 세상에서 어떤 즐거운 도전들을 하고 있는지, 앞으로도 코인원 공식 블로그를 통해 지켜봐주세요! :-)#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #기업문화 #조직문화 #사내복지 #업무환경 #팀원소개

이번 칼럼에서는 프로세스 마이닝의 Input 요소인 이벤트 데이터에 대해 살펴보겠습니다. 이벤트 로그를 어떻게 얻고 프로세스 마이닝 분석이 가능하도록 어떻게 전처리를 할까요? 이벤트 로그는 SAP와 같은 ERP 시스템, 미들웨어, 금융 정보시스템, 사물인터넷 데이터 등 다양한 정보 소스에서 얻을 수 있습니다. 정보 소스는 어디에나 있으며 대부분 수많은 DB 시스템으로 구성되어 있기 때문에 문제는 어떤 데이터를 추출하고 어떻게 프로세스 마이닝에서 사용할 수 있는 이벤트 로그로 변환하느냐는 방법입니다. 아래 그림은 프로세스 마이닝에 필요한 데이터를 설명하는 개념 모델입니다. 각각의 케이스는 이벤트로 이루어져 있고, 이벤트는 여러 속성을 가질 수 있습니다. 원본 소스로부터 이와 같은 형태의 데이터를 추출하고 변환하는 방법이 필요합니다.[그림 1] 이벤트 로그 개념예를 들어 SAP에서 데이터를 추출하는 경우를 보겠습니다. SAP에는 수천 개의 테이블이 있고 여기에는 많은 이벤트 관련 정보가 있습니다. 정확한 데이터를 추출하려면 분석하고자 하는 프로세스가 무엇인지 정의하고 어디가 시작 위치인지 어디가 종료 위치인지 찾아야 합니다. 이러한 데이터 식별, 위치 지정이 제대로 되어야 적절한 이벤트 데이터 수집과 범위 선정이 가능합니다. 병원 데이터도 환자와 관련된 정보가 담긴 1,000개 이상의 테이블을 볼 수 있습니다. 병원 데이터를 분석하려면 마찬가지로 분석 프로세스를 정의하고 분석 범위와 이벤트 데이터 속성에 대해 정의해야 합니다. 이는 중요하지만 어려운 일입니다. 프로세스 마이닝을 위해 필요한 데이터는 여러 정보 시스템에 산재되어 있으며 수집할 수 있는 데이터의 종류와 양도 어마어마합니다.  근본적인 데이터 모델 구조를 이해하고 적합한 이벤트 데이터의 종류와 범위를 산정해야 하며 수집한 데이터를 하나의 테이블로 정리할 수 있어야 프로세스 마이닝을 위한 적절한 이벤트 로그 수집과 준비가 되는 것입니다.티켓 예약 데이터를 통해 데이터 추출과 이벤트 매핑을 살펴보겠습니다. 다음 그림에는 티켓, 예약, 공연, 지불, 고객과 같이 다양한 엔티티(Entity)가 있으며 이러한 엔티티는 관련된 이벤트 또는 액티비티를 가지고 있습니다.[그림 2] 티켓 예약 데이터베이스 구조데이터 분석을 위해 우리가 가장 먼저 결정해야 할 것은 프로세스 인스턴스, 즉 케이스가 무엇인가입니다. 우리가 티켓의 수명주기를 설명하는 모델을 알고 싶다면 티켓을 케이스로 설정하고 이에 해당하는 액티비티를 찾아야 합니다. 예약, 공연, 지불 등의 액티비티가 필요하며 여러 티켓이 동일한 예약 기록이나 지불 이벤트를 가지고 있을 수 있습니다. 따라서 여러 개의 다른 프로세스 인스턴스가 하나의 예약에 연결되어 있을 수 있습니다. 또한, 프로세스 모델이 예약에 대해 설명한다고 하면 다른 액티비티를 찾아야 합니다. 이러한 과정이 명확하거나 쉽지 않기 때문에 어려움이 있습니다. 하나의 예약에 5장의 티켓, 2번의 지불과 같이 여러 이벤트가 연결될 수 있습니다. 예약 취소와 같은 이벤트는 티켓, 공연, 예약 등 여러 엔티티에 영향을 미치게 됩니다. 따라서 엔티티 간의 단순 일대일 대응은 없으며 원하는 이벤트 로그를 얻기 위해서는 데이터 전처리가 필요합니다.케이스 선정과 매핑 문제 외에도 정확한 데이터 추출을 위해서는 고려해야 할 다양한 문제가 있습니다. 케이스나 이벤트가 기록되지 않는 데이터 누락이 발생할 수 있습니다. 실제 수행자가 아닌 다른 수행자가 기록되는 것과 같이 데이터가 정확하지 않을 수 있습니다. 원하는 데이터 레벨이 아닐 수도 있습니다. 예를 들어 개별 작업자에 대해 확인하고 싶은데 부서 레벨이 기록되어 있을 수 있습니다. 또 다른 문제는 관련성이 없는 데이터가 많아 분석 항목을 찾기 어려울 수 있습니다.지금까지 프로세스 마이닝의 이벤트 데이터 관련 문제를 검토하였습니다. 이러한 문제점을 염두에 두고 데이터를 추출해야 프로세스 마이닝 분석을 제대로 수행할 수 있습니다. 프로세스 마이닝 분석을 위한 로그 생성 가이드라인 (https://blog.naver.com/prodiscovery/221160671117) 칼럼을 참조하시면 데이터 추출 문제 해결에 대해 도움을 얻을 수 있습니다.#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트