작은 방

• 웹 개발에서 WAS는 클라이언트의 요청을 처리하고 동적인 웹 콘텐츠를 생성하는 핵심 컴포넌트이다.
• 프론트엔드와 백엔드 간의 원활한 통신을 가능하게 하며, 웹 애플리케이션의 성능, 보안, 확장성을 좌우하는 중요한 요소이다.

WAS

• 웹 애플리케이션을 실행하고 관리하는 서버 소프트웨어
• 클라이언트로부터 HTTP 요청을 받아 처리하고, 동적인 웹 페이지나 데이터를 생성하여 응답을 반환한다.
• WAS는 주로 백엔드 로직을 처리하며, 데이터베이스와의 상호작용, 인증 및 권한 관리, 비즈니스 로직 실행 등을 담당한다.

WAS와 Web Server의 차이

• 웹 서버 : 주로 정적인 콘텐츠들을 제공하며, HTTP 요청을 처리한다.
  • 대표적으로 Apache, Nginx 등이 존재한다.
• 웹 애플리케이션 서버 : 동적인 콘텐츠를 생성하고, 복잡한 비즈니스 로직을 처리한다.
  • 대표적으로 Tomcat, Jetty, WildFly 등이 있다.

⇒ WAS는 웹 서버와 함께 사용되는 경우가 많으며 웹 서버가 정적인 콘텐츠를 제공하고 WAS가 동적인 처리를 담당하여 효율적인 자원 관리를 가능하게 한다.

WAS의 주요 역할

1. 동적 콘텐츠 역할
   • 사용자 요청에 따라 동적으로 웹 페이지나 데이터를 생성하여 응답한다.
2. 비즈니스 로직 처리
   • 애플리케이션의 핵심 기능을 구현하는 로직을 실행한다.
3. 데이터베이스 연동
   • 데이터베이스와의 상호 작용을 관리하여 데이터를 조회, 삽입, 수정, 삭제한다.
4. 인증 및 권한 관리
   • 사용자 인증 및 권한 부여를 통해 보안을 유지
5. 세션 관리
   • 사용자 세션을 관리하여 상태 정보를 유지
6. 트랜잭션 관리
   • 데이터의 일관성을 유지하기 위해 트랜잭션 관리

WAS의 주요 기능

1. 로드 밸런싱
   • 여러 대의 서버에 요청을 분산시켜 서버 부하를 줄이고, 가용성을 높임
2. 클러스터링
   • 여러 대의 WAS 인스턴스를 클러스터로 구성하여 고가용성과 확장성을 제공
3. 캐싱
   • 자주 요청되는 데이터를 캐시에 저장하여 응답 속도 향상
4. 보안
   • SSL/TLS 지원, 인증 및 권한 관리, 데이터 암호화 등을 통해 보안을 강화
5. 모니터링 및 로깅
   • 애플리케이션의 성능을 모니터링하고, 로그를 기록하여 문제를 진단하고 해결
6. API 관리
   • RESTful API나 GraphQL API를 제공하여 프론트엔드와의 원활한 통신을 지원

프론트엔드와 WAS의 연동

• 프론트엔드 애플리케이션은 WAS와 API를 통해 데이터를 주고받으며, 사용자 인터페이스를 동적으로 업데이트한다.

1. API 설계
   • RESTful API 또는 GraphQL을 설계하여 프론트엔드와 백엔드 간의 통신 규약을 정의합니다.
2. HTTP 요청 처리
   • 프론트엔드에서 fetch 또는 axios 같은 라이브러리를 사용하여 WAS의 엔드포인트에 HTTP 요청을 보냅니다.
3. 데이터 포맷
   • 일반적으로 JSON 형식을 사용하여 데이터를 주고 받습니다.
4. 인증 및 권한
   • JWT나 OAuth를 사용하여 인증 및 권한을 관리합니다
5. 에러 핸들링
   • 프론트엔드에서 백엔드로부터의 에러 응답을 적절히 처리하여 사용자에게 알립니다.
6. CORS 설정
   • WAS에서 CORS를 설정하여 프론트엔드와의 교차 요청을 허용합니다.

결론

• WAS는 현대 웹 애플리케이션의 핵심 구성 요소로 프론트엔드와 백엔드 간의 원활한 통신을 지원하고, 애플리케이션의 성능과 보안을 책임집니다. 다양한 WAS가 존재하며, 프로젝트의 요구사항에 맞는 적절한 WAS를 선택하는 것이 중요합니다.
• WAS의 존재에 대해 잘 몰랐기 때문에 그 동안 서버라고 말하면 모두 웹 서버를 말하는 줄 알았는데 오히려 프론트와의 긴밀한 연결은 WAS와 이어지고 있다는 것을 깨달았습니다. 두 서버가 왜 다른 지 이해했고, WAS를 어떤 시각으로 바라보고 프론트에서 적절하게 사용해야 하는 지 알았습니다.

스타트업에서 MVP를 만드는 알바를 할 때 정해진 스택이 있었다.

TypeScript, Next.js, 그리고 Zustand.

그 당시 세 가지를 모두 처음 사용해본 터라 부랴부랴 검색해가며 공부와 개발을 병행했던 기억이 있다.

시키니까 일단 사용은 하는데... 사실 잘 이해하지 못하고 주도해주셨던 프론트 팀장님 말 듣고 사용하라는 데로 사용하기만 한 기억이 있다.

그래서 스타트업에 특화 된 어떤 장점이 있으니까 사용했을 거라는 생각이 들어 미리 좀 알아보고자 한다.

Zustand 바로가기

내가 생각하는 Zustand의 가장 큰 장점은 로고가 귀엽다 .. 다른 상태 관리 도구들은 너무 공대틱한 느낌이 심한데 갑자기 곰돌이가 있어서 큐티한 느낌이 난다.

홈페이지에 들어가봐도 큐티한 곰돌이 월페이퍼에 어떻게 코드를 작성하는 지 간단한 카운터 예시가 들어가 있다.

코드를 보고 어떻게 사용하는 지 한 번 분석해 봤다.

import { create } from 'zustand'

const useStore = create((set) => ({
  count: 1,
  inc: () => set((state) => ({ count: state.count + 1 })),
}))

