[edu]IT기본지식(스타트업,기획자,디자이너)

[프로그램의 본질은 소스코드]

우리는 굉장히 많은 컴퓨터 프로그램을 이용한다.

카카오톡 같은 메신저를 비롯해서 쇼핑, 게임, 소셜 등등 그 종류도 많고 

우리 생활에 굉장히 밀접하다.

이런 프로그램들을 만들기 위해서는 프로그래밍 언어된 소스 코드를 작성해야 한다.

그리고 그것을 컴퓨터가 알아 들을 수 있는 기계어로 번역해야 한다.

프로그래밍 언어로 작성된 소스 코드는 

컴퓨터가 바로 알아듣고 실행할 수 없기 때문에 변환과정이 필요하다.

사람의 언어로 비유하면 영어 > 한국어 로 번역 과정이라고 할 수 있다. 

번역하는 작업은 컴파일이라고 부른다.

프로그래밍 언어에는 c, c++, c#, java, python, javascript, ruby, 등등 굉장히 많은 언어들이 있다.

이것들은 각각의 특징을 가지고 있고 용도 또한 다르다.

각각 상황에 맞는 최선의 선택이 필요하다.

필요한 언어를 빠르게 습득하는 것도 개발자의 능력이다.

안드로이드를 앱을 제작할 때는 java 를 사용하고 웹에서는 javascript 를 사용하고

아이폰 앱을 제작할 때는 objective-c, swift 를 사용한다.

그리고 펌웨어를 만들때는 c 를 사용한다.

어떤 언어가 좋다라는 것은 없고 다만 목적과 특징이 다를 뿐이다.

어떤환경에서 동작할 건지, 성능이 빨라야 하는지?

생산성이 좋아야 하는지, 여러가지를 고려해서

진행하는 프로젝트에 적합한 개발 언어를 선택해야 한다.

Q/A

Q: 가장 최신 가장 좋은 언어 하나만 사용하면 되지 않느냐?

A: 새로운 언어가 개발될때 이전의 언어들의 단점이 보완되기는 하지만

모든 장점을 가지지는 못한다.

언어들은 동작하는 환경마다 특징이 다르다.

과거 언어들의 스파케티 코드를 해결하기 위해 OOP 라는 개념이 나왔지만

여전히 작은 하드웨어의 펌웨어 에서는 C 로 작성한다.

펌웨어 같이 낮은 성능의 칩에서는 OOP 언어를 돌릴만한 성능 리소스가 필요없고

그렇게 큰 소스코드를 작성할 필요도 없다.

반대로 고급언어들은 높은 생산성을 가지고 있지만 성능은 C 보다 많이 느리다.

하지만 고급 언어에서 항상 성능이 느리지는 않다.

많은 계산을 빨리 해야하는 부분은 C로 작성된 코드를 사용할 수 있다.(라이브러리 개념)

굉장히 많은 언어들이 있지만 우위를 따지기 힘든게

용도에 따라 최선이 되는 언어는 달라진다.

[프로그램은 운영체제 위에 동작한다]

안드로이드, iOS, Windows, linux, macOS 등등 많이 들어 봤을 것이다.

이것들은 모두 os 의 종류 들이다.

OS는 Operatin System 의 약자 이다. 

컴퓨터만 있다고 인터넷을 하고 게임을 할 수는 없다.

컴퓨터 즉 하드웨어를 구동 시키는 os 가 설치되어 있어야 한다.

인터넷 브라우저나 게임, 카카오톡, 인스타그램 같은 어플리케이션들은

운영체제가 설치되어 있는 상태에서 동작할 수 있다.

때문에 모든 어플리케이션은 os에 의존적이며

구동되는 os 에 룰에 따라야 한다.

한 종류의 어플리케이션은 

안드로이드 버전, 아이폰 버전, 윈도우 버전, 맥  등등

각각의 os 버전들이 따로 존재한다.

[라이브러리, 프레임워크, 플랫폼, 아키텍처]

[라이브러리]

프로그램을 만들 때 필요한 기능들 이라고 할 수 있다.

비유하자면 자동차를 만들때 타이어, 헤드라이트, 에어백, 시트, 안전밸트 등등 이다.

이 부분들은 대부분 자동차들에 범용적으로 사용된다.

자동차 회사들이 이러한 자동차 부품들을 모두 직접 만들 필요는 없다.

게다가 A라는 차에는 a라는 헤드라이트를 B라는 차에는 b라는 헤드라이트를

장착한다고 해보자

헤드라이트 뿐만 아니라 

각각의 필요한 부품들을 만들려면 자동차 공장 이외에

부품을 만드는 공장들을 부품수 * 자동차 종류 만큼 건설해야 한다.

자동차에 필요한 부품들은 수만개라고 한다.

이게 효율적일까?

모든 자동차에 범용적인 부품을 사용하고

그 부품들은 만들어진 완전품을 구입해서 사용하면 훨씬 효율적이다.

소프트웨어도 마찬가지다.

개발하는 모든기능들을 모두 직접 만들 필요는 없다.

일반적으로 사용하는 기능들은

이미 너무 잘 만들어진 것들이 존재한다.

그것들을 잘 사용하면된다.

라이브러리를 잘 사용하면 개발이 보다 쉬워진다.

예시로 javascript 의 jQuery 

windows 에서 dll(dynamic-link library) 파일 이 있다.

[프레임워크]

자동차에 비유 하자면 기본 뼈대가 되는 프레임 이다.

프레임워크만으로는 실행되지 않고

필요한 기능을 추가해야 한다.

단 프레임워크가 정의한 규칙을 준수하고 규격에 맞게 진행해야 한다.

필요한 기능중에 상당 부분이 프레임워크 자체에서 제공하는 

경우가 많다. django 의 경우는 

어드민 사이트를 구현하지 않아도 기본적으로 제공한다.

