IT 방랑기

X-Frame-Options와 CSP frame-ancestors는 무엇이 다를까? 클릭재킹 방어 기준 정리

포도알77 — Fri, 15 May 2026 10:35:06 +0900

X-Frame-Options와 CSP frame-ancestors는 무엇이 다를까? 클릭재킹 방어 기준 정리

X-Frame-Options와 Content-Security-Policy: frame-ancestors는 다른 사이트가 내 페이지를 <iframe> 같은 프레임 안에 넣을 수 있는지 제어하는 HTTP 응답 헤더다. 2026년 5월 15일 기준 MDN과 OWASP 문서를 보면, 둘 다 클릭재킹 방어에 쓰이지만 표현력과 권장 용도가 다르다.

실무에서는 관리자 화면, 결제 화면, 설정 화면처럼 사용자가 로그인한 상태에서 중요한 동작을 수행하는 페이지가 특히 대상이 된다. 이 글은 공식 문서를 기준으로 두 헤더의 차이, 함께 넣어야 하는 경우, 그리고 자주 놓치는 설정 포인트를 객관적인 사실만 정리한다.

클릭재킹은 무엇이고 왜 프레임 제어가 필요할까?

클릭재킹은 공격자가 자기 페이지 위에 투명하거나 위장된 프레임을 올려 두고, 사용자가 실제로는 다른 사이트의 버튼이나 링크를 누르게 만드는 공격이다. MDN과 OWASP는 이런 상황을 막는 대표적인 방법으로 프레임 임베딩 제한과 SameSite 쿠키를 함께 언급한다.

즉 핵심은 내 문서가 어떤 상위 문서 안에서 렌더링될 수 있는지를 제한하는 것이다. 이 지점에서 X-Frame-Options와 frame-ancestors가 역할을 한다.

X-Frame-Options는 무엇을 할 수 있을까?

MDN 기준 X-Frame-Options는 문서의 프레임 임베딩 가능 여부를 제어하는 응답 헤더다. 값은 사실상 DENY와 SAMEORIGIN 두 가지로 보면 된다.

DENY: 어떤 출처에서도 이 문서를 프레임에 넣을 수 없다.
SAMEORIGIN: 모든 상위 프레임이 현재 문서와 같은 origin일 때만 임베딩할 수 있다.

ALLOW-FROM은 MDN이 obsolete로 설명하는 값이다. 현대 브라우저는 이 값을 만나면 헤더 전체를 무시할 수 있으므로, 허용 목록이 필요하면 frame-ancestors를 써야 한다.

CSP frame-ancestors는 무엇이 다를까?

frame-ancestors는 CSP의 navigation directive로, 어떤 부모 문서가 현재 페이지를 임베딩할 수 있는지 더 세밀하게 지정한다. MDN은 이 지시어가 <frame>, <iframe>, <object>, <embed>에 대한 부모를 제한한다고 설명한다.

frame-ancestors 'none': 어떤 부모도 허용하지 않는다.
frame-ancestors 'self': 같은 origin 부모만 허용한다.
frame-ancestors 'self' https://partner.example: 같은 origin과 특정 파트너 도메인 같은 여러 출처를 허용할 수 있다.

여기서 중요한 차이는 허용 대상을 여러 개 나열할 수 있다는 점이다. 사내 포털, 결제 파트너, 관리자 셸처럼 일부 외부 도메인만 임베딩을 허용해야 하는 경우에는 X-Frame-Options만으로 표현하기 어렵다.

둘의 핵심 차이는 무엇일까?

항목	X-Frame-Options	CSP frame-ancestors
표현력	`DENY`, `SAMEORIGIN` 중심	여러 허용 출처를 명시 가능
권장 위치	HTTP 응답 헤더	HTTP 응답 헤더
메타 태그 지원	지원하지 않음	지원하지 않음
기본값	없으면 임베딩 허용	없으면 임베딩 허용
세부 제어	낮음	높음

MDN은 frame-ancestors를 X-Frame-Options의 replacement로 설명한다. 동시에 브라우저가 frame-ancestors를 지원하면 같은 응답에 X-Frame-Options가 함께 있어도 X-Frame-Options는 무시된다고 적고 있다.

둘 다 같이 넣어야 할까?

MDN의 클릭재킹 가이드는 frame-ancestors와 X-Frame-Options를 함께 설정하면, frame-ancestors를 지원하지 않는 브라우저에서도 임베딩 차단 효과를 기대할 수 있다고 설명한다. 다만 최신 브라우저에서는 frame-ancestors 지원이 매우 좋기 때문에 주된 정책은 보통 이쪽에 둔다.

실무 기준으로 정리하면 다음과 같다.

임베딩을 완전히 막고 싶다면 frame-ancestors 'none'와 X-Frame-Options: DENY 조합이 가장 단순하다.
같은 사이트 내부에서만 임베딩이 필요하다면 frame-ancestors 'self'와 X-Frame-Options: SAMEORIGIN 조합이 대응된다.
특정 외부 파트너 도메인을 허용해야 한다면 실제 제어는 frame-ancestors로 하고, 필요 시 보조적으로 X-Frame-Options를 함께 둔다.

자주 놓치는 설정 포인트는 무엇일까?

1. 메타 태그로는 충분하지 않을까?

아니다. MDN과 OWASP는 둘 다 이 정책들을 HTTP 응답 헤더로 적용해야 한다고 설명한다. <meta http-equiv="X-Frame-Options">는 효과가 없고, frame-ancestors도 <meta> 요소에서 지원되지 않는다.

2. `default-src 'none'`만 있으면 프레임도 막힐까?

아니다. MDN은 frame-ancestors가 default-src의 fallback을 받지 않는다고 명시한다. 즉 default-src 'none'를 선언해도 frame-ancestors를 따로 쓰지 않으면 다른 사이트가 페이지를 임베딩할 수 있다.

3. 중첩 프레임에서도 한 번만 검사할까?

아니다. MDN은 frame-ancestors가 각 ancestor를 검사한다고 설명한다. 중첩 프레임 구조에서 상위 조상 중 하나라도 정책에 맞지 않으면 로드가 취소된다.

SameSite 쿠키는 왜 같이 언급될까?

OWASP와 MDN은 SameSite=Lax 또는 SameSite=Strict를 세션 쿠키에 적용하면, 다른 사이트의 <iframe> 안에서 요청이 발생할 때 세션 쿠키가 함께 가지 않도록 도와줄 수 있다고 설명한다. 이는 클릭재킹을 직접 막는 프레임 정책의 대체재는 아니지만, 로그인이 필요한 공격 시나리오를 약화시키는 방어층이 될 수 있다.

다만 이 속성만으로 모든 클릭재킹을 막을 수 있다는 뜻은 아니다. 공격이 인증 상태를 필요로 하지 않으면 보호 효과가 제한될 수 있다.

어떤 기준으로 선택하면 될까?

완전 차단이 목표면 frame-ancestors 'none'를 기준으로 설계하고, 호환성 보조용으로 X-Frame-Options: DENY를 함께 검토하면 된다.
같은 origin만 허용하면 충분한 일반 서비스라면 'self'와 SAMEORIGIN 조합이 가장 이해하기 쉽다.
여러 파트너나 서브도메인을 구체적으로 허용해야 하면 frame-ancestors가 사실상 필수다.
보안 헤더를 이미 강하게 설정했더라도 frame-ancestors를 별도로 선언했는지 확인해야 한다.

FAQ

Q. `X-Frame-Options`만 써도 충분할까?

완전 차단이나 same-origin 허용 정도라면 동작 자체는 가능하다. 다만 여러 허용 출처를 표현할 수 없고, MDN도 더 포괄적인 대안으로 frame-ancestors를 안내한다.

Q. 파트너 사이트 한 곳만 프레임 허용하려면 어떻게 해야 할까?

X-Frame-Options의 ALLOW-FROM은 현대 브라우저에서 사실상 쓸 수 없으므로, Content-Security-Policy: frame-ancestors 'self' https://partner.example처럼 허용 출처를 명시하는 방식이 맞다.

Q. iframe 안에 내가 불러오는 외부 페이지 출처 제어도 같은 설정일까?

아니다. MDN은 frame-ancestors가 누가 나를 감쌀 수 있는지 정하는 정책이고, frame-src는 내 페이지 안의 iframe이 어디에서 로드될 수 있는지 정하는 정책이라고 구분한다.

정리

2026년 5월 15일 기준 공식 문서를 기준으로 보면, 클릭재킹 방어의 주력 정책은 CSP frame-ancestors이고 X-Frame-Options는 더 단순한 구형 호환용 성격에 가깝다. 둘 다 응답 헤더로 보내야 하며, 메타 태그로는 대체되지 않는다.

중요한 페이지를 운영 중이라면 현재 응답에 frame-ancestors가 실제로 있는지, default-src만 믿고 있지는 않은지, 그리고 세션 쿠키의 SameSite 속성이 어떤 값인지 함께 점검하는 편이 안전하다.

참고 자료

[크롤링] 데이터 수집을 위한 크롤링 8편 : ETag와 If-None-Match로 변경된 페이지만 다시 받는 방법

포도알77 — Thu, 14 May 2026 12:13:20 +0900

[크롤링] 데이터 수집을 위한 크롤링 8편 : ETag와 If-None-Match로 변경된 페이지만 다시 받는 방법

크롤링에서 같은 URL을 반복 수집할 때 핵심은 두 가지다. 서버가 ETag 같은 검증자(validator)를 제공하는지, 그리고 클라이언트가 이전 응답의 ETag를 저장했다가 다음 요청에 If-None-Match로 다시 보내는지다. 이 조건이 맞으면 서버는 내용이 바뀌지 않았을 때 304 Not Modified를 돌려주고, 본문을 다시 전송하지 않아도 된다.

RFC 9110 기준으로 If-None-Match는 조건부 요청 헤더이고, GET이나 HEAD에서 조건이 실패하면 서버는 304 Not Modified로 응답해야 한다. 즉 크롤러 입장에서는 "다시 요청은 하되, 바뀌지 않았으면 바디는 받지 않는다"는 흐름을 표준 방식으로 구현할 수 있다.

왜 ETag를 먼저 봐야 할까?

ETag는 특정 시점의 리소스 표현(representation)을 식별하는 값이다. 리소스가 바뀌면 새로운 ETag가 생성돼야 하므로, 같은 URL이라도 현재 버전이 이전과 같은지 비교하는 기준으로 쓸 수 있다.

이 방식이 유용한 이유는 URL 자체만으로는 변경 여부를 알 수 없기 때문이다. 뉴스 본문, 상품 상세, 문서 페이지처럼 주소는 같지만 내용은 바뀔 수 있는 페이지에서는 ETag가 있으면 전체 HTML을 다시 내려받지 않고도 변경 여부를 판별할 수 있다.

If-None-Match는 어떻게 동작할까?

첫 요청에서는 평소처럼 리소스를 받고 응답 헤더의 ETag 값을 저장한다. 다음 요청부터는 같은 URL에 대해 If-None-Match 헤더에 그 값을 넣어 보낸다.

GET /resource HTTP/1.1
Host: example.com
If-None-Match: "abc123"

RFC 9110에 따르면 서버는 If-None-Match를 평가할 때 약한 비교(weak comparison)를 사용한다. 현재 리소스의 ETag가 요청 헤더에 들어온 값과 일치하면, GET과 HEAD에서는 요청 본문을 다시 보내지 않고 304 Not Modified로 응답해야 한다.

304 Not Modified를 받으면 무엇을 해야 할까?

304 Not Modified는 "변경이 없으니 기존에 저장한 표현을 계속 써도 된다"는 뜻이다. MDN과 RFC 설명 모두 이 응답에는 본문이 없어야 한다는 점을 분명히 한다.

따라서 크롤러는 304를 오류로 처리하면 안 된다. 보통은 이전에 저장해 둔 본문이나 파싱 결과를 유지하고, 마지막 확인 시각만 갱신하는 식으로 처리한다. 반대로 200 OK가 오면 새 본문과 새 ETag를 함께 저장해야 다음 요청에서도 조건부 요청을 이어갈 수 있다.

ETag가 있으면 항상 트래픽이 줄어들까?

대부분의 경우 줄어들지만, 전제는 있다. 서버가 실제로 ETag를 보내야 하고, 이후 요청에서 If-None-Match를 해석해 304를 돌려줘야 한다. 일부 사이트는 ETag를 아예 제공하지 않거나, 캐시 정책상 다른 검증자를 우선 사용할 수 있다.

또한 304는 바디 전송을 줄여 주는 것이지 요청 자체를 없애 주는 것은 아니다. 연결 수, 요청 빈도, robots 정책 준수는 여전히 별도의 문제다. 조건부 요청은 크롤링 예절을 대체하는 기능이 아니라 재수집 비용을 줄이는 표준 메커니즘으로 보는 편이 맞다.

If-Modified-Since와는 무엇이 다를까?

If-Modified-Since는 날짜 기반 검증자이고, If-None-Match는 ETag 기반 검증자다. RFC 9110은 두 헤더가 함께 있을 때 If-None-Match를 더 정확한 조건으로 보고, 수신자는 If-None-Match가 있으면 If-Modified-Since를 무시해야 한다고 정의한다.

즉 서버가 ETag를 제공한다면 보통은 ETag 기반 흐름이 더 우선이다. 날짜는 서버 시계 보정, 복원 시점, 초 단위 정밀도 문제 때문에 해석이 미묘해질 수 있지만, ETag는 표현 버전을 직접 식별하는 값이라 조건부 재수집에 더 적합한 경우가 많다.

크롤러에서는 어떤 흐름으로 구현하면 될까?

실무 흐름은 단순하다. 첫 수집 때 URL별로 본문과 ETag를 함께 저장하고, 다음 수집 때는 저장된 ETag가 있으면 If-None-Match를 넣어 요청한다. 응답이 304면 기존 데이터를 재사용하고, 200이면 본문과 ETag를 갱신한다.

이때 주의할 점은 ETag를 URL 단위로만 대충 공유하지 않는 것이다. 쿼리스트링, 언어, 인증 상태, 콘텐츠 협상에 따라 같은 경로라도 다른 표현이 나올 수 있다. 서버가 Vary 헤더를 보내는 경우에는 어떤 요청 헤더 조합이 다른 표현을 만들 수 있는지도 함께 봐야 한다.

약한 ETag와 강한 ETag는 어떻게 봐야 할까?

ETag는 W/ 접두사가 붙은 약한 ETag와 그렇지 않은 강한 ETag로 나뉜다. MDN 설명처럼 약한 ETag는 의미상 같은 표현을 판별하는 데는 쓸 수 있지만, 바이트 단위 동일성이 중요한 비교에는 덜 적합하다.

다만 If-None-Match는 원래 약한 비교를 사용하도록 정의돼 있다. 그래서 변경 감지 목적의 재수집에서는 약한 ETag도 충분히 유효할 수 있다. 반대로 부분 응답이나 바이트 단위 동일성이 중요한 경우에는 강한 검증자가 더 적합할 수 있다.

FAQ

모든 사이트가 ETag를 보내나?

아니다. ETag는 널리 쓰이지만 필수 헤더는 아니다. 서버가 ETag를 보내지 않으면 해당 URL에는 If-None-Match 기반 재검증을 적용할 수 없다.

304 응답에도 헤더는 올 수 있나?

그렇다. MDN과 RFC 설명 기준으로 304는 본문은 없어야 하지만, 캐시 갱신에 필요한 일부 헤더는 포함될 수 있다. 따라서 바디가 비었다고 해서 응답 헤더까지 무시하면 안 된다.

If-None-Match와 If-Modified-Since를 같이 보내도 되나?

보낼 수는 있지만, RFC 9110은 If-None-Match가 있을 때 If-Modified-Since를 무시해야 한다고 정의한다. 즉 실질적인 기준은 ETag 쪽이 된다.

정리

크롤링 재수집 비용을 줄이려면 기준은 명확하다. 응답의 ETag를 저장하고, 다음 요청에 If-None-Match를 보내고, 304면 기존 데이터를 재사용한다는 흐름을 지키면 된다. 이 방식은 임의 규칙이 아니라 RFC 9110에 정의된 조건부 요청 절차다.

서버가 ETag를 제공하지 않는다면 Last-Modified와 If-Modified-Since를 대안으로 볼 수 있지만, 둘 다 있을 때는 ETag 기반 검증이 우선이라는 점까지 함께 기억해 두는 편이 안전하다.

참고 자료

라즈베리파이에서 SPI를 어떻게 켤까? Bookworm 기준 활성화와 spidev 확인 방법

포도알77 — Wed, 13 May 2026 11:52:29 +0900

라즈베리파이에서 SPI를 어떻게 켤까? Bookworm 기준 활성화와 spidev 확인 방법

라즈베리파이에서 SPI 장치를 붙이기 시작할 때 가장 먼저 확인할 것은 두 가지다. Raspberry Pi OS Bookworm 이후에는 부트 설정 파일 경로가 주로 /boot/firmware/config.txt이고, SPI0는 기본적으로 비활성화되어 있어 직접 켜야 한다는 점이다.

공식 문서 기준으로 SPI를 켜는 방법은 raspi-config를 쓰거나, config.txt에 dtparam=spi=on을 설정하는 방식이다. 설정 후 재부팅하면 커널이 SPI 인터페이스를 로드하고, 필요한 경우 /dev/spidev0.0, /dev/spidev0.1 같은 장치 노드를 확인할 수 있다.

왜 먼저 경로부터 확인해야 할까?

라즈베리파이 공식 문서는 Bookworm 이전에는 부트 파티션을 주로 /boot/에서 다뤘지만, Bookworm 이후에는 /boot/firmware/를 기준으로 설명한다. 예전 글을 보고 /boot/config.txt만 찾다가 설정 위치를 잘못 잡는 경우가 가장 흔한 실수다.

따라서 지금 Raspberry Pi OS를 새로 설치했거나 Bookworm 계열을 쓰고 있다면, SPI 관련 설정은 먼저 /boot/firmware/config.txt 기준으로 보는 편이 안전하다.

SPI를 켜면 실제로 무엇이 바뀔까?

라즈베리파이 문서에 따르면 SPI 활성화는 두 가지 의미를 갖는다. SPI 인터페이스를 켜고, 부팅 시 SPI 커널 모듈이 자동으로 로드되게 한다는 뜻이다. 즉 단순히 설정 파일 한 줄을 추가하는 문제가 아니라, 운영체제가 해당 버스를 사용할 준비를 하게 만드는 과정에 가깝다.

공식 문서는 SPI0가 기본적으로 비활성화되어 있으며, 활성화하려면 raspi-config를 사용하거나 /boot/firmware/config.txt에 dtparam=spi=on이 주석 처리되지 않은 상태여야 한다고 설명한다.

가장 단순한 활성화 방법

터미널에서 대화형 설정을 쓸 수 있다면 sudo raspi-config가 가장 단순하다. 비대화형 문서 기준으로는 다음 명령도 제공된다.

sudo raspi-config nonint do_spi 0

라즈베리파이 설정 도구 문서에서 do_spi 0은 SPI 활성화, do_spi 1은 비활성화로 정의돼 있다. 자동화 스크립트나 원격 초기 설정에서는 이 방식이 더 다루기 쉽다.

config.txt로 직접 설정할 때 볼 것

설정을 파일로 관리하고 싶다면 /boot/firmware/config.txt에 다음 줄을 둔다.

dtparam=spi=on

공식 하드웨어 문서는 이 설정이 기본 SPI0를 켜는 기준이라고 설명한다. 기본적으로 SPI0는 두 개의 칩 셀렉트 라인을 사용하며, 필요하면 dtoverlay=spi0-1cs처럼 칩 셀렉트 수를 조정하는 오버레이도 사용할 수 있다.

여기서 중요한 점은 재부팅 전까지 설정이 실제 동작에 반영되지 않는다는 것이다. 설정을 바꾼 뒤 장치 노드가 바로 보이지 않아도 먼저 재부팅 여부를 확인하는 편이 맞다.

활성화 뒤 무엇을 확인하면 될까?

커널의 SPI userspace API 문서는 SPI 장치가 spidev 드라이버에 바인딩되면 /dev/spidevB.C 형식의 문자 장치가 만들어진다고 설명한다. 예를 들어 버스 0, 칩 셀렉트 0이면 일반적으로 /dev/spidev0.0 형태다.

다만 SPI를 켰다고 해서 모든 주변기기가 자동으로 바로 통신 가능한 상태가 되는 것은 아니다. 문서상으로도 spidev는 바인딩된 SPI 디바이스가 있어야 의미가 있다. 즉 버스 활성화와 실제 디바이스 바인딩은 구분해서 봐야 한다.

Python이나 C에서 바로 읽고 쓸 수 있나?

가능하다. Linux 커널 문서 기준으로 spidev는 기본적인 read(), write()와 함께 ioctl() 기반의 전송 설정을 제공한다. 다만 이 인터페이스는 어디까지나 사용자 공간용 저수준 API이므로, 인터럽트 처리나 커널 내부 서브시스템 연동이 필요한 드라이버를 완전히 대체하는 용도는 아니다.

간단한 센서 실험, 마이크로컨트롤러와의 프로토콜 테스트, 프로토타이핑처럼 사용자 공간에서 빠르게 검증하려는 목적에는 잘 맞는다.

언제 SPI1 이상 오버레이까지 봐야 할까?

기본 장치가 SPI0만으로 충분하지 않거나 칩 셀렉트 구성이 더 필요할 때다. 라즈베리파이 문서는 SPI1에 대해 1개, 2개, 3개 칩 셀렉트 오버레이를 제공한다고 설명하고, 비슷한 오버레이가 SPI2부터 SPI6까지도 있다고 적고 있다.

반대로 대부분의 입문형 연결에서는 SPI0부터 확인하는 것이 맞다. 센서 하나나 디스플레이 하나를 붙이는 수준이라면 먼저 SPI0를 정상 활성화하고 /dev/spidev0.0 또는 /dev/spidev0.1가 기대대로 보이는지 확인하는 순서가 실용적이다.

FAQ

Bookworm인데 예전 글처럼 `/boot/config.txt`를 수정해도 되나?

공식 문서는 Bookworm 이전과 이후의 기본 부트 파티션 경로 차이를 분명히 구분한다. 최신 Raspberry Pi OS Bookworm 기준으로는 /boot/firmware/config.txt를 우선 확인하는 편이 안전하다.

SPI를 켰는데 `/dev/spidev0.0`가 바로 안 보일 수 있나?

그럴 수 있다. SPI 설정은 재부팅 후 반영되고, spidev 장치 노드는 해당 SPI 디바이스가 드라이버에 바인딩될 때 생성된다. 따라서 재부팅 누락과 디바이스 바인딩 상태를 함께 봐야 한다.

`raspi-config`와 `config.txt` 중 무엇이 더 낫나?

한 번만 설정할 때는 raspi-config가 단순하고, 여러 대를 같은 방식으로 맞출 때는 config.txt 또는 raspi-config nonint가 더 관리하기 쉽다. 둘 다 공식 문서에 있는 경로다.

정리

라즈베리파이에서 SPI 설정을 헷갈리지 않으려면 기준은 간단하다. Bookworm이면 /boot/firmware/config.txt를 본다, SPI0는 기본적으로 꺼져 있으니 dtparam=spi=on 또는 raspi-config로 켠다, 재부팅 후 /dev/spidev* 존재 여부를 확인한다는 세 단계면 된다.

이 순서만 지켜도 예전 문서 경로와 최신 문서 경로를 섞어서 생기는 시행착오는 많이 줄일 수 있다.

참고 자료

Python uuid7은 언제 써야 할까? 정렬 가능한 ID 선택 기준 정리

포도알77 — Tue, 12 May 2026 12:15:46 +0900

Python uuid7은 언제 써야 할까? 정렬 가능한 ID 선택 기준 정리

Python 3.14부터 표준 라이브러리 uuid 모듈에서 uuid.uuid7()을 바로 만들 수 있다. uuid7은 Unix epoch 기준 밀리초 타임스탬프를 상위 48비트에 넣는 구조라서, 무작위 중심의 uuid4보다 생성 시각 순서를 반영하기 쉬운 것이 핵심이다.

그래서 로그, 이벤트, 주문, 작업 큐처럼 생성 순서와 조회 지역성이 중요한 데이터에서는 uuid7이 실용적일 수 있다. 반대로 순서가 전혀 필요 없거나, 기존 시스템이 이미 uuid4 중심으로 설계되어 있다면 굳이 바꿀 이유는 없다.

uuid7은 무엇이 다른가?

RFC 9562는 UUIDv7을 Unix timestamp in milliseconds 기반 형식으로 정의한다. 타임스탬프가 가장 앞쪽 비트에 오고, 나머지 비트는 무작위 값 또는 단조 증가를 돕는 필드로 채워진다. 이 구조 덕분에 생성 시각이 가까운 값들이 정렬될 때 서로 더 가깝게 모이기 쉽다.

Python 3.14 문서도 같은 방향을 따른다. uuid.uuid7()은 RFC 9562 §5.7에 따른 time-based UUID를 생성하고, 플랫폼의 서브밀리초 정밀도가 부족한 환경에서도 같은 밀리초 안에서 단조성을 보장하기 위해 42비트 카운터를 사용한다고 설명한다.

언제 uuid7이 잘 맞을까?

다음 조건이 두세 가지 이상 맞으면 uuid7을 우선 검토할 만하다.

생성 시각 기준 정렬이 자주 필요하다.
데이터베이스나 스토리지에서 완전히 랜덤한 키보다 쓰기 지역성이 나은 식별자가 유리하다.
여러 프로세스나 여러 서버에서 중앙 시퀀스 없이 ID를 만들어야 한다.
표준 라이브러리만으로 구현하고 싶고, Python 3.14 이상을 사용할 수 있다.

예를 들어 이벤트 로그, 비동기 작업 ID, 배치 실행 이력, 파일 처리 파이프라인의 run ID 같은 경우에는 사람이 타임라인을 따라가기 쉽고, 최근 생성분을 묶어서 읽기도 편하다.

uuid4와 비교하면 무엇이 달라질까?

항목	uuid4	uuid7
기본 성격	무작위 기반 UUID	시간 기반 UUID
정렬 친화성	낮음	높음
Python 표준 라이브러리 지원	오래전부터 지원	Python 3.14부터 지원
문서상 보안 관련 설명	cryptographically-secure method로 생성	시간 기반 생성, 같은 밀리초 내 단조성 고려

