figma·2026년 8월 13일·3분 읽기큐레이션 요약

올바른 방향으로 빠르게 나아가는 방법 | Figma 블로그

AI는 소프트웨어 제작 속도를 크게 높였지만, 빠른 실행이 곧 올바른 제품을 의미하지는 않는다. AI가 만든 결과물을 그대로 받아들이면 기술 부채가 늘고, 평균적인 디자인과 기능에 머물 수 있다. 따라서 좋은 팀은 먼저 무엇을 만들지 충분히 고민하고, 명확한 맥락과 시스템을 제공한 뒤, 자신만의 관점으로 결과물을 다듬어야 한다. ## AI는 실행을 가속하지만 판단을 대신하지 못한다 - AI는 짧은 프롬프트만으로도 완성도 높아 보이는 프로토타입과 코드를 만들어낸다. - 그러나 겉보기의 완성도는 내부 구조, 제약 조건, 시스템 동작 방식까지 올바르다는 뜻이 아니다. - 과거에는 결과물의 세련됨 뒤에 전문가의 의사결정과 트레이드오프가 있었지만, 이제는 AI가 그 빈틈을 임의로 채울 수 있다. - **인지적 항복(cognitive surrender)**은 AI의 출력을 검토 없이 자신의 판단처럼 받아들이는 현상이다. - 첫 번째 결과물이 그럴듯하다는 이유로 바로 출시하지 말고, 문제의 본질과 실제로 만들 가치가 있는 것을 먼저 정의해야 한다. 글에서는 이를 **고려의 의무(consideration imperative)**로 표현한다. ## 맥락과 의도를 먼저 제공해야 한다 - 에이전틱 엔지니어링에서는 개발자의 역할이 코드를 직접 작성하는 것에서 **의도를 명확히 표현하고 검증하는 것**으로 이동한다. - Google의 관련 백서는 다음 요소를 중요한 기반으로 제시한다. - **결정론적 계층**: 테스트, 타입 검사, 검증처럼 매번 동일하게 실행되며 AI의 오류를 잡는 장치 - **고신호 맥락**: 명세, 문서화된 컴포넌트, 설계 원칙 등 에이전트가 의도를 정확히 이해하도록 돕는 정보 - **명확한 인터페이스**: 시스템 각 부분이 어떻게 연결되는지 에이전트가 추측하지 않도록 정의한 계약 - 디자인에서 코드로 전환할 때도 에이전트가 실제 프로덕션 컴포넌트의 구조를 모르면 픽셀을 보고 임의로 재구성할 가능성이 높다. - Figma MCP의 Code Connect처럼 실제 컴포넌트의 코드, props, variants를 제공하면 에이전트가 기존 시스템에 맞는 결과를 만들 수 있다. - 강력한 디자인 시스템은 결정 사항을 재사용 가능한 어휘와 가드레일로 codify해 결과물의 일관성을 높이고 코드와 기술 부채를 줄인다. - 초기에는 명세와 시스템을 준비하는 데 더 많은 시간이 들지만, 장기적으로 유지보수 비용을 낮춘다. ## “괜찮은 결과”는 쉽게 평균이 된다 - AI 모델은 방대한 기존 데이터를 학습했기 때문에 이미 널리 사용된 패턴과 스타일, 즉 **분포 안의 평균적인 결과**를 생성하는 경향이 있다. - 예를 들면 다음과 같은 결과가 반복될 수 있다. - 로고: 단순한 기하학적 형태와 그라디언트 - 발표 자료: 흔한 산세리프 글꼴과 익숙한 레이아웃 - React 컴포넌트: 둥근 모서리의 전형적인 카드 UI - 이런 결과는 틀리지는 않지만 차별성이 부족하다. - AI가 만든 “충분히 좋은” 결과를 반복해서 받아들이면 사용자의 판단 기준이 좁아지고, “무엇이어야 하는가?”보다 “덜 나쁜 선택은 무엇인가?”를 고르게 된다. - AI의 품질이 향상될수록 개인이 과거보다 나은 결과를 만들 수 있지만, 동시에 다른 AI 생성물과 비슷해질 위험도 커진다. ## 제품의 관점은 사람이 결정해야 한다 - AI는 실행과 변형을 빠르게 수행할 수 있지만, 제품의 목적과 차별화된 방향까지 자동으로 결정하게 두어서는 안 된다. - 명확한 의도와 평가 기준이 없으면 모델이 기본값과 평균적인 패턴을 대신 선택한다. - 팀은 AI가 제시한 결과를 출발점으로 활용하되, 왜 이 기능과 디자인이 필요한지, 누구를 위한 것인지, 무엇이 달라야 하는지를 직접 판단해야 한다. - 결국 속도의 핵심은 첫 결과물을 빨리 내는 것이 아니라, 명확한 맥락과 검증 장치를 통해 **올바른 방향으로 빠르게 반복하는 것**이다. AI를 활용할 때는 프롬프트 작성보다 먼저 목표, 제약 조건, 성공 기준을 문서화하는 것이 좋다. 테스트·타입 검사·디자인 시스템·명확한 인터페이스를 갖추고, AI 결과물을 반드시 사람의 관점과 제품 기준으로 검토해야 평균적인 결과와 기술 부채를 피할 수 있다.

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

대규모 언어 모델AI디자인 시스템React+3

toss·2026년 8월 13일·5분 읽기큐레이션 요약

AI에게 투자정보를 말하게 하기까지

LLM을 활용한 금융 투자 정보 서비스의 핵심은 문장을 잘 생성하는 데 있지 않고, 생성 전후의 근거 선별·검증·관찰 체계를 설계하는 데 있습니다. 토스증권은 이를 위해 세 가지 관문을 제시합니다. 즉, 말할 정보를 고르고, 생성 과정을 통제하며, 결과를 평가 가능한 구조로 만드는 것입니다. ## 금융 투자 정보가 일반 요약보다 어려운 이유 - **적시성**: 시장 상황은 빠르게 변하므로 늦은 설명은 부정확한 정보가 될 수 있습니다. - **정확성**: 기사에 기업명이 등장했다는 사실만으로 해당 기업의 주가 변동을 설명할 수 없습니다. - 자회사 관련 내용인지 - 유사한 이름의 다른 기업인지 - 단순 홍보성 기사인지 구분해야 합니다. - **검증 가능성**: 모든 설명에 근거를 남기고, 결과를 평가하며, 오류 발생 시 재현할 수 있어야 합니다. - **비정상성**: 실적 시즌, 금리 이벤트, 선거, 지정학적 이슈 등에 따라 데이터 분포와 시장 반응이 달라집니다. ## LLM과 에이전트의 불확실성 - LLM은 비정형 텍스트를 자연어로 재구성하는 데 강하지만, 근거가 부족하면 유창한 오답을 생성할 수 있습니다. - 에이전트 구조에서는 다음과 같은 오류가 여러 단계로 전파될 수 있습니다. - 검색 단계에서 잘못된 근거 선택 - 툴 호출 결과의 오해 - 이전 단계의 잘못된 상태를 다음 판단에 사용 - 따라서 투자 정보 서비스에서는 에이전트의 자율성을 무조건 확대하기보다, 필요한 부분은 제한하고 생성 전후의 통제를 강화해야 합니다. ## 첫 번째 관문: 말할 정보 고르기 ### 입수 단계에서 메타데이터 구축 - 뉴스·공시·재무 데이터를 수집할 때 BERT 기반 분류 모델로 미리 분류합니다. - 데이터에는 다음과 같은 정보를 함께 저장합니다. - 산업·시장·콘텐츠 유형 등의 `taxonomy_tags` - 관련 기업인 `related_entities` - 벡터 검색을 위한 `embedding` - 검색 시점에 매번 분류하는 대신, 데이터가 들어올 때부터 검색과 검증에 필요한 구조를 갖춥니다. ### 후보를 넓게 검색한 뒤 단계적으로 축소 - 하이브리드 리트리버로 후보를 넓게 확보해 재현율을 우선합니다. - 이후 다음 절차로 부적절한 정보를 제거합니다. - **중복 제거**: 의미 유사도 기반으로 같은 이벤트를 클러스터링하고 대표 출처만 남깁니다. - **리랭킹·필터링**: 기업 주가 움직임과의 직접적 관련성을 기준으로 순위를 조정합니다. - **설명 유형 분류**: 실적, 가이던스, 기업 행동 등 주요 설명 패턴을 분류합니다. - **실패 사유 분류**: 광고성, 홍보성, 근거 부족 등의 라벨을 붙여 필터링합니다. - 최종 근거는 다음 순서로 배치합니다. - 무슨 일이 있었는가 - 대상 기업과 어떻게 연결되는가 - 주가 방향과 근거의 방향성이 일치하는가 - 근거가 충분하고 최신인가 이 과정은 LLM에 전달할 정보를 압축하고, 비즈니스 요구에 맞게 배치하는 **컨텍스트 엔지니어링**입니다. ## 두 번째 관문: 생성 과정 통제하기 ### 절차형 태스크 그래프 - 검색, 관련성 판단, 중복 제거, 근거 구성, 응답 생성 등을 독립된 단계로 나눕니다. - 각 단계의 입력·출력 스키마를 명확히 정의하면 다음 효과가 있습니다. - 단계별 디버깅과 평가 가능 - 비용과 레이턴시 예측 - 실패 지점 추적 - 단계별 폴백 설계 ### 자율형 에이전트와 절차형 오케스트레이션의 구분 - 탐색 과정 자체가 중요한 업무에는 자율형 에이전트가 적합합니다. - 투자 아이디어 발굴 - 시장 이벤트의 잠재 시나리오 탐색 - 응답 형식과 판단 절차가 명확한 업무에는 절차형 그래프가 유리합니다. - 특정 기업의 주가 등락 원인 설명 - 정해진 근거 검증과 방향성 판단 - 긴 ReAct 루프는 툴 호출, 토큰, 레이턴시와 실행 경로를 늘리므로 제품 요건이 명확할 때는 과도할 수 있습니다. - 이 경우 LLM은 검색과 판단을 모두 자율적으로 수행하기보다, 요약·재작성·근거 기반 설명에 집중시키는 편이 안정적입니다. ### 절차형 그래프의 재사용성 - 절차형 그래프는 단순한 운영 안정화 수단을 넘어 다른 에이전트가 호출할 수 있는 기능 인터페이스가 됩니다. - 예를 들어 다음과 같은 입력과 출력의 도구로 제공할 수 있습니다. - 입력: 종목, 주가 방향, 시간 범위 - 처리: 검색 → 관련성·방향성 판단 → 중복 제거 → 근거 정렬 → 설명 생성 - 출력: 설명, 근거 목록, 추론 유형 등 - 이렇게 구성하면 상위 에이전트가 복잡한 절차를 직접 계획하지 않고 검증된 기능을 재사용할 수 있습니다. ## 세 번째 관문: 평가 가능한 결과 만들기 ### 범주형 루브릭과 구조화된 출력 - 자연어 답변만 생성하지 않고, 답변과 함께 이벤트 유형·실패 사유 등의 분류값도 생성합니다. - 이를 통해 다음 지표를 측정할 수 있습니다. - 관련성 오탐 감소 여부 - 주가 방향성과 근거 방향성의 불일치 비율 - 부적절한 이슈의 통과율 - 정밀도, 재현율, F1-score - 시장 국면이 바뀌면 새로운 실패 유형과 이벤트 유형을 추가할 수 있도록 분류 체계를 유연하게 운영해야 합니다. - 운영 중 발견된 문제, 평가 데이터셋, 프롬프트 버전, 모델 버전을 연결해야 개선 효과를 재현하고 수치로 확인할 수 있습니다. ### 맥락 기반 Few-shot Retrieval - 고정된 Few-shot 예시는 다양한 금융 이벤트와 시장 국면을 충분히 대표하지 못합니다. - 대신 운영 샘플에 다음 정보를 저장합니다. - 원문 - 판단 결과 - 실패 유형 - 유사도 검색용 임베딩 - 새로운 판단 요청이 들어오면 유사한 과거 사례를 검색해 포지티브·네거티브 예시를 함께 프롬프트에 넣습니다. - 성공 사례와 실패 사례를 동시에 제공하면 모델이 판단의 경계와 오류 패턴을 더 잘 파악할 수 있습니다. - 실제 관련성 검증 태스크에서 재현율을 유지하면서 정확도와 정밀도가 개선되었으며, 특히 False Positive 감소에 효과적이었습니다. ## 프롬프트와 모델 학습을 넘어 필요한 것 - 금융 AI 서비스 품질은 프롬프트와 모델만으로 결정되지 않습니다. - 운영을 위해 다음 요소가 함께 필요합니다. - 적절한 임베딩 모델과 리트리빙 전략 - 별도 분류 모델을 활용한 데이터 구조화 - 근거 검증과 실패 유형 관리 - 단계별 추적 및 평가 - 시장 국면 변화에 따른 평가셋·프롬프트 업데이트 투자 정보 서비스에서는 LLM의 자율성을 최대화하기보다, 근거를 선별하고 검증하는 절차를 명확히 설계하는 것이 중요합니다. 검색·분류·검증은 통제 가능한 그래프로 구성하고, LLM은 구조화된 근거를 바탕으로 설명을 생성하도록 제한하는 방식이 안정성과 확장성을 함께 확보하는 현실적인 접근입니다.

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

