github·2026년 6월 25일·4분 읽기큐레이션 요약

모델과 작업별 GitHub Copilot 에이전틱 하니스의 성능 및 효율성 평가

GitHub은 모델 자체의 지능뿐 아니라 도구·컨텍스트·작업 흐름을 조율하는 에이전틱 하니스(harness)가 실제 성능을 좌우한다고 주장합니다. 동일한 모델과 작업을 기준으로 비교한 결과, GitHub Copilot 하니스는 모델 제공업체의 하니스와 비슷한 작업 해결률을 유지하면서 대부분 더 적은 토큰을 사용하는 것으로 나타났습니다. 따라서 하나의 하니스를 개선하면 Copilot CLI, 앱, 코드 리뷰, IDE 등 여러 제품 경험이 함께 향상된다는 결론입니다. ## 에이전틱 하니스의 역할 - 모델은 기본적인 추론 능력을 제공하지만, 하니스가 그 능력을 실제 작업에 적용하는 방식을 결정합니다. - 하니스는 다음 요소를 조율합니다. - 사용할 도구 - 모델에 제공할 컨텍스트 - 작업 실행 순서와 워크플로 - 메모리 및 MCP 서버 활용 - GitHub Copilot의 하니스는 Copilot SDK의 공통 구성 요소입니다. - Copilot CLI, Copilot 앱, Copilot 코드 리뷰, VS Code·Xcode 등 다양한 GitHub 및 Microsoft 경험에서 공유됩니다. - GitHub은 좋은 하니스의 조건으로 빠른 속도, 낮은 토큰 사용량, 예측 가능성을 제시합니다. ## 벤치마크 비교 방법 - 공개 벤치마크와 GitHub·Microsoft 대규모 코드베이스에서 도출한 내부 벤치마크를 함께 사용합니다. - 통제된 실험 결과를 실제 사용 지표와 온라인 실험으로 보완합니다. - 비교 시 다음 조건을 동일하게 맞췄습니다. - 같은 모델 - 같은 벤치마크 작업 - 동일하게 정규화한 컨텍스트 윈도우 - 동일한 추론 수준 - 동일한 도구 선택 및 MCP 서버 - 비교 대상은 다음과 같습니다. - GitHub Copilot CLI - Claude 모델의 기본 하니스인 Claude Code - GPT 모델의 기본 하니스인 Codex CLI - 평가 모델은 Claude Sonnet 4.6, Claude Opus 4.7, GPT-5.4, GPT-5.5입니다. ## 사용한 벤치마크 - **SWE-bench Verified** - 오픈소스 Python 저장소의 사람이 검증한 버그 수정 500개 - 코딩 에이전트의 대표적인 산업 표준 벤치마크 - **SWE-bench Pro** - 여러 단계의 추론과 광범위한 코드 변경이 필요한 어려운 작업 - 실제 소프트웨어 엔지니어링에 가까운 복잡한 문제를 평가 - **SkillsBench** - 에이전트가 스킬을 얼마나 효과적으로 사용하고 호출하는지 평가 - **TerminalBench** - 개발자가 사용하는 명령줄·터미널 기반 작업 수행 능력 측정 - **Win-Hill** - Windows 컨테이너에서 실행되는 내부 벤치마크 - 운영체제와 실행 환경이 달라져도 성능이 유지되는지 검증 ## 토큰 효율 - 동일한 모델과 작업을 사용했을 때 Copilot 하니스는 대부분의 설정에서 더 적은 토큰을 소비했습니다. - 토큰 사용량이 줄었음에도 전반적인 작업 완료율은 다른 모델 제공업체 하니스와 비슷한 수준이었습니다. - Claude Sonnet 4.6과 Opus 4.7에서는 Copilot CLI가 비교된 모든 사례에서 더 나은 결과를 보였습니다. - GPT-5.4와 GPT-5.5에서도 대부분 Copilot CLI가 우세했지만, SWE-bench Verified에서는 각각 7%, 4% 낮은 성능을 기록했습니다. - 단순히 비용을 줄이는 것이 아니라, 작업 해결 능력을 유지하면서 토큰 소비를 낮추는 것이 핵심입니다. ## 작업 해결률 - 전체적으로 Copilot 하니스의 작업 해결률은 모델 제공업체 하니스와 대등했습니다. - SWE-bench Verified에서는: - Sonnet 4.6과 Opus 4.7에서 Copilot CLI가 더 높은 해결률을 보였습니다. - GPT-5.4와 GPT-5.5에서는 더 낮았습니다. - SWE-bench Pro에서는: - Sonnet 4.6에서만 Copilot CLI가 소폭 낮았습니다. - 나머지 모델에서는 더 나은 성능을 보였습니다. - SkillsBench에서는 Claude 모델에서 낮았지만 GPT 모델에서는 더 높았습니다. - Win-Hill에서는 모든 모델에서 같거나 더 나은 결과를 기록했습니다. - TerminalBench 2에서는: - Sonnet 4.6과 Opus 4.7에서 더 높았습니다. - GPT-5.5에서는 동률이었습니다. - GPT-5.4에서는 더 낮았습니다. - 저자들은 모델의 확률적 특성으로 인한 실행별 변동을 고려하면 이러한 차이는 실질적으로 “동등한 수준”이라고 해석합니다. ## 실행별 변동성과 비용 분석 - TerminalBench 2.0을 사용해 작업 해결률뿐 아니라 작업당 비용과 실행별 변동도 분석했습니다. - 벤치마크 결과는 한 번의 실행만으로 하니스 성능을 판단하기 어렵다는 점을 보여줍니다. - 같은 에이전트와 모델 조합도 실행마다 결과가 달라질 수 있습니다. - 평가에서는 더 많은 작업을 해결하면서 비용을 적게 쓰는 구성이 더 좋은 것으로 간주합니다. - Copilot CLI는 이러한 분석에서 모델 제공업체 하니스와 비교해 같거나 더 나은 해결률·토큰 효율을 보였습니다. ## 실용적인 의미 - 모델을 선택할 때 모델의 벤치마크 점수만 보지 말고 하니스의 도구 사용, 컨텍스트 관리, 토큰 효율도 함께 평가해야 합니다. - 여러 모델을 한 제품에서 사용해야 한다면, 특정 모델에 종속되지 않으면서 성능을 유지하는 공통 하니스가 유리합니다. - 실제 도입 전에는 SWE-bench 같은 표준 평가뿐 아니라 조직의 코드베이스와 터미널 작업을 반영한 내부 벤치마크를 반복 실행하는 것이 좋습니다. - 단일 실행 결과보다 해결률, 비용, 토큰 사용량, 실행 간 변동을 함께 비교해야 신뢰할 수 있는 판단을 내릴 수 있습니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트모델 컨텍스트 프로토콜github-copilot+3

meta·2026년 6월 25일·5분 읽기큐레이션 요약

AI 네이티브 시대의 프라이버시 인식 인프라: 자산 분류 사례 연구

프라이버시 통제는 데이터의 정체와 사용 맥락을 정확히 이해해야 제대로 작동하며, 이를 위한 자산 분류가 모든 보존·접근·목적 제한·공유·익명화 정책의 기반이 된다. Meta는 LLM을 모든 운영 판단에 사용하는 대신, 풍부한 맥락과 인간 검토를 바탕으로 모호하거나 새로운 자산을 해석하게 하고, 검증된 패턴은 버전 관리되는 결정론적 규칙으로 전환하는 하이브리드 방식을 제안한다. 그 결과 일상적인 운영 집행은 빠르고 재현 가능하며 감사하기 쉬운 규칙이 담당하고, LLM은 점차 예외적인 경우에만 사용된다. ## 프라이버시 인프라에서 자산 분류가 중요한 이유 - 프라이버시 인식 인프라(PAI)는 다음 네 가지 운영 문제를 다룬다. - 어떤 데이터가 존재하고 어떻게 관리되는지 파악 - 특정 정책과 관련된 데이터 흐름 탐색 - 보존 기간, 접근 권한, 허용 목적, downstream 공유 제한 집행 - 검증 가능한 증거를 통한 컴플라이언스 입증 - 자산 분류는 이 중 ‘데이터 이해’ 계층에 해당하며, 이후 모든 통제의 기반이 된다. - 분류 대상은 테이블과 컬럼에 한정되지 않는다. - 중첩 페이로드의 필드 - 로그 키와 이벤트 파라미터 - API 필드 - ML 피처와 임베딩 - 중간 파이프라인에서 생성된 파생 데이터셋 - 같은 데이터가 파이프라인을 거치며 피처, 모델 학습 데이터, 결합된 파생 신호 등 여러 표현으로 바뀌므로, 분류는 데이터의 형태보다 의미와 계보(lineage)를 따라야 한다. ## 데이터 분류가 어려운 네 가지 이유 - **노이즈가 많고 신호가 약하다** - 자산마다 수십 개의 맥락 필드를 제공하면 모델이 매번 중요한 정보를 다시 찾아야 한다. - 불필요한 필드가 토큰과 주의를 소모해 실제 결정 경계를 흐린다. - 예를 들어 `age`는 개인정보 맥락에서는 사람의 나이지만, 인프라 파이프라인에서는 캐시 TTL일 수 있다. - 코드 해석과 lineage 분석이 없으면 캐시 파이프라인 전체에 불필요한 제한이 적용되는 false positive가 발생한다. - **관련 정보가 여러 시스템에 흩어져 있다** - 코드, 데이터 계보, 소유자, 의미론적 주석, 문서, 실제 사용 패턴을 함께 확인해야 한다. - **요구사항과 정책 해석이 계속 변한다** - 제품 기능이 빠르게 바뀌면 정적 규칙이나 주기적 수동 검토만으로는 정책 공백이 생긴다. - **분류 오류가 downstream 전체에 전파된다** - false positive는 불필요한 제한을 유발한다. - false negative는 보호되지 않은 데이터가 남는 문제를 만든다. - 따라서 모호성을 다루는 추론 능력과 설명·재현 가능한 집행 방식이 모두 필요하다. ## LLM과 결정론적 규칙의 역할 분담 - LLM은 다음 상황에 제한적으로 사용한다. - 기존 규칙으로 처리하기 어려운 모호한 자산 - 초기 데이터가 부족한 cold start 상황 - 이전에 보지 못한 새로운 패턴 - 검증된 패턴은 버전이 있는 결정론적 규칙으로 변환한다. - 낮은 지연 시간 - 동일 입력에 대한 재현성 - 실행 결과의 감사 가능성 - 대규모 운영에 적합한 비용과 성능 - 일반적인 운영 판단은 LLM이 아니라 규칙이 담당한다. - 인간은 다음 단계에 관여한다. - 기준 라벨(reference label) 판정 - 보호 정책에 영향을 주는 규칙 승격 검토 및 승인 - 장기적으로는 LLM이 담당하는 운영 범위를 줄이고, 규칙이 처리하는 안정적인 영역을 넓히는 것이 목표다. ## 원칙 1: 프롬프트보다 맥락이 중요하다 - 분류 실패의 주요 원인은 지시문이 약해서가 아니라 모델에 제공된 증거가 부족하거나 정리되지 않았기 때문이다. - 원시 필드를 그대로 전달하면 중요한 정보와 오해를 일으키는 정보가 섞인다. - 대신 다음 요소를 포함한 **evidence brief**를 구성한다. - 판단을 지지하는 신호 - 판단과 모순되는 신호 - 각 정보의 출처(provenance) - 모델이 이미 알고 있는 정보와 중복되는 순환 필드의 마스킹 - 프롬프트를 계속 최적화하는 것보다, 코드·계보·소유권·문서 등 관련 증거를 선별하고 구조화하는 편이 정확도 향상에 더 효과적이다. - 즉, 모델에 무엇을 어떻게 묻는지보다 먼저 무엇을 보여줄지를 설계해야 한다. ## 원칙 2: 평가와 최적화를 분리한다 - LLM의 결과는 추천이며, 그 자체가 정답 데이터가 되어서는 안 된다. - 평가 체계는 분류기와 독립적으로 유지해야 한다. - 서로 다른 모델과 프롬프트 전략 - 고정된 reference set - 사람이 검토한 라벨 - 회귀(regression) 통과 기준 - 분류 결과를 다시 평가 기준으로 사용하면 실제 개선이 아니라 모델의 드리프트를 측정할 위험이 있다. - 인간 검토 라벨은 모델 출력과 분리된 신뢰 가능한 기준점으로 사용해야 한다. ## 원칙 3: 안정적인 동작을 규칙으로 증류한다 - 반복적으로 검증된 분류 패턴은 사람이 검토한 뒤 결정론적 규칙으로 만든다. - 규칙에는 버전, 적용 조건, 판단 근거를 남겨야 한다. - 규칙 기반 집행은 LLM 추론보다 빠르고, 결과를 재생(replay)할 수 있으며, 감사와 디버깅이 쉽다. - LLM은 새로운 패턴을 발견하는 학습 장치로 활용하고, 안정화된 지식은 규칙에 축적한다. ## 플랫폼 서비스로서의 분류 계약 분류기는 개별 모델 호출이 아니라 안정적인 플랫폼 서비스처럼 설계해야 한다. - 입력 - 자산 식별자 - 정리된 맥락 정보 묶음 - 출력 - 분류기 taxonomy상의 카테고리 - 모델의 원시 confidence score - 판단에 영향을 준 증거를 보여주는 decision trace - 결정론적 규칙으로 판단했다면 매칭된 규칙 - 사용된 맥락, 규칙, 프롬프트의 버전 정보 - confidence는 모델의 자기평가일 뿐이므로, 사람이 검토한 라벨과 비교해 실제 보정 상태를 평가해야 한다. - 모든 분류기를 하나의 보편적 taxonomy로 통합하지 않고, 각 분류기가 하나의 범위가 좁은 질문을 담당하도록 한다. - 예: 사용자 데이터인지 운영 데이터인지 분류 - 예: 특정 AI 학습 용도에 적합한 자산인지 분류 - 좁은 범위의 분류기는 평가·디버깅·거버넌스가 쉽고, 여러 분류기의 결과를 downstream에서 조합할 수 있다. 실무적으로는 LLM을 최종 집행 엔진으로 삼기보다, 사람이 검토한 라벨과 충분한 맥락을 이용해 새로운 패턴을 발견하는 보조 계층으로 두는 것이 바람직하다. 이후 안정화된 판단은 버전 관리되는 규칙으로 승격해 운영하고, 모든 결과에 증거·버전·추적 정보를 남겨 재현성과 감사 가능성을 확보해야 한다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델data-governancehuman-in-the-loopdata-lineage+3

