끝이 없을 모험 이야기

man-month: 한달에 투입되는 사람수(소프트웨어를 개발할 때 얼마나 많은 사람이 투입되어야 하는가), 정량적 수치

1 man-month: 한 사람이 한달동안 풀로 들어가는 것

12 M/Ms = 12명이 1달 = 1명이 12달?에 대한 문제 발생 -> 문제가 없는 논리이지만 소프트웨어에서는 안 통한다.

늦어진 소프트웨어 프로젝트에 사람을 추가하는 것은 더 늦게 끝나게 한다.

책(직접 겪었던 프로젝트 관리 실패담들을 모은 책)에서 강조한 것

man-month

Second system effect

prototyping

이전처럼 소프트웨어를 관리하는 것은 실패

-> man-month쓰기 부적절, 변수가 많음. 환상이다.

   길어지는 이유

   1.새로운 사람 뽑으면 교육하는데 오래 걸림

        (애자일로 training 시간이 더 오래 걸리게 됨. 문서 수가 적으므로)

Man-month의 문제점: SW개발에서 서로 다른 팀끼리의 소통이 필수적이지만 사람이 늘어나면 소통이 길어질 수밖에 없다.

케이스 바이 케이스(no silver bullet)

한가지 방법이 모든 문제에 적용되지는 않는다.

!!!!!!!경험이 레퍼런스가 될 수 있으나 다른 문제의 솔루션이 될 수 없음!!!!!!!!!!!!!

이렇게 해결 가능한 완전 재사용가능한 프로그램은 없음

Second-system Effect

첫번째 시스템에서 느꼈던 아쉬운 점, 못 만든 기능들을 다 넣을려고, 만들려고 한다. 따라서 반드시 필요한 개선점이 들어가야 하는 것이다. 오버하는 것은 지양해야 한다.

Over-engineering

개발자들의 문제를 관리자들이 이해해야함 그리하지 못함

!!!!!!!!!!!!! Second-system에는 반드시 필요한 것들만 추가 개선!!!!!!!!!!!!!

Irreducible number of errors

버그가 없는 프로그램은 존재하기 힘들다. 따라서 작은 버그는 두고 큰 버그들을 해결해야 한다. 정성, 정량적으로 버그의 level을 나눠서 사소한 버그들은 두고, 큰 버그들을 다뤄야 한다.

Progress tracking

수면 위에 드러나지 않은 문제들로 전체적인 시간 delay가 있을 수 있다.

소프트웨어 개발이 어떻게 1년이나 늦어지는 거지? 하루에 한 시간씩 늦어지면 그럴 수도 있지.

애자일: 데일리 스크럼등으로 자주 대화하는 이유가 이러한 문제들을 파악하고 해결함

즉 각자 알아서 하라고 내버려두는 것이 아니라 소통을 통해 문제들 파악하게 하는 것

Conceptual integrity

소프트웨어를 만들 때 소프트웨어가 가져야 할 철학, 일관성

Waterfall 방식인 것 같음.

시스템 아키텍쳐: 시스템을 설계(기술적인 부분)

프로젝트 매니저: 프로젝트를 관리, 행정을 한다.

하나의 시스템 설계팀이 철학, 일관성에 따라 결정한다. Ex) 스티브 잡스, 다이슨

하나의 설계팀에서

SW의 전체적인 구조 설계와 철학, 일관성을 고려한 결정을하고 계획함

추가적인 기능등도 일관성 측면에서 판단하고 추가 또는 배제함

The Manual(개발과 관련됨, 시스템 아키텍쳐가 쓰는 것)

설계자가 매뉴얼 정의 -> 맞춰서 개발

The pilot system(권장 사항) = Prototype(주요 기능을 구현해보고 확인하고 나서 버린다.)

첫번째로 만든 시스템은 대부분 시행착오를 겪고 잘못된 설계 하에 채워질 수 있으니 상용화 하지 말고 버려라.

프로그램에서 검증해야할 중요한 것들 중심으로 먼저 만들어보기

Formal documents(project manager)

Product Manager(PM): 관리쪽(개발X)

이들이 만드는 문서에는

프로젝트의 목적, 누가 만드는지, 언제 만들어질 건지, 비용 등

포함됨 (개발관련 X)

project estimation:

공식적인 개발과 관련된 일정을 누가 얼마에 하는지 등을 계산(행정)

어떤 SW를 파는 것은 만드는 것과 다른 얘기

상용화 하기 위한 준비기간이 매우 김

waterfall일때 전체 기간의 30퍼센트만 개발 기간이 주어짐

Communication

큰 문제 피하기위함

탑다운일 때, 내가 결정하는 것이 아닌 물어봐야함(전체철학에 맞는지)

업무의 경우 이메일로(주장 및 근거, 책임...)

통화, 대화로 하지 않는다

The surgical team

파일럿 팀: 유능한 사람들이 먼저 개발하고

그 뒤에 대체 인력 투입

개발자의 능력은 동일하지 않다.

Code freeze and system versioning: 코드를 얼린다=개발을 종료한다.

오류가 있어도 code freeze 했으면 손을 데지 않아야 한다. 완벽할 수는 없다.

요구 사항을 더이상 받지 않고 개발 종류 선언

완벽한 SW가 아닐 수 있으나 괜찮음 원래  그럼

Specialized tools

개발 도구를 직접 개발한다. 반복적인 일을 도구로 만든다. Ex) 업무 자동화.

Ex) projectlibre

Lower software development costs

소프트웨어 개발 비용을 낮추는 것이다. 어떤 조직에서는 개발하는 사람이 항상 필요하지는 않다.

코딩이 필요한 시간에만 개발자를 고용하라

요구사항을 만족하는 오픈소스나 상용 제품이 있다면 그것을 그냥 쓰는 것도 나쁘지 않다.

오픈소스 라이선스: 소프트웨어를 출시하고 사용할 때 신경 써야 할 중요한 부분

오픈소스의 정의

배포된 소스코드를 자유롭게 복사, 수정, 사용, 재배포 할 수 있는 소프트웨어를 뜻한다.

오픈소스 선택 시 고려사항

품질: 기능(우리가 원하는 기능이 있는가?), 성능, 호환성(얼마나 수정해야 하는가?) 등 오픈소스의 품질은 오픈소스를 선택하는 데 가장 중요한 요소다. 개발자 입맛에 따라 오픈 소스가 만들어지므로 오픈소스의 클래스, 메소드들이 다 다르다. github에서의 sta, fork수(정성적 정량 수치)로 오픈소스의 완성도를 가늠할 수 있다. 오픈소스를 사용하려는 기술 조직은 당연히 충분한 기능과 성능 검증을 수행한 후 제품/서비스에 도입해야 한다.

커뮤니티: 오픈소스가 얼마나 사용자를 보유하고 있는지, issue 관리는 이루어지고 있는지, 지속적으로 업데이트를 하는 지 등, 지속가능한 오픈소스를 선택해야 한다.

문서화: 문서화가 잘 되어있으면 기업이 도입하는 데 수월하다. 설명이 잘 되어 있는 것을 선택한다.

보안 취약점: 사용하려는 오픈소스의 버전이 보안 취약점이 있는지 확인 후 사용해야 한다. 보안은 OS 보안, 네트워크 보안, 웹 보안으로 나뉘는데 웹 보안이 가장 문제가 많다. CVE 사이트에서 사용하려는 오픈소스 보안 취약점을 체크해라.