대규모 언어 모델프롬프트 엔지니어링multi-agent-systemsembeddings+4

google·2026년 8월 12일·4분 읽기큐레이션 요약

빈 서가인가, 잃어버린 열쇠인가? 회상은 매개변수적 사실성의 병목이다

LLM의 사실 오류는 사실을 학습하지 못해서라기보다, 이미 저장한 사실을 필요할 때 꺼내지 못해서 발생하는 경우가 많다. Google Research는 이를 측정하는 ‘지식 프로파일링’과 WikiProfile 벤치마크를 제안했으며, 최신 모델에서는 지식 습득보다 지식 활용과 회상이 사실성의 병목이라고 결론 내린다. 따라서 모델 규모 확대만으로는 한계가 있고, 저장된 지식을 안정적으로 회수하도록 하는 후처리·추론 기법이 중요해진다. ## 인코딩과 회상을 구분해야 하는 이유 - 일반적인 정확도 지표는 모델이 사실을 아예 학습하지 못한 경우와, 학습했지만 답변하지 못한 경우를 구분하지 않는다. - 두 실패의 원인은 다르다. - **인코딩 실패**: 사실이 모델 파라미터에 충분히 표현되지 않음 → 모델 규모 확대나 학습 데이터 보강이 필요하다. - **회상 실패**: 사실은 저장되어 있지만 외부 단서 없이 검색·활용하지 못함 → 후처리 학습이나 추론 시점 기법으로 개선할 가능성이 있다. - 글에서는 다음과 같이 개념을 구분한다. - **인코딩**: 사전학습 당시와 유사한 문맥에서 사실을 재현할 수 있는 능력 - **지식**: 표현이 달라지거나 질문 방향이 바뀌어도 사실에 답하는 능력 - **회상**: 인코딩된 사실을 별도 외부 단서 없이 꺼내는 능력 - **인식**: 여러 선택지 중 올바른 사실을 식별하는 능력 ## 지식 프로파일링과 다섯 가지 사실 상태 - 분석 단위를 개별 질문이 아니라 **사실 자체**로 바꾼다. - 각 사실을 다음 다섯 가지 상태로 분류한다. - 인코딩 실패 - 회상 실패 - 직접 회상 - 사고를 거친 회상 - 인코딩 없이 추론 - ‘사고를 거친 회상’은 중간 계산이나 다단계 추론을 유도해야만 답할 수 있는 경우다. - ‘인코딩 없이 추론’은 해당 사실 자체는 저장되지 않았더라도, 다른 사실들을 조합하거나 추측해 정답에 도달하는 경우를 뜻한다. ## WikiProfile 벤치마크 구성 - Wikipedia에서 추출한 2,150개의 사실을 대상으로 한다. - 사실은 문서에 먼저 등장하는 주체와 객체의 순서쌍으로 정의된다. - 각 사실에는 총 10개의 과제가 연결된다. - 인코딩 측정 2개 - 지식 평가 4개 - 인식 평가용 객관식 문제 4개 - 질문은 직접 질문과 역방향 질문을 모두 포함한다. - 예: “B는 무엇인가?”와 “A는 무엇인가?” - 질문 생성 후 정제·검색 기반 필터링·수작업 검증을 거쳐 모호하거나 정답이 여러 개인 사례를 제거했다. - 13개 LLM을 사고 기능 활성화 여부에 따라 평가했으며, 모델·사실·과제별로 8개 응답을 샘플링해 약 450만 개의 응답을 자동 평가했다. ## 최신 LLM의 병목은 인코딩이 아니라 회상 - Gemini 2.5 Pro, Gemini 3 계열, GPT-5 같은 프런티어 모델은 사실 인코딩률이 거의 포화 상태다. - Gemini 3 Pro와 GPT-5는 약 **95~98%의 사실을 인코딩**하고 있다. - 그러나 사고 없이 직접 회상하는 데는 여전히 **26~34%의 사실에서 실패**한다. - 사고를 허용해도 **11~12%의 사실은 여전히 회상하지 못한다.** - 모델 규모를 키우면 인코딩 실패는 크게 줄지만, 회상 실패는 상당 부분 남는다. - 즉, 스케일링은 모델이 “무엇을 저장하는가”는 개선하지만, “저장된 것을 얼마나 안정적으로 꺼내는가”는 상대적으로 덜 개선한다. ## 회상이 어려워지는 조건 - 회상 능력은 사실을 학습할 때의 조건과 밀접하게 연결된다. - 질문의 표현, 문맥, 정보의 배열 순서가 학습 당시와 달라지면 사실이 저장되어 있어도 접근하기 어려워질 수 있다. - 이는 모델의 지식 부족이라기보다, 저장된 지식에 연결되는 단서가 충분히 활성화되지 않는 문제로 해석할 수 있다. ## 희귀 사실과 롱테일 지식 - 기존 연구는 모델이 희귀한 사실에 약한 이유를 주로 모델 용량 부족으로 설명했다. - 이 연구에서는 희귀 사실도 인기 있는 사실과 비슷한 수준으로 인코딩되는 경우가 많다고 본다. - 인기 있는 사실과 희귀한 사실의 인코딩률 차이는 비교적 작지만, 회상률 차이는 더 크게 나타난다. - 따라서 롱테일 사실의 문제는 “모델이 전혀 저장하지 않았다”기보다 “저장했지만 적절한 상황에서 꺼내지 못한다”는 관점으로 재해석할 수 있다. ## 실용적인 결론 - 사실성 개선을 위해 단순히 모델 크기와 학습 데이터만 늘리는 전략에는 한계가 있다. - 저장된 지식을 다양한 표현과 질문 방향에서 안정적으로 회수하도록 하는 후처리 학습, 프롬프트 설계, 사고 유도 기법을 함께 개발해야 한다. - 모델 평가에서도 단일 정답률보다 인코딩·직접 회상·사고 기반 회상·인식 능력을 분리해 측정하는 것이 바람직하다.

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

대규모 언어 모델benchmarkingchain-of-thoughtpre-training+3

cloudflare·2026년 8월 7일·4분 읽기큐레이션 요약

레이더 리서처 소개: 자연어로 인터넷 데이터를 탐색하는 AI 도구

Cloudflare Radar Researcher는 자연어 질문만으로 인터넷 트래픽 데이터를 조회하고, 실제 API 기반 차트와 설명을 제공하는 AI 도구다. 사용자는 복잡한 필터 설정이나 API 문서 학습 없이 국가별 인터넷 품질, 장애·셧다운 상황 등을 분석할 수 있다. Cloudflare는 이를 통해 초보자부터 네트워크 전문가까지 Radar의 공개 데이터를 더 빠르고 쉽게 활용하도록 하는 것을 목표로 한다. ## Radar Researcher를 만든 배경 - Cloudflare Radar는 2020년부터 전 세계 인터넷 트래픽에 대한 공개 데이터와 시각화를 제공해 왔다. - 주요 데이터에는 다음이 포함된다. - 1.1.1.1 공개 DNS 리졸버의 DNS 질의 - Cloudflare 글로벌 네트워크의 HTTP 트래픽 - Cloudflare Speed Test 기반 네트워크 품질 데이터 - 기존에는 사용자가 적절한 Radar 페이지를 찾고, 필터를 설정하고, API 문서를 읽어야 했다. - AI 도구의 발전으로 데이터셋의 구조와 전문 용어를 몰라도 자연어로 원하는 정보를 얻을 수 있게 되었다. - 기자나 연구자처럼 신속하게 데이터를 확인해야 하는 사용자는 복잡한 탐색 과정을 거치지 않고 바로 분석을 시작할 수 있다. ## 자연어 기반 데이터 질의 - Radar Researcher는 사용자의 질문을 해석해 Radar API에 필요한 데이터 요청을 자동으로 구성한다. - 답변은 단순한 텍스트가 아니라 Radar에서 제공하는 것과 같은 인터랙티브 차트와 간단한 설명으로 제공된다. - 답변의 깊이를 선택할 수 있다. - 짧고 직접적인 답변 - 여러 주제를 다루는 상세 보고서 - 답변 뒤에는 추가로 조사할 만한 후속 질문을 제안한다. - 대화 기록은 검색·고정할 수 있고, 링크로 공유할 수 있다. - 공유 링크는 30일 후 자동 만료된다. - 사용자는 텍스트 입력뿐 아니라 음성 입력이나 Radar 검색창에서도 Researcher를 실행할 수 있다. - 모델이 질문을 어떻게 해석했고, 어떤 데이터셋과 API를 사용했으며, 결과를 어떻게 분석했는지 확인할 수 있다. ## 기존 차트에서 바로 분석 시작 - Radar의 차트에 있는 **Explain with AI** 기능을 사용하면 현재 보고 있는 시각화를 대화의 출발점으로 삼을 수 있다. - 모델에는 다음 세 가지 정보가 함께 전달된다. - 차트 스크린샷: 사용자가 실제로 보는 시각적 맥락 파악 - Radar API의 원시 데이터: 숫자를 픽셀에서 추정하지 않고 정확하게 인용 - 현재 화면의 위치, 날짜 범위, 필터 등 조회 조건 - 따라서 일반적인 차트 설명이 아니라 사용자가 선택한 국가·기간·필터에 정확히 맞춘 분석을 제공한다. ## 사례: 포르투갈의 인터넷 품질 분석 - 사용자는 “포르투갈의 가정용 인터넷 품질은 어떤가?”처럼 자연어로 질문할 수 있다. - Researcher가 인터넷 품질 API를 조회하고 결과를 분석한 뒤, 수치 나열 대신 인터랙티브 차트로 답변한다. - 이후 포르투갈과 인접 국가를 비교하거나, 포르투갈에서 가장 흔한 인터넷 장애를 확인하는 식으로 후속 분석을 이어갈 수 있다. - API 호출 방식이나 파라미터를 직접 알지 않아도 국가별·주제별 비교가 가능하다. ## 사례: 이란 인터넷 셧다운 조사 - 2026년 이란에서 발생한 정부 주도 인터넷 차단 사례를 조사할 때 여러 트래픽 차트와 장애 기록을 직접 찾아 비교할 필요가 없다. - Researcher는 이란의 Cloudflare Radar 장애 이벤트와 관련 HTTP 트래픽 데이터를 함께 조회한다. - 분석 결과를 다음과 같은 타임라인으로 설명한다. - 1월 7일 HTTP 트래픽 지수가 약 0.58에서 시작 - 1월 9일까지 사실상 0으로 하락 - 1월 17일경 부분 회복 시작 - 1월 27일경 셧다운 이전 수준에 근접 - 2월 28일 시작된 두 번째 셧다운도 장애 표에 표시 - 장애 기간은 트래픽 차트 위에 직접 표시되며, 관련 장애 이벤트는 표 형태로 함께 제공된다. - 이후 주변 국가와의 트래픽 비교 같은 추가 조사도 제안한다. ## Cloudflare 개발자 플랫폼으로 구축 - Radar Researcher는 Cloudflare의 자체 개발자 플랫폼 위에서 구현되었다. - 핵심 구성은 다음과 같다. - Cloudflare Worker - Cloudflare Agents SDK - 대화별 상태를 유지하는 Durable Objects - 각 대화의 기록·제목·스트리밍 응답을 저장하는 SQLite 데이터베이스 - Workers AI 기반의 오픈 모델 - 사용자가 페이지를 떠나도 서버에서 응답 생성이 계속되고, 다시 접속하면 결과를 이어받을 수 있다. - 특정 모델이나 제공업체에 의존하지 않도록 세 가지 모델 계열을 순서대로 사용하는 fallback 체인을 구성했다. - 한 모델이 일시적으로 용량 부족 상태가 되면 다른 모델로 자동 전환해 서비스 중단 가능성을 줄인다. - 모든 AI 호출은 AI Gateway를 거친다. ## 실용적인 결론 Radar Researcher는 전문적인 데이터 탐색 과정을 자연어 인터페이스로 감싸, 기자·연구자·네트워크 운영자뿐 아니라 일반 사용자도 Cloudflare Radar의 공개 데이터를 쉽게 활용하게 해준다. 다만 AI의 해석을 그대로 받아들이기보다는 제공되는 API 데이터, 조회 조건, 분석 과정을 함께 확인하는 방식으로 사용하는 것이 적절하다.

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

