전문지식 함양/TIL

[프로그래머스 겨울방학 인공지능 과정] 기초1. github와 jupyter note의 설치

샤프펜슬s 2022. 1. 4. 16:20

0. 주의사항 : 아래의 내용을 무조건적으로 신뢰하지 않기를 바란다. 프로그래밍의 세계는 매우 심오하고 복잡해서 지금 정리하는 내용이 완벽하다고 나조차도 신뢰하지 않기 때문이다.

 

1. 일자 : 2022년 1월 3일 14:00 ~ 18:00 (1일차)

 

2. 주제 : github 이용방법과 jupyter note의 사용법

 

3. 내용

(1) git의 구조

 git의 구조를 이해하기 위해서는 컴퓨터 내부에서 진행되는 "Local"환경과 외부(웹상)에서 진행되는 "Remote"환경이라는 두 개의 구조를 이해할 수 있어야 한다. 구조는 아래와 같다.

 

<Local>

(1) Working Directory - Unstaged

(2) Staging area - Staged

(3) Repository - Commited

 

<Remote>

(1) Repository

 

 

(2) <Local> 이해하기

 우리가 외부저장소로 자료를 보내기 위해서는 Local에서 (1) Working Directory - (2) Staging area - (3) Repository 순으로 거쳐야 한다. 이때 자료의 상태는 각각 Unstaged - Staged - Commited되었다고 말한다.

 

(2.1) Unstaged상태에서 Staged상태로

쉽게 생각해보자. 먼저, 우리가 처리한 작업물A은 Working Directory에 남는다. Working Directory에 존재하는 작업물은 "Unstaged"상태이다. Unstaged된 작업물을 확인하고 싶다면 git bash에 아래의 명령어를 입력해보면 바로 알 수 있다.

// 0. git에서 unstaged, staged, commited의 상태를 확인한다.
git status

 만약 Unstaged된 작업물이 존재할 경우, 해당 작업물은 빨간색 글자로 표시가 된다.  우리가 외부저장소로 작업물A를 보내기 위해서는 해당 작업물의 상태를 Unstaged에서 Staged로 바꾸어주어야 한다.  즉, (2) Staging area로 자료를 보내주어야 한다.

// 1. file_name을 unstaged 상태에서 staged 상태로 변경한다.
git add (file_name)
// 여기서 ()기호는 입력하지 않는다.

 만약 python으로 작성된 작업물A를 staged상태로 변경하고 싶다면, "git add 작업물A.py"라고 입력하면 된다. 이를 통해서 무사히 Staging area에 작업물A를 보낼 수 있다. 

 

(2.2) Staged상태에서 Commit상태로

 마지막으로 우리는 <Local> 내부의 Repository로 작업물A를 보내고 싶다. 이를 위해서는 작업물A를 commited상태로 만들어주어야 한다. 다만, unstaged된 작업물을 곧바로 commited 상태로 변경할 수는 없고, 반드시 staged상태로 만들어준 다음 commited상태로 바꾸어야 한다.

// 2. Staged상태인 작업물을 Commited상태로 바꾼다. (Local의 Repository로 보낸다)
git commit -m "(message)"
// 여기서 (message)는 자신이 입력하고 싶은 내용을 적는 공간으로
// 나중에 <Remote>의 Repository로 자료를 보낼 때 해당 메시지가 입력된다.

 이 과정까지 진행한다면 우리는 성공적으로 작업물A를 Local의 Repositroy로 보내는 것에 성공했을 것이다.  <Remote>의 Repository로 보내는 방법은 branch에 대한 이해가 선행되어야 하므로 해당 내용과 같이 다룬다.

 

 

(3) Branch

 branch는 '나뭇가지'라는 의미를 갖고 있는데, 글자 그래도 '나뭇가지처럼 코드의 분기를 나누는 것'을 말한다. 우리가 흔히 과제물을 작성할 때 "최종본1", "최종본1-1", "최종본1-2"처럼 어느 분기점에서 파일을 '덮어쓰기'하지 않고 별도로 저장한 적이 있을 것이다. branch는 이처럼 commit을 할 때 코드를 덮어쓰지 않고도 수정 및 저장을 할 수 있다는 장점이 있다. 이를 통해 우리는 프로그래밍 파일의 버전관리가 용이해진다는 사실을 이해할 수 있을 것이다. 