이런점은 굉장히 큰 장점이고 개발일정을 앞당길 수 있다.

예시 java 에 spring

python 의 django

[아키텍처]

기획한 프로그램의 필요한 주요 특징을 기술적으로 설계하고 명시하는 것이다.

자동차로 비유하자면 설계 도면이라고 보면된다.

하지만 모든 특징이 명시되지는 않고 특히나 구현 방법이나 라이브러리, 프레임워크는 

명시되지 않을 수도 있다.

사실 실제 현업에서 구체적인 설계를 못하는 경우가 많다.

혹은 설계를 했다고 하더라도 개발하면서 많은 변경사항이 발생하여

최초의 설계에서 많이 수정되는 경우가 많다.

예시로 ms Azure 솔류션 아키텍처

[플랫폼]

 프로그램의 실행 환경이라고 볼 수 있다.

자동차로  비유하자면 일반도로/고속도로용인가? 사막용, 경주용 등등 이 될 수있다.

윈도우용 프로그램이면 플랫폼은 윈도우가 되는 것이다. 

플랫폼 위에 또 다른 플랫폼이 존재할 수 있다.

윈도우에서 java 로 개발하고 있으면 2개의 플랫폼을 사용하고 있는 것이다.

모든 플랫폼에서 실행되도록 개발하기는 어렵고 

목적에 맞는 플랫폼을 선택하는 것이 중요하다.

플랫폼 예시

윈도우, 리눅스, 맥, os 는 모두 플랫폼

구글 플레이 스토어, 아이폰 앱 스토어 등도 플랫폼

Java 프로그램은 os 제약이 없지만 실행되기 위해서는 

자바 가상 머신(JVM)위에서 실행 되므로 JAVA 플랫폼이 필요하다.

[API]

개발자가 아니라도 관련 업무를 하거나 기획을 하면 많이 듣게 되는 단어다.

API 는 Application Programming Interface 의 약자이다.

해석 하자면 사람의 인터페이스가 아니라 어플리케이션의 인터페이스다.

어플리케이션에서 카카오 톡 기능, 페이스북 기능, 유튜브 기능 등등의 기능을 사용할 때 필요하다.

새로 만드는 앱이 있는데 카카오톡에서 친구 추가 기능을 이용하려고 한다.

이것은 카카오톡에서 제공하는 API 를 이용해야 한다.

어떤 앱에서 페이스북에 자동으로 글을 등록하는 기능을 구현 하려면

페이스북에서 해당 기능을 제공하는 API 를 이용해야 한다.

API 는 해당 서비스 개발사에서 제공을 해야지 사용할 수 있다.

기획 단계에서 연동하려는 서비스에서 

해당 기능을 API 로 제공하는지 API 문서나 직접 문의를 해야 한다.

API 가 없다면 해당 기능은 사용할 수 없다.

때문에 반드시 확인을 해야한다.

[웹/앱]

웹과 앱이라는 말은 많이 들어 봤을 것이다.

발음도 비슷해서 혼동할 수도 있는데 정확한 차이를 알아보자

[WEB]

월드 와이드 웹(world wide web)의 줄임말로 

인터넷상의 문자,영상,소리 등의 정보를 인터넷에 연결해 주는 서비스를 의미한다.

웹은 브라우저(ms ie, fireforx, chrome, opera 등)를 통해 동작한다.

인터넷에서 정보를 이용하려면 브라우저가 필요하고 

브라우저는 서버에 필요한 정보를 요청(request)하여 받아온다.

우리가 인터넷에서 사용하는 포털 사이트, 구글, 네이버 등등도 웹이고

쇼핑몰 사이트, 블로그, 각종 웹서비스도 웹이다.

네트워크가 연결되지 않으면 아무것도 할 수 없다.

인터넷 망에 연결된 상태에서만 개발자의 의도대로 동작한다.

[HTML/CSS/JavaScript]

브라우저에서 네이버나 구글 같은 웹사이트에 접속하면

이미지파일 등을 제외하고 html, css, js 이렇게 세가지 파일을 받아 온다.

HTML, CS, JavaScript 는 개발자가 아니라도 굉장히 많이 들어 봤을 것이다.

웹페이지에서 각각 어떤 역활을 하는지 알아보자

HTML은 웹 페이지의 내용을 담당한다. 

순수하게 내용만 담당해서 효과나 장식적인 요소를 배제한 텍스트정도 라고 생각하면 된다.

CSS는 웹페이지의 외형을 담당한다.

HTML 은 메모장에 쓴 투박한 내용만 담고 있다면

CSS는 이 내용들에 색깔도 입히고, 여기저기 배치도 시키고 

웹페이지을 꾸며준다.

우리가 보는 웹페이지는 HTML의 내용에 CSS 의 스타일을 입혀서

최종적으로 외형이 완성된다.

웹페이지에는 겉에 보이는 모습 뿐만 아니라 

동작이나 기능들이 있다.

JavaScript 가 바로 이것들을 담당한다.

웹페이지의 이미지 슬라이드 같은 종류나, 우측 상단의 설정 버튼을 누르면 메뉴가 뜨고

글자 크기를 조정하고 이런 동작들이 모두 JavaScript 에서 구현된 동작이다.

[APP]

흔히 모바일 앱을 떠올리게 된다.

어플리케이션(application) 의 준말로 프로그램을 의미한다.

모바일에서 카카오톡, 텔레그램, 슬랙 메신저와 인터넷 뱅킹 앱, 카메라 앱

갤러리, 내파일, 지하철 노선, 캘린더 등등이 모두 앱이다.

모바일 앱 뿐만 아니라 window, mac, linux 의 각종 게임이나 프로그램도

앱으로 분류한다.

안드로이드 앱은 Java 로 개발되고 iOS 는 object-C 나 Swift 언어로 개발된다.

