행복하기 위한 삶

direnv 사용법

워니주니구니 — Thu, 26 Mar 2026 18:41:17 +0900

zsh에서 direnv (핸즈온)

공식 문서: direnv.net — 아래는 여러 AWS 계정 쓸 때 AWS_PROFILE·kubectl 컨텍스트를 디렉터리마다 고정하는 한 번에 붙여 넣기 예시다. REPO만 본인 클론 경로로 바꾼 뒤 위에서 아래로 실행하면 된다.

# --- 최초 1회: 설치 + zsh 훅 ---
brew install direnv
grep -q 'direnv hook zsh' ~/.zshrc 2>/dev/null || echo 'eval "$(direnv hook zsh)"' >> ~/.zshrc
source ~/.zshrc

# --- 레포 준비 (이 줄만 수정) ---
REPO=/path/to/repo
cd "$REPO"

# --- 루트 .envrc (플레이스홀더는 본인 값으로) ---
cat > .envrc <<'EOF'
export AWS_PROFILE=YOUR_AWS_PROFILE
export KUBECONFIG="${KUBECONFIG:-$HOME/.kube/config}"
kubectl config use-context arn:aws:eks:REGION:ACCOUNT_ID:cluster/CLUSTER_NAME >/dev/null 2>&1 || true
EOF

direnv allow .

# --- terraform/.envrc (루트와 별도 파일, source_up 한 줄. terraform/ 디렉터리 필요) ---
mkdir -p terraform
echo 'source_up' > terraform/.envrc
direnv allow terraform

# --- 확인 ---
cd "$REPO/terraform"
echo "AWS_PROFILE=$AWS_PROFILE"
kubectl config current-context

.envrc 내용을 고쳤으면 그 디렉터리에서 direnv allow 다시 실행한다.

MAC OS Bootstraping

워니주니구니 — Tue, 24 Mar 2026 17:35:56 +0900

새 Mac 한 번에 세팅: Homebrew, Brewfile, Oh My Zsh

기존 맥에서 쓰던 Homebrew 패키지 목록을 Brewfile로 모아 두고, 새 맥에서는 스크립트 하나로 Command Line Tools → Homebrew → 패키지 일괄 설치 → Oh My Zsh까지 돌리는 방법을 정리했다.

무엇을 하는지

Xcode Command Line Tools가 없으면 설치를 유도하고, 끝나면 다시 실행하라고 안내한다.
Homebrew가 없으면 공식 설치 스크립트로 비대화형 설치한다.
같은 폴더의 Brewfile로 brew bundle을 실행해 formula·cask를 한 번에 맞춘다.
~/.oh-my-zsh가 없을 때만 Oh My Zsh를 비대화형(--unattended)으로 설치한다. 기본 로그인 셸은 자동으로 바꾸지 않는다.

파일 배치

같은 디렉터리에 두 파일을 둔다.

scripts/mac/
  Brewfile
  bootstrap.sh

bootstrap.sh에 실행 권한을 주면 편하다.

chmod +x scripts/mac/bootstrap.sh

`Brewfile`

로컬에서 brew list로 나온 항목을 기준으로 두었고, 필요에 따라 줄을 추가·삭제하면 된다. 단독으로 쓰려면:

brew bundle --file=/path/to/Brewfile

# 새 Mac 부트스트랩 — 로컬 brew 목록 기준 (scripts/mac/bootstrap.sh 와 함께 사용)
# 사용: brew bundle --file="$(dirname "$0")/Brewfile"

# Shell / 도구
brew "bash"
brew "git"
brew "grep"
brew "zsh"
brew "direnv"
brew "socat"

# Python (프로젝트별 venv용)
brew "python@3.13"
brew "python@3.14"

# AWS / 클라우드 CLI
brew "awscli"

# Kubernetes / IaC
brew "helm"
brew "terraform"
brew "terraform-docs"
brew "tfenv"
brew "tflint"
brew "trivy"

# DB 클라이언트
brew "mysql-client"

# Git hooks
brew "pre-commit"

# UI (선택)
cask "openlens"

`bootstrap.sh`

#!/usr/bin/env bash
# 새 Mac에서 Homebrew + Brewfile + Oh My Zsh를 한 번에 설치합니다.
# 사용: bash scripts/mac/bootstrap.sh
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
BREWFILE="${SCRIPT_DIR}/Brewfile"

log() { printf '\033[1;32m[%s]\033[0m %s\n' "$(date '+%H:%M:%S')" "$*"; }
warn() { printf '\033[1;33m[%s]\033[0m %s\n' "$(date '+%H:%M:%S')" "$*" >&2; }

if ! xcode-select -p &>/dev/null; then
  warn "Xcode Command Line Tools가 없습니다. 설치 창에서 확인을 눌러 주세요."
  xcode-select --install || true
  warn "설치 완료 후 이 스크립트를 다시 실행하세요."
  exit 1
fi

if ! command -v brew &>/dev/null; then
  log "Homebrew 설치 중..."
  NONINTERACTIVE=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
fi

# Apple Silicon: PATH에 brew 추가 (현재 세션)
if [[ -x /opt/homebrew/bin/brew ]]; then
  eval "$(/opt/homebrew/bin/brew shellenv)"
elif [[ -x /usr/local/bin/brew ]]; then
  eval "$(/usr/local/bin/brew shellenv)"
fi

