당신의 기획안을 통과시키는 마법의 단어, 클라우드안녕, 여러분! 다들 다망하신 와중에 이렇게 지면으로 찾아뵙게 되어 굉장히 반갑습니다. 저는 spoqa의 노예 xym입니다. 어느덧 벌써 연말이네요. 온갖 골든 위크로 시작했던 4/4분기, 이제 한창 주말 외에는 법정공휴일이 없는 데스마치를 진행중이시리라 생각되는데요, 안 그래도 다들 크리스마스만 바라보고 미친듯이 달리고 계시죠?네, 그래서 제가 이렇게 잠시 여러분 머리를 식혀드리기 위해 한 번 재밌는 이야기를 하고자 찾아뵙게 되었습니다. 개발자가 아닌 분들에게도 별로 어렵지 않게 쓰고자 노력했으니 한번쯤 “오 이런 신기한 게 있구나”하고 읽어보시고 머리 좀 식히고 가세요.업계 분들이나, 이쪽 업계에 소식이 빠삭한 분들은 아시겠지만 몇년 전부터 이 바닥은 새롭게 몰아치는 파도를 맞고 있습니다. 2, 3년 전부터 올해 중순까지 업계 뜨거운 감자였던 키워드들에 대해서 기억하고 계신가요? 네, 그 소위 HTML5니 클라우드, 빅데이터, 소셜 게임 따위의, 기획안에 쓰면 사장님 입이 귀에 걸리게 만드는 마법의 단어들이요.이 글도 사실 그 마법의 단어들에 관련된 이야기입니다. 정확히는 클라우드 기술에 관련된 이야기예요.뜬구름 잡는 클라우드대관절 클라우드란 무엇이길래 여러분의 기획안을 통과시키게 하는가 궁금하지 않으셨나요? 알고 계신 분들도 많을 테니 간략하게 설명하고 넘어가겠습니다. 클라우드는 클라우드 컴퓨팅 기술의 약자입니다. 위키피디아에 있는 정의는 다음과 같습니다:인터넷 따위의 네트워크를 통해 실시간으로 많은 컴퓨터들을 관리하는 여러 컴퓨팅 기술과 관련된 개념들을 총칭얼핏 들으면 굉장히 뜬구름 잡는 소리입니다. 아니, 그럼 그 전까지는 그런 걸 안 했다는 건가? 물론 아닙니다. 클라우드 컴퓨팅이란 단어가 버즈워드로써 시장을 강타하기 전에도 소위 클라우드 컴퓨팅을 위한 기술들은 존재했습니다.엄밀히 말하면 클라우드 컴퓨팅은 ‘기술 융합’의 일종이라고 볼 수 있습니다. 기존에 존재하던 개념들과 기술들을 융합하여 새로운 접근법을 탄생시킨 것이죠. 간단히 소개하자면 그 클라우드 컴퓨팅을 이루는 기반에는 다음과 같은 두 개의 거대한 축이 있습니다.가상화(Virtualization) : 하나의 컴퓨팅 자원을 여러 개로 나누어 마치 여러 개의 독립된 컴퓨터처럼 사용하는 기술 혹은 개념그리드 컴퓨팅(Grid computing) : 하나의 작업을 동시에 여러 개의 컴퓨터가 분할하여 처리하는 기술 혹은 개념거기에 중요한 개념 하나만 더 얹고 넘어가겠습니다. 이것도 한 때는 버즈워드로 사람들을 흥분시켰었죠.Application Programming Interface(API) : 복잡한 내부 동작에 대해서는 잘 몰라도 정해진 규약(인터페이스)만 알고 있으면 해당 기능을 사용할 수 있도록 한다는 개념그러니까 어떤 작업을 하기 위해 하나의 컴퓨터를 여러 개로 분리하고(자르고), 또다시 그 분리된 컴퓨터들을 합쳐서(합치는), 어쨌든 정해진 규약대로 사용할 수 있게 만드는 것(편한 거).아, 너무 기네요. 줄여서 “난 잘 모르겠지만 뭔가 좀 편한 거군.” 정도로 해두죠. 그게 클라우드의 궁극적인 목표이자 본질이라고 볼 수 있겠습니다. 그래서 이름도 뜬구름 잡는 소리 같다고 클라우드잖아요?그래도 마냥 뜬구름 잡는 소리만 할 수는 없으니 한번 클라우드 서비스의 종류를 알아봅시다.IaaS(Infrastructure as a Service) - 인프라스트럭쳐, 한마디로 서버를 조립하고 설치하는 방법을 몰라도 쓸 수 있도록 편하게 제공한다고 보면 됩니다. Amazon Web Service 같은 애들이죠.PaaS(Platform as a Service) - 이번엔 IaaS를 잘 몰라도 서비스를 돌릴 수 있게 만들어진 플랫폼을 제공합니다. Heroku가 대표적입니다.SaaS(Software as a Service) - 그렇게 만들어진 플랫폼 위에 돌아가는 서비스들을 제공합니다. icloud.com의 keynote 따위가 있겠군요.생각보다 어렵지 않죠?docker 란 무엇인가사설이 길었네요. 이제부터가 본론입니다. 제가 오늘 소개할 녀석은 클라우드 컴퓨팅에 있어 “자르는” 축을 담당하는 가상화의 떠오르는 아이돌, LXC를 사용한 docker 입니다. LXC가 무엇인지는 여기서 중요하지 않습니다#2. 그냥 업계의 떠오르는 아이돌 정도로 해 둡시다. 그러니까 아이유 같은 존재죠.docker가 등장한 배경을 설명하자면 이렇습니다. Heroku와 함께 PaaS계에서 끗발을 날렸던 dotCloud는 어느 날 갑자기 충격적인 발표를 합니다. 자기네들이 쓰는 가상화 및 애플리케이션 플랫폼을 공개해 ‘오픈 소스로’ 제공하겠다는 것이죠. 아니, 이럴 수가! 이러시면… 이러시면 정말 감사합니다#3!docker의 가장 큰 특징은 다음과 같이 요약할 수 있습니다.image 관리의 간편화와 container 관리 간편화어떤 서비스를 돌리기 위해서는 필요한 서버들이 있습니다. 데이터베이스 서버, 웹 서버, 캐시 서버, 워커 서버 따위의 것들이죠. 이 모든 걸 한 군데로 퉁쳐서 모을 수도 있겠지만 그렇게 되면 데이터베이스, 웹, 캐시, 비동기 업무를 위한 설정과 프로그램들을 한 군데로 모아 관리해야 합니다. 그렇게 되면 설정이 복잡해지거나 애플리케이션이 거대해지거나 필요할 때 횡적인 확장을 하기가 어려워집니다.예를 들어 웹서버에서는 A라는 라이브러리의 1버전을 필요로 하는데 데이터베이스 서버에서는 2버전을 필요로 한다던지, 이벤트 하느라 접속자가 너무 증가했는데 다른 웹서버가 한시간 정도만 필요한 일을 그럴 수 없어서 서버를 통째로 하나 사야 한다던지 하는 일들이죠. docker는 그런 상황에 유연하게 대응하기 위해 서버 설정과 필요한 프로그램들을 따로 관리할 수 있는 환경을 제공합니다.docker는 이렇게 분리된 환경을 image라고 부르며, 이 image를 기반으로 여러 개의 container를 생성할 수 있습니다. 음… 이렇게 이해하시면 편할 것 같습니다. image는 유전자 설계도고, container는 그 유전자 지도에서 만들어진 생물체라고나 할까?즉, 이 설계도를 관리하면 필요할 때 목적에 적합하게 만들어진 생물체를 얼마든지 만들어낼 수 있게 되죠. 필요할 때는 설계도의 설계를 바꿔서 새로운 생물체를 만들어낼 수도 있습니다. 단순하지만 docker의 가장 커다란 컨셉이고 강력하기까지 합니다. 이렇게 단순하고 간편한 환경은 여러 가지 시도를 가능하게 합니다.오토스케일링(웹서버가 필요할 때 웹서버를 막 찍어낸다던가!)유연한 배포 정책(서버를 최신 버전으로 업데이트했는데 버그가 있어서 재빨리 옛날 버전으로 돌아가야 한다던가!)자원의 효율적인 활용(이 쪽 서버가 놀고 있으니까 여긴 웹서버 두개 정도 더 띄운다던지)거기다 수고를 좀 더 들이면, docker의 API를 활용해 Heroku 부럽지 않은 웹 GUI PaaS 서비스를 만들 수 있을지도 모릅니다(만들어 주시면 감사히 쓰겠습니다).한번 docker를 살펴봅시다이야기는 실컷 했으니 한번 설치해보고 실행시켜봅시다. 지면 관계상 모든 플랫폼을 다룰 수는 없기에 우분투 13.10을 기준으로 살펴보도록 하겠습니다. 필요하신 분들은 공식 홈페이지 설치 메뉴얼을 참고하여 진행해주세요.주의 : 이후 내용은 비 개발자 분들에게는 다소 지루한 내용일 수도 있습니다.docker 설치curl http://get.docker.io | sudo sh 참 쉽죠?자 이제 시작이야이제 여러분의 플랫폼에는 docker가 설치됐습니다. 한번 서버에서 기본 이미지를 다운받아 설치해 봅시다.sudo docker pull base 인터넷 환경에 따라 좀 기다리셔야 하실지도 모릅니다. 이미지가 설치되면 아래 명령으로 확인할 수 있습니다.sudo docker images 아래와 비슷한 화면이 나타났다면 성공한 겁니다.REPOSITORY TAG IMAGE ID CREATED SIZE base latest b750fe79269d 8 months ago 24.65 kB (virtual 180.1 MB) base ubuntu-12.10 b750fe79269d 8 months ago 24.65 kB (virtual 180.1 MB) …(생략) 이렇게 내려받은 image에는 다음과 같은 명령어로 접근할 수 있습니다.sudo docker run -i -t base /bin/bash 자세한 명령어 사양은 docker help run을 실행해 알아볼 수 있습니다. 여러분은 이제 base라는 image에 접속했습니다. 지금부터 하는 행동은 image에 영향을 미치게 되며, 이는 전부 로그로 남아 저장됩니다. 한번 이것저것 설치해봅시다.sudo apt-get install python ruby … 이후에 Ctrl+D를 눌러 이미지를 빠져나옵니다. 그리고 아래 명령을 입력하면 방금 전에 수정한 container 목록이 출력됩니다.sudo docker ps -a 아래와 같은 식으로 출력됩니다.CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES eda0060b7af9 base:latest /bin/bash 6 minutes ago Exit 0 lavender_deer 66c849867834 busybox:latest echo Docker has been 8 minutes ago Exit 0 blue_cat 이제 image의 수정사항을 기반으로 새로운 이미지를 만들어 봅시다. 이미지를 만드려면 변경사항을 commit 해야 합니다. VCS나 DVCS를 쓰시는 분이라면 무슨 말인지 감이 오실 겁니다. 네, 바로 버전 관리 시스템의 그것입니다. 기존 base를 기반으로 변경사항을 만들고 commit하여 새로운 이미지를 생성할 수 있습니다. 매우 쉽군요. 한번 생성해봅시다.docker commit [ID] [image name] commit 명령의 구조는 단순합니다. container ID와 그리고 만들 이미지 이름입니다. 이미지 이름은 보통은 만든이/목적 같은 컨벤션으로 만들곤 합니다. 저는 아래와 같이 만들어보겠습니다.sudo docker commit eda0060b7af9 xymz/grocery 확인은 당연히 아래와 같이 할 수 있습니다.sudo docker images repository 에서 여러분이 만든 이미지 이름을 확인할 수 있다면 성공한 겁니다. 여러분의 첫 docker image 생성을 축하합니다!물론 이렇게 약간 거칠어보이는 방법과는 다르게 Dockerfile 이라고, 딱 봐도 버전관리 시스템에 넣을 수 있을 거 같고 정리가 잘 되는 방법도 존재합니다. 아마도 실제로 사용하실 땐 Dockerfile을 사용하게 되실 거고, 그 방법이 훨씬 낫습니다. 다만 본 포스트의 목적은 개발자나 비개발자 분들에게 docker를 한번 소개해보자는 취지라서 Dockerfile의 operation 을 일일히 설명하기엔 얘기가 너무 복잡해질 것 같아 직접 try-out 하기에 쉬운 commandline 쪽을 선택하게 되었습니다.당연히 이게 끝은 아닙니다여기까지 나온 내용으로 서비스를 구성하기에는 무리가 있습니다. 우리는 이제 막 docker image를 생성하고 저장하는 방법을 알았을 뿐이지 그 외에는 아무것도 모릅니다. docker를 제대로 사용하기 위해서는 아래와 같은 방법들을 추가적으로 알아야 합니다.생성된 이미지 관리 : 새로 만든 이미지를 어딘가에 업로드하여 다른 docker 시스템(host)에 배포하기 위한 방법에 대해 알아야 합니다.실제 서비스를 container 에 올리고 관리하는 방법 : 아까 언급한 것처럼 예시를 들자면, 현재 서버에서 웹서버를 를 몇개나 띄울 건지 등을 결정하고 관리하는 방법에 대해 알아야 힙니다.docker host와 guest간의 통신 관리 : docker가 설치된 실제 서버와 그 위에서 돌아가는 container들 간에 오가는 통신에 대한 이해가 필요합니다. 포트 바인딩, 포트포워딩이라고도 하죠.docker API : 이 모든 스택을 관리하기 위한 docker의 API를 알고 있다면 무한한 활용이 가능해집니다.하지만 이 방법들에 대해 여기서 다 열거하고 넘어가기에는 무리가 있으니 좋은 링크를 몇 개 소개토록 하겠습니다.파이썬 웹앱 올려보기docker를 개발환경으로 사용해보기Dockerfile 로 image 관리하기포트 리다이렉션적어놓고 보니 대부분 docker 공식 홈페이지 자료들이네요. 사실 docker는 documentation이 훌륭한 편이라, 그 쪽만 참고해도 많은 도움이 되실 겁니다.Deis?그리고 이 모든걸 쉽게 해주겠다는 Deis라는 녀석이 있습니다. Docker, Chef, Heroku Buildpacks를 이용해 하나의 PaaS스택을 만들고 그 위에 여러분의 서비스를 돌릴 수 있도록 해주겠다는 녀석인데요. 어쩌면 진정한 Open source PaaS 종결자일지도 모르겠습니다. 기회가 된다면 다음에 또 소개할 수 있었으면 좋겠네요.마치기 전에즐거우셨나요? 중간 이후 내용은 다소 비개발자분들에게 지루한 내용이었을지도 모르겠습니다만, 전반적으로 최대한 쉽게 설명하고자 노력했습니다. 다음 번에는 더욱 재밌는 글로 찾아볼 수 있도록 하겠습니다. 그럼 뿅!참고한 링크들docker.ioUsing Docker as a Development EnvironmentDocker: Error starting container: Unable to load the AUFS module주석사실 API는 거창한 기술적 개념이라기보단, 소소한 개발 방법론에 가까운 이야기입니다. 온갖 프로그래밍 언어와 다양한 기술들이 난립하는 와중에 그 모든 걸 알고 전부 뭉쳐서 하나의 덩어리를 만들면 관리/사용하는 비용이 너무 커지니 각 영역을 딱딱 잘라 구분하여 ‘정해진 규약’만 알면 서로 통할 수 있게 만들자. 라는 개념입니다.(약간의 지식이 있는 분들을 위해) LXC(LinuX Containers)는 기존 전가상화full virtualization나 반가상화paravirtualization와는 다르게 OS 위에 가상머신이 따로 돌아가는 게 아니라 OS영역에서 공유 라이브러리를 가지고 유저가 생성하는 프로세스 단위로 성능 분리를 합니다. 덕분에 이름에서 보이듯 특정 플랫폼밖에 지원을 하지 않는다는 단점이 있네요. 그래도 가상화에 따른 자원 손실이 최소화된다는 점에서 많이들 선호하고 있습니다. Heroku에서도 LXC를 통해 가상화를 하고 있죠.보통 이렇게 자신들의 플랫폼을 오픈소스로 공개하는 이유는 단순히 사회에 기여하기 위해서도 있지만, 사내에서 사용되는 기술의 수준을 오픈 소스 커뮤니티의 참여를 통해 향상시키고, 또 좋은 개발자들을 리크루팅 할 수 있게 되는 기회를 만드는 등 선순환을 유도하기 위해서입니다. 그러니까 여러분도 사내에서 사용하는 기술을 공개해 주시면 누이 좋고 매부 좋은 일이라 할 수 있죠.이 글은 __저의 개인 텀블러__에서도 찾아볼 수 있습니다.#스포카 #개발 #개발자 #개발팀 #인사이트 #Docker #클라우드 #꿀팁

