참관기

[컨퍼런스] 20151007 TECH PLANET 2015 2015.10.08
20130713 Helloworld 세미나 이야기 2013.07.14

[컨퍼런스] 20151007 TECH PLANET 2015

2015. 10. 8. 09:59

장소: 잠실 롯데호텔월드 3층 연회장
Tech Planet 2015(http://techplanet.skplanet.com/)
- 시간표: http://techplanet.skplanet.com/agenda.html
관련사진 모음: https://goo.gl/photos/BQ4qp1nmsXqu5yrZ6

1. 시럽페이로 풀어본 보안 이야기, 임형태(매니저, SK PALNET)

1.1. 시럽페이 소개

간편결제
비용지불이
순수한 웹으로 구현된 시럽페이

1.2. 간편결제

핀테크와 다르다. - 핀테크: 은행권에서 사용하는 결제

Paypal과 같은 서비스 영역
- 2015년 금융결제원에서 규제를 철폐하겠다는 발표를 하면서 10개의 서비스가 출현
- 결제시장이 왜곡되고 불편했다.
보안 > 사용자 권리
- 획일화된 환경 요구
- 보안!!
'외부의 탈취와 훼손으로부터 보호'하는 것!!
기존에 불편에 대한 생각을 다시 해보게 된다.
- 불편한 것이 정말 보안을 위해 적절한 것인가?
고민 & 과정
- 키워드 중심의 보안 아키텍처(!?)
‘해결 방법보다 숙제를 함께 풀고 싶습니다.’
- 해결한 것보다, 해결하는 과정을 이야기하면서 숙제를 던진다.
허니몬: 해결방법은 문제에 접근하는 사람과 관점에 따라 다양해질 수 있겠다.

1.3. 의사소통Communication

사람과 사람, 컴퓨터와 컴퓨터, 컴퓨터와 사람
의사소통 in 네트워크
- Add WIFI
- ‘모든 것은 네트워크를 위해 존재한다’
불특정 다수의 네트워크

1.3.1. 인증Authentication, 누구냐 넌?

식별을 하자.
가맹점 and 사용자
- 자원에 접근하고자 하는 모든 대상에 대해서는 인증해야 한다.

1.3.2. 가맹점 인증

OAUTH2
- Client credentials
- Grant 부여
- ID/Secret token
Javascript Object Signing and Encryption
- 무결성, 암호화를 위한 암호화 알고리즘, 알고리즘 데이터를 암호화해서 전달하고 이를 복화하여 사용하는거야?
http://jwt.io
시럽페이의 가맹점 인증절차
1. 사용자가 시럽페이 결제 선택
2. 가맹점이 결제 데이터 구성 후 서명
3. 시럽페이 서버로 전달
4. 시럽페이 인증받고
결제데이터 + 서명 = 가맹점 인증

1.3.3. 사용자 인증

사용자 편의성
**Single Sign ON(SSO)**이 주는 이점
- 패스워드에 대한 피로감을 줄여준다.
- 토큰으로 인증을 대행한다.
Single Sign on 발급조건: 두가지
- 자체 회원체계를 가진 신뢰된 가맹점
- 해당 가맹점에서 접근에 대해 사용자의 명시적인 동의
그외에는 ID/PASSWORD 방식 대응

1.3.4. 암호화 해시 함수

단방향 암호화
- 동일한 입력 = 동일한 출력
  - 인덱스, 성능
  - 암호화 취약성을 가져오게 된다.
  - **Dictionary(Rainbow Table) Attack
    = 구글 인터넷 검색을 통해서 처리
    = 고성능 기기를 이용한 처리
- 빠른 처리 속도
  - Brute-Force Attack
암호화 해시 함수 취약점 보완
- Salt
  - **Dictionary(Rainbow Table) Attack 저항
  - 입력값에 대한 가변성을 줌
- Key Stretching
  - Brute-Force Attack 저항
  - Strength를 부여
패스워드 암호화 in 시럽페이
- HMAC
- PBKDF2: Password-Based Key Derivation Function2
- Scrypt
- Invidual Salt(32bits)
- SHA256
- 성능적인 문제가 걸릴 수 있지만, ID/PASSWORD 체계에서는 괜찮다.
- 암호화에 대한 것은 개발팀에서 고려할 문제

1.4. 결제, 권한Authorization

인증된 사용자가 얻은 권한
- 접근 권한
- 결제권한??
ID/PASSWORD 만으로는 결제에 대한 권한을 부여하기는 그렇다.
ID/PASSWORD + PIN
- 결제 기능에 대한 접근권한을 얻기 위한 인증단계
권한(AS OAUTH2) in 시럽페이
권한을 위해서 인증이 필요하다.
- 자원에 대한 접근을 하기 위한 수단
적절한 인증을 거친 사용자에게 적절하지 못한 권한을 주었기 때문에 문제가 발생할 수 있다.
- 보안: 인증Authentication과 권한Authorization의 적절한 정리가 필요함
인증의 요소
- KNOW(인증번호, 핀)
- HAS(as SMS-OTP, ARS, OTP)
- IS(as 생체인식)
  - 사용자가 쓰고 있는 컨텍스트
- IN(Contextual, as FDS)
결제수락

명시적으로 사용자가 결제를 하겠다는 의사를 취합

핀 번호 입력 == 카드를 긁고 사인을 하는 것과 유사함

추가인증
- 편리함 in 안전함
  - 결국은 인증과 권한의 균형 <- 제일 중요한 키워드군요.

1.5. 우리 둘만 아는 이야기, 의사소통(통신)

불특정 다수로 이루어진 고통
무결성과 암호화
- 무결성: 정확성, 합리성
- 암호화: 임의의 문자열로 부호화
TLS Transport Layer Security
- 이런 것을 이용하는 훌륭한 체계가 있음
- 그런데 왜 우리가 고민해야할까?
- 현재 인증정보가 세션Current session state 에 저장하고, 이것이 없으면 TLS에서 사용할 수 없다.
- 보호해야 하는 데이터의 생명주기가 TLS 세션 밖에서도 유지되어야 한다면 추가적인 무결성, 암호화 알고리즘 적용을 고려해야 한다. 시럽페이의 어느 개발자
- TLS 안, TLS 밖
암호화 알고리즘
- JOSE JWA에 명시된 알고리즘을 사용
  = HS256
  = RS256
  = AI28CBC-HS256

1.6. 마치며

보안은 어렵습니다. ㅠㅠㅠ

사슬의 약한 부분만큼 강하다.
- 약한 부분에서 만큼의 강도를 가진다.
굳이~ ActiveX, 보안모듈을 설치하지 않더라도 사용자에게 보안솔루션을 제공할 수 있는 서비스를 만들자.

1.7. 정리

시럽페이 보안: 인증과 권한을 조화롭게 다루어 의사소통을 하도록 하여 결제를 편리하게 할 수 있도록 유도하는 것이 목표!!

비싼 점심. 맛있음. +_+)b