function Counter() {
  const { count, inc } = useStore()
  return (
    <div>
      <span>{count}</span>
      <button onClick={inc}>one up</button>
    </div>
  )
}

zustand에서 create를 import합니다

그리고 useStore라는 함수를 만들어 create 전역 스토어를 설정합니다

기본 상태 count의 초기값을 1로 정의하고, inc 액션 함수를 정의합니다

set 함수를 사용하여 현재 상태인 1을 업데이트하네요

카운터 컴포넌트는 위에서 만든 useStore 함수를 호출해 count와 inc 함수를 가져오네요

그리고 그 상태인 count를 화면에 표시합니다

onClick에는 useStore에서 만든 inc 함수를 넣을 수 있네요

이것으로 간략하게 어떻게 Zustand가 돌아가는 지 이해 했습니다

Zustand는 작고 빠르며 React 프로젝트에서 사용하는 상태관리 라이브러리입니다.

아래는 간략하게 정리한 Zustand의 특징들입니다.

1. 사용하기 쉬운 API이다

Zustand의 API는 매우 간단하고 직관적이다. 복잡한 설정이 필요 없으며 create 함수를 통해 상태와 상태 변경 함수를 쉽게 정의할 수 있습니다. 또한, 전역 상태와 로컬 상태를 분리하거나 다양한 상태를 혼합해서 사용할 수 있는 유연성을 제공합니다.

2. 최소한의 러닝커브를 가진다

다른 상태 관리 라이브러리와 비교해 상태 정의와 구성이 쉬워 비용이 적게 듭니다.

3. 선택적으로 구독할 수 있다

특정 상태에만 구독할 수 있는 기능을 제공합니다. 즉, 컴포넌트는 필요한 상태 부분만 구독하여 렌더링 성능을 최적화할 수 있으며, 상태가 변경될 때마다 전체 컴포넌트가 리렌더링되지 않도록 방지합니다.

4. 비동기 로직에 대한 간편한 지원

비동기 함수나 동기화가 필요한 상태 관리도 쉽게 지원합니다. useStore 훅을 통해 간단하게 비동기 작업을 정의할 수 있으며, Redux의 Middleward와 유사한 기능도 포함되어 있어 복잡한 비동기 로직을 쉽게 관리할 수 있습니다.

5. Context API와의 통합이 필요 없음

Zustand는 React의 Context API를 사용하지 않으므로, 성능상의 이점을 누릴 수 있습니다. 상태를 전역적으로 사용할 때 Context API의 단점을 피하면서도 상태에 직접 접근할 수 있는 구조입니다.

6. 크기와 성능

Zustand는 가볍고 빠르며, 특히 웹이나 모바일 애플리케이션에서 사용하기가 적합합니다. 크기가 작은 만큼 로딩 속도가 빠르고, 상태 변경 시 최적화 된 구독 구조 덕분에 불필요한 리렌더링이 발생하지 않아 성능에 큰 이점을 줍니다.

이렇게 언뜻 보면 다른 상태 관리 도구들과 함께 옵션에 있는 경우에도 Zustand를 선택해야 하는 이유를 딱 찾지는 못하겠네요 ..

그럼 얘를 왜 써요..?

빠르고 가벼운 전역 상태 관리가 필요한 컴포넌트 기반 애플리케이션
비동기 API 데이터를 효율적으로 캐싱하고 필요한 곳에만 제공해야하는 경우
Context API의 한계를 경험하며 단순하지만 유연한 전역 상태 관리가 필요한 경우
다수의 독립적인 상태 관리가 필요한 복잡한 구조의 프로젝트

Zustand는 가벼운 API와 성능 최적화 덕분에 간단한 전역 상태 관리를 빠르고 효율적으로 제공합니다. 특히, 상태를 컴포넌트 간에 빠르고 공유할 수 있으며 React Context의 단점인 전체 리렌더링을 피해 필요한 부분에만 상태를 제공하는 선택적 구독을 할 수 있습니다.

결론적으로 Zustand의 핵심 키워드는 선택적 구독이라는 생각이 드는데요. 리액트를 공부하면서 코드 최적화를 통해 전체 리렌더링을 줄이는 방법을 공부한 적이 있기 때문에 zustand가 얼마나 효율적일 지 궁금하기도 합니다. 

하지만 Recoil도 atom과 selector 단위로 상태를 관리하기 때문에 선택적 구독이 가능해 익숙한 Recoil에 더 손이 많이 갈 것 같다는 생각을 합니다. 두 방식에 약간의 차이는 있다고 합니다.

- Recoil은 상태 의존성 그래프를 생성하여 상태를 세밀하게 구독하고 업데이트를 전달합니다.

- Zustand는 선택적 구독과 독립적인 스토어 개념을 사용해, 상태를 단순하게 관리하면서도 필요한 컴포넌트에만 상태를 전달하는 방식으로 성능을 최적화합니다.

사실 지난 번 Recoil을 공부할 때 다크모드/라이트모드 등을 예시로 들었었는데 단순 가벼운 전역 상태 관리를 위한 도구로는 zustand가 더 어울린다는 상황이 드네요.

Recoil은 그보다는 조금 더 복잡한 여러 개를 선택하는 필터 옵션, 정렬 옵션 등에 더 어울리는 것 같습니다.

상황에 맞는 상태 관리 쓰기!! 중요 체크체크 

저희 학교 소프트웨어학부 학과 학생들의 졸업 방법은 크게 두 가지가 있는데요.

하나는 졸업 프로젝트, 또 하나는 TOPCIT 시험입니다.

사실 저 같은 경우는 TOPCIT을 접수할 때 이미 졸업 프로젝트가 마무리 되어가고 있었기 때문에 졸업 요건에 대한 큰 걱정은 없었습니다.

하지만 학교에서 TOPCIT을 왜 이렇게 적극적으로 격려하는 지, 응시료 지원 뿐만 아니라 추가 장학금도 주더라고요.

TOPCIT만 응시하면 응시료 지원 + 추가 장학금 + 200점 넘을 시 또 추가 장학금을 준다고 하길래 냉큼 신청했습니다ㅎㅎ;