뭐가 문제였나필자는 현재 HMR(가정간편식) 커머스를 다루는 모 스타트업에서 백엔드 개발자로 재직 중이다. 말이 백엔드지 최근 변화되고 있는 트렌드에 맞춰 열심히 API 작성 셔틀을 하고 있다.API 개발에 주로 사용하는 HTTP 상태 코드는 주로 200 (정상), 400 (잘못된 요청), 401 (보안 토큰 에러), 403 (권한 없음), 404 (찾을 수 없음) 정도가 있었다.문제는 여기에서 발생했는데, API를 계속 개발해 나가다 보니 API 요청 시 데이터가 없을 때 200 상태 코드에 빈 배열을 돌려주어야 하는지, 404 상태 코드를 돌려주어야 되는지 상황에 따라 다를 수 있겠다는 생각이 들었다.만약 '데이터가 없을 수도 있는 상황'과 '데이터가 없으면 안 되는 상황'에서 404 Not Found 에러 코드로 같게 응답할 경우 다음과 같은 애매한 상황이 펼쳐질 수 있다.API를 사용하는 클라이언트가 404 에러에 대한 대응을 에러로 표시할지 데이터 없음으로 표시할지 상황에 따라 다르게 정의해줘야 한다. 결과적으로 클라이언트에서 API 요청에 대한 처리가 복잡해진다.// front-endimport fetch from 'node-fetch'; function fetchUserList() {  // 유저 목록을 가져오는 API를 사용한다고 가정  return fetch('https://api.exmaple.com/users')    .then((response) => {      if (response.statusCode === 404) {        // 이 404 Http 상태 코드를 에러로 처리할 것인가? 데이터 없음으로 처리할 것인가?        // 에러일 경우 : throw new Error('Not Found');        // 데이터 없음일 경우 : return [];      } else if (response.statusCode === 200) {        return response.json();      } else {        throw new Error('Unexpected Http Status Code');      }    })    .then(result => render(successPage, result))    .catch(error => render(failurePage, error));}결국, 어떤 식으로 표시해야 명확하게 표현할 수 있을까 하여 페이스북 존잘 개발자님들에게 의견을 물었다. # 굉장히 많은 분이 의견을 주셨고 나름대로 생각을 정리할 수 있었다.결론적으로는 '데이터 없음'과 '404 Not Found'를 같은 용도로 사용하면 안 된다.그렇다면 뭘 어째야 하나위에서 나온 결론을 조금 더 자세히 풀어보면 다음 내용이다.상황에 따라 데이터가 없는 것이 정상인 상황이 있고, 데이터가 없는 것이 에러인 상황이 있다. 이를 구분 해야 한다.데이터가 없는 것이 정상일 수 있는 상황// server-sideAPI.get('/orders/date/:date', async (request, response) => {  // 특정 날짜의 주문을 검색. 특정 날짜에 주문이 없을 수도 있다.  const { date } = request.params;  const orders = await Repository.Order.findByDate(date);  // 200: OK  // 204: No Contents  response.statusCode(orders.length > 0 ? 200 : 204).json(orders);});데이터가 없는 것이 에러인 상황API.get('/orders/:orderId', async (request, response) => {  // 특정 ID의 주문을 검색. 데이터가 없으면 에러다.  const { orderId } = request.params;  const order = await Repository.Order.find(orderId);  if (order.length > 0) {    response.statusCode(200).json(order);  } else {    // 404: Not Found    response.statusCode(404).json({      message: `${orderId} is Not Found`    });  };});그렇다면 요청한 API 리소스가 없는 경우에는 어떤 에러를 보여줘야 하는가? 일반적으로는 404 Not Found 가 통상적으로 사용되지만 우리는 이미 404를 다른 용도로 사용하고 있다. 다행히도 HTTP 상태 코드에는 501 Not Implemented 이라는 좋은 친구가 있다. 이 친구를 사용할 수 있다.import { Users, Orders } from './Routes'; app.route('/users', Users);app.route('/orders' Orders);app.all('*', (request, response) => {  // 501: Not Implemented (구현되지 않음)  response.statusCode(501).json({    message: 'This Method is Not Implemented',  });})대충 이 정도면 클라이언트는 Http 상태 코드를 보고 다음 로직을 처리할 수 있을 것이다.물론 일반적으로 사용되는 상태 코드들이지만 실제 개발 진행 시에는 클라이언트를 개발하는 개발자와 미리 어떤 상황에서 어떤 상태 코드를 보낼 것인지 정해야 할 것이다.마무리API 개발 시 사용할 법 직한 응답 코드를 정리해보았다.200: OK (정상, 데이터 있음)204: No Contents (정상, 데이터 없음)301: Moved Permanently (리다이렉션)400: Bad Request (실패, 클라이언트에서 넘어온 파라미터가 이상함)401: Unauthorized (실패, 클라이언트에서 넘어온 보안 토큰이 이상함)403: Forbidden (실패, 사용자의 권한으로 리소스를 사용할 수 없음)404: Not Found (실패, 데이터가 있어야 하나 없음)410: Gone (실패, 데이터가 있었으나 삭제됨. 이건 굳이...?)500: Internal Server Error (실패, 서버 로직 문제)501: Not Implemented (실패, 없는 리소스 요청)기타 304나 502, 503 등의 상태 코드의 경우 API Application을 작성하는 개발자의 역할보다는 Server 쪽의 역할에 가깝다고 생각하여 작성하지 않음.뭔가 어렵다고 느껴진다면 다음 짤을 참고해서 쉽게 이해할 수 있다. #플레이팅 #개발 #개발자 #인사이트 #경험공유 #조언 #꿀팁 #HTTP #버그 #버그수정 #문제해결

