zuryeong의 개발 블로그

1. 파일 시스템의 문제점

   1) 데이터 중복성

      -1 한 시스템 내에 같은 내용의 데이터가 여러 파일에 저장 관리됨

      -2 문제점

         (a) 경제성 : 추가적인 공간과 갱신 비용 증가

         (b) 일관성 : 데이터 간의 모순, 불일치 발생

         (c)  무결성 : 데이터 정확성 유지 어려움

      -3 파일 시스템의 데이터 중복성 해결 : 데이터 통합

   2) 데이터 종속성

      -1 응용 프로그램과 데이터 사이의 의존관계

   3) 동시 공유, 보안, 권한 부여, 회복 기능 부족

   4) 응용 프로그램을 개발하기 어려움

2. DBMS

   1) 데이터의 종속성과 중복성의 문제를 해결하기 위해 데이터베이스를 공용할 수 있도록 관리하는 시스템 소프트웨어

   2) 응용 프로그램은 데이터베이스의 생성, 접근방법, 물리적 구조 등 자세한 설명 없이 원하는 데이터와 처리 작업을 

        DBMS에 요청

   3) 컴퓨터 시스템에서 DBMS의 위치는 -> 중간, MID 역할

3. DBMS의 필수 기능

   1) 정의 기능

      -1 다양한 형태의 데이터 요구를 지원할 수 있도록 가장 적절한 데이터베이스 구조를 정의할 수 있는 기능 

      -2 데이터 구조 정의에 고려해야 할 사항들

      -3 스키마를 정의하거나 수정 또는 삭제하기 위해 사용

      -4 DDL

   2) 조작 기능

      -1 사용자와 데이터베이스 사이의 인터페이스를 위한 수단 제공

      -2 사용자의 요구에 따라 체계적으로 데이터베이스를 접근하고 조작 가능해야 함

      -3 조작 기능에 고려해야 할 사항 : 쉽고 자연스러운 조작방법 명확하고 완전한 데이터 사이의 명세가 가능해야 함

          효율적인 데이터 접근, 처리

      -4 데이터의 검색, 삽입, 삭제, 수정 등의 처리를 요구하기 위해 사용

      -5 DML

   3) 제어 기능

      -1 데이터의 정확성과 보안성을 유지하는 기능

      -2 제어 기능에 고려해야 할 사항들 : 무결성 유지

                                                                보안, 권한 검사

                                                                병행 제어

                                                                 회복

      -3 내부적으로 필요한 규칙(무결성, 보안, 회복, 동시성 보장 등)이나 기법을 정의하기 위해 사용

      -4 DCL

4. DBMS의 장단점

   1) 장점

      -1 데이터 중복의 최소화

      -2 데이터 독립성 확보

      -3 데이터의 공용

      -4 데이터의 일관성과 무결성 유지

      -5 데이터의 보안 보장

      -6 응용 개발 시간 단축 및 편리성 증대

      -7 표준화 및 전체 데이터 요구의 조정

   2) 단점

      -1 비용이 증대

      -2 복잡한 백업과 회복

      -3 중앙 집중 관리로 인한 취약점 존재 -> 신뢰성과 가용성을 저해

    3) 여러 단점에도 불구하고 장점이 더 많기 때문에 DBMS 이용

5. DBMS 발전 과정

   1) 네트워크 DBMS : 그래프 형태로 구성

   2) 계층 DBMS : 트리 형태로 구성

   3) 관계 DBMS : 장점 - 테이블 형태로 모델이 간단하여 이해하기 쉬움

                                       자신이 원하는 것만 명시

                                       데이터가 어디에 있는지, 어떻게 접근해야 하는지 결정

   4) 객체지향 DBMS

   5) 객체관계 DBMS

   6) XML DBMS

   7) NoSQL DBMS : 비정형 데이터 저장 및 처리에 대한 요구 증가로 개발

      -1 관계형 모델을 사용하지 않으며 테이블 간의 조인 기능 없음

      -2 직접 프로그래밍을 하는 등 비sql 인터페이스를 통한 데이터 액세스

      -3 여러 대의 데이터베이스 서버를 묶어서 하나의 데이터베이스를 구성

      -4 관계 데이터베이스에서 지원하는 데이터 처리 완결성 보장하지 않음

      -5 데이터의 스키마와 속성들을 다양하게 수용

      -6 데이터베이스의 중단 없는 서비스와 자동 복구 기능 지원

      -7 다수가 open source로 제공

      -8 확장성, 가용성, 높은 성능

   8) NewSQL DBMS

      -1 정형 데이터를 처리하는 관계 DBMS 유지하면서 비정형 데이터를 처리하기 위한 NoSQL을 추가로 도입하는 부담을

          줄이기 위해 등장

     -2 안정성과 일관성을 유지하면서도 ㄴ비을 이용해 다양하고 복잡한 데이터 처리를 편리하게 요청할 수 있음

      -3 관계 DBMS의 장점과 NoSQL의 확장성 및 유연성을 모두 지원

