220530_TIL (Data Engineering Section 시작!)

Section3 - Data Engineering Part START!

Key words

개발 환경, 터미널과 CLI, 파이썬/콘다 가상환경(Virtual Environment), Git-Github, add-commit-push-pr(⭐)

(데이터 엔지니어링의 Introduction 같은 시간이었다.)

1. 터미널과 CLI

• CLI(Command Line Interface) - 글자 기반으로 사람의 명령과 결과가 진행되는 것을 말한다. GUI(Graphic User Interface)가 나오기 전에 컴퓨터를 사용하는 유일한(?) 방식이었고, 지금까지도 개발 시의 효율성, 작업 속도 등의 이유로 개발자들에게 애용된다고 한다. 개인적으론 GUI를 대중화시켜준 잡스의 1984매킨토시를 상당히 추앙하는 편이라, CLI가 정말 어느 정도의 편리함을 줄까 기대하고 있다. 앞으로 익숙해지면 나도 알 수 있겠지?
• 터미널은 글자 기반으로 명령을 전달할 수 있는 '어플리케이션'이다. CLI = 방식, 터미널 = 도구로 이해하면 될 것 같다.
• 기본 명령어 (⭐⭐) - 앞으로 자주 사용하며 익숙해져야할 친구이다.

- $ pwd : 현재 경로를 나타내는 명령어
- $ mkdir {폴더명}: 폴더(디렉토리)를 생성
- $ cd {폴더명} : 폴더에 들어가는 명령어
- $ ls : 현재 디렉토리 안의 파일 및 폴더 목록을 출력 (list!)
	- $ ls -l : 상세정보 출력
	- $ ls -a : 숨긴 파일까지 표시 (.git 같은 건 숨겨짐)
	- $ ls -al : 숨긴 파일까지 상세정보 포함해서 출력
- $ cat {파일명} : 파일을 터미널에 출력 (아직 안 써봄)
- $ echo 'Hello world' 

• 근데 이런 명령어는, 노트에서도 말하지만, 지금 무작정 외우려고 할 필요는 없다. 어차피 까먹으니까! 너무 기본적인 건 기억해야겠지만, 우리에겐 갓구글이 있으니 필요한 건 그때그때 찾도록 하자.
  
  

2. 파이썬 가상환경

• 개발하는 환경을 독립시킨 것을 가상환경이라고 생각해도 무리가 없을 것 같다. 별도의 가상환경에 내가 사용한 언어의 버전, 패키지 등을 세팅하여, 누가 실행해도 똑같은 결과가 나올 수 있도록 하는 것이다.
• 조금만 생각해보면 왜 이렇게 하는지 이유는 알 수 있을 것이다. (적절한 비유일지는 모르겠지만) 한국 토양과 기후, 농약/비료 등에 최적화된 A작물을 갑자기 어느 열대지방에 가져가 똑같이 키우려고 하면 키워지겠냐고!
• 따라서 하나의 환경에는 한 패키지당 하나의 버전만 설치될 수 있다. 예를 들어, 한 환경 내에서 pandas v1.1.2미만의 버전과 pandas v1.2.1이상의 버전을 동시에 만족할 수는 없다는 거다.
  • (이렇게 한 개의 환경에 어느 패키지가 이런 동시에 만족할 수 없는 두 개의 버전을 가정하고 만들어졌다면 충돌(Conflict)이 일어날 수 있다. 이걸 패키지 충돌이라고 한다)
• 파이썬의 가상환경은 각각의 어플리케이션을 독립된 공간으로 만들어 이러한 패키지 충돌 문제도 방지할 수 있다고 한다. 앞으로 자주 사용하게 될 것이라고 하니 금방 익숙해질 것 같다.

3. Conda 가상환경

• Anaconda는 주피터 노트북, 가상환경 등등 다양한 기능과 툴들이 내장되어 있는데(데이터 과학자들에게 유용하다고 함), 오늘은 이 중 파이썬의 패키지 및 가상환경을 관리해주는 conda라는 도구를 메인으로 사용해보았다.
• 가상환경이 무엇인지는 앞에서 얘기했으니 사용한 코드 위주로 메모 간드아~!
  • $ conda env list : 가상환경 리스트를 출력해준다.
    • $ conda env list > result.txt: 참고로 이런 식으로 하면 result.txt로 출력된 리스트 저장도 가능하더라고!?
  • $ conda create -n 'NAME' python = 3.8: 이렇게 가상환경을 생성해줄 수 있다. python 버전 지정한 건, 앞으로 세션이 저 버전에 최적화되어 있다고 해서임.
  • $ conda activate 'Name': 만든 가상황경을 지정해 실행할 수 있다.
  • $ conda deactivate: 가상환경 종료. 참고로 가상환경은 동시에 여러 개가 실행될 수도 있는데, 새로운 가상환경을 시작하기 전 깔끔하게 실행되고 있던 기존 가상환경을 종료하걸 추천했다.
  • $conda env remove -n 'NAME': 가상환경 제거하기.