물론 큰 금액은 아니지만 시험 한 번 보는 것 치고는 가성비 있는 벌이이기도 하고, 학점이 안 좋은 저에게 공부한 능력을 다시 점검하는 기회이기도 하고, 정말 혹시 모를 보험을 위한 졸업 요건이기도 하기 때문에 즐거운 마음으로 응시했습니다.

사실 전공생이라면 아는 지식으로 봐도 졸업요건(150점)은 넘는다는 얘기를 많이 들었기 때문에 공부에 대한 큰 부담은 없었습니다. 

학교에서 공부를 격려하는 마음으로 TOPCIT 공식 홈페이지에서 제공하는 학습 자료를 제본해줬지만 양이 너무 방대해서 ... 쉽게 열어 볼 엄두가 나지 않았어요.

TOPCIT 에센스

하지만 문제를 풀면서 과목들이 비슷해 어느 정도 커버가 되겠다는 생각을 했기 때문에 교재가 너무 두꺼워서 공부하기 어렵겠다는 생각이 드시는 분들은 두 개를 한꺼번에 해결하기 위해 정처기를 공부하셔도 되겠네요👍

탑싯은 단순 성적 뿐만 아니라 종합 성취도, 산업계 부합도, 정체영역 진단 결과, 점수 분포 등 총체적인 결과를 분석해서 함께 제공해줍니다.

미천한 저의 점수를 공개해볼게요.

공부를 좀 했다면 학교 1위를 해서 백만원을 받을 수 있지 않을까? 라는 생각을 점수 나오는 날 아침 2분 정도 했습니다만 상위 10%의 벽부터가 꽤 높아요;;;

저는 총 65문제 중에 38문제를 받아 435점을 받았습니다. 가엾게도 반타작도 못했네요...

이 정도면 개발자할만하다는 거 맞겠죠ㅎㅎ;?? 별 의미가 있나 싶지만 산업계 부합도보다는 가산점 최소 기준인 3수준을 채웠다는 게 정말 기뻐서 후다닥 TOPCIT 가산점을 인정해주는 기업이 남아있나 찾아봤는데 

엥

없는 것 같은데

빨간색이 저고 파란색이 평균입니다

이렇게보면 평균보다는 앵간 높은 결과가 보이죠ㅎㅎ? 이 정도 나온 것만으로도 엄청 만족입니다

개인적으로 데이터랑 보안쪽이 너무 어렵다고 생각했는데 역시나 ^_^

제가 윤리적인 사람인거에 감사하며 살아가야겠어요(사실 이 과목은 그냥 문해력 싸움이었던 것 같기도 하다)

이렇게 저의 TOPCIT 회고 (라기 보다는 걍 점수공개) 를 마칩니다

아직 학생이라면 반드시 열심히 공부해서 학교 1위를 노리는 게 짱인 것 같네요

TOPCIT이 다시 살아나서 어디든 하나라도 가산점을 줬으면 좋겠네요!!

이 글을 쓰는 11월 10일 기준 SQLD 자격증 시험을 딱 일주일 남겨두고 있습니다.

원서 쓸 때마다 자격증 칸이 텅텅 비어서 허전하기도 하고 후에 일부 공고에서 가산점을 받고 싶은 마음으로 SQLD를 신청해봤는데요.

정처기는 가벼운 마음으로 떨어져도 머ㅋ 하고 신청했는데 얘는 무려 오만원입니다. (개비싸)

차마 오만원을 날리고 싶지는 않기 때문에 책까지 사며 공부를 시작했습니다.

사실 많은 분들이 구입하시는 것은 제가 산 책이 아니라 노랑이입니다.

책이 노랗다고 노랑이라고 부르는 게 사람들은 정말 귀여워요

노랑이

저도 주류를 따라 이 책으로 공부할까 하고 더 찾아보고 있었는데 노랑이는 개념, 이론 부분이 간단하고 요약본에 가깝다고 들어서 데베 성적이 별로였던 저는 지레 겁을 먹고 그냥 이론이 많은 책을 찾았습니다.

제가 선택한 것은 이론이 좀 더 자세하게 설명되어 있고 소단원마다 동영상 강의가 있어 이해하기 쉬운 SQLD의 모든 것입니다. 

SQLD의 모든 것

사실 책이 더 예뻐 보이는 것도 있고, 14일 안에 합격을 시켜준다고 해서 딱 2주 전쯤에 결제해서 열심히 공부를 시도해보고 있습니다.

책표지에 보면 노랭이가 이해 안 된다면 이 책을 권한다고 도전장을 내밀고 있을 정도...로 자신이 있나 봐요

책에서 제시하는 학습 플랜입니다

열심히 공부할라고 1일차를 썻다가 ... 곱게 써서 다시 팔라고 더 안 쓰고 있어요ㅎㅎ;

책을 읽다보면 친절하게 어디까지가 몇일차 분량인 지 표시해놔서 하루 공부량을 지켜가며 공부할 수 있어요

개인적으로 책의 구성이 저와 잘 맞는 것 같습니다

이론 + 출제예상문제(20문항) + 복원 기출문제로 구성이 되어 있습니다.

이론으로 공부하고, 출제 예상 문제를 통해 적용과 예시를 이해한 후에 기출 문제를 돌리는 방식이 예시가 있어야만 제대로 이해할 수 있는 저에게 정말 적합한 방식이었습니다.

특히 이론이 길고 영상 강의가 있어서 비전공자들에게는 노랭이보다는 좀 더 편하게 읽힐 것 같다는 생각이 듭니다.

각 문제마다 해설이 있는 것도 공부에 도움이 됩니다

그리고 개인적으로는 시간이 될 때마다 프로그래머스의 SQL 문제를 조금씩 풀고 있는데요

정말 찔끔씩 풀고 있지만 풀다보면 잔디도 채워지고 개념도 잡히고 성취감도 있어요

SQL 활용 문제들은 어느 정도 알고 있는 개념들이기 때문에 이중으로 복습이 되어 공부도 되고 있습니다

2과목이 어려우신 분들은 머리도 식힐 겸 같이 풀며 진행하는 것을 추천합니다

문제는 이걸 아직 합격 안 하고 쓰고 있다는 점인데요