6. 데이터베이스 사용자

   1) 데이터베이스 관리자 (DBA)

      -1 데이터베이스 구성 요소 성정

      -2 데이터베이스 스키마 정의

      -3 물리적 저장 구조와 접근 방법 결정

      -4 무결성 유지를 우한 제약조건 정의

      -5 보안 및 접근 권한 정책 결정

      -6 백업 및 회복 기법 정의

      -7 시스템 데이터베이스 관리 

      -8 시스템 성능 감시 및 성능 분석

      -9 데이터베이스 재구성

   2) 최종 사용자

      -1 데이터를 조작하기 위해 데이터베이스에 접근하는 사람

      -2 캐주얼 사용자 : DML 이용, 검색정도 할줄 아는 사람

      -3 초보 사용자 : 메뉴나 GUI 이용

   3) 응용 프로그래머

      -1 C, Java 등 프로그래밍 언어와 DML 이용

1. 보험 개요

   1) 보험 종류

      -1 생명보험

         (a) 상부상조 정신을 바탕으로 출생 및 사망 등의 불의의 사고로 인한 경제적 손실을 보전하기 위한 준비제도

               (생명보험협회)

      -2 손해보험

         (a) 우연한 사건으로 발생하는 재산상의 손해를 보상하여, 경제생활의 불안정을 제거 또는 경감해주는 상품

   2) 계약의 체결

      -1 기본용어

         (a) 보험료  :  보험계약자가 보험회사에 납부

         (b) 보험금  :  보험회사가 보험계약자에게 지급

         (c) 계약자  :  보험계약을 체결하고 보험료를 지급할 의무가 있는 자

         (d) 피보험자  :  보험사고가 발생하였을 때에 보험금을 지급받을 자 (손해보험),

                                  생명과 신체가 보험에 가입된 자연인(생명보험)

         (e) 수익자  :  보험금을 지급받을 자

      -2 계약체결 과정

         (a) 대체로 보험계약자가 청약서를 작성하여 보험설계사나 보험대리점에 제출

         (b) 이에 대하여 보험회사가 승낙을 함으로써 계약이 체결

         (c) 이후 보험증권을 교부

2. 언더라이팅

   1) 언더라이팅 개요

      -1 언더라이팅(계약심사) 의미

         (a) 협의  :  보험 회사의 위험 선택업무 즉, 위험평가의 체계회된 기법

         (b) 광의  :  보험계약의 모집과정부터 계약인수 및 처리, 손해사정 및 보험지급까지의 모든 과정의 체계화된 기법

     -2 언더라이터  :  언더리이팅하는 업무 담당자 또는 보험업자

      -3 역선택

         (a) 보험가입자  :  미래 위험 발생 가능성이 있거나 그 정도가 높은 사람 또는 물건 등

         (b) 손해 발생  :  보험 상품을 만들 때 정해진 보험료보다 보험금이 더 많은 경우

         (c) 역선택  :  보험 계약 전 계산된 위험보다 높은 집단이 가입하여 피보험 단체의 사고발생확률을 증가시키는 것

      -4 인공지능 활용 포인트

         (a) 계약심사 과정의 비용절감

         (b) 계약 심사 과정의 신속화

         (c) 계약심사 정확도 향상

         (d) 역선택 탐지

        -->  인공지능을 활용한 엉더라이팅 자동화

A생보사 : 자동 언더라이팅으로 자동화, 고객으로부터의 서류 제출과 정보 수집 절차 간소화

B생보사 : 인공지능과 가입심사 규칙 시스템 결합

C생보사 : 청약서 이미지와 영업, 계약 등의 단계에서 수집된 정보로 자동 승낙

D생보사 : 자연어 학습 기반의 머신러닝 언더라이팅 자동화 시스템 구축 특허 획득 

      -5 D생보사의 인공지능 활용 예시

         (a) 데이터 수집 : 보험설계사가 질문하고 고객이 답변한 사전 질문서, 고객의 연령, 직업, 과거 심사정보,

                                     보험 가입이력

         (b) 데이터 전처리 : 질문서의 비정형 텍스트 벡터화 , 과거 심사정보 벡터화, 보험 가입이력 벡터화 

         (c) 표준 미달 가능성, 승인 거절 가능성 계산 

         (d) 자동 심사결과 영향도 분석 (변수 중요도)

   2) 서비스 구현 예시

      -1 서비스 구현 기획

         (a) 서비스 정의 : 보험 계약체결 후 인수 심사를 위한 지표(Score) 생성

         (b) 데이터셋 : 고객정보, 가입정보, 모집설계사 정보, 챗봇 설문지

         (d) 데이터셋 수집 : 내부 데이터 

         (e) 데이터 예제

             1. 계약자 및 피보험자 정보

             2. 주보험 상품명, 보험기간, 납입기간, 납입주기, 납입보험료, 납입방법

             3. 모집인명, 모집인코드, 모집인 입사일자, 모집인 근속년수

             4. 심사점

      -2 서비스 구현 기술 

         (a) 저장 (스토리지 / 데이터 레이크)

         (b) 빅데이터 및 분석 

         (c) 머신러닝 프로그래밍 언어

         (d) 머신러닝 프레임워크, 라이브러리 

         (e) 머신러닝 플랫폼 서비스

         (f) 데이터 시각화

   3) 인공지능 활용의 한계

      -1 프로파일링 대응권

         (a) 소비자가 보험사 등에 자동화된 언더라이팅 결과, 신용평가 결과, 대출 거절 등에 관해 설명을 요구하고 이의를

               제기할 수 있는 제도

      -2 인공지능 모델의 해석과 한계

         (b)  거절된 계약에 대해 사유 요청 시 안내나 설명이 불가하거나 어려움

      -3 동의 데이터 부족

