반응형

요즘 연일 AI 서비스들이 쏟아져나오고 있다.

빅테크부터 스타트업까지 정말 다양한 서비스들을 내놓고 있다. 

이제 Chat GPT, Gemini, Grok, Claude 등을 종종 다양하게 써보며 구글검색을 주로 곁들여 쓰고 있다

특히 요즘 구글검색이 너무 사용하기 좋게 변했던데 첫페이지에서 왠만한 쓸만한 답변을 다 얻고 있어서

페이지 넘겨가며 검색하는 경우가 거의 없을 정도로 줄었다.

진짜 1년전과 비교해도 검색시간이 훨씬 단축된게 심각하게 체감될 정도다.

 

워낙 다양한 AI 툴들을 써보려고 노력하고 있고, 뭔가 새로나왔다고 하면 한번씩은 써보고 하는데

작년말부터 알게된 Goover AI 는 국산이라고 해서 그래도 애정을 가지고 한번씩 사용해보는데

오늘 정말 실망스러운 리서치 결과를 보고 참 고민스럽다.

계속 쓰는게 맞는건가... 결국 빅테크인건가

 

기업공부를 위해 디앤디파마텍 회사에 대해서 조사해달라고 넣었는데 내용이 너무 별로인거다.

차마 캡쳐는 하지 않았다. 요즘 증권사 리포트에서 중요하게 언급되는 이야기는 하나도 안나오길래 재차 질문했고, 계속 빙빙 돌려말하는 것같은 답변만 내놓는다. 그래서 GLP-1 기술에 대해서 설명해달라는 언급을 하니까 그제서야 관련 언급을 하고있다. 먼가 좀 쎄한 느낌

근데 답변중에 최근에 GLP-1 기술의 파킨슨병 치료제 임상2상을 시작한다는데 이건 뭐지. 내가 보고서에서 읽었던거랑은 완전 다른 내용이다.

내가 알기로는 파킨슨병 치료제는 개발중단된걸로 알고 있었는데 올해 임상2상을 진행한다고? 전혀 금시초문, 그래서 구글검색을 해봄

정확한 내용을 확인해보니 임상실패해서 중단되었던 NLY01 이 다시 재조명받고 있어 다시 진행 가능성여부에 대해 기대한 기사가 있었다. 

무튼, AI가 완전히 잘못된 이야기를 전달해주는 것 같아서 다른 AI서비스들을 다 똑같이 질문해봤는데 다 정확히 대답해주고 Goover AI만 일단 이렇게 오류가 있는중. 

결국 해당 내용의 레퍼런스를 클릭해보니 날짜정보가 잘못되었던게 원인인것 같다. 해당 내용 끝의 6이라는 숫자 레퍼런스를 클릭해봄.

2019년 기사를 레퍼런스로 했던 것이었음. 

이거이거 레퍼런스의 날짜를 인식하는 루틴에 오류가 있는것 같아

결국 아직 시기상조인가보다. 

 

검색해보니 실제로 2019년에 임상 2상 진행시작 결국 2023년 임상실패로 개발중단.

단 60세미만의 젊은 환자에게 유의미한 변화가 보여 다시 무언가 해보려는 듯한 기대감이 있는 정도인듯하다.

구글 및 재미나이, 그록, 챗지피티 모두 유사한 답 

 

스스로 경각심을 가지고 AI 서비스를 사용할 때 레퍼런스 체크를 잘 해보자

투자는 본인의 결정이고 책임은 오롯이 자신이 지는 것이기 때문.

반응형
반응형

✅ 가비아 DNS 그대로 사용하는 방식

장점

  • 설정이 간단: EC2 퍼블릭 IP만 입력하면 끝
  • 추가 비용 없음: Route 53을 쓰지 않으니 AWS 요금 없음
  • 관리 분산: 도메인 만료/갱신은 가비아에서, 서버 관리는 AWS에서

