[WIL]항해99 4주차 주특기 숙련 회고록

항해 99 부트캠프 

 

4주차 주특기 숙련 주차 (11 . 22 월 ~ 11 . 27 토 )

 

 

 

 

목차

 

- 주특기 숙련 주차 개인 프로젝트

 

- ORM

 

- SQL vs NoSQL

 

- 4주차 소감 및 부족한 점

 

 

 

 

1. 주특기 숙련 주차 개인 프로젝트

 

4주 주특기 숙련 주차에서는 3주 주특기 기본 주차에서 했던 개인 프로젝트에서 기능들을 추가하는 개인 프로젝트를 진행했다. 이번 개인 프로젝트도 전 주와 같이 여러 조건들이 있었다.

 

1. 회원 가입 페이지
   • 회원가입 버튼을 클릭하기
   • 닉네임, 비밀번호, 비밀번호 확인을 입력하기
   • 닉네임은 최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)로 구성하기
   • 비밀번호는 최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패로 만들기
   • 비밀번호 확인은 비밀번호와 정확하게 일치하기
   • 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러메세지를 프론트엔드에서 보여주기
   • 회원가입 버튼을 누르고 에러메세지가 발생하지 않는다면 로그인 페이지로 이동시키기
2. 로그인 페이지
   • 로그인, 회원가입 버튼을 만들기
   • 닉네임, 비밀번호 입력란 만들기
   • 로그인 버튼을 누른 경우 닉네임과 비밀번호가 데이터베이스에 등록됐는지 확인한 뒤, 하나라도 맞지 않는 정보가 있다면 "닉네임 또는 패스워드를 확인해주세요"라는 메세지를 프론트엔드에서 보여주기
   • 로그인 버튼을 눌러서 에러 메세지가 발생하지 않는다면 전체 게시글 목록 조회 페이지로 이동시키기
3. 로그인 검사
   • 아래 페이지를 제외하고 모두 로그인 한 경우만 볼 수 있도록 하기
     • 회원가입 페이지
     • 로그인 페이지
     • 게시글 목록 조회 페이지
     • 게시글 조회 페이지
   • 로그인을 하지 않거나 올바르지 않은 경로로 접속한 사용자가 로그인이 필요한 경로에 접속한 경우 "로그인이 필요합니다." 라는 메세지를 프론트엔드에서 띄워주고 로그인 페이지로 이동시키기
   • 로그인 한 사용자가 로그인 페이지 또는 회원가입 페이지에 접속한 경우 "이미 로그인이 되어있습니다."라는 메세지를 띄우고 전체 게시글 목록 조회 페이지로 이동시키기
4. 게시글 조회 페이지 > 댓글 목록 조회
   • 로그인 하지 않은 사용자도 댓글 목록 조회가 가능하도록 하기
   • 현재 조회중인 게시글에 작성된 모든 댓글을 목록 형식으로 볼 수 있도록 하기
   • 댓글 목록 위에 댓글 작성란 만들기
     • 댓글 작성에 관한 기능은 5번 요구사항으로 연결하기
   • 댓글 목록 중, 내가 작성한 댓글인 경우 댓글 수정, 댓글 삭제 버튼 만들기
     • 댓글 수정 버튼을 누르면 6번 요구사항으로 연결하기
     • 댓글 삭제 버튼을 누르면 7번 요구사항으로 연결하기
   • 제일 최근 작성된 댓글을 맨 위에 띄우기
5. 게시글 조회 페이지 > 댓글 작성
   • 로그인 한 사용자만 댓글 작성이 가능하도록 하기
   • 게시글 조회 페이지 하단에 댓글 내용을 입력할 수 있는 댓글 작성 버튼 만들기
   • 로그인 하지 않은 사용자가 댓글 작성란을 누르면 "로그인이 필요한 기능입니다." 라는 메세지를 띄우고 로그인 페이지로 이동시키기
   • 댓글 내용란을 비워둔 채 댓글 작성 버튼을 누르면 "댓글 내용을 입력해주세요" 라는 메세지를 띄우기
   • 댓글 내용을 입력하고 댓글 작성 버튼을 누른 경우 작성한 댓글을 추가하기