• 앞서 말했지만, 여기서 전부 다 기억하려고 무리할 필요는 없다! 어차피 다 구글링하게 되어있어.. ㅎ
• 참고로 파이썬 가상환경 관리 도구는 conda 외에도 pipenv, virtualenv 등 다양하게 있다고 한다. 각자 장단점이 있는 것 같은데, 이런 글에서는 conda를 이제는 쓰지 말라고 하기도 한다. 난 일단 conda부터 잘 써보며 불편함 같은 것좀 느끼고 익숙해지면 넘어가는 거 생각해봐야겠다.

4. Git, Github (⭐⭐)

• 오늘 가장 잘 기억해야할 친구다.
• git은 버전관리 시스템(Version-Control System)이다. git이 github 만든 사람이 만든 건 줄 아는 사람도 본 적 있는데 그렇지 않다. github와 동일한 기능을 제공하는 플랫폼은 더 있다. git이 물이면 github는 물병이라고 말할 수 있을 것 같다.
  • 버전관리가 왜 필요하냐? 이것도 사실 조금만 생각하면 잘 알 수 있어서 굳이 더 남겨두진 않겠다.
  • 이 버전 관리에도 각 사람들의 욕구에 따라 Local VCS에서 Centralized VCS, Distributed VCS 등 다양한 형태로 발전되어 온 것 같다.
  • 여기에서 본 것에 더해 뇌피셜을 살짝 더해보면, 로컬에서만 버전관리(LVCS)하니 협업할 때 너무 불편해!! => 중앙에 모아두는 곳을 만들자! (CVCS)로 이어진 것 같고, CVCS를 하다보니 중앙 서버가 다운되거나 날라가면서 일어나는 대참사 때문에, 중앙에 몰아두는게 아니라 각자 로컬에 clone을 해서 작업 파일을 불러올 수 있고, 작업한 건 다시 push하는 방식을 개발하는 것으로 이어진 것 같다.
  • 그나저나 DVCS가 태어날 수 있도록, CSVS 아래서 중앙 서버가 날라가 모든 자료가 사라지는 대참사를 여러 차례 겪어주신 선배 인류 여러분 고생 많으셨습니다.. 진보는 이렇게 누군가의 희생을 먹고 이루어진다ㅋㅋㅋ..ㅠ
• 이 그림 하나면 오늘 기억해야할 건 싹 정리가 되는 것 같다. 기억하자.
• 출처
  • 여기서 remote repository는 github으로 생각하면 된다.
  • 맨 위 Keyword부분에 별표쳐둔 add-commit-push-pr는 내가 로컬에서 작업한 걸 github에 push하고, 공동 저장소에 pull request하는 것 까지 내가 밟아야할 과정이었다!
  • 참고로 원격 레포에서 로컬로 가져오는 걸 clone한다고 하고, $ git clone url과 같이 한다. clone은 Push랑 반대 개념이다.
  • 이 그림도 도움이 될 것 같다.

5. 실습한 것

실습한 내용을 간단히 옮겨둔다. 위에서 언급한 건 반복 안할 거임.

• $ git clone URL로 원격 레포(깃헙)에서 로컬로 불러온다.
• 항상 가상환경을 켜고 작업하는 습관을 들이자.
  • 아, 가상환경 만들어지면 pytest 제출에 필요한 플러그인 설치 꼭 해야 한다. 그 다음 $ pip install -r requirements.txt이걸로 필요한 패키지들도 설치하고!
  • (requirements.txt 여기에서 필요한 패키지 목록 넘겨주는 이유는 예상할 수 있겠지? 나는 이 가상환경에서 이러이런 버전을 가진 이러이런 패키지들로 작업을 했으니까, 너가 나랑 설치 버전 등이 다르면 문제 생길 수 있으니까 한번에 모아줄게~ 편하게 설치해~ 느낌인 거다. 만약 대충 메모지에 볼펜으로 적어서 줬다면, 내가 하나하나 다 install 해야하니 매우 귀찮았겠지)
