흐흐흫. 저희가 어떤사람인지 궁금하신가요오오오오~~~그래서 준비했습니다! 레터플라이 동업자들을 소개합니다![A군]UC 버클리 학사 성적 우수 졸업유펜 석사 성적 우수 졸업STX 해외 장학생 (4년간 2억 장학금), 삼성 해외 장학생 (2년간 1억 장학금)금융 파생상품 모델링 3년 경력[B양]하버드대 학사 성적 우수 졸업삼성 해외 장학생 (4년간 2억)유명 해외로펌, 컨설팅 회사 2년 경력[C군]서울대 학사 성적 우수 졸업과학고 조기졸업개발, 세무, 마케팅 등 하기만 하면 마스터하는 능력자[D군]부산대에서 시각디자인을 전공했으나신이 내린 개발 능력때문에개발자로 5년 이상을 살아온 비운의 디자이너레터플라이에서는제품관리마케팅개발 (IT)분야에서 멋진 동업자를 찾고 있습니다.학력, 성별, 나이는 보지 않습니다.능력, 열정, 인성을 봅니다.레터플라이에 관심있다면?!망설이지 마시고 지금바로 연락주세요!#레터플라이 #채용 #팀소개 #팀원소개 #기업문화 #조직문화 #사내복지

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;">

OverviewQA담당으로 입사하자마자 12월 21일, 22차 업데이트를 위한 앱 QA를 진행했습니다. QA는 이전 직장에서도 꾸준히 했는데도 아직까지 적응하기 어렵습니다. 그렇게 확인을 많이 하는데 오류는 왜 배포 후에 보이는 걸까요.분노를 느끼는 중22차 QA 한줄 요약: 뫼비우스의 QATC 수정 중QA담당자의 카운트다운은 기획이 완료된 SB를 참고하여 TC를 수정하는 것부터 시작됩니다. 물론 이전의 다른 과정들도 중요합니다만 이때부터는 마음속에 폭풍전야의 전운이 돌기 시작합니다. TC를 수정하는 순간 시트를 통째로 머릿속에 외워야 합니다. Depth 구성이나 QA해야할 내용을 담당자가 미리 파악하지 못한다면 테스트 도중 쏟아지는 문의사항들을 감당하지 못하기 때문이지요.뫼비우스의 QA...어떤 문의사항이냐고요? 이것을 설명하려면 브랜디의 QA과정을 먼저 설명드려야 할 것 같습니다. 브랜디의 QA는 내부 테스트와 외부 테스트로 구분되어 있습니다. 내부 테스트는 R&D본부의 서비스팀에서 1차 개발이 완료된 Android, iOS 버전의 앱을 검증합니다. 반면 외부 테스트는 브랜디 전체 직원들이 모여 앱을 검증합니다. 개발자가 아닌 사용자 입장에서 QA가 진행되다 보니 수많은 질문들을 마주합니다.“이건 왜 이럴까요?”“꼭 이래야만 할까요?”“이상한 것 같은데요.”????????그러나, QA담당의 책무를 다하기 위해 이를 꽉 무는 일이 있더라도 친절하게 답변합니다. 좋은 앱을 위해 모두가 노력하는 거니까요. 게다가 QA전문 회사에 다니면서 여러 프로젝트를 경험해봤지만, 회사 직원 전체가 배포 전에 테스트하는 게 굉장히 좋은 과정이라고 느껴졌습니다. 개발자가 아닌 고객의 관점에서 품질을 높이겠다는 회사의 방향을 엿볼 수 있었기 때문입니다.Android QA sheet중 일부iOS QA sheet중 일부사실 이렇게 꼼꼼한 과정을 거쳐도 완벽한 테스트는 없습니다. QA담당은 지속적으로 테스트를 해야 합니다. 그렇기 때문에 입사 후 처음으로 경험했던 브랜디의 QA테스트는 무사히 마쳤지만 아직도 현재진행형이기도 합니다. 내부, 외부 테스트 때 나온 결함을 Android와 iOS개발자에게 직접 전하고, 다시 테스트를 진행하고 있습니다.ConclusionQA 담당자로서 첫 번째로 중요한 업무는 QA프로세스의 정립입니다. 브랜디는 스타트업 회사이기 때문에 QA프로세스의 완성도가 아직 부족합니다. (제가 입사한 이유이기도 합니다.) 두 번째로는 JIRA(BTS) 도입으로 이슈관리의 개념부터 만드는 것도 목표 중에 하나로 생각하고 있습니다. JIRA가 있으면 소스코드 관리, 이슈 관리, 빌드, 프로젝트 관리 등의 효과를 얻을 수 있는데 특히 이슈관리(버그추적) 시스템이 도입되면 신세계가 열립니다. JIRA이슈관리 시스템은 이슈를 쉽게 조회할 수 있고, 저장된 속성을 이용해 통계자료까지 얻을 수 있습니다. 이슈 형태를 이용한 검색도 가능하기 때문에 이전에 발생했던 이슈를 쉽게 찾아볼 수 있습니다. (브랜디를 포함해 이슈관리 시스템을 이용하지 않는 회사가 많습니다만… 여기에 글을 쓴 이상 제가 해야겠지요.) 또한 다른 개발자들과 함께 피, 땀, 눈물을 쏟아내다 보면 selenuim, appium을 이용한 자동화 테스트 도입도 할 수 있을 거라 생각합니다. QA와 관련된 자세한 이야기는 앞으로도 꾸준히 공유하겠습니다. 기대해주세요.글김치영 대리 | R&D PM팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #기업문화 #조직문화 #업무환경 #인사이트 #경험공유