2. Fast and Beautiful: Serving High Quality Pohotos at Scale on Flickr, Hugo Haas

2.1. 플리커 고해상도 사진의 공유

2… 플리커의 사용자 경험 공유

플리커, 훌륭한 컨텐츠: 멋진 사진들
- 컨텐츠만으로즌 부족하다. 이것을 공유하기 위한 것이 필요하다.
빠른 속도(쉽고! 짧고 분명한 가치) 문제
높은 기술수준

2.3. 아름다움, WHhat does beautiful mean?

주관적이지: 고양이 사진
Feature
사용자가 사진을 맘에 들어할 지 그렇지 않을 지에 대한 기술적 접근

2.4. 빠름, What does fast mean?

API 응답성
사진 제공
스크린 스크롤 읽어오기
화면비율
여러가지 레벨로 적용가능
Server side -> User interaction

2.5. Challenge:

2.5.1. Designs are more immersive

차이: 2009년도 vs 2015년도
- 픽셀들이 이미지에 사용되어야 한다.

2.5.2. 해상도Resolution

해상도, 사용자에게 제공하려고 하는 컨텐츠가 점점 거대해지고 있다.
네트워크의 대역폭은 지역별로 차이가 크고 그렇게 높지 않다.
- 아시아는 4Mbps 속도

2.6. 해결책

2.6.1. First things, Instrumentation!

다양한 측정정보를 수집
- 모든 계층에 대한 계측!!
  - 서버, 통신, 기기, 클릭

2.6.2. Analyze, Analyze, Analyze

분석에 많은 시간이 소요됨

최악,
평균
최선