단점

  • DNS 기능 제한적: 가비아 DNS는 단순 A/CNAME 정도만 제공 → 세밀한 트래픽 라우팅, 복잡한 레코드 관리 불편
  • 전파 속도 조금 느림: 가비아 네임서버 특성상 DNS 전파가 AWS보다 느릴 수 있음
  • AWS 서비스 연계 어려움: CloudFront, ALB, S3 웹호스팅 등을 붙일 때 Route 53보다 설정이 번거로움

✅ Route 53 사용하는 방식

장점

  • AWS 서비스와 강력한 연동:
    • CloudFront, ALB(로드밸런서), S3 정적 웹호스팅 등 쉽게 연결
    • 헬스체크, 지리적 라우팅(서울은 서울 서버, 미국은 미국 서버 등) 가능
  • 빠른 DNS 응답 속도: AWS 글로벌 인프라 기반으로 성능 우수
  • 고급 기능 제공: 가중치 라우팅, 페일오버, 지연시간 기반 라우팅 등 엔터프라이즈 기능

단점

  • 추가 비용 발생:
    • 호스팅 존 유지비 약 $0.50 / 월
    • 쿼리당 소량 비용 (트래픽 많을 때만 체감)
  • 초기 설정 복잡: 가비아에서 네임서버 변경해야 함
  • 관리 이원화: 도메인 자체는 가비아에서 갱신, DNS는 AWS에서 관리

👉 정리

  • 개인 블로그/소규모 프로젝트 → 가비아 DNS 직접 사용 (간단, 무료)
  • 서비스 규모가 크거나 AWS 서비스 적극 활용 예정 → Route 53 권장 (확장성, 성능, 유연성)
반응형
반응형

