🤖 1424 in / 4003 out / 5427 total tokens

AI 업데이트: 프롬프트 엔지니어링 진화, 서브도메인 하이재킹, 그리고 군사 AI의 가속화

🔥 핫 토픽

1. Simon Willison의 GPT-5.5 프롬프팅 가이드 — 프롬프트 엔지니어링이 여전히 핵심 기술이다

Simon Willison이 공개한 GPT-5.5 프롬프팅 가이드는 단순한 사용법 정리가 아니다. 이 가이드는 모델이 점점 강력해질수록 프롬프트 작성 방식 자체가 '코딩'과 유사한 구조적 사고를 요구하게 된다는 사실을 보여준다. 변수 바인딩, 조건 분기, 출력 포맷 제약 같은 개념들이 프롬프트 안에 녹아들고 있고, 이건 게임 개발에서 스크립트 시스템 설계할 때와 닮은 구석이 있다. Blueprint 노드에서 입력->처리->출력 흐름 잡는 거랑 본질적으로 같은 패턴이다.

왜 중요하냐면, Claude 같은 모델을 실제 프로덕션에 붙일 때 '잘 물어보는 기술'이 아닌 '명세를 정확하게 전달하는 엔지니어링'이 필요하다는 걸 명확히 해주기 때문이다. 특히 Anthropic의 Claude는 system prompt를 통한 제어력이 강한 편인데, 이 가이드에서 다루는 구조적 프롬프팅 기법들은 Claude의 특성에도 직접 적용된다. 실무에서 AI를 API로 호출해 결과를 파이프라인에 넣는 입장에서는, 프롬프트가 곧 설정 파일이자 인터페이스 명세가 된다.

또 하나 주목할 점은 가이드가 모델 버전별로 프롬프트 전략이 달라야 한다는 뉘앙스를 풍긴다는 거다. GPT-4o 때 잘 되던 프롬프트가 5.5에서는 오히려 과도한 제약이 될 수 있고, Claude 3.5 Sonnet과 Opus 사이에서도 비슷한 현상이 있다. 모델 진화가 빨라지면서 프롬프트 버전 관리라는 새로운 영역이 생겨나고 있고, 이건 개발자에게 또 하나의 유지보수 부담이자 기회이기도 하다. 결국 LLM 시대의 개발자는 모델 버전, 프롬프트, 출력 스키마 세 축을 동시에 관리해야 한다.

개발자 입장에서 챙겨야 할 건: 프롬프트를 코드처럼 버전 관리하라. Git에 텍스트로 커밋하지 말고, JSON이나 YAML 같은 구조화된 포맷으로 관리하라. 템플릿 엔진(Jinja2 등)과 결합해서 변수 주입을 체계적으로 하라. 안 그러면 3개월 뒤에 자기가 쓴 프롬프트 해석하느라 하루를 날린다.

출처: Simon Willison - GPT-5.5 Prompting Guide

📰 뉴스

2. 대학 서브도메인이 포르노를 서빙하고 있다 — 서브도메인 하이재킹의 현실

수십 개 대학의 수백 개 서브도메인이 사기꾼들에게 하이재킹당해 포르노 콘텐츠를 서빙하고 있다는 Ars Technica 보도는, AI 시대의 보안이 모델 자체만이 아니라 '인프라 관리'에 있다는 걸 적나라하게 보여준다. 원인은 단순하다. 과거에 생성된 서브도메인이 DNS 레코드는 남아있는데 실제 가리키는 리소스(CNAME, A레코드 대상)는 사라진 상태. 이른바 'Dangling DNS' 문제다. 공격자는 해당 클라우드 리소스를 자기 계정으로 다시 확보해서, 대학 도메인의 신뢰도를 빌려 원하는 콘텐츠를 올리는 방식이다.

이게 왜 AI 개발자에게 중요하냐. AI 서비스 인프라도 똑같은 구조적 취약점을 가지고 있기 때문이다. 예를 들어, Claude API를 연동하는 웹 서비스에서 A/B 테스트용으로 띄웠던 서브도메인(demo.your-ai-product.com)이 있다고 치자. 테스트 끝나고 EC2 인스턴스나 S3 버킷은 삭제했는데 Route 53 레코드는 지우지 않았다. 그럼 누구나 해당 버킷명을 다시 생성해서 your-ai-product.com의 서브도메인 제어권을 가로챌 수 있다. AI 프로덕트는 특히 API 키, 웹훅 엔드포인트, 콜백 URL 같은 걸 서브도메인에 많이 물리기 때문에 노출 면적이 넓다.

이 문제는 앞서 언급한 프롬프트 엔지니어링 이슈와도 연결된다. 프롬프트 인젝션 공격이 모델 수준의 취약점이라면, 서브도메인 하이재킹은 인프라 수준의 취약점이다. 둘 다 '신뢰 경계(boundary of trust)'가 어디인지 명확히 정의하지 않았을 때 발생한다. 게임 서버 개발할 때도 비슷했다. 클라이언트가 보내는 패킷을 무조건 신뢰하면 망하고, 서버 사이드 검증을 철저히 해야 한다는 원칙. AI 서비스도 마찬가지다. 모델 출력, API 응답, 웹훅 페이로드—모두 외부 입력으로 취급하고 검증해야 한다.

실제 대응책은 의외로 단순하다. DNS 레코드 인벤토리를 자동화하라. AWS라면 Route 53 + CloudTrail 로그를 크롤링해서 dangling record를 탐지하는 Lambda를 하나 돌리면 된다. GitHub Actions에 DNS 감사 스텝을 넣는 것도 방법이다. 핵심은 '사람이 기억해서 정리한다'는 걸 가정하지 않는 거다. 인프라 관리도 결국 코드로 해야 자동화된다.

출처: Ars Technica - University Websites Serving Porn

3. Project Maven — 군사 AI가 실전에 배치되는 속도가 무섭다

The Verge의 Project Maven 심층 보도는 미군의 AI 활용이 연구 단계를 넘어 실전 작전에 완전히 통합되었음을 보여준다. 이란 공격 첫 24시간에 1,000개 이상의 타겟이 타격됐는데, 이건 2003년 이라크전 '쇼크 앤 드'의 거의 두 배 규모다. 이 속도의 핵심에 AI 기반 타겟 식별 및 분류 시스템이 있다. 인간 분석가가 위성 이미지 하나하나 보고 타겟을 선정하던 시대는 끝났다. AI가 후보를 걸러내고, 인간이 최종 승인하는 'human-in-the-loop' 구조—but loop가 점점 짧아지고 있다.

이 뉴스가 개발자에게 중요한 이유는, 'AI의 실제 영향력'이 어디서 발휘되는지 보여주기 때문이다. 우리가 매일 다루는 Claude, GPT 같은 모델은 챗봇이나 코드 생성에 쓰이지만, 같은 기술의 변형이 사람의 생명에 직결된 의사결정에 쓰이고 있다. 기술적으론 객체 탐지(object detection), 자연어 명령 파싱, 멀티모달 분석—우리가 익숙한 것들이다. 그런데 이게 무기 시스템의 트리거에 연결되어 있다. 'AI 안전성'이 Anthropic이 강조하는 Constitutional AI 같은 원칙이 아니라, 현장에서는 생사를 가르는 문제라는 걸 체감하게 해주는 대목이다.

Anthropic은 군사 용도를 제한하는 사용 정책을 명시적으로 가지고 있다. Claude의 사용 규약에 '무기 개발 및 군사 작전' 관련 사용 금지 조항이 있다. 하지만 Project Maven 같은 사례는 이 경계가 모호해지고 있음을 시사한다. AWS, Google, Microsoft 같은 클라우드 제공사는 이미 방산 분야와 계약을 맺고 있고, 테크 기업의 '군사 협력 거부'는 점점 상징적 의미만 남고 있다. 개발자 입장에서도 자기가 만든 모델이나 파이프라인이 최종적으로 어디에 쓰이는지 추적하기 어려워지는 구조다.

앞선 두 뉴스와 연결해보면 한 가지 공통점이 보인다. 프롬프트 엔지니어링이든, 인프라 보안이든, 군사 AI든—모두 '인간의 통제력'이 어디까지 유효한가라는 질문으로 귀결된다. 프롬프트로 모델을 제어하려다 보면 한계가 있고, DNS 레코드 관리를 사람에게 맡기면 빈틈이 생기고, 군사 AI의 휴먼 인더 루프도 속도 압력에 의해 허술해진다. 결국 시스템 설계 단계에서 '인간의 실패 가능성'을 전제로 안전장치를 설계해야 한다는 교훈이다. 게임에서도 anti-cheat 시스템을 '사람이 언젠가 실수한다'는 전제로 짜듯이.

출처: The Verge - How Project Maven Taught the Military to Love AI

💭 개발자 관점 정리

이번 주 세 가지 뉴스는 각각 다른 영역(모델 인터랙션, 인프라 보안, 실세계 영향)에 해당하지만, 공통된 메시지가 있다. AI 시스템의 통제력은 모델 자체의 성능이 아니라, 그걸 감싸는 인프라와 프로세스의 견고함에 달려 있다. 프롬프트를 코드처럼 관리하고, DNS를 코드처럼 감사하고, AI의 윤리적 경계를 코드처럼 명세해야 한다. 감에 의존하는 관리는 다 빈틈이 된다.

프롬프트도 코드고, DNS 레코드도 코드고, 사용 정책도 코드다. 관리를 자동화하지 않은 건 결국 '언젠가 터질 버그'를 예약하는 것과 같다.