라이선스: 오픈소스를 “재배포 시” 준수해야 할 의무사항을 요구한다. 가장 간단한 의무인 고지 의무부터 가장 복잡한 의무인 소스 코드 공개 의무까지.

GPL: 관련된 모든 소스코드를 공개(가장 강력한 라이센스)

오픈소스와 법적 책임

라이선스를 지키지 않으면 사용 권리가 박탈되고 제품을 판매할 수 없다. 또한 수익을 능가하는 돈을 내야 할 수도 있다. 기업 이미지에 큰 손실을 끼친다. 법적 소송에 연루될 수 있다.

오픈소스도 저작권 지식 재산권 존재

!!!!!!!!소스코드가 공개 되도 오픈소스 라이센스가 없으면 오픈소스가 아님!!!!!!!

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

1. 저작권 표시 및 라이선스 고지: 가장 약한 라이선스, 소스 코드 파일 상단에 주석을 달거나 README 파일 안에 고지한다.

2. 소스코드 공개

3. 재배포시 동일 라이선스 적용: “Copyleft”

2,3을 동시에 요구하는 라이센스: GPL

오픈소스를 사내에서 테스트 용도로 사용한다면, 의무사항은 부과되지 않는다.

OSI: 오픈소스에 해당하는 라이선스의 최소한의 기준을 정의 해놓고 이 정의에 따라 오픈소스 라이선스를 인증함.

아무 조건 없이 사용 가능한 라이선스

Creative Commons Zero

The Unlicense: 아무런 제한을 걸지 않는 라이선스(아무런 제한을 걸지 않아도 라이선스를 등록 해야한다.)

수월하게 사용 가능한 라이선스(Permissive License)

오픈소스 라이선스의 고지 의무가 있는 라이선스

Ex) BSD, JSON License, MIT License, Microsoft Public License, Python Software Foundation License, Independent JPEG Group License

주의가 필요한 copyleft 라이선스

GPL은 재배포 시 소스코드 공개를 요구한다. +Create commons attribution.

이러한 오픈소스는 설계 단계에서부터 build 시 자사 소프트웨어와 통합되지 않고 runtime에도 독립된 프로세스로 동작되도록 해야한다.

GPL-3.0 같은 경우에는 제품을 배포하기 위해 소스 코드뿐만 아니라 설치 정보를 함께 제공해야 한다.

Weak Copyleft

LGPL: 메모리를 공유하는 방식인 Dynamic Linking 방식은 봐준다.

별도의 실행 파일을 통신으로 하면 GPL 라이선스를 겪지 않을 수 있다. LGPL Library 부분만 소스 코드를 공개하면 되고, 결합하는 코드는 공개를 하지 않아도 된다.

+apple, mozilla, eclipse

static linking: 코드가 링킹되어 하나의 실행 파일안에 링킹되어 있을때, 99개중 1개가 GPL 라이선스면 배포 시 100개가 모두 GPL이 걸리는 것이다.

dynamic linking: 별도 파일(dll)로 존재하여 필요할 때 메모리에 올려 사용

GPL: static,dynamic 둘다 소스코드 공개, 재배포시 동일 라이선스 적용

lGPL: dll은 봐주는 약화된 GPL

GPL우회법: 별도 프로그램 두개로 만들어서 '통신'으로 연결함

사용 제한 라이선스

네트워크에서는 gpl보다도 agpl이 더 강력하다. 서버에 agpl의 오픈소스가 있다면 배포하지 않아도 함께 링크되어 동작하는 다른 소프트웨어의 소스코드까지 agpl로 공개해야 한다. 회사의 핵심 서버 프로그램까지도 공개해야 하는 위험이 있다.

광고 조항 포함 라이선스도 있다.

소스코드 제공 의무 유형

GNU GPL, GNU AGPL: 모든 소스 코드를 공개해야함

GNU LGPL, NASA: static하게 연결된 모든 걸 열어라(파생 작업물)

Mozila, Sun public license: 코드가 아닌 파일 공개, 파일 단위로 열어라, 다는 아님.

이클립스: 모듈 단위(함수, 함수의 변형된 형태 공개), 다는 아님.

~ : 수정된 부분만 파일 단위로 공개

~ :모듈(함수의 수정된 부분만 모듈 단위로 공개)

Apache: 고지의무

GNU GPL

카피레프트, 자유 소프트웨어 재단에서 만든 라이선스, 배포하는 경우 무조건 GPL로 공개해야 한다. Dynamic Linking을 해도 GPL 라이선스.

별도의 실행 파일을 두개로 만들어서 통신으로 연결하면 GPL 라이선스를 겪지 않을 수 있다.

EX) 리눅스 커널, 워드프레스

GNU AGPL(server)

서버에 agpl의 오픈소스가 있다면 배포하지 않아도 함께 링크되어 동작하는 다른 소프트웨어의 소스코드까지 agpl로 공개해야 한다.

Ex) 몽고DB

GNU LGPL

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

EX) 모질라 파이어폭스

MIT License

MIT에서 소프트웨어 공학도들을 돕기 위해 개발한 라이선스. 가장 느슨한 조건을 가진 라이선스 중 하나이다. 고지의무를 가진다.

EX) 부트스트랩, Backbone.js, jQuery

BSD License

버클리의 캘리포니아 대학에서 배포하는 라이선스다. 공공의 몫으로 돌려주자는 의미가 강하다. 저작권 표시 조건 외에는 제약이 없다.

EX) Nginx

주의가 필요한 copyleft 라이센스

가장 강력함!

GPL이 여기 속함

Creative common 라이센스, 뒤에 붙는 레벨에 따라 다름!

지적 재산권을 명시하면서도 사용을 허용함

기능정의 후 개발 전 관련 라이센스 등을 다 확인

weak copyleft:

LGPL: DLL에 대해서 완화해준다.(약간 완화됨)

이클립스: lgpl에 속하는 오픈소스

소스코드 말고도 설치 정보등의 사용자 제품에대한 정보도 공개해야함

다이나믹 link에대해서 dll은 봐줌(PPT 참조)

대부분의 법적 절차는 '기간'이 치명적임

그 정도 기간이면 웬만한 스타트업은 못버티고 사라짐

사용 제한 라이선스

GNU affero : 옾소가 들어간 서버가 인터넷 서비스 -> 이건 재배포에 해당하니까 코드 공개

따라서 많은 기업들이 금지함

광고를 포함한 라이선스 : 요구사항 준수가 어려워 대부분 사용을 금지함

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

[GPL이 무서운 이유]

내가만든 실행파일에 GPL 라이선스 포함되면 전부 공개

static link,Dynamic linking: 동일한 메모리를 공유하면 전부 해당됨

몽고DB: Affero GPL(통신으로~ 소스코드 다운가능해야함)

LGPL: 분리되어 있는 경우, 봐줌(라이브러리,모듈 링크를 허용함)

정적링크는 소스코드와 앱의 오브젝트 코드도 공개해야함

Mozilla Public License(MPL)

개발자 편향적(GPL과 반대)

소스코드와 실행파일의 저작권을 분리함!

실행파일은 내꺼

MIT License

가장 느슨, 법적 고지문을 카피해서 포함하는 형태면 충분

bootstrap,angular.js

Berkeley Sw Distribution (BSD)

라이센스 및 저작권 표시하면 끝

