2018년 6월 2~3일 양일간 JavaScript 최대 컨퍼런스인 JSConf 유럽 행사인 JSConf EU 가 개최되었다. 필자는 가보지 못했지만 , TC39 패널도 나오고 Remy Sharp 도 발표자로 나오고 하니 볼만한 컨퍼런스였던 거 같다. (TC39는 ECMAScript – 즉 JavaScript 의 표준을 정하는 단체다. Remy Sharp 는 nodemon, jsbin 의 개발자로 유명하다.)
하지만, 지금 들려오는 최고의 이야기는 deno 에 대한 이야기이다. 이 프로젝트가 공개된지 20여일만에 깃헙 스타를 2만개를 어떻게 받았을지 한번 알아보도록 하자.
그림 1. JavaScript 최고의 컨퍼런스
JSConf.EU에서 라이언 달(Ryan Dahl)은 첫날 저녁 세션에서 "10 Things | Regret About Node.js" 라는 제목으로 발표했다.
그림 2. 개발자의 완성은 얼굴
유튜브 링크 : https://www.youtube.com/watch?v=M3BM9TB-8yA
pdf 링크 : http://tinyclouds.org/jsconf2018.pdf
라이언 달은 Node.js 를 처음 만든 사람으로써 현재 가장 큰 오픈소스 커뮤니티 중 하나인 노드 커뮤니티의 첫번째 리더였다. 그가 이번에 발표한 것은 그동안 사람들이 많이 제시한 부분을 어느 정도는 이야기 하고 있다는 점에서 주목해 볼만하다. 10가지 이야기를 살펴보자
처음 라이언 달이 노드를 만들때는 이벤트 드리븐 HTTP Server를 만들고 싶었고 거기에 가장 적합했던 것이 당시 JavaScript 였고 그 목표는 훌륭하게 달성했다고 한다. (Node.js는 이 말 대로 가장 빠르게 인기를 얻은 서버사이드 프레임워크가 되었고 이 사상은 이후 다른 언어에 영향을 끼치게 된다.)
하지만, 최근에 학술적인 컴퓨팅 작업을 하면서 버그들이 명확하지 않다라는 사실을 알게 되었고, 이번의 작업을 하게되었다고 한다.
아마 Node.js를 작업하는 대부분의 사람들은 이 말에 백퍼공감 할 것 같은데, Node.js 의 비동기 호출은 여전히 콜백 API를 기준으로 되어 있다. Promises는 Async, Await 을 제공하기 위해서는 필수라고 할 수 있다. 2009년에 추가했다가 2010년에 지운 일에 대해서 언급하면서 자신이 Promises를 고집했다면 커뮤니티 소스가 더 빨리 Async Await으로 진보했을 것이라는 후회
V8은 그 자체로 훌륭한 샌드박스 모델을 가지고 있다는 것과 이후 Node 응용 프로그램이 어떻게 유지되고 발전되는 것을 고려했었으면 다른 언어들이 갖지 못할 보안을 가질 수 있었을 걸 하는 후회를 남겼다.(V8은 Node.js의 JavaScript 엔진으로써 구글에서 만들어 크롬에도 사용된다.)
처음 노드를 만들때 크롬 브라우저가 GYP라는 메타 빌드 시스템을 사용하다가 크롬은 GN 으로 메타 빌드 시스템을 업그레이드 했는데 Node.js 는 GN으로 변경하지 못한 부분에 대한 이야기를 한다. 참고로 구글의 GN을 소개하는 시스템에서는 20배 정도 빠르게 빌드가 된다고 한다.( 메타 빌드 시스템은 여러 플랫폼-윈도우즈,Mac, Linux-에서 소스코드를 빌드하기 위해서 사용되는 빌드 시스템이다.)
GYP를 이용해 빌드 시스템을 만들면서 네이티브 콜을 하기 위해서는 C++ 바인딩을 하도록 사용자에게 강제 했는데, FFI(Foreign Function Interface) 를 제공했었어야 되었다고 하는 이야기를 한다.
Node.js 는 모듈 시스템을 가지고 있다. 이 모듈 시스템을 go 와 java에서 최근에 언어 자체적으로 구현이 되는 스펙들이 발표가 되었다. (go는 나오면서 부터) 하지만, 이 모듈 시스템을 관리하는 프로그램은 3
파티 프로젝트로 최근에는 떼어 놓는 것이 일반적인데 노드는 npm이라는 패키지 매니저가 관리하는 package.json. 파일이 main() 함수에서 찾도록 함으로 npm 의존적으로 커뮤니티를 만든 점을 스스로 비판하고 있다. 최근에는 facebook에서 만든 yarn이라는 패키지 매니저가 npm을 대체하고 있지만 package.json은 그대로 사용하고 있다. 의도하지 않았지만 defacto(사실상의 표준)이 된 셈.
또, 이 package.json 파일은 모듈을 찾을 때 명시적이지 않은 단점도 존재한다. 아래 그림을 참조하면 이해가 될 것이다.
그림 3. somemodule을 찾아라!(출처 : http://tinyclouds.org/jsconf2018.pdf )
package.json 파일의 모듈 시스템이 파일 디렉토리 기준으로 잡혀 있게 만들어서 package.json 파일이 현재는 라이센스, 레파지토리, 설명등을 비롯해서 모듈 시스템 자체만으로는 필요없는 정보를 다 가지게 되어서 너무 무겁게 된 경향이 있다고 한다.
위에서 언급한 파일 디렉토리 기반의 모듈 시스템의 약점과도 일맥상통하게 모듈을 가져오는 알고리즘이 복잡해졌고, 브라우저에서 가져오는 방법과도 맞지 않기 때문에 굉장히 어려워 졌다는 이야기를 하면서 그렇지만 이것은 돌이킬 수 없기 때문에 커뮤니티에 미안하다는 의견을 피력했다.
이것은 오히려 브라우저내 자바스크립트가 작동하는 것과 표준이 달라서 모듈로더는 사용자의 의도를 파악하기 위해 많은 고민을 해야 한다는 점을 이야기 했다.
브라우저가 index.html을 default로 가지기 때문에 index.js 를 지정한게 그 때는 괜찮다고 생각했으나 모듈로딩 시스템을 더 복잡하게 만들었다고 한다.
이상의 10가지 이야기를 마지막으로 자기가 새로 만들고 있는 프로젝트를 공개했는데 그게 바로 이 deno 프로젝트다.
프로젝트 링크 : https://github.com/ry/deno
그림 4. 무려 TypeScript Runtime
아직은 프로토타입 같이 시작에 불과한 프로젝트지만 이런 작은 소스코드가 얼마나 커지는 지를 그동안 Node.js를 통해 우리는 잘 보아 왔다.
가장 기본적인 특징은 TypeScript를 Runtime 으로 가진다는 것이다. 트랜스 파일이 아니라 바로 런타임 지원이라는 것이 중요한 특지이다.
package.json 없고 npm 없고 source code url 만 import 할 수 있다. 다음을 보자.
import { test } from "https://unpkg.com/deno\_testing@0.0.5/testing.ts"
import { log } from "./util.ts"
require 가 아니라 import 명령어를 사용하고 확장자 .ts를 지정하며 url 임포트를 한다.
파일시스템과 네트워크는 샌드박스 모델을 사용해서 그냥 사용할 수는 없고 인터페이스를 통해서만 가능하고 현재는 프로토콜 버퍼를 통해 V8 엔진과 인터페이스 할 수 있다. 빌드 스크립트에는 gn과 ninija를 사용한다.
그림 5. gyp 안녕
그 외에도 자기가 후회하는 것들을 모두 바로 잡아 두었음을 알 수 있다. 흥미로운 것은 golang 브랜치를 가지고 있다는 것이다.
그림 6. 어디에 쓰는 브랜치인고
브랜치로 가보면 go 로 빌드하는 인스트럭션이 나와 있는 걸로 봐서는 go 빌드를 중간에 고려했다가 gn으로 선회한 것으로 보인다. 혹시 틀렸으면 멘션 주시면 반영하겠다.
아직은 조금 더 두고 봐야하는 프로젝트겠지만 아마도 Node.js 진영에서 이 변화를 강건너 불 보듯 하고만은 있지는 않을 것 같다. 현재는 Node.js. 에 합칠 수 있어보이지 않기 때문에 긴 시간의단련은 필요해 보이지만 서버사이드 스크립트 엔진의 새로운 시작이라고 보여지고 계속 주목해 보아야 하겠다.
]]>한동안 살펴보지 않았던 GitHub 트렌드에 다시 관심을 가져보려고 합니다. 요새 너무 회사일만 했더니 뭔가 새로운 걸 해보고 싶은데, 재미있을
만한 게 생각이 나지 않았습니다. 그래서 GitHub 트렌드를 보다보면 재미있는걸 찾는데 도움이 되지 않을까 생각합니다. 같이 재미있는 것을 찾아 보실까요?
이번 주에 8,792번의 스타를 받은 TypeScript 리파지토리 입니다. V8엔진에서 동작하는 보안 런타임이라고 짧게 설명이 되어있는데,
최초 커밋 이후로 한달도 지나지 안았습니다. 그래서 인지 아직 문서화도 되어 있네요. TypeScript를 잘 알지 못해서 리파지토리가 어떤
역할을 하는지 정확히는 알 수 없지만, 대단한 인기를 누리고 있는 것으로 보아, 중요한 역할을 하는 것으로 짐작됩니다.
요새 개발 관련된 회사에 들어가긴 위해서 필수가 된 알고리즘에 관련된 리파지토리입니다. 보통 알고리즘을 설명하는 것들이 C나 java로 된 것에
반에 이 리파지토리는 JavaScript로 내용을 설명합니다. 자료구조와 알고리즘을 상세하고 예제를 통해서 잘 설명하고 있습니다. 어떤 개발자가
보아도 좋을정도로 잘 기록되어 있습니다. 특히 JavaScript에 익숙한 웹 개발자이거나, JavaScript를 익히려는 개발자가 관심을
가지면 좋을 거 같습니다. 영어로 쓰여있으며, 중국어로는 번역이 되어 있는 것 같습니다. 이번주 3,231번의 스타를 받았습니다.
무언가를 만들고자 할때 이 리파지토리를 먼저 살펴봐야할 거 같습니다. 자신 만의 뭔가를 모아둔 큐레이션 리파지토리입니다. 여기에 다른 사람이
만들어놓은 것을 참고로 더 나은 것을 만들 수도 있겠네요. 다양한 분야의 결과물들이 올라와있습니다. 저는 자바스크립트 게임보이 에뮬레이터가 눈에
들어오네요. 이번주 2,882 스타를 받았습니다.
터미널에서 보는 개인정보 대시보드라는 설명입니다. 2,426개의 스타를 받안 Go언어 리파지토리네요. 리파지토리명이 주는 느낌이 썩 기분좋지많은
않습니다. ( 이거 뭐 잘 안될때 하는 말(what the f-word)인거죠? )
개인정보 대시보드라는 설명만 봐서는 잘 이해가 안됬는데, 스크린샷을 보니 한번에 이해가 됩니다. 일정과 작업하고 있는 리파지토리 할일 정보를
터미널에서 보여주는 개발자스런 대시보드입니다. 터미널을 사랑하는 개발자라면 한번 쯤 설치해볼만 할거 같습니다.
주변에서 자주 애자일에 관해 얘기를 해서 제목만 보고 GitHub에서 eXtreme Programing을 할 수 있게 도와주는 도구겠거니
짐작했는데, GitHub을 Windows XP스타일로 띄워주는 어플리케이션입니다. 깨알같이 도움말을 보여주는 크립도 보이네요. 2,361개의
스타를 받았습니다.
새로운 라이센스입니다. 퍼블릭 라이센스이며 “이 라이센스는 신과 나만이 뭘 했는지 이해했고, 지금은 신만 알고 있을때 사용한다”라고 합니다.
GLWTPL ( Good Luck With That Public License )의 의미를 보면 이해가 되네요. 중국어, 불어, 러시아, 그리고
포르투갈 언어로 번역되어 있습니다. 스타는 2,278개를 받았습니다.
중국어로된 nodejs 학습가이드 리파지토리입니다. 중국어로 설명이 되어있어서 더이상의 파악은 불가합니다.
다시 나타난 중국어 리파지토리입니다. 번역기를 이용해서 내용을 살펴보면 다양한 클라이언트를 한번 작성한 코드를 사용하여 다양한 엔트포인트(
Web/ReactNative )로 컴파일 할 수 있도록 해주는 솔루션이라고 합니다. 문법은 React를 따른다고 하니 한번 사용해보고 싶지만,
내용 설명이 모두 중국어로 되어 있어서 엄두가 나지 않네요. 이번 주 2,004번의 스타를 받았습니다.
리눅스 커널과 라즈베리파이를 통해 OS개발을 배울 수 있는 컨텐츠를 가진 리파지토리입니다. 단순한 OS시스템을 만드는 거부터 단계별로 설명되어
있으며, 라즈베리파이를 위한 OS이지만 리눅스 커널을 사용하기 때문에 커널의 이해를 시작할 수 있는 좋은 시작 점이 될 수 있어 보입니다.
내용은 계속 추가되고 있으며, 현재 전체 내용중에 약 60%정도가 완성되어 있습니다. 1,887번의 스타를 받았습니다.
조지아 텍의 컴퓨터 사이언스 전공과목 중 “자연어” 강의 자료입니다. 1,492번의 스타를 받은거 보면 해당 과정을 듣는 사람이 많은 거
같습니다.
1,568번은 스타를 받은 그래프 시각화 프레임웍입니다. 이 리파지토리는 주저리 주저리 설명하는 것보다, 예제를 직접 보시는 게 이해가
빠릅니다.
데모 페이지도 있습니다.
https://antv.alipay.com/zh-cn/g6/1.x/index.html
( 만드신 분이 중국분이신데, 다행히도 GitHub에는 영어로 적어주셔서 내용을 알 수 있었습니다. )
그래프 시각화 말고 데이터 시각화에 대한 것들도 만들어져있고, 미국 일리노이주립대학교 교수님의 추천사와 많은 곳에서 이미 사용중이라고 얘기하고
있으니 기능이나 성능은 사용을 고려해봄직한데, 중국어의 압박이 있습니다.
https://antv.alipay.com/zh-cn/index.html
인터뷰 질문들을 모아놓은 리파지토리입니다. 우리나라 뿐만 아니라 외국도 인터뷰에 대한 고민이 참 많음을 엿볼 수 있는 것 같습니다. 다만
우리나라는 이러한 인터뷰 내용을 본인만 알고 있는 경우가 많은데, 이렇게 공개해준것이 감사할 따름입니다. 면접이 없더라도 본인에게 스스로 해보면
좋을 만한 질문들이 많이 모여져 있습니다.
더 질문을 알기쉽게 모아둔 웹 페이지도 있으니 방문해 보면 좋을것 같습니다.
https://30secondsofinterviews.org/
설명이 필요없을 정도로 유명하죠. 비주얼스튜디오 코드의 소스코드입니다. 거의 매일 소스코드가 업데이트 되고 있으며, 그동안 약 5만 3천번의
스타를 받았으며, 이번주는 1,348회의 스타를 받았습니다. 개인적으로 마이크로소프트에 대한 인상이 많이 달라지게 했던 툴 중의 하나입니다.
최근에 뉴스를 보니 ReactNative로 변경할 예정이라고 하니 어떤 변화를 가져올지 지켜볼 필요가 있을 거같습니다.
GitLab, GitHub, 그리고 yona 같은 Git 호스팅 서비스입니다. 이런 호스팅 서비스를 처음 설치하다보면 많은 어려움을 겪게
되는데, gitea는 이러한 고통으로부터 해방하는 것이 목표라고 말하고 있습니다. 실행 해볼 수 있는 데모 페이지는
https://gitea.io/en-US/ 이며, 필요할 때 간단히 설치할 수 있을거 같습니다.
UI상으로 봤을 때, GitHub과 유사해 보입니다. Go를 이용하여 만들었다고 하니 속도는 빠르겠다는 생각이 듭니다. 1,385번의 스타를
받았습니다.
성능 테스트 분석 툴입니다. 자바스크립트로 만들어져 있으며, npm으로 설치하고 “$ hiper uri” 로 간단하게 테스트를 실행하고 잠시 후
결과를 볼 수 있습니다. 간단하게 성능테스트를 해볼 때 사용해 봄 직합니다.
이번주에 1,360번의 스타를 받았습니다.
몇 년 전이었나요? airbnb의 자바스크립트 코딩 스탠다드가 인기를 얻었던 적이있는데, 비슷한 맥락으로 이해할 수 있을거 같습니다.
vip.com의 자바 코딩 스탠다드와 라이브러리와 도구를 담고있는 리파지토리입니다. 자바 코딩스탠다드로 1,231번의 스타를 받았을 것 같지는
않고, jvm관련 한 툴(vjmap, vjtop, vjdump, vjmcli)이 인기를 얻었을 거 같은 생각이 듭니다. 중국에서 만든
리파지토리이고 대부분 중국어로 설명되어 있지만, 일부 툴은 영문 매뉴얼을 제공합니다.
react, angular와 더불어 많은 인기를 누리고있는 vue의 리파지토리입니다. 모두 97,211번의 스타를 받았으며 이번주에
1,085번의 스타를 받았습니다. 프론트엔드 개발을 하신다면 알고 계셔야할 리파지토리 중의 하나 겠네요.
react에서 사용할 수 있는 차세대 routing 툴입니다. react 15버전 이상에서 사용할 수 있다고 하며,
https://reach.tech/router 페이지에서 소개와 사용법에 대해서 설명하고
있습니다. react로 개발하고 계신다면 한번쯤 참고해 보실만한 리파지토리입니다. 1,137번의 스타를 받았습니다.
자바스크립트로 어플리케이션을 관리하는 UI 툴킷입니다. 일렉트론으로 만들어진거 같습니다. 관리의 범주에는 앱을 그룹별로 정리하거나, 앱 생성,
검색, 프로젝트 대시보드, 프로젝트 내의 파일을 찾아준다거나 스크립트를 생성해주는 IDE가 해주는 대부분의 기능을 소화합니다. 툴킷이라고
하기보다는 IDE라고 봐도 무방할거 같습니다.
https://opencollective.com/jsui# 에서 펀딩을 받아서
개발하고 있는 것으로 보입니다.
이번 주에 1,107번의 스타를 받았습니다.
react에서 사용할 수 있는 이미지 컴포넌트입니다. 비동기로 이미지를 로딩하도록 하는 것이고 ideal이라는 명칭을 사용한 것에 걸맞게
lazy-loading은 물론이고 저용량으로 먼저로딩하고 보여주는 방식, 느린 네트워크에서 사용자의 요청이 있을 때 이미지를 다운 또는
placeholder만 보여주는 방식등 이미지 컴포넌트가 가질 수 있는 모든 기능을 가지고 있습니다. 이번주 1,065 번의 스타를 받았습니다.
다음 페이지에서 예제를 확인하실 수 있습니다.
https://github.com/stereobooster/react-ideal-image/blob/master/introduction.md
텐서플로우를 모르시는 분은 없겠죠? 구글에서 공개한 머신러닝 프레임웍입니다. 이번주 854번의 스타를 받았습니다. 공개한 이후 10만번 넘게
스타를 받았네요. 머신러닝의 스타 플레이어 답습니다.
머신러닝 라이프사이클을 완성하기 위한 오픈소스 플랫폼이라고 소개하고 있습니다. 파라미터를 변경한 것을 기록하고 결과를 추적하는 것, 코드를
패키징해서 재사용가능하도록 하는 것, 모델을 관리하고 배포할 수 있도록 하는 것이 주요 기능이라고 합니다. 현재 만들어지고 있는 중이고 계속해서
변화가 있을 수 있다고 명시하고 있습니다. 파이썬으로 개발되었고 927개의 스타를 받았습니다.
웹 어플리케이션에서 “Pull to Refresh”를 위한 빠르고 강력한 플러그인이라고 설명하고 있습니다. JavaScript로 작성되어 있고
데모를 제공하는데 모바일에서만 동작하지만 동작하는 이미지를 제공합니다. 의존관계가 없다고 설명하고 있고 간단하게 추가할 수 있다고 하니 기능이
필요하다면 한번 살펴보면 좋을 것 같습니다. 940번의 스타를 받았습니다.
C언어의 튜토리얼을 모아놓은 큐레이션 리파지토리입니다. 기존 튜토리얼 큐레이션과 다른 점은 실제 크고 작은 프로젝트를 진행하면서 익힐 수 있는
튜토리얼들을 모아놓았다는 접입니다. 씨언어를 익혀야 하거나 평소와 다른 카테고리의 어플리케이션을 개발해야 한다면 참고해 봄직 하네요. 이번 주
884번의 스타를 받았습니다.
이번 주의 마지막 리파지토리 입니다. 894번의 스타를 받았고 Qt( https://www.qt.io/
)라는 크로스플랫폼 SDK 와 C++ 의 리버스 엔지니어링 툴입니다. 스크린샷을 보니 Deassembly 같은 용어가 눈에 보입니다.
핀포인트를 제거 하니까 OOM이 사라졌습니다!!!!
그리고!! 스카우터에서 쿼리가 안나와서 계속 고생했는데요..
안나오던 스카우터 쿼리도 나오게 됐어요!!!
원인은 모르겠으나!! 제보.. 드립니다! ^ㅂ^)/
추측컨데 우리서비스가 쿼리를 때리는 양이 많아서…
핀포인트가 그 쿼리를 쓰는 속도보다 우리 쿼리가 들어오는 속도가 많아져서 OOM이 난거겠죠..
핀포인트의 어딘가 IO처리하는 쪽에서 줄서서 대기타고 있다가 그랬겠죠??
가장 최근에 궁금해 했었던 프로젝트는 아마도 React 가 아니었나 싶다. GIS(Geographic Information System) 프로젝트를 하면서 Zero Dependency Map Framework를 만들던 추억을 되짚어 보면서 언젠가 비슷한 프레임워크를 만들어야지 했었던 다짐(?)들이 솔솔 떠오르는 주제중의 하나가 웹 프레임워크인데 Virtual DOM이 어떻게 작동할지가 가장 궁금한 영역이었다.
아래의 리스트들을 살펴보자.
JavaScript: How to write your own Virtual DOM
Welcome To Facebook 의 약자라 믿으며(응?) 읽어볼 수 있는 “WTF is JSX”는 어떻게 JSX를 파싱해서 렌더링 트리를 만드는지에 대한 내용이 주로 있다. 이 글에서 가장 중요한 부부은 h() 함수. hyperscript 부분이다.
1 | function h(nodeName, attributes, ...args) { |
hypertext를 JavaScript 객체로 바꿔 주는 부분이라고 볼 수 있다.
이 내용은 마지막 링크인 “How to write your own Virtual DOM” 과 굉장히 자연스레 이어지기 때문에 독자들에게는 좋은 인사이트를 줄 수 있을 것 같다.
위의 hyperscript가 JSX 를 파싱해서 아래와 같은 형태의 DOM 트리를 만들고나면 브라우저에 DOM으로 표현을 하게 되면 이른바 우리가 알고 있는 브라우저에 렌더링 하는 형태로 드러나지게 되는 것이다.1
2
3
4h(‘ul’, { ‘class’: ‘list’ },
h(‘li’, {}, ‘item 1’),
h(‘li’, {}, ‘item 2’),
);
이후, Hanlding Changes 부분이 바로 Tree의 변화를 감지해서 바로 그려주게 되는 내용을 기술하고 있다고 보면 된다. props와 state등의 더 깊은 부분은 이 포스팅에서는 찾아볼 수 없지만, 이루어지는 메커니즘을 이해하는데에는 훌륭한 글이라 보여진다.
물리 엔진(영어: physics engine) 또는 물리 연산 엔진은 강체동역학(충돌 감지 포함), 연체동역학, 유동역학과 같은 단순한 특정 물리 시스템을 최대한 시뮬레이션하려고 하는 컴퓨터 소프트웨어이다.
이 물리 엔진을 위해서 아래의 내용들을 제공하고 있다.
이 중에서 “Build your own basic physics engine in JavaScript”에는 브라우저에서 어떻게 캔버스에 물리 오브젝트를 그리고 값을 변화시기는지 간단하게 나와 있다. 이 중에서 가장 초보자들이 가장 눈여겨 봐야할 부분은 다음의 소스 코드에서 requestAnimationFrame 이 들어간 부분이다. 이 부분은 브라우저 캔버스에서 60프레임을 확보하기 위해서 사용되는 내장 브라우저 함수이다.1
2
3
4
5
6
7Loop = function()
{
//재귀호출을 실행한다.
requestAnimationFrame(Loop);
//실제 프레임 안에서 작동하는 내용을 기술해서 작동하도록 한다.
frameRender();
}
requestAnimation에 대한 자세한 내용은 다음을 통해 숙지하자.
모질라 개발자 사이트 - requestAnimationFrame
“How Physics Engines Work” 글에서는 조금 더 나아가서 실제로 오브젝트에 물리식들을 조금씩 적용해 보는 예제들을 확인할 수 있다. 뉴턴의 제2법칙 -
물체의 운동량의 시간에 따른 변화율은 그 물체에 작용하는 힘과 (크기와 방향에 있어서) 같다. -인 F=ma 를 찾아볼 수 있다. 즉 질량 * 가속도 = 힘으로 우리가 알고 있는 내용이다.
실제 중력 가속도 인 0.98을 이용해서 공이 자유낙하 하는 예제를 포함하고 있다.
jsfiddle 예제
jsfiddle 예제를 통해서도 볼 수 있다.
더 관심이 있는 사람은 다른 아티클들을 가지고 더 들여다 볼수도 있다.
이 외에도 블럭체인, OS, Database, 검색엔진 같은 흥미로운 주제들을 생각해 볼 수 있을 것으로 보인다.
조금 더 좋은 개발자가 된다는 일은 어떤 느낌일까? 개인적으로는 조금 더 깊은 본질에 가까워지는 노력을 게을리 하지 않고, 흘러가는 트렌드를 놓치지 않기 위해 노력하지만 천둥 벌거숭이 같은 남자 아이 셋을 키우는 입장에서는 언제나 시간이 부족하다. 하지만 언제나 이런 좋은 리소스들이 넘쳐나는 세상에서 배울것이 무궁무진하다는 것은 고무적인 일이다.
]]>지금 포스팅은 이런 상황에 직면한 개발자들을 위해 쓰여졌다. 하지만 유용할 것이라고 생각한다.
아래와 같은 순서로 포스팅은 진행된다.1
2
3
4
5
6
7
8
9
10
11
12
13- 반응형 웹의 정의
- 반응형 웹의 기술들
1. 픽셀의 정의와 viewport metatag
2. 반응형 레이아웃
2.1. 미디어 쿼리
2.2. 레이아웃 패턴과 중단점
2.3. flexbox
3. 반응형 리소스
3.1. 이미지
3.2. 텍스트
3.3. 폰트(em,rem)
3.3. 반응형 CSS 로딩
4.개발자 도구 툴 활용
반응형 웹(Responsive Web)을 정의할때면 언제난 적응형 웹(Adaptive Web)에 대한 이야기가 같이 나온다.
모바일 환경이 시작되면서 장치도 같이 다양해 지기 시작했다. 해상도의 크기도 다르고 비율이 달라지는 일들이 벌어졌다. 그 전에는 모니터에 맞춰서 1024x768, 1280x960 등의 동일 비율의 크기에 대한 대응만 하면 되던 일들이 아예 비율도 달라지고 해상도는 굉장히 높은데, 모바일 디바이스의 경우는 픽셀의 크기자체가 모니터의 크기랑 비교가 안되게 작아지는 일들이 생겨서 페이지를 설계하는데에 고려할 사항들이 많이 늘어 났다.
이런 상황에 적응할 수 있도록 반응형 웹 기술과 적응형 웹 기술이 탄생했다. 적응형 웹은 기본적으로 서버사이드에서 미리 클라이언트의 정보를 받아서 클라이언트가 모바일인지 웹인지를 파악해서 리소스를 선택해서 내려주는 형태를 이야기한다. 예를 들어 모바일 폰으로 네이버에 접속할 때를 생각해보면 쉽게 이해가 될 것이다. www.naver.com을 쳤지만 모바일 브라우저로 접근하면 m.naver.com로 리다이렉트 하고 렌더링하는 리소스들도 전혀 다르다. www.naver.com 의 크기를 늘였다 줄여도 레이아웃이 전혀 변경되지 않는다.
하지만 반응형 웹은 같은 페이지 리소스를 가지고 오지만 해당 페이지의 크기에 따라서 다르게 보이는 것을 이야기 한다. 하지만 삼성 SDS 사이트의 경우는 브라우저의 사이즈를 줄일 수록 레이아웃 자체가 바뀌는 것을 볼 수 있다.
어떤 것이 더 좋은지는 웹 페이지의 지향점에 따라 다르기 때문에 무엇이 더 좋다고 할 수는 없지만, 모바일 환경에서 반응형 웹 페이지를 고려해야 하는 것은 요즘에는 너무나 당연한 것으로 이야기 되어진다. 왜 그런지 알아보도록 하자.( 심지어 m.naver.com 으로 일단 진입하고 나면 레이아웃이 바뀌는 모습도 발견할 수 있다.)
그렇다면 이 반응형 웹 페이지를 만들기 위해서는 어떤 기술들을 알아야 할까요? 어떤 기술들이 있으면 반응형 웹 페이지를 만들 수 있는지, 모바일과 웹에서 같은 사용자의 경험을 가져갈 수 있는지 알아봅시다.
먼저 픽셀에 대해서 알아보자.
웹페이지를 제작할 때에 대부분의 사이트가 width:600px
같은 형태로 픽셀을 기준으로 페이지를 그리고 있다. 픽셀은 화면을 구성하는 가장 기본이 되는 단위로 보통 Picture Element 혹은 화소라고도 불린다. 이른바 15인치 모니터에 1024x768이라고 하면 모니터의 수평으로 1024개의 픽셀이 수직으로 768개의 픽셀이 배치되어 있다고 보면 된다. 즉 786432개의 픽셀로 이루어진 셈이다.
하지만 모바일 환경에서는 이 픽셀을 그대로 사용하지는 않는다. 왜냐하면 손 안에 들어오는 작은 디스플레이에 같은 픽셀을 기준으로 적용을 할 수 없기 때문이다. 아이폰 3GS 시절만 해도 320x480 같은 저해상도의 디스플레이였기 때문에 대부분의 페이지가 화면을 넘어가는 문제로 해상도를 그대로 사용할 수 없었다면, 현재 갤러시 S9은 1440x2960 과 같은 해상도의 화면이기 때문에 깨알 같이 보이는 어려움이 있다.
이 문제를 처음 깨닫고 해결하려고 덤벼든 것은 당연히 가장 먼저 스마트 폰에서 제대로 된 웹 환경을 제공한 애플이다. 당시에는 지금처럼 사이트를 모바일 사이트로 만들지 않았고 웹 페이지가 기준이었으니까 가상 viewport 개념을 도입했다. 실제로는 320px의 디스플레이를 980px의 viewport를 그린 것이다. 아래 그림을 보면 이해가 더 편할 것으로 보인다. 아래 그림은 애플 개발자 사이트에서 viewport 부분을 캡처한 화면이다. 320px 에서는 다 보이지 않는 페이지들이 980px의 viewport 안에 보이게 브라우저가 작동을 하는 것을 볼 수 있을 것이다.
출처 : 애플 개발자 사이트 - Configuring the Viewport
이 때부터 대부분의 모바일 브라우저의 virtual viewport는 980px로 고정이 되었다. ( virtual viewport는 진짜 해상도가 320px,1440px,1080px등 다양한 장비들이 width는 보시다시피 같은 너비 기준으로 렌더링한다. 모바일 웹페이지의 width height 들을 작성을 할때는 참고하자. )
현재도 그런지 시뮬레이터에서 다음의 소스로 확인해 보자.
1 | var w = Math.max(document.documentElement.clientWidth, window.innerWidth || 0); |
보기와 같은 소스코드로 확인해 보면 최신의 장비도 아래와 같이 980px를 안드로이드와 iOS모두 고수하고 있음을 알 수 있다.
즉 우리가 보는 픽셀은 실제로 장비의 픽셀 너비는 980/(실제 장비의 pixel width) 임을 알수 있다.
그런데, 실제로 모바일 장비의 해상도는 더 커지고 다양해 지는데, 모든 장비에서 사람들에게 편안한 크기의 이미지를 제작하고 폰트를 제공하려면 어떻게 해야 될까? ( 그에 관련된 내용도 출처를 밝힌 위의 링크에서 확인해 볼수 있다. )
일단 데스크 탑 용 네이버 사이트를 980px에서 확인해 보자.
도저히 한눈에 들어오는 가독성은 아니다. 결국 사람이 익숙한 폰트도 12~16px의 폰트가 적당하다고 봤을때, 각각 장비별로 적정한 device-width를 정의하기 시작했고, 아이폰은 처음 시작은 320px를 device-width로 주고 meta 태그에 viewport라는 아래와 같은 옵션을 주면 장비의 가독성이 가장 좋은 viewport를 가지기 시작했다.
1 | <meta name="viewport" content="width=device-width,initial-scale=1.0"> |
최신의 아이폰들은 375px를, Pixel XL은 412px를 viewport로 가지고 있다.
이제 viewport 라는 개념이 헷갈리기 시작할텐데 다음과 같은 원칙으로 정의해 보자.
이해를 돕기 위해 가로 640px 세로 640px의 이미지를 렌더링 하는 코드를 여러 장비에서 한번 확인해 보자. 사용된 시뮬레이터는 왼쪽으로 부터 iPhone X 와 iPhone 6, 그리고 Pixel2 XL과 저해상도 안드로이드 장비다. (저해상도 안드로이드 장비는 아이폰 3GS 시절의 320x400이 동작하는 방식을 재현하기 위해서다. )
일반적인 이미지보기를 할 때
img 태그만 적용해서 확인을 해 보면 640px의 이미지가 출력이 되는데, viewport가 980px 이므로 저해상도 안드로이드 장비말고는 모두 오른쪽에 여백이 남는다. 각 이미지별로 사각무늬의 크기도 제각각이다.
viewport 옵션을 적용한 이미지보기를 할 때
각 장비별로 이미지가 보이는 부분은 다르지만 사각무늬의 크기는 동일하게 나온다. 이것을 이용하면 어떤 장비든지 보기 좋고 동일한 UX를 만들 수 있을 것 같은 확신이 든다.
viewport의 옵션을 더 알아보자.
먼저 페이지에 들어가서 핀치투 줌 같은 사용자의 행동을 막기 위한 옵션을 줄 수 있다. 네이버나 다음 사이트에 들어갔을때 두 손가락으로 줌인 줌아웃이 안되는 것을 볼 수 있을 것이다. viewport를 마음대로 변경하면 서비스 사업자가 원하는 데로 서비스가 제공되지 않을 때 사용한다.
가장 좋은 예는 지도 앱의 경우는 두손으로 확대를 하면 지도가 확대가 되어야 하는데 웹 페이지가 확대되는 걸 본적이 있을 것이다. 이런 경우를 위해서 사용이 된다.
1 | <meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no"> |
여기서 device-width이외에 추가된 부분들이 그 역할을 하는데, 최초의 scale을 기준으로 사용자가 임의로 스케일을 변경할 수 없음을 이야기 한다. scale은 각 장비의 가장 가독성이 높은 device-width의 배율로 정의하면 이해하기 편하다. 즉 0.5로 scale을 바꾸면 Pixel XL2의 경우는 824 픽셀이 나온다.(414/0.5)
이상의 내용을 잘 이해하면 앞으로 나올 반응형 레이아웃과 미디어쿼리등의 상황을 잘 적응할 수 있을 것으로 보인다.
참고로 landscape(핸드폰을 옆으로 뉘였을때)일 때도 980px가 기본 viewport width 이다. meta-tag 설정을 하면 어떻게 되는지는 각자 확인을 해보자. 안드로이드 에뮬레이터에서 데스크 탑의 localhost 를 접속하려면 10.0.2.2를 사용하는 것도 이번 포스팅을 알면서 알게된 좋은 성과다.
이번 포스팅을 통해서 기하급수적으로 늘어나는 모바일 디바이스에서 화면을 어떻게 적응 시키기 위한 노력들을 했는지 알아보았고 그에대한 대답으로 가상 뷰포트라는 것이 존재한다는 것과 실제 여러 디비이스에서 동일하게 폰트와 이미지 크기를 나오게 하기 위해서 viewport와 scale=1.0 옵션을 가지고 있다는 것을 알게 되었다. 이후에는 반응형 웹을 어떻게 만들 것인지에 대한 실체에 조금더 접근해 보자.
이어지는 포스팅에는 반응형 레이아웃에 대해서 알아보도록 하겠다.
]]>‘상식 밖의 경제학’의 저자이며, 행동경제학의 석학으로 알려진 듀크대의 댄 애리얼리 교수의 연구팀이 아주 재미있는 실험[^1]을 했습니다.
* 애리얼리 교수는 효율성보다는 의미가 중요하다고 주장한다
레고를 조립하는 두 개의 그룹으로 피실험자들을 나눈 후에, 첫번째 실험 참가자들은 하나의 로봇 레고를 조립하고 나면, 다른 종류의 로봇을 제공받게 했습니다. 그리고, 그들은 계속 로봇을 만들게 했는데요. 완성된 로봇 레고는 피실험자들 앞에 진열하도록 했습니다. 두번째 참가자들은 첫번째 그룹과 달리 동일한 종류의 로봇을 계속 제공받았습니다. 그리고, 그들이 하나를 완성하면 그들이 보는 앞에서 완성된 로봇은 분해되도록 했습니다.
두 실험그룹은 완성된 로봇 숫자만큼 똑같이 금전적 보상을 받도록 했죠. 그리고, 참가자들은 본인 의사에 따라 로봇을 만드는 것을 언제든 그만 둘 수 있었습니다.
일반적으로 생각해보면 두번째 실험군은 동일한 로봇만 계속 만들기 때문에, 만드는 속도도 빨라지고 더 많은 보상을 받을 수 있을 거라고 예상할 수 있죠. 그렇지만, 정반대의 결과가 나왔습니다. 첫번째 그룹은 평균 10.6대를 완성하고 14.4달러의 보상을 받은 반면, 두번째 그룹은 7.2대를 완성하고, 11.5달러 밖에 받지 못했습니다.
애리얼리 교수는 인간의 노동에 대한 금전적 보상만으로는 동기를 부여할 수 없고, 무언가를 성취하는 과정에서 의미를 찾는게 인간이라고 이유를 들었습니다. 두번째 실험그룹은 끝없이 돌을 옮겨야만 했던 시지프스와 같은 굴레에 갖혀버리게 되었고, 낮은 생산성을 보일 수 밖에 없었던 것이라고 말입니다. 결국, 높은 금전적 보상은 생산성과는 관련이 없다고 봐도 될 거에요.
그렇다면, 인간을 몰입하게 하고, 생산성을 높이기 위한 가장 효과적인 방법은 무엇일까요?
이미 애리얼리 교수가 언급했지만, 인간은 성취감을 얻고, 존재의 의미를 찾을 수 있을 때 그 순간에 집중하게 됩니다.
심지어, 인간은 무언가를 먹을 때도 왜 이것을 메뉴를 선택했고, 어떤 속도로 먹어야 하는가에도 의미를 부여합니다. 등산을 가서 등반 코스를 정할 때에도, 마트에서 라면 하나를 고르면서도 전부 의미없는 선택이란 없다는 걸 떠올려 보세요. 어떤 선택이 내 몸에 도움을 주는가, 어떤 메뉴를 선택해야 같이 식사하는 이 사람과 대화의 물꼬를 틀 수 있을까하는 고민들을 하거든요. 결국 사람은 자신의 무언가 선택을 하고, 실행을 해서 성취해내는 과정 속에서 존재의 의미를 찾습니다. (물론, 다른 방법을 통해 존재의 의미를 찾지 못한다는 것은 아닙니다.) 그 과정의 결과가 바로 몰입이며 생산성의 향상일 뿐이죠.
모든 회사들이 근래에 겪고 있는 가장 심각한 문제는 지속적으로 떨어지고 있는 직원들의 업무 몰입도입니다. 특정 부서의 문제가 아니라 전세계적으로 형편없는 수준으로 떨어졌다는 연구가 계속 보고되고 있죠. 이미 미국 직장인의 2/3는 업무에 집중하지 못하고, 다른 동료들의 업무에 방해가 되거나 동료들과의 관계도 좋지 않은 만성 피로상태에 있다고 합니다. 이런 현상은 미국의 정치/경제의 변화의 속도가 너무 빨라졌고, 높아진 불확실성이 개인들을 위축시키며 최악의 스트레스에 시달리게 만든 것이 원인이라고 미국 심리학회[^2]는 분석했습니다. 우리나라의 경우도 다르지 않습니다. 실업자 200만, 정리해고, 떨어지는 경제 성장률, 50년간 이어져 온 북한의 안보위협까지 만성화된 스트레스에 살고 있으니까요.
거기에 더해서 저성장 시대의 기업들은 더 높은 매출과 성장, 시장의 확대가 직원들의 성장과 따로 생각할 수 없는 것이라고 주장합니다. (회사는 또 하나의 가족이라는 개념은 심각한 오류다.) 어떤 기업은 ‘회사의 비전과 개인의 비전이 일치해야만 높은 성과를 이뤄낸다’며, 개인들의 앞으로의 업무 비전을 적어서 제출하라고 하기까지 합니다. 앞에서도 언급한 것처럼 개인에게 의미없는 목표를 강제로 주입한다고 해서, 그것이 달성되는 것도 아니며 생산성이 높아지지도 않습니다.
더군다나 분기/반기별로 이어지는 성과 평가는 개인을 생산성 측정의 대상으로 밖에 보지 않고, 직원의 겪고 있는 스트레스에 대해서는 외면하고 개인의 책임으로 돌리는 경우가 많습니다. 이러다보니 직원들은 ‘회사’라는 장소가 불행의 근원이며, 무언가 성취하기 위해 일하는 것이 아니라 의무감으로 ‘해야 할 일만’ 하게 되는 악순환을 겪게 됩니다.
그럼, 이 불행한 공간인 ‘회사’를 행복한 공간으로 바꾸는 방법은 없을까요?
시스코(Cisco)는 전세계의 네트워크를 책임지고 있다고 해도 과언이 아닌 회사죠. 그런데, 시스코의 제품과 기술력보다 더 주목할 부분은 엄청난 횟수의 M&A를 통해 성장해 왔다는 겁니다. (한 해 동안 23건의 인수합병을 했던 적도 있다.) 대부분의 회사들이 M&A후에 인수 업체의 인력이 회사를 떠나거나, 조직간 불화로 인해 실패하는 경우가 많습니다. 그렇지만, 시스코는 M&A 사례는 대부분 성공적이었고, 놀라운 것은 실리콘밸리의 평균 이직률이 30%이고, 인수합병된 회사들은 33%의 직원이 1년 이내 회사를 떠나는데 비해, 시스코의 평균 이직률은 가장 높았던 경우에도 10%를 넘지 않았고, 인수합병된 기업의 종업원의 평균 이직률은 2% 정도에 불과했던 것이죠. [^3]
이것은 시스코가 떠나고 싶지 않은 직장이라는 것, 인수합병된 회사의 인력들이 지속적으로 존재 가치를 찾을 수 있는 일을 사내에서 수행할 수 있었다는 걸 의미합니다. 실제로 시스코의 인수합병 과정은 상당히 신속하게 이뤄지는데, 이는 인수대상 기업 직원들의 불안감을 없애고, 이들에게 주어진 새로운 비전을 재빨리 인식시키기 위한 것이기도 합니다. 시스코의 교육 프로그램, 복지와 관련된 이야기는 따로 드리지 않아도 될 겁니다. 시스코의 모든 전략의 핵심에는 ‘사람’이 있다고들 하니까요.
IT업계에서 낮은 이직률을 보이는게 쉽지 않은 일인 만큼, 지인 추천 입사율이 90%에 달하는 회사가 있다는 것도 말이 안되는데요. ‘카카오’가 그 어려운 걸 해냈습니다. 카카오 임직원들의 근무만족도는 대기업 평균보다도 월등히 높고, 업계 평균의 2배에 가깝습니다. 카카오의 개발자들이 언급하는 카카오의 장점은 ‘수평적인 커뮤니케이션’과 ‘성장가능성’ 등 여러가지가 있지만, 가장 중요한 점은 회사에 출근하는 것이 ‘재미’있다는 것, 무언가 새로운 일이 일어날 것을 ‘기대’하게 되는 것일 겁니다.
/* 재밌게 일한다니, 그런 회사가 존재한다면 게임 회사 밖에 없다고 생각했다. (출처:카카오)
IT기업이 가진 가장 큰 장점은 조직이 상대적으로 젊다는 겁니다. 시장과 기술이 변하는 속도에 맞추려면, 기업문화 또한 유연하게 움직이지 않을 수 없죠. 그래서, 카카오는 다음과 합병 이후에 TF를 구성해 10개의 일하는 원칙을 만들었습니다.
/* 카카오의 ‘일하는 방식’을 보면, 신뢰를 기반으로 충돌해도 된다고 말한다.(출처:카카오)
여기에는 직급과 직책을 떠나 수평적인 관계, 협업하는 방법, 그리고, 서로의 성장을 독려하기 위한 카카오의 핵심가치가 녹아있습니다. 물론, 어떤 면에서 수평적인 조직은 의사결정이 느려지고, 문제 해결에 오랜 시간이 걸릴 수도 있습니다. 그렇지만, 카카오는 서로의 다름을 인정하고, 뜨겁게 토론하는 문화 속에서 직원 개인이 단순한 부품이 아니라 ‘존재 가치’가 있는 구성원인 것을 인식하도록 하고 있습니다.
IT회사에서 누군가 내가 작성한 코드에 대해 비평하는 것을 들었을 때, ‘분노’가 1차적인 감정으로 느껴지는 회사가 있고, ‘감사’의 마음이 먼저드는 회사가 있습니다. 당연히 카카오에서는 서로를 성장시켜주는 ‘감사’가 바탕에 있다고 생각이 들어요. 매일매일 출근하면 내가 만든 것을 누군가에게 보여주고 싶다면, 얼마나 출근이 즐거운 일일까요? 그리고, 내가 만든 SW가 조립된 레고 로봇들처럼 고객들의 눈 앞에 있다는 것만큼 행복한 일이 없을 겁니다.
그리고, 최악의 IT회사는 내가 작성한 코드에 대해 어느 누구도 관심도 없는 곳이죠. 이런 곳에서는 형식적인 검토 과정만 존재할 뿐, 결함은 없지만 부족한 기능의 코드는 어느새 완성된 SW의 일부가 되어있게 되겠죠.
카카오처럼 다양한 시도를 통해 행복한 개발자들을 만들어 나가는 IT회사가 많아지길 바래봅니다. 다시 한 번 말씀드리지만, IT기업의 핵심은 ‘사람’입니다.
[^1]: 댄 애리얼리 교수 테드 강연
[^2]: 미국 심리학회는 미국인들의 스트레스는 불확실한 국가의 미래 때문일 거라고도 분석한다.
[^3]: How to Think Like the World’s Greatest Masters of M&A,McGraw-Hill Inc, NY, 2001
]]>Facebook이나 Google과 같은 글로벌 IT기업 뿐만 아니라 작은 규모의 스타트업일지라도 자신만의 특색을 갖춘 기업문화를 갖고 있습니다. 예를 들면 출퇴근이 자유롭거나, 재택근무를 선택할 수도 있고, 자신이 원하는 프로젝트팀을 지원해서 업무를 선택할 수 있기도 합니다. 물론 기업의 제품이나 서비스, 혹은 사회기여(CSR)가 기업문화의 일부를 보여줄 수도 있습니다. 그렇지만, 기업문화의 본체는 채용되는 과정부터 업무 배정, 근무 환경과 협업, 역량개발, 평과, 승진, 퇴직에 이르는 이 모든 LifeCycle에서 드러나게 됩니다.
특히, IT기업에서 HR이 기업문화의 대변자로 가장 중요하게 여겨지는 이유는 ‘설비’와 ‘자재’, ‘품질’ 등이 중요시되는 제조업과 달리 ‘사람’이 차별화되는 기술역량의 실체이고, 제품과 서비스를 만들어내는 살아있는 설비이기 때문입니다. 이것에 대한 근거는 대기업들이 M&A를 통해 스타트업을 인수했다가, 핵심 인력들이 이탈한 이후에 관련 사업을 포기했던 사례들을 통해 알 수 있습니다. 서로 다른 문화를 가진 조직이 합쳐지는 것은 쉬운 일이 아니죠. , 개성이 강한 개발자들을 이해하지 못하는 채용담당자, 글로벌 협업체계와 Agile이 중요시 되는 개발 프로세스를 모르는 근무환경 담당자, 상대평가와 금전적인 인센티브만으로 동기를 부여하겠다는 평가담당자까지… HR이 제대로 동작하지 않는 IT기업은 사업 규모와 역량을 키워나갈 기회를 알아서 포기하는 것과 다름 없다는 얘기가 여기서 나오는 겁니다.
HR이 회사의 미래의 발목을 잡는 것은 이제 IT기업만의 일은 아닌 시대가 되긴 했지만 말입니다.
왜냐구요? 이제 금융회사도 자기들은 IT회사이고, 의료기기제조회사도 자신들은 Tech 기업이고, 커피만드는 회사도 지식기반회사라고 이야기하고 있으니 말입니다.
글로벌 금융그룹인 ING는 ‘ING’s Agile Transformation’ 의 매킨지 리포트를 통해서 볼 수 있는 것처럼, 2015년 본사 직원 3,500명을 중심으로 조직을 Agile하게 변화시키기 위한 혁신활동을 추진했습니다. ING는 ‘금융 기반의 IT기술회사’가 자신들이 가야 할 방향임을 알았고, 이어 Google이나 Netfilx, Spotify와 같은 IT기업을 방문/벤치마킹하고 나서 큰 충격을 받았습니다. Google의 같이 일할 사람을 직접 선택하고 거부할 수 있는 Peer-to-Peer 채용방식부터 부서간의 커뮤니케이션 단절이 없이 협업할 수 있는 문화, 2~3주만에 측정되고 변경되는 목표관리방법을 보면서, IT조직을 시작으로 전사적인 변화가 필요하다는 걸 실감했죠. 그래서, ING는 전체 직원을 대상으로 Agile한 변화에 대해 알리고, Tribe와 Squad로 구성된 조직으로 변화했습니다. 실제 이 변화과정에서 모든 직원들에게 새로운 직무를 선택할 수 있도록 했고, 40%의 인력이 새로운 업무를 담당하게 되었습니다. 그리고, 물론 변화의 속도를 따라오지 못한 직원들은 회사를 떠나기도 했을 겁니다. 이런 변화를 통해서 ING는 새로운 상품 출시의 시기를 획기적으로 단축했고, 분기 단위로 회사의 전략방향을 신속하게 바꿀 수 있는 체계를 만들었습니다.
우리가 여기서 주목할 점은 왜 전통적인 기업이 Agile을 적용할까 하는 점이 아니라, 왜 조직의 구성부터 바꾸었는가 하는 점입니다. Agile의 핵심은 지속적인 개선과 측정을 위한 프로세스가 아니라, Agile의 철학과 가치관을 이해하는데서 시작합니다. 새로운 시도와 실패가 장려되고, 문제 해결을 위한 협업이 일상화되어야 합니다. 그러기 위해서는 결국 ‘조직’이 바뀌어야 할 수 밖엔 없습니다. 그런데, 문제는 조직을 바꾼다 해도 ‘조직문화’가 이것을 뒷받침해주지 못하면 ‘자리바꿈’ 밖에는 될 수 없죠. 그래서, ING는 Agile 문화를 이해하지 못하는 본사 직원들을 내보낼 수 밖에 없었던 겁니다. 결정적인 이유 중의 하나는 Agile한 프로세스는 1~2주 안에도 새로운 의사결정과 실패 공유, 신규 투자 등이 빈번히 일어나고, 비즈니스상 중요한 의사결정도 반 년 이상 걸리던 것이 1달도 안되어 진행될 수 있습니다. 그런데, HR은 기본적으로 채용제도 변화는 3년 단위로, 새로운 인센티브 제도는 2년 단위로 변경되고 가장 짧은 프로세스 혁신활동도 1년 미만의 활동은 찾아보기 어렵죠. 조직의 Agile한 변화를 HR은 전혀 따라오지 못하는 겁니다.
그래서, HR이 ‘조직문화’를 대변하고, HR이 IT기업의 핵심경쟁력이 되어야함에도 불구하고, HR은 결국 조직 전체의 혁신의 발목을 잡게 되는 겁니다.
]]>누구나 한 번은 들어봄직한 중소기업 브랜드가 있죠.
내용물이 새어나오지 않는 밀폐용기 브랜드인 락앤락, 내구성 강한 다이아몬드 코팅으로 유명한 주방기구 브랜드 해피콜 말입니다. 최근 홈쇼핑 채널을 보면, 이 제품들이 해외 주방기구 전시회의 메인 부스를 차지하고 있는 장면들도 심심찮게 볼 수 있습니다.
이와 같이 훌륭한 제품 기술력을 보유하고 있는 국내 중소기업들이 글로벌 시장에서도 성공할 수 있었던 이면에는 CJ오쇼핑의 상생 전략이 숨어있던 것 알고 계신가요?
* CJ 오쇼핑이 해외 Hit 상품으로성공시킨 중소 브랜드 (출처 : CJ오쇼핑)
CJ오쇼핑은 자사 홈쇼핑 플랫폼이 진출해 있는 지역에 글로벌 상품 소싱 자회사인 CJ IMC를 설립, 2004년부터 우수 중소기업 상품의 해외 진출(중국, 베트남, 일본 등 11개국)을 지원해 왔습니다. 협력사의 상품이 해외진출을 하고자 하는 경우 수출, 통관들의 무역실무를 지원하는 방식이죠. 이를 위해 CJ오쇼핑 본사에서는 동반성장사무국을 통해 우수 중소브랜드를 지속 발굴하고 있습니다. 심지어 우수 농가와 중소기업을 대상으로는 수수료를 받지 않고, TV방송을 진행하여 국내 판로를 개척해 주기도 합니다.
이런 활동은 일반적으로 재능 기부나 임직원들의 불우이웃 돕기와 같은 기업의 사회적 책임(CSR, Corporate Social Responsibility) 활동과는 성격이 다소 다릅니다. CSR은 기업이 벌어들인 이익을 사회에 환원한다는 의미로 ‘자선활동’으로 인식되는 경향이 있죠. 그런 반면, CJ오쇼핑의 중소기업과의 동반 성장/상생 프로그램은 우수한 상품을 발굴하여 판매를 촉진, 매출 증가와 브랜드를 글로벌 쇼핑 플랫폼으로 성장시키는 투입대비 사회/경제적 가치를 동시에 높여주는 경영전략이라고 볼 수 있습니다.
CJ오쇼핑의 이런 경영전략을 설명해주는 경제용어가 있습니다.
공유가치창출(CSV, Creating Shared Value)는 경제/사회적 조건을 개선시키면서 동시에 비즈니스 핵심 경쟁력을 강화하는 일견의 기업 정책/경영활동을 말합니다. (출처 :Wiki), 2006년 하버드 비즈니스 리뷰를 통해 마이클 포터가 발표하면서 등장한 이 개념은 이미 많은 기업들이 적극적으로 실행하고 있는 전략이기도 합니다.
기업의 사회적 책임만을 다루는 CSR과 CSV는 ‘비즈니스와의 관련성’이 있느냐 없느냐가 가장 큰 차이점입니다. CSR은 사회적 공감대를 기반으로 하는 자선활동과 캠페인 등으로, 확장된 개념으로는 기업이 진출하고 있는 시장에서 발생하는 사회문제와 이슈를 해결하는데 초점을 맞추고 있습니다. 더구나, CSR은 기부/후원을 위한 한정적인 예산 내에서 이뤄지고, 때로는 여론과 사회 정서의 문제로 기업활동을 오히려 위축시키는 등 제약이 많았습니다.
그러나, CSV는 기업의 경쟁력을 강화시키고, 사회적 가치를 더 높이는 활동을 결합하는 방법입니다. 마이클 포터는 논문에서 공정무역의 사례를 들어 이 차이를 설명하죠. 가난한 농부가 재배한 농작물을 제 값을 받도록 해주는 공정무역은 CSR 관점에서 빈곤문제를 도와주는 선행이지만, 이것은 제한된 자원을 재분배하는 것일 뿐 파이 자체를 키워주지는 못한다고 이야기 합니다. 반면, CSV는 농법을 개선하고, 농부를 위한 지역단체 협력/지원 체계를 구축하여 줌으로써 지속 가능한 성장과 소득 증가를 담보해주는 것이라고 설명하죠.
* 20년간 780만명의학생을 170개국에서 교육, 엔지니어로 성장시킨 Cisco (출처 : Cisco 홈페이지)
이렇게 기업의 사회적 책임을 다하면서, 전략적인 핵심자원을 확보하는 미래가치를 높인 대표적인 사례로는 Cisco가 있습니다. Cisco의 핵심사업은 네트워크 장비를 다루는 하드웨어부터 가상화/클라우드까지 다양하지만, 글로벌 시장에서 지속적인 성장을 유지하기 위해서 넘어야 할 중요한 문제가 하나 있었습니다. Cisco의 네트워크 장비와 제품/서비스들은 고객이 직접 설치/관리하기에는 전문지식이 필요한 경우가 대부분이었죠. 새로운 시장을 개척하더라도 제품을 판매/관리하는 네트워크 전문가와 엔지니어가 반드시 필요하다는 뜻이었습니다.
이러한 문제의 해답으로 Cisco는 Cisco Networking Academy라는 프로그램을 만듭니다. NGO와 UN산하 기관들과 파트너십을 맺고, 클라우드 서비스 형태로 제공되는 교육 서비스는 전문인력 부족과 신규시장 진출의 두 마리 토끼를 잡는데 최적의 방법이었습니다. 아카데미가 설립되는 지역을 Cisco가 진출하지 못한 곳을 우선적으로 선정하고, 빈곤층 청소년에게 교육을 제공함으로써 잠재시장에 부족한 전문가 양성과 제품 판매/점유율을 높였던 것이죠. 1997년부터 20년간 16개 언어로, 2만명에 달하는 Cisco의 훈련된 강사들이 투입된 이 프로그램은 780만명이 거쳐갔고, 빈곤한 지역사회에 IT전문가로서 안정적인 수입을 가지도록 했습니다.
Cisco의 사례에서 알 수 있는 것처럼, IT기업에게 ‘지식 기반의 역량을 확대하는 CSV’는 주목할 만한 기회가 아닐 수 없습니다. 왜냐하면, 모든 IT서비스와 솔루션의 지상 목표는 기업과 개인에게 없어서는 안되는 필수재로서 비즈니스와 삶의 영역에 자리잡는 것입니다. 그리고, 이 CSV는 자사의 서비스가 개인에겐 중요한 소득의 수단이 되고, 그 역량은 기업과 개인에게 의미있는 자산이 된다는 점에서 IT기업에 딱 들어맞는 것이니까요.
이 모델은 어떤 측면에서는 ‘다단계’와 ‘피라미드’ 마케팅과 다르지 않아 보입니다. 그렇지만, Amway가 뛰어난 품질의 제품을 공급하고, 삶의 수준을 향상시키는 브랜드로 평가받는 것과 같이, 결국 서비스가 제공하는 가치가 평가 결과로 나타나겠죠.
실제로 모든 IT기업에게 이런 CSV에 대한 기회는 열려있습니다.
Adobe가 운영하는 디자인 학교, Google Map이 제공하는 지역전문가 교육 같은 다양한 아이디어가 현실이 된다면 어떨까요? 미래의 직업은 IT플랫폼을 이용하지 않을 수 없을 거란 전망이 많습니다. 심지어 예술가들조차 종이 위가 아닌 화면을 캔버스로 이용하는 것을 거북해 하지 않고 있거든요. IT서비스와 솔루션을 개발하는 단계에서부터 ‘어떻게 하면 우리 서비스가 고객들의 지식 기반 역량을 향상시키고, 필수요소로 자리 잡도록 하는 가치’를 제공할 수 있을지 고민해 보시길 권합니다.
]]>1월 한달간 깃헙에 올라온 프로젝트 중 많은 호응을 얻었던 프로젝트들을 정리해 보았다. 특이하게 디버깅에 관련된 프로젝트들이 많이 올라 왔다. 30 seconds of code 는 매우 유용한 자바스크립트 코드를 확인해 볼 수 있다.
이 중에서 yew라는 rust 기반의 프로젝트를 살펴보자.
yew는 rust 기반의 웹 프레임 워크를 표방하고 있다.
rust 라고 하면 기본적으로 어려운 언어. 파이어폭스의 다음버전 퀀텀의 기반. 혁신적인 속도 등의 키워드로 개발자들에게 알려져 있다. 물론 비슷한 시기에 나와서 더 성공적으로 론칭된 go의 경우는 구글의 버프를 받고 무럭 무럭 개발자 커뮤니티가 성장하고 있다. 그에 비해 rust 는 많이 외면 받아 왔는데 그 이유로는 어려운 문맥과 더불어 타게팅된 어플리케이션을 찾기가 힘들었다.
그 와중에 우리가 들어 봤던 가장 좋은 소식중에 하나는 아마도 servo 일 것이고 그 servo가 차기 파이어 폭스 퀀텀의 핵심이 될 것이다.(아니 이미 서브 프로젝트들은 퀀텀에 장착되기 시작했다.) 그런데 퀀텀은 이미 개발자들 사이에 굉장히 화제가 되었고 속도가 많이 개선되었다는 이야기들이 오가기 시작했다. 다만 이전 플러그인들 호환 문제 때문에 파이어 폭스의 미래는 여전히 밝지 않지만 모두에게 rust === ‘고성능이였지’ 공식의 향수를 일으키기에 충분했다.
그러던 와중에 1월의 프로젝트중에 yew가 눈에 띄었다. 그래서 한 번 살펴 보았는데, 프론트엔트 개발자들에게는 개발에 대한 패러다임을 바꿀 수 있는 어떤 무언가가 보여서 한 번 나눠볼까 한다.
Rust 내부에 DOM 코드를 작성하는 형식은 리액트의 Virtual DOM을 따라 했는데, 컴파일을 하고 서비스가 로딩이 된 후 사이트에 접속을 하면 react 처럼 virtual dom을 만들고 렌더링을 한다.
네트워크를 통해 전송되는 html은 다음과 같다.
1 |
|
하지만 DOM의 경우는 다음 그림처럼 렌더링이 되어 있다.
자바 스크립트는 웹 어셈블리(혹은 Asm.js)로 작성되어서 떨어진다. Asm.js는 브라우저가 이해하기 쉬운 기계어 포맷에 가까운 자바스크립트이고, 웹 어셈블리는 이전에 블로그에서 언급한 적이 있다.
링크 : WebAssembly - hello world 어셈블리를 브라우저에 올려보자
말 그대로 브라우저에서 돌아가는 기계어다.
아무래도 ???! 이게 뭐지? 하는 느낌으로 지금쯤 읽고 있는 독자들이 많으리라.
코드를 보고 이야기 하자.
먼저 TO DO MVC 코드는 다음과 같다. 맞다 . 여러분이 아는 그 To Do MVC 말이다. ToDoMVC
1 | // 중략 |
코드는 생각보다 어렵지 않다. Gorilla 같은 Go의 웹 프레임워크를 처음 볼때와 흡사하다. 다만 다른 부분은 view안에 JSX 처럼 코드 스니펫을 사용한다는 것이다. JSX 처럼 컴포넌트화 하지는 않는 것 같다.
struct는 모델을 정의하고 이벤트를 처리할 함수를 update로 정의한 후에 view 에서 렌더링을 하고 있다. 이렇게 코드를 작성하고 실행을 시키고 나면, 다음과 같이 ToDoMVC 앱이 뜨는 것이다.
이것이 정확히 어떻게 작동하게 되는지 app.js를 알아보자. toggleEdit이라는 이벤트의 아래 코드는 다음과 같이 바뀐다.
이런 극적인 코드가 가능해 지는데에는 cargo-web 이라는 프로젝트가 뒤에 있다.
링크 : cargo web
cargo는 rust 에서 사용되는 패키지 매니저인데 subcommand라는 개념으로 패키지들을 관리한다.
그 중에 이 cargo web이라는 프로젝트가 rust 코드를 asm.js 록은 웹어셈블리로 변환해 주는 역할을 하고 있다.
Mac OS 기준으로 아래와 같은 명령어를 사용해서 설치를 했다.
emscripten 설치
1 | $curl -O https://s3.amazonaws.com/mozilla-games/emscripten/releases/emsdk-portable.tar.gz |
cargo 설치
1 | $curl -sSf https://static.rust-lang.org/rustup.sh | sh |
cargo web 설치
1 | $cargo install cargo-web |
yew 설치
1 | $ cargo install cargo-web |
프로젝트에 데모가 존재한다.
깃으로 클론을 받자1
$ git clone https://github.com/DenisKolodin/yew
프로젝트에 들어가서 해당 샘플폴더(Cargo.toml이 있는 곳)에서 cargo web start를 실행하면 프로젝트가 시작이 된다. 기본포트는 8000번을 사용한다.1
$cargo web start
관련 링크는 다음과 같다.
]]>11월 한달(27일 기준) 가장 핫한 프로젝트 10선
링크 : git-flight-rules
이 프로젝트는 작명도 훌륭하지만 더 훌륭한 것은 내용이다.
예를 들어서 “특정한 리비전으로 파일을 리버트 하고 싶을때에는 어떻게 하지?” 라는 질문 형태의 목록들을 가지고 있다.
(우리가 궁금해 하는 바로 그것! 느낌!)
예를 들어 질문 목록을 확인해 보면 아래 그림과 같다.
해석해 보면
등등으로 실제로 필요한 일상의 개발 노하우가 잘 나타나 있다
물론 한글이 아니라 좀 답답하기는 한데 누군가가 한글로 금방 번역해서 올려 줄 것으로 예상된다.
최근 팀에서 코드리뷰를 하다가 자바스크립트에서 세미콜론(;)을 붙이는것을 표준으로 할 것인지 아니면 붙이지 않는 것을 표준으로 할 것인지에 대한 논쟁이 일어났다.
당연히 최근에 나온것이 세미콜론이 없어도 해석할 수 있다이므로 없애는 것에 한표를 던졌는데, 지지를 철회해야 할 지도 모르겠다.
이 프로젝트는 Node.js 의 BP들을 잘 모아둔 curation 사이트다.
많은 사람들이 Node.js에서 신경써야할 아키텍처와 패턴을 잘 몰라하는데 이 프로젝트는 꽤나 많은 해답을 줄 수 있을 것으로 보인다.
예를 들어 1.3의 “공용(common) 으로 사용하는 자바스크립트는 npm package로 만들어라” 부분 같은 것은 Node 패키지의 기본 컨셉을 담고 있고 2.1의 “에러 핸들링은 Async와 Await을 사용해라” 같은 부분도 최근 코드리뷰를 하면서 팀원들 끼리 옥신 각신 했던 부분인데 왜 그렇게 해야하는지도 잘 설명하고 있는것이 포인트.
(콜백 에러 핸들링이 콜백지옥으로 빠지는 것을 Async와 Await을 사용하면 잘 해결 되는 것을 이야기 하고 있음.)
chartJS 가 아님. 다른 프로젝트에 디펜던시가 없는 간단한 차트 프로젝트.
프로젝트를 찬찬히 들여다 보면 깃헙의 히트맵과 프로그레스 바를 만들어 둔 것이 인상적이다. 관련 블로그에도 해당 내용이 적혀 있을 정도.
프로젝트 링크 : charts 깃헙
블로그 링크 : so we decided to create our own charts
블로그를 읽다가 보면 c3.js를 사용하다가 스타을 새로 준다던지, 새로운 고객들의 요구에 응하려다가 자체적으로 개발하기로 한 과정들이 나와 있고 DOM을 조작하는데 SnapSVG 나 jquery 없이 만들기 위해 어떤 고려들을 했는지, CSS3 대신에 고려할 것드을 어떻게 확인했는지 등의 이야기가 재미있게 기술되어 있다.
( 블로그가 훨씬 흥미로운 내용이 많은 듯 .)
jquery를 바닐라도 대체할 때 참조할 수 있는 You might not need jQuery
라는 사이트도 참조할 만하다. ( 하지만 사이트를 보다보면 jquery 없이 어떻게 개발하지? 라는 생각이 들지도…)
타임스탬프 혹은 Date 라이브러리는 언제나 어렵다. 특히 MSA 같은 이기종간의 데이터를 주고 받는 요즘에 점점 중요해 지지만 매번 어렵기는 마찬가지.
이 문제를 해결하기 위한 가장 스마트한 방법은 그동안 모멘트 프로젝트 였는데, 오픈 소스 내부 컨트리뷰터 중에서 모멘트의 구조를 바꾸려고 하다가 프로젝트를 새로 만들었는데 사람들의 주목을 많이 받았습니다.
링크1: 모멘트 프로젝트
링크2: luxon 프로젝트
몇가지 눈에 띄는 다른 점을 코드를 통해 살펴보자.
가장 눈에 띄는 변화는 immutable 의 적용이다.
(immutable 이란 객체의 값이 변경되지 않는 것을 의미 하는 것으로 map 같은 객체가 변경이 되는 코드가 들어가면 리턴 값으로 새로운 객체를 반환해 주는 특징을 가지고 있다.)
immutable.js 가 가장 대표적인 라이브러리이다.
일단 모멘트의 코드부터 살펴보자
|
|
1시간을 더 했지만 m1 과 m2의 값이 같다니.
immutable 을 적용한 luxon의 코드는 다음과 같다.
|
|
그 외의 주요 변화는 다음과 같다.
참고 : 모멘트 개발자가 알아둬야할 부분.
이번에 커버 되지는 않았지만 딥러닝쪽 tensorflow 와 state of art 시리즈를 볼 때 지속적으로 딥러닝 프레임워크 쪽은 들여다 볼 필요가 있을 것으로 생각이 들고 여전히 프론트 엔드쪽은 강세인데 vue.js 가 깃헙 프로젝트의 순위도 점점 평정해 가는 느낌이 강하다. 추세선으로는 react 를 조만간 뛰어넘을 기세로 보인다. 그리고 현장에서는 이미 vue가 통일을 하는 분위기로 보인다. 아직은 중요한 프로젝트들은 react로 의사 결정이 나지만 내년 하반기에는 바뀌지 않을까?
]]>지금까지는 금수저로 살아서 성능테스트는 로드런너 밖에 안써봤어요..
내가 만든 프로그램이 얼마나 잘 버틸까 궁금하잖아요?
내가 아는 공짜 툴은 JMeter 밖에 없었는데 뭐 이것저것 많이 있네요..
작년에는 grinder를 좀 쓰게 좋게 만든 nGrinder로 했었대요
그러다가 혜규샘이http://whatsup.nhnent.com/ne/board/viewByMeta/468/154980#null이런걸 알려줬어요.
이름부터 겁나 멋지네여 게를링이라니!!!
다른거 다 필요 없고 이름이 짱 멋지니까 알아보기로 해요..
게를링은 완전 심플해요
뭘 쏠지 정하고 (recorder.sh)
쏘면 됩니다. (gatling.sh)
세상 심플..
설치하면 실행파일이 딱 두개밖에 없어여
레코딩도 따는 것도 제공해줘요!
방식은 recorder.sh를 실행시키면 얘가 프록시 서버를 8000 번 포트로 띄우고 브라우저에서 프록시 통해서 http 리퀘스트 보내면 그걸 레코딩 하는 방식이에요
./recorder.sh 실행
package는 이거 별로 시나리오 파일을 별도로 떨궈서 꼭 쓰는게 좋아요
No Static Resources 선택하면 static한 애들은 빼고 스크립트 딸 수 있어요
start! 누르면 프록시 서버가 떠요
로컬 네트워크 설정에서 프록시를 설정해도 되지만 우리는 브라우저만 프록시를 태워도 돼요.
브라우저 요청만 스크립트로 딸꺼니까여
Proxy SwitchyOmega라는 플러그인을 설치해요
New profile… 을 누르고
profile이름 정해주고 proxy profile을 새로 만들어요
프록시 서버는 로컬호스트로 하고 개를링 레코딩서버의 프록시 포트를 써줘요
그리고 알파 핑다에 들어가서 이런 저런 작업을 해주면 스크립트가 뙇 떨어집니다.
/user-files/simulations 요기에 패키지 별로 생깁니다.
스크립트는 아래처럼 스칼라 코드로 나오는데요 그냥 줄줄 읽기 나쁘지 않아요..
수정하는 방법은 더 연구해 볼께요..
(중략) val scn = scenario(“RecordedSimulation”) .exec(http(“request_0”) .get(uri1 + “/“) .headers(headers_0)) .pause(1) .exec(http(“request_1”) .options(“/display/sections/3”) .headers(headers_1) .resources(http(“request_2”) .options(“/categories”) .headers(headers_1), http(“request_3”) .options(“/products/search?order.by=POPULAR&order.direction=DESC&pageNumber=1&pageSize=20&hasTotalCount=true”) .headers(headers_1), http(“request_4”) (후략)
걍 ./gatling.sh를 실행하면 어떤 시나리오를 실행해볼껀지 물어보네요
[6] pingda_main.RecordedSimulation 를 선택해 보아요
그리고 시뮬레이션 ID랑 description을 한번 더 입력받고 막 쏘네요
결과를 html로 떨궈주고 nginx에 오렬서 보니까 이쁘게 나오네여
개를링이가 진짜 가벼워서 로컬에서 막 쏴봐도 될 것 같아요.
그런데.. 그랬다가는 혹시나 회사에서 DDOS 돌리냐고 인프라팀에 잡혀갈까봐 서버에서 돌리는 게 좋을 것 같아요…
여러대 서버에서 묶어서도 돌릴 수 있대요.. 그런데 서버는 빵빵하니까 한대에서 쏴도 될 것 같아요
]]>도커로 깃랩을 설치하는 것과 관련된 글은 검색을 하면 수십개가 나오고, 젠킨스와 깃랩을 연동하는 부분도 굉장히 많이 나오지만 도커로 설치된 깃랩과 젠킨스 연동을 위한 중요한 링크가 빠져 있다.
중요한 두가지 설정 포인트가 필요하다.
|
|
이후 git 명령어로 프로젝트를 잘 가져오는지 확인하자.
|
|
링크 : gitlab과 Jenkins연동
위 링크에 대해서 URL을 설정하는 부분만 아래와 같이 바꾸면 잘 해결되는 것을 확인할 수 있다.
이렇게 되고 나면 깃에 자유자재로 업데이트하고 긁어올 수 있음을 알 수 있다. 나머지 CI, CD 옵션은 원하는데로 구성하면 된다.
]]>필자의 경우는 테스트 환경을 꾸밀 수 있지 않을까 하는 기대에 관련된 작업들을 진행해 보았고 관련되어 링크를 남기기도 했다.
링크 : 헤드리스 크롬과 selenium2의 조합을 사용해 보자 with node (http://keen.devpools.kr/2017/06/07/about-test/ )
그런데, 8월 한달 가장 주목받은 프로젝트가 된 이 puppeteer는 Node.js에서 헤드리스 크롬을 사용할 수 있는 API들을 제공하는 것이다. Headless 모드를 발표하자마자 Phantom.JS는 더 이상 개발 안하기로 선언을 한 것과 마찬가지로 Node.js 진영에 새로운 무기가 생겨버린 셈이 되었다
먼저 프로젝트를 한번 만들어 보자.
|
|
이렇게 설치를 하고 나면 프로젝트에 index.js 파일을 만든다..
<코드>index.js
|
|
스크린샷을 가져 오는 코드가 작성되었다. 개발바보들 첫 페이지의 스크린 샷을 가져오는 소스 코드를 작성한 이후에 node index.js 명령어를 입력하면 다음과 같은 이미지를 가지고 오는 것을 볼 수 있다.
기본적으로 지정된 이미지 크기는 800*600으로 지정된 듯 하다. 보통 phantomJS 같은 경우는 스크롤을 다 잡아 가던 초반 모습에 비해 메모리 관리를 위한 것인지 이미지 해상도도 그렇게 좋은 거 같지는 않아 보인다.
PDF로 Export 하는 기능도 API를 통해 구현이 가능하다.
이번엔 find.js 라는 파일을 아래와 같이 만들어 본다. 실제로 이미지와 지금 아래 크롤링 소스는 해당 프로젝트와 내용이 거의 유사하다.
|
|
그 결과는 다음과 같다. 이 과정 중에 어떤 브라우저의 인터렉션도 필요 없었고 (내부적으로는 크롬 헤드리스 브라우저가 작동을 했지만) 사용자의 경우는 결과만 가져올 수 있다.
왜 구글은 이런 제품을 내놓고 있는 걸까? 워낙 혁신적인 기업이라 속내를 다 살펴볼 수는 없지만 지속적으로 API를 내놓고 있는 것은 웹의 많은 부분이 자동화로 돌아설 것이고 그 중심에 인공지능이 있지 않을까 하는 생각이 들어 잠시 한번 고민을 해 보았다. 아마도 텐서플로가 조만간 DOM 기반의 러닝 모델을 공개하는 날이 오지 않을까?
]]>딥러닝은 여러가지 알고리즘을 가지고 있지만 결국 하고자 하는 대부분의 일들이 군집(clustering)과 분류(classification) 라는 관점으로 귀결된다.
그에 따라 AI 기술 스택을 분류하는 방법은 여러가지가 있고 활용되는 분야도 다양하지만 아래와 같이 분류를 해보았다.
먼저 챗봇과 번역등에 사용되는 NLU등을 사용하는 Conversational AI.
두번째는 개와 고양이 구분하기 등에 많이 사용되는 Visual AI 분야.
마지막으로는 전통적으로 진행하던 데이타 분석을 하는 Analytic AI.
Conversational AI 에는 기본적으로 NLU(Naturla Language Understanding)을 그 근간으로 한다. 오픈 소스중에선 Rasa.ai 같은 프레임워크가 존재하고 오픈 서비스로는 wit.ai 와 api.ai 가 있고 제품으로 유명한 것은 IBM의 conversational 엔진이 유명하다. 일반적인 개발자들이 가장 많이 만나는 것은 페이스북을 가지고 챗봇을 한번 만들어보다가 만나게 되는 것이 NLU 와의 처음 만남이 된다고 볼 수 있다. 이 NLU 엔진은 여러가지 기능을 가지는데 기본적으로 전체의 맥락을 판단하고 키워드를 뽑아내는 게 으뜸된 기능인데 이것을 인텐트와 엔터티라는 업계 용어로 지칭한다.
맥락 혹은 화행에는 기본적으로 의도가 들어가 있고 감정이 들어가 있어서 이런 감성을 파악해 내는 데 word2vec doc2vec 같은 툴들이 사용된다. 한글의 경우는 영어와 다른 구조를 가지고 있기 때문에 형태소를 분석해야 하고 mecab-ko 나 은전한잎 같은 툴들이 이용된다.
여기까지는 일반적인 NLU에 대한 이야기만 한 것이고, 챗봇을 위해서는 다이알로그의 룰이 존재하기 마련이라 룰 매니저 혹은 다이알로그 매니저들이 존재한다. 얘룰 들면 페이스북 챗봇을 만들 때 이런 말이 들어오면 이렇게 대답해야지.. 라고 만드는 대화 구성이 그런 역할을 하는 것이다. 이런 다이알로그 개념이 들어가면 한 문장의 문맥이 아닌 전체 문맥을 파악해야하는 기능과 랭킹 시스템을 구축해야 한다.
조금 더 나아가면 보통 STT(Speech To Text), TTS(Text To Speech) 로 알고 있는 음성자동 시스템이랑 연결해서 사용자의 음성을 듣고 텍스트로 변환해 준 뒤에 그것을 구축해 놓은 챗봇 시스템과 연결해 구축하는 작업들이 생겨나고 있다.
얼굴 인식, 피플 카운팅 등에 사용되는 Face Recognition 과 딥러닝 기반의 Object Recognition 은 미디어들을 통해 사람을 인식하거나 장면등을 파악해서 시스템과 연결하는 일들을 할 때 많이 사용된다. 딥러닝 기반 객체 인식은 보통 CNN 알고리즘으로 유명한데 최근에는 여러가지 알고리즘이 더 들어간 경우가 많고 YOLO Darknet 같은 경우는 인식률과 속도에서 다른 범용 툴을 압도한다.
피플 카운팅을 응용하면 히트맵 히트존 등의 기술등으로 확장이 가능하다.
OCR 프로그램은 기존에도 존재했던 것들인 많은데, 딥러닝 기반으로 프로젝트들이 변경되고 있다. 구글 tesseract 도 LSTM 알고리즘의 4.0 버전을 테스트 중이다.
기존의 데이터들을 분석하는 툴 기반이라 딥러닝 보다는 기존 스파크와 하둡 기반의 빅데이터 툴들이 더 많은 일들을 해 주는 부분들이다.
딥러닝은 기본적으로 다층 레이어의 많은 학습을 요구하기 때문에 단순한 계산이 순식간에 많이 일어나는 것을 특징으로 한다. 그렇기에 병렬처리 컴퓨팅이 가장 중요한 핵심기능이 되어서 기존 CPU이외의 다른 대안들이 필요하다.
그런 의미에서 프로세서 유니트(코어) 각각의 성능은 떨어지지만 프로세서 유니트 수가 압도적으로 많은 GPU 가 각광을 받았다. 특히 엔비디아 CUDA (병렬컴퓨팅 플랫폼의 API모델) 의 등장은 프로세서 경쟁에 불을 붙였다.
참조 : http://www.epnc.co.kr/news/articleView.html?idxno=75603
범용 GPU를 이야기 하는 것으로 AI 용으로만 사용될 때는 TPU라는 이름을 쓰기도 한다.(Tensor Processing Unit) NVIDIA의 GPGPU를 극대화 하기 위한 CUDA 기술을 공개했고 동시에 범용 GPU 기능이 주목 받기 시작했다
구글의 딥러닝의 학습속도를 향상시키기 위해 자체 디자인한 반도체 칩셋(ASIC)를 적용되면서 더 각광 받기 시작함. 구글의 ASIC를 TPU(Tensor Processing Unit) 이라 부르고 GPGPU의 범주에 놓기도 한다.
MS는 같은 목적으로 FPGA 칩을 클라우드 데이타 센터에 탑재해 Azure 서비스에도 이용하고 있는데, FPGA는 저전력의 강점도 가지고 있다.
신경구조와 유사한 프로세서가 차후 프로세서로 각광을 받고 있고 IBM 같은 회사들이 준비하고 있다.
링크 : http://www.research.ibm.com/cognitive-computing/neurosynaptic-chips.shtml#fbid=rXQq5aX-WkP
크게 딥러닝 전용 인프라는 클라우드와 판매형 인프라로 나뉘어서 볼 수 있을 것 같은데 기존의 아마존 AWS, 마이크로소프트의 Azure, 구글 클라우드 같은 빅3는 이미 클라우드 인프라를 가지고 있다.
AWS의 경우는 클라우드 AMI(Amazon Machin Image)도 제공하고 있어서 굉장히 편리하게 쓸 수 있다. AMI라는 것은 미리 만들어진 이미지 같은 개념으로 볼 수 있다. NVidia 의 경우는 자사의 GPU를 이용한 클라우드 서비스를 하고 있는 것이 흥미롭다.
판매형 인프라는 기존의 서버 벤더들과 비슷한 형태를 취하고 있는데 웨이브 컴퓨팅은 하나의 모델을 제안하는 데 텐서플로 같은 소프트웨어에 특화되어 만들어져 있다.이에 비해 Penguin computing 은 몇가지 옵션들을 더 제공하고 있다.
딥러닝, 인공지능 등을 바라볼때 탑뷰로 어떤 기술이 있는지를 알아보는 과정을 거치고 있다. 다음 번엔 개발자에게는 가장 중요한 딥러닝 프레임워크들을 다뤄보도록 하겠다.
]]>headless browser는 기본적으로 GUI 없는 웹 브라우저를 의미한다.
“A headless browser is a web browser without a graphical user interface.”
출처 : What is a headless browser?
즉 CLI(Command Line interface)에서만 다루는 브라우저를 이야기 한다.유명한 헤드리스 브라우저로는 phantomJS 가 있다.
헤드리스 브라우저가 사용되는 예는 여러가지가 있는데 좋은 예로는 테스트 자동화를 할 수 있고 데이타를 긁어오기(scraping) 하는 데 사용되고 스크린샷을 뜨는데에도 손쉽게 사용된다. 웹페이지 반응을 자동으로 스크립팅할 수 있는 부분도 존재한다.나쁜 예로는 DDOS 공격을 하는데 사용되기도 하고, 자동화를 좋지 않은데에 쓰이기도 한다는 것이다.
셀레니엄은 태생 자체가 다르다고 보면 된다. 헤드리스 브라우저는 범용적인 목적에 따라 CLI환경에서 브라우저 환경을 에뮬레이션 하는 것이라고 하면 selenium은 브라우저 플러그인을 넣고 테스트를 실행시킨다. 서버 사이드에서 테스트에 관련된 실행을 시킬 수 있는 리모트 컨트롤러가 존재하고 다양한 브라우저를 지원하기 위해 드라이버들을 제공하는데 webdriver 라고 불려진다. 이후 버전이 업데이트 되었다.
클라이언트 서버 구조로 서버 사이드와 RC(Remote Control)로 구성되어 있던 것을 webdriver와 결합하면서 현재의 selenium2가 된 것이다.
즉 CLI 툴로 사용할 수 있는 헤드리스 크롬의 경우는 다양한 브라우저를 테스트의 목적으로 사용해야 하는 범용 테스트 목적 보다는 다른 용도로 많이 사용될 것으로 보인다. DDOS machine?
nightwatch 혹은 webdriverio는 node 환경에서 selenium2를 사용할 수 있게 해 준다. 옵션과 홈페이지, 구글 트렌드를 생각하면 nightwatch를 이용해야겠지만 일단 간단하게 사용하기 위해 webdriver로 실행을 해 보자.(robotframework도 같이 고려)
전역 옵션으로 webdriverio를 아래와 같이 설치한다.(nightwatch의 경우도 같이 진행할 수 있음.)
|
|
selenium2는 다음과 같은 명령으로 내려받을 수 있다.
크롬용 웹드라이버 -chromedriver를 받아서 압축을 풀고 PATH에 적용 시켜 준다.
이 경우는 며칠전만 해도 canary를 쓴다고 했지만 지금은 크롬 최신버전이면 다음의 옵션만으로 실행할 수 있다.(MacOS 의 경우)
아래와 같이 테스트 코드를 작성하고 나면 일단은 selenium2 기반의 테스트 프레임워크의 시작을 했다고 보면 된다.
|
|
해당 소스는 깃헙의 다음 링크에서 받아볼 수 있다.
https://github.com/ehrudxo/headlesssample
.
]]>AI vs Human Brain
최근 급하게 프로젝트에 두달간 투입이 되면서 블로그 포스팅을 할 여유가 전혀 없었다.
좀 반성하는 차에 진행한 프로젝트에서 얻은 인사이트를 공유하고자 한다.
어떤 절대적인 가이드라인은 사실 없기 때문에 마음대로 만들 수는 있고 마음대로 기획할 수는 있지만 많은 경우에 지금 활용할 수 있는 가이드라인들은 존재한다. 이른바 먼저 가본 사람들이 적어 놓은 가이드 라인들이 있다.
여기 가장 유명한 두개의 가이드라인만 소개를 할까 한다.
이 중에서 가장 첫번째 원칙인 인간인척 하지 않는 것. 즉 사용자에게 사람인척 하지 않는 것이 중요한데 사람은 챗봇이라고 생각할 때와 사람이라고 생각할 때에 다르게 행동(입력)하고 기대하는 바도 매우 다르기 때문이다. 그래서 사람이 아닌 챗봇이라 버튼을 활용한다던지 다른 인터페이스에 대한 디자인을 하는 것은 무척이나 중요하다.
사람
디자인 원칙에서 보았듯이 가장 중요한 원칙은 사람에 대한 이해다.
사용자가 어떻게 챗봇을 활용할 지를 이해하지 못하면 서비스가 제대로 쓸모 없는 서비스를 하게 마련이다. 그런 의미에서 아직은 인공지능과 사람의 인터페이스는 투박하다.
사용자가 어떻게 챗봇을 쓸 것인지를 정의하려면 내가 하려는 서비스가 어떤 것인지를 명확하게 정의해야 하고 어떤 기능을 대체를 하려는지를 기획자 혹은 개발자 스스로가 알고 있어야 한다.
사용자들과 인터뷰를 하다보면 정작 사용할 사용자들은 챗봇에게 큰 기대를 하지 않는다. 마치 우리가 시리와 빅스비에게 심드렁한 것 처럼. 하지만 기획단계에서의 기획자와 발안자들은 굉장히 많은 기대를 가지고 프로젝트에 접근한다.
심지어 챗봇을 위한 디자인 원칙들을 읽어 보지도 않고 말이다. 챗봇들이 무엇인가 세상을 바꿀 것 처럼 굉장히 멋진 장표들과 아키텍처들을 보고 있지만 정작 이것이 어떤 문제를 해결할 지 알고 있는 사람은 없다.
개발을 진행하면서 이 프로젝트들이 꽤나 많은 분야의 인력에 대한 감축을 전제로 하고 그런 미래가 바로 닥쳐 있다는 사실을 부정할 수는 없지만 굉장한 청사진 또한 동의할 수 없다. 그래서 현실적이지 않은 요구사항들을 사용자 인터뷰와 가이드라인을 기준으로 다 잘라내고 있지만 의사 결정자들 마저도 굉장한 기대감을 가지고 있다는 사실은 어떻게 보면 슬픈 일이다.
하지만 심지어 페이스북과 같이 작업을 했던 항공 티케팅 분야의 챗봇 담당자는 이렇게 이야기 한다
“아무도 챗봇으로 티켓을 사려고 하지는 않아요.”
우리는 구글이 아니다. 이걸 인정하면 마음은 굉장히 편해지지만 대부분의 어른들(?)은 그걸 인정하기가 아들 딸 성적표보다 어려운 모양이다. 하지만 우리에게도 희망은 있다. 챗봇의 아키텍처에서 인공지능이 차지하는 부분은 우리가 기대하는 부분보다 굉장히 작다. 오히려 룰을 어떻게 만들고 어떻게 처리할 것인가 하는 부분이 훨씬 중요한 문제로 다가오게 된다.
위의 주제의 연속이다. 챗봇의 대부분은 소프트웨어 엔지니어의 영역이다. 그래서 챗봇 엔진을 잘 만들기 위해서는 좋은 엔지니어와 좋은 아키텍트가 당연히 필요하다. 물론 NLU라던지 딥러닝을 잘 하면 할 수록 더욱 좋다. 하지만 좋은 개발만큼 중요한 부분은 없다.
좋은 개발자는 여러가지 복잡하게 얽혀있는 챗봇의 어려움들을 풀어줄 시작과 마지막이다. 점점 인공지능의 세상이 오면 올 수록 사용자의 입장에서 이해하는 개발자가 더 중요해 질 것이다.
이렇게 죽어있는 레거시는 곤란하다
상담이라던지, 견적이라던지 모든 챗봇이 풀고자 하는 문제들은 기존의 시스템이 자리잡고 있다. 그럼 이 레거시들을 어떻게 유기적으로 풀고 어떻게 서비스를 대체할 수 있을까? 마이크로 서비스 아키텍처는 그 중의 좋은 대답이 될 수 있다. 하지만 이것은 만병통치약은 아니다. 가장 중요한 것은 기존 레거시 함수를 묶어주는 표준을 만들어 주는 것이고 그 레거시를 어떻게 접근할지에 대한 해답은 챗봇이 가지고 있어야 한다.
그렇다면 사용자의 자연어와 레거시간의 연계는 어떻게 이루어 질 것인가. 여기에는 기존에 없던 인공지능 분야의 기술이 필요하다.
stay tuned
이 쪽은 지속적으로 계속 발전할 것이다. 그렇다는 것은 지금 발을 들이기에 무척이나 좋은 시기라는 것이다.
아무래도 발전에 대한 틀은 대부분이 갖춰지는 것 같다.
누군가가 기가막힌 사용자 인터페이스를 제시할 것이고 그 때 쯤이면 아직까지는 기대할 것 없는 챗봇 분야의 인공지능도 수준이 많이 올라갈 것이다.
언제나 관심을 기울이고 있어야 한다는 이야기다.
Originally published at 개발바보들.
By Keen Dev on May 30, 2017.
Exported from Medium on May 31, 2017.
]]>기본적으로 Excel내의 분석도구는 비활성화 되어 있습니다. 이 분석도구를 활성화 시키기 위해서는 Excel의 버전에 따라 다른 방법으로 분석모델을 활성화시켜줘야 합니다. 과거의 Office버전에서는 기본적으로 파일메뉴 - 옵션 - (좌측)추가기능메뉴 - 분석도구 - 확인클릭
순으로 분석도구를 활성화할 수 있습니다. 하지만 저는 최신의 Mac용 Office를 사용하기 때문에 다른 경로로 분석도구를 활성화 시켜줘야 합니다. (상단)도구 - 추가기능 - 분석기능 체크 - 확인
이렇게 하면 데이터
탭 우측 상단에 데이터 분석
도구가 있음을 확인할 수 있습니다.
분석도구를 설치했으니, 이제 선형 회귀분석을 위한 데이터를 로드를 합니다. 우리가 작업할 데이터는 중고차의 가격과 킬로수가 함께 나온 데이터로써, 주행거리(Odometer)와 중고차 가격(Price)간 상관관계를 구하고 이를 예측하기 위해 분석을 진행할 것입니다. 상단의 데이터 - 데이터분석
으로 시작합니다. 팝업에 나오는 메뉴중에 Regression(회귀분석)
을 선택합니다.
독립변수 X값과 종속변수 Y값에 대해 해당 셀을 Block지정합니다. 그리고 라벨을 체크합니다.
데이터의 분석결과가 별도의 시트로 추가가 되며, 우리가 분석한 주행거리별 중고차 가격에 대한 분석은 아래와 같습니다. 중요하게 체크해야할 항목에 녹색표시를 해두었습니다.
R Square(설명력)
의 값은 입력한 X값(주행거리)가 Y값(중고값)을 결정하는데 65%의 영향력을 끼친다는 것을 의미합니다. 또한 하단의 Intercept(Y절편)
와 Price항목은 선형 회귀분석 모델의 수식인 Y = aX + b
를 완성하는데 쓰입니다. 이는 차트를 통해 확인을 하도록 합니다.
차트를 추가하려면 차트버튼을 클릭하면 간단하게 차트를 추가할 수 있습니다.
차트의 데이터를 하나 클릭하여 우클릭을 하면 추세선을 추가할 수 있고, 추세선 서식 옵션의 수식을 차트에 표시
를 체크함으로써 분석한 데이터의 선형 회귀분석 모델의 수식을 쉽게 구할 수 있습니다.
분석된 데이타를 통해 도출된 선형 회귀분석 모델의 공식은 “y = -10.433x + 190655”로 쉽게 확인할 수 있습니다.
]]>지난 3월 22일 수요일 오후 늦은 7시, 잠실에 있는 삼성SDS 지하에서는 동회사에 근무하시는 신상재님께서 주관하셨던 코드리뷰관련 Meetup, “제1회 re:View”가 열렸습니다. re:View의 공식사이트, Facebook, Slack, Twiter의 운영과 개인별 문자/메일 발송 등의 멀티채널을 통한 참가자들의 압박(…)은 그 많은 인원이 평일 오후에 참석할 수 있었던 큰 원동력이 된 것 같습니다. 이뿐만 아니라 컨트롤이 힘든 자녀를 둔 맞벌이 개발자와 취업에 고군분투하고 있는 취업준비생을 위한 배려는 그동안 제가 참석한 다양한 Meetup에서는 단 한번도 보지 못한 멋진 운영중 하나였습니다. 이 글을 통해 준비해주셨던 모든 분들께 감사의 말씀을 드립니다.
행사는 1부 서지연님 발표, 2부 김헌기님 발표, 3부 QnA로 구성되어 있었으며 발표중 질문이나 요청은 Slack채널의 운영으로 현장에서 온라인을 통한 참석자들의 참여가 있었습니다.
카카오 서지연님의 사외 발표는 지난 나프다 컨퍼런스를 포함 2번였고 저는 운좋게 그 두번의 발표를 모두 라이브로 들을 수 있었습니다. 나긋나긋하며 또박또박한 발음으로 발표하시는 서지연님의 발표는 내용이 재미있어서 다행이지 따분한 내용의 발표였다면 청중의 수면을 유도하기 참 좋은(…) 목소리인 것 같습니다. 각설하고, 서지연님은 사내에서 경험한 본인의 코드리뷰를 바탕으로 이야기를 풀어나가셨습니다.
내 코드가 부끄럽습니다. 이는 주니어뿐만 아니라 시니어들도 가지고 있는 생각일 것입니다. 보잘것 없는 코드가 타인에 의해 드러나는 것도, 의견을 주고 싶은데 잔소리로 오해 받을까봐 걱정되는 것도, 코드리뷰를 경험해보지 않은 인력들에게는 모두 걱정입니다. 코드리뷰란 코드로 대화하는 팀원간의 커뮤니케이션입니다. 부끄러움은 짧고 코드의 히스토리를 길다는 점을 명심해주세요. 잘못된 코드는 누군가에게 레거시코드가 되어 영원한 고통을 안겨줄 수 있습니다. 덮어놓고 코드를 작성하다 보면 장애의 위협은 항상 우리를 괴롭힐 것입니다.
자칫 잘못하면 꼰대가 될 수 있음에 주의해야지만, 내가 아는 것을 모르는 사람에게 알려주는 것은 잘못된 것이 아닙니다. 이런 상황에서 온라인으로 진행하는 코드리뷰가 가지는 장점이 여기서 드러납니다. 목소리가 아닌 글로 격려와 칭찬을 하면서 진행하면 이러한 오해를 줄이는데 큰 도움이 됩니다. 코드는 본인이 아닙니다. 나에 대한 평가가 아닌 나의 코드에 대한 리뷰를 받는 것임을 생각하며 진행하도록 합니다.
프로젝트 초반에는 모두 코드리뷰에 대한 열정에 어마어마한 리뷰 요청이 들어오게 됩니다. 하지만, 이를 다 받아주면 내가 해야할 일에 병목이 생기고 번아웃이 되기 쉽습니다. 팀원이 요청한 모든 리뷰에 피드백을 줄 필요는 없습니다. 본인의 업무와 조율하며 코드리뷰 실행을 조절하되 정말 하고 싶거나 또는 좋은 의견을 주고 싶은 리뷰라면 나중에 하기로 약속하는 것도 좋은 방법입니다.
코드를 통한 협업에서는 가이드라인(Code Fomatting, Naming Rule 등)이 필수이지만 개발자의 취향은 존중받아야함이 마땅합니다. 리뷰어가 해당 코드에 대한 반대의 의견이 있을때는 요청자를 위해 목소리를 내어줘야하고, 요청자 역시 반대의 의견을 듣는 것을 두려워하지 말아야 합니다. 하지만 타당한 이유로 반박해야할 내용이 있다면, 왜 내가 이렇게 작성을 했는지에 대한 설명을 해줘야합니다. 해당코드에 대한 고민은 내가 가장 많이 했으니까요.
초기에는 코드리뷰리더 역할을 가진 멤버가 필요합니다. 코드리뷰 리더는 반드시 개발을 잘하거나 연차가 높은 사람일 필요가 없습니다. 가장 중요한 자질은 적극적으로 코드리뷰를 참여하고 멤버들을 독려할 수 있는 열정을 소유하는 것입니다. 그 후, 메일이나 Slack을 통한 Notification 환경을 구축하고, 칭찬할 내용에 대해서는 아낌없는 따봉을 팍팍 줌으로써 서로 격려하는 문화를 만들어 나갑니다. 정기적인 오프라인 미팅운영도 큰도움이 됩니다. 아낌없는 격려와 칭찬. 이것은 코드리뷰를 도입하는데 있어 큰 밑거름이 됨을 잊지마시길 바랍니다.
이전에는 본인 개성을 베이스로 자유로운 코드가 가득했던 반면, 코드리뷰를 통해 타인이 볼 것이라는 압박때문이라도 코드를 한번 더 생각해보는 습관이 생깁니다. 이를 위해서는 적절한 협업도구의 사용이 성공유무를 가르게 될 수 있습니다. 다같이 즐겁게 코딩하는 것이 코드리뷰의 궁극적인 목표임을 다시 한번 상기합시다. 꾸준한 코드리뷰를 통해 팀원들과 협업하는 재미가 생기는 것을 자신을 발견할 수 있을 것입니다.
사내 코드리뷰 경험을 공유해 주신 서지연님의 발표에서 그녀가 대한민국에서 얼마나 행복한 개발자인가를 알 수 있었으며, 그와는 별개로 발표용 키노트에 기가 막힌 타이밍에 삽입한 탁월한 짤방이 청중에게 큰 공감을 가져오게한 능력이 돋보인 발표였습니다.
행사를 준비하며 온라인에서 보여주신 신상재님과 김헌기님의 모습은 한때 시대를 풍미했던 서수남과 하청일, 서경석과 이윤석처럼 ‘이런 것이 Meetup을 준비하는 자들의 호흡이다!’를 온몸으로 외치는 듯 했습니다. 더불어, 40대 개발자는 이런 자세를 견지해야 팀내의 젊은 후배들과 활기찬 협업을 할 수 있다라는 것을 30대 후반의 미천한 능력을 지닌 저에게 알려주셨습니다. 김헌기님의 직장생활 기간의 희열차트로 시작한 발표는 깨알같은 아들 자랑을 은근 슬쩍하시더니 본인 회사의 자랑을 본격적으로 대놓고 하시는 모습을 보며, 무언가 심상치 않은 발표가 될 것이라 예상했습니다. 홈쇼핑을 통해 물건을 구매하지 않는 저로써는 GS SHOP이 어떤 회사인지, 어떤 비지니스 물밑에서 하고 있는지 몰랐는데, 이런 오프라인 모임을 통해 커머스 비지니스를 하는 IT회사들은 어떤 환경을 가지고 어떤일을 하고 있는지에 대해 조금이나마 알게 되었습니다. 김헌기님이 발표하신 내용을 좀 정리해보자면…
과거에는 회사가 위험요소가 있는 곳은 애당초 가지 않았는데 이제는 이런 위험요소를 탐지하는 것 자체가 어려워졌습니다. 그래서 민첩함을 키워야했고, 현재는 팀장이 직접 코딩도 하고 사내에서 개발관련 지식을 공유하는 세미나도 주관하는 상황에 이르렀습니다. 이는 변화에 적응하기 위해 현업들과 코드로 대화를 해야하는 것이 필요하다는 것을 몸소 깨달았기 때문입니다. 우리모두 변화에 적응하는 유연성을 기르도록 합시다.
GS eShop에서 사용하는 엔터프라이즈 시스템에는 어마어마한 레거시 코드들이 아직도 있습니다. 자바코드 44000줄, A4로 뽑을 경우 670장이나 되는 거대한 양의 코드입니다. 메소드에 파라메터가 20개 이상인 것도 부지기수이고 또한, 개발 기준없이 개발자들마다 본인의 개성에 맞는 스타일로 작업을 하다보니 상황은 점점 절망적이 되어갔습니다. 이런 절망적인 상황에서 이를 해결하기 위해 내부에서 자발적인 고민을 하기 시작합니다. 더러운 코드로 인해 악순환이 계속되는 구조를 클린코드를 유입시키고 이를 통해 테스트 오류를 감지할 수 있는 선순환구조로 바꾸기 위해…
측정가능한 투명한 품질활동을 위해 관리자와 테스트 전문가가 프레임 워크를 제작하기로 했습니다. Python과 django사용를 사용하여 제작을 했는데 어느 프로젝트나 마찬가지지만 새로운 언어로 개발을 한다는 것은 쉬운일이 아니였습니다. 우리는 방향을 잡을 수 있는 목표와 보여줄수 있는 가치를 현실화 하기 위해 리더/엔지니어/테스트전문가/보안전문가로 구성된 팀을 꾸렸고, 영어 닉네임을 사용했습니다. 꾸준한 리뷰를 통해 잘못된 코드의 작성자는 즉시 담당자에게 호출되었고, 모의해킹/기능테스트/해킹테스트와 같은 품질향상을 위한 작업 역시 꾸준히 이루어졌습니다. 이리하여 배포품질관리시스템 “de:light”가 탄생되었습니다. 하지만 프로세스와 플랫폼으로 살림살이가 바로 나아지지가 않았습니다. 코드리뷰 문화의 확산 필요해졌습니다. 우선 사내커뮤니티 활성화하고 목표는 유지보수 가능한 코딩 기술을 전수하자는 미명하에 다양한 행사나 사내 Meetup/Hackerthon 등을 진행하였습니다. 코드리뷰는 품질개선의 건전한 활동이자 개발문화입니다.
애자일을 시도했지만 우리에게는 이 방식이 불가능 하다고 판단을 하였습니다. 하지만 애자일의 아이템중 취해야 할 것은 과감히 채택하여 적용하였습니다. 특히, 커뮤니케이션 방식의 변화를 위해 주기적으로 업무를 끊고 갈수 있는 스프린트 방식을 도입했습니다. 각자 본인이 한달에 할 수 있는 범위를 정하고 이는 수단과 방법을 가리지 않고 실행하며, 한주의 스프린트 결과를 별거 없거나 아주 작은 내용이라도 팀원들에게 공유해야하는 그라운드룰을 운영했습니다. 이것을 우리가 원하는 상황으로 가고 있지 않을때 플랜B를 갈지 판단할 수 있는 판단의 근거로 작용하게 되었습니다. 관리만 할 줄 아는 사람들이 직접 참여하며 느끼는 것이 있었습니다.
발표전 김헌기님께서는 서지연님과의 발표를 듣고 본인이 속았다라고 볼멘소리로 주최측에 항의하셨으나 발표의 내용을 모두 들어봤을때, 사내외행사를 통한 경험을 토대로 이번 Meetup의 발표을 위해 큰 그림을 그려오셨다는 생각만이 머리속에 맴돌았습니다.
슬랙을 통한 질의가 행사진행중 계속되었는데 많은 분들의 질문, 특히 본인의 업과 관련된… 업무에서 많은 고민을 해왔고 이 자리를 빌어 조언을 구하고 싶은 듯한 날카로운 질문들에 대해 김현기님과 서지연님이 혼을 다해 답변을 해주셨습니다. 슬랙을 통해 올라온 많은 질문들을 시간관계상 답변을 해드리지 못한 것은 발표자나 참가자들에게 모두 아쉬운 점이였다고 생각합니다.
이렇게 평일 오후라는 제한적인 시간에 많은 분들이 모여 코드리뷰라는 주제로 뜻깊은 시간을 가졌습니다. 서지연님과 김헌기님의 성공사례를 보며, 코드리뷰라는 것은 단순히 남의 코드를 다른 사람이 검사해준다는 느낌보다는 개발을 업으로 삼고 있는 사람들의 업무방식을 변화시켜줄 수 있는 문화라는 것을 모두가 공감했을 것입니다. 차기 Meetup에서도 곳곳에 숨어있는 다른 개발자분들의 다양한 경험담을 공유할 수 있길 바래봅니다.
]]>페이지 하단의 페이스북 댓글 창을 추가하기 위해서 해야할 작업은 그리 어렵지 않습니다. 우선 페이스북 개발자 소셜 플러그인 패아자내의 “댓글 플러그인 코드 생성 도구”를 통해 쉽게 코드를 얻어올 수 있습니다. url
항목은 어차피 Liquid태그로 수정을 해야하니 대충 넣고, 너비
는 Responsive한 웹을 위해 100%, 게시물
수는 입맛에 맞게 넣습니다. 저는 default로 되어 있는 ‘5’를 사용했습니다. 3개의 항목을 채우고 해당 서식 바로 아래 있는 코드받기
를 통해 두개의 코드를 받아옵니다.
첫번째의 코드는 페이지내의 `<body>`태그 바로 뒤에 붙이라고 가이드가 되어 있습니다. 그렇다면 우리는 `_layout/default.html`의 `<body>`태그 뒤에 바로 붙여줍니다. 그리고 두번째로 주어지는 페이스북 댓글창으로 사용될 코드인데, 댓글은 각 페이지의 주소마다 다르게 보여집니다. 따라서 `data-href`의 값으로 고정주소를 선언하게 되면 블로그내의 모든 포스팅에서 모두 동일한 페이스북 댓글창을 사용하게 됩니다. 따라서 Liquid문법을 이용하여 현재 페이지의 url을 동적으로 생성하고 이렇게 만든 두번째 html코드를 `_include/post.html`에사용하도록 합니다.<figure class="highlight"><pre>`<span class="nt"><div</span> <span class="na">class=</span><span class="s">"fb-comments"</span> <span class="na">data-href=</span><span class="s">{{ site.url | append: page.url }}</span> <span class="na">width=</span><span class="s">"100%"</span> <span class="na">data-numposts=</span><span class="s">"5"</span> <span class="nt">></div></span>
웹에서의 페이스북 소셜플러그인 댓글 기능의 사용은 별도의 App-id가 필요없이 현재 포스트에 대한 url을 해당 data-href
에 어떻게 지정할지만 고민을 하면 아주 손쉽게 붙일 수 있습니다.
TBD
]]>9시 부터 등록시작이라고 했지만, 이미 등록을 시작하고 있었고 몇몇 분들이 파트너사의 홍보 부스를 구경하면서 사은품을 받아가고 있었습니다. ( 저도 역시.. 행사의 꽃은 사은품이니까요. )
색연필과 응급처치킷, ( 행사의 꽃인 ) 티셔츠를 받았습니다. 보통 반팔을 주시는 데, 특이하게 긴팔 티를 주셨습니다. 그리고 사진에는 없지만, 에코백, 수첩, 아마존 용어집 핸드북, 그리고 엄청나게 커다란 안경 닦는 수건도 받았습니다. ( 위 사진에 있는 마이보틀은 행사 종료후 아마존에서 참가기념으로 나눠준 사은품입니다) 잠시 사은품에 홀렸던 정신을 바로 잡고 행사 등록하고 참가 확인 배지를 받았습니다.
9시 40분부터 입장이 시작된다고 했지만, 20분 전부터 입구에는 입장하려는 사람들이 줄을 서기 시작했으며, 입장이 시작되고 나서 빠르게 자리가 사라졌습니다. 나중에는 자리가 없어서 서서 계시는 분들도 계셨습니다. 발표장은 많은 참가자를 대상으로 하고 있어서 세군데에 대형 스크린이 설치되어 있었습니다. 주위를 둘러보니 저같이 개발자로 보이는 분 계시고, 대학생으로 보이는 분, 나이 지긋하신 아키텍쳐 또는 사장님으로 보이는 분도 계셨고 아직 많이 어려보이는 중,고등학생으로 보이는 분들도 종종 눈에 띠었습니다.
AWSomeDay는 아마존 웹서비스의 다양한 기능과 기본적인 서비스의 사용법을 익히는 수업인 “AWS 기술 에센셜” 과정과 동일한 내용이라는 설명으로 시작했습니다. 물론 참가 인원이 많아서 실습은 진행하지 않고, 강사분과 질의응답을 할 기회가 거의 없기 때문에 위 정규과정과는 차이가 있다고 합니다.
10시 부터 시작된 오전 세션에서는 AWS를 사용하는 주요 기업의 사례와 AWS의 인프라과 신규 기능을 소개하는 기조연설을 시작으로 아마존의 대표 서비스인 EC2( Elastic Compute Cloud )와 오프젝트 스토리지 서비스인 S3( Simple Storage Service )에 대한 사용법, 기능 및 주의점에 대한 설명을 들었고, 어떻게 사용하면 되고, 과금은 어떤 식으로 이루어지는지에 대해서 자세한 설명이 있었습니다.
이후 12시부터 점심시간이었습니다. 세종대학교 주변에 식사할 곳이 마땅치 않은데, AWSomeDay에서는 감사하게도 참가자 전원에게 맛있는 도시락이 제공되었습니다. 다만, 참가자가 많아 이마저도 뒤에 앉으신 분들은 본 도시락으로 드셨습니다.
한시간의 점심시간이 끝나고 1시부터 블록스토리지 서비스인 EBS( Elastic Block Storage ), 네트워크 구성과 관련된 VPC ( Virtual Private Cloud ), 보안관련 IAM( Identity and Access Management ), NoSql DB인 DynamoDB, 관계형 데이터베이스인 RDS ( Relational Database Service )에 대한 설명이 이어진 후 잠시 휴식시간을 가졌습니다. 각 서비스에 대한 설명이후에는 설명한 것에 대한 시연 영상이 보여져서 설명을 이해하는 데 도움이 되었습니다.
이후 20분 정도의 휴식시간이 주어졌고, 참가자가 많았기에 간단한 과자와 음료수가 제공되었는데, 순식간에 동이나는 광경을 목격할 수 있었습니다. 미리 사전등록을 받을 때, 인원에 제한을 두었더라면 조금은 덜 혼잡했을텐데, 조금 아쉬웠습니다. 현장등록도 가능한 것으로 보아 참가인원에 제한은 없었던 것으로 보입니다.
휴식이후 ELB( Elastic Load Balancing ), CloudWatch, Auto Scaling에 대해서 설명을 들었으며, Scale up / down 에 대한 동작 원리, 구현 방법에 대해서 이해할 수 있었습니다. 특히 HA 구성을 할 때, 여러 AZ(가용영역)에 걸쳐서 구성할 때, 어떤 점을 고민해야하는지 설명을 해주셔서 나중 서비스를 구성할 때 도움이 될 것 같습니다. 이후 Trusted Advisor 기능 설명을 들었습니다.
모든 세션이 끝나고 경품추첨을 마지막으로 기념품인 마이보틀을 받고 모든 행사가 종료되었습니다. 아마존이라는 회사가 클라우드 서비스를 주로 하기 때문에 이런 행사를 통해서 고객을 늘린다는 목적도 있겠지만, 고객들이 본인들의 서비스를 좀 더 잘 알고 더 효율적으로 사용할 수 있도록 (큰 비용을 들여서 ) 스스로 알리고 있다는 점에서 ( 물론 프리티어 사용자 이지만 ) 한 사람의 고객으로써 감사한 마음을 가졌습니다. 지금 서비스를 위해서 사용하는 모 기업의 클라우드와 비교해보면 동일하게 클라우드를 서비스하고 있다고 주장하지만, 내부의 네트워크 구성이나 서비스 구성법을 전혀 알려주지 않고, 심지어 상품안내 조차 없는 것 등 많은 점이 비교되었고, 아마존과 비교해보면 그들이 하는 클라우드 서비스 수준은 IDC를 통해 온프라미스 서버를 구성하는 것과 크게 다르지 않음을 알 수 있었고 진정한 클라우드 서비스는 ( 시작도 다르고 추구하는 방향도 다르겠지만 ) 아직 멀었다고 말해주고 싶습니다.
집에와서 찾아보니 “AWS 기술 에센셜” 교육은 1일과정에 44만원이라 하는 과정이라 개인이 듣기에는 부담되는 과정이기에 이번 행사는 아마존 웹서비스를 처음 사용하거나, 저처럼 (몰라서) 단순히 프리티어 EC2정도만 사용하는 사람에게는 하루 정도를 투자할 가치가 충분하다고 생각되는 행사였습니다.
]]>