커넥션의 연결상태
지리적인 부분
- 한국
- 싱가폴, 필리핀 등
다운로드 속도, 렌더링 속도
첫바이트, 라스트 바이트

2.6.3. 서버사이드 그리고 Latency

서버사이드에서의 최적화!
테스트 코드
- 작성된 코드의 작성시기
- 작성된 코드의 변경사항에 따라 속도의 영향을 끼친 것
- 하드웨어의 변화
하드웨어
속도를 향상시키기 위해서 고려해야할 점들이 많다.
속도에 대해 최대한 빠르게 파악하여 속도저하를 해결하려고 해야 한다.
속도저하가 발생하는 것은 게으른 것이다.

클라이언트 - 서버, 160ms 차이

HTTP 통신
- SSL Handshake
- HTTP Request
  *** 500+ ms
- Server-side Response
- Data transmission
최적화를 위한 포인트를 찾다.
- 브라질에 있는 경우 15-40% 의 개선이 있었지만 실제로 느끼게 되는 것은 5-10% 향상효과밖에 없다.
- 유저들에게 돌아가는 혜택이 줄어들 수밖에 없게 된다.

2.6.4. Where do we spend time when getting media?

connection && request + server processing + response transfer(Largest payload!!)
- 전송 바이트를 줄일 수 있을까? Can we send less byte?
Encoding & compressing… with care
- 사진을 더 압축!!
  - compressing!! noise
  - 600kb, 85kb 를 두고서 고객에게 이야기 했을 때 같다고 이야기할 것인가?
  - 노이즈를 줄이면서 압축효율을 높이고 싶다.

2.6.5. 노력을 통해 얻은 진전

비슷한 화질을 50%의 사이즈로 전송할 수 있다. -> 비용이 높다.
- 사이즈를 변경한다.
원본사진을 가지고서 특정한 사이즈별로 만들어서 제공하게 되었다.
- 원본 사이즈, 중간사이즈, 작은 사이즈
오랜시간을 들여서 이미지의 크기를 줄이고 빠르게 전달할 수 있는 방법을 찾기 위해 노력했다.

2.6.6. 빈도?Latency

360kb -> 3.7s, 120kb -> 2.9s
- 작게 만들었지만 그보다 더 제한을 주는 요소가 있다.
대역폭별 속도를 분석했다.
- 특정시점에 이르러 비슷한 상황이 된다.
- 클라이언트와 서버의 거리, 연결connection
- 대역폭 vs 서버와의 거리
  - 서버와의 거리가 중요한 요인이다.

2.7. 문제점

2.7.1. Lowering the latency: bring content closer to the user

페북과는 다른 플리커의 사용자와 친구 관계
- 페북과는 다르게 플리커는 컨텐츠(풍경, 이미지)에 따라서 관심을 가진 대상들이 거리가 다양하게 된다.
- 관심사의 거리
15B 이미지를 다루는 것은 어렵다.
이미지 카피를 사용자에 가까이 유지
- user - Regional cache - Image store
- 사용자가 만들어낸 컨텐츠를 제공하기 위한 다른 캐시를 도입

2.7.2. Regional cache & CDN to the rescure

호주의 reginoal cache 로드타입 전후에 따른 속도차이
- 컨텐츠를 유저 가까이 가져오면 큰 차이를 보이게 된다.

2.7.3. 시도

서버의 속도를 향상
이미지 사이즈 조절
서버의 거리를 줄이기(Regional cache)를 통해서 사용자 가까이에 컨텐츠를 두었지.

서비스를 개선하기 위해 노력해왔지만, 이를 더 개선하기 위해서 더 할 수 있는 것들이 있을까?

클라이언트가 속도를 향상시킬 수 있는 좋은 장소다.
- Client is the best place to make things faster
- 다음 장소, 이전 결과를 제공하여 사용자의 행동을 유도
- 클라이언트가 사용자에 관한 컨텍스트를 가지고서 예측하여 먼저 제공한다.
클라이언트를 스마트하게 만든다.
- Make the client smart
- Use local cache
- 기회예측, 사용자 행동예측
- But not too aggressively
  - 대역폭에 따른 사용공간의 변화
  - Prioritize request
- 50~70% 예측
  - 이것은 치팅(눈속임?) 그렇다고 분노할 필요는 없지.

많은 시도!!!

2.8. 요약

