큐는 동종의 아이템들(자료형이 같은 것들)만의 그룹이고 새로운 아이템은 큐의 맨끝에 추가되고, 제거 되는 아이템은 맨 앞에서 사라진다.

이러한 특성을 FIFO(First in First Out)이라 부른다. ex). Job buffers, Network buffers

Queue

• Logical level

  • Constructor

    • Class Name

  • Transformer

    • enqueue(value)

    • dequeue( )

    • clear

  • Observer

    • isFull( )

    • isEmpty( )

Queue의 동작설명

• Enqueue( )

  • Queue의 맨 끝인 rear에 추가하고자 하는 아이템의 값을 추가한다.

  • 시간복잡도 : O(1)

• Dequeue( )

  • Option 1 (front의 값을 제거 후 모두 앞으로 당기기)

    • front의 값을 제거한다.

    • 이후 기존의 값들의 위치를 한 칸씩 앞으로 당겨 재정렬한다.

    • 시간복잡도 : O(N)

  • Option 2 (배열을 옮기는 것이 아닌 front가 앞으로 움직인다.)

    • front의 값을 제거한다.

    • 그 후 front가 가리키는 값을 기존의 front에서 한 칸 뒤로 옮긴다.

    • 시간복잡도 : O(1)

    • 순환하는 Queue 구조가 된다.

    • 과연 Option 2는 문제가 없는 방식인가?

    • rear와

  • Circular Queue에서의 동작 구조 설명

큐는 배열로 구현된 선형의 형태를 가진다. 이에 따라, 데이터 삽입/삭제 시 데이터들을 앞 혹은 뒤로 당겨주는 과정이 필요하며, 이는 불필요한 시간 낭비를 불러일으킨다.

이러한 단점을 극복하기 위해 고안된 개념이 'Circular Queue'이다.

• enqueue( )

  • 큐가 가득 차있지 않다면, 아이템을 삽입한다. rear의 위치를 한 칸 옮겨주고, 본래 rear 자리에 아이템을 넣어준다.

  • rear = rear + 1

• dequeue( )

  • 큐가 비어있지 않다면, front를 한칸 옮긴다. 동시에 front에 저장되어 있던 아이템을 반환해준다.

• front = front + 1

• isFull( )

  • front의 값이 rear에서 1개 더한 값과 같다면 Full인 상태라고 판단한다.

  • front == rear + 1

• isEmpty( )

  • front의 값이 rear에서 1개 더한 값과 같다면 Empty인 상태라고 판단한다.

  • front == rear + 1

• 그렇다면 isFull( )인지 isEmpty( )인지 어떻게 구분할 것인가?

  • 해결책 : Reserved Space

    • 실제론 데이터를 보관하지 않는 공간을 만든다.

    • front는 항상 reserved space를 가리키도록한다.

    • Queue가 isFull일 경우 rear+1 == front이다.

    • 즉, (rear+1) % maxQueue == front이다.

    • Queue가 isEmpty일 경우 rear == front이다

    • 한 메모리 공간을 낭비하더라도, Full과 Empty를 구분할 수 있다.

    • reserved space 공간은 Queue크기가 커질 수록 공간에 대한 부담이 줄어든다.

Big - O 시간복잡도 (Queue)

스택은 동종의 아이템들(자료형이 같은 것들)만의 그룹이고 Stack의 맨 위에 아이템을 추가하고 삭제한다.

이러한 특성을 LIFO(Last in First Out)이라 부른다. ex). Undo, Back Browser

Stack

• Logical level

  • Constructor

    • Class Name

  • Transformer

    • Push(value)

    • Pop( )

  • Observer

    • size( )

    • isFull( )

    • isEmpty( )

Stack의 동작설명

• Stack이 비어있는 상태는 어떻게 되는 것일까?

  • Stack의 맨 위의 값(top)이 -1로 설정된다.

• size( )

  • size는 맨위의 값(top)에 1을 더하여 return해준다.

  • 아무것도 없을 때, top = -1 --> -1 + 1 = 0 --> size의 반환 값 : 0

• isFull( )

  • Stack에서 설정한 Max_Size값에서 -1을 뺀 값이 현재 top과 동일하며 True이다.

  • 아닐 경우는 False를 반환한다.

  • 왜 Max_Size에서 1을 빼는가? --> 첫 번째의 값의 인덱스가 0이기 때문이다.

• isEmpty( )

  • Stack의 top의 값이 -1이면 True를 아니면 False를 반환한다.

• push( )

  • Unsorted list의 appendItem가 유사한 동작방식이다.

  • isFull일 경우 아무것도 반환하지 않는다.

  • 만약 isFull이 아니라면, top의 값에 1을 더한 후, data[top]에 추가하고자 하는 value를 붙인다.

  • 시간복잡도 : O(1)

• pop( )

  • isEmpty일 경우 아무것도 -1을 반환한다.

  • isEmpty가 아닐 경우 반환하고자 하는 맨 꼭대기의 값을 변수에 저장한다.

  • 이후 top의 값에서 1을 뺀 후, 변수를 반환한다.

  • 시간복잡도 : O(1)

Big - O 시간복잡도 (Stack)

Class Template

Stack은 한 종류의 자료형만을 저장할 수 있는 구조(homogeneous)이다.

하지만 여러 형태의 자료형(int, char, bool)을 저장하고 싶다면 어떻게 해야할까?

이때 도와주는 것이 Class Template이다.

• Class Template

  • Type Parameters를 활용하여, 다양한 버전의 class type를 생성하도록 해준다.

  • 형식적인 parameter는 class template의 정의에서, 실제 parameter는 client code에서 나타난다.

  • 둘다 < >로 둘러 쌓여있다는 것을 기억해야한다.

• Class Template 사용법

  • Template의 실제 parameter가 data type이다.

  • 어떤 타입을 사용한든, 내재된거나, 유저가 정의한 것들 중 하나여야한다.

  • Class Template를 제작할때, 반드시 헤더 파일을 포함해야한다.

Pointer

• 메모리의 할당 방법

  • 변수가 선언 될때, 값이 할당될 수 있도록 충분한 메모리 공간이 마련된다.

  • int : 4byte / float : 4byte / char : 1byte

• 메모리의 주소(Memory Addresses)

  • array가 아닌 변수의 주소는 '&'를 통해 확인할 수 있다.

• Pointer Variable

  • 메모리에서 주소의 위치 값을 나타내는 변수이다.

  • 포인터 변수를 선언하기 위해선 반드시, 값의 타입을 명시해야한다.

    • int * ptr : 정수형 포인터
    • char * ptr : 문자형 포인터

  • int x = 12; int * ptr = &X;

    • 이 경우 x의 주소를 ptr이 그리고 ptr은 x를 가리키고 있다고 말한다.

    • ptr로 가리켜진 값은 *ptr로 표시된다.

  • 포인터의 변수는 어떤 형태인든 크기가 8byte로 동일하다.

- null Pointer (nullptr)

  - 포인터를 표현하는 값 중에 "널을 표현한 값"이다

  - 하지만 Null은 메모리 주소 0을 가리키는 것은 아니다.

  - "포인터가 아무것도 가리키지 않은 상태"를 의미한다.

  - NULL과 nullptr차이

    - C++11부터 도입된 nullptr은 포인터 타입의 널 값을 의미하며 정수 0과 구분되는 명확한 타입이다.

    - 반면 NULL은 정수 0으로 정의된 매크로로, 함수 오버로딩 시 int로 취급되어 예기치 않은 오류를 유발할 수 있다.

    - 이러한 NULL의 단점을 보완하고자, nullptr이 등장한다.

Memory Allocation

• Process Memory Map

  • 프로그램을 메모리에 적재할 때 프로세스의 요소들을 배치하는 방식.

  • 스택 영역 (Stack Area)

    • 스택영역으로 할당된 부분은 스택 방식으로 작동. : LIFO방식

    • 메모리의 정확성을 유지하기 위해 stack 방식을 사용.

  • 힙 영역 (Heap Area)

    • 프로그램 실행 중(런타임)에 동적으로 할당되는 데이터(객체, 배열 등)를 위한 메모리 영역.

    • address를 Stack 영역에 참조 데이터 타입(Reference Data Type)으로 만들어서 그것을 reference해서 사용.

  • 데이터 영역 (Data Area)

    • 프로그램의 전역 변수(Global)와 정적(Static) 변수가 저장되는 메모리 공간.

    • BSS (Block Stated Symbol) // Data Segment (Initialized Data)이 존재.

  • Text(Code) 영역

  - 프로그램의 실행 가능한 코드들을 포함하고 있는 영역.

추가 개념

• Dynamic Allocation (동적 할당)

  • 프로그램 실행 중(런타임)에 필요한 만큼의 메모리(힙 영역)를 운영체제로부터 할당받아 사용하는 기술.

  • 필요한 만큼만 메모리를 사용하므로 자원을 효율적으로 관리가 가능하다.

  • 하지만, 할당한 메모리는 반드시 프로그래머가 삭제해야하며, 그렇지 않을 경우 메모리 누수가 발생할 수 있다.

• Linear relationship

  • 각각의 요소들은 첫 번째를 제외하면, prdecessor(전임자)가 있고, 마지막을 제외하면, successor(후임자)가 있다.

• Length

  • 리스트안의 항목들의 갯수들이다.

Unsorted List

• Unsorted List : 리스트의 아이템이 정렬되지 않은 리스트를 의미한다.

• Logical level

  • Constructor

    • Class Name

  • Transformer

    • appendItem(value)

    • insertItem(pos,value)

    • removeItem(value)

    • updateItem(pos,new_value)

    • clear()

  • Observer

    • size()

    • isFull()

    • isEmpty()

    • findItem(item)

    • getItem(pos)