dropbox·2026년 6월 25일·3분 읽기큐레이션 요약

DSPy를 활용해 Dash 채팅에서 AI 평가를 더 나은 응답으로 전환한 방법

Dropbox는 Dash chat 에이전트의 최종 답변만 평가하지 않고, 의도 파악·검색·도구 사용·근거 선택·다중 턴 대응까지 전체 실행 과정을 평가했습니다. 이후 사람의 평가 데이터를 활용해 LLM 평가자(judge)를 보정하고, DSPy의 GEPA·MIPROv2로 평가자와 에이전트 시스템 프롬프트를 최적화했습니다. 그 결과 불완전한 답변을 줄이고 토큰 사용량도 낮추면서 답변 품질을 유지할 수 있었습니다. ## 에이전트 평가가 어려운 이유 - 전통적인 검색 평가는 단일 결과의 관련성을 주로 측정하지만, 에이전트는 여러 단계의 의사결정을 수행합니다. - 평가 대상에는 다음 과정이 모두 포함됩니다. - 사용자의 의도 해석 - 문서·메시지·회의 기록 등 적절한 컨텍스트 수집 - 검색 및 문서 읽기 같은 도구 사용 - 여러 출처의 정보 종합 - 직접 답변, 추가 검색, 요약, 명확화 질문 중 적절한 선택 - 대화가 여러 턴에 걸쳐 진행될 수 있으므로 최종 답변뿐 아니라 피드백 반영과 재검색 과정도 평가해야 합니다. - 따라서 답변 품질, 의도 이해, 컨텍스트 선택, 도구 사용, 근거성, 지시 준수, 과업 완료 여부를 পৃথ도로 분석해야 실패 원인을 찾을 수 있습니다. ## 사람의 평가로 LLM judge 보정 - 내부 채팅 샘플과 에이전트 trace 로그를 수집하고, 사람이 다음 다섯 가지 차원을 평가했습니다. - 사용자 의도 추종 - 의미적 관련성 - 도구 호출 품질 - 지시사항 준수 - 컨텍스트 선택 - 평가자는 먼저 의도와 컨텍스트가 적절했는지 확인한 뒤 검색·검색 결과 활용·도구 행동을 검토했습니다. - 이후 최종 답변이 선택된 근거에 의해 뒷받침되는지, 관련성·근거성·완전성·지시 준수 여부를 평가했습니다. - 일부 지표는 1~5점으로 점수화하고, 함께 다음 정보를 기록했습니다. - 점수의 근거가 되는 reasoning note - 오래된 근거, 누락된 컨텍스트, 근거 없는 주장, 불완전한 답변, 개인화 실패 등의 failure code - 점수는 결과를 요약하지만, 평가 메모와 실패 코드는 문제가 발생한 위치와 원인을 보여줍니다. - 이 데이터는 judge 프롬프트 보정뿐 아니라 디버깅, 오류 분석, 개선 로드맵 수립, 우선순위 결정에도 활용됐습니다. ## DSPy를 이용한 평가자 개선 - 목표는 LLM judge의 점수가 사람의 판단과 더 일치하도록 만드는 것이었습니다. - judge는 단순히 답변에 점수를 매기는 것이 아니라 다음과 같은 정해진 절차를 따라야 했습니다. - 사용자의 의도 추론 - 대화 내용 검토 - 에이전트 trace와 지원 근거 확인 - 컨텍스트 선택과 도구 사용 분석 - 점수·실패 코드·평가 메모 작성 - DSPy를 최적화 도구로 사용하고, GEPA와 MIPROv2를 알고리즘으로 활용했습니다. - 알고리즘은 사람의 라벨이 있는 예제에서 프롬프트 변경안을 자동으로 제안하고 테스트했습니다. - 지원한 최적화 방식에는 다음이 포함됩니다. - judge 지침을 처음부터 새로 작성 - 기존 평가 행동을 유지하면서 다른 기반 모델에 맞게 조정 - 특정 실패 유형을 집중적으로 수정하는 타깃 최적화 - 이렇게 최적화된 judge는 이후 채팅 에이전트 자체의 시스템 프롬프트를 개선하는 평가 신호로 사용됐습니다. ## 평가에서 에이전트 개선으로 이어지는 피드백 루프 - 전체 과정은 다음 순환 구조로 구성됩니다. - 사람의 라벨이 judge를 보정 - 개선된 judge가 대규모 평가 신호 생성 - 평가 신호가 에이전트 프롬프트와 행동 개선에 사용 - 이 구조를 통해 사람의 평가를 모든 대화에 직접 적용하지 않고도 에이전트를 반복적으로 최적화할 수 있었습니다. - 최종적으로 불완전한 답변이 크게 줄었고, 답변 품질을 떨어뜨리지 않으면서 토큰 사용량도 절감했습니다. 실무적으로는 에이전트 개선 전에 평가자의 신뢰성을 먼저 검증해야 합니다. 최종 점수만 수집하기보다 trace, 평가 이유, 실패 유형을 함께 기록하고, 사람의 라벨과 DSPy 같은 자동 최적화 도구를 결합하면 평가를 지속적인 품질 개선 시스템으로 전환할 수 있습니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트dspyprompt-optimization+4

line·2026년 6월 24일·5분 읽기큐레이션 요약

시멘틱 컨텍스트 OS 설계: 에이전트 시스템의 토큰 스터핑을 넘어