Python 문서 기준으로 uuid4는 cryptographically-secure method로 생성된다. 반면 uuid7의 장점은 보안성보다 정렬 친화성과 운영 편의성에 가깝다. 즉, 어떤 값이 더 낫다는 문제가 아니라 어떤 특성이 필요한지의 문제다.

Python에서는 어떻게 쓰나?

Python 3.14 이상이라면 바로 사용할 수 있다.

import datetime as dt
import uuid

u = uuid.uuid7()

print(u)
print(u.version)   # 7
print(u.time)      # Unix epoch milliseconds
print(dt.datetime.fromtimestamp(u.time / 1000, tz=dt.timezone.utc))

UUID.time 속성은 버전 7에서는 Unix epoch 기준 48비트 밀리초 타임스탬프를 돌려준다. 운영 로그나 디버깅 도구에서 생성 시각을 빠르게 확인할 때 유용하다.

uuid7이 항상 정답은 아닌 이유

다음 상황에서는 uuid4나 다른 방식이 더 단순할 수 있다.

생성 순서가 전혀 중요하지 않다.
서비스 전반이 이미 uuid4를 전제로 동작하고 있어 바꿀 실익이 작다.
런타임이 Python 3.14 미만이라 표준 라이브러리 uuid.uuid7()을 바로 쓸 수 없다.

또한 RFC 9562는 가능하면 UUIDv7을 UUIDv1과 UUIDv6 대신 사용할 것을 권하지만, 그것이 모든 식별자 정책을 uuid7 하나로 통일하라는 뜻은 아니다. 이름 기반 식별자가 필요하면 uuid3 또는 uuid5가 맞고, 완전히 무작위 중심의 식별자가 더 자연스러운 경우도 있다.

데이터베이스 키로 써도 될까?

가능하다. 다만 중요한 기준은 "UUID를 문자열로 저장할지, 바이너리로 저장할지", "기본 키 외에 생성 시각 컬럼을 별도로 둘지", "애플리케이션이 실제로 시간 순 조회를 얼마나 자주 하는지"다.

uuid7은 상위 비트에 타임스탬프가 있으므로 무작위형 UUID보다 시간 순서가 반영되기 쉽다. 하지만 데이터베이스의 실제 인덱스 효율은 컬럼 타입, 정렬 방식, 저장 엔진, 보조 인덱스 설계에 따라 달라진다. 따라서 uuid7을 쓴다고 해서 모든 쓰기 패턴이 자동으로 최적화된다고 보면 과장이다.

FAQ

Python 3.13에서는 uuid7을 못 쓰나?

표준 라이브러리 기준으로는 그렇다. Python 3.14 문서에서 UUID versions 6, 7, 8이 추가되었다고 명시한다.

uuid7을 정렬하면 항상 생성 순서와 완전히 같아지나?

대체로 시간 순서를 반영하기 쉽지만, 분산 환경에서는 같은 밀리초 안에 여러 값이 만들어질 수 있고 구현 세부도 영향을 준다. Python은 같은 밀리초 안의 단조성을 돕기 위해 42비트 카운터를 사용한다고 문서화하고 있다.

uuid1 대신 uuid7을 고려하는 이유는 무엇인가?

Python 문서는 uuid1이 호스트의 네트워크 주소를 포함할 수 있어 개인정보가 노출될 수 있다고 설명한다. RFC 9562도 가능하면 UUIDv1과 UUIDv6 대신 UUIDv7을 사용하라고 권고한다.

정리

Python에서 uuid7을 선택할지 판단하는 기준은 단순하다. 생성 시각 순서가 중요하면 uuid7, 순서가 중요하지 않고 무작위 UUID면 충분하면 uuid4다. Python 3.14부터는 이 선택을 표준 라이브러리 안에서 바로 할 수 있다.

실무에서는 "정렬 가능한 분산 ID가 필요한가"라는 질문에 먼저 답하면 된다. 그 답이 예라면 uuid7은 꽤 무난한 기본값이 될 수 있다.

참고 자료

Let's Encrypt 인증은 HTTP-01, DNS-01, TLS-ALPN-01 중 무엇을 써야 할까? 선택 기준 정리

포도알77 — Mon, 11 May 2026 12:26:24 +0900

Let's Encrypt 인증은 HTTP-01, DNS-01, TLS-ALPN-01 중 무엇을 써야 할까? 선택 기준 정리

Let's Encrypt로 인증서를 발급할 때는 ACME challenge 방식이 먼저 맞아야 한다. 2026년 5월 11일 기준 Let's Encrypt 공식 문서와 RFC를 보면, 일반적으로 많이 쓰는 선택지는 HTTP-01, DNS-01, TLS-ALPN-01 세 가지다.

차이는 단순히 설정 위치가 아니라 발급 가능한 인증서 종류, 필요한 포트, 자동화 방식, 다중 서버 환경에서의 운영 난이도에 있다. 이 글은 공식 문서 기준으로 각 방식의 동작과 선택 기준을 정리한다.

세 방식의 차이를 먼저 보면?

방식	검증 위치	필수 포트	와일드카드	주요 용도
`HTTP-01`	웹 서버의 `/.well-known/acme-challenge/` 경로	80	불가	일반 웹 서버, 단일 사이트
`DNS-01`	DNS TXT 레코드 `_acme-challenge`	없음	가능	와일드카드, 포트 80 사용이 어려운 환경
`TLS-ALPN-01`	TLS handshake와 ALPN	443	불가	TLS 종료 프록시, CDN, 로드밸런서

위 표의 와일드카드 가능 여부와 포트 요구사항은 Let's Encrypt challenge types 문서와 RFC 8555, RFC 8737에서 확인할 수 있다.

HTTP-01은 언제 적합할까?

HTTP-01은 가장 흔한 방식이다. Let's Encrypt는 클라이언트가 웹 서버의 http://<도메인>/.well-known/acme-challenge/<TOKEN> 경로에 응답을 준비하면, 여러 지점에서 해당 파일을 가져와 도메인 제어 여부를 검증할 수 있다고 설명한다.

공식 문서 기준으로 이 방식은 TCP 80번 포트에서 동작해야 하며, 와일드카드 인증서 발급에는 사용할 수 없다. 또한 여러 웹 서버가 뒤에 있는 구조라면 검증 파일이 모든 서버에서 일관되게 노출되어야 한다.

HTTP-01이 무난한 경우

일반적인 웹 사이트나 API 서버처럼 이미 HTTP 서비스를 운영 중인 경우
포트 80을 열 수 있고, .well-known 경로 제어가 가능한 경우
와일드카드 인증서가 필요하지 않은 경우

HTTP-01이 맞지 않을 수 있는 경우

ISP 정책이나 방화벽 때문에 80번 포트를 열 수 없는 경우
백엔드가 여러 대라서 검증 파일을 모든 노드에 맞추기 어려운 경우
*.example.com 같은 와일드카드 인증서가 필요한 경우

DNS-01은 왜 와일드카드에 필요할까?

DNS-01은 웹 서버 대신 DNS에 TXT 레코드를 추가해 도메인 제어를 증명한다. RFC 8555는 검증용 이름으로 _acme-challenge.<도메인> 아래에 TXT 값을 두는 절차를 정의하고, Let's Encrypt 문서는 이 방식이 와일드카드 인증서 발급을 가능하게 한다고 설명한다.

즉 *.example.com이 필요하면 사실상 먼저 검토할 방식은 DNS-01이다. 반대로 일반 단일 도메인만 필요하다면 반드시 DNS-01을 써야 하는 것은 아니다.

DNS-01을 먼저 검토할 상황

와일드카드 인증서가 필요한 경우
80번 포트를 외부에 열 수 없는 경우
정적 사이트 호스팅, 내부 서비스, 프라이빗 백엔드처럼 HTTP 검증 경로 제어가 어려운 경우

DNS-01에서 운영상 주의할 점은?

Let's Encrypt는 자동 발급과 자동 갱신이 중요하므로, DNS-01은 DNS 제공업체의 API로 TXT 레코드를 자동화할 수 있을 때 특히 의미가 크다고 설명한다. 수동으로 레코드를 바꾸는 방식은 가능하더라도 갱신 자동화 측면에서는 불리하다.

또 이 방식은 DNS 전파 시간의 영향을 받을 수 있다. 따라서 짧은 발급 성공만 보지 말고, 사용 중인 DNS 제공업체가 API와 적절한 TTL 운영을 지원하는지도 같이 확인하는 편이 안전하다.

TLS-ALPN-01은 무엇이 다를까?

TLS-ALPN-01은 HTTP 계층이 아니라 TLS 계층에서 검증한다. RFC 8737에 따르면 ACME 서버는 443번 포트로 접속해 acme-tls/1 ALPN과 대상 도메인 SNI를 사용하고, 클라이언트는 검증 전용 인증서를 제시해야 한다.

Let's Encrypt는 이 방식이 대부분의 사용자보다는 TLS 종료 리버스 프록시, CDN, TLS-terminating load balancer 같은 환경에 더 적합하다고 설명한다. HTTP 라우팅을 건드리지 않고 TLS 레이어만 제어할 수 있을 때 장점이 있다.

TLS-ALPN-01이 유리한 경우

80번 포트를 열 수 없지만 443번 포트는 제어 가능한 경우
여러 백엔드 앞단에서 TLS 종료 장비가 일괄적으로 인증을 처리하는 경우
HTTP 애플리케이션 설정을 건드리지 않고 인증 검증을 처리해야 하는 경우

TLS-ALPN-01의 한계는?

와일드카드 검증에는 사용할 수 없다.
검증 시점에 443 포트의 TLS 응답을 직접 제어해야 한다.
다중 서버 환경에서는 각 검증 대상이 일관된 TLS 응답을 내놓아야 한다.

결국 무엇을 기준으로 고르면 될까?

Let's Encrypt 문서는 확신이 없으면 클라이언트 기본값이나 HTTP-01을 따르라고 안내한다. 이를 바탕으로 실무 기준을 단순화하면 다음처럼 볼 수 있다.

일반 웹 서버이고 와일드카드가 필요 없으면 HTTP-01이 기본 선택지다.
와일드카드가 필요하거나 80번 포트를 쓸 수 없으면 DNS-01을 먼저 본다.
TLS 종료 프록시나 CDN 계층에서 검증을 끝내야 하면 TLS-ALPN-01이 더 자연스럽다.

자주 나오는 질문

Q. 리버스 프록시 뒤에 여러 웹 서버가 있으면 어떤 방식이 안전할까?

정답이 하나로 고정되지는 않는다. 다만 Let's Encrypt 문서상 HTTP-01과 TLS-ALPN-01은 여러 서버가 동일한 검증 응답을 제공해야 하므로, 앞단 프록시나 로드밸런서에서 일괄 제어가 가능해야 운영이 단순해진다. 그렇지 않다면 DNS 제어를 자동화한 DNS-01이 더 단순할 수 있다.

Q. 포트 443만 열려 있으면 HTTP-01도 가능한가?

아니다. RFC 8555는 HTTP-01 검증 요청이 HTTP 서버의 TCP 80번 포트로 가야 한다고 정의한다. 443만 열려 있다면 DNS-01이나 TLS-ALPN-01을 검토해야 한다.

Q. 와일드카드가 없는데도 DNS-01을 써도 될까?

가능하다. 다만 공식 문서 기준으로 DNS-01의 핵심 장점은 와일드카드 지원과 HTTP 포트 의존성 회피다. 일반 단일 사이트라면 HTTP-01이 더 단순할 수 있고, DNS-01은 DNS API 자동화가 준비되어 있을 때 특히 편하다.

정리

HTTP-01, DNS-01, TLS-ALPN-01은 모두 ACME 표준 안에 있지만 적합한 환경이 다르다. 일반 웹 서비스는 HTTP-01, 와일드카드나 DNS 중심 자동화는 DNS-01, TLS 종료 계층 중심 운영은 TLS-ALPN-01으로 생각하면 판단이 빨라진다.

가장 중요한 기준은 포트 제약, 와일드카드 필요 여부, 그리고 검증 지점을 애플리케이션과 DNS, TLS 중 어디에서 안정적으로 자동화할 수 있는가다.

참고 자료

Referrer-Policy는 무엇이고 어떤 값을 써야 할까? strict-origin-when-cross-origin 기준 정리

포도알77 — Sun, 10 May 2026 10:12:54 +0900

Referrer-Policy는 무엇이고 어떤 값을 써야 할까? strict-origin-when-cross-origin 기준 정리

Referrer-Policy는 브라우저가 요청을 보낼 때 Referer 헤더에 어느 범위의 이전 URL 정보를 담을지 정하는 HTTP 응답 헤더다. 2026년 5월 10일 기준 MDN과 W3C Referrer Policy 문서를 보면, 이 헤더는 전체 URL을 보낼지, origin만 보낼지, 아예 보내지 않을지를 정책 값으로 제어한다.

실무에서는 분석 도구, 외부 스크립트, CDN, 결제 이동, 이미지 핫링크 같은 상황에서 이 값이 직접 영향을 준다. 이 글은 공식 문서를 기준으로 각 정책의 차이와 현재 기본값, 그리고 어떤 상황에서 어떤 값을 검토해야 하는지를 객관적인 사실 위주로 정리한다.

Referrer-Policy는 정확히 무엇을 제어할까?

MDN은 Referrer-Policy를 요청에 포함되는 referrer 정보의 양을 제어하는 응답 헤더로 설명한다. 여기서 실제 요청 헤더 이름은 Referer인데, 헤더 이름은 역사적인 이유로 철자가 잘못된 상태이고 정책 이름은 올바른 Referrer를 쓴다.

Referer 헤더에는 문서의 전체 URL, origin만 남긴 값, 또는 아무 값도 들어가지 않을 수 있다. 다만 문서와 표준은 URL fragment와 사용자 이름, 비밀번호 정보는 referrer에 포함되지 않도록 정의한다.

2026년 기준 기본값은 무엇인가?

MDN은 2026년 5월 10일 확인 기준, 정책을 따로 지정하지 않았거나 잘못된 값을 넣은 경우 기본값이 strict-origin-when-cross-origin라고 설명한다. MDN은 이전 기본값이 no-referrer-when-downgrade였고, 현재 기본값 변경은 2020년 11월 스펙 개정과 연결된다고 적고 있다.

이 기본값에서는 same-origin 요청에는 전체 URL이 전달될 수 있고, HTTPS에서 HTTPS로 가는 cross-origin 요청에는 origin만 전달되며, HTTPS에서 HTTP로 내려가는 요청에는 Referer가 전송되지 않는다.

정책 값은 어떻게 나뉠까?

W3C Referrer Policy와 MDN이 공통으로 설명하는 주요 값은 다음과 같다.

no-referrer: 어떤 요청에도 referrer를 보내지 않는다.
same-origin: same-origin 요청에만 전체 URL을 보낸다.
origin: same-origin과 cross-origin 모두 origin만 보낸다.
origin-when-cross-origin: same-origin에는 전체 URL, cross-origin에는 origin만 보낸다.
strict-origin: 보안 수준이 유지될 때만 origin을 보내고 HTTPS에서 HTTP로는 보내지 않는다.
strict-origin-when-cross-origin: same-origin에는 전체 URL, 보안 수준이 유지되는 cross-origin에는 origin만 보내며 HTTPS에서 HTTP로는 보내지 않는다.
unsafe-url: 어디로 가든 origin, path, query까지 보낼 수 있다.

왜 기본값이 strict-origin-when-cross-origin일까?

이 질문에 대한 직접적인 설계 의도는 표준의 privacy와 security 설명에서 읽을 수 있다. 전체 URL referrer는 분석과 디버깅에는 유용하지만, path나 query string 안에 민감한 식별자나 검색어가 들어 있으면 외부 origin으로 정보가 흘러갈 수 있다.

strict-origin-when-cross-origin는 same-origin에서는 상세 URL을 유지해 내부 분석과 라우팅 진단에 도움이 되면서, cross-origin에서는 origin만 남기고 HTTPS에서 HTTP로 내려갈 때는 referrer를 막는다. 즉 기본 동작만으로도 분석 편의와 정보 최소화 사이의 균형을 맞추려는 정책이라고 해석할 수 있다.

어떤 값이 언제 문제가 될까?

1. `unsafe-url`은 왜 주의해야 할까?

MDN은 unsafe-url이 HTTPS URL의 path와 query 같은 잠재적으로 민감한 정보를 안전하지 않은 origin으로도 보낼 수 있다고 경고한다. 로그인 후 이동 경로, 검색어, 내부 문서 경로를 URL에 담는 서비스라면 특히 검토가 필요하다.

2. `no-referrer`는 언제 과할 수 있을까?

모든 요청에서 referrer를 지우면 외부 분석 도구, 결제 전환 분석, 파트너 유입 분석, 일부 CSRF 방어 보조 로그가 기대하는 정보가 사라질 수 있다. 보안상 가장 보수적이지만, 운영 관측성은 줄어든다.

3. `origin`과 `strict-origin`의 차이는 무엇일까?

둘 다 path와 query를 보내지 않는다는 점은 같지만, origin은 HTTPS에서 HTTP로 가더라도 origin을 보낼 수 있다. 반면 strict-origin은 보안 수준이 낮아지는 이동에서는 referrer를 보내지 않는다.

보통 무엇을 기준으로 고르면 될까?

아래 기준은 공식 문서에 나온 동작 차이에서 바로 따라오는 선택 기준이다.

외부로 path와 query를 보내고 싶지 않지만 내부 same-origin 분석은 유지하고 싶다면 strict-origin-when-cross-origin이 기준점이 된다.
cross-origin 요청에도 origin만 남기고, HTTPS에서 HTTP로의 유출은 막고 싶다면 strict-origin 또는 기본값인 strict-origin-when-cross-origin를 먼저 검토할 수 있다.
아예 어떤 referrer도 남기고 싶지 않다면 no-referrer가 가장 보수적이다.
외부 분석이나 연동 때문에 전체 URL 전달이 꼭 필요하다면 unsafe-url 또는 더 완화된 정책을 검토할 수 있지만, URL 설계와 민감정보 포함 여부를 먼저 확인해야 한다.

위 기준 중 마지막 항목은 정책 동작을 바탕으로 한 운영 판단이다. 실제 선택은 서비스의 URL 구조, 외부 연동, 개인정보 정책에 따라 달라진다.

헤더 말고 HTML에서도 지정할 수 있을까?

가능하다. MDN은 문서 전체에 대해 <meta name="referrer" ...>로 정책을 줄 수 있고, 개별 요청에는 referrerpolicy 속성을 <a>, <img>, <script>, <iframe>, <link> 등에 붙일 수 있다고 설명한다.

또 링크에는 rel="noreferrer"를 쓸 수도 있다. 이 값은 대시 없는 noreferrer이고, 메타 태그의 no-referrer와 표기가 다르다는 점을 MDN이 별도로 경고한다.

CSS 요청에도 영향이 있을까?

있다. MDN은 외부 CSS 스타일시트가 가져오는 리소스도 referrer policy의 영향을 받는다고 설명한다. 외부 CSS 파일은 기본 정책인 strict-origin-when-cross-origin를 따르며, 해당 CSS 응답에 별도 Referrer-Policy 헤더가 있으면 그 값이 우선할 수 있다.

반면 문서 안의 <style> 요소나 style 속성에서 발생하는 요청은 소유 문서의 정책을 따른다.

FAQ

Q. 기본값이면 대부분 충분할까?

공식 문서 기준으로 기본값은 strict-origin-when-cross-origin다. same-origin 상세 URL은 유지하면서 cross-origin 정보 노출을 줄이는 동작이므로, 별도 요구사항이 없는 일반 웹 서비스에서는 우선 비교 기준으로 삼기 쉽다. 다만 이것이 모든 서비스의 최적값이라는 뜻은 아니다.

Q. HTTPS에서 HTTP로 이동할 때 왜 referrer가 비어 있을 수 있을까?

strict-origin과 strict-origin-when-cross-origin는 HTTPS에서 HTTP처럼 보안 수준이 낮아지는 이동에 대해 referrer 전송을 막기 때문이다. MDN과 W3C 문서 모두 이 동작을 명시한다.

Q. 구형 브라우저 호환용 fallback도 줄 수 있을까?

가능하다. MDN은 쉼표로 구분한 정책 목록을 예시로 들며, 지원하지 않는 브라우저에서는 앞선 fallback을 쓰고 지원하는 브라우저에서는 마지막 정책을 사용할 수 있다고 설명한다.

정리

Referrer-Policy는 단순한 보안 헤더가 아니라, 개인정보 노출 범위와 분석 가능성을 동시에 조절하는 설정이다. 2026년 5월 10일 기준 공식 문서상 기본값은 strict-origin-when-cross-origin이며, 이는 same-origin 상세 정보 유지와 cross-origin 정보 최소화 사이의 절충안에 가깝다.

운영 중인 서비스에서 URL path나 query에 민감한 값이 들어갈 수 있다면, 현재 정책이 무엇인지 먼저 확인하는 편이 안전하다. 반대로 외부 분석 정확도가 중요하다면 정책을 완화했을 때 어떤 URL 정보가 실제로 외부로 나가는지 함께 점검해야 한다.

참고 자료

cron과 systemd timer는 무엇이 다를까? 리눅스 작업 스케줄링 선택 기준 정리

포도알77 — Sat, 9 May 2026 16:04:26 +0900

cron과 systemd timer는 무엇이 다를까? 리눅스 작업 스케줄링 선택 기준 정리

리눅스에서 반복 작업을 예약할 때 여전히 cron을 먼저 떠올리는 경우가 많지만, systemd를 쓰는 배포판에서는 systemd timer도 공식 기능으로 널리 사용된다. 2026년 5월 9일 기준 Ubuntu manpage와 systemd 문서를 보면 두 방식은 단순히 문법만 다른 것이 아니라, 시간 표현 방식, 누락 실행 처리, 로그 확인 방식, 서비스 의존성 관리에서 차이가 있다.

이 글은 Ubuntu manpage와 systemd 문서를 기준으로 cron과 systemd timer의 차이를 객관적인 사실만 정리한 글이다. 어떤 상황에서 무엇을 선택하는 편이 맞는지 빠르게 판단할 수 있도록 핵심 비교와 예시를 함께 묶었다.

cron은 무엇이고 systemd timer는 무엇인가?

crontab(5) 문서는 cron을 특정 시각과 날짜에 명령을 실행하는 방식으로 설명한다. 각 줄은 기본적으로 다섯 개의 시간 필드와 명령으로 구성되며, cron 데몬은 이를 기준으로 주기 작업을 실행한다.

반면 systemd.timer(5)는 timer unit이 다른 unit, 보통 같은 이름의 .service를 시간 조건에 따라 활성화하는 구조라고 설명한다. 즉 systemd timer는 단순 문자열 스케줄러라기보다, systemd의 unit 관리 체계 안에서 동작하는 예약 실행 기능에 가깝다.

가장 큰 차이는 무엇인가?

실무에서 체감이 큰 차이는 네 가지다.

cron은 다섯 필드 기반의 crontab 문법을 중심으로 작업을 정의한다.
systemd timer는 OnCalendar=, OnBootSec=, OnUnitActiveSec= 같은 unit 옵션으로 스케줄을 정의한다.
systemd timer는 Persistent=로 타이머가 비활성 상태였던 동안 놓친 실행을 다시 처리할 수 있다.
systemd timer는 실행 결과를 journal과 service 단위 상태로 함께 추적할 수 있다.

스케줄 문법은 어떻게 다른가?

Ubuntu의 crontab(5)는 cron 항목이 분, 시, 일, 월, 요일 필드와 명령으로 구성된다고 설명한다. 예를 들어 0 2 * * *는 매일 2시에 실행하는 식이다. 또 월의 일(day of month)과 요일(day of week)을 모두 제한하면 둘 중 하나만 일치해도 실행된다고 문서가 밝힌다.

systemd timer는 같은 주기 작업을 OnCalendar=로 표현할 수 있다. Ubuntu의 systemd.timer(5)는 calendar event 표현식과 monotonic timer를 함께 지원한다고 설명하며, systemd.time(7)는 시간 간격 문법 예시로 2h 30min 같은 형식을 제시한다. 즉 systemd timer는 "매일 02:00" 같은 달력 기반 표현과 "부팅 5분 뒤", "마지막 실행 1시간 뒤" 같은 상대 시간 표현을 한 체계 안에서 다룰 수 있다.

놓친 실행을 복구해야 하면 무엇이 더 유리할까?

이 질문에서는 systemd timer 쪽이 분명한 장점이 있다. Ubuntu의 systemd.timer(5)는 Persistent=가 참이면 마지막 트리거 시점을 디스크에 저장하고, 타이머가 비활성 상태였던 동안 한 번이라도 실행됐어야 했다면 타이머가 다시 활성화될 때 즉시 서비스를 실행한다고 설명한다.

또 같은 문서는 OnCalendar= 기반 calendar timer가 시스템이 suspend 상태일 때 시점을 놓치더라도 재개 후 catch up 처리한다고 설명한다. 다만 연속해서 여러 번 놓쳤더라도 서비스 활성화는 한 번으로 합쳐질 수 있다고 명시한다.

반대로 cron 문서는 기본적으로 현재 시각과 필드 일치 여부에 따라 실행되는 구조를 설명한다. 그래서 "부팅 중이거나 서비스가 멈춘 사이에 놓친 작업을 자동 복구해야 하는가"가 중요하면, cron 단독보다 Persistent=가 있는 systemd timer가 더 직접적인 선택지가 된다.

로그와 실패 확인은 어떻게 다른가?

cron 계열은 전통적으로 작업 출력 메일 전송과 셸 리다이렉션을 많이 사용한다. Ubuntu의 crontab(5)는 MAILTO를 통해 작업 출력을 메일로 보낼 수 있다고 설명한다.

systemd 쪽은 실행 단위가 service이기 때문에 상태 확인과 로그 조회가 더 일관적이다. Ubuntu의 systemd.cron(7)와 systemd-crontab-generator(8) 문서는 관련 로그가 journal에 남고, systemctl list-timers로 타이머 현황을 볼 수 있다고 설명한다. systemd timer를 직접 작성하면 같은 흐름으로 systemctl status와 journalctl -u ...를 사용할 수 있다.

정확한 시각 실행이 중요하면 무엇을 확인해야 할까?

systemd timer는 설정한 시각에 무조건 초 단위로 딱 맞춰 실행된다고 보면 안 된다. Ubuntu의 systemd.timer(5)는 타이머가 AccuracySec=의 영향을 받으며, 기본값은 1분이라고 설명한다. 즉 별도 조정이 없으면 설정 시각 주변 윈도 안에서 동작할 수 있다.