0. Decorator Pattern이란?

 데코레이터 패턴은 객체의 추가적인 요건을 동적으로 추가하는 패턴이다. 중심이 되는 객체가 반환하는 값에 추가적으로 더해져서 결과값을 반환한다.

1. goal

 데코레이터 패턴은 특정 객체의 기능을 정적으로 확장(장식)하는 데 사용할 수 있다. 하나의 객체에 부가적인 기능을 덧붙여 많은 객체에게 다양한 부가기능을 쉽고 빠르게 적용하는 것이 목표이다. 다시 말해 객체가 동적으로 움직이고 있는 중에 특정 기능을 추가하고 뺄 수 있도록 하는 것이다.

2. Detail

 중심이 되는 객체를 놔두고 추가적인 사항을 첨가하는 방식이라 객체에 기능을 추가 또는 삭제할 때 중심이 되는 객체를 수정하지 않고 동적으로 추가 또는 삭제할 수 있다는 장점이 있다. 객체 지향의 원칙 중 확장에는 열려 있고 변경에는 닫혀 있어야 한다는 원칙인 OCP(Open-Close Principle)에 충실한 패턴이다. 데코레이터 패턴을 사용하게 되면 기존 객체는 변경하지 않고 자유로운 확장을 구현할 수 있으며 기존 객체 혹은 데코레이터가 수정되더라도 해당 클래스의 내용만 수정해주면 되기 때문에 변경에 대해서도 닫혀 있다. 또한 기본적인 데이터에 첨가하는 데이터가 일정하지 않고 다양할 때 데코레이터 패턴을 사용하면 효율적으로 사용할 수 있다. 반면에 데코레이터를 너무 많이 사용하게 되면 자잘한 객체가 많이 추가될 수 있고 오히려 코드가 복잡해질 수 있다는 단점이 있다.

[상속과의 차이점]

상속은 하위 클래스를 생성하는 방법으로 확장을 하며 데코레이터 패턴은 기본 객체에 추가하는 객체를 생성하는 방법으로 확장을 한다. 상속은 오버라이딩을 통해 기능을 전부 명시해 줘야 하지만 데코레이터 패턴은 기본 기능은 놔두고 추가되는 기능만 명시해 줄 수 있다는 차이가 있다.

[Composite 패턴과 차이점]

다양하고 일정하지 않은 여러 객체들을 하나의 객체로 묶는 것을 Composite 패턴이라고 한다. Composite 패턴은 목적이 생성되어 있는 객체들 간의 합성에 있고 데코레이터 패턴은 목적이 객체에 새로운 행동을 추가하는 데에 있다.

[Strategy 패턴과의 차이점]

Strategy 패턴은 유사한 행위를 캡슐화하는 인터페이스를 정의하여 객체들의 행위를 유연하게 확장하는 방법이다. Strategy 패턴은 객체의 내부를 변화시키며 데코레이터 패턴은 새로운 객체를 추가하여 객체를 변경시킨다는 점에서 차이가 있다.

3. UMLs

Component: 동적으로 추가할 객체들의 인터페이스 역할을 한다.

ConcreteComponent: 제공할 서비스의 베이스가 되는 컴포넌트를 정의한다.

Decorator: Component 객체에 대한 참조자를 관리(인스턴스 변수로 소유)하면서 Component에 정의된 인터페이스를 만족하도록 인터페이스를 정의한다.

ConcreteDecoreator: Component에 추가할 내용을 구체적으로 구현한다.

4.     Code Example

 위젯을 그리는 프로그램을 만든다고 가정하고 여러가지 위젯 중 캘린더 위젯을 만들고 위젯은 Scroller, Boarder로 구성할 수 있다.

[Component]

class WidgetComponent {

public:

    virtual void Draw() = 0;

};

[ConcreteComponent]

class CalendarWidget: public WidgetComponent {

public:

    virtual void Draw() {

        cout<<"Draw Window"<<endl;

    }

};

[Decorator]

class Decorator: public WidgetComponent {

public:

    Decorator(WidgetComponent* comp): component(comp){};

    virtual void Draw() {

        component->Draw();

    }

private:

    WidgetComponent* component;

};

[ConcreteDecorator]

class BorderDecorator: public Decorator {

public:

    BorderDecorator(WidgetComponent* comp)

    :Decorator(comp){}

    virtual void Draw() {

        Decorator::Draw();

        DrawBoarder();

    }

private:

    void DrawBoarder() {

        cout<<"Draw Boarder"<<endl;

    }

};

class ScrollDecorator: public Decorator {

public:

    ScrollDecorator(WidgetComponent* comp)

    :Decorator(comp){}

    virtual void Draw() {

        Decorator::Draw();

        DrawScroll();

    }

private:

    void DrawScroll() {

        cout<<"Draw Scroll"<<endl;

    }

};

[실행]

int main(int argc, const char * argv[]) {

    WidgetComponent* widget = new CalendarWidget();

    widget = new BorderDecorator(widget);

    widget = new ScrollDecorator(widget);

    widget->Draw();

    return 0;

}

[실행 결과]

Draw Window

Draw Boarder

Draw Scroll

Design Pattern의 효과
Design Pattern을 통해 내가 만들 소프트웨어에 어떤 class가 존재해야 하고 그들의 관계는 어떠해야 하는지를 빠르게 이해하고 접근할 수 있다.
최근 언어들은 Hello World!! 부터가 아닌
최소한의 구조가 갖춰진 프로젝트 형태에서 시작함
 
Design Pattern을 재사용하는 이유
재사용: 생산성(보다 빠른 시간안에 소프트웨어를 출시하기 위함)과 신뢰성(그 패턴이 오랫동안 사용되어 와서 대부분의 문제가 정리되었다고 봄) 증가, 개발 시간 감소
디자인 패턴도 재활용, 재사용한다.
 
Design Pattern
흔히 발생하는 문제에 대한 솔루션을 재사용한다. 특정 프로그래밍 언어의 특징을 반영하지 않는다. 코드와 밀결합된 것이 아니다. Class와 그들의 상관관계에 대한 것이다. 알고리즘의 상위개념이다.
객체지향 디자인 패턴: 전형적으로 클래스나 오브젝트 간의 상관관계를 보여준다.

 
Adapter Pattern
신입 사원이 주로 쓴다.
목표: 기존의 클래스, 코드를 수정하지 않으면서 서로를 연결하기 위해 만들어졌다. (건들면 안 되는 입력 파라미터 3개를 요구하는 adaptee와 입력 파라미터 1개를 요구하는 adaptee를 연결해주기 위해 중간에 adapter를 끼워 맞추는 것이다.) 양립 불가능한 인터페이스를 가진 클래스들을 작동하게 하기위한 코드이다.
Adapter 클래스가 adaptee를 호출한다.
c++에서는 adapter class가 어댑티 클래스를 상속했다.
C++은 다중 상속이 됨( istream, ostream을 상속받는 iostream)
다중 상속이 안되면, mixing class를 사용함.
Adaptee: 수정X
Adapter: 우리가 작성, 수정하는 코드
1대1의 관계
Adapter class가 adaptee를 부르고 클라이언트의 입력을 연결해주는 역할
adaptee, 클라이언트를 안 고쳐도 됨!
 
