Deview 2014 관람기

• Deview 발표프로그램: http://deview.kr/2014/schedule
• Deview2014 기록전 문서(Writed by markdown

8번째 DEVIEW라고 했던가? DEVIEW는 워낙 인기가 좋은 컨퍼런스다보니 늘 참가신청 하기가 쉽지 않았다. 올해에도 참가신청을 하는데 1차에는 1분, 2차에는 50초(다행히 2차에서 참가신청을 할 수 있었다)만에 참가신청이 완료되는 진기록을 세웠다. 모두들 어떻게 그리 재빠르게 신청을 하는지 놀랍기 그지없다. ㅎㅎ

지금 회사에 입사한지 이틀만에 컨퍼런스에 참가한다고 하는 것이 약간 눈치가 보이기는 했지만, 어쨌든~ 입사하기 전에 신청한 컨퍼런스이고 한번은 가봐야겠다는 생각을 가지고 있었기에 비오는 날에 롯데호텔로 향했다. 교복을 입은 학생들도 꽤 많았는데, DEVIEW에 대한 높은 관심을 옅볼 수 있었다.

● Keynote

현재 하드웨어는 성능적인 한계에 도달하였다. CPU의 클럭속도는 당분간 상승할 수 없는 상황(트랜지스터의 집적률이 높아지면서 그로 인해 많은 전력을 필요로 하고 높은 열이 발생하는 벽에 부딪쳤다)에 도달하면서 멀티코어 아키텍처쪽으로 방향을 잡았다. 과거 싱글코어에 익숙한 프로그래밍을 하던 개발자들은 이 멀티코어를 활용하여 성능을 향상시킬 수 있는 프로그래밍을 할 수 있는 능력을 키워야 한다. 개발자는 이제 하드웨어에 대해서도 이해해야 한다.

---

● 신개념 N스크린 웹앱 프레임워크 ‘PARS’

• 발표자: 이동영 LG전자

  신개념 멀티스크린 웹 아키텍처의 발전방향

LG전자에서 연구중인 N스크린 웹앱 프레임워크 ‘PARS’에 대한 발표였다.
node.js를 기반으로 하여 다양한 기기의 화면을 브라우저 상에서 제어할 수 있는 웹앱 프레임워크.
아직은 연구단계이기 때문에 진행상황을 지켜보기 바람.

---

● 네이버 모바일 홈을 움직이는 반응형 무한스크롤의 비밀

• 발표자: 손찬욱 Naver

• Why Cards are the Future of the Web
  카드는 다양한 화면 디자인에 대해 유연성Scalability이 높다.
  네이버도 일부분 카드UI 사용: 사용자 최적화된 그리드 레이아웃 + 무한스크롤

  • 예: 핀터레스트 Card UI

• 교훈

  모든 사람들은 비슷한 고민을 한다. 하지만, 모든 사람들이 똑같은 고민을 하지 않는다.
  다른 사람이 한 삽질이 있고, 본인이 해야할 삽질이 있다.

• 그리드 레이아웃 처리방식에 대한 고민

• 무한 스크롤 처리에 대한 고민
• 사용한 방법에서 발생되는 문제들

---

● 소프트웨어개발 방법론을 건축가에게만 배워야 하는가?

• 발표자: 신현묵 스윗트래커

• TO-BE 모델이 확실한 건축가보다, 경험을 기반으로 기록(증거)를 남기며 전문적인 기술을 관리하는 의사들에게서 배우는 것이 개발자들에게 더욱 적합하다는 생각을 전달함.

• 과거에 이발사는 의사(외과의)의 역할을 수행해왔다. 그 이발사는 현재에 이르며 이발사/의사로 분리되었다. 의사들은 오래전부터 쌓아온 자신들의 경험(치명적인 실수 포함)을 기록으로 관리하며 학문으로 발전시키고 학회를 통해 공유하며 자신들의 경험을 수많은 실험을 통해서 체계화하여왔다.

• 의사들이 일하는 방식 -> 배워야할 것

  • 문제를 인식하는 방법
  • 문제를 지식화하는 방법
  • 문제를 전파하는 방법
  • 문제를 끊임없이 연구하는 자세
  • 애자일 선언
  • 무엇을 진행했고, 어떤 것을 얻었으며, 어떤 것을 실패하였는가?
    • 기록하고 관리하고, 연구하고, 대비한다.
    • 잦은 실수가 발생하는 것을 어떻게 관리하는 지가 중요하다. 이것이 회사의 역량차이가 될 수 있다.

• 근거중심의 소프트웨어 개발방법론

  1. 문제점으로부터 명료한 질문을 파악
  2. 이에 상응하는 과거의 아키텍처와 패턴 탐색
  3. 해당 내용에 타당도와 유용성에 대한 비여적 평가수행
  4. 실무에서 찾아진 유용한 내용을 적용

• 의료에서 배워야할 4가지

  1. 요구사항과 환자에 대한 진단이 명확해야 한다.
  2. 그리고, 세심하게 관리해야 한다.
  3. 책임을 누군가가 가지고 주도해야 한다.
  4. 당연 비용을 관리해야 한다.
  • 그리고 기록해야 한다.

• 코드

  • 정량적인 검토는 자동화, 정성적인 검토는 기준을 명확하게 하라.
  • 자기만의 표기법을 만들고, 타인의 ‘표식’과 호흡하다.

대화하라. 애자일을 실천하라.

---

● GitHub’s First Principles

• 발표자: Pill Haack(https://haacked.com) github

• 소프트웨어가 세상을 변화시켰다. software is changed the world

• 소프트웨어는 세상을 변화시키고 있다. software is changing the world
• 콘웨이법칙

  하나의 시스템을 설계하는 집단은, 그 집단의 의사소통 구조와 유사한 시스템을 설계한다.

◎ Traits

• Do real work and Ship it!: 최선을 다해서 작업하고 곧바로 배송하라.
• Automate all the things: 모든 것을 자동화하기: hubot
• Always be classy: 항상 세련되기
  • 항상 기술을 연마하는 것을 게을리하지 않는 것이 중요하다.
• Create a better future: 더 나은 미래를 만들기
• Love your work: 자신의 일을 사랑하기
• Never work just for Money: 결코 돈만을 위해 일하지 않기
  • 그렇지만~ 이왕이면 좀 더 많이 벌 수 있으면 좋지.
• Optimize for happiness: 행복을 위해 최적화하기
  • 개발자의 행복은 뭘까나?
  • autonomy 자율성
  • mastery 숙달
  • purpose 목적
• No Set work hours: 고정된 근무시간 없애기
• No meeting: 회의 없애기
• No deadlines: 마감시간 없애기
  • 마감시간이 개발자에게 주는 정신적 압박감은 매우 크지.
• Take vacation when you need it
  • 휴가는 필요할 때마다 가기
  • 휴식이 필요하다고 생각되는 순간에 훌쩍 떠날 수 있다면 참 좋지.
• Dunbar’s number 라는 것은, 개인이 사회적 관계를 안정적으로 유지할 수 있는 사람의 숫자를 말한다.

◎ 탁월한 소프트웨어를 개발하기 위해서는, 탁월한 소프트웨어 회사를 세워라.

to build great software build a great software company.

---

● Docker로 보는 클라우드 서버 운영의 미래

• 발표자: 김대권Leevi

• 빌드-배포에 대한 새로운 패러다임을 제공하고 있는 도커Docker는 내부적으로는 IaaS에 가까운 환경 구축의 유연성을 제공하면서, 외부적으로는 Docker만 있다면 언제 어디서도 실행 가능한 형태로 이미지를 만들 수 있도록 지원해 PaaS나 SaaS에 가까운 장점을 누릴 수 있도록 해준다고 한다.

  아직 Docker에 대해서는 제대로 살펴보지 못했기에 뭐라고 단정할 수는 없지만, 많은 개발자들이 도커에 열광하는 이유에 대해서 살펴볼 필요가 있다.

전체적으로 좋은 컨퍼런스였다. 조금 아쉬운것이 있었다면, 발표를 위한 음향처리부스가 입구쪽에 마련되어 있는 탓에 많은 사람들이 들어오고 나가는 곳이 협소하여 제대로 움직이기가 쉽지 않았다. 한편으로는 출입을 통제하기 위한 목적으로 그럴 수도 있겠다 싶었지만, 많은 사람이 움직이는데 불편함을 야기했다.