LLM의 컨텍스트 창이 커져도 입력을 무작정 늘리는 ‘토큰 스터핑’만으로는 소프트웨어 에이전트의 추론 성능을 보장할 수 없다는 것이 글의 핵심 주장입니다. 긴 컨텍스트에서는 어텐션 희석과 컨텍스트 부패가 발생해 검색 정확도와 논리 일관성이 떨어질 수 있으므로, 컨텍스트를 텍스트가 아닌 관리 가능한 시스템 자원으로 다뤄야 합니다. 이를 위해 글은 로컬 루프백 프록시 형태의 ‘시맨틱 컨텍스트 OS’와 VFS, AST 기반 가지치기, 동적 토큰 관리 구조를 제안합니다. ## 컨텍스트 창은 전통적인 RAM과 다르다 - Karpathy의 은유에 따르면: - LLM은 사전 학습된 가중치를 바탕으로 추론을 수행하는 CPU와 유사합니다. - 컨텍스트 창은 현재 상태와 실행 데이터를 담는 휘발성 RAM과 유사합니다. - 그러나 전통적인 RAM과 달리 LLM의 컨텍스트 검색은 결정론적인 주소 조회가 아닙니다. - 특정 메모리 주소에서 데이터를 정확히 읽는 방식이 아니라, Q·K·V 행렬과 어텐션 점수에 기반한 확률적 검색입니다. - 컨텍스트가 32K에서 1M 또는 2M 토큰으로 커져도 정보 접근 정밀도가 선형적으로 증가하지 않습니다. - 입력이 커질수록 계산 표면적과 구조적 잡음이 증가해 오히려 추론 성능이 저하될 수 있습니다. ## 어텐션 희석과 ‘중간 정보 유실’ - 긴 코드베이스나 시스템 로그에는 다음과 같은 불필요한 정보가 포함됩니다. - 보일러플레이트 정의 - 참조되지 않는 import - 중복된 구문과 유틸리티 - 관련 없는 로그와 실행 데이터 - 이런 정보가 키 행렬에 많이 포함되면 쿼리와 키 사이의 의미 차이가 작아지고, 어텐션 로짓이 균일해집니다. - 그 결과 중요한 정보에 집중하던 날카로운 어텐션 피크가 넓게 분산되어, 정확한 사실 검색이 어려워집니다. - 글은 이를 Stanford 연구에서 제시한 ‘Lost in the Middle’ 현상과 연결합니다. - 컨텍스트의 시작과 끝에 있는 정보는 비교적 잘 검색됩니다. - 중간 영역, 특히 중간 70% 부근의 정보는 검색 정확도가 크게 낮아집니다. - 수만 줄의 코드나 복잡한 서비스 의존성을 다루는 에이전트에게 이러한 검색 편향은 심각한 논리적 오류로 이어질 수 있습니다. ## 장기 작업에서 발생하는 컨텍스트 부패 글은 자동 리팩토링, 레거시 마이그레이션, API 계약 검증처럼 여러 단계가 필요한 작업에서 컨텍스트가 시간이 지나며 악화되는 현상을 ‘컨텍스트 부패’라고 설명합니다. - **컨텍스트 오염** - 과거 실행 로그, 터미널 오류, 원시 데이터를 계속 누적합니다. - 모델이 일시적인 과거 오류를 현재 작업의 영구적인 제약으로 잘못 해석할 수 있습니다. - **컨텍스트 산만** - 모노레포의 동일한 이름, 오버로드된 메서드, 중복 유틸리티가 검색 결과에 함께 들어옵니다. - 구조적으로 비슷하지만 논리적으로 무관한 코드가 핵심 실행 경로를 가립니다. - **컨텍스트 충돌** - 이전 단계의 지시사항을 제거하거나 갱신하지 않으면 서로 모순되는 명령이 남습니다. - 에이전트가 논리적으로 마비되거나 무한 추론, 타임아웃, 환각을 일으킬 수 있습니다. - 글은 능동적인 관리 계층이 없을 경우 컨텍스트 깊이가 커질수록 실패율이 비선형적으로 증가하고, 깊은 코드 구조에서는 실패율이 약 40%에 이를 수 있다고 주장합니다. ## 수동적 프롬프트에서 능동적 거버넌스로 - 일반적인 구현은 문자열을 계속 이어 붙여 다음 LLM 호출에 전달하는 방식입니다. - 이 방식은 메모리 관리, 토큰 최적화, 노이즈 제거를 LLM의 내부 어텐션에 맡깁니다. - 시맨틱 컨텍스트 OS는 애플리케이션 로직과 파운데이션 모델 API 사이에 위치하는 AI 전용 커널로 제시됩니다. - 로컬 `localhost:8080` 루프백 프록시로 동작하며 다음 작업을 담당합니다. - 컨텍스트 상태와 접근 경로 관리 - 토큰 생명 주기 모니터링 - 전송 전 데이터 격리와 정책 적용 - 모델별 하드웨어 토큰 한계와 의미론적 컨텍스트 거버넌스의 분리 ## MVC(Minimum Viable Context) 파이프라인 MVC의 목표는 거대한 텍스트 덤프가 아니라 현재 추론 단계에 필요한 최소한의 고밀도 정보만 모델에 제공하는 것입니다. - **수집 및 토큰 매핑** - 소스 파일, 의존성 트리, 런타임 로그를 수집합니다. - `cl100k_base`, `o200k_base` 등 실제 모델 토크나이저를 사용해 정확한 토큰 수를 계산합니다. - **구조 가지치기** - 정적 코드 분석과 구조 규칙으로 불필요한 정보를 제거합니다. - 컴파일러 주석, 미사용 import, 관계없는 유틸리티 코드 등이 대상입니다. - 글에서 제시한 전체 아키텍처는 이후 단계에서 의미적 정제와 실행 중 토큰 최적화를 수행하도록 설계됩니다. ## 시맨틱 컨텍스트 OS의 구성 요소 - **POSIX 유사 VFS** - 컨텍스트와 에이전트 상태를 가상 파일 시스템처럼 구조화합니다. - 상태 토폴로지와 접근 경계를 명시적으로 관리합니다. - **PathAlign** - AST를 활용해 코드의 구조적 경로를 분석합니다. - 현재 작업과 관련된 가지를 남기고 무관한 코드 트리를 제거합니다. - **비동기 톱니(sawtooth) 메모리 모델** - 실행 중 컨텍스트를 계속 축소·갱신하는 방식으로 토큰 사용량을 최적화합니다. - 장기 실행 루프에서 오래된 상태와 불필요한 데이터를 누적하지 않도록 합니다. - **보안 및 격리** - 모델에 전달되는 데이터의 범위를 제한합니다. - 기업 코드와 로그 등 지적 재산이 불필요하게 외부 추론 엔진으로 유출되는 위험을 줄이는 것을 목표로 합니다. 시맨틱 컨텍스트 OS의 실질적인 메시지는 “큰 컨텍스트 창”보다 “잘 선별되고 지속적으로 관리되는 컨텍스트”가 중요하다는 것입니다. 엔터프라이즈 에이전트를 구축할 때는 토큰 예산을 명시적으로 계산하고, AST·의존성·의미 기반 필터링을 적용하며, 오래된 지시와 로그를 정리하는 런타임 거버넌스 계층을 두는 것이 권장됩니다. 단, 글의 실패율과 성능 개선 수치는 제안된 아키텍처의 주장으로 보아 실제 환경에서 별도의 벤치마크 검증이 필요합니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트transformerabstract-syntax-tree+4

google·2026년 6월 24일·3분 읽기큐레이션 요약

회상을 위한 사고: 추론은 LLM의 파라메트릭 지식을 어떻게 끌어내는가

LLM의 추론 과정은 복잡한 논리 문제가 없어도 단순한 사실을 회상하는 데 도움을 준다. 연구진은 그 이유로 생성된 추론 토큰이 추가 계산 공간으로 작동하는 효과와, 관련 사실을 먼저 떠올려 정답을 활성화하는 사실 프라이밍을 제시한다. 다만 중간에 생성한 사실이 환각일 수 있어, 이 방식은 정확성 검증과 함께 사용해야 한다. ## 단순한 사실 회상에도 추론이 효과적인 이유 - 일반적으로 Chain-of-Thought(CoT)는 수학, 프로그래밍, 다단계 질의응답처럼 복잡한 문제를 단계적으로 해결할 때 유용하다. - 그러나 “Mary Engle Pennington이 National Inventors Hall of Fame에 헌액된 연도는?”처럼 단일 사실을 묻는 질문에는 명시적인 논리 전개가 필요하지 않다. - 연구진은 이런 질문에서도 추론을 허용하면, 추론을 끈 상태에서는 사실상 회수하기 어려운 정답이 생성될 수 있음을 확인했다. - 실험에는 Gemini-2.5 Flash/Pro와 Qwen3-32B, SimpleQA Verified 및 EntityQuestions 데이터셋이 사용됐다. ## 지식 회수 한계 측정: pass@k - `pass@k`는 한 번의 최상위 답변만 보는 대신, 여러 번 생성한 답변 중 정답이 포함되는지를 측정한다. - 이를 통해 정답이 모델의 출력 분포 안에 잠재적으로 존재하는지, 현재 최상위 답변으로 선택되지 않았을 뿐인지 구분할 수 있다. - 추론 ON/OFF 모드를 비교한 결과, 세 모델과 두 데이터셋에서 추론을 활성화했을 때 정답 회수율이 일관되게 향상됐다. - 데이터셋이 주로 단순한 단일 단계 질문으로 구성되어 있어, 성능 향상이 복잡한 문제 분해 때문이라고 보기 어렵다. ## 생성 토큰이 제공하는 계산 버퍼 - 첫 번째 메커니즘은 추론 토큰이 모델에 추가적인 계산 시간과 내부 상태 갱신 기회를 제공한다는 것이다. - 연구진은 모델의 자연스러운 추론 내용을 제거하고, `"Let me think"` 같은 무의미한 문자열을 원래 추론과 같은 길이로 반복해 넣었다. - 의미 없는 토큰만 제공해도 추론을 완전히 끈 경우보다 사실 회상 성능이 크게 향상됐다. - 이는 추가 토큰이 의미를 전달하지 않더라도 여러 번의 forward pass를 통해 모델이 내부 표현을 정제하고, 접근하기 어려운 지식을 검색하게 만들 수 있음을 시사한다. - 다만 토큰을 계속 늘리면 효과가 감소하며, 자연스러운 추론의 성능에는 도달하지 못했다. - 따라서 계산량 자체가 중요하지만, 추론 과정에 포함된 실제 내용도 추가적인 역할을 한다. ## 관련 사실을 떠올리는 사실 프라이밍 - 자연스러운 추론을 분석한 결과, 모델은 논리적 증명을 수행하기보다 질문과 관련된 주변 사실을 먼저 나열하는 경우가 많았다. - 연구진은 이를 인간 기억의 ‘ spreading activation’과 유사한 현상으로 보고, **사실 프라이밍(factual priming)**이라고 명명했다. - 관련 사실을 생성하면 질문과 정답 사이에 의미적 연결 고리가 형성되어, 목표 사실을 회상하기 쉬워진다. - 실험에서는 추론 과정에서 나온 구체적인 사실만 추출하고, 채움말, 검색 계획, 정답 자체에 대한 직접 언급은 제거했다. - 짧은 사실 목록만 정답 생성에 제공해도 추론이 만들어내는 성능 향상의 상당 부분이 재현됐다. - 예를 들어 네팔의 제10대 왕을 묻는 질문에서 모델이 앞선 9명의 왕을 먼저 떠올리면, 이 정보들이 제10대 왕을 회상하기 위한 의미적 준비 단계로 작동할 수 있다. - 이 효과는 추론 모드가 꺼진 상태에서 사실 목록을 추가 문맥으로 제공했을 때도 나타났다. ## 환각으로 인한 위험 - 사실 프라이밍은 모델이 중간 사실을 스스로 생성한다는 점에서 근본적인 위험을 가진다. - 중간에 떠올린 관련 사실이 실제 지식이 아니라 환각일 경우, 잘못된 정보가 정답 회상을 방해하거나 오답을 강화할 수 있다. - 제공된 글은 이 위험을 검증하는 실험을 소개하는 도중에 끝나므로, 환각의 구체적인 측정 결과와 완화 방법은 확인할 수 없다. ## 실용적인 결론 - 단순한 사실 질문에서도 모델의 추론을 허용하면 잠재 지식 회수율을 높일 수 있다. - 성능 향상은 충분한 생성 길이를 제공하는 것과, 관련 사실을 먼저 회상하도록 유도하는 방식에서 비롯된다. - 다만 중간 추론을 그대로 신뢰하지 말고, 외부 검색·검증 또는 여러 독립 샘플의 일치 여부를 함께 확인하는 것이 안전하다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델chain-of-thoughtparametric-memorylatent-computation+3

