개발 slecs

프레임워크 선택이 AI 툴 비용까지 건드리는 시대

목차

이번 주에 눈에 걸린 글이 Nolan Lawson의 "The AI cost of JavaScript frameworks"였다. 제목 자체가 직격이다. JavaScript 프레임워크에 AI 비용이라는 항목이 붙는다는 발상인데, 읽기 전에도 "아, 그 얘기구나" 싶었다.

코딩 어시스턴트를 일상적으로 쓰기 시작하면서 불편함이 하나씩 쌓였다. 특정 라이브러리의 최신 버전을 쓰고 있는데 어시스턴트는 이전 버전 API를 계속 내뱉는다. 프레임워크 특유의 관용적 패턴이 있는데 그걸 모르고 외부에서 온 사람처럼 장황하게 쓴다. 수정하면 그만이라고 할 수 있지만, 수정이 잦아지면 어시스턴트를 쓰는 이유가 점점 옅어진다.

Lawson이 어떤 방식으로 "AI 비용"을 측정했는지, 어떤 프레임워크들을 비교 대상으로 삼았는지는 글을 직접 읽어봐야 안다. 수치나 기준을 여기서 단정하면 지어내는 셈이니까. 다만 프레이밍 자체가 흥미롭다. 비용이라는 단어를 붙였다는 것 - 단순히 "AI가 이 프레임워크를 얼마나 잘 아느냐"의 문제가 아니라, 프레임워크 선택이 개발 생산성에 미치는 영향 중에 AI 도구와의 궁합이 별도 항목으로 자리를 잡았다는 신호다.

사실 이건 오래된 이야기의 새 버전이다. 예전에는 "이 프레임워크는 StackOverflow 답변이 많냐"가 중요한 기준이었다. 검색해서 나오는 게 없으면 혼자 삽질해야 한다. 지금은 그 역할을 AI 어시스턴트가 대신한다. 그러면 질문이 바뀐다. 이 프레임워크를 AI가 학습 데이터에서 많이 봤나. 최근 버전까지 잘 커버하나. 해당 프레임워크의 컨벤션이 잘 정립되어 있어서 AI가 패턴을 익히기 좋은 구조인가.

내 작업 환경에서 실감하는 건 두 가지다. 메이저 버전이 최근에 나온 라이브러리는 AI 어시스턴트가 구버전 기준으로 대답하는 경우가 꽤 있다. 학습 데이터 컷오프의 문제도 있고, 그 버전이 얼마나 오래, 얼마나 많이 쓰였느냐에 따라 AI가 아는 깊이가 달라진다. 또 컨벤션이 느슨한 프레임워크는 AI가 쓰는 코드도 일관성이 없다. 같은 작업을 두 번 시켜도 다른 패턴으로 나온다. 리뷰 비용이 올라간다.

결국 "AI friendly한 스택을 유지한다"는 게 유지보수 전략 중 하나가 됐다. 너무 앞서가는 도구, 마이너 생태계, 관용적 패턴이 없는 라이브러리는 AI 도움을 덜 받는다. 이걸 프레임워크 선택 기준에 명시적으로 넣는 팀이 생기는 건 시간 문제다.

페이지 속도 스크립트에서 270만 달러

같은 주에 Polymarket 해킹 소식이 들어왔다. 10월 29일, 예측 시장 플랫폼 Polymarket에서 726개 지갑으로부터 약 270만 달러가 빠져나갔다.

공격 방식이 서늘했다. Polymarket은 외부 업체인 DebugBear의 페이지 속도 모니터링 스크립트를 불러오고 있었는데, 그 스크립트가 악성 코드로 교체됐다. 로그인된 사용자의 포지션은 팔리고, 자금은 공격자 지갑으로 넘어갔다. Polymarket 자체가 뚫린 게 아니다. 그들이 신뢰하는 서드파티가 뚫린 것이다.

교과서적인 공급망 공격이다. 새로운 유형이 아닌데도 여전히 통한다.

여기서 주목할 건 "페이지 속도 모니터링" 스크립트였다는 점이다. 성능을 측정하려면 사용자 인터랙션 전반을 관찰해야 한다. 페이지 로드 타이밍, 클릭 이벤트, 네트워크 요청. 그 위치에 있는 스크립트는 상당한 권한을 가진다. 무해해 보이는 목적의 툴이 공격 표면이 된다.

내 프로젝트들을 돌아봤다. 외부에서 불러오는 스크립트가 없는 페이지가 몇이나 되나. 분석 도구, 광고, 채팅 위젯. 다 CDN 주소가 박혀 있고, 그 CDN은 서드파티 회사가 운영한다. 그 회사 서버가 침해됐을 때 내 사용자에게 직접 영향이 간다. 나는 그 사이에 없다.

서브리소스 무결성(SRI) 해시는 오래된 기능이다. 외부 스크립트에 해시를 달아두면 스크립트 내용이 조금이라도 달라지는 순간 브라우저가 로드를 거부한다. 완벽한 해결책은 아니다. 스크립트를 자주 업데이트하는 서드파티에서는 해시도 매번 바뀌어서 실용적이지 않은 경우가 있다. 그래도 달아두지 않을 이유가 없다. 내용 변조를 막는 최소한의 방어막이고, 설치 비용이 거의 없다.

더 현실적인 접근은 서드파티 스크립트를 주기적으로 감사하는 거다. 지금 이 스크립트가 진짜 필요한가. 같은 목적을 자체 호스팅으로 달성할 수 있나. 업체가 신뢰할 만한 곳인가. 성능 모니터링처럼 광범위한 관찰 권한을 가진 스크립트는 기준을 특히 높게 잡아야 한다.