1. React Native란

페이스북에서 개발한 크로스 플랫폼 개발 프레임워크로, 웹과 서버에서 널리 사용되는 javascript를 언어로 사용한다. 웹 프론트엔드 개발에 대표적인 라이브러리인 react를 기반으로 개발된 프레임워크 이기에 react를 경험해본 개발자거나 웹 개발에 익숙한 개발자는 react native를 사용하면 비교적 쉽게 모바일 앱을 만들 수 있다.

안드로이드, ios, 웹, UWP용 애플리케이션을 개발하기 위해 사용되며, 개발자들이 네이티브 플랫폼 기능과 더불어 리액트 사용할 수 있게 한다. 번역기 같은 역할을 하는 것이다.

react native는 다양한 장점을 가지고 있어 많은 기업에서 사용하고 있다. 대표적으로 페이스북, 인스타그램, 에어비앤비 등이 있다.

2. React Native를 사용하는 이유

   1) 효율적인 개발 및 관리

react native는 단일 코드 베이스 (앱을 만들기 위해 필요한 소스 코드의 모임)로 ios와 android 앱을 동시에 개발할 수 있어 개발 속도를 높일 뿐만 아니라, 효과적으로 관리하기에 적합하다.

native 앱으로 ios와 안드로이드에서 앱을 개발할 경우 두 개의 코드 베이스를 관리해야 하는데, react native의 단일 코드 베이스로 관리하면 관리해야 하는 코드의 양은 절반으로 줄어들기 때문에, 개발 속도와 업무 효율성 모두 높아진다. 또한 두 플랫폼에 대한 별도의 개발팀이 필요하지 않기 때문에 인력 및 운영 비용을 절감할 수 있어 프로젝트를 진행하는 기업 입장에서는 효율적인 개발 및 관리가 가능하다

   2) 뛰어난 성능 제공

react native로 개발된 앱은 네이티브 앱과 유사한 성능을 제공한다. 자바스크립트 코드를 네이티브 코드로 변환하는 역할을 하는 모듈을 통해 빠른 성능을 지원한다. 사용자는 빠른 반응 속도와 부드러운 애니메이션을 경험하며 앱을 사용할 수 있다.

   3) 개발 커뮤니티 활성화

개발자들이 개발할 때 구글에서 검색을 하는 시간이 가장 많다는 밈이 있을 정도로 개발 시 필요한 기술에 대해 검색해서 찾고, 난관에 부딪힐 때 검색으로 해결하는 경우가 많다. 이미 많은 서비스에서 이용되고 있는 react native는 커뮤니티가 활성화되어있어 개발을 할 때 참고할 자료가 풍부하다. 또한 react native 생태계에서는 다양한 라이브러리와 플러그인이 개발되어 있기에 원하는 특정 기능을 라이브러리에서 찾는다면 직접 개발하지 않고, 다른 개발자가 만들어 둔 것을 참조하여 사용하기만 하면 된다.

   4) OTA(Over-The-Air) 업데이트

ota 업데이트를 사용해 업데이트를 빠르게 진행할 수 있다. 이는 버그 수정이나 디자인 변경을 할 때 유용하게 사용할 수 있다. 일반적으로 네이티브 앱의 경우 간단한 기능이나 텍스트 등을 수정하려면 스토어에 등록한 후, 사용자 업데이트가 가능하다. 앱의 수정은 금방 할지라도 스토어에서 검수 과정이 24시간이 소요되기 때문에 사용자에게 업데이트를 위해 전달되는 체감 시간은 오래 걸린다. 이에 비해 react native 앱은 ota 업데이트를 활용하기 때문에 빠른 업데이트가 가능하다. ota 업데이트는 앱 업데이트를 위해 스토어를 거치지 않고 원격 서버를 통해 업데이트를 하는 기능을 말하는데, 이를 이용해서 업데이트를 하면 사용자가 앱을 다시 시작하기만 해도 앱 업데이트가 가능하다. 스토어에서의 검수 과정이 생략되기 때문에 기능을 추가하거나 버그 수정이나 디자인 변경 정도를 할 때는 ota 업데이트를 통해 빠르게 배포할 수 있다.단 큰 변화를 위한 업데이트가 필요한 경우에는 네이티브 앱과 동일하게 스토어에 올린 후 검수 과정을 거쳐야 한다.

3. 크로스 플랫폼 앱이란

   1) 크로스 플랫폼 앱은 하나의 소스 코드로 안드로이드, iOS에서 똑같이 작동하는 앱을 의미하며, 네이티브 앱과는 대조되는 개념이다

   2) 네이티브앱은 각 운영 체제에 맞춰 따로 개발 및 운영이 필요하다. 어떻게 보면 당연한게 각 앱마다 사용하는 프로그래밍 언어도 다르고 개발하는 플랫폼도 다를 것이기 때문이다. 

이런 한계점을 개선하고자 생긴게 크로스 플랫폼 앱이다. 크로스 플랫폼 앱에는 대표적으로 React native, Flutter가 있다.

4. React  VS  React Native

5. 단점

   1) 러닝 커브

