글이 너무 늦었지만, 그래도 시간 날 때마다 쓰자

Docker 공부 2 - 엔진과 네트워크

# Table Of Contents

# 글을 시작하며

어쩌다 보니 회사에서 SSR 에 관한 작업을 많이 하게 되었다. 현재 근무중인 직장은 k8s 기반으로 거의 모든 어플리케이션 서버 리소스가 돌아가고, 컨테이너를 다루기위한 기술로 `Docker`를 사용한다. 어디나 그렇겠지만 특정 조직은 현 상황에 알맞는 형태로 기술을 사용하기 마련이고, 이를 이해하기 위해선 당연히 시간이 필요하다 생각한다(이 조직에 인프라에 대해 모르는게 많아서 지금은 머리가 뒤죽박죽이다). 또한 이 환경을 이해하기 위한 기반 기술의 기본 지식이 있다면 이해가 더욱 빠를것이라 생각한다. _말인 즉슨 일 잘하려면 공부해야 된다._

헌데 한참 devops 나 backend 관련 실무를 더 많이하던 시절엔 비교적 빠릿하게 떠오르던 도커와 관련된 내용들이 가물가물 하다. 해서 이참에 기억을 되살릴겸/공부할겸 글을 적는다. 사실 실무에 내가 해야하는 작업에 딱 필요한만큼? 혹은 조금더? 살펴본것 외엔 그다지 깊게 공부한적도 없는것 같다.

이 시리즈는 둘 또는 네가지를 주제로 작성될 예정이며, 더 길어지거나 짧아질수도 있다.  
이글은 그중 첫번째 주제인 `가상화`를 다룬다.

