[Weekly Stash/주간 채집] 2025년 9월 둘째주

1. [기사] 앤트로픽, 소송 합의금으로 2조 지급..."AI 저작권 인정 첫 사례"
2. [기사] 오픈AI, 생성형 AI 환각 해결 실마리 찾았다
3. [블로그] 모호성이 무너뜨리는 LLM 보안
4. [블로그] Context Engineering: AI 시대의 새로운 핵심 역량 
5. [논문리뷰] Scalable and Effective Generative Information Retrieval
6. [블로그] AI Agent Tool 이름의 중요성: 왜 중요할까?

🐿️ 친칠라의 주간 채집 🌱
한 주 동안 "나중에 살펴봐야지!" 하고 수집해 둔 링크들이 그대로 잊히지 않도록,
주말마다 가볍게 살펴보고 짧은 생각을 남깁니다.
주로 LLM이나 프롬프트 엔지니어링과 관련된 내용들을 스크랩하고,
본 전공인 국어학 쪽에서도 재미있는 내용이 있으면 가져올게요!

 

1. [기사] 앤트로픽, 소송 합의금으로 2조 지급..."AI 저작권 인정 첫 사례"

https://www.aitimes.com/news/articleView.html?idxno=202163

앤트로픽, 소송 합의금으로 2조 지급..."AI 저작권 인정 첫 사례" - AI타임스

이게 되네...?
AI 모델의 학습용으로 사용되는 데이터들의 저작권 관련 문제는 끊임없이 제기되어 왔다. 기사에 언급된 앤트로픽은 클로드 모델 학습을 위해 불법으로 디지털화된 도서들을 알면서도 다운로드했다는 이유로 고소를 당했다. 이건 앤트로픽에서만 일어나는 일은 아닐 것이고, 또 텍스트 데이터에 대해서만 일어나는 일도 아닐 것이다. 몇 년 전에 여러 그림 작가들이 본인들의 작품이 동의 없이 이미지 생성 AI 학습 데이터로 사용된 것에 대해 저작권 문제를 제기했던 것으로 기억한다. 영상, 음악, 성우들의 목소리, AI 서비스의 대상이 된다면 그 어떤 형태의 데이터로든 이런 일은 계속해서 이어져 왔을 것이다.
 
그렇지만 솔직히 빠른 시일 내에 이런 합의가 있을 것이라고는 기대하지 않았다. 학습용으로 사용되는 데이터를 일일이 추적하기도 어려울 것이고, 또 워낙 급박하게 변화가 일어나고 있다 보니 저작권법이 이러한 상황을 폭넓게 커버할 수 있을 수준이 되려면 시간이 꽤나 걸릴 것이라고 생각했다. 물론 소송을 통해 결론이 난 것은 아니고 작가들과 앤트로픽이 합의를 이룬 케이스이고, 중고책을 구입해 스캔해서 학습에 이용한 것은 공정 사용(fair use)이라는 판결이 있었으니 기사 제목처럼 'AI 저작권 인정 첫 사례'라고 거창하게 말할 만한 것인지는 약간 의문이 남는다.
(중고책 이용은 특히 정말 애매한 것 같다. 대가를 지급했으니 어떻게 사용하든 신경쓰지 말아야 하는 걸까? 아니면 누군가의 저작물을 영리적 목적으로 사용했으니까 여기에 대해서는 또다른 대가가 지급되어야 하는 걸까? 대학교 교재도 원래 '내돈내산'일지라도 개인적으로 제본하면 안 되는 거라는데. 다른 대가가 지급되어야 한다면 그 지급 시점과 액수 측정은 어떻게 결정해야 하는 걸까?)

나는 콘텐츠 창작자들의 저작권 보장에 꽤 관심이 있는 편인데, 그래서 (애매한 부분이 있다 할지라도) 참 고무적인 뉴스가 아닐 수 없다. AI의 발전이 창작자들의 설 자리를 뺏지 않고, AI와 창작자들이 상생할 수 있는 방법이 어쩌면 있을지도! 저작권에 대한 논의가 그 실마리가 될 수 있었으면 좋겠다.
 

2. [기사] 오픈AI, 생성형 AI 환각 해결 실마리 찾았다

https://www.digitaltoday.co.kr/news/articleView.html?idxno=590044

