context-engineering

8 개의 포스트

line4분 읽기큐레이션 요약

개인 AI 활용의 다음 단계는 무엇인가 - LY Corporation에서 AIDD 워크숍을 통해 살펴본 AIDD 조직 도입의 조건

LY Corporation은 개인의 AI 활용을 조직 차원의 재현 가능한 개발 방식으로 확장하기 위해 팀 단위 AIDD 워크숍을 진행했습니다. 워크숍의 핵심 결론은 AI 도구 자체보다 요구 사항, 사양, 용어, 제약 조건 등 컨텍스트를 정비하고 사람과 AI의 역할·책임을 설계하는 일이 더 중요하다는 것입니다. 또한 조직적 도입을 위해서는 다양한 직군과 의사결정자가 실제 업무 주제를 함께 다뤄야 합니다. ## AIDD의 정의와 지향점 - AIDD는 요구 사항 정리부터 설계, 구현, 리뷰까지 개발 전 과정에서 AI를 협력자로 활용하는 방식입니다. - AI에 업무를 일괄 위임하는 것이 아니라, AI가 초안을 만들고 사람이 의도·제약 조건을 제공하며 핵심 판단과 책임을 맡습니다. - 각 단계의 결과를 다음 단계로 연결하는 통합된 개발 프로세스를 설계하는 것이 중요합니다. - 따라서 AIDD는 단순한 보조 도구 활용이 아니라, AI와 사람의 역할 분담을 포함한 개발 방식의 재설계입니다. ## 개인 활용에서 조직 도입으로 넘어가는 장벽 - AI 코딩 에이전트는 코드 자동 완성, 테스트, 리서치, 문서 작성 등에 널리 활용되고 있습니다. - 그러나 다음과 같은 문제로 개인의 노하우에 머무르기 쉽습니다. - 개인이 사용해도 팀의 개발 프로세스와 연결되지 않음 - AI 산출물의 리뷰 기준과 책임 범위가 불명확함 - 기존 제품과 코드베이스에 적용하는 방법이 모호함 - 편리함은 확인했지만 조직 차원의 투자와 표준화로 이어지지 않음 - 워크숍은 이러한 정체를 해결하고, 조직이 AI를 활용하기 위한 ‘AI Ready’ 조건을 확인하는 데 목적이 있었습니다. ## 팀 단위 워크숍을 선택한 이유 - AI 활용의 성과는 프롬프트 작성 능력보다 정보 전달, 리뷰 지점, 최종 산출물 기준, 피드백 흐름에 좌우됩니다. - 기획, 디자인, 엔지니어링, 리더십 등 여러 역할의 관점과 암묵지가 함께 드러나야 프로세스를 설계할 수 있습니다. - 팀 단위로 실제 업무를 다루면 다음 논점이 구체화됩니다. - 어떤 업무에 AI를 적용할 것인가 - 누가 AI 산출물을 검토할 것인가 - 어떤 결과물을 공식 산출물로 인정할 것인가 - 책임과 의사결정의 경계를 어디에 둘 것인가 - 의사결정자가 참여하면 적용 범위, 투자 우선순위, 표준화 수준을 워크숍 이후 실행으로 연결하기 쉬워집니다. ## 이틀간의 프로그램 구성 - 첫째 날에는 문제 정의와 업무 컨텍스트 정리에 집중했습니다. - 둘째 날에는 팀이 자율적으로 AI 활용을 검증하고 실제 업무에 적용 가능한 형태로 구체화했습니다. - 21개 팀, 112명이 실제 프로젝트 주제를 가져와 실습했습니다. - Orchestration 길드, Developer Relations, Technical Directors가 콘텐츠 구성과 멘토링, 학습 공유를 지원했습니다. - 단순한 도구 시연이 아니라 이해, 실습, 검증, 공유를 반복하는 실천 중심 구조였습니다. ## 구현보다 중요한 사전 정리 - AI 코딩 에이전트의 코드 생성 속도보다 그 이전 단계의 정리 작업이 더 큰 가치로 인식되었습니다. - 특히 다음 작업이 중요했습니다. - 모호한 요구 사항을 논점별로 분해하기 - 요구 사항을 명확한 언어로 정의하기 - 팀 내부의 인식을 일치시키기 - 선행 의사결정과 우선순위를 정하기 - 다음 작업 단위로 구체화하기 - AI가 개발을 전진시키려면 사람이 목적과 제약 조건을 먼저 명확히 해야 합니다. ## 병목은 AI 도구가 아니라 컨텍스트 - AI 출력의 품질은 제공되는 컨텍스트의 품질에 크게 의존합니다. - 필요한 컨텍스트에는 다음이 포함됩니다. - 사양과 용어 - 제약 조건 - 설계 의도와 판단 이유 - 기존 코드와 기능 간의 관계 - 운영 규칙 - 컨텍스트가 부족하면 AI가 그럴듯한 답을 내더라도 실무 적용이 어렵고, 사람의 리뷰 부담이 커집니다. - 따라서 컨텍스트 정리는 부수적인 준비가 아니라 조직적 AI 활용을 위한 핵심 기반입니다. ## 팀 협업과 의사결정자의 역할 - 개인 실험에서는 잘 드러나지 않던 합의 형성, 책임 범위, 리뷰 기준이 팀 단위 활동에서 명확해졌습니다. - 서로 다른 직군이 같은 업무를 검토하면서 역할별 인식 차이와 숨은 전제가 드러났습니다. - 리더나 의사결정자가 참여한 팀은 워크숍 후에도 다음 실행으로 이어질 가능성이 높았습니다. - 조직 확산을 위해서는 다음을 결정할 사람이 초기 단계부터 참여해야 합니다. - 우선 적용 영역 - 투자할 시간과 자원 - 표준화할 대상 - 운영 프로세스에 내재화할 범위 ## 조직에 AIDD를 정착시키는 방법 - 처음에는 적용하기 쉬운 주제부터 시작해야 합니다. - 요구 사항이나 쟁점이 불명확한 업무 - 관계자 간 인식 정렬이 중요한 업무 - 기존 정보를 어느 정도 확보할 수 있는 업무 - 짧은 주기로 결과를 검증할 수 있는 업무 - 기능 하나, 요구 사항 정리 하나, 리뷰 기준 정리 하나처럼 작은 진입점을 마련해야 합니다. - 사양·용어·제약 조건·설계 의도를 정리하는 작업을 개인의 자발성에 맡기지 말고 공식 업무로 인정해야 합니다. - 컨텍스트 자산화는 AI를 위한 작업인 동시에 팀의 개발 역량과 지식을 강화하는 활동입니다. 실무적으로는 전사 도입을 서두르기보다, 의사결정자와 여러 직군이 참여하는 작은 팀에서 실제 업무 한 사이클을 검증하는 것이 좋습니다. 그 과정에서 컨텍스트, 리뷰 책임, 표준화 범위를 정리한 뒤 성공 사례를 조직 전체로 확장해야 합니다.