균형을 잡는 흥미로운 행위
- 속도는 중요하다.
measure
Experiment
Look at all layers of the stack
사용자client 측에서 시도할 수 있는 것들이 있을까??
- 단축할 수 있는 것들이 많다.
- 시도해볼 수 있는 것: 다각 사이즈 조절
- 실제속도보다 빠르게 보이게 만들 수 있는 것
캐시
- 클라이언트를 제어한다.
앱에서 어떤 것들을 제공할지를 결정하는 것이 중요하다.
jpeg, 포멧별로 접근, 요구사항이 다르다.

2.9. 정리

사용자에게 '쾌속’과 '아름다움’을 제공하기 위한 노력을 멈추지 마라. 속도를 저하시킬 수 있는 부분들을 찾고 찾아서 그것을 최적화를 시도하라. 그리고 최적화를 할 수 있는 적절한 공간은 사용자측 client 가 될 것이다. Cheatting!!

3. Sclable Network for the Next Generation Resource Scheduling: 공용준(아키텍트, 카카오: Andrew)

아키텍트로 가는 길
- 아키텍트는 슈퍼맨, 아키텍트가 가져야할 역량
다음세대 자원관리를 위한 유연한 네트워크설계?

3.1. Term

3.1.1. Scale

Scale up vs Scale Out

스케일을 키우는 방법은 두가지!!

Scale: 눈에 띄는 변화는 없어야 한다.

3.1.2. Network

3.1.3. Scale Network

네트워크를 아무리 키워봐야 소프트웨어가 그대로면 별다른 변화는 없다?
- 빵빵한 네트워크가 있다고 해도 그걸 활용할 수 없다면 슬프겠지…?
2 by 4, 4명이서 2달해보고 잘되면 쉬자?
개발자, Step(비개발자)들도 가상서버를 자유롭게 만들 수 있다.
45000 krane, VM 서비스만으로 상당하나 규모를 사용하고 있다.
오픈스택에 3000 VM을 가지고 있다.
- 상당히 많은 것들이 구동되고 있으며,
- 이를 AWS에 올렸으면 상당한 비용을 지불했어야 할 것이다.
- 2, 3명이서 관리하고 있다.
- 대부분의 시스템이 자동화되어 있기 때문에 적은 인원으로도 관리할 수 있게 되었다.

3.1.4. Scale growth -> 자원이 고갈되고 있다.

3.1.5. 개발자들의 욕심에 따라서 언젠간 자원은 고갈되게 된다.

CPU, Memory, Sotrage always experience shortage.
They hav skewness
IP is also Resource
- IP 부족으로 서버를 생성할 수 없는 경우가 있었다.
- IP는 까다로운 자원이다.
- 서브넷을 나다는것은 게이트웨이가 분할되어 있고 게이트웨이는 지역성을 가지고 있다.
SDN without SDN: Openstack
- 10.0.0.1/32 or IP 10.0.0.1 netmask 255.255.255.255
- 유투브 조회수, Openstack foundation
SDN, Overlay 네트워크
VPN이 있는 회사가 좋은 회사?
- 라우팅 테이블
- private 네트워크를 겹치지 않도록 하는 경우가 많다.
- 암호화
  - 암호화를 하기 위해서 CPU를 사용하면서 속도가 느려질 수 있어?
  - 암호화를 끌 수 있…
Calico, Cumulus linux
L2 네트워크 인스턴스의 단점
- 뭔 이슈가 그리 많아!!
라우터는 유연한 네트워크를 처리하기 위해 잘 갖춰져 있다.

3.2. Next Generation Resource

3.2.1. Container

모든 리소스를 표준화
less mutable things
- pips, gems, war, packages
컨테이너만으로는 의미가 없다.
컨테이너: 사이즈가 정해져 있다.
- 해운업: 적재장이 정해져 있다.
IT 리소스가 표준화 되어 있다면 어떨까?!
클라우드 서비스간에 인스턴스가 표준화 되어 있지 않다.
서비스 제공자는 표준만 제공
개발자가 아닌 곳에서 제공
- 인프라도 힘들어 졌다.
- 무조건 개발이다.

3.3. Nework Next generation Network Resource Scheduling

프록시 의존적인 네트워크는 안정적이지 않다.
네트워크
- HTTP, CURL 을 통해서 접근하고 싶다.
Overlay 퍼포먼스가 좋지 않다.
- tunnel == vpn
OPEN FLOW???, OVS???
multicast debugging…?