오픈AI, 생성형 AI 환각 해결 실마리 찾았다 - 디지털투데이 (DigitalToday)

막연하게 LLM이 환각을 일으키는 건 당연하지! 라고만 생각했는데, 환각의 원인이 '시험 모드'처럼 작동하는 학습 방식에 있다는 게 재미있었다. 학습 구조상 LLM은 불확실한 부분이 있어도 '모른다'거나 '확실하지 않다'고 대답하는 것보다 추측이라도 해서 답변을 하도록 장려받고 이것이 환각으로 이어진다는 것이다.
 
'정확성 기반 평가가 계속해서 추측을 보상하는 한, AI는 환각을 반복할 수밖에 없다'는 표현이 나온다. 정확성 평가라고 했다는 것은 곧 그동안 LLM은 정답을 정확하게 맞혀야 하는 문제에 적합하게 학습하고 평가받았다는 의미로 이해된다. 그래, 정답이 반드시 존재하는 온실 속에서 자랐으니 이 야생의 거친 현실을 어떻게 받아들이겠어... 하고 조금 측은한(?) 생각도 든다.
 
한 금융 도메인 콜봇의 감정분석 기능 개발에 참여한 적이 있다. 고객사 담당자 분의 말씀 중에 'recall보다는 precision이 우리에게는 훨씬 치명적이다'라는 말이 아직도 뇌리에 남아 있다. 예를 들어 실제 '분노' 발화를 '분노'로 잘 분류하는 것도 잘 하면 좋겠지만, '분노'로 분류된 발화들 중에 실제로는 '분노'가 아닌 케이스가 없는 게 더 중요하다는 것이다. recall과 precision에는 trade-off가 있으니, recall이 좀 떨어지더라도 precision을 우선적으로 봐달라며 f1 score도 precision에 가중치를 둔 수치로 정리해달라고 하셨다. 그분이 그렇게 말씀하시기 전에는 당연히 recall과 precision이 둘 다 중요하다고만 생각했고, 어느 쪽이 사용자의 편의성에 더 큰 영향을 미치는지까지는 고려하지 못했었다. 사용자 경험에 따라 집중해야 할 부분이 달라지고, 필요한 성능 지표도 달라진다는 것을 체감한 순간이었다.
 
환각은 어떤 도메인이든 LLM을 서비스에 도입하려고 할 때 반드시 부딪히게 되는 장벽인 것 같다. 아무리 context를 잘 주고 문서를 잘 파싱해서 RAG를 구성한다 해도 환각을 100% 통제할 방법이란 없어 보인다. 그런데 이게 '장벽'으로 느껴진다는 것 자체가, 좀 불확실해도 열심히 추측을 해서 대답을 내놓는 LLM보다, 차라리 '그건 불확실하고 나는 그런 건 모른다'라고 대답하는 LLM이 현실 세계의 우리에게는 더 유용하다는 뜻이라고 생각한다. OpenAI의 다음 모델에서는 환각이 확 줄어들 거라고 기대해도 되려나?
 
 

3. [블로그] 모호성이 무너뜨리는 LLM 보안

https://velog.io/@gnl010/aisecurity

모호성이 무너뜨리는 LLM 보안

프롬프트 인젝션이나 탈옥은 관심 있는 주제이지만 나는 핫한 탈옥 프롬프트를 다소 늦은 타이밍에 접하는 편이기 때문에 제대로 성공해본 적은 없다. 그래도 여기저기 기웃거리며 주워들은 기법들을 가벼운 서비스 봇들에 가끔씩 써보는데, 기존 답변 톤이 무너지는 걸 보면 희열(?)이 느껴지면서도 내가 참여하고 있는 서비스들은 어떡하지 하는 걱정도 든다.
 
이 글은 여러 프롬프트 인젝션 기법을 간단히 정리해 준 점도 좋은 참고가 되었지만, LLM의 안전 정렬을 무너뜨리는 것이 '의도된 모호성'이라는 표현으로 딱 짚어준 점이 내 마음에 와닿았다. 거짓말과 기만, 가스라이팅의 핵심은 진실과 거짓의 경계를 흐리게 만드는 데 있다. LLM을 상대로도 마찬가지인 것이다. 본심인 유해 의도를 새로운 형식과 표현으로 모호하게 감싸면 LLM의 눈을 가리고 학습한 안전 패턴의 범위를 벗어나도록 만들 수 있다.
 