원문 읽기(새 탭에서 열림)
netflix5분 읽기큐레이션 요약

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 기반 구조가 유효할 수 있음을 보여준다.

원문 읽기(새 탭에서 열림)
kakao4분 읽기큐레이션 요약

AI 에이전트로 카카오톡 추천 지표 분석 자동화하기

카카오는 기존 Hadoop 환경에 AI 에이전트를 연결해 추천 지표 분석 절차를 자동화했다. 핵심은 새로운 플랫폼이나 권한을 추가하는 것이 아니라, 사람이 알고 있던 데이터 접근 절차·지표 정의·판단 기준을 Markdown 기반 스킬과 컨텍스트 문서로 정리하는 데 있었다. AI는 분석 초안을 빠르게 만들고 다음 질문을 제안하지만, 결과의 정확성과 최종 판단은 사람이 검증해야 한다. ## 반복적인 추천 지표 분석의 비효율 - CTR 하락, 실험군 반응, 배포 후 사용자군 변화 등을 확인하려면 다음 과정을 반복해야 한다. - 분석 환경 접속 - 적절한 테이블 탐색 - SQL 작성 및 실행 - 결과 해석 - 연령대·카테고리·시간대 등 관점별 추가 분석 - 질문은 간단해도 데이터 준비와 추출에 많은 시간이 걸린다. - 반복적이고 절차가 정형화된 업무이므로 AI 자동화에 적합하다. ## Hadoop 접속 절차를 Agent Skill로 정리 - 기존 Hadoop 접속 스크립트와 실행 환경은 그대로 활용했다. - AI가 Hadoop을 사용할 수 있도록 접속·쿼리 실행 방법을 `SKILL.md` Markdown 문서로 작성했다. - 여러 스킬을 묶은 사내 플러그인 `hadoop-butler`를 통해 AI가 다음 작업을 수행하도록 했다. - Hadoop 클러스터 접속 - 분석 목적에 맞는 SQL 작성 - 쿼리 제출 및 결과 수집 - 결과 정리와 인사이트 도출 - 새로운 분석 플랫폼이나 MCP 서버를 구축하기보다, 기존 인프라에 업무 지식을 “접착제”처럼 추가한 접근이다. ## 컨텍스트 문서로 분석 기준 명시 - 분석 디렉터리에 `CLAUDE.md`, `AGENTS.md`와 같은 컨텍스트 문서를 배치했다. - 문서에는 다음 정보를 담았다. - 분석 대상 테이블과 Hadoop 클러스터 - `watch_length`, `valid_view` 등 주요 컬럼의 의미 - 사용자·세션 집계 기준 - CTR 등 주요 지표의 정의 - 명확한 기준을 문서화하면 AI가 매번 테이블과 컬럼의 의미를 추측하지 않아도 된다. - 이는 AI의 분석 품질을 높이는 동시에 팀의 데이터 지식을 문서화하고 신규 구성원의 온보딩에도 도움을 준다. ## AI는 분석 초안을 만들고 사람은 질문을 확장 - 자연어로 분석 목적을 설명하면 AI가 첫 번째 리포트와 추가 분석 후보를 제시한다. - 이상치 확인, 실험 결과 비교, 주간 현황 점검처럼 반복 업무에 특히 효과적이다. - 대시보드가 수치를 빠르게 보여준다면, 자연어 분석은 “어디를 더 살펴볼지”를 제안한다. - 사용자는 초안 결과를 확인한 뒤 세부 사용자군이나 특정 기간 등으로 질문을 이어가며 분석을 구체화할 수 있다. - AI 결과는 최종 결론이 아니라 검토 대상이며, 쿼리 기준과 지표 정의를 사람이 확인해야 한다. ## AI가 그럴듯하게 만드는 의미·성능 오류 - **의미 오류** - 사용자 수 집계에 계정 단위 식별자인 `user_id` 대신 세션 성격의 `session_user_id`를 사용할 수 있다. - 쿼리는 정상 실행되지만 실제 사용자 수 의미와 다른 결과를 낼 수 있다. - **성능 오류** - 여러 컬럼에 대해 `COUNT(DISTINCT ...)`를 한 번에 실행하는 SQL을 생성할 수 있다. - Hive에서는 이 방식이 단일 리듀서로 처리되어 매우 느려질 수 있다. - 컬럼별 쿼리를 분리해 병렬 실행하는 방식이 더 적절하다. - 문법적으로 올바른 SQL과 업무적으로 올바른 분석은 다르므로, 도메인 지식과 실행 엔진 특성에 대한 검증이 필요하다. ## 문서화와 회귀 테스트로 품질 관리 - 자주 발생하는 오류를 지침에 명시적으로 추가했다. - 사용자 수 집계에는 반드시 `user_id` 사용 - 모든 컬럼명은 백틱으로 감싸 예약어 충돌 방지 - 다중 `COUNT(DISTINCT)`는 컬럼별로 분리해 병렬 실행 - 스킬과 프롬프트가 늘면서 한 지침 수정이 다른 기능을 깨뜨리는 회귀 문제가 발생했다. - 이를 해결하기 위해 MLflow 기반 E2E 평가 파이프라인을 구축했다. - 스킬별 기대 동작을 테스트 시나리오로 정의 - 에이전트를 헤드리스 모드로 실행 - LLM Judge가 결과를 평가 - 도구 호출 순서, 실행 트레이스, 최종 출력까지 다층 검증 - 배포 전 전체 시나리오를 자동 회귀 테스트 - 자연어 지침도 소프트웨어처럼 테스트와 배포 관리가 필요하다는 점을 강조한다. ## 실용적인 도입을 위한 네 가지 요소 - **모델**: 자연어 요청을 이해하고 분석 절차를 수행하는 에이전트 - **컨텍스트**: 테이블, 피처, 지표 정의와 업무 규칙 - **실행 환경**: 실제 데이터에 접근할 수 있는 기존 Hadoop 인프라 - **검증 루프**: 결과와 도구 실행 절차를 확인하는 자동 테스트 체계 반복 업무에 AI를 도입할 때는 새로운 시스템부터 만들기보다, 기존 절차와 도메인 지식을 문서화하고 실행 환경에 연결하는 것이 효과적이다. 다만 AI의 결과를 그대로 신뢰하지 말고, 명확한 분석 기준과 회귀 테스트를 함께 마련해야 실무에서 안전하게 활용할 수 있다.

