Article

[Agile] 데일리 스크럼(Daily Scrum)이란?

[Agile] 데일리 스크럼(Daily Scrum)이란?

Tech News
Click the link to read the original article: Here =============== 데일리 스크럼(Daily Scrum)을 잘 하는 방법 Goal 데일리 스크럼이란 무엇인가(개념과 일반적인...
Read More
지속적인 통합 (CI: Continuous Integration)

지속적인 통합 (CI: Continuous Integration)

Tech Trend
지속적인 통합 (CI: Continuous Integration) Click the link to read the original article: 지속적인 통합 (CI: Continuous Integration) ======================================== 지속적인 통합의...
Read More
Spring에서 YAML 파일 데이터 객체에 매핑하여 로드하기

Spring에서 YAML 파일 데이터 객체에 매핑하여 로드하기

Tech Trend
Spring에서 YAML 파일 데이터 객체에 매핑하여 로드하기 Click the link to read the original article: Spring에서 YAML 파일 데이터 객체에 매핑하여...
Read More
DevOps Tool – Jenkins / Travis CI / Docker / Ansible with YAML

DevOps Tool – Jenkins / Travis CI / Docker / Ansible with YAML

Tech Trend
각종 DevOps Tool - Jenkins / Travis CI / Docker / Ansible with YAML Click the link to read the...
Read More
DevOps란 무엇이며, CI는 무엇인가?(각 종 Tool들…)

DevOps란 무엇이며, CI는 무엇인가?(각 종 Tool들…)

Tech Trend
DevOps란 무엇이며, CI는 무엇인가? Click the link to read the original article: DevOps란 무엇이며, CI는 무엇인가? ==================== DevOps에 대해서, 하나의 소프트웨어를...
Read More
‘개념에서 의의까지’ 데브옵스 따라잡기

‘개념에서 의의까지’ 데브옵스 따라잡기

Tech Trend
'개념에서 의의까지' 데브옵스 따라잡기 Click the link to read the original article: 데브옵스따라잡기 ========== 데크옵스라는 용어의 정의를 추적하다 보면 ‘애자일’,...
Read More
DevOps란 무엇일까?

DevOps란 무엇일까?

Tech Trend
DevOps란 무엇일까? Click the link to read original article: DevOps란 무엇일까? ============================================ 이 글은 기술이야기는 아닙니다. 조직이야기입니다. 그리고, 일반론도 아닙니다. 하지만,...
Read More
DevOIps, 그문화에 대해서…

DevOIps, 그문화에 대해서…

Tech Trend
DevOIps, 그문화에 대해서... Click the link to read original article: DevOps, 그문화에 대해서... ==================================== 개발 방법론이나 소프트웨어 개발과 관련된 은빛 탄환과도...
Read More
Frontend Dev Bookmarks

Frontend Dev Bookmarks

Tech News
Frontend Dev Bookmarks Frontend Dev Bookmarks ==  
Read More
Backend Development Bookmark

Backend Development Bookmark

Tech News
Backend Development Bookmark Backend Development node.js Installation paths: use one of these techniques to install node and npm without having...
Read More
Full Stack Development Resources

Full Stack Development Resources

Tech News
Full Stack Development Resources https://yhjor1212.gitbooks.io/full-stack-handbook/content/
Read More
Front-End Developer Handbook 2017

Front-End Developer Handbook 2017

Tech News
Written by Cody Lindley sponsored by — Frontend Masters This is a guide that anyone could use to learn about the practice of...
Read More
AVAILABLE NOW: Front-End Developer Handbook 2016

AVAILABLE NOW: Front-End Developer Handbook 2016

Tech News
Front-End Developer Handbook 2016 Front End Handbook Written by Cody Lindley sponsored by — Frontend Masters This is a guide that anyone could...
Read More
취업과 직결되는 인기 클라우드 자격증 11가지 집중 탐구

취업과 직결되는 인기 클라우드 자격증 11가지 집중 탐구

Tech Trend
Click the link to read the article: 내용 보러가기 ================ 경험이 풍부한 IT 전문가들은 어디에서 어떻게 자신을 차별화 할 수 있을까요?...
Read More
IT의 위기! 조직 내 지위와 역할이 바뀌고 있다

IT의 위기! 조직 내 지위와 역할이 바뀌고 있다

Tech News
IT의 위기! 조직 내 지위와 역할이 바뀌고 있다 너무 많은 약속들 지켜지지 않아...IT를 ‘지출’로 인식하기 시작 혁신적인 기술들 도입하려는 시도,...
Read More
IT 부서가 5년을 내다보고 준비해야 할 역량

IT 부서가 5년을 내다보고 준비해야 할 역량

Tech Trend
IT 부서가 5년을 내다보고 준비해야 할 역량 Sharon Florentine | CIO IT의 역할이 지속해서 발전하고 새로운 기술이 잇달아 도입되는 상황에서...
Read More
2017 IT 트렌드- 전 세계 1200명 CIO가 뽑은 중요 IT 기술 세 가지

2017 IT 트렌드- 전 세계 1200명 CIO가 뽑은 중요 IT 기술 세 가지

Tech Trend
2017 IT 트렌드 전 세계 1200명 CIO가 뽑은 중요 IT 기술 세 가지 Click the link to read to the...
Read More
사물인터넷(Internet of Things;IoT)이란 무엇인가?

사물인터넷(Internet of Things;IoT)이란 무엇인가?

Tech News
사물인터넷(Internet of Things;IoT)이란 무엇인가? Click the link to read the article:  http://blog.bizmerce.com/ ===== 사물인터넷(Internet of Things;IoT)이란 무엇인가? Posted on 2014년 12월...
Read More
힘이되는 100가지 명언 모음

힘이되는 100가지 명언 모음

Good Articles
힘이되는 100가지 명언 모음  세상사는데 도움이되는 명언들 힘이되는 명언 용기를 주는 명언 위로가되는 명언 좋은명언 글귀 모음 100가지  자주 보면...
Read More
The top 25 laptop battery life performers from CNET Labs

The top 25 laptop battery life performers from CNET Labs

Science
The top 25 laptop battery life performers from CNET Labs Click to the link: https://www.cnet.com/pictures/cnet-labs-laptops-and-hybrids-with-the-best-battery-life/    
Read More
[Agile] 데일리 스크럼(Daily Scrum)이란?
Tech News

[Agile] 데일리 스크럼(Daily Scrum)이란?

Click the link to read the original article: Here

===============

데일리 스크럼(Daily Scrum)을 잘 하는 방법
Goal
데일리 스크럼이란 무엇인가(개념과 일반적인 규칙)
데일리 스크럼을 하는 이유(필요성)
데일리 스크럼을 잘 도입하는 방법

[들어가기 전] 데일리 스크럼을 주제로 선택한 이유

‘애자일 방법론’에 대해 이해하기 위해서 조금 더 구체적인 소재를 골랐다.
보통은 추상적 -> 구체적(개론 -> 강론)으로 설명을 진행한다.
어떤 소재를 이해하는데 있어서 위와 같은 방법은 좋은 접근법이 아니다.
만약에 대상(소재) 자체가 불확실성이 없어서 수학 공식처럼 명확하게 설명이 가능하다면 위의 방법처럼 순차적으로 설명하는 방식이 맞다.
구체적 -> 추상적 -> (구체적+추상적)
하지만 대상(소재)이 복잡하고 불확실한 경우라면
1) 처음에 구체적인 것을 이해한 후
2) 그 다음에 추상적인 것을 접하면서
3) 추상적인 것과 구체적인 것을 본인 스스로 능동적으로 서로 융합해서 이해하려고 하는 것이 좋다.
처음에 구체적인 것을 통해 이해를 하고, 그 후에 추상적인 내용이 나오면 추상적인 서로 다른 레벨에 있는 두 가지를 서로 융합하려고 노력한다.
즉, 계속해서 추상적인 것과 구체적인 것과의 관계를 생각하게 되면서 본인 스스로가 능동적으로 학습하게 되는 것이다.
데일리 스크럼은 간단하기 때문에 다루기 쉬운 주제다.
누구나 쉽게 배워서 할 수 있는 느낌이다.
실생활과 연관성이 깊다.
SW가 아닌 쪽에서도 도입할 수 있다.
데일리 스크럼이란?

스크럼 방법론에서 쓰이는 용어로, 날마다하는 짧은 회의를 뜻한다.

매일 현재 상태를 업데이트하고 조율하는 것 을 의미한다.
다른 애자일 방법론인 XP에서는 스탠드업 미팅이라고 하는 것도 있다. 스탠드업 미팅에서는 회의를 서서하는 것이 필수적이다.
데일리 스크럼의 일반적인 규칙과 필요성

데일리 스크럼의 일반적인 규칙
정해진 시간은 없다.(꼭 아침에만 해야 되는 것은 아니다.) 단, 최대 15분 이내에 마친다.
꼭 서서 하지 않아도 된다.
팀원들이 모두 돌아가면서 아래의 질문에 대답한다.
질문
지난 데일리 스크럼부터 지금까지 내가 완수한 것이 무엇인가
다음 데일리 스크럼까지 내가 하기로 한 것이 무엇인가
현재 장애가 되고 있는 것(곤란하고 어려운 것)이 무엇인가
데일리 스크럼의 필요성
그렇다면 왜 업데이트/조율을 매일해야 하는가?

우리가 진행하는 프로젝트의 불확실성이 높으면 매일 매일 상태를 업데이트할 필요성이 높아진다.
프로젝트에 대해 서로 더 많이 알고 계속해서 조율을 해야지만 불확실성이 줄어들기 때문이다.
하지만! 사람들은 일반적으로 가만히 놔두면 서로 업데이트/조율을 하지 않는다.
왜냐하면? 학교에서 그렇게 훈련을 받았으니까!
학교에서는 불확실한 상황에 대해서 어떻게 대처해야 될지에 대해서 알려주는 것이 아니라 확실한 상황에서 어떻게 준비할까에 대해서 가르친다.
그래서 사람들은 보통, 주어진 상황에서 계획을 짜서 역할을 나누고 각자가 맡은 부분을 마지막에 합친다. 이게 과연 협력일까?
관련된 재미있는 일화
사람들이 일을 나눠서 하는 것에 대해 협력이라고 착각하는 일화
상황) SW 개발을 하려는 대학생으로 구성된 팀을 멘토링하던 중 ‘린 스타트업’(Lean Startup, 회사를 운영하는 것을 해나가는 전략적인 방법)에 대해서 이번 주에 스터디를 해보면 좋을 거 같다는 조언을 해주었다.
그 다음 주에 학생들이 발표를 위한 ppt를 준비했다.
첫 번째 학생 발표 시작, ‘린’
도요타 자동차 회사에 대한 얘기
린 메소돌로지(도요타 자동차 회사의 혁신적인 생산 방식을 미국에서 비슷하게 만든 것) 등
두 번째 학생 발표 시작, ‘스타트업’
창업이란 무엇인가에 대한 얘기
지원, 기획서 등
‘린 스타트업’은 하나의 개념인데, 그거에 대해서는 아무도 공부하지 않았다.
(불확실성을 줄이는 것 == 일을 잘 나누는 것)..?
대부분의 사람들은 초반부에 일을 나누려고 한다.
하지만 초반부는 프로젝트에 대한 정보가 적을 때이기 때문에 일을 잘 나누기가 어렵다.
그래서 대부분의 사람들은 일을 비효율적으로 나누게 된다.
프로젝트에 대한 정보가 많을 때인 프로젝트가 끝날 때 일을 가장 잘 나눌 수 있다.
하지만 프로젝트가 끝날 때 일을 잘 나누는 것은 소용이 없다.
그러므로 일을 잘 나누는 것이 중요한 것이 아니라 계속해서 서로를 체크하고 조율할 수 있는 데일리 스크럼을 통해 불확실성을 줄일 수 있다.
데일리 스크럼의 장점과 궁극적인 목적

데일리 스크럼의 장점
데일리 스크럼을 하면 무슨 장점이 있는 거지? 굳이 얼굴을 보면서 해야하나?
메일이나 스프레드시트를 사용하면 되지 않을까
아니면 일주일에 한 번씩 워드에 적어서 팀 전체에 공유하면 되지 않을까
문자/전화 커뮤니케이션 VS 음성 + 얼굴 커뮤니케이션
문자/전화 커뮤니케이션
사람들이 기본적으로 문자/전화 커뮤니케이션은 인류의 역사에서 짧은 시간동안 이루어진 것이다.
이런 text로 된 것을 통한 커뮤니케이션은 ‘비동기적인 커뮤니케이션’에 속한다.
text로 적으면 어느 부분에서 문제가 되는 것인지 알기가 어렵다.
학습이 느리고 신뢰를 만들기 어렵다.
text 작성을 위한 추가적인 노력이 필요하다.
음성 + 얼굴 커뮤니케이션
사람들은 음성과 함께 얼굴을 보면서 하는 소통이 편하고 익숙하다
얼굴을 보면서 소통하는 것이 신뢰를 만들기가 쉽다.
즉각적인 피드백 을 통해서 학습을 더 많이, 더 빨리 할 수 있다.
어느 부분에서 상대방의 마음에 안드는지 바로 알 수 있다.
나의 말에 대한 반응을 바로 인지하여 피드백을 받을 수 있다.
즉, 이를 통해 서로를 잘 이해할 수 있고 협력에 도움이 된다.
얼굴을 보면서 하는 데일리 스크럼의 장점
애자일에서는 협력을 중요시하는데 이를 위해서는 협력이 잘 되는 구조가 필요하다. 즉, 데일리 스크럼을 이용하면 협력이 잘 될 확률이 높아지는 것이다.
또한, 데일리 스크럼은 일종의 리츄얼(Ritual)이다. 즉, 데일리 스크럼을 통해 같이 이야기하는 방법을 훈련 하는 효과과 있고 매일 모여서 이야기하는 것으로 ‘우리는 같은 팀이지’라는 생각을 무의식적으로 갖게 만든다.
얼굴을 보면서 소통함으로써 신뢰 를 만들기가 쉽고, 즉각적인 피드백 을 통해서 학습 을 더 많이, 더 빨리 할 수 있다.
사람들이 데일리 스크럼에 대해 생각하는 오해, 함정
(데일리 스크럼 == 정보 전달을 위한 회의)..?
만약에 데일리 스크럼의 목적을 정보 전달이라고만 생각한다면 데일리 스크럼이 필요가 없다.
이런 목적을 가지고 데일리 스크럼을 진행하면 회의가 굉장히 삭막해진다.
즉, 대화가 아닌 보고가 된다.
데일리 스크럼에는 사회적인 자본(Social Capital) 즉, 서로 간의 네트워크와 신뢰를 키우는 것이 포함되어 있다.
데일리 스크럼을 통해 서로 소통하는 법, 대화하는 법, 협력하는 법을 훈련할 수 있다.
데일리 스크럼의 궁극적인 목적
데일리 스크럼을 할 때 잘 안되는 경우
정보 전달로만 데일리 스크럼을 다룬다.
누군가가 데일리 스크럼을 도입할 때 그냥 책대로, 규칙대로만 진행한다.
예를 들어, ‘나 데일리 스크럼이라는 거 알아요. 이거 좋은데 우리 한 번 적용해봅시다.’
이런 식으로 데일리 스크럼이 진행되면 그냥 하면서 흐지부지된다. 점점 규칙이 흐려지면서 변질된다.
데일리 스크럼을 성공적으로 하는 경우
예를 들어, ‘아 우리 팀이 좀 소통이 부족하다는 걱정이 있어요. 다들 어떻게 생각하시나요? 우리 어떻게 하면 좋을까요? 데일리 스크럼이라는 것을 아는데 이 방법을 통해서 어떤 효과를 가져올 수 있을까요?’
데일리 스크럼을 하면서 일주일에 한 번 정도는 ‘요즘 우리의 데일리 스크럼은 어떤가’, ‘데일리 스크럼을 어떻게 바꿔나가면 좋겠는가’를 얘기하면 좋은 변화가 생긴다.
즉, 데일리 스크럼을 잘하기 위해서는 이것을 도입하는 과정에서 협력적이고 피드백(애자일의 원리)을 통해서 도입해야한다
데일리 스크럼이라는 것이 있으니까 쓴다는 생각이 아니라, 이 방법을 통해 어떤 효과를 가져오려고 하는 것인지에 대해 고민해야한다.
즉 그 효과를 가져오기 위해서 우리는 어떻게 해야되는가를 고민해야 하는 것이지, 데일리 스크럼을 도입하기 위해서 우리가 어떻게 해야되는지를 고민해선 안된다.
이런 과정을 통해서 제대로 데일리 스크럼이 도입되면 ‘우리가 더 잘하고 있구나’라는 생각을 하게 된다.
관련된 Post
애자일 방법론이란 무엇인가? 애자일 방법론의 핵심은 무엇인가?에 대해 알고 싶으시면 애자일이란을 참고하시기 바랍니다.
애자일 자격증의 종류와 그 효용 가치에 대해 알고 싶으시면 애자일 자격증을 참고하시기 바랍니다.
TDD(테스트 주도 개발)의 개념과 효과에 대해 알고 싶으시면 TDD(테스트 주도 개발)란을 참고하시기 바랍니다.
짝 프로그래밍(Pair Programming)의 개념과 효과에 대해 알고 싶으시면 짝 프로그래밍(Pair Programming)이란을 참고하시기 바랍니다.

References
애자일 키워드 – 김창준, 강재영 진행
Ten Tips to make your Daily Scrum more effective

How to Run a Successful Scrum Meeting with a Remote Team


https://gmlwjd9405.github.io/2018/06/01/agile-dailyscrum.html

지속적인 통합 (CI: Continuous Integration)
Tech Trend

지속적인 통합 (CI: Continuous Integration)

지속적인 통합 (CI: Continuous Integration)

Click the link to read the original article: 지속적인 통합 (CI: Continuous Integration)

========================================

지속적인 통합의 개념은 아래와 같습니다.

CI : Continuous Integration : 지속적인 통합

– 지속적으로 퀄리티 컨트롤(품질 관리)을 적용하는 프로세스를 실행하는 것.

– 모든 개발을 완료한 뒤에 퀄리티 컨트롤을 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점

– 초기에 그리고 자주 통합해서 통합 시 발생하는 여러가지 문제점을 조기에 발견하고, 피드백사이클을 짧게 하여 소프트웨어 개발의 품질과 생산성을 향상시키는 것.

CI시스템이 어떻게 적용이 되는지 좀 더 자세히 살펴보도록 하겠습니다.

CI시스템을 구축하지 않은 경우에는 개발자들이 각자 개발한 소스코드를 형상관리 서버에 커밋하면 별도의 품질관리를 거치지 않고, 대부분 개발이 끝난 막바지에 통합을 하여 테스트를 진행하게 됩니다.

이런 경우, 개발 중 별도의 품질관리를 수행하지 않았기 때문에 잘못된 소스코드를 형상관리 시스템에 반영하였을 경우 발생되는 문제가 개발 후반에 모두 장애로 발견됩니다.

CI서버는 형상관리 서버에 Commit된 소스코드를 주기적으로 폴링하여 컴파일, 단위테스트. 코드 인스펙션 등의 과정을 수행하며신규 또는 수정된 소스코드가 결함이 있는지의 여부를 지속적으로 검증합니다.

검증 결과는 이메일, RSS 등의 피드백 메커니즘을 통해 개발자들에게 전달되고, 이를 통해 조기에 결함을 발견하여 해결할 수 있는 것입니다.

이제, CI시스템 구축을 위한 핵심 구성요소에 대해서 살펴보겠습니다.

1. CI Server

– 빌드 프로세스를 관리하는 서버

– Jenkins, Hudson, CruiseControl.NET, TeamCity

CI시스템을 구축하기 위해서는 우선 CI 서버가 필요하겠지요. 오픈소스인 Jenkins가 가장 널리 사용되고 있는 CI서버입니다.

2. SCM(Source Code Management)

– 소스코드 형상관리 시스템

– 소스코드의 개정과 백업 절차를 자동화하여 오류 수정 과정을 도와줄 수 있는 시스템

– 여러사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 자동으로 동기화할 수 있는 시스템

– SubversionGit, Mercurial

두번째, CI서버에서 자동으로 폴링하여 검증할 수 있도록 소스코드를 관리하는 형상관리 시스템이 필요합니다.

SVN(Subversion)과 Git이 가장 널리 사용되고 있습니다.

3. Build Tool

– 컴파일, 테스트, 정적분석 등을 실시해 동작 가능한 소프트웨어를 생성

– Ant, Maven, MSBuild, Make

세번째, 개발하는 언어에 맞는 빌드 툴이 필요합니다.

빌드란, 소스코드 파일을 컴퓨터에서 실행할 수 있는 독립 소프트웨어 가공물로 변환하는 과정을 말하거나 그에 대한 결과물을 일컫는 것으로 빌드에 있어서 가장 중요한 단계는 소스코드 파일이 실행 코드로 변환되는 컴파일 과정입니다.

컴파일과 빌드를 혼동하여 쓰는 경우가 있으나 컴파일은 빌드 과정 중 한 단계일 뿐이며, 빌드는 형상관리 시스템에 있는 소스코드를 가져와 컴파일하여 사용자들이 실행할 수 있도록 실행 파일로 만드는 일련의 과정을 모두 포함합니다.