3.4. 컨테이너가 가지고 있는 네트워크의 속성을 변경해보자.

컨테이너 내부 IP를 라우팅되는 IP로 변경해보자.
- 제약사항들을 벗어던질 수 있다.
blog.midonet.org, using docker libnet
- Container 를 위한 Dynamic 주소 처리가 가능해?
조만간 이런 한계들이 개발될 가능성이 있다.

in this planet, we’re not alone.

3.4. 어려운 일 vs 시간이 오래 걸리는 일

3.5. 정리

제일 중요한 것은 한번 해보는 일이다.

KField network

컨테이너, IT 리소스 표준화, 네트워크 성능개선…

도커Docker를 다뤄보자.

4. How to make your team successful with github(or Breaking silos), TAKAFUMI IKEDA(Sales engineer, Github) ikeike443

깃헙을 이용해서 성공적인 팀 만들기 저자
http://www.yes24.com/24/Goods/14725219?Acode=101

4.1. 성공으로 이끄는 팀 개발 실천기술 저술

github anna’s story

4.2. github universal 소개

지금까지 소프트웨어를 사용하지 않았던 사람들이 자신의 문제를 해결하기 위해서 소프트웨어를 사용할 것이다.
- 그래서 깃헙을 쓸거다.
NASA에서도 깃헙을 사용하고 있다.
PIXAR
- 뛰어난 애니메이터와 엔지니어는 비슷한 점이 많다.
- 이터레이션을 반복적으로 한다.
- 팀웍이 중요하다.
- 모든 팀원들이 훌륭한 애니메이터다.
GE
- 이전까지 소프트웨어와 관련이 없다고 생각한 이들도 깃헙을 사용하고 있다.
정부 기관의 정보를 깃헙에서 공개하고 여러사람들이 함께 만들어가고 있다.
깃헙은 카페인을 좋아하는데, 알콜도 좋아한다.
Octoshop

4.3. Git LFS 1.0

Large File Storage 1.0
Integration Directory
YubiKey
- 새로운 인증키

4.4. Agenda

Why do you need github

4.5. Why do you need github

4.5.1. Every company is a software company

테크놀러지가 모두 소프트웨어와 서비스로 이동하고 있다.
우버
- 사람, 물건도 나나르고
에어비앤비
라인
- 커뮤니케이션의 흐름을 바꾸고 있다.
소프트웨어와 관계가 없다고 생각했던 기업들이 이동해가고 있다.

4.5.2. What’s happening in Dev world todays?

Needs
- High velocity
- good user experience & High Quality
- Quck & innovation
Pain points
- very slow & unreliable dev/deploy flow
- no code review, no ci, too many regressions
- No transparency, Reinvent the wheel, silos
  = 서로 만들고 있는 것을 몰라서 반복적으로 만드는 행위가 반복

4.6. Where software is built?

4.6.1. Github flow

4.6.2. Branching is quick and easy

Experimentation without risk
Branches should be shot lived
Github이 아니라 GIT이 가진 강점이지.

4.6.3. Collaborate with anyone on the Pull Request

모든 사람들이 협업을 할 수 있게 되었다!?
Involve anyone to make it

4.6.4. Test it before merging

머지하기 전에 테스트를 해서 검증하는 것이 중요하다.

4.6.5. Merge it! with any condition you prefer

Protected branches and required status
- 깃헙 블로그에 보면 기능 나와있어…

4.6.6. Revert pull request

풀리퀘스트 단위의 revert 기능을 제공
Pull request didn’t go as planned? revert!

4.6.7. Web Blame and Linked pull request information

4.6.8. Closing issue pull request

4.6.9. Global Issue and Pull Request

4.6.10. You can find everything here

Great talent, useful code are already here
많은 것들을 찾아볼 수 있어.

4.6.11. Emoji

코드리뷰 후 원활한 의사표시를 위해서!!

4.7. Wrap up, Breaking up your silos

모든 정보가 한군데에 모인다.
누구나 접근할 수 있다.
변경하거나 협력하는 일에 대해서 겁내지 않아도 된다.
사일로에 갇힐 필요가 없다.

4.8. 정리