<리스트 그림>

Unsorted List의 동작설명

• appendItem()

  • 넣고자 하는 리스트에 isFull()인지 확인을 한다.

    • isFull이면 아무것도 리턴하지 않는다.

  • 이후 현재 data의 length(아이템 갯수)의 인덱스를 통해 새로운 값을 넣는다.

  • 이후 length에 1을 더해 length을 최신화 해준다.

• insertItem()

  • 넣고자 하는 리스트에 isFull()인지 확인을 한다.

    • isFull이면 아무것도 리턴하지 않는다.

  • 이후 원하는 위치의 인덱스에서 부터 뒤까지 한 칸씩 value를 뒤로 이동시킨다.

  • 그리고 리스트에 넣고자 하는 위치에 사용자가 지정한 value값을 다시 붙인다.

  • 이후 length에 1을 더해 length을 최신화 해준다.

• appendItem() vs insertItem()

  • appendItem은 item의 value를 리스트의 맨 마지막에 추가해준다.

  • insertItem은 item의 value를 사용자가 원하는 특정한 위치에 추가해준다.

  • 시간복잡도는 insertItem이 더 오래 걸린다.

  • appendItem() -> O(1) // insertItem() -> O(N)

• insertItem()은 O(N)이 최선인가?

  • insertItem의 시간복잡도가 O(N)이 최선이지 않다.

  • new_insertItem()의 동작

    • 새롭게 추가하고자 하는 Item의 위치의 원래 값을 리스트 맨 뒤로 이동시킨다.

    • 그 후 추가하려는 value를 사용자가 원하는 위치에 값을 붙인다.

  • 리스트의 맨 뒤로 이동하는 시간 복잡도 = O(1)

  • 사용자가 원하는 위치에 값을 붙이는 시간 복잡도 = O(1)

  • 최종 시간 복잡도 O(1+1) = O(2) = O(1)

• removeItem()

  • 리스트에 제거하고자 하는 Item의 위치를 찾는다 --> K라 가정

  • 이후 K번째 값으로 한 칸씩 앞으로 당긴다. --> N - K번

  • 리스트의 전체 길이 length의 값에서 1을 뺀다. -- 1번

  • 최종 Big - O 값 : O( N - K + 1 ) = O( N )

• removeItem()은 O(N)이 최선인가?

  • removeItem의 시간복잡도가 O(N)이 최선이지 않다.

  • new_removeItem()의 동작

    • 없애고자 하는 Item의 위치의 원래 값에 리스트 맨 뒤의 값을 적용시킨다.
    • 그 후 리스트의 전체 길이 length의 값에서 1을 뺀다.

• updateItem()

  • update하고자 하는 위치가 length보다 크거나 같으면 그냥 return한다.

  • 그렇지 않을 경우 리스트의 위치에 새로운 값을 덧붙인다.

  • 시간복잡도 : O(1)

• clear()

  • length의 값을 0으로 전환한다.

  • 시간복잡도 : O(1)

• findItem()

  • 리스트의 인덱스 값을 0으로 초기화한다.

  • 인덱스 값이 length보다 작을 때까지 리스트의 item에 유저가 원하는 item이 있는지 확인하고 있으며, True, 없으면 False를 반환한다.

  <pop과 append의 설명 그림>

Sorted List

• Sorted List : 리스트의 아이템이 정렬의 기준(key)을 가지고 의미 있는 관계로 배열된 리스트를 뜻한다.

  • Key : 정렬의 기준이자 논리적 순서를 결정하는 속성이다. ex). 나이, 성별...

Sorted List 동작설명

• insertItem()

  • 추가하고자 하는 Item의 적절한 위치를 찾아낸다. --> N번 가정

  • 한칸씩 나중 item들의 위치를 옮겨준다. --> N-K라 가정

  • 사용자가 원하는 아이템을 추가해서 넣는다. --> 1

  • 리스트의 length값에 1을 더해준다. --> 1

  • 시간 복잡도 : O(2N + 2 - K) = O(2N) = O(N)

• finditem()

  • 기본적인 동작 : 선형탐색

  • 리스트의 모든 Item들을 하나씩 비교해가며, 찾아본다.

    • 시간 복잡도는 O(N)이다.

  • 이게 최선의 방법(선형탐색)일까?

    • search scope(검색 범위)를 좁히면 개선되지 않을까?

  • Binary Search (이진 탐색)

    • Mid : 리스트의 중앙값(길이 length의 절반 인덱스의 위치하는 값)

    • First : 리스트의 처음 값, Last : 리스트의 맨 마지막 값.

    • 찾는 값이 중앙값보다 작으면 Last = Mid - 1로 재설정한다.

    • 찾는 값이 중앙값보다 크면 Last = Mid + 1로 재설정한다.

    • 이런 식으로 반복하다 First가 Last보다 큰 경우일 경우 False로 리턴한다.

  • Binary Search는 얼마나 개선되었는가?

    • length가 1000이라면 최악의 경우에도 약 10번의 계산이 걸린다.

    • 2^k = N --> K = log(N) // (2는 생략 가능)

    • 선형일 경우 1000번 걸릴 것이 10번으로 줄어들었다. 100배의 효과.

Big - O 비교(리스트의 동작)

추가 개념

• ADT의 동작 방식 기본 개념

  • Constructor : ADT의 새로운 object를 만든다.

  • Transformer : object의 하나 이상의 데이터 값의 상태를 변경한다.

  • Observer : object의 변형없이 데이터의 상태를 관찰한다.

• Class Constructor

  • class가 만들어질때, 암묵적으로 호출되는 특별한 멤버 함수이다.

  • 리턴할 value의 type가 없다.

  • 한 class는 여러개의 constructor들을 가질 수 있다.(overloading)

  • 파라메타가 없는 constructor가 기본 설정이다.

• Time Complexity (시간 복잡도)

  • 효율적인 프로그램이란?

    • 시간을 더 짧게 사용하고, 컴퓨터 자원을 더 적게 사용하는 것이 효율적이다.

    • 계산(computations)이 많을 수록 시간이 더 많이 걸린다.

  • Big - O 표기법

    • 흔히 시간복잡도를 계산할 때, 최악의 경우를 산정하고 계산한다.

    • 규칙1 : 앞의 계수는 무시한다. -> O(2N) = O(N) // O(2) = O(1)

    • 규칙2 : 작은 단위는 무시한다. -> O( N + 1 ) = O( N )

<Big - O 표기법 그래프 비교>

<Big - O 표기법 그래프 설명>

추상화(abstraction)이란, 시스템의 viewer의 관점에서 필수적인 세부사항들만 포함하고 있는, 복잡한 시스템의 모델이다.

즉, 프로그램들은 추상화이다. -> 우린 프로그램이 무엇(what)인지 알아도, 어떻게 동작하는 지는 모른다.

Abstract Data Type(ADT)

자료 자체의 형태와 그 자료에 관계된 연산들을 수학적으로만 정의한 것.

• ADT는 DATA + Operations로, 어떤 형태로 보관하고, 어떻게 접근하며 검색하고 계산할지에 대한 것이다.

예시 Python - list

test = []

test.append(1)
test.append(3)
test.append(5)

print(test)

test.remove(5)

print(test)

test라는 리스트의 요소들이 어떻게 출력될지 예상이 되는가? => [1,3,5] // [1,3] 이렇게 출력이된다.

하지만 test라는 리스트의 요소들이 어떻게 리스트에 추가되고, 빼지는지 동작 상으로 알 수 있는가? => 모른다. 그저, 함수를 통해 리스트의 자료를 추가하고 뺄 뿐이다.

• 그렇다면 리스트와 같이 자료가 어떻게 넣어지고 빼지는 지 동작에 대해 일일이 알아야하는가?

  • 아니!! 그럴 필요없다!!!

  • 우린 이미 동작하는 방식을 알고 있다. 어떻게 동작하는지를 모를 뿐이다.

  • 자동차를 몰기 위해서 자동차 엔진이 어떻게 바퀴를 굴리는지 알 필요가 있는가?

Information Hiding (정보은닉)

객체에 대한 구체적인 정보를 노출시키지 않도록 하는 기법. / 필수적인 것에만 접근하도록 허용하고 나머진에는 접근을 금한다.

오로지, public 상호작용과 방식으로만 접근이 허용된다.

캡슐화(encapsulation)과 유사하다.

• 방금전 리스트를 떠올려보아라.

    test = []

    test.append(1)
    test.append(3)
    test.append(5)

    print(test)

    test.remove(5)

    print(test)

• 실제 test 리스트가 어떻게 동작하는가?

    typedef struct {

        PyObject_VAR_HEAD
        PyObject **ob_item;
        Py_ssize_t allocated;
    } PyListObject

-> 우린 실제로 **ob_item에 접근할 수도, 수정할 수도 없다. : Information Hiding

Data Structure

자료구조란, 대량의 데이터를 효율적으로 저장, 조직, 관리, 수정하기 위해 논리적 규칙에 따라 데이터를 배치하는 구조를 뜻한다.

• 자료구조의 특징들

  • 여러 데이터들의 집합체인 만큼 구성 요소로 분해될 수 있다.

  • 각각의 요소들을 어떻게 배치하냐에 따라, 접근 방식이 달라진다.

  • 배치와, 그들에게 접근하는 방식은 캡슐화가 되어있다.

Composite Data Type (복합 데이터)

복합 데이터란, 각각의 데이터 구성요소가 하나의 변수 이름 아래에 저장될 수 있는 데이터 타입을 의미한다.

개별 데이터 요소들을 접근하는 것을 허용한다

• 예시

  • Array (structured) - homogenous

  • Class (unstructured) - unhomogenous

  • Struct (unstructured) - unhomogenous