원문 읽기(새 탭에서 열림)
line4분 읽기큐레이션 요약

ODW #7: 세 가지 방법으로 토큰 소비량 40% 절감! ADK를 이용한 컨텍스트 엔지니어링

LY Corporation의 워크숍은 AI 에이전트의 비용 증가와 응답 정확도 저하를 해결하기 위해 컨텍스트 엔지니어링을 소개한다. 핵심은 LLM에 전달하는 프롬프트, 도구 정의, 대화 이력, 외부 데이터를 무조건 많이 제공하는 것이 아니라 작업에 필요한 고품질 정보만 적절한 형태로 선별하는 것이다. ADK의 구조화 스키마, AgentTool, MCP 도구 필터링을 활용하면 토큰 사용량을 줄이면서도 장시간 실행 에이전트의 정확도를 개선할 수 있다. ## 사내 AI 활용 확대에 따른 문제 - Claude Code, Cline, ADK 등 AI 도구의 사용자가 늘면서 토큰 소비량이 급증했다. - 프롬프트에 명시한 지시를 AI가 무시하거나 중요한 정보를 누락하는 문제가 발생했다. - 대화가 길어질수록 AI가 이전 맥락에 묻혀 엉뚱한 답변을 생성하기도 했다. - 주요 원인은 LLM에 전달되는 컨텍스트를 체계적으로 관리하지 않았기 때문이다. - 토큰 증가 요인에는 다음이 포함된다. - AI 사용 인구 증가 - 원하는 결과를 얻기 위한 반복 작업 - 싱글 에이전트에서 멀티 에이전트로의 확장 - 단발성 작업에서 장시간 실행 작업으로의 변화 - MCP 도구 정의 자체가 차지하는 토큰 - 컨텍스트 최적화 기법의 확산 부족 ## 컨텍스트 부패와 토큰 관리 - LLM 사용 비용은 입력과 출력에 사용된 총 토큰 수를 기준으로 산정된다. - 장시간 실행되는 에이전트에서는 대화 이력과 중간 결과가 계속 축적된다. - 현재 작업과 관계없는 정보가 컨텍스트에 남으면 중요한 신호가 노이즈에 묻힌다. - 이로 인해 컨텍스트 윈도 압박, 관련성 저하, 응답 정확도 하락이 발생한다. - 해결책은 필요한 정보만 추려 LLM에 전달하는 것이다. ## 컨텍스트 엔지니어링의 개념과 원칙 컨텍스트 엔지니어링은 에이전트가 사용하는 모든 문맥 정보를 설계하고 최적화하는 방법이다. - 관리 대상은 세 가지로 나뉜다. - **정적 컨텍스트**: 시스템 프롬프트, 도구 정의 - **동적 컨텍스트**: 사용자 메시지, 대화 이력, RAG 데이터 - **장기 컨텍스트**: 장시간 실행 중 축적되는 정보와 세션 상태 - 핵심 원칙은 “고품질 신호를 가진 최소한의 토큰 집합”을 찾는 것이다. - 정보를 너무 적게 주면 AI가 추측에 의존한다. - 정보를 지나치게 많이 주면 비용이 증가하고 핵심 정보가 묻힌다. - 따라서 작업에 필요한 수준으로 구체적이면서도 불필요한 정보는 제거해야 한다. - 프롬프트 엔지니어링이 지시문 작성에 초점을 둔다면, 컨텍스트 엔지니어링은 프롬프트뿐 아니라 도구, 데이터, 이력, 상태까지 포함해 전체 입력 환경을 최적화한다. ## ADK를 활용하는 이유 Google의 오픈소스 AI 에이전트 프레임워크인 ADK는 컨텍스트 엔지니어링을 팀 단위로 적용하기에 적합하다. - 개인의 CLI 숙련도에 의존하지 않고 팀의 지식을 에이전트 설계에 반영할 수 있다. - UI, API 서버, 평가 기능, 멀티 에이전트 구성을 제공한다. - 에이전트를 조합하고 도구처럼 호출할 수 있어 컨텍스트를 분리하기 쉽다. - 컨텍스트 엔지니어링을 위한 9개 핵심 컴포넌트를 조합해 사용할 수 있다. ## 주요 ADK 컴포넌트 실습에서는 다음 세 가지 기능을 중심으로 설명한다. - **Structuring Data** - 입력과 출력을 특정 JSON 스키마로 강제한다. - 에이전트 간 데이터 전달 형식을 명확히 한다. - 불필요한 자연어 설명을 줄여 토큰 사용량을 절감한다. - **AgentTool** - 다른 에이전트를 함수나 도구처럼 호출한다. - 하위 에이전트의 내부 도구와 중간 컨텍스트를 호출자에게 노출하지 않는다. - 최종 결과만 반환해 상위 에이전트의 컨텍스트 누적을 막는다. - **MCP Toolset의 `tool_filter`** - MCP 서버가 제공하는 도구 중 필요한 도구만 선택한다. - 예를 들어 Jira 티켓 검색에는 `jira_search`, 상세 조회에는 `jira_get_issue`만 허용할 수 있다. - 불필요한 도구 정의를 제거해 토큰 비용과 LLM의 판단 부담을 줄인다. ## Jira 주간 보고서 에이전트: v1의 문제 v1은 하나의 에이전트가 Jira 티켓 검색, 개별 티켓 상세 조회, 분석, 보고서 작성을 모두 수행하는 구조다. - 단일 에이전트에 Jira 관련 도구를 모두 제공한다. - 티켓마다 상세 정보를 가져와 같은 컨텍스트에 계속 축적한다. - 티켓 수가 증가할수록 컨텍스트가 커지고 컨텍스트 부패가 발생한다. - 여러 도구의 정의와 중간 결과가 함께 전달되어 토큰 사용량이 커진다. - 장시간 작업에서 중요한 티켓 정보와 불필요한 이전 정보가 섞일 가능성이 높다. ## Jira 주간 보고서 에이전트: v2의 개선 v2는 역할을 분리한 2-에이전트 구조로 변경했다. - **루트 에이전트** - Jira 티켓 목록을 검색한다. - 개별 티켓 분석 에이전트를 호출한다. - 각 분석 결과를 Markdown 표 형태의 주간 보고서로 집계한다. - **개별 티켓 분석 에이전트** - 하나의 Jira 티켓만 담당한다. - `issue_key`를 입력으로 받고 `report`를 구조화된 출력으로 반환한다. - Jira 상세 조회 도구인 `jira_get_issue`만 사용할 수 있다. - 사실만 포함하고 추측은 금지하도록 지시된다. - `AgentTool`을 통해 하위 에이전트의 내부 처리 과정은 루트 에이전트에 노출하지 않는다. - `input_schema`와 `output_schema`로 에이전트 간 데이터 형식을 제한한다. - `tool_filter`로 각 에이전트가 실제로 필요한 MCP 도구만 사용하게 한다. - 결과적으로 티켓별 상세 분석 컨텍스트가 루트 에이전트에 불필요하게 누적되는 것을 줄인다. AI 에이전트를 설계할 때는 프롬프트를 길게 작성하는 것보다 어떤 정보를 언제, 어떤 형식으로 전달할지 먼저 설계하는 것이 중요하다. 특히 작업을 하위 에이전트로 분리하고, 입력·출력 스키마와 도구 필터를 적용하면 비용과 정확도를 함께 개선할 수 있다.

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