stripe·2026년 6월 23일·4분 읽기큐레이션 요약

HITEC 2026에서 본 여행 및 호스피탈리티 트렌드 네 가지

호텔 업계의 AI 투자는 빠르게 확대되고 있지만, 실제로 핵심 운영에 AI를 통합하고 투자수익률을 입증한 기업은 10% 미만이다. 성공의 걸림돌은 모델 성능보다 데이터 단절, 낡은 결제 인프라, 실제 업무 흐름과 연결되지 않은 기술에 있다. 앞으로는 검색 최적화보다 AI 답변에 노출되는 구조화된 데이터, 원활한 결제, 눈에 띄지 않게 작동하는 개인화 기술이 경쟁력을 좌우할 전망이다. ## AI 시대의 직접 예약 경쟁 - 기존 호텔 업계는 SEO와 검색 순위 개선을 통해 Expedia, Booking.com 같은 OTA를 거치지 않고 직접 예약을 유도했다. - 그러나 AI Overview가 포함된 Google 검색의 65%는 사용자가 웹사이트를 클릭하지 않고 종료되며, 모바일에서는 이 비율이 78%까지 높아진다. - 업계의 전통적인 검색 트래픽은 약 25% 감소하고 있어, 키워드와 백링크 중심의 SEO만으로는 충분하지 않다. - AI 모델에 노출되려면 다음 정보가 정확하고 기계가 읽기 쉬운 형태로 제공되어야 한다. - 객실 유형과 세부 조건 - 편의시설 - 취소 및 환불 정책 - 주변 지역 정보 - 실시간 재고와 요금 - 숙박업체 사이트의 90% 이상이 아직 AI 모델에 제대로 탐지되지 않는다. - 여행자의 56%가 최근 1년 동안 여행 계획, 예약 또는 현지 지원에 AI를 사용했다. - 따라서 대규모 AI 투자보다 먼저, 주요 AI 서비스가 자사 호텔을 정확히 설명하고 있는지 데이터 감사를 수행해야 한다. - AI 검색 노출만으로는 부족하며, 현지 결제수단·통화, 원클릭 결제, 사기 방지 기능을 갖춘 결제 과정까지 연결해야 예약 전환이 가능하다. ## 호텔 AI의 병목은 모델보다 데이터 연결성 - 많은 호텔이 AI 기능을 도입하고 있지만, 전략과 데이터 기반, 운영 아키텍처가 부족해 안정적으로 확장하지 못하고 있다. - 주요 시스템이 분리되어 있어 동일 고객에 대한 정보가 여러 곳에 흩어진다. - PMS(호텔 운영 시스템) - CRM - 멤버십·로열티 시스템 - 식음료 시스템 - 결제 시스템 - 이로 인해 AI 개인화가 부정확해지고, 재무팀의 대사 업무가 늘며, 고객 프로필이 불완전해지고, 고객 경험에도 마찰이 발생한다. - 중요한 것은 AI를 만드는 것보다 실제 운영 환경에서 안정적으로 실행하는 ‘AI 운영화’다. - 효과적인 기업은 정제되고 연결된 데이터를 업무 흐름 안에 제공해 직원이 적시에 행동하도록 만든다. - 예를 들어: - Delta Air Lines는 고객 프로필과 운영 데이터를 활용한 AI 컨시어지를 모바일 앱의 고객 지원 과정에 통합했다. - Wynn Las Vegas는 목표 대비 실적이 하락할 때 수익 관리자에게 예측 알림과 구체적인 대응 방안을 함께 제공한다. - 즉, 대부분의 여행 기업에서 우선 해결해야 할 문제는 더 좋은 AI 모델이 아니라 데이터의 통합과 업무 시스템 연결이다. ## 결제 인프라가 예약과 고객 경험을 좌우한다 - 호텔 업계는 결제를 단순한 비용과 운영 기능으로 취급해왔지만, 이제 결제 방식 자체가 성장과 경쟁력의 요소가 되고 있다. - 호텔 경영진 설문에서: - 90%는 결제가 성장에 중요하다고 답했다. - 37%는 결제수단 부족이 고객 경험을 가장 크게 해치는 요인이라고 답했다. - 58%는 사기 방지 시스템이 정상 거래까지 차단한다고 답했다. - 74%는 결제 시스템 분절로 대사 업무에 과도한 시간이 든다고 답했다. - 특정 국가에서 널리 쓰이는 결제수단을 지원하지 않으면 고객은 결제가 가능한 OTA나 다른 플랫폼으로 이동한다. - 대형 OTA는 결제 전문 인력을 대규모로 운영할 수 있지만, 독립 호텔이나 소규모 사업자는 같은 방식으로 투자하기 어렵다. - 대신 적절한 결제 인프라를 사용하면 적은 인력으로도 여러 국가의 결제수단, 통화, 사기 방지 기능을 운영할 수 있다. - 결제 범위의 작은 차이가 직접 예약을 잃고 OTA에 고객을 빼앗기는 결과로 이어질 수 있다. ## 성공적인 기술은 고객에게 보이지 않는다 - 고객은 작동하지 않는 기술에 큰 불만을 느끼며, 반드시 항의하지 않더라도 재방문하지 않을 수 있다. - 기술의 성공 기준은 고객이 기술의 존재를 인식하지 못할 정도로 자연스럽게 작동하는 것이다. - 이상적인 개인화 경험의 예시는 다음과 같다. - 고객이 도착하기 전에 객실 온도가 선호 수준으로 설정됨 - TV에 선호 채널이 표시됨 - 선호하는 베개가 준비됨 - 고객이 매번 자신의 취향을 직접 입력하지 않아도, 과거 투숙·멤버십·운영 데이터를 바탕으로 필요한 서비스를 예측해야 한다. - 다만 개인화는 “AI가 무엇을 했는지”를 과시하는 방식보다, 자연스럽고 방해 없이 서비스에 녹아드는 방식이 효과적이다. ## 실무적인 시사점 호텔과 여행 기업은 유행하는 AI 기능을 무작정 추가하기보다, 먼저 고객·객실·재고·결제 데이터를 통합해야 한다. 이후 AI 검색에서 자사 정보가 정확히 노출되는지 점검하고, 선호 결제수단을 지원하며, 예측 결과가 실제 직원 업무와 자동화된 조치로 이어지는지 확인하는 것이 우선이다. საბოლო적으로 경쟁력 있는 기술은 가장 화려한 기술이 아니라 예약을 늘리고 운영을 단순화하면서 고객이 불편을 느끼지 않게 하는 기술이다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AIAI 에이전트seo+4

line·2026년 6월 23일·4분 읽기큐레이션 요약

프롬프트 튜닝을 수작업에서 AI 튜닝으로: 유전 알고리즘 기반 자동 최적화와 고속화

프롬프트 튜닝은 반복적인 수작업과 개인 의존성 때문에 수일에서 수주가 걸리지만, 유전 알고리즘 기반의 GEPA를 적용하면 이를 약 한 시간으로 단축할 수 있다. GEPA는 후보 프롬프트를 여러 세대에 걸쳐 평가·변이하고, 점수뿐 아니라 자연어 피드백까지 활용해 개선 방향을 찾는다. LY Corporation은 이를 Yahoo! JAPAN Search의 건강·의료 쿼리에 적용해 정책 준수와 답변 가독성을 함께 최적화했다. ## 프롬프트 튜닝이 어려운 이유 - 프롬프트를 조금만 수정해도 출력을 다시 생성하고 사람이 품질을 판단해야 한다. - 수십~수백 개의 프롬프트 패턴을 시험하는 경우가 있어 반복 작업량이 크다. - “특정 표현이나 지시 순서가 효과적이다” 같은 노하우가 담당자 개인에게 남기 쉽다. - 개선 이유와 시행착오 과정이 기록되기 어려워 재현성과 설명 가능성이 떨어진다. - 모델 버전이 바뀌면 출력 품질도 변하므로 지속적인 재튜닝이 필요하다. - 사람이 직접 해야 할 정책 검증, 평가 기준 정리, 품질 판단에 충분한 시간을 쓰기 어렵다. ## 프롬프트 자동 최적화 방법 - 대표적인 접근법은 다음과 같다. - **강화 학습 기반**: 출력에 대한 스칼라 보상을 이용해 프롬프트 생성 정책을 학습한다. - **베이지안 최적화 기반**: 지시문과 퓨샷 예시를 탐색 공간으로 보고 효율적으로 후보를 선택한다. - **유전 알고리즘 기반**: 여러 프롬프트 후보를 집단으로 관리하며 세대별로 개선한다. - 자연어로 구성된 프롬프트는 이산적인 구조이므로 유전 알고리즘과 잘 맞는다. - 실행 결과와 평가 내용을 자연어로 분석하는 **리플렉션(reflection)**을 통해 단순 점수 이상의 개선 정보를 활용할 수 있다. ## GEPA의 진화적 최적화 루프 - 여러 후보 프롬프트를 생성하고 각 후보를 평가한다. - 점수가 높거나 여러 평가 축에서 균형이 좋은 후보를 선택한다. - 후보의 출력과 피드백을 자연어로 분석해 문제점을 찾는다. - **Reflective Prompt Mutation**을 사용해 기존 프롬프트를 개선한 변이 후보를 생성한다. - 이 과정을 수~수십 세대 반복하면서 평가 기준에 맞는 프롬프트로 수렴시킨다. - 여러 평가 관점을 동시에 고려하기 위해 **Pareto frontier 기반 선택**을 사용한다. - 스칼라 보상 하나에만 의존하는 방식과 달리, “왜 감점됐는가”라는 설명을 개선 과정에 반영할 수 있다. ## DSPy와 GEPA를 이용한 구현 - DSPy에서는 입력과 출력을 정의한 `Signature`, 실행 로직을 담은 `Module`, 예측을 수행하는 `Predict`를 구성한다. - 시그니처의 독스트링은 LLM에 전달되는 인스트럭션으로 사용된다. - GEPA는 이 인스트럭션을 자동으로 재작성해 최적화한다. - 최적화 과정에서 다음 모델을 분리해 설정할 수 있다. - **추론 모델**: 실제 답변을 생성하는 모델 - **평가 모델**: 생성 결과를 채점하는 모델 - **리플렉션 모델**: 평가 결과를 바탕으로 개선 프롬프트를 만드는 모델 - `num_candidates`, `num_generations` 등의 설정으로 후보 수와 세대 수를 조정한다. - 최적화는 학습 예제 집합을 대상으로 `optimizer.compile()`을 실행해 수행한다. ## 평가 함수와 자연어 피드백 - GEPA의 평가 함수는 기본적으로 `score`라는 단일 스칼라 값을 반환해야 한다. - 평가 기준이 여러 개라면 각 점수를 0~10 범위로 계산한 뒤 평균 등을 사용해 하나의 값으로 정규화한다. - 예를 들어 구체성, 정책 준수, 가독성의 점수를 합산해 전체 점수를 만들 수 있다. - 동시에 `feedback` 필드에 감점 이유와 개선 방향을 자연어로 전달할 수 있다. - 점수만 전달하면 “0.6점”이라는 결과만 알 수 있지만, 피드백을 주면 “의료 판단을 단정적으로 표현해 감점됐다”처럼 구체적인 원인을 알 수 있다. - 정답 데이터가 있다면 `gold`를 사용해 기대 출력이나 레이블과 비교할 수 있다. - 정답이 없는 경우에도 LLM-as-a-Judge나 규칙 기반 평가를 사용할 수 있다. - LLM-as-a-Judge를 사용할 때는 평가 기준을 명확히 작성하고, 출력 점수의 범위를 제한하는 등 평가 결과를 정규화해야 한다. ## Yahoo! JAPAN Search 건강·의료 쿼리 적용 - 건강·의료 답변은 일반 쿼리보다 정책 요구가 많다. - 주요 정책에는 다음이 포함된다. - 질병명이나 중증도를 단정하지 않기 - 근거 수준에 맞는 표현 사용하기 - 일반적인 설명 범위를 유지하기 - 필요할 때 의료기관 진료를 권유하기 - 허위 정보나 확증되지 않은 정보를 제공하지 않기 - 동시에 제목, 목록, 강조 등 마크다운 형식을 적용해 가독성도 높여야 했다. - 정책 준수와 가독성은 한쪽을 강화하면 다른 쪽이 약화될 수 있어 사람이 동시에 최적화하기 어렵다. ## 실제 최적화 방식과 기대 효과 - 초기 프롬프트에는 기존 범용 프롬프트와 건강·의료 정책 문구가 단순히 이어 붙어 있었다. - GEPA는 시그니처의 인스트럭션 부분을 재작성하며 두 목표를 동시에 최적화했다. - 평가 함수는 여러 품질 관점의 점수를 집계하고, LLM이 작성한 평가 이유를 리플렉션 피드백으로 제공했다. - 결과적으로 수일~수주가 걸리던 프롬프트 조정 작업을 약 한 시간으로 줄이는 것을 목표로 했다. - 모델 업데이트나 정책 변경 때도 동일한 평가·최적화 파이프라인을 다시 실행할 수 있어 유지보수 자동화에 유리하다. 프롬프트 최적화를 도입할 때는 먼저 정책과 품질 기준을 세분화하고, 점수뿐 아니라 구체적인 자연어 피드백을 평가 함수에 포함하는 것이 중요하다. 다만 LLM 평가자의 편향과 변동성이 결과에 영향을 줄 수 있으므로, 가능하면 규칙 기반 검사와 정답 데이터 기반 평가를 함께 사용해 최적화된 프롬프트를 별도로 검증하는 것이 권장된다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델llm-as-a-judgeprompt-optimizationdspy+3