대규모 언어 모델Cloudflare Workersdurable-objectssqlite+3

cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

Cloudflare가 AI를 활용해 엔지니어링 표준을 시행하는 방법

Cloudflare는 흩어져 있던 엔지니어링 지침을 통합·관리하는 표준 저장소인 **Cloudflare Codex**를 구축했다. Codex는 RFC 형식의 표준을 사람과 AI 에이전트가 작업 시점에 검색하고 적용할 수 있게 하며, 코드 리뷰·기술 설계 검토·사고 보고서 검토 등에 공통으로 활용된다. 도입 후 AI 코드 리뷰어는 약 23만 건의 위반을 발견했고, 그중 약 1만 6천 건의 병합을 차단했다. ## Codex가 필요했던 이유 - Cloudflare의 기존 지침은 공식 문서, 저장소 파일, 채팅 기록, 개인의 경험 등 여러 위치에 분산돼 있었다. - 개발자는 문제 해결보다 관련 지침을 찾는 데 많은 시간을 써야 했다. - 지침을 찾더라도 최신 정보인지, 권위 있는 기준인지, 현재 상황에 적용 가능한지 판단하기 어려웠다. - 조직이 커지면서 모든 표준을 읽고 모든 요구사항을 검토하는 것이 불가능해졌다. - 팀 이동이나 인력 변화로 조직의 지식이 유실되기 쉬웠고, 지침이 일관되게 노출·강제되지 않아 프로젝트 간 품질 편차가 발생했다. ## 도메인과 RFC 기반 거버넌스 - Codex는 아키텍처, 프런트엔드, 컨트롤 플레인, 보안, 신뢰성, TypeScript, Rust 등 여러 도메인으로 나뉜다. - 각 도메인에는 담당자가 있어 문서의 내용·일관성·품질을 관리한다. - 표준은 RFC 2119의 의미에 따라 `SHOULD`와 `MUST` 키워드를 사용한다. - `SHOULD`: 특별한 이유가 없다면 따라야 하는 권고 - `MUST`: 반드시 지켜야 하는 필수 요구사항 - RFC에는 도메인과 상태 같은 메타데이터를 담은 front matter가 포함된다. - 도메인 역량과 관심이 있는 직원은 정해진 형식의 merge request로 RFC를 제안할 수 있다. - 제안서는 점점 더 넓은 범위의 리뷰를 거치며, 도메인 담당자가 최종 승인하면 Codex에 편입되고 Astro 기반 내부 사이트에 게시된다. ## 승인과 강제를 분리한 표준 수명주기 - 승인된 RFC는 Codex 클라이언트와 에이전트가 즉시 읽고 코드·설정·문서의 위반을 탐지하는 데 사용할 수 있다. - 다만 승인 직후부터 병합을 차단하지는 않는다. - RFC가 `approved`에서 `enforced` 상태로 승격된 뒤에야 관련 요구사항이 차단 근거가 된다. - 이 단계 분리를 통해 팀이 새로운 요구사항을 받아들일 시간을 확보하고, 자동화나 예외 처리 등 강제에 필요한 준비도 마칠 수 있다. - 승인된 RFC의 위반은 일반적으로 비차단 권고로 처리되며, 강제 상태 RFC의 `MUST` 위반은 심각도에 따라 승인 보류 또는 병합 차단으로 이어진다. ## LLM을 위한 구조화와 점진적 공개 - 60개가 넘는 RFC 전체를 매번 LLM에 제공하면 컨텍스트 윈도우 부담이 커지고 결과 품질이 떨어질 수 있다. - 이를 해결하기 위해 별도의 에이전트가 RFC에서 `SHOULD`와 `MUST` 문장을 추출해 JSON 구조로 압축한다. - 각 표준 문장에는 다음 정보가 포함된다. - RFC 번호와 제목 - RFC 상태와 도메인 - 적용 수준(`SHOULD` 또는 `MUST`) - 문장이 속한 섹션 - 원문으로 연결되는 링크 - 안정적인 `slug` 식별자 - 에이전트는 우선 관련 표준 문장만 검색하고, 추가 설명이 필요할 때만 RFC 전체 내용을 불러온다. - 안정적인 slug는 RFC가 수정돼도 같은 요구사항을 추적할 수 있게 해 모니터링, 분석, 예외 처리에 활용된다. - 초기에는 간결한 Markdown을 사용했지만, 더 정확한 필터링을 위해 구조화된 JSON으로 전환했다. - 향후에는 설계·구현·런타임 등 소프트웨어 개발 생명주기 단계별 적용 범위도 메타데이터에 포함할 계획이다. ## AI 코드 리뷰 적용 - AI 코드 리뷰어는 merge request를 여러 기준으로 검사하며 Codex 준수 여부도 평가한다. - 리뷰마다 관련 RFC와 추출된 표준 문장을 검색하고, 필요한 경우에만 RFC 본문을 추가로 읽는다. - 대부분의 위반은 압축된 표준 문장만으로도 문제와 근거를 설명할 수 있다. - Codex 도입 이후 약 23만 건의 위반을 발견했다. - 이 중 약 1만 6천 건은 강제 상태 RFC의 `MUST` 요구사항 위반으로 승인 보류를 발생시켰다. ## AI 리뷰를 보완하는 빠른 린터 - AI 리뷰는 코디네이터와 여러 하위 에이전트를 실행하므로 보통 수 분이 걸린다. - 수정 후 다시 리뷰를 받아야 하는 추가 왕복과 대기 시간이 개발자 경험을 저하시킬 수 있다. - Cloudflare는 기계적으로 검증 가능한 언어별 요구사항을 별도 린터 설정 패키지로 제공하는 방식을 마련했다. - 이 린터는 Codex 표준과 정렬되며 문제를 밀리초 단위로 표시할 수 있다. - TypeScript가 첫 번째 대상 언어였고, 동시에 `oxlint`를 표준화하는 방향으로 진행됐다. ## 여러 엔지니어링 단계로의 확장 - Codex는 코드 리뷰에만 한정되지 않는다. - 기술 설계가 구현되기 전에 표준을 검토하는 spec reviewer가 이미 약 600개의 설계를 평가했다. - incident report reviewer 등 사고 분석과 운영 프로세스에도 같은 기준을 적용할 수 있다. - 하나의 관리된 표준 원천을 여러 에이전트가 공유함으로써 설계부터 구현, 운영까지 일관된 엔지니어링 기준을 적용할 수 있다. 새로운 표준은 먼저 `approved` 상태로 도입해 팀의 적응과 자동화 준비 시간을 확보한 뒤, 충분히 검증되면 `enforced`로 승격하는 방식이 실용적이다. 또한 LLM에는 전체 문서를 무작정 제공하기보다, 안정적인 식별자와 메타데이터를 갖춘 핵심 규칙을 먼저 검색하게 하고 필요할 때만 원문을 공개하는 구조가 효과적이다.

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

대규모 언어 모델TypeScriptRustastro+4

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

GEM 트레이닝: Meta가 LLM 규모의 광고 파운데이션 모델 효율성을 두 배로 높인 방법

Meta의 GEM은 Instagram과 Facebook 광고 추천을 담당하는 기반 모델로, 최신 GPU 수천 장을 활용해 LLM 규모로 학습된다. Meta는 추천 시스템에 특화된 커널·초저정밀도·병렬화·네트워크·메모리를 함께 설계해 12개월 동안 학습 FLOPs를 4배 늘리면서 E2E 학습 효율을 20~25% MFU까지, 기존 대비 2배 향상했다. 핵심 결론은 LLM용 인프라를 그대로 적용하는 것만으로는 부족하며, 추천 모델의 데이터와 구조에 맞춘 하드웨어·소프트웨어 공동 설계가 필요하다는 것이다. ## GEM의 하이브리드 구조와 추천 데이터의 특성 - GEM은 Meta 광고 시스템의 중앙 추천 파운데이션 모델이다. - 수조 개의 희소 임베딩 파라미터와 수십억 개의 밀집 파라미터를 함께 사용한다. - 입력 데이터는 크게 두 종류다. - **시퀀스 특징**: 사용자의 활동 이력처럼 순서가 있는 데이터 - **비시퀀스 특징**: 사용자 위치, 광고 크리에이티브 표현 등 - 각 특징 그룹에는 별도의 어텐션 메커니즘을 적용하면서도, 서로 다른 특징 간 상호작용을 학습한다. - 이처럼 LLM과 추천 시스템의 구조가 결합되어 있어 일반적인 LLM 학습보다 GPU 활용과 분산 확장이 어렵다. ## 추천 모델에서 높은 GPU 활용률이 어려운 이유 - **가변적인 시퀀스 길이** - 사용자 활동 이력의 길이가 샘플마다 크게 다르다. - 모든 입력을 최대 길이에 맞춰 패딩하면 최대 50%의 연산이 낭비될 수 있다. - **비대칭적인 어텐션 형태** - 긴 활동 이력에 대해 긴 시퀀스와 짧은 어텐션 윈도우를 사용하는 self-attention - 긴 쿼리와 짧은 key/value를 사용하는 사용자-광고 cross-attention - 사용자 이력을 압축해 짧은 쿼리와 긴 key/value를 만드는 PMA - 이런 다양한 행렬 형태는 GPU 내부 파이프라이닝과 연산 유닛 포화를 어렵게 만든다. - **메모리 대역폭 중심 연산** - 작은 임베딩 차원의 MLP와 여러 정규화 연산은 계산량보다 메모리 접근의 영향을 크게 받는다. - 따라서 Tensor Core 등 GPU 연산 자원이 충분히 활용되지 않을 수 있다. - **정밀도 변화에 대한 민감성** - CTR·CVR 예측은 수치 변화에 민감하다. - 단순히 낮은 정밀도를 적용하면 모델 품질이 저하될 수 있어, 연산별로 정밀도를 신중하게 선택해야 한다. ## 수천 개 GPU로 확장할 때의 병목 - GEM의 학습 단계 지연 시간은 다음과 같이 결정된다. `E2E 지연 시간 = 각 GPU rank에서의 max(로컬 연산 시간, 통신 시간)` - 선형에 가까운 확장을 위해서는 다음 조건이 필요하다. - 전체 연산 시간이 통신 시간보다 충분히 커야 한다. - 통신을 연산 뒤에 숨기되 두 작업이 자원을 놓고 경쟁하지 않아야 한다. - 메모리 부족으로 인한 activation recomputation을 최소화해야 한다. - GPU rank 간 부하가 균등해야 한다. - GEM에서는 다음 문제가 이를 방해한다. - 수조 개 희소 파라미터와 수십억 개 밀집 파라미터가 큰 통신량을 만든다. - 레이어별 구조가 달라 연산과 통신을 겹칠 수 있는 시간이 일정하지 않다. - 긴 시퀀스와 큰 activation 때문에 메모리가 부족해 재계산이 발생한다. - 가변 시퀀스 길이로 인해 GPU마다 처리량이 달라지는 부하 불균형과 straggler가 생긴다. ## E2E MFU를 연산 효율과 확장 효율로 분해 - 전체 학습 효율은 다음 두 요소의 곱으로 정의한다. `E2E MFU = Local MFU × Scaling Ratio` - **Local MFU** - 단일 GPU의 연산 유닛을 얼마나 잘 활용하는지를 나타낸다. - 커널 설계, 수치 정밀도, 시퀀스 길이와 데이터 차원이 GPU 구조에 얼마나 잘 맞는지에 좌우된다. - **Scaling Ratio** - 단일 GPU 성능이 수천 개 GPU로 확장된 뒤 얼마나 유지되는지를 의미한다. - 1.0이면 완전한 선형 확장이지만, 실제로는 통신 오버헤드·부하 불균형·straggler·activation 재계산 때문에 낮아진다. - Meta는 레이어를 단일 GPU에서 개별 실행해 Local MFU를 측정하고, 통신과 activation 재계산의 영향을 제외한 기준 성능을 산출했다. - 이후 Local MFU와 E2E MFU의 비율을 통해 Scaling Ratio를 계산해 연산 병목과 분산 시스템 병목을 분리했다. ## GPU 연산 효율을 높인 맞춤형 커널과 정밀도 - 추천 모델의 비정형적인 입력과 어텐션 패턴에 맞춰 자체 추천용 커널 라이브러리를 개발했다. - 주요 커널은 다음과 같다. - **Jagged Flash Attention(JFA)**: 가변 길이 시퀀스를 패딩 낭비 없이 처리 - **Generalized Dot-Product Attention(GDPA)**: 추천 모델의 다양한 어텐션 형태에 대응 - **BlockAttention**: 블록 단위 연산으로 메모리 접근과 GPU 활용을 최적화 - 최신 GPU 아키텍처를 직접 활용하도록 커널을 설계해 추천 워크로드의 낮은 활용률을 개선했다. - 어텐션과 MLP에는 **MXFP8**을 포함한 혼합 초저정밀도 학습을 적용했다. - 모든 연산을 무조건 낮은 정밀도로 처리하지 않고, 광고 예측 품질에 민감한 특성을 고려해 연산별로 정밀도와 안정성을 조정했다. ## 네트워크와 결합한 5차원 병렬화 - 대규모 학습에서는 병렬화 방식 자체뿐 아니라 GPU와 네트워크 토폴로지의 매핑이 중요하다. - GEM은 네트워크 계층 구조를 고려한 **토폴로지 인지형 5D 병렬화**를 적용했다. - 밀집 파라미터에는 다음 조합을 사용했다. - 2D FSDP - Expert Parallelism - 희소 파라미터에는 **Fully Sharded 2D Model Parallelism**을 적용했다. - 통신 집단 연산은 GPU의 Streaming Multiprocessor(SM)를 점유하지 않는 방식으로 설계했다. - 통신이 연산 자원을 직접 빼앗지 않도록 해 연산과 통신의 충돌을 줄인다. - Meta의 다계층 네트워크 구조와 병렬화 전략을 함께 설계해 통신량과 통신 노출 시간을 줄였다. ## 성과와 설계 원칙 - 12개월 동안 총 학습 FLOPs를 4배로 확대했다. - 동시에 E2E 학습 효율을 2배 높여 20~25% MFU를 달성했다. - 성능 개선은 단일 기법이 아니라 다음 요소들의 결합으로 이루어졌다. - 추천 특화 커널 - 혼합 초저정밀도 - 희소·밀집 파라미터별 병렬화 - 네트워크 토폴로지 최적화 - SM 비점유 통신 - 메모리와 부하 균형 관리 추천 모델을 LLM 규모로 확장하려면 LLM 인프라를 그대로 복사하기보다, 가변 길이·희소 임베딩·비대칭 어텐션·정밀도 민감성 같은 도메인 특성을 먼저 분석해야 한다. 특히 단일 GPU의 커널 효율과 수천 GPU의 통신·메모리 효율을 별도의 문제로 측정하고 동시에 최적화하는 접근이 효과적이다.

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