패션블로그 웹뜰입니다3월에 다녀온 여름나라 코타키나발루 3박5일 웹뜰 해외워크샵 두번째 이야기를 들고 왔습니다. 마누칸 섬에서 패러세일링 까지의 이야기로 1차 후기를 끝냈었는데요 첫번째 이야기는 아래 참고하시면 됩니다:)[웹뜰 창립 10주년 해외워크샵] 3월에 다녀온 여름나라 코타키나발루 3박5일 이야기 (1)패러세일링 이후 점심을 먹기 위해 마누칸섬으로 다시 돌아와 처음에 자리 잡았던 식당으로!!씨워킹을 나갔던 직원분들은 이미 돌아와 계셨구요 두팀으로 나누어 갔던 패러세일링 팀도 모두 왔네요 이제 점심식사를 기다려 봅니다. 점심식사는 현지식이라고 하는데 드디어 나왔네요 따란~!현지식 세트라고 하는데 왠열 엄청 맛있어요 제 입맛에 딱!!가운데 새우랑 고기 바베큐는 일인 일꼬치!그리고 개인에게 플레이팅되어 나온 음식은 볶음밥이랑 샐러드 웨지감자 작은꼬치, 옥수수, 닭고기 등이였어요 패러세일링을 하고 돌아와서 배가 고팠던건지 아니면 입에 정말 잘 맞았던건지 남김없이 흡입 했답니다. 특히나 저 옥수수는 지금도 생각나요 밥도 배부르게 먹고 이제 다시 마젤란수트라하버 리조트로 돌아가기전까지 자유시간이 주어졌습니다. 웹뜰 직원들 각자 흩어져서 섬구경을 하기도 하고 스노쿨링을 하기도 했어요 여기저기 일단 섬구경을 하다보니 바다도 예쁘고 섬 곳곳이 어찌나 이쁘던지 사진찍다 시간이 다 갔을 정도였어요 식당 바로 앞에 있는 코코넛 가게 조차도 포토스팟! 갬성사진 스팟이였다구요코코넛 가게에서만 사진을 몇장을 찍었는지 몰라요 ㅎㅎㅎ정말로 사진이 잘 나와 찍어 준 사람도 찍힌 사람도 만족했답니다. ㅋㅋ마치 윤식당 같은 느낌 물씬이랄까 ㅎㅎㅎ 웹뜰 직원들에게 인기 만점 코코넛 가게 사진을 찍고 있으니 어디선가 나타난 야옹이 한마리꺄아 넘나 귀여워서 야옹아 야옹아 하고 불러보지만 고개를 휙 돌려버리네요 한국말이라 못알아 듣는 걸까요? ㅋㅋ사람들이 하도 귀찮게 하니 코코넛 가게 위로 휙 올라가서 잠을 자네요 이 모습 조차도 어찌나 귀엽던지 ㅋㅋㅋㅋ  마누칸 섬은 정말 조용하고 정말 평화롭더라구요 대부분이 한국 사람이랑 중국 사람이긴 했지만 그래도 동양말고도 세계 각국에서 오신 분들이 많이 계셨어요  밥도 먹고 섬 구경 하면서 소화도 시켰으니 이제 바닷물에 몸도 좀 담구고 스노쿨링도 즐겨봅니다물이 깨끗하고 햇살이 따뜻해서 물에 몸 담궈 놓고 둥둥 떠다니기만해도 기분이 좋았습니다. 스노쿨링 장비는 따로 비용 내고 대여가 가능 하지만 저희는 장비를 본인거 챙겨가서 즐겼답니다. 구명조끼만 마젤란수트라하버 선착장에서 비용내고 대여했어요 스노쿨링 하면서 액션캠으로 찍은 바닷속 영상입니다. 물이 정말 맑고 깨끗했답니다. 얕은 바다인데도 물고기들이 많이 있었습니다. 다만 종류가 생각보단 많지 않아 조금 아쉬움이... ㅎㅎ마누칸섬 바다에서 열심히 놀고 있는데 사람들이 웅성웅성 거립니다. 앗! 두둥 이녀석은 뭐죠? ㄷㄷㄷ 엄청난 녀석이 바닷가에서 어슬렁 어슬렁 사람들이 몰려와 사진찍고 난리가 났는데도 저 녀석은 아무 동요없이 어슬렁 거리다가 숲속으로 사라졌답니다. ㅎㅎ마누칸 섬에서 즐거움을 사진으로 남겨두고 이제 다시 마젤란수트라하버리조트로 돌아갑니다.  잠시 자유시간을 가지고 나서 저녁식사를 하러 나왔습니다. 둘째날의 저녁식사는 아침에 조식을 먹었던 식당에서 뷔페식으로 먹을수도 있구요 비치가 보이는 바에서 간단하게 먹을수도 있었습니다. 저희 웹뜰 직원들도 각자 나누어서 원하는 곳에서 선셋을 바라보며 식사를 했답니다.  코타키나발루의 아름다운 선셋을 보고 정말 말잇못! 다시한번 이곳에 워크샵을 오게 되어 감사하고 행복한 순간 이였답니다. 7시간이 지나며 해가 떨어질수록 노을빛이 붉은색에서 보라색으로 변하는데 너무 아름다워서 선셋 감상하느라 밥먹는 것도 잊을 뻔 했다는 건 안비밀 ~식사를 마치고 본격 웹뜰워크샵 행사를 시작하기 위해 대여한 홀로 모였습니다. 그냥 여행이 아니라 웹뜰 10주년을 기념하는 워크샵이기에 10주년을 기념하는 대표님의 말씀도 듣고 앞으로 나아갈 웹뜰에 미래에 대한 건설적인 이야기도 하고 푸짐한 상품을 놓고 여러가지 게임들을 했었답니다.   워크샵 오기전에 웹뜰에 대한 각자의 이야기도 동영상으로 풀어놓고  10년동안의 웹뜰 사진이나 동영상들을 차곡차곡 모아놨다가 이렇게 기념하는 자리에서 틀어놓으니 감회가 정말 새롭더라구요  대표님의 소중한 말씀웹뜰 주식회사 창립 10주년기념 함께한 10년 , 함께 할 10년함께 고생하며 10년동안 잘 꾸려온 회사 앞으로 10년 20년 30년... 쭈욱 함게 할 웹뜰 기대해 보겠습니다.  그리고 대표님 말씀에 이어 부장님의 말씀웹뜰의 10년이 지나는 동안 오랜 세월 함께 한 부장님이시기에 더욱 감회가 새로우셨다고 합니다. 앞으로 웹뜰의 성장과 더블어 여기 있는 웹뜰 직원들 모두 함께 성장하기를 바라신다는 말씀! 그리고 생일 축하파티까지!원래 한달에 한번씩 매달 생일자 파티가 있는데 이번에 워크샵 자리에서 축하하게 되었습니다.   매번 회사 사무실에서 생일파티하다가 먼 나라에서 생일파티 하니 더욱 분위기가 새롭네요생일자 분들도 감회가 새롭다 하더라구요 :)다시한번 축하드려요 두분 생일 그리고 3월의 우수사원시상도 하였답니다. 우수사원 받으신 분들도 축하축하 드려요~~앞으로도 웹뜰을 위해 열심히 일해주실꺼죠? ㅎㅎㅎ이제 본격적으로 게임을 하기 전 강당대여하면서 코타키나발루 마젤란수트라하버에서 제공되는간단한 주전부리로 배를 채워 봅니다. 게임이 격할 수 있으니 힘내야죠 ㅋㅋ 먼저 조 소개와 구호소개가 있었습니다. 사회자와 심판 사진촬영사는 빠지고 제비뽑기로 1조부터 4조까지 5명씩 총 4개조로 나누었답니다. 구호에서 부터 천차만별 조의 특색이 보이는 것 같더라구요  첫번째 게임은 몸으로 말해요 입니다. 스케치북에 주어닌 속담을 보고 말하지 않고 몸으로 표현하는 건데 과연 어떤 모습들을 보여줄지!!ㅋㅋㅋㅋㅋㅋ 말 하지 않고 몸으로면 표현하려니 답답들했죠?기상천외한 행동들과 표현력 ㅋㅋㅋ 그렇지만 못알아듣는 조원들 그 중 누가 구멍일까 지켜보는 재미도 쏠쏠하고 지켜보는 사람들은 함박웃음 빵빵 터졌답니다. ㅎㅎ 그리고 카드 뒤집기 게임앞면과 뒷면으로 나누어 어느쪽이 더 많으냐에 따라 이기는 게임인데 웹뜰 직원들 정말 기동력에 행동력 짱짱! 아무도 몸 사리지 않고 열심히 게임을 하는 모습보고 놀랬답니다.  카페트에 미끄러지지 않으려고 맨발로 하는 투혼까지! 심판의 준비~시작!과 날아다니는 모습들 ㅎㅎ정말 대단했어요 몸사리지 않고 어찌나 열정적이던지!! 이모습은 현장에서 직접봐야 더 대단한데 말입니다. ㅋㅋ절대 싸우는거 아님 게임하는거 맞습니다!! ㅎㅎㅎ 게임이 끝났네요 후끈후끈 열정적으로 게임한 팀들은 너무너무 지쳤어요 언뜻보아 노란색면과 흰색면의 카드색이 비슷해 보이는데과연 어느 팀이 이겼을지 두구두구두구  심판의 확인결과 !! 짜잔 노란카드 팀의 승리입니다.  결승전까지 불태워서 승리한 1조는 환호를 한뒤 모두 지쳐버렸다는 후문이 ㅋㅋㅋㅋ이후로도 두어번정도 게임을 더 진행하였으나 스크롤의 압박으로 그냥 넘기실지 몰라 게임은 여기까지만 올리겠습니다. ㅋㅋㅋ최종우승은 역시나 게임에 적극적으로 참여하고 열의를 불태운 1조 였답니다. 평소에 성격이 조용하신 분들로 구성된 팀이라 저렇게 열의를 불태워서 1등을 할지 전혀 몰랐는데 말이죠 ㅎㅎ역시 할때는 시원하게 하는 웹뜰 직원답네요 최고!1등한 1조원들은 게임상금 30만원입니다. 부럽습니다요 :)1등 한 조 외에도 각각 상품이 어마어마해서 많은 직원분들이 상품을 받아가셨답니다. 10주년 워크샵을 위해서 해외여행부터 상품까지 크게쓰신 웹뜰 이태경대표님께 다시한번 감사인사 드립니다. 마지막으로 다같이 웹뜰 창립10주년 구호함께한 10년 함께할 10년를 외치며 건배를!! 모든 직원들이 함께여서 정말 즐겁고 기분좋은 날이였답니다. 마지막으로 단체사진 한장!  끝으로 워크샵을 마쳤습니다함께여서 즐거웠던 시간이였고 앞으로도 함께할 날이 기대되는 웹뜰입니다. 이 날의 그 마음 변치 않고 열심히 더 좋은 상품으로 보답하고  고객님들의 목소리에 귀기울이며 직원끼리도 화합하며 일하는 웹뜰이 되겠습니다. 워크샵이 끝났다고 해서 여행이 끝난건 아닙니다. 아직 저희에겐 이틀의 시간이 더 남아있답니다. ㅎㅎ 이렇게 둘째날 밤도 끝나는게 아쉬운 직원들은 워크샵 이후에 한 방에 모여서 한잔으로 마무리!아쉬워할꺼라 미리 예상하신 대표님께서 웹뜰 직원들을 위해 양주까지 챙겨주셨답니다. 대!! 박!! 감사히 잘 마셨습니다. 이렇게 둘째날 밤도 마무리 하였구요 이제 코타키나발루는 셋째날 과 넷째날 이야기가 남았네요 웹뜰 10주년 기념 코타키나발루 워크샵 두번째 이야기는 이렇게 마치도록 하겠습니다. 셋째날 넷째날 이야기도 기다려 주세요 #웹뜰 #웹뜰워크샵 #웹뜰10주년워크샵 #코타키나발루 #마젤란수트라하버 #해외워크샵 #해외여행 #워크샵 #말레이시아

EOS Smart Contract 를 위한 준비와 토큰 발행 그리고 C++를 활용해 토큰의 간단한 기능을 개발해 보겠습니다.환경 구성 및 지갑 생성은 SAM 님의 아래 2글을 참고해 주시기 바립니다.EOS — 설치 및 실행 (1/2)EOS — 동작구조 및 환경설정(2/2)지갑 생성하기SAM 님의 포스트를 참고 하셨다면 아마 다음과 같이 ‘default’ (별도의 이름을 지정하지 않았을 시) 지갑을 생성 하셨을 겁니다.이 지갑을 사용하여 계정을 Create 한 후 Key 를 Import 하겠습니다.Key 생성하기$ cleos create key위 명령을 실행 하시면 다음과 같은 화면을 얻을 수 있습니다.create key 명령의 결과**주의 : Private Key는 Public Key의 소유를 증명하는 중요한 개념으로 절대 타인에게 노출하면 안됩니다.AdditionalKey 생성 후 지갑에 import 하기 귀찮으시다면 생성된 지갑에서 바로 Key 를 생성하셔도 됩니다.$ cleos wallet create_key위와같이 key가 생성 됩니다. 하지만 public key 만 보이기 때문에 하단 명령 입력 후 지갑 key를 입력하면 private key를 확인할 수 있습니다.$ cleos wallet private_keys지갑에 Key import하기지갑은 Public Key — Private Key를 저장하는 저장소 입니다. 생성된 키를 지갑에 저장하기 위해 다음과 같은 명령어를 입력합니다.$ cleos wallet import-n : 옵션을 사용하면 지갑의 이름을 지정합니다. 지정하지 않는다면 기본 생성된 default 지갑으로 지정됩니다.위 명령을 입력 하면 key 가 임포트 되었다는 결과를 확인 할 수 있습니다.** 만약 지갑을 Unlock 한 상태가 아니라면 ‘private key: Error 3120003: Locked wallet’ Exception 이 나옵니다.unlock 을 위해 다음 명령을 실행한 후 wallet 생성시 저장했던 Key를 입력하여 Unlocked 상태로 만들어 줍니다.$ cleos wallet unlock password: Unlocked: default(Optional) 지갑에 저장된 Key 리스트 확인다음 명령어를 입력하여 지갑에 key 가 잘 import 됐는지 확인합니다.$ cleos wallet keys계정 생성eosio.token 이라는 이름으로 계정을 생성하도록 하겠습니다.** 지갑과 Key 그리고 계정에 관해서는 Hexlant 미디움에 게재될 예정입니다.$ cleos create account eosio eosio.token EOS63kstp8kthzJY3rAotp1LAxUDbWk4MywReG578R2ddbktrDHYKcreator : eosioaccount name : eosio.tokenowner key : 지갑에 import 된 keyAdditional본 포스팅은 local 환경에서 빌드 후 System Contract 들이 적용되지 않은 상황을 가정하였습니다. 만약 Public Network 환경에서 접속 시 eosio 와 eosio.token을 사용할 수 없습니다.또한 계정이름은 다음과 같은 규칙을 따릅니다.- 12문자- 12345abcdefghijklmnopqrstuvwxyz 만 사용 가능** 만약 ‘Error 3090003: provided keys, permissions, and delays do not satisfy declared authorizations’ 에러 발생 시 eosio 에 대한 key 를 지갑에 import 해야 합니다.eosio 에 대한 정보는 다음과 같습니다.public key: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CVprivate key: 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3위 과정을 모두 마쳤다면, EOS 지갑과 키 그리고 계정에 대한 권한을 모두 가지고 있는 상태가 됩니다. 다음 포스팅에서는 이 계정을 사용 하여 Token 을 발행하는 방법을 알아보도록 하겠습니다.감사합니다#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