line·2026년 6월 22일·5분 읽기큐레이션 요약

분석 에이전트의 힘으로 분석을 하나로 연결하다! 전문 조직에서 도전하는 생성 AI 시대의 업무 혁신과 역할 전환

PJ One Piece는 생성형 AI 에이전트로 비즈니스 질문, 데이터 분석, 결과 해석, 다음 액션까지 연결해 분석 업무의 단절을 없애려는 프로젝트입니다. 기존에 평균 2주 걸리던 분석을 약 10분 만에 수행할 수 있게 되었고, 사업부 구성원의 절반 이상이 사용하는 플랫폼으로 확산되었습니다. 핵심은 단순한 SQL 자동화가 아니라 도메인 지식, 분석 프로세스, 도구, 로그와 피드백을 결합해 조직의 분석 역량을 지속적으로 축적하는 데 있습니다. ## 프로젝트 출범 배경: 세 가지 단절 - **비즈니스와 데이터의 단절** - DWH와 BI가 있어도 SQL 작성, 테이블·컬럼 선택, KPI 정의, 결과 해석에는 높은 장벽이 남아 있었습니다. - 데이터에 접근할 수 있는 것과 사업 담당자가 필요한 정보를 스스로 얻는 것 사이에 ‘마지막 1마일’이 존재했습니다. - **분석 프로세스 내 단절** - 과제 정의, 분석 설계, 실행, 리뷰, 액션이 담당자와 도구의 차이로 분리되었습니다. - 사업 배경과 의사 결정 목적이 제대로 전달되지 않아 재작업이 발생했고, 단계 사이의 대기 시간으로 리드타임이 길어졌습니다. - 분석 품질이 균일하지 않고 결과가 실제 액션으로 이어지는 속도도 떨어졌습니다. - **도메인 간 단절** - 사업마다 KPI, 테이블 구조, 사용자 행동, 시책 맥락이 달라 분석 지식과 패턴이 특정 도메인에 머물렀습니다. - 시책 평가, 퍼널 분석, 원인 분석처럼 구조가 유사한 분석도 조직 전체에서 재사용하기 어려웠습니다. ## 분석 에이전트로 분석 흐름 연결 - 사용자는 채팅 형태의 화면에서 자연어로 질문을 입력합니다. - 에이전트는 질문의 목적을 해석하고 분석 계획을 세운 뒤 다음 작업을 수행합니다. - 필요한 데이터와 문서 탐색 - SQL·Python 기반 집계 및 분석 - 시각화와 보고서 작성 - 결과 해석과 추가 분석 제안 - 다음 의사 결정과 액션 검토 - 자연어 질문만으로 분석을 시작할 수 있어 사업 담당자가 데이터 사이언티스트에게 요청하고 기다리는 구조를 줄입니다. - 질문 정리, 지표 선택, 비교 축, 리뷰 관점, 추가 분석 판단을 로그로 남겨 분석 지식과 패턴을 재사용 가능한 자산으로 만듭니다. ## 분석 플랫폼을 구성하는 다섯 가지 요소 - 사용자와 상호작용하는 애플리케이션 - 추론과 도구 사용을 담당하는 LLM 기반 에이전트 - SQL·Python 실행, 사내 문서 조사, 시각화 도구 - 도메인 지식, 스킬, 테이블 정보를 제공하는 지식 베이스 - 실행 로그, 사용자 피드백, 모니터링과 평가를 담당하는 측정 시스템 - 지식 영역은 도메인별 플러그인으로 확장할 수 있으며, 사용량이 늘수록 지식과 분석 패턴이 축적됩니다. ## 자연어 질문을 분석 요구 사항으로 변환 - 사용자가 상세한 분석 설계를 직접 작성하도록 요구하지 않고, 에이전트가 부족한 전제 조건만 확인합니다. - 예를 들어 캠페인 효과 분석에는 대상 정책, 기간, KPI, 비교 대상, 분석 단위, 제외 조건 등이 필요합니다. - 서비스 이해, KPI 정의, 집계 주의사항, 정책 탐색 방법, 리뷰 관점은 도메인 지식으로 관리합니다. - 테이블과 컬럼의 의미, 사용 조건, 적절한 활용 상황도 별도로 정비합니다. - 에이전트는 이미 확정 가능한 항목과 사용자 확인이 필요한 모호한 항목을 구분해 불필요한 질문을 줄입니다. ## 필요한 데이터에 안전하게 접근하는 구조 - 대규모 테이블 정보를 한꺼번에 LLM에 제공하지 않고 단계적으로 공개합니다. - 먼저 테이블 목록으로 후보를 좁힘 - 선택한 테이블의 상세 정의 확인 - SQL 작성 전에 컬럼 설명, 샘플, 파티션 조건, 사용상 주의사항 확인 - 원천 테이블을 그대로 사용하지 않고, 분석에 적합한 속성을 결합한 와이드 테이블을 논리적 뷰나 실제 테이블로 제공합니다. - 복잡한 JOIN을 줄여 SQL 생성 난이도와 오류 가능성을 낮춥니다. - SQL 실행 전후에 시스템 차원의 가드레일을 적용합니다. - `SELECT` 중심의 읽기 전용 제한 - 공개된 테이블 정의 및 사용 규칙 검증 - 파티션 조건 확인 - 개인정보·민감 정보 접근 제한 - 결과 행 수 제어 ## 멀티 에이전트로 분석 맥락 유지 - 슈퍼바이저형 멀티 에이전트 구조를 사용합니다. - 메인 에이전트는 사용자 요청, 분석 목적, 확인된 내용, 다음 판단 과제를 계속 관리합니다. - 통계 검정, 시계열 분석, 클러스터링, 리뷰 등 전문 작업은 역할이 제한된 서브 에이전트에 위임합니다. - 전체 분석 설계와 전문 작업을 분리해 긴 시행착오나 전문 분석이 전체 맥락을 압박하지 않도록 합니다. - 장시간 분석 중에는 발견 사항, 분석 설계, 사용 가능·불가능한 데이터, 제약 조건을 공유해 사용자가 중간에 방향을 수정할 수 있게 합니다. ## 로그와 스킬을 통한 조직 자산화 - 실행 로그로 다음 내용을 추적합니다. - 입력과 출력 - 에이전트의 도구 사용 과정 - 전제 조건 확인 방식 - 분석 설계와 생성된 SQL - 오류가 발생한 지점 - 사용자와 분석 담당자의 피드백을 결합해 프롬프트, 도구, 데이터, 스킬 중 개선이 필요한 영역을 백로그로 관리합니다. - 반복되는 분석은 스킬로 일반화합니다. - 범용 스킬: 시계열 분석, 클러스터링 등 - 도메인 특화 스킬: 월간 보고서, 정책 모니터링 등 - 스킬에는 전제 조건, 비교 축, 주의사항, 결과 해석 방법까지 포함해 다른 담당자와 도메인에서도 재사용할 수 있도록 합니다. ## 선행 도입으로 확인한 사업 가치 - 일부 서비스 사업부에 도입한 결과 구성원의 절반 이상이 사용하는 분석 플랫폼으로 성장했습니다. - 데이터 사이언티스트뿐 아니라 프로덕트 오너와 현장 구성원도 일상 업무에서 먼저 질문하는 진입점으로 활용하고 있습니다. - 기존 요청부터 결과 회신까지 평균 약 2주 걸리던 분석을 약 10분 만에 실행할 수 있게 되었습니다. - 월 수백 건의 분석이 실행되며 데이터 활용 인원이 빠르게 증가했습니다. 분석 AI를 도입할 때는 SQL 생성 자동화에만 집중하기보다, 도메인 지식 관리·데이터 접근 통제·분석 맥락 유지·로그 기반 개선까지 함께 설계하는 것이 중요합니다. 특히 반복 분석을 스킬과 조직 자산으로 축적해야 단기적인 생산성 향상을 넘어 지속적으로 성장하는 분석 플랫폼을 만들 수 있습니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트생성형 AIPython+4