Memory Allocation

• 우리가 사용하는 PC는 어떻게 프로그램을 돌리는 것인가?

  Memory Allocation - Variables

  프로그램이 실행될 때, 운영체제는 자동적으로 프로그램이 필요한 메모리를 할당해준다.

  object가 만들어진다면, 멤버들을 위한 메모리 공간이 할당된다.

  -> 이때 이 메모리를 보다 효율적이고, 안정적으로 프로그램이 돌아갈 수 있도록 최적화된 메모리 운영방식에 '자료 구조'개념이 필요하다.

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

추가 개념

One - Dimensional Array

• 1차원 배열은 유한한 크기의 특정 데이터만 저장이 가능하다.

• 각 요소들의 위치는 직접적으로 접근이 가능하다. (인덱스 개념 사용)

  

• Address[index] = BaseAddress + Index * Size Of Element

• BaseAdress는 첫 번째 요소의 메모리 위치이다.

Two - Dimensional Array

• 2차원 배열은 유한한 크기의 특정 데이터만 저장이 가능하다.

• 각 요소들의 위치는 직접적으로 접근이 가능하다. (인덱스 개념 사용)

• 각각의 위치는 행과 열의 개념으로 한 쌍의 인덱스의 값이 저장되어 사용된다.

• 메모리에선 2차원 배열이 선형으로 일직선 형태로 저장된다.