if ! command -v brew &>/dev/null; then
  warn "brew를 PATH에서 찾을 수 없습니다. 터미널을 다시 열거나 ~/.zprofile 에 brew shellenv를 추가한 뒤 다시 실행하세요."
  exit 1
fi

log "brew bundle 실행: ${BREWFILE}"
brew bundle --file="${BREWFILE}"

if [[ ! -d "${HOME}/.oh-my-zsh" ]]; then
  log "Oh My Zsh 설치 중..."
  # --unattended: 프롬프트 없이 설치(기본 셸 자동 변경 없음 — 필요 시 chsh -s 로 zsh 지정)
  sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended
else
  log "Oh My Zsh 이미 설치됨 (~/.oh-my-zsh), 건너뜀"
fi

log "완료. 터미널을 새로 열거나: eval \"\$($(brew --prefix)/bin/brew shellenv)\""

실행 방법

저장소를 클론했거나 위 두 파일만 복사한 뒤:

bash scripts/mac/bootstrap.sh

또는:

./scripts/mac/bootstrap.sh

메모

로그인 셸을 Homebrew zsh로: chsh -s "$(brew --prefix zsh)/bin/zsh" (한 번만).
패키지 목록 갱신: 기존 맥에서 brew leaves 등으로 확인한 뒤 Brewfile을 수정한다.
App Store / DMG 앱은 Brewfile의 cask로 옮길 수 있는 것만 넣는다. 나머지는 수동 설치 목록을 블로그에 따로 적어두면 된다.

[ISMS] AWS WorkSpaces Pools + Okta SAML 세부 구성 가이드 (2편)

워니주니구니 — Thu, 19 Mar 2026 10:20:02 +0900

ISMS 인증심사를 위한 망분리를 위해 WorkSpaces Pools를 구성한 과정을 단계별로 정리했다. Okta SAML SSO 연동, non-persistent Pool, 커스텀 이미지(Chrome 기본)까지 포함한다.

개요

목적: ISMS 인증심사 대응 망분리. 개인정보 접근 환경을 일반 업무망과 분리한 전용 WorkSpaces Pool 구성
사전 준비: 리전(예: ap-northeast-2), VPC(Private 서브넷 2개, NAT), Okta Admin 권한, AWS IAM·WorkSpaces 콘솔 접근

관련 글: 구성기 (1편)에서 WSP, 트러블슈팅 확인. 1편 먼저 읽기 권장.

[일반 업무망]                    [개인정보 접근 전용망]
  사용자 PC  ······················►  admin (직접 접근 불가)
      │
      ▼
    Okta  ──(SAML)───►  WorkSpaces Pool  ───(NAT EIP)───►  admin

사전 확인

항목	확인
리전	Pool 운영 리전 (예: ap-northeast-2 서울)
VPC	Private 서브넷 2개 (서로 다른 AZ), NAT Gateway 아웃바운드
Okta	Admin 권한, SAML 앱 생성 가능
AWS	IAM, WorkSpaces 콘솔 접근 권한

aws ec2 describe-subnets --filter "Name=vpc-id,Values=YOUR_VPC_ID" \
  --region ap-northeast-2 \
  --query 'Subnets[*].[SubnetId,AvailabilityZone,CidrBlock]' --output table

방법

Step 1: Pools 디렉토리 생성

WorkSpaces 콘솔 접속
Directories, Create directory
WorkSpace type: Pool
User identity source: User access URL placeholder (나중에 Okta Sign on URL로 변경), Relay state parameter name 비움
Directory information: Name, Description
Networking: VPC, Private 서브넷 2개 (서로 다른 AZ), Access to internet 활성화 (Private 시 생성 후 CLI로 false)
Security group: 아웃바운드 TCP 80, 443, UDP 4195
Active Directory Config: 건너뜀
Storage: Home folders 비활성화
Create directory

확인: 디렉토리 ID (wsd-로 시작), Registration code 메모

Step 2: Okta SAML 앱 생성

Okta Admin, Applications, Create App Integration
SAML 2.0, Next
Single sign on URL: https://signin.aws.amazon.com/saml
Audience URI: https://signin.aws.amazon.com/saml
Name ID format: Persistent
Save
Sign On 탭, Identity Provider metadata URL 복사

Step 3: IAM SAML IdP 생성

IAM Identity providers 접속
Create provider, Provider type: SAML
Provider name: 예) OktaWorkSpacesPools
Metadata document: Okta 메타데이터 URL 붙여넣기 또는 XML 파일 업로드
Create provider

Step 4: IAM SAML 역할 생성

IAM Roles, Create role
Trusted entity: SAML 2.0 federation, Step 3 IdP 선택
Allow programmatic access only
Role name: 예) WorkSpacesPoolsOktaRole, Create role

Trust relationships 수정:

sts:TagSession 추가
Condition을 SAML:aud = https://signin.aws.amazon.com/saml 로 변경 (SAML:sub_type 아님)

"Condition": {
  "StringEquals": {
    "SAML:aud": "https://signin.aws.amazon.com/saml"
  }
}

인라인 정책 추가:

{
  "Effect": "Allow",
  "Action": [
    "workspaces:CreateStreamingSession",
    "workspaces:DescribeWorkspacesPoolDirectory",
    "workspaces:Stream"
  ],
  "Resource": "arn:aws:workspaces:ap-northeast-2:YOUR_ACCOUNT_ID:directory/DIRECTORY_ID"
}