제가 떨어지면 이게 다 무슨 소용일까요? 합격자 발표가 나오려면 다음달까지 기다려야 하니까

제가 붙는다면 합격후기로 다시 돌아오겠습니다

Recoil은 유일하게 내가 주도적으로 사용한 경험이 있는 상태 관리 라이브러리이다. 

이번 졸업 프로젝트에 적용하기 위해서 간단하고 빠르게 익혀 사용할 수 있는 상태 관리 도구가 필요했는데, 지난 번 타 프로젝트에서 누군가 손쉽게 리코일을 추가해 사용법을 알려줬던 기억이 나 빠르게 프로젝트에 적용해 보기로 했다.

내가 리코일을 필요로 했던 상황은 아래와 같다.

1. 페이지에서 내용들을 등록하다가 다른 페이지에 갔다가 돌아오는 경우 

"작업하시던 내용을 그대로 이어하시겠습니까?" 같은 프로세스가 필요했기 때문에

내용을 저장해둬야 했다.

2. 한 페이지 안에서 두 단계를 거쳐 행사를 등록하는 과정을 거치는데 이 과정에서 앞에서 입력받은 내용이 다음 단계에 영향을 끼치는 동시에 왼쪽에 위치한 네비게이션 바에도 영향을 끼쳐야 한다.

위와 같은 이유로 단순히 입력받은 내용을 매개변수로 넘기는 것보다는 전역 상태로 저장해두는 것이 사용하기에 편리하다고 생각이 들었다.

Recoil

리코일 공식 홈페이지

Recoil은 React 애플리케이션을 위한 상태 관리 라이브러리이다. 이는 React의 기본적인 상태 관리 영역에서 확장되어, 특히 복잡하고 대규모의 서비스에서 효율적인 상태 관리를 가능하게 한다.

Recoil은 FaceBook에서 개발 되었으며, React의 기존 개념과 잘 통합되도록 설계되었다.

Recoil을 사용하면 atoms에서 selectors를 거쳐 React 컴포넌트로 내려가는 data-flow graph를 만들 수 있다.

atoms는 컴포넌트가 구독할 수 있는 상태의 단위다. Selectors는 atoms 상태 값을 동기 또는 비동기 방식을 통해 변환한다. 

쉽게 정의하면 키와 기본 값을 정의하는 atoms을 만들어 useRecoilState로 상태를 업데이트하는 툴인 것.

그리고 selector는 기존의 atom이나 다른 selector로부터 계산된 값을 생성할 수 있게 해 주는 것.

솔직히 써봐야 이해하기 쉬운 것 같기는 하다.

아래는 Recoil에서 말하는 Recoil의 사용 이유이다.

- Recoil은 공유상태도 React의 내부 상태처럼 간단한 get/set 인터페이스로 사용할 수 있도록 boilerplate-free API를 제공한다.

- Recoil은 동시성 모드를 비롯한 다른 새로운 React의 기능들과의 호환 가능성도 갖는다.

- 상태 정의는 점진적이고 분산되어 있기 때문에, 코드 분할이 가능하다.

- 상태를 사용하는 컴포넌트를 수정하지 않고도 상태를 파생된 데이터로 대체할 수 있다.

- 파생된 데이터를 사용하는 컴포넌트를 수정하지 않고도 파생된 데이터는 동기식과 비동기식 간에 이동할 수 있다.

- Recoil은 탐색을 일급 개념으로 취급할 수 있고 심지어 링크에서 상태 전환을 인코딩할 수도 있다.

- 전체 애플리케이션 상태를 하위 호완하는 방식으로 유지하기가 쉬우므로, 유지된 상태는 애플리케션 변경에도 살아남을 수 있다.

즉, 다른 상태 관리 툴이 아닌 Recoil을 선택해야 하는 상황은 다음과 같다.

1. 복잡한 파생 상태 관리가 필요한 경우

- Recoil의 selector는 여러 상태를 결합하거나 파생 상태를 계산할 때 매우 강력하다. Redux와 같은 라이브러리에서도 파생 상태를 생성할 수 있지만, Recoil의 selector는 기본적으로 캐싱을 지원하여 성능 최적화를 제공하고, 비동기 상태도 쉽게 처리할 수 있다.

2. React와의 자연스러운 통합을 선호하는 경우

- Recoil은 React에서 작동하도록 설계된 라이브러리로, React의 상태 관리 방식과 일관된 API를 제공한다.

- 특히 React의 기존 useState와 비슷한 사용성을 원한다면 Recoil은 이를 자연스럽게 확장한 느낌을 준다.

3. 동적 상태가 필요할 때

- Recoil의 atomFaimily와 selectorFamily는 파라미터를 통해 상태를 동적으로 생성할 수 있도록 한다.

이는 동적 리스트나 상황에 따라 다른 상태가 필요한 경우 매우 유용하다.

4. 비동기 데이터 관리가 많은 경우

- selector는 비동기 함수를 기본으로 지원하므로 API 호출이나 비동기 데이터 처리가 매우 간편하다. Recoil은 별도의 설정 없이 바로 비동기 상태 관리를 구현할 수 있다.

- Redux에서 Redux-saga를 추가로 필요로하는 것과 달리 단독으로 비동기 상태관리를 할 수 있다는 뜻

* 사용법이나 문법 등은 굳이 추가하지 않겠다.

결론적으로 React와 비슷한 문법으로 자연스럽게 전역 상태 관리를 추가하거나 복잡한 비동기 데이터 관리 등이 필요한 경우에 사용하면 좋은 전역 상태 관리 툴이다. 

다른 프로젝트들을 보니 Recoil은 로그인 상태 관리 혹은 전역 테마 상태 (다크 모드) 관리에 유용하게 사용되는 것 같다.

나도 후에 다크 모드 기능 구현을 시도해보고 싶었는데 그 때 Recoil을 유용하게 사용할 수 있을 것 같다. 

처음 동아리에 들어가 스터디를 하며 Redux에 배웠고, 실제로 개발을 하며 더 가벼운 상태 관리 도구가 필요하다고 생각해 Recoil을 사용해 봤고, 스타트업에서 알바를 할 때는 Zustand로 상태 관리를 하라고 했다.