• $ git add . 를 하면 변경한 '모든' 사항을 staging area에 넘긴다. 작업한 일부만 넘기는 건 나중에 필요하면 찾아봐라.
• $ git status는 add와 따라 다니는 명령어로 생각하면 될 것 같다. 어느 브랜치에서 내가 작업하고 있고, 파일들은 어떤 상태인지 등을 볼 때 사용한다.
  • add, status에 대해선 여기의 설명이 좋은 것 같다.
• $ git commit -m 'MESSAGE' commit하는 거다. 메세지는 다른 협업자가 보았을 때 '아 얘 이 git(버전)에서는 주로 이 작업을 했구나~' 알 수 있도록 잘 적어주는게 중요하다고 한다. 어느 글에서는 '똑똑한 사람은 작업한 시간을 적어둘 겁니다' 라고 하는 사람도 있었다. 버전 관리니까 관리하거나 롤백할 때 편하라고 그런 거겠지? 뭐 구체적인 건 조직마다 규칙이 분명 있을 것 같으니 그때가서 따르자.
• $ git push origin main main branch로 push하는 거다. 이렇게 push까지 해야 깃헙에서 보았을 때 내가 작업한게 반영이 된다.
  • (push, commit은 이 글 설명 좋은듯)
• $ git remote -v: 현재 깃과 연결되어 있는 원격 레포와 관련된 명령어라는데, 지금 내가 깃헙 어디랑 연결되어 있는지 볼 때 쓰는 거라고 알 고 있다.
• $ git branch -a: 모든 branch 목록을 볼 수 있다. (로컬, 원격 포함) 로컬 브랜치만 본다거나 등등 다양한 옵션이 있는데 그건 필요할 때 구글링 하셈.
• branch 생성하기: 아~ 이거 너무 헷갈렸다. 이 글 참고하셈.
• 근데 오늘 branch merge해보려고 했는데 잘 안됐다. un뭐시기 histories라서 제한되었다는 메시지가 나왔는데, 서로 연관 없어 보이는 브랜치끼리는 디폴트로 막아주는 기능 같다. 이거 강제로 푸는 방법도 찾아보니까 있던데 거기까지 하진 않았다. 일단 일반적인 상황에서의 merge의 느낌은 알겠다. (이 글 참고)
• 여하간 도전과제까지 잘 풀어서 3점 만점 획득! 굿!

그 외

• 이번 섹션3에서는 과제를 pytest라는 걸로 제출하고 있다. python -m pytest --submit을 하면 아마 부트캠프 서버로 제출되는 것 같다. python -m pytest --score를 하면 내 과제 점수도 바로 확인이 가능하다. (참고로 가상환경 안 켜고는 이 코드들 실행 안되었음!)
• pytest는 TDD(test driven developemente)를 위해 쓰이는 도구 중 하나인데, 작성한 코드에 오류가 있는지 개발사항 올리기 전에 테스트해보는? 개념으로 사용하는 것 같다.
  • 실무에서 코드리뷰랑 pytest가 어떻게 다른 의미로 쓰이는지 물어봤었는데, 속시원한 대답을 얻지는 못 했다. 코드리뷰 하는 것도 꼭 서로 더 나은 코드에 대해서 얘기하려고만 하지 않고 다양한 목적 아래 하는 것처럼, pytest도 같은 맥락에서 생각하면 될 것 같다. 이것도 역시 조직마다 문화와 규칙이 있을테니 그때 그때 적응하면 될듯하다.

Feeling

• Section3가 시작되었다. 벌써 S3라니.. Time flies..
  S3는 데이터 엔지니어링 파트다. 개인적으론 DE capa가 있으면 좋겠다고 생각해온터라, 흥미롭게 하루를 시작했다.
• 그러나.. 완전히 새로운 개념들이 쏟아지며 스트레스 지수가 상당히 올라갔었다. 부트캠프 시스템도 섹션마다 아직 얼라인이 안되어 있다고 느껴지는 부분이 많아서 이것도 적응하느라 눈동자가 상당히 흔들렸었다. (섹션마다의 특성을 반영한 최선의 선택에서의 차이라면 좋지만, 그렇지 않은 부분에서도 느껴질 때가 종종 있다. 이건 뭐 이해는 한다.. 얼라인하는게 어렵긴 하지.)
• 아무튼 배운거 다시 정리 한 지금은 매우 상쾌해! 좋아! 오늘 하루도 고생 많았다!