Step 5: workspaces_DefaultRole

IAM, Roles, workspaces_DefaultRole 검색
없으면: WorkSpaces Quick Setup 또는 Personal WorkSpace 1회 실행으로 자동 생성
Add permissions, Attach policies, AmazonWorkSpacesPoolServiceAccess 연결

Step 6: Okta SAML 앱 속성

Okta Admin, Applications, Step 2 앱 클릭
Sign On 탭, Edit
Attribute statements, Add Attribute 3개:

Name	Value
`https://aws.amazon.com/SAML/Attributes/Role`	`"arn:aws:iam::YOUR_ACCOUNT_ID:role/WorkSpacesPoolsOktaRole,arn:aws:iam::YOUR_ACCOUNT_ID:saml-provider/OktaWorkSpacesPools"` (따옴표 포함, Constant)
`https://aws.amazon.com/SAML/Attributes/RoleSessionName`	`user.profile.email`
`https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email`	`user.profile.email`

Save
Assign 탭, 사용자 또는 그룹 할당

Step 7: Okta Relay State

Okta 앱, Sign On, Edit, Show Advanced Settings
Relay State URL: https://workspaces.euc-sso.ap-northeast-2.aws.amazon.com/sso-idp?registrationCode=REGISTRATION_CODE
REGISTRATION_CODE를 Step 1 디렉토리 Registration code로 교체 (공백은 +)
파라미터명: RelayState

Step 8: 디렉토리에 SAML 활성화

WorkSpaces, Directories, Pools directories
Step 1 디렉토리 선택
Authentication, Edit, Edit SAML 2.0 Identity Provider
User Access URL: Okta 앱 Sign on URL 전체 복사 (appId 포함 필수)
IdP deep link parameter name: RelayState
Save

Step 9: WorkSpaces Pool 생성

WorkSpaces, Pool, Create WorkSpaces Pools
Bundle: Value (Windows Server 2019). Pool은 Linux 미지원
Running mode: AutoStop
Manual scaling: Minimum 0, Maximum 사용 인원 + 여유
Select directory: Step 1 디렉토리
Create WorkSpace Pool

Step 10: EnableInternetAccess 수정 (Private 서브넷 시)

aws workspaces modify-workspace-creation-properties \
  --resource-id DIRECTORY_ID \
  --workspace-creation-properties EnableInternetAccess=false \
  --region ap-northeast-2

Step 11: 접속 테스트

Okta 앱에 할당된 사용자로 로그인
해당 앱 타일 클릭
WorkSpaces Pool 세션 시작
또는 https://clients.amazonworkspaces.com에서 Registration code 입력

(선택) Step 12: 커스텀 이미지 생성

Chrome 기본 브라우저 등 커스텀 설정이 필요하면 아래 순서로 진행. 이미지 빌더는 반드시 Value (Server 2019).

12.1 Simple AD 생성 (도쿄)

서울에는 Simple AD 없음. 도쿄(ap-northeast-1)에서 생성.

WorkSpaces 콘솔, 리전 ap-northeast-1
Directories, Create directory
WorkSpace type: Personal, User identity source: Simple AD
Directory DNS name: imagebuilder.local (FQDN, 점 포함 필수)
Directory NetBIOS name: IMAGEBUILDER
Administrator password: 8-64자
Networking: VPC, Private 서브넷 2개
Create directory

12.2 이미지 빌더 WorkSpace (도쿄)

WorkSpaces (도쿄), Create WorkSpace
Directory: 12.1 Simple AD
Bundle: Value (Windows Server 2019) (WSP 필수)
User: imagebuilder 등 1명
Create WorkSpace, Available 대기

12.3 Chrome 설치

WorkSpace 접속
Edge로 Chrome 다운로드 후 설치
설정, 앱, 기본 앱, 웹 브라우저, Chrome
캐시·히스토리 삭제

12.4 Image Checker

WorkSpace 재부팅
C:\Program Files\Amazon\ImageChecker.exe 실행
Run, 모든 검사 PASSED
Validation Successful 확인

12.5 커스텀 이미지 생성 (도쿄)

WorkSpaces (도쿄), 해당 WorkSpace 선택
Actions, Create image
Image name: 예) pool-chrome
Create image, 완료 대기

12.6 이미지 복사 (도쿄에서 서울로)

WorkSpaces, Images, Image Registry, ap-northeast-1
이미지 선택, Actions, Copy image
Destination: ap-northeast-2 (Seoul)
Copy image, 완료 대기

12.7 커스텀 번들 생성 (서울)

WorkSpaces, 리전 ap-northeast-2
Images, Image Registry, 복사된 이미지, Create bundle
Compute: Value (2 vCPU, 4GB RAM)
Storage: Value와 동일 (Root 80GB)
Bundle name: 예) pool-chrome-bundle
Create bundle, Bundle ID 확인

12.8 Pool에 커스텀 번들 적용

aws workspaces update-workspaces-pool \
  --pool-id POOL_ID \
  --bundle-id BUNDLE_ID \
  --region ap-northeast-2

12.9 빌드 리소스 삭제

도쿄 이미지 빌더 WorkSpace 삭제
도쿄 Simple AD 디렉토리 삭제
도쿄 커스텀 이미지 삭제 (선택)

체크리스트

