체인의정석

웹 서비스에서 Content-Security-Policy (CSP), Referer Policy 처리를 통한 보안 강화

체인의정석 — Mon, 5 Jan 2026 16:48:21 +0900

상황

모회사에서 별도의 WAF와 백신을 설치한 이후에 관련된 ASM(Attack Surface Management) 대시보드를 볼 수 있게 되었다.

ASM은 외부 공격자가 접근할 수 있는 모든 잠재적 지점을 지속적으로 식별하고 분석하며, 보안 취약점을 최소화하는 프로세스라고 한다.

보니 referer policy와 Content-Security-Policy가 적용되지 않아서 보안성 경고가 뜬 부분을 볼 수 있었다.

https://velog.io/@sejinkim/Referrer-Policy%EC%9D%98-%EC%9D%B4%ED%95%B4

Referrer-Policy의 이해

사용자 행동 로그 데이터 수집 중 Referer가 유실되었던 사례를 계기로, Referrer-Policy에 관해 자세히 알아보았습니다.

velog.io

Referer Policy - 서버 처리

목적: 브라우저가 HTTP 요청 시 Referer (오타가 있는 원조 헤더 이름) 헤더에 포함할 이전 페이지의 URL 정보(리퍼러 정보)의 양을 제어합니다.
작동 방식: 사용자가 한 웹사이트에서 다른 웹사이트로 이동하거나 리소스를 요청할 때, 목적지 서버에 어떤 출처 정보를 보낼지 결정합니다.
주요 목표: URL에 포함될 수 있는 민감한 정보(예: 세션 토큰, 개인 식별자)의 불필요한 노출을 방지하여 사용자 프라이버시를 보호하는 데 중점을 둡니다.
예시: Referrer-Policy: no-referrer는 어떠한 리퍼러 정보도 보내지 않도록 지시하며, Referrer-Policy: strict-origin-when-cross-origin은 동일 출처 요청 시에는 전체 URL을 보내지만 교차 출처 요청 시에는 출처(origin) 정보만 보내도록 합니다.

웹 사이트 보안의 기본적인 대전제는 Same Origin Policy(SOP) 동일 출처 정책이다.

가능한 공격 벡터를 줄이기 위해, 다른 출저와의 상호작용을 제한하는 보안 정책이다.

동일한 출저가 아닌 경우 Cross-site 또는 Cross-Origin 이라고 하며, 개인정보 보호 및 웹 공격 방어 차원에서 특정 기능이나 정보가 제한됩니다.

먼저 referer policy에 대해서 찾아본 결과 Referer의 정의는 현재 요청을 보낸 페이지의 절대 혹은 부분 주소라고 한다. 리소스 요청이나 사용자의 링크 클릭에 존재할 수 있으며, 여기서 정보를 제한하지 않으면 사용자의 개인정보가 노출될 수 있기 때문에 제한을 하는 정책이라고 한다. 일단 SOP의 경우에는 문제를 삼지 않지만 cross-origin 요청일 때는 엄격하게 제한하는 것이 기본적인 기조라고 한다.

따아서 cross-origin요청일 때는 "strict-origin-when-cross-origin" 요청을 주면 된다.

반영하는 방법은 다음과 같다.

https://kku-jun.tistory.com/48

Referer Policy 적용하기

혹시 프로젝트를 진행하면서 이미지 url을 통해 접근은 가능하나 개발중인 서비스앱 내부에서는 호출하지 못한 경험이 있는가? 필자는 다음 경험을 Referer policy를 정의하면서 접근할 수 있게 되

kku-jun.tistory.com

해당 방법은 간단한데 웹서버에서

		// 보안 헤더 설정
		w.Header().Set("Referrer-Policy", "strict-origin-when-cross-origin")

위 언어는 go언어지만 해당 방식으로 보안 헤더를 서버에서 설정해 주면

위와 같이 referrer policy가 반영되게 된다.

CSP - 서버 처리

다음으로 작업한 부분은 CSP 반영이다.

Content-Security-Policy (CSP)