• Address[row][col] = BaseAddress + (row x column 길이' + guswo colmun) x Size Of Element

Man - Month

Man - Month : 사람(man)수를 달(month)수로 계산한 값. 즉, 어떤 업무를 수행함에 있어 필요한 사람의 수에 대한 측정치. -> 사람들의 실력은 동일하고 노동의 강도는 동일하다는 가정.

• Man - Month가 높을 수록 프로젝트의 성공률과 속도가 향상되는가?

  • 절대로 아니다. 오히려 악영향을 미칠 수 있다.

  Man - Month의 역설

• Brooks의 법칙에 따르면 manpower을 추가할 수록 프로젝트는 더 늦게 출시된다.

• 이유 :

  • 사람을 추가 투입하면 그에 따른 새로 추가 투입된 사람들(개발자)에 필요한 준비과정, 비용 등이 많이 소모되기 때문이다.

  • 공식 : n(n-1)/2 - 그룹간 상호 커뮤니케이션 공식

No silver bullet

• 한 번에 해결할 수 있는 수단 및 방법은 없다.

• 지속적인 개발과 유지보수가 필요하다는 의미이다.

The second - system effect

• 개발자들의 특성에 대한 내용으로, 개발자들은 기존의 시스템을 개선 시킬 때 over-engineering을 한다.

Irreducible number of errors

• 개발자들은 개발할때 버그에 대한 두려움을 잊어야한다.

• 개발하면서 버그가 0개일 순 없다. -> 받아들여야할 버그는 받아들여라.

Conceptual integrity

• 설계 철학을 위배해선 안되고, 모두 일관되게 생각하고 행동하라.

• 아무리 혁신적인 아이디어가 도출되었다 하더라도, 그것이 전체 프로젝트의 설계 철학에 위배된다면 받아들여서는 안된다.

The manual

• 최고 설계자는 시스템의 설명사항에 대한 메뉴얼을 만들어놔야한다.

• 그리고 이러한 메뉴얼은 시스템의 외부 설명도 상세히 명시되어야한다.

The pilot system

• 본격적인 본 시스템(Final System)을 구축하기 전, 제한된 범위에서 핵심 기능과 구조를 실제와 유사한 환경에서 시험적으로 구축하여 운영해보는 과정이다.

• 시장에 전시할 상용프로그램을 한 번에 만들 수 없으니, 작은 단계에서 천천히 사용 단계까지 이끌어가자.

Formal documents

• 모든 프로젝트 매니저는 반드시 작더라도, 핵심적인 공식 문서를 만들어야한다.

• 이 공식 문서에는 프로젝트 목적, 어떻게 목적을 성취했는지, 누가 성취할 것인지 언제 성취할 것인지, 비용은 얼마나 드느지에 대한 내용을 포함해야한다.

Project estimation

• 프로젝트를 완성하는데 걸리는 시간 및 비용을 계산하거나, 견적을 낼때 개발자는 최소 3배 이상의 비용과 시간이 걸린다는 것을 감안하고 계획해야한다.

Communication

• 재앙(불협화음)을 피하기 위해선 팀간의 의사소통은 덧없이 중요하다.

• 자신의 부족함이 무엇인지 알리고, 팀원 간의 얘기를 많이 해서 서로가 필요한 부분에 적재적소 들어가 도움을 주고 받아라.

The surgical team(소방수 팀)

• 프로젝트를 진행함에 있어 반드시, 심각한 문제가 발생하는 구간이 있다.

• 그런 상황에 급히 소방수팀(surgical team)을 투입시켜라. 그들은 일반적인 프로그래머에 비해 실력이 월등히 높은 사람들로 선별하라.

오픈소스의 정의

오픈소스란 라이선스 방식을 통해 배포된 소스 코드를 자유롭게 복사, 수정, 사용, 재배포 할 수 있는 소프트웨어를 지칭함.

오픈소스는 누구라도 버그를 수정하거나, 코드를 개조하여 기능을 추가할 수 있으며, 소프트웨어 개발에 참여할 수 있음

오픈소스는 개발자에게 프로그램 배포 권리, 소스코드 접근 권리, 소스 코드 수정 권리를 제공함

오픈소스 선택 시 고려 사항

• 품질

  • 기능, 성능, 호환성 등 오픈소스의 품질은 오픈소스를 선택하는데 가장 중요한 요소이다.

  • Github에 호스팅하는 프로젝트라면, Star수, Fork수로 오픈소스의 완성도를 가늠할 수 있다.

  • 오픈 소스를 사용하려는 기술 조직은 당연히 충분한 기능과, 성능 검증을 수행한 후 제품/서비스에 도입해야한다.

• 커뮤니티

  • 커뮤니티는 오픈소스가 얼마나 많은 사용자를 보유하는지, Issue 관리는 이루어지는지, 지속적으로 업데이트를 하는 지 등 커뮤니티 활성화 여부.

• 문서화

  • 오픈소스를 적절히 도입하고 유지보수하기 위해 프로젝트가 얼마나 문서를 충실하게 제공되는지 확인.

  • 문서화가 잘 된 프로젝트의 산출물은 기업이 도입하는데 수월.

• 보안 취약점

  • 오픈소스 보안 취약점이 알려진 오픈소스는 사용해선 안됨.

  • 보안 취약점이 발견된 오픈소스의 버전은 CVE 등 데이터베이스에서 관리.

• 라이선스

  • 오픈소스 라이선스는 소프트웨어를 누구나 자유롭게 사용할 수 있는 권리르 부여하는 허가증.

  • 대부분의 라이선스는 오픈소스를 재배포시 준수해야할 의무사항을 요구.

오픈소스 법적 책임

오픈소스에 대한 법적 책임과 이에 따른 위험을 제대로 숙지하지 못할 경우, 사용권리 박탈과 제품을 판매 불가할 수 있음.

오픈소스 라이선스

일반 상용소프트웨어와 마찬가지로 오픈소스에도 저작권 등 지식 재산권이 있으며, 권리자의 허락 없이 함부로 사용하면 소송을 당할 수 있다.

오픈소스 권리자들은 많은 사람들이 사용할 수 있도록, 광범위한 라이선스 부여.

오픈소스 라이선스의 주요 의무 사항

• 저작권 표시 및 라이선스 고지

  • 개발자 또는 기여자에 관한 사항과 저작권에 관한 사항을 제품에 표시하거나, 포함하도록 요구한다.
  • 이용자들이 오픈 소스에 관한 권리를 잘 이해할 수 있도록 배포자로 하여금 해당 라이선스의 사본을 함께 첨부할 것을 요구하고 있다.

• 소스코드 공개

  • 대표적인 GPL계열의 라이선스는 바이너리 형태로의 소프트웨어 배포를 허용하는 대신, 바이너리에 해당하는 소스코드를 함께 공개할 것을 요구한다.

• 재배포시 동일 라이선스 적용

  • 라이선스에 따라 큰 차이를 보이는 부분은 'Copyleft'사항이다. 수정된 소프트웨어도 동일한 Lincense로 배포할 것을 요구한다.

오픈소스 라이선스 명시

• 소스 코드 파일 상단의 주석
• 오픈소스 소프트웨어 내 License파일
• 오픈소스 전용 웹사이트를 통한 라이선스 공개

여러가지 오픈소스 라이선스

• 아무조건 없이 사용할 수 있는 라이선스

  • 예시

    • Creative Commons Zero v1.0 Universal (CC0-1.0)

    • The Unlicense (Unlicense)

• Permissive License

  • 오픈소스 라이선스의 고지 의무가 있으며, 비교적 수월하게 준수할 수 있다.

  • 예시

    • Apache License 1.1 (Apache-1.1)

    • Apache License 2.0 (Apache-2.0)

    • BSD 2-Clause "Simplified" License (BSD-2-Clause)

    • BSD 3-Clause "New" or "Revised" License (BSD-3-Clause)

    • Json License (JSON)

    • Microsoft Public License (MS-PL)

    • PostgreSQL License (PostgreSQL)

    • zlib License (zlib)

• 주의가 필요한 Copyleft 라이선스

  • GPL(GNU General Public License)은 오픈소스 재배포 시 소스 코드 공개를 요구함.

  • Copyleft 라이선스 유형은 오픈소스 라이선스 중에 요구하는 의무사항이 가장 많은 라이선스 유형이기 때문에 주의가 필요함.

  • 소스 코드를 직접 제공하거나, 사용자가 요청시 소스 코드를 제공하겠다는 서면 약정서를 제공.

  • 예시

    • GNU General Public License v2.0 (GPL-2.0)

    • GNU General Public License v3.0 (GPL-3.0)

  • 우회방법

    • 자사 코드 분리 방법 : Copyleft라이선스 유형의 라이선스가 적용된 오픈소스는 개발자가 소속한 회사가 배포하는 제품에 포함시 주의해야한다.

    • 따라서 오픈소스는 설계 단계에서 Build시 자사 소프트웨어와 통합되지 않고 Runtime에도 독립된 프로세스로 동작하도록 한다.

• Weak Copyleft 라이선스

  • Weak Copyleft는 Copyleft 유형의 라이선스에 비해 공개 범위가 약하다.

  • 우회방법

    • LGPL Library - Dynamic Link 사용

    • LGPL도 재배포시 소스 코드 공개를 요구함.

    • 하지만 Library형태의 LGPL하의 오픈소스를 Link형태로 결합할 경우, LGPL Library 부분만 소스 코드를 공개하면 되고, 결합하는 코드는 공개 의무가 없다.

  • 예시

    • GNU Lessor General Public License v2.0 (LGPL-2.1)

    • GNU Lessor General Public License v3.0 (GPL-3.0)

• 사용 제한 라이선스

  • 비상업용 라이선스

    • 연구, 학습 만을 위해서라고 해도 영리 회사 내에서 사용한다면 상업적인 활동으로 간주.

 - 예시

   - Creative Commons Attribution Non Commercial 4.0 International (CC-BY-NC-4.0)


 - Network 서비스 제한 라이선스

   - Network 서비스도 배포로 간주하여 의무사항 준수를 요구.

   - Network 서비스를 제공하는 서버에 AGPL로 공개된 오픈소스가 포함되어 있을 경우, 소프트웨어를 배포하지 않아도, AGPL 오픈소스 뿐 아니란 다른 소프트웨어의 소스코드까지 공개해야함.

 - 예시

   -  GNU Affero Genral Public License v3.0 (AGPL-3.0)


 - 광고 조항 포함 라이선스

   - 오픈소스의 기능,활용을 언급하는 모든 광고에 특정 문구를 포함..

• 소스코드 제공 의무 유형

  • Work Based on the Code

    • 제공의무 : 원 저작물의 소스코드를 원본 그대로, 혹은 수정하여 새로운 SW에 포함하였을 경우

    • 제공범위 : 원 저작물의 소스코드가 포함되어, 파생 저작물로 인정되는 범위내의 모든 소스코드

 - Derivative Work

   - 제공의무 : 원 저작물의 소스코드를 수정하여 사용한 경우 제공의무가 존재하며, 수정 없이 그대로 사용하였을 경우에는 소스코드를 제공하지 않아도 됨

   - 제공범위 : 원 저작물의 사용함에 있어, 수정을 거쳤을 경우, 원 저작물의 소스코드에서 부터 존재하던 파일을 모두 공개.


 - File

   - 제공의무 : 원 저작물의 소스코드를 원본 그대로, 혹은 수정하여 새로운 SW에 포함하였을 경우.

   - 제공범위 : 원 저작물의 사용함에 있어, 수정을 거쳤을 경우, 원 저작물의 소스코드에서 부터 존재하던 파일 중 수정된 부분을 포함하는 파생 저작물을 모두 공개.


 - Module

   - 제공의무 : 원 저작물의 소스코드를 원본 그대로, 혹은 수정하여 새로운 SW에 포함하였을 경우.

   - 제공범위 : 원 저작물의 사용함에 있어, 수정을 거쳤을 경우, 원 저작물의 소스코드에서 부터 존재하던 파일 중 수정된 부분을 포함하는 모듈을 모두 공개.


 - File Derivative Work

   - 제공의무 : 원 저작물의 소스코드를 수정하여 사용한 경우 제공의무가 존재하며, 수정 없이 그대로 사용하였을 경우에는 소스코드를 제공하지 않아도 됨.

   - 제공범위 : 원 저작물의 소스코드에서부터 존재하던 파일 중 '수정된 부분을 파일 단위'로 공개.

 - Module Derivative Work

   - 제공의무 : 원 저작물의 소스코드를 수정하여 사용한 경우 제공의무가 존재하며, 수정 없이 그대로 사용하였을 경우에는 소스코드를 제공하지 않아도 됨.

   - 제공범위 : 원 저작물의 소스코드에서부터 존재하던 파일 중 '수정된 부분을 모듈 단위'로 공개.

• 대표적인 오픈소스 라이선스

  • Apache License

    • 아파치소프트웨어재단이 본인들의 SW에 적용하기 위해 만든 라이선스

    • 소스코드 공개 의무같은 의무사항은 없지만, 아파치 라이선스 소스코드를 수정해 배포하는 경우 "아파치 라이선스 버전 2.0"을 꼭 포함시키고, 아파치 재단에서 만든 소프트웨어임을 밝혀야 함.

- GNU(Gnu is Not Unix) General Public License(GPL)

   - 자유소프트웨어재단에서 만든 라이선스

   - 카피레프트 조항을 포함하고 있다.

   - GPL 프로그램은 어떤 목적으로, 어떤 형태로든 사용할 수 있지만 사용하거나 변경된 프로그램을 배포하는 경우 무조건 동일한 라이선스 즉, GPL로 공개.

 - GNU Affero GPL(AGPL)

   - GPL을 기반으로 만든 라이선스로 버전 1,2,는 아페로, 가장 최신버전인 3은 자유소프트웨어재단에 의해 개발.

   - 서버에서 프로그램을 실행해 다른 사용자들과 통신하면, 실행되고 있는 프로그램의 모든 소스코드를 사용자들이 다운로드 할 수 있게 해야한다는 조항을 포함.

 - GNU Lesser GPL(LGPL)

   - 좋은 자유 소프트웨어 제품이 더 많이 쓰이고, 표준이 되도록 유도하기 위해 단순한 라이브러리 모듈 링크를 허용한 라이선스.

   - 너무 강력한 철학이 담긴 GPL의 카피레프트 조항을 보완하기 위해 만든 라이선스로 자유소프트웨어를 지향하짐만 GPL이 오히려 자유소프트웨어의 철학을 훼손한다는 생각에서 나온 라이선스.

   - LGPL 라이브러리를 정적 링크하는 애플리케이션을 배포하는 경우에는 LGPL 라이브러리의 소스코드와, 애플리케이션의 오브젝트 코드도 공개해야한다.

   - LGPL 라이브러리를 동적 링크하는 애플리케이션을 배포하는 경우에는 LGPL 라이브러리의 소스코드를 공개해야한다. 하지만 애플리케이션의 오브젝트 코드도 공개할 필요는 없다.

 - Mozila Public License (MPL)

   - 모질라 공용 허가서는 과거 넷스케이프 웹브라우저의 소스코드를 공개하기 위해 개발된 라이선스.

   - MPL의 특징은 소스코드와 실행파일의 저작권을 분리했다는 부분이 있다.


 - MIT License

   - MIT에서 개발한 라이선스로, 라이선스와 저작권 관련 명시만 지켜주면 되는 라이선스이며, 가장 느슨한 조건을 가진 라이선스 중 하나이다.

 - Berkeley Software Distribution(BSD) License

   - 버클리 캘리포니아 대학에서 배포하는 공개 SW라이선스.

   - 공공기관에서 만들어낸 것으로 공익성이 강하다. 따라서 아무런 제한 없이 누구나 자신의 용도에 사용할 수 있다.

   - 라이선스 및 저작권 표시 조건 외엔 제약이 없는 굉장히 자유로운 라이선스 중 하나이다.

Design Pattern이란 무엇인가?

Design Pattern이란, Product-ability와 Reliability를 높이기 위한 Re-usability이다. 여기서 Re-usability의 범위는 언어, 표준 라이브러리, 오픈 소스 등의 다양한 범위를 가진다.

Software Design Pattern

• 일반적으로, 흔히 발생하는 문제를 주어진 맥락에서 해결할 수 있도록 하는 재사용가능한 해결책이다.

• 디자인 패턴은, 사용자(개발자)가 application이나, system을 설계할 때 발생하는 문제를 해결하기 위한 최고의 방법들이다.

• Design Pattern은 computer Programming에 있어서 구조화된 접근 방식이다.

Object-Oriented Design Pattern

클래스들과 Objects들 사이에 관계 혹은 상호작용들을 보여준다.

• 여러 가지의 OOD Pattern

Adapter Pattern

• Adapter design pattern은 다음과 같은 문제를 해결해준다. (예시)

  • client가 원하는 인터페이스를 어떻게 재사용할 수 있을까?
  • 인터페이스 작업을 어떻게 상호 연결할 수 있을까?

• 한 클래스의 인터페이스(Adaptee)를 클라이언트에서 사용하고자하는 다른 인터페이스(Target)로 변환한다.

  • 이렇게 할 경우 인터페이스를 다시 만들 필요 없이 간단하게 전환하여 재사용이 가능하다.

  • Adapter Pattern 그림 (UML)

  • UML이란? (Unified Modeling Language)

    소프트웨어 집약 시스템의 구조와 행동을 시각적으로 명세화, 설계, 문서화하는 표준화된 범용 모델링 언어.

  • 선의 의미

  

Facade Pattern

• 복잡한 클래스 라이브러리에 대해 사용하기 편하게 간편한 인터페이스(API)를 구성하기 위한 구조 패턴이다.

• Facade Pattern은 다음과 같을 때 사용한다.

  • 시스템이 너무 복잡하다.
  • 간단한 인터페이스를 통해 복잡한 시스템을 접근하고자 한다.
  • 시스템을 사용하고 있는 외부와 결합도가 너무 높을 때 의존성 낮출 것이다.

• Facade 장점

  • 하위 시스템의 복잡성에서 코드를 분리하여, 외부에서 시스템을 사용하기 간단해진다.

  • 하위 시스템 간의 의존 관계가 많을 경우 이를 감소시키고 의존성을 한 곳으로 모을 수 있다.

  • 복잡한 코드를 감춤으로써, 클라이언트가 시스템의 코드를 모르더라도 Facade 클래스만 이해하고 사용 가능하다.

  

Decorator Pattern

• 대상 객체에 대한 기능 확장이나 변경이 필요할때 객체의 결합을 통해 서브클래싱을 사용할 수 있다.

• 이러한 Decorator Pattern은 동적 할당하며, 실시간 동안 추가되거나 삭제되어야한다.

• Decorator Pattern 장점

  • 서브클래스를 만들때보다 훨씬 더 유연하게 기능을 확장가능.

  • 객체를 여러 데코레이터로 래핑하여 여러 동작을 결합.

  • 컴파일 타임이 아닌 런타임에 동적으로 기능을 변경.

  

• Decorator Pattern의 대표적 예시 : 게임

  • 무기 및 아이템 강화

  • 캐릭터 버프 및 상태 이상

    • 이러한 요소들을 통해, 각각의 클래스를 따로 구현할 필요성이 사라진다.

Design Pattern의 역사

1977~79년 Chritopher Alexander에 의해 창시되었다.

이후 1987년 Ward Cunningham과, Kent Beck이 OOPSLA 컨퍼런스에 5가지의 Design Pattern을 발표한다.

1994년 Gang of Four(GoF)이라는 네 명의 개발자가《Design Patterns: Elements of Reusable Object-Oriented Software》라는 책을 발간하며, 전 세계 개발자들의 '성경'이라 불린다.

개발의 끝의 과정은 어떻게 평가할까?

• Reliability (신뢰성)
• Sustainability (지속성 + 기능추가)
• Performance (성능)
• Readability (가독성)

Test-Driven-Development

TDD가 무엇인가?

• TDD는 요구사항을 충족하는 특정 테스트 케이스(테스트 코드)를 만든 후, 테스트를 통과할 수 있는 코드를 개발한 후 지속적인 짧은 개발을 반복하는 개발 방법이다.

• 실제로 단위 테스트 또는 TDD를 사용하면 디버깅하는 시간이 현저히 줄어들 뿐만 아니라, 잘못된 코드에 대해 빠른 오류 확인이 가능하다.

• TDD의 사이클

  • Add a test

    • 각각의 Feature을 실행하기 위한 테스트를 작성한다.
    • Feature의 기능과 요구사항을 만족하는 함수의 향상 혹은 함수를 정의한다.
    • 이 함수들은 테스트가 존재하는 동안 변형할 수 있다.

  • Run all tests and check fails

    • 테스트가 올바르게 작동하는지 확인하는 단계이다.
    • 첫 번째 테스트는 실패하는 것이 올바르게 작동하는 것이다. -> 테스트 코드에 아무것도 없기 때문이다.

  • Write the codes

    • 함수를 통과할 수 있는 테스트 코드를 작성한다.
    • 이때 테스트 코드는 완벽할 필요가 없고, 일단 통과하기만 하면된다. -> 뒷 단계에서, 이 소스코드를 Refactoring을 할 것이다.
    • 단, 프로그래머는 이 단계에서, 필요 이상의 함수를 구현해서는 안된다.

  • Run tests

    • 테스트를 진행해보면서, 모든 테스트 케이스가 통과하는지 확인한다.
    • 이때, 테스트 케이스를 모두 통과한다면, 테스트 요구사항을 모두 만족한다고 생각하면된다.
    • 만약 테스트 코드를 통과하지 못한다면, 될때까지 반복해야한다.

  • Refactor code

    • 이후 작성한 코드를 제거/수정/개선한다.
    • Object, class, module, variable은 반드시 목적과 사용의도를 드러내는 명확한 이름을 지어야한다.

• TDD 장점

  • 테스트 코드를 작성함으로써 실제 코드에 대한 이해를 높일 수 있다.
  • 디버깅하는 시간이 현저히 줄어들 뿐만 아니라, 잘못된 코드에 대해 빠른 오류 확인이 가능하다.
  • 테스트 코드 작성 단계에서 실제 코드에 대한 명확한 처리를 설계함으로써 과도한 설계를 피할 수 있고, 간결한 인터페이스를 갖는다.

• TDD Principle

  • 기능의 갯수를 최소화한다.
    • TDD에서 최소한의 기능을 구현하고, 이후 Refactoring단계에서 기능을 확장한다.

TDD in Python

• unittest

  • Python에 포함된 다양한 테스트를 자동화할 수 있는 기능이 포함되어 있는 표준 라이브러리
  • unittest에 포함된 주요 개념
    • TestCase : unittest 프레임 워크의 테스트 조직의 기본 단위
    • Fixture : 테스트함수의 전 또는 후에 실행 / 테스트 환경이 예상 된 상태에 있는지 확인
    • assertion : unittest가 테스트가 통과하는지 또는 실패 하는지를 결정

Profiling (computer programming)

• Profiling이란?

  프로그램 실행 중 CPU 사용량, 메모리, 함수 호출 주기/빈도 등을 측정하여 성능 병목 지점을 찾고 최적화하는 동적 분석 기술이다.

  Profiling은 프로그램의 최적화를 위해 주로 사용된다.

• Profiler

  • 소프트웨어 개발에서 프로그램의 실행 시간, 메모리 사용량, CPU 점유율, 함수 호출 빈도 등 성능 데이터를 실시간으로 수집하고 분석하는 동적 분석 기법.
  • Profiler는 다양한 방면의 데이터를 모으는 기술을 사용하며, 하드웨어 오류, 운영 체제 오류 등을 포함한다.

• Profiler 사진

각각의 함수가 차지하는, 시간과 메모리를 실시간 분석하여, 누가 많이 사용하는지 드러낸다.

• Profiler Tools

  • Bulit-in Profiler in Python
  • RunSnakeRun
  • SNAKEVIZ
  • FYI (Profiler Software)

Coding Guideline (Convention)

• 특정 프로그래밍 언어에서 프로그래밍을 할때 추천하는 스타일, 관행, 방식 등의 일련의 가이드라인을 말한다.

• 주로 파일 구성, 들여쓰기, 주석, 선언 등 프로그래밍을 하며 많이 사용하는 방식을 뜻한다.

• 소프트웨어의 구조적 품질을 유지하기 위한 방식이다.

• 프로그래머들은 가독성을 향상과 소스 코드의 유지보수를 용이하기 위한, 매우 추천되는 가이드라인들이다.

• 더 나아가, Convention(관습)일 경우에는, 규칙에 대한 문서가 존재하는 만큼 반드시 지키고 따라야할 방식이다.

• Convention은 회사별, 팀별, 단체별 다를 수 있다.

들어가기 앞서

대다수의 개발자들은 공유된 프로젝트를 수행하기 위해서 어떻게 할까?

• GitHub
• Google Docs

Software Maintenance Tools

• Version Control
• Concurrent Versions System (CVS)
• Apache Subversion (SVN)
• Git
• Github

Version Control

누가, 언제, 무엇을, 어떻게 변경하였는지를 확인하고, 저장하는 것을 지칭한다.

변화에 대한 관리는 문서(documents), 컴퓨터 프로그램, 웹 사이트, 혹은 다른 정보의 집합체로 보관된다.

변경된 사항들은 수정번호(revision number), 수정단계(revision level)으로 일컫는다.

각각의 변경 사항들은 time-stamp, 수정한 사람의 이름 등과 연관되어 진다. 즉, 어느부분을 누가, 언제, 어떻게, 무엇을, 왜, 수정했는지가 보여지면, 동료(co-worker)에게 비교당하고, 저장되고, 합병된다.

Version Control on Single Machine

• 로컬 컴퓨터에서 이루어지며, 사용자가 저장하거나 수정한 파일을 Version Database에 넣는 행위를 'Check in' 또는 'Commit'이라 부른다.

• 반대로 version Database에서 필요한 version의 정보 및 데이터를 가져오는 행위를 'Check out'이라 한다.

  Version Control on Multiple Machine

(Centralized Version Control Systems)

• 중앙의 하나의 Version Control Database에서 함께 저장하며, 각각의 Working computer(computer A/B)에서 수정한 파일을 넣거나, 추출하여 사용한다.

(Distributed Version Control Systems)

• Server Computer의 Version Database에서 완전히 똑같은 Version Database를 각각의 local 환경에서도 구축한다.

• 각각의 사용자 (computer A/B)는 자신이 작업한 작업물 혹은 수정사항들을 자신의 local computer에 저장하면 local Version Database와 연결된 Server Computer Version Database에서도 수정이된다.

  Version Control

  

• 수정은 일반적으로 일련의 개발과정에서 발생하며, 각각의 분기점에서 뻗어나가, 새로운 기능을 추가한다. 이때 분기점(Branches)에서 기존 계획에 필요하거나 추가해야할 기능이라면, 더해지지만(merges) 그렇지 않은 경우 사라진다.

Concurrent Version System (CVS)

동시에 여러 개발자들이 자신들의 개발을 관리하도록 만든 시스템이다.

• Free Software로써, client-server revision control system이다.
• 파일에 관한 모든 변화와 모든 작업의 추적을 유지하는 version control system이며, 동시에 여러 명의 개발자가 사용이 가능하다.

Apache Subversion (SVN)

Apache Lincense 하의 오픈 소스로써, 원격으로 Software의 버전과 수정을 관리하는 시스템이다.

• Software 개발자들은 Subversion을 통해, 현재 그리고 과거의 버전(소스코드, 웹 페이지, 문서)을 관리한다.

• 오픈 소스 커뮤니티는 Subversion을 널리 사용하고 있다.

Git

free와 open source의 distributed version control system이다.

• Git은 대량의 사람들 사이의 컴퓨터 파일과 그러한 파일을 관리하는 작업의 변화를 추적하는 version control system이다.

• 주로 소스코드의 관리를 위해 사용되지만, 모든 파일의 변화를 추적하기 위해 사용되곤 한다.

• 대표적인 분산 버전 관리 시스템으로 속도와 data의 통합을 목표로 발전하였다.

• Linus Torvalds(리눅스 개발자)가/이 2005년에 Linux kernel의 개발을 위해 만들었으며, 다른 리눅스 개발자의 초기 개발자들과 함께 협력하여 만들었다.

  Git - Distributed Version Control

  • Distributed Version Control은 버전 관리의 한 형태로, 개발자의 컴퓨터(로컬 환경)를 사용하여, 소스코드, 프로젝트의 버전들을 관리한다.

• Centrailized Version Control System

  • 중앙엔 Central server이 있다. : 모든 팀의 소스코드가 저장되는 장소이다.
  • 각각의 멤버는 서버로 부터 직접적으로 'Check out'을 한다.
  • 그들의 로컬 환경에서 수정을 거친 후, 개발자들은 그들의 변경사항들을 server code에 실어 중앙 서버로 적용(commit)시킨다.

  

• Distributed Version Control System (DVCS)

  • 모든 팀의 소스 코드는 원격의 central server에 저장된다.

  • 각각의 멤버는 중앙 서버로 부터 'Check out'을 하기 위한 메시지(pull)를 보낸다.

  • 로컬 환경에 각각의 중앙서버와 동일한 local 저장소가 있다. 따라서 개발자는 일시적으로 작업물에 대한 변경 사항들을 로컬 서버에 적용시킨다.

  • 개발자들은 그들의 작업물을 완전히 적용시킬길 원한다면, 로컬 서버에서 중앙 서버로 밀어(push)달라는 메시지를 보낸다.

  • 3단 구조로, 모든 프로젝트는 중앙 저장소로 가기전 프로젝트의 유지관리자들의 로컬 저장소에 저장된다.

  • 개발자들은 동일한 로컬 복사본을 만들 수 있다.

  • 중앙 저장소의 소스 코드의 변화들은 정기적으로 로컬 저장소와 융합된다.

  • 개발자들은 새로운 분기점(branch)를 만들때, 자신의 로컬 저장소에서 만들고, 분기점의 소스 코드를 수정한다.

  • 개발이 완료되면, 변화는 중앙 저장소에 통합된다.

Git - Distributed Version Control 용어

• Pull requsets
  • 소스 코드에 대한 Contributions을 지칭한다.
  • Contributor는 중간 관리자(유지 관리자)에게 소스 코드에 대한 변경 사항들을 "pull"해줄 것을 요청한다.
  • pull requests은 대부분 코드의 변환에 대해 집중한다.
  • pull requests은 중간 관리자(유지 관리자)에 의해 허락되고 거절된다.
  • 일단 pull requests가 승인되면, 저장소에 코드들이 합쳐진다.

Git의 저장하는 과정

• Remote Repository

  • 여러 사람이 함께 공유하기 위한 파일을 보관하는 전용 저장소

• Local Repository

  • 내 PC에 파일이 저장되는 개인 저장소 (Commit 하는 저장소)

• Staging Area

  • Working Directory 에서 Repository로 정보가 저장되기 전 준비 영역
  • 파일 상태를 기록, 스테이징을 한다. (Working Directory = 작업 영역)
  • 실제 코드를 수정하고, 추가하는 변경이 이루어진다.
  • 실제 프로젝트 디렉토리, git 이력과 관련된 정보가 저장되어있는 .git을 제외한 모든 영역이다.

• git init

  • high level의 새로운 깃 저장소를 시작하기 위해 사용된다.
  • 새로운 빈 git 저장소를 만든다.
  • 새로운 저장소를 위한 메타데이터를 포함하는 subdirectory를 만든다.

• git clone

  • 새로운 깃 저장소를 시작하기 위해 사용된다.
  • git clone은 git init에 종속된다. 내부족으로 git clone은 git init을 호출한 후 새로운 저장소를 만든다.
  • 유저의 로컬 컴퓨터에 존재하는 git 저장소를 다운로드한다.

• git pull

  • 원격 git 저장소에 상응하는 local git 저장소를 업데이트한다.

• git fetch

  • 원격 git 저장소에 상응하는 local git 저장소를 업데이트 하지만, 유저의 workspace에는 없는 완전히 새로운 변경 사항만을 업데이트한다.
  • git pull = git fetch + git merge

• git add

  • workspace에서 staging area로 변경 사항들을 추가한다.

• git commit

  • staging area에서 local Git repository로 변경 사항들을 추가한다.

• git push

  • local Git repository에서 Remote repository로 변경 사항들을 추가한다.

GitHub

git을 사용하는 웹 기반의 hosting 서비스이다.

• Readme를 통해 자동 렌더링된 문서화와, 라벨, 마일스톤과 함께, issue를 tracking할 수 있다.
• 코드 리뷰와 comments와 함께 pull requests를 가능하다.
• commits 이력을 추적할 수 있다.

Structure of Data (Data Structure)

자료 구조는 컴퓨터에서 효율적으로 데이터를 사용하기 위한 특별한 방식이다.

자료 구조는 하나 혹은 더 특정한 추상적인 데이터 타입(ADT)을 실행할 수 있다.

각각의 언어(C/Python)에는 공통된 자료구조를 포함하고 있으면 더 나아가, 자신들의 언어만의 고유 자료구조를 가지고 있다.

• 자료 구조의 종류

Processing of Data (Algorithm)

• 알고리즘은 문제의 유형들을 풀기위한 애매모호한 특정한 방식이다.
• 알고리즘은 계산과 데이터 처리과정, 추론 업무를 자동화할 수 있다.

Representation of Algorithm (Flow-chart)

• Flow-chart는 다이어그램의 유형으로, 일의 흐름과 과정을 나타낸다. 알고리즘의 정도를 표현해주며, 단계별 접근이 가능한 업무방식이다.
• Flow-chart는 다양한 분야에서 과정과 프로그램의 분석, 다자인, 문서화, 관리하는 것에 사용되곤 한다.

Representation of Algorithm (Pseudo-code)

실제 프로그래밍 언어(C, Python 등)의 문법이 아닌, 인간의 언어(한글, 영어 등)와 프로그래밍 구조를 섞어 알고리즘을 흉내 내어 표현하는 방식

• Pseudo-code란 의사코드로, 특정 언어의 규칙에 얽매이지 않고 논리 흐름을 설계하는 데 집중한다.

• 일반적인 프로그래밍 코드와 달리 인간이 기계언어를 읽고 이해할 수 있도록 하는 것이 목표이다.

Organized collection of Data

Database는 데이터의 집합체이다.

관계 데이터베이는 더 업격히 스키마, 테이블, 쿼리, 보고서, 뷰 그리고 다른 요소들을 포함하고 있다.

• Relational model : 관계형 모델

• Entity-relationship model : 엔티티 기반 관계 모델

  Relational Database model

  구조와 언어를 활용하여 데이터를 관리하는 접근 방식이다. 모든 데이터는 관계로 그룹화되어, 튜플을 나타낸다.

  

  Entity - Relational model

  ER 모델은 특정 지식 도메인과 상호연관된 것들을 묘사한다.

  기본 ER 모델은 entity타입으로 구성되며, 각종 entity 타입의 예시 사이 존재할 수 있도록, 관계를 명시한다.

  • 기본 ERD 구성요소

  • Entity Relationship Diagram (ERD)

  

SQL과 NoSQL Database

• SQL : Structured Query Language (table based)

• NoSQL : No or Not only SQL

  SQL (Structured Query Language)

  관계형 데이터베이스 관리 시스템(RDBMS)에서 데이터를 정의, 조작, 제어 및 조회하기 위해 설계된 표준 프로그래밍 언어

  NoSQL Data Model

  NoSQL은 고성능 비관계형 데이터 저장소를 나타내고, 사용 편의성, 확장성, 복원력 및 가용성 특성에 탁월하다.

  정규화된 데이터의 테이블을 조인하는 대신, NoSQL은 구조화되지 않은 데이터 또는 반구조화된 데이터를 Key-value 쌍(pair) 또는 Json문서에 저장하는 경우가 많다.

Software Block Diagram

특정 부분이나 기능을 블록으로 나타낸 시스템 다이어그램으로, 선으로 연결되어 블럭들 간의 관계를 보여준다.

• software block Digagram으로 나타낸 자율주행자동차

Computer Network Diagram

컴퓨터 네트워크 또는 더 일반적으로 모든 통신 네트워크의 노드와 노드 간의 연결을 묘사하는 개략도이다.

Message Sequence Chart

시스템 구성 요소나 객체들이 시간 흐름에 따라 서로 주고받는 메시지와 상호작용의 순서를 시각적으로 나타내는 UML 동작 다이어그램(Sequence Diagram)의 일종이다.

State Transition Diagram

시스템이나 객체가 시간에 따라, 또는 특정 이벤트(Event) 발생 시 어떻게 상태가 변경(Transition)되는지 시각적으로 모델링한 다이어그램이다.

State diagram은 시스템의 상태를 묘사하며, 각각의 정해진 상태를 구성하여 단계별로 어떠한 상태로 넘어가는지 명확히 보여준다.

Software 개발의 패러다임 변화

• 과거 : 소프트웨어
  • 마이크로소프트 윈도우 / 오피스
  • 한컴 한글 워드 프로세서
  • 어도브 포토샵
  • 패키징 게임들
  • 이러한 소프트웨어는 매우 장기간의 걸친 프로젝트이다.
  • 거대한 규모의 인력과 자본을 필요로 한다.
  • 예상된 마감기한이 존재한다.
• 현재 : 서비스위주
  • 구글 & 네이버 검색 서비스
  • 무료 게임 (부분 유료화 서비스)
  • 다음, 카카오, 라인 메신저 서비스
  • 광고 기반 무료 서비스들
  • 가능한 빨리 서비스를 출신한다.
  • 제한된 인력과 자본을 요구한다. (비교적 소규모)
  • 시장의 요구사항들을 만족하는 서비스를 개발한다.

Waterfall process : 아래로 흐르는 개발 과정cess : 아래로 흐르는 개발 과정

Waterfall process의 표식도

1. 요구사항 분석 : 1~6개월

2. 디자인(설계) : 6개월 ~ 3년

3. 개발 : 6년

4. 시험(테스팅)

5. 유지 및 보수

   Waterfall process with Gantt chart

   

   해야할일 들을 작성하고, 정해진 시간( 마감 기한 )에 맞게 제대로 진행하고 있는지 일련의 과정을 볼 수 있는 차트표.

Waterfall process의 장점

1. 전체 프로젝트의 과정을 문서화와 소스코드를 확인할 수 있다.
2. 문제를 쉽게 고칠 수 있고, 문제를 나중에 발견하는 것이 아닌, 조기에 발견할 수 있다.
3. 의사소통이 부족하거나 오류가 덜 발생하며, 각 단계들을 간다하게 참고할 수 있다.
4. 각 단계별로 성취해야할 목표들을 간단명료하게 확인하고 공유할 수 있다.
5. 견고한 구조는 팀의 목표와 스케줄을 관리할 능력을 증가시켜준다.

Waterfall process의 단점

1. 전체 프로젝트의 과정이 단계별로 간단하게 이어나가지만, 뒤에 문제가 발생하였을 때 뒷 단계로 돌아가기 쉽지 않다.
2. Waterfall 방식에서는 refactoring을 하지 않는다.
3. 각 단계별 조건을 완전히 만족하기란 불가능에 가깝다. -> 시장은 빠르게 변하짐만 1번과 같이 개발 도중에 고객의 요구가 변화하더도, 뒷 단계로 돌아가지 못하기 때문에 즉각적인 대응이 하기 어렵다.
4. 3번과 같은 즉각적인 대응이 어려우므로, 프로젝트 자체의 시간과 비용이 기하급수적으로 증가하게 된다.

Agile

소프트웨어 개발 및 프로젝트 관리에서 계획에 얽매이지 않고 변화에 민첩하게 대응하며 점진적·반복적으로 결과물을 산출하는 유연한 방법론

Agile이 무엇인가?

1. process와 tools보다는 individuals와 interactions을
2. comprehensive documentation 보다는 Working software를
3. contract negotiation 보다는 Customer collaboration를
4. following a plan 보다는 Responding to change를 가치 있게 여긴다.

Agile Manifesto 12 Principles

• 고객 만족

• 변화에 대응

• 자주 보여준다

• 정기적으로 의사소통한다

• 대면으로 의사소통한다

• 업무의 진척도를 측정한다

• 개발 과정을 보여준다

• 좋은 디자인을 공유한다

• 진척도를 측정한다

• 팀 멤버와 협력한다

• 결과를 계속해서 찾아본다

• 반영하고 조정하는 것을 두려워하지 말라

Scrum for Agile

Scrum은 Agile의 정신을 실현하고 소프트웨어 개발에서 업무를 관리하고 중요성을 강조하기 위한 프레임워크이다.

Scrum은 3~9명의 개발자 팀을 위해 고안된 방식으로, 진행도를 추적하고, 매일 15분씩 업무의 상황을 보고하고, 미팅을 가진다.

DevOps (development and operations)

DevOps는 시스템 변화를 확인하고 일반 상품에 적용시키는데 걸리는 시간을 줄이도록 고안된 방식이다.

• DevOps의 주된 특성은 강력한 자동화와 모든 소프트웨어 개발의 단계를 모니터링한다는 것이다.
• DevOps는 더 짧은 개발 사이클, 증가된 빈도, 더 많은 출시 등을 목표로 한다.

DevOps 개발 도구들

Background for Selecting OS

• Business
  • Market share
• Technical requirement
  • Distributed, Multi & Parallel processing
  • Realtime processing
  • Extremely small hardware resource environment
  • Secure computing

Market Share

2025 전 세계 데스크탑 OS 점유율

2025 전 세계 모바일 OS 점유율

2025 전 세계 서버 OS 점유율

리눅스 OS 점유율

• 2022년 기준 리눅스의 점유율은 다른 OS(iOS, Windows)에 비해 시장 점유율은 떨어진다.

• 클라우드 인프라의 약 90%가 리눅스가 차지하였다.

• 전 세계의 대표적인 웹 서버들의 96.3%가 리눅스이다.

• 미국은 거의 2백만개의 우분투 웹사이트가 있다.

  왜 리눅스인가?

  1. 리눅스는 오픈 소스이다.
  2. 리눅스는 멀티 유저를 감당한다.
  3. 리눅스는 "Free"(자유)이다.
  4. 리눅스는 신뢰할 수 있다.
  5. 리눅스는 backwards와 상호성립이 가능하다.
  6. 리눅스는 네트워크 친화적이다.

Linux Foundation

Linux Foundtaion은 리눅스의 발전을 제고하기 위해 설립된 비영리 연합체이다. 2000년에 오픈 소스 개발 연구소와 자유 표준 그룹의 병합으로 설립된 리눅스 재단은 리눅스 제작자 리누스 투르발스의 일을 지원하고 있으며, 전 세계의 선도하는 리눅스 및 오픈 소스 기업과 개발자로부터 지원을 받고 있다.

Linux

• 리눅스의 32비트의 Unix와 같은 OS이다. 처음에는 가정용 컴퓨터를 위해 제작되었으나, 현재는 Macintosh, Amiga, DEC Alpha를 포함한 여러 플랫폼에 이식되었다.
• 리눅스의 소스코드는 모든이에게 자유롭게 사용이 가능하다.
• 리눅스의 운영체제는 다음과 같은 특징을 갖는다.
  • 안정성(Stable) : 리눅스 하의 운영체제는 다른 운영체제에 비해, crash와 서버 다운 문제가 덜 발생한다.
  • 신뢰성(Reliable) : 리눅스 서버는 다른 서버에 비해, 수 백일은 더욱 버틸 수 있다.
  • 강력함(powerful) : 이러한 두 가지 특성으로 리눅스는 강력한 서버라고 평가받는다.

Linux Kernel

• 커널은 전체 컴퓨터을 돌리는 OS 코드를 포함한 리눅스의 중심이자, 민간한 시스템이다.
• 커널은 특정 전문적인 일(TCP/IP networking)을 포함한 수행하는 코드들을 포함한다.
• 커널 디자인의 기본은 모듈러이다. 그래서 실제 OS코드는 매우 작고, 실제 그것이 필요할 때 적재될 수 있다. -> 커널은 작고, 매우 빠르며, 높은 확장성을 갖는다.

Linux Networking

• 네트워킹은 자연스럽게 리눅스에게 몰린다. 리눅스는 인터넷과 WWW의 산물이다.

기타 리눅스 운영체제 사용분야

VxWorks (Commercial RTOS)

• VxWorks는 실시간 운영체제로써, 1987년에 출시되었다. 실시간과 제시간 안에 업무를 수행하는 것을 필요로하는 임베디드 시스템에 사용된다.
• 안전과 보안 등의 분야에서 활용된다.

RTL (Real Time Linux collaborative project)

Zephyr (자원이 제한된 기기를 위한 OS : IoT)

Secure Computing (ARM TrustZone)

• Trusted Computing에서 파생된 개념
• Trusted Computing은 Trusted Computing Group이 개발하고 선도한 기술이다. = Trusted Computing은 지속적으로 예상 경로를 통해 행동하고 그러한 행동들을 컴퓨터의 하드웨어와 소프트웨어에의해 통제된다.
• 그리고 이러한 행동들은 특정한 encryption key가 없다면 접근할 수 가 없다.

Select Right Language

• 만약 누군가 언어를 추천해달라다고 가정하자. -> 누구에게 무엇을 추천할 것인가? -> Python?, C++ -> 추천해 달라하는 사람의 직장과 성향에 따라 천차만별일 것이다.

언어를 선정하는 기준은 무엇인가?

1. Hardware관련 특정 문제를 다루어야 하는가?
    - 일반적으로 어셈블리어로 C, C++이 선택
    - Aurdino라면 C를 선택
    - Linux / Unix Kernel의 경우에는 C / C++이 지지받는다.
    - MacOS kernel일 경우 C 혹은 Swift가 요구될 것이다.
2. Hardware에 구애받지 않는 문제라면?
    - Web 클라이언트 그리고 서버 프로그래밍
    - 데이터 분석, 엔지니어, 사이언티스트
    - 이러한 것들은 보통 접근 기반의 high level language를 사용하는 것이 좋다.

C / C++이 가지는 Hardware 관련 feature가 무엇인가?

• Physical memory management : 물리 메모리 관리(접근이 가능)

  • C / C++의 포인터개념 : C기반의 언어들(C, C++, Rust, gigle)은 기본적으로 다른 변수의 주소를 저장할 수 있으며, 변수의 주소를 포인터를 통해 물리적으로 접근이 가능하다.
    • 하드웨어를 접근해서 읽고 쓸 수 있다.(하드웨어 장치와 매핑이 가능.) == Ram을 매개체로 명령을 수행이 가능하다. == imbeded programming이 가능하다.

• Bit Operation : 0과 1로 연산이 가능하다.

  • mapping된 하드웨어 장치를 포인터를 통해 실제 주소로 이동하면, 매핑된 입력과 출력 장치를 통해 실제 기계와의 소통이 가능하다.(계산이 가능하다.)

Domain Specific Language

특정 분야의 도메인에 주로 활용되거나, 널리 사용되어 대체하기 어려운 언어가 존재한다.

• 도메인의 종류

  • Web server
  • Data analytics
  • Cloud computing
  • Microservice programming

  Web server (programming language)

  • Javascript
    • 1995/12/04 탄생
    • 초기에 오로지 웹브라우저에서 client-side를 실행하기 위해 설계되었다.
    • 그러다 현재 많은 유형의 host software에 이식되면서 널리 사용되고 있다.
  • Node.js
    • 2009/05/27 탄생
    • Open Source, Cross platform, JavaScript run time 환경

Web server (with dedicated tools)

• Apache

• Nginx

• Wordpress

  Data analytics (Data Analysis, Data Science)

• 데이터를 점검, 변형, 청소, 모델링 하는 과정을 거친다.

• 데이터를 유요한 정보로 바꾸어 결론에 제안하는 것을 목표로 한다.

• 선호되는 언어 : Python , R

• 주요 요구사항

  • 자연어 처리, 글자 분석
  • 선형, 확률, 통계

  Cloud computing

• OpenStack

• CPU, 저장소, networking의 대규모 통제하며, datacenter내에서 자원을 관리한다.

그럼에도 무슨 언어를 선정해야할지 모르는 경우

Selection by Tiobe index

프로그래밍 언어의 인기도를 측정한 지표

성향에 따른 도표표를 통한 빠른 선정

가고자하는 회사에서의 로드맵 참고

• 예시 : 우아한 형제들 (서버) : JavaScript

Problem Definition (software layer)

• System software
• Application software

System software vs Application software

애플리케이션 개발자 : Application , Middleware

시스템 개발자 : OS UI, OS Services, OS drivers and runtimes, Hypervisor, Firmware, Hardware

Problem Definition의 목적(purpose)

• Purely your own purpose -> 자신의 문제 해결 ex). 창업, 기획
• Based on othe person's request -> 다른 사람의 문제 해결 ex). 취업, 하청