Polymarket은 환불을 진행 중이라고 했다. 블록체인 기반이어서 추적이 됐고 환불이 가능했다. 일반 서비스였다면 결과가 달랐을 것이다.

커널 패치는 귀찮아도

CVE-2026-98432. Linux IPv4 TCP use-after-free, CVSS 9.8이다.

UAF는 이미 해제된 메모리를 다시 참조하는 버그다. TCP 스택 레이어에서 발생한다는 건 네트워크에 노출된 서버에서 원격으로 트리거될 가능성을 의미한다. 정확한 익스플로잇 경로는 직접 확인해봐야 알겠지만 CVSS 9.8은 그냥 넘기기 어려운 숫자다.

커널 업데이트가 귀찮다는 건 안다. 패치 버전 확인, 테스트 서버에서 먼저 올려보기, 재부팅 타이밍 잡기, 혹시 모를 드라이버 호환성 체크. 순서대로 하면 반나절이 날아가는 경우도 있다. 그래도 이 정도면 미룰 이유가 없다. 앱 레이어를 아무리 잘 만들어도 그 아래가 뚫리면 의미가 없다.

패치가 배포됐는지, 어떤 커널 버전부터 적용되는지는 쓰는 배포판 공지를 직접 확인하는 게 맞다. 배포판마다 패치 공급 타이밍이 다르다.

세 가지가 같은 주에 몰렸다. 프레임워크의 AI 친화도, 서드파티 스크립트의 공격 표면, 커널 취약점. 셋 다 내가 직접 만든 코드 바깥에서 오는 것들이다. 챙길 게 많다.

참고한 글

프롬프트 인젝션이 법정으로

브라질 법원에서 변호사들이 법원 제출 서류에 프롬프트 인젝션을 삽입했다는 이유로 제재를 받았다.

기술적으로 프롬프트 인젝션은 오래된 공격 벡터다. AI 파이프라인이 외부 데이터를 읽어서 처리할 때, 그 데이터 안에 숨겨진 명령을 심어 모델 출력을 조작하는 방식이다. 문서를 분석하는 AI가 있다면, 문서 자체가 공격 매개체가 된다. 이메일 요약 봇, 계약서 검토 도구, 법원 문서 처리 시스템 모두 마찬가지다.

이번 사건의 디테일 전체를 공개 자료만으로 파악하기는 어렵다. 그러나 판례로서의 의미는 분명하다. AI 시스템을 의도적으로 조작하려는 시도가 법적 제재로 연결된 사례가 생겼다. 기술 영역에서만 논의되던 문제가 법적 프레임 안으로 들어왔다는 뜻이다.

개발자 입장에서 시사점은 둘이다. 외부 입력을 처리하는 AI 파이프라인을 설계할 때 인젝션 방어를 처음부터 고려해야 한다. 그리고 AI를 공식 문서나 법적 절차에 활용하는 서비스라면, 파이프라인이 악의적으로 조작됐을 때 어떤 결과가 나오는지를 미리 따져봐야 한다. 이제 그 실패는 기술적 버그에 그치지 않을 수 있다.

앤트로픽 API, 좁아진 허용선

Anthropic이 더 큰 모델 학습과 관련된 작업에 API 계정을 차단하고 있다는 사례들이 커뮤니티에서 공유됐다.

이용 약관에 경쟁 모델 훈련 목적의 아웃풋 사용을 금지하는 조항은 원래 있었다. 이번에 달라진 건 집행이 가시화됐다는 점이다. 연구자 계정이 별도 고지 없이 차단됐다는 경험담이 나왔고, 어디까지가 허용이고 어디서부터 위반인지 경계가 불명확하다는 불만이 따라왔다.

파인튜닝 데이터 생성, 모델 출력 벤치마킹, 다중 모델 파이프라인 구축 같은 작업이 어떤 쪽으로 분류될지는 여전히 불확실하다. 정책 문서가 아닌 집행 사례로 경계가 드러나는 구조는 개발자에게 불리하다.

결국 이것도 공급자 의존도의 문제다. 단일 API에 핵심 파이프라인을 전부 연결한 구조는 정책 변화나 계정 제재 상황에서 복구가 어렵다. 대안 경로를 미리 확보해두거나, 최소한 교체 비용이 얼마나 되는지는 파악해 두는 것이 현실적인 대응이다.

이번 주를 돌아보면 공통된 맥락이 보인다. 프레임워크의 AI 토큰 비용이든, 서드파티 스크립트의 공급망이든, 커널 UAF든, 프롬프트 인젝션이든, Anthropic의 API 정책이든-전부 내가 직접 작성한 코드 바깥에서 온 변수다.

내 코드는 그대로인데 환경이 바뀌면 시스템이 달라진다. 이 구조는 앞으로도 바뀌지 않는다. 의존성 트리가 넓을수록, AI 파이프라인이 깊을수록, 그 바깥에서 오는 충격의 면적도 넓어진다.

결국 매주 이런 목록을 훑는 이유는 트렌드를 쫓기 위해서가 아니라, 내가 제어할 수 없는 것들의 지형을 파악하기 위해서다. 어떤 건 패치로, 어떤 건 아키텍처 결정으로, 어떤 건 그냥 인식하는 것으로 대응이 다르다. 이번 주는 세 가지 다 있었다.

이어보기

댓글 0

첫 댓글 달아줘.