KCD(Korea Community Day)를 다녀와서

발표자료는 http://kcd.onoffmix.com/program.php 여기서 받아볼 수 있습니다.

-       모바일의 미래 그리고 앞으로의 전망

n  iOS의 생태계는 망가짐

n  모바일 개발을 할 때 도움을 받는 곳

1.      stackover flow

2.      GitHub를 통해서, Library를 다운받아서 코드를 본다.

3.      코드를 decompile를 통해서 실마리를 잡아간다.

4.      지인을 통해서

5.      opensource를 통해서

6.      커뮤니티를 통해서

u  그러나 일정수준을 넘으면, 정보가 부족해지며, 정보에 대한 공유가 안 된다(그래서 내가 올려야 한다.).

-       클라우드 서비스 브로커(CSB – Cloud Service Broker)가 가져올 클라우드 세상(장선진)

n  brokerage

1.     중간자 역할

2.     가트너가 생각

n  right scale

1.     AWS를 관저해줌

2.     다른 cloud서비스를 연결해 줄 수 있다.

3.     CSB서비스의 근간이 됨

4.     뭔지 한번 찾아볼까?

n  프로그래밍 언어의 변화

1.     언어의 형태에 따라, 그 특성에 따라 사용하게 된다.

2.     Back-End는java, CSS는Ruby, javascript 등 하나의 프로그램에 각각 구현되는 모듈 및 환경에 따라 다른 언어를 사용한다.

n  PaaS(Platform as a Service)

1.     PaaS 마켓이 성장하고 있다.

2.     어떤 서비스의 사용량 등 통계를 내줄 수 있게 됐다(이게 맞나?).

3.     App을 지속적으로 사용하는 경향이 생김

4.     클라우드 위에서 내가 원하는 서비스를 빠르게 사용하는 방향으로 바뀜

5.     그러하기에 누가 이런 것들(클라우드 뒤에 있는 리소스들)을 관리 할 지가 중요해짐

n  CSB IO

1.     점점 Cloud Service는 zero base를 가고 있다.

n  Easy Cloud Service

1.     cloud platform을 이해할 줄 아는 개발자 à 생각의 영역을 넓혀 준다.

2.     고로 공부해야겠지?

n  Community & Company

1.     새로운 것을 찾아서, 모여서 함께 공부하는 것

2.     큰 비전을 가지고 앞으로 나간다.

n  질문시간이었음

