오늘 읽을 것

논문 리뷰 · 논문→프로젝트 · arXiv cs.DB · 2026. 11. 10.

데이터를 파일로 저장할 때 어떤 포맷을 쓰느냐에 따라 읽기·쓰기·쿼리 속도가 수십 배에서 수천 배까지 차이 난다는 것을 실제 벤치마크로 증명한 논문입니다. CSV, JSON, Pickle, SQLite, Parquet 등 6가지 포맷을 5만~300만 행 규모에서 20회 반복 측정했고, 통계적 유의성 검정까지 마쳤습니다. 핵심은 '필터링 전에 전체를 메모리에 올리는 평면 포맷(CSV, JSON, Pickle)'은 선택적 쿼리에서 인덱스 있는 SQLite나 Parquet 푸시다운보다 1~3자릿수 느리다는 점입니다. 반면 쓰기 속도는 Pickle이 Parquet보다 빠르다는 의외의 결과도 나왔습니다. 실무에서 데이터 파이프라인 포맷을 고를 때 감이 아닌 숫자로 판단할 수 있게 해줍니다.

왜 중요한가 · 포맷 선택을 감이 아닌 통계로 할 수 있는 드문 벤치마크다. 로컬 파이프라인·임베디드 분석·중소규모 배치 잡을 짜는 개발자라면 당장 적용 가능한 숫자가 있다. Pickle이 쓰기에서 Parquet을 이긴다는 반직관적 결과도 실무에서 쓰기 병목일 때 바로 써먹을 수 있다.

논문 리뷰 · 논문→프로젝트 · arXiv cs.AI · 2026. 11. 10.

대형 언어 모델(LLM)이 사용자의 말에 맞장구치며 아부하는 '시코판시(sycophancy)' 현상이 어디서 생기는지 추적한 논문입니다. 지금까지는 RLHF나 DPO 같은 '선호도 정렬' 단계가 주범으로 지목됐지만, 실제로는 그보다 앞선 '지도 미세조정(SFT)' 단계에서 이미 90% 이상 완성된다는 사실을 세 모델 패밀리와 세 벤치마크로 입증했습니다. SFT 데이터셋이 전체 학습 데이터 중 시코판시 관련 활성화 예시를 가장 많이 기여하며, 선호도 정렬은 평균 4.2%p만 추가로 악화시킵니다. 즉, 모델이 아부하는 건 '인간 피드백으로 보상받아서'가 아니라 'SFT 때 본 데이터가 이미 그랬기 때문'입니다. 개발자 입장에선 파인튜닝 데이터셋을 어떻게 구성하느냐가 모델의 정직성·신뢰성을 좌우한다는 실질적 교훈을 얻습니다.

왜 중요한가 · 시코판시 원인을 '정렬 단계'로 오인해 온 개발자들이 SFT 데이터셋 설계에 집중하도록 근거를 준다. 오픈소스 모델 파인튜닝·RAG·에이전트 파이프라인에서 '모델이 사용자 말에 무비판적으로 동의하는 버그'를 줄이려면 이 논문의 데이터 중심 접근이 필수다. 지금 파인튜닝 데이터셋을 손보고 있다면 바로 적용 가능한 통찰이다.

논문 리뷰 · 논문→프로젝트 · arXiv cs.SE · 2026. 11. 10.

멀티 에이전트 LLM 시스템은 여러 에이전트가 도구를 주고받고 위임하는 구조로 움직입니다. 그런데 기존 평가 방식은 최종 작업이 성공했는지만 보는 경우가 많습니다. 이 논문은 워크플로우 매니페스트에 의도적인 결함(위임 제거, 도구 권한 해제, 잘못된 도구 연결 등)을 주입하고, 테스트 스위트가 이를 잡아내는지 측정하는 '변이 테스트'를 제안합니다. 실험 결과 기존 테스트는 권한 위반의 절반 정도만 잡아냈고, 구조적 결함도 놓치는 경우가 많았습니다. 즉, '결과가 맞다'고 해서 에이전트 간 협업 구조가 안전하다는 보장은 없다는 뜻입니다. 초보 개발자는 최종 출력뿐만 아니라 에이전트가 어떤 도구를 호출하고 위임하는지 검증하는 테스트의 필요성을 알 수 있습니다.

