IT 5분 잡학사전 - 에피소드 30~34

Today I Learned

2023.11.19

오늘 읽은 범위

에피소드 30. 코로나가 준 레거시 시스템의 교훈
에피소드 31. 데이터와 단짝 친구, SQL
에피소드 32. NoSQL이 뭐죠?
에피소드 33. 깃 & 깃허브, 똑같은 거냐고?
에피소드 34. 버전을 표기하는 방법도 있어요?

📌에피소드 30. 코로나가 준 레거시 시스템의 교훈

레거시(legacy): 유산
레거시 시스템: 오래 전에 개발된 시스템
ex) 미국 정부 사이트
ex) 미국의 은행 시스템 중 43%
ex) 미국 ATM 시스템 중 95% 는 '코볼'이라는 오래된 컴퓨터 언어로 개발 되었다.

개발자 관점: 프로그램은 책임 있게 만들어야 한다.

개발자가 만든 프로그램은 사람들에게 영향을 주기 때문에 개발자는 자신이 만든 프로그램에 완벽하게 책임을 져야한다. 너무 빠쁜 나머지 '프로그램이 돌아가기만 하면 그만이다'라는 생각으로 코드를 대충 짜는 개발자도 있는데, 그러면 안된다. ❌

관리자 관점: 시스템은 한번 구축하면 끝이 아니다.

개발자라면 코드를 살아 있는 생명체처럼 꾸준히 관리해야 한다. 물을 자주 주지 않아도 되는 선인장도 방치하면 죽는 것과 같다.

📌에피소드 31. 데이터와 단짝 친구, SQL

SQL

structured: 구조화된
query: 질문/문의
language: 언어

SQL은 데이터 베이스에 어떤 질문 또는 문의를 하기 위해 어떤 구조를 가진 언어이다. SQL은 한마디로 데이터베이스를 다루는 언어다.

데이터베이스

• 데이터를 저장하는 창고 역할만 할 뿐 데이터를 직접 정리하거나 처리하는 능력이 없다. 이런 일들은 DBMS가 한다.
• 데이터베이스는 엑셀에 데이터를 입력한 테이블 처럼 생겼다.
  

DBMS (database management system): 데이터베이스 관리 시스템

• 데이터베이스에 접근하려면 DBMS와 SQL로 소통해야 한다.
• SQL은 데이터베이스가 아니라 DBMS와 대화하는 말!

  SQL: "저, 데이터 베이스와 얘기 좀 하고 싶은데요."
  DBMS: "아, 그러면 DBMS인 저와 이야기 하시면 됩니다."

• DBMS의 종류

  • MySQL, PostgreSQL, SQLite, Oracle, MariaDB 등
  • 같은 SQL이지만 사투리 처럼 조금씩 다르다.
  • 이 모든 것들은 데이터베이스가 아닌 DBMS다!

ORM

• object relational mapping
• 개발자를 위한 SQL 번역기
• 파이썬의 장고 ORM, 라라벨의 엘러퀀트 ORM, 노드제이에스의 시퀄라이즈 ORM

ORM의 문제

개발자들이 ORM에 지나치게 의존해서 SQL 공부를 뒤로 미루려는 경향이 있다. 영어로 따지면 ORM라는 통역기가 있기 때문에 굳이 영어를 배우려고 하지 않는 것과 같다. 하지만 번역기가 만능은 아니듯 ORM에만 의지하면 해결하기 어려운 상황에 대처하기 어렵다.

SQL을 꼭 공부할 것!

📌에피소드 32. NoSQL이 뭐죠?

NoSQL

• 노에스큐엘이라고 읽는다.
• SQL은 사투리처럼 프로그램마다 조금씩 다르지만 NoSQL은 언어의 특징 뿐만 아니라 각 NoSQL 마다 데이터베이스 자체의 성질도 다르다.

NoSQL 종류

document DB, key-value DB(키값 데이터베이스), graph DB 등

1) document DB

• 데이터 형식이 매우 자유로운 document DB

• 대표적: Mongo DB

• 데이터를 JSON(제이슨) document 형태로 저장한다.
  - JSON: JavaScript object notation

  • JSON document: 제이슨 형식으로 저장된 파일
  • JSON 형식이라는 건 그냥 {키1: 값1, 키2: 값2,..} 형태로 구성된 데이터의 모양일 뿐 그 이상 그 이하도 아니다.

• Mongo DB에 저장한 데이터의 모습

