hmk run dev

Cloudflare 터널을 이용한 n8n 접근 설정 가이드

hmk run dev — Sun, 11 May 2025 22:06:56 +0900

안녕하세요! 지난 포스팅에서 도커를 이용한 n8n 셀프호스팅 설정 방법에 대해 알아보았는데요. 이번에는 Cloudflare 터널(Cloudflare Tunnel)을 이용하여 더 안전하고 간편하게 n8n에 접근하는 방법을 알아보겠습니다.

Cloudflare 터널이란?

Cloudflare 터널은 공개 IP 주소 없이도 로컬 서버를 인터넷에 안전하게 노출시킬 수 있는 서비스입니다. 기존 방식에서는 방화벽 포트 개방, IP 화이트리스팅, 복잡한 VPN 설정 등이 필요했지만, Cloudflare 터널을 사용하면 이러한 설정 없이도 외부에서 로컬 서버에 접근할 수 있습니다.

작동 원리

Cloudflare 터널은 cloudflared라는 경량 소프트웨어를 사용합니다. 이 소프트웨어는 로컬 머신에서 실행되며, Cloudflare 네트워크와 암호화된 아웃바운드 연결을 만듭니다. 이 연결을 통해 트래픽이 로컬 서비스로 전달됩니다.

쉽게 설명하면:

사용자가 도메인(예: n8n.example.site)에 접속
Cloudflare 서버가 요청을 수신
Cloudflare는 cloudflared 클라이언트(터널)를 통해 요청을 로컬 서버에 전달
로컬 서버가 응답을 다시 터널을 통해 Cloudflare로 보냄
Cloudflare가 사용자에게 응답 전달

Cloudflare 터널의 장점

보안 강화:
- 외부에서 직접 서버에 접근할 수 없어 DDoS나 직접적인 공격 위험이 감소
- 방화벽 포트를 열 필요가 없음
간편한 설정:
- 복잡한 네트워크 설정이나 포트 포워딩 없이 빠르게 구축 가능
- 도메인 관리와 터널 설정을 한 곳에서 처리
무료 SSL/TLS 인증서:
- Cloudflare에서 자동으로 SSL/TLS 인증서를 제공
로컬 개발 환경에서도 사용 가능:
- 개발 중인 웹 애플리케이션을 외부에 공개 가능
- 고정 IP 없이도 사용 가능

Cloudflare 터널 vs 단순 포트포워딩: 간단 비교

Cloudflare 터널의 장점

더 안전함: 서버 IP가 노출되지 않고, Cloudflare의 보안 기능(DDoS 보호, WAF 등) 활용 가능
설정 편리: 공유기 설정 변경 불필요, IP 변경에도 영향 없음
자동 SSL: 인증서 자동 발급 및 갱신
특수 환경 지원: CGNAT, 공유 네트워크, 동적 IP 환경에서도 사용 가능
글로벌 성능: Cloudflare 네트워크를 통한 속도 개선 가능성

포트포워딩의 단점

보안 취약: 서버 IP와 포트가 직접 노출되어 공격 위험 증가
관리 번거로움: 동적 IP 사용 시 지속적 관리 필요
제한된 환경: ISP나 공유 네트워크에서 포트포워딩이 막혀있을 수 있음
SSL 설정 필요: 인증서를 직접 설정하고 갱신해야 함

사전 준비 사항

Cloudflare 계정:
- Cloudflare 계정을 생성하고 도메인을 연결해야 합니다.
- 이전 포스팅에서 설명한 "가비아 도메인을 Cloudflare로 연결하기" 부분을 참고하세요.
도커로 실행 중인 n8n:
- n8n이 도커를 통해 로컬에서 실행되고 있어야 합니다.
- 기본적으로 포트 5678에서 실행됩니다.
cloudflared 설치:
- Cloudflare 공식 문서를 참고하여 OS에 맞게 설치합니다.

Cloudflare 터널 설정 단계

1. Cloudflare 로그인 및 인증

첫 번째 단계는 cloudflared 클라이언트를 Cloudflare 계정에 연결하는 것입니다. 터미널을 열고 다음 명령어를 실행합니다:

cloudflared login

이 명령어를 실행하면 브라우저가 열리고 Cloudflare 로그인 페이지가 나타납니다. 로그인 후 권한을 부여하면 터널 사용 권한이 cloudflared 클라이언트에 부여됩니다.

2. 터널 생성

이제 n8n용 터널을 생성합니다:

cloudflared tunnel create n8n-tunnel

이 명령어는 n8n-tunnel이라는 이름의 새 터널을 생성합니다. 터널이 생성되면 인증서 파일이 자동으로 ~/.cloudflared 디렉토리에 저장됩니다. 이 인증서는 터널의 고유 ID를 포함하고 있습니다.

3. 터널 구성 파일 설정

다음으로, 터널 구성 파일을 생성합니다. 이 파일은 트래픽을 어떻게 라우팅할지 정의합니다:

cat <<EOF > ~/.cloudflared/config.yml
tunnel: n8n-tunnel
credentials-file: /Users/example/.cloudflared/2312442-7c232-49f4-852b-12323421.json

ingress:
  - hostname: n8n.example.site     
    service: http://localhost:5678
  - service: http_status:404
EOF

이 구성 파일에서:

tunnel: 사용할 터널의 이름
credentials-file: 터널 인증 파일의 경로 (파일명은 실제 생성된 터널의 ID로 변경해야 합니다)
ingress: 트래픽 라우팅 규칙
- hostname: 접속할 도메인 이름
- service: 트래픽을 전달할 로컬 서비스 주소 (n8n이 실행 중인 주소)
- 마지막 규칙은 일치하는 규칙이 없을 때 404 에러를 반환합니다

참고: credentials-file 경로는 본인의 시스템 경로에 맞게 조정해야 합니다.

4. DNS 레코드 생성

터널과 도메인을 연결하기 위해 DNS 레코드를 생성합니다:

cloudflared tunnel route dns n8n-tunnel n8n.example.site

이 명령어는 Cloudflare DNS에 n8n.example.site가 n8n-tunnel을 통해 접근 가능하도록 CNAME 레코드를 자동으로 생성합니다.

5. 터널 실행

이제 터널을 실행합니다:

cloudflared tunnel run n8n-tunnel

이 명령어를 실행하면 터널이 활성화되고, 설정한 도메인(n8n.example.site)을 통해 로컬에서 실행 중인 n8n에 외부에서 접근할 수 있게 됩니다.

터널이 실행되는 동안 로그가 표시되며, CTRL+C를 누르면 터널이 중지됩니다.

도커 자동 실행 설정

컴퓨터를 재부팅해도 도커와 n8n이 자동으로 실행되도록 설정하는 방법입니다.

도커 데스크톱 자동 실행 설정 (Mac/Windows 사용자)

Docker Desktop 실행
설정(Settings) 메뉴 열기
General 탭에서 "Start Docker Desktop when you sign in to your computer" 옵션 체크

터널 자동 실행 설정

아쉽게도 터널은 컴퓨터 재부팅 시 수동으로 다시 실행해야 합니다:

cloudflared tunnel run n8n-tunnel

리눅스에서 systemd를 이용한 자동 실행 설정

리눅스 서버를 사용하는 경우 systemd 서비스를 생성하여 터널을 자동으로 실행할 수 있습니다:

서비스 파일 생성:

sudo nano /etc/systemd/system/cloudflared.service

다음 내용 추가:

[Unit]
Description=Cloudflare Tunnel
After=network.target

[Service]
User=<your-username>
ExecStart=/usr/local/bin/cloudflared tunnel run n8n-tunnel
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

서비스 활성화 및 시작:

sudo systemctl enable cloudflared
sudo systemctl start cloudflared

macOS에서 launchd를 이용한 자동 실행 설정

macOS에서는 launchd를 사용하여 자동 실행을 설정할 수 있습니다:

plist 파일 생성:

nano ~/Library/LaunchAgents/com.cloudflare.tunnel.plist

다음 내용 추가:


http://www.apple.com/DTDs/PropertyList-1.0.dtd">


    Label
    com.cloudflare.tunnel
    ProgramArguments
    
        /usr/local/bin/cloudflared
        tunnel
        run
        n8n-tunnel
    
    RunAtLoad
    
    KeepAlive

plist 파일 로드:

launchctl load ~/Library/LaunchAgents/com.cloudflare.tunnel.plist

문제 해결 및 팁

1. 터널 연결 문제

터널 연결에 문제가 있는 경우:

# 터널 상태 확인
cloudflared tunnel info n8n-tunnel

# 로그 확인
cloudflared tunnel run n8n-tunnel --loglevel debug

2. n8n 설정 조정

n8n에서 웹훅을 사용할 때는 WEBHOOK_URL 환경 변수를 설정해야 합니다. docker-compose.yml 파일에 다음과 같이 추가합니다:

environment:
  - N8N_HOST=n8n.example.site
  - N8N_PROTOCOL=https
  - WEBHOOK_URL=https://n8n.example.site

3. 여러 서비스 연결

하나의 터널로 여러 서비스를 연결할 수 있습니다. config.yml 파일에 여러 서비스를 추가하면 됩니다:

ingress:
  - hostname: n8n.example.site
    service: http://localhost:5678
  - hostname: dashboard.example.site
    service: http://localhost:3000
  - service: http_status:404

마치며

Cloudflare 터널을 이용하면 복잡한 네트워크 설정 없이도 로컬에서 실행 중인 n8n에 안전하게 접근할 수 있습니다. 특히 개발 환경이나 홈 서버에서 실행 중인 서비스에 접근할 때 유용합니다.

이 방법의 장점은:

복잡한 포트 포워딩 설정이 필요 없음
SSL/TLS 자동 설정으로 안전한 접속
Cloudflare의 보안 기능을 활용할 수 있음
고정 IP가 없어도 언제든지 접근 가능

다음 포스팅에서는 n8n에서 실제 워크플로우를 만들고 자동화하는 방법에 대해 알아보겠습니다. 혹시 질문이나 문제가 있으시면 댓글로 남겨주세요!

참고 자료:

n8n 무료로 사용하기 (셀프호스팅 도커 환경 구축 - 웹훅 설정부터 도메인 연결까지)

hmk run dev — Sun, 11 May 2025 17:40:19 +0900

최근 n8n을 셀프호스팅으로 구축하면서 겪은 경험을 공유하고자 합니다. 이 글에서는 도커를 이용한 n8n 설치부터 웹훅 설정, 그리고 가비아에서 구매한 도메인을 Cloudflare에 연결하는 과정까지 상세하게 설명하겠습니다.

n8n이란?

n8n(노드이트노드)은 워크플로우 자동화 도구로, Zapier나 IFTTT와 같은 서비스와 유사하지만 오픈소스이며 셀프호스팅이 가능합니다. API 연동, 데이터 처리, 자동화 작업 등을 노드 기반 인터페이스를 통해 쉽게 구현할 수 있습니다.

주요 특징:

직관적인 노드 기반 워크플로우 에디터
200개 이상의 서비스와 연동 가능
셀프호스팅 지원으로 데이터 주권 확보
워크플로우 템플릿 제공
강력한 에러 핸들링 및 디버깅 기능

도커를 이용한 n8n 셀프호스팅 구축

도커(Docker)란?

도커는 애플리케이션을 컨테이너라는 독립된 환경에서 실행할 수 있게 해주는 플랫폼입니다. 컨테이너는 필요한 모든 종속성과 라이브러리를 포함하고 있어, 어떤 환경에서든 동일하게 작동합니다. 이는 "내 컴퓨터에서는 작동하는데..."라는 문제를 해결해줍니다.

n8n 도커 설치 과정

도커 설치하기

먼저 서버에 도커와 도커 컴포즈가 설치되어 있어야 합니다. 리눅스 환경에서는 다음 명령어로 설치할 수 있습니다:

# 도커 설치
sudo apt update
sudo apt install docker.io

# 도커 컴포즈 설치
sudo apt install docker-compose

# 도커 서비스 시작 및 자동 시작 설정
sudo systemctl start docker
sudo systemctl enable docker

docker-compose.yml 파일 생성

프로젝트 디렉토리를 만들고 그 안에 docker-compose.yml 파일을 생성합니다:

mkdir n8n-project
cd n8n-project
touch docker-compose.yml

다음은 기본적인 n8n 구성을 위한 docker-compose.yml 파일 내용입니다:

version: '3'

services:
  n8n:
    image: n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=도메인주소 # 여러분의 도메인으로 변경해주세요
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - WEBHOOK_URL=https://도메인주소 # 여러분의 도메인으로 변경해주세요
    volumes:
      - ./n8n_data:/home/node/.n8n

n8n 실행하기

docker-compose.yml 파일이 있는 디렉토리에서 다음 명령어를 실행합니다:

sudo docker-compose up -d

-d 옵션은 백그라운드에서 실행하도록 합니다. 이제 n8n이 도커 컨테이너 내에서 실행되고 있습니다.

로그 확인하기

실행 중인 n8n의 로그를 확인하려면:

sudo docker-compose logs -f n8n

웹훅 설정을 위한 도메인 연결

웹훅(Webhook)이란?

웹훅은 특정 이벤트가 발생했을 때 실시간으로 알림을 받을 수 있는 HTTP 콜백 메커니즘입니다. 쉽게 말해, 어떤 서비스에서 이벤트(예: 새 이메일 수신, 결제 완료, GitHub 커밋 등)가 발생하면 미리 지정한 URL로 HTTP 요청을 보내주는 방식입니다.

n8n에서 웹훅은 외부 서비스로부터 트리거를 받아 워크플로우를 실행하기 위한 핵심 기능입니다.

웹훅을 위한 도메인 설정

n8n에서 웹훅을 사용하기 위해서는 외부에서 접근 가능한 도메인이 필요합니다. 개발 환경에서는 ngrok 같은 터널링 서비스를 사용할 수 있지만, 프로덕션 환경에서는 실제 도메인을 사용하는 것이 좋습니다.

도메인 연결하기

도메인을 서버의 IP 주소에 연결해야 합니다. DNS 관리 페이지에서 A 레코드를 생성하여 도메인이 서버 IP를 가리키도록 설정합니다.

SSL 인증서 설정

웹훅은 보안을 위해 HTTPS를 사용하는 것이 좋습니다. Let's Encrypt를 이용해 무료 SSL 인증서를 발급받을 수 있습니다.

다음은 Nginx와 Let's Encrypt를 이용한 설정 예시입니다:

# Nginx 설치
sudo apt install nginx

# Certbot 설치 (Let's Encrypt 클라이언트)
sudo apt install certbot python3-certbot-nginx

# SSL 인증서 발급
sudo certbot --nginx -d 여러분의도메인.com

Nginx 리버스 프록시 설정

n8n은 기본적으로 5678 포트에서 실행되므로, Nginx를 통해 80/443 포트의 요청을 n8n으로 전달하도록 리버스 프록시를 설정합니다:

server {
    listen 80;
    server_name 여러분의도메인.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name 여러분의도메인.com;

    ssl_certificate /etc/letsencrypt/live/여러분의도메인.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/여러분의도메인.com/privkey.pem;

    location / {
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nginx 설정을 저장하고 적용합니다:

sudo nginx -t  # 설정 문법 검사
sudo systemctl reload nginx  # 설정 적용

가비아 도메인을 Cloudflare로 연결하기

네임서버(Name Server)란?

네임서버는 도메인 이름을 IP 주소로 변환해주는 DNS(Domain Name System)의 일부입니다. 쉽게 말해, 우리가 웹브라우저에 도메인 이름을 입력했을 때 해당 웹사이트의 서버를 찾을 수 있도록 도와주는 '전화번호부' 같은 역할을 합니다.

Cloudflare란?

Cloudflare는 CDN(Content Delivery Network), DNS 관리, DDoS 방어, SSL 인증서 등 다양한 웹 서비스를 제공하는 회사입니다. 무료 플랜에서도 강력한 기능을 제공하여 많은 개발자들이 사용하고 있습니다.

가비아 도메인을 Cloudflare로 이전하는 과정

Cloudflare 계정 생성 및 도메인 추가

먼저 Cloudflare 웹사이트에서 계정을 생성하고, 대시보드에서 '사이트 추가' 버튼을 클릭하여 가비아에서 구매한 도메인을 입력합니다

1. DNS 레코드 확인

Cloudflare가 현재 도메인의 DNS 레코드를 스캔합니다. 스캔이 완료되면 결과를 확인하고 필요한 경우 DNS 레코드를 수정합니다.

2. 플랜 선택

Cloudflare는 다양한 플랜을 제공하지만, 개인 프로젝트라면 무료 플랜으로도 충분합니다. 필요한 플랜을 선택합니다.

3. 네임서버 변경

Cloudflare는 여러분의 도메인에 사용할 네임서버 정보를 제공합니다. 일반적으로 다음과 같은 형태입니다:

ns1.cloudflare.com
ns2.cloudflare.com

1. 가비아에서 네임서버 변경하기

가이드에 맞게 변경

2. 변경 확인 및 적용 대기

네임서버 변경은 전 세계 DNS에 전파되는 데 시간이 걸립니다. 일반적으로 몇 시간에서 최대 48시간까지 소요될 수 있습니다. Cloudflare 대시보드에서 '활성화 확인 중' 상태를 볼 수 있으며, 활성화가 완료되면 '활성화됨' 상태로 변경됩니다.

3. SSL/TLS 설정

Cloudflare 대시보드에서 'SSL/TLS' 메뉴로 이동하여 암호화 모드를 설정합니다. 일반적으로 '유연한' 또는 '전체' 모드를 선택합니다.

4. 페이지 규칙 및 추가 설정

필요에 따라 페이지 규칙, 캐시 설정, 방화벽 등 Cloudflare의 다양한 기능을 설정할 수 있습니다.

마치며

이제 n8n을 도커로 셀프호스팅하고, 웹훅을 위한 도메인 설정까지 완료했습니다. 가비아에서 구매한 도메인을 Cloudflare로 연결하여 추가적인 보안과 성능 혜택도 얻었습니다.

n8n을 통해 다양한 서비스를 연동하고 자동화 워크플로우를 구축할 수 있습니다. GitHub, Slack, Google Sheets, 이메일 서비스 등 수많은 서비스와 연동할 수 있으니, 여러분의 업무를 더욱 효율적으로 만들어보세요!

추가적인 질문이나 문제가 있다면 댓글로 남겨주세요. 다음에는 n8n에서 실제 워크플로우를 구축하는 방법에 대해 더 자세히 다루어보겠습니다.

참고 자료:

CI 린트 체크시간 최적화하기

hmk run dev — Fri, 9 May 2025 00:31:00 +0900

모노레포에서 린트 작업의 처리 속도를 크게 향상시키기 위해, 동기 방식에서 비동기 방식으로 전환한 경험을 공유합니다. Node.js의 이벤트 루프와 비동기 처리의 원리를 이해하면 빌드 파이프라인의 효율성을 대폭 개선할 수 있습니다.

왜 린트 시간을 개선해야 했는가?

모노레포 프로젝트가 커질수록 린트 작업은 점점 더 많은 시간을 소요합니다. 특히 CI/CD 파이프라인에서 모든 패키지를 일일이 검사하는 과정은 개발 생산성을 저하시키는 주요 요인이 됩니다. 기존에는 변경된 패키지마다 린트 작업을 순차적으로(동기적으로) 실행했으나, 이 방식은 패키지 수가 늘어날수록 선형적으로 시간이 증가하는 문제가 있었습니다.

해결 접근법: 비동기 병렬 처리

코드를 분석해보면, 기존에는 execSync를 사용해 패키지별 린트 작업을 순차적으로 처리했습니다.

이를 exec와 Promise를 활용한 비동기 병렬 처리 방식으로 변경하여 린트 시간을 획기적으로 단축했습니다.

execSync와 exec의 차이

execSync - 동기적 실행

const { execSync } = require('child_process');

// 이전 코드(가정)
affectedPackages.forEach((pkgPath) => {
  console.log(`Starting lint for ${pkgPath}...`);
  try {
    const output = execSync(`pnpm turbo lint --filter=./${pkgPath}`, { encoding: 'utf-8' });
    console.log(`Completed lint for ${pkgPath}`);
    console.log(output);
  } catch (error) {
    console.error(`Error in ${pkgPath}:`, error.stderr);
    process.exit(1);
  }
});

execSync는 동기적으로 작동합니다.

각 패키지의 린트 작업이 완료될 때까지 다음 패키지 처리가 대기합니다.
이벤트 루프가 차단되어 다른 작업을 동시에 수행할 수 없습니다.
패키지 A의 린트가 끝나야만 패키지 B의 린트가 시작됩니다.

exec - 비동기적 실행

const { exec } = require('child_process');

// 새 코드
const promises = packagesArray.map((pkgPath) => {
  return new Promise((resolve, reject) => {
    console.log(`Starting lint for ${pkgPath}...`);
    exec(`pnpm turbo lint --filter=./${pkgPath}`, (error, stdout, stderr) => {
      if (error) {
        console.error(`Error in ${pkgPath}:`, stderr);
        reject(error);
        return;
      }
      console.log(`Completed lint for ${pkgPath}`);
      console.log(stdout);
      resolve();
    });
  });
});

Promise.all(promises).catch((_) => {
  process.exit(1);
});

exec는 비동기적으로 작동합니다:

명령을 실행하고 즉시 제어권을 반환합니다.
이벤트 루프가 차단되지 않고 다른 작업을 병렬로 수행할 수 있습니다.
모든 패키지의 린트 작업이 동시에 시작되어 병렬로 처리됩니다.

Node.js 이벤트 루프와 비동기 처리 이해하기

이벤트 루프란?

Node.js의 핵심은 단일 스레드 기반의 이벤트 루프입니다. 이는 자바스크립트가 비동기 작업을 처리하는 방식의 기본 메커니즘입니다.

동기 vs 비동기 & 블록 vs 논블록

블록 + 동기 (execSync 방식)
- 작업 A가 완료될 때까지 다음 작업이 시작되지 않습니다.
- 한 번에 하나의 작업만 처리됩니다.
- 자원 활용이 비효율적입니다.
논블록 + 비동기 (exec + Promise 방식)
- 작업 A를 시작한 후 완료를 기다리지 않고 작업 B, C를 진행합니다.
- 작업이 완료되면 콜백(Promise의 resolve)을 통해 결과를 처리합니다.
- 여러 작업이 병렬로 처리되어 CPU와 I/O 자원을 효율적으로 활용합니다.

동작 원리

각 패키지마다 린트 명령을 비동기적으로 실행하는 Promise 객체를 생성합니다.
Promise.all을 사용해 모든 린트 작업이 병렬로 실행되게 합니다.
어느 하나라도 실패하면 전체 프로세스가 실패로 간주됩니다.

성능 개선 효과

이러한 변경을 통해 얻을 수 있는 성능 개선을 살펴보겠습니다:

패키지 수execSync (순차 처리)exec + Promise (병렬 처리)개선율

5개	약 50초	약 15초	70%
10개	약 100초	약 20초	80%
20개	약 200초	약 25초	87.5%

병렬 처리의 효과는 패키지 수가 많을수록 극대화됩니다. 단, 시스템 자원(CPU, 메모리)의 한계로 인해 무한히 개선되지는 않습니다.

주의사항 및 고려사항

자원 사용량: 병렬 처리는 CPU와 메모리 사용량이 증가할 수 있습니다.
의존성 문제: 패키지 간 의존성이 있는 경우 병렬 처리가 문제를 일으킬 수 있습니다(이 경우 Turborepo의 의존성 관리 기능이 도움이 됩니다).
동시성 제한: 너무 많은 동시 프로세스가 시스템에 부담을 줄 수 있으므로, 패키지 수가 많은 경우 동시성을 제한하는 방법도 고려해볼 수 있습니다.

브라우저 vs Node.js 비동기 처리 비교

libuv는 내부적으로 스레드 풀을 관리합니다.

비동기 처리 기반	브라우저 내장 API + 운영체제	libuv 라이브러리
병렬 처리 방식	브라우저 내부 스레드 + 운영체제 API	libuv 스레드 풀 + 운영체제 API
파일 시스템 액세스	제한적 (File API)	전체 접근 가능
네트워크 요청	Fetch API, XMLHttpRequest	http, https, net 모듈
병렬 JavaScript 실행	Web Workers	Worker Threads
프로세스 생성	불가능	child_process 모듈

확장 가능한 개선 방안

더 나아가 다음과 같은 방법으로 성능을 추가 개선할 수 있습니다:

동시성 제한 도입

// p-limit 라이브러리 활용 예시
const pLimit = require('p-limit');
const limit = pLimit(4); // 최대 4개 작업만 동시에 실행

const promises = packagesArray.map((pkgPath) => {
  return limit(() => new Promise((resolve, reject) => {
    // exec 비동기 호출
  }));
});

캐싱 전략 활용: Turborepo의 캐싱 기능을 최대한 활용하여 중복 작업을 방지합니다.

결론

Node.js에서 execSync에서 exec로의 전환은 단순한 API 변경 이상의 의미를 갖습니다. 이는 동기 블로킹 방식에서 비동기 논블로킹 방식으로의 패러다임 전환이며, 이벤트 루프를 효과적으로 활용하는 방식으로의 변화입니다.

이러한 변경을 통해 린트 시간을 크게 단축할 수 있었고, 개발자 경험과 CI/CD 파이프라인의 효율성을 모두 향상시킬 수 있었습니다. 모노레포 환경에서 빌드 파이프라인을 최적화할 때는 항상 비동기 처리와 병렬화를 고려해보시기 바랍니다.

비동기 처리는 JavaScript의 강력한 특징 중 하나이며, 이를 효과적으로 활용하면 성능 개선의 큰 열쇠가 됩니다!

블록과 논블록, 동기와 비동기

hmk run dev — Tue, 6 May 2025 17:57:46 +0900

오늘은 프로그래밍에서 매우 중요한 개념인 블록(Block)과 논블록(Non-block), 그리고 동기(Synchronous)와 비동기(Asynchronous) 처리에 대해 자세히 알아보겠습니다. 이 개념들은 종종 혼동되기 쉽지만, 효율적인 프로그래밍을 위해 반드시 이해해야 하는 핵심 요소입니다.

개념 정의와 차이점

블록 vs 논블록

블록(Block) 처리란:

특정 작업이 완료될 때까지 다음 작업으로 진행하지 않고 대기하는 방식
프로그램이 해당 작업에 "차단(blocked)"되어 있는 상태
작업이 끝날 때까지 제어권을 돌려받지 못함

논블록(Non-block) 처리란:

작업 완료 여부와 상관없이 다음 작업으로 즉시 진행하는 방식
프로그램이 "차단되지 않고(non-blocked)" 계속 실행됨
작업을 요청한 후 즉시 제어권을 돌려받음

동기 vs 비동기

동기(Synchronous) 처리란:

작업이 순차적으로 실행되며, 한 작업이 완료된 후에 다음 작업이 시작
결과를 즉시 반환받음
코드의 실행 순서와 작업의 완료 순서가 일치

비동기(Asynchronous) 처리란:

작업의 완료를 기다리지 않고 다음 작업을 진행
결과는 나중에 콜백, 프로미스, 이벤트 등의 방식으로 받음
코드의 실행 순서와 작업의 완료 순서가 일치하지 않을 수 있음

블록/논블록과 동기/비동기의 관계

이 두 쌍의 개념은 서로 다른 측면을 다루고 있습니다:

블록/논블록은 제어권(control flow)에 관한 것
동기/비동기는 작업의 완료 시점과 결과 처리 방식에 관한 것

따라서 이론적으로는 다음과 같은 조합이 가능합니다:

블록 + 동기: 가장 전통적인 방식 (예: 일반적인 함수 호출)
논블록 + 비동기: 현대적 웹 개발에서 많이 사용 (예: AJAX 요청)
블록 + 비동기: 드물게 사용 (예: 일부 멀티스레딩 상황)
논블록 + 동기: 특수한 경우 (예: 일부 폴링 메커니즘)

장단점 비교

블록 처리의 장단점

장점:

코드가 직관적이고 이해하기 쉬움
디버깅이 간단함
작업의 순서가 명확함

단점:

자원 활용 효율이 낮음 (대기 시간 동안 CPU 유휴 상태)
사용자 인터페이스가 멈출 수 있음
확장성이 제한됨

논블록 처리의 장단점

장점:

자원 활용 효율이 높음
사용자 인터페이스 응답성 유지
높은 처리량 가능

단점:

코드 복잡성 증가
디버깅이 어려움
경쟁 상태(race condition)와 같은 동시성 문제 발생 가능

동기 처리의 장단점

장점:

코드 흐름 추적이 용이함
순차적 실행으로 예측 가능성이 높음
에러 처리가 직관적임

단점:

I/O 작업 등에서 효율이 낮음
병렬 처리가 어려움
긴 작업은 전체 프로그램을 지연시킬 수 있음

비동기 처리의 장단점

장점:

높은 응답성과 효율적인 자원 활용
병렬 처리 가능
I/O 바운드 작업에 이상적

단점:

콜백 지옥(callback hell)과 같은 코드 복잡성
에러 처리가 복잡함
디버깅 어려움

실전 적용 가이드

블록 처리를 사용해야 할 때

단순한 계산이나 메모리 작업처럼 빠르게 완료되는 작업
다음 작업이 이전 작업의 결과에 의존적일 때
트랜잭션 일관성이 중요한 데이터베이스 작업
초기화 과정과 같이 반드시 순차적으로 실행되어야 하는 경우

논블록 처리를 사용해야 할 때

UI 응답성이 중요한 클라이언트 애플리케이션
네트워크 통신이나 파일 I/O와 같이 대기 시간이 긴 작업
동시에 여러 작업을 처리해야 하는 서버
실시간 데이터 처리가 필요한 경우

동기 처리를 사용해야 할 때

순차적인 데이터 처리가 필요한 경우
코드의 명확성과 디버깅 용이성이 중요할 때
에러 처리가 중요한 중요 업무 로직
작업의 결과가 즉시 필요한 경우

비동기 처리를 사용해야 할 때

네트워크 요청, 데이터베이스 쿼리 등 I/O 바운드 작업
대용량 데이터 처리
사용자 인터페이스의 응답성 유지가 중요한 경우
여러 독립적인 작업을 동시에 처리해야 할 때

프로그래밍 언어별 구현 사례

JavaScript

JavaScript는 단일 스레드 언어지만 비동기 처리를 위한 다양한 메커니즘을 제공합니다.

// 블록 + 동기
function syncBlock() {
  const result = expensiveCalculation(); // 이 함수가 완료될 때까지 대기
  console.log(result);
}

// 논블록 + 비동기 (콜백 방식)
function asyncNonBlock() {
  fetchData((result) => {
    console.log(result);
  });
  console.log("요청 시작됨"); // fetchData 완료 전에 실행됨
}

// 논블록 + 비동기 (Promise 방식)
function asyncNonBlockPromise() {
  fetchDataPromise()
    .then(result => console.log(result))
    .catch(error => console.error(error));
  console.log("요청 시작됨"); // Promise 완료 전에 실행됨
}

// 논블록 + 비동기 (async/await 방식 - 문법적으로는 동기식처럼 보이지만 내부적으로는 비동기)
async function asyncNonBlockAwait() {
  console.log("요청 시작됨");
  try {
    const result = await fetchDataPromise(); // 비동기지만 코드는 동기식처럼 보임
    console.log(result);
  } catch (error) {
    console.error(error);
  }
}

실제 사례

웹 개발에서의 API 호출

웹 애플리케이션에서 외부 API를 호출할 때:

블록 + 동기 방식:

// 블록 + 동기 (권장하지 않음)
function getDataSync() {
  const xhr = new XMLHttpRequest();
  xhr.open('GET', 'https://api.example.com/data', false); // 동기 모드
  xhr.send();
  if (xhr.status === 200) {
    return JSON.parse(xhr.responseText);
  }
}
// 주의: 이 방식은 브라우저 메인 스레드를 차단하여 UI 응답성을 저하시킴

논블록 + 비동기 방식 (권장):

// 논블록 + 비동기 (fetch API)
function getDataAsync() {
  fetch('https://api.example.com/data')
    .then(response => response.json())
    .then(data => {
      updateUI(data); // 데이터가 준비되면 UI 업데이트
    })
    .catch(error => console.error('Error:', error));
  
  showLoadingIndicator(); // 즉시 실행되어 사용자에게 로딩 중임을 표시
}

[Q&A] async/await는 블록인가 논블록인가?

Q: API 호출에 await를 사용하면 응답을 기다려야 하므로 블록 방식이 아닌가요?

A: 이 질문은 매우 좋은 포인트를 짚고 있습니다! async/await의 블록/논블록 특성은 두 가지 관점에서 봐야 합니다:

함수 내부 관점: await는 해당 함수 내에서 Promise가 해결될 때까지 다음 코드 실행을 일시 중지합니다. 이런 면에서는 "블록"처럼 보입니다.

async function getData() {
  console.log("1. 요청 전");
  const data = await fetchAPI(); // 여기서 함수 실행이 일시 중지됨
  console.log("3. 데이터 수신 후"); // 응답이 올 때까지 실행되지 않음
  return data;
}

전체 프로그램 관점: await를 만나면 함수 실행은 일시 중지되지만, 중요한 점은 제어권이 이벤트 루프로 넘어간다는 것입니다. 따라서 메인 스레드는 차단되지 않고 다른 작업을 계속할 수 있습니다.

getData();
console.log("2. getData 호출 후 즉시 실행"); // 데이터를 기다리지 않고 실행됨

// 실행 순서: 1 → 2 → 3

이처럼 async/await는 개발자에게는 동기 코드처럼 보이는 가독성을 제공하면서도, 실제로는 프로그램 전체가 블록되지 않는 논블록 방식으로 동작합니다. 이것이 JavaScript의 비동기 프로그래밍의 강력한 특징입니다.

결론: API 호출을 await로 처리하는 코드는 전체 시스템 관점에서 볼 때 "논블록 + 비동기" 패턴이라고 할 수 있습니다!

파일 시스템 작업

Node.js에서 파일 시스템 작업 시:

블록 + 동기 방식:

javascript// 블록 + 동기
const fs = require('fs');

function readFileSync() {
  try {
    const data = fs.readFileSync('large-file.txt', 'utf8');
    console.log(data);
  } catch (error) {
    console.error('Error:', error);
  }
  console.log('파일 읽기 완료'); // 파일 읽기가 완료된 후에만 실행됨
}

논블록 + 비동기 방식:

// 논블록 + 비동기
const fs = require('fs');

function readFileAsync() {
  fs.readFile('large-file.txt', 'utf8', (error, data) => {
    if (error) {
      console.error('Error:', error);
      return;
    }
    console.log(data);
  });
  console.log('파일 읽기 요청됨'); // 파일 읽기 완료 전에 실행됨
}

데이터베이스 쿼리

Node.js와 MongoDB를 사용한 데이터베이스 쿼리:

블록 + 동기 방식 (잘 사용하지 않음):

// 블록 + 동기 (가상의 예시, 실제로는 권장하지 않음)
function findUserSync(id) {
  const user = db.collection('users').findOneSync({ _id: id });
  return user;
}

논블록 + 비동기 방식 (권장):

// 논블록 + 비동기 (Promise)
function findUserAsync(id) {
  return db.collection('users').findOne({ _id: id })
    .then(user => {
      return processUser(user);
    })
    .catch(error => {
      console.error('Error:', error);
      throw error;
    });
}

// 논블록 + 비동기 (async/await)
async function findUserAsyncAwait(id) {
  try {
    const user = await db.collection('users').findOne({ _id: id });
    return processUser(user);
  } catch (error) {
    console.error('Error:', error);
    throw error;
  }
}

결론

블록/논블록과 동기/비동기는 서로 다른 개념이지만, 상호보완적으로 작용하여 프로그램의 실행 방식과 성능에 영향을 미칩니다. 현대 프로그래밍에서는 특히 사용자 경험과 시스템 효율성을 위해 논블록 비동기 방식이 선호되는 추세이지만, 각 상황에 맞는 적절한 방식을 선택하는 것이 중요합니다.

효율적인 개발을 위해서는:

작업의 특성 파악: I/O 바운드인지, CPU 바운드인지 분석
사용자 경험 고려: 응답성이 중요한지, 처리 속도가 중요한지 판단
개발 복잡성 평가: 팀의 역량과 프로젝트 요구사항에 맞는 방식 선택
최신 API와 라이브러리 활용: 각 언어와 플랫폼에서 제공하는 최적화된 도구 사용

이러한 개념을 제대로 이해하고 적용한다면, 더 효율적이고 반응성 높은 애플리케이션을 개발할 수 있을 것입니다.

셀프회고(2025.05.05)

hmk run dev — Tue, 6 May 2025 00:49:55 +0900

이직 후 6개월이 넘는 시간 동안, 저는 통신 도메인 회사의 PMF(Product Market Fit)를 찾는 팀에 소속되어 있습니다. 아직 큰 성과를 내지 못했지만, 30조 시장에서 아무도 도전하지 않았던 통신 시장의 문제를 해결한다는 설렘을 가지고 계속해서 목표를 향해 나아가고 있습니다.

100% 확신을 갖기는 어렵지만, 언젠가 모요가 통신시장의 문제를 해결하고 PMF를 찾을 것이라는 믿음을 가지고 일하는 중 입니다~!

이 확신은 제가 직접 경험한 불편함, 필드리서치, 사용자 테스트, 그리고 주변 사람들이 겪고 있는 명확한 문제들에 기반합니다. 특히 이러한 불편함을 해결하고자 하는 플레이어가 저희가 유일하다는 점(~~물론 비판적 시각에서 지금까지 이 문제가 해결되지 않은 이유가 있을 수도 있다는 생각도 합니다.~~ 그래도 도전 해보렵니다.)

정량적인 성과가 아직 보이지 않아 불안하지만, 동료들 덕분에 즐겁게 일하고 있습니다.

(작은 위안으로, Canva, Notion, Figma와 같은 성공적인 기업들도 PMF 달성에 1년~2년 이상의 시간이 소요되었다는 점..)

팀원 각자가 직군에 상관없이 메이커로서의 모습을 보여주어 큰 동기부여가 되었습니다. 거의 모든 구성원이 오너십을 가지고 프로페셔널한 태도로 적극적으로 도전하는 모습에 저 역시 그 분위기에 깊이 빠져들어 제품만 생각하며 생활하고 있습니다.

프론트엔드 개발자로 시작했지만, 이제는 필드리서치, 사용자 테스트 등을 거치며 길가다 휴대폰을 사용하는 사람들에게 자연스럽게 말을 걸 수 있는 "철판"까지 장착하게 되었죠 ㅎㅎ

우리팀 (tmi - 쌍수한 디자이너와 호칭에 맞게. 뒷 모습만 보이는 백엔드 개발자)

제품 성공을 위한 고민

제품을 위해 헌신하고 밤낮을 가리지 않는 분위기 속에서, "어떤 프론트엔드 개발자 혹은 팀원이 되어야 이 팀이 목표를 이루는 데 일조할 수 있을까?"라는 생각을 많이 하게 되었고 실제 액션했던 것들

- 빠르게 가설을 검증하기 위해 빠르고 안정적인 서비스를 딜리버리 할 수 있는 역량

pmf를 찾기위해 다양한 가치나 소구 포인트로 여러 제품을 만들어야하는 상황에서 빠르지만 안정적인 서비스를 만들어야 했어요

사실 한정된 자원, 시간 속에서 안정성을 위한 테스트 등을 많이 챙기진 못했지만 중요 로직이나 함수는 테스터블하게 만들고 테스트 코드를 검증하려고 했어요, 그리고 오류를 적시에 발견할 수 있도록 센트리, 데이터독과 같은 로깅 시스템을 적극 활용했어요

- 데이터 기반으로 UI/UX를 검증하고 개선 방향까지 제시 할 수 있는 역량

팀에선 믹스패널을 이용해 유저 행동을 수집하고 이를 통해 데이터 기반으로 UI/UX를 개선하는 방식으로 일했어요,

저는 프론트엔드 개발자이지만, 배포전까지 가장 화면을 많이 보는 사람으로써 개선방향을 적극적으로 제안했고

배포 이후에도 믹스패널 사용법을 숙지해 데이터에 기반한 문제점을 빠르게 파악하고 개선점을 적극적으로 제안하려고 했어요

- 원팀으로써 헌신하고 주체적으로 팀원의 불편함을 찾아서 개선할 수 있는 사람

때로는 프론트엔드 직군이라는 틀에서 벗어나 팀이나 조직의 목표를 위해 헌신하거나, 손이 남는 시점에 동료의 불편함을 개선할 수 있는 사람 같이 일하는 팀원이 되고자 노력했어요 데이터 분석가 동료를 위한 스크래핑 봇, 다수의 인플루언서 컨택을 하고 싶은 마케팅 팀을 위한 인스타 그램 DM 자동화 봇, SKT 유심사태 TF 리소스 지원 등 도움을 줄 수 있는 곳에 원팀으로써 적극적으로 리소스를 지원했어요

SKT 유심사태로 인한 당일 tf 결성 후 밤샘작업을 하고 본 일출

동료에 불편함을 해결해주고 받은 첫 shout out!

물론 이 과정들은 너무 재밌었지만, 프론트엔드 챕터로써 DX를 개선 경험이 적었던 것은 조금 아쉬웠어요 ㅎㅎ

이 부분은 여러 동료들에게 1on1을 하며 상담했지만, 현재로써 pmf를 찾고 스쿼드에 전념하는 것이 좋다고 스스로 판단해서

조금 아쉽지만 틈틈히 의식적으로 노력해 채워가야할 부분이 아닌가 스스로 생각이 듭니다.

누구도 도전하지 않았던 시장에서 PMF를 찾는 과정은 설레면서도 결코 쉽지 않음을 매 순간 피부로 느끼고 있습니다. 그래서 더욱 이 문제를 해결하고 싶고 헌신하고 싶다는 생각이 듭니다. 여전히 부족한 부분이 많아 스스로와 동료들에게 피드백을 받으며 성장해야겠습니다.

앞으로는 단순히 "무언가 해보자"는 시도보다는, 팀이 집중하는 가설이나 문제의 흐름을 더 깊이 이해하고, 그 속에서 진정으로 필요한 기술적/제품적 인풋을 탐색하겠습니다. 또한, 단순 실행자가 아닌 DRI로서 팀에 임팩트 있는 기여를 제안하고 실현하는 역할을 더 명확히 하겠습니다. 이를 위해 사소하더라도 '무엇을 위해 하는가'를 더 자주 질문하고, 챌린지를 받는 것에도 열린 자세를 유지해야겠습니다!

카카오 로그인 URL 길이 제한 문제와 해결방안

hmk run dev — Mon, 5 May 2025 17:47:58 +0900

웹 애플리케이션 개발 중 예상치 못한 에러를 마주칠 때가 있습니다. 그중에서도 특히 외부 API와 연동할 때 발생하는 문제는 디버깅이 어려울 수 있습니다. 최근 저희 팀은 카카오 로그인 구현 과정에서 긴 URL로 인해 발생하는 404 에러와 Nginx 오류 화면을 마주쳤습니다. 이 글에서는 그 원인과 해결 방안, 그리고 이와 관련된 개발 시 고려해야 할 사항들을 공유하고자 합니다.

문제 상황

카카오 로그인 구현 시 kauth.kakao.com/oauth/authorize로 로그인 요청을 보내는 과정에서 URL이 너무 길 경우 404 에러 및 Nginx 오류 화면이 나타나는 문제가 발생했습니다. 특히 UTM 파라미터(마케팅 추적 코드)와 같은 추가 매개변수가 포함된 경우에 이런 현상이 두드러졌습니다.

문제의 예시

아래와 같이 긴 URL로 요청을 보낼 경우 오류가 발생했습니다:

https://kauth.kakao.com/oauth/authorize?client_id=97cdc170451dc8b3186cb5853bd0feed&redirect_uri=https%3A%2F%2Fwww.moyoplan.com%2Fr%2Flogin%2Fkakao&response_type=code&state=%7B%22next%22%3A%22%2Fr%2Fmohyo-pickup%2Fsend%3FsellerName%3DLG...
(이하 생략된 매우 긴 URL)

특히 state 파라미터 내에 포함된 JSON 데이터가 매우 길고, UTM 파라미터(utm_medium, utm_source, utm_campaign 등)와 Facebook 추적 코드(fbclid)가 여러 위치에 중복 포함되어 있었습니다.

원인 분석

Nginx의 URL 길이 제한

이 문제의 주된 원인은 Nginx 웹 서버의 URL 길이 제한에 있었다고 추측했습니다.

Nginx는 기본적으로 요청 URL에 길이 제한을 두고 있으며, 이 제한을 초과하면 414(Request-URI Too Large) 에러를 반환합니다.

Nginx의 URL 길이 제한은 large_client_header_buffers 설정으로 관리됩니다. 기본 설정은 다음과 같습니다:

large_client_header_buffers 4 8k;

이는 4개의 버퍼를 사용하며 각 버퍼 크기가 8KB라는 의미입니다. 하지만 요청 라인(HTTP 메서드, URL, 프로토콜 버전)은 한 버퍼 크기를 초과할 수 없으므로, 실제 URL 길이 제한은 약 8KB보다 작습니다. 일반적으로 Nginx는 최대 URL 길이를 약 4KB(4,096 bytes)로 제한하고 있습니다.

그러나 414에러 대신 404에러를 뱉었다는 점을 미루어보아

그러나 414에러 대신 404에러를 뱉었다는 점을 미루어보아, 카카오의 인증 서버에는 표준 HTTP 프로토콜과 다른 커스텀한 에러 처리 로직이 구현되어 있을 가능성이 큽니다. HTTP 표준에 따르면 URL이 너무 길 경우 414(URI Too Long) 에러를 반환하는 것이 적절합니다. 하지만 카카오에서는 이런 상황에 404(Not Found) 에러를 반환했습니다.

이러한 비표준 동작에는 몇 가지 가능한 설명이 있습니다.

첫째, 카카오의 인증 서버는 다중 계층 아키텍처로 구성되어 있을 수 있습니다. 외부에서 접근 가능한 Nginx와 같은 프록시 서버가 URL 길이를 미리 검증하고, 일정 길이를 초과하는 요청은 내부 애플리케이션 서버로 전달하지 않고 곧바로 404 응답을 반환하도록 설정되었을 가능성이 있습니다. 이런 구현은 다음과 같은 Nginx 설정으로 가능합니다

location /oauth/authorize {
    # URL 길이가 특정 값을 초과하면 404 반환
    if ($request_uri ~* "^.{4000,}$") {
        return 404;
    }
    
    proxy_pass http://internal_auth_server;
}

그러나 414에러 대신 404에러를 뱉었다는 점을 미루어보아, 카카오의 인증 서버에는 표준과 다른 커스텀한 에러 처리 로직이 있을 가능성이 큽니다. 이에 대한 몇 가지 가능성은 다음과 같습니다.

다중 계층 아키텍처: 외부 프록시 서버가 URL 길이를 검증하고 길이 초과 시 내부 서버로 전달하지 않고 바로 404를 반환
보안 목적: 414 에러는 서버의 정확한 URL 길이 제한을 노출하므로, 보안을 위해 의도적으로 모호한 404 에러를 사용
라우팅 문제: 긴 URL이 라우팅 단계에서 "존재하지 않는 리소스"로 해석되어 404로 처리

이러한 비표준 동작은 개발자에게 혼란을 줄 수 있으므로, 외부 API 연동 시에는 공식 문서 외에도 실제 동작 방식을 충분히 테스트해보는 것이 중요합니다.

카카오 로그인 API 스펙

카카오 로그인은 OAuth 2.0 프로토콜을 기반으로 구현되어 있으며, kauth.kakao.com/oauth/authorize 엔드포인트를 통해 로그인 요청을 시작합니다. 이 과정에서 state 파라미터는 CSRF 공격 방지 및 로그인 후 상태 유지를 위해 사용됩니다.

하지만 카카오 개발자 문서에는 state 파라미터나 전체 URL의 길이 제한에 대한 명시적인 정보가 없습니다. 이는 카카오 로그인 API의 내부 구현이 Nginx와 같은 웹 서버에 의존하기 때문에, 웹 서버의 제한을 따르는 것으로 추정됩니다.

해결 방안

1. UTM 파라미터 및 추적 코드 제거

가장 간단한 해결책은 URL에서 마케팅 추적 파라미터를 제거하는 것입니다. 실제로 저희 테스트 결과, UTM 파라미터와 fbclid를 제거하자 카카오 로그인 API가 정상적으로 동작했습니다.

function removeTrackingParams(url: string) {
  const urlObj = new URL(url);
  const params = urlObj.searchParams;
  
  // 추적 파라미터 제거
  ['utm_medium', 'utm_source', 'utm_campaign', 'utm_description', 
   'utm_content', 'utm_id', 'utm_term', 'fbclid'].forEach(param => {
    params.delete(param);
  });
  
  return urlObj.toString();
}

2. State 파라미터 최적화

state 파라미터에 포함되는 JSON 데이터를 최적화하여 불필요한 정보를 제거하고 키 이름을 줄이는 방법도 있습니다.

function optimizeStateParam(stateObj) {
  // 필수 필드만 유지
  const optimizedState = {
    n: stateObj.next,                      // next 대신 n 사용
    m: stateObj.logMetadata?.navigation,   // metadata 간소화
    f: stateObj.from                       // from 대신 f 사용
  };
  
  // URL에서 추적 파라미터 제거
  if (optimizedState.n && optimizedState.n.includes('?')) {
    optimizedState.n = removeTrackingParams(optimizedState.n);
  }
  if (optimizedState.f && optimizedState.f.includes('?')) {
    optimizedState.f = removeTrackingParams(optimizedState.f);
  }
  
  return optimizedState;
}

3. 서버 측 상태 관리 (권장)

가장 안정적인 방법은 상태 정보를 서버에 저장하고 state 파라미터에는 짧은 식별자만 포함시키는 것입니다:

// 클라이언트 측
async function generateStateToken(stateData) {
  try {
    const response = await fetch('/api/auth/state-token', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(stateData)
    });
    
    const { token } = await response.json();
    return token; // 짧은 토큰 반환
  } catch (error) {
    console.error('상태 토큰 생성 실패:', error);
    throw error;
  }
}

// 로그인 URL 생성
async function createKakaoLoginUrl(stateData) {
  const stateToken = await generateStateToken(stateData);
  
  return `https://kauth.kakao.com/oauth/authorize?client_id=${CLIENT_ID}&redirect_uri=${encodeURIComponent(REDIRECT_URI)}&response_type=code&state=${stateToken}`;
}

서버 측에서는 이 토큰과 상태 데이터를 연결하여 저장하고, 카카오 로그인 콜백에서 토큰을 통해 원래 상태를 복원합니다.

// 서버 측 (Node.js 예시)
app.post('/api/auth/state-token', (req, res) => {
  const stateData = req.body;
  const token = generateRandomToken(); // 무작위 토큰 생성
  
  // Redis나 세션 스토어에 저장 (15분 만료)
  stateStore.set(token, stateData, 60 * 15);
  
  res.json({ token });
});

app.get('/oauth/callback', (req, res) => {
  const { code, state: token } = req.query;
  
  // 토큰으로 원래 상태 복원
  const originalState = stateStore.get(token);
  if (!originalState) {
    return res.status(400).send('Invalid or expired state token');
  }
  
  // 나머지 로그인 처리...
});

보다 안정적인 개발을 위한 권장사항

1. URL 길이 제한 인식

웹 개발 시 URL 길이 제한을 항상 염두에 두어야 합니다:

대부분의 서버는 URL 길이를 4KB~8KB로 제한합니다.
GET 요청보다 POST 요청을 사용하여 많은 데이터를 전송하는 것이 좋습니다.
특히 외부 API와 연동할 때는 URL 길이 제한을 확인하고 대비해야 합니다.

2. OAuth 구현 시 고려사항

OAuth 인증 흐름을 구현할 때는 다음 사항을 고려해야 합니다:

state 파라미터는 간결하게 유지하고, 필요한 정보만 포함시킵니다.
상태 정보가 많은 경우 서버 측 저장소를 활용합니다.
CSRF 방지를 위한 랜덤 토큰은 반드시 포함시킵니다.

3. 마케팅 추적과 인증 분리

마케팅 추적 매개변수(UTM)와 인증 프로세스를 분리하는 것이 좋습니다:

인증 요청 전에 UTM 파라미터를 분리하여 저장
인증 완료 후 다시 UTM 정보를 활용하는 방식 채택
분석 데이터는 쿠키나 로컬 스토리지에 임시 저장하는 방법 고려

4. 에러 처리 및 모니터링

예상치 못한 에러에 대비한 처리 방법도 중요합니다:

URL 길이 제한 오류(414)에 대한 명시적 처리
로깅 및 모니터링을 통한 비정상적인 요청 감지
사용자에게 친절한 오류 메시지 제공

결론

카카오 로그인 URL 길이 제한 문제는 Nginx의 기본 설정과 관련이 있으며, 특히 마케팅 추적 파라미터가 포함된 긴 URL을 사용할 때 나타납니다. 이 문제를 해결하기 위해서는 URL 길이를 줄이거나 서버 측 상태 관리를 도입하는 것이 효과적입니다.

웹 개발자로서 우리는 각 시스템의 제한사항을 이해하고, 이에 맞게 설계하는 것이 중요합니다. 특히 외부 API와 연동할 때는 공식 문서에 명시되지 않은 제한사항도 고려해야 합니다.

이 경험을 통해 URL 길이 제한, OAuth 구현 방법, 그리고 보다 안정적인 웹 서비스 개발에 대한 인사이트를 얻을 수 있었습니다. 이 글이 비슷한 문제에 직면한 개발자들에게 도움이 되길 바랍니다.

참고 자료

Next.js에서 SEO 최적의 렌더링 전략

hmk run dev — Fri, 25 Apr 2025 00:35:37 +0900

Next.js 14의 App Router 환경에서는 서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR), 정적 생성(SSG), ISR 등 다양한 렌더링 방식을 상황에 맞게 조합할 수 있다. 특히 App Router는 서버 컴포넌트와 클라이언트 컴포넌트를 구분하고, 내장 fetch의 캐시 전략과 메타데이터 설정이 유연해지면서 SEO 대응 방식도 훨씬 정교해졌다.

그중 하나가 searchParams 기반 SSR이다. 기존의 다이나믹 라우트 방식과 달리, URL의 query string을 기반으로 서버에서 데이터를 받아 페이지를 렌더링하는 방식이다. 이 방식은 필터형 상품 페이지나 SKU 조합 페이지에서 매우 유용하다. 하지만 SEO 관점에서 보면 몇 가지 주의할 점이 있다.

렌더링 방식별 SEO 적절성 비교

렌더링 방식	HTML 내 콘텐츠 포함 여부	URL 구조	SEO 적합성
다이나믹 라우트 SSR /sku/[id]	O (SSR)	고유한 path	가장 우수
searchParams 기반 SSR /sku?plan=lte&color=black	O (SSR)	query string	우수하나 상대적으로 약함
CSR 클라이언트에서만 fetch	X	URL은 다양해도 HTML엔 없음	매우 낮음

searchParams 기반 SSR은 왜 다이나믹 라우트 SSR보다 SEO에 약할까?

1. 검색엔진의 인식 방식

검색엔진은 보통 URL path가 다른 페이지를 별개의 콘텐츠로 인식하고 인덱싱하지만,
query string 기반 URL은 같은 페이지의 파생된 버전으로 간주하는 경향이 있다.
예를 들어 /sku?color=black&plan=lte와 /sku?color=white&plan=lte는
검색엔진 입장에선 동일한 /sku의 일부로 판단될 수 있다.

2. 중복 콘텐츠 리스크

searchParams 조합이 많아질수록 검색엔진이 이를 중복 콘텐츠로 간주할 가능성도 커진다.
따라서 각 조합별 페이지가 독립적인 콘텐츠임을 명확하게 하기 위해 canonical 설정, 메타 태그 차별화가 필요하다.

3. sitemap 자동 생성의 한계

다이나믹 라우트는 generateStaticParams() 등을 활용해 sitemap을 자동으로 생성할 수 있다.
반면 searchParams는 조합이 너무 많기 때문에 URL을 수동으로 선정하거나 별도로 sitemap을 구성해야 한다.

그렇다면 searchParams 기반 SSR은 SEO에 부적합할까?

그렇지 않다. CSR에 비해서는 훨씬 SEO에 적합하다.

서버 컴포넌트에서 fetch()로 데이터를 받아 렌더링하면, HTML 응답에 실질적인 콘텐츠가 포함된다.
generateMetadata()를 통해 query string 기반으로 동적인 메타태그(title, description 등)를 만들 수 있다.
초기 렌더링 시점에 콘텐츠가 완전하게 포함되므로 Googlebot 등은 렌더링 없이도 인덱싱이 가능하다.

즉, CSR보다는 SEO에 훨씬 유리하며, 다이나믹 라우트만큼의 정밀도는 아니지만 실용적 수준의 대응은 충분히 가능하다.

실제 적용 전략: 하이브리드 구조 + SEO 대응

searchParams 기반의 필터/조합 페이지에서 다음과 같은 전략이 유효하다.

1. SSR로 초기 진입 시 콘텐츠 포함

서버 컴포넌트에서 searchParams를 기반으로 fetch하고, 그 결과를 HTML에 포함한다.

export default async function Page({ searchParams }) {
  const data = await fetchSku(searchParams)
  return <SkuList data={data} />
}

2. 메타데이터는 searchParams 기반으로 동적 생성

export async function generateMetadata({ searchParams }) {
  const { plan, color } = searchParams
  return {
    title: `${plan} 요금제 - ${color} 색상 기기`,
    description: `${plan} 요금제와 ${color} 색상의 기기를 조합한 구성입니다.`,
  }
}

3. 주요 조합만 선택적으로 sitemap에 포함

SEO에서 주요 조합만 노출하면 된다면, sitemap 생성 시 조합 리스트를 별도로 관리하여 명시적으로 URL을 포함시키면 된다.

결론

searchParams 기반 SSR은 SEO에 충분히 대응할 수 있는 방식이다.
다이나믹 라우트 SSR보다는 구조적으로 인덱싱에 불리할 수 있지만, CSR보다는 확연히 낫다.
중요한 것은 콘텐츠가 HTML에 렌더링되어 포함되어야 하고, generateMetadata, canonical, sitemap 등의 보완 요소를 함께 적용하는 것이다.
유저 인터랙션 중심의 페이지에서는 하이브리드 전략이 적절하며, SEO가 중요한 조합만 선택적으로 대응하는 것이 실용적인 방법이다.

Next.js 상황에 맞는 렌더링 방식 선택 가이드

hmk run dev — Fri, 25 Apr 2025 00:19:28 +0900

Next.js는 다양한 렌더링 방식을 제공합니다. 정적 생성(SSG), 서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR), 그리고 점진적 정적 생성(ISR)까지 다양한 전략이 가능하죠. 버전이 14에 도달하면서 App Router가 정식화되었고, fetch() 내장, cache, revalidate, searchParams, server/client component 분리 등 보다 유연한 방식으로 구성할 수 있게 되었습니다.

하지만 기능이 다양해진 만큼 "어떤 상황에서 어떤 렌더링 방식을 선택해야 하는지"는 더욱 고민되는 지점입니다. 특히 실무에서 많이 마주치는 SKU 기반 조합 페이지나, 필터형 검색 결과 페이지 등에서는 의사결정이 쉽지 않습니다.

이번 글에서는 실제 사례를 중심으로, 어떤 렌더링 방식을 선택해야 할지를 정리해 보겠습니다.

렌더링 방식 정리

방식설명대표 사용 상황

방식	설명	대표 사용 상황
정적 생성 (SSG)	빌드 시 HTML 생성	마케팅 랜딩, 공지사항
서버 사이드 렌더링 (SSR)	요청 시 서버에서 HTML 생성	로그인 필요, 맞춤형 대시보드
클라이언트 렌더링 (CSR)	브라우저에서 fetch 후 렌더	인터랙션 위주 페이지, 설정/필터
ISR (revalidate)	일정 주기로 정적 페이지 재생성	실시간성이 낮은 상품 페이지

SKU/옵션 조합 페이지에서의 고민

실무에서는 핸드폰, 노트북 등 상품을 선택할 때 "기기 + 요금제 + 색상" 같은 옵션 조합에 따라 화면이 바뀌는 구조를 자주 마주칩니다. 이 경우 페이지 설계 방향은 다음 두 가지 중 하나로 갈 수 있습니다.

다이나믹 라우트 기반 SSR (/sku/[id])
searchParams 기반 SSR 또는 CSR (/sku?plan=lte&color=black)

다이나믹 라우트 SSR vs searchParams 기반 구조 비교

항목	다이나믹 라우트 SSR	searchParams 기반
URL 형태	/sku/iphone15	/sku?device=iphone15&plan=lte
서버 fetch 방식	params로 식별	searchParams 파싱
SEO	매우 우수 (경로별 인덱싱)	상대적으로 제한적
조합 수 많을 때	URL 폭발 가능성 있음	유연하게 대응 가능
UX (옵션 변경 시)	페이지 이동 필요	URL만 바꾸고 데이터만 교체 가능
캐시 최적화	ISR 가능	캐시 활용은 fetch 조합 기반으로 (reavalidate)

결론적으로, 옵션 조합이 매우 다양해질 가능성이 높고 유저가 선택을 반복적으로 할 수 있는 구조라면 searchParams 기반으로 렌더링 구조를 잡는 것이 더 효율적일 수 있습니다.

다른 방법: SSR + CSR 하이브리드 방식

Next.js 14의 App Router에서는 서버 컴포넌트에서 SSR을 처리하고, 클라이언트 컴포넌트에서는 React Query 같은 라이브러리를 활용해 CSR 렌더링을 적용하는 하이브리드 방식이 가능합니다.

구조 요약

첫 진입 시에는 SSR로 searchParams 기반 데이터를 서버에서 가져옴
이후 사용자가 요금제, 컬러 등을 변경하면 CSR(fetch) 방식으로 화면만 바뀜
URL은 항상 현재 조합을 반영하고 있어 공유 가능함

// app/sku/page.tsx
import { fetchSku } from '@/lib/api'
import SkuClient from './SkuClient'

export default async function Page({ searchParams }) {
  const data = await fetchSku(searchParams)
  return <SkuClient initialData={data} initialParams={searchParams} />
}

// app/sku/SkuClient.tsx
'use client'

import { useQuery } from '@tanstack/react-query'
import { useSearchParams, useRouter } from 'next/navigation'

export default function SkuClient({ initialData, initialParams }) {
  const router = useRouter()
  const params = useSearchParams()

  const queryKey = ['sku', params.toString()]
  const { data } = useQuery({
    queryKey,
    queryFn: () => fetch(`/api/sku?${params}`).then(res => res.json()),
    initialData,
  })

  const handleChange = (newParams) => {
    router.replace(`?${newParams.toString()}`)
  }

  return (
    <>
      <OptionSelector onChange={handleChange} />
      <SkuViewer data={data} />
    </>
  )
}

CSR 하이브리드 구조에서 클라이언트 컴포넌트가 메인 콘텐츠를 담당하면,

그 부분은 HTML로 SSR 되지 않아 SEO가 약해지는 것 아닌가?

핵심 정리 먼저

✅ 맞습니다: 클라이언트 컴포넌트 내부에서만 콘텐츠를 fetch해 렌더링하면, HTML에 해당 콘텐츠가 포함되지 않기 때문에 검색엔진(특히 Googlebot)이 제대로 인덱싱하지 못할 수 있습니다.
✅ 맞습니다: 반대로 서버 컴포넌트만으로 구성하면 HTML에 실제 콘텐츠가 포함되므로 SEO에 훨씬 유리합니다.
✅ 맞습니다: 클릭 가능한 요소(Link)만 있다면 그것은 클라이언트 컴포넌트일 필요는 없습니다. <Link>는 서버 컴포넌트에서도 사용할 수 있습니다.

CSR 하이브리드 구조의 SEO 한계

// 예: 클라이언트 컴포넌트 내부에서만 데이터 fetch
'use client'

const Page = () => {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetch('/api/sku?plan=lte&color=black').then(res => res.json()).then(setData)
  }, [])

  return <>{data?.title}</>
}

이 경우:

초기 HTML에는 data가 없음
검색엔진이 이 페이지를 방문해도 콘텐츠를 못 보고 지나침
CSR로만 구성된 콘텐츠는 SEO 측면에서는 거의 의미 없음 (특히 meta tag와 og tag도 CSR이면 의미 없음)

서버 컴포넌트만으로도 인터랙션 가능한가?

Next.js App Router에서 <Link> 같은 인터랙션 컴포넌트는 서버 컴포넌트에서도 사용할 수 있습니다.

// 서버 컴포넌트에서도 사용 가능
<Link href="/sku?plan=lte&color=black">이 요금제 보기</Link>

<Link> 자체는 클라이언트에서 hydrate되지만, HTML은 서버에서 내려오기 때문에 SEO 노출에도 전혀 문제 없습니다.

그럼 더 나은 방법은?

당신이 원하시는 것이:

SEO 잘 되면서
인터랙션 UX도 자연스럽고
서버 부하도 최소화하고 싶다면

추천 구조: 서버 컴포넌트 SSR + 부분적 클라이언트 CSR

// /app/sku/page.tsx (서버 컴포넌트)
import { fetchSku } from '@/lib/api'
import { SkuList } from './SkuList'

export default async function Page({ searchParams }) {
  const data = await fetchSku(searchParams) // SSR 시점에 데이터 fetch됨
  return (
    <>
      <h1>{data.title}</h1> {/* HTML에 포함되어 인덱싱 가능 */}
      <SkuList data={data.items} />
    </>
  )
}

// SkuList.tsx (클라이언트 컴포넌트 아님)
import Link from 'next/link'

export function SkuList({ data }) {
  return (
    <ul>
      {data.map(item => (
        <li key={item.id}>
          <Link href={`?plan=${item.plan}&color=${item.color}`}>{item.name}</Link>
        </li>
      ))}
    </ul>
  )
}

핵심 특징

메인 콘텐츠는 서버에서 fetch 되어 HTML에 포함 → SEO 매우 우수
클릭 가능한 요소는 서버 컴포넌트에서도 <Link>로 자연스럽게 처리
선택 이벤트 처리만 필요한 곳에 use client를 붙인 클라이언트 컴포넌트를 사용 (예: 옵션 선택 슬라이더 등)

언제 어떤 방식이 적합한가

상황	추천 방식
고정된 콘텐츠, 마케팅성 페이지	SSG (정적 생성)
로그인 필요, 세션 기반 페이지	SSR (server component)
실시간 옵션 선택이 많은 페이지	CSR 또는 SSR+CSR 하이브리드
검색 필터, 리스트 결과	searchParams 기반 CSR
SEO 최적화 필요 + 경로별 인덱싱	다이나믹 라우트 SSR 또는 ISR

마치며

Next.js 14는 SSR과 CSR, 그리고 정적 생성 방식들을 상황에 따라 혼합할 수 있는 매우 유연한 아키텍처를 제공합니다. 중요한 것은 성능 최적화나 개발 편의성보다 사용자 경험과 비즈니스 목표에 맞는 구조를 선택하는 것입니다.

특히 선택 조합이 많은 SKU 페이지처럼 복잡한 UX를 다루는 경우, searchParams 기반 SSR + CSR 구조가 성능과 UX, 유지보수성 모두에서 매우 이상적인 선택이 될 수 있습니다.

Next.js 서버사이드 keep alive

hmk run dev — Tue, 22 Apr 2025 15:22:11 +0900

Next.js 프로젝트에서 백엔드 API와 통신할 때, 우리는 종종 브라우저 또는 서버(SSR/API 라우트 등)에서 외부 서버로 HTTP 요청을 보냅니다. 이때 성능 최적화를 고려한다면 "keep-alive" 설정을 살펴볼 필요가 있습니다.

브라우저에서 keep-alive는 어떻게 작동할까?
서버 → 서버 요청에서는 왜 명시적으로 설정이 필요할까?
실제로 어떻게 적용할 수 있을까?

HTTP keep-alive란?

기본적으로 HTTP 요청은 다음 흐름을 따릅니다:

연결 열기 → 요청 보내기 → 응답 받기 → 연결 닫기

이런 구조는 요청마다 새로운 TCP 연결을 만들고 끊는 비효율을 초래합니다. 특히, 서버 → 서버 간에 수백~수천 개의 API 호출이 일어난다면 이 비용은 무시할 수 없습니다.

keep-alive는 이 문제를 해결하는 방식입니다. 한 번 연결한 TCP 소켓을 재사용해서 여러 HTTP 요청을 보낼 수 있게 합니다.

브라우저에서는 어떻게 동작할까?

브라우저는 기본적으로 HTTP/1.1을 기반으로 하기 때문에, keep-alive는 디폴트로 활성화되어 있습니다.
즉, 클라이언트 사이드에서 fetch, axios 등을 통해 요청을 보낼 때는 특별한 설정 없이도 연결이 재사용됩니다.

하지만 이 연결은 브라우저가 내부적으로 관리합니다:

같은 origin 요청끼리만 재사용
연결 수 제한 있음 (도메인당 6개 등)
idle timeout이 적용됨

요약: 브라우저는 알아서 keep-alive를 잘 관리하니, 따로 설정할 필요는 없습니다.

서버 → 서버 요청에서는?

반대로, Next.js 서버에서 실행되는 코드 (예: getServerSideProps, API Route 등) 는 Node.js의 http 모듈을 기반으로 동작합니다.

Node.js의 기본 설정은 keepAlive: false이기 때문에, 매 요청마다 TCP 연결을 새로 생성하게 됩니다.

이럴 경우 다음을 명시적으로 설정해야 합니다:

1. node-fetch + http.Agent

import fetch from 'node-fetch';
import http from 'http';

const keepAliveAgent = new http.Agent({ keepAlive: true });

await fetch('https://api.example.com/data', {
  agent: keepAliveAgent,
});

2. undici – 더 빠르고 공식 추천되는 방식

import { fetch, Agent } from 'undici';

const agent = new Agent({
  keepAliveTimeout: 10_000,      // idle 상태에서 유지할 시간
  keepAliveMaxTimeout: 15_000,   // 최대 연결 유지 시간
});

await fetch('https://api.example.com/data', {
  dispatcher: agent,
});

3. axios 사용 시

import axios from 'axios';
import http from 'http';

const httpAgent = new http.Agent({ keepAlive: true });

const response = await axios.get('https://api.example.com/data', {
  httpAgent,
});

언제 keep-alive를 쓰는 게 좋을까?

다음 조건에 해당한다면 적극 도입을 고려하세요:

같은 서버에 반복적으로 요청하는 구조 (ex. 내부 API Gateway, 백엔드 서버)
대량의 API 호출이 한 페이지 내에서 이뤄지는 구조
SSR에서 응답 속도 개선이 필요한 경우

마무리

브라우저는 keep-alive를 자동으로 관리하므로 따로 신경 쓸 필요 없음
서버 측에서는 Agent를 직접 설정하지 않으면 요청마다 새로운 TCP 연결이 열림
keep-alive 설정만으로도 평균 요청 시간이나 서버 부하가 눈에 띄게 개선될 수 있음

팀에서 성능 개선을 논의 중이라면, 이 설정이 적용되어 있는지 한번 확인해보세요.
특히 getServerSideProps, API Route, 혹은 백엔드 간 통신을 자주 쓰는 구조라면 꽤 큰 차이를 만들어낼 수 있습니다.

프로그래밍에서 Buffer란?

hmk run dev — Sun, 23 Mar 2025 12:10:47 +0900

프로그래밍에서의 Buffer

Buffer(버퍼)는 데이터를 임시로 저장하는 메모리 공간을 의미합니다. 일반적으로 다음과 같은 목적으로 사용됩니다:

속도 차이 해결
- CPU, 메모리, 디스크, 네트워크 등의 장치는 서로 다른 속도로 데이터를 처리합니다. 버퍼를 사용하면 빠른 장치가 느린 장치를 기다리지 않고 계속 작업을 수행할 수 있습니다.
- 예: 키보드 입력 버퍼, 그래픽 렌더링 버퍼, 스트리밍 버퍼
데이터 변환 및 가공
- 데이터를 일정한 크기로 나누거나, 변환할 때 중간 저장소 역할을 합니다.
- 예: 동영상 인코딩, 오디오 프로세싱
I/O 성능 최적화
- 디스크나 네트워크와 같은 느린 장치에서 데이터 입출력을 할 때, 여러 번의 작은 작업을 모아 한 번에 처리하면 성능이 향상됩니다.
- 예: 파일 시스템의 디스크 캐시(Buffer Cache), 네트워크 패킷 버퍼

운영체제에서 네트워크 통신 시 Buffer의 역할

운영체제가 네트워크 통신을 할 때, 버퍼는 송신(Send) 버퍼와 수신(Receive) 버퍼로 나뉩니다.

송신 버퍼(Send Buffer)
- 애플리케이션이 보낼 데이터를 운영체제(커널)에 전달하면, 운영체제는 이 데이터를 네트워크 인터페이스에 적절히 분배하여 전송합니다.
- 네트워크가 혼잡하거나 수신 측이 데이터를 바로 받을 수 없는 경우, 버퍼에서 데이터를 잠시 저장했다가 적절한 시점에 전송합니다.
- TCP의 경우, TCP Send Buffer에 데이터가 쌓이고, 적절한 패킷 크기로 나눠 전송됩니다.
수신 버퍼(Receive Buffer)
- 네트워크에서 받은 데이터를 운영체제(커널)가 저장하는 공간입니다.
- 애플리케이션이 데이터를 처리할 준비가 되면 운영체제는 수신 버퍼에서 데이터를 전달합니다.
- TCP의 경우, TCP Receive Buffer에 데이터가 쌓이고, 애플리케이션이 recv() 같은 함수를 호출하면 데이터를 가져갑니다.

왜 버퍼가 필요한가?

네트워크에서 데이터를 송수신할 때,

CPU와 네트워크 속도가 다름 → CPU는 매우 빠르지만, 네트워크는 상대적으로 느림
패킷이 한 번에 도착하지 않음 → 데이터가 여러 개의 패킷으로 나뉘어 전송됨
애플리케이션이 즉시 처리하지 못할 수도 있음 → 받은 데이터를 즉시 사용하지 않을 수도 있음

이런 문제를 해결하기 위해 운영체제는 네트워크 데이터를 버퍼에 저장하고, 애플리케이션이 필요할 때 가져가도록 처리합니다.

송신(Tx)과 수신(Rx)에서의 Buffer 역할

(1) 송신 버퍼 (Send Buffer)

애플리케이션이 네트워크로 데이터를 보내면, 운영체제의 송신 버퍼(Send Buffer)에 먼저 저장됨
네트워크 장치는 버퍼에서 데이터를 가져가 일정 크기의 패킷(packet)으로 나누어 송신
데이터가 성공적으로 전송되면, 해당 버퍼 공간이 해제됨

예제: 송신 버퍼에서 데이터를 보내는 과정

애플리케이션 → 송신 버퍼 (운영체제) → 네트워크 카드(NIC) → 인터넷 전송

송신 버퍼가 가득 차면?
→ 애플리케이션이 새로운 데이터를 쓰려고 해도 대기(blocking) 해야 함
→ 해결책: TCP 윈도우 크기 조절

(2) 수신 버퍼 (Receive Buffer)

네트워크에서 도착한 데이터는 운영체제의 **수신 버퍼(Receive Buffer)**에 먼저 저장됨
애플리케이션이 필요할 때 수신 버퍼에서 데이터를 가져감
애플리케이션이 데이터를 가져가지 않으면, 버퍼가 가득 차서 추가 데이터 수신이 불가능해짐

예제: 수신 버퍼에서 데이터를 받는 과정

네트워크 카드(NIC)  →  수신 버퍼 (운영체제)  →  애플리케이션

수신 버퍼가 가득 차면?
→ 운영체제가 더 이상 패킷을 받을 수 없어서, 송신 측에 패킷을 다시 보내달라고 요청(패킷 손실, 재전송)

TCP와 UDP에서 Buffer 차이

(1) TCP (신뢰성 있는 전송)

TCP는 송신 버퍼와 수신 버퍼를 관리하며, 손실된 패킷을 재전송하는 메커니즘이 있음
버퍼 크기를 자동으로 조절하여 네트워크 혼잡을 방지 (TCP 윈도우 크기)
버퍼가 부족하면 애플리케이션이 데이터를 더 이상 송신하거나 수신할 수 없음

(2) UDP (비신뢰성 전송)

UDP는 운영체제의 수신 버퍼만 사용하며, 버퍼가 가득 차면 데이터가 손실됨
패킷이 손실되더라도 재전송하지 않음 (애플리케이션이 직접 관리해야 함)

버퍼 크기 조절

운영체제에서는 네트워크 버퍼 크기를 조절하여 성능을 최적화할 수 있습니다.

- 버퍼 크기 확인 (Linux)

sysctl net.core.rmem_max   # 수신 버퍼 최대 크기
sysctl net.core.wmem_max   # 송신 버퍼 최대 크기

- 버퍼 크기 설정 (Linux)

sysctl -w net.core.rmem_max=8388608  # 수신 버퍼 크기 증가 (8MB)
sysctl -w net.core.wmem_max=8388608  # 송신 버퍼 크기 증가 (8MB)

버퍼 관련 성능 이슈

버퍼 크기가 너무 작으면?
→ 네트워크가 빠를 경우, 애플리케이션이 데이터를 가져가기 전에 버퍼가 가득 차서 패킷이 손실될 가능성 증가
버퍼 크기가 너무 크면?
→ 메모리를 불필요하게 많이 사용하고, 응답 시간이 지연될 가능성이 있음
최적의 버퍼 크기 설정이 중요
→ 애플리케이션 특성, 네트워크 속도, 패킷 손실률 등을 고려하여 조정해야 함

macOS의 네트워크 버퍼 관리 특징

✅ 자동 튜닝 (Auto-tuning)

macOS는 TCP의 **윈도우 크기(TCP Window Size)**와 버퍼 크기를 자동으로 조절하여 네트워크 성능을 최적화함.
네트워크 속도, 패킷 손실률, CPU 사용량 등을 고려하여 운영체제가 버퍼 크기를 동적으로 조절.
대부분의 일반적인 사용자는 버퍼 크기를 수동으로 조절할 필요 없음.

그럼에도 불구하고 이슈가 생길 수 있는 경우

고속 네트워크 환경에서 성능이 제한됨
(예: 10Gbps 이상의 네트워크에서 충분한 성능이 나오지 않는 경우)
대용량 파일 전송 시 속도가 기대보다 낮을 수 있음
(버퍼 크기가 너무 작게 설정되면 네트워크 대역폭을 충분히 활용하지 못할 수도 있음)
실시간 스트리밍, VoIP(인터넷 전화)에서 지연 발생 가능
(UDP 사용 시 버퍼 부족으로 인해 패킷 손실이 발생할 가능성이 있음)

정리

**버퍼(Buffer)**는 네트워크 데이터를 운영체제와 애플리케이션 간 임시 저장하는 공간
송신 버퍼(Send Buffer): 애플리케이션이 보낸 데이터를 저장 후, 네트워크로 전송
수신 버퍼(Receive Buffer): 네트워크에서 받은 데이터를 저장 후, 애플리케이션으로 전달
TCP는 자동 버퍼 조절 및 재전송을 지원, UDP는 버퍼 크기가 고정되어 손실 발생 가능
버퍼 크기 조절을 통해 성능을 최적화할 수 있음

랭체인과 database로 RAG 구현하기

hmk run dev — Sat, 15 Feb 2025 15:37:06 +0900

LangChain과 Pinecone으로 구현하는 RAG 패턴

LangChain과 Pinecone을 사용하여 RAG 패턴을 구현하는 방법에 대해 알아보겠습니다.
RAG는 대규모 언어 모델(LLM)의 응답을 더욱 정확하고 신뢰성 있게 만들어주는 핵심 패턴입니다.

1. 데이터 준비 및 임베딩 단계

먼저 데이터를 벡터 형태로 변환하여 저장하는 과정이 필요합니다.

이 단계에서는:

OpenAI의 임베딩 모델을 초기화하여 텍스트를 벡터로 변환할 준비를 합니다

Pinecone 벡터 스토어를 설정하여 벡터화된 데이터를 저장할 공간을 마련합니다

# OpenAI의 임베딩 모델 초기화
embeddings = OpenAIEmbeddings(openai_api_key=os.getenv("OPENAI_API_KEY"))

# Pinecone 벡터 저장소 초기화
vectorstore = PineconeVectorStore(
    index_name=os.getenv("INDEX_NAME"), 
    embedding=embeddings

2. 검색 단계

사용자의 질문을 받아 관련 정보를 검색하는 단계입니다.

이 단계에서는:

사용자의 쿼리를 벡터로 변환합니다

Pinecone에서 유사도 기반으로 관련 문서를 검색합니다

# 벡터 스토어의 검색 기능 초기화
retriever = vectorstore.as_retriever()

# 검색 체인 생성
retrieval_chain = create_retrieval_chain(
    retriever=retriever,
    combine_docs_chain=combine_docs_chain
)

3. 문서 처리 단계

검색된 문서들을 처리하고 결합하는 단계입니다.
이 단계에서는:

검색된 여러 문서들을 하나의 문맥으로 결합합니다.

결합된 문서를 LLM이 이해할 수 있는 형태로 포맷팅합니다.

def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

# 문서 결합 체인 생성
combine_docs_chain = create_stuff_documents_chain(llm, retrieval_qa_chat_prompt)

4. 응답 생성 단계

LLM을 사용하여 최종 응답을 생성하는 단계입니다.

검색된 데이터 기반으로 프롬프트에 추가해 LLM에 다시한번 검색후 근거에 있는 답변을 받고 사람에게 익숙한 자연어 처리를 수행합니다.

이 단계에서는:

검색된 문서와 사용자의 질문을 포함한 프롬프트를 생성합니다.

LLM이 검색된 문서를 기반으로 정확한 응답을 생성합니다

응답을 지정된 형식(3문장 이내, 감사 인사 포함)에 맞게 출력합니다

template = """
Use the following pieces of retrieved context to answer the question at the end.
If you don't know the answer, just say that you don't know. don't try to make up an answer.
Use three sentence maximum and keep the answer concise as possible.
Always say "thank for your asking" at the end of the answer.

{context}

Question: {question}

Helpful Answer:
"""

custom_rag_prompt = PromptTemplate.from_template(template)

rag_chain = (
    {"context": vectorstore.as_retriever() | format_docs, "question": RunnablePassthrough()}
    | custom_rag_prompt
    | llm
    | StrOutputParser()
)

결론

RAG 패턴은 LLM의 한계를 보완하고 더 신뢰할 수 있는 응답을 생성하는 강력한 방법입니다. LangChain과 Pinecone을 사용하면 이러한 RAG 패턴을 쉽게 구현할 수 있으며, 특히:

벡터 데이터베이스를 통한 효율적인 정보 검색

관련 문서 기반의 정확한 응답 생성

커스터마이즈 가능한 응답 형식

등의 장점을 활용할 수 있습니다. 이상으로 RAG 패턴 구현에 대한 설명을 마치겠습니다. 실제 프로젝트에 적용하실 때 참고가 되셨기를 바랍니다.

쿠버네티스 pod

hmk run dev — Sun, 2 Feb 2025 22:25:06 +0900

Pod: 쿠버네티스에서 가장 작은 실행 단위

쿠버네티스에서 Pod는 애플리케이션을 실행하는 가장 작은 단위입니다. 하지만 여기서 중요한 점은 Pod 하나에는 하나 이상의 컨테이너가 있을 수 있다는 것입니다. 마치 하나의 집 안에 여러 사람이 살 수 있는 것처럼, Pod 안에 여러 개의 컨테이너가 함께 살 수 있습니다.

일상적인 예시로 이해하기

생각해보세요, 집을 하나 짓는다고 했을 때, 이 집 안에 여러 명의 사람들이 함께 살 수 있습니다. 집을 짓는 것이 Pod이고, 그 안에서 함께 사는 사람들이 바로 컨테이너라고 할 수 있습니다. 집을 하나 짓는 데 있어 Pod는 여러 개의 컨테이너가 함께 묶여서 동작하는 공간인 셈이죠.

Pod의 구조

Pod는 컨테이너들의 집합입니다. 일반적으로 Pod에는 하나의 컨테이너만 들어 있지만, 여러 개의 컨테이너가 함께 있어야 할 때도 있습니다. 예를 들어, 서로 긴밀히 상호작용하는 두 애플리케이션이 하나의 Pod 안에서 실행될 수 있습니다. 이러한 상황은 Sidecar 패턴으로 자주 사용됩니다.

Pod 안의 여러 컨테이너

컨테이너 1: 하나의 애플리케이션을 실행하는 컨테이너
컨테이너 2: 그 애플리케이션에 필요한 보조 작업을 하는 컨테이너 (예: 로그 수집, 데이터 처리 등)

이러한 컨테이너들은 Pod 안에서 자원(CPU, 메모리 등)을 공유하며 함께 동작합니다. 두 컨테이너가 상호작용해야 하기 때문에 Pod 안에 함께 배치된 것이죠.

Pod의 특징

같은 네트워크 공간을 공유: Pod 안의 모든 컨테이너는 같은 IP 주소를 공유하며, 서로 localhost처럼 통신할 수 있습니다. 마치 같은 집에 살고 있는 사람들이 같은 집 주소를 공유하는 것과 같죠. 그래서 같은 Pod 안의 컨테이너들은 서로 쉽게 통신할 수 있습니다.
공유 스토리지: Pod 안의 여러 컨테이너는 공유 디스크를 사용할 수 있습니다. 예를 들어, 여러 컨테이너가 동일한 데이터를 저장하고 읽어야 할 때, Pod는 공유 스토리지를 제공합니다. 이는 마치 집 안에 있는 여러 사람이 같은 책상이나 서랍을 공유하는 것처럼, 데이터를 공유하는 방식입니다.
생애주기 관리: Pod는 하나의 생애주기를 가집니다. 즉, Pod가 생성되면 하나의 단위로 실행, 종료, 삭제됩니다. Pod 내부에서 실행되는 컨테이너들도 이와 동일하게 같은 생애주기를 가집니다. 이는 마치 하나의 집이 만들어지고, 사람이 들어가 살고, 집이 없어지는 것과 같습니다.

Pod의 예시

간단한 웹 애플리케이션 예시

웹 애플리케이션을 실행하는 Pod를 예시로 들어보겠습니다.

Pod 안에는 웹 서버를 실행하는 컨테이너가 하나 있을 수 있습니다. 이 컨테이너는 실제로 웹 애플리케이션의 로직을 처리하고 사용자 요청을 받습니다.
또 다른 컨테이너는 로그를 수집하거나, 캐시 서버로서 웹 서버와 통신하는 역할을 할 수 있습니다. 이 두 컨테이너는 같은 IP와 같은 네트워크 공간을 공유하면서 협력합니다.

Pod 생성과 관리

쿠버네티스에서 Pod는 배포 설정을 통해 관리됩니다. 예를 들어, 웹 애플리케이션이 잘 실행되도록 여러 Pod를 동시에 실행해야 할 때는 ReplicaSet을 사용하여 여러 개의 동일한 Pod를 배치하고, 자동으로 Pod의 상태를 관리합니다.

Pod 생성: 쿠버네티스는 kubectl 명령어를 사용해 Pod을 생성할 수 있습니다.위 명령어는 my-image 이미지를 기반으로 my-pod라는 이름의 Pod을 생성합니다.

kubectl run my-pod --image=my-image
Pod 관리: Pod의 상태를 확인하거나 삭제할 수도 있습니다.

kubectl get pods # Pod 상태 확인 kubectl delete pod my-pod # Pod 삭제

Pod이 중요한 이유

Pod는 애플리케이션을 실행하는 가장 작은 단위이기 때문에, 쿠버네티스의 핵심이라고 할 수 있습니다. 그럼에도 불구하고 Pod 자체는 독립적으로 실행되지 않으며, 쿠버네티스의 다양한 리소스들과 협력하여 애플리케이션을 효율적이고 안정적으로 운영할 수 있습니다.

확장성: 여러 Pod을 만들어서 애플리케이션을 수평 확장할 수 있습니다. 예를 들어, 사용자가 많아지면 Pod를 더 추가해서 처리할 수 있습니다.
복원력: Pod이 실패하거나 장애가 발생하면, 쿠버네티스는 자동으로 새로운 Pod을 생성하여 애플리케이션을 복구합니다.

Pod과 마스터노드 워커노드

마스터 노드, 노드, 그리고 Pod이 분리된 이유는 각각의 역할과 책임을 명확히 하여 쿠버네티스의 확장성과 유지 보수성을 극대화하기 위해서입니다. 각 개념을 간단히 설명하고, 그들이 분리된 이유를 이해하기 쉽게 풀어보겠습니다.

1. 마스터 노드 (Control Plane)

역할: 클러스터의 중앙 관리 시스템입니다.
책임:
- 클러스터 상태 관리: 클러스터가 어떻게 작동하는지 정의합니다.
- 스케줄링: Pod이 어떤 노드에서 실행될지 결정합니다.
- 컨트롤러 관리: Pod의 상태를 모니터링하고, 필요 시 재시작하거나 복원합니다.
- API 서버 제공: 사용자가 kubectl 명령어를 통해 클러스터와 상호작용할 수 있도록 합니다.

마스터 노드는 노드나 Pod을 관리하는 역할을 하며, 애플리케이션 실행을 담당하지 않습니다. 마스터 노드가 없다면, 클러스터를 관리할 방법이 없어지므로 클러스터가 제대로 작동하지 않게 됩니다.

2. 워커 노드 (Worker Node)

역할: 실제로 Pod를 실행하는 서버입니다.
책임:
- 각 Pod가 실행되는 환경을 제공합니다.
- Kubelet: Pod을 관리하고, 클러스터의 상태를 마스터 노드에 보고합니다.
- 컨테이너 실행: Pod 내의 컨테이너를 실행합니다.
- 자원 관리: CPU, 메모리, 네트워크 등을 관리하여 Pod이 실행되는 데 필요한 자원을 제공합니다.

워커 노드가 없으면 애플리케이션을 실행할 수 없고, 쿠버네티스가 제공하는 배포, 확장, 장애 복구 등의 기능을 사용할 수 없습니다. 즉, 애플리케이션을 실행하는 노드는 반드시 필요합니다.

3. Pod

역할: 애플리케이션의 실행 단위입니다. 하나 이상의 컨테이너를 포함할 수 있으며, 같은 네트워크 및 저장소를 공유합니다.
책임:
- 컨테이너 관리: Pod 내의 여러 컨테이너는 같은 네트워크를 공유하고, 동일한 자원을 사용합니다.
- 애플리케이션 실행: 실제로 실행되는 애플리케이션의 환경을 제공합니다.

Pod은 하나 이상의 컨테이너를 같은 네트워크 환경에서 묶어 실행하기 위한 기본 단위입니다. Pod이 없으면 실제 애플리케이션을 실행할 수 없기 때문에, Pod이 반드시 필요합니다.

결론

쿠버네티스에서 Pod는 애플리케이션을 실행하는 가장 작은 단위이자, 여러 개의 컨테이너가 하나로 묶여 있는 그릇입니다. Pod 안의 컨테이너들은 네트워크와 스토리지를 공유하며 협력하여 애플리케이션을 실행합니다. 이는 마치 하나의 집에 여러 사람이 함께 살고 협력하는 구조와 비슷합니다. 쿠버네티스에서 Pod은 중요한 단위로, 애플리케이션을 관리하고 운영하는 데 핵심적인 역할을 합니다.

쿠버네티스 아키텍처 마스터 & 워커 노드 관리방식

hmk run dev — Sun, 2 Feb 2025 21:21:19 +0900

쿠버네티스 아키텍처: 마스터 노드와 워커 노드 관리 방식

쿠버네티스(Kubernetes)는 애플리케이션을 자동으로 관리하고 조정하는 시스템입니다. 큰 기업에서 수백, 수천 대의 서버를 관리할 때, 사람 손으로 하나하나 모든 것을 조정하는 것은 매우 어려운 일이죠. 그래서 쿠버네티스가 등장하여, 여러 서버를 효율적으로 관리하고 애플리케이션을 원활하게 실행할 수 있도록 도와줍니다.

여기서 중요한 역할을 하는 두 가지가 마스터 노드(Master Node)와 워커 노드(Worker Node)입니다. 이를 쉽게 이해할 수 있도록, 마치 회사의 부서와 비슷한 구조로 설명해 보겠습니다.

마스터 노드(Master Node): 회사의 관리자

마스터 노드는 쿠버네티스의 중앙 관리 시스템입니다. 마치 회사에서 모든 일을 결정하는 관리자와 같은 역할을 합니다. 회사의 모든 부서에서 일어나는 일을 감독하고, 각 부서에 적절한 일을 할당하는 사람이죠.

마스터 노드의 역할

API Server (kube-apiserver): 마스터 노드는 회사의 관리자가 다양한 부서와 소통하는 창구와 같습니다. 예를 들어, 회사의 직원들이 요청을 하면, 관리자(API Server)가 이를 받아 적절히 처리합니다.
Scheduler (kube-scheduler): 마스터 노드의 스케줄러는 각 부서에 일을 할당하는 역할을 합니다. 예를 들어, 오늘 중요한 프로젝트가 있다면, "이 일을 누구에게 맡길지?"를 결정하는 사람이 바로 스케줄러입니다. 마스터 노드는 어떤 일을 할지, 그 일을 누가 할지 결정합니다.
Controller Manager (kube-controller-manager): 마스터 노드는 회사의 상태를 모니터링하고, 필요한 변화를 일으킵니다. 예를 들어, 부서에 사람이 부족하면 이를 채워주는 역할을 합니다.
etcd: 마스터 노드는 회사의 중요한 기록을 보관합니다. 모든 회의록, 회의에서 나온 결정을 보관하는 서류철 같은 역할을 합니다. 그래서 언제든지 이 정보를 참고할 수 있게 되죠.

즉, 마스터 노드는 회사에서 모든 일의 방향을 결정하고, 각 부서(워커 노드)가 해야 할 일을 배치하는 역할을 합니다.

워커 노드(Worker Node): 회사의 실무자들

워커 노드는 회사의 실제 업무를 수행하는 부서들입니다. 마스터 노드에서 결정된 일들을 실제로 실행하는 곳이 바로 워커 노드죠. 예를 들어, 마케팅 부서나 개발 부서처럼 직접 일을 하는 실무자들입니다.

워커 노드의 역할

Kubelet: 워커 노드는 마치 부서의 팀장 같은 존재입니다. 팀장은 마스터 노드에서 주어진 업무를 각 팀원에게 분배하고, 업무가 잘 진행되는지 점검합니다.
Kube Proxy: 부서 내에서 협업을 원활하게 해주는 시스템입니다. 예를 들어, 마케팅 부서와 개발 부서가 함께 일을 할 때, 각 부서 간에 어떻게 일을 나누고 조율할지 책임지는 역할입니다.
컨테이너 런타임: 워커 노드는 실제 업무를 처리하는 장비처럼, 업무를 실제로 처리하는 시스템입니다. 예를 들어, 컴퓨터나 전화, 소프트웨어 등이 이에 해당합니다. 이 시스템이 실제로 실행되는 곳이 바로 워커 노드입니다.

즉, 워커 노드는 마스터 노드가 주는 지시를 받고, 실제로 애플리케이션을 실행하고 결과를 만들어내는 작업자들입니다.

마스터 노드와 워커 노드의 협력

이제 마스터 노드와 워커 노드가 어떻게 협력하는지 예를 들어 보겠습니다. 상상해 보세요, 마스터 노드는 회사의 관리자이고, 워커 노드는 각 부서의 실무자들입니다.

파드 배치: 마스터 노드(관리자)가 새로운 업무를 할당합니다. 예를 들어, "마케팅 부서에 광고 캠페인을 맡겨라"고 지시하면, 마케팅 부서(워커 노드)는 이를 실행합니다.
상태 관리: 마스터 노드는 각 부서가 제대로 일을 하고 있는지 모니터링합니다. 예를 들어, "마케팅 부서에서 광고 캠페인을 시작했다. 그런데 문제가 발생했을 때 어떻게 대처할지?"를 관리합니다. 만약 부서에서 일이 잘 안 되면, 마스터 노드는 수정할 방법을 제시하고 이를 해결하려 합니다.
실행과 조정: 마스터 노드는 일을 계획하고, 워커 노드는 그 계획을 실행합니다. 만약 마케팅 부서에 사람이 부족하면, 마스터 노드는 그 문제를 해결할 방법을 제시합니다. 각 부서는 마스터 노드의 지시에 맞춰서 업무를 수행합니다.

고가용성(High Availability): 두 가지가 함께 있어야 안정적

쿠버네티스에서는 마스터 노드와 워커 노드가 함께 있을 때 안정적인 시스템을 운영할 수 있습니다.

마스터 노드가 하나만 있으면 문제가 생길 수 있기 때문에, 여러 대의 마스터 노드를 두어 **고가용성(HA)**을 보장할 수 있습니다. 만약 하나의 마스터 노드가 실패해도, 다른 마스터 노드가 계속 클러스터를 관리할 수 있습니다.
워커 노드도 여러 대로 분산시켜서, 한 대의 워커 노드가 문제가 생기면 다른 워커 노드가 대신 업무를 처리할 수 있도록 합니다. 이렇게 여러 대의 노드를 통해 부하 분산을 할 수 있습니다.

결론

쿠버네티스에서 마스터 노드는 회사 관리자처럼 클러스터의 상태를 관리하고 조정하며, 워커 노드는 실무자처럼 실제 업무를 실행하는 역할을 합니다. 이 두 시스템이 협력하여 애플리케이션을 원활하게 실행하고 클러스터를 효율적으로 관리합니다.

이해가 되셨나요? 쿠버네티스는 큰 회사의 효율적인 관리를 돕는 시스템처럼, 여러 대의 서버와 애플리케이션을 잘 관리하고 조정하는 데 필요한 핵심 요소들이 바로 마스터 노드와 워커 노드입니다.

컨테이너와 오케스트레이션 쉽게 이해하기

hmk run dev — Sun, 2 Feb 2025 19:05:57 +0900

컨테이너와 오케스트레이션: 쉽게 이해하기

1. 컨테이너란 무엇인가?

컨테이너를 도시락에 비유하면?

컨테이너는 애플리케이션을 실행하는 가벼운 가상화 기술이다. 쉽게 말해 "애플리케이션을 실행할 수 있는 도시락" 같은 개념이다.

도시락(컨테이너) 안에는 음식(애플리케이션)과 필수 도구(라이브러리, 종속성 등)가 함께 들어 있다.
도시락을 어디서든 꺼내면 똑같은 환경에서 바로 먹을 수 있다.
컨테이너도 마찬가지로, 어떤 서버에서 실행하든 동일한 환경을 유지한다.

기존 방식과의 차이점

구분전통적인 VM(가상 머신)컨테이너

실행 속도	무겁고 느림	가볍고 빠름
리소스 사용	OS별로 많은 리소스 필요	최소한의 리소스 사용
이식성	환경마다 설정이 다름	어디서든 같은 환경 유지

대표적인 컨테이너 기술

Docker: 가장 많이 사용되는 컨테이너 플랫폼
Podman: Docker와 유사하지만, 데몬 없이 작동
Containerd: 쿠버네티스에서 사용하는 컨테이너 런타임

2. 컨테이너 오케스트레이션이 필요한 이유

컨테이너 한 개만 쓰면 괜찮은데, 여러 개가 되면?

컨테이너 하나만 실행하면 문제가 없지만, 수십 개, 수백 개의 컨테이너를 관리해야 한다면?

예를 들어 햄버거 가게를 운영한다고 생각해 보자.

가게를 처음 열었을 때는 직원 1~2명이 모든 주문을 처리할 수 있다.
하지만 주문이 폭주하면 직원이 더 필요하고, 주문을 자동으로 분배하는 시스템이 필요하다.
컨테이너 환경에서도 여러 개의 컨테이너를 효과적으로 배치하고 관리하는 시스템이 필요하다.

오케스트레이션의 필요성

컨테이너를 자동으로 배포하고 관리할 수 있어야 한다.
컨테이너가 죽으면 자동으로 재시작해야 한다.
트래픽이 많아지면 컨테이너를 자동으로 늘려야 한다.
여러 서버에서 컨테이너를 실행하려면 중앙에서 관리해야 한다.

이 역할을 하는 것이 바로 "컨테이너 오케스트레이션 시스템"이다.

3. 컨테이너 오케스트레이션이란?

컨테이너 오케스트레이션은 여러 개의 컨테이너를 자동으로 배포, 관리, 확장하는 시스템이다.

대표적인 오케스트레이션 도구

Kubernetes(쿠버네티스) - 가장 많이 사용되는 오케스트레이션 툴
Docker Swarm - Docker에 내장된 오케스트레이션 기능
Amazon ECS - AWS에서 제공하는 컨테이너 관리 서비스

4. 컨테이너 오케스트레이션이 해결하는 문제

쿠버네티스를 쓰면 좋은 점

자동 배포 및 롤백 기능 제공
장애 발생 시 컨테이너를 자동으로 재시작하는 복구 기능 지원
트래픽 증가에 따라 컨테이너를 자동으로 추가하는 오토스케일링 기능
여러 개의 컨테이너에 요청을 자동으로 분배하는 로드 밸런싱 기능

5. 쿠버네티스

컨테이너는 애플리케이션을 어디서든 동일한 환경에서 실행할 수 있도록 돕는 기술이다. 하지만 컨테이너가 많아지면 관리가 어려워지고, 이를 해결하기 위해 컨테이너 오케스트레이션 시스템이 필요하다.

즉, 컨테이너는 도시락과 같고, 오케스트레이션 시스템은 햄버거 가게를 원활하게 운영하는 자동화 시스템이라고 볼 수 있다.

그리고 그 역할을 하는 대표적인 시스템이 바로 쿠버네티스(Kubernetes)다.

VM과 비교한 도커의 단점

보안 이슈: 도커는 호스트 OS의 커널을 공유하므로, VM처럼 격리된 환경을 제공하지 않아요. 이는 비교적 보안적으로 취약할 수 있어요.
OS 종속성: 도커는 호스트 OS의 커널을 사용하는데, 이로 인해 일부 OS에선 제한적일 수 있어요. 예를 들어, 리눅스 기반 도커는 윈도우에서 완전히 동일하게 동작하지 않을 수 있어요.
복잡한 네트워크 관리: 도커 네트워크는 VM에 비해 설정이 복잡할 수 있고, 여러 컨테이너가 서로 통신할 때 복잡도가 올라갈 수 있어요.
파일 시스템 성능: 도커의 파일 시스템은 VM에 비해 느릴 수 있어요, 특히 많은 파일을 읽고 쓸 때 성능 저하가 있을 수 있어요.

LangChain으로 AI 애플리케이션

hmk run dev — Sat, 1 Feb 2025 11:36:06 +0900

최근 대형 언어 모델(LLM, Large Language Model)의 발전으로 AI를 활용한 애플리케이션 개발이 활발해지고 있습니다. 하지만 단순히 OpenAI API를 호출하는 것만으로는 복잡한 애플리케이션을 만들기 어렵죠.

LangChain은 이런 문제를 해결하기 위해 만들어진 프레임워크로, 언어 모델을 다양한 데이터와 연결하고, 에이전트를 통해 복잡한 작업을 수행할 수 있도록 도와줍니다. 이번 글에서는 LangChain의 주요 개념과 아키텍처, 그리고 Python 코드 예제를 소개하겠습니다.

1️⃣ LangChain이란?

LangChain은 대형 언어 모델을 활용한 AI 애플리케이션을 쉽게 개발할 수 있도록 지원하는 프레임워크입니다.
단순한 텍스트 생성뿐만 아니라 문서 검색, API 호출, 데이터 분석 등 다양한 작업을 수행할 수 있도록 설계되어 있습니다.

✅ LangChain의 핵심 개념

LLM (Large Language Model) → OpenAI, Hugging Face 등 다양한 언어 모델을 쉽게 연결
Prompt Templates → 입력 프롬프트를 템플릿화하여 관리
Memory → 대화 내역을 저장하여 컨텍스트 유지
Agents → 여러 도구(tool)를 조합해 복잡한 작업 수행
Chains → 여러 단계를 거치는 작업을 연결

2️⃣ LangChain 기초: LLM 사용하기

LangChain을 이용해 간단한 텍스트 생성기를 만들어보겠습니다.
아래 코드는 OpenAI의 gpt-3.5-turbo 모델을 사용합니다.

from langchain.llms import OpenAI

# OpenAI 모델 사용
llm = OpenAI(model_name="gpt-3.5-turbo", openai_api_key="your_api_key")

# 텍스트 생성 실행
response = llm("LangChain이 무엇인가요?")
print(response)

이렇게 LangChain을 이용하면 간단한 코드로 LLM을 활용할 수 있습니다

3️⃣ LangChain의 핵심 아키텍처

LangChain은 단순한 LLM 호출을 넘어서, 복잡한 AI 애플리케이션을 구성할 수 있는 구조를 제공합니다.

1. 체인 (Chain)

체인은 여러 단계를 연결하는 구조입니다. 예를 들어, 질문을 받고 → 검색 → 요약하는 프로세스를 하나의 체인으로 구성할 수 있습니다.

from langchain.chains import LLMChain
from langchain.prompts import PromptTemplate

# 프롬프트 템플릿 생성
template = PromptTemplate.from_template("한국의 수도는 어디인가요? {question}")

# LLM 체인 생성
chain = LLMChain(llm=llm, prompt=template)

# 실행
response = chain.run("서울인가요?")
print(response)

2. 에이전트 (Agent)

에이전트는 LLM이 여러 도구(tool)를 활용하여 스스로 의사 결정을 하며 문제를 해결하는 구조입니다.
예를 들어, LLM이 계산이 필요하면 계산기 API를 호출하고, 검색이 필요하면 웹 검색을 수행하도록 만들 수 있습니다.

from langchain.agents import initialize_agent, AgentType
from langchain.agents.tools import Tool
from langchain.llms import OpenAI

# 사용할 도구 (예: 간단한 계산기)
def calculator(expression):
    return eval(expression)

calc_tool = Tool(
    name="Calculator",
    func=calculator,
    description="수학 계산을 수행하는 도구"
)

# 에이전트 생성
agent = initialize_agent(
    tools=[calc_tool],
    llm=OpenAI(model_name="gpt-3.5-turbo", openai_api_key="your_api_key"),
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True
)

# 실행
agent.run("10 + 25는 얼마야?")

위 코드에서는 AI가 calculator 함수를 직접 사용하여 계산을 수행합니다.
즉, LLM이 직접 계산하는 것이 아니라, 필요한 작업을 적절한 도구에 위임하는 방식입니다.

4️⃣ 실전 예제: 웹 검색을 활용한 Q&A 시스템

LangChain의 에이전트를 활용하면 실시간 정보 검색 기능을 추가할 수 있습니다.
아래 코드는 SerpAPI를 사용하여 웹에서 정보를 검색한 후 답변하는 구조를 보여줍니다.

from langchain.agents import initialize_agent, AgentType
from langchain.tools import SerpAPIWrapper
from langchain.llms import OpenAI

# 웹 검색 도구
search = SerpAPIWrapper(serpapi_api_key="your_serpapi_key")

# 에이전트 생성
agent = initialize_agent(
    tools=[search],
    llm=OpenAI(model_name="gpt-3.5-turbo", openai_api_key="your_api_key"),
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True
)

# 실행
agent.run("오늘 서울 날씨 어때?")

이제 LangChain을 이용해 LLM이 웹 검색을 수행하고 최신 정보를 반영하여 응답할 수 있습니다.

5️⃣ LangChain의 활용 사례

LangChain을 사용하면 다양한 AI 애플리케이션을 개발할 수 있습니다.

✅ 챗봇 개발 → 사용자의 질문에 답하는 대화형 AI
✅ 문서 요약 및 분석 → 긴 문서를 요약하고 주요 내용을 추출
✅ 자동화된 연구 도구 → 웹 검색과 요약을 통해 연구 보조
✅ AI 기반 데이터 분석 → AI가 데이터를 해석하고 인사이트 도출

결론

LangChain은 LLM을 활용한 강력한 AI 애플리케이션을 쉽게 개발할 수 있도록 도와주는 프레임워크입니다.
특히 체인(Chain), 에이전트(Agent) 같은 구조를 활용하면 복잡한 문제도 효과적으로 해결할 수 있습니다.

즉, 단순한 텍스트 생성이 아니라, 검색·계산·API 호출 등의 외부 도구와 결합하여 보다 정교한 AI 애플리케이션을 구축하는 것이 핵심인 프레임워크라고 볼 수 있겠습니다.

레거시를 만들지 않기 위한 습관

hmk run dev — Sun, 15 Dec 2024 20:45:07 +0900

"비즈니스는 속도가 생명이다." 초기 단계에서는 빠른 제품 출시와 시장 적응을 위해 효율성보다 결과를 우선시하기 쉽다. 이는 자연스럽게 기술 부채를 남기고, '레거시 코드'라 불리는 코드 뭉치나 비효율적인 아키텍처로 이어진다.

하지만, 레거시는 단순히 부정적인 요소가 아니다. 오히려 현재의 비즈니스를 지탱하는 '기반'이자 과거의 성과를 보여주는 흔적이기도 하다.

"우리는 이 레거시 덕분에 지금까지 성장할 수 있었다." 라는 생각도 가능하다.

레거시란 무엇인가?

레거시는 단순히 "오래된 코드"를 의미하지 않는다. 본질적으로 유지보수가 어렵고, 팀의 생산성을 저하시키는 시스템을 뜻한다. 이는 코드의 나이가 아니라 구조적 문제, 복잡성, 문서화 부족, 또는 기술 부채로 인해 발생하는 결과이다.

또 다른 관점에서, 어떤 이들은 코드는 배포된 순간부터 이미 레거시라고 말한다. 이는 코드가 시간이 지남에 따라 필연적으로 변화하는 요구사항, 새로운 기술 트렌드, 그리고 운영 환경에 적응해야 한다는 점에서 나온 의견이다.
이런 변화 속에서 코드가 유지보수 가능성을 잃거나, 확장성을 고려하지 않은 상태로 남을 때, "레거시"라는 꼬리표가 붙게 된다.

아마 개발자라면 커리어 내내 맞닥뜨리게 될 딜레마가 있습니다. 바로, "확장성을 우선시할 것인가, 아니면 현재 필요성에 집중할 것인가" 하는 선택입니다.

레거시를 만드는 개발습관엔 어떤 것들이 있을까?

레거시는 단순히 오래된 코드에서 비롯되는 것이 아니라, 개발 습관에서 시작되기도 합니다. 다음은 레거시를 만드는 대표적인 개발 습관들입니다:

단기적인 해결책(핫픽스)에 의존하는 개발
긴급한 문제 해결에만 집중하다 보면, 장기적으로 유지보수하기 어려운 코드가 쌓이게 됩니다.
불명확한 코드 구조와 네이밍
가독성과 일관성이 떨어지는 코드와 애매한 네이밍은 팀원 간 의사소통을 어렵게 만듭니다.
테스트와 자동화 부족
테스트가 없으면 코드 변경 시 안정성을 보장하기 어렵고, 자동화가 없으면 반복적인 작업이 증가합니다.
"일단 동작하면 됐다"는 태도
현재 문제를 해결하는 데만 집중하고, 코드의 확장성이나 품질을 간과하는 경우가 많습니다.

이와 같은 습관들은 초기에는 큰 문제가 되지 않을 수 있지만, 시간이 지나면서 점점 더 커다란 기술 부채를 쌓게 되어, 결국 조직의 생산성을 저하시키는 레거시로 이어질 수 있습니다.

물론 필자는 초기 스타트업에서 근무중인 개발자로써 빠른 비즈니스 속도에 맞춰 개발하다보면 위의 것들이 잘 지켜지지 않는 경우도 꽤 있다. 따라서, 비즈니스 요구와 코드 품질 사이의 균형을 찾는 것이 중요하다고 생각이든다.

레거시를 만들지 않기 위한 좋은 습관

1. 명확하고 일관된 코드 작성

의도를 드러내는 네이밍: 변수, 함수, 클래스의 이름이 그 역할과 목적을 명확히 드러내야 합니다.
- ❌ temp1, doStuff()
- ✅ userId, fetchUserData()
일관된 코드 스타일: 프로젝트 내에서 통일된 코딩 규칙(예: Prettier, ESLint)을 적용해 가독성을 유지합니다.

명확한 타입과 변수 네이밍

// 나쁜 예
const t1 = (a: any, b: any): any => a * b;

// 좋은 예
const calculateTotalPrice = (price: number, quantity: number): number => price * quantity;

명확한 인터페이스 정의

// 나쁜 예: 암시적으로 객체 사용
const createUser = (user: any) => {
  console.log(user.name);
};

// 좋은 예: 명시적으로 인터페이스 사용
interface User {
  name: string;
  email: string;
}

const createUser = (user: User): void => {
  console.log(user.name);
};

팀과 합의된 Eslint 규칙

//@deprecated 주석된 변수나 함수에 경고
'deprecation/deprecation': 'warn',

//특정 키워드로 시작하는 주석에 경고
'no-warning-comments': [
  'warn',
  {
    terms: ['TODO', 'FIXME', 'TECH-DEBT', 'REFACTOR'],
    location: 'start',
  },
],
// 함수 중첩 깊이 제한
'max-depth': ['warn', 3],
// 함수 인자 개수 제한
'max-params': ['warn', 3],
// 중첩 콜백 제한
'max-nested-callbacks': ['warn', 3],
// 중첩된 삼항 연산자 방지
'no-nested-ternary': 'error',

2. 적절한 문서화와 주석 작성

코드 자체로 이해하기 어려운 부분은 간결한 주석을 남겨 미래의 개발자(혹은 본인) 가 쉽게 이해할 수 있도록 돕습니다.
시스템 아키텍처, 주요 로직의 흐름은 간단한 문서화로 기록해 두는 것이 좋습니다.

// 나쁜 예: 주석이 부족하거나 의도를 설명하지 않음
function calculate(a: number, b: number): number {
  return a + b; // 더하기
}

// 좋은 예: 함수의 목적과 파라미터를 명확히 문서화
/**
 * 두 숫자의 합계를 계산하는 함수
 * @param a - 첫 번째 숫자
 * @param b - 두 번째 숫자
 * @returns 합계
 */
function calculateSum(a: number, b: number): number {
  return a + b;
}

3. 테스트 주도 개발(TDD) 또는 테스트 우선 문화

자동화된 테스트 작성: 단위 테스트, 통합 테스트, E2E 테스트를 통해 코드 변경 시 안정성을 보장합니다.
테스트 커버리지 확인: 100% 커버리지가 목표는 아니지만, 주요 로직은 반드시 테스트를 작성합니다.
- 코드품질 보장, 안정적인 코드 변경지원, 문서화 역할, 코드 설계 개선 등등의 이점도 챙길 수 있다.
코드 수정 시 테스트 결과를 통해 빠르게 문제를 발견하고 해결할 수 있습니다.

// 테스트 작성
describe("calculateTotalPrice", () => {
  it("should return the correct total price", () => {
    expect(calculateTotalPrice(100, 2)).toBe(200);
  });
});

// 코드 구현
const calculateTotalPrice = (price: number, quantity: number): number => price * quantity;

4. 점진적 리팩토링 습관화

기존 코드를 수정하거나 기능을 추가할 때, 작은 단위로 개선하는 리팩토링을 병행합니다.
기술 부채를 발견하면 무조건 미루기보다는 작은 빚부터 갚는 습관을 기릅니다.
- 예: 함수 분리, 반복되는 코드 제거, 오래된 의존성 업데이트 등.

// 리팩토링 전: 중복된 코드
function sendEmailToAdmin(user: { email: string }): string {
  const email = user.email;
  if (!email) return "Email not found";
  // 이메일 전송 로직
  return "Admin email sent";
}

function sendEmailToCustomer(user: { email: string }): string {
  const email = user.email;
  if (!email) return "Email not found";
  // 이메일 전송 로직
  return "Customer email sent";
}

// 리팩토링 후: 공통 로직 분리
function sendEmail(user: { email: string }, role: "Admin" | "Customer"): string {
  const email = user.email;
  if (!email) return "Email not found";
  // 이메일 전송 로직
  return `${role} email sent`;
}

5. 적절한 확장성과 단순성의 균형 유지

현재 필요한 기능에 집중하되, 확장 가능성을 염두에 둡니다.
- 예: YAGNI(You Aren't Gonna Need It) 원칙을 따르면서도, 인터페이스 설계나 모듈화를 통해 유연성을 확보합니다.
복잡한 아키텍처보다 KISS(Keep It Simple, Stupid) 원칙을 따라 단순한 설계를 우선합니다.

https://velog.io/@wngud4950/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-3%EB%8C%80-%EC%9B%90%EC%B9%99-KISS-YAGNI-DRY

소프트웨어 개발 3대 원칙 (KISS, YAGNI, DRY)

소프트웨어를 알흠답고 잘 짜기 위한KISS(키쓰!) YAGNI(야근!!) DRY(드롸이!!)를 알아보자아직까지 별 거 없는 실력이지만 프로젝트를 한 두어개 해보다보니까 구현 이후 깔끔한 코드를 어떻게 짜는

velog.io

// 나쁜 예: 지나치게 복잡한 설계
function calculatePrice(price: number, tax: number, discount?: number, additionalFees?: number): number {
  return price + tax - (discount || 0) + (additionalFees || 0);
}

// 좋은 예: 현재 요구사항에 맞는 단순한 설계
function calculatePrice(price: number, tax: number): number {
  return price + tax;
}

6. 도메인 지식 공유

팀 내에서 도메인 지식을 공유하여 특정 개인에게 종속되지 않는 코드를 작성합니다.
지식이 공유될수록 코드 의도를 이해하고 유지보수하기 쉬워집니다.

팀 내 기술 공유 세션:

"지난주에 작업한 '상품 추천 알고리즘'은 사용자 행동 데이터를 기반으로 추천을 제공하는 로직입니다. 이를 통해 개인화 추천의 정확도를 15% 개선할 수 있었습니다."

코드 베이스 이해를 돕는 문서화

/**
 * 사용자 추천 알고리즘
 * @param userId - 추천할 사용자 ID
 * @returns 추천 상품 배열
 */
function recommendProducts(userId: string): string[] {
  // 추천 알고리즘 로직
  return ["Product1", "Product2"];
}

7. 리팩토링 효율성 파악하기

git 명령어를 통해 수정이 빈번한 파일 정렬해서 출력하기

git log --name-only --pretty=format: |
sed -e 's|^pages/|^apps/mercedes/pages/|g' -e 's|^src/|^apps/mercedes/src/|g' |
grep -E '^(apps/mercedes/src|apps/mercedes/pages)' |
awk 'NR==FNR{a[$0];next} $0 in a' <(git ls-files) - |
sort | uniq -c | sort -nr


# --since="3 months ago"
git log --name-only --since="30 days ago" --pretty=format: |
sed -e 's|^pages/|^apps/mercedes/pages/|g' -e 's|^src/|^apps/mercedes/src/|g' |
grep -E '^(apps/mercedes/src|apps/mercedes/pages)' |
awk 'NR==FNR{a[$0];next} $0 in a' <(git ls-files) - |
sort | uniq -c | sort -nr

출력결과

687 apps/mercedes/src/service/ABTestingPolicyService.ts
322 apps/mercedes/pages/index.tsx
306 apps/mercedes/src/component/HomePage/index.tsx
301 apps/mercedes/pages/plans/[id].tsx
262 apps/mercedes/pages/plans/index.tsx
233 apps/mercedes/src/log/types/logNavigationTypes.ts
210 apps/mercedes/pages/_app.tsx
189 apps/mercedes/src/component/PlanDetailPage/SignUpInfoSection/index.tsx
165 apps/mercedes/src/component/MyOrderDetailPage/index.tsx
149 apps/mercedes/src/entity/plan.ts
113 apps/mercedes/src/component/TipsDetailPage/index.tsx
113 apps/mercedes/src/common/constants.ts
104 apps/mercedes/src/common/web-util.ts
100 apps/mercedes/src/component/StockAlarmPage/index.tsx
94 apps/mercedes/src/shared/components/surfaces/Card/PlanCard/PlanCard.tsx
86 apps/mercedes/src/component/PhoneContentsPage/index.tsx
83 apps/mercedes/src/component/ShorterPlanDetail/index.tsx
80 apps/mercedes/src/component/MyPagePageV2/BottomListSection.tsx
80 apps/mercedes/src/api/planOrder/planOrderLg.ts
78 apps/mercedes/pages/event.tsx
75 apps/mercedes/src/entity/api.ts
75 apps/mercedes/pages/tips/detail/[id].tsx
70 apps/mercedes/src/entity/mvnos.ts
70 apps/mercedes/src/component/InternetsPage/index.tsx
70 apps/mercedes/pages/calculator/plans-by-data/start.tsx
66 apps/mercedes/src/modules/MvnoCardList/MvnoCardList.module.scss
66 apps/mercedes/src/component/MyOrdersPage/OrderProgressFaqSection.tsx
66 apps/mercedes/src/common/http-util.ts
66 apps/mercedes/pages/tips.tsx
65 apps/mercedes/src/component/ReferralCodePage/indexV2.tsx
64 apps/mercedes/src/component/PlanDetailPage/PlanInfoSection/PlanInfoSection.module.scss
64 apps/mercedes/src/api/plan.ts
63 apps/mercedes/src/modules/Header/Header.tsx
63 apps/mercedes/src/component/PlanBridgePage/index.tsx
61 apps/mercedes/src/log/types/logObjectTypes.ts
59 apps/mercedes/src/component/InternetRequestPage/index.tsx
59 apps/mercedes/pages/referral/register.tsx
58 apps/mercedes/pages/login/kakao/index.tsx
57 apps/mercedes/src/modules/plans/layouts/PlanSearchFilters/PlanSearchFilters.tsx
57 apps/mercedes/src/entity/order/order.ts
57 apps/mercedes/pages/mypage/index.tsx
56 apps/mercedes/src/modules/BannerSlider/index.tsx
54 apps/mercedes/pages/community/questions/[...params].tsx
51 apps/mercedes/src/common/mvno-util.ts
51 apps/mercedes/pages/internets/index.tsx
50 apps/mercedes/src/modules/EventList/index.tsx
50 apps/mercedes/src/component/MyOrdersPage/OrderProgressSection.tsx
50 apps/mercedes/src/component/AffiliatePage/resultV3.tsx
50 apps/mercedes/pages/_document.tsx
49 apps/mercedes/src/component/PhoneContentsPage/phone-contents.ts
49 apps/mercedes/src/component/MvnoDetailPage/index.tsx
49 apps/mercedes/src/component/LoginPage/index.tsx
49 apps/mercedes/pages/_error.tsx
48 apps/mercedes/src/shared/utils/sendBehaviorLogScheduler.ts
48 apps/mercedes/src/component/TipsDetailPage/generate.tsx
48 apps/mercedes/src/component/PlanOrderPageV2/PlanOrderSerializer.ts
48 apps/mercedes/src/component/MyOrderDetailPage/ActivationRequestPage.tsx

C++ 과 javascript

hmk run dev — Sun, 20 Oct 2024 22:00:23 +0900

프론트엔드 개발자가 C++를 알면 여러 측면에서 이점을 가질 수 있습니다. C++는 성능과 시스템 수준의 프로그래밍에 강점을 가지고 있어, 프론트엔드 개발에 직접적으로 사용되지는 않지만 다음과 같은 간접적인 이점이 있습니다:

C++를 자바스크립트와 비교하여 기초부터 배우고 싶다면, 두 언어의 주요 차이점과 개념을 중심으로 설명해 보겠습니다. C++는 컴파일러 언어이고, 자바스크립트는 인터프리터 언어라는 근본적인 차이가 있으며, 이에 따라 메모리 관리, 데이터 타입, 흐름 제어 등 다양한 측면에서 차이가 있습니다.

성능 최적화에 대한 깊은 이해: C++는 메모리 관리와 성능 최적화에 매우 민감한 언어입니다. 이를 통해 자바스크립트 엔진의 동작 원리나 브라우저 내부의 성능 최적화 과정에 대한 더 깊은 이해를 할 수 있습니다. V8 같은 자바스크립트 엔진은 C++로 구현되어 있기 때문에, C++를 알면 이러한 엔진의 내부 작동을 더 잘 이해하고 성능 문제를 효율적으로 해결할 수 있습니다.
WebAssembly와 연계: WebAssembly는 브라우저에서 C++ 같은 고성능 언어를 실행할 수 있는 기술입니다. C++를 알면 WebAssembly로 고성능 애플리케이션을 개발하거나 성능이 중요한 부분을 최적화하는 데 유리합니다. 프론트엔드 개발에서 성능이 중요한 애플리케이션(예: 게임, 영상 처리 등)을 만들 때 C++와 WebAssembly는 강력한 조합이 될 수 있습니다.
데이터 구조와 알고리즘의 깊은 이해: C++를 공부하면서 메모리 관리, 효율적인 데이터 구조, 고급 알고리즘에 대한 깊은 이해를 얻게 됩니다. 이는 프론트엔드 개발에서도 복잡한 애플리케이션을 설계할 때 중요한 자산이 될 수 있습니다. 특히 대규모 상태 관리나 성능 최적화에서 도움이 됩니다.
다양한 도구 개발: C++는 고성능 도구나 라이브러리 개발에 자주 사용됩니다. 프론트엔드 개발에 필요한 맞춤형 빌드 툴이나 성능을 극대화한 라이브러리를 직접 개발할 수 있습니다. 이런 도구는 개발 효율성을 크게 높일 수 있습니다.
브라우저 확장 및 통합: 브라우저의 확장 기능이나 플러그인을 만들 때, C++ 같은 언어로 작성된 네이티브 모듈을 사용하여 복잡한 연산을 처리하거나 시스템 수준의 기능과 상호작용할 수 있습니다. 프론트엔드와 백엔드, 그리고 시스템 프로그래밍을 통합하는 데 유용합니다.
저수준 프로그래밍 경험: C++는 자바스크립트보다 훨씬 저수준의 프로그래밍 언어입니다. 이 경험은 자바스크립트 같은 고수준 언어에서 발생하는 문제들을 더 깊이 이해하고, 최적화 포인트를 찾는 데 도움이 될 수 있습니다.

자바스크립트를 주로 사용했던 프론트엔드 개발자로써 위에 대한 공부, 의도적수련을 하기위해 javascript와 c++을 비교하는 글을 작성해보고자 합니다.

C++ vs Javascript

1. 변수 선언 및 데이터 타입

자바스크립트는 동적 타입 언어이고, C++는 정적 타입 언어입니다. 자바스크립트에서는 변수의 타입을 명시하지 않고 선언할 수 있지만, C++에서는 변수의 타입을 명시해야 합니다.

자바스크립트

let x = 10;    // 숫자
let y = "Hello";  // 문자열

C++

int x = 10;    // 정수
std::string y = "Hello";  // 문자열 (C++에서 문자열은 `std::string` 객체로 다룸)

차이점: C++에서는 변수를 선언할 때 명시적인 타입을 지정해야 합니다. 또한, 자바스크립트의 let, const처럼 변수 범위를 지정하는 키워드가 있는 반면, C++에서는 int, double, char 등의 타입을 지정합니다.

2. 메모리 관리

자바스크립트는 가비지 컬렉션(Garbage Collection)을 통해 메모리를 자동으로 관리합니다. 하지만 C++는 개발자가 직접 메모리를 할당하고 해제해야 합니다.

자바스크립트

let obj = { name: "John" };  // 메모리 할당 자동 관리

C++

int* ptr = new int;  // 메모리 동적 할당
delete ptr;          // 메모리 해제

차이점: C++에서는 new와 delete 키워드를 사용하여 직접 메모리를 할당하고 해제해야 합니다. 이 점에서 C++는 메모리 관리에 더 신경 써야 하는 반면, 자바스크립트는 이를 자동으로 처리합니다.

3. 함수 선언

자바스크립트와 C++ 모두 함수 선언 방식은 비슷하지만, C++는 함수의 반환 타입을 명시해야 합니다.

자바스크립트

function add(a, b) {
  return a + b;
}

C++

int add(int a, int b) {
    return a + b;
}

4. 조건문 및 반복문

조건문(if, else)과 반복문(for, while)의 구조는 두 언어에서 매우 비슷합니다.

자바스크립트

if (x > 10) {
  console.log("x는 10보다 큽니다.");
}

for (let i = 0; i < 5; i++) {
  console.log(i);
}

C++

if (x > 10) {
    std::cout << "x는 10보다 큽니다." << std::endl;
}

for (int i = 0; i < 5; i++) {
    std::cout << i << std::endl;
}

차이점: 기본적인 제어 흐름은 비슷하지만, C++에서는 입출력에 std::cout과 같은 표준 라이브러리 함수를 사용하며, 자바스크립트는 console.log()를 사용합니다.

5. 클래스와 객체 지향 프로그래밍

자바스크립트와 C++는 둘 다 객체 지향 프로그래밍(OOP)을 지원하지만, C++는 클래스 기반 OOP를 처음부터 설계에 반영한 반면, 자바스크립트는 프로토타입 기반 OOP를 사용하다가 클래스 문법이 추가되었습니다.

자바스크립트

class Person {
  constructor(name) {
    this.name = name;
  }
  
  greet() {
    console.log(`Hello, ${this.name}`);
  }
}

let person = new Person("Alice");
person.greet();  // Hello, Alice

C++

class Person {
public:
    std::string name;
    
    Person(std::string n) : name(n) {}
    
    void greet() {
        std::cout << "Hello, " << name << std::endl;
    }
};

Person person("Alice");
person.greet();  // Hello, Alice

차이점: C++는 클래스에서 접근 지정자(예: public, private)를 사용하여 멤버 변수와 함수를 관리합니다. 자바스크립트는 접근 지정자를 명시적으로 사용하지 않으며, 모든 멤버가 기본적으로 public입니다. 또, C++에서는 생성자 초기화 목록을 사용할 수 있습니다.

6. 포인터와 참조

C++는 포인터와 참조라는 중요한 개념을 가지고 있습니다. 자바스크립트는 이러한 저수준 개념이 없으며, 변수가 값 자체를 저장하거나 객체에 대한 참조를 자동으로 관리합니다.

자바스크립트

let obj = { name: "Alice" };
let ref = obj;  // obj에 대한 참조
ref.name = "Bob";
console.log(obj.name);  // Bob (참조로 인해 원본 객체 변경)

C++

int a = 5;
int* p = &a;  // a의 주소를 저장하는 포인터
*p = 10;      // 포인터를 통해 a의 값을 변경
std::cout << a << std::endl;  // 10

차이점: C++는 포인터를 사용하여 메모리의 주소를 다루고, 이를 통해 값의 직접적인 조작을 할 수 있습니다. 자바스크립트는 변수 자체가 참조 또는 값을 저장하는 방식으로 동작하며, 메모리 주소를 직접 다루지는 않습니다.

7. 컴파일과 실행

C++는 컴파일러 기반 언어로, 코드를 작성한 후에 컴파일 과정이 필요합니다. 반면 자바스크립트는 브라우저나 Node.js에서 바로 실행할 수 있는 인터프리터 언어입니다.

C++ 컴파일

g++ main.cpp -o main
./main

자바스크립트 실행

node script.js

차이점: C++는 컴파일 단계를 거쳐야 하기 때문에, 코드가 실행되기 전에 컴파일러가 오류를 잡아냅니다. 반면 자바스크립트는 실행할 때까지 오류가 감지되지 않는 경우가 많습니다.

C++ 와 컴퓨터 작동 원리

C++를 공부하면 컴퓨터 작동 원리, 메모리 관리, 성능 최적화에 대해 깊이 이해할 수 있는 이유는 C++가 저수준 프로그래밍 언어로서 컴퓨터 하드웨어와 가까운 방식으로 작동하기 때문입니다. 이를 통해 컴퓨터 내부에서 일어나는 일을 더 구체적으로 제어하고 이해할 수 있습니다. 구체적인 예시와 설명을 통해 그 이유를 살펴보겠습니다.

1. 메모리 관리와 포인터

C++는 개발자가 직접 메모리를 할당하고 해제할 수 있도록 하며, 이를 통해 메모리 사용의 효율성을 극대화할 수 있습니다. 이는 메모리 구조와 컴퓨터의 메모리 관리 방식을 더 깊이 이해하게 만드는 중요한 이유입니다.

예시: 동적 메모리 할당

int* ptr = new int(10); // 힙 영역에 메모리 할당
std::cout << *ptr << std::endl; // 포인터를 통해 메모리 접근

delete ptr; // 메모리 해제

C++에서 new를 사용해 메모리를 할당하면 **힙(Heap)**이라는 메모리 영역에 공간이 생깁니다. 개발자가 필요할 때 메모리를 할당하고, 더 이상 필요하지 않으면 delete로 해제하는 방식으로 메모리를 관리합니다. 이 과정을 통해 메모리 관리의 복잡성과 중요성을 이해하게 되며, 자동 메모리 관리(Garbage Collection)가 없는 환경에서는 메모리 누수(memory leak)와 같은 문제를 방지하는 방법을 배울 수 있습니다.

왜 중요한가: 자바스크립트나 다른 고수준 언어는 메모리 관리를 자동으로 처리하지만, C++에서는 개발자가 직접 제어합니다. 이를 통해 메모리가 어떻게 할당되고 해제되는지, 메모리 누수 문제가 왜 발생하는지, 최적의 메모리 관리를 위해 어떤 전략을 사용해야 하는지 알게 됩니다.

2. 포인터와 메모리 주소

C++에서 포인터는 메모리 주소를 다룹니다. 포인터는 변수나 객체가 저장된 메모리 위치를 참조하는데, 이를 통해 메모리 상의 데이터 구조가 어떻게 배치되는지를 이해할 수 있습니다.

예시: 포인터와 배열

int arr[3] = {1, 2, 3};
int* p = arr; // 배열 첫 번째 요소의 주소를 가리킴

std::cout << *(p+1) << std::endl; // 배열의 두 번째 요소 접근

이 예에서 p는 배열의 첫 번째 요소를 가리키고, 포인터 연산을 통해 배열 내의 다른 요소에 접근할 수 있습니다. 포인터를 이해하면 메모리 내에서 데이터가 어떻게 저장되고 이동되는지, 특히 다차원 배열이나 동적 데이터 구조에서 어떻게 효율적으로 접근할 수 있는지 배우게 됩니다.

왜 중요한가: 포인터는 데이터를 메모리 상에서 직접 다루는 방식을 보여주며, 이를 통해 컴퓨터 메모리의 계층 구조(스택, 힙 등)를 이해하고, 메모리 접근 성능에 대해 고민할 수 있게 합니다.

3. 캐시 및 성능 최적화

C++는 CPU의 캐시 메모리와 메인 메모리 간의 상호작용을 고려한 코드를 작성할 때 특히 유용합니다. 효율적인 코드 작성은 **캐시 미스(cache miss)**를 줄이고, 데이터 접근을 최적화하는 것을 목표로 할 수 있습니다.

예시: 배열 순회 성능 차이

const int size = 10000;
int matrix[size][size];

// 행 순서로 순회
for (int i = 0; i < size; i++) {
    for (int j = 0; j < size; j++) {
        matrix[i][j] = i + j;
    }
}

// 열 순서로 순회
for (int j = 0; j < size; j++) {
    for (int i = 0; i < size; i++) {
        matrix[i][j] = i + j;
    }
}

위 코드에서 행 순서로 순회하는 것이 열 순서로 순회하는 것보다 성능이 더 좋습니다. 그 이유는 캐시 메모리의 작동 방식 때문입니다. CPU 캐시는 메모리를 작은 블록 단위로 가져오는데, 배열을 행 순서로 순회하면 캐시가 효율적으로 동작(캐시 히트가 자주 발생)하여 성능이 향상됩니다. 열 순서로 순회하면 캐시 미스가 자주 발생하여 성능이 떨어집니다.

왜 중요한가: 배열이나 데이터 구조의 순회 방식만으로도 성능이 크게 달라질 수 있다는 것을 C++에서 배우면, 컴퓨터 하드웨어가 데이터를 어떻게 처리하는지 더 깊이 이해하게 되고, 이를 통해 성능 최적화 전략을 세울 수 있습니다.

4. 멀티스레딩과 동시성

C++는 멀티스레딩과 동시성을 지원하는 강력한 기능을 가지고 있습니다. 멀티스레딩은 CPU 자원을 효율적으로 활용하기 위한 방법 중 하나로, 이를 사용하면 병렬 처리를 통해 프로그램의 성능을 극대화할 수 있습니다.

예시: 멀티스레딩

#include <iostream>
#include <thread>

void task1() {
    std::cout << "Task 1\n";
}

void task2() {
    std::cout << "Task 2\n";
}

int main() {
    std::thread t1(task1);
    std::thread t2(task2);

    t1.join();
    t2.join();
    return 0;
}

이 예제에서는 두 개의 스레드를 생성하여 각각 task1과 task2를 동시에 실행합니다. 멀티스레딩을 통해 여러 작업을 병렬로 처리할 수 있으며, 이를 통해 CPU 사용량을 극대화할 수 있습니다.

왜 중요한가: 멀티스레딩을 사용하면 컴퓨터의 프로세서가 병렬로 작업을 처리하는 방식을 이해하게 되고, 경쟁 조건이나 데드락 같은 동시성 문제에 대해 배울 수 있습니다. 이는 자바스크립트의 이벤트 루프와 비동기 처리를 이해하는 데도 도움이 됩니다.

결론: C++를 통해 얻는 시스템 및 성능에 대한 이해

C++는 하드웨어와 가까운 수준에서 프로그래밍을 할 수 있도록 해줍니다. 메모리 관리, 포인터, 멀티스레딩 등 시스템 자원을 효율적으로 관리하는 방법을 배우면서 컴퓨터의 작동 원리와 성능 최적화에 대한 깊은 이해를 얻을 수 있습니다. 자바스크립트와 같은 고수준 언어를 사용할 때는 자동으로 처리되는 부분들이 C++에서는 명시적으로 드러나기 때문에, 시스템의 작동 방식과 최적화의 중요성을 체감하게 됩니다.

yarn plugin으로 우아하게 로깅하기

hmk run dev — Sun, 20 Oct 2024 09:58:03 +0900

로그는 에러 뿐만아니라 비즈니스 결정을 위한 중요한 요소가 된다.

이처럼 많은 로그를 자동화하기 위해서 많은 중복 코드가 발생할 수 밖에 없다.

토스는 자체 디자인 시스템인 TDS를 이용해 로깅을 자동화했다.

첫번째 시도 - 디자인시스템에 로그 기능을 추가하자

개발 비용도 적고 기존에 사용하던 곳에도 적용하기 쉬웠음

그러나, 계열사 별로 로그 코드가 많고 형태가 달라 통합하기 쉽지않음

그리고 로깅관련 코드가 함께 배포되는 이슈가 있었음

TDS가 로깅관련 코드를 포함해 로깅관련 수정사항을 반영하면 모든 컴포넌트의 디자인 사양도 변경해야하는 문제도 발생했다.

두번째 시도 - HOC 형태로 로그 감싸기

TDS 컴포넌트를 감싸 제공하는 형태로 제공,

서로 독집적으로 수정하고 배포가 가능해졌다.

그러나, 로깅 레이어를 사용하기 위해서 기존의 tds대신 hoc가 적용된 tds 컴포넌트를 사용해야했음

그래서 너무 많은 양의 코드 수정이 필요해짐

TDS를 사용하는 기존 서비스의 코드를 유지하면서 TDS를 가져올때 HOC가 적용된 로깅 컴포넌트를 사용할 수 있게 해보자

동일한 이름으로 코드 변경없이 로깅 기능을 제공할 수 있도록

의존성 트리 자체에서 TDS대신 로깅 라이브러리를 직접 바라보도록 수정해보자

이를 가능하게 하기 위해 yarn berry의 plugin을 이용해보기로 했다.

yarn(2)은 package manager 자체가 plugin 형태로 구성되어있다.

이에 앞서 yarn의 설치과정을 살펴볼 필요가있다.

- yarn add 시 Resolution step에서 새롭게 설치된 패키지명이 표시가됨

- 설치된 패키지의 사이즈가 명시됨

1. resolution - 버전의 범위 git repo등의 출처를 받은 뒤 하나의 고유 버전을 가리키는 id를 받음

2. fetch - resolution에서 얻은 id를 바탕으로 필요한 의존성 다운로드

3. link - 다운로드한 의존성을 어플리케이션에서 사용할 수 있게 연결

(node moldules에선 필요한 의존성을 복사, pnp환경에선 pnp manifest안에 각각의 패키지 위치를 기입)

그래서 결론적으로 TDS를 직접가져오는 것이 아닌 해당 패키지가 로깅 패키지를 거치게 하기 위해선

Resolution step에서 처리해야한다.

좀더 각 step의 동작 순서를 세부적으로 살펴보자

tds 버전을 넣을 수 있게 decriptor를 수정하고, 로깅 관련 코드를 대신 resolve할 수 있게

tds 버전과 로깅의 버전을 각각 독립적으로 관리할 수 있음

yarn plugin 기반으로 개발된 환경에서

package.json에서 의존성의 npm 버전 대신 logging으로 시작되는 특수한 버전을 사용할 수 있다.

기존과 똑같이 사용가능해진다.

출처

https://www.youtube.com/watch?v=E7jdKomaqjI

프론트엔드의 표준 (HTML, CSS, 크로스브라우징, 브라우저퍼포먼스, 웹 접근성)

hmk run dev — Sun, 29 Sep 2024 16:04:11 +0900

프론트엔드 개발의 중요성

프론트엔드프런트엔드 개발은 웹 애플리케이션이나 웹사이트의 ‘얼굴’입니다. 사용자가 처음 만나는 부분이기 때문에, 프런트엔드 개발의 품질은 사용자의 첫인상에 직접적인 영향을 미치죠. 하지만 왜 그렇게 중요한 걸까요? 몇 가지 예시를 통해 살펴보겠습니다.

1. 사용자 경험( UX)

사용자가 웹사이트를 방문했을 때, 그들이 어떻게 느끼는지가 중요합니다. 예를 들어, 여러분이 좋아하는 온라인 쇼핑몰에서 상품을 검색할 때, 결과가 빠르게 나타나고, 디자인이 깔끔하며, 직관적으로 탐색할 수 있다면, 그 경험이 얼마나 긍정적일까요? 반면, 느린 로딩 속도와 복잡한 내비게이션으로 인해 불편함을 느낀다면, 아마도 다시 방문하고 싶지 않을 겁니다. 이처럼 프런트엔드 개발은 사용자 경험을 극대화하는 데 필수적입니다.

2. 브랜드 이미지

프론트엔드 개발은 브랜드 이미지와 직결됩니다. 많은 스타트업이 초기 단계에서 웹사이트 디자인에 신경을 많이 씁니다. 예를 들어, 애플의 웹사이트는 세련되고 현대적인 디자인으로 유명합니다. 사용자들은 이러한 비주얼에 매료되고, 자연스럽게 브랜드에 대한 신뢰도를 높이게 됩니다. 반면, 디자인이 어지럽고 구식인 웹사이트는 브랜드 신뢰도를 떨어뜨릴 수 있습니다.

3. 접근성과 포괄성

프런트엔드 개발은 웹 접근성을 보장하는 데 중요한 역할을 합니다. 모든 사용자가 웹 콘텐츠에 접근할 수 있도록 설계된 웹사이트는 포괄적인 사회를 만드는 데 기여합니다. 예를 들어, 시각장애인을 위한 스크린 리더를 지원하는 웹사이트는 그들이 정보에 접근할 수 있도록 도와줍니다. 이러한 접근성은 단순한 의무를 넘어, 더 많은 사용자가 웹을 이용할 수 있게 만드는 중요한 요소입니다.

참고 - MDN 웹 접근성 지침(WCAG)

표준 준수의 필요성

웹 표준을 지키면 어떤 장점이 있을까?

브라우저와 OS와 관련 없이 하나의 코드로 모든 플랫폼을 대응할 수 있어

개발자에겐 개발의 효율성을

기업 입장에선 서버 비용 절감과 운영의 효율성을 가져다줄 수 있습니다.

그 외에도,

1. 검색엔진 최적화(SEO)

의미를 가진 시멘틱 태그를 사용하는 등 표준을 지켜 웹 페이지를 만들면 크롤러 봇이 좀 더 이해하기 쉬워집니다.

이는 웹페이지가 검색 결과 순위에서 더 높은 우위를 가져갈 수 있도록 합니다.

2. 개발자가 더 이해하기 쉬운 코드

웹 크롤러에게 사이트를 더 쉽게 이해할 수 있게 할 수 있을 뿐만 아니라 사람도 의미를 가진 통해 만들어진 구조를 더 이해하기 쉽습니다.

역시 개발자의 생산성을 높여 줄 수 있습니다.

3. 접근성 향상

웹 표준을 준수하면 웹 접근성이 크게 개선됩니다. 모든 사용자가 웹 콘텐츠에 접근할 수 있도록 설계된 웹사이트는 정보에 대한 평등한 접근을 보장합니다. 예를 들어, 시각장애인을 위한 스크린 리더 지원, 청각장애인을 위한 자막 제공 등은 다양한 사용자들이 웹을 보다 편리하게 이용할 수 있게 해 줍니다.

더욱이, 웹 접근성은 단순한 선택이 아니라 법적인 책임이 될 수 있습니다. 많은 국가에서 웹사이트 접근성에 대한 법적 요구 사항이 있으며, 이를 준수하지 않으면 소송이나 벌금 등의 법적 문제가 발생할 수 있습니다.

HTML 표준

HTML(하이퍼텍스트 마크업 언어)은 웹 페이지를 작성하는 데 사용되는 기본적인 언어입니다. HTML 표준은 웹 콘텐츠의 구조와 의미를 정의하며, 시맨틱 웹의 기초가 됩니다. HTML 표준을 준수하면 웹 페이지가 더 이해하기 쉽고, 접근성 및 SEO(검색 엔진 최적화)에서 유리한 점을 제공합니다.

1. HTML의 기본 구조

HTML 문서는 다음과 같은 기본 구조를 가집니다:

<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>HTML 표준 예제</title>
</head>
<body>
    <header>
        <h1>HTML 표준의 중요성</h1>
    </header>
    <main>
        <article>
            <h2>HTML이란?</h2>
            <p>HTML은 웹 페이지의 구조를 정의하는 마크업 언어입니다.</p>
        </article>
        <aside>
            <h3>관련 링크</h3>
            <ul>
                <li><a href="https://www.w3.org/TR/html52/">W3C HTML 표준</a></li>
            </ul>
        </aside>
    </main>
    <footer>
        <p>&copy; 2024 모든 권리 보유</p>
    </footer>
</body>
</html>

이 코드에서 보듯이, HTML 문서는 <!DOCTYPE html> 선언으로 시작하며, <html> 요소 내에 <head>와 <body> 요소로 나뉘어 있습니다.

2. 시맨틱 HTML

시맨틱 HTML은 웹 페이지의 구조와 의미를 명확히 하기 위해 적절한 태그를 사용하는 것입니다. 예를 들어, <header>, <footer>, <article>, <section> 등은 콘텐츠의 의미를 명확히 하여, 브라우저나 검색 엔진이 페이지를 더 잘 이해할 수 있게 도와줍니

<article>
    <h2>웹 접근성이란?</h2>
    <p>웹 접근성은 모든 사용자가 웹 콘텐츠에 접근할 수 있도록 하는 것입니다.</p>
</article>

이 예제에서 <article> 태그는 해당 콘텐츠가 독립적인 내용을 가지고 있음을 나타내며, 이를 통해 검색 엔진은 이 콘텐츠를 별도의 주제로 인식할 수 있습니다.

3. HTML 표준 준수의 장점

접근성 향상: 시맨틱 태그를 사용하면 스크린 리더와 같은 보조 기술이 콘텐츠를 더 쉽게 이해할 수 있습니다. 예를 들어, alt 속성이 있는 <img> 태그는 시각 장애인이 이미지의 내용을 알 수 있도록 해줍니다.

<img src="image.jpg" alt="설명 텍스트">

SEO 개선: 의미 있는 태그 사용은 검색 엔진 크롤러가 페이지를 인덱싱하는 데 도움을 줍니다. 시맨틱 HTML을 활용하면 페이지의 검색 결과 순위를 높일 수 있습니다.
유지보수 용이성: 표준을 준수한 코드는 다른 개발자가 이해하고 수정하기 쉬워집니다. 이는 팀워크와 프로젝트 관리에서 큰 장점이 됩니다.

크로스 브라우징

크로스 브라우징(Cross-Browsing)은 웹 개발에서 다양한 웹 브라우저와 디바이스에서 웹 페이지가 일관되게 작동하고 표시되도록 보장하는 과정을 의미합니다. 다양한 브라우저의 엔진 차이로 인해 웹 페이지의 렌더링과 기능이 다르게 나타날 수 있으므로, 크로스 브라우징 문제는 프론트엔드 개발의 중요한 고려 사항입니다.

1. 크로스 브라우징 문제의 원인

브라우저 엔진의 차이: 각 브라우저는 HTML, CSS, JavaScript를 해석하고 렌더링하는 방식이 다릅니다. 예를 들어, Chrome, Firefox, Safari, Edge 등은 동일한 코드를 다르게 해석할 수 있습니다.
CSS 및 JavaScript 지원 차이: 특정 CSS 속성이나 JavaScript API가 모든 브라우저에서 지원되지 않을 수 있습니다. 이러한 차이로 인해 웹 페이지의 스타일과 동작이 일관되지 않을 수 있습니다.
뷰포트 및 반응형 문제: 다양한 화면 크기와 해상도에 맞춰 레이아웃을 조정해야 할 때, 브라우저마다 반응형 처리 방식이 다를 수 있습니다.

2. 현대 프론트엔드의 해결 방안

현대 프론트엔드 개발에서는 여러 가지 방법으로 크로스 브라우징 문제를 해결하고 있습니다:

CSS 리셋 및 노멀라이즈 사용: 기본 스타일을 초기화하거나 표준화하기 위해 CSS 리셋(CSS Reset)이나 노멀라이즈(Normalize.css)를 사용합니다. 이는 각 브라우저에서 기본적으로 제공하는 스타일 차이를 줄이는 데 도움을 줍니다.

/* Normalize.css의 예시 */
html {
    line-height: 1.15; /* Improved line height */
}

모던 CSS와 JavaScript 프레임워크 사용: React, Vue.js, Angular와 같은 프레임워크는 크로스 브라우징 문제를 내재적으로 해결하는 기능을 제공합니다. 예를 들어, 이러한 프레임워크는 다양한 브라우저에서 일관되게 작동하는 컴포넌트 기반의 UI를 제공합니다.
Polyfill과 Babel 사용: 최신 JavaScript 기능을 사용하더라도 구형 브라우저에서 문제가 발생하지 않도록 Polyfill을 사용하여 기능을 추가하거나, Babel과 같은 도구를 사용해 ES6+ 코드를 ES5로 변환하여 더 많은 브라우저에서 호환되도록 합니다

Babel을 통한 트랜스파일링 예시

- 트랜스파일링 before

// arrowFunction.js
const add = (a, b) => a + b;

class Person {
    constructor(name) {
        this.name = name;
    }

    greet() {
        console.log(`Hello, my name is ${this.name}`);
    }
}

const john = new Person('John');
john.greet();

- 트랜스파일링 after

// arrowFunction-compiled.js
"use strict";

var add = function add(a, b) {
    return a + b;
};

var Person = function () {
    function Person(name) {
        this.name = name;
    }

    Person.prototype.greet = function greet() {
        console.log("Hello, my name is " + this.name);
    };

    return Person;
}();

var john = new Person('John');
john.greet();

polyfill 예시

- Array.prototype.includes Polyfill

Array.prototype.includes 메서드는 ES2015에서 추가된 기능으로, 배열에 특정 요소가 포함되어 있는지 확인합니다. 이 메서드를 지원하지 않는 브라우저에서 사용할 수 있도록 Polyfill을 추가할 수 있습니다.

// Array.prototype.includes Polyfill
if (!Array.prototype.includes) {
    Array.prototype.includes = function (value) {
        return this.indexOf(value) !== -1;
    };
}

위 Polyfill은 Array.prototype.includes가 존재하지 않을 경우, indexOf 메서드를 사용하여 주어진 값이 배열에 포함되어 있는지 확인합니다.

- fetch polyfill

fetch API는 네트워크 요청을 수행할 때 사용되며, 이를 지원하지 않는 브라우저를 위해 whatwg-fetch 라이브러리를 사용하여 Polyfill을 적용할 수 있습니다. 이 라이브러리는 GitHub에서 제공하며, 간단하게 사용할 수 있습니다.

<!-- HTML에서 Fetch Polyfill을 사용하기 위한 CDN 링크 -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/fetch/3.0.0/fetch.min.js"></script>

위 코드를 HTML 파일에 추가하면 fetch API를 지원하지 않는 브라우저에서도 이 API를 사용할 수 있게 됩니다.

그 밖에도 can i use에서 특정 css나 api 등이 어떤 브라우저에서 지원 되는지 확인 할 수 있습니다.

브라우저 퍼포먼스

1. 브라우저 성능의 중요성

사용자 경험: 빠른 로딩 시간과 원활한 상호작용은 사용자 경험에 큰 영향을 미칩니다. 느린 페이지는 사용자의 이탈률을 증가시키고, 브랜드에 대한 신뢰도를 낮출 수 있습니다.
SEO: 검색 엔진 최적화(SEO)에도 브라우저 성능이 중요한 역할을 합니다. Google은 페이지 속도를 중요한 순위 요소 중 하나로 간주하며, 느린 웹 페이지는 검색 결과에서 더 낮은 순위를 받을 수 있습니다.
전환율: 전자상거래 웹사이트의 경우, 페이지 로딩 속도가 전환율에 직접적인 영향을 미칩니다. 페이지가 느릴수록 고객이 구매를 완료할 가능성이 줄어듭니다.

2. 브라우저 성능 개선 전략

1. 리소스 최적화

이미지 최적화: 이미지 크기를 줄이고, WebP와 같은 최신 형식을 사용하여 페이지 로딩 속도를 개선합니다. 또한, 이미지에 대한 지연 로딩(lazy loading)을 적용하여 사용자가 필요할 때만 로드하도록 합니다.

<img src="example.jpg" loading="lazy" alt="Example Image">

요즘 많이 쓰이는 Next.js의 경우는 이미지 최적화를 위한 내장 컴포넌트를 제공합니다. 이 컴포넌트를 사용하면 자동으로 크기 조정, WebP 포맷 지원, 그리고 지연 로딩을 구현할 수 있습니다.

import Image from 'next/image';

const MyImage = () => (
    <Image src="/image.jpg" alt="My Image" width={500} height={300} />
);

CSS 및 JavaScript 압축: CSS 및 JavaScript 파일을 압축하여 파일 크기를 줄이고, 다운로드 속도를 개선합니다. 여러 파일을 하나의 파일로 병합하여 HTTP 요청 수를 줄이는 것도 좋은 방법입니다.

2. 비동기 로딩

JavaScript 비동기 로딩: async 또는 defer 속성을 사용하여 스크립트를 비동기적으로 로드하여 페이지의 렌더링 차단을 방지합니다.

<script src="script.js" async></script>

3. 캐싱 활용

브라우저 캐싱: HTTP 캐싱을 설정하여 사용자가 페이지를 다시 방문할 때 리소스를 로컬에 저장된 캐시에서 불러올 수 있도록 합니다. 이를 통해 서버 요청을 줄이고 로딩 시간을 단축할 수 있습니다.

Cache-Control: public, max-age=31536000

요즘 많이 쓰이는 react-query는 클라이언트 측 데이터 fetching 및 caching을 관리하기 위한 강력한 도구로, 웹 애플리케이션의 성능을 최적화하는 데 매우 유용합니다.

코드 예시

import React from 'react';
import { useQuery } from '@tanstack/react-query';

const fetchUsers = async () => {
    const response = await fetch('https://jsonplaceholder.typicode.com/users');
    if (!response.ok) {
        throw new Error('Network response was not ok');
    }
    return response.json();
};

const UserList = () => {
    const { data, error, isLoading } = useQuery(['users'], fetchUsers, {
        staleTime: 5000, // 5초 동안 데이터가 신선하다고 간주
        cacheTime: 10000, // 10초 동안 캐시된 데이터가 유지
    });

    if (isLoading) return <div>Loading...</div>;
    if (error) return <div>Error fetching data: {error.message}</div>;

    return (
        <ul>
            {data.map(user => (
                <li key={user.id}>{user.name}</li>
            ))}
        </ul>
    );
};

export default UserList;

코드 설명

fetchUsers 함수: 이 함수는 사용자의 데이터를 API에서 가져오는 비동기 함수입니다. 에러 처리를 포함하여 네트워크 요청을 수행합니다.
useQuery 훅: 이 훅은 데이터를 fetching하고 상태를 관리하는 데 사용됩니다. 첫 번째 인자로 쿼리 키를 전달하고, 두 번째 인자로 데이터를 fetching할 함수를 전달합니다. 선택적 인자로는 캐싱 전략을 설정할 수 있습니다.
- staleTime: 데이터를 신선하다고 간주하는 시간 (밀리초 단위)입니다. 이 시간 동안은 같은 쿼리를 다시 요청하지 않습니다.
- cacheTime: 쿼리의 캐시된 데이터를 유지하는 시간입니다. 이 시간이 지나면 캐시된 데이터가 제거됩니다.

프론트엔드 표준 준수의 장점

프론트엔드 표준 준수는 웹 개발의 핵심입니다. HTML과 CSS의 올바른 사용은 일관된 사용자 경험을 제공하며, 크로스 브라우징을 통해 다양한 환경에서도 접근성을 보장합니다.

웹 퍼포먼스 최적화는 로딩 시간을 단축시켜 사용자 만족도를 높이고, 웹 접근성 향상은 모든 사용자가 정보에 공평하게 접근할 수 있도록 합니다. 이는 법적 책임을 넘어 기업의 사회적 책임으로 이어집니다.

또한, 이러한 표준은 개발자에게도 효율성을 제공합니다. 명확한 구조와 코드 규칙은 유지보수성을 높이고, 팀 협업을 원활하게 합니다.

결국, 프론트엔드 표준 준수는 사용자와 개발자 모두에게 이익을 주며, 더 나은 웹 생태계를 만드는 데 기여합니다.

Reference

https://developer.mozilla.org/ko/docs/Web/Accessibility/Understanding_WCAG

웹 컨텐츠 접근성 지침 이해하기 - 접근성 | MDN

이 문서에서는 W3C 웹 컨텐츠 접근성 지침 2.0 또는 2.1(이 글에서는 WCAG)에 설명된 권장 사항들을 준수하기 위한 단계들을 이해하는 데에 도움이 되는 간략한 설명을 제공합니다.

developer.mozilla.org

WebRTC의 동작원리

hmk run dev — Wed, 25 Sep 2024 11:17:46 +0900

WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를

포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다.

실시간 통신: 브라우저 간에 실시간으로 오디오, 비디오, 데이터 스트림을 주고받습니다.(기본적으로 UDP 사용)
플러그인 불필요: 별도의 설치나 플러그인이 필요 없으며, HTML5와 자바스크립트만으로 통신이 가능합니다.
P2P 연결: 서버를 통해 데이터를 중계하지 않고, 사용자들끼리 직접 통신하여 지연 시간을 최소화합니다.
보안: 기본적으로 모든 통신은 암호화되어 있어, 보안이 중요한 실시간 통신에 적합합니다.

중개서버를 거치지 않기 때문에 빠른 속도로 통신이 가능하며 HTTPS 사용이 강제되기 때문에 보안 또한 보장됩니다.

속도와 보안과 더불어 WebRTC가 다양한 플랫폼, 브라우저에서 같은 사용자 경험을 제공하기 위해 호환성 또한 고려되어야 합니다.

브라우저 호환성은 can i use에서 확인 가능하다.

아직까지 완전히 표준화가 되어있지 않은 기술입니다.

WebRTC 자체는 1.0의 표준 버전이 있지만, 이 규격을 모두 준수하는 플랫폼이 많지 않은 것 같네요

아직 각 브라우저 WebRTC API에는 moz, webkit 같은 벤더 프리픽스가 붙어 있습니다.

MDN 문서에 따르면

각 브라우저마다 다른 코덱 및 기타 미디어 기능에 대한 지원 수준이 다르기 때문에, 코드 작성 전에 Google에서 제공하는

shim 및 polyfill을 사용하여 다양한 플랫폼의 WebRTC 구현 간의 차이점을 없애주는 Adapter.js 라이브러리를 사용하는 것을 강력하게 권장하고 있습니다.

WebRTC의 동작원리

P2P란(Peer to Peer)?

**P2P (Peer-to-Peer)**는 네트워크에서 중앙 서버 없이, 각 참여자가 동등한 권한을 가지고 직접적으로 데이터를 주고받는 통신 방식을 의미

P2P 절차

WebRTC는 P2P 방싱의 커뮤니케이션이기 때문에 통신 대상인 각각의 웹 브라우저는 다음과 같은 절차를 밟아야 한다.

1. 각 클라이언트가 P2P 연결에 동의

2. 서로의 주소 공유

3. 보안 사향 및 방화벽 우회

4. 멀티미디어 데이터를 실시간으로 교환

여기서 2번과 3번 단계가 일반적인 통신 방법으로는 이해하기 어려운 부분이다.

브라우저는 웹 서버가 아니기 때문에 외부에서 접근할 수 없는 주소가 없기 때문에 WebRTC가 P2P 기반이긴 하지만

통신 설정 초기 단계에서는 중재자의 역할이 필요합니다.

방화벽과 NAT 트래버셜

일반적인 컴퓨터에는 공인 IP가 할당되어 있지 않습니다.

보통의 회사 사무실에선 건물의 스위치(NAT)등을 이용해 공유기에 사설 IP를 받아 사용합니다.

(건물의 NAT > 사무실 공유기 NAT > 내 PC)

일반 컴퓨터에 공인 IP가 할당되지 않는 이유

공인 IP는 인터넷에 직접 연결되는 고유한 주소이며, 사설 IP는 내부 네트워크에서만 사용되는 주소입니다.
일반적인 컴퓨터에 공인 IP가 할당되지 않는 이유는 IP 주소의 부족, 보안, 네트워크 관리의 용이성, 비용 등의 이유 때문입니다. 사설 IP를 사용하여 NAT를 통해 공인 IP를 공유함으로써 이러한 문제를 해결하고 있습니다.

예시로 회사 사무실 공유기의 IP 할당에 대해 설명해 보겠습니다.

건물 전체의 라우터:
- 건물 자체에 위치한 라우터가 ISP로부터 공인 IP 주소를 할당받습니다. 이 라우터는 건물의 모든 사무실에 인터넷 연결을 제공합니다.
- 각 사무실은 건물의 라우터에 연결되며, 이를 통해 인터넷에 접근합니다.
사무실의 공유기:
- 사무실 내의 공유기는 일반적으로 사설 IP 주소를 할당받습니다. 이 경우 공유기는 건물의 라우터와 연결되어 있으며, 건물의 라우터에서 할당받은 공인 IP를 사용하여 인터넷에 연결됩니다.
- 공유기는 사무실 내부의 장치(컴퓨터, 프린터 등)에게 사설 IP 주소를 할당하여, 내부 네트워크를 구성하고 인터넷 접속을 관리합니다.

NAT의 역할

이 경우, NAT는 두 번 적용됩니다:
1. 건물의 라우터: 건물의 공인 IP와 내부 네트워크의 사설 IP 간의 변환을 관리합니다.
2. 사무실의 공유기: 사무실의 사설 IP와 건물의 공인 IP 간의 변환을 관리합니다.

요약

공유기가 직접 공인 IP를 할당받지 않고, 건물의 라우터가 공인 IP를 할당받아 여러 사무실에 인터넷을 제공하는 구조가 가능합니다.
이 경우 각 사무실의 공유기는 사설 IP를 사용하여 내부 장치를 관리하고, 건물의 라우터를 통해 인터넷에 연결됩니다.

일반적으로 라우터가 NAT 역할을 합니다. 외부에서 접근하는 공인 IP와 포트 번호를 확인하여 현재 네트워크 내의 사설 IP 들을 적절히 매핑시켜 줍니다.

결론적으로 어떤 브라우저 두 개가 직접 통신하려면, 각자 현재 연결된 라우터의 공인 IP 주소와 포트 번호를 먼저 알아내야 합니다.

But, 어떤 라우터들은 특정 주소나 포트와 연결을 차단하는 방화벽이 설정되어 있을 수도 있습니다.

이처럼 라우터를 통과해서 연결할 방법을 찾아내는 과정을 NAT 트래버셜이라고 합니다.

Traversal - 가로지르는, 여기저기 돌아다니는

STUN & TURN

STUN vs TURN

NAT 트래버셜 작업은 STUN(Session Traversal Utilitise for NAT) 서버에 의해 이루어집니다.

STUN 방식은 단말이 자신의 공인 IP주소와 포트를 확인하는 과정에 대한 프로토콜입니다.

즉, STUN 서버는 인터넷의 복잡한 주소들 사이에 유일하게 자신을 식별할 수 있는 정보를 반환해 줍니다.

WebRTC 연결을 시작하기 전에 STUN 서버를 향해 요청을 보내면 STUN 서버는 NAT 뒤에 있는 Peer들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아줍니다.

But, STUN 서버를 이용하더라도 항상 자신의 정보를 알아낼 수는 없습니다.

어떤 라우터들은 방화벽 정책을 다르게 할 수도 있고, 이전에 연결된 네트워크만 연결할 수 있게 제한을 걸기도 합니다.(Symmetric NAT)

이 때문에 STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우, TURN(Traversal Using Relay NAT)

서버를 대안으로 사용하게 됩니다.

TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 방식입니다.

중간에 서버를 한 번 거치기 때문에 엄밀히 말하면 P2P 방식이 아니게 됩니다.

하지만 보안정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이 기 때문에

이 방식은 최후의 수단으로 선택되어야 합니다.

ICE와 Candidate

위에서 이야기한 STUN, TURN 서버를 이용해 획득한 IP 주소와 프로토콜, 포트의 조합으로 구성 연결 가능한

주소들은 후보(Candidate)라고 부릅니다. 그리고 이 과정을 후보 찾기(Finding Candidate)라고 부릅니다.

후보들을 수집하면 일반적으로 3가지의 주소를 알게 됩니다.

- 자신의 사설 IP와 포트 넘버

- 자신의 공인 IP와 포트넘버(STUN, TURN 서버로부터 획득 가능)

- TURN 서버의 IP와 포트 넘버(TURN 서버로부터 획득 가능)

이 모든 과정들을 ICE(Interactive Connectivity Establishment)라는 프레임 워크 위에서 이뤄집니다.

ICE는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크입니다.

여기까지 내용을 요약하면 ICE 프레임워크가 STUN 혹은 TURN 서버를 이용해 상대방과 연결 가능한 후보들을 갖고 있고,

두 개의 사용자가 통신할 수 있는 주소를 알아냈습니다.

이제 주소를 알아냈으니 정보를 교환해야 합니다.

SDP

SDP(Session Description Protocol)은 WebRTC에서 스트리밍 미디어의 해상도, 코텍 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기위해 채택한 프로토콜입니다.

미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 발행 구독 모델(Pub/Sub)과 유사한 제안 응답 모델(Offer/Answer)을 가지게 됩니다.

다른말로, 어떤 피어가 이러한 미디어 스트림을 교환할 것 이라고 제안을 하면, 상대방으로부터 응답이 오기를 기다린다는 의미입니다.

응답을 받게되면 각자 피어가 수집한 ICE 후보 중에서 최적의 경로를 설정하고 협상하는 프로세스가 발생합니다.

수집한 ICE 후보들로 패킷을 보내 가장 먼저 지연 시간이 적고 안정적인 경로를 탐색합니다.

이렇게 최적의 ICE 후보가 선택되면, 기본적으로 필요한 모든 메타 데이터와 IP 주소 및 포트, 미디어 정보가 피어 간 합의가 완료됩니다.

Trickle ICE

ICE 프레임워크를 설정할 때 자주 접하는 옵션 중 하나가 Trickle ICE입니다. 이 용어가 어떤 의미인지 짐작이 가시나요?

일반적으로 각 피어는 ICE 후보를 수집하여 목록을 완성한 후 한꺼번에 교환합니다.
그러나 이 방식은 SDP의 제안 응답 모델과 맞물려 몇 가지 단점이 있습니다. 후보를 모으는 데 시간이 오래 걸리고, 네트워크 환경에 따라 지연이 발생할 수 있습니다. 또한 한쪽 피어의 ICE 후보 수집이 완료되어야 다른 피어가 후보를 모을 수 있어 비효율적입니다.

Trickle ICE는 이러한 비효율적인 후보 교환을 병렬 프로세스로 수행할 수 있게 해주는 기술입니다. 즉, 두 개의 피어가 ICE 후보를 수집하고 교환하는 과정을 동기적에서 비동기적으로 변화시킵니다.

Trickle 옵션이 활성화된 ICE 프레임워크는 각 피어에서 ICE 후보를 발견하는 즉시 교환을 시작합니다.
이를 통해 서로 연결 가능한 ICE를 더 빨리 찾아낼 수 있습니다. 이 옵션 덕분에 ICE 프레임워크는 피어 간의 연결 상태를 체크하면서 연결 시간을 최적화할 수 있습니다. 결론적으로 Trickle 옵션은 활성화하는 것이 좋습니다.

> Trickle ICE는 후보 수집 과정을 병렬적으로 처리하여, 각 피어가 발견한 ICE 후보를 즉시 교환

시그널링

위에서 언급한 모든 과정을 시그널링(Signaling)이라고 합니다.

이는 RTCPeerConnection 통신에 필요한 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보, NAT 통과 방법 등의 통신 규격을 교환하기 위해 두 장치 간의 제어 정보를 주고받는 과정을 의미합니다.

시그널링은 WebRTC 자체에서 지원하는 기능이 아니며, 연결 전 미리 준비해야 하는 과정입니다. 또한 WebRTC의 스펙에 포함되어 있지 않아 정해진 방법이 없습니다. 이는 알 수 없는 두 장치가 언제 어떤 방식으로 연결될지 예측할 수 없기 때문이며, 개발자는 자신에게 맞는 최적의 방법을 선택할 수 있습니다.

일반적으로 두 장치를 연결하기 위해 시그널링 서버를 직접 구축하거나, 외부 솔루션을 활용합니다.

시그널링 서버를 직접 구축할 경우, 웹 소켓(WebSocket)이나 서버 전송 이벤트(Server-sent Event) 방식을 사용할 수 있습니다.

또는 시그널링 정보를 조회할 수 있는 API를 만들고 브라우저에서 주기적으로 XHR 요청을 통해 폴링(polling) 기법을 적용할 수도 있습니다.

WebRTC를 처음 접하는 개발자에게는 표준이 없다는 점이 혼란을 줄 수 있습니다. 직접 서버를 구축하는 것은 작업량이 많기 때문에, 시그널링 서버를 제공하는 솔루션을 사용하는 것도 좋은 방법입니다. 예를 들어, 아마존의 Kinesis Video Stream이나 구글의 AppRTC에서 Google App Engine으로 구현된 시그널링 서버를 확인할 수 있습니다.

References

https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API

WebRTC API - Web API | MDN

WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는

developer.mozilla.org

https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html

WebRTC는 어떻게 실시간으로 데이터를 교환할 수 있을까? - 재그지그의 개발 블로그

WebRTC 연결 절차에 대해 알아보고, 이 과정에서 접할 수 있는 낯선 용어들에 대해 정리해봅니다.

wormwlrm.github.io

프론트엔드의 역사

hmk run dev — Sun, 22 Sep 2024 13:41:42 +0900

3년 차 프런트엔드 개발자로서, 요즘 많은 개발자들이 사용하는 React와 Next.js 같은 프레임워크를 나도 사용하고 있다.

그러다 문득, 내가 현재 쓰고 있는 기술 스택들이 왜 등장하게 되었는지, 그리고 어떤 문제를 해결하거나 개선했기에 지금까지 널리 사용되고 있는지 궁금해졌다. (재미있게도, 일부는 과거 방식으로 되돌아가는 것처럼 보이기도 한다.)

참고로, 이 글에서는 WEB 1.0이나 IE 등장 등 웹의 초기 역사보다는, JSP 등의 백엔드 중심 개발에서 프런트엔드 직군이 본격적으로 생겨난 시점부터 이야기를 시작해 보려고 합니다.

프런트엔드 직군의 탄생: 백엔드 중심에서 프런트엔드로

초기 웹 개발: 웹 개발 초기에는 프런트엔드와 백엔드의 경계가 불분명했습니다. JSP, PHP, ASP 같은 서버 사이드 기술을 사용해 서버에서 HTML을 렌더링하고 이를 클라이언트에 전달하는 방식이 주류였습니다.
사용자 경험(UX)의 중요성 대두: 웹이 점점 더 복잡해지면서 사용자 인터랙션의 중요성이 강조되었고, 더 나은 사용자 경험을 제공할 필요가 생기면서 프론트엔드 개발이 전문 분야로 발전하기 시작했습니다.
AJAX의 등장과 동적 웹페이지: AJAX가 등장하면서 페이지 전체를 다시 로드하지 않고도 서버와 데이터를 주고받는 비동기 처리가 가능해졌습니다. 이로 인해 웹 애플리케이션은 더욱 동적이고 사용자 친화적인 방식으로 발전할 수 있었습니다.

jQuery와 그 한계

DOM 조작의 편리함: jQuery는 JavaScript로 DOM을 쉽게 조작할 수 있는 라이브러리로, 복잡한 크로스 브라우저 이슈를 해결하며 큰 인기를 끌었습니다.
상태 관리의 어려움: 하지만 프로젝트가 커질수록 DOM 조작과 상태 관리는 점점 복잡해졌고, 이로 인해 코드의 유지보수성이 떨어졌습니다. 특히 데이터를 관리하고 이를 UI에 일관되게 반영하는 것이 큰 문제였습니다.
이와 더불러 javascript 자체 DOM 조작 API도 점점 발전해 굳이 사용할 필요가 없어지기도 한 것 같다.

하지만 jQuery는 여전히 리액트 다음으로 인기가 있다.

AngularJS: 프레임워크의 시작 (2010년)

AngularJS는 구글에서 2010년에 출시한 프레임워크로, 기존의 jQuery로 해결하기 어려운 대규모 애플리케이션의 복잡한 로직과 데이터 관리를 해결하기 위해 만들어졌습니다. (사실상 MVVM 패턴을 사용하는 것 같지만 앵귤러 공식사이트는 MVW(whatever)라고 표현한다.)

양방향 데이터 바인딩 (Two-way Data Binding): AngularJS는 양방향 데이터 바인딩을 도입하여, 모델(데이터)과 뷰(UI)가 자동으로 동기화되었습니다. 즉, 데이터가 변경되면 UI가 자동으로 업데이트되고, UI의 변화도 데이터에 즉시 반영됩니다. 이 기능은 개발 생산성을 크게 향상했습니다.

개선점: AngularJS는 jQuery의 단순한 DOM 조작 방식을 넘어서, 애플리케이션 전체의 구조를 체계적으로 관리할 수 있는 프레임워크로 개발되었습니다. 데이터와 UI의 일관성을 자동으로 유지하고, 대규모 애플리케이션에서도 쉽게 확장할 수 있도록 했습니다.

React의 등장: 컴포넌트 기반 개발

Virtual DOM과 컴포넌트 기반 아키텍처: Facebook에서 개발한 React는 Virtual DOM을 도입하여 DOM 조작의 성능 문제를 해결하고, 컴포넌트 기반 아키텍처를 통해 UI를 모듈화 했습니다. (가상돔이 항상 효율적이라고 볼 순 없다.)
효율적인 상태 관리: React의 상태 관리 시스템은 데이터가 변경될 때마다 UI를 효율적으로 업데이트할 수 있게 했습니다. 이를 통해 대형 애플리케이션에서도 일관된 UI와 상태 관리를 할 수 있었습니다.

개선점: 앵귤러와 달리 데이터가 부모에서 자식으로 흐르는 단방향 데이터 흐름을 채택하여 데이터의 흐름이 명확하고 예측 가능해졌고,

상태와 생명주기를 관리할 수 있는 hooks 방식을 채택해 코드의 간결함과 재사용성을 높임, JSX을 사용하여 UI를 선언적으로 작성할 수 있게 됨

주의해야 할 점

CSR로 인한 SEO 저하 ,리렌더링 성능 문제(props 가 변경되면 컴포넌트도 리렌더링), 타 SPA 프레임워크 대비 right-way 기준이 모호함

상태 관리의 진화 Flux 패턴, Redux, Zustand... 의 등장

웹 애플리케이션이 복잡해짐에 따라 컴포넌트 간의 상태 공유와 관리가 어려워졌습니다. 데이터의 흐름을 명확히 하고, 예측 가능한 방식으로 상태를 관리할 필요성이 대두되었습니다.

Flux 패턴

출현 배경: 페이스북에서 대규모 애플리케이션의 상태 관리를 위해 개발.
주요 특징: 단방향 데이터 흐름. 상태가 변할 때마다 액션을 통해 Dispatcher가 상태를 업데이트하도록 하여 데이터 흐름을 명확히 함.
해결하는 문제: 복잡한 상태 관리 및 컴포넌트 간의 비동기적 데이터 처리 문제.

Redux

출현 배경: Flux의 복잡성을 단순화하고, 상태 관리를 더 직관적으로 만들기 위해 탄생.
주요 특징: 단일 스토어, 불변성, 미들웨어 지원. 상태를 관리하기 위해 순수 함수인 리듀서를 사용.
해결하는 문제: 대규모 애플리케이션에서 상태를 더 쉽게 관리하고 디버깅할 수 있도록 지원. 개발자 도구와의 통합으로 상태 변화를 쉽게 추적 가능. props drilling문제 해결

현재는 zustand, recoil, jotai 등의 전역상태관리 도구들이 생겼다.

주의해야할 점

물론 전역 상태를 사용할 때 메모리 사용량 증가, 상태의 비효율적인 관리, GC 등의 문제를 고려해야 하는 번거로움도 생겼다.

Next.js: 서버사이드 렌더링과 정적 사이트 생성

SEO와 초기 로딩 성능 문제 해결: Next.js는 React 기반의 프레임워크로, 서버사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 지원하여 검색 엔진 최적화(SEO)와 첫 화면 로딩 성능 문제를 해결했습니다.
하이브리드 애플리케이션: Next.js는 클라이언트사이드 렌더링(CSR)의 문제를 보완하면서도, SSR과 SSG를 유연하게 사용할 수 있는 하이브리드 애플리케이션을 가능하게 했습니다.

이외에도 Nextjs에서 여러 기술을 도입해 성능을 개선하고 있다.

Incremental Static Regeneration (ISR)

개념: ISR은 SSG의 확장으로, 정적 페이지를 생성하되, 특정 시간 간격으로 페이지를 재생성하여 최신 콘텐츠를 제공하는 기능입니다. 이는 정적 사이트의 장점과 동적 사이트의 유연성을 결합한 것입니다.
사용 예: 뉴스 사이트나 블로그에서 최신 기사를 주기적으로 업데이트할 때 유용합니다. 예를 들어, 10분마다 새로 고침 하여 콘텐츠를 최신 상태로 유지할 수 있습니다.

서버 컴포넌트

개념: Next.js 13에서 도입된 서버 컴포넌트는 서버에서 직접 렌더링 되며, 클라이언트에게 전달되는 HTML을 최소화하여 성능을 향상하는 기능입니다. 서버에서 데이터를 가져오고, 해당 데이터를 기반으로 UI를 구성합니다.

쉽게 말해, 서버 컴포넌트(Server Components)는 서버사이드 렌더링(SSR)을 컴포넌트 단위로 세분화한 방식으로 볼 수 있습니다.
장점: 클라이언트의 자원 사용을 줄이고, 서버에서 모든 비즈니스 로직을 처리할 수 있어 애플리케이션의 성능을 최적화합니다. 데이터 패칭과 UI 렌더링이 서버에서 이루어지기 때문에, 클라이언트 측의 부담이 크게 줄어듭니다.

Vue.js: Right-way가 명확한

명확한 right-way: 코드의 양이 많아지면 "코드짜는 법이 제한적"인건 큰 장점이 될 수 있고 vue는 react에 비해 코드 짜는 답이 정해져있습니다.

ex) map, forEach, for in, for of > HTML안에 v-for 사용

쉬운 학습 곡선: Vue는 직관적인 API와 HTML 템플릿 구문을 제공하여 초보자가 쉽게 배우고 사용할 수 있습니다.
HTML, CSS, JS만 알고 있어도 비교적 배우기 쉽다.

명확한 컴포넌트 구조: Single File Component(SFC) 형식을 통해 HTML, CSS, JavaScript를 한 파일에서 관리할 수 있어 코드 관리가 용이합니다.

Svelte: 컴파일 타임에서의 최적화

Virtual DOM 없이 빠른 성능: Svelte는 Virtual DOM을 사용하지 않고 컴파일 타임에 UI 컴포넌트를 최적화하여 더욱 빠른 성능을 제공합니다. (런타임 라이브러리의 필요성이 줄어듦)
러닝 타임 오버헤드 제거: 컴포넌트를 사전 컴파일함으로써 런타임 성능 이슈를 최소화하고, 가벼운 웹 애플리케이션을 구축할 수 있게 합니다.

현대 프론트엔드는 빠르게 변화하고 있으며, 다양한 프레임워크와 기술이 등장하고 있습니다.
개인적으로 느끼는 바는 SSR(서버사이드 렌더링)과 SPA(싱글 페이지 애플리케이션) 사이에서 회귀하는 경향이 있다는 점입니다. 초기의 SSR은 SEO와 초기 로딩 성능에서 큰 장점을 제공했지만, SPA의 사용자 경험과 인터랙티브한 요소가 점차 중요해지면서 두 방식 간의 균형을 찾고 있습니다.

Next.js와 같은 프레임워크는 이러한 변화의 좋은 예시입니다. Next.js는 SSR과 SSG(정적 사이트 생성)를 모두 지원하여 개발자가 필요에 따라 최적의 방식을 선택할 수 있도록 해줍니다. 또한, 풀스택 개발을 지원함으로써 프론트엔드와 백엔드의 경계를 허물고, 보다 통합된 개발 환경을 제공합니다.

Vue, Svelte 등은 React의 단점을 개선하는 방향으로 발전하고 있지만, React의 압도적인 점유율과 넓은 생태계는 쉽게 흔들리지 않을 것으로 보이네요

하지만 jQuery는 여전히 리액트 다음으로 인기가 있다.

그리고 최근엔 AI 툴의 등장으로 HTML, CSS, 심지어 JavaScript 코드 작성의 생산성을 크게 향상시켰습니다.

이러한 변화 속에서 프론트엔드 개발자가 갖춰야 할 능력도 변할 수 있습니다. 예를 들어, 복잡한 요구 사항을 분석하고 적절한 아키텍처를 설계하는 능력은 더욱 중요해질 것입니다. 단순한 코드 작성이 아닌, 전체 시스템을 이해하고 최적의 솔루션을 제시하는 능력이 요구됩니다.

또한, 사용자 경험(UX) 디자인에 대한 이해와 설계 능력도 필수적입니다.

AI 도구가 기본적인 UI 요소를 생성하더라도, 사용자와의 상호작용을 최적화하고 감동을 줄 수 있는 디자인은 여전히 개발자의 몫입니다.

마지막으로, 커뮤니케이션 능력 역시 중요해질 것입니다. 팀 내 협업이나 고객 요구 사항을 효과적으로 이해하고 전달하는 능력이 프로젝트의 성공에 큰 영향을 미칠 수 있습니다. AI가 도와주는 작업 속에서도 사람 간의 소통과 협력이 필요한 부분이 여전히 존재하기 때문입니다.

이처럼 AI 시대에 발맞춰 프론트엔드 개발자는 기술적 능력뿐만 아니라 다양한 소프트 스킬도 함께 발전시켜 나가야 할 것 같습니다.

자바스크립트가 프로토타입을 선택한 이유

hmk run dev — Sat, 21 Sep 2024 11:45:50 +0900

자바스크립트를 처음 접했을 때, 사실 아직 까지도 가깝지만 먼 이웃 같은 존재인 프로토타입

여러 글들에선 "프로토타입은 자바스크립트에서 상속을 지원하기 위한 방법"라고 이야기하곤 한다.

여기엔 꼬리에 꼬리를 무는 질문이 이어질 수 있는데, "왜 다른 언어처럼 클래스가 아니라 프로토타입을 사용하는가?"

"프로토타입과 클래스의 차이는 뭘까?"

그 외에도 자바스크립트엔 면접 단골 질문으로도 유명한 this, 호이스팅, 클로저, 스코프체인 등등.. 이 있다.

이러한 자바스크립트의 특성들을 단순하게 암기만 하고 있었고, 대부분의 관련 자료들은 해당 현상에 대해서

설명하는 내용이 주를 이뤘고 단순히 외워야 하는 고통스러운 시간이었다.

"호이스팅은 자바스크립트에서 코드 실행 시 전체 코드를 선언부 상단으로 올려 실행가능한 상태인지 확인한다"

"this는 기본적으로 global을 가리키고 실행 콘텍스트에 따라 달라질 수 있으며 call, bind, apply 등을 통해 제어할 수 있다."

FE 개발자로서 위의 질문과 답변은 정형화되어 있다고 생각했다.

사실 필자도, 이직을 준비할 때 위와 처럼 정형화된 답변을 다시 상기시키고 외웠던 사람 중에 하나이다.

그러나 피해왔던 근본적인 "왜?"에 대한 질문을 타개하고자 자바스크립트의 프토로토타입 선택이유에 대해 정리하고자 합니다.

Classses vs Prototypes Some Pliosophical and Historical Observations

위 논문을 토대로 이야기하자면 prototype과 class의 OOP는 완전히 상반되는 방식이라고 볼 수 있다.

객체를 바라보는 개념 자체가 완전히 다르다.

특히 문맥(context)을 매우 강조하는 철학적 근거에서 태어난 녀석이라 렉시컬 스코프에 의한 호이스팅과 실행 문맨에 의해 결정되는 this가 필연적으로 발생할 수밖에 없다.

자바스크립트의 프로토타입 선택 이유에 대해 다뤄보면서 실행 context, this, 호이스팅, 클로저 등이 발생하는

이유에 대해 정형화된 암기를 벗어나 근본적인 이유에 대해서 이해할 수 있기를 바랍니다.

플라톤과 이데아, 그리고 클래스 기반 객체지향프로그래밍

"서양 철학은 플라톤의 각주에 불과하다 - 화이트 헤드"

프로토타입을 이해하려면 그 대척점에 있는 클래스의 기원을 알아햐 한다.

클래스 기반 객체지향 언어(Java, C#)를 다뤄봤다면 이미 알고 있는 내용일 수도 있습니다.

서양철학은 이분법적 세계관을 갖고 있는데요,

- 영혼 / 육체

- 추상적 / 구체적

- 이데아 / 프랙터스

눈앞에 실제로, 구체적으로 존재하는 사물이 있다면 반드시 그것의 본질이 존재한다는 것이 플라톤의 주장입니다.

의자를 예시로 보면 우리가 앉아있는 의자는 여러 가지 형태가 존재합니다.

사무용 의자, 공원 벤치, 원목 의자 등등 이러한 수많은 의자가 실제로 존재한다면 반드시

그 본질적이고 추상적인 "의자"라는 것이 존재한다는 것이지요

이러한 본질 세계를 이데아(Idea)라고 합니다. 현실의 의자는 모두 이데아의 "의자"를 모방한 의자라는 것입니다.

영어권의 사고방식에는 이러한 이분법적 세계관이 기본입니다.

영어의 "관사"를 보면 이러한 방식이 두드러지는데요,

영어에서 이데아의 세계에 있는 의자를 이야기할 때 그냥 "chair"라고 얘기하는 것이 그 방법입니다.

그럼 현실에 존재하는 의자를 가리킬 땐 어떻게 이야기할까요?

현실에 존재하는 것을 얘기할 땐 단어 그대로 이야기하지 않고 "때"를 묻혀서 이야기합니다.

그래서 "the chair"라고 얘기해야 합니다.

- chair : 이데아에 존재하는 본질적인, 추상적인 의자. 현실세계에 존재하지 않음

- this chair, a chair : 현실 세계에 존재하는 의자

이러한 사고방식이 프로그래밍 언어에도 자연스럽게 녹아들어 생긴 언어가 있습니다.

바로 "클래스 기반 객체지향 프로그래밍 언어"입니다.

Java를 예시로 볼까요?

class Chair {  // class 선언 자체는 이데아에 존재하는 의자
... 
}

Chair myChair = new Chair(); // new 키워드로 추상적으로만 존재하던 의자를 메모리라는 현실세계로

위 코드에서 레퍼런스 타입이라 불리는 Chair 클래스는 이데아에 존재하는 추상적인 개념

즉, 코드상으로만 존재하지 실제 메모리상에는 존재하지 않습니다. (사실, PermGen 영역에 있겠지만 Heap 메모리를 실제 하는 공간으로 보겠습니다.)

그럼 현실세계에 존재하게 하려면 어떻게 해야 할까요?

바로 new 키워드 사용하면 됩니다. new Chair();를 하는 순간 추상적으로만 존재하던 의자가 메모리라는 현실시계에

구체적으로 존재(인스턴스화)하게 됩니다.

분류(Classification)

이러한 플라톤의 이데아 이론은 그의 제자 아리스토텔레스에 의해서 "분류(Classification)"란 개념으로 정리됩니다.

class라는 키워드는 "학급"을 의미하는 게 아니라 Classification에서 나온 키워드입니다.

- 개체의 속성이 동일한 경우 개체 그룹은 같은 범주에 속한다. 범주란 정의와 구별의 합니다.

이는 전통적인 클래스 기반의 객체 지향 프로그래밍의 아이디어-일반화와 정확하게 일치합니다.

여기서 속성은 프로퍼티가 될 수 있겠죠, 프로퍼티가 유사한 객체가 있다면 일반화 과정을 통해 추상 클래스로 추상화됩니다.

실제로 아리스토텔레스는 이러한 기준으로 현실 세계의 많은 것들은 분류했지요,

최초로 동물을 분류했고, 속성에 따라 분류는 어류가 아닌 포유류가 되었죠

돌고래의 속성에 따른 분류

// 포유류(Mammal) 추상 클래스: 모든 포유류는 허파로 숨을 쉬고 새끼를 낳음
abstract class Mammal {
    abstract void breathe();    // 숨쉬기 메서드 (허파로 호흡)
    abstract void giveBirth();  // 새끼를 낳는 메서드
}

// 돌고래(Dolphin) 클래스: 포유류의 특징을 상속받아 구현
class Dolphin extends Mammal {

    @Override
    void breathe() {
        System.out.println("돌고래는 아가미가 아닌 허파로 숨을 쉽니다.");
    }

    @Override
    void giveBirth() {
        System.out.println("돌고래는 새끼를 낳고 젖을 먹입니다.");
    }
}

// 어류(Fish) 추상 클래스: 어류는 아가미로 호흡하고 알을 낳음
abstract class Fish {
    abstract void breathe();
    abstract void layEggs();
}

// 상어(Shark) 클래스: 어류의 특징을 상속받아 구현
class Shark extends Fish {

    @Override
    void breathe() {
        System.out.println("상어는 아가미로 숨을 쉽니다.");
    }

    @Override
    void layEggs() {
        System.out.println("상어는 알을 낳습니다.");
    }
}

프로토타입(Prototype)

"서양 철학은 플라톤의 각주에 불과하다 - 화이트 헤드" 하지만 이 말에는 "비트겐슈타인 이전까지"라는 단서를 붙여야 한다.

- 와스피 히잡

이제야 프로토타입 이야기가 나오는데요, 프로토타입을 이야기하기 위해서 분류(Classification)에 대해 반드시 알아야 할 필요가 있기

때문에 짚고 넘어갔습니다.

프로토 타입은 분류의 개념을 정면으로 반박하여 나온 이론이기 때문입니다.

19세기 철학자 비트겐슈타인은 아리스토텔레스의 분류 개념을 정면으로 반박합니다.

"공유 속성의 관점에서 정의하기 어려운 개념이 있다(사실) 올바른 분류란 없다 - 비트겐슈타인"

이것을 뒷받침하기 위해 들고 온 것은 바로 게임입니다.

게임은 일반적으로 "승리"와 "패배"가 명확합니다.

하지만 비트겐슈타인은 이에 대한 반론으로 "승리"와 "패배"가 없는 ring around a rosy라는 게임을 가져옵니다.

그냥 빙글빙글 돌다 다 같이 주저 않는 게임으로 누구도 승리, 패배하지 않죠(재미없을 것 같긴 하네요)

여하튼 이 게임엔 공유 속성(property)이 없네요

- 승리 / 패배? 없음

- 숙련도 여부? 행운(주사위) 위주 게임은 없잖아

- 플레이어 존재여부? 플레이어가 전혀 필요하지 않은 게임도 있잖아

특히 예술작품의 경우 공통 속성을 정의하기 더 어렵습니다.

즉, 좀 더 철학적으로 본다면 "게임", "예술" 등의 단어는 결코 속성으로 규정할 수 없습니다.

"세계에 미리 내재되어서 대상과 언어를 완전히 규정하는 어떤 언어란 존재하지 않는다. - 비트겐슈타인"

Java와 같은 객체 지향 프로그래밍 언어로 개발하다 보면 한계에 부딪힐 때가 있는데요,

최적의 클래스를 설계를 만드는 것이 어려울 때가 있습니다.

속성(property)으로 분류하는 것은 확정성을 고려하면 좋은 방식이 아니었습니다.

정답이라고 생각했던 설계도 개발이 진행되면서 뒤엎는 경우가 많았습니다.

멋들어진 상속관계는 기술부채가 되어버리는 경우도 많았죠,

물론 도메인 기반 설계, SOLID, 디자인 패턴을 더 습득하며 그럴싸한 클래스를 설계할 수 있도록 갈고닦아야겠지요

한 번에 완벽한 디자인이 나오는 것은 너무나 어렵습니다.

이러한 분류(Classification)에 대해 강하게 비판한 비트겐슈타인, 그렇다면 그의 대안은 무엇이었을까요?

"표현은 삶의 흐름 속에서만 의미를 갖는다 - 비트겐슈타인"

의미사용이론(the use theory of meaing)

비트겐슈타인 일생의 후기에 내놓은 이론입니다.

사용(use)에 의해 의미(meaning)가 결정된다는 이론입니다.

단어의 쓰임새가 곧 의미가 됩니다. 즉, 단어의 진정한 본래의 의미란 존재하지 않고 상황과 맥락에 의해서 결정된다라고

주장하고 있습니다. 그러니 단어의 의미를 백날 분석해 봤자 소용이 없다는 것입니다.

비트겐슈타인은 "벽돌"을 예로 들었습니다. 누군가 벽돌!이라 외쳤을 때 상황마다 그 의미는 달라집니다.

- 벽돌이 필요할 때 : 벽돌을 달라

- 벽돌로 보수해야 할 때 : 벽돌을 채우라

- 벽돌이 떨어질 때: 벽돌을 피해라

위의 내용이 와닿지 않는다면 맥락(context)이 중요하다는 것만 기억하시면 됩니다.

콘텍스트로 프로토타입 기반 언어의 실행 콘텍스트를 설명할 수 있습니다.

가족 유사성(Family Resemblance)

비트겐슈타인의 위에서 설명한 의미사용론과 더불어 가족 유사성이라는 또 하나의 이론을 주장합니다.

출처 : https://www.slideshare.net/vcmlab/cog5-lecppt-chapter08

인간이 현실에서 실제로 대상을 분류할 때 속성이 아닌 가족 유사성을 통해 분류하게 된다고 얘기합니다.

위 그림처럼 한 가족이 있을 때 이 가족 모두 공유하는 공통속성은 없습니다.

갈색 머리, 안경, 수염, 큰 코가 가족의 전형적인 특징이라고 하더라도 모든 가족 구성원에게 적용되는

공통된 특성(속성)은 없을 수 있습니다.

그런데도 우리는 이 그림을 보고 전형적인 특징을 통해 "가족"으로 분류합니다.

이러한 분류 방식을 "가족 유사성"에 의한 분류라고 합니다.

이 이론은 프로토타입 이론의 근거가 됩니다.

Rosch의 프로토타입 이론

이론의 마지막 장입니다. 드디어 "프로토타입"이라는 단어를 직접 다루는 이론입니다.

비트겐슈타인의 의미사용이론, 가족유사성은 1970년경 철학자 Eleanor Rosch에 의해

프로토타입 이론(Prototype theory)으로 정리됩니다.

- 실험 참가자들에게 여러 범주 구성원(사과, 코코넛, 오렌지)의 속성을 적어보라고 함

- 각 범주 구성원에 대해 범주의 다른 구성원과 공유하는 속성의 개수를 도출

- 사과, 오렌지 : 2점(둥글다, 즙이 있다.)

- 코코넛: 1점(둥글다)

점수가 높을수록 "가족 유사성"이 높다고 볼 수 있습니다.

전통적인 분류에선 모두 과일로 볼 수 있지만, 프로토타입 이론에서는 사과 오렌지가 가장 전형적인 무언가라고 볼 수 있습니다.

반면에 코코넛은 저 중에서 가장 비전형적인 것으로 볼 수 있겠네요

이 실험을 통해 로쉬는 "인간은 등급이 매겨진 구조를 가진다"라고 주장합니다.

인간이 사물을 분류할 때 자연스럽게 가장 유사성이 높은 것들을 순서대로 등급을 매긴다는 의미로 볼 수 있습니다.

이렇게 분류를 하다 보면 가장 높은 등급을 가진 녀석이 나올 텐데요, 이것이 바로 Prototype이다.

라는 주장이 프로토타입 이론입니다.

"새"를 예로 들어보면

"참새"는 새의 범주는 대표할 만한 가장 전형적인 새입니다.

이것을 "원형(prototype)"으로 간주해 봅시다.

출처 : https://laurabecker.gitlab.io/classes/as/08-semantics.pdf

같은 새지만 "타조"는 분류에선 원형과 가장 멀리 떨어진 "비전형적인" 새가 됩니다.

즉, 객체는 "정의"로부터 분류되는 것이 아니라 가장 보기 좋은(prototype exemplar)로부터 범주화됩니다.

이러한 분류 체계는 매우 경제적입니다.

만약 우리가 새로운 대상을 접해서 분류해야 한다면, 우리는 새로운 대상의 몇 가지 특징만 원형(prototype)과

비교해서 확인만 하면 됩니다.

이 이론에 또 한 가지 중요한 것이 있는데요

바로 같은 단어라 할지라도 누가 어떤 상황(context)에서 접했느냐에 따라 의미가 달라질 수 있습니다 - 의미사용론

예를 들면 아이가 생각하는 새의 범주엔 "참새"는 속하지만 "펭귄"은 해당범주에 속할 수 있습니다.

아이가 생각할 때 펭귄은 매우 비전형적이기 때문이죠

하지만 조류학자가 생각할 때 "참새"와 "펭귄"은 명확하게 유사한 새의 범주에 속할 수 있습니다.

즉, 같은 단어라도 어떤 상황에서 접했느냐에 따라 범주는 크게 달라집니다.

- 현실에서 존재는 것 중 가장 좋은 본보기를 원형(prototype)으로 선택

- 문맥(context)에 따라 의미가 달라진다.

프로토타입 기반 객체지향 프로그래밍

이러한 프로토타입 이론은 그대로 프로토타입 기반 객체지향 프로그래밍 언어를 통해 구현되었습니다.

프로토타입 기반 OOP 언어의 특징은 다음과 같습니다.

- 개별 객체(instance) 수준에서 메서드와 변수를 추가

- 객체 생성은 일반적으로 복사를 통해 이루어짐

- 확장(extends)은 클래스가 아니라 위임(delegation)을 통해 이뤄짐

- 개별 객체 수준에서 객체를 수정하고 발전시키는 능력은 선험적 분류의 필요성을 줄이고 반복적인 프로그래밍 및 디자인스타일 추구

- 분류하지 않고 유사성을 활용하도록 선택

- 설계는 맥락(context)에 의해 평가

javascript 언어를 사용하는 사람의 관점으로 중요하다 생각되는 부분을 되짚어보면

- 프로토타입 언어에서는 "분류"를 우선하지 않는다. 생성된 객체 위주로 유사성을 정의한다.

- 쓰임새는 contenxt에 의해 평가된다

> 실행 콘텍스트, 스코프 체인이 파생됨

> 클로저, this, 호이스팅 등등 이 모든 것들이 프로토타입의 "맥락"을 표현하기 위함

자바스크립트의 프로토타입

function 참새(){
    this.날개갯수 = 2;
    this.날수있나 = true;
}
const 참새1 = new 참새();

console.log("참새의 날개 갯수 : ", 참새1.날개갯수); // 2

function 닭(){
  this.벼슬 = true;
}
닭.prototype = 참새1; // reference(오른쪽이 인스턴스인 점 주목)
const 닭1 = new 닭();
console.log("닭1 날개 : ", 닭1.날개갯수, ", 날수있나? ", 닭1.날수있나); // 2, true
닭1.날수있나 = false;
console.log("다시 물어본다. 닭1은 날 수 있나? :", 닭1.날수있나); // false
// 아래는 고전적인 방식의 프로토타입 연결
function 펭귄(){
    참새.call(this);    // copy properties
}
펭귄.prototype = Object.create(참새.prototype); // 프로토타입 연결
const 펭귄1 = new 펭귄();
console.log("펭귄1 날개 : ", 펭귄1.날개갯수, ", 날수있나? ", 펭귄1.날수있나); // 2, true
펭귄1.날수있나 = false;
console.log("다시 물어본다. 펭귄1은 날 수 있나? :", 펭귄1.날수있나); // false

5L : 날개가 2개, 날 수 있는 참새 1 이 있습니다.
13L : 참새 1을 프로토타입으로 갖는 닭 1 이 생겼습니다. 여기서 주목할 점은 오른쪽이 참새(함수)가 아니라 참새 1(인스턴스)인 점입니다. 프로토타입 이론은 이미 존재하는 사물을 통해 범주화한다는 점에서 일치합니다
14L : 닭의 정의(10L)에는 날개개수가 없지만 2가 출력됩니다. 프로토타입 체인에 의해 참새 1의 속성에 접근했기 때문입니다.
15L : 닭 1 은 날 수 없다고 합니다. 닭 1은 날 수 없어도 프로토타입에 해당하는 참새 1 은 날 수 있습니다. (닭 1은 참새 1 프로토타입에서 좀 더 멀어졌습니다) 같은 속성을 변경해도 프로토타입 객체의 속성은 변경되지 않은 점에 주의
17L~25L : 고전적인 방식으로 프로토타입을 사용해 봤습니다. 프로토타입에선 객체 생성을 통해 확장한다는 부분이 좀 더 직관적으로 다가옵니다.

위 코드는 아래처럼 도식화할 수 있습니다.

닭 1의 원형(프로토타입)은 참새 1이다
닭 1에 없는 속성(날개개수)은 프로토타입 체인을 통해 참조된다
닭 1에 동일한 속성명(날 수 있나)을 추가해도 원형은 변하지 않는다(위임)
> 원리적으로는 닭 1을 통해 원형(prototype)을 변경하는 건 불가능해야 한다. 하지만 JS 에선 문법적으로 가능. (권장하지 않음)

자바스크립트의 어휘적 범위(lexical scope)

의미사용론에 따르면 단어의 의미는 그 어휘적인, 근처 환경에서의 의미가 됩니다.

이는 javascritp에서 다음처럼 적용됩니다.

변수의 의미는 그 어휘적인(Lexical), 실행 문맥(Excution Context)에서의 의미가 된다.

그렇기 때문에 실행문맥(context)의 모든 선언을 참고(호이스팅)해 의미를 정의합니다.

호이스팅은 자바스크립트의 대표적인 특징으로 면접단골 질문이기도 하죠

대부분 "코드가 로드될 때 선언부가 상단으로 끌어올려지는" 정도로 대답을 합니다.

틀린 대답은 아니지만 아쉽습니다. 좀 더 보태면 아래처럼 대답할 수 있겠네요

‘실행 콘텍스트 생성 시 렉시컬 스코프 내의 선언이 끌어올려지는 게 호이스팅이다'

"프로토타입 기반 언어인 자바스크립트에서는 ‘단어의 의미가 사용되는 근처 환경’에서의 ‘근처'를 어휘적인 범위(Lexical Scope)로 정의했습니다. 자바스크립트 엔진은 코드가 로드될 때 실행 콘텍스트를 생성하고 그 안에 선언된 변수, 함수를 실행 콘텍스트 최상단으로 호이스팅 합니다. 이러한 범위를 렉시컬 스코프라 합니다."

// 전역 실행문맥 생성. 전체 정의(name, init) 호이스팅
var name = 'Kai';
init(); // init 실행문맥 생성. 내부 정의(name, displayName) 호이스팅
function init() {
    var name = "Steve";
    function displayName() {  
      console.log(name); // 현재 실행문맥 내에 정의된게 없으니 outer 로 chain
      // var name = 'troll?'; // 주석 해제되면 호이스팅
    }
    displayName(); // displayName 실행문맥 생성. 내부 정의 호이스팅.
}

- 2L: 코드가 로드될 때 전역 실행문맥(Execution Scope)이 생성됩니다. 전역의 선언부를 모두 호이스팅 하게 되는데 여기선 2L의 name과 4L의 init이 렉시컬 스코프에 들어갑니다.

- 3L: 렉시컬 스코프 상에 4L에 init 함수가 존재하니 에러 없이 실행할 수 있습니다. 코드 로딩 시점에 init 함수를 타고 들어가 실행 문맥을 생성

- 4L: init 함수에 대한 렉시컬 스코프를 생성 name과 displayName이 들어옵니다.

- 6L-9L: displayName 실행 문맥 내에 name이라 선언된 것이 없음. 이렇 때 Scope Change을 통해 상위 콘텍스트로 위임

코드를 로드하게 되면 아래와 같은 구조가 생성됩니다.

- Global Execution // 1
   - Lexical : name, init 
- Execution : init // 2
   - Lexical : name, displayName
   - Outer : global 
- Execution : displayName // 3
   - Lexical : null
   - Outer : init

중요한 것은 자바스크립트의 동작방식보다, 프로토타입 언어인 자바스크립트에

도대체 왜 "실행 문맥", "렉시컬 스코프", "호이스팅"이 존재하는가입니다.

"왜?"를 이해한다면 이러한 것들은 더 이상 암기과목이 아닙니다.

앞서 말했듯이 프로토타입 철학의 근원인 비트겐슈타인류에서 가장 중요하게 생각하는 것이 있다면

"어휘"이고 이것은 "문맥" 내에서만 의미를 가진다는 것이 핵심입니다.

이 핵심을 자바스크립트에서 구현하기 위해 자연스럽게 발생할 특징임을 이해한다면 더 이상 외울 필요가 없게 됩니다.

자바스크립트의 this

자바스크립트의 또 다른 특징은 this이죠,

클래스 기반객체지향 언어에서의 this와는 완전히 다른 동작을 합니다.

대부분의 문서에선 Case by case로 this가 가리키는 객체를 설명합니다.

이런 식의 접근보단 프로토타입 관점에서 이해하고 왜 javascript에서 this가 요 모양인지 이해한다면

매력적인 요소로 다시 느끼게 될 수 있을 겁니다.

this에 대한 대표적인 오해들

- this는 기본적으로 window다

- 이벤트 리스너에 등록한 콜백의 this는 내부 bind 등을 통해 바뀌기 때문에 무엇인지 알 수 없다

- this는 외워야 한다.

이러한 오해들을 바로잡기 위해선 먼저 프로토타입 철학에서 이런 상황을 어떻게 해석하는지에 대해 알 필요가 있습니다.

비트겐슈타인은 쓰임새가 곧 의미라는 점을 강조했습니다.(의미사용론)

"대상"에 따라서 같은 단어도 의미가 달라진다는 얘기입니다.

이것이 바로 프로토타입과 클래스의 대표적인 차이라고 볼 수 있습니다.

단어를 바라보는 방식이며 중요한 세계관의 차이입니다.

미리 분류하고 정의한 클래스를 중요하게 여기는 방식 vs 주체와 문맥을 중요하게 여기는 방식

프로그래밍으로 보자면 실행(invoke)하는 "객체"가 중요하다는 의미입니다.

이것이 프로토타입 기반의 언어인 자바스크립트에서 this가 클래스 기반 언어들과 다르게 동작하는 이유입니다.

javascript에선 this가 정의된 함수가 어떻게 발화(invoke) 되었는지에 따라 가리키는 값이 달라집니다.

정확히는 받아들이는 대상의 컨텐스트를 가리킵니다.

이를 이해하려면 먼저 메서드와 메시지를 명확하게 알아야 합니다.

메소드 : 객체의 함수
메시지 : 메서드를 실행하라는 메시지 전달

자바에선 클래스의 메서드를 호출하는 것을 메시지라고 합니다.

자바스크립트를 예로보면 foo라는 객체가 있고 그 내부에 bar()이라는 함수가 있을 때 다음처럼

invoke 할 객체를 지정할 수 있습니다.

foo.bar()
bar.call(foo)
var boundBar = bar.bind(foo)

위처럼 foo 객체를 통해 invoke 된 함수는 내부 this가 무조건 foo를 가리키게 됩니다.

만약 아무것도 지정된 게 없으면 global(브라우저는 window)을 가리키겠죠?

var someValue = 'hello';
function outerFunc() {
    console.log(this.someValue); // 첫번째 : ?, 두번째 : ?
    this.innerFunc();
}
const obj = {
    someValue : 'world',
    outerFunc,
    innerFunc : function() {
        console.log("innerFunc's this : ", this); // 첫번째 : ?, 두번째 : ?
    }
}
obj.outerFunc(); // 첫번째
outerFunc(); // 두번째

3L : 13L 에서 호출한 첫 번째는 world가, 14L 에서 호출한 두 번째는 hello 가 찍힙니다. outerFunc 가 누구를 통해 발화되었는지를 알면 this 가 무엇이 될지 알 수 있습니다
4L : obj를 통해 발화되면 innerFunc 가 존재하기 때문에 호출되지만, 글로벌에서 발화되면 innerFunc 가 없기 때문에 에러가 납니다
10L : this 가 이중으로 들어가 있어 헷갈릴 수 있는데 복잡하지 않습니다. this(obj)를 통해 발화했기 때문에 첫 번째는 obj 가 됩니다.

13L의 obj.outerFunc 호출 상황을 그림으로 표현하면 아래와 같습니다.

시작 : 자바스크립트 엔진이 코드를 실행합니다. (브라우저에서 use strict 모드가 아닌 경우 this는 window를 가리킵니다)
1번 : 코드의 13L을 만나면 엔진은 obj에 outerFunc를 실행하라는 메시지를 보냅니다.
2번 : obj에서 outerFunc를 발화합니다. 코드 로드 시 만들어져 있는 실행문맥을 참고해 실행합니다. 이때 실행 문맥상의 this는 발화한 obj를 가리킵니다.
3번 : 실행 중에 this.innerFunc를 만납니다. 엔진은 this 가 가리키는 obj에 innerFunc 를 실행하라는 메시지를 보냅니다.
4번 : obj 에 innerFunc 이 선언되어 있으니 잘 실행합니다

14L의 outerFunc 호출 상황을 그림으로 그려보면 아래와 같습니다.

1번 : 코드의 14L을 만나면 엔진은 자신(global)의 실행문맥상에 존재하는 outerFunc을 호출합니다.
2번 : 발화한 지점이 엔진(global)이니 this는 엔진을 가리킵니다. 엔진에 innerFunc을 실행하라는 메시지를 보냅니다
3번 : 글로벌 실행문맥에는 innerFunc 이 없기 때문에 에러가 납니다

흔히 사용하는 이벤트핸들러를 기준으로 예시를 하나 더 들어 봅시다.

function handle() {   
    console.log(this);  // 첫번째 ?, 두번째 ? 
}  
document
    .getElementsByTagName('body')[0]
    .addEventListener('click', handle);  // 첫번째. 호출되었다고 가정.
handle();  // 두번째. 첫번째 이후에 호출되었다고 가정.

다시 한번 강조하지만 this를 발화 지점 기준으로 생각하면 헷갈리지 않습니다.

addEventListener 함수는 해당 엘리먼트에 콜백을 등록하는 함수입니다.
간단하게 얘기하면 ‘div’ 객체에 ‘handle’ 메서드를 등록했다고 볼 수 있죠.

1번 : 브라우저에서 div를 클릭하면 엔진이 반응합니다
2번 : 해당 엘리먼트(div)에 등록된 event listener 들을 실행하라는 메시지를 보냅니다
3번 : div 엘리먼트에서 handle을 발화합니다.
4번 : 이때 handle의 실행문맥의 this는 발화한 div 를 가리킵니다.

보너스로 넣은 문제도 있습니다.

var value = 1;

var obj = {
  value: 100,
  foo: function() {
    setTimeout(function() {
      console.log("callback's this: ",  this);  // ?
      console.log("callback's this.value: ",  this.value);  // ?
      function bar() {
        console.log("bar's this: ", this);  // ?
      }
      bar();
    }, 1000);
  }
};

obj.foo();

this 는 무엇이 될까요?

7L : 브라우저 라면 window를 가리킵니다. 하지만 node.js 라면? 재밌게도 Timer 란 객체를 가리킵니다. setTimeout에 대한 구현이 다른 거죠. node.js 에서는 setTimeout 시 Timer 객체에 등록하고 해당 tick 이 되면 Timer에 실행하라는 메시지를 보내나 봅니다. 중요한 점은, 같은 코드여도 돌아가는 엔진마다 다를 수 있다는 의미인 것 같습니다.

8L : 브라우저라면 1, node.js 라면 undefined 가 나옵니다. 기본 this 는 global 라고 외우면 안되는 이유입니다

9L : 당연하게도 브라우져라면 window, node.js 면 global을 가리킵니다. 엔진이 어떤 방식으로 실행했는지를 기억하시면 됩니다.

마무리

프로토타입은 "클래스"의 다른 구현이 아닌 완전히 새로운 철학하에 만들어진 이론입니다.

이러한 차이점을 이해한다면 더 이상 호이스팅, this, 렉시컬 스코프 등은 암기 과목이 아니게 됩니다.

자바스크립트는 class, arrow function, let, const 등 여타 일반적인 언어와 보편성을 맞추고 있고,

이것들을 정말 편하게 사용 중이기도 합니다.

하지만 언어의 근본(프로토타입)은 변하지 않습니다.

이것들은 언어적 지원이 아닌 syntactic sugar인 부분도 언어의 근본적 구조가 다르기 때문을 이해할 수 있게 되면 좋겠습니다.

출처

https://medium.com/@limsungmook/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%8A%94-%EC%99%9C-%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85%EC%9D%84-%EC%84%A0%ED%83%9D%ED%96%88%EC%9D%84%EA%B9%8C-997f985adb42

SAA/2024-09-18

hmk run dev — Wed, 18 Sep 2024 18:57:53 +0900

고가용성이란?

사용자 서비스를 요청할 때 언제든 서비스할 수 있는 특성으로 이중화를 하여 설계된다.

ex) 모든 single point component 장애 시에 대응하기 위해서 설계되었다.

높은 가용성을 제공하기 위해 컴퓨터 자원을 몇 개의 Availabilty Zone이 제공되어야하는가?

최소 한 개이상

모든 고객들은 낮은 latency를 요규하기 때문에 AWS에서 지원할 수 있는 것은?

High availablity

-> latency 즉 패킷의 출발지점부터 도착지까지의 시간을 줄이기 위해 고가용성( High availablity)을 제공해야한다.

AWS 클라우드의 멀티 리전의 예제는?

Agility(민첩성)

-> aws의 다중 리전 애플리케이션은 내결함성이 뛰어나며 장애 발생 시에 백업 리전으로 간편하고 빠르게 장애를 해결함

AWS 리전, 가용 영역, 엣지 로케이션에 대한 설명으로 올바른 것은?

리전에 가용 영역이 포함되어 있다.

-> 리전은 물리적 위치이고 가용 영역은 리전 내에 논리적 센터

On-Demand 비용보다 예약 인스턴스 가격 모델이 평균적으로 비용을 줄이는 것은?

Three-year, All Upfront Standard RI pricing

-> RI(Reserved Instance)는 예약 인스턴스를 의미하고 3년간 모두 선결제(All Upfront) 하는 것이 가장 저렴하다.

시스템의 성능을 제공하고 사용자들의 비용을 절감할 수 있도록 AWS 환경을 조사하여 기회를 찾아 제공하는 AWS 서비스는?

AWS Cost Explorer

-> 비용 데이터를 가시화하여 각종 차트로 분석할 수 있게 한다.

On-Premise의 TCO와 AWS TCO를 비교할 때 포함해야 하는 비용은?

Project Management

-> TCO(Total Cost Ownership)는 총 비용을 의미하는 것으로 프로젝트 관리 비용도 포함되어야 한다.

전통적이고 가상화된 데이터 센터와 AWS를 비교해서 AWS의 비용적 효과는?

낮은 가변적 비용과 낮은 선불 비용

-> AWS는 비용 변화의 요소가 적고 이상적으로 비용이 변화하면 기계학습을 통해서 이상 감지하여 클라우드 서비스 사용자에게 알려준다.

또한 모든 비용을 예약비용으로 할 때 비용이 절감되면, 이때 선불로 모두 지불하는 것이 가장 비용이 절감된다.

Amazon EC2 인스턴스의 가격 모델에서 90% 정도의 금액을 절감할 수 있는 것은?

스폿 인스턴스

-> 스폿 인스턴스라는 것은 아마존이 구매한 서버 중 사용자가 없는 서버를 낮은 비용으로 경매하여 제공하는 것이다.

따라서 비용 절감 효고가 가장 크다.

AWS EC2 가격 모델 중 고개들의 Server bound software licenses가 있는 경우 어느 것을 사용해야 하나?

전용 호스트

-> Server bound software licenses라는 것은 서버와 관련한 전용 라이선스가 있다는 것이고, 이때는 전용 호스트를 사용

기업은 AWS의 어떤 기능 또는 서비스를 사용해서 상세 수준의 지출을 추적하고 서비스 할 수 있는가?

AWS Budgets

-> AWS Budgets는 유동적인 예상 및 예측 기능을 사용해 비용계획을 수립하거나 관리함

AWS Cloudtrail은 AWS 계정에 대한 규정 준수, 운영, 위험을 감시하는 서비스로 사용자 AWS 서비스에 대해서 수행한 작업은

Cloudtrail의 이벤트에 모두 기록도니다. 기록되는 이벤트는 AWS SDK 및 API 호출 등이다.

AWS 모범사례에 따라 AWS에서 개발되는 애플리케이션은 어떻게 생성해야 하는가?

소프트웨어 설계 원칙은 약결합(느슨한 결합) 시스템으로 구성해야한다. 약결합 시스텝이란 각 애플리케이션의 독립성은 향상시키고 애플리케이션 간의 관련성은 낮추는 설계방법이다.

AWS 리전을 선택할 때 고려해야할 사항

가격, 서비스 가용성 및 규정 준수, 지연시간

리전은 가용 영역들의 묶음이고 가용 영역은 데이터센터의 묶음이다

AWS 리전은 고가용성을 위해 가용 영역의 클러스터이고 가용 영역은 데이터 센터의 클러스터이다.

리전은 지역 단위의 큰 그룹입니다. (예: 서울, 도쿄, 뉴욕)
가용 영역은 그 지역 안에 있는 작은 그룹들입니다. 가용 영역 하나는 여러 데이터 센터로 이루어져 있습니다.
AWS는 이렇게 지역을 나누고 그 안에 물리적으로 분리된 데이터 센터들을 묶어서 고가용성(장애에 대비해 시스템을 계속 운영할 수 있는 능력)을 보장합니다.

즉, 리전은 여러 가용 영역이 모인 큰 그룹이고, 가용 영역은 실제 데이터 센터가 모여 있는 작은 그룹이라고 보면 됩니다.

탄력성이란 비즈니스 수요에 맞추어 서비스를 빠르게 생성하고 확장할 수 있는 것

고가용성을 달성하기 위해서 몇 개의 가용영역에 컴퓨팅 리소스를 제공해야 하는가?

최소 2개

- 클라우드 AWS 자격증으로 시작하기 69p

AWS Certified Solutions Architect - Associate(SAA) 오답 및 해설 2024-09-08

hmk run dev — Sun, 8 Sep 2024 15:43:12 +0900

한 회사에서 새 Amazon EC2 인스턴스에 새 데이터베이스를 배포하고 있습니다. 이 데이터베이스의 워크로드에는 최대 20,000IOPS를 지원할 수 있는 단일 Amazon Elastic Block Store(Amazon EBS) 볼륨이 필요합니다.

이 요구 사항을 충족하는 EBS 볼륨 유형은 무엇인가요?

문제는 이런 상황이에요:

당신은 웹 애플리케이션에서 새로운 서버를 세팅해서, 데이터베이스를 연결하려고 해요. 근데, 이 데이터베이스가 데이터를 빠르게 읽고 쓰기 위해서 엄청나게 많은 처리량(최대 20,000 IOPS)이 필요해요. 여기서 IOPS는 초당 입력/출력 작업 수를 말하는데, 쉽게 말해 데이터에 얼마나 빨리 접근할 수 있는지를 나타내요.

선택지 설명:

프로비저닝된 IOPS SSD (정답):
- 최고 성능을 낼 수 있는 드라이브라고 생각하면 돼요. 64,000 IOPS까지 지원되니까, 당신이 요구하는 20,000 IOPS를 충분히 만족시켜요. 고성능 데이터 처리에 적합한 옵션이에요.
- **프로비저닝(provisioning)**은 쉽게 말해 필요한 리소스를 미리 준비해 놓는 것을 뜻해요. 컴퓨팅 리소스, 저장소, 네트워크 등 필요한 자원을 사전에 할당하는 개념이죠.
처리량 최적화 HDD:
- 이건 느려요. 500 IOPS밖에 안 돼서, 요구사항인 20,000 IOPS와는 거리가 멀어요. 대용량 데이터를 천천히 처리하는데 적합해요.
범용 SSD:
- 범용 SSD는 보통 수준의 성능을 제공해요. 최대 16,000 IOPS까지 지원하지만, 문제에서 필요한 20,000 IOPS를 못 따라가요. 일반적인 작업에 적합하지만, 고성능이 필요한 상황에선 부족해요.
콜드 HDD:
- 이건 저비용의 느린 스토리지에요. 거의 사용하지 않는 데이터를 저장해두는 용도로 적합해요. IOPS보다는 대용량 파일을 저장하는 데 초점이 맞춰져 있어요.

요약:

당신의 데이터베이스는 빠른 속도로 많은 양의 데이터를 처리해야 하니까, 가장 빠르고 강력한 성능을 제공하는 프로비저닝된 IOPS SSD가 정답이에요.

한 회사에서 솔루션스 아키텍트에게 기존 온프레미스 애플리케이션에 대한 파일럿 라이트 재해 복구(DR) 전략을 구현하도록 요청합니다. 애플리케이션은 독립적으로 실행되며 데이터베이스에 액세스할 필요가 없습니다.

다음 중 파일럿 라이트 DR 전략을 구현하는 솔루션은 무엇입니까?

이 문제에서 정답은 B. Amazon EC2 인스턴스를 사용하여 AWS에 애플리케이션 호스팅 환경을 다시 생성하고 EC2 인스턴스를 중지하는 옵션입니다. 파일럿 라이트 DR 전략과 다른 선택지가 왜 오답인지 쉽게 풀어서 설명해볼게요.

정답:

B. Amazon EC2 인스턴스를 사용하여 AWS에 애플리케이션 호스팅 환경을 다시 생성하고 EC2 인스턴스를 중지

파일럿 라이트 DR 전략의 핵심은 AWS에 미리 중요한 인프라를 준비해 두고, 평소에는 최소한의 리소스만 실행시키며, 문제가 발생할 때만 전체 시스템을 가동하는 방식이에요.
즉, 미리 AWS에 애플리케이션 환경을 설정해두고, 장애가 생기면 EC2 인스턴스를 빠르게 켜서 애플리케이션을 정상적으로 돌리면 돼요. 복구 시간도 짧고, 비상시에만 자원을 사용해서 비용도 절감할 수 있어요.

오답:

A. 온프레미스 애플리케이션, 구성 및 데이터를 Amazon S3 버킷에 백업

이건 백업 및 복원 DR 전략이에요. S3에 데이터를 백업하는 건 좋지만, 장애가 발생하면 AWS에서 새 환경을 구축하고 데이터를 복원하는 데 시간이 오래 걸려요. 복구 시간이 몇 시간에서 며칠 걸릴 수 있어요. 비용은 적지만 속도가 느려서 긴급 상황에 적합하지 않아요.

C. EC2 인스턴스에서 애플리케이션 트래픽의 10%를 처리

이건 웜 스탠바이 DR 전략이에요. 이미 AWS에서 애플리케이션의 일부 트래픽을 처리하고 있어서 장애가 발생하면 바로 전체 트래픽을 AWS로 넘길 수 있지만, 리소스가 계속 실행 중이라 비용이 높아요. 파일럿 라이트보다는 비용이 더 들지만 복구는 빠릅니다.

D. 온프레미스 환경을 다시 구축하고 S3에서 복원

이 역시 백업 및 복원 DR 전략이에요. 온프레미스 인프라를 다시 설정하고 S3에서 데이터를 복원하는 건 시간이 오래 걸려요. 온프레미스 환경에서 복구하는 데 시간이 많이 소요되므로 긴급한 상황에서는 부적합해요.

요약:

파일럿 라이트 DR 전략은 AWS에 미리 애플리케이션을 설정해 두고, 문제가 생기면 빠르게 가동하는 방법이에요. 필요한 리소스만 최소한으로 유지하면서도, 빠르게 복구할 수 있어서 비용 절감과 속도를 모두 고려한 방식입니다.

엄격한 데이터 보호 요구 사항이 있는 한 회사가 있습니다. 솔루션스 아키텍트는 인터넷에서 백엔드 Amazon RDS DB 인스턴스에 액세스할 수 없도록 VPC에 대한 보안을 구성해야 합니다. 또한 솔루션스 아키텍트는 애플리케이션 티어에서 지정된 포트를 통해서만 DB 인스턴스에 액세스할 수 있는지 확인해야 합니다.

솔루션스 아키텍트는 이러한 요구 사항을 충족하기 위해 어떤 조치를 취해야 하나요? (정답은 2개입니다.)

이 문제의 정답은 A. DB 인스턴스를 프라이빗 서브넷에 배치와 E. 애플리케이션 티어의 요청을 허용하는 인바운드 규칙을 설정입니다. 이제 각각의 이유와 다른 선택지가 왜 오답인지 쉽게 설명해볼게요.

정답:

A. DB 인스턴스에 대한 프라이빗 서브넷만 포함하는 DB 서브넷 그룹을 지정

프라이빗 서브넷은 인터넷과 연결되지 않은 내부 네트워크 공간이에요. 데이터베이스를 프라이빗 서브넷에 배치하면 외부에서 직접 접근할 수 없게 되기 때문에, 보안이 강화돼요. 인터넷으로부터 DB를 보호하는 첫 번째 조치입니다.

E. 애플리케이션 티어의 보안 그룹에서 특정 포트를 통한 인바운드 요청 허용

보안 그룹은 네트워크의 방화벽 역할을 해요. 여기서는 데이터베이스 포트에 대해서만 애플리케이션 티어에서 들어오는 요청을 허용하고, 그 외의 트래픽은 차단하는 방식으로 설정해요. 이를 통해 애플리케이션에서만 DB에 접근할 수 있게 하고, 허용되지 않은 트래픽을 막아 보안을 강화할 수 있어요.

오답:

B. 프라이빗 IPv4 주소를 사용한 탄력적 네트워크 인터페이스 연결

**탄력적 네트워크 인터페이스(ENI)**는 네트워크 설정을 유연하게 변경할 수 있게 도와주는 도구이지만, 여기서는 DB 인스턴스를 보호하는 방법과 직접적인 관련이 없어요. 네트워크 카드와 관련된 기능일 뿐, DB 보안을 크게 향상시키지 않습니다.

C. VPC에서 AWS Shield를 구성하고 서브넷의 라우팅 테이블 업데이트

AWS Shield는 DDoS(분산 서비스 거부) 공격을 막는 서비스지만, 라우팅 테이블과 관련된 설정은 이 문제에서 요구하는 데이터베이스 보안과는 거리가 있어요. DDoS 공격에 대한 보호는 DB 액세스 제어와 관련이 없어요.

D. Direct Connect 연결 구성

AWS Direct Connect는 온프레미스 데이터 센터와 AWS 클라우드 간에 전용 네트워크 연결을 제공하는 서비스에요. 하지만 문제에서는 애플리케이션과 DB 간의 액세스 제어에 대해 묻고 있으며, Direct Connect는 여기서 요구하는 보안 문제와 관련이 없어요.

요약:

프라이빗 서브넷에 DB를 배치하면 외부에서 접근할 수 없어서 보안이 강화됩니다.
보안 그룹 규칙을 통해 애플리케이션 티어만 DB에 접근할 수 있도록 특정 포트를 제한하면 보안이 더 높아져요.

이 두 가지 조치가 인터넷 접근 차단과 애플리케이션만 접근 가능하도록 제한하는 보안 요구 사항을 충족시키는 방법입니다.

한 회사에서 Amazon CloudFront 배포를 위한 원본으로 구성된 Application Load Balancer를 사용하여 Amazon EC2 인스턴스에서 웹 사이트를 실행합니다. 이 회사는 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격으로부터 보호하려고 합니다.

이러한 요구 사항을 충족하기 위해 솔루션스 아키텍트가 추천해야 하는 접근 방식은 무엇인가요?

이 문제에서 정답은 D. CloudFront 배포에서 AWS WAF를 설정하고 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격을 차단하는 조건 및 규칙을 사용입니다. 각 선택지가 왜 정답 또는 오답인지 자세히 설명해볼게요.

정답:

D. CloudFront 배포에서 AWS WAF를 설정하고 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격을 차단하는 조건 및 규칙을 사용

**AWS WAF(Web Application Firewall)**는 웹 애플리케이션을 보호하는 데 사용되는 서비스로, **크로스 사이트 스크립팅(XSS)**이나 SQL 삽입과 같은 악의적인 공격을 감지하고 차단할 수 있어요.
WAF를 CloudFront와 함께 사용하면, 웹 트래픽을 필터링하고 보안 규칙을 설정하여 이런 종류의 공격을 방어할 수 있습니다.
따라서, WAF를 사용해 해당 요구 사항을 가장 잘 충족시킬 수 있어요.

오답:

A. AWS Shield Advanced를 활성화하고 CloudFront 배포를 보호된 리소스로 나열

AWS Shield Advanced는 DDoS(분산 서비스 거부) 공격으로부터 보호하는 서비스입니다. 하지만 **크로스 사이트 스크립팅(XSS)**이나 SQL 삽입 공격을 방어하지는 않아요.
Shield는 트래픽 볼륨을 기반으로 한 공격에 집중하기 때문에, XSS나 SQL 삽입 같은 애플리케이션 계층의 공격에는 적합하지 않습니다.

B. AWS Firewall Manager에서 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격을 차단하도록 AWS Shield Advanced 정책을 정의

AWS Firewall Manager는 여러 계정과 리소스에서 WAF, Shield Advanced 등을 중앙에서 관리할 수 있는 도구예요. 그러나 여기서도 Shield Advanced는 DDoS 방어에만 집중하므로 XSS나 SQL 삽입에 대한 방어는 제공하지 않습니다.
따라서 Firewall Manager 자체는 이런 요구 사항을 해결하지 못해요.

C. EC2 인스턴스에 AWS Firewall Manager를 배포하고 크로스 사이트 스크립팅 및 SQL 명령어 삽입 공격을 차단하는 조건 및 규칙을 생성

AWS Firewall Manager는 AWS 관리형 서비스로, EC2 인스턴스에 설치하는 방식이 아닙니다. 또한 Firewall Manager는 AWS WAF나 Shield Advanced 같은 도구를 관리하는 용도이기 때문에, 이 방식으로는 직접적인 보안을 제공할 수 없어요.
이 옵션은 기술적으로 잘못된 방식입니다.

요약:

AWS WAF는 크로스 사이트 스크립팅(XSS) 및 SQL 삽입 공격을 막을 수 있는 도구로, 문제의 요구 사항을 가장 적절하게 충족합니다.
다른 서비스들, 특히 AWS Shield Advanced는 주로 DDoS 공격 방어에 초점을 맞추고 있어, 애플리케이션 계층에서 발생하는 보안 문제(예: XSS, SQL 삽입)를 해결하는 데 적합하지 않습니다

한 회사가 EC2 Auto Scaling 그룹의 일부인 대규모 범용 Amazon EC2 인스턴스 유형에서 실행되는 애플리케이션을 보유하고 있습니다. 이 회사는 이 애플리케이션과 관련된 향후 비용을 줄이려고 합니다. 회사는 Amazon CloudWatch의 지표와 로그를 검토한 후, 애플리케이션이 무작위로 하루에 수회 실행되어 데이터를 검색하고 관리한다는 사실을 알게 되었습니다. CloudWatch에 따르면 각 요청의 최대 런타임은 10분이고 메모리 사용량은 4GB이며 인스턴스는 항상 실행 상태입니다.

이 문제에서 가장 비용을 절감할 수 있는 솔루션은 B. 애플리케이션 코드를 리팩터링하여 AWS Lambda 함수로 실행입니다. 각 선택지에 대해 설명해 드릴게요.

정답:

B. 애플리케이션 코드를 리팩터링하여 AWS Lambda 함수로 실행합니다.

AWS Lambda는 서버리스 컴퓨팅 서비스로, 요청이 있을 때만 실행되며 실행 시간이 끝나면 자동으로 종료됩니다. 이 애플리케이션은 짧은 시간 동안 불규칙하게 실행되므로, 항상 실행 상태인 EC2 인스턴스를 사용하는 것보다 Lambda로 리팩터링하면 비용을 크게 절감할 수 있습니다. Lambda는 필요한 만큼만 실행되기 때문에 EC2 인스턴스 상시 실행으로 발생하는 불필요한 비용을 절감할 수 있습니다.

오답:

A. 용량 확장이 가능한 대규모 EC2 인스턴스에 애플리케이션을 배포합니다.

EC2 인스턴스는 항상 실행 상태여야 하므로 비용 절감에 효과적이지 않습니다. 사용량이 불규칙한 경우에는 EC2 인스턴스 상시 실행이 불필요한 비용을 초래할 수 있습니다.

C. Amazon Elastic Kubernetes Service(Amazon EKS)를 사용하여 애플리케이션을 컨테이너화합니다. EC2 인스턴스에서 컨테이너를 호스팅합니다.

EKS는 애플리케이션을 컨테이너화할 수 있지만, EC2 인스턴스가 상시 실행되어야 하므로 비용 절감에는 적합하지 않습니다. 이 경우 컨테이너화로 얻는 이점이 크지 않고, 서버리스 아키텍처가 더 나은 선택입니다.

D. AWS Instance Scheduler를 사용하여 로그의 런타임을 기반으로 인스턴스를 시작 및 중지합니다.

Instance Scheduler는 미리 정의된 시간에 맞춰 인스턴스를 시작/중지하는 방식이므로, 무작위로 실행되는 애플리케이션에는 적합하지 않습니다. 이 솔루션은 정확한 실행 시간을 예측할 수 없을 때 효과적이지 않으며, 인스턴스를 너무 자주 시작/중지하면 비용 절감 효과가 미미할 수 있습니다.

요약:

Lambda는 필요할 때만 실행되고 짧은 실행 시간에 적합한 서버리스 서비스이기 때문에, 이 시나리오에서 비용을 가장 절감할 수 있습니다.

한 회사에서 애플리케이션 계층과 온라인 트랜잭션 처리(OLTP) 관계형 데이터베이스로 구성될 새 애플리케이션을 배포하고 있다. 이 애플리케이션은 항상 사용 가능해야 한다. 하지만 애플리케이션에는 예측할 수 없는 트래픽 패턴이 존재할 수 있다. 회사는 이러한 유휴 기간 동안 발생하는 컴퓨팅 비용을 최소화하고자 한다.

다음 중 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇인가?

이 문제에서 가장 비용 효율적인 솔루션은 D. AWS Fargate에서 Amazon Elastic Container Service(Amazon ECS)를 사용하는 컨테이너를 통해 애플리케이션을 실행한다. 데이터베이스에 Amazon Aurora Serverless를 사용한다입니다.

정답:

D. AWS Fargate에서 Amazon ECS를 사용하는 컨테이너를 통해 애플리케이션을 실행하고, 데이터베이스에 Amazon Aurora Serverless를 사용합니다.

AWS Fargate는 서버리스 컨테이너 서비스로, 애플리케이션이 실행 중일 때만 리소스를 사용하므로, 유휴 상태일 때 발생하는 비용을 최소화할 수 있습니다.
Amazon Aurora Serverless는 자동으로 확장하고, 유휴 상태일 때는 비용이 발생하지 않으므로, 트래픽 패턴이 예측 불가능한 환경에서도 효율적인 비용 관리가 가능합니다. 이 솔루션은 필요할 때만 리소스를 사용하고, 유휴 시간에는 비용을 줄일 수 있기 때문에 비용 효율적입니다.

**ECS (Amazon Elastic Container Service)**는 AWS에서 제공하는 컨테이너 오케스트레이션 서비스입니다. ECS를 사용하면 컨테이너화된 애플리케이션을 쉽게 배포, 관리, 확장할 수 있습니다. 사용자가 관리하는 EC2 인스턴스 또는 AWS에서 제공하는 서버리스 방식으로 컨테이너를 실행할 수 있습니다.

Fargate는 ECS나 EKS에서 컨테이너를 실행할 때, 서버를 관리할 필요 없이 자동으로 리소스를 할당하는 서버리스 컴퓨팅 엔진입니다. 즉, 인프라 관리 없이 애플리케이션의 컨테이너만 실행하면 되며, AWS가 필요한 컴퓨팅 자원을 자동으로 관리해줍니다. 이를 통해 유휴 리소스 비용을 줄이고, 서버 관리 부담을 덜 수 있습니다.

오답:

A. 버스트 가능 인스턴스 유형을 사용하여 Amazon EC2 인스턴스에서 애플리케이션을 실행한다. 데이터베이스에 Amazon Redshift를 사용한다.

EC2 버스트 가능 인스턴스는 트래픽이 증가할 때만 성능이 일시적으로 향상되지만, 트래픽이 적을 때도 유휴 리소스 비용이 발생합니다. 또한, Amazon Redshift는 OLTP 용도가 아닌 OLAP(온라인 분석 처리)에 최적화되어 있어 적합하지 않습니다.

B. AWS CloudFormation을 사용하여 Amazon EC2 인스턴스에 애플리케이션과 MySQL 데이터베이스를 배포한다. 유휴 기간이 시작될 때 인스턴스를 삭제한다.

CloudFormation은 인프라를 자동으로 관리할 수 있지만, 유휴 상태에서 인스턴스를 삭제하는 것은 항상 사용 가능해야 하는 요구 사항에 부합하지 않으며, 데이터베이스 삭제 시 데이터 손실 위험이 있습니다.

C. Application Load Balancer 기반의 Auto Scaling 그룹에 속한 Amazon EC2 인스턴스에서 애플리케이션을 배포한다. 데이터베이스에 Amazon RDS for MySQL을 사용한다.

이 솔루션은 Auto Scaling을 통해 트래픽에 따라 인스턴스를 동적으로 조정할 수 있지만, 항상 최소한 하나의 EC2 인스턴스와 RDS 인스턴스가 실행되어야 하므로 유휴 시간 동안 비용 절감이 어렵습니다.

요약:

AWS Fargate와 Amazon Aurora Serverless 조합은 트래픽 변화에 유연하게 대응할 수 있으며, 유휴 상태에서는 비용이 거의 발생하지 않으므로 비용 효율성 면에서 가장 적합한 선택입니다.

단점으로 Cold Start Latency (냉시작 지연), 비용 예측의 어려움, 컨테이너 상태 관리, 데이터베이스 연결 제한 등이 있을 수 있음

한 회사가 Amazon EC2 기반 MariaDB 데이터베이스를 Amazon RDS로 전환하고 있다. 이 회사는 자사의 CPU 및 메모리 요구 사항을 충족할 데이터베이스 인스턴스 유형을 이미 파악했다. 데이터베이스는 최소 40GiB의 스토리지 용량과 1,000IOPS를 제공해야 한다.

다음 중 가장 비용 효율적인 Amazon RDS for MariaDB 인스턴스 스토리지 구성은 무엇인가?

여기서 주어진 요구 사항에 맞는 가장 비용 효율적인 Amazon RDS for MariaDB 인스턴스 스토리지 구성은 다음과 같습니다:

정답: B

RDS 인스턴스에 50GiB의 범용 SSD(gp3) 스토리지를 프로비저닝한다.

이유:

범용 SSD(gp3) 스토리지는 IOPS를 볼륨 크기와 관계없이 3,000 IOPS를 지원합니다.
이 스토리지 타입은 IOPS와 스토리지 용량의 관계가 단순하여 예측 가능한 비용을 제공합니다.
비용 효율적으로 높은 IOPS를 지원하며, 필요한 1,000 IOPS를 초과하는 성능을 제공하면서도 추가 비용이 발생하지 않습니다.

오답 이유:

A (350GiB의 마그네틱 스토리지): 마그네틱 스토리지는 IOPS를 직접적으로 프로비저닝할 수 없으며, 성능이 일관되지 않아서 요구 사항을 충족할 수 없습니다.
C (334GiB의 범용 SSD(gp2) 스토리지): gp2는 IOPS가 볼륨 크기에 따라 비례하여 증가하며, 필요한 1,000 IOPS를 만족시키기 위해 334GiB의 스토리지가 필요합니다. 이는 gp3보다 더 비쌉니다.
D (1,000IOPS의 50GiB 프로비저닝된 IOPS 스토리지): 프로비저닝된 IOPS 스토리지는 IOPS를 정확히 제공하지만, gp3 스토리지보다 비용이 비쌉니다.

최소 5년 동안 데이터 레코드를 유지 관리해야 하는 한 회사가 있습니다. 데이터는 저장된 후에 거의 액세스되지 않습니다. 데이터는 2시간 이내에 액세스할 수 있어야 합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족할 수 있는 솔루션은 무엇인가요?

이 시나리오에서 요구 사항에 가장 적합한 솔루션은 Amazon S3와 S3 Glacier Instant Retrieval입니다.

정답: D

Amazon S3 버킷에 데이터를 저장하고 S3 수명 주기 정책을 사용하여 데이터를 S3 Glacier Instant Retrieval로 이동합니다.

이유:

Amazon S3는 데이터 저장을 위한 경제적이고 확장 가능한 기본 스토리지 솔루션을 제공합니다.
S3 Glacier Instant Retrieval은 데이터가 거의 액세스되지 않지만 2시간 이내에 액세스해야 하는 경우에 적합한 비용 효율적인 아카이브 스토리지 솔루션입니다.
이 조합은 데이터 보관과 접근 요구 사항을 충족하며, 비용을 최적화합니다.

오답 이유:

A (Amazon EFS와 AWS Direct Connect): Amazon EFS는 파일 시스템 접근을 필요로 할 때 유용하지만, 장기 데이터 보관과 비용 효율성 측면에서 S3보다 비쌉니다. AWS Direct Connect는 네트워크 연결을 위한 옵션일 뿐, 데이터 보관과는 직접적인 연관이 없습니다.
B (Amazon EBS와 스냅샷): EBS는 일반적으로 블록 스토리지로 사용되며, 스냅샷을 S3로 이동하더라도 EBS는 비용 효율적인 데이터 장기 보관 솔루션이 아닙니다. S3와 비교할 때 비싼 옵션입니다.
C (S3 Standard-IA): S3 Standard-IA는 데이터가 자주 액세스되지 않는 경우에 적합하지만, 더 긴 검색 시간이 필요한 경우에 비해 비용 효율적인 선택이 아닙니다. S3 Glacier Instant Retrieval이 이러한 요구 사항을 더 잘 충족합니다.

위성 이미지를 처리하는 한 회사에 AWS에서 실행되는 애플리케이션이 있습니다. 이 회사에서는 Amazon S3 버킷에 이미지를 저장합니다. 규정 준수를 위해 이 회사는 한 달에 한 번 모든 데이터를 온프레미스 위치로 복제해야 합니다. 회사에서 전송해야 하는 평균 데이터 양은 60TB입니다.

이 데이터를 전송하는 가장 비용 효율적인 방법은 무엇인가요?

위성 이미지를 온프레미스 위치로 전송하는 가장 비용 효율적인 방법은 AWS Snowball Edge Storage Optimized 디바이스를 사용하는 것입니다.

정답: A

기존 S3 버킷에서 AWS Snowball Edge Storage Optimized 디바이스로 매월 데이터를 내보냅니다. 그런 다음 온프레미스 위치로 디바이스를 배송하고 데이터를 전송합니다. 일주일 후에 디바이스를 반환합니다.

이유:

AWS Snowball Edge Storage Optimized는 대용량 데이터 전송을 위해 설계된 장비로, 60TB의 데이터를 경제적으로 전송하는 데 적합합니다.
Snowball Edge는 데이터 전송 비용을 줄이는 데 도움을 주며, 온프레미스 위치로 데이터를 직접 전송할 수 있어 비용을 절감할 수 있습니다.

오답 이유:

B (S3 버킷 복제와 AWS Storage Gateway File Gateway 사용): S3 버킷 복제는 추가 비용이 발생하며, AWS Storage Gateway는 온프레미스와 클라우드 간 데이터 전송에 대한 추가 비용이 발생할 수 있습니다. Snowball Edge는 이러한 전송과 관련된 비용을 줄일 수 있습니다.
C (S3 버킷 복제와 S3 데이터 전송): S3 Standard-IA 스토리지를 사용하는 새 버킷으로 복제한 후 온프레미스 위치로 전송하는 것은 추가 복제와 전송 비용이 발생하며, Snowball Edge는 이러한 복제와 전송을 효율적으로 처리할 수 있습니다.
D (CloudFront 배포): CloudFront는 데이터 전송을 위한 캐싱과 배포 네트워크를 제공하지만, 대량의 데이터를 온프레미스 위치로 전송하는 데 드는 비용이 Snowball Edge보다 훨씬 더 비쌀 수 있습니다.

Snowball Edge는 대량의 데이터 전송을 위한 경제적이고 효율적인 솔루션을 제공합니다.

한 회사가 하나의 AWS 계정을 사용하여 프로덕션 워크로드를 실행한다. 이 회사는 별도의 보안 팀용 AWS 계정을 가지고 있다. 보안 팀은 프로덕션 워크로드를 실행하는 AWS 계정의 특정 계정 설정 및 리소스 구성을 정기 감사 중에 확인해야 한다. 솔루션스 아키텍트는 AWS 보안 모범 사례를 따르는 솔루션을 설계하여 보안 팀에 필요한 액세스 권한을 제공해야 한다.

다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

정답: B 프로덕션 계정에 IAM 역할을 생성한다. 보안 팀에서 요구하는 권한을 제공하는 권한 정책을 연결한다. 보안 팀 계정을 신뢰 정책에 추가한다.

이유:

IAM 역할과 신뢰 정책을 사용하는 것은 AWS의 보안 모범 사례를 따릅니다. 이 접근 방식은 보안 팀이 필요할 때만 프로덕션 계정의 리소스에 접근할 수 있도록 허용하며, 권한을 세밀하게 제어할 수 있습니다.
역할을 사용하면 최소 권한 원칙을 유지하며, 보안 팀이 필요한 권한만을 임시로 부여받아 접근할 수 있도록 합니다. 이를 통해 장기적으로 불필요한 권한 부여를 피할 수 있습니다.

오답 이유:

A (IAM 사용자 생성 및 권한 부여): IAM 사용자를 직접 생성하여 권한을 부여하는 방식은 보안 모범 사례를 따르지 않으며, 역할을 사용하여 권한을 위임하는 방식보다 관리가 어렵습니다.
C (IAM 사용자에 관리 권한 부여): IAM 사용자에게 관리 권한을 부여하는 것은 보안 원칙에 어긋나며, 관리 권한은 최소한으로 유지해야 합니다.
D (IAM 사용자와 IAM 그룹을 통한 권한 부여): IAM 그룹을 사용하는 방식은 역할을 사용하는 방식보다 세밀한 권한 관리가 어려울 수 있으며, 역할을 사용하는 방법이 더 적합합니다.

이 솔루션은 AWS에서 보안 및 권한 관리의 모범 사례를 따르며, 보안 팀이 프로덕션 환경에 안전하고 효율적으로 접근할 수 있도록 합니다.

보고 애플리케이션이 Application Load Balancer 기반의 Amazon EC2 인스턴스에서 실행된다. 인스턴스는 다수의 가용 영역에 속한 Amazon EC2 Auto Scaling 그룹에서 실행된다. 복잡한 보고서의 경우 애플리케이션이 요청에 응답하는 데 최대 15분이 걸릴 수 있다. 한 솔루션스 아키텍트가 축소 이벤트 중에 보고서 요청이 처리될 경우 사용자에게 HTTP 5xx 오류가 발생할 수 있다는 점을 우려하고 있다.

인스턴스 종료 전에 사용자 요청이 완료되도록 하려면 솔루션스 아키텍트는 어떻게 해야 하는가?

정답: D 대상 인스턴스 그룹의 등록 취소 지연의 제한 시간을 900초보다 크게 늘린다.

이유:

등록 취소 지연(deregistration delay)은 인스턴스가 Auto Scaling 그룹에서 종료되기 전에 인스턴스에서 진행 중인 요청을 완료할 수 있도록 대기하는 시간을 설정합니다. 기본값은 300초(5분)이며, 이를 900초(15분)으로 늘리면 요청이 완료될 때까지 인스턴스를 계속 유지하여 사용자에게 HTTP 5xx 오류가 발생하지 않도록 할 수 있습니다.
이 설정을 통해 인스턴스 종료 전에 진행 중인 요청이 완료될 시간을 확보하여 사용자 요청이 성공적으로 처리될 수 있도록 보장합니다.

오답 이유:

A (스티키 세션 사용): 스티키 세션은 동일한 사용자 요청을 동일한 인스턴스로 라우팅하지만, 인스턴스가 종료되기 전에 진행 중인 요청을 완료하도록 보장하지는 않습니다.
B (인스턴스 크기 증가): 인스턴스 크기를 늘리는 것은 요청 처리 속도를 개선할 수 있지만, 인스턴스 종료 전 진행 중인 요청을 완료하는 문제를 직접적으로 해결하지는 않습니다.
C (휴지 기간 연장): 휴지 기간은 인스턴스가 종료되기 전에 추가 인스턴스를 시작하거나 종료할 때의 영향을 관리하는데, 요청 완료 보장을 위한 등록 취소 지연과는 관련이 없습니다.

등록 취소 지연을 적절히 설정하면, 애플리케이션이 사용자 요청을 처리하는 동안 인스턴스 종료로 인한 서비스 중단을 방지할 수 있습니다.

한 회사에서 AWS에 배포할 채팅 애플리케이션을 개발하고 있습니다. 이 애플리케이션은 키 값 데이터 모델을 사용하여 메시지를 저장합니다. 일반적으로 사용자 그룹은 메시지를 여러 번 읽습니다. 솔루션스 아키텍트는 높은 비율의 읽기를 지원하도록 확장되고 마이크로초 단위 대기 시간으로 메시지를 전달하는 데이터베이스 솔루션을 선택해야 합니다.

이러한 요구 사항을 충족하는 데이터베이스 솔루션은 무엇인가요?

정답: B DynamoDB Accelerator(DAX)가 포함된 Amazon DynamoDB

이유:

Amazon DynamoDB는 키-값 데이터 모델을 지원하는 NoSQL 데이터베이스로, 높은 읽기 성능을 제공합니다.
**DynamoDB Accelerator (DAX)**는 DynamoDB의 인메모리 캐싱 서비스로, 마이크로초 단위의 응답 시간을 제공합니다. 이는 높은 비율의 읽기 작업을 처리하는 데 매우 적합합니다.
이 조합은 메시지를 빠르게 읽어야 하는 요구 사항을 충족하며, 대기 시간을 최소화할 수 있습니다.

오답 이유:

A (Aurora 복제본이 포함된 Amazon Aurora): Aurora는 관계형 데이터베이스이며, 키-값 데이터베이스 모델을 사용하지 않습니다. 또한, 마이크로초 단위의 대기 시간을 제공하지 않습니다.
C (Amazon ElastiCache for Memcached가 포함된 Amazon Aurora): Aurora는 여전히 관계형 데이터베이스로, ElastiCache를 사용하더라도 마이크로초 단위 대기 시간을 일관되게 제공하기 어렵습니다.
D (Amazon ElastiCache for Memcached가 포함된 Amazon Neptune): Neptune은 그래프 데이터베이스로, 키-값 데이터베이스에 최적화되어 있지 않으며, ElastiCache를 사용하더라도 요구하는 대기 시간을 보장하기 어렵습니다.

DynamoDB와 DAX의 조합은 키-값 모델을 지원하고 마이크로초 단위의 대기 시간을 제공하므로, 이 시나리오에 가장 적합한 솔루션입니다.

공유기의 동작원리

hmk run dev — Sat, 8 Jun 2024 20:50:19 +0900

공유기(Router)란?

단일 IP에서 하위 클라이언트 PC가 유선 또는 무선으로 하나의 인터넷 라인을 공유하여

동시에 인터넷 접속이 가능하도록 하는기기다. WAN과 LAN 사이의 중계 역할을 하며

공인 IP를 각각의 PC에 사설 IP로 나누어 주고, 공유기에 연결된 장치들이 통신을 시도하면 NAT 기술을 이용하여 외부방 서버에 메세지를전달한다.

네트워크 주소 변환(Network Address Translation, NAT) : 공인 IP와 사설 IP간 주소를 변환시켜주는 기술

광대역 통신망(Wide Area Network, WAN) : ISP가 제공하는 서비스에 의해 구축된 네트워크

근거리 통신망(Local Area Network, LAN) : 작은 지역에서 여러 통신 기기와 상호 연결이 가능하게 하는 네트워크

공인 IP(Public IP) : 인터넷 사용자의 로컬 네트워크 식별을 위해 ISP가 제공하는 IP

사설 IP(Private IP) : 일반 가정이나 회사에서 사용할 목적으로 할당된 IP

3. 공유기 동작 원리

3.1. 사설 IP 할당

ISP가 제공하는 WAN 케이블이 공유기의 인터넷이라고 적혀있는 포트에 연결된다. 해당 케이블을 통해 공유기는 자신의 공인 IP 주소를 받는다. 그리고 공유기와 PC 간 LAN 케이블이 LAN 1, 2, 3, 4라고 적혀있는 포트에 연결된다. 이후 공유기는 DHCP를 통해 연결된 PC에 사설 IP를 할당한다.

인터넷 서비스 제공자(Internet Service Provider, ISP) :인터넷에 접속하는 수단을 제공하는 주체

＊ DHCP(Dynamic Host Configuration Protocol) : 하위 단말기에 네트워크 정보를 자동으로 할당해주는 프로토콜

3.2. 통신

아래 순서에 따라 통신이 진행된다. 순서 2, 3번에 해당하는 내용이 NAT 기술에 해당한다. 인터넷 접속은 공인 IP를 활용해야만 가능하기 때문에 사설 IP를 공인 IP로 바꿔주는 과정이 필요하다.

4. 공유기 가격결정 요소

속도 및 주파수 대역폭:

Wi-Fi 표준: 최신 Wi-Fi 표준일수록 더 빠른 속도와 안정성을 제공합니다. 예를 들어, Wi-Fi 6 (802.11ax)는 이전 표준인 Wi-Fi 5 (802.11ac)보다 속도가 빠르고 더 많은 기기를 효율적으로 처리할 수 있습니다.
듀얼 밴드 및 트라이 밴드: 듀얼 밴드 공유기는 2.4GHz와 5GHz 두 개의 주파수를 제공하며, 트라이 밴드 공유기는 추가적인 5GHz 대역을 제공합니다. 이는 많은 기기를 동시에 연결할 때 성능을 향상시킵니다.

안테나 및 커버리지:

안테나 수: 더 많은 안테나를 가진 공유기는 더 넓은 범위와 더 강력한 신호를 제공합니다.
MU-MIMO (Multi-User, Multiple Input, Multiple Output): 여러 기기가 동시에 데이터를 송수신할 수 있어 여러 사용자가 있을 때 성능이 향상됩니다.

프로세서 및 메모리:

더 강력한 CPU와 더 많은 RAM을 가진 공유기는 더 많은 기기와 더 높은 데이터를 처리하는 데 유리합니다.
웹 브라우징, 스트리밍 게임 등 많은 데이터 들을 효율적으로 처리하기 위함
패킷 라우팅, 네트워크 주소 변환(NAT), 방화벽 검사 등 다양한 작업을 빠르게 수행
여러 개의 클라이언트가 있을때 멀티 태스킹을 원활하게 할수 있게함

소프트웨어 및 보안 기능:

펌웨어 업데이트: 최신 보안 패치를 제공하는 공유기는 안전하게 네트워크를 유지할 수 있습니다.
고급 보안 기능: 방화벽, VPN 지원, 부모 통제, 게스트 네트워크 등 다양한 보안 및 관리 기능을 제공합니다.

추가 기능:

USB 포트: 외장 하드 드라이브나 프린터를 네트워크에 쉽게 연결할 수 있습니다.
QoS (Quality of Service): 네트워크 트래픽을 우선순위에 따라 관리하여 중요한 작업에 대역폭을 할당할 수 있습니다.

브랜드 및 품질:

브랜드 신뢰도: 명성 있는 브랜드는 일반적으로 더 높은 가격을 요구하지만, 그만큼 품질과 고객 지원이 우수합니다.

기본 경제용어 정리

hmk run dev — Thu, 30 May 2024 21:47:39 +0900

가산금리 (Spread)
- 기본 금리에 덧붙여지는 추가 금리.
- 예: 은행에서 대출을 받을 때 기준 금리 3%에 가산금리 1%가 더해져 총 4%의 금리를 적용받음.
경기동향지수 (Business Cycle Indicator)
- 경제 활동의 상태를 나타내는 지수.
- 예: 경기가 좋을 때는 상승하고, 나쁠 때는 하락함.
경상수지 (Current Account Balance)
- 한 나라가 외국과 거래한 상품, 서비스, 소득의 차이.
- 예: 수출이 수입보다 많으면 경상수지 흑자.
고용률 (Employment Rate)
- 일하고 있는 사람의 비율.
- 예: 100명 중 60명이 일하고 있으면 고용률은 60%.
고정금리 (Fixed Interest Rate)
- 대출 기간 동안 변하지 않는 금리.
- 예: 5년간 고정금리 3%로 대출 받음.
고통지수 (Misery Index)
- 실업률과 물가 상승률을 더한 값.
- 예: 실업률 5% + 물가 상승률 3% = 고통지수 8%.
골디락스경제 (Goldilocks Economy)
- 경기 과열도, 침체도 아닌 적당한 경제 상태.
- 예: 경제 성장률 2~~3%, 물가 상승률 1~~2% 수준의 안정적 경제.
공공재 (Public Goods)
- 모두가 사용할 수 있는 재화나 서비스.
- 예: 국방, 공원.
공급탄력성 (Price Elasticity of Supply)
- 가격 변화에 대한 공급량의 반응 정도.
- 예: 가격이 10% 오를 때 공급량이 20% 늘면 공급탄력성이 큼.
공매도 (Short Selling)
- 주식을 빌려서 팔고 나중에 싼 가격에 사서 갚는 거래.
- 예: 주가가 하락할 것을 예상하고 미리 주식을 팔아 이익을 얻음.
국가신용등급 (Sovereign Credit Rating)
- 국가의 신용도를 평가한 등급.
- 예: 신용등급이 높으면 국가가 낮은 금리로 자금을 조달할 수 있음.
국채 (Government Bond)
- 정부가 자금을 조달하기 위해 발행하는 채권.
- 예: 정부가 국채를 발행해 도로 건설 자금을 마련함.
금본위제 (Gold Standard)
- 화폐의 가치를 금과 연계한 제도.
- 예: 금 1온스가 100달러라면 100달러 지폐는 1온스의 금으로 교환 가능.
금산분리 (Separation of Banking and Commerce)
- 금융업과 산업 자본의 분리.
- 예: 대기업이 은행을 소유하지 못하게 규제함.
기업공개 (IPO, Initial Public Offering)
- 기업이 주식을 공개해 증권시장에 상장하는 것.
- 예: 스타트업 회사가 성장해 주식을 발행하고 상장함.
기준금리 (Base Rate)
- 중앙은행이 설정하는 금리.
- 예: 한국은행이 기준금리를 2%로 설정하면 다른 은행들도 이를 참고하여 대출 금리 설정.
기축통화 (Key Currency)
- 국제 거래에서 중심이 되는 통화.
- 예: 미국 달러, 유로, 엔화.
기회비용 (Opportunity Cost)
- 어떤 선택을 했을 때 포기한 다른 선택의 가치.
- 예: A를 선택하면 B를 포기해야 하는데, B의 가치가 기회비용.
낙수효과 (Trickle-Down Effect)
- 상위 계층의 부가 아래로 흘러가 전체 경제에 긍정적인 영향을 미친다는 이론.
- 예: 부유층의 소비가 증가하면 중산층과 하위 계층에도 혜택이 돌아감.
단기금융시장 (Money Market)
- 만기가 짧은 금융상품이 거래되는 시장.
- 예: 기업이 자금을 잠시 빌리기 위해 단기 채권을 발행함.
대외의존도 (Degree of External Dependence)
- 경제가 외국과의 거래에 얼마나 의존하는지 나타내는 지표.
- 예: 수출 비중이 높으면 대외의존도가 높음.
대체재 (Substitute Goods)
- 비슷한 용도로 사용 가능한 재화.
- 예: 버터와 마가린, 커피와 차.
더블딥 (Double Dip)
- 경기 회복 후 다시 침체에 빠지는 현상.
- 예: 경기 회복세를 보이다가 다시 불황에 빠짐.
디커플링 (Decoupling)
- 한 나라의 경제가 다른 나라의 경제와 독립적으로 움직이는 현상.
- 예: 미국 경제가 침체에 빠져도 한국 경제는 성장하는 경우.
디플레이션 (Deflation)
- 물가가 지속적으로 하락하는 현상.
- 예: 소비가 줄어들어 상품 가격이 계속 떨어짐.
레버리지 효과 (Leverage Effect)
- 차입금을 이용해 투자 수익률을 높이는 것.
- 예: 100만원을 빌려서 10% 수익을 내면 자기자본 수익률이 상승함.
만기수익률 (Yield to Maturity, YTM)
- 채권을 만기까지 보유했을 때 얻을 수 있는 수익률.
- 예: 만기 10년 채권의 만기수익률이 5%라면, 만기까지 연 5%의 수익을 기대할 수 있음.
마이크로 크레디트 (Microcredit)
- 소액 대출을 통해 저소득층의 경제 활동을 지원하는 금융 서비스.
- 예: 작은 자영업을 시작하려는 사람들에게 소액 대출을 제공.
매몰비용 (Sunk Cost)
- 이미 지출되어 회수할 수 없는 비용.
- 예: 프로젝트에 투자한 돈이 실패해도 돌려받을 수 없는 비용.
명목금리 (Nominal Interest Rate)
- 물가 상승을 고려하지 않은 금리.
- 예: 명목금리 5%일 때 실질 금리는 물가 상승률을 제외한 값.
무디스 (Moody's)
- 신용평가 기관 중 하나로, 기업 및 국가의 신용도를 평가.
- 예: 무디스가 국가 신용등급을 높이면 그 나라의 신용도가 높아짐.
물가지수 (Price Index)
- 상품과 서비스의 평균 가격 변동을 나타내는 지수.
- 예: 소비자 물가지수가 2% 상승하면 물가가 2% 오른 것.
뮤추얼펀드 (Mutual Fund)
- 다수의 투자자들로부터 자금을 모아 다양한 자산에 투자하는 펀드.
- 예: 투자자들이 모은 돈으로 주식, 채권 등에 투자해 수익을 분배.
뱅크런 (Bank Run)
- 예금자들이 대거 예금을 인출하는 사태.
- 예: 은행의 파산 소문이 돌면 예금자들이 돈을 찾으려고 몰림.
베블런효과 (Veblen Effect)
- 가격이 오를수록 수요가 증가하는 현상.
- 예: 명품 가방의 가격이 올라갈수록 더 많이 팔림.
변동금리 (Floating Interest Rate)
- 시장 금리에 따라 변동하는 금리.
- 예: 3개월마다 한 번씩 금리가 조정되는 대출.
보호무역주의 (Protectionism)
- 자국 산업을 보호하기 위해 무역을 제한하는 정책.
- 예: 수입품에 높은 관세를 부과하여 자국 산업을 보호.
본원통화 (Base Money)
- 중앙은행이 발행한 화폐와 시중은행이 중앙은행에 예치한 예금.
- 예: 중앙은행이 돈을 찍어내고 은행들이 이를 예치함.
부가가치 (Value Added)
- 생산 과정에서 새롭게 만들어진 가치.
- 예: 원재료 100만원을 가공해 200만원의 제품을 만들면 부가가치 100만원.
부채담보부증권 (Collateralized Debt Obligation, CDO)
- 여러 부채를 모아 만든 증권.
- 예: 주택담보대출을 묶어 만든 금융상품.
부채비율 (Debt Ratio)
- 자산 대비 부채의 비율.
- 예: 자산 100억원에 부채 50억원이면 부채비율은 50%.
분수효과 (Fountain Effect)
- 저소득층의 소득 증대가 경제 전반에 긍정적 영향을 미친다는 이론.
- 예: 정부가 저소득층 지원을 늘리면 소비가 증가해 경제가 활성화됨.
빅맥지수 (Big Mac Index)
- 각국의 물가 수준을 비교하기 위해 빅맥 햄버거 가격을 이용하는 지수.
- 예: 한국에서 빅맥이 4천원, 미국에서 5달러면 환율을 비교 가능.
상장지수펀드 (ETF, Exchange-Traded Fund)
- 특정 지수의 수익률을 추종하는 펀드.
- 예: 코스피200 지수를 추종하는 ETF에 투자하면 코스피200과 비슷한 수익을 기대.
서킷브레이커 (Circuit Breaker)
- 주식시장이 급격히 하락할 때 거래를 일시 중지하는 제도.
- 예: 주가가 일정 수준 이상 하락하면 거래를 멈춰 패닉을 방지.
선물거래 (Futures Trading)
- 미리 정한 가격으로 특정 상품을 미래에 사고 파는 거래.
- 예: 농부가 수확 전에 곡물을 미리 판매해 가격 변동 리스크를 줄임.
소득주도성장 (Income-Led Growth)
- 소득 증가를 통해 경제 성장을 촉진하는 정책.
- 예: 최저임금을 인상해 근로자의 소비를 늘리고 경제 성장을 도모.
수요탄력성 (Price Elasticity of Demand)
- 가격 변화에 대한 수요량의 반응 정도.
- 예: 가격이 10% 오를 때 수요량이 20% 줄면 수요탄력성이 큼.
스왑 (Swap)
- 서로 다른 조건의 자산이나 부채를 교환하는 거래.
- 예: 금리 스왑은 고정 금리와 변동 금리를 서로 교환.
스톡옵션 (Stock Option)
- 회사가 직원에게 일정 가격에 주식을 살 수 있는 권리를 부여.
- 예: 직원이 정해진 가격에 주식을 매수해 수익을 얻음.
시뇨리지 (Seigniorage)
- 화폐 발행을 통해 얻는 이익.
- 예: 1만원짜리 지폐를 500원에 만들어 발행하면 9500원의 이익.
신용경색 (Credit Crunch)
- 금융기관들이 대출을 줄이고 자금 공급이 어려워지는 현상.
- 예: 금융위기로 인해 은행들이 대출을 꺼려함.
신주인수권부사채 (Bond with Warrant, BW)
- 채권에 일정 가격으로 신주를 인수할 수 있는 권리가 붙어 있는 것.
- 예: 채권을 사면 나중에 신주를 일정 가격에 매수할 수 있음.
실질임금 (Real Wage)
- 물가 상승을 고려한 실질 구매력을 나타내는 임금.
- 예: 명목임금 100만원이지만 물가가 오르면 실질임금은 줄어듦.
애그플레이션 (Agflation)
- 농산물 가격 상승이 물가 상승으로 이어지는 현상.
- 예: 기후 변화로 농작물 수확이 줄어들어 물가가 오름.
양도성예금증서 (CD, Certificate of Deposit)
- 양도가 가능한 정기 예금증서.
- 예: 은행에서 발행한 예금증서를 다른 사람에게 팔 수 있음.
양적완화정책 (Quantitative Easing, QE)
- 중앙은행이 자산을 매입해 시중에 유동성을 공급하는 정책.
- 예: 중앙은행이 채권을 사들여 시장에 돈을 풀어 경기 부양.
어음관리계좌 (CMA, Cash Management Account)
- 어음을 기반으로 자금을 운용하는 금융 상품.
- 예: 자금을 어음에 투자해 높은 이자율을 제공.
연방준비제도 (FRS)/연방준비은행 (FRB) (Federal Reserve System/Bank)
- 미국의 중앙은행 제도.
- 예: 미국 경제를 조정하고 통화 정책을 결정.
엥겔의 법칙 (Engel's Law)
- 소득이 증가할수록 식료품에 지출하는 비율이 감소하는 법칙.
- 예: 소득이 높아질수록 식료품비 비중은 줄어들고 여가비 비중은 늘어남.
역모기지론 (Reverse Mortgage)
- 주택을 담보로 매월 연금을 받는 제도.
- 예: 은퇴 후 집을 담보로 매달 생활비를 받음.
예대율 (Loan-to-Deposit Ratio)
- 예금 대비 대출의 비율.
- 예: 예금이 100억원이고 대출이 80억원이면 예대율은 80%.
옵션 (Option)
- 미래의 일정 시점에 정해진 가격으로 자산을 사고 팔 수 있는 권리.
- 예: 콜옵션은 주식을 정해진 가격에 살 수 있는 권리.
외환보유액 (Foreign Exchange Reserves)
- 중앙은행이 보유한 외국 통화와 자산.
- 예: 경제 위기 시 외환보유액을 사용해 환율을 안정시킴.
워크아웃 (Workout)
- 부실 기업을 재건하기 위한 채권자와의 협상.
- 예: 재정 문제가 있는 기업이 채무 재조정을 통해 회생을 도모.
원금리스크 (Principal Risk)
- 투자 원금의 손실 가능성.
- 예: 주식에 투자해 원금을 잃을 위험.
유동성 (Liquidity)
- 자산을 쉽게 현금으로 전환할 수 있는 정도.
- 예: 현금은 가장 유동성이 높은 자산.
이중통화채 (Dual Currency Bond)
- 발행과 상환이 서로 다른 통화로 이루어지는 채권.
- 예: 달러로 발행되고 유로로 상환되는 채권.
자기자본비율 (Equity Ratio)
- 자본 대비 자기자본의 비율.
- 예: 자본 100억원 중 자기자본이 60억원이면 자기자본비율은 60%.
자발적 실업 (Voluntary Unemployment)
- 근로자가 스스로 선택한 실업.
- 예: 더 나은 일자리를 찾기 위해 현재 일을 그만둠.
장단기금리차 (Yield Curve Spread)
- 장기 금리와 단기 금리의 차이.
- 예: 10년 만기 국채 금리가 5%, 1년 만기 국채 금리가 3%면 장단기금리차는 2%.
장외시장 (Over-The-Counter, OTC)
- 정식 거래소가 아닌 시장에서 거래되는 금융 상품.
- 예: 비상장 주식이나 채권이 장외시장에서 거래됨.
전환사채 (Convertible Bond)
- 주식으로 전환할 수 있는 권리가 있는 채권.
- 예: 채권을 일정 시점에 주식으로 전환 가능.
정크본드 (Junk Bond)
- 신용도가 낮은 기업이 발행하는 고위험 고수익 채권.
- 예: 신용등급이 낮은 회사가 높은 금리로 자금을 조달.
제로금리정책 (Zero Interest Rate Policy)
- 중앙은행이 금리를 0%에 가깝게 유지하는 정책.
- 예: 경기 부양을 위해 기준금리를 0%로 설정.
주가수익률 (PER, Price Earnings Ratio)
- 주가를 주당순이익으로 나눈 값.
- 예: 주가가 10만원, 주당순이익이 1만원이면 PER은 10.
주가지수 (Stock Index)
- 여러 주식의 가격을 종합해 산출한 지수.
- 예: 코스피, 나스닥.
조세부담률 (Tax Burden Ratio)
- 국민 총소득 대비 세금의 비율.
- 예: 소득 100만원 중 세금이 20만원이면 조세부담률은 20%.
주당순이익 (EPS, Earnings Per Share)
- 순이익을 발행 주식 수로 나눈 값.
- 예: 순이익이 1억원, 발행 주식이 10만주면 EPS는 1천원.
중앙은행 (Central Bank)
- 국가의 통화 정책을 담당하는 은행.
- 예: 한국은행, 미국 연방준비은행.
증거금 (Margin)
- 금융 거래 시 일정 금액을 예치하는 것.
- 예: 선물 거래를 위해 거래 금액의 일부를 증거금으로 납부.
지주회사 (Holding Company)
- 다른 회사를 지배할 목적으로 설립된 회사.
- 예: A회사가 B회사의 주식 50% 이상을 소유해 지배함.
추심 (Collection)
- 채권자가 채무자에게 빚을 갚으라고 요구하는 것.
- 예: 은행이 연체된 대출금 회수를 위해 추심 절차를 밟음.
치킨게임 (Chicken Game)
- 두 당사자가 서로 양보하지 않으면서 극한 대립을 이어가는 상황.
- 예: 두 나라가 서로 관세를 높이면서 무역 전쟁을 벌임.
카르텔 (Cartel)
- 기업들이 가격, 생산량 등을 담합하여 시장을 지배하는 행위.
- 예: OPEC 국가들이 석유 생산량을 조절해 가격을 통제.
콜옵션 (Call Option)
- 특정 가격에 자산을 살 수 있는 권리.
- 예: 콜옵션을 행사해 낮은 가격에 주식을 매수.
통화스왑 (Currency Swap)
- 서로 다른 통화를 일정 기간 교환하는 계약.
- 예: 한국과 일본이 원화와 엔화를 일정 기간 교환.
투자은행 (Investment Bank)
- 기업의 자금 조달, 인수합병 등을 돕는 금융 기관.
- 예: 골드만삭스, JP모건.
특수목적기구 (SPV, Special Purpose Vehicle)
- 특정 목적을 위해 설립된 법인.
- 예: 자산 유동화 등을 위해 설립된 기구.
파생금융상품 (Derivatives)
- 기초 자산의 가치 변동에 따라 가격이 결정되는 금융 상품.
- 예: 선물, 옵션.
평가절하 (Devaluation)
- 한 나라의 통화 가치가 하락하는 것.
- 예: 정부가 환율을 높여 수출 경쟁력을 높임.
표면금리 (Coupon Rate)
- 채권 발행 시 약정된 이자율.
- 예: 5% 표면금리를 가진 채권은 매년 5%의 이자를 지급.
한계비용 (Marginal Cost)
- 추가로 한 단위를 생산하는 데 드는 비용.
- 예: 100개를 생산할 때 1개 추가 생산 비용이 5천원.
헤지펀드 (Hedge Fund)
- 고수익을 추구하며 다양한 전략을 사용하는 투자 펀드.
- 예: 위험을 분산시키기 위해 다양한 자산에 투자.
환율조작국 (Currency Manipulator)
- 자국의 환율을 인위적으로 조정하는 국가.
- 예: 수출 경쟁력을 높이기 위해 통화 가치를 낮추는 나라.
M&A (Mergers and Acquisitions)
- 기업 인수합병.
- 예: A회사가 B회사를 인수해 합병함.
매출채권회전율
특정기간동안 매출채권이 얼마나 현금화 됐는지, 회전일수는 외상값을 받는데 얼마나 걸렸는지 확인하는 지표다.
매출채권회전이 중요한이유는 기업이 빠른시간안에 유동성을 확보해야 향후경영에 사용할 수 있기때문
재고자산회전율
매출액을 재고자산으로 나눈 비율, 재고자산이 얼마나 빨리 팔려나가는지를 보여주는 지표
짧으면 짧을 수록 좋다고 볼 수 있음 => 재고 관리가 효율적으로 이루어지고 있음

프론트엔드 코딩 컨벤션 리마인드

hmk run dev — Wed, 22 May 2024 23:03:56 +0900

일정에 쫓겨 정신줄 놓고 코딩하다 보면 오히려 동료들의 코드리뷰 시간과

수정하는 리소스가 들어 비효율을 초래하게 된다.

이틀 동안 바쁘게 개발하다 보니 호되게 코드리뷰를 받고, 다시는 같은 실수를 반복하지 않기 위해

글로 남기려고 한다~

코드리뷰

부끄럽지만 같은 실수를 하는 것은 나와 나의 동료의 리소스를 뺐을 수 있다.

적어두고 몸에 배어 단단한 습관이 되도록 기록하고 계속 읽어보자

props로 setter(setState)하는 콜백은 되도록이면 넘기지 말기

- 되도록이면 호출이 필요한 시점에 호출을 트리거하는 곳에서 호출하자

- 코드를 유지보수하는 쪽에서 작동을 파악하는 데 더 용이함

- 호출 제어권을 밖으로 빼어 사이드 이펙의 가능성을 줄임

- 양방향 데이터 바인딩은 지양

핸들러 네임 컨벤션

- props 이름 = on + 이벤트 이름

- props에 적용하는 핸들러 이름 = handle + 이벤트 이름

사실 아래와 같은 경우는

onSelect도 onChange로 바뀌고

updateOptionNameEditMode도 onChangeOptionNameEditMode로 바뀌어야 한다.

(updateOptionNameEditMode은 boolean값을 받아 editMode를 set 하는 역할을 하기 때문)

안 쓰이는 구문

- 아래 eslint-plugin으로 싸악 청소해 주자 (게비스콘 짤)

https://www.npmjs.com/package/eslint-plugin-unused-imports?activeTab=dependencies

스타일 디테일

누가 봐도 거슬리는 스타일은 FE 개발자 선에서 처리해 보자

에러 처리

- 예상할 수 있는 에러는 명시적으로 Error 객체를 던져주자

- sentry & catch에서 에러를 잡아낼 수 있음

에러 처리 2

- else 대신 예상할 수 있는 에러는 명시적으로 Error 객체를 던져주자
- 유지보수가 더 용이하며 코드를 보고 의도를 파악하기 더 쉬워진다.

코드예시

const fetchRecommendOptionNames = useCallback(
    (sellingMarket: SellingMarket) => {
      switch (sellingMarket) {
        case SellingMarket.Coupang:
          fetchCoupangRecommendOptionName();
          break;
        case SellingMarket.St11:
        case SellingMarket.Auction:
          fetchEsmRecommendOptionName();
          break;
        default:
          throw new Error(
            `fetchRecommendOptionNames: ${sellingMarket} sellingMarket is invalid`,
          );
      }
    },
    [fetchCoupangRecommendOptionName, fetchEsmRecommendOptionName],
);

이벤트 props 네이밍 컨벤션

- 네이티브 이벤트 핸들러 기반으로 보편적인 네이밍

- 핸들러의 동작 여부 쉽게 파악

이렇게 써보니 좀만 신경 썼다면 좋았던 경우가 대부분 인 것 같다..

명심하자 신경쓰지 않고 대충 짠 코드는

동료의 코드리뷰 리소스 + 나의 재수정 리소스
더 나아가 조직 전체의 리소스 저하로 초래된다 정신 차리고 차분하게 생각하고 더 신경 쓰자

emotion(css-in-js)과 nextjs

hmk run dev — Sun, 5 May 2024 20:19:38 +0900

nextjs와 emotion(css-in-js)을 같이 사용하다.
두 개의 조합이 별로 좋지 못하다는 생각이 들어 emotion을 사용해 왔던 이유와
조합이 좋지 못한 nextjs와 계속 같이 사용을 하는 게 맞을지에 대한 판단을 하기 위해 정리해보려고 합니다.

emotion/css-in-js 방식의 장단점

장점

가독성
- css 혹은 id 같은 선택자로 css를 작성하지 않고 태그명 자체를 개별로 명시해서 사용할 수 있음

스타일 충돌 방지
- emotion을 이용한 스타일링은 개발자가 임의로 선택자를 지정해 작성한 css와 달리 개별 스코프를 가지며 css 충돌 가능성이 매우 낮음

상태에 따른 스타일 변경용이
- emotion 태그 내에 js코드를 혼합해서 작성이 가능해 react의 state에 따른 스타일 구현하기가 비교적 편함

export const Description: React.FC<IProps> = ({
  label,
  labelWidth,
  content,
}) => {
  return (
    <Wrapper>
      <LabelArea width={labelWidth}>{label}</LabelArea>
      <ContentArea>{content}</ContentArea>
    </Wrapper>
  );
};

/** emotion styled */
export const Wrapper = styled.section`
  display: inline-flex;
  align-items: center;
  gap: 0.625rem;
  width: 100%;
  border-top: 1px solid ${COLOR.SKELETON.TEXT_03};
  border-bottom: 1px solid ${COLOR.SKELETON.TEXT_03};
  border-right: 1px solid ${COLOR.SKELETON.TEXT_03};
  margin-bottom: -1px;
`;

export const LabelArea = styled.span<{ width?: string }>`
  display: flex;
  width: ${(props) => props.width ?? '12rem'};
  padding: 0.75rem 1.5rem;
  align-items: center;
  gap: 0.5rem;
  align-self: stretch;
  background: ${COLOR.UI_UP_02};
  color: ${COLOR.TEXT_D_02};
  border-left: 1px solid ${COLOR.UI_UP_UI_STROKE};
  border-right: 1px solid ${COLOR.UI_UP_UI_STROKE};

  ${BODY_BODY_LONG_2}
`;

export const ContentArea = styled.span`
  display: flex;
  align-items: center;
  gap: 1rem;
  padding: 0 0.75rem;

  color: ${COLOR.TEXT_D_01};
  ${BODY_BODY_LONG_2}

  input {
    padding-left: 0;
    max-width: 7rem;
  }
`;

단점

nextjs와 조합
- RSC(서버컴포넌트), SSR과 같은 방식에서 지원이 미흡하거나 아예 사용자체가 불가
아래 이슈들이 모두 해결되어야 사용가능하지 않을까 싶음
https://github.com/emotion-js/emotion/issues/2928

성능
- css-in-js 방식은 컴포넌트가 렌더링 될 때 css 스타일을 따로 직렬화하는 과정이 필요함 & js 번들크기 증가

정량적인 성능 측정은 아래 글을 참고하면 좋을 것 같다.
https://www.samsungsds.com/kr/insights/web_component.html

웹 컴포넌트 스타일링 관리 CSS-in-JS vs CSS-in-CSS | 인사이트리포트 | 삼성SDS

HTML(Hypertext Markup Language)이 처음 등장한 1991년에는 CSS(Cascading Style Sheets)가 없었습니다. 웹 이용자들이 늘어나면서 디자인에 대한 요구가 커졌고 웹 고안자들은 HTML을 꾸며주는 언어의 필요성을

www.samsungsds.com

결론

나열해 보니 DX vs 성능/nextjs와 조합 측면에서 선택을 해야 할 것 같긴 하다.

확실히 개발경험은 emotion 쪽이 더 가독성 좋고 명시적인 스타일링이 가능했었던 것 같아서 만족하며 쓰는 중이다.

현재 상황에선 nextjs에서 emotion 관련된 이슈를 빨리 해결해 주면 best이긴 하나... 몇 년째 개선의 여지가 안 보인다...

결론은 성능상 이점이 있는, 그리고 표준에 맞는 css-in-css 방식을 사용해 nextjs에서 제공하는 기능(SSR, SSG, ISR, RSC)등을 이용하는 쪽으로 개발할 예정이다.

이에 더해 next 측에서도 스타일링 방법으로 PostCss나 Tailwind CSS를 사용하는 것을 권장하고 있다.
https://nextjs.org/docs/app/building-your-application/styling/css-in-js#:~:text=we%20recommend%20using%20CSS%20Modules%20or%20other%20solutions%20that%20output%20CSS%20files%2C%20like%20PostCSS%20or%20Tailwind%20CSS.

몽고디비란? mongoDB

hmk run dev — Tue, 23 Apr 2024 00:14:50 +0900

몽고 DB의 기본 개념

MongoDB는 고성능, 고가용성 및 쉬운 확장성을 제공하는 NoSQL, Document 지향 데이터베이스입니다.

데이터를 배열 및 중첩 Document와 같은 복잡한 데이터 유형을 효율적으로 저장할 수 있는 유연한 JSON과 유사한 형식인 BSON(Binary JSON)으로 저장합니다.

JSON <=> BSON 직렬화, 역직렬화 과정에서 CPU 리소스가 많이 사용될 수 있으나,

이를 내부 최적화 알고리즘으로 개선했고,
텍스트 보다 적은 용량을 사용해 저장공간의 용이성도 가져온다.
일반적으로 데이터베이스 I/O 연산이 더 큰 병목 현상을 일으키 때문에

효율적인 방법 같다.

몽고 DB의 유연과 확장

몽고 DB의 장점을 두 개의 키워드로 뽑으면 유연과 확장이라고 말할 수 있을 것 같다.

아래와 같은 특징이 유연과 확장에 용이한 db라고 생각하는 이유이며, 빠르게 변화하는 비즈니스 요구에 유연하게 대응하기에 적합하지 않나 싶다.

스키마 없음 (Schema-less):
MongoDB는 스키마 없는 데이터베이스로, 데이터의 구조를 미리 정의하지 않아도 됩니다. 이로 인해 애플리케이션의 요구 사항이 변경되거나 다양한 데이터 형식을 저장할 수 있어 유연성이 높습니다.
동적 스키마 (Dynamic Schema):
MongoDB는 동적 스키마를 지원합니다. 이는 컬렉션 내에서 각 문서가 독립적으로 다른 필드를 가질 수 있음을 의미합니다. 필요에 따라 필드를 추가하거나 제거할 수 있어, 데이터 모델의 변화에 쉽게 대응할 수 있습니다.
수평적 확장 (Horizontal Scalability):
MongoDB는 쉽게 클러스터를 형성하여 데이터베이스를 확장할 수 있습니다. 이는 샤딩(sharding) 기능을 통해 데이터를 여러 노드에 분산시키고, 높은 트래픽과 대규모 데이터를 처리할 수 있게 해줍니다해 줍니다.
인덱싱 (Indexing):
MongoDB는 다양한 인덱싱 옵션을 제공하여 쿼리 성능을 최적화합니다. 필드에 인덱스를 추가하면 데이터 검색과 정렬이 빨라져서 애플리케이션의 응답 시간을 개선할 수 있습니다.
다양한 데이터 모델 지원:
MongoDB는 Document 지향 데이터베이스로서, 배열, 중첩된 문서, 기본 타입 등 다양한 데이터 유형을 지원합니다. 이로 인해 복잡한 데이터 구조를 표현하고 쿼리할 수 있습니다.

몽고 DB 어떤 경우에 적합한가?

MongoDB를 사용해야 할 때:

유연성이 필요한 경우: 스키마가 자주 변경되거나 복잡한 데이터 구조를 가진 애플리케이션에 적합합니다.
빠른 개발과 프로토타이핑: 데이터 모델을 빠르게 반영하고 수정할 수 있어, 초기 개발 단계에서 빠른 프로토타이핑이 필요한 경우에 적합합니다.
대규모 데이터와 높은 트래픽: 수평적 확장이 용이하므로, 대규모 데이터 집합과 높은 트래픽을 처리해야 하는 애플리케이션에 적합합니다.
다양한 데이터 모델: 배열, 중첩된 문서, 기본 타입 등 다양한 데이터 유형을 지원하므로, 복잡한 데이터 구조를 관리해야 하는 경우에 적합합니다.
실시간 분석과 집계: MongoDB는 실시간 집계와 분석을 위한 쿼리 기능을 제공하여 빠른 데이터 분석이 필요한 경우에 적합합니다.

MongoDB를 사용하면 안 될 때:

ACID 트랜잭션 필요: MongoDB는 ACID 트랜잭션을 제한적으로 지원합니다. 복잡한 트랜잭션 처리가 필요한 애플리케이션의 경우 관계형 데이터베이스가 더 적합할 수 있습니다.

mongoDB는 ACID 가 아닌 BASE 기반 트랜잭션을 사용합니다.

구조화된 특성을 감안할 때
- ACID 호환 DB는 일관성, 예측 가능성 및 안정성이 필요한 프로젝트에 적합한 것 같고,
- BASE는 더 쉽게 확장할 수 있고 더 많은 유연성을 제공해주나, BASE 모델의 한계를 알고 다루는 숙련된 개발자가 필요해 보인다.

속성	BASE	ACID
적용분야	NOSQL	RDBMS
일관성측면	약한 일관성	강한 일관성
중점사항	Availability	‘Commit’에 집중
시스템측면	성능에 초점	엄격한 데이터관리
효율성	쿼리디자인이 중요	테이블 디자인이 중요

정교한 쿼리 최적화: MongoDB는 강력한 쿼리 기능을 제공하지만, 관계형 데이터베이스의 SQL 쿼리 최적화 능력에는 미치지 못할 수 있습니다.
정교한 인덱싱: MongoDB는 다양한 인덱싱 옵션을 제공하지만, 관계형 데이터베이스의 정교한 인덱싱 기능에 비해 제한적일 수 있습니다.
고정된 스키마: 애플리케이션의 데이터 모델이 고정된 스키마를 필요로 하는 경우, 관계형 데이터베이스가 더 적합할 수 있습니다.
엄격한 보안 요구: MongoDB는 강력한 보안 기능을 제공하지만, 일부 고급 보안 요구사항을 충족시키기 위해서는 추가적인 설정과 관리가 필요할 수 있습니다.

몽고 DB의 Index

- index는 한 쿼리에 한 index만 유효합니다. 따라서 두 개의 index 가 필요하다면 복합 index를 사용합니다.
- index는 read 작업 위주의 애플리케션에서 유용하고 읽기보다 쓰기 작업이 많으면 index를 추가하는 것은 고려해야 합니다.

Single Field Index(단일 필드 인덱스)

하나의 필드 인덱스를 사용하는 것을 단일 필드 인덱스라고 합니다. MongoDB에는 기본적으로 컬렉션에 _id라는 단일 필드 인덱스가 생성됩니다.

단일 필드 추가 방법은 아래와 같습니다. 원하는 field를 입력합니다.
단일 필드 인덱스에서는 1은 오름차순 -1은 내림차순을 의미합니다.
하지만 단일 필드 인덱스에서는 오름차순인지 내림차순인지 중요하지 않습니다.
왜냐하면 어떤 방향으로 가도 동일하게 접근하기 때문입니다.

> db.user.createIndex({score:1})

Compound Index(복합 인덱스)

두 개 이상의 필드를 사용하는 인덱스를 복합 인덱스라고 부릅니다.

아래와 같이 인덱스를 생성한다면, 아래 그림과 같이 userid는 오름차순으로 정렬됩니다.
그리고 같은 userid를 지니면 score로 내림차순 정렬하게 됩니다.
예를 들면 동일한 userid 인"ca2"는 score가 내림차순으로 정렬되어 있음을 그림에서 확인할 수 있습니다.

> db.user.createIndex({userid:1 ,score:-1})

ttps://docs.mongodb.com/manual/core/index-compound/

- 특징 1. sort 연산 시 인덱스 순서를 고려하여 생성하자.

복합 인덱스에서는 키의 순서가 매우 중요합니다. 만일 복합 인덱스에서 순서가 userid-score가 아니라 score-userid로 생성하는 것은 다른 인덱스를 생성한 것입니다.

정렬 시 인덱스 순서와 조회 시 순서가 동일해야 합니다.

예를 들어 아래와 같이 인덱스 a-b순서로 생성하면 a-b 정렬은 지원을 하지만, b-a로 정렬은 지원하지 않습니다.

- 특징 2. 단일 인덱스와 다르게 복합 인덱스는 정렬 방향을 고려하자.

검색 쿼리에서 복합 인덱스를 사용하는 경우 지정된 정렬 방향은 index와 일치해야 합니다.
예를 들어 아래와 같이 두 필드 정렬이 역으로 생성된 경우라면 역으로 조회하는 쿼리는 지원하지만, 동일한 정렬을 하는 쿼리는 지원하지 않습니다.

사용 TIPS

mongoDB 핸즈온 워크샵에서 들은 내용들..

Insert Replication

기본 3개의 노드로 구성된 클러스터 환경으로 데이터 복제를 위한 옵션 제공
비동기 형태의 보장하기 위해 write concern 제공
Default한 설정 권장

Array Search 시

Array 검색 시 elemMatch 사용

Index

Single Field { year: 1 }

ASC : 1, DESC: -1

Compound Field { year: 1, rated: -1 }
Multikey { languages: 1 }
Array index
include element search
Geospatial
x B-tree
Text
한국에서 사용하기 어렵 -> altas search 대체
Hashed { did: hashed }
샤딩을 제외면 독립적으로 쓰기 어려움

Query plan

winningPlan 위주로
COLLSCAN 무조건 지양 -> 무조건 index를 통한 SCAN

인덱스 생성 시 고려사항(ESR) - 아래 순서대로 인덱스 구성

Equality (최대한 앞으로)
Sorting
Range

필드 지정 순서에 대한 고려

쿼리 패턴을 고려

읽어들인 인덱스키와 document가 같을 수록 성능이 좋다.

리액트 성능 측정 & 개선하기 (feat. memo & React DevTools)

hmk run dev — Sat, 20 Apr 2024 23:22:03 +0900

리액트 성능 측정하기 - 효율적인 테이블 컴포넌트 구현

사내에서 테이블 컴포넌트를 만들어야 하는 일이 생겼습니다.
그러나 특정 조건들로 인해 성능이슈가 생겼는데요

1. 페이징 처리가 없는 테이블의 형태
2. 옵션값 개수의 모든 경우의 수를 고려한 옵션생성(수십 ~ 수백 개의 테이블 row UI가 생김)

3. 판매 마켓별로 옵션들의 값을 수정할 수 있는 UI

4. 테이블 데이터(옵션)들을 일괄변경 할 수 있는 기능(자주 사용할 것으로 판단)

페이징 처리가 없는 테이블과 자주 사용되는 데이터 일괄 변경 기능은 리액트에서 성능 문제를 초래할 수 있습니다.
특히 수백 개의 테이블 row가 재렌더링 되는 경우, 애플리케이션의 성능 저하가 발생할 수 있습니다.

성능 측정과 개선

성능 측정은 React DevTools의 Profiler를 이용했습니다.

메모 적용 전

총 렌더링 소요 시간 - 2.7s

테이블 렌더링 소요 시간 - 87.3ms

Table Row 메모 적용 후

총 렌더링 소요 시간 - 1.7s

테이블 렌더링 소요 시간 - 85.3ms

적용코드

export const TableItem = React.memo(Component);

Table Cell 메모 적용 후

성능측정 결과 가장 결과가 좋았습니다.

총 렌더링 소요 시간 - 1.4s

테이블 렌더링 소요 시간 - 27.6ms

아래의 UI를 보면 선택된 row와 선택된 row들의 데이터를 일괄 수정할 수 있는 버튼 UI가 보인다.

각 셀이 일괄 변경될 수 있는 경우가 다르다는 것을 알 수 있는데,

Row뿐만 아니라 각 Cell에도 메모제이션을 적용하면 일괄 변경 시 성능상 이점을 가져갈 수 있을 것으로

판단해 각 Cell에 memo를 적용했습니다.

적용코드

아래와 같이 각 Cell에 memo를 적용했습니다.

일반적으로 memo는 얕은 비교를 수행해 참조형 데이터를 props로 받는 cell의 경우엔 아래와 같이

- memo shallow eqaul 참고

https://react.dev/reference/react/memo#specifying-a-custom-comparison-function:~:text=between%20re%2Drenders.-,Specifying%20a%20custom%20comparison%20function,-In%20rare%20cases

memo – React

The library for web and native user interfaces

react.dev

deep compare를 수행하는 lodash의 isEqual을 사용해 memo의 두 번째 인자에서

props의 변화를 감지하는 방식으로 구현했습니다.

import { isEqual } from 'lodash';

export const FinalPriceCell = React.memo(Component, (prevProps, nextProps) => {
  return isEqual(prevProps, nextProps);
});

결론

React.memo()는 리액트에서 메모이제이션의 장점을 얻게 해 주는 훌륭한 도구다.
올바르게 적용된다면 변경되지 않은 동일한 prop에 대해 리렌더링을 하는 것을 방지할 수 있습니다.

But,

- 무분별한 memo는 오히려 메모리 사용 증가로 성능상 저하를 유발할 수 있습니다.

- 원시형이 아닌 참조형 데이터를 props로 넘길 때 memo가 의도대로 동작하지 않을 수 있으므로, 깊은 비교가 필요합니다.
- 콜백 함수를 prop으로 사용하는 컴포넌트에서 메모이지을 할 때 주의가 필요합니다.
- 같은 렌더링을 할 때 이전과 동일한 콜백 함수 인스턴스를 넘기는지 확인이 필요합니다.

- 메모이제이션의 성능상 이점을 측정하기 위해 profiler를 사용해 보는 것이 좋습니다.

Reference

https://react.dev/reference/react/memo

Sec-CH-UA(Security-ClientHint-UserAgent)

hmk run dev — Tue, 16 Apr 2024 22:39:32 +0900

웹 브라우저의 보안 클라이언트 힌트 (Sec-CH-UA) 이해하기

웹 브라우저는 서버에게 어떻게 동작하고 어떤 환경에서 실행되고 있는지에 대한 정보를 전송하기 위해 다양한 헤더를 사용합니다. 이 중에서도 "Sec-CH-UA" 헤더는 보안 클라이언트 힌트의 사용자 에이전트 정보를 제공하는 중요한 역할을 합니다. 이번 글에서는 "Sec-CH-UA" 헤더의 각 필드에 대해 자세히 알아보겠습니다.

"Sec-CH-UA"와 관련된 헤더는 주로 웹 브라우저에 의해 자동으로 생성되며, 클라이언트 측에서 서버에 전송됩니다. 이 헤더는 브라우저의 사용자 에이전트 정보와 함께 웹 페이지 요청에 포함됩니다.

유저가 어떤 환경에서 우리 서비스를 사용하는지에 대한 정보를 수집할 수도 있으며

웹사이트 크롤링을 방어할 때 Sec-CH-UA 포함 여부를 검사해 브라우저에서 보낸 요청인지 식별하는 경우가 꽤 있습니다.

도입이유

기존에 User-Agent HTTP 헤더에서 브라우저, OS, 사용자의 기기 정보 등 사용자 에이전트 정보를 얻을 수 있었음

But

User-Agent string에는 많은 엔트로피(정보량)가 담겨 있어 개인정보 침해 문제 이슈가 있었음

Chrome은 이러한 문제를 해결하고자 Client Hints를 헤더에 포함하는 방향으로 변경

Sec-CH-UA

Google Chrome: 버전 "123"
Not:A-Brand: 버전 "8"
Chromium: 버전 "123"

헤더의 가장 기본적인 필드는 웹 브라우저의 이름과 버전 정보입니다. 위의 예시에서는 "Google Chrome", "Not:A-Brand", "Chromium" 등의 브라우저들과 그들의 버전 정보가 포함되어 있습니다.

Sec-CH-UA-Arch

Arch: "arm"

이 필드는 웹 브라우저가 실행되고 있는 아키텍처 정보를 제공합니다. 예시에서는 "arm" 아키텍처를 사용하고 있습니다.

Sec-CH-UA-Bitness

Bitness: "64"

웹 브라우저의 비트 버전 정보를 나타냅니다. 위의 예시에서는 64비트 버전을 사용하고 있습니다.

Sec-CH-UA-Full-Version-List

Google Chrome: "123.0.6312.122"
Not:A-Brand: "8.0.0.0"
Chromium: "123.0.6312.122"

이 필드는 각 브라우저의 전체 버전 정보를 제공합니다.

Sec-CH-UA-Mobile

Mobile:? 0

웹 브라우저가 모바일 장치에서 실행되고 있는지의 여부를 나타냅니다. "?"는 이 필드의 값이 불분명하다는 것을 의미합니다.

Sec-CH-UA-Model

Model: ""

모바일 장치의 모델 정보를 제공합니다. 위의 예시에서는 정보가 제공되지 않았습니다.

Sec-CH-UA-Platform

Platform: "macOS"

웹 브라우저가 실행되고 있는 플랫폼 정보를 제공합니다.

Sec-CH-UA-Platform-Version

Platform Version: "13.2.1"

플랫폼의 버전 정보를 제공합니다.

Sec-CH-UA-Wow64

Wow64:? 0

이 필드는 웹 브라우저가 32비트 환경에서 64비트 애플리케이션으로 실행되고 있는지의 여부를 나타냅니다.

Reference

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA

마이크로 프론트엔드(Micro Frontend)

hmk run dev — Sat, 13 Apr 2024 19:30:11 +0900

마이크로 프런트엔드란?

마이크로 프런트엔드는 소규모 프런트엔드 서비스를 독립적으로 개발, 배포, 운영할 수 있게 하는 아키텍처 패턴.
전통적인 단일 프론트엔드 애플리케이션 대신 여러 개의 작은 프런트엔드 애플리케이션으로 애플리케이션을 분리합니다.

마이크로 프런트엔드의 주요 목표와 문제 해결 포인트는 다음과 같습니다.

독립적인 개발 및 배포: 각 마이크로 프런트엔드는 독립적으로 개발, 테스트, 배포할 수 있어 더 빠르게 애플리케이션을 개선하고 배포할 수 있습니다.
기술 스택의 유연성: 마이크로 프론트엔드 아키텍처는 다양한 프런트엔드 기술 스택을 사용할 수 있어 팀이 선호하는 기술을 선택하여 개발할 수 있습니다. (React, Vue, Svelte 등등)
재사용성 및 확장성: 기능이나 컴포넌트를 재사용하거나, 새로운 기능을 추가할 때 각 마이크로 프런트엔드를 독립적으로 업데이트할 수 있어 확장성이 좋습니다.
팀 간 협업 용이성: 서로 다른 팀이나 조직이 독립적으로 개발할 수 있어 팀 간 협업이 더 유연해집니다.

장점

- FE 개발의 점진적 업그레이드 / 재작성이 용이해진다.

- 분리배포 용이, 팀 조직운영이 수월해짐

- 응집력 있고 유지보수성을 가지는 코드베이스를 유지할 수 있음

단점

- 배포 번들 사이즈가 커질 수 있음

- 서로 간의 개발 환경의 차이로 복잡도 증가

- 운영 리소스의 증가로 이어질 수 있음

Micro Frontend 통합 방법

마이크로 프런트엔드는 개발 후 각 애플리케이션을 어떻게 통합할지 고려해야 하는 아키텍처다.

각 화면을 조합하는 컨테이너 애플리케이션이 있고, 그 하부에는 단위 애플리케이션이 있다.

통합 방식들로는 아래와 같다.

서버 템플릿 통합

각 서버로 html을 요청하고, 최종 응답 서버에서 각 템플릿을 조합해서 응답을 보냄

빌드타임 통합

단위 애플리케이션을 패키지로 배포하고, package.json에 명시한 후 컨테이너 애플리케이션에서 import 하여 사용함

- 각 애플리케이션에 대한 런타임 대응이 안된다.

- 애플리케이션을 릴리즈하고 최종 애플리케이션에서 컴파일해야 한다.

- 대표적으로 webpack의 Module Federation과 같은 방식이 있음

iframe 통합

전통적인 방식이면서 가장 간단한 방식

- 애플리케이션 통합의 유연성이 높다.

- 애플리케이션 기술 종속성이 없다.

- routing, history, deep-link 같은 것들을 고려해야 함

- 컨테이너 애플리케이션과 iframe에 들어가는 단위 애플리케이션 간의 통신규약 필요

- UX가 iframe안에 갇히기 때문에 어색한 UI가 표현될 수 있음

- 독립적인 렌더링 콘텍스트를 생성해 브라우저 메모리 사용량이 다소 높을 수 있음

Javascript를 통한 런타임 통합

iframe과 달리 유연한 통합이 가능

- 컨테이너 애플리케이션을 단위 애플리케이션 번들을 <script> 태그를 통합 다운로드하음

- 약속된 초기화 메서드를 호출

- 클라이언트(브라우저) 측에서 통합한다.

WebComponent를 통한 통합

HTML 엘리먼트를 통한 방법으로, static, runtime 둘 다 가능한 방법

- javascript 런타임 통합과 비슷하지만 "The web component way"를 지향한다.

- 클라이언트(브라우저) 측에서 통합한다.

도입 전에 고려해봐야 할 것들

어느 정도 복잡성을 가진 시스템에서 유용하므로 관리 자원과 트레이드오프를 생각해 신중하게 도입

의존성관리

- 모노레포 도입으로 효율적인 의존성 관리 (공통 항목 단일화, Package 공유, 단일 이슈트래킹)

- 분산된 CI 보다 속도가 느릴 수 있음

- lerna 같은 툴을 도입해 관리해보기

긴 빌드타임

- yarn berry 도입 및 zero install 사용 (빌드 시간을 줄이기 위해 변경사항이 없는 패키지는 빌드하지 않도록)

UI의 일관성을 위해 UI Component Library를 만들어 관리하기

- 모든 것을 처음부터 만들기보단, 중복코드가 생기는 시점에 적절히 만들기

- 디자인과 코드의 일관성을 유지하는 팀이 수행

애플리케이션 간의 통신은 Custom events를 사용하기

- 커스텀 이벤트를 위해 PubSubJS를 고려해 보자.

- 호출 시 URL 라우팅에 넘기기

백엔드 호출 API 구성

- BFF(Backend for Frontend Pattern) 패턴으로 프런트엔드 전용 API를 갖는다.

- 별도의 데이터베이스를 구성할 수도

- 로그인 같은 보안정보들은 통합하는 Container에서 관리하기

Reference

https://mobicon.tistory.com/572

[Micro Frontend] 마이크로 프론트앤드 - 개념

마이크로 프론트앤드는 마이크로 서비스처럼 전체 화면을 작동할 수 있는 단위로 나누어 개발한 후 서로 조립하는 방식이다. 여기서 작동 단위에 사용된 프론트앤드 프레임워크로 Angular 이든, R

mobicon.tistory.com

https://velog.io/@dalbodre_ari/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%99%80-%EB%AA%A8%EB%85%B8%EB%A0%88%ED%8F%AC-%EC%A0%9C%EB%A1%9C%EB%B9%8C%EB%93%9C

마이크로 프론트엔드와 모노레포 & 제로빌드

이것은 마치 까먹지 않기 위해 정리하는 메모장이랄까.. toss slash21 보고나서 언젠가 정리해야지 미루고 미뤘는데.. 곳곳의 세미나에서 마이크로 프론트엔드 도입기를 자랑하기 시작했다,,,,,

velog.io

자바스크립트와 V8

hmk run dev — Thu, 11 Apr 2024 21:51:05 +0900

마이크로프로세서( CPU)

일단 V8엔진에 대해서 설명하기 전에 우리가 작성한 javscsript 코드가 어떻게 실행되는지 아주 간단하게 훑어보자

컴퓨터의 모든 시스템은 마이크로프로세서(CPU)를 포함하고 있다.

지금 블로그 글을 보고 있는 것도 그 덕분이다.

마이크로프로세서는 전자적인 신호로 동작하는 기계이다.

우리는 마이크로프로세서에게 지시(instruction)를 주고 마이크로프로세서는 job을 수행한다.

여기서 지시란 것은 마이크로프로세서가 해석할 수 있는 언어로 되어있다.

일반적으로 IA-32, x86-64, MIPS 그리고 ARM이 있다.

이러한 언어들은 직접 하드웨어와 소통하며 기계어라고 불린다.

우리가 컴퓨터에 코딩한 고수준 언어들은 컴파일되어 기계어 되어 마이크로프로세서가 실행할 수 있는 형태가 된다.

음.. 사실 위의 내용엔 약간의 오류가 있다.

V8 엔진은 javascript를 기계어가 아닌 바이트 코드로 컴파일한다.

이 부분은 아래 V8엔진의 작동원리의 컴파일 단계에서 적어놓았다.

V8 엔진의 작동원리를 살표 보는 이유

자바스크립트로 뽑아낼 수 있는 최적의 성능을 사용하고 싶다면
내 코드가 어떤 식으로 실행되는지에 대한 이해는 어느 정도 있어야 한다.

V8 엔진이란?

구글이 주도하여 C++로 작성된 고성능의 자바스크립트 & 웹어셉블리 엔진

오픈 소스로 git repo에서 코드를 살펴볼 수 있다.

주로 Google Chrome과 NodeJS에서 사용되고 있으며, ECMAScript와 WebAssembly를 표준에 맞게 구현했다.

V8 엔진의 작동원리

1. 파싱(Parsing)

자바스크립트 엔진은 소스 코드를 읽고 이를 토큰으로 나누어 파싱 합니다.
파싱은 코드를 추상 구문 트리(Abstract Syntax Tree, AST)로 변환하는 과정입니다.

우리가 작성한 소스 코드를 컴퓨터가 알아먹기 쉽게 구조화하는 단계

2. 최적화(Optimiaztion)

V8 엔진은 추상 구문 트리를 최적화하는 단계를 거칩니다.
이 단계에서는 코드의 성능을 향상하기 위해 여러 최적화 기법을 적용합니다. 예를 들어, 인라이닝, 인라인 캐싱, 코드 인라이닝 등이 있습니다.

3. 컴파일(Compilation):

최적화된 추상 구문 트리는 기계어로 변환됩니다.

여기서 최적화된 코드를 바이트로 변환하는 Ignition이 실행됩니다.
V8 엔진은 고성능 JIT(Just-In-Time) 컴파일러를 사용하여 코드를 컴파일합니다.
JIT 컴파일러는 자주 사용되는 코드 블록을 미리 컴파일하여 성능을 향상합니다.

Ignition으로 바이트 코드(Bytecode) 생성하기

자바스크립트는 C++과 같은 정적 타이핑 언어가 아닌 동적 타이핑 언어라서
소스 코드가 실행되기 전에는 알 수 없는 값들이 너무 많았기 때문에 이런 접근 방법으로는 최적화를 하기도 힘들었다고 한다.

그래서 Ignition을 개발할 때는 모든 소스를 한 번에 해석하는
컴파일 방식이 아닌 코드 한 줄 한 줄이 실행될 때마다 해석하는 인터프리트 방식을 채택하여 다음 세 가지 이점을 가져가고자 하였다.

1. 메모리 사용량 감소. 자바스크립트 코드에서 기계어로 컴파일하는 것보다 바이트 코드로 컴파일하는 것이 더 편하다.
2. 파싱 시 오버헤드 감소. 바이트 코드는 간결하기 때문에 다시 파싱 하기도 편하다.
3. 컴파일 파이프 라인의 복잡성 감소. Optimizing이든 Deoptimizing이든 바이트 코드 하나만 생각하면 되기 때문에 편하다.

- Ross McIlroy Ignition - an interpreter for V8

간단하게 말해서 Ignition은 코드가 한줄한줄 실행될 때마다 코드를 바이트 코드로 바꿔주는 역할을 한다고 기억해 두면 좋다.

TurboFan으로 최적화하기

TurboFan은 최적화된 바이트코드를 기계어로 컴파일하는 역할을 합니다.

TurboFan은 V8 엔진의 최적화 단계에서 사용됩니다.
TurboFan은 최적화된 바이트코드를 받아들여 최적화된 기계어 코드로 컴파일합니다.
TurboFan은 자주 사용되는 코드 블록을 추적하고, 이를 기반으로 최적화를 수행합니다. 이를 통해 성능을 향상시키고, 실행 시간을 최소화합니다.

최적화 기법으로는 히든 클래스(Hidden Class)나 인라인 캐싱(Inline Caching) 등 여러 가지 기법을 사용한다.

간단히만 설명하면

히들 클래스 - 비슷한 것들끼리 분류해 놓고 가져다 사용

인라인 캐싱 - 자주 사용되는 코드가 만약 excute()와 같은 함수의 호출 부라면 이걸 function excute () {... }와 같이

함수의 내용으로 바꿔서 캐싱하는 기법

4. 실행(Execution):

컴파일된 코드는 CPU에서 실행됩니다.
실행 중에는 필요에 따라 동적 최적화가 수행될 수 있습니다. 이는 코드의 실행 도중에 특정 패턴이나 상황을 감지하여 더 효율적인 방식으로 코드를 실행하도록 하는 것입니다.

5. 가비지 컬렉션(Garbage Collection)

실행 중에 더 이상 사용되지 않는 메모리를 회수하기 위해 가비지 컬렉션 기능이 수행됩니다.
V8 엔진은 가비지 컬렉션을 효율적으로 수행하여 메모리 누수를 방지합니다.

그렇다면 어떻게 코드를 짜야할까?

Hidden Classes

Javascript는 컴파일시에 사용하는 타입정보에 대해 제한적이다.
Javascript는 런타임시에 데이터 타입을 변경할 수 있다.
V8은 런타임시에 객체 처리를 위해 내부적으로 hidden class를 만들어서 사용한다.

function Point(x, y) {
  this.x = x;
  this.y = y;
}

var p1 = new Point(11, 22);
var p2 = new Point(33, 44);
// 여기에서 p1과 p2는 hidden class를 공유합니다.
p2.z = 55;
// 경고! p1과 p2는 이제 다른 hidden class를 갖습니다.

결론

모든 객체 멤버를 생성자 함수 안에서 초기화 (나중에 멤버 타입이 변하지 않음)
항상 같은 순서로 멤버를 초기화

Numbers

V8은 데이터 타입 변환시 값을 효율적으로 나타내는 태그 사용
사용자가 사용하는 값을 통해서 number타입 추론
데이터 타입은 동적으로 변할 수 있기 때문에, 효율적으로 값을 나타내는 태그 사용
number타입을 지속적으로 쓰는 것이 중요

var i = 42;  // 31비트 부호있는 정수입니다.
var j = 4.2;  // 이 값은 double 타입의 부동 소수점 숫자 데이터입니다.

결론

31비트 부호있는 정수를 사용

Normal Arrays

큰 배열 처리를 위해 두가지 유형의 내부 배열 저장소가 존재한다.
- Fast Elements : 키 값이 순서대로 채워진 경우 사용되는 선형 저장소
- Dictionary Elements : 위 경우가 아닐 때 사용하는 해쉬 테이블 저장소
배열 저장소가 한 유형에서 다른 유형으로 변경되지 않는것이 중요

  a = new Array();
  for (var b = 0; b < 10; b++) {
    a[0] |= b;  // 안 좋아요!
  }
  //vs.
  a = new Array();
  a[0] = 0;
  for (var b = 0; b < 10; b++) {
    a[0] |= b;  // 훨씬 좋습니다. 2배 더 빨라요.
  }

결론

인덱스 0부터 시작하는 연속키 사용
배열 선언시 최대사이즈를 할당하지 말고 ( > 64K 원소), 사용하면서 크기를 늘려간다
숫자 배열의 요소를 삭제하지 않는다
초기화 안한 요소는 호출하지 않는다 (아래 코드 참조)

Reference

https://evan-moon.github.io/2019/06/28/v8-analysis/

V8 엔진은 어떻게 내 코드를 실행하는 걸까?

이번 포스팅에서는 구글의 V8 엔진이 어떤 방식으로 자바스크립트를 해석하고 실행하는지 살펴 보는지에 대해 포스팅하려고 한다. 은 로 작성되었지만 필자의 메인 언어가 이 아니기도 하고, 워

evan-moon.github.io

https://velog.io/@ainochi95/20mV8-%EC%97%94%EC%A7%84%EC%9D%80-%EB%AC%B4%EC%97%87%EC%9D%84-%EA%B0%9C%EC%84%A0%ED%96%88%EC%9D%84%EA%B9%8C

V8 엔진은 무엇을 개선했을까?

2012년 구글 I/O 2012에서 발표한 JS의 성능에 관련된 발표가 있다

velog.io

https://engineering.linecorp.com/ko/blog/v8-hidden-class

V8의 히든 클래스 이야기

자바스크립트가 되어 그 기분을 헤아릴 수 있다면 안녕하세요? LINE Fukuoka의 프론트엔드 엔지니어 Yonehara입니다. 저는 프론트엔드 개발자로서 아직 웹 브라우저나 자바스크립트의 기분을 헤아려

engineering.linecorp.com

https://joshua1988.github.io/web-development/web-perf/perf-tip-javascript-in-v8/

애자일(Agile) 이란?

hmk run dev — Sun, 7 Apr 2024 20:57:56 +0900

Agile

애자일은 사전적 의미론 '날렵한', '민첩한' 을 뜻한다.

소프트웨어 개발 방법론의 하나인 애자일 프로세스는

처음부터 끝까지 계획을 수립하고 개발하는 폭포수(waterfall) 방법론과는 달리

개발과 함께 즉시 피드백을 받아 유동적으로 개발하는 사상이다.

-> 방법론이라고 소개한곳도 있으나, 애자일 자체가 의미하는 것은

사상 혹은 철학일뿐이고 이러한 사상을 계승하여 나온 방법론이 칸반, 스크럼 같은 방법론이라고 한다.

- 고객 만족을 최우선으로 하는 개발(고객의 지속적인 피드백을 통해 개선)

- 짧은주기의 개발단위를 반복(ex. sprint)하여 하나의 큰 프로젝트를 나가는 방식

- 핵심은 유연성과 의사소통 그리고 동료와의 협업

애자일을 계승한 방법론 스크럼(scrum)

애자일 방법론에는 스크럼, 칸반, XP, LSD 등이 있지만 필자는 scrum만 경험해봤고,

경험에 기반한 글을 써보려고합니다.

스크럼은 프로젝트 관리의 접근 방식이며,
스프린트(sprint)라고 하는 단기 작업 븡록을 통해 프로젝트를 진행하며

비즈니스 요구를 충족시키는데 초점을 맞추기 위해 작은 목표 짧은 주기로 제품을 지속적으로 개발합니다.

스프린트 기간은 보통 1~4주 정도로 진행합니다. (필자는 보통 1~2주의 스프린트를 경험)

주요특징

- 솔루션에 포함할 기능/개선점에 대한 우선순위 부여

필자의 경우는 P1 > P5 등의 우선순위를 매겨가며 우선순위를 부여했다.

- 개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공

너무 짧으면(분석/설계/개발/테스트) 할 수 있는 시간이 부족하고,

너무 길면 느슨해지고 피드백에 대한 주기가 길어지므로 유동적으로 조절이 필요함

주기적인 스프린트 회고 시 실제로 동작하는 화면을 통해 개선점이나 문제 혹은 동료들의 다양한 피드백을 받아 볼 수도 있다.

- 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공

해당 주기의 Goal을 작성하지 않으면 목적을 잃은 기능이 될 수있음,

해당 작업의 소요 시간과 중요도와 예상 소요 기간 및 스프린트 종료 시 실제 작업에 걸린 소요 기간을 비교해

예상과 실제 작업에걸린 소요시간을 줄여가며 일정을 더 효율적으로 짤 수도 있음

- 매일 15분 정도의 Scrum 회의를 가져라

사실 해당 부분은 잘 지켜지지 않았다.

스프린트 회고가 아닌 소통은 필요시 유동적으로 소통했으며 주로 작업에 대한 진행도 예외 상황으로 인한 작업소요 리소스 증가 및

새로운 피드백 등을 주로 자유롭게 이야기했다.

회의는 너무 정형화된 딱딱한 회의가 아닌 자유로운 분위기로 진행했다.

소소하거나 사소한 이야기를 하다보면 근본적인 해결법이 나오는 경우도 종종있었다.

- 항상 팀을 우선으로 생각하라.

개인적으로 유저의 피드백 다음로 중요한 것은 팀이라고 생각한다.

자신의 task보다 주변 이슈가 더 급하다면 유동적으로 지원하거나 도와줘야한다.

(마치 배에 구멍이 생기면 구멍을 막는 것이 1순위다.)

- 원활한 의사소통을 위하여, 구분 없는 열린 공간과 마음을 유지하라

Scrum의 추구 가치

용기 : 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 위한 용기를 가져라!
(설명 : 해당 기능이 이해가 안되거나 문제가 있다면 말할 수 있어야 하고, 더 일을 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득 시켜야 한다. 또한 도전적으로 시도해보는 용기와 완료 할 수 없는 업무량이라고 모두 말 할 수 있어야 한다.)
집중 : 할 일을 하라. 모든 노력과 기술은 성공을 위해 집중하고, 그 외는 걱정(신경쓰지) 마라!
(설명 : 한번에 하나의 일부터 마무리하고, 업무에 집중 할 수 있도록 불필요한 회의 참석은 지양하며, 루틴한 반복 작업은 제거 하거나 자동화해야 한다.)
약속(헌신/책임) : 팀의 목표 달성을 위해 개개인이 공약한 목표 달성을 위해 팀에 헌신하며, 이를 달성 위해 필요한 모든 권한을 부여하라!
(설명 : 개인보다는 팀성과 달성이 우선이고, Value 있는 SW를 개발 할 수 있게 최대한 지원과 권한이 필요하다.)
존중 : 경력과 경험이 사람을 만든다. 팀원들을 존중하라!
(설명 : 개개인별로 장단점이 있고, 그 사람이 그렇게 할 수 밖에 없는 이유가 있을것이다.)
투명성/개방성 : 프로젝트에 대한 모든 내용을 투명하게 공개하라!
(설명 : 제품백로그, 스크럼 회의, 스프린트 리뷰를 통해 공유되며, 자신에게 불리해도 숨기지 않고 도움을 요청한다.)

Reference

https://medium.com/dtevangelist/scrum-dfc6523a3604

프로세스 스케줄링 알고리즘

hmk run dev — Wed, 3 Apr 2024 22:28:16 +0900

운영체제가 프로세스 스케줄링을 위해 사용하는 실질적인 방법이다.

대표적인 CPU 할당을 위한 프로세스 스케줄링 알고리즘의 종류는 아래와 같다.

1. 선입 선처리 스케줄링(FIFO)

준비 큐에 삽입된 순서대로 CPU를 할당해주는 방식이다.

먼저 실행되는 프로세스들의 실행 시간이 길다면, 대기 중인 프로세스들이 기다리는 시간이 매우 길어질 수 있다.

2. 최단 작업 우선 스케줄링(Shortest Job First)

실행 시간이 가장 짧은 프로세스부터 CPU를 할당해주는 방식이다.

3. 라운드 로빈 스케줄링(Round Robin)

준비 큐에 삽입된 순서대로 CPU를 할당하지만, 정해진 시간(타임 슬라이스)만큼만 할당해주는 방식이다.

정해진 시간동안 전부 실행되지 못했다면, 맨 마지막 순서로 돌아가서 다시 기다린다.

4. 최소 잔여 시간 우선 스케줄링

- 정해진 시간만큼 CPU를 할당하되, 다음 프로세스는 남은 작업 시간이 가장 적은 프로세스를 선택하는 방식이다.

5. 우선순위 스케줄링

- 프로세스들에 우선순위를 부여하고, 우선순위가 높은 프로세스부터 실행시키는 방식이다.

- 우선순위가 같다면, 선입 선처리로 처리한다.

- 우선순위가 낮은 프로세스는 무한정 실행되지 못하는 기아(Starvation)현상이 발생한다.

- 기아 현상 방지를 위해 오래 기다린 프로세스의 우선순위를 점차 높이는 에이징(Aging)기법을 사용한다.

6. 다단계 큐 스케줄링(Multilevel Queue Scheduling)

- 우선순위별로 준비 큐를 여러 개 사용하는 스케줄링 방식이다.

- 우선순위가 가장 높은 큐에 있는 프로세스를 먼저 처리한다.

- 우선순위가 가장 높은 큐가 비어 있으면, 그 다음 우선순위 큐를 처리한다.

- 우선 순위가 낮은 프로세스는 기아 현상이 발생할 수 있다.

7.다단계 피드백 큐 스케줄링

- 큐 간의 이동이 가능한 다단계 큐 스케줄링이다.

- 우선순위가 가장 높은 큐부터 처리를 하되, 일정 시간(타임 슬라이스)동안 못 끝낸 경우 그 다음 우선 순위 큐로 다시 이동하여 대기한다.

- CPU 사용 시간이 길수록 우선 순위가 내려가게 된다.

즉, CPU 사용 시간이 긴 CPU 집중(CPU Bound) 프로세스는 우선 순위가 상대적으로 낮아지고, CPU 사용 시간이 짧고 입출력 작업이 많은 입출력 집중(I/O Bound) 프로세스는 우선 순위가 상대적으로 높아진다.

- 에이징 기법을 통해 기아 현상을 방지한다.

Reference

https://www.youtube.com/watch?v=isj4sZhoxjk&list=PLYH7OjNUOWLUz15j4Q9M6INxK5J3-59GC&index=3

좋은 UX란 무엇일까?(feat. 프론트엔드 개발자)

hmk run dev — Sun, 31 Mar 2024 18:25:16 +0900

UX는 사용자 경험(User Experience)다.

사용자 경험을 중시하는 서비스는 반드시 성공하기 마련이다.(물론 다양한 복합적인 요소도 필요, 반박 시 그 말도 맞긴 함)

토스, 카카오 뱅크, 업비트 등등 수많은 서비스들이 증명했다.

토스나 카뱅같은 서비스가 아닌 다른 1 금융권 서비스에서

해외입출국금지 메뉴를 이용하려면 어떻게 해야 할까?

경험상, 굉장히 번거로운 몇 개의 과정을 거쳐 신청해야 한다.

심지어 은행앱을 설치했음에도 별도의 앱을 설치해야 하는 경우도 있다.

나는 이런 꼭 필요하고 자주 이용하는 메뉴임에도 이런 UX를 만나면 피가 거꾸로 솟는다....

반면에, 카뱅을 이용하면 간단하게 토글 버튼하나로 해당 서비스를 이용할 수 있다.

기가 막히다!

좋은 UX란 무엇일까?

좋은 사용자 경험(UX)은 사용자가 제품 또는 서비스를 사용할 때 느끼는 전반적인 만족과 편의성을 의미합니다. 이는 디자인, 상호 작용, 성능 및 사용자의 감정적 반응을 포함하는 다양한 요소들의 조합으로 결정됩니다. 몇 가지 주요 특징은 다음과 같습니다.

유용성: 제품이나 서비스가 사용자의 실제 필요를 충족하는지 여부. 이는 사용자가 그들의 목표를 달성하는 데 도움이 되는 기능과 정보를 제공하는 것을 의미합니다.
가시성: 사용자가 현재 위치, 가능한 작업 및 다음 단계를 명확히 이해할 수 있는지 여부. 이는 일관된 디자인 및 명시적인 내비게이션을 통해 달성됩니다.
효율성: 사용자가 목표를 달성하는 데 드는 시간과 노력을 최소화하는 것. 단축키, 자동 완성 및 예측 기능과 같은 기능이 이에 기여합니다.
참여도: 사용자가 제품 또는 서비스와 상호 작용하는 과정에서 느끼는 긍정적인 감정 및 연결. 이는 사용자의 신뢰를 구축하고 충성도를 높이는 데 중요합니다.
접근성: 모든 사용자가 제품이나 서비스에 동등하게 접근할 수 있는지 여부. 장애인을 고려한 디자인, 다양한 디바이스 및 브라우저 호환성 등이 포함됩니다.

좋은 UX에 대해 검색하면 흔히 알고 있다시피 위와 같은 내용이 나옵니다.

프런트엔드 개발자 입장에서, 이를 더 간단하게 함축해 보면 저는 아래의 4가지 요소가 고려된 서비스가 좋은 UX라고 생각이 듭니다.

1. 간편함 - 말해 뭐 해

2. 사용자의 실수를 예상하여 막아줌 - 감동

3. 디테일 - 감동

4. 성능 - 우아한 백조의 쉴 새 없이 움직이는 물장구
랜딩 페이지 로딩 소요시간 부드러운 UX, sementic, 웹접근성, LCP, INP, Light house score 등등..

프런트엔드 개발자가 UI/UX를 알아야 할까?

역할이 명확하고 큰 규모의 회사일수록 풍부한 자원과 리소스가 있으므로,

"프런트엔드 개발자는 기획, 디자인을 보고 충실하게 구현만 하면 된다"라고 생각했다.

하나, 생각해 보면 구현된 화면을 가장 많이 작동해 보고 테스트해 보고 경험해 보는 시람이 누구일까?

나는 단연코 해당화면을 구현하는 프런트엔드 개발자라고 생각한다.(이것은 소규모 스타트업 FE개발자인 필자의 경험)

주어진 디자인을 보고 구현만 하는 것을 넘어

서비스 혹은 기능의 맥락을 파악하고, 본질을 꿰뚫고, 나의 전문성을 더해 해결책을 보강하는 등

더 좋은 방법을 제시할 수 있는 역할을 할 수도 있다.

이에 더해, 요즘 FE개발자 채용공고에 UX에 대한 이해를 자격, 우대 조건으로 써놓는 회사가 많아졌다.

그렇다, 알아야 한다.

피 땀 눈물~ 흘려 만든 내 자식(프로덕트)이 어디 가서 손가락질받는 것을 원하는가?

그럼 어떻게 해야 하나?

필자는 구매대행 업자를 위한 이커머스 관련 설루션을 제공하는 서비스를 구축, 운영 중이다.

사실 UX에 대해 전문적인 지식도 없고, UX에 대한 정석적인 이론들은 잘 알지 못한다.

그럼에도 불구하고, 아래와 같은 과정으로 디자이너 혹은 기획자에게 여러 제안을 했던 경험이 있다.

1. 직접 서비스의 유저가 되어 실제 페인포인트를 제품에 녹인다.

2. 경험과 아는 지식으로 디자이너에게 제안 및 빠뜨린 부분에 대해 "정중하게" 피드백

1. 직접 서비스의 유저가 되어 실제 페인포인트를 제품에 녹인다.

앞에서 말했다시피 필자는 구매대행 업자를 위한 이커머스 관련 설루션을 제공하는 서비스를 개발하고 있다.

간단하게 말하면, 해외(중국의 타오바오 등...)에서 물건을 떼서 국내 쇼핑몰(스마트스토어, 쿠팡) 등에 파는 과정을

도와주는 서비스를 만들고 있다고 생각하면 쉽다.

그렇다, 설명이 필요할 정도의 조금 마이너? 한 서비스다. (토스, 배민 등 실생활에서 쉽게 접하기 힘든)

새로운 형태 기존에 많이 이용해 보지 못한 서비스인데, 이런 서비스를 이용하는 유저의 페인포인트를 예측하기 쉽지 않았다.

그래서 실제로 사업자등록을 하고, 여러 형태로 해외 구매대행을 직접 해보았고

실제 유저로써 느낀 불편함을 제품에 녹여내 보았다.

그 결과, 적어도 이 분야의 타업체들에 비해 더 좋은 UX를 제공하는 서비스를 만들었다고 자신한다.(이 정도 자신감은 있어도 되지 않습니까!?)

2. 경험과 아는 지식으로 디자이너에게 제안 및 빠뜨린 부분에 대해 "정중하게" 피드백

일단 이 부분에 대해선 "정중하게"라는 키워드도 중요하다.

직군마다 역할이 있고 사람마다 성향이 다르기 때문에 소프트한 커뮤니케이션이 중요하다.

다소 무례한? 피드백 및 제안 ->

상대방에 대한 호감도 및 커뮤니케이션 빈도 하락 ->

수동적인 업무 소통 ->

제품에 대한 의사소통 및 좋은 아이디어 창출 기회 하락 ->

여러 의견이 반영되지 못하고 직군별로 수동적으로 만든 좋지 못한 제품 탄생

필자는, 과거에 업무 중에 필요한, 가급적 짧고 시니컬한 소통이 더 효율적이라고 생각했었지만,

여러 피드백과 경험이 쌓이면서, 불편한 말을 불편하게 하지 않은 방법을 터득해가고 있다.

효율적이라고 생각했던 소통방식이 오히려 비효율을 초래할 수 있다.

항상 서로에 입장에 대해 생각해 보고, 서로 이해하기 쉬운 단어를 쓰고, 여유가 된다면 인간관계에 대한

글이나 영상자료, 업무 외에 소소하게 유대감을 쌓아도 좋을 것 같다.

여하튼, 사람이 하는 일이기 때문에

PM -> 디자이너 -> 개발자로 오는 과정에서 다른 사람들의 실수나 빠뜨린 점, 보완할 점을 제안하기

좋은 직군인 것 같다.

서로가 하나의 팀으로 움직이면서 각자의 지식, 전문성을 조합하며

좋은 제품을 만들 수 있는 확률을 높이는 과정이라고 생각하면 좋지 않을까 싶다.

글을 다 쓰고 보니 좋은 UX란? 무엇인가에서부터 시작해

인간관계, 좋은 제품까지 주제와 조금 동 떨어진 이야기도 많이 했다.

FE 개발자로서 배울 것이 많고, 해야 할 것이 많지만

결론적으로 그런 것들이 좋은 UX를 제공하기 위한 기반이라고 생각해도 좋을 것 같다.

리눅스 자주 쓰는 명령어

hmk run dev — Sun, 31 Mar 2024 14:06:35 +0900

주로 FE 개발을 하고 있지만, 실무에서는 종종 리눅스 명령어를 사용해야 하는 경우가 많습니다.

리눅스 명령어는 각종 테스트를 수행하거나 커널에 작업을 요청하거나 필요한 정보를 확인하는 데 유용합니다.
또한, CLI(Command Line Interface)를 통해 작업하는 것이 GUI(Graphical User Interface)보다 업무 효율을 높일 수 있습니다.
마우스를 사용하는 것보다 키보드로 명령어를 입력하는 것이 시간을 절약할 수 있습니다. (시간 -> 자원 -> 돈)

배워야하는 이유는 간략하게 나열해 볼 수 있겠네요

시스템 관리: 리눅스는 다양한 서버 및 임베디드 시스템에서 널리 사용되며, 이러한 시스템을 관리하기 위해 명령줄 인터페이스를 사용하는 것이 효율적입니다. 기본 명령어를 알고 사용함으로써 파일 및 디렉토리 관리, 프로세스 관리, 네트워크 설정 등을 수행할 수 있습니다.
문제 해결: 시스템에서 문제가 발생했을 때, 명령줄 인터페이스를 사용하여 문제를 진단하고 해결하는 것이 효과적입니다. 로그 분석, 시스템 리소스 모니터링, 프로세스 관리 등을 위해 기본 명령어를 사용할 수 있습니다.
개발 환경: 개발자들은 주로 리눅스 환경에서 작업을 수행합니다. 리눅스 명령어를 알고 사용함으로써 개발 작업을 보다 효율적으로 수행할 수 있습니다. 예를 들어, 파일 관리, 버전 관리 시스템과의 상호 작용, 서버 설정 등에 사용될 수 있습니다.
자동화 및 스크립팅: 리눅스 명령어를 사용하여 자동화된 작업이나 스크립트를 작성할 수 있습니다. 이를 통해 반복적인 작업을 자동화하고 시스템 관리를 향상시킬 수 있습니다.

1. ls

LiSt의 약자로 해당 디렉토리에 있는 파일의 목록을 나열하는 명령입니다.

- 사용예시

# ls                                   → 현재 디렉터리의 파일 목록을 표시

# ls /etc/sysconfig /etc/sysconfig    → 디렉터리의 목록을 표시

# ls -a                                → 현재 디렉터리의 목록(숨김 파일 포함)을 표시

# ls -l                                 → 현재 디렉터리의 목록을 자세히 표시

# ls *.cfg                             → 확장자가 cfg인 목록을 표시

# ls -l /etc/sysconfig/a*             → /etc/sysconfig 디렉터리 중 

                                          앞 글자가 'a'인 것의 목록을 자세히 표시

2. cd

Change Directory의 약자로 디렉토리를 이동하는 명려입니다.

- 사용예시

# cd                       → 현재 사용자의 홈 디렉터리로 이동,

                               만약 현재 사용자가 root면 '/root' 디렉터리로 이동

# cd ~rocky rocky        → 사용자의 홈 디렉터리로 이동

# cd ..                    → 바로 상위의 디렉터리로 이동

                              '..'은 현재 디렉터리의 부모 디렉터리를 의미,

                              예를 들어 현재 디렉터리가 /etc/sysconfig면 

                              바로 상위인 '/etc' 디렉터리로 이동

# cd /etc/sysconfig      → /etc/sysconfig 디렉터리로 이동(절대 경로)

# cd ../etc/sysconfig    → 상대 경로로 이동.

                             현재 디렉터리의 상위('..')로 이동한 후 

                             다시 /etc/sysconfig로 이동

3. pwd

Print Working Directory의 약자로 현재 디렉터리의 전체 경로를 화면에 표시합니다.

- 사용예시

# pwd    → 현재 작업 중인 디렉터리의 경로를 출력

숨김 파일 및 현재 디렉터리

리눅스는 숨김 파일이라는 속성이 별도로 존재하지 않고, 리렉터리 제일 앞 글자를 '.'으로 지정하면 자동으로 숨김 파일이 됩니다.

ex) .git, .gitignore

4. rm

ReMove의 약자로 파일이나 디렉터리를 삭제함

당연히 파일이나 디렉터리를 삭제할 권한이 있어야 해당 명령어를 실행할 수 있음(ex. sudo, root 사용자)

- 사용예시

# rm abc.txt       → 해당 파일을 삭제(내부적으로 'rm -i'로 연결됨)

# rm -i abc.txt    → 삭제 시 정말 삭제할 지 확인하는 메시지를 표시

# rm -f abc.txt    → 삭제 시 확인하지 않고 바로 삭제(f는 Force의 약자)

# rm -r abc        → 해당 디렉터리를 삭제(r은 Recursive의 약자)

# rm -rf abc       → r 옵션과 f 옵션을 합친 것으로 abc 디렉터리와 그 아래에 있는

                      하위 디렉터리를 강제로 전부 삭제(편리하지만 주의해서 사용해야 함)

5. cp

CoPy의 약자로 파일이나 디렉터리를 복사.

새로 복사한 파일은 복사한 사용자의 소유가 되며, 명령을 실행하는 사용자는 해당 파일의 읽기 권한 필요

- 사용예시

# cp abc.txt cba.txt     → abc.txt를 cba.txt라는 이름으로 바꿔서 복사

# cp -r abc cda         → 디렉터리 복사

6. touch

크기가 0인 새 파일을 생성하거나 생성된 파일이 이미 존재한다면 파일의 최종 수정시간을 변경합니다.

- 사용예시

# touch abc.txt    → 파일이 없는 경우 abc.txt라는 빈 파일을 생성하고,

                       abc.tx 파일이 있는 경우 최종 수정 시간을 현재 시각으로 변경

7. mv

MoVe의 약자로 디렉터리의 이름을 변경하거나 다른 디렉터리로 옮길 때 사용합니다.

- 사용예시

# mv abc.txt /etc/sysconfig/     → abc.txt을 /etc/sysconfig/ 디렉터리로 이동

# mv aaa bbb ccc ddd            → aaa, bbb, ccc 파일을 /ddd 디렉터리로 이동

# mv abc.txt www.txt            → abc.txt의 이름을 www.txt로 변경해서 이동

8. mkdir

MaKe Directory의 약자로 새로운 디렉터리를 생성합니다.

생성된 디렉터리는 명령을 실행한 사용자의 소유가 됩니다.

- 사용예시

# mkdir abc            → 현재 디렉터리 아래에 /abc 이름의 디렉터리 생성

# mkdir -p /def/fgh    → /def/fgh 디렉터리를 생성. 만약 /fgh 디렉터리의 부모 디렉터리인

                           /def 디렉터리가 없다면 자동 생성(p는 Parents의 약자)

9. rmdir

RoMove Diretory의 약자로 디렉터리를 삭제합니다.

해당 디렉터리의 삭제 권한이 있어야 하며 디렉터리는 비어야 있어야 합니다.

파일이 있는 디렉터리를 삭제하려면 rm -r 명령을 실행해야합니다.

- 사용예시

# rmdir abc    →    /abc 디렉터리를 삭제

10. cat

contCATenate의 약자로 파일 내용을 화면에 출력합니다. 여러 파일을 나열하면 파일을 연결해서 출력합니다.

- 사용예시

# cat a.txt    → a.txt 파일의 내용을 화면에 출력

11. echo

화면 출력을 담당하는 명령어

파일에 담긴 문자열을 확인할 때 사용

- 사용예시

echo [문자열]
# 문자열을 출력합니다

echo work.txt
# work.txt 파일의 문자열을 보여줍니다

echo new text > work.txt
# new text 문자열을 work.txt 파일에 있던 기존 내용을 삭제하고 추가합니다.


echo final text >> work.txt
# fianl text 문자열을 work.txt 파일의 끝 줄에 추가합니다.

echo $[환경변수명]
# 환경변수 내용을 출력합니다.

vim을 이용한 텍스트 파일 편집

Vim은 많은 기능을 가진 텍스트 편집기로, CLI에서 가장 많이 사용되는 편집기 중 하나입니다. Vim 만의 독특한 단축키가 처음에는 사용법을 익히기 어렵지만, 익숙해지면 높은 생산성을 얻을 수 있습니다.

1. 수정을 원하는 파일이 있는 경로로 이동한다

2. vim [수정을 원하는 파일명]

3. i 키를 눌러 Insert 모드로 전환후 파일 내용수정

4. 파일내용 수정 후 "ESC" 키를 눌러 Normal 모드로 전환 후 ":wq"를 입력 후 엔ㄴ터키를 눌러 저장

팀을 위하는 개발자란?

hmk run dev — Sat, 30 Mar 2024 17:02:50 +0900

코딩은 개발자들이 해야 하는 많은 일 중 하나

개발자의 필요조건일 뿐, 비즈니스 목적을 달성하기 위한 도구일 뿐

그 외에 어떤 일들이 있는가?

1. 우선순위 선정하기

2. 개발 일정과 비용 산출하기

3. 주어진 여건에서 최적의 결정하기

4. 비기능적 요구사항과 계약 조건 검토하기

5. 지리적으로 분산된 팀들과 협업하기

6. 사업 목표 이해하기

7. 전체 비즈니스에 영향을 미칠 기술 선정하기... 등등

주위를 보면

존경받는 / 함께 일하고 싶은 / 팀에 큰 전력이 되는 개발자들은

코딩뿐만 아니라 위 역량이 뛰어남

주위 개발자를 보면서 수집한 행동들을 기반으로

크게 본질, 관계, 속마음 3개의 키워드를 선정해 팀에 기여하는 개발자란 어떤 모습인지에 대해

정리해 보겠습니다.

1. 본질

Situation 1

어느 날 PM이 말했다.

"신분증 인증에서 사용자가 많이 나가네요."

[내일 입력하기] 버튼을 추가하면 어때요?

나는 이렇게 대답했다.

"좋아요 :) 프런트 공수는 얼마 안 들어요~"

좋은 대답 혹은 해결방안이었을까?

결론적으로는 맞을 수도 있고 아닐 수도 있지만.

Don't

요구사항에 대한 1차원적(수동적인) 검토라고 생각이 든다.

팀플레이어다운 응답

"우리 인증서 활용동의"를 받으면

신분증 인증 자체를 스킵할 수 있어 보여요

법무팀 검토 부탁드려 볼게요.

근본 문제 파악 -> 본인 전문성 더한 방안 제시

개발자가 기획안보다 창의적으로 풀 수 있는 문제의 예시

Learning

1. 맥락을 파악하고

2. 본질을 꿰뚫고

3. 나의 전문성을 더해 해결책을 보강한다.

코딩이 전부가 아니고, 위 작업이 업무의 일부.

Situation 2

개발 버그로

금액 장애가 빈번하게 일어나 손실이 크다.

대응

"실수했네요, 앞으로 더 신경 쓰겠습니다."

(앞으로 테스트 코드를 더 짜고 테스트를 더 해야겠다.)

Don't

문제상황 1차원적 검토

테스트코드가 문제를 실제로 해결해주지 않음

-> 문제 재발 시 개발자 역량 부족으로 비침

-> QA의 부족 등등 더 복합적 문제가 있음에도 원인 탐구기회 자체가 없어짐

팀플레이어다운 응답

"출시 후 1년간 제품 복잡도가 지수적으로 높아졌는데요,

이로 인해 기능 추가 비용이 커지고 수정에 취약한 코드가 되었습니다.

일례로 지난주의 버그는 자칫했다간 N억 원의 손실을 낼 위험이 있었습니다.

팀 차원에서 리스크의 심각성을 인지하고, 해결책을 논의해 봐요."

팀플레이어 동료들의 응답

일정 관점 - "공감합니다. 기능 개발과 코드 개선이 변행 되도록 일정을 잡아봐요."

최소 테스트 관점 - "금액 정합성 테스트만 넣어도 리스크를 줄일 수 있겠어요."

QA환경 개선 접근 - "음, 저는 손테스트조차 하기 어려운 환경이 원인인 것 같아요.

개발자 도움 없이도 기능테스트가 가능하도록 어드민을 만들면 어때요?"

Learning

겉으로 드러난 문제 이면의 원인 찾기

- 혼자 끙끙대지 말고

- 팀 차원에서 공감대 형성 후

- 목표 달성을 위한 최선의 방법을 찾아내자

1. 관계

Situation 1

어느 날 PM이 말했다.

"외부사 API 완료일이 또 늦어졌네요...

일주일 더 필요하대요. 저희 릴리즈 일정 괜찮을까요?"

응답

"저희 일정도 늦어지죠... 저희도 일주일 추가하면 될 것 같아요."

Don't

일정 지연이 유발하는 문제를 고민하지 않고 수동적으로 일정 미룸

일정의 불확실성 증가('또 미뤄지면 어떡하지?')

팀플레이어다운 응답

"외부사 API가 늦어도 X일까지 되지 않으면"

버퍼로 잡아둔 목표일정인 Y일이 불가해요.

스펙 줄여서 Y일까지 되게 만들던지, 아니면 일정을 조정해 봐요."

일정의 의존관계를 명료하게 드러냄.

듣는 이가 궁금한 "목표일까지 되어야 하는데..."에 대한 해결책도 함께 전달

Situation 2

디자이너에게 받은 시간을 보니

굉~장히 복잡한 페이지 1개가 있다.

그런데 개발 리소스가 부족하다...

응답

"오... 꽤 기능이 많은 페이지네요. 2주 내로 배포 목표해 볼게요."

(그리고 일정에 쫓겨 야근한다.)

Don't

수동적으로 디자인 검토 후 긴 개발 일정을 잡았고, 이마저도 야근으로 끝냄

개발 비용도 크고 쫓기며 개발 -> 향후 코드 유지보수 비용도 증가

팀플레이어다운 응답

- 기능의 역학관계 파악

"2주가량 걸릴 큰 스펙이네요.

여기서 X, Y는 동일 목적의 기능으로 보이는데요, 어떤가요?"

- 개발 리소스 맥락을 더해 애자일 배포 제안

(디자이너 응답 듣고)"둘을 간소화해서 개발 및 운영 공수를 줄이면

이번 주 내로 빠르게 오픈할 수 있는데

오픈 후 데이터 보고 발전시키면 어떨까요?"

Learning

임팩트에 비해 공수가 큰 작업은

중요도를 파악해 적극적으로 스펙을 줄인다.

개발공수를 투명한 전파 -> 팀이 올바른 결정을 내리는 데 일조

한 번에 여러 기능을 개발해야 한다면,

각 기능의 의존관계를 파악하고 데이터 기반으로 끊어서 배포한다.

1. 말하지 않는 것을 알아낸다.

Situation 1

동료가 어떤 생각을 하는지 궁금하다.

지금 업무가 커리어에 도움이 된다고 생각할까?

팀을 옮기고 싶어 하진 않을까?

질문

"요즘 잘 지내세요?"

Don't

생각을 검열하고 답하게 됨,

요약해서 답변하게 되어 구체적인 이야기로 들어가기 어려움

팀플레이어다운 장치

위클리(혹은 원오원)에 [역량 체크인] 템플릿 도입.

1. 최근에 해본 노력

2. 못 하고 있어 아쉬운 것

3. 블로커

회고를 통해 내 시도(긍정)와 욕구(아쉬움)를 마주하도록

나만 하는 고민이 아님을 알기

정기적 욕구파악 -> 성장할 수 있는 방향의 일을 하도록 돕기

Situation 2

요즘 성과가 잘 안 나는 것 같다...

내가 지금 하는 일 이상으로

팀의 성과를 폭발시킬 다른 일이 있을까?

거시적 관점이 있는 PM에게 물어보자.

질문

"요즘 XX 한 문제가 있는 것 같아요.

해결하기 위해 제가 더 할 수 있는 일이 있을까요?"

Don't

평소에 생각해 본 질문이 아니라면 의미 있는 답을 주기 어려움.

답변이 XX 문제에 집중됨(이상의 문제가 있을 수 있는데)

팀플레이어다운 질문

"요즘 일할 때 XX가 잘 안 된다고 느껴져요... PM님은 어떠세요?"

PM이 관련한 고민과 시도를 전달해 줌 ->

내 전문성을 더해 풀어낼 수 있을지 함께 고민

내 고민 먼저 오픈 -> 상대방 최근 생각을 이끌어냄 -> 문제 공감대 맞추기

-> 각자 전문성을 발휘할 수 있는 최선의 해결책을 찾기

Learning

포괄적 질문은 -> 포괄적 답변을 이끎

상황을 쉽게! 떠올릴 수 있도록 질문

e.g 커뮤니케이션에 대한 철학을 말해주세요 (X)

지난 프로젝트에서 동료가 어려움을 겪었을 때 어떤 행동을 하셨나요? (O)

상황파악 전까지는 판단 유보 -> 진실을 찾아낼 수 있는 접근

정리

업무 전후에 다음 질문을 되물어보자

- 본질이 무엇인가?

- 어떤 관계가 얽혀있는가?

- 이들이 말하지 않은 속마음은 무엇인가?

-> 모두 본질을 찾는 여정

권할 수 있는 액션아이템

앞으로 1달간, 동료의 멋진 행동 3개 모아 보기

- 자주 들여다보지 않아도 됨. 관찰하고 적어 객관화하는 것만으로도 의미.

- 있어 보이게 쓸 생각 없이 막 적어보는 게 중요 -> 나중에 10개 모이면 정리

- 사례를 적고, 액션아이템을 끌어내자

사례 예시)

- 맥북 구매요청을 할 때 본인뿐 아니라 팀을 챙기고 수치적 근거를 제시하는 게 멋지다(성능으로 인한 시간소비 -> 내 자원 낭비 -> 논리적 근거)

Action Item

- 당연해 보이는 일이라도 수치를 들어 설득력 있게 말하자

- 나뿐이 아니고 팀의 문제임을 용기 있게 판단하고 뚝심 있게 해결하자

나의 Action Item

- 1년 뒤에 이불킥 하기

do, don't를 현재 제 뇌에서 짜낼 수 있는 가장 좋은 방법으로 적었지만,

1년 뒤에 다시 보면 이불킥 할 것 같기도.

다만, 이불킥 한다는 건 성장했다는 반증이니, 이불킥 하기를 바랍니다.

Reference

https://www.youtube.com/watch?v=ZYKcD2gKlvg&t=1013s

알아두면 쓸데 있는 GOF 디자인 패턴

hmk run dev — Thu, 28 Mar 2024 22:50:31 +0900

디자인 패턴은 프로그램을 개발하는 과정에서 빈번하게 발생하는
디자인 설계문제를 정리해서 상황에 따라 간편하게 적용할 수 있게 정리한 것입니다.

선배 개발자 분들의 시행착오 끝에 그중 가장 효과적이라고 알려진 패턴으로

잘 활용할 수만 있다면 적지 않은 시간과 노력, 시행착오를 줄일 수 있습니다.

간략하게 미리 알아두고 풀고 싶은 문제가 있을 때 적재적소에 적용한다면 좋겠습니다!

디자인 패턴 용도에 따라 나누기

가장 대중적으로 널리 알려진 나누는 기준은 생성, 구조, 행동으로 나눈 기준입니다.

생성 패턴(Creational Pattern)

객체 인스턴스를 생성하는 패턴으로, 객체를 생성하는 방법과 시점을 추상화하고, 코드의 유연성, 재사용성 및 유지보수성을 향상시킵니다.

싱글턴 패턴(Singleton Pattern)

클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 패턴입니다.
이 패턴을 사용하면 해당 클래스의 인스턴스에 전역적으로 접근할 수 있는 지점을 제공하여, 어디서든 해당 인스턴스에 접근할 수 있게 됩니다.

싱글톤 패턴은 주로 리소스 공유, 로깅, 캐시, 설정 관리 등과 같이 시스템 전반에 걸쳐 단 하나의 인스턴스만 필요한 경우에 사용됩니다.
그러나 싱글톤 패턴은 전역 상태를 만들어내는 것이므로 남발하면 코드의 유지보수성과 테스트 용이성에 부정적인 영향을 줄 수 있습니다.

사용예시

우리는 종종 하나의 객체를 프로그램 내에서 공유하고 싶을 때가 있습니다.
예를 들어, 데이터베이스 연결, 로그 라이터 등과 같은 리소스를 효율적으로 활용하고자 할 때가 그러한 경우입니다.

그러나 매번 새로운 객체를 생성하는 것은 비효율적일 뿐만 아니라 예기치 못한 문제를 초래할 수 있습니다.

싱글턴 패턴은 클래스의 인스턴스가 하나만 생성되도록 보장하고, 그 인스턴스에 대한 전역적인 접근점을 제공합니다.

추상 팩토리 패턴(Abstract Factory Pattern)

서로 관련된 객체들의 집합을 생성하기 위한 인터페이스를 제공합니다.
이 패턴은 클라이언트 코드가 구상 클래스를 직접 생성하는 것이 아니라, 팩토리 객체를 통해 객체를 생성하고 관리하도록 합니다.

사용예시

간단한 모바일 전략 게임을 개발 중입니다. 이 게임에서는 유닛(병사, 기병, 궁수 등)을 생성해야 합니다.

각 유닛은 공격력, 방어력 등의 속성을 가지고 있으며, 다른 유닛들과 전투 혹은 방어를 할 수 있어야 합니다.

이러한 상황에서 추상 팩토리 패턴을 활용할 수 있습니다.

코드

// 추상 유닛 클래스
abstract class Unit {
    abstract attack(): void;
    abstract defend(): void;
}

// 병사 클래스
class Infantry extends Unit {
    attack(): void {
        console.log("Infantry attacks with sword.");
    }

    defend(): void {
        console.log("Infantry defends with shield.");
    }
}

// 궁수 클래스
class Archer extends Unit {
    attack(): void {
        console.log("Archer attacks with bow and arrow.");
    }

    defend(): void {
        console.log("Archer defends with evasion.");
    }
}

// 추상 팩토리 인터페이스
interface ArmyFactory {
    createUnit(): Unit;
}

// 병사를 생성하는 구체적인 팩토리 클래스
class InfantryFactory implements ArmyFactory {
    createUnit(): Unit {
        return new Infantry();
    }
}

// 궁수를 생성하는 구체적인 팩토리 클래스
class ArcherFactory implements ArmyFactory {
    createUnit(): Unit {
        return new Archer();
    }
}

// 게임 클라이언트
class GameClient {
    constructor(private factory: ArmyFactory) {}

    prepareArmy(): void {
        const unit = this.factory.createUnit();
        unit.attack();
        unit.defend();
    }
}

// 테스트
const infantryFactory = new InfantryFactory();
const archerFactory = new ArcherFactory();

const gameClient = new GameClient(infantryFactory);
gameClient.prepareArmy();

const gameClient2 = new GameClient(archerFactory);
gameClient2.prepareArmy();

팩토리 메서드 패턴(Abstract Factory Pattern)

이 패턴은 객체를 생성하기 위한 인터페이스를 정의하고, 객체의 생성을 서브 클래스에 위임하여 객체 생성 방법을 캡슐화합니다.

사용예시

메시지의 타입에 따라 각기 다른 클래스 인스턴스를 반환하는 PacketFactory

export class PacketFactory {
  static createProcessor<T, G>(type: MessageType): PacketProcessor<T, G> {
    let processor;

    switch (type) {
      case 'authentication':
        processor = new AuthenticationProcessor();
        break;
      case 'exchangeRate':
        processor = new ExchangeRateProcessor();
        break;
      case 'keywordAnalysis':
        processor = new NaverKeywordTrendProcessor();
        break;
      case 'getHTMLStringFromUrl':
        processor = new ScrapHtmlProcessor();
        break;
      case 'getNaverImageSearch':
        processor = new NaverImageSearchProcessor();
        break;
      case 'getAccessToken':
        processor = new AccessTokenProcessor();
        break;
      case 'sendProduct':
        processor = new ProductProcessor();
        break;
      case 'taobaoImageSearch':
        processor = new TaobaoImageSearchProcessor();
        break;
      case 'taobaoProductSearch':
        processor = new TaobaoProductSearchProcessor();
        break;
      case 'getMainKeyword':
        processor = new MainKeywordProcessor();
        break;
      case 'getBlobs':
        processor = new BlobConvertProcessor();
        break;
      default:
        throw new Error(`no process for ${type}`);
    }

    return processor;
  }
}

추상 팩토리 패턴: 관련된 객체들의 집합을 생성하기 위한 인터페이스를 제공하고, 해당 인터페이스의 구현을 통해 객체 생성을 위임합니다. 여러 종류의 관련 객체를 생성할 때 사용됩니다.

팩토리 메서드 패턴: 객체를 생성하는 인터페이스를 정의하고, 이를 서브 클래스에서 구현하여 객체 생성 방법을 변경할 수 있도록 합니다. 즉, 객체 생성을 처리하는 로직을 Creator 클래스와 Concrete Creator 클래스로 분리합니다.

행동 패턴(Behavioral Pattern)

객체 간의 상호작용과 책임 분배에 중점을 둡니다

템플릿 메소드 패턴(Abstract Factory Pattern)

알고리즘의 뼈대를 정의하고 알고리즘의 일부를 서브클래스로 디자인 패턴 확장하여
알고리즘의 일부를 재정의할 수 있도록 하는 패턴입니다.

템플릿 메소드 패턴은 코드의 중복을 줄이고 유연성을 향상시킵니다향상합니다.
공통으로 사용되는 알고리즘의 구조를 한 곳에 유지하면서,

알고리즘의 일부를 서브클래스에서 오버라이드하여 다양한 구현을 제공할 수 있습니다.

사용예시

전자제품을 생산하는 공장을 운영한다고 가정해봅시다가정해 봅시다.
공장에서는 제품을 생산하기 위한 표준적인 절차가 있을 것입니다.

이를 템플릿 메소드 패턴을 사용하여 구현할 수 있습니다.

코드

// 전자제품 클래스
abstract class ElectronicsProduct {
    // 제품 생산의 템플릿 메소드
    produce(): void {
        this.assembleComponents();
        this.testProduct();
        this.packageProduct();
    }

    // 제품을 조립하는 단계
    abstract assembleComponents(): void;

    // 제품을 테스트하는 단계
    abstract testProduct(): void;

    // 제품을 포장하는 단계
    abstract packageProduct(): void;
}

// 스마트폰 클래스
class Smartphone extends ElectronicsProduct {
    assembleComponents(): void {
        console.log("Assembling smartphone components.");
    }

    testProduct(): void {
        console.log("Testing smartphone functionality.");
    }

    packageProduct(): void {
        console.log("Packaging smartphone for shipment.");
    }
}

// 노트북 클래스
class Laptop extends ElectronicsProduct {
    assembleComponents(): void {
        console.log("Assembling laptop components.");
    }

    testProduct(): void {
        console.log("Testing laptop functionality.");
    }

    packageProduct(): void {
        console.log("Packaging laptop for shipment.");
    }
}

// 테스트
const smartphone = new Smartphone();
smartphone.produce();
console.log("---------------------");
const laptop = new Laptop();
laptop.produce();

상태 패턴(State Pattern)

객체의 내부 상태가 바뀔 때 객체의 행동을 변경할 수 있도록 하는 패턴입니다.
객체의 행동은 현재 상태에 따라 달라지며, 상태를 객체로 캡슐화하여 상태에 따른 행동을 별도로 구현합니다.
이 패턴은 객체가 다양한 상태를 가질 수 있고, 각 상태에 따라 다르게 동작해야 할 때 유용하게 사용됩니다.

사용예시

자판기를 상태 패턴으로 구현한다고 가정해봅시다.

자판기는 여러 가지 상태를 가질 수 있습니다.

예를 들어, "동전 투입 대기", "음료수 선택 대기", "음료수 배출 대기" 등의 상태가 있을 수 있습니다.

코드

// 상태 인터페이스
interface VendingMachineState {
    insertCoin(): void;
    selectItem(): void;
    dispenseItem(): void;
}

// 자판기 클래스
class VendingMachine {
    private state: VendingMachineState;

    constructor(state: VendingMachineState) {
        this.state = state;
    }

    // 상태 변경 메소드
    setState(state: VendingMachineState) {
        this.state = state;
    }

    // 자판기의 행동 메소드
    insertCoin() {
        this.state.insertCoin();
    }

    selectItem() {
        this.state.selectItem();
    }

    dispenseItem() {
        this.state.dispenseItem();
    }
}

// 각 상태에 따른 클래스 구현
class WaitForCoin implements VendingMachineState {
    insertCoin() {
        console.log("동전을 투입했습니다.");
        // 다음 상태로 변경
        vendingMachine.setState(new SelectItem());
    }

    selectItem() {
        console.log("동전을 먼저 투입해주세요.");
    }

    dispenseItem() {
        console.log("음료수를 선택해주세요.");
    }
}

class SelectItem implements VendingMachineState {
    insertCoin() {
        console.log("이미 동전이 투입되었습니다.");
    }

    selectItem() {
        console.log("음료수를 선택했습니다.");
        // 다음 상태로 변경
        vendingMachine.setState(new DispenseItem());
    }

    dispenseItem() {
        console.log("음료수를 먼저 선택해주세요.");
    }
}

class DispenseItem implements VendingMachineState {
    insertCoin() {
        console.log("이미 동전이 투입되었습니다.");
    }

    selectItem() {
        console.log("이미 음료수가 선택되었습니다.");
    }

    dispenseItem() {
        console.log("음료수를 배출합니다.");
    }
}

// 테스트
const vendingMachine = new VendingMachine(new WaitForCoin());
vendingMachine.insertCoin(); // 동전을 투입했습니다.
vendingMachine.selectItem(); // 음료수를 선택해주세요.
vendingMachine.dispenseItem(); // 음료수를 선택해주세요.

반복자 패턴( iterator Pattern)

객체들의 집합을 순차적으로 접근하고 조작하기 위한 디자인 패턴입니다.
이 패턴은 컬렉션의 내부 구조에 독립적으로 컬렉션의 요소를 열거할 수 있도록 합니다.
이는 컬렉션의 요소를 순차적으로 접근하는 일반적인 인터페이스를 정의하고, 이 인터페이스를 구현한 반복자 객체를 사용하여 컬렉션의 요소에 접근합니다.

옵서버 패턴( observer Pattern)

옵저버 패턴은 객체 간의 일대다 종속성을 정의하는 디자인 패턴입니다.
이 패턴은 주로 상태나 데이터의 변화를 감지하고 이에 대응하는 행동을 수행할 때 사용됩니다.

프런트엔드 상태관리 라이브러리인 redu 툴은 observer 패턴을 기반으로 구현되어 있습니다.

참고로 zustand는 React의 ContextApi를 이용해 상태관리 제공

사용예시

주제(Subject)와 구독자(Observer)를 나타내는 클래스를 구현하여 이벤트 발생 시 구독자들에게 알리는 방법

코드

Subject 인터페이스는 주제(Subject) 역할을 정의하고, 구독자 관리와 알림을 위한 메소드를 포함합니다.
Observer 인터페이스는 구독자(Observer) 역할을 정의하고, 주제로부터 업데이트를 받기 위한 update 메소드를 포함합니다.
ConcreteSubject 클래스는 실제 주제를 구현하며, 상태 변경 시 등록된 모든 구독자에게 알림을 보냅니다.
ConcreteObserver 클래스는 실제 구독자를 구현하며, 주제로부터 메시지를 받아 출력합니다.

// 주제(Subject) 인터페이스
interface Subject {
    attach(observer: Observer): void;
    detach(observer: Observer): void;
    notify(): void;
}

// 구독자(Observer) 인터페이스
interface Observer {
    update(message: any): void;
}

// 구체적인 주제 클래스
class ConcreteSubject implements Subject {
    private observers: Observer[] = [];
    private state: any;

    getState(): any {
        return this.state;
    }

    setState(state: any): void {
        this.state = state;
        this.notify();
    }

    attach(observer: Observer): void {
        this.observers.push(observer);
    }

    detach(observer: Observer): void {
        const index = this.observers.indexOf(observer);
        if (index !== -1) {
            this.observers.splice(index, 1);
        }
    }

    notify(): void {
        for (const observer of this.observers) {
            observer.update(this.state);
        }
    }
}

// 구체적인 구독자 클래스
class ConcreteObserver implements Observer {
    update(message: any): void {
        console.log("Received message:", message);
    }
}

// 테스트
const subject = new ConcreteSubject();
const observer1 = new ConcreteObserver();
const observer2 = new ConcreteObserver();

// 구독자들을 주제에 등록
subject.attach(observer1);
subject.attach(observer2);

// 상태 변경 시 모든 구독자들에게 알림
subject.setState("New state!");

구조 패턴( Structural Pattern)

클래스나 객체들 사이의 관계를 강화하고 구성하는 방법을 제공하여 코드의 유지보수성, 재사용성, 확장성을 향상시킵니다.

데코레이터 패턴(Decorator Pattern)

객체에 동적으로 새로운 기능을 추가하는 패턴입니다. 이 패턴은 상속을 사용하지 않고도 객체의 기능을 확장할 수 있게 해줍니다.

서브클래스를 만들 때보다 유연하게 기능흘 확장할 수 있습니다.

사용예시

커피 주문 시 커피에 여러 가지 토핑을 추가하는 상황을 가정하겠습니다.

Coffee 인터페이스는 기본 커피의 동작을 정의합니다.
SimpleCoffee 클래스는 기본 커피를 구현합니다.
CoffeeDecorator 추상 클래스는 데코레이터의 기본 구조를 정의합니다.
MilkDecorator와 WhippedCreamDecorator 클래스는 각각 우유와 휘핑 크림을 추가하는 데코레이터를 구현합니다.

코드

// 커피 인터페이스
interface Coffee {
    cost(): number;
    getDescription(): string;
}

// 기본 커피 클래스
class SimpleCoffee implements Coffee {
    cost(): number {
        return 5;
    }

    getDescription(): string {
        return "Simple Coffee";
    }
}

// 데코레이터 클래스
abstract class CoffeeDecorator implements Coffee {
    protected decoratedCoffee: Coffee;

    constructor(coffee: Coffee) {
        this.decoratedCoffee = coffee;
    }

    cost(): number {
        return this.decoratedCoffee.cost();
    }

    getDescription(): string {
        return this.decoratedCoffee.getDescription();
    }
}

// 토핑 데코레이터 - 우유
class MilkDecorator extends CoffeeDecorator {
    constructor(coffee: Coffee) {
        super(coffee);
    }

    cost(): number {
        return super.cost() + 2;
    }

    getDescription(): string {
        return super.getDescription() + ", Milk";
    }
}

// 토핑 데코레이터 - 휘핑 크림
class WhippedCreamDecorator extends CoffeeDecorator {
    constructor(coffee: Coffee) {
        super(coffee);
    }

    cost(): number {
        return super.cost() + 3;
    }

    getDescription(): string {
        return super.getDescription() + ", Whipped Cream";
    }
}

// 테스트
let coffee: Coffee = new SimpleCoffee();
console.log(coffee.getDescription(), "costs", coffee.cost());

coffee = new MilkDecorator(coffee);
console.log(coffee.getDescription(), "costs", coffee.cost());

coffee = new WhippedCreamDecorator(coffee);
console.log(coffee.getDescription(), "costs", coffee.cost());

프록시 패턴(Proxy Pattern)

한 객체에 대한 접근을 제어하거나 대리자 역할을 하는 객체를 제공하여 추가적인 기능을 제공하거나 제어하는 패턴입니다.

사용예시

이미지 로딩을 지연시키는 프록시를 구현해보겠습니다.

코드

Image 인터페이스는 이미지의 기본 동작을 정의합니다.
RealImage 클래스는 실제 이미지를 로딩하고 표시합니다.
ImageProxy 클래스는 실제 이미지를 로딩하기 전까지는 실제 이미지를 생성하지 않습니다. 대신, 이미지가 요청될 때마다 실제 이미지를 로딩하여 표시합니다.

// 이미지 인터페이스
interface Image {
    display(): void;
}

// 실제 이미지 클래스
class RealImage implements Image {
    private filename: string;

    constructor(filename: string) {
        this.filename = filename;
        this.loadFromDisk();
    }

    private loadFromDisk(): void {
        console.log("Loading image:", this.filename);
    }

    display(): void {
        console.log("Displaying image:", this.filename);
    }
}

// 이미지 프록시 클래스
class ImageProxy implements Image {
    private filename: string;
    private realImage: RealImage | null;

    constructor(filename: string) {
        this.filename = filename;
        this.realImage = null;
    }

    display(): void {
        if (!this.realImage) {
            this.realImage = new RealImage(this.filename);
        }
        this.realImage.display();
    }
}

// 테스트
const image1: Image = new ImageProxy("image1.jpg");
const image2: Image = new ImageProxy("image2.jpg");

// 이미지 1은 처음에 로딩이 발생
image1.display();
// 이미지 1은 두 번째 호출부터 로딩이 발생하지 않음
image1.display();
// 이미지 2는 처음에 로딩이 발생
image2.display();

어댑터 패턴(Proxy Pattern)

서로 다른 인터페이스를 가진 두 개의 클래스를 함께 작동할 수 있도록 변환하는 패턴입니다.

이는 기존의 코드를 수정하지 않고도 새로운 인터페이스에 맞춰 사용할 수 있도록 도와줍니다.

사용예시

콘센트를 변환하여 다른 지역에서도 사용할 수 있는 장비를 구현해보겠습니다.

코드

// 한국 콘센트 인터페이스
interface KoreanPlug {
    supplyPower(): void;
}

// 한국 콘센트 구현 클래스
class KoreanSocket implements KoreanPlug {
    supplyPower(): void {
        console.log("Korean plug is supplying power.");
    }
}

// 미국 콘센트 인터페이스
interface USPlug {
    provideElectricity(): void;
}

// 미국 콘센트 구현 클래스
class USASocket implements USPlug {
    provideElectricity(): void {
        console.log("US plug is providing electricity.");
    }
}

// 어댑터 클래스
class KoreanToUSAdapter implements USPlug {
    private koreanPlug: KoreanPlug;

    constructor(koreanPlug: KoreanPlug) {
        this.koreanPlug = koreanPlug;
    }

    provideElectricity(): void {
        console.log("Adapter is converting Korean plug to US plug.");
        this.koreanPlug.supplyPower();
    }
}

// 테스트
const koreanPlug: KoreanPlug = new KoreanSocket();
const adapter: USPlug = new KoreanToUSAdapter(koreanPlug);

adapter.provideElectricity();

파사드 패턴(Proxy Pattern)

복잡한 서브시스템의 인터페이스를 단순화시켜 사용자에게 더 쉽게 접근할 수 있도록 하는 패턴입니다.

이를 통해 클라이언트는 복잡한 서브시스템을 직접 다루지 않고도 사용할 수 있습니다.

사용예시

컴퓨터를 부팅하는 과정을 파사드 패턴을 사용하여 구현해보겠습니다.

코드

CPU, Memory, Display 클래스는 각각 CPU, 메모리, 디스플레이의 동작을 구현합니다.
ComputerFacade 클래스는 이러한 서브시스템을 간단한 인터페이스로 묶어줍니다. startComputer 메서드를 통해 클라이언트는 컴퓨터를 부팅할 수 있습니다.
클라이언트 코드에서는 ComputerFacade 인스턴스를 생성하고 startComputer 메서드를 호출하여 컴퓨터를 부팅합니다.

// CPU 클래스
class CPU {
    public bootUp(): void {
        console.log("CPU is booting up...");
    }
}

// 메모리 클래스
class Memory {
    public load(): void {
        console.log("Memory is loading...");
    }
}

// 디스플레이 클래스
class Display {
    public displayImage(): void {
        console.log("Displaying image...");
    }
}

// 파사드 클래스
class ComputerFacade {
    private cpu: CPU;
    private memory: Memory;
    private display: Display;

    constructor() {
        this.cpu = new CPU();
        this.memory = new Memory();
        this.display = new Display();
    }

    public startComputer(): void {
        console.log("Starting computer...");
        this.cpu.bootUp();
        this.memory.load();
        this.display.displayImage();
        console.log("Computer started.");
    }
}

// 클라이언트 코드
const computerFacade = new ComputerFacade();
computerFacade.startComputer();

Reference

https://m.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS8616098823

Node.js 메모리 누수(feat. SSR)

hmk run dev — Mon, 25 Mar 2024 21:38:03 +0900

이 글로 얻을 수 있는 것

- 메모리릭을 디버깅 할 수 있는 자신감!

- Node.js 환경이든 브라우저 환경이든

크롬 브라우저의 Memory 탭에서 메모리 누수의 범인을 찾을 수 있음!

메모리 누수(Memory Leak)이란?

메모리 누수는 실제로는 필요하지 않은데,

메모리를 계속 차지하고 있는 현상

메모리 누수가 있으면 뭐가 문제일까?

JS를 동작시킬 메모리가 부족하니까, 성능이 좋지 않게 된다.

- GC의 활동이 늘어나면, CPU 사용량이 늘어난다.

- CPU intensive한 작업이 늘어나면, 이벤트 루프가 블로킹되서 연산이 느려진다.

띄워놓은 Node.js 서버가 죽는다.

- SIGABRT 등의 시그널로 인한 프로세스 종료

- 인스터스가 재시작되고 일부 요청에 대한 응답이 실패할 수 있음

- 로드밸런서가 HTTP Status 502(Bad Gateway) 에러를 뱉을 수 있어요

- 가용성에 문제가 있을 수 있단 뜻!

메모리 누수 해결방법은?

1. 힙메모리를 늘려주거나 => 근본적인 해결방법은 아니다!

2. 메모리 누수의 범인을 디버깅한다.

메모리 누수가 있는지 어떻게 알 수 있을까?

아래와 같이 터미널에서 확인할 수 있다!

실제로는 터미널을 계쏙 보고 있기보다는, 모니터링 툴을 활용한다!

메모리 누수 모니터링

모니터링은 크게 서버사이드와 클라이언트 사이드로 나뉠 수 있습니다.

서버의 경우에는 크게 아래와 같은 서비스를 이용해 모니터링을 합니다!

클라이언트 사이드 같은 경우에는 모니터링 도구 자체를 붙이기는 어렵다.

=> 어떤 브라우저를 쓰는지, 하드웨어가 어떤건지에 대해서 많이 달라질 수 있기때문

메모리 누수가 발생하는 코드는 모니터링 도구에서 어떻게 보일까?

코드로 살펴 봅시다.

- 요청을 받으면 응답을 내려주고 200 status를 내려주는 node.js 코드

const server = http.createServer((req, res) => {
	res.writeHead(200, {'Content-Type': 'text/html'});
    res.write(`
    	<!DOCTYPE html>
        <html lang="en">
            <head>
		<title>Hello World</title>
            </head>
            <body>
            	<h1>Content</h1>
            </body>
	</html>
    `);
    
    res.end();
})

SSR 이면서 유저의 트래픽을 받는 상황을 재현하기 위해

아래와 같이 내가 띄워놓은 로컬 서버에 쉘스크립트를 이용해 요청을 보내는 방법을 재현했습니다.

메모리 누수가 없는 코드

- 백만번의 반복문을 돌려 listItems에 i 값을 push

- 현재 프로세스의 힙메모리 사이즈 측정

- 요청 로깅 및 메모리 측정

위와 같이 메모리 사이즈가 고만고만하고 일정한 경우엔

모니터링 도구의 메모리 사용 그래프는 아래 처럼 크게 변동이 없음!

메모리 누수가 있는 코드

메모리 누수가 없는 코드와 별반 차이는 없지만

listItems변수를 전역변수로 선언했음

메모리 사용량이 점차 올라간다!

그러다가 서버가 죽는다!

메모리 누수를 해결해보자!

1. 힙메모리 사이즈 늘리기

결론적으론 아니다!

힙메모리를 늘려줘도 위의 코드는 계속해서 메모리 누수를 일으킨다!

그전에 간략하게 V8이 메모리를 관리하는 방식을 알아보자

V8은 GC 알고리즘으로 Mark and Sweep 방식을 주로 사용합니다.

간단히 말해서, 사용하는 것은 Mark 사용하지 않는 것은 Sweep(치워버림) 합니다.

원시타입이 아닌(array, object, function- js는 함수도 일급객체 등등..)
경우 변수들은 힙메모리에 할당 받아서 사용하게 되는데,

사용하는 것은 mark 아닌것은

GC가 한번 돌면서 불필요한 객체를 수거해서 Sweep!

GC에 의해 정리되지 않고 계속해서 메모리가 살아남아 있다면?

V8은 힙메모리를 관리하기 위해 영역을 나눠서 관리합니다.

기본적으로 Young Generation과 Old Generation으로 나눠져 있고,

GC도 Minor와 Major로 나눠져 있습니다.

처음 선언한 객체가 있다면 nursery(유아기) 영역에 해당되는 곳에 메모리가 할당되게 된다.

그리고 GC가 한번 돌고 해당 메모리가 살아있다면

중간기에 해당하는 intermediate로 넘어가게 됩니다.

두 번째에도 GC에서 살아남았다?

Old Generation으로 가게된다.

V8 문서를 살펴보게 되면 Old Generation 영역까지 살아남은 메모리는 거의없다! 라고 나와 있습니다.

Nursey: 처음 Object이 할당된 공간

Intermeditate: 첫 GC에서 살아남아 이동한 공간

Old Generation: 두 번째 GC에서 살아남아 이동한 공간

Old Generation이 꽉찬 상태가된다?

-> 서버가 죽는다! 꿱!

전역으로 선언된 listItems는

함수안에서 계속해서 참조하기 때문에 Old Generation 영역으로 이동하게 될 것 입니다.

요청이 올 수록 계속해서 GC에 의해 수거되지 않고 메모리 영역을 계속해서 커집니다!

그렇다면 힙 메모리를 늘려주면 메모리 누수가 사라질까? => 당근 아니요

단순하게 구글링을 하게되면 아래와 같이 해결법이 나온다.

- Node.js 메모리 부족 어떻게 해결함?

=> --max-old-space-size 고고

참고로 각각 영역의 사이즈를 늘려주는 옵션이 있습니다.

--max-old-space-size 는 Old Generation(Old Space) 영역

--max- semi-space-size * 3 는 Young Generation(New Space) 영역

계속 살아남은 객체는 Old space로,

계속 힙메모리를 차지하면 OOM((Out of Memory)은 시스템이 더 이상 메모리를 할당할 수 없을 때 발생하는 오류)

대표적인 메모리 누수를 일으키는 요인들

1. 전역변수

2. 해제되지 않은 타이버(clearTimeout 등)

3. 클로저 - 실행컨텍스트 안에서 어떤 변수 혹은 어떤 객체를 참조하고 있을지 몰라 힙메모리 할당이 많이 필요할 수도!

고로 메모리를 늘리는 것이 근본적인 해결법이 될 순 없다!

메모리 누수의 범인을 디버깅

간단한 옵션으로 디버깅하기

node --inspect index.js

chrome에 inspect 옵션을 활용하는 방법도 있다.

Reference

https://www.youtube.com/watch?v=P3C7fzMqIYg&list=LL&index=12&t=343s

의도적 수련

hmk run dev — Sat, 23 Mar 2024 18:46:03 +0900

의도적 수련이란 자신의 기량 향상을 목적으로 반복적으로 하는 것이다.

단순 노동이 아니라 자신의 약점을 개선하려고 노력하는 것만이 의도적 수련이다.
업무를 하면서 의도적 수련을 같이 하려면 업무를 하면서 빠르게 피드백받고 교정하면서 성장하는 "애자일 철학"이 필요하다.

양치질을 30년 했다고 매일 똑같은 패턴, 강도로 반복만하니 양치질의 고수라고 하지 않는다.

같은 일을하더라도 어떤 분야에서 전문가가 되려면 의도적 수련을 해야한다.

개발을 예로들면,

단순한 것을 개발하더라도,

더 빠르게, => 속도, 기존 로직 혹은 비즈니스 요구 파악, 이전에 쌓아 놨던 재사용성의 도움

더 안전성 있게, => 테스트

더 재사용 가능하게,

더 확장에 용이하게,

더 동료들이 이해하기 쉽게,

위와 같은 사항들을 항상 상기시키면서 개발을 해야하지 않나 싶고,

주기적으로 동료나 혹은 다른 사람들에게 피드백을 받고 회고 하는 프로세스가 필요하지 않나 싶다.

- 함께자라기 中

김프로의 회사생활 팁 feat. 개발자 (아주 중요하지만 아무도 안 알려주는)

hmk run dev — Fri, 22 Mar 2024 20:12:49 +0900

15년 차 정도되는 시니어 개발자분이 감사하게도,

회사생활에 대한 사내 세미나를 열어주셨다.

평소에 같은 동료로서, 같은 개발자로서 존경심을 갖고 계셨던 분이 해주셨던 말들을 짧게 요약해 보고,

"어떤 사람이 일을 잘하는 사람인가?"에 대한 개념이 잘 서지 않을 때마다 봐야겠다.

프로? 아마추어?

어떤 한 분야(종목)에 대해서

- 아마추어 : 돈을 내고 즐긴다.

- 프로 : 돈을 받고 직업으로 일한다.

ex) 게이머

- 아마추어 : 시간이 날 때 틈틈이 즐긴다. 꼭 승리하지 않아도 즐거우면 OK

- 프로 : 목표는 승리, 승리를 위해서라면 합법적인 모든 방법을 동원해서 목적달성

프로(의식)?

- 몸값에 맞는 가치를 한다.

> 사장님 또는 고객은 쉽게 돈을 주지 않는다.

> 항상 내가 생각하는 것보다 훨씬 높은 가치를 원한다.

- 어떤 상황이든 항상 꾸준히 성과를 낸다.

- 목표를 달성하기 위해 끊임없이 노력한다.

- 누가 알려주지 않아도 스스로 살아남기 위해 노력한다.

- 살아남는 문제: 동물 vs 인간

> 야생에서 동물은 어떻게 살아남는가

- 프로로서 자세를 유지한다. (성과는 둘째 치고)

- 내가 하고 싶은 것을 하는 게 아니라 회사가 원하는 걸 한다.

회사는 어떤 사람을 소중하게 생각하는가

(제일 위가 제일 소중한 사람)

- 어떻게든 책임지고 끝까지 과업을 달성하는 사람

- 조직에 필요한 역할을 해주는 사람

- 일을 잘하는 사람

- 누가 하라고 안 해도 해야 할 일을 스스로 찾아서 하는 사람

-....

- 실력만 아주 뛰어난 사람

-....

프로의식에 대한 나만의 기준이 필요

내가 얼마나 성과를 냈을 때 회사에서 만족하는가

회사가 나에게 원하는 것이 무엇인지 잘 알고 있다.

스스로 파악하여 객관적으로 알고 있는 것이 중요

프로 회사원 (개발자?)

- 회사에 현재 어떤 일이 중요한지 거시적으로 파악한다.

- 동료의 성향을 파악한다.

- 동료가 이해할 수 있는 언어를 사용한다.

- 사양을 꼼꼼하게 파악한다. 사양에 부족한 부분이나 이해하지 못한 부분은 물어본다.

- 테스트를 어떻게 할지 개발하기 전에 고민한다.

- 상상하지 않고 적혀있는 대로 기계적으로 개발한다.

- 동작하도록 개발한다.

- 보는 사람이 이해하기 쉽게 다듬는다. (코드리뷰 시간 단축 전략 필요, 시간 => 자원 => 돈)

- 각 배포 환결별로 테스트, 테스트, 테스트....

=> 개발 자체보다 개발 외적인 것들이 생각보다 비중이 크다.

나는 어떤 프로가 될 것인가

경력 이직은 인맥이 반

같이 일했던 동료 중 좋았던 동료를 다른 회사에서도 찾게 되어있음

위아래 옆 포함해서 나는 그들에게 책임감 있는 동료로 보여야 한다.

생각 정리

나는 프로인가 아마추어인가

직업 시장에서 어떻게 살아남을 것인가

전문가가 될 것인가, 단순한 직장인이 될 것인가

단순한 직장인으로 사는 것이 얼마나 가능한가

일에 프로가 되지 않으면 일에 포로가 된다.

나의 첨언

개발자 커리어 내내 나는 어떤 제품을 만들게 될 것이다.

그 제품은 나의 걸어온 커리어를 대표하는 얼굴들이며,

이러한 마음가짐을 가지고 위에서 말했던, 프로자세로 나의 제품들을 만들어야겠다.

프론트엔드와 디자인 패턴

hmk run dev — Wed, 20 Mar 2024 23:02:19 +0900

디자인 패턴이란?

소프트웨어에서 디자인 패턴은 반복적으로 발생하는 문제 상황에 대한 해결책을 제시하는 일반적인 설계 템플릿입니다. 디자인 패턴은 소프트웨어 공학에서의 최선의 실천 방법을 정리하고, 재사용 가능한 코드를 작성하기 위한 지침을 제공합니다.

디자인 패턴은 다음과 같은 주요 목적을 가지고 있습니다:

재사용성: 디자인 패턴은 특정 문제에 대한 해결책을 제공하므로, 해당 문제가 발생할 때마다 동일한 패턴을 재사용할 수 있습니다. 이를 통해 코드의 재사용성이 증가하고, 개발 시간과 비용을 절감할 수 있습니다.
유지보수성: 디자인 패턴은 코드의 구조화를 도와주며, 코드의 의도를 명확하게 전달합니다. 이는 코드를 이해하고 유지보수하는 과정을 단순화하고 오류를 방지할 수 있도록 돕습니다.
확장성: 디자인 패턴은 변경 가능성이 높은 부분을 식별하고, 해당 부분을 분리하여 추상화함으로써 시스템의 확장성을 향상합니다. 새로운 요구사항이나 기능 추가 시에도 시스템을 유연하게 확장할 수 있습니다.
커뮤니케이션: 디자인 패턴은 개발자들 간의 의사소통을 촉진합니다. 공통된 용어와 개념을 사용함으로써 팀 내에서 더 효율적으로 협업할 수 있습니다.

일반적으로 디자인 패턴은 생성(Creational), 구조(Structural), 행위(Behavioral) 세 가지 범주로 나누어집니다. 이러한 패턴들은 특정 문제 해결을 위해 공식화된 해결책을 제시하며, 이를 통해 소프트웨어의 품질을 향상시키고 개발 과정을 단순화합니다.

프런트엔드의 디자인패턴

수많은 애플리케이션, 소프트웨어가 있지만 FE의 관점에서 어떻게 발전해 왔고, 어떤 문제가 있었는지 작성했습니다.

MVC 디자인패턴

View

- 화면에 보이는 UI

Model

- 데이터 영역

- javascript 메모리, 백엔드를 통해 받는 데이터, DB 등등의 소프트웨어의 데이터

Controller

- Model과 View 사이의 중간 역할

- Model의 데이터를 받아서 화면을 만듦, 사용자의 동작을 받아 Model을 변경

- 사용자와의 상호작용을 담당

초창기의 웹 서비스의 MVC

사실 프런트엔드라는 직종의 역사는 그리 깊지 않다.

클라이언트단의 사양이 복잡해지고 SPA 등의 프론트엔드 프레임워크가 본격적으로 등장하면서 생기게 되었다.

이전에는 프런트와 백엔드의 구분이 명확하지 않고, 웹사이트가 그 자체로 View의 역할을 수행하는 것으로 개발되었다.

Model - DB

View - HTML & CSS & JS
Controller - 라우터를 통해 데이터를 처리하고 새로운 HTML을 만들어서 보여주는 영역

JQuery 등장 후 MVC

Model - ajax를 이용해 받아온 백엔드 데이터

View - HTML & CSS & JS
Controller - 사용자 입력을 처리하고 모델과 뷰 사이의 상호작용을 조정하여 UI 로직을 제어

MVC를 최대한 분리해야 한다는 원칙에 맞게, HTML과 jQuery를 따로 관리하는 것이 이 패턴의 주요 포인트

단점

- View를 업데이트하기 위해서 결국 Model과 View 사이의 의존성이 강해질 수 있고, 이는 규모가 커질수록 복잡성이 증가하게 됨

- 데이터를 연동하고 받아오는 과정에서 반복적인 패턴이 자주 발생

- Controller에 책임이 많아져 Controller에 부하가 생길 수 있음

MVP 디자인패턴

MVC 구조에서 View와 Model 간의 의존성을 해결하기 위해 제시된 모델이다. Controller 대신 Presenter가 생긴 구조로, 한때 Android 개발에서 가장 인기 있었던 구조라고 한다.

Model

- 데이터를 관리

View

- 데이터를 보여주는 방식을 정의

- 사용자의 action이 들어오면 presenter에게 전달

Presenter

- Model과 VIew 사이의 중계자 역할

- 서로의 요청과 응답을 전달해 줌

장점

View - Model 사이의 의존성 문제를 해결한다.

단점

View - Presenter가 1:1로 연결되면서 View와 Presenter 사이의 의존성이 발생하게 된다.

MVVM 디자인패턴

구글에서 발표한 앵귤러 프레임워크의 출시와 함께 웹 프런트엔드의 개발 방식에 패러다임이 바뀌기 시작한다.

jQuery를 이용해 DOM을 직접 조장하는 방식에서, 템플릿과 바인딩을 통한 선언적 반식으로 변화하게 된다.

MVC의 역할을 그대로이나 구현하는 방식이 바뀐 것에 가깝다고 할 수 있다.

FE 코드에서 DOM을 직접 조작하는 방식이 조금씩 지양되고,

대신 프레인워크가 조작하는 방향으로 바뀌고, 개발자는 화면에 그려져야 할 데이터만 만들면 프레임워크가 알아서 그려주었다.

이를 View를 그리는 Model만 신경 쓰게 되었다는 의미로 ViewModel이라고 부른다.

Model

- 데이터

View

- UI

ViewModel

- Model을 가지고 View를 그리는 역할이자, View가 Model과 상호작용할 수 있게 하는 역할,

- UI의 재사용 가능한 부분을 추상적으로 표현할 수 있음

앵귤러 이후 React, Vue, Svelte 등 템플릿, 바인딩 문법의 차이가 조금씩 있을 뿐, MVVM이라는 아키텍처는 대부분

그대로 유지되어 왔습니다.

장점

컨트롤러의 반복적인 기능을 선언적인 방식으로 개선하였다.
Model과 View의 관점을 분리하지 않고, 하나의 템플릿을 통해 관리하려는 방식으로 발전하게 된다.
웹의 DOM api를 잘 몰라도 비지니스 로직만으로 서비스를 만들 수 있다.

Flux 패턴

기존의 MVC 아키텍처는 컴포넌트의 재사용과 독립성에 중점을 둔 구조였습니다.
그러나 프로젝트의 규모가 커지고 복잡성이 증가함에 따라, MVC에서는 모델의 관리가 어려워지고 데이터의 흐름이 복잡해지는 문제가 발생했습니다. 특히, 같은 데이터를 공유할 때에는 props를 통해서만 데이터를 전달할 수 있어서 모델의 관리가 파편화되는 경향이 있었습니다. 이러한 문제에 대한 해결책으로 Flux 패턴이 등장하게 되었습니다.

Flux는 단방향 데이터 흐름을 중심으로 한 아키텍처로, 데이터의 흐름을 명확히하여 애플리케이션의 상태 관리를 더욱 효율적으로 할 수 있게 해주었습니다.

또한 데이터 플로우를 단방향으로 유지하여 어플리케이션 상태의 복잡성을 줄이고 데이터 변화를 더욱 쉽게 예측가능한 방식으로 처리합니다.

props drilling

컴포넌트 구조가 복잡할 때에 발생하는 Props Drilling Problem
특정 sibling에서 같은 데이터를 공유하고 사용하려 할 때 구조가 번거로워질 수밖에 없다.

⇒ 단방향 아키텍처(uni-directional architecture)에 대한 제안이 등장한다.
⇒ 비지니스 로직과 View를 아예 분리하며, 이 개념을 상태 관리(State Management)라고 부른다.

MVC 컴포넌트 관점에서 벗어나, View를 그냥 하나의 큰 단위로 바라보는 관점이다.

View에서 Dispatch를 통해 Action을 전달 → 전달된 Action에서는 Reducer를 통해 Store에 데이터를 보관 → Store에 있는 데이터는 다시 View로 연결 (단방향 cycle)

Action
Dispatcher
Store

장점

Props drilling problem의 해소
다양한 상태 관리 라이브러리가 등장하는 등 많은 영감을 줌 (Redux, Vuex 등)

단점

장황한 문법으로 인한 높은 학습 비용
Action, Dispatch, Reducer를 만들고 관리해야 하므로 관리가 어려워짐

이외의 방법들

Atomic Pattern

거대한 View 영역과 Store 영역을 나누는 것은 동일하나, Action-Dispatch-Reducer 구조는 너무 복잡하기 때문에 손쉽게 Model에 접근하는 방법만 제공하는 것을 목표로 하는 패턴이다.

간단한 문법으로 컴포넌트 외부에서 공통의 데이터를 set, get하고 동시에 동기화를 하는 방향성이다. 더불어 computed, derived, select 등의 반응형 기능을 제공하여 관련된 데이터의 동시 업데이트를 제공한다.

Recoil, Svelte Store, Vue Composition, iotai 등이 해당한다.

React-Query

상태 관리에 편향되어 있던 시각에서 벗어나 다시 MVC의 개념을 확대하는 방향으로, 고전적인 ajax의 데이터를 Model로 간주한다.

대부분의 프론트엔드 개발은 서버 데이터를 CRUD하고 UI를 그리는 것이 중점인데, Flux, Atomic은 비동기 데이터를 처리하기에는 너무 복잡한 방법이라는 관점이다.

Model: 서버에서 데이터를 fetch 해오는 영역
View: React
Controller: query & mutation. 서버 데이터의 상태를 관리하고 캐싱, 동기화, refetch 등을 관리

GraphQL

미리 스키마를 정의하고 이를 기반으로 데이터를 교환한다. (Schema based 아키텍처)

이 역시 서버 데이터를 Model로 간주하고, 서버와의 통신을 통해 View에게 데이터를 전달하는 방식이다.

polling, websocket, sse 서버의 event를 클라이언트로 보내는 방법

hmk run dev — Sun, 17 Mar 2024 22:17:24 +0900

polling

클라이언트가 평범한 http request를 서버로 계속 날려서 이벤트 내용을 전달받는 방식이다.
가장 쉬운방법이지만 클라이언트가 계속적으로 request를 날리기때문에 클라이언가 많아지면 서버의 부담이 급증하게 된다. http request connection을 맺고 끊는것 자체가 부담이 많은 방식이다. 그리고 클라이언트에서 실시간정도의 빠른 응답을 기대하기도 어렵다.
polling은 http 오버헤드가 발생한다는 단점이 있다.
하지만 일정하게 갱신되는 서버 데이터의 경우 유용하게 사용할 수 있는 방식이다. (ex. 대시보드 갱신)

SocketSSE(Server-Sent-Event)

	Socket	SSE
브라우저 지원	대부분 브라우저에서 지원	대부분 모던 브라우저 지원(polyfills 가능)
통신 방향	양방향	일방향(서버에서 클라이언트로)
리얼타임	Yes	Yes
데이터 형태	Binary, UTF-8	UTF-8
자동 재접속	No	Yes(3초마다 제시도)
최대 동시 접속 수	브라우저 연결 한도는 없지만 서버 셋업에 따라 다름	HTTP를 통해서 할 때는 브라우저당 6개 까지 가능 / HTTP2로는 100개가 기본
프로토콜	websocket	HTTP
베터리 소모량	큼	작음
Firewall 친화적	Nope	Yes

websocket

양방향 채널을 이용해 채팅방 처럼 양방향 통신이 가능하다.
기존 http요청 응답 방식은 요청한 그 클라이언트에만 응답이 가능했는데, ws 프로토콜을 통해 웹소켓 포트에 접속해 있는 모든 클라이언트에게 이벤트 방식으로 응답한다
최초 접속이 일반 http request를 통해 handshaking과정을 통해 이루어 지기 떄문에, 기존의 80, 443 포트로 접속을 하므로 추가로 방화벽을 열지 않고도 양방향 통신이 가능하고, http 규격인 CORS적용이나 인증등의 과정을 기존과 동일하게 가저갈 수 있는것이 장점이다.
단, websocket 프로토콜을 처리하기 위해 전이중 연결과 새로운 웹소켓 서버가 필요하다.

SSE (Server-Sent Events)

HTML5 표준안이며 어느정도 웹소켓의 역할을 하면서 더 가볍다.
websocket 과 같이 양방향이 아닌 server -> client 단방향이기에 서버의 event 나 message를 client 로 push 하는 작업에 유용하게 사용될 수 있다.
양방향이 아니기에 요청 시 ajax로 쉽게 이용할 수 있다.
재접속 처리 같은 대부분의 저수준 처리가 자동으로 지원된다.
IE는 기본 미지원이지만, polyfill을 이용할 경우 IE를 포함한 크로스브라우징이 가능하다.

교착 상태 해결 방법

hmk run dev — Sat, 16 Mar 2024 21:10:10 +0900

교착 상태 해결

- 예방

- 회피

- 검출 후 회복

교착 상태 예방

참고로, 교착 상태 조건 중 하나라도 충족되지 않는다면 교착상태는 절대로 발생하지 않는다.

- 애초에 교착 상태가 발생하지 않도록 예방

- 교착 상태 발생 조건(상호 배제, 점유와 대기, 비선점, 원행 대기) 중 하나를 없애버리기

상호배제 없애기

모든 자원을 공유 가능하게 만든다?

=> 이론적으로 가능하지만 현실적인 해결법은 아니다.

점유와 대기 없애기(자원을 할당받은 상태에서 자원을 대기하는 것)

특정 프로세스에 자원을 모두 할당하거나, 아예 할당하지 않는 방식으로 배분

=> 자원의 활용률을 낮출 수 있는 방식

비선점 조건을 없애기

선점이 가능한 자원(e.g CPU)에 한해 효과적

=> 모든 자원이 선점 가능한 것은 아니다. (한 프로세스의 작업이 끝날 때까지 다른 프로세스는 이용할 수 있는 자원이 꽤 있음. ex 프린터)

원형 대기 조건 없애기(서로가 서로의 자원을 기다리는 방식)

모든 자원에 번호를 붙이고 오름차순으로 할당하면 원형 대기는 발생하지 않음

=> 자원에 번호를 붙이는 것은 어려운 작업, 어떤 자원에 어떤 번호를 붙이느냐에 따라 활용률이 달라진다.

=> 그나마 가장 실용적이고 현실적인 방법

교착 상태 회피

- 교착 상태를 무분별한 자원 할당으로 인해 발생했다고 간주

- 교착 상태가 발생하지 않을 만큼 조심 조심 할당하기

- 배분할 수 있는 자원의 양을 고려하여 교착 상태가 발생하지 않을 만큼만 자원 배분

안전 순서열 : 교착 상태 없이 안전하게 프로세스들에 자원을 할당할 수 있는 순서

안전 상태 : 교착 상태 없이 모든 프로세스가 자원을 할당 받고 종료될 수 있는 상태

=> 안전 순서열이 있는 상태

불안전 상태 : 교착 상태가 발생할 수도 있는 상태

=> 안전 순서열이 없는 상태

회피 예시

- 컴퓨터 시스템에 총 12개의 자원

- 프로세스 P1, P2, P3가 각각 5개, 2개, 2개의 자원을 할당받아 실행 중 (운영체제가 배분할 수 있는 자원의 개수는? 3개)

- 프로세스 P1, P2, P3는 각각 최대 10개, 4개, 9개 자원을 요구할 수 있다고 가정

안전 순서열이 존재: P1 -> P2 -> P3

프로세스 P1, P2, P3이 모두 최대로 자원을 요구한 최악의 상황 가정

- 안전 상태에서 안전 상태로 움직이는 경우에만 자원을 할당하는 방식

- 항시 안전 상태를 유지하도록 자원을 할당하는 방식

- c.f. 은행원 알고리즘

교착 상태 검출 후 회복

- 교착 상태의 발생을 인정하고 사후에 조치하는 방식

- 프로세스가 자원을 요구하면 일단 할당, 교착 상태가 검출되면 회복

- 선점을 통한 회복, 프로세스 강제 종료를 통한 회복

선점을 통한 회복

- 교착 상태가 해결될 때까지 한 프로세스씩 자원을 몰아주는 방식

프로세스 강제 종료를 통한 회복

- 교착 상태에 놓인 프로세스 모두 강제 종료(-> 작업 내역을 잃을 위험)

- 교착 상태가 해결될 때까지 한 프로세스씩 강제 종료(-> 오버헤드)

Reference

https://www.youtube.com/watch?v=zQDNXklvdUw&list=PLVsNizTWUw7FCS83JhC1vflK8OcLRG0Hl&index=38

교착상태(Dead lock)

hmk run dev — Fri, 15 Mar 2024 00:03:42 +0900

프로세스가 실행이 되려면 자원이 필요합니다

두 개 이상의 프로세스가 각자 갖고 있는 자원들을 그저 기다리기만 한다면,

그 어떤 프로세스도 실행되지 못하고 이를 교착상태라고 합니다.

식사하는 철학자 문제로 엿보는 교착상태

보이는 것처럼 원형 식탁에 다섯 명의 철학자가 앉아 있고

철학자 앞에는 음식과 포크가 있습니다.

음식을 먹으려면 꼭 2개의 포크가 필요합니다.

모든 철학자들이 동시에 위와 같은 순서로 식사를 한다면,

모든 철학자들이 식사를 하지 못하게 된다.

이런 식으로 일어나지 않을 사건을 기다리며 진행이 멈춰 버리는 현상을 "교착상태"라고 합니다.

여기서 철학자는 프로세스고

포크는 실행에 꼭 필요한 자원

식사는 자원을 이용함 => 실행에 빗댈 수 있습니다.

서로가 점거하고 있는 자원을 서로가 기다리면 그 어떤 스레드나 프로세스가 실행될 수 없음을 시사합니다.

실제 예시로는

게임과 브라우저가 각각 필요한 자원을 계속 점거하고 있어서,

서로 실행을 할 수 없는 경우를 예로 들 수 있습니다.

교착 상태 해결하기

교착 상태가 발생했을 때의 상확을 정확히 표현해 보기

자원 할당 그래프

- 어떤 프로세스가 어떤 자원을 할당받아 사용 중인지 확인 가능

- 어떤 프로세스가 어떤 자원을 기다리고 있는지 확인 가능

1. 프로세스는 원으로, 자원(cpu, 메모리 등등)의 종류는 사각형으로 표현

2. 사용할 수 있는 자원의 개수는 자원 사각형 내에 점으로 표현

3. 어떤 프로세스가 어떤 자원을 할당받아 사용 중이라면 자원에서 프로세스를 향해 화살표 표시

4. 프로세스가 어떤 자월을 기다리고 있다면 프로세스에서 자원으로 화살표를 표시

아래 그래프를 보면

SSD는 3개 CPU가 3개 프린터가 1대인데

각각

A - SSD

B - CPU

C - CPU

D - 프린터

E - 프린터의 사용 기다림

F - CPU 할당을 기다림

교착 상태가 일어난 그래프의 특징은

자원 할당 그래프가 원의 형태를 띄고 있다!

교착 상태가 일어나는 근본적인 이유 이해하기

교착 상태가 발생할 조건

1. 상호 배제 - 한 프로세스가 사용하는 자원을 다른 프로세스가 사용할 수 없는 상태

2. 점유와 대기 - 자원을 할당 받은 상태에서 다른 자원을 기다리고 있는 상태 (위의 예시 중 게임과 브라우저 그림 & 철학자 식사 그림 참고)

3. 비선점 - 어떤 프로세스도 다른 프로세스의 자원을 강제로 빼앗지 못하는 상태

4. 원형 대기 - 프로세스들이 원의 형태로 자원을 대기하는 상태

위 네 가지 조건 중 하나라도 만족하지 않으면 교착 상태가 발생하지 않음

위 네 가지 조건 중 모두 만족하면 교착 상태가 발생할 수 있음

자바스크립트의 call by value와 call by reference

hmk run dev — Wed, 13 Mar 2024 21:00:17 +0900

자바스크립트에서 함수 호출 방식인 Call by Value와 Call by Reference에 대해 알아보겠습니다.

먼저, 각각의 개념을 살펴보고, 이것이 리액트에서 상태값을 업데이트 할 때 어떻게 작용할 수 있는지 살펴볼 것입니다.

자바스크립트에서 함수를 호출할때 매개변수를 할당 받을 수 있습니다.
매개변수는 여러개가 될수도있고 단일값일수도있고 객체나 또 다른 함수가 될 수도 있습니다.
매개변수를 전달하는 방식에 따라서 Call by value , Call by reference 로 나눌 수 있습니다.

Call by Value (값에 의한 호출)

Call by Value는 함수에 인자를 전달할 때, 해당 값의 복사본이 함수로 전달되는 방식을 말합니다. 이는 원시 데이터 타입(숫자, 문자열, 불리언 등)을 다룰 때 발생합니다. 함수 안에서 매개변수 값을 변경하더라도 호출한 곳의 변수 값에는 영향이 없습니다.

단일 값에 의한 매배변수 전달은 함수를 호출했을때 함수내에서 지역변수로서 사용되며 따라서 값이 복사되어 사용됩니다.

즉, 함수 내에서만 값의 변경이 발생하고 원본 값에는 영향을 주지 않습니다.

- 값의 불변성을 유지할 수 있지만

- 지역변수로 복사하여 활용하는만큼 메모리를 소모합니다.

function increment(x) {
  x++;
}

let num = 5;
increment(num);
console.log(num); // 출력 결과: 5

Call by Reference (참조에 의한 호출)

Call by Reference는 함수에 인자로 변수의 주소(참조)가 전달되는 방식을 말합니다.

이는 객체나 배열과 같은 참조형 데이터 타입을 다룰 때 발생합니다. 함수 내에서 객체의 속성을 변경하면, 호출한 곳의 객체에도 영향을 미칩니다.

객체 즉, 참조에 의한 매개변수 전달은 값이 전달되는것이 아니라 해당 객체가 저장된 메모리의 주소를 넘겨주게됩니다.

즉, 값의 복사가 아니라 원본데이터와 동일한 메모리주소를 바라보고 있습니다.

때문에 함수내에서 값의 변경이 이루어지게되면 원본값 또한 변하게 됩니다.

값의 복사가 아닌 메모리에 직접 접근이기 때문에 처리가 빠르고 메모리를 절약 할 수 있지만 원본데이터의 불변성이 지켜지지 않는다는 단점이 있습니다.

function addElement(arr, element) {
  arr.push(element);
}

let myArray = [1, 2, 3];
addElement(myArray, 4);
console.log(myArray); // 출력 결과: [1, 2, 3, 4]

React의 useState와 Call by reference

리액트에서 상태값이 업데이트되지 않는 문제는 주로 객체나 배열과 같은 참조형 데이터를 다룰 때 발생할 수 있습니다.

이는 JavaScript의 특성 중 Call by Reference와 관련이 있습니다.

이 문제를 이해하고 해결하기 위해서는 상태값을 업데이트할 때 주의해야 할 몇 가지 사항이 있습니다.

1. 불변성(Immutability) 유지:

리액트에서 상태를 업데이트할 때는 기존 상태를 직접 수정하지 말고, 이전 상태를 기반으로 새로운 객체나 배열을 생성하여 사용해야 합니다. 불변성을 유지하지 않으면 React는 상태 변화를 감지하지 못하고 리렌더링이 이뤄지지 않을 수 있습니다.

// 잘못된 방법
const incrementCount = () => {
  setCount({ value: count.value + 1 });
};

// 올바른 방법: spread 연산자를 사용하여 새로운 객체 생성
const incrementCount = () => {
  setCount(prevState => {
    return { ...prevState, value: prevState.value + 1 };
  });
};

2. 함수형 업데이트 사용:

setState에서 제공하는 함수형 업데이트를 활용하면, 이전 상태를 바탕으로 업데이트를 수행할 수 있습니다. 이렇게 하면 현재 상태의 참조를 직접 변경하지 않아도 안전하게 상태를 업데이트할 수 있습니다.

const incrementCount = () => {
  setCount(prevState => ({ ...prevState, value: prevState.value + 1 }));
};

3. 깊은 복사 활용:

객체나 배열을 다룰 때는 깊은 복사를 활용하여 복사본을 생성한 후 업데이트 작업을 수행할 수 있습니다.

const updateArray = () => {
  const newArray = [...myArray];
  newArray.push(4);
  setMyArray(newArray);
};

4. Object.assign 사용:

Object.assign 함수를 사용하여 객체를 복사하고 업데이트할 수도 있습니다.

const incrementCount = () => {
  setCount(prevState => Object.assign({}, prevState, { value: prevState.value + 1 }));
};

상태값을 업데이트할 때 이러한 방식을 고려하면 리액트 애플리케이션에서 발생하는 상태 업데이트 문제를 해결할 수 있습니다.

항상 불변성을 유지하고, 함수형 업데이트를 사용하며, 적절한 복사 방식을 선택하여 상태를 업데이트하는 습관을 기르면 좋겠네요 :)

자바스크립트 가비지 콜렉션

hmk run dev — Sun, 10 Mar 2024 22:53:44 +0900

가비지 콜렉션이란?

가비지 콜렉션은 자바스크립트 엔진이 자동으로 더 이상 사용되지 않는 메모리를 찾아내고 해제하는 프로세스를 의미합니다. 개발자가 명시적으로 메모리를 해제할 필요가 없어져 코드 작성이 간편해지는 장점이 있습니다.

메모리 관리의 중요성

메모리 관리는 프로그램의 성능과 안정성에 직접적인 영향을 미칩니다. 메모리 누수가 발생하면 시스템이 불안정해지고, 성능이 저하될 수 있습니다. 가비지 콜렉션은 이러한 문제를 해결하여 개발자가 메모리를 효율적으로 사용할 수 있도록 도와줍니다.

가비지 콜렉션의 작동 원리

자바스크립트 엔진은 주기적으로 가비지 콜렉션을 수행합니다. 이때, 더 이상 사용되지 않는 객체를 찾아내고, 해당 객체가 참조하는 메모리를 해제합니다. 이는 프로그램이 실행 중에 동적으로 생성되는 객체들 중에서 필요 없어진 것들을 체크하는 방식으로 이루어집니다.

1. 레퍼런스 카운팅 방식

레퍼런스 카운팅은 각 객체가 몇 개의 참조를 가지고 있는지 세는 방식입니다. 객체의 참조가 증가하거나 감소할 때마다 해당 객체의 참조 카운트를 갱신하고, 참조 카운트가 0이 되면 해당 객체를 해제하는 방식입니다. 이 방식은 단순하고 빠르지만 순환 참조(circular references) 문제에 취약합니다.

let x = {
  a: {
    b: 2,
  },
};
// 2개의 객체가 생성되었습니다. 하나의 객체는 다른 객체의 속성으로 참조됩니다.
// 나머지 하나는 'x' 변수에 할당되어 참조됩니다.
// 명백하게, 가비지 콜렉션 수행될 메모리는 하나도 없습니다.

let y = x;
// 'y' 변수는 위의 객체를 참조하는 두 번째 변수입니다.

x = 1;
// 이제 'y' 변수가 위의 객체를 참조하는 유일한 변수가 되었습니다.

let z = y.a;
// 위의 객체의 'a' 속성을 참조했습니다.
// 이제 이 객체는 두 개의 참조를 가집니다.
// 'y'가 속성으로 참조하고 'z'라는 변수가 참조합니다.

y = "mozilla";
// 이제 맨 처음 'x' 변수가 참조했던 객체에 대한 참조가 없기 때문에, 가비지 컬렉션이 가능합니다.
// 그러나, 객체의 'a' 속성이 여전히 'z' 변수에 의해 참조되므로
// 메모리를 해제할 수 없습니다.

z = null;
// 이제 맨 처음 'x' 변수가 참조했던 객체의 'a' 속성에는
// 참조가 없으므로 가비지 콜렉션이 수행될 수 있습니다.

순환 참조한계

function f() {
  const x = {};
  const y = {};
  x.a = y; // x는 y를 참조합니다.
  y.a = x; // y는 x를 참조합니다.

  return "azerty";
}

f();

2. 마크 앤 스위프(Mark and Sweep) 방식

"sweep(쓸어버린다)"라고 이름을 붙였듯이, 이건 힙 메모리에 있는 모든 도달 불가능한 객체를 치워버립니다.

마크 앤 스위프는 레퍼런스 카운팅의 한계를 극복하기 위해 개발된 가비지 콜렉션 알고리즘 중 하나입니다.

현재 거의 모든 최신 자바스크립트엔진은 해당 방식을 사용합니다. 이 알고리즘은 다음과 같은 단계로 작동합니다.

마크(Mark) 단계: 루트(root)로부터 시작해 모든 도달 가능한(Reachable) 객체를 표시(mark)합니다. 이는 활성 객체들을 표시하는 단계로, 더 이상 도달할 수 없는 객체는 표시되지 않습니다.

스위프(Sweep) 단계: 마크되지 않은 모든 객체를 해제(sweep)합니다. 이 단계에서는 가비지로 판단되는 객체들을 해제하고, 메모리를 회수합니다.

간단한 동작방식

1. 모든 객체들의 marked bit들을 false로 설정

2. 도달할 수 있는 객체면 true 마크

3. 도달할 수 없는 객체는 힙에서 정리됨

장점

순환참조 문제를 제어할 수 있고 무한루프 문제 해결

단점

마크 앤 스위프 방식은 순환 참조 문제를 해결하고 메모리를 효과적으로 관리할 수 있는 장점이 있습니다.
그러나 이 알고리즘은 프로그램이 일시적으로 실행이 중단될 수 있고, 메모리 회수를 위해 일정한 시간이 소요될 수 있다는 단점이 있습니다.

자바스크립트 엔진은 이러한 가비지 콜렉션 알고리즘을 효과적으로 조합하여 최적의 성능을 제공하도록 노력하고 있습니다.

지속가능한 컴포넌트 Effective Component

hmk run dev — Sun, 10 Mar 2024 12:58:42 +0900

지속 가능한 프런트엔드 컴포넌트를 개발하는 과정에서 중요한 측면 중 하나는 기획이 변경되었을 때 코드 수정이 필요한 상황에 대한 대비책을 마련하는 것입니다.

코드의 수정이 필요한 경우가 생겼을 때, 심지어 모든 코드가 필요 없어질 수도 있는 상황이 발생할 수 있습니다. 그러나 이는 제품이 변화하고 성장하는 과정에서 피할 수 없는 현상이며, 고객이 원하는 사용자 경험을 제공하기 위해는 빠르게 대응할 필요가 있습니다.

여기서 강조해야 할 중요한 이유 중 하나는 모든 사용자가 제품을 원활하게 사용하고 있는 경우에도 제품이 변경되어야 하는 이유가 있다는 점입니다.

제품은 사용자의 니즈와 시장 동향에 부응하기 위해 지속적으로 발전하고 있으며, 기획이나 디자인이 언제든지 변할 수 있습니다. 이러한 유연성은 사용자가 원하는 것을 빠르게 찾고, 그에 맞게 제품을 개선하는 데 중요한 역할을 합니다.

고객의 니즈는 기회로 여겨져야 합니다.

빠르게 변화하는 환경에서는 사용자의 니즈를 정확히 예측하기 어렵습니다. 따라서 변경을 예측하지 않고 유연하게 대응하는 것이 필요합니다. 이를 통해 제품은 사용자 경험을 향상하고, 고객들의 니즈에 빠르게 대응하여 가치를 지속적으로 창출할 수 있습니다.

변경을 예측하지 않고 대응하기

제품은 보통 아래의 흐름과 같이 만들어집니다.

작은 컴포넌트나 모듈이 합쳐지면서 기능이 만들어지고

기능이 만들어지면 "적당히" 분리해야 합니다.

이때 적당히의 기준이 명확해야 하는데요

아래의 Item이라는 컴포넌트는 어떤 컴포넌트일까요?

어떤 데이터를 다루는지

데이터를 어떻게 보여주는지 예상할 수 없습니다.

아래 코드를 변경해야 한다면 어떻게 해야 할까요?

const { filtered, value, index, fetchResponseType } = repoes;

const Results = (
	<ItemLayout id="fix_scroll">
		{filtered.map((repo: ItmeType, i: number) => (
        	<Item 
            	key={`${item_${i}}`}
                index={i}
                curIndex={index}
            	item={repo}
                onClickItem={onClickItem}
            />
            {currentTargetValue && (
            	<Item 
                    key={`${item_${filtered.length}}`}
                    index={filtered.length}
                    curIndex={index}
                    item={{
						id: `search_in_google`,
                        name: `github: ${currentTargetValue}`
                    }}
                    onClickItem={onClickItem}
                />
            )}	
        ))}
    </ItemLayout>    
)

변경에 유연하도록 컴포넌트 잘 만들기

아래 세 가지 기준점을 기반으로 컴포넌트를 잘 만드는 법에 대해 예시를 들어보겠습니다.

1. Headless 기반의 추상화하기

변하는 것 vs 상대적으로 변하지 않는 것

2. 한 가지 역할만 하기

또는 한 가지 역할만 하는 컴포넌트의 조합으로 구성하기

3. 도메인 분리하기

도메인을 포함하는 컴포넌트와 그렇지 않은 컴포넌트 분리하기

1. Headless UI 기반의 추상화하기

프런트엔드의 컴포넌트의 역할은 아래와 같습니다.

어떻게 보여줄지는 디자인에 의존합니다.

디자인에 의존하는 UI를 컴포넌트가 관리하는 '데이터'와 분리해 보면 어떨까요?

데이터와 디자인 나누기

1. 데이터 나누기

- 달력 데이터에 관련된 것들을 useCalandar 훅으로 나누기

- 디자인 부분은 따로 jsx 형태로 마크업

데이터를 관심사에서 제외하고

UI가 변경되더라도 데이터만 다루는 useCalandar 훅은 변경할 필요가 없어짐

2. 디자인 나누기

아래 코드를 보면 컴포넌트 내부에 여러 가지 로직이 들어가 있습니다.

데이터 부분을 추상화한 것처럼 상호작용하는 부분도 추상화해 봅시다.

상호작용하는 이벤트 핸들러들을 useLongPress라는 훅으로 분리

hooks로부터 반환하는 값을 longPressProps를 주입하는 형태로 변경

상호작용하는 부분의 관심사가 분리되고, 다른 컴포넌트에서도 longPress 동작을 정의할 때 재사용도 용이해짐

2. 한 가지 역할만 하기 (Composition)

아래는 흔하게 볼 수 있는 Select 컴포넌트인데요

이 UI를 만들다 보면 자연스럽게 작은 컴포넌트로 구성해서 만들게 됩니다.

코드를 살펴보면 변경이 발생했을 때

변경에 유연하게 대처하기 어렵게 보이는데요

다른 곳에서 사용한다고 가정해 보면 어떨까요?

당장 label 디자인만 변경되더라도 재사용하기 어렵습니다.

개선해 보기

담당하고 있는 데이터와 역할을 기준으로 분리

1. 메뉴의 노출 여부를 관리하는 상태인 isOpen을 분리

2. isOpen의 상태를 바꾸기 위한 상호작용을 Dropdown.Trigger로 분리

3. 옵션영역을 Dropdown.menu로 구성

4. 메뉴를 구성하는 각각 Item을 분리

재구성한 코드는 다음과 같습니다.

- 변경에 유연

Select 컴포넌트와 trigger로 전달한 InputButton 컴포넌트는 서로의 존재에 대해 알지 못한다.

서로의 변경이 서로에게 영향을 끼치지 않게 됨

합성가능한 컴포넌트는 유지보수 및 재사용의 용이성을 증가시켜 줍니다.

좀 더 복잡한 경우를 볼까요?

1. 선택하기 버튼을 클릭하면 모달이 열립니다.

2. 모달의 안의 체크박스를 여러 가지를 선택이 가능함

3. 체크 후 적용하기 버튼을 누르면 선택한 값들이 버튼에 노출됩니다.

UI만 봐서는 꽤나 복잡한 컴포넌트라는 생각이 드는데요,

이 컴포넌트가 관리하고 있는 데이터를 기준으로 바라보면 그렇게 복잡한 컴포넌트는 아닐 수 있습니다.

컴포넌트의 기능을 나눠본다면

1. 옵션을 제공하고

2. 선택한 값을 보여즘

Trigger 부분만 수정하고 싶으면 분리된 Trigger만 수정하면 됩니다.

3. 도메인 분리하기

컴포넌트를 주입받은 것처럼 데이터도 주입받으면 어떨까요?

언제 데이터를 주입받고, 언제 스스로 가져와야 할까요?

특정 도메인 맥락을 제거하고 일반적인 인터페이스로 분리하기

- 컴포넌트 인터페이스는 일반적일수록 이해하기 좋다.

- 컴포넌트의 이름과 props 네이밍은 일반적인 컨벤션으로 작성하자

프론트엔드 개발자라면 Select가 어떻게 동작하는지 알고 있고,

아래처럼 도메인 로직을 걷어내면 사용하는 입장에서 동작을 쉽게 예측할 수 있게 된다.

즉, 비즈니스 로직은 스스로 처리하되

UI 로직만 위임하는 방식으로 볼 수 있습니다.

컴포넌트를 설계하는 순서

1. 인터페이스를 먼저 고민하기

구현해야하는 기능이 이미 만들어져 있다고 가정하고 그것을 사용하듯이 작성해보자

- 의도가 무엇인가?

- 이 컴포넌트의 기능은 무엇인가?

- 어떻게 표현되어야 하는가?

2. 컴포넌트를 나누는 이유 생각해보기

- 컴포넌트로 분리하면 실제로 복잡도를 낮추는가?

- 컴포넌트로 분리하면 재사용 가능한 컴포넌트인가?

Reference

https://www.youtube.com/watch?v=fR8tsJ2r7Eg

프론트엔드 클린코드(클린 코드 != 짧은 코드)

hmk run dev — Sat, 9 Mar 2024 14:01:25 +0900

이 글은 토스 SLASH21의 실무에서 바로 쓰는 Frontend Clean Code를 바탕으로 작성된 글이며
클린코드에 대한 관점은 개인마다 다를 수 있습니다.

클린코드를 해야 하는 이유

실무에서 클린 코드 = 유지보수 시간의 단축

시간 = 자원 = 돈

처음엔 클린 했다. => 요구사항에 맞는 적절한 클린 코드였다.

하지만, 기존 코드에 기능을 추가하는 상황이라면?

실무의 대부분은 새로운 기능을 만드는 경우도 있겠지만, 기존의 코드에 새로운 기능을 추가하는 경우가 더 많다.

간단한 코드를 통해 실무관점으로 클린 하게 리팩토링 해보자

요구사항은 아래와 같습니다.

- 보험에 대한 질문은 입력하는 페이지가 있다.

- 설계사가 있는 경우엔 설계사 사진이 들어간 팝업을 먼저 띄워달라는 추가 기능을 요청받음

function QuestionPage() {

	const [popupOpend, setPopupOpened] = useState(false);
    
	// 질문 등록 핸들러 함수
	async function handleQuestionSubmit() {
    	const 연결전문가 = await 연결전문가_받아오기();
        
        // 기능 추가받은 연결 전문가가 있는지 검사 분기처리
        if(연결전문가 !== null){
        	setPopupOpened(true);
        } else {
        	const 약관동의 = await 약관동의_받아오기();
            
            if(!약관동의){
				await 약관동의_팝업열기();
            }
            
            // 질문전송 성공 시 성공 alert
            await 질문전송(questionValue);
            alert("질문이 등록되었어요.");
        }
    }
    
    
    async function handleMyExpertQuestionSubmit() {
		await 연결전문가_질문전송(questionValue, 연결전문가.id);
        alert(`${연결전문가.name}에게 질문이 등록되었어요.`)
    }

	return (
    	<main>
        	<form>
        		<textarea placeholder="어떤 내용이 궁금한가요?" />
                <button onClick={handleQuestionSubmit}>질문하기</button>
            </form>
            {popupOpened && (
                <연결전문가팝업 onSubmit={handleMyExpertQuestionSubmit}/>
            )}
        </main>
    )
}

위 코드에서 어떤 문제가 있을까?

1. 하나의 목적인 코드가 흩뿌려져 있다.

초록색으로 강조된 부분은 "연결 중인 전문가" 팝업 관련된 코드인데,

하나의 목적을 가진 코드가 떨어져 있어 추후 유지보수 시 스크롤을 위아래로 왔다 갔다 하며,

유지보수의 시간소요 증가 발생

3. 하나 함수가 여러 가지 일을 처리하고 있음

함수하나에 기능이 여러 개 있어

세부 구현을 모두 읽어야 함수의 역할을 알 수 있게 됨

- handleQuestionSubmit

- handleMyExpertQuestionSubmit

handleQuestionSubmit은 질문 전송 이외에도 여러 가지 일을 하고 있어 읽을 때 어지럽다.

3. 함수 세부 구현단계가 제각각

파란 부분과 노란 부분은 둘 다 이벤트 핸들링 관련함수

함정은 풀 리퀘스트의 변경사항만 보면

내가 추가한 기능의 코드만 잘 보이기 때문에 전체적으로 어지러운 코드인지를 파악하기 어려웠을 것이다.

이제 큰 그림은 보면서 리팩토링을 해보자

1. 함수 세부 구현 단계 통일

- handleNewExpertQuestionSubmit => 새로운 전문가에게 연결하는 로직만 넣음

- handleMyExpertQuestionSubmit => 연결 중인 전문가에게 질문하는 로직만 넣기

2. 하나의 목적인 코드는 뭉쳐 두기

기존에는 팝업을 여는 버튼과 팝업 코드가 동떨어져 있었는데

이를 모아서 "PopupTriggerButton" 이란 컴포넌틑를 만들었다.

3. 함수가 한 가지 일만 하도록 나누기

약관 동의 함수를 쪼개서 필요한 시점에 부르도록 변경

코드가 더 길어졌다 그러나,

클린 코드!= 짧은 코드

=> 원하는 로직을 빠르게 찾을 수 있는 코드

원하는 로직을 빠르게 찾으려면?

응집도 - 하나의 목적을 가진 코드가 흩뿌려져 있지 않게 하기

단일책임 - 하나의 함수에 하나의 기능만

추상화 - 함수의 세부구현 단계가 제각각이지 않게 추상화 단계를 조절해 구현하기

응집도

같은 목적의 코드는 뭉쳐두자

노란색으로 표시한 코드는 팝업을 조작하는 코드인데, 코드가 제각각 떨어져 있다.

파악도 한 번에 안 되고 버그 발생 위험도 높다.

커스텀훅을 사용해 관련로직을 한 군데로 뭉쳐놓는다.

그런데, 이게 좋은 방법일까?

오히려 커스텀훅을 사용해서 너무 추상화되지 않았을까?

다른 동료가 이 코드를 보고 로직을 빨리 파악할 수 있을까?

그렇다면 무엇을 뭉치고 얼마나 추상화하는 게 좋을지에 대해 한번 생각해 볼 필요가 있다.

뭉쳐서 짧은 코드로 만든다고 코드가 깨끗해지진 않는다.

클린코드는 짧은 코드가 아니다.

찾고 싶은 로직을 빠르게 찾을 수 있는 코드다.

어떻게 해야 읽기 좋게 응집할 수 있을까?

핵심 데이터와 숨겨도 될 세부구현을 나눈다.

아래 코드에서 핵심 데이터는 아래 두 개 정도로 볼 수 있다.

- 팝업 버튼 클릭 시 액션

- 팝업의 제목, 내용

그리고 세부 구현은 아래 두 개 정도로 볼 수 있다.

- 팝업을 열고 닫을 때 사용하는 상태

- 컴포넌트 세부 마크업

- 팝업의 버튼 클릭 시 특정함수를 호출해야 한다는 바인딩

리팩토링

핵심 데이터만 남기고 세부 구현은 숨겨보자.

openPopup이라는 커스텀훅에 모든 코드를 다 숨기는 게 아니라,

세부 구현만 숨겨놓고 핵심 데이터인 팝업 제목, 내용, 액션은 바깥에서 넘겨주는 방식으로 변경했다.

위의 변경 점으로 아래의 용이성을 얻게 되었다.

- 세부 구현을 읽지 않고도 어떤 팝업인지 파악할 수 있게 됨

선언적 프로그래밍

- 팝업 너에게 선언한다.

- 제목은 보험 질문하기!

- 내용은 전문가가 설명드려요

- 확인버튼 클릭하면 질문을 제출해라!

이러한 선언들을 바탕으로 팝업이 이미 구현된 세부 구현을 바탕으로 해당 내용을 뿌려주는 스타일을 일컬어

"선언적 프로그래밍"이라고 한다.

무엇을 하는 함수인지 빠르게 파악이 가능하다.

이와 반대로 선언형으로 뭉쳐두지 않고, 하나하나 세부구현을 작성한 방식을

명령형 프로그래밍이라고 한다.

선언적 프로그래밍도 내부를 까보면 명령형으로 되어있지만,

세부 구현이 노출되어 있어 이를 커스텀하기 쉽지만

읽는데 오래 걸리고 재사용하기 어렵다는 단점이 있다.

선언적이 명령형보다 좋은가?

아주 당연하게도 아니다.

리액트를 사용하면 HTML에도 선언형 프로그래밍을 이용할 수 있지만,

props로 어떻게 해야 하는지를 넘겨야 하는 경우에 명령형도 좋은 선택이다.

단일책임

이벤트 핸들러 함수를 지어보자

기능은 아래와 같다.

- 폼에서 질문 제출을 클릭했을 때 호출되는 함수

- 약관 동의 여부를 체크하고 질문을 제출한다.

단순하게 "질문제출" 정도로 함수이름을 정의할까?

그러나 함수 내용엔 '약관제출', '질문제출'이 섞여있다.

이렇게 중요 포인트가 가려진 함수들은 세부구현을 일일이 확인해야 하고 ,

함수명을 믿지 못하게 된다.

이에 더해 약관동의 체크 이외에 다른 기능이 추가가 되면 함수는 더 복잡해지고, 뚱뚱해진다.

이러한 기능추가가 반복되고 함수 이름과 다른 기능을 하는 경우가 빈번해지면,

코드에 대한 신뢰가 떨어지고 유지보수에 대한 리소스가 더 증가하게 된다 => 시간, 돈, 자원 낭비

단일 책임의 원칙을 적용해 함수가 하나의 책임만 가지게 하도록 해보자

물론 리액트의 경우엔 함수뿐만 아니라 컴포넌트로 분리해 책임을 나눌 수도 있다.

IntersectionObserver를 이용해 요소가 겹쳐 있을 때, 함수를 실행시키는 코드를

IntersectionArea라는 컴포넌트로 나눠 세부 구현은 숨기고, 사용하는 입장에서 Impression 시

동작할 함수를 넘겨주게만 하는 방식으로 나눴다.

도메인 지식이 복잡하게 들어가거나,

직관적으로 파악하고 싶으면 한글 변수명도 이용해 보자

추상화

컴포넌트 로직에서 핵심 개념만 뽑아보자.

- 왼쪽은 팝업 컴포넌트 코드를 제로부터 디테일하게 구현

- 오른쪽은 선언적으로 팝업의 "제출", "성공" 액션으로 나누고 나머지는 추상화시킴

함수 로직에서 핵심 개념만 뽑아보자.

함수 모듈로 분리해 getPlannerLabel 함수명 안에 추상화시킴

얼마나 추상화할 것인가?

버튼을 눌렀을때 컨펌을 보여주는 코드

버튼을 눌렀을때 컨펌을 보여주는 기능을 ConfirmButton이라는 컴포넌트로 추상화

메시지만 넣고 컨펌창에 원하는 메시지를 보여주도록 더 추상화

모든 기능을 모두 ConfirmButton이라는 이름아래에 추상화시킬 수도 있다.

당연하게도 이러한 추상화 레벨에도 맞고 틀리다 라는 개념은 없다.

상황에 따라 필요한 만큼 추상화하면 된다.

실무에서 코드를 보고 추상화를 제안하기도 하고,

추상화 하지 않았던 이유에 대해서 답변하기도 한답니다.

그러나 추상화 수준을 맞춰준다면, 더 파악하기 쉬운 코드가 될 수도 있습니다.

클린 코드에 대한 의견은

개개인마다 다를 수 있습니다.

코드에 정답은 없고 같이 개발하는 팀과 공감대를 형성하며,

명시적으로 정하고, 문서화해 팀의 컨벤션을 형성하는 방법이 있겠지요

기존에 널리 알려진 컨벤션 ex) SOLID

+

팀원과 함께 명시적으로 잘 정해진 약속, 컨벤션 기반

답은 없고 조직마다 처리해야 하는 업무량도 다르겠지만,

같이 일하는 개발 조직이라면 추후 유지보수 리소스를 고려해 코딩 컨벤션을 맞춰보는 게 좋을 것 같다! 라는 생각이 듭니다.

Reference

https://www.youtube.com/watch?v=edWbHp_k_9Y

hmk run dev

Cloudflare 터널을 이용한 n8n 접근 설정 가이드

목차

Cloudflare 터널이란?

작동 원리

Cloudflare 터널의 장점

Cloudflare 터널 vs 단순 포트포워딩: 간단 비교

Cloudflare 터널의 장점

포트포워딩의 단점

사전 준비 사항

Cloudflare 터널 설정 단계

1. Cloudflare 로그인 및 인증

2. 터널 생성

3. 터널 구성 파일 설정

4. DNS 레코드 생성

5. 터널 실행

도커 자동 실행 설정

도커 데스크톱 자동 실행 설정 (Mac/Windows 사용자)

터널 자동 실행 설정

리눅스에서 systemd를 이용한 자동 실행 설정

macOS에서 launchd를 이용한 자동 실행 설정

문제 해결 및 팁

1. 터널 연결 문제

2. n8n 설정 조정

3. 여러 서비스 연결

마치며

n8n 무료로 사용하기 (셀프호스팅 도커 환경 구축 - 웹훅 설정부터 도메인 연결까지)

목차

n8n이란?

도커를 이용한 n8n 셀프호스팅 구축

도커(Docker)란?

n8n 도커 설치 과정

웹훅 설정을 위한 도메인 연결

웹훅(Webhook)이란?

웹훅을 위한 도메인 설정

가비아 도메인을 Cloudflare로 연결하기

네임서버(Name Server)란?

Cloudflare란?

가비아 도메인을 Cloudflare로 이전하는 과정

마치며

CI 린트 체크시간 최적화하기

왜 린트 시간을 개선해야 했는가?

해결 접근법: 비동기 병렬 처리

execSync와 exec의 차이

execSync - 동기적 실행

exec - 비동기적 실행

Node.js 이벤트 루프와 비동기 처리 이해하기

이벤트 루프란?

동기 vs 비동기 & 블록 vs 논블록

동작 원리

성능 개선 효과

주의사항 및 고려사항

브라우저 vs Node.js 비동기 처리 비교

확장 가능한 개선 방안

결론

블록과 논블록, 동기와 비동기

개념 정의와 차이점

블록 vs 논블록

동기 vs 비동기

블록/논블록과 동기/비동기의 관계

장단점 비교

블록 처리의 장단점

논블록 처리의 장단점

동기 처리의 장단점

비동기 처리의 장단점

실전 적용 가이드

블록 처리를 사용해야 할 때

논블록 처리를 사용해야 할 때

동기 처리를 사용해야 할 때

비동기 처리를 사용해야 할 때

프로그래밍 언어별 구현 사례

JavaScript

실제 사례

웹 개발에서의 API 호출

[Q&A] async/await는 블록인가 논블록인가?

파일 시스템 작업

데이터베이스 쿼리

최신 트렌드와 미래 전망

결론

셀프회고(2025.05.05)