기존에 os 네이티브 앱을 개발하던 개발자는 새로운 javascript를 학습해야 한다. 그리고 리액트를 접하지 않았던 개발자들은 새로운 개념인 jsx의 리액트 고유 방식을 이해하고 리액트가 사용하는 props, state등의 개발 방식을 이해해야 한다

   2) 네이티브보다 성능이 떨어진다

리액트 네이티브는 네이티브 브릿지를 사용하여 네이티브 스레드를 연결시켜 동작하는 하이브리드앱이기 때문에 네이티브 개발 방식보다는 당연하게 성능이 떨어진다. 일반적인 애플리케이션을 만단다고 한다면 문제는 없지만 애니메이션 60프레임 이상을 사용하거나 자바스크립트 스레드애서 5ms보다 시간이 걸리는 처리를 하게 된다면 성능 저하를 경함할 수 있다

1. Generator

2. 클래스를 상속했을 때 메서드 실행 방식

3. GIL과 그로인한 성능 문제

4. GC 작동 방식

4. Celery

5. pypy가 CPython보다 빠른 이유

6. 메모리 누수가 발생할 수 있는 경우

7. Duck Typing

8. Timsort  :  python의 내부 sort

1. 자료구조란 무엇인가

2. 대표적인 자료구조는 어떤 것들이 있는가

3. 리스트

4. 큐

4-1 우선순위 큐는 무엇인가

5. 스택

5-1 스택은 어떤 경우에 주로 사용하는가

5-2 큐를 스택으로 구현하는 방법을 설명하라

6. 링크드 리스트

7. 해쉬 테이블

7-1 해쉬 테이블을 이용할 때 해쉬 충돌이 발생할 겨우 어떻게 처리할 수 있는가

8. 트리

8-1 이진 탐색 트리, 포화 이진 트리, 완전 이진 트리의 차이점은 무엇인가

8-2 이진 탐색 트리에서 발생할 수 있는 문제는 무엇이고, 이를 보완할 수 있는 방법이 있다면 무엇인가

9. 힙

10. 그래프

10-1 BFS와 DFS의 차이점은 무엇인가

11. 배열과 연결 리스트의 차이점을 설명하라

12. 단순 연결 리스트를 역순으로 출력하는 방법을 설명하라

13. 트리와 그래프의 차이점은 무엇인가

1. 리액트는 라이브러리인가 프레임워크인가

2. virtural DOM에 대해서 아는가

3. 리액트의 랜더링에 대해 아닌그

4. 리액트 파이버에 대해 아는가

5. 리액트 파이버 트리

6. 리액트 파이버와 DOM, Virtural DOM의 관계

7. 렌더 단계와 커밋 단계에 대해 아는가

8. React에서 함수 컴포넌트와 클래스 컴포넌트의 차이

9. 리액트에서 함수형 컴포넌트라고 부르지 않고 함수 컴포너트라고 부르는 이유가 무엇인가

10. props와 state의 차이

11. props가컴포넌트 간에 전달받는 것이라고 했는데 자식에서 부모로도 전달할 수 있는가

12. flux에 대해 아는가

13. 리덕스에 대해 아는가

14. 리덕스의 기본 원칙은

15. 리액트에서 state의 불변성을 유지하라는 말이 있는데 이에 대해 설명하라

16. 리듀서 내부에서 불변성을 지키는 이유는? 전개 연산자의 단점을 해결할 수 있는 방법은 무엇인가

17. 리액트 사용시에 부수효과로 인해 생기는 문제점이 있다면

18. 컴포넌트의 라이프 사이클 메서드

19. hooks의 종류

20. useMemo와 useCallback의 차이를 아는가

21. 리액트에서 setState는 비동기 동작인가 동기 동작인가

22. setState가 비동기 동작을 취했을 때 얻을 수 있는 이점은 무엇인가

23. useLayoutEffect는 무엇인가

24. 리액트의 성능 개선 방법에 대해 설명하라

25. 컴포넌트에서 이벤트를 실행시키기 위해서는 어떻게 핸들링 해야 하는가

26. spa가 무엇인가

27. ssr이 무엇인가

28. seo가 무엇인가

29. 서버 사이드 렌더링을 지원하기 위한 리액트 api를 알고 있는가

30. 하이드레이션에 대해 알고 있는가

31. next의 렌더링 수행 방식

32. next를 쓴 이유

33. next를 구성하는 기본 설정 파일에 대해 알고 있는가

34. 사전 렌더링을 위해 사용해본 함수가 있는가

35. suspense가 무엇인가. suspense로 가능한 것은 어떤 것들이 있는가

36. 웹 성능 최적화

37. lcp가 무엇인가

38. fcp가 무엇인가

39. controlled pattern에 대해 아는가

40. uncontrolled pattern에 대해 아는가

1. React란

React(리액트)는 전 세계에서 Node.js 다음으로 인기 있는 웹 개발 기술이다. 2023년 기준으로 전 세계 웹 개발자의 40.58%가 리액트를 사용하고 있다. 페이스북, 인스타그램은 무론 에어비앤비, 넷플릭스, 트위터 등 수많은 기업이 채택했다.

React는 2013년 메타(전 페이스북)가 오픈소스로 공개한 프론트엔드 JavaScript 라이브러리이다. 라이브러리는 특정 기능을 수행하는 코드들의 집합으로 개발 시 필요한 기능을 직접 호출해서 사용 할 수 있는데, 리액트는 복잡한 U도 '컴포넌트'라는 작은 단위 기반으로 단순하게 개발할 수 있고 다른 라이브러리나 프레임워크도 함께 활용하기 쉽다. 이런 장점 덕분에 프론트엔드 개발 분야에서 대세가 되었다.

