허니몬(Honeymon)의 자바guru

* 발표자 : 옥상훈, http://okgosu.net

* 관련자료

    * OAuth Core 1.0 Revision A : http://oauth.net/core/1.0a/

    * OAuth 2.0 : http://oauth.net/2/

* 인증이란?

* ID/PW 방식 인증의 위험성

* OAuth

* 사용자 입증에서 ID/PW 를 서드파티앱에 노출하지 않고 회원 인증할 수 있어야 함

* 서비스 제공자 입장에서는 인증한 API에 대해 권한을 부여하고 이에 따라 API를 제공할 수 있어야 함

* OAuth 버전

* 1.0 -> 1.0a -> 2.0 draft

* OAuth 적용기업

* Facebook

* Foursquare

* Daum

* NHN

* 국내는 아직 1.0a, 해외는 2.0

* OAuth 1.0a 작동방식

* 3-legged model

- User

- Consumer

- 서비스 제공자에게 컨슈머 정보를 등록해 컨슈머키(id)와 시크릿값을 발급 받아야 함

- Service Provider

* OAuth 인증 프로세스

- 써드파티앱은 회원을 서비스 제공자 화면으로 이동시켜 회원인증을 하면서 서비스 제공자로부터 접근토큰을 전달받음

- 서비스 제공자의 API를 호출할 때 접근토큰을 함께 넘겨야 사용가능

* OAuth 1.0a 개발은 서비스 제공자로부터 '접근토큰'을 발급 받기 위함

- 1단계 : 서비스 제공자에게 요청토큰을 요청함

- 2단계 : 화면을 서비스 제공자의 로그인 페이지로 이동시킴

- 3단계 : 서비스 제공자에게 접근토큰을 요청함

* OAuth 1.0a 전체 절차

* OAuth 2.0의 등장

* OAuth 1.0 의 불편한 점을 개선하기 위해 스펙논의

- 암호화, 다양한 앱 지원 등 애플리케이션에 대한 지원 강화

* OAuth 1.0 vs OAuth 2.0 비교

* OAuth 2.0 인증방식

- 3-legged

- 2-legged

* OAuth 1.0a 인증예제

* 네이버 카페 API 활용

* Consumer key, Consumer Secret 은 정확하게!

* 필수 라이브러리

- 인증 로그인화면을 띄우기 위해 WebView invisible 로 선언

* OAuth 2.0a 인증 예제

* 구글 Task API 활용

1. 인증시작

2. 회원로그인

3. 접근토큰 획득

4. API 호출

* 클라이언트 API KEY 생성

* HTTPS를 사용

* 인증서비스를 만들 때 고려사항은?

* 정리

이전다음

012

    플랫폼을 지향하는 서비스들이 대거 출현하고, 이 서비스들에서 OPEN API를 제공하면서 많은 매시업Mashup 서비스들이 출현한다. 이 과정에서 사용자의 인증 절차를 제대로 파악하는 것이 중요하다.

    플랫폼 서비스를 고려하는 이들이 OAuth 인증절차에 대한 좋은 이해의 장이 되었을 것이라 생각한다.

* 발표자 : 주종면

* MongoDB 공식 한국 사용자 그룹 운영자

- 사이트 : http://mongodb-korea.org

* NoSQL 개념

* IT 기술전망 : 클라우드, 빅데이터에서 많은 이야기가 거론됨

* Bic Data 솔루션

- 빅데이터의 수집과 저장기술 오늘의 소개 주제

- NoSQL, MongoDB, Casandra, Hbase

- 빅데이터의 추출과 분산기술

- Hadoop, Storm, Spark, Kafka

- 빅데이터의 분석 및 통계기술

- R, SAS, SPSS

* DBMS for NoSQL : 150여개

- NoSQL 제품군 : 유용성Availability, 일관성Consistency, 파티셔닝Partioning

- Key-Value Database

- Big Table Database

- Document Database

- Graph Database

* NoSQL 제품별 평가결과

- MongoDB : 평가기준에서 전체적으로 좋은 성능의 제품이 나타남

- Community Support 지원

* Data Modeling & 설계 패턴

* MongoDB주요 특징

- Humongos라는 회사의 제품명 

- JSON 타입의 데이터 저장구조를 제공

- CRUD 위주의 다중 트랜잭션 처리가 가능하고 인덱스를 통한 빠른 데이터 검색이 가능

- 분산/병렬처리MapReduce 기능을 제공

- 분산Sharding/복제Replica 기능을 제공

- RDBMS 에서는 대용량의 데이터 처리가 어려워질 수 있다

- Memory Mapping 기술을 기반으로 Big Data 처리에 탁월한 성능 제공

* Collection 생성 : 데이터 저장 가능공간 생성

- 비정형화된 데이터

- db.createCollection("emp", {capped:false, size:8192}); 8k -> 이 공간을 넘어서면 새로운 확장을 하기 위해서 대기상태가 자주 발생하게 된다. 

- db.emp.validate(); Collection의 현재 상태 및 정보분석

* 성능을 개선하기 위해서는 구조에 대한 이해가 필요하다.

* 논리적 구조

- 입력과정에서 생기는 extent의 사이즈에 대한 고려가 필요하군.

* MongoDB 설계 주요 특징

1. MongoDB는 데이터의 중복을 허용하며 비정형화된 설계를 지향한다.

2. MongoDB는 중첩 데이터 구조를 설계할 수 있기 때문에 불필요한 JOIN을 최소화시킬 수 있다.

3. MongoDB는 N:M 관계 구조를 설계할 수 있고 구축할 수 있다.

4. MongoDB는 Schema 중심으로 설계하지 않는다.

* OODBMS vs RDBMS

- Embedded Document

- Extend Document : 먼저 Root Document를 넣고, Root Document에다가 Document 추가

- Linking Document

* 설계패턴

* MongoDB 데이터 저장 구조(Embedded)

- 장점

1. Query가 단순해지고 Join 문을 실행할 필요가 없기 때문에 Document 단위의 데이터 저장에 효과적이며 빠른 성능이 보장된다.

2. 데이터 보안에 효과적이다.

- 단점

1. Embedded 되는 Document의 크기는 최대 10MB  내외

* Manual Linking

- RDBMS : relationship을 통해 제한

- OODBMS : 

- 장점

1. 별도의 논리적 구조로 저장되기 때문에 Document 크기에 제한받지 않는다.

2. 비즈니스룰 상 별도로 처리되는 데이터 구조에 적합하다.

- 단점

1. 매번 논리적 구조간에 Linking해야 하기 때문에 Embedded보다 성능이 늦다.

2. Collection 갯수가 증가하며 관리비용이 많이 든다.

* 만들고자 하는 데이터의 패턴을 고려하여 적합한 설계패턴을 고려해야한다.

- 설계에는 답이 없다.

* Self reference join

* 계층형 데이터 구조

- ANCESTOR, PARENT 를 이용하여 계층혀 데이터 구조 설계 가능

* Inheritence(OODBMS) : 상속 

- 데이터가 저장되는 시점에서 필드와 크기가 저장되기 때문에, 별도로 표현할 필요가 없다.

* MongoDB 성능 튜닝 솔루션

* 적절한 분석을 통해 최적의 컬렉션 구조를 설계하라.

* 빅 데이터의 빠른 검색을 위해 인덱스를 적절히 활용하라.

- 다양한 인덱스 종류

- TTL index : 2.0 에서 추가됨 

- GeoSpatial Index : 좌표정보(위도, 경도, 온도)

* MongoDB의 분산Sharding/복제Replica를 적절히 활용

* Database profiler

- 성능 저하 요소를 찾아 튜닝

* Hint 절과 실행계획

- DB에서 말하는 Hint는 뭐지? +_+)?

* 빅데이터 추출 및 분석

- MongoDB의 Map/Reduce 기능을 이용한 빅데이터 추출

- Javascript function으로 구현

- Aggregation Framework 를 이용해서 기본적인 추출 가능

- MongoDB 와 Hadoop을 연동한 데이터 처리

- Map/Reduce in Python

* Sharding

* MongoDB Architecture

- 좋은 시스템보다는 충분한 메모리 용량이 있을 때 성능만족!

* 정리

이전다음

01234567

    딱, 'DB 전문가'의 느낌이 나는 발표였다. ^^; 몽고DB를 사용할 때 주의해야할 요소요소들을 콕콕 찝어주었다. NoSQL 관련 DB 중에서 가장 높은 선호도와 기술안정성을 가지고 있는 것이 MongoDB기에 많은 사람들이 NoSQL 관련 DB를 고려할 때 우선적으로 떠올리는 DB이기도 하다. 몽고DB 도입시 고려사항들에 대해서 상세히 잘 이야기해주셨다.

    내가 'MongoDB'를 사용하고 경험할 수 있을 때가 언제 오려나~?

* 발표자 : 조대협(조병욱), http://bcho.tistory.com

* 발표자료 : http://bcho.tistory.com/717

* 서버 사이드 개발 

* 모바일 개발쪽으로 엔지니어들의 대거 이동이 일어남

* 4가지 이야기

* 개발프로세스

* 개발도구

* 아키텍처

* 테스트 

* 요즘 트렌드는?

* 서버 사이드 트렌드가 많이 바뀜

- 과거 : EJB, WebLogic만 알면 되었다.

- 벤더를 이용한 테스트 가능

- 현재 : 동물원처럼 tomcat, camel, 코끼리 등

* 소규모(10~20)

* 새로운 트렌드에 대한 수용이 용이함

* 끊임없이 공부, 사람이 재산

* 개발 프로세스 : 소프트웨어 개발 현실 

* 개발자의 현실

* 관리자의 현실

* 소프트웨어 결과물

* 망한 프로젝트가 없다 : 망하기 전에 차세대 진행!

* RUP, CBD, MUI, 방법론

- 방법론은 방법론

- 소프트웨어 개발은 하향평준화 해야한다.

- 웹 서비스는 어렵다.

- REST

* 하향 평준화 : 실용적으로 개발하자

- 기존 방법론과의 차이점

- 요구사항이 변한다는 것을 인정하다.

- 에러가 있음을 인정하여, 자주 테스트

- 협업과 커뮤니케이션

- 애자일 방법론 적용시 자신의 조직 문화에 맞춰서 해야한다.

* 대표적인 개발 방법론

- 스프린트

- 매니지먼트 쪽에서 가시성이 나타나지 않음

- 대안 : Big Umbrella 방법론

- 관리층에게는 예측성, 실무진에게는 가시성

- 각 단계를 스프린트 형태로 세분화하여 애자일 방법론 적용

- 제약

- 어떻게?

- 어려운 것, 중요한 것 먼저

* 테스크 흐름을 만듬

- 태스크를 하루나 이틀의 크기로 나눠 주어야 한다.

- 팀의 속도, 예측이 가능하다.

* 도구들 : JIRA, Redmine, Trac, Mantis

- off site 개발에 유리

- 도구는 도구일뿐, 프로세스를 정립하고 실천하는 것이 우선!

- 실무 적용 : 이슈를 등록하고, 이 이슈를 내가 하고 있는 일을 다른 사람에게 전달할 수 있는 형태로 전달

- 디테일한 기록을 남기기 위해서

- 내가 휴가를 떠나더라도, 다른 사람이 노트만 보고 일을 할 수 있도록 해준다.

- 도구를 공부하는데 너무 많은 시간이 할당된다.

* 엑셀부터 시작하세요.

- 프로젝트의 흐름을 몸에 익히는 것이 중요하다.

* 스크럼, 툴 등 자신에게 맞춰서 하면 된다.

* 개발방법론은 한가지만 사용하지 마라.

- 린(큰 그림), 스크럼(작은 업무처리를 어떻게 할 것인가), XP(커뮤니케이션)

* 개발환경

* 소스 체크아웃 -> 작업 확인 -> 코딩 -> 빌드 등등...

* 툴셋업 보다는 실천

- 커밋 후 일일 빌드

- 일일 빌드 후 메일 알림 처리, 빌드 처리

- 80% 라인 커버리지 

- 빌드 태깅, 테스트 자동화

* daily check out & commit

- 소스 형상화 최신 상태 유지

- SomeUI

- REST API만 테스트

* DEV, QA & STAGE

- 자동빌드 -> 배포시스템(Python Fabric, Ruby Capistrano) -> DEV -> QA -> STAGE

- Python Fabric, Ruby Capistrano : 하루 이틀 정도로 할 수 있을까?

* 아키텍처

* 기술 트렌드의 변화

- 기업 중심의 벤더 주도형 : 기업 중심의 벤더 주도형

- 웹로직, 오라클, EJB, J2EE 몇몇 기술만 알던 시대

- HP 수퍼돔 같은 소수의 대형 서버

- 벤더 지원

- 현재의 기술 트렌드 : SNS 중심의 서비스회사 주도형

- 수 많은 오픈소스 조합

- x86기반 분산 시스템 클라우드 컴퓨팅(Devops)

- 구글

- 개발자가 똑똑해진 시대가 되었다.

* 아키텍처 설계순서

1. 비즈니스 아키텍처

- 비즈니스 관점

2. 시스템 아키텍처

- 아미텍쳐 기본Architecture Principals

- Application Architecture

1. Static Arch.

2. Dynamic Arch.