같은 문서는 RandomizedDelaySec=를 함께 써서 부하 분산을 할 수 있다고 설명한다. 따라서 "정확히 매일 00:00:00에 실행"이 정말 중요하면 systemd timer에서도 AccuracySec과 지연 옵션을 의식해서 설정해야 한다.

서비스 의존성과 실행 환경을 같이 관리하려면?

cron은 기본적으로 명령 실행 중심이다. 환경 변수, 셸, 경로를 crontab 안에서 따로 챙겨야 하고, 복잡한 의존성은 스크립트 내부에서 처리하는 경우가 많다.

systemd timer는 timer가 service를 활성화하는 구조라서, 실제 작업 정의를 .service에 분리할 수 있다. 이 방식이면 작업 계정, 작업 디렉터리, 재시작 정책, 선행 조건, 리소스 제한 같은 systemd 속성을 같이 관리하기 쉽다. 배포 자동화나 서버 운영 작업에서 timer가 자주 선택되는 이유가 여기에 있다.

FAQ

Q. 간단한 개인 작업도 systemd timer로 바꿔야 할까?

반드시 그렇지는 않다. 이미 cron 문법에 익숙하고 단순 반복 실행만 필요하다면 cron도 충분히 실용적이다. 다만 로그 추적, service 단위 관리, 놓친 실행 복구가 필요하면 systemd timer 쪽 이점이 커진다.

Q. systemd timer는 달력 기반 예약만 가능한가?

아니다. systemd.timer(5)는 OnCalendar= 외에도 OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec= 같은 monotonic timer 옵션을 설명한다.

Q. systemd timer를 쓰면 놓친 실행이 모두 개별적으로 재실행되나?

항상 그렇지는 않다. Ubuntu의 systemd.timer(5)는 suspend 중 여러 번 시점을 놓친 calendar timer라도 재개 후 서비스 활성화는 한 번만 일어날 수 있다고 설명한다.

언제 cron을 쓰고 언제 systemd timer를 쓰면 좋을까?

다음 기준으로 나누면 실무 판단이 단순해진다.

cron: 짧은 명령 하나를 익숙한 다섯 필드 문법으로 돌리면 충분한 경우
systemd timer: 서비스 단위 관리, journal 로그, 누락 실행 복구, 부팅 기준 상대 시간 실행이 필요한 경우

특히 서버 운영 작업이나 배포 후 정기 점검 작업처럼 "실패 원인 추적"과 "실행 보장"이 중요한 경우에는 systemd timer가 더 설명력이 높다. 반대로 개인 환경에서 간단한 명령을 빠르게 예약하려면 cron이 더 짧고 익숙할 수 있다.

정리

cron과 systemd timer는 둘 다 반복 작업을 예약하지만, 동작 모델은 다르다. cron은 시각 필드와 명령 중심이고, systemd timer는 timer와 service를 분리해 더 넓은 운영 제어를 제공한다.

2026년 5월 9일 기준 Ubuntu와 systemd 문서를 기준으로 보면, 놓친 실행 복구가 중요하거나 journal과 unit 상태까지 함께 관리해야 하는 작업은 systemd timer가 유리하다. 반대로 단순한 예약 명령이라면 cron이 여전히 충분히 실용적이다.

참고 자료

Let's Encrypt rate limit은 어떻게 계산될까? 2026 기준 발급 제한과 재시도 방법 정리

포도알77 — Fri, 8 May 2026 10:15:43 +0900

Let's Encrypt rate limit은 어떻게 계산될까? 2026 기준 발급 제한과 재시도 방법 정리

Let's Encrypt를 운영하다 보면 "왜 갑자기 발급이 막혔지?"라는 상황을 겪을 수 있다. 하지만 대부분의 제한은 임의로 막히는 것이 아니라 문서에 공개된 규칙대로 계산된다. 새 인증서 발급, 동일 도메인 반복 발급, 검증 실패 누적, 테스트 환경 사용 여부를 구분해서 보면 원인을 비교적 빠르게 좁힐 수 있다.

이 글은 2026년 5월 8일 기준 Let's Encrypt 공식 문서와 Certbot 공식 안내를 바탕으로, 자주 부딪히는 rate limit 수치와 renewal 예외, 재시도 방법을 객관적으로 정리한 초안이다.

가장 먼저 알아야 할 핵심은 무엇인가?

Let's Encrypt의 rate limit은 요청마다 적용되는 토큰 버킷 방식으로 계산된다. 그래서 짧은 시간에 몰아서 요청하면 제한에 빨리 닿을 수 있고, 시간을 두고 나누면 같은 총량이어도 더 안정적으로 처리될 수 있다. 또한 인증서를 취소해도 이미 사용한 발급 자원은 되돌아오지 않으므로, revoke가 limit 초기화 수단은 아니다.

새 계정 생성 제한과 인증서 발급 제한은 서로 다르다.
갱신은 신규 발급과 동일하게 취급되지 않는다.
테스트나 장애 분석은 production보다 staging에서 먼저 하는 것이 안전하다.
에러 메시지와 Retry-After 헤더를 보면 언제 다시 시도할지 판단할 수 있다.

2026년 기준으로 자주 보는 주요 발급 제한 수치는?

Let's Encrypt의 2025년 6월 12일자 rate limits 문서 기준으로, 실무에서 가장 자주 확인하는 수치는 다음과 같다.

계정당 새 order: 3시간에 최대 300개
등록 도메인당 새 인증서: 7일에 최대 50개
정확히 같은 식별자 집합: 7일에 최대 5개
계정당 식별자별 authorization 실패: 1시간에 최대 5회

여기서 registered domain은 단순히 최상위 도메인 문자열이 아니라 Public Suffix List 기준으로 계산된다. 예를 들어 www.example.com은 example.com, new.blog.example.co.uk는 example.co.uk 기준으로 묶인다. IPv4는 개별 주소, IPv6는 /64 범위를 기준으로 본다고 문서에 적혀 있다.

왜 같은 도메인을 반복 발급하면 더 빨리 막힐까?

운영 중 많이 헷갈리는 부분이 exact set of identifiers 제한이다. 같은 호스트명 조합으로 인증서를 반복 발급하면 7일 동안 최대 5개까지만 허용된다. 예를 들어 example.com과 www.example.com 조합으로 짧은 시간 안에 인증서를 여러 번 다시 만들면, 다른 limit보다 먼저 여기에 걸릴 수 있다.

Let's Encrypt 문서는 ACME 클라이언트를 반복 재설치하거나, 배포 때마다 클라이언트 설정을 지우고 새로 발급하는 패턴을 대표 원인으로 든다. 따라서 운영 환경에서는 기존 계정과 기존 인증서 계보를 유지한 채 갱신 흐름을 쓰는 편이 안전하다. 단순 재배포를 신규 발급처럼 만들면 limit을 불필요하게 소모한다.

renewal은 정말 rate limit에서 자유로운가?

완전히 같은 방식은 아니지만, 공식 문서는 renewal을 두 가지 방식으로 예외 처리한다고 설명한다. 가장 우선되는 방식은 ACME Renewal Info, 즉 ARI 기반 renewal이다. ARI로 조정되는 renewal은 모든 rate limit에서 면제된다.

ARI를 아직 쓰지 않는 클라이언트나 호스팅 환경이라도, 같은 식별자 집합으로 갱신하면 renewal로 인정될 수 있다. 이 경우에도 새 order per account와 registered domain per 7 days 제한에서는 제외되지만, authorization 실패 제한과 exact set of identifiers 제한에서는 완전히 자유롭지 않다. 그래서 "renewal이면 무조건 아무 제한도 없다"라고 단정하면 틀릴 수 있다.

또한 Let's Encrypt는 2026년 2월 24일 공지에서 향후 2년 동안 기본 인증서 수명을 90일에서 64일, 다시 45일로 줄여 가겠다고 설명했다. 동시에 renewal은 계속 rate limit 예외로 취급되므로, 기존 인증서를 정상적으로 갱신하는 운영이라면 수명 단축 자체가 limit 확대를 의미하지는 않는다고 밝혔다.

검증 실패 limit은 어떤 상황에서 잘 발생할까?

authorization 실패는 발급 수보다 더 빨리 장애를 키우는 항목이다. 식별자별로 계정당 1시간에 5회까지만 실패할 수 있기 때문이다. HTTP-01과 TLS-ALPN-01은 외부 검증 서버가 실제 서비스에 도달하지 못할 때, DNS-01은 CNAME 또는 TXT 레코드 설정 실수 때 자주 실패한다는 점을 Let's Encrypt 문서가 명시하고 있다.

연속 실패에 대한 별도 limit도 있다. 같은 식별자에 대해 연속 authorization 실패가 누적되면 발급이 일시 정지될 수 있으며, 문서에는 최대 1,152회의 연속 실패 한도와 self-service portal을 통한 해제 절차가 설명돼 있다. 즉 단순히 재시도 루프를 돌리는 것은 복구 전략이 아니라 문제를 더 오래 끄는 패턴일 수 있다.

테스트와 장애 분석은 어떻게 해야 안전할까?

Let's Encrypt는 production API 대신 staging environment를 먼저 쓰라고 명확하게 권장한다. staging은 production과 같은 종류의 limit을 가지지만 값이 훨씬 크다. 예를 들어 계정당 새 order는 3시간에 1,500개, exact set of identifiers는 주당 30,000개까지 허용된다.

Certbot을 쓴다면 공식 안내에 따라 sudo certbot renew --dry-run으로 자동 갱신을 점검할 수 있다. Let's Encrypt 문서는 Certbot에서 staging 테스트를 위해 --test-cert 또는 --dry-run을 사용할 수 있다고 설명한다. 또한 staging과 production의 ACME 계정은 서로 분리되므로 별도 계정이 필요하지만, Certbot이 이 부분을 처리한다고 문서에 적혀 있다.

실무에서는 어떤 예방책이 효과적인가?

배포마다 새 인증서를 발급하지 말고 기존 renewal 흐름을 유지한다.
장애 분석은 먼저 staging에서 재현한다.
검증 실패가 나면 무한 재시도보다 HTTP, DNS, 방화벽, 프록시 구성을 먼저 확인한다.
동일 식별자 집합으로 짧은 시간에 인증서를 반복 생성하지 않는다.
자동 갱신 점검은 Certbot의 renew --dry-run이나 사용 중인 ACME 클라이언트의 테스트 절차로 확인한다.

여기에 더해 계정을 쓸데없이 여러 개로 나누지 않는 것도 중요하다. Let's Encrypt는 대규모 통합 환경에서 하나의 계정을 여러 고객에 재사용하는 설계를 권장한다. 반대로 발급 로직이 분산돼 매번 새 계정을 만들면 계정 생성 limit과 운영 복잡도가 함께 커질 수 있다.

FAQ

Q. rate limit에 걸렸다면 인증서를 revoke하면 바로 다시 발급할 수 있나?

아니다. Let's Encrypt 문서는 인증서 취소가 이미 소비된 발급 자원을 되돌리지 못한다고 설명한다. 따라서 revoke는 보안 대응 수단이지, rate limit 초기화 수단이 아니다.

Q. exact set of identifiers 제한을 피하려고 호스트명을 하나 더 넣으면 되나?

문서상으로는 식별자 집합이 바뀌면 exact set limit은 달라질 수 있다. 다만 이렇게 만든 order는 renewal이 아니라 새 발급으로 취급될 수 있어, account당 새 order 제한과 registered domain 제한을 다시 소모할 수 있다. 임시 우회는 가능해도 기본 운영 전략으로 삼기에는 위험하다.

Q. Certbot 자동 갱신이 설정돼 있는지 어떻게 확인하나?