(참조 : 빌드의 중요성(http://softwaredev.tistory.com/10) / 빌드와 컴파일의 차이(http://allofsoftware.net/19)

4. Test Tool

– 작성된 테스트 코드에 따라 자동으로 테스트를 수행해주는 도구로, 빌드 툴의 스크립트에서 실행

– JUnit, CppUnit, CppTest, MSTest, Selenium(사용자테스트 자동화 가능)

네번째, 개발하는 언어에 맞는 테스트 툴이 필요합니다.

테스트는 단위 테스트를 말하며, 개발자라면 익숙한 JUnit(자바 애플리케이션의 단위 테스트 자동화를 위한 프레임웍)이 대표적입니다.

단위 테스트는 테스트 대상이 되는 코드 기능의 아주 작은 특정 영역을 실행해 보는 것으로, 개발자가 작성한 테스트 코드로 특정 메소드(Function)를 시험해보는 것이 일반적입니다.

다시 말해, 개발자가 작성한 메소드가 입력값에 따라 제대로 수행되는지 여부를 체크하는 것이지요.

단위테스트는 언어별로 자동화 테스트 도구들이 잘 만들어져 있어서 테스트코드 작성만 하면 자동으로 수행할 수 있습니다.

그 중 JUnit은 Ant와 같은 빌드 툴과도 쉽게 통합이 되기 때문에 가장 널리 사용되고 있습니다.

5. Test Coverage Tool

– 테스트 코드가 대상 소스 코드에 대해 어느정도 커버하는지 분석하는 도구

– Emma, Cobertura, TestCocoon

다섯번째는 테스트 툴과 함께 사용되는 테스트 커버리지 툴입니다.

테스트 커버리지 툴은 용어 그대로 개발자가 작성한 테스트코드가 테스트 대상 소스코드에 대해서 어느정도 테스트를 수행하는지를 코드 라인과 백분율을 통해 리포팅하는 것으로 단위테스트 수행 시 테스트 커버리지를 분석하기 위하여 부가적으로 사용하는 툴입니다.

6. Inspection Tool

– 프로그램을 실행하지 않고, 소스코드 자체로 품질을 판단할 수 있는 정적분석 도구

– 코딩 표준 준수 검사, 코드 메트릭 측정, 중복코드 검사, 코드 인스펙션 검사 등이 있음.

– CheckStyle, FindBugs, Cppcheck, Valgrind

마지막으로 인스펙션 툴이 필요합니다.

인스펙션 툴은 정적분석 도구로, 프로그램을 실행하여 분석하는 동적분석(JUnit도 일종의 동적 분석에 속함)과는 달리 소스코드 자체로 프로그램 상의 예상되는 잠재적인 결함을 검출하는 도구입니다.

정적분석의 개념과 도구에 대한 내용은 추후에 별도의 포스트로 작성하도록 하겠습니다.

3~6번의 도구는 XML 형태의 빌드 스크립트(Ant 등)로 수행 내용을 작성하여 CI서버에서 형상관리 서버에서 폴링한 소스코드를 빌드하면서 자동으로 수행됩니다.

빌드 스크립트를 통한 CI 자동화 수행 절차 예시는 아래와 같습니다.

1. 소스코드를 바이너리 파일로 컴파일 한다.

2. 바이너리 파일을 배포 형태로 패키징 한다.

3. 단위테스트(커버리지 포함)수행한다. (선택)

4. 정적분석을 수행한다. (선택)

5. 분석 결과를 리포팅 한다. (선택)

6. 패키징한 파일을 테스트 서버에 배포한다.

Jenkins 설치/설정 방법과 Ant 빌드 스크립트 작성 방법 등 자세한 CI시스템 구축 방법에 대한 내용은 추후에 별도의 포스트로 소개하도록 하겠습니다.

Spring에서 YAML 파일 데이터 객체에 매핑하여 로드하기
Tech Trend

Spring에서 YAML 파일 데이터 객체에 매핑하여 로드하기

Spring에서 YAML 파일 데이터 객체에 매핑하여 로드하기

Click the link to read the original article: Spring에서 YAML 파일 데이터 객체에 매핑하여 로드하기

========================================

서론

Spring 프로젝트를 진행할 때 외부에서 데이터를 로드할 경우가 종종 있다. 가장 쉽게는 Spring Boot에서 사용하는 Configuration Porperty를 로드하는 것이다. Spring Boot는 기본적으로 application.properties 파일을 추가하면 자동으로 Common application properteis 로드하여 프로퍼티 값을 적용할 수 있다. 하지만 자바의 Properties 의 파일의 사용에는 표현의 한계가 있기 때문에 최근에는 Properties를 YAML을 많이 사용하고 있다. Spring Boot에서는 SnakeYAML을 포함하고 있어서 쉽게 외부 파일을 YAML으로 작성하여 쉽게 로드하여 객체로 매핑할 수 있다. 이번 포스팅에서는 Spring Boot에서 YAML로 작성한 파일을 객체로 매핑하여 사용하는 방법을 소개한다.

테스트를 위한 데이터 YAML 파일로 만들기

테스트를 위해 간단한 데이터가 필요하다. 이 때 처음부터 JPA와 같이 ORM을 가지고 데이터를 만들어서 사용하려면 꽤 여러가지 일을 해야한다. 우리는 테스트를 위한 파일을 쉽게 가져올 수 있게하기 위해서 YAML 파일을 사용하기로 한다. Spring Boot는 application.properties 이나 application.yml 파일에 필요한 설정을 정의하면 어플리케이션에서 자동으로 읽어들일 수 있다. Spring Boot 프로젝트를 생성하면 src/main/resources/application.properties 라는 어플리케이션 프로퍼티 파일이 만들어 진다. Spring에서 복잡한 XML 설정을 Spring Boot에서는 이 파일 안에서 간단하게 설정하여 어플리케이션에 적용할 수 있다. http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html 자세한 사항은 링크를 참조하면 된다.

Spring Boot에서는 Snake YAML 라이브러리를 내장하고 있다. 이런 이유로 Spring Boot에서는 YAML 파일을 로드하여 사용할 수 있다. http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#boot-features-external-config-yaml (링크를 참조). 뿐만아니라src/main/resources/application.yml 파일에 설정을 정의하면 application.properties와 같이 Spring Boot에서 자동으로 읽어와 필요한 곳에 매핑된다.

YAML 파일은 .properties 파일과 달리 계층과 배열 구조의 데이터를 쉽게 만들 수 있고 이것을 Map, List 또는 Bean에 쉽게 편리하게 매핑할 수 있다. Ruby on Rails에서는 이미 오래전부터 YAML 파일을 사용하여 데이터베이스나 시스템 설정 파일로 사용해 왔다. YAML은 JSON과 비슷하지만 표현법이 더 간단하여 인기있기 사용되고 있다.

우리는 테스트를 위한 데모 데이터세트를 Spring Boot가 환경 설정을 읽어오는 것과 유사하게 로드하게 할 것이다. 먼저 데모 데이터를 src/main/resources/fixtures.yml 에 저장한다.

fixtures:  
  articles:
    -
      id: 1
      title: title1
      content: content1
    -
      id: 2
      title: title2
      content: content2
    -
      id: 3
      title: title3
      content: content3

YAML 파일을 Map으로 매핑하기

먼저 YAML 파일을 로드하기 위해서는 외부에서 Configuration을 로드 하기 위해 Externalized Configuration (글을 참조) 설정을 해야한다. 간단하게 다시 말하자면 YAML 파일을 Spring 어플리케이션어 로드하기 위한 컴포넌트가 필요하다. 우리는 fixtures.yml 파일을 Configuration Property 파일 형태로 로드하기 위해서 src/main/java/{패캐지명}/FixturesProperty.java 파일을 만든다. 여기서 주의할 점은 앞에서 만든 fixtures.yml 파일을 로드하기 위해서 classpath 위치를 지정하는데 SpringBoot는 기본적으로 src/main/resources/ 디렉토리를 클래스 패스로 가지고 있기 때문에 아래와 같이 지정한다. 그리고 fixtures.yml 파일 안에 articles는 fixtures 라는 Key의 List value로 만들어 놓았기 때문에 YAML 파일을 읽어들일 때 prefix로 fixtures를 정의하여 이 키 값 안의 데이터를 로드하게 한다. 그리고 우리가 만든 fixtures.yml 파일은 article 내용이 YAML의 배열로 작성했기 때문에 나중에 List

로 매핑될 것이다. 외부 프로퍼티 파일(.propertis 나 .yml)을 Injection 로드하기 위해서는 Spring의 컴포넌트가 되어야하기 때문에 @Component 어노테이션을 추가하고 프로퍼티 파일을 로드하기 위한 클래스라는 것을 정의하기 위해서 @ConfigurationProperties 어노테이션을 추가한다.

package net.saltfactory.tutorial;

import org.springframework.boot.context.properties.ConfigurationProperties;  
import org.springframework.boot.context.properties.NestedConfigurationProperty;  
import org.springframework.stereotype.Component;

import java.util.ArrayList;  
import java.util.List;  
import java.util.Map;

/**
 * Filename : FixturesProperty.java
 * Author   : saltfactory<saltfactory@gmail.com>
 * Created  : 11/23/15.
 */
@Component
@ConfigurationProperties(locations = {"fixtures.yml"}, prefix = "fixtures")
public class FixturesProperty {  
    @NestedConfigurationProperty
    private List<Map> articles = new ArrayList<>();

    public List<Map> getArticles() {
        return articles;
    }
}

스크린샷과 같이 Spring Boot Configuration Annoation Processor를 찾을 수 없다는 에러가 나타나면 다음과 build.gradle 파일을 열어서 다음 내용을 추가한다. 원래 Spring Boot에서 외부 프로퍼티 파일을 로드하기 위해서는 메타 정보를 파일로 만들어서 추가해야는데 propdes-plugin을 사용하면 메타 파일을 추가하지 않고 자동으로 적용할 수 있다. http://docs.spring.io/spring-boot/docs/1.3.0.RELEASE/reference/html/configuration-metadata.html#configuration-metadata-annotation-processor (글을 참조)

프로젝트 안의 build.gradle 파일을 열어서 다음과 같이 수정하고 gradle.properties 파일을 적용한다.(IntelliJ에서는 이 파일을 수정하고 Gradle projects 패널에서 새로고침 버튼을 누르면 의존성 있는 라이브러리를 자동으로 다운 받게 된다)

buildscript {  
    ext {
        springBootVersion = '1.3.0.RELEASE'
    }
    repositories {
        mavenCentral()
        maven { url 'http://repo.spring.io/plugins-release' }
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
        classpath("org.springframework.build.gradle:propdeps-plugin:0.0.7")
    }
}

apply plugin: 'java'  
apply plugin: 'eclipse'  
apply plugin: 'idea'  
apply plugin: 'propdeps'  
apply plugin: 'spring-boot'  
apply plugin: 'propdeps-idea'

jar {  
    baseName = 'spring-boot-demo'
    version = '0.0.1-SNAPSHOT'
}
sourceCompatibility = 1.8  
targetCompatibility = 1.8

repositories {  
    mavenCentral()
}


dependencies {  
    compile('org.springframework.boot:spring-boot-starter-web')
    optional("org.springframework.boot:spring-boot-configuration-processor")

    testCompile('org.springframework.boot:spring-boot-starter-test')
}

compileJava.dependsOn(processResources)


eclipse {  
    classpath {
         containers.remove('org.eclipse.jdt.launching.JRE_CONTAINER')
         containers 'org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8'
    }
}

task wrapper(type: Wrapper) {  
    gradleVersion = '2.9'
}

이제 외부 프로퍼티 파일을 로드하기 위한 설정을 모두 마쳤다. 우리가 만든 fixtures.yml 파일을 FixturesProperty 클래스가 잘 로드하는지 확인하기 위해서 Test 파일을 만들어보자. src/test/java/{패키지경로}/FixturesPropertyTest.java. 앞에서 FixtureProperty는 Spring의 @Component로 만들었기 때문에 스캐닝되고 @ConfigurationProperty 때문에 YAML 파일을 오브젝트에 매핑되어 반환하게 될 것이다. 우리는 fixtures.yml에 3개의 아이템을 리스트로 만들었기 때문에 테스트에서 리스트의 사이즈를 3이 맞는지 테스트를 진행하였다.

package net.saltfactory.tutorial;

import org.junit.Test;  
import org.junit.runner.RunWith;  
import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.boot.test.SpringApplicationConfiguration;  
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import java.util.List;  
import java.util.Map;

import static org.hamcrest.MatcherAssert.assertThat;  
import static org.hamcrest.core.Is.is;

/**
 * filename : FixturespropertyTest.java
 * author   : saltfactory<saltfactory@gmail.com>
 * created  : 11/23/15
 */
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = SpringBootDemoApplication.class)
public class FixturesPropertyTest {  
    @Autowired
    private FixturesProperty fixturesProperty;

    @Test
    public void testGetArticles() {
        List<Map> articles = fixturesProperty.getArticles();
        assertThat(articles.size(), is(3));
    }

}

테스트 파일을 만들었으면 단위 테스트를 실행해보자.

YAML 파일을 POJO로 매핑하기

위에 yaml로 만든 외부 파일을 Map으로 매핑을 할 수 있는 것을 살펴보았다. Spring 프로젝트에서는 데이터를 저장하는 객체를 POJO로 만들어서 setter/getter를 한다. YAML의 데이터를 POJO 객체로 바로 매핑하는 방법을 살펴보자. 우선 Article 객체를 fixtures.yml 파일에 정의한 key 값과 동일한 이름으로 field와 setter/getter를 만든다.

package net.saltfactory.tutorial;

import java.io.Serializable;

/**
 * filename : Article.java
 * author   : saltfactory<saltfactory@gmail.com>
 * created  : 11/23/15
 */
public class Article implements Serializable {  
    private long id;
    private String title;
    private String content;

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public String getContent() {
        return content;
    }

    public void setContent(String content) {
        this.content = content;
    }
}

앞에서 외부 Configuration Property를 로드하기 위한 FixturesProperty를 열어서 로드할 타입을 Map에서 Article로 변경한다.

package net.saltfactory.tutorial;

import org.springframework.boot.context.properties.ConfigurationProperties;  
import org.springframework.boot.context.properties.NestedConfigurationProperty;  
import org.springframework.stereotype.Component;

import java.util.ArrayList;  
import java.util.List;

/**
 * Filename : FixturesProperty.java
 * Author   : saltfactory<saltfactory@gmail.com>
 * Created  : 11/23/15.
 */
@Component
@ConfigurationProperties(locations = {"fixtures.yml"}, prefix = "fixtures")
public class FixturesProperty {  
    private List<Article> articles = new ArrayList<>();

    public List<Article> getArticles() {
        return articles;
    }
}

테스트를 위한 FixturesPropertyTest 파일을 수정하고 브레이크포인트를 걸어서 확인해보자.

package net.saltfactory.tutorial;

import org.junit.Test;  
import org.junit.runner.RunWith;  
import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.boot.test.SpringApplicationConfiguration;  
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import java.util.List;

import static org.hamcrest.MatcherAssert.assertThat;  
import static org.hamcrest.core.Is.is;

/**
 * filename : FixturespropertyTest.java
 * author   : saltfactory<saltfactory@gmail.com>
 * created  : 11/23/15.
 */
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = SpringBootDemoApplication.class)
public class FixturesPropertyTest {  
    @Autowired
    private FixturesProperty fixturesProperty;

    @Test
    public void testGetArticles() {
        List<Article> articles = fixturesProperty.getArticles();
        assertThat(articles.size(), is(3));
    }

}

테스트의 브레이크 포인트를 확인하면 fixtureProperty.getArticles() 에서 YAML 파일에서 로드된 데이터가 Article의 객체로 매핑되어 로드된 것을 확인할 수 있다.

계층 구조의 YAML 파일을 POJO로 매핑하기

YAML의 장점은 계층 구조의 데이터를 잘 표현할 수 있는 것이다. properties 파일은 계층 구조를 표현하기 위해서 좀 더 복잡한 방법을 사용해야하지만 YAML을 사용하면 들여쓰기 기준으로 계층 구조를 쉽게 표현할 수 있다. 또한 계층 구조로 된 POJO로 데이터를 로드하여 사용할 수 있다. 만약 Article 안에 Comment를 리스트로 가지고 있는 구조가 있다고 가정해보자. fixtures.yml 파일을 다음과 같이 수정한다.

fixtures:  
  articles:
    -
      id: 1
      title: title1
      content: content1
      comments:
        -
          id: 10
          articleId: 1
          content: comment11
        -
          id: 11
          articleId: 1
          content: comment12
    -
      id: 2
      title: title2
      content: content2
      comments:
        - id: 20
          articleId: 2
          content: comment21
        - id: 21
          articleId: 2
          content: comment22
    -
      id: 3
      title: title3
      content: content3
      comments:
        - id: 30
          articleId: 3
          content: comment31
        - id: 31
          articleId: 3
          content: comment32

그리고 Comment가 매핑될 객체를 만든다.

package net.saltfactory.tutorial;

import java.io.Serializable;

/**
 * filename : Comment.java
 * author   : saltfactory<saltfactory@gmail.com>
 * created  : 11/23/15
 */
public class Comment implements Serializable {  
    private long id;
    private String content;
    private long articleId;

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getContent() {
        return content;
    }

    public void setContent(String content) {
        this.content = content;
    }

    public long getArticleId() {
        return articleId;
    }

    public void setArticleId(long articleId) {
        this.articleId = articleId;
    }
}

그리고 Article 안에 Comment 리스트를 추가한다.

package net.saltfactory.tutorial;

import org.springframework.stereotype.Component;

import java.io.Serializable;  
import java.util.List;

/**
 * filename : Article.java
 * author   : saltfactory<saltfactory@gmail.com>
 * created  : 11/23/15
 */
public class Article implements Serializable {  
    private long id;
    private String title;
    private String content;
    private List<Comment> comments;

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public String getContent() {
        return content;
    }

    public List<Comment> getComments() {
        return comments;
    }

    public void setComments(List<Comment> comments) {
        this.comments = comments;
    }
}

단위 테스트를 다음과 같이 수정하자.

package net.saltfactory.tutorial;

import org.junit.Test;  
import org.junit.runner.RunWith;  
import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.boot.test.SpringApplicationConfiguration;  
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import java.util.List;

import static org.hamcrest.MatcherAssert.assertThat;  
import static org.hamcrest.core.Is.is;

/**
 * filename : FixturespropertyTest.java
 * author   : saltfactory<saltfactory@gmail.com>
 * created  : 11/23/15.
 */
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = SpringBootDemoApplication.class)
public class FixturesPropertyTest {  
    @Autowired
    private FixturesProperty fixturesProperty;

    @Test
    public void testGetArticles() {
        List<Article> articles = fixturesProperty.getArticles();
        assertThat(articles.size(), is(3));
    }

    @Test
    public void testGetCommentsByArticle() {
        List<Article> articles = fixturesProperty.getArticles();
        Article article = articles.get(0);
        List<Comment> comments = article.getComments();
        assertThat(comments.size(), is(2));
    }
}

단위 테스트를 실행시켜서 Article 객체 안에 Comment가 정상적으로 로드 되었는지 확인해보자.

브레이크 포인트를 확인해보면 Article 객체 안에 Comment가 리스트로 정상적으로 로드된 것을 확인할 수 있다.

결론

최신 Spring은 좀더 계층구조를 표현하기 쉽고 사람이 읽기 쉬운 YAML 파일을 로드할 수 있는 기능을 포함하였다. Spring Boot에서는 Spring 어플리케이션의 설정을 src/main/resources/application.properties에서 정의하면 자동으로 어플리케이션에 적용이되는데 YAML 파일을 사용하여 application.yml 파일을 만들어도 자동으로 적용을 할 수 있다. SnakeYAML 라이브러리를 포함하고 있는 Spring Boot에서는 YAML 파일을 읽어들어 Map이나 POJO에 바로 매핑하여 데이터를 로드할 수 있다. 더구나 @ConfigurationProperties를 사용하면 Spring 어플리케이션에서 YAML 파일을 Configuration Property 파일로 인식하여 특별한 자바 코드 없이도 Spring annotation 만으로도 외부의 YAML 파일을 로드할 수 있다. 만약 데이터베이스가 없는 데모 어플리케이션을 만들거나 테스트를 위한 간단한 데이터를 외부 파일에서 조작하기 위해서 YAML 파일을 사용하여 데이터를 정의하여 사용하면 매우 간단하게 처리할 수 있다.

소스코드

참조

  1. https://bitbucket.org/asomov/snakeyaml
  2. http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html
  3. https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
DevOps Tool – Jenkins / Travis CI / Docker / Ansible with YAML
Tech Trend

DevOps Tool – Jenkins / Travis CI / Docker / Ansible with YAML

각종 DevOps Tool – Jenkins / Travis CI / Docker / Ansible with YAML

Click the link to read the original article: DevOps Tool – Jenkins / Travis CI / Docker / Ansible with YAML

 

================================

Continuous Integration Tool

Jenkins란

젠킨서버란 오픈 소스 CI(Continuous Integration) Tool 로 Java로 만들어졌다. CI란 팀 구성원들이 작업한 내용을 정기적으로 통합하는 것을 의미한다. 만약 github을 통해 협업 중이라면 각각의 version controller 에 각자 작업한 내용을 commit을 하게 되는데, 이렇게 commit된 소스코드들을 정기적으로 통합시켜주는 것을 도와준다. 지속적으로 코드의 퀄리티를 관리할 수 있으며, 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 그 목적이 있다. 현재 csv, svn, git 등의 소스 툴들을 지원하고 ant와 maven 등의 빌드 툴을 지원하며 배포 형태는 war 파일을 통해 배포한다.
그 기능을 자세히 알아보자면 다음과 같다.
GUI 제공 / 소스 코드 체크아웃 / 분산 빌드 / 지속적인 빌드 및 테스트 자동화와 배포 자동화 / 테스트 보고서 작성 / Groovy script를 이용한 Job Scheduling 기능 / CLI 제공 / 실행 결과를 통보하고 결과물을 저장
프로젝트의 빌드가 정상적으로 되고 있는지 체크할 때 사용하며, 자동으로 유닛 테스트와 통합 테스트들의 정기적인 실행을 해줘 만약 문제가 발생하면 리포트를 해준다.