출근이 즐거워지는바로고의 복지 문화13가지안녕하세요, 바로고 입니다.바로고 직원들의 출근이 즐거워지는13가지 이유바로복지 문화 13가지가 있기 때문이죠^^[바로고 복지문화]바로고 복지 문화에 대해자세히! 알고 싶다면 클릭!뼈가 되고, 살이 되는외부 인사 초청 강연훌륭한 팀워크와 업무 효율을 높이는유익한 외부 인사 초청 강연!맛있는 음식과 함께 해봐요^^2017년 9월 7일외부 인사 초청 강연강연자헬로네이처 허광남 CTO뼈가 되고 살이 되는강연의 주제는고객 행동 데이터 보면서 개발하기강연은바로고 본사에서 진행되었습니다.강연을 본격적으로 시작하기 전프로젝터로 점검하고간단한 담소를 주고받으며편안한 분위기를 만들어주시는 허광남님뼈가 되고 살이 되는 강연이그동안 바로고에서 진행된 만큼오늘의 강연 또한 기대됩니다!고객 행동 데이터 보면서 개발하기Elastic Stack오늘 강연은1. 데이터 시각화의 가치2. 오픈소스 시각화 패키지 Elastic Stack3. 유용한 플러그인 소개4. ELK 적용 사례위의 같은 순서로 알차게 진행되었습니다.시작부터 집중하는바로고의 직원들업무에 바쁘다 보면다른 정보를 습득하거나다른 분야의 사람들과 의견을 공유할 여유가 없을 수도 있어요.이렇게 외부 인사 초청 강연을 통해다양한 의견을 공유하고리프레쉬 하는 기회가 생기는 것에바로고 직원들의 만족도가 높은 편입니다.이번 강연의 핵심이었던Elastic Stack 의 특징에 대해간단히 설명해보겠습니다강연의 내용을 함께공유한다는 것에도 의미가 있어요^^Elastic Stack 특징-Google Analytics(GA)의 데이터로사이트 접속 통계를 구할 경우원하는 대로 데이터를 획득하기 어렵다.-자체 서버의 모든 로그를 100% 수집할 수 있기 때문에데이터에 대한 신뢰성이 높다.-파라미터 값별로 통계를 볼 수 있기 때문에정확한 데이터 분석이 가능하다.-검색엔진(lucene)이 포함되어 있어빠르게 데이터를 검색할 수 있다.-모두 오픈소스이며 자유롭게 사용이 가능하다.자유롭게 질문을 주고받으며의견을 공유할 수 있었던 의미 있는 시간이 되었습니다.이번 강연에서도다양한 의견을 주고받고같은 문제에 대해다양한 시각이 존재한다는 것을알게 된 계기가 된 것 같습니다.바로고 직원 모두에게의미있는 시간이 되었으리라 생각합니다.오늘 열정으로 강의해주신허광남님께 진심으로 감사의 말을 전합니다.또 다른 시각에서 접근하는고객에 대한 접근 방법뼈가 되고 살이 되는알찬 시간이 되었습니다.감사합니다!바로고의 외부 강연이 끝날 시간 즈음그 시간이 바로 점심시간열심히 강의 들었으니에너지 충전이 필요합니닷!모두 수고하셨습니다.선택이 아닌 필수#배달 #배달대행바로고날씨 좋은 9월, 야외에서 오늘은 쉬는 날, 집에서누구와 함께 든 어디에서든내가 원하는 곳으로 배달!-전국 배송망을 갖춘바로고에서라면가능합니다.배달대행[바로고 공식 홈페이지]

스캐터(Scatter)는 암호화폐 지갑 계정에 대한 신원인증을 대행해주는 일종의 신원인증 프로그램으로, 별도의 보팅포털에 접속해서 신원인증을 통해 로그인을 도와주는 크롬의 확장 프로그램입니다.스캐터를 사용하게 되면, 기존에 여러 지갑 및 사이트로 부터 EOS 프라이빗 키를 부여 받아야 했던 번거로움 없이, 한번만 등록해놓으면 다양한 사이트에서 스캐터 계정 하나로 자신의 EOS 계정을 증명할 수 있게 됩니다.이러한 스캐터를 사용하는 방법을 지금 부터 알아보겠습니다.Step 1. Scatter 설치 및 계정 생성Scatter에서 크롬 확장 프로그램을 다운로드하여 설치하셔야 합니다.설치 후 크롬 브라우저에 설치된 Scatter 아이콘을 누르시면 다음과 같은 화면이 나타납니다.새로운 비밀번호 (최소 8글자)를 입력하시면 됩니다.비밀번호 입력 후 Create New Scatter 버튼을 누르세요.그럼 아래와 같이 12단어가 표시된 화면이 나타납니다. 바로 단어들을 복사 혹은 화면 캡처를 하여 보관해야 합니다.( * 저장하지 않은 채 다른 창을 누르시게되면 해당 화면이 사라지게 되니 꼭 바로 저장하셔야 합니다.)이 단어들은 나중에 비밀번호를 잃어버렸을 때 필요합니다.다 복사를 하셨으면 [ I wrote it down]을 눌러주세요.그 다음 화면에서 백업을 하실 지, 그냥 넘기실 지 선택하셔야 합니다.선택하시면 다음화면으로 넘어가게 됩니다.이제 더 편리하게 사용할 수 있도록 한국어 설정으로 바꿔 볼 거에요!우측 상단의 톱니바퀴 모양을 누르신 후[Language]-한국어 선택 -[Change Language] 차근차근 클릭하여진행하시면 됩니다.짜잔! 이제 한국어 버전으로 사용할 수 있습니다.이제부터 Scatter를 통해 자신의 EOS 프라이빗 키를 등록하셔야 합니다.왼쪽 상단의 [ < ]뒤로가기 버튼을 누르시면 다음과 같은 화면이 나옵니다.여기서 두번째 줄에 보이는 키 쌍(Key pairs)을 선택합니다.우측 상단의 [신규 생성]버튼을 클릭 하셔서 계정을 생성 하셔야 합니다.버튼을 누르시면 아래와 같은 화면을 확인하실 수 있습니다.이는 ‘현재 등록이 되어 있지 않다’는 것을 의미합니다.프라이빗키 항목에 자신의 EOS 프라이빗키를 넣고이름은 영어나 숫자를 이용하여 자유롭게 이름을 정하시면 됩니다.*프라이빗 키를 입력하면 퍼블릭 키는 자동으로 입력됩니다.*반드시 키 쌍 생성 버튼이 아닌 저장 버튼을 누르셔야 합니다.정상적으로 등록이 완료되면 다음과 같은 화면을 확인 하실 수 있습니다.다들 잘 따라오셨나요?만약 이 절차를 진행하셨음에도 등록이 안되었다면 계정이 EOS에 등록이 되지 않은 경우입니다.Step2 : Scatter 설정하기이제 등록된 Scatter 계정을 통해 HEX BP 사이트의 투표 시스템과 연동하는 방법을 알아보겠습니다.Scatter의 첫 화면으로 돌아가서 [톱니바퀴]를 선택합니다.해당 버튼을 누르시면 다음과 같은 화면이 나타납니다.[네트워크]를 선택합니다.해당 버튼을 누르시면 아래와 비슷한 화면이 나타납니다.이제 다시 우측 상단의 [신규 생성] 버튼을 누릅니다.해당 버튼을 누르면 네트워크 정보를 입력해야 하는 화면이 나옵니다.* 이름 : eosnet.hexlant.Io* https 선택* 도메인 혹은 IP 주소 : 목록 중에 선택* 포트 : 80* 체인 ID : aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906복사하여 붙여넣기모두 정확하게 입력 하셨으면 저장 버튼을 눌러주시기 바랍니다.이제 등록한 Chain을 계정에 연결해야 합니다![신원인증 ID]를 눌러주세요그 다음 [신규 생성]을 클릭 합니다.EOS Mainnet을 설정 한 후에 자신의 계정을 선택합니다.모두 선택하셨으면 [가져오기]를 누릅니다.[가져오기] 버튼을 누르신 후 잠시 기다리시면다음과 같은 화면이 나타납니다.이때 acticve 권한을 클릭 후 [선택한 계정 사용] 버튼을누르시기 바랍니다.*아래 개인 정보 입력하는 부분은 옵션이기 때문에 굳이 입력하지 않으셔도괜찮습니다. 모두 입력 하셨으면 [저장] 버튼을 눌러주시기 바랍니다.이제 스캐터 새 계정이 성공적으로 만들어졌습니다. 짝짝짝Step 3 : 투표하기[Login] 눌러서 Scatter 로그인 하기2. [신원인증 ID 선택]-[수락] 클릭하기3. Log out으로 바뀐 화면을 확인하실 수 있습니다.4. 투표를 하기 위해선 [Vote] 버튼을 누르셔야 합니다.5. Vote 버튼을 누르시면 체크박스가 생성됩니다! 이제 21명의 BP가 되길 원하는 후보자를 선택하시면 됩니다.누르시면 아래부분에 선택한 BP 후보자들을 확인하실 수 있습니다.후보자를 다 선택하셨다면 [Done] 버튼을 눌러 투표를마무리 해주시면 됩니다!6. [Done] 을 누르시면 마지막으로 Scatter 화면이 뜹니다. 여기서 [Accept] 버튼을 누르시면 됩니다.자 이제 투표도 모두 완료되었습니다!#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심 #Scatter