깃헙을 쓰세요.
깃헙 말고 요비(http://yobi.io) 도 있어요.

5. 흔히 발견되는 자바 웹 애플리케이션 아키텍처 안티패턴(박성철, 본부장/SK PLANET)

아키텍처 -> 애플리케이션 아키텍처 -> 구조적인 접근
안티패턴
- 좋지 않다는 감지.
학습을 하다보면 정상치
- 침체기를 겪게 된다.
새로운 시도
- 새로운 지식, 학습
- 내가 가지고 있던 역량보다 낮아질 수 있게 된다.
- 모험
프로그래머들 스스로 하고 있는 일이 무엇인지 어떤 것인지 알지 못한다.
- 그래서 그 다음 단계로 나아가지 못한다.
87년생설

C/S 패턴

5.1. 연통가설

애플리케이션의 각 모듈이 독립적으로 개발되어 다른 모듈과 로직이나 데이터를 공유하지도 않고 상호작용하지도 않는다.

중복이 발생할 수 있다.
관심사에 따른 계층 설계
- 관심사 분리 원칙에 따라 계층도 각 계츠으이 관심사에 따라 설계

5.2. 뒤범벅 아키텍처jumble architecture

무거운 서비스

횡적인 요소들이 있다.

5.2.2. 해결책

애플리케이션 서비스 계층 추가
파이프 & 필터 패턴
- ex) 서블릿 필터
AOP
- 기능에 직교적인 횡적 관심사를 분리해 모듈화 수준을 높이는 기술

5.3. 긴 공개 메서드long method

클래스에 공개 메서드 뿐이고 각 메서드의 크기도 너무 길다.
- 미미한 기능 분화, 낮은 유지 보수성
- 중복 다량 발생
- 단일 책임 원칙 위반
- 기능 분화로 재사용 코드 발견, 추상화의 기회
클래스 추가 공포증

5.3.2. 해결법

5.4. 하는 놈 따로, 아는 놈 따로

5.4.1. 도메인 모델 도입

모델링 -> DB 모델링

5.5. 낮은 응집도 높은 결합

5.6. 오염된 도메인

도메인 영역의 모델만 가지고 도메인해야 한다.

5.7. 정리

시도하고 실패하고 경험을 쌓자.

6. Docket 클라우드 환경 구축 프로젝트 - d4, (황상철/SK PLANET)

… 못들음…

* 황상철님 발표자료: http://readme.skplanet.com/?p=11449

0. 정리

Tech planet의 강연은 만족스러웠다.

DEVIEW 2015 와 TECH PLANET 2015에 참가한 깃헙의 발표는 이제 듣지 않아도 될 것 같다.

깃을 기반으로 한 개발을 자연스럽게 하게 되면서, 굳이 깃헙 서비스를 중심으로 개발을 하지 않아도 충분히 개발과 관련된 버전관리를 할 수 있는 대안들이 많이 있는 상황이기 떄문이다. 어제 스쳐간 글들 중 드랍박스에서 구글 드라이브로 이주해가는 것에 대한 글들도 많이 나왔는데 개발 버전관리시스템도 그와 같다고 할까?
‘성공으로 이끄는 팀 개발 실천기술(http://www.yes24.com/24/Goods/14725219?Acode=101)’ 이 책의 저자가 왔었지만… 그다지 흥미롭지는 않았다. Git LFS(https://git-lfs.github.com/)에 대한 이야기를 해줬으면 흥미를 주었을지도 모르는데…

한국 개발자들의 발표는 좋았다. 한국어기 때문인가!? +_+)
전체적으로 한국 개발자들의 수준이 향상되었고 많은 노하우를 축적했기 때문이겠지.
내년에도 필.참.하도록 하자.

저작자표시

'logbook' 카테고리의 다른 글

20151024, Modern java web application with spring 참여 (0)	2015.10.26
[덕후감] 자바 ORM 표준 JPA 프로그래밍 (0)	2015.10.16
ㅎㅎ 개발자들의 개인방송 전성시대... 나도? (0)	2015.09.14
DEVIEW 2015 첫째날만 참가 (0)	2015.09.12
미미박스, 개발자 모집중 '꽃밭에서 코딩... 해볼래?' (1)	2015.08.16

20130713 Helloworld 세미나 이야기

2013. 7. 14. 08:42

관련페이지 : http://helloworld.naver.com/helloworld/416268
일시 : 2013년 07월 13일 오후 2시
장소 : 그린팩토리 2층 커넥트 홀

