[TIL] 22-09-30: Open Source, Git/GitHub

22-09-30 금요일
3주차

 

 

앞선 시간에 이미 들었던 내용이지만, 오늘은 조오오금 더 자세히 이야기 해주셨다.

그냥 컴퓨터 과학 교양처럼 가볍게 듣고 넘어가자. 단, 라이센스 개념은 숙지하자구!

 

 

 

---

 

 

✔️ OpenSource

세상에 공짜는 없어요

이미 했던 내용이지만, 더 자세히 말해주려고 한다!!

• 리눅스, LLVM, Swift, 쿠버네틱스, 파이썬, …
• Open ↔ Closed
• 빌게이츠 ↔ Open Source
• 활용한 오픈소스의 라이선스에 따라 출처 설명과 소스코드 공개가 필요하다.

라이선스는 전이가 된다!!

 

 

 

1️⃣ 정의

Open Source Software, OSS

아마존에서 오픈소스를 잘 써서 거기에서 정리한 문서를 중심으로 이야기한다.

• 누구나 자유롭게 확인, 수정 배포할 수 있는 코드 → 돈이 들지 않아야 한다.
• 동료평가 + 커뮤니티 기반 프로덕션 → 분산된 동시에 협업 방식으로 개발

MS가 이전에 만든 MS-DOS의 소스코드를 공개했다! 70년대에 만든 운영체제로 4년전에 공개되었다.

기계어에 가까운 코드로 코딩이 되어 있다… (ASM)

 

• 소스는 공개했는데, 빌드한 결과는 돈내고 사용해야하는 경우도 있다. 오픈소스 소프트웨어가 반드시 무료로 제공되는 실행 가능한 소프트웨어라는 의미는 아니다. 그러나 소스코드는 무료로 제공되어야 한다.
  • red hat (얼마 전에 IBM에서 인수했다)
  • Linux를 이용해서 만든 여러 오픈소스

 

• Swift PackageManager
  • safari 엔진에 들어간 기술이 WebKit이다.
  • WebKit을 쓴 회사가 또 있다. chrome!
  • Brave Brower, Whale…
  • 현재는 구글이 Blink 라는 것을 chrome 엔진으로 쓰고 있지만 계속 영향을 주고받고 있다

 

Free Software

자유 소프트웨어

• 프리 소프트웨어 운동

Linux

• ubuntu linux
• pop_os!
• mint
• ios - mac
• android - linux (추천하는 사람들이 많다)

 

 

2️⃣ 오픈소스 개발 모델의 작동방식

• 대부분의 오픈소스 프로젝트는 Github에서 호스팅되며, 여기에서 저장소에 접속하거나 커뮤니티 프로젝트에 참여할 수 있다.
• 소스코드에 대해서 스폰서 마크를 붙일 수 있고, 도네이션을 할 수 있다.

 

 

3️⃣ 오픈소스의 가치

동료평가

• 소스코드에 누구나 액세스할 수 있으며 오픈 소스 커뮤니티 자체도 활발하기 때문에 오픈 소스 코드는 동료 프로그래머에 의해 적극적으로 검토 및 개선될 수 있다.
• 침체 상태에 놓인 비공개 코드보다 훨신 살아있는 코드라고 간주할 수 있다.

투명성

• 오픈소스를 사용하면… 해당 코드에서 어떤 종료의 데이터가 어디로 이동했는지, 어떤 변경 사항이 있었는지 정확하게 파악해야 하는 경우 → 벤터에 의존할 필요x 직접 이를 확인 및 추적할 수 있다.

안정성

• 독점 코드의 경우 해당 코드의 업데이터,패치, 작업을 제어하는 단일 작성자 또는...(중략)

유연성

• 오픈소스는 수정하므로.. 자신의 비즈니스 또는 커뮤니티에서 겪고 있는 고유한 문제를 해결할 수 있다.

비용절감

• 오픈 소스 코드 자체가 무료이다.
• Ubuntu, Oracle, Red Hat과 같은 기업은 활용하는 경우 지원서비스, 보안 강화, 상호 운용성 관리와 같은 부분에 비용을 지불하게 된다.
  • Open Source = Free
  • Open Source Software = Free or not