에이전틱 개발 이야기: Spotify x Anthropic Live | Spotify Engineering (새 탭에서 열림)

Spotify와 Anthropic은 소프트웨어 개발의 패러다임이 AI 에이전트 중심으로 급격히 이동하고 있으며, 이는 단순한 도구의 변화를 넘어 조직의 인프라와 개발 문화 전반의 혁신을 요구한다고 강조합니다. 특히 Spotify의 배경 코딩 에이전트 'Honk'의 사례를 통해 수천 개의 저장소에 걸친 복잡한 마이그레이션을 자동화하는 등 실질적인 대규모 에이전트 운용 전략을 제시했습니다. 결론적으로 미래의 개발 환경은 인간 중심의 IDE에서 에이전트 중심의 터미널 기반 상호작용으로 변화하며, 개발자의 역할은 코드 작성자에서 에이전트 결과물에 책임을 지는 관리자로 진화할 것입니다. **에이전트 중심 개발로의 전환과 기술적 변곡점** * Anthropic의 Opus 4.5 모델 출시를 기점으로 Spotify 내부 엔지니어들의 작업 방식에 뚜렷한 변화가 관찰되었습니다. * 개발자들이 IDE(통합 개발 환경) 앞에 머무는 대신, 터미널에서 에이전트와 직접 소통하며 명령을 내리는 시간이 비약적으로 증가했습니다. * 이는 AI를 단순한 보조 도구가 아닌, 개발 워크플로우의 핵심 주체로 인식하기 시작했음을 시사합니다. **Spotify의 코딩 에이전트 'Honk'와 Slack 기반 워크플로우** * Spotify는 'Honk'라는 이름의 배경 코딩 에이전트를 구축하여 Slack 메시지만으로 작업을 지시할 수 있는 환경을 마련했습니다. * Honk는 결정론적인 단순 코드 마이그레이션을 넘어, 수천 개의 리포지토리에 걸친 복잡하고 대규모인 소프트웨어 변경 작업을 수행합니다. * 개발자들이 Slack에서 문제를 논의하다가 Honk를 멘션(@Honk)하여 즉시 해결책을 실행하도록 하는 에이전트 친화적 협업 모델이 정착되었습니다. **대규모 AI 확장을 위한 컨텍스트 엔지니어링** * 엔터프라이즈 규모에서 Claude와 같은 모델을 효과적으로 활용하기 위해선 복잡한 시스템보다 표준화되고 재현 가능한 설정이 중요합니다. * Claude MD 설정이나 도메인 특화 스킬 정의 등 단순하면서도 명확한 '컨텍스트 엔지니어링'이 에이전트의 성능을 좌우합니다. * Spotify의 개발자 포털인 Backstage는 MCP(Model Context Protocol)를 통해 수동 워크플로우를 대체하며 에이전트 우선 플랫폼으로 진화하고 있습니다. **에이전트 시대의 거버넌스와 책임** * 에이전트가 인간의 리뷰 속도보다 빠르게 코드를 생성하고 배포함에 따라 새로운 병목 현상과 거버넌스 문제가 발생하고 있습니다. * 중요한 것은 코드의 생성 주체(인간 vs 에이전트)가 아니라 '결과물' 중심의 사고방식이며, 최종 결과에 대해 책임을 지는 주체는 여전히 인간이어야 합니다. * 에이전트가 생성한 출력물에 대한 투명한 검토 체계와 책임 소재를 명확히 하는 것이 대규모 도입의 핵심입니다. **소프트웨어 생명주기 전체로의 확장** * 2025년까지의 변화가 코드 생성에 집중되었다면, 향후 에이전트의 역할은 유지보수, 코드 삭제 등 개발자가 기피하는 '번거로운 작업' 전반으로 확장될 것입니다. * Anthropic은 내부적으로 'Ant-fooding'이라 불리는 테스트 문화를 통해 Claude Code와 Cowork 같은 제품을 지속적으로 고도화하며 개발 수명 주기 전반을 자동화하고 있습니다. 성공적인 에이전트 도입을 위해서는 기술적 복잡성에 매몰되기보다, 조직 내 리포지토리 전반에 걸쳐 일관된 컨텍스트를 제공할 수 있는 표준화된 인프라를 먼저 구축해야 합니다. 또한, 에이전트가 생성한 방대한 코드의 품질을 관리할 수 있도록 인간의 역할을 '작성'에서 '검증 및 책임'으로 재정의하는 조직적인 준비가 필요합니다.