상태 관리는 다 거기서 거기 아닌가라고 생각이 들었지만, 상태 관리 도구에 따라 기본 원리와 사용법이 다르다.

각각의 상태 관리의 특성들을 이해하고 있어야 상황과 환경에 맞춰 알맞은 상태관리 도구들을 선택할 수 있겠다는 생각이 들어 미리 각 도구들에 대해 이해해놓고자 한다.

사실 이미 가볍게 한 번 공부한 적이 있으나 좀 대충 공부했나.. 잘 생각이 나지 않는다. 

(그래서 복습 겸 .. 오블완 겸 ..)

https://asmallroom.tistory.com/19

좀 더 심화적으로 공부해야겠다.

특히 후의 개발 면접 등을 생각해봤을 때 프로젝트에서 특정 스택을 사용한 이유를 설명할 수 있어야 한다고 생각하니 그 중요성이 더 체감이 된다. 

오늘은 첫번째 상태 관리 도구인 Redux이다. 

Redux

https://ko.redux.js.org/introduction/getting-started/

Redux는 내가 처음 접한 상태 관리 도구이다. 하지만 스터디 당시 너무 어렵고 활용하기가 어렵다는 생각이 들어 제대로 이해하지 못했던 도구이기도 하다.

Redux란 뭘까?

- 자바스크립트 앱을 위한 상태 관리 애플리케이션으로, Redux는 React와 함께 자주 사용되지만 리액트에 한정되지 않고 모든 애플리케이션에서 사용할 수 있다.

Redux의 핵심 개념

- 스토어 : 애플리케이션의 상태를 담고 있는 객체. 단 하나만 존재하며 애플리케이션의 모든 상태가 저장된다.

- 액션 : 상태를 변화시키기 위한 의도를 나타내는 객체

- 리듀서 : 액션을 받아 상태를 업데이트하는 함수이다. 이전 상태와 액션을 인자로 받아 새로운 상태를 반환하는 순수 함수이다.

- 디스패치 : 액션을 스토어에 전달하는 함수이다. 디스패치된 액션은 리듀서를 통해 상태를 업데이트 하게 된다.

=> Redux에서 액션을 보내면, Reducer 함수를 작동시켜, 스토어를 업데이트 한다.

아래의 움짤을 통해 이 과정을 쉽게 이해할 수 있다. 

아래는 이 글을 쓰면서 발견한 칼럼이다. 이 글을 읽고 Redux를 사용해야하는 규모와 이유, 상황에 대해 이해했다.

리덕스가 필요한 이유

위의 칼럼에서 말하는 Redux를 사용해야하는 순간은 다음과 같다.

- 앱 상태의 형태가 여러 컴포넌트에 걸쳐 퍼져있을 때

- 상태를 바꾸는 함수가 여러 컴포넌트에 걸쳐 퍼져있을 때

- 앱 상태의 개요 파악을 위해 마음속에 앱 구조에 대한 모델을 가지고 있어야 할 때

- 여러 단계의 컴포넌트에 걸쳐 같은 props를 전달해야 할 때

- 디버깅할 때 상태 변경을 추적하기가 힘들어졌을 때

사실 전역 상태 관리 도구인 만큼 작거나 간단한 앱은 이런 상황을 이르지 않기 때문에 굳이 상태 관리 앱을 적용해 사용할 필요는 없는 것 같다. 특히 Redux는 너무 장황하고 익히는 데 시간이 걸리기 때문에 급하게 상태 관리를 도입해야 하는 경우에는 선택하고 싶지 않다. 

하지만, 기업별 기술 스택을 확인할 수 있는 페이지인 Codenary에 Redux를 검색해보니 많은 기업, 특히 대기업들도 Redux를 많이 사용하는 것을 확인할 수 있었다.

실제로 나도 공고들을 보면서 Redux 사용 경험에 대해 써져있는 공고들을 심심찮게 발견하기도 했다.

아무래도 기업들의 프로젝트는 사이즈가 크고, 데이터가 많기 때문이다.

관리해야 할 데이터가 많을수록 데이터를 데이터를 엄격하기 관리해야 하기 때문일 것이다.

Redux의 공식 홈페이지에서도 다음 처럼 말하고 있다.

단지 누군가가 사용하라고 했다는 이유만으로 Redux를 사용하지는 마세요. - 시간을 들여서 잠재적인 이점과 그에 따르는 단점을 이해하세요.  

그럼 Redux는 언제 쓰란거지.. 웬만한 상태 관리는 다른 쉬운 상태 관리 툴들로 커버가 될 것 같은데 왜 다들 쓰고 있는 걸까.

공식에서 제시하는 Redux가 사용되어야 하는 상황은 다음과 같다.

- 계속해서 바뀌는 상당한 양의 데이터가 있다

- 상태를 위한 단 하나의 근원이 필요하다

- 최상위 컴포넌트가 모든 상태를 가지고 있는 것은 더 이상 적절하지 않다

어려워요 언제 써야되는 지 몰겠어요

다만 확실한 거는 제가 해왔던 자그마한 플젝들 중에서는 Redux가 쓰일만한 복잡한 상태 관리도 상태가 왔다갔다해야하는 트리구조도 없었기 때문에 딱히 도입할 필요가 없었다는 것을 느꼈다.

근데 어떤 방면에서 보면 Redux가 필요하지 않은 가벼운 프로젝트들만 진행한 것이기 때문에 복잡한 로직 구조와 데이터의 상태 분리 경험도 못 해본 것이기 때문에 약간의 아쉬움이 느껴진다.

이후 사용할 일이 있거나 더 배운 것이 있어서 이 글이 수정되기를 ...🙏

안녕하세요, 오늘은 막학년 여름 방학을 쏟은 저의 졸업작품에 대해 회고해보겠습니다.

프로젝트명은 '체크메이트'로, 교내 행사 및 이벤트 통합 관리를 위한 자동화 서비스라는 부제를 갖고 있습니다.

교내 비교과의 출석 관리 및 서류화를 담당해 주시는 교직원 분들의 불편함을 해소하고자하는

아이디어에서 시작된 프로젝트입니다.

