dyway

I'm very well : Life of an ordinary programmer

Archive for 9월 2012

DEVIEW 2012 참관기

* 간략하게 분위기나 느낀점 같은 걸 공유하고자 사내에 전체 메일로 보낸 내용을 편집하여 블로그에 게재함.

지난 9월 17일에 코엑스에서 열린, NHN 주관의 개발자 컨퍼런스인 DEVIEW(http://deview.kr/2012/xe/index.php?mid=Overview)에 다녀왔다.  DEVIEW는 매년 열리는 행사이고, 접수 시간에는 워낙에 사람이 많이 몰려서 서버가 다운되기 일쑤인데, 이번에는 신기하게도 신청에 성공해서 처음으로 참석할 수 있었다. 올 해에는 처음으로 트위터나 링크트인 클라우데라 인텔 등과 같은 외국 기업의 연사들이 참여를 했다.

총 7개의 트랙에서 각각 6개의 세션이 열렸으며,  나는 트위터의 대용량 데이터 처리 방법, 링크트인에서 만든 카프카 pub-sub 메시징 시스템, 클라이언트에 심는 쿠키의 네트웍 트래픽을 줄이기 위한 자칭 서버 사이드 쿠키 시스템, 구글의 엔지니어링 문화, Netty의 내부 구조 이렇게 5개의 세션에 참석했다. 100% 기억에 의존해(모든 정보가 정확하지 않을 수도 있다는 의미) 느낀 점과 내용, 관련 자료 찾은 것을 짤막하게 정리해본다.

  • 트위터의 대용량 데이터 처리 방법
  • 링크트인의 카프카
    • 링크트인의 Senior Software Engineer인 Richard Park 발표. (한국 분인줄 알았는데, 아닌 듯)
    • 링크트인에서 만들었고, 빠르고 안정적이다. 기본적으로 ‘메시징 시스템이란 이런 것이다’라기 보다는 ‘우리가 이걸 만들었는데, 이런 방식으로 사용을 하고 있고, 성능과 안정성이 좋다. 잘 만들어져 있다.’는 식의 광고 비슷한 느낌이랄까. 링크트인에 실제 적용되어 있음.
    • 현재 아파치에서 인큐베이팅 중이며 오픈 소스로 공개되어 있음.
    • 보통 파워포인트나 PDF로 주로 자료를 만들어서 발표를 했는데 이 분은 특이하게 Prezi로 발표. Prezi.com에서 검색해보니 자료가 나옴 : http://prezi.com/mxenutdbqzij/sdec-2012-apache-kafka/
    • 카프카는 여기에서 확인 : http://incubator.apache.org/kafka/index.html
    • 카프카는 Apache Flume이나 Facebook의 Scribe와 많이 비교를 하고 있고, RabbitMQ나 ZeroMQ등 과는 서로 비교를 많이 하지 않는 것 같음.
  •  쿠키 대안 서버 사이드 솔루션
    •  NBP의 조규만님의 발표, TripleS라는 내부 솔루션에 대한 설명.
    • 네이버 메인 같은 경우에는 서버가 너무 많아서 로그인 정보 등의 데이터를 세션으로 공유하는 데에 애로사항이 있다. 따라서, 쿠키를 주로 사용하게 되는데 이 쿠키의 크기가 점점 커지기도 하고, 서비스가 유선에서 무선으로 많이 옮겨가는 추세에서 1KB, 2KB 정도의 쿠키가 네트웍에 부담이 될 수 있는 상황이라 서버 측에 쿠키 정보를 저장을 하는 방안을 고안했다고 함.
    • 즉, 쿠키로 저장하던 여러 정보를 키-밸류 형태로 웹 서버나 WAS에서 접근 가능한 서버측 저장소에 저장하며, 쿠키에는 키를 저장하도록 해서 단말이 서버에 붙을 때 쿠키에 저장된 키를 읽어서 저장소의 키에 해당하는 데이터를 찾아와서 처리할 수 있도록 했다고 함.
    • 서버 측 내부에서 데이터를 가져오는 데에 속도가 느려지면, 쿠키로 인한 트래픽을 없애는 것보다 좋지 않다고 판단했는데 내부 적으로 사용하는 속도가 빠른 저장소를 사용했다고.
    • 현재 네이버의 내 검색어 관련 저장 기능에 쓰이고 있다고 함.
  •  구글의 엔지니어링 문화
    • 구글 코리아 권순선님. kldp.org를 만든 분이고, 삼성전자, NHN을 다니다가 구글에 2011년 말에 입사.
    • 구글의 엔지니어링 문화라기 보다는 회사 생활에 대한 얘기를 블로그에 글 쓰듯이 쉽게 얘기함.
    • 대략 생각나는 내용은 다음과 같은 게 있다.
      • 근무 시간에 제약이 없다.
      • 하고싶은 업무를 본인이 결정한다.
      • 보고서는 최대한 간략하게 한 장. 폰트의 크기나 색깔 따위는 중요하지 않다.
      • 내가 무슨 일을 하는지 모든 팀원이 다 알고 있다. (다른 팀원이 무슨 일을 하는지 본인이 다 알고 있다.),
      • 자바를 만든 사람(제임스 고슬링), 파이썬을 만든 사람(귀도 반 로썸) 같은 유명한 사람들이 인트라넷에 있다. 심지어 출장가면 싸인도 받는다고.
      • 입사하기가 까다롭다.  6개월간 여섯 번의 인터뷰 그리고, 모든 팀원이 OK해야 입사 가능할 정도.
      • 하향 평가만 이뤄지는 게 아니라 동료 평가, 상향 평가가 이뤄진다.
  • Netty 내부 구조
    • Netty 라는 프레임웍을 만든 트위터의 이희승님.
    • 지금 프로젝트의 내가 맡은 파트에서 사용하는 프레임웍이고, 이걸 만든 사람이 직접 나와서 발표한다는 게 신기함. 게다가 젊은 한국인.
    • Netty의 구조적 설명은 둘째 치고 가장 임팩트가 있었던 건 JVM에서 메모리를 할당하는 것보다 더 빠르게 동작하게끔 코드를 짤 수 있을 것 같았고, 해보니 정말 그렇게 되었다라는 점.
    • 사실 Netty 보다 이희승이라는 사람에 더 관심이 가서, 기술적인 내용에 대해서는 기억이 잘 안 난다. 문서나 소스 코드를 통해 학습했던 내용이랑 겹치는 것도 한 몫 했었을 듯.
    • Netty : https://netty.io/
    • DEVIEW 다음 날 일간지에 나온 이희승님과 관련한 기사

DEVIEW의 모든 세션과 관련된 자료와 동영상은 추후에 공유가 된다고 한다.

다음 달에는 올 해의 마지막 대규모 개발자 컨퍼런스로 추정되는, 다음이 주관하는 디브온(http://devon.daum.net/2012/)이 열린다. 신청은 다음 주에 한다고 하니 잘 기억해 두는 게 좋겠다. 개인적으로는 본인이 초보 개발자인데 이런 행사에 한 번도 안 가본 사람이라면 꼭 한 번은 참석을 해서 같은 관심사를 가진, 같은 직업을 가진 수 많은 개발자들의 열정같은 것을 느껴보기를 권장한다. 멘붕이 올 수도 있고, 자극이 될 수도 있고, 동기 부여가 될 수도 있다.

추가적으로,
직접 찍은 사진 : http://plus.google.com/photos/107682966135641789948/albums/5789354715326633713
내가 찍힌 사진이 포함된 블로터 닷넷 기사 – [현장] 개발자와 소통 NHN 데뷰 2012 : http://www.bloter.net/archives/127639

* [20120921] 추가

오늘 DEVIEW 사이트에 들어가보니 동영상은 아직 업데이트가 안 되어있고, 발표 자료는 슬라이드 셰어에서 공유되고 있다.

슬라이드 셰어에 올라온 모든 슬라이드
– http://www.slideshare.net/deview/presentations
DEVIEW 2012의 시간표에서 세션 별로 하나씩 눌러서 자료를 볼 수도 있다.
– http://deview.kr/2012/xe/index.php?module=timetable&act=dispTimetableTimetable

광고

Written by dyway

2012년 9월 21일 at 4:28 오후

내 경험에 게시됨

Tagged with , , ,

Constant Interface 문제 – Constant는 어디에? Class? Interface?

간만의 자바 프로젝트인데다, 2-3년 전과 비교해서 달라진 부분도 많고, 그 동안 손을 놓고 있던 탓에 모르는 부분이 태반이라 공부도 할 겸해서 혼자 조금씩 스프링 프레임웍을 사용하여 게시판을 만들어 보고 있다. 최근까지도 계속 자바 프로젝트를 진행한 사람들이 많이 있는 다른 파트의 소스를 참고용으로 보다가 눈에 띈 사실이 하나 있었다.

여러 클래스에서 사용하는 상수 값을 파트마다 다르게 분리하여 사용하고 있다는 것. 상수 값을 Constants라는 이름으로 따로 분리해 놓긴 했는데, 어떤 파트는 Class로, 어떤 파트는 Interface로 분리해 놓은 것이었다. 내 경험 상으로는 Constant는 항상 Class로 빼서 사용을 해 왔는데, 생각해보니 어차피 값이 바뀌는 일도 없고, Constant클래스에서 상수 값 외의 별도의 메소드를 따로 작성하지 않기도 했었기 때문에 Interface를 써도 문법상으로 틀린 것도 아니고 그렇게 잘못된 것 같지는 않았다. 단지, 좀 찜찜하다는 생각이 들기는 했지만.

그렇게 계속 소스를 보는데, 정말 Constant를 Interface에 넣어서 사용해도 될까? 그렇게 많이들 쓰나? 하는 의문이 들기 시작했다. 급기야 메신저로 몇 명에게 물어봤더니 위의 이유대로 어차피 상수 값만 가지고 있고, 구현되어있는 내용이 없으니 Interface에 상수 값을 담아둬도 상관없는 것 아니겠느냐는 반응과 그렇게 쓰는 건 본 적이 없다는 반응을 보이더라.

나는 후자인 입장인데다가  Interface는 Interface 나름의 사용 용도가 있는 건데, 여기에 상수를 넣어서 참조한다는 게 영 꺼림칙했다. 그래서 찾아보니 Anti pattern 즉, 자주 사용되기는 하지만 비효율적이거나 비생산적인 유형에 이 문제가 포함되어 있는 걸 발견했다. 게다가, 지금까지 얘기한 Constant Interface는 별도의 위키가 따로 있을 정도였다.

결론적으로 상수 값은 Class에 담아서 사용하는 게 낫고(Anti pattern이 반드시 지양해야할 법칙이라면 옳고 그름의 문제이겠지만, 그런 게 아니니까), 코드의 양을 줄이기 위해서는 import static 구문을 사용하면 된다는 것을 알 수 있었다. Interface는 애초의 사용 용도에 맞게끔 사용해야하며, Interface에 상수 값을 넣고 사용할 때의 문제점, 비효율적인 점(내부에서 사용하는 상수 값이 외부에 노출, 추후에 사용하지 않게 되더라도 계속 가지고 있어야 한다는 점 등)들은 위의 위키 링크에서 언급이 되어 있으니 참고하면 될 듯하다. 읽지도 않고, 책꽂이에 잘 모셔둔 Effective Java에 이 내용이 포함되어 있다는 것도 검색을 하다 알게 되어 참 민망하기도 했다.

Written by dyway

2012년 9월 4일 at 12:00 오후

프로그래밍에 게시됨

Tagged with , ,

%d 블로거가 이것을 좋아합니다: