ActivityPub 서버에서 YouTube 추적 링크 방지하기

ActivityPub 서버에 공유되는 YouTube 링크는 종종 사용자들 사이에서 개인정보 보호 측면의 우려 사항으로 언급됩니다. 이는 공유된 URL에 포함된 si 파라미터나, YouTube 웹사이트 자체에 내장된 다양한 추적 기술 등 방문자를 추적하는 데 사용될 수 있는 여러 기술적 메커니즘 때문입니다.

현실적으로 볼 때, ActivityPub 프로토콜을 구현하는 프로젝트들이 이 문제에 대해 기본 제공 해결책을 제시할 가능성은 낮습니다. 이는 YouTube라는 특정 서비스에 국한된 문제가 아니라, 보다 광범위한 웹 추적 문제에 해당하기 때문입니다.

그럼에도 불구하고, 서버 관리자는 서버 차원에서 이러한 우려를 완화하기 위한 실질적인 조치를 취할 수 있습니다.

1. 대체 YouTube 프론트엔드 사용

YouTube로 직접 연결하는 대신, 개인정보 보호에 더 우호적인 대체 프론트엔드 사용을 권장할 수 있습니다.

• DNT-YT (권장 — 이 시나리오를 위해 특별히 설계됨)
• Piped
• Invidious

이러한 프론트엔드들은 영상 접근성을 유지하면서도 추적을 줄이거나 제거하는 데 도움을 줍니다.

2. Nginx sub_filter를 사용한 링크 재작성

대체 프론트엔드를 설정한 이후에는, Nginx의 sub_filter 기능을 사용하여 YouTube 링크를 투명하게 재작성할 수 있습니다. 이를 통해 사용자가 원본 YouTube URL에 직접 접근하는 것을 방지하고, 대신 대체 프론트엔드를 통해 영상을 보도록 유도할 수 있습니다.

예시 설정은 다음과 같습니다.

sub_filter 'www.youtube.com/' 'dnt-yt.catswords.net/';
sub_filter 'youtube.com/' 'dnt-yt.catswords.net/';
sub_filter 'www.youtu.be/' 'dnt-yt.catswords.net/';
sub_filter 'youtu.be/' 'dnt-yt.catswords.net/';

결과

youtube.com 또는 youtu.be로 연결되는 링크가 일관되게 대체 프론트엔드 주소로 변경되는 것이 확인되면, 설정은 완료된 것입니다.

이 접근 방식을 실제로 적용한 사례는 아래 링크에서 확인할 수 있습니다.

https://catswords.social/@gnh1201/115801692643125819

Terraform & Kubernetes 도입 후기

최근 인프라 구성과 서비스 운영 전반에서 (늦었지만…) Terraform과 Kubernetes를 본격적으로 사용해 보았고, 생각보다 경험이 꽤 좋아서 기록 겸 공유해 둔다.

TL;DR

이걸 왜 이제 썼지. 진작 써볼 걸. (feat. 관리할 서버가 많아질수록 체감이 큼)

기존에 사용하던 방식

1. 웹 브라우저 → AWS 콘솔에서 마우스 클릭으로 인프라 구성 (EC2 생성, 네트워크 설정 등)
2. 로컬 서버에 Docker / Docker Compose 기반 운영

이번에 사용한 방식

Terraform (IaC)

• VPC, Subnet, NAT, Kubernetes Cluster 까지 인프라를 코드로 선언
• 변경 이력이 Git에 남아 변경 추적과 리뷰가 가능
• 코드로 명확히 남기니 재사용성과 일관성이 크게 좋아짐
• 콘솔 수작업이 줄어들어 휴먼 에러 감소
• '이 인프라가 왜 이렇게 생겼는지'가 코드로 설명됨

내 경우는 NCP(Naver Cloud Platform) 를 사용했는데, 지원하는 리소스 범위가 제한적이라 일부는 여전히 웹 콘솔에서 수작업이 필요했다.

그럼에도 불구하고, Terraform을 도입한 만족도는 꽤 높았다.

Kubernetes

• 배포, 롤링 업데이트(무중단), 오토스케일링이 정책 기반으로 자동 동작
• 모든 설정을 yaml파일로 관리할 수 있는 점이 매우 편리
• 서비스 디스커버리, 헬스 체크, 셀프 힐링 덕분에 운영 부담이 체감될 정도로 감소
• Pod / Node / Resource 단위로 문제를 분리해서 볼 수 있어 장애 원인 추적이 수월
• 서비스 규모가 커질수록 정리된 상태를 유지하기 쉬운 구조
• GitLab CI + Container Registry + ArgoCD 조합의 배포 자동화 경험이 매우 만족스러웠음

그리고, AI의 도움

이번에 느낀 또 하나의 큰 포인트는 AI의 존재감이었다.

• Terraform module 구조 설계, variable 정리
• Kubernetes manifest 작성 및 리팩토링 (Deployment, HPA, Ingress 등)
• 에러 메시지 / 이벤트 로그 해석
• 필요한 CLI 명령어를 바로 바로 알려줌
• “이 구성, 더 나은 패턴이 있는가?” 같은 설계 피드백
• 문서를 처음부터 끝까지 파는 방식보다, AI와 대화하면서 검증하고 다듬는 흐름이 훨씬 효율적이었다.

결과적으로,

• 러닝 커브는 여전히 존재하지만 AI를 보조 도구로 사용하면서 학습 속도와 시행착오 비용이 크게 줄어든 느낌

요약하자면,

• 수많은(?) 장애와 벽에 부딪히는 순간에도 언제든 도움을 받을 수 있다는 점에서 덜 두려웠다.

부록) K8S, 다음에도 바로 쓸 것인가?

• 서비스 초기부터 바로 도입할 것 같지는 않다 (K8S Cluster만 해도 NCP 기준 월 약 7만 원)
• 초기에는 인스턴스 1~2대 + 오토스케일링 정도로 충분할 듯 (아예 오토스케일링이 필요 없는 경우도 많다)
• 사용하는 인스턴스 수가 늘고, 서비스 규모가 커지면 그때 도입을 고민
• 사용 경험은 긍정적이지만 작은 서비스에는 확실히 오버스펙
• 서버에 바로 SSH 접근해서 띄우고 로그보고 재기동 시키고 하는 게 더 편안한 1인이라, 그런 거 못할 때 가끔 불편하게 느껴지기는 했음 (물론 셸 접근은 가능하나, 그러기에는 Pod이 너무 많..)

정리하면

• Terraform: 서비스 초기부터 도입하고 싶다
• Kubernetes: 상황에 따라 선택, 작은 서비스라면 초반 도입은 X

TL;DR
AI 구독은 저절로 팀 생산성을 높여주지는 않는다.
개인의 노하우가 휘발되지 않고 팀의 자산으로 축적되는 워크플로우를 설계하는 것이 AI 시대 리더의 핵심 역할이다.
단계별 컨텍스트 분리 + 결정적 검증(CI) + 비결정적 판단(LLM) + 작은 변경 단위로 굴러가는 일관된 워크플로우를 팀단위로 적용할 것을 제안한다.

개요

코딩 에이전트가 개발의 필수 도구가 된 지금, AI를 쓰지 않는 개발자를 찾기가 오히려 어렵다. 기업들도 이 흐름에 발맞춰 OpenAI, Claude, Gemini를 종류별로 전부 구독하며 적극적인 사용을 장려한다.

하지만 비싼 비용을 들여 AI를 구독한다고 해서 생산성이 저절로 높아지지는 않는다.
METR 리서치에 따르면 AI 코딩 도구를 사용했을 때 개발 완료 시간이 오히려 19% 증가했다는 결과도 있다. 개발자들은 20% 단축을 기대했지만, 누군가에게는 아니었다.
반면, SNS에서 자주 회자되는 프로그래밍좀비라는 개발자는 AI를 활용해 350개의 앱을 개발하고 수익화에 성공했다고 한다. 중국인 개발자 EastonDev는 10,000라인 레거시 코드를 14일 만에 리팩토링하며 테스트 커버리지, 버그, 성능 지표까지 개선했다.

같은 도구를 쓰면서 왜 이런 생산성 차이가 생길까? 개인이 각자 알아서 AI를 사용하다 보면, 도구에 대한 이해도, 축적된 경험, 효과적인 활용법에 따라 결과가 천차만별이기 때문이다. 개발팀을 리딩하면서 느끼는 문제의식이 바로 이 지점 – 개발자, 개발조직마다 발생하는 AI 활용 역량의 편차-이다. AI 구독은 개인 능력의 상한선을 높여주지만, 그것이 곧 팀 전체의 생산성 향상을 보장하지는 않는다.

이 글에서는 필자가 고민한 개인의 AI 활용 역량을 팀 전체의 역량으로 전환하는 방법을 다룬다.

LLM과 Harness의 한계

LLM의 한계는 이미 잘 알려진 내용이므로 깊이 다루지는 않겠다. 다만 트랜스포머 기반 AI에게 업무를 맡길 때 반드시 인지해야 할 본질적 한계를 짚고 넘어가보자.

1. 컨텍스트는 유한하다

아무리 컨텍스트 윈도우가 커져도, 긴 맥락이 필요한 작업에는 여전히 한계가 있다. 대규모 코드베이스 전체를 이해하거나, 수십 개 파일에 걸친 리팩토링을 한 번에 처리하기는 어렵다. 이를 해결하려면 맥락을 효과적으로 전달하는 별도의 방법을 고안해야 한다.

2. 결과물은 확률적이다

같은 프롬프트에도 매번 다른 결과가 나온다. 이는 LLM의 근본적인 생성 방식 때문이다. 창의적인 작업에서는 장점이 되지만, 일관성이 필요한 작업에서는 치명적인 단점이 된다.

3. 환각은 피할 수 없다

LLM은 자신 있는 어조로 틀린 정보를 생성한다. 코딩 맥락에서는 존재하지 않는 API를 호출하거나, deprecated된 문법을 최신인 것처럼 제안하거나, 아예 없는 라이브러리를 import하는 코드를 만들어낸다. 문제는 이런 환각이 그럴듯해 보인다는 것이다. 검증 없이 AI의 출력을 그대로 믿으면, 컴파일 에러는 그나마 다행이고 런타임에서나 확인하는 대형사고로 이어질 수 있다.

Harness: 현실적인 해결책

이러한 한계를 보완하는 여러 방법 중, 현재 가장 제품 수준의 완성도를 보여주는 것이 Harness(Tool Use 기반의 에이전트 구조)다. Claude Code, Cursor, Windsurf 같은 코딩 에이전트들이 이 방식을 채택하고 있다.

하지만 Harness에는 유효기간이 있다.

Bitter Lesson의 깨달음, Scaling Law는 여전히 유효하다. 어느 날 갑자기 Google이나 OpenAI의 신모델이 등장해, 팀이 공들여 구축한 Harness를 무용지물로 만들 수 있다. 실제로 예전에는 PDF에서 텍스트를 추출하려면 복잡한 파이프라인이 필요했지만, 이제는 멀티모달 모델에 이미지로 던지면 끝이다. 팀이 몇 주간 구축한 PDF 파싱 Harness가 하룻밤 사이에 레거시가 되어버리는 것이다.

그럼에도 Harness를 만들어야 하는 이유

이런 리스크에도 불구하고, 지금 당장 Harness가 제공하는 생산성 향상은 무시할 수 없다.

Harness 없이 Raw LLM만 쓰는 것과, 잘 구성된 에이전트 환경에서 작업하는 것의 생산성 격차는 이미 크게 벌어졌다. 6개월 뒤 무용지물이 될 수 있다 해도, 그 6개월간의 생산성 이득이 구축 비용을 상회한다면 만들어야 한다.

문제는 이 Harness를 개인이 아닌 팀 전체가 일관되게 사용하도록 만드는 것이다.

개인의 AI 역량 ≠ 팀의 AI 역량

AI를 잘 쓰는 개인은 많다. 하지만 그 개인이 속한 팀이 AI를 잘 쓰는가는 전혀 다른 문제다.

팀원들에게 비싼 AI 구독을 제공한다고 해서 팀 생산성이 저절로 높아지지 않는다. 개인 단위의 AI 활용이 팀 단위의 생산성으로 전환되지 못하는 데는 구조적인 이유가 있다.

1. 인간 지능이 병목이다

AI의 코드 생산 속도는 인간의 리뷰 속도를 아득히 넘어선다. ITWorld의 분석에 따르면, 이는 "조립 라인에서 한 기계만 속도를 높이고 나머지를 그대로 두면, 공장이 빨라지는 것이 아니라 처리되지 못한 작업이 쌓여갈 뿐"인 상황과 같다. 코드는 10배 빨리 생성되는데, 리뷰는 여전히 사람이 일일이 해야 한다면 결국 인간 리뷰어가 병목이 될 수 밖에 없다.

2. 검증 체계가 없다

AI가 생성한 코드를 얼마나 신뢰할 수 있는가? 코드래빗 보고서에 따르면, AI 생성 코드는 사람이 작성한 코드보다 PR당 1.7배 더 많은 이슈를 발생시킨다. 객관적인 검증 지표와 자동화된 품질 게이트 없이는, AI 결과물에 대한 확신을 가질 수 없다.

3. 숙련도 격차가 크다

누군가는 정교한 프롬프트와 최적화된 에이전트 설정으로 높은 품질의 결과물을 뽑아내지만, 누군가는 기본적인 활용에도 어려움을 겪는다. 같은 도구, 같은 구독료를 내면서도 생산성 격차는 몇 배씩 벌어진다. 이 격차를 좁히는 것은 개인의 노력만으로는 한계가 있다.

4. 경험과 노하우가 휘발된다

가장 심각한 문제다. 비슷한 업무를 하는 팀원들이 각자 비슷한 프롬프트를 만들고, 비슷한 에이전트 구성을 시도한다. 누군가 효과적인 방법을 발견해도, 그 지식은 개인에게 머문다. 슬랙에 공유한 팁은 며칠 뒤 묻히고, 노션에 정리한 가이드는 업데이트되지 않는다. AI를 잘 쓰는 경험과 노하우가 팀에 축적되지 않고 휘발된다.

---

이 네 가지 문제의 공통점은 무엇인가? AI 역량을 축적하고 공유할 워크플로우의 부재다.

개인의 역량에 의존하는 한, 팀 전체의 AI 활용 수준은 들쭉날쭉할 수밖에 없다. 필요한 것은 개인의 경험이 팀의 자산으로 축적되고, 검증된 워크플로우가 모든 팀원에게 일관되게 적용되는 구조다.

AI 시대, 리더가 해야 할 일

앞으로 모든 기술 리더는 개인의 경험이 팀의 자산으로 축적되는 구조를 설계해야 한다. 이것은 비단 AI Era만 해당되는 이야기가 아니다. 다만 AI 시대에는 앞서 언급한 이 문제가 첨예해졌을 뿐이다.

리더의 역할은 적극적으로 Harness를 구축하고, 이를 팀 워크플로우에 녹여내는 것이다. 다음은 이를 위한 다섯 가지 원칙이다.

1. 워크플로우 단계별로 맥락을 분리하라

하나의 거대한 프롬프트로 모든 것을 해결하려 하지 마라. 기획 검토, 설계, 구현, 테스트, 리뷰 - 각 단계는 필요로 하는 맥락이 다르다. 단계마다 적절한 컨텍스트만 전달하면 LLM의 유한한 컨텍스트 윈도우를 효율적으로 활용할 수 있고, 결과물의 품질도 높아진다.

2. 결정적 작업(Deterministic Tasks)과 비결정적 작업(Non-Deterministic Task)을 구분하라

모든 것에 LLM을 쓸 필요는 없다.

결정적 작업은 규칙 기반으로 항상 같은 결과를 내야 하는 작업이다. 린팅, 포매팅, 정적 분석, 타입 체크, 보안 스캔이 여기에 해당한다. 이런 작업에 LLM을 쓰면 불필요한 비용과 불확실성만 늘어난다. 전통적인 도구가 더 빠르고, 더 정확하고, 더 일관적이다.

비결정적 작업은 맥락 이해와 판단이 필요한 작업이다. 여기가 LLM이 진가를 발휘하는 영역이다:

• Tidying: 변수명 개선, 불필요한 중복 제거 같은 작은 정리 작업
• Reviewing: 잠재적 버그 탐지, 성능 이슈 지적, 컨벤션 위반 발견
• 문서화: 코드 주석, README, API 문서, CHANGELOG 작성
• 테스트 생성: 단위 테스트 작성, 엣지 케이스 도출, 테스트 커버리지 확장

결정적 작업은 CI 파이프라인에 맡기고, LLM은 비결정적 작업에 집중시켜라.

3. 변경 범위를 작게 유지하라

AI가 한 번에 수천 줄을 생성할 수 있다고 해서, 매번 수천 줄을 생성해야 하는 것은 아니다. 큰 변경은 리뷰어의 인지 부하를 높이고 병목을 유발한다. 충분히 검증 가능하고, 문제가 생겨도 쉽게 롤백할 수 있는 작은 단위로 변경을 쪼개야 한다.

그렇다고 무조건 작게만 유지하라는 것은 아니다. 핵심은 인지 부하 없이 자동 검증 가능한 범위를 찾는 것이다.

Kent Beck은 Tidy First?에서 리팩토링보다 작고 린팅보다는 의미 있는 'Tidying'이라는 개념을 제안한다. 예를 들어:

• 가드 클로즈로 중첩 조건문 펼치기
• 설명하는 변수명으로 매직 넘버 대체하기
• 죽은 코드 제거하기
• 함수 순서 재배치하기

이 정도 규모의 변경은 테스트만 통과하면 별도 리뷰 없이 머지해도 된다. 워크플로우를 잘 설계하면 이런 Tidying 작업을 AI가 자동으로 수행하고, 자동으로 검증하고, 자동으로 적용하는 것이 가능하다.

4. 인간 개입을 최소화할 수 있는 워크플로우를 만들어라

병목은 결국 인간이다. AI의 생산 속도를 인간의 리뷰 속도가 따라갈 수 없다면, 인간 개입을 최소화하여 AI 결과물을 검증할 수 있는 자동화된 워크플로우가 필요하다.

일반적으로 검증 워크플로우는 계층적으로 구성된다:

1차: 결정적 검증 (CI 파이프라인)

• 린팅, 포매팅, 타입 체크 통과 여부
• 테스트 스위트 전체 통과 여부
• 보안 스캔, 의존성 취약점 검사

2차: 비결정적 검증 (AI 리뷰어)

• PR이 생성되면 리뷰어 에이전트가 변경점을 분석
• 잠재적 버그, 성능 이슈, 아키텍처 위반 탐지
• PR 변경의 핵심 포인트 요약 및 개선 제안

3차: 범위 기반 자동 승인

• Tidying 수준의 작은 변경 + 1차/2차 검증 통과 → 자동 머지
• 버저닝을 유발하는 큰 변경 → 리뷰 생성

여기서 Conventional Commits 규칙이 에이전트에게 힌트를 줄 수 있다. 커밋 메시지에 feat:, fix:, refactor:, chore:, docs: 같은 타입과 !(breaking change) 표시를 강제하면, AI가 변경의 성격과 영향 범위를 명확히 판단할 수 있다.

chore: 미사용 import 제거          → 자동 머지 가능
refactor: 결제 로직 함수 분리      → AI 리뷰 후 자동 머지
feat!: 인증 API 응답 구조 변경     → 별도의 리뷰 프로세스 필요

이렇게 구성하면 버저닝을 유발하는 큰 변경이 아닌 chore, style, docs, refactor 수준의 변경은 1차/2차 검증만 통과하면 리뷰어 에이전트가 직접 머지할 수 있다. feat!, fix! 같은 breaking change나 feat 같은 의미 있는 변경만 별도의 리뷰 프로세스를 도입하면 된다.

이 워크플로우의 수준이 높아져서 다소 큰 변경마저도 리뷰 에이전트가 인간 지능 개입 없이 머지가능한 수준으로 고도화된다면 결국 대부분의 변경이 인간 개입 없이 자동으로 처리되고, 이 팀/프로젝트의 생산성은 큰 변곡점을 맞게 될 것이다.

5. 모든 개선이 팀의 자산으로 축적되게 하라

이것이 가장 중요하다.

AI 도입은 "좋은 도구를 사주면 끝나는" 문제가 아니다. 2025 DORA 리포트는 성공적인 AI 도입을 툴 문제가 아니라 시스템 문제로 정의하며, AI의 가치는 도구 그 자체보다 주변의 기술·문화적 환경에 Lock-in 된다고 말한다.

누군가 효과적인 프롬프트를 발견했다면, 그 프롬프트는 휘발되지 않고 팀 전체가 쓰는 도구에 반영되어야 한다. 누군가 실수를 방지하는 워크플로우를 만들었다면, 그 워크플로우는 개인의 습관이 아니라 팀의 시스템으로 자리 잡아야 한다.

개인이 발견한 베스트 프랙티스가 → 팀의 표준 워크플로우가 되고 → 버전 관리되며 → 지속적으로 개선되는 구조.

이 구조가 작동하려면, 조직은 명확하고 공유된 AI 스탠스(정책/기대치/허용 도구/적용 범위) 를 가져야 한다. DORA 리포트는 AI 도입의 긍정적 효과가 이런 "clear and communicated AI stance"의 존재에 의존하며, 이것이 있을 때 개인 효과와 조직 성과의 긍정적 영향이 증폭된다고 제시한다.

이것을 가능하게 하는 것이 AI 시대 리더십의 핵심 역할이다.

---

다음 편에서는 이 원칙들을 Claude Code의 Skills, Hooks, Plugins로 구현하는 구체적인 방법을 살펴보겠다.