데이터진흥원 DB 스타즈 프로그램에서 연락이 와서 오늘 오후 스타트업 얼라이언스에서 진행했던 스타트업 조직문화 특강. 조직,인사 컨설턴트였다가 조직심리 박사과정을 하고 있고(논문 써야 하는데 ㅜㅜ) 이제는 작은 스타트업의 대표가 된 이력때문에 패스트캠퍼스에서 연락이 와서 시작했던 강의인데 그 이후에 이 내용으로 여기저기서 강의 요청이 와서 신기해하고 있다. 그런데 아마 이 내용으로 강의는 다음 달에 있을 현대아산나눔재단이 마지막이지 않을까 싶다. ^^ '나도 팀원으로 일하고 싶은 스타트업 만들기'라는 다소 유치해보이는 강의제목을 달아놓았는데 실제 우리 마보를 그런 스타트업으로 만들어 놓기 전까지는 내가 그런 말을 하고 다닐 자격이 있을까 하는 생각이 들기 때문이다.우리 마보가 저 제목에 당당한 스타트업이 되면 그때 당당하게 우리의 사례를 알리는걸로! 그러려면 마보 서비스를 더 알리고 우리 마보팀부터 키우는 것으로~덧붙임: 그래도 끝나고 Dable 과 rainist 에서 대표로 오신 두분은 도움이 많이 되었다고 하셔서 기뻤음. 사실 이 강의는 스타트업 CEO분들께 꼭 전달하고 싶은 내용임. 한마디로 요약하면 스타트업 대표가 본인 스스로를 동기부여하는 것이 무엇인지 먼저 생각해보고 직원들을 동기부여하라는 것!#마보 #스타트업 #스타트업강연 #강연후기 #조직문화 #기업문화 #사내문화 #특강 #스타트업CEO

안녕하세YO!미미박서의 사소하지만 특별한 이야기를 담아오는 Moth입니다!  본격적인 인터뷰에 들어가기에 앞서미미박스는 현재 '도와줘요 미미 SOS' 프로그램을 운영하고 있는 것을 알고 계신가요?바로 '도와줘요 미미 SOS'는 뷰티 고민 상담소인데요!매주 목요일 3시-5시 네이버 톡톡(채팅)에서 평소 가지고 있던 뷰티고민을 문의하면 모든 고객님들께 미미언니가 뷰티 솔루션을 드리고 있는 프로그램입니다! ↓↓↓ 도와줘요 미미 SOS 자세히 알아보러가기 ↓↓↓이처럼 미미박스는 고객의 입장에서고객 한 분 한 분의 고민을 해결하는 데에 도움을 드리고 더 좋은 경험을 할 수 있도록 노력하고 있습니다!현재 미미박스 판교 사옥에는 고객을 생각하는 회의실명으로 CUSTOMER 라는 공간도 따로 있을 정도랍니다!미미박스 회의실 CUSTOMER고객은 바로 미미박스의 중심!        ~(  ͡°  ͜ʖ  ͡° )~ 다시 본론으로 돌아와서..Humas of MEME는 탐험가 정신을 지닌 미미박서 분들의 가치관 혹은 삶을 살아가는 방식에 대한 이야기를 듣고자 진행되고 있는 프로젝트입니당 :)  이번 주에 저 Moth는가장 직접적으로 고객과 소통하고 있는 CS팀의 Luna를 만나보았습니다!Luna는 ‘해질녘 어느날…(아련)’ 머리 스타일을 가지고 있는 미미박스인데요!개성 있는 헤어스타일과 다양한 뷰티 제품 지식을 셥렵하고 있어서역시 코덕계의 성지, 미미박서! 라는 생각이 딱 들었습니당   바로 오늘 그 파!워!소!통!러! CS 팀 루나의 이야기가 궁금하시지 않으세용? 저는 매우매우 기대가 됩니다.(나는. 지금. 인터뷰가. 땡긴다.)그럼 그 두번째 주인공, LUNA를 만나볼까요?   Q. 뷰티 회사의 직원으로서 느끼는 ‘뷰티’가 아니라, Luna가 느끼는 ‘아름다움’ 이란 무엇인가요?A. 자기 자신을 사랑하는 거라고 생각해요. 제가 화장품에 관심을 갖고 좋아하게 된 계기이기도 하고 항상 즐거워 보이는 비결이기도 합니다(하지만 그로 인해 살을 못 빼는 치명적인 단점이 있다는 후문...).  어렸을 때에는 이해할 수 없었던 ‘나 자신을 사랑해야 다른 이에게도 사랑받는다는 말’을, 지금은 누구보다 공감하고 있어서 제가 사랑하는 모든 분들이 공감하시고 실행하실 수 있으면 좋겠네요! Q. 혹시 좋아하는 문장이나 문구 있으신가요?A. 어렸을 때 친구들이랑 모여서 모임이름이자 건배사로 썼던 단어인데요(웃음). 화.개.장.터! 입니다. 한명이 큰 소리로 화개장터! 를 선창하면, 다같이 화려한·개그를·장시간·터트리자! 라고 외치고 건배를 하곤했어요(웃음). 저는 누군가에게 도움이 되거나 좋은 사람이 되었을 때 만족하고 누군가를 웃게한 제 자신이 가장 좋거든요.  그러다보니 저런 웃긴 구호도 만들어서 놀고 그랬었네요. Q. 누군가에게 도움이 되는 존재이고 싶은 Luna 가 왜 CS팀에서 근무하고 계신지 단번에 이해가가네요! 혹시 그렇다면 ‘미미박스’ 뷰티 회사의 CS 팀에서 일하는 특별한 점은 무엇이 있을까요?A. 제일 먼저 생각나는 건, 아무래도 뷰티회사 직원이다보니 화장품을 포함한 뷰티제품을 많이 사고 써보고 관심있어 한다는 거죠! 덕분에 월급이 통장을 스쳐 지나가 버리지만.. ‘그래! 이건 내가 뷰티회사 직원이기 때문이지! 직업정신이다!’ 라며 죄책감을 잊을 수 있다는 장점이 있습니다(웃음).미미박스에서 일하면서 만족하는 건 저희 CS팀이 일반 고객센터처럼 단순 처리만 하는 게 아니라 CS팀으로서의 책임감과 자부심을 가지고 다각도로 고객들을 케어하려고 한다는 점이에요.어려운 이슈가 발생했을 경우에는 정해진 룰에만 따르는 것이 아니라 다같이 의견을 공유하고 가장 나은 처리를 할 수 있도록 하고 있습니다! 수동적이 아닌 주도적으로 일을 하고 있지요(뿌듯).고객의 불편함을 미리 방지할 수 있도록 대처를 하거나 더 나은 방법으로 고객께서 미미박스를 이용하실 수 있도록 사후관리도 하고있으며 무엇보다 고객들께 친근하게 접근하려고 노력하고 있습니다. Q. 어떻게 친근하게 접근하고 계신지 더 자세히 여쭤봐도 될까요?A. 예를 들면 저희는 고객이 제품에 대해 궁금해하시면 바로 자리를 박차고 일어나 제품을 준비해온뒤 통화하면서 제품을 발라보고 사용해보면서 경험을 공유하고 있어요.미미박스를 사랑해주시는 소중한 고객님들 한 분의 문의도 놓치고 싶지않기에 네이버지식인, 구글앱스토어, SNS, 고객센터전화, 1:1게시판으로 오는 문의를 모두 응대하고 있습니다. 더불어 소중한 미미박서님들의 문의도 저에게 슬랙(사내SNS)만 주시면 열심히 도와드리고 있습니다(아직 모르는 분들도 있으신거같아요! 내부 직원 문의는 루나에게 간단히 슬랙만 주셔도되고 가벼운 마음으로 찾아와주셔도 되어요!).사랑하는 저희 팀원들의 멋진 CS마인드도 특별하고 더불어 미미박스에는 타 부서에도 고객님을 생각하고 도와주시는 여러분들이 계셔서 많은 도움을 받을 수 있어서 더 멋지고 특별한 것 같아요.  고객과 미미박서 여러분들에게언제든 따뜻한 도움을 주고 계시는 Luna ❤︎실제로 루나는 다양한 뷰티 소식들을 미미박서분들께 공유해주시는 메신저 역할도 톡톡히 하고 계십니다>.<실제 근무하고 있는 루나의 모습! 루나의 책상에는 코덕을 증명하듯다양한 제품들과 향기가 가득했습니다..! (모뜨는 반성합니다_책상아 미안해)미미박서의 삶! 그리고 일! 을만나보셨는데 어떠셨나요?저는 인터뷰를 진행하면서 와- 미미박스에 이런 멋진 사람들이 많이 있구나! 라고 생각하고다음 인터뷰를 만날 생각에 참 기뻐용 허허.다음에는 NEW 미미박서 이야기를 NEW롭게 들려드리도록 하겠습니다!그렇다면 오늘은 ㅎㅎ루나의 건배사로 포스팅을 마치도록 하겠습니다!화!개!장!터!