Façade Pattern
1대n의 관계
겉면만 모양을 유지하고 뒤는 좋게 바꾸는 것이다.
목적: 사용자의 interface는 바꾸지 않겠다.
Client가 Façade class를 호출하면 파사드는 필요에 따라 다른 클래스를 호출한다. 파사드 클래스의 메소드 안에서 클래스의 객체를 생성한다.
성능이 좋지 못하다는 단점이 있다.
사용자가 복잡한 서브 시스템에 직접 접근하지 못하도록 한다. 예쁜 인터페이스로 입구를 차단해버림
내부에 작동하는걸 외부에 보여줄 필요가 없다.
모든 프로그래밍 언어의 기본 철학
Information hiding, Encapsule 좋음
 
Decorator Pattern
객체가 동적으로 움직이고 있는 중에 특정 기능을 추가하고 뺄 수 있다. 게임에서는 아이템이나 무기를 추가할 수 있도록 하는 디자인 패턴이다. 즉 기능을 추가할 수 있다.
1대n의 관계

Component를 base로 하여 concreteComponent와 decorator class를 생성하고 decorator를 base로 하는 concreteDecorator class를 생성한다. Decorator는 component 클래스와 has relationship 관계이다. 이때 ConcreteComponent는 가장 기본적인 아무것도 없는 캐릭터이고, concreteDecorator는 갑옷, 칼, 총 등 추가되는 아이템들이다.
ConcreteComponent: 가장 기본적인 아무것도 없는 캐릭, 먼저 실행됨
ConcreteDecorator: 갑옷, 칼, 총 등 추가되는 아이템들
 
Singleton
반드시 하나의 객체만 존재해야 한다. 절대로 이 클래스에서 만들어진 객체가 두 개 이상이면 안 된다. Ex) 자원을 관리하거나 중요한 데이터를 관리하는 프로그램에서 사용됨, 하드웨어의 자원은 물리적으로 하나이다. 두개 이상의 제어가 발생할 경우 충돌한다.
 
최근에 나온 소프트웨어 디자인 관련 책: clean code, clean, architecture
디자인 패턴은
SW 설계에 있어 시행착오를 줄여 줌
Design Pattern은 매우매우매우 호불호가 갈릴 수 있음
클래스 다이어그램으로 시각화
언어마다 구조가 다를 수 있음 -> Dependency
 
디자인 패턴의 비판
1. poor language
언어가 별로 안 좋아서 기능적을 부족한 게 많아서 디자인 패턴을 고민하는 것 아니냐?
23개 중 16개 의미가 없었음
-> 그래도 7개는 의미 있네, 쓰기 싫으면 쓰지마 (호불호 갈림)
2. 불필요하게 복잡성만 높인다.

디지털 노마드의 정의

디지털 노마드: (직장이 아닌 다른 곳으로 떠나) 원하는 곳에서 개발하거나 일할 자유를 말한다. 유목민이라고 말하기도 한다.

어디에서 일하는 지를 정하는 대신 그 선택에 책임을 져야 한다.

디지털 노마드를 찬성하는 고용주의 입장

고용주들은 전세계적으로 최고의 인재를 모을 수 있다. 중견, 중소 기업에서 국내의 인재들을 데려오기 힘들 때 다른 나라에 있는, 예를 들어 비교적 인건비가 저렴한 인도에서 경쟁력 있는 인재를 고용할 수 있다.

디지털 노마드를 찬성하는 개인 개발자의 입장

편리하다는 장점이 있다. 이동시간이 감소된다는 점, 집을 새로 마련하지 않아도 된다는 점, 주거비. 식사. 교통 면에서 직장에 출근하여 직장에서 일하는 것보다 비용이 적게 든다. 즉 경제적 부담이 감소된다. 또한 근무 시간이 자유롭다는 장점이 있다.

Covid 이전과 이후의 디지털 노마드를 찬성하는 이유

Covid 이전에는 훌륭한 인재를 채용하기 위해 디지털 노마드를 했다면, Covid 이후에는 직원을 한 곳에 모아두지 않는다면 돈을 안써도 된다는 것을 깨닳았기 때문이다. 예를 들어 직원을 한 곳에 모아뒀을 때 들어가는 부동산 값, 커피 값, 식당 등 업무 환경을 위해 드는 잡다한 비용이 많다.

이전에는 직원의 움직임, 장소에 벗어나는 것 등에 압박

이후에는 거점 오피스 등이 많이 생기고 장소 압박이 적다 (문화적 변화)

어디서 디지털 노마드를 하는지, 그리고 그 기준은?

기준

1.인터넷이 빠른가?

2.물가가 싼가?

장소

일본, 캘리포니아: 집 가격이 비싸서 비대면을 좋아함

한국은 치안이 괜찮은편이다. 그래서 서울로 많이들 디지털 노마드 하러 온다.

제주도에서 가장 열심이다.

제주도에는 다음, 카카오 본사가 있다. 장소에 독립적인(회사가 어디 있든 문제없는) 개발사들을 위치시켜 지역 활성화를 유도한다. 제주도가 그 예시이다.

워케이션: work+vacation: 휴양지 등에 회사를 위치시킨다.

디지털 노마드 tools

Slack은 Collaboration을 위한 것이다. 업무용 채팅 소프트웨어이고 개발 도구와 연동이 된다. 과거의 기록을 찾아볼 수 있다.

구글 드라이브는 Team Work를 위한 것이다.

Zoom은 Communication을 위한 것이다.

Doist(Item Manager), TRELLO(Project Manager), Parabol(Agile Meeting)

보안 때문에 웹에서 IDE를 구현하는 경우도 있음

애초에 코드가 세어 나가지 않도록

애자일 스크럼, 깃허브 etc...

기업에도 채팅 시스템 존재:

채팅 로그, 트래픽 분석을 통해 직원의 영향력 등을 파악함

다 감시하고 인사과에서 유용하게 씀

실제로 네이버 비즈니스 플랫폼은 기업들한테 제공하는 서비스

기업들은 빠르게 서비스를 만드는 것이 중요함

-> 웹 서비스 구현을 전부 오픈소스로 해버림

    -> 서비스 사용화 시간 단축

미네르바 대학

크게 5개 학과로 나눠 여행하면서 온라인으로 수업 받음. 여러 나라로 여행을 다니면서 교육을 함. “비판적인 사고, 창의적인 사고, 효율적인 소통”

전 세계 7개의 도시를 순환하면서 학생들이 함께 생활하는 하이브리드 주거 모델을 제공함.

철학: 고등 교육의 위기, 꼭 대학에서 해야 할 필요가 없음, 대학에서는 실용적 지식을 가르쳐야 함, 글로벌 문화, 다 차원적인 교육, 우리 시대의 가장 복잡한 문제를 해결하는 데 필요한 광범위한 지식과 실용적인 기술

MIT는 서로 다른 전공의 사람들이 모여 협업하고 인프라 제공에 대학의 의미가 있다고 함.

인류 존속에 관한 문제 해결을 위한 학과 존재함.

과 5개: 예술&인문학, computational sciences(컴퓨터를 도구로 삼아 문제를 해결함, engineer 계열은 아님), 자연 과학, 사회 과학, 비즈니스

computational sciences: 컴퓨터로 사회 문제를 분석한다. Computer science가 아니다.

문제를 찾아서 해결하는 방식으로 가르침. Learn the critical skills you need to make evidence-based, data informed decisions.

Tokbox: Active Learning Platform

Uncertainty: 불확실성에 대한 대비로 개인의 능력을 기른다

불확실한 미래에 대해 개인 주도적 문제 정의 및 해결을 위함