Unity, Unreal 같은 게임엔진은 여러 플랫폼으로 개발할 수 있다.

앱에서 일부 기능은 네트워크가 연결되어 있어야 동작 하지만

모든 기능이 네트워크가 반드시 필요하지 않을 수도 있다.

안드로이드 앱같은 경우는 편의성, 보안성, 안전성 등의 이유로 

구글 플레이 스토어라는 플랫폼에서 배포된다.

[web, app 차이점]

사실 앱이라고 해서 서버에서 정보를 가저오지 않는것은 아니고

정보를 보여주는 측면에서는 별차이가 없을 수도 있다.

하지만 개발자의 의도와 사용자의 사용방식에 있어서는

명백히 서로 다르다.

그럼 브라우저는 웹일까? 앱일까? 브라우저 자체는 앱이고, 

브라우저에서 접속하는 네이버나 블로그 같은 것은 웹이다.

웹의 경우 브라우저를 통해 동작하고 

업데이트 내용이 즉시 반영된다.

모든 사용자가 즉각 업데이트된 내용을 이용하게 된다는

매우 큰 장점이다.

또한 플랫폼의 제약이 별로 없다.

안드로이드,아이폰, window, mac, linux 등등

OS 나 브라우저가 달라도 웹은 동일하게 동작한다.

하지만 단말의 정보나 기능을 이용 하기에는 제한적 이다.

앱은 사용자가 업데이트된 내용을 이용하려면

해당 디바이스에 다운로드 받고 설치를 완료해야 한다.

이 과정은 항상 모든 유저가 하지 않을 수 있다.

일부 유저는 귀찬아서 최신버전으로 업데이트를 하지 않을 수도 있다.

따라서 이전버전과 호환성을 고려해서 개발해야 한다.

또한 플랫폼의 제약이 크다.

안드로이드 앱과 아이폰 앱을 별도로 개발해서 배포해야 한다.

여러 플랫폼으로 개발하는데 필요한 비용을 충분히 고려해야 한다.

 

Q/A

Q: 스타트업을 준비중인데 이것을 웹으로 해야할지 앱으로 해야할지

하이브리드앱으로 해야할지 모르겠어요.

A: 각각 장단점이 있습니다. 필연적으로 서버는 만들어야 할 거 같고

문제는 사용자 로컬에서  프론트 엔드를 어떤 방식으로 하느냐의 문제 입니다.

단말 기능을 적극 이용하고 단말 의존성이 높거나 빠른 동작을 요구한다면

네이티브 앱을 추천합니다.

하지만 네이티브 앱은 안드로이드, iOS 각각 개발해야 합니다.

크로스플랫폼으로 안드로이드와 iOS 를 같이 개발한다면

따로 만들지 않아서 개발 시간이 줄어 들수 있지만 개인적으로는 추천드리지는 않습니다.

가장 추천 드리는 방식은 네이티브 앱으로 제작하는 것입니다.

초기부터 모든 모바일을 제작하시기 힘드시다면

사람이 많이 사용하는 안드로이드 먼저 제작하는 것도 방법입니다.

[서버,클라이언트,DB]

서버와 클라이언트, DB 라는 말은 인터넷을 하거나 게임을 하거나

많이 들어본 단어들이다.

우리가 흔히 사용하는 카카오톡, 인터넷 뱅킹, 게임, 유투브 등등

모두 서버, 클라이언트, DB 등의 구조를 가지고 있다.

대부분의 웹서비스도 이런 구조를 반드시 가지고 있다.

간단하게 클라이언트는 요청자, 서버는 요청에 대한 제공자,

DB 는 서버가 응답해줄 데이터의 집합체다.

예를 들어 인스타그램에서 친구 페이지에 접속 한다고 해보자

그러면 스마트폰은 클라이언트가 된다.

클라이언트에서 해당 페이지 정보를 요청하는 것이다.

정보 요청에 대한 응답은 서버가 하게 된다.

서버는 해당 페이지의 글과 사진을 응답하기 위해

필요한 정보들을 DB(database)에서 불러온다. 그리고

최종적으로 스마트폰에서 인스타그램 해당 페이지를 볼 수 있다. 

하나의 서버에는 다수의 클라이언트의 요청이 있을 수 있다.

요청이 많아 질 수록 서버는 바뻐지게 된다.

수용할 수 있는 요청을 넘으면 클라이언트에게 정상적인 응답을 할 수 없다.

이 모든 과정들은 네트워크 통신에서 이루어 진다.

네트워크 통신 또한 비용이기 때문에 무분별한 요청과 응답이 이루어 지면 안된다.

꼭 필요할 때 요청을 해야 서버가 쾌적하게 동작할 수 있다.

[AWS]

웹서비스를 관련 업무를 하다 보면 개발자에게 aws 라는 말을

한번쯤 들어 봤을 수 있다.

당황하지 말고 어떤 뜻인지 알아보자!

Amazon Web Service 의 약자로 아마존에서

제공하는 클라우드 서비스다.

과거에는 서버를 구축하려면 서버로 사용할 컴퓨터를

구비해서 물리적으로 관리해 주어야 했다.

물론 요즘도 그런 경우는 많다.

예를 들어 보자. 쇼핑몰을 구축하려고 한다.

서버로 사용할 컴퓨터를 준비하고 os 는 리눅스를 설치하였다.

그리고 인터넷도 끈기면 안되니 안정적이어야 한다.

정전되지 않을까 별도의 발전기 까지 구비해 두었다.

그리고 쇼핑몰에 고객이 많아저서 

서버가 수용할 수 있는 한계를 넘어섰다.

기존 서버를 그대로 두고 새로운 서버를 다시 구축해야 한다.

이러한 과정을 한번에 제공하는 클라우드 서비스 바로 aws 다.

물리적인 서버는 우리는 볼 수 없지만

