자바스크립트를 공부하다 보면 this 키워드가 정말 헷갈립니다.

함수 안에서 썼을 때는 객체를 가리키더니, 어떤 때는 undefined가 나오고,

어떤 때는 window를 가리킵니다.

 

왜 그럴까요?

 

그 이유는 자바스크립트의 this가 “동적 바인딩”이라는 규칙을 따르기 때문입니다.

 

this란?

this는 “현재 실행 중인 함수가 누구를 통해 호출됐는가“에 따라 달라지는 실행 컨텍스트의 참조값입니다.

 

 

예제 1: 객체 메서드에서의 this

const person = {
  name: "Alice",
  greet: function () {
    console.log("Hi, I'm " + this.name);
  }
};

person.greet(); // 👉 this는 person을 가리킴 → 출력: Hi, I'm Alice

❗ 그런데 변수에 옮기면?
const greetFn = person.greet;
greetFn(); // ❌ this는 undefined (strict mode) 또는 window (비엄격 모드)

 

greetFn()은 이제 객체 없이 단독으로 호출되고 있습니다.

즉, 이 시점에서 this는 더 이상 person이 아닙니다.

 

  • 브라우저 환경에서는 기본적으로 window를 가리킴
  • 'use strict' 모드에서는 undefined

 

👉 이것이 자바스크립트의 동적 바인딩입니다.

호출되는 방식에 따라 this가 달라지는 것이죠

 

 

예제 2: setTimeout과 일반 함수

const counter = {
  value: 0,
  increase: function () {
    setTimeout(function () {
      console.log(this.value); // ❌ this는 counter가 아님
    }, 1000);
  }
};

counter.increase(); // 출력: undefined

setTimeout의 콜백 함수는 단독으로 호출되기 때문에,

그 안의 thiswindow 또는 undefined가 됩니다.

 

 

해결법 1: this를 변수에 저장 (var that = this 패턴)

const counter = {
  value: 0,
  increase: function () {
    const that = this;
    setTimeout(function () {
      console.log(that.value); // ✅ that은 counter를 가리킴
    }, 1000);
  }
};

전통적인 방식입니다. 외부 thisthat에 복사해두고, 콜백에서 사용합니다.

 

해결법 2: 화살표 함수 사용

const counter = {
  value: 0,
  increase: function () {
    setTimeout(() => {
      console.log(this.value); // ✅ 화살표 함수는 this를 바깥에서 가져옴
    }, 1000);
  }
};

화살표 함수는 this를 만들지 않고, 자신이 정의된 위치의 this를 그대로 사용합니다.

위 코드에서는 increase() 메서드의 thiscounter이므로, 콜백 안에서도 그대로 유지됩니다.

 

 

주의: 화살표 함수를 객체 메서드로 직접 정의하면?

const user = {
  name: "Jane",
  greet: () => {
    console.log("Hi, I'm " + this.name); // ❌ this는 user가 아님
  }
};

user.greet(); // 출력: Hi, I'm undefined

화살표 함수는 객체의 메서드로 사용하면 안 됩니다.

그 정의 시점의 this는 전역 스코프(window/global)이기 때문이에요.

 

 

요약

상황 this가 가리키는 대상
객체의 메서드에서 호출 해당 객체
일반 함수에서 호출 전역 객체 (window) 또는 undefined
화살표 함수 정의된 시점의 외부 this를 유지
setTimeout, setInterval 기본적으로 전역 또는 undefined
메서드를 변수에 저장 후 호출 전역 또는 undefined

 

 

마무리

자바스크립트의 this어디서 정의되었느냐보다, 어떻게 호출되었는지에 따라 값이 결정됩니다.

이것이 바로 동적 바인딩의 원리입니다.

 

그리고 이 불편함을 해소하기 위해 나온 것이 바로 화살표 함수(arrow function)입니다.

화살표 함수는 this를 고정시켜서, 의도하지 않은 바인딩 오류를 줄여줍니다.

'Server > node.js' 카테고리의 다른 글

자바스크립트의 const, let, var  (0) 2025.06.09
무작위 키 발급하는 방법 (Node.js 활용)  (0) 2025.03.10

 