최근 리디북스에서는 판타지 연재물을 웹에서 바로 볼 수 있는 기능을 새롭게 선보였습니다.기존에는 별도의 앱을 설치하고 다운로드하는 과정을 거쳐야 했기에 연재물을 보는 사용성이 좋지 않았습니다만, 브라우저에서 바로 볼 수 있는 “웹뷰어” 기능을 제공함으로써 사용성을 높일 수 있었습니다.그리고 여기에 사용성을 더하기 위해 추가된 것이 이어보기 기능입니다. 짧아도 100화 이상, 길게는 1000화가 넘는 연재물에서 다음 화로의 매끄러운 연결은 매우 중요합니다. 혹은 잠시 읽기를 중단했다가 다시 돌아왔을 때, 어디까지 보고 있었는지를 빠르게 알려준다면 호흡을 이어서 작품에 더욱 몰입할 수 있을 것입니다.이어보기가 구현된 모습리디북스에 로그인되어 있다면, 이곳에서 확인하실 수 있습니다.이번 글은 이어보기 기능에 대한 개발 후기입니다. 요구 사항에 따라 여러 저장소 솔루션을 비교해 보았으며 최종적으로 Couchbase를 선택한 이유와 간단한 벤치마크 결과, 그리고 겪었던 문제를 공유합니다.요구 사항기획된 내용을 요약하니 아래와 같습니다.연재물의 가장 마지막에 읽은 화를 알 수 있다.보았던 모든 연재물에서 가장 마지막에 읽은 연재물을 알 수 있다.사용자가 본 모든 연재물 목록을 확인할 수 있다.이를 개발자 용어로 다시 풀어보면 아래와 같습니다.연재물을 읽을 때마다 연재물 ID와 화(episode) 정보를 기록한다.보았던 연재물을 최신순으로 정렬하여 가져온다.선택된 연재물의 마지막으로 읽은 화를 가져온다.목록에서 특정 연재물을 삭제한다.이어보기는 가장 마지막에 읽은 연재물을 기억하기 위해 작품을 열 때마다 해당 정보를 기록해야 합니다. 그런데 수십 화를 연달아서 보는 연재물의 특성상 내가 어디까지 읽었는지를 조회하는 것(read)보다 내가 읽은 연재물을 기록하는 것(write)이 더 많을 것으로 판단했습니다. 즉, 읽기보다 쓰기가 더 많을 것으로 예상했습니다.NoSQL을 쓰자대부분의 연산이 쓰기(write)와 관련된 이상, 어떤 저장공간을 사용할 것인지가 주된 관심사였습니다.특히 RDBMS와 NoSQL 사이에서 어떤 것을 사용할지 많은 고민과 테스트를 했고, 결국 아래와 같은 이유로 NoSQL을 사용하는 것이 적합하다고 판단했습니다.현재 사용 중인 MariaDB를 그대로 사용한다면 마스터에 부담을 줄 수 있다.별도로 MariaDB를 구성하더라도 운영 및 쓰기 분산하기가 여전히 어렵다.반면 NoSQL은 RDBMS 대비 확장(Scale out)이 간편하므로 운영에 대한 부담이 적다.단순 Key-Value 보관 용도면 충분하다.이어보기 데이터는 독립적인 성격을 가지고 있어서 다른 사용자 데이터와 JOIN을 할 필요가 없다.이어보기 데이터는 크리티컬한 트랜잭션이 필요하지 않다.MongoDB vs. Couchbase데이터를 영속적으로 유지해야 한다는 요구 사항을 충족하기 위해, Redis 등의 메모리만 사용하는 NoSQL은 제외했습니다. 물론 디스크에 기록할 수 있지만, 성능이 급감하기 때문에 실용적이지 못 합니다. 또한, 메모리 사이즈에 기반을 두기 때문에 Scale up 비용이 크고, 서비스 확장시 Scale out 빈도가 높습니다.그래서 MongoDB와 Couchbase를 비교 대상으로 했습니다. 둘 다 도큐먼트 기반의 NoSQL이고 확장이 용이합니다. 과거에는 MongoDB가 Write lock 사용에 있어서 문제점이 있었지만, 최근 버전에서는 문제가 되지 않습니다.[1] 둘 다 기업용 서비스 및 충분한 부가 기능들을 제공하므로 선택하기 어려웠지만, 최종적으로 아래와 같은 이유로 Couchbase(CE)를 선택했습니다.1. 이미 사내에서 다른 서비스에 사용되고 있습니다.가장 중요한 요인이었습니다. 더 좋은 솔루션이 있더라도 어디까지나 서버 스택을 늘리는 것 이상의 효용이 있는지를 따져보아야 합니다. 이미 사용하고 있는 솔루션이 있다면, 검증이 되었을 뿐만 아니라 개발 및 운영 경험도 활용할 수 있습니다.2. 이어보기는 복잡한 쿼리(Query)가 필요 없습니다.이어보기에서 사용할 쿼리는 간단하기 때문에 Couchbase의 뷰(View)만으로 충분했습니다.Couchbase, 실제 성능은 어떨까?테스트를 하기 전 우리가 어떤 식으로 사용할 것인지 정리해야 합니다. 애플리케이션 액세스 패턴이나 동시성 문제, 데이터 구조화 등을 파악하고 그에 맞는 테스트를 진행해야 합니다. 이번 이어보기는 쓰기 연산이 보다 많기 때문에 이로 인한 뷰의 인덱싱(Indexing)에 초점을 맞추고 테스트를 진행했습니다.성능을 위협하는 요소들View IndexingCouchbase는 MapReduce를 이용하여 뷰를 제공합니다. MapReduce는 일반적으로 리소스를 많이 소모하는 동작입니다. 그래서 Couchbase는 버킷의 새로 갱신된 데이터만 인덱싱하는 Incremental MapReduce라는 기법을 적용해서 리소스 소모를 줄였다고 합니다.[2] 하지만 해당 작업으로 인한 부하는 여전히 발생합니다.Auto CompactionCouchbase는 데이터와 인덱스를 디스크에 데이터를 저장할 때 파일에 추가하기(Append) 모드로만 쓰기를 수행합니다.[3] 그리고 오래되고 불필요한 데이터들은 추후 한꺼번에 정리하는데, 이는 디스크 쓰기 성능을 최대화하기 위함입니다.그런데 이렇게 추가만 하게 되면 오래된 정보들은 파일의 앞에 쌓이게 됩니다. 그리고 사용하지 않게 된 데이터도 남아있습니다. 이를 주기적으로 정리해서 최적화하는 작업을 Auto Compaction이라고 합니다. 뷰의 인덱스는 디스크에 존재하기 때문에 디스크 작업이 있으면 인덱싱에 영향을 미치게 됩니다.성능 테스트Couchbase는 기본적으로 5,000ms마다 Index를 업데이트합니다.[2] 그리고 데이터를 비동기적으로 응답합니다. 비동기는 응답속도를 빠르게 하지만, 데이터 불일치가 발생할 수 있습니다. 데이터 불일치가 신경 쓰이고 이 시간이 길다고 생각되면, stale 옵션을 지정해서 뷰의 인덱스를 업데이트할 수 있습니다.이어보기는 뷰가 간단하기 때문에 응답시간에 큰 문제가 없을 것으로 예상하고 stale 옵션을 꺼두었습니다. 이 옵션은 뷰를 조회했을 때 버킷의 변경사항에 따라 뷰를 인덱싱하고 데이터를 응답합니다. 하지만 예상한 것과 같이 실제로도 응답시간이 짧은지 확인할 필요가 있습니다. 그래서 다음과 같이 테스트를 진행했습니다.테스트 환경은 아래와 같이 2-tier로 준비하고 요청을 늘려가면서 RPS를 측정했습니다.서버 구성OS: Ubuntu 14.04Application: Couchbase Server (CE) 3.1.3클라이언트 구성클라이언트 1개에서 50개의 세션으로 요청10만 사용자 가정책은 1만개의 책중 랜덤으로 선택됨요청의 70%는 책 읽기(Bucket Write)요청의 30%는 연재물의 마지막에 읽은 책 가져오기(View Read)그래프 분석성능 테스트 주요 지표RPS : Response Per SecondSP : Saturation PointBuckle zone : 시스템 과부하로 인해 내부 자원이 서로 경쟁상태나 적체 상태가 심해지기 때문에 최대 처리량보다 더 떨어지는 경우가 발생함성능테스트 결과그래프를 보면 요청이 늘어남에 따라 RPS가 선형으로 증가하지만, SP인 8,000 RPS에 도달하고 나서 Buckle zone에서 7,000 RPS로 수렴하고 있습니다. 물론 1개의 클라이언트에서 세션을 생성해서 테스트를 진행했기 때문에 서버의 성능 부족이 아닌 클라이언트의 병목 현상이 원인일 수 있습니다. 또한 JMeter나 다른 부하 테스트 툴을 사용하지 않고 간략하게 만든 테스트 툴을 사용하였기 때문에 수치가 부정확할 수 있습니다. 그러나 어디에서 병목이 있었든 현재 이 이상의 성능이 필요하지 않기 때문에 테스트 결과에 만족할 수 있었습니다.이어보기 배포 후모바일 브라우저 캐시 문제이어보기 기능을 배포하자마자 당일 저녁 이슈 하나를 접수했습니다. 아이패드와 PC를 번갈아 이용할 경우 이어보기 데이터가 맞지 않다는 것이었습니다.데이터를 쌓을 때 모든 이력을 기록하지는 않았지만, 다행히도 Couchbase에 이용기기와 시간은 기록하였기 때문에 이를 바탕으로 디버깅을 할 수 있었습니다. (서비스 초기라 할지라도 최대한 많은 이력을 남기는 것이 중요함을 다시 느꼈습니다)원인은 아이패드의 멀티태스킹으로 인한 캐시 소멸이었습니다. 아이패드 브라우저의 캐시가 소멸되면서 마지막으로 열어두었던 페이지가 강제적으로 리로딩되었고, 이때 의도치 않게 마지막 위치 정보가 덮어씌워진 것입니다.이 문제는 기술적으로 해결이 쉽지 않아 결국 기획을 수정하게 되었습니다. 사용자가 해당 책을 읽었다고 판단하는 기준이 “페이지를 열어본 즉시”였다면, 이를 “페이지를 열고 수 초 이상을 유지”하는 것으로 기준을 변경하였습니다. 물론 근본적인 해결책은 아니었지만, 실제 사용에는 지장이 없는 합리적인 해결책이라고 생각합니다.Key 구조의 변경 및 동시성 문제Couchbase는 높은 성능을 위해 메타데이터(Key + @)를 모두 메모리에 적재하는 특징이 있어서, Document 하나가 평균 350Byte를 차지하고 있었습니다. 따라서 현재 상태로 1000만개의 데이터를 저장할 경우 최소 3.5G의 메모리를, 2개의 사본(Replica)를 유지할 경우 약 10.5G의 메모리를 사용하게 될 것으로 예상되었고 이는 큰 부담으로 다가왔습니다.처음에는 단순히 “사용자ID_연재물ID” 형태의 Key를 사용하였지만, 보다 빠르게 증가할 것으로 예상되는 것은 사용자보다 연재물 이었으므로 아래와 같이 Key값을 변경하여 메모리 사용량을 크게 줄였습니다.// U_id : S_id 조합을 사용하면 Key가 엄청 많아진다. // 그래서 사용자당 Key를 100개로 제한하도록 한다. Count = 100 Key = '사용자ID' + ('연재물ID' % Count) 그런데 이렇게 Key 구조를 변경하였더니, 간단한 업데이트 동작임에도 불구하고 정상적으로 수행되지 않는 경우가 빈번하게 발생하였습니다. 이유는 낙관적 동시성(Optimistic concurrency) 모델의 특징 때문이었는데, Couchbase는 명시적인 잠금 이외에도 “Check and Set(CAS)”이라는 기능을 제공하고 있었습니다.공식 문서의 예제를 참고하여 아래와 같이 로직을 수정한 뒤로는 다행히도 동시성 문제가 아직까지 발생하지 않고 있습니다.boolean updateUsingCas(key, value) {  for (tryCount = 0; tryCount < MAX>    orgValue, cas = getValueAndCas(key)           // Update the original value.     // newValue = ... if setValueWithCas(key, newValue, cas)      return SUCCESS sleep(0.1) // 부하를 줄이기 위해  }  return FAIL } 맺으며동작하는 서비스에 새로운 기능을 추가한다는 것은 어려운 일입니다. 특히 새로운 데이터 스토리지를 필요로 하는 일이라면 더더욱 어렵다고 생각합니다. 그리고 그럴 때일수록 설계에 많은 시간을 들여야 한다는 것을 느꼈습니다. 설계 초기에는 RDBMS의 샤딩까지 고려하였지만, 요구 사항을 구체화할수록 단순 Key-Value로도 같은 문제를 해결할 수 있음을 깨달았기 때문입니다.또한, 서비스 개발에 있어서 어려운 문제를 마주했을 때 기술적으로만 접근할 것이 아니라 고객이 정말 원하는 것이 무엇인지를 고민하여 기획적으로 해결하는 능력도 중요하다는 것을 실감하였습니다.마지막으로 Couchbase는 현재로서도 꽤 좋고 앞으로도 많은 발전이 기대되는 NoSQL입니다. 도입을 고민하시던 분들께 조금이라도 도움이 되었기를 바랍니다.참고자료[1] MongoDB - Concurrency[2] Couchbase - Views Operations[3] Couchbase - File write#리디북스 #개발 #개발자 #서버개발 #서비스개발 #고객중심 #기능개발 #Couchbase #인사이트 #개발후기