그러고 보니 이거, 류츠신의 "삼체"에서도 비슷한 이야기가 있었는데... 삼체인들은 지구인들과 소통하며 지구인에게 '생각하다'와 '말하다'가 동의어가 아니라는 것을 받아들이기 어려워했다. 그들에게는 기만이라는 개념이 존재하지 않았다. 지구인은 누구나 거짓말을 한다는 사실이 삼체인에게는 위협이 되었고, 지구인들은 이것을 무기 삼아 면벽 프로젝트를 진행했으며, 삼체인들은 결국 기만이라는 기술을 습득했다. AI가 삼체인들처럼 자아를 갖고 인간의 기만에 위협을 느끼며 진화할 거라고 생각하는 건 아니지만... 아무튼 인간처럼 남을 기만할 줄 모르는 AI가 알아서 유해한 발화를 판독하고 거르도록 하는 건 쉽지 않은 일이다. 글을 읽으며 모든 공격을 막을 단 하나의 완벽한 방법이란 존재하지 않으니 방어 방안을 촘촘하게 설계하는 게 중요하겠다는 생각을 했다. 여러 단계에 걸쳐서(데이터 수집부터 배포 단계까지), 여러 기술을 종합적으로 고려해서(모델 학습 방식부터 프롬프트 엔지니어링까지) 전술을 짜야 하는구나 싶다. 여기도 보이지 않는 치열한 전쟁이네.
 

4. [블로그] Context Engineering: AI 시대의 새로운 핵심 역량

https://devocean.sk.com/blog/techBoardDetail.do?ID=167772&boardType=techBlog

Context Engineering: AI 시대의 새로운 핵심 역량

한동안은 프롬프트 엔지니어링이라는 단어가 무슨 마법의 키워드인 것처럼 시끌시끌했는데, 요즘은 컨텍스트 엔지니어링이 그런 것 같다. 컨텍스트 엔지니어링은 프롬프트 엔지니어링의 확장판으로, 단순히 프롬프트 문구 자체만 신경 쓰는 게 아니라 컨텍스트를 어떻게 관리하고 유지하고 처리할지까지 설계하는 데 주안점을 둔다. 프롬프트 엔지니어링에 비해 시스템 아키텍처에 대한 이해나 기술적인 지식이 좀 더 필요한 영역이라고 보는 것 같다.
 
효과적인 컨텍스트 설계에 대한 논의는 환영하지만, 사실 컨텍스트에 대한 고민은 프롬프트를 쓰다 보면 자연스럽게 닿을 수밖에 없는 부분이라 '프롬프트 엔지니어링'과 '컨텍스트 엔지니어링'을 이렇게까지 구분하고 싶어하는 건 좀 의아하게 느껴진다. 프롬프트 엔지니어를 직업으로 삼는 사람치고 글에서 말하는 컨텍스트 엔지니어링을 안 하는 사람이 과연 있을까? (물론 기술 스택에 따라 어느 범위까지 커버하느냐는 케바케겠지만...) 아까 내가 컨텍스트 엔지니어링이 프롬프트 엔지니어링의 '확장판'이라는 표현을 썼는데, 내가 느끼기에는 오히려 컨텍스트 엔지니어링이 프롬프트 엔지니어링의 한 부분 같다. 애초에 용어부터가 프롬프트 '라이팅'이 아니라 프롬프트 '엔지니어링'이었으니, 프롬프트 엔지니어링이라는 분야 자체가 확장이 된 것이고 그 분야 안에 컨텍스트 설계와 관리, 프롬프트 문구 설계 및 작성이 포함된다고 보는 게 더 맞는 설명이 아닐까 싶다. 그렇지만 모든 용어란 곧 사회적 합의이니 어느 쪽으로든 용어가 자리잡으면 일단 따라가야지 뭐.
 

5. [논문리뷰] Scalable and Effective Generative Information Retrieval

https://obsidian-blog-gilt.vercel.app/paper-review/Scalable%20and%20Effective%20Generative%20Information%20Retrieval/

Scalable and Effective Generative Information Retrieval