크래커나인 팀에서는 사용자의 의견을 적극 반영하기 위해서 안드로이드 개발자 박형일님의 크래커나인 사용기 인터뷰를 해보았습니다.개발자 박형일님본인 소개를 부탁 드려요~저는 에이치나인에서 안드로이드 개발 파트를 담당하고 있는 박형일 입니다. 개발 경력은 12년 정도 됐구요.에이치나인에 입사한지는 4년 정도 됐습니다. 주로 외주 안드로이드 앱 개발 업무를 하고 있습니다.개발일을 꽤 오래 하셨네요. 시니어 개발자들은 코드를 직접 작성하는 것을 선호 하시는 것 같던데, 형일님은 어떠신가요?저도 코드를 직접 작성하는 것을 선호 하는 편입니다. 툴에서 생성되는 코드를 별로 신뢰하지 않아요. 제가 원하는 대로 안 나온다는 느낌을 많이 받거든요.그럼 크래커나인의 첫인상은 어떠셨나요? GUI 로 부터 코드를 생성해 주는 툴인데..처음엔 아이디어는 괜찮은데, 이게 과연 제대로 된 코드를 생성 해 줄까? 라는 의심이 들었죠. 꼭 사용 해 보고 싶은 프로그램은 아니었어요.크래커나인을 사용하신지는 얼마나 되셨죠?올해 6월쯤에 처음 접하여 2달 정도 된 같아요.어떤 프로젝트에 적용 해 보셨나요?회사에서 회의실 예약 시스템이 필요하다고 해서 회의실 예약 앱을 만들었어요.그 때 처음 사용 했죠. 공식 프로젝트가 아니라 디자이너 없이 웹에서 무료로 사용할 수 있는 Sketch 파일로 된 디자인 샘플을 받아서 혼자서 만들었어요.앱을 구성하는 화면은 대략 5~6개 정도로 간단한 프로젝트여서 가능 했죠. 지금은 외주 과제를 하고 있는데, 크래커나인을 사용 해서 하고 있어요.외주 같으면 주로 파워포인트로 작성된 GUI 가이드라인 문서를 보고 개발 하잖아요. 크래커나인을 사용하기 전에는 디자이너와 무엇을 통해서 개발에 필요한 디자인 정보를 얻으셨어요? 에이치나인에 있으면서 거의 대부분 GUI 가이드라인 문서를 보고 개발 했죠. 최근에 다른 프로젝트 팀에서 GUI 가이드라인 문서 없이 제플린을 쓰더라구요. 그래서 그것도 조금 써봤어요.제플린과 같은 기존의 유사 서비스와 비교해서 크래커나인은 어땠나요?GUI 가이드라인 문서를 보면서 개발을 하다 제플린을 써보니까 너무 편리하더라구요. 문서에서 원하는 정보 찾는게 불편했거든요.그래서 사실 처음 크래커나인을 사용 했을 때는 제플린과 큰 차이를 못 느꼈어요.근데 프로젝트를 진행 하다 보니 크래커나인의 코드 생성 기능이 있어서 좀 더 편리하다고 느껴지는 순간이 오더라구요. 제플린을 보고 개발 할 때는 코드나 수치를 직접 입력하다 보니 실수를 할 때도 있었고, 여전히 XML 작성하는 수고로움이 남아 있었거든요.근데 크래커나인의 레이아웃 코드 생성 기능을 사용해서 나온 XML 코드가 100% 는 아니지만 70~80%는 작업을 안해도 될 수준이더라구요. 그래서 XML 작성하는데 들이는 시간이 많이 줄어 들었어요.크래커나인을 익히는데 어렵지는 않으셨어요?타 서비스를 사용한 경험이 있어서 많은 부분 기능을 따로 매뉴얼로 보지 않아도 파악이 됐는데요.사용하는데 크게 문제는 없었던 거 같아요. 직관적으로 파악이 안 되는 기능은 사용하지 못한 것 같지만 따로 매뉴얼은 찾아보지 않았습니다.Cracker9의 어떤 기능이 가장 편리하셨나요?당연히 레이아웃 코드 자동 생성 기능이었습니다.손으로 직접 코딩 하지 않고 View들의 관계를 맺으면 자동으로 View의 관계와 속성을 xml 코드로 생성해주는 기능이 개발하는 데에 상당히 많은 도움이 되었습니다.Cracker9을 사용하면서 불편했던 점이나 개선했으면 하는 부분이 있었나요?Asset 이름이나 리소스(문자열, drawable) 이름이 해쉬값이나 text1, text2 이런 식으로 되어 있어 나중에 다 변경을 해 주어야 되었습니다. 이 부분은 개선이 되었으면 좋겠습니다.※ 위의 내용은 Cracker9 0.9.5 에서 개선되었습니다.Cracker9의 정식 버전으로 출시가 되면 사용할 의향이 있으신가요?네, 사용할 것 같아요. 가격만 너무 비싸지 않으면 전 무조건 사용하겠습니다.App을 만들거나 디자이너와 소통해야 하는 다른 개발자들에게 알려주고 싶은 Cracker9 사용 Tip이 있다면 알려주세요~디자이너가 텍스트나 이미지 단위로 View를 만드는데요. 개발자가 원하는 모든 View를 만들진 않기 때문에 Custom Layout 활용은 필수입니다.Custom Layout을 잘 활용하시면 원하시는 레이아웃 작업이 모두 가능합니다. 그리고, 오른쪽에 Tree Structure 패널이 있는데요.View의 트리 구조 순서로 레이아웃 xml 코드가 생성되기 때문에 어떻게 코드가 만들어질지 예상할 수 있어요. 물론 View의 순서나 부모/자식 관계는 마우스 드래그로 편집할 수 있습니다.마지막으로 Constraint Layout의 관계를 맺을 때, View가 작으면 정확하게 클릭하여 작업하기 어려울 수 있는데요. 당연하지만 View를 확대해서 연결 지으면 쉽게 작업할 수 있습니다.마지막으로 Cracker9에게 한 말씀해주세요~저는 안드로이드 App을 개발하면서 레이아웃 작업은 초반에 하는 시간 잡아먹는 노가다 작업이라고 생각을 했는데요.레이아웃을 자동으로 생성해주는 Cracker9을 사용하면서 더 이상 노가다라는 생각을 하지 않게 되었습니다. 아직은 Beta 버전이라 부족한 부분이 보이지만, 개선될 것이라고 믿고 계속 사용할 거 같아요.앞으로 발전하는 모습 기대하겠습니다 파이팅!#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑

이 글에서는 데일리호텔이 왜 png에서 svg로 갈아탔는지, 그리고 간단한 svg 실무 적용 팁에 대해 알려드리고자 합니다.01 SVG란 무엇인가?SVG는 “ Scalable Vector Graphics”의 약자입니다.JPEG, PNG 처럼 SVG도 그래픽 포맷(Graphic format) 중 하나입니다. SVG는 벡터 기반이기 때문에 리사이징이 되어도 전혀 깨지지 않습니다. 모든 해상도에서 자유자재로 활용할 수 있기 때문에 특정 해상도에 제한되어있지 않다는 게 핵심 포인트라고 할 수 있습니다.02 SVG가 왜 좋은가?다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 필자가 생각했을 때의 핵심 장점들은 이러합니다.1. 특정 사이즈에 구애를 받지 않습니다.즉 어느 해상도에서든 pixelate 되지 않습니다. 요새 디자이너들이 자주 사용하는 디자인 프로그램인 스케치로 따지면 아트보드와 비슷한 것 같습니다. 아트보드 안에 만든 레이어, 요소들은 다 벡터 기반입니다. 아트보드를 리사이징 해도 안에 요소들은 깨지지 않고 그 모습 그대로를 가지고 있습니다. 같은 원리로 SVG도 어떤 사이즈로든 그 모습 그대로가 유지됩니다. 그렇기 때문에 사이즈별로 아이콘을 일일이 생성해서 개발자에게 넘겨줄 필요가 없습니다. SVG 파일 하나면 모든 해상도를 대응할 수 있습니다.2. 작은 파일 사이즈비트맵 이미지들(PNG, JPEG) 같은 경우 파일 크기를 결정하는 주요 요소는 바로 ‘해상도’입니다. 예를 들어 5000x5000 픽셀 이미지는 항상 500x500보다 파일 사이즈가 큽니다.반면, SVG 그래픽 같은 경우 파일 크기를 결정하는 주요 요소는 바로 ‘복잡도’입니다. Path가 비교적 적은 간단한 이미지는 PNG, JPEG 보다 파일 사이즈가 적을 수도 있지만 이미지를 구성하는 요소의 복잡도(레이어가 많다든지 특정 효과가 많다든지)에 따라 파일 사이즈가 커집니다.하지만 이런 용량 문제는 SVG Optimizing을 하게 되면 나름 해결됩니다. 필자 같은 경우 업무적으로 스케치를 사용하고 있기 때문에 스케치에서 제공해주는 SVGO Compressor 플러그인을 활용하고 있습니다.https://github.com/BohemianCoding/svgo-compressorBohemianCoding/svgo-compressorsvgo-compressor - A Plugin that compresses SVG assets using SVGO, right when you export them. This Plugin requires Sketch 3.8.github.com 작은 파일 사이즈로 인해 로딩 시간도 훨씬 더 줄어든다는 장점 또한 있습니다.여기서 잠깐!혹시나 Bitmap과 SVG의 구성요소에 대해 잘 모르실 분들을 위하여 간단한 비교 해드리겠습니다.비트맵 그래픽: Raster Graphics (픽셀 기반)대표적인 포맷은 JPEG, PNG입니다. 이들은 픽셀로 구성되어 있습니다. 예를 들어 2x2 픽셀인 비트맵 이미지는 총 4px로 구성되어 있습니다. 개개인에 대한 픽셀들은 자유자재로 바꿀 수가 없고 움직일 수도 없습니다. 그렇기 때문에 100% 이상으로 이미지를 확대하면 Pixelate가 됩니다.SVG 그래픽: 벡터 기반픽셀로 구성되어 있지 않고 작업하고 있는 그래픽에 대한 정보로 구성되어 있습니다. 그렇기 때문에 어떤 사이즈로든 자유자재로 늘어나는 것이 가능합니다. 이러한 이유들로 인해 코드로 쉽게 적용된 스타일을 수정할 수 있습니다. 예를 들어 동그라미의 보더 값을 6에서 8로 바꾼다 / 색상을 그레이에서 블랙으로 바꾼다 / 사이즈를 40x40에서 80x80을 바꾼다 등스케치로 작업할 때도 쉽게 두 개의 차이점을 확인해볼 수 있습니다. 스케치에서 Export를 할 경우 비트맵 이미지는 하나의 압축된 레이어로 Export 됩니다. 반면 SVG는 레이어 그대로 눈에 보이지 않는 그래픽을 구성하는 정보들이 같이 저장된 채 Export가 됩니다.SVG를 구성하는 눈에 보이지 않는 정보들03 스케치가 SVG 이미지를 Export하는 방식다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 제가 생각했을 때의 핵심 장점들은 이러합니다.Sketch Export 기능스케치 하단 오른쪽 패널을 보면 Export 버튼이 있습니다. 여기서 Format을 SVG로 바꾸고 Export하면 금방 쉽게 끝나겠지 라고 생각할 수 있는데 여기서 조심해야 할 점은 본인이 어떻게 이미지를 작업했냐에 따라 옳지 않게 SVG가 내보내질 수 있습니다. 옳지 않게 SVG가 내보내 지게 되면 나중에 두 번 일을 작업하는 일이 발생할 수도 있습니다.쉽게 이해하실 수 있도록 이미지를 제작해 보았습니다. 아래 이미지는 같은 디자인인데 만들어진 방식이 각각 다릅니다.같은 아이콘이지만 구성하는 방식이 다름1. Two Shape2. One Shape3. Border and Shape Mix위 3가지 방법들은 옳고 그름이 없습니다. 다만 어떻게 이 아이콘을 나중에 활용할 것인가에 따라 만드는 방법이 달라지겠죠. 만약에 자동차 아이콘 안에 헤드라이트 색상을 바꾸고 싶다고 하면 위 방법 중 1번을 선택하면 될 것이고 선의 두께를 따로 조정하고 싶다 하면 3번 방식을 택하면 됩니다.SVG에 대해 잘 알지 못할 때는 프로그램 탓을 했었습니다. ‘왜 프로그램이 알아서 잘 못해주지?’라는 질문을 던졌지만… 슬프게도 이건 프로그램 잘못이 아닌 작업자 잘못입니다 �스케치 프로그램이든 아도비 일러스트레이터든 이 프로그램들은 디자이너가 만든 그래픽을 있는 그대로 svg 레이어로 번역하도록 프로그램이 되어 있습니다. 디자이너가 어떻게 작업했냐에 따라 그 정보 그대로 인식해서 svg로 만들어줍니다.04 SVG 아이콘이 제대로 적용 안될 경우다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 필자가 생각했을 때의 핵심 장점들은 이러합니다.헐 이건 도대체 왜….?!!!어느 날 SVG를 적용하기로 마음먹고 데일리호텔 앱 내 편의시설 아이콘 중 수영장 SVG 파일을 개발자에게 넘겼습니다. 근데 구멍이 뚫려야 할 곳이 채워져서 나오는데 원인을 모르고 헤매던 시절이 있었습니다. 미디엄에서 이 문제를 해결해줄 좋은 글을 발견하게 되었는데 난생처음 보는 단어가 2개 있었습니다.Even-Odd, Non-Zero…여기서 Even-Odd, Non-Zero의 차이점을 자세히 언급하기에는 너무 길어서 제가 참고한 미디엄 블로그 링크를 공유해드릴 테니 가서 보시면 이해하실 수 있을 것 같습니다. 작업하기에 앞서 꼭 읽어보시기를 권장합니다.https://medium.com/sketch-app-sources/preparing-and-exporting-svg-icons-in-sketch-1a3d65b239bbPreparing and Exporting SVG Icons in Sketch – Design + Sketch – MediumThis article is going to assume that you already understand the fundamentals of icon design. And focus on how to prepare and export them…medium.com 그래도 가볍게 필요한 내용만 공유드리자면 안드로이드에서는 fill-rule:evenodd를 제대로 지원하지 않고 fill-rule:nonzero만 지원한다고 보시면 됩니다. Even Odd는 특정 앱에서 호환이 안된다는 뜻입니다. (안드로이드 API 24 이상에서만 evenodd가 지원됨)근데 우리가 사용하고 있는 스케치 프로그램에서는 default값이 fill-rule:evenodd로 설정이 되어있고 여러 Path가 겹치는 아이콘 같은 경우 그대로 svg export를 하게 되면 위에서 제가 경험하였던 아이콘이 다 채워진 현상을 겪을 수 있게 되는 것입니다.1. Fills 섹션에서 Even-Odd를 Non-Zero로Fills 섹션에 가면 설정 아이콘이 있습니다. 클릭 시 Even-Odd가 디폴트 값인 것을 확인할 수 있습니다.스케치 Fill Default 값 = Even-OddNon-Zero로 설정값을 바꾸면 수영장 사다리 부분이 가득 채워진 채로 나오게 되는 것을 확인할 수 있습니다. 실제로 이 파일을 개발자에게 넘기게 되면 이렇게 채워진 채로 아이콘이 노출이 됩니다.Non-Zero 설정 / 모든 shape이 다 칠해짐이렇게 나가면 안 될 테니 수정하는 법을 알려드리겠습니다.2. Paths > Reverse Order 적용원래 뚫려 있어야 하는 Path를 Layer 패널에서 찾으면 됩니다. 빨간색으로 칠한 부분이 뚫려있어야 하는 부분들입니다.레이어 패널에서 path 확인하기Path가 선택된 채로 Layers > Paths > Reverse Order을 클릭합니다.Paths > Reverse OrderReverse Order을 클릭한 후 원래 뚫려있어야 하는 부분이 뚫리게 됩니다. 이 상태로 svg로 export하시고 개발자에게 전달을 하면 됩니다.마치며개인적으로 SVG에 대한 장점이 너무나도 크다고 생각하여 굳이 갈아타지 않을 이유가 없다고 생각합니다. 특히 Web 디자인을 할 때도 SVG를 저는 적극적으로 사용하시라고 권장하고 싶습니다. � 안드로이드 개발자에게 넘기기 전에 SVG 파일이 문제가 있는지 가볍게 확인하고 싶은 경우 아래와 같은 사이트를 추천해드립니다.http://inloop.github.io/svg2android/위에 문제가 되었던 수영장 아이콘을 이 사이트에 올려서 보게 되면 이런 화면이 뜹니다. Warning하고 노란색 경고 박스가 뜨게 되는데 fills-rule:evenodd에 대해서 언급을 하더라구요. 정말 유용한 사이트인 것 같습니다.아울러..많은 디자이너들이 SVG 적용을 해보시길 바라며 주변에 이 글도 많이 공유해주시면 감사하겠습니다. (ㅎㅎ)또한 데일리호텔 Tech, UI/UX 등의 정보를 얻어보고자 하시는 분은 https://dailyhotel.io/ 를 읽어 보시길 권장합니다.그럼 다음에도 좋은 정보로 찾아뵙겠습니다!원문 링크 : https://dailyhotel.io/디자인-안드로이드-앱-svg-아이콘-적용기-왜-svg로-갈아탔는가-99c57cd84240작성자 : Product팀 Rachel Kim#데일리 #데일리호텔 #개발자 #개발팀 #업무환경 #개발환경 #SVN

 지난 10월 20일, 비트윈 PC 버전의 오픈 베타 테스트를 시작했습니다. PC 버전 덕분에 컴퓨터 앞에서 일과 시간을 보내는 직장인들도 편리하게 비트윈으로 연인과 대화할 수 있게 되었습니다. 이 글에서는 PC 버전에 어떤 기술이 사용되었는지 소개하고 약 4개월의 개발 기간 동안 겪은 시행착오를 공유합니다.비트윈 PC 버전 스크린샷개발 플랫폼 선택PC 버전 개발을 본격적으로 시작하기 전에 어떤 개발 플랫폼을 선택할 것인지 많은 고민을 했습니다. MFC나 WinForms 같은 네이티브 플랫폼, Qt 등의 크로스 플랫폼 라이브러리, 그리고 웹 기반 앱 등의 여러 후보를 가지고 토론을 거쳐 웹 앱으로 개발하기로 했습니다.웹 기반으로 개발하게 된 가장 큰 이유는 생산성입니다. PC 버전 팀이 웹 기술에는 이미 익숙하지만 다른 플랫폼은 경험이 많지 않았습니다. 또한, 비교적 자유롭게 UI를 구성할 수 있으며 기존의 각종 개발 도구를 이용하면 빠른 이터레이션이 가능할 것으로 예상했습니다.단, 사용자가 기존에 설치한 웹 브라우저를 통해 접속하는 방식이 아니라 브라우저 엔진을 내장한 실행 파일을 배포하는 방식을 택하기로 했습니다. 여러 브라우저 환경에 대응하지 않아도 되고, 브라우저에서 지원하지 않는 일부 시스템 기능을 직접 확장해서 사용할 수 있기 때문입니다.서버 아키텍처의 변화비트윈 서버의 서비스 로직은 Thrift 서비스로 구현되어 있습니다. 그리고 Alfred라는 자체 개발 라이브러리를 사용하여 Thrift 서비스를 Netty 기반의 서버로 구동합니다.기존의 비트윈 모바일 클라이언트는 채팅 서버와 Thrift의 바이너리 프로토콜로 통신하고 있습니다.1 그러나 웹 플랫폼에서는 서버와 지속적으로 양방향 연결을 유지하려면 WebSocket 프로토콜을 사용해야 하므로 Alfred에 WebSocket 프로토콜 지원을 추가하였습니다. 애플리케이션이 아닌 라이브러리 수준의 변화였기 때문에 기존 서비스 코드에 영향을 거의 주지 않고 새로운 프로토콜을 지원할 수 있었습니다.Alfred에 웹소켓 지원을 추가하였습니다.비트윈 PC 버전 셸비트윈 PC 버전은 크게 HTML과 자바스크립트로 작성된 웹 앱 부분과 웹 앱을 브라우저 엔진으로 구동해주고 플랫폼 API를 제공하는 셸 (Shell) 부분으로 구성되어 있습니다.비트윈 PC 버전 구조PC 버전 셸은 Chromium Embedded Framework (CEF)를 사용합니다. 이름에서도 알 수 있듯이 Chromium 브라우저 엔진을 애플리케이션에 내장하기 쉽도록 감싸놓은 라이브러리입니다. CEF는 Evernote나 Steam 등 웹 브라우저를 내장한 애플리케이션에서 널리 사용되고 있어 선택하게 되었습니다.2자바스크립트에서 셸이 제공하는 플랫폼 API를 호출할 때는 CEF의 Message Router를 사용하였습니다. Chromium은 멀티 프로세스 구조로 이루어져 있어, 렌더 프로세스에서 작동하는 자바스크립트 코드가 브라우저 프로세스에서 작동하는 C++ 코드를 호출하고 결과를 돌려받기 위해서는 별도의 처리가 필요합니다. Message Router는 이 두 프로세스 사이의 비동기 통신을 지원합니다. 이를 통해 창 투명도 조절이나 트레이 알림 표시 등 원래는 웹 플랫폼에서 지원하지 않는 기능을 확장하여 지원할 수 있었습니다.CEF에서는 Chrome 개발자 도구를 사용할 수 있어 디버깅이 용이했고, 디자이너 옆에서 바로바로 좌표나 색상 등을 바꿔볼 수 있어 협업에도 도움이 되었습니다.그러나 PC 버전을 개발하면서 가장 많은 시행착오를 겪은 부분이 CEF를 다루는 것이었습니다.문서화가 잘 되어있지 않습니다. 그래서 실제 작동 방식을 확인하기 위해 직접 소스 코드를 읽어야 하는 경우가 많았습니다일반적인 웹 브라우저에서는 잘 작동하는 API를 CEF가 자원하지 않거나 버그가 있어 다른 방식으로 구현해야 할 때가 있습니다.CEF에 노출된 API에만 접근할 수 있어 Chromium에서 제공하는 플랫폼 추상화 레이어를 활용할 수 없었습니다.비트윈 PC 버전 웹 앱비트윈 PC 버전의 주요 애플리케이션 코드는 HTML과 자바스크립트로 작성되어 있습니다. 자바스크립트로 큰 규모의 애플리케이션을 작성할 때 발생하는 여러 가지 어려움을 피하고자 React 라이브러리 및 최신 자바스크립트 기술을 적극적으로 활용하였습니다.ReactReact는 Facebook에서 개발한 오픈 소스 자바스크립트 UI 라이브러리입니다. 일반적인 웹사이트보다는 비교적 복잡한 인터페이스를 구현해야 했기 때문에 jQuery처럼 간단한 라이브러리로는 부족할 것으로 생각하여 비트윈 PC 버전은 처음부터 React를 사용하였습니다.전통적인 개발 방식에서는 UI를 변경해야 할 때 기존에 렌더링 된 DOM 요소에 명령을 내립니다. 예를 들어 어떤 항목을 삭제하려면 그 요소를 찾아서 삭제 명령을 내리게 됩니다. React를 사용할 때는 이와 달리 해당 요소가 사라진 DOM 트리 전체를 다시 생성하면 React가 이전 트리와 새 트리를 비교하여 바뀐 부분만 반영해줍니다. 전체를 다시 렌더링하기 때문에 기존에 DOM 트리가 어떤 상태였는지 신경 쓰지 않고도 원하는 상태로 쉽게 변경할 수 있어 UI 코드의 복잡도를 줄일 수 있습니다.또한, React의 컴포넌트 시스템은 독립적인 UI 요소들을 서로 영향을 주지 않고 조합할 수 있도록 해주어, 한가지 컴포넌트를 수정했을 때 의도하지 않은 다른 컴포넌트와 간섭하는 문제가 적게 발생합니다. 비트윈 PC 버전에는 약 40가지의 React 컴포넌트가 쓰이고 있습니다.자바스크립트 모듈 시스템모든 코드를 한 파일에 넣으면 코드를 관리하기가 힘들어집니다. 따라서 서로 관련 있는 코드끼리 모듈로 나누어야 하는데, 자바스크립트에는 모듈 시스템이 기본적으로는 제공되지 않습니다. 비트윈 PC 버전에서는 CommonJS 표준을 따라서 모듈을 나누고, 이를 웹 브라우저가 해석할 수 있는 형태로 합쳐주는 Webpack 빌드 툴을 사용했습니다.Webpack은 자바스크립트뿐만 아니라 CSS나 이미지, JSON 파일 등도 모듈로 취급할 수 있고, 플러그인으로 지원하는 모듈 종류를 추가할 수 있습니다. 비트윈 PC 버전을 빌드할 때 실제로 사용하는 플러그인은 다음과 같은 것들이 있습니다.jsx-loader: React에서 사용하는 JSX 코드를 자바스크립트로 변환합니다. 또한, 미래의 자바스크립트 문법을 현재 브라우저에서 지원하는 형태로 변환합니다.less-loader: LESS 파일을 CSS 파일로 변환합니다.css-loader: CSS에서 참조하는 외부 리소스를 인식하여 의존성을 파악해줍니다.url-loader: 파일 크기가 일정 이하인 리소스를 Base64 인코딩으로 내장해줍니다.ECMAScript 6ECMAScript 6는 차기 자바스크립트 표준입니다. 현재 자바스크립트의 불편한 점을 많이 해소하기 때문에 장점이 많이 있습니다. 일부 기능은 이미 브라우저에 구현되어 있지만, 아직 지원되지 않는 기능도 있어서 jstransform을 통해 ECMAScript 5 코드로 변환하여 사용하였습니다.화살표 함수: 익명 함수를 (a, b) => a + b와 같은 문법으로 훨씬 간단하게 선언할 수 있습니다. 또한, this 변수의 스코프를 현재 코드 상의 위치에 따라 결정해줍니다.클래스: 다른 언어와 유사한 클래스 문법을 제공합니다. 상속이나 접근 제한도 가능합니다.해체(destructuring) 대입: 객체의 필드를 바로 같은 이름의 변수에 대입할 수 있습니다. 예를 들어, var {a, b} = {a: 1, b: 2}; 같은 코드를 작성할 수 있습니다.기타 사용된 패키지RSVP.js: Promise/A+ 구현을 제공하는 라이브러리로, Promise 패턴을 사용하여 비동기 로직을 알아보기 쉬운 형태로 작성했습니다.FormatJS: 다국어, 국제화 지원을 위한 라이브러리입니다. UI 메시지 번역이나 날짜, 시간 등의 포매팅에 사용했습니다.정리비트윈 PC 버전은 개발 비용을 줄이기 위해 웹 플랫폼 기반의 네이티브 애플리케이션으로 개발되었습니다.비트윈 서버에서 사용하는 Alfred 라이브러리에 WebSocket 프로토콜 지원을 추가하였습니다.Chromium Embedded Framework를 브라우저 엔진으로 사용하여 웹 앱을 구동하고 웹 플랫폼에서 제공하지 않는 기능을 확장하여 사용했습니다.자바스크립트 코드의 복잡도를 줄이기 위해 React, CommonJS, ECMAScript 6 등의 기술을 활용하였습니다.VCNC Engineering Blog, 비트윈 시스템 아키텍처, 2013년 4월↩Wikipedia, Chromium Embedded Framework - Applications using CEF↩