대규모 언어 모델recommendation-systemsdistributed-traininggpu-optimization+3

figma·2026년 7월 31일·3분 읽기큐레이션 요약

AI 숙련도는 최종 목표가 아니다 | Figma 블로그

AI 도구를 잘 다루는 능력은 중요하지만, 그것만으로는 AI 시대의 성공을 보장할 수 없다. 더 중요한 역량은 개인의 생산성 향상을 팀 전체의 속도로 확장하고, 다양한 의견을 모아 결정을 내리며, 실험과 실패를 안전하게 공유하는 협업 능력이다. 결국 AI의 가치는 한 사람이 10배 빠르게 일하는 데보다 팀 전체가 함께 더 빠르고 현명하게 움직이는 데 있다. ## AI 활용 능력 이상의 역량 - 제품 개발자 90% 이상이 AI 활용 능력을 미래의 성공에 필수적이라고 답했다. - AI 도구 숙련도는 채용, 업무 속도, 자신감 향상에 직접적인 도움을 준다. - 그러나 AI가 업무 방식을 바꿀수록 다음과 같은 역량의 중요성이 더 커진다. - 팀이 함께 사용할 수 있는 시스템 구축 - 적절한 사람들과 아이디어를 주고받는 능력 - 공동의 목표를 향해 협력하는 능력 ## 내부 제품 빌더가 되기 - AI 도구를 개인용으로만 사용하지 말고, 팀 전체가 활용할 수 있는 내부 도구로 전환해야 한다. - 예시는 다음과 같다. - 프로토타이핑 에이전트 - 브랜드 플러그인 - 공유 프롬프트 라이브러리 - 누구나 사용할 수 있는 프로토타이핑 도구 - Figma 연구팀은 AI를 활용해 설문 데이터를 탐색할 수 있는 인터랙티브 웹사이트를 만들었다. - 데이터와 맥락이 개인의 컴퓨터나 머릿속에만 머무르지 않게 했다. - AI를 개인 생산성 도구가 아니라 팀의 협업 역량을 확장하는 수단으로 활용했다. - Figma Brand Studio는 Figma Make로 이미지 효과 생성기를 제작했다. - 팀원이 사진이나 디자인에 브랜드에 맞는 질감을 클릭 한 번으로 적용할 수 있었다. - 핵심은 팀의 업무에서 반복되거나 막히는 지점을 발견하고, AI로 마찰을 줄이는 것이다. - 한 사람이 10배 빠르게 일하는 것보다 팀 전체가 함께 10배 빠르게 움직이는 편이 더 큰 효과를 낸다. ## 수많은 선택지에서 결정으로 이끌기 - AI는 짧은 시간에 수십 개의 방향과 결과물을 만들어내므로, 생성 자체보다 선택과 의사결정이 어려워진다. - 효과적인 의사결정을 위해서는 프로젝트 책임자뿐 아니라 다음 사람들을 참여시켜야 한다. - 반대 의견이나 새로운 관점을 가진 사람 - 과거의 맥락과 조직의 경험을 아는 사람 - 잠재적 위험을 발견할 수 있는 전문가 - 한 팀이 AI로 내부 앱을 빠르게 만들었지만, 직원들이 접근해서는 안 되는 회사 프로젝트 정보가 노출되는 문제가 발생했다. - 데이터 거버넌스 전문가를 초기 단계부터 참여시켰다면 예방할 수 있었던 사례다. - 회의 전에 이해하기 쉬운 선택지를 제공해야 한다. - 프로토타입의 각 흐름을 설명하는 Loom 영상 - 방향별 동작을 보여주는 주석이 달린 FigJam 파일 - 회의에서는 단순한 설명보다 트레이드오프를 비교하고 결정을 내리는 데 집중해야 한다. - 발언하지 않은 사람의 의견을 요청한다. - 모호한 추천은 구체적으로 되묻는다. - 논의를 진전시키는 질문을 한다. - 회의가 끝나기 전에 결정사항과 다음 단계를 확인한다. ## 나쁜 아이디어도 공유하기 - AI 활용 속도는 개인과 조직 사이에서 서로 다르게 나타난다. - 20%는 개인 기여자가 조직의 지원 없이 앞서가고 있다고 답했다. - 27%는 리더십이 AI 도입을 밀어붙이지만 팀이 따라가기 어려워한다고 답했다. - 팀원마다 AI를 접한 시점과 숙련도가 달라, 방치하면 역량 격차가 계속 커질 수 있다. - 앞선 사람만 계속 실험하면 다른 구성원은 AI 활용법을 배우기보다 뒤처지는 상황에 놓인다. - 따라서 아직 다듬어지지 않은 아이디어나 실패한 시도도 공유할 수 있는 환경이 필요하다. - 실험 결과를 공개적으로 나누면 개인의 경험이 팀의 학습 자산이 되고, AI 도입 속도 차이를 줄일 수 있다. AI 도구를 배우는 데 그치지 말고, 팀이 함께 사용할 수 있는 도구와 프로세스를 만들고, 다양한 이해관계자를 참여시켜 의사결정을 구조화하는 것이 좋다. 또한 완성된 결과만 공유하기보다 실패와 미숙한 아이디어까지 안전하게 나누는 문화를 구축해야 AI의 효과를 조직 전체로 확장할 수 있다.

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

대규모 언어 모델AI프로토타이핑figma-make+2

netflix·2026년 7월 30일·5분 읽기큐레이션 요약

GenRec: 넷플릭스에서 LLM 네이티브 추천을 향하여

Netflix의 GenRec은 사용자 이력과 콘텐츠 메타데이터를 자연어로 표현하고, Netflix에 맞게 후처리 학습한 LLM을 추천 랭커로 활용하는 시스템이다. 기존의 대규모 수작업 피처와 특화 아키텍처 의존도를 줄이면서도, 카탈로그 인식 점수 헤드와 보상 신호를 통해 개인화·장기 사용자 가치·비즈니스 제약을 반영한다. 대규모 A/B 테스트에서 기존 랭커보다 단기 및 장기 지표를 유의미하게 개선했으며, 더 적은 라벨 데이터와 입력 신호만으로도 경쟁력 있는 성능을 보였다. ## 기존 추천 시스템의 복잡성과 LLM의 가능성 - Netflix의 기존 모델은 사용자·아이템·상호작용에 대한 수천 개의 수작업 피처를 사용한다. - 시퀀스 모델링, 피처 상호작용, 멀티태스크 학습 등 다양한 특화 구조가 콘텐츠 유형과 제품 화면별로 구축되어 있다. - 새로운 콘텐츠 유형이나 추천 화면을 추가하려면 피처 설계, 모델 구조, 인프라, 실험을 함께 변경해야 한다. - LLM은 사용자 이력과 아이템 정보를 텍스트로 통합하고, 자연어 기반의 의미 관계와 추천 조건을 표현할 수 있다. - 하지만 일반 LLM은 인기 콘텐츠 편향, 카탈로그에 없는 아이템 생성, 비즈니스 제약 무시, 부족한 개인화 등의 문제가 있다. ## GenRec의 추천 문제 정의 - 사용자 \(u\), 컨텍스트 \(\tau\), 시간 \(t\), 상호작용 이력 \(H\)를 입력으로 받아 Netflix 전체 카탈로그 \(C\)의 순위 \(\pi\)를 생성한다. - 컨텍스트에는 기기, 화면, 지역, 시간 등이 포함된다. - 후보군이 주어지면 Top-K 순위를 만들고, 후보군이 없으면 전체 카탈로그를 대상으로 순위를 계산한다. - 단순 클릭이나 재생 수가 아니라 만족도와 유지율을 대변하는 장기적 회원 효용을 최적화한다. ## 2단계 학습 구조 ### Netflix 맞춤형 기반 LLM - 오픈소스 LLM을 Netflix의 독점 데이터로 적응시킨다. - Netflix 콘텐츠 이해, 회원 행동과 선호 패턴, 일반적인 언어 이해 능력을 학습한다. - 여러 애플리케이션이 공유하는 Netflix 인식 기반 모델로 사용된다. - 콘텐츠 변화에 맞춰 자주 갱신하기보다는 비교적 드물게 업데이트된다. ### GenRec 후처리 학습 - 기반 LLM을 추천 순위화와 제어에 특화된 모델로 전환한다. - 랭킹 데이터와 복수의 보상 신호를 사용한다. - 새로운 콘텐츠와 변화하는 취향을 반영하기 위해 더 자주 갱신한다. - Netflix의 LLM 서빙 비용과 지연시간을 고려해 최적화한다. ## 상호작용 로그를 대화 데이터로 변환 - Netflix의 조회, 재생 시간, 좋아요·싫어요, 찜하기, 중단 등 방대한 이벤트를 추천 대화 형식으로 변환한다. - 사용자 메시지에는 다음 정보가 포함된다. - 현재 화면과 기기 같은 컨텍스트 - 사용자 프로필과 과거 이력 - 아이템 메타데이터 - “다음에 시청하거나 좋아요를 누를 콘텐츠를 추천하라”와 같은 과제 - 어시스턴트 메시지에는 실제 회원 행동이 기록된다. - 어떤 콘텐츠를 재생했는지 - 얼마나 오래 시청했는지 - 어떤 피드백을 남겼는지 - 학습 시에는 언어 모델링과 추천 랭킹을 함께 지원하지만, 추론 시에는 답변 텍스트를 생성하지 않는다. - 실제 서비스에서는 verbalized context를 입력하고, 별도의 카탈로그 인식 점수 헤드로 콘텐츠를 정렬한다. ## 피처 엔지니어링에서 컨텍스트 엔지니어링으로 - 기존 추천 시스템이 밀집 벡터와 수작업 피처를 중심으로 한다면, GenRec은 이력과 상황을 자연어로 변환해 LLM의 의미 공간에 입력한다. - 모델이 아이템 간 관계, 반복 시청, 변화하는 관심사 같은 고차원 패턴을 직접 학습하도록 한다. - 모든 상호작용을 그대로 입력하면 토큰 한도와 비용 문제가 발생하므로, 컨텍스트를 선별하고 압축한다. - 긴 재생이나 긍정 피드백처럼 신호가 강한 이벤트는 자세히 유지 - 짧은 재생이나 빠른 탐색처럼 신호가 약한 이벤트는 제거 - 폭주 시청처럼 반복적인 행동은 요약 - 신작이나 콜드스타트 아이템은 필요한 경우 더 자세히 설명 - 제한된 토큰 예산 안에서 최근성과 신호 강도가 높은 이력을 우선한다. - 프롬프트의 공통 접두사를 늘려 prefix caching을 활용하고, 서빙 비용을 낮춘다. - 결과적으로 모델 개발의 초점이 개별 피처 제작에서 정보 밀도 높은 입력 문맥 설계로 이동한다. ## 랭킹·언어·보상 신호를 결합한 학습 ### 카탈로그 인식 랭킹 목표 - 충분히 긴 재생이나 강한 명시적 피드백처럼 가치가 높은 참여를 긍정 샘플로 사용한다. - 임계값과 노이즈 제거 로직으로 부정확한 행동 신호를 정제한다. - 전체 카탈로그 또는 후보군에 대한 cross-entropy 손실을 사용해 긍정 아이템의 점수를 높인다. - 자유로운 텍스트 생성이 아니라 실제 Netflix 카탈로그 안에서 점수를 계산하므로, 존재하지 않는 콘텐츠를 추천하는 문제를 줄인다. ### 언어 모델링 목표 - 입력과 출력의 텍스트에 대해 언어 모델링 목표를 유지한다. - 자연어로 표현된 사용자 이력과 콘텐츠 메타데이터를 이해하는 능력을 보존한다. - 향후 추천 이유나 설명 생성과 같은 텍스트 기반 기능으로 확장할 가능성도 유지한다. ### 보상 기반 정렬 - 단기 클릭이나 재생만 최적화하지 않고 장기적인 회원 만족도를 반영한다. - 영화, 시리즈, 게임, 라이브, 팟캐스트 등 콘텐츠 유형 간 균형 같은 비즈니스 요구사항을 고려한다. - 여러 보상 신호를 보상 가중 손실에 반영해 랭킹 결과가 Netflix의 장기 목표와 맞도록 조정한다. ## 서빙 효율성과 성능 - GenRec은 Netflix의 LLM 서빙 스택에서 prefill-only 방식으로 실행된다. - 추론 시 토큰을 생성하지 않고 입력을 처리해 아이템별 점수를 계산하므로 생성형 LLM보다 비용 효율적이다. - 기존의 성숙한 프로덕션 랭커와 비교한 대규모 A/B 테스트에서 단기 및 장기 온라인 지표를 모두 통계적으로 개선했다. - Phase 2 학습에 필요한 라벨 데이터와 입력 신호도 기존 시스템의 일부만 사용했다. 실무적으로는 LLM을 추천 시스템에 도입할 때 모든 로그를 무작정 텍스트화하기보다, 카탈로그 제약을 보장하는 점수 헤드, 장기 보상 설계, 토큰 예산 관리, 캐싱 전략을 함께 설계하는 것이 중요하다. GenRec의 사례는 추천 모델의 성능뿐 아니라 피처 유지보수 비용과 새로운 추천 시나리오의 확장성까지 고려할 때 LLM 기반 구조가 유효할 수 있음을 보여준다.

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