3. interface Arch.

- Technical Architecture

1. SW deployment arch.

2. HW deployment arch.

- Data Architecture

- Reference Architecutre를 찾아라.

- Reference Arch

- Vendor Consulting

- Case study

3. Architecture Decision Process

- 기술트렌드 : 장애가 나면 빠르게 고치는 것으로 변화

* 일반적인 서버 아미텍처

- 내부 트랜잭션 처리

- 시스템간 연동

- 통계 분석

- 운영

* 레퍼런스 아키텍처 

- User Interface Layer

- Access Layer

- Business Component Layer

- Stroace Layer

* 솔루션

- Apache Camel : 외부 연계가 쉬워?

* Global roll out 시스템의 설계

1. 위치선정

- 법적 이슈 : Regulation

- 회선 속도

- 세금

- 3센터 : 미서부, 영국, 중국

- 중국은 서비스하려면 중국내에서 위치해야하며, 26개 성에 각각 있어야 한다.

2. API 라우팅

3. 데이터 복제

- ETL, CDC

- 과연 데이터 복제가 필요할까?

* 클라우 컴퓨팅상의 아키텍처 설계

- 클라우드 컴퓨팅의 장점

- 빠른 시장 진입

- 운영비 절감

- 초기 투자비용

- 유연한 자원

- 설계시 고려사항

- 느려요 :IO Performance

- 싸지 않다.

- 자신에게 맞는 환경을 선정하는 것이 중요

- 기존 솔루션이 안돌아요

- 장애가 납니다.

* 언어 트렌드

- 스크립트 언어 하나정도는 더 해놔야...

* 테스트

* 테스팅 모델

* 테스트 레벨별 키 포인트

- 단위 테스트

- 통합 테스트 : End2End 시나리오 : 웹은 화면, 단말은 단말에서, 기능검증은 다른 사람이!

- 시스템 테스트 : 성능, 장애, 확장성(증설에 대한 안정성), 안정성

- 마이크로 벤치 마크 테스트

- 기술검증, 1~2일 소요, 30 vuser 정도의 부하

- SOAP UI, Python

- 부하테스트

* 코드 리뷰

- Peer review -> Walk Through -> **Team review** -> Inspection

- Team review가 가장 효과가 좋았다. 

* 정리

이전다음

01234

    서버 관련 기술을 검색해보면 많이 나오는 블로그 '조대협의 블로그'를 운영하고 있는 조대협님의 발표다. 삼성에서 아키텍트로 근무하고 있으며, 수원에서 일할 개발자들을 찾고 있다. 처음듣는 조대협님의 발표였다. 꽤 많은 준비를 해온 것으로 보인다. 발표하는 중간중간 가벼운 이야기로 분위기를 전환하면서 이야기에 대한 집중도를 유도하는 기술도 좋았다.

    JCO에서 들었던 발표자들 중에서는 잘준비된 발표였다. 기술 트렌드나 서버 사이드 개발과 관련된 4가지 주제로 잘 정리된 이야기도 괜찮았다. 전체적으로 흠을 잡을 데 없는 발표였다.

    발표 이후에 발표자료도 자신의 블로그에 빠르게 공개하셨다.

* 발표자 : 박상근

