웹페이지를 이미지로 저장하는 기능을 구현하게 되었다. 하지만 언제나 복병인 ios/safari에서 웹페이지 내부에 자리하고 있는 이미지 요소가 누락되어 저장되는 이미지가 발생했고, 이를 해결한 과정을 기록해보려고 한다.

우선 나는 이미지화를 위해 html-to-image 라이브러리를 활용했다. html-to-image의 동작 방식부터 알아보자.

1. html-to-image 동작 방식

1. DOM 요소를 SVG 문자열로 직렬화
2. SVG를 <img>로 만든 후 <canvas>에 그림
3. 그린 결과물을 다시 toBlob()으로 추출 👉 이 때, SVG 내부에 들어간 image, font 등이 GPU 레이어에 반영되기 전이면 빈 그림이 그려지며 이미지가 누락된 캡쳐가 발생

2. 이슈 원인 : Safari 비동기 렌더링

내가 파악한 이슈의 원인은 다음과 같다.

Safari는 html-to-image로 DOM을 캡쳐할 때, 외부 이미지나 blob URL을 렌더링 직전에 비동기로 불러온다. 렌더 타이밍에 따라 이미지가 GPU 레이어에 올라가기 전에 toBlob이 실행될 수 있다. 👉 이로 인해 간헐적으로 canvas에 그림을 못 그리고, 빈 blob이 생성된 채로 캡쳐 이미지가 생성된 것이었다.

💡 Safari는 DOM에 그려진 것처럼 보여도, 내부적으로 GPU 레이어에 실제 이미지나 폰트가 올라오지 않은 상태일 수 있다.

💡 Safari는 리소스 최적화를 위해 백그라운드 탭에서의 이미지 로딩을 지연시키거나, 크로스-오리진 이미지에서 CORS 정책을 더 엄격하게 적용하기도 한다.

3. 해결 방안 : Blob 사이즈를 활용하기

구글링해 본 결과 html-to-image 라이브러리에도 이미 해당 이슈가 등록 되어 있었고, 여러가지 방법을 시도해보았지만 이슈를 해결할 수 있었던 건 Blob 사이즈를 검사하는 방식이었다.

✨ Blob의 사이즈를 확인하여 이미지 요소가 정상적으로 렌더되었는지 확인 후 이미지 저장을 시도하도록 시점을 변경하였다. ⇒ Safari가 GPU 렌더링까지 끝낼 수 있도록 시간을 벌면서 반복 재시도 ⇒ 이미지가 완전히 그려진 후 캡쳐됨으로써 이미지 누락 문제 해결

4. 시도한 Safari 대응 방법

Summary Safari가 이미지/폰트 렌더링을 완료하기 전에 캡쳐가 시도되어 이미지가 누락 되는 이슈 발생. 정상적으로 렌더링된 Blob의 사이즈인지 검사 후 캡쳐 시도하도록 개선.

🔥 Image is not showing in some cases iOS, Safari

쿠버네티스는 컨테이너 런타임을 통해 컨테이너를 다루는 도구를 말한다. 여러 서버에 컨테이너를 분산 배치하거나 문제가 생긴 컨테이너를 교체하는 등의 일을 해주며, 이를 컨테이너 오케스트레이션이라고 한다.

• Pod Kubernetes의 기본 실행 단위이다. 하나 이상의 컨테이너로 구성되며, 같은 네트워크 환경에서 실행된다. 각 Pod는 자체 IP 주소를 가지며, 컨테이너들 간의 내부 통신이 가능하다.

• Service Pod들을 외부와 연결하거나 클러스터 내에서 접근할 수 있게 한다. 로드 밸런싱, 서비스 디스커버리 등을 제공하여 여러 Pod들을 단일 IP로 묶어 관리한다.

• Deployment 애플리케이션의 상태를 정의하고, 업데이트를 관리한다. 애플리케이션의 버전 관리와 자동 롤백, 확장 등을 지원한다.

• ReplicaSet 특정 수의 Pod 복제본을 항상 유지하기 위해 사용한다.

   Deployment에 의해 관리되며, Pod의 수를 자동으로 조정한다.

• Namespace 클러스터 내에서 리소스를 논리적으로 분리할 수 있는 방법이다. 여러 환경에서 동일한 리소스 이름을 사용하면서도 충돌을 방지할 수 있다.

• Node Kubernetes 클러스터 내에서 애플리케이션을 실행하는 서버이다. 각 Node는 컨테이너를 실행할 수 있는 하나 이상의 Kubelet 프로세스를 실행하고 있다.

• Ingress 외부 HTTP/HTTPS 요청을 클러스터 내부 서비스로 라우팅하는 규칙을 정의한다. 일반적으로 로드 밸런서와 함께 사용되며, URL 경로 기반으로 요청을 처리할 수 있다.

• ConfigMap과 Secret 애플리케이션에 대한 설정 정보를 저장하는 방법입니다. ConfigMap은 텍스트 기반 설정 정보를, Secret은 암호화된 민감한 정보를 저장합니다.

장점

• 자동화: 컨테이너의 배포, 확장, 복구를 자동으로 처리한다.
• 확장성: 애플리케이션의 요구 사항에 맞게 클러스터 리소스를 동적으로 확장할 수 있다.
• 자원 최적화: 클러스터 내 리소스를 효율적으로 분배하고, 여러 애플리케이션을 격리하여 실행할 수 있다.
• 운영 간소화: 상태 관리, 모니터링, 로깅 등을 중앙에서 처리할 수 있어 운영 효율성이 높다.

2. 쿠버네티스 실습

2-0. 미니 쿠베 명령어

# 미니쿠베 시작 (단일노드)
minikube start
minikube start -n 2 # 다중노드
minikube start --driver=docker # 도커를 가상 드라이버로 설정
minikube start -p helloworld # helloworld라는 이름의 프로필로 생성

# 미니쿠베 프로필 목록 확인
minikube profile list

# 현재 사용중인 프로필 확인
minikube profile

# 프로필 변경
minikube profile helloworld # helloword로 변경

# 미니쿠베 상태 확인
minikube status

# 미니쿠베 일시정지
minikube pause

# 미니쿠베 종료
minikube stop

# 미니쿠베 삭제
minikube delete # 미니쿠베 삭제하기

2-1. 미니쿠베 설치 및 시작하기

(1). 미니쿠베 설치

> brew install minikube

==> Auto-updating Homebrew...
Adjust how often this is run with HOMEBREW_AUTO_UPDATE_SECS or disable with
HOMEBREW_NO_AUTO_UPDATE. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
.
.
.
==> minikube
zsh completions have been installed to:
  /opt/homebrew/share/zsh/site-functions

(2). 미니쿠베 실행

> minikube start
>
😄  Darwin 15.2 (arm64) 의 minikube v1.34.0
✨  자동적으로 docker 드라이버가 선택되었습니다
📌  Using Docker Desktop driver with root privileges
👍  Starting "minikube" primary control-plane node in "minikube" cluster
🚜  Pulling base image v0.0.45 ...
💾  쿠버네티스 v1.31.0 을 다운로드 중 ...
    > preloaded-images-k8s-v18-v1...:  307.61 MiB / 307.61 MiB  100.00% 21.89 M
    > gcr.io/k8s-minikube/kicbase...:  441.45 MiB / 441.45 MiB  100.00% 12.76 M
🔥  Creating docker container (CPUs=2, Memory=7789MB) ...
🐳  쿠버네티스 v1.31.0 을 Docker 27.2.0 런타임으로 설치하는 중
    ▪ 인증서 및 키를 생성하는 중 ...
    ▪ 컨트롤 플레인을 부팅하는 중 ...
    ▪ RBAC 규칙을 구성하는 중 ...
🔗  bridge CNI (Container Networking Interface) 를 구성하는 중 ...
🔎  Kubernetes 구성 요소를 확인...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  애드온 활성화 : storage-provisioner, default-storageclass
🏄  끝났습니다! kubectl이 "minikube" 클러스터와 "default" 네임스페이스를 기본적으로 사용하도록 구성되었습니다.

# 실행 상태 확인
> minikube status
>
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

(3). 미니쿠베 프로필 설정

# 기존 실행 중인 미니쿠베 종료
> minikube stop
>
✋  "minikube" 노드를 중지하는 중 ...
🛑  "minikube"를 SSH로 전원을 끕니다 ...
🛑  1개의 노드가 중지되었습니다.

# testProfile 이라는 이름의 프로필 생성 및 시작
> minikube start -p testProfile
>
😄  [testProfile] Darwin 15.2 (arm64) 의 minikube v1.34.0
✨  자동적으로 docker 드라이버가 선택되었습니다
📌  Using Docker Desktop driver with root privileges
👍  Starting "testProfile" primary control-plane node in "testProfile" cluster
🚜  Pulling base image v0.0.45 ...
🔥  Creating docker container (CPUs=2, Memory=7789MB) ...
🐳  쿠버네티스 v1.31.0 을 Docker 27.2.0 런타임으로 설치하는 중
    ▪ 인증서 및 키를 생성하는 중 ...
    ▪ 컨트롤 플레인을 부팅하는 중 ...
    ▪ RBAC 규칙을 구성하는 중 ...
🔗  bridge CNI (Container Networking Interface) 를 구성하는 중 ...
🔎  Kubernetes 구성 요소를 확인...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  애드온 활성화 : storage-provisioner, default-storageclass
🏄  끝났습니다! kubectl이 "testProfile" 클러스터와 "default" 네임스페이스를 기본적으로 사용하도록 구성되었습니다.

# 생성된 프로필 리스트 확인
>  minikube profile list
>
|-------------|-----------|---------|--------------|------|---------|---------|-------|----------------|--------------------|
|   Profile   | VM Driver | Runtime |      IP      | Port | Version | Status  | Nodes | Active Profile | Active Kubecontext |
|-------------|-----------|---------|--------------|------|---------|---------|-------|----------------|--------------------|
| minikube    | docker    | docker  | ---.---.--.- | 8443 | v1.31.0 | Stopped |     1 | *              |                    |
| testProfile | docker    | docker  | ---.---.--.- | 8443 | v1.31.0 | Running |     1 |                | *                  |
|-------------|-----------|---------|--------------|------|---------|---------|-------|----------------|--------------------|

# 프로필 변경
> minikube profile minikube
> ✅  minikube profile was successfully set to minikube

2-2. 도커 이미지 배포하기

(1). deployment.yaml 파일 작성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-web
  template:
    metadata:
      labels:
        app: my-web
    spec:
      containers:
        - name: my-web
          image: my-web:1.0
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: my-web-service
spec:
  selector:
    app: my-web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
  type: NodePort

(2). 미니쿠베 이미지 업로드

• 미니쿠베 활성화 : eval $(minikube docker-env)

# 미니쿠베 도커 활성화
> eval $(minikube docker-env)

# 도커 이미지 빌드
> docker build -t my-web:1.0 .
> [+] Building 19.2s (12/12) FINISHED     

# 이미지 전송
> minikube image load my-web:1.0

# kubectl 컨텍스트 확인
> kubectl config current-context
> minikube

# 컨텍스트가 미니쿠베가 아니라면 미니쿠베로 변경 필요
> kubectl config use-context minikube

# 쿠버네티스 배포
> kubectl apply -f deployment.yaml
> 
deployment.apps/my-web created
service/my-web-service created

(3). 배포 확인

• 미니쿠베 리소스 확인 : kubectl get all

# minikube 리소스 확인
> kubectl get all
>
NAME                            READY   STATUS             RESTARTS   AGE
pod/my-web-57bc889df4-zc84r     0/1     ImagePullBackOff   0          29m

NAME                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/my-web-service     NodePort    10.101.36.165   <none>        80:32136/TCP   29m
service/kubernetes         ClusterIP   10.96.0.1       <none>        443/TCP        163m

NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-web     0/1     1            0           29m

NAME                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/my-web-57bc889df4     1         1         0       29m

2-3. 외부에서 접근할 수 있도록 설정

(1). service.yaml 파일 생성 - nodePort 설정

Node Port는 외부에서 접근할 수 있도록 포트를 개방한다. Node Port를 사용하면 외부에서 지정된 포트를 통해 서비스에 접속할 수 있다.

apiVersion: v1
kind: Service
metadata:
  name: my-web-service
spec:
  type: NodePort
  selector:
    app: my-web
  ports:
    - protocol: TCP
      port: 8080        # 외부에서 접근할 기본 포트
      targetPort: 3000  # 컨테이너의 포트
      nodePort: 30001   # 외부에서 접근할 NodePort (범위: 30000-32767)

(2). deployment / service 배포

• deployment 반영 : kubectl apply -f deployment.yaml
• service 반영 : kubectl apply -f service.yaml

> kubectl apply -f deployment.yaml
> deployment.apps/my-web created

> kubectl apply -f service.yaml
> service/my-web-service configured

(3). 서비스 접근

http://<Minikube IP>:<NodePort> url로 접근 가능하게 된다

• pod 상태 확인 : kubectl get pods

# Pod 상태 확인. Running으로 표시되어야 정상 실행중인 것
> kubectl get pods
>
NAME                        READY   STATUS    RESTARTS   AGE
my-web-78f96cb845-8fhlw     1/1     Running   0          12s

# 미니쿠베 ip 확인
> minikube ip
> 192.168.49.2

# service 확인. 접근 가능 url 출력
> minikube service my-web-service
>
|-----------|------------------|-------------|---------------------------|
| NAMESPACE |       NAME       | TARGET PORT |            URL            |
|-----------|------------------|-------------|---------------------------|
| default   |  my-web-service  |        8080 | http://192.168.49.2:30001 |
|-----------|------------------|-------------|---------------------------|
🏃  my-web-service 서비스의 터널을 시작하는 중
|-----------|------------------|-------------|------------------------|
| NAMESPACE |       NAME       | TARGET PORT |          URL           |
|-----------|------------------|-------------|------------------------|
| default   |  my-web-service  |             | http://127.0.0.1:64487 |
|-----------|------------------|-------------|------------------------|
🎉  Opening service default/my-web-service in default browser...
❗  darwin 에서 Docker 드라이버를 사용하고 있기 때문에, 터미널을 열어야 실행할 수 있습니다

(4). 그 외

• deployment 확인 : kubectl get deployment
• pod 로그 확인 : kubectl describe pod <POD_NAME>
• 서비스 삭제 : kubectl delete service city-web-service
• 쿠버네티스 모든 리소스 삭제 : kubectl delete all --all

# deployment 확인
> kubectl get deployment
>
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
my-web     1/1     1            1           15m

# pod 로그 확인
> kubectl describe pod my-web-57bc889df4-lh2dh
>
Name:             my-web-57bc889df4-lh2dh
Namespace:        default
Priority:         0
Service Account:  default
Node:             minikube/192.168.49.2
Start Time:       Mon, 30 Dec 2024 10:57:12 +0900
Labels:           app=my-web
                  pod-template-hash=57bc889df4
Annotations:      <none>
Status:           Pending
IP:               10.244.0.7
IPs:
  IP:           10.244.0.7
Controlled By:  ReplicaSet/my-web-57bc889df4
Containers:
  my-web:
    Container ID:   
    Image:          my-web:1.0
    Image ID:       
    Port:           3000/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-wlpqw (ro)
.
.
.
Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  2m20s                default-scheduler  Successfully assigned default/my-web-57bc889df4-lh2dh to minikube
  Normal   Pulling    41s (x4 over 2m20s)  kubelet            Pulling image "my-web:1.0"
  Warning  Failed     39s (x4 over 2m17s)  kubelet            Failed to pull image "my-web:1.0": Error response from daemon: pull access denied for my-web, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
  Warning  Failed     39s (x4 over 2m17s)  kubelet            Error: ErrImagePull
  Warning  Failed     25s (x6 over 2m17s)  kubelet            Error: ImagePullBackOff
  Normal   BackOff    13s (x7 over 2m17s)  kubelet            Back-off pulling image "my-web:1.0"

2-4. Port Forwarding

Port Forwarding은 로컬 머신에서 쿠버네티스 Pod으로 트래픽을 포워딩하는 방법이다. 외부에서 서비스에 바로 접근할 수 없고 개발 환경에 사용한다.

(1). Port Forwarding 설정

• 포트포워딩 :kubectl port-forward pod/<POD_NAME> <LOCAL_PORT>:<POD_PORT>

> kubectl port-forward pod/my-web-78f96cb845-8fhlw 8080:3000
>
Forwarding from 127.0.0.1:8080 -> 3000
Forwarding from [::1]:8080 -> 3000
Handling connection for 8080
Handling connection for 8080
Handling connection for 8080
...

(2). 서비스 접근

http://localhost:<LOCAL_PORT> 로 접근 가능하다.

2-5. Volume

볼륨 : pod 내의 컨테이너에서 데이터를 저장하거나 공유할 수 있도록 하는 스토리지

