devNote

[Docker] 실무에서 당장 써먹는 Docker Logs 핵심 명령어 5가지 요약

sddev — Thu, 2 Jul 2026 16:23:32 +0900

Docker 컨테이너를 운영하다 보면 "방금 찍힌 에러 로그가 뭐지?", "어제 새벽 3시에 무슨 일이 있었지?" 같은 상황을 직면하게 됩니다. 수백 만 줄의 로그 속에서 길을 잃지 않기 위해, 실무에서 가장 활용도가 높은 실용적인 명령어 패턴을 정리해 보았습니다. 이 5가지만 기억해도 로그 확인 시간이 절반으로 줄어듭니다.
1. 실시간 로그 모니터링: -f (Follow)
가장 기본적이면서도 가장 많이 쓰는 명령어입니다. 배포 직후 서버가 정상적으로 떴는지 확인하거나, 실시간으로 들어오는 요청을 모니터링할 때 사용합니다.

docker logs -f [컨테이너_이름]

Tip: 로그가 너무 빠르게 올라가서 멈추고 싶다면 Ctrl + C로 빠져나올 수 있습니다.

2. 최근 N줄만 깔끔하게 보기: --tail
컨테이너가 몇 달 동안 켜져 있었다면, docker logs를 그냥 쳤을 때 수 기가바이트(GB)의 과거 로그가 터미널을 덮어버려 렉이 걸릴 수 있습니다. 최근 쌓인 로그만 빠르게 확인하세요.

# 최근 100줄만 출력
docker logs --tail 100 [컨테이너_이름]

# 최근 50줄을 출력하면서, 앞으로 쌓일 로그도 실시간으로 보기 (가장 추천!)
docker logs -f --tail 50 [컨테이너_이름]

3. 특정 시간대 범인 찾기: --since & --until
"오늘 오후 3시 40분쯤에 API가 터졌다"는 제보를 받았다면, 특정 시간대만 타임머신을 타고 돌아가듯 격리해서 봐야 합니다.

# 날짜와 정확한 시간 지정 (YYYY-MM-DDTHH:MM:SS)
docker logs --since "2026-07-02T15:40:00" --until "2026-07-02T15:50:00" [컨테이너_이름]

# 인간 친화적인 상대 시간 지정 (30분 전부터 10분 전까지)
docker logs --since 30m --until 10m [컨테이너_이름]

m은 분(Minutes), h는 시간(Hours), d는 일(Days) 단위로 쓸 수 있어서 --since 3h 형태로도 자주 쓰입니다.

4. 로그에 강제로 시간표시 하기: -t (Timestamps)
컨테이너 내부 애플리케이션 프레임워크 설정을 잘못해서 로그에 "언제 이 로그가 찍혔는지" 시간이 나오지 않을 때가 있습니다. 이때 도커 엔진이 기억하는 타임스탬프를 강제로 주입할 수 있습니다.

docker logs -t [컨테이너_이름]

결과 비교:
• 기본: [INFO] Connection accepted.
• -t 적용: 2026-07-02T15:42:01.123456789Z [INFO] Connection accepted.

5. 에러 로그만 필터링하거나 검색하기: grep 조합
특정 키워드(예: Exception, Error, 404)가 포함된 로그만 골라내고 싶을 때 리눅스의 grep과 조합합니다. 여기서 핵심 포인트는 2>&1 리다이렉션입니다. 도커의 표준 에러(stderr)까지 파이프로 넘겨주어야 놓치는 로그가 없습니다.

# 'Exception'이 포함된 로그 검색
docker logs [컨테이너_이름] 2>&1 | grep "Exception"

# 실시간으로 들어오는 로그 중 'ERROR'라는 단어만 실시간 감시
docker logs -f [컨테이너_이름] 2>&1 | grep "ERROR"

한눈에 보는 요약 치트시트 (Cheat Sheet)

상황명령어 조합

방금 배포하고 잘 돌아가는지 볼 때	docker logs -f --tail 100 <name>
어제 하루 동안 쌓인 에러 확인할 때	docker logs --since 24h <name> 2>&1 \| grep "ERROR"
특정 장애 발생 시간 10분간을 분석할 때	docker logs --since "시간" --until "시간" -t <name>

[AI] Claude Code 실용적 활용 팁 9가지 (소스코드 분석 기반)

sddev — Thu, 2 Jul 2026 16:15:44 +0900

출처: unclejobs.ai (Threads) 요약: Claude Code 소스코드 분석을 통해 밝혀진, 단순 채팅을 넘어 '에이전트 오케스트레이션 플랫폼'으로 활용하기 위한 구체적인 설정 및 사용법.

1. CLAUDE.md는 매 턴마다 다시 읽힙니다.

세션 시작 시 한 번만 읽는 것이 아니라, 메시지를 보낼 때마다 다시 읽습니다. 이는 소스코드에서 확인된 동작으로, AI의 행동을 제어하는 가장 강력한 수단입니다.