삼분의일 매트리스 제품 개발 초기부터 품질만큼 신경 썼던 것은 바로 냄새였다. 유명한 템퍼도 냄새 때문에 고객들과의 잡음이 끊이지 않았기 때문이다. (참조 : http://news1.kr/articles/?2737094)삼분의일은 업계 최초로 폴리우레탄 냄새를 잡을 수 있는 설비와 공정을 추가했다. 이거 때문에 정식 출시가 2달이나 늦춰졌다. '아직' 유명 브랜드도 아니고, 이제 '막' 시작한 삼분의일 입장에서는 엄청난 투자를 했다.(삼분의일 공정 소개 : https://www.youtube.com/watch?v=8deepSEXGqo&feature=youtu.be ) 모두들 미쳤다고 했지만, 결과적으로 경쟁사들에 비해서 냄새 관련 컴플레인을 90% 넘게 줄일 수 있었다. 그런데 날씨가 굉장히 추워진 2018년 12월 어느 날부터 냄새 관련 컴플레인이 급속도로 증가하기 시작했다. 너무 갑작스러워서 삼분의일 CS팀은 멘붕에 빠졌다. 하지만 우리가 할 수 있는 일은 해결책을 찾아 제공해드리는 것이었다. 문제가 발생한 고객님들의 제품은 우선 빠르게 회사 비용을 들여서 회수했다. 그리고 나는 매일 공장으로 출근해서 왜 같은 공정을 거쳤는데 냄새가 나는지, 원인을 파악하는데 총력을 기울였다. 1주일이 지나서야 원인을 찾을 수 있었다. 범인은 추위였다. 갑자기 한파가 닥치면서 작업장 내부 온도가 영하 밑으로 내려갔고 이로 인한 문제가 발생한 것이다. 방금 발포를 끝낸 폼의 내부 온도는 180도이고, 이를 둘러싸고 있는 외부 공기 온도가 영하게 가까울 때 문제가 발생한다. 추운 공기는 무겁고 밀도가 높다. 따듯한 공기는 가볍고 밀도가 낮기 때문이다.작업장 내부 온도가 영상이라면 공기의 밀도가 높지 않아서 내부에 쌓여있던 냄새 분자들이 스멀스멀 폼 외부로 빠져나온다. 그리고 어느 정도 빠져나온 이후에 전용 탈취기를 통해서 잔류 냄새를 말끔하게 제거할 수 있다.하지만 작업장 내부 온도가 영하라면 폼을 둘러싸고 있는 외부 공기 온도가 너무 낮고 밀도가 높아서 폼 내부에 있는 냄새 분자들이 외부로 빠져나오지 못하는 상황이 발생한다. 이 상태로 탈취기를 돌려도 예전만큼 탈취가 되지 않는다. 그리고 고객님의 집에 도착해서 외부 온도가 따듯해지면 그때부터 내부에 숨어 있던 냄새 분자들이 스멀스멀 나오기 시작하면서 고객님들의 컴플레인이 일어난 것이다. 이제 원인을 알았으니 재발 방지를 위한 프로세스를 구축해야 했다. 한파가 닥쳐도 작업장 내부 온도가 영하로 떨어지지 않도록 비닐 보온막을 꼼꼼하게 설치했다. 그리고 탈취기를 폼이 통과하는 속도를 2배 늦추고, 반복하는 횟수를 두배로 늘렸다. 문제는 해결했지만, 12월 물량이 크게 늘면서, 이미 출고된 제품들의 컴플레인은 한 달 동안 계속되었다. 접수된 불만 건은 한 건 한 건 사과드리고 가장 빠른 시일 내에 완벽한 제품으로 교환해 드렸다. 변명보다 모든 상황을 솔직하게 말씀드리고, 진심을 담은 사과와 해결책을 제안해 드리려고 노력했다. 대부분의 고객님들이 감사하게도 넓은 아량으로 삼분의일을 이해해주셨다. 삼분의일 매트리스가 출시되고 첫 번째 겨울에 우리는 소중한 경험을 했다. 이사일이 맞물려서 방바닥에서 며칠을 주무시면서도 더 좋은 제품을 만들어 달라고 응원해주신 고객님들이 자랑스럽게 우리 제품을 가장 소중한 사람들에게 추천할 수 있도록 앞으로도 제품 개선, 개발에 더 박차를 가하기로 했다. 결국 단순한 진리를 다시 마주하게 되었다. 최고의 제품을 만들고, 진심을 다해서 고객을 대하자. 이제 냄새 걱정하지 마세요.http://bit.ly/coldsmellby 삼분의일 대표전주훈#삼분의일 #매트리스 #문제해결 #인사이트

시작하기전에...오늘 내용은 디자이너님들을 위한 내용이 주를 이룹니당 :)그런 경험이 겁나 많았어요. 분명 쟤 시안이 딱히 더 이쁜 건 아닌데 이상하게 쟤 건 쓱쓱 컨펌나고 내 껀 원죄라도 짊어진 듯 반려만 오만번... 왜 쟤만 항상...?도대체 뭐가 문젠지 아무리 들여다봐도 시안은 아주 정상적이고 전혀 문제도 없단 말이죠. 정렬도 정확하고 색도 기가막혀. 내가 봐도 이건 천년에 한 번 나올까말까하는 역대급시안이야. 근데.........내 것만 맨날 싫대. 다시 해오래. 그 느낌 아니래. 뭔가 좀 부족하대. 쓰읍...다 괜찮은데 쪼금..그 뭔가 하아..그게 없대. 도대체 그게 뭐냐고오............오늘은 시안컨펌의 비밀을 한 번 까보려고 합니다. 일단 컨펌이 안나는 이윤 3가지가 있습니다.1. 내가 맘에 안들어2. 답정넌이야(내가 원하는 그 그림이 아냐. 물론 그 그림을 얘기해주진 않을거야.)3. 진짜 걔가 더 잘했어 네 그렇습니다.  사실 사회생활이란 게 익히 아시다시피 노력한만큼 정당한 결과가 늘 주어지진 않더라구요. 사실 한 번 눈밖에 나면 내가 국보급 시안을 가져가도 뭔가 색안경을 끼고 보기 마련입니다. 컨펌하는 분과 어느정도의 친근친근한 관계를 유지해놓는 것은 굉장히 유리한 일입니다. 딱히 시안이 예쁘진 않지만 맨날 팀장님과 술친구하던 저 녀석은 조금만 어찌저찌 에이 팀장님, 눈으로 찡긋, 오늘 치맥콜? 하더니 컨펌되버리고..나는 엊그제 팀장하고 옳은 UX에 대해 논쟁을 벌이다가 그 분의 심기를 건드려버린 탓에 벌써 7번째 반려당하고 있는 게 또 현실입니다... 정말 분비물같은 현실이죠...네 맞아요, 우리는 지금 디자인이라기보단... 정확히는 '일' 을 하고 있는 중입니다.아부 클라스가 아주 붓글씨로 적어 현판을 걸어야겠다.2번, 답정넌은 뭐 거의 모든 경우에서 찾아볼 수 있습니다. 대부분은 설명은 잘 못하겠고 할 수 있어도 말해주지 않지만 넌 내 생각을 알고있어야 하죠. 그리고 그 그림과 다르면 반려당합니다.  세번째 원인처럼 진짜 포인트를 잘못잡고있는 경우일 수도 있어요. 지금 우리 기획방향과 이 디자인의 목적성이 예쁨인지 아니면 가독성인지, 자극을 주는 용도인지 뭔지 다시 생각해봐야 할 경우예요. 실상 수많은 디자인업무에서 진짜 고퀄의 예쁜 디자인을 필요로 하는 경우는 그리 많지 않더라구요. 오히려 워딩이나 구성, 가독성이 주가 되어야 하는 경우가 훨씬 많죠. 그렇다면 최대한 컨펌나게 한 번 해봅시다.일단 선작업이 좀 필요해요. 모든 사람들은 뭔가 원하는 그림이 있기 마련입니다. 대부분 그걸 간파해주길 바라죠. 진짜 얼토당토않는 요구지만, 어쨋든 불평만 하고있을 수 없잖습니까. 일은 해야하니까요. 그러니 간파해보자구요.  1.     비슷한 컨셉의 시안은 금물. 보통 처음에 레퍼런스를 보여주면서 컨셉을 정할 때 승부를 띄워야해요. 그때 보통 3개 정도 컨셉레퍼런스 이미지를 가져가잖아요. 이 때 주의할 건, 완벽하게 다른 걸 가져가라는 거예요.(좌부터) 안드레이 몰리 보슈 코 作, 서울사회적기업협의회, Veerle Pieters-  글 없고 여백많은 심플한 컨셉의 시안(누가봐도 포토샵) -  공공입찰제안서와 같은 알차고 빼곡하며 클래식한 분위기의 시안(누가봐도 PPT) -  플랫아이콘과 컬러감이 살아있는 벡터 중심의 시안(누가봐도 AI)  예전에 이상형월드컵 기억나세요? 일단 그런식으로 압축시켜 나가야 해요. 완전히 다른 시안3개를 주면 고민의 폭이 굉장히 줄어들어요. 사람은 대부분 자기 생각에 대한 확신이 없어요. 그냥 확신이 있다고 생각만 하고 있을 뿐이죠. 정작 원하는 걸 구체적으로 물어보면 대부분 자세히 대답하지 못해요. 이를테면 이런 식이예요. 이상형 누구야? 하면 누구같은 사람 어떤 사람 얘기하잖아요. 나름 분명하다고 생각할 거예요. 그럼 이렇게 물어볼까요? 쌍꺼풀은? 코 높이는? 피부톤은? 울대는 나와있어야 해? 어깨가 좋아 등근육이 좋아? ...정작 이렇게 하나하나 물어보면 고민한다구요. 우리가 확실하다고 '생각'하는 것들은 대부분 착각입니다. 눈으로 보여야 그제서야 구체화되기 시작해요. 그래서 눈으로 보여주는 거예요. 구체적으로 까이기도 하고..'당신이 원하던 건 이런거였어!' 라고. 상대방이 생각을 압축할 수 있도록 차근차근 제시해주는거죠. 그래서 이 때 보여주는 시안들은 비슷해선 안되요. 완전히 하나를 선택할 수 있게 확실하게 다른 종류들이어야 합니다. 하나가 사진위주의 스큐모픽이라면 다른 하나는 완전 벡터이미지 가득한 플랫디자인 이미지인거죠. 2.     컬러, 정렬, 톤 순서로 압축시켜요!뭔가 디자인컨셉이 잡혔다면 이젠 컬러를 잡읍시다! 세상엔 오조오억개의 색이 존재해요. 그러니 무턱대고 어떤 색으로 할까요? 라는 질문은 '그건 니가 정해야지!' 라는 카운터어택으로 돌아옵니다. 그러니 객관식으로 정리해서 선공을 날리도록 합시다.색구성방식엔 HSB가 있는 걸 알고계실 거예요. HSB는 색도(Hue), 채도(Saturation), 명도(Brightness)로 나뉘어지잖아요. 상대방에게 컬러를 제안할 땐 B-H-S 순서로 제안해보도록 해요!- 밝게 가요? 어둡게 갈까요?(전체톤)- 빨주노초파남보 중에 어떤 컬러톤으로 갈까요?(메인컬러)- 색은 진하게가요 부들부들하게 가요?(메인컬러 채도)B복잡하게 갈 필요없이 ‘어두운 톤에 밝은 글씨로 갈까요? 밝은 배경에 어두운 글씨로 갈까요?’ 이것부터 확정지어 보아요. 회색배경은 거의 선택하지 않아요. 그러니 선택항에서도 아예 빼버리도록 합시다. 괜히 하나 더 물어봐야 혼란스럽기만 하거든요. H다음은 색도를 정해보아요. 빨주노초파남보 중 뭘 고르고 싶은지 물어보는 거예요. 놀랍게도 대부분의 사람들은 파란색이나 보라색계열을 많이 선택하더라구요. 물론 팬톤에선 올해의 색을 출시하고 실제로 컬러는 산업전반에 큰 영향을 미치기는 하지만, 우리 옷장엔 무채색 옷이 즐비한 것을 보면 인간의 색채선택은 꽤나 제한적이예요. 새로운 색에 대한 공포심은 디자인시안에도 그대로 적용되죠.  실제로 조선일보에서 진행한 색채 선호도조사에선 우리나라 355명의 성인 중 16.9%가 파랑을 가장 좋아하는 색으로 선택했다고 해요. 2위와 3위는 동률로 초록색과 보라색이 선택되었어요. 모두 푸른 계열의 색상이죠. 싫어하는 색은 18.6%로 주황색, 핑크(12.2%)와 빨강(11.9%)가 그 뒤를 이었답니다. 모두 붉은 계열의 색상이예요. 특히 우리나라 사람들의 옷장엔 대부분 검정, 남색, 흰색, 파랑, 회색 등의 옷이 가득한 것을 생각해보면, 어떤 색을 먼저 제안해야 할 지 대략 감이 올 듯 하죠?근데 이런 고민이 들어요. 이번컨셉은 도저히 파란색이 어울리지 않아. 무조건 부농부농으로 가야해!! 그런데 팀장님이 파란색덕후야 완전 스머프야. 어떻게 할까요? 네 맞아요. 일단 파란색으로 가요. 우리는 일을 하고 있어요. 일단 그 사람의 신뢰와 호감을 얻는게 먼저에요. 파란색으로 가면 본인도 이게 아니라는 걸 알거예요. 그러면 그 때 넌지시 제안해봐요. '그럼 혹시...부농색은 어떨까요? 이번 컨셉에도 꽤나 잘 어울리고.. 좀 색다를 것 같은데요..'라고. 팀장의 의견을 충분히 들어주었으니 이제 본인도 너그러운 사람이 되고싶어요. '어 그래, 그렇게 한 번 해보자.' 라고 말할 수 있어요. 뭔가를 요구할 때는 상대방이 자신의 체면을 구기지 않으면서 무언가를 제공할 명분이 있어야 해요. 하나를 주고 두번째 수를 생각하는 게 훨씬 좋아요.S 만약 윗사람의 취향이 놀랍게도 특이해서 민트색이 정해졌다고 해볼께요. 이젠 마지막으로 채도를 정할 차례예요. 파스텔톤의 부드러운 민트색도 있고, 화창한 하늘색과 같은 민트도 있고, 페리오치약색도 있고, 굉장히 불량해보이는 피스타치오 아이스크림 색과 같은 진한 민트색도 있어요. 민트색은 그 종류만 수백만가지가 될 수 있어요. 미묘한 차이까지 포함하면 거의 무한대에 가깝죠. 그러니 거두절미하고 우리가 먼저 제안하도록 해요. 채도를 10단계로 쪼개요. 어렵게 할 필요없어요. 진한색기준으로 투명도(opacity)를 10%씩 줄여요. 그렇게 10개 색을 만들어서 고르게 만들어요.물론 이렇게 해서 최종적으로 색을 골라도 어차피 나중에 또 바뀔거예요. 반쯤 포기하고 그냥 고르라고 하세요. 색이 정해진 후엔, 가운데/왼쪽/오른쪽 정렬 중 어느 쪽으로 레이아웃을 정리할 지 정해요이미 대략적인 레이아웃 포맷을 잡아가도 좋아요.마지막으로 폰트와 톤을 정리해요.전체적으로 둥글고 부드러운 톤으로 갈 것인지, 각지고 정렬된 느낌으로 갈 것인 것 등의 톤을 정리하면 두 번째 관문이 끝나요. 짱복잡해요. 하지만 글로 쓰니까 긴거예요. 실제로는 5분안에 끝날 수 있어요.   3.     순서를 정하고 이유를 달아줘요!시안을 보고하러 가는 눈빛이젠 시안이 완성된 다음 보고하러 갈 때의 노하우예요. 보통 하나만 덜렁 가져가진 않아요. 그건 아주 초보적인 거예요. 적어도 3개의 안을 들고가는게 맞아요. 보통 노련한 분들은 이쁜거 하나, 특이한 거 하나, 그지같은 거 하나를 들고가요. 하나는 버리는 카드고 내가 미는 시안을 1번으로 달아요.사실 시안이란 것은 대부분은 ‘느낌’에 의해서 만들어져요. ‘쌍꺼풀 있는 사람이 좋아.’라고 얘기하면서도 정작 내 연인은 무쌍인 경우를 생각해보면 쉽게 이해가 가죠. 원함과 실제는 굉장히 달라요. 원함은 굉장히 추상적이예요. 그리고 이유를 설명하기 어렵죠. 그러니 우리가 이유를 만들어줘요. 이유를 달아줄 땐 어려운 얘기 쓰지 말고, 이것을 선택하지 않으면 생기는 문제점들 위주로 말해줘요. 2번시안은 좋긴 한데, 가독성이 좀 떨어질 수 있고, 3번 시안은 사람에 따라 호불호가 있을 수 있다는 등등…맞아요 결국엔 ‘1번을 선택하세요.’ 란 얘기예요. 만약 그럼에도 상대방이 2번이 좋다고 할 수도 있어요. 사람의 마음은 순천만갈대보다 더욱 휘청거리니까요. 하지만 막무가내로 우기진 않을거예요.  ‘2번에서 글자를 크게 키워서 가독성을 높여주세요.’ 정도로 정리되겠죠. 왜냐구용?앞에서 우리가 그렇게 하나하나 꼬집꼬집 물어보면서 정리해놓은 히스토리가 있잖아요. 본인이 직접 정하고 골랐던 경험이 있으니 자신의 선택에 대해 번복하는 건 좀 부끄러운 일이예요. 그냥 적당히 합리화시키는 편이 더 빠르고 효율적이예요. 사람의 선택은 대부분 이렇게 이루어지죠. 물론 이와같은 각고의 노력에도 불구하고 그냥 다 맘에 안드니 다시 해!!! 라고 할 수도 있어요. 사람도 아니예요. 그래선 안되는거예요. 나쁜새럼...혼란하다 혼란해.....아니 그럴거면 왜 이런 고생을 해요? 라고 하겠지만, 저 과정은 그 자체로 두 가지 의미가 있어요.일단 여러분이 명쾌하고 깔끔한 커뮤니케이션을 하는 사람임을 어필할 수 있어요. '와, 쟤 진짜 뭔가 체계적이다...' 라는 이미지를 줄 수 있죠.그리고 명분을 획득할 수 있어요. '팀장님이 이거 좋다면서요!?' 라는 명분과 '지금까지 주구장창 당신의견을 들어줬으니 이제 내 의견도 들어워요!' 라고 말할 수 있는 명분말이예요. 그러니 앞으로 컨셉 레퍼런스를 정할 땐, 조금 더 몇장 준비해서 가져가도록 해봐요. 질문 몇 개가 더 추가되는 것만으로도 뭔가 쉽게 정리되는 느낌을 받을 수 있을거예요. (물론 그전에 다소 돈독한 관계가 쌓여있는 상태라면 더욱 좋을 것 같아요.. 혹시라도 찌릿찌릿한 웬수관계라면 이번 기회에 커피타임이라도 한 번 가져보도록 해요... 이것도 저것도 아니면 팔근육과 갑빠를 키워보아요...)스킬사용조건 : 최소한 상대방이 사람의 말을 이해할 수 있어야 한다. 시전자와 상대방의 관계가 좋을 경우 100%의 추가효과를 부여받는다. 그러나 상극일 경우 효과는 일정확률로 효과는 0가 된다.