컨테이너는 일시적인 파일 시스템을 사용하므로, 컨테이너가 재시작되거나 삭제되면 데이터가 사라진다. 이러한 문제를 해결하기 위해 볼륨을 사용한다.

볼륨 특징

• pod 내의 여러 컨테이너에서 동시에 접근할 수 있다. 이를 통해 컨테이너 간 데이터 공유가 가능하다.
• 볼륨은 pod의 라이프사이클 동안 유지가 된다. 데이터 영속성을 제공한다.

볼륨 주요 타입

• EmptyDir pod이 실행되는 동안에만 존재하는 임시 볼륨이다. 여러 컨테이너가 데이터를 공유해야하는 경우에 사용한다. pod이 삭제되면 데이터도 함께 삭제된다.

    volumes:
    - name: my-empty-dir
      emptyDir: {}

• hostPath 노드의 특정 디렉토리를 pod에 마운트한다. 로컬 파일 시스템 접근이 필요한 경우에 사용한다. 호스트 의존적이므로 클러스터 간 이식성이 떨어진다.

    volumes:
    - name: my-host-path
      hostPath:
        path: /path/on/host
        type: Directory

• persistentVolumeClaim (PVC) PV와 연동하여 스토리지를 동적으로 할당받는다. 클라우드 스토리지나 네트워크 파일 시스템 사용 시에 사용한다. 데이터가 pod의 라이프사이클과 독립적으로 유지된다.

    volumes:
    - name: my-pvc
      persistentVolumeClaim:
        claimName: my-pvc

(1). 로컬 디렉토리 생성

mkdir -p /Users/unknown/k8sData

(2). 컨테이너 내 디렉토리 탐색

# 실행 중인 컨테이너 확인
> docker ps
>
CONTAINER ID   IMAGE                                 COMMAND                   CREATED      STATUS        PORTS                                                                                                                                  NAMES
73b86b6b2209   gcr.io/k8s-minikube/kicbase:v0.0.45   "/usr/local/bin/entr…"   3 days ago   Up 24 hours   127.0.0.1:55674->22/tcp, 127.0.0.1:55675->2376/tcp, 127.0.0.1:55677->5000/tcp, 127.0.0.1:55678->8443/tcp, 127.0.0.1:55676->32443/tcp   minikube

# 컨테이너 쉘 실행
> docker exec -it 73b86b6b2209 /bin/bash

# 내부 경로 확인
> ls /
CHANGELOG  Release.key  bin  boot  data  dev  docker.key  etc  home  kic.txt  kind  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  version.json
> ls /mnt
> data

(3). 로컬 디렉토리를 VM에 마운트

로컬의 /Users/unknown/k8sData 디렉토리를 컨테이너 /mnt/data로 마운트

> minikube mount /Users/unknown/k8sData:/mnt/data
>
📁  Mounting host path /Users/unknown/k8sData into VM as /mnt/data ...
    ▪ Mount type:   9p
    ▪ User ID:      docker
    ▪ Group ID:     docker
    ▪ 버전:      9p2000.L
    ▪ 메시지 사이즈: 262144
    ▪ 옵션:      map[]
    ▪ 연결된 주소: 127.0.0.1:51567
🚀  Userspace file server: ufs starting
✅  Successfully mounted /Users/unknown/k8sData to /mnt/data

(4). deployment 파일 수정

hostPath 볼륨을 사용하여 /Users/unknown/k8sData 로컬 디렉토리를 컨테이너 내 /app/data 경로에 마운트

    containers:
          volumeMounts:
            - mountPath: /mnt/data  # 컨테이너 내 경로
              name: my-web-volume
      volumes:
        - name: my-web-volume
          hostPath:
            path: /mnt/data  # Minikube VM에서 마운트된 경로
            type: Directory

(5). deployment 적용

수정한 deployment.yaml 파일을 쿠버네티스 클러스터에 적용하여 pod을 배포한다.

명령어 실행 시 쿠버네티스 클러스터 내에 pod이 생성되고, hostPath 볼륨이 설정되어 로컬 PC의 /Users/unknown/k8sData 디렉토리와 컨테이너의 /app/data 경로가 연결된다.

> kubectl apply -f deployment.yaml
> deployment.apps/my-web configured

2-6. replicas 적용

(1). deployment 수정

    # deployment.yaml

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-web
    spec:
      replicas: 2  # replicas 2
      selector:
        matchLabels:
          app: my-web
      template:
        metadata:
          labels:
            app: my-web
        spec:
          containers:
            - name: my-web
              image: my-web:1.0
              imagePullPolicy: Never
              ports:
                - containerPort: 3000
              volumeMounts:
                - mountPath: /mnt/data 
                  name: my-web-volume
          volumes:
            - name: my-web-volume
              hostPath:
                path: /mnt/data 
                type: Directory

(2). 수정한 deployment 적용

> kubectl apply -f deployment.yaml
> deployment.apps/my-web configured

(3). pod이 2개로 유지 실행되는지 확인

# pod이 2개 실행되고 있는지 확인 (status: Running이어야 정상 실행중)
> kubectl get pods
>                
NAME                        READY   STATUS    RESTARTS   AGE
my-web-54677cd5f6-ffftd     1/1     Running   0          8s
my-web-54677cd5f6-ht6fm     1/1     Running   0          8s

# pod 하나 죽여보기
> kubectl delete pod my-web-54677cd5f6-ffftd
> pod "my-web-54677cd5f6-ffftd" deleted

# 새로운 pod이 자동으로 생성되는지 확인
> kubectl get pods
>
NAME                        READY   STATUS    RESTARTS   AGE
my-web-54677cd5f6-bchbh     1/1     Running   0          4s
my-web-54677cd5f6-ht6fm     1/1     Running   0          5m37s

글을 시작하기에 앞서, 나는 3년차 프론트엔드 개발자로, 그 동안 회사에서 프론트 개발 위주의 업무만 했었다. 당장 프론트만 해도 기술 트렌드가 금방금방 바뀌다보니 그거 따라잡기 바빴었다. (react 했다가 vue 했다가.. 다시 react+next하고 난리법석) 그러다가 이번에 이직을 하게 되었는데, 주니어로만 구성되어있던 전 직장과 달리 감사하게도 나 빼고 다 시니어 개발자분들로 개발팀이 구성되어 있었고 이번에 주니어로 내가 합류하게 되면서 많은 가르침을 받고 있다. 프론트엔드 개발자도 인프라에 대해 어느정도 알아두면 좋다며 docker, kubernetes, aws 등등 공부해보자 하셨고, 프로젝트가 잠시 여유있는 기간 동안 인프라에 대해 공부해보게 되었다. (즉 이 글은 인프라에 매우 무지한 프론트 개발자가 찍먹한 인프라를 기록용으로 쓰는 글이라는 점...ㅎㅎ)

1. 컨테이너와 도커, 쿠버네티스 개념 정리

컨테이너는 실행 환경까지 포함하여 독립적으로 프로그램을 실행할 수 있도록 도와주는 기술이다. 컨테이너 환경을 묶어서 배포한 컨테이너 이미지를 내려받아 구동하면 각종 설정 과정을 줄일 수 있다. 이러한 컨테이너를 사용할 때 필요한 도구가 컨테이너 런타임이며, 그 중 유명한 것이 도커이다.

*용어 정리 컨테이너 : 앱이 구동되는 환경까지 감싸서 실행할 수 있도록 하는 격리 기술 도커 : 컨테이너를 다루는 도구 (컨테이너 런타임) 쿠버네티스 : 컨테이너 런타임을 통해 컨테이너를 오케스트레이션하는 도구 오케스트레이션 : 여러 서버에 걸친 컨테이너 및 사용하는 환경 설정을 관리하는 행위

2. Docker 실습

Docker는 컨테이너를 사용해 애플리케이션을 실행하기 위한 플랫폼이다. 컨테이너는 애플리케이션과 필요한 모든 라이브러리, 의존성을 하나의 패키지로 묶어 운영체제에 독립적인 환경을 제공한다. 즉, 어떤 환경에서든 프로그램이 동일하게 운영되게 도와준다.

Docker Image는 컨테이너를 실행하기 위한 불변의 템플릿이다. 애플리케이션 코드, 라이브러리, 환경설정 파일 등을 하나의 이미지로 저장하는 것이다.

2-1. Dockerfile 작성

프로젝트 루트 위치에 Dockerfile 생성

> Dockerfile

# 베이스 이미지 선택
FROM node:22

# 작업 디렉토리 설정
WORKDIR /app

# 패키지 파일 복사
COPY package*.json ./

# 의존성 설치
RUN npm install

# 애플리케이션 코드 복사
COPY . .

# 애플리케이션 실행
CMD ["npm", "start"]

# 컨테이너가 사용할 포트
EXPOSE 3000

2-1-1. docker-compose.yml 작성

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:3000"
    volumes:
      - ./app:/app
    environment:
      NODE_ENV: production

2-2. 도커 이미지 빌드

docker build -t <이미지_이름>:<태그> <경로>

 > docker build -t my-web:1.0 .

my-web : 이름으로 이미지 태깅 1.0 : 태그 정보 . : 현재 디렉토리를 빌드 컨텍스트로 사용

2-2-1. docker-compose로 이미지 빌드

docker-compose build

2-3. 빌드된 이미지 리스트 확인

docker images

> docker images

> 결과물
> REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
> my-web     1.0       2d22502f7d55   30 seconds ago   3.21GB

REPOSITORY: 이미지 이름 TAG: 이미지 태그 IMAGE ID: 이미지의 고유 ID SIZE: 이미지 크기

2-4. 도커 컨테이너 실행

docker run -p <호스트_포트>:<컨테이너_포트> <이미지_이름>:<태그>

> docker run -p 8080:3000 my-web:1.0

p 8080:3000: 호스트의 8080번 포트를 컨테이너의 3000번 포트와 연결 my-web:1.0: 사용할 이미지 이름과 태그

동작 방식 ∙호스트 포트 : 도커 컨테이너 외부에서 접근 시 사용되는 포트 ∙컨테이너 포트 : 도커 컨테이너 내에서 실행되는 포트
호스트 포트를 통해 브라우저나 다른 클라이언트가 컨테이너 내 프로젝트에 접근한다. → 컨테이너는 내부적으로 3000번 포트에서 프로젝트를 실행하고 있으며, 외부에서 직접 접근 불가능하다. → 8080번 포트로 접근 시 컨테이너의 300번 포트로 요청이 전달된다.

2-5. 도커 컨테이너 로그 확인

2-6. 도커 볼륨

2-6-1. 볼륨 생성하기

docker volume create <볼륨 이름>

> docker volume create volumeTest

2-6-2. 생성된 볼륨 확인하기

// 볼륨 리스트 확인
> docker volume ls
> DRIVER    VOLUME NAME
> local     volumeTest

// 볼륨 정보 확인
> docker volume inspect volumeTest
> 
[
    {
        "CreatedAt": "2024-12-26T04:18:25Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/volumeTest/_data",
        "Name": "volumeTest",
        "Options": null,
        "Scope": "local"
    }
]

2-6-3. 컨테이너와 연결

> docker run -p 8080:3000 -v /Users/joy/log:/app/logs my-web:1.0

→ 확인

// 실행 중인 컨테이너 확인
> docker ps
> CONTAINER ID   IMAGE          COMMAND                   CREATED         STATUS         PORTS                    NAMES
> 7cbce098572b   my-web:1.0   "docker-entrypoint.s…"   6 minutes ago   Up 6 minutes   0.0.0.0:8080->3000/tcp   gifted_mclaren

> docker exec -it 7cbce098572b sh // 컨테이너 접속
> cd /app
> ls -l // 파일 리스트 확인
-rw-r--r--  1 root root    365 Dec 26 05:23 Dockerfile
-rw-r--r--  1 root root   1253 Dec 26 00:45 README.md
-rw-r--r--  1 root root    238 Dec 26 05:15 app.log
-rw-r--r--  1 root root    393 Dec 24 06:12 eslint.config.mjs
drwxr-xr-x  2 root root   4096 Dec 26 05:33 logs
-rw-r--r--  1 root root    228 Dec 24 06:17 next-env.d.ts
-rw-r--r--  1 root root    744 Dec 26 02:15 next.config.mjs
drwxr-xr-x  1 root root  16384 Dec 26 05:32 node_modules
-rw-r--r--  1 root root 298276 Dec 26 00:13 package-lock.json
-rw-r--r--  1 root root    807 Dec 26 00:13 package.json
-rw-r--r--  1 root root    135 Dec 24 06:12 postcss.config.mjs
drwxr-xr-x  2 root root   4096 Dec 24 06:12 public
drwxr-xr-x 12 root root   4096 Dec 24 06:22 src
-rw-r--r--  1 root root   4328 Dec 26 00:37 tailwind.config.ts
-rw-r--r--  1 root root    602 Dec 24 06:12 tsconfig.json
> exit

// 로그 파일 생성 확인
> ls /Users/joy/log

2-7. 도커 이미지 업로드 (docker hub / aws)

2-7-1. dockerhub에 이미지 업로드하기

(1). 도커 로그인

> docker login
> Authenticating with existing credentials...
> Login Succeeded

(2). 이미지 태그 지정

docker tag <로컬_이미지> <dockerhub_사용자명>/<리포지토리_이름>:<태그>

> docker tag my-web:1.0 joy/my-web:1.0

(3). 이미지 푸시

docker push <dockerhub_사용자명>/<리포지토리_이름>:<태그>

 > docker push joy/my-web:1.0

 >
 The push refers to repository [docker.io/joy/my-web]
 ...
 92b12b0dccf2: Pushed 
 fd63102cac36: Pushed 
 1.0: digest: sha256:209aff250058014a9c073d2a311ee9644ca2d98221105d6f741aa3a7b712b0e3 size: 856

(4). dockerhub 업로드 확인

2-7-2. aws erc 에 이미지 업로드하기

(1). aws configure 설정

> aws configure
> AWS Access Key ID [None]:
> AWS Secret Access Key [None]:
> Default region name [None]: ap-northeast-2
> Default output format [None]: 

// 작업 증명 활성화 홧인
> aws sts get-caller-identity
> 
{
    "UserId": "",
    "Account": "",
    "Arn": ""
}

(2). ecr 레포지토리 생성

(3). aws ecr 로그인

aws ecr create-repository --repository-name <리포지토리_이름> --region <리전_이름>

> aws ecr get-login-password --region ap-southeast-2 | docker login --username ~~~             
> Login Succeeded

(4). 이미지 태그 변경

docker tag <로컬_이미지_이름>:<태그> <AWS_Account_ID>.dkr.ecr.<리전_이름>.amazonaws.com/<리포지토리_이름>:<태그>

> docker tag my-web:1.0 ~~~

(5). 이미지 푸시

docker push <AWS_Account_ID>.dkr.ecr.<리전_이름>.amazonaws.com/<리포지토리_이름>:<태그>

> docker push ~~~

> The push refers to repository ~~~
...
3981e863d195: Pushed 
92b12b0dccf2: Pushed 
ff27b22d4715: Pushed 
7bd0f29b7dc7: Pushed 
1.0: digest: sha256:209aff250058014a9c073d2a311ee9644ca2d98221105d6f741aa3a7b712b0e3 size: 856

(6). 이미지 업로드 확인

pull to refresh를 구현하다가 막혔던 ios 이슈를 해결한 방법을 기록해보려고 한다. 현업에서 일하다 보면 내 블로그를 내가 참고하게 되는 일이 참 많다. 과거의 나에게 또 물을 수 있도록 미루던 블로깅을 이제서야 한다.🥲

ios에서는 기본적으로 scroll bounce 이라는 효과를 제공한다. 이는 페이지 최상/하단에 도달했을 때 페이지가 고무줄처럼 늘어나는 효과인데, 스크롤이 관성적으로 작용한다. 좋은 UX이긴 하지만, 프론트엔드 개발자로서 다양한 이벤트들을 적용하다보면 골칫거리가 되기도 한다...ㅎㅎ

pull to refresh UI를 구현하다가 scroll bounce와 스크롤 이벤트가 충돌하여 애를 먹은 적이 있었다. (왜 항상 aos에서는 정상 작동하는데, ios 너만...)

서론이 길었지만, 스크롤 바운스 막는 방법은 다음과 같다.

• html, body 태그 overflow: hidden;
• body 태그 position: fixed; inset: 0

// pulling 중일 때 ios 스크롤 바운스 비활성화 처리
isPulling(n) {
  if (n) {
    // ios 스크롤 바운스 방지
    document.documentElement.style.overflow = 'hidden';
    document.body.style.overflow = 'hidden';
    document.body.style.position = 'fixed';
    document.body.style.inset = '0px';
  } else {
    // ios 스크롤 바운스 방지 해제
    document.documentElement.style.overflow = 'auto';
    document.body.style.overflow = 'auto';
    document.body.style.position = '';
    document.body.style.inset = '';
  }
}