Step 1: Pools 디렉토리
Step 2-4: Okta, IAM IdP, IAM 역할
Step 5: workspaces_DefaultRole
Step 6-8: Okta 속성, Relay State, 디렉토리 SAML
Step 9-11: Pool 생성, EnableInternetAccess, 접속 테스트
Step 12: 커스텀 이미지 (선택, Value/Server 2019 필수)

참고

#AWS #WorkSpaces #WorkSpacesPools #Okta #SAML #SSO #ISMS #망분리 #인증심사 #커스텀이미지 #WSP #클라우드데스크톱

[ISMS] AWS WorkSpaces Pools + Okta SAML + 커스텀 이미지 구성기 (1편)

워니주니구니 — Thu, 19 Mar 2026 10:15:27 +0900

ISMS 인증심사를 위한 망분리가 목적이었다. 개인정보를 다루는 내부 관리 페이지 접속을 일반 업무망과 분리하고, WorkSpaces Pools로 전환하면서 Okta SSO 연동과 Chrome 기본 설치 커스텀 이미지를 구성했다. 이 과정에서 겪은 것들을 정리해봤다.

개요

목적: ISMS 인증심사 대응 망분리. 개인정보 접근 환경을 일반 업무망과 분리
구성: WorkSpaces Pools (non-persistent), Okta SAML, 커스텀 이미지 (Chrome 기본)
접속 흐름: Okta 앱 클릭, SAML 인증, Pool 세션 할당, 내부 페이지 접속

관련 글: 세부 구성 가이드 (2편)에서 Step 1-12 절차 확인

망분리 구조

일반 업무망에서는 admin 페이지에 직접 접근할 수 없고, Okta 인증 후 WorkSpaces Pool(전용망) 세션을 통해서만 접근한다. Pool은 Private 서브넷에 있으며 NAT EIP만 admin 화이트리스트에 등록된다.

[일반 업무망]                         [개인정보 접근 전용망]
  사용자 PC  ························►  admin (직접 접근 불가)
      │
      ▼
    Okta  ──(SAML)────►  WorkSpaces Pool  ───(NAT EIP)───►  admin

1차 시도: Server 2022 커스텀 이미지 – 실패

Windows Server 2022 기반으로 커스텀 이미지를 만들었다. Image Checker 통과, 서울 복사, 번들 생성까지 문제없이 됐다. Pool에 해당 번들을 적용하려 하니 다음 에러가 났다.

Only bundles with WorkSpaces Streaming Protocol are supported

원인: Server 2022 기반 이미지는 DCV 프로토콜 사용. Pool은 WSP 번들만 지원
결과: Pool 적용 불가

2차 시도: Server 2019 (Value) 기반으로 재생성 – 성공

이미지 빌더 WorkSpace를 Value (Windows Server 2019) 번들로 다시 만들고, 커스텀 이미지·번들도 모두 Server 2019 기반으로 재생성했다.

해결: 이미지 빌더 WorkSpace 생성 시 반드시 Value (Windows Server 2019) 선택
비고: Server 2022는 Pool에서 사용 불가

Simple AD는 서울에 없음

WorkSpaces 커스텀 이미지를 만들려면 Simple AD 또는 Managed AD가 필요하다. 서울(ap-northeast-2)에는 Simple AD가 없다. Managed AD만 지원한다.

방법: 이미지 빌드용 WorkSpace를 도쿄(ap-northeast-1) 에 두고, Simple AD + WorkSpace 생성 후 이미지 생성. 이미지는 서울로 복사, 서울에서 번들 생성, Pool 적용. 빌드 완료 후 도쿄 WorkSpace·Simple AD 삭제 (비용 절감)

[도쿄 ap-northeast-1]                    [서울 ap-northeast-2]
  Simple AD                               이미지 복사
      │                                       │
      ▼                                       ▼
  이미지 빌더 WorkSpace  ──────────────►   번들 생성
      │                                       │
      ▼                                       ▼
  커스텀 이미지 생성  ─────────────────►  Pool 적용

커스텀 이미지 재빌드 시 기존 리소스 처리

Server 2022로 잘못 만든 경우, 기존 WorkSpace는 OS 변경 불가. 삭제 후 새로 만들어야 한다.

기존 리소스	처리
이미지 빌더 WorkSpace	삭제 후 Value(Server 2019)로 새로 생성
Simple AD	그대로 사용. 새 WorkSpace 생성 시 동일 디렉토리 선택
도쿄 커스텀 이미지	선택 삭제 (서울에 복사본 있으면 불필요)
서울 기존 이미지/번들	새 번들로 Pool 업데이트 후 선택 삭제

순서: 기존 WorkSpace 삭제, Value(Server 2019)로 새 WorkSpace 생성, Chrome 설치·Image Checker, 이미지 생성, 서울 복사, 번들 생성, Pool 업데이트, 도쿄 빌드 리소스 삭제

Okta SAML 연동 시 자주 나오는 에러

`Not authorized to perform sts:AssumeRoleWithSAML`

원인: Trust Policy의 Condition이 SAML:sub_type으로 되어 있음
해결: SAML:aud로 변경

"Condition": {
  "StringEquals": {
    "SAML:aud": "https://signin.aws.amazon.com/saml"
  }
}

404 또는 접속 실패

원인: User Access URL에 Okta 앱 Sign on URL 전체가 아님. appId(xxx_yyy_1) 누락 시 404
해결: Okta 앱, Sign On, Metadata details에서 Sign on URL 값 그대로 복사