A.     cloud자료를 공부할 수 있는 곳

                                  i.         cloud서비스관련해서는 아직 정리가 안되어있는 상황

                                 ii.         EaaS(뭐지?): 기존 서비스를 cloud서비스로 전환(AWS Image서비스를 보면 공부할 수 있다. 그러닌까 AWS를 써봐야겠다.

B.      Openstack, Cloudstack, 보안 솔루션(왜 적은거지?)

 

-       오픈소스 커미터 과연 개발의 미래인가? (이희승, 김남형, 박현우, 조현종, 진성주)

n  참여했던 오픈소스, 참여하게 된 계기

1.     이: netty work framework(library, framework)를 개발

2.     김: linux kernel

A.     OS가 궁금해서 시작, 내가 사용하는 것들이 어떻게, 그리고 수치적으로 보고 싶어서

B.      scheduler, file descriptor, memory영역의 소스를 직접 공부

3.     박: mpk라는 오픈소스를 진행

4.     조: parse system 개발, 올챙이라는 오픈소스 진행 중

5.     진

A.     user grid라는 오픈소스를 진행 중.

B.      게으름 때문에 내가 편하려고 참여하게 됨

n  커미터가 되는 법

1.     진: 기업에서 진행하는 프로젝트는 진정한 의미에서의 커미터가 될 수없다. 기업 프로젝트에서의 커미터는 위에서 인정을 받아야 하기에

2.     조: 개인 간의 오픈소스에서는 개인간의 친분를 통해, 이 말은 신뢰를 쌓아야 한다. 실력보다는 신뢰가 중요

3.     박: 커미터가 되는 것이 곡 오픈소스에 참여하는 것만은 아니다(그래서 내 생각은 GitHub공부?).

4.     김: Linux kernel개발의 경우 참여인원이 많다. 그 중maintainer(?)활동을 활발이 하면, 커미터가 될 수 있다.

5.     이: 다른 사람의 수정 사항에 대한 활발한 review를 해주고, 또한 그 프로젝트에 대한 기술적 지식을 가지고 있고, 프로젝트 참여할 수 있는 시간을 가지고 있어야 함

n  오픈 소스를 하는데 있어서

1.     진: 단순히 코드만 open하는 것이 아니라, 꾸준히 코드에 관심을 가져야 한다.

2.     김: Linux 커널. 홍보가 아직 부족

3.     진

A.     오픈소스 재단, 비영리 단체가 하는 일

B.      Donation에 대한 세금 문제, 각 종 기술 외적인 부분을 도와준다. 이런 커뮤니티에 참가하는 것도 하나의 방법이다.

n  오픈소스 vs. 상용 서비스

1.     박

A.     오픈소스를 사용함으로써, 그것을 만든 열정적인 개발자에 대한 가치를 높여주는 것이므로, 장기적인 관점에서 오픈소스를 사용하는 것이 더 장점이 있다고 생각함

B.      그러나 오픈소스에 대한 우리나라 정부의 참여가 과연 올바른가?

C.      오픈소스의 contents가 더 중요하다.

2.     진

A.     국가란 자국민의 이익을 보호해주어야 하는 큰 틀. 그 큰 틀을 벗어나지 않은 선에서 오픈소스 vs. 상용서비스의 구도를 말하기보다는 그 소프트웨어의 contents가 더 중요함

B.      오픈소스에 대한 사용은 더 좋은 contents의 중점을 두고, 상용서비스는 모든 기업에 고른 기회를 제공할 수 있도록 한다.

n  오픈소스를 하게 된 이유

1.     이

A.     공개함으로써 누릴 수 있는 과정(프로그램이 성장해가는 과정)의 즐거움이

B.      공개를 함으로써 프로젝트가 더 성공에 가까운 데로 가는 듯

2.     조: 다른 사람들과의 정보 공유를 위해, 그 동안의 다른 사람들에 대한 고마움에 대한 하나의 표현

3.     박: 개발을 좋아하는 개발자가 자신의 프로그램이 더 알려지는 것이 더 의미 있다(난 개발을 좋아하나?).

n  오픈소스 vs. 회사

1.     김: 업무의 일부는 회사와 상의. 업무 외적으로는 분리가 되지 않을까?

2.     박: 비즈니스 로직이 들어가지 않은 것은 공개해도 상관없을 테고, 제품 중 수익에 영향을 주지 않은 부분의 기능이라면, 일부분을 공개하는데 있어서 회사도 이해하지 않을까?

3.     조: 이왕이면 자문을 구하는 것이 좋을 듯

n  해외 개발자와 국내 개발자간의 의사소통의 차이점은?

1.     이: 언어적 장벽 외에는 큰 차이가 없음

2.     진

A.     오픈소스 프로젝트 내에서는 남을 설득하는 것이 중요

B.      코드 다음으로 중요한 것은 언어 능력 상승

3.     김: 두 개발자간의 차이는 없다. 국내 개발자의 경우 시작에 대한 두려움이 있다. 용기가 필요한 듯

4.     조: 직접 해보는 것. 글 쓰는 것에도 패턴이 있다. 직접 써보고, 훈련하는 것

n  오픈소스하면서 생긴 사람들과의 관계(갈등)

1.     이

A.     성향의 차이가 생김 à 갈등

B.      대화를 통해서, 내가 한 발짝 물어날 수 있는 지혜

C.      프로젝트의 일고나성이 보장되어야. 프로젝트가 하나하나 나갈 수 있음

D.     토론의 기법 à 합리적인 결과를 낼 수 있도록 하는 대화법(의식적으로 생각해서 대화하도록)

E.      오픈소스를 함에 있어서의 매너 à 짜증을 유발하지 말자

2.     김

A.     반복적인 질문은 옳지 않다. à 잘 정리되어 있는 문서가 있으니 그걸 잘 보도록

B.      오픈소스 그룹 간의 대화는

                                  i.         contribution에 대한 참고 à 큰 오픈소스 프로젝트에는 잘 정리되어 있으니 한번 보면 좋을 듯

C.      IIC라는게 있는데 live하게 communication하는데 꽤 좋은 tool이다.

D.     프로젝트의 주최가 되는 그룹을 만들어야 한다. 모임의 중심이 되는 것이 있어야 하며, 그들을 통해서 문화를 만들어야 한다.

 

-       아키텍트의 길을 묻다. (박성선, 신연복, 강승준, 장선진)

n  토론 중간에 들어가서 질문이 뭔지 모른다.

1.     신: 가장 초기 문서 작성이 중요하다.

2.     강

A.     아키텍트는 철면피적인 성향이 있어야 한다.

B.      그렇다고 아키텍트가 슈퍼맨은 아니다. 그러나 기술에 대해 알고 있어야 한다.

C.      현재 기술은 하루가 다르게 새로운 것이 나온다. 다 알 수 없음을 인정 à 그러나 공부해야 한다. 그리고 다른 전문가를 통해 배운다(know where, know who).

n  아키텍트의 뛰어난 능력은 모든 분야의 아키텍트에게 무조건적으로 필요한 능력인가?

1.     박: 모든 분야가 그렇다. 각 분야 별로 아키텍트가 필요하다.

2.     신

A.     (의료서비스를 예를 들면)의료서비스 또한 프로세스가 있다.

                                  i.         어떤 서비스를 진행할지, 어디에 새로운 빌딩을 건설할지 등을 위한 프로세스가 있다.

                                 ii.         이러한 프로세스가 개발 프로세스와 비슷하다.

3.     강

A.     소프트웨어 아키텍트에 더 많은 것을 요구하는 것 같다.

B.      가시성의 차이

                                  i.         하드웨어 설계는 계산에 대한 결과값을 눈으로 확인할 수 있다.

                                 ii.         그러나 소프트웨어는 눈에 보이지 않는다. à 보이는 건 사람 밖에 없다. 아키텍트를 보고, 아키텍쳐를 상상하게 된다.

n  개발자는 아키텍트 아니면 슈퍼 개발자 무엇이 되어야 하는가?

1.     박: 성향의 차이

A.     아키텍트가 아이디어가 있을 때 슈퍼 개발자가 필요하다.

B.      현재 우리나라에 필요한 건 한 분양의 슈퍼 개발자(누구에게나 멘토가 될 수 있는)

2.     신: 슈퍼 개발자가 되기 위해서는 리스크를 가져야 한다.

A.     그래야 자신의 브랜드를 완성할 수 있다.

B.      최소 5~6년의 투자가 필요하다.

C.      나만의 솔루션을 가지고 있어야 한다.

n  아키텍트가 되기 위해, 그리고 설계의 단계를 경험해 볼 수 있는 know-how는?

1.     신

A.     기본적인 틀을 잡는 것은 거의 비슷하다.

B.      도메인 지식은 2년이면 알 수 있다.

C.      사람의 흐름을 보고, 요구사항을 도출할 수 있는 능력을 가져야 한다.

n  아키텍트의 덕목. 아키텍트는 고객의 편인가? 개발자의 편인가?

1.     박

A.     아키텍트는 App의 효율성을 위해 대립할 수 밖에 없다.

B.      아키텍쳐는 기준이 없으면, 설계를 할 수 없다. 견정한 후, 그 다음을 고민해야 한다. à 아키텍쳐 또한 보이지 않는다.

C.      아키텍트는 귀를 열어야 한다.

D.     client <-> 아키텍트 <-(신뢰가 중요)-> 개발자(패턴을 중요시 함)

E.      모든 프로젝트는 유니크하다. à client의 기준이 다 다르다.

2.     강: 아키텍트 또한 회사원이다.

A.     시스템을 성공시켜야 한다. à 성공을 위해 조율해 나갈 수 밖에 없다.

n  아키텍트도 하고 싶고, 개발자도 하고 싶은데

1.     박: 개발하면서 아키텍트는 어렵다. 개발하면서 큰 흐름을 파악하기는 어렵다.

2.     신

A.     개발하면서, 아키텍트를 하려면 회사를 차리면 된다.

B.      오픈소스에 참여. prototype을 만들면서

C.      한 분야를 10년은 해야 하지 않을까?