대규모 언어 모델자연어 처리recommendation-systemsreinforcement-learning+2

google·2026년 7월 30일·4분 읽기큐레이션 요약

Science One 프레임워크: 증거 사슬을 통한 검증 가능한 자율 연구 프레임워크

Science One Framework는 AI가 생성한 연구 결과의 모든 주장에 실제 근거를 연결하는 Chain-of-Evidence(CoE) 방식으로 환각과 재현성 문제를 줄이는 자율 연구 프레임워크다. 문헌 검색, 실험 탐색, 논문 작성 전 과정에서 증거 사슬을 구축하고, CoE Audit로 인용·점수·코드·방법의 일치 여부를 독립 검증한다. 실험 결과, 기존 시스템의 참고문헌 환각률이 최대 21%에 달한 반면 Science One Framework는 유령 참고문헌 없이 높은 재현성과 성능을 달성했다. ## 자율 연구 시스템에서 검증 가능성이 중요한 이유 - LLM 기반 연구 에이전트는 문헌 조사, 가설 수립, 실험 실행, 논문 작성까지 자동화하고 있다. - 그러나 생성 과정에서 발생한 오류가 다음 단계로 누적·증폭될 수 있다. - 대표적인 문제는 다음과 같다. - 존재하지 않는 논문을 참고문헌으로 생성 - 논문에 설명한 방법과 실제 실행 코드가 불일치 - 논문에 보고된 실험 점수가 코드를 다시 실행했을 때 재현되지 않음 - 따라서 논문의 문장 품질만이 아니라, 각 주장과 근거 사이의 연결을 검증해야 한다. ## Chain-of-Evidence(CoE)의 원칙 - CoE는 데이터베이스 트랜잭션의 ACID처럼 신뢰할 수 있는 연구 산출물이 갖춰야 할 속성을 정의하는 개념적 프레임워크다. - 핵심은 두 가지다. - **완전성**: 연구 산출물의 모든 주장에 기록된 증거 사슬이 있어야 한다. - **정확성**: 연결된 증거가 실제로 해당 주장을 뒷받침해야 한다. - 검증 대상이 되는 주장은 다음과 같다. - 참고문헌의 존재 여부 - 논문에 보고된 실험 수치 - 연구 방법 설명 - 최종 결론 - 증거는 학술 논문, 실험 로그, 실제 실행된 코드, 결과 테이블 등으로 연결된다. - 존재하지 않는 참고문헌, 재현되지 않는 점수, 코드와 다른 방법 설명은 모두 증거 사슬이 끊어진 사례다. ## 문헌을 근거로 고정하는 Problem Investigator - Semantic Scholar API를 사용해 주제별 인용 그래프를 구축한다. - 최대 100개의 전문 PDF를 읽어 구조화된 연구 브리프를 만든다. - 최종 논문의 참고문헌은 모델의 기억에서 생성하지 않고, API를 통해 실제로 검색·확인된 자료에서 가져온다. - 이 방식으로 존재하지 않는 참고문헌이 논문에 포함되는 문제를 방지한다. ## 병렬 탐색을 수행하는 Discovery Engine - 여러 탐색 브랜치를 병렬로 운영해 새로운 아이디어를 탐색하고 성능이 좋은 아이디어를 개선한다. - 각 독립 사이클에서 다음 작업이 수행된다. - Solver 에이전트가 해결책을 구현 - 문제별 evaluator가 결과를 평가 - 성능이 높은 브랜치를 반복적으로 개선 - 모든 evaluator의 원시 출력은 엄격한 읽기 전용 기록으로 저장된다. - 따라서 논문에 기재된 점수를 실제 평가 결과와 대조할 수 있다. ## 주장과 근거를 연결하는 Paper Writer와 Claim Verifier - 논문을 렌더링하기 전에 모든 사실 주장을 구조화하고, 각 주장에 인라인 증거 태그를 붙인다. - 증거 태그는 해당 주장을 뒷받침하는 특정 작업 공간 산출물에 연결된다. - Claim Verifier는 각 주장을 선언된 출처와 대조한다. - 주장이 근거보다 과장된 경우 삭제하기보다 근거가 뒷받침하는 수준으로 보수적으로 다시 작성한다. - 이를 통해 논문 내용이 실제 수행된 연구와 일치하도록 유지한다. ## CoE Audit의 네 가지 검증 CoE Audit는 생성된 논문, 코드, 해결책, 참고문헌을 대상으로 수행하는 사후 자동 감사 프로토콜이다. - **점수 검증** - 논문에서 보고된 점수를 추출한다. - 제출된 코드를 완전히 독립적으로 다시 실행해 결과를 비교한다. - **명세 위반 검사** - 코드가 실제 문제를 해결하는지 확인한다. - 평가 지표를 악용하거나 정답 파일을 직접 읽는 등의 부정한 구현을 검사한다. - **참고문헌 검증** - 모든 참고문헌을 학술 API와 대조한다. - 존재하지 않는 유령 참고문헌을 식별한다. - **방법-코드 정렬 검사** - LLM 심사자가 논문의 방법론 설명과 코드를 나란히 비교한다. - 논문이 실제 구현보다 복잡하거나 다른 알고리즘을 설명하는지 확인한다. ## 실험 결과 - ADRS 벤치마크의 5개 시스템 최적화 과제(Prism, Cloudcast, EPLB, LLM-SQL, transaction scheduling)에서 5개 시스템이 생성한 총 75편의 논문을 평가했다. - Science One Framework는 네 가지 무결성 검사 모두에서 기존 기준 시스템보다 우수했다. - 참고문헌 환각률은 0%였다. - 반면 기존 시스템에서는 최대 21%의 참고문헌이 존재하지 않았다. - 제출 코드의 독립 재실행을 통한 점수 검증에서 완벽한 결과를 보였다. - 방법 설명과 실제 코드의 일치도 역시 가장 높았다. - 일부 기준 시스템은 실제 코드가 단순한 결정론적 휴리스틱임에도 “하이브리드 뉴로-심볼릭 솔버”처럼 과장된 방법을 기술했다. - 검증 절차를 강화했음에도 연구 성능이 저하되지 않았다. - 5개 ADRS 과제에서 인간 전문가 수준 이상을 기록했다. - Cloudcast와 EPLB에서는 전체 시스템 중 최고 성능을 달성했다. - 외부 일반화 평가에서도 MLE-Bench의 의료 영상, 세밀한 이미지 인식, 3D 인식 관련 대회에 적용되었으며, 일부 과제에서 Gold Medal 성과를 기록했다. ## 실용적인 시사점 자율 연구 시스템은 논문을 완성한 뒤 사실을 확인하는 방식보다, 문헌·코드·실험 로그·결과를 생성 시점부터 연결하는 구조가 바람직하다. 특히 자동화된 연구 결과를 실제 의사결정이나 후속 연구에 사용하려면, 논문 자체뿐 아니라 독립적인 코드 재실행, 참고문헌 확인, 방법-코드 비교를 포함한 CoE Audit 같은 검증 절차를 함께 운영해야 한다.

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

대규모 언어 모델머신러닝autonomous-agentssemantic-scholar-api+3

toss·2026년 7월 30일·5분 읽기큐레이션 요약

LLM은 똑똑한데, 왜 우리 회사 일은 모를까