백엔드 한 명, 프론트 엔드 두 명. 총 세 명이 기획하며 프로젝트를 꾸려나갔으며 대략적인 디자인은 디자이너를 구해 따로 디자인을 맡았습니다.

저는 프론트엔드를 맡았으며 PWA 전환 작업, 구글 로그인 연결, 온보딩 페이지, 행사 등록 기능 구현, 전체 통계 기능 구현 등의 작업을 담당했습니다.

개념만 알고 시도해보지 못한 작업들을 시도해보고 스스로의 부족한 부분을 파악할 수 있는 의미있는 프로젝트였습니다.

1. PWA

https://asmallroom.tistory.com/15

이미 한 번 포스팅한 적이 있다. 기존에 웹앱을 만들기 위해 웹페이지를 계획하고 서비스를 만들었다. 

서비스 사용 과정에 몇 가지 에러 사항이 존재했는데,

1. 앱이 아니기에 체크메이트에 바로 들어가기가 애매했다는 점

2. 웹사이트이기 때문에 아이패드 사용 시 도구 막대 때문에 화면이 움직이는 불편함

3. 연결이 불안정할 때 API 연결이 에러 처리가 떠서 원인 파악이 불분명했다는 점

초반에는 사용자 테스트 때마다 직접 가서 사용 상황을 보고 있었기에 대처나 설명이 가능했지만 우리의 목표는 사용자들끼리 오롯이 전체 과정을 진행하는 것이였기 때문에 이 불편함을 해소해야 했습니다.

PWA에 대해서는 자세히 알고 있지 못안녕하세요, 오늘은 막학년 여름 방학을 쏟은 저의 졸업작품에 대해 회고해보겠습니다.

프로젝트명은 '체크메이트'로, 교내 행사 및 이벤트 통합 관리를 위한 자동화 서비스라는 부제를 갖고 있습니다.

교내 비교과의 출석 관리 및 서류화를 담당해 주시는 교직원 분들의 불편함을 해소하고자하는

아이디어에서 시작된 프로젝트입니다.

백엔드 한 명, 프론트 엔드 두 명. 총 세 명이 기획하며 프로젝트를 꾸려나갔으며 대략적인 디자인은 디자이너를 구해 따로 디자인을 맡았습니다.

저는 프론트엔드를 맡았으며 PWA 전환 작업, 구글 로그인 연결, 온보딩 페이지, 행사 등록 기능 구현, 전체 통계 기능 구현 등의 작업을 담당했습니다.

개념만 알고 시도해보지 못한 작업들을 시도해보고 스스로의 부족한 부분을 파악할 수 있는 의미있는 프로젝트였습니다.

1. PWA

https://asmallroom.tistory.com/15 

이미 한 번 포스팅한 적이 있다. 기존에 웹앱을 만들기 위해 웹페이지를 계획하고 서비스를 만들었다. 

서비스 사용 과정에 몇 가지 에러 사항이 존재했는데,

1. 앱이 아니기에 체크메이트에 바로 들어가기가 애매했다는 점

2. 웹사이트이기 때문에 아이패드 사용 시 도구 막대 때문에 화면이 움직이는 불편함

3. 연결이 불안정할 때 API 연결이 에러 처리가 떠서 원인 파악이 불분명했다는 점

초반에는 사용자 테스트 때마다 직접 가서 사용 상황을 보고 있었기에 대처나 설명이 가능했지만 우리의 목표는 사용자들끼리 오롯이 전체 과정을 진행하는 것이였기 때문에 이 불편함을 해소해야 했습니다.

PWA에 대해서는 자세히 알지 못했지만 컴퓨터를 통해 엑셀 파일과 행사의 이미지를 넣는 등록 과정을 거치고, 행사장에 아이패드를 설치해 출석하게 할 수 있는 방법을 충족할 수 있는 저희에게 필요한 솔루션이었습니다.

2. 구글 로그인 

3. Recoil 

4. Chart.js

5. Media-Query

저의 졸업 프로젝트였던 '체크메이트'는 아래의 주소에서 더 자세히 확인하실 수 있습니다.

https://github.com/CheckMate-sookmyung/CheckMate-client

다음 프로젝트는 함께 일하는 팀원들을 위한 코드를 작성하고, 사용자의 편의성에 더욱 신경을 쓰며, 디테일에 신경을 쓸 수 있도록 개선된 프로젝트를 만들겠습니다.

정렬 개념

• 정렬은 사용자가 정의한 순서로 데이터를 나열하는 것을 말한다. 사용자가 정의한 순서는 오름차순 / 내림차순일 수도 있고 임의의 조건이 될 수도 있다.

정렬이 필요한 이유

• 데이터를 정렬하면 원하는 데이터를 쉽게 찾을 수 있다. 이진 탐색 트리가 그 예이다.
• 데이터를 정렬하지 않은 값에서 중앙값을 찾으려면 모든 데이터를 확인하고 비교해야 한다. 반면 데이터를 정렬하면 데이터의 값을 보거나 비교할 필요 없이 말 그대로 데이터 전체 크기에서 중간의 값만 찾으면 그 값 자체가 중앙값이 된다.

삽입 정렬

• 데이터의 전체 영역에서 정렬된 영역과 정렬되지 않은 영역을 나누고 정렬되지 않은 영역의 값을 정렬된 영역의 적절한 위치로 놓으며 정렬한다.

  

• 정렬되지 않은 영역의 맨 앞에 있는 값을 키라고 부른다.
• 삽입 정렬의 과정
  • 최초에는 정렬된 영역을 왼쪽 1개, 정렬되지 않은 영역을 나머지로 친다.
  • 키와 정렬된 영역의 맨 끝 값부터 거슬러 올라가며 다음 처리를 한다.
    • 키보다 크면 해당 값을 오른쪽으로 한 칸 밀어낸다.
    • 키보다 작거나 더 이상 비교할 값이 없으면 밀어낸 자리에 키를 넣는다.
  • 모든 데이터가 정렬된 영역이 될 때까지 위의 단계를 반복한다.
• 삽입 정렬의 시간 복잡도
  • 최악의 경우 O(N^2)
  • 최선의 경우 O(N)