`Invalid property email in expression user.email`

원인: user.email 미지원
해결: user.profile.email 사용

`Something went wrong` (WorkSpaces 클라이언트)

원인: IAM 역할에 workspaces:Stream 권한 없음
해결: workspaces:CreateStreamingSession, workspaces:DescribeWorkspacesPoolDirectory, workspaces:Stream 디렉토리 리소스에 추가

`Unable to connect` (번들 변경 후)

원인: 커스텀 번들이 WSP 아님 (Server 2022 기반), 또는 Pool capacity 0, STOPPED
해결: WSP 호환 번들(Server 2019 기반) 확인, Pool capacity 1 이상, RUNNING 상태 확인

기타

Directory DNS name 규칙 (Simple AD)

FQDN 형식 필수. 점(.) 포함 xxx.yyy 형태.

올바름: imagebuilder.local, corp.example.com
잘못됨: corp (점 없음), admin-pool-image-builder (점 없음)

Private 서브넷 + EnableInternetAccess

Pool 디렉토리를 Private 서브넷에 두고 NAT 사용 시, EnableInternetAccess=false 로 설정. 콘솔 생성 시 true로 두고, 생성 후 CLI로 false 변경.

aws workspaces modify-workspace-creation-properties \
  --resource-id <DIRECTORY_ID> \
  --workspace-creation-properties EnableInternetAccess=false \
  --region ap-northeast-2

Security Group 아웃바운드

프로토콜	포트	용도
TCP	80	HTTP, EC2 메타데이터
TCP	443	HTTPS
UDP	4195	WorkSpaces 스트리밍

알게 된 점 정리

Pool은 WSP 번들만 지원
커스텀 이미지·번들은 반드시 Value (Windows Server 2019) 기반. Server 2022는 사용 불가.
Simple AD는 서울에 없음
이미지 빌드는 도쿄에서 하고, 이미지만 서울로 복사.
Okta Trust Policy는 SAML:aud
IAM 마법사가 넣는 SAML:sub_type은 잘못됨.
User Access URL에 appId 필수
Sign on URL 전체 복사. appId 누락 시 404.
EnableInternetAccess=false
Private 서브넷 + NAT 사용 시 CLI로 설정. NAT EIP를 admin 화이트리스트에 등록.

참고

#AWS #WorkSpaces #WorkSpacesPools #Okta #SAML #SSO #ISMS #망분리 #인증심사 #커스텀이미지 #WSP #클라우드데스크톱

Aurora MySQL 대용량 테이블 DROP COLUMN

워니주니구니 — Thu, 19 Mar 2026 01:02:24 +0900

Aurora MySQL 대용량 테이블 DROP COLUMN, 두 번 실패 후 성공한 기록

수억 행, 200GB가 넘는 테이블에서 컬럼을 제거해야 할 때가 있다. ALTER TABLE DROP COLUMN은 단순해 보이지만, 테이블 규모가 크면 예상보다 훨씬 오래 걸리고, 리소스 부족으로 실패하기도 한다. 이번에는 두 번 실패한 뒤 세 번째 시도에서 성공한 과정을 정리해봤다.

배경: 왜 컬럼을 제거했나

개인정보 보호를 위해 기존 평문 컬럼을 제거하고, 암호화된 컬럼만 남기는 작업이었다. 대상 테이블은 감사(audit) 로그용으로, 수억 행에 200GB 이상의 데이터와 인덱스를 가지고 있었다.

1차 시도: 일괄 DROP – 실패

첫 시도는 3개 컬럼을 한 번에 제거하는 방식이었다.

ALTER TABLE target_table
  DROP COLUMN col1,
  DROP COLUMN col2,
  DROP COLUMN col3,
  ALGORITHM=INPLACE,
  LOCK=NONE;

인스턴스 스펙: (2 vCPU, 16GB 메모리)
실행 시점: 새벽 (트래픽 최소)
결과: 실패

추정 원인은 리소스 부족이었다. 대용량 테이블 리빌드 시 메모리, lock wait timeout 등에 여유가 부족했을 가능성이 크다.

2차 시도: 컬럼별 분리 실행 – 또 실패

부담을 줄이려고 컬럼을 하나씩 나눠서 실행해봤다.

ALTER TABLE target_table DROP COLUMN col1, ALGORITHM=INPLACE, LOCK=NONE;
-- 완료 후
ALTER TABLE target_table DROP COLUMN col2, ALGORITHM=INPLACE, LOCK=NONE;
-- 완료 후
ALTER TABLE target_table DROP COLUMN col3, ALGORITHM=INPLACE, LOCK=NONE;

결과: 실패

컬럼을 나눠도 테이블 전체 리빌드가 필요하다는 점은 같다. 한 번에 3개를 하든 1개씩 하든, 처리해야 할 데이터 양은 비슷하고, 결국 같은 리소스 한계에 부딪혔다.

3차 시도: 스펙업 후 재시도 – 성공

사전 준비

인스턴스 스펙업

항목	변경 전	변경 후
vCPU	2	16
메모리	16GB	128GB

Writer, Reader를 순차적으로 스펙업 (디비스펙업 시에는 Reader부터 하면 failover를 한 번만 할 수 있다)
Storage-optimization이 끝난 뒤 ALTER 실행 (한 인스턴스가 Storage-optimization 중일 때 다른 인스턴스 수정은 가능하지만, DDL 복제 부담을 줄이려면 모두 available 상태일 때 실행하는 것이 안전함)