LLM이 사내 질문에 정확히 답하려면 단순히 관련 문서를 검색하는 것만으로는 부족하다. 문서·코드·메신저의 최신성, 상충 여부, 실제 구현과의 일치 여부까지 관리하는 신뢰 가능한 컨텍스트 계층이 필요하며, Topic은 이를 구축하기 위한 시스템이다. Topic은 원본을 의미 단위로 정규화하고, 개념과 관계를 연결한 뒤, 변경된 부분만 선택적으로 검증한다. ## 검색만으로는 신뢰를 보장할 수 없는 이유 - 검색은 질문과 관련된 텍스트를 찾아줄 뿐, 해당 정보가 최종 결정인지 판단하지 못한다. - 문서, 미팅, 코드가 서로 다른 정책을 설명할 수 있다. - 메신저 논의가 실제 결론인지, 문서가 오래된 것인지, 코드 변경이 의도된 것인지 추가 판단이 필요하다. - 에이전트가 각자 원문을 검색하면 자료 선택과 충돌 해석이 달라져 답변 일관성이 떨어진다. - Topic은 출처, 관계, 최신성, 충돌 상태를 공통 계층에서 관리해 사람과 LLM이 같은 근거를 사용하도록 한다. ## 신뢰를 구성하는 여섯 가지 축 - **Granularity**: 독립적으로 관리할 수 있는 적절한 크기와 의미의 컨텍스트인지 판단한다. - **Faithfulness**: 컨텍스트의 주장이나 설명이 원문 근거로 뒷받침되는지 확인한다. - **Staleness**: 정보가 현재도 유효한지 검사한다. - **Canonicality**: 서로 다른 이름이나 표현이 같은 대상을 가리키는지 판단한다. - **Consistency**: 여러 출처의 내용이 서로 양립하는지 확인한다. - **Coverage**: 중요한 근거와 관점이 누락되지 않았는지 살핀다. - 모든 문제를 하나의 신뢰도 점수로 합치지 않고, 규칙·LLM·사람 검토를 각각 적합한 판단에 사용한다. ## Ingest: 출처별 의미 단위를 보존한 정규화 Topic은 문서·코드·메신저의 원본을 공통 `ContentUnit`으로 변환한다. - 주요 필드: - `source_type`: document, code, messenger - `unit_type`: 문서 섹션, 메신저 스레드 등 - `source_uri`: 원문으로 돌아가는 주소 - `content_hash`: 변경 감지용 해시 - `created_at_src`, `updated_at_src` - 출처별 식별자와 구조를 담은 `metadata` - 공통 형식은 후속 추출·검증을 일관되게 만든다. - 출처별 구조는 의미 경계와 증거의 원천을 보존하기 위해 유지한다. ### 문서는 제목 계층 단위로 분할 - Markdown 문서를 고정 길이가 아니라 제목 구조에 따라 나눈다. - 상위 제목 경로를 함께 저장해 문장이 어떤 정책이나 기능에 속하는지 보존한다. - 섹션이 지나치게 긴 경우에만 추가 분할한다. - 문서 경로, 원문 URL, 작성·수정 시각도 검증 정보로 남긴다. ### 메신저는 개별 메시지보다 스레드 단위로 처리 - 메시지 하나만 보면 질문인지 결론인지 알기 어렵기 때문에 스레드 전체를 하나의 의미 단위로 삼는다. - 요약 시: - 함수명, 에러 클래스, 파일 경로 등 기술 식별자를 원문 그대로 보존한다. - 질문, 검토한 선택지, 최종 결과를 구분한다. - 확정된 내용과 미결정 내용을 나눈다. - 대화에 없는 합의를 만들어내지 않는다. - 잡담만 있는 스레드는 컨텍스트로 만들지 않는다. ### 코드는 심볼과 비즈니스 동작을 함께 표현 - 파서로 함수·클래스 등 코드 심볼을 추출한다. - 파일 경로, 심볼 종류, 시작·종료 줄, import 관계는 규칙 기반으로 수집한다. - 여러 심볼을 가로지르는 업무 동작은 `CodeSemanticCard`로 묶는다. - semantic card에는 다음 정보가 포함된다. - 업무 대상과 실제 동작 - 도메인 용어와 코드 식별자 - 저장소·파일·줄·심볼 단위의 근거 span - 기준이 된 `commit_sha` - LLM이 만든 카드는 파일·줄이 실제 존재하는지, 설명을 뒷받침하는 span이 있는지 규칙 기반으로 재검사한다. - 최종 검증에서는 카드의 설명만 믿지 않고 현재 코드의 실제 span을 다시 읽는다. ## Extract: 개념과 관계를 원문 근거와 연결 - 각 `ContentUnit`에서 개념 후보와 이를 뒷받침하는 문장을 추출한다. - 함께 등장한 후보를 중심으로 관계를 제안하고, 표현·의미가 유사한 후보의 중복 가능성을 계산한다. - 충분한 근거가 있을 때만 대표 개념으로 통합한다. - 문서·메신저·코드처럼 출처가 다른 unit 사이에도 연결 후보를 만든다. - 개념과 관계에는 원문 위치, 인용, 판단 상태를 함께 저장한다. ### 사내 용어는 사람 검토를 포함 - 띄어쓰기·대소문자 차이는 정규화와 임베딩으로 자동 탐지할 수 있다. - 사내 약어와 별칭은 잘못 합치면 검색·검증 전체를 오염시킬 수 있다. - 애매한 동의어는 즉시 병합하지 않고 `Synonym Proposal`로 등록한다. - 사람이 승인한 별칭만 관리되는 관계로 반영하며, 거절된 후보는 반복 제안하지 않는다. ### 문서와 코드 관계를 유형별로 구분 - `supported_by`: 코드가 문서의 설명을 뒷받침한다. - `contradicted_by`: 코드와 문서의 동작이 충돌한다. - `mentions`: 같은 기능을 언급하지만 일치·충돌 여부를 판단할 근거가 부족하다. - 임베딩으로 후보를 제한한 뒤, 의미 판단이 필요한 후보만 배치 검증한다. - 관계에는 유형뿐 아니라 신뢰도, 판단 이유, 원문 인용, 검증 상태를 기록한다. - 검증 실패나 낮은 신뢰도는 관계를 저장하지 않는다. 관계가 없다는 것은 무관하다는 뜻이 아니라 아직 확인되지 않았다는 의미다. ## Verify: 변경된 부분만 선택적으로 재검증 - 각 unit의 안정적인 식별자와 `content_hash`를 이용해 변경 범위를 추적한다. - 변경되지 않은 unit의 추출·관계 결과는 재사용한다. - 새로 생성되거나 변경된 unit만 다시 처리한다. - 원본이 삭제되면 해당 원본을 참조하던 관계도 정리한다. - 코드 anchor에는 검증 당시의 commit과 span hash를 저장한다. - 현재 코드에서 anchor가 사라졌으면 orphaned 상태로 표시한다. - anchor의 span hash가 같으면 의미 검증을 생략한다. - span hash가 달라졌으면 변경된 코드에 대해 faithfulness를 다시 검증한다. - 해시와 참조 무결성은 규칙 기반으로 검사하고, 실제 의미가 달라진 경우에만 LLM을 호출한다. - 이 방식은 비용을 줄이면서도 변경 원인과 컨텍스트 상태 변화를 추적하게 해준다. ## 실용적인 결론 사내 LLM의 품질을 높이려면 검색 성능만 개선하기보다, 의미 단위·원문 근거·출처 간 관계·최신성·충돌 상태를 함께 관리해야 한다. 특히 자동화는 명확한 변경 감지와 관계 추출에 사용하고, 사내 용어 통합이나 중요한 정책 판단처럼 맥락 의존적인 문제는 근거를 제시한 뒤 사람의 승인을 받는 방식이 안전하다.

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

대규모 언어 모델human-in-the-loopsemantic-searchknowledge-graph+4

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

Copilot vs. 직접 API 접근: 실제로 무엇에 비용을 지불하고 있나요?

같은 AI 모델을 사용하더라도 GitHub Copilot과 원시 API는 서로 다른 계층의 문제를 해결한다. Copilot은 이슈부터 코드 수정, 테스트, 풀 리퀘스트와 조직 정책 적용까지 연결된 개발 워크플로를 제공하고, 원시 API는 프롬프트·검색·라우팅·보안·로그·과금 등을 직접 설계하는 시스템 구축용 기반이다. 따라서 비용과 선택 기준은 토큰 단가만이 아니라 팀이 직접 소유하고 운영해야 하는 작업의 범위에 따라 결정된다. ## GitHub Copilot은 모델을 둘러싼 개발 도구 - Copilot의 모델 호출은 개발 작업 전체 중 한 단계에 불과하다. - 일반적인 유지보수 작업에는 다음 요소가 함께 필요하다. - GitHub Issue 분석 - 저장소와 관련 파일 탐색 - 코드 수정 및 diff 생성 - 저장소 지침과 허용된 명령 반영 - 터미널에서 테스트 실행 - Pull Request 생성 및 리뷰 - 조직의 보안·사용 정책 적용 - Copilot은 에디터, 저장소, 이슈, PR, 터미널, 조직 관리 기능을 하나의 흐름으로 연결한다. - 유료 플랜에서는 코드 자동 완성과 Next Edit Suggestions가 계속 포함되며, 더 많은 리소스를 사용하는 채팅·에이전트 작업에는 AI Credits가 적용된다. - 실제 작업 비용은 모델의 토큰 단가 외에도 다음 요인에 영향을 받는다. - 선택된 컨텍스트의 양 - 도구 호출 횟수 - 실패에 따른 재시도 - 이슈에서 리뷰 완료 PR까지 이어지는 전체 작업 경로 - 조직 플랜은 AI Credits를 조직 단위로 공유하고, 관리자가 예산과 사용량을 대시보드에서 추적할 수 있다. ## 원시 API는 직접 소유하는 시스템을 위한 기반 - API 직접 호출은 다음과 같은 시스템을 만들 때 적합하다. - 제품 기능에 포함되는 AI 기능 - 사내 에이전트 플랫폼 - 모델 평가·벤치마크 도구 - 자동화 파이프라인 - 개발자가 직접 결정할 수 있는 항목이 많다. - 프롬프트 구성 - 문서 및 코드 검색 방식 - 모델 라우팅 - 실패한 도구 호출의 재시도 정책 - 로그와 추적 데이터 저장 - 인증 정보와 보안 경계 - 과금 및 사용량 관리 - 예를 들어 사내 에이전트가 특정 태그의 이슈를 읽고, 회사 문서를 검색하고, 별도 시스템에 변경 요청을 만들며, 감사 기록까지 남긴다면 자체 데이터 경계·이벤트 트리거·승인 절차가 필요하다. - API는 이런 요구사항을 구현할 수 있는 기본 요소를 제공하지만, 저장소 파일을 어떻게 검색하고 에이전트 권한을 어디까지 허용할지는 개발자가 설계해야 한다. ## 에이전트 SDK는 두 계층 사이의 선택지 - 에이전트 SDK는 모델 API와 완성된 개발 도구 사이에서 오케스트레이션을 담당한다. - 일반적으로 다음 기능을 제공한다. - 도구 사용 - 세션 관리 - 스트리밍 응답 - 에이전트 실행 흐름 제어 - SDK에 따라 특정 제공업체에 종속되거나 여러 모델 제공업체를 지원할 수 있다. - GitHub Copilot SDK는 Copilot CLI를 구동하는 에이전트 런타임을 노출해, 직접 처음부터 에이전트 하네스를 만들지 않고도 검증된 실행 환경을 임베드할 수 있게 한다. - 이 런타임은 Copilot 구독 또는 사용자의 자체 provider key로 실행할 수 있다. ## BYOK: Copilot 워크플로와 모델 비용을 분리 - Copilot의 BYOK(Bring Your Own Key)는 지원되는 외부 모델을 Copilot Chat, Copilot CLI, VS Code에서 사용할 수 있게 한다. - 지원 제공업체에는 다음이 포함된다. - Anthropic - AWS Bedrock - Google AI Studio - Microsoft Foundry - OpenAI 및 OpenAI 호환 제공업체 - xAI - 모델은 Copilot의 하네스와 GitHub가 유지하는 통합 기능을 사용하지만, 토큰 비용은 사용자가 연결한 제공업체에 청구된다. - 기존 클라우드 계약이나 약정된 사용량이 있는 팀은 해당 계약을 유지하면서도 개발자는 익숙한 Copilot 환경을 사용할 수 있다. - Copilot CLI에서는 Azure OpenAI, Anthropic, 로컬 Ollama 모델 등도 사용할 수 있다. - BYOK는 글 작성 시점에 공개 프리뷰이므로 구매나 아키텍처 결정을 내리기 전에 최신 GitHub 문서를 확인해야 한다. - 엔터프라이즈와 조직 관리자는 GitHub 호스팅 모델과 BYOK 모델을 포함해 팀에서 사용할 모델을 정책으로 제한할 수 있다. ## 상황에 따른 선택 기준 - **원시 API를 선택할 때** - 자체 제품이나 내부 시스템에 AI를 통합해야 할 때 - 사용자 정의 프롬프트·검색·라우팅이 필요할 때 - 보안, 감사, 승인, 로그, 과금 체계를 직접 통제해야 할 때 - **GitHub Copilot을 선택할 때** - 개발자가 GitHub와 IDE 안에서 코드를 작성하고 리뷰할 때 - 이슈부터 PR, 테스트, 보안 정책까지 연결된 흐름이 중요할 때 - 조직 차원의 사용량·예산·모델 정책 관리가 필요할 때 - **BYOK를 고려할 때** - Copilot의 개발 워크플로는 유지하면서 특정 외부 모델이나 기존 클라우드 계약을 사용해야 할 때 실용적으로는 팀의 개발 생산성 향상이 목적이면 Copilot을, 독자적인 AI 제품이나 자동화 시스템 구축이 목적이면 원시 API를 우선 검토하는 것이 적절하다. 두 요구가 모두 있다면 Copilot 또는 Copilot SDK에 BYOK를 결합하는 방식도 선택지가 된다.

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

대규모 언어 모델github-copilotAPIagentic-workflows+4

meta·2026년 7월 15일·4분 읽기큐레이션 요약

메타 광고 딥 퍼널 최적화를 위한 계층적 관심사 표현 탐구