github·2026년 6월 15일·3분 읽기큐레이션 요약

초보자를 위한 GitHub Copilot CLI: 자주 사용하는 슬래시 명령어 개요

GitHub Copilot CLI의 슬래시 명령은 모델 선택, 컨텍스트 관리, 세션 재개, 변경 사항 확인 등을 터미널에서 직접 수행하게 해주는 핵심 제어 기능이다. `/`를 입력하면 사용 가능한 명령 목록을 확인할 수 있으며, 각 명령을 익히면 작업 흐름과 권한을 더 효율적으로 관리할 수 있다. 특히 모델과 토큰 사용량을 상황에 맞게 조절하면 속도와 결과 품질을 균형 있게 유지할 수 있다. ## 슬래시 명령의 역할 - 슬래시 명령은 Copilot CLI에 내장된 제어 기능이다. - Copilot의 동작을 지시하고, 변경 사항과 컨텍스트를 확인하며, 세션과 프로젝트를 관리한다. - 터미널에서 `/`를 입력하면 현재 지원되는 명령을 스크롤 목록으로 확인할 수 있다. ## 작업에 맞는 모델 선택: `/model` - `/model`을 입력하면 사용 가능한 모델 목록이 표시된다. - 모델마다 적합한 작업이 다르다. - 간단한 리팩터링이나 빠른 작업에는 가벼운 모델이 적합하다. - 기능 설계나 복잡한 추론에는 더 강력한 모델이 유리하다. - 모델 목록은 사용 중인 요금제나 조직 설정에 따라 달라질 수 있다. - 각 모델 옆의 비용 배수는 사용량과 비용 수준을 비교하는 기준이 된다. - 작업의 복잡도와 속도, 비용을 고려해 모델을 선택해야 한다. ## 컨텍스트와 토큰 관리 ### 현재 사용량 확인: `/context` - `/context`는 현재 세션의 컨텍스트 사용량을 보여준다. - 남은 토큰 수, 시스템이 사용하는 공간, 추가로 활용 가능한 버퍼를 확인할 수 있다. - 컨텍스트 창이 가득 차면 Copilot이 이전 대화와 정보를 충분히 참고하기 어려워진다. ### 대화 압축: `/compact` - `/compact`는 현재 대화를 요약해 컨텍스트 공간을 확보한다. - 기존 세션을 유지하면서 새로운 작업으로 넘어갈 때 유용하다. - 컨텍스트 한도에 가까워지면 Copilot CLI가 자동으로 압축할 수 있지만, 사용자가 직접 실행할 수도 있다. ### 세션 초기화: `/clear` - `/clear`는 현재 세션을 완전히 지운다. - 이전 대화의 영향을 받지 않고 새로운 작업을 시작할 때 사용한다. ## 이전 세션 재개: `/resume` - `/resume`은 과거에 진행한 세션 목록을 표시한다. - 로컬 세션과 원격 세션을 모두 확인할 수 있다. - 세션을 선택하면 이전 작업 기록을 검토한 뒤 중단한 지점부터 작업을 이어갈 수 있다. ## 변경 사항 확인: `/diff` - `/diff`는 현재 세션에서 발생한 최근 변경 사항을 보여준다. - Copilot이 수정한 파일을 검토하고, 의도하지 않은 변경이 없는지 확인하는 데 사용한다. - 변경 내용을 검증한 뒤 커밋이나 다음 작업으로 넘어가는 것이 좋다. ## 작업 디렉터리 변경: `/cwd` - `/cwd`를 사용하면 Copilot을 종료하지 않고 다른 저장소나 디렉터리로 이동할 수 있다. - 여러 프로젝트를 오가며 작업할 때 편리하다. - Copilot의 작업 범위를 현재 선택한 프로젝트에 맞게 조정할 수 있다. ## 도구 권한 초기화: `/reset-allowed-tools` - `/reset-allowed-tools`는 이전에 허용한 파일 수정 등의 도구 권한을 초기화한다. - 신뢰 수준이 다른 저장소로 이동했을 때 기존 권한을 재설정하는 데 유용하다. - 민감한 프로젝트를 다룰 때 권한을 다시 확인하는 안전 장치로 활용할 수 있다. ## 실용적인 활용 방법 - 작업을 시작하기 전에 `/`를 입력해 사용 가능한 명령을 확인한다. - 복잡한 기능 설계에는 `/model`로 추론 능력이 높은 모델을 선택한다. - 컨텍스트가 부족해지면 `/context`로 상태를 확인하고 `/compact`를 실행한다. - Copilot이 코드를 수정한 뒤 `/diff`로 변경 내용을 검토한다. - 다른 프로젝트로 이동할 때는 `/cwd`, 권한을 정리해야 할 때는 `/reset-allowed-tools`를 사용한다. - 슬래시 명령을 익히면 Copilot CLI를 단순한 코드 생성 도구가 아니라 세션·컨텍스트·권한을 통제하는 작업 환경으로 활용할 수 있다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델github-copilot-clislash-commandscommand-line-interface+2

cloudflare·2026년 6월 15일·3분 읽기큐레이션 요약

Ensemble AI 출신 인재들과 함께 Cloudflare AI 팀을 확장하기

Cloudflare는 Ensemble AI의 핵심 인력을 영입해 AI 인프라와 추론 효율성 분야를 강화한다. 목표는 대규모·멀티모달 모델을 더 작고 빠르며 저렴하게 실행해, 개발자가 전 세계에서 AI 애플리케이션을 안정적으로 배포하도록 돕는 것이다. 이를 위해 모델 구조 개선, 메모리·연산량 감소, GPU 활용률 향상에 집중한다. ### Ensemble AI의 모델 효율화 기술 - Ensemble AI는 2023년 설립 이후 대규모 모델의 메모리, 연산량, 배포 비용을 줄이는 기술을 개발해왔다. - 단순한 양자화나 하드웨어 최적화가 아니라, 신경망의 구조 자체를 더 작고 효율적으로 만드는 접근을 취한다. - **NdLinear**는 트랜스포머의 표준 선형 계층을 대체하는 기술이다. - 다차원 활성값을 평탄화하지 않고 직접 처리한다. - 어텐션 헤드, 채널, 공간 차원 등 데이터의 의미 있는 구조를 보존한다. - 이를 통해 파라미터 수와 계산량을 줄인다. - **NdLinear-LoRA**는 대규모 모델을 파인튜닝할 때 학습해야 하는 파라미터 수를 줄이는 방식이다. - 양자화, 벡터 양자화와 결합하면 모델의 메모리 사용량과 실행 비용을 더욱 낮출 수 있다. ### Cloudflare Workers AI의 추론 효율 개선 - Workers AI는 Cloudflare의 글로벌 네트워크에서 서버리스 GPU 기반 추론을 제공한다. - AI 애플리케이션이 확산될수록 모델 추론 비용은 확장성을 결정하는 핵심 요소가 된다. - 모델 크기, 메모리 사용량, 처리량, GPU 활용률을 개선하면 개발자의 비용 부담을 줄이고 더 많은 AI 서비스를 운영할 수 있다. - 대상 워크로드는 텍스트 생성뿐 아니라 다음 영역으로 확대되고 있다. - AI 에이전트 - 멀티모달 모델 - 개인화 - 파인튜닝 - 검색 결합 생성(RAG) - 강화학습 - Cloudflare는 기존의 추론 엔진 **Infire**, 텐서 압축 기술 **Unweight**, 대규모 언어 모델 실행 플랫폼을 기반으로 효율화 작업을 강화한다. ### 글로벌 AI 인프라와 모델 압축의 결합 - 개발자는 이제 모델에 접근하는 것만으로는 충분하지 않으며, 모델을 저렴하고 안정적으로 사용자 가까이에서 실행할 인프라가 필요하다. - Cloudflare의 글로벌 네트워크와 서버리스 플랫폼은 AI 실행 환경을 애플리케이션이 이미 배포된 위치에 가깝게 제공할 수 있는 기반이 된다. - Ensemble AI의 모델 압축·효율적 아키텍처 기술을 결합하면 다음 효과를 기대할 수 있다. - 낮은 추론 비용 - 빠른 응답 속도 - 향상된 GPU 활용률 - 대규모 배포의 운영 복잡성 감소 - 다양한 모델 크기와 파인튜닝 방식에 대한 실험 용이성 ### 향후 목표 - Cloudflare는 강력한 AI 모델을 전 세계 규모로 실행하면서도 추론 경제성을 개선하는 것을 목표로 한다. - 새 팀은 대규모 언어 모델과 고급 AI 아키텍처의 서빙 비용을 낮추고, 효율적인 모델 실행과 확장 가능한 배포 방식을 발전시킬 예정이다. - 궁극적으로 개발자가 비용과 운영 부담에 막히지 않고 AI 애플리케이션을 구축·배포할 수 있는 플랫폼을 제공하려는 전략이다. 실용적으로는 AI 서비스를 설계할 때 모델 성능만 비교하기보다 파라미터 수, 메모리 사용량, GPU 활용률, 추론 지연시간, 글로벌 배포 비용을 함께 평가해야 한다. Cloudflare의 방향은 이러한 운영 비용을 모델 구조와 인프라 양쪽에서 동시에 줄이려는 접근으로 볼 수 있다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델머신러닝quantizationcloudflare-workers-ai+4

github·2026년 6월 12일·3분 읽기큐레이션 요약

GitHub Copilot CLI가 작업 위임을 더 선별적으로 하도록 만든 방법