toss원문

Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기 (새 탭에서 열림)

현재 많은 개발팀이 LLM을 도입하고 있지만, 실제 생산성은 엔지니어 개개인의 'LLM 리터러시'에 따라 극심한 격차를 보이고 있습니다. 이러한 '각자도생'의 한계를 극복하기 위해서는 LLM을 개인의 도구가 아닌 팀 차원의 시스템으로 편입시켜 전체적인 생산성의 저점(Floor)을 높이는 전략이 필요합니다. Claude Code와 같은 생태계를 활용해 팀의 노하우를 '실행 가능한 지식(Executable SSOT)'으로 자산화하는 것이 Software 3.0 시대의 핵심 경쟁력이 될 것입니다. **컨텍스트 엔지니어링과 LLM 리터러시의 격차** * 단순 질문을 반복하는 방식과 작업 전 팀의 가이드라인, 린트 규칙, 코드 패턴 등 '컨텍스트'를 먼저 주입하는 방식은 결과물에서 큰 차이를 만듭니다. * 이러한 생산성 격차는 코딩 실력이 아닌 LLM을 제어하는 노하우의 차이이며, 이를 개인의 센스에만 맡기는 것은 조직적 손실입니다. * 팀 전체의 역량을 상향 평준화하기 위해서는 누구나 최적의 맥락 위에서 작업할 수 있도록 돕는 시스템적 장치(Harness)가 필요합니다. **Claude Code와 마찰 없는 워크플로우 이식** * 브라우저 기반 챗봇으로 코드를 복사·붙여넣기 하는 과정에서 발생하는 문맥 교환(Context Switching) 비용을 최소화해야 합니다. * Claude Code가 제공하는 TUI(Terminal User Interface) 환경은 터미널 안에서 자연어와 코드가 끊김 없이 섞이는 매끄러운 경험을 제공합니다. * 이러한 낮은 진입 장벽은 설계된 AI 워크플로우를 팀원들에게 저항감 없이 전파할 수 있는 기반이 됩니다. **실행 가능한 진실의 원천(Executable SSOT)** * 기존의 위키나 노션 문서는 작성 즉시 낡은 정보가 되지만, 플러그인 형태의 지식은 사람이 읽는 매뉴얼인 동시에 LLM이 즉시 실행하는 시스템 프롬프트가 됩니다. * RAG(검색 증강 생성) 방식은 내부 로직의 불투명성으로 인해 어떤 컨텍스트가 주입될지 예측하기 어렵다는 단점이 있습니다. * 반면 플러그인 방식은 명시적인 코드로서 개발자가 주입되는 맥락을 100% 통제할 수 있어 높은 예측 가능성과 신뢰성을 제공합니다. **계층화된 아키텍처를 통한 거버넌스와 전파** * 지식을 전사 공통(Global), 팀/비즈니스 도메인(Domain), 특정 프로젝트(Local)의 3단계 레이어로 계층화하여 관리함으로써 지식의 파편화를 방지합니다. * `/new-feature`와 같은 슬래시 커맨드를 통해 숙련된 엔지니어의 노하우(이슈 발급, 브랜치 생성, 구현 계획 수립 등)를 모든 팀원에게 즉시 배포할 수 있습니다. * 단순한 린터를 넘어, 메인 브랜치 커밋 시도를 감지하고 정책에 맞는 브랜치 생성을 가이드하는 등 AI 에이전트 기반의 강력한 거버넌스 구현이 가능합니다. **엔지니어링의 본질: 플랫폼 엔지니어링과 데이터 플라이휠** * Software 1.0 시대에 공통 라이브러리로 중복 작업을 줄였듯, Software 3.0에서는 AI 워크플로우 플러그인을 통해 팀의 생산성을 최적화해야 합니다. * 규격화된 플러그인을 통해 축적된 양질의 데이터는 향후 도메인 특화 모델(sLLM)을 파인튜닝하고 평가하는 기반이 됩니다. * 사용자가 많아질수록 데이터가 쌓이고 모델이 정교해지는 '데이터 플라이휠' 구조를 구축하는 것이 AI-Native 조직의 최종 목표입니다. 이제 LLM 활용 능력은 개인의 역량을 넘어 팀이 설계하고 배포해야 할 시스템의 영역입니다. Claude Code의 마켓플레이스와 같은 도구를 활용해 팀 내에 흩어진 암묵지를 명시적인 워크플로우로 엮어내고, 우리 조직에 최적화된 '시스템 하네스'를 구축하는 것부터 시작해 보기를 추천합니다.