참고로 나는 pull to refresh 시에만 스크롤 바운스를 비활성화 시키고 싶었기에 pulling 이벤트가 진행 중일 땐 해당 css를 적용시켰다가 pulling이 끝나면 css를 초기화 시켜 비활성화를 해지시켰다.

Next.js는 리액트 기반의 서버사이드 렌더링 프레임워크이다. React는 클라이언트 사이드에서만 작동한다는 특징이 있는데, 이로 인해 SEO 효과가 저조했으며 초기 렌더링시 성능 부담이 크다는 문제점이 존재했다. 이러한 문제점을 해결하기 위해 Next.js가 도입되기 시작했다.

📑 Next13 이후에 변경된 점

app router가 도입되면서 page router 와 app router 두 가지 방식으로 나뉘게 되었다.

• app router : app/ 디렉토리로 라우팅을 처리하는 방식
• page router : pages/ 디렉토리로 라우팅을 처리하는 방식

두 라우팅 방식의 차이점은 서버 컴포넌트를 사용하는지에 대한 유무이다.

*서버 컴포넌트 : 넥스트 서버에서 리액트를 미리 렌더링해서 프론트 또는 브라우저 또는 클라이언트로 데이터를 보내줄 때 완성된 HTML을 미리 보내주는 것
프론트 입장에서 HTML 로딩 시간 감소, HTML과 JS 용량 감소 등의 이점이 생겼다.
그러나, 서버 컴포넌트는 유저의 브라우저에서 진행하던 일을 넥스트 서버에서 다 진행하기 때문에 서버의 부담이 증가한다. 이 문제를 원활하게 해결하고자 서버에서 캐시를 적극적으로 활용했다.

2. Next.js 프로젝트 생성하기

npx create-next-app 프로젝트명

*리액트 프로젝트 생성 명령어와 매우 유사하다 (npx create-react-app)

3. Next 폴더 구조

• public : 퍼블릭 폴더 내부에 위치한 것들은 넥스트 서버에서 누구나 접근할 수 있게 서빙 해준다. 때문에 모든 사람이 접근해도 무방한 이미지와 같은 파일들이 내부에 위치하게 된다.
• src : 보통은 루트 아래에 src, app이 별도로 존재하는 구조이지만, src 내에 app 폴더를 두게 되면 타입스크립트를 한번에 처리하기에 용이하다.
• app : 라우터와 관련된 파일들이 위치한다.
• next.config.js : 넥스트에 대한 설정 파일
• ts-config.json : 타입스크립트에 대한 설정 파일

4. Root Layout

app router는 app 디렉토리 내에 root layout을 필수로 포함해야 한다. Root Layout은 모든 페이지에 공통적으로 적용되는 레이아웃으로, 필수 레이아웃이다. Root Layout에는 html 태그와 body 태그가 포함되어야 한다.

만일, 라우터별로 레이아웃을 따로 만들고 싶다면 해당 디렉토리 내에 layout.tsx 파일을 별도로 생성하면 된다. *RootLayout > HomeLayout > HomePage