GitHub는 Copilot CLI가 단순한 작업까지 불필요하게 서브에이전트에 위임해 발생하던 검색 반복, 도구 실패, 대기 시간을 줄이기 위해 위임 정책을 개선했다. 핵심은 좁고 명확한 작업은 메인 에이전트가 직접 처리하고, 독립적인 탐색·복잡한 조사·병렬 실행이 필요한 경우에만 서브에이전트를 활용하는 것이다. 그 결과 도구 실패가 23% 감소하고 P95 사용자 대기 시간이 5% 줄었으며, 품질 저하 없이 Copilot CLI 전체 트래픽에 적용됐다. ### 서브에이전트 위임은 항상 효율적이지 않다 - 서브에이전트는 복잡한 작업을 분해하고 여러 조사를 병렬로 수행하는 데 유용하다. - 하지만 단순한 파일 수정까지 위임하면 오히려 다음과 같은 비용이 발생한다. - 불필요한 에이전트 간 인계와 조정 - 동일하거나 겹치는 저장소 검색 - 메인 에이전트가 결과를 기다리는 시간 - 오래된 파일 경로, 잘못된 상대 경로, 워크스페이스 불일치에 따른 도구 실패 - 특히 메인 에이전트가 이미 충분한 맥락을 알고 있는데도 탐색 서브에이전트를 실행하면, 서브에이전트가 저장소를 다시 검색하면서 작업이 지연된다. ### 데이터 분석으로 불필요한 위임 패턴 식별 - GitHub는 에이전트의 전체 실행 궤적을 LLM으로 분석해 위임이 실제로 도움이 되는지 확인했다. - 분석 결과, 다음과 같은 작업에 서브에이전트가 과도하게 사용되고 있었다. - 범위가 좁고 명확한 작업 - 필요한 정보가 이미 핸드오프에 포함된 작업 - 파일을 찾고 읽은 뒤 한 곳을 수정하는 작업 - 이를 바탕으로 “간단한 탐색과 수정은 메인 에이전트가 직접 처리한다”는 방향을 개선 목표로 삼았다. ### 좁은 작업은 직접 처리하고 복잡할 때만 위임 - Copilot CLI의 새로운 정책은 가장 간단한 실행 경로에서 시작한다. - 파일 찾기 - 파일 읽기 - 특정 부분 수정 - 변경 사항 검증 - 다음과 같은 경우에는 서브에이전트 위임이 효과적이다. - 익숙하지 않은 대규모 저장소 탐색 - 서로 독립적인 코드 영역 조사 - 장시간 실행되는 명령 수행 - 여러 작업을 동시에 진행할 수 있는 경우 - 작업이 복잡하거나 불확실할 때 위임하고, 다시 작업 범위가 좁아지면 메인 에이전트가 직접 처리하도록 한다. - 서브에이전트는 메인 에이전트를 멈추게 하는 “일시정지 버튼”이 아니라, 독립 작업을 병렬화하는 도구로 사용해야 한다. ### 구체적인 핸드오프와 병렬 실행 - 서브에이전트를 실행할 때는 핸드오프에 다음 내용을 명확히 포함해야 한다. - 사용자가 요청한 전체 목표 - 메인 에이전트가 이미 파악한 정보 - 서브에이전트가 담당할 범위 - 반환해야 하는 결과의 형태 - 메인 에이전트는 서브에이전트의 결과를 기다리기만 하지 않고, 그동안 독립적으로 수행할 수 있는 작업을 계속 진행해야 한다. - 이 방식은 중복 검색과 순차적 대기를 줄이고, 실제로 병렬 처리가 가능한 작업에서 위임의 이점을 높인다. ### 오프라인 평가와 운영 환경 A/B 테스트 - GitHub는 자동 생성 회귀 테스트와 기존 벤치마크를 이용해 정책 변경을 먼저 오프라인에서 검증했다. - 이후 내부 사용자와 공개 사용자를 대상으로 A/B 테스트를 진행했다. - 평가 항목은 다음과 같았다. - 도구 안정성 - 사용자 응답성과 대기 시간 - 서브에이전트 사용량 - 최종 결과 품질 - 성능 향상은 개별 LLM 호출 자체를 빠르게 만든 결과가 아니라, 불필요한 서브에이전트 실행을 줄여 오케스트레이션 비용을 낮춘 결과였다. ### 측정된 개선 효과 - 세션당 도구 실패가 **23% 감소** - 검색 도구 실패: **27% 감소** - 편집 도구 실패: **18% 감소** - 사용자 대기 시간 개선 - P95: **5% 감소** - P75: **3% 감소** - 품질 저하는 관찰되지 않았다. - 개선된 위임 기능은 Copilot CLI 운영 트래픽의 100%에 배포됐다. - 사용자는 `/update` 명령으로 Copilot CLI **1.0.42 이상**으로 업데이트하면 적용된 기능을 사용할 수 있다. 간단한 작업에는 직접 실행을 우선하고, 서브에이전트는 독립성·복잡성·병렬성 때문에 실제 이득이 있을 때만 사용하는 것이 효율적이다. 이를 위해 위임 여부뿐 아니라 핸드오프의 구체성, 메인 에이전트의 병렬 진행 여부까지 함께 설계해야 한다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델github-copilot-cliorchestrationab-testing+2

dropbox·2026년 6월 12일·3분 읽기큐레이션 요약

Dropbox가 MCP와 Dash를 활용해 디자인에서 코드로 이어지는 보안 격차를 해소하는 방법

Dropbox는 보안 위협 모델과 실제 코드 구현 사이의 단절을 MCP, 기초 언어 모델, Dash를 결합해 해결하고자 했다. 시스템은 코드 리뷰 시 관련 위협 모델을 자동으로 검색하고, 문서에 정의된 보안 요구사항이 코드에 반영됐는지 비교한다. 분석 결과 구현 PR의 12%만 원래 보안 검토와 연결되어 있었으며, 보안 지식을 코드 리뷰 시점에 자동으로 제공하는 것이 핵심 해결책으로 제시된다. ## 설계와 코드 사이의 보안 격차 - 보안 검토에서는 잠재적 위험, 공격 가능성, 필요한 보호 조치를 위협 모델에 기록한다. - 그러나 개발이 시작되면 위협 모델은 위키나 문서 시스템에 남고, 구현 코드는 별도의 PR에서 관리된다. - 명시적인 링크가 없으면 코드 리뷰어가 과거의 보안 요구사항을 확인하기 어렵다. - Dropbox의 분석 결과: - 구현 PR 중 원래 설계 검토 및 위협 모델을 연결한 비율은 **12%**에 불과했다. - 검증된 79개 쌍 중 **54%**는 보안 검토 후 한 달이 지나서야 PR이 생성됐다. - 보안 검토부터 PR 생성까지의 중앙값은 약 **5주**였다. - 일부 지연은 **11개월 이상**이었다. - 검토 후 2주 이내에 생성된 PR은 **29%**뿐이었다. ## 기존 보안 도구의 한계 - 정적 분석 도구는 코드에 특정 보안 제어가 존재하는지 확인할 수 있다. - 하지만 해당 제어가 설계 검토에서 합의한 요구사항과 일치하는지는 판단하기 어렵다. - 정적 분석은 코드의 패턴은 검사하지만, 설계 의도와 이전에 결정된 보안 맥락은 알지 못하기 때문이다. - 개발자에게 설계 문서와 PR을 직접 연결하도록 요구하거나 알림 봇을 사용하는 방식도 지속적인 준수에 의존한다. - 설계 검토의 약 **15%**는 코드가 먼저 작성된 뒤 사후적으로 진행됐다. - 따라서 자동화 시스템은 기존 검토와 코드를 연결하는 것뿐 아니라, 보안 검토가 필요할 가능성이 있는 작업을 개발 중 조기에 식별하는 역할도 할 수 있다. ## Dash와 MCP를 활용한 컨텍스트 연결 - Dash는 여러 연결된 애플리케이션의 문서를 색인하므로, 기존 위협 모델과 엔지니어링 문서를 통합적으로 검색할 수 있다. - Dropbox는 코드가 리뷰에 제출될 때 관련 위협 모델을 자동으로 검색하도록 시스템을 구축했다. - MCP(Model Context Protocol)는 AI 에이전트가 Dash가 색인한 문서에 접근하도록 하는 연결 계층이다. - 보안 검토 에이전트는 Dash의 MCP 서버를 통해 위협 모델과 관련 문서를 검색하고 읽는다. - 별도의 소스 시스템별 맞춤 통합 없이 여러 컨텍스트를 하나의 에이전트 세션에 결합할 수 있다. ## 요구사항과 구현 코드의 비교 - 코드 리뷰가 시작되면 에이전트는 관련 위협 모델과 보조 문서를 가져온다. - 기초 언어 모델은 문서에 기록된 보안 요구사항과 변경된 코드를 함께 분석한다. - 예를 들어 위협 모델이 특정 엔드포인트에 인증을 요구한다면, 실제 코드가 인증을 강제하는지 판단할 수 있다. - 기존 정적 분석과 달리 단순히 취약한 코드 패턴을 찾는 것이 아니라, **설계 단계의 보안 결정이 구현에 반영됐는지**를 검토한다. - 결과를 별도의 보안 절차가 아니라 개발자가 이미 사용하는 코드 리뷰 과정에 제공하는 것이 중요한 설계 원칙이다. ## 실용적인 결론 보안 검토 문서를 별도로 잘 작성하는 것만으로는 충분하지 않다. 해당 문서의 요구사항이 코드가 검토되는 시점에 자동으로 노출되고 구현과 비교되어야 하며, 이를 위해 조직의 기존 문서 검색 시스템과 MCP 기반 AI 에이전트를 코드 리뷰 흐름에 통합하는 접근이 효과적이다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델모델 컨텍스트 프로토콜코드 리뷰static-analysis+2

github·2026년 6월 11일·1분 읽기큐레이션 요약

비밀 스캔의 신뢰성 향상: 대규모 환경에서 오탐 줄이기

Mariko는 Microsoft의 Principal Applied Scientist로서 사이버보안 운영을 위한 에이전트형 AI 워크플로 개발을 이끌고 있습니다. 특히 LLM 기반 시스템과 에이전트 워크플로를 연구하며, 최신 AI 연구를 실제 제품과 운영 환경에 적용하는 데 집중합니다. ### Microsoft에서의 역할 - Microsoft의 Principal Applied Scientist로 활동 - 사이버보안 운영을 위한 에이전트형 AI 워크플로 개발 주도 - AI를 실제 보안 업무와 운영 프로세스에 통합하는 역할 수행 ### 주요 연구 관심사 - LLM 기반 시스템 - 여러 단계의 작업을 자율적으로 수행하는 에이전트형 워크플로 - 최신 AI 연구를 현실적인 제품과 운영 환경에 적용하는 방법 ### 실무적 의미 - AI 에이전트가 사이버보안 운영을 자동화하거나 지원할 가능성을 보여줌 - 연구 성과를 실제 제품과 보안 업무에 연결하는 응용 중심의 접근을 강조함

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트cybersecurityai-workflows+1

slack·2026년 6월 11일·4분 읽기큐레이션 요약

에이전트 기반 테스트: E2E 테스트 스택에서 에이전트가 적합한 위치