[
	{ "id": 1, "name": "슬리퍼", "price": 30000},
    { "id": 2, "name": "바지", "price": 50000}
]

• SQL은 예를 들어 반팔이라는 데이터를 추가하려면 id, name에 해당 하는 값을 다 마련해야 한다. 반면, JSON document 형태는 대괄호와 중괄호만 구성하면 되고, 데이터마다 구성이 같을 필요 없이 개발자가 원하는 모양, 종류의 데이터를 저장할 수 있다.

2) key-value DB

• 읽고 쓰는 속도가 엄청 빠른 키값 데이터베이스(key-value DB)
• 대표적: 카산드라디비(CassandraDB), 다이나모디비(DynamoDB)
  - 카산드라디비의 특징을 열이 엄청 많은 데이터베이스다.
  - 수만 개의 데이터를 1초 만에 읽을 수 있다.
  • 애플, 넷플릭스, 인스타그램, 우버가 카산드라디비를 사용한다.

3) graph DB

• 노드로 관계를 표현하는 그래프 데이터베이스
• 열이나 도큐먼트는 필요하지 않은 대신, '노드'라는 개념이 필요함.

• user 1이 user 2를 팔로우 한다.
• user 2가 사진 1에 좋아요를 눌렀다.

그래서 어떤게 좋은데요?

용도에 맞게 쓰자! 실제로 인스타그램도 처음에는 PostgreSQL, 즉 SQL 데이터베이스로 시작을 했지만 회사가 점점 성장하면서 graph database (NoSQL database)로 옮겼다. 이처럼 기술에는 좋고 나쁨이 없으니 상황에 맞게 쓰자.

📌에피소드 33. 깃 & 깃허브, 똑같은 거냐고?

깃: 커피
깃허브: 커피숍

깃

• 깃은 감시자다.
  왕이 하는 말을 기록하는 사관처럼, 깃은 파일을 항상 지켜보는 감시자다. 깃은 내가 파일에 무엇을 기록했고, 무엇을 지웠고, 파일을 이동했는지, 파일을 아예 지워버렸는지 모두 알고있다.

• 깃은 어벤져스에서 여러 버전의 주인공과 같다.
  같은 파일이라도 다른 버전으로 보관할 수 있다.
  

또다른 예로는, 소설의 엔딩이 3가지가 있고 앞의 내용을 수정하고 싶을 때 파일을 3개 준비해야 할까? 깃이 있다면 파일은 하나만 유지한 상태로 앞쪽의 수정할 내용을 한번에 적용할 수 있으면서 엔딩 버전은 3개를 준비할 수 있다.

• 깃은 함께 일하는 동료에게도 유용하다.
  같은 파일을 복사해서 각자 컴퓨터에 저장 후 작업한 뒤 다른 사람이 변경한 부분과 내가 변경한 부분을 비교해서 다시 하나로 만들 수 있다.

깃허브

• 깃허브는 깃으로 관리한 파일 이력을 모두 저장해서 공유할 수 있는 '곳'이다.
• 깃허브는 특정 폴더나 파일의 접근 권한을 친구에게줌으로써 파일 공유를 하는 점에서 파일 클라우드 서비스(원드라이브, 구글 드라이브)와 같다. 하지만 파일 뿐만 아니라 깃으로 관리한 '파일 이력'까지 공유할 수 있다는 점에서 차이가 있다.
• 깃허브에 깃 이력을 업로드 하는 것을 푸시, 내려받는 것을 풀이라고 한다.
  - 개발자가 자신의 컴퓨터에서 파일을 변경하면 깃 이력이 생기고, 이것을 깃허브로 밀거나 당기면서 작업한다.

📌에피소드 34. 버전을 표기하는 방법도 있어요?

SemVer (시맨틱 버저닝)

• semantic versioning specification
• 숫자 3개로 표시하는 버전 표기 방식
• 장고와 리액트가 사용

첫번째 숫자의 의미
1.1.0 -> 2.1.0

• 전체 이사를 하는 수준이라 새 버전에 맞게 기존에 작성했던 코드도 새롭게 업데이트 해줘야한다.
  

두번째 숫자의 의미
16.7.0 -> 16.8.0

• 새 기능을 추가하는 수준이라 기존에 작성한 프로젝트의 코드를 완전히 갈아 치울 필요는 없다.
  

마지막 숫자의 의미
4.0.0 -> 4.0.25

• 패치나 버그 수정을 의미한다.
• 4.0.25와 같이 표기되었다면 수정을 25번 한 것이다.