세션 타임아웃 설정

SET SESSION wait_timeout = 86400;
SET SESSION lock_wait_timeout = 86400;

SET SESSION은 해당 연결에만 적용되므로, 다른 서비스에는 영향을 주지 않는다.

실행 및 결과

동일한 ALTER를 다시 실행했고, 약 3~4시간 후 성공적으로 완료되었다.

진행 상황 모니터링

수 시간 걸리는 작업이라, 진행 여부를 확인할 방법이 필요했다.

1. Performance Schema

SELECT * FROM performance_schema.events_stages_current 
WHERE EVENT_NAME LIKE '%alter%' OR EVENT_NAME LIKE '%copy%';

stage/innodb/alter table (merge sort) → merge sort 단계 (가장 오래 걸림)
stage/innodb/alter table (insert) → insert 단계
WORK_COMPLETED, WORK_ESTIMATED가 함께 증가하면 진행 중

2. Performance Insights

wait/io/file/innodb/innodb_temp_file wait가 보이기 시작하면, 임시 파일 I/O가 진행 중이라는 의미로, 실제 데이터 복사 단계에 진입한 것이다.
CPU 사용률이 낮게 나와도(예: 11%) I/O bound 구간에서는 정상이다.

3. CloudWatch – FreeLocalStorage

ALTER 진행 중: 임시 파일 사용으로 FreeLocalStorage 감소
완료 후: 정리되면서 원래 수준으로 복귀

이 지표만으로도 "진행 중인지", "완료되었는지"를 대략 파악할 수 있었다.

4. 프로세스 확인

SHOW PROCESSLIST;

State가 copying to tmp table 또는 altering table이면 진행 중이다.

알게 된 점 정리

컬럼별 DROP이 항상 유리한 건 아니다
테이블 리빌드 규모가 같다면, 나눠서 해도 리소스 부담은 비슷하다.
대용량 DDL은 인스턴스 스펙이 중요하다
메모리와 CPU가 충분해야 버퍼 풀, 정렬, I/O를 감당할 수 있다.
Storage-optimization은 인스턴스별 제한
한 인스턴스가 Storage-optimization 중이어도, 다른 인스턴스는 수정할 수 있다. 다만 DDL 복제 부담을 고려하면, 모두 available일 때 실행하는 편이 안전하다.
FreeLocalStorage로 진행 여부 추정 가능
CloudWatch에서 이 지표가 줄었다가 다시 올라오면, ALTER가 끝났을 가능성이 높다.
디비스펙업 시 Reader부터
Reader를 먼저 스펙 다운하면 failover를 한 번만 할 수 있다.

실패 시 대안

같은 방식으로 또 실패한다면, 아래를 검토할 수 있다.

방법	비고
pt-online-schema-change	청크 단위로 처리, Aurora에서도 사용 가능
gh-ost	바이너리 로그 기반 온라인 스키마 변경
유지보수 시간 + ALGORITHM=COPY	다운타임을 허용할 수 있다면, 한 번에 처리 가능

마치며

대용량 테이블 DDL은 "쿼리 한 줄"이지만, 실제로는 수 시간이 걸리고, 리소스 설계가 중요하다. 이번 경험을 바탕으로, 비슷한 규모의 작업을 할 때 참고할 수 있기를 바란다.

MongoDB 디스크 공간 정리 (compact 작업 정리)

워니주니구니 — Thu, 5 Mar 2026 13:28:42 +0900

MongoDB 디스크 공간 정리 (compact 작업 정리)

MongoDB에서 WiredTiger 스토리지 엔진을 사용할 때 삭제된 데이터로 인해 **디스크 공간 단편화(fragmentation)**가 발생할 수 있다. 이때 compact 명령어를 사용해 스토리지를 정리할 수 있다.

1. Secondary 노드 직접 접속

compact는 Primary가 아닌 Secondary 노드에서 실행해야 하므로,
특정 노드에 직접 접속할 수 있도록 directConnection 옵션을 사용한 connection string을 사용한다.

Compass를 사용해서 작업하면 한결 수월하다.

(민감 정보 제거 예시)

mongodb://<user>:<password>@<secondary-host>:27017/?replicaSet=<replica-set-name>&directConnection=true&tls=true

예시

mongodb://user:password@atlas-xxxxx-shard-00-01.xxxxx.mongodb.net:27017/?replicaSet=atlas-xxxxx-shard-0&directConnection=true&tls=true

directConnection=true 옵션을 사용하면 특정 Secondary 노드에 직접 접속할 수 있다.

2. 작업 전 상태 확인

compact 작업 전에는 Replica Set 상태와 replication 상태를 반드시 확인해야 한다.
아래 명령어들은 Primary 또는 Secondary 어느 노드에서든 실행 가능하지만 일반적으로 Primary에서 전체 상태 확인을 진행한다.

db.stats()
rs.status()
db.hello()
rs.printReplicationInfo()
rs.printSecondaryReplicationInfo()
rs.status().members.map(m => ({name: m.name, state: m.stateStr, health: m.health}))

각 명령어 용도