6. 게시글 조회 페이지 > 댓글 수정
   • 내가 작성한 댓글만 수정 가능하도록 하기
   • 댓글 본문이 사라지고, 댓글 내용, 저장 버튼 생성하기
   • 댓글 내용에는 이전에 입력했던 댓글 내용을 기본 값으로 채우기
   • 수정할 댓글 내용은 비어 있지 않도록 하기
   • 저장 버튼을 누른 경우 기존 댓글의 내용을 새로 입력한 댓글 내용으로 바꾸기
7. 게시글 조회 페이지 > 댓글 삭제
   • 내가 작성한 댓글만 삭제 가능하도록 하기
   • "정말로 삭제하시겠습니까?" 메세지를 띄우고, 확인/취소 버튼 중 "확인" 버튼을 누른 경우 목록에서 해당 댓글을 삭제하기
   • 취소를 누른 경우 삭제되지 않고 그대로 유지하기
8. 회원가입 테스트 코드 작성
   • 회원가입시 구현한 아래 조건을 검사하는 테스트 코드를 작성하기
     • 닉네임은 최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)로 이루어져 있어야 합니다.
     • 비밀번호는 최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패합니다.
     • 비밀번호 확인은 비밀번호와 정확하게 일치해야 합니다.
     • 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러메세지가 발생합니다.
   • 테스트 코드 실행 시 실제로는 데이터베이스에 연결되지 않도록 하기
   • 각 조건 별로 2개 이상의 테스트 케이스가 존재하도록 하기

 

위와 같은 조건들을 구현해내기에는 백엔드를 주특기로 삼고 있는 나에게는 너무 힘들었던게 프론트도 건들여야 한다는게 좀 어려웠다.

뭔가 이 프로젝트에서 의도한 바는 뭔지 알 것 같다.

 

이제 주특기 주차들을 마무리하면 항해 99에서 프론트엔드를 주특기로 희망하는 분들과 협업을 하게 되는데 프론트엔드도 해본다면 협업을 할때 서로가 맡은 바를 이해를 할 수 있을 것 같았다.

 

벡엔드도 힘들고 프론트엔드도 힘들겠지만 프론트엔드에서 해야하는게 엄청 많은 것 같아서 내심 프론트엔드를 하시는 분들을 대단하게 생각할  수 있었다.

 

프론트에서 ejs파일을 사용을 했지만 템플릿 엔진은 사용안하고, html을 사용했다... 템플릿 엔진도 나중에 배워봐야겠다.

또한, 올바르지 않은 경로로 들어갈 시 로그인이 필요하다는 유저 정보를 담은 Middleware도 만들었다.

 

 

주특기 숙련 주차 개인 프로젝트

 

https://github.com/kwak9898/nodejs_2week.git

GitHub - kwak9898/nodejs_2week

 

 

 

 

 

2. ORM

 

ORM이란

• Object Relational Mapping, 객체-관계 매핑으로, 객체와 데이터베이스의 관계를 매핑해주는 도구다.
  • 객체 지향 프로그래믕은 클래스를 사용하고, 관계형 데이터베이스는 테이블을 사용한다.
  • 객체 모델과 관계형 모델 간에 불일치가 존재한다.
  • ORM을 통해 객체 간의 관계를 바탕으로 SQL을 자동으로 생성해서 불일치를 해결한다.
• 데이터베이스 데이터를 자동으로 매핑해주는 도구다.
  • 객체를 통해 간접적으로 데이터베이스 데이터를 다룬다.
• 객체와 관계형 데이터베이스 사이의 중계자(통역자) 역할을 한다.

 

ORM의 장점