Customer Requirement Analysis (고객 요구 분석)

1. 첫번째 방법

1. Used Case Diagram

2. Focus Group

3. BrainStorming

4. Obsersvation

5. Interview

6. Survey

7. Join Application Method

8. Interface Analysis

9. Prototyping

2. 두번째 방법

   1. Requirement elicitation : 고객 도메인에서 요구사항 추출

   2. Requirement analysis : 추출한 사항을 바탕으로 분석

   3. Requirement specification : 이를 바탕으로 요구 명시

   4. Functional doamin : 이후 기능 도메인에서 구현하고자 하는 기능 실현

Problem Definition (legacy)

• From scratch : 백지에서 시작 (처음부터 시작)

• Based on existing platforms : 최대한 재사용하기 (reverse engineering)

  Reverse Engineering (reengineering)

• 완제품이나 시스템을 분해·분석하여 그 설계 기술, 동작 원리, 구성 요소를 역으로 추적해내는 과정 (보완/해킹)

• 기술 문서가 없거나, 경쟁사 제품 분석, 구형 시스템 복원 및 보안 취약점 분석을 위해 활용

• Reverse Engineering 예시

  • 동작되는 file은 있는데 source code는 없을때
    • 악성 코드 분석 -> machine language code를 high-level language로 역변환

  Software Reuse

  