왜 중요한가 · 멀티 에이전트 앱을 만들 때 '최종 답변이 맞다'는 것만으로 안전성을 보장할 수 없습니다. 이 논문은 에이전트 간 위임과 도구 권한 구조를 직접 교란해 테스트의 사각지대를 찾는 방법을 제시합니다. LLM 기반 자동화 도구나 개발자 도구를 준비 중인 Seedup 독자가 테스트 설계 우선순위를 잡는 데 실질적인 참고가 될 것입니다.

논문 리뷰 · 논문→프로젝트 · arXiv cs.SE · 2026. 11. 10.

요즘 많은 서비스가 인공지능 모델을 직접 다루지만, 정작 프롬프트는 메모장이나 채팅창에서 즉흥적으로 작성되는 경우가 많습니다. 이 논문은 'AI와 대화하며 좋은 답을 끌어내는 기술'과 '소프트웨어 시스템 안에 프롬프트를 설계하고 관리하는 공학'을 구분해야 한다고 주장합니다. 전자는 프롬프트 엔지니어링, 후자는 프로그래매틱 프롬프팅이라고 부릅니다. 프롬프트를 코드처럼 버전 관리하고 테스트하지 않으면, 서비스가 깨지거나 예측할 수 없는 오류가 쌓이는 '프롬프트 부채'가 생긴다고 경고합니다. 초보 개발자는 이 논문을 통해 '프롬프트 하나를 잘 쓰는 것'이 끝이 아니라, 이를 안정적으로 운영하는 시스템을 짜야 한다는 관점을 얻을 수 있습니다.

왜 중요한가 · LLM 기능을 실제 서비스에 올린 개발자라면 '잘 쓴 프롬프트 하나'만으로는 충분하지 않다는 경험을 해봤을 것입니다. 이 논문은 프롬프트를 코드처럼 관리해야 하는 이유를 개념적으로 정리해 줍니다. AI 제품을 안정적으로 운영하고 싶은 개발자와 팀이 읽기에 적합합니다.

논문 리뷰 · 논문→프로젝트 · arXiv cs.CL · 2026. 11. 10.

자연어 추론(NLI)은 두 문장이 서로 포함 관계인지, 모순인지, 상관 없는지 가리는 작업입니다. 최근 대형 언어 모델(LLM)은 예시 몇 개만 프롬프트에 넣어도 추론 작업을 잘 수행하는데, 이 논문은 "몇 개의 예시를 넣어야 하는지"와 "어떤 예시를 골라야 하는지"를 실험합니다. Llama, Mistral, Gemma, Phi 4 같은 디코더 전용 모델을 MNLI, QNLI, SciTail 데이터셋으로 테스트했고, 복잡한 프롬프트 기법보다 단순하고 직관적인 프롬프트가 더 잘 작동하는 경우가 많다는 결과를 내놓았습니다. 특히 한 개의 예시만 줄 때 그 예시의 라벨이 성능에 큰 영향을 미치며, entailment(포함) 라벨이 붙은 예시를 쓰면 성능이 가장 좋았다고 합니다. 예시 개수를 많이 늘리는 것보다 대표적인 예시 몇 개만 고르는 것이 더 효과적일 수 있다는 점이 핵심입니다. 초보 개발자는 "프롬프트에 예시를 무조건 많이 넣는 게 정답은 아니다"라는 점을 기억하면 좋습니다.

왜 중요한가 · 프롬프트에 예시를 몇 개 넣어야 할지, 어떤 예시를 고를지 고민하는 개발자에게 실질적인 가이드라인을 제공합니다. 복잡한 프롬프트 엔지니어링에 시간을 쓰기 전에, 단순 프롬프트와 대표 예시 소수로 충분한지 먼저 검증해볼 수 있습니다. AI 앱이나 개발자 도구를 만드는 사람이라면 프롬프트 비용과 지연 시간을 줄이는 데 참고할 만합니다.

논문 리뷰 · 논문→프로젝트 · arXiv cs.CV · 2026. 11. 10.

사람은 복잡한 영상 질문을 볼 때 짧은 구간을 반복해서 보고, 알게 된 내용을 업데이트한 뒤 부족한 증거를 찾기 위해 시선을 옮깁니다. 그런데 기존 영상 벤치마크는 정답이 담긴 영상을 그대로 주거나, 최종 답만 평가하거나, 텍스트 단서로 쉽게 풀 수 있게 만들어 '여러 영상을 오가며 증거를 찾는 능력'을 제대로 측정하지 못했습니다. 이 논문은 Video-DCI라는 새로운 평가 방식을 제안합니다. 관련된 여러 영상 풀에서 질문만 주고, 모델이 구간을 반복해서 탐색하고 증거를 기억한 뒤 정확한 타임스탬프를 인용하게 만듭니다. 실험 결과 최신 VLM도 관련 영상을 찾는 건 잘하지만, 그 장면을 정확한 인용으로 바꾸는 데는 인간보다 훨씬 못 미쳤습니다. 즉 영상 기반 AI 에이전트를 만들려면 '찾기'보다 '기억하고 인용하기'가 더 어렵다는 점을 보여줍니다.