export default function RootLayout({ 
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

5. [Dynamic Routes]

Dynamic Routes는 동적 데이터(변수)로 라우터를 설정할 때 사용한다. 디렉토리명을 대괄호[] 로 묶어서 생성하면 해당 경로는 동적 데이터를 사용할 수 있다.

예를 들어, https://velog.io/@kim_unknown_ 과 같이 경로에 유저의 id가 들어가야 한다면, [userId] 와 같이 디렉토리를 생성한다.

6. (Route Groups)

Route Groups는 라우터에 영향을 주지 않으면서 라우터를 그룹화할 때 사용한다. 디렉토리명을 소괄호()로 묶어서 생성하면 내부에 있는 디렉토리들을 그룹화할 수 있다.

예를 들어, 아래와 같이 특정 서비스의 로그인 전 단계와 로그인 후 단계의 경로를 구분하여 그룹화할 경우, (beforeLogin) 과 (afterLogin)은 경로가 되지 않는다. 단순 묶음 폴더의 역할을 하는 것 뿐이다. 따라서 실제 브라우저 주소창에는 /login , /join , /logout , /leave 로 경로가 보이게 된다.

app
    /* 로그인 전 라우터 */
  ⌞(beforeLogin) 
    ⌞login 
    ⌞join
   /* 로그인 후 라우터 */
  ⌞(afterLogin)
    ⌞logout
    ⌞leave

7. layout.tsx / template.tsx

• Layout : 페이지를 넘나들 때 새로 마운트(리렌더링)가 되지 않는다.
• Template : 페이지를 넘나들 때마다 새로 마운트(리렌더링)가 된다.

때문에 마운트 필요에 따라 적절하게 레이아웃과 템플릿을 구분하여 사용해야 한다. 레이아웃과 템플릿은 공존하면 안된다.

8. Link

Next에서는 <a> 태그 대신 <Link> 컴포넌트를 사용한다. <a> 태그를 사용하여 경로 이동 시, 화면이 깜빡거리며 페이지가 새로고침 되기 때문에 좀 더 부드러운 경로 이동을 위해 <Link> 컴포넌트를 사용한다.

import Link from "next/link";

<Link href="/home">홈</Link>

9. Image

Next에서는 <img> 태그 대신 <Image> 컴포넌트를 사용한다. <Image> 컴포넌트를 사용하게 되면 넥스트에서 이미지를 최적화해준다.

Image 컴포넌트에서 제공하는 기능은 다음과 같다.

• lazy loading
• 이미지 사이즈 최적화
• placeholder 제공

import Image from "next/image";
import logo from '../public/logo.png';

<Image src={logo} alt="logo" />

10. Redirect

redirect 함수는 다른 URL로 리다이렉트 시킬 때 사용한다.

import { redirect } from 'next/navigation';

export default function Default() {
  redirect('/home');
}

11. @Parallel Route

Parallel Route는 여러 개의 페이지를 동시에 보여줄 때 사용한다. (ex. 뒤에 페이지가 남아있으면서 그 위로 모달을 띄울 때) Parallel Route를 적용할 때는 디렉토리명 앞에 골뱅이(@)를 명시한다. (ex.@modal)

다만, 같은 계층에 위치한 페이지끼리 병렬적으로 렌더링할 수 있기 때문에 다른 계층 구조의 페이지는 병렬적으로 렌더링할 수 없다.

12. "use client"

• 서버 컴포넌트 : 서버에서 도는 컴포넌트, 리액트 Hook 사용 불가
• 클라이언트 컴포넌트 : 클라이언트단 컴포넌트, 리액트 Hook 사용 가능

서버 컴포넌트를 클라이언트 컴포넌트로 전환하기 위해서는 파일 최상단에 "use client" 를 명시한다.

*서버 컴포넌트는 클라이언트 컴포넌트를 임포트하는 것이 가능하지만, 클라이언트 컴포넌트는 서버 컴포넌트를 임포트는 것이 불가능하다. *클라이언트 컴포넌트가 서버 컴포넌트를 임포트하면 클라이언트 컴포넌트로 바뀌어버린다.

• 서버 -> 클라이언트 (O)
• 클라이언트 -> 서버 (X)

13. default.tsx

default.tsx는 Parallel Route의 기본값이다.

export default function Default(){
    return null;
}

14. (.)Intercepting Routes

Intercepting Routes는 서로 다른 라우트에서 한 화면을 같이 뜰 수 있게 해준다. Intercepting Routes를 적용할 때는 디렉토리명 앞에 (상대경로..) 를 명시한다.

• (.)을 사용하여 동일 레벨 세그먼트 매칭
• (..)을 사용하여 1단계 윗 레벨 세그먼트 매칭
• (..)(..)을 사용하여 2단계 윗 레벨 세그먼트 매칭
• (...)을 사용하여 app 디렉토리의 루트에 위치한 세그먼트 매칭

ex. (.)myPage (인터셉트 라우트) / myPage (일반 라우트)

*Interception Routes는 클라이언트 단을 통해서 진입할 때 적용되며, 브라우저로 주소창을 입력하여 직접 진입하거나 새로고침을 할 경우에는 일반 라우트로 넘어간다. 따라서, 가로채기가 발생하는 상황과 발생하지 않는 상황에 따라 두 디렉토리가 모두 필요하다

15. _Private Folder

Private Folder는 폴더 정리용으로 사용되며, 라우터에 영향을 주지 않는다. Private Folder를 적용할 때는 디렉토리명 앞에 언더바(_)를 명시한다.

라우터에 영향을 안주는 폴더 3가지

• (그룹 폴더)
• @페러렐 라우트
• _프라이빗 폴더

참고자료 🎥 Next + React Query로 SNS 서비스 만들기 강의

자바스크립트에서History API는 history 전역 객체를 사용하여 브라우저의 세션 히스토리에 대한 접근과 조작 기능을 제공한다. 여기서 세션 히스토리는 페이지 방문 이력을 의미한다. 즉, 세션은 유저가 새 페이지를 열 때마다 쌓이며, 이를 통해 브라우저에서 앞으로 가기, 뒤로가기가 가능하다.

뒤로가기	앞으로가기	세션 length

2. History API 메소드

History API의 메소드는 크게 2가지 특성으로 분류해서 설명할 수 있을 것 같다. 페이지 이동을 위한 메소드(back, forward, go)와 세션 히스토리 변경을 위한 메소드(pushState, replaceState)이다.

history.back()

history.back()은 브라우저 상에서 뒤로가기 버튼을 누른 것과 같은 효과를 낼 수 있다. 즉 하위 state로 이동하며, history의 length는 유지된다.

history.forward()

history.forward()는 브라우저 상에서 앞으로가기 버튼을 누른 것과 같은 효과를 낼 수 있다. 상위 state로 이동하며, history의 length는 유지된다.

history.go()

history.go()는 현재 state를 기준으로 특정 위치의 state로 이동시키는 효과를 낼 수 있다. 파라미터로 양수를 넘기면 앞으로 이동하며, 음수를 넘기면 뒤로 이동한다. 또한 0을 넘기면 해당 페이지를 새로고침한다. 따라서, go()는 back()과 forward()를 모두 대체 가능하다.

history.back();      // 뒤로가기
history.forward();   // 앞으로가기

history.go(-1);      // 현재 state 기준 뒤로 1칸 가기 (=history.back())
history.go(0);       // 새로 고침
history.go(1);       // 현재 state 기준 앞으로 1칸 가기 (=history.forward())

*즉, back, forward, go 메소드는 세션 히스토리를 변경시키지 않는다.

history.pushState()

history.pushState(state, title, url)

• state : 직렬화가 가능한 아무 값을 넣을 수 있으며, history.state로 꺼내어 사용 가능하다.

• title : 사용하진 않지만 필수로 넣어야하는 값으로, 주로 빈문자열을 넣는다.
• url : 새로 히스토리에 쌓을 url 이다.

pushState()는 파라미터로 들어온 url을 현재 state의 다음 state로 추가하며, 뒤에 있던 state는 모두 날려버린다. 즉, 파라미터로 들어온 url이 가장 최상위 state가 되는 것이다.

history.replaceState()

history.replaceState(state, title, url) *파라미터는 pushState와 동일

replaceState()는 파라미터로 들어온 url로 현재 페이지의 url을 변경한다. 즉, 새로운 state를 쌓는 것이 아닌 현재 state를 대체하는 것이며 state length의 변화가 없다.

3. popstate 이벤트

브라우저에서 뒤로가기, 앞으로가기 액션이 일어나면 popstate 이벤트가 발생된다. 이 popstate 이벤트를 활용하여 뒤로가기 누르면 모달 닫기 등의 적절한 처리가 가능하다.

window.addEventListener("popstate", (event) => {
 console.log(event.state)
});

참고자료 🎥 [10분 테코톡] 참새의 history api

UX적으로 생각해보았을 때 모달은 페이지 변경이 아닌 레이어 위에 쌓이는 형태이기 때문에 라우팅 변경없이 띄워지고 사라질 때로 라우팅 변경없이 모달 창만 사라지는게 가장 자연스럽다고 생각했다.

또한, 만약 이 모달이 띄워진 상태에서 유저가 브라우저 창의 뒤로가기 버튼을 눌렀을 시에도 라우터가 뒤로가는 게 아닌 모달창이 닫히는 게 자연스러운 사용자 경험을 제공할 것이라 생각했다. 이러한 고민을 바탕으로 내가 어떤 식으로 모달을 관리했는지 공유해보려고 한다.

내가 생각한 로직은 다음과 같다.

• 모달을 열 때는 store에 현재 여는 모달을 기록하고 history를 한 번 쌓아준다.
• 모달을 store에 기록하는 이유는 브라우저 상에서 모달이나 팝업 등이 중첩으로 열리는 경우도 있기 때문에 이를 전역적으로 상태관리를 하기 위함이다.
• 브라우저 상에서 뒤로가기/닫기 액션이 이루어졌을 때는 store에 담아둔 모달 리스트를 체크하고 띄워져 있는 모달이 있다면 모달만 닫는다. 이 때 쌓아둔 히스토리를 제거한다.

1. 모달 관리 스토어 생성하기

// modal 관리를 위한 스토어 생성
export default {
  name: 'modal',
  state() {
    return {
      modalList: [] // 쌓인 모달을 담을 배열
    };
  },
  getters: {
    getModalList(state) {
      return state.modalList;
    }
  },
  mutations: {
    // 모달이 띄워질 때마다 modalList에 추가
    ADD_MODAL_LIST(state, value) {
      state.modalList.push(value);
    },
    // 모달이 닫힐시 modalList에서 제거
    REMOVE_MODAL_LIST(state, value) {
      state.modalList.splice(value, 1);
    },
    // modalList 제일 뒤에 있는 요소 제거
    POP_MODAL_LIST(state, value) {
      state.modalList.pop();
    }
  },
  actions: {
    // 현재 닫으려고 하는 모달을 찾아 modalList에서 제거
    // 다만 동일한 모달이 여러 개가 띄워졌을 경우 가장 위에 쌓인 하나만 제거 되도록 함
    removeLastModal({ getters, commit }, modalElement) {
      const modalList = window.$nuxt.$store.getters['router/getModalList'];
      const findIndex = modalList.indexOf(modalElement);
      if (findIndex > -1) {
        window.$nuxt.$store.commit('router/REMOVE_MODAL_LIST', findIndex);
      }
    }
  }
};

2. 모달 open, close 공용함수 만들기

computed: {
  ...mapGetters({
    modalList: 'modal/getModalList'
  })
},
methods: {
  ...mapMutations({
    ADD_MODAL_LIST: 'modal/ADD_MODAL_LIST',
    POP_MODAL_LIST: 'modal/POP_MODAL_LIST'
  }),
  ...mapActions({
    removeLastModal: 'modal/removeLastModal'
  })
  ...
}

// 모달, 팝업 띄우기
openModalHandler(component, props = {}, actions = {}) {
  /* 컴포넌트 띄우는 함수(openHandler) 실행 시 mount와 close 이벤트 액션을 넘김 */
  return this.openHandler(component, props, { ...actions,
    // mount event action
    mount: (componentEl) => {
      // 컴포넌트가 마운트 되면 mount 이벤트를 emit
      // history 쌓기
      window.history.pushState(null, '', window.location.href);
      this.ADD_MODAL_LIST(componentEl); // store에 마운트된 컴포넌트 담기
    },
    // close event action            
    close: (componentEl) => {
      // 모달 내부적으로 존재하는 닫기 버튼을 누르면 close 이벤트 emit
      // 컴포넌트 제거 함수 (closeHandler) 실행하여 띄워진 요소 닫기
      this.closeHandler(componentEl);
      this.removeLastModal(componentEl); // store removeLastModal 함수 실행
    }
  });
}


// 브라우저 뒤로가기 시 모달, 팝업만 닫기
closeModalHandler() {
  // 가장 위에 쌓인 모달 요소 찾기
  const modalEl = this.modalList[this.modalList.length - 1];
  // 찾은 모달 닫기 액션
  this.closeHandler(modalEl);
  this.POP_MODAL_LIST(); // store에서 modal 제거
}

3. 브라우저 뒤로가기 이벤트 감지

브라우저 페이지 이동 시에 발생하는 onpopstate 이벤트를 활용하여 브라우저 뒤로가기 이벤트를 감지시 예외처리를 해주었다.

// 브라우저 레이어가 mount 됐을 때 popstate 이벤트 핸들러 등록
mounted() {
  window.addEventListener('popstate', this.historyHandler);
},
beforeDestroy() {
  window.removeEventListener('popstate', this.historyHandler);
},

...

// 브라우저 뒤로가기 클릭시 모달만 닫히도록 예외처리
historyHandler() {
  // 스토어 modalList length를 체크하여
  // 떠 있는 팝업이 존재하면 팝업만 닫히게 closeModalHandler 실행
  if (this.modalList.length > 0) {
    this.closeModalHandler();
  }
}

프론트엔드 스터디에서 eject를 해보게 되었는데, eject를 하고 나니 Parsing Error가 뜨면서 파일마다 빨간줄이 뜨고 난리가 났었다.ㅠㅠ 생각보다 간단하게 해결이 되었는데, 여러 삽질 끝에 해결한 방법을 공유해보겠다.

우선 eject가 무엇인지 알고 들어가자.

1. eject란

CRA로 생성한 프로젝트는 설정파일과 종속성 등등의 것들이 숨겨져 있는데, 이 설정들을 보이도록 꺼내주는 것이 eject이다. eject는 한 번 하면 되돌릴 수 없기 때문에 신중히 해야한다.

npm run eject

eject를 하고나면 아래와 같은 설정 파일들이 나타나는 것을 볼 수 있다.

2. eject 후 나타나는 Parsing Error 해결하기

eject를 실행하고 났더니 아래와 같이 parsing error가 나타났다.

수시간의 삽질 끝에 내가 해결한 방법은 아래와 같다. package.json > "eslintConfig"에 아래 코드를 추가했더니 해결되었다.

// package.json

  "eslintConfig": {
    ...
    "parserOptions": {
      "babelOptions": {
        "presets": [
          [
            "babel-preset-react-app",
            false
          ]
        ]
      }
    }
  },

혹시 나와 같은 오류로 헤매고 있는 사람이 있다면 이 글이 도움이 되었으면 좋겠다🥲

참고자료 🗒️https://github.com/velopert/learning-react/issues/348

CRA 환경에서 eject하지 않고 Craco를 활용하여 절대경로 설정할 수 있다. 구글링 해보면 craco-alias를 활용하는 방법이 많이 나오는데, 현재는 지원하지 않는다고 한다. 몇 시간의 삽질 끝에 성공한 craco만으로 적용하는 방법을 정리해보려고 한다.

1. Craco 설치

craco는 *Create **React App Configuration Override의 약자로, CRA에 config 설정을 덮어쓰기 위한 패키지이다.

npm install @craco/craco

2. tsconfig.paths.json 생성

tsconfig.json 파일의 경로설정을 외부파일(tsconfig.paths.json)로 분리한다. 파일을 루트 위치에 생성한다.

// tsconfig.paths.json

{
    "compilerOptions": {
        "baseUrl": "./src",
        "paths": {
            "@components/*": ["./components/*"],
            "@pages/*": ["./pages/*"],
            "@styles/*": ["./styles/*"]
        }
    }
}

3. tsconfig.ts 파일 override 설정

외부로 분리된 경로 설정을 tsconfig.json에서 인식할 수 있도록 override 설정해준다.

//tsconfig.ts

"extends": "./tsconfig.paths.json"

4. craco.config.js 생성

루트 위치에 craco.config.js 파일을 생성하여 override 할 설정을 적용한다.

const path = require('path');

module.exports = {
  webpack: {
    alias: {
      '@src': path.resolve(__dirname, './src'),
      '@components': path.resolve(__dirname, './src/components'),
      '@pages': path.resolve(__dirname, './src/pages'),
      '@styles': path.resolve(__dirname, './src/styles')
    }
  }
};

5. package.json 수정

마지막으로 package.json의 스크립트를 react-scripts -> craco 로 수정한다. (*eject는 건들 필요 없다)

// package.json

"scripts": {
    "start": "craco start",
    "build": "craco build",
    "test": "craco test",
    "eject": "react-scripts eject"
}

위 과정을 완료한 후 npm run start를 실행하면 아래와 같이 절대경로로 파일을 import 해올 수 있다.

import { Hello } from '@components/Hello';
import { World } from '@pages/World';

*개발서버가 실행 중인 상황에서는 즉각적으로 반영되지 않는다. 종료 후 서버를 재실행시키면 적용될 것이다!

MVVM 패턴의 ViewModel 레이어에 해당하는 화면(View)단 라이브러리

✨Vue의 핵심 - Reactivity (반응성) -> 데이터가 바뀌면 변화를 감지하고 알아서 화면에 반영함

1. 뷰 인스턴스(instance)

인스턴스는 뷰로 화면을 개발하기 위한 생성 단위이다.

Vue를 생성자라고 함 → 필요한 모든 기능을 생성자에 미리 정의해 놓고 사용자가 그 기능을 재정의하여 편리하게 사용하기 때문

인스턴스 생성 방법

 new Vue();

인스턴스 속성

new Vue({
  el: ,
  template: ,
  data: ,
  methods: ,
  created: ,
  watch: ,
});

• el : 인스턴스가 그려지는 화면의 시작점 (특정 HTML 태그)
• template : 화면에 표시할 요소 ( HTML, CSS 등)
• data : 뷰의 반응성(Reactivity)이 반영된 데이터 속성
• method : 화면의 동작과 이벤트 로직을 제어하는 메서드
• created : 뷰의 라이프 사이틀과 관련된 속성
• watch : data에서 정의한 속성이 변화했을 때 추가 동작을 수행할 수 있게 정의하는 속성

var vm = new Vue({
  // body 태그 안에서#app을 찾아 해당 인스턴스를 붙이겠다는 의미
  // el을 정의하지 않으면 속성들을 정의하더라도#app에서 사용할 수 없음
  // 즉, 무조건 el을 특정 태그에 붙여줘야만 사용 가능
  el : '#app'
});

2. 템플릿 문법

2-1. 데이터 바인딩

뷰 인스턴스에서 정의한 속성들을 화면에 표시하는 방법. 콧수염 괄호 {{ }}

<div>{{ message }}</div>

new Vue({
    data: {
        message: 'Hello World';
    }
})

2-2. 디렉티브

화면 요소를 조작하기 위한 문법.

• v-text → 자바스크립트 innerText

<span v-text="msg"></span>
<!-- 같은 방법 -->
<span>{{msg}}</span>

• v-html → 자바스크립트 innerHTML

<div v-html="html"></div>

• v-if → 조건부 렌더링
• v-else
• v-else-if

<!-- v-if - loading이 참일 때 보임 -->
<div v-if="loading">Loading...</div>

<!-- v-else - loading이 거짓일 때 보임 -->
<div v-else>test user has been logged in</div>

new Vue({
    data: {
        loading: false
    }
})

• v-show v-if와 비슷하게 조건에 따라 엘리먼트 표시

<div v-show="loading">Loading...</div>

new Vue({
    data: {
        loading: true
    }
})

• v-if와 v-show의 차이 v-show를 엘리먼트는 항상 렌더링 되어 DOM에 남아있다. 즉, v-show는 단순히 display 속성(display:none)을 변경하는 것이고, v-if는 조건에 따라 실제로 돔을 제거하고 생성한다.

• v-for 데이터 속성의 개수만큼 화면의 요소를 반복하여 출력

<ul>
  <li v-for="(item,i) in items">{{ item }}</li>
</ul>

new  Vue({
    data: {
        items: ['Home', 'About', 'Login']
    }
})

• v-bind 동적으로 엘리먼트 속성 설정

<div v-bind:속성="사용할 속성명(data)"></div>

🍀예시

<!-- id, class 바인딩 -->
<p v-bind:id="uuid" v-bind:class="name">{{number}}</p>

<script>
  new Vue({
    el: "#app",
    data: {
      uuid: "abc123",
      name: "text-blue",
    },
  });
</script>

• v-on 이벤트 처리

<button v-on:이벤트 이름="실행할 메소드"></button>

🍀예시

<!-- 클릭할 때마다 이벤트 실행 -->
<button v-on:click="logText">Click Me!</button>
<!-- 키보드를 누를 때마다 이벤트 실행 -->
<input type="text" v-on:keypress="logText" />
<!-- 엔터키를 누를 때마다 이벤트 실행 -->
<input type="text" v-on:keypress.enter="logText" />

<script>
  new Vue({
    el: "#app",
    methods: {
      // 이벤트 함수
      logText: function () {
        console.log("clicked");
      },
    },
  });
</script>

*v-on:이벤트이름.prevent - 이벤트 새로고침 막기 (event.preventDefault()와 동일)

• v-model input 값 구하기

<input type="text" v-model="message" />
<p>{{message}}</p>

<script>
  new Vue({
    el: "#app",
    data: {
            // input 값이 바뀔 때마다 자동으로 message가 변경됨
      message: "",
    },
  });
</script>

2-3. this

인스턴스 안의 메서드에서 사용되는 this는 해당 인스턴스를 가리킨다.

→ 객체에 속한 메서드에서 사용될 때 this가 해당 메서드를 호출한 객체를 가리키는 것과 비슷한 관점에서 바라보면 됨

2-4. computed 속성

간단한 연산 수행 → data가 변경되면 연산 수행

computed 속성은 반응형(reactive) 종속성에 기반하여 캐시된다

<script>
new Vue({ 
  el: "#app",
  data: {
    number: 100,
  },
  // number의 값이 바뀌면 doubleNum도 같이 바뀜
  computed: {
    doubleNum: function () {
      return this.number * 2;
    },
  },
});
</script>

2-5. watch 속성

매번 실행되기 부담스러운 무거운 로직 (ex. 데이터 요청)

<script>
  new Vue({
    el: "#app",
    data: {
      num: 10,
    },
    // watch - 데이터의 변화에 따라 특정 로직을 실행
    watch: {
      num: function () {
        this.logText();
      },
    },
    methods: {
      addNum: function () {
        this.num++;
      },
      logText: function () {
        console.log(`${this.num} changed`);
      },
    },
  });
</script>

*왠만하면 watch보다는 computed를 사용하는걸 추천

3. 뷰 컴포넌트

컴포넌트는 화면의 영역을 구분하여 개발할 수 있는 뷰의 기능이다. 컴포넌트 기반으로 화면을 개발하게 되면 코드의 재사용성이 올라가고 빠르게 화면을 제작할 수 있다.

컴포넌트는 전역 컴포넌트와 지역 컴포넌트로 구분하여 생성할 수 있다.

• 전역 컴포넌트는 인스턴스를 생성할 때마다 따로 등록할 필요 없이 모든 인스턴스에서 사용 가능
• 지역 컴포넌트는 해당 인스턴스 내에서만 사용 가능, 인스턴스마다 새로 생성해야 함

전역 컴포넌트 생성 방법

Vue.component('컴포넌트 이름', {
  // 컴포넌트 내용
});

지역 컴포넌트 생성 방법

new Vue({
  el: "#app", // #app에서만 사용할 수 있는 지역 컴포넌트
  components: {
    // '컴포넌트 이름' : { 컴포넌트 내용 },
  }
});

🍀예시

// 표시
<div id="app">
  <app-header></app-header>
</div>

// 생성
Vue.component("app-header", {
  template: "<h1>Header</h1>",
});

4. 컴포넌트간의 통신 방식

상위에서 하위로는 데이터를 내려주고, 하위에서 상위로는 이벤트를 올려준다.

• 하위 컴포넌트 → (이벤트 발생) → 상위 컴포넌트
• 상위 컴포넌트 → (props 전달) → 하위 컴포넌트

4-1. props (상위→하위)

props에도 Reactivity가 반영된다.

props 사용 방식

// 하위 컴포넌트의 내용
var childComponent = {
  props: ['프롭스 속성 명']
}

<!-- 상위 컴포넌트의 템플릿 -->
<div id="app">
  <child-component v-bind:프롭스 속성 명="상위 컴포넌트의 data 속성"></child-component>
</div>

🍀예시

<div id="app">
    <app-header v-bind:propsData="message"></app-header>
</div>

<script>
  // 컴포넌트를 분리하여 작성하고 등록하는 방식으로 가독성을 높임
  var appHeader = {
    template: "<h1>{{ propsData }}</h1>",
    props: ["propsData"], // props 속성 이름 지정
  };

  new Vue({
    el: "#app",
    components: {
      "app-header": appHeader,
    }
    data: {
      message: "hi",
    },
  });
</script>

4-2. 이벤트 (하위→상위)

// 하위 컴포넌트의 내용
this.$emit('이벤트 명');

<!-- 상위 컴포넌트의 템플릿 -->
<div id="app">
  <child-component v-on:하위 컴포넌트에서 발생한 이벤트 명="상위 컴포넌트의 실행할 메서드 이름"></child-component>
</div>

🍀예시

<div id="app">
    <app-header v-on:pass="logText"></app-header>
</div>

<script>
  var appHeader = {
    template: "<button v-on:click='passEvent'>Click Me</button>",
    methods: {
      passEvent: function () {
        this.$emit("pass");  // 이벤트 명
      },
    },
  };

  new Vue({
    el: "#app",
    components: {
      "app-header": appHeader,
    },
    methods: {
            // 이벤트 발생시 실행할 메서
      logText: function () {
        console.log("hi");
      },
    },
  });
</script>

4-3. 같은 레벨의 컴포넌트 간의 통신 방식

이벤트로 Root로 전달하고 Root에서 props로 전달

var appContent = {
  template:
    "<div>content<button v-on:click='passNum'>pass</button></div>",
  methods: {
    passNum: function () {
      // 10을 같은 레벨인 appHeader에 전달하기 위해서
      // 먼저 Root로 올려 전달하고 Root에서 appHeader로 내려 전달하는 방식
      // 상위로 올릴 때는 event 내릴 때는 props
      this.$emit("pass", 10);
    },
  },
};

5. 뷰 라우터

뷰 라우터는 뷰 라이브러리를 이용하여 SPA를 구현할 때 사용하는 라이브러리이다.

설치 방법

• CDN

  <script src="https://unpkg.com/vue-router@3.5.3/dist/vue-router.js">

• NPM

  npm install vue-router

라우터 인스턴스 생성

// 라우터 인스턴스 생성
var router = new VueRouter({
  // 라우터 옵션
})

// 인스턴스에 라우터 등록
new Vue({
  router: router
})

라우터 옵션

• routes : 페이지의 라우팅 정보 (라우팅할 url과 컴포넌트)
  • path : 페이지의 url
  • component : 해당 url에서 표시될 컴포넌트
• mode : URL의 해쉬 값(#) 제거 속성

router-view

url에 따라 해당하는 컴포넌트를 보여주는 태그로 뷰 인스턴스에 라우터를 연결해야 사용 가능하다.

<router-view></router-view>

router-link

특정 url로 이동시켜주는 태그로 html a태그와 같은 역할을 한다.

<router-link to="이동할 url"></router-link>

<div id="app">
  <div>
    <!-- 특정 페이지로 이동시켜줌 -->
    <router-link to="/login">Login</router-link>
    <router-link to="/home">Home</router-link>
  </div>
    <!-- url에 따라 해당 하는 컴포넌트를 보여줌 -->
  <router-view></router-view>
</div>

<script src="https://cdn.jsdelivr.net/npm/vue@2/dist/vue.js"></script>
<!-- CDN vue-router -->
<script src="https://unpkg.com/vue-router@3.5.3/dist/vue-router.js"></script>

<script>
var LoginComponent = {
  template: "<div>login</div>",
};
var HomeComponent = {
  template: "<div>home</div>",
};

new VueRouter({
  mode: 'history',  // url 해시값 제거
  routes: [
        // '/login'에서 LoginComponent 컴포넌트 표시
    { path: '/login', component: LoginComponent },
        // '/home'에서 HomeComponent 컴포넌트 표시
    { path: '/home', component: HomeComponent }
  ]
})

new Vue({
    // 인스턴스에 라우터 연결
    router: router,
  });
</script>

6. Vue CLI

CLI (Command Line Interface) : 명령어를 통해 특정 액션을 실행하는 도구.

프로젝트 생성

vue create '프로젝트 폴더 위치'

프로젝트 실행

npm run serve

7. 싱글 파일 컴포넌트

파일 구조

<template>
<!-- HTML -->
</template>

<script>
// Javascript - 인스턴스 속성들
</script>

<style>
/* css */
</style>

*템플릿 루트는 무조건 하나여야 한다. -> 전체 태그를 하나의 태그가 감싸고 있어야 함

*파스칼 케이스로 네이밍 + 최소 두단어 이상으로 조합

참고 자료 📝 Vue.js 시작하기 - Age of Vue.js 강의 📝 Cracking Vue.js

8월 말부터 취준을 시작하여 감사하게도 한 달만에 취업이 되었다. 한 달 동안 면접을 보러 다니면서 느낀 점은 질문 내용이 다 비슷해서 단골 질문 리스트만 잘 공부해가면 기술 면접은 문제 없다는 것이었다. 그래서 내가 면접 대비하면서 공부하고 실제로 받았던 질문 리스트를 올려보려고 한다. 이 글이 누군가에게는 도움이 되길...!🍀

1. 기술면접💻

1. CS

1. 브라우저 렌더링 원리를 설명해보세요. ⭐⭐

2. 주소창에 www.google.com 을 입력하면 생기는 일을 설명해주세요.

3. 웹 프로토콜이란?

4. HTTP와 HTTPS의 차이점을 말해주세요.

5. RESTFUL API란? ⭐

6. get, post 차이를 설명해주세요. ⭐⭐

7. 브라우저 저장소 (로컬 스토리지, 세션 스토리지, 쿠키의 차이) ⭐⭐⭐

8. JWT란?

9. CORS란?

10. MVC와 MVVM 패턴의 차이를 설명해주세요. ⭐

11. OOP (Object Oriented Programming)란 무엇인가요? ⭐⭐

12. CSR과 SSR의 차이를 설명해주세요. ⭐

13. SPA와 MPA의 차이를 설명해주세요. ⭐

14. Git을 사용해보셨나요? Git에 대해 아는 것을 말해보세요. ⭐

15. 웹팩과 바벨이 무엇인가요?

16. 깊은복사와 얕은복사의 차이점을 말해주세요.

17. 크로스 브라우징이란?

18. Sementic HTML란 무엇인가요?

19. 라이브러리와 프레임워크에 대해 설명해주세요.

2. JavaScript

19. 실행 컨텍스트가 무엇인가요? ⭐⭐⭐

20. 호이스팅에 대해 설명해주세요. ⭐⭐⭐

21. 클로저와 스코프에 대해 설명해주세요. ⭐⭐⭐

22. 화살표 함수와 일반함수의 차이를 설명해보세요.

23. this에 대해 아는대로 설명해보세요.

24. call( ), apply( ), bind( )의 차이점을 말해주세요.

25. 자바스크립트 비동기 처리(callback, promise, async/await)에 대해 설명해주세요 ⭐⭐⭐ -> promise와 async/await의 차이점을 설명해주세요.

26. 이벤트 루프가 무엇인가요?

27. 마이크로태스크 큐와 태스크 큐의 차이점을 아시나요?

28. Promise와 setTimeout 우선 순위에 대해 말해주세요.

29. 이벤트 버블링과 캡쳐링이란 무엇인가요?

30. event.target과 event.currentTarget의 차이점을 말해주세요.

31. var, let, const의 차이점을 말해주세요. ⭐⭐

32. 자바스크립트의 원시타입에 대해 설명해주세요.

33. ES6 문법 아는 것이 있다면 말해주세요.

34. forEach( )와 Map( )의 차이가 무엇인가요?

35. Sass/Scss/css-in-js를 사용해보셨나요? (혹은 차이점을 말해주세요)

36. AJAX란?

37. HTML이 렌더링 중에 자바스크립트가 실행되면 렌더링이 멈추는 이유를 설명해주세요.

38. package.json에서 dependencies와 devDependencies의 차이점을 말해주세요.

39. 타입스크립트를 써보신 경험이 있나요? 타입스트립트에 대해서 어떻게 생각하시나요? ⭐

3. React

44. React에 대해 아는대로 말씀해주세요. (원리, 특징, 장단점)

45. Virtual DOM이란? Virtual DOM을 사용하는 이유는 무엇인가요? ⭐⭐

46. props와 state에 대해 설명해주세요. ⭐⭐

47. React Hook이 무엇인가요?

48. JSX란?

49. React 라이프사이클에 대해서 설명해주세요. ⭐

50. useMemo와 useCallback의 차이점을 말해주세요.

51. Class와 Hooks의 차이를 아시나요?

52. 전역상태관리 툴을 사용해보신 경험이 있나요? 있다면 말씀해주세요.

2. 인성면접🤔

1. 자기소개 부탁드립니다.

2. 왜 개발자가 되고 싶은가요?(전업했다면 그 이유), 개발자는 어떤 직업이라고 생각하나요?

3. 본인이 생각하는 본인의 성격 장단점은 무엇인가요?

4. 왜 굳이 프론트엔드를 선택했나요? 프론트엔드란 어떤 분야인가요?

5. 개발자로서 중요하게 생각하는 점이 있다면 무엇인가요?

6. 개발은 평생 공부해야하는 분야인데 어떤 식으로 학습을 하고 있나요? 본인만의 학습법이 있다면?

7. 개발자로서 목표가 무엇인가요? 혹은 본인의 인생의 목표가 무엇인가요?

8. 최근 공부해보고 싶은 기술이 있다면 무엇이 있을까요?

9. 스트레스 관리는 어떻게 하시나요?

10. 프론트엔드는 기술이 빠르게 변화하는 데 두려워하진 않나요?

11. 프로젝트를 진행하면서 어려웠던 점과 어떻게 극복했는지 말해주세요.

12. 마지막으로 회사에 궁금한 점 혹은 하고 싶은 말

자바스크립트에서의 데이터 타입은 원시값과 참조값으로 구분한다.

• 원시 타입(Primitive Type): String, Number, Boolean, Null, Undefined, Symbol
• 객체 타입(Reference Type): Array, Object, Function

원시값은 읽기 전용으로 변경 불가능한 값이다. 원시 값을 할당한 변수는 원시 값 자체를 값으로 갖는다.

여기서 변경 불가능한 값은 변수에 재할당이 불가능하단 의미가 아니라, 메모리에 올라간 값이 변경되지 않는다는 의미이다. 원시값이 변수에 저장될 때에는 메모리 공간이 확보되어 그 공간에 값이 저장되고 변수는 그 주소를 참조한다. 재할당도 마찬가지로 새로운 메모리 공간을 확보하여 값을 저장하고 변수가 참조하던 기존 주소를 새로 할당한 값의 주소로 변경하는 것이다. 즉, 값이 직접 변경되는 것이 아닌 참조하는 메모리 공간의 주소가 변경되는 것이다.

참조값은 변경 가능한 값이다. 참조 값을 변수에 할당하면 변수에는 참조 값이 저장된다. 실제 객체의 값은 별도의 메모리 공간에 저장되며 변수는 그 공간을 참조하는 주소를 값으로 갖는다. 즉, 참조값은 생성된 객체가 저장된 메모리 공간의 주소를 의미한다. 참조값은 재할당 없이 직접적으로 객체에 접근하여 프로퍼티를 동적으로 추가, 갱신, 삭제가 가능하다. 이것이 변경 가능한 값의 의미이다.

원시 타입과 참조 타입은 값을 복사할 때에도 큰 차이가 있다. 원시 타입은 값이 복사되어 전달되며, 이것을 값에 의한 전달이라고 한다. 반면, 참조 타입은 실제 값이 아닌 참조값이 전달되며, 이것을 참조에 의한 전달이라고 한다.

요약

원시값은 변경 불가능한 값으로 원시값이 변수에 저장될 때에는 메모리 공간이 확보되어 그 공간에 값이 저장되고 변수는 그 주소를 참조한다. 재할당을 하게되면 값이 직접 변경되는 것이 아닌 참조하는 메모리 공간의 주소가 변경된다.

참조값은 변경 가능한 값으로 참조 값을 변수에 할당하면 실제 객체의 값은 별도의 메모리 공간에 저장되며 변수는 그 공간을 참조하는 주소를 값으로 갖는다. 참조값은 직접적으로 객체에 접근하여 추가, 갱신, 삭제가 가능하다.

2. 얕은 복사와 깊은 복사

원시 타입의 값은 새로운 메모리 공간에 독립적인 값을 저장하기 때문에 깊은 복사가 되고 참조 타입값은 얕은 복사가 된다.

즉, 얕은 복사는 '메모리 주소 값'을 복사한 것이다. 반대로 깊은 복사는 새로운 메모리 공간을 확보해 완전히 복사하는 것이다.

2-1. 얕은 복사

얕은 복사(Shallow Copy)란 객체를 복사할 때 원본 값과 복사된 값이 같은 참조(=메모리 주소)를 가리키고 있는 것을 말한다. 객체 안에 객체가 있을 경우 한 개의 객체라도 원본 객체를 참조하고 있다면 이를 얕은 복사라고 한다.

아래와 같이 일반적인 복사의 경우 참조에 의한 할당이 이루어지므로 둘은 같은 주소를 참조하게 된다. 즉, 똑같은 데이터가 하나 더 생성되는 것이 아니라, 해당 데이터의 메모리 주소를 복사함으로써 한 데이터를 같이 공유하는 것이다. 이와 같은 경우를 얕은 복사라고 한다.

얕은 복사의 경우 서로 같은 참조를 가리키기 때문에 복사 후에 객체를 수정하면 기존 객체에도 영향을 끼친다.

const obj1 = { a: "a", b: "a", c: "c"};
const obj2 = obj1;

// 원본 객체(obj1)와 복사 객체(obj2)가 서로 같은 참조를 가리킴
console.log( obj1 === obj2 );  // true

obj2.a = "apple";  // 복사한 객체 수정

// 원본 객체에도 영향을 미침 둘 다 값이 바뀜
console.log(obj1);  // { a: "apple", b: "a", c: "c"}
console.log(obj2);  // { a: "apple", b: "a", c: "c"}

Object.assign(), spread 연산자{...obj}는 객체 자체는 깊은 복사가 수행되지만, 2차원 이상의 객체는 얕은 복사가 수행된다. 아래와 같이 객체 자체는 서로 다른 주소를 참조하고 있는 깊은 복사가 이루어지지만 내부의 객체는 같은 주소를 참조한다.

let origin = {
    a: "a",
    b: { c: "c" }
};

// Object.assign()을 활용한 복사
let copyAssign = Object.assign({}, origin);
// 전개 구문을 활용한 복사
let copySpread = {...origin}

// 복사한 객체 수정
copyAssign.b.c = "cat"
copySpread.b.c = "cat"

// 객체 자체는 깊은 복사가 되어 서로 다른 주소를 참조함
console.log(origin === copyAssign) // false
console.log(origin === copySpread) // false
// 하지만 2차원 이상의 객체는 얕은 복사가 수행되어 같은 주소를 참조함
console.log(origin.b.c === copyAssign.b.c) // true
console.log(origin.b.c === copySpread.b.c) // true

2-2. 깊은 복사

깊은 복사(Deep Copy)는 복사된 객체가 다른 주소를 참조하며 내부의 값만 복사된다. 객체 안에 객체가 있을 경우에도 원본과의 참조가 완전히 끊어졌다면 이를 깊은 복사라고 한다.

JSON.stringify()는 객체를 json 문자열로 변환하는데 이 과정에서 원본 객체와의 참조가 모두 끊어진다. 객체를 json 문자열로 변환 후, JSON.parse()를 이용해 다시 원래 객체(자바스크립트 객체)로 만들어준다.

const obj1 = {
  a: "a",
  b: {
    c: "c",
  },
};

const obj2 = JSON.parse(JSON.stringify(obj1));

obj2.b.c = "cat";

console.log(obj1); // { a: "a", b: { c: "c" } }
console.log(obj1.b.c === obj2.b.c); // false

커스텀 재귀 함수를 구현하면 깊은 복사를 할 수 있다.

let origin = {
    a: 1,
    b: { c: 2 }
};

function isCopyObj(origin) {
    let res = {};

    for (let key in origin) {
      if (typeof origin[key] === 'object') {
          res[key] = isCopyObj(obj[key]);
      } else {
          res[key] = origin[key];
      }
    }

    return res;
}

let copy = isCopyObj(origin);

copy.b.c = 3
console.log(origin.b.c === copy.b.c) //false

요약

얕은 복사(Shallow Copy)란 객체를 복사할 때 원본 값과 복사된 값이 같은 참조(=메모리 주소)를 가리키고 있는 것을 말한다. 객체 안에 객체가 있을 경우 한 개의 객체라도 원본 객체를 참조하고 있다면 이를 얕은 복사라고 한다.

깊은 복사(Deep Copy)는 복사된 객체가 다른 주소를 참조하며 내부의 값만 복사된다. 객체 안에 객체가 있을 경우에도 원본과의 참조가 완전히 끊어졌다면 이를 깊은 복사라고 한다.

참고 자료 📝 [JavaScript] - 원시 값과 참조 값 📝 [JS] 참조 타입의 얕은 복사와 깊은 복사(Shallow Copy & Deep copy)

1-1. CSR

CSR(Client Side Rendering)은 렌더링이 클라이언트 측에서 발생한다.

CSR은 유저가 웹사이트에 방문하면 브라우저가 서버에 콘텐츠를 요청하고 서버는 빈 뼈대만 있는 html을 응답으로 보내준다. 이 때문에 처음에 접속하면 빈 화면만 보인다는 문제점이 있다. 이 후 브라우저는 링크된 js 파일을 서버로부터 다운받게 된다. 이 js 파일 안에는 어플리케이션을 구동하는 라이브러리와 프레임워크의 소스 코드까지 모두 포함되어 있기 때문에 시간이 오래 걸릴 수도 있다. 이러한 과정을 거쳐 동적으로 페이지를 띄워주게 된다.

첫 로딩 시 다운로드 받아야 할 파일이 많아 사용자가 첫 화면을 보기 까지 시간이 오래 걸린다. 하지만 이후에는 필요한 데이터만 서버에 요청하기 때문에 나머지 속도는 빠르며, 서버 성능에도 무리가 가지 않는다.

CSR은 html 내용이 아래와 같이 텅 비어있기 때문에 검색엔진최적화(SEO)가 불리하다. 검색 엔진이 색인할 만한 컨텐츠가 존재하지 않기 때문이다.

<body>
  <div id="root"></div>
  <script src="app.js"></script>
</body>

1-2. SSR

SSR(Server Side Rendering)은 서버에서 렌더링을 마치고 클라이언트로 전달하는 방식이다.

SSR은 유저가 웹사이트에 방문하면 브라우저가 서버에 콘텐츠를 요청한다. 서버에서 필요한 데이터를 모두 가져와서 렌더링 준비를 마친 html과 js를 전달한다. 클라이언트 상에서는 잘 만들어진 html 파일을 받아와서 바로 화면에 띄운다. 때문에 사용자가 첫 화면 빠르게 볼 수 있지만, 동적으로 데이터를 처리하는 js 로직과 연결될 때까지 사용자의 입력에 반응이 없을 수도 있다.

첫 로딩 속도는 빠르지만 나머지 로딩 시에도 동일한 과정을 거치기 때문에 나머지 로딩 속도가 느리고 화면 깜박임 문제가 존재한다. 또한, 사용자가 클릭을 할 때마다 서버에 요청을 해야하므로 서버 과부하에 걸리기 쉽다. 또한, 모든 컨텐츠가 html 파일에 담겨져 있기 때문에 검색엔진최적화(SEO)가 유리하다.

요약

CSR은 렌더링이 클라이언트 측에서 발생한다. 첫 로딩시 모든 정적 파일을 다운로드 받아야하기 때문에 첫 로딩 속도는 느리지만 이후 나머지 로딩은 빠르다. 필요한 데이터만 서버에 요청하기 때문에 서버 성능에도 무리가 가지 않는다. 다만 SEO에 불리하다.

SSR은 서버에서 렌더링을 마치고 클라이언트로 전달하는 방식이다. 첫 로딩 속도는 빠르지만 나머지 로딩 시에도 동일한 과정을 거치기 때문에 나머지 로딩 속도가 느리다. 사용자가 클릭을 할 때마다 서버에 요청을 해야하므로 서버 과부하에 걸리기 쉽다. 다만 SEO에 유리하다.

2. SPA와 MPA

2-1. SPA

SPA(Single Page Application)는 한 개(Single)의 Page로 구성된 Application이다.

SPA는 웹 에플리케이션에 필요한 모든 정적 리소스(HTML, CSS, JavaScript)를 첫 로딩 시 한 번에 다운로드한다. 그 이후 다른 페이지 요청이 있을 때, 페이지 갱신에 필요한 데이터만 전달 받아서 페이지를 갱신한다. 즉, 첫 로딩 시 페이지를 받아온 이후에는 페이지 새로고침 없이 필요한 부분만 수정하는 것이다. 따라서, SPA는 CSR(Client Side Rendering) 방식을 채택하고 있는 것이다.

SPA 특징

• 페이지 전체를 새로고침하지 않기 때문에 페이지 이동 시 깜빡임이 없고 자연스러운 사용자 경험을 제공할 수 있다.
• 첫 로딩 시 필요한 모든 파일을 다운로드 해야하기 때문에 첫 로딩 속도가 느리다.
• 첫 로딩 이후 페이지 이동 등의 나머지 로딩 시에는 이미 필요한 파일을 모두 다운로드 받은 상태이므로 나머지 로딩 속도가 빠르다.
• 데이터 요청이 있을 때만 서버에 요청하기 때문에 서버에 부담이 적다.
• html 파일에 검색 엔진이 색인할 컨텐츠가 없어 검색엔진최적화(SEO)가 불리하다.

2-2. MPA

MPA(Multiple Page Application)는 여러 개(Single)의 Page로 구성된 Application이다.

MPA는 페이지를 요청할 때마다 서버에서 렌더링 된 정적 리소스(HTML, CSS, JavaScript)를 매번 다운로드한다. 즉, 첫 로딩 시에나 다른 페이지로 이동 시에나 동일하게 서버로부터 완전한 페이지를 받아오는 것이다. 따라서, MPA는 SSR(Server Side Rendering) 방식을 채택하고 있는 것이다.

MPA 특징

• 페이지 이동이 발생할 때마다 전체 페이지의 새로고침이 발생하기 때문에 화면 깜빡임이 존재한다.
• 서버에서 이미 렌더링을 마친 상태로 전달받기 때문에 첫 로딩 시에 다운로드 받을 파일이 많지 않아 첫 로딩 속도가 빠르다.
• JS 파일을 모두 다운로드하고 적용하기 전까지는 각각의 기능이 동작하지 않는다.
• 첫 로딩 이후 페이지 이동 등의 나머지 로딩 시에도 첫 로딩과 동일한 로딩 과정을 거쳐야하기 때문에 나머지 로딩 속도가 느리다.
• 매번 서버에 요청을 하기 때문에 서버에 부담이 갈 수 있다.
• 서버로부터 완성된 형태의 HTML파일을 전달 받기 때문에 검색 엔진이 페이지를 크롤링하기에 적합하여 검색엔진최적화(SEO)에 유리하다.

요약

SPA는 한 개의 Page로 구성된 Application이다. 첫 로딩 시 웹 에플리케이션에 필요한 모든 정적 리소스를 한 번에 다운로드하며, 다른 페이지 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달 받아서 페이지를 갱신한다. 일반적으로 CSR 방식을 채택하고 있다.

MPA는 여러 개의 Page로 구성된 Application이다. 페이지를 요청할 때마다 서버에서 렌더링 된 정적 리소스를 매번 다운로드하며 매번 전체 페이지가 재렌더링 된다. 일반적으로 SSR 방식을 채택하고 있다.

this는 자신이 속한 객체 또는 자신이 생성할 인스턴스를 가리키는 자기 참조 변수이다. this를 통해 자신이 속한 객체 또는 자신이 생성할 인스턴스의 프로퍼티나 메서드를 참조할 수 있다. 자바스크립트의 this는 호출에 따라 달라진다.

1-1. 기본 바인딩 (전역, 함수 안에서 사용)

this를 단독 호출하거나 함수 안에서 호출하면 전역 객체(global object)에 바인딩된다. 브라우저에서 호출하는 경우 [object Window]가 된다. (엄격모드라면 undefined)

1-2. 암시적 바인딩 (메서드 안에서 사용)

this를 메서드 안에서 호출하면 해당 메서드를 호출한 객체로 바인딩된다. * 메서드: 어떤 객체의 프로퍼티에 할당된 함수

1-3.명시적 바인딩 (call(), apply(), bind())

자바스크립트의 함수 프로토타입 메서드인 call(), apply(), bind() 중 하나를 호출하여 this 바인딩을 코드에서 명시하면 this는 직접 명시한 객체에 바인딩된다. 단 bind 메서드는 새로운 함수를 반환하지만 call, apply 메서드는 그 자리에서 함수를 호출한다는 차이점이 있다.

1-4. 화살표 함수

위에서 본 this 바인딩은 함수가 호출되는 시점에 발생하는 동적 바인딩이지만, 화살표 함수는 정적 바인딩이다. 즉, 함수가 선언된 순간 코드상으로 바로 바깥쪽에 있는 스코프의 this를 사용한다.

요약

this는 자신이 속한 객체 또는 자신이 생성할 인스턴스를 가리키는 자기 참조 변수이다. 자바스크립트의 this는 호출에 따라 결정된다. 전역범위나 함수에서 사용될 때 this는 전역객체를 가르킨다. 객체에 속한 메서드에서 사용될때 this는 해당 메서드를 호출한 객체를 가르킨다. 객체에 속한 메서드의 내부함수에서 사용될땐 전역객체를 가르킨다. call(), apply(), bind()를 사용하면 this는 직접 명시한 객체를 가리킨다.

2. CORS

CORS(Cross Origin Resource Sharing)란 도메인이 다른 자원에 리소스를 요청할 때 접근 권한을 부여하는 메커니즘이다. 즉, 무분별하게 클라이언트가 다른 리소스에 접근하는 것을 막는 보안 이슈이다.

쉽게 말하자면 친구의 물건을 쓰려면 친구가 제한하는 규약안에서 사용해야 하듯, 다른 도메인의 자원을 쓰려면 자원의 주인이 허락한 규약을 지켜야 하는 것이고 이러한 규약을 표준화한 것이 CORS 이다.

CORS는 도메인 혹은 포트가 다른 서버의 자원을 요청할 때 생긴다. 예를 들어, 클라이언트는 3000번 포트를, 서버는 5000번 포트를 사용하는 경우와 같이 처음 리소스를 요청했던 그 주소가 아니라면 차단한다. 해당 문제를 해결하려면 Access-Control-Allow-Origin를 세팅하거나 proxy를 사용하면 된다.

3. MVC, MVVM 패턴

3-1. MVC

MVC 패턴은 프로그램을 역할에 따라 Model, View, Controller로 분리하여 설계한 이키텍처 패턴이다.

• Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
• View : 사용자에게 보여지는 UI부분
• Controller : 사용자의 입력(Action)을 받고 처리하는 부분

MVC 패턴은 가장 단순한 패턴이며 널리 사용되지만, View와 Model간의 의존성이 높아 복잡성이 높아지고 유지보수가 어려워진다는 단점이 있다. 또한, View에서 데이터의 업데이트가 발생하면 그에 따라 연쇄적으로 업데이트가 발생한다. 즉, MVC 패턴은 데이터의 변경 사항을 신속하게 전파하기가 어렵다.

3-2. MVVM

MVVM 패턴은 각 구성 요소가 독립적으로 작성되고 테스트될 수 있도록 Model, View, ViewModel로 분리하여 설계한 아키텍처 패턴이다.

• Model : 앱에서 사용되는 데이터와 그 데이터를 처리하는 부분
• View : 사용자에서 보여지는 UI 부분
• View Model : View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터 처리를 하는 부분

MVVM 패턴은 MVC패턴과 달리 View와 Model 사이의 의존성이 없다. 또한 Command 패턴과 Data Binding을 사용하여 View와 ViewModel사이의 의존성 또한 없앤 패턴이다. 즉 각 구성요소의 의존성이 없고 독립적으로 작성된다. 그리고 중복되는 코드를 모듈화 하여 개발할 수 있다. 단, View Model의 설계가 쉽지 않다는 단점이 있다.

요약

MVC 패턴은 프로그램을 역할에 따라 Model, View, Controller로 분리하여 설계한 이키텍처 패턴이다. MVVM 패턴은 각 구성 요소가 독립적으로 작성되고 테스트될 수 있도록 Model, View, ViewModel로 분리하여 설계한 아키텍처 패턴이다.

MVC 패턴은 단순하고 직관적이지만, View와 Model 사이의 의존성으로 인해 어플리케이션이 커질수록 복잡해지고, 유지보수가 어렵다는 단점이 있다. MVVM 패턴은 View와 Model 사이의 의존성이 없고, View와 View Model사이의 의존성을 없어 각 구성요소가 독립적이다. 그러나 View Model의 설계가 쉽지 않다는 단점이 있다.

4. REST API

REST란 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다. REST란 HTTP URI를 통해 자원을 명시하고, HTTP Method (POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD OPERATION을 적용하는 것을 의미한다.

• REST의 구성 자원(Resource) - URL 행위(Verb) - Http Method 표현(Representations)

• REST의 특징 클라이언트-서버 구조(Client-Server) 무상태성(Stateless 캐시 처리 가능(Cacheable) 자체 표현 구조 (Self - descriptiveness) 계층화(Layered System) 인터페이스 일관성(Uniform Interface)

REST API는 'REST하게 클라이언트와 서버간에 데이터를 주고받는 방식'이다. REST API를 제공하는 웹 서비스를 RESTful 하다고 할 수 있다.

참고 자료 📑 [JS] 알쏭달쏭 자바스크립트 this 바인딩 📑 [JS] 자바스크립트에서의 this 📑 CORS란? 📑 Cors란 무엇인가? 📑 MVVM vs MVC, 장점과 단점 📑 RESTful API 이란

1. DOM 생성 렌더링 엔진은 HTML 문서를 파싱하여 HTML 문서에 있는 모든 것들로 DOM을 구성한다.

2. CSSOM 생성 렌더링 엔진은 DOM을 생성하다가 css 태그를 만나면 css를 파싱하고 CSSOM을 만든다. CSSOM은 DOM이 화면에 어떻게 표시될지를 알려주는 역할을 한다.

3. Render Tree 생성 DOM과 CSSOM을 결합하여 Render Tree를 생성한다. Render Tree는 화면에 표시되어야 할 모든 노드의 컨텐츠, 스타일 정도를 포함하는 트리이다. Render Tree는 DOM 트리의 루트(html)에서부터 각 노드를 순회하면서 각각의 맞는 CSSOM을 찾아서 규칙을 적용하여 생성된다. 참고로 화면에 표시되지 않는 노드는 렌더 트리에 포함되지 않는다. (<head>, <title>, <script> 등)

   ❗주의 display: none 은 눈에 보이지도 않고 공간을 차지하지도 않기 때문에 렌더 트리에 포함되지 않는다. visibility: hidden은 눈에 보이지는 않지만 공간을 차지하므로 렌더 트리에 포함된다.

4. Layout (Render Tree 배치) 기기의 뷰포트(viewport) 내에서 노드의 정확한 위치와 크기를 계산한다. css에서 상대적인 단위(%, em 등)를 사용한 부분은 뷰포트에 맞춰서 절대적인 px단위로 변환된다. 이렇게 레이아웃 과정에서 렌더링 엔진은 각 요소들이 어떻게 생겼고 어떻게 보여줘야 하는지 알게 된다.

5. Paint (Render Tree 그리기) 렌더 트리를 순회하면서 페인트 함수를 호출해 노드를 화면에 실제 픽셀로 그려지도록 표현한다. 이렇게 하면 최초 렌더링이 완료된다.

요약

① 렌더링 엔진은 HTML 문서를 파싱하고 DOM을 생성한다. ② css 태그를 만나면 css를 파싱하고 CSSOM을 만든다. ③ DOM과 CSSOM을 결합하여 Render Tree를 생성한다. ④ 뷰포트 내에서 노드의 정확한 위치와 크기를 계산하여 Render Tree를 배치한다. ⑤ Render Tree의 노드를 화면에 실제 픽셀로 그린다.

2. HTTP와 HTTPS

2-1. HTTP

HTTP(Hyper Text Transfer Protocol)는 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다. 즉, HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로, 80번 포트를 사용하고 있다. HTTP 서버가 80번 포트에서 요청을 기다리고 있으며, 클라이언트는 80번 포트로 요청을 보내게 된다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다. * HTTP는 1989년 팀 버너스 리(Tim Berners Lee)에 의해 처음 설계되었다.

그러나, HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이였기에 개인정보를 주고 받으면 제3자가 정보를 조회할 수 있는 문제점이 있었다. 이러한 문제를 해결하기 위해 등장한 것이 HTTPS이다.

2-1. HTTPS

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 SSL(Secure Socket Layer) 보안 소켓 계층을 이용하여 HTTP의 보안 문제를 해결하였다. 43번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원하고 있다.

HTTPS를 사용하면 검색엔진 최적화(SEO)에 있어서 유리하다. 그러나, 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느려진다는 단점이 있다. 또한 인증서를 발급하고 유지하기 위한 비용도 발생한다. 따라서, 상황에 맞게 HTTP와 HTTPS를 구분하여 사용하는 것이 옳은 방법이다.

요약

HTTP와 HTTPS의 가장 큰 차이점은 보안(SSL 인증서)이다. HTTP는 보안에 취약한 반면 HTTPS는 안전하게 데이터를 주고 받을 수 있다. 그러나, 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느리고 인증서를 발급하고 유지하기 위한 비용이 발생한다. 따라서, 개인 정보와 같은 중요한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 노출이 되어도 무관한 정보라면 HTTP를 이용해도 괜찮다.

3. 브라우저 저장소

먼저 쿠키와 세션을 사용하는 이유는 HTTP의 특성이자 약점을 보완하기 위해서이다.

HTTP 프로토콜 환경은 Connectionless, Stateless한 특성을 가지기 때문에 서버는 클라이언트가 누구인지 매번 확인해야한다. 이 특성을 보완하기 위해서 쿠키와 세션을 사용하는 것이다.

🔎Connectionless와 Stateless ⁕ Connectionless : 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징 ⁕ Stateless : 통신이 끝나면 상태정보를 유지하지 않는 특징 → 정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 다시 하는 등의 일이 발생할 수 있다.

3-1. Cookie🍪

쿠키(Cookie)는 클라이언트가 서버에 방문한 정보를 클라이언트 단에 저장하는 작은 파일이다. HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용할 수 있다.

쿠키는 매번 서버에 전송되므로 크기가 클 경우 서버에 부담이 갈 수 있다. 대부분의 브라우저가 지원하며, 저장 용량이 4KB로 작다. 만료 기간이 존재하며, 만료기간이 남아있다면 브라우저가 종료되어도 데이터가 보존된다. 보안이 취약하며, SameSite 옵션이 Strict가 아닌 경우, 다른 도메인에서 요청할 때도 자동 전송되는 위험성이 있다. (CSRF 취약)

• 쿠키의 동작 방식 ① 클라이언트가 페이지를 요청한다. (→ 사용자가 웹사이트에 접근) ② 웹 서버는 쿠키를 생성한다. ③ HTTP 헤더에 쿠키를 포함 시켜 응답한다. ④ 넘겨받은 쿠키는 클라이언트가 보관하고 있다가(로컬 PC에 저장) 다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다. (브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있는다.) ⑤ 동일 사이트 재방문 시 클라이언트의 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송한다.

3-2. Web Storage

웹 스토리지(Web Storage)는 클라이언트에 데이터를 저장할 수 있도록 HTML5부터 새롭게 지원하는 저장소이다. 데이터의 지속성에 따라 로컬 스토리지(Local Storage)와 세션 스토리지(Session Storage)로 나뉜다.

• 로컬 스토리지(Local Storage)는 데이터의 만료기간이 없으며 사용자가 데이터를 지우지 않은 한 영구적으로 보존된다. 사용자 설정 저장이나, 브라우저를 닫고 열었음에도 정보가 남아야 하는 것들을 저장할 때 사용한다. 즉, 자동 로그인을 할 때 사용한다.

• 세션 스토리지(Session Storage)는 브라우저를 종료하면(세션이 종료되면) 데이터를 삭제한다. 즉, 일회성 로그인을 할 때 사용한다.

HTML5부터 등장하였기 때문에 HTML5를 지원하지 않는 브라우저에서는 사용할 수 없다. 키(Key)와 값(Value)의 쌍 형태로 데이터를 저장하며, 단순 문자열을 넘어서 객체 정보 저장이 가능하다. 쿠키와 달리, 서버에 전송되지 않으므로 서버에 부담이 가지 않는다. 저장 용량이 5MB로 쿠키보다 크며, 만료 기간이 존재하지 않는다. 또한, 필요한 경우에만 꺼내 쓰는 것이므로 자동 전송의 위험성이 없다. 다른 오리진에서 요청하는 경우에는, 꺼내 쓰고 싶어도 오리진 단위로 접근이 제한되는 특성 덕분에 값을 꺼내 쓸 수 없다. (CSRF 안전)

• 세션의 동작 방식 ① 클라이언트가 페이지에 요청한다. (사용자가 웹사이트에 접근) ② 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인한다. ③ session-id가 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에게 돌려준다. ④ 서버에서 클라이언트로 돌려준 session-id를 쿠키를 사용해 서버에 저장한다. ⑤ 클라이언트는 재접속 시, 이 쿠키를 이용해 session-id 값을 서버에 전달

요약

쿠키는 클라이언트가 서버에 방문한 정보를 클라이언트 단에 저장하는 작은 파일이다. 모든 브라우저에서 지원하지만, 매번 서버에 전송이 되므로 서버에 부담이 갈 수 있다. 저장 용량이 작고 보안에 취약하다는 단점이 있다. 만료기간이 존재하며, 만료기간이 남아 있다면 브라우저가 종료되어도 데이터가 보존된다.

웹스토리지는 쿠키의 단점을 보완하여 HTML5부터 등장하였다. 웹 스토리지는 클라이언트에 저장만 할 뿐 서버로 전송되지는 않으므로 서버에 부담이 없다. 쿠키보다 저장용량이 크며, 만료기간이 존재하지 않는다. 또한, 단순 문자열을 넘어서 객체 정보 저장이 가능하며, 데이터의 지속성에 따라 로컬 스토리지와 세션 스토리지로 나뉜다.

로컬 스토리지는 브라우저 자체에 반영구적으로 저장되며 브라우저가 종료되어도 데이터가 유지된다. 세션 스토리지는 탭 윈도우 단위로 생성되며, 탭 윈도우를 닫을 때 데이터가 삭제된다.

4. JWT

앞서 말한 HTTP의 특성(Connectionless, Stateless)으로 인해 쿠키, 세션 외에도 JWT 인증 방식을 사용한다.

JWT(Json Web Token) 모바일이나 웹의 사용자 인증을 위해 사용하는 암호화된 토큰을 의미한다. JWT 정보를 request에 담아 사용자응 정보 열람, 수정 등 개인적인 작업 등을 수행할 수 있게한다.

• JWT 구성요소 Header(헤더) : JWT 토큰을 어떻게 해석해야 하는지를 알려주는 부분으로, 토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있다. Payload(내용) : 토큰에 담을 정보로, 정보의 한조각을 클레임(claim)이라고 부른다. 클레임은 name/value의 한 쌍으로 구성된다. 클레임의 종류는 등록된(registered)클레임, 공개(public)클레임, 비공개(private)클레임 이 있다. Signature(서명) : 누군가 JWT를 탈취하여 위변조 했는지 검증하기 위한 부분으로, 헤더의 인코딩 값과 정보의 인코딩 값을 합친 후 비밀키로 해쉬를 하여 생성한다.
  JWT는 .을 구분자로 하여 위 3가지 문자열로 구성된다. Header와 Payload는 암호화 한 것이 아니라 단순히 JSON 문자열을 base64로 인코딩한 것이다. 따라서 디코딩하면 평문으로 해독이 가능하기 때문에 민감한 정보를 넣으면 안된다. 그러나 Signature는 복호화할 수 없다.

JWT을 사용하면 토큰 값만 알고 있다면 어떤 서버로 요청이 들어가던 상관이 없다. 즉, 별도의 저장소(세션스토리지)에 정보를 저장해 둘 필요가 없다. 이러한 이유로 CORS 문제도 해결된다. JWT는 어떤 도메인에서도 토큰만 유효하다면 처리가 가능하기 때문이다. 또한, 보안성 쿠키를 전달하지 않아도 되므로 쿠키를 사용함으로써 발생하는 취약점이 사라진다.

하지만, 모든 요청에 대해서 토큰이 전송되므로 토큰에 담기는 정보가 증가할 수록 네트워크 부하가 증가한다. 또한 토큰 자체에 정보를 담고 있기 때문에 JWT가 만료시간 전에 탈취당하면 보안 문제가 발생한다. 그래서 JWE(JSON Web Encryption)를 통해 암호화 하거나 중요데이터를 Payload에 넣어서는 안 된다. 마지막으로 토큰은 한 번 생성되면 임의로 삭제하는 것이 불가능하므로 만료 시간을 꼭 넣어 주어야 한다.

요약

JWT는 모바일이나 웹의 사용자 인증을 위해 사용하는 암호화된 토큰을 말한다. Header(헤더), Payload(내용), Signature(서명) 3가지로 구성되어 있으며, Header와 Payload는 디코딩하면 평문으로 해독이 가능하기 때문에 민감한 정보를 넣으면 안된다.

JWT을 사용하면 토큰 값만 알고 있다면 어떤 서버로 요청이 들어가던 상관이 없다. 또한, 보안성 쿠키를 전달하지 않아도 되므로 쿠키를 사용함으로써 발생하는 취약점이 사라진다. 하지만, 모든 요청에 대해서 토큰이 전송되므로 토큰에 담기는 정보가 증가할 수록 네트워크 부하가 증가한다. 토큰 자체에 정보를 담고 있기 때문에 JWT가 만료시간 전에 탈취당하면 보안 문제가 발생할 수도 있다. 토큰은 한 번 생성되면 임의로 삭제하는 것이 불가능하므로 만료 시간을 꼭 넣어 주어야 한다.

참고 자료 📑 웹 페이지 로딩 과정 이해하기 📑 (Frontend) Browser - Reflow & Repaint 📑 [WEB] 브라우저의 동작 원리 📑 [WEB] HTTP와 HTTPS의 개념 및 차이점 📑 [Web] 쿠키, 웹 스토리지 (로컬 스토리지, 세션 스토리지) 📑 쿠키와 세션 그리고 로컬 스토리지와 세션 스토리지 📑 JWT란?

호이스팅(Hoisting)은 변수 선언문이 마치 호이스팅 최상단에 끌어올려진 듯한 현상이다. 실제로 선언문이 있는 코드라인을 물리적으로 최상단으로 끌어올린 것이 아니라, 자바스크립트 엔진이 먼저 코드 전체를 스캔하면서 변수를 실행 컨텍스트에 미리 기록해두기 때문에 발생하는 것이다.

var, let, const 모두 호이스팅이 발생한다. 하지만 변수 생성 과정의 차이로 인해 값이 할당되기 전에 참조하면 서로 다른 결과를 도출한다.

변수의 생성 단계는 3가지로 나뉜다.

1. 선언 단계
2. 초기화 단계
3. 할당 단계

var는 선언과 초기화가 동시에 진행된다. 이 때 값을 undefined로 초기화하기 때문에 값을 할당하기 전에 참조해도 오류가 나지 않고 undefined 값을 얻는다.

반면 let과 const는 선언 단계와 초기화 단계가 분리되어 진행된다. 호이스팅 되면서 선언단계가 이루어지지만, 초기화 단계는 실제 코드에 도달했을 때 진행된다. 따라서, 실제 코드에 도달하기 전에 먼저 참조를 하게 되면 ReferenceError가 발생한다.

이는 Temporary Dead Zone(TDZ) 때문이다. let과 const로 선언된 변수들은 실제 코드에 도달하기 전까지는 TDZ 영역에 존재하며, 접근할 수 없다. TDZ로 인해 잠재적인 버그를 줄일 수 있다.

* 변수 선언 코드에 도달하기 전까지의 영역을 변수에 접근할 수 없다는 의미로 Temporary Dead Zone(TDZ)이라고 한다.

함수 표현식(const func = () => {})은 함수를 변수에 담고 있기 때문에 변수 호이스팅과 동일하게 동작한다.

함수 선언문(function func() {})은 실행 컨텍스트에 함수 전체가 통채로 저장되기 때문에 함수 이름을 key로 하고 함수 자체를 value로 저장하여 완전하게 초기화된다. 따라서, 완전하게 저장된 상태에서 접근하는 것이기 때문에 변수 선언 이전에 변수에 접근하더라도 변수를 참조할 수 있다.

요약

호이스팅은 변수 선언문이 마치 호이스팅 최상단에 끌어올려진 듯한 현상이다. var로 선언된 변수는 선언과 초기화가 동시에 진행된다. 값을 할당하기 전에 참조해도 오류가 나지 않고 undefined 값을 얻는다. let과 const로 선언된 변수는 선언과 초기화가 분리되어 진행된다. 실제 코드에 도달하기 전까지는 TDZ 영역에 존재하며, 접근할 수 없기 때문에 ReferenceError가 발생한다.

2. 스코프

스코프는 변수의 접근 가능 유효범위로 변수 이름, 함수 이름과 같은 식별자가 선언된 위치에 따라 다른 코드에서 참조 가능 여부가 결정되는 것이다.

전역적으로 선언된 변수는 전역 스코프에, 지역적으로 선언된 변수는 지역 스코프에 있다. 전역스코프와 지역스코프는 서로 계층적으로 연결되어 있는 데, 이것을 스코프 체인이라 한다. 스코프 체인은 물리적으로 존재하며 자바스크립트 엔진은 이 스코프 체인을 통해 변수를 참조한다.

스코프 체인은 무조건 상위(지역->전역) 스코프로만 올라가면서 참조한다. 자신의 스코프에서 변수를 찾고 해당 변수가 없다면, 상위 스코프로 타고 타고 올라가면서 변수를 찾는다. 이 과정에서 변수를 찾으면 반환하고, 가장 상위인 전역 스코프까지 와서도 끝내 못 찾는다면 ReferenceError를 반환한다.

이렇게 계층적으로 연결되어 있는 스코프 체인 덕분에 하위 스코프에서 상위 스코프에 있는 변수를 참조할 수 있는 것이다.

*생명 주기를 마감한 상위 함수의 변수를 참조할 수 있는 이유 -> 클로저

스코프체인 참조 과정

1. fooColor를 출력하려할 때 bar 스코프에는 fooColor가 존재하지 않음.
2. 스코프 체인을 타고 foo 스코프로 이동하여 변수를 찾아내고 출력함.
3. 마찬가지로 globalColor를 출력하려할 때 bar 스코프에는 fooColor가 존재하지 않음
4. 스코프 체인을 타고 foo 스코프로 이동하여 변수를 찾음. 하지만, foo 스코프에도 존재하지 않음.
5. global 스코프로 이동하여 변수를 찾아내고 출력함.

요약

스코프는 변수의 접근 가능 유효범위이며, 상위 스코프와 하위 스코프들이 계층적으로 연결되어 있는 것을 스코프 체인이라고 한다. 이 때문에 하위 스코프에서 상위 스코프에 있는 변수를 참조할 수 있는 것이다.

3. 클로저

클로저는 함수와 그 함수의 렉시컬 환경의 조합이다. 클로저의 핵심은 스코프를 이용해서, 변수의 접근 범위를 지정하는 것이다.

클로저를 사용하면 스코프에 데이터를 보존하기 때문에 외부 함수의 실행이 끝나더라도 외부 함수 스코프에서 선언된 변수에 접근이 가능하다. 또한, 정보의 접근을 제한할 수 있다. 클로저 함수를 변수에 할당하면 각자 독립적으로 값을 사용하고 보존할 수 있기 때문에 모듈화에 유리해진다.

요약

클로저는 함수와 그 함수의 렉시컬 환경의 조합이다. 클로저의 핵심은 스코프를 이용해서, 변수의 접근 범위를 지정하는 것이다. 클로저를 사용하면 데이터 보존이 가능하고 정보의 접근을 제한할 수 있으며, 모듈화에 유리해진다.

4. 실행 컨텍스트

실행 컨텍스트는 코드를 실행하는 데 필요한 환경(조건이나 상태)을 제공하는 객체이며, 식별자를 더욱 효율적으로 결정하기 위한 수단이 된다.

실행 컨텍스트는 Variable Environment, Lexical Environment, ThisBinding을 구성 요소로 가진다.

• VariableEnvironment : 현재 컨텍스트 내의 식별자들에 대한 정보 + 외부 환경 정보. 선언 시점의 LexicalEnvironment의 스냅샷으로, 변경 사항은 반영되지 않음
• LexicalEnvironment : 처음에는 VariableEnvironment와 같지만 변경 사항이 실시간으로 반영됨.
• ThisBinding : this 식별자가 바라봐야 할 대상 객체

실행 컨텍스트는 동일한 환경에 있는 코드들을 실행할 때 필요한 환경 정보들을 모아 객체를 구성하고, 이를 콜 스택에 쌓아올렸다가, 가장 위에 쌓여있는 컨텍스트와 관련 있는 코드들을 실행한다. 이렇게 해서 전체 코드의 환경과 순서를 보장할 수 있다. 어떤 실행 컨텍스트가 활성화되는 시점에 선언된 변수를 위로 끌어올리고 외부 환경 정보를 구성하고, this 값을 설정하는 등의 동작을 수행한다.

요약

실행 컨텍스트는 코드를 실행하는 데 필요한 환경(조건이나 상태)을 제공하는 객체이며, 식별자를 더욱 효율적으로 결정하기 위한 수단이다. 실행 컨텍스트로 전체 코드의 환경과 순서를 보장할 수 있다.

참고 자료 📑 [JavaScript] 클로저(Closures)란 무엇일까? 📑 [10분 테코톡] 💙 하루의 실행 컨텍스트

• 프로젝트 주제: 공간 대여 예약 플랫폼

• 프로젝트명: TWOGATHER(투게더)

• 제작 기간: 22.07.04 ~ 22.07.24 (3주)

• 기술 스택 프론트엔드: React, JavaScript, Styled-components, Axios 백엔드: TypeScript, Nest, MySQL, typeORM, enkins, AWS EC2, S3(lambda) 기타 협업 도구 : Swagger, Postman, Slack

• 팀 구성: 프론트엔드(4명) + 백엔드(2명)

• 구현 기능 ① 회원가입, 로그인, 로그아웃 • 카카오 소셜 회원가입 및 로그인 • 로그인 시 유저 권한에 따라 페이지 접근 • 비밀번호 분실 시, 가입한 이메일로 임시 비밀번호 발송 ② 마이페이지 • 내 정보 수정 및 프로필 사진 등록 • 내 예약 내역 • 내가 작성한 리뷰 및 Q&A 목록 ③ 공간 조회 • 지역, 공간유형, 공간명, 해시태그 등 키워드로 공간 검색 • 등록순, 가격순 등 공간 조회 필터링 ④ 공간 예약 • 공간 이미지 슬라이드 • 공간 설명 및 지도 • 날짜별 예약 불가능한 시간대 필터링 • 시간대별 룸 예약 ⑤ 공간 호스팅 • 호스트 등록 • 공간/룸 등록 및 수정, 삭제 • 내 공간 예약 내역 관리 • 내 공간 리뷰 및 Q&A 관리 ⑥ 관리자 • 유저 관리 • 전체 예약 내역 관리 • 공지사항

• 담당 포지션 및 업무: 프론트엔드 - 공간 상세, 공간 예약, 호스트/어드민 예약관리, 호스트 Q&A 관리

• 결과물 살짝

프로젝트 중 발생한 이슈 및 해결

1. 컴포넌트 간의 state 공유 개발을 하다보니 하위 컴포넌트들끼리 state를 공유해야 하거나 상위 컴포넌트에서 state를 사용해야 하는 상황을 마주하게 되었다. state 끌어올리기에 대해서 잘 모르고 있던 상태였는데, 구글링 해보니 공식 문서에도 있을 만큼 자주 사용되는 개념이었다. 생소한 개념이다보니 어떻게 적용시켜야하나 고민이 많았는데 유튜브에 설명이 잘 되어있는 영상이 있어서 그걸 참고하여 적용시켰다. 막상 이해하고 보니 어려운 개념이 전혀 아니었다. 내가 속도가 빠른 편이었어서 팀원들 중에서 가장 먼저 state 끌어올리기를 적용시킨 것이었는 데 이후 팀원들도 나와 같은 상황에 마주했을 때 내가 해결 방법을 설명해줄 수 있었다. 먼저 공부한 내용을 다른 팀원들에게 알려주어 도움을 줄 수 있어서 매우 뿌듯했다!
   
2. setState 무한 루프에 빠지다. 공간 상세 페이지에서 해당 공간의 상세 룸들의 정보를 뿌려줘야 했다. 그래서 map 안에서 api를 요청하여 그 결과를 setState로 저장했더니 무한 루프에 빠져버리는 문제가 발생했다. 내가 의도한 것은 룸의 개수만큼만 api를 요청하는 것이었는 데 api 요청이 끝없이 발생하는 것이었다. 무한루프는 처음 마주해봤는 데 해결방법을 몰라 패닉에 빠졌었다.😱 오랜 시간동안 삽질을 하고, 팀원분들과 이 문제에 대해서 같이 머리를 싸매고 고민한 결과 다음과 같은 방식으로 겨우 해결할 수 있었다. 우선 첫 렌더링 시에만 api 요청을 하도록 useEffect를 사용하였다. 그런데 이것만으로는 해결이 되지 않았고, api 요청이 map 안에만 들어가면 무한루프에 빠지는 현상이었기 때문에 api 요청을 바깥으로 분리하여 state로 관리하였다. 그리고 map 안에서 해당 state를 불러서 사용하는 방식으로 분기하였다.

소감

리액트를 처음 배우고 첫 프로젝트였기 때문에 시작할 때 걱정이 컸다. 나와 마찬가지로 다른 프론트엔드 팀원들도 리액트가 처음인 상황이었다. 그래서 첫 회의때 다른 새로운 기술을 도입하기 보다는 리액트에 집중해서 개발하는 게 어떻겠냐고 제안했고, 팀원분들도 모두 좋다고 해주셔서 리액트로만 개발하게 되었다. 덕분에 프로젝트를 진행하면서 리액트를 제대로 적용시켜볼 수 있었고, 역시 직접 해보니 더욱 이해가 잘 되었다.

이번 프로젝트는 저번 프로젝트보다 개발 기간이 1주가 더 길었지만, 기획부터 우리가 다 해야했기 때문에 사실상 주어진 시간이 많지 않았다. 그래서 첫 주차부터 새벽까지 코딩을 하면서 정말 바쁜 3주를 보냈다. 잠도 잘 못 자는 상태에서 하루종일 코딩을 하다보니 팀원들이 예민해져서 서로 날카로워지기도 했었다. 좋지 않은 상황에서도 팀원들 모두 다 열심히 해주었고 마지막날까지 밤샌 끝에 완성할 수 있었다.

이번 프로젝트를 하면서 저번 프로젝트에 비해서 내 개발 실력이 많이 늘었다는 것을 느낄 수 있었다. 속도도 내가 가장 빠르다보니 다른 팀원들을 더 많이 도와줄 수 있었다. 뭔가 문제가 생겼을 때 같이 코드를 보면서 해결하는 등 팀원들을 도와주는 상황이 많았었다. 물론 나도 난관에 봉착했을 때 다른 팀원들에게 도움을 얻을 수 있었다. 서로서로 도와가면서 개발하는 분위기가 정말 좋았던 것 같다. 팀에 도움이 될 수 있는 사람이어서 행복했다.

서버사이드 렌더링 복습

• 렌더링 방식 CSR - Client Side Rendering SSR - Server Side Rendering SSG - Static Site Generation ISR - Incremental Static Regeneration
  

• Client Side Rendering : useEffect 렌더링이 클라이언트 측에서 발생. 자바스크립트 코드가 많으면 앱 로딩이 느려짐 SEO에 취약
• Server Side Rendering : getServerSideProps 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달 SEO에 유리
  
• next js - React로 만드는 서버사이드 렌더링 프레임워크
• yarn dev npm run dev 개발 환경 세팅
• yarn build npm run build 실서버 배포 버전 생성
• yarn build npm run start 실서버 구동
  
• pages/index.js는 엔트리 파일
• nextjs는 라우팅을 따로 처리해주지 않아도 자동으로 설정됨
• id는 가변적인 파라미터로 처리. useRouter를 통해서 id 값에 접근할 수 있음

  import {useRouter} from 'next/router';
  export default function Topic() {
  const  router = useRouter();
  const id = router.query.id;
  return <>/sub/{id}.js</>
  }

• Link : 페이지 리로드 없이 페이지를 전환하도록 돕는 컴포넌트

  <Link href="/sub">Index</Link>

• nextjs는 express 처럼 백엔드 기능이 내장
• /pages/api 폴더는 server side api를 위한 전용공간

  export default (req, res) => {
  const { id } = req.query;
  const topic = topics.filter(e => e.id === Number(id))[0]
  res.status(200).json(topic);
  };

• Vercel 이용해서 git repository 끌어와서 배포
• Freenom으로 무료 도메인 생성

- 220629 ~ 220631

여태까지 배운 내용 정리하고 스타일 컴포넌트 복습

프로젝트 소개

• 프로젝트 주제 - 캡슐커피 쇼핑몰
• 프로젝트명 - ${elicebucks} (엘리스벅스)
• 제작 기간 - 220523 ~ 220605 (2주)
• 기술 스택 - Vanilla js, Node js, Express, Mongo DB 등
• 팀 구성 - 5명 (프론트엔드 3명 + 백엔드 2명)
  
• 구현 기능 ① 회원가입, 로그인, 회원정보 수정 및 탈퇴 등 사용자 관련 CRUD ② 카테고리 관련 CRUD, 제품 관련 CRUD, 주문 관련 CRUD ③ 장바구니 관련 기능을 프론트 단에서 수행 ④ 관리자 페이지 ⑤ 추가 개선 기능 (공지사항, 페이지네이션, 쇼핑몰 현황, 로딩)
  
• 담당 포지션 프론트엔드 팀장
  
• 담당 업무 메인 상품 목록 상품 카테고리 상품 상세 +) 공지사항 +) 페이지네이션
  
• 결과물 살짝 ⬇️

프로젝트 중 발생한 이슈 및 해결

1. 컴포넌트 임포트 실패 우리 팀은 상단바 특정 부분(로그인, 로그아웃)을 따로 컴포넌트로 빼놓고 임포트해서 사용하는 식으로 구현을 했다. 그런데 일부 파일에서 임포트가 되지 않는 문제가 발생했다. 상대 경로로 ( ../url ) 임포트를 하고 있었는 데 해당 경로가 먹히지 않고 있었다. 이 부분에 대해서 원인을 알아보니 서버 사이드 렌더링이 아닌 클라이언트 사이드 렌더링이라서 클라이언트 브라우저 상 경로로 찾아가줘야 하는 것이었다. 그래서 ( /url ) 이나 (./../url) 이런식으로 임포트를 하니 문제가 해결되었다.
   
2. 페이지네이션 처리 영역 구분 페이지네이션을 프론트와 백엔드 중 어디서 처리할 지에 대한 이슈도 있었다. 처음에 나는 프론트엔드에서 처리하는 것이 더 낫지 않나 생각했었다. 백엔드에서 페이지네이션을 처리하면 페이지 목록을 클릭할 때마다 url 쿼리가 변경되기 때문에 매번 재렌더링 되는 부분이 다소 어색하다고 느껴졌기 때문이다. 페이지네이션은 같은 페이지를 단순히 나눠서 보여주는 것이기 때문에 페이지 목록을 이동을 하더라도 재렌더링되지 않고 같은 페이지에 머물고 있다는 느낌을 줘야한다고 생각이 들었다.
   이 부분에 대해서 백엔드 담당자분과 논의를 해보다가 결국은 결론이 나지 않아 코치님께 조언을 구했다. 코치님께서는 프론트에서 모두 처리하게 되면 프론트가 모든 데이터를 계속 보관하고 있어야하기 때문에 서버 성능에 무리가 갈 것이라고 말씀하셨다. 코치님의 조언을 듣고 서버의 성능을 위해 백엔드에서 처리하는 방법으로 결정하게 되었다.
   프론트엔드 담당인 나는 단순히 유저 경험만을 고려하고 있었다는 사실을 깨달았고 프로젝트를 만들 때 서버 성능을 고려하는 것도 중요하다는 것을 잊지 말아야겠다고 생각했다.
   
3. 백엔드와의 협업 팀원 분중에 이번이 코딩이 처음이신 분이 계셨었다. 그 분이 백엔드 상품 DB 담당이셨고, 나는 상품 목록, 상세 등을 담당했었기 때문에 그 분과 교류가 정말 많을 수 밖에 없었다. 처음이신걸 고려하고 어려움이 많으실 것 같아 도움을 드릴 수 있는 부분은 많이 도와드리려 했었다! 깃 사용법을 알려드린다던가, 개발을 하다가 자잘한 오류를 발견하여 담당자분께 알려드리는 등 조금씩 도와드리면서 개발을 진행을 했었다.
   하루는 백엔드 담당자분께서 데이터베이스 관련으로 도움을 요청하셔서 함께 화상으로 코드를 뜯어보면서 이것저것 시도해보았지만 이상하게 잘 해결이 되지 않았다. 나는 그 과정에서 뭔가 백엔드 부분이 전체적으로 꼬여있는 듯한 느낌을 받았다..! 백엔드 3계층 구조를 모두 왔다갔다 하며 원인을 확인한 결과 함수를 엉뚱한 이름으로 불러와서 사용하고 계시는 등의 실수가 원인이었다. 3계층으로 개발을 하다보니 혼동이 있으셨던거 같다. 그렇게 3시간동안의 회의 끝에 원인을 찾고 오류를 잘 해결할 수 있었다!👏
   나는 이번 일을 통해 프론트엔드가 백엔드의 지식도 어느정도 알아야겠다는 생각이 들었다. 오류가 발생했을 때 프론트엔드의 문제인지 백엔드의 문제인지 구분이 잘 안될 때가 있는 데, 백엔드를 어느정도 알면 구분이 쉬워지기 때문이다! 또한, 내가 생각했던거보다 프론트엔드는 다른 담당자분들과 교류가 정말정말 많았다. 그런 이유에서도 원활한 의사소통을 위해 어느정도는 알아야겠다는 생각이 들었다.

소감

제대로 된 팀 프로젝트는 이번이 처음이었던지라 많이 떨리고 부담감이 컸다. 그리고 얼떨결에 팀장까지 맡게 되어서 임무가 더 막중해진 기분이었다. 팀장인데 내가 맡은 1인분도 제대로 못 해내면 정말 팀원들 보기 부끄럽겠다는 생각이 들어서 부담이 너무 컸다🥲 부담감을 껴안고 프로젝트를 진행하다보니 뭔가 제대로 해결이 안 될 때마다 울고 싶기도 하고 이걸 못 해내면 안된다는 생각이 머릿속을 지배했다. (덕분에 꿈 속에서도 오류를 해결하고 있었다.)

시간 안에 마무리 해야한다는 압박감이 커서 2주 동안 잠도 제대로 못 자고 밥 먹는 시간도 아껴가면서 개발을 했다. 프로젝트를 진행하는 2주는 정말 역경과 고난의 연속이었지만, 프로젝트가 마무리 되어갈 쯤에는 전체적인 그림이 나오고 끝이 보이기 시작하니 정말 뿌듯했다. 그리고 팀원분들 모두 묵묵히 자기 역할을 다 잘해주셔서 완성할 수 있었던 거 같다.

팀프로젝트를 한 번 경험해보니 감이 잡혀서 다음 프로젝트는 이번보다는 익숙하게 할 수 있을 것 같다. 그리고 나에게 항상 깃은 어려운 존재였어서 늘 쓰던 기능만 썼었다. (add, commit, push...) 하지만, 이번 팀프로젝트를 진행하면서 깃에 대한 장벽을 뚫을 수 있었다.

프로젝트 시작 전에 깃을 익혀놔야겠다 싶어서 조금 만져보니 금방 익힐 수 있었고 깃을 헤매는 팀원분들께 사용법을 알려드리기도 했다! (뭔가 뿌듯...ㅎㅎ) 처음에 conflict 날 때 정말 당황스러웠는데 계속 하다보니 나중에는 conflict가 나도 능숙하게 해결할 수 있었다.

이번 경험을 통해 프로젝트에 대한 두려움을 뿌시고 많이 성장할 수 있었던 거 같다. 개발은 직접 해봐야 늘 수 있다는 것을 뼈저리게 느꼈다. 앞으로 시간 날 때 팀프로젝트나 개인프로젝트를 더 많이 해봐야할 것 같다.

crud의 전체적인 내용 정리와 상태 관리 훅에 대해서 학습했다. 온라인 강의 실습 내용이 유독 어려웠는 데, 기본 개념이 제대로 학습되지 않은 상태에서 코드를 짜려하니 너무 힘들었다. 그래서 결국은 혼자 블로깅 하면서 따로 개념 학습을 했다.🥲 상태관리 훅이 이렇게 많이 있는지 몰랐는 데, 각 훅들의 특성을 잘 알고 상황에 따라 잘 사용해야겠다는 생각이 들었다. 잘못하면 성능이 되려 나빠질 수도 있기 때문에..

• useEffect는 promise를 입력값으로 받지 않는다.

• Link의 to는 click했을 때 해당 url로 변경하라는 의미 -> a 링크와 동일
• Route의 path는 바뀐 url과 매치되는 컨포넌트를 렌더링
  
• useRef는 useState와 달리 ref의 값이 변경되어도 컴포넌트가 재렌더링되지 않는다. useRef 함수는 current 속성을 가지고 있는 ref객체를 반환한다.
  
• useContext는 state를 컴포넌트 간에 전역적으로 공유하여 사용할 수 있다. createContext로 context 객체를 생성할 수 있고, 생성된 context 객체는 Provider를 통해 하위 컴포넌트에게 전달될 수 있다.
• context = createContext(default value) 컨텍스트 생성
• <context.Provider value={provider value}> 컨텍스트로부터 컴포넌트 생성
• contextValue = useContext(context) context의 값을 불러옴 -> 가까운 Provider의 영향을 받음
  
• useReducer는 useState와 똑같이 상태 관리를 하지만, 보다 복잡한 상태 관리에 유리하다.
• 다음 state가 이전 state에 의존적인 경우에 보통 useState보다 useReducer를 사용하는 것이 좋다.
• const [state, dispatch] = useReducer(reducer, initialArg, init)
• useReducer를 은행으로 비유

  const initialState = {count: 0};
  // reducer는 은행
  // state는 현재 장부 값, action은 사용자가 시킨 행동
  function reducer(state, action) {
  switch (action.type) {
    case 'increment':
      // return 값이 state 값이 됨
      return {count: state.count + 1};
    case 'decrement':
      return {count: state.count - 1};
    default:
      throw new Error();
  }
  }
  // state는 장부 값
  // dispatch는 창구 직원, dispatch를 부르면 reducer 함수 실행
  // initialState는 state의 초기값
  function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({type: 'decrement'})}>-</button>
      <button onClick={() => dispatch({type: 'increment'})}>+</button>
    </>
  );
  }

- 220622 ~ 220623

리덕스에 대해서 배웠는 데 너무너무너무 어려웠다. 아직 상태관리 훅에도 익숙해지지 않았는 데 리덕스까지 배우려니 너무 힘들었다.. 리덕스랑 리액트 리덕스랑 리덕스 툴킷을 한 번에 배우려니 너무 혼동이 왔다😱 그래도 리덕스는 중요한 개념이니 잘 챙겨가야겠다는 생각이 들었다.

• Redux: 전역적으로 상태 관리

• npm install redux react-redux redux 설치
• 하나의 store에 모든 state를 저장하고 관리 -> createStore
• import { createStore } from "redux";
• const store = createStore(reducer, initialState);;
• import store from "./Store"; Store.js

  import { createStore } from 'redux';
  const reducer = (state, action) => {
  if (action.type === 'up') {
    return { ...state, value: state+value + action.step };
  }
  return state;
  };
  const store = createStore(reducer, {value: 0});
  export default store;

• react-redux로 리액트와 리덕스 연결 필요
  
• Provider는 Store를 전역적으로 사용할 수 있게 해줌
• import { Provider } from "react-redux";
• <Provider store={store}> store를 전역적으로 공급 index.js

  import store from "./Example/ExStore";
  import { Provider } from "react-redux";
  // 최상위에서 Provider로 컴포넌트들을 감싸줘야 함
  root.render(
  <Provider store={store}>
    <App />
  </Provider>
  );