Generative Retrieval이라니 생성 검색이 대체 뭐야? 하고 궁금했지만 차마 논문 원문을 읽어보지는 못하고... 논문 리뷰를 찰지게 남겨주시는 분의 블로그로 대략 훑었다. Generative Retrieval의 기본 아이디어는 문서 임베딩 후 계층적인 K-means 클러스터링을 수행해서 군집을 만들고, 그렇게 만들어진 군집을 바탕으로 문서마다 ID를 부여한다는 것. 어떤 질문에 어떤 ID를 출력해야 하는지를 학습시키면, 질문에 더 정확하게 대답하는 모델을 얻을 수 있다는 것이다. 그래서 이 ID는 문서들끼리의 연관성을 나타낼 수 있도록, 비슷한 ID의 문서는 의미론적으로 비슷해야 하며 반드시 계층적인 구조로 이루어져야 한다고 한다. (처음에는 HyDE처럼 가상의 문서를 생성하게 해서 검색에 활용하는 걸 생성 검색이라고 하나, 하면서 클릭했는데 전혀 다른 내용이었다...)
 
이 글에서 리뷰한 논문은 Generative Retrieval을 처음 소개한 논문은 아니고, 기존 방식의 성능적 한계를 극복하기 위한 새로운 방식을 제안했다는 데 의의가 있다. 완벽히 이해하지는 못했지만 기존의 방식은 문서 ID 생성에 비효율적인 면이 있었고, 그래서 올바른 ID를 생성하게 하기 위한 최적화 방식을 찾아가려 했다, 정도는 이해했다. 문서 ID가 계층적인 구조를 따르기 때문에 문서에 따라 ID 길이가 달라지게 되고, 짧은 ID와 긴 ID를 모두 잘 생성하도록 하기 위한 방법을 열심히 고안했다...는 부분도 이해한 것 같다. 잘 모르겠어도 최대한 끝까지 따라가 보려고 했는데, 훈련 과정 파트에서는 결국 포기했다. 전공자들의 연구 내용을 한번에 이해하려고 한 내 욕심이 잘못했지... 하고 있었는데 작성자분이 코멘트에 '훈련 과정이 너무 복잡하다. 몇 번을 샘플링을 하는지 모르겠다. 그리고 하나라도 안하면 성능이 떨어지는 부분 역시 아쉽다.'라고 쓰신 걸 보고 좀 위안을 얻었다. 일단은 Dense Retrieval과 Sparse Retrieval의 개념도 최근에서야 알게 된 나의 뇌 속에 Generative Retrieval이라는 대안을 추가했다는 데에 만족해야겠다.
 

6. [블로그] AI Agent Tool 이름의 중요성: 왜 중요할까?

https://slashpage.com/sujin-prompt-engineer/prompt_tips?post=d367nxm3qz86jmj98pv1

AI Agent Tool 이름의 중요성: 왜 중요할까? - sujin-prompt-engineer

회사 동료들과 프롬프트 이름의 체계를 잡는 것에 대해 고민해본 적이 있는데, MCP의 세상이 오니 툴 이름의 작명도 하나의 과제가 되었구나 싶다. 좀 다른 점은 프롬프트 이름은 사용하는 사람들의 혼선 방지와 원활한 소통을 위한 것이었지만 툴 이름은 AI 에이전트의 툴 콜링 결과에 영향을 주고 따라서 서비스상의 성능과도 관련된다는 점일까.
 
글에서 언급된 동사(행동) + 객체(object) 구조나, 공통 prefix/suffix를 사용한다는 점이 결국 동료들과 정한 프롬프트 네이밍 규칙과 얼추 비슷해서 조금 안심이 되었다. 우리 꽤 괜찮은 방향으로 가고 있었구나!
 
인용된 Anthropic 글에서 prefix와 suffix 중 어떤 것이 효과적이냐는 모델마다 다르다는 이야기가 나온다. 실험이 필요하다는 게 또다른 영원한 과제가 되겠지만 또 이런 게 있어야 탐구하는 재미가 있는 법이다. 기억해 뒀다가 실험해 볼 기회가 생기면 꼭 해봐야지.

We have found selecting between prefix- and suffix-based namespacing to have non-trivial effects on our tool-use evaluations. Effects vary by LLM and we encourage you to choose a naming scheme according to your own evaluations.