line원문

엔터프라이즈 LLM 서비스 구축기 1: 컨텍스트 엔지니어링 (새 탭에서 열림)

대규모 엔터프라이즈 환경에서 LLM 서비스를 구축할 때는 정교한 지시어(프롬프트 엔지니어링)보다 AI에게 필요한 정보만 선별해 제공하는 '컨텍스트 엔지니어링'이 더욱 중요합니다. LY Corporation은 260개가 넘는 API와 방대한 문서를 다루는 클라우드 AI 어시스턴트를 개발하며, 컨텍스트의 양이 늘어날수록 모델의 추론 성능이 하락하고 환각 현상이 발생하는 문제를 확인했습니다. 이를 해결하기 위해 사용자의 의도에 맞춰 필요한 도구와 가이드라인만 실시간으로 주입하는 '점진적 공개' 전략과 시스템 프롬프트의 충돌을 방지하는 '모의 도구 메시지' 기법을 도입하여 성능과 정확도를 동시에 확보했습니다. ### 컨텍스트 과부하와 성능의 상관관계 * **정보량과 성능의 반비례**: 최신 LLM은 수십만 토큰의 컨텍스트 윈도우를 지원하지만, 입력 길이가 길어질수록 핵심 정보를 찾는 능력이 최대 85%까지 급격히 하락합니다. * **노이즈로 인한 판단력 저하**: 질문과 유사해 보이지만 실제로는 관계없는 정보(노이즈)가 섞이면 모델이 당당하게 가짜 정보를 생성하는 환각 현상이 빈번해집니다. * **토큰 소모 효율성**: LLM은 이전 대화를 기억하지 못하는 스테이트리스(stateless) 구조이므로, 대화가 길어지고 API의 JSON 응답이 누적되면 64K 토큰 정도의 용량은 순식간에 소모되어 비용과 성능에 악영향을 줍니다. ### 도구 선별을 통한 컨텍스트 절약 * **선별적 로드**: 260개의 모든 API 도구를 한 번에 컨텍스트에 올리지 않고, 사용자의 질문에서 제품군(예: Redis, Kubernetes)을 먼저 식별합니다. * **도구 최적화**: 사용자가 특정 제품에 대해 물을 때만 관련된 소수의 도구(API)만 선별하여 제공함으로써 모델의 인지 부하를 획기적으로 줄입니다. ### 응답 가이드라인과 점진적 공개 전략 * **상황별 지침 주입**: "리소스 변경 시 UI 안내 우선"과 같이 특정 조건에서만 필요한 운영 지침을 '응답 가이드라인'으로 정의하고, 질문의 성격에 따라 필요한 시점에만 선택적으로 로드합니다. * **시스템 프롬프트와 가이드라인의 분리**: 모든 상황에 적용되는 '대원칙'은 시스템 프롬프트에, 특정 상황의 '행동 절차'는 가이드라인에 배치하여 관리 효율을 높입니다. ### 모의 도구 메시지(ToolMessage)를 활용한 환각 방지 * **프롬프트 충돌 문제**: 새로운 가이드라인을 단순히 시스템 프롬프트 뒤에 추가할 경우, 모델이 기존의 대원칙(예: "반드시 검색 결과로만 답변하라")을 무시하고 가이드라인에만 매몰되어 환각을 일으키는 현상이 발생했습니다. * **도구 메시지 전략**: 가이드라인을 시스템 프롬프트에 넣는 대신, 마치 검색 도구를 실행해서 얻은 결과값인 것처럼 '도구 메시지(ToolMessage)' 형식으로 주입합니다. * **전략의 효과**: 이 방식을 통해 LLM은 시스템 프롬프트의 대원칙을 준수하면서도, 주입된 가이드라인을 도구로부터 얻은 최신 정보로 인식하여 훨씬 정확하고 일관된 답변을 생성하게 됩니다. 엔터프라이즈 LLM 서비스의 핵심은 모델의 지능을 믿고 모든 데이터를 던져주는 것이 아니라, 모델이 가장 똑똑하게 판단할 수 있도록 최적의 정보만 정교하게 큐레이션하여 전달하는 설계 능력에 있습니다. 특히 복잡한 비즈니스 로직이나 사내 고유 지식을 반영해야 할 때는 시스템 프롬프트를 비대하게 만드는 대신, 도구 메시지나 동적 컨텍스트 주입 기술을 활용해 모델의 판단 체계를 보호하는 것이 실질적인 해결책이 됩니다.

