23년 3월 2일
배운 것
오늘은 딱히 배운 것이라고 하기에는 뭔가 없고, 퀴즈 시험과 팀원들이랑 이번 주특기 입문주차에서 잘 몰랐던 개념이나 용어를 정리해보는 일을 하였다.
시도 한 것
아침에 퀴즈시험이 있었는데 개인 프로젝트에서 충분히 했다면 어려웠던 시험은 아니였다. 개인 프로젝트에서 적었던 API코드들을 다시 가져와서 변수나 메소드 일부만 수정 시켜주면 가능했었다.
스키마는 미리 다 정의가 되었었기 때문에 부담 없이 기존에 썼던 코드들을 가져와서 일부만 수정하면 되었다. 그렇게 시험은 2시간이였지만 30분이면 충분히 마무리 할 수 있었던 시험이였다. 이것도 합격과 불합격 유무는 상관이 없었기에 그렇게 마무리 하였다.
그리고 점심 먹고 나서 그간 개인과제에 다들 끙끙거려서 미처 하지 못했던 팀 과제를 하기 시작하였다. 팀과제는 간단했다. 총 4가지 질문이 있는데 그걸 직접 구글링해서 개념의 답을 찾는 것이였고, 그 외로 이번주에서 특히 중요했다고 생각했던 키워드를 5가지를 선정하여서 추가로 적는 것이였다.
먼저 4가지 질문부터 조사한 것은 나는 다음과 같이 정리를 하였다.
-
for 문이 있는데 for ... in for...of 문법이 새로 나온 이유는 무엇일까요? 우리가 이것을 고르는 기준은 무엇일까요?
기존의 for문 방식은 (초기식; 표현식; 증감식;) 으로 for...of나 for...in에 비해서 간단하게 표현하기 전의 방식이기 하다.
for...of는 배열의 반복에서 사용된다. 객체에서 쓰면 오류가 난다.
for...in은 객체의 반복에서 사용된다. 배열에서도 써도 오류는 나지 않지만 그 배열의 인덱스 값이 나온다. -
restAPI의 put 과 patch 는 어떤 차이점이 있을까요? 어떤 경우에 사용하면 좋을까요?
데이터를 수정하는 방법에는 PUT과 PATCH가 있다.
PUT : 리소스의 모든 것을 업데이트 한다. 변경하지 않는 정보도 같이 적어야 한다. (변경하지 않는 정보를 넣지 않으면 NULL로 대체됨)
PATCH : 리소스의 일부를 업데이트 한다. 변경하지 않는 정보도 같이 적을 필요가 없다. -
몽고DB로 테이블 설계를 해봅시다. 회원가입을 한 유저가 게시판에 글을 쓰는 서비스입니다. 게시판 목록 페이지에서는 게시글 제목, 작성자 이름 등이 보이겠죠? 각각의 모델은 어떤 모양새이면 좋을까요? 게시판 글 리스트를 불러오는 api 에서는 몽구스 데이터를 어떻게 가져오면 좋을까요?
게시글을 적기 위해서는 우선 글을 쓴 작성자(user), 게시글의 제목(title), 게시글의 내용(content)을 필수적으로 들어가야 한다.
추가적으로 그 사람의 비밀번호(password)를 추가해서 나중에 게시글을 수정이나 삭제할때 그 사람인지 인증을 하는 것도 넣으면 좋다.
마지막으로 그 사람이 언제 게시글을 적은 날짜(createAt)를 넣으면 언제 적었는지 볼 수 있다.
user: { // 작성자
type: String,
required: true
},
title: { // 제목
type: String,
required: true
},
content: { // 내용
type: String,
required: true
},
// 아래 두개는 필수는 아니나 추가적으로 넣을 때 좋은 스키마 정의
password: { // 비밀번호
type: String,
required: true
},
createAT: { // 작성날짜
type: Date,
required: false
};- 우리가 브라우저에서 구매한 도메인 주소를 입력하면 만들어 놓은 aws EC2 서버까지 전달이 되어서 해당 서버에게 요청을 보낼 수 있습니다. 이 과정이 상세하게 어떻게 진행되는지 그림으로 한번 그려볼까요?
+----------+ +------------+
| | | |
| User's | | AWS EC2 |
| Browser | | Server |
| | | |
+----------+ +------------+
| |
| DNS Lookup |
|------------------------>|
| |
| Return IP Address |
|<------------------------|
| |
| HTTP Request |
|------------------------>|
| |
| Process Request |
|<------------------------|
| |
| HTTP Response |
|<------------------------|
| |- 사용자는 브라우저에 도메인 이름을 입력하고 Enter 키를 누릅니다.
- 브라우저는 도메인 이름을 IP 주소로 확인하기 위해 DNS 조회 요청을 DNS 서버로 보냅니다.
- DNS 서버는 AWS EC2 서버의 IP 주소로 응답합니다.
- 브라우저는 IP 주소를 사용하여 AWS EC2 서버에 HTTP 요청을 보냅니다.
- AWS EC2 서버는 요청을 처리하고 HTTP 응답을 생성합니다.
- HTTP 응답이 브라우저로 다시 전송됩니다.
다음은 입문 주차에 대해서 다시 생각해보거나 필요했던 개념을 5가지 정도 정리하였다.
1. CURD
CRUD는 Create, Read, Update, Delete의 약자입니다. 데이터에 대한 기본 작업을 수행하기 위해 컴퓨터 프로그래밍 및 데이터베이스 관리에서 일반적으로 사용되는 방법입니다.
만들기(CREATE): 이 작업은 데이터베이스 또는 시스템에서 새 데이터를 만드는 것을 말합니다. 예를 들어 새 사용자 계정을 만들거나 온라인 상점에 새 제품을 추가합니다.
읽기(READ): 이 작업에는 데이터베이스 또는 시스템에서 기존 데이터를 읽거나 검색하는 작업이 포함됩니다. 예를 들어 사용자의 프로필을 검색하거나 제품의 세부 정보를 표시합니다.
업데이트(UPDATE): 이 작업에는 데이터베이스 또는 시스템의 기존 데이터를 수정하거나 업데이트하는 작업이 포함됩니다. 예를 들어 사용자의 비밀번호를 변경하거나 제품 가격을 업데이트합니다.
삭제(DELETE): 이 작업에는 데이터베이스 또는 시스템에서 데이터를 삭제하거나 제거하는 작업이 포함됩니다. 예를 들어 사용자 계정을 삭제하거나 온라인 상점에서 제품을 제거합니다.
CRUD 작업은 데이터 저장 및 관리와 관련된 대부분의 소프트웨어 응용 프로그램의 기본 빌딩 블록으로 간주됩니다. 데이터와 상호 작용하는 간단하고 표준화된 방법을 제공하며 웹 애플리케이션, 모바일 앱 및 기타 소프트웨어 시스템에서 널리 사용됩니다.
2. express의 request, response
Request
클라이언트가 서버에게 연락하는 것을 요청이라고 하며, 요청을 보낼때는 요청에 대한 정보를 담아 서버로 보낸다.
Response
서버가 요청에 대한 답변을 클라이언트에게 보내는 것을 응답이라고 한다.
3. SQL 과 NoSQL의 차이
SQL 데이터베이스는 테이블을 사용하여 데이터를 저장하는 관계형 데이터베이스입니다. 각 테이블에는 데이터 구조를 정의하는 행(레코드)과 열(필드)이 포함되어 있습니다. SQL 데이터베이스는 구조화된 데이터를 처리하고 관계 및 제약 조건을 통해 데이터 무결성을 강화하는 기능으로 잘 알려져 있습니다.
반면에 NoSQL 데이터베이스는 테이블을 사용하지 않는 비관계형 데이터베이스입니다. 대신 문서 지향, 키-값, 그래프, 컬럼 패밀리 등 다양한 데이터 모델을 사용하여 데이터를 저장하고 관리합니다. NoSQL 데이터베이스는 구조화되지 않은 데이터를 처리하고 여러 서버에서 수평으로 확장하는 기능으로 잘 알려져 있습니다.
4. 스키마
스키마는 데이터를 구성하고 저장하는 방법을 정의하는 청사진 또는 구조입니다. 여기에는 테이블, 열, 제약 조건 및 테이블 간의 관계가 포함됩니다. 스키마는 전체 데이터베이스의 논리적 보기를 제공하고 데이터의 일관성과 정확성을 보장합니다.
5. HTTP 상태코드
HTTP 상태 코드는 HTTP 요청에 대한 서버의 응답을 나타내며, 다양한 상황에 따라 여러 가지 상태 코드가 있습니다. 자주 볼 수 있는 HTTP 상태 코드에는 다음과 같은 것들이 있습니다.
- 200 OK: 요청이 성공적으로 처리되었음을 나타냅니다.
- 201 Created: 새로운 리소스가 성공적으로 생성되었음을 나타냅니다.
- 204 No Content: 요청은 성공적으로 처리되었지만, 응답으로 반환할 콘텐츠가 없음을 나타냅니다.
- 400 Bad Request: 요청이 잘못되었거나 서버가 요청을 이해할 수 없는 경우를 나타냅니다.
- 401 Unauthorized: 요청한 리소스에 대한 권한이 없는 경우를 나타냅니다.
- 403 Forbidden: 요청이 서버에서 거부되었음을 나타냅니다.
- 404 Not Found: 요청한 리소스를 찾을 수 없음을 나타냅니다.
- 500 Internal Server Error: 서버에서 처리 중에 오류가 발생했음을 나타냅니다.
- 503 Service Unavailable: 서버가 요청을 처리할 수 없음을 나타냅니다.
이 외에도 다양한 HTTP 상태 코드가 있지만, 위에서 언급한 상태 코드들은 자주 볼 수 있는 상태 코드들입니다.
이렇게 팀 과제는 구글링과 챗GPT를 이용해서 찾아밨고 다시 한 번 더 개념을 생각해보는 시간을 가지게 되었다.
이 뒤로는 이번 입문주차때 할 것은 다 했기 때문에 이 후에 SQL이 언급된다고 해서 SQL 문법정도 예전에 내가 적었던던거 보면서 복습정도 하였다.
마지막으로 저녁에 오늘 풀었던 퀴즈의 해설하는 세션 특강을 듣게 되었다. 물론 내가 적은 코드들도 있었지만 더 간단하게 try...catch문을 이용해서 구현하는 것이 가능하였다.
또한 1명만 조회 하는 것도 findOne으로 찾아 낼 수 있다는 것도 나중에 알게 되었다. 강의노트에서 실습할때는 살짝 언급정도만 했을 뿐 실제로 강의 실습 할 때는 사용하지 않았었는데 다음에는 저 코드를 사용하면서 구현하면 좋을 것 같다.
해결
그렇게 시험과 팀과제를 끝으로 오늘로 입문주차의 여정은 마무리 되었다.
알게 된 점
저번주 목요일부터 수요일까지 지옥의 강의랑 개인 프로젝트 과제 하느라 엄청 고생을 하였다. 개인 프로젝트는 이거 내가 다 구현 못하면 어쩌지 불안함이 많았었는데 결국에는 팀원들에게 도움을 청하는 것이 중요하였다. 그리고 애러 찾는 것도 구글링을 하면서 알아보고 그런 것들도 중요하였다. 덕분에 시험도 무사히 개인 프로젝트 했던거 다시 코드 보면서 해결도 하였고, 팀과제도 2시간만에 개념들을 정리하면서 복습도 마무리 했다. 이 후 SQL 강의가 제공이 되었는데 이거는 작년 12월에 한번 들었던 강좌여서 간단하기 강의노트 보고 예전에 적었던 블로그 코드들을 보면서 복습하는 시간만 가졌다. 이후 주특기 숙련, 심화 주차때 이용 할거라고 해서 간만에 오늘 하루는 많은거는 하지 않고 그동안 체력적으로 힘들었기에 SQL 잠깐 복습 한 것으로 끝으로 푹 쉰 것 같다.
마지막으로 그동안 개인 프로젝트가 막혔을때 도와줬던 팀원 두분이 도와줘서 무사히 개인 프로젝트를 마칠 수 있어서 좋았다.
이렇게 주특기 node 입문주차는 이렇게 마무리 되었다. 그동안 막혔을때 도와줬던 팀원 두분이 있었기에 무사히 입문주차도 성공적으로 마무리 하였다. 물론 깜빡하고 날짜 구현까지는 하지 못하고 제출했는데 이부분은 아쉽긴 하였다.
앞으로 할 일
내일부터는 주특기 2번째 주차로 숙련 주차가 시작된다. 오늘로 딱 25일차인데 이제 전체 일정의 1/4이 지났다. 또 새로운 고비가 오겠지만 입문주차때를 생각해보면서 계속 도전 해볼 예정이다.