• useSelector는 상태를 읽을 때 사용, useDispatch는 상태를 변경할 때 사용, reducer는 상태 변경을 처리하는 함수
• import { useSelector, useDispatch } from "react-redux";
• useSelector((state) => state.value); 값을 읽을 때 사용
  
• npm install @reduxjs/toolkit redux toolkit 설치
• 스토어를 분리해서 사용 -> slice
• createSlice slice 생성
• configureStore slice를 합친 store 생성 -> createStore 대체

  import { configureStore } from "@reduxjs/toolkit";
  import countUp from "./countUpSlice";
  import countDown from "./countDownSlice";
  const store = configureStore({
  reducer: {
    countUp: countUp.reducer,
    countDown: countDown.reducer
  }
  });
  export default store;

• createAction 액션 생성 함수 생성
• createReducer reducer 함수 생성
• createSelector state 값 가져오기 -> useSelector 대체
• Action의 payload는 내용이라는 뜻

- 220624

테스팅은 처음 학습해봤는 데 처음부터 끝까지 초면인지라 처음엔 감잡기가 힘들었는데 실습 문제를 몇번 풀어보니 대충 이런거구나 감을 잡을 수 있었다. 이번주에 배운 내용들은 전체적으로 어렵지만 하나도 버릴게 없고 중요한 내용들이었다. 힘들지만 얼마 안남았으니 파이팅해야겠다..!