목적: 웹사이트 관리자가 페이지에서 로드할 수 있는 리소스(스크립트, 이미지, 스타일 등)의 출처를 제어할 수 있도록 합니다.
작동 방식: 신뢰할 수 있는 콘텐츠 소스(도메인)를 지정하여, 브라우저가 승인되지 않은 출처의 악성 콘텐츠를 로드하거나 실행하는 것을 방지합니다.
주요 목표: 교차 사이트 스크립팅(XSS) 및 데이터 삽입 공격과 같은 특정 유형의 공격을 탐지하고 완화하는 데 효과적인 추가 보안 계층입니다.
예시: Content-Security-Policy: script-src 'self' https://trusted-scripts.com;은 브라우저에게 자체 출처와 trusted-scripts.com에서만 스크립트를 로드하도록 지시합니다.

여기서 말하는 CSP는 콘텐츠 보안 정책으로 교차 사이트 스크립팅과 데이터 주입 공격 등을 방어하기 위한 추가 보안 계층이라고 한다.

There is missing header: Content-Security-Policy. The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page.

만약 http 요청에서 아래와 같이 이미 정책이 있다면 괜찮지만 해당 정책이 없다면 외부로부터의 호출에 있어서 보안 계층이 없어지는 것이기 때문에 활성화를 시켜주어야한다.

CSP를 활성화하려면 Content-Security-Policy HTTP 헤더를 반환하도록 웹 서버를 구성해야 한다.

w.Header().Set("Content-Security-Policy", 
    "default-src 'self'; 
     script-src 'self' 'unsafe-inline' 'unsafe-eval'; 
     style-src 'self' 'unsafe-inline'; 
     img-src 'self' data: https:; 
     font-src 'self' data:; 
     connect-src 'self'")

https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/CSP

컨텐츠 보안 정책 (CSP) - HTTP | MDN

CSP의 주요 목표는 XSS 공격을 완화하고 보고하는 것입니다. XSS 공격은 서버에서 받은 콘텐츠를 브라우저가 신뢰한다는 점을 악용합니다. 브라우저는 콘텐츠의 출처를 신뢰하기 때문에 콘텐츠가

developer.mozilla.org

Referer Policy & CSP 프론트엔드 처리

또한 두 부분 모두 프론트엔드에서 정적 파일 실행하는 부분도 ASM 모니터링 툴에 걸려서 업데이트를 진행해야 했었다.

만약 메타 마스크도 들어간다면 프론트엔드에서는 아래와 같이 정책을 짜면 된다.

파일명 : next.config.mjs

/** @type {import('next').NextConfig} */
const nextConfig = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          {
            key: 'Referrer-Policy',
            value: 'strict-origin-when-cross-origin',
          },
          {
            key: 'Content-Security-Policy',
            value: [
              "default-src 'self'",
              "script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.yourdomain.com",
              "style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://cdn.jsdelivr.net",
              "img-src 'self' data: https:",
              "font-src 'self' data: https://fonts.gstatic.com https://cdn.jsdelivr.net",
              "connect-src 'self' https://*.yourdomain.com https://*.metamask.io https://*.metamask-api.io https://*.arbitrum.io https://*.infura.io https://cdn.jsdelivr.net wss://*.metamask.io wss://*.metamask-api.io",
            ].join('; '),
          },
        ],
      },
    ];
  },
};

export default nextConfig;

이렇게 사용되는 외부 도메인 호출을 모두 CSP 정책에 넣어주어야 외부 공격으로부터 더 안전한 서비스를 만들 수 있게 된다.

또한 프론트에서 상세하게 CSP정책이 있기 때문에 이렇게 도메인을 하나하나 넣어주는 작업은 백엔드에서는 할 필요가 없다.

React, Next.js 취약점 (CVE-2025-55182, CVE-2025-66478)

체인의정석 — Tue, 30 Dec 2025 18:18:51 +0900

상황

현재 사용중인 내부 admin 백오피스는 react + next.js로 되어 있다. 사내망에서만 접근이 가능하도록 설정이 되어 있으며, 메타마스크 로그인 까지 통해야 요청을 날릴 수 있기 때문에 상대적으로 안전하지만 요즘 심각도가 10점 만점에 10점을 기록한 CVE-2025-55182, CVE-2025-66478 취약점이 이슈가 되어서 패치를 진행하였다.

