* 프로그래머스, 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 5기 강의 수강 내용을 정리하는 포스팅.

* 더 수월할 내용 이해를 위해 수업 이외의 자료 등을 덧붙이고 있음.

1. 프로젝트

• 일정한 기간 내에 특정 목적을 달성하기 위해 수행하는 업무의 묶음.

• 웹 개발에서는 하나의 프로그램(시스템)을 제작하기 위한 일련의 과정을 뜻한다.

• 프로젝트에는 이를 위한 기획, 설계, 테스트, 배포 등의 과정을 포함한다.

• 하나의 프로젝트 과정이 완료되었다고 해도, 후속 개발이나 대규모 보수 등의 사유로 프로젝트의 규모가 커지거나 다른 프로젝트로 연장될 수 있다.

• 네이버 홈페이지를 기준으로 설명하자면, 네이버라는 거대한 프로젝트 아래에는 이메일 / 블로그 / 뉴스 등의 하위 프로젝트들이 다수 존재할 수 있다.

• 똑같은 '프로젝트'를 진행한다고 해도 규모, 참여 인력, 예산 등은 천차만별. 나홀로 진행하는 경우도 왕왕 존재한다.

2. 협업 프로젝트를 위한 협업 환경

• 100%는 아니지만 회사라고 한다면, 당연히 많은 경우에는 다수의 개발자들이 모여서 '같은 프로젝트'를 진행하곤 한다.

• 이를 위해서는 다수의 사람들이 협업을 진행할 수 있는 '환경'이 갖추어져야 한다.

• 협업 환경이라는 것은 곧 '공유'. 각각이 작성한 코드와 프로젝트에 필요한 문서들을 원활하게 공유할 수 있어야 한다.

Readme

• Git을 이용하게 되면, Repo를 생성할 때 Readme를 생성할 것인지 따로 물어본다.

• 그렇다면 Readme라는 것은 무엇인가?

• 개발 직군에서는 주로 완성된 프로그램의 설명서, 구현 중인 프로젝트의 현황을 기재하는 용도로 사용된다.

• 해당 프로그램의 사용 방법, 레퍼런스, 구현 중인 프로젝트의 주요 기능 / 현황 / 발생한 문제점 등을 포함한다.

Readme 작성 방법

• Git Repo 상에서 직접 수정하는 방법. 우측 필기구 모양의 버튼을 클릭하면, Readme 수정 모드로 전환된다.

• GitHub 저장소를 로컬에 클론해서 사용하는 경우, VSCode 등의 프로그램에서 해당 프로젝트의 Readme 파일을 수정하는 방법.

• 어느 방법을 사용해도 좋지만 Readme 문서는 Markdown 문법을 기반으로 동작한다는 사실을 기억하면서 작성/수정해주어야 한다.

Markdown

• Readme.md. Readme 파일의 확장자는 .md라는 생소한 문자로 되어있다. md는 바로 markdown의 약자.

• 일반적인 텍스트 파일에서는 그저 문자열과 숫자의 나열만 처리된다. 문단을 구분하거나 문장을 강조하는 등의 가독성을 개선하는 방법이 대단히 제한될 수 밖에 없다.

• 마크다운(Markdown)은 문서 작성에 유용한 간단한 언어로써 일반 텍스트 파일의 문제점들을 보완해준다.

• 주로 GitHub README과 해당 문법을 채용한 홈페이지 글쓰기 등지에서 사용한다. 위키피디아, 티스토리, 슬랙, 노션 등등.. 이 포스팅이 올라가는 Velog에서도 채용 중.

• 다만 각각의 홈페이지나 서비스에서 사용하는 Markdown은 완전히 동일하진 않다. 각자 필요에 따라서 변형을 주는 경우가 있기 때문.
  (Github의 경우 Github-Flavored-Markdown이라는 변형 Markdown을 사용한다.)
  (기본 Markdown에 코드 블록, 체크박스, 표(table) 같은 추가적인 기능이 포함된 형식.)

• 화면 상에서 이렇게 출력되는 Readme 파일은..

• 실제로는 이런 Markdown 문법으로 작성되는 것이다.

3. 버전 관리 시스템

버전 관리는 왜 필요할까?

1. 변경 이력 관리 및 복구 용이