dropbox원문

Dash가 더 스마트한 AI를 위해 (새 탭에서 열림)

Dropbox Dash는 단순한 검색 시스템을 넘어 사용자의 의도를 이해하고 실행하는 에이전트형 AI로 진화하면서, 모델에 제공되는 정보를 정교하게 관리하는 '컨텍스트 엔지니어링'을 핵심 전략으로 채택했습니다. 단순히 많은 정보를 제공하는 것이 아니라 모델이 추론하고 행동하는 데 꼭 필요한 정보만을 선별하여 전달함으로써, AI의 '분석 마비' 현상과 토큰 낭비를 방지했습니다. 결과적으로 이러한 전략적 컨텍스트 관리는 모델의 판단 속도와 작업 정확도를 동시에 높이는 성과를 거두었습니다. ### 도구 정의의 최소화와 통합 인터페이스 구축 * 모델에게 너무 많은 API 호출 선택지를 주면 판단 속도가 느려지고 정확도가 떨어지는 현상이 발생했습니다. 이를 해결하기 위해 개별 서비스(Confluence, Jira, Google Docs 등)의 검색 도구를 하나로 묶은 '유니버설 검색 인덱스' 기반의 단일 도구를 구축했습니다. * Model Context Protocol(MCP)을 활용하여 도구 설명을 간결하게 유지함으로써, 모델의 컨텍스트 창(Context Window)이 사용자 요청이라는 본연의 목적에 더 많이 할애되도록 설계했습니다. * 하나의 일관된 인터페이스를 통해 정보를 검색하게 함으로써 모델의 계획 수립 과정을 단순화하고 효율성을 극대화했습니다. ### 지식 그래프를 통한 맥락적 데이터 필터링 * 단순히 여러 API에서 데이터를 가져오는 것에 그치지 않고, 검색된 결과 중 가장 관련성 높은 정보만 모델에 전달되도록 필터링 시스템을 강화했습니다. * 통합 인덱스 위에 사람, 활동, 콘텐츠 간의 관계를 연결한 '지식 그래프'를 구축하여 사용자별 맞춤형 순위 산출이 가능하게 했습니다. * 모델이 런타임에 방대한 정보를 직접 분석하는 대신, 이미 관계가 정립된 고가치 정보만 수신함으로써 추론의 질을 높이고 성능 저하를 방지했습니다. ### 복잡한 작업을 위한 전담 에이전트 도입 * 검색 쿼리 생성과 같이 복잡한 지침과 예시가 필요한 작업은 메인 모델의 컨텍스트 창을 과도하게 점유하는 문제를 일으켰습니다. * 이를 해결하기 위해 메인 에이전트는 전체적인 계획만 세우고, 구체적인 쿼리 작성은 별도의 '전담 에이전트'에게 위임하는 구조를 도입했습니다. * 역할 분담을 통해 메인 모델은 복잡한 세부 사항에 매몰되지 않고 전체 작업의 흐름에 집중할 수 있으며, 각 에이전트는 자신에게 할당된 컨텍스트 내에서 최적의 결과를 도출합니다. 효과적인 에이전트형 AI를 구축하기 위해서는 무조건 많은 데이터를 입력하기보다 모델이 처리해야 할 정보의 양과 질을 전략적으로 제어해야 합니다. 도구의 통합, 지식 그래프 기반의 정교한 필터링, 그리고 전문 에이전트로의 역할 분담은 성능 향상과 비용 절감을 동시에 달성할 수 있는 실무적인 context engineering 방안이 될 것입니다.