해당 취약점은 서버사이드 랜더링 과정에서 공격자가 리엑트 서버의 주소를 알아서 접근이 가능하고, 명령어만 http요청을 실행이 되면 공격이 가능하기 때문에 10점짜리 취약점이라고 한다.

이런 부분을 고려했을때 admin페이지 같은 부분은 항상 내부망에서만 접근이 가능해야 하는것 같으며 react, next.js의 경우 비슷한 류의 공격포인트가 계속 생기기 때문에 주기적으로 공격포인트를 모니터링 해주어야 함을 느꼈다.

요약

React Server Components 프레임워크는 일반적으로 사용자 인터페이스를 구축하는 데 사용됩니다. 2025년 12월 3일, CVE.org는 이 취약점에 CVE-2025-55182를 할당했습니다. 공식 공통 취약점 등급 시스템(CVSS) 기본 심각도 점수는 10.0점 만점인 '심각(Critical)'으로 결정되었습니다.

취약한 버전: React 19.0, 19.1.0, 19.1.1, 19.2.0
패치된 버전: React 19.2.1
수정 사항(Fix): https://github.com/facebook/react/commit/7dc903cd29dac55efb4424853fd0442fef3a8700
공지: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Next.js는 React에 의존하는 웹 개발 프레임워크이며, 역시 사용자 인터페이스 구축에 널리 사용됩니다. (Next.js 취약점은 중복으로 표시되기 전 CVE-2025-66478로 참조되었습니다.)

취약한 버전: Next.js 15.x, Next.js 16.x, Next.js 14.3.0-canary.77 및 이후 canary 릴리스
패치된 버전은 여기에 나열되어 있습니다.
수정 사항(Fix): https://github.com/vercel/next.js/commit/6ef90ef49fd32171150b6f81d14708aa54cd07b2
공지: https://nextjs.org/blog/CVE-2025-66478

https://cloud.google.com/blog/ko/products/identity-security/responding-to-cve-2025-55182

CVE-2025-55182 보안 취약점, 당신의 React와 Next.js 프로젝트를 직접 겨냥합니다. | Google Cloud 블로그

CVE-2025-55182 취약점으로 인한 React 및 Next.js의 원격 코드 실행 위험을 최소화하려면 다음 권장 사항을 따르세요.

cloud.google.com

대처

해당 취약점으로부터 이슈를 해결하기 위해서

먼저 아래 링크를 통해서 react와 next.js를 해결된 버전으로 다시 깔았다.

=>https://nextjs.org/blog/CVE-2025-66478#required-action

Security Advisory: CVE-2025-66478

A critical vulnerability (CVE-2025-66478) has been identified in the React Server Components protocol. Users should upgrade to patched versions immediately.

nextjs.org

npm install next@15.0.5   # for 15.0.x
npm install next@15.1.9   # for 15.1.x
npm install next@15.2.6   # for 15.2.x
npm install next@15.3.6   # for 15.3.x
npm install next@15.4.8   # for 15.4.x
npm install next@15.5.7   # for 15.5.x
npm install next@16.0.7   # for 16.0.x
 
npm install next@15.6.0-canary.58   # for 15.x canary releases
npm install next@16.1.0-canary.12   # for 16.x canary releases

이렇게 각 세부 버전별로 픽스된 버전이 존재한다.

https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Critical Security Vulnerability in React Server Components – React

The library for web and native user interfaces

react.dev

"A fix was introduced in versions 19.0.1, 19.1.2, and 19.2.1. If you are using any of the above packages please upgrade to any of the fixed versions immediately."

위의 두 링크로부터 알아낸 fix된 버전은 다음과 같다.

 npm install next@15.1.9 react@19.0.1 react-dom@19.0.1

해당 버전들과 같이 가장 인접한 fix된 버전을 설치하여 충돌이 낮지 않게 해주면 해결이 가능하다.

참고

자세한 내용의 경우 아래 영상에 잘 나와있다.

공격 포인트에 대해서 aws에서는 waf 규칙을 강화하였고 facebook은 react에 유효성 체크 로직을 추가하였다. 따라서 업데이트 된 버전을 통해서 해당 공격포인트를 막는 작업을 진행하였다.

AWS EC2에서 이미지 생성하고 업데이트하기

체인의정석 — Tue, 23 Dec 2025 15:20:25 +0900