여행은 이러한 문제정의에 대한 도움

프랑 에꼴 42: 교수가 없는 교육 기관 -> 한국에서도 모방해 42서울을 만듦.

1. unittest

 Unittest를 처음 경험해보기 때문에 먼저 매우 간단한 코드를 통해 unittest를 해보았다. myCalc.py 파일에 input 파라미터를 두 개를 받아 더한 값을 return 해주는 add함수와 input 파 라미터로 두 개를 받아 첫 번째 input에서 두 번째 input을 뺀 값을 return 해주는 substract 함수 를 정의했다.

그리고 나서 unittest를 위한 test.py 파일을 작성했다. unittest.TestCase로부터 파생된 MyCalcTest 클래스를 생성했다. 그리고 test_add와 test_substract 테스트 메서드를 작성했고, 그 안에서 self.assertEqual()를 사용하여 결과를 검사했다. 마지막 줄에서 unittest.main()이 실행되면, 테스트 메서드들이 실행되게 된다.

여기서 주의할 점은 테스트 메서드의 이름은 반드시 test로 시작해야 한다는 것이다. 그래야 테스트를 실행할 때 해당 메서드가 누락되지 않고 정확히 테스트 케이스로 인식이 된다.

unittest 모듈의 TestCase 클래스틑 assertEqual 말고도 assert로 시작하는 많은 메서드를 제공한다.

MyCalcTest 클래스는 TestCase 클래스를 상속하고 있기 때문에 부모 클래스인 TestCase가 제공하는 모든 메서드를 self를 통해 접근하여 호출할 수 있다.

IDLE에서 test.py를 실행한 결과는 다음과 같다. 두개의 메서드를 통과했기 때문에 점( . )이 2개가 찍히는 것을 볼 수 있다.

참고로 점( . )대신에 좀 더 자세한 피드백을 받고 싶다면 -v 옵션을 붙여서 테스트를 실행하면 된다.

test_add 메서드와 test_substract 메서드가 잘 실행된 것을 볼 수 있다.

test_add 메서드를 아래와 같이 수정하고 test.py 파일을 실행하면,

테스트가 실패했다고 알려주며 어떤 부분이 틀렸는지를 피드백 해준다.

2. unittest.mock

 mocking이란 단위 테스트를 작성할 때 외부에 의존하는 부분을 임의의 가짜로 대체하는 기법 이다. 즉, 외부 서비스에 의존하지 않고 독립적으로 실행이 가능한 단위 테스트를 작성하기 위해 서 사용되는 테스팅 기법이다. 다른 사람의 코드를 사용해 짠 코드를 테스트해야 하는데 아직 다 른 사람이 코드를 다 작성하지 못했을 때 사용한다.

test.py를 수정하여 unittest.mock를 사용해 코드를 작성하고 실행시켜 보았다. 결과는 아래와 같다.

20과 10을 더하면 30이지만 mock을 통해 실패하지 않고 정상이라 판단되었다.

 TDD 기법에 대해 공부한 후 직접 unittest를 해보니 더 잘 와닿는 것 같다. 평소에 소프트웨어 를 작성하는 방식과는 조금 달라 신기했지만 생각보다 괜찮은 기법이라고 여겨진다. 다음에 소프 트웨어를 개발할 대 TDD 기법을 이용해 해봐도 좋을 것 같다는 생각이 들었다.

Test and Enhancement: 정해진 기법은 아니다. 회사마다 다르다.

개발은 잘 작동하면 끝인가?

1.     Reliability(신뢰성): 믿을 수 있나? 24시간, 365일 잘 동작하는가?

2.     Sustainability(지속 가능성): 한번 만들면 계속 사용됨, 유지보수 측면에서 계속 사용가능한가?

3.     Performance(성능): 더 빠르게, 더 적은 메모리 관리, 더 적은 리소스

4.     Readability(가독성): 다른 사람이 코드를 읽을 때 쉽게 읽을 수 있는가?

TDD에 대해 설명해라

TDD는 test 프로그램을 만들고 test를 통과하는 것을 목표로 한다.

일단은 주어진 입력에 맞춰 test를 통과하는 코드를 짜자. 주어져 있는 요구사항에 충실해라.

애자일 스크럼이라면 우리가 이번 스프린트에서 달성해야 할 백로그 존재하고, TDD에서는 요구사항이 있다.

What is TDD?

TDD란 요구사항을 담은 테스트 코드를 작성하고 이 테스트 코드를 통과하는 product 코드를 짜는 기법이다. 일단은 주어진 입력에 맞춰 test를 통과하는 코드를 짜는 것이 목적이다.  요구사항들을 쪼개 여러 사이클을 돌도록 하고 테스트 코드와 product 코드는 사이클을 돌면서 점점 커진다.

테스트 기반 개발은 익스트림 프로그래밍의 개념과는 관련이 있다.

프로그래머는 또한 이 개념을 이전 기술로 개발된 레거시 코드를 개선하고 디버깅하는 것에 적용한다.

TDD과정

1.     이번 사이클의 요구사항을 테스트하는 코드를 먼저 짠다. 내가 만들 프로그램의 함수, 클래스, 메소드를 호출하고 원하는 결과가 나오는 지를 test하는 코드를 먼저 짠다. 이 과정을 통해 본인이 짜야 할 프로그램에 대한 이해가 더 견고해질 수 있다. 또한 아무것도 없는 상태에서 test 코드를 짜므로 객관성을 유지할 수 있다. (본인이 짠 함수나 클래스에 애정이 생겨 의도치 않게 방어를 하는 경우가 있음) 테스트 코드 개발자와 product 코드 개발자를 다른 사람으로 한다면 더 객관적일 수 있다. 이를 pair programming이라고 한다.

2.     테스트 코드를 실행해 성공하는 지 실패하는 지를 본다. 만약 성공할 경우 다시 테스트 코드를 짠다. 통과되는 것이 사실 이상하다.

3.     실패할 경우 test 코드를 통과하기 위한 product 코드를 작성한다. 이 과정에서 작성되는 코드는 완벽하지 않아도 된다. Test를 통과하는 코드를 작성하는 것이 최우선이고 구조를 다듬고 성능을 높이는 refactoring은 나중에 한다.

4.     작성한 product 코드에 대해서 테스트를 실행하고 테스트 실패 시 다시 product 코드를 작성한다.

5.     테스트를 모두 통과하면 코드를 refactor, 청소한다. 이러면 한 사이클이 끝나는 것이다. 예를 들어 자주 등장하는 메소드들을 묶어 클래스를 만들거나 (가독성을 위해) 이름을 정리한다, duplication을 제거한다.

6.     이후 사이클에서는 기존의 테스트 코드, product 코드에 새로운 요구사항에 대한 코드를 추가하는 방식이다. 따라서 test 코드가 점점 커진다. 이전 사이클의 테스트 코드는 그대로 놔두고, 새로운 요구사항을 만족시킬 테스트 코드를 추가한다. 한 사이클마다 전체 기능의 3%, 6%씩 만들어 나가는 것이다.

TDD와 Agile의 관계

Cycle을 한번 통과하면 요구사항에 대한 test를 마친다. 자연스럽게 cycle-based로 돌아가는 것이 agile의 sprint 기법하고 잘 맞는다. Sprint의 백로그를 TDD의 요구사항으로 볼 수 있다. 테스트 결과를 보고서로 제출하는 것이 document를 줄이고자 하는 agile과 알맞다.