오픈 협업

• 오픈소스 커뮤니티 → 다양한 지원, 리소스, 관점을 접할 수 있다.

 

 

 

 

4️⃣ 오픈소스 소프트웨어 라이선스 유형

 

 

✔️ Public Doamin License

• 누구나 제한없이 software를 수정, 사용, 상업화 가능
• 대부분 퍼블릭 도메인 오픈소스 소프트웨어의 제작자는 소프트웨어에 저작권을 부여하지 않기로 의도적으로 자발적인 결정을 내렸다.

→ copyleft

 

 

✔️ 허용적 라이센스

• 소프트웨어를 수정하거나 배포하는 방법에 대해 최소한의 요구사항이 포함되어 있다.

예시) Apache 라이선스, BSD(Berkeley Source Distribution) 라이선스

• 원본 소프트웨어는 저작권이 있고 오픈 소스이지만, 사용자는 수정된 버전을 상업화하고 재배포할 수 있다.

 

 

✔️ LGPL (GNU Library General Public License)

약소 일반 퍼블릭 라이선스

• 오픈소스 구성요소를 무제한으로 사용할 수 있다.
• GPL ↔ LGPL
  • 상용x ↔ 애플리케이션을 상용화할 수 있다.

 

 

✔️ Copyleft License

카피래프트 라이선스

• GPL이 대표적인 예
• 해당 라이선스의 조건은 상업화를 제한한다.
• 이걸 쓰면 애플리케이션과 함께 모든 새 소스코드를 릴리스 해야 한다. 그러나 애플리케이션을 내부에서만 사용하고 일반에 공개하지 않으면 그럴 필요가 없다.
• GPL 수정본을 판매할 수 있지만 구매자가 원하는 경우 추가로 재배포 할 수 있다.
• 새 코드의 저작권 설명에 모든 과거 코드 작성자의 기여한 바를 밝혀야 한다.

좀 복잡해서 잘 안쓴다.

 

 

 

5️⃣ 누가 오픈소스 소프트웨어를 규제하나요?

open source initiative(OSI)

• 오픈소스를 잘 쓰고 있는지 감시하는 기관이다. 글로벌 비영리 조직.

• MIT
• BSD
• Apache

 

 

 

---

 

 

 

✔️ Git

버전 관리 시스템

• 다 외울 필요가 없다.
• 터미널에서 굳이 입력할 일 많이 없다.
• 요즘엔 앱들이 잘 나와있다.
• GitHub의 많은 기능에 겁먹지 말아라.
• 재미있게 협업해보자!

 

 

 

1️⃣ DevOps

 

DevOps 이전의 방식: 폭포수 방식

한단계씩 차례로 내려가면서 프로젝트가 내려온다.

 

 

좀 더 나은 방법으로: Design Thinking

시작 단계에서 짧게 끊어서 진행해보자.

• 공감(Empathize) → 문제 정의(Define) → 아이디어 찾기(Ideate) → 시제품 만들기(Prototype) → 평가하기(Test)
• 반복하다보면 더 좋은 앱이 나오겠지

개발 전체를 짧게 끊어볼 수 없을까?

• 아이디어 검증만 하지말고 진짜 제품을 만들때에도 이 방법을 써보자.

 

요즘 대세는: Agile

스프린트가 하나의 단위로 돌아가면서 개발-디자인-테스트가 진행된다.

순간순간 이 기능에 대한 고민을 하니까 최종 목표가 무엇인지는 몰라도 최소화된 기능에 더 집중할 수 있다. 그 단계에서 바로 출시할 수 있다. 시장 상황과 사용자 반응을 보면서 또 다시 진행이 가능하다.

처음 최소한의 단계에서 비슷하게 출시하고, 반응 보고, 맞춰가고 … 계속 진행한다. 이러면 오히려 수익성이 더 늘어난다고 판단했다.

예전에는 개발팀과 운영팀이 따로 있어서 개발팀이 개발을 하고 출시를 하면 모든 소스코드를 운영팀에 넘겨준다.운영팀은 새로운 기능을 만드는 것이 아니라 버그를 고치거나 유지보수를 한다. 이게 폭포수 방식이어서 그런거다.

 