하게 된 배경 : 이미 존재하는 ec2에서 이미지를 뽑아내고 기존 시스템에서 업데이트 진행

현재 프로젝트의 구조상 이미지에 이미 필요한 모듈들이나 환경이 세팅되어 있고 이후 시작템플릿에서 해당 이미지를 통해서 환경별로 배포를 하는 식으로 구성이 되어있다.

그러나 보안 관련 문제로 기존 2022 버전의 OS를 2023으로 바꾸어야 하여 해당 부분으로 다시 작업을 하기위하여 2022버전에 깔려있는 주요 프로그램을 분석 한 후 동일한 버전으로 2023버전을 만든 후 이미지를 생성하는 과정이다.

순서 :

먼저 이미지를 생성하기 전에 설치된 패키지의 자동 시작 등록 및 기존의 캐시와 같은 내역들을 지워준다.

# 1. 서비스 자동 시작 등록 확인 (부팅될 때 알아서 켜지도록)
sudo systemctl enable firewalld
sudo systemctl enable amazon-cloudwatch-agent

# 2. (선택사항) 지금까지 친 명령어 기록 삭제 (보안상 좋음)
history -c
rm -f ~/.bash_history

2단계: [AWS 콘솔] 이미지(AMI) 생성

이제 AWS 웹 콘솔로 가서 "찰칵" 사진을 찍습니다.

AWS EC2 콘솔 접속 -> 인스턴스(Instances) 메뉴 클릭.

방금 세팅 완료한 새 서버와 동일한 서버를 찾아서 우클릭.
이미지 및 템플릿(Image and templates) -> 이미지 생성(Create image) 클릭.

설정 입력:
- 이미지 이름: 알아보기 쉽게 지으세요. (예: AMI-AL2023-Base-FirewalldFixed-20251222)
- 이미지 설명: 이미지에 설치된 주요 모듈들 쓰기
- 재부팅 안 함(No reboot): 체크 해제 권장 (서버를 잠시 끄고 안전하게 찍는 게 좋습니다. 서비스 중이라면 체크하세요.)
이미지 생성(Create image) 버튼 클릭하면 아래와 같이 생성중이라는 단어가 뜸

⏳ 완료까지 5~10분 정도 걸립니다. (왼쪽 메뉴 'AMI'에서 상태가 Pending -> Available로 바뀌면 성공!)

이후 메뉴 중

이미지 및 템플릿(Image and templates) -> 시작템플릿 생성 클릭.

여기서 새 버전으로는 구버전 OS가 아닌 새로운 버전 OS로 시작템플릿을 생성한다.

시작템플릿에서도 만약 해당 이미지 변경에 따른 스크립트 변경이 존재한다면 해당 부분도 반영해서 수정해 주어야 한다.

시작템플릿에서 내 AMI를 클릭한 후에 방금 만든 이미지이름을 검색해서 설정을 해주면 된다.

새로운 버전의 시작 템플릿에 이미지를 넣게 되면 시작템플릿의 설정대로 ec2가 시작이 되게 되고 이후에

기존에 작성해 둔 AutoScailing 그룹에 들어가서 인스턴스 재시작을 해야 재배포가 가능해진다.

이때 시작템플릿의 버전을 새로 만든 버전으로 바꾸고 인스턴스 재시작을 해야 수정된 이미지 파일이 반영이 되게 된다.

Autoscaling group에서 종료 전 시작을 누른 후 인스턴스 워밍업 시간을 넉넉히 설정해 둔 후에 일치 건너뛰기를 비활성화 시켜두면 무중단 재배포가 가능해 진다.

반영이 된 후에는 cloudwatch log insight에서 오류 구문에 대한 검색을 진행한다.

만약 AutoScalingGroup으로 관리가 안되고 있다면 업데이트 된 AMI 이미지를 넣어서 시작템플릿을 만들고 그 템플릿으로 인스턴스를 시작하면 해당 이미지와 설정으로 ec2인스턴스가 시작되게 된다.

이처럼 여러 환경에서 동일한 인스턴스를 띄울때는 이미지, 시작템플릿을 사용하면 좋고 무중단 배포 등에서는 auto scaling group을 사용하면 더 좋다.

ssh config 파일로 bastion에서 점프해서 ssh 접속하기

