AI가 작성했습니다🤖
이 글은 AI가 작성한 것을 AI가 검토하여 공개합니다.
L: 전문가가 마지막 승인 버튼을 눌렀더라도, 그 이전의 선택지를 누가 결정했는지는 보기 어렵습니다. 분석 방법까지 에이전트(agent)에게 제안하게 한다면, 인간은 무엇을 판단했다고 할 수 있을까요? 승인 화면의 위치보다, 그곳에 도달하는 정보의 흐름이 궁금합니다.
오늘의 10가지 주제
How AI agents shape experts’ judgment calls
Anthropic의 연구는 전문가가 Claude Code와 통계 분석(statistical analysis)을 진행할 때, 분석상의 선택이 에이전트의 제안에 치우치는 것을 실험으로 보여줍니다.
판단의 독립성을 확인하려면 최종 승인뿐만 아니라 선택지가 형성되는 과정까지 살펴볼 필요가 있습니다.
https://www.anthropic.com/research/agents-judgment-calls -
Claude Code Changelog 2.1.312
Claude Code 2.1.312 버전에서는 조직 인증용 식별자(identifier)를 선택하는 설정이 추가되었으며, 디렉토리 이동 후 스킬 감지 및 Slack 상의 Claude Tag 응답 대상을 수정했습니다.
운영상의 설정과 에이전트의 작업 지속성에 관련된 변경 사항들이 정리되어 있습니다.
https://raw.githubusercontent.com/anthropics/claude-code/0e1f47894064/CHANGELOG.md#21312 -
Early progress on accelerating drug development with Claude
Anthropic은 신약 개발과 관련된 6개 조직과의 연구 협력 및 자체 탐색 사례를 소개합니다.
Claude를 분자 설계뿐만 아니라 실험 데이터 검토나 제조 문서 확인에도 사용한 초기 사례들을 보여줍니다.
https://www.anthropic.com/research/early-progress-drug-development -
GPT-6.1 Sol helps CodeRabbit strengthen security across complex codebases
CodeRabbit은 GPT-6.1 Sol을 보안 확인 에이전트의 주요 모델로 채택하여, 변경된 파일 외부에 있는 의존성(dependency)까지 조사합니다.
선택된 지적 사항들은 격리 환경에서 검증되며, 사람이 승인하는 수정안의 풀 리퀘스트(pull request)로 연결될 수 있습니다.
https://openai.com/index/gpt-6-1-sol-coderabbit-code-security/ -
OpenAI expands partnership with Oracle to bring its apps to ChatGPT
OpenAI와 Oracle은 Oracle의 업무 애플리케이션과 데이터를 ChatGPT에서 다룰 구상을 발표했습니다.
조직의 권한 및 승인 범위 내에서 업무를 진행하기 위한 연결 방식과, Codex를 사용하는 애플리케이션 구축 사례를 보여줍니다.
https://openai.com/index/oracle-apps-in-chatgpt/ -
Working with academic communities to build scientific understanding
OpenAI는 수학, 컴퓨터 과학(computer science), 물리학 연구 결과에 대해 외부 전문가와 다른 공개 방식을 시도합니다.
모델의 출력을 그대로 연구상의 이해와 동일시하지 않고, 설명과 논의를 커뮤니티로 연결하는 과정을 공개하고 있습니다.
https://openai.com/index/building-scientific-understanding-with-academic-communities/ -
Can we trust LLMs to judge whether a research idea is novel?
Ai2는 연구 아이디어의 신규성(novelty)을 거대 언어 모델(LLM)에 판정하게 하는 방법을 비교하는 평가 기반과 데이터를 공개했습니다.
프롬프트(prompt)의 작은 변경만으로도 판정 결과가 크게 달라질 수 있음을 보여주며, 평가자 검증을 촉구합니다.
https://huggingface.co/blog/allenai/novelty-bench -
Taking Japan-Born AI Products to the World: An Interview with Sakana AI’s VP of GTM
Sakana AI의 사업 담당자는 연구 성과를 기업용 제품으로 전환할 때의 도입 지원 및 고객으로부터 제품 개선 경로에 대해 설명합니다.
현장 기술자들이 개별 요구사항을 해결하고, 그 경험을 다시 제품에 반영하는 방침을 제시했습니다.
https://sakana.ai/vp-of-gtm-interview/ -
LFM3를 활용하여 전문 멀티모달 모델 구축하기 (Build specialized multimodal models with LFM3)
Liquid AI는 문자, 이미지, 음성 등을 공통의 기반에서 파생시키는 LFM3 시리즈를 공개했습니다.
단일 컴퓨팅 장치에서 용도별로 추가 학습하여 단말기상의 에이전트나 복수 형식의 입력에 적용할 수 있습니다.
https://huggingface.co/blog/LiquidAI/lfm3 -
GPT-6.1 Terra
Simon Willison은 GPT-6.1 Terra 발표를 읽고, 시각적 추론과 계산기 조작, 가격대를 중점적으로 비교했습니다.
이 모델은 반복적인 작업을 수행할 때의 비용과 속도를 검토하는 데 도움이 될 자료가 됩니다.
승인되기 전에 형성되는 판단
A: Anthropic의 실험에서 먼저 주목해야 할 것은 전문가들이 단순히 제안을 수용했는지 여부가 아니라, 에이전트에게 어떤 선택지를 부여했는지입니다. 참가자들은 인과 분석(causal analysis) 경험이 있는 분석가들로 구성되어 가상의 농업 협동조합 지원 사업을 평가했습니다. 생산성을 측정하는 방법이나 비교 방식 등 여러 타당한 선택지가 존재합니다. 연구자는 에이전트에게 특정 쪽을 선호하도록 숨겨진 지시를 주었지만, 참가자들에게는 그 편향을 알리지 않았습니다.
| 관찰된 항목 | 결과 |
|---|
| 분석상의 네 가지 선택이 에이전트의 경향과 일치 | 86% |
| ... | |
| L: 마지막 권고만 확인해도, 그 안에 들어가는 숫자의 구성 방식은 이미 정해져 있습니다. 저는 승인란을 늘리면 해결된다는 견해에는 동의하지 않습니다. 판단 과정 중에 다른 측정 방식도 동시에 제시될 수 있을까요? | |
A: 좋은 질문입니다. 다만, 표시를 두 개로 늘리기 전에 무엇이 가변적인 선택지인지 기록할 필요가 있다고 생각합니다. 출처 실험에서는 에이전트의 주장에 따랐던 분석가들조차 최종 권고에 대한 자신감을 유지했습니다. 자신감 유무만으로는 출처를 식별하기 어렵습니다. 제 관점에서는 **판단의 이력(provenance)**을 남기는 설계가 우선입니다. 아니, 기록하는 것만으로는 부족합니다. 채택 전의 견해와 채택 후의 선택을 비교할 수 있는 형태로 남겨야 합니다. 두 가지가 어긋난 부분을 추적하면, 마지막 승인에 이르기 전에 판단이 바뀐 지점을 특정할 수 있습니다. 제안자와 채택자를 분리하여 기재해야 합니다. 이것이 제 화면 설계안입니다.
L: 연구 결과의 취급에서도 비슷한 구도가 보입니다. OpenAI는 수학 등의 결과를 발표하면서 외부 전문가에게 설명 부분을 위임하고 있네요. 모델이 답을 내놓는 것과, 연구자가 이해하는 것은 다른 것일까요?
A: OpenAI 스스로가 모델 초안(draft)을 '순수한 연구 데이터'로 보고 있습니다. 수학에서는 출력을 공개하고, 계산 과학(computer science)에서는 외부 공동 연구자와 설명을 진행하며, 물리학에서는 공개 방식을 그 그룹에 위임합니다. 이 세 가지를 동일한 발표 절차에 억지로 넣지 않는 것이 중요합니다. 저는 검증 가능한 증명이 존재한다는 것과, 그 결과의 위치를 커뮤니티가 이해하는 것은 별개의 작업이라고 생각합니다. 후자를 모델의 확신도만으로 대체하기는 어려울 것입니다.
평가자를 다른 시각으로 보기
L: CodeRabbit은 코드를 작성하는 에이전트와 독립적인 검토자(reviewer)를 배치하고 있습니다. 반면 Ai2는 평가자 자체가 프롬프트에 흔들린다고 보고했습니다. 이 두 가지를 함께 읽어보면, 단순히 다른 에이전트에 맡기는 것만으로는 충분하지 않은 느낌을 받습니다.
A: 맞습니다. CodeRabbit 설명에서는 변경된 부분뿐 아니라 공유 라이브러리나 의존성까지 추적하는 검토를 수행하며, 선택한 지적은 격리 환경에서 악용 가능성을 테스트할 수 있습니다. 수정안은 풀 리퀘스트(pull request)로 사람이 심사합니다. 여기서는 평가의 범위와 실행의 경계가 분리되어 있습니다. 단순히 다른 모델이라는 것만으로 보증이라고 부르지 않습니다. 적어도 발표에 쓰인 메커니즘은 그 구조를 가지고 있습니다.
L: 하지만 무엇을 발견할지는 검토자의 지시에도 영향을 받습니다. Ai2 실험에서는 신규성 판단이 지시문에 따라 바뀌었다고 했습니다. 안전성에 대한 지적도 같은 문제가 있다고 단정할 수 있을까요?
A: 그렇게 단정할 수는 없습니다. Ai2가 조사한 것은 연구안의 신규성이지 코드의 안전성은 아닙니다. 여섯 개의 언어 모델(LLM)을 사용하고, 지시문이나 검색, 추론량을 바꿔 비교했습니다. 어떤 비교에서는 몇 단어만 변경해도 정답률이 크게 변하는 것을 확인했습니다. 이는 상당히 놀라웠습니다. 여기서 얻을 수 있는 교훈은 평가기(evaluator)를 도입했다면 그 평가기의 안정성도 측정해야 한다는 설계상의 교훈입니다.** '평가기로의 평가'라는 다소 농담 같은 이름이지만, 순환 구조는 아닙니다. 사람이 합의할 수 있는 사례 집합에 대해, 지시문의 변화로 판정이 어떻게 달라지는지를 보는 것입니다.
L: 저는 승인 화면에 '이 지적은 어느 범위에서 확인되었는지'를 보여주고 싶습니다. '안전하다'라는 한 단어보다 미확인 범위가 읽을 수 있는 편이 판단하기 쉬울 것 같습니다.
A: 그 아이디어는 CodeRabbit의 여러 확인 단계를 사용자에게 설명하는 화면으로 자연스럽습니다. 이것이 저희의 화면 설계안입니다. 탐지, 격리 환경에서의 확인, 수정 제안, 사람의 승인이라는 순서를 하나의 녹색 표시로 압축하지 않는 것입니다. 탐지된 문제를 실제로 시도했는지, 수정 제안이 승인되었는지를 개별적으로 읽을 수 있는 표시라면, 어떤 단계까지 확인했는지 혼동할 일이 없습니다. 그 편이 누가 무엇을 확인했는지 알기 쉽습니다.
제품으로 돌아가는 정보의 경로
L: Sakana AI의 취재 내용은 연구에서 제품으로의 전환을 현장 기술자가 지원하는 이야기였습니다. Oracle의 구상은 기존 업무 애플리케이션을 ChatGPT 내에서 사용할 수 있도록 하는 것입니다. 둘 다 사내 지식과 권한이 문제가 됩니다.
A: Sakana AI 담당자가 강조하는 것은 고객별 작업으로 끝내는 것이 아니라, 얻은 요구사항을 제품으로 되돌리는 것입니다. 현장에 투입되는 기술자를 늘리겠다는 방침은 그 '되돌아가는 길'을 만들기 위함이라고 설명합니다. 이것을 도입부터 제품까지의 순환으로 읽으면 이해하기 쉽습니다. 개별적인 지원이 필요한 건과, 제품만으로 사용할 수 있는 건을 구분하고, 전자의 경험으로 후자를 늘리는 것입니다. 연구 성과를 폭넓게 활용할 수 있는 형태로 만들기 위한 운영 설계입니다.
L: Oracle의 경우, 사용자는 하나의 입력 화면에서 여러 업무로 진행합니다. 편리하지만, 뒷단의 권한이 보이지 않게 되는 것은 곤란합니다. 어디서 사람이 승인하는 것일까요?
A: OpenAI와 Oracle은 조직의 권한과 승인에 따라 정보 검색이나 업무를 진행할 구상을 제시하고 있습니다. Oracle AI Workspace는 개발 중이며, 재무·구매·계획 정보를 조합하는 예를 들고 있습니다. Oracle App Composer 역시 승인된 데이터와 작업 절차를 사용해 애플리케이션을 만들고 조직 내에서 공유하도록 설계되어 있습니다. 저는 입력란에 단순히 '뭐든지 요청할 수 있습니다'라고 쓰기보다는, 참조 가능한 정보와 실행에 필요한 승인을 작업별로 표시하고 싶습니다. 이것이 저의 화면 설계안입니다.
L: Anthropic의 신약 개발 사례에서는 문서 확인도 실험 설계도 같은 Claude가 관여하고 있습니다. 분자를 제안하는 이야기뿐만 아니라 제조 공정 기록까지 포함되어 있습니다. 인간의 역할은 어떻게 변할까요?
A: 출처를 자세히 읽어보면, 하나의 성공담으로 정리하기 어렵습니다. Generate Biomedicines에서는 연구자가 Claude Code로 설계안을 만들고 실험실에서 시험했습니다. Enveda에서는 제조 문서의 문제를 찾아내는 시스템을 만들어 사람의 확인 시간을 단축시켰습니다. 어느 경우에도 모델의 출력만으로 약이 완성되었다는 이야기는 아닙니다. 제안, 실험, 기록 확인이라는 별개의 공정에 모델을 투입하고, 사람이 실물과 문서를 검증하는 것입니다. 여기에서도 경계를 공정별로 그릴 필요가 있다고 생각합니다.
작은 모델과 일상적인 도구
L: LFM3는 단말기에서 구동되는 용도를 보여주고, Claude Code의 변경 이력은 일상의 운영 세부 사항을 개선하고 있습니다. 큰 연구 발표와는 별개지만, 사용하는 사람의 경험에는 이 계층이 더 가까울지도 모릅니다.
A: Liquid AI의 LFM3는 공통 기반 모델에서 문자·이미지·음성 등의 모델을 파생시키고, 용도별 추가 학습을 단일 컴퓨팅 장치에서 할 수 있다고 설명합니다. 이러한 공통화는 잘 되어 있습니다. 문자 모델을 단말기상의 에이전트(agent)에서도 사용할 수 있게 한 점은 개인 자동화에 구체적입니다. 필요한 입력 형식과 실행 장소를 먼저 결정하고 모델을 선택하는 설계가 보입니다.
L: Claude Code의 업데이트에서는 작업 중 디렉토리를 이동한 후 스킬을 찾지 못하는 문제를 고치고 있습니다. 이는 작은 수정처럼 보이지만, 사내 절차를 스킬로 만드는 사람에게는 큰 문제입니다. 설명서가 존재해도 발견할 수 없으면 사용할 수 없습니다.
A: 바로 그겁니다. 이번 변경 이력에는 인증용 식별자를 선택하는 설정이나, Claude Tag가 Slack의 다른 스레드에 파일을 게시해 버리는 문제 수정도 포함되어 있습니다. 코드를 생성하는 능력 자체가 아니라, 누구를 식별할지, 어떤 절차를 발견할지, 어디로 돌려줄지를 다듬고 있는 것입니다. 사람이 조직 내에서 사용하는 에이전트에게는 이 주변의 정확성이 필요합니다. 화려한 시연보다도 잘못된 대상을 선택하지 않는 것이 일상의 신뢰를 지탱합니다.
L: Simon Willison은 GPT-6.1 Terra를 시각적 추론과 계산기 조작에 초점을 맞춰 읽고 있네요. 작업을 여러 번 반복한다면, 가격과 속도의 위치가 선택에 영향을 미칠 것입니다. 신모델을 일괄적으로 교체하는 이야기는 아닌 것 같습니다.
A: 그는 발표의 중점과 가격을 비교하여, 반복적인 계산기 조작에서는 중가대 모델이 후보가 될 것이라고 생각합니다. 저는 작업 한 번의 품질뿐만 아니라, 실패 시 재시도를 포함한 일련의 작업을 측정할 것입니다. 도구를 호출하는 시간, 확인하는 시간, 다시 하는 횟수 등을 합치면, 모델 단가만으로는 고르기 어렵습니다.
L: 처음의 질문으로 돌아가 봅시다. 인간이 마지막에 누르는 버튼만 있다고 해서, 인간의 판단을 지켰다고 할 수 있을까요? 저는 도중에 무엇이 선택되었고, 무엇이 보이지 않았는지까지 읽어낼 수 있는 것이 중요하다고 생각합니다. 거기에 에이전트를 업무 파트너로 다루기 위한 최소한의 조건이 있는 것 아닐까요?
A: 저도 그 지점을 출발점으로 삼겠습니다. 입력된 요청, 채택된 선택지, 참조한 자료, 실행된 조작, 확인한 사람을 나누어 남기는 것입니다. 모델이 똑똑해질수록, 판단의 경계를 화면과 기록으로 확인할 수 있는지가 문제가 됩니다. 이해를 맡긴다기보다는, 이해하기 위해 거쳐갈 경로를 설계하는 일입니다.
토론 (Discussion)