자바스크립트의 변수 선언 방식에 대해 알아보겠습니다

 

자바스크립트에서는 var, let, const 세 가지 방법으로 변수를 선언할 수 있으며, 각각 스코프 범위호이스팅 방식에 차이가 있습니다.

 

1. var

1) var는 함수 스코프(Function Scope)를 가집니다.

함수 스코프란 변수가 선언된 함수 전체에서 접근 가능하다는 의미입니다.

즉, 중괄호({})로 감싸진 블록 내부에서 선언된 변수라도, 함수 내라면 블록 밖에서도 참조할 수 있습니다.

 

function a() {
  if (true) {
    var x = 2;
  }

  console.log(x); // 출력: 2 (에러 아님)
}

 

 

2) var는 호이스팅(hoisting)이 됩니다.

호이스팅이란 자바스크립트 엔진이 코드를 실행하기 전에 변수 선언을 코드 상단으로 끌어올리는 개념입니다.

단, 끌어올려지는 것은 선언만이며, 할당은 끌어올려지지 않습니다.

console.log(x); // 출력: undefined
var x = 2;

위 코드는 실제로는 아래처럼 동작합니다:

var x;
console.log(x); // undefined
x = 2;

 

 

 

2. const

1) const는 블록 스코프(Block Scope)를 가집니다.

 

블록({}) 내부에서만 접근할 수 있으며, 블록을 벗어나면 참조할 수 없습니다.

function example() {
  if (true) {
    let y = 20;
    const z = 30;
  }
  console.log(y); // ❌ ReferenceError
  console.log(z); // ❌ ReferenceError
}

2) const 초기값을 반드시 할당해야 하며, 이후 값을 변경할 수 없습니다.

그래서 상수(constant)로 사용되며, 변하지 않는 값을 저장할 때 주로 사용됩니다.

일반적으로는 const로 변수를 선언하고, 값이 바뀔 필요가 있을 때만 let을 사용합니다.

 

 

3. let

1) let 역시 블록 스코프(Block Scope)를 가집니다.

const와 마찬가지로 블록 내부에서만 유효합니다.

 

2) let 값을 나중에 변경할 수 있습니다.

재할당이 가능하기 때문에 반복문 등에서 자주 사용됩니다.

 

let count = 0;
count = count + 1; // ✅ 가능

 

 

4. 함수 선언과 함수 표현식의 호이스팅 차이

1) 함수 선언문(Function Declaration)은 완전히 호이스팅됩니다.

즉, 선언 전에 호출해도 정상적으로 실행됩니다.

sayHello(); // 출력: Hello!

function sayHello() {
  console.log("Hello!");
}

함수 선언문은 변수 선언과 함수 정의 전체가 한꺼번에 호이스팅되기 때문에, 코드 상단에서 호출하더라도 에러가 발생하지 않습니다.

 

 

2) var로 선언한 함수 표현식(Function Expression)은 호이스팅될 때 undefined로 초기화됩니다.

함수 표현식은 var로 선언되었기 때문에 선언만 호이스팅되고, 함수 내용은 나중에 할당됩니다.

sayHi(); // ❌ TypeError: sayHi is not a function

var sayHi = function () {
  console.log("Hi!");
};

이 코드는 내부적으로 아래처럼 해석됩니다:

var sayHi;
sayHi(); // ❌ TypeError
sayHi = function () {
  console.log("Hi!");
};

즉, sayHi는 함수로 인식되기 전에 undefined 상태이기 때문에, 호출 시 에러가 발생합니다.

 

 

글 개요

기존에 EB로 배포된 웹에 SSH로 접속하여 Nginx 설정을 수정하고 SSL 인증서를 수동으로 적용했던 과정을 자동화된 방식으로 전환하였습니다. AWS Elastic Beanstalk에서 SSL 인증서를 자동으로 설정하는 방법과 그 과정에서의 시행착오, 해결 방법을 정리했습니다.

 

기존 방식

0. 다운로드 받은 pem 키 권한 부여 (SSH초기 접속시)

% chmod 400 YourPemKeyName.pem

 

 

1. SSH 접속

% ssh -i ~/Downloads/YourPemkeyName.pem ec2-user@Your-IP

 

2. SSL 수동 설정