병합 정렬

• 정렬되지 않은 영역을 쪼개서 각각의 영역을 정렬하고 이를 합치며 정렬하는 방식
  • 이런 방식을 분할 정복 (Divide and Conquer) 이라고 한다.

• 정렬되지 않은 영역이 1칸이 될 때까지 반씩 쪼갠 후 다시 조합할 때 오름차순으로 정렬하며 합친다.
• 병합 정렬에서의 핵심은 ‘병합할 때 정렬하는 부분을 어떻게 구현해야 하는ㄱ?’ 이다.
• 병합 정렬의 과정
  • 각 데이터의 첫 번째 원소를 가리키는 포인터를 만든다.
    • 포인터가 가리키는 두 값 중 작은 값을 선택해 새 저장 공간에 저장한다.
    • 값이 선택된 포인터는 다음 위치의 값을 가리킨다.
  • 새 저장 공간에 하나의 데이터가 완전히 저장될 때까지 위 과정을 반복한다.
    • 저장할 값이 남은 데이터의 값을 순서대로 새로운 저장 공간에 저장한ㄷ.
    • 그러면 새로운 저장 공간에 두 개의 데이터가 정렬된 상태로 저장된다.
  • 새로운 저장소에 저장된 값의 개수와 초기에 주어진 데이터에 들어있는 값의 개수가 같을 때까지 과정 1, 2를 반복한다.

📄
포인터라는 개념?
말 그대로 특정 배열의 원소를 가리키기 위한 화살표 같은 것.

• 병합 정렬의 시간 복잡도
  • 병합 정렬의 동작은 분할과 정복(결합)으로 나눠진다.
  • 분할은 배열을 계속 반으로 나누는 과정이고, 더 이상 나눌 수 없을 때까지 반복하므로
    • log_2N번 진행한다.
  • 정복은 다시 병합하며 정렬하는 과정이기 때문에 데이터가 N개면
    • N번 진행하여 병합한다.
  • 분할과 정복을 종합하면 log_2N번의 나누기와 N번의 병합을 수행하므로 총 Nlog_2N번 연산한다.
  • 다만, 시간 복잡도에서는 밑이 2인 로그는 생략하므로 O(NlogN)이라고 할 수 있다.

힙 정렬

• 힙이라는 자료구조를 사용해 정렬한다.
• 따라서 힙 정렬은 힙 자료구조가 무엇인지 먼지 알아야 한다.
• 힙 정렬을 하기 위해서는 먼저 주어진 데이터로 힙을 구축해야 한다.
  • 힙은 특정 규칙이 있는 이진 트리이다. 규칙에 따라 최대 힙, 최소 힙으로 나뉠 수 있다.
  • 최대 힙은 부모 노드가 자식 노드보다 크고, 최소 힙은 부모 노드가 자식 노드보다 작다.힙이란?

    

• 왼쪽의 최대 힙을 보면 부모 노드는 항상 자식보다 크다. 반대로 오른쪽의 최소힙은 부모 노드가 항상 자식보다 작다.

힙 구축 방법 : 최대힙

• 최대힙과 최소힙은 힙을 구성하는 규칙만 다르고 나머지는 모두 동일하다.
• 최대힙을 구축하는 maxHeaplify()라는 함수가 있다고 가정하고 어떻게 연산을 하는 지 알아보자.
  • 현재 노드와 자식 노드의 값을 비교한다.
    • 현재 노드의 값이 가장 크지 않으면 자식 노드 중 가장 큰 값과 현재 노드의 값을 바꾼다.
    • 만약 자식 노드가 없거나 현재 노드의 값이 가장 크면 연산을 종료한다.
  • 맞바꾼 자식 노드의 위치를 현재 노드로 하여 위의 과정을 반복한다.

 📄
 힙을 구축할 때는 자식 노드가 없으면 아무런 동작도 하지 않으므로 N부터 힙 구축을 시작하지 않아도 된다. 현재 노드 인덱스가 N/2을 넘으면 자식 노드의 인덱스가 N을 넘는다. 힙의 크기는 N이므로 실제 노드의 인덱스가 N 이상 넘어가는 일은 없으므로 고려하지 않아도 괜찮다.

• 힙 구축은 N이 아니라 N/2부터 시작해도 괜찮다.
• 힙 정렬 과정 : 최대힙
  • 최대힙에서 힙 정렬은 루트 노드가 가장 큰 값이므로 루트 노드의 값을 빼서 저장하기만 하면 된다. 다만 루트 노드의 값을 뺀 이후 최대힙을 유지하는 것이 중요하다.
    • 정렬되지 않은 데이터로 최대힙을 구축한다.
    • 현재 최대힙의 루트 노드와 마지막 노드를 맞바꾼다. 맞바꾼 뒤 마지막 노드는 최대힙에서 제외한다.
    • 현재 최대힙은 마지막 노드가 루트 노드가 되었다. 따라서 최대힙을 다시 구축해야 하기 때문에, maxHeapify(1)을 진행하여 최대힙을 구축하고 위의 과정을 다시 수행한다. 이 과정을 최대힙의 크기가 1이 될 때까지 반복한다.
• 힙 정렬의 시간 복잡도
  • 정렬되지 않은 값 N개를 힙으로 나타내면 높이가 logN인 트리가 된다. 데이터는 N개이므로 각 데이터에 대해 힙 정렬을 수행하면 시간 복잡도는 O(NlogN)이다.

우선순위 큐

• 우선순위 큐는 우선순위가 높은 데이터부터 먼저 처리하는 큐이다. 쉽게 말해 큐는 큐인데 우선순위에 따라 팝을 하는 큐인 것.
• 우선순위 큐의 내부동작은 힙과 매우 유사하므로 우선순위 큐를 구현할 때는 힙을 활용하는 것이 효율적이다. 여기를 다 공부하면 우선순위 큐 자체가 정렬과 연관이 있음을 알게 된다.
• 우선순위 큐 동작 과정
  • 우선순위 큐의 우선순위 기준은 작은 값일수록 우선순위가 높다고 가정
    • 빈 우선순위 큐를 하나 선언
    • 3을 삽입한다. 빈 큐이므로 별다른 우선순위를 생각하지 않고 맨 앞에 푸시한다.
    • 이어서 1을 삽입한다. 1은 3보다 작으므로 우선순위가 높다. 따라서 1을 3으로 삽입한다. 이렇게 하면 3보다 1이 먼저 pop 될 것이다.
    • pop을 수행하면 1이 나온다.
  • 우선순위에 따라 데이터를 pop할 수 있으므로 정렬과 깊은 연관이 있다는 것도 알았을 것이다.