Hierarchical Interest Representation은 사용자와 광고주·제품·서비스를 하나의 그래프로 연결하고, 이들의 잠재적 관심사를 여러 수준의 임베딩으로 학습하는 Meta Ads의 상위 표현 계층이다. 희소한 광고 참여 신호에 텍스트·이미지·영상 기반의 세계 지식을 결합해, 사용자의 잠재 관심과 광고주의 상품을 연결하고 딥 퍼널 광고 성과를 높이는 것이 목표다. 수십억 건의 상호작용을 이용해 학습한 범용 임베딩과 관심 토큰은 검색, 개인화, 추천, 감독 신호, 랭킹 모델 전반에 활용될 수 있다. ## 딥 퍼널 광고 최적화를 위한 표현 계층 - 사용자가 스크롤, 클릭, 반응, 구매 등으로 표현한 선호를 바탕으로 명시적·암묵적 관심사를 추론한다. - 광고주가 제공하는 상품·서비스와 사용자의 잠재 관심을 연결해, 단순 노출이나 클릭을 넘어 전환 등 딥 퍼널 목표를 최적화한다. - Meta의 Generative Ads Model(GEM), Andromeda, Adaptive Ranking Model 등 광고 추천 생태계의 여러 단계에서 사용할 수 있는 상위 표현 계층을 지향한다. - 대규모 참여 데이터에서 안정적인 관심 앵커를 추출해, 사용자가 아직 직접 반응하지 않은 광고의 발견 가능성도 높인다. ## 광고 생태계를 그래프로 모델링 - 사용자, 광고주, 제품, 서비스, 캠페인 등을 그래프의 노드로 표현한다. - 노드 사이의 노출, 클릭, 참여, 구매 등의 활동과 이벤트는 엣지가 된다. - Meta의 광고 네트워크는 매월 수백만 광고주와 수백만 개 광고가 수십억 명의 사용자에게 제공되는 초대형 그래프다. - 사용자와 특정 광고 사이의 직접적인 딥 퍼널 신호는 희소하기 때문에, 그래프에서 멀리 떨어진 연결과 공통 패턴을 함께 학습해야 한다. ## 희소한 신호와 동적인 관심사 - 사용자는 ‘관심 있음/관심 없음’ 같은 직접 피드백뿐 아니라 광고 참여 행동으로도 관심을 표현한다. - 광고 노출 기회와 전환 피드백은 광고·상품의 전체 규모에 비해 제한적이다. - 개별 사용자와 광고의 연결만 보면 데이터가 부족하므로, 관련 사용자·상품·광고주 사이의 장거리 관계를 활용해야 한다. - 대규모 그래프에서 장거리 관계를 계산하려면 메모리 효율적인 어텐션 커널과 고성능 학습 알고리즘이 필요하다. ## 차원 축소와 관심 원시 단위 - 원시 광고 그래프를 학습된 잠재 관심 단위인 ‘슈퍼 노드’ 중심의 슈퍼 그래프로 변환한다. - 원래는 희소했던 사용자-광고 연결을 공통 관심 원시 단위로 묶어 더 조밀한 관계로 만든다. - 관심 원시 단위의 어휘는 개별 광고보다 안정적이고 정적이므로, 광고 비즈니스와 상품 구성이 바뀌어도 재사용하기 쉽다. - 이를 통해 개별 광고에 대한 충분한 이력이 없는 사용자나 상품에도 일반화할 수 있다. ## 멀티모달 지식 보강 - 광고주와 제품의 페이지 메타데이터, 카탈로그 속성, 텍스트, 이미지, 영상 정보를 활용한다. - 언어 모델과 비전 모델로 콘텐츠를 처리해, 사용자가 해당 상품과 어떻게 상호작용했는지뿐 아니라 상품 자체가 무엇인지도 표현한다. - 참여 데이터가 부족한 희귀하거나 새롭게 등장한 광고주·제품에 대해서도 의미적 유사성을 바탕으로 추론할 수 있다. - 실제 세계의 지식과 행동 기반 신호를 결합해 콜드스타트와 신호 부족 문제를 완화한다. ## 통합 관계 임베딩 - 사용자, 광고주, 제품, 서비스와 잠재 관심 원시 단위를 하나의 거리 기반 공간에 배치한다. - 임베딩 간 거리를 이용해 다음 관계를 추정할 수 있다. - 사용자와 관심 원시 단위의 근접성 - 광고·광고주가 어떤 관심사를 제공하는지 - 관심 원시 단위끼리의 유사성 - 유사한 사용자, 광고, 제품의 이웃 관계 - 서로 다른 유형의 엔터티 간 친화도 - 동일한 표현 공간을 사용하므로 사용자 관심과 광고 상품의 의미적 연결을 직접 계산할 수 있다. ## 여러 계층의 관심 표현 - 상위 계층은 여행·스포츠·패션처럼 안정적이고 넓은 관심사를 표현한다. - 하위 계층은 특정 브랜드, 세부 상품, 구매 의도처럼 희소하지만 정밀한 관심사를 표현한다. - 조밀하고 안정적인 관계는 더 거친 계층으로, 드물고 구체적인 관계는 더 세밀한 계층으로 표현한다. - 여러 계층을 연쇄적으로 학습하면 검색·개인화에는 넓은 관심 표현을, 최종 랭킹에는 구체적인 의도 표현을 선택적으로 사용할 수 있다. ## 트랜스포머 기반 그래프 학습 - LLM에서 영감을 받은 트랜스포머 구조를 대규모 광고 그래프에 적용한다. - 희소 어텐션을 사용해 모든 노드 간 연결을 계산하지 않고도 장거리 그래프 관계를 포착한다. - 편향을 고려한 어텐션과 자기지도 방식의 교차 뷰 지식 증류를 활용해 여러 관점의 그래프 정보를 통합한다. - 사용자 행동의 시간적 변화와 광고주·제품 콘텐츠의 의미 정보를 함께 학습한다. - 전체 시스템은 실제 Meta 광고 데이터의 수십억 건 상호작용으로 엔드투엔드 학습된다. ## 범용 임베딩과 Bag-of-Meaning 토큰 - 광고 생태계의 사용자·광고주·제품·서비스에 대한 범용 임베딩을 생성한다. - 여러 의미 단위로 구성된 ‘Bag-of-Meaning’ 관심 토큰은 사용자의 관심과 광고의 의미를 공통 어휘로 표현한다. - 이 결과는 다음 용도로 확장될 수 있다. - 광고 및 상품 검색·후보 생성 - 개인화 추천 - 랭킹 모델의 입력 특성 - 학습을 위한 감독 신호 - 특정 도메인에 최적화된 전문 랭킹 아키텍처 실용적으로는 직접적인 전환 데이터가 부족한 광고·상품을 다뤄야 하거나, 신규 엔터티와 장기적인 관심 관계를 포착해야 하는 시스템에 특히 유용하다. 다만 범용 임베딩을 실제 광고 순위에 적용할 때는 최신성, 사용자 프라이버시, 관심사 편향, 계층별 표현의 검증을 함께 관리해야 한다.

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

대규모 언어 모델멀티모달 AItransformerembeddings+4

cloudflare·2026년 7월 1일·4분 읽기큐레이션 요약

콘텐츠 독립기념일, 1년 후—에이전틱 인터넷의 비즈니스 모델 구축

AI 확산으로 인터넷의 기존 경제 모델인 “콘텐츠 제공 → 검색 노출 → 추천 트래픽”의 구조가 빠르게 붕괴하고 있다. 사람들은 검색 결과를 직접 방문하기보다 AI가 통합한 답변을 소비하고 있으며, 크롤러의 절반 이상이 AI 학습용으로 사용된다. 이에 Cloudflare는 콘텐츠 접근 통제·투명성·희소성을 통해 콘텐츠 라이선싱 시장을 만들고, 퍼블리셔가 AI 기업과 더 공정하게 거래할 수 있도록 하겠다고 주장한다. ## AI adoption과 오픈 웹의 급격한 변화 - 생성형 AI는 스마트폰보다 2배 이상 빠른 속도로 확산되고 있다. - 약 3.5년 만에 전 세계 25억 명, 즉 인류의 30% 이상이 정기적으로 생성형 AI를 사용하게 됐다. - 인터넷 사용 방식도 바뀌었다. - 온라인에서 정보를 검색하는 1시간 중 실제 오픈 웹에서 보내는 시간은 약 15분에 불과하다. - 여러 웹사이트를 방문해 정보를 비교하는 대신, 사용자는 AI에 질문하고 통합된 답변을 바로 받는다. - 이 변화는 검색 기반 유입에 의존하던 콘텐츠 사업자에게 직접적인 위협이 된다. ## 에이전틱 인터넷과 비인간 트래픽 - 2026년에는 인터넷 트래픽의 50% 이상이 처음으로 비인간 트래픽이 됐다. - AI 에이전트와 크롤러가 정보 검색, 상품 비교, 조사, 업무 수행을 직접 처리하면서 인간 방문자와 자동화된 접근의 경계가 흐려지고 있다. - 콘텐츠 소유자는 자신의 콘텐츠가 누구에게, 어떤 목적으로 사용되는지 파악하기 어려워지고 있다. ## 크롤러의 목적 변화 - 2026년 6월 기준 크롤러 요청의 52%가 AI 학습 목적이었다. - 2025년 봄의 22%에서 크게 증가한 수치다. - 검색·에이전트·학습을 혼합한 크롤러가 전체 활동의 36% 이상을 차지한다. - 순수 검색용 크롤링은 전체에서 작아지고 있지만, 퍼블리셔의 검색 노출에는 여전히 중요하다. - 혼합형 크롤러는 콘텐츠 소유자에게 딜레마를 만든다. - AI 시대에도 발견되려면 크롤링을 허용해야 한다. - 그러나 그 과정에서 핵심 콘텐츠가 보상 없이 AI 학습에 사용될 수 있다. - 따라서 검색을 위한 접근과 AI 학습을 위한 접근을 기술적으로 구분하는 것이 중요해졌다. ## 검색 유입 중심 모델의 붕괴 - 과거에는 콘텐츠를 검색엔진에 제공하면 검색 결과를 통해 방문자가 유입됐고, 그 트래픽이 광고·구독·판매 등의 경제적 가치를 만들었다. - 현재는 콘텐츠가 계속 크롤링되고 사용되지만, 원 출처로 돌아오는 트래픽은 줄어들고 있다. - AI가 원문을 방문하지 않고도 질문에 답하고 제품을 비교하며 업무를 수행하기 때문이다. - 이에 따라 콘텐츠 제작자는 “사람들이 원문을 방문하지 않아도 어떻게 지속 가능한 수익을 만들 것인가”라는 문제에 직면했다. - 일부 퍼블리셔는 검색 유입이 거의 사라지는 상황을 “Google Zero”라고 부르며 대비하고 있다. ## 산업 전반으로 확산되는 영향 - 초기에는 뉴스·미디어 기업이 가장 큰 영향을 받았지만, 현재는 다음 산업으로 확산되고 있다. - 소매 - 소프트웨어 - IT - 금융 - 일부 고크롤링 분야에서는 1년 이내 인간 트래픽이 최대 40% 감소했다. - 인터넷에 독점적이거나 전문적인 정보를 게시하는 모든 조직이 에이전틱 인터넷에 대응해야 한다. - 이 문제는 퍼블리셔만의 문제가 아니라, 인터넷을 기반으로 운영되는 전체 경제와 정보 생태계의 지속 가능성에 영향을 준다. ## 콘텐츠 시장을 만들기 위한 세 가지 요소 Cloudflare는 Content Independence Day 이후 다음 세 가지 방향을 추진했다고 설명한다. - **투명성과 통제** - 사이트 운영자가 자신의 콘텐츠가 어떻게 접근되고 수익화되는지 결정하도록 지원한다. - **희소성 창출** - 무제한 접근을 기본값으로 두지 않고, 콘텐츠 접근을 제한해 소유자의 협상력을 높인다. - **콘텐츠 마켓플레이스** - 콘텐츠 제작자와 AI 기업이 콘텐츠를 발견하고, 라이선스를 협의하며, 콘텐츠 가치를 정할 수 있는 시장을 구축한다. ## 통제와 투명성이 협상력을 만든 방식 - 기존에는 퍼블리셔가 AI 기업의 콘텐츠 접근·사용 방식을 충분히 알기 어려웠다. - Cloudflare의 귀속 분석, 비즈니스 인텔리전스, 집행 도구는 네트워크 수준에서 AI 콘텐츠 소비를 파악하고 통제하도록 했다. - 이는 자발적 규범인 `robots.txt`보다 강력한 집행 수단으로 제시된다. - 운영자는 다음과 같은 데이터를 확보할 수 있다. - LLM이 콘텐츠에 접근하려 한 빈도 - 어떤 경쟁 AI 모델이 크롤링했는지 - 가장 많이 요청된 URL - 크롤링 횟수와 실제 추천 트래픽의 비율 - 이런 데이터는 콘텐츠 접근을 제한해 희소성을 만들고, 라이선스 협상에서 정보 비대칭을 줄인다. - 결과적으로 퍼블리셔는 AI 기업이 콘텐츠를 얼마나 필요로 하는지 근거를 바탕으로 판단하고, 더 유리한 조건을 협상할 수 있게 된다. ## 실용적인 결론 콘텐츠 사업자는 검색 유입만을 성과 지표로 삼기보다 AI 크롤러의 접근 목적과 규모를 측정해야 한다. `robots.txt` 같은 선언적 방식에 더해 접근 제어, 사용량 분석, AI 학습과 검색 접근의 구분, 콘텐츠 라이선싱 정책을 마련하는 것이 필요하다. 앞으로는 콘텐츠를 공개할지 차단할지의 이분법보다, 어떤 용도로 누구에게 어떤 조건으로 제공할지를 관리하는 능력이 핵심 경쟁력이 될 것이다.

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