% sudo nano /etc/nginx/conf.d/ssl.conf
server {
    listen 443 ssl;
    server_name YourSeverName;

    ssl_certificate /etc/letsencrypt/live/YourSeverName/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/YourSeverName/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    access_log /var/log/nginx/access.log main;
}

server 블록은 Nginx가 HTTPS(SSL)를 통해 요청을 수신하고 백엔드 서버로 전달(proxy) 하도록 설정하는 구성입니다.

접근 로그를 /var/log/nginx/access.log에 기록합니다. 

 

sudo nano /etc/nginx/conf.d/redirect.conf
server {
    listen 80;
    server_name YourServerName;

    return 301 https://$host$request_uri;
}

 

3.  Nginx 문법 검사, 재시작

sudo nginx -t 
sudo systemctl reload nginx 
sudo systemctl restart nginx

 

4. 포트 443이 열려 있고 Nginx(또는 다른 서비스)가 이 포트를 리슨 중인지 확인

sudo netstat -tulpn | grep :443

 

 

👀 Elastic Beanstalk는 배포할 때 EC2 인스턴스를 처음부터 다시 생성하거나 덮어쓰기 때문에 /etc/nginx/conf.d/ssl.conf 파일을 수동으로 만들고 저장해도 다음 배포 때 사라집니다.

그래서 .platform/hooks/postdeploy/ 스크립트를 사용하여 배포했습니다.

이 스크립트는 배포가 끝난 뒤에 SSL 설정 파일을 /etc/nginx/conf.d/로 다시 복사하고 nginx를 재시작하게 해주는 역할입니다.

 

개선 방식

0. 파일 구조

/project-backend-root
├── .platform
│   ├── hooks
│   │   └── postdeploy
│   │       └── 01_reload_nginx.sh
│   └── nginx
│       └── conf.d
│           ├── ssl.conf
│           └── redirect.conf

 

 

1. 01_reload_nginx.sh 스크립트

#!/bin/bash