원하는 os 와 스펙의 컴퓨팅을 계정생성 즉시 얻을 수 있다.

쇼핑몰이 잘되서 트래픽이 더 많이 발생한다면

그만큼의 비용을 지불하고 수용한계가 더 많은

서비스를 이용하면 된다.

아마존에서 물리적인 요소도 알아서 관리하기 때문에

정전이 발생하거나 네트워크가 불안정 하지도 않다.

대표적인 경쟁 업체로는 ms azure 가 있다.

[프론트엔드/백엔드]

프론트엔드 백엔드는 개발자가 아닌 사람에게는 생소한 용어일 수 있다.

웹서비스를 개발하면 많이 접할 수 있는 단어들이다.

프론트엔드(front-end)는 사용자 눈에 보이면 화면을 의미한다.

이것을 개발 하는 사람을 프론트엔드 개발자 라고 부른다.

프론트엔드 개발자는 pc, 모바일등 각각 다른 종류의 디바이스에서

각각 다른 해상도에서 웹을 보기좋게 프로그래밍 한다.

백엔드(back-end)는 사용자가 볼 수 없는 영역 즉,

프론트엔드 이외에 부분을 말한다.

프론트와 데이터를 주고 받거나 DB에 데이터를 처리하거나 

뒤에서 보이지 않게 여러가지 일을 한다.

말 그대로 보이는일과, 뒤에서 하는 일이라고 보면 된다.

프론트는 개발적인 측면보다 디자인적 측면이 강하다.

프론트엔드에서 개발자가 필요한 기술은 웹 디자이너가 만든 리소스를

웹상에서 의도대로 보이도록 기본적으로 

HTML, CSS, JavaScript, 를 주로 다루게 된다.

이것은 앞서 설명했던 것처럼 해당 사이트에 접속하면 받아오는 것들이다.

백엔드에서는 프론트에서 필요한 정보들,

예를들어 쇼핑몰이라고 하면 상품사진, 상세정보, 고객정보 등

프론트에서 요청한 정보를 처리해서 전달해 준다.

보통 백엔드 개발자가 더 높은 연봉을 받는걸로 알려저 있지만

최근에는 디자인적 부분이 많이 강조되는 만큼 프론트의 역할도 중요하다.

최근에는 디자이너 중에도 프론트엔드를 공부해서

개발 가능한 인력이 종종 있다.

프론트와 백엔드 두가지를 다 할 수 있는 개발자를

풀스택 개발자 라고 부른다.

혼자서 모든걸 다 할수 있다는 뜻이기도 한데

이것이 반드시 좋은 것은 아니다.

각각 분야를 할 수 있지만 전문성이 떨어질 수 있고

혼자 하더라도 개발시간은 아무래도 굉장히 증가 할 수 있기 때문이다.

[스타트업:린스타트업]

스타트업의 실패 확률이 너무 높고

고객에 대한 무지, 시장 니즈 파악실패 등이 가장 큰 실패 이유다.

그래서 린스타트업 방법론이 도입되는데

최소기능제품(Minimal, Viable Product, MVP) 라고 하는

첫 제품을 빠르게 출시한 후 소비자들의 반응을 살피고, 여기에 개선점을 찾아

더 나은 제품을 내놓는 사이클을 반복한다.

이를 통해 제품의 실소비자를 파악하고 이들의 취향과 원하는 것을 구체적으로 

알수 있게 된다.

하지만 린스타트업은 만능이 아니다. 

모든 분야와 케이스에 적용될 수는 없다.

헬스케어, 법률, 금융 등등 MVP 에서 Minimal 이 용납되지 않는 분야가 존재한다.

의료쪽은 최소기능이라고 해서 환자를 치료 하다말거나 

오히려 아프게 하거나

법률, 금융 쪽도 최소기능이라는 것을 용납하지 못한다.

그외에도 호텔 예약하는 서비스 인데 

실제 예약에서 문제가 발생해서 신혼여행자가

예약이 안되는 불상사가 생기면 안된다.

최소기능제품을 빨리 만들어라!

많은 테스트를 하라!

 

Q/A

Q: 요즘 린스타트업이란 애기를 많이 들었습니다.

이것을 무조건 하는게 좋은 건가요?

A: 실제로 현업에서는 린스타트업의 지침을 완벽히 따라하기는 힘들고 그런 케이스도 많이는 없습니다.

상황에 따라 유동적으로 적용해야 합니다.

무조건적으로 프로세스 전반에 일괄적으로 적용하는 것도 문제가 생길 수 있습니다.

제가 강조하고 싶은건 MVP 입니다.

어떤 제품을 만들때 MVP가 아닌 너무나 쓸데없는 것을 추가합니다.

MVP 가 필연적으로 무거워 지는 프로젝트(헬스케어, 금융, 등등)에는

결함이나 오류가 있는 상태에서 시장에 나가기 어렵습니다.

대부분 소프트웨어 프로젝트에는 적용해서 이점이 있으나

이것을 판단하는 것은 리더의 역량입니다. 

[워터폴, 애자일]

애자일(Agile), 워터폴(Waterfall) 은 모두 소프트웨어 개발 방법론이다.

이 둘의 차이점을 알아보자