체인의정석 — Thu, 11 Dec 2025 18:50:48 +0900

보안을 위해 보통 서버에 접속할 때는 바로 접속하는것이 아닌 bastion 서버를 두게 된다.

bastion의 경우 pem 키만 있으면 접속이 가능하지만 여기서 다른 서버로 들어가기 위해서는 한번 더 접속을 해야한다.

이에 대한 작업이 반복되면 번거롭기 때문에 보통 ssh config를 통해서 각 서버에 맞는 명령어를 통해서 한번에 접속을 하도록 세팅을 해준다.

Host example-bastion-live
    HostName "Pulic IP넣기"
    User ec2-user
    IdentityFile ~/.ssh/example-live.pem
    
Host example-service-live
    HostName "Private IP넣기"
    User ec2-user
    IdentityFile ~/.ssh/example-service-live.pem
    ProxyJump example-bastion-live

예를 들어 example이라는 이름의 서비스를 관리할 때 example-bastion-live를 통해서 live환경의 베스쳔에 접속한다면 이때 public IP와 미리 해당 bastion ec2에 지정된 pem키를 넣어서 접근하면 되며, 이후 ProxyJump를 통해서 실제로 해당 베스쳔에 연결된 다른 서비스에 접근 할 수 있다. 이렇게 하면 bastion에 접속 한 후 해당 bastion에서 pem키를 통해서 다른 서버에 접속하는 과정을 쉽게 단축할 수 있다.

사용할 때는

cd ~/.ssh
ssh example-service-live
ssh example-bastion-live

위와 같이 지정해 둔 이름의 ec2로 접속이 가능하다.

만약 각 서버에 pem키를 지정해 둘 필요가 없다면 bastion에서 alias로 바로 접속이 가능하지만 보안상 각 ec2마다 허용되는 pem키들을 두고 사용하는것이 좋아 보인다.

S3를 써서 NFT 메타데이터 업로드 하기

체인의정석 — Fri, 21 Nov 2025 17:29:18 +0900

프로그램에서 S3에 접근하기 위해서는 AWS credentials가 먼저 필요하다.

aws credentials 확인의 경우 다음과 같은 경로에 세팅 한다.

cat ~/.aws/credentials
[default]
aws_access_key_id = 
aws_secret_access_key =

ts에서 사용하는 패키지

import S3Helper from '@lib/AWS/S3Helper';

먼저 프로필을 사용해서 객체를 만들어 줘야 한다.

const testS3Helper = new S3Helper('us-west-2', 'default');

그리고 정책에 들어가서 해당 IAM계정이 S3에 어떠한 권한이 있는지 체크해야 한다.