Travis CI

Jenkins와 비슷한 CI Tool이다. Jenkins는 서버가 필요하지만 Travis는 그렇지 않다.
GitHub을 이용하여 협업 프로젝트를 진행할 때, CI를 위한 오픈소스 프로젝트이다.
Git에 commit이나 push가 일어날 때 마다, 자동으로 프로젝트 빌드와 테스트를 진행할 수 있다.
Virtual Machines vs Docker

Virtual Machine

Virtual Machine이란 가상머신은 물리적인 컴퓨터에서 구동되는 운영체제와 응용프로그램으로 이루어진 소프트웨어 컨테이너를 지칭한다. 컴퓨팅 환경을 소프트웨어로 구현한 것으로 컴퓨터를 애뮬레이션하는 소프트웨어이다. 가상머신은 하드웨어 구성요소가 전혀없는 소프트웨어로 구성되므로 물리적인 하드웨어를 넘어서는 여러 가지 장점을 갖고 있다 가상자원(vCPU, vMem, vDisk, vNIC)을 갖고 있기 때문에 운영체제, 애플리케이션, 다른 컴퓨터의 네트워크들은 가상머신과 물리적인 장치의 차이를 인지하지 못하게 되는 것이다. 대표적인 Tool로 Oracle 사의 Virtual Box가 있다.

Docker
Docker는 오픈소스 프로젝트 명인 동시에 기업명이기도 한다. Go 언어로 작성된 리눅스 컨테이너 런타임 패키징 오픈 플랫폼으로 리눅스 컨테이너 기술을 자동화하여 쉽게 사용할 수 있게 해준다. 컨테이너라는 것은 새로운 개념은 아니다. 기존부터 존재한 기술이었지만 복잡하고 어려워 활발하게 사용되지는 않았다. 하지만 닷클라우드란 기업이 도커에 대한 기술지원을 시작하면서 활발해졌다. 리눅스 컨테이너 기술은 가상화 기술과 비슷한 기술이다. 하지만 가상화 기술은 하이퍼바이저란 기술이 반드시 있어야 한다. ( 하이퍼바이저는 하나의 컴퓨터에서 여러 개의 OS를 사용할 수 있게 도와주는 기술을 말한다. ) 가상화 기술을 통해 갖춰진 가상화 환경은 Host OS를 공유하며 그 위에 Guest OS가 올라가는 것이다.
도커는 하이퍼바이저와 달리 Guest OS를 두지 않고 호스트 OS의 커널을 바로 사용한다. 때문에 리눅스 커널이 작동되는 곳에서라면 어느 곳에서든 작동한다. 하이퍼바이저 대신 도커 엔진이 올라가 호스트 OS와 여러 애플리케이션을 연결해주는 역할을 한다. 따라서 도커를 사용하면 가상화보다는 내부에서 더 적은 일을 처리하고 애플리케이션을 좀 더 빠르고 효율적으로 실행시킬 수 있다.

두 가지의 차이점 정리
가상머신은 수 GB에 달하는 애플리케이션, 바이너리/라이브러리 및 게스트 OS를 포함하고 있다.
VM이 생성될 때마다 내 PC 애플리케이션 공간에 게스트 OS가 구동되며 크기, 속도의 문제가 있다.
Provision Tool

Ansible이란?
ansible이란 테스트 환경을 구축하는데 사용되는 Tool이다. 즉, Provision & configuration management tool로 오픈 소스 버전과 Enterprise 버전이 따로 존재한다. 다른 provision tool로는 Chef, Puppet, Chpistrano 가 존재한다. 다른 provistion tool이 ruby로 개발된 반면에 ansible은 python으로 개발되었다. YAML이라는 언어를 통해 정의할 수 있고 json으로 통신하며 github에서 정말 활발한 활동성을 보인다.
ansible 선택에 따른 이점은 빠른 SSH 통신, 빠른 provision이 가능하다. 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질은 멱등성을 제공하며 자동 배포 환경이 쉽다. 그리고 오픈소스 버전이 존재하기 때문에 개발 가능성이 높다.
>> provision 이란? >>
cf> YAML 이란
YAML은 Yet Another Markup Language의 약자(현재 공식적인 약자)로 사람이 쉽게 읽을 수 있는 데이터 직렬화 양식이다. 핵심은 문서 마크업이 아닌 데이터 중심에 있다. YAML은 모든 데이터를 리스트, 해쉬 , 스칼라 데이터의 조합으로 적절히 표현할 수 있다는 믿음에 만들어졌다. 문법은 상대적으로 이해하기 쉽고 XML과 거의 비슷하다. ruby, python개발자에게는 property 파일로 활용되나 다른 언어 개발자들에게는 생소할 수 있는 언어이다.
최근에는 Spring 진영에서도 외부에서 데이터를 로드하는 경우에 사용된다. 자바의 properties 파일의 사용에는 표현의 한계가 존재하기 때문에 properties에 YAML을 사용한다. Spring Boot에는 SnakeYAML을 포함하고 있어서 쉽게 외부 파일을 YAML으로 작성하여 로드할 수 있으며 객체로 매핑할 수 있다.
DevOps란 무엇이며, CI는 무엇인가?(각 종 Tool들…)
Tech Trend

DevOps란 무엇이며, CI는 무엇인가?(각 종 Tool들…)

DevOps란 무엇이며, CI는 무엇인가?

Click the link to read the original article: DevOps란 무엇이며, CI는 무엇인가?

====================

DevOps에 대해서,

하나의 소프트웨어를 개발하기 위해서는 여러 명이 동시에 개발할 수 있는 환경도 필요하며, 수천명의 사용자를 상대로 내놓으려면 서버와 스토리지, 운영체제 등 뒷단에서 관리해줘야 하는 인프라 환경도 갖춰야 한다. 이러한 역할을 수행하는 것이 Ops의 역할이다. 개발자(Dev)는 고객에게 제공한 변경을 빠르게 보길 원하고 운영자(Ops)는 제공하는 서비스 또는 소프트웨어의 안정성에 더 관심을 두게 된다. 또한 개발자는 개발 생산성을 향상시킬 수 있는 새로운 프레임워크를 도입하고 싶어하지만 Ops는 안정성이 보장되지 않는다는 이유로 이를 꺼려한다.
서로 다른 목적을 갖고 다른 프로세스로 다른 도구를 사용하여 개발을 진행하는 것이다. 이런 차이점 때문에 Dev와 Ops간에 충돌이 발생한다. 이러한 배경에서 등장한 것이 DevOps이다. DevOps란 소프트웨어 개발자들과 IT종사자들 사이의 의사 소통, 협업, 융합을 강조한 소프트웨어 개발 방법론이며 소프트웨어 개발과 IT 운영간의 상호 의존관계에 대한 산물이다. 조직에서 DevOps의 역할은 소프트웨어 상품과 서비스를 신속히 생산하는 것에 도움이 되는 임무를 수행하게 된다. Dev와 Ops 간에 그 목적을 일치시키고 프로세스와 도구에 대한 접근을 공유하여 그 차이를 줄이는데 목적이 있다.
CI(Continuous Integration)란 무엇인가?
개발자가 각각 개발한 소스코드를 모아서 한꺼번에 빌드하는 통합 빌드의 과정을 특정 시점이 아니라 주기적으로 수행함으로써 통합에서 발생하는 오류를 사전에 해결하고 이러한 과정들에 소요되는 시간을 줄이기 위한 기법을 말한다. 더이상 빌드는 컴파일만을 의미하지 않는다. 소프트웨어가 거대해지고 복잡해지면서 팀 단위로 개발을 하게 되었고, 그 과정에 있어서 분업과 협업은 필수적이 되었다. 이 분업과 협업의 과정에서 소스 버전 관리 툴을 이용한 소스 코드의 Merge 과정은 까다롭게 되었고, 이 문제를 해결하기 위한 기법이다. Agile 방법론이 대두되면서 이는 더욱 주목받게 되었으며, 배포를 위한 빌드 단계, 테스팅 단계 등에서 시간을 절약하는 효과를 발휘하여 빠른 시장 변화 속도에 발맞춰 대응할 수 있다. 속도와 품질 두 마리의 토끼를 잡을 수 있는 것이다.
CI 시스템 구축을 위한 핵심 구성요소
CI Server
빌드 프로세스를 관리하는 서버로 Jenkins가 여기에 속한다.
ex) Jenkins, Travis CI,  etc
SCM(Source Code Management)
소스코드 형상 관리 시스템으로 Git이 여기에 속한다. 소스코드의 개정과 백업 절차를 자동화하여 오류 수정 과정을 돕는다. 팀 프로젝트의 경우 각자 수정한 부분을 전체가 자동으로 동기화 할 수 있는 시스템이다.
ex) subversion, Git etc
Build Tool
컴파일, 테스트, 정적 분석 등을 실시해 동작가능한 소프트웨어를 생성하는 도구로 Maven이 여기에 속한다. 빌드는 형상 관리 시스템에 있는 소스코드를 가져와 컴파일하여 실행 가능한 파일로 만드는 일련 과정을 일컫는 말이다.
ex) Maven, Gradle, Ant, make etc
Test Tool
작성된 테스트 코드에 따라 자동으로 테스트를 수행해주는 도구로 빌드 툴의 스크립트에서 실행되며 JUnit이 여기에 해당한다.
ex) JUnit, Mocha etc
빌드 스크립트를 통한 CI 자동화 수행 절차
1. 소스코드를 바이너리 파일로 컴파일 한다.
2. 바이너리 파일을 배포 형태로 패키징 한다.
3. 단위 테스트를 수행한다.
4. 정적 분석을 수행한다.
5. 분석 결과를 리포팅 한다.
6. 패키징한 파일을 테스트 서버에 배포한다.

>> 각종 Tool들에 대해서 >>

‘개념에서 의의까지’ 데브옵스 따라잡기
Tech Trend

‘개념에서 의의까지’ 데브옵스 따라잡기

‘개념에서 의의까지’ 데브옵스 따라잡기

Click the link to read the original article: 데브옵스따라잡기

==========

데크옵스라는 용어의 정의를 추적하다 보면 ‘애자일’, 시스템 관리’ ‘린’(lean) 등의 유행어 집합을 접하게 된다. 결국 동어반복에 그치는 설명들이다. 여기 좀더 이해가 쉬운 해설을 제시한다.

데브옵스(DevOps)의 기본 개념은 개발자(Developer)와 운영자(Operator)라는 두 가지 역할을 동시에 수행한다는 것이다. 얼핏 단순한 복합 직무로 여겨질 수 있다. 그러나 사실 데브옵의 개념을 보다 잘 이해하기 위해서는 개발자와 운영자 두 직무가 지금까지 어떤 역할을 수행해왔는지를 잠시 생각해볼 필요가 있다.

운영자의 책무는 업타임(uptime)과 안정성을 보장하는 것이었다. 그 역할을 수행하는 가장 간단한 방법은 시스템의 통로를 걸어 잠그고 변화를 최소화하는 것이다. 이와 반대로 소프트웨어 개발자는 변화를 만들어내는 사람이다. 기본 역할에서부터 그 방향성이 정반대인 것이다. 즉, 데브옵스의 시작은 두 역할 사이의 벽을 허무는 것에서부터 출발한다.

여기 그 사례를 살펴보자.

수 년, 길게는 수십 년 전부터 시스템 관리자들은 반복적 작업과 설정을 자동화하기 위해 몇몇 스크립트(배시(bash), 펄(pearl), 오크(awk), 세드(sed))를 작성해왔다. 이들 스크립트는 코드지만, 시스템 관리자들이 작성하는 코드는 프로그래머들이 따라야 하는 방법론들 중 무엇도 따르지 않았다.

이는 어떤 요청이나 공식적인 테스트 프로세스, 배치 프로세스도 갖추지 않았으며 소스 코드 통제에도 포함되지 않았다. 어떤 작업 표준도 가지지 않으며 이들 코드는 생산 코드와는 다른 프로그래밍 언어를 취했다.

코드의 대상 가운데는 프로그래머가 재사용 가능한 것도 있었지만 프로그래머들은 그것의 존재를 알지 못했다. 두 직무 사이의 공동 작업 구조가 있었다면 지식과 활동, 근본적으로는 코드베이스의 공유까지 가능했을 것이다

시스템 관리 작업의 자동화와 반복은 프로그래머들이 가장 잘 할 수 있는 작업이다. 이런 문제의식에서부터 시작된 것이 오늘날의 데브옵스 트렌드라 할 수 있다.

Credit: ThinkStock

데브옵스라는 개념
구축과 배포, 유닛 테스트 재구동, 통합, 엔드 투 엔드 확인 작업 자동화, 가상 머신(VM) 생성… 모두 명확하고 정의 가능한 비즈니스 프로세스들이다. 실제로 시스템 관리자들은 이와 관련한 메뉴얼북이나 FAQ, 위키 페이지 등을 제작해 업무에 활용하기도 한다.

프로그래머는 자동화 하는 게 일이다. 그렇다면 개발자의 역할(자동화)과 운영(배치 및 유지)을 합쳐버리는 건 어떨까? 운영의 일부를 자동화하고 테스팅하는 두 역할을 병합한다는 것이야말로 데브옵스의 핵심을 이루는 개념이다.

분업을 중시했던 전통적인 IT 및 프로세스 엔지니어링 분야에 있어 데브옵스는 분명 부정적인 것으로 간주될 수도 있다. 그렇지만 수많은 워터폴(Waterfall) 프로세스 문서들은 스크럼이나 애자일 소프트웨어에 대해서도 비슷한 말을 하지 않았던가?

데브옵스의 두 가지 방식
첫 번째 방식은 개발자들이 짧게는 수 주에서 수 개월 정도 운영 과정에 참여하게 하는 것이다. 이론적으로는 인-옵 프로그래머(programmer-in-ops) 가 기존 코드베이스를 체크하고 주기적인 작업을 스마트한 방식으로 자동화 하며, 재사용 가능한 코드 라이브러리를 만들고, 코드를 통해 만들어 낸 가상 머신으로 물리적 머신을 대신할 수 있게 될 것이다.

이 방식은 얼핏 보기에는 분명 즉각적인 성과를 만들어낼 것처럼 보이기도 한다. 하지만 실제로는 프로그래머가 과중한 업무량에 지쳐 쓰러지고 실제 데브옵스 도입이 제한적으로 머물게 될 확률이 높다.

또 다른 방법은 개발 팀에 지원 책임을 높게 할당하는 것이다. 예를 들어 프로그래밍 팀에서 빌드에서 배치, 지원까지 모든 책임을 맡아 한 번에 2주씩 지원 업무를 경험하도록 하는 것이다.

이를 통해 개발자는 코드베이스에 대해 더욱 폭넓은 이해를 할 수 있게 되고 자신의 일을 지원하는 것이 얼마나 쉽지 않은 일인지도 알게 된다. (그렇지만 여전히 소규모의 운영 팀이 생산 서버나 데이터베이스 같은 인프라스트럭처를 지원해줘야 할 것이다.)

빌드 자동화
지속 통합(CI, Continuous Integration) 툴이야 말로 여기 언급된 것들 중 가장 널리, 많이 쓰이는 툴일 것이다. 일부 기업들은 빌드를 계속하기도 하지만 자동화 빌드의 잠재력은 컴파일 단계에서 그치지 않는다. 브랜치에 따른 로깅 및 태깅 빌드를 포함할 수도 있고, 커밋 넘버와 브랜치에 연결된 아카이브에 빌드를 저장할 수도 있으며, 빌드에 기능을 연결할 수도 있을 지도 모른다.

빌드가 완성되면 항상 모든 유닛 테스트를 진행할 수 있을 뿐 아니라 소프트웨어를 개발, 테스트, 및 스테이징 서버에 언제든지 배치할 수 있다. CI툴에서 웹 서비스나 GUI 엔드 투 엔드 체크를 통해 새로운 코드에 큰 결함은 없는지 살펴볼 수 있다.

그렇지만 이것이 지속적 전달(continuous delivery )은 아니다. 코드가 자동으로 프로덕션 코드가 되는 것은 아니다. (일부 기관들에서는 배치할 때마다 개발 환경을 업그레이드 하는 게 아니라 완전히 새로운 가상 서버를 구매하기도 하고, 프로그래머 당 하나 이상의 가상 환경을 만들기도 한다.)

결함으로 인해 발생하는 데미지가 해당 결함의 심각성과 그것이 얼마나 많은 사람들에게 노출되었느냐에 의해 결정된다고 한다면, 최대한 빨리 그 결함을 발견하고 수리하는 것이야 말로 피해를 최소화하는 방법일 것이다. 많은 사용자들이 발견하기 전에 문제를 먼저 발견하는 것이 쉽지만은 않지만, 시각적 모니터링과 대체로 어느 정도 도움을 받을 수 있다.

서버 로그에는 엄청난 분량의 정보가 들어 있다. 리퀘스트 처리에 얼마만큼의 시간이 걸리는지에서부터 시스템에 404, 500 에러가 얼마나 발생했는지까지 말이다. 이 에러들을 그래파이트(Graphite)와 같은 오픈소스 툴을 사용해 그래프로 시각적으로 표현하면 문제가 발생하는 즉시 이를 파악하고 조치를 취할 수 있다.

이러한 작업이 완성되고 나면, 프로덕션 롤아웃 단계는 웹 페이지, 혹은 최소한 명령행 인터페이스상에 자동화할 수 있다. 지속적인 배치 시스템은 여기서 프로덕션으로 한 단계만 더 나아가면 된다.

푸시 버튼 배치는 푸시 버튼 해결책으로 이어지게 되고 이는 프로덕션 모니터링과 만나 결함의 TTL(time to live)을 극적으로 줄이게 된다.

설정 플래그
설정 플래그(Configuration Flag)는 TTL을 줄이는 또 다른 메커니즘이다. 프로덕션 코드를 바꾸는 대신 새 코드에 “if(feature){}”을 적용해 코드를 바꾼다. 프로그래머는 플래그를 온 또는 오프로 저장한 디스크상의 파일을 바꾼다. 이는 코드를 변경하는 것이 아니므로 새로운 빌드/배치가 필요 없다.

노아 서스먼(Noah Sussman)의 “컨피그 플래그: 러브 스토리(Config Flags: A Love Story)”는 이 주제를 훨씬 깊이 있게 다루고 있다. 설정 플래그는 점진적인, 그리고 궁극적으로 폭넓은 고객 유형을 만족시키는 방안이 될 수 있다. 맨 처음에는 직원, 다음으로 직원들의 가족, 베타 테스터, 리스크 감내 고객, 다음으로는 정기 고객, 그리고 마지막으로 ‘기업’고객 및 리스크 회피적 고객 순으로 배포 범위를 넓혀나감으로써, 새로운 기능을 알려나가는 과정에서 시스템 관리와 피드백 수집의 이점을 누릴 수 있다.

그 구체적인 방법론은 다양하게 전개될 수 있지만, 대표적인 전략을 한 가지 소개하자면 2008년 출간된 “마이크로소프트의 소프트웨어 테스트 비법(How We Test Software in Microsoft)”에 소개되며 알려진 ‘생산 중 테스트(Testing in Production)’을 이야기해볼 수 있다.

이 아이디어들은 대부분 컨셉트에 그치지만, 그것을 실행할 방법은 상용, 오픈소스 시장에 다양하게 존재한다. 가장 흔히 이용되는 전략 중 하나는 퍼블릭/프라이빗 클라우드 내에 가상 서버 팜을 생성하는 것이다. 새로운 빌드를 생성하되 배치하지 않는 방식이다.

이 경우 시스템은 새로운 기기로 로드 밸런스를 조절해 보낼 수 있다. 이러한 서비스 ‘전환’은 사용자가 그 과정을 인식할 수 없도록 이뤄진다. 또한 혹 발생할 수 있는 심각한 문제에 대비해 전환 후 수 분 간은 기존 시스템 역시 대기하게 된다.

(실물 혹은 가상) 기기 셋을 설정하는 것은 다량의 스크립팅과 자동화를 요구한다. 이 과정을 지원하는 툴로는 셰프(Chef)와 퍼펫(Puppet)이 대표적으로, 모두 데브옵스 업무에 자주 사용되고 있다.

데브옵스에 관해 듣게 되는 가장 실망스러운 말은 데브옵스가 ‘새로운 역할’라거나, 이를 위해 제 3의 ‘팀’을 꾸려야 한다는 것이다. 일부 개발자들은 자동화 혹은 인프라스트럭처 작업의 구축/배치를 선택할 수도 있지만, 데브옵스라는 아이디어는 본래 공동 작업을 원칙으로 한다. 다른 이들이 이해하지 못하고, 신경도 쓰지 않는 모호한 디테일들을 다루는 특수직이 되어버린다면, 결국 데브옵스은 머지않아 자취를 감추게 될 것이다.

데브옵스 테스트는 당신의 팀이 어느 정도나 데브옵스을 받아들였는지, 그리고 앞으로 받아들일 수 있을지를 간단히 평가할 수 있는 도구다. 완벽하진 않지만 빠르고 간편하게 진행할 수 있으니 시험 삼아 참여해보자. 결국 미래는 당신이 써 내려가는 것이다.

원문보기:
http://www.ciokorea.com/news/25644?page=0,1#csidx1ec2d172b7135cb8ee0c184a43bf794 
원문보기:
http://www.ciokorea.com/news/25644?page=0,0#csidx5975ae5a195efbe915bfc2203cbf20e 

DevOps란 무엇일까?
Tech Trend

DevOps란 무엇일까?

DevOps란 무엇일까?

Click the link to read original article: DevOps란 무엇일까?

============================================