[워터폴 모델 도식화, 출처 http://slidehunter.com/]

워터폴은 폭포수 방법론이라고도 한다.

정해진 순서대로 앞선 파트의 업무가 순서대로 진행된다.

이전 단계가 완성되어야 다음단계로 넘어갈 수 있고

이전단계의 수정사항이 발생한다면 

다시 순차적으로 이러한 과정을 반복해야 하기 때문에

비용이 상대적으로 높다.

요구분석 > 설계 > 디자인 > 코딩 > 개발 > 테스트

실제 디자인 또는 개발된 결과물을 시각적으로 확인하고 나서야

수정요청이 발생한다.

이럴경우 요청을 수용하려면 이미 지나온 이전 단계들로 돌아가

기획단계부터 수정되어야 하는데

이것은 일정과 비용등 여러 항목에서 많은 문제점을 가지고 있다.

[애자일 모델 도식화,출처 http://slidehunter.com/ ]

애자일은 특정 방법론을 지칭하지 않는다.

Agile = 기민한, 날렵한

적은 비용으로 요구사항과 테스트에 빠르게 반응할 수 있는

다양한 방법론을 통칭하는 말이다.

애자일 소프트웨어 개발 선언문

'프로세스와 도구' 보다는 '개인과 상호작용'

'포괄적인 문서화' 보다는 '동작하는 소프트웨어'

'계약협상' 보다는 '고객과의 협력'

'계획 준수' 보다는 '변화에 대응'

이것은 경량(Lightweight) 프로세스라고 한다.

애자일과 다른 방법론이 구별되는 가장 큰 차이점은

문서를 통한 개발이 아니라 코딩을 통한 방법론이다.

일반적으로 스크럼 프로세스를 따르게 되는데

보통 한달, 짧게는 1~2주 정도 단위를 개발주기로 정한다.

그 기간동안 목표와 필요 작업을 명시하는데

그것을 별도의 문서로 만드는 비용을 소비할 필요 없이

애자일 모델을 지원하는 소프트웨어를 사용하면 편하다.

기획, 디자인, 개발 각각 파트는 워터폴과 다르게

서로 병렬 구조 혹은 서로 상호작용을 하면서

동시 다발적으로 진행된다.

스크럼단위로 짧은 시간 단위로 끈임없이 프로토 타입을

만들어 내며 필요한 요구사항을 더하고 수정하는

과정을 거치게 된다.

이것은 고객이 개발에 참여하는 모델이며 고객의 니즈를

여러 테스트를 통해 파악할 수 있는 장점이 있다.

Less Document-Oriented

Code-Oriented

애자일이 워터폴보다 좋다? 라고 오해할 수도 있다.

이둘은 어느것에 우위에 있는 것이 아니며

진행하는 프로젝트에 적합한 방법론을 적용해야 한다.

	워터폴	애자일
요구사항	미리 정의된 것	진행 과정에 걸처 진화
릴리즈	빅뱅 릴리즈	빠르고 반복적인
기획	계획중심	학습중심
의사소통	고객과 드믄 소통	지속적인 소통
결과물 전달	단계별 전달	진행중인 작업본 지속적인
개발순서	수평적인 단계별	기능별 수직 개발
테스트	마지막 단계	초기이후 잦은 테스트
통합	마지막에 통합	초기이후 잦은 통합
진행 사항 진단	문서화된 진행사항 진단	개발중 소프트웨어로 진단

MVP 가 상당히 무거운 프로젝트에서는 전체 프로세스에 애자일을

적용하기 힘들고

애자일을 적용할 수 있는 프로젝트에도 무조건적으로 

전체 프로세스에 적용하는건 옳지 않다.

이것을 판단하는것은 곧 프로젝트 리더의 역량이고

사실 방법론은 지침일 뿐이고 리더의 역할이 굉장히 크다고 생각한다.

Q/A

Q: 문서를 최소화 하고 코드 지향적이라고 했는데 기획자는 코드를 작성하는 사람이 아닌데

어떻게 의사 전달을 해야 하나요?

A: 프로젝트에서 내부 공유 문서의 본질은 정보의 공유라고 생각합니다.

문서를 보고 개발자들은 기능을 구현합니다.

문서가 복잡해지고 방대해 지면 그것을 생산하고 이해하는데 많은 비용이 소모 됩니다.

또한 잦은 피드백으로 방향이 자주 변경된다면 더더욱 그렇습니다.

Code-Oriented 는 문서를 아예 만들지 말라는 의미가 아니라

정보 공유, 의사전달이 만족한다면 

더이상 의미없는 문서작성에 시간을 낭비하지 말라는 의미 입니다.

[엔지니어는 왜 중요한가?]

 최근 스타업 하는 사람이 증가하고 있다.

그럼 스타트업이란 과연 무엇일까?

스타트업: 설립한 지 오래되지 않은 신생 벤처기업을 뜻한다. 미국 실리콘밸리에서 생겨난 용어로서, 혁신적 기술과 아이디어를 보유한 설립된 지 얼마되지 않은 창업 기업이다.

위키백과에서 말하는 스타트업의 정의이다.

사실 이것만 가지고 설명이 되기는 힘들다.

예로 동네 고기집은 스타트업이라고 하지 않는다.

동네 고기집은 왜 스타트업이라고 하지 않을까?

아무리 장사가 잘되도 가게에 비치된 테이블 이상으로 돈을 벌 수없다.

즉 어느 시점으로 폭발적인 성장이 불가능 하다.

스타트업은 다르다. 성장하다 보면 어느 시점에서

폭발적인 성장이 가능하다.

폭발적인 성장은 IT 기술 , 즉 보통은 웹기술을 기반으로

많은 사람들에게 서비스를 제공하면서 이것이 가능하다.

스타트업에는 SW 가 필연적으로 포함되고 굉장히

주요한 요소이다

스타트업에서 가장 중요한게 무엇일까?

어떤 사람들은 좋은 아이디어가 있으면 성공할 수 있다고 말한다.

스타트업들을 멘토링 하거나 많이 만나는 경우가 있는데

의외로 많은 스타트업들이 기획/마케팅/경영의 중심으로 팀빌딩을 한다.

명문대 혹은 해외 유학 경영,경제 쪽 전공의 사람들이 괜찬은 비지니스 아이디어를

 가지고 찾아 옵니다. 

괜찬은 BM 을 가지고 전문가 뺨치게 그럴듯하게 발표도 잘하고

질의응답도 전혀 흠잡을 데가 없이 잘합니다.

그런데 그것을 어떻게 만들것인가? 라고 물어보면

시드 머니를 가지고 '외주 개발' 을 맡긴다고 합니다.

.......

기획도 중요하고 마케팅도 중요하고 경영도 중요하고 재무도 중요합니다.

하지만 개발이 제일 중요합니다.

스타트업에서 어떠한 서비스를 기획하고 빨리 만들어서

시장의 반응을 빨리 확인하고 방향을 수정해야 합니다.

개선하고 피드백 받고 개선하고

이러한 과정을 거처서 점점 현실적이고 가능성이 높은 서비스로 변화하게 된다

이러한 과정에는 어떠한 비용이 발생할까?

웹서비스는 프론트, 백엔드 개발자가 필요하다.

끈임없이 소스코드의 유지보수 과정을 거처야 한다.

수익이 발생할 때 까지 정말 빨라야 1년~3년 , 늦는 다면 5년이상도 걸릴 수 있다.

이런 긴 시간과 수많은 시도에서 개발비용을 어떻게 감당해야 할것인가?

스타터업의 가장 중요한 것은 사실 아이디어가 아니라

실행력(excution) 에 있다고 생각한다!

그 누구도 맨 처음에 완전 무결한 아이디어와 기획으로

수정없이 한번에 성공할 수 없다.

만약 기존에 성공한 모델을 똑같이 카피하지 않는다면 말이다.

그리고 사실 새로운 아이디어? 라는건 거의 없다.

쿠팡이 처음 나올때 서울에만 관련 업체가 700개 정도가 됬다고 한다.

무작위로 성공한 스타트업을 예시로 들어도 유일무이한 아이디어는

정말 찾아보기 힘들다.

결국 아이디어 문제가 아니라 누가 먼저 잘 만들어서 

잘 서비스 하냐의 싸움이라고 본다.

아이디어는 적은 비용으로 빠르게 개발되어야 한다.

유능한 내부 개발자를 보유하면 빠르게 개발하고

시장의 반응을 빨리 확인할 수 있다. 시간이란 비용과

돈을 줄일 수 있다.

외주개발은 많은 비용과 의사소통의 어려움, 

오류를 수정하거나 사소한 기능을 추가하려고 해도

추가 비용을 계속 지불해야 한다.

심지어 글자를 몇개 바꾸는 데도 돈을 달라고 할 것이다.

시간이 지나갈 수록 큰 자금의 압박을 받는다.

미국의 유명한 IT guru인 Guy Kawasaki는 예전에 Forbes와의 인터뷰에서 다음과 같은 말을 했다.

초기기업의 기업가치(valuation)를 산정할 때 사용하는 단순한 법칙이 있다. 풀타임 엔지니어 1명당 50만불 (약 5억원)을 더하고, 풀타임 MBA 1명당 25만불(약 2.5억원)을 빼라

결국 개발자가 있어야 원하는 것을 낮은 비용으로 구현할 수 있고

스타트업에서 좋은 개발자를 얻는 것은 매우 중요하다.

애자일, 코드 오리엔티드, 린스타트, 빠른 최소기능상품 제작 ..

스타트업의 서비스는 IT기술위에 동작하며

그것은 할 수 있는 실행력의 상당 부분이 개발자에게 나오기 때문이다.

필요한 개발인력을 반드시 보유해야 한다.

그렇지 못하면 여러가지 시도를 하는데 어려움이 많다.

Q/A

Q: 약간 개발자 중심의 사고 인거 같기도 하고.. 근데 어떤 개발자가 좋은 개발자 인가요?

그리고 스타트업 멤버로는 어떤 사람이 좋을 까요?

A: 스타트업이란 폭발적인 성장이 가능합니다. 그렇기 위해서는 IT 기술이 필연적으로 필요합니다.

IT 회사는 사실 아이디어 보다 실행력(execution)이 중요합니다.

스타트업은 극도로 높은 리스크와 불확실성 때문에 

상황에 맞게 계속적으로 변화해야 합니다.

이것은 아이디어나 제품의 변화를 의미합니다.

이러한 과정에서 개발자의 능력은 굉장히 큰 부분을 차지 합니다.

좋은 개발자를 찾는것은 상당히 어려운 일입니다.

아는 사람에게 추천을 받을 수도 있고 공개적으로 모집할 수도 있습니다.

좋은 개발자와 좋은 스타트업멤버는 다를 수 있습니다.

회사에서 원하는 좋은 개발자는 원하는 스펙의 제품만 만들어 주면 된다고 생각합니다.

따라서 필요한 제품을 주어진 일정안에 만드는 능력만 있으면 된다고 봅니다.

하지만 공동 창업자의 경우는 다릅니다.

단순 능력은 당연히 중요합니다. 하지만 더 중요한게 2가지 정도 있다고 봅니다.

이것은 개인적인 의견이지만 경험을 통해 어느정도는 갠관적이라고 봅니다.

1. 회사밖에서 독자적으로 상품을 만든 경험이 있는 사람

회사를 오래 다니다 보면 회사의 단점들이 많이 보입니다.

그리고 불만이 생기기도 합니다.

자신이 오너가 되서 아주 작은 상품을 만들어 보면 이것이 얼마나 

어려운 일인지 알게 됩니다.

예를 들어서 안드로이드 마켓에 똥 피하기 게임 이나 테트리스 

의외로 다운로드 수가 높은 것들이 있습니다.

실제로 광고 수익으로 굉장히 많은 돈을 버는 게임 개발자들이 있습니다.

쉬워 보여서 만들어 보면 절대 쉽지 않습니다. 

실제 시장에 내놓는 제품을 만들때는 

해결해야 할 것들이 너무 많고 책임저야 할것도 많습니다.

저는 지인들에게 스터디를 하라고 권유하지 않습니다.

제품을 만들라고 권유합니다.

2. 자신과 비슷한 가치관, 사고를 가진 사람

어쩌면 이것이 첫번째 보다 중요할 수도 있습니다.

회사에서 일을 하다 보면 보통은 수직적인 구조이기 때문에

의사결정에 큰 문제가 없습니다. 

그리고 자신들이 오너가 아니라서 사실 책임지지도 않습니다.

스타트업은 다릅니다. 

정말 많은 스타트업 공동 창업자들이 정말 많이 싸웁니다.

의견이 달라서 너무 많이 싸웁니다.

매 상황마다 최선의 선택을 해야 하는데 

이것은 객관적으로 분석하더라도 불확실성이 너무 높아서

객관적인 지표가 부족한 경우도 많습니다.

종교, 아이폰, 안드로이드, 운동, 취미, 가치관 등등이

비슷하면 비지니스에서도 비슷한 결정을 내릴 가능성이 높습니다.

이런것들이 모여서 사고체계를 형성하고 비슷한 사고방식은

비슷한 결정을 할 가능성이 높습니다.

물론 능력이 전혀 없이 필요 없는 사람을 말하는 것은 아닙니다.

저의 경험으로는 많은 불확실성과 어려움을 극복하고 오래가려면

결국엔 비슷한 가치관을 가진 사람인거 같습니다.

[개발자와 의사소통]

기획자는 새로운 서비스를 기획하고

개발자는 그것을 만들어 낸다.

기획자가 새로운 기능을 추가하고 싶다면

개발자에게 요청한다.

이때 개발자는 기획자에게 다음과 같은 항목에 대해서

알려주면 좋다.

- 소모되는 시간

- 기능 구현 여부

- 리스크

하지만 경험많은 시니어 개발자거나 이미 해당 기능 구현을 해본 경우가 아니라면

이것들은 개발 착수 이전에 정확히 측정하기는 어렵다.

모른다면 당장 말할 수 없고 시도해 보고 1주후에 알려주면 된다.

[효율적인 커뮤니케이션]

소통의 방법에는 여러가지가 있다.

메일을 쓰기도 하고 메신저를 하기도 한다.

급하면 전화를 하기도 하고 더 중요한 일이라면

직접 얼굴을 마주하고 이야기 하기도 한다.

효율적인 의사소통의 방법이라면

적은 비용으로 확실한 의도, 정보를 전달하고

받는 사람또한 그것을 전달자의 의도대로 받아 들이면 된다.

리눅스 토발즈(리눅스 커널, 깃을 최초로 만든사람)이 한 말이 있다.

모든 사람이 사교적이지 않다.

그래서 사람을 마주 대하는 것에 스트레스나 부담감이 있을 수 있다.

꽤 많은 사람에게 해당 되는 말이기도 하다.

그래서 최근에는 고객문의를 전화가 아니라 톡으로 하는 이유도

전화보다 메신저가 더 스트레스를 받지 않고 

시도하는 문턱이 낮다는 이유다.

예를 들어 매니저가 어떠한 일을 개발자에게

요청하였다.

요청 할 때와 그것이 완료 되었을 때 어떤식으로

소통하면 좋을까?

꽤 어렵고 굉장히 중요한 일이라면

대면회의를 하는게 좋을 것이다.

하지만 매번 사소한 것에도 이런 비용을 지속적으로 소모하긴 힘들다.

요즘 소통의 도구에는 굉장히 유용한 여러가지가 있다.

Trello

액션아이템 별로 관리 할 수 있다.

예를들어 kim 이라는 사람의 보드를 To do, Done  2개 만든다.

매니저는 To do 보드에 크고 작은 요청사항을 생성한다.

개발자는 그것을 보고 이상없으면 진행을 하고

추가로 코멘트가 필요하면 코멘트를 달아서 매니저 To do 로 이동시킨다.

그러면 매니저는 요청사항을 수정해서 다시 개발자 To do 로 이동시킨다.

모든 소통을 이것으로 하라는 것이 아니다.

사소한 것 이런 툴로 가능한 것에 전화나 바쁜 사람을 불러서

많은 비용을 소비하지 말라는 뜻이다.

잦은 회의, 전화, 메신저는 업무를 수행하는데

인터럽트를 걸어 낮을 생산성을 가저온다.

Trello API 로 자동화 시켜서 더 편리하게 사용할 수도 있다.

앱이 릴리즈되면 이후 작업을 해야하는 인력들의 To do 보드에

액션아이템이 생성되서 그것을 수행할 수 있다.

Slack

메신저는 가장 많이 쓰이는 의사소통 도구이다.

다른 툴과 연동하여 알람을 받거나 할 수 있다.

웹서비스를 업데이트 할때나, 스케줄이나 이슈가 리포트 되거나

다양한 알람을 받을 수 있고

받고 싶은 알람만 선택해서 받을 수도 있다.

효율적인 커뮤니케이션이란 비용을 줄이자는 것이다.

[형상관리]

프트웨어 형상관리는 Software Configuration Management, 줄여서 SCM라는 단어를 쓰기도 하는데, 

SW개발 및 유지보수 과정에서 발생하는 소스코드, 문서, 인터페이스 등 각종 결과물에 대해 형상을 만들고, 

이들 형상에 대한 변경을 체계적으로 관리, 제어하기 위한 활동이다.

git, svn, perforce(p4) 등 형상관리 시스템이 있다.

[매니저]

개발자를 어떻게 관리해야 하나?

외주 개발은 어떻게 해야하나?

폰트 사이즈 12 고딕

폰트 사이즈 12 고딕

[개발일정/유지보수/이슈관리]

개발업무는 투자 시간 대비 반드시 비례하지 않는다.

100명의 개발자가 1달안에 못하는 일을

단 한명의 슈퍼 개발자가 해내는 경우가 있다.

시간을 무조건적으로 투입하는 경우보다

낭비요소가 없나 방향이 잘못 되지 않았나

체크하는게 더 효율 적이다.

실제 현업 프로젝트에서 필요 없는 일을 하는 경우는 의외로 많다.

다음 7가지 낭비 요소중에 해당되는지 체크해 봐야 한다.

1. 미완성 작업

개발 과정에서 만드는 중간 산출물(분석, 설계문서, 테스트하지 않는 코드등)이

필요한 업무이기는 하지만 고객 관점에서는 가치가 없는 것들이다. 

프로젝트 진행중인 상태에서는 이런 중간 산출물을 최소화할 수 있도록 관리해야 한다.

2. 추가 프로세스

보통 성숙된 기업에서는 사용하는 표준 프로세스가 있다.

이것은 제품을 잘 만들 수 있는 지침서지만 모든 상황에 항상 효율적이지는 않다.

때로는 업무에 발목을 잡는 요소로 작용할 수 있다. 

개발팀에 가치를 주지 못하는 프로세스는 주기적으로 검토하고 개선할 필요가 있다. 

3. 추가 기능

고객이 직접 이야기 하지 않았지만 향후 사용에 대비하여 개발자는 종종 기능을

추가로 넣을 때가 있다. 어쩌다가 한번 사용할지도 모르는 기능을

계속 추가 하면 상당히 비효율적이고 유지보수 비용도 증가한다.

4. 멀티 태스킹

많은 조직에서 한사람이 여러 프로젝트에 관여하는 경우가 많다.

업무 특성상 비슷한 일이고 다른 사람과 연관성도 낮다면 나쁘지 않다.

하지만 반대라면 비효율적인 요소가 많다. 

여러개 업무를 하다보면 업무 전환 비용 이 발생한다.

A 란 프로젝트를 하다가 B로 전환하려면 다시 상황을 이해해야 하고

어디까지 진행되었나 이슈가 무엇이었나? 파악하는데 비용이 소비된다. 

5. 대기시간

개발업무를 진행하다 보면 고객과 여러 분야의 기술자들이 모여서 빠르게

의사결정을 해야 할 일이 생긴다.

이럴때 한 공간안에 있으면 즉시 결정을 할 수 있지만

그렇지 않다면 그때까지 대기시간이 소비된다.

대기하는 동안 다른일을 해야 한다고 생각할 수 있지만

업무를 전환 하는데 비용이 또 소모된다.

이런 낭비 요소는 잘 보이지 않지만 해소했을 때 효과는 매우크다.

6. 이관: 문서 전달

전통적인 프로젝트 문서 지향 프로젝트의 경우 분석, 설계, 구현, 테스트와 같은

순차적 공정에서 단계를 거처 제품을 생산한다.

이때 각 단계마다 전문가가 투입되어서 업무 효율성을 높이려고 하는 것이 일반적이다.

이런 폭포수 모델의 프로젝트는 문서에 모든 내용이 담겨 있다는 것을 전제로 한다.

하지만 고객의 요구사항을 모두 문서에 담기는 정말 어렵고 실제로 담지 못하는 

부분이 많다.

옳바른 요구사항은 초기에 완벽히 나오기 어려우며 

고객과 자주 커뮤니케이션할 때  나타난다.

고객과 빈번한 소통을 해야 하는데 그때마다

매번 문서를 작성하고 전달 받고 그것에 대해 질문하고

이것은 많은 비용이 발생한다. 

7. 결함

제품을 개발할 때 결함은 반드시 발생하며 늦게 발생할수록 

수정하는데 더 큰 비용이 들어간다.

따라서 결함이 발생했다는 것 자체가 낭비요소다.

예를들어 SNS 웹서비스를 출시 했는데 가끔 사진이 업로드 되지 않는다.

크리티컬한 결함이며 이것을 수정할때 까지

고객들은 불편을 느끼고 심지어 이탈자가 발생할 수도 있다.

결함은 조기에 발견하여 수정하거나 아예 결함이 발생하지 않도록 해야 한다.

애자일에서는 개발과 테스트가 분리 되어 진행하지 않고

일체화된 공정 하나로 진행하여 코딩단계부터 결함을 예방한다.

TDD(Test Driven Development)는 이런 기법 중 하나다. 

프로젝트중 애자일로 개발한다면 테스터와 개발자가 밀접하게

소통하는 것을 권장한다.

IT 업계 뿐만 아니라 유지보수 라는 말을 많이 들어 봤을 것이다.

말 그대로의 유지 하고 보수 하는 것이다.

이것이 왜 중요한가? 의문을 가질 수도 있을 것이다.

사실 요즘에는 100% 완성된 형태로

소프트웨어 결과물이 나가는 경우가 없다.

베타버전부터 출시하여 사용자의 반응을 보고 테스트기간을 거치는 경우가 대부분이다.

어떠한 웹서비스가 개발기간이 6개월 이라면

출시후 유지보수 기간은 10년 아니 그 이상이 될 수도 있다.

소프트웨어 생명 주기에서 봤을 때 출시전까지 시간은 고정되있고

유지보수 기간은 계속 증가한다.

때문에 소스코드도 유지보수 하기 좋아야 한다.

가끔 평범한 코딩을 특이하게 잘 쓰지도 않는 프레임워크로 하는 개발자가 종종 있다.

그사람이 더 이상 개발하지 않고 다른 누군가가 이어서 한다면

아마 다시 개발하거나 유지보수 비용은 엄청 증가할 것이다.

이슈관리라는 말은 곧 버그나 수정사항을 의미한다.

이런 이슈들은 테스터에 의해 등록되기도 하고

개발자, 기획자, 매니저에 의해 등록 되기도 한다.

이슈

 

[비용, 생산성]

비용은 돈인가?

생산성은 공장에서만?

폰트 사이즈 12 고딕

폰트 사이즈 12 고딕