• 힙으로 우선순위 큐를 구현해야 하는 이유
  • 우선순위 큐의 핵심 동작은 우선순위가 높은 데이터를 먼저 팝하는 것
  • 이를 위해 앞서 언급했던 것처럼 데이터를 푸시할 때마다 아무 정렬 알고리즘을 사용해서 데이터를 우선순위에 맞게 정렬해도 된다.
    • 하지만 최소힙이나 최대힙은 특정 값을 루트 노드에 유지하게 하는 특징이 있고, 이는 우선순위 큐의 핵심 동작과 맞아 떨어지므로 힙을 활용하면 우선순위 큐를 효율적으로 구현할 수 있다는 것을 알 수 있다.
    • 자바스크립트에서는 힙을 공식적으로 제공하지 않는다.
• 우선순위 큐가 활용되는 분야
  • 우선순위 큐는 데이터의 중요성 혹은 우선순위에 따라 처리해야 하는 경우 많이 활용된다.
    • 작업 스케줄링
    • 응급실 대기열
    • 네트워크 트래픽 제어
    • 교통 네트워크 최적화

위상 정렬

• 일의 순서가 있는 작업을 순서에 맞춰 정렬하는 알고리즘
• 위상 정렬은 일의 순서가 중요하므로 반드시 간선의 방향이 있어야 한다.
• 만약 그래프에 순환이 있거나 간선의 방향이 없으면 일의 방향이 없는 것이므로 방향 비순환 그래프 (Directed Acyclic Graph)에서만 사용할 수 있다.
• 위상 정렬과 진입차수
  • 위상 정렬은 자신을 향한 화살표 개수를 진입차수로 정의하여 진행한다. 

    

     
    • 진입차수가 0이라고 하면 자신을 향한 화살표가 없다는 뜻이므로 ‘선행 작업이 필요 없는, 바로 할 수 있는 일’이라는 뜻과 같다.
• 위상 정렬 과정
  • 위상 정렬은 기본적으로 바로 진행할 수 있는 일, 다시 말해 진입차수가 0인 일을 해결하고 관련된 작업의 진입차수를 1씩 낮추면서 새롭게 진입차수가 0이 된 작업들을 해결하는 식으로 진행한다.
  • 이 해결이라는 행위는 큐를 활용하여 구현한다.
  • 진입차수가 0인 작업을 일단 전부 큐에 넣고 하나씩 팝하면서 해당 작업과 연결되어 있는 작업들의 진입차수를 줄이고 진입차수가 0이 된 작업을 큐에 넣는다.
    • 위상 정렬을 진행할 그래프가 있으면 앞서 말한대로 진입차수를 노드에 작성한다.
    • 진입차수가 0인 노드를 큐에 푸시한다. 그런 다음 팝을 하면서 인접한 노드의 진입차수를 -1한다.
    • 노드들이 모두 푸시 후 팝 작업이 완료되면 팝한 순서를 늘어놓는다.
• 위상 정렬의 시간 복잡도
  • 위상 정렬은 모든 정점과 간선을 딱 한 번씩만 지나므로 시간 복잡도는 O(|V| + |E|)가 된다.

계수 정렬

• 데이터에 의존하는 정렬 방식이다.
• 지금까지 배운 정렬들은 사용자가 정한 기준에 따라 정렬했다. 반면 계수 정렬은 데이터의 빈도수로 정렬한다.
  • 왼쪽의 배열에서 데이터의 빈도수를 세어 빈도수 배열에 저장한 것
  • 빈도수를 다 채운 다음 우선 순위가 높은 데이터부터 빈도수만큼 출력하는 것이 계수 정렬

    

• 계수 정렬의 한계
  • 계수 정렬의 핵심 동작은 앞서 본 것처럼 빈도수를 세어 빈도수 배열에 저장하는 것. 그래서 빈도수 배열에 저장할 값의 범위가 듬성듬성 있거나 음수가 있으면 계수 정렬을 하기 곤란하다.
• 계수 정렬의 시간 복잡도
  • 값이 N개인 데이터에서 데이터를 세는 과정은 전체 데이터를 한 번씩 체크하면 되므로 N번 탐색한다고 생각할 수 있다.
  • 값의 최솟값 ~ 최댓값 범위 크기가 K라면 빈도수 배열에서 K + 1만큼 탐색해야 하므로 계수 정렬의 시간 복잡도는 O(N + K) 라고 생각할 수 있다.
• 정렬 알고리즘의 시간 복잡도정렬 방법 최악의 경우 최선의 경우 특이점 

  삽입 정렬	O(N^2)	O(N)	데이터가 거의 정렬되어 있을 때는 최고의 성능 발휘
  병합 정렬	O(NlogN)	O(NlogN)	안정적인 성능으로 정렬 가능
  병합 과정에서의 추가적인 메모리 필요
  힙 정렬	O(NlogN)	O(NlogN)	안전적인 성능으로 정렬 가능
  데이터를 삽입과 동시에 빠르게 정렬할 수 있다
  계수 정렬	O(N + K)	O(N + K)	데이터에 의존적이므로 항상 사용 가능한 것은 아님
  위상 정렬	O(V + E)	O(V+E)	작업의 순서가 존재할 때 사용되는 알고리즘

  • N은 원소의 길이, K는 원소값의 범위, V는 정점, E는 간선의 개수
  • 정렬이 안정적이다?
    • 성능이 안정적이라는 뜻이 아니라 동일한 우선순위를 가진 원소들의 상대적 순서가 정렬 후에도 보존되는 것을 말한다.

문제 풀이

• • K번째 수

  

  • 가장 큰 수

  

  • H - index

  

출처

• 코딩테스트 합격자 되기 - 자바스크립트 편