2. React 특징

리액트는 데이터가 변할 때마다 화면을 새로 띄우는 대신, 필요한 곳만 업데이트해주는 형식이다.

'가상 DOM(Document Object Model)' 이라는 개념이 이를 가능케 한다. DOM은 HTML 문서를 브라우저가 이해할 수 있도록 만든 자료구조다. DOM에 변화가 생기면 브라우저는 이 변화를 반영하기 위해 계속 연산을 하게 되는데, 변화가 많으면 그만큼 연산량도 많아지므로 전체적으로 효율이 떨어진다.

가상 DOM은 실제 DOM보다 가벼운 복제품이다. 데이터에 변화가 생겼을 때 브라우저와 연결된 실제 DOM에 입력하는 대신 가상 DOM에 먼저 입력하고 가상 DOM과 기존 DOM을 비교해 최소한의 부분만 찾아 업데이트하는 원리다.

덕분에 빠른 로딩 속도와 반응성 높은 UI를 구현할 수 있게 되었다. 데이터 규모가 클수록, 데이터 변경이 많을수록 리액트는 더 큰 힘을 발휘한다.

3. 장점

   1) 개발 생산성이 높다

리액트는 '컴포넌트'라는 작은 코드조각을 기본 단위로 UI를 구성하는데, 화면에 구성되는 요소들을 하나하나 개발하지 않고 반복되는 것들은 컴포턴트를 재사용해 생산성을 높일 수 있다. 레고를 조립할 때 단순한 블록으로 수많은 형태를 완성하는 형식과 비슷하다. 오류가 생겼을 때도 전체 페이지를 수정하는 대신 해당 컴포넌트만 수정하면 되기 때문에 해결하기 쉽다

   2) 입문자도 쉽게 흥미를 느낄 수 있다

프론트엔드 개발은 보이는 영역의 웹 화면을 설계하기 때문에 입문 개발자도 쉽게 흥미를 느낄 수 있다. 전체적인 레이아웃, 배치, 디자인, 고객과의 상호작용까지 직접 구현할 수 있기 때문에 서비스에 기여하는 바가 명확하게 눈에 보인다.

   3) 사용하는 기업이 많다

전 세계 65만 개 프론트엔드 채용 공고를 분석한 결과, 리액트 채용 공고는 약 35만 5000개 정도로 압도적인 1위를 차지했다. 국내 기업만을 분석한 통계는 없지만 쿠팡, 11번가, 티몬, 오피지지, 카카오페이 등 수많은 기업에서 프론트엔드 개발에 리액트를 사용하고 있다.

   4) Flux와 Redux

리액트는 Flux 아키텍처와 Redux를 통해 데이터를 체계적으로 관리할 수 있다. Redux는 단일 상태 트리를 사용하여 애플리케이션의 전체 상태를 관리하고, Flux아키텍처는 데이터 플로우를 단방향으로 유지한다. 데이터를 한 곳에서 관리하기 문에 실수도 줄이고, 데이터 흐름도 쉽게볼 수 있다.

4. React와 함께 학습하면 좋은 언어와 프레임워크

   1) TypeScript  :  오류를 줄이고 개발 생산성 향상

타입스크립트는 JavaScript의 확장버전으로, 정적 타입 시스템을 제공한다. 정적 타입 시스템은 코드 작성 중 발생할 수 있는 오류를 줄이고 유지 보수를 쉽게 만든다.

타입스크립트를 함께 사용하면 코드의 가독성도 높일 수 있다. 코드의 의도를 보다 명확하게 표현할 수 있기 때문에 코드의 구조를 변경하는 작업도 더욱 수월하고 빠르게 이뤄진다.

   2) Nest,js  :  리액트 문법 그대로 리액트의 단점을 보완

리액트 CSR(Client Side Rendering)방식으로 동작한다. CSR은 서버에서 데이터를 보내 브라우저에서 페이지를 만드는 방식이다. CSR은 기본 구조 상 SEO(검색 엔진 최적화)에서 불리하다는 단점ㅁ이 있는데, 이를 보완하는 것이 Nes.js이다.

Nest.js는 리액트 문법을 그대로 사용하면서 SSR(Server Side Rendering) 방식으로 작동하는 프레임워크이다. SSR은 서버가 페이지를 만들어 브라우저에게 전달한다. 검색엔진이 이미 서버에서 만들어진 정보들을 가져올 수 있기 때문에 SEO에 유리하다. 이외에도 리액트 개발을 보다 효율적으로 만들어주는 다양한 장점을 지니고 있다.

Flutter는 Google에서 개발 및 지원하는 오픈소스 프레임워크다.

프론트엔드 & 풀스택 개발자는 Flutter를 사용해 다수의 플랫폼에 대한 애플리케이션의 사용자 인터페이스(UI)를 단일 코드 베이스로 구축할 수 있도록 지원한다.

2018년 출시 이후 Flutter는 iOS, Android, Web, MacOS, Linux 여섯가지 플랫폼에 대한 애플리케이션 개발을 지원한다.

1. Flutter의 주요 특징