Adobe XD(이하, XD)는 Sketch, Balsamiq 등의 프로토타이핑/와이어프레임 툴에 대항하기 위해, Comet이라는 프로젝트 이름으로 시작된 Adobe의 프로토타이핑 툴입니다.그동안 그래픽 디자인 툴에서 Adobe의 영향력은 절대적이었습니다. 하지만 UI 디자인에 특화된 툴들이 등장하기 시작하면서 Adobe의 입지는 좁아졌고, 이런 상황을 극복하기 위해 출시된 툴이 바로 XD입니다. 저는 페이퍼 UI 작업을 하면서 8개월 동안 XD를 사용해왔습니다. XD를 실무에서 사용하며 느낀 점과 어떤 기능을 사용해 UI 디자인을 진행했는지 이야기해 보려고 합니다.XD를 도입하게 된 배경현재 UI 디자인 영역에서 가장 높은 점유율을 보이는 툴은 스케치일 것입니다. 빠르고, 편리하며, 다양한 익스텐션으로 UI 디자인에 최적화된 모습을 보여주고 있습니다. 이렇게 많이 사용되고 있는 스케치에 비하면 출시 된 지 얼마 되지 않은 XD는 아직 부족한 점이 많습니다. 그런데도 불구하고 현재 XD를 이용해 페이퍼 UI 디자인하는 것에 대해 만족하고 있는데요, 그 이유는 다음과 같습니다.UI 디자인에 제약이 많은 PAPER리디북스에서 판매하고 있는 PAPER와 PAPER Lite(이하 페이퍼)는 2015년 10월에 출시한 리디북스 전용 전자책 단말기입니다. 일반적인 LCD와 달리 EPD(Electrophoretic Display)를 사용한 제품입니다.EPD 패널은흑백만 표현 가능하다는 점흑백도 (실질적으로) 16단계만 표현할 수 있다는 점반응 속도가 느리다는 점특징이 있습니다. 이러한 특징 때문에 일반적인 모바일 디바이스와는 다른 방향으로 UI를 디자인해야 합니다.빠르게 작업하고, 쉽게 공유할 수 있는 XD하지만, 그러한 제약 덕분에 XD를 사용해보는데 더 좋은 환경이 되었습니다. 디테일한 패스 제작이 불가능한 점이나 UI 요소에 필요한 스타일을 완전히 표현할 수 없다는 XD의 단점은 페이퍼 UI 디자인을 하는 데 큰 문제가 되지 않았습니다. 오히려 빠르게 프로토타입을 진행하고 바로 공유할 수 있는 점이 다양한 팀과 함께 진행해야만 하는 페이퍼 UI 디자인에 큰 장점으로 다가왔습니다.XD의 강점올해 초부터 지금까지 XD를 통해 페이퍼 UI 작업을 진행했고, 기능이 부족했음에도 계속 사용해온 이유는 크게 세 가지였습니다.1. 기존 Adobe 툴 사용자에게 익숙한 UIXD를 사용하기 시작하면서 처음 느낀 장점은 기존 Adobe 툴과 UI가 비슷해 적응하기 쉽다는 점이었습니다. 이는 새로운 툴임에도 불구하고 사용성의 진입 장벽을 낮춰주는 역할을 합니다. 스케치를 처음 시작했을 때 느꼈던 낯선 작업 환경과 적응하는데 걸렸던 시간을 생각한다면 오랫동안 써왔던 툴과 비슷한 경험을 제공하는 XD의 장점이 드러납니다. 스케치 또한 적응하면 능수능란하게 사용할 수 있겠지만 당장 입문자에게 편리한 쪽은 XD라 생각합니다.2. 빠른 플로우 제작 시간/과정다른 툴들과 다르게 XD는 디자인 화면과 프로토타입 화면을 유연하게 왔다 갔다 할 수 있습니다. ‘디자인’ 탭에서 각 화면 디자인을 끝낸 후 바로 ‘프로토타입’ 탭으로 전환해 플로우를 구성할 수 있습니다. 프로토타입을 제작하는 방법도 UI 요소와 각 화면 사이를 노드로 연결하는 방식이라 쉽고 빠르게 플로우를 검증할 수 있습니다. 일반적인 LCD 기반 기계와 달리 페이퍼는 디스플레이의 한계가 많아서 UI 테스트가 많이 필요합니다. 이럴 때, 유용합니다.3. 쉬운 공유 기능이렇게 만들어진 플로우를 다른 팀과 손쉽게 공유할 수 있다는 것도 큰 장점입니다. 프로토타입을 제작하고 버튼 몇 번만 눌러주면 Adobe 서버에 업로드되고 공유 링크가 만들어지는데 이 링크를 전달해 다른 팀의 의견을 받을 수 있습니다.XD를 이용해 페이퍼 UI 디자인해보기그럼, 실무에서 어떻게 XD를 사용하고 있는지 간단히 소개해보려고 합니다. 보여드릴 예시는 암호를 입력해 구매목록에 접근하는 기능입니다.디자인 : 기본 UI 디자인벡터/텍스트 툴을 이용 기본 UI 디자인기본 UI 요소들은 XD에서 충분히 표현할 수 있으므로 버튼, 토글스위치, 프로그레스 바, 텍스트 등의 UI 요소는 XD에서 바로 작업합니다. EPD의 특성상 컬러를 다양하게 사용할 수 없으므로 검은색(#000000), 회색(#333333, #666666, #999999), 흰색(#FFFFFF)만 컬러 셋에 등록해두고 사용합니다. XD에서 작업하기 힘든 복잡한 모양의 아이콘은 일러스트레이터에서 작업한 후 패스를 복사해 붙여넣기 합니다.디자인 : 반복 그리드XD에서 호평을 받는 그리드 기능을 이용해 책 목록을 만들어 보겠습니다. 리디북스 서점이나 뷰어에서 가장 많이 보이는 레이아웃이 ‘책 목록’인데 이러한 그리드 구조를 XD에서는 손쉽게 만들 수 있습니다. 책 커버 이미지, 제목, 저자 등 개별 항목을 선택한 후 ‘반복 그리드’를 적용해줍니다. 그리고 그리드 전체 크기와 각 항목 사이의 간격을 드래그로 조절해주면 책 목록을 쉽게 만들어낼 수 있습니다. 스케치에서는 Craft 같은 플러그인을 이용해야 하는 기능이지만 XD에서는 별도의 플러그인 없이 구현할 수 있습니다.디자인 : 프로토타이핑각 화면이 완성되었다면 프로토타이핑을 진행합니다. 이번 예시에서는 ‘내 서재에서 구매목록 탭’ → ‘암호 확인’ → ‘구매목록’으로 이동하는 프로세스를 구현합니다. XD의 프로토타입 탭으로 이동한 후 ‘구매목록’ 텍스트를 선택하고 노드를 ‘암호 입력’ 페이지로 연결해줍니다. ‘암호 입력’ 페이지에서는 아트보드 전체를 ‘구매목록’ 아트보드로 연결합니다.온라인 공유프로토타입 확인을 위한 공유 링크 만들기프로토타입을 완료했다면 오른쪽 위의 ‘미리 보기’ 버튼을 눌러 이상이 없는지 확인해보고, 타 팀에 공유할 링크를 만듭니다. 오른쪽 위의 ‘온라인 공유’를 클릭하면 제목, 섬네일 이미지를 지정할 수 있고 링크 업데이트나 새 링크를 눌러 웹에서 확인할 수 있는 링크를 복사할 수 있습니다. 이제 이 링크를 타 팀에 전달하고 피드백을 받으면 디자인 과정이 완료됩니다.XD에 바라는 기능제가 담당하고 있는 페이퍼 UI 디자인을 할 때는 XD의 불편함이 그리 크지 않습니다. 페이퍼 UI 특성상 세밀한 디자인이 필요하다기보다 전체 흐름을 점검하며 사용자 경험의 단계를 줄이는 것이 더 유용한 경우가 많기 때문입니다. 하지만 이러한 상황에서도 XD에 아쉬운 점이 있는데 몇 가지 부족한 점을 꼽아보겠습니다.1. Photoshop/Illustrator 파일 호환Adobe에서 출시한 툴답게 단축키와 인터페이스가 포토샵/일러스트레이터를 많이 닮아있습니다. 하지만 파일 호환성은 만족스럽지 않은데요, 일러스트레이터 파일이나 포토샵 파일을 불러오는 것이 불가능합니다. 가져올 수 있는 파일은 SVG와 JPG, PNG 등의 비트맵 이미지뿐입니다. 저는 따로 파일을 가져오지 않고 일러스트레이터에서 패스를 복사 → XD에 붙여넣는 방식으로 작업하고 있습니다. 포토샵 파일은 어렵더라도 일러스트레이터 파일은 손쉽게 들고 올 수 있으면 좋겠습니다.2. 가이드 추출 및 공유스케치는 Zeplin, Sketch-measure 같은 훌륭한 가이드 익스텐션이 존재합니다. 각 오브젝트의 위치와 크기, 코멘트를 공유할 수 있는 툴인데요, 아쉽게도 XD에서는 가이드를 생성하고, 전달하기가 마땅치 않습니다. 별도로 이미지를 제작하거나 문서로 전달해야 한다는 게 아쉽네요.3. 레이어XD에는 레이어 패널이 없습니다. 일러스트레이터처럼 ‘앞으로 가져오기/뒤로 보내기’ 등의 높낮이 개념은 존재하지만, 포토샵에서 볼 수 있는 레이어 패널은 없습니다. 그래서 오브젝트를 레이어 별로 정리하거나 조절할 방법이 없는데요, 차후 지원되면 좋겠습니다.4. 심볼스케치에는 UI 요소나 반복적으로 사용할 요소를 만들어두고 재사용할 수 있는 심볼 기능이 있습니다. 포토샵의 스마트 오브젝트와 비슷한 개념인데요, 대표 심볼을 수정하면 모든 심볼에 반영이 되어 편리하게 사용할 수 있다는 점이 좋은데, 아직 XD에는 이런 심볼 기능이 없습니다. 그래서 거의 비슷한 요소들을 복사 → 붙여넣기 해야 한다는 단점이 있습니다. 반드시 추가되면 좋겠습니다.5. 컬러 관리마지막으로 컬러를 관리할 수 있는 기능이 없습니다. 포토샵에서는 Swatch를 통해 컬러 세트를 관리할 수 있는데 XD에서는 자주 사용하는 컬러를 등록할 수는 있어도 별도의 파일로 추출 → 공유하는 것이 불가능합니다. 특히, 리디북스에서는 RSG(Ridibooks Style Guide)를 통해 컬러를 일관되게 사용하고 있는데요, XD에서는 이러한 컬러 세트를 사용할 수 없어 아쉽습니다. 미리 컬러를 등록해둔 XD 파일을 이용해 작업을 시작하고 있지만 좀 더 세심한 컬러 관리 기능이 도입되면 좋겠습니다.다음 업데이트가 기대되는 툴그동안 디자이너에게 포토샵과 일러스트레이터의 위상은 높았습니다. 하지만, 어느 순간부터 UI 디자인의 무대가 웹에서 모바일로 이동하고, 모바일 UI 디자인이 필요로 하는 다양한 기능들을 가지고 있는 툴에게 자리를 내주게 되었습니다. 하지만, Adobe도 가만있지 않고 기존의 툴에서 부족한 점이 무엇인지 정확히 파악하고, 그 부분을 쉽게 사용할 수 있는 XD를 출시하게 된 것이죠.디자이너의 입장에서는 아직 아쉬움이 많지만 간단하게 만들 수 있는 그리드, 빠르게 진행할 수 있는 프로토타이핑, 그리고 만든 프로토타입을 쉽게 공유할 수 있는 기능 등 XD만의 특별한 부분도 많아 계속 XD를 통해 작업해볼 생각입니다. 또, 정식 버전으로 출시된 후 한, 두 달에 한 번씩 업데이트되고 있는데요, 업데이트 내용을 보면 XD가 어떠한 방향으로 나아가야 할지 Adobe가 잘 알고 있음을 느낄 수 있었습니다. 앞으로도 발전할 XD를 기다리며 글을 마칩니다.맥 사용자이고 Adobe에 회원 가입이 되어있다면 무료로 XD를 사용할 수 있습니다.http://www.adobe.com/kr/products/experience-design.html#리디북스 #디자인 #디자이너 #Adobe #XD #AdobeXD #꿀팁 #디자인꿀팁 #UI #페이퍼UI #반복그리드 #프로토타이핑 #공유기능

Confidence crisis. 전세계 P2P 금융 핀테크 시장의 선두 주자인 렌딩클럽의 창업자이자 대표이사인 르노 라플랑셰(Renaud Laplanche) 의 부정행위가 적발되어 지난 5월 본인이 만든 회사에서 불명예스럽게 퇴출당했다. 샌프란시스코에서 개최되었던 렌딧 컨퍼런스2016 (Lendit Conference 2016) 에서 첫 키노트 스피커를 맡으며 P2P 금융 모델의 우수성을 공유, 축하했던 그에게 한달 후에 벌어진 일이다. 시장은 민감하게 반응했고 온갖 추측과 루머들이 난무하며 렌딩클럽의 주가는 폭락했다. 한때 $9B 을 넘던 회사가 1/6 토막이 나버렸다. 선두 주자의 부정행위는 투자 시장 전체에 confidence crisis 를 불러왔다. 2014년 12월 성공적으로 나스닥에 상장한 렌딩클럽. 출처: Forbes일각에서는 렌딩클럽이 "부정 대출"을 발생시켰고 이 사건이 P2P 금융 모델 자체의 불안정성을 의미한다는 추측까지 돌고 있다. 하지만 실상은 상당히 다르다. 렌딩클럽을 비롯한 대부분의 P2P 금융 회사가 자산으로 보유하고 있는 대출채권을 기관 투자자에게 판매하여 자금을 유동화하는게 일반적인데, 이때 기관 투자자는 자신들의 요구 조건을 명시하게 된다. 예를 들면 DTI (Debt to Income : 총부채상환비율) 35% 이하, FICO score 720 이상이어야한다는 필수 조건.. 그런데 렌딩클럽이 올해 1분기 동안 발생된 채권의 0.6% 를 한 기관 투자자에게 매각하는 과정에서 이 요구 조건에 맞지 않는 대출 채권까지 포함시켰고 대표이사가 이 문제를 조기에 발견했음에도 불구하고 묵인했다는 것이 감사에서 밝혀진 것이다. 즉 대출 지급 과정에 문제가 있었던 것이 아니라 "자산 매각 부정"이라고 봐야한다. 자세한 이유가 무엇이든 간에 Laplanche 는 부정행위를 묵인했고 이는 충분히 해고 사유가 된다. 오히려 발빠르게 과감한 결정을 내린 렌딩클럽 이사회의 판단과 실행력에 박수를 보낸다. 르노 라플랑셰 렌딩클럽 창업자. 출처: Bloomberg존경하는 금융계 멘토가 본인의 오랜 멘토로부터 2008년에 들은 이야기를 하나 해주셨다.세계적인 투자은행 베어스턴스에도 골드만삭스만큼이나 똑똑하고 훌륭한 인재들이 모여있었다. 서브프라임 모기지 사태로 베어스턴스만 역사 속으로 사라진 이유는 어떤 문제가 발견되었을 때 상사 눈치 보지 않고 손들고 반론을 던질 수 있는 회사 문화가 베어스턴스에는 존재하지 않았기 때문이다.렌딩클럽 사건 역시 분명히 내부 직원들 여럿이 알고 있었을 것이다. 손들고 문제를 지적할 만큼 용기있는 문화가 없었던 것이 이번 사건의 본질적인 원인이다.100-1=0, 렌딧 (LENDIT) 사무실 벽 곳곳에 붙어있는 메시지. 백가지를 잘해도 한가지를 잘못하는 순간 신뢰는 바닥으로 떨어지고 이를 회복하려면 많은 노력과 시간이 필요하다. 너무 강한 압박으로 느껴질 수 있지만 신뢰로 먹고 사는 우리에게는 가장 중요한 메시지다. 단순히 실수를 용납하지 않는다는 의미가 아니다. 실수를 받아들이고 대응하는 우리의 윤리강령과 문화를 포함하고 있다.