대규모 언어 모델AI생성형 AIcloudflare+3

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

Attribution Business Insights로 크롤링의 실체 밝히기

웹사이트의 기존 검색엔진 생태계는 크롤링의 대가로 방문자를 보내는 구조였지만, AI 크롤러의 확산으로 이 균형이 무너지고 있다. AI 봇은 콘텐츠를 대량 수집하면서도 원 사이트로 유입되는 방문자는 거의 제공하지 않아, 게시자는 트래픽·수익·인프라 비용 측면에서 손해를 입을 수 있다. Cloudflare는 이를 판단할 수 있도록 봇별 활동과 크롤링 대비 추천 비율을 보여주는 **Attribution Business Insights** 대시보드를 공개했다. ## 검색엔진 시대에서 ‘제로 클릭’ 시대로 - 전통적인 검색엔진은 콘텐츠를 크롤링한 뒤 사용자에게 원문 페이지를 추천했다. - 게시자는 검색 유입을 통해 광고, 제휴, 구독 수익과 독자 관계를 확보할 수 있었다. - 검색엔진의 크롤링 횟수와 추천 방문자 수 사이에는 비교적 균형 잡힌 관계가 있었다. - 그러나 AI 챗봇은 원문을 수집해 답변을 직접 생성하면서 사용자를 원 사이트로 보내지 않는 ‘제로 클릭’ 환경을 만들고 있다. - 이에 따라 인터넷의 최적화 전략도 SEO에서 AEO(Answer Engine Optimization), GEO(Generative Engine Optimization) 중심으로 변화하고 있다. ## AI 크롤러의 불균형한 트래픽 - Cloudflare가 관찰한 주요 AI 크롤러의 크롤링 대비 추천 방문 비율은 약 **118:1에서 거의 50,000:1**까지 나타났다. - 일부 AI 크롤러는 방문자 한 명을 보내기 위해 콘텐츠를 수십만 번에 가깝게 요청할 수 있다. - 게시자는 두 가지 손실을 동시에 부담한다. - 광고 노출, 직접 방문, 독자 관계 등 수익으로 이어지는 트래픽 감소 - 상업적 가치가 불분명한 봇 요청을 처리하는 서버·대역폭 비용 증가 - 따라서 모든 크롤러를 허용해 노출을 기대하는 기존 전략은 더 이상 합리적이지 않을 수 있다. ## Attribution Business Insights 대시보드 - Cloudflare Bot Management 고객에게 제공되는 대시보드다. - 복잡한 로그 분석이나 수동 필터링 없이 사이트의 봇 트래픽을 사업 관점에서 파악하도록 설계됐다. - 주요 제공 정보는 다음과 같다. - 콘텐츠 페이지에 접근한 인간 사용자와 봇의 전체 트래픽 비교 - 사이트 전체 및 봇 운영자별 크롤링 대비 추천 방문 비율 - 24시간, 7일, 30일 단위의 비율 변화 - 트래픽 규모가 큰 봇 목록 - 봇의 국가, 사용 대역폭, 현재 허용·차단 상태 - 이를 통해 어떤 봇이 콘텐츠를 많이 사용하고 실제 방문자를 유도하는지 확인할 수 있다. ## 행동 기반 AI 크롤러 분류 Cloudflare는 AI 봇을 단순히 ‘AI 크롤러’로 묶지 않고 목적에 따라 분류한다. - **Training** - 차세대 대규모 언어 모델을 학습하기 위해 콘텐츠를 수집하는 크롤러 - **Search** - RAG(검색 증강 생성)에 사용할 데이터베이스를 갱신하는 크롤러 - **Agent** - 최종 사용자의 요청에 답하기 위해 에이전트형 상호작용에서 콘텐츠를 조회하는 크롤러 - 이러한 분류를 통해 게시자는 단순한 요청량뿐 아니라 콘텐츠가 어떤 용도로 사용되는지도 판단할 수 있다. ## 데이터에서 콘텐츠 비즈니스 전략으로 - 사이트 운영자는 보안 전문가가 아니더라도 대시보드의 요약 지표만으로 현재 콘텐츠 보안 정책의 효과를 점검할 수 있다. - 더 자세한 분석이 필요한 경우 봇 운영자별로 다음 정보를 비교할 수 있다. - 봇 유형 - 크롤링 대비 추천 비율 - 전체 요청량 - 현재 허용 또는 차단 정책 - 이 데이터는 AI 기업과의 협상이나 콘텐츠 라이선스 재검토에도 활용할 수 있다. - 예를 들어 특정 회사의 크롤링량이 다른 회사보다 20배 많거나, 이미 콘텐츠 사용료를 지급하는 회사가 있다면 이를 근거로 접근 정책과 계약 조건을 조정할 수 있다. - 핵심은 AI 트래픽을 일괄적으로 허용하거나 차단하는 것이 아니라, 실제 사업 가치와 비용을 기준으로 운영하는 것이다. ## 실용적인 적용 방향 게시자는 봇별 크롤링량, 추천 방문자, 대역폭 비용을 함께 비교해 허용·제한·차단 정책을 세워야 한다. 특히 Training, Search, Agent 목적을 구분하고, 유입 가치가 낮은 대량 크롤러에는 속도 제한이나 차단을 적용하며, 수익 또는 라이선스와 연결되는 봇에는 차별화된 접근 정책을 검토하는 것이 바람직하다.

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

대규모 언어 모델RAGai-crawlersweb-crawling+4

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

프롬프팅에서 워크플로로, AI로 프런트엔드 개발 생산성 끌어올리기

코딩 속도보다 더 큰 병목은 Jira, Figma, Confluence, Slack, Git 등에 흩어진 정보를 모으고 조정하는 비용입니다. 글은 LLM을 단발성 프롬프트 도구가 아니라 반복 가능한 개발 워크플로의 실행 엔진으로 활용해야 한다고 주장합니다. 이를 통해 구현 전 요구 사항을 통합하고, 불확실성을 드러내며, 구현 후 검증까지 자동화하는 오케스트레이션 중심의 프런트엔드 개발이 가능해집니다. ## 프런트엔드 개발의 병목 변화 - 하나의 기능을 구현하려면 여러 시스템을 오가야 합니다. - 요구 사항: Jira - 디자인: Figma - 기술·정책 문서: Confluence - 의사결정과 논의: Slack - 구현과 검증: Git - 프런트엔드 개발자는 이 정보를 통합해 실제 사용 가능한 결과물로 조립하는 역할을 담당합니다. - 주요 부담은 코드를 작성하는 일보다 다음과 같은 컨텍스트 작업에 있습니다. - 티켓과 디자인 분석 - 에지 케이스 확인 - 제품·백엔드 팀과의 동기화 - 기존 코드와 재사용 가능한 구성 요소 탐색 ## 프롬프트에서 반복 가능한 워크플로로 - 단발성 프롬프트는 한 번의 작업에는 유용하지만, 반복성과 누적 효과가 부족합니다. - 워크플로는 입력부터 출력까지의 표준화된 경로입니다. - 여러 시스템에서 관련 컨텍스트 수집 - 요구 사항 요약 - 모호하거나 충돌하는 내용 식별 - 구현 계획과 파일 목록 제안 - 사람이 검토한 뒤 코드 수정 진행 - 이 구조에서 LLM은 단순히 코드를 생성하는 도구가 아니라 워크플로를 실행하는 엔진입니다. - 한 번 구축한 워크플로는 티켓의 내용이 달라져도 동일한 패턴으로 적용할 수 있어 확장성이 높습니다. ## 연결된 개발 컨텍스트와 Noah MCP - LY Corporation의 Noah MCP는 Jira, Confluence, Slack, GitHub 같은 내부 도구를 연결합니다. - AI 에이전트가 사람이 복사해 붙여넣은 정보가 아니라 실제 업무 시스템에 존재하는 컨텍스트를 직접 읽고 추론할 수 있게 합니다. - 이를 통해 개발자는 각 시스템을 수동으로 방문하고 정보를 노트에 조합하는 작업을 줄일 수 있습니다. - 핵심은 AI를 별도의 도구로 사용하는 것이 아니라 기존 업무 흐름 안에 배치하는 것입니다. ## 구현 전 요구 사항 통합 예시 기능은 검색·필터·정렬과 역할 기반 필터 표시가 있는 목록 페이지입니다. 기존 방식에서는 개발자가 Jira, Figma, Confluence, Slack, 코드베이스를 직접 확인한 뒤 계획을 작성합니다. 워크플로 기반 방식에서는 에이전트에게 다음을 요청합니다. - Jira 티켓 분석 - 관련 Confluence 문서 검색 - Slack의 최근 의사결정 확인 - 유사한 코드 구현 탐색 - 코드 수정 없이 다음 결과 반환 - 요구 사항 요약 - 프런트엔드 영향 범위 - 관련 파일 - 구현 체크리스트 - 테스트 체크리스트 - 미해결 질문 에이전트가 도출한 계획에는 다음과 같은 구체적인 정보가 포함됩니다. - `FeatureListPage.tsx`, `FeatureList.tsx` 등 신규 파일 - 기존 `useTableFilters`, `useUrlState` 훅의 재사용 - `GET /api/<feature>`의 기존 페이지네이션 API 활용 - 역할별 필터 표시 - viewer: 검색, 상태 필터, 날짜 범위 - editor: owner 필터 추가 - admin: 내부 전용 플래그 추가 - 필터·정렬·페이지 상태를 URL 파라미터와 동기화 - 로딩, 빈 결과, 검색 결과 없음 상태 구현 ## 숨겨진 요구 사항과 재작업 방지 - Slack 논의에서 필터 상태를 `localStorage`가 아니라 URL에 저장해야 한다는 결정이 발견됩니다. - URL 공유가 가능해지고 - 새로고침 후에도 상태가 유지되며 - 다른 사용자가 동일한 화면을 재현할 수 있습니다. - 코드베이스 검색을 통해 이미 존재하는 훅을 재사용할 수 있습니다. - 불필요한 중복 구현 방지 - 기존 동작과의 일관성 유지 - 개발 시간 단축 - 구현 전에 다음과 같은 미해결 사항도 드러납니다. - 필터·정렬 상태를 URL에 저장할지 여부 - 빈 상태에서 “필터 초기화” 버튼을 제공할지 여부 - 이런 문제를 PR 리뷰 단계가 아니라 구현 전에 발견하면 재작업 가능성을 줄일 수 있습니다. ## 코딩 이후의 폐쇄 루프 검증 워크플로는 코드 생성에서 끝나지 않고 검증 단계까지 포함해야 합니다. - 구현 후 원래 계획과 실제 변경 사항을 대조합니다. - 자동 검증 항목을 실행합니다. - 타입 검사 - 린트 - 관련 단위 테스트 - 스모크 테스트 또는 로컬 검증 흐름 - 에이전트는 다음 결과를 보고합니다. - 통과한 검사 - 실패 후 수정한 문제 - 자동화하지 못한 검증 - UI 상태별 스크린샷이나 확인 메모 - PR 전 남은 위험 요소 - 이 폐쇄 루프를 통해 계획, 구현, 검증이 하나의 연속된 개발 사이클이 됩니다. ## 실용적인 적용 방향 프런트엔드 팀은 먼저 Jira·문서·메신저·코드 검색을 묶은 “구현 전 분석 워크플로”부터 도입하는 것이 좋습니다. 이후 구현 계획 승인, 코드 수정, 자동 테스트, PR 전 검증을 단계적으로 연결하면 단순한 코드 생성보다 재작업 감소와 품질 향상이라는 더 큰 효과를 얻을 수 있습니다.

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

대규모 언어 모델모델 컨텍스트 프로토콜ReactTypeScript+4