허니몬(Honeymon)의 달콤한 비행

올해 처음으로 Deview 2012(http://deview.kr/2012/xe/?mid=main)에 참가했습니다. 

  작년에 참가하려고 했다가 프로젝트에 치여지내느라 참가할 여유가 없었거든요. 올해는 SDEC 트랙도 포함해서 동시에 진행이 되었다고 합니다. 저는 당장은 DB와 관련된 관심사항이 없어서 SDEC 관련 트랙은 제외를 하고 들었습니다. 천여명의 국내 개발자들이 태풍을 뚫고 삼성동 코엑스 그랜드볼룸으로 모여들었습니다. 저는 회사에 교육신청을 하고 왔지만, 어느 개발자들은 연차를 사용해서 오는 경우도 심심찮게 볼 수 있었습니다. 개발자가 자신의 실력을 유지하기 위해 꾸준하게 이런 컨퍼런스 등에 참가하면서 소식들을 접해야한다는 것을 이해하는 임직원들이 많지 않다는 것이 참 슬프네요. 그것도 국내 대기업 IT회사들이 그런다는 것이 더욱 슬프군요.

  JCO때와 달리, 그랜드볼룸으로 가기 전에 접수대가 설치되어 있었습니다. 그래서 그랜드볼룸 쪽이 번잡하지도 않고 괜찮더군요.

SDEC 2012도 함께 진행되었습니다. 

빅데이터에 대한 이야기가 많이 다루어졌던 것 같습니다. 올해, 내년, 앞으로 당분간 DB와 관련된 트렌드에서 중요한 것은 클라우드 컴퓨팅과 빅데이터 처리가 아닐까요? 저는 당분간은 DB에 대한 직접적인 기술개발을 할 상황이 아니라 대충 어떤 흐름이겠구나 하는 정도지요. 몇몇 곳에서 하둡을 이용한 분산데이터처리를 시도하고 있는 것 같기는 한데, 아직은 컨퍼런스 등에서 '레퍼런스' 사례로 발표된 것은 못본 듯 합니다. 비싼 돈 주고 가는 세미나에서는 공유가 되었으려나요?

많은 사람들이 키노트를 듣기 위해 자리를 차지했습니다.

저는 키노트는 들을 생각이 없어서, 코엑스 맞은 편에 있는 카페에 가서 느긋하게 키노트가 끝나길 기다렸습니다. ^^;;

• Track A, Session 1
• 발표자 : KTH 문추근
• 루비는 만능, 최고?
• 루비
• 목표와 철학
• 유키히로 마츠모토
• Perl 보다 강력하고 Python보다 객체지향적인 언어를 만들고 싶었다.
• 재미있는 프로그래밍, 프로그래머가 행복하게, 인간지향적인 프로그래밍(사람이 생각하는 바를 코드로 쉽게 옮길 수 있도록)
• 특징
• 객체지향 프로그래밍
• 객체지향, 실제 세상과 닮아 있다. 코드로 옮기는데 적합하다.
• 객체(데이터-자료, 행동-기능)
• 루비에서는 모든 게 객체, 행동의 주체가 된다.
• 유연한 문법
• 몽키패치 : 실행 중 동적으로 코드 변경
• 메타 프로그래밍
• 자신만의 언어를 만드는데 유용한 문법코드
• Attribute_accessor :name, :email -> 게터, 세터 제공
• 코드의 양을 줄여주고, 코드를 개발자가 원하는대로 만들어주고
• 반복 : for 문, while 문
• 객체 대신 구문을 먼저 생각해야 하는 상황이 생겨 생각을 방해한다.
• each, Enumerable
• 객체를 먼저 생각하고, Enumerable 에서 제공하는 객체들을 먼저 생각하면 된다.
• 영향
• prototype
• underscore.js
• sugar
• coffeScript
• 루비의 유연한 문법을 차용
• 레일스
• 특징
• 웹 프레임워크
• 전통적인 MVC 구조, Router
• Router를 통해서 가져온 URL을 바탕으로 컨트롤러에서 어떻게 처리할지 결정하고 Model과 통신하고 가져온 값을 View에서 처리
• Scaffold
• 15분 만에 블로그 만들기
• 구조물
• 자동으로 프로토타입으로 생성되는 파일의 구조를 파악하면 동작원리를 이해하는데 큰 도움이 될 것이다.
• RESTful : CRUD
• Create -> POST
• Read -> GET
• Upddate -> PUT
• Delete -> DELETE
• 영향
• Backbone.js : 모델, 컨트롤러, 라우터 구조 가져옴
• 루비와 레일스의 활용
• 루비의 활용
• Rake : Make의 루비버전
• Backbone / Underscore / Zepto / Prototype
• Homebrew
• BDD
• Cucumber
• Terminal 기반 루비 프로그램
• 개발자라면 ’터미널’에서 수족처럼 다룰 수 있는 스크립트 언어 하나는 있어야 한다.
• 그 대안으로 ’루비’를 추천한다.
• 레일스의 활용
• 트위터, 그루폰, 깃헙, 슬라이드쉐어…
• 한국에서는 왕따
• 트위터에서 고래를 자주 봤지.
• 트위터에서 루비를 걷어내고 있다더라
• 등가교환의 법칙
• 무언가를 얻기 위해서는 그와 동등한 대가가 필요하다.
• 회사의 자원이 넘친다면 충분하다.
• 스타트업, 사람, 돈, 시간이 없는 곳에서는 ’우선순위의 문제’를 겪게 된다.
• 모바일 시대
• 쏟아져 나오는 앱
• 개발 속도가 더 중요한 서비스에 적합
• MVC 구조는 죽었다.
• 뷰가 중요하지 않은 시대
• API 중심 서버
• RESTful에 친숙한 서비스
• 배워야 하는 이유
• 매년 새로운 언어를 배워라.
• 실용주의 프로그래머 Tip #8
• 다른 언어는 동일한 문제를 다르게 푼다.
• 그 언어에 맞는 해결방식을 이용하여 해결하도록 해라.
• 언어의 한계가 곧 자기 세계의 한계다.
• 나의 세계는 자바에 국한되어 있다.
• 컴파일 언어 vs. 스크립트 언어
• 터미널에서 스크립트를 작성하여 바로 테스트해볼 수 있다.
• 자신이 하고자하는 작업에 집중하여 코딩이 가능하다.
• 빠르게 언어를 배울 수 있는 방법
• 배우려고 하는 사람의 성향에 따라서 달라진다.
• 자신에게 맞는 방법을 찾는 것이 중요하다.

• 정리
• 새로운 언어를 배울 때에는 새로운 언어에 맞는 문제해결방식을 익혀두는 것이 좋다.
• 루비(Ruby)라는 언어가 가지는 장단점에 대해서 가감없이 전달된 시간
• 빠르게 개발하기 - 프로토타입 제품을 만들어내기에는 좋다.
• ’빠르게 개발하기’와 ’빠른 성능’에는 차이가 있다.
• 사람들은 이것을 제대로 이해하지 못하는 이들이 많다.
• 루비로 빠르게 개발하여 제품을 출시한 후에는, 루비가 가지는 언어적인 한계를 정확하게 구분지을 필요가 있다.
• 개발자는 그런 언어가 가지는 특징과 한계를 분명히 파악하고, 거기서 발생할 수 있는 문제를 파악하여 대비하는 능력도 필요하다.

• Track C, Session 2
• 발표자 : 박대준(NTS 웹표준개발팀)

• 웹접근성을 해야하는 분들을 위한 NHN 웹접근성 시행착오 프로젝트 경험담
• 웹접근성이 뭔가요?
• 접근성이란 장애인뿐만 아니라 모든 사람이 정보통신 기기나 서비스를 이용하는데 불편함이 없도록 해야하는 것
• 꼭 해야 하나요?
• 법 - 규제대응
• 장애인차별금지법(장차법)
• 자발적 참여 - 도의적
• 무관심, 무관여, 무관찰
• 주변에 직접적인 관찰의 기회를 가진 사람들이 없다.
• Awareness : 결정권을 가진 분들을 대상으로 하여, 느낄 수 있도록 내재화 온오프라인교육
• 웹의 태생 자체가 장애인들을 대상으로 해서 태어나지 않았다. 이 부분에 대해서는 생각해볼 여지가 많구나. 내가 장애인이 아니기 때문에 공감하지 못하는 부분들도 분명히 있다. 만약, 내가 장애를 겪게 되었다면 어떻게 대처하는 것이 좋을까?
• 엔비전스(NVisions)
• 보편성
• 사용성에 대한 이슈 처리
• 접근성이란 무엇인가 느끼게 하는 것이 중요하다.
• 사용성이 떨어지진 않을까요?
• 대부분 ‘오히려’ 좋아진다.
• 적녹생맹 : 가이드라인
• 페이지 네비게이션, 가이드
• 고민되는 부분도 있다.
• 일반 사용성과 장애 접근성
• 장애인들은 각 요소들을 빠르게 뛰어넘는다.
• 새로운 것이 업데이트 되었다는 것을 알아야할 필요가 있는가?
• 새로운 것이 생긴 것보다는, 기존의 것이 유지되는 것이 더 중요하지 않은가?
• 얼마나 적용해야 하나?
• 어떤 서비스의 어떤 페이지에 어떤 수준으로 적용해야 하는가?
• 모든 서비스의 모든 페이지를 전부다 적용해야 합니다.
• 우선순위를 두고 점진적으로 적용
• 접근성에 대한 효율적 접근 또는 전략
• http://html.nhncorp.com/blog/42598
• 시각장애에 포인트를 두고 접근성을 해결하자
• 우선순위에 따른 점진적 적용
• 우선순위
• 소비성 컨텐츠 > 비소비성 컨텐츠
• 적용범위
• 모든기능 및 모든 페이지 > 동영상 > UGC
• 적용수준
• 시각장애 대응 수준 + 지체 장애
• 스킵 네비게이션
• 브라우저 타이틀
• 대체 텍스트
• 자동 재생 컨텐츠 제어
• 키보드 사용 보장
• 뭘 해야 하나요?
• 선형화 - Linearization : Make sense when linearized
• 시각장애인들은 마우스를 사용하지 않는다.
• 대체 텍스트 - Alternative Text : The use of alternative-text is fundamental to accessiblility
• 정보성 이미지는 대체 컨텐츠(텍스트를 제공)
• 대체 텍스트가 영문일 경우, 정확한 의미전달을 위해 국문으로 입력
• 적용범위 : 서비스 공급자가 제공하는 모든 정보성 이미지
• NWCAG 1.0
• 체크리스트
• 잘 모르겠어요
• Ajax application
• ex) 네이버 지도
• 지도는 적용하기 어렵다.
• 마우스 인터렉션 이외의 부분들에 대해서 지켜줘!!
• Fallback, text
• 동영상
• 이상적 : Html5 로 대체
• 현실적 : 키보드 조작이 가능한 컴포넌트를 제공하여 컨트롤
• 그래프(차트)의 대체 텍스트
• 복잡한 정보를 담고 있는 경우 모든 정보를 텍스트로 제공
• 복잡한 정보를 담고 있는 경우 모든 정보를 전달할 수 없기 때문에 정보를 요약하여 선언한다.
• 하긴 했는데 맞게 했나요?
• 누가 맞나요?
• UX 가이드
• 스킵 네비게이션
• 문서의 최상위에 위치, Tab키를 누르면 노출,
• Skip to main menu : 메인 메뉴 바로 가기
• Skip sub menu
• Skip to content
• 변하지 않고 고정된 3개의 Skip menu 를 제공(Tab을 이용) : 이것에 대한 적용은 장애인들의 웹사용방법에 대한 이해가 필요하겠다.
• 노출 인터렉션
• 자동재생 컨텐츠
• 컨텐츠 자동생신 문제점
• 페이지 리프레시, 리다이렉트
• 일정시간이 자니면 리프레시가 발생한다.
• 롤링컨텐츠
• 해당 컨텐츠를 만났을 때 사용자가 제어할 수 있도록 한다.
• 자동재생
• 제어 기능의 위치
• 웹 접근성에 대한 공감

• 정리
• 웹 접근성과 호환성(크로스 브라우징)은 다른 것이구나.
• 마우스 없이 키보드만으로 웹을 사용할 수 있다면, 그건 개발자들에게도 좋은 일이겠…지? 그걸 적용하는 건 귀찮은 일이겠…지?

• Track A, Session 4
• 발표자 : SKP 이동욱 매니저, Platform SW 개발팀
• Content
• Scala 맛보기
• 함수형 프로그래밍과 객체지향의 조우
• 패턴 매칭과 조우
• 정리의 시간
• 미지와의 조우 : Close encounters of the third kind
• 40분 동안 무엇을 할까?
• 주입식으로 결정
• 스칼라의 기본적인 뭄법을 주입식으로 익히고 자바에서 지원하지 않았던 몇가지 기능 확인
• Scala 맛보기
• Scala = Scalable Language, 마틴 모더스키?
• Scala는 JVM 위에서 돌아간다.
• Java의 성능과 유사하다.
• 스칼라의 표현력을 이용하여 세련된 프로그래밍이 가능하다.
• 인포그래픽으로 보는 Scala
• 스칼라를 유명하게 만든 건 트위터?
• 루비로 되어 있던 백단을 스칼라로 변경하면서 세간의 관심을 받기 시작
• 아직은 마이너리한 위치에 있다
• Scala는 하이브리드 언어
• Java, ML, Smalltalk, Earlang, Haskell, Eiffel
• Scala를 이용해 여러 언어들이 제공하는 특징을 접할 수 있습니다.
• 스칼라의 전반적인 모습
• Java Platform / .Net
• 강화된 타입 시스템(동적 타입 시스템)
• 객체지향
• 함수형 프로그래밍의 패러다임을 안고 있음
• REPL : Read -~~ command line
• Scala는 모든 것이 객체
• 엄청난 속도로 배우기!!
• 변수, 그리고 타입 추론
• val : read only, var = read-writable
• 함수 선언하기
• 중급편 들어가기
• Object 이해하기
• 튜플(Tuple) : 다른 타입의 자료를 담을 수 있는 그릇(Container Object)
• 튜플 패턴을 이용한 대입
• 각 자료형에 맞는 패턴이 있어 대입/반복문 등에 활용할 수 있다.
• List : Scala의 기본적 컬렉션 클래스
• Map : Key-Value 로 튜플을 만들어서 보관
• Option
• 존재할 수도/안 할 수도 있는 선택적인 값을 나타낼 때 사용.
• Key가 없는 경우
• Key는 있는데, 그 값이 Null인 경우?
• 언어는 어떻게 발전하고 있는가?
• 프로그래밍 언어가 추구하는 이상
• 문제 영역의 크기나 복잡도가 증가하여도 가능하면 간단한 표현으로 문제 해결이 가능해야 함
• 객체는 어떤 내용을 담는가?
• 객체에게 적절한 역할을 분배하는 쪽에 집중되어 있음
• 객체에게 역할을 부여
• 어떻게 흐름제어를 할 것인가?
• 어떻게 함수를 손쉽게 표현할 것인가?
• 프로그래밍 스타일에 따른 시간/품질 분석
• 함수형 프로그래밍과 객체지향의 조우
• 스칼라의 위치 : 함수형과 명령형의 중간 어딘가
• 명령구문을 많이 사용하면 명령형
• 명령어 위주 : if, for, while
• 함수호출을 많이 하면 함수형
• 함수위주 : pass, store, return 가능
• 함수 리터럴 선언
• 함수 리터럴을 이용해 함수를 인자로 전달하거나, 변수에 저장, 반환할 수 있다.
• Lamda 함수
• Collection에게 던져주기
• 루프를 이용한 List 조작하기
• Higher-order method로 List 조작하기
• underscore.js
• higher-order method 많이 사용
• Scala에서 자바를 보다.
• 패턴 매칭과 조우
• Programming in Scala
• 1/2 - 880p
• Scala의 패턴 매칭 - 기본 문법
• Match ~ case는 자바의 switch ~ case와 닮았어.
• 변수, 타입, 와일드 카드, 생성자 패턴, 시퀀스패턴(List), 튜플(Tuple), 패턴 혼합
• 패턴 매칭 : 객체지향적으로 개선된 분기문
• extractor를 통해 객체를 분해, 패턴으로 표현하기
• 정리의 시간
• 일단 학습 내용이 다양하다. 한번 봐선 잘 모른다.
• 자바는 기본
• 함수형 프로그래밍
• 여러 언어의 특징들을 익히게 된다.
• 꼬리 재귀, 패턴 매칭, 강한 타입 언어
• 타입의 설계및 qusgud rhksfus sodyd
• 동시성 관련 기법들
• 혼자하긴 힘들어요!
• 발표 이후 스칼라와 어떻게 만날 수 있을까?
• Programming in Scala
• 9월 18일부터 Martin Ordersky 의 직강 시작 @Coursera
• scala-korea
• Typesafe
• github 번역

• Track E, Session 5
• 발표자 : 권순선
• 구글 : 개발자 relationship, 개발자 지원
• 약력 : kldp, 삼성, nhn, google
• 발표에는 위트가 섞여 있어야 한다잉.
• 근무시간 :
• 8시 출근~5시 퇴근, 야근 아침 10시 출근~7시 퇴근
• 자율 출퇴근
• 자신이 자율적으로 필요한 시간을 조절할 수 있다.
• 자신에게 맞는 시간을 효율적으로 조절가능
• 보고
• 일한 것을 상관에게 보고
• 보고를 위한 형식적이고 소모적인 보고서를 만들어내야 한다.
• 내용에 집중하면 되고, 메일을 통해 보고
• 투명성
• 같은 팀, 옆팀이 뭘하는지 알 수가 없다.
• 직원들이 각자하는 일의 진행상태와 목표를 확인할 수 있다.
• 채용
• 채용이 까다롭지. 실무자들이 참가
• 실제로 같이 일을 할 사람들이 면접에 동참
• 같이 일을 하고 싶은지 동의되어야 통과된다.
• 실력이 있어도 통과하기 어려워질 수 있다.
• 매니저
• 관리자
• 마이크로 매니지
• 자율적으로 일하도록 냅둬
• 평가에는 관여, 일을 하는데 지시를 해서 움직이지 않는다.
• 우리나라 기업 임원
• 상향평가
• 직원들이 임원을 평가

• 정리
• 구글에 대한 개발자들의 관심이 높다.
• 구글의 내부적인 문화에 대한 소개와 관련된 내용은 익숙했다.
• 참관하는 사람들이 관심있었던 건, ’어떻게 들어갈 수 있는거지?’가 아니었을까?

• Track E, Session 6
• 발표자 : 이희승(Twitter 소프트웨어 엔지니어)
• 소개
• 네티란?
• 사용자들이 참관을 많이 했네.
• Java network application framework
• http://netty.io/
• @netty_project
• 비동기 & 이벤트 기반
• 요즘 추세는 비동기인가?
• 적은 자원, 스레드, CPU 사이클
• API 는 I/O 추상계층, 추상계층 API
• works with NIO, OIO ,AIO(Asynchronized) & more without many changes
• 잘 정의된 이벤트 모델 & 스레드 모델 : Well-defined event model & thread model
• Flexible event handling with bi-directional chain of responsibility pattern
• Promotes ‘separation of concerns’
• I/O Layer(netty)
• Protocol codec(Netty or user)
• Business Loginc(User)
• 구성요소
• 이벤트 루프
• 유사한 경우
• 윈도우 이벤트 dispatcher
• swing event loop
• reactor
• 사용자의 I/O 요청 처리
• 이벤트 루프 스레드 내에서 요청했을 경우 즉시
• 이벤트 루프 스레드 외에서 요청했을 경우 루프의 작업 큐에 넣어 스케쥴 처리
• 외부의 자극에 반응하고 파이프라인에 알림
• 데이터를 읽어들임
• 소켓 버퍼가 꽉 찼음
• 사용자가 원하는 임의 작업 실행
• 파이프라인
• BiDiCoR
• Bi-directional Chain of Responsibility pattern
• Similar to Servlet filters and decorator pattern
• Inbound Event
• 이벤트 루프가 발생시킨 이벤트(소켓 연결, 데이터 수신 등)
• 사용자가 작성한 inbound Event 가 수신할 수 있도록 해줌
• Outboud Event
• 사용자가 요청한 동작(쓰기, 읽기 일시중단 등)
• 사용자가 작성한 outbound event handler가 다른 핸들러에서 요청한 동작을 가로챌 수 있도록 해줌
• 최종적으로 루프에 전달되어 실제 I/O가 수행되도록 함
• Outbound Event
• 선형적으로 구성되어 있지만, 로직에 따라 다르게 구현
• Transports
• Handlers : Component
• 다양한 프로토콜을 제공해서 사용자가 사용할 수 있도록 하고 있음
• 자기만의 핸들러를 작성해서 사용가능
• I/O abstraction - Channels, Event loops and pipelines
• 이벤트 모델
• 기존 이벤트 모델
• 이벤트 = 자바 객체
• 이벤트가 발생할 때마다 자바객체가 생성되어 이것을 핸들링
• 효율성에 대한 의심이 생겨남
• 가정
• Is GC cheap?
• 작은 객체에 대한 GC 처리비용이 저렴하지 않았다.
• Can buffer pool beat JVM’s memory allocator?
• 자바기반의 메모리 할당을 빠르게 가져올 수 있을까?
• Too many state events?
• 사용자에게 제일 관심사항은 ’연결(Connected)’이다.
• new buffer is created on every MessageEvent
• GC pressure
• User has no cotrol over the buffer
• 사용자에게 제어권이 없지.
• No Buffered flush
• Every Write is an immediate flush.
• 모든 쓰기는 즉시 flush가 된다?
• Sometimes not desired?
• 새 이벤트 모델
• 이벤트 = 메소드 호출
• 상태 전이 단순화
• 핸들러가 수신 및 송신 버퍼를 만들어 네티에게 제공하면 지속적으로 재사용
• Bufferd flush
• Outboud 버퍼를 사용하지 않아.
• 훨씬 적은 GC 빈도
• 단점
• 이벤트 유형별로 메소드를 전부 정의해야함(코드 중복)
• 사용자 정의 이벤트 처리 어려움
• 별도로 UserEventTriggered 메소드 추가
• 스레드 모델
• 왜 필요할까?
• 잘 정의된 스레드 모델의 필요성
• 프레임워크에서 사용자의 코드가 어느 스레드에서 언제 실행될지 충분히 정확히 정의해야 함
• 프레임워크가 어느 정도의 Thread safety를 사용자 코드(e.g. 이벤트 핸들러)에게 제공할 것인가?
• 정확한 스레드 모델이 제시되지 않으면 사용자 코드는 방어적으로(또는 부정확하게 작성됨)
• 예 : 네티의 SSL 핸들러
• netty 4 스레드 모델
• 3.x 대비 이벤트 모델 개선과 함께 가장 중요하고 긍정적인 변화
• 네티는 핸들러가 @Sharable 어노테이션이 붙어 있는 경우가 아니면 절대 같은 핸들러 메소드를 동시에 호출하지 안흔다.
• 네티가 핸들러 메소드를 호출할 때 각 호출 사이에는 happens-before 관계가 성립한다
• 이벤트 루프는 항상 싱글 스레드로 실행된다.
• 테스팅
• 네티 유저의 테스트
• 네티는 EmbeddedChannel 이라 불리는 Channel 구현을 제공
• 사용자는 자신이 작성한 핸들러를 EmbeddedChannel 의 파이프라인에 추가하고 이벤트를 임의적으로 발생시켜 테스트
• 네티 자체의 테스트
• 각 트랜스포트의 정확한 동작을 확인하기 위해 모든 트랜스포트 조합과 주요 프로토콜 조합에 대해 교차 테스트 수행
• 모든 종류의 소켓 통신에 대한 테스트 처리를 함
• 자체 제공 핸들러의 경우는 EmbeddedChannel 을 이용
• 기타
• 생각할 거리
• Dynamic Event routing
• Statistical Distributed performance Analysis on mesos cluster
• 버전업 될떄마다 성능에 대한 이슈가 발생
• Management and monitoring
• Native Transport
• 추상화된 계층을 제거
• Scalable community
• 커뮤니티의 건전성을 어떻게 벗어날 것인가
• 이벤트에 대한 처리방식이 중요한 부분이구나.
• netty 4 alpha, 문서화 작업 등의 작업을 마친 후 beta 출시 예정(올해 하는게 목표!?)

• 정리
• Netty를 사용하는 사람들이 많구나.
• 비동기식, 이벤트 기반의 플랫폼들이 많은 인기를 받고 있구나.
• 개발자가 차분하고 우리말로 경건하게 발표하는 모습은 종교적인 느낌이 들긴 했다. ^^;

몇몇 분들과 이야기를 나누어본 결과, 2012 JCO 컨퍼런스보다는 더욱 실속이 있었다.

Google Engineering Culture 를 보면서 문화쇼크를 기대했었는데...

약간 못미친 감이 없지 않아 있다. ^^;;

약간 피곤하기는 하지만, 전체적으로 유익한 컨퍼런스 였다.

역시 여기서도 숙제를 찾아냈다. 웁스.