기본적으로 "master"라는 이름의 branch가 존재하며, 사용자는 여기에 추가로 branch를 만들어 분기점을 나누는 것이다.

 

(3.1) branch의 생성과 전환

 먼저 branch를 생성하는 방법을 알기 전에, branch의 상태를 확인하는 코드를 알아본다.

git branch -v

해당 코드를 git bash에 입력한다면 우리는 어떤 branch가 생성되어 있는지 등을 확인할 수 있다.

 

 지금부터 우리는 branch를 생성한다. branch_name으로 우리는 branch를 생성하였다.

// branch_name으로 branch를 생성합니다.
git branch (branch_name)
// ()기호는 적지 않습니다.

그러나, branch만 만든다고 해서 프로그램이 자동으로 방금 생성한 branch영역으로 바꾸어주지는 않는다. 우리가 직접 해당 영역으로 들어가 작업을 수행해야 한다.

// "이미 생성된" branch_name으로 전환합니다.
git checkout (branch_name)
// 이때, ()기호는 적지 않는다.

 무사히 branch를 전환했다면 우리는 '(2)<Local>이해하기'에서 진행했던 것처럼 작업을 이어나가면 된다. 사용자가 아무리 파일을 최신화한다고 하더라도 "master" branch에 담긴 파일에는 아무런 영향을 끼치지 못한다. 하지만 언젠가는 사용자가 작성한 파일이 "master" branch에도 반영되어야 한다. 이 경우, 아래의 과정을 통해 해결한다.

 

(3.2) branch와 master의 코드 병합하기

 이 작업을 수행하는 여러 방법이 존재하지만, 여기서는 아주 쉬운 방법을 통해 해결한다. 왜냐하면 내가 그 방법으로 배웠기 때문이다.

 이 방법을 한 문장으로 요약한다면, "현재 작업 중인 branch에 다른 branch상황을 반영하는 것"이다. 이 문장을 찬찬히 뜯어보면서 작업을 진행해보자.

 

(3.2.1) "현재 작업 중인 branch에"

현재 작업 중인 branch, 즉 작업상황을 반영하고자 하는 branch로 전환하는 과정이 필요하다. 나는 "master" branch로 변경할 것이므로 checkout을 통해 master branch로 변경한다.

git checkout master

 

(3.2.2) "다른 branch상황을 반영하는 것"

그 다음, 다른 branch의 상황을 반영한다. 우리가 삭제, 수정, 추가한 상황을 모두 master branch에 반영하는 것이다. 이것을 가르쳐주었던 분께서는 이를 두고 "빨리감기를 하는 것 같다"라고 말한 바 있다. 해당 내용을 그대로 덮어쓰기하는 것이 아닌, 다른 branch에서 진행했던 과정을 모두 거치면서 master branch에 반영하기 때문에 이렇게 비유한 것이 아닐까 생각한다.

git merge (branch_name)
// ()기호는 작성하지 않는다.

 

 

(3.2.3) 필요없어진 branch의 삭제

 분기점에서 작성된 작업물을 master branch에 통합한 이상 생성한 branch는 의미가 없어졌다. 그러므로 우리는 branch를 삭제하여 깨끗하게 작업공간을 관리하고자 한다.

git branch -d (branch_name)
()기호는 작성하지 않는다.

 

(4) <Remote>의 repository로 전송

 이제 우리는 외부저장소로 지금까지 진행했던 작업물을 보내고자 한다. 이를 위해서 우리는 먼저 git에서 회원가입을 진행한 뒤, "Code"라고 적힌 초록색 버튼을 클릭하여 URL를 복사한다. 그리고 아래의 코드를 입력하여 외부저장소의 위치를 정확히 지정해준다.