이 글은 기술이야기는 아닙니다. 조직이야기입니다. 그리고, 일반론도 아닙니다. 하지만, 해당되는 분이라면 한번쯤 고민해보셨으면 좋겠습니다.


road-to-devops-roi-7-638

클라우드 서비스를 하는 클라우드먼치는 이미 오래전에 DevOps에 대한 ROI를 따졌다. 이 부문이 DevOps에 대한 필요성이 가장 높았기 때문이다.

DevOps는 그냥 “운영”이 아니다.

SI만 하던 분들은 “개발운영”을 그냥 “운영”으로 이해합니다. 그냥 “운영”은 시스템이 멈춰서지 않도록 관리해주는 것에 가깝습니다. 제조업이나 공장 등 산업 인프라 쪽은 그게 매우 중요합니다. 쉬지 않고 대량생산을 해야 하니까요.

하지만, 인터넷 서비스는 그렇지 않습니다. 봄,여름,가을,겨울 계절별로 마케팅을 합니다. 사업 제휴에 따라 신규 기능이 막 추가 되기도 합니다. 규제가 생기면 거기에 맞추어 이것저것 수정을 해야 합니다. 즉, 시스템 자체가 판매 매장이기 때문에 변경이 발생될 수 밖에 없습니다.

비유하자면, “시스템 신규 구축”은 백화점을 건설하는 일입니다. 반면 “시스템 운영”은 매장을 운영하는 것입니다. 진열방식을 바꾸고 시즌별로 상품을 교체합니다. 건물의 변화는 없습니다. 하지만, 개발운영은 “매장 운영”을 하면서, 백화점을 증축하는 일입이다. 어떤 경우는 본점보다 더 큰 별관을 뒤에 지어야 합니다.

완전히 다른 업무이다.

그래서 개발 리소스의 핸들링 방법이 아예 다릅니다.

증축공사가 크면, 별도 개발팀을 꾸려야 합니다. 물론, 기존 건물의 설계도와 시공정보도 함께 있어야겠지요.

증축공사가 작아도, 계획 관리는 따로 해야 합니다. 고객들에게 불편을 끼치면 안되니까요. 먼지가 많이 나고 소리가 크면 영업에 방해가 됩니다.

같은 조직에 운영과 증축을 함께 시키면 조직의 생산성은 보통 1/4 이상으로 떨어집니다. 경영자는 비용이 줄어들거라고 생각하지만, 오히려 커지는 경우가 대부분입니다. 사업에도 집중하지 못하고, 증축일시도 지키지 못해 사업이 어려워지기까지 합니다.

이거 잘 이해해야 합니다. 그리고 잘 설명해줘야 합니다. 경영자는 100% 헷갈리고, 개발자들도 10% 밖에 이해하지 못합니다.

devops3

사업팀과 전략팀, 개발부서 간에 관리하는 상이한 지표들. 즉, “DeLone”, “McClean”이 이야기하는 전통적인 IT성공모델이 달라졌다는 것을 의미한다.

※ 참고 링크 : Delone and McClean 의 Information Systems Success Model

기술보다 업무로 이해해야 한다.

갈라진 벽면에 시멘트를 발라 보수하는 것과, 증축하는 벽면에 시멘트를 붓는 것은 같은 기술입니다. 하지만, 공법이 완전히 다릅니다. 기술이 같다고 같은 일이 아니라는 뜻입니다.

개발자 분들은 “일”을 “기술”이 아니라 “업무”TASK로 보았으면 좋겠습니다. “금방 되요.” 이런 이야기 안했으면 좋겠습니다. 마감도 분명 업무이고, 잡무를 처리할 기타 개발자들이 따로 있는 게 아닙니다. 거기에 들어가는 시간도 절대 공짜가 아닙니다.

경영자는 김대리의 코딩 능력이 궁금한 게 아닙니다. 비용과 기간이 얼마나 되는지 궁금합니다. 거기서 “금방 됩니다”라고 이야기하는 건 넌센스입니다. 어떻게 해야 우리 회사가 적당한 비용에 원하는 시스템을 제때 가질 수 있는지 이야기하는 게 맞습니다.

DevOps는 사람을 줄이는 방법이 아니다.

DevOps는 운영자 두 사람을 개발자 한 사람으로 줄이는 방법이 아닙니다. 개발Dev과 운영Ops을 분리하기 힘든 비즈니스를 “잘 해나가는” 방법입니다.

그런데, 한 사람이 모든 일을 다 처리하면 업무 효율은 오르겠지만 생산성에 한계가 생깁니다. 푸쉬하면 조금 더 오르겠지만 근본적으로 바뀌지는 않습니다.

소프트웨어는 “소프트” 하긴 하지만 “도깨비 방망이”가 아닙니다. 들쭉날쭉한 생산량으로 비용예측을 할 수 없습니다. 인터넷 서비스는 “시스템”과 “개발팀”을 가지고 하는 사업입니다. 엄연히 원가와 비용이 있고 현금흐름과 자금회전주기도 있습니다. 생산단위 예측이 되어야 수지타산을 맞춰볼 수 있습니다.

DevOps는 전체 절차를 줄여서 서비스의 효율성과 기민성을 높이려고 하는 것입니다. 사람을 줄여 놓고, 비용이 줄어들기를 기대하는 것은 잘못된 접근입니다.

문제를 해결하지 못하면, 도구는 짐이다.

Continuous Integration, Continuous Delivery 모두 중요하지만 그 출발점이 어디인지를 명확히 인지했으면 좋겠습니다. 인터넷 서비스를 하다보면 여러가지 문제에 부딪힙니다. 그 중 몇 개의 문제를 해결하기 위해 CI와 CD가 만들어졌습니다. 즉, CI, CD를 하면 모든 문제가 해결되는 것이 아니라는 뜻입니다.

사람이 문제를 푸는 거다.

CI와 CD가 필요한 상황까지 서비스가 발전하는 것이 첫번째입니다. 그 상황이 되면 CI와 CD로 풀 수 없는 문제도 생기게 됩니다. 좋은 탈곡기가 들어왔다고 벼농사가 잘 되는 것은 아닙니다. DevOps는 “툴” 중의 하나란 걸 인지하시고, 함께 일하고 있는 “사람”에게 좀 더 집중했으면 합니다.

참고로, “개발운영”은 개발하면서 운영을 한다는 의미가 강합니다. 즉, 개발에 무게감이 더 실립니다. 반면 “운영개발”은 운영을 위해 개발한다는 뜻이 강합니다. 즉, 운영에 무게감이 더 실립니다. 사람마다 의견이 다를 수 있지만, 저는 그렇게 느낍니다.

※ 참고글 : DevOps의 ROI를 증명하기 위한 지표는 무엇일까? (David Leanwook, 2017.2.17)

저자가 영국분이신데 운영쪽으로 입문을 해서, 지금은 컨설턴트로 일을 하고 있습니다. 석사논문으로 운영팀의 ROI에 대한 연구를 했습니다. 조금 부럽네요. 개인적으로는 이런 연구와 시도들이 점차 IT산업의 격차를 벌릴 거라고 봅니다.

DevOIps, 그문화에 대해서…
Tech Trend

DevOIps, 그문화에 대해서…

DevOIps, 그문화에 대해서…

Click the link to read original article: DevOps, 그문화에 대해서…

====================================

개발 방법론이나 소프트웨어 개발과 관련된 은빛 탄환과도 같은 뉘앙스를 풍기는 접근법은 수없이 많았다. 이제는 최고의 화두로 떠오른 DevOps에 대해서 삐딱한 아키텍트의 생각으로 끄적거려 보자.

주변에 DevOps를 지향하는 개발회사들이 많다. 그리고, DevOps를 무슨 완전체인 것처럼 소개하는 칼럼이나 글들도 많다. 그렇다면, DevOps의 정체는 무엇이며, 우리 회사, 우리 개발팀이나 운영팀은 그런 준비가 되어 있는 것인지에 대해서 생각해봐야 한다.

사람들은 정말 DevOps가 어떤 의미이기에 사람들이 궁금해하고 있는 것일까?, 그리고. 과연 정말 내가 속한 조직과 팀이 DevOps를 지향할 수 있을까? DevOps에 대해서 삐딱한 아키텍트가 생각해보는 것이 이번 칼럼의 목적이다.

DevOps는 모든 팀, 모든 회사, 모든 곳에 사용되는 만병통치약이 아니다.

DevOps는 새로운 개념인가?

Culture와 movement에 대해서 먼저 이야기를 시작하는 것이 맞을 듯하다. Culture는 어떤 한 국가나 집단의 문화와 같은 것을 의미한다. 그리고, movement는 어떤 움직임을 의미하는 것으로 여기서 사용되는 의미로는 사람들이 조직적으로 어떤 것을 벌리는 운동을 의미한다.

일반적으로 문화란 어떤 옷, 음악, 형태를 가진 조형물 등을 포괄하는 것으로 무형, 유형의 것을 모두 포함하는 것이 문화라고 할 수 있다.

그리고, 이러한 문화는 해당 문명과 조직, 사회의 모든 것을 표현하고 있는 것이며, 그것에 대비하여 문화라는 형태를 통해서 표현한다. 그래서, 소프트웨어 개발의 조직이나 기업에서도 자체적인 개발자 문화라는 것이 존재하고 있다. 이는, 일반적으로 각 회사별로 그 형태나 상황, 사람들의 모습, 역사적인 배경과 발전과정을 통하고, 어떤 사람들이 그 조직을 거쳐갔느냐에 따라서 많은 부분에 있어서, 개발자들의 문화는 매우 다르다고 할 수 있다.

이처럼, 개발자 문화의 영향으로 소프트웨어 개발 방법론과 같은 무형의 것부터, 실제 산출물, 개발 소스와 같은 실제 눈에 보이는 것까지 개발자 문화란 눈에 보이는 것과 눈에 보이지 않는 것을 모두 포함한다고 할 수 있다.

이런 개발자 문화를 언급하기 전에, 개발자들의 운동과 운동을 위한 선언과 같은 것에 대해서 알아보자. 그중에서도 movement를 먼저 살펴보자. 개발자들 커뮤니티와 개발자들의 요즘 철학적인 움직임은 ‘요구사항’ 변동에 대해서 이제 관대한 생각을 가지기 시작했다고 볼 수 있다.

어차피, 요동치는 요구사항에 대해서 ‘완결된 요구사항’이 나올 것이라고 기대하지 않고, 요구사항은 사랑하는 애인의 변덕스러운 마음이라는 생각을 가지기 시작한 것이 DevOps의 원칙적인 기본 생각의 변화라고 먼저 이야기를 하고 싶다.

이제, 개발자들은 요동치는 사람들의 마음이나 사회적인 변덕을 소프트웨어로 반영하는 것을 매우 당연스럽고 자연스러운 과정이라고 인지하기 시작한 것이라고 볼 수 있다. 이처럼 기본적으로 요구사항이 변덕스러운 기획자나 고객의 마음이 당연한 것이라고 생각한다면, 오히려, 더 행복한 개발이 가능하도록 기준이나 계획을 잡을 수 있는 것 아닐까?

이것이 DevOps의 개념 전환의 기본적인 개념이라고 볼 수 있다. 오히려. 처음부터 요구사항이 잘 정해졌고, 더 이상 변하지 않을 것이라고 거짓말을 하고 있는 기획자와 고객들의 마음속에 변덕스러운 변화에 대해서 이제는 관대한 개발자가 되려는 마음을 가진 것이라고 생각할 수 있다고 소프트웨어 개발자들은 이해하기 시작한 것이다.

DevOps는 이러한 마음가짐의 변화와 movement가 먼저 필요하다. 기존의 개발 방법론이나 개발 문화에서 정의하려고 하였던, 뜬구름 잡는 ‘요구사항 명세’는 어차피 불가능한 것이니까, 그 부분을 매우 관대하게 받아들이고자 변화의 마음을 가지게 된 것이라고 생각한다. 그래서, 실제 고객을 만족시키는 요리사의 마음에다가 고객의 마음을 좀 더 가까이에서 이야기를 나눌 수 있는 웨이터의 마음을 가지고 시작해야 한다고 설명하는 것이 더 현명할 수 있다.

이러한 변화의 요소에는 다음과 같은 개발자들이 두려워하는 몇 가지 요소들에 대해서 이제는 정말 명확하게 이야기할 수 있기 때문에 DevOps는 가능하다고 생각한다.

DevOps의 내면에 깔려 있는 소프트웨어 개발자들의 두려움을 먼저 알아야 DevOps의 기본적인 원칙에 좀 더 접근할 수 있다. 그것은 다음에 나열된 내용들은 일반적으로 소프트웨어 개발자들이 어려워하는 것들이다.

1.  소프트웨어를 솔루션 형태의 디자인으로 만드는 것은 정말 어렵다

 개발자들은 솔루션을 만들고 그것을 디자인하고 설계, 구현한다는 것은 정말 어려운 것이라고 인지하기 시작하였다. 솔루션을 만들고, 어떤 문제를 해결한다는 것은 정말 험난하고 고된 일이라고 이미 인지하였다.

2.  테스트 케이스를 작성한다는 것은 정말 어렵다
수많은 사용자의 환경을 인지하고, 그것에 대응하는 완벽한 테스트는 불가능하다는 것 또한 개발자들은 인지하였다. 그리고, 그 테스트를 만들기 위해서 쥐어뜯었던 머리카락과 수많은 시간들에 대해서 완전이란 불가능하다는 것을 인지한 것이다.

3.  개발 관련 문서작성 또한 매우 어려운 것이다
개발자들 간에 상호 소통하기 위한 문서의 작성과 다이어그램과 모델을 만든다는 것 또한 정말 어려운 일이다. 또한, 그것을 표준이나 변화해가는 기술적인 요청과 반영 내용을 모두 담는다는 것은 정말 어려운 일이라고 인지하였다.

4.  개발자 자신이 동의하지 않는 기능 구현을 허구 헌 날 해야 한다는 것
간혹이 아니라, 상당 부분 발생하는 동의하지 않는, 쓸모없다고 생각하는 기능 구현에 매달리고 있는 현실에 대해서 이제는 약간은 무덤덤하게 대응할 수 있는 개발자들의 마음가짐은 정말 관해하게 변화하였다.

5.  다른 사람이 작성한 코드를 다루는 것인 매우 당연하다는 것
생각 이상으로 다른 사람의 코드와 프레임워크에 가두어진 상태로 프로그래밍을 해야 한다는 것에 대해서 학교에서는 가르치지 않았다는 것을 매우 두려워하고, 원망한다. 타인이 만들어 놓은 코드에 대해서 읽는 방법에 대해서 가르쳐 주지 않은 교수님이 원망스러울 뿐이다.

6.  고객과 같이 비전문가와 커뮤니케이션해야 한다는 것
비전문가와 소통하는 방법에 대해서 아무도 가르쳐주지 않았다. 사실은 그들과 소통하고 그들을 설득하는 것이 최선의 방법인데, 왜? 그들과 소통하는 방법은 학교에서 가르치고 있지 않는가? 혹시. 교수님들도 그것을 포기한 것 아닌가 하는 의심이 든다? 그러한 마음이 생기기 시작하였고, 과거의 방법론이나 공학에 대해서 의심을 하기 시작하였다.

7.  업무 완료에 필요한 시간 예측은 필수가 되었다는 것
기능 단위의 시간 예측과 일정에 대해서 ‘감’이 필요하다는 것은 실제 현업에 나와서야 만 가능하다는 것을 이야기해준 선배와 교수가 없었다는 점도 실제 현업의 초기에 어려움을 느끼는 부분들이다.

8.  업무의 우선순위와 작업 할당이 애매하다는 것
도대체 누가 결정하는가? 그 순서에 대해서 아무도 모른다.

9.  이름을 만들고, 이름과 의미를 부여한다는 것은 매우 어렵다는 것
그냥, X, Y, I, j, k를 부여하면 안 된다고 하는데, 생각 이상으로 붙여야 할 이름과 규칙들이 너무도 많다.

이처럼, 소프트웨어 개발이 어려워지고 두려워지는 개발자들보다 더 어려운 것도 있다는 사실을 소프트웨어 개발자들은 경험으로 터득한다. 그것은 다음과 같은 상황이다. 그리고, 해결책도 없다는 점이다.

위의 두려운 상황은 ‘단단한 마음’으로 이겨낼 수 있지만, 정마로, 다음의 상황들은 가능하면 소프트웨어 개발자들이 피하고 싶어 진다. 하지만, 우리가 지금 당장, 어제, 그리고 내일도 만날 수 있는 상황이다.

1.  무능력한 경영진의 삽질
2.  멍청한 동료 개발자의 어설픈 코드
3.  특정 기술이 무슨 이유에서 쓰이는지도 모르고 강제로 배우거나 사용해야 하는 것
4.  재미있어 시작한 개발일이 정말 반복적인 작업에 의해서 재미없어졌을 때
5.  이제 쏟아지는 버그를 만나게 되었을 때

하지만 가장 두려운 상황의 최고봉은 역시, ‘개발자는 고객과 대화를 나누는 것이 가장 두렵다’라는 것이 정답일 것이다. 그리고, 두려운 것은 동료와의 커뮤니케이션과 소통이다. 아마도, 이러한 고객과 동료들 사이에 있다면, 개발자는 당연한 것이지만. ‘개발하는 것이 행복하지 않다’라고 느끼는 것은 매우 당연할 것이다.

여기서. DevOps는 출발한다.

이렇게 ‘개발하지 않는 것이 불행한 개발일’을 하지 않게 하기 위한 일종의 movement라고 생각하면 된다.

아이러니 하지만, 이러한 불행을 해결할 가장 좋은 방법은 행복의 최소 조건이나 개발자가 원하는 개발환경의 최소 조건을 만족하면 된다. 그것은 바로 자원(resource)이 충분한 환경을 만들면 가능하다. ‘돈’이 넉넉하면 부수적으로 대부분 따라오는 것들이다.

하지만, 실제 개발일을 이런 환경에서 할 수 있는 방법은, ‘취미’로 개발일을 하는 경우에만 100% 만족할 수 있을 것이다. 취미는 최종 개발완룐일을 언제든지 뒤로 미룰 수 있기 때문에 ‘무한정의 리소스’를 투입할 수 있는 유일한 방법일 것이다.

DevOps는 개발자가 행복하게 소프트웨어를 개발할 수 있는 환경을 만드는 것이 목표이다. 과거의 개발 방법론이나 문화, 운동들이 대부분 ‘소프트웨어 품질’을 위해서 개개인의 시간과 개개인의 능력 차이를 무시하고 진행되었다면, DevOps는 그 우선순위의 가장 높은 개념으로 ‘개발자의 행복’을 우선순위 위에 둔다.

결론적으로 ‘개발자가 행복’하다면,
자연스럽게 소프트웨어의 ‘품질’을 올라간다는 개념이다.

물론, ‘행복’이 아니라, ‘시간 낭비’라는 단어와 ‘물자와 자원 낭비’라는 결코, 개발자는 행복하지 않을 것이다. 대부분의 개발자들은 ‘시간과 자원의 낭비’를 가장 싫어한다. DevOps는 기본적으로 개발자들을 신뢰해야 형성된다.

DevOps는 소프트웨어 개발과 운영, 서비스의 효율적인 환경을 만들기 위해서 노력하는 개발 문화로써 간단하게 줄여서 설명하자면. ‘소비자, 사용자들의 서비스의 요구사항을 가장 빠르고 단순화하여 대응할 수 있는 신속한 서비스 지원 형태. 그리고, 그것을 지원하고 유지시켜주는 소프트웨어 개발 문화’라고 이야기할 수 있다. 그래서 Development / Operations를 합친 말이라고 본다.

물론, 이렇게 만들어진 환경은 당연하지만 개발자를 ‘행복’하게 할 것이다.

DevOps는 빠르고, 단순화, 신속함이라는 서비스 형태를 지향한다. 그리고, 그것을 지원하고 유지시켜주는 소프트웨어 개발 문화를 지향하고 있다. 실제, DevOps를 구현했다고 평가를 받고 있는 Netflix와 Flickr 등의 개발 성과물들은 정말 놀라울 정도로 효과적이다.

1만 개 이상의 AWS 인스턴스를 불과 10여 명의 DevOps팀이 운영하고, 초당 4만 장 이상의 업로드 부하를 버티고. 자동화된 상태에서 하루 10회 이상의 배포본이 반영되는 매우 효과적인 개발과 운영이 접목된 환경을 만들어 낸다는 사실에 개발자 문화의 최신화 경향을 만들어 냈다.

이렇든 엄청난 효율과 고속의 처리를 만들어 낸 것은 어떤 이유 때문에 가능한 것이었을까? 그리고, 이러한 DevOps의 성과물들은 일반적인 IT기업에서도 얻을 수 있는 환경일까? 가장 먼저 DevOps의 장점을 몇 가지 정리하고 넘어가자.

DevOps의 장점을 서술한다면 다음의 3가지로 선언할 수 있다.

1.  최소 인원으로의 개발과 운영이 가능한 환경을 지향한다
2.  서비스의 배포와 운영이 자유롭고, 서비스가 매우 신속하고 빠르게 운영된다.
3.  개발의 배포가 자동화되며, 그에 따라 고품질 서비스를 지향한다.

자, 그렇다면. 가장 중요한 것은 이러한 DevOps는 내가 속한 조직에서 만들 수 있는 문화와 개발형 태인가? 대부분의 개발 조직에서는 이러한 것에 대해서 가장 궁금할 것이다. 결론부터 이야기하자면 DevOps가 가동되고, 개발 조직의 문화가 되려면 다음의 두 가지가 필수이다.

1.  소프트웨어를 잘 만들어내는 개발자
2.  잘 동작하도록 운영하는 운영자

