오늘 읽은 범위: ep.30 코로나가 준 레거시 시스템의 교훈 ~ ep.34 버전을 표기하는 방법도 있어요?
기억하고 싶은 내용(간단하게 내용 정리):
ep.30 코로나가 준 레거시 시스템의 교훈
코볼(COBOL. common business oriented language)은 과거에는 미국의 은행 시스템과 ATM 시스템의 대다수에 사용된 인기있는 언어였다. 하지만 현재는 거의 사용하지 않아 사용자 커뮤니티가 매우 적은 옛날 언어가 되었으며, 이에 따라 코볼로 개발한 프로그램을 관리할 사람이 점점 사라지는 문제가 생기게 되었다.
레거시 시스템(legacy system): 오래 전에 개발된 시스템(레거시 legacy: 유산)
미국 뉴저지 정부 사이트는 코볼로 구현된 30년이 넘은 오래된 시스템이었다. 코로나로 발생한 실업자들을 지원해주기 위한 시스템 사용이 증가하게 되면서 코볼 개발자가 급하게 필요하게 되었다. 코볼 개발자를 구하면서 정부 시스템 관리자는 프로그램에 사용된 언어 이름도 제대로 알지 못해 시스템 관리에 관심이 없고 프로그램을 오랫동안 방치했다는 문제점을 부각시켰다.
이 사건은 레거시가 우리 생활에 큰 영향을 끼친 사례로 볼 수 있으며 이를 통해 두 가지 교훈을 얻을 수 있다. - 1. 개발자는 프로그램을 좀 더 책임감 있게 만들어야 하며, 자신이 만든 프로그램에 완벽하게 책임을 져야 한다. - 2. 시스템은 한번 구축하면 끝이 아니다. 개발자는 프로그램을 꾸준하게 끊임없이 관리해야 한다.
ep.31 데이터와 단짝 친구, SQL
SQL(structured query language)은 데이터베이스에 어떤 질문 또는 문의를 하기 위해 어떤 구조를 가진 언어이다. 즉, 데이터베이스(창고)를 관리해주는 DBMS와 대화하기 위한 언어이다.
DBMS(database management system)은 데이터베이스 관리 시스템을 말하며, SQL로 데이터베이스와 상호작용을 하려면 DBMS를 거쳐야 한다. - DBMS의 종류: MySQL, PostgreSQL, SQLite, Oracle, MariaDB 등
데이터베이스에서 한 무리의 데이터를 테이블(table)이라고 한다.
SQL 문법 예시 - e.g. SELECT age FROM users WHERE email LIKE "%kmail.com"; : kmail.com이라는 이메일을 사용하는 사람들의 나이 가져오기
ORM(object relational mapping)은 개발자에게 SQL 번역기 같은 도구로, 사용자에게 익숙한 프로그래밍 언어로 SQL을 사용할 수 있게 해준다. - ORM의 종류: 파이썬에는 장고 ORM(Django ORM), 라라벨에는 엘러퀀트 ORM(eloquent ORM), 노드제이에스에는 시퀄라이즈 ORM(Sequelize ORM)이나 타입 ORM(type ORM)이 있다.
개발자가 ORM에 지나치게 의존하면 ORM만으로 해결하기 어려운 상황에 대처하기 어렵기 때문에 개발에 꼭 필요한 데이터와 데이터베이스를 이해할 수 있게 해주는 SQL의 기초 공부를 해야한다. 꼭 시간을 투자해서 공부해 볼 것을 권함.
ep.32 NoSQL(노에스큐엘)이 뭐죠?
NoSQL은 SQL과 성격 자체가 다르다. 언어의 특징만 있는 것이 아니라 그들이 사용하는 데이터베이스 자체의 성질도 다르다.
NoSQL의 데이터베이스 종류 (사실 더 많다)
데이터 형식이 매우 자유로운 도큐먼트 데이터베이스(document DB) - 대표적인 예: 몽고디비(MongoDB) - 몽고디비는 데이터를 {키1: 값1, 키2: 값2, ...} 형태로 구성된 데이터의 모양으로 저장된 파일인 제이슨(JSON. JavaScript object notation) 도큐먼트(document) 형태로 저장한다. - SQL로 다루는 데이터베이스는 데이터를 행과 열의 개념으로 저장한 표의 형태를 띠고 있으며 정적인 형태를 가진다. 만약 열을 늘리고 싶다면 다른 행에는 반드시 그 행에 해당하는 값을 넣어주어야 한다. 반면 JSON 도큐먼트 형태는 대괄호와 중괄호로만 구성하면 되고, 데이터마다 구성이 같을 필요가 없기 때문에 개발자가 원하는 모양과 종류의 데이터라도 저장할 수 있다는 장점이 있다.
읽고 쓰는 속도가 엄청 빠른키값 데이터베이스(key-value DB) - 대표적인 예: 카산드라디비(CassandraDB), 다이나모디비(DynamoDB) -카산드라디비의 특징은한 행의 열이 넓다는(column wide) 것이다. 그리고 읽고 쓰는 속도가 정말 빠르다는 장점 때문에대용량 데이터를 빠르게 저장해야 하거나 읽어야할 때사용하면 좋다. (e.g. 애플, 넷플릭스, 인스타그램, 우버) -다이나모디비는 아마존이 만들었으며 1초에 2만 4,000개 데이터를 읽을 수 있을 정도로굉장히 빠르다. (e.g. 듀오링고)
노드로 관계를 표현하는 그래프 데이터베이스(graph DB) - 열이나 도큐먼트가 필요하지는 않고 노드라는 개념이 필요하다. 노드란 변과 함께 그래프를 구성하는 요소로 그래프를 이루는 점을 말한다. - 그래프 데이터베이스는 데이터를 각각 관계망으로 연결하는 페이스북 등의 서비스에서 사용한다.
SQL 데이터베이스와 NoSQL 데이터베이스 중 우위를 가릴 수는 없다. 기술은 용도에 맞게 쓰면 된다. e.g. 인스타그램의 경우 SQL 데이터베이스(PostgreSQL)로 시작했다가 회사가 성장하면서 NoSQL 데이터베이스(그래프 데이터베이스)로 옮겼다.
몽고DB에 저장한 데이터의 모습 (도큐먼트 데이터베이스)
ep.33 깃&깃허브, 똑같은 거냐고?
깃(git)은 파일 이력을 관리하는 프로그램이다.
깃은 파일을 항상 지켜보고 기록하는 사관 역할을 한다. 깃은 같은 파일이라도 다른 여러 버전으로 보관할 수 있어 버전 관리를 가능하게 해준다.
깃은 같은 파일을 복사해서 각자 컴퓨터에 저장해서 작업한 뒤 다른 사람이 변경한 부분과 내가 변경한 부분을 비교해서 다시 하나로 합칠 수도 있다. 그래서 내가 실수한 부분이 있다면 다른 동료가 확인할 수 있어 협업도 매우 쉬워진다.
깃허브(Github)는 파일과 깃으로 관리한 파일 이력을 모두 저장해서 공유할 수 있는 공간이다.
깃허브는 파일 클라우드 서비스와 같다. 다만 파일 뿐만 아니라 깃으로 관리한 파일 이력도 공유할 수 있다는 점에 차이가 있다. e.g. 깃허브(Github), 깃랩(GitLab), 비트버킷(Bitbucket)
파일 변경을 하면 버전별로 깃 이력이 생기고, 이것을 깃허브에 업로드하거나(푸시. push) 내려받는다(풀. pull)
ep. 34 버전을 표기하는 방법도 있어요?
숫자 3개를 사용하는 버전 표기 방식을 시맨틱 버저닝(semantic versioning specification, SemVer)이라고 하며 가장 널리 쓰이는 버전 표기 방식이다. e.g. 대표 기술에는 리액트와 장고가 있다. - 첫 번째 숫자의 의미: 프로그램에 엄청나게 큰 변화가 있을 때 바뀐다. (새집으로 이사하는 수준) - 중간 숫자의 의미: 마이너한 업데이트. 기능을 추가하는 수준. (소품, 인테리어로 살짝 업그레이드) - 마지막 숫자의 의미: 패치나 기존 프로그램의 버그 수정을 의미한다. (e.g. 4.0.25는 수정을 25번 했다고 생각해도 좋다)
개발자는 꼭 맥북을 사용해야 하나? - 시간을 많이 절약해 줄 수 있는 물건인가? - 동기 부여를 할 수 있는 물건인가? - 방해 요소를 줄일 수 있는 물건인가?
오늘의 파트에 대한 소감(떠오르는 생각) :
레거시 프로그램의 교훈 부분을 읽고 다시 한 번 개발자가 가져야 할 마음가짐과 태도에 대해 생각해볼 수 있었다. 개발자는 책임감을 갖고 프로그램을 만들고 그 결과물에 따른 책임을 져야 하며, 프로그램을 꾸준하게 끊임없이 관리해야 한다! 당연한 것이라고 생각했던 내용들을 다시 읽어보면서 그 무게감을 새삼 다시 느낄 수 있었다. 앞으로 내가 만들 프로그램과 서비스가 세상에 긍정적인 영향을 주고, 내가 그것에 대해 보람과 뿌듯함을 느낄 수 있다면 정말 더할 나위 없이 좋을 것이다. 생각만 해도 기분이 좋다ㅎㅎ🥰
ORM은 스프링부트와 JPA 관련 책에서 용어만 들어보고 정의를 몰랐는데 이번에 새롭게 알게 됐다. ORM을 이용하면 프로그래밍 언어로 SQL을 쓸 수 있기 때문에 SQL에 대한 의존도가 낮아진다. SQL 기초를 다지면 좋다고 책에서 하는데 SQL 공부도 할 겸 SQLD 자격증을 같이 준비해봐야겠다!
깃과 깃허브를 사용하면서도 잘 모르고 많이 쓰는 기본적인 기능만 쓰는 정도인데 다양한 사용법을 익혀 깃을 좀 더 자유자재로 사용해보고 싶다. 리드미 작성, 내 깃허브 페이지 꾸미는 방법 등도 찾아보고 적용해봐야겠다는 생각이 들었다.
추가로 알게된 것(책내용+a 로 궁금한 것, 이해가 가지 않는 것 등)
책에 나온 그래프 데이터베이스에서 노드에 대한 설명이 간단해서 노드의 정의를 찾아보았다. 노드는 그래프를 이루는 점을 말하며 변과 함께 그래프를 구성하는 요소이다.
깃과 깃허브 사용법과 리드미 작성, 내 깃허브 페이지 꾸미는 법 등을 좀 더 찾아보고 익혀보자.
소감 3줄 요약(오늘 TIL 3줄 요약) :
SQL은 DBMS와 대화하기 위한 언어이며, DBMS를 거쳐 데이터베이스와 상호작용한다.
기술에는 좋고 나쁨이 없다. 용도에 맞게 쓰면 되니까 비교해보면서 우위를 따지는 실수를 하지 않도록 하자.
시맨틱 버저닝 표기 방식으로 첫번째 숫자는 대대적인 변경 사항이 있을 때, 중간 숫자는 기능 추가 정도의 버전 업데이트, 마지막 숫자는 패치나 기존 프로그램의 버그 수정을 의미하는 버전 업데이트를 뜻한다.