서버 디스크 공간 문제를 해결하기 위해 Docker 관련 정리 명령

  해결 방법:

  1. 사용하지 않는 Docker 이미지 정리:
  docker system prune -a --volumes

  2. Docker 빌드 캐시 정리:
  docker builder prune -a

  3. 디스크 사용량 확인:
  df -h
  du -sh /var/lib/docker/*

  4. APT 캐시 정리:
  sudo apt-get clean
  sudo apt-get autoremove

  5. 로그 파일 정리:
  sudo journalctl --vacuum-time=3d

  이런 정리 작업 후에 Docker 빌드를 다시 시도해보시기 바랍니다.

반응형
반응형

N+1 문제와 1+N 문제는 사실상 같은 문제를 다르게 표현한 것입니다.

데이터베이스 성능 최적화에서 가장 흔히 발생하는 문제 중 하나입니다.

 

N+1 문제란?

하나의 메인 쿼리 + N개의 추가 쿼리가 실행되는 문제입니다.

구체적인 예시

시나리오: 사용자 10명과 각자의 게시글을 조회

 
 
sql
-- 1. 첫 번째 쿼리: 사용자 목록 조회
SELECT * FROM users LIMIT 10;

-- 2. 각 사용자마다 개별 쿼리 실행 (N번)
SELECT * FROM posts WHERE user_id = 1;
SELECT * FROM posts WHERE user_id = 2;
SELECT * FROM posts WHERE user_id = 3;
...
SELECT * FROM posts WHERE user_id = 10;

결과: 총 11개의 쿼리 (1 + 10)

코드에서 발생하는 예시

 
 
python
# 문제가 있는 코드
users = User.objects.all()[:10]  # 1번째 쿼리

for user in users:
    posts = user.posts.all()     # 각 사용자마다 추가 쿼리
    print(f"{user.name}: {len(posts)} posts")
 
 
javascript
// JavaScript/Node.js 예시
const users = await User.findAll({ limit: 10 });  // 1번째 쿼리

for (const user of users) {
    const posts = await Post.findAll({             // N번의 추가 쿼리
        where: { userId: user.id }
    });
    console.log(`${user.name}: ${posts.length} posts`);
}

성능에 미치는 영향

 
 
사용자 10명: 11개 쿼리
사용자 100명: 101개 쿼리  
사용자 1000명: 1001개 쿼리

데이터가 증가할수록 쿼리 수가 선형적으로 증가하여 성능이 급격히 저하됩니다.

해결 방법들

1. JOIN 사용 (가장 기본적)

 
 
sql
-- 하나의 쿼리로 해결
SELECT u.*, p.* 
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
WHERE u.id <= 10;

2. Eager Loading

 
 
python
# Django ORM
users = User.objects.prefetch_related('posts')[:10]

# SQLAlchemy
users = session.query(User).options(joinedload(User.posts)).limit(10)
 
 
javascript
// Sequelize
const users = await User.findAll({
    limit: 10,
    include: [{ model: Post, as: 'posts' }]
});

3. 배치 조회

 
 
python
# 두 번의 쿼리로 해결
users = User.objects.all()[:10]
user_ids = [user.id for user in users]
posts = Post.objects.filter(user_id__in=user_ids)

# 메모리에서 매핑
posts_by_user = {}
for post in posts:
    if post.user_id not in posts_by_user:
        posts_by_user[post.user_id] = []
    posts_by_user[post.user_id].append(post)

4. DataLoader 패턴 (GraphQL에서 주로 사용)

 
 
javascript
const DataLoader = require('dataloader');

const postLoader = new DataLoader(async (userIds) => {
    const posts = await Post.findAll({
        where: { userId: userIds }
    });
    
    // userIds 순서대로 정렬하여 반환
    return userIds.map(id => 
        posts.filter(post => post.userId === id)
    );
});

1+N과 N+1의 차이점

표현 방식의 차이일 뿐 본질적으로는 동일합니다:

  • N+1: N개의 데이터를 위해 1개의 메인 쿼리 + N개의 추가 쿼리
  • 1+N: 1개의 메인 쿼리 + N개의 추가 쿼리

둘 다 같은 문제를 설명하며, N+1이 더 일반적으로 사용되는 표현입니다.

실무에서 주의할 점

숨겨진 N+1 문제

 
 
python
# 언뜻 문제없어 보이지만...
users = User.objects.select_related('profile').all()

for user in users:
    # 여기서 추가 쿼리 발생!
    recent_posts = user.posts.filter(created_at__gte=last_week)

ORM의 지연 로딩

대부분의 ORM은 기본적으로 지연 로딩(Lazy Loading)을 사용하므로, 의도치 않게 N+1 문제가 발생할 수 있습니다.

N+1 문제는 애플리케이션 성능에 치명적인 영향을 미칠 수 있으므로, 개발 단계에서부터 쿼리 최적화를 고려하고 데이터베이스 쿼리 로그를 모니터링하는 것이 중요합니다.

반응형
반응형

docker-compose

docker-compose -f docker-compose.prod.yml down 
docker-compose -f docker-compose.prod.yml up -d 
docker-compose -f docker-compose.prod.yml build --no-cache

docker-compose down 후 up 만으로 수정사항 반영되는 경우는 어떤 경우이며, docker-compose build 까지 해야 하는 경우는 어떤 경우인가요? fastAPI, nginx를 사용중입니다.

Docker Compose에서 down/up만으로 충분한 경우와 build가 필요한 경우를 구분하는 핵심은 이미지 재빌드 필요 여부입니다.

down/up 만으로 충분한 경우
설정 파일 변경
docker-compose.yml 수정
docker-compose.prod.yml 수정
환경변수 변경 (.env 파일)
포트 매핑 변경
볼륨 마운트 경로 변경
네트워크 설정 변경
볼륨 마운트된 파일 수정
yaml

이런 설정에서 호스트 파일 수정

volumes:

  • ./nginx.conf:/etc/nginx/nginx.conf
  • ./templates:/app/templates
    호스트의 nginx.conf나 templates 폴더 내용을 수정하면 down/up만으로 반영됩니다.

외부 이미지 사용 시
yaml
services:
nginx:
image: nginx:latest # 외부 이미지 사용
build가 필요한 경우
소스 코드 변경
Python 파일 수정 (FastAPI 코드)
Dockerfile 수정
requirements.txt 변경
새로운 패키지 설치
이미지 내부 파일 변경
dockerfile

Dockerfile에서 COPY되는 파일들

COPY ./app /app
COPY requirements.txt .
RUN pip install -r requirements.txt
빌드 시점에 설치되는 요소들
apt 패키지 설치
pip 패키지 설치
이미지 내부 설정 파일 변경
실제 시나리오 예시
down/up으로 충분
bash

nginx 설정 파일 수정

vim nginx.conf

환경변수 변경

vim .env

포트 변경

vim docker-compose.yml

적용

docker-compose down
docker-compose up -d
build 필요
bash

FastAPI 코드 수정

vim app/main.py

새 패키지 추가

echo "requests==2.28.0" >> requirements.txt

Dockerfile 수정

vim Dockerfile

적용

docker-compose down
docker-compose build
docker-compose up -d
판단 기준
핵심 질문: "컨테이너 내부의 파일이 변경되었는가?"

YES → build 필요
NO → down/up만 충분
추가 고려사항:

볼륨 마운트된 파일은 호스트에서 직접 수정되므로 빌드 불필요
이미지 태그가 latest인 경우 docker-compose pull로 최신 이미지 가져올 수 있음
캐시된 레이어가 있어도 코드 변경 시에는 해당 레이어부터 재빌드됨
개발 효율성을 위해 가능한 한 볼륨 마운트를 활용하여 down/up만으로 변경사항을 반영할 수 있도록 설정하는 것이 좋습니다.

반응형
반응형

Nginx의 역할과 기능

  1. Reverse Proxy (리버스 프록시)

  [브라우저] → [Nginx:80] → [FastAPI:8000]

  역할:
  - 클라이언트의 요청을 FastAPI 서버로 전달
  - FastAPI 서버의 응답을 클라이언트로 전달
  - 내부 서버(FastAPI)를 외부에 직접 노출하지 않음

  설정 예시:
  upstream fastapi {
      server fastapi:8000;  # Docker 컨테이너 이름
  }

  location / {
      proxy_pass http://fastapi;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
  }

  2. Load Balancer (로드 밸런서)

  여러 FastAPI 인스턴스가 있을 때 요청을 분산:

  upstream fastapi {
      server fastapi1:8000;
      server fastapi2:8000;
      server fastapi3:8000;
  }

  3. Static File Server (정적 파일 서버)

  location /static/ {
      alias /usr/share/nginx/html/static/;
      expires 30d;
      add_header Cache-Control "public, immutable";
  }

  효과:
  - CSS, JS, 이미지 파일을 Nginx가 직접 서빙
  - FastAPI 서버 부하 감소
  - 빠른 정적 파일 전달

  4. Security Headers (보안 헤더)

  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header X-XSS-Protection "1; mode=block" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;

  보안 기능:
  - XSS 공격 방어
  - 클릭재킹 방어
  - MIME 타입 스니핑 방지

  5. Rate Limiting (속도 제한)

  # 존 정의
  limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
  limit_req_zone $binary_remote_addr zone=auth:10m rate=5r/m;

  # 적용
  location ~ ^/(login|signup|logout) {
      limit_req zone=auth burst=2 nodelay;  # 5회/분 제한
  }

  location / {
      limit_req zone=general burst=20 nodelay;  # 10회/초 제한
  }

  효과:
  - DDoS 공격 방어
  - 무차별 로그인 시도 방지
  - 서버 리소스 보호

  6. Compression (압축)

  gzip on;
  gzip_vary on;
  gzip_min_length 1024;
  gzip_types text/plain text/css text/xml text/javascript application/json;

  효과:
  - 네트워크 대역폭 절약
  - 페이지 로딩 속도 향상
  - 사용자 경험 개선

  7. SSL/TLS Termination (SSL 종료)

  server {
      listen 443 ssl http2;
      ssl_certificate /path/to/certificate.pem;
      ssl_certificate_key /path/to/private.key;

      location / {
          proxy_pass http://fastapi;  # 내부는 HTTP 통신
      }
  }

  역할:
  - HTTPS 암호화/복호화 처리
  - FastAPI는 HTTP만 처리하면 됨
  - SSL 인증서 관리

  8. Caching (캐싱)

  location /static/ {
      expires 30d;  # 30일 캐시
  }

  location /api/ {
      proxy_cache my_cache;
      proxy_cache_valid 200 1h;  # 1시간 캐시
  }

  9. Health Check & Failover

  upstream fastapi {
      server fastapi1:8000 max_fails=3 fail_timeout=30s;
      server fastapi2:8000 backup;  # 백업 서버
  }

  내 프로젝트에서의 Nginx 역할

  현재 설정 분석:

  1. 포트 80에서 요청 받음
  2. 정적 파일 (/static/) 직접 서빙
  3. 인증 엔드포인트 특별 관리 (Rate Limiting)
  4. 모든 요청을 FastAPI:8000으로 프록시
  5. 보안 헤더 자동 추가
  6. Gzip 압축 적용

  장점:

  - 성능: 정적 파일을 Nginx가 직접 처리
  - 보안: Rate Limiting, 보안 헤더
  - 확장성: 여러 FastAPI 인스턴스로 확장 가능
  - 운영: 로그 관리, 모니터링

  FastAPI만 사용했을 때와의 차이:

  FastAPI만:
  [브라우저] → [FastAPI:8000]

  Nginx + FastAPI:
  [브라우저] → [Nginx:80] → [FastAPI:8000]

  Nginx가 웹 서버의 역할을, FastAPI가 애플리케이션 서버의 역할을 각각 담당하여 웹을 통해 보안토큰이 전송될 필요없이 효율적인 구조를 가집니다.

반응형
반응형

Claude Code의 우측 하단에 표시되는 **"Context left until auto-compact: 8%"**는 자동 압축까지 남은 컨텍스트 여유 공간을 나타냅니다.

🔍 정확한 의미 해석

"Context left until auto-compact: 8%"

  • 현재 컨텍스트 사용률: 92% (100% - 8% = 92%)
  • 자동 압축까지 남은 여유: 8%
  • 상태: 곧 자동 압축이 실행될 예정

📊 컨텍스트 상태 단계

 
 
Context left until auto-compact:
100% - 새 세션, 거의 비어있음
50%  - 중간 정도 사용
20%  - 주의 필요
8%   - ⚠️ 현재 상황 - 곧 압축 실행
2%   - 🔴 매우 위험 - 즉시 압축 필요
0%   - 자동 압축 실행됨

⚠️ 현재 8% 상황의 의미

즉시 발생할 수 있는 상황

 
 
✅ 자동 압축 곧 실행됨
⚠️ 응답 속도 약간 느려질 수 있음
⚠️ 일부 이전 컨텍스트 손실 가능
🔴 복잡한 요청 시 오류 가능성

권장 조치사항

 
 
bash
# 즉시 수동 압축 실행 (권장)
claude: /compact

# 또는 현재 상태 저장 후 새 세션
claude: /reset

🛠️ 즉시 해야 할 조치

1. 수동 압축 실행

 
 
bash
claude: /compact

압축 후 예상 결과:

  • Context left until auto-compact: 60-80%로 증가
  • 응답 속도 개선
  • 안정적인 작업 환경 복구

2. 중요한 작업 전 압축

 
 
bash
# 큰 작업을 시작하기 전에
claude: /compact

# 그 다음 작업 시작
"이제 새로운 기능을 구현해보자"

3. 세션 상태 확인

 
 
bash
# 상세 상태 확인
claude: /status

📈 압축 전후 비교

현재 상태 (8% 남음)

컨텍스트 사용률: 92%
━━━━━━━━━━━━━━━━━━━━ ▓▓ (8% 남음)

포함 내용:
- 전체 대화 히스토리
- 모든 파일 변경사항
- 디버깅 로그
- 임시 데이터
- 이전 시도들

압축 후 예상 (70% 남음)

컨텍스트 사용률: 30%
━━━━━━ ░░░░░░░░░░░░░░ (70% 남음)

압축된 내용:
- 핵심 대화만 유지
- 현재 파일 상태
- 중요한 컨텍스트
- 프로젝트 구조

🔧 압축 과정에서 일어나는 일

제거되는 정보

  • 오래된 대화 내용
  • 중간 시도들과 실패한 코드
  • 임시 파일과 테스트 코드
  • 중복된 설명들

보존되는 정보

  • 현재 작업 중인 파일들
  • 최근 중요한 대화
  • 프로젝트 구조와 설정
  • 핵심 컨텍스트 정보

타이밍별 대응 전략

8% 남음 (현재 - 즉시 조치 필요)

 
 
bash
# 지금 바로 실행
claude: /compact

# 압축 완료 후 작업 계속
"압축이 완료되었습니다. 이제 계속 작업해보겠습니다."

20% 남음 (주의 단계)

bash
# 큰 작업 전에 미리 압축
claude: /compact

50% 남음 (안전 단계)

bash
# 정상적인 작업 가능
# 필요시에만 압축 고려

💡 압축 최적화 팁

압축 전 준비사항

bash
# 1. 중요한 파일 내용 확인
"현재 작업 중인 파일들의 상태를 요약해줘"

# 2. 압축 실행
claude: /compact

# 3. 압축 후 상태 확인
"압축이 제대로 되었는지 확인해줘"

압축 후 확인사항

  • Context left 수치가 증가했는지 확인
  • 현재 파일들이 제대로 유지되었는지 확인
  • 프로젝트 구조가 보존되었는지 확인

🚨 응급 상황 대처

0%에 도달한 경우

bash
# 자동 압축이 실행되거나 오류 발생 시
claude: /reset  # 새 세션 시작

# 또는 강제 종료 후 재시작
# Ctrl+C로 종료 → claude 재실행

압축 후에도 문제가 지속되는 경우

bash
# 완전 재시작
claude: /reset

# 새 세션에서 필요한 파일만 다시 로드
"프로젝트 구조를 다시 설정해주세요"

📋 실행할 체크리스트

□ 1. 즉시 /compact 실행
□ 2. 압축 후 Context left 수치 확인 (60%+ 목표)
□ 3. 현재 파일들 상태 확인
□ 4. 프로젝트 구조 보존 여부 확인
□ 5. 정상 작업 가능 여부 테스트

결론: 현재 8%는 매우 위험한 상태입니다. 즉시 /compact 명령어를 실행하여 컨텍스트를 압축하고 안정적인 작업 환경을 확보하세요!

반응형
반응형

현재서비스 구조 확인:

  Browser → nginx (port 80) → FastAPI (port 8000) → Templates (Jinja2)

  📋 현재 서비스 특성:

  1. SSR (Server-Side Rendering): FastAPI + Jinja2 템플릿
  2. Same-Origin: 브라우저 요청과 응답이 모두 같은 도메인 (http://xx.xx.xx.xx)
  3. HTMX 사용: 일부 동적 업데이트만 AJAX

  🎯 CORS가 필요한 경우 vs 불필요한 경우:

  CORS가 필요한 경우:
  - SPA (React, Vue, Angular)에서 다른 도메인 API 호출
  - http://frontend.com → http://api.com 호출

  CORS가 불필요한 경우:
  - SSR 웹앱 (Django, Flask, FastAPI + Templates)
  - Same-Origin 요청: http://00.00.00.00 → http://00.00.00.00

  ✅ 결론: CORS 설정 불필요!

  이유:
  1. Same-Origin 정책: 모든 요청이 http://내주소 에서 시작되어 같은 도메인으로
   전송
  2. SSR 구조: HTML이 서버에서 렌더링되어 브라우저로 전송
  3. HTMX 요청도 Same-Origin: 페이지 내에서 같은 도메인으로 요청

  현재 CORS 설정은 무시됨:
  - nginx가 프록시 역할을 하므로 FastAPI는 nginx로부터만 요청을 받음
  - 브라우저는 nginx와만 통신하므로 CORS 검사 없음

반응형
반응형

YouTube Data API v3 API Key 얻는 방법

  1. Google Cloud Console 접속
    👉 Google Cloud Console 에 로그인 (구글 계정 필요)
  2. 프로젝트 생성
    • 상단 메뉴에서 프로젝트 선택새 프로젝트 만들기
    • 프로젝트 이름과 조직(없으면 개인으로) 설정 후 생성
  3. API 활성화
    • 좌측 메뉴에서 API 및 서비스 → 라이브러리
    • 검색창에 YouTube Data API v3 입력
    • 선택 후 사용 설정(Enable) 클릭
  4. API Key 생성
    • 좌측 메뉴에서 사용자 인증 정보 (Credentials)
    • 사용자 인증 정보 만들기 → API 키
    • 새 API Key가 발급됨 (예: AIzaSy...)
  5. 보안 설정 (중요)
    • 기본 상태에서는 모든 요청을 허용하므로, 도메인 제한 또는 IP 제한을 꼭 걸어두는 것이 좋습니다.
    • 예: 웹 앱에서 쓰면 HTTP referer 제한, 서버에서 쓰면 IP 제한

📌 비용(무료 vs 유료)

  • 무료로 사용 가능합니다.
  • 다만 쿼터 제한이 있습니다:
    • 기본 제공: 하루 10,000 유닛 (무료)
    • 각 요청은 리소스에 따라 1~100 유닛 정도 소모
    • 예: channels.list 요청 = 1 유닛 → 하루 약 10,000번 호출 가능
  • 더 많은 쿼터가 필요하다면 유료로 Google Cloud Billing 연결해서 요청할 수 있습니다.
    (일반적인 개인/소규모 프로젝트는 무료 한도로 충분)

📌 정리

  • API Key는 Google Cloud Console → 프로젝트 생성 → YouTube Data API v3 활성화 → Credentials에서 발급
  • 비용: 기본적으로 무료 (10,000 유닛/일), 초과 사용 시 유료
  • 이 API Key를 이용하면 channels.list 요청으로 채널의 썸네일 이미지 URL을 자동으로 얻을 수 있음
반응형
반응형

맥북에서 Claude Code 작업 시 화면이 꺼지거나 잠들 때의 동작과 개발 환경 설정에 대해 자세히 알려드리겠습니다.

🔋 화면 꺼짐 vs 슬립 모드

화면만 꺼진 경우:

  • Claude Code 계속 실행됨
  • ✅ 네트워크 연결 유지
  • ✅ 작업 진행 계속됨

맥북이 슬립 모드로 들어간 경우:

  • Claude Code 일시 중단됨
  • ❌ 네트워크 연결 끊김
  • ❌ 작업 진행 중단

⚙️ 개발용 맥북 설정

1. 에너지 절약 설정

시스템 설정 → 배터리 → 전원 어댑터:

 
 
✅ 디스플레이 끄기: 10분 (원하는 시간)
❌ Mac 자동 잠자기 방지: 체크
✅ 전원이 연결되어 있을 때 잠자기 방지: 체크
✅ Wake for network access: 체크

터미널 명령어로 설정:

 
 
bash
# 전원 연결 시 절대 잠들지 않기
sudo pmset -c sleep 0

# 디스플레이만 10분 후 끄기
sudo pmset -c displaysleep 10

# 배터리 사용 시에도 설정 (선택사항)
sudo pmset -b sleep 30
sudo pmset -b displaysleep 5

# 현재 설정 확인
pmset -g

2. Caffeinate 명령어 사용

장시간 작업할 때:

 
 
bash
# 시스템 잠들지 않게 하기 (무제한)
caffeinate

# 특정 시간만 (3600초 = 1시간)
caffeinate -t 3600

# 디스플레이도 안 끄기
caffeinate -d

# Claude Code와 함께 실행
caffeinate claude

3. 터미널 세션 유지

tmux 사용 (권장):

 
 
bash
# tmux 설치
brew install tmux

# 새 세션 시작
tmux new-session -s claude-work

# Claude Code 실행
claude

# 세션에서 분리 (Ctrl+B, 그다음 D)
# 맥북 종료해도 세션 유지됨

# 나중에 다시 연결
tmux attach-session -t claude-work

screen 사용 (대안):

 
 
bash
# screen 세션 시작
screen -S claude-work

# Claude Code 실행
claude

# 분리: Ctrl+A, 그다음 D
# 재연결: screen -r claude-work

🛠 Claude Code 최적 설정

1. 자동 저장 설정

 
 
bash
# Claude Code에서 자동 저장 활성화
claude config set auto-save true

# 작업 상태 자동 저장 간격 설정
claude config set save-interval 60  # 60초마다

2. 알림 설정

 
 
bash
# 작업 완료 시 알림
claude config set notifications true

# 맥 알림 센터 사용
claude config set notification-type system

3. 긴 작업을 위한 설정

 
 
bash
# 타임아웃 시간 늘리기
claude config set timeout 3600  # 1시간

# 자동 재시도 설정
claude config set auto-retry true

📱 개발 환경 완전 설정

1. 기본 도구 설치

 
 
bash
# Homebrew가 없다면
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 개발 필수 도구들
brew install tmux tree htop git node

2. 터미널 환경 개선

 
 
bash
# ~/.zshrc 또는 ~/.bash_profile에 추가
echo 'alias ll="ls -la"' >> ~/.zshrc
echo 'alias claude-session="tmux new-session -s claude"' >> ~/.zshrc
echo 'alias claude-resume="tmux attach-session -t claude"' >> ~/.zshrc

# 설정 적용
source ~/.zshrc

3. 작업 공간 설정

 
 
bash
# 개발 전용 디렉토리 생성
mkdir -p ~/Development/claude-projects
cd ~/Development/claude-projects

# 각 프로젝트별 tmux 세션 관리 스크립트
cat > ~/start-claude.sh << 'EOF'
#!/bin/bash
PROJECT_NAME=${1:-default}
tmux new-session -d -s "claude-$PROJECT_NAME"
tmux send-keys -t "claude-$PROJECT_NAME" "cd ~/Development/claude-projects/$PROJECT_NAME" Enter
tmux send-keys -t "claude-$PROJECT_NAME" "claude" Enter
tmux attach-session -t "claude-$PROJECT_NAME"
EOF

chmod +x ~/start-claude.sh

🔔 작업 모니터링

1. 진행 상황 확인

 
 
bash
# 다른 터미널에서 작업 상황 모니터링
watch -n 30 'ps aux | grep claude'

# 네트워크 상태 확인
ping -c 1 api.anthropic.com

2. 로그 확인

 
 
bash
# Claude Code 로그 확인
tail -f ~/.claude/logs/claude.log

# 시스템 로그에서 네트워크 문제 확인
log stream --predicate 'subsystem contains "com.apple.network"'

🚨 비상 계획

1. 작업 복구

 
 
bash
# Claude Code 세션 복구
claude resume

# 이전 작업 상태 확인
claude status
claude history

2. 백업 및 복구

 
 
bash
# 작업 상태 정기 백업
crontab -e
# 매 시간마다 백업: 0 * * * * cp -r ~/.claude/sessions ~/Dropbox/claude-backup/

💡 추천 워크플로우

장시간 작업 시작 전:

 
 
bash
# 1. 전원 연결 확인
# 2. tmux 세션 시작
tmux new-session -s claude-work

# 3. Caffeinate 실행
caffeinate &

# 4. Claude Code 시작
claude

# 5. 작업 시작

작업 중단 시:

 
 
bash
# tmux 세션에서 분리
Ctrl+B, 그다음 D

# 나중에 재연결
tmux attach-session -t claude-work

이렇게 설정하면 맥북 화면이 꺼져도 Claude Code 작업이 안전하게 계속 진행됩니다! 특히 tmux나 screen을 사용하면 맥북을 완전히 종료해도 서버에서 작업이 계속 실행될 수 있어 매우 유용합니다.

반응형

+ Recent posts