# Thoughtworks Technology Radar, Volume 34 공개 > Clean Markdown view of GeekNews topic #28625. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28625](https://news.hada.io/topic?id=28625) - GeekNews Markdown: [https://news.hada.io/topic/28625.md](https://news.hada.io/topic/28625.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-17T10:34:02+09:00 - Updated: 2026-04-17T10:34:02+09:00 - Original source: [thoughtworks.com](https://www.thoughtworks.com/radar) - Points: 4 - Comments: 0 ## Topic Body - **테크닉/도구/플랫폼/개발언어 및 프레임워크** 분야 최신 트렌드를 "도입 권장, 시험 사용, 평가, 주의" 4단계로 시각화 및 설명 - 핵심 테마 4개: 에이전트 시대와 기술 평가, 원칙은 유지하되 패턴은 재검토, 에이전트의 보안 문제, 코딩 에이전트 하네스 ### 에이전트 시대와 기술 평가의 난제 - AI 도입으로 기술 평가 자체가 어려워지고 있으며, **시맨틱 확산(semantic diffusion)** 으로 인해 의미가 안정되기 전에 새 용어가 빠르게 등장 - spec-driven development, harness engineering 등 용어가 일관되지 않게 사용되거나 의미가 겹침 - 공유된 정의 부재로 별개 기법인지 같은 개념의 다른 이름인지 판단 곤란 - 성숙한 독립 엔지니어링 방법론과 코딩 어시스턴트 같은 **AI 도구의 일상적 사용**을 구분하는 것이 지속적 난제 - 변화 속도가 불확실성을 가중, **한 달도 안 된 도구**들이 다수 등장하며 일부는 단일 기여자가 코딩 에이전트와 함께 유지하는 형태 - 도구 성숙을 기다리면 가이드가 낡고, 빠르게 움직이면 금방 사라질 트렌드를 부각할 위험 - 빠르고 적은 노력으로 만들어지는 것들의 **지속 가능성** 문제 제기 - 코드베이스 인지 부채(Codebase Cognitive Debt) - AI 생성 코드가 늘수록 **작동 원리에 대한 멘탈 모델 없이** 솔루션을 채택하기 쉬워짐 - 이러한 이해 격차가 누적되면 시스템을 추론·디버그·발전시키기 어려워짐 ### 원칙은 유지하되 패턴은 재검토 - AI가 미래만이 아니라 **소프트웨어 크래프트맨십의 기초**를 다시 돌아보게 만드는 중 - 페어 프로그래밍, **제로 트러스트 아키텍처**, 뮤테이션 테스팅, DORA 메트릭 등 기존 기법 재조명 - 클린 코드, 의도적 설계, 테스트 가능성, 접근성 등 핵심 원칙을 일급 관심사로 재확인 - 향수가 아닌, AI 도구가 복잡성을 빠르게 생성하는 속도에 맞서는 **필수적 균형추** 역할 - **커맨드라인의 부활**, 수년간 사용성을 위해 추상화되어 왔으나 agentic 도구가 개발자를 터미널로 되돌아오게 함 - AI 지원 개발은 엔지니어링 실천의 근본적 전환으로, 협업과 팀 구조 재고 필요 - **agent topologies**를 team topologies와 나란히 고려하고 피드백 주기 재설계 필요 - **measuring collaboration quality with coding agents** 같은 기법이 소프트웨어 개발자의 정의 자체를 재규정 - AI 주도 환경에서 **인지 부채 관리**가 핵심 과제, "규율 없는 속도는 비용을 가중시킨다"는 원칙 유지 중요 ### 권한을 탐하는 에이전트의 보안 문제 - **"Permission hungry"** 는 지금 에이전트 상황의 본질적 딜레마를 묘사, 가치 있는 에이전트일수록 모든 것에 접근 필요 - **OpenClaw**, Claude Cowork는 실제 업무 감독 - **Gas Town**은 코드베이스 전체에 걸쳐 에이전트 스웜 조율 - 사적 데이터, 외부 통신, 실제 시스템에 대한 광범위한 접근 요구 - 안전장치가 이 야심을 따라잡지 못한 상태, 프롬프트 인젝션으로 모델이 **신뢰 명령과 비신뢰 입력을 안정적으로 구분 불가** - Simon Willison의 **"lethal trifecta"** 정의 — 사적 데이터, 비신뢰 콘텐츠, 외부 행동 — 이 오설정이 아닌 **기본값으로** 대부분의 유용한 에이전트에 해당 - 인젝션 외의 위협도 존재, 모델 동작의 비일관성 - 한 번 성공한 작업이 다음에도 성공한다는 보장 없음 - 에이전트가 악의 없이도 **창의적 유출 경로**를 찾고, 건드리면 안 될 브랜치에 푸시하며, 승인/거부 체크포인트 무력화 - 현재 대응 가능한 것 — **제로 트러스트**, 최소 권한, 모델 개선, 심층 방어가 기본 조건이나 단일 해법 부재 - 안전한 에이전트 시스템은 모놀리식 에이전트가 아닌 **더 제약된 에이전트들의 파이프라인**, 강력한 모니터링·제어로 구성 필요 - **Agent Skills**를 MCP의 통제 가능한 대안으로 활용 - durable agents, **agent instruction bloat** 방지 기법 등이 이 방향성 제시 - 공간이 빠르게 진화 중이므로 **비용 큰 실수 회피**를 위해 신중함 필수 ### 코딩 에이전트에 고삐 채우기 - 코딩 에이전트 성능 향상으로 인간이 루프에서 빠지려는 유혹 증가, 이에 팀들이 **coding agent harnesses** 투자 시작 - 코드 생성 전 에이전트 행동을 유도하고 이후 피드백으로 자기 수정 가능하게 하는 통제 장치 - Feedforward 통제 - 에이전트가 **첫 시도에 정답 확률**을 높이도록 필요한 것을 미리 제공 - **Agent Skills**가 주요 진전으로, 지시와 관례를 모듈화하고 필요 시점에 로드 - **Superpowers**는 소프트웨어 팀을 위한 유용한 스킬 카탈로그 예시 - **plugin marketplaces** 개념 부상으로 스킬과 컨텍스트 구성 배포 용이화 - **spec-driven development** 프레임워크 — **GitHub Spec-Kit**, **OpenSpec** 등이 계획·설계·구현 워크플로우 구조화 - Feedback 통제 - 에이전트 행동 후 관찰하여 자기 수정 루프 생성 - **feedback sensors for coding agents** — 컴파일러, 린터, 타입 체커, 테스트 스위트 같은 **결정론적 품질 게이트**를 에이전트 워크플로우에 직접 통합 - 실패 시 인간 리뷰 전 자동 수정 트리거 - 이번 Radar의 예시로 **cargo-mutants** 와 뮤테이션 테스팅 도구, **WuppieFuzz** 같은 퍼즈 테스팅 도구, **CodeScene** 등 코드 품질 분석 도구 포함 - 인-루프 피드백 외에, 결정론적 구조 규칙과 **LLM 기반 평가**를 결합해 아키텍처 드리프트 감소 사례도 존재 --- ### [Techniques] #### Adopt **1. Context engineering** - 현대 AI 시스템의 핵심 아키텍처 관심사로 진화한 기법으로, 프롬프트 엔지니어링이 문구에 집중하는 것과 달리 컨텍스트 윈도우를 설계 표면으로 다루고 AI의 정보 환경을 의도적으로 구축 - 에이전트가 복잡한 작업을 처리할수록 대형 컨텍스트 윈도우에 원시 데이터를 쏟아붓는 방식은 "context rot"과 추론 저하 초래, 정적·모놀리식 프롬프트에서 [progressive context disclosure](https://www.thoughtworks.com/radar/techniques/progressive-context-disclosure)로 전환 중 - Context setup은 [prompt caching](https://www.anthropic.com/news/prompt-caching)으로 정적 지시를 선로딩해 비용 절감 및 첫 토큰 시간 개선, Dynamic retrieval은 기본 RAG를 넘어 [도구 선택](https://huggingface.co/papers/2411.10�953)과 필요한 MCP 서버만 로드 - [Context graphs](https://www.thoughtworks.com/radar/techniques/context-graph)는 정책, 예외, 선례 등 기관적 추론을 구조화·쿼리 가능한 데이터로 모델링, [stateful compression](https://cognition.ai/blog/dont-build-multi-agents)과 서브 에이전트로 장기 워크플로우에서 중간 출력 요약 - AI 컨텍스트를 정적 텍스트 박스로 취급하는 것은 환각으로 가는 지름길, **견고한 엔터프라이즈 에이전트 구축을 위해 컨텍스트를 동적이고 정밀하게 관리되는 파이프라인으로 엔지니어링해야 함** **2. Curated shared instructions for software teams** - 개별 개발자가 처음부터 프롬프트를 작성하는 것을 안티패턴으로 보고, AI 가이던스를 **개인 워크플로우가 아닌 협업 엔지니어링 자산**으로 다루는 실천법 - 초기에는 공통 작업용 범용 프롬프트 라이브러리 유지에 집중했으나, 이제 **서비스 템플릿에 직접 지시를 앵커링**하는 진화된 방식으로 발전 - `CLAUDE.md`, `AGENTS.md`, `.cursorrules` 같은 지시 파일을 새 서비스 스캐폴딩용 베이스라인 리포지토리에 배치 - 코딩 에이전트를 **레퍼런스 애플리케이션에 앵커링**하는 관련 실천법도 탐색, 살아있는 컴파일 가능한 코드베이스가 단일 진실 공급원 역할 - 아키텍처와 코딩 표준 진화 시 레퍼런스 앱과 임베디드 지시 모두 업데이트 가능, 새 리포지토리는 최신 에이전트 워크플로우와 규칙을 기본 상속 **3. DORA metrics** - [DORA 연구](https://dora.dev/) 프로그램이 정의한 메트릭으로, 변경 리드 타임, 배포 빈도, MTTR, 변경 실패율, 그리고 새로운 다섯 번째 메트릭인 **rework rate** 포함 - Rework rate는 안정성 메트릭으로 팀 전달 파이프라인이 사용자 버그나 결함 같은 **기완료 작업의 재작업에 소비되는 비율** 측정 - AI 지원 개발 시대에 DORA 메트릭은 그 어느 때보다 중요, AI 생성 코드 라인 수로 [생산성을 측정](https://martinfowler.com/articles/measuring-developer-productivity-humans.html)하는 것은 오해를 일으킴 - 리드 타임 감소와 배포 빈도 증가 없이는 빠른 코드 생성이 더 나은 결과로 이어지지 않음 - 안정성 메트릭, 특히 rework rate 저하는 무분별한 AI 지원 개발의 맹점·기술 부채·위험을 조기 경고 - 복잡한 대시보드 구축보다 **회고 중 체크인 같은 단순 메커니즘**이 역량 개선에 더 효과적 **4. Passkeys** - FIDO Alliance가 주도하고 Apple, Google, Microsoft가 지원하는 FIDO2 자격 증명으로 비대칭 공개키 암호화를 사용해 비밀번호 대체 - 프라이빗 키는 사용자 기기의 하드웨어 기반 보안 엔클레이브에 저장, 생체 인식이나 PIN으로 보호되며 외부로 유출되지 않음, 각 자격 증명은 릴레잉 파티 도메인에 원본 바인딩되어 **구조적으로 피싱 저항성** 보유 - 피싱이 전체 데이터 침해의 1/3 이상 원인, [FIDO Alliance Passkey Index 2025](https://fidoalliance.org/)는 전 세계 150억 개 이상의 적격 계정 보고, Google은 8억 사용자 전반에서 로그인 성공률 30% 개선, Amazon은 기존 방식 대비 6배 빠른 로그인 확인 - NIST SP 800-63-4(2025년 7월)는 synced passkeys를 AAL2 준수로 재분류, UAE·인도·미국 연방 기관 규제당국은 금융·정부 시스템에 피싱 저항 인증 의무화 - FIDO Credential Exchange Protocol로 자격 증명 관리자 간 안전한 이식성 확보, Auth0·Okta·Azure AD 주요 ID 공급자가 일급 기능으로 지원, 구현이 수개월 작업에서 **2개 스프린트 프로젝트**로 단순화 - 계정 복구 설계에 주의하고 SMS OTP 같은 피싱 가능 폴백 경로 회피 필요 - AAL3 시나리오(권한 접근 등)에는 하드웨어 보안 키의 디바이스 바인딩 자격 증명 여전히 필요 **5. Structured output from LLMs** - 모델을 JSON이나 특정 프로그래밍 언어 클래스 같은 **사전 정의된 형식으로 응답하도록 제약**하는 실천법 - 프로덕션에서 신뢰할 수 있는 결과 제공, LLM 응답을 프로그램적으로 소비하는 애플리케이션의 **합리적 기본값**으로 간주 - 모든 주요 모델 공급자가 네이티브 구조화 출력 모드 제공, 지원하는 JSON Schema 서브셋이 다르고 API가 빠르게 진화 - [Instructor](https://github.com/567-labs/instructor) 라이브러리나 [Pydantic AI](https://ai.pydantic.dev/) 프레임워크로 검증과 자동 재시도 포함한 안정적 추상화 제공, 자체 호스팅 모델의 제약 생성에는 [Outlines](https://github.com/dottxt-ai/outlines) 권장 **6. Zero trust architecture** - 에이전트 시대 진입에 따라 예측 불가능한 시스템에 자율성 부여 시 보안 위험 대응의 합리적 기본값 - **"절대 신뢰하지 말고, 항상 검증하라"**, 정체성 기반 보안, 최소 권한 접근 원칙을 **모든 에이전트 배포의 기반**으로 취급 - [SPIFFE](https://spiffe.io/) 같은 표준을 에이전트에 적용해 강력한 정체성 기반 구축, 동적 환경에서 세밀한 인증 활성화 - 에이전트 동작의 지속적 모니터링·검증이 위협 선제 관리에 중요 - 에이전트 배포 외에도 GCP의 [OIDC impersonation](https://cloud.google.com/iam/docs/workload-identity-federation) 같은 실천법을 [CI/CD 파이프라인](https://github.com/google-github-actions/auth) 등에 도입, 장기 정적 키를 정체성 검증 후 발급되는 단기 토큰으로 대체 - **구축 시스템과 무관하게 ZTA 원칙을 협상 불가능한 기본값**으로 취급 권장 #### Trial **7. Agent Skills** - AI 에이전트가 단순 챗 인터페이스에서 자율 작업 실행으로 진화하며 컨텍스트 엔지니어링이 핵심 과제가 됨, [Agent Skills](https://www.anthropic.com/news/skills)는 지시, 실행 가능 스크립트, 문서 같은 관련 리소스를 패키징해 **컨텍스트 모듈화를 위한 오픈 표준** 제공 - 에이전트는 설명 기반으로 필요할 때만 스킬 로드, 토큰 소비 감소 및 컨텍스트 윈도우 고갈과 [agent instruction bloat](https://www.thoughtworks.com/radar/techniques/agent-instruction-bloat) 문제 완화 - 코딩 에이전트뿐 아니라 [OpenClaw](https://www.thoughtworks.com/radar/tools/openclaw) 같은 개인 비서에도 빠르게 채택, 많은 사용 사례가 로컬 CLI나 스크립트를 에이전트가 가리키게 하는 것으로 효과적으로 해결 가능해 팀들이 **MCP 기본 사용에 신중**해지는 이유 중 하나 - [Plugin marketplaces](https://www.thoughtworks.com/radar/tools/claude-code-plugin-marketplace)가 스킬을 버전 관리·공유하는 방식으로 부상, 스킬 효과성 평가 방법 탐색 다수 진행 중 - 제3자 스킬의 검토 없는 재사용은 **심각한 공급망 보안 위험** 유발하므로 주의 필요 **8. Browser-based component testing** - 과거에는 브라우저 기반 도구를 권장하지 않았으나(설정 어렵고 느리며 flaky), 현재는 크게 개선되어 [Playwright](https://playwright.dev/) 같은 도구로 **실행 가능하고 선호되는 접근 방식** - 실제 브라우저에서 테스트 실행 시 코드가 실제로 실행되는 환경과 일치해 **더 높은 일관성** 제공 - 성능 저하는 감수할 만한 수준으로 감소, flakiness도 줄어 [jsdom](https://github.com/jsdom/jsdom) 같은 에뮬레이트 환경보다 더 많은 가치 제공 **9. Feedback sensors for coding agents** - 코딩 에이전트를 더 효과적으로 만들고 인간 리뷰어 부담을 줄이기 위해 에이전트가 직접 접근 가능한 피드백 루프 필요, 피드백 [backpressure](https://www.reactivemanifesto.org/glossary#Back-Pressure) 형태로 작용 - 개발자는 오랫동안 **컴파일러, 린터, 구조 테스트, 테스트 스위트** 같은 결정론적 품질 게이트에 의존, 이를 agentic 워크플로우에 연결해 실패 시 적시 자기 수정 트리거 - 체크 실행과 수정 트리거를 담당하는 리뷰어 에이전트 도입, 또는 병렬 실행되는 동반 프로세스로 체크 노출 등 다양한 구현 가능 - 코딩 에이전트 덕에 커스텀 린터와 구조 테스트 구축 비용 저렴해져 피드백 루프 강화 - 가능하면 **커밋 후 체크보다 코딩 세션 중 실행**, 커밋 전 깨끗한 결과 보고하도록 할 것 **10. Mapping code smells to refactoring techniques** - 에이전트에게 **정의된 접근 방식**으로 특정 이슈를 처리하도록 지시하는 기법 - 첫 번째 레이어는 일반적 케이스를 위해 [Refactoring](https://refactoring.com/) 같은 일반 참조로 에이전트 유도, 더 전문적 이슈는 Agent Skills, 슬래시 커맨드, `AGENTS.md`로 고유한 smell을 특정 기법에 매핑 - 린팅 도구와 통합 시 smell 감지 때마다 적절한 리팩토링 접근 방식 트리거하는 **결정론적 피드백** 생성 - .NET Framework 2.0이나 Java 8 같은 **레거시 스택**에서 특히 효과적, 일반 훈련 데이터가 부족한 경우 유용 - 목표 지시 없이는 에이전트가 특정 요구 사항 대신 일반 패턴으로 기본 설정하는 경향 **11. Mutation testing** - 테스트 스위트의 **실제 결함 감지 능력 평가**에 가장 정직한 신호, 라인 실행만 추적하는 전통적 코드 커버리지와 달리 소스 코드에 **의도적 버그(mutations)** 도입해 동작 파괴 시 테스트 실패 검증 - 변이가 감지되지 않으면 단순 커버리지 부족이 아닌 검증의 간극을 드러냄, **AI 지원 개발 시대**에 특히 중요 — 높은 커버리지가 논리적으로 공허한 테스트나 의미 있게 단언되지 않은 생성 코드를 가릴 수 있음 - AI 생성 테스트 케이스가 일반화되면서 누락된 단언이나 분리된 mock으로 로직 변경과 무관하게 통과하는 **"영원히 녹색(perpetually green)" 테스트**를 잡는 강화 레이어 역할 - [Stryker](https://stryker-mutator.io/), [Pitest](https://pitest.org/), [cargo-mutants](https://github.com/sourcefrog/cargo-mutants) 같은 도구로 코어 도메인 로직에서 **얼마나 많은 코드가 실제로 검증되는지**에 초점 이동 **12. Progressive context disclosure** - [Context engineering](https://www.thoughtworks.com/radar/techniques/context-engineering) 실천 내의 기법, 에이전트에게 지시를 선제적으로 압도하는 대신 **사용자 프롬프트 기반으로 필요한 것을 선택하는 경량 디스커버리 단계** 부여 - RAG 시나리오에 적합, 에이전트가 먼저 사용자 쿼리에서 관련 도메인 식별 후 특정 지시와 데이터 검색 - 많은 agentic 코딩 도구의 Agent Skills 처리 방식과 동일, **조건과 주의사항으로 가득 찬 단일 모놀리식 지시 세트** 대신 먼저 작업에 관련된 스킬 결정 후 상세 지시 로드 - agentic 시스템 구축 시 끝없는 "DO"와 "DO NOT" 규칙으로 [지시를 부풀리는 덫](https://www.anthropic.com/engineering/claude-code-best-practices)에 빠지기 쉬움, 이는 궁극적으로 성능 저하 - 컨텍스트 윈도우를 간결하게 유지하고 [context rot](https://research.trychroma.com/context-rot) 방지 **13. Sandboxed execution for coding agents** - 제한된 파일 시스템 접근, 통제된 네트워크 연결, 제한된 리소스 사용으로 **격리된 환경 내에서 에이전트 실행**하는 실천법 - 코딩 에이전트가 코드 실행·빌드·파일 시스템 상호작용 자율성을 얻으며, 무제한 접근은 우발적 손상부터 자격 증명 노출까지 실제 위험 초래, **선택적 향상이 아닌 합리적 기본값** - 샌드박싱 옵션 스펙트럼 광범위 — 많은 코딩 에이전트가 내장 샌드박스 모드 제공, [Dev Containers](https://www.thoughtworks.com/radar/tools/dev-containers)는 친숙한 컨테이너 기반 격리 제공 - [Shuru](https://shuru.sh/)는 매 실행 시 리셋되는 일회용 마이크로VM 부팅, [Sprites](https://www.thoughtworks.com/radar/platforms/sprites)는 체크포인트/복원 지원 상태 저장 환경 제공 - Linux 네이티브 격리에는 Bubblewrap이 경량 네임스페이스 기반 샌드박싱 제공, macOS에서는 `sandbox-exec`가 유사 보호 제공 - 기본 격리 외에도 빌드·테스트에 필요한 모든 것, GitHub과 모델 공급자 같은 서비스와의 안전하고 간단한 인증, 포트 포워딩, 충분한 CPU·메모리 고려 필요 - 샌드박스를 일회용 기본값으로 할지, 세션 복구를 위한 영구적으로 할지는 보안·비용·워크플로우 연속성 우선순위에 따른 설계 결정 **14. Semantic layer** - 데이터 저장소와 BI 도구, AI 에이전트, API 같은 소비 애플리케이션 사이에 **공유된 비즈니스 로직 레이어**를 도입하는 데이터 아키텍처 기법 - 메트릭 정의, 조인, 접근 규칙, 비즈니스 용어를 중앙화해 소비자가 공유된 정의 보유, 현대 데이터 스택 이전의 개념이지만 [metrics stores](https://www.getdbt.com/blog/semantic-layer-for-the-modern-data-stack) 같은 코드 우선 접근 방식으로 관심 재부상 - 세만틱 레이어 없으면 비즈니스 로직이 임시 웨어하우스 테이블, 대시보드, 다운스트림 애플리케이션 전반에 흩어지고 메트릭 정의 조용히 분기 - agentic AI로 문제 심화 — LLM으로 순진한 text-to-SQL 번역 수행 시 특히 수익 인식 같은 비즈니스 규칙이 스키마 밖에 있을 때 잘못된 결과 빈번 - 클라우드 플랫폼이 세만틱 레이어 직접 임베딩 중, Snowflake는 Semantic Views, [Databricks는 Metric Views](https://docs.databricks.com/aws/en/machine-learning/feature-store/metrics-views)로 호칭, [dbt MetricFlow](https://docs.getdbt.com/docs/build/about-metricflow)와 [Cube](https://cube.dev/) 같은 독립형 도구는 시스템 전반 이식 가능 레이어 제공 - [Open Semantic Interchange (OSI) v1.0](https://osi.dev/) 최근 출시, [다수 벤더](https://www.snowflake.com/en/blog/open-semantic-interchange/) 지원으로 분석·AI·BI 플랫폼 전반 표준화·상호운용성 확산 신호 - 주 비용은 선행 데이터 모델링 투자, 엔터프라이즈 전체 롤아웃보다 **단일 도메인부터 시작** 권장 **15. Server-driven UI** - 렌더링을 일반 컨테이너로 분리하고 서버를 통해 구조와 데이터 제공, 모바일 팀이 반복마다 긴 앱 스토어 리뷰 주기 우회 가능 - JSON 기반 형식으로 실시간 업데이트 활성화해 **출시 시간을 크게 개선**, Airbnb와 Lyft 같은 회사의 안정적 패턴 등장으로 복잡성 감소 - 이전에는 독점 프레임워크가 만들 수 있는 "끔찍하고 과도하게 구성 가능한 난장판" 경고, 대규모 애플리케이션에서 투자 정당화 쉬워짐 - 여전히 강력한 비즈니스 케이스와 절제된 엔지니어링 필요, 유지 어려운 **"신 프로토콜(god-protocol)"** 생성 방지 중요 - 애플리케이션의 모든 UI 개발 대체가 아닌 **고도로 동적인 영역**에 적용 권장 #### Assess **16. Agentic reinforcement learning environments** - LLM 기반 에이전트를 위한 훈련장으로 컨텍스트, 도구, 피드백을 결합해 **다단계 작업 완료** - [이 접근](https://arxiv.org/abs/2503.19326)은 LLM 사후 훈련을 단순 단일 턴 출력에서 추론과 도구 사용 같은 agentic 동작으로 재구성, 각 행동에 보상이나 페널티 할당 - [RLVR](https://arxiv.org/abs/2411.15124) 같은 기법으로 보상이 검증 가능하고 게임화에 저항하도록 보장 - AI 연구 랩이 현재 개발 주도, 특히 코딩과 컴퓨터 사용 에이전트용, [Cursor의 Composer](https://cursor.com/blog/composer)가 프론티어 랩 외부 예시로 제품 환경 내에서 훈련된 전문 코딩 모델 - Prime Intellect의 [Environments Hub](https://www.primeintellect.ai/blog/environments), [Agent Lightning](https://www.thoughtworks.com/radar/languages-and-frameworks/agent-lightning), [NVIDIA NeMo Gym](https://developer.nvidia.com/blog/how-to-train-a-reasoning-model-with-nvidia-nemo-gym/) 같은 프레임워크와 플랫폼 등장으로 프로세스 단순화 진행 **17. Architecture drift reduction with LLMs** - AI 코딩 에이전트 사용 증가로 의도된 코드베이스·아키텍처 설계에서 **드리프트 가속**, 방치 시 에이전트와 인간이 기존 패턴(저하된 것 포함) 복제하며 드리프트 복합, 나쁜 코드가 더 나쁜 코드 낳는 피드백 루프 형성 - 결정론적 분석 도구([Spectral](https://github.com/stoplightio/spectral), [ArchUnit](https://www.archunit.org/), [Spring Modulith](https://spring.io/projects/spring-modulith))와 LLM 기반 평가 결합해 **구조적·의미적 위반 모두 감지** - API 품질 가이드라인을 서비스 전반에 강제하고 에이전트 생성 개선을 안내하는 아키텍처 존 정의에 적용 - 전통 린팅처럼 초기 스캔은 다수 위반 표면화 → 분류·우선순위 필요, LLM이 이를 도움 - 에이전트 생성 수정을 작고 집중적으로 유지해 리뷰 용이화, 변경이 회귀 없이 시스템을 개선하는지 확인하는 **추가 검증 루프** 필수 - [feedback sensors for coding agents](https://www.thoughtworks.com/radar/techniques/feedback-sensors-for-coding-agents)의 아이디어를 전달 라이프사이클 후기 단계로 확장, OpenAI 팀 표현대로 드리프트 감소는 **"가비지 컬렉션"** 형태로 작동 **18. Code intelligence as agentic tooling** - LLM은 코드를 토큰 스트림으로 처리하며 **호출 그래프, 타입 계층, 심볼 관계에 대한 네이티브 이해 없음** - 코드 탐색에 오늘날 대부분 코딩 에이전트가 기본적으로 텍스트 기반 검색(모든 언어 전반에서 가장 강력한 공통 분모) 사용, IDE의 빠른 단축키인 리팩토링을 위해 에이전트는 여러 텍스트 diff 생성 필요 - 에이전트가 AST에 이미 존재하는 정보 재구성에 상당한 토큰 소비 - **AST를 인식하는 도구**에 에이전트 접근 제공, 예: Language Server Protocol(LSP)을 통해, "이 심볼에 대한 모든 참조 찾기"나 "이 타입을 모든 곳에서 이름 변경" 같은 연산을 일급 행동으로 수행 - [OpenRewrite](https://docs.openrewrite.org/) 같은 codemod 도구는 더 풍부한 [Lossless Semantic Tree(LST)](https://docs.openrewrite.org/concepts-explanations/lossless-semantic-trees) 코드 표현에서 동작, 결정론적 도구에 적절한 작업 위임으로 환각 편집 감소와 토큰 소비 절감 - [Claude Code](https://www.thoughtworks.com/radar/tools/claude-code), [OpenCode](https://www.thoughtworks.com/radar/tools/opencode) 등이 로컬 실행 LSP 서버와 통합, JetBrains는 IDE 탐색과 리팩토링을 외부 에이전트에 노출하는 [MCP 서버](https://www.jetbrains.com/help/idea/mcp-server.html) 제공, [Serena](https://github.com/oraios/serena) MCP 서버는 의미적 코드 검색·편집 제공 **19. Context graph** - 결정, 정책, 예외, 선례, 증거, 결과를 **그래프의 일급 연결 노드로 모델링**하는 지식 표현 기법, AI 소비를 위해 구조화 - 기록 시스템이 무엇이 일어났는지 포착한다면, [context graph](https://ibis-project.org/posts/context-graph/)는 **왜**를 포착 — Slack 스레드, 승인 체인, 사람들의 머릿속에 묻힌 기관적 추론을 쿼리 가능한 기계 판독 구조로 전환 - 에이전트 효과성에 필수, 예: 할인 예외를 처리하는 에이전트가 이것이 표준 정책인지 일회성 오버라이드인지 판단 불가 시 잘못 추론, 컨텍스트 그래프가 출처 직접 노출로 결정 추적 순회·관련 선례 적용·다중 홉 인과 체인 추론 가능 - 정적 문서 말뭉치에서 구축되는 [GraphRAG](https://github.com/microsoft/graphrag)와 달리, 컨텍스트 그래프는 **모든 엣지에 시간적 유효성 유지**, 대체된 사실은 덮어쓰기 아닌 무효화 - 세션 간 지속 메모리나 추적 가능한 결정 추론이 필요한 agentic 애플리케이션에 평가할 가치 **20. Feedback flywheel** - 코딩 에이전트와 작업하는 팀들이 점점 [spec-driven development](https://www.thoughtworks.com/radar/techniques/spec-driven-development) 워크플로우 채택, 경량 또는 opinion한 프레임워크 관계없이 spec → plan → implement 흐름 따름 - [Feedback flywheel](https://martinfowler.com/articles/exploring-gen-ai/17-feedback-flywheel.html)은 이 흐름에 **coding agent harness 지속 개선에 초점 맞춘 추가 단계** 확장 - 회고와 유사, 팀이 코딩 에이전트 세션 중 성공과 실패 포착해 미래 세션 예측가능성 향상에 사용, 시간이 지나며 [복합 효과](https://www.thoughtworks.com/insights/blog/machine-learning-and-ai/what-does-coding-agent-mean-software-delivery) - **human on the loop**가 [curated shared instructions](https://www.thoughtworks.com/radar/techniques/curated-shared-instructions-for-software-teams)와 [feedback sensors for coding agents](https://www.thoughtworks.com/radar/techniques/feedback-sensors-for-coding-agents) 같은 피드포워드 통제 개선에 집중하는 메타 기법 - 다음 레벨은 **[agentic feedback flywheel](https://www.anthropic.com/engineering/building-effective-agents)**, 누적 피드백 기반으로 에이전트가 필요한 개선 결정, 현재는 여전히 context rot과 에이전트를 오도할 수 있는 노이즈 피드백 방지 위해 human-in-the-loop 필요 - 환경 진화에 따라 전체 coding agent harness 평가에 활용, 특히 새 모델 채택 시 한 모델에서 작동한 것이 다음에서는 불필요할 수 있음 **21. HTML Tools** - agentic 도구로 작고 작업별 유틸리티 구축이 쉬워져 주요 과제는 **배포와 공유 방법** - [HTML Tools](https://simonwillison.net/2025/Oct/7/tools/)는 공유 가능한 스크립트나 유틸리티를 **단일 HTML 파일로 패키징**하는 접근 방식 - 브라우저에서 직접 실행, 어디든 호스팅, 또는 단순히 파일 공유 가능, 바이너리 공유나 패키지 매니저 사용이 필요한 CLI 도구 배포 오버헤드 회피 - 전용 호스팅을 가진 전체 웹 애플리케이션 구축보다 단순 - 보안 관점에서 신뢰할 수 없는 파일 실행은 여전히 위험 수반, 브라우저 샌드박스와 소스 코드 검사 가능성이 일부 완화 제공 - 경량 유틸리티에 **단일 HTML 파일은 매우 접근 가능하고 휴대 가능한 방식** 제공 **22. LLM evaluation using semantic entropy** - LLM QA 애플리케이션의 환각 형태인 **컨페뷸레이션(confabulation)** 은 전통적 평가 방법으로 해결 어려움 - 한 접근은 주어진 입력에 대한 출력의 **어휘 변이를 분석해 불확실성 측정**으로 정보 엔트로피 사용 - [Semantic entropy](https://www.nature.com/articles/s41586-024-07421-0) 사용 LLM 평가는 표면 수준 변이보다 **의미의 차이**에 초점 맞춰 이 아이디어 확장 - 단어 시퀀스가 아닌 의미 평가로 **사전 지식 없이 데이터셋과 작업 전반에 적용 가능**, 미지 작업에 잘 일반화 - 컨페뷸레이션 유발 가능 프롬프트 식별과 필요 시 주의 권장에 도움 - 순진한 엔트로피는 종종 컨페뷸레이션 감지 실패, **[semantic entropy](https://arxiv.org/abs/2406.15927)는 거짓 주장 필터링에 더 효과적** **23. Measuring collaboration quality with coding agents** - 코딩 에이전트 사용 시 실제 생산성 향상 관찰되지만, 대부분 평가 메트릭이 여전히 첫 출력 시간, 생성된 코드 라인, 완료된 작업 같은 [coding throughput](https://www.thoughtworks.com/radar/techniques/coding-throughput-as-a-measure-of-productivity)에 과도하게 집중 - 팀이 [속도의 덫(speed trap)](https://ordep.dev/posts/the-speed-trap-of-ai-development)에 빠지지 않도록 **인간과 에이전트가 얼마나 효과적으로 협업하는지**로 초점 전환 - **first-pass acceptance rate**, 작업당 반복 주기, 머지 후 재작업, 실패한 빌드, 리뷰 부담 같은 메트릭이 속도 단독보다 의미 있는 신호 제공 - [Claude Code](https://www.thoughtworks.com/radar/tools/claude-code) 사용 팀은 `/insights` 커맨드로 에이전트 세션의 성공과 과제 반영 리포트 생성 가능, 커스터마이즈된 `/review` 커맨드의 first-pass acceptance 추적 실험도 - 짧은 피드백 주기와 실패한 빌드 감소는 **에이전트와의 더 효과적인 상호작용** 지표 - 팀 수준에서 개인 수준이 아닌, DORA 메트릭과 함께 협업 품질 추적해 코딩 에이전트 도입의 더 완전한 그림 구축 **24. MITRE ATLAS** - Agentic 시스템과 코딩 도구가 **새로운 아키텍처와 발생하는 보안 위협** 도입 - [MITRE ATLAS](https://atlas.mitre.org/)는 AI와 ML 시스템을 표적으로 하는 적대적 전술과 기법의 지식 베이스 - 더 광범위한 [MITRE ATT&CK](https://attack.mitre.org/) 프레임워크보다 집중적이고 보완 설계, ML 파이프라인·LLM 애플리케이션·agentic 시스템 위협 분류 제공 - 공유 어휘 없으면 보안 위험이 종종 간과되거나 체크박스 연습으로 축소, ATLAS가 이를 도움 - 실제 인시던트와 기술 패턴 연구 기반, 팀이 **위협 모델링 지원에 프레임워크 사용** 가능 - [SAIF](https://saif.google/) 같은 통제 프레임워크의 자연스러운 보완, AI 시스템의 진화하는 위협 환경 설명에 도움 **25. Ralph loop** - Wiggum loop으로도 불리는 자율 코딩 에이전트 기법, **고정 프롬프트를 무한 루프로 에이전트에 공급** - 각 반복은 새 컨텍스트 윈도우로 시작 — 에이전트가 사양이나 계획에서 작업 선택, 구현, 새 컨텍스트로 루프 재시작 - 코어 통찰은 **단순성**, [teams of coding agents](https://www.thoughtworks.com/radar/techniques/team-of-coding-agents)나 [coding agent swarms](https://www.thoughtworks.com/radar/techniques/coding-agent-swarms) 조율 대신 단일 에이전트가 사양에 대해 자율적으로 작업, 반복 반복을 통해 코드베이스가 사양으로 수렴 기대 - 각 반복에 새 컨텍스트 윈도우 사용으로 **누적된 컨텍스트로 인한 품질 저하 회피**, 상당한 토큰 비용 감수 - [goose](https://github.com/block/goose) 같은 도구가 패턴 구현, 경우에 따라 반복 간 교차 모델 리뷰로 확장 **26. Reverse engineering for design system** - 조직이 종종 **"디자인 표준"이 분리된 웹페이지, 마케팅 자료, 스크린샷의 느슨한 컬렉션**으로만 존재하는 파편화된 레거시 인터페이스로 고민 - 역사적으로 이러한 아티팩트를 감사해 통합 기반 구축은 수동이며 시간 소모적 프로세스 - 멀티모달 LLM으로 이 추출을 자동화 가능, 기존 시각 자산에서 **디자인 시스템을 효과적으로 리버스 엔지니어링** - 웹사이트, [스크린샷](https://github.com/abi/screenshot-to-code), UI 조각을 [전문 도구](https://www.thoughtworks.com/insights/articles/design-system-reverse-engineering)나 비전 가능 AI 모델에 공급해 팀이 **색상 팔레트, 타이포그래피 스케일, 간격 규칙** 같은 코어 디자인 토큰 추출과 반복되는 컴포넌트 패턴 식별 - AI가 이 비구조화 시각 데이터를 디자인 시스템의 구조화된 의미적 표현으로 합성, Figma 같은 도구와 통합 시 출력이 공식화되고 유지 가능한 컴포넌트 라이브러리 생성 크게 가속화 - 시각 감사 노력 감소 외에도 **"AI-ready" 디자인 시스템 구축의 디딤돌** 역할 - 브라운필드 디자인 부채로 부담받는 엔터프라이즈에 AI로 기준선 디자인 시스템 확립은 전체 재설계나 프론트엔드 표준화 전 실용적 시작점 **27. Role-based contextual isolation in RAG** - 접근 제어를 애플리케이션 레이어에서 **검색 레이어로 이동**하는 아키텍처 기법 - 모든 데이터 청크에 인덱싱 시점에 **역할 기반 권한 태그**, 쿼리 시점에 검색 엔진이 사용자의 인증된 정체성 기반으로 검색 공간 제한, 각 청크의 메타데이터와 매칭 - AI 모델이 **검색 단계에서 필터링**되므로 승인되지 않은 컨텍스트 접근 불가 보장, 내부 지식 베이스에 **제로 트러스트 기반** 제공 - [Milvus](https://milvus.io/docs/filtered-search.md)나 [Amazon S3](https://aws.amazon.com/s3/features/vectors/) 기반 서비스 같은 많은 벡터 데이터베이스가 고성능 메타데이터 필터링 지원으로 대형 지식 베이스에도 도입 실용적 **28. Skills as executable onboarding documentation** - [Agent Skills](https://www.thoughtworks.com/radar/techniques/agent-skills), [curated shared instructions](https://www.thoughtworks.com/radar/techniques/curated-shared-instructions-for-software-teams)와 다른 [context engineering](https://www.thoughtworks.com/radar/techniques/context-engineering) 기법이 이번 Radar 전반에 등장, 코딩 컨텍스트에서 강조하고 싶은 사용 사례는 **실행 가능 온보딩 문서로서의 스킬** - 여러 레벨에 적용, 코드베이스 내에서 `/_setup` 스킬이 `go.sh` 스크립트와 README 파일 역할 수행, 스크립트화 불가능한 단계에 LLM 실행 의미론과 스크립트 결합 - 스크립트가 할 수 있는 것을 넘어 **코드베이스와 환경의 현재 상태를 동적으로 고려** 가능 - 라이브러리와 API 생성자가 문서의 일부로 소비자에게 스킬 제공, 내부 또는 외부 스킬 레지스트리([Tessl](https://tessl.io/) 같은) 통해 - 팀의 내부 플랫폼 온보딩에 유용, 핵심 기술 사용 장벽 낮추거나 디자인 시스템 채택 시 마찰 감소, 지금까지 MCP 서버에 많이 의존했으나 이제 스킬로 전환 중 - 다른 문서 형태와 마찬가지로 최신 유지 과제는 사라지지 않음, 그러나 **실행 가능 문서는 정적 문서와 달리 낡음을 훨씬 일찍 알아차리게 도움** **29. Small language models** - SLM이 계속 개선되며 특정 사용 사례에서 LLM보다 **달러당 더 나은 지능** 제공 시작 - 추론 비용 절감과 agentic 워크플로우 속도 향상 위해 팀들이 SLM 평가, 최근 진전은 [지능 밀도](https://arxiv.org/abs/2505.11239)에서 꾸준한 이득 보여 요약과 기본 코딩 같은 작업에서 구 LLM과 경쟁력 확보 - "더 클수록 더 좋다"에서 **더 높은 품질 데이터, [모델 증류](https://arxiv.org/abs/2503.22812), [양자화](https://huggingface.co/docs/transformers/en/quantization/overview)** 로 전환 반영 - Phi-4-mini, Ministral 3 3B 같은 모델이 증류 모델이 더 큰 교사 모델의 많은 능력 유지 입증 - Qwen3-0.6B, Gemma-3-270M 같은 초소형 모델도 **엣지 디바이스에서 실행 가능**해짐 - 구 LLM이 충분했던 agentic 사용 사례에 SLM을 **저비용·저지연·리소스 요구 감소 대안**으로 고려 **30. Team of coding agents** - 이전 Radar에서 개발자가 **역할별 에이전트 소집단을 조율**해 코딩 작업 협업하는 기법으로 설명 - 이후 도입 장벽 하락, 서브에이전트 지원이 기존 코딩 에이전트 도구 전반에서 기본 기능화, Claude Code에 내장 조율 제공하는 [agent teams 기능](https://www.anthropic.com/news/claude-code-agent-teams) 포함 - 에이전트 팀에서 주 오케스트레이터가 보통 작업 시퀀싱과 병렬화 조정, 에이전트는 오케스트레이터뿐 아니라 **서로와도 통신 가능** 해야 함 - 일반 사용 사례는 리뷰어 팀이나 백엔드·프론트엔드 같은 애플리케이션 다른 부분 담당 구현자 그룹 - 업계 일부가 "agent teams"와 ["agent swarms"](https://www.thoughtworks.com/radar/techniques/coding-agent-swarms)를 교체 가능하게 사용(Claude Code가 agent teams 기능을 "our implementation of swarms"로 설명)하지만, 구분에 가치 있음 - **작고 의도적인 에이전트 팀이 작업에 협업**하는 것은 진입 장벽, 복잡성, 사용 사례 측면에서 대형 swarm과 상당히 다름 **31. Temporal fakes** - IoT와 산업 플랫폼에서 오래 사용된 **실세계 시스템 시뮬레이션** 아이디어 확장 - AI 코딩 에이전트가 시뮬레이터 구축 노력 감소시켜 **외부 의존성의 고충실도 복제본** 훨씬 쉽게 생성 가능 - 정적 요청-응답 쌍을 반환하는 전통적 mock과 달리, temporal fakes는 **내부 상태 머신 유지하고 실 시스템의 시간적 진화 모델링** - 한 팀이 대형 GPU 데이터 센터용 관측성 스택 개발에 이 기법 사용, 물리적 하드웨어 조달 회피 - 실 시스템에 대한 알림 규칙, 대시보드, 이상 감지 테스트는 비실용적(예: [thermal throttle](https://www.nvidia.com/en-us/data-center/tools/dcgm/) 알림 검증 위해 의도적으로 GPU 과열) - 대신 [NVIDIA DCGM](https://developer.nvidia.com/dcgm)과 InfiniBand fabric 같은 하드웨어 도메인용 fake를 [Go](https://go.dev/)로 구축 - 시뮬레이터로 thermal throttling, XID 에러 폭풍, 링크 flap, PSU 실패 같은 실패 시나리오를 구성 가능한 강도와 지속 시간으로 활성화, [process-compose](https://github.com/F1bonacc1/process-compose) 스택으로 조율 - 중앙 레지스트리가 유효 실패 시나리오 정의, [MCP](https://www.thoughtworks.com/radar/platforms/model-context-protocol-mcp) 서버가 에이전트에 시나리오 주입 노출 - 에이전트가 특정 GPU에 thermal throttle 주입 같은 결함 트리거 가능, 메트릭이 예상대로 변화하고 알림 발동, 대시보드 업데이트 검증 - 이러한 **시간적 충실도**가 실패가 연쇄되는 복잡 시스템 테스트에 기법 가치 제공, 단 fake가 실세계 동작에 충실하지 않으면 자동화된 파이프라인에 잘못된 자신감 생성 위험 **32. Toxic flow analysis for AI** - 에이전트 능력이 보안 실천을 앞지르는 중, [OpenClaw](https://www.thoughtworks.com/radar/tools/openclaw) 같은 **권한을 탐하는(permission-hungry) 에이전트** 부상으로 팀들이 [lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)에 노출된 환경에 에이전트 배포 증가 — 사적 데이터 접근, 비신뢰 콘텐츠 노출, 외부 통신 능력 - 능력 증가에 따라 공격 표면도 증가, 프롬프트 인젝션과 도구 오염 같은 위험에 시스템 노출 - [Toxic flow analysis](https://invariantlabs.ai/blog/toxic-flow-analysis)를 agentic 시스템 조사로 **안전하지 않은 데이터 경로와 잠재 공격 벡터 식별**하는 주요 기법으로 지속 인식 - 위험이 더 이상 MCP 통합에 국한되지 않음, [Agent Skills](https://www.thoughtworks.com/radar/techniques/agent-skills)에서도 유사 패턴 관찰 — **악의적 행위자가 민감 데이터 유출을 위한 숨은 지시를 내장한 유용해 보이는 스킬 패키징** - 에이전트 작업 팀에 toxic flow analysis 수행과 악용 전 안전하지 않은 데이터 경로 식별 위해 [Agent Scan](https://www.thoughtworks.com/radar/tools/agent-scan) 같은 도구 사용 강력 권장 **33. Vision language models for end-to-end document parsing** - 문서 파싱이 레이아웃 감지, 전통적 OCR, 후처리 스크립트 결합한 다단계 파이프라인에 의존, **복잡한 레이아웃과 수학 공식에 고전** - VLM을 사용한 종단 간 문서 파싱은 문서 이미지를 **단일 입력 모달리티로 취급**해 아키텍처 단순화, 자연스러운 읽기 순서와 구조화 콘텐츠 보존 - [olmOCR-2](https://huggingface.co/allenai/olmOCR-2-7B-1025), 토큰 효율적 [DeepSeek-OCR (3B)](https://huggingface.co/deepseek-ai/DeepSeek-OCR), 초소형 [PaddleOCR-VL](https://www.paddleocr.ai/latest/version3.x/algorithm/PaddleOCR-VL/PaddleOCR-VL.html) 같은 이 목적으로 특별히 훈련된 오픈소스 모델이 매우 효율적 결과 산출 - VLM이 다단계 파이프라인 대체로 아키텍처 복잡성 감소시키지만, **생성적 특성으로 환각 경향** - 오류 허용도 낮은 사용 사례는 여전히 하이브리드 접근이나 결정론적 OCR 필요 - 대량 문서 수집 처리 팀은 정확성 유지하며 장기 유지 오버헤드 감소 가능 여부 결정 위해 이러한 통합 접근 평가 필요 #### Caution **34. Agent instruction bloat** - `AGENTS.md`, `CLAUDE.md` 같은 컨텍스트 파일이 시간이 지나며 **코드베이스 개요, 아키텍처 설명, 관례, 규칙 추가로 누적** - 각 추가는 격리된 상태에서 유용하지만, 종종 **agent instruction bloat** 초래, 지시가 길어지고 때로 서로 충돌 - 모델이 긴 컨텍스트 중간에 묻힌 내용에 덜 주목하는 경향, 긴 대화 기록 깊숙이 있는 가이던스는 놓쳐질 수 있음 - 지시 증가에 따라 **중요 규칙이 무시될 가능성 증가** - 많은 팀이 AI로 `AGENTS.md` 파일 생성 중이지만, [연구](https://arxiv.org/abs/2510.09230)는 **손으로 작성한 버전이 종종 LLM 생성보다 효과적**임을 시사 - agentic 도구 사용 시 지시에 대해 의도적이고 선택적이어야 하며, 필요에 따라 추가하고 **최소하고 일관된 세트로 지속적 정제** 필요 - 현재 작업에 필요한 지시와 능력만 표면화하도록 [progressive context disclosure](https://www.thoughtworks.com/radar/techniques/progressive-context-disclosure) 활용 고려 **35. AI-accelerated shadow IT** - AI가 비코더의 복잡 시스템 구축 장벽을 계속 낮추는 중, 실험과 요구 사항 초기 검증 가능하게 하지만 **AI 가속 shadow IT 위험** 도입 - AI API(OpenAI나 Anthropic 등)를 통합한 노코드 워크플로우 플랫폼 외에도, [Claude Cowork](https://www.anthropic.com/cowork) 같은 더 많은 agentic 도구가 비코더에게 제공 중 - 조용히 비즈니스를 운영하던 스프레드시트가 **거버넌스가 없는 커스텀 agentic 워크플로우로 진화**하면 상당한 보안 위험과 유사 문제에 대한 경쟁 솔루션 확산 도입 - 일회성 워크플로우와 내구성 있고 프로덕션 준비된 구현 필요한 중요 프로세스 구분이 **실험과 통제 균형의 핵심** - 조직은 AI 도입 전략의 일부로 거버넌스 우선순위화, 통제된 환경 내 실험 촉진 필요 - 적절히 계측된 내부 샌드박스가 비코더에게 사용량 추적 가능한 프로토타입 배포 장소 제공 - 기존 워크플로우 공유 카탈로그와 페어링으로 팀이 이미 구축된 것 발견 후 중복 노력 회피 도움 **36. Codebase cognitive debt** - 시스템 구현과 팀의 **어떻게와 왜 작동하는지에 대한 공유 이해 사이의 증가하는 간극** - AI가 변경 속도 증가시키면서, 특히 여러 기여자나 [Coding Agent Swarms](https://www.thoughtworks.com/radar/techniques/coding-agent-swarms)에서 팀이 **설계 의도와 숨겨진 결합 추적 상실** 가능 - 증가하는 [기술 부채](https://martinfowler.com/bliki/TechnicalDebt.html)와 결합되어 시스템을 점점 추론 어렵게 만드는 강화 루프 형성 - 약한 시스템 이해는 개발자의 AI 효과적 안내 능력 감소, 엣지 케이스 예상과 에이전트를 아키텍처 함정에서 벗어나게 유도 어려움 - 관리 안 되면 **작은 변경이 예상 못한 실패 트리거하는 티핑 포인트 도달**, 수정이 회귀 도입, 정리 노력이 위험 감소 대신 증가 - [AI 생성 코드에 대한 안일함](https://arxiv.org/abs/2506.08872) 회피하고 명시적 대응책 도입 — [feedback sensors for coding agents](https://www.thoughtworks.com/radar/techniques/feedback-sensors-for-coding-agents), [팀 인지 부하 추적](https://teamtopologies.com/key-concepts-content/what-is-team-cognitive-load-and-why-it-matters), [아키텍처 피트니스 함수](https://www.thoughtworks.com/insights/articles/fitness-function-driven-development)로 AI가 출력 가속화할 때 핵심 제약 지속 강제 **37. Coding agent swarms** - [team of coding agents](https://www.thoughtworks.com/radar/techniques/team-of-coding-agents)가 작고 의도적인 그룹이라면, **coding agent swarm은 수십~수백 에이전트를 문제에 적용**, AI가 구성과 크기를 동적으로 결정 - [Gas Town](https://github.com/steveyegge/gastown), [Ruflo](https://ruflo.dev/)(이전 Claude Flow) 같은 프로젝트가 좋은 예시 - swarm 구현의 초기 패턴 등장 중 — **계층적 역할 분리**(오케스트레이터, 감독자, 임시 워커), 에이전트가 작업 분할·조정 도움 받는 내구성 작업 원장(Gas Town은 [beads](https://www.thoughtworks.com/radar/tools/beads) 사용), 병렬 작업 충돌 처리 머지 메커니즘 - 두 swarm 실험이 특히 주목 — Anthropic의 [C 컴파일러 생성](https://www.anthropic.com/research/software-engineering-superintelligence)과 Cursor의 [agent scaling 실험](https://cursor.com/blog/beyond-a-week)(일주일에 걸쳐 브라우저 생성) - **두 팀 모두 기존 상세 사양에 의존 가능한 사용 사례 선택**, C 컴파일러의 경우 명확하고 측정 가능한 피드백 제공하는 포괄적 테스트 스위트 포함 - 이러한 조건은 요구 사항이 덜 정의되고 검증이 더 어려운 **전형적 제품 개발을 대표하지 않음** - 그럼에도 이러한 실험이 장기 실행 swarm을 기술적으로 실행 가능하게 만드는 신흥 패턴에 기여, 여전히 비용 많이 들고 성숙과 거리 멀어 **도입에 신중 권장** **38. Coding throughput as a measure of productivity** - AI 코딩 어시스턴트가 실제 생산성 향상 제공하며 표준 개발자 도구로 빠르게 자리 잡는 중 - 그러나 조직들이 **생성된 코드 라인이나 풀 리퀘스트(PR) 수** 같은 피상적 지표로 성공 측정 증가 - 이러한 coding throughput 메트릭이 고립되어 사용되면 **직원 행동에 부정적 영향** 가능 - 결과는 종종 **리뷰를 느리게 하고 전달 처리량을 해치며 보안 위험 도입하는 제대로 정렬되지 않은 코드 홍수**, 엔지니어가 불충분히 리뷰된 AI 출력으로 채워진 PR 제기해 리뷰어와 반복 왕복으로 사이클 시간 증가 - 이러한 메트릭은 AI 생성 코드를 팀 아키텍처·관례·패턴에 맞추는 데 필요한 **잔여 노력 포착 실패** - 더 의미 있는 선행 지표 존재 — **first-pass acceptance rate**, AI 출력이 최소 재작업으로 사용될 수 있는 빈도 - 이를 측정하면 숨겨진 노력 노출과 개선 실행 가능화, 팀이 프롬프트 정제, 프라이밍 문서 개선, 디자인 대화 강화로 수용 지속 증가 - AI 출력이 덜 수정 필요한 선순환 생성, first-pass acceptance는 [DORA 메트릭](https://www.thoughtworks.com/radar/techniques/dora-metrics)과 자연스럽게 연결 — 낮은 수용률은 변경 실패율 증가 경향, 반복 주기 반복은 변경 리드 타임 연장 - AI 어시스턴트가 보편화됨에 따라 조직은 **coding throughput 단독에서 실제 영향과 전달 결과 반영 메트릭으로 초점 전환** 필요 **39. Ignoring durability in agent workflows** - 여러 팀에서 관찰된 안티패턴, 개발에서는 작동하지만 **프로덕션에서 실패하는 시스템** 초래 - 분산 시스템이 직면한 과제는 에이전트 구축 시 더욱 두드러짐, **실패를 예상하고 우아하게 복구하는 사고방식이 반응적 접근보다 우수** - LLM과 도구 호출이 네트워크 중단과 서버 충돌로 실패 가능, 에이전트 진행 중단과 열악한 사용자 경험·운영 비용 증가 초래 - 일부 시스템은 작업이 단기일 때 이를 허용 가능하지만, 며칠 또는 몇 주 실행되는 복잡 워크플로우는 **내구성 필요** - [LangGraph](https://langchain-ai.github.io/langgraph/concepts/durable_execution/), [Pydantic AI](https://ai.pydantic.dev/durable_execution/overview/) 같은 에이전트 프레임워크에 내구성 있는 실행 통합 중 - **진행과 도구 호출의 상태 저장 지속성** 제공, 실패 후 에이전트가 작업 재개 가능 - human in the loop 포함 워크플로우는 내구성 있는 실행이 입력 대기 중 진행 일시 중단 가능 - [Durable computing](https://stackoverflow.blog/2024/10/31/durable-execution-a-not-so-new-paradigm-for-a-new-era/) 플랫폼인 [Temporal](https://temporal.io/), [Restate](https://restate.dev/), [Golem](https://www.golem.cloud/)도 에이전트 지원 제공 - 내장 도구 실행과 결정 추적 관측성이 디버깅 용이화와 프로덕션 시스템 이해 개선 - 에이전트 프레임워크의 네이티브 내구성 실행 지원으로 시작, 워크플로우가 더 중요하거나 복잡해지면 독립 플랫폼 활용 **40. MCP by default** - [Model Context Protocol (MCP)](https://modelcontextprotocol.io/)가 주목받으며, 팀과 벤더가 더 단순한 대안이 있음에도 AI 에이전트와 외부 시스템 간 **기본 통합 레이어로 채택** 경향 - MCP를 기본으로 사용하는 것에 주의, MCP는 구조화된 도구 계약, OAuth 기반 인증 경계, 거버넌스된 멀티테넌트 접근에 실제 가치 추가 - Justin Poehnelt가 ["abstraction tax"](https://justinpoehnelt.com/posts/2025-09-29-the-hidden-cost-of-mcp/)라고 부르는 것도 도입 — 에이전트와 API 사이의 모든 프로토콜 레이어가 **충실도 손실**, 복잡 API는 이러한 손실 복합 - 실제로 좋은 `--help` 출력, 구조화된 JSON 응답, 예측 가능한 에러 처리를 갖춘 **잘 설계된 CLI가 프로토콜 오버헤드 없이 에이전트가 필요한 모든 것 제공** - Simon Willison의 [지적](https://simonwillison.net/2025/Sep/12/mcp-vs-cli/)처럼, "MCP로 달성할 수 있는 거의 모든 것은 CLI 도구로 처리 가능" - MCP 거부가 아님, 팀은 기본 채택 회피하고 시스템이 실제로 **프로토콜 수준 상호운용성 필요한지** 먼저 질문 - MCP는 거버넌스와 통합 이점이 복잡성 추가와 잠재 충실도 손실을 능가할 때 타당 **41. Pixel-streamed development environments** - VDI 스타일 원격 데스크탑이나 워크스테이션을 소프트웨어 개발에 사용, **편집·빌드·디버깅이 로컬 머신이나 코드 중심 원격 환경 대신 스트리밍 데스크탑 통해 수행** - 조직들이 특히 오프쇼어 팀과 리프트 앤 시프트 클라우드 프로그램의 보안, 표준화, 온보딩 목표 충족 위해 계속 채택 - 그러나 실제로는 트레이드오프 종종 부실 — **지연, 입력 지연, 일관되지 않은 화면 반응성이 지속적 인지 마찰 생성**, 전달 속도 저하와 일상 개발 작업을 더 피곤하게 만듦 - [클라우드 개발 환경](https://www.thoughtworks.com/radar/techniques/development-environments-in-the-cloud), [Google Cloud Workstations](https://cloud.google.com/workstations), [Coder](https://www.thoughtworks.com/radar/platforms/coder), [VS Code Remote Development](https://code.visualstudio.com/docs/remote/remote-overview) 같은 도구와 달리 — 전체 데스크탑 스트리밍 없이 **컴퓨팅을 코드에 더 가깝게 이동** - pixel-streamed 설정은 개발자 흐름보다 **중앙 집중 통제 우선순위화**, 종종 이를 사용하는 엔지니어로부터 충분한 입력 없이 부과 - 강력한 보안이나 규제 제약이 생산성 비용을 명확히 능가하지 않는 한 **소프트웨어 전달의 기본 선택으로 pixel-streamed 개발 환경 비권장** ### [Platforms] #### Adopt — 없음 #### Trial **42. AG-UI Protocol** - 풍부한 사용자 인터페이스와 백엔드 AI 에이전트 간 **통신 표준화** 위해 설계된 오픈 프로토콜과 라이브러리 - 역사적으로 agentic UI 구축은 양방향 상태 저장 협업을 위한 맞춤 배관 작업 필요, [AG-UI](https://github.com/ag-ui-protocol/ag-ui)는 server-sent events(SSE)와 WebSockets 같은 전송 지원하는 **일관된 이벤트 기반 아키텍처**로 해결 - 추론 단계 스트리밍, 상태 동기화, 동적 UI 컴포넌트 렌더링 지원 - 그러나 에이전트 인터페이스 아키텍처 환경이 빠르게 변화 중, AG-UI는 의도적으로 MCP 외부에 위치해 프론트엔드와 에이전트 백엔드 간 **인터페이스 레이어** 역할 - 새로운 MCP 기반 애플리케이션이 [HTML과 UI 위젯을 MCP 서버나 스킬 내에 직접 패키징](https://www.thoughtworks.com/radar/platforms/mcp-apps)하는 다른 접근 방식 부상 - UI 컴포넌트가 도구와 함께 임베딩되고 제공 가능해지면서 — [MCP-UI](https://mcpui.dev/) 같은 인접 표준과 관련된 패턴 — AG-UI 같은 **별도 UI 프로토콜 레이어 필요성에 의문 제기** - 프론트엔드 UX와 백엔드 오케스트레이션 분리에는 여전히 견고한 선택, 단 MCP 생태계 내 도구 로직과 UI 통합 추세 고려해 역할 평가 필요 **43. Apache APISIX** - 레거시 Nginx 기반 솔루션의 한계 해결하는 오픈소스, 고성능, 클라우드 네이티브 게이트웨이 - Nginx와 OpenResty의 LuaJIT 위에 구축, **etcd를 구성 저장소로 사용**해 리로드로 인한 지연 제거, 동적 마이크로서비스와 서버리스 아키텍처에 적합 - 주요 강점은 **완전 동적이고 플러그인 가능한 아키텍처**, API와 WASM 포함 다국어 플러그인 생태계로 트래픽 관리·보안·관측성 커스터마이즈 가능 - [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) 지원으로 [Apache APISIX](https://apisix.apache.org/)를 [Kubernetes](https://kubernetes.io/) 게이트웨이로 사용 가능, 레거시 Nginx ingress 컨트롤러 대체 강력 후보 **44. AWS Bedrock AgentCore** - 인프라 관리 오버헤드 없이 **에이전트를 안전하게 대규모로 구축·실행·운영**하기 위한 agentic 플랫폼, [GCP Vertex AI Agent Builder](https://cloud.google.com/products/agent-builder), [Azure AI Foundry Agent Service](https://learn.microsoft.com/en-us/azure/ai-foundry/agents/overview)와 유사 - 플랫폼을 모놀리식 블랙박스로 채택하기 쉽지만, **세분화되고 분리된 아키텍처**로 더 큰 성공 — 세션 격리·보안·관측성 같은 프로덕션 관심사에는 [AgentCore](https://aws.amazon.com/bedrock/agentcore/) 런타임 사용, 오케스트레이션 로직은 [LangGraph](https://www.thoughtworks.com/radar/languages-and-frameworks/langgraph) 같은 외부 프레임워크에 유지 - 이러한 관심사 분리로 LLM 환경 진화 시 적응 유연성 유지하며 관리형 인프라 이점 활용 가능 - 런타임 우선 집중으로 조직이 **벤더 특정 오케스트레이션 레이어에 핵심 로직 통제권 양도 없이** agentic 워크로드를 점진적으로 프로덕션에 이동 가능 **45. Graphiti** - Zep의 오픈소스 시간적 지식 그래프 엔진으로 **LLM 메모리 문제 해결**의 프로덕션 가능성 입증 - [RAG](https://www.promptingguide.ai/research/rag) 파이프라인의 평면 벡터 저장소가 사실의 시간 변화 추적 실패하는 반면, [Graphiti](https://github.com/getzep/graphiti)는 데이터를 별개 [에피소드](https://help.getzep.com/graphiti/core-concepts/adding-episodes)로 수집하고 그래프 엣지에 **양시간적 유효성 윈도우** 유지, 오래된 사실은 덮어쓰기 아닌 무효화 - 배치 지향 [GraphRAG](https://microsoft.github.io/graphrag/)와 달리 그래프를 점진적 업데이트, 의미 검색·BM25·그래프 순회 결합한 하이브리드 검색으로 **쿼리 시점 LLM 호출 없이 서브초 검색** 제공 - 두 요인이 이동 추진 — 18.5% 정확도 개선과 [90% 지연 감소](https://blog.getzep.com/state-of-the-art-agent-memory/) 보고하는 동료 검토 벤치마크, 그리고 Model Context Protocol 호환 에이전트가 최소 통합 노력으로 영구 시간 메모리 부착 가능하게 하는 일급 [MCP 서버](https://help.getzep.com/graphiti/getting-started/mcp-server) 출시 - 강력한 커뮤니티 도입이 프로덕션 준비성 추가 신호 - Neo4j가 주 백엔드, [FalkorDB](https://www.thoughtworks.com/radar/platforms/falkordb)가 가벼운 대안 - 쓰기당 LLM 추출 비용과 1.0 이전 릴리스 상태 고려한 의존성 고정 필요 **46. Langfuse** - 관측성, 프롬프트 관리, 평가, 데이터셋 관리를 다루는 오픈소스 LLM 엔지니어링 플랫폼 - 마지막 평가 이후 프로젝트 크게 성숙, v3 아키텍처가 [ClickHouse](https://www.thoughtworks.com/radar/platforms/clickstack), Redis, S3를 백엔드 컴포넌트로 도입해 **확장성 향상되었으나 자체 호스팅 복잡성도 증가** - Python과 TypeScript SDK 모두 [OpenTelemetry](https://opentelemetry.io/) 위에 네이티브로 구축, OTEL 기반 관측성 사용 팀에 자연스러운 적합 - 실험 러너 SDK와 프롬프트 실험용 구조화 출력 지원 같은 새 기능이 [Langfuse](https://langfuse.com/)를 순수 추적에서 체계적 평가 워크플로우로 확장 - Arize Phoenix, [Helicone](https://www.helicone.ai/), [LangSmith](https://www.langchain.com/langsmith) 포함 점점 혼잡한 공간에서 고려할 만함 - 주로 [Pydantic AI](https://ai.pydantic.dev/) 위에 구축하는 팀은 LLM 특정 도구 모음 대신 **풀스택 OTEL 관측성 플랫폼**으로 더 광범위한 접근 취하는 [Pydantic Logfire](https://pydantic.dev/logfire)도 고려 - 통합된 추적, 평가, 프롬프트 관리를 단일 자체 호스팅 가능 플랫폼에서 필요한 팀에 신뢰할 만한 선택, 단 모델 레이어 비용·지연 가시성이 주 필요라면 Helicone 같은 더 좁은 도구로 충분할지 평가 필요 **47. Port** - 개발자 경험 개선 위해 설계된 **상용 내부 개발자 포털**, 소프트웨어 자산 중앙화·워크플로우 자동화·엔지니어링 표준 강제로 플랫폼 팀에 셀프 서비스 워크플로우의 단일 진실 공급원 제공 - 조직이 엔지니어링 워크플로우 표준화하면서 템플릿, API, 자동화, 에이전트를 개발자가 실제 사용 가능한 형태로 노출하려 함에 따라 더 중요해짐 - 독립 포털뿐 아니라 [Port](https://www.port.io/)의 API와 MCP 레이어 통해 **IDE에서 직접 사용 가능** - 플랫폼 엔지니어링에 무겁게 투자하지 않고 제품화된 포털 역량 원하는 조직에 잘 작동 - 클라이언트 참여에서 수천 명 개발자 지원하면서 상대적으로 작은 플랫폼 팀이 효과적 셀프 서비스 빠르게 전달 가능하게 함 - 내부 개발자 포털 역량 빠르게 필요하고 **상용 플랫폼과 벤더 의존성 제약 수용 가능한 조직**에 평가할 가치 **48. Replit** - **즉각적 개발 환경, 실시간 코딩, 통합 AI 어시스턴스**를 브라우저에서 바로 제공하는 클라우드 네이티브 협업 개발 플랫폼 - 에디터, 런타임, 배포, AI 코딩 워크플로우를 단일 통합 플랫폼에 결합, 개발자가 로컬 설정 없이 즉시 코딩 시작 가능 - AI 기반 협업 IDE가 **온보딩 마찰 감소**에 매우 도움, 팀으로 함께 프로토타이핑에 적합 - 트레이닝 세션, 지식 공유, 부트캠프에도 매우 효과적 - 일부는 [Replit](https://replit.com/)을 AI 지원 취미 프로젝트 장소로 볼 수 있지만, **환경이 전통 로컬 IDE와 경쟁 가능할 만큼 강력**해 반복과 협업이 훨씬 쉬워짐 **49. SigNoz** - 로그·메트릭·추적을 통합 지원하는 **오픈소스 OpenTelemetry 네이티브 관측성 플랫폼** - 현대 마이크로서비스와 분산 아키텍처의 APM과 계측 요구 해결하면서 **벤더 종속 회피** - ClickHouse를 기본 컬럼 데이터베이스로 활용해 빠른 쿼리와 함께 확장 가능, 고성능, 비용 효과적 저장 제공, Datadog 같은 플랫폼의 강력한 자체 호스팅 대안으로 자리매김 - PromQL과 ClickHouse SQL을 통한 유연한 쿼리, 다중 알림 채널 알림 지원 - 실제로 [SigNoz](https://signoz.io/)가 성능 손상 없이 **인프라 리소스 소비와 전체 관측성 비용 감소** 확인 - 관리형 클라우드 서비스 가능하지만, 데이터와 인프라 통제 유지 선호 조직에 사용 준비된 Docker 이미지와 Helm 차트 실용적 선택 #### Assess **50. Agent Trace** - Cursor가 제안한 **AI 코드 귀속 표준화** 오픈 사양 - 코딩 에이전트 도입 증가로 누가 코드를 수정했는지 이해가 인간 개발자를 넘어 AI 생성 변경 포함으로 확장 - `git blame` 같은 기존 도구는 코드 라인이 수정되었음을 보여줄 수 있지만, **변경이 인간·AI·둘 다에 의한 것인지 포착 실패** - [Agent Trace](https://github.com/agent-trace/agent-trace)는 코드 변경 추적 방법 정의에 벤더 중립적 접근, 추적 저장 방법에 대해 의견 없음 - Git, Mercurial, [Jujutsu](https://github.com/jj-vcs/jj) 포함 다중 버전 관리 시스템과 호환 - 사양은 human, AI, mixed, unknown 같은 **기여자 유형**과 각 기여 출처 설명 추적 레코드 정의 - Cline, OpenCode 같은 도구의 지원과 [Git AI](https://www.thoughtworks.com/radar/tools/git-ai) 같은 구현으로 도입 초기 신호 **51. ClickStack** - 단일 고성능 데이터 저장소(ClickHouse 기반)에서 **로그·추적·메트릭·세션 통합**하는 OpenTelemetry 호환 오픈소스 관측성 플랫폼 - 인프라 성장과 관측성 비용 증가로 많은 팀이 **파편화된 텔레메트리 도구 체인과 비싼 벤더 플랫폼**으로 고전 - [ClickStack](https://clickhouse.com/use-cases/observability)이 ClickHouse 컬럼 저장소 활용해 대량 텔레메트리 데이터 전반 서브초 고카디널리티 쿼리 가능, 관측성에 더 단순하고 비용 효과적 기반 제공 **52. Coder** - [pixel-streamed development environments](https://www.thoughtworks.com/radar/techniques/pixel-streamed-development-environments)의 좋은 대안, **코드 실행 위치와 개발자 상호작용 방법 분리** - 전체 데스크탑 인터페이스 스트리밍 대신 개발자가 VS Code 같은 로컬 IDE나 브라우저로 원격 환경 연결, 사용성 손상 없이 더 반응성 있는 경험 - 코드는 원격 확장 가능 인프라에서 실행되며 환경은 코드로 정의·관리, 팀이 개발 설정 표준화하고 신규 개발자 온보딩 단순화 가능 - 내부 시스템 통제된 접근 제공과 사전 승인된 AI 코딩 에이전트 접근 간소화도 용이 - [Coder](https://coder.com/)를 로컬 개발과 완전 가상화 데스크탑 사이 **중간 지점**으로 인식 — pixel-streamed VDI의 사용성 한계 없이 중앙 집중 통제와 거버넌스 제공 - 원격이나 통제된 실행 환경 필요 조직, 특히 더 높은 컴퓨팅이나 안전 접근 필요한 곳에 좋은 옵션 - 이러한 환경 관리에 따른 **운영 오버헤드와 보안 책임** 평가 필요 **53. Databricks Agent Bricks** - 에이전트 기반 접근 방식이 주류화되며 데이터 플랫폼이 이러한 워크로드를 추가 모듈이 아닌 **네이티브로 지원하도록 진화** 중 - [Databricks Agent Bricks](https://www.databricks.com/product/artificial-intelligence/agent-bricks)는 지식 어시스턴트와 데이터 분석가 같은 **일반 AI 패턴용 사전 구축, 자동 최적화 컴포넌트** 제공 - 선언적 접근 방식 따름 — 개발자가 목표와 기본 데이터 정의, 프레임워크가 실행과 최적화 처리 - LLMOps 단순화와 데이터 큐레이션에 필요한 노력 감소로 팀이 **보일러플레이트보다 비즈니스 결과에 더 집중** 가능 - 한 팀이 전임상 R&D용 복잡 RAG 솔루션 평가·구축에 커스텀 에이전트와 함께 사용 - 이미 Databricks 생태계 투자, 챗봇과 문서 추출 같은 일반 사용 사례에 에이전트 기반 접근 탐색 중이라면 평가 고려 **54. DuckLake** - **표준 SQL 데이터베이스를 카탈로그와 메타데이터 관리에 사용**해 lakehouse 아키텍처 단순화하는 통합 데이터 레이크와 카탈로그 형식 - 전통 오픈 테이블 형식인 Iceberg나 Delta Lake가 복잡한 파일 기반 메타데이터 구조에 의존하는 반면, [DuckLake](https://ducklake.select/)는 메타데이터를 카탈로그 데이터베이스(SQLite, PostgreSQL, DuckDB 등)에 저장하면서 데이터를 로컬 디스크나 S3 호환 객체 저장소의 Parquet 파일로 지속 - 이러한 하이브리드 접근이 **쿼리 계획 지연과 동시 업데이트 중 트랜잭션 신뢰성 개선** - DuckDB가 `ducklake` 확장 통해 쿼리 엔진 역할, 표준 DDL과 DML 연산용 친숙한 SQL 인터페이스 제공 - 파티셔닝 같은 lakehouse 특성 유지하면서 인덱스와 기본/외래 키 생략 - 시간 여행, 스키마 진화, ACID 준수 지원으로 독립 분석 스택 추구 팀에 **저복잡성 옵션** 제공 - 아직 성숙도 초기지만, 전통 lakehouse 아키텍처에 대한 유망하고 가벼운 대안 - Spark나 Trino 기반 생태계와 관련된 운영 오버헤드 회피, 간소화된 데이터 환경에 적합 **55. FalkorDB** - Cypher를 지원하는 **Redis 기반 그래프 데이터베이스**, 무거운 그래프 플랫폼 도입 없이 그래프 역량 원하는 팀에 적합 - 운영 마찰이 낮은 게 중요한 관계 풍부 AI와 애플리케이션 워크로드 구축, 임베디드 저장보다 **서버 기반 그래프 서비스가 선호되는** 조직에 실용적 옵션 - 아키텍처가 유망하고 개발자 모델이 접근 가능하지만, 광범위한 도입 결정 전 [FalkorDB](https://www.falkordb.com/)의 **확장, 운영 도구, 장기 생태계 성숙도 관련 프로덕션 동작 검증** 필요 **56. Google Dialogflow CX** - Google Cloud의 관리형 대화형 AI 플랫폼, **Flows와 Pages로 구축된 그래프 기반 상태 머신**과 Vertex AI Gemini 기반 생성 역량 결합 - 이전에 그 전신인 Dialogflow를 Radar에서 추적 - CX는 상당한 재설계 대표, 2024년 Google이 Vertex AI Gemini 모델 통합 후 주목받음, **지시 기반 에이전트용 Generative Playbooks**와 인덱싱된 콘텐츠에 응답 그라운딩하는 **Data Store RAG** 도입 - 자연어 데이터 디스커버리 에이전트 구축에 사용, 저코드 환경과 Generative Playbooks 위해 커스텀 SDK 접근보다 [Dialogflow CX](https://cloud.google.com/dialogflow/cx/docs) 선택 - 자연어 쿼리를 SQL로 번역하기 위한 few-shot 프롬프팅으로 구성 - Google Cloud 기반 구축 팀이 구조화된 내부 데이터 위에 자연어 인터페이스 구축 시 커스텀 에이전트 스택 대비 전달 가속화 발견 - 그러나 **무료 티어 없음**, 깊은 Google Cloud 의존성으로 상당한 벤더 종속 도입, 컨텍스트 엔지니어링 노력 계획 필요 **57. MCP Apps** - Model Context Protocol의 **첫 공식 확장**, MCP 서버가 대시보드, 폼, 시각화로서 **대화에서 직접 렌더링되는 인터랙티브 HTML 인터페이스 반환** 가능 - Anthropic, OpenAI, 오픈소스 기여자 공동 개발, 도구가 호스트가 UI 지원 부족 시 텍스트로 우아하게 저하되는 **샌드박스 iframe에서 렌더링되는 UI 템플릿 선언**하는 `ui://` 리소스 스키마 표준화 - 별도 라이브러리 레이어로 작동하는 [AG-UI](https://www.thoughtworks.com/radar/platforms/ag-ui-protocol)와 달리, [MCP Apps](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SEP-1865.md)는 **UI를 MCP 서버 내부에 직접 패키징** - 양방향 설계로 모델이 사용자 행동 관찰 가능, 인터페이스는 텍스트가 할 수 없는 **실시간 데이터와 직접 조작** 처리 - Claude, ChatGPT, VS Code, Goose 포함 클라이언트가 이미 지원 출시 - 더 풍부한 에이전트 상호작용 탐색 팀은 평문 텍스트 응답 대비 추가 복잡성이 사용 사례에 정당한지 평가 필요 **58. Monarch** - **단일 머신 PyTorch 워크로드의 단순함을 대형 GPU 클러스터로 가져오는** 오픈소스 분산 프로그래밍 프레임워크 - 원격 프로세스와 액터 생성용 Python API 제공, 이를 브로드캐스트 메시징 지원하는 **mesh** 컬렉션으로 그룹화 - **supervision tree를 통한 결함 허용** 제공, 실패가 계층 위로 전파되어 깔끔한 에러 처리와 세밀한 복구 가능 - 효율적 GPU·CPU 메모리 이동 위한 **point-to-point RDMA 전송** 지원, 액터가 명령형 프로그래밍 모델 유지하면서 프로세스 전반 분할된 텐서로 작업 가능한 분산 텐서 추상화 제공 - [Monarch](https://github.com/meta-pytorch/monarch)는 고성능 Rust 백엔드 위에 구축 - 아직 개발 초기 단계지만, **분산 텐서를 로컬처럼 동작하게 하는 추상화**가 강력해 대규모 분산 AI 훈련 복잡성 크게 감소 가능 **59. Neutree** - **사설 인프라에서 LLM 관리·서빙**하는 오픈소스 플랫폼, 엔터프라이즈 AI를 위한 모델 서비스 레이어로 자리매김 - 모델 라이프사이클 관리, 추론 서빙, NVIDIA·AMD·Intel 가속기 같은 이종 하드웨어 전반 컴퓨팅 스케줄링용 통합 통제 평면 제공 - 조직이 호스팅 API에서 자체 호스팅, 거버넌스된 배포로 이동함에 따라 [Neutree](https://github.com/neutree-ai/neutree)가 명확한 간극 해결 — **멀티테넌시, 접근 제어, 사용량 회계, 인프라 추상화** 같은 엔터프라이즈급 역량으로 LLM 워크로드 운영 - 모델 서빙을 애플리케이션 로직과 분리해 팀이 특정 클라우드 공급자에 강하게 결합 없이 베어 메탈, VM, 컨테이너 포함 환경 전반에 모델 배포·확장·라우팅 가능 - 그러나 비교적 새로움, 도입에 신중 접근 필요 - 생태계, 운영 성숙도, 통합 역량이 더 확립된 ML 플랫폼 대비 여전히 진화 중 - 유망하지만, **신흥 엔터프라이즈 AI 인프라 평가·형성에 투자 의지 있는 팀**에 가장 적합 **60. OptScale** - GPU와 실험 비용이 빠르게 급증할 수 있는 **AI/ML 무거운 워크로드를 지원하는 오픈소스 멀티클라우드 FinOps 플랫폼** - 클라우드 API에서 청구와 사용 데이터 수집, 단일 시스템에서 비용 가시성, 최적화 권장사항, 예산 추적, 이상 감지를 팀이나 비즈니스 구조에 정렬된 정책 기반 알림과 결합 - OpenCost와 비교 시 [OptScale](https://hystax.com/optscale/)은 Kubernetes 수준 분석 제공하면서 **더 광범위한 비 Kubernetes FinOps 사용 사례** 커버 - IBM Cloudability, CloudZero, CloudHealth, IBM Kubecost, Flexera One 같은 엔터프라이즈 스위트보다 **더 많은 통제와 적은 벤더 종속** 제공 - 트레이드오프는 더 높은 운영 오버헤드, 배포 복잡성, 커넥터 엣지 케이스, 컨테이너 이미지 보안 위생 관련 우려 - 플러그 앤 플레이 제품이 아닌 **플랫폼 역량 투자**로 취급 필요 **61. Rhesis** - LLM과 agentic 애플리케이션용 오픈소스 테스트 플랫폼, 팀이 **자연어로 예상 동작 정의**, 적대적 테스트 시나리오 생성, UI와 SDK 또는 API 모두로 결과 평가 가능 - 전통 테스트 접근이 결정론적 동작 가정하는 반면 **AI 시스템은 더 미묘한 방식으로 실패** — jailbreak, 멀티턴 상호작용, 정책 위반, 컨텍스트 의존 엣지 케이스 포함 - 단순 프롬프트 평가 이상이 필요한 팀에 유용한 플랫폼 - [conversation simulator](https://docs.rhesis.ai/sdk/synthesizers/conversational), 적대적 테스트, OpenTelemetry 기반 추적, Docker 통한 자체 호스팅 같은 기능이 제품·도메인·엔지니어링 팀을 공유 테스트 워크플로우로 가져오는 실용적 방식 - 주요 이점은 **비결정론적 시스템에 대한 프로덕션 전 검증 개선** - 평가 비용, LLM-as-judge 메트릭의 한계, 플랫폼이 가치 전달 전 잘 정의된 요구 사항 필요 같은 일반 트레이드오프 고려 필요 - 기본 프롬프트 체크 이상의 협업 가능, 반복 가능 테스트 필요한 LLM이나 agentic 시스템 구축 팀에 평가할 가치 **62. RunPod** - 조직들이 LLM 훈련과 미세 조정 실험 증가, AWS와 Google Cloud 같은 **하이퍼스케일러는 높은 비용과 제한된 하드웨어 가용성** 도입 가능 - [RunPod](https://www.runpod.io/)이 컴퓨팅 집약적 AI 워크로드용 **비용 효과적 대안** 제공 - 글로벌 분산 GPU 마켓플레이스로 운영, 엔터프라이즈급 H100 클러스터부터 소비자급 RTX 4090까지 광범위한 하드웨어 온디맨드 접근 제공, 종종 **전통 클라우드 공급자보다 상당히 낮은 비용** - 장기 약정이나 벤더 종속 없이 AI 모델 개발·훈련·배포할 유연하고 예산 친화적 인프라 필요한 팀에 평가할 가치 있는 실용적 옵션 **63. Sprites** - **AI 코딩 에이전트 격리 실행 위해 설계된 Fly.io의 상태 저장 샌드박스 환경** - 대부분 에이전트 샌드박스가 일회용으로 작업 위해 생성되고 사라지는 반면, [Sprites](https://fly.io/blog/sprites/)는 **무제한 체크포인트와 복원 역량 갖춘 영구 Linux 환경** 제공 - 개발자가 설치된 의존성, 런타임 구성, 파일 시스템 변경 포함 **전체 환경 상태 스냅샷** 가능, 에이전트가 궤도 이탈 시 롤백 가능 - 이는 Git 단독으로 복구 불가능한 것을 넘어, 버전 관리가 추적하지 않는 **시스템 상태 포착** - 팀들이 [sandboxed execution for coding agents](https://www.thoughtworks.com/radar/techniques/sandboxed-execution-for-coding-agents)를 합리적 기본값으로 점점 채택함에 따라, Sprites는 스펙트럼의 한쪽 끝 대표 — **일회용 컨테이너의 단순함을 더 풍부한 복구 옵션으로 교환하는 비일회용 상태 저장 접근** - 에이전트 샌드박싱 평가 팀은 [Dev Containers](https://www.thoughtworks.com/radar/tools/dev-containers) 같은 일회용 대안과 함께 필요와 워크플로우에 따라 Sprites 고려 **64. torchforge** - **언어 모델의 대규모 사후 훈련을 위해 설계된 PyTorch 네이티브 강화 학습 라이브러리** - 알고리듬 로직을 인프라 관심사에서 분리하는 **상위 수준 추상화** 제공, [Monarch](https://www.thoughtworks.com/radar/platforms/monarch)를 조정에, vLLM을 추론에, [torchtitan](https://www.thoughtworks.com/radar/platforms/torchtitan)을 분산 훈련에 오케스트레이션 - 이 접근으로 연구자가 **의사 코드 같은 API로 복잡한 강화 학습 워크플로우 표현** 가능, 리소스 동기화·스케줄링·결함 허용 같은 저수준 관심사 관리 없이 수천 GPU 전반 워크로드 확장 - "무엇"(알고리듬 설계)을 "어떻게"(분산 실행)에서 분리해 [torchforge](https://github.com/meta-pytorch/forge)가 **대규모 정렬 시스템에서 실험과 반복 단순화** - 고급 사후 훈련 기법을 더 접근 가능하게 만드는 유용한 단계, 단 팀은 기존 ML 인프라 내 **성숙도와 적합성 평가** 필요 **65. torchtitan** - **생성 AI 모델의 대규모 사전 훈련을 위한 PyTorch 네이티브 플랫폼**, 고성능 분산 훈련용 깔끔하고 모듈식 참조 구현 제공 - 고급 분산 프리미티브를 응집된 시스템으로 모아 **데이터·텐서·파이프라인·컨텍스트 병렬화의 [4D 병렬화](https://pytorch.org/blog/training-using-float8-fsdp2/)** 지원 - Llama 3.1 405B 규모 모델 훈련이 상당한 규모와 효율 요구함에 따라, [torchtitan](https://github.com/pytorch/torchtitan)이 **대형 훈련 워크로드 구축·운영의 실용적 기반** 제공 - 모듈식 설계로 팀이 프로덕션 준비성 유지하면서 병렬화 전략 실험·진화 용이 - PyTorch 생태계에서 대규모 모델 훈련 표준화의 유용한 단계, 특히 **자체 사전 훈련 인프라 구축 팀**에 적합 ### [Tools] #### Adopt **66. Axe-core** - 웹사이트와 다른 HTML 기반 애플리케이션의 **접근성 이슈 감지** 오픈소스 테스트 도구 - [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) 같은 표준 준수 페이지 체크 — A, AA, AAA 적합성 수준 포함 — 일반 접근성 모범 사례 표시 - 2021년 Trial로 Radar 첫 등장 이후 여러 팀이 클라이언트와 [Axe-core](https://github.com/dequelabs/axe-core) 도입 - 접근성이 점점 필수 품질 속성, 유럽에서는 [European Accessibility Act](https://ec.europa.eu/social/main.jsp?catId=1202) 같은 규제로 조직이 디지털 서비스 접근성 요구 사항 충족 의무화 - CI 파이프라인에서 자동화된 체크 활성화로 현대 개발 워크플로우에 잘 맞음 - 팀이 회귀 방지, 규정 준수 유지, 개발 중 조기 피드백 받기 도움, 특히 **AI 지원과 agentic 코딩 도구 광범위 도입 시 접근성을 피드백 루프 일부로 보장** **67. Claude Code** - Anthropic의 **복잡한 다단계 워크플로우 계획·실행** agentic AI 코딩 도구 - Thoughtworks 내외부 팀이 프로덕션 소프트웨어 전달에 일상적으로 사용, **역량과 사용성의 벤치마크**로 널리 취급되어 Adopt로 이동 - CLI 에이전트 환경이 OpenAI의 [Codex CLI](https://www.thoughtworks.com/radar/tools/openai-codex), Google의 [Gemini CLI](https://github.com/google-gemini/gemini-cli), [OpenCode](https://www.thoughtworks.com/radar/tools/opencode), [pi](https://www.thoughtworks.com/radar/tools/pi) 같은 도구로 빠르게 확장되었으나, [Claude Code](https://www.anthropic.com/claude-code)가 많은 팀의 선호 옵션 - 사용이 코드 작성을 넘어 **사양, 스토리, 구성, 인프라, 문서, markdown 정의 비즈니스 프로세스** 포함 광범위한 워크플로우 실행으로 확장 - 스킬, 서브에이전트, 원격 통제, agentic 팀 워크플로우 같은 다른 도구가 따라가는 기능 지속 도입 - 도입 팀은 절제된 운영 실천과 페어링 필요, agentic 코딩이 개발자 노력을 수동 구현에서 **의도, 제약, 리뷰 경계 명세**로 전환 - 전달 가속화 가능하지만 [AI 생성 코드에 대한 안일함](https://www.thoughtworks.com/radar/techniques/codebase-cognitive-debt) 위험 증가, 사람과 에이전트 모두에게 시스템 유지·진화 어려워짐 - agentic 워크플로우 더 신뢰성 있게 만드는 [컨텍스트 엔지니어링](https://www.thoughtworks.com/radar/techniques/context-engineering)(주제 인식, 범위 기반 컨텍스트 선택)과 [curated shared instructions](https://www.thoughtworks.com/radar/techniques/curated-shared-instructions-for-software-teams) 구현 방법으로 [harness engineering](https://martinfowler.com/articles/exploring-gen-ai/30-harness-engineering.html)에 관심 증가 **68. Cursor** - Claude Code와 함께 **전달 팀의 기본 선택**으로 일관되게 등장하는 가장 널리 채택된 코딩 에이전트 중 하나 - **plan mode, hooks, subagents** 같은 기능 갖춘 종합 agentic 환경으로 성숙 - 터미널 기반 에이전트도 인기 있지만, 많은 개발자가 IDE 내 에이전트 감독이 실행 전 계획 검토·정제에 더 풍부한 경험 제공한다고 발견 - [Agent Client Protocol](https://github.com/zed-industries/agent-client-protocol) 도입으로 대형 JetBrains 사용자 기반 장벽 낮추어 [Cursor](https://cursor.com/) 역량을 해당 IDE에서 접근 가능하게 함 - **개별 에이전트 단계 검사 능력**이나 계획 이탈 시 이전 단계로 롤백 능력 특히 가치 있음 - [Agent Skills](https://www.thoughtworks.com/radar/techniques/agent-skills) 활용으로 팀이 재사용 가능 지시 패키징, 에이전트가 복잡 코드베이스와 상호작용하는 방법 표준화 도움 - 생산성 이득 명확하지만, **agentic 자율성은 여전히 미묘한 회귀 잡기 위해 엄격한 자동화 테스트와 인간 감독 필요** **69. Kafbat UI** - Apache Kafka 클러스터 모니터링·관리용 **무료 오픈소스 웹 UI** - 팀이 일상 디버깅 중 읽기 어려운 페이로드 검사 필요 시 특히 유용 - 팀이 종종 **암호화된 메시지 디버깅에 막힘**, [Kafbat UI](https://github.com/kafbat/kafka-ui)의 내장과 플러그인 가능 SerDes 지원이 복호화나 커스텀 디코딩 적용해 메시지를 다시 읽을 수 있게 하는 실용적 방법 제공 - 일회성 디버그 스크립트 대비 더 빠른 피드백과 개발자·지원 팀에 더 나은 운영 경험 제공 - **안전한 메시지 검사와 효율적 문제 해결이 표준 실천이어야 하는 Kafka 무거운 환경**에 권장 **70. mise** - 마지막 평가 이후 [asdf](https://asdf-vm.com/)의 고성능 대안에서 **개발 환경의 기본 프론트엔드**로 진화 - **도구·언어 버전 관리, 환경 변수 관리, 작업 실행** 세 가지 파편화된 관심사를 단일 고성능 Rust 기반 도구로 통합, 선언적 `mise.toml` 파일로 구성 - [mise](https://mise.jdx.dev/)는 설정 쉽고 CI/CD 파이프라인과 잘 작동 - [Cosign](https://docs.sigstore.dev/cosign/system_config/installation/)과 [GitHub Artifact Attestations](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds) 통합 통해 **다른 버전 관리자에 종종 누락된 공급망 보안 레이어** 추가 - 개발자 환경 설정 표준화 추구 팀에 권장 기본값 - 다중 마이크로서비스 polyglot 환경에서 코드베이스가 동시에 새 언어 버전 채택 시 특히 유용 - 기존 언어별 도구와도 작동하므로 팀이 한 번에 모두 마이그레이션할 필요 없음 #### Trial **71. cargo-mutants** - **Rust용 mutation testing 도구**, 단순 코드 커버리지 메트릭을 넘어 이동 도움 - 연산자 스왑이나 기본값 반환 같은 **작고 의도적인 버그를 자동 주입**, 기존 테스트가 회귀를 실제로 잡는지 검증 - 제로 구성 접근이 특히 효과적, 이전 도구와 달리 **소스 트리 변경 불필요** - Rust 새내기 팀에 유용한 피드백 루프 제공, 누락된 엣지 케이스 식별과 단위·통합 테스트 신뢰성 개선 - [cargo-mutants](https://github.com/sourcefrog/cargo-mutants)는 다른 생태계에서도 시도 중인 [mutation testing](https://www.thoughtworks.com/radar/techniques/mutation-testing)의 전문 구현 - 주 비용은 테스트 실행 시간 증가, 각 mutant가 증분 빌드 필요 - 관리 위해 로컬 개발 중 특정 모듈 타겟팅이나 CI에서 전체 스위트 비동기 실행 권장 - 논리적으로 동등한 mutant 필터링 필요 가끔 있을 수 있지만, **결과적 테스트 신뢰성 증가가 추가 노이즈 능가** **72. Claude Code plugin marketplace** - 이전에는 커스텀 명령, 전문 에이전트, MCP 서버, [스킬](https://www.thoughtworks.com/radar/techniques/agent-skills) 공유가 개발자가 Confluence나 다른 외부 소스에서 지시를 복사·붙여넣기하는 **수동 프로세스** - 이로 인해 종종 버전 드리프트 발생, 팀원들이 오래된 프로젝트 지시 사용 - 팀들이 [Claude Code plugin marketplace](https://docs.anthropic.com/en/docs/claude-code/plugin-marketplaces)를 활용해 **Git 기반 배포 모델** 사용, 공유 명령·프롬프트·스킬 배포 - GitHub이나 유사 플랫폼에 내부 팀 마켓플레이스 호스팅으로 조직이 이러한 아티팩트를 더 안전하고 일관되게 배포 가능 - 개발자가 CLI 통해 AI 기반 워크플로우와 도구를 로컬 환경으로 직접 동기화 가능 - [Cursor](https://www.thoughtworks.com/radar/tools/cursor) 같은 다른 코딩 에이전트도 팀 [plugin marketplace](https://docs.cursor.com/en/plugins/marketplace) 지원, 이러한 아티팩트 공유의 더 간소화되고 거버넌스된 방식 활성화 **73. Dev Containers** - `devcontainer.json` 구성 파일 사용해 **재현 가능한 컨테이너화 개발 환경 정의**의 표준화된 방식 - 원래 팀에 일관된 개발 설정 제공 위해 설계, **코딩 에이전트용 [샌드박스 실행 환경](https://www.thoughtworks.com/radar/techniques/sandboxed-execution-for-coding-agents)으로 매력적인 새 사용 사례** 발견 - [Dev Container](https://containers.dev/) 내에서 AI 코딩 에이전트 실행 시 호스트 파일 시스템·자격 증명·네트워크에서 격리, 팀이 호스트 머신 위험 없이 **에이전트에 광범위한 권한 부여** 가능 - [오픈 사양](https://containers.dev/implementors/spec/)이 VS Code와 Cursor 같은 VS Code 기반 도구에서 네이티브 지원 - [DevPod](https://devpod.sh/)이 SSH 통해 모든 에디터나 터미널 워크플로우로 devcontainer 지원 확장 - **일회용 기본 접근**(즉, 컨테이너가 시작 시마다 구성에서 재구축) 채택, 도구와 의존성 재설치 비용으로 깨끗한 보안 경계 제공 - 영구 상태나 체크포인트·복원 역량 필요 팀에는 [Sprites](https://www.thoughtworks.com/radar/platforms/sprites) 같은 다른 접근 대안 - 에이전트 샌드박싱 외에도 공급망 보안 이점 제공, 도구 체인을 선언적 구성에 정의해 **손상된 패키지와 예상치 못한 의존성 노출 감소** **74. Figma Make** - 이전에 self-serve UI prototyping with GenAI 블립, 이 기법은 이제 제품 매니저와 디자이너 포함 개발 팀에 의해 **사용자 테스트 가능 고충실도 프로토타입 생성**에 널리 채택 - [Figma Make](https://www.figma.com/make/)는 디자인 시스템의 **실제 컴포넌트와 레이어 활용**해 결과가 프로덕션 애플리케이션과 매우 유사하게 만드는 강력한 옵션 - 고품질 디자인 패턴으로 훈련된 맞춤 AI 모델 사용 - 팀이 새 디자인 화면 생성, 기존 화면 향상, **빠른 사용자 피드백 수집을 위한 공유 가능 프로토타입** 구축에 사용 중 **75. OpenAI Codex** - **macOS 앱과 CLI 통해 사용 가능한 독립 agentic 코딩 도구**로 진화 - 자율 작업 위임용으로 설계 — 프롬프트 주어지면 최소 개입으로 파일 전반 계획·구현·반복 - **고속 초안 도구**로 효과적, 특히 그린필드 작업과 반복 구현 작업에 유용 - 그러나 [OpenAI Codex](https://github.com/openai/codex)가 **논리적으로 건전하지만 기능적으로 오래된 라이브러리 패턴 제안 경향**으로 자동화 테스트와 인간 리뷰 필수 - 이 Radar의 다른 agentic 도구처럼 **미묘한 기술 부채 누적 위험은 실재**하며 팀이 부여하는 자율성 수준에 비례 **76. Typst** - **프로그램적 문서 생성을 위한 LaTeX의 현대적 후속**으로 자리매김한 마크업 기반 조판 시스템 - 고품질 타이포그래피와 더 단순한 구문 결합, 매우 큰 문서도 전통 LaTeX 도구 체인의 일부 시간으로 컴파일하는 **상당히 빠른 컴파일 파이프라인** 제공 - [Typst](https://typst.app/)는 더 명확한 에러 메시지와 조건문·루프 같은 내장 스크립팅 역량 제공 - JSON이나 CSV에서 구조화 데이터 로드 가능, **자동화 문서 생성에 잘 적합** - 팀들이 일관된 형식으로 대규모 생성 필요한 은행과 금융 서비스 고객용 명세서와 보고서 생성에 사용 - 오픈소스 컴파일러 자체 호스팅 가능, 성장하는 생태계에 커뮤니티 기여 패키지 포함 - LaTeX보다 접근 가능하면서 **비교 가능한 타이포그래피 품질** 전달 #### Assess **77. Agent Scan** - MCP 서버와 스킬 포함 **로컬 컴포넌트 발견하고 프롬프트 인젝션, 도구 오염, toxic flow, 하드코딩된 시크릿, 안전하지 않은 자격 증명 처리 같은 위험 표시**하는 에이전트 생태계용 보안 스캐너 - **에이전트 공급망 가시성의 신흥 간극** 해결, 빠르게 성장하는 에이전트 표면 인벤토리·테스트할 실용적 방법 제공 - 그러나 도입은 의도적이어야 함 — 스캔이 **컴포넌트 메타데이터를 Snyk API와 공유** 필요, 신호 품질과 false-positive 비율이 환경에서 검증 필요 - 팀이 [Agent Scan](https://snyk.io/articles/snyks-evolving-agentic-threat-landscape/)을 필수 전달 게이트 일부로 만들기 전 **운영 가치 확인** 중요 **78. Beads** - **코딩 에이전트용 영구 메모리 레이어**로 설계된 Git 기반 이슈 트래커 - 임시 Markdown 계획에 의존 대신 에이전트에 **블로커 관계, 준비 작업 감지, 세션 전반 장기 작업 조정용 브랜치 친화적 구조의 작업 그래프** 제공 - [Beads](https://github.com/steveyegge/beads)는 브랜치, 머지, diff, 테이블 복제를 Git 리포지토리와 유사하게 지원하는 내장 버전 관리 SQL 데이터베이스인 [Dolt](https://www.dolthub.com/) 위에 구축 - **에이전트 네이티브 프로젝트 메모리와 작업 추적 도구의 새 카테고리** 대표 - 이 공간의 다른 초기 프로젝트는 [ticket](https://github.com/sublayerapp/ticket)과 [tracer](https://github.com/keithcurtis/tracer) - GitHub Issues와 Jira 같은 전통 티켓팅 시스템과 달리, **에이전트가 서로 작업 할당 포함 자율 멀티 에이전트 실행 조정의 새 워크플로우** 활성화 **79. Bloom** - **LLM 동작 평가하는 AI 안전 연구자용 Anthropic 도구** - sycophancy(아첨)와 self-preservation(자기 보존) 같은 동작 탐지 - 정적 벤치마크 대비 **타겟 동작과 평가 매개변수 정의하는 시드 구성 사용**해 다양한 테스트 대화 동적 생성 후 결과 평가 - 이 [자동화 행동 평가](https://www.anthropic.com/research/petri-bloom)에 대한 접근은 모델 출시 속도 따라가기 위해 필수, 외부 연구 팀이 평가 수행 가능하게 함 - [Petri](https://github.com/safety-research/petri)가 동반 도구로 주어진 모델에서 어떤 동작이 나타나는지 식별, [Bloom](https://github.com/safety-research/bloom)은 어떤 시나리오에서 얼마나 자주 그러한 동작 발생하는지 식별, 함께 더 완전한 평가 스위트 형성 - Bloom이 **주어진 학생 모델 평가하는 교사(또는 평가자) 모델 필요**가 한 우려, 교사 모델은 맹점과 편향 가질 수 있어 **다중 평가자 사용으로 결과 편향 감소** 가능 - AI 안전 연구 팀이 신흥 모델 동작 평가에 정적 벤치마크 보완으로 평가할 가치 **80. CDK Terrain** - 2025년 12월 HashiCorp가 사용 중단·아카이브한 **Cloud Development Kit for Terraform([CDKTF](https://developer.hashicorp.com/terraform/cdktf))의 커뮤니티 포크** - [CDK Terrain](https://github.com/cdk-terrain/cdktn)(CDKTN)이 CDKTF가 중단된 곳에서 이어받음, 팀이 TypeScript, Python, Go로 인프라 정의하고 Terraform이나 OpenTofu 통해 프로비저닝 가능 - 이미 CDKTF 투자 팀에 기존 코드와 워크플로우 보존, [HCL](https://github.com/hashicorp/hcl)이나 [Pulumi](https://www.pulumi.com/)로 강제 이동 대신 **마이그레이션 경로 제공** - 프로젝트가 매월 릴리스, OpenTofu 지원을 일급 타겟으로 추가 - 그러나 **벤더 포기 프로젝트의 커뮤니티 유지 포크는 장기 지원 관련 본질적 위험** 동반, CDKTF 접근은 광범위 도입 달성 못함 - HashiCorp가 종료 시 제품-시장 적합성 부족 인용 - 현재 CDKTF 사용 팀은 CDK Terrain을 연속 옵션으로 평가, **더 광범위 지원 접근으로 마이그레이션의 적기인지도 저울질** 필요 **81. CodeScene** - 2017년에 social code analysis 블립, **코딩 에이전트 도입 증가로 [CodeScene](https://codescene.com/) 같은 도구에 새로운 관심** - **코드 복잡성 메트릭과 버전 관리 이력 결합**해 기술 부채 식별하는 행동 코드 분석 도구 - 전통 정적 분석과 달리 **"hotspot"을 강조**해 팀이 실제 개발 활동과 비즈니스 영향 기반 리팩토링 우선순위 도움 - 이제 [AI 친화적 코드 설계](https://codescene.com/blog/refactoring-vs-rewriting-code-for-ai)용 가이던스 제공 - 팀들이 코딩 에이전트가 인간 개발자보다 훨씬 빠르게 코드 수정 가능하므로 **코드 품질이 더욱 중요**해짐 발견 - CodeScene의 CodeHealth 메트릭이 **LLM이 환각 위험 없이 안전하게 리팩토링하기에 너무 복잡한 영역 식별**해 유용한 가드레일 제공 - 코딩 에이전트 도입의 가드레일로 평가 권장, CodeHealth 메트릭이 **안전한 리팩토링 타겟 강조**하고 에이전트 적용 전 개선 필요 영역 표시 **82. ConfIT** - 통합과 컴포넌트 스타일 API 테스트를 코드로 명령형으로 작성 대신 **JSON으로 선언적 정의**하는 라이브러리 - 큰 테스트 스위트가 종종 HTTP 클라이언트, 요청 설정, 단언 주변 보일러플레이트 누적하므로 이 접근에 관심 증가 - AI 지원 개발이 이 추세 강화, **구조화된 테스트 정의가 장황한 절차적 코드보다 생성·유지 쉬워짐** - 클라이언트 경험과 평가 기반, 선언적 레이어가 컴포넌트와 통합 테스트 간 중복 감소, 가독성 개선, 팀 전반 테스트 의도 진화 용이 - 그러나 [ConfIT](https://github.com/confit-net/confit) 자체는 **제한된 커뮤니티 도입과 작은 생태계** 보유, 이러한 이점에도 광범위 권장 어려움 - 사양 주도 API 테스트 탐색 .NET 팀에 평가할 가치, 단 **장기 유지 가능성, 생태계 적합성, 운영 트레이드오프 검증** 필요 **83. Entire CLI** - Git 워크플로우에 후크해 **AI 코딩 에이전트 세션 — 트랜스크립트, 프롬프트, 도구 호출, 터치된 파일, 토큰 사용량 — 을 전용 리포지토리 브랜치에 저장된 검색 가능 메타데이터로 캡처** - [Claude Code](https://www.thoughtworks.com/radar/tools/claude-code), Gemini CLI, [OpenCode](https://www.thoughtworks.com/radar/tools/opencode), [Cursor](https://www.thoughtworks.com/radar/tools/cursor), Factory AI Droid, GitHub Copilot CLI 지원 - AI 에이전트가 코드베이스의 주 기여자가 됨에 따라 팀들이 **Git이 추적하는 것과 코딩 세션 중 실제 일어나는 것 사이의 간극 증가**에 직면 - [Entire CLI](https://github.com/entire-cli/entire-cli)가 메인 브랜치 이력 오염 없이 **커밋과 함께 전체 세션 기록해 에이전트 활동 감사 추적** 생성 - 체크포인트 시스템도 실용적 복구 활성화, 팀이 에이전트 이탈 시 알려진 양호 상태로 되감기와 모든 체크포인트에서 재개 가능 - 도구가 매우 새롭고 에이전트 세션 추적성 생태계가 여전히 형성 중이지만, **AI 생성 코드 관련 규정 준수나 감사 요구 사항 있는 팀**에 Git 네이티브 세션 캡처가 자연스러운 적합 **84. Git AI** - 리포지토리에서 **AI 생성 코드 추적**, 모든 AI 작성 라인을 생성한 에이전트, 모델, 프롬프트에 연결하는 오픈소스 Git 확장 - [Git AI](https://github.com/iharkatkavets/git-ai)가 체크포인트와 후크 사용해 커밋 시작과 끝 사이의 **증분 코드 변경 추적** - 각 체크포인트는 현재 상태와 이전 체크포인트 간 diff 포함, AI 또는 인간 작성으로 표시 - 이 접근은 삽입 시점에 코드 라인 수 카운팅에 집중하는 접근보다 **더 정확** - Git Notes로 AI 생성 코드 추적용 [오픈 표준](https://github.com/git-ai-spec/git-ai-spec) 사용 - 지원 에이전트 생태계가 여전히 성숙 중이지만, **agentic 워크플로우에서 장기 책임성과 유지 가능성 유지하려는 팀**에 평가할 가치 - 인간과 AI 에이전트 모두 `/ask` 스킬 통해 아카이브된 에이전트 세션 참조해 **특정 코드 블록 뒤의 원래 의도와 아키텍처 결정 쿼리** 가능 **85. Google Antigravity** - Windsurf에서 라이선스된 기술 위에 구축된 독립 VS Code 포크, 2025년 11월 Gemini 3와 함께 [공개 프리뷰로 출시](https://blog.google/technology/google-deepmind/gemini-3/#agentic-flagship) - IDE를 **멀티 에이전트 오케스트레이션 중심으로 재구성** — Agent Manager가 작업 전반 다중 에이전트 병렬 실행, 내장 Chromium 브라우저로 에이전트가 라이브 UI와 직접 상호작용, 스킬 시스템이 재사용 가능 에이전트 지시를 리포지토리에 저장 - Agent Manager가 표준 챗 사이드바보다 **"Mission Control" 대시보드** 역할, 개발자 역할을 라인별 코드 작성에서 **다중 자율 워크스트림 오케스트레이션**으로 근본적 전환 - 필요 시 개발자가 여전히 human-in-the-loop(HITL) 통제 위해 에디터로 들어갈 수 있음 - [Google Antigravity](https://antigravity.google/)가 [Model Context Protocol](https://modelcontextprotocol.io/) 통해 Google Cloud와 Firebase와 통합, [Agent Development Kit](https://www.thoughtworks.com/radar/languages-and-frameworks/agent-development-kit-adk)로 에이전트 개발 지원 - 공개 프리뷰 상태 유지, GA 날짜 없음, **보안 자세와 엔터프라이즈 준비성 여전히 진화 중** - 멀티 에이전트 실행 모델과 자율 브라우저 접근이 agentic IDE의 방향 신호 **86. Google Mainframe Assessment Tool** - 조직이 **메인프레임에서 실행되는 애플리케이션 리버스 엔지니어링** 도움, 전체 포트폴리오나 개별 시스템 분석 - 핵심에 **결정론적 언어 파서 의존**해 코드베이스 전반 호출 흐름과 데이터 의존성 매핑, 애플리케이션 상호작용 방식의 구조적 뷰 생성 - 이 기반 위에 생성 AI 기능이 **요약, 문서화, 테스트 케이스 생성, 현대화 제안** 제공 - 이 접근은 [GenAI를 사용한 레거시 코드베이스 이해](https://martinfowler.com/articles/legacy-modernization-gen-ai.html)의 더 광범위한 패턴과 정렬, 시스템에 대한 강력한 통찰이 AI 효과적 사용의 기반 형성 - [Google Mainframe Assessment Tool](https://github.com/Google-Cloud-DevRel/mainframe-assessment-tool)이 모든 주요 메인프레임 기술 스택을 아직 지원하지 않지만 빠르게 진화 중 - 팀들이 **메인프레임 애플리케이션 발견과 현대화에 집중한 클라이언트 참여**에 도움이 됨을 발견 **87. OpenCode** - 강력한 **터미널 우선 경험** 가진 가장 두드러진 오픈소스 코딩 에이전트 중 하나로 빠르게 부상 - 주요 강점은 **모델 유연성** — 호스팅 프론티어 모델, 자체 호스팅 엔드포인트, 로컬 모델 지원 - [OpenCode](https://opencode.ai/)를 비용 통제, 커스터마이즈, **에어 갭 설정 포함 제한된 환경**에 매력적으로 만듦 - 사용자가 구독이나 API 사용 시 라이선스와 공급자 약관에 대해 명시적이어야 함을 의미 - OpenCode의 확장 모델이 매력의 또 다른 핵심, **팀별 워크플로우, 도구, 가드레일용 플러그인과 MCP 통합 모두 지원** - 많은 사용자가 [Oh My OpenCode](https://github.com/jasenmichael/Oh-My-OpenCode)를 활용, 조정된 에이전트 팀과 더 풍부한 오케스트레이션 패턴 갖춘 더 의견 있고 **batteries-included 설정 제공하는 선택적이지만 인기 있는 harness** **88. OpenSpec** - AI 코딩 에이전트 역량 진화에 따라 개발자가 요구 사항과 컨텍스트가 일시적 챗 이력에만 존재할 때 **예측가능성과 유지가능성 과제**에 점점 직면 - 이를 해결하기 위해 **spec-driven development(SDD) 도구** 등장 - [OpenSpec](https://github.com/Fission-AI/OpenSpec)은 코드 생성 전 인간 개발자와 AI 에이전트가 **무엇을 구축할지 정렬 보장**하는 경량 사양 레이어 도입하는 오픈소스 SDD 프레임워크 - 차별점은 **유동적이고 최소한의 워크플로우**, 종종 세 단계로 축소 — propose → apply → archive - 많은 SDD 프레임워크([GitHub Spec Kit](https://www.thoughtworks.com/radar/languages-and-frameworks/github-spec-kit) 등)나 Agentic Skills 워크플로우([Superpowers](https://www.thoughtworks.com/radar/languages-and-frameworks/superpowers) 등)가 브라운필드보다 **그린필드 프로젝트에 더 적합** - OpenSpec의 완전한 사양 선행 정의 대신 [spec deltas에 집중](https://github.com/Fission-AI/OpenSpec?tab=readme-ov-file#why-deltas)이 특히 좋음, **기존 시스템에 잘 적합** - 더 엄격한 워크플로우 강제 무거운 대안([BMAD](https://github.com/bmad-code-org/BMAD-METHOD) 등)이나 벤더 특정 IDE 통합 필요([Kiro](https://kiro.dev/) 등)와 달리 **반복적이고 도구 중립** - 무거운 프로세스 채택 없이 AI 지원 개발에 구조와 예측가능성 도입하려는 팀에 평가할 가치 있는 개발자 친화적 프레임워크 - 동시에 모델과 코딩 에이전트가 더 강력해짐에 따라 팀이 네이티브 역량 모니터·재방문하고 SDD 도구 필요성 재평가도 권장 **89. PageIndex** - 전통 임베딩 기반 검색 의존 대신 **벡터 없는 추론 기반 RAG 파이프라인용 문서의 계층적 인덱스** 구축 도구 - 문서를 벡터로 청킹하면 구조 정보 손실되고 결과 검색 이유 가시성 제한될 수 있는 반면, [PageIndex](https://github.com/VectifyAI/PageIndex)는 **LLM이 단계별로 순회해 관련 콘텐츠 검색하는 목차 인덱스** 구축 - 인간이 헤딩 스캔 후 특정 섹션으로 드릴다운하는 방식과 유사하게, **특정 섹션이 선택된 이유 설명하는 명시적 추론 추적** 생성 - 의미보다 구조에 의미가 크게 의존하는 문서, 예: **숫자 데이터의 금융 보고서, 교차 참조 조항의 법률 문서, 복잡한 임상이나 과학 문서**에 잘 작동 - 그러나 트레이드오프 동반, LLM 추론이 검색 프로세스 일부이므로 **특히 큰 문서에 상당한 지연과 비용 도입 가능** **90. Pencil** - [Cursor](https://www.thoughtworks.com/radar/tools/cursor)와 [Claude Code](https://www.thoughtworks.com/radar/tools/claude-code) 같은 IDE와 코딩 에이전트와 통합되는 디자인 캔버스 도구 - 현재 읽기 접근만 제공하는 [Figma](https://www.figma.com/)와 달리, [Pencil](https://www.usepencil.com/)은 **양방향 로컬 MCP 서버 실행**해 캔버스 직접 조작에 읽기와 쓰기 접근 모두 제공 - [Figma Make](https://www.thoughtworks.com/radar/tools/figma-make)와 [Builder.io](https://www.builder.io/) 같은 도구처럼 디자인-투-코드 역량도 제공, 단 **더 개발자 중심 접근** — 디자인 파일이 `.pen`이라는 오픈 JSON 형식으로 리포지토리에 저장되어 코드와 함께 디자인 자산 버전 관리 가능 - 개발자에게 친숙한 도구와 통합으로 **디자인-개발 핸드오프 간극 좁히는 데 도움** - 대규모이고 복잡한 디자인 시스템에는 Figma가 여전히 역할 전반 협업 표준 - 그러나 **전담 디자이너 없는 팀이나 강한 디자인 스킬 가진 개발자 있는 팀**에 고려할 가치 **91. Pi** - TypeScript로 작성된 **미니멀리스트 오픈소스 터미널 코딩 에이전트** - 주류 엔터프라이즈 기본값이 아닌 **티커러와 실험자에게 매력적인 옵션** - [Pi](https://github.com/anthropics/codebase-context-assistant)는 [OpenCode](https://www.thoughtworks.com/radar/tools/opencode) 같은 완전한 에이전트보다 **더 커스터마이즈 가능한 베어본 harness** - [ADK](https://www.thoughtworks.com/radar/languages-and-frameworks/agent-development-kit-adk), [LangGraph](https://www.thoughtworks.com/radar/languages-and-frameworks/langgraph), [Mastra](https://www.thoughtworks.com/radar/languages-and-frameworks/mastra) 같은 agentic 프레임워크로 새 에이전트 구축보다 적응 쉬움 - 강한 추진력과 활발한 릴리스에도 프로젝트가 여전히 초기, 주로 유지 관리자 주도 - pi를 **완전한 가드레일과 지원 갖춘 엔터프라이즈 플랫폼이 아닌 엔지니어 대면 빌딩 블록**으로 취급 필요 **92. Qwen 3 TTS** - 많은 유료 API보다 더 큰 개발자 통제 제공하면서 **상용 제품과의 품질 격차를 크게 줄이는** 오픈소스 텍스트-투-스피치 모델 - 다중 언어 지원, 짧은 샘플(약 10-15초)에서 음성 클로닝 가능, 도메인이나 캐릭터 특정 음성을 위한 사후 훈련 미세 조정 허용 - **브랜드 특정 음성이나 온프렘 통제 필요한 팀**에 매력적인 옵션 - [Qwen 3 TTS](https://qwen.ai/blog?id=fd00cb47b6f74c2890ea0ab9f54c14fa&from=research.research-list)는 여전히 최근 출시, 팀이 프로덕션 중요 음성 워크로드 도입 전 **안정성, 안전 통제, 라이선스 적합성, 운영 성숙도 검증** 필요 **93. SGLang** - 프론트엔드 프로그래밍 언어와 백엔드 런타임의 **공동 설계 통해 LLM 추론의 컴퓨팅 오버헤드 감소**하는 고성능 서빙 프레임워크 - **RadixAttention 도입**, 프롬프트 전반 KV(키-값) 상태를 적극적으로 캐싱·재사용하는 메모리 관리 기법 - 이 접근은 **높은 prefix overlap 시나리오에서 vLLM 같은 표준 서빙 엔진 대비 상당한 성능 개선** 전달 - 복잡한 자율 에이전트 구축, 긴 시스템 프롬프트 의존, 공유 예시로 광범위한 few-shot 프롬프팅 사용 팀에 [SGLang](https://github.com/sgl-project/sglang)이 지연과 효율성에서 상당한 이득 제공 가능 **94. ty** - Python이 특히 AI와 데이터 사이언스 공간에서 인기 계속 성장, **강력한 타입 시스템 보유가 점점 가치 있어짐** - [Ty](https://github.com/astral-sh/ty)는 Rust로 작성된 **극도로 빠른 Python 타입 체커와 언어 서버** - [uv](https://github.com/astral-sh/uv)와 [ruff](https://github.com/astral-sh/ruff) 같은 도구도 포함하는 [Astral](https://astral.sh/) 생태계의 일부 - 빠른 피드백 제공, Visual Studio Code 같은 일반 에디터와 잘 통합 - ty를 다른 Astral 도구와 함께 사용하면 **대규모 조직에서 Python 개발 단순화** - agentic 코딩이 일반화됨에 따라 **빠른 피드백 루프 갖춘 결정론적 타입 체커 보유**가 실수 조기 잡기와 단순 에러에 대한 코드 리뷰 노력 감소 도움 **95. Warp** - Radar에 마지막 포함 이후 [Warp](https://www.warp.dev/)가 **"AI 기능 갖춘 터미널" 설명을 훨씬 넘어 진화** - 코어 강점 — 블록 기반 명령 출력, AI 기반 제안, 노트북 기능 — 유지하면서 **전통적으로 IDE가 차지한 영역으로 확장** - 이제 Markdown 렌더링, 파일 트리 표시, 터미널에서 직접 파일 열기 가능, 패널 전반 전체 agentic 개발 워크플로우 지원 — 한 패널에 [Claude Code](https://www.thoughtworks.com/radar/tools/claude-code) 같은 코딩 에이전트, 다른 패널에 셸, 세 번째 패널에 워크스페이스 파일 뷰 - 관찰된 실용적 이점은 Warp가 **현대 코딩 에이전트가 생성하는 고처리량 텍스트 출력을 전통 터미널보다 더 잘 처리**, 렌더링 속도와 가독성이 병목될 수 있음 - 내장 코딩 어시스턴트도 추가, 단 팀에서 광범위 평가 안 됨 - Warp가 최근 **터미널과 통합되는 클라우드 에이전트용 오케스트레이션 플랫폼 [Oz](https://www.warp.dev/oz) 출시**, 이 블립은 터미널 자체에 집중 - 가벼운 조합 가능 터미널 선호, 자체 AI 도구 가져오기 원하는 팀은 [Ghostty](https://ghostty.org/)가 더 적합 — Warp의 batteries-included 철학과 대조적으로 **의도적으로 미니멀리스트 접근** - 새 기능 속도와 Warp의 더 광범위한 플랫폼 야망이 제품 안정화와 새 역량에 대한 더 많은 현장 경험 얻기 전까지 Trial로의 이동 시기상조 **96. WuppieFuzz** - **OpenAPI 정의 사용해 유효 요청 생성, 엣지 케이스 탐색 위해 변이, 새 실행 경로 도달하는 입력 우선순위화 위해 서버 측 커버리지 피드백에 의존**하는 REST API용 오픈소스 fuzzer - 대부분 팀이 여전히 예제 기반 통합과 계약 테스트에 의존, **예상치 못한 입력, 비정상 요청 시퀀스, 실패 무거운 경로를 거의 탐색하지 않음**, API가 종종 현대 시스템의 주 통합 표면임에도 - 초기 평가 기반, [WuppieFuzz](https://github.com/TNO-S3/WuppieFuzz)가 이러한 테스트의 유망한 보완으로 보임 — **처리되지 않은 예외, 권한 부여 간극, 민감 데이터 누출, 서버 측 에러, 스크립트 테스트가 놓칠 수 있는 로직 결함** 같은 이슈 발견 가능 - 팀이 여전히 CI에 어떻게 맞는지, 도입하는 런타임 오버헤드, 결과가 실제로 얼마나 유용한지 평가 필요 - 그 이유로 **중요하거나 외부 노출된 REST API 구축 팀**에 평가할 가치 #### Caution **97. OpenClaw** - 작성자가 **"hyper-personal AI assistant" 카테고리**라고 부르는 오픈소스 프로젝트 - 사용자가 자체 인스턴스 호스팅, WhatsApp이나 iMessage 같은 메시징 채널 통해 지속적으로 사용 가능 유지, 연결된 도구 통해 작업 실행 - 대화, 선호도, 습관의 영구 메모리로 **GenAI 챗 인터페이스나 전형적 코딩 에이전트와 실질적으로 다르게 느껴지는 영구 개인 경험** 생성 - 모델이 명백히 매력적이며 [Claude Cowork](https://www.anthropic.com/cowork) 같은 추종자 이미 영감 - [OpenClaw](https://github.com/openclaw/openclaw)를 Caution에 배치한 이유는 모델이 **상당한 보안 트레이드오프** 요구 - 캘린더, 이메일, 파일, 통신에 더 많은 접근 부여할수록 더 유용해지고 [toxic flow analysis for AI](https://www.thoughtworks.com/radar/techniques/toxic-flow-analysis-for-ai)에서 경고한 정확한 패턴으로 **권한 집중** - 이 위험은 OpenClaw에 고유하지 않음, **확립된 벤더 제품 포함 같은 패턴의 다른 구현에도 적용** - OpenClaw [고려 팀을 위한 조언](https://martinfowler.com/articles/2025-openclaw-decision.html)과 [샌드박스 실행 환경](https://www.thoughtworks.com/radar/techniques/sandboxed-execution-for-coding-agents) 게시, [NanoClaw](https://github.com/openclaw/nanoclaw)나 [ZeroClaw](https://github.com/openclaw/zeroclaw) 같은 대안이 폭발 반경 감소 가능 - 그러나 **hyper-personal assistant 패턴 자체가 권한을 탐하고 고위험으로 유지** ### [Languages and Frameworks] #### Adopt **98. Apache Iceberg** - 대규모 분석 데이터셋용 오픈 테이블 형식으로 S3 같은 저장 시스템에 **데이터 파일, 메타데이터, 스키마가 어떻게 조직되는지** 정의 - 최근 몇 년간 크게 진화, **기술 중립적 lakehouse 아키텍처의 기반 빌딩 블록**으로 자리매김 - AWS(Athena, EMR, Redshift), Snowflake, Databricks, Google BigQuery 포함 **모든 주요 데이터 플랫폼 공급자가 지원**, 벤더 종속 회피의 강력한 옵션 - [Apache Iceberg](https://iceberg.apache.org/)를 다른 오픈 테이블 형식과 차별화하는 것은 **기능과 거버넌스 전반의 개방성**, 단일 벤더에 의해 역량이 제한되거나 통제되는 대안과 대조 - 신뢰성 측면에서 스냅샷 기반 설계가 **직렬화 가능 격리, 낙관적 동시성 통한 안전한 동시 쓰기, 롤백 포함 버전 이력** 제공, 성능 병목 없이 강력한 정확성 보장 전달 - [Apache Spark](https://spark.apache.org/)가 가장 일반적인 엔진이지만, [Trino](https://trino.io/), [Flink](https://flink.apache.org/), [DuckDB](https://duckdb.org/) 등도 잘 지원해 엔터프라이즈 데이터 플랫폼부터 가벼운 로컬 분석까지 광범위한 사용 사례에 적합 - 많은 팀에서 **안정적이고 개방된 데이터 형식으로 강한 신뢰** 획득, 현대 데이터 플랫폼 구축 조직의 기본 선택으로 권장 **99. Declarative Automation Bundles** - 이전 Databricks Asset Bundles로 알려졌으며, **Databricks 생태계에 소프트웨어 엔지니어링과 CI/CD 실천 도입**의 주요 도구로 진화 - 크게 성숙해 팀이 **클러스터, ETL 파이프라인, 잡, 머신러닝 모델, 대시보드** 포함 대부분 플랫폼 리소스를 코드로 관리 가능 - `databricks bundle plan` 명령으로 팀이 변경 미리보기, [Terraform](https://www.terraform.io/) 같은 도구로 인프라 관리하는 것과 유사하게 **Databricks 아티팩트에 반복 가능한 배포 실천** 적용 - 대시보드와 ML 파이프라인 같은 전통적으로 변경 가능한 자산을 코드로 취급해 **전통 마이크로서비스와 동일한 엄격함으로 버전 관리·테스트·배포** 가능 - 프로덕션 환경 경험 기반, [Declarative Automation Bundles](https://docs.databricks.com/en/dev-tools/bundles/index.html)가 Databricks에서 데이터와 ML 워크플로우 관리의 신뢰할 수 있는 접근으로 자리매김 - Databricks 생태계에서 광범위 작업 팀은 **인프라 관리 실천 표준화를 위해 도입 고려** 권장 **100. React JS** - 2016년 이후 JavaScript UI 개발의 기본 선택이었으나, [React](https://react.dev/) 19 일부로 **React Compiler의 안정 릴리스** 출시(지난 10월)로 재방문할 가치 - 빌드 시점에 메모이제이션 처리해 수동 `useMemo`와 `useCallback`이 **대부분 불필요**, 팀은 effect 의존성의 정밀 통제 필요 시 이스케이프 해치로 유지 권장 - Meta에서 배틀 테스트되고 Expo SDK 54, [Vite](https://vitejs.dev/), [Next.js](https://nextjs.org/) 지원, **React 대규모 작업 시 오래된 비용이었던 성능 보일러플레이트 카테고리 제거** - React 19는 Actions와 `useActionState`, `useOptimistic` 같은 hooks도 도입, **외부 라이브러리 의존 없이 폼 처리와 데이터 변이 단순화** - 2025년 Linux Foundation 산하 [React Foundation 출시](https://reactfoundation.org/) — Amazon, Expo, Callstack, Microsoft, Software Mansion, Vercel이 Meta와 합류 — 라이브러리의 장기 안정성 강화, **도입 고려 시 신중한 팀들이 역사적으로 인용한 우려 해소** **101. React Native** - **크로스 플랫폼 모바일 개발의 기본 선택**으로 Adopt에 이동 - 이전 Trial이었으나 New Architecture 롤아웃 — 구체적으로 [JSI](https://github.com/nicklockwood/react-native-jsi)와 [Fabric](https://reactnative.dev/architecture/fabric-renderer) — 이 **브릿지 병목과 초기화 속도 관련 오래된 우려 해결** - 복잡한 UI 전환과 데이터 집약적 워크로드에서 **상당한 성능 이득** 관찰 - 비동기 브릿지에서 벗어나며 [React Native](https://reactnative.dev/)가 이제 **단일 코드베이스 유지하면서 네이티브 구현에 필적하는 반응성** 전달 - 다중 프로덕션 프로젝트에서 성공적 사용, [Expo](https://expo.dev/)와 React 중심 생태계가 성숙하고 안정적 - 상태 관리가 여전히 신중한 계획 필요하지만, [fast refresh](https://reactnative.dev/docs/fast-refresh) 워크플로우와 공유 스킬 셋의 생산성 이점이 이러한 비용 상회 - 대부분 하이브리드 모바일 사용 사례에 **성능, 일관성, 속도 추구 팀의 주요 권장** **102. Svelte** - **빌드 시점에 컴포넌트를 최적화된 JavaScript로 컴파일**하는 JavaScript UI 프레임워크, 큰 브라우저 측 런타임이나 가상 DOM에 의존하지 않음 - Trial로 마지막 소개 이후 더 많은 팀이 프로덕션에서 성공적 사용, [SvelteKit](https://svelte.dev/docs/kit/introduction)이 SSR과 풀스택 웹 애플리케이션의 더 견고한 선택으로 만들어 Adopt으로 이동 확신 증가 - [Svelte](https://svelte.dev/)를 선택하는 원래 이유가 여전히 유효 — **작은 번들 생성, 강한 런타임 성능, 더 단순한 컴포넌트 모델** - Svelte 5의 **runes와 snippets** 같은 새 역량이 반응성과 UI 구성을 더 명시적이고 유연하게 만듦 - 더 무거운 프론트엔드 프레임워크 대비 **더 적은 코드로 더 깨끗한 개발 경험** 제공 - 팀 피드백이 점점 **React나 Vue의 신뢰할 수 있는 대안**으로 제시, 틈새 옵션이 아님 - 생태계 친숙도, 채용, 플랫폼 적합성 여전히 고려 필요하지만, **성능과 전달 단순성 중요한 현대 웹 애플리케이션 구축의 합리적 기본값**으로 권장 **103. Typer** - **표준 타입 어노테이션 함수에서 CLI 구축** Python 라이브러리, 자동 도움말 텍스트, 셸 자동 완성, 작은 스크립트에서 큰 CLI 애플리케이션으로의 명확한 경로 제공 - 팀들이 내부 도구, 자동화, AI 인접 개발자 워크플로우를 **일급 CLI로 전환**함에 따라 관련성 증가 - [Typer](https://typer.tiangolo.com/)는 실제 프로젝트에 도입 쉬움, 팀이 얼마나 빠르게 명확하고 읽기 좋은 명령 생성하는지 높이 평가 - 강점 — 타입 힌트 기반 API, 자동 도움말과 자동 완성, 단순 스크립트에서 멀티 명령 CLI로의 **저마찰 경로** - 그러나 Python 특정 솔루션이며 고도로 커스터마이즈된 CLI 동작이나 교차 언어 일관성 필요 시 최선이 아닐 수 있음 - **전달, 운영, 개발자 경험 워크플로우용 CLI 구축 팀**에 권장 #### Trial **104. Agent Development Kit (ADK)** - AI 에이전트 구축·운영을 위한 Google 프레임워크, 오케스트레이션·도구·평가·배포용 **소프트웨어 엔지니어링 지향 추상화** 제공 - Assess에 포함한 이후 생태계와 운영 역량 크게 성숙, 활발한 다국어 개발과 더 강한 관측성·런타임 기능 보유 - 벤더 네이티브 에이전트 프레임워크가 이제 혼잡한 분야 — [Microsoft Agent Framework](https://github.com/microsoft/agents), [Amazon Bedrock AgentCore](https://www.thoughtworks.com/radar/platforms/aws-bedrock-agentcore), [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/), [Claude Agent SDK](https://docs.anthropic.com/en/docs/agents-and-tools/claude-agent-sdk) 등 경쟁 옵션 진전 중 - [LangGraph](https://www.thoughtworks.com/radar/languages-and-frameworks/langgraph)와 [CrewAI](https://www.crewai.com/) 같은 오픈소스 대안이 **프레임워크 이식성과 더 광범위한 생태계 우선순위** 팀에 여전히 강력한 선택 - [ADK](https://google.github.io/adk-docs/)가 일부에서 pre-GA 상태 유지, 간헐적 조잡한 부분과 업그레이드 마찰 있지만 **특히 Google 플랫폼 투자 프로젝트**에서 더 많은 성공적 사용 관찰 **105. DeepEval** - **LLM 성능 평가용 오픈소스 Python 기반 프레임워크** - [LlamaIndex](https://www.llamaindex.ai/)나 [LangChain](https://www.langchain.com/) 같은 프레임워크로 구축된 [RAG](https://www.promptingguide.ai/research/rag) 시스템과 애플리케이션 평가, 모델 [베이스라인과 벤치마크](https://docs.confident-ai.com/docs/benchmarks-overview)에도 사용 가능 - 단순 단어 매칭 메트릭을 넘어 **정확성, 관련성, 일관성 평가**로 실세계 시나리오에서 더 신뢰할 수 있는 평가 제공 - 환각 감지, 답변 관련성 점수, 하이퍼파라미터 최적화 같은 역량 포함, 팀이 **커스텀 사용 사례별 메트릭 정의** 가능한 기능이 특히 유용 - 최근 [DeepEval](https://github.com/confident-ai/deepeval)이 복잡한 agentic 워크플로우와 멀티턴 대화 시스템 지원으로 확장 - 최종 출력 평가를 넘어 [tool correctness](https://docs.confident-ai.com/docs/metrics-tool-correctness), [step efficiency](https://docs.confident-ai.com/docs/metrics-agentic-step-efficiency), [task completion](https://docs.confident-ai.com/docs/metrics-task-completion)용 내장 메트릭 제공, [MCP](https://modelcontextprotocol.io/) 서버와의 상호작용 평가 포함 - 대규모 멀티턴 애플리케이션 스트레스 테스트 위해 테스트 케이스 자동 생성하는 **conversation simulation**도 도입 **106. Docling** - **비구조화 문서를 깔끔하고 기계 판독 가능한 출력으로 변환**하는 오픈소스 Python과 TypeScript 라이브러리 - 레이아웃과 의미 이해에 **컴퓨터 비전 기반 접근** 사용, 스캔 문서 포함 PDF 같은 복잡 입력을 JSON과 Markdown 같은 구조화 형식으로 처리 - [RAG](https://www.promptingguide.ai/research/rag) 파이프라인과 [LLM에서 구조화 출력](https://www.thoughtworks.com/radar/techniques/structured-output-from-llms) 생성에 적합, [ColPali](https://arxiv.org/abs/2407.01449) 같은 비전 우선 검색 접근과 대조 - [Docling](https://github.com/docling-ai/docling)은 [Azure Document Intelligence](https://azure.microsoft.com/en-us/products/ai-services/ai-document-intelligence), [Amazon Textract](https://aws.amazon.com/textract/), [Google Document AI](https://cloud.google.com/document-ai) 같은 독점 클라우드 관리형 서비스의 **오픈소스 자체 호스팅 대안** 제공, [LangGraph](https://www.thoughtworks.com/radar/languages-and-frameworks/langgraph) 같은 프레임워크와 잘 통합 - 텍스트, 테이블, 이미지 포함 매우 큰 파일 포함 디지털과 스캔 PDF 전반 **프로덕션 규모 추출 워크로드에서 잘 수행** - 다운스트림 agentic RAG 워크플로우에 **강한 품질 대 비용 균형** 전달 **107. LangExtract** - 사용자 정의 지시 기반으로 **비구조화 텍스트에서 구조화 정보 추출**하는 Python 라이브러리, 각 추출된 엔티티를 원본 문서 위치에 연결하는 **정밀한 출처 그라운딩** 포함 - 임상 노트와 보고서 같은 **도메인 특정 자료** 처리 - 핵심 강점은 **출처 추적성**, 각 추출 데이터 포인트가 출처로 추적 가능 보장 - 추출된 엔티티를 언어 모델 데이터의 표준 형식인 JSONL 파일로 내보내기 가능, **맥락적 검토를 위한 인터랙티브 HTML 인터페이스**로 시각화 가능 - 문서 처리용 [LLM에서 구조화 출력](https://www.thoughtworks.com/radar/techniques/structured-output-from-llms) 고려 팀은 [LangExtract](https://github.com/SonnetSaif/LangExtract)를 [Pydantic AI](https://ai.pydantic.dev/) 같은 스키마 강제 접근과 함께 평가 필요 - LangExtract는 **장문, 비구조화 소스 자료에 더 적합**, Pydantic AI는 **더 짧고 예측 가능한 입력의 출력 형식 제약에 탁월** **108. LangGraph** - 이전 Radar 이후, 모든 멀티 에이전트 시스템을 **글로벌 공유 상태 갖춘 상태 저장 그래프로 취급**하는 [LangGraph](https://langchain-ai.github.io/langgraph/) 아키텍처가 항상 agentic 시스템 구축의 최선은 아님을 관찰 - [Pydantic AI](https://ai.pydantic.dev/) 같은 프레임워크에서 사용되는 대안 접근도 잘 작동 - **경직된 그래프와 대규모 공유 상태로 시작하는 대신**, 이 접근은 코드 실행 통한 **단순 에이전트 통신을 선호**, 필요 시 그래프 구조 나중에 추가 - 많은 사용 사례에서 **더 간결하고 효과적인 시스템** 생성, 각 에이전트가 필요한 상태에만 접근하므로 추론·테스트·디버깅 쉬워짐 - 결과적으로 **Adopt에서 이동**, 여전히 강력한 도구이지만 모든 agentic 시스템 구축의 **기본 선택으로 더 이상 간주하지 않음** **109. LiteLLM** - 다중 LLM 공급자 위의 **얇은 추상화 레이어로 시작해 본격 AI 게이트웨이로 확장** - API 통합 단순화를 넘어 GenAI 시스템의 일반 교차 관심사 해결 — **재시도와 장애 조치, 공급자 간 로드 밸런싱, 예산 통제 포함 비용 추적** - 팀들이 점점 [LiteLLM](https://github.com/BerriAI/litellm)을 AI 기반 애플리케이션의 **합리적 기본값**으로 도입 - 게이트웨이가 요청 추적, 접근 제어, API 키 관리, 콘텐츠 필터링과 데이터 수정·마스킹 같은 **엣지 수준 가드레일** 포함 거버넌스 관심사 해결의 일관된 장소 제공 - 그러나 차별화 공급자 기능 의존 팀은 종종 공급자 특정 매개변수 필요, 게이트웨이가 제거하려는 **결합 재도입** - `drop_params` 모드가 지원되지 않는 매개변수를 조용히 폐기해, 라우팅 결정 전반 **가시성 없이 역량 상실** 가능 - 운영 통제를 위한 실용적 선택이지만, **공급자 특정 역량 활용은 게이트웨이 의존성과 공급자 결합 코드 모두 유지 의미** **110. Modern.js** - ByteDance의 React 메타 프레임워크, **Module Federation 기반 마이크로 프론트엔드 요구 사항 있는 팀** 대상 Trial 배치 - 트리거는 실용적 — `nextjs-mf`가 **수명 종료(end-of-life)** 방향, Pages Router는 작은 백포트 수정만 받을 예정, 새 개발 미계획, CI 테스트는 2026년 중후반 제거 예상 - Next.js에 공식 Module Federation 지원 부재, 커뮤니티 플러그인 단계적 폐지로, Module Federation 코어 팀이 **federation 기반 아키텍처의 주요 지원 프레임워크로 [Modern.js](https://modernjs.dev/en/) 권장** - `@module-federation/modern-js-v3` 플러그인이 자동 빌드 배선 즉시 제공, **스트리밍 SSR과 Bridge API**는 별도 역량으로 사용 가능 - 그러나 결합에 제한 — `@module-federation/bridge-react`가 아직 Node 환경과 호환되지 않아 **SSR 시나리오에서 Bridge 사용 불가** - 초기 경험 긍정적, Module Federation 이미 사용 팀에 마이그레이션 경로 잘 정의 - **ByteDance 외부 생태계 여전히 성숙 중**, 더 얇은 문서와 업스트림과의 더 긴밀한 참여 계획 필요 - 현재 더 잘 지원되는 대안 없는 **Module Federation 사용 사례에서 투자 정당화** #### Assess **111. Agent Lightning** - **자동 프롬프트 최적화, 지도 미세 조정, agentic 강화 학습** 활성화하는 에이전트 최적화·훈련 프레임워크 - 대부분 에이전트 프레임워크가 에이전트 구축에 집중, 시간 경과에 따른 **개선에는 미집중** - [Agent Lightning](https://github.com/Stanford-ILIAD/agent-lightning)이 [AutoGen](https://github.com/microsoft/autogen)과 [CrewAI](https://www.crewai.com/) 같은 프레임워크 지원하며, 기본 구현 변경 없이 기존 에이전트를 **지속 개선** 가능하게 함 - [Training-Agent Disaggregation](https://arxiv.org/abs/2502.14189)이라는 접근 통해 달성, 훈련과 에이전트 프레임워크 사이에 레이어 도입 - 두 코어 컴포넌트 — **Lightning Server**가 훈련 프로세스 관리하고 업데이트된 모델용 API 노출, **Lightning Client**가 추적 수집해 훈련 지원 위해 서버로 전송하는 런타임 역할 - 확립된 에이전트 배포 보유 팀이 **에이전트 성능 지속 개선 방법으로** 탐색 권장 **112. GitHub Spec Kit** - 이번 사이클 논의에서 **Spec-driven development가 두드러짐**, 두 가지 광범위한 진영 등장 — 최소 구조로 코딩 에이전트의 지속 개선 역량에 의존하는 팀과 **정의된 워크플로우와 상세 사양 선호** 팀 - 여러 팀이 주로 브라운필드 환경에서 [GitHub Spec Kit](https://github.com/github/spec-kit) 사용해 spec-driven 실천 실험 중 - Spec Kit의 핵심 개념은 **constitution**, 소프트웨어 개발 라이프사이클을 정렬하는 기초 규칙 북 - 실제로 유용한 constitution은 보통 **프로젝트 범위, 도메인 컨텍스트, 기술 버전, 코딩 표준, 리포지토리 구조**(예: 헥사고날 아키텍처, 레이어드 모듈) 포착, 에이전트가 의도된 아키텍처 경계 내에서 동작 도움 - [instruction bloat](https://www.thoughtworks.com/radar/techniques/agent-instruction-bloat) 같은 과제도 발생 — 프로젝트 컨텍스트 지속 추가로 증가하는 에이전트 지시 세트와 결국 [context rot](https://research.trychroma.com/context-rot), 한 팀이 재사용 가능 가이던스를 [스킬](https://www.thoughtworks.com/radar/techniques/agent-skills)로 추출해 에이전트 지시를 간결하게 유지, 필요 시에만 상세 컨텍스트 로드로 해결 - 브라운필드 시스템에서 많은 재작업이 불명확한 의도, 숨겨진 가정, 제약의 늦은 발견에서 비롯, 한 팀이 **spec → plan → tasks → coding → review 라이프사이클** 도입해 이슈 조기 표면화 도움 - 시간이 지나며 반복 가능 컨텍스트를 `.github/prompts/speckit.<command>.prompt.md` 같은 파일로 이동, 프롬프트 짧아지고 에이전트 동작 더 일관적 - 불필요한 방어적 체크와 과도하게 장황한 markdown 출력 같은 **조잡한 부분** 보고됨 - Spec Kit 템플릿과 지시 커스터마이즈(예: 생성 markdown 파일 수 제한, 콘솔 장황함 감소)로 일부 이슈 해결 - 궁극적으로 강한 클린 코딩과 아키텍처 실천을 가진 **경험 많은 엔지니어가 spec-driven 워크플로우에서 가장 많은 가치 추출** **113. Mastra** - **AI 애플리케이션과 에이전트 구축용 오픈소스 TypeScript 네이티브 프레임워크** - 그래프 기반 워크플로우 엔진, 다양한 LLM 공급자 통합 접근, human-in-the-loop 일시 중단·재개, RAG와 메모리 프리미티브 제공 - MCP 서버 작성과 평가·관측성용 내장 도구도 포함, 명확한 개발자 문서 지원 - [Mastra](https://mastra.ai/)는 Python 무거운 스택의 대안 제공, 팀이 [Node.js](https://nodejs.org/)나 [Next.js](https://nextjs.org/) 같은 기존 웹 생태계 내에서 직접 **풍부한 AI 역량 구축** 가능 - AI 레이어를 위해 Python으로 전환 피하고 싶은 **TypeScript 생태계 투자 팀에 평가할 가치** **114. Pipecat** - STT, LLM, TTS, 전송 오케스트레이션용 **모듈식 파이프라인 모델로 실시간 음성과 멀티모달 에이전트 구축**하는 오픈소스 프레임워크 - 팀이 대화 동작에 빠르게 반복하고 비교적 **낮은 마찰로 공급자 교체** 가능해 강한 관심 유도 - [LiveKit Agents](https://docs.livekit.io/agents/) 대비 [Pipecat](https://www.pipecat.ai/)은 더 큰 프레임워크 유연성 제공하지만 **덜 통합된 프로덕션 경로**, 특히 자체 호스팅 배포, 전송 신뢰성, 대규모 저지연 턴 처리에서 - 강한 엔지니어링 대면 기반 제공하지만, 비즈니스 중요 프로덕션 워크로드에 의존 전 **상당한 플랫폼 엔지니어링 작업 필요** **115. Superpowers** - 코딩 에이전트 사용 증가에 따라 모든 팀에 처방된 **단일 워크플로우 없음**, 대신 팀이 컨텍스트와 제약 기반 맞춤 워크플로우 진화 중 - [Superpowers](https://github.com/nicholasgriffintn/superpowers)는 이러한 워크플로우 중 하나로 **조합 가능한 [스킬](https://www.thoughtworks.com/radar/techniques/agent-skills)로 구축** - 코딩 에이전트를 구조화된 워크플로우의 스킬로 감싸, **코딩 전 브레인스토밍, 구현 전 상세 계획, 강제된 red-green-refactor 주기의 TDD, 체계적 근본 원인 우선 디버깅, 구현 후 코드 리뷰** 장려 - [Claude Code plugin marketplace](https://www.thoughtworks.com/radar/tools/claude-code-plugin-marketplace)와 Cursor plugin marketplace 통해 **플러그인으로 배포** **116. TanStack Start** - [TanStack Router](https://tanstack.com/router/latest) 위에 구축된 React와 Solid용 **풀스택 프레임워크**, Next.js와 비교 가능, SSR, 캐싱, 동일한 많은 기능 지원 - [TanStack Start](https://tanstack.com/start/latest)가 서버 함수, 로더, 라우팅 전반 **엔드투엔드 컴파일 타임 안전성** 제공, 프론트엔드의 깨진 링크나 불일치 데이터 형태 위험 감소 - 관례보다 **명시적 구성 선호**, 경험이 plain React 작업에 더 가까움 - SSR 역량을 필요에 따라 점진적 추가 가능 - 내부 작동에 익숙하지 않으면 예상치 못한 동작 초래 가능한 더 의견 있는 기본값 가진 Next.js 대비 **더 명시적이고 예측 가능** - [TanStack](https://tanstack.com/) 생태계도 크게 성숙, 현대 웹 애플리케이션 구축용 **강력한 도구 세트** 제공 **117. TOON (Token-Oriented Object Notation)** - 구조화 데이터가 LLM에 전달될 때 **토큰 사용량 감소를 위해 설계된 JSON 데이터의 인간 판독 가능 인코딩** - 기존 시스템에 JSON 유지하고 **모델과 상호작용 지점에서만 변환** 가능 - 토큰 비용, 지연, 컨텍스트 윈도우 제약이 RAG 파이프라인, 에이전트 워크플로우, 기타 AI 무거운 애플리케이션에서 **실제 설계 고려 사항**이 되는 중 - 원시 JSON이 종종 유용한 콘텐츠보다 **반복된 키와 구조적 오버헤드에 토큰 소비** - 초기 평가에서 [TOON](https://toon.dev/)은 프롬프트 입력의 흥미로운 **라스트 마일 최적화**, 특히 스키마 인식 형식이 JSON보다 더 효율적이고 모델 처리 쉬운 크고 규칙적인 데이터셋에 - API, 데이터베이스, 모델 출력에서 JSON 대체가 아니며, 깊게 중첩되거나 비균일 구조, 반균일 배열, CSV가 더 컴팩트한 평면 표형 데이터에는 종종 **잘못된 선택** - 컴팩트 JSON이 잘 수행하는 지연 중요 경로에도 덜 적합할 수 있음 - 구조화 입력 크기가 의미 있는 비용이나 품질 관심인 **LLM 애플리케이션 구축 팀에 평가할 가치**, 자체 데이터와 모델 스택으로 JSON이나 CSV 대비 벤치마크 필요 **118. Unsloth** - **LLM 미세 조정과 강화 학습을 상당히 빠르고 메모리 효율적으로 만드는 데 집중**하는 오픈소스 프레임워크 - LLM 미세 조정은 수십억 행렬 곱셈 포함, GPU 가속에서 이점, [Unsloth](https://unsloth.ai/)이 이러한 연산을 NVIDIA GPU용 **고효율 커스텀 커널로 변환해 최적화**, 비용과 메모리 사용량 극적 감소 - 비싼 H100 클러스터 대신 **T4 이상 소비자 GPU에서 모델 미세 조정 가능**하게 함 - LoRA, 전체 미세 조정, 다중 GPU 훈련, 긴 컨텍스트 미세 조정(최대 500K 토큰) 지원, Llama, Mistral, DeepSeek-R1, Qwen, Gemma 포함 인기 모델 대상 - 도메인 특정 AI 애플리케이션이 점점 미세 조정에 의존함에 따라, Unsloth가 **진입 장벽을 상당히 낮춤** ## Comments _No public comments on this page._