• 객체 지향적 코드로 인해서 더 직관적이고 비즈니스 로직에 집중할 수 있게 도와준다.
  • CRUD를 위한 긴 SQL 문장을 작성할 필요가 없다. (하지만 여전히 Query작성은 필요)
  • 각 객체별로 코드를 작성해서 가독성을 높여준다.
  • SQL의 절차적 접근이 아닌 객체적인 접근으로 생산성을 높여준다.
• 재사용 및 유지보수의 편리성이 증가한다.
  • 매핑 정보가 명확하고, ERD를 보는 것에 대한 의존도를 낮출 수 있다.
  • ORM은 독립적으로 작성이 되어 있으며 해당 객체들은 재사용이 가능하다.
• DBMS에 대한 종속성이 줄어든다.
  • 대부분의 ORM은 DB에  종속적이지 않다.
  • 개발자는 Object에 집중함으로 DBMS를 교체하는 극단적인 작업에도 비교적 적은 리스크와 시간이 소요된다.
  • 중속적이지 않다는 것은 구현 방법 말고도 많은 솔루션에서 자료형 타입까지 유효하다.

(종속성 = 프로그램의 구조가 데이터의 구조에 영향을 받는 것을 의미한다.)

 

 

ORM의 단점

• 완벽한 ORM만으로는 구현이 어렵다.
  • 사용하기에는 편하지만 설계에는 매우 신중해야한다.
  • 프로젝트의 복잡성이 높아질 경우에는 난이도가 올라갈 수 있다.
  • 잘못 구현하게 되면 속도 저하와 심한 경우에는 일관성이 무너지는 문제점을 불러올 수 있다.
• 프로시저가 많은 시스템에서는 ORM의 객체 지향적인 장점을 활용하기가 어렵다.
  • 이미 프로시저가 많은 시스템에는 다시 객체로 바꿔야되고, 그 과정에서 생산성 저하와 리스크가 발생될 수 있다.

(프로시저 = 특정작업을 위한 프로그램의 일부이며, 함수와 같은 의미다.)

 

Sequelize

 

Node.js 에서 많이 사용되고, MySQL, PostgreSQL, MariaDB, SQLite, MSSQL을 지원한다.

(그 외에도 트랜잭션이나 relation, read replication등 지원한다.)

 

가장 큰 특징은 Promise(비동기작업 제어방식)를 바탕으로 지원해준다는 특징이 있다.

 

Promise의 장점

• 복잡한 비동기 코드를 깔끔하고 쉽게 만들 수 있도록 한다.
• Chaining을 통해서 값을 전달하거나 연속된 일련의 작업을 처리할 수 있다.
• Error handling에 대한 처리를 깔끔하게 처리할 수 있다.

이러한 이유들로 Node.js를 이용하는 사람들은 Sequelize를 가장 많이 사용하고, 실제 Sequelize도 Node.js에 가장 특화된 ORM이라 할 수 있다.

 

Prisma

 

특징은 GraphQL스키마를 기반으로 DB를 자동생성 해준다.

 

GraphQL이란?

facebook에서 만든 Graph Query Language로 애플리케이션 쿼리 원어로 기존의 REST API의 한계점을 개선하고자 나온 통신 규약으로 REST API를 대체할 수 있다.

 

GraphQL 장점

• 요청메시지가 값이 없는 JSON과 비슷하며 받는 데이터는 JSON형식이다.
• 단일요청으로 원하는 데이터를 한번에 가져올 수 있다.
• type system을 지원한다.
• GraphiQL 등의 강력한 도구를 사용할 수 있다.
• 확장성이 좋다.

이러한 장점이 있고 이 것들을 기반으로 Prisma가 요즘에 뜨는 ORM이다. GraphQL이 성장을 하고 있지만 아직까지는 완벽하게 REST API를 대체하지는 못할 것이다.

 

 

 

 

3. SQL vs NoSQL

 

SQL (관계형 데이터베이스)