• 테스트 종류 3가지 • 유닛(Unit) 테스트 : 프로젝트의 기능을 잘게잘게 쪼개서 테스트 • 통합(Integrated) 테스트 : 기능단위로 묶어서 잘 작동하는지 테스트 • E2E(End-to-End) 테스트 : 프로젝트가 브라우저 위에서 잘 동작하는지 사용자 관점에서 테스트

• 테스팅 용어 • Mocking : 특정 동작을 흉내 내는 것 • Stubbing : 더미를 채워 넣는 것
• 테스팅 구성 3가지 • setup : 테스트를 위한 환경 생성 • expectation : 테스트를 위한 코드를 작성 • assertion : 테스트 결과가 원하는 대로 나왔는지를 검증
  
• 리액트 테스팅 툴 - jest, react-testing-library
  
• jest • Assertion Matchers : toBe() toEqual() toContain() toMatch() toThrow() • Async assertion : test() done() • Mock functions : jest.fn() jest.mock() mockReturnValueOnce() mockResolvedValue() • Mock functions assertion : toHaveBeenCalled toHaveBeenCalledWith toHaveBeenLastCalledWith • Lifecycle functions : beforeEach afterEach beforeAll afterAll • Grouping : describe() test() • Snapshot testing : toMatchSnapshot() toMatchInlineSnapshot()
  
• react-testing-library Query - 렌더링 된 DOM 노드에 접근하여 엘리먼트를 가져오는 메서드 • get - 동기적으로 처리되며 타겟을 찾지 못할 시 에러를 던짐 getBy-, getAllBy- • find - 비동기적으로 처리되며 타겟을 찾지 못할 시 에러를 던짐 findBy-, findAllBy- • query - 동기적으로 처리되며 타겟을 찾지 못할 시 null을 반환 queryBy-, queryAllBy- • dom 테스팅 - toBeInTheDocument(), toHaveValue(), toBeDisabled(), toBeVisible() ⇨ ByRole ByText ByPlaceholderText ByLabelText ByDisplayValue ByAltText ByTitle, ByTestId 이벤트 - userEvent, fireEvent, createEvent