본문 바로가기

개발/프로그래머스 데브코스

프로그래머스 데브코스 1일차 with. TS 웹 풀스택

프로그래머스에서 진행하는 `타입스크립트로 함께하는 웹 풀 사이크 개발 3기`를 참여하게 되었습니다. 오늘부터 앞으로 공부하는 내용에 대해 정리하면서 개인적인 생각과 의문을 적어보겠습니다. 가능하면 의문에 대한 답변까지 기록하겠습니다.

 

요약📚

오늘은 프로젝트가 무엇인지부터 시작합니다. 개인이 아닌 동료와 함께 진행하게 되는 과정인 만큼 협업을 어떻게 잘 할 수 있는가에 대한 한 가지 길 `공유`를 하는 방법에 대해 배웠습니다. 개발자가 공유할 수 있는 여러 부분이 있지만, 그중에 프로젝트의 현황을 공유할 수 있는 Readme와 코드를 버전에 따라 공유할 수 있는 버전 관리 시스템에 대해 배웠습니다.

 

 

📖프로젝트란?

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

△출처 위키백과-프로젝트

일정한 기간? 일정한 목적? 뭔가 애매한 말이지만 어쩔 수 없습니다. 왜냐구요? 프로젝트의 기준은 본인이 정하기 나름이기 때문입니다. 개발자의 업무를 예로 들면 새로운 웹 사이트를 만드는 것이 프로젝트가 될 수 있고, 기존에 있던 웹 사이트를 더 나은 방향으로 수정하기 위해서 고도화시키는 과정 또한 프로젝트가 될 수 있기 때문입니다. 이처럼 사소한 것부터 넓은 범위의 목적을 기간을 정해 수행하는 것을 프로젝트라고 할 수 있습니다.

 

프로젝트의 정의를 한 번 봤습니다. 그럼 누가 프로젝트를 하는 것일까요? 개발자 혼자 할까요? 맞습니다. 개발자랑 디자이너랑 같이 해야하는거 아닌가요? 맞습니다. 다 맞는 말입니다. 프로젝트는 최소 1명부터 수십 수백 명까지 참여할 수 있습니다. 다시 처음으로 돌아가 생각해 보겠습니다. 이 과정의 목표가 무엇인가요? 학습도 맞지만 취업입니다. 회사에 들어가서 다른 사람들과 일하는 것입니다. 특이한 경우에는 혼자 일하겠지만, 일반적인 경우만 생각해 보겠습니다. 혼자가 아닌 여럿이 일하려면 협업은 정말로 중요한 일입니다.

그렇다면 협업은 어떻게 해야 잘 할 수 있을까요? 공유!

상황이 바뀐 것에 대한 공유, 코드 작성에 대한 공유, 현황 공유 등 개발자의 협업에서 공유는 빼놓을 수 없습니다. 그중 오늘은 프로젝트 현황을 공유할 수 있는 Readme와 코드를 공유할 수 있는 버전 관리 시스템에 대해 알아보겠습니다.

 

📖Readme(with. markdown)

Readme는 뭘까? 뭔데 나를 읽어달라고 하는 것인가? 쉽게 생각해봅시다. 무엇인가를 사용하기 전에 보는 것이 무엇인가? 바로 설명서입니다.  Readme는 크게 두 가지 역할을 하고 있는데 첫 번째 역할이 바로 완성된 프로그램의 설명서입니다. 두번째 역할은 구현 중인 프로젝트의 현황을 나타내는 것입니다. 예를 들어 진행 정도, 수정 사항, 오류 사항 등 협업에서 여러 상황을 공유할 수 있는 역할입니다. Readme는 간단하게 텍스트 파일(.txt 확장자)에 정리되어 공유될 수 있습니다. 하지만 복잡하거나 내용이 많아질수록 일정한 간격과 글자 크기를 가진 텍스트 파일은 가독성이 떨어질 수 있습니다. 그래서 사용되는 것이 markdown 기술입니다. markdown 기술을 사용하면 텍스트로 작성했지만 여러 효과를 사용해 가독성을 높이고 시각적인 즐거움을 줄 수 있습니다.

 

📄markdown