1) 프러터는 모든 사람이 아름답고, 좋은 성능을 가진 모바일 앱을 만들 수 있도록 제공하는 모바일 SDK이며 Dart로 구성되었다.

2) Dart는 구글이 만든 언어로 자바스크립트로 컴파일할 수 있다

3) Dart는 빠르며, 엄격한 형식을 지원하고 배우기 쉽다

4) 플러터는 네이티브 디바이스 코드로 컴파일되므로 다른 크로스 플랫폼 기술보다 성능이 뛰어나다

5) 또한 Dart의 JIT, 플러터의 리로드 덕분에 최상의 개발자 경험을 제공한다

6) 플러터는 훌륭한 성능의 크로스 플랫폼 앱을 빨리 만들어야 하는 사람에게 적합하다. 하지만 두 개의 네이티브 팀을 이미 보유한 큰 회사는 플러터가 좋은 선택이 아닐 수 있다.

7) 플러터의 모든 것은 위젯이다

8) 여러 작은 위젯을 조립해 위젯 트리를 완성하며 UI를 만든다

9) 위젯은 크게 상태가 없는 위젯과 상태가 있는 위젯으로 분류된다

10) 플러터는 위젯 생명주기 메서드, 특별한 State 객체 등 상태 관리 도구를 제공한다

2. Flutter 주요 개념

1) 플러터는 리액티브다

2) 모든 것은 위젯이다

3) state 객체는 오래 살아남으며 종종 재사용된다

4) 위젯의 제약은 부고가 서술한

3. Flutter 장점

   1) 통합 개발 환경 지원

Flutter는 다양한 Editor(Android Studio, VS Code 등등)를 사용하여 빌드가 가능하다. Android Studio는 Flutter Inspector와 Flutter Outline이라는 개발 도구를 추가적으로 지원해준다. VS code 에서는 간단하게 Extension 으로 Flutter를 설치하여 Flutter를 사용할 수 있다.

   2) 성능 문제 해결

기존 React Native 혹은 Hybrid App의 경우 네이티브 브릿지를 통한 통신이 불가피했다. 하지만 Flutter는 직접 컴파일되서 Render를 직접 하기때문에 성능이 빠르다. 애니메이션 속도가 60프레임은 가뿐히 넘어서는 것이 기존 크로스 플랫폼시장의 주류였던 React Native와 Flutter를 비교하는 많은 글들에서 Flutter를 내세우는 부분이다.

   3) 머티리얼 디자인과 쿠퍼티노

Flutter는 Androd와 iOS의 대표 디자인 가이드를 기본적으로 제공한다. 구글의 머티리얼 디자인(Material Design)의 홈페이지에는 이미 Flutter가 포함되어 있고 가이드만 제공하는 것 뿐만아니라 Flutter 프로젝트에 바로 추가하여 사용할 수 있는 패키지도 제공한다. 안드로이드와 iOS에서 같은 머티리얼 디자인을 사용하더라도 플랫폼에 따라 다르게 출력되는 부분을 각각 디자인 가이드에 맞게 화면을 그린다. iOS앱을 개발하는 경우 iOS특유의 디자인 시스템인 쿠퍼티노(Cupertino) 위젯을 제공한다. 그렇기에 선택의 폭이 정해져 있기 때문에 어떤 UI 라이브러리를 사용할 것인지 고민 할 필요가 없습니다만 이건 장점이자 단점이 될수도 있다.

   4) Dart를 사용하지만 Native 코드도 사용
앞서 Dart를 사용한다고 했지만 결국엔 크로스 플랫폼이기에 해당 OS에 최적화된 앱을 만들려면 Native 코드를 사용할수밖에 없고 Dart와 섞어서 사용한다. 즉, Dart만 사용하는것이 아니라 Android면 Kotlin, iOS면 Swift도 사용한다. 이는 기존의 Native 코드를 사용한 개발자라면 장점이 된다.

4. 단점

   1) Native API를 Dart에서 직접 호출 불가하다.
특별히 심하게 문제가 되진 않지만 외부 플러그인을 써야한다.

   2) Code Pushing
코드를 고치려면 새 버전을 배포해야 한다.
React Native, Cordova, Ionic 에선 이미 지원 중 이다.

   3) Air BNB Lotti 사용 불가하다.
Android, iOS, React-Native만 지원하고 Flutter는 지원하지 않는다.

   4) C/C++ 라이브러리 호출이 안된다.
NDK C/C++ 라이브러리 호출이 Dart에서 안된다. 외부 플러그인을 써야하고, 원하는 플러그인이 없다면 만들어야 하는 번거로움이 있다.

   5) 지원되는 플러그인이 부족하다.
어플을 생성할 때, Webview, Map 등 플러그인은 필요하다. 하지만 Flutter의 이러한 플러그인들은 전부 0.4, 0.3 등등 1.0을 넘는 버전을 보기가 힘들다. 따라서 지속적으로 업데이트가 되고있고, 업데이트가 될때마다 다시 붙이고 테스트해보는 것은 번거로운 일이 될 것이다.

   6) 아직까진 국내에 개발관련 자료가 많이 없다.
Android, iOS Native는 나온지 오래되서 자료가 많다보니 문제해결이 쉽지만, 국내엔 아직까진 자료가 많다고 할수가 없어 이슈 상황 발생시 자료 찾기가 어렵다. 또한, Flutter 개발자들도 그렇게 많은 편이 아니기에 도움을 구하기도 어느정도 힘이 다.