• SQL은 '구조화 된 쿼리 언어 (Structured Query Language)'의 약자이다.
• 그러므로 데이터베이스 자체를 나타내는 것이 아니라, 특정 유형의 데이터베이스와 상호 작용하는 데 사용 하는 쿼리 언어다.
• 그러나 SQL을 '관계형 데이터베이스' 라는 의미로도 사용한다.
• SQL을 사용하면 관계형 데이터베이스 관리 시스템(RDBMS)에서 데이터를 저장, 수정, 삭제 및 검색을 할 수 있다.

SQL의 주요 특징

 

1. 엄격한 스키마

데이터는 테이블에 레코드로 저장이 되고, 각 테이블에는 명확하게 정의된 구조가 있다.

(구조란 어떤 데이터가 테이블에 들어가고 어떤 데이터가 그렇지 않을지를 정의하는 필드 집합을 가르킨다.)

 

구조는 필의 이름과 데이터 유형으로 정의된다.

출처 https://siyoon210.tistory.com/130

• SQL은 스키마를 지키지않으면 레코드를 추가할 수 없다.
• 더 많은 필드를 얻고 싶으면 다른 테이블을 선택해야된다. 일부 필드가 누락되어도 다른 테이블을 선택해야된다.
• 스키마를 다시 만들지 않는 한 필드를 추가할 수 없다.

 

2. 관계

데이터들을 여러 테이블에 나눠서 데이터들이 중복되는 것을 피할 수 있다. 예를 들면 사용자가 구입한 상품들을 나타내기 위해 사용자, 상품, 주문상품의 여러 테이블을 만들어야 하지만, 각각의 테이블들은 다른 테이블에 저장되지 않은 데이터만을 가지고 있다.

출처 https://siyoon210.tistory.com/130

중복되지 않은 명확한 구조의 장점이 있다. 하나의 테이블에서 중복없이 하나의 데이터만을 관리하기 때문에, 다른 테이블에서 정확하지 않은 데이터를 다룰 위험이 없다.

1. SQL 장점
   • 명확하게 정의가 된 스키마, 데이터 무결성 보장
   • 관계는 각 데이터를 중복없이 한번만 저장이 된다.
2. SQL 단점
   • 상대적으로 덜 유연하다. 데이터 스키마는 사전에 계획이되어 있어야한다. (추후에 수정하기 불편하거나 불가능 할 수 있다.)
   • 관계를 맺고 있기 때문에, join문이 많은 복잡한 쿼리가 만들어질 수 있다.
   • 수평적 확장이 어렵고, 대체로 수직적 확장만 가능하다. 
   • 처리할 수 있는 처리량과 관련해서 성장 한계에 직면하게 된다.

 

SQL은 언제 사용할지

• 관계를 맺고 있는 데이터가 자주 변경이 되는 애플리케이션일 경우
• 변경될 여지가 없으며 명확한 스키마가 사용자와 데이터에게 중요한 경우

  

 

NoSQL (비관계형 데이터베이스)

 

SQL과 반대되는 접근방식을 따른다.

• 스키마가 없다.
• 관계가 없다.
• 레코드를 문서라고 부른다.

NoSQL에서는 다른 구조의 데이터를 같은 컬렉션(SQL의 테이블과 같은 의미)에 추가할 수 있다.

출처 https://siyoon210.tistory.com/130

• 문서는 JSON 형식과 비슷한 형태를 가지고 있다. 스키마는 없기 때문에 신경을 쓸 필요가 없다.
• 여러 테이블에 나누어서 담는 SQL과 다르게 관련 데이터들을 같은 컬렉션에 넣는다.
• 예를 들어 많은 주문상품이 있는 경우에는 일반적인 정보를 모두 포함한 데이터를 주문상품 컬렉션에 저장한다. 즉 사용자나 상품들에 대한 정보들을 주문상품에 포함해서 한꺼번에 저장을 한다. 
• 따라서 여러 테이블과 컬렉션에 join할 필요없이 이미 필요한 모든 것을 갖춘 문서를 작성할 수 있다.
• NoSQL은 join이라는 개념이 존재하지 않는다.
• 대신 컬렉션을 통해 데이터를 복제해서 각 컬렉션 일부분에 속하는 데이터를 정확하게 산출하도록 해야된다.