Test code자체가 document가 될 수 있다. (가독성이 좋다.)

다른 시각에서의 TDD

Refactoring 단계를 크게 보는 경우도 있다. Refactoring은 성능을 끌어올리는 단계이다. 이 단계에서 반복적으로 발생하는 코드를 함수로 묶거나 자주 등장하는 메소드들을 묶어 클래스로 만들어duplication을 없애고 class를 만들고 이름을 바꾼다.

Refactor 단계가 점점 커지면서 Design Pattern 등을 함

TDD 원칙: 요구 사항을 최소한으로 하기.

한 사이클에서의 테스트 양을 적게 해라. 예를 들어 함수 몇 개씩, 클래스 하나의 메소드 몇 개씩. 이것의 효과는 디버깅하기가 편리하다는 것(요구 사항이 적으므로 어디서 오류가 발생하는 지를 찾기가 편함), 별도의 문서가 없어도 테스트 코드를 통해 이해할 수 있다.

TDD in Python

원시적인 방법: shell을 이용하여 테스트하기, 예상되는 값을 이용해 테스트하기

Assert를 이용하여 테스트하기: 조건이 부합하면 통과하고 아니면 프로그램을 중단한다. (AssertionError)

Ex) assert p.cost == 183419.0

unittest 라이브러리를 사용한다. 이는 테스트를 자동화해주고 체계적인 테스트를 해주며 테스트 레포트가 있다. (Ran 2 tests in 0.002s OK.)

Test case: 테스트할 것을 테스트 케이스로 정리

Test Runner: 전체적인 소프트웨어 테스트를 수행함. 구체적인 항목들이 있는 suite를 실행

Test Suite: 어떤 테스트를 해야 할지에 대한Test case들을 가짐. 구체적인 항목을 집어넣음.

Python Unittest 과정

1.     Testcase를 베이스 클래스로 하는 테스트 클래스 생성

2.     테스트할 것들을 메소드로 만들어 나열

3.     각 메소드 내의 assertEqual가 에러를 확인. 에러가 나더라도 중단시키지 않고 끝까지 테스트한다.

C++: google test, cppUtest

unittest.Mock

다른 사람의 코드를 사용해 짠 코드를 테스트해야 하는데 아직 다른 사람이 코드를 다 짜지 않았을 때

Pair programing 중에 아직 팀원의 테스트 코드가 작성 중 일 때

팀플 중에 내가 일부만 담당했을 때

진짜 오브젝트의 동작을 모방한 것.

외관만 짜여진 것이다. 실체가 아닌 껍데기, prototype

Profiling (computer programming): 동적 프로그램 분석: 성능

Software을 분석하는 것이다. 어느 함수가 얼마나 시간을 썼고, 메모리를 얼만큼 썼는 지 등을 분석한다. 알고리즘을 최적화하는 데 도움을 준다. 비동기 및 병렬 처리에 도움을 준다. Profiler는 시간을 잡아먹는 애들을 처리하기도 한다.

Python에서 re, cProrfile 라이브러리를 통해 할 수 있다.

RunSnakeRun, SNAKEVIZ(Profiler Visualization Opensource for Python)

Profiling: 성능 얘기

Coding Guideline (or Convention): 가독성을 위해

권장하는 프로그래밍 스타일, 파일 이름, 디렉토리 경로, 중괄호를 어디에서 여는 지 등

가이드라인이 문서화되어 있다.

Install one of the recommended software

LibreOffice 7.5.2버전을 설치했다. LibreOffice Draw는 무료 오픈 소스 벡터 그래픽 편집기이다. The Document Foundation에서 개발한 LibreOffice 오피스 제품군에 포함된 응용 프로그램 중 하나이다. LibreOffice Draw는 모양 도구, 직선 및 곡선 도구, 다각형 도구 등을 사용하여 복잡한 도형을 만드는 데 사용할 수 있다. 이를 이용해 순서도, 기술 도면, 브로셔, 포스터, 맞춤형 사진, 사진 갤러리 및 앨범을 만들 수 있다.

다음은 LibreOffice를 설치한 후 LibreOffice Draw를 실행시킨 화면이다.

Drawing a picture for the one of your previous software developments work

LibreOffice Draw를 이용해 지난 학기 디자인적 사고 수업에서 만든 프로토타입에 대한 그림을 그려보았다.