• 프로젝트의 각 작업 단계에서 발생한 변경 사항을 시간 순서대로 기록.

• 이렇게 기록된 이력은 특정 문제가 발생했을 때 되돌리거나 이전 시점으로 복구하는 데 대단히 큰 도움이 된다. 특히 소프트웨어 개발 과정에서 오류가 발생하거나, 잘못된 수정이 필요할 때 이러한 기록은 매우 유용하다.

2. 안정적인 협업과 통합 작업 지원

• 여러 개발자가 동시에 작업할 때, 작업 내용이 서로 충돌하거나 겹치는 경우가 자주 발생할 수 있다.

• 버전 관리 시스템은 이러한 충돌을 최소화하고, 각자의 작업을 손쉽게 병합할 수 있는 환경을 제공.

3. 작업 기록을 통한 분석 및 개선

• 각 커밋에는 수정된 내용과 그 이유가 기록되므로, 언제 어떤 변화가 일어났는지 추적할 수 있다.

• 개발 과정에서 언제 어디서 무엇이 변경되었다는 세세한 정보들이 자동으로 저장된다. 이를 이용해서 문제의 원인 분석이나 코드 개선에 필요한 데이터를 확보할 수 있다.

4. 백업 및 안정성 확보

• 프로젝트를 진행하다가 무언가의 이유로 파일을 잘못 삭제하거나, 파일이 손상되었다면?

• 백업 데이터가 없으면 그 프로젝트는 그대로 망하는 것이다. 프로젝트의 규모가 크면 클 수록 백업 데이터의 중요성이 대단히 증대되는 것.

• 그런데 여기에 필요한 저장공간을 확보하는 것도, 주기적으로 백업 데이터를 갱신해주는 것은 여간 귀찮은 일이 아니다. 버전 관리 시스템은 자동으로 로컬 컴퓨터에서 작업 중인 파일을 원격 저장소에 업로드하여 백업해준다. 백업에 필요한 저장공간과 노력을 대신해준다는 것.

5. 버전 관리로 코드의 일관성 유지

• 프로젝트가 발전하면서 여러 버전이 생기더라도, 버전 관리 시스템은 각 버전이 일관되게 유지되도록 관리.

• 이것이 무슨 뜻이냐. main 또는 master 브랜치를 유지하면서 독립적인 브랜치를 분리하여 새로운 기능 개발, 버그 수정, 테스트 등등을 진행할 수 있다. 여러 버전들을 편하게 관리할 수 있다는 뜻.

• 이렇게 나눠진 브랜치들은 필요한 시점에 병합(merge)을 통해 메인 코드에 변경 사항을 반영할 수 있다.

버전 관리 시스템의 종류

• 로컬, 중앙집중식, 분산.

• 로컬은 협업 용도라기보다는 개인 단위에서 버전을 관리하는 용도로 사용한다. (RCS 등)

• 장점: 간단한 사용과 설정이 가능하며, 단독 작업 시 적합.

• 단점: 협업에 불편하고, 다른 컴퓨터나 원격 저장소에 의존할 수 없기 때문에 백업이 취약.

• 중앙집중식은 모든 데이터가 중앙 서버에 집중되고, 사용자는 로컬로 파일을 가져와서 수정하면 서버가 업데이트 되는 식. (CVS, SVN, Perforce 등)

• 장점: 여러 사용자가 공동으로 작업할 수 있고, 중앙 서버를 통해 변경 이력과 데이터를 관리할 수 있다.

• 단점: 중앙 서버가 다운되면 모든 작업이 중단되며, 분산형에 비해 복구 및 백업 기능이 취약할 수 있다.

• 분산. 모든 사용자들이 전체 데이터를 각각의 로컬에 복제하여 가지고 있고, 각자 관리하는 방식. (Git, Mercurial, Bazaar 등)

• 장점: 로컬에 전체 저장소가 복제되어 있어 서버 문제가 발생해도 작업에 지장이 없다. 또한 브랜치를 활용한 독립적 작업이 용이하고, 협업에 최적화되어 있다. Git을 가장 많이 사용하는 이유.

• 단점: 저장소가 크면 전체를 복제하는 데 많은 저장 공간과 시간이 필요할 수 있다.