`.md`확장자를 사용하며 텍스트를 정해진 문법에 따라 입력하면 일반적인 텍스트에 꾸며진 효과를 줄 수 있는 기술입니다. 제목과 본문의 구분, 리스트를 만들기, 인용문 만들기 등 여러 효과 적용할 수 있는 기술입니다. 사용되는 곳은 블로그, 깃허브의 Readme파일, 디스코드 채팅, 노션 등 다양한 곳에서 사용되고 있습니다. 사용되는 곳에 따라 문법이 조금씩 다르고 적용되는 효과가 달라집니다. 이제 간단한 문법을 배워보겠습니다.

티스토리 글쓰기의 마크다운 모드를 이용한 사진

이 외에도 여러 문법들이 있지만 자세한 내용은 다음 시간에 더 알아보는 것으로 합시다.

 

📖버전 관리 시스템(Version Control System)

개발자는 프로젝트의 현황을 공유하는 것도 중요하지만 결국 그것보다 기초에 있는 코드를 공유하는 것이 정말 중요합니다. 공유하기 이전에 공유할 문서의 이름을 '완성본'이라고 하겠습니다. 개발자는 '완성본'을 공유했습니다. 시간이 지나고 더 좋은 코드로 수정하고 '완성본1'이라는 문서로 저장했습니다. 그렇다면 개발자는 '완성본1'을 공유할 것입니다. 다음에 다른 수정이 생기게 되면 이름을 어떻게 지어야 할까요? 이를 지정하는 방식은 다양하지만 이름이 있습니다. 바로 `버전`입니다.

버전이라는 이름은 익숙하실 수 있습니다. 게임에서 1.02 패치나 휴대폰 업데이트 후 2.3.2라고 하는 숫자로 이뤄진 것들이 버전입니다. 물론 완성본1, 완성본2를 버전이라고 할 수도 있습니다. 왜냐하면 버전은 유의미한 수정을 의미하기 때문입니다.

잠깐 버전을 설명 드렸는데, 왜 그랬느냐? 코드에서는 유의미한 수정이 자주 발생하기 때문입니다. 그렇기에 코드는 수많은 버전이 만들어지는데 이를 어떻게 다 공유할까요? 바로 VCS를 이용하는 것입니다. VCS는 버전 관리 시스템(Version Control System)의 약자입니다. VCS는 의미 그대로 많은 버전을 관리해 주고, 백업 또한 도와줍니다. 마지막으로 협업에 필요한 기능 또한 제공해 줍니다.

VCS의 종류

  1. 로컬 VCS : 로컬이라는 말 그대로 개인의 노트북 또는 데스크탑에서 동작하는 것을 의미합니다. 개인의 환경에서 동작하기 때문에 협업 기능은 존재하지 않습니다.
  2. 중앙집중식 VCS : 로컬에 저장하던 파일들을 외부 한 곳(중앙)에 저장합니다. 외부에 저장되어 사용되기 때문에 다른 사람 또한 접근할 수 있는데, 이를 이용해 협업을 진행합니다. 예를 들어 SVN, CVS가 있습니다.
  3. 분산형 VCS : 중앙집중식을 통해 협업을 진행할 수 있는데 왜 또 다른 게 있을까요? 저장하고 불러오는 단위에 차이가 있습니다. 중앙집중식은 파일 단위로 저장하고 불러온다면 분산 CVS는 프로젝트 단위로 저장하고 불러옵니다. 이를 통해 좀 더 편리한 관리를 할 수 있습니다. 예를 들어 Git, Mecurial이 있습니다.
중앙집중식 VCS와 분산형 VCS의 단위 차이? 두 가지의 차이가 뭐지?🙄
중앙집중식의 경우 중앙에서 전부 처리하기 때문에 버전 관리도 중앙에서 합니다. 중앙에서 원하는 파일을 요청하고 수정하는 방식입니다. 한 곳에서 전부 관리하기 때문에 사용과 관리가 쉽다는 장점과 고장이 발생하면 고치기 어렵다는 단점이 있습니다.
분산형의 경우 하나의 파일이 아닌 모든 버전을 로컬로 가져와서 작업합니다. 이 경우 중앙에 문제가 생겨도 작업을 진행할 수 있고, 복구도 비교적 쉽다는 장점이 있습니다. 하지만 수정 사항을 반영하는 과정이나 여러 과정이 복잡해져 사용이 어려워진다는 단점이 있습니다.

 

다음 시간에 계속...

 

출처 & 참고

김송아 강사님의 강의

Git(분산형 버전관리시스템)이란?, murpin, 2024.04.08

Git 버전 관리 시스템 이해, Andrew's Akashic Records, 2024.04.08