Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 에이전트의 핵심 요소인 '컨텍스트'를 단순 입력값을 넘어, 코드처럼 관리하고 버전화하며 수명주기(생성-평가-배포-관찰)를 거쳐야 함을 강조합니다. 컨텍스트는 이제 제품 기능 그 자체가 되며, 조직 지식으로 축적되는 것이 중요해졌습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AGENTS.md는 여러 도구에서 재사용할 수 있는 지침 형식으로 표준화가 진행 중임
CLAUDE.md를 사용하며, 이를 둘러싼 PR 논의도 있음
Context7과 Ref는 코드 의존성을 바탕으로 사용하는 라이브러리와 버전에 맞는 문서와 정보를 가져옴
MCP 커넥터는 Slack 등 엔지니어가 의사결정과 논의의 근거를 찾는 정보원에 접근함
명세는 단순 프롬프트보다 구조화된 작업 의도를 전달함
Kiro는 작업 명세 중심으로, SpecKit은 프로젝트에 계속 유지하는 제품 기능 중심으로 접근함
Baruch의 의도 무결성(intent integrity)은 실행 중에도 명세를 검증하는 접근임
사람의 역할은 문서, 코드, 지침, 규칙을 관리하는
컨텍스트 큐레이터로 바뀜
실제로 무엇을 가져올지는 에이전트가 결정하더라도, 최신의 올바른 정보에 접근할 수 있도록 준비해야 함
SWE-bench 같은 벤치마크는 작업 입력과 수행 결과를 비교하는 테스트 사례의 출발점이 됨
모델을 직접 만드는 사람이 아니더라도, 같은 방식을 컨텍스트 평가에 사용할 수 있음
Docker 컨테이너에서 코딩 에이전트를 실행하고 결과를 테스트해 컨텍스트 유무, 이전 버전과 새 버전을 비교할 수 있음
첫 단계는
린팅과 구조 검증임
스킬의 YAML 메타데이터에 필수 항목이 있는지, 문법이 올바른지, 설명 필드가 명세상 길이 제한을 지키는지 확인함
다음 단계는
LLM 심사자(LLM-as-a-judge) 를 통한 작성 품질 검토임
Grammarly처럼 문체와 표현을 검토하고, 지나치게 짧은 설명이나 뒤섞인 지시가 해당 모델에 효과적인지 피드백을 받을 수 있음
기능 평가는 스킬이 의도한 작업을 실제로 완료하는지 검사함
컨텍스트 수정 후 결과가 개선되는지 비교하되, 일부 테스트의 개선이 다른 테스트의 실패를 유발할 수 있음
Vercel처럼 라이브러리 제공자가 모델별 작동 결과와 필요한 정보, 모범 사례를 시험하고 테스트 하네스를 제공하는 움직임도 있음
라이브러리는 사람뿐 아니라 에이전트의 사용에도 최적화해야 하며, 오늘 모델이 실패한 작업도 이후 모델에서는 성공할 수 있음
최종적으로는
자체 코드베이스의 종단 간 테스트가 필요함
특정 커밋에서 시작해 프롬프트를 주고, 목표 작업이 완료됐는지 테스트하는 시나리오를 구축함
독립적인 합성 검사만으로는 실제 저장소에서의 유효성을 보장할 수 없음
테스트가 있어야 컨텍스트를 체계적으로 최적화할 수 있음
모델이 이미 아는 정보는 효과 없이 컨텍스트 창만 차지할 수 있으므로 제거 후보가 됨
서로 충돌하는 지침을 찾고, 새 에이전트를 설치했을 때 기존 컨텍스트가 왜 작동하지 않는지 재검증할 수 있음
실제 사용 중 Claude Code가 잘못 수행한 작업을
회귀 테스트 사례로 남길 수 있음
컨텍스트가 없는 상태와 개선한 컨텍스트를 적용한 상태를 비교해 수정 효과를 확인함
로컬에서는 일부 테스트로 빠르게 피드백을 받고, 이후 범위를 넓혀 CI/CD에 통합할 수 있음
컨텍스트 변경은 다른 평가를 깨뜨릴 수 있고, 실행 결과도
비결정적임
같은 테스트를 가령 다섯 번 실행해 대체로 성공하는지 판단하는 방식이 필요할 수 있음
평가의 98%가 통과했을 때 출시할지는 단순한 테스트 통과 여부가 아니라 위험 수용의 결정임
오류 예산(error budget) 처럼 기능별 허용 실패 수준을 다르게 정할 수 있음
반드시 통과해야 하는 평가와 어느 정도 변동을 허용할 평가를 구분함
제품 책임자가 출시 여부를 판단해야 하는 상황도 생김
공급업체의
기본 제공 평가 지표만으로 검증을 끝내서는 안 됨
깨끗하게 통제된 환경이 아니라 자신의 코드와 운영 환경에서 의미 있는 평가인지 확인해야 함
AI로 평가를 생성할 수 있지만, 충분한 컨텍스트를 주고 생성된 테스트의 적절성을 검토해야 함
Slack 복사와 붙여넣기를 넘어
재현 가능한 배포 방식이 필요함
GitHub 저장소에 컨텍스트를 넣으면 프로젝트와 함께 받을 수 있음
Git 서브모듈은 별도 갱신을 잊기 쉽고, 한 저장소에 모으는 방식도 여러 프로젝트 사이의 재사용 문제를 남김
코드 라이브러리처럼
패키지 관리자와 레지스트리로 컨텍스트를 배포할 수 있음
npm 패키지와 유사하게 버전을 지정해 설치하고 갱신함
사용하는 라이브러리 버전에 맞는 컨텍스트, 팀 규칙, 프런트엔드용 패키지 등을 조합할 수 있음
SKILL.md하나를 공유하는 것만으로는 실제 코드베이스에서의 동작을 알기 어려움
AGENTS.md의 표준화처럼, 스킬 형식은 지침과 규칙을 여러 도구에서 교환하고 재사용하는 기반이 될 수 있음
AI 구성 명세서(AI Bill of Materials) 처럼 누가, 언제, 왜, 어떻게 컨텍스트를 만들었는지 추적할 수 있음
GitHub 주석을 활용하면 커밋한 사람만 보는 데 그치지 않고 코드가 AI로 작성됐는지도 구분할 수 있음
출처 정보는 코드 라이브러리와 마찬가지로 신뢰 판단의 근거가 됨
변경과 작업을
트랜잭션 로그처럼 기록하면 출처 추적을 넘어 새로운 컨텍스트가 됨
몇 단계 전에 누가 무엇을 했고 왜 그렇게 했는지 에이전트가 읽을 수 있는 작업 이력을 제공함
에이전트가 실패 로그를 살펴보고 지침을 다시 작성하는
자기 개선 루프를 만들 수 있음
Hugging Face는 코드베이스에서 수행한 작업의 좋고 나쁜 점을 에이전트가 회고하게 하고, 결과를 다시 입력으로 사용함
개선한 컨텍스트를 재패키징해 레지스트리에 올리면 다른 에이전트에도 다음 반복부터 배포할 수 있음
이는 합성 평가를 넘어
실제 사용 사례에 기반한 피드백임
여러 도구가 관찰 계층을 활용하면서 로그 형식의 표준화도 중요해짐
OpenTelemetry처럼 공통 형식을 여러 도구가 활용하는 것이 이상적이며, Devin도 자기 성찰 루프를 구축하고 있음
코드 리뷰와 Slack 대화 역시 관찰 데이터임
Hud는 코드를 계측해 운영 중 사건이 발생했을 때 영향을 받은 코드 줄을 수집함
샌드박스 안에서도 의도하지 않은 행동을 관찰해야 함
알려지지 않은 엔드포인트 접근, 환경 변수나 메모리의 정보 접근, DNS를 통한 데이터 유출 같은 시도도 관찰 대상임
이 사례에는 과장된 부분이 있지만, 정상 작업의 로그만 보는 것으로는 충분하지 않음
네트워크 격리만으로는 에이전트가 시작할 때 자동으로 읽는
CLAUDE.md
의 내용까지 통제할 수 없음
공유 라이브러리로 파일 읽기 호출을 가로채 디스크에서 읽는 내용을 검사하는
컨텍스트 방화벽 개념 증명을 구현함
eBPF로도 이런 접근이 가능하지만, 해당 Mac 환경에서는 사용할 수 없었음
컨텍스트 방화벽은 프롬프트 인젝션뿐 아니라 기존 지침을 덮어쓰는 다른 방식도 검사할 수 있음
웹 애플리케이션 방화벽처럼 규칙 작성이 번거롭고 잡음이 많을 수 있음
차단하지 않고 기록만 하더라도 에이전트가 무엇을 읽는지 피드백을 얻을 수 있음
OpenAI는 앱 로그와 Codex 문제를 연결해 모델 학습에도 활용함
명세를 넣으면 코딩 에이전트들이 소프트웨어를 만드는
다크 팩토리(dark factory) 접근도 있음
Google, Okta, Jira 등을 흉내 내는 디지털 트윈으로 동작을 검증하고, 에이전트가 자신의 작업 결과를 관찰하게 함
에이전트 관리에는 여러
개입 수준이 있음
매 단계마다 사람이 세부 지시를 내릴 수 있음
명세를 전달하고 생성된 결과를 사람이 리뷰할 수 있음
여러 에이전트가 작업과 상호 비판을 수행하고, 의견이 갈릴 때 사람이 결정할 수도 있음
야간에도 자율 실행하되 해결하지 못하는 충돌이 생길 때만 사람을 호출하는 방식도 가능함
중요한 것은 가장 높은 자율성이 아니라
상황에 맞는 관리 방식임
실패해서는 안 되는 작업에는 사람이 깊이 개입해야 함
위험이 낮고 익숙한 상황이며 가드레일이 갖춰졌다면 더 많은 자율성을 허용할 수 있음
높은 자동화 수준에서도
온콜과 사람의 의사결정은 남음
에이전트를 맹목적으로 신뢰하는 대신 자신의 사업이 감수할 위험을 판단해야 함
개발자는 코드 작성 외에
운영, QA 설계, 제품 결정, 데이터 관리 역할을 맡게 됨
에이전트를 운영하고 결과를 판단하며, 명세로 원하는 동작을 규정함
무엇을 만들지 결정하고, 여러 개념 증명을 비교해 좋은 결과를 선택할 수 있음
수집한 데이터를 지식으로 전환하는 역할도 중요해짐
AI는 기존의
좋은 엔지니어링 관행을 수행할 직접적인 동기를 만듦
테스트가 있어야 에이전트가 만든 코드의 품질을 판단할 수 있음
좋은 컨텍스트를 작성하면 에이전트의 작업 품질이 좋아지고 리뷰 부담이 줄어듦
엔지니어링 리더도 지침을 컨텍스트로 배포해 더 넓은 범위에 적용할 수 있음
개인이 해결한 문제와 모범 사례를
동료와 동료의 에이전트에 공유하면 같은 문제의 반복을 줄일 수 있음
AI가 할 수 없다고 보는 작업도 수행에 필요한 컨텍스트를 작성해보는 참여 기회가 될 수 있음
플랫폼 팀이 지침을 컨텍스트로 배포하면 여러 팀으로 확장할 수 있으며, 구성원 모두가 일부 컨텍스트에 기여할 수 있음
CLAUDE.md와 스킬에도 명확한 소유권이 필요함
라이브러리나 마이크로서비스처럼 해당 정보를 가장 잘 관리할 팀이 책임져야 함
누구나 규칙을 제안하되, 지정된 구성원만 전사 배포를 승인하는 방식도 있음
컨텍스트 변경에도 PR 처리와 승인 절차가 필요함
성숙도는
도구와 조직 관행을 각각 평가해야 함
에이전트가 코딩뿐 아니라 컨텍스트 생성과 적절한 컨텍스트 확보를 얼마나 잘 지원하는지 확인함
팀이 테스트를 적용하는지, 검증 없이 배포하는지도 별개의 문제임
관리자는
공유 플랫폼, 교육, 도구, 실천 방식을 제공해야 함
팀이 컨텍스트를 쉽게 발행하고 재사용할 수 있게 지원함
문제가 생겼을 때 “컨텍스트를 갱신했는가?”를 자연스럽게 확인하는 습관이 필요함
@Claude에 수정과 PR 생성을 요청하고, 사람이 승인 여부를 결정하는 사례가 있음
컨텍스트 드리프트는 지속적으로 관리해야 함
모델이 바뀌면 기존 컨텍스트의 효과도 달라질 수 있고, 과거 지침이 더 이상 적절하지 않을 수 있음
여러 개발자가 지침을 거부하는 신호를 AI가 찾아 재검토 논의를 도울 수 있음
사람마다 서로 다른 버전의 컨텍스트를 사용하는 문제는 아직 해결되지 않음
다음 영역은
아직 탐색이 필요한 과제임
컨텍스트 카오스 엔지니어링은 잘못된 컨텍스트를 주입해 탐지와 복원력을 확인하는 접근임
컨텍스트 분석에서는 다운로드 수와 실제 활용 효과 중 무엇을 측정할지 정해야 함
두 팀에 새 컨텍스트를 시험한 뒤 전체로 확장하는 A/B 테스트도 탐색 대상임
컨텍스트를 위한 차세대 GitHub나 Kubernetes에 해당하는 플랫폼도 탐색 과제로 남아 있음
에이전트가 관리 작업까지 도울 수 있어도
책임과 위험 판단은 사람에게 남음
일부 결정은 여전히 사람이 내려야 하며, 에이전트끼리 사람이 읽기 어려운 언어로 컨텍스트를 공유하게 될 가능성에 대한 우려도 남아 있음
중요한 것은 파일의 양이 아니라 그 안에 담긴
구체적이고 유효한 지식임
기업의 경쟁우위는 코드 자체보다
사업을 이해하는 올바른 컨텍스트에 있을 수 있음
유사한 GitHub 저장소 다섯 개의 기능을 추출해 자신의 프로젝트에 반영하도록 요청할 수는 있음
하지만 무엇을 만들고 어디로 나아가야 하는지에 대한 사업적 이해까지 복사할 수 있는 것은 아님
코딩 에이전트가 엔진이라면
컨텍스트는 연료임
적절한 컨텍스트를 제공하지 않으면 에이전트가 제대로 작동하지 못하거나 기대 이하의 성능을 낼 수 있음
컨텍스트에 적합한 언어는
모델의 학습 데이터에 영향을 받음
널리 쓰이는 모델은 영어 학습 비중이 높으며, 임베딩이 언어 간 유사성을 연결하더라도 어려움이 생길 수 있음
스페인어로 작성된 스킬을 검토할 때도 언어 선택이 적절한지 문제가 됐으며, 모든 언어가 동일하게 작동한다고 보기는 어려움
레거시 환경에서는 해당 프로그래밍 언어에 대한
모델의 학습 수준부터 확인해야 함
일부 AI 코딩 공급업체는 사용자가 적은 언어에 특화해 학습하며, 적절한 컨텍스트도 대체로 성능을 높이는 데 도움이 됨
은행 같은 환경의
자동 프로덕션 배포는 테스트와 가드레일, 위험 수용 수준에 달려 있음
신입 개발자가 첫날 배포할 수 있는지를 판단할 때처럼 테스트뿐 아니라 주변 안전장치가 중요함
적절한 조건에서 자동 배포가 가능한 사례는 있을 수 있지만, 무조건적인 자동 배포에는 신중해야 함
그 위험을 받아들일 의사가 없다면 자동 배포하지 않아야 함