git remote add (별칭) (github repository 주소)
// (별칭)은 어느 것을 입력하여도 무방함

이후 Local에서 Commit상태로 기다리고 있던 작업물을 외부 저장소로 보내는 작업을 수행하자.

git push (별칭) (branch_name)
// branch_name이 들어갈 곳에는 branch의 이름을 넣는다.
// (별칭)이 들어가는 부분은 우리가 앞서 외부저장소를 지정했을 때 사용한 별칭을 넣는다.

 

 만약 master branch의 내용을 push하려고 할 경우, git의 운영정책으로 인해 문제가 발생할 수 있다. 이는 master-slave와 같이 전근대사회나 사용되었을 법한 용어를 바꾸고자 하는 움직임 때문이므로 우리는 프로그래밍 사회의 움직임에 맞추어 기꺼이 바꾸어주도록 한다. 그래서 나는 master branch를 아래 코드를 통해 main으로 변경하였다.

git branch -M main

이후 "git push (별칭) main"을 통해 외부저장소로 파일을 전송하였다.

 

(5) jupyter notebook의 설치 및 관련 이슈

 인공지능 데이터분석에서 jupyter notebook을 사용하는 이유는 데이터 분석을 진행하면서 "왜 이 코드를 작성했는지"가 무척 중요하게 다루어지기 때문이다. 코드창 내에서도 이미 //나 #을 통해서 주석을 지원하고 있지만, 이 경우 가시성이 크게 떨어진다는 단점이 있다. 그러나 jupyter notebook은 코드 입력창을 분리할 수 있고, 각 코드칸 별로 설정에 따라 마크다운 문서 형태도 지원하기 때문에 작성이 훨씬 용이하다. 그래서 우리는 jupyter notebook을 통해 교육을 받았다. jupyter notebook을 설치하는 방법은 아주 간단하다. 명령 프롬프트(cmd)창에서 아래와 같이 입력해주기만 하면 된다.

pip install jupyter

 이렇게 하면 컴퓨터가 알아서 잘 설치해준다. 이후 jupyter notebook을 사용하고 싶다면 명령 프롬프트 창에서 아래와 같이 입력해주면 웹 환경에서 실행된다.

jupyter notebook

 

(5.1) jupyter notebook이 설치된 장소와 다른 곳에 jupyter notebook파일을 저장하고 싶을 경우

나는 pip install을 통해서 설치한 결과 컴퓨터가 자동으로 C드라이브에 설치해주었다. 하지만 내 작업공간 폴더는 D드라이브에 위치하고 있었다. Save as를 눌러 D드라이브를 저장공간으로 지정하자, "(사용자가 새로 지정하고자 하는 저장고간의 경로) ipynb is outside root contents directory"처럼 경고문구와 함께 거부되었다.

위와 같은 문제가 발생할 경우 아래의 링크를 참고하면 된다.

 

https://stackoverflow.com/questions/35254852/how-to-change-the-jupyter-start-up-folder

 

How to change the Jupyter start-up folder

I tried following the instructions given on the Jupyter Notebook documentation. Unfortunately, I haven't been able to figure it out. Where exactly is this "start in" field? I've a windows 7 (64 b...

stackoverflow.com

 

다만 위 페이지는 전부 영어이므로, 영어에 거부감을 가지고 있는 분들을 위해 간단하게 설명한다.

먼저 명령 프롬프트 창을 열어 아래 코드를 작성해준다. 이 명령어는 jupyter notebook의 config 파일을 생성해준다.

jupyter notebook --generate-config

그 다음 생성된 jupyter_note_config.py파일을 실행한다.

해당 config파일 안에 "c.NotebookApp.notebook_dir"을 검색하면 주석처리가 된 c.NotebookApp.notebook_dir = ''을 찾을 수 있다. 여기서 빈 작은따옴표 사이에 사용자가 지정하고 싶은 폴더경로를 복사하고, 해당 코드의 주석을 해제하면 된다.