에이전트 기반 E2E 테스트는 기존의 결정적 테스트를 대체하기보다, 사용자의 목표 달성 여부를 탐색적으로 검증하는 별도의 계층으로 활용해야 한다. 200회 이상 실험한 결과 Playwright MCP 기반 에이전트가 복잡한 흐름에서도 가장 안정적이었고, 생성된 Playwright 테스트는 단순한 흐름에서는 빠르지만 복잡도가 높아질수록 실패율이 크게 증가했다. 따라서 전통적 테스트는 핵심 회귀 검증에, 에이전트 테스트는 유연한 탐색과 목표 중심 검증에 배치하는 것이 적절하다. ## 여정 검증에서 목표 검증으로 - 전통적인 E2E 테스트는 `클릭 → 클릭 → 입력 → 검증`처럼 미리 정해진 UI 경로를 검증한다. - 에이전트 기반 테스트는 “스레드 메시지를 보내라”처럼 목표를 제시하고, 에이전트가 현재 UI 상태에 따라 경로를 선택하게 한다. - 동일한 결과에 도달하더라도 다음과 같은 차이가 발생했다. - 검색 제안 클릭 또는 Enter 키 사용 - 검색 화면을 다시 열거나 기존 상태 재사용 - 중간 클릭, 스냅샷 확인 등의 추가·생략 - 에이전트는 중간 단계도 검증할 수 있지만, 경로의 유연성 때문에 실행 시간·비용·신뢰성 관리가 필요하다. ## 실험 구성과 비교 대상 - 200회 이상의 자동 실행으로 신뢰성, 속도, 비용을 비교했다. - 비교한 실행 방식은 세 가지다. - **에이전트 + Playwright MCP**: 브라우저 액션과 DOM 상태·로그를 지속적인 컨텍스트로 사용 - **에이전트 + Playwright CLI**: 셸에서 명령을 한 단계씩 실행하고 매번 UI 상태를 바탕으로 다음 행동 결정 - **생성된 Playwright 테스트**: 자연어 설명으로 결정적 테스트 코드를 생성한 뒤 실행·수정 - Claude Sonnet 4.5와 Opus 4.6을 사용했으며, 비운영 데이터가 있는 테스트 워크스페이스에서 실행했다. - 입력 형식은 다음 두 가지였다. - 자연어 지시: 사람이 읽기 쉬운 단계별 설명 - 구조화된 YAML: 단계, 액션, 대상, 기대 결과를 명시 - 각 설정은 20회씩 실행했다. ## 테스트한 사용자 흐름 - **Thread Reply** - 약 15~20단계의 단순한 흐름 - 채널 생성, 메시지 전송, 스레드 답글 작성, 스레드 상태 확인 - **Search Discovery** - 약 25~30단계의 중간 복잡도 흐름 - 검색어 입력, 검색 결과 탐색, 채널·스레드·검색 화면 간 이동, 결과 검증 ## 측정 결과 | 방식 | Thread Reply 실패율 | Search Discovery 실패율 | 평균 실행 시간 | |---|---:|---:|---:| | 에이전트 + Playwright MCP | 0% | 약 12% | 약 5~8분 | | 에이전트 + Playwright CLI | 약 12% | 약 20% | 약 9~11분 | | 생성된 Playwright 테스트 | 약 8% | 약 48% | 약 3분 | - 에이전트 테스트는 실행당 15~30달러가 들고 10분 이상 걸릴 수 있어, 일반적인 빠른 회귀 테스트를 그대로 대체하기에는 부담이 있다. - 그러나 전통적 테스트와 목적이 다르므로 단순한 실패율만으로 비교해서는 안 된다. ## 복잡도가 높아질수록 벌어지는 신뢰성 차이 - Playwright MCP는 단순한 시나리오에서 거의 실패하지 않았고, 복잡한 흐름에서도 실패율이 0~12% 수준이었다. - Playwright CLI는 인증 처리, 탐색 타이밍, 세션 불안정 등 실행 환경 문제로 약 12~20%의 실패율을 보였다. - 생성된 Playwright 테스트는 단순한 흐름에서는 약 8% 실패했지만, 복잡한 검색 흐름에서는 약 48%까지 악화됐다. - 생성 테스트는 대체로 전체 흐름의 70~80%까지 진행한 뒤 마지막 상호작용이나 assertion에서 실패했다. - 주요 원인은 다음과 같다. - UI 상태의 변동성 - 자연어 명세와 실제 요소 선택 간의 추상화 불일치 - 기존 Page Object 추상화가 복잡한 상황에서 정확한 요소 지정을 방해 - MCP는 애플리케이션의 실시간 상태를 안정적으로 유지하는 반면, CLI는 단계마다 스냅샷을 다시 구성한다. - 긴 흐름에서는 상태 해석과 타이밍의 작은 차이가 누적되어 CLI 방식의 실패 가능성이 커질 수 있다. ## 테스트 스택에서의 적절한 역할 - 전통적인 결정적 Playwright 테스트는 빠르고 반복 가능하므로 핵심 회귀 테스트와 CI의 기본 검증에 적합하다. - 에이전트 기반 테스트는 특정 클릭 순서가 아니라 “사용자가 목표를 달성할 수 있는가”를 검증하는 데 적합하다. - 특히 다음 영역에서 활용 가치가 있다. - 다양한 UI 경로를 허용해야 하는 사용자 여정 - 사전에 모든 경로를 코드로 작성하기 어려운 탐색적 테스트 - 복잡한 화면 상태와 실제 사용자 행동에 가까운 검증 - 에이전트 방식 중에서는 실시간 브라우저 컨텍스트를 유지하는 Playwright MCP가 복잡한 시나리오에 더 적합한 것으로 나타났다. - 다만 높은 비용과 긴 실행 시간을 고려해 모든 커밋에서 실행하기보다는, 야간 테스트나 릴리스 전 검증 등 별도 계층에 배치하는 것이 현실적이다. 에이전트 기반 E2E 테스트는 결정적 테스트의 대체재가 아니라 보완재로 도입하는 것이 좋다. 빠르고 안정적인 핵심 회귀 검증은 기존 Playwright 테스트로 유지하고, MCP 기반 에이전트 테스트를 목표 중심·탐색적 검증에 제한적으로 추가하는 구성이 가장 실용적이다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트모델 컨텍스트 프로토콜claude+3

toss·2026년 6월 9일·3분 읽기큐레이션 요약

빠르게 움직이는 조직에서, TAM은 어떻게 문제를 해결할까?

TAM CONNECT 2025는 토스와 카카오페이의 TAM들이 기술과 비즈니스를 연결하는 역할과 운영 문제 해결 방식을 공유한 자리였습니다. 두 회사의 환경은 달랐지만, 알림 노이즈·담당자 의존성·고객사 커뮤니케이션·AI 활용 등 현장에서 겪는 고민은 비슷했습니다. 글은 TAM을 단순 기술지원이 아닌, 복잡한 문제를 구조화하고 서비스와 조직을 개선하는 기술 기반 문제 해결자로 정의합니다. ## TAM의 역할과 해결하는 문제 - 파트너사의 연동 문제를 해결하고 API 도입을 기술적으로 지원합니다. - 장애 발생 시 고객사와 내부 개발·운영 조직을 연결하고 대응을 조율합니다. - 운영 프로세스를 개선하고 반복되는 문제를 자동화합니다. - 서비스와 플랫폼 구조를 더 나은 방향으로 개선하는 데 참여합니다. - 로그 분석, 우선순위 조율, 장애 대응 등 개발자·PM·운영 담당자의 역할을 상황에 따라 수행합니다. - 인증, Face Connect, 금융 플랫폼, 결제, 파트너 API 등 다양한 서비스 영역을 다룹니다. ## 알림 노이즈를 줄이고 문제를 구조화하기 - 모든 알림이 중요한 것은 아니므로 “정말 확인해야 하는 문제는 무엇인가?”를 먼저 정의했습니다. - 불필요한 알림을 줄이고 장애 패턴을 체계화했습니다. - 반복 이슈를 자동으로 탐지하는 시스템을 구축했습니다. - 정산 불일치의 근본 원인을 분석해 단기 대응이 아닌 재발 방지에 집중했습니다. - 장애를 빠르게 처리하는 것을 넘어, 장애가 반복되지 않는 운영 구조를 만드는 데 초점을 맞췄습니다. ## 특정 담당자에게 의존하지 않는 운영 - 운영 지식이 일부 담당자에게 집중되는 문제를 해결하려 했습니다. - 대응 이력을 투명하게 공유하고 구성원 모두가 같은 정보를 확인할 수 있도록 했습니다. - 담당자가 바뀌어도 누구나 신속하게 문제를 해결할 수 있는 협업 구조를 만들었습니다. - n8n 기반 워크플로 자동화로 디스코드 개발자 커뮤니티의 평균 응답 시간을 10분 이내로 유지했습니다. - LLM을 활용해 로그를 분석하고 장애 원인과 해결 가이드를 자동으로 제안했습니다. ## 고객사 경험을 운영 개선으로 연결하기 - 고객사 담당자였던 경험을 바탕으로 고객이 느끼는 답답함과 필요한 커뮤니케이션을 이해했습니다. - PDCA(Plan-Do-Check-Act) 사이클을 활용해 연동 가이드를 지속적으로 개선했습니다. - 반복되는 문의와 커뮤니케이션을 표준화했습니다. - 운영 프로세스를 구조화해 동일한 문제가 되풀이되지 않도록 했습니다. - TAM의 목표를 단순한 문제 해결이 아니라 문제의 재발 방지로 확장했습니다. ## 회사는 달라도 비슷한 운영 고민 - 고객사와 내부 개발팀 사이에서 이해관계와 우선순위를 조율해야 합니다. - 빠르게 변하는 서비스와 복잡해지는 운영 구조에 대응해야 합니다. - 기술과 비즈니스를 동시에 이해해야 하는 역할의 부담이 있습니다. - TAM은 지원 조직이나 단순 운영 인력이 아니라, 여러 조직을 움직이며 문제를 구조화하는 역할입니다. - 결과적으로 TAM은 기술 기반의 Problem Solver에 가깝다는 공감대가 형성됐습니다. ## AI 시대의 TAM - 로그 분석, 장애 원인 추천, 운영 가이드 생성에 AI를 활용할 수 있습니다. - 반복 문의 응답, 이상 탐지, 문서 검색과 요약도 자동화 대상입니다. - AI가 반복 업무를 대신할수록 TAM은 복잡한 문제 해결과 구조적 개선에 집중하게 됩니다. - 조직 간 조율, 고객 경험 설계, 운영 전략 수립처럼 높은 판단력이 필요한 업무의 중요성이 커질 전망입니다. ## 실용적인 시사점 TAM 조직은 반복 문의와 장애를 개인의 경험으로 처리하기보다, 알림 기준·대응 이력·문서·자동화 시스템으로 표준화하는 것이 중요합니다. 또한 AI를 단순 응답 자동화에만 사용하지 말고, 장애 재발 방지와 운영 구조 개선까지 확장해야 합니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델APIincident-managementfintech+4