• Agile 소프트웨어 개발
  • 반복, 점진적인 접근 방식
  • 사용자의 지속적 피드백
  • 반복 작업을 수행하는 교차 기능 단위로 구성되며, 각 반복 작업은 작동 중인 제품을 생산한다!!
• 스프린트 단위로 계속 지속하는 것은 애자일이 아니다. 애자일은 하나의 최소 기능을 만들고 바로 출시하고 반응보고… 이게 애자일이다.
• 기술에 매몰x, 사람이 쓰는 것에 대해서
• 기획서x, 코드에 집중
  • 모든 제안은 1페이지에 다 적을 수 있게 해야한다.

 

Agile의 장점

• 변화하는 요구사항을 수용하기 쉽다
• 최종 목표가 확실하지 않은 프로젝트에 용이하다
• 보다 빠르고 고품질을 제공할 수 있다.
• 강력한 팀 상호 작용
• 사용자 의견을 수용하기 쉽다

디자이너와 개발자, 소통할 때 서로 같은 개념을 가지고 있어야 한다. 개념은 일치해야 한다. 내가 디자인에 대해서 왈가왈부하는게 아니다.

예를 들어 이미지를 심는게 나을지, 코드로 구현하는게 나을지 결정하는 것이다. 그래서 코드로 하는거면 개발자가 적당히 크기, 여백 같은걸 받아서 구현해서 보여주거나… 뭐 그런거다.

 

Agile의 단점

• 계획의 불확실성
• 팀을 구성하기 여러움: 능력자가 아니면 애자일에서 살아남기 힘들다…
• 비포괄적인 설명서
• 최종 제품이 요구사항과 다를 수 있음

 

 

Development + Operations = DevOps

요즘엔 Agile보다 DevOps

• 개발 + 운영
  • Coding + Publish, Trouble Shooting
  • Publish이 시간 많이 걸리니까 자동화해둔다. 그래서 배워야할 기능이 늘어나는 것이다. 그때그때 필요한 것을 배워서 따라야 하는게 맞다.
• 애플리케이션, 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화철학, 방식 및 도구의 조합
• 무한 경쟁. 고객을 더 잘 지원하고 시장에 좀 더 효과적으로 경쟁할 수 있다.

 

DevOps의 장점

• 속도
• 신속한 제공
• 안정성

 

앱개발자 입장에서 DevOps를 하는 툴?

• appcenter
• Github Actions
• Xcode Cloud

 

 

2️⃣ 프로젝트 관리 시스템의 종류

 

Version Control System(VCS)

버전 관리 시스템

• 사용자 프로젝트에 포함된 파일의 변경 사항을 추적할 수 있도록 돕는 방법론(methodology)이나 도구
• 하나의 스냅샷을 찍어서 버전명을 붙여 관리하는 것이다.
• 가장 단순한 방법은 작업 중인 파일의 복사본을 만들고 파일 이름뒤에 사용자가 손수 날짜와 시간을 붙이는 방식

혼자 개발할 때는 해볼만하다!

근데 같이는? 으음..

 

 

Distributed Version Control System(DVCS)

분산된 환경에서 협업을 위한 버전 관리 시스템

• 각 개발자가 중앙 서버에 접속하지 않은 상태에서 코드 작업을 할 수 있다.
  • CVS (Current Versions System)
  • SVN (Subversion)
  • Mercurial
  • Git

 

 

Configuration Management(CM)

• 형상 관리 도구는 애플리케이션의 여러 버전에서 서로 다른 구성(configuratino)을 다루기 위해 설계된 도구를 지칭한다.
• 형상 관리 시스템 자체가 버전 관리 시스템은 아니다.

 

Git

• Linus Torvalds가 2005년에 만든 분산 버전 관리 시스템
• 리눅스 커널 코드 관리하다가 답답해서 내가 2주만에 만들었다

 

Git 장점

• Small & Fast
  • C로 만들어서 빠르다. 서버와 통신x 대부분 작업이 로컬에서