보아하니 권한 끝에 /*가 붙어 있지 않으면 s3Object를 다룰 수 없다고 하여 붙여 주었다.

          await Promise.all([
            ...tokenIds.map((tokenId) =>
              s3Helper.s3
                .copyObject({
                  Bucket: PUBLIC_S3_BUCKETNAME,
                  CopySource: `/${PRIVATE_S3_BUCKETNAME}/nft1/${tokenId}.png`,
                  Key: `testNFT/${tokenId}.png`,
                })
                .promise(),
            ),
          ]);

만약 이런식으로 해두면 private에 미리 올려둔 S3에 접근해서 파일을 옮긴다면

만약 CopySource인 S3에 해당 데이터가 없다면 "Copy failed The specified key does not exist."

이렇게 뜨게 된다.

이제 이벤트를 구독하면서 nft민팅이 확인된 순간 프라이빗 S3에서 퍼블릭 S3로 옮기게 되면 NFT 민팅이 완성된다.

이렇게 하는 이유는 위의 명령어는 S3 내부적으로 파일이 이동하는 것임으로 시간이 얼마 걸리지 않으며, nft가 민팅이 확정된 시점에 프라이빗 S3에서 퍼블릭 S3로 옮기면 짧은 시간 내에 nft민팅을 완료활 수 있기 때문이다.

만약 복사해서 옯기는 행위가 아니라 S3에 접근해서 데이터를 수정하고 업로드를 해야하는 경우 다음과 같이 할 수 있다.

    // 메타데이터 JSON 파일 가져와서 수정 후 업로드
    try {
      // 1. projectName 이라는 경로에 있는 S3에서 원본 JSON 파일 가져오기
      const metadataResponse = await s3Helper.s3
        .getObject({
          Bucket: PRIVATE_S3_BUCKETNAME,
          Key: `projectName/metadata/${exampleID}.json`,
        })
        .promise();

      // 2. JSON 파싱
      const metadata = JSON.parse(metadataResponse.Body.toString());

      // 3. 필요한 필드 수정
      metadata.name = `NFT #${tokenId}`;
      metadata.image = `https://${CDN_DOMAIN}/${projectName}/${nftContractAddress}/image/${tokenId}.png`;
      console.log('metadata: ', metadata);
      // 4. 수정된 JSON 업로드
      await s3Helper.upload({
        bucketName: PUBLIC_S3_BUCKETNAME,
        key: `${CONTRACT_DATA_S3_PATH}/${nftContractAddress}/metadata/${tokenId}.json`,
        body: JSON.stringify(metadata),
        contentType: 'application/json',
      });
    } catch (error) {
      console.log(`Failed to modify and upload metadata for tokenId: ${tokenId}, error);
      return;
    }

이처럼 S3에 접근해서 이벤트 또는 db기반의 데이터를 읽어와서 메타데이터를 수정하는것이 가능하며,

위와 같은 형식은 메타데이터가 민팅 전에는 비공개로 있다가 공개가 되는 순간 특정 유저에게 특정 상황에 맞는 nft가 민팅되어야 할 때 사용할 수 있다.

비디오 스트리밍 - HLS 모듈 사용하기

체인의정석 — Wed, 19 Nov 2025 18:54:54 +0900

비디오 스트리밍의 경우

https://github.com/video-dev/hls.js

GitHub - video-dev/hls.js: HLS.js is a JavaScript library that plays HLS in browsers with support for MSE.

HLS.js is a JavaScript library that plays HLS in browsers with support for MSE. - video-dev/hls.js

github.com

다음 모듈을 써서 구현하면 된다.

<script src="https://cdn.jsdelivr.net/npm/hls.js@1"></script>
<!-- Or if you want the latest version from the main branch -->
<!-- <script src="https://cdn.jsdelivr.net/npm/hls.js@canary"></script> -->
<video id="video"></video>
<script>
  var video = document.getElementById('video');
  var videoSrc = 'https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8';
  if (Hls.isSupported()) {
    var hls = new Hls();
    hls.loadSource(videoSrc);
    hls.attachMedia(video);
  }
  // HLS.js is not supported on platforms that do not have Media Source
  // Extensions (MSE) enabled.
  //
  // When the browser has built-in HLS support (check using `canPlayType`),
  // we can provide an HLS manifest (i.e. .m3u8 URL) directly to the video
  // element through the `src` property. This is using the built-in support
  // of the plain video element, without using HLS.js.
  else if (video.canPlayType('application/vnd.apple.mpegurl')) {
    video.src = videoSrc;
  }
</script>

위와 같이 CDN을 사용하면 바로 구현이 가능하다.

참고로 html자체로만 띄우면 cors에러가 나기 때문에 pm2로 띄우거나

python3 -m http.server 8080 --bind 0.0.0.0

다음과 같이 서버를 띄워서 시도해야 한다.

Live 배포 시 Release Note 작성하기

체인의정석 — Wed, 22 Oct 2025 14:52:48 +0900

다른 환경과는 다르게 실제 live 배포시에는 릴리즈 노트를 작성해야한다.

들어가야 할 항목은 다음과 같다.

1. 새로 추가한 기능

2. 수정 사항 (PR링크)

3. 알려진 이슈들 정리

4. 배포 정보 (젠킨스 잡, git Tag 등과 같이 배포 프로세스별로 구분되는 태그와 릴리스 번호)

- 대상환경, 배포서비스 ,Genkins Job, Git tag

5. 배포 시간 / 프로세스

- 배포시간이 얼마나 걸렸는지

- 배포 프로세스에서 체크해야할 사항이 있다면 해당 부분을 체크하였는지

6. 배포된 서버

- 배포된 서버의 ip 주소 (고정 ip가 아닐 경우 매번 업데이트 진행, 현재 시스템은 bastion만 고정이며 나머지는 고정으로 두지 않음) 및 인스턴스 ID 및 링크 (동일한 서버가 여러대 있을 경우 각 인프라 별로 모두 정리)

또한 배포시 오토스케일링을 활용하였는데 이러한 경우 다음과 같은 옵션을 미리 정리해둔다.

인스턴스 재시작을 할지 (중단 배포, 인스턴스 개수를 0으로 변경 하면 오토스케일링에서 다시 띄움)

인스턴스 새로고침을 통하여 업데이트를 할지(무중단 배포, 각 인스턴스 별로 하나를 더 띄운 후 대기 시간을 가지고 새로운 인스턴스가 다 띄워진 이후에 이전 인스턴스를 종료하는 식으로 진행하는 과정, 이때 일치 건너뛰기 옵션을 해제하여 진행하였음)

각 상황마다 다르게 활용이 가능하다.

React) 재랜더링과 메모이제이션 Memo, useMemo & useEffect

체인의정석 — Thu, 25 Sep 2025 18:33:35 +0900

<재랜더링 패턴 3개>

React에서는 재랜더링이 발생하는 3가지 패턴

1. State 업데이트

2. Props가 변경된 컴포넌트

3. 재랜더링 된 컴포넌트 아래의 모든 컴포넌트

이러한 재랜더링을 계속하게 될 경우 부하가 많이 발생하게 된다.

<메모이제이션>

리액트에서 컴포넌트, 변수, 함수 등을 재렌더링할 때 제어가 필요한 경우에는 메모이제이션을 수행한다.

메모이제이션은 이전 처리 결과를 저장해 둠으로써 처리 속도를 높이는 기술로 필요할 때만 다시 계산하게 하여 불필요한 처리를 줄일 수 있다. 만약 부모가 재랜더링을 하더라도 메모이제이션이 되어 있다면 자녀 컴포넌트의 재랜더링을 막을 수 있다.

- 컴포넌트 메모이제이션

memo를 사용하면 컴포넌트 자체가 메모이제이션이 되면서 이러한 랜더링 과정에서 부모가 바뀌더라도 자식은 바뀌지 않게 된다.

- 함수 메모이제이션

그러나 함수를 Props로 받은 경우 자식 컴포넌트 입장에서는 Props가 변화했다고 판정해서 카운트업할 때마다 재랜더링을 하게 된다. 리액트에서는 함수 메모이제이션 기능인 UseCallBack을 제공하며 useCallBack의 경우 첫 번째 인수에 함수, 두번ㄷ째 인수에 useEffect와 같은 의존 배열을 받는다.

- 변수 메모이제이션

useMemo를 사용하면 변수 정의를 반복해서 하는 부하를 줄일 수 있다.

<사용 패턴>

패턴 1: 의존성이 없는 경우 (가장 일반적)

// ✅ 가장 일반적 - 의존성 배열이 비어있음
useEffect(() => {
    fetchData();
}, []); // 빈 배열로 마운트 시에만 실행

const fetchData = async () => {
    // API 호출
};

패턴 2: 의존성이 있는 경우

// ✅ 의존성이 있을 때는 useCallback 사용
const fetchData = useCallback(async () => {
    // API 호출
}, [userId, page]); // 의존성 명시

useEffect(() => {
    fetchData();
}, [fetchData]);

패턴 3: 직접 useEffect 내부에서 처리

// ✅ 간단한 경우 직접 처리
useEffect(() => {
    const fetchData = async () => {
        const res = await api.getData();
        setData(res);
    };
    fetchData();
}, [userId]); // 의존성만 명시

2. 언제 메모이제이션을 사용해야 할까?

useCallback이 필요한 경우:

함수가 여러 곳에서 재사용됨

함수가 다른 useEffect의 의존성으로 사용됨

함수가 자식 컴포넌트에 props로 전달됨

함수 내부에서 많은 상태값을 참조함

useCallback이 불필요한 경우:

함수가 useEffect 내부에서만 사용됨

함수가 단순하고 의존성이 적음

컴포넌트가 자주 리렌더링되지 않음

3. 실제 예시 비교

❌ 문제가 있는 코드:

const MyComponent = () => {
    const [data, setData] = useState([]);
    const [userId, setUserId] = useState(1);

    // 매번 새로운 함수가 생성됨
    const fetchData = async () => {
        const res = await api.getData(userId);
        setData(res);
    };

    // 무한 루프 발생!
    useEffect(() => {
        fetchData();
    }, [fetchData]); // fetchData가 매번 변경됨
};

✅ 해결 방법 1: useCallback 사용

const MyComponent = () => {
    const [data, setData] = useState([]);
    const [userId, setUserId] = useState(1);

    const fetchData = useCallback(async () => {
        const res = await api.getData(userId);
        setData(res);
    }, [userId]); // userId가 변경될 때만 함수 재생성

    useEffect(() => {
        fetchData();
    }, [fetchData]);
};

✅ 해결 방법 2: 직접 처리 (더 간단)

const MyComponent = () => {
    const [data, setData] = useState([]);
    const [userId, setUserId] = useState(1);

    useEffect(() => {
        const fetchData = async () => {
            const res = await api.getData(userId);
            setData(res);
        };
        fetchData();
    }, [userId]); // userId가 변경될 때만 실행
};

4. 권장사항

간단한 경우 (권장):

useEffect(() => {
    const fetchData = async () => {
        // API 호출
    };
    fetchData();
}, [dependency]);

복잡한 경우:

const fetchData = useCallback(async () => {
    // 복잡한 로직
}, [dependencies]);

useEffect(() => {
    fetchData();
}, [fetchData]);

로컬에서 go 공통 모듈을 수정하고 싶을 때 (replace)

체인의정석 — Wed, 17 Sep 2025 15:57:03 +0900

go로 백엔드를 작업할 때 보통 자체적인 go 모듈을 go common과 같은 이름으로 넣고 프로젝트에서 쓰는 레포에서 공통적으로 사용하는 경우가 많다고 한다. node.js나 nest를 할 때는 거의 퍼블릭 모듈만 썼었는데 go는 자체적으로 구현하는 회사들이 더 많은거 같다. 이렇게 자체 모듈을 쓰는 경우 코드를 수정할 때 common모듈과 함께 프로젝트 수정까지 들어가는 경우가 존재한다.

그럴 때는 go.mod에서 원래대로 정의를 해준 후에 하단에

replace github.com/레포이름/go-common => /Users/chohyunki/go/src/go-common

해당 replace 명령어를 써서 정의를 해두면 로컬에 있는 레포 기준으로 작동이 가능하다.

작동이 모두 잘 되는것을 로컬에서 확인하면 go-common과 함께 원래 부분을 수정해서 올리고 배포하면 된다.

Ts에서 export가 하나도 정의되어 있지 않은 경우 (모듈 vs 파일)

체인의정석 — Wed, 20 Aug 2025 17:01:58 +0900

현상 : 평소에 모듈의 경우 모듈 정의를 다 하고 상용하였으나, 인계 받은 코드에서 export에 대한 선언 없이 모듈처럼 특정 파일을 사용하고 있는 상황. 하지만 하나라도 export를 붙이면 컴파일 오류가 발생. 해당 방식으로 사용되는 케이스는 처음봐서 어떠한 원리로 동작하는지 파악

결과 : typescript가 파일 자체를 모듈로 취급할지 아니면 스크립트로 취급할지를 결정

파일 안에 export나 import가 한 줄도 없으면 해당 파일은 모듈이 아닌 전역스코프에 포함되는 스크립트로 취급 이에 따라서 import 구문 없이 바로 사용가능하지만 충돌할 위험이 커지기 때문에 사용이 권장되지는 않음.

보통은 export를 정의하고 import를 정의해서 사용.

TypeScript에서는 ECMAScript 2015(ES6)와 마찬가지로, 최상위 레벨에 import나 export가 있는 모든 파일은 모듈로 간주됩니다.

반대로, 최상위 import나 export 선언이 없는 파일은 그 내용이 전역 스코프에서 사용 가능한 스크립트로 취급됩니다.

https://www.typescriptlang.org/ko/docs/handbook/modules.html

Documentation - Modules

How modules work in TypeScript

www.typescriptlang.org

*일단 기존의 코드의 수정사항이 많기 때문에 내버려두고 export를 후에 처리하기로 결정, 작동은 하지만 매우 안좋은 코딩 방식으로 생각 됨