(프로토타입에 대해 더 알아보고 싶다면? https://endlesschallengerspoiuy3.tistory.com/124)

이 프로토타입은 미래에 우리 생활을 더 개선할 제품이라는 주제로 기술력과 윤리적 문제가 모두 해결되었다는 가정하에 이루어졌다. 우리 조는 간단한 질병은 집에서 휴대폰을 이용 해 자가 진료할 수 있고 휴대폰으로 매일 자신의 건강을 검진할 수 있는 어플의 프로토타입을 만들었다.

Design by Figures

소프트웨어를 설계할 때 말 대신 그림으로 표현한다.

같은 말을 하더라도 서로 다른 생각을 하고 있을 수 있기 때문에 그림으로 표현하는 것이 좋다.

그럼, 그림으로 표현하는 것이 좋은 사례로는 무엇이 있을까?

1. Structure of Data (Data Structure)

자료 구조는 데이터를 효율적으로 사용할 수 있도록 컴퓨터에서 데이터를 구성하는 특정 방법이다.

2. Algorithm

알고리즘을 플로우 차트로 표현할 수 있다. 플로우 차트는 워크 플로우나 프로세스를 나타내는 일종의 다이어그램이다. 순서도는 다양한 종류의 박스들로 단계를 표시하고 박스를 화살표로 연결하여 순서를 보여준다. 다양한 분야에서 프로세스 또는 프로그램을 분석, 설계, 문서화 하는 데 사용된다.

3. Database

데이터 베이스는 데이터의 모음이다. 표(table)로 정보를 표현하고 표들 간에 관계를 맺고 있다. 

SQL: 구조화된 데이터를 Query하는 언어이다. (table based)

NoSQL: No or Not-only SQL. 고성능 비관계형 데이터 저장소를 나타내고 사용 편의성, 확장성, 복원력 및 가용성 특성에 탁월하다. 구조화되지 않은 데이터 또는 반구조화된 데이터를 Key-Value 쌍(pair) 또는 JSON 문서에 저장하는 경우가 많다.

4. Computer Network Diagram

5. Message Sequence Chart

1. 개념 정리

Agile이란?

고객의 요구에 빠르게 반응할 수 있는 개발 방법이다. 공정과 도구보다 ‘개인과 상호작용’을, 포 괄적인 문서보다 ‘작동하는 소프트웨어’를, 계약 협상보다 ‘고객과의 협력’을, 계획을 따르기보다 ‘변화에 대응하기’를 가치 있게 여긴다.

현업에 종사하는 사람들이 말하는 애자일 방식 사용의 장점은 다음과 같다. - 업무공유와 의사소통이 매우 잘 진행되어서 빠른 대처와 피드백이 가능해졌다.

- 기존에 본인 업무가 아닌 다른 업무를 경험해 보는 것과 필요 시 서로 도울 수 있다는 점이 좋았다.

- 팀원들 사이에 업무 진행상황과 진도를 바로 확인할 수 있으며 필요시 업무지원 요청을 바로 할 수 있다는 점이 좋았다.

- 애자일 미팅을 통해 서로의 고충도 공유하고 일의 진행이 매끄러워졌다.

- 업무공유가 효율적이며 팀원끼리의 유대관계가 좀 더 좋아질 수 있었다.

- 팀원들과 오픈마인드로 좀 더 교류를 할 수 있게 되었으며 팀워크가 좀 더 향상된 것 같다.

- 더 많고 다양한 종류에 업무를 접하고 지식공유를 통해 새로운 것을 배워나가는 데 있어서 많은 도움이 되었다.

- 밝은 분위기, 많은 대화, 타 모듈에 대한 관심, 적극성이 생긴 것 같다.

Scrum이란?

Agile이 개발 방법이라면 스크럼은 agile을 위한 도구이다. 스크럼은 럭비에서 유래된 용어이다. 팀 안에서 서로 공을 주고받으며 하나가 되어 필드를 나아가는 럭비의 모습을 본받았다. 스크럼 은 3~9명의 개발자로 구성된 팀을 위해 설계되었다. 스프린트(sprint)라고 불리는 업무 주기를 1~4주에 한 번씩 Scrum Master 지휘하에 반복한다. 이는 버전이 1~4주마다 하나씩 나오는 것이 라고 생각하면 된다. 그리고 Daily Scrum이라고 매일 모여서 이야기를 나눈다. 주로 전 날에 했던 일들을 이루었는지, 못 이루었다면 이슈는 무엇인지 등 진행사항에 관해 이야기한다. Scrum의 구 성요소로는 ‘Focus, Openness, Respect, Courage, Commitment’가 있다.

2. Agile case: Kakao agile coach part

  카카오에는 애자일코치파트가 존재한다. 애자일코치파트의 업무는 크게 두 가지이다. 첫 번째는 애자일코치로서 팀을 코칭하고, 일하는 방식을 더욱더 성숙하게 하기 위한 일들을 수행하는 것이 다. 카카오 크루들이 애자일 마인드셋, 가치, 원칙, 실천법들을 올바르게 이해하고 실행할 수 있도 록 돕는다. SDLC(Software Development Life Cycle)를 더욱 민첩하게 하기 위한 문화, 표준, 도구, 프로세스, 실천법들을 발굴하고 적용한다. SDLC 내에 다양한 피드백 루프를 구성할 수 있도록 하 고, 이를 지속해서 이어나갈 수 있도록 돕는다. 두 번째는 첫 번째 업무를 뒷받침하는 다양한 협 업도구들을 안정적으로 운용하고, 기민함에 날개를 달아줄 수 있는 다양한 도구의 활용법, 애자일 적용 사례들을 발굴하고 사내에 전파하는 업무를 수행한다. 효율적인 플랫폼 운영을 위한 다양한 도구(플러그인, 운영툴, 자동화 도구, 시스템 간 연동 등)를 개발한다. 도구에 대한 교육 업무(도구 기초 교육, 애자일 프랙티스를 적용할 수 있는 실무 교육 등)을 진행한다.

  이러한 카카오의 애자일 조직을 통해 성공한 소프트웨어가 있다. 그것은 ‘카카오뱅크’이다. 2014 년 카카오는 모바일 송금 서비스를 제공하는 ‘뱅크 월렛 카카오’와 모바일 결제에 중점을 둔 ‘카 카오 페이’를 거의 동시에 출시하며 핀테크 시장에 진입했다. 하지만 뱅크 월렛 카카오 서비스는 2016년 12월에 종료되었다. 가상 계좌를 만든 뒤 돈을 충전해야 하는 등 불편함이 컸기 때문이다. 또한 카카오페이 역시 삼성페이나 네이버 페이에 밀렸다. 카카오는 이러한 실패에서 얻은 교훈으 로 직관적인 사용자 경험에 초점을 맞춰 빠르게 대응하는 가벼운 전략인 ‘애자일 조직문화’를 택 했다. 하나의 서비스나 상품 개발을 위해 필요한 각 분야의 업무 담당자를 한 곳에 모아 놓아 부 서 간 경계를 허물고 필요에 맞게 팀은 구성해 업무를 수행하였다. 이와 같은 ‘agile’ 방식으로 카 카오는 카카오 뱅크를 성공시켰다.

  카카오 외에도 국내에서는 삼성 SDS, KB 국민은행, 현대카드와 SK이노베이션이 애자일 업무 방 식을 적용 중에 있다. 국외에는 구글, 스포티파이, ING은행, 넷플릭스, 페이스북, 아마존, 알리바바, 샤오미, H&M, 자라, 교세라 등이 있다.

Design(& Development) Process

1. Software development paradigm

과거에는 소프트웨어를 직접 팔기 위해 개발하였다. 즉 소프트웨어 자체가 수익의 목표였다.

ex) Microsoft Windows & Office, Hancom Hangul Word Processor, Adobe Photoshop, Packaged Game

또한 소프트웨어를 개발하는 데 긴 시간이 걸렸고 많은 사람과 돈을 요구했으며 언제까지 완성할 지에 대한 데드라인이 엄격했다.

오늘날은 서비스를 위해 도구적 관점으로 소프트웨어를 개발한다.

ex) Google & Naver Search Service, Free Game with Pay Items, Daum KaKao & Line Instant Messenger, Ad-based Free Services

또한 오늘날 서비스는 가능한 빨리, 제한된 인력과 돈으로 시장 요구를 충족시키며 개발된다.

2. Waterfall process

Waterfall Process는 위에서 아래로 흐르기 때문에 설계가 잘못되면 다 꼬인다. 따라서 최대한 앞쪽에서 문제가 없도록 노력해야 한다.

선행 단계가 완벽할 때는 좋다. 하지만 서비스가 중심인 오늘날에는 시장, 고객의 마음이 바뀌는 경우가 허다하다. 

따라서 오늘날에는 Waterfall Process는 적합하지 않다.

3. Agile

"어떻게 하면 소프트웨어를 잘 만들어낼 수 있을까?"에 대한 고민을 하여 만들어낸 소프트웨어 개발 방법이자 철학, 규정, Manifesto이다.

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

Agile Manifesto 12 Principles (9개로 생략)

1. 상사가 아닌 고객을 만족시켜라.

2. 변화를 거부하지 말고 받아들여라.

3. 문서가 아닌 소프트웨어로 진행사항을 보여줘라.

4. 개발자가 아닌 사람들과도 대화를 많이 해라.

5. 프로젝트를 동기부여가 된 개인들로 구성해라.

6. 얼굴을 보며 대화하는 것이 가장 효과적이다.

7. 작동하는 소프트웨어로 중간 과정을 보여줘라.

8. 스폰서, 개발자, 사용자들이 유기적으로 연결되어 있어야 한다.

9. 끊임 없이 스스로 발전 시켜라. 자기 분야에 관심을 가져야 한다.

4. Scrum

Scrum은 에자일이라는 철학을 반영한 방법론이다.

Product가 가져야할 것들을 Product Backlog에서 명시한 후 우선 순위대로 여러 Sprint로 쪼갠다.

하루에 한번씩 모여 어제 해야 할 것들을 이뤘는 지, 새로 생긴 이슈가 무엇인 지 등을 이야기하는 Daily Scrum이라는 것이 존재한다. 이로써 시장의 반응을 빠르게 받아들일 수 있다.

제일 중요한 것은 1~4주 마다 하는 Sprint 과정을 통해 데모, 즉 버전이 하나씩 나온다는 것이다.