Flutter의 상태관리의 종류에는

1. StateFul

2. ValueListenable

3. Getx

4. Provider

5. Bloc

6. Cubit

7. Riverpod

8. Mobx

Bloc은 플러터의 상태관리를 도와주는 패키지로써 bloc 외에도 상태관리 패키지를 사용하지 않는 것까지 포함해서 8정도가 있다.

   1) 상태 (state)

앱 내부의 데이터라고 할 수 있다. 유저가 어떤 행동을 취했을 때 내부에서 변하는 데이터를 상태라고 한다.

   2) 상태관리 (state management)

간단한 to do 앱의 경우 미들웨어가 필요 없을테지만, 앱의 덩어리가 조금 더 커지면 setSate만으로는 상태 관리하는데 어려움이 있을 것이다. 이 때문에 따로 상태를 관리할 수 있는 미들웨어 (여기선 bloc)이 필요하다.

1. bloc 패턴이란

bloc(Business LOgic Component)패턴은 상태 변화에 있어 UI와 Business Logic을 분리하는데 사용되는 디자인 패턴이다.

bloc은 "simple", "powerful", "testable"을 핵심가치로 개발되었다.

   1) simple  :  이해하기 쉽고, 다양한 수준의 개발자가 사용할 수 있게 하기 위해

   2) powerful  : 어플리케이션을 작은 단위의 컴포넌트로 나눠주어 멋지고 복잡한 애플리케이션 개발을 돕기 위해

   3) testable  :  어플리케이션의 모든 부분을 쉽게 테스트할 수 있게 하여 코드에 확신을 가지고 개발을 진행할 수 있게

                         하기 위해

2. Bloc을 사용하는 이유

   1) 뷰 영역과 비즈니스 영역을 쉽게 구분할 수 있다.

뷰 영역은 화면 UI부분을 뜻하며 사용자의 액션을 받아 이벤트를 발생시키는 영역을 말한다. 비즈니스 영역은 사용자의 입력에 따라 여러가지 기능(회원가입, 검색 등)을 수행하게 되는데 사용자들은 대부분 어떤 과정을 통해 기느을 수행하는지 알 필요 없다. 사용자의 요청을 빠르게 수행하기 위해 로직을 작성하게 되는 부분을 비즈니스 영역이라고 말한다.

뷰와 비즈니스 영역은 서로 상호작용하게 되어 결과를 도출해 주는 집합체가 하나의 서비스가 되는 것이다.

   2) 테스트하기 쉽고(TDD), 재사용을 가능하게 해 준다.

TDD 개발 방법론 적용 시 bloc적용은 특정 비즈니스 로직 부분만 유닛 테스트  ->  리펙토링 반복 개발을 수월하게 해준다

   3) 이벤트 트레킹을 통합적으로 관리할 수 있다.

BlocObserver라는 게 있어서 이를 통하여 이벤트 트레킹을 통합적으로 관리할 수 있게 된다. 

   4) 통일된 코드 베이스로 일할 수 있다.

룰이 정해져 있기 때문에 개발자들끼리동일한 개발 패턴을 다르게 되어있다. 때문에 업무 효율이 올라간다.

   5) UI와 Business Logic을 분리함으로서 유지보수하기 좋은 구조로 설계할 수 있다.

UI입장에서는 데이터가 처리되는 과정을 알 필요가 없다. 단지 필요한 데이터를 요청하고 그 결과만을 가지고서 화면에 맞게 표시해주는 역할에만 충실하면 된다.

하지만  UI처리 코드와 Business Logic이 같이 섞여 있는 코드라면 복잡성은 높아지고 유지보수도 힘들어진다. 추가로 사이드 이팩트 오류가 발생할 확률도 높아진다.

   6) 분리된 코드는 상태관리되기 때문에 UI에 있어 변경된 부분만 다시 그려주거나 상태만 변경해줌으로써 앱은 빠른 성능이 보장된다

이렇게 상태관리가 되어 있지 않은 앱은 불필요한 UI 다시 그리기 처리, 상태체크 등 작업이 발생됨으로써 그만큼 좋은 성능을 낼 순 없다

1. 데이터베이스

   1) 여러 사용자 및 프로그램에서 사용하기 위해 저장 및 관리하는 데이터 집합

   2) 구성요소

      -1 개체(entity, 엔터티)  :  데이터로 표현하려는 대상

      -2 속성(attribute)  :  개체의 특성 및 상태

      -3 관계(relationship)  :  개체 간 관계

2. 관계형 데이터베이스

   1) 테이블을 이용해 데이터의 종속성과 구조를 나타내는 데이터베이스

   2) 용어

      -1 스키마(schema)  :  데이터의 구조와 표현 방식, 제약 조건 등을 정의해 데이터베이스의 전체적인 구조를 나타냄

      -2 릴레이션(relation)  :  데이터베이스에서 데이터의 개념적 모델

      -3 테이블(table)  :  릴레이션을 실제로 구현한 개체로, 행과 열로 관계형 데이터베이스를 구성함

      -4 튜플(tuple)  :  테이블의 행에 해당하는 데이터 묶음으로, 레코드라고도 함

      -5 속성(attribute)  :  테이블의 열에 해당하고 이름과 타입을 가짐, 필드라고도 함