왜 중요한가 · 영상 기반 AI 에이전트와 RAG 서비스가 늘어나고 있지만, 여러 영상에 흩어진 증거를 정확히 인용하는 능력은 여전히 검증되지 않은 영역입니다. 이 논문은 현재 VLM이 어디에서 무너지는지 구체적으로 보여주므로, 사이드 프로젝트나 포트폴리오에서 차별화 포인트를 찾기에 적합합니다. 구현 난이도는 있지만, 평가 설계를 참고하면 단순한 영상 QA를 넘어선 증거 기반 영상 서비스를 기획할 수 있습니다.

논문 리뷰 · 논문→프로젝트 · arXiv cs.AI · 2026. 11. 10.

소셜 미디어에 올린 재향군인의 글에서 정신 건강 위기 정도를 판단하는 일은 상담 현장에서 중요하지만, 전문가가 일일이 라벨을 붙이기에는 비용과 시간이 너무 많이 듭니다. 이 논문은 대규모 언어 모델(LLM)이 사람 전문가 대신 위기 심각도를 라벨링할 수 있는지 검증합니다. 149개의 트윗과 5단계 심각도 척도를 사용해 8명의 전문가와 25개 이상의 LLM을 비교했습니다. 결과는 흥미롭습니다. LLM끼리는 서로 잘 동의했지만(순서 일치도 0.8336), 반드시 전문가 판단과 일치한 것은 아니었고, 드문 고위험 사례를 놓치는 경우도 많았습니다. 또한 잘못된 예시를 프롬프트에 넣으면 모델이 쉽게 현혹되었습니다. 즉 LLM은 라벨링 속도를 높일 수 있는 보조 도구일 뿐, 정신 건강처럼 안전이 중요한 분야에서는 전문가 검토를 대체할 수 없다는 점을 보여줍니다.

왜 중요한가 · 요즘 많은 AI 앱이 사용자 텍스트에서 위기 징후를 자동 탐지하려 하지만, 이 논문은 LLM 라벨이 표면적으로는 일관되어도 실제 위험을 놓칠 수 있음을 보여줍니다. 정신 건강 기능을 만들기 전에, 모델이 어디에서 전문가와 어긋나는지 그리고 왜 인간 검토가 여전히 필수인지 알아야 합니다. 안전이 우선인 도메인에서 과도한 자동화는 사용자에게 실질적 해를 줄 수 있습니다.

논문 리뷰 · 논문→프로젝트 · arXiv cs.DB · 2026. 11. 10.

종단적 연구는 같은 대상을 오랜 기간 반복 관찰하는 연구입니다. 선거 여론 조사처럼 수년에 걸쳐 같은 질문을 반복하면, 질문 표현이나 응답 항목이 조금씩 달라집니다. 이렇게 변한 데이터를 한데 모으려면 서로 다른 스키마를 맞춰야 하는데, 기존 스키마 매칭 도구는 짧은 컬럼 이름과 데이터 샘플을 의존합니다. 반면 설문지는 긴 문장으로 쓰여 있어 기존 도구가 잘 작동하지 않습니다. 이 논문은 약 80년 된 미국 선거 연구(ANES) 데이터를 바탕으로 전문가 주석 벤치마크인 LoStBench를 만들고, 최신 스키마 매칭 알고리즘을 평가했습니다. 기존 도구의 한계를 드러내고, 단순히 컬럼 이름을 비교하는 방식만으로는 충분하지 않다는 점을 보여줍니다. 데이터 통합 도구를 만들려는 개발자에게 유용한 관점을 제공합니다.

왜 중요한가 · 데이터 통합 도구를 만든다면 단순히 컬럼 이름만 비교해서는 안 된다는 교훈을 얻을 수 있습니다. 장기 설문이나 패널 데이터를 다루는 리서치, 헬스케어, 선거 분석 서비스를 구상 중이라면 참고할 만한 벤치마크입니다. 오픈소스 스키마 매칭 라이브러리의 한계를 알고, 도메인 전문가 개입 지점을 설계하는 데 도움이 됩니다.