db.stats()
DB의 data size / storage size / index size 확인
rs.status()
Replica Set 전체 상태 및 노드 역할(PRIMARY / SECONDARY) 확인
db.hello()
현재 접속 노드가 Primary인지 Secondary인지 확인
rs.printReplicationInfo()
oplog 크기 및 replication window 확인
rs.printSecondaryReplicationInfo()
Secondary replication lag 확인
rs.status().members.map(m => ({name: m.name, state: m.stateStr, health: m.health}))
모든 노드의 name / state / health 요약 확인

3. Compact 실행

compact 명령어는 서비스 영향 최소화를 위해 Secondary 노드에서 실행한다.

db.runCommand({ compact: 'yourCollectionName' })

Primary에서 실행할 경우 해당 컬렉션 write가 block될 수 있고, force 옵션을 쓰라고 나오지만 무시하는게 좋다.

4. 작업 순서

운영 환경에서는 보통 아래 순서로 진행한다.

Secondary 노드에서 compact 실행
작업 완료 후 stepdown / failover 진행하여 Primary 전환
기존 Primary가 Secondary가 되면 동일하게 compact 실행

이 방식으로 서비스 영향 없이 모든 노드를 순차적으로 정리할 수 있다.

5. 작업 시 주의사항

Analytics Node는 다른 클라우드/VPC에 존재하는 경우가 있어
접속이 되지 않으면 IP Allowlist 추가가 필요할 수 있다.
MongoDB 디스크 공간 정리 완료 후 필요에 따라서는 Cluster Spec 변경 (스케일업 / 스케일다운) 작업이 필요할 경우
수 분 ~ 수 시간까지 소요될 수 있으므로
- 로그 모니터링
- Replica 상태 모니터링
- 작업 상태 확인
을 지속적으로 수행해야 한다.
작업이 장시간 진행되거나 문제가 발생하면
MongoDB Support 티켓을 열어 함께 진행하는 것이 안전하다.

참고 문서

https://www.mongodb.com/ko-kr/docs/manual/faq/storage/#how-do-i-reclaim-disk-space-in-wiredtiger-
https://www.mongodb.com/ko-kr/docs/manual/reference/command/compact/#mongodb-dbcommand-dbcmd.compact

bitwarden 로그인할 때 에러가 날 경우

워니주니구니 — Tue, 21 Oct 2025 16:51:51 +0900

개요

Bitwarden을 처음 사용하거나 이전에 어렴풋이 사용했던 상황에서 로그인할 경우 에러가 나는 경우가 종종 있다. 패스워드가 틀렸거나 확인이 안되는 등 다양한 상황에서 제일 강력한 해결 방법중에 하나

해결

https://vault.bitwarden.com/#/recover-delete 여기서 내 이메일 계정을 삭제하면 해결되는 경우가 있다.

참고

https://vault.bitwarden.com/#/recover-delete

bitwarden enterprise my vault 안 보이는 이슈 (내 보관함)

워니주니구니 — Mon, 13 Oct 2025 17:55:39 +0900

개요

Bitwarden enterprise를 사용할 경우 admin이나 owner가 아닌 계정은 my vault (내 보관함)이 안 보인다

해결

Owner 계정으로 로그인해서 Policies 에서 Enforce organization data ownership 을 off 하면 일반 계정에서 내 보관함이 확인 된다.

참고

https://bitwarden.com/help/policies/#enforce-organization-data-ownership

[ECR] [Scanning]: Ubuntu 24.04 not supported

워니주니구니 — Wed, 6 Aug 2025 11:26:30 +0900

개요

ECR image Scanning을 할 때 지원이 안한다는 메세지와 함께 멈추는 경우가 있다.
[ECR] [Scanning]: Ubuntu 24.04 not supported

방법

Features & Settings >> Scanning >> Opt in >> Scan Type (Enhanced)

참고

https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning-basic.html
https://github.com/aws/containers-roadmap/issues/2434
https://docs.aws.amazon.com/inspector/latest/user/supported.html#w123aac53c15

CloudFront Route53 HTTPS DNS record 지원

워니주니구니 — Thu, 3 Jul 2025 11:24:20 +0900

개요

CloudFront alias로 Route53에서 HTTPS DNS record를 지원 (2025년 7월 1일)
https://aws.amazon.com/ko/blogs/networking-and-content-delivery/boost-application-performance-amazon-cloudfront-enables-https-record/

장점

DNS 쿼리 비용 절감
DNS RTT 절감
HTTPS 바로 시작

적용방법

1. CloudFront HTTP/2, HTTP/3 enable
2. Route53 a record alias CloudFront 생성
3. Route53 HTTPS record alias CloudFront 생성

확인방법

### MAC 기본 유틸 dig
# dig -v
DiG 9.10.6
# dig exmaple TYPE65

#### dig latest
# brew install bind
# echo 'alias dig="/opt/homebrew/bin/dig"' >> ~/.zshrc
# source ~/.zshrc
# dig -v                                        
DiG 9.20.10
# dig example.com HTTPS

비고 (AWS는 적용안되어 있고, 구글 이나 클라우드플레어는 잘 되어 있음)

➜  ~ dig amazonaws.com HTTPS

; <<>> DiG 9.20.10 <<>> amazonaws.com HTTPS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63616
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ba13fd850a96cabf010000006865e55ec520d43d566125a5 (good)
;; QUESTION SECTION:
;amazonaws.com.			IN	HTTPS