cp .platform/nginx/conf.d/*.conf /etc/nginx/conf.d/
nginx -t && systemctl reload nginx
🔍 각 줄 설명

#!/bin/bash
//이 스크립트가 bash 셸에서 실행되어야 한다는 것을 명시합니다 (리눅스 스크립트의 표준 시작 줄)

cp .platform/nginx/conf.d/*.conf /etc/nginx/conf.d/
	•	.platform/nginx/conf.d/ 디렉터리에 있는 .conf 파일들을 Nginx의 설정 디렉터리인 /etc/nginx/conf.d/로 복사합니다.
	•	즉, ssl.conf, redirect.conf 같은 Nginx 설정 파일들을 실제 서버 설정 위치에 반영하는 과정입니다.

nginx -t && systemctl reload nginx
	•	nginx -t: Nginx 설정 파일이 문법적으로 올바른지 테스트합니다.
	•	&&: 앞의 명령어가 성공했을 때만 뒤 명령을 실행합니다.
	•	systemctl reload nginx: 설정이 문제 없으면 Nginx를 재시작하지 않고 리로드해서 설정을 적용합니다 (서비스 중단 없음).

 

2. ssl.conf, redirect.conf 파일 안에 기존과 동일하게 sever 내용을 작성해주면 됩니다.

 

3. 해당 스크립트 파일에 실행권한을 부여

chmod +x .platform/hooks/postdeploy/01_reload_nginx.sh

chmod +x .platform/hooks/postdeploy/01_reload_nginx.sh Elastic Beanstalk 인스턴스 내에서 스크립트를 실행 가능하도록 권한을 부여하는 명령어. 로컬에서 압축 전 한번만 실행해도 됩니다.

 

 

이제 수동으로 SSH 접속하여 설정하지 않아도 돼서 훨씬 편하네요.. 😉👍

 

더 좋은 의견이나 다른 견해가 있으시면 댓글 남겨주세요. 감사합니다!

 

개발하고 있던 웹프로젝트에 meta API를 라이브 모드로 사용하기 위해서 ssl을 발급받아 https로 변경해주려고 합니다.


 

1. PEM 키 파일 설정 및 SSH 접속

먼저 AWS에서 발급받은 PEM 키 파일의 권한을 설정합니다:

(.pem키가 다운로드 항목에 있다면)

chmod 400 ~/Downloads/펌키이름.pem

 

이후 SSH 접속 시도:

ssh -i ~/Downloads/펌키이름.pem ec2-user@e2c퍼블릭IP

 

2. Certbot 및 Nginx 설치

Amazon Linux 2023 기준으로 Certbot 및 Certbot-Nginx 플러그인을 설치합니다:

sudo yum install -y certbot python3-certbot-nginx

sudo nginx -v으로 설치되어있는가를 확인 후,

 

3. Nginx 시작 및 부팅 시 자동 실행 설정

sudo systemctl start nginx
sudo systemctl enable nginx

 

 

4. SSL 인증서 발급 (Let's Encrypt)

sudo certbot --nginx -d 도메인주소 -d www.도메인주소

저는 www 도메인 등록을 안 해둬서 www는 제외하고 발급받았습니다.

 

/etc/letsencrypt/live/도메인주소/ 경로에 인증서 저장됨 

 

5. 인증서 갱신 테스트 및 자동화

갱신 시뮬레이션 테스트

sudo certbot renew --dry-run

 

Crontab을 이용한 자동 갱신 설정

sudo crontab -e

파일을 만들어 아래 내용 입력 후 저장

0 3 * * * certbot renew --quiet --nginx

매일 새벽 3시에 갱신 시도

 

6. HTTP -> HTTPS 강제 리디렉션 설정

다음 내용을 /etc/nginx/conf.d/redirect.conf 파일에 작성:

server {
    listen 80;
    server_name 도메인주소;

    return 301 https://$host$request_uri;
}

 

설정 확인 및 Nginx 재시작:

sudo nginx -t
sudo systemctl reload nginx

 

도메인으로 보안 연결이 정상 작동하며 인증서 자동 갱신까지 설정 완료

이제 https로 접속 시도해보고 정상 작동함을 확인하면 됩니다 !

 

보안이 중요한 프로젝트에서는 무작위 키(Random Key) 를 생성해야 할 때가 많습니다. API 키, JWT 시크릿 키, 세션 토큰 등 다양한 용도로 사용됩니다. 이번 글에서는 Node.js를 활용한 무작위 키 발급 방법을 소개합니다! 


 

1️⃣ 간단한 한 줄 코드로 무작위 키 생성

Node.js의 crypto 모듈을 사용하면 한 줄 명령어로 랜덤 키를 생성할 수 있습니다.

node -e "console.log(require('crypto').randomBytes(64).toString('hex'))"

📌 실행 결과 (64바이트 랜덤 키)

3f8d9b4c5a8b9e2f1d4c7e5a6f8d2b3c4e9a1f2b3c5d6e7f8a9b0c1d2e3f4a5
  • randomBytes(64): 64바이트(512비트) 길이의 랜덤 바이트 생성
  • .toString('hex'): 16진수(hex) 문자열로 변환

이제 무작위 키가 필요할 때마다 위 명령어를 실행하면 됩니다! 😊

 

무작위 키 길이 조절하기

더 짧거나 긴 키가 필요하다면?

  • 32바이트(256비트) 키 생성: randomBytes(32).toString('hex')
  • 128바이트(1024비트) 키 생성: randomBytes(128).toString('hex')

예제:

const shortKey = crypto.randomBytes(32).toString('hex'); // 32바이트
const longKey = crypto.randomBytes(128).toString('hex'); // 128바이트

console.log("Short Key:", shortKey);
console.log("Long Key:", longKey);

 

 

마지막으로,

보안 키는 코드에 직접 하드코딩하기보다는 환경 변수(.env 파일) 에 저장하는 것이 좋습니다!!

 

AWS Elastic Beanstalk 또는 EC2에 배포한 후 웹사이트를 실행했을 때 502 Bad Gateway 오류가 발생하는 경우가 있습니다. 이번 글에서는 환경 변수 설정 누락으로 인해 발생한 문제의 원인과 해결 방법을 정리하겠습니다.


1️⃣ 문제 상황

📍 배포 후 오류 발생: 배포가 정상적으로 완료되었지만, 웹사이트 접속 시 502 Bad Gateway 오류가 발생함.

📍 로그 확인 (web.stdout.log) AWS 인스턴스 내부의 web.stdout.log 파일을 확인한 결과, 환경 변수를 찾을 수 없다는 오류가 발생.

 

2️⃣ 문제 원인

1. .env 파일이 포함되지 않음

Mac에서는 .env 파일이 숨김 파일로 처리됩니다. 이로 인해 배포할 때 .zip으로 압축할 때 .env 파일이 포함되지 않으면 환경 변수가 적용되지 않는 문제가 발생할 수 있습니다.

2. AWS Elastic Beanstalk에서 환경 변수가 설정되지 않음

AWS에서는 환경 변수를 별도로 지정하지 않으면 시스템에서 인식하지 못할 수 있습니다.

 

3️⃣ 해결 방법

✅ 1. AWS 환경 변수 설정하기 (배포 전)

AWS Elastic Beanstalk을 사용할 경우, 배포 전에 환경 변수를 설정하는 것이 가장 좋은 방법입니다.

📌 환경 변수 설정 방법

  1. AWS Elastic Beanstalk 콘솔 접속
  2. 환경  구성(Configuration)
  3. 환경 속성(Environment Properties) 섹션에서 KEY=VALUE 형식으로 환경 변수 추가
  4. 저장 후 배포 다시 진행

✅ 2. 배포 후 환경 변수 추가하기

만약 .env 파일이 누락된 상태로 배포되었다면, 배포 후 환경 변수를 직접 추가할 수도 있습니다.

📌 배포 후 환경 변수 설정 방법

  1. AWS Elastic Beanstalk 콘솔 접속
  2. 환경(Environment)  구성(Configuration) 선택
  3. 소프트웨어(Software)  환경 속성(Environment Properties) 섹션으로 이동
  4. 누락된 환경 변수를 추가하고 저장
  5. 애플리케이션을 다시 시작 (eb restart 또는 콘솔에서 재시작)

 

 

결론

AWS 배포 후 502 Bad Gateway 오류가 발생하는 주요 원인은 환경 변수가 설정되지 않았기 때문입니다. 이를 해결하기 위해:

  1. 배포 전에 환경 변수를 AWS Elastic Beanstalk 환경 속성에 추가
  2. 배포 후 AWS 콘솔에서 환경 변수를 추가 및 적용
  3. .env 파일을 배포 시 포함하거나 .ebextensions/env.config 파일을 활용
 

 

대전 빵지도 웹사이트를 개발하고 테스트하는 도중 이미지의 용량이 클 경우 (사실 그렇게 크지도 않음..) 업로드가 실패하는 버그가 발생.

이번 글에서는 AWS Elastic Beanstalk 환경에서 발생한 413 Request Entity Too Large 오류의 원인과 해결 방법에 대해 공유하려 합니다.


1️⃣ 문제 배경

📍 문제 상황: 대전 빵지도 웹사이트를 개발 및 테스트하는 도중, 특정 크기 이상의 이미지를 업로드하면 업로드가 실패하는 문제가 발생했습니다.

  • 오류 코드: 413 Request Entity Too Large
  • Content-Type: text/html
  •  문제: 서버가 JSON이 아닌 HTML을 응답함.

📍 브라우저 네트워크 로그:

Request Method: PATCH
Status Code: 413 Request Entity Too Large
Referrer Policy: strict-origin-when-cross-origin
content-type: text/html

 

 

2️⃣ 문제의 원인

1. 파일 크기 제한 (client_max_body_size)

AWS Elastic Beanstalk 환경에서 Nginx의 기본 설정으로 인해, 파일 크기가 1MB를 초과하면 업로드가 제한됩니다.

  • Nginx의 기본 client_max_body_size 값이 1MB로 설정됨
  • 설정을 변경하지 않으면 AWS에서 기본값이 유지됨

2. Elastic Beanstalk 환경에서 Nginx 설정이 자동으로 덮어씌워짐

  • /etc/nginx/nginx.conf를 직접 수정해도 재부팅하면 원래 설정으로 복구될 가능성이 있음
  • Elastic Beanstalk 환경에서는 프록시 설정 파일을 수정해야 함 (/var/proxy/staging/nginx/nginx.conf)

3. Node.js (Express) 자체의 요청 크기 제한

  • Express의 기본 요청 크기 제한은 100KB
  • JSON 요청을 받을 경우 express.json({ limit: "100mb" }) 설정이 필요
  • 현재 FormData로 전송 중  express.urlencoded({ limit: "100mb", extended: true }) 설정 추가 필요

 

3️⃣ 해결 방법

📌 AWS Elastic Beanstalk에서 Nginx 설정 수정하기

✅ 1. SSH로 Elastic Beanstalk EC2 인스턴스 접속

ssh -i [your-key.pem] ec2-user@[your-ec2-ip]

✅ 2. Nginx 설정 파일 수정

Elastic Beanstalk 환경에서는 다음 두 개의 설정 파일을 수정해야 합니다.

(1) /etc/nginx/nginx.conf 수정

sudo nano /etc/nginx/nginx.conf

 

설정 파일의 http {} 블록 안에 아래 내용을 추가

http {
    ...
    client_max_body_size 100M;
    ...
}

수정 후 저장: Ctrl + X → Y → Enter

(2) /var/proxy/staging/nginx/nginx.conf 수정 (Elastic Beanstalk 환경 필수)

sudo nano /var/proxy/staging/nginx/nginx.conf

 

파일에 아래 내용 추가

client_max_body_size 100M;

✅ 3. Nginx 설정 적용 (재시작)

파일 수정 후, Nginx를 다시 로드하면 됩니다.

sudo systemctl restart nginx
sudo nginx -t

 

 
 

4️⃣ Express에서 요청 크기 제한 해제

Nginx 설정을 변경했어도 Express가 요청 크기를 제한하고 있다면 해결되지 않을 수 있습니다.

서버의 server.js 또는 app.js 파일을 수정

const express = require("express");
const app = express();

// 요청 크기 제한 해제
app.use(express.json({ limit: "100mb" }));
app.use(express.urlencoded({ limit: "100mb", extended: true }));

 

 

🔥 해결 방법 요약

  • Nginx client_max_body_size 값을 100MB로 확장
  • Elastic Beanstalk 프록시 설정 파일에도 동일한 설정 적용
  • Express의 요청 크기 제한 해제 (express.json()  express.urlencoded() 설정)
  • Nginx 설정을 저장하고 재시작

 

대전 빵집 지도 웹사이트 🍞 구경하고 가세요 ㅎㅎ

http://daejeonbread.shop/

 

대전에서 나는 빵 | 맛있는 빵집 추천

 

daejeonbread.shop

 

 

 


참고

AWS Elastic Beanstalk로 생성한 EC2에 SSH 접속하기

https://sig03.medium.com/aws-elastic-beanstalk%EB%A1%9C-%EC%83%9D%EC%84%B1%ED%95%9C-ec2%EC%97%90-ssh-%EC%A0%91%EC%86%8D%ED%95%98%EA%B8%B0-6727dea20775

 

AWS Elastic Beanstalk로 생성한 EC2에 SSH 접속하기

AWS Elastic Beanstalk (이하 EB) 환경을 생성하면 EC2가 자동으로 생성된다. EC2 서버에서 EB 환경이 돌아가는 구조이다. 간혹 로그 추적 등의 이유로 EC2에 접근해야 할 일이 있다. 일반 EC2를 생성하면 중

sig03.medium.com

 

 

삭제 기능 추가하기

 

1. controller에 삭제 메서드 추가

@GetMapping("/delTodo")
    public String delTodo(@RequestParam("delToDo") Long delToDo){
        toDoRepository.deleteById(delToDo);
        return "redirect:/";
    }

 

2. html에 삭제버튼 추가

<li th:each="todo : ${todos}">
      <span th:text="${todo.todo}"></span>
      <a th:href="@{/delTodo(delToDo=${todo.id})}" class="delete-link">&cross;</a>
</li>

- /메서드(파라미터=${데이터 id값}

(데이터베이스의 데이터는 id값을 참조해서 지움)

- &cross 엑스버튼

 

3. 실행 결과

삭제시 데이터베이스 테이블에서도 삭제됨

+ Recent posts