[네이버 부스트캠프 9기 챌린지] Day 13 학습 정리

이 글은 2024년에 진행하는 네이버 부스트캠프 웹모바일 9기 챌린지 프로그램의 일자별 학습 내용을 정리한 글이다.

부스트캠프에서 제공하는 모든 콘텐츠는 외부 유출이 금지되며, 이 글에서는 직접적인 내용을 포함하지 않는다.

---

진행 과정

• Git 학습
• SHA 학습
• 요구사항 분석
• 요구사항 설계
• 요구사항 구현
• 단위 테스트

---

학습 내용

버전 관리 시스템

• 소스 코드 등의 디지털 문서를 버전에 따라 관리하는 시스템
• 버전을 통해 해당 파일의 시간에 따른 변경 사항과 해당 변경 사항을 수행한 작업자를 추적함
• 버전 관리는 다음 이점을 제공함
  • 변경 사항과 해당 작업자를 쉽게 추적할 수 있음
  • 문제가 발생했을 때 복구를 원할히 함
  • 브랜치를 통해 동시에 여러 버전을 개발할 수 있음
  • 새로 개발한 부분을 머지를 통해 안전하게 결합할 수 있음
  • 협업하는 동료에게 변경 사항을 쉽게 공유할 수 있음
• 버전 관리 시스템은 다음과 같이 분류됨
  • 로컬 버전 관리 시스템
    • 별도의 서버 없이 로컬 컴퓨터 내에서 버전을 관리함
    • 간단하지만 실수하기 쉬움
    • 협업에 적합하지 않음
  • 중앙집중형 버전 관리 시스템
    • 프로젝트를 관리하는 서버를 두고 클라이언트는 서버에서 파일을 받아서 사용함
    • 서버에 문제가 발생하면 전체 사용자가 작업을 수행할 수 없는 문제가 있음
  • 분산 버전 관리 시스템
    • 서버에서 전체 프로젝트를 로컬 컴퓨터에 복제한 후 수정해서 다시 서버에 등록하는 식으로 사용함
    • 서버에 문제가 발생하더라도 로컬에 복제한 프로젝트로 작업 가능

git

• 오픈 소스로 개발된 분산 버전 관리 시스템
• git은 다음 특징을 가짐
  • 빠른 속도
  • 단순한 구조
  • 비선형적 개발
  • 완벽한 분산
  • 대형 프로젝트에서 유용함

git 동작 원리

• 아래 그림에서 git 환경에서 git 명령어가 동작하는 방식을 도식화함

• 구성 요소
  • 작업 폴더 (Working Directory)
    • 현재 작업 중인 파일이 있는 공간
    • 사용자가 실제로 작업하는 공간
  • 스테이징 영역 (Staging Area)
    • 저장소에 commit하기 전 임시로 저장하는 공간
  • 로컬 저장소 (Local Repository)
    • 로컬 git의 메타 데이터와 데이터 정보를 저장하는 영역
    • 작업 폴더의 .git 폴더
  • 원격 저장소 (Remote Repository)
    • Github 등의 온라인 저장소
• 명령어
  • add
    • 스테이징 영역에 현재 변경 사항 저장
  • commit
    • 로컬 저장소에 스테이징된 변경 사항 저장
  • push
    • 원격 저장소에 커밋된 변경 사항 저장
  • fetch
    • 원격 저장소의 변경 사항을 로컬 저장소로 받아옴
    • 작업 폴더에 반영하지 않음
  • merge
    • 로컬 저장소의 변경 사항을 작업 폴더에 반영
  • pull
    • 원격 저장소의 변경 사항을 로컬 저장소로 가져오는 동시에 작업 폴더에 반영

Github

• git을 기반으로 한 웹 호스팅 서비스
• git을 통한 버전 관리 및 소셜 네트워크 등의 추가 기능 제공
• 풀 리퀘스트(Pull request)를 통한 코드 검토 및 댓글 작성 지원

• 구성 요소
  • master branch
    • 기준이 되는 브랜치
  • feature branch
    • 각 작업자가 별도로 생성한 브랜치
• 명령어
  • branch
    • 새로운 브랜치 생성
  • checkout
    • 선택한 브랜치로 이동
  • merge
    • 다른 브랜치를 현재 브랜치에 병합

Hash

• 입력 데이터를 고정된 길이의 데이터로 변환한 값

해시 함수

• 데이터를 해시로 변환하는 함수
• 해시 함수의 성질
  • 역상 저항성 : 주어진 결과값에 대해 입력값을 계산하기 어려워야 한다
  • 제2역상 저항성 : 주어진 입력값에 대해 충돌쌍을 갖는 다른 입력값을 계산하기 어려워야 한다
  • 충돌 저항성 : 충돌쌍을 갖는 두 개의 입력값을 계산하기 어려워야 한다.
• 해시 충돌
  • 해시 함수가 서로 다른 두 개의 입력값에 대해 동일한 출력값을 내는 상황
  • 해시 함수를 사용한 자료구조나 알고리즘의 효율성을 떨어트림

SHA

• 미국의 국립표준기술연구소(NIST)에서 표준으로 채택한 해시 함수
• 문자가 하나라도 바뀌면 해시값이 완전히 변함
• SHA-0에서 시작해 SHA-1로 발전하고, 이후 SHA-2로 통칭되는 4가지 변형 SHA-224, SHA-256, SHA-384, SHA-512로 발전하고, 이후 SHA-3을 공모함
• SHA-0과 SHA-1에 대한 공격 방법은 이미 발견되었으나 SHA-2는 아직 발견되지 않음

---

느낀점

 이번 미션은 페어 프로그래밍으로 진행됐다. 지난 주차에서는 페어 프로그래밍의 방법을 모른 채 짝이랑 서로 논의해서 적절한 진행 방식을 찾아가는 식이었다면 이번 페어 프로그래밍은 페어 프로그래밍의 기본적인 진행 과정을 이해하고 그 과정을 실제로 적용해보는 시간이었다. 나는 이 부분 만들고 너는 이 부분 만들어 하는 분업의 방식이 아닌 한 명이 코드를 작성하면 다른 한 명이 설계에 맞게 보조하는, 페어 프로그래밍에서 흔이 일컫는 네비게이터와 드라이버의 역할을 서로가 교대해가며 수행했다. 서로 페어 프로그래밍 과정을 이해하고 네비게이터와 드라이버의 역할을 서로 교대하면서 수행하기는 했는데 완벽히 진행했는지는 잘 모르겠다. 부스트캠프에서 페어 프로그래밍 과정을 가이드하면서 10~20분의 짧은 간격으로 교대하라고 했었는데, 우리는 역할을 교대할 때 별도로 시간 제한을 두지 않았고, 거의 구현할 함수 단위로 교대했던 것 같다. 시간으로 따지면 한 30~40분 정도마다 교대했던 것 같은데 함수 단위로 진행하는 것도 충분히 효과적으로 수월하게 진행됐던 것을 생각해보면 짧게 교대하는 것이 효율적일지 구현 내용에 따라 교대하는게 효율적인지는 아직 잘 모르겠다. 그런데 짧게짧게 진행하기도 좀 뭐했던게 JavaScript 경험이 아직 부족해서 사용해야 할 메소드들을 전부 외우고 있지 않았기도 했고 내가 코드를 좀 느릿느릿하게 작성하는 스타일이다보니 짧게 교대하면 뭔가를 작성하기도 전에 교대될 것 같았다. 간단하게 생각하면 내 실력을 더 높이면 되는 문제긴 하지만 그래도 페어 프로그래밍을 몇 번 더 진행해봐야 유의미한 결론이 나올 것 같다.