;; AUTHORITY SECTION:
amazonaws.com.		900	IN	SOA	dns-external-master.amazon.com. hostmaster.amazon.com. 2017224478 180 60 604800 900

;; Query time: 8 msec
;; SERVER: 168.126.63.1#53(168.126.63.1) (UDP)
;; WHEN: Thu Jul 03 11:05:18 KST 2025
;; MSG SIZE  rcvd: 147

➜  ~ dig google.com HTTPS

; <<>> DiG 9.20.10 <<>> google.com HTTPS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43173
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d6431d33010ba853010000006865e5665cb50cbf6aa8f0af (good)
;; QUESTION SECTION:
;google.com.			IN	HTTPS

;; ANSWER SECTION:
google.com.		1415	IN	HTTPS	1 . alpn="h2,h3"

;; ADDITIONAL SECTION:
google.com.		70	IN	A	142.250.198.46
google.com.		21	IN	AAAA	2404:6800:4005:81b::200e

;; Query time: 8 msec
;; SERVER: 168.126.63.1#53(168.126.63.1) (UDP)
;; WHEN: Thu Jul 03 11:05:26 KST 2025
;; MSG SIZE  rcvd: 136

➜  ~ dig cloudflare.com HTTPS

; <<>> DiG 9.20.10 <<>> cloudflare.com HTTPS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9447
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c43ae3d6d007332d010000006865e56e1ef19160a3c47d37 (good)
;; QUESTION SECTION:
;cloudflare.com.			IN	HTTPS

;; ANSWER SECTION:
cloudflare.com.		184	IN	HTTPS	1 . alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5

;; ADDITIONAL SECTION:
cloudflare.com.		294	IN	A	104.16.132.229
cloudflare.com.		294	IN	A	104.16.133.229

;; Query time: 9 msec
;; SERVER: 168.126.63.1#53(168.126.63.1) (UDP)
;; WHEN: Thu Jul 03 11:05:35 KST 2025
;; MSG SIZE  rcvd: 176

행복하기 위한 삶

direnv 사용법

zsh에서 direnv (핸즈온)

MAC OS Bootstraping

새 Mac 한 번에 세팅: Homebrew, Brewfile, Oh My Zsh

무엇을 하는지

파일 배치

Brewfile

bootstrap.sh

실행 방법

메모

[ISMS] AWS WorkSpaces Pools + Okta SAML 세부 구성 가이드 (2편)

개요

사전 확인

방법

Step 1: Pools 디렉토리 생성

Step 2: Okta SAML 앱 생성

Step 3: IAM SAML IdP 생성

Step 4: IAM SAML 역할 생성

Step 5: workspaces_DefaultRole

Step 6: Okta SAML 앱 속성

Step 7: Okta Relay State

Step 8: 디렉토리에 SAML 활성화

Step 9: WorkSpaces Pool 생성

Step 10: EnableInternetAccess 수정 (Private 서브넷 시)

Step 11: 접속 테스트

(선택) Step 12: 커스텀 이미지 생성

12.1 Simple AD 생성 (도쿄)

12.2 이미지 빌더 WorkSpace (도쿄)

12.3 Chrome 설치

12.4 Image Checker

12.5 커스텀 이미지 생성 (도쿄)

12.6 이미지 복사 (도쿄에서 서울로)

12.7 커스텀 번들 생성 (서울)

12.8 Pool에 커스텀 번들 적용

12.9 빌드 리소스 삭제

체크리스트

참고

[ISMS] AWS WorkSpaces Pools + Okta SAML + 커스텀 이미지 구성기 (1편)

개요

망분리 구조

1차 시도: Server 2022 커스텀 이미지 – 실패

2차 시도: Server 2019 (Value) 기반으로 재생성 – 성공

Simple AD는 서울에 없음

커스텀 이미지 재빌드 시 기존 리소스 처리

Okta SAML 연동 시 자주 나오는 에러

Not authorized to perform sts:AssumeRoleWithSAML

404 또는 접속 실패

Invalid property email in expression user.email

Something went wrong (WorkSpaces 클라이언트)

Unable to connect (번들 변경 후)

기타

Directory DNS name 규칙 (Simple AD)

Private 서브넷 + EnableInternetAccess

Security Group 아웃바운드

알게 된 점 정리

참고

Aurora MySQL 대용량 테이블 DROP COLUMN

Aurora MySQL 대용량 테이블 DROP COLUMN, 두 번 실패 후 성공한 기록

배경: 왜 컬럼을 제거했나

1차 시도: 일괄 DROP – 실패

2차 시도: 컬럼별 분리 실행 – 또 실패

3차 시도: 스펙업 후 재시도 – 성공

사전 준비

실행 및 결과

진행 상황 모니터링

1. Performance Schema

2. Performance Insights

3. CloudWatch – FreeLocalStorage

4. 프로세스 확인

알게 된 점 정리

실패 시 대안

마치며

MongoDB 디스크 공간 정리 (compact 작업 정리)

MongoDB 디스크 공간 정리 (compact 작업 정리)

1. Secondary 노드 직접 접속

2. 작업 전 상태 확인

3. Compact 실행

4. 작업 순서

5. 작업 시 주의사항

`Brewfile`

`bootstrap.sh`

`Not authorized to perform sts:AssumeRoleWithSAML`

`Invalid property email in expression user.email`

`Something went wrong` (WorkSpaces 클라이언트)

`Unable to connect` (번들 변경 후)