1. **[가상화 : 도커를 이해하기 위한 가장 기본적인 가상화와 컨테이너의 개념을 다룬다](https://devlog.juntae.kim/post/docker-study-1)**
2. [도커엔진과 네트워크 : 실제 docker 엔진과 네트워크 구조를 살펴본다](https://devlog.juntae.kim/post/docker-study-2)
3. **도커파일과 이미지**(고민중) : 도커파일과 이미지, 이미지 표준, 레이어 캐싱등의 개념을 다룬다
4. **활용**(고민중) : 명령어및 실무에서 겪었던 경험(logging, troubleshooting, container orchestration - main ECS / sub K8S)을 다룬다

글을 적으려다 보니 도커는 참 대단하단 생각이 든다. [k8s 측이 런타임으로 서의 도커지원을 중단한다는 소식](https://kubernetes.io/ko/blog/2020/12/02/dont-panic-kubernetes-and-docker/)을 듣곤, podman 같은걸 슬슬 봐야하나? 했던 때가 있었다.
이땐 실무에서 컨테이너를 만질일이 많아서 더 쫄렸다. but, k8s 와 관련있는 EKS 등이 아니라 ECS 만 사용했다는거. 무튼 주변을 보면 아직도 도커는 컨테이너 관련 솔루션으로서 여전히 건재한것 같다([containerd](https://containerd.io/) 가 있으니 뭐). 사실상 거의 표준이라 해도 문제없지 않을까.

```
잘못된 정보가 퍼져나가는 것을 원치 않습니다.
잘못된 내용이 있다면, 댓글 혹은 메일로 알려주세요.
```

# Docker 란

뭐 다들 알겠지만 도커는 `리눅스 컨테이너`에 여러 기능을 추가하여, 어플리케이션을 컨테이너로서 좀더 편하게 사용하게 만들어진 오픈소스 프로젝트이다. 뭐 이전부터 이것저것 가격정책은 있었지만, 오픈소스란 말이지. 근데 이녀석이 왜 이리도 핫해졌을까? 뭐가 다를까?
우선, 컨테이너란 근본적으로 무엇인가를 알아보자.

# 컨테이너(Container)

일단 컨테이너란 무엇인가를 좀 정리하고 싶다. 내가 생각하는 컨테이너의 정의를 한마디로 한다면 `격리된 환경에서 프로세스를 실행하는 기술` 이다. 이게 무슨말이냐?

```
여기서 이야기하는 컨테이너는 시스템 컨테이너, 어플리케이션 컨테이너 등을 엄격하게 구분짓지 않고
조금더 포괄적인 개념을 이해하기 위한 표현으로 사용한다.
```

우리가 작성하는 소프트웨어는 결국 os 와 라이브러리에 의존성을 지니고 있다. 우리가 브라우저에서 어떤 라이브러리를 이용해 HTTP 요청을 작성하더라도, 이것은 결국엔 os 의 socket 을 이용해야 하는것처럼 말이다. 이런 의존성을 가진채, 성격이 전혀 다른 어플리케이션 여러개를 하나의 os 에 띄워야 한다고 생각해보자. 이때, 작동중인 어플리케이션들이 서로 간섭하지 않고 안전하게 동작하려면 어떤 요소가 필요할까?

nodejs 어플리케이션 여러개를 하나의 server 에서 실행해야 한다고 가정해보자. 이때 nodejs 어플리케이션이 실행되어야 하는 host 환경이 모두 다르며, 의존하는 nodejs 의 버전이 모두 다르다고 가정해보자. 도대체 어떤 일들이 필요할까? 그냥 생각만 해도 머리가 아프다.

![linux-container](/images/post/2024/02/linux-container.png)
[Virtualization VS Containers - 이미지 출처](https://www.redhat.com/ko/topics/containers/whats-a-linux-container)

컨테이너라는 개념(기술)은 위와같은 문제들을 해결한다. 컨테이너를 실행한다는 것은, 기존 시스템에 존재하는 프로세스를 격리하여 `독립적인 환경` 에서 실행하게 된다는 의미이다. 사실 **컨테이너는 실제로 실행중인 프로세스** 일 뿐이다.

아울러 도커에서 이야기하는 컨테이너는 근본적으로 `리눅스`의 기술이다. 뒤에 조금더 자세히 다루겠지만, 도커는 `리눅스 시스템콜`을 활용해 특정 프로세스를 논리적으로 격리시킨다.
간혹 그럼 윈도우에서는 어떻게 동작하지? 란 의문을 갖을수도 있다만, 이건 도커를 윈도우에서 실행할때 linux VM 을 실행해 주기 때문에 가능한 것이다([참고](https://www.docker.com/blog/the-magic-behind-the-scenes-of-docker-desktop/)).

도커 컨테이너는 호스트와 많은것을 공유하는 만큼 호스트에 영향을 받으며, 머신에 영향도 받는다. m1 맥이 처음 나왔을때 이걸 도커측에서 지원해주길 기다리며 펑펑 터지는걸 꼼수로 처리하던 기억이 있는 사람들이라면 알것이다. 머신 아키텍처에 영향을 받는다.

```
도커는 컨테이너가 자체가 아니다.
컨테이너를 관리하기 위한 많은 기능을 지닌채, 컨테이너 관리에 필요한 기능들을
편리하게 이용할 수 있게 만들어진 툴이다.
```

# 가상화

도커란 녀석을 구글링 하다보면 자주 만나는게 **system call 혹은 커널을 공유한다** 라는 문구이다. 이부분은 워낙 자료가 많긴한데, 일단 살펴보자. 우선 이 커널을 공유한다는게 얼마나 큰 의미인지 알기 위해선 컨테이너 이전의 가상화 기술을 살펴보아야 한다.

## 가상화 기술

기존의 가상화 기술은 하이퍼바이저를 이용해 여러개의 운영체제를 하나의 호스트에서 생성해 사용하는 방식이었다. 이러한 여러 개의 운영체제는 가상 머신이라는 단위로 구분되고, 각 가상머신에는 Ubuntu, CentOS 등의 운영체제가 설치되어 사용된다. 당연히도 OS 자체를 가상화 하다보니 무거울수 밖에 없다.

아울러 각종 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업은 하이퍼바이저를 거치게 되는데, 이때 일반 호스트에 비하여 성능 손실이 발생한다.

- 하이퍼바이저: 호스트 컴퓨터에서 다수의 운영 체제를 동시에 실행하기 위한 논리적 플랫폼(virtual machine monitor 또는 virtual machine manager, 줄여서 VMM). 가상머신과 하드웨어 간의 리소스할당, io 처리등을 담당한다.
- Guest OS: 하이퍼바이저를 통해 생성되고 관리되는 운영체제. 즉 host OS 에 올라가는 가상화된 녀석.

![virtual-machines-docker-containers](/images/post/2024/02/virtual-machines-docker-containers.png)
[Virtual machines vs Docker Containers - 이미지 출처](https://www.cherryservers.com/blog/a-complete-overview-of-docker-architecture)

이를 해결하기 위해 CPU의 가상화 기술([HVM](https://en.wikipedia.org/wiki/Hardware-assisted_virtualization))을 이용한 [KVM](https://linux-kvm.org/page/Main_Page)(Kernel-based Virtual Machine)과 [반가상화](https://en.wikipedia.org/wiki/Paravirtualization)(Paravirtualization)방식의 Xen이 등장한다. 이러한 방식은 게스트 OS가 필요하긴 하지만 전체OS를 가상화하는 방식이 아니였기 때문에 호스트형 가상화 방식에 비해 성능이 향상 되었다.

- 전가상화(Hardware Virtual Machine): 어려운말 재끼고 그냥 하드웨어까지 완전히 가상화 하는 기술. Guest OS 의 수정이 필요 없다. 그대신 비교적 무겁다.
- 반가상화(Para-Virtualization): 하드웨어를 완전히 가상화 하지 않고, 하이퍼콜이라는 인터페이스를 통해 하이퍼바이저에게 요청을 날리는 형식. Guest OS 를 수정하여 특정 명령을 날릴때 하이퍼콜을 호출한다. 비교적 가볍긴 하지만 Guest OS 를 수정해야 한다(말인즉슨 오픈소스 OS 아니면 조금 곤란하지 않을까?).

하지만 전가상화든 반가상화든 추가적인 OS를 설치하여 가상화하는 방법은 어쨌든 성능문제가 있었고 이를 개선하기 위해 프로세스를 격리 하는 방식이 등장한다.

리눅스에서는 이 방식을 `리눅스 컨테이너`라고 하고 단순히 프로세스를 격리시키기 때문에 가볍고 빠르게 동작한다. CPU나 메모리는 딱 프로세스가 필요한 만큼만 추가로 사용하고 성능적으로도 손실이 미미하다. 도커는 `runC(libContainer 의 wrapper)`를 사용하여 컨테이너를 만드는데, 이녀석은 host OS 의 자원을 공유한다. 때문에 기존 VM 에 비해 소프트웨어로 가상화를 구현해야 하는 요소가 엄청나게 줄어들고, 이는 가벼운 크기의 이미지와 성능 손실이 비교적 미미한 실행환경을 갖게되는 것으로 연결된다.

한가지 추가로 언급하고 싶은점은 **os 가상화가 안좋아 보이지만 그것도 아니다.** 격리수준은 더 높아 보안적인 측면에선 더 뛰어나기도 하다. 또한 도커와 VM 기술은 꼭 따로써야 하는것도 아니다. 다만, 컨테이너 기술을 활용하여 리소스를 격리시키는 메커니즘은 현대의 어플리케이션이 돌아가는 환경에 잘 맞는 부분이 많다. 하여 **"현 시기에 동작하는 많은 어플리케이션과 궁합이 좋은 기술이다"** 라는 말이 조금더 정확한 표현이라 생각한다.

사실 모든 기술이란 어떤 니즈/문제가 있어야 탄생하고, 많은이가 원하는 요소를 아름답게 뭉쳐내면 그중 몇몇이 한시대를 풍미하는것 아닐까 한다만. 도커는 현대 어플리케이션을 관리함에 있어 필요한 사항을 아주 잘 뭉쳐낸 기술이라 하기에 충분해 보인다.

## 가상화와 성능

일단 리눅스 컨테이너를 구현하려면 `리눅스 시스템 콜`인 `chroot`나 `namespace`, `cgroup`, `unionmount` 등의 기능을 활용해야 한다. 도커는 `libcontainer` 로 인해 리눅스 커널 기능인 cgroups, namespaces 등을 직접적으로 활용할 수 있는데, 이런식으로 리눅스의 기술을 활용한 프로세스 단위의 격리환경을 만들기 때문에 성능의 손실이 거의 없다(**뒤에서 더 자세히 다룬다**).

직전에 전가상화/반가상화 와 하이퍼바이저를 언급하며 설명했듯, 일단 이 하이퍼바이저를 통해 무언가를 실행한다면 내 컨테이너가 실행되는 커널의 기능을 직접적으로 사용하지 못한다는것을 의미한다(system call 도 따지고 보면 interface 이긴 하지만 성격이 다르다). 중간에 어떠한 특정 단계가 있으니 오버헤드가 있는것은 당연하다. 아울러 가상화나 반가상화로 만든 환경은 무겁기 때문에, 상대적으로 이미지가 크고, 이는 실행/배포 시간 등에 영향을 줄수밖에 없다.

즉 이 도커라는 녀석을 사용하여 컨테이너를 활용한다면

1. 컨테이너에 필요한 커널은 호스트의 커널을 공유하여 사용하고
2. 컨테이너 안에는 어플리케이션을 구동하는데 필요한 라이브러리 및 실행 파일만 필요하기 때문에, 만들어내는 이미지의 크기가 작다.
3. 이미지의 크기가 작으니 가상 머신에 비해 이미지를 만드는 속도가 빠르며, 이미지 저장소에 push 를 한다는 등의 행위에 속도가 빠르다.
4. 리눅스 컨테이너를 기반으로 작동하는 만큼 단순히 프로세스를 격리시키기 때문에, 성능 손실이 훨씬 적을수 밖에 없다. 즉 빠르다.

# 도커의 컨테이너

컨테이너와 가상화를 정리했으니, 이제 이걸 도커가 어떤 형태로 구현했는지 살펴보자. 일단 도커는 리눅스 컨테이너 기술을 활용한다 했다. [이 글](https://www.docker.com/blog/docker-0-9-introducing-execution-drivers-and-libcontainer/) 을 살펴보면 알수있듯, 0.9 버전 이전엔 컨테이너 기술을 활용하기 위한 수단으로 [LXC](https://linuxcontainers.org/lxc/) 를 사용했으나, 0.9 부턴 [libcontainer](https://github.com/opencontainers/runc/blob/main/libcontainer/README.md) 라는 내장 드라이버를 기본드라이버로 사용하기 시작했다.

이 변화로 도커는 LXC나 다른 사용자 영역 패키지에 의존하지 않고 `namespaces`, `control groups`, `capabilities`, `apparmor profiles`, `network interfaces`, `firewalling rules` 등을 모두 일관되고 예측 가능한 방식으로 조작할 수 있게 되었는데, 여러 변수를 대폭 줄이고 LXC 버전 및 배포판 전반에 걸쳐 발생하는 부작용으로부터 Docker를 보호 하게 되었다고 한다. 실제로 안정성을 크게 향상시켰다고 하고, 나는 이게 window/mac 등의 여러 플랫폼에서 더 잘 동작하기 위한 기반을 만드는데 큰 영향을 준 변경사항 이었다는 생각이 든다.

![docker execdriver diagram](/images/post/2024/02/docker-execdriver-diagram.png)[docker execdriver diagram - 이미지 출처](https://www.docker.com/blog/docker-0-9-introducing-execution-drivers-and-libcontainer/)

위 이미지를 보면 알 수있듯 [libcontainer](https://github.com/opencontainers/runc/blob/main/libcontainer/README.md) 는 도커가 필요로하는 리눅스의 시스템콜을 사용하는데 관여하며, 컨테이너를 생성하기 위한 기본 Go 구현을 제공한다. 현재는 [runC](https://github.com/opencontainers/runc) 에 포함되어 있다. 이어서 `runC` 가 어디서 어떻게 돌아가는지 가볍게만 살펴보자(**도커 엔진은 다음글에서 다룰 예정**).

## containerd

[containerd](https://containerd.io/)는 도커의 런타임인데, [OCI](https://opencontainers.org/) 가 정한 표준을 준수하여 도커측에서 만든 런타임이다. 도커 컨테이너의 실행과 관리, 이미지, 스토리지와 네트워크 인터페이스 연결과 같은 시스템의 전체 라이프사이클 관리하는 주체가 된다. 하지만 containerd 는 컨테이너를 생성하는 역할은 하지 못하기에, 이를 가능케하는 녀석에 의존하게 되는데 이때 컨테이너를 생성하는 녀석이 바로 [runC](https://github.com/opencontainers/runc)([정확히는 내부의 libcontainer](https://github.com/opencontainers/runc/tree/main/libcontainer)) 이다.
아래 이미지를 살펴보자.

![docker engine](/images/post/2024/02/docker-engine.png)[docker engine - 이미지 출처](https://gngsn.tistory.com/128)

위 이미지의 흐름대로 도커 cli 를 통해 명령어를 입력하게 되면 실행되는 흐름은 다음과 같고 이는 [다음 글](https://gngsn.tistory.com/128)을 참고하였다. **runC 가 실행되는 시점까지만 살펴본다**.

1. docker container run ...
2. docker client는 명령어를 적절한 API Payload로 변환해서 Docker Daemon(이하 dockerd)에게 REST API로 POST 요청
3. API 는 UNIX 소켓을 통해 dockerd 에게 전달.
4. dockerd 가 로컬 이미지를 확인하고 없으면 이미지를 registry 에서 가져옴 새로운 컨테이너를 생성하라는 명령을 수신하면, containerd를 호출(with.grpc)
5. containerd 는 docker 이미지를 가져와서 컨테이너 구성을 적용하여 runc 가 이해할수 있는 OCI 번들로 변환
6. runc(내부의 libcontainer 사용)는 OS 커널에 접속해서 컨테이너를 만드는 데 필요한 모든 구성 요소(네임스페이스, cgroup 등)를 하나로 묶고 컨테이너를 생성한다.

...

위와같은 단계로 우리의 도커컨테이너를 만들어줘 란 명령어는 실행되고, 우린 이미지가 컨테이너로 만들어져 실행되는 것을 볼 수 있는것이다.

# 마치며

원래 알던내용도 있고, 헷갈리거나 애매하게 알던내용. 모르던 내용들을 나름 정리해 보았다. 그간 내가 도커를 너무 모르고 썼다는 생각이 드는데, 나머지 주제도 이어서 작성해 보겠다.  
다음은 엔진이다. 공부할 내용의 분량이 상당히 많을것 같다.

# Ref

- [docker vs containerd](https://blog.purestorage.com/purely-informational/containerd-vs-docker-whats-the-difference/)
- [the magic behind the scenes of docker desktop](https://www.docker.com/blog/the-magic-behind-the-scenes-of-docker-desktop/)
- [how docker desktop for windows works under the hood](https://collabnix.com/how-docker-desktop-for-windows-works-under-the-hood/)
- [what is a hypervisor](https://www.redhat.com/ko/topics/virtualization/what-is-a-hypervisor)
- [lxc vs docker](https://earthly.dev/blog/lxc-vs-docker/)
- [linux container](https://www.44bits.io/ko/keyword/linux-container#lxc)
- [whats future lxc dockers semi forgotten step mother](https://cloudnativenow.com/features/whats-future-lxc-dockers-semi-forgotten-step-mother/)
- [a practical guide to choosing between docker containers and vms](https://www.weave.works/blog/a-practical-guide-to-choosing-between-docker-containers-and-vms)
- [초보를 위한 도커 안내서 - 도커란 무엇인가?](https://subicura.com/2017/01/19/docker-guide-for-beginners-1.html)
- [Docker Engine, 제대로 이해하기](https://gngsn.tistory.com/128)
- [containerd 는 무엇이고 왜 중요할까](https://www.linkedin.com/pulse/containerd%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-sean-lee/?originalSubdomain=kr)


근 2년만에 쓰는 글이 도커일 줄이야

Docker 공부 1 - 가상화

yarn berry workspace + storybook(vite) + next.js + esbuild 를 이용한 monorepo 세팅

모노레포를 마주하며 2 - monorepo 세팅

모노레포를 도입하는 시기와 공통 컴포넌트를 설계하며 느낀점을 이야기합니다

모노레포를 마주하며 1 - 의사결정과 컴포넌트 설계

# Table of Contents

# 글을 시작하며

안녕하세요! 오늘은 팀원분이 트러블 슈팅중 문제를 공유한 슬랙덕에, 제 과거 경험을 공유했었는데요. 이슈는 `iOS` 에서만 `동영상 자동재생`이 되지 않는 문제입니다. 생각난 김에 이때 트러블 슈팅을 어떻게 접근했고, 어떤 방법으로 해결했었는지 이야기해 보겠습니다.

# 버그가 있다는 소식이 들려왔다(나만 안돼요)

당시 버그소식을 들었던 기능은, 제가 개발을 하진 않았었습니다. 하지만 퇴근시간 이후였고, git 에 올라간 순간부터 이제 이 코드는 우리 팀의 코드 아니겠습니까. 특히나 이 기능을 개발한 동료가 신입인데다, 아직 회사에 적응 중이었으므로 퇴근후까지 일을 하게 하고 싶진 않아 기나긴 삽질을 시작하게 됩니다.

`요구사항`은 간단 했습니다. 그저 유저가 페이지에 진입시, 저희가 재생하고자 하는 동영상을 자동재생 해주기만 하면 됩니다. 저는 이슈를 제보받자 마자 제보자들께 한가지 부탁과 두가지 질문을 했는데요.`os` 버전과 `app` 버전 을 여쭙고, 절대 os 와 app 버전 `업데이트를 하지 말아달라` 라는 부탁입니다. 부탁한 이유야 뭐 인앱 웹뷰나, 모바일 웹뷰를 대응하다 보면 누구나 근시일 내에 겪게되는 부분 이라고 생각하는데요. 이유는 다음과 같습니다.

1. `인앱 웹뷰` 라면, 앱 버전에 따라 `네이티브 코드`가 어떻게 `수정`되었는지를 파악해야 하기 때문입니다. 만약 현재 우리 최신버전의 앱에서는 아무 이상이 없지만, 서비스하고 있는 과거 버전의 앱에서 문제가 발생한다고 가정하겠습니다. 이때 정확한 테스트와 방법을 찾기 위해서는 네이티브 앱의 **버전**이 중요하고, 이 앱의 버전을 알아야 앞뒤로 어떤 **코드의 변화**가 생겼는지를 추적 가능합니다. **TestFlight** 등이 잘 관리되고 있고, 내가 네이티브 코드나 버전 히스토리를 잘 알고있어 바로 수정이 가능타 해도 `앱 버전`은 알아두어야 합니다. 후에 네이티브 개발자 분께 도움을 청하기 위해서라도요.

2. `인앱 웹뷰`, `모바일 웹` 모두에 해당하는 사항인데요. `os 버전`은 굉장히 중요합니다. 왜냐. 이게 os 버전이 올라감에 따라 모바일에 기본 탑재되는 소프트웨어 버전이 같이 올라가는 경우가 있는데요. 특히나 iOS 에서 제공하는 브라우저인 `Safari` 의 경우는 이게 정말 빈번합니다. 흔한예로, `display: flex` 를 준 부모 아래 요소가 부모의 `height`을 제대로 상속받지 못하는 이슈는 현재 제 모바일 safari 에서는 잘 해결이 된 상태이지만, 업무 외적으로 사용중인 구버전의 os(Bigsur 11.1) 버전을 쓰는 노트북에서는 해결되지 않은 상태입니다.

크게 위와 같은 이유로 각 디바이스의 환경을 고정해 놓고 나서, 코드와 나머지 레벨에서의 이슈를 찾아내는 것을 추천하고 싶습니다. 저는 처음 실무를 시작했을 당시, **os 버전이 달라서** 이슈가 생길 수 있다는 부분을 잘 몰라 한참을 고생했던 경험이 있었던 이후로는 위 사항을 꼭 신경씁니다.

# 코드 레벨 이슈

이제 코드레벨에서 이슈를 찾을 차례입니다.

이 이슈를 해결할 당시 `Web Frontend` 와 `iOS 네이티브` 코드 둘다 어느정도 문제가 있었는데요. 일단 저는 Web 개발을 하는 만큼 일단은 제 영역인 `Frontend 영역`에서 문제를 찾기 시작했습니다. 당시 기준, 하위 os 버전에서는 문제가 없었으나 최신 os 버전에 해당하는 11대 버전에서는 동영상이 제대로 재생이 되지 않는 문제가 있었습니다. 그래서 Html 에 아래와 같은 속성을 추가해 해결 하게 되었는데 코드는 다음과 같습니다.

```html
<video loop="loop" muted="muted" autoplay="autoplay" playsinline></video>
```

- `muted`: 이 속성은 말그대로 음소거 처리를 하는 속성입니다. 제 경우 iOS 에서 이슈를 발견했으나 트러블 슈팅중 chrome 에서도 재생이 안되는 현상을 발견했고, 이 속성은 사용자의 제한된 네트워크 상황에서 과도한 데이터 소비를 방하기 위한 정책과 관련이 있습니다. 아래 링크를 참조해 주세요.

  - [chrome - autoplay/#webaudio](https://developer.chrome.com/blog/autoplay/#webaudio)

- `playsinline`: 이 속성은 동영상 재생시 저절로 전체화면이 되는것을 막는 속성인데요. chrome 에 경우 이 속성이 없어도 무방합니다. 하지만 iOS 의 경우 11 버전 이후로는 이 속성이 활성화 되어야만 자동재생이 가능합니다. 아래 링크를 참조해 주세요.

  - [webkit - new video policies](https://webkit.org/blog/6784/new-video-policies-for-ios/)
  - [iOS - delivering_video_content_for_safari](https://developer.apple.com/documentation/webkit/delivering_video_content_for_safari)

`iOS 네이티브` 영역의 이슈입니다. 이역시 최신버전의 앱에서는 문제 없이 작동했으나, 위 이슈를 수정하고 나서도 문제가 있어 iOS 팀의 커밋 로그를 뒤져봤는데요. 해당 수정사항을 작성해서 릴리즈하기 전 앱버전을 사용하는 분들에게서 일어나는 이슈였습니다. 저는 네이티브 개발은 잘 몰라서, 당시 회사의 iOS 팀에 의심가는 부분을 질문드린 뒤 확신을 갖을수 있었습니다. 서비스중인 iOS 프로젝트의 몇달치 커밋 로그를 한땀한땀 읽느라 눈이 조금 아팠던 기억이 나네요. 아래 링크를 참조해 주세요.

- [apple developer](https://developer.apple.com/documentation/webkit/wkwebviewconfiguration/1851524-mediatypesrequiringuseractionfor)

위의 사항이 모두 충족되었을때, 사내 버그를 제보해주신 대부분의 분들께 작동이 잘 된다는 이야기를 들을 수 있었습니다. 여기까지 해결하는데는 그래도 비교적 짧은 시간이 걸렸는데요. 이제부터 제가 진정한 삽질을 시작합니다. 이때도 그렇고 지금도 그렇지만 역시나 트러블 슈팅은 짬에서 나오는것이 최강인가 하는 생각이 듭니다.

# 디바이스 레벨(OS) 에서의 문제

위 코드영역에서의 문제를 해결하고도, 단 한분께 아직 재생이 안된다는 제보를 받았습니다. os 버전도 체크하고, 코드도 체크하고, 앱 버전을 체크했음에도 문제는 계속 되었죠. 그렇게 이걸 바꾸고, 저걸 바꾸고, 한참을 구글링 하던중... 저는 어찌보면 참 싱겁고 어이없는 부분에서 해결 방법을 찾게 되었습니다. 바로 `저전력모드` 입니다. iOS 에서는 절전모드 사용시 비디오 자동재생이 되지 않는데요. iOS 의 경우 `9버전`부터 이를 지원하였고, 이때는 아래와 같은 제약사항이 생긴다고 합니다.

- CPU Throttling (60% 제한)
- Background Application Refresh 제한
- WebView Video play제한
- auto-download 제한
- GPU performacne 저하 (requestAnimationframe등의 효과 제한)
- 화면 밝기 저하

이때는 이 이상의 자료를 찾아보진 않았으나 이것도 apple 문서 어딘가에 나와있지 않을까 싶네요. 아울러 참 재미있는 stack overflow 의 글을 읽었는데요. iOS 가 저전력모드에서 `suspend` 이벤트를 사용해 트리거 한다는 내용입니다(_아래링크 참조_).

- [stackoverflow](https://stackoverflow.com/questions/54379718/autoplay-video-iphone-low-power-mode-not-working)

저 이슈를 찾자마자, 저전력 모드이길 바라는 마음으로 제보자(a.k.a Jenny) 에게 혹시 저전력모드를 사용중인지, 그렇다면 풀고 페이지에 접속시에도 문제가 발생하는지 기도하는 맘으로 질문을 했었습니다. ~~장애가 났을때 트러블 슈팅 뒤 누른 배포버튼과 함께 빨리 서비스가 살아나길 바라며 하는 기도와 같은 그런 느낌으로요.~~
당시 저는 저전력 모드에서의 자동재생을 시킬 방법은 찾지못하여, `Fallback GIF` 를 디자이너분께 부탁해 만들고, 자동재생이 실행되지 않을 시 이걸 대신 보여주는 방법으로 해결했던 기억이 나는데요. 기회가 된 김에 잠시 구글링을 해 보았는데, 오늘기준 딱히 뚜렷한 방법이 보이지는 않는듯 합니다. 혹시 방법을 알고계신 분은 메일 부탁드려요🙏.

# 마치며

오랜만에 옛 기억을 떠올리며 글을 작성해 보았는데요. 트러블 슈팅은 이래서 짬인가 싶기도 하고, 여태 만난 문제들이 새록새록 기억에 남네요. 제가 이 문제를 해결할 당시만 해도 특히나 저전력 모드에서 문제가 생긴다는 생각을 아예 하지 못해서인지 구글링을 하는데 정말 오랜 시간이 걸렸었습니다. 이글을 작성하며 해당 이슈에 대한 글이 있나? 하고 보니 그래도 지금은 보이는 글이 적지 않습니다. 제 글도 어느 누군가의 구글링에 걸려 도움이 되길 바라며. 즐거운 코딩 되시길 바랍니다. 감사합니다.


예전에 삽질했던 기억이 나네요. iOS. 단어 근본으로 썼습니다

iOS 동영상 자동재생이 안될때(mobile issue)

# Table of Contents

# 글을 시작하며

안녕하세요! 얼마전 제가 블로그를 리뉴얼 하게 되었습니다.  
아직 추가로 해야하는 작업들이 좀 남아있지만, 리뉴얼로 인해 생긴 변경사항들을 미리 말씀드릴까 합니다.
이 블로그로 인해 강의 제안도 받고, 이직 제안도 받고 참 나름? 재미있는 일들이 생겼었는데요.
블로그를 더욱 잘 운영하기 위해, 그리고 도움을 더 잘 드리기 위해 개발을 새로 하게 되었습니다.
아울러 블로그를 만들며 생각한 기술적 이야기와 몇몇가지 팁들을 이야기 해 보겠습니다.

```
그동안 제 메마른 블로그에 남겨주신 댓글들, 그리고 개인적으로 주신 email 모두 참 감사합니다.
댓글들은 모두 정리하여 글 하단에 남겨두었습니다. 다시한번 감사드립니다.
```

# 블로그 개편

제가 블로그를 새로 개편한 표면적인 이유는 단순합니다. 글을 조금더 자주 쓰고 싶고, 블로그를 운영하는데 신경쓸일이 적었으면 좋겠다 란 니즈에서 시작한 생각인데요. 제가 이전(v1, v2) 버전에서 관리하던 블로그는 어려운 기술이 들어가진 않았습니다. 다만 의도하에 `오버엔지니어링` 을 한 부분도 있고, `Admin` 까지 만들어 놓은지라 `Backend 서버`, `SSR 용 서버` 와 `두 종류의 클라이언트` 를 운영중 이었습니다. 아울러 `DB` 는 아직 RDS 를 쓸 단계는 아닌지라 직접 `EC2` 에 `Docker` 로 에 말아 올려 `Private Subnet` 안에 넣고, `NAT` 도 돈아낀답시고 EC2 로 직접 돌리는등의 작업을 해 두었었는데요. 그래도 `Lambda` 기반의 `Serverless` 로 서버를 돌린게 편리함에 참 큰 역할을 했네요(사실 EC2 나 ECS 를 써도, 이정도 트래픽이면 운영시 트래픽 문제로 신경쓸 일은 없었을겁니다 ㅋㅋㅋ).

이때 이렇게 보안이며 뭐며 나름 신경을 쓴데에는 이유가 있었습니다. 이유는 공부입니다. cloud 에 익숙해질겸 `VPC` 내부 설정도 직접 해보고, `Subnet` 쪼개서 보안도 챙기고, 아무리 작아도 일단 라이브하는 서비스 바닥부터 다 만들어 봐야지? 란 생각이 컸죠. 이때 아직도 살아있는 어드민에는 Markdown Editor 까지 직접 구현을 해 두었습니다(잘가라). 뭐 어찌되었든 사이즈가 너무 크단 생각이 들었습니다.  
상세 구조를 자세히 그리자면 너무 복잡해질것 같아, 러프한 구조를 그린 이미지를 첨부합니다.

![devlog_prev_architecture](/images/post/2022/11/devlog_prev_architecture.png)

특히나 DB 를 직접 띄우다 보니 글을쓰고 댓글을 쓰는 일이야 크게 없지만서도 지금 남은 용량이 얼마나 되고, EBS 볼륨은 언제쯤 늘려야 하나. 메모리는 언제쯤 올려야 하나. 를 신경쓰기가 참 귀찮더군요. 만약 제가 이 블로그로 사이드 프로젝트를 끝낼거라면 모르겠습니다. 허나 저는 진행중인 개인 프로젝트의 서버에 K8S 더나아가 EKS 를 써볼 생각입니다. 초기엔 모르겠지만 RDS 를 써야 하는 때가 올때까지 서비스를 키워보겠다는 목표를 갖고 개발중 인데요. 그럼 이 블로그는 진짜 나만 쓰는 블로그이니, 최대한 편하게 관리하도록 만들어 놓는게 내가 유지하는데 현실성이 있는 선택이겠다 싶더군요.

## 다시 NextJS

저는 리액트를 참 좋아합니다. 이 블로그 역시 Next.js 로 만들어서 배포했다가, 에이 직접하자 란 생각에 `React.js` + `Node.js` 로 직접 `SSR` 서버를 돌리고 있었습니다. 허나 다시 `Next.js` 로 돌아가게 되었는데요. 그이유는 생각보다 단순합니다. 아니 `React18` 이 나왔는데 사용중이던 `lodable-components` 가 이걸 지원을 제대로 안해주는 겁니다. 혹시 모르니 기다리자란 생각에 조금 여유를 두고 지켜보았으나, 빠른 시일 내엔 불가능 할 것 같다는 생각이 들더군요. 아울러 Next 진영의 빵빵한 후원 역시 참 매력적이란 생각은 꽤 오래전부터 해왔었습니다. `SSG` 의 편리함을 생각한 부분이 아예 없진 않지만, 사실 저게 가장 컸습니다. 만약 React18 대응이 빨랐다면 저는 그냥 SSR 서버를 운영하고 있었을 것 같네요. 그런데 말입니다. 얼마전 `Next.js 13` 버전의 발표가 있었죠. 저는 이걸 보고 참 잘 선택했다 란 생각과 동시에 이래서 어느정도 서포트를 잘 해주는 기술을 쓰는게 답인가? 란 생각을 했습니다.

일단 이 글은 Next.js 13 에 대한 내용을 다루는 글은 아님에도 개인적인 소감을 말하자면, 괜히 React 팀과 협업을 하는게 아니구나 라는 생각을 지울수 없는 발표였습니다. 이 블로그도 테스트를 조금만 더 해보고 13으로 버전을 올려야겠어요.  
어찌 되었든, 저는 이번에 Next.js 로 스택을 변경하며 가장 크게 가져간 이득은 두가지란 생각입니다.

### 서버가 사라졌다

서버가 사라지고, `Static Site` 제공이 굉장히 편리해 졌습니다. `next export` 명령어만 입력해주면 알아서 정적 파일을 만들어주는 덕에 개발자인 제가 따로 관리하고 신경써야 할 부분이 굉장히 줄었습니다. 만들어준 정적 파일을 `S3` 에 올리고 이걸 `Cloudfront` 와 연결해 주기만 하면 되니 이 얼마나 편한지요. 하지만 여기서 AWS 에 작은 **불만**이 있긴한데요, 정적 페이지에 대한 다이나믹 라우팅을 언제쯤 편하게 할 수 있도록 지원 해주려나요. `Lambda@Edge` 로 처리를 하긴 했으나, 그냥은 안되나? 싶은 생각을 지우지 못했습니다. 그래서 잠시 `Netlify`, `Vercel`, `Cloudflare` 등을 알아보았으나 역시나 혼자 관리하는 만큼 관리해야 하는 환경을 분산시키기가 싫어 그냥 AWS 상에 구축을 선택했습니다. 구글링을 하다보니, 지원을 기다리며 `Serverless Framework` 등을 쓰고 버티다 결국에 나도 넘어갔다란 글이 보이던데, 이걸 개선 해준다면 저로선 참 감사한 일이 아닐까 싶네요.

현재는 서버가 없어진 대신 `getStaticProps`, `getStaticPaths` 등의 함수를 이용하고 있고, `빌드시` markdown 으로 작성된 파일을 읽어와 바로 데이터를 주입해 주고 있는데요. 생각보다 그리 어렵지도 않았고 큰 이슈도 없어, 개발하는데 크게 어려움을 느낀적이 없었습니다.

### 빵빵한 지원

이부분은 사실 느낀지 시간이 좀 된 부분입니다. 여태 Next.js 에 릴리즈 노트를 접해오며, 비교적 다른 React.js 관련 기술들에 비해 확실히 지원이 빠르다란 느낌도 지울수가 없었구요. 아울러 github 에 나와있는 공식적인 예시들이나 풍푸한 레퍼런스로 인해 개발시 발생하는 트러블슈팅을 하기가 참 수월하단 생각입니다. Remix 도 참 좋지만, 아직까진 Next.js 가 가장 좋아보이는 이 느낌은 지울 수가 없네요. 13을 어서 적용해 보고 싶은데 Layout 등의 새로운 기능이 아직 beta 인지라 테스트를 좀더 해보거나, 혹은 기간의 여유를 좀 두었다가 Migration 을 진행할 생각입니다.

# 작은 팁(Safari hover + border-radius 문제 해결)

제 블로그는 1024px 이상부터 포스트에 `hover` 를 하면 `Thumbnail` 이 `확대` 가 되는 효과를 주었습니다. 테스트를 해보던중 히안한 현상을 발견했는데요. `safari` 에서 `border-radius` 효과가 사라지며 잠시 각진 외곽선이 드러났다가, 다시 `border-radius` 가 정상적으로 작동이 되는것 입니다. 말인즉슨 아래와 같은 현상이 일어났습니다.

1. border-radius 가 먹혀있는 포스트 카드들
2. hover 하니 이미지가 확대
3. 확대되는 과정에서 border-radius 효과가 사라짐
4. 그로인해 radius 영역의 가리워진 부분이 잠시 드러났다가
5. 다시 사라지며 정상 작동

결론적으로 Safari 렌더링엔진 Webkit 의 버그라고 하는데요. 우선적으론 safari 에서 layer 속성을 살펴 보았고, 이후 관련 글들을 읽어보니 결국엔 쌓임 맥락이란 부분과 연관지어 발생한 이슈 라는것을 알 수 있었습니다. 저는 아래와 같은 CSS 속성을 추가해 해결하였고, 이때 참고한 글들을 첨부합니다. 이 레이어에 대한 부분도 참 재미있는 요소가 많네요.

```css
isolation: 'isolate';
```

- [ToastUI 디버깅 도구 관련 글](https://ui.toast.com/weekly-pick/ko_20211027)
- [Sungik Choi 님의 트러블 슈팅 글](https://www.sungikchoi.com/blog/safari-overflow-border-radius/)

# 블로그 변경사항

블로그에 작은 변경사항들이 몇가지 생겼습니다. 디자인과 기타 look and feel 등을 제외하면 사실 말씀드릴 부분은 간단하게 세가지 정도 일 것 같은데요. 다음과 같습니다.

~~**댓글 기능** 이 사라졌습니다. 댓글을 놔둘까 말까 고민을 조금 했는데요. 블로그를 방문해 주시는 숫자 대비 댓글의 수가 미미한데다, 조금 상세한 질문은 대부분 email 로 주시는 경우가 더 많았기 때문입니다. 이 부분은 후에 고민해보고 추가한다 싶으면 github issue 등의 기능을 좀 알아볼까 생각중 입니다.~~

**2022.12.30** 기준 [https://utteranc.es/](https://utteranc.es/) 기반의 `댓글기능`을 추가했습니다.

**공유하기** 기능을 추가했습니다. 사실 상세페이지에 들어가면 얼마든지 공유가 가능하지만, 공유하기 버튼이 있는경우 모바일 대응이 잘 되어있다면 참 편하다고 느껴 추가했습니다. 많이 사용하실지는 모르지만 일단 예쁘니 맘에듭니다.

**소개** 페이지에 간략한 커리어 관련사항을 기재 했습니다. 수가 많은것은 아니나, 이 블로그를 통해 연락을 받은경우 제 커리어나 회사에 대해 궁금해 하시는 분들이 종종 계셨습니다. 커리어야 뭐 특별할것도 없고, 숨길것도 없는지라 그냥 보실수 있게 해 보았습니다.

# 마치며

조금더 좋은, 양질의 글을 공유하기 위한 노력을 꾸준히 하겠단 말을 마지막으로, 이 삭막한 블로그에 남겨주셨던 감사한 댓글을 아래 첨부합니다. 글 읽어주셔서 감사합니다.

# 그간 남겨주신 댓글들

```
# WebServer 와 Application Layer(with. golang)
  ㄴ dongko	너무 좋은 내용입니다! 좋은 생각거리를 주셔서 감사합니다 :)
      ㄴ John	좋게 읽으셨다니 저야말로 감사합니다. 여력이 난다면 실습편으로 찾아뵙겠습니다:)
```

```
# 개발 중 조심해야 할 것들(2)
  ㄴ 고헤일리 때론 단순함에 집중하자.. 새겨듣겠습니다.
      ㄴ John	아 헤일리ㅋㅋㅋㅋㅋㅋㅋㅋ

  ㄴ 뉴비 좋은 글 감사합니다! 라이브러리에 대해서 다시 생각하게 되는 계기가 되었네요 😊
      ㄴ John	좋게 읽어 주셔서 읽어주셔서 감사합니다 🙂
```

```
# 개발 중 조심해야 할 것들(1)
  ㄴ ㅇㅇ
      블로그 정말 잘 구성하셨네요. 저는 프론트 React Typescript + 백엔드 Go로 블로그 만들려다가
      이것저것 기능 구현하는데 시간이 많이 걸림을 깨닫고 현재 파이어베이스의 힘을 조금 빌려서 개발하고 있습니다 ㅎㅎ
      현업에서는 수천 개의 상태를 다룰 수 있어야 하는군요.
          ㄴ John
              요세 정신이 없어서 글을 너무 늦게 봤군요.
              저도 Typescript 와 golang 을 참좋아하는데 좋은 결과물이 나오시길 바랍니다.
              바쁜 시기만 지나면 글을 조금더 자주 써볼게요.
              감사합니다.

  ㄴ ss
      이제막 1년 되어가는 프론트,백엔드 개발자입니다
      처음 입사했을때 꽤나 규모있는 프로젝트를 혼자 맡았는데 시간은 급하고해서
      계속해서 일단 기간에만 맞춘다고 아무렇게나 동작만하면 되는식으로 짜게 되더라고요
      아직 갈 길이멀지만 언젠가 저도 실력있는 개발자가 되고싶네요
          ㄴ John
            저도 늘 노력중이랍니다.
            저도 일정이 빠듯할땐 쉽지 않은경우를 종종 겪었어요 ㅎㅎ
            같이 화이팅 하시죠. 글 읽어주셔서 감사합니다.
```

```
# Goodbye Next.js, Hello React.js
  ㄴ 나그네
      말씀처럼 개인프로젝트나 공부 목적이라면 직접 다 하나하나 만들면 좋지만
      많은 사람과 협업을 위해서는 통일성과 제약성 그리고 빠른 개발을 위해 많이 쓰는 프레임워크를 쓰는 게 낫지요..
        ㄴ John
            우선 글을 읽어주셔서 감사합니다!! :)
            네 저 역시 일정 부분은 같은 생각입니다. 위 글에서도 언급했지만, React.js 를 이용한 SSR 을 구현시
            저는 주위 사람들에게 우선적으로 Next.js 를 권합니다. 아울러 제가 팀 내에서 SSR 을 구현해야 한다면 Next.js 를 우선적으로
            고려해 볼 것입니다. 다만 개인적으론 위 과정들에 익숙하기 때문에 직접 ssr 을 구현하는 것을 선호하는 편이고,
            개발 속도에서도 별 차이가 나지 않습니다.

            통일성과 제약성, 빠른 개발이란 사항은 각 기술의 특성과 팀원들,
            혹은 팀별로 모두가 익숙한 부분이 다를 수 밖에 없는 경우가 많습니다.
            때문에 저희 팀의 경우 새로운 기술을 도입하거나 결정을 해야할 때,
            특별한 문제가 있지 않은 이상 무엇보다 팀원들의 의사를 가장 중요히 반영해 각 사항들을 결정합니다.
            (물론 해당 기술의 생태계나, 대중적인 개발자들의 선호도는 고려합니다.)

            추가로 이번에 업데이트 예정인 react v18 의 발표사항과 이전 발표등에서 보여준 변화의 방향성 등을
            개인적으로 판단했을때, 직접 SSR을 구현하는 방향을 선택하게 되었습니다.
            하지만 앞으로 제 생각이 어떻게 변경될지는 모르겠네요. loadable 이 React 의 업데이트를 따라가지 못한다면 다시 이동할지도요 ㅎㅎ
            글 읽어주셔서 감사합니다 :)

  ㄴ ㅇㅇ	글 잘보았습니다~
      ㄴ John	감사합니다 :)
```

```
# 블로그 개발 후기 3 - Next.js
  ㄴ Websterking 좋은 글 잘보았습니다 ~ z
        ㄴ John	감사합니다~

  ㄴ cam Nextjs로 블로그 개발하는데 많은 도움이 되었습니다 감사합니당 !
        ㄴ John	도움이 되었다니 기쁘네요. 읽어주셔서 감사합니다 :)

  ㄴ gamguma 좋은 내용 정말 감사합니다!! 행복한 연말 보내시길 바랍니다 :)
        ㄴ John	읽어주셔서 감사합니다. 이제 곧 새해에요. 복 많이 받으세요 :)

  ㄴ Teddy
      안녕하세요 글 잘봤습니다. 혹시 serverless-nextjs를 통해 배포를 하시면 SEO가 잘 잡히나요??
      저도 패키지(정확히는 serverless-nextjs-plugin 말고 serverless-nextjs 컴포넌트)를 이용해서
      Lambda@edge를 이용하고 있는데 cold start 때문에 크롤러가 데이터를 잘 받아가지 못할 수 있다는 몇몇 글들을 보게 됐어요.
      가령 이런 링크들 입니다.
      https://stackoverflow.com/questions/61433306/cheapest-way-to-deploy-a-react-app-using-nextjs-ssr-on-aws
      https://github.com/serverless-nextjs/serverless-next.js/issues/1388
      크롤러가 다녀가는데 보통은 며칠이 걸리는건지.. 혹은 해당 이슈 때문인지 최초 페이지를 제외하곤 검색 결과 노출이 안되고 있습니다.
      혹시 이부분 해결하셨다면 어떤 접근을 하셨는지 여쭤봐도 될까요?"
        ㄴ John
            1. 일단 cold start 문제를 해결하기 위한 방법은 여러가지가 있지만 저는 적용해두지 않은 상태입니다. 크롤러가 다녀가는데 수일이 걸릴수 있는건 사실이 맞구요.
            2. 저는 현재 rss 나 sitemap 등을 제공하기 때문에 해당 자료역시 등록을 해둔상태인데, 크롤러가 데이터를 긁어가는데 도움이 됩니다.
            3. nextjs 의 방식을 그대로 사용하셔서 개발을 진행하셨다면 페이지당 ssr 이 적용될테니 각 페이지별로 seo 가 적용될겁니다.
            4. 검색엔진에 노출빈도는 사실 굉장히 여러가지의 요소가 적용되기 때문에  ssr 하나의 요소만으로 판단하기는 어렵습니다. 다만 시간이 지나면 검색엔진에 노출이 될것 같다는 생각이 드네요.
               글에 관심을 갖아주셔서 감사합니다^^ 더 궁금하신 부분이 있다면 메일이나 댓글 부탁드려요:)"
        ㄴ John
            아울러 당연히 작업해두셨을것 같긴한데..
            header 부분에 meta tag 작업을 조금 꼼꼼히 해두셔도 도움이 많이 된답니다! 도움이 되셨으면 좋겠네요~
              ㄴ Teddy
                  답변 정말 감사드립니다. 리전별로 배포가 되어있어 latency에 따라 국가별 크롤러가
                  타임아웃될 수 있다는 점이 좀 걸리지만 적어도 국내 서비스는 국내 검색 결과로 잘 SEO되는걸로 확인이 되네요.
                  serverless-nextjs 저렴하면서도 정말 괜찮은것 같습니다. 다시한번 좋은글 감사드립니다!

  ㄴ 김용희
      안녕하세요 웹팩을 도입하려는 초보 개발자입니다.
      Next.js 와 react 가 초기 셋업 부분이 다른점이 있을까요? 처음이라 너무 감이 안잡히네요..ㅜ
        ㄴ John
            일단 어떤 방식으로 어떤 부분을 설정 하시려는지 알아야 도움을 드릴 수 있을것 같습니다.
            react 프로젝트를 webpack 과 함께 구성하는 방식은 너무나 여러가지 이기때문입니다.
            개인적으로 Next.js 프로젝트 초기 구성시 저는 공식홈페이지에 있는 예시의 방법을 사용합니다.
            추가로 궁금하신 부분이 있다면 댓글이나 메일 남겨주세요! 답변 드릴수 있는 부분이라면 최대한 답변 드리겠습니다.
```

```
# 블로그 개발 후기 2 - GraphQL(with. REST API)
  ㄴ hi graphql은 전혀 모르고 본 글인데 어떤 개념인지 이해하기 쉽네요. 잘 봤습니다 :)
        ㄴ John	감사합니다!
```

```
# 블로그 개발 후기 1 - Typescript
  ㄴ Tei 전설의 시작...
        ㄴ Fsd 고마워요 ㅋㅋ

  ㄴ roach Typescript 전설의 개발자..
        ㄴ John	고마워요 로치 ㅋㅋ 태의를 닮아가는군요

  ㄴ 댓글	혹시 댓글 구현은 어떻게 하셧나요?
        ㄴ John	정확히 댓글의 어느부분을 질문 주신지 모르겠어서 답변을 드리기가 어렵네요ㅜㅜㅜ
          우선 소개 페이지 github 에 코드가 모두 공개되어 있습니다.
          참고해보시고 궁금한게 또 있으시다면 메일이나 댓글 남겨주세요! 감사합니다.
```


블로그를 새로 만든 이유와 관련 기술에 대해 이야기 합니다(이전 댓글들은 여기 기록해 두었습니다)

블로그 리뉴얼, 그리고 기술 이야기(with. NextJS)

# Table of Contents

# 글을 시작하며

안녕하세요. 이 블로그를 운영하기 시작한 이후로, 처음 제 개인적인 이야기를 적는듯 합니다.

그동안 적지 않은 일이 있었습니다. 일단 가장 큰일은 `이직` 을 하게 되었습니다. 이 과정에 제 개인적인 생각들과 앞으로의 방향성에 대한 여러가지 고민을 해 볼 수 있었죠. 그덕에 본격적으로 다시 집중해서 공부할 영역을 정할 수 있었습니다.

`블로그`를 새롭게 `개편`하게 되었습니다. 디자인과 기능등에 작은 변경사항 들이 생겼죠. 큰 이슈는 없었지만, 이번에 겪은 소소한 팁들을 공유할까 하는데요. 큰 덩어리를 놓고 보자면 React.js + Node.js 로 직접 SSR 을 구현해 놓았던 블로그를, 처음 배포했을 때와 같이 Next.js 로 바꾸었습니다. 이부분에 대한 자세한 이야기는 따로 글을 적을 생각입니다.

그럼, 본격적인 이야기를 시작해 보겠습니다.

# 이직

저는 약 5년간 백화점에서(흔히 유통업계라 불리는) 옷을 판매하는 일을 해왔습니다. 그리고 28에 처음 코딩이라는 것을 시작하였죠. 어쩌다 보니 판교에서 개발로 돈을 벌고 있었고, 어쩌다 보니 약 3년 7개월 이라는 시간을 근무한 회사를 떠나 이직을 하게 되었습니다.

제가 이전에 근무하던 회사는 `생활연구소` 라는 회사입니다. 주로 `청소연구소` 라는 이름으로 서비스 중인 앱의 Backend API, DevOps, Web/Mobile Frontend, Backoffice Back/Frontend 에 관한 일을 했습니다. 팀은 **Server 팀** 이라고 불리는 팀에 있었으나 사실상 흔히들 **Full Stack Engineer** 라 불리우는 롤을 맡고 있었죠. 개인적으로 특별히 맡고 있던 역할은 사내 `매출`, `정산`과 관련된 **모든 엔지니어링**을 담당하고 있었습니다.

너무 많은 부분을 맡고 있지 않았냐구요? 사실 저는 개발자로서의 첫 커리어를 시작할 때 모든것을 다 할 수 있는 회사를 원했습니다. 기본적으로 서비스를 나 혼자 운영할 수 있는 스킬의 기본을 쌓아보고 싶었죠. 그리고 그 시간동안 참 많은것들을 경험했습니다.

## 왜 떠나게 되었는가

개인적으로 생활연구소 라는 회사는 정이 굉장히 많이 든 곳이었습니다. 제가 입사할 당시 저를 포함한 직원이 채 20명 이 되지 않았었고, 시리즈 투자는 받기전 이었습니다. 저는 이 회사의 창업멤버를 제외한 **첫 웹 개발자** 로 입사한 사람이었죠. 이후 함께한 시간동안 회사는 **시리즈 A, B, C 투자**를 받았고, 직원은 어느덧 **100명** 에 가까이 늘어나 있었습니다.

제게 3년 7개월 이란 시간은, 이 모든 것들을 만들어 나가기 위해 동료들과 함께 무던히 노력 했던 시간이었습다. 어느덧 한국 이름보다 요한(john) 이라 불리는 것이 더 익숙해져 있었을 정도이니 말입니다. 이렇게 정이 든 회사를 떠나며 이직을 결심한 계기는 개발자로서의 `커리어`에 대한 고민이 가장 큰 영향을 주었습니다.

좋으나 싫으나 4년차의 개발자가 된 저로서는 어느 한 분야에 집중을 해야 할 시기가 된 것 같다는 생각을 했습니다. 그리고 Web 잡부로 일해온 저로서는 이제 집중해야 할 것을 찾아야 겠다는 생각을 하는 시기가 되었죠. 결과적으로 저는 `Web Frontend` 라는 분야를 선택하게 되었습니다. 그렇다고 흔히 말하는 **Backend** 에 관련한 공부를 놓을 생각은 없는데요. 그 이유는 제가 생각하는 **Frontend** 라는 분야의 특성이 사실 Backend 와 다르다면 다르고, 어찌보면 또 **다르지만은 않다** 이기 때문입니다.

# 앞으로의 계획

앞으로의 계획은 굉장히 단순합니다. 저는 제가 가장 잘 하는 것을 꼽으라면 안되는게 될때까지 그냥 꾸준히 하는걸 잘합니다. 그래서 그냥 앉아서 계속 공부할 생각입니다. 아울러 새로운 회사에 도움이 되어야 겠죠. 이 조직에 얼마나 더 있을지, 정확히 어떤일을 더 하게될지는 아직 모르지만 입사한지 얼마 되지 않은만큼 일단은 적응에 힘을 쓰려 합니다. 그리고 어서 도움이 되는 동료가 되어야겠죠.

추가로 소홀했던 블로그에 글을 좀 열심히 적을 생각인데요. 제가 공부했었지만 잊어버린(Network, 브라우저, Javascript, DevOps 관련 등...) 부분들 중 웹개발을 할 때 꼭 알아야 한다고 생각하는 부분들에 대한 공부를 다시 집중해 할 생각입니다. 특히나 Javascript 의 딥한 부분이나, 메커니즘 등이 가물가물하여 당분간 그 부분에 집중할까 합니다. 여기서 제가 생각하는 `Frontend` 개발자가 알아야 한다고 생각하는 부분에 대한 이야기를 조금 해보겠습니다.

## Frontend 개발자는 어디까지 알아야 하는가

이부분은 개인적으로 할말이 많은 부분입니다. 특히나 주니어 분들. 혹은 취준생 분들께 꼭 말씀드리고 싶은 이야기 입니다. 처음 취업을 준비할 시기에 Javascript, CSS, React, Vue 등등등 과 더해 Browser, Network 등등의 공부를 누구나 할 것으로 생각이 됩니다. 당연히 javascript 잘 알아야 겠죠. 실무자 라면 평소 팀에서 쓰는 라이브러리도 잘 사용해야 할 것입니다. 라이브러리나 프레임워크 없이 바닐라로 코딩도 할 수 있어야 하구요. 그러나. 저는 그 이후에 이야기를 하고싶습니다.

Frontend 개발자 임에도 불구하고, Backend 를 알아야 한다고 생각하기 때문입니다. 더 나아가 웹 서비스에 대한 전반적인 지식과 운영에 관련한 지식을 꼭 갖추어야 한다고 이야기 드리고 싶습니다. 물론 이건 Backend 개발자라 하더라도 제 생각은 크게 다르지 않습니다. Backend 개발자도 Frontend 알아야 한다고 생각합니다.
기본적으로 자기가 집중하는 분야는 진짜 엄청나게 파고, 나머진 적당히 해야한다 라는 이야기를 하고 싶습니다.

### API 를 협의한다면

백엔드 개발자와 API 를 협의한다고 가정해 보겠습니다(REST 로 설계가 되어있다는 가정). 기획에 추가 요구사항이 생긴 덕에 새로운 데이터를 내려받아야 하는 상황입니다. 가령 Frontend 개발자의 시선에서는, 이 데이터는 기존에 부르던 API에 그냥 데이터 하나만 더해서 내려주면 로직상 더 깔끔하게 처리가 가능한 상황입니다. 그러나 Backend 개발자는 굳이 새로운 API 를 하나 더 만들고 이걸 나중에 한번 더 호출해 달라고 요구합니다. 물론 그 이유는 당연히 설명해달라 하면 다 설명 해주시겠죠. 그러나 이때 빠른 납득과 이해를 위해서는 백엔드를 어느정도 좀 알면 좋다는 생각을 자주 합니다.

이를테면 우리가 현재 만드는 서비스의 트래픽이 만만찮다고 가정해보죠. 그럼 메인페이지(예를 들어 home) 라던지 혹은 리스트를 내려주는 API 를 작성할때, 교과서에서 배운대로 코딩을 하면 디비가 그냥 죽어버리는 경우를 종종 만날 수 있습니다. 간단히 예를 들다면 이런 쿼리를 날린달까요.

```sql
SELECT * FROM post ORDER BY updated_at DESC;
```

물론 slave 달고, 캐시하고, 이때 캐시전략은 어떻게 해서 여긴 MongoDB 쓰고, 여긴 그냥 Redis 쓰고, 뭐 어쩌구의 영역이야 그정도 트래픽을 감당해야 하는 서비스는 당연히 잘 되어있겠죠. 그럼에도 불구하고 불가피한 상황이 생깁니다. 이부분을 깊게 들어가면 이야기에 주제에서 너무 벗어나는 듯 하여 이 이야기는 여기까지만 하겠습니다.

혹은 조회가 정말 많은 메인 페이지에서는 DB 를 최대한 때리지 않게 설계를해서 부하를 감당케 해야하는 상황 인지라, 처음에 부르는 API 에서 DB 를 때려 동적으로 데이터를 만들어내는 로직을 넣기가 곤란한 상황이 종종 있습니다. 어떨땐 DB 를 때리는 로직을 넣기는 하지만 내려주어야 하는 데이터를 만들기 위해, 상대적으로 부하가 큰 로직을 작성해야 하는 경우가 더러 있죠. 저는 이럴때 클라이언트 개발자 분들께 양해를 구하고, 협의를 요청했었는데요. 이부분을 이해해주시는 분들과는 정말정말 협업할때 수월했습니다.

물론 훌륭한 Frontend 엔지니어 분들이 많기에 이런 부분을 모른다는 의미로 한 이야기는 **아닙니다.** 다만 Web 서비스 하나가 전체적으로 어떻게 돌아가는지에 대한 메커니즘을 잘 이해한다면 협의를 하는 과정이나 기타 스펙을 잡아나아가는 과정에서 빠른 의사결정을 하는데에 도움이 될 것이란 생각입니다.

이부분은 Backend 엔지니어도 마찬가지 입니다. Figma 에 나타난 flow 상 중간저장 등이 명시되어 있거나, submit 이 한번에 일어나는 것이 아니라 쪼개서 일어나야 하는데 이걸 무시하고 그냥 하나의 통 API 로 설계를 해버린다면 의도치 않게 까다로운 상황이 생기겠지요.

말의 요지는 Web Service 를 만드는 개발자라면, 분야 불문하고 이 Web Service 전체가 어떻게 돌아가는지에 대한 전체적인 이해를 하는것이 좋지 않을까 란 생각을 저는 합니다.

### 운영(Operations)과 최적화의 영역을 생각해보자 (with.Server Side Rendering)

이부분은 특정 주제(Server Side Rendering) 에 대한 이야기를 나눌때 제가 참 아쉽다 느낀 부분이 많았는데요. SSR 이 마냥 장점만 있는것은 아닙니다. 일단 제가 `SSR` 이 가지는 가장 큰 트레이드 오프라 생각하는 부분은 Server 를 `운영` 한다는 부분입니다. 만약 작은 서비스라 하면 크게 문제가 되지 않을 수도 있습니다. 하지만 순식간에 수천 ~ 수천만, 혹은 그 이상의 request 가 일어나는 서비스의 SSR 을 진행한다면 어떤 부분을 고려해야 할까요? 어마어마한 request 가 짧은 시간내 발생할 가능성이 있다면요.

말그대로 `대용량 트래픽 처리` 에 대한 부분을 꼭 고려해야 합니다. 물론 `SSR Server` 가 `Backend API Server` 에 비해 수평 확장에 대해 대체적으로 유리하다는 것은 맞다란 생각입니다. 허나, 이부분은 정적 페이지로 서비스 하고, 이부분은 나중에 데이터를 페칭하도록 해서 CSR 로 화면을 그리도록 하자. 이부분은 동적으로 바뀌어야 하는 데이터가 있지만 완전히 실시간 성일 필요는 없으니, 캐시를 도입해서 부하를 줄이자 라는 등의 의사결정을 위한 논의가 필요합니다. 아울러 팀원들이 이에대한 경험이 없다면 섣불리 도입했다가 오히려 더 큰 폭탄과 함께 할 수도 있는 부분이란 생각입니다.

너무나 당연한 부분입니다만. 트래픽에 대한 스케일링과 여러 대응이 제대로 되지 않는다면, 단지 first paint 만 빨라진채 밀려오는 요청을 힘겹게 처리하는 서버의 응답만을 기다리고 있는 브라우저를 사용자는 보게 될 것입니다. 오히려 더 **느려질 수도 있다** 는 뜻입니다. 단순히 속도만 느려진다면 차라리 다행일듯 싶은데요. 서버가 뻗어버려서 서비스에 장애가 나는 상황을 만들지 않으려면 미리미리 스케일링 처리도 하고, 모니터링도 잘 하고, 부하가 친다싶으면 슬랙에 알림도 쏴서 어서 지켜보라는 등등의 대비도 잘 해야겠죠.

제가 가장 아쉬웠던 부분은 그냥 우리 페이지 뜨는 속도가 느리니 SSR 을 도입하자 란 단순한 주장을 들을때 였는데요. 페이지가 왜 느린지 프로파일링을 제대로 해보지도 않고 이런 말을 하는것은 너무나 섣부른 접근이라는 생각입니다. 아니 지금 느린게 js chunk file 이 커서인지, image load 가 느린것인지, api call 이 느린 이유인지를 정확히 알지도 않은채 무작정 도입 한다니요. 속도를 개선하거나, 사용성을 개선하기 위한 방법은 굉장히 다양합니다.

- Code Splitting 이 되어있다 해도, main chunk 가 크다면 `tree shaking` 이 제대로 되고는 있는지 분석해보고, main chunk 의 사이즈를 줄이는데 우선적으로 힘을 쓰면 됩니다.
- image file 에 대한 로드가 느리다면 이에대한 `resizing`, `CSS Sprite`, `lazy loading` 등과 `CDN` 등을 도입하면 됩니다.
- 혹은 그저 image 의 width 와 height 에 해당하는 `skeleton` 만을 미리 그려주어도 `Layout Shift` 를 굉장히 많이 개선할 수 있습니다.
- 이외에도 수없이 많은 방법이 있겠지요.

저는 위와같은 우선적인 개선사항보다 더 큰 이점이 있을때. 그리고 위의 사항이 이미 충족되었으나, SSR 로 얻는 추가적인 요소가 있을때 도입하는 것이 SSR 이란 생각입니다. 그리고 회사입장에선 가장 중요한 문제중 한가지인 `비용` 문제를 생각해야 합니다.

기존에 CDN 을 이용해 웹 서비스를 제공하던 회사라고 가정하겠습니다. 이때는 CDN 비용만을 생각하면 되었습니다. 하지만 이제 Server 를 운영하는데 비용이 추가됩니다. 사용자가 정말 많은 서비스에 화면을 그려내는 `SSR Server` 의 비용을 생각한다면, 만만찮을 것입니다. 비용만이 문제가 아닙니다. 이를 운영하고 관리하는 인적 자원역시 더 필요할것은 자명한 사실입니다.

React.js 프로젝트를 Next.js 로 이관하고 빨라졌다고 해서 이게 모두 SSR 덕이란 생각은 섣불리 하지 않으셨으면 좋겠습니다. 실제로 Next.js 가 해준 작업들 중에 image 최적화, ssg, code splitting 등 어느 부분이 내 어플리케이션에 속도를 높여 주었냐가 더욱 중요한 아젠다 입니다.

### 운영(Operations)과 최적화의 영역을 생각해보자 (with.Edge Computing)

직전 언급한 사항들을 상쇄해 내고도 더큰 비즈니스적, 퍼포먼스적인 이득이 있냐를 우선적으로 고려하는 것이 저는 맞다고 생각합니다. 하지만 위의 요소가 전부다 충족되어 이제 `SSR Server` 를 운영한다고 가정 해보겠습니다. 그럼 우리 Frontend 개발자들에겐 어떤 지식이 필요로 하게 될까요?

얼마전 2022 FEConf 에서도 그렇고, 사실 수년전부터 이런 이야기는 참 많이 대두 되었습니다. `웹의 미래는 엣지다` 라는 뉘양스의 이야기 말입니다. 저는 이 문장에 격하게 공감하는 1인입니다. 이제는 국내에서도 이런 이야기는 심심찮게 들립니다. 관련 내용에 관하여, 비교적 최근 접한 링크 두가지를 첨부합니다.

- [GeekNews](https://news.hada.io/topic?id=7575)
- [FEConf Track 마지막 김혜성님](https://www.youtube.com/watch?v=jZNk-Ncez6E)

그럼 이어서, 우린 뭘 공부해야 할까요?  
Internet 서비스의 근본적인 부분을 이해해야 한다는 생각입니다. 예를들어 수많은 MicroService 로 이루어진 서비스가 있다고 가정해 보겠습니다. 이때 BFF 에서 GraphQL 등을 사용한 고도화를 직접 시도해 볼 수 있지 않을까요?

혹은, 각 edge location 별 커스텀 함수를 태우는 작업을 Frontend 엔지니어들이 하면 어떨까요? 이미 aws lambda@edge 등을 통한 이미지 리사이징 등의 기능은 너무나 흔하게 사용되고 있습니다. 저는 앞으로 이 부분이 더욱 발전될 것이라 생각하는데요.

이에따른 Server 의 스케일링, CDN, 그리고 이로인해 신경써야 하는 요소에 관한 공부를 한다면 조금더 대체 불가능한 개발자로서 성장해 나아가지 않을까란 생각을 합니다. 저역시 너무나 모자란 부분이 많기에 꾸준히 공부를 해야하지만 Frontend 란 분야는 제가 생각하기에 참 매력적인 분야입니다.

# 마치며

저는 위 언급한 부분과 같이 기존에 공부한던 부분에서 백엔드에 대한 부분에 비중을 조금 줄이는 대신, 제가 부족하다 느끼는 browser, javascript, node.js, devops 에 대한 부분을 꾸준히 공부하려 합니다.

이전엔, 코드가 아무리 거지같아도 장애는 DB 에서 난다는 말에 엄청난 동감을 하며 query 튜닝에 힘을 써 왔었습니다.  
이제는 Frontend 와 관련된, 한번쯤 공부는 했었지만 기억이 잘 나지 않는 부분을 복습하는 마음으로 다시 공부하고, 그에대한 글을 꾸준히 작성하려 하는데요.

WebService 의 최적화와 Network, 자바스크립트의 깊은부분을 다루는 책을 샀습니다. 한동안 잊고 있던 부분을 다시 부여잡아 보려 합니다. 어서 읽고싶네요. Frontend 개발자로서의 새로운 시작이 어떻게 끝나게 될진 모르지만, 늘 노력하는 개발자가 되고 싶습니다.

이 블로그에도 글을 더욱 자주올려 다른 개발자 분들께 도움이 되고 싶습니다. 무던히 노력하겠습니다.  
긴글 읽어주셔서 감사합니다. 여러분의 코딩이 늘 즐거우셨으면 합니다.


Frontend 개발자로서의 계획과 주관을 담은 생각을 이야기 합니다

이직, 그리고 개발자로서의 커리어에 관하여

# Table of Contents

# 글을 시작하며

안녕하세요! 기술 스택을 선택한 이유와 관련한 질문을 많이 받아 이에 대한 제 개인적인 견해에 관한 이야기를 할까 합니다. 제가 가장 많이 받은 질문. 그리고 가장 많이 읽어주신 글이 `Next.js` 에 관한 글인데요.

이 부분은 실무에서도 실제로 선택을 해야했던 상황이 있었고, 이때에 제가 특정 방식을 선택한 이유가 분명했기에 이를 예시로 제 기술 스택의 선택 기준을 말씀드려볼까 합니다.

기술적인 구현에 관한 이야기보다는 제가 기술을 선택하는 상황과 저의 판단의 기준에 관한 이야기가 될것 같습니다. 아울러 SSR 을 구현시 Next.js 및 React.js 를 제 기준으로 비교하고 생각한 선택기준과 기술적 관점에 대한 글은 아래 두 글의 링크를 참고해주시면 감사하겠습니다.

[블로그 개발 후기 3탄: Next.js](https://devlog.juntae.kim/post/blog-development-review-3)
[GoodBye Next.js, Hello React.js](https://devlog.juntae.kim/post/good-bye-nextjs)

# 현재 내가 SSR 을 구현한다면 어떤 방법을 선택할 것인가

사실 이부분은 실무에서 특히나 상황에 따른 선택을 할 경우가 많을것이란 생각이 드는데요. 대표적으론 아래와 같은 경우가 있을것 같습니다.

## 새로작성하는 프로젝트의 경우

### 실무

#### React.js vs Next.js vs Remix.js

실무의 경우라면 저는 `Next.js` 선택합니다. 이유는 다음과 같습니다.

1. 현재 제가 있는 팀은 모두가 SSR 을 직접 구현하는데 익숙치 않습니다.
2. 일단 수많은 레퍼런스가 있는만큼 믿을만 합니다.
3. 굉장히 잘 만들어진 프레임워크 입니다. 아울러 굉장히 훌륭한 엔지니어분들의 주도하에 관리되고 있는 프로젝트인 만큼 안정성 역시 뛰어납니다.
4. 만약 현재 모두가 직접 SSR 을 구현 하는데에 있어 장인이라 할지라도 이후에 합류하게 될 팀원이 어떤 분이 오실지 알 수 없습니다.
5. 직접 SSR 을 구현시 무언가 특별히 알아야 하는 사항이 있는경우, 이때는 이를 구현한 구성원의 도움(문서)을 받을수 밖에 없습니다. 하지만 Next.js 처럼 잘 관리되고 있는 프로젝트의 경우는 공식문서 및 github 이나 stack overflow 등 기타 여러 부분에서 문제를 해결할 방법을 찾기가 비교적 수월합니다.
6. 말인 즉슨 새로운 분이 오셔도, 혹은 기존 팀원이 와도 모두가 같은 범위 내에서의 자료를 참고하기에 드는 리소스가 비교적 적습니다.
7. 개인적으로 저는 팀이되어 움직이는 실무의 경우 가능한 줄일수 있는 리소스라면 줄이는것이 좋다고 생각하는편 입니다.
8. Remix 를 선택하지 않은 이유는 굉장히 잘 만들어진 기술같기도 하고, 좋아보이긴 하나 아직 상대적으로 젊은 녀석이기에 실무에 섣불리 도입하기엔 이른감이 있지않을까 란 생각이 들어서 입니다.

#### 배포 환경: Docker(ECS, K8S..) vs Serverless Framework(Lambda)

이 부분은 현재 제가 속한 팀과 web 의 활용 정도, 팀의 크기에 의해 굉장히 많이 좌우될것 같습니다. 일단 전 k8s 를 사용해본 적이 없습니다. 해서 ECS 를 사용한다고 가정하겠습니다.

`ECS` 를 선택합니다. 이유는 다음과 같습니다.

1. 현재 제가 있는 회사의 서비스엔 웹의 SSR 을 필요로 하는 비중이 그렇게 크지 않습니다.
2. 위와 같은 이유로 Lambda 와 같은 기술을 사용한다 해도 비용적 문제가 발생할 가능성이 거의 없다고 어느정도 확신할 수 있을것 같습니다. 사실 비용적인 측면은 ECS 와 따져보았을때 어느때즈음 Lambda 가 더 큰 비용이 발생하는지는 아직 경험해 본 바가 없으나 현시점 Lambda 가 무료로 제공하는 request 의 양을 고려 해 본바 충분히 감당 가능합니다.
3. ECS 의 경우 아무리 관리를 안한다 하여도 관리가 필요합니다. 이를테면 트래픽이 확 치솟을 경우 컨테이너를 더 띄운다던지, 혹은 환경을 처음 구성할 때 역시 cloudformation 이나 terraform 등으로 이미 iac 구성이 되어있는 조직을 제외 직접 해주어야 하는 작업의 가짓수가 더 많습니다. 물론 Lambda 역시 동시성 요청에 limit 을 늘리려면 따로 요청을 해야하는 것으로 알고 있으나, 이역시 저희가 아닌 AWS 에 요청을 하면 해결되는 부분으로 알고 있습니다.
4. 위와 같은 이유라면 Lambda 를 선택할것 같지만, 실제 저희 조직내 **SSR** 이 **처음 필요** 할때 제가 **초기 프로젝트의 구조 및 인프라 환경**을 구축 하였는데요. 이때 `ECS` 를 선택한 이유는 다음과 같습니다.
5. 이미 회사의 모든 ServerSide 프로젝트가 ECS 위에서 돌아가고 있었습니다.
6. 아무리 작업할 사항이 적다고 하여도 팀원들이 비교적 새롭게 알아야 하는 사항이 늘어납니다. (S3, cloudfront, apigateway ...)
7. 하여 저는 팀원들의 의견을 물어보고 ECS 위에 SSR 을 구축했습니다.
8. 이미 팀원들이 익숙한 기술이 있고, 해당 기술을 선호한다면 선택하지 않을 이유가 크게 없다 생각합니다.

### 개인 프로젝트

#### React.js vs Next.js vs Remix.js

이부분은 정말정말 굉장히 많은 요소가 결정을 짓게 할것 같습니다만. 결론부터 말씀드리자면 저는 **React.js** 는 `빼고` 선택할것 같습니다. 이유는 다음과 같습니다.

1. 상대적으로 React.js 에 비해 Next.js 나 Remix.js 를 Deep 하게 다루어 본적이 없습니다. 개인프로젝트는 또 새로운거 써보는 맛이 있지 않겠습니까.
2. 현재 진행중인 개인 프로젝트에선 그냥 React.js 로 프로젝트를 진행중인데 SSR 을 구현할 생각이 없어서 입니다만. 만약 후에 구현이 필요타면 이땐 코스트를 따져보고 직접 구현하거나 Next.js vs Remix.js 둘중 하나를 선택할것 같네요.
3. 여담으로 이번엔 RTK query 를 사용하는 중인데 회사에서 React Query 는 사용해봤고, 개인적으로 SWR 도 사용해 봤습니다. 아울러 이 블로그는 Apollo client 를 사용해 작성했기에 경험해보지 않은 기술을 써보고 싶었습니다.

#### 배포 환경: Docker(ECS, K8S..) vs Serverless Framework(Lambda)

저는 `AWS Lambda` 를 선택할것 같습니다.

1. 비용적으로 굉장히 이득을 보는 부분이 많습니다.
2. 이미 사용해봤기에 상대적으로 익숙합니다.
3. 트래픽 관리가 거의 필요 없습니다.
4. 이번에 진행하는 개인프로젝트의 서버사이드를 컨테이너로 관리할 예정인데 이부분에서 컨테이너에 대한 경험은 충분히 키울 수 있을것 같습니다.
5. 함께 사용하려고 생각중인 CloudFront 등과 연동이 굉장히 수월합니다.
6. 즉, 저 혼자 모든걸 관리해야 하는 프로젝트이기에 이번 프로젝트에서 제가 공부하고자 하는 부분을 얻을 수 있다면 ops 의 영역을 최대한 배제할 수 있는 스택을 선택할 것 같습니다.

## 이미 작성되어 있는 프로젝트일 경우

이때는 저는 실무이든, 개인 프로젝트이든, 어떤 기술을 선택할 것이다 란 대답을 현재로선 드리지 못할것 같습니다. 기존 프로젝트가 어떤 스택을 사용해 작성되어있는지 모르기 때문에 어떤 방식으로 옮겨가는 것이 코스트를 줄이는 방향인지 현재로선 대답하기가 힘들기 때문이지요.

1. 어떨땐 프로젝트 전체를 새로 파서 작성하더라도 코스트가 적을 수 있습니다.
2. Next.js 가 모두들 익숙하더라도, 이미 기존에 있던 프로젝트가 마이그레이션을 하기에 힘든 상황이 있다면 직접 SSR 을 구현하는 것이 나을 수도 있습니다.
3. 제일 중요한것은 함께 만드는 동료가 있다면 이들의 공감을 얻어내는 것이라 생각하는데, 동료들과 합의된 어떠한 의견을 도출해 내는것에 가장 신경을 쓸 것 같습니다.
4. 다만 전적으로 모든 선택의 권한이 제게 있다면 저는 제가 판단하기에 코스트가 가장 적어보이는 부분을 선택할 가능성이 큽니다.

여기서 중요한 것은 예외의 경우가 있을 수 있는데. 이를태면 지금 너무너무 예전 스택을 사용하고 있어서, 조금만 바꿔서 이를 해결하는 경우 새로운 개발자가 오면 적응하기 힘들다 란 판단이 들 때가 있습니다. 그럴땐 시간만 주어진다면 어쩌면 대공사를 할지도 모르겠습니다. (그래서 리펙터링과 이런 대공사엔 잘 작성되어있는 테스트 코드가 정말 큰 힘이 된다 생각합니다...)

# 마치며

제가 이 글을 작성하는 가장 큰 이유는 Next.js 로 작성되어 있는 블로그를 React.js 로 바꾼 이유에 대한 질문을 종종 들을때. 무조건 이게 옳은 선택은 아니고, 저역시 다른 선택을 하는 경우가 굉장히 많다는 이야기를 하는데 그 이유를 말씀드리고 싶었습니다.

상황에 따라 늘 선택은 달라질 수 있고, 실무라면 나와 함께 코드를 작성해야 하는 팀원. 그리고 앞으로의 채용과 새로운 개발자를 맞이하기에 좋은 방향은 무엇인가를 고민하는것이 가장 중요하다 생각하는 편입니다.

여러분은 어떠신가요? 행여 제 생각과 기준이 궁금하셨던 분들이 계시다면 도움이 되셨기를 바라며, 코딩이 늘 재밌으셨으면 좋겠습니다. 감사합니다.


기술 스택 결정에 대한 질문을 받아 작성하는 글

server 짤때 golang 참 재미있고 괜찮습니다

WebServer 와 Application Layer(with. Golang)

# Table Of Contents

# 글을 시작하며

```
현재는 블로그가 다른 기술 스택으로 작성되어 있습니다.
아래 질문에 대한 답변에 해당하는 기술 스택으로 작성된 코드는 github 에 모두 공개되어 있습니다.
```

안녕하세요. 이 블로그를 운영중인 김준태(요한 john) 라고 합니다. 다름이 아니라 제가 이 블로그를 통해 받아온 질문들중 자주 받은 질문을 정리해 간단한 답변을 드릴까 합니다.

사실 제가 쓴 글이 바탕이 되다보니 비교적 비슷한 질문을 많이 받았는데요. 제 글을 읽어주신 감사한 분들의 수고로움이 조금이나마 줄어들까 하는 마음에 이 글을 작성합니다.

아울러 아직 글을 써놓고 정리중이거나 다듬느라 공개되지 않은 글들이 많은데요. 제가 조금더 부지런해 지겠습니다. 아직은 많이 부족한 주니어 개발자 인지라 더욱 열심히 공부해서 도움이 되는 글을 작성하고 싶네요.

추가로 궁금하신 사항이 있다면 댓글이나 이메일 주세요!
(저의 게으름으로 인해 댓글, 답글에 대한 알림을 구현해 두지 않아 이메일 회신이 가장 빠릅니다...)

**Email:** [public.juntae@gmail.com](mailto:public.juntae@gmail.com)

```
제가 꽤 많은 기간동안 이메일 주소를 잘못 적어 놓은걸 이제야 발견했네요. ㅜㅜㅜ
그동안 연락해 주신 분들은 어떻게 주신건지 놀라울 따름입니다.
잘못된 주소로 인해 제게 주신 메일에 대한 회신을 못받으신 분들께는 정말 죄송합니다.
간혹 회신이 늦더라도 답변은 최선을 다해 드리고 있으니, 편하게 메시지 주세요.
```

## 코드 스타일에 관한 질문

이 블로그의 개발 목적은 빠른 오픈 이었던지라... 사실 구조나 코드에 퀄리티를 크게 신경 쓰지 않았습니다. 그래서 요세 작성중인 `madre` 라는 개인프로젝트의 github 주소를 첨부합니다. 해당 프로젝트는 그래도 구조를 신경쓰면서 작성중이랍니다. (사실 아직도 구조를 바꾸는 중이고, 서버에 경우는 언어가 바뀔 수 도 있습니다..)

- server: [https://github.com/rlawnsxo131/madre-server](https://github.com/rlawnsxo131/madre-server)
- client: [https://github.com/rlawnsxo131/madre-client](https://github.com/rlawnsxo131/madre-client)

## Next.js 에서 React.js 로 직접 SSR (블로그) 를 다시 구현한 이유가 무엇인가요? 요즘 Next.js 를 많이 사용하던데 특별한 이유가 있나요?

관련한 내용의 글도 있지만 저는 Next.js 를 상당히 좋은 기술이라 생각합니다.
다음에 또 서버사이드 렌더링을 구현해야 한다면 고려할 생각도 충분이 갖고 있구요.
다만 저는 성향상 구조 설계나 비교적 세세한 컨트롤 등을 직접 하는걸 선호합니다.

아울러 Next.js 를 이용해 서버사이드 렌더링을 구현 하더라도 제가 원하는 스택을 추가하거나, 기능을 넣다보면 커스텀이 필요했습니다. 그리고 이미 `React + loadable-components` 의 조합으로 서버사이드 렌더링을 구현한 경험이 있었고, 상대적으로 Next.js 보다 React + loadable-components 로 SSR 을 구현하는것에 `익숙`했기에 후자를 선택 했습니다.

## React 를 잘 하려면 무엇을 공부해야 할까요?

제가 답변드리기 쉽지 않은 질문중 하나 인듯 싶습니다.
사실 제 기준에 저는 React 를 그리 잘 하는 사람이 아니기 때문입니다.
다만 저는 React 의 기능을 잘 사용하는 것보다 React 가 어떻게 작동하는지. 그리고 React 란 기술이 왜 나오게 되었으며 어떨때 선택해야 하는지를 더 중요하게 생각하는 편 입니다.

감히 조언을 드리자면 저는 React 의 작동 원리나 javascript(with. typescript) 를 깊히 공부하는 것을 더 추천드리고 싶습니다. 아울러 브라우저가 어떻게 동작하고, 이녀석이 화면을 렌더링 할 때 어떤 일들이 이루어 지는지. 혹은 서버로 request 를 날릴때 어떠한 단계를 거치고, 어떠한 부분을 고려하면 좋은지. 등에 관한 웹의 전반적인 부분을 공부하시면 좋을 것 같습니다. 이부분은 저또한 맨날 공부하고 읽어도 항상 까먹습니다...

## Frontend 개발자 이신가요?

현재 재직중인 회사의 팀 특성상 백엔드와 웹 프론트엔드를 모두 다룹니다. 개인적으론 혼종이라 생각합니다.

## Serverless Framework 로 Server Side Rendering 을 어떻게 구현해야 하나요?

짧은 설명으로 적기엔 내용이 다소 많아 이 블로그의 서버사이드 렌더링이 이루어지는 과정만 말씀드리겠습니다. 어서 관련한 내용을 포스트로 작성해야 겠다는 생각이 드네요.

1. 도메인을 찌릅니다. 제 도메인은 **AWS** 의 **API Gateway** 에 연결되어 있습니다.
2. 이때 API Gateway 에 도메인 연결과 함께 트리거를 걸어놓은 **AWS Lambda** 를 호출합니다.
3. 여기서 호출하는 **Lambda** 는 **Serverless Framework** 을 이용하여 작성된 **SSR** 만을 위한 함수입니다.
4. 이제 Application 에서 우리가 직접적으로 관여할 일이 많은 Code 의 영역입니다. 현재 **굵게는** React + loadable-components + Apollo-Client + Redux-Toolkit 에서의 SSR 을 위한 처리가 되어있는 코드가 동작합니다.
5. 위 단계에서 만들어진 결과물을 text/html 형태로 반환합니다. react-dom/server 의 renderToString 함수와 renderToStaticMarkup 함수를 사용하고 있습니다.
6. 이때 첫 화면을 그리기 위한 **html** 파일에 **script** 태그가 심어져 있습니다.
7. 이때 **Splitting** 된 **chunk file** 들은 **Cloud Front** 에 올라가 있고, 파일이 필요한 때 불러오게 됩니다.

## 댓글, 대댓글 은 어떻게 구현했나요?

1. 일단 데이터베이스 comment 테이블의 스키마에 post_id 와 level, reply_comment_id 라는 컬럼이 있습니다. 저는 level 을 3depth 까지만 허용하기 위해 로직에서 제한(0, 1, 2) 을 걸어 두었습니다.
2. 댓글의 대댓글인 경우 reply_comment_id 라는 컬럼에 부모 댓글의 아이디가 저장됩니다.
3. 부모 댓글의 level 을 기반으로 현재 새롭게 만들어진 댓글에 +1 을 해서 level 을 기록합니다.
4. 특정 포스트를 가져올 때 해당 포스트 아이디에 매핑되어 있는 comment 를 가져옵니다.
5. 이 때 가장 최상위 댓글을 기반으로 id 와 reply_comment_id 만을 골라냅니다.
6. 위에서 골라온 댓글을 기반으로 reply_comment_id 를 이용해 최상위 댓글의 댓글을 골라내고, 이 과정을 한번더 반복하 가장 하위 댓글을 골라냅니다.
7. 이렇게 3번의 select 로 찾아낸 댓글을 application 단에서 조인합니다.
   그럼 아래와 같은 구조의 데이터가 만들어 집니다.

```json
{
  "comments":[
    {
      "id": 1,
      "level": 0,
      ...
      "replies": [
        {
          "id": 2,
          "level": 1,
          ...
          "replies": [
            {
              "id": 3
              "level": 2
            }
          ]
        }
      ]
    }
}
```

## 몇년차 이신가요?

2019년 부터 현업에서 일을 한 3년차 개발자 입니다.

## 메인 언어가 무엇인가요?

코딩을 시작은 java 와 Spring 으로 했으나 현재 가장 익숙한 언어는 javascript 와 typescript 입니다. backend 는 node.js 를 가장 익숙히 다루고, 프론트 엔드는 React.js 를 이용해 개발하는 것을 선호합니다. 요즘은 golang 에 관심을 갖고 공부중인데요. golang 에 대한 글도 적어보겠습니다. 아주 매력있는 언어랍니다.

# 마치며

위 답변이 도움이 되셨으면 좋겠습니다. 아무래도 여태는 글의 양도 그렇고, 상대적으로 뾰족한 주제에 대한 양질의 글을 쓰지 못한것 같습니다. 반성하고 더욱 좋은 글을 작성하도록 노력해 보겠습니다. 감사합니다.


가장 자주받은 질문을 정리해 보았습니다

자주 받은 질문 정리

# Table of Contents

# 글을 시작하며

안녕하세요 정말 오랜만에 글을 씁니다.
한동안 `Next.js` 로 작성되어 있던 제 블로그의 `Client` 기술 스펙을 변경했는데요.

이번엔 `SSR` 을 위해 **Next.js** 로 작성되어 있던 프로젝트를
`React + @loadable/component + Koa` 로 전환하며 느낀점들과 바꾼 이유에 대한 이야기를 할까 합니다.

Next.js 사용에 대한 후기가 궁금하시다면 [블로그 개발 후기 3탄:Next.js](https://devlog.juntae.kim/post/blog-development-review-3),
코드가 궁금하시다면 [이 링크](https://github.com/rlawnsxo131/devlog-client) 를 참고해 주세요.

현재 React.js 로 SSR 을 구현한 코드는 [이 링크](https://github.com/rlawnsxo131/devlog-client-v2)를 참조해 주세요.

# Next.js 를 버린 이유

혹시 [이전글](https://devlog.juntae.kim/post/blog-development-review-3) 을 보신다면 아시겠지만 저는 **Next.js** 가 상당히 좋은 기술이라 생각합니다.

그럼에도 불구하고 왜 번거로움을 감수하고
`React` + `@loadable/component` + `Koa` 로 직접 **SSR** 을 구현했을까요?
번거로운 작업이 꽤나 있다는걸 알면서도 바꾼 이유는 사실 개인적인 성향이 가장 많은 영향을 끼친것 같습니다. 저는 제가 작성하는 어플리케이션의 모든 부분을 직접 컨트롤 하는 것을 좋아합니다. 예를 들자면
**Create React App** 이란 명령어 한줄이면 리액트 프로젝트의 구조를 잡아주는 아주 편한 도구가 있음에도,
처음 리액트를 공부하던 시절 이후론 단 한번도 이 도구를 제 프로젝트에 사용한 적이 없는데요.

이유는 다음과 같습니다.

1. 그럴일이 없다면 좋겠지만 어플리케이션이 복잡해지고 고도화 되는 경우, 혹은 SSR 을 직접 구현해야 하는 경우 결국엔 이 설정파일을 까서 커스텀 해야하는 일이 생깁니다.이때 쉽게 만나는 문제가 있습니다. eject 이전엔 모든 의존성을 내가 알지 못한다는 사실입니다. yarn eject 이후 숨겨져있는 수많은 디펜던시들이 드러나게 되는데, build 파일을 만드는데 필요한 의존성이 대다수 포함되어 있습니다. 이말은 내가 프로젝트의 버전을 올리거나 어떤 작업을 할 때 문제가 생긴다면, 결국은 eject 를 해서 현재의 의존성을 알아야 하는 경우가 생기기 쉽다는 이야기 입니다.

2. 추상화가 많이 되어있습니다. 지금이야 CRA 를 써도 eject 이후 설정을 커스텀 하는데 큰 어려움을 겪진 않지만, 지금보다 bundler 에 익숙치 않았을 땐 설정을 파악하는데 한참 걸렸습니다. 이경우 차라리 제가 직접 설정한 파일을 읽는게 더 수월합니다.

3. 같은 코드로 작성한 어플리케이션을 Create React App 과 제가 직접 설정한 Webpack 환경에서 build 하고 bundle 사이즈를 비교해 본 결과 대부분의 경우 별 차이가 없었습니다. 어떨땐 직접 설정한 환경에서의 bundle 파일이 오히려 더 작은 경우도..

4. CRA 초기에만 해도 Sass 나 Typescript 등등 굉장히 많은 요소들의 추가사용을 위해 webpack을 커스텀 해야 했는데요, 지금은 알아서 해주는 부분이 많아진 만큼 굉장히 뚱뚱합니다. 즉 제게 필요없는 설정이 너무 많습니다.

5. 위 언급했듯 bundle 사이즈나 기타 결과물의 차이가 크게 없음에도, build 시간은 더 길어지는 경우가 종종 있습니다.

Next.js 를 버리고 직접 SSR 을 구현하려 마음을 먹은 이유도 비슷합니다.
SSR 시 제가 사용하는 서드파티 라이브러리 들의 특정 처리가 필요한 부분은 Next.js 를 쓰나, React 로 SSR 을 구현하나 어차피 똑같은 처리가 들어갑니다.

거기에 **SSR** 시 데이터에 대한 처리를 해주는 부분은 Next.js 에서 제공해 주는 **getInitialProps**,
**getStaticProps**, **getServerSideProps** 등을 사용해야 합니다.

뭐, 안쓰려고 마음먹고 커스텀한다거나 다른 방법으로 이부분을 처리하려 든다면 얼마든지 방식은 달라질 수 있겠지만 이경우 오히려 그냥 제공해 주는 옵션을 사용하는 것이 정신건강에 이롭단 생각입니다.

Next.js 가 제공해주는 편의성은 상당히 다양합니다.
**Serverless Framework** 로 SSR 을 한다던지 어떤 작업이 필요할 때 플랫폼 측에서 제공해주는 편리한 기능들이 많지만, 이걸 제가 파보지 않는 이상 매직박스 같다는 생각이 들더군요.

아울러 **CRA** 와 비슷하게 어플리케이션이 고도화 된다거나 복잡해진다면, 혹은 커스텀이 필요하다면?
그땐 **Next.js** 측에서 제공하는 Next.config.js 파일에 추가 설정을 작성하게 되는데 이게 제가 직접 **webpack** 의 config 파일 을 작성하는 것에 비해 크게 편하단 생각이 들지 않았습니다.

그래서 이럴바엔 차라리 어차피 안해본것도 아니고 그냥 내가 하자.
란 생각에 직접 SSR 을 구현하게 되었습니다. 이 과정에서 생긴 가장 큰 변화는 사실 **코드레벨**이 아닌,
`Production(AWS)` 배포시의 추가 고려 사항들이었는데요.

어떤 변화가 있었는지, 어떤 차이점이 있었는지 살펴보겠습니다.

# Serverless Framework

제 블로그는 `서버사이드 렌더링` 에 [Serverless Framework](https://www.serverless.com/) 을 사용하고 있습니다. 그리고 이를 위해 Next.js 측에서 제공해주는 Plugin 을 적용하고, next.config.js 에 몇몇 설정을 추가하는 방식을 따르고 있었죠.

하지만 이걸 Next.js 에서 벗어나 직접 구현하며 몇 가지의 작업을 추가로 더 해주게 되었는데요.
간단한 비교를 통해 어떤 추가 작업을 해야 하는지 살펴보겠습니다.

## Next.js

위와 같이 Next 진영에서 지원해주는 요소들을 이용해 Serverless Framwork 배포를 하는경우, 정적파일과 서버사이드 렌더링에 필요한 서버파일을 각각의 `s3` 버킷에 나누어주고, 추가로 SSR 시 필요한 `API Gateway` 역시 알아서 설정하고 만들어 줍니다.

조금더 정확히 말하자면 `Serverless Framework` 로 **BackEnd** 를 배포한다 가정시 내부적으론 `CloudFormation` 을 이용해 각종 설정을 자동으로 해주고, `API Gateway` 등의 기본 설정을 알아서 해주는 부분은 동일합니다. 그러나 **Next.js** 는 애초에 서버에 관한 어떤 작업이 없어도, **next.config.js** 와 **serverless.yml** 파일의 간단한 설정이면( 플러그인도 필요합니다 ) 이 모든 부분이 해결됩니다.

당연히 위에서 이루어지는 몇몇 사항을 직접 처리해 주어야 하는데요. 이어서 살펴보겠습니다.

## React.js + @loadable/component + Koa

일단 SSR 을 위한 설정이나 코드레벨 에서의 작업은 여기서 자세히 다루진 않겠습니다. 위 언급했듯, 우선은 `배포` 시 필요한 `클라이언트용 빌드` 와 `Serverless용 빌드` 가 필요합니다. 아울러 우리가 로컬에서 테스를 하기위한 `로컬 개발환경` 을 위한 설정도 필요하겠죠.

이 말인 즉슨 **어떤식으로 webpack.config 파일을 추상화 하던 배포및 테스트를 위한 네가지 방식의 bundler 설정이 필요하다** 는 의미가 됩니다. 저는 공통로직을 묶고, 파일 갯수를 줄이는 등의 작업을 하지 않고 보통 그냥 4가지의 설정 파일을 따로 만들어두고 사용하는데요. 이 경우 아래와 같은 설정 파일이 나옵니다.

- webpack.config.dev.js: 로컬 개발을 위한 설정
- webpack.config.prod.js : 클라이언트용 어플리케이션 빌드를 위한 설정
- webpack.config.server.js: SSR 역할을 해야하는 어플리케이션 로컬 빌드를 위한 설정
- webpack.config.serverless.js: serverless 환경에서 SSR 역할을 파일의 빌드를 위한 설정

각각의 로컬 테스트를 위해 작성한 방식을 포함하면 4가지가 나오지만 실상 프로덕션 배포시 저는 딱 두가지의 번들파일을 가지고 배포하게 되는데 순서는 다음과 같습니다.

> 클라이언트용 번들 빌드 > S3 로 업로드 > Serverless 용 번들 빌드와 동시에 배포

정적파일을 CloudFront 에 캐싱하는데 저는 이걸 S3 에 올리는 작업을 해주고, 첫 화면 진입시
SSR 역할을 할 번들파일을 Serverless Framework 를 이용해 생성과 배포를 함께합니다.

## SSR 을 어떤방식으로 처리할까?

Serverless Framework 을 사용한 SSR 진행시, 이것도 여러 방법이 있을텐데요.
제가 생각하기에 가장 간단한 방법은 아래와 같습니다.

### SSR 만을 처리하는 middleware 가 응답하도록 하기

람다를 사용하실때 자주 마주하게 되는 형태일 것이란 생각이 드는데요. **SSR** 만을 처리하는 **middleware** 를 작성해 html 과 statusCode 를 return 하면, 응답에 이 값을 넣어 던져줍니다.

```typescript
import { APIGatewayEvent } from 'aws-lambda';
import serverRender from './server/middleware/serverRender';
import qs from 'qs';

export const handler = async (event: APIGatewayEvent) => {
  const query = event.queryStringParameters
    ? qs.stringify(event.queryStringParameters)
    : '';
  const url = query ? event.path.concat('?', query) : event.path;

  try {
    const result = await serverRender({
      url,
    });
    if (!result) throw new Error('Result is null');

    const { html, statusCode } = result;

    return {
      statusCode: statusCode,
      headers: {
        'content-type': 'text/html; charset=utf-8;',
      },
      body: html,
    };
  } catch (e) {
    console.error(e);
    return {
      statusCode: 500,
      body: JSON.stringify({
        msg: 'SSR has crashed',
        e,
      }),
    };
  }
};
```

어렵거나 복잡한 방식은 아닌듯 싶습니다. 서버를 배포할 땐 **Serverless-http** 를 이용한 방식을 사용했지만, **SSR** 만을 처리하는 람다에서는 굳이 그렇게 해야할 이유가 없다고 생각했습니다.

# 마치며

Next.js 를 사용해 서버사이드 렌더링을 구현하는 것 보다, 현재 제가 서버사이드 렌더링을 구현하는 방식이 분명 해주어야 하는 일이 더 많습니다. Next.js 가 알아서 해주던 일을 제가 직접 밖으로 끄집어내 작성한 것과 크게 다를바 없으니까요.

그러나 저는 추가로 진행하는 개인프로젝트 역시 SSR 이 필요하다면 직접 구현하는 방식을 많이 선택할 것 같습니다. 이유는 위에 설명했듯 섬세한 컨트롤이나 설정들을 직접 하는게 성미에 잘 맞습니다.

여러분이 SSR 을 구현하셔야 하는 일이 있다면 저는 우선적으로 Next.js 를 권하고 싶습니다. 아울러 제가 팀에서 SSR 을 구현해야 한다면 Next.js 를 우선적으로 고려할 것 같습니다. 다만 저와같이 모든 컨트롤을 직접 하고 싶다거나, 혹은 공부의 목적이 있어 서버사이드 렌더링을 직접 구현하고 싶다면 한번쯤 해보셔도 재미있을 것이란 생각이 드네요.

읽어주셔서 감사합니다.


Next.js 를 React.js 로 갈아 엎어보았다

Goodbye Next.js, Hello React.js

블로그 개발 후기 3 - Next.js

블로그 개발 후기 2 - GraphQL(with. REST API)

# Table of Contents

# 글을 시작하며

> \*글 작성에 앞서 **이 블로그에 쓰인 모든 기술스택**은 아래 링크를 참조해 주세요.
>
> \*아래 링크를 따라가시면 깃헙 링크에 모든 코드가 공개되어 있습니다.
>
> \*[https://devlog.juntae.kim/info](https://devlog.juntae.kim/info)

개발용 블로그를 직접 만든 이유는 너무 여러가지 인지라 생략하고,
이 블로그를 개발하며 사용한 기술들에 대한 **지극히 개인적인 의견** 들을 **순차적**으로 작성하려 합니다.

첫번째는 **Typescript**입니다.
결론부터 말씀드리자면, 전 앞으로 Javascript로 작성될 수 있는 프로젝트는
가능타면 모두 Typescript 로 작성할 생각입니다.

개인적으로 몇가지 정적타입의 컴파일 언어들을 다루어 보았으나, 이녀석은
이름부터 Type 이 들어가는게 어울린다 할만큼 강타입의 언어란 생각이 가장 많이 드는 언어입니다.

특히나 **Typescript** 에 익숙해지기 이전엔 **Javascript** 로 아무 신경쓰지 않고 작성하던 많은 로직들을
타이핑하느라(특히나 서드파티 라이브러리...) 삽질을 한적도 종종 있습니다.

각설하고 코드로 비교 해보겠습니다.
편의상 예시코드는 최대한 쉽고, 간단한 코드로 살펴봅니다.

# 간단한 코드

## Javascript

아래는 posts 라는 값을 props 로 받아 리스트를 그리는 아주 간단한
리액트 컴포넌트 입니다. 물론 아무런 경고 따위는 뱉지 않습니다.

```tsx
import * as React from 'react';

function Posts({ posts }) {
  return (
    <div>
      {posts.map((v, i) => (
        <div key={i}>
          <span>{v.id}</span>
          <span>{v.title}</span>
        </div>
      ))}
    </div>
  );
}
```

## Typescript

이번엔 타입스크립트 입니다.
만약 위와 같은 코드를 파일 확장자만 **jsx** > **tsx** 로 변경한다면 아래와 같은 에러가 발생합니다.

```
var posts: any
Binding element 'posts' implicitly has an 'any' type.ts(7031)

(parameter) v: any
Parameter 'v' implicitly has an 'any' type.ts(7006)

(parameter) i: any
Parameter 'i' implicitly has an 'any' type.ts(7006)
```

네 그냥 죄다 무슨 타입인지 모르겠다네요. 다 **any** 타입 이래요.
이 코드를 타입스크립트로 작성해 보겠습니다.

```tsx
import * as React from 'react';

type Post = {
  id: number;
  title: string;
};
type PostsProps = {
  posts: Array<Post>;
};

function Posts({ posts }: PostsProps) {
  return (
    <div>
      {posts.map((v, i) => (
        <div key={i}>
          <span>{v.id}</span>
          <span>{v.title}</span>
        </div>
      ))}
    </div>
  );
}
```

편의상 객체의 타이핑은 컴포넌트 상단에 했습니다.
한눈에 보기에도 차이가 쉽게 보입니다.

**Typescript** 는 posts가 어떤 타입들의 배열인지 모르고,
posts 안에 있는 Post 들이 어떤 프로퍼티를 가지고 있는지 타이핑을 해주지 않는다면,

> 난 니가 말하는 값들, 그리고 거기 들어있다는 id, title이 뭔지 알수없으니 타이핑을 해줘!
> 라는 경고문구 혹은 에러를 뱉어냅니다.

여기까지만 본다면 음.. 이게 과연 뭐가 좋은 거지?
라는 생각이 들 수도 있습니다.
그럼 더 간단한 아래 코드를 살펴보겠습니다.

# 더 간단한 코드

## Javascirpt

아래 **sum** 이란 함수는 인자 a, b 를 받고 이를 더해 리턴하는 아주 간단한 함수입니다.
그런데 여기 **문자열 '1'** 과 **숫자 2**를 인자로 전달한다면?
javascript의 특성상 결과는 **문자열 12** 가 나와버립니다.

```javascript
function sum(a, b) {
  return a + b;
}
const result = sum('1', 2);
console.log(result); // 12
console.log(typeof result); // string
```

사실 이런 부분을 이용해 **javascript** 로 어찌보면 유연하고,
정적 타입의 언어에서는 도저히 불가능한 코드를 작성할 수 있지만,
이는 종종 개발자가 생각지 못한 버그를 발생시키기 쉬운 요소중 한가지가 됩니다.

저역시 회사나 개인 프로젝트중 굉장히 복잡한 데이터들을 처리해야 하는
**javascript** 및 **ruby** 코드를 작성할 때, 타입 확인을 소홀히 해 이런실수를 한적이 종종 있습니다.
(사실 로직자체를 복잡하게 짜지 않는게 옳은 방법이란 생각이 드네요 1111)

또는 굉장히 **복잡한 객체**들을 가지고 **수백 or 수천줄 분량의 복잡한 연산을 하는 코드**를 작성하는 경우엔,
개발중 로직이 꼬인부분을 찾기 위해 수없이 디버깅을 돌리곤 합니다. ㅜㅜ
(사실 로직자체를 복잡하게 짜지 않는게 옳은 방법이란 생각이 드네요 2222)

## Typescript

타입스크립트입니다.
일단 저 파일의 확장자만 **ts**로 변경한다면 **너 지금 인자가 any 야** 란 경고를 뱉어줍니다.

```
(parameter) b: any
Parameter 'b' implicitly has an 'any' type.ts(7006)
```

타이핑을 해보겠습니다.

```typescript
function sum(a: number, b: number) {
  return a + b;
}
const result = sum('1', 2);
```

네 저 **sum** 함수에 **문자열 '1'** 을 넣었다고 아래와 같은 경고를 뱉어줍니다.
덕분에 타입을 못맞춰 실수할 일은 없겠네요.

```
Argument of type 'string' is not assignable to parameter of type 'number'.ts(2345)
```

# Server && Client Codes

마지막으로 타입스크립트로 작성된 이 블로그의 서버와 클라이언트 사이드 코드를 간단히 보고 넘어가겠습니다.
편의상 **ServerSide**는 **RestAPI** 로 짜여진 부분의 코드를 참조합니다.

## ServerSide

서버사이드의 코드입니다. 필요없는 부분은 전부 생략했습니다.
이번 코드에서 살펴보실 부분은 딱 한가지, **Parameter** 에 관한 **typing** 입니다.

```typescript
type EnrollPostArgs = {
  id?: number; // 이값은 항상 있나없나 확인하라는 경고
  post_header: string;
  post_body: string;
  short_description: string;
  open_yn: boolean;
  series_id?: number; // 이값도 항상 있나없나 확인하라는 경고
  tags: Array<string>;
};

// 예를들어 아래 참조된 코드중 이런부분
post.series_id = series_id ? series_id : 0;

// 이런식으로 작성하면 경고
post.series_id = series_id;
```

**?** 가 없을 수도 있는값이야 란 부분을 명시해주면
귀신같이 **?** 로 명시한 타입의 값이 들어올 때 값의 유효성을 체크하라고 빨간 밑줄을 그어줍니다.
아래 명시된 주석과 코드를 함께 보신다면 쉽게 이해가 갈 것 같습니다.

```typescript
// ...
type EnrollPostArgs = {
  id?: number;
  post_header: string;
  post_body: string;
  short_description: string;
  open_yn: boolean;
  series_id?: number;
  tags: Array<string>;
};
export const enrollPost: Middleware = async (ctx) => {
  const {
    id,
    post_header,
    post_body,
    short_description,
    open_yn,
    series_id,
    tags,
  } = ctx.request.body as EnrollPostArgs;

  // start transaction
  await getConnection().transaction(async (tm: EntityManager) => {
    try {
      const postRepo = tm.getRepository(Post);
      const postHasTagRepo = tm.getRepository(PostHasTag);
      // 아이디가 있을지 없을지 모르니 확인이 필요함
      const post = id ? await postRepo.findOne(id) : new Post();
      if (!post) {
        ctx.status = 400;
        return;
      }
      let released_at = undefined;
      if (open_yn && !post.released_at) {
        released_at = new Date();
      }
      if (post.released_at) {
        released_at = post.released_at;
      }

      post.post_header = post_header;
      post.short_description = short_description;
      post.post_body = post_body;
      post.open_yn = open_yn;
      post.released_at = released_at;
      // 여기도 series_id가 있을지 없을지 모르니 확인
      post.series_id = series_id ? series_id : 0;
      await postRepo.save(post);

      if (!tags.length) {
        await postHasTagRepo
          .createQueryBuilder()
          .delete()
          .where('post_id = :id', { id: post.id })
          .execute();
      }

      // ...

      ctx.body = {
        post,
      };
    } catch (e) {
      ctx.throw(500, e);
    }
  });
};
```

## Client

다음은 게시글 리스트를 그려주는 클라이언트 사이드의 코드입니다. 이번에도 한부분만 살펴보겠습니다.
**val** 에 **PostType** 이란걸 명시해 주었습니다. 이렇게 타이핑을 하지 않으면 **val** 가 **any** 라며 경고를 합니다.

```tsx
const { loading, error, data } = useQuery(GET_POSTS, {
  variables: {
    tag: query.tag,
  },
});

<>
  {data.posts.map((val: PostType, idx: number) => (
    <PostCard key={`${val.id}${idx}`} post={val} />
  ))}
</>;
```

저는 귀찮아서 위와같이 작성했지만 사실 아래와 같이 바꾸어 주어도 무방합니다.

```tsx
// data가 무슨 타입인지 알려주고,
const { loading, error, data } = useQuery<{ posts: Array<PostType> }>(
  GET_POSTS,
  {
    variables: {
      tag: query.tag,
    },
  },
);

// 어쩌면 이녀석은 undefined 일수도 있으니
// 값이 있을때만 그리란 optional 연산을 해줍니다.(data?.<logic>)
<>
  {data?.posts.map((val, idx) => (
    <PostCard key={`${val.id}${idx}`} post={val} />
  ))}
</>;
```

위 작성한 예시 컴포넌트의 모든 코드입니다.

```tsx
import * as React from 'react';
import styled from 'styled-components';
import PostCard from './PostCard';
import { useRouter } from 'next/dist/client/router';
import { GET_POSTS, PostType } from '../../graphql/post';
import { useQuery } from '@apollo/react-hooks';
import Head from 'next/head';
import PostCardsSkelleton from './PostCardsSkelleton';

type PostCardsProps = {};

const { memo } = React;
function PostCards(props: PostCardsProps) {
  const { query } = useRouter();
  const { loading, error, data } = useQuery(GET_POSTS, {
    variables: {
      tag: query.tag,
    },
  });

  if (loading) return <PostCardsSkelleton />;
  if (error) return <div>error</div>;

  return (
    <Block>
      {/* ... */}
      {data.posts.map((val: PostType, idx: number) => (
        <PostCard key={`${val.id}${idx}`} post={val} />
      ))}
    </Block>
  );
}

const Block = styled.div`
  display: flex;
  flex-direction: column;
`;

export default memo(PostCards);
```

# 마치며

위 예시를 위해 작성한 코드는 아주 간단한 코드로 이루어 져 있습니다.
아울러 제가 이 글에서 말하고 싶은부분 또한 아주 단순한 부분입니다.
제가 생각하는 **Typescript** 의 최대의 강점은,

```
타입이 날아다니던 javascript 를 정적타입의 언어로 둔갑시켜줌과 동시에,
약간은 귀찮지만 조금더 안전한 코드를 작성할 수 있게 해준다는 점입니다.
```

물론 이녀석은 간단히 말하면 javascript 에 타입을 씌워주는 역할만을 하기에,
특별히 typescript 를 사용함으로써 로직의 성능이 비약적으로 올라간다거나 하는 일은 없습니다.

네 모던한 신택스로 작성한 javascript 를 컴파일하고 보면 사실 그냥 똑같은 자바스크립트이고,
Typescript 역시 컴파일하고 보면 그냥 똑같은 자바스크립트입니다.

아울러 서드파티 라이브러리를 사용하거나, 혹은 타이핑을 지원하지 않는 라이브러리를 사용하는 경우엔
귀찮은 상황이 종종 있습니다.

자바스크립트에 익숙한 개발자 라면 정말 쉽게 타입스크립트에 익숙해 질 수 있다 생각하지만,
굳이 내가 이걸 사용해야 하나? 란 생각 역시 얼마든지 할 수 있다 생각합니다.

다만 좀더 안정적인 코드를 작성하고, 실수를 줄이고 싶다면 한번쯤은 고려해도 좋은 선택지란 생각이 듭니다.

이후 작성하는 글들은 보다 기술적인 부분들을 조금 더 다루어 보겠습니다.
아마도 다음글은 **GraphQL** 에 관한 내용이 될 것 같습니다.