그리고, 이러한 두 가지의 조건을 만족시키기 위한 기본적인 환경적인 구성이 필요하다. 그것은 가장 먼저 소프트웨어 품질을 관리하는 제대로 된 품질관리 조직이 있어야 하며, 개발 조직이 빠르게 소프트웨어를 개발, 빌드, 테스트, 배포, 운영하게 할 수 있는 사이클을 신속하게 진행할 수 있는 개발환경을 갖추고 있어야 하고 업무 프로세스를 정의하고, 각 조직 간의 역할을 조율하는 프로세스들이 매우 자연스럽게 자동화되어지고 효율적으로 운영되고 있어야 한다. 그래야, ‘소프트웨어를 잘 만들어내는 개발자’와 ‘잘 동작하도록 운영하는 운용자’가 만들어지게 되고, 그 역할과 방법론이 효율적으로 가동되는 DevOps는 가동된다.

DevOps의 원칙

그렇다면, 이러한 DevOps을 세팅하고 구입하기 위해서 조직이 필요로 하는 비용적인 측면은 어떤 것들이 있을 것인지 가볍게 살펴보자. DevOps는 매우 큰 비용을 요구하는 것은 아니다. 다만, 그 비용이라는 것이 전반적으로 투자된 비용을 의미하는 것이지, 단기간에 투입되어 얻어지는 효과는 아니라는 점에 주목해야 한다.

가장 먼저, 개발자들은 기능 개발과 결함의 수정 등의 변화를 얼마나 자주 일으키고 있는지 체크하고 이를 관리하거나, 관리할 수 있는 포인트를 개발자들에게 제공하고 있는가? 하는 측면이 가장 먼저라고 할 수 있다.

두 번째는 운영자가 실제 서비스의 안전성과 성능의 향상을 위하여 취해지는 시스템 아키텍처 적인 변화에 대해서 얼마나 두려워하고 있으며, 이를 얼마나 수치화하여 관리하고있는지, 그리고. 그 선택을 할 수 있는지가 DevOps에 가장 중요한 측면이기도 하다.

세 번째는 이러한 개발집단과 운영 집단에서 선택과 운영, 개발의 우선순위 등을 고르고 선택할 수 있는 ‘권한과 책임’이 주어지고 있느냐 하는 점이다.

네 번째는 큰 조직, 큰 기업, 큰 프로세스의 운영 시에는 이러한 DevOps와 같은 콘셉트는 운영하기 매우 어렵다. 그러므로, 개발과 운영환경의 구분과 절차. 권한과 릴리즈 절차와 규칙 등에 대해서 얼마나 세분화하고 있는지, 그리고. 일에 대해서 얼마나 작은 규모로 산정하고 산출하고 있는지에 대해서도 정의되어야 한다.

아쉽게도 DevOps를 구현하고 싶지만, 착각하고 있는 개발자 조직의 경우의 사례를 살펴보면 다음과 같은 실제 일들이 벌어진다고 볼 수 있다.

1.  사용하지도 않는 기능을 도출하고, 이를 위하여 시간과 비용을 낭비하고 있는 경우
2.  개발 후 버그를 찾기 위해서 테스트를 하고 있다고 프로세스를 정형화하는 일이다. 실제 DevOps를 지향하는 개발 조직의 경우에는 내부적으로 개발 단계에서 충분하게 품질을 고려하여 디자인되고 개발을 진행하려 노력한다.
3.  예측을 위한 투자를 많이 하고 있는가?라는 질문에 소극적인 경우이다. 대부분은 그나마. 사건 발생 시에 빠르게 대처할 수 있는 환경이라고 가능한 구축하라고 권하는 경우가 태반이다.
4.  소프트웨어 공학을 잘 못 받아들여 정말 중요한 지표에 집중해야 하는데, 너무 많은 지표를 도출하기 위하여 삽질을 하는 경우가 대표적인 착각되어진 개발 조직의 경우라고 볼 수 있다.

DevOps을 좁게 보는 진정한 장점

DevOps는 ‘잦은 배포’를 수행하면서, 잦은 릴리즈를 수행하고, 잦은 릴리즈를 통해서 위험을 하향 균등화 시키는 것이 주목적이라고 작게 정의할 수 있기도 하다. 그래서, 애자일과도 아주 잘 맞는다. TimeBox를 2주로 맞추거나 1.5주로 맞추고 배포를 진행하는 경우도 빈번하게 필자는 상황을 참조한다.

하지만, 이러한 DevOps를 구현하는 데 있어서는 다음과 같은 최소한의 필요충분 요건이 필요하다.

1.  잦은 개발과 버그 픽스가 가능한 개발자 환경을 구현하라
2.  공유 소스 코드 버전 관리시스템도 없다면, 이러한 환경을 구성한 다는 것은 거의 불가능하지 않겠는가?
3.  빌드, 테스트, 배포 단계를 자동화하기 위하여 얼마나 노력하고 있는가?
4.  수작업의 실수와 반복을 어떻게 최소화하기 위해서 노력하는가?
5.  개발 조직과 운영조직의 협업을 위하여 빈번한 커뮤니케이션 소통 비용을 지불하고 있는가?

이러한 최소한의 필요충분조건을 만족한다면, 개발 조직은 다음과 같은 최소한의 목표를 이루기 위해서 준비를 한다고 볼 수 있다.

1.  개발과 품질관리, 운영을 교집합적으로 운영하기 위한 방법을 터득하였고, 그것을 개발 조직에 내재화하기 위하여 노력 중이다.
2.  신뢰성, 보안성, 개발과 배포 사이클을 보다 더 빠르게 개선하기 위해서 배포, 테스트, 세부 기능 개발, 릴리즈 관리를 목표로 조직이 운영 중이다.
3.  툴이 아니라, 문화와 일하는 방법에 대한 경험을 더 우선적으로 하고 있다.

DevOps의 가장 중요한 원칙

위에서 이야기한 필요조건과 환경에 대한 것이 준비가 된다면, 다음과 같은 DevOps의 원칙을 실현할 준비가 된 것이다. 그 원칙을 살펴보자

1.  주요 기능에 집중하고 있는가?
2.  품질을 내재화하기 위하여 노력하고 있는가?
3.  개발에 필요한 지식을 창출하기 위해서 과학적으로 접근하고 있는가?
4.  완벽한 명세서를 만들기 위한 비용보다, 명쾌한 협업을 중시하여 커뮤니케이션 비용을 지출하고 있는가?
5.  가능한 한 빨리 개발하기 위해서 시도하고 있는가?
6.  사람을 존중하는 개발자 문화를 만들고 있는가?
7.  최적화를 위한 방안을 고안하는데 회의나 토론을 아까워하지 않고 있으며, 그것에 대해서 투자를 아낌없이 하고 있는가?

이러한 과정은 DevOps에 대해서 실현하기 위해서 노력하는 행위와 절차라고 볼 수 있다. 가능하다면 DevOps의 성숙도 모델에 대한 설명과 실제 우리가 그러한 모델을 통해서 개발 조직에 DevOps의 사상을 표현할 수 있는지에 대해서 설명할 기회가 곧 다가올 것으로 기대해본다.

물론, 기술적 부채에 대해서도 한 번 거론한 다음에 그 이야기를 이야기하도록 하겠다.

DevOps는 애자일과 마찬가지로 선언이고 문화에 해당한다. 즐거운 개발을 지향하고 있다면 소프트웨어 품질은 매우 당연하게 좋아진다. 행복한 개발자가 훌륭한 소프트웨어를 만든다는 것을 잊지 말자. 그것이 DevOps의 시작이며, 출발이다.

Frontend Dev Bookmarks
Tech News

Frontend Dev Bookmarks

Frontend Dev Bookmarks

Frontend Dev Bookmarks

==

 

Backend Development Bookmark
Tech News

Backend Development Bookmark

Backend Development Bookmark

Backend Development


Full Stack Development Resources
Tech News

Full Stack Development Resources

Full Stack Development Resources

https://yhjor1212.gitbooks.io/full-stack-handbook/content/

Front-End Developer Handbook 2017
Tech News

Front-End Developer Handbook 2017

Written by Cody Lindley sponsored by — Frontend Masters

This is a guide that anyone could use to learn about the practice of front-end development. It broadly outlines and discusses the practice of front-end engineering: how to learn it and what tools are used when practicing it in 2017.

It is specifically written with the intention of being a professional resource for potential and currently practicing front-end developers to equip themselves with learning materials and development tools. Secondarily, it can be used by managers, CTOs, instructors, and head hunters to gain insights into the practice of front-end development.

The content of the handbook favors web technologies (HTML, CSS, DOM, and JavaScript) and those solutions that are directly built on top of these open technologies. The materials referenced and discussed in the book are either best in class or the current offering to a problem.

The book should not be considered a comprehensive outline of all resources available to a front-end developer. The value of the book is tied up in a terse, focused, and timely curation of just enough categorical information so as not to overwhelm anyone on any one particular subject matter.

The intention is to release an update to the content yearly.

The handbook is divided into three parts.

Part I. The Front-End Practice

Part one broadly describes the practice of front-end engineering.

Part II: Learning Front-End Development

Part two identifies self-directed and direct resources for learning to become a front-end developer.

Part III: Front-End Development Tools

Part three briefly explains and identifies tools of the trade.


Download a .pdf, .epub, or .mobi file from:

Contribute content, suggestions, and fixes on github:

AVAILABLE NOW: Front-End Developer Handbook 2016
Tech News

AVAILABLE NOW: Front-End Developer Handbook 2016

Front-End Developer Handbook 2016

Front End Handbook

Written by Cody Lindley sponsored by — Frontend Masters

This is a guide that anyone could use to learn about the practice of front-end development. It broadly outlines and discusses the practice of front-end engineering: how to learn it and what tools are used when practicing it in 2016.

It is specifically written with the intention of being a professional resource for potential and currently practicing front-end developers to equip themselves with learning materials and development tools. Secondarily, it can be used by managers, CTOs, instructors, and head hunters to gain insights into the practice of front-end development.

The content of the handbook favors web technologies (HTML, CSS, DOM, and JavaScript) and those solutions that are directly built on top of these open technologies. The materials referenced and discussed in the book are either best in class or the current offering to a problem.

The book should not be considered a comprehensive outline of all resources available to a front-end developer. The value of the book is tied up in a terse, focused, and timely curation of just enough categorical information so as not to overwhelm anyone on any one particular subject matter.

The intention is to release an update to the content yearly.

The handbook is divided into three parts.

Part I. The Front-End Practice

Part one broadly describes the practice of front-end engineering.

Part II: Learning Front-End Development

Part two identifies self-directed and direct resources for learning to become a front-end developer.

Part III: Front-End Development Tools

Part three briefly explains and identifies tools of the trade.

 

Download a .pdf, .epub, or .mobi file from:

취업과 직결되는 인기 클라우드 자격증 11가지 집중 탐구
Tech Trend

취업과 직결되는 인기 클라우드 자격증 11가지 집중 탐구

Click the link to read the article: 내용 보러가기

================

경험이 풍부한 IT 전문가들은 어디에서 어떻게 자신을 차별화 할 수 있을까요? 최고의 기회는 어디에서 찾을 수 있을까요? 다음은 급여를 걸만한 가치가 있는 플랫폼들입니다.

클라우드는 “사용한 만큼 지불하는” 컴퓨팅을 몽상에서 일상적인 현실로 바꾸어 놓았습니다. 가트너는 규모에 관계없이 조직이 어떻게 온프레미스 컴퓨팅에서 클라우드 기반 컴퓨팅과 서비스로 전환하고 있는지, 그리고 기존 데이터센터와 전환 간의 균형을 어떻게 잡아가고 있는지를 설명하기 위해 “클라우드 전환(Cloud Shift)”이라는 용어를 사용하고 있습니다.

도대체 클라우드는 얼마나 큰 것일까요? 지난해, 가트너는 소위 IT에서의 클라우드 전환이 1조 달러 이상의 관련 지출에 영향을 미칠 것으로 추산했습니다. 이렇게 많은 금액의 성패가 달려있는 만큼, IT 전문가들에게는 수많은 기회가 있을 것입니다. 실제로 가까운 장래에 자격을 갖춘, 클라우드에 정통한 ITT 전문가에 대한 수요가 공급을 초과할 것으로 보입니다.

링크드인의 소피 시크 대변인에 따르면 클라우드와 분산 컴퓨팅이 링크드인의 2016 최고의 10가지 기술 목록에서 1등을 차지했다고 합니다. 시크는 “고용주는 경쟁력을 유지하기 위해 클라우드와 분산 컴퓨팅, 통계분석, 그리고 데이터 마이닝 기술을 가진 직원을 필요로 합니다”라고 시크는 말했습니다. 또, 클라우드와 분산 컴퓨팅이 지난 2년간 1위 자리를 유지하고 있으며 거의 모든 목록 에서 최고의 기술로 꼽히고 있다고 강조했습니다. 프랑스, 독일, 인도, 아일랜드, 싱가포르, 미국 그리고 스페인을 포함한 수치입니다. 통계분석과 데이터 마이닝은 지난해 2위를 기록했으며 2014년에는 1위였습니다.

어떤 IT 기술이 클라우드 일자리를 만들어낼지 알아봅시다.

일자리, 일자리, 그리고 또 일자리
필자는 구직 사이트를 확인해 어디에 일자리가 있는지 파악하는 것으로 조사를 시작했습니다. 4곳의 사이트에 집중했는데, 심플리하이어드(SymplyHired), 인디드(Indeed), 링크드인 잡스(LinkedIn Jobs), 그리고 테크커리어스(TechCareers)가 그 대상입니다. 70여 가지 이상의 클라우드 관련 IT 자격증 목록을 가지고 시작했습니다. 각각의 자격증에 대해서, 샘플로 추출한 3일 간의 일자리 개수를 집계했습니다. 4곳 모두의 사이트에 대한 합계를 계산하고 현직자 구직 게시판에서 어느 자격증이 가장 많이 언급되었는지를 알기 위해 합계 치의 평균을 계산했습니다.

이 조사 결과는 표1과 같으며, 최상위 11개의 클라우드 관련 IT 자격증을 열거하고 있습니다. 항목들 중 하나가 CompTIA의 기본 스킬 자격증이므로 11가지를 실었다. 11가지 최고 인증서를 나열해 CompTIA 자격증의 위상(7위)을 알 수 있었고, 소득 능력을 직접적으로 향상할 수 있는 10가지 자격증도 나타났습니다. 순수하게 기초가 되는 자격증으로서, CompTIA 클라우드 에센셜(Cloud Essentials)이 커트라인을 통과할 것으로 생각하지는 않습니다.

표1

표1

1. 아키튜라 클라우드 스쿨(Arcitura Cloud School), CCP(Certified Cloud Professional)
클라우드 컴퓨팅 자격증의 리더격인 아키튜라 클라우드 스쿨은 CCP 순위 평가를 포함해서 몇 가지 자격증을 발급하고 있습니다. CCP는 가상화, 클라우드 특성, 관리, SaaS(Software-as-a-Service), PaaS(Platform-as-a-Service), IaaS(Infrastructure-as-a-Service), 클라우드 배포 모델(퍼블릭, 프라이빗, 하이브리드, 그리고 커뮤니티)을 비롯한 여러 분야에서의 기본 기술을 검증합니다. 지원자들은 이 자격증을 따기 위해 2개의 CCP 시험을 통과해야 합니다.

2 아키튜라 클라우드 스쿨, 공인 클라우드 아키텍트 (CCA)
CCA 자격증은 고위 IT 전문가들을 대상으로 설계되었습니다. 지원자들은 클라우드 기반 솔루션과 플랫폼의 설계, 지원, 그리고 관리와 관련된 전문가 수준의 지식과 기술이 필요합니다. 자격증을 취득하려면 5개의 시험을 통과해야 합니다. 시험 주제에는 (고급 클라우드 아키텍처를 포함해서) 클라우드 컴퓨팅 기초, 클라우드 기술 개념, 그리고 클라우드 아키텍처가 포함되어 있습니다. 클라우드 아키텍처 랩(Lab)의 성공적인 이수 내용도 필요합니다.

3. AWS-CSA-전문가
AWS(Amazon Web Service) CSA-전문가 자격증은 AWS를 사용하는 클라이언트를 지원하는 클라우드 전문가들에게 유용합니다. 설계, 배포, 베스트 프랙티스 구현을 포함해서 AWS 클라이언트 지원을 위해 필요한 기술과 전문성을 검증합니다. 추가로 하이브리드 아키텍처, 보안, 스토리지, 클라우드 이전, 비즈니스 연속성, 그리고 확장성 같은 개념에 대한 철저한 이해가 요구됩니다. 이 자격증을 취득하기 위해서, 지원자는 우선 AWS_CSA-어소시에이트 자격증을 따고 그 다음에 AWS CSA-전문가 시험을 통과해야 합니다.