• 이미 개발되어 검증된 소프트웨어의 구성요소(코드, 설계, 문서 등)를 새로운 애플리케이션 개발에 활용하는 기법

  • 디자인 패턴, 함수, 모듈, 라이브러리, 클래스 ... 등

• 디자인 패턴

  • 프로그래밍 패러다임 : function(함수) 재사용
    • 객체 지향 프로그래밍 : class(클래스) 재사용
    • 디자인 패턴, 구조적 패턴 : 프로그램 설계에 대한 재사용

  Refactoring

  

• 소프트웨어의 외부 동작을 변경하지 않으면서 내부 구조를 개선하는 코드 재구성 작업
• Refactoring의 주요 목적
  • 코드 가독성 향상 : Redability
  • 유지보수 용이 : Maintainability
  • 중복 제거 및 코드 구조 개선 : Performance
  • 시간 복잡도 개선 : Complexity
  • 확장성 개선 : Extensibility
  • 실행 속도 향상 : Execution

Problem Definition (Project characteristics)

• Due(Service deployment date) : 언제까지 개발해야하는가

• Performance(Capacitty, Response, Time) : 얼마만큼의 성능을 뽑아내야하는가

• Resource(개발자 수, 개발자 수준, 돈... 등) : 얼마만큼의 예산이 필요한가

  Performance indicator (KPI)

  • 성능을 측정하고 평가하기 위한 핵심 평가 지표(key performance indicator)

  • KPI는 특정 활동과 조직의 성과를 평가할 수 있으며, 전략과 운영 개선에 중점을 맞추었다.

  • KPI 예시

    • 