4단계 계층 구조: 글로벌 (~/.claude/CLAUDE.md), 프로젝트 (./CLAUDE.md), 모듈별 규칙 (.claude/rules/*.md), 로컬 메모 (CLAUDE.local.md) 순으로 적용됩니다.
활용법: 아키텍처 결정, 파일 규칙, 테스트 패턴, "절대 하지 말아야 할" 규칙 등을 명시해두면 매번 AI의 판단에 반영됩니다.

2. 서브에이전트 5개를 돌려도 비용은 1개와 거의 같습니다.

서브에이전트를 생성(fork)하면 부모 컨텍스트의 바이트 단위 복사본을 만들고, API가 이 프롬프트를 캐시하기 때문에 비용이 거의 늘어나지 않습니다.

3가지 실행 모델:
- fork: 부모 컨텍스트를 상속하여 캐시 효율을 극대화합니다.
- teammate: 별도 터미널 패널(tmux/iTerm)에서 파일 기반 메일박스로 통신합니다.
- worktree: 독립된 git 워크트리로 에이전트별 브랜치를 격리하여 안전하게 작업합니다.
시사점: 보안 감사, 리팩토링, 테스트 작성, 문서 업데이트, 버그 수정을 동시에 병렬로 처리할 수 있는 구조가 이미 내장되어 있습니다.

3. 권한 팝업을 매번 클릭하는 것은 설정 실패입니다.

"이 작업을 허용할까요?" 팝업이 뜰 때마다 클릭하는 것은 정상적인 사용 경험이 아닙니다. settings.json에 glob 패턴으로 허용 범위를 미리 지정해두어야 합니다.

설정 예시: Bash(npm *), Bash(git *), Edit(src/**) 와 같이 허용할 명령어와 파일 범위를 명시할 수 있습니다.
Auto 모드: 새로 생긴 auto 모드는 LLM 분류기가 각 동작의 위험도를 판단하여 안전한 작업은 자동으로 승인해줍니다.

4. 5가지 컨텍스트 압축 전략을 이해하고 활용해야 합니다.

Anthropic 엔지니어들이 컨텍스트 초과 문제 해결에 많은 노력을 기울였다는 증거입니다. 자동 압축을 기다리기보다, 필요할 때 수동으로 개입하는 것이 중요합니다.

5가지 전략: microcompact(오래된 도구 결과 제거), context collapse(대화 구간 요약), session memory(핵심 맥락 파일 추출), full compact(전체 히스토리 요약), PTL truncation(가장 오래된 메시지 그룹 폐기)
핵심 조언: /compact 명령어를 게임의 '수동 세이브'처럼 사용하세요. 중요한 맥락이 날아가기 전에 보존하고 불필요한 내용은 정리할 수 있습니다.

5. Hook 시스템이 진짜 확장 API입니다.

PreToolUse(도구 실행 전), PostToolUse(실행 후), UserPromptSubmit(메시지 전송 시) 등 25개 이상의 라이프사이클 이벤트에 사용자 정의 로직을 연결할 수 있습니다.

UserPromptSubmit 훅: 메시지를 보낼 때마다 자동으로 테스트 결과나 최신 git diff를 컨텍스트에 첨부할 수 있어 매우 강력합니다.
5가지 훅 종류: command(쉘 명령), prompt(LLM 맥락 주입), agent(에이전트 검증), HTTP(웹훅), function(JS 실행)

6. 세션을 매번 새로 시작하지 마세요.

모든 대화는 JSONL 파일로 저장되며, 세션을 이어가면 session memory가 축적되어 AI가 더 똑똑하게 행동합니다.

세션 명령어:
- --continue: 마지막 세션을 이어서 시작합니다.
- --resume: 특정 세션을 골라서 다시 엽니다.
- --fork-session: 과거 대화의 특정 지점에서 새로운 브랜치를 만듭니다.
비유: 매번 새 세션을 여는 것은 IDE를 1시간마다 껐다 켜는 것과 같습니다.

7. 읽기는 병렬, 쓰기는 순차입니다.

Claude Code는 속도와 안정성을 모두 고려하여 도구를 실행합니다.

병렬 실행 (읽기): 파일 10개를 읽어야 하면 동시에 읽어 속도를 높입니다.
순차 실행 (쓰기): 파일 3개를 수정해야 하면 충돌 방지를 위해 하나씩 순서대로 처리합니다.

8. 중간에 끊는 것을 두려워하지 마세요.

전체 파이프라인이 비동기 제너레이터 방식으로 동작하므로, Esc 키를 누르면 현재 스트리밍만 깔끔하게 중단되고 이전 맥락은 그대로 보존됩니다.

시사점: AI가 잘못된 방향으로 가고 있다면, 끝까지 기다리지 말고 즉시 중단하고 방향을 바로잡아주는 것이 효율적입니다.

9. 결론: 설정하고, 병렬로 돌리고, 세션을 이어가세요.

Claude Code를 잘 쓰는 것은 프롬프트 엔지니어링의 영역이 아닙니다. 소스코드 분석 결과, 이 도구는 단순한 터미널 채팅이 아니라 **'에이전트 오케스트레이션 플랫폼'**에 가깝습니다.

핵심: 설정을 통해 권한을 자동화하고, Hook으로 필요한 정보를 주입하며, 병렬 에이전트로 작업을 동시에 처리하고, 세션을 이어가며 컨텍스트를 축적하는 것이 핵심입니다.

[AI] Claude Code 실용적 활용 팁 9가지 (소스코드 분석 기반)

sddev — Wed, 1 Jul 2026 16:10:46 +0900

출처: unclejobs.ai (Threads) 요약: Claude Code 소스코드 분석을 통해 밝혀진, 단순 채팅을 넘어 '에이전트 오케스트레이션 플랫폼'으로 활용하기 위한 구체적인 설정 및 사용법.

1. CLAUDE.md는 매 턴마다 다시 읽힙니다.

4단계 계층 구조: 글로벌 (~/.claude/CLAUDE.md), 프로젝트 (./CLAUDE.md), 모듈별 규칙 (.claude/rules/*.md), 로컬 메모 (CLAUDE.local.md) 순으로 적용됩니다.
활용법: 아키텍처 결정, 파일 규칙, 테스트 패턴, "절대 하지 말아야 할" 규칙 등을 명시해두면 매번 AI의 판단에 반영됩니다.

2. 서브에이전트 5개를 돌려도 비용은 1개와 거의 같습니다.

서브에이전트를 생성(fork)하면 부모 컨텍스트의 바이트 단위 복사본을 만들고, API가 이 프롬프트를 캐시하기 때문에 비용이 거의 늘어나지 않습니다.

3가지 실행 모델:
- fork: 부모 컨텍스트를 상속하여 캐시 효율을 극대화합니다.
- teammate: 별도 터미널 패널(tmux/iTerm)에서 파일 기반 메일박스로 통신합니다.
- worktree: 독립된 git 워크트리로 에이전트별 브랜치를 격리하여 안전하게 작업합니다.
시사점: 보안 감사, 리팩토링, 테스트 작성, 문서 업데이트, 버그 수정을 동시에 병렬로 처리할 수 있는 구조가 이미 내장되어 있습니다.

3. 권한 팝업을 매번 클릭하는 것은 설정 실패입니다.

설정 예시: Bash(npm *), Bash(git *), Edit(src/**) 와 같이 허용할 명령어와 파일 범위를 명시할 수 있습니다.
Auto 모드: 새로 생긴 auto 모드는 LLM 분류기가 각 동작의 위험도를 판단하여 안전한 작업은 자동으로 승인해줍니다.

4. 5가지 컨텍스트 압축 전략을 이해하고 활용해야 합니다.

5가지 전략: microcompact(오래된 도구 결과 제거), context collapse(대화 구간 요약), session memory(핵심 맥락 파일 추출), full compact(전체 히스토리 요약), PTL truncation(가장 오래된 메시지 그룹 폐기)
핵심 조언: /compact 명령어를 게임의 '수동 세이브'처럼 사용하세요. 중요한 맥락이 날아가기 전에 보존하고 불필요한 내용은 정리할 수 있습니다.

5. Hook 시스템이 진짜 확장 API입니다.

UserPromptSubmit 훅: 메시지를 보낼 때마다 자동으로 테스트 결과나 최신 git diff를 컨텍스트에 첨부할 수 있어 매우 강력합니다.
5가지 훅 종류: command(쉘 명령), prompt(LLM 맥락 주입), agent(에이전트 검증), HTTP(웹훅), function(JS 실행)

6. 세션을 매번 새로 시작하지 마세요.

모든 대화는 JSONL 파일로 저장되며, 세션을 이어가면 session memory가 축적되어 AI가 더 똑똑하게 행동합니다.

세션 명령어:
- --continue: 마지막 세션을 이어서 시작합니다.
- --resume: 특정 세션을 골라서 다시 엽니다.
- --fork-session: 과거 대화의 특정 지점에서 새로운 브랜치를 만듭니다.
비유: 매번 새 세션을 여는 것은 IDE를 1시간마다 껐다 켜는 것과 같습니다.

7. 읽기는 병렬, 쓰기는 순차입니다.

Claude Code는 속도와 안정성을 모두 고려하여 도구를 실행합니다.

병렬 실행 (읽기): 파일 10개를 읽어야 하면 동시에 읽어 속도를 높입니다.
순차 실행 (쓰기): 파일 3개를 수정해야 하면 충돌 방지를 위해 하나씩 순서대로 처리합니다.

8. 중간에 끊는 것을 두려워하지 마세요.

전체 파이프라인이 비동기 제너레이터 방식으로 동작하므로, Esc 키를 누르면 현재 스트리밍만 깔끔하게 중단되고 이전 맥락은 그대로 보존됩니다.

시사점: AI가 잘못된 방향으로 가고 있다면, 끝까지 기다리지 말고 즉시 중단하고 방향을 바로잡아주는 것이 효율적입니다.

9. 결론: 설정하고, 병렬로 돌리고, 세션을 이어가세요.

핵심: 설정을 통해 권한을 자동화하고, Hook으로 필요한 정보를 주입하며, 병렬 에이전트로 작업을 동시에 처리하고, 세션을 이어가며 컨텍스트를 축적하는 것이 핵심입니다.

[개발자 도구] 새 창/팝업 뜰 때 개발자 도구(F12) 자동으로 열고 네트워크 로그 잡는 방법

sddev — Thu, 25 Jun 2026 11:24:27 +0900

웹 개발을 하거나 API 테스트를 하다 보면, 버튼을 눌렀을 때 새 창(팝업)이나 새 탭이 열리면서 데이터가 넘어가는 과정을 확인해야 할 때가 많습니다.
하지만 새 창이 뜨는 속도가 너무 빨라 뒤늦게 F12를 누르면 이미 초기 네트워크 로그(Network Log)는 날아가고 없는 경우가 허다하죠. ‍
오늘은 마이크로소프트 엣지(Edge) 브라우저에서 부모 창의 개발자 도구를 켜두면 새 창이 열릴 때 개발자 도구도 자동으로 함께 켜지게 만드는 전역 설정 방법을 소개해 드립니다. 이 방법을 쓰면 첫 요청부터 완벽하게 로그를 보존할 수 있습니다!
️ Edge 새 창 뜰 때 개발자 도구 자동 연결하기 (30초 컷)
방법은 아주 간단합니다. 부모 창(원래 창)에서 옵션 하나만 켜두면 됩니다.
1단계: 개발자 도구 설정 진입

현재 띄워져 있는 메인 브라우저 창에서 F12 키를 눌러 개발자 도구를 엽니다.
개발자 도구 창 우측 상단에 있는 **톱니바퀴 아이콘(설정 / Settings)**을 클릭합니다.
(톱니바퀴가 안 보인다면 F1 키를 눌러도 바로 설정 화면으로 이동합니다.)

2단계: 자동 열기 옵션 체크

설정 왼쪽 메뉴에서 Preferences (기본 설정) 탭을 선택합니다.
스크롤을 아주 조금만 아래로 내려 Global (전역) 섹션을 찾습니다.
항목 중 Auto-open DevTools for popups (팝업에 대해 자동으로 개발자 도구 열기) 찾아 체크박스에 체크(V)합니다.

설정 끝! 이제 설정 창을 닫고 테스트를 해보시면 됩니다.
완벽한 로그 보존을 위한 마지막 한 걸음 (강력 추천)
만약 새 창이 열리자마자 다른 주소로 **순식간에 리다이렉트(화면 전환)**가 일어나는 페이지라면, 자동 열기 설정만으로는 첫 로그가 덮어씌워져 안 보일 수 있습니다.
이를 방지하기 위해 새 창이 열렸을 때 다음 설정까지 함께 켜주면 완벽합니다.

자동으로 열린 새 창의 개발자 도구에서 Network (네트워크) 탭으로 이동합니다.
상단 메뉴 바에서 Preserve log (로그 보존) 체크박스에 체크합니다.
(아이콘 모드일 경우, 깔대기 모양 옆에 화살표가 둥글게 감싸고 있는 모양입니다.)

이 Preserve log 기능까지 활성화해 두면, 페이지가 새로고침되거나 다른 URL로 넘어가도 이전 단계의 네트워크 요청 기록이 지워지지 않고 차곡차곡 누적됩니다.
✍️ 요약 및 정리

문제: 새 창이 뜨면 개발자 도구를 켜기도 전에 초기 네트워크 로그가 유실됨.
해결: F12 > 설정(F1) > 기본 설정 > Auto-open DevTools for popups 체크!
한 줄 팁: 리다이렉트가 심한 사이트라면 네트워크 탭의 **Preserve log**까지 켜둘 것!

이제 새 팝업창이 뜰 때마다 허둥지둥 F12 누르지 마시고, 이 전역 옵션 하나로 편안하게 디버깅하세요! 도움이 되셨다면 공감과 댓글 부탁드립니다.

[AI] 프롬프트 캐싱, 서킷 브레이커, 그리고 Ralph Loop 한눈에 이해하기

sddev — Tue, 23 Jun 2026 14:49:08 +0900

1. 프롬프트 캐싱 (Prompt Caching)
개념: 고정된 컨텍스트(API 문서, 시스템 가이드, 긴 코드베이스 등)의 연산 비용과 응답 시간을 아끼기 위해 메모리에 적재해두는 기술입니다.
의사코드 구현 모델
개발자가 매번 긴 시스템 지침을 모델에 전달하는 대신, 백엔드나 프레임워크 단에서 내부적으로 매칭되는 해시(Hash)가 있는지 확인하고 이를 재사용하는 논리 구조입니다.

-> LLM.compute_with_cached_state 핵심이다.(캐시 key값을 같이 넘겨준다. 나머지는 변경된 user_query만)

import hashlib

class PromptCacheManager:
    def __init__(self):
        # 실제 환경에서는 Redis나 클라우드 제공업체의 내장 KV Cache 메모리 레이어입니다.
        self.cache_storage = {}

    def get_completion(self, system_instruction, user_prompt):
        # 1. 고정된 대형 프롬프트의 해시값을 생성
        instruction_hash = hashlib.sha256(system_instruction.encode()).hexdigest()
        
        # 2. 캐시 스토리지 확인 (Hit or Miss)
        if instruction_hash in self.cache_storage:
            print("✨ Prompt Cache HIT! (비용 절감, 빠른 응답)")
            cached_tokens_state = self.cache_storage[instruction_hash]
            # 이미 계산된 KV Cache 상태를 모델에 전달하여 user_prompt만 이어서 연산
            response = LLM.compute_with_cached_state(cached_tokens_state, user_prompt)
        else:
            print("  Prompt Cache MISS. (전체 연산 후 캐싱 진행)")
            # 처음부터 전체 연산 수행
            cached_tokens_state, response = LLM.compute_full(system_instruction, user_prompt)
            # 다음 요청을 위해 저장
            self.cache_storage[instruction_hash] = cached_tokens_state
            
        return response

2. 서킷 브레이커 (Circuit Breaker)
개념: 외부 API나 하위 서비스가 망가졌을 때 무한정 대기하거나 연쇄 장애를 일으키지 않고, 즉시 차단(Fail-Fast)했다가 정상화되면 다시 연결하는 패턴입니다.
의사코드 구현 모델
Closed, Open, Half-Open 상태를 상태 패턴(State Pattern)이나 조건문으로 관리하는 백엔드 단의 구현 형태입니다.

-> CircuitBreaker 기능(실패 횟수에 따른 비활성화, 일정 시간 이후에 정상화 검증, 정상화 후 활성화 상태로 복구)을 하는 구현체를 Agent가 사용하는 API, 도구 등에 적용하는 방식이다.

import time

class CircuitBreaker:
    def __init__(self, failure_threshold=3, recovery_time=10):
        self.state = "CLOSED"           # 초기 상태: 정상
        self.failure_count = 0          # 실패 횟수 카운트
        self.failure_threshold = failure_threshold # 차단 기준치
        self.recovery_time = recovery_time         # 격리 시간(초)
        self.last_state_changed = time.time()

    def call_external_api(self, request_data):
        current_time = time.time()

        # 1. OPEN 상태일 때: 격리 시간이 지났으면 테스트 모드(HALF-OPEN)로 전환
        if self.state == "OPEN":
            if current_time - self.last_state_changed > self.recovery_time:
                self.state = "HALF-OPEN"
                print("⚡ [HALF-OPEN] 서비스 회복 여부를 확인하기 위해 요청을 하나 흘려보냅니다.")
            else:
                # 격리 기간 중에는 바로 에러를 뱉거나 대체 데이터(Fallback)를 리턴 (Fail-Fast)
                return "Fallback Data: 외부 서버 장애로 임시 데이터를 반환합니다."

        # 2. 실제 API 호출 시도
        try:
            response = ExternalService.request(request_data)
            
            # 호출 성공 시 처리
            if self.state == "HALF-OPEN":
                print("  [CLOSED] 서비스가 정상 복구되었습니다! 서킷을 닫습니다.")
                self.state = "CLOSED"
                self.failure_count = 0
            return response

        except Exception as e:
            # 호출 실패 시 처리
            self.failure_count += 1
            print(f"❌ 호출 실패 (누적: {self.failure_count}/{self.failure_threshold})")

            if self.failure_count >= self.failure_threshold or self.state == "HALF-OPEN":
                self.state = "OPEN"
                self.last_state_changed = time.time()
                print("  [OPEN] 장애율 초과! 서킷이 열렸습니다. 외부 호출을 차단합니다.")
                
            return "Fallback Data: 서비스 장애 감지로 우회 처리되었습니다."

3. Ralph Loop (Agent Harness Engineering)
개념: 코딩 에이전트(Claude Code, Cursor CLI 등)가 긴 작업을 할 때 대화가 길어질수록 환각(Hallucination)이 심해지고 성능이 떨어지는 문제를 해결하기 위한 루프입니다. **매 반복마다 컨텍스트 창을 완전히 초기화(Fresh Context)**하되, 파일 시스템(TODO 파일, Git 커밋)을 영속성 메모리로 활용하여 끈질기게 작업을 완수하게 만듭니다.

-> 모든 것을 LLM에 던지는 것이 아니라, 여러 영속적 메모리를 활용하여, 그 때 그 때 필요한 항목들만 조회해와서 LLM에 context로 넘기면서 단계적으로 수행하여 전체 작업을 성공적으로 수행해내는 방식

-> 한번에 모든 할일을 LLM에 context로 다 넘기고 작업을 수행하게 할 수도 있지만, 정확도가 떨어진다. 먼저 task 단위로 여러개를 나누고, task와 관련된 내용들을 파일로 만들고, task들을 순회하면서 새로운 LLM context에서 개별 작업들을 통해, 원하는 전체작업을 완성도 있게 수행해나가는 방식이다.

의사코드 구현 모델
주로 에이전트를 감싸고 실행하는 인프라/스크립트(Harness)단인 **Shell Script(Bash)**나 이를 오케스트레이션하는 도구 형태로 구현됩니다.

#!/bin/bash
# ralph-loop.sh: 자율 코딩 에이전트를 실행하는 하네스(Harness) 스크립트

MAX_ITERATIONS=10
ITERATION=1
COMPLETED=false

echo "  Ralph Loop를 시작합니다. 목표: 모든 개발 태스크 완료"

# 루프가 돌 때마다 에이전트는 완전히 '새 프로세스'로 실행되어 대화 히스토리(컨텍스트 오염)가 초기화됩니다.
while [ $ITERATION -le $MAX_ITERATIONS ] && [ "$COMPLETED" = false ]
do
    echo "--------------------------------------------------"
    echo "  Iteration $ITERATION/$MAX_ITERATIONS - Fresh Context로 에이전트 구동"
    echo "--------------------------------------------------"

    # 1. 파일 시스템에 적힌 현재 할 일(Task) 확인하기
    CURRENT_TASK=$(node -e "
        const tasks = require('./.agent/tasks.json');
        const next = tasks.find(t => t.status === 'PENDING');
        console.log(next ? next.id : 'NONE');
    ")

    if [ "$CURRENT_TASK" = "NONE" ]; then
        echo "  모든 태스크가 성공적으로 끝났습니다!"
        COMPLETED=true
        break
    fi

    # 2. AI 에이전트를 완전 독립된 세션으로 실행 (Harness 가 프롬프트를 주입)
    # 에이전트는 이 실행 파일 안에서 코드를 수정하고 테스트를 돌립니다.
    claude-code --non-interactive --prompt "
        너는 지금 Ralph Loop 모드로 작동 중이야. 
        ./.agent/tasks/TASK-${CURRENT_TASK}.json 에 적힌 요구사항을 구현해줘.
        작업이 끝나면 반드시 'npm test'를 돌려 검증하고, 
        성공하면 해당 태스크 상태를 'COMPLETED'로 바꾸고 종료해.
    "

    # 3. 에이전트가 종료된 후, 하네스(Harness) 단에서 자동 검증 및 Git 커밋
    if npm run test:critical; then
        echo "✅ 검증 성공: Git 커밋을 생성하고 다음 태스크로 넘어갑니다."
        git add .
        git commit -m "feat(agent): completed task $CURRENT_TASK"
    else
        echo "⚠️ 검증 실패: 코드가 깨졌습니다. 다음 루프에서 에이전트가 이어서 디버깅하도록 컨텍스트를 유지합니다."
        # 실패 정보를 다음 루프의 에이전트가 읽을 수 있게 파일로 기록
        echo "Test failed on task $CURRENT_TASK" > ./.agent/error_log.txt
    fi

    ITERATION=$((ITERATION + 1))
done

if [ "$COMPLETED" = false ]; then
    echo "  지정된 최대 반복 횟수에 도달하여 루프를 안전하게 탈출합니다."
fi

한눈에 정리하는 아키텍처적 차이점

프롬프트 캐싱은 LLM 엔진 내부에서 똑같은 입력을 빠르게 처리하기 위한 '성능 최적화 스크립트'입니다.
서킷 브레이커는 백엔드 인프라에서 불완전한 외부 시스템으로부터 내 앱을 보호하는 '방어벽 인터셉터'입니다.
Ralph Loop는 **에이전트 실행 환경(Harness)**에서 LLM의 기억력 한계를 극복하고 장기적인 자동화를 가능케 하는 '무한 궤도 오케스트레이터'입니다.

[SSO] Single Sign On의 본질: 한 번 로그인으로 여러 시스템에 접근하기

sddev — Mon, 22 Jun 2026 16:52:09 +0900

엔터프라이즈 환경에서 SSO가 왜 다양한 형태로 구현되는지, 그리고 “표준 OIDC”와 “포털 연동형 SSO”의 차이를 이해하기 위한 핵심 정리

1. SSO란 무엇인가

SSO(Single Sign-On) 는 사용자가 한 번 인증하면, 연결된 여러 애플리케이션에 다시 로그인하지 않고 접근할 수 있게 하는 방식이다.

핵심은 두 가지다.

개념설명

인증(Authentication)	“이 사람이 누구인가?” — 신원 확인
인가(Authorization)	“이 사람이 무엇을 할 수 있는가?” — 권한 부여

SSO는 인증을 중앙(또는 게이트웨이)에 맡기고, 각 앱은 그 결과를 받아 자체 세션·토큰을 만드는 구조가 일반적이다.

[사용자] → [SSO / IdP / 게이트웨이] → 인증 완료
                ↓
         [앱 A, 앱 B, 앱 C] ← 각자 세션/토큰 발급

2. SSO를 구현하는 네 가지 대표 패턴

실무에서 자주 만나는 방식만 골라 정리한다.

2.1 OIDC / OAuth2 (클라우드·SaaS의 표준)

가장 널리 쓰이는 현대적 방식.

사용자 → IdP 로그인 페이지
     → redirect (?code=...)
     → 앱이 code를 access_token으로 교환
     → JWT(id_token) 서명 검증 후 로그인 완료

장점단점

표준 스펙, 라이브러리 풍부	IdP 등록·설정 필요
토큰 검증·만료·갱신이 명확	레거시 포털과 직접 연동 어려움

대표 IdP: Azure AD, Okta, Google, Keycloak

2.2 SAML 2.0 (대기업 레거시)

XML 기반 Assertion을 IdP가 앱( SP )으로 POST한다.

금융·대기업에서 여전히 많이 사용
OIDC보다 설정이 무겁고 XML 서명 검증이 필요
신규 프로젝트는 OIDC를 더 선호하는 추세

2.3 헤더 기반 SSO (Reverse Proxy / 게이트웨이 신뢰)

사용자는 SSO 게이트웨이 앞에서만 로그인하고, 게이트웨이가 인증된 요청에 HTTP 헤더를 붙여 앱으로 전달한다.

[사용자] → [SSO Gateway] → iv-user: hong.gildong
                        → [내부 앱]

특징

대표 헤더	iv-user, REMOTE_USER, X-Forwarded-User
전제 조건	앱은 게이트웨이 뒤에 있어야 하고, 헤더 위조를 막을 수 있어야 함
흔한 환경	사내망, IBM WebSEAL, SiteMinder 등

iv-user 는 IBM Tivoli / WebSEAL 계열에서 흔히 쓰이는 헤더 이름이다.

2.4 암호화 페이로드 + 포털 브릿지 (B2B·내부 포털 연동)

포털(예: 구매 시스템)이 공유 비밀키로 암호화한 사용자 정보를 앱에 넘긴다.

포털 → POST app1_user_info=AES(env|사번|user_id)
앱  → 복호화 → 사용자 식별 → 자체 토큰 발급

장점 단점

기존 포털 규격에 맞추기 쉬움	표준이 아니라 앱마다 포맷이 다름
IdP 없이 빠르게 연동 가능	키 관리·검증 로직을 앱이 직접 책임져야 함

3. 패턴 비교 한눈에

방식신뢰 근거흔한 환경표준성

OIDC/OAuth2	IdP 서명 JWT, code 교환	SaaS, 클라우드	★★★★★
SAML	XML Assertion 서명	대기업 레거시 IdP	★★★★☆
헤더 SSO	게이트웨이가 헤더 주입	사내망, WebSEAL	★★☆☆☆ (관례)
암호화 페이로드	공유키 복호화	내부 포털, B2B	★☆☆☆☆ (자체 규격)

“SSO = OIDC”가 아니다.
환경에 따라 위 방식이 단독으로 쓰이거나 조합된다.

4. 하이브리드 SSO: 현실에서 가장 흔한 형태

대기업 내부 연동에서는 아래가 자주 한 세트로 묶인다.

[포털] ── 암호화 페이로드(app1_user_info) ──→ [앱]
[게이트웨이] ── iv-user 헤더 ─────────────→ [앱]
[앱] ── 임시 토큰(session_id) ──────────→ [프론트]
[프론트] ── session_id 교환 ─────────────→ [앱] → access_token

왜 이렇게 복잡한가?

포털은 이미 자체 암호화 규격을 가지고 있다.
게이트웨이는 네트워크 경계에서 SSO를 처리한다.
앱은 브라우저에 바로 내부 토큰을 주지 않고, 1회용 브릿지 토큰으로 한 번 더 교환한다.

이것은 교과서 OIDC는 아니지만, 레거시 인프라 제약 안에서의 실무적 브릿지 패턴이다.

5. 2단계 토큰 교환이란

많은 포털 연동 SSO가 다음 두 단계를 거친다.

단계토큰역할수명

1	session_id (임시)	포털 → 프론트 브릿지	짧음 (Redis TTL)
2	access_token (정식)	API 호출·세션 유지	상대적으로 김

POST /sso (서버 간·리다이렉트)
  → session_id 발급
  → redirect: https://app/?session_id=xxx

GET 프론트
  → POST /auth/sso-login { session_id }
  → access_token 발급

왜 URL에 session_id를 쓰는가?
포털이 브라우저를 앱으로 보낼 때 가장 단순한 방법이 query string이기 때문이다.
대신 짧은 TTL, 1회 사용, HTTPS가 전제가 된다.

표준 OAuth의 authorization code와 역할은 비슷하지만, 스펙은 다르다.

6. 검증 로직을 이해하는 열쇠

하이브리드 SSO를 읽을 때 확인할 질문 세 가지.

Q1. 누를 신뢰하는가?

HTTP 헤더 (iv-user)
암호화 본문 (app1_user_info)
둘 다 있을 때 교차 검증하는가?

Q2. prod와 dev 규칙이 다른가?

prod: 헤더 필수
dev: 암호문만으로도 허용
특정 domain: prod에서도 헤더 생략 허용

→ 환경·도메인별 예외는 운영 요구에서 자주 생긴다.

Q3. 최종 세션은 어디에 저장되는가?

Redis (서버 세션)
HttpOnly Cookie
프론트 메모리 / localStorage (보안상 덜 권장)

7. 보안 체크리스트 (핵심만)

항목권장

전송	HTTPS 필수
임시 토큰	짧은 TTL, 가능하면 1회성
URL 토큰	히스토리·Referer 노출 인지
헤더 SSO	게이트웨이 뒤에서만 신뢰, 직접 인터넷 노출 금지
공유키	로그에 전체 노출 금지, 주기적 로테이션
prod 예외	domain 화이트리스트 등으로 최소화

8. “우리 앱 SSO”를 읽는 방법

코드나 흐름도를 볼 때 이 순서로 따라가면 된다.

진입점 — /sso, /callback, middleware 예외 분기?
입력 — 헤더? form body? query?
검증 — 복호화, 헤더 일치, env/domain 예외
브릿지 토큰 — session_id 생성·저장 위치
프론트 — URL에서 토큰 추출 → API 교환
최종 로그인 — access_token 발급, 사용자·역할 조회
이후 요청 — Bearer / Cookie로 인증

9. 정리

오해사실

SSO는 항상 OAuth다	OIDC가 표준이지만, 레거시·포털 연동은 다른 형태가 많다
헤더만 있으면 된다	게이트웨이 신뢰 + 네트워크 격리가 전제다
암호문만 있으면 된다	키 유출 시 위조 가능 — 헤더와 교차 검증이 안전하다
session_id in URL은 항상 위험하다	짧은 TTL·1회성이면 실무 타협으로 쓰이기도 한다

SSO의 본질은 “표준 프로토콜을 쓰느냐”가 아니라,

신원을 누가·어떤 근거로 확인했고, 앱이 그 결과를 어떻게 자기 세션으로 바꾸는가

를 이해하는 것이다.

클라우드 신규 서비스라면 OIDC를 우선 검토하고,
기존 포털·게이트웨이·App1 같은 내부 시스템과 붙는다면 하이브리드 브릿지가 현실적인 선택이 될 수 있다.

참고: 용어 정리

용어설명

IdP	Identity Provider — 신원을 증명해 주는 주체
SP	Service Provider — 서비스를 제공하는 앱
iv-user	IBM SSO 게이트웨이 등에서 쓰는 사용자 ID 헤더
app1_user_info	공유키로 암호화된 사용자 정보 페이로드 (프로젝트별 규격)
session_id	SSO 브릿지용 임시 토큰
access_token	API 인증용 정식 토큰

[SSL] 운영환경 HTTPS 적용기 : Nginx + Docker + 사내 와일드카드 인증서

sddev — Tue, 16 Jun 2026 11:12:10 +0900

AOF Frontend HTTPS 설정 가이드

이 문서는 AOF 프로젝트에서 Nginx frontend 컨테이너에 HTTPS를 적용하기 위해 수행한 작업을 정리한 참고 자료입니다.
인증서 발급부터 배포, CI/CD, 트러블슈팅까지 한 번에 파악할 수 있도록 구성했습니다.

1. 전체 아키텍처 한눈에 보기

핵심 원칙

원칙설명

SSL 종료 지점	frontend Nginx 컨테이너 (443)
Backend SSL	불필요 — Nginx 뒤에서 HTTP(8001/8002)로 프록시
인증서 저장	Git ❌ → 호스트 고정 경로 /data001/config/dev/ssl/
자동 전환	entrypoint.sh가 인증서 유무로 HTTP/HTTPS 설정 선택

2. 프로젝트에서 SSL이 처리되는 위치

2.1 관련 파일 맵

파일역할

cicd/container/entrypoint.sh	server.crt + server.key 존재 시 HTTPS 템플릿 적용
cicd/container/default.conf.ssl.template	80(HTTP) + 443(HTTPS) Nginx 설정
cicd/container/default.conf.template	인증서 없을 때 HTTP만
cicd/container/docker-compose-prd.yml	포트 80/443 노출, SSL 볼륨 마운트
cicd/container/ssl-setup/setup-ssl.sh	보안팀 원본 → server.crt/server.key 변환·배포
cicd/container/Dockerfile	Nginx 이미지 + 템플릿/entrypoint 포함

2.2 entrypoint 자동 전환

# cicd/container/entrypoint.sh (요약)
if [ -f /etc/nginx/ssl/server.crt ] && [ -f /etc/nginx/ssl/server.key ]; then
    # → default.conf.ssl.template 사용 (HTTP + HTTPS)
else
    # → default.conf.template 사용 (HTTP만)
fi

컨테이너 시작 시점에 판단하므로, 인증서만 배치하고 frontend를 재시작하면 HTTPS가 활성화됩니다. 이미지 재빌드는 필요 없습니다.

예외: default.conf.ssl.template 내용을 바꾼 경우(리다이렉트, HSTS 등)에는 frontend 이미지 재빌드가 필요합니다.

2.3 docker-compose 볼륨 마운트

# cicd/container/docker-compose-prd.yml
frontend:
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - /data001/config/dev/ssl:/etc/nginx/ssl:ro

컨테이너 내부 경로: /etc/nginx/ssl/server.crt, /etc/nginx/ssl/server.key
호스트 경로: /data001/config/dev/ssl/ (GitLab clone 경로와 무관)

Backend .env와 동일한 패턴으로, 비밀/인증서는 repo 밖 고정 경로에 둡니다.

3. 보안팀 인증서 파일 이해하기

고객사 등에서 받는 파일 구성 예시:

파일의미Nginx 배포에 사용

File_Wildcard.xxx.com_crt.crt	서버(리프) 인증서 (*.xxx.com)	✅ server.crt의 첫 번째 블록
KeyFile_Wildcard.xxx.com_crt.key	개인키 (암호화된 경우 password.txt 필요)	✅ server.key
ChainFile_ChainBundle.crt	중간 CA 체인	✅ server.crt에 이어 붙임
CA_GLOBALSIGN.crt	루트 CA	❌ 배포 불필요 (검증·참고용)
password.txt	개인키 복호화 비밀번호	❌ 배포 불필요 (작업 시에만 사용)

3.1 PEM 파일에 BEGIN CERTIFICATE가 여러 개?

정상입니다. 하나의 .crt에 서버 인증서 + 중간 CA가 함께 들어 있는 경우가 많습니다.

-----BEGIN CERTIFICATE-----   ← 1번: 서버(리프) 인증서
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----   ← 2번: 중간 CA
...
-----END CERTIFICATE-----

openssl x509 -in file.crt → 첫 번째 인증서만 읽음
Nginx ssl_certificate → 모든 PEM 블록 사용 (fullchain)

3.2 최종 산출물

Nginx가 기대하는 형태는 딱 2개입니다.

파일내용

server.crt	서버 인증서 + 중간 CA 체인 (fullchain PEM)
server.key	복호화된 개인키 (평문 PEM)

CA_GLOBALSIGN.crt(루트)는 Nginx 설정에 넣지 않습니다. 브라우저/OS에 내장된 루트 CA로 검증합니다.

4. setup-ssl.sh 워크플로우

4.1 디렉토리 구조

cicd/container/ssl-setup/
├── setup-ssl.sh                              ← 실행 스크립트 (Git 포함)
├── .gitignore                                ← *.crt, *.key, password.txt 제외
├── File_Wildcard.xxx.com_crt.crt      ← 보안팀 파일 (Git 제외)
├── ChainFile_ChainBundle.crt
├── CA_GLOBALSIGN.crt
├── KeyFile_Wildcard.xxx.com_crt.key
├── password.txt
└── .work/                                    ← 중간 산출물 (실패 시 디버깅용, 성공 시 삭제)

4.2 실행

# 1. 보안팀 파일 5개를 ssl-setup/ 에 복사
# 2. 스크립트 실행
./cicd/container/ssl-setup/setup-ssl.sh

# 3. frontend 재시작 (인증서 반영)
docker compose -f cicd/container/docker-compose-prd.yml restart frontend

4.3 스크립트가 하는 일

원본 파일 존재·크기(0바이트) 검사
password.txt로 암호화된 개인키 복호화 → server.key
서버 인증서 + 체인 번들 결합 → server.crt
인증서·키 쌍 일치(modulus) 및 체인 검증
/data001/config/dev/ssl/에 배포 (기존 파일 백업 후 교체)

4.4 상단 변수 (재활용 시 수정)

SERVER_CERT_FILE="File_Wildcard.xxx.com_crt.crt"
CHAIN_BUNDLE_FILE="ChainFile_ChainBundle.crt"
ROOT_CA_FILE="CA_GLOBALSIGN.crt"
PRIVATE_KEY_FILE="KeyFile_Wildcard.xxx.com_crt.key"
PASSWORD_FILE="password.txt"
SSL_DEPLOY_DIR="/data001/config/dev/ssl"

5. 트러블슈팅: 반드시 알아둘 PEM 이슈

5.1 파일 끝 줄바꿈 누락 (cat 합칠 때 PEM 깨짐)

보안팀에서 받은 .crt 끝에 \n(개행)이 없는 경우가 있습니다.

증상:

원본 File_Wildcard...crt 단독 → openssl x509 성공 ✅
합본 .work/server.crt → Could not read certificate ❌

원인: cat으로 체인을 붙일 때 마지막 base64 줄과 -----BEGIN CERTIFICATE-----가 한 줄에 붙음

...abc123-----BEGIN CERTIFICATE-----

해결: setup-ssl.sh의 append_pem_file이 합칠 때 끝 개행을 자동 보정합니다.

직접 확인:

tail -c 5 File_Wildcard.lgdisplay.com_crt.crt | xxd
# 끝이 0a (LF)가 아니면 개행 없음

5.2 빈 server.crt

원본 파일이 0바이트이거나 placeholder인 경우. 스크립트가 사전에 ! -s 검사로 차단합니다.

5.3 적용 확인

# 로그
docker logs frontend 2>&1 | head -5
# "SSL 인증서가 발견되었습니다. HTTPS 설정을 적용합니다."

# 컨테이너 내부
docker exec frontend ls -la /etc/nginx/ssl/
docker exec frontend nginx -t

# 연결 테스트
curl -vk https://<도메인>/
curl -I http://<도메인>/

6. GitLab Runner / CI/CD와의 관계

6.1 왜 Git에 인증서를 넣지 않는가

개인키 유출 위험
보안 정책 위반
GitLab Runner는 매 파이프라인마다 새 clone → clone 경로에 인증서를 두면 불안정

6.2 현재 CI/CD 구조 (요약)

prd 브랜치 push
  → GitLab Runner (shell executor)
  → docker compose build/up (호스트 Docker)
  → frontend 컨테이너 교체

.gitlab-ci.yml의 HOST_PROJECT_DIR 변환은 소스 clone 경로용이며, SSL은 /data001/config/dev/ssl 고정 경로를 사용합니다.

6.3 Backend와 동일한 패턴

종류호스트 경로Git

Backend .env	/data001/config/dev/.env.*	❌
SSL 인증서	/data001/config/dev/ssl/	❌
애플리케이션 코드	GitLab clone	✅

6.4 인증서 갱신 시

# 1. ssl-setup/ 에 새 원본 파일 배치
# 2. setup-ssl.sh 실행
# 3. frontend만 재시작 (CI/CD 불필요)
docker compose -f cicd/container/docker-compose-prd.yml restart frontend

7. HTTP / HTTPS 병행 정책

현재 default.conf.ssl.template은 HTTP(80)와 HTTPS(443)를 동시에 제공하고, 강제 리다이렉트는 하지 않습니다.

7.1 변경 내용

항목이전현재

80 포트	301 → https:// 리다이렉트	HTTP 서비스 제공 (template과 동일)
HSTS	활성화	주석 처리 (HTTP 병행과 충돌 방지)
443 포트	HTTPS 서비스	동일

리다이렉트/HSTS 설정은 템플릿에 주석으로 보존되어 있어, 나중에 HTTPS 강제 전환 시 주석 해제만 하면 됩니다.

7.2 HTTP vs HTTPS 블록 관계

default.conf.ssl.template
├── server { listen 80;  ... }  ← default.conf.template 과 동일
└── server { listen 443 ssl; ... + SSL 설정 }  ← 추가

인증서 없을 때(default.conf.template)의 HTTP 동작과, 인증서 있을 때의 HTTP 동작은 동일합니다. HTTPS가 추가되는 것뿐입니다.

7.3 애플리케이션 영향

항목영향

Frontend API (/management)	상대 경로 → 프로토콜 자동 맞춤, 재빌드 불필요
X-Forwarded-Proto	Nginx가 $scheme으로 전달 → backend가 HTTP/HTTPS 구분 가능
인증 쿠키	현재 secure=False → HTTP/HTTPS 모두 동작
보안	HTTP 구간은 평문 통신 — 사내 정책·노출 범위 확인 필요

8. 운영 체크리스트

최초 HTTPS 적용

보안팀 인증서 5개 파일을 ssl-setup/에 배치
./cicd/container/ssl-setup/setup-ssl.sh 실행·검증 통과
/data001/config/dev/ssl/server.crt, server.key 존재 확인
default.conf.ssl.template 변경 사항 반영 시 frontend 재빌드
docker compose restart frontend 또는 CI/CD 배포
docker logs frontend에서 HTTPS 적용 메시지 확인
curl -vk https://<도메인>/ 및 curl -I http://<도메인>/ 테스트
방화벽/LB에서 80, 443 포트 개방 확인

인증서 갱신

ssl-setup/에 새 원본 파일 교체
setup-ssl.sh 재실행 (기존 인증서 자동 백업)
frontend 재시작

HTTPS 강제 전환 시 (향후)

default.conf.ssl.template에서 80 포트 리다이렉트 블록 주석 해제
HTTP 서비스 블록 주석 처리 (선택)
HSTS 주석 해제 검토
backend 쿠키 secure=True 검토
frontend 재빌드·배포

9. 자주 묻는 질문 (FAQ)

Q. ssl/ (프로젝트 루트)와 cicd/container/ssl-setup/ 차이는?
A. ssl/은 xxx 사내 CA 등 빌드용 참고 자료. 운영 HTTPS 배포는 ssl-setup/ + /data001/config/dev/ssl/을 사용합니다.

Q. 와일드카드 *.xxx.com이면 어떤 도메인까지 되나?
A. 1단계 서브도메인 (aof.xxx.com) ✅. 2단계 (x.aof.xxx.com)는 와일드카드로 커버되지 않을 수 있음.

Q. 인증서 변경만 했는데 frontend 재빌드가 필요한가?
A. 아니요. 볼륨 마운트이므로 재시작만 하면 됩니다. Nginx 템플릿을 수정한 경우에만 재빌드가 필요합니다.

Q. server_name localhost는 문제 없나?
A. 실제 도메인 접속 시 리다이렉트 URL에 영향을 줄 수 있습니다. HTTPS 강제 리다이렉트를 켤 때는 운영 도메인으로 server_name 수정을 검토하세요. 현재는 리다이렉트를 사용하지 않으므로 영향이 적습니다.

Q. .gitignore를 폴더마다 둬도 되나?
A. 네. ssl-setup/.gitignore는 해당 폴더의 인증서만 제외하고, 다른 경로의 .crt(예: ssl/xxx_CA_v3.crt)에는 영향을 주지 않습니다.

10. 참고: OpenSSL 명령어 모음

# 인증서 정보
openssl x509 -in server.crt -noout -subject -dates

# 개인키 검증
openssl rsa -in server.key -check -noout

# 인증서·키 쌍 일치 (MD5 해시가 같아야 함)
openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5

# 체인 검증
openssl verify -CAfile CA_GLOBALSIGN.crt \
  -untrusted ChainFile_ChainBundle.crt \
  File_Wildcard.xxx.com_crt.crt

# 암호화된 키 복호화
openssl rsa -in KeyFile_Wildcard.xxx.com_crt.key \
  -out server.key -passin file:password.txt

# fullchain 수동 생성 (스크립트 없이)
cat File_Wildcard.xxx.com_crt.crt ChainFile_ChainBundle.crt > server.crt
# ⚠️ 파일 끝 개행 없으면 빈 줄 삽입 필요

[AI] AI 디자인의 한계, 'DESIGN.md' 파일 2,000개로 돌파하기 (ft. Refero Styles)

sddev — Wed, 27 May 2026 14:12:03 +0900

안녕하세요! 오늘은 AI를 활용해 디자인을 하시는 분들에게 그야말로 '보물창고'가 될 만한 소식을 가져왔습니다.
AI에게 디자인을 맡기면 어딘가 모르게 뻔하고, 결과물이 비슷비슷해서 아쉬웠던 적 없으신가요? 이제 세계적인 수준의 디자인 데이터를 직접 AI에게 학습시켜 보세요.

AI 디자인의 치트키, DESIGN.md
해외 디자인 씬에서 화제가 되고 있는 세계 최고 제품 2,000개의 디자인 데이터가 담긴 .md 파일들을 소개합니다. 이 파일들은 단순한 이미지 모음이 아닙니다. AI가 즉시 이해하고 적용할 수 있는 디자인 명세서에 가깝습니다.

포함된 핵심 요소: 색상(Color), 타이포그래피(Typography), 간격(Spacing), 레이아웃(Layout) 등
활용 방법: 해당 .md 파일을 AI(Claude, ChatGPT 등)에게 업로드하거나 텍스트를 복사해 넘겨주기만 하면 됩니다.

"AI로 뻔하게 디자인하지 마세요"
범용적인 데이터만 학습한 AI는 평범한 결과물만 내놓습니다. 하지만 애플, 에어비앤비 같은 글로벌 제품들의 디자인 가이드가 담긴 데이터를 참고한다면 이야기가 달라집니다.
세계적인 수준의 디자인 감각을 내 작업물에 이식해 보세요. 단순히 따라 하는 것을 넘어, 이 데이터들을 조합해 나만의 독창적인 DESIGN.md를 구축하는 것이 핵심입니다.

참고 링크
아래 사이트에서 전 세계 디자인 트렌드와 핵심 요소들을 확인하고 직접 활용해 보실 수 있습니다.
Refero Styles 바로가기

한 줄 요약
"AI에게 '예쁘게 해줘'라고 말하는 대신, 세계 최고의 디자인 데이터를 건네주세요. 결과물의 디테일이 180도 달라집니다."
여러분의 프로젝트에 세계적인 디자인 감각을 더해 보시기 바랍니다!

[AI] AI가 과대해석하거나 자주 실수하는 부분을 잘 잡아주는 CLAUDE.md & .cursor

sddev — Wed, 27 May 2026 14:05:19 +0900

https://github.com/forrestchang/andrej-karpathy-skills/blob/main/CLAUDE.md

andrej-karpathy-skills/CLAUDE.md at main · multica-ai/andrej-karpathy-skills

A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls. - multica-ai/andrej-karpathy-skills

github.com

andrej-karpathy-skills/.cursor/rules/karpathy-guidelines.mdc at main · multica-ai/andrej-karpathy-skills · GitHub

andrej-karpathy-skills/.cursor/rules/karpathy-guidelines.mdc at main · multica-ai/andrej-karpathy-skills

A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls. - multica-ai/andrej-karpathy-skills

github.com

[AI] Claude Code 분석 모음

sddev — Thu, 21 May 2026 00:09:10 +0900

ai-study.zip

2.55MB