• Distributed
  • 분산 버전 관리 시스템
• Data Assurance
  • 데이터의 무결성 보장
  • 모든 파일과 커밋은 체크섬 검사하고, 특정 히스토리를 변경하면 해당 커밋 ID와 모든 항목의 커밋 ID가 변경된다.
• Staging Area
  • 커밋 이전에 Staging area 혹은 index라 불리는 상태를 가진다.
  • staging을 만드는 것은 회사 자유이다.
• Free and Open Source

 

Git 단점

• 기존의 다른 버전 관리시스템보다 덜 직관적이고 배우기 어렵다
• 터미널 명령어(CLI)를 많이 사용하기 때문에 처음 배우기에 어렵다
• 초보자가 사용하기 쉬운 GUI 앱이 없다(근데 요즘엔 또 아님)

 

 

 

3️⃣ Git의 기본 흐름

• 원격레포에서 가져오거나(clone), 새로 만들거나(init) → 로컬 레포로 가져옴
• .git (hidden)

1. Working Directory
   • 코드 작성
   • add 로 staging area에 올림
2. Staging Area
   • 이 파일도 Git 관리에 포함할거야!
   • commit + commit message 로 commit 함
3. Commits
   • hash 값으로 저장

 

 

4️⃣ GitHub

• 2008년에 설립된 대표적인 무료 Git 저장소
• 2016년, MS가 75억 달러에 인수

 

 

5️⃣ Git의 주요 개념

 

구조

• Repository
  • 저장소
  • Git으로 버전 관리하는 디렉토리(폴더)
• Local Repository
  • 로컬 저장소
  • 작업자의 개발환경(Mac, PC)에 설정된 Git 저장소
• Remote Repository
  • 원격 저장소
  • GitHub등 외부 서버에 설정된 Git 저장소

 

명령어

• Commit
  • spnashot
  • 특정 상태를 기록한것, 버전
• Branch
  • 가지치기, 갈래
  • 또 다른 작업공간
• Merge
  • 병합, 합치기
  • 특정 브랜치에서 작업한 내용을 또 다른 브랜치에 적용하는 것을 의미함

 

Branching, Mergin

• Git을 사용하지 않고 단순 파일의 복사본들로 관리하면 비효율적이다.
• Git은 브랜치를 제공하여 동시에 여러 작업을 진행하고 합치는 충돌을 해결할 수 있다.

 

Repository

사용자가 변경한 모든 내용을 추적하는 공간

• 코드의 현재상태
• 변경이 언제 발생했는지
• 누가 변경했는지
• 변경 사항을 설명하는 텍스트 로그 메세지

 

Commit

의미있는 변화에 대한 기록

근데 그 ‘의미’라는 것이 굉장히 주관적이다.

 

 

Working Tree

작업트리

• 저장소를 바라보는 자신의 현재 시점
• 소스코드, 빌드 파일, 단위 테스트 등 프로젝트 모든 파일을 가진다.

 

Push

로컬의 저장한 것을 원격에 올림

 

Pull

원격 저장소의 변경 이력을 내 로컬에 다운로드

 

Tag

milestone을 달성했을 때 꼬리표 달아줌

 

Branch

파일이 분기하는 곳

작업 공간 분리

• 원격 저장소에 제공되는 기본 이름 origin

 

 

6️⃣ Git 구성하기

개발자 정보 입력

• Git은 분산 환경의 특성으로 사용자 이름과 이메일 주소는 제공하는 중앙 저장소가 없어 git config로 직접 설정
  • name, email
• 시스템에서 생성하는 모든 저장소의 기본값이 될 전역값 설정은 --global 옵션 사용

 

7️⃣ Git 도구들

• Xcode에서 바로 쓸 수 있따.
• 소스트리
• 깃허브 데스크탑

 

8️⃣ 많이 사용하는 Git 전략

1. 의미 있는 Branch는 만들자.
   이것이 데브옵스다 - 실전편
2. GitHub의 Pull Request는 오픈소스에 유용하다.

 

 

 

 

왕~~~~ 와왕~~~~ 3주차도 끄으읏