Problem Definition (Hardware depency)

• Hardwared dependent : 하드웨어가 필요하다.
  • 아두이노(Arudino), 라즈베이파이(RaspberrPi), 쿠다(CUDA)
• Hardwared in - dependent : 하드웨어가 필요없다.
  • 웹/서버 개발 -> 일반적으로 KPI가 적용된다.
  • 모바일 애플리케이션 개발
    • Native platform(iOS, Android) -> 극한 성능을 뽑아야한다.
    • Cross platform(HTML, CSS, JavaScript, Dart/Flutter) -> 빠른 개발과 출시가 중요하다.

오픈소스 소프트웨어

소스 코드를 공개해 누구나 특별한 제한 없이 그 코드를 보고 사용할 수 있는 오픈 소스 라이선스를 만족하는 소프트웨어를 의미한다. 통상적으로 간략하기 '오픈소스'라고 칭한다.

Free 소프트웨어

Free란 무료가 아닌 '자유'를 의미한다. / 복사와 사용, 연구, 수정, 배포 등의 제한이 없는 소프트웨어 혹은 그 통칭한다.

프리 소프트웨어의 궁극적인 목표는 누구나 자유롭게 사용하여, 이전의 없는 기능을 추가하고, 성능을 향상시킴으로써, 모두에게 이익이 되도록하고 재배포하는 등 소프트웨어 생태계가 지속 가능하게 하도록 하는 것이다.