3. NoSQL 데이터베이스

   1) 비관계형 데이터베이스로, 다양한 형태의 데이터를 저장함

   2) 대용량 데이터 조회 시 속도가 빠르고 수평적 확장성이 좋음

4. 키

   1) 데이터베이스에서 튜플을 구분하기 위한 속성 또는 속성의 집합

   2) 종류

      -1 슈퍼 키  :  튜플 식별이 가능하여 유일성은 만족하나 최소성은 만족하지 않아도 됨

      -2 후보 키  :  튜플 식별이 가능하며 유일성과 최소성을 만족해야 함

      -3 기본 키  :  후보 키 중 메인이 되는 키로 NULL 값을 가지면 안됨

      -4 대체 키  :  후보 키 중 기본 키를 제외한 키

      -5 외래 키  :  다른 테이블의 기본 키를 참조하는 키

5. 무결성

   1) 데이터베이스의 데이터와 현실의 데이터가 일치하는 정확성과 데이터의 일관성을 의미함

   2) 종류

      -1 개체 무결성  :  모든 테이블이 NULL 값이 아닌 기본 키를 가져야 함

      -2 도메인 무결성  :  테이블의 속성 값은 도메인에 속해야 함

      -3 참조 무결성  :  외래키의 값은 참조하는 테이블의 기본 키 값과 동일하거나 NULL이어야 함

6. 인덱스

   1) 튜플 검색 성능을 높이기 위해 속성 값과 튜플이 저장된 주소를 저장하는 것

   2) 장점  :  정렬된 상태를 유지해 데이터 검색 속도를 향상시킴

   3) 단점

      -1 인덱스 테이블을 저장하기 위한 저장 공간이 따로 필요하고 데이터 추가/수정/삭제 시 속도가 느림

      -2 삭제 연산 시 인덱스 테이블에는 값이 남아서 불필요한 데이터가 남게 됨

   4) 종류

      -1 해시 테이블 익덱스  :  등호 연산만 가능

      -2 B +- 트리 인덱스  :  비교 연산 가능

7. 트랜잭션

   1) 데이터베이스의 상태를 바꾸기 위해 수행하는 작업의 단위

   2) 특성  :  원자성, 일관성, 독립성, 연속성

   3) TCL  :  트랜잭션을 제어하는 데 사용하는 명령어의 집합

      -1 COMMIT  :  트랜잭션의 정상 종료, 데이터베이스에 변경 사항 반영

      -2 ROLLBACK  :  트랜잭션의 비정상 종료, 데이터베이스를 이전 상태로 되돌림

      -3 SAVEPOINT  :  트랜잭션의 특정 지점 지정

8. 락

   1) 트랜잭션이 처리되는 순서를 보장해 데이터베이스의 무결성을 유지하려고 사용함

   2) 종류

      -1 공유 락  :  데이터를 읽는 락, 여러 공유 락이 동시 접근 가능

      -2 베타 락  :  데이터를 수정하는 락, 하나의 베타 락이 처리 중일 떄 다른 베타 락이 동시 접근 불가능

9. 트랜잭션의 교착 상태

   1) 트랜잭션이 자신이 처리 중인 데이터에 대해 락을 가진 상태에서 다른 트랜잭션이 처리 중인 데이터에 대해 락을 요청하면서 무한 대기 상태에 빠진 현상

   2) 해결 방법

      -1 예방 기법  :  트랜잭션 처리 전 필요한 데이터에 대해 미리 락을 획득함

      -2 회피 기법  :  트랜잭션이 들어온 순서에 따라 락을 획득하거나 트랜잭션이 종료되는 방식으로, 

                               wait-die와 wound-wait가 있음

10. 이상

   1) 트랜잭션 처리 중 속성 간 종속이나 데이터 중복 때문에 발생하는 문제

   2) 종류

      -1 삽입 이상  :  의도하지 않은 데이터가 삽입됨

      -2 갱신 이상  :  일부 튜플만 갱신되어 데이터 모순 발생

      -3 삭제 이상  :  의도하지 않은 데이터가 삭제됨

11. 정규화

   1) 데이터베이스의 이상 현상을 해결하기 위해 테이블을 분해하는 것

   2) 정규화를 필요 이상으로 진행하면 테이블이 많아져 연산 시간이 증가할 수 있음

   3) 정규화 단계

12. 조인

   1) 여러 테이블을 합쳐 원하는 데이터를 얻으려는 작업

   2) 내부 조인(INNER JOIN)  :  2개 이상의 테이블에서 공통되는 속성을 가진 데이터를 검색하기 위한 연산

   3) 외부 조인(OUTER JOIN)  :  테이블에서 조인 조건에 해당하는 속성 값이 없는 데이터까지 모두 조회하는 연산

      -1 왼쪽 외부 조인(LEFT OUTER JOIN)  :  왼쪽 테이블의 모든 데이터가 결과 테이블에 조회

      -2 오른쪽 외부 조인(RIGHT OUTER JOIN)  :  오른쪽 테이블의 모든 데이터가 결과 테이블에 조회

      -3 완전 외부 조인(FULL OUTER JOIN) :  양쪽 테이블에서 조건을 만족하지 않는 데이터까지 모두 포함해 결과

                                                                       테이블에 조회