Certbot 공식 안내는 자동 갱신 명령이 /etc/crontab, /etc/cron.*/*, 또는 systemctl list-timers에 있을 수 있다고 설명한다. 그리고 실제 갱신 동작 테스트는 sudo certbot renew --dry-run으로 확인하라고 안내한다.

정리

Let's Encrypt rate limit은 막연한 정책이 아니라 공개된 수치와 규칙으로 동작한다. 2026년 기준으로 핵심은 새 order 3시간 300개, 등록 도메인 7일 50개, 동일 식별자 집합 7일 5개, 식별자별 authorization 실패 1시간 5회다. 운영에서 중요한 점은 신규 발급과 renewal을 구분하고, 장애 분석은 staging에서 먼저 하며, 반복 재발급과 무한 재시도 루프를 피하는 것이다.

참고 자료

윈도우 소리를 맥북 스피커로 보내기: FFmpeg와 VB-CABLE로 만든 개인용 네트워크 스피커

포도알77 — Thu, 7 May 2026 21:42:19 +0900

윈도우 소리를 맥북 스피커로 보내기: FFmpeg와 VB-CABLE로 만든 개인용 네트워크 스피커

데스크톱 PC에는 스피커가 없고, 옆에 있는 맥북 스피커는 멀쩡히 남아 있는 상황이 있다. 이럴 때 가장 먼저 떠오르는 생각은 단순하다. 윈도우에서 재생되는 소리를 네트워크로 맥북에 보내고, 맥북이 그것을 스피커처럼 재생하면 되지 않을까?

결론부터 말하면 가능하다. 다만 윈도우에 진짜 스피커 장치처럼 보이게 만드는 것과, 개인용으로 빨리 쓸 수 있게 만드는 것은 난이도가 크게 다르다. 이 글은 직접 실험하면서 정리한 가장 현실적인 구성, 즉 VB-CABLE + FFmpeg + MPEG-TS/Opus over UDP 방식의 개인용 네트워크 스피커 구조를 정리한다.

처음 생각한 구조

이상적인 모습은 다음과 같다.

윈도우에 Network Speaker 같은 출력 장치가 나타난다.
사용자는 그 장치를 기본 스피커로 선택한다.
윈도우 앱이 오디오를 받아 네트워크로 전송한다.
맥 앱이 수신한 오디오를 맥북 스피커로 재생한다.

사용자 경험만 보면 간단해 보이지만, 첫 번째 단계가 가장 어렵다. 윈도우 사운드 설정에 새로운 출력 장치를 만들려면 일반 앱이 아니라 가상 오디오 드라이버가 필요하다. Microsoft의 SysVAD 샘플처럼 가상 오디오 장치를 구현하는 예제가 있기는 하지만, 실제로 쓰려면 Windows Driver Kit, 드라이버 설치, 테스트 서명 또는 배포용 서명 절차까지 고려해야 한다.

개인용 도구를 만들기 위해 처음부터 드라이버를 붙잡는 것은 배보다 배꼽이 커지기 쉽다. 그래서 이 실험에서는 드라이버는 이미 검증된 VB-CABLE에 맡기고, 전송과 재생만 직접 구성했다.

최종 구성

최종적으로 잘 동작한 구성은 다음과 같다.

Windows
  기본 출력 장치: CABLE Input(VB-Audio Virtual Cable)
  캡처 장치:     CABLE Output(VB-Audio Virtual Cable)
  송신:          FFmpeg
  포맷:          Opus inside MPEG-TS
  전송:          UDP

Mac
  수신/재생:      ffplay
  출력:          MacBook speaker

윈도우는 실제 스피커 대신 VB-CABLE의 입력 장치로 소리를 보낸다. 그러면 FFmpeg가 VB-CABLE의 출력 장치를 캡처해서 맥으로 전송한다. 맥에서는 ffplay가 UDP 패킷을 받아 재생한다.

처음에는 raw PCM over UDP와 RTP/Opus도 시도했다. raw PCM은 단순하지만 Wi-Fi 상태에 따라 소리가 늘어지거나 지연이 쌓일 수 있었다. RTP/Opus는 구조적으로는 맞지만 SDP와 payload type 설정이 생각보다 예민했다. 결과적으로 개인용 스크립트에서는 MPEG-TS 컨테이너에 Opus를 넣어 UDP로 보내는 방식이 가장 무난했다.

필요한 것

윈도우 쪽에는 두 가지가 필요하다.

VB-CABLE: 윈도우에 가상 오디오 케이블 장치를 만들어준다.
FFmpeg: VB-CABLE 오디오를 캡처하고 네트워크로 전송한다.

맥 쪽에는 FFmpeg에 포함된 ffplay가 필요하다.

brew install ffmpeg

윈도우에서 FFmpeg를 설치하는 가장 쉬운 방법은 winget을 사용하는 것이다.

winget install Gyan.FFmpeg

VB-CABLE은 드라이버 성격의 프로그램이므로 별도로 설치해야 한다. 단순 실행파일을 앱 폴더에 같이 넣는 것과는 다르게, 관리자 권한과 장치 설치 과정이 필요할 수 있다.

맥 수신 스크립트

맥에서는 UDP 5004 포트로 들어오는 MPEG-TS 스트림을 ffplay로 재생한다. 아래 예시는 로컬 경로를 포함하지 않는 일반화된 스크립트다.

#!/usr/bin/env bash
set -euo pipefail

PORT="${1:-5004}"

ffplay \
  -hide_banner \
  -loglevel warning \
  -nodisp \
  -fflags nobuffer \
  -flags low_delay \
  -max_delay 50000 \
  -probesize 2048 \
  -analyzeduration 0 \
  -f mpegts \
  "udp://0.0.0.0:${PORT}?listen=1&buffer_size=65536&fifo_size=512&overrun_nonfatal=1"

실행 순서는 맥 수신기를 먼저 켜고, 그 다음 윈도우 송신기를 실행하는 방식이 좋다.

윈도우 송신 스크립트

윈도우에서는 DirectShow 입력 장치로 VB-CABLE의 출력 장치를 지정한다. VB-CABLE 장치 이름은 설치 환경에 따라 공백이 조금 다를 수 있으므로, 실제 장치 목록에서 확인한 이름을 넣어야 한다.

param(
  [Parameter(Mandatory = $true)]
  [string]$MacIp,

  [int]$Port = 5004,

  [string]$Device = "CABLE Output(VB-Audio Virtual Cable)"
)

$target = "udp://$($MacIp):$($Port)?pkt_size=1316"

ffmpeg `
  -hide_banner `
  -loglevel info `
  -fflags nobuffer `
  -flags low_delay `
  -f dshow `
  -audio_buffer_size 30 `
  -i "audio=$Device" `
  -vn `
  -ac 2 `
  -ar 48000 `
  -c:a libopus `
  -b:a 128k `
  -vbr off `
  -application lowdelay `
  -frame_duration 10 `
  -compression_level 0 `
  -flush_packets 1 `
  -f mpegts `
  $target

맥의 IP 주소는 맥에서 다음 명령으로 확인할 수 있다.

ipconfig getifaddr en0

윈도우에서는 다음처럼 실행한다.

powershell -ExecutionPolicy Bypass -File .\send-ts.ps1 -MacIp 192.168.0.10

192.168.0.10은 예시 IP다. 실제로는 자신의 맥북 IP 주소로 바꿔야 한다.

테스트톤으로 먼저 확인하기

문제가 생겼을 때는 실제 윈도우 소리를 바로 보내기보다 테스트톤부터 보내는 편이 좋다. 이렇게 하면 네트워크 문제인지, VB-CABLE 캡처 문제인지 분리해서 볼 수 있다.

param(
  [Parameter(Mandatory = $true)]
  [string]$MacIp,

  [int]$Port = 5004
)

$target = "udp://$($MacIp):$($Port)?pkt_size=1316"

ffmpeg `
  -hide_banner `
  -loglevel info `
  -f lavfi `
  -i "sine=frequency=440:sample_rate=48000" `
  -ac 2 `
  -ar 48000 `
  -c:a libopus `
  -b:a 128k `
  -vbr off `
  -application lowdelay `
  -frame_duration 10 `
  -compression_level 0 `
  -flush_packets 1 `
  -f mpegts `
  $target

테스트톤은 들리는데 일반 오디오가 들리지 않는다면, 윈도우 기본 출력 장치가 CABLE Input(VB-Audio Virtual Cable)으로 설정되어 있는지 확인한다. 테스트톤도 들리지 않는다면 두 장비가 같은 네트워크에 있는지, 맥 방화벽이 수신을 막고 있지 않은지, IP 주소를 잘못 입력하지 않았는지부터 확인한다.

왜 TCP는 피했나?

처음 디버깅할 때는 TCP도 시도했다. TCP는 연결 실패가 비교적 명확하게 보이기 때문에 네트워크 확인용으로는 편하다. 하지만 오디오 스트리밍에서는 버퍼가 커지거나 재전송이 발생하면서 지연이 크게 늘어날 수 있다. 실제 체감 지연이 1~2초 이상으로 느껴질 수 있으므로, 스피커처럼 쓰기에는 UDP가 더 적합했다.

UDP는 패킷 손실에 민감하지만, 같은 공유기 안의 개인용 네트워크에서는 충분히 쓸 만하다. 특히 raw PCM보다 Opus를 사용하면 대역폭 부담이 줄어들고, MPEG-TS 컨테이너를 쓰면 수신 쪽에서 스트림을 인식하기도 쉽다.

FFmpeg를 앱에 포함할 수 있을까?

FFmpeg 실행파일은 앱 폴더에 포함해서 배포하는 형태로 만들 수 있다. 예를 들어 윈도우 폴더 안에 bin/ffmpeg.exe를 넣고, PowerShell 스크립트가 PATH보다 그 파일을 먼저 찾게 만들면 사용자는 FFmpeg를 별도로 설치하지 않아도 된다.

다만 배포를 생각한다면 라이선스를 확인해야 한다. FFmpeg는 기본적으로 LGPL 계열 라이선스이고, 빌드 옵션에 따라 GPL 또는 재배포가 어려운 nonfree 구성이 될 수 있다. 개인용으로 쓰는 것과 공개 배포는 다르므로, 공개 배포를 할 때는 FFmpeg 공식 legal 문서와 사용한 바이너리의 빌드 옵션을 확인해야 한다.

VB-CABLE까지 포함할 수 있을까?

FFmpeg와 달리 VB-CABLE은 단순한 보조 실행파일이 아니라 윈도우 오디오 드라이버에 가깝다. 그래서 앱 폴더에 같이 넣고 실행하는 방식으로 자연스럽게 포함하기 어렵다. 설치에는 관리자 권한과 드라이버 설치 과정이 필요하고, 재배포 조건도 별도로 확인해야 한다.

VB-CABLE 없이 완전히 처음부터 만들려면 자체 가상 오디오 드라이버를 만들어야 한다. Microsoft의 SysVAD 샘플이 출발점이 될 수 있지만, 이 순간부터는 작은 유틸리티가 아니라 Windows 드라이버 프로젝트가 된다. 개인용 네트워크 스피커를 만들기 위한 목적이라면, 드라이버는 VB-CABLE에 맡기고 나머지 송수신 흐름만 직접 다루는 편이 현실적이다.

정리

윈도우 소리를 맥북 스피커로 보내는 것은 가능하다. 하지만 완전히 자연스러운 제품처럼 만들려면 가상 오디오 드라이버라는 큰 벽을 만나게 된다. 개인용으로 빠르게 쓰려면 다음 조합이 가장 단순했다.

VB-CABLE
+ FFmpeg
+ Opus inside MPEG-TS over UDP
+ ffplay on Mac

이 방식은 완벽한 제품은 아니지만, 같은 네트워크 안에서 데스크톱 PC의 소리를 맥북 스피커로 보내는 개인용 도구로는 충분히 실용적이다. 중요한 포인트는 처음부터 드라이버를 만들려고 하지 않는 것이다. 먼저 검증된 가상 오디오 케이블을 사용해 흐름을 완성하고, 정말 필요할 때만 드라이버 제작을 별도 프로젝트로 분리하는 편이 낫다.

참고 자료

Python free-threaded 빌드는 무엇이 달라졌을까? 3.13~3.14 기준 설치·확인·제약 정리

포도알77 — Thu, 7 May 2026 10:08:56 +0900

Python free-threaded 빌드는 무엇이 달라졌을까? 3.13~3.14 기준 설치·확인·제약 정리

Python에서 스레드를 여러 개 써도 CPU 병렬 실행이 기대만큼 나오지 않는 이유로 GIL(Global Interpreter Lock)이 자주 언급된다. Python 3.13부터는 GIL을 끈 free-threaded 빌드가 도입됐고, 2026년 5월 7일 기준 공식 문서는 설치 방법, 확인 방법, 제약 사항을 별도 문서로 정리하고 있다.

이 글은 Python 공식 문서와 PEP 703을 기준으로, free-threaded 빌드가 무엇인지, Python 3.13과 3.14 문서에서 어떻게 설명되는지, 실제로 확인할 때 어떤 점을 봐야 하는지 객관적인 사실만 정리한 글이다.

Python free-threaded 빌드는 무엇인가?

Python 3.13 공식 문서는 free threading을 GIL이 비활성화된 Python 빌드로 설명한다. 이 빌드의 목적은 여러 CPU 코어에서 스레드를 병렬로 실행할 수 있게 하는 것이다. 다만 모든 프로그램이 자동으로 빨라지는 것은 아니며, 스레딩을 염두에 두고 설계된 프로그램에서 효과를 기대할 수 있다고 문서는 설명한다.

PEP 703은 이 변화를 "CPython에서 GIL을 선택 사항으로 만드는 작업"으로 정의한다. 즉 free-threaded 빌드는 기존 Python 동작을 완전히 대체하는 기본 모드라기보다, 별도 빌드 구성을 통해 GIL 없는 실행 경로를 제공하는 방향으로 이해하는 편이 정확하다.

Python 3.13과 3.14 문서 표현은 어떻게 다른가?

Python 3.13의 "What's New" 문서는 free-threaded mode를 실험적 지원이라고 설명한다. 같은 3.13 HOWTO 문서도 free-threaded mode는 experimental이며 버그와 단일 스레드 성능 저하를 예상해야 한다고 적고 있다.

반면 현재 메인 문서 경로인 Python 3.14 계열 HOWTO는 제목을 "Python support for free threading"으로 바꿔 설명한다. 다만 여기서도 모든 생태계가 준비된 것은 아니라고 분명히 밝힌다. 특히 일부 서드파티 패키지, 그중에서도 extension module을 포함한 패키지는 free-threaded 빌드에서 GIL을 다시 활성화할 수 있다고 안내한다.

정리하면 2026년 5월 7일 기준 공식 문서 흐름은 이렇다.

Python 3.13: 기능 도입 시점이며 실험적 지원이라고 명시
Python 3.14 문서: free threading 지원 문서로 발전했지만 패키지 호환성 주의는 계속 유지

어떻게 설치하고 빌드할 수 있나?

공식 HOWTO에 따르면 Python 3.13부터 macOS와 Windows의 공식 설치 프로그램은 free-threaded Python 바이너리를 선택적으로 설치할 수 있다. 소스에서 직접 빌드할 때는 --disable-gil 옵션을 사용해야 한다.

즉 설치 경로는 두 가지다.

공식 macOS 또는 Windows 설치 프로그램에서 free-threaded 바이너리 선택
소스 빌드 시 --disable-gil 옵션 사용

공식 문서는 다른 플랫폼에 대해서는 별도 커뮤니티 가이드를 연결하지만, 이 글에서는 Python 공식 문서에 직접 적힌 정보만 기준으로 다룬다.

내 Python이 free-threaded 빌드인지 어떻게 확인하나?

Python 3.13 HOWTO와 3.14 HOWTO는 확인 방법을 명확히 제시한다. python -VV와 sys.version 문자열에 free-threading build 문구가 들어가면 해당 빌드는 free-threading을 지원한다. 또 sys._is_gil_enabled()로 현재 프로세스에서 GIL이 실제로 켜져 있는지 확인할 수 있다.

빌드 구성 여부를 코드에서 판별할 때는 sysconfig.get_config_var("Py_GIL_DISABLED")를 쓰는 것이 공식 문서가 권장하는 방법이다. 값이 1이면 그 빌드는 free threading을 지원한다.

python -VV

python -c "import sys; print(sys.version)"
python -c "import sys; print(sys._is_gil_enabled())"
python -c "import sysconfig; print(sysconfig.get_config_var('Py_GIL_DISABLED'))"

GIL은 항상 꺼진 상태로 동작하나?

아니다. 공식 HOWTO는 free-threaded 빌드가 런타임에서 GIL을 다시 켤 수 있다고 설명한다. 방법은 환경 변수 PYTHON_GIL 또는 명령행 옵션 -X gil이다.

또 하나 중요한 점은 C API extension module이다. 문서에 따르면 free threading을 명시적으로 지원하지 않는 C 확장 모듈을 import하면, 경고와 함께 GIL이 자동으로 활성화될 수 있다. 따라서 "free-threaded Python을 설치했다"는 사실과 "실제 실행 중에도 끝까지 GIL 없이 동작한다"는 사실은 구분해서 봐야 한다.

스레드 안전성은 자동으로 보장되나?

공식 HOWTO는 dict, list, set 같은 내장 타입이 동시 수정에 대해 내부 락을 사용해 GIL 환경과 비슷한 동작을 목표로 한다고 설명한다. 하지만 이것은 현재 구현 설명일 뿐, 미래 버전까지 보장되는 언어 명세는 아니라고 못 박고 있다.

그래서 문서도 내장 타입의 내부 락에 기대기보다 threading.Lock 같은 동기화 도구를 직접 사용하는 편을 권장한다. free-threaded 빌드가 생겼다고 해서 기존 경쟁 조건이 자동으로 사라지는 것은 아니다.

현재 공식 문서가 말하는 제약은 무엇인가?

Python 3.13 HOWTO는 몇 가지 제한을 구체적으로 적고 있다. 첫째, 3.13의 free-threaded 빌드는 일부 객체를 immortalize해 참조 카운트 갱신 경쟁을 줄인다. 이 때문에 특정 유형의 객체를 많이 만드는 프로그램은 메모리 사용량 증가를 볼 수 있다고 문서는 설명한다.

둘째, 다른 스레드에서 frame 객체에 접근하는 것은 안전하지 않으며 충돌을 일으킬 수 있다. 셋째, 같은 iterator 객체를 여러 스레드가 공유하는 것도 안전하지 않다고 설명한다.

넷째, 3.13 문서는 단일 스레드 성능 오버헤드가 있다고 밝힌다. pyperformance 기준으로 3.13 free-threaded 빌드는 기본 GIL 빌드보다 약 40%의 오버헤드를 보인다고 적고 있으며, 그 주요 이유 중 하나로 specializing adaptive interpreter가 비활성화돼 있다는 점을 든다.

그럼 언제 검토하는 것이 맞을까?

공식 문서 기준으로 free-threaded 빌드는 다음 상황에서 검토 가치가 있다.

CPU 코어를 활용하는 스레드 병렬 실행이 실제로 필요한 경우
사용 중인 패키지, 특히 C 확장 모듈이 free threading 호환 상태인지 별도로 확인할 수 있는 경우
단일 스레드 성능 저하나 일부 구현 제약을 감수할 수 있는 경우

반대로 I/O 중심 워크로드이거나, 핵심 라이브러리가 아직 free-threaded 빌드를 제대로 지원하지 않는다면 기본 GIL 빌드를 유지하는 편이 더 단순할 수 있다. 이 판단은 성능 기대치보다 패키지 호환성과 운영 안정성 확인이 먼저다.

FAQ

Q. Python 3.13을 설치하면 기본으로 free-threaded 빌드를 쓰게 되나?

아니다. Python 3.13 공식 문서는 free-threaded mode가 기본값이 아니라고 설명한다. 별도 실행 파일이나 설치 선택지, 또는 소스 빌드 구성이 필요하다.

Q. free-threaded 빌드면 모든 패키지가 그대로 동작하나?

공식 3.14 HOWTO는 일부 서드파티 패키지, 특히 extension module이 포함된 패키지가 아직 준비되지 않았을 수 있다고 설명한다. 이런 패키지는 GIL을 다시 활성화할 수 있다.

Q. 동시성 버그가 자동으로 사라지나?

아니다. 공식 문서도 내장 타입의 현재 동작을 언어 차원의 보장으로 보지 말라고 설명하며, threading.Lock 같은 동기화 수단을 계속 사용할 것을 권장한다.

정리

Python free-threaded 빌드는 GIL이 없는 Python을 바로 기본값으로 바꾼 것이 아니라, Python 3.13부터 선택 가능한 별도 빌드 경로를 추가한 변화다. 2026년 5월 7일 기준 공식 문서를 보면 3.13에서는 실험적 지원으로 소개됐고, 3.14 문서에서는 지원 문서가 정리됐지만 패키지 호환성과 일부 제약은 여전히 중요한 확인 항목이다.

따라서 실무에서는 설치 여부보다 먼저 현재 빌드가 free-threading을 지원하는지, 실행 중 GIL이 다시 켜졌는지, 핵심 패키지가 이를 지원하는지, 그리고 단일 스레드 성능 저하를 감수할 수 있는지를 함께 점검하는 편이 정확하다.

참고 자료

CSP nonce와 hash는 언제 써야 할까? strict-dynamic까지 한 번에 정리

포도알77 — Wed, 6 May 2026 10:23:51 +0900

CSP nonce와 hash는 언제 써야 할까? strict-dynamic까지 한 번에 정리

Content Security Policy(CSP)를 적용할 때 가장 많이 헷갈리는 부분 중 하나가 nonce와 hash를 언제 써야 하느냐다. 결론부터 말하면 서버가 응답마다 HTML을 동적으로 만들 수 있으면 nonce가 유지보수에 유리하고, 정적 파일이나 캐시되는 HTML이라면 hash가 더 잘 맞는다. W3C CSP Level 3, MDN, web.dev 문서는 이 두 방식을 모두 strict CSP의 핵심 수단으로 설명한다.

핵심 차이는 신뢰를 표시하는 방법이다. nonce는 응답마다 새로 만든 임의 값을 Content-Security-Policy 헤더와 <script> 또는 <style> 요소에 같이 넣는 방식이고, hash는 인라인 스크립트나 스타일의 정확한 내용에 대한 SHA-256, SHA-384, SHA-512 해시를 정책에 넣는 방식이다. 여기에 strict-dynamic까지 이해하면 실제 배포 판단이 훨씬 쉬워진다.

nonce는 정확히 무엇을 뜻하나?

MDN과 CSP 명세에 따르면 nonce는 한 번만 쓰는 난수 값이다. 서버는 각 HTTP 응답마다 예측하기 어려운 새 값을 생성하고, 그 값을 CSP 헤더의 'nonce-...' 형태와 허용할 <script>, <style> 요소의 nonce 속성에 같은 값으로 넣는다.

Content-Security-Policy:
  script-src 'nonce-rAnd0mBase64Value';
  object-src 'none';
  base-uri 'none';

이 방식은 서버가 템플릿을 렌더링하는 환경에서 잘 맞는다. 응답을 만들 때마다 새 nonce를 생성해 각 스크립트 태그에 주입할 수 있기 때문이다. web.dev도 서버 렌더링 페이지에서는 nonce 기반 strict CSP를 우선적인 선택지로 설명한다.

hash 기반 CSP는 어떻게 동작하나?

hash 기반 CSP는 인라인 스크립트나 스타일의 내용을 해시해 정책에 넣는다. MDN 기준으로 사용할 수 있는 알고리즘은 sha256, sha384, sha512다. 브라우저는 문서를 받으면 인라인 블록의 내용을 해시하고, 정책에 적힌 값과 일치할 때만 실행을 허용한다.

Content-Security-Policy:
  script-src 'sha256-Base64EncodedHashValue';
  object-src 'none';
  base-uri 'none';

이 방식은 정적으로 배포되는 HTML, 캐시가 중요한 페이지, 빌드 결과물이 고정된 SPA에 잘 맞는다. 대신 스크립트 내용이 공백 하나라도 바뀌면 해시를 다시 계산해야 한다. MDN은 이 때문에 동적 페이지에서는 nonce가 더 관리하기 쉽고, 반대로 정적 페이지에서는 hash가 잘 맞는다고 설명한다.

nonce와 hash 중 무엇을 먼저 고르면 되나?

실무에서는 페이지 생성 방식부터 보면 된다.

서버가 응답마다 HTML을 렌더링한다면 nonce가 보통 더 단순하다.
정적 파일을 CDN에 올리거나 HTML 자체를 오래 캐시해야 한다면 hash가 더 자연스럽다.
인라인 블록 내용이 자주 바뀌면 hash 유지 비용이 커진다.
응답마다 안전한 난수를 생성하고 템플릿에 주입할 수 없다면 nonce 방식은 맞지 않는다.

web.dev는 nonce는 매 응답마다 새 값이 필요하고, hash는 정적 페이지에 더 적합하다고 정리한다. 이 기준은 프레임워크와 무관하게 그대로 적용해도 무리가 적다.

strict-dynamic은 왜 같이 언급되나?

strict-dynamic은 nonce나 hash로 신뢰를 받은 스크립트가 추가로 불러오는 스크립트까지 신뢰를 전파하는 키워드다. MDN과 CSP Level 3는 이 키워드가 있으면 지원 브라우저에서 'self', 호스트 allowlist, 'unsafe-inline' 같은 일부 소스 표현식이 스크립트 로딩 판단에서 무시된다고 설명한다.

Content-Security-Policy:
  script-src 'nonce-rAnd0mBase64Value' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

이 점 때문에 strict-dynamic은 서드파티 로더 스크립트나 런타임에 다른 스크립트를 붙이는 구조에서 자주 같이 나온다. 다만 W3C와 MDN, web.dev 모두 신뢰된 스크립트가 동적으로 붙이는 URL 자체가 공격자 입력에 오염되면 CSP가 그 부분까지 막아주지는 못한다고 경고한다.

지원 브라우저와 하위 호환은 어떻게 보나?

W3C CSP Level 3와 MDN 설명에 따르면 strict-dynamic은 하위 호환을 고려해 함께 배치할 수 있다. 예를 들어 MDN은 script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic' 같은 정책이 CSP1, CSP2, CSP3 지원 수준에 따라 다르게 해석될 수 있다고 설명한다. 즉 최신 브라우저에서는 nonce와 strict CSP 중심으로 동작하고, 오래된 브라우저에서는 제한적으로 fallback이 쓰인다.

다만 fallback을 넣는 목적은 구형 브라우저 대응이지, 최신 브라우저에서 정책을 느슨하게 만들기 위해서가 아니다. 최신 엔진은 strict-dynamic을 이해하면 그에 맞는 우선순위로 정책을 처리한다.

nonce를 쓸 때 주의할 점은?

nonce 값은 응답마다 새로 생성해야 한다.
예측하기 어려운 난수여야 한다.
허용할 요소와 CSP 헤더에 같은 값을 넣어야 한다.
nonce는 <script>와 <style> 같은 요소에 적용하는 방식이다.

MDN은 최근 브라우저에서 nonce 값을 단순한 속성 조회로 숨기는 동작도 설명한다. 이는 CSS 선택자 같은 우회 경로로 nonce가 새어 나가는 위험을 줄이기 위한 동작이다.

hash를 쓸 때 주의할 점은?

해시는 스크립트나 스타일의 실제 내용과 정확히 일치해야 한다.
공백과 줄바꿈 차이도 해시에 영향을 준다.
내용이 바뀌면 해시를 다시 계산해 배포해야 한다.
MDN은 외부 리소스를 해시 기반으로 허용할 때 integrity 속성도 필요하다고 설명한다.

따라서 hash 기반 CSP는 빌드 산출물이 고정돼 있고 배포 파이프라인에서 해시 갱신을 자동화할 수 있을 때 특히 깔끔하다.

FAQ

Q. 정적 React나 Vue 배포 페이지라면 무엇이 더 잘 맞나?

HTML이 정적으로 제공되고 캐시를 적극적으로 쓴다면 hash 기반 CSP가 더 자연스럽다. web.dev는 정적 HTML이나 캐시되는 페이지에서 hash 기반 strict CSP를 대표 사례로 든다.

Q. SSR 페이지에서도 hash를 쓸 수 있나?

가능은 하지만, 인라인 블록이 자주 달라지면 해시 재계산 부담이 커진다. 응답을 매번 렌더링하는 구조라면 nonce가 유지보수상 더 단순한 경우가 많다.

Q. CSP만 있으면 XSS를 막았다고 봐도 되나?

아니다. web.dev는 strict CSP를 XSS 완화에 유용한 방어층으로 설명하지만, 입력 검증과 취약점 수정의 대체재로 보지는 않는다. CSP는 방어 심화 수단으로 보는 편이 맞다.

정리

선택 기준은 복잡하지 않다. 동적으로 렌더링되는 HTML이면 nonce, 정적이거나 오래 캐시되는 HTML이면 hash를 먼저 검토하면 된다. 그리고 런타임에 신뢰된 스크립트가 다른 스크립트를 불러오는 구조라면 strict-dynamic이 왜 같이 나오는지까지 이해해야 정책을 올바르게 읽을 수 있다.

결국 CSP에서 중요한 것은 문법을 외우는 것보다 배포 방식과 빌드 방식을 정책과 맞추는 일이다. 응답마다 값을 주입할 수 있는지, 콘텐츠가 얼마나 자주 바뀌는지, 스크립트 로딩이 정적인지 동적인지를 먼저 보면 nonce와 hash 중 어느 쪽이 맞는지 더 빨리 판단할 수 있다.

참고 자료

Discord에서 Codex를 이어 쓰는 로컬 브리지 만들기

포도알77 — Tue, 5 May 2026 23:14:58 +0900

Discord에서 Codex를 이어 쓰는 로컬 브리지 만들기

Codex를 VS Code에서 쓰다 보면 자리를 옮겼을 때 짧은 지시만 Discord로 이어 보내고 싶을 때가 있다. 핵심 요구사항은 거창하지 않다. 외부에 포트를 열지 않고, Discord의 특정 채널에 쓴 메시지를 현재 Codex 세션으로 전달하고, Codex의 응답을 다시 Discord에서 확인하는 정도면 충분하다.

이 글은 그런 요구를 로컬 브리지로 구현한 과정을 정리한다. 최종 구조는 두 단계로 나뉜다. 먼저 안정적인 기본 경로로 codex exec resume을 붙였고, 그 다음 VS Code에 열려 있는 Codex 패널까지 같이 갱신되도록 설치된 VS Code 확장에 작은 inbox poller를 추가했다.

처음 목표는 외부 노출 없이 이어 쓰기였다

처음부터 웹훅 서버를 공개하거나 터널을 열 필요는 없었다. Discord 봇은 원래 Discord Gateway에 outbound 연결을 유지한다. 따라서 사용자가 Discord에 메시지를 쓰면 봇은 이미 열려 있는 Gateway 이벤트로 메시지를 받을 수 있다. 로컬 머신 쪽에 inbound 포트를 열 필요가 없다.

이 구조에서는 Codex 전용 Discord 채널 하나를 만들고, 그 채널 안에서만 동작하게 제한하는 편이 안전하다. 코드, 파일 경로, 명령 출력, 작업 메모가 대화에 포함될 수 있기 때문에 일반 알림 채널과 분리하는 것이 좋다.

기본 경로: codex exec resume

가장 먼저 붙인 방식은 단순하다. Discord 봇이 최근 Codex 세션 목록을 읽어 드롭다운으로 보여주고, 사용자가 세션을 선택하면 그 세션 ID를 저장한다. 이후 같은 채널에 일반 메시지를 쓰면 봇이 다음 형태로 Codex를 실행한다.

codex exec resume --json --skip-git-repo-check \
  --output-last-message /tmp/last-message.txt \
  <session_id> "<discord message>"

응답은 --output-last-message 파일에서 읽어 Discord에 다시 보낸다. 동시에 봇은 ~/.codex 아래의 세션 JSONL 로그를 polling해서 사용자 메시지와 Codex 응답을 Discord에 backfill하거나 mirror한다.

이 방식은 안정적이다. Codex CLI가 제공하는 공식 실행 경로를 쓰고, Discord 봇도 로컬 파일과 Gateway만 사용한다. 다만 한 가지 한계가 있었다. 이렇게 추가된 턴은 세션 파일에는 남지만, 이미 열려 있는 VS Code Codex 패널이 그 변경을 즉시 live-tail하지는 않았다.

왜 VS Code 패널에는 바로 안 보였나?

설치된 Codex VS Code 확장을 열어보면 구조가 조금 다르다. 확장은 내부에서 codex app-server를 자식 프로세스로 띄우고, webview는 vscode://codex/... 브리지를 통해 그 app-server와 통신한다. 열린 패널의 실시간 화면은 단순히 JSONL 파일을 tail하는 것이 아니라, extension host와 app-server 사이의 notification stream으로 갱신된다.

그래서 외부에서 codex exec resume으로 같은 세션 파일에 기록해도, 현재 열려 있는 VS Code webview에 새 이벤트가 자동으로 broadcast되지는 않는다. 세션 지속성과 현재 UI 스트림은 서로 다른 문제였던 셈이다.

실험 경로: VS Code 확장 inbox poller

열려 있는 VS Code Codex 패널까지 같이 갱신하려면, 같은 extension-owned app-server에 턴을 넣어야 했다. 이를 위해 설치된 Codex VS Code 확장 번들에 아주 작은 hook을 추가했다. Discord 봇은 더 이상 바로 Codex CLI를 실행하지 않고, 로컬 inbox JSONL 파일에 메시지를 한 줄 추가한다.

{
  "id": "timestamp-random",
  "createdAt": "2026-05-05T13:50:00.000Z",
  "threadId": "019df81f-7552-7273-9efc-d5376b66f468",
  "text": "Discord에서 사용자가 보낸 메시지입니다...",
  "source": "discord"
}

패치된 VS Code 확장은 이 inbox를 1초마다 읽고, 처리하지 않은 줄을 app-server로 전달한다. 내부 호출 순서는 다음과 같다.

thread/resume으로 선택한 세션을 app-server에 올린다.
turn/start로 Discord 메시지를 새 사용자 입력으로 보낸다.
처리 offset을 runtime/codex-vscode-inbox.jsonl.offset에 기록한다.
성공과 실패는 runtime/codex-vscode-inbox.log에 남긴다.

이미 해당 thread가 app-server에서 활성 상태라면 thread/resume이 실패할 수 있다. 이 경우에도 hook은 실패를 로그에 남기고 turn/start를 시도한다. 실제로 열린 VS Code 패널에 Discord 메시지가 들어오는지 확인하는 데는 이 fallback이 중요했다.

Discord 쪽 사용자 경험

Discord 채널에서는 !codex 명령으로 세션 선택 패널을 띄운다. Discord의 select menu를 사용하므로 긴 세션 ID를 직접 입력할 필요가 없다. 세션을 선택하면 최근 대화 일부를 채널에 backfill하고, 이후 일반 메시지는 선택된 Codex 세션으로 전달된다.

VS Code bridge 모드가 켜져 있으면 봇은 메시지를 받은 직후 다음처럼 응답한다.

@user VS Code Codex에 전달했습니다.

그 뒤 실제 Codex 응답은 VS Code 패널에서 진행되고, Discord 쪽 mirror는 세션 로그 polling을 통해 따라온다. 즉 Discord는 원격 입력 장치이자 보조 모니터가 되고, VS Code는 여전히 실제 작업 화면으로 남는다.

여러 채널로 동시에 작업하기

처음 구현은 Codex 전용 채널 하나만 바라봤다. 실제로 써보니 작업 주제가 갈라질 때는 채널을 여러 개 두는 편이 훨씬 낫다. 예를 들어 한 채널은 코딩 작업 세션에 묶고, 다른 채널은 리뷰 작업 세션에 묶어두는 식이다.

이를 위해 브리지 상태를 전역 세션 하나가 아니라 채널별 상태 맵으로 바꿨다. 각 Discord 채널은 자신만의 선택된 Codex 세션, JSONL mirror offset, CLI fallback 실행 상태를 가진다. 그래서 두 채널이 서로 다른 Codex 세션에 연결되어도 polling 위치가 섞이지 않고, 한 채널에서 Codex가 처리 중이어도 다른 채널의 작업을 막지 않는다.

DISCORD_CODEX_CHANNEL_ID=첫번째_전용_채널_ID
DISCORD_CODEX_CHANNEL_IDS=두번째_채널_ID,세번째_채널_ID

기존 단일 채널 설정은 그대로 유지했다. 추가 채널이 필요할 때만 DISCORD_CODEX_CHANNEL_IDS에 쉼표로 더 넣으면 된다. 각 채널에서 !codex를 한 번씩 실행해 원하는 세션을 선택하면 그 다음부터는 채널 단위로 독립적으로 이어 쓸 수 있다.

운영 파일과 설정

브리지에 사용한 주요 환경 변수는 다음과 같다.

DISCORD_CODEX_CHANNEL_ID=전용_채널_ID
DISCORD_CODEX_CHANNEL_IDS=추가_채널_ID,또_다른_채널_ID
DISCORD_CODEX_ENABLED=1
DISCORD_CODEX_VSCODE_BRIDGE=1
DISCORD_CODEX_VSCODE_INBOX=/Users/awe/Desktop/servers/discord/runtime/codex-vscode-inbox.jsonl
DISCORD_CODEX_SESSION_LIMIT=10
DISCORD_CODEX_POLL_INTERVAL_MS=3000
DISCORD_CODEX_BACKFILL_LIMIT=12

VS Code 확장 패치는 별도 스크립트로 재적용할 수 있게 했다.

node ./servers/discord/scripts/patch-codex-vscode-bridge.js

이 스크립트는 설치된 확장 파일을 수정하기 전에 백업을 만든다. 확장 업데이트로 패치가 사라지면 스크립트를 다시 실행하고 VS Code를 reload하면 된다.

보안상 주의할 점

이 구성은 외부 inbound 포트를 열지 않는다. Discord 입력은 Gateway 연결로 들어오고, Codex 전달은 로컬 파일과 로컬 VS Code extension host 안에서 처리된다. 그래도 안전하다고 방심하면 안 된다.

Codex 전용 채널은 반드시 비공개로 둔다.
봇은 설정된 채널 ID에서만 Codex 메시지를 처리한다.
Discord로 보내는 mirror에는 token, password, secret 계열 문자열을 마스킹한다.
긴 응답은 Discord 전송 전에 잘라낸다.
VS Code 확장 패치는 공식 API가 아니므로 업데이트 후 재검증한다.

특히 마지막 항목이 중요하다. 설치된 확장 번들을 직접 패치하는 방식은 실험으로는 유용하지만, 장기적으로는 깨질 수 있다. 버전이 올라가면 내부 함수 이름이나 코드 위치가 바뀔 수 있으므로 재패치 스크립트와 rollback 절차를 같이 보관해야 한다.

문제가 생겼을 때 확인할 로그

Discord 봇이 bridge 모드로 떠 있는지는 PM2 로그에서 확인할 수 있다.

pm2 logs discord --lines 80 --nostream

VS Code extension hook이 inbox를 읽고 있는지는 다음 로그를 보면 된다.

tail -80 ./servers/discord/runtime/codex-vscode-inbox.log

정상 시작 시에는 inbox 경로가 기록되고, 메시지를 처리하면 sent 로그가 남는다. 실패하면 resume skipped 또는 failed 로그가 남기 때문에 어느 단계에서 막혔는지 추적할 수 있다.

정리

처음에는 Discord 메시지를 codex exec resume으로 전달하는 것만으로 충분해 보였다. 하지만 VS Code에 열린 현재 Codex 패널까지 자연스럽게 이어 쓰려면, 세션 파일에 쓰는 것과 live UI stream에 넣는 것은 다르다는 점을 분리해서 봐야 했다.

최종적으로는 기본 CLI 경로를 fallback으로 남기고, 실험용 VS Code extension inbox bridge를 추가했다. 이후 채널별 상태를 분리해 여러 Discord 채널에서 서로 다른 Codex 세션을 동시에 이어 쓸 수 있게 했다. 이 방식은 공식 확장 API가 아니므로 유지보수 리스크가 있지만, 로컬 전용 환경에서 Discord를 Codex 입력 장치로 쓰기에는 꽤 실용적이다. 중요한 것은 외부 포트를 열지 않고도, 선택형 UI와 세션 backfill, VS Code 패널 반영까지 한 흐름으로 묶을 수 있다는 점이다.

안전하게 키를 보관하려면 무엇을 봐야 할까? KMS 서비스 선택 기준 정리

포도알77 — Tue, 5 May 2026 21:14:30 +0900

안전하게 키를 보관하려면 무엇을 봐야 할까? KMS 서비스 선택 기준 정리

클라우드에서 암호키를 직접 파일이나 애플리케이션 설정값으로 관리하면 접근 통제, 회전, 감사 기록을 일관되게 유지하기가 어렵다. 그래서 많은 팀이 KMS(Key Management Service)를 사용한다. KMS를 고를 때는 단순히 "암호화가 된다"는 점보다 키가 어디에 저장되는지, 누가 접근할 수 있는지, 회전과 감사가 어떻게 되는지를 먼저 봐야 한다.

이 글은 2026년 5월 5일 기준 AWS KMS, Google Cloud KMS, Azure Key Vault 및 Managed HSM 공식 문서를 바탕으로, 안전하게 키를 보관하기 위해 확인해야 할 기준을 객관적으로 정리한 글이다.

KMS를 볼 때 가장 먼저 확인할 기준은 무엇인가?

실무에서는 아래 다섯 가지를 먼저 보면 서비스 성격이 빠르게 정리된다.

키가 소프트웨어 보호인지, HSM 기반인지
멀티테넌트인지, 싱글테넌트인지
접근 제어가 IAM, 키 정책, RBAC 등 어떤 방식인지
자동 회전과 수동 회전이 어디까지 지원되는지
감사 로그와 지역 고정 같은 운영 요구사항을 충족하는지

같은 "KMS"라는 이름을 써도 지원 범위는 다르다. 어떤 서비스는 키 관리에 집중하고, 어떤 서비스는 secrets나 certificates까지 함께 다룬다. 따라서 기능명을 그대로 비교하기보다 운영 모델을 비교하는 편이 정확하다.

AWS KMS는 어떤 경우에 적합한가?

AWS 문서에 따르면 AWS KMS에는 고객이 직접 생성하고 정책, 회전, 삭제 일정을 제어하는 customer managed key와, AWS 서비스가 계정 안에서 관리하는 AWS managed key, 그리고 AWS 서비스 계정이 소유하는 AWS owned key가 있다. 제어와 감사가 중요하면 customer managed key가 중심이 된다.

AWS KMS는 customer managed key에 대해 키 정책, IAM 정책, grants, alias, rotation, deletion scheduling을 제어할 수 있다고 설명한다. 또한 사용 내역은 AWS CloudTrail에서 감사할 수 있다. 반대로 AWS managed key는 볼 수는 있지만 속성 변경이나 정책 수정, 삭제 예약은 할 수 없고, 자동 회전 주기도 사용자가 바꿀 수 없다.

회전 정책도 확인해야 한다. AWS 문서 기준으로 자동 회전은 대칭 암호화용 customer managed key에서 지원되며, 기본 주기는 1년이고 사용자 정의 일수도 지정할 수 있다. 즉 "키를 AWS에 보관한다"는 사실만으로 충분하지 않고, 어떤 키 유형인지와 누가 수명주기를 관리하는지까지 봐야 한다.

Google Cloud KMS는 무엇이 다른가?

Google Cloud KMS 문서는 보호 수준을 명확하게 구분한다. 기본 소프트웨어 보호인 SOFTWARE, Google 소유 HSM에서 동작하는 HSM, 전용 파티션을 쓰는 HSM_SINGLE_TENANT, 외부 키 관리자와 연결하는 EXTERNAL, VPC 기반 외부 키 연결인 EXTERNAL_VPC가 대표적이다.

이 구조의 장점은 "보호 수준"을 먼저 결정하고 같은 API와 클라이언트 라이브러리 흐름 안에서 운영할 수 있다는 점이다. 공식 문서에는 모든 보호 수준에서 IAM 역할로 접근을 제어하고, 키 작업을 감사 로그로 남길 수 있다고 정리돼 있다. 또 Cloud HSM은 FIPS 140-2 Level 3 검증 HSM을 사용한다고 설명한다.

외부 키가 필요한 조직이라면 EXTERNAL과 EXTERNAL_VPC 차이도 중요하다. Google은 외부 인터넷 경유 방식보다 VPC 기반 방식이 가용성 측면에서 더 유리할 수 있다고 안내한다. 즉 Google Cloud에서는 같은 KMS 안에서도 소프트웨어, 멀티테넌트 HSM, 싱글테넌트 HSM, 외부 키를 단계적으로 선택할 수 있다.

Azure는 Key Vault와 Managed HSM을 어떻게 나눠 봐야 하나?

Azure 문서상 Key Vault는 keys, secrets, certificates를 함께 다루는 서비스다. 반면 Managed HSM은 키 전용 서비스로, secrets와 certificates는 지원하지 않는다. 이 차이부터 이해해야 설계가 깔끔해진다.

Azure Managed HSM 문서는 이 서비스를 fully managed, highly available, single-tenant HSM 서비스라고 설명하며, FIPS 140-3 Level 3 validated HSM을 사용한다고 밝힌다. 또 각 인스턴스는 고객별 보안 도메인으로 격리되고, 로컬 RBAC 모델과 Azure Monitor 기반 감사 기능을 제공한다고 설명한다.

정리하면 Azure에서 "키만 강하게 보호"가 목표라면 Managed HSM을, 키 외에 secrets와 certificates까지 함께 다뤄야 하면 Key Vault를 먼저 검토하는 구조다. 다만 Managed HSM은 소프트웨어 보호 키나 secrets 저장소의 대체재가 아니라는 점을 구분해야 한다.

안전한 키 보관 관점에서 어떤 선택이 합리적인가?

규제 요구가 크지 않고 클라우드 네이티브 서비스와 빠르게 연동하는 것이 우선이면 소프트웨어 보호 키나 기본 KMS 기능으로 시작하는 경우가 많다. 반대로 HSM 요구사항, 싱글테넌시, 외부 키 주권, 세밀한 감사 추적이 중요하면 HSM 또는 외부 키 관리 기능을 먼저 검토해야 한다.

다음처럼 나누면 판단이 쉬워진다.

운영 단순성이 우선이면: 클라우드 기본 KMS와 customer managed key 또는 기본 vault 모델
키 보호 수준 강화가 우선이면: HSM 기반 옵션
테넌트 분리가 중요하면: single-tenant HSM 계열
키를 클라우드 밖에서 통제해야 하면: external key management 계열
키 외에 secrets, certificates 관리도 필요하면: Azure Key Vault처럼 객체 범위가 넓은 서비스 검토

FAQ

Q. KMS만 쓰면 애플리케이션의 모든 비밀번호와 인증서를 한 곳에 보관할 수 있나?

서비스마다 다르다. Azure Key Vault는 keys, secrets, certificates를 지원하지만, Azure Managed HSM은 키만 지원한다. Google Cloud KMS 문서는 키 보호 수준과 키 작업에 초점이 있고, AWS KMS 문서도 키 관리 중심으로 설명한다. 따라서 "KMS"라는 이름만 보고 secrets 저장 기능까지 있다고 가정하면 안 된다.

Q. 자동 회전이 되면 기존 데이터를 다시 모두 암호화해야 하나?

AWS KMS 문서는 키 회전이 현재 키 재료를 바꾸는 것이지, 기존에 보호한 데이터를 다시 암호화하는 동작은 아니라고 설명한다. 회전 후에도 AWS KMS는 기존 암호문을 복호화할 때 맞는 키 재료를 자동으로 사용한다. 다른 클라우드도 회전 방식은 서비스별 문서를 따로 확인하는 편이 안전하다.

Q. HSM이면 무조건 더 좋은가?

보호 수준과 규제 대응 측면에서는 장점이 있지만, 비용과 운영 제약도 함께 본다. 공식 문서만 놓고 보면 HSM 계열은 대체로 더 높은 보호 수준과 격리 모델을 제공하지만, 모든 워크로드에 반드시 필요한 것은 아니다. 요구사항 없이 HSM을 선택하는 것보다 접근 통제, 회전, 감사 요구를 먼저 정리하는 편이 합리적이다.

정리

안전하게 키를 보관하려면 서비스 이름보다 운영 모델을 봐야 한다. AWS KMS는 고객 관리 키와 회전 정책 통제가 강점이고, Google Cloud KMS는 보호 수준 선택 폭이 넓으며, Azure는 Key Vault와 Managed HSM의 역할이 분명하게 나뉜다. 결국 핵심은 HSM 여부, 테넌시, 접근 제어, 회전, 감사 로그, 외부 키 요구사항을 기준으로 선택하는 것이다.

참고 자료

[크롤링] 데이터 수집을 위한 크롤링 7편 : HTTP 429 Too Many Requests와 Retry-After 이해하기

포도알77 — Tue, 5 May 2026 16:33:37 +0900

[크롤링] 데이터 수집을 위한 크롤링 7편 : HTTP 429 Too Many Requests와 Retry-After 이해하기

웹 크롤링이나 API 수집 중 HTTP 429 Too Many Requests가 나오면, 가장 먼저 봐야 할 것은 서버가 정한 요청 한도와 Retry-After 헤더다. IETF RFC 6585는 429 상태 코드를 2012년 4월에 정의했고, RFC 9110은 Retry-After 헤더의 문법과 의미를 설명한다.

핵심은 단순하다. 429는 일정 시간 동안 요청을 너무 많이 보냈다는 뜻이고, Retry-After가 있으면 그 값만큼 기다린 뒤 다시 시도해야 한다. 크롤러를 설계할 때는 이 응답을 오류로만 취급하지 말고, 요청 속도를 조절하라는 명시적 신호로 해석하는 편이 맞다.

HTTP 429는 정확히 무엇을 의미하나?

RFC 6585 4장에 따르면 429는 사용자가 일정 시간 안에 너무 많은 요청을 보냈을 때 사용하는 상태 코드다. 흔히 말하는 rate limiting 상황을 표현하기 위해 만들어졌으며, 서버는 응답 본문에 제한 사유를 설명할 수 있고 Retry-After 헤더를 함께 보낼 수 있다.

이 표준은 서버가 사용자를 어떤 기준으로 식별하는지까지 정하지는 않는다. 즉 서버는 IP, 인증된 계정, 쿠키, 특정 리소스별 카운터, 혹은 여러 서버를 묶은 전체 정책으로 요청 수를 계산할 수 있다. 따라서 같은 사이트라도 페이지마다 제한 방식이 다를 수 있다.

Retry-After 헤더는 어떻게 읽어야 하나?

RFC 9110 10.2.3절에 따르면 Retry-After 값은 두 가지 형식 중 하나다. 하나는 HTTP 날짜이고, 다른 하나는 지연 초 수다. 예를 들어 Retry-After: 120이면 응답을 받은 뒤 120초를 기다리라는 뜻이고, 날짜 형식이면 그 시각 이후에 다시 요청하라는 뜻이다.

RFC 9110은 이 헤더를 원래 3xx와 503 응답에서 설명하지만, RFC 6585는 429 응답에도 Retry-After를 포함할 수 있다고 규정한다. 실무에서는 429와 함께 초 단위 값이 오는 경우가 많지만, 날짜 형식도 처리할 수 있게 구현하는 편이 안전하다.

429와 503은 무엇이 다른가?

429는 보통 클라이언트의 요청 빈도가 정책 한도를 넘었다는 뜻이고, 503은 서버가 일시적으로 요청을 처리할 수 없다는 뜻이다. 둘 다 Retry-After를 가질 수 있지만, 429는 과도한 요청 제어에, 503은 서비스 장애나 점검 같은 일시적 불가 상태에 더 가깝다.

크롤링 관점에서는 429를 받았을 때 먼저 요청 간격, 동시성, 재시도 정책을 조정해야 한다. 반대로 503이 반복되면 서버 상태나 점검 공지를 함께 확인하는 편이 해석에 더 적합하다.

크롤러에서 바로 적용할 수 있는 대응 원칙

Retry-After가 있으면 그 값을 우선 적용한다.
헤더가 없으면 즉시 반복 재시도하지 말고 보수적인 대기 시간을 둔다.
동시 요청 수와 초당 요청 수를 함께 낮춘다.
같은 URL만이 아니라 같은 도메인 전체의 호출 속도를 함께 본다.
429 응답을 성공처럼 무시하지 말고 로그에 남겨 한도 정책을 추적한다.

왜 지수 백오프가 자주 쓰이나?

429는 서버가 이미 부담을 느끼고 있다는 신호이므로, 짧은 간격의 고정 재시도는 같은 문제를 반복할 가능성이 크다. 그래서 재시도 간격을 점차 늘리는 지수 백오프가 많이 쓰인다. 다만 이 방법도 서버가 명시한 Retry-After 값이 있을 때는 그 값보다 앞서면 안 된다.

1회차 실패: 60초 대기
2회차 실패: 120초 대기
3회차 실패: 240초 대기

위와 같은 방식은 예시일 뿐이며, 실제 대기 시간은 대상 서비스의 문서나 응답 헤더를 우선해야 한다. 공식 한도 문서가 있다면 그 기준이 가장 신뢰할 만하다.

간단한 예시 응답

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600

이 경우 RFC 6585 기준으로는 일정 시간 내 요청이 너무 많았다는 뜻이고, Retry-After: 3600은 3600초 뒤에 다시 시도하라는 의미다. 같은 자원에 즉시 재요청을 보내면 동일한 제한에 다시 걸릴 가능성이 높다.

FAQ

Q. 429를 받으면 바로 프록시나 IP 변경으로 우회해도 되나?

이 글은 우회 방법을 다루지 않는다. 크롤링 실무에서는 우회보다 먼저 대상 서비스의 이용 정책, robots.txt, 공개 문서, 응답 헤더를 확인하고 요청 속도를 조정하는 것이 기본이다.

Q. Retry-After가 없으면 몇 초를 기다려야 하나?

표준은 429에 반드시 Retry-After를 넣으라고 강제하지 않는다. 헤더가 없다면 서비스 문서의 rate limit 설명을 먼저 보고, 문서가 없으면 보수적인 대기 시간과 낮은 동시성으로 다시 시도하는 편이 안전하다.

Q. 429 응답은 캐시에 저장될 수 있나?

RFC 6585는 429 응답이 캐시에 저장되어서는 안 된다고 명시한다. 따라서 중간 캐시 동작을 기대하기보다 클라이언트 쪽 재시도 정책을 올바르게 설계하는 것이 중요하다.

정리

429는 크롤러가 실패했다는 뜻만이 아니라, 현재 속도가 서버 정책과 맞지 않는다는 뜻이다. Retry-After를 읽고, 요청 간격과 동시성을 낮추고, 공식 문서가 있으면 그 한도를 기준으로 재시도 정책을 잡는 것이 가장 기본적인 대응이다.

참고 자료

[크롤링] 데이터 수집을 위한 크롤링 6편 : robots.txt와 robots 메타 태그 이해하기

포도알77 — Tue, 5 May 2026 16:18:01 +0900

[크롤링] 데이터 수집을 위한 크롤링 6편 : robots.txt와 robots 메타 태그 이해하기

웹 크롤링을 시작할 때 가장 먼저 확인할 항목은 /robots.txt와 문서의 robots 제어 정보다. 2022년 9월 표준화된 IETF RFC 9309는 robots.txt의 기본 동작을 정의하고, Google Search Central 문서는 robots 메타 태그와 X-Robots-Tag가 색인과 검색 노출을 어떻게 제어하는지 설명한다.

핵심은 역할 구분이다. robots.txt는 크롤러가 어떤 URL을 가져가도 되는지에 관한 접근 규칙이고, robots 메타 태그는 HTML 페이지를 읽은 뒤 그 페이지를 색인하거나 스니펫으로 노출할지에 관한 규칙이다. 따라서 데이터 수집 자동화를 설계할 때는 두 장치를 같은 기능으로 보면 안 된다.

robots.txt는 무엇을 하는가?

RFC 9309에 따르면 robots.txt는 서비스 최상위 경로의 /robots.txt 파일로 제공되며, 크롤러는 여기에 선언된 User-agent, Allow, Disallow 규칙을 해석한다. 가장 구체적으로 일치하는 경로 규칙이 우선되고, 같은 길이의 충돌에서는 Allow가 우선될 수 있다.

이 파일의 목적은 자동 클라이언트의 접근 범위를 알리는 것이다. RFC 9309는 이것이 인증이나 보안 장치가 아니라고 명시한다. 공개 URL을 숨기고 싶다면 인증, 권한 제어, 네트워크 제한 같은 실제 접근 통제가 별도로 필요하다.

robots 메타 태그와 X-Robots-Tag는 무엇이 다른가?

Google Search Central 문서에 따르면 robots 메타 태그는 HTML <head> 안에 넣어 페이지 단위로 색인과 노출 방식을 제어한다. 대표적으로 noindex, nofollow, nosnippet 같은 값을 사용할 수 있다.

HTML이 아닌 PDF, 이미지, 기타 바이너리 리소스에는 메타 태그를 넣을 수 없으므로 HTTP 응답 헤더 X-Robots-Tag를 사용한다. 즉 HTML 페이지면 메타 태그, 비HTML 리소스면 헤더가 기본 선택지다.

크롤링 실무에서 자주 헷갈리는 지점은?

1. robots.txt 차단은 비공개 처리가 아니다

Google은 robots.txt가 주로 크롤링 트래픽 관리를 위한 장치이며, 페이지를 검색 결과에서 완전히 숨기는 수단이 아니라고 설명한다. 검색 노출 자체를 막고 싶다면 noindex 또는 인증이 필요하다.

2. noindex는 페이지를 읽을 수 있어야 해석된다

Google 문서에는 robots 메타 태그는 크롤러가 해당 페이지에 접근할 수 있을 때만 읽고 따를 수 있다고 적혀 있다. 따라서 같은 URL을 robots.txt로 막아 두면 크롤러가 페이지 내용을 읽지 못해 메타 태그도 확인하지 못할 수 있다.

3. 서비스별 해석은 완전히 같지 않을 수 있다

RFC 9309는 robots.txt의 공통 규칙을 정의하지만, robots 메타 태그나 확장 지시어는 검색엔진마다 지원 범위가 다를 수 있다. Google도 일부 규칙은 다른 검색엔진에서 동일하게 처리되지 않을 수 있다고 안내한다. 운영 환경에서는 대상 서비스의 공식 문서를 직접 확인해야 한다.

최소 점검 순서

수집 대상 도메인의 /robots.txt를 열어 허용 범위를 먼저 확인한다.
수집하려는 상세 페이지의 <head> 또는 응답 헤더에 robots 관련 지시어가 있는지 본다.
검색 노출 제어와 접근 제어를 구분해서 해석한다.
문서에 금지나 제한이 있으면 우회하지 말고 수집 범위를 조정한다.

예시로 보면 더 쉽다

User-agent: *
Disallow: /private/
Allow: /private/public-report.html

위 예시는 모든 크롤러에 대해 /private/ 아래를 막되, 더 구체적인 /private/public-report.html은 허용하는 형태다. RFC 9309 기준으로는 더 구체적인 경로가 우선 적용된다.

<meta name="robots" content="noindex, nofollow">

이 메타 태그는 HTML 페이지가 검색 결과에 나타나지 않도록 요청하고, 그 페이지의 링크를 따라가지 않도록 지시하는 예시다. 다만 이 지시를 읽으려면 크롤러가 페이지 자체에는 접근할 수 있어야 한다.

FAQ

Q. robots.txt만 설정하면 검색 결과에서 사라지나?

아니다. Google은 검색 결과 제외 목적이라면 noindex 또는 인증을 사용하라고 안내한다. robots.txt는 기본적으로 접근 규칙이다.

Q. PDF에도 noindex를 넣을 수 있나?

HTML 메타 태그는 넣을 수 없지만, Google 문서 기준으로는 HTTP 응답 헤더 X-Robots-Tag를 사용해 비HTML 리소스에 규칙을 줄 수 있다.

Q. 크롤링 전에 무엇을 문서화하면 좋은가?

대상 사이트의 robots.txt 확인 시각, 적용된 주요 규칙, 페이지별 robots 지시어 여부를 남겨 두면 나중에 수집 범위를 설명하거나 수정할 때 도움이 된다.

정리

robots.txt는 URL 접근 규칙, robots 메타 태그와 X-Robots-Tag는 색인 및 검색 노출 규칙이라고 분리해서 이해하면 실수가 크게 줄어든다. 크롤링 자동화는 기술 구현보다도 먼저 공식 규칙을 읽고 존중하는 절차가 필요하다.

참고 자료

포토리움: 개인용 로컬 사진/동영상 서버 (무료)

포도알77 — Tue, 7 Oct 2025 17:23:55 +0900

Photorium: 내 PC의 사진과 동영상을 위한 개인 미디어 서버 만들기

무료 미디어 서버 Photorium를 소개합니다. (아직 테스트 버전 입니다)

주저리..는 심심하시면 읽어 보세요. 제미나이가 썼습니다.

왜 만들었을까?

여러분도 PC에 흩어져 있는 수많은 사진과 동영상 파일 때문에 정리에 어려움을 겪은 적 없으신가요? 저 역시 스마트폰으로 찍은 사진, 인터넷에서 다운로드한 이미지, 그리고 소중한 동영상들이 여러 폴더에 뒤죽박죽 섞여 있었습니다. 클라우드 서비스는 편리하지만 월별 비용이 부담스럽고, 개인적인 사진을 외부에 저장하는 것이 왠지 모르게 찜찜하게 느껴졌습니다.

그래서 결심했습니다. "내 PC에서 직접 실행되는, 나만의 간단한 미디어 서버를 만들어보자!" 그렇게 Photorium 프로젝트가 시작되었습니다.

Photorium: 주요 기능 소개

Photorium은 복잡한 설치 과정 없이, 실행 파일(photorium.exe) 하나로 모든 것을 해결할 수 있도록 설계되었습니다.

1. 직관적인 GUI 컨트롤러

!GUI 컨트롤러

프로그램을 실행하면, 서버의 상태를 한눈에 볼 수 있는 컨트롤러 창이 나타납니다. 버튼 하나로 웹 페이지를 열거나, 서버를 재시작하고, 실시간으로 접속 로그를 확인할 수 있어 편리합니다.

2. 폴더 기반의 유연한 컬렉션 관리

컬렉션 관리

PC에 있는 어떤 폴더든 '컬렉션'으로 추가할 수 있습니다. '사진' 폴더, '다운로드' 폴더, 심지어 외장 하드에 있는 폴더까지, 원하는 모든 미디어를 Photorium에서 한 번에 관리할 수 있습니다.

3. 날짜순으로 정렬되는 아름다운 갤러리

갤러리

추가된 모든 컬렉션의 사진과 동영상은 촬영된 날짜(수정 날짜 기준)에 따라 자동으로 그룹화되어 표시됩니다. 스크롤을 내리며 과거의 추억을 시간 순서대로 감상하는 재미를 느껴보세요. 동영상은 첫 프레임이 썸네일로 자동 생성되어 어떤 영상인지 쉽게 알아볼 수 있습니다.

4. 숨겨진 정보까지, 상세 메타데이터 뷰어

사진을 클릭하면 단순한 이미지뿐만 아니라, 그 안에 담긴 풍부한 정보를 확인할 수 있습니다.

기본 정보: 해상도, 파일명
촬영 정보: 카메라 모델
위치 정보: GPS 데이터가 있다면, "경기도 용인시 수지구"와 같이 실제 주소로 변환하여 보여줍니다.

어떤 기술을 사용했을까?

Photorium은 다음과 같은 기술 스택으로 만들어졌습니다.

백엔드: Flask (Python)
웹 서버: Waitress
이미지/동영상 처리: Pillow, OpenCV
GPS 주소 변환: geopy
프론트엔드: HTML, CSS, JavaScript (Vanilla JS)
GUI: Tkinter (Python 기본 라이브러리)
실행 파일 패키징: PyInstaller

특히, 멀티 스레드 환경에서 여러 요청이 동시에 파일에 접근할 때 발생할 수 있는 데이터 유실 문제를 threading.Lock을 사용하여 해결하는 과정이 기억에 남습니다.

마치며

Photorium은 제 개인적인 필요에서 시작된 작은 프로젝트지만, 개발 과정에서 웹 서버, 데이터 처리, GUI 프로그래밍 등 많은 것을 배우고 경험할 수 있었습니다. 누군가에게는 복잡한 클라우드 서비스의 좋은 대안이, 또 다른 누군가에게는 자신만의 프로그램을 만들어보는 데 영감을 주는 계기가 되었으면 합니다.

프로젝트의 전체 소스 코드는 아래 GitHub 저장소에서 확인하실 수 있습니다. 여러분의 피드백과 기여는 언제나 환영입니다!

GitHub 저장소: https://github.com/ChangdaeJeong/photorium

긴 글 읽어주셔서 감사합니다!

왜 만듬?

(1) 아이폰, 갤럭시, 카톡, 다운로드 이미지 전부 이름 달라서 정리 안됨..

(2) 정리가 안되니까, 하드에만 쳐박아두고 사진을 안봄

(3) 클라우드 쓸라니까 돈 아까움. (집에 외장 하드 하나씩은 다 있잖아?)

특징

(1) 외부 서버와 통신 없음

(2) PC내 저장장치 사용

다운 방법

exe 다운로드 링크 : https://github.com/ChangdaeJeong/photorium/releases/download/v1.0.0/Photorium.exe

(v1.0.0 버전임)

실행 방법

(1) Photorium 실행 (위험성 어쩌고 저쩌고는 그냥 무시)

(2) Open Photorium 클릭

(3) 127.0.0.1:5000 사이트 접속

(4) Your Collections의 Browse & Add.. 클릭

(5) 사진/동영상 있는 위치 추가

* 드라이브 변경: 좌상단 드라이브 버튼 클릭

* 사진/동영상 있는 위치 이동 후 Select This Folder 클릭

* 우측 숫자는 이미지(파랑), 비디오(주황) 갯수를 뜻함

(6) 갤러리 이동 (View Full Gallery 클릭)

(7) 즐기기

미리 보기/ 확대/ 영상 재생/ 메타 데이터 보기 됨

다음 기능은?

(1) 즐겨찾기

(2) 한글 지원?

타오위안 국제공항 토스 현금 인출

포도알77 — Fri, 4 Jul 2025 12:12:09 +0900

토스 외화 계좌 개설 후 뽑으면 됨
해외 신용카드, 인출, 약정 계좌

만약 에러코드 4301을 만난다면 비밀번호가 틀림거임
4자리+00으로 6자리 입력하자

I2S의 bclk, lrclk 출력 시점

포도알77 — Sun, 22 Dec 2024 18:54:55 +0900

(1) BCLK과 LRCLK의 발생 타이밍

클럭 정보를 얻는 단계 (hw_params):
- hw_params()는 ALSA ASoC 계층에서 PCM 정보를 전달 받는 단계임.
- 이 단계에서 샘플링 레이트, 채널 수, 샘플 크기 패러미터를 바탕으로 정확한 BCLK, LRCLK 정보를 생성함.
  - 예를 들어 BCLK = Rate * Channel * Bit per sample, LRCLK = Rate
- set_sysclk에서도 동일하게 설정할 수 있을 것으로 보이는데, 일반적으로 set_sysclk에서는 더 일반적인 범위의 클럭을 설정한다고 함. (예를 들어 PLL 설정이나 클럭 소스 설정)
클럭 발생 시점:
- BCLK, LRCLK 모두 오디오 데이터가 흐르는 순간(dma 전송 준비 완료 후 trigger 호출 시점)에 같이 출력됨 (이론)
  - 하지만 대부분의 audio codec들은 bclk을 base clock으로 사용하므로, 실제 데이터와 clk이 같이 들어오면 데이터가 누락될 가능성이 높음.
  - 따라서 일반적으로 bclk 출력이 먼저 발생됨. (얼마나 빨리 줄 것인가는 Audio codec datasheet을 기반으로하는 구현 또는 tuning의 영역으로 보임)
- 일부 ASoC에서는 소비 전류의 이유로 hw_params에서 클럭을 출력하지 않고, 실제 데이터가 흐르는 그 직전까지 클럭을 출력하지 않도록 할 수 있음. Q사의 qchannel 컨트롤

(2) Audio 출력시 audio if의 ops 호출 순서

startup(): 오디오 스트림을 위한 리소스 초기화.
set_sysclk(): 시스템 클럭 설정 (필요한 경우).
set_fmt(): DAI 포맷(I2S, RJ, LJ 등) 설정.
set_tdm_slot(): TDM 모드 슬롯 구성 (필요한 경우).
hw_params(): 스트림 파라미터 설정(샘플링 레이트, 포맷, 채널 수 등).
prepare(): 데이터 전송 준비(FIFO 리셋, 클럭 활성화).
trigger() (START): DMA 활성화 및 데이터 전송 시작.
pointer(): 현재 재생/수신 포인터 반환 (주기적으로 호출).
trigger() (STOP): DMA 비활성화 및 데이터 전송 종료.
shutdown(): 스트림 종료 후 리소스 해제.

pinctrl-names과 pinctrl

포도알77 — Tue, 22 Oct 2024 22:03:39 +0900

1. GPIO

일반적으로 하나의 gpio 핀은 여러 기능을 수행할 수 있다. 예를 들면 UART, I2C, SPI 등, 설정 가능한 여러 기능이 있으며 현재의 configuration에 맞게 동작한다.

설정할 수 있는 값은 일반적으로 아래와 같다.

(1) 기능(인터페이스) 설정 : i2c, i2s, spi, uart등

(2) 핀 설정 : pull up/down, value 설정등

(3) 그룹 설정, 핀들을 모아 특정 인터페이스를 세팅

2. GPIO configuration

GPIO 설정은 당연히 kernel pinctrl driver를 통하여 하나씩 설정할 수 있다. 일반적으로 enable이나 interrupt 핀의 경우, driver에서 gpio를 컨트롤하는 방식을 많이 사용한다.

하지만 여러개의 핀을 한번에 설정하는 동작이나 suspend, resume과 같이 특정 기능에 콜백으로 처리하는 경우도 생각한다면, driver에서 하나씩 하나씩 설정하는 것은 썩 좋지 못한 방법이다.

3. pinctrl-names

다수의 configruation을 일괄로 처리하기 위한 방법으로 pinctrl-names를 고려해볼 수 있다. device tree를 통하여 여러개의 configuration을 생성해두고, 각 configuration마다 name을 부여한 다음, driver에서는 단순히 name을 호출하는 방식으로 처리하는 것이다.

예를 들어 아래와 같이 default와 sleep 이라는 이름을 정의하면, 각각의 이름은 pinctrl-0과 pinctrl-1에 대응된다.

&uart1 {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&uart1_pins_default>;
    pinctrl-1 = <&uart1_pins_sleep>;
};

그리고 device driver에서는 아래와 같이 pinctrl 정보를 얻어, name으로 일괄 설정을 할 수 있게 된다.

struct device *dev = 어딘가
struct pinctrl *pinctrl;
struct pinctrl_state *default_state;

pinctrl = devm_pinctrl_get(dev);
if (IS_ERR(pinctrl)) {
    dev_err(dev, "Failed to get pinctrl\n");
    return PTR_ERR(pinctrl);
}

default_state = pinctrl_lookup_state(pinctrl, "default");
if (IS_ERR(default_state)) {
    dev_err(dev, "Failed to look up 'default' state\n");
    return PTR_ERR(default_state);
}

pinctrl_select_state(pinctrl, default_state);

4. 별개로 알아두면 좋은 것들

핀컨트롤 커널 링크: https://www.kernel.org/doc/Documentation/pinctrl.txt

핀컨트롤 커널 레포: https://github.com/torvalds/linux/blob/master/drivers/pinctrl/core.c#L1048

pinctrl은 create_pinctrl이 호출될 때 device 정보를 같이 받으며, 해당 device의 np으로 pinctrl-names와 pinctrl-0,..를 파싱해서 pinctrl_list에 저장해둔다.

따라서 장치의 pinctrl을 찾으려면, devm_pinctrl_get을 이용할 수 있다. 이 함수는 pinctrl_list에 저장되어 있는 항목 중 device가 동일한 pinctrl을 리턴한다.

struct pinctrl *devm_pinctrl_get(struct device *dev)

그리고 create_pinctrl시에 device의 pinctrl은 pinctrl-0, ... , N의 property로 길이를 측정한다. 정확히는 0부터 계속해서 찾아나가는 형태이며, 이에 대응되는 names가 없는 경우, 해당 숫자가 이름으로 설정된다.

예를 들어 아래와 같이 pinctrl-0~4번까지 있지만, names는 2개밖에 없는 경우는 "default", "sleep", "2" ,"3" 과 동일하다.

그리고 pinctrl-3과 같이 아무것도 없는 경우 dummy state로 생성되어 매핑된다.

물론 3번에 해당되는 names를 안부르면 그만이지만, 정말 삭제하고자 한다면 delete property를 이용해야 한다.

&uart1 {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&uart1_pins_default>;
    pinctrl-1 = <&uart1_pins_sleep>;
    pinctrl-2 = <&uart1_pins_idle>;
    pinctrl-3;
};

create_pinctrl https://github.com/torvalds/linux/blob/master/drivers/pinctrl/core.c#L1048C24-L1048C38

pinctrl_dt_to_map https://github.com/torvalds/linux/blob/master/drivers/pinctrl/devicetree.c#L182

갑자기 샤워 온수가 안나올 때 & 수압이 약해졌을 때

포도알77 — Sat, 20 May 2023 19:41:52 +0900

1. 수압이 약해졌을 때

주거의 종류(아파트, 빌라, 주택..)에 따라 다르겠지만, 우선 옥외와 옥내로 구분해서 생각해야 한다.

옥외와 옥내를 구분하는 포인트는 바로 아래의 수도 계량기이다.

수도 계량기 사진이 포함된 뉴시스의 기사, 출처 https://mobile.newsis.com/view.html?ar_id=NISX20220502_0001856675

댁내에서 나오는 모든 물은 여기를 지나게 되며, 외부에서 바로들어오는 물이라고 하여 직수라고도 부른다.

당연하게도 직수는 열을 가하지 않은 물이다. 즉, 집에서 찬물을 틀었을 때 나오는 물이 직수이다. 반면 따뜻한 물은 이 직수가 보일러를 거쳐서 나오게 된다. 따라서 별도의 수압 펌프를 달지 않았다면, 따뜻한 물은 찬물보다 수압이 약하다.

다시 한번더 정리하자면, 대충 우리가 쓰는 물은 아래와 같이 연결되어 있다고 보면 된다. 대략적으로 아래와 같이 연결되었다는 거지, 무조건 저렇다는건 아니다. 정말 개인 집의 배관이 궁금하다면, 각 집의 배관도면을 구해다가 보면 된다.

이제부터는 배관의 흐름에 따라 문제가 될 만한 부위를 짚어본다.

1) 옥외 인입 수압의 저하

집에 찬물을 틀어보자. 댁내 모든 찬물 수도꼭지에서 수압이 낮아졌다면, 인입되는 물의 수압이 약해진 경우이다.

실제로는 굉장히 드문 케이스이므로, 아닐 것이라고 판단하고 넘기는 편이 좋다.

아파트라면 지하의 배관실, 빌라나 주택이라면 상수도관을 의심해볼 수 있고, 각 아파트 사무실이나, 빌라라면 관리 업체, 주택이라면 상수도에 연락하여 확인을 요청할 수 있다.

2) 수도 계량기측 감압 밸브 (혹은 수도꼭지)의 고장

이제 수도 계량기 안쪽의 배관을 차례로 확인할 차례인데, 위의 수도 계량기가 있는 곳을 열어봐야 한다. 배관에 좌, 우측 어디든 밸브(수도꼭지) 혹은 감압 밸브가 달려 있을 것이다. 밸브나 감압 밸브의 압력을 조금씩 변경해서 수압의 변화가 생기는지 확인해보자.

만약 변화가 있다면, 해당 부품의 문제이다. 일반적으로 계량기를 넘어 들어오는 배관은 각 세대에서 처리하는 것이 맞다.

물론 감압 밸브가 없을 수도 있다.

3. 배관 자체의 문제인 경우

정말 최악의 케이스로, 콘트리트 아래에 묻혀있는 배관이 잘 못 되었을 경우이다. 각 배관을 연결하거나, 분배하는 부품에 이물질, 녹등으로 막힌 케이스가 있을 수 있다. 또한 배관 자체가 잘못되어 터져서 누수가 되고 있다거나 할 수도 있다.

물론 대부분의 경우는 1) 케이스와 마찬가지로 여기에 해당되지 않는다.

정~말 다 찾아보고 나서도 답이 안나온다면, 그때되어서 이것을 의심해도 되겠다. 확인을 위해서는 누수, 배관을 전문적으로 하는 업체를 불러 체크해야하며, 최악의 경우 바닥을 깨고 배관을 실제 교체한다거나.. 할 수 있다.

4. 수전의 문제

대부분 이 케이스이다. 수전의 구조상 필터류가 막혔거나, 수전 배관쪽이 막혔다던가 (수도 배관에 비해 관로가 좁고 극단적으로 꺾여있는 경우가 많음) 하여 수전 교체가 필요한 케이스.

수전의 대부분은 수압을 조절하는 수도꼭지가 별도로 존재하는데, 해당 꼭지를 조작하여 정상적으로 수압이 변경되는지 확인하고 만약 충분한 수압을 만들어 낼 수 있다면 그대로 사용하면 되겠다.

만약에 수도꼭지를 모두 풀었는데도 수압이 부족하다면, 수전을 분리하여 수전 문제인지 여부를 확실히 해볼 수 있다. 이 경우는 수전을 분해할 수 있는 몽키스페너등이 있어야하며, 수도 계량기의 수도꼭지를 잠그고 수전을 분리한 다음, 다시 수도 계량기의 수도꼭지를 풀어 실제 수압이 정상적으로 토출되고 있는지 확인한다.

2. 온수가 안나올 때 (온수의 수압이 약할 때)

앞서 언급한 배관들을 따라가보면 온수의 시작은 보일러이다. 따라서 보일러부터 수도꼭지까지 흐름을 생각하면서 점검이 필요한 부위를 확인해보자.

1) 보일러 인입 수압이 약한 경우

인입 수압이 약한 경우는 앞서 언급한 수압이 약한 경우 1), 2), 3)을 체크하여 보일러까지 오는 물의 수압이 강한지 확인한다. 특정 경우에는 보일러 인입 배관에 감압 밸브가 달려 있는 경우가 있으니, 감압 밸브를 체크하자

2) 보일러 온수의 토출 수압이 약한 경우

보일러에 따라 다르지만, 직수의 수압으로 데우는 방식과 모터로 수압을 추가하여 밀어내는 방식이 있다. 이는 보일러 업체에 문의해보아야 한다. 대부분의 경우 모델명을 알려주면 어느 방식인지 알려준다.

추가적으로 온수 토출 배관에 감압 밸브를 다는 경우도 있다. 이 경우는 감압 밸브 동작 여부를 확인하자.

3) 배관 문제인 경우

만약 일부 수전에서만 온수의 수압이 낮아진 경우, 혹은 앞서 말한 두 경우가 아닌데도 불구하고 전체 온수 수압이 낮아진 경우이다. 이는 앞서 언급한 수압이 약해졌을 때 3) 배관 문제인 경우와 동일하다.

4) 수전 문제인 경우

마찬가지다 수압이 약해졌을 때 4) 수전 문제인 경우와 동일하다. 대부분은 이 케이스이니 이것부터 확인하는 것도 방법이다.

3. 온수가 안나올 때 (온수 수압은 괜찮은데 뜨겁지 않을 때)

그냥 보일러 문제이다. 뭐 여러가지 경우가 있겠지만, 찾아본 바 5~10년 정도된 보일러에서 가장 빈번하게 발생하는 문제는 삼방 밸브이다. 이건 보일러의 어디가 고장이 아니고를 떠나서 그냥 보일러 업체를 부르자.

4. 근데 사실

내 경우는 화장실 샤워 수전의 뜨거운 물 수압이 약한 케이스였다. 느끼기에는 찬물을 포함한 모든 수압이 낮아진 것 같은데 관련 업체나 점검시에는 자기네들은 이상이 없단다.

결국 수전을 분리하다 못해 수전을 벽의 밸브에서 완전히 떼어내어 확인해보니, 뜨거운 물만 졸졸졸 나오는 상태. 세면대나 싱크대, 세탁실의 뜨거운 물은 잘 나온다.

그렇다면 배관 문제로 밖에 볼 수 없는데, 집이 3년이내의 신축인 점이나 누수로 인한 흔적이 없는 점을 감안했을 때, 화장실로 인입된 다음 분배되는 위치에서 문제라고 밖에 볼 수 없었다.

실제 정확한 수리를 위해서는 배관을 확인해야 하므로, 화장실을 뿌개는 방법 밖엔 없었는데..., 수전을 분해하고 다시 결합하면 또 괜찮아진다. 그러곤 수전을 다시 결합하고 하루 이틀지나면 수압이 떨어지고..

혹시 화장실내 온수 배관이 분배되는 지점에 뭔가 걸린게 아닌가 싶어, 온수 배관 (보일러 온수 토출 배관에 달린) 밸브를 마구마구 열고 닫고 반복하다 보니 수압이 유지 됐다...(?)

아직까지 뭐가 원인인지 모르는 상태이다..

ChatGPT의 현재와 미래 전망

포도알77 — Sun, 9 Apr 2023 01:30:37 +0900

ChatGPT는 OpenAI에서 개발한 대화형 인공지능 언어 모델로서, 다양한 분야에서 활용되고 있습니다. 최신 기술인 GPT-3.5 아키텍처를 바탕으로 학습된 이 모델은 대화형 인공지능 기술의 성숙도를 나타내는 지표 중 하나입니다. 이전 모델들과는 달리, ChatGPT는 인간처럼 대화를 주고받는 능력이 매우 뛰어납니다.

ChatGPT는 현재 대화형 인공지능 기술의 중심에 있으며, 이미 많은 분야에서 활용되고 있습니다. 이 모델은 기존의 자연어 처리 분야 뿐만 아니라, 검색 엔진, 챗봇, 음성 인식, 번역 등 다양한 분야에서 응용될 수 있습니다. ChatGPT를 활용하여, 보다 인간적인 대화를 주고받을 수 있습니다.

미래 전망으로는 ChatGPT가 더욱 인간과 유사한 대화 능력을 갖추게 될 것으로 예상됩니다. 인공지능 기술의 발전 속도는 빠르게 가속화되고 있으며, ChatGPT도 이러한 발전 속도에 따라 점차 더 발전할 것입니다. 미래에는 ChatGPT를 기반으로 한 다양한 서비스가 출현할 것으로 예상됩니다. 예를 들어, 더욱 정교한 챗봇이나 개인 비서 서비스, 인공지능 작가 등이 이에 해당됩니다.

하지만 동시에 ChatGPT는 기술적 한계를 가지고 있습니다. 인공지능의 발전 속도는 빠르지만, 인간의 뇌와 같은 수준까지 도달하는 데에는 아직 많은 시간과 연구가 필요합니다. 또한, 인공지능 기술의 발전에 따라 생기는 윤리적 문제도 제기될 수 있습니다. 예를 들어, 인공지능 기술을 활용해 불법적인 행동을 하는 경우가 발생할 수 있으며, 이를 방지하기 위해서는 인간 중심의 법적 규제가 필요합니다.

결론적으로, ChatGPT는 대화형 인공지능 기술의 중심에 있으며, 앞으로 더욱 발전할 것으로 예상됩니다. 이러한 발전은 우리가 보다 편리하고 효과적인 서비스를 제공받을 수 있게 해줄 것입니다.

Ubuntu에서 ffmpeg로 MOV 파일 mp4로 변환하기

포도알77 — Sun, 19 Feb 2023 13:47:08 +0900

설치 :

sudo apt install ffmpeg

변환 :

ffmpeg -i input.mov -vcodec h264 -acodec mp2 output.mp4

디렉터리내 파일 전체 변환 :

find *.MOV | xargs -n1 -I {} /bin/bash -c 'ffmpeg -i {} -vcodec h264 -acodec mp2 {}.mp4'

Ubuntu에서 HEIC 이미지를 jpg로 변환

포도알77 — Sun, 19 Feb 2023 13:37:21 +0900

설치 :

sudo apt install libheif-examples

이미지 변환:

heif-convert image.HEIC image.HEIC.jpg

디렉터리내 모든 이미지 변환 :

find *.HEIC | xargs -n1 -I {} /bin/bash -c 'heif-convert {} {}.jpg'

s906b sound card probe 살펴보기

포도알77 — Thu, 26 May 2022 23:13:47 +0900

sound card의 platform_driver

위와 같이 드라이버를 module_platform_driver로 등록시켜주면, 보일러 플레이트에 의하여 regitser, unregister로 확장된다.

이후에 platform_driver가 등록되고, 이름이 같은 platform_device가 platform_device_register로 등록되면 driver의 probe가 호출된다.

- probe가 호출되는 과정 : platform_add_devices -> platform_device_register -> platform_device_add -> device_add -> bus_probe_device -> device_initial_probe -> __device_attach -> __device_attach_driver -> driver_probe_device -> really_probe -> "dev->bus->probe(dev) 또는 drv->probe(dev)"

- 근데 platform_add_devices를 누가 부르는지 모르겠다

아무튼 driver.probe가 호출되는 과정을 찾았으므로 rainbow_sound_probe를 연속해서 따라가보면,

...나중에 계속

s906b alsa sound card 코드 따라가기

포도알77 — Thu, 19 May 2022 22:33:57 +0900

sound/soc/samsung/rainbow_prince.c

1) Platform driver 드라이버 정의

sound/soc/samsung/rainbow_prince.c

이름이 "rainbow-sound"인 platform_driver를 등록
probe, remove member ops는
- rainbow_sound_probe,
- rainbow_sound_remove 함수를 이용

* platform_driver: include/linux/platform_device.h 정의
* platform device, 가상 버스인 플랫폼 버스에 연결되는 hot plugin 미지원으로 항상 연결되어 있음이 보장되어 있는 장치라고 한다. 주로 device-tree에 정의(항상 연결되어 있으니 실제 장치 확인 필요 없음)한다 함??

sound/soc/samsung/rainbow_prince.c

[MODULE_DEVICE_TABLE 관련 공부 필요]

arch/arm64/boot/dts/samsug/g0s/g0s_eur_openx_w01_r27.dts

2) probe 호출 및 카드 등록
dt에서 장치를 찾았으므로 아래 호출으로 등록한 rainbow_sound_driver의 probe 함수인 rainbow_sound_probe가 호출

module_platform_driver(rainbow_sound_driver);
-> module_platform_driver 매크로는 보일러플레이트(상용구)로 따라가보면 rainbow_sound_driver의 init, exit 함수를 정의해주며, module_init (include/linux/module.h), __initcall (include/linux/init.h), device_initcall, __define_initcall(fn, 6)... 따라 올라가서 asm으로 영역 지정한다.

호출 시점은 kernel_init 부터라는데 이 부분은 https://m.blog.naver.com/kazama10/50174820319 참고, 대충 early 먼저 호출되고, init은 지정된 번호 순서대로 호출되는 듯. [initcall 공부 필요]

삼성 S906B (S22+) 리눅스 커널 다운 및 vim, cscope, ctags 준비

포도알77 — Thu, 19 May 2022 21:43:56 +0900

1. S906B(S22+) 커널 다운로드

삼성 오픈소스 사이트에서 S906B 검색 후 다운로드

https://opensource.samsung.com/uploadSearch

Samsung Open Source

Samsung's Key Value for Open Source Samsung believes that the practice of open source is the key to preparing for future technologies. Openness It means having an open mindset and open engagement, and is not simply defined as public disclosure. Collaborati

opensource.samsung.com

2. ctags, cscope 다운 및 생성

brew install ctags
brew install cscope
make ARCH=arm64 tags cscope

3. vim 세팅

일단 내가 회사에서 쓰던 세팅이 어디껀지 몰라서 검색해서 나온 것 추가

~/.vimrc : https://tot0rokr.github.io/environment/vimrc/

cscope : https://gist.github.com/cyeong/3862602

1) ~/.vimrc 저장
파일 : https://gist.githubusercontent.com/tot0rokr/332669f2accbbf58e766aa5b71d1068c/raw/f4186441e859a1c1919afad6fc6974c06d1b761c/.vimrc
2) git clone
git clone https://github.com/gmarik/Vundle.vim.git ~/.vim/bundle/Vundle.vim
3)vim 실행후 아래 커맨드 실행
:pluginInstall

4. troubleshooting

vim 사용시 swap 파일을 못연다고 나오는데, vimrc에서 ~/.vim/temp에 위치를 설정한다, 따라서 .vimrc의 최상단에 디렉터리를 만들어 주는 부분을 추가해주자.

if empty(glob('~/.vim/temp'))
silent !mkdir -p ~/.vim/temp
endif

이후 잘되는지 확인

디저트가 맛있는 봉천역 카페 - 카페 모리츠

포도알77 — Fri, 22 Apr 2022 15:11:27 +0900

1. 정보

영업시간 10:00 - 21:00(월화수목), 10:00 - 22:00(금토), 11:00 - 22:00 (일)

주소 : 서울 관악구 남부순환로 1711

연락처 : 0507-1486-8031

주차 : 가게 앞 주차 3대??

대표메뉴 : 아몬드크림 라떼, 브라운치즈 크로플, 얼그레이 파운드

4번출구에서 한블록 거리다.

2. 사진

3. 후기

디저트뿐 아니라 음료도 굉장히 퀄리티 있게 나온다. 오히려 유명 카페들보다 훨씬 정성이 담긴 느낌.

사람 자체가 많은 편은 아니고, 테이블간 거리도 넓어서 좋다. 또 하얀 건물에 채광도 잘 늘어와서 편안한 느낌을 준다.

의왕 브런치 카페 뒤란 - DUIRAN

포도알77 — Fri, 22 Apr 2022 15:02:07 +0900

1. 정보

영업시간 11:00 - 21:00 (월요일 휴무), 15:00 -17:00 (브레이크타임, 카페는 운영)

주소 : 경기 의왕시 왕곡로 227 뒤란

연락처 : 031-456-4419

주차 : 주차장 O

대표메뉴 : 스테이크 피자, 명란 크림파스타

2. 사진

3. 후기

1) 웨이팅은 없었고 내부 공간이 넓어 오히려 편하게 식사했음.

2) 식사에 커피가 포함되어 있는데 식사중에 나오는 음료 선택으로 보면 됨.

3) 풍기 피자가 진짜 너무 맛있었고, 파스타도 수준 높게 나왔다.

4) 카페 자체도 좋고, 한적한 위치와 1층이 내려다 보이는 2층 구조가 좋음

☆ 3.5 풍기 피자 또 먹으로 가야지?

영통 브런치 - 소니스 썬프란시스코 마켓 후기

포도알77 — Thu, 21 Apr 2022 10:14:56 +0900

1. 정보

영업시간 10:30 - 21:00 (화요일 휴무), 15:30 -17:00 (브레이크타임)

주소 : 경기 수원시 영통구 매영로425번길 18 1층

연락처 : 070-8833-0078

주차 : 가게옆 외 도로주차

대표메뉴 : 클램차우더와 치즈 브레드, 썬프란시스코 피자

2. 사진

3. 후기

1) 웨이팅이 엄청 길다. 토요일 1시쯤 도착했고 앞에 10팀, 실제로 들어간 시간은 3시쯤. 거의 2시간을 기다렸다.

2) 주차하기가 힘들다. 영통역 근방이 주차가 힘들지만, 특히나 자체 주차장 없이 도로변이나 인근 주택가에 주차해야 한다. 불편함과 불안함은 덤이다.

3) 맛이 평범하다. 뭔가 시그니처라고 부르는 매운 딸기 소스는 묽은 딸기잼에 페퍼론치노 넣은 정도이고, 파스타와 피자 모두 그저 그랬다.

4) 영통역 근방 저렴한 브런치 가게

☆ 2.5 딱히 갈 이유가 없다

나이키 x 사카이 블레이저 로우 화이트 페이턴트 레더

포도알77 — Wed, 20 Apr 2022 10:22:51 +0900

1. 나이키 x 사카이 블레이저 로우 화이트 페이턴트 레더

- 출시일 2022-03-31

- 출시가 139,000원

- 흰색 + 페이턴트 (유광)

- 하얀 사카이라 굉장히 깔끔하게 보이는데, 유광임

2. 실사

3. 시세

하얀색의 깔끔한 사카이라는 점은 좋으나 페이턴트라 유광이라는 점,

블레이저라는 점에서 +5~10 정도로 보임

에어프라이어로 피자 만들기 (페퍼로니와 이마트 훈제 삼겹살)

포도알77 — Wed, 20 Apr 2022 09:55:49 +0900

요약

반죽

재료 : 밀가루 강력분, 소금, 설탕, 이스트 (4~500원 정도)

- 밀가루, 소금, 설탕, 이스트를 섞은 다음 물을 넣고 반죽한다.

- 어느정도 반죽되면 올리브유(아무 기름이나 상관 없음)을 넣고 반죽을 한다.

- 따뜻한 곳에 두어 발효 & 다시 반죽을 적당히 반복한다

토핑

재료 : 케첩 (토마토 소스), 페퍼로니, 피자치즈(모짜렐라)

- 반죽을 넓게 펴고, 그 위에 케첩(토마토 소스)를 바른다.

- 페퍼로니를 올린다

- 치즈를 올린다.

에어프라이기

- 온도 180~200도, 15분 정도

- 반죽 기준이 아니라 치즈 굽기 정도를 보고 꺼내면 된다.

결과
1) 페퍼로니 (저렴한 제품) 아니면 너무 질기다.

2) 의외로 훈제 삼겹살로 하는게 더 맛있다. 페퍼로니보다 훨씬 싸고 양도 많음

산본 매화주공 14단지 - GTX 금정역, 월판선

포도알77 — Tue, 19 Apr 2022 15:12:13 +0900

이름 : 산본동 매화주공 14단지

위치 : 군포시 산본동

세대 : 1847세대

준공 : 1995.7 (22년 기준 28년차)

용적 : 148%

건폐 : 13%

평형 : 20평(공급 69, 전용 50), 21평 (공급 70, 전용 50)

평형 세대 : 20평(267세대), 21평(240세대), 영구임대 1340세대

눈 여겨볼 포인트

1) 임대 아파트

- 용적과 건폐가 낮으면서 1800세대의 대단지 아파트

- 총 1800세대 중 1300세대가 영구 임대로 LH관리

- 사용 연한 30년 기준으로 재개발을 결정하므로, 본 궤도에 오르려면 2+3~4년이 걸리며 실입주는 +@로 10년 넘게 남음

- 단, LH가 한다고 가정했을 때 이야기고 민간 세대만 분리, 단독 진행은 어렵지 않을까

2) 금정역 GTX + 종합 환승 센터 <- 이게 중요

- 금정역 GTX은 이미 들어오는게 기정 사실이라 거들떠 볼 것도 없다.

- 오히려 종합 환승 센터를 건립하므로 교통의 요충지로 만들겠다는 의지로 보임

경강선 ‘월곶~판교선’ 내년 8월 착공 2025년 개통 - 인천투데이

인천투데이=김갑봉 기자 | 인천과 강릉을 잇는 고속철도 경강선 월곶~판교 구간(월판선)이 이르면 내년 8월 착공할 예정이다. 경강선 기점은 송도역과 강릉역이다.경강선은 현재 월판선과 여원

www.incheontoday.com

3) 월판선

- 판교부터 인천까지 가는 월판선이 안양역(1정거장)과 인덕원(GTX 1정거장) 두 곳을 스쳐지나감

- GTX로 강남 출퇴근권 + 월판선으로 판교 출퇴근권이 마련된 것. (이런거 보면 인덕원이 진짜 레전드)

출처 : http://www.gunponews.net/mobile/view.asp?group_name=332&intNum=25870

4) 금정역 일대 재개발

- 의외로 아파트 + GTX만 보고 매화 주공을 찾았을 텐데, 앞부분에 재개발 지역으로 묶여있다.

- 금정역 주변 4~5000 세대 수준이며, 아마도 비슷한 시기에 올라가지 않을까 싶음.

- 지금 당장으로는 오래된 상권으로 보이지만, 향후에는 2), 3), 4) 합쳐서 시너지가 괜찮을 것으로 보임

5) 의외로 별로인 위치

- 의외로 언덕에 위치하고 있음, 물론 금정역까지 600미터 남짓인데 힘든 도보가 될 것.

- 앞에 아파트가 버티고 있음, 현재 정문 위치에 아파트 하나가 떡하니 버티고 있음.

- 주변에 아무것도 없음. 상권은 거리가 있고 실제 아파트 주변에는 별게 없다. (보는 시각 차이, 오히려 상권이 좀 있어야 할텐데 싶음)

- 뒤로 수도권 제1 순환 고속도로 있음, 실제 안살아봐서 소음이나 먼지!! (큰길 주변은 방음도 문젠데 먼지가 너무 심함)가 어떨지 모르겠음, 물론 교통은 좋겠지만 바로 탈 수 있는지 여부는 아직 확인 안해봄

6) 그 외

- 완전 평지면서 넓게 배치되어있는 안양의 역세 베드타운인 평촌이나 범계랑 가격이 크게 차이가 안남

- 금정역에 더 가까운 위치가 재개발되기 때문에 위치적 요소에 따라 가치 디스카운트가 있을 수 있음.

작성일 기준 실거래가 5.1억, 호가 5.2억이며 거래가 그렇게 많지는 않음. (아마도 민간 500세대라 1800세대 대비 거래량이 이정도 라는 착각이)

개인적으로 매수하고 싶음

1) 가격이 저렴함. 서울 출퇴 가능 경기도권 + 역세권 5억이면 싸다.

2) 호재가 많음. 말만인 호재가 아니라, 실제 건설시에 강남+판교 출퇴 가능이라면 말 다했지

3) 앞에 구도심도 거의 재개발이니 나름 괜찮아 보임

4) 단, 아파트 지대 자체가 높고, 임대아파트라는 점, 10년을 넘게 지켜봐야 한다는 점

5) 가장 중요한건 이미 즐겨찾기 이후로 많이 올랐다는 점..ㅋㅋ

MySql - DB 저장 위치 변경 & 디스크 변경 (데이터 복사)

포도알77 — Fri, 8 Apr 2022 01:25:37 +0900

MySQL 데이터 저장 위치를 변경 (파일 위치 변경 또는 디스크 변경) 및 파일 데이터 복사

1) DBMS 끄기

sudo service mysql stop

2) 현재 저장 디렉터리 확인

mysql client로 확인

sudo mysql
select @@datadir;

또는 cnf 파일로 확인

grep -nri datadir /etc/mysql

grep 명령어로 검색하면 datadir이 명시된 파일 위치가 나온다. 내 경우 /etc/mysql/mariadb.conf.d/50-server.cnf 였음

위 파일 열어보면 알겠지만 해당 파일에 정의한 datadir이 mysql client로 나오는 것

3) conf 변경

/etc/mysql/mariadb.conf.d/50-server.cnf 내
...

#
# * Basic Settings
#
user            = mysql
pid-file        = /yourlocation/mysqld.pid
socket          = /yourlocation/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /yourlocation
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking

4) DBMS 켜기

sudo service mysql start

** 만약 데이터까지 옮기고 싶다면 dbms 켜기전에 아래와 같이 파일을 복사해준다.

sudo rsync -av /기존패스 /신규패스

rsync로 하면 권한도 같이 복사한다.

4월 신제품 삼성 스마트 모니터 M8 디테일 개봉 & 사용 후기

포도알77 — Thu, 7 Apr 2022 20:17:04 +0900

요약
1) 다 감안해서 65만원에 내놓았어야 할 모니터
2) 돈 벌이에 혈안이 되어 있는 전형적인 양산형 품질
3) 위의 두 가지 금액과 품질만 빼놓으면 나쁘지 않은 모니터.

1. M7과 M8 스펙 비교

	M7	M8
디자인	일반적인 원형 기둥 모양의 스탠드	각진 모양
밝기	250cd	400cd
색재현력	미기재	sRGB 99%
베사홀	O	X
입력 포트	C 타입 1개, HDMI2.0 2개	C 타입 1개, HDMI2.0 1개
허브	USB 3.0 3개	C 타입 1개
응답 속도	8ms(GTG)	4ms(GTG)
가격	55만	85만
기타		카메라 있음(탈부착 쉬움)

큰 차이점
1) 액정 변경
* 액정 변경으로 색재현률이 sRGB 99%으로 쓸만해졌고, 밝기 400cd로 매우 높아졌다.
- 요즘 색재현률은 초저가, 삼류회사 제품이 아니라면 대부분 sRGB 99~100%
- 밝기 400cd는 일반 사용자용 모니터 치고는 굉장히 높은 수치 (대부분 250~350cd)

2) 입출력 단자 줄어듬
* HDMI2.0 2개 -> 1개
- 이 모니터의 컨셉이 PC 모니터와 TV를 동시에 즐기도록하는 멀티퍼포즈 제품인데, 입력 단자가 너프됨.
- 플스나 엑박같은 게임기를 쓴다던가, 외부 입력 장치를 추가적으로 쓰는 사람들에게는 매우 디메리트
* USB 3.0 A 3개 -> C type 1개
- USB 허브 자체를 줄였기 때문에 연결성이 떨어짐
- C type 모니터 구매 이유 == 노트북 충전과 모니터 출력을 1개의 선으로 하려고 하는 것인데..

3) 베사홀 제거
* 전작에 있던 베사홀을 제거함
- 왜 제거 했는지 이해하지 못하겠다. 아마도 베사홀 연결부를 만들어서 팔아먹으려고 하는게 아닐지

4) 카메라
* 코로나 시국에 줌 회의를 위한 카메라가 달려있다.
- ? 코로나 끝나가고 있고, 음.... 이거때문에 전작에 비해 30만원 오른건 아니죠?

2. 박스 개봉 및 구성품

모니터 박스

생각보다 얇다.

박스 개봉시

박스를 개봉하면 좌우로 모니터 스탠드의 목 부분과 바닥 부분이 있고, 아래로는 사용 설명서와 충전기 및 케이블 등이 있다.

충전기 & 케이블류와 스탠드

좌측부터 케이블류, 모니터 스탠드 목, 그리고 바닥

스탠드 목과 바닥 연결

스탠드의 목부분이다. 보이는 대로 케이블 정리용 홀과 엘리베이션이되며, 간단한 틸트가 된다. 90도로는 안돌려봤다.

바닥 부분이다. 맥처럼 유니바디를 생각했는데 의외로 분리되어 있다;

실제 연결시에 바닥부분의 나사를 조여야 아래처럼 뜨는 부분 없이 잠긴다.
마지막으로 액정은 델과 같이 스탠드 힌지에 모니터를 걸어 고정하는 형태이다.

전체적으로 보면 뭔가...뭐랄까...
음... 흰색 쇠로된 서랍장(매끈한것 말고)처럼 질감이 있는데 되게 그냥 서랍장 같은 스틸이다.
그리고 뒷부분 저 모양은 플라스틱이다. 걍 싼티난다.

3. 액정 부분

모니터 구성품을 빼고 상단 스티로폼을 뺴면 아래에 패널이 들어있다.

사실 좀 충격받은게, 패널에 그 어떤 보호 부착물이 없다.
그냥 저 스티로폼 포장이 끝이다. 흠...
우측 하단에는 리모컨 수신부가 있다.

뒷면에는 모니터 연결부가 있으며, HDMI와 C type 2개 그리고 충전기 연결부가 있다.

이건 나중에도 다시 말할거지만, 마감 불량과 더불어 양끝을 보면 검은 뭔가가 묻어있다. ㅋㅋ.....

4. 구성품

충전기

충전기는 접지가 없는 2핀 전원선을 사용하고 있으며, 무려 140W급이다.
아마 모니터 밝기가 높아서 그런 것도 있겠지만 C Type 출력&충전을 지원해서 그런것도 있는 것 같다.
케이블 길이는 약 1.5미터정도이다.

리모컨

의외로 사람들이 이 리모컨을 욕하던데, 사실 잘 만들었다.
리모컨은 크게 두종류로 나뉘는데, 버튼 기능 많고 무거운 것과 가벼운 것.
삼성은 후자에 속하고 리모컨도 사실 적당하다고 본다.
거기에 C type 충전도 가능하니, 오히려 삼성 티비 리모컨 보다 낫다.

카메라

카메라는 자석형으로 모니터 뒷면에 착하고 붙일 수 있게 되어있다.
특히한 점은 카메라 자체는 C type이고, C type 커넥터를 연결해서 모니터 포고 핀과 연결한다.
* 모니터를 C type으로 연결하면 컴퓨터에서도 인식해서 사용할 수 있다.

카메라 각도. 문제는 모니터에 붙이게되면 일정각도 이하로 숙일 수가 없다..
물론 아슬아슬하게 정중앙에 위치하긴 한다

케이블

HDMI to mini HDMI 케이블과 C to C 케이블을 제공한다.
의외로 갤럭시의 CtoC나 애플의 CtoC를 연결하면 화면이 안나온다. 단, C to C 케이블이 1미터이다.

5. 설치

모니터가 생각보다 큰 듯 크지 않다.
좌측부터 32인치 M8, 25인치 Dell 모니터, 맥북에어 순.

의외로 초기 설정에 대한 소프트웨어가 잘되어있어서 놀랬다.

연결 과정 중에 파란화면이다.
색이 일단 균일하지 못하다... 색재현력 수치만으로 모니터를 사면 안되는 이유이다.

Dell u2515h모니터와 비교
델 모니터는 15년도 제품으로 IPS패널 sRGB 99%이고 350cd이다.
전반적으로 M8이 밝은 이유는 기본 설정이 밝게되어있어서다.
막상 비교해봤을 때 패널에서 오는 색감 차이는 크게 없었다. VA 패널에 대한 걱정이 있다면 조금 덜어놔도 되겠다.

6. 의외로 칭찬할 점

의외의 부분에 디테일을 신경 썼다는게 눈에 띄었는데

첫째로는 충전기, 케이블 봉투를 쉽게 뜯을 수 있게 해놓았다. 처음에는 가위를 가질러 일어섰는데, 저 부분 발견하고 너무 잘 뜯겨서 기분 좋게 다시 앉았다.
두번째로는 각 부속품 포장에 전용 스티커를 사용했다는 점. 옛날의 삼성이라면 그냥 파란색 스티커나 스카치 테잎 같은걸 발라놨을 텐데 장족의 발전이다.

세번째로는 케이블 캡을 제공하여 이물질로부터 커넥터 보호할 수 있게 만들어 놓았다.

네번째로는 카메라에 뚜껑을 만들어 놓았다. 이 또한 카메라의 전체적인 자석 컨셉에 맞추어 챡하고 달라붙게 되어있다.

7. 문제점

전반적으로 단차 문제가 많다.

그리고 왜 이렇게 까만게 많이 뭍어있는지 모르겠다. QC라는게 없는 것인가?

8. 사용 후기

1) 애석하게도 워크스테이션을 처분하고 1 모니터 1 노트북으로 전환해서, 포트에 대한 불만은 없다.
2) 걱정했던 화질은 생각보다 준수했고, 밝기도 좋아서 오히려 눈이 아플 정도.
3) 티비는 생각했던 것보다 좋다. 우리집 삼성 티비보다 기능이 많은 건 함정
4) 스피커가 너무 조악하다. 사실 왜 넣었는지 모르겠다
5) 전반적인 마감이나 포장 퀄리티가 너무 떨어지는데, 설치하고 나니까 싹 까먹었다.
6) 너무 비싸다

9. 마지막으로 M8에 느끼는 감정

지금까지 모니터는 델 제품을 주로 써와서 패키징이나 외관, 케이스등에는 굉장히 실망스러웠다. 박스 크기에서 알 수 있듯, 이미 이 회사는 많이 팔아먹기 좋게 제품을 만든다. 패키지 자체의 불필요한 부분을 다 빼고 스티로폼으로 최대한 얇게 포장을 하고, 제품 자체도 만듦새가 조악한 수준이다. 오히려 삼성 마크 떼면 중국산 삼류 제품이라고 해도 모를 정도.

또 기존 모델에 비해 30만원이나 비싸졌음에도 불구하고 사용자가 필요로 하는 기능에 장난질을 했고, 그놈의 스피커는 인터넷 가입하면 주는 싸구려 티비를 보는 듯한 수준이다. 에라이 와사비망고가 스피커는 더 좋겠다.

무려 85만원짜리 제품이다. 여기에 3~40만원을 더하면, 왠만한 컴퓨터 다 씹어먹고 퀄리티나 디스플레이 그리고 스피커 성능까지 좋은 아이맥을 살 수 있다.
아니 삼성보다 제품을 더 많이 파는 애플도 패키징이나 제품이 신경을 쓰는데, 삼성은 따지고 들면 가성비도 안좋으면서 이렇게 퀄리티가 안좋은 제품을 팔다니 그냥 자국민 배짱 장사하는 것도 아닌가 싶다. 제발 반성좀

10. 놀라운 결말

놀랍게도 구매한지 16일만에 사망했다. (4/7 수령, 4/23 사망)
정확히는 사용중 지직 거리면서 액정이 나가고 소리만 출력되는 상태.

환불 규정상 10일 이내 중대하자시 환불인데, 이미 개봉 16일이 지난 상태라 무조건 교환 또는 수리만 가능한 상황.

여기서 두 가지 빡침포인트가 있었는데
1) 대량 생산 특성상 뽑기가 있다는건 인정, 하지만 몇 년 쓴 것도 아니고 16일만에 갑자기 죽어버린다?
2) 32인치 모니터를 어디가 고장났는지 확인하려고 방문 요청하려고 하니 무조건 출장비를 내야한다? 심지어 제품 하자로 인한 고장인데도??

너무 화가나지만 85만원짜리 불량 모니터에 단 1원도 더 내기 싫었기에,  센터에 무려 32인치 모니터를 들고 가서 점검을 받았고 액정 불량 판정

당연히 액정 수리를 위해서는 모니터 분해가 필수..

만약 100만원이나 주고 산지 2주된 휴대폰에 액정이 나가서 휴대폰 다 뜯어서 수리해야 한다고 하면 누가 좋아할까?
qc나 품질을 제대로 못잡은 제조사는 수리만 해주고, 환불 규정보다 며칠 지났다는 이유로  수리로 인해 발생되는 방수, 중고가 하락등의 부차적인 손해는 소비자가 지고??

그래서 엔지니어에게 난 수리 용납 안되니까 교환 해주시고 안되면 환불해달라고 요청했다. 다행이도 m8 모니터 수급 문제인지 아니면 다른 이유에서인지 센터장과 상의하시더니 환불해주셨다.

이게 처음이자 마지막 삼성 모니터 사용 후기가 될 것 같다.
삼성은 메모리와 갤럭시빼고 사면 안된다. 제품 퀄리티, QC를 봐도 그냥  물량 찍어내기, 유행 따라 디자인 내놓기등 규모의 경제를 누리는 중소기업 수준 밖에 안된다는 걸 다시금 깨달았다.

삼성 모니터 M7, M8 달라진 점, 그리고 델 모니터와 비교

포도알77 — Fri, 1 Apr 2022 18:51:35 +0900

삼성 모니터 M7, M8 차이점 비교

일단 기본적으로 BT, WIFI, 타이젠 기반 TV, 어플 실행 기능 있고, VA패널 4K등 기본적으로 사양인 동일하다.

가장 두드러지는 차이점은 1) 패널이 변경되었는지 밝기와 색 재현력이며, 2) 너프먹은 입출력 포트와 베사홀, 3) 재택 근무를 노린거 같은 철지난 카메라 되시겠다.

	M7	M8
디자인		각진 모양, 애플 따라했다는데 크게 와닿진 않음. 모니터 두께 얇아짐 * 하단 스탠드는 비슷한 느낌의 형태라고 생각했는데, 오히려 새로 추가된 색상을 보니 컬러감이 똑같아 전체적으로 아이맥을 카피했다는 느낌이 듬.
밝기	250cd	400cd
색재현력		sRGB 99%
베사홀	O	X
입력 포트	C 타입 1개, HDMI2.0 2개	C 타입 1개, HDMI2.0 1개
허브	USB 3.0 3개	C 타입 1개
응답 속도	8ms(GTG)	4ms(GTG)
가격	55만	85만
기타		카메라 있음(탈부착 쉬움)

M7 : 가성비, 모니터 1대 쓰면서 색 재현력에 크게 영향 받지 않는 일반 사용자라면 가성비 모델로 추천할만하다. 55만원

M8 : 아래의 수식을 살펴보자. 단 M7에 비해서 베사홀이나 포트 사라진것 외에는 크게 발전했다. 물론 가격도.. 85만원

대기업(삼성, 엘지, Dell) + 32인치 + 그나마 괜찮은 패널 /= 80만원 비쌈

대기업(삼성, 엘지, Dell) + 32인치 + 그나마 괜찮은 패널. + TV 기능 /=. 80만원 비쌈, 60만원대 적당해보임

대기업(삼성, 엘지, Dell) + 32인치 + 그나마 괜찮은 패널. + TV 기능 + 카메라 = M8

지금 쓰는 델 u2515h 비교

일단 이모델은 출시된지 7년이나 된 제품이다.

밝기 350cd, 응답 속도 8ms(GTG), 색재현력 sRGB 99%, DP, mini DP, HDMI, USB3.0 *5, 베사홀

요새는 델 모니터가 그닥 쓸만한게 없는데, 대충

밝기 350cd, 응답속도 5ms(GTG), 색재현력 sRGB 100% + DCI-P3 : 9X% + @ 기능 정도이다.

후기

일단은 모니터가 도착하면 실제로 옆에 두고 색감이나 전반적인 마감 정도를 비교해보고 후기를 더 작성할 예정

후기는 아래 글 클릭

스마트 모니터 M8 개봉 & 사용 후기

요약 1) 다 감안해서 65만원에 내놓았어야 할 모니터 2) 돈 벌이에 혈안이 되어 있는 전형적인 양산형 품질 3) 위의 두 가지 금액과 품질만 빼놓으면 나쁘지 않은 모니터. 1. M7과 M8 스펙 비교 M7 M8

jcdgods.tistory.com

차단기는 정상인데 콘센트 전기가 안들어올 때

포도알77 — Wed, 16 Mar 2022 14:27:21 +0900

차단기는 정상인데 콘센트 전기가 안들어올 때

(1) 출력부에 전선 결합이 제대로 되어있는지 확인
- 고정 나사가 잘 결합되어 있는지, 선은 빠진 것이 없는지

(2) 전기가 안들어오는 콘센트를 분해하여 결합 확인
- 빠진 선은 없는지?
- 초록색(접지)외 빨강, 검정, 하양등 선이 제대로 콘센트에 연결되어 있는지
- 탄 부분은 없는지

(3) 콘센트 하나가 아니라, 여러개가 동시 다발적으로 안된다면 (예, 주방 콘센트가 전부 안된다거나)
- 주방으로 들어오는 시작 부위에 문제가 있을 확률이 있음.
- 차단기에서 출발하는 배선은 정상이나, 주방에 인입되기 직전까지를 확인해야함
- 주로 콘센트에서 선은 점프해서 연결하므로, 차단기에서 문제 위치까지 이어지는 중간의 콘센트를 확인해야 함
- * 만약 오래된 집에 콘센트 교체를 했다거나, 안쓰던 콘센트를 썼다던가 했을때 십중팔구는 콘센트에서 점프하는 부분이 제대로 결합되지 않아서 발생

(4) 선 자체가 나간 경우
- 최악의 경우 해당 콘센트들로 가는 배선 자체가 탄 경우로, 이 경우는 전기 공사 불러야 함

* 집에 간단한 전기 테스트기와 고무 목장갑 정도는 비치해두는게 좋다.

(5) 장마철 갑자기 차단기가 내려갈 때
오래된 집이면 집안의 습기때문에 합선으로 인한 차단기가 내려가는 경우가 있음. 집을 건조하게 하거나 합선이 되는 부분을 전기미터기를 찍어가면서 찾아 가야하나 사실상 일반인이 하기 어려움..
- 정말 이런 집이 많은가? 놀랍게도 장마철만 되면 이 글에 유입량이 늘어난다. 굉장히 잦은 케이스인 듯

구운동 삼환아파트, 재건축 가능할까?

포도알77 — Tue, 11 Jan 2022 10:22:18 +0900

1. 수원 권선구 구운동에 위치한 삼환 아파트

건축연도	1991.04 (32년차)	세대	1680세대 (2동 복도식)
용적률	228%	건폐율	18%
19, 20, 21년도 매매가(22평)	1.7억 / 2.2억 / 2.7억	22년도 매매가 (22평)	4억 3천
주차공간	부족	주변시설	화서역, 버스터미널, 학교, 식목원

2. 호재

1) 신분당선

신분당선이 아파트를 끼고 있는 대로를 따라 지나갈 예정. 단 아파트 바로 입구는 불가할 것으로 보이며 일월먹거리촌이 있는 사거리즈음이 아닐까 싶음.

2) 재건축

추가적으로 아파트 가격을 견인할 만한 호재라고 하기에는 조금 무리가 있어 보임. 포스팅 작성 현재 안전진단 E등급을 받아서 재건축이 인가가 났음.

3) 주변 시설

스타필드가 화서역에 건축중이고, 위로는 수목원, 사이언스 파크등이 건설중이다. 초품아는 아니지만 근거리에 초등학교, 중학교도 2개나 위치해 있다. 또한 그외 대형 마트나, 버스터미널 그리고 공원같은 녹지가 매우 많다.

4) 도로망

우선 서울을 다니기 편하다. 과천 - 남태령 - 강남 순환로를 이용할 수 있다. 다만 수원내 타지역으로 가기에는 교통 체증이 심한편이다. 특히 수원역과 고가도로는 헬이다.

3. 재건축

지금 상황이 그대로 유지된다면 안될 거라 본다.

아파트의 대지가 일단 3종 일반 거주지역이다. 아마 화서 푸르지오는 상업지역으로 용적률 500%까지 건축이 가능하지만, 이 아파트는 300%까지 밖에 안된다. 즉, 현재 용적률 228%에서 가용할 수 있는 용적률은 72%밖에 되지 않는다. 물론 대지 용도가 바뀌면 모르겠지만 단순 아파트 재건축에 대지 용도를 바꿔줄리는 만무해보인다.

바로 앞 동남아파트가 재건축에 들어가서 가격이 많이 올랐는데, 이 아파트는 5층짜리 저층 아파트이다. 제일 작은 평수 기준 5-6억정도 하는데 아마 삼환 아파트도 재건축을 하게 된다면 분담금이 2-3억 하지 않을까 싶다.

아 물론 구운역이 들어서면 용적률 500%된다, 분담비 없이 재건축 한다라고는 하지만 실제 가능성 여부는 불투명.

4. 그래서

선거철이기도 하고, 실제로 다음 부동산 정책에서 재건축, 재개발을 많이 허용하는 추세라면 어떻게 될지는 모르겠지만, 실제 폭등전 집 값 만큼을 분담금으로 내고 매수할 수 있는 사람이 얼마나 많을지는 지켜 보아야한다. 무조건적으로 분담금을 내는 선택을 해야하는 것도 아니지만, 굉장한 난항이 예상된다. 물론 재개발되고 난다면 분양가는 민간 기준 7억~8억이지 않을까 싶다.

맛집 - 서울대 입구 동경산책

포도알77 — Fri, 7 Jan 2022 14:47:24 +0900

서울대 입구 맛집 검색하면 무조건 나오는 동경산책
맛집이라 나오는줄 알았는데 죄다 광고다

가기전 이미지는 별로였는데 가보니 나름 괜찮다.
☆ 3.4 주변에 있으면 가볼만 하다

분위기는 근대 일본 식당 같으면서도 차분한 느낌이다.
캘리포니아 롤은 위에 튀김가루가 있어서 바삭바삭했고 맛 자체는 생각보다 좋았다.

찬바람 불 때 스키아끼 정식이 땡기면 가보자.

맛집 - 용인 고기리 막국수, 들기름 막국수!

포도알77 — Fri, 7 Jan 2022 14:35:54 +0900

용인 고기리에 위치한 맛집 오브 맛집 고기리 막국수

너무 유명해서 모르는 사람이 없을 정도.

들기름 막국수와 수육은 필수 조합이고, 인당 막국수 1개씩 시켯을 때 사리 추가가 가능하다. (사리 추가 메뉴는 그냥 물,비빔 막국수 1개이다)

최소 2명이서 갈거니 들기름 막국수로 통일하고 원하면 물막국수나 비빔막국수를 즐기자.

내 입맛 기준 많이 슴슴하지만 그래도 먹어볼만 하다.

☆ 3.9 - 죽기 전에 꼭 가봐야하는 맛집

맛집 - 용인 라우트66 (가족이 즐길 수 있는 바베큐)

포도알77 — Fri, 7 Jan 2022 13:44:40 +0900

용인에 위치한 라우트 66

한적한 곳에 위치해 주차 고민이 없고, 전반적으로 간이 세지않아 가족단위로 먹으러 오는 사람들이 많다.

☆ 3.4 먹어볼만 하다.
강렬한 맛에 익숙해진 나는 오히려 토미하우스가 더 맛있게 느껴졌다.

맛집 - 성수역 YND(요놈들)

포도알77 — Fri, 7 Jan 2022 13:40:56 +0900

성수역에 위치한 양식전문점

비프크림파스타와 치킨필라프 그리고 청포도에이드

비프크림파스타

☆ 3.5 생각날만 하다.
굉장히 진하고 고소하며, 고기도 잘 구워져서 맛있다. 치즈폭탄에서 오는 그 깊은맛은..

치킨필라프

☆ 3.6 생각날만 하다.
필라프도 굉장히 맛이 진하다. 약간 매콤하기도 하다.

청포도 에이드

☆ 3.7 이거 마시러 가고싶을 정도
직접 만드신 청포도청으로 만든 에이드. 많이 달지 않고 청포도의 식감도 좋다. 위 두 메뉴가 짠맛이 강한데 그에 비해 슴슴한듯 달달한 청포도에이드가 잘 중화시켜준다.

단 2층에 있어 잘 안보인다.

맛집 - 광교 리틀넥 (3대 메뉴 그리고 고구마 프라이즈!!)

포도알77 — Fri, 7 Jan 2022 13:22:13 +0900

광교 갤러리아에 위치한 리틀넥에서 제일 유먕한 세개 메뉴

하우스 스테이크, 명란크림파스타, 고구마 프라이즈

하우스 스테이크

☆3.4 먹어볼만 함
살치살은 일반적인 미디움레어의 스테이크였지만, 지미추리와 바질이 들어간 그린소스나 치즈가 들어간 메쉬드 포테이토 조합으로 먹어볼만한 메뉴

명란크림파스타

☆3.0 메뉴가 있어 먹는다
그냥 일반적인 크림파스타 맛 : ☆ 3.0

고구마 프라이즈

☆3.8 리틀넥을 방문해야하는 이유
이것을 먹기위해 리틀넥에 방문한다고해도 다를바 없는 메뉴
튀긴 고구마의 딱딱함을 생각했으나, 바삭하고 속은 오히려 감자튀김보다도 부드럽다. 고구마 자체의 단맛도 있어 다른 짠메뉴인 파스타와 스테이크와도 잘 어울린다 : ☆ 3.8

추신
의외로 아메리카노 맛집이다
☆ 3.9 저렴하지만 스타벅스보다 맛있다.

리눅스 파일 전송 명령어 : SCP

포도알77 — Wed, 15 Dec 2021 18:48:35 +0900

1. SCP : Secure Copy

2. 파일 보낼 때

- scp 파일명 계정@주소:/원격지/파일/패스

3. 파일 받을 때

- scp 계정@주소:/원격지/파일/패스 파일명

4. 옵션

scp -P 포트 -r

포트 : -P 옵션 이후 포트 번호

디렉터리 : -r 옵션

압축 : -c

[해외 ETF] KODEX 미국 S&P500 TR - 연금/IRP용

포도알77 — Wed, 15 Dec 2021 14:27:30 +0900

1. KODEX 미국 S&P500 TR (379800)

"S&P500 TR Index(KRW)는 미국 주식시장에 상장된 기업 중 시가총액 등을 기준으로 500개 대형주의 주가" 를 추종하는 ETF입니다.

상품정보 - 홈페이지 발췌

1. 미국 증권시장에 상장된 대형주 500개 종목에 투자할 수 있는 ETF입니다.
- S&P500 지수는 미국시장을 대표하는 지수 중 하나로, 대형주 500개 종목의 가치를 반영합니다.

2. S&P500 TR ‘현물’ 지수를 추종합니다.
- 현물 투자 등을 통해 S&P500 TR 현물 지수 추종을 목표로 합니다.
- 따라서, 연금저축/퇴직연금 등 연금투자도 가능합니다.
- 구성 종목의 현금배당이 재투자되는 토탈리턴 지수입니다.

3. 달러 환노출 상품입니다.
- 미국 달러에 대하여 환노출되는 상품입니다. 따라서 환율 변동에 따른 영향을 받습니다.

2. ETF 정보

- 2021.12.14일 기준

순자산 총액	2252억	사무수탁사	한국예탁결제원
상장일	2021.04.09	수탁은행	한국시티은행
총보수	연 0.05%	설정단위	100,000좌
분배금	1, 4, 7, 10월 마지막 영업일, 회계종료일	거래단위	1주

상장일이 4월인 것을 감안하고 이익률을 보아야 한다.

3. 수익률

상장 직후부터 현재까지 약 20% 정도, 나스닥의 우상향하는 특성상 오래 보유해야하는 연금에 적합하고, 유동성이 다른 주식에 비해 크지 않아 1~2년 이상 자금을 묶을 때 구매하면 좋겠다.

4. 구성종목

S&P 500 지수를 추종하기 때문에 구성 종목은 비슷하다. 아래는 상위 20개를 나타낸다.

1	설정현금액	CASH00000001	1,217,467,048	-	1,217,467,048
2	원화예금	KRD010010001	16,448,521	-	16,448,521
3	APPLE Inc	AAPL US Equity	403	6.89	83,755,539
4	MICROSOFT	MSFT US Equity	193	6.38	77,465,266
5	Amazon.com Inc	AMZN US Equity	11	3.63	44,116,715
6	ALPHABET INC-CL A	GOOGL US Equity	8	2.27	27,592,707
7	ALPHABET INC-CL C	GOOG US Equity	7	2.00	24,288,983
8	Meta Platforms Inc	FB US Equity	61	1.99	24,129,640
9	TESLA MOTORS	TSLA US Equity	21	1.98	24,000,405
10	NVIDIA Corp	NVDA US Equity	64	1.75	21,314,047
11	BERKSHIRE HATHWAY CL B ORD.	BRK/B US Equity	48	1.36	16,462,359
12	JPMORGAN CHASE & CO	JPM US Equity	77	1.18	14,380,226
13	S&P500 E-MINI F2112	ESZ1INDEX000	0.05	1.14	13,803,129
14	UNITEDHEALTH GROUP INC	UNH US Equity	24	1.12	13,570,760
15	JOHNSON & JOHNSON	JNJ US Equity	68	1.12	13,546,209
16	HOME DEPOT INC	HD US Equity	27	1.07	12,939,394
17	PROCTER & GAMBLE CO/THE	PG US Equity	62	0.95	11,560,553
18	VISA INC-CLASS A SHARES	V US Equity	43	0.88	10,730,746
19	BANK OF AMERICA CORP	BAC US Equity	190	0.81	9,792,164
20	PFIZER INC	PFE US Equity	144	0.77	9,400,250

[해외 ETF] TIGER 미국테크 TOP10 INDXX - 연금/IRP용

포도알77 — Wed, 15 Dec 2021 14:27:28 +0900

1. TIGER 미국테크 TOP10 INDXX (381170)

“Indxx US Tech Top10 지수(Price Return)(원화환산) * 100%”를 추종하는 ETF로 나스닥 Tech-Oriented 기업들중 시총 상위 10개 종목을 구성종목으로 한다.

상품정보 - 홈페이지 발췌

1. “Indxx US Tech Top10 지수(원화환산)”를 기초지수로 하여 1좌당 순자산가치의 변동률을 기초지수의 변동률과 유사하도록 투자신탁재산을 운용함

2. 투자목적 달성을 위해서 미국 주식에 투자신탁 자산총액의 60% 이상을 투자합니다. “Indxx US Tech Top 10 지수(원화환산)"는 미국 나스닥 상장 주식 중 'Tech-Oriented' 기업이 속하는 섹터를 선별한 뒤 시가총액 상위 10개 종목을 구성종목으로 하는 지수입니다.

3. 환헤지를 실시하지 않습니다

2. ETF 정보

- 2021.12.14일 기준

순자산 총액	1조 1397억	사무수탁사	한국예탁결제원
상장일	2021.04.09	수탁은행	한국시티은행
총보수	연 0.49%	설정단위	50,000좌
분배금	1, 4, 7, 10월 마지막 영업일, 회계종료일	거래단위	1주

상장일이 4월인 것을 감안하고 이익률을 보아야 한다.

3. 수익률

상장 직후부터 현재까지 약 31% 정도, 나스닥에서 시총이 높은 순이기 때문에 안정적?이지만 수익률이 매우 높은편이다.

4. 구성종목

No 종목코드 종목명 수량㈜ 평가금액(원) 비중(%)

1	Microsoft Corp	345	138,474,181	21.41
2	Apple Inc	666	138,414,862	21.40
3	Alphabet Inc	31	106,921,739	16.53
4	Amazon.com Inc	21	84,222,820	13.02
5	Meta Platforms Inc	132	52,214,959	8.07
6	Tesla Inc	38	43,429,305	6.71
7	NVIDIA Corp	113	37,632,614	5.82
8	Adobe Inc	22	17,127,122	2.65
9	Comcast Corp	214	12,074,275	1.87
10	PayPal Holdings Inc	55	12,122,714	1.87
11	원화예금	4,226,601	1	0.65

[해외 ETF] TIGER 미국 필라델피아 반도체 - 연금/IRP용

포도알77 — Wed, 15 Dec 2021 14:18:58 +0900

1. TIGER 미국 필라델피아 반도체 (381180)

“PHLX Semiconductor Sector 지수(원화환산)”를 추종하는 ETF로 나스닥 반도체 섹터 시총 상위 30개 종목을 구성종목으로 한다.

상품정보 - 홈페이지 발췌

1. “PHLX Semiconductor Sector 지수(원화환산)”를 기초지수로 하여 1좌당 순자산가치의 변동률을 기초지수의 변동률과 연동하여 운용함을 목적으로 합니다.

2. 투자목적 달성을 위해 미국 주식시장에 상장된 주식에 투자신탁 자산총액의 60% 이상 투자합니다. “PHLX Semiconductor Sector 지수(원화환산)"는 미국 주식시장(NASDAQ, NYSE, NYSE American, CBOE)에 상장된 종목 중 반도체 섹터 시가총액 상위 30개 종목을 구성종목으로 하는 지수입니다. 다만, 이 투자신탁은 해외 주식에 투자하면서도 환헤지를 하지 않으므로 1좌당 순자산가치는 기초지수의 원화환산 수익률에 연동하게 됩니다.

3. 환헤지를 실시하지 않습니다

2. ETF 정보

- 2021.12.14일 기준

순자산 총액	9019억	사무수탁사	한국예탁결제원
상장일	2021.04.09	수탁은행	한국시티은행
총보수	연 0.49%	설정단위	50,000좌
분배금	1, 4, 7, 10월 마지막 영업일, 회계종료일	거래단위	1주

상장일이 4월인 것을 감안하고 이익률을 보아야 한다.

3. 수익률

상장 직후부터 현재까지 약 20% 정도, 반도체 사이클에 따라서 가격차이가 많이 나는편이고 최근에 반도체 수급 이슈로 인해 가격이 많이 오른것 같다.

4. 구성종목

No 종목코드 종목명 수량㈜ 평가금액(원) 비중(%)

1	NVIDIA Corp	163	54,284,213	8.94
2	QUALCOMM Inc	249	53,981,763	8.89
3	Broadcom Inc	73	53,667,783	8.84
4	Texas Instruments Inc	192	43,876,919	7.22
5	Intel Corp	677	40,031,010	6.59
6	Marvell Technology Inc	299	30,617,998	5.04
7	Advanced Micro Devices Inc	165	26,108,260	4.30
8	KLA Corp	54	25,528,194	4.20
9	Micron Technology Inc	248	24,738,572	4.07
10	Lam Research Corp	30	24,301,365	4.00
11	Applied Materials Inc	136	23,658,622	3.90
12	Analog Devices Inc	112	23,638,565	3.89
13	NXP Semiconductors NV	85	22,294,552	3.67
14	Microchip Technology Inc	215	21,652,696	3.56
15	Taiwan Semiconductor Manufacturing Co Ltd	154	21,202,456	3.49
16	ASML Holding NV	22	19,889,368	3.27
17	ON Semiconductor Corp	169	12,507,201	2.06
18	Skyworks Solutions Inc	65	12,261,374	2.02
19	Teradyne Inc	65	11,942,367	1.97
20	Monolithic Power Systems Inc	18	10,217,876	1.68
21	Entegris Inc	53	8,917,797	1.47
22	Qorvo Inc	43	7,881,520	1.30
23	Wolfspeed Inc	46	6,026,387	0.99
24	Lattice Semiconductor Corp	53	4,708,983	0.78
25	IPG Photonics Corp	21	4,139,927	0.68
26	Silicon Laboratories Inc	16	3,780,157	0.62
27	Azenta Inc	29	3,447,030	0.57
28	II-VI INC	41	3,227,752	0.53
29	Amkor Technology Inc	95	2,516,572	0.41
30	Power Integrations Inc	23	2,345,710	0.39
31	원화예금	3,988,684	1	0.66

[해외 ETF] KODEX 미국나스닥100TR - 연금/IRP용

포도알77 — Wed, 15 Dec 2021 11:17:36 +0900

1. KODEX 미국나스닥 100TR (379810)

미국 나스닥 100 지수를 추종하는 ETF로 배당금까지 재투자되는 TR 상품이다.

상품정보 - 홈페이지 발췌

1. 미국 나스닥 시장에 상장된 기업 중 시가총액, 거래량을 기준으로한 100개 우량종목에 투자합니다.
- 리츠, ETF, 금융 섹터는 제외한 지수입니다.

2. NASDAQ100 TR ‘현물’ 지수를 추종합니다.
- 현물 투자 등을 통해 NASDAQ100 TR 현물 지수 추종을 목표로 합니다.
- 따라서, 연금저축/퇴직연금 등 연금투자도 가능합니다.
- 구성 종목의 현금배당이 재투자되는 토탈리턴 지수입니다.

3. 달러 환노출 상품입니다.
- 미국 달러에 대하여 환노출되는 상품입니다. 따라서 환율 변동에 따른 영향을 받습니다.

2. ETF 정보

- 2021.12.14일 기준

순자산 총액	2454억	사무수탁사	한국예탁결제원
상장일	2021.04.09	수탁은행	한국시티은행
총보수	연 0.05%	설정단위	100,000좌
분배금	미지급 (TR)	거래단위	1주

상장일이 4월인 것을 감안하고 이익률을 보아야 한다.

3. 수익률

라즈베리파이에서 one-wire 온도센서(DS18B20) 읽는 제일 쉬운 방법

포도알77 — Sat, 27 Nov 2021 10:45:28 +0900

1. One wire는?

1개의 데이터 선에 여러 장치를 붙여서 쓰는 식이다. 우리가 멀티탭에 전원을 꽂아서 쓰듯.

이 방식을 이용하면 선 1개로 여러 개의 센서를 붙일 수 있는데, 나는 온도 센서를 한줄로 붙여서 외부, 베란다, 거실 온도를 측정했다.

2. Raspberry 설정

1) one-wire 설정 enable 해주자.

sudo raspi-config

interface -> one-wire -> enable

2) 아래의 명령으로 w1 모듈을 프로브 해주자.

sudo modeprobe w1-gpio

sudo modprobe w1-therm

3) reboot을 하자.

4) /sys/bus/w1/devices 디렉터리가 생성되면 설정 완료

3. 디바이스 확인하기

나는 DS18B20 온도 센서를 3개 썼다. 이 온도 센서는 아래와 같이 28-으로 시작한다.

28-0000075bb47e

28-0000075be046

28-0000075cddf2

온도 값은 해당 장치 아래 파일에서 확인할 수 있다.

cat /sys/bus/w1/devices/28-0000075cddf2/w1_slave

2a 01 4b 46 7f ff 06 10 16 : crc=16 YES
2a 01 4b 46 7f ff 06 10 16 t=18625

여기서 t=X가 온도 값이다. 이 값에 1000을 나눠주면 된다.

4. python 코드

간단하게 파일 열어서 해당 값을 re로 뽑아내면 된다.

장치 id는 내가 따로 온도 센서를 추가하지 않는 한 변하지 않을 것이므로 그냥 하드 코딩 해버렸다.

import re

tempPattern = re.compile('t=(\\d+)')

def getTemp(sid):
	f = open('/sys/bus/w1/devices/'+sid+'/w1_slave')
    lines = f.readlines()
    f.close
    
    for s in lines:
    	v = tempPattern.search(s)
        if(v):
        	return float(v.group(1))/1000
	return -999
    
sids = ['28-xxxxxxxxxxx']

for sid in sids:
	v = getTemp(sid)
    print(sid, v)

이제 이 데이터를 db에 넣어주면 된다.

라즈베리와 아두이노 USB로 통신하기

포도알77 — Sat, 27 Nov 2021 10:28:24 +0900

1. 간단하게 서로 통신할 방법이 없을까?

아두이노는 USB로 전원을 공급받을 수 있고, 프로그램 업로드도 가능하다. 즉 USB로 데이터 송수신을 할 수 있다.

2. Raspberry에서 어떻게 아두이노에 데이터를 줄까?

Raspberry에서 serial 통신을 수행하면 된다. Python의 경우 PySerial을 통하여 시리얼 통신을 열고 read, write를 수행할 수 있다.

3. 라즈베리 예시코드

import serial

com = serial.Serial(port = "/dev/ttyACM0",
		baudrate = 9600,
		bytesize = serial.EIGHTBITS,
		parity = serial.PARITY_NONE,
		timeout = 1)
s = "TEST CODE"
com.write(s.encode())

Serial 통신을 몇번 다뤄본 사람은 간단하게 다른게 없다고 생각할 것이다. 처음 사용하는 사람도 그저 파일하나 오픈해서 read, write 한다고 생각하면 된다.

4. 아두이노 예제 코드

void setup()
{
  Serial.begin(9600);
}
void loop()
{
  char a = Serial.read();
}

... 간단해서 더 이상 설명할게 없다.

참고하고 싶다면 아래의 두 포스트를 더 참고하자.

(1) 라즈베리에서 USB를 찾고 싶다면

https://jcdgods.tistory.com/351

[라즈베리파이] USB 컨버터(RS485/RS232)를 이용한 시리얼 통신 읽/쓰기 파이썬 예제

라즈베리파이(Raspberry pi / RPi)에 USB TTL 컨버터(RS485/RS232)를 이용하여 시리얼 통신하는 예제 코드를 작성하여 둔다. 우선 컨버터를 이용하기 때문에 결국 프로토콜이 RS232이든 반이중 RS485이든

jcdgods.tistory.com

(2) 아두이노에서 Serial 통신하기

https://jcdgods.tistory.com/465

[간단한 아두이노 코딩] 17. USB to TTL 컨버터 사용해보기

Serial 통신 해보기 1. Serial 통신 시리얼 통신은 병렬 통신과 달리 적은 수의 신호선을 이용하여 데이터를 전송하는 방식을 말한다. 일반적으로 1~2개의 선을 가지며, 우리가 익숙하게 사용하는

jcdgods.tistory.com

동일한 요청을 여러 서버에 Broadcasting 해주는 NginX mirror

포도알77 — Sat, 27 Nov 2021 09:34:57 +0900

1. 하나의 요청을 여러 서버가 알아야 할 때

아래의 그림과 같이 한 서버에 요청을 릴레이 하면서 또 다른 서버가 해당 요청을 알아야 할때 사용할 수 있는 mirror 기능이다.

2. NginX conf

location / {
	mirror /mirror;
	proxy_pass http://location.to;
}

location /mirror {
	internal;
	proxy_pass http://location.to.mirror;
}

location으로 /mirror을 등록하고, internal 지시어를 통하여 해당 path는 내부적으로만 접근할 수 있게 강제한다. (외부에서 도메인이나 ip타고 들어오는 경우엔 접근할 수 없다는 의미)

그리고 해당 path에 proxy_pass를 설정한 다음 등록을 원하는 location에 mirror로 등록하면 된다.

이렇게 되면 /으로 오는 요청은 항상 location.to, location.to.mirror에 모두 전달되지만, location.to.mirro 응답은 nginx단에서 버려진다. 즉, 웹 서버 본연의 요청-응답 모델에 어떠한 영향 없이 스니핑이 가능한 상태가 된다.

3. 어디다 쓰지?

이미 이 글을 검색해서 들어왔다면 원하는 쓰임새가 있을 것이다. 나의 경우 데이터 전달시 두 서버에 전달하기 위하여 mirror를 활용했다.

IT 방랑기

X-Frame-Options와 CSP frame-ancestors는 무엇이 다를까? 클릭재킹 방어 기준 정리

X-Frame-Options와 CSP frame-ancestors는 무엇이 다를까? 클릭재킹 방어 기준 정리

클릭재킹은 무엇이고 왜 프레임 제어가 필요할까?

X-Frame-Options는 무엇을 할 수 있을까?

CSP frame-ancestors는 무엇이 다를까?

둘의 핵심 차이는 무엇일까?

둘 다 같이 넣어야 할까?

자주 놓치는 설정 포인트는 무엇일까?

1. 메타 태그로는 충분하지 않을까?

2. default-src 'none'만 있으면 프레임도 막힐까?

3. 중첩 프레임에서도 한 번만 검사할까?

SameSite 쿠키는 왜 같이 언급될까?

어떤 기준으로 선택하면 될까?

FAQ

Q. X-Frame-Options만 써도 충분할까?

Q. 파트너 사이트 한 곳만 프레임 허용하려면 어떻게 해야 할까?

Q. iframe 안에 내가 불러오는 외부 페이지 출처 제어도 같은 설정일까?

정리

참고 자료

[크롤링] 데이터 수집을 위한 크롤링 8편 : ETag와 If-None-Match로 변경된 페이지만 다시 받는 방법

[크롤링] 데이터 수집을 위한 크롤링 8편 : ETag와 If-None-Match로 변경된 페이지만 다시 받는 방법

왜 ETag를 먼저 봐야 할까?

If-None-Match는 어떻게 동작할까?

304 Not Modified를 받으면 무엇을 해야 할까?

ETag가 있으면 항상 트래픽이 줄어들까?

If-Modified-Since와는 무엇이 다를까?

크롤러에서는 어떤 흐름으로 구현하면 될까?

약한 ETag와 강한 ETag는 어떻게 봐야 할까?

FAQ

모든 사이트가 ETag를 보내나?

304 응답에도 헤더는 올 수 있나?

If-None-Match와 If-Modified-Since를 같이 보내도 되나?

정리

참고 자료

라즈베리파이에서 SPI를 어떻게 켤까? Bookworm 기준 활성화와 spidev 확인 방법

라즈베리파이에서 SPI를 어떻게 켤까? Bookworm 기준 활성화와 spidev 확인 방법

왜 먼저 경로부터 확인해야 할까?

SPI를 켜면 실제로 무엇이 바뀔까?

가장 단순한 활성화 방법

config.txt로 직접 설정할 때 볼 것

활성화 뒤 무엇을 확인하면 될까?

Python이나 C에서 바로 읽고 쓸 수 있나?

언제 SPI1 이상 오버레이까지 봐야 할까?

FAQ

Bookworm인데 예전 글처럼 /boot/config.txt를 수정해도 되나?

SPI를 켰는데 /dev/spidev0.0가 바로 안 보일 수 있나?

raspi-config와 config.txt 중 무엇이 더 낫나?

정리

참고 자료

Python uuid7은 언제 써야 할까? 정렬 가능한 ID 선택 기준 정리

Python uuid7은 언제 써야 할까? 정렬 가능한 ID 선택 기준 정리

uuid7은 무엇이 다른가?

언제 uuid7이 잘 맞을까?

uuid4와 비교하면 무엇이 달라질까?

Python에서는 어떻게 쓰나?

uuid7이 항상 정답은 아닌 이유

데이터베이스 키로 써도 될까?

FAQ

Python 3.13에서는 uuid7을 못 쓰나?

uuid7을 정렬하면 항상 생성 순서와 완전히 같아지나?

uuid1 대신 uuid7을 고려하는 이유는 무엇인가?

정리

참고 자료

Let's Encrypt 인증은 HTTP-01, DNS-01, TLS-ALPN-01 중 무엇을 써야 할까? 선택 기준 정리

Let's Encrypt 인증은 HTTP-01, DNS-01, TLS-ALPN-01 중 무엇을 써야 할까? 선택 기준 정리

세 방식의 차이를 먼저 보면?

HTTP-01은 언제 적합할까?

HTTP-01이 무난한 경우

HTTP-01이 맞지 않을 수 있는 경우

DNS-01은 왜 와일드카드에 필요할까?

DNS-01을 먼저 검토할 상황

DNS-01에서 운영상 주의할 점은?

TLS-ALPN-01은 무엇이 다를까?

TLS-ALPN-01이 유리한 경우

TLS-ALPN-01의 한계는?

결국 무엇을 기준으로 고르면 될까?

자주 나오는 질문

Q. 리버스 프록시 뒤에 여러 웹 서버가 있으면 어떤 방식이 안전할까?

Q. 포트 443만 열려 있으면 HTTP-01도 가능한가?

2. `default-src 'none'`만 있으면 프레임도 막힐까?

Q. `X-Frame-Options`만 써도 충분할까?

Bookworm인데 예전 글처럼 `/boot/config.txt`를 수정해도 되나?

SPI를 켰는데 `/dev/spidev0.0`가 바로 안 보일 수 있나?

`raspi-config`와 `config.txt` 중 무엇이 더 낫나?

1. `unsafe-url`은 왜 주의해야 할까?

2. `no-referrer`는 언제 과할 수 있을까?

3. `origin`과 `strict-origin`의 차이는 무엇일까?