NHN 그린팩토리 주변에 보면 고급 아파트들이 둘러쳐져 있다.

처음으로 와본 그린 팩토리. 2층과 1층은 일반인에게 개방되어 있기에 인근 주민들이 찾아와 시간을 보내는 모습이 색다르다. 하지만, 이 주민들 중 누군가는 그린팩토리의 창으로 비치는 태양이 눈부시다고 넣은 민원에 서명을 한 이도 있지 않을까? ㅋㅋ

접수창구에는 올드멤버중 한분이신 채수원님이 주말알바로 접수요원을 하고 계셨다. 오랜만에 뵙기에 반갑게 인사드리고 약간의 기념품(스티커, 배지, 군것질류, 생수)을 챙기며 커넥트 홀로 들어섰다.

앞자리로 이동하니, 첫발표자인 정상혁님과 다다음 발표자인 백기선님을 뵐 수 있었다.

정상혁님은 '[Spring 3.0 -> 3.1 -> 3.2 따라하기]'라는 주제로 발표를 시작하신다. 소스코드가 많은 발표이기에 github 에 마크다운으로 작성된 문서를 기반으로 발표를 진행하신다. 이런 방법도 괜찮다 싶다. 개발과 관련된 발표자료를 만들때 소스코드를 이쁘게 표현하기가 참 쉽지 않은데, 그럴바에는 차라리 마크다운 문서로 보여주고 이를 공요하는 것이 적절해보인다. 프리젠테이션 파일로 만들어진 발표자료는 나중에 보기가 쉽지 않고, 시스템에서 텍스트 검색도 되지 않아서 나중에 다시볼 가능성이 극히 희박하다.

스프링의 버전이 3.0에서 3.1로 넘어가면서 많은 변화가 일어났다. 스프링이 하위호환성(새로 출시된 프레임워크가 이전 프레임워크에 맞춰 개발된 기능을 그대로 유지-지원하는 것)을 강조하는 프레임워크지만, 코드의 개선을 위해서 3.1에서는 꽤 많은 부분이 변경되었다. 이 변경된 항목들에 대해서 찬찬히 짚어가는 시간이 지속되었다. 여전히 스프링 3.0을 이용하고 있는 프로젝트가 많은 상황에서 스프링 3.1 이상으로 업그레이드를 하려고 하는 이들에게 도움이 되었으리라고 본다.

발표자료 : Spring 3.0 -> 3.1 -> 3.2 따라하기

다음 발표는, 성능테스트 툴로 사람들의 많은 관심을 받고 있는 nGrinder에 관한 발표였다. 'nGrinder 초딩도 하는 성능 테스트'라는 제목으로 윤준호님이 발표하셨다. 낼모레 불혹을 앞두고 있는 '디자이너 출신'의 개발자는 nGrinder의 미려함에 대해서 강조하셨다.

창조자인 개발자에게 자신의 창조물을 파괴하는 행위인 '테스트'는 참 힘든 일이다. 하지만, 자신이 만든 창조물의 성능과 안정성을 높이는 일은 외면해서는 안될 일이다. 어느 개발자들은 '테스트'는 품질관리QA(Quility Assurance)자에 의해서 진행이 되어야 한다고 말하지만, 나는 개발자가 일정수준 이상의 품질을 갖춘 제품을 만들어낼 의무가 있다고 본다.

개발자가 일정수준 이상의 품질을 갖춘 제품을 만들어내기 위해서는 '테스트'를 진행해야 하는데, 그 테스트를 개발자 스스로 하게 하려면 어떻게 해야할까? '테스트'가 쉬워야 한다. 쉬워야 테스트를 쉽게 하고 제품의 품질을 높이면 자랑할 수가 있다. 테스트를 하면할수록 성능이 개선된다면 개발자는 자발적으로 테스트를 수행하게 될 것이다.

nGrinder는 Grinder에서 시작되었다. Java 이외의 Jython과 Groovy를 지원하며, 테스트에 사용되는 스크립트를 자동생성하고 자체 SVN으로 관리해주고 테스트 결과를 저장하여 살펴볼 수 있는 기능을 제공한다. IDE와 클러스터링을 지원하면서 개발자의 '제품'에 대한 성능 테스트를 용이하게 한다. 이렇게 테스트를 용이하게 하면서 NHN내부에서도 620여명의 사용자가 11,000건의 테스트를 진행하며 성능 테스트 활동이 10배이상 증가하는 테스트를 달성했다고 한다.