4. 오라클, OCA-자바 클라우드 서비스 공인 어소시에이트 (Oracle Java Cloud Service Certified Associate (OCA-JAVA Cloud Service)
가장 인기 있는 오라클 클라우드 자격증 중 한 가지가 OCA-자바 클라우드 서비스입니다. 대부분의 오라클 자격증과 마찬가지로, 이 자격증을 얻기 위해서는 시험 한 가지를 통과해야 합니다. 이 자격증은 6개의 핵심 영역에 대한 지원자의 기술을 검증합니다. JCA(Java Caching System), 개발과 배포, 사용자와 인스턴스 관리, 공존화 확장(Co-existence & Extensions), 감시와 문제해결, 그리고 보안. 다른 모든 오라클 자격증처럼 교육이 있기는 하지만 필수는 아닙니다.

5. 시스코, CCNA(Cisco Certified Network Associate) 클라우드
CCNA-클라우드 자격증은 시스코 클라우드 제품을 지원하는 IT 전문가들에게는 필수적입니다. CCNA-클라우드는 클라우드 제공(Provisioning), 지원, 네트워킹, 그리고 시스템 총괄 관리와 관리 같은 기술을 검증합니다. 이 자격증 취득을 위해서는 2개의 시험이 필요합니다.

6. 아키튜라 클라우드 스쿨, 공인 클라우드 기술 전문가(CCTP)
CCTP 자격증을 따기 위해, 지원자는 여러 가지 클라우드 컴퓨팅 메커니즘과 보안에 대한 위험요소, 장점과 단점뿐 아니라 클라우드 용어와 컴퓨팅 개념들에 대한 철저한 이해가 필요합니다. 지원자는 IaaS, SaaS, 그리고 PaaS 모델을 사용하는 일반적인 클라우드 플랫폼들을 구현하고 배포하기 위한 능력도 입증해야만 합니다. 인증 과정에는 각기 클라우드 컴퓨팅 기초, 클라우드 기술 개념, 그리고 클라우드 기술 랩을 다루는 3가지 시험이 포함됩니다.

7. CompTIA 클라우드 에센셜
CompTIA 클라우드 에센셜 자격증은 비즈니스 전문가, 관리자, 그리고 비즈니스 목적으로 클라우드 컴퓨팅을 이해할 필요가 있는 여타 의사결정자 같은 비 기술직 직원들을 대상으로 하는 초급 수준의 자격증입니다. 지원자들은 위험요소, 비상사태 대비. 보안 위협요소와 위협 대응, 그리고 실제 환경에서 기술 정보를 적용하는 능력 등 클라우드 원리에 대한 이해도를 요구받습니다. 시험은 한 종류입니다.

8. 오픈스택 재단, 공인오픈스택 관리자(COA)
COA는 오픈스택 재단이 발급하는 최초의 그리고 유일한 자격증이라는 특별함이 있습니다. 중급수준의 자격증인 COA는 매일 오픈스택 클라우드 환경을 관리하고 운영해야만 하는 전문가들을 대상으로 합니다. 지원자들은 오픈스택, ID 관리, 오픈스택 대시보드(Dashboard), 컴퓨팅, 오브젝트 스토리지와 블록 스토리지, 네트워킹, 히트(Heat: 오픈스택 오케스트레이션 프로그램의 주 프로젝트로 오케스트레이션 엔진을 구현)와 오케스트레이션, 문제해결, 그리고 이미지 관리에 대한 기초 지식을 갖춰야 합니다.

9. 델 EMC 클라우드 아키텍트(EMCCA)
EMCCA 자격증에는 2가지 등급이 있습니다. 스페셜리스트(Specialist: 숙련가)와 엑스퍼트(Expert: 전문가). EMCCA 스페셜리스트 자격증은 클라우드 인프라, 계획, 그리고 설계에 초점이 맞춰져 있습니다. 엑스퍼트 자격증(EMCCAe)은 클라우드 서비스를 대상으로 하고 있습니다. 두 가지 자격증 모두 선수 조건으로 델 EMCISA(EMC Information Storage Associate) 자격증이나 델 EMCCIS(EMC Cloud Infrastructure and Services Associates) 자격증 중 한 가지를 요구합니다. EMCCAe 지원자는 EMCCAe 시험을 치르기 전에 반드시 EMCCA를 취득해야만 합니다.

10. 레드햇, 레드햇 인증 아키텍트(RHCA, RED HAT CERTIFIED ARCHITECT) 클라우드
RHCA는 레드햇의 최고 권위 있는 자격증입니다. RHCA를 취득하기 위해서, 지원자는 우선 RHCE(Red Hat Certified Engineer: 레드햇 공인 엔지니어) 직함이나 RHCJD (Red Hat Certified JBoss Developer: 레드햇 공인 J보스 개발자) 자격증 중 한가지를 취득해야만 합니다. 그 다음에는 추가로 최소 5가지의 클라우드 기반 자격증을 따야 합니다. RHCA-클라우드 자격증 소지자는 클라우드 인프라(프라이빗, 가상, 그리고 하이브리드)를 관리하기 위해 클라우드폼(CloudForms)을 사용하거나, 스토리지 솔루션을 만들어내기 위해 하이브리드 또는 온프레미스 클라우드를 사용하고, 오픈시프트 엔터프라이즈(OpenShift Enterprise)를 사용해서 클라우드 애플리케이션을 관리(생성, 구성, 그리고 관리)하기도 하고, 여러 시스템을 관리하기 위해 새틀라이트 서버(Satellite Server)를 사용하는 등 고급 작업을 수행할 수 있습니다. 레드햇은 오픈스택에 많은 투자를 하고 있으며 오픈스택의 COA 자격증도 지지하고 있음에 주목하십시오.

11. (ISC)2, 공인 클라우드 보안 전문가(CCSP)
(ISC)2가 발급하는 CCSP는 클라우드 정보 보안분야에서 맹활약하고 있는 전문가를 대상으로 하는 고급 수준의 자격증입니다. CCSP는 정보 보안 설계, 일상적인 운영, 보안 위험요소 규명과 완화, 감사, 거버넌스(Governance) 컴플라이언스(Compliance), 그리고 보안 아키텍처를 포함하는 핵심 보안 영역에 대한 지원자의 기술과 지식을 검증합니다. 지원자는 시험을 치르기 전에 최소 5년의 실무 경험을 가지고 있어야만 합니다.

표에 있는 언급 횟수에서 볼 수 있듯이, 이런 자격증 중 몇 가지에 대한 수요는 높은 편입니다. 직무 내용 설명서에 자격증이 필수라고 쓰여있지 않을 수도 있지만, 언급된 경우라면 구직에 성공하는 데 도움이 될 가능성이 높습니다.

그렇다면, 이런 자격증을 취득하기 위해 필요한 지식은 어떻게 얻을 수 있을까요? 이 질문은 필자를 몇 가지 인기 있는 동시에 무료인 무크(MOOC: Massively Open Online Courses – 온라인 공개강좌)를 포함해서, 자격증과 다른 클라우드 관련 교육을 위한 기회와 창구로 이끌었습니다.

HPE(Hewlett Packard Enterprise) 자격증
HPE는 현재 2개의 진로 단계에 거쳐서 5가지의 클라우드 중점 자격증을 발급하고 있습니.: 데이터센터와 클라우드 그리고 IT 관리. 5가지 모두 전문가 (ATP: Accredited Technical Professional) 또는 엑스퍼트 (ASE: Accredited Solutions Expert) 수준의 기술을 보유하고 있는 경험 많은 실무자를 대상으로 설계되어 있습니다. 필수는 아니지만, 대부분의 HPE 자격증에 대해서는 교육을 강력하게 권장합니다. 지원자들은 등록하기 위해서 반드시 HPE 러너(Learner) ID를 확보해야만 합니다.

 HPE APT Data Center and Cloud V2 : 전문가 수준의 자격증인 HPE ATP Data Center and Cloud(데이터센터와 클라우드) 자격증은 클라우드 솔루션을 수용하기 위해 자신들의 시스템을 업그레이드할 필요가 있는 데이터센터 전문가들을 대상으로 합니다. 지원 자격을 얻기 위해서는 최소 3년의 경험이 있어야 하며 데이터센터 솔루션을 관리, 계획, 그리고 설계할 수 있어야 합니다. HPE 헬리온(Helion)이나 오픈스택 같은 서드파티 클라우드 기술에 대한 기초 수준의 기술이 플러스가 됩니다. 자격증을 획득하기 위해서는 “Navigating the Journey to the Cloud(HPE0-D33)”이라는 하나의 시험을 통과해야 합니다. 이 자격증은 좀 더 고급인 HPE ASE 데이터센터와 클라우드 아키텍트 자격증에 대한 선수 조건입니다.

 HPE ASE Data Center and Cloud Architect V3 : Data Center and Cloud Architect(데이터센터와 클라우드 아키텍트) 자격증은 기술과 비즈니스 요구사항을 평가할 수 있고, 제안돤 데이터센터 솔루션을 설계하고 정의할 수 있으며, 클라우드 솔루션으로의 전환을 구현할 수 있는 세일즈 엔지니어, 프리세일즈(Pre-sales) 기술 아키텍트, 그리고 HPE 클라우드시스템(CloudSystem)과 HPE 헬리온을 사용해서 작업하는 컨설턴트를 대상으로 하고 있습니다. 엑스퍼트 수준의 자격증이기 때문에, 지원자들은 우선 HPE ATP Data Center and Cloud V2나 V1 자격을 취득해야 하고, “Designing HPE Data Center and Cloud Solutions (HPE0-D34) 시험도 통과해야만 합니다.

 HP ATP Cloud Service Automation V4 : Cloud Service Automation(클라우드 서비스 자동화)자격증은 HPE CSA(Cloud Service Automation)를 사용해서 작업하는 전문가들에 초점을 맞추고 있습니다. 지원자들은 CSA 개념, 시작과 배포 프로세스, 시작 구성요소, 그리고 CSA를 확장하고 구성하는 방법에 대해서 설명할 수 있어야 할 뿐 아니라, CSA에 대한 배포하고 사용 할 수 있어야 합니다. 또한, 자격증 준비생들은 마켓플레이스 포탈(Marketplace Portal)과 관리 콘솔(Management Console)을 사용하는 방법을 알아야 하고, 감독하에 그것들을 구현할 수 있어야 합니다. 자격증을 취득하기 위해서, 지원자들은 HPE Cloud Service Automation 4.x Software (HP0-M100) 시험을 통과해야 합니다. HPE ATP CSA 자격증은 HPE ASE Software for Cloud Management 자격증에 대한 선수 조건입니다.

 HP ASE Software for Cloud Management V2 : 이 자격증은 전문가 수준의 클라우드 관리와 자동화 (데이터센터와 비즈니스 서비스) 기술을 보유한 HPE 직원, 고객 그리고 기술 협력업체를 대상으로 합니다. 지원자들은 대개 최소 1년의 경험과 HPE ATP CSA 자격증을 소지하고 있어야 합니다. 선수 조건 기술 이외에, 지원자들은 가상화를 관리할 수 있어야 하고, 서버를 탐색하기 위해 전반적인 파일 시스템과 셸 (Shell)이 어떻게 사용되는 지를 설명할 수 있어야 하며, SA에서 스크립트를 실행하고 관리할 수 있고, 구성 관리 (패키지, 패치, 그리고 애플리케이션) 업무를 알아볼 수 있어야 합니다. 지원자들은 자격증을 취득하기 위해 Advanced Operations Orchestration 10.x Software 시험 (HP0-M2015)이나 Advanced Server Automation 10.x Software 시험 (HP0-M209) 중 한가지를 통과해야 합니다. 이 자격증은 HPE Master ASE Software for Cloud Management V2 자격증의 선수 조건입니다.

 HPE Master ASE Software for Cloud Management V2 : 달인 급의 이 자격증은 비즈니스 서비스와 클라우드 관리 소프트웨어 분야의 엑스퍼트인 기술 전문가, 구성 관리 엔지니어, 그리고 CMS 관리자를 대상으로 합니다. 마스터라는 칭호를 얻기 위해서, 지원자들은 HPE ASE Software for Cloud Management V2 자격증을 보유하고Advanced Operations Orchestration 10.x Software 시험(HP0-M205)과 Advanced Server Automation 10.x Software exam(HP0-M209)라는 2가지 시험을 통과해야만 합니다. 이 모든 선수 조건 외에, 지원자들은 PoC(Proofs of Concepts: 개념 증명)을 시연할 수 있어야 하고, HPE SA와 운영 업무 오케스트레이션(Operations Orchestration)을 구현할 수 있어야 하며, 설치 프로세스와 운영업무 오케스트레이션 아키텍처를 논할 수 있고, 감독하에 CMS를 구성, 관리, 그리고 구현할 수 있어야 합니다.

전문 자격증 외에, HPE는 HPE 직원과 협력업체들만 취득할 수 있는 일련의 파트너 국한 자격증도 발급하고 있습니다. HPE는 이 범주에서 HPE Technical Certified II Software for Cloud Automation in SME (2014) 자격증이라는 한 가지 자격증을 발급하고 있습니다. 이 자격증을 위해서는 Implementing Cloud Services Automation Hands-On Assessment (HP0-M206P)라는 하나의 실기 시험을 통과해야 합니다. 전문가들은 구현에 대한 설계의 영향을 이해해야 하며(SAVA, OO, 그리고 SA를 포함), 통합 구현 플로우에 대한 계획을 수립하고 구현할 수 있어야 하며, 클라우드 서비스 라이프사이클을 관리하고 자동화 할 수 있어야 합니다.

HPE 교육 서비스(Education Services)는 오픈스택과 HPE 헬리온에 대한 종합적인 교육 과정도 제공하고 있습니다.

이런 자격증들은 취업 수요와 관련하여 어떨까요? 다음 표는 HPE 자격증이 어느 정도의 차이를 보일 수 있는지를 보여줍니다.

표2 : 구인란 검색 결과

표2 : 구인란 검색 결과

자격증 교육
다른 클라우드 자격증 발급기관들도 독학, 전통적인 강사 주도의 학습, 가상 학습, 그리고 중간에 있는 모든 것을 포함해서 종합적인 교육을 제공하고 있습니다. 많은 발급기관들이 하이브리드 학습 솔루션 그리고 멘토, 커뮤니티, 블로그, 문서, 백서를 비롯한 다른 학습 이벤트에 대한 액세스도 제공하고 있습니다. 때로, 여러 가지 자격증 전반에 대한 교육용 프로그램에도 액세스할 수 있어서, 교육에 대한 투자를 극대화하기 쉽게 해줍니다.

클라우드 컴퓨팅에 대한 교육은 찾기 쉽습니다. 간단한 인터넷 검색만으로도 참석할 만한 가치가 있는 데브옵스와 클라우드 관련 컨퍼런스 뿐 아니라 고려할 만한 가치가 있는 그야말로 수 백 가지의 기회를 보여줍니다. 선택할 수 있는 옵션이 너무 많아서, 압도되기 쉽습니다.

자격증 준비에 도움이 되도록, 필자가 여러 가지 선택사항들 중 일부에서 몇 가지 정보를 모아놓았습니다. 아래 표는 자격증 발급기관과 소수의 선정된 서드파티 교육기관이 제공하는 학습 기회에 대한 정보를 정리한 것입니다. 주: ILO는 강사 주도의 온라인 교육의 약자이며, ILT는 실제 강의실에서 진행되는 강사 주도의 교육 약자입니다.

표3 : 자격증 발급 기관별 클라우드 교육 옵션

표3 : 자격증 발급 기관별 클라우드 교육 옵션

주요 자격증 발급기관들이 제공하는 교육만 바라볼 필요는 없습니다. 수 많은 서드파티 공급업체들이 클라우드 관련 이슈나 공급업체 자신들의 플랫폼 관련 자격증에 대한 일반적인 교육과 함께 주요 자격증들에 대한 교육을 제공하고 있습니다. 예를 들면, 구글은 자체 구글 고유의 클라우드 아키텍트 자격증뿐 아니라 기초사항과 시스템 운영을 포함해서 자사의 플랫폼에 관련된 몇 가지 교육과정을 가지고 있습니다.

표 4 : 서드파티 클라우드 교육 제공업체

표 4 : 서드파티 클라우드 교육 제공업체

대학의 자격증이나 학위 프로그램
클라우드 교육이 자격증 발급기관이나 서드파티 교육 기관으로 국한된 것은 아닙니다. 많은 대학과 대학교들이 학부 졸업생, 대학원 졸업생, 그리고 현역으로 활동하고 있는 IT 전문가를 대상으로 설계된 자격증이나 학위 프로그램을 가지고 클라우드 인기에 편승하고 있습니다. 이런 옵션 중 몇 가지는 다음과 같습니다(특정 순서나 우선권은 없음).

 풀 세일 대학교 : 클라우드 기술 이학사; 온라인 그리고 캠퍼스 강의 과정

 ECPI 대학교 : 사이버 보안과 네트워크 보안, 클라우드 컴퓨팅 과정 전공의 컴퓨터와 정보 과학 이학사; 온라인과 캠퍼스 강의 과정; STEP 직종 승인 대학 (STEP Jobs Approved College); 2016년 사이버보안 분야에서 가장 합리적인 온라인 학위

 타이드워터 커뮤니티 칼리지 : 클라우드 컴퓨팅 경력 연구 자격증; CompTIA 클라우드 에센셜, CompTIA 클라우드+, VM웨어 공인 전문가, 그리고 EMC 전문 클라우드 인프라와 서비스 인증(Proven Professional Cloud Infrastructure and Services), 백업 복구 시스템과 아키텍처, 그리고 정보 저장과 관리 자격증 대비 지원자 교육과정

 아메리칸 밀리터리 대학교 : 클라우드 컴퓨팅 학부 인증서(1년, 18학점)

 램튼 대학 : 빅 데이터를 위한 클라우드 컴퓨팅, 온타리오 대학 대학원 인증서, 전자, 컴퓨터 공학, 정보 기술, 또는 엔지니어닐/기술 분야의 대학 졸업장이나 학위 필수

추가로, 어바나-샴페인 소재 일리노이즈 대학교 그리고 연세 대학교 같은 교육기관에서 제공하는 여러 가지 클라우드 컴퓨팅 과정에 대해 코세라(Coursera)에서 확인 해보는 것도 좋습니다. 아직도 찾고자 하는 것을 찾지 못했다면 도큐레이티드(Docurated)의 전세계 클라우드 컴퓨팅 학위 상위 50개 목록이라는 훌륭한 자원을 확인하십시오. 모든 클라우드 관련 사항들이 그렇듯, 여기에도 놀랄 정도로 많은 내용이 있습니다.

무크(MOOC) 강좌, 공짜라고! 정말?
무크 교육이 엄청난 인기를 얻고 있는 데에는 그럴 만한 이유가 있습니다. 무크는 학습자들에게 편안한 자신의 집이나, 자신들이 선택한 사무실 혹은 학습 환경에서 최고의 대학교와 교육기관들이 제공하는 과정 중 일부를 공부할 수 있는 기회를 제공하고 있습니다. 모든 무크는 학습자들에게 무료로 제공되어, 재정적인 제약을 없애주고, 누구나가 양질의 교육에 자유롭게 액세스할 수 있게 해줍니다. 일부 기관은 수료증 같은 “부가 가치” 서비스에 대해 수수료를 받기도 합니다. 서류 작업을 할 때 세심하게 살펴보십시오.

무크 목록은 많지만, 필자는 특히 MOOCSE(무크 검색 엔진)를 좋아합니다. MOOCSE는 약 4만 3,000개의 무크 학습 기회를 제공하는 링크가 있는 탄탄한 사이트입니다. 자연스럽게, 여기에는 단지 호기심을 가지고 있는 사람들을 위한 입문 강좌부터 고급, 그리고 전문 강좌에 이르기까지, 많은 클라우드 주제가 포함되어 있습니다. 바로 수강할 수 있는 강좌는 모바일과 클라우드 컴퓨팅, 클라우드 인프라 기술, 클라우드 TV, 구글 클라우드, 오픈스택을 비롯한 다수의 주제를 다루고 있습니다.

한 가지 유쾌한 놀라움은 무크 제공 업체의 다양성입니다. 앨리슨과 에드X는 수많은 클라우드 컴퓨팅 무크 강좌 제공으로 두드러지게 눈에 띕니다. 다수의 클라우드 업계 리더들이 학습자들이 무한한 클라우드 교육 비디오 스트림을 찾을 수 있는 정평 있는 유튜브 채널로 소셜 미디어의 저력을 활용하는 사례입니다. 클라우드 미디어를 가지고 있는 몇 가지 흥미 있는 채널로는 IBM InterConnect 2017, 에듀레카(Edureka), 프로핏브릭스(ProfitBricks) (클라우드 컴퓨팅 TV), 그리고 오라클 클라우드(Oracle Cloud)가 있습니다. 물론, (이름이 의미하듯) 모든 것을 클라우드에 바치고 있는 클럽 클라우드 컴퓨팅닷컴(Club Cloud Computing.com) 채널도 놓치고 싶지 않을 것입니다. 비디오 학습에 전념할 수 있는 시간이 제한적인 IT 전문가들은 아이튠즈를 확인해보는 것도 좋습니다. 애플은 잉그램 마이크로의 “클라우드 컴퓨팅: 클라우드의 힘” 같은 여러 가지 클라우드 컴퓨팅 관련 팟캐스트를 제공하고 있습니다.

마이크로소프트, 시스코, 그리고 델 EMC도 무크 게임에 참여하고 있습니다. 이들 각각은 클라우드 컴퓨팅이나 관련 주제(빅 데이터, 데이터 과학, 데이터 분석 등)에 대한 최소 한 두 가지의 무크를 제공하고 있습니다. 마이크로소프트 러닝의 교육 서비스 담당 이사인 크리스 로이는 마이크로소프트는 애저 무크에 대한 종합적인 교육과정을 이미 보유하고 있으며 더 많은 것들이 진행 중이라고 말했습니다. HPE는 애플리케이션 보안과 빅 데이터에 대한 무크 파일럿 프로그램을 얼마 전에 시작했는데, 다음 회에 참여하려면 등록이 필요합니다.

다양한 무크 기회 속에서 사용자의 관심 분야에 부합하는 과정을 꼭 찾을 수 있을 것입니다.

그 다음은 어디로? 당연하게도 클라우드!
이 자료를 이용해서 작업할 때는, 시간과 에너지를 똑똑하고 조심스럽게 사용하십시오. 선택할 옵션, 학습, 공부, 그리고 실습할 수 있는 채널이 현기증 날 정도로 많기 때문에, 진짜로 중요한 것을 놓치기 쉽습니다.

자격증과 교육 프로그램을 이 기사에서 확인하고, 그 다음에 어떤 것이 흥미를 주는 지를 알아보기 바랍니다. 투자할 가치가 있는 후보에 대한 짧은 목록을 작성하고 나면, 그 다음부터 실제 일이 시작됩니다. 개인적 인맥을 통해서 여기저기를 둘러보십시오. 자신이 하려고 하는 일을 이미 한 수료생이나 실문 전문가들의 반응과 평가점수를 얻으려면 온라인을 둘러보십시오. 그렇게 한 다음에야 최종 선택을 할 준비를 마친 것이라 할 수 있습니다. 자, 소매를 걷어 붙이고 작업에 돌입하는 모든 시간을 즐기기 바랍니다!

원문보기: 
http://www.itworld.co.kr/news/105443#csidxc795a178737b581a4549fc0dfe4a313 

IT의 위기! 조직 내 지위와 역할이 바뀌고 있다
Tech News

IT의 위기! 조직 내 지위와 역할이 바뀌고 있다

IT의 위기! 조직 내 지위와 역할이 바뀌고 있다

너무 많은 약속들 지켜지지 않아…IT를 ‘지출’로 인식하기 시작
혁신적인 기술들 도입하려는 시도, IT가 지원할 수 있어야

Click the link to read the article: 내용 보러가기

[보안뉴스 문가용 기자] IT 환경의 급격한 변화로 인해 IT 담당자들 역시 숨이 가쁘다. 이 변화의 물결 속에서 자신의 가치를 입증한다는 것이 전공자들로서도 힘이 드는 것이다. 그런데 재미있는 건 이런 변화의 속도를 만들어낸 것도 일정 부분은 그들 자신이라는 것이다. 늘 변화의 중심에 있던 IT가, 스스로 그 속도에 휘말려 들어가 자신의 변혁까지도 꾀해야 하는 이유는 다음과 같다.

너무 약속‘만’ 많았다
이것만 등장하면 모든 불편이 해소될 거라는 약속이 얼마나 지켜졌나? 이제 아무도 그런 말을 믿지 않고, 더 이상 기다려주지도 못하는 때가 되었다. IT 기다리다가 경쟁자에게 뒤처지기 일쑤이기도 하다. 오히려 이런 저런 잔고장이나 오류 때문에 IT 부서를 찾는 일이 현대 환경에서는 더 많아졌다.

카이저 퍼머넌트(Kaiser Permanente)의 수석 IT 솔루션 컨설턴트인 데이비드 칼드웰(David Caldwell)은 “여태까지 ‘악속’만으로 지원을 받아온 IT라는 걸 모두가 어렴풋이 눈치 채기 시작했다”며 “약속한 걸 해내기는커녕, 제대로 기능을 발휘하지도, 시간을 엄수하지도 않아왔다는 건 IT에 대한 전반적인 신뢰를 갉아먹는 꼴이 됐다”고 말한다. IT에게 필요한 건 미래에 대한 희망이 아니라 안정적인 서비스 제공이다.

기대감이 바뀌기 시작했다
IT에 대한 경영자들의 시선이 위에서 말한 것처럼 바뀌기 시작한다는 건 다시 말해 IT가 ‘비용’ 혹은 ‘지출’의 개념으로 비쳐지기 시작했다는 것이다. ‘약속’들이 통할 때 IT는 ‘투자’였다. 물론 IT 없이는 사업을 하루도 못할 회사들이 많은 게 사실이고, 대기업들조차 얼마 버터지 못할 것이라는 게 분명하지만, 그것만으로는 ‘지출’이 ‘투자’가 되지는 못한다.

이는 더 장기적으로 보면, C 레벨 정보 책임자와 기술 책임자가 더 이상 동급(C 레벨)으로 남아있지 않을 가능성도 시사한다. 즉 앞으로 CIO나 CTO는 경영진 회의에 참석이 어려워질 수도 있다. 예전처럼, 경영진 회의 결과에 나온 것을 IT 부서는 그대로 수행만하면 되는, 말 그대로 기계적인 부서로 돌아갈 가능성이 없지 않다. 그러면 기술적인 어려움에 대해 임원진들에게 설명해줄 사람이 없어지고, IT는 비현실적인 임무 앞에 또 다시 숨을 헐떡이고 있을 것이다.

“보안이 중요하고, 그래서 CISO가 임원진 회의에 동석하느냐 마느냐로 따지고 있는 때에, 아예 IT 자체에 대한 회의론이 슬슬 수면 밖으로 나오고 있습니다. 정보 전문가들이 있어봤자 사업 전략 회의 시간에 유의미한 도움이 되지 않는다고 판단하고 있는 것이죠.” 칼드웰의 설명이다. “물론 이러한 변화가 급하게 이뤄질 것 같지는 않습니다만.”

IT, 스스로의 죽음을 선고했다
클라우드나 SaaS, 은둔의 IT가 본격적으로 등장하기 전 IT에는 특수한 역할이 있었고, 그 때문에 회사 내에서 가치를 가졌었다. 하드웨어와 소프트웨어, 네트워크의 수호자도 역시 IT 부서였다.

“그런데 역설적으로 IT 계통에서 불어온 변화의 바람이 전통의 IT들을 위협하기 시작했습니다. 왕자가 선왕의 왕좌를 위협하는 꼴이랄까요.” 클라우드 기업인 소니안(Sonian)의 CTO 그레그 아르넷(Greg Arnette)의 설명이다. “현재 IT는 구조적인 변화를 겪고 있어요. 신기술의 등장으로 IT 구성원이 그리 많지 않아도 되는 때입니다.”

클라우드와 SaaS가 급격히 대세로 올라선 것은 2008년과 2009년부터 시작된 세계 경제 불황 때문이다. 전통의 IT 구조를 유지하는 것보다 클라우드와 SaaS 업체와 계약하는 것이 훨씬 가격 면에서 유리했기 때문이다. 이때부터 IT를 투자가 아닌 지출로 보는 시각이 형성되었을 수도 있다.

“당시는 악재가 겹치던 때였습니다. IT는 희망을 약속하기만 하고 이뤄놓은 것은 없지, 은둔의 IT라고 해서 운영 상 필요한 애플리케이션을 몰래 설치하고 사용하는 것도 못하게 하지, 경기는 안 좋아져 마냥 기다릴 수만은 없지, 그래서 결국 세일즈포스나 젠데스크 같은 업체와 손을 잡기 시작했습니다. 그런 클라우드 서비스들이 악재와 악재를 타고 회사 시스템의 뒷단에 들어가게 된 것입니다.”

그래서 IT는 이제 새로운 환경의 뒷바라지를 해야 하는 상황에 놓이게 되었다. 클라우드 연결이 잘 되지 않을 때, 보안 문제가 발생했을 때, 호환성 문제가 발생했을 때, IT 담당자들이 나서야만 했다. 그러한 새로운 기술이나 환경에 대해 잘 알지도 못한 채로 말이다.

CIO와 CTO의 역할이 바뀌고 있다
아마 어지간한 규모를 갖춘 기업들 대부분에는 CIO와 CTO가 있을 것이다. 그러나 얼마 전부터 이들은 최고 데이터 책임자(Chief Data Officer)나 최고 분석 책임자(Chief Analytics Officer), 최고 혁신 책임자(Chief Innovation Officer) 등으로 타이틀이 바뀌고 있다. 당연히 역할에도 변화가 있다.

“더 이상 기업의 임원진들이 정보 자체에 크게 집중하거나 벌벌 떠는 모습이 아닙니다. 대신 혁신 기술들을 도입할 때 IT가 뒷받침해주기를 바라고 있죠. 그래서 데이터 분석이나 혁신이라는 단어가 타이틀에 붙는 겁니다. 아마, 이러한 경영진의 기대감이 IT 업체의 정체성이 되지 않을까 합니다.”

최근 기업 내 소프트웨어와 하드웨어는 SaaS와 IaaS로 각각 대체되고 있는 분위기다. 물론 아직은 중간 단계라 ‘하이브리드’ 형태가 많은 것이 사실이나, 이 시기가 지나가면 대부분의 일들이 가상 공간에서 처리될 것으로 보인다. 이 시기가 지날 것이라고 예측하는 이유는 경제적인 매력 때문이다. ‘허풍쟁이’로만 보이고 있는 IT가 이러한 혁신의 바람을 타고 새로운 역할을 차지할 수 있을까?

글 : 리사 모건(Lisa Morgan)
[국제부 문가용 기자(globoan@boannews.com)]

Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>

IT 부서가 5년을 내다보고 준비해야 할 역량
Tech Trend

IT 부서가 5년을 내다보고 준비해야 할 역량

IT 부서가 5년을 내다보고 준비해야 할 역량

Sharon Florentine | CIO
IT의 역할이 지속해서 발전하고 새로운 기술이 잇달아 도입되는 상황에서 IT 전문가는 향후 5년에 대비해 어떤 계획을 세워야 할까? 핵심은 새로운 기술이나 기술적 경험을 배우는데 머무르지 않고 큰 그림에서 사고하는 것이다.
비즈니스 및 기술 컨설팅 기업 웨스트 몬로 파트너스(West Monroe Partners)의 기술 통합 활동 책임자 코리 채플린은 “향후 6개월, 1년, 5년 동안 어떤 기술이 주목받을지 알려주는 수정 구슬 따윈 없다. 하지만 일정한 경향성을 찾을 수는 있다. 단순히 하나의 제품, 기술, 언어에 특화된 인재보다는, 전체적인 솔루션이나 기술 영역에서 전문성을 가진 인력에 대한 수요가 점점 커지고 있다는 것이다”라고 말했다.

예를 들어, 단일 운영체제 접근방식보다는 여러 플랫폼, 장치, 운영 체제에서 개발할 수 있는 모바일 개발자나 여러 유형의 웹 애플리케이션을 디자인하고 구축할 수 있는 프런트 엔드(Front End) 개발자를 들 수 있다.

협업과 인간 관계
또한 미래의 IT 부서는 조직 내의 최종 사용자나 외부 고객 등과의 상호작용이 늘어날 것이다. 채플린은 “고객이나 최종 사용자와의 초기 회의에 더 많은 개발자가 참석해 그들과 상호작용하고 사용 사례와 요건뿐만 아니라 비즈니스와 전략 계획을 논의해야 할 것이다. 개발자는 할 일 목록을 받아 처리하는 대신 협업하는 것과 자신이 프로젝트와 계획에 참여하는 이유에 더 관심을 가져야 할 것”이라고 말했다.

미국 노동통계국 자료를 보면 이러한 변화 중 상당 부분은 밀레니엄 세대가 주도한다. 이들은 2015년 말 현재 이미 전체 직원 중 가장 많은 비중을 차지하고 있다. 밀레니엄 세대는 상관으로부터 명령을 받아 이에 따르는 것에 만족하지 않고 과업, 프로젝트, 비즈니스 계획 이면의 이유를 알고자 한다.

채플린은 “전통적인 IT 부서에서는 자신의 업무가 기업에 어떤 영향을 끼치는지 이해하지 않고도 IT의 범주 내에 ‘단순히’ 머무르는 것만으로도 괜찮았다. 하지만 이제는 IT가 이런 더욱 광범위한 전략 논의에 참여해야 하고 더 큰 목적을 이해해야 한다. 우리와 그들을 구분 짓는 관념에서 벗어나 비즈니스와 IT 리더십의 협력에 집중해야 한다”라고 말했다.

이런 변화로 IT 리더는 더 많은 시간과 인내심이 필요하게 됐다. 그러나 이를 통해 더 큰 생산성과 더 나은 제품을 실현할 수 있다. 채플린은 “지난 6~7년 동안 내 역할이 크게 바뀌었다. 이제 프로젝트 초기에 팀원에게 고객이 달성하고자 하는 목표를 설명하는 데 더 많은 시간을 할애한다. 목표를 제시함으로써 더 나은 결과를 얻을 수 있다는 사실을 깨달았기 때문이다. 이제 그들은 야근이나 주말 근무를 가리지 않고 자발적으로 문제를 해결한다. 그들은 기꺼운 마음으로 참여하기 때문에 더 좋은 기능을 구현하고 고객 만족도도 더 높아진다”고 말했다.

사용자 만족도
또한 미래의 IT 부서는 성공의 지표로써 사용자 만족도에 집중해야 한다. 따라서 혁신과 새로운 기술 통합의 균형을 유지하는 것뿐 아니라 기존 솔루션의 관리와 유지보수 업무도 담당해야 한다. 실제로 IT 및 HR 성과 관리 및 컨설팅 기업 그린 엘리펀트(Green Elephant)가 직급에 상관 없이 약 10만 명의 IT 전문가를 대상으로 시행한 설문조사 결과를 보면 사용자 IT 만족도가 IT의 비즈니스 가치에 영향을 끼칠 수 있으며 IT는 팀은 물론 팀의 이미지를 신뢰 받는 서비스 제공자로서 재정립해야 하는 것으로 나타났다.

그린 엘리펀트의 CEO 사이먼 채플로는 “IT는 마케팅을 벌이고 사용자를 고객으로 생각해야 한다. IT가 서비스의 80%만을 제공하고 있는가? 예의가 없는가? 비효율적인가? 모두 문제가 있는 것이다. 사용자에게 IT 서비스를 제공하는 것이기 때문에 ‘브랜드’가 중요하다. 사용자가 서비스의 가치를 느끼지 못한다면 회사 전체가 IT에 가치가 없다고 생각하게 될 것”이라고 말했다.

이런 상황을 개선하려면 IT가 측정과 책무성에 집중해야 한다. 사용자 IT 만족도를 측정하고 사용자가 현재 서비스를 평가할 수 있도록 허용해야 한다. 이 결과를 바탕으로 IT는 개선이 필요한 부분에 역량을 집중하고 그 과정에서 더 많은 것을 얻을 수 있다.

채플로는 “업무 지원센터 호출, 마감된 티켓과 이벤트 마감 시간 등에 기초한 생산성 통계만 측정한다면 투자는 받을 수 있겠지만 한계가 있을 것이다. 사용자 만족도와 행복도를 포함해 IT에 사용자 만족도에 대한 문제를 해결할 더 많은 시간과 공간을 할애한다면 전반적으로 서비스가 개선될 것”이라고 말했다.

미래의 IT 부서는 지금도 그렇듯 새로운 기술과 소프트웨어, 하드웨어 그리고 ‘가장 최신의’ 신기술에 집중해야 할 것이다. 그러나 이 모든 것의 기반이 되는 것은 따로 있다. 바로 지식의 폭, 인간 관계와 협업 그리고 사용자 만족도다. ciokr@idg.co.kr

원문보기:
http://www.ciokorea.com/news/28403#csidx01af0f4e258c96eb333aa669642287d 

2017 IT 트렌드- 전 세계 1200명 CIO가 뽑은 중요 IT 기술 세 가지
Tech Trend

2017 IT 트렌드- 전 세계 1200명 CIO가 뽑은 중요 IT 기술 세 가지

2017 IT 트렌드
전 세계 1200명 CIO가 뽑은 중요 IT 기술 세 가지

Click the link to read to the article: 기사 보러가기

딜로이트 컨설팅은 지난해 말 전 세계 CIO 1200명을 대상으로 2017년 IT 트렌드 전망을 묻는 설문조사를 했다. 이들은 올해 가장 주목해야 할 IT 기술로 보안, 애널리틱스, 클라우드를 꼽았다.

기술 1 | 보안

미국 뉴욕에 있는 리서치 기업 글로벌 스트레티지 그룹(Global Strategy Group)의 앤드루 호 부사장은 늘 보안이 중요하지만 특히 선거가 많은 해에는 그 중요성이 더 커질 수밖에 없다고 지적한다. 그는 이와 관련해 “우리는 미국 민주당 전국위원회(DNC)와 협력하기 때문에 항상 보안을 중요하게 다루지만 다중 요소 인증과 같은 도구를 사용해 보안을 더욱 강화할 계획”이라고 말했다.

호 부사장은 “보안의 핵심은 문화”라고 강조한다.” 새로운 기술 도입도 중요하지만, 보안의 70%는 문화적인 요소가 좌우한다. 이 때문에 해킹과 관련한 심리적 요소를 분석해 사람들의 행동을 바꾸거나, 비밀번호 설정과 변경의 중요성 등에 대한 인식을 바꾸는 것 등이 강력한 방화벽을 설치하는 것 이상으로 중요하다.

인력을 늘리는 것도 보안 문제 해결에 중요하다. 올해 신규 직원 채용 계획이 있는 기업의 30%는 인력 증원 이유가 보안 강화라고 답했으며 그중 26%는 보안, 규정 관련 신규 채용을 계획 중이라고 답했다.

기술 2 | 애널리틱스

기업들이 고객에게 더 가까이 다가가기 위해 노력하면서 고객 관련 데이터 분석도 중요해졌다. 기업마다 웹 트래픽과 제품 선호도, 구매 행동, 실제 환경의 제품 성능 등에 대한 데이터를 축적해서 잠재적인 ‘통찰력의 금맥’을 만들고 있다. 적절한 전략과 분석 도구를 사용해 데이터의 의미를 보다 충실하게 파악할 수 있다면 그 금맥은 비로소 엄청난 결실을 가져다 줄 것이다.

딜로이트 설문에 응한 CIO의 65%는 올해 빅데이터, 엔터프라이즈 분석, 비즈니스 인텔리전스 도구 등 데이터 분석에 대한 지출을 늘릴 계획이라고 답했다. 응답자들이 선정한 현재 추진 중인 가장 중요한 기술 프로젝트 순위에서 데이터 분석이 1위를 기록했다.

캐나다 앨버타주의 에드먼턴은 올해 시 정부 차원에서 데이터 분석 역량을 높이기로 했다. 브루스 랜킨 에드먼턴 데이터 책임자는 “부서 간 장벽을 허물어 정보 공유와 이용을 원활히 하고 이를 통해 더 나은 의사 결정을 하도록 돕는 것이 목표”라고 말했다.

기술 3 | 클라우드

기업들이 디지털 혁신을 위해 IT 인프라를 재정비함에 따라 클라우드 컴퓨팅 관련 수요는 꾸준히 늘어날 것이다. ‘서비스형 소프트웨어(SaaS·software-as-a-service)’ 선호가 두드러지는 것도 이와 관련이 있다. 설문조사 결과 CIO의 33%는 조직이 내년에 SaaS 투자를 늘릴 계획이라고 답했다. 아울러 29%는 클라우드 또는 SaaS 시스템이 향후 3~5년 동안 비즈니스에 가장 큰 영향을 미치는 파괴적 기술이 될 것으로 예상했다.

보스턴 지역에 20개의 매장을 거느린 식료품 체인점인 로슈 브라더스(Roche Bros.)는 최대한 많은 인프라와 애플리케이션을 SaaS 모델로 전환 중이다. 이 회사는 인사와 인증, 백업, 복구, 생산성 관련 애플리케이션까지 모두 클라우드로 전환한 덕분에 비용을 절감할 수 있었다. 로슈 브라더스의 IT 담당 부사장인 존 로더바크는 “사내 IT 직원은 4명인데, 서버를 관리하고 백업과 복구까지 처리하려면 버겁다”며 “초기 변화에 적응하는 데 다소 시간이 걸리더라도 전산처리를 클라우드화하면서 안정적으로 정보를 관리할 수 있게 됐다”고 말했다.

  • Copyright ⓒ 조선일보 & Chosun.com
사물인터넷(Internet of Things;IoT)이란 무엇인가?
Tech News

사물인터넷(Internet of Things;IoT)이란 무엇인가?

사물인터넷(Internet of Things;IoT)이란 무엇인가?

Click the link to read the article: 

http://blog.bizmerce.com/

=====

사물인터넷(Internet of Things;IoT)이란 무엇인가?

가트너에서 매년 발표하는 다음 해의 전략과제에 보면 최근 빠짐없이 등장하는 용어가 바로 사물인터넷이라는 용어입니다. 우리 회사가 클라우드 플랫폼을 기반으로 하는 제품을 만드는 회사로서 이 사물인터넷은 클라우드를 기반으로 하는 파생기술 또는 확장기술이기 때문에 반드시 기술력을 확보해야 하는 분야이기도 합니다. 이번 포스트에서는 그런 의미로 사물인터넷이란 무엇이며 그 실제 사례에는 어떤 것이 있는지 등의 간단한 개요를 알아보는 시간을 마련해 보았습니다. 여러분의 많은 관심 바라며, 사물인터넷을 이해하는데 조금이나마 도움이 되기를 바랍니다.

사물인터넷이란?

사물인터넷이란 무엇일까요? 어떻게 사물인터넷을 정의할 수 있을까요? 사물인터넷이란 말 그대로 사물이 인터넷에 연결되어 그 정보를 활용하여 사물 본연의 기능을 더 충실히 행하도록 하는 기술을 말합니다.

사물이란 그럼 무엇일까요? 사물은 말 그대로 어떤 목적을 달성하기 위해 만들어진 물건을 의미합니다. 알람시계는 시간을 알려주고 정해진 시간에 소리를 내어 알려주는 역할을 하기 위한 물건입니다. 우산은 비가 오는 날에 비를 막아 사람이 움직이는데 불편을 최소화 하는 역할을 하기 위한 물건입니다. 버스정류장은 사람들이 버스를 기다리고 원하는 버스를 타도록 하기 위한 물건입니다.

이러한 특정한 목적을 가지고 있는 사물에 인터넷을 연결합니다. 그리고 그 인터넷을 통해 필요한 정보를 가져옵니다. 그리고 그 정보를 가공하여 그 물건이 해야 할 일을 보다 더 똑똑하게 할 수 있도록 제어하고 또 알려 주어 그 사물의 가치를 더욱 더 높여줍니다.

바로 이러한 기술이 사물인터넷입니다. 사물인터넷이 가지는 정보나 그 기능이 범용컴퓨터에서 못하는 기술은 아닙니다. 오히려 스마트폰 같은 범용 장비가 더 많은 일을 하며 더 많은 정보를 제공합니다. 하지만 범용 장비는 자신이 원하는 정보를 얻기 위해 더 많은 단계를 거쳐야 하고 정확한 정보를 얻어 내는 것은 더 어려운 일입니다.

그렇다면 유비쿼터스 컴퓨팅과는 무슨 차이가 있을까요. 물건을 더 똑똑하게 만든다는 컨셉은 유사하지만 인터넷에 연결되지 않아도 똑똑하게 일하도록 미리 세팅해 놓는 다는 점이 다릅니다. 예를 들어 사람이 방에 있는 것을 감지하고 조명을 켜는 것, 그리고 보일러를 가동하는 것, 이런 것들은 인터넷에 연결되지 않고도 미리 설정해 놓은 조건만으로도 얼마든지 작동이 가능한 기술입니다. 사물인터넷은 이보다 더 똑똑합니다.

본격적으로 사물인터넷의 사례에 들어가기에 앞서, 스페이스 오딧세이라는 소설의 저자인 과학소설가 “아서 클라크”가 한 말을 살펴볼까요?

충분히 발전된 기술은 마법과 구분하기 어렵다 – Arthur Clark

그렇습니다. 잘 만들어진 사물인터넷 제품은 마법과 같은 일을 합니다.

사물인터넷의 사례

그렇다면 사물인터넷에는 어떤 사례들이 있을까요? 아직도 활발히 연구가 진행되고 있고 제품화를 위해 많은 기업들이 노력을 하고 있지만, 사용할 만한 기술과 제품들이 곳곳에 나와 있습니다.

도난방지가 가능한 지갑입니다. 지갑 참 많이 잃어 버리죠. 저도 역시 그런 사람 가운데 하나입니다. 지갑은 소중한 물건입니다. 잃어 버리면 여러가지로 복잡한 상황에 부딛히게 되죠. 그 지갑이 이제는 내 주인이 나에게서 10m만 떨어져도 나를 놓고 가지 말라고 알려줍니다. 건망증 심한 주인에게는 아주 똑똑한 지갑입니다.

상황을 인지하는 알람시계도 있습니다. 내일 출장을 갈 일이 있어 비행기 시간에 맞춰 알람을 맞춰 놓았습니다. 그런데 알람시계가 아침에 깨우긴 깨웠는데 내가 정한 시간보다 30분이나 늦게 깨웠습니다. 왠일인가 알고보니 안개가 짙어서 내가 타고 가려는 비행기가 30분 늦게 출발한다는 것을 시계가 알고 있었던 것입니다.

아침에 일어나 눈을 떠보니 늦었습니다. 부랴부랴 씻고, 화장하고, 옷을 입고 아파트 25층에서 아래층까지 내려왔습니다. 그랬더니 비가 옵니다. 미리 우산을 챙겨 오지 않은 자신을 실컷 욕하며 다시 집으로 올라 갑니다. 이미 회사는 지각입니다. 그런데 어떤 사람은 똑같은 상황에서 집 현관을 나가려고 보니 우산 손잡이가 빛을 내며 깜빡입니다. 그렇습니다. 비가 오는 것입니다. 그 똑똑한 우산은 주인에게 비가 오니 날 가지고 가야 한다고 알려 주고 있는 것입니다.

정해진 시간에 약을 먹어야 하는 환자가 있습니다. 여러가지 사정으로 집에서 통원 치료를 받고 있습니다. 그런데 깜빡하고 약을 먹지 않았습니다. 그걸 약이 알고 있습니다. 뚜껑을 열지 않았기 때문이죠. 뚜껑은 즉시 담당의사에게 이 사실을 알려 줍니다. 건망증 심한 환자는 의사에게 꾸중을 듣습니다.

그렇습니다. 그 외에도 많은 분야에 사물인터넷이 활용되고 있습니다. 영화에 나오는 마법과 같은 일이 벌어지고 있습니다. 그리고 그 물건은 자신의 역할을 보다 똑똑하게 해내고 있습니다. 주인들을 위해서 말이죠.

일반컴퓨팅과 사물인터넷의 차이

그렇다면 일반컴퓨팅과 사물인터넷은 구체적으로 어떻게 다른지 살펴보겠습니다.

일반컴퓨팅이 사물인터넷이 하는 일을 못하는 것이 절대 아닙니다. 예를 들어 버스 도착 정보를 확인하는 기능을 살펴보겠습니다. 스마트폰을 이용한 일반컴퓨팅(어느새 스마트폰이 일반적인 컴퓨팅 도구가 되었습니다)을 이용해 버스승강장으로 가면서 1000번 버스가 내가 버스를 타고자 하는 승강장에 언제 도착하는지를 조회하고자 합니다. 스마트폰을 꺼내고, 잠금을 푼다음, 다음이나 네이버 같은 버스정보를 조회할 수 있는 앱을 열고, 지역을 선택하고, 버스를 조회한다음, 버스 승강장을 조회하여 몇분 또는 몇초 뒤에 도착하는지 확인합니다. 그 시간이 상당한 시간이 소요되며, 그러는 사이 1000번 버스는 지나가 버려 다음 버스를 기다려야 하는 상황이 자주 발생합니다.

사물인터넷은 버스승강장에 버스 도착 알림 기능을 가지게 됩니다. 그리고 버스승강장에 가면 1000번 버스가 언제 도착하는지 바로 알 수 있습니다. 단순한 예를 들었지만 실제 일반 컴퓨팅은 몇단계를 거쳐 필요한 정보를 얻고 그 정보를 판단하여 행동을 해야 하는 반면 사물인터넷은 사물 자체의 역할이 정해져 있기 때문에 필요한 정보를 판단하여 액션까지 취해주는 편리함을 제공하게 되는 것입니다.

사물인터넷의 구성

그렇다면 이런 마법 같은 일이 어떤 원리로 일어나게 되는 것일까요? 사물인터넷의 구성은 의외로 간단합니다. 사물인터넷 기능을 가지는 사물은 인터넷에 연결되어야 합니다. 그리고 그 사물은 컨트롤러와 센서, 그리고 액추에이터를 가지고 있습니다. 컨트롤러는 인터넷에 연결하고 정보를 분석하며, 사물이 특정한 액션을 하도록 하는 등의 제어를 합니다. 센서는 특정한 일이, 상황이 벌어지고 있는지를 탐지합니다. 마지막으로 액추에이터는 특정한 신호를 발생시키는 액션을 담당합니다.

비가 오는 것을 미리 아는 똑똑한 우산을 예로 들어보면, 우산은 우산 손잡이에 컨트롤러를 내장하고 인터넷에 연결하여 날씨 정보를 가져오고 해당 지역의 날씨를 확인합니다. 근접센서를 통해 주인이 현관 문 근처에 오는지를 알아챕니다. 그리고 액추에이터인 LED를 이용해 손잡이에서 예쁜 빛을 냅니다. “나를 가져가세요”

이제 사물인터넷의 원리가 잘 이해가 되었나요?

사물인터넷의 원동력

사물인터넷이 왜 관심을 받게 되었을까요? 사물인터넷은 결국 조금 더 편리하고자 하는 인간의 삶에 대한 본질적 욕구 때문에 관심을 받게 되고 만들어지게 됩니다. 일반 컴퓨팅은 편리하기는 하지만 사람들의 본질적인 삶을 변화 시키는데는 한계가 있습니다. 여전히 우리 주변에는 컴퓨터를 잘 못다루는 사람들, 스마트폰을 쓰지 않는 사람들, 인터넷뱅킹을 하지 않는 사람들이 많습니다. 그것은 일반 컴퓨팅이 해결하지 못하는 부분입니다.

하지만 사물인터넷, 즉 인터넷에 연결되어 있는 사물은 사람들의 본질적인 삶의 모습을 변화시킵니다. 왜냐하면 그 사물이 결국 그들의 삶의 일부분이기 때문이죠. 여전이 사물인터넷은 연구대상입니다. 새로운 물건이 만들어졌지만, 여전히 비쌉니다. 때문에 발전을 거듭하며 가격이 낮아져야 하고 대중화가 되어야 하겠죠. 아마도 사물인터넷의 확산은 이러한 흐름의 속도에 따라 달라질 것입니다.

사물인터넷은 누가 만드는가?

사물인터넷은 누가 만드는 것일까요? 사물인터넷은 사물 그 자체라고 이미 앞에서 말했습니다. 즉, 사물을 만드는 사람이 바로 사물인터넷을 만드는 사람인 것입니다. 결국 어느 IT 담당자, IT 기업, 개발자 등이 주도해서 만드는 것이 아니라 사물을 만드는 사람들 모두가 사물인터넷을 만드는 것입니다.

따라서 예술가와 장인, 그리고 디자이너, 엔지니어, 개발자 등 사물을 만드는데 역할을 할 수 있는 모두가 사물인터넷을 만드는 주인공이 될 수 있습니다.

마치며…

이번에는 사물인터넷에 대한 개념을 쉽게 이해할 수 있도록 하기 위하여 쉽게 이해할 수 있는 예를 들어 포스트를 작성해 보려고 많이 노력을 했습니다. 사물인터넷에 대한 이해의 폭이 조금이라도 넓혀졌기를 기대해 봅니다.

우리 비즈머스는 현재 FTA와 클라우드, 그리고 FTA와 클라우드의 접목, 플랫폼의 개발 등에 관심을 많이 가지고 있습니다. 그와 함께 클라우드 기술을 기반으로 하는 새로운 파생 상품에 대한 것도 관심을 가지고 있죠. 사물인터넷은 그 범위가 매우 광범위 하지만 우리 비즈머스가 클라우드의 파생 기술 및 상품분야로 눈여겨 봐야 하는 분야입니다. 앞으로도 더 많은 자료를 정리하여 이해의 폭을 넓히는데 최선을 다할 것입니다. 많은 관심과 성원 바랍니다.

힘이되는 100가지 명언 모음
Good Articles

힘이되는 100가지 명언 모음

힘이되는 100가지 명언 모음

 세상사는데 도움이되는 명언들 힘이되는 명언 용기를 주는 명언 위로가되는 명언 좋은명언 글귀 모음 100가지  자주 보면 좋을듯 하여 선별 했습니다.

1. 삶이 있는 한 희망은 있다  -키케로
2. 산다는것 그것은 치열한 전투이다.  -로망로랑
3. 하루에 3시간을 걸으면 7년 후에 지구를 한바퀴 돌 수 있다. -사무엘존슨
4. 언제나 현재에 집중할수 있다면 행복할것이다. -파울로 코엘료
5. 진정으로 웃으려면 고통을 참아야하며 , 나아가 고통을 즐길 줄 알아야 해 -찰리 채플린
6. 직업에서 행복을 찾아라. 아니면 행복이 무엇인지 절대 모를 것이다 -엘버트 허버드
7. 신은 용기있는자를 결코 버리지 않는다 -켄러
8. 행복의 문이 하나 닫히면 다른 문이 열린다 그러나 우리는 종종 닫힌 문을 멍하니 바라보다가
9.우리를 향해 열린 문을 보지 못하게 된다  – 헬렌켈러
10. 피할수 없으면 즐겨라 – 로버트 엘리엇
11. 단순하게 살아라. 현대인은 쓸데없는 절차와 일 때문에 얼마나 복잡한 삶을 살아가는가?-이드리스 샤흐
12. 먼저 자신을 비웃어라. 다른 사람이 당신을 비웃기 전에  – 엘사 맥스웰
13. 먼저핀꽃은 먼저진다  남보다 먼저 공을 세우려고 조급히 서둘것이 아니다 – 채근담
14. 행복한 삶을 살기위해 필요한 것은 거의 없다. -마르쿠스 아우렐리우스 안토니우스
15. 절대 어제를 후회하지 마라 . 인생은 오늘의 나 안에 있고 내일은 스스로 만드는 것이다 L.론허바드
16. 어리석은 자는 멀리서 행복을 찾고, 현명한 자는 자신의 발치에서 행복을 키워간다  -제임스 오펜하임
17. 너무 소심하고 까다롭게 자신의 행동을 고민하지 말라 . 모든 인생은 실험이다 . 더많이 실험할수록 더나아진다  – 랄프 왈도 에머슨
18. 한번의 실패와 영원한 실패를 혼동하지 마라  -F.스콧 핏제랄드
19. 내일은 내일의 태양이 뜬다
20. 피할수 없으면 즐겨라 -로버트 엘리엇
21.절대 어제를 후회하지 마라. 인생은 오늘의  내 안에 있고 내일은 스스로 만드는것이다. -L론허바드
22. 계단을 밟아야 계단 위에 올라설수 있다, -터키속담
23. 오랫동안 꿈을 그리는 사람은 마침내 그 꿈을 닮아 간다, -앙드레 말로
24. 좋은 성과를 얻으려면 한 걸음 한 걸음이 힘차고 충실하지 않으면 안 된다, -단테
25. 행복은 습관이다,그것을 몸에 지니라 -허버드
26. 성공의 비결은 단 한 가지, 잘할 수 있는 일에 광적으로 집중하는 것이다.- 톰 모나건
27. 자신감 있는 표정을 지으면 자신감이 생긴다 -찰스다윈
28. 평생 살 것처럼 꿈을 꾸어라.그리고 내일 죽을 것처럼 오늘을 살아라. – 제임스 딘
29. 네 믿음은 네 생각이 된다 . 네 생각은  네 말이 된다. 네말은 네 행동이 된다 네행동은 네 습관이된다 . 네 습관은 네 가치가 된다 . 네 가치는 네 운명이 된다 – 간디
30. 일하는 시간과 노는 시간을 뚜렷이 구분하라 . 시간의 중요성을 이해하고 매순간을 즐겁게 보내고 유용하게 활용하라. 그러면 젋은 날은 유쾌함으로 가득찰것이고 늙어서도 후회할 일이 적어질것이며 비록 가난할 때라도 인생을 아름답게 살아갈수있다  – 루이사 메이올콧
31. 절대 포기하지 말라. 당신이 되고 싶은 무언가가 있다면, 그에 대해 자부심을 가져라. 당신 자신에게 기회를 주어라. 스스로가 형편없다고 생각하지 말라. 그래봐야 아무 것도 얻을 것이 없다. 목표를 높이 세워라.인생은 그렇게 살아야 한다.  – 마이크 맥라렌
32. 1퍼센트의 가능성, 그것이 나의 길이다. -나폴레옹
33. 그대 자신의 영혼을 탐구하라.다른 누구에게도 의지하지 말고 오직 그대 혼자의 힘으로 하라. 그대의 여정에 다른 이들이 끼어들지 못하게 하라. 이 길은 그대만의 길이요,  그대 혼자 가야할 길임을 명심하라.  비록 다른 이들과 함께 걸을 수는 있으나 다른 그 어느 누구도 그대가 선택한 길을 대신 가줄 수 없음을 알라.
-인디언 속담
33. 고통이 남기고 간 뒤를 보라! 고난이 지나면 반드시 기쁨이 스며든다. -괴테
34. 삶은 소유물이 아니라 순간 순간의 있음이다 영원한 것이 어디 있는가 모두가 한때일뿐 그러나 그 한때를 최선을 다해 최대한으로 살수 있어야 한다 삶은 놀라운 신비요 아름다움이다. 법정스님 -버리고 떠나기
35. 꿈을 계속 간직하고 있으면 반드시 실현할 때가 온다. -괴테
36. 화려한 일을 추구하지 말라. 중요한 것은 스스로의 재능이며, 자신의 행동에 쏟아 붓는 사랑의 정도이다. -머더 테레사
37. 마음만을 가지고 있어서는 안된다. 반드시 실천하여야 한다. -이소룡
38. 흔히 사람들은 기회를 기다리고 있지만 기회는 기다리는 사람에게 잡히지 않는 법이다. 우리는 기회를 기다리는 사람이 되기 전에 기회를 얻을 수 있는 실력을 갖춰야 한다. 일에 더 열중하는 사람이 되어야한다. -안창호
39. 나이가 60이다 70이다 하는 것으로 그 사람이 늙었다 젊었다 할 수 없다. 늙고 젊은 것은 그 사람의 신념이 늙었느냐 젊었느냐 하는데 있다. -맥아더
40. 만약 우리가 할 수 있는 일을 모두 한다면 우리들은 우리자신에 깜짝 놀랄 것이다. -에디슨
42. 나는 누구인가 스스로 물으라 자신의 속얼굴이 드러나 보일 때까지 묻고 묻고 물어야 한다건성으로 묻지말고 목소리 속의 목소리로 귀 속의 귀에 대고 간절하게 물어야 한다해답은 그 물음 속에 있다. 법정스님- 산에는 꽃이 피네
43. 행복은 결코 많고 큰데만 있는 것이 아니다 작은 것을 가지고도 고마워 하고 만족할 줄 안다면 그는 행복한 사람이다. 여백과 공간의 아름다움은 단순함과 간소함에 있다. 법정스님 – 홀로사는 즐거움 에서
44. 물러나서 조용하게 구하면 배울 수 있는 스승은 많다. 사람은 가는 곳마다 보는 것마다 모두 스승으로서
배울 것이 많은 법이다.  -맹자
45. 눈물과 더불어 빵을 먹어 보지 않은 자는 인생의 참다운 맛을 모른다. -괴테
46. 진짜 문제는 사람들의 마음이다. 그것은 절대로 물리학이나 윤리학의 문제가 아니다. -아인슈타인
47. 해야 할 것을 하라. 모든 것은 타인의 행복을 위해서, 동시에 특히 나의 행복을 위해서이다. -톨스토이
48. 사람이 여행을 하는 것은 도착하기 위해서가 아니라 여행하기 위해서이다. -괴테
49. 화가 날 때는 100까지 세라. 최악일 때는 욕설을 퍼부어라. -마크 트웨인
50. 재산을 잃은 사람은 많이 잃은 것이고, 친구를 잃은 사람은 더많이 잃은 것이며, 용기를 잃은 사람은 모든것을 잃은 것이다. -세르반테스
51. 돈이란 바닷물과도 같다. 그것은 마시면 마실수록 목이 말라진다. -쇼펜하우어
52. 이룰수 없는 꿈을 꾸고 이길수 없는 적과 싸우며, 이룰수 없는 사랑을 하고 견딜 수 없는 고통을 견디고,
잡을수 없는 저 하늘의 별도 잡자. -세르반테스
53. 고개 숙이지 마십시오. 세상을 똑바로 정면으로 바라보십시오. -헬렌 켈러
54. 고난의 시기에 동요하지 않는 것, 이것은 진정 칭찬받을 만한 뛰어난 인물의 증거다. -베토벤
55. 사막이 아름다운 것은 어딘가에 샘이 숨겨져 있기 때문이다 – 생떽쥐베리
56. 행복의 한 쪽 문이 닫히면 다른 쪽 문이 열린다. 그러나 흔히 우리는 닫혀진 문을 오랫동안 보기 때문에 우리를 위해 열려 있는 문을 보지 못한다. -헬렌 켈러
57. 만족할 줄 아는 사람은진정한 부자이고, 탐욕스러운 사람은진실로 가난한 사람이다. -솔론
58. 성공해서 만족하는 것은 아니다. 만족하고 있었기 때문에 성공한 것이다.-알랭
59. 곧 위에 비교하면 족하지 못하나,아래에 비교하면 남음이 있다. -명심보감
60. 그대의 하루 하루를 그대의 마지막 날이라고 생각하라 – 호라티우스
61. 자신을 내보여라. 그러면 재능이 드러날 것이다. – 발타사르 그라시안
62. 자신의 본성이 어떤것이든 그에 충실하라 . 자신이 가진 재능의 끈을 놓아 버리지 마라. 본성이 이끄는 대로 따르면 성공할것이다 -시드니 스미스
63. 당신이 할수 있다고 믿든 할수 없다고 믿든 믿는 대로 될것이다.- 헨리 포드
64. 단순하게 살라. 쓸데없는 절차와 일 때문에 얼마나 복잡한 삶을 살아가는가? -이드리스 샤흐
65. 당신이 인생의 주인공이기 때문이다 . 그사실을 잊지마라 . 지금까지 당신이 만들어온 의식적 그리고 무의식적 선택으로 인해 지금의 당신이 있는것이다 .  – 바바라 홀
66. 지금이야 말로 일할때다. 지금이야말로 싸울때다. 지금이야말로 나를 더 훌륭한 사람으로 만들때다 오늘 그것을 못하면 내일 그것을 할수있는가- 토마스 아켐피스
67. 모든것들에는 나름의 경이로움과 심지어 어둠과 침묵이 있고 , 내가 어떤 상태에 있더라도 나는 그속에서 만족하는 법을 배운다 -헬렌켈러
68. 작은 기회로 부터 종종 위대한 업적이 시작된다  -데모스테네스
69. 인생이란 학교에는 불행 이란 훌륭한 스승이 있다. 그 스승 때문에 우리는 더욱 단련되는 것이다. -프리체
70. 세상은 고통으로 가득하지만 그것을 극복하는 사람들로도 가득하다 – 헨렌켈러
71. 도저히 손댈 수가 없는 곤란에 부딪혔다면 과감하게 그 속으로 뛰어들라 . 그리하면 불가능하다고 생각했던 일이 가능해진다.
72. 용기있는 자로 살아라. 운이 따라주지 않는다면 용기 있는 가슴으로 불행에 맞서라. -키케로
73. 최고에 도달하려면 최저에서 시작하라. -P.시루스
74. 내 비장의 무기는 아직 손안에 있다 .그것은 희망이다 – 나폴레옹
75. 문제는 목적지에 얼마나 빨리 가느내가 아니라 그 목적지가 어디냐는 것이다. -메이벨 뉴컴버
76. 한 번 실패와 영원한 실패를 혼동하지 마라. -F.스콧 핏제랄드
77. 인간의 삶 전체는 단지 한 순간에 불과하다 . 인생을 즐기자 – 플루타르코스
78. 겨울이 오면 봄이 멀지 않으리 -셸리
79. 일하여 얻으라 . 그러면 운명의 바퀴를 붙들어 잡은것이다 -랄프 왈도 에머슨
80. 당신의 행복은 무엇이 당신의 영혼을 노래하게 하는가에 따라 결정된다. – 낸시 설리번
81. 자신이 해야 할 일을 결정하는 사람은 세상에서 단 한 사람, 오직 나 자신뿐이다. -오손 웰스-
82. 먹고 싶은것을 다 먹는 것은 그렇게 재미있지 않다 . 인생을 경계선 없이 살면 기쁨이 덜하다 . 먹고싶은대로 다 먹을 수있다면 먹고싶은 것을 먹는데 무슨 재미가 있겠나 – 톰행크스
83. 인생을 다시 산다면 다음번에는 더 많은 실수를 저지르리라 – 나딘 스테어
84. 절대 어제를 후회하지 마라 . 인생은 오늘의 나 안에 있고 내일은 스스로 만드는 것이다 -L.론허바드
85. 인생에서 원하는 것을 엇기 위한 첫번째 단계는 내가 무엇을 원하는지 결정하는 것이다 -벤스타인
86. 가난은 가난하다고 느끼는 곳에 존재한다 .- 에머슨
87. 삶이 그대를 속일지라도 슬퍼하거나 노하지 말아라 슬픈 날에 참고 견디라 . 즐거운 날은 오고야 말리니 마음은 미래를 바라느니 현재는 한없이 우울한것 모든건 하염없이 사라지나가 버리고 그리움이 되리니 – 푸쉬킨
88. 문제점을 찾지 말고 해결책을 찾으라 – 헨리포드
89. 우선 무엇이 되고자 하는가를 자신에게 말하라 그리고 해야 할일을 하라 -에픽토테스
90. 되찾을 수 없는게 세월이니 시시한 일에 시간을 낭비하지 말고 순간순간을 후회 없이 잘 살아야 한다. -루소
91.인생에 뜻을 세우는데 있어 늦은 때라곤 없다 – 볼드윈
92. 도중에 포기하지 말라. 망설이지 말라. 최후의 성공을 거둘 때까지 밀고 나가자. – 헨리포드
93. 네 자신의 불행을 생각하지 않게 되는 가장 좋은 방법은 일에 몰두하는 것이다. -베토벤
94. 우리는 두려움의 홍수에 버티기 위해서 끊임없이 용기의 둑을 쌓아야 한다. -마틴 루터 킹
95. 직접 눈으로 본 일도 오히려 참인지 아닌지 염려스러운데 더구나 등뒤에서 남이 말하는 것이야 어찌 이것을 깊이 믿을 수 있으랴? -명심보감-
96. 이미끝나버린 일을 후회하기 보다는 하고 싶었던 일들을 하지못한 것을 후회하라. – 탈무드
97. 실패는 잊어라 그러나 그것이 준 교훈은 절대 잊으면 안된다. -하버트 개서
98. 내가 헛되이 보낸 오늘은 어제 죽어간 이들이 그토록 바라던 하루이다 단 하루면 인간적인 모든 것을 멸망시킬수도 다시 소생시킬수도 있다. -소포클레스
99. 성공으로 가는 엘리베이터는 고장입니다. 당신은 계단을 이용해야만 합니다. 한계단 한계단씩 – 조 지라드
100. 길을 잃는 다는 것은 곧 길을 알게 된다는 것이다. – 동아프리카속담
101. 삶을 사는 데는 단 두가지 방법이 있다. 하나는 기적이 전혀 없다고 여기는 것이고 또 다른 하나는 모든 것이 기적이라고 여기는방식이다. – 알베르트 아인슈타인
The top 25 laptop battery life performers from CNET Labs
Science

The top 25 laptop battery life performers from CNET Labs

The top 25 laptop battery life performers from CNET Labs

Click to the link: https://www.cnet.com/pictures/cnet-labs-laptops-and-hybrids-with-the-best-battery-life/