* 공식 홈페이지 : [PyLatte](http://pylatte.org/)

* 스프링 

* Get started

* 토스 3.1, 두꺼워서 베개로도 사용하지 못한다

* 왜 거론했을까? 

* 파이썬 기반 웹 프레임워크

* Django, Webpy, Bottlepy

* python3를 지원하지 않음

* 친구들과 고민하다가 파이썬3으로 프레임워크를 만들어보자

* PyLatte, 카이스트 지식서비스공학과 석사과정

* 구조 

* Django 와의 비교

* python 문법, 상식과 다름

* html 안에 Python 문법 적용해서 사용가능

* 간단해서 탈락 -> 너무 심플하다?

* 기능

* URL Mapping

* Database

- db-mapping.xml

- sql_ex.html

- java iBatis 차용 

* Dictionary : Get/Post -> param 에 모두 합류

* {$ $}

- {$= session[''] $}

* Download

- github : 

- pyPI : [Pylatte 1.0](https://pypi.python.org/pypi/Pylatte/1.0)

- PIP : pip-3.2 install pylatte

* 데모시연

* python 으로 가볍게 MVC1 방식(Servlet)으로 구현한 것 같잖아? ㅡ_-)?

* 말하고 싶은 이야기 : 파이라떼를 만들면서 겪은 이야기들을 나누고 싶었다. 

* Python의 창시자 귀도 반 로썸의 Pylatte 언급

* 첫번쨰 Python 3 웹 프레임워크

* 아직도 python3 가 확산이 안되어 있다는 거구만.

* 무료 홈페이지 영어 교정 : 메일을 주고받으면서 교정받음. 좋구만!

- 인문학(영문학)을 전공한 개발자라...

* 듣다보면 화가 나고, 우울해지고?

* 단순했던 기능들이 '너무 단순하다.' 라는 멘토들의 조언에 따라 Servlet, iBatis를 Python으로 옮겨구현했다는 이야기를 들으면서 어이가 없어서 '피식' 웃었다. 

* 한국인은 칭찬에 인색하다?

* Feedback

* 오픈소스 참여

* 정리

이전다음

01234

    2번째 세션은 '그냥 사람들과 모여서 이야기를 나눴으면 좋았겠는걸?' 하는 시간대였다. 딱히 메리트가 없는 발표이 모여있는 시간대였다. 나한테는 말이다.

    발표내용을 정리해보면 **Python3 을 기반으로 하는 웹프레임워크 'PyLatte'를 국내에서는 최초로 만들어서 '공개소프트웨어 개발대회에서 수상'**했다.

    내가 파이썬이라는 개발언어를 많이 접하게 된 건 3~4년 정도 된 듯 하다. 파이썬을 배워야지 하면서 맨날 변수, 함수 부분에서 맴돌고 있는 상황이지만, 이것도 돌파를 해야지.

    딱히 스프링을 걸고 넘어갈만한 그런 요소들이 없는데, 왜 스프링을 걸고 넘어가는지는 이해가 안되었다. 파이라떼와 스프링의 프레임워크로서의 목적이나 위치가 전혀 다른데 굳이 '도발'식으로 개발자들을 모으려고 했던건가 하는 생각은 지울 수가 없다. 자신만만했던 발표와는 다르게 딱히 매력적인 요소는 없었다. 자바에서 Model1 식으로 서블릿으로 HTML코드를 생성하고, iBatis를 이용해서 SQL을 관리하고 DBMS와 연동하는 거랑 별다른 차이점을 못느꼈으니까.

    개발하는 과정에서 '너무 쉽다.'라는 '멘토'의 이야기를 들으면서 어이없다는 생각도 한다. '단순함'의 아름다움을 모르는 고지식한 '전문 심사위원' 교수님들이 왕성하게 활동하고 있는 '공공기관' 지원 행사들은 문제가 많아보인다. '독창성', '창의성'과 '참신함'을 중점적으로 평가하는 것이 좋은 '개발대회'에서 '트위터'나 '페이스북' 같은 그럴싸한 상품을 바라는 사람들이 '멘토'라고 활동하는 것이 안타깝다.

* 발표자 : 이용혁(ItemBay)

* Server

* Database

* 쓰던거 쓴다! MySQL, 

* 이중화 + 세션 클러스터링

* nginx + tomcat + RDB

* 추가증설에 대한 고민

* 세션클러스터링의 한계 : 클러스터링 하다가 많은 서버들이 복잡하게 연결

- 사용자가 집중되었을 때 문제가 발생할 가능성이 있다.

* 대책

* tomcat간의 세션 클러스터링 포기

* 세션 대신 쿠키 사용

* 쿠키에는 KEY값 저장

* 업무에 필요한 사용자정보는 DB저장

* DB의 집중 문제가 발생!

- 로그인 20여 만건 이상 : 성능상의 이슈가 발생

* Cache Server!!

- 세션정보를 저장

- 자주 사용되는 항목들 저장

- 물리적인 서버 추가는 힘들다.

- 기존 WAS의 남는 리소스에 띄운다.

- 여러 WAS에 분산가능해야 한다.

- Open Source

- infinispan : http://www.jboss.org/infinispan

- Transactional in memory key/value NoSQL database & Data grid

- JSR 107, JSR 347 완벽지원

- 무료!!

- etc/cluster.xml 설명

1. eviction : 자신이 실제로 데이터를 가지고 있는 수 지정

- etc/jgroups-tcp.xml : 통신 설정 정의

1. <TCP ... /> -> <MPING ... />

2. 멀티캐스트 IP를 가지고 있는 것들끼리 내부적으로 그룹화처리됨

서로 공유한다

- bin/sc01.sh

- bin/sc02.sh 

- java pom.xml

- tomcat7 과 부딪치는 것 때문에 <execution />으로 infinispan 을 제외시켜주어야 한다.

- Java : hotrod-client.properties

- 접속할 서버 리스트 : 중점적으로 접속할 서버만 설정해주면, 자동으로 연결되면서 자동처리됨

- java : Default Util

- RemoteCacheManage

- RemoteCache<Object, Object>

- java : Session Util

- java : Session Interceptor

* tomcat + was 2대 + infinispan 4대

* Cache는 메모리에 저장

* 시스템 다운시 데이터 사라짐

* 캐시 사용으로 이점이 있지만 문제 상황에 대비해야함

- Down시에는 다시 DB 사용

* 메인 DB를 사용하기에는 부담

* NoSQL 사용

* NoSQL에 대한 고심

* MongoDB, Cassandra : MongoDB 사용, 기존에 사용해왔고 내재화가 잘 되어 있음.

* 무료기술지원 : Google!!

- 무료기술지원 : www.mongodb.org

* Java  : Session Util 변경

- 캐시에서 가져와서 null인 경우 몽고DB에서 가져오면서 캐시에 등록

- 데이터 저장시 : 몽고DB에 우선 넣고 성공시 세션에 추가하도록 구현

- 분당 요청 : 3~5000, 몽고DB의 리소스 사용률은 지극히 낮다.

* RDB + MongoDB

* 이중화 + 클러스터링 되어 있어서 특정 서버가 정지하더라도 안정적인 작업이 가능

* 서버 구성 

* Nginx 1.2

* Tomcat 7

* infinispan 5

* mongoDB

* RDB

* Spring 

* 분산처리(멀티 스레드 환경 포함)에서는 static 으로 선언해주는 것이 중요하군.

* 정리

* 오픈소스 기반으로 구축

* 쉽고 빠른 확장

* 성능저하 최소

- 성능의 저하요소 : DB의 성능저하가 없는 이상 별다른 성능저하 요소가 없음

- DB 성능만 받쳐준다면 앞에 서버들은 언제나 확장 가능

* 관리이슈 증가 : 캐시서버의 상태 관리

* 담당자들의 역량 중요 : 오픈소스 사용한 프로젝트는 담당자들이 해결해야 함, 기술 내재화에 대한 장단점

- 비용은 감소, 담당자들의 역량은 강화

이전다음

0123456789101112131415

최근에 유행하고 있는 기술 트랜드의 중심은 오픈소스다. 과거 엔터프라이즈와 벤더 중심에서 오픈소스로 넘어오기 시작한 것이다. 오픈소스라고 하면 공짜의 느낌을 강하게 받는 사람들이 많은데, 전혀 '공짜'가 아니다. 기술을 사용하는 것은 자유로울지 모르지만, 그 기술을 사용하기 위해서 들여야 하는 노력(오픈소스를 하면서 생길 수 있는 '오류'나 오픈소스에 있는 '결함'을 해결하거나 우회하기 위한 파악)이 필요하다. 

이런 노력은 그 기술을 도입하는 조직이 '일정 크기'이상의 규모를 지녔을 때 감쇄효과가 있다.오픈소스를 사용하기 위해 중요한 것은, 그것을 조직 내부의 것으로 만들 수 있는 내재화를 하는 것이다. 벤더의 기술을 사용할 때와는 달리, 오픈소스를 사용하면서 생기는 시행착오와 오류를 해결하는 것은 전적으로 조직 내부와 외부의 지원(오픈소스 관련 커뮤니티 활동성과도 관련이 커질 것이다) 정도에 달려있다고 본다. 이런 의미에서 보면 오픈소스를 도입하고 적용하는 것은 역시나 인적-물적 자원이 풍부한 대기업이 앞설 수밖에 없다고 본다. 최근 인력이동의 시기에 맞춰서 내가 아는 조직들 사이에 인력유출과 인력유입이 활발하게 진행되고 있다. 이런 인력유동 현상은 '오픈소스'에 대한 역량을 격동시키는 큰 요인이될 수 있을 것이라 예측해본다.

컨퍼런스에 참관하러 가서 듣고 싶은 것 중에 하나는 '새로운 시도에 대한 시행착오와 그것을 해결하기 위한 시도들에 대한 이야기'이다. 그런 의미에서 본다면 만족스런 발표였지만, 한편으로는 내가 nginx, infinispan나 mongoDB에 대한 이해나 경험이 부족한 탓에 충분히 이해하지 못하였다는 불만도 있겠다. 이 만은 결국 내 부족함에서 시작된 것이지.