이러한 Agile과 Scrum의 간단한 도구로 post-it이 있다.

5. DevOps

좋은 기술로 원하는 소프트웨어를 개발하기 원하는 개발자와 안정적으로 소프트웨어를 운영하려는 운영자가 합을 맞춰 잘 돌아가야 한다. 이를 위해 나온 개발 철학이자 문화가 DevOps이다.

DevOps의 가장 핵심적인 특징은 모든 과정이 자동화된다는 것이다.

DevOps는 더 짧은 개발 사이클, 증가된 개발 효율, 더 믿을만한 릴리즈를 목표로 한다.

아래의 사진을 보면 DevOps를 위한 많은 도구들이 소개되어 있다.

DevOps와 Agile을 비교해보자면 다음과 같다.

1. Playstation4의 운영체제 Orbis OS의 기반이 된 FreeBSD

 FreeBSD는 유닉스 계열 운영체제이며 리눅스처럼 서버 용, 데스크탑 용으로 쓸 수 있는 범용적 인 운영체제이다. 먼저 BSD에 대해 알아보면 BSD는 Berkeley Software Distribution의 약어로, 캘 리포니아 대학교 버클리 캠퍼스에서 유래한 데서 붙여진 이름이다. 여럿 버클리 출신 프로그래머 들이 버클리에 있던 시절에 BSD를 위해 FreeBSD를 만들었다. BSD의 역사는 1977년 빌 조이가 유 닉스 V6에 일부 추가 기능을 더한 것을 Berkeley Software Distribution이라 배포한 것을 시작으로 하는데, FreeBSD는 4.4BSD 기반의 386BSD에서 출발했다. BSD는 혁신적인 기술들을 도입하는 것 으로 유명했는데, TCP/IP의 BSD 소켓이나 가상 메모리, NFS, ZFS 등이 이에 해당한다. 그러나 BSD 는 AT&T와의 라이선스 문제 등이 있어 4.4BSD-Lite를 끝으로 FreeBSD, NetBSD, OpenBSD 등으로 갈라지게 되었다. FreeBSD는 리눅스와 마찬가지로 AT&T의 공식 유닉스 인증을 받지는 않았으나 코드의 기원이 UNIX에서 시작되었기 때문에 Genetic UNIX로 분류된다.

 FreeBSD는 C와 어셈블리 언어로 개발되었다. 또한 소수지만 매우 활동적인 커뮤니티를 가지고 있어 질문에 대한 답변도 웬만한 인기 리눅스 배포판보다 훨씬 빠르게 달린다. FreeBSD는 BSD 라 이선스를 따르는데 이는 리눅스의 GPL 라이선스보다 “Free”라는 단어를 포괄적으로 해석하여 자 유 소프트웨어라면 사용하는 것 자체가 제약 없이 자유여야 한다는 모토이기 때문에, 소스를 가 져다가 마음대로 바꿔 소스 공개를 하지 않는 채 상업적으로 이용해도 아무런 제약이 없다.

이러한 FreeBSD를 커스터마이징 하여 만든 운영체제인 Orbis OS는 PlayStation 4에서 사용하는 운영체제이다. PlayStation 5에서는 개선된 버전인 Orbis 2.0을 사용했다. 추가적으로 PlayStation 3 에서는 FreeBSD 8.2 기반인 CellOS를 사용했다.

2. SteamOS

 SteamOS는 Linux 기반 운영 체제의 공개 릴리즈이다. Steam Machines 및 Steam Deck의 기본 운영 체제이다. SteamOS는 일부 비공개 소스 구성 요소가 포함된 오픈 소스이다. SteamOS는 주 로 TV에 직접 연결할 수 있는 일반 PC 하드웨어를 사용하여 콘솔과 같은 경험을 제공함으로써 PC에서 떨어져 비디오 게임을 플레이하도록 설계되었다. Linux용으로 개발되고 Steam 스토어에서 구입한 게임을 기본적으로 실행할 수 있다. SteamOS는 마우스나 키보드 없이 게임을 하기 위한 것이므로 웹 브라우징과 게임 플레이 외에는 내장된 기능이 없다. OS는 기본적으로 Nvidia, Intel 및 AMD 그래픽 프로세서를 지원한다.

 2013년 12월에 출시된 SteamOS 버전 1.0과 2.0은 GNU 데스크탑이 있는 Linux 의 Debian 배포 판을 기반으로 한다. Valve는 SteamOS를 통해 개발자가 Linux 게임 옵션을 더 잘 지원하기 위해 Linux 호환성을 릴리스에 통합하도록 권장했다.

 가장 최근 버전인 SteamOS 3(Steam Deck 하드웨어)이다. 2022년 3월, Linus Tech Tips는 세 가지 게임 벤치마크를 사용하여 Steam Deck에서 SteamOS 3의 성능을 Windows 10과 비교했다. Hitman 3은 Windows 10에서 평균 19fps, SteamOS 3에서 평균 34fps를 기록했다. Doom Eternel에서 SteamOS 3은 평균 60fps를 기록한 반면 Windows는 평균 47fps를 기록했다. Elden Ring은 Windows, SteamOS 3 각각 평균 30fps, 평균 37fps를 기록했다.

SteamOS가 당면한 문제

 SteamOS가 가진 문제점의 첫 번째는 낮은 호환성이다. 우선 SteamOS는 다양한 시스템에서 설 치되어 게임을 구동해야 하는 형태이다 보니 하드웨어 호환성이 다른 콘솔 게임기보다 중요하다. 하지만 리눅스를 기반으로 하기 때문에 기존 리눅스에서 생기는 호환성 문제는 여전히 산적해 있 으며, 특히 게임 성능에 절대적인 영향력을 가진 그래픽카드 중 상당한 점유율을 가진 Radeon 그래픽카드가 SteamOS에서 부팅이 되지 않거나 설치가 되더라도 Big Picture 인터페이스가 흐려 지는 문제 등, 제대로 동작하지 않는 사례가 많다. 또한, 상대적으로 지원이 원활하게 이루어지고 있는 지포스 그래픽카드 또한 SteamOS가 가진 호환성 문제에서 벗어나기 어렵다. G80 세대 이후, 즉 지포스 8000시리즈 이후 출시된 그래픽카드만 제대로 지원되는 문제는, 시기가 지난 부품을 게임용으로 재활용하고자 하는 이들이나 저렴한 시스템을 구축하고자 하는 이들에게 아쉬운 부분 이라고 생각된다.

 두 번째 문제는 바로 '언어'이다. SteamOS는 공식적으로 다국어를 지원하지만 현재 영어 이외의 언어는 설정을 하더라도 제대로 표시가 되지 않는다. 또한 이 언어 문제는 내장된 브라우저를 통 해 인터넷을 하게 될 때 확실하게 알 수 있으며, 별도의 언어 설정과 언어 파일을 설치하면 지원 은 되겠지만 SteamOS가 정식으로 지원할 때 까지는 영어만 지원한다고 볼 수 있다.

 SteamOS는 아직 걸음마 단계라고 볼 수 있지만 기대가 되는 것 같다. 그 이유는 게임을 위한 최초의 전문 OS라는 점과, 온라인 마켓 플레이스로 구매와 동시에 플레이가 가능한 점은 현재 게 임을 편리하게 할 수 있는 콘솔 게임과 다양한 활용이 가능한 PC의 장점을 절충했기 때문이다.