내가 만든 제품에 대해서도 성능테스트를 진행해봐야겠어. ㅡ_-);;

세번째 발표는, whiteship 이라는 닉네임으로 '스프링 프레임워크'와 관련해서 잘 알려진 백기선님이 'Vert.x와 socket.io 이해 및 활용'이라는 주제로 발표하셨다. 특이하게, 자신의 큰 딸 '서연이'와 함께하는 발표였다. 발표 중간중간에 서연이의 돌발 행동에 참석자들은 흐뭇한 '아빠미소'를 짓고 있지 않았을까?

시작에 '왕좌의 게임'에 나오는 말을 인용하며 '개발이 딸보다 쉬웠다' 라는 그의 말을 조금은 이해할 수 있는 순간이었달까?

Vert.x는 매우 쉽게 확장 가능한 차세대 비동기 애플리케이션 개발 플랫폼이다.

Vert.x는 자바스크립트 엔진을 이용한 node.js와 비교되는 Java를 기반으로 하는 비동기 애플리케이션 개발 플랫폼이다. 백기선님은 Vert.x에 관심을 가지고 관련한 글을 꾸준하게 작성하고 있다. 지금도 꾸준하게 관련한 소식들을 게재하고 있다.

Vert.x의 핵심요소는 Netty(IO 처리), Hazelcast(메모리형 데이터를 분산처리할 수 있는 그리스 시스템 제공)이다.

About Vert.x

Vert.x 의 주요 개념으로 Verticle, Vert.x. instance, Ployglot, Concurrency 에 대해서 하나하나 짚어나간다.

Verticle은 Vert.x 에서 배포가능한 애플리케이션 단위이며 개별적인 클래스로더를 사용하여 실행해주며, 손쉽게 클러스터링할 수 있다. 수평적인 확장을 지원하며, 확장된 Verticle 간에는 메시지를 주고 받을 수 있다.

Polyglot은 JVM에서 실행가능한 다양한 언어들로 작성할 수 있다.JavaScript, Ruby, Java, and Groovy 등의 언어를 지원하고 있으며 추가적으로 Clojure, Scala and Python 등의 다양한 언어를 지원할 것으로 보인다.

Vert.x 를 이용할 때는 vertx-core, vertx-platform을 이용하면 된다. 버전업 되면서 사용하는 방법이 달라졌다고 한다. 라이브코딩을 하다가 당황하셨지만 능숙하게 대처하는 모습에서 그의 발표경험의 연륜을 짐작하게 만든다.

node.js가 많은 인기를 끌게 만든 모듈 중 하나가 socket.io(전송 방식을 추상화하여 모든 브라우저와 모바일 기기용 실시간 애플리케이션을 개발가능하도록 하는 것이 목적)다. Socket.io를 이용해서 실시간 웹 기술을 이용하여 요즘 많이 관심받는 푸쉬Push 기술을 구현하기가 용이해진다. Socket.io 는 node.js의 모듈이다보니 자바쪽에서 아쉬워하는 녀석 중에 하나였는데, 기선님이 keesun/mod-socket-io 를 만들어내어 오픈소스로 제공하고 있다.

스프링 4.0에서는 자체로 웹소켓WebSocket을 지원하는데, SockJS 구현체가 들어 있어 지원한다고 한다. SockJS가 서버의 연결이 끊어졌을 때 서버와 클라이언트가 서로 그 정보를 주고 받는 핑퐁(Ping-Pong, 이걸 핑퐁이라고 하는 것이군!)을 지원하지 않아 아쉽다고 하였는데, 과연 스프링에 포함되었을 때는 어떤 모습을 가질 수 있을지... 궁금하군.

개인적인 일정으로 여기까지만 듣고 Helloworld 세미나장을 나온다.

비가 내리는 날에도 많은 사람들이 참여한 세미나였고, 나로서는 처음 그린팩토리를 살펴볼 수 있는 좋은 기회였다. ㅎㅎ 하지만, 우리집(경기도 남양주시)에서 정자동까지는 멀고먼 여정이었다. Orz... 집에 돌아와서는 10시에 체력저하로 다운.