Free Software Foundation

1985년 10월 4일에 설립된 이 단체는 저작권(copyright)를 비꼬며, 'copyleft'를 창시, 이후 자신들만의 GNU General Public Lincense를 만들었으며, 자신들 산하의 여러 기술과 프로젝트를 진행하고 있다.

GNU OS?

GNU는 운영 체제 중 하나이자, 컴퓨터 소프트웨어의 모음집 이다. GNU는 온전히 자유 소프트웨어로 이루어져 있으며, 그 중 대부분이 GNU 프로젝트의 GPL로 라이선스 된다.

리처드 스톨만?

미국의 자유 소프트웨어 운동 활동가이자 프로그래머이다. 그는 사용자가 소프트웨어를 사용, 연구, 배포, 수정할 수 있는 자유를 가질 수 있도록 소프트웨어를 배포해야 한다는 캠페인을 벌이고 있다.

오픈소스 소프트웨어만 있는가?

오픈소스 소프트웨어 이외에도, 오픈소스 하드웨어도 존재한다. 대표적인 오픈소스 하드웨어는 '아두이노'이다.

또한 Open Source Processor인 RISC-V 또한 존재한다. 아 RISC-V는 프로세서를 만드는 설계 및 각종 소프트웨어를 만들어서 공유를 담당한다.

LINUX

왜 LINUX일까?

현재(2025기준) 스마트폰과 IoT(사물인터넷)의 대부분이 리눅스로 운영되고 있다. 동시에 Physical Computing역시, 리눅스가 차지하고 있다. 이외에도, 슈퍼컴퓨터의 운영체제로도 활용되고 있다.

Linux 일화 : 윈도우의 적? 이제는 친구! (WSL)

과거 MS는 리눅스를 '암(Cancer)'이라고 부를 정도로 경계했으나, 2010년대 이후 Satya Nadella CEO 취임 후 'MS는 리눅스를 사랑한다'고 입장을 바꿨다.

또한 이제는 윈도우 10/11에 'Linux용 Windows 하위 시스템(WSL2)'이 기본 탑재되어, 윈도우 안에서 리눅스 명령어를 완벽하게 사용할 수 있도록 변모되었다.

Linux의 생태계

리눅스의 생태계는 점점 넓어지고 있으며, 활용 범위 또한 넓어져 현재는 다양한 일상 생활속에 녹아있다 봐도 무방하다.

1. ROS(로봇 운영체제), 2. Automative Grade Vehicles, 3. 클래식 게임 플랫폼, 4. 온라인 게임 거래 플랫폼(Steam)

협의 & 광의의 Linux

1. 협의의 리눅스(narrow Linux)

   • Linus Torvalds가 개발한, linux kernel software(OS)
   • Linux Foundation(LF): Linux의 발전을 제고하기 위해 설립된 비영리 연합체

2. 광의의 리눅스

   • linux foundation 산하 900개의 projects