출처 https://siyoon210.tistory.com/130

• 이런 방식은 데이터가 중복이돼서 불안정한 측면이 있다.
• 실수로 컬렉션 B에서는 데이터를 수정하지 않았는데, 컬렉션 A에서만 데이터를 업데이트 할 위험이 있다.
• 특정 데이터를 같이 사용하는 모든 컬렉션에서는 똑같은 데이터가 업데이트 되도록 해야된다.
• NoSQL의 큰 장점은 어떨 때 느리거나 복잡하고 join을 사용할 필요가 없다.
• 수정이 자주 필요하지 않는 데이터면 더 큰 장점이 있다.

 

1. NoSQL 장점
   • 스키마가 없어서 유연하다. 언제든지 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있다.
   • 데이터는 애플리케이션이 필요로 하는 형식으로 저장된다. 그래서 데이터를 읽어오는 속도가 빠르다.
   • 수직적 확장과 수평적 확장이 가능해서 데이터베이스가 애플리케이션에서 발생시키는 모든 읽기 / 쓰기 요청을 처리할 수 있다.
2. NoSQL 단점
   • 유연성 때문에 데이터 구조 결정을 못 하고 미루게 될 수 있다.
   • 데이터 중복은 여러 컬렉션과 문서가 여러 개의 레코드가 변경된 경우 업데이트를 해야된다.
   • 데이터가 여러 컬렉션에 중복되어 있기 때문에 수정을 해야하는 경우 모든 컬렉션에서 수정을 해야된다.

 

NoSQL은 언제 사용할지

• 정확한 데이터 구조를 알 수 없거나 변경이나 확장이 될 수 있는 경우
• 읽기 처리를 자주하지만, 데이터를 자주 변경하지 않는 경우
• 데이터베이스를 수평으로 확장해야하는 경우 즉 막대한 데이터를 다뤄야할 때

 

 

4. 4주차 소감 및 부족한 점

4주차가 끝났다. 뭔가 훅 지나간 것 같다. 이번주에는 추가된 기능들을 구현하느라 하루에 평균 4시간을 잔 것 같다. 괴롭다기 보다는 재밌어서 내가 잠을 줄여가면서도 코딩을 할 수 있던 것 같다.

 

항해99 대표님을 만나 팀별로 면담을 진행했는데, 인상적인 말이 있었는데 개고생해본 사람들이 현업에 가서도 잘 적응하고 좋은 퍼포먼스를 발휘한다는 것이다. 뭔가 그 말을 듣고 깨닫는게 있어서 더욱 더 코딩을 할때 대충 넘어가는게 아니라 내가 쓴 코드에 대해서 왜 이렇게 썼을까 라는 생각을 했고 이 시간이 결코 헛되지 않을꺼란 생각이 들었다.

 

개인 프로젝트를 하면서 초반에는 하 어떻게 하지 했지만 에러가 나면 그것을 수정해서 기능 구현에 성공을 하면 엄청 뿌듯했던 것 같다. 어떨 때는 꿈에서 코딩을 했던 꿈도 꿨던 것 같다. 진짜 그정도로 열심히 했나보다.

 

아직은 혼자 할 수 없지만 문제가 발생돼서 해결이 안되면 화면을 공유 해놓고 팀원 분들이나 다른 분들 앞에서 에러를 해결해 나갔던 것 같다. 이게 프론트처럼 보이지가 않아서 에러를 수정하기 어려웠지만 이게 백엔드에 매력이지 않을까 싶다.

 

다음주에 있을 5주차는 주특기 심화 주차로 주특기 커리큘럼의 마지막 주차이다. 마지막 주차인 만큼 얻고 가는게 많았으면 좋겠다.

5주차도 열심히 해야겠다!