JENNIFER 5의  유용한 기능을 소개해 드리는 시간. 새로운 기능을 검토해 보시고, 지금 바로 사용해 보세요. 제니퍼소프트는 제품을 사용하는 고객이 최적의 환경에서 모니터링 할 수 있도록 하는데 최고의 가치를 두고 모든 제품을 개발합니다.제니퍼(JENNIFER)는 웹 애플리케이션 (Java EE, .NET, PHP) 시스템 모니터링을 위한 APM(Application Performance Monitoring) 솔루션입니다. 제니퍼는 경량화(Light-Weight), 실시간(Real-Time), 그리고 개별 트랜잭션 모니터링(Individual Transaction Monitoring) 등 기술기반의 '직관적인 통합 성능관리 솔루션'으로 이미 국내외 1200여 개 고객사를 통해 검증된 바 있습니다.  또한, 시대의 요구 사항인 모바일, 클라우드, 그리고 빅 데이터 시장의 온전한 모니터링 체계를 위하여, 웹 서비스 사용자 모니터링 (Web Service Real-User Monitoring), 웹 서비스 중심의 토폴로지 뷰(Web Service Topology View), 클라우드(대규모 시스템) 환경을 고려한 아키텍처, HMTL 5기반의 N스크린(N-Screen)까지도  지원하는 APM 제품입니다.웹 서비스 중심 토폴로지 뷰 (Web Service Topology View)제니퍼 토폴로지 뷰(Topology View)는 기업의 웹 서비스를 중심으로 연결된 서비스에 대한 가시성(Visibility)을 확보하는 것이 핵심 기능입니다. WAS를 중심으로 연결된 서비스(DB, 외부 연계 서비스, HTTP 등) 사이에 발생하는 트랜잭션, 즉, 구간에서 처리되는 트랜잭션까지 실시간으로 모니터링 할 수 있습니다.구간 엑티브 서비스 모니터링: 구간에서 처리되고 있는 엑티브 서비스를 실시간 모니터링 하여 병목 지점과 그 원인을 분석할 수 있습니다.X-view 연계 분석: 병목 지점이 되는 구간에서 처리되는 모든 트랜잭션에 대한 분석을 할 수 있습니다.구간 실시간 모니터링: 실시간 차트를 통해 원하는 구간에 대한 모니터링이 가능합니다.웹 서비스 사용자 응답시간 모니터링(RUM)클라이언트 구현 기술의 발전과 모바일 기기의 대중화로 인해 기업의 서비스는 복잡해졌습니다. 사용자는 모바일을 통해 언제, 어디서든 기업의 서비스를 이용할 수 있게 되었고, APM은 이제 서버사이드 영역의 모니터링뿐만 아니라, 실제 사용자의 만족도를 높일 수 있는 사용자 중심의 성능 모니터링 기능을 요구하고 있습니다. 이러한 변화에 따라 제니퍼는 프런트 앤드(Front-End) 영역의 모니터링을 위한 실제 사용자 모니터링, 즉 RUM(Real User Monitoring)을 지원합니다.이 기능은 웹 표준 조직 기구인 W3C의 Timing Navigation API를 사용하여 별도의 모듈 설치 없이 브라우저에서부터 서버사이드까지 전 영역에 대한 응답시간 측정이 가능하며, 서버와 네트워크로 이어지는 애플리케이션 수행 경로를 시각적으로 표시하여 애플리케이션 성능에 대한 깊이 있는 분석이 가능합니다.제니퍼 for CLOUD최근 IT 흐름의 큰 변화 중 하나는 클라우드(대용량 시스템)입니다. 클라우드 환경의 큰 특징은 트랜잭션의 양에 따라 하드웨어의 제약을 받지 않고 필요에 따라 서버 수를 조절하며 운영할 수 있어야 한다는 것입니다. 제니퍼는 자동감지(Agent Auto Detection), 일괄 설정(Central Configuration), 일괄 배포 (Central Deployment) 기능을 통하여 클라우드 환경에서의 애플리케이션 성능 모니터링을 지원합니다.스마트 프로파일링(Smart Profiling)제니퍼의 개별 트랜잭션의 응답시간을 활용한 엑스 뷰 기반의 분석은 이미 수많은 고객사에서 검증된 트랜잭션 모니터링 기법입니다. 하지만, 프로파일링 분석은 개발자 혹은 성능 튜닝의 전문가가 아니면 어려움을 겪는 것이 사실이었습니다. 이에 제니퍼는 누구나 쉽게 프로파일링 데이터를 분석 할 수 있는 스마트 프로파일링(Smart Profiling)을 제공합니다. 이 기능을 통해 사용자는 Method, SQL, 외부 서비스 중 응답시간이 느린 구간을 선택하여 해당 시점의 프로파일을 쉽게 분석할 수 있습니다.실시간 Connection Pool 모니터링실시간 Connection Pool 모니터링은 Instance별 Connection Pool을 실시간으로 모니터링하는 기능입니다. 이 기능은 액티브 서비스 차트와 함께 모니터링하며 액티브 서비스 점유가 주로 DB Connection에 있을 경우 Connection Pool 설정을 조정할 수 있어 서비스 성능을 개선할 수 있다는 것입니다. 다른 측면에서 DB Connection을 특정 애플리케이션에서 많이 사용할 경우 현재 Connection을 사용하고 있는 Active Service를 찾아내어 원인을 분석할 수 있습니다.실시간 애플리케이션 변경 이력 모니터링기업에서 운영하는 서비스는 수많은 고객의 요구사항을 반영하고 서비스 개선을 위해 하루에도 여러 번 애플리케이션을 변경합니다. 모니터링 관점에서 애플리케이션 변경 시점은 곧 서비스 장애가 일어날 가능성이 가장 많은 시점입니다. 그렇기에 모니터링이 가장 필요한 시점이기도 합니다. 애플리케이션 변경 감지 기능은 변경 전후의 성능 변화를 실시간으로 모니터링하고, 변경 시점에 변경된 소스코드를 추적하여 어떤 소스코드가 변경되었는지 추적할 수 있습니다.  이를 통해 개발자와 운영자 모두가 쉽고 빠르게 서비스의 변화를 감지하고 대응할 수 있는 장점이 있습니다. 엑스 뷰(X-View) > 애플리케이션 연계 분석애플리케이션 연계 분석은 검색한 X-View의 개별 트랜잭션을 기반으로 애플리케이션 단위 호출건수, 평균 응답 시간, 최대 응답 시간, 평균 SQL 시간, 평균 CPU 시간을 함께 분석할 수 있는 기능입니다.  또한 이러한 성능 수치들이 높은 애플리케이션의 개별 트랜잭션을 분석하여 성능에 영향을 미치는 애플리케이션을 튜닝 할 수 있습니다.엑스 뷰(X-View) > 연계 트랜잭션 분석제니퍼는 하나의 요청으로부터 시작된 다수의 트랜잭션 간의 상관 관계를 모니터링하거나 분석할 수 있습니다. 하나의 서버에서 처리된 서로 다른 업무 트랜잭션들을 연계할 수 있으며, 다른 서버에서 발생된 트랜잭션을 연계할 수 있습니다. 프로토콜 후킹 방식(HTTP, RMI)과 GUID를 활용한 연계방식을 지원합니다.엑스 뷰(X-View) > 자동 스택트레이스제니퍼를 포함한 대부분의 APM은 트랜잭션이 느린 원인을 분석하기 위해 매서드 프로파일링 기능을 제공합니다. 하지만 매서드 프로파일링 기능은 잘못된 설정으로 성능에 영향을 주거나 실제 느린 매서드를 찾지 못할 경우가 많습니다. 또한, 로직을 잘 알아야 하므로 성능 전문가가 아닌 이상 사용이 매우 어려운 단점이 있습니다.제니퍼는 이런 제약사항을 없애고 좀 더 쉽게 사용하기 위해 자동 스택트레이스 기능을 제공합니다.  이 기능은 성능 전문가가 아니더라도 느린 트랜잭션이 발생했을 때 해당 시점에 자동적으로 스텍트레이스(Stacktrace)를 남겨서 원인을 쉽고 빠르게 분석할 수 있습니다. 제니퍼소프트는 항상 제니퍼 고객의 모니터링 환경을 좀 더 쉽고 유용하게 할 수 있도록 고민하고 있습니다.  더 좋은 기능을 제공할 수 있도록 노력하겠습니다. 

 이 포스트는 제가 개발팀에게 했던 세미나를 정리한 것입니다. 개발자와 기획자, 개발자와 디자이너 사이에 의사소통에 대해서 얘기하는 글이 너무나 많습니다. 디자이너(기획자)가 개발자와 일하기 위해 알아야하는 최소한의 개발 용어, 기획자와 개발자가 절대 하지 말아야 할 말들 등등 재밌는 포스트들이 인터넷에 떠돌고 여러 담당자들의 공감과 비판을 사고 있지요. 언제 이야기해도 농담을 주고 받으며 할 수 있는 좋은 주제인 것 같습니다. 그러나 그런 글들은 해당 개발자 또는 기획자가 쓴 글이기 때문에 바이어스가 걸리기 마련이지요. 우스갯소리로 넘기기에는 껄끄럽고 진지하게 받아들이기에도 껄끄럽죠. 왜 이런 말들이 이렇게 많이 나올까요? 왜냐하면 실제로 그들이 대화하는 방식이 너무나 다르고 서로가 하는 일을 이해하기 힘들기 때문입니다. 서로간에 말이 정말 잘 통했다면 그럴 일이 없겠지요. 심지어 화성에서 온 개발자 금성에서 온 기획자라는 말이 한 때 많이 나돌아 다녔지요.UI/UX도 모르면서...결국 게시판 만들라는 거잖아요이런걸 기획서라고 써오다니...아니 그걸 다 된다고 하면 어떡해요이거 하나 바꾸는게 그렇게 어려운가요?언제까지 가능한지만 얘기해주세요여기서는 되는데 우리는 왜 안되나요?개발 공부 할거에요! 공감 하시나요? 저는 개발자이지만 한번 기획자의 입장에서 왜 그렇게 할 수 밖에 없었는지 핑계를 대보겠습니다. 도대체 기획자는 저딴 방구인지 말인지 모를 말들을 할까요? 와이컴비네이터의 폴 그래햄의 유명한 에세에인 Do things that don’t scale의 한국어 요약본입니다. 영어가 싫고 1분1초가 아까운 여러분을 위해서 준비했습니다 :) 읽어보시면 스타트업에서 처음부터 규모가 큰 작업을 하거나 그것을 자동화하는 일이 얼마나 위험한 일인지 간접적으로 느끼실 수 있을것 같아요. 그 중에 일부만 발췌하여 말씀드리면1. 모집 : 사람들은 많은 선택권을 가지고 있기 때문에 우리 제품을 써야할 필요가 없음그들을 선택하려면 빠른 프로토타입이 필요하고 요구사항에 맞춰 변화할 필요가 있음2. 황홀감 : 모든 유저들에게 황홀한 수준의 경험을 제공해야하는데 엔지니어 교육과정중에 유저 만족에 기울어야한다는 내용이 없어서 생각하기 힘듬3. Meraki : 하드웨어 벤처의 경우 수동으로 기계를 생산/조립하면서 기존에는 알지못했던 핵심 요인들을 발견할 수 있음4. 수동 : 초기에는 소프트웨어가 할일을 사람이 직접하는게 좋을 수도 있음.수동으로 해결하다가 해결책을 자동화하는 것은 확실한 고객을 확보할 수 있지만, 처음부터 자동화된 해결책으로 아무런 문제도 해결하지 못한다면 확실한 실패로 이어짐5. 대형 : 처음부터 큰 스케일로 일을 벌인다고해서 성공으로 이어지는 건 아님. 수동을 싫어하기 때문에 크게 일을 벌리는 것은 큰 실패로 이어짐.큰 버그가 아니고 시장 진입 타이밍이 중요하다면 바로 출시할 수도 있다 이 중에서도 저는 4번의 수동이라는 덕목을 가장 중요하게 생각합니다. 개발자라는 족속들이 수동을 굉장히 싫어하는 경우가 많습니다. 수동은 쿨하지 않거든요. 그래서 모든 것을 자동화시키려고 하죠. 자동은 쿨하니까요. 어떤 포털사이트의 랜딩 페이지를 개발해야하는 프로젝트가 생겼다고 예를 들어봅시다. 개발자는 생각합니다.매일매일 갱신되는 랜딩페이지를 만들자. 좋아요와 댓글이 많은 글들을 최신순으로 정렬하여 보여주는데 매일 자정에 랜딩 페이지가 새로운 내용으로 갱신되는게 좋겠다. 이미 한번 게시되었던 글은 다시는 게시되지 않도록 구성해야겠군. 좋아요와 댓글의 가중치는 1:2 정도가 좋겠지? 이렇게 랜딩 페이지를 하나 구성하는데 엄청난 노력과 시간을 투자합니다. 기획자 또는 마케터는 왜 이렇게 일이 오래걸리는지 답답해하죠. 빨리 출시해서 고객들의 반응을 보고 싶은데 개발이 늦어지니까요. 사실 고객들은 포털 사이트의 메인 컨텐츠가 자동으로 구성되던 수동으로 구성되던 관심이 없어요. 그건 기획자 또한 마찬가지지요. 그들에게 어떤 컨텐츠를 보여줘야 좋아할까 고민하지요. 심지어 그전에 랜딩 페이지라는 기능이 유효한지 증명되지도 않았지요. 실제로 이전에 제가 만들었던 시크릿차트라는 서비스에서 병원의 랭킹을 계산하여 유저들에게 보여주는 기능을 만들 때도 비슷한 일이 있었습니다. 병원 랭킹 기능이란 각 병원이 언급된 블로그와 카페 글을 스크레이핑하여 몇 개인지 세고 데이터베이스를 쌓고 블로그와 카페 글이 많은 순서대로 정렬하여 보여주는 기능입니다. 처음에 저도 욕심이 생기는 겁니다. 검색 포털의 API를 이용하여 스크레이핑 봇을 만들고 데이터베이스를 구축해주는 프로그램을 만들고 싶었습니다. 그 프로그램을 만드는데는 테스팅까지 약 1주일이라는 시간이 꼬박 들겠지요. 그래도 굉장히 쿨하고 재밌어 보였습니다. 그러나 그 욕망을 꾹 참고 수동으로 세서 데이터베이스를 구축하기로 결심합니다. 검색 포털에서 검색하여 나온 숫자를 눈으로 직접 보고 데이터베이스에 직접 접근하여 수동으로 입력하는 방식입니다. 저는 기획자와 다른 개발자에게도 입력하는 것을 도와달라고 협조를 요청했습니다. 그렇게 2일만에 우리는 데이터베이스를 구축했고 빠르게 배포하여 고객의 반응을 살폈습니다. 고객의 반응을 살펴보던 기획자들은 그 기능이 정말 잘 작동하고 고객들이 좋아한다는 것을 증명해냈고 저는 그제서야 API를 이용하여 모든 것을 자동화했지요. 우리는 자동화의 욕심을 버려야합니다. 물론 시간과 비용, 효율을 따져서 해야겠지요. 효율을 따지는 것은 여러분이 더욱 능숙하실거라고 생각합니다. 우선은 간단한 예로 비개발자들이 왜 요상한 말과 행동을 하는지 알아보았습니다. 그러면 개발자인 우리는 그들에게 어떻게 이야기해야할까요? 어떻게 해야 싸우지 않고 일할 수 있을까요? 애자일 개발방법론 중에 하나인 익스트림 프로그래밍에서도 이야기하듯이 지식 섬 현상(Islands of Knowledge)은 굉장히 위험한 요소입니다. 서로가 이해하는 것이 다르기때문에 계속적인 커뮤니케이션을 통해 지식 섬을 없애야합니다. 저는 그 지식섬을 없애기 위한 실질적인 방법을 소개하려고 해요.조카에게 설명하듯이1. 훈민정음 아시겠지만 개발 용어는 절대 금지입니다. 정말로 필요한 경우가 아니면 절대 개발 용어를 쓰지마세요.2. ABC 제목만 보면 훈민정음 룰과 반대되는 내용인 것 같죠? 예를 들어서 설명할게요. 태그 기능을 만든다고 합시다. 그런데 거기서 기획서에 나오지 않은 허점을 우리는 발견했습니다. 손가락을 이리저리써가며 태그가 여러개가 되었을 때 꼬이는 현상을 설명하려 하지마세요. 태그A, 태그B, 태그C 이렇게 설명하세요, 또는 "가나다"도 좋겠군요.3. 연필 & 종이 미팅을 할때 무조건 연필과 종이를 챙겨가세요. 그리고 말보다는 그림을 그려가며 설명하세요. 종이를 아끼지 말고 최대한 자세하게요. 또는 미리 정리한 문서를 준비해가세요. 문서를 보면서 설명하면 빼먹지않고 더 잘 설명할 수 있지요.4. 메타포를 사용하라 익스트림 프로그래밍에도 나오듯이 시스템 전체 또는 기능 전체를 하나의 메타포로 정의하여 설명하는 방법입니다. 현재 제가 만들고있는 IoT 관제 솔루션의 뒷면에는 기획자 또는 디자이너가 절대 이해하지 못할 프로토콜이라고 불리는 부분이 있습니다. 우리는 프로토콜을 어떻게 개발자가 아닌 사람에게 설명해야 할까요? 저는 커피머신을 메타포로 사용하여 설명하겠습니다. 우리는 제품으로부터 raw data라는 가공되지 않은 커피빈을 받습니다. 그냥 겉으로만 보면 어떤 유용한 데이터를 가지고 있는지 전혀 모르죠. 커피빈을 볶고 갈아서 사람이 마실만한 에스프레소를 만듭니다. 거기에 우유, 크림, 초콜릿 등을 더해서 다른 사용자가 좋아할 만한 또다른 커피도 만들 수 있겠죠. 데이터베이스를 모르는 사람들이 보는 깔끔한 그래프가 나오는 화면은 아메리카노, 라떼 등으로 비유할 수 있겠군요. 정말 조카에게 설명하듯이 쉽게 친절하게 설명하시면 됩니다. 그럼 다음으로 여기서 한발짝 더 나아가서 심화학습을 해보죠. 우리는 개발자로서 비개발자인 그들에게 어떻게 해주면 더 좋을까요?1. 기획의도를 이해하기 왜 이렇게 기획했는지 이해하면 좋습니다. 유저의 요구사항이 무엇이고 왜 그런 요구를 했는지 Back-log를 알면 개발이 더 쉬울 뿐만 아니라 빠르게 배포할 수 있을지도 모릅니다. 예를 들어 배포 30분전에 버그가 발견되었습니다. 개발자는 "헉, 버그다."이러면서 열심히 고치겠지요. 그러면서 기획자에게 배포를 내일해도 되냐고 물어봅니다. 기획자는 안된다고 하고 또 싸우겠죠. 만약 기획의도를 이해한다면 이 싸움이 필요하지 않을지도 모릅니다. 해당 기능을 작동시키는데 있어서 크리티컬한 것이 아니면 서비스를 우선 배포하고 이 후에 고쳐도 되겠지요. 또는, 마케팅이나 시장은 타이밍이 중요하기 때문에 기능 구현의 우선순위를 기획자가 잡아줄 수도 있습니다.2. 프로토타입을 빠르게 개발자는 코드로 이야기합니다. 그러나 비개발자는 이해 못합니다. 움직이는 프로토타입은 고객뿐만 아니라 동료의 이해도를 드라마틱하게 높일 수 있지요.3. 계속해서 점검받기 점검받는다고 그들의 아래에 있는 것이 아닙니다. 우리는 프로젝트를 완수하기 위해 각자 다른 역할을 수행하고 있는 동등한 존재임을 잊지맙시다. 개발자는 비개발자에게 계속해서 움직이는 프로토타입을 보여주고 피드백 받으면서 지식의 섬을 없애나가야 합니다. 고객들이 원하는대로, 기획자들이 기획한대로, 디자이너 디자인한대로 구현하는 것이 프로젝트에서는 무엇보다도 중요하니까요.4. 데드라인은 꼭 지키기 데드라인을 지키는 것은 개발자와 비개발자간에 신뢰관계를 높이는 방법 중에 개발자가 할 수 있는 가장 효과적인 방법입니다. 또한 고객과도 마찬가지죠. 약속을 지키지 못하는 회사의 제품을 사가는 사람은 없습니다.  우리는 서로에 대해 너무 조금만을 알고 있습니다. 그래서 서로의 입장을 모르고 문제가 생기기 마련이지요. 당연히 서로에 대해 자세히 알 필요는 없지요. 우리팀에서 프로젝트를 망치고 싶어하는 사람은 없습니다. 그러나 상황이, 그리고 오해가 프로젝트를 망치게 하지요. 그리고 누구나 똥을 쌉니다. 서로 부족한 점이 있으니 부족한 점을 욕하기보다는 부족한 부분을 채우기위해 영역을 넓혀가는 건 어떨까요? 저건 내 일이 아니니 알아서 되겠지라는 태도보다는 다 같이 고민하며 빈 공간을 채우는 편이 좋다고 생각합니다. 서로를 비난하면서 프로젝트를 할 것인가, 서로를 이해하는 마음가짐으로 즐겁게 프로젝트를 할 것인가... 선택은 당신의 손에 달렸지요.#비주얼캠프 #인사이트 #경험공유 #조언 #개발자 #개발팀 #협업 #팀워크

오전 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 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업

[LG CNS 채용 시리즈 2]내 회사! LG CNS가 맘에 드는 이유!신입사원 이열정씨가 LG CNS에 빠진 이유는 무엇일까요?▶ LG CNS와 함께하고 싶다면?https://goo.gl/fAUEYo#LG #LG그룹 #LGCNS #IoT #IT #IT채용 #LGCNS블로그 #LGCNS신입채용 #LGCNS채용 #R&D #SW개발 #공채 #박사 #보안 #블록체인 #빅데이터 #석사 #스마트에너지 #스마트팩토리 #신입사원 #아키텍쳐 #인공지능 #인프라운영 #일터 #채용 #취업 #취직 #컨설팅 #클라우드 #플랫폼개발 #하반기공채 #하반기신입사원채용 #하반기채용 #학사

전편에서는 개발 프로세스 내에서 모니터링 단계의 문제점과 이를 해결하기 위한 방법으로 APM의 역할이 DevOps 진영에서는 매우 중요한 이슈가 되고 있다고 정리했었다. 또한 모니터링 프로세스의 세부 단계와 모니터링 기준 값 설정에 대한 내용을 다뤘는데, 이를 기반으로 제니퍼를 활용하여 모니터링하는 방법에 대해 알아보려고 한다.장애 발견 및 알림제니퍼에서 이벤트 발생 조건은 컴파일 에러나 응답 시간 초과, OOM과 같은 애플리케이션 에러 유형이나 액티브서비스 개수, 응답 시간, CPU 사용률, 힙 메모리 사용률 등 서비스나 시스템의 상태 값으로 설정될 수 있다. 그리고 이벤트 설정시 외부연동 활성화 기능을 사용할 수 있으며, SMTP(Simple Mail Transfer Protocol) 모듈을 기본으로 제공한다. 또한 고객이 직접 이벤트 모듈을 구현할 수 있도록 인터페이스와 유틸리티를 제공한다. 참고로 제니퍼를 사용하는 고객사 중에서 자체적으로 구축한 관제 시스템에 제니퍼 이벤트를 연동하여, 별도의 WAS 경고 시스템을 만든 사례도 있다.   서비스 부하량 제어 (운영)제니퍼는 PLC(Peak Load Control)라는 서비스 부하량을 제어할 수 있는 기능을 제공한다. 트랜잭션 유입 차단의 기준이 되는 최소/최대 액티브서비스 개수를 설정하고, 해당 임계치 값 초과시 사용자에게 가이드해줄 수 있는 메시지나  리다이렉트 페이지를 설정할 수 있다.   만약에 대상 애플리케이션(서버 또는 WAS)이 처리 중인 액티브서비스 개수가 설정한 임계치 값을 초과하면 들어오는 사용자 요청은 거절되며 액티브서비스 이퀄라이저 차트의 요청 효과가 반사되고, 색상 또한 붉은색 계통으로 변하게 된다.사용자의 요청(Request)이 거절되면 PLC 관리 화면에서 설정한 메시지가 보이거나 아래와 같은 화면으로 리다이렉트 되며, 모니터링 대상 애플리케이션의 액티브서비스가 임계치보다 낮아지면 원래의 화면으로 돌아올 수 있다.  장애 원인 분석 (개발)개별 트랜잭션에 대한 프로파일 데이터를 분석하기 위해서는 대상이 되는 패키지나 클래스를 알아야 하는데, 적용 범위에 따라 프로파일 데이터 크기가 매우 커질 수 있으므로 실제로 운영되는 서비스에는 큰 부담이 될 수 있다. 하지만 제니퍼의 자동 프로파일링과 스택트레이스 기능은 설정한 응답시간을 초과한 트랜잭션에만 적용되기 때문에 실제 운영 단계에서 사용하기에 적합하다. 프로파일이란 트랜잭션의 시작점이 되는 메소드의 호출 구조를 상세하게 분석하는 기능을 말하며, 스택트레이스는 앞에서 설정한 기준 값을 초과하는 순간에 호출된 메소드 구조에 대한 로그를 남기는 것을 말한다. 만약에 설정한 응답시간을 초과하여 의심이 될만한 트랜잭션을 분포도 차트에서 찾았다면, 트랜잭션 분석 화면을 통해 문제 시점의 스택트레이스 정보를 참고하거나 응답이 지연되는 프로파일 데이터를 구간 별로 검색하여 콜-트리를 통해 문제가 되는 메소드 위치를 정확히 알아낼 수 있다.소스코드가 배포되었다면 트랜잭션 분포도 차트에서 배포 시점에 세로 축이 하나 그려진다. 해당 축을 선택하면 새로 추가되거나 수정된 리소스 목록을 조회할 수 있으며, 리소스의 배포 전/후의 내용을 분석하는 코드리뷰 기능은 개발 환경에서 반영된 소스코드를 분석해야하는 번거로움을 덜어준다.배포 이후에 액티브서비스가 빠르게 처리되지 못하고, 트랜잭션 분포도 차트가 기존의 패턴과 다르게 형성이 된다면 새로 반영된 소스코드에 문제가 있을 가능성이 매우 높다.결론인류 사회에서 자신이 속해 있는 환경과 전혀 다른 이질적인 문화나 새로운 생활 양식을 접할 때 받는 충격과 공포를 문화 충격(Culture Shock)라고 하는데, 이는 IT 분야에서도 크게 다르지 않다. 사실 DevOps는 몇년 전부터 계속 주목받고 있으며, 많은 소프트웨어 개발 조직에서 시도하고 있는 개발 방법론이다. 하지만 새로운 문화에 대한 거부감으로 인해 제대로 적용되지 못하고 있는 것이 현실이다.DevOps가 추구하는 가치인 존중과 신뢰를 바탕으로 개발과 운영의 원활한 의사소통과 협업 관계 형성은 말처럼 쉽지 않다. 어떻게 보면 이상적일 수 밖에 없는 추상적인 개념이지만 본문에서 다뤘듯이 APM을 상호 간의 의사소통 도구로써 잘 활용한다면 이상이 아닌 보다 현실에 가까워질 수 있다고 필자는 확신한다. APM은 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목표로 하는 DevOps를 개발 문화로 성공적으로 정착시키는데 가장 중요한 역할을 하는 도구라고 생각한다.