Solid Queue가 Rails 8 기본값으로 채택된 과정, 그리고 오픈소스 유지보수에 대한 추가 정보

37signals의 Principal Programmer인 Rosa Gutiérrez는 Rails 8의 기본 백그라운드 작업 큐인 Solid Queue를 개발했습니다. 이전 37signals에서는 백그라운드 작업 관리를 위해 7개의 별도 gem을 사용했으며, 이는 비효율적인 접근 방식임을 깨달았습니다. 이에 따라 Redis와 같은 별도의 인메모리 서비스에 의존하는 대신, 현대적이고 빠른 데이터베이스 스토리지를 활용하는 Solid Queue가 개발되었습니다. 내부 도구에서 Rails 기본으로 전환하면서 수많은 이슈와 풀 리퀘스트가 쏟아졌습니다. Gutiérrez는 덜 체계적인 gem을 디버깅했던 경험을 바탕으로 Solid Queue 설계에서 가독성 있는 코드의 중요성을 강조했습니다. 그녀는 Solid Queue가 AI 코드 어시스턴트가 널리 사용되기 전에 개발되었다고 언급했습니다. 현재 루비 생태계는 AI 에이전트에 대한 적합성과 커뮤니티의 convention-over-configuration 원칙에 힘입어 부활을 경험하고 있습니다. Gutiérrez는 기여자 행동의 변화를 설명하며, AI 에이전트가 이제 자주 이슈와 풀 리퀘스트를 열고 있다고 말했습니다. 그녀는 이러한 AI 기여가 종종 정중하고 잘 형식화되어 있다고 강조했습니다. 저자는 이전의 인간 기여자들과 현재의 AI 기여자들 간의 대조가 주목할 만하다고 생각했습니다.

How Solid Queue Became the Rails 8 default, and More on Open Source Maintainership dev.to

RSS Hunter • 오늘

TPU 개발자 허브: 고성능 AI 플랫폼에 대한 기술 검토

Google의 TPU 개발자 허브는 머신러닝 실무자들이 특화된 가속 하드웨어에 더 쉽게 접근할 수 있도록 하는 것을 목표로 합니다. 이 허브는 문서, 가이드, 사전 구성된 환경을 중앙 집중화하여 효율적인 TPU 학습에 필요한 시간을 줄여줍니다. MaxText, Pathways, Vertex AI 통합과 같은 추상화 계층을 도입하여 채택을 용이하게 합니다. 아키텍처 측면에서 TPU는 정적 텐서 모양을 가진 대규모 밀집 모델 학습에 뛰어나며, GPU 대비 상당한 처리량 증가와 비용 효율성을 제공합니다. 이는 행렬 곱셈에 최적화된 시스톨릭 배열 아키텍처 덕분입니다. 금융 기관의 경우, 이는 사기 탐지, 신용 점수 산정, 감성 분석 모델 학습 비용을 절감하는 것으로 이어집니다. 하지만 이 허브가 모든 마찰 지점을 해결하는 것은 아니며, 특히 규제된 금융 환경에서는 더욱 그렇습니다. JAX와의 생태계 종속성은 PyTorch에 익숙한 팀에게 어려움을 안겨줍니다. Google Cloud 외부에서의 제한된 관찰 가능성은 수동 계측을 필요로 합니다. 규정 준수 및 데이터 상주 문제는 Google Cloud에 저장된 데이터에 대한 신중한 법률 및 기술적 고려가 필요합니다. 중요한 함정에는 동적 모양이 성능에 미치는 부정적인 영향과 TPU pod의 가용성 보장 부족으로 인해 강력한 체크포인팅이 필요하다는 점이 포함됩니다. 권장되는 멀티 클라우드 패턴은 Google Cloud에서 TPU로 학습하고 AWS에서 추론하며 각 플랫폼의 강점을 활용하는 것을 포함합니다. 데이터 준비 및 스키마 유효성 검사는 AWS 내에서 이루어진 후 학습을 위해 Google Cloud로 복제됩니다. 그런 다음 모델은 AWS에 내보내져 배포되어 규정 준수를 유지하면서 저지연 추론을 수행합니다. 오케스트레이션은 AWS Step Functions를 통해 관리되며, 제어 평면은 감사 및 변경 관리 통합을 위해 AWS에 상주합니다. 책임감 있는 채택은 프로덕션 환경에서 TPU를 사용하기 전에 워크로드 프로필을 검증하고 잠재적인 함정을 신중하게 해결하는 것을 요구합니다.

TPU Developer Hub: A Technical Review of a High-Performance AI Platform dev.to

RSS Hunter • 오늘

픽셀에서 계획까지: AWS 기반 지리공간 데이터 플랫폼

Google Research의 "pixels to planning" 이니셔티브는 컴퓨터 비전 모델을 넘어서는 강력한 데이터 플랫폼의 중요성을 강조합니다. 주요 과제는 페타바이트 규모의 지리공간 데이터를 효율적으로 처리하는 것입니다. 위성 이미지를 기본적인 S3 파티셔닝을 사용하여 단순한 로그 파일처럼 취급하면 시간적 및 공간적 요구사항의 충돌로 인해 과도한 쿼리 비용이 발생합니다. 더 효과적인 솔루션은 GeoParquet 및 지리공간 술어 푸시다운과 함께 Apache Iceberg를 사용하는 것으로, 스캔되는 데이터를 크게 줄여줍니다. AWS 상의 금융 등급 지리공간 파이프라인은 수집부터 소비까지 다단계 프로세스를 포함합니다. 여기에는 S3에 원시 데이터가 안착되고, 큐레이션된 데이터가 GeoParquet/Iceberg로 변환되며, SageMaker를 통해 머신러닝 모델이 학습 및 배포되는 과정이 포함됩니다. 연/월, H3 그리드 해상도, 센서의 세 가지 수준 계층 구조를 사용하는 지리공간 파티셔닝은 비용 및 지연 시간 관리에 중요합니다. H3의 일관된 셀 면적은 예측 가능한 파티션 크기를 보장하여 복잡한 기하학적 연산 없이 센서 간 조인을 용이하게 합니다. 이 파이프라인을 구축하려면 S3 수명 주기 정책 구성, Glue 변환 작업 개발, Lake Formation을 사용한 세분화된 액세스 제어 구현을 포함한 신중한 계획이 필요합니다. 데이터셋 스냅샷 및 코드 버전에 대한 완전한 추적성을 갖춘 머신러닝 모델 학습은 감사 및 규제 준수에 매우 중요합니다. 제어된 지연 시간으로 API Gateway를 통해 추론 기능을 노출하고 OpenTelemetry를 사용하여 관찰 가능성을 구현하는 것은 운영상의 신뢰를 위해 필수적입니다. Iceberg 테이블의 GeoParquet는 기본적인 아키텍처 개선을 나타내며, 상당한 비용 절감을 제공하고 쿼리 시간 지리공간 조인을 제거합니다. 지리공간 데이터가 금융 의사 결정에 영향을 미칠 때 데이터 거버넌스, 특히 계보 추적성은 선택 사항이 아니며 규제 요구 사항이 됩니다. 고해상도 위치 데이터는 본질적으로 민감하므로 다층 방어 체계를 갖춘 제로 트러스트 보안 모델을 구현하는 것이 필요합니다. 이 접근 방식은 고급 지리공간 애플리케이션에 대한 데이터 무결성, 보안 및 규정 준수를 보장합니다.

Pixels to Planning: Geospatial Data Platforms on AWS dev.to

RSS Hunter • 오늘

계정은 단순한 저장소가 아닙니다. 솔라나가 빠른 이유 중 하나입니다.

Solana는 멤풀 없이 높은 속도를 위해 병렬 실행을 가능하게 하는 블록 단위로 트랜잭션을 처리합니다. 계정은 데이터를 저장하고 프로그램은 스마트 계약과 유사하게 실행 가능한 코드를 포함합니다. Solana에는 각각 고유한 기능을 수행하는 여러 계정 유형이 있습니다. 예를 들어, 시스템 프로그램은 모든 1로 구성된 고정 소유자 주소를 사용합니다. Solana의 계정 주소는 공개 키(개인 키로 보호됨) 또는 프로그램 파생 주소(PDA)입니다. PDA는 특정 시드와 프로그램 ID를 사용하여 프로그램에 의해 결정론적으로 생성됩니다. 이러한 PDA는 프로그램이 소유하며 스마트 계약이 관리하는 보안 금고와 유사하게 작동합니다. 공개 키를 가진 사용자 계정은 PDA에 대해 소유자 역할을 합니다. Solana는 효율적인 트랜잭션 처리를 위해 동적 병렬 계정 잠금을 사용합니다. 트랜잭션은 검증자 엔진에 모든 관련 계정을 사전에 선언해야 합니다. 이 시스템은 이중 지불을 방지하기 위해 읽기 잠금(Read-Locks)과 쓰기 잠금(Write-Locks)을 사용합니다. 중요한 것은 이 잠금 메커니즘을 통해 관련 없는 계정을 동시에 처리할 수 있어 네트워크 병목 현상을 방지한다는 것입니다.

Accounts are not just storage. They're one of the reasons Solana is fast. dev.to

RSS Hunter • 오늘

GPT-5 vs Claude vs Nova on Bedrock: A Production Governance Bake-off

Amazon Bedrock은 GPT-5.5 및 Codex와 같은 고급 모델을 기존 옵션과 함께 통합하여 엔터프라이즈 AI의 중앙 플랫폼으로 자리 잡고 있습니다. 이를 통해 AWS 보안 및 거버넌스 프레임워크 내에서 모델을 사용할 수 있게 되어 규제 산업의 규정 준수가 간소화됩니다. 이전에는 외부 모델을 사용하는 것이 AWS 제어를 우회하는 것을 의미했지만, Bedrock이 IAM 정책 및 CloudTrail과 통합되면서 이 문제가 해결되었습니다. 그러나 엄격한 격리 요구 사항의 경우 네트워크 지연 및 AWS 계정 외부의 모델 가중치 상주가 고려 사항으로 남아 있습니다. 프로덕션 성능은 벤치마크와 다르며, 부하 상태에서의 동작 및 일관된 지연 시간에 중점을 둡니다. Claude 3.7 Sonnet은 감사 가능한 확장된 추론을 통해 에이전트 워크플로우에서 뛰어난 성능을 발휘합니다. GPT-5.5는 강력한 추론 기능을 제공하지만 네이티브 API에 비해 출력에 대한 세분화된 제어가 덜합니다. Amazon Nova Pro는 네이티브 통합으로 두각을 나타내며, 파인튜닝을 가능하게 하고 토큰당 최저 비용을 제공합니다. 효과적인 AI 시스템 운영은 관찰 가능성에 달려 있으며, OpenTelemetry와 같은 도구를 사용하여 모델 출력을 비즈니스 컨텍스트와 연관시킵니다. 실제 비용은 토큰 가격 외에도 프롬프트 효율성, 재시도 및 운영 오버헤드를 포함합니다. GPT-5.5는 Claude 3.7 Sonnet보다 비싸고 Nova Pro보다 훨씬 비싸며, 특히 고용량 작업의 경우 더욱 그렇습니다. Bedrock에서의 배치 추론은 Claude 및 Nova에 대해 비용 절감을 제공하지만, GPT-5.5는 아직 Bedrock을 통해 이를 지원하지 않습니다. 타사 모델의 분당 토큰 제한은 신중한 관리가 필요하며, 다른 워크로드에 대해 별도의 AWS 계정이 필요할 수 있습니다. 복잡성과 요구 사항에 따라 가장 적합한 모델로 요청을 지능적으로 라우팅하는 라우팅 패턴은 비용과 성능을 크게 최적화할 수 있습니다. 동일한 보안 및 관찰 도구를 다양한 모델에 걸쳐 활용하는 이 통합 거버넌스 접근 방식은 여러 최첨단 모델을 효과적으로 관리하는 과제를 해결합니다.

GPT-5 vs Claude vs Nova on Bedrock: A Production Governance Bake-off dev.to

RSS Hunter • 오늘

현대적 KYC: 금융 서비스의 서버리스, AI 및 감사 추적

전통적인 KYC 프로세스는 비효율적이고 비용이 많이 들며, 오픈 파이낸스 및 즉시 결제와 같은 현대적인 요구 사항을 충족하는 데 어려움을 겪고 있습니다. 워크플로우 문제로 취급되는 경우가 많은 이 시대에 뒤떨어진 접근 방식은 새로운 아키텍처 패러다임으로 대체되고 있습니다. KYC의 미래는 AI를 코파일럿으로 강화한 이벤트 기반 서버리스 시스템을 포함합니다. 감사 가능성은 이제 단순한 규정 준수 후처리 사항이 아니라 모든 결정이 투명하고 추적 가능하도록 보장하는 주요 아키텍처 고려 사항입니다. 이러한 변화의 주요 동인에는 AWS Step Functions와 같은 서버리스 오케스트레이션 도구의 성숙도와 Amazon Textract 및 Bedrock과 같은 서비스를 통한 AI 기반 문서 추출 및 검증의 발전이 포함됩니다. AWS의 부문별 인증은 규제 준수를 크게 완화하여 관리형 서비스에 대한 감사 범위를 줄입니다. 현대적인 KYC 파이프라인은 이벤트 기반 흐름으로 설계되며, 문서 수집부터 위험 점수화까지 각 단계가 불변적으로 오케스트레이션되고 기록됩니다. 이 새로운 아키텍처에서의 감사 가능성은 최종 결정뿐만 아니라 각 단계에서 사용된 정확한 데이터, 프롬프트 및 모델 버전을 캡처하는 것을 의미합니다. WORM(Write Once, Read Many) 기능을 갖춘 안전한 저장소에 저장된 이 상세 기록은 규제 감사에 중요합니다. 아키텍트는 이제 AI를 단독 의사 결정자가 아닌 지원 도구로 사용하고 모든 구성 요소가 멱등성을 갖도록 보장하면서 오케스트레이션을 통해 실패 처리를 중앙 집중화하는 데 집중해야 합니다. 서버리스 KYC를 구현하는 데는 프로비저닝된 동시성을 사용하여 Lambda 콜드 스타트를 관리하고 저품질 문서의 잠재적인 정확도 문제를 해결하는 것과 같은 절충이 있습니다. 대규모 AI 추론 비용은 신중하게 고려해야 하며, 외부 API 제한은 지능형 캐싱 전략을 필요로 합니다. 조직적으로는 전담 KYC 설계 권한, 의사 결정 관찰 가능성에 대한 투자, AI 프롬프트를 버전 관리되는 인프라로 취급하는 것이 성공적인 채택에 필수적입니다. 다중 리전 배포 계획 및 감사에서 생성형 AI의 비결정적 특성 해결도 아키텍트에게 중요한 고려 사항입니다.

Modern KYC: Serverless, AI and Audit Trails in Financial Services dev.to

RSS Hunter • 오늘

하나의 조직인가, 여러 조직인가? 아무도 쓰고 싶어 하지 않는 사후 분석

한 금융 기관은 비용 거버넌스를 위해 비즈니스 단위를 단일 AWS Organization으로 통합했지만, 루트 노드에 서비스 제어 정책(SCP)을 잘못 적용하여 47분간의 프로덕션 중단을 야기했습니다. 통합된 비용 가시성, 단일 정책 시행, 자동화 간소화에 대한 압박이 이러한 아키텍처 결정으로 이어졌습니다. 규정 준수를 위해 AWS 리전을 제한하려는 보안 팀의 시도가 루트에 SCP를 적용하면서 의도치 않게 결제 파이프라인에 대한 중요한 DynamoDB 호출을 차단했습니다. 이는 결제 계정이 차단된 리전의 DynamoDB Global Tables 엔드포인트를 사용했고, 초기 모니터링에서 오류가 감지되지 않았기 때문에 발생했습니다. 사고 타임라인은 SDK 오류부터 서킷 브레이커 작동, 그리고 처음에는 문제 해결 노력을 잘못 유도했던 알림까지 점진적인 실패를 보여줍니다. 근본 원인은 단일 조직 아키텍처에서 비롯된, 설계상 제한되지 않은 영향 범위였으며, 단순한 인적 오류가 아니었습니다. 이 설계는 결제와 같은 규제 워크로드와 운영 워크로드 간의 격리가 부족했습니다. 계층적 SCP를 가진 단일 조직은 루트 수준의 SCP가 네이티브 점진적 롤백 없이 모든 계정에 동시에 영향을 미친다는 것을 의미합니다. 이 텍스트는 더 강력한 격리 경계를 제공하는 수정된 멀티 조직 접근 방식과 이 문제적인 단일 조직 패턴을 대조합니다. 여러 조직은 독립적인 정책 수명 주기, 별도의 관리 계정 자격 증명, 그리고 감사자가 더 쉽게 수용하는 더 명확한 규제 격리를 제공합니다. 여러 조직은 운영 복잡성과 랜딩 존 자동화 중복을 증가시키지만, 이는 해결 가능한 문제입니다. 즉각적인 기술적 수정에는 루트 또는 중요한 OU에 정책을 연결하는 것을 방지하는 가드레일 SCP 구현이 포함되었습니다. 중기적으로는 PCI-DSS 워크로드를 위한 두 번째 AWS 조직이 생성되어 보안 및 정책 독립성을 강화했습니다. AWS Organizations 이벤트를 Slack 및 PagerDuty로 캡처하여 관찰 가능성이 향상되었고, 탐지 평균 시간(MTTD)이 크게 단축되었습니다. SCP의 핵심 문제는 일반적인 인프라 코드와 달리 즉각적인 전파와 스테이징 또는 자동 롤백의 부족입니다. 이를 해결하기 위해 SCP에 대한 불변 상태 레지스트리가 구현되어 몇 초 내에 자동 롤백이 가능해졌습니다.

One Org or Many? The Postmortem Nobody Wants to Write dev.to

RSS Hunter • 오늘

ADR: 프로덕션 환경에서 Amazon Bedrock AgentCore 채택

AWS 금융 플랫폼 아키텍트인 저자는 규제된 금융 환경에서 AI 에이전트를 운영하기 위해 Amazon Bedrock AgentCore를 채택한 배경의 의사 결정 과정을 상세히 설명합니다. 기존 접근 방식은 2 AM 장애 및 규정 준수와 같은 중요한 운영 문제에 어려움을 겪었습니다. 긴급한 해결책이 필요했던 다섯 가지 주요 요인은 다음과 같습니다. 크로스턴 상태 관리, 규정 준수 추적성 보장, 강력한 가드레일 구현, 예측 불가능한 토큰 비용 제어, 런타임 이식성 달성입니다. EKS에서의 자체 호스팅 솔루션, 이전 세대의 Bedrock Agents, Lambda와 함께 Step Functions 사용을 포함한 여러 옵션이 고려되었습니다. EKS에서의 자체 호스팅 옵션은 높은 운영 책임과 엔지니어링 비용으로 인해 기각되었습니다. 이전 Bedrock Agents 세대는 제한된 가시성 및 예산 제어로 인해 불충분하다고 판단되었습니다. Step Functions는 결정론적 워크플로우에서의 강점에도 불구하고 대화형 에이전트 런타임으로는 부적절하다고 판단되었습니다. Amazon Bedrock AgentCore는 세션 메모리, 가드레일, 추적성 및 도구 사용을 위한 네이티브 기능을 갖춘 관리형 런타임을 제공하는 권장 솔루션으로 부상했습니다. AgentCore를 선택한 결정적인 요인은 도구별 OAuth2/OIDC 지원을 갖춘 게이트웨이와 금융 분야의 보안 및 규정 준수에 중요한 구성 가능한 TTL을 갖춘 관리형 세션 메모리였습니다. 저자는 런타임에 대한 플랫폼 종속성의 절충점을 인정하지만, 기본 도구의 이식성을 강조합니다. 이 글은 효과적이고 안전한 운영을 위해 가드레일, AgentCore 메모리, 게이트웨이 및 토큰 예산에 대한 구체적인 구성 조언을 제공하며, 이들의 중요성을 강조합니다. TurnsPerSession, TokensPerSession, ToolCallFailureRate, GuardrailInterventionRate와 같은 가시성 지표가 설명되어 있으며, 상세한 추적 및 규제 감사를 위해 X-Ray 및 CloudTrail을 활용하는 것이 강조됩니다. 저자는 또한 런타임 종속성, 보수적인 할당량, 가드레일 지연 시간 및 메모리 비용을 포함한 결과 및 위험에 대해 경고하며, 신중한 수용 및 완화 전략을 촉구합니다.

ADR: Adopting Amazon Bedrock AgentCore in Production dev.to

RSS Hunter • 오늘

CloudWatch에서 OTel로: 관찰 가능성 브릿지 패턴 해체

CloudWatch를 OpenTelemetry로 연결하는 브릿지 패턴은 금융 플랫폼이 AWS 메트릭을 통합 관찰 가능성 백엔드로 통합해야 할 때 흔히 사용되는 솔루션입니다. 이 패턴의 주된 목적은 AWS 서비스에서 외부 시스템으로 메트릭을 전달하여 파편화된 관찰 가능성을 해결하는 것입니다. 이 패턴은 일반적으로 AWS 서비스가 CloudWatch로 메트릭을 내보내고, 이를 CloudWatch Metric Streams가 캡처하거나 GetMetricData API를 통해 검색하는 과정을 포함합니다. 이 메트릭들은 Lambda 함수나 OpenTelemetry Collector에 의해 OpenTelemetry 형식으로 변환된 후 Datadog이나 Grafana와 같은 관찰 가능성 백엔드로 전송됩니다. 하지만 이 "명백한" 솔루션은 특히 메트릭 신선도와 API 비용이 중요한 고용량 금융 환경에서 숨겨진 복잡성을 내포하고 있습니다. 이 패턴에는 두 가지 주요 수집 경로가 있습니다. Kinesis Firehose를 사용하는 CloudWatch Metric Streams는 낮은 지연 시간과 예측 가능한 비용을 제공하는 반면, GetMetricData를 사용한 폴링은 세밀한 제어를 제공하지만 API 속도 제한에 걸리거나 높은 비용이 발생할 위험이 있습니다. 강력한 변환 Lambda는 멱등성을 가져야 하며, 외부 엔드포인트에 대한 서킷 브레이커와 알람이 있는 Dead Letter Queue를 포함해야 합니다. 이 패턴은 외부 OTLP 지원 백엔드가 필요하고, 메트릭 볼륨이 스트림 비용을 정당화하며, 60초 이하의 메트릭 신선도 SLO가 필요한 경우에 적합합니다. 또한 관찰 가능성을 AWS와 분리하고 추적-메트릭 상관 관계를 가능하게 합니다. 보안이 가장 중요하며, 리소스 조건을 포함한 엄격한 IAM 정책, 전송 중인 데이터에 대한 KMS 암호화, 제어된 네트워크 나가는 트래픽이 필요합니다. 피해야 할 안티 패턴으로는 단순한 폴링, 적절한 오류 처리나 예약된 동시성이 없는 Lambda 함수, 이 메트릭 중심 브릿지를 통해 로그나 추적을 전달하려는 시도 등이 있습니다. 잘 설계된 구현은 스트림 수준에서 메트릭 필터링을 우선시하고, 효율적인 버퍼링을 사용하며, 관찰 가능성을 위해 브릿지 자체를 계측하고, 엄격한 보안 조치를 사용합니다.

CloudWatch to OTel: Tearing Down the Observability Bridge Pattern dev.to

RSS Hunter • 오늘

Agentic RAG와 OpenSearch Serverless: 패턴의 해부

저자는 새로운 에이전트 AI 중심의 OpenSearch Serverless를 비판하며, 콜드 스타트, 폭발적인 비용, 서버리스가 아키텍처적 필요성을 제거한다는 오해와 같은 잠재적 함정을 강조합니다. 고전적인 RAG는 LLM이 다양한 데이터에 걸쳐 도구를 반복적으로 호출하고 쿼리를 재구성하는 에이전시에서 어려움을 겪습니다. 금융 에이전트는 여러 인덱스에 걸쳐 빠르고 낮은 지연 시간의 벡터 검색이 필요합니다. OpenSearch Serverless OCU는 컬렉션별로 확장되며, 유휴 컬렉션의 콜드 스타트는 상당한 지연 시간 문제입니다. 에이전트 RAG 패턴은 오케스트레이터, 도구 및 메모리를 사용한 수집, 임베딩 및 반복적인 검색-생성 주기를 포함합니다. 주요 구성에는 낮은 지연 시간을 위한 HNSW 인덱싱과 검색 품질을 위한 메타데이터 필터링을 포함한 계층적 청킹이 포함됩니다. 검색된 문서를 크로스 인코더로 재순위 지정하면 정밀도가 크게 향상됩니다. 크기 조정 고려 사항에는 OCU 메모리 제한, P99 벡터 검색 지연 시간 및 콜드 스타트 시간이 포함됩니다. 이 패턴은 가변 트래픽, 비균일 지식 성장 및 멀티 테넌시에 적합합니다. 500ms 미만의 엔드투엔드 에이전트 응답 SLO에는 부적합합니다. 안티 패턴에는 필터 없는 멀티 테넌트 단일 인덱스, 캐시되지 않은 쿼리 임베딩, 재순위 지정 없는 높은 k, 배치 수집에 대한 OCU 비용 무시, 비멱능적 수집 파이프라인이 포함됩니다. 보안은 KMS CMK, 최소 권한 IAM 역할, VPC 엔드포인트 및 쿼리 감사를 의무화합니다. 관찰 가능성은 인프라 모니터링, 애플리케이션 추적 및 오프라인 검색 품질 메트릭을 필요로 합니다.

Agentic RAG with OpenSearch Serverless: Anatomy of a Pattern dev.to

RSS Hunter • 오늘

EC2 G7e: 생성형 비디오 추론을 위한 아키텍처 결정

이 문서는 금융 환경에서 생성 비디오 추론을 위한 GPU 인스턴스 선택에 관한 아키텍처 결정을 개괄합니다. 생성 비디오 추론은 시간적 상태, GPU 메모리 대역폭 및 엄격한 지연 시간 요구 사항으로 인해 이미지 추론에 비해 고유한 과제를 제시합니다. 모델은 상당한 VRAM을 필요로 하며, 클립 지속 시간과 해상도는 메모리 소비를 직접적으로 증가시킵니다. NVIDIA L40S GPU를 탑재한 새로운 EC2 G7e 인스턴스는 48GB의 VRAM을 제공하여 CPU 오프로딩을 제거함으로써 이러한 요구를 충족합니다. 이 결정에 영향을 미치는 주요 아키텍처 요인에는 토큰당 비용 대 시간당 비용, 지역 가용성 및 데이터 상주 규정, 테넌트 격리 요구 사항, 콜드 스타트 시간이 포함됩니다. G5, G6 및 G7e 인스턴스와 같은 옵션을 평가할 때 G7e는 720p-1080p 비디오에 대해 90초 미만의 지연 시간 SLO를 갖는 프로덕션 워크로드에 선호되는 선택으로 부상합니다. Amazon Bedrock은 G7e 가용성이 부족한 스파이크 및 지역에 대한 관리형 대체 솔루션으로 권장됩니다. 제안된 아키텍처는 G7e 오케스트레이션 및 콜드 스타트 완화를 위한 웜 풀 전략을 위해 Karpenter를 사용하는 EKS를 사용합니다. 보안 및 규정 준수는 테넌트별 암호화, Pod IAM을 위한 IRSA, 프롬프트 주입 보호 및 포괄적인 감사 가능성을 통해 해결됩니다. G7e의 48GB VRAM과 향상된 메모리 대역폭은 중요한 발전을 나타내며, 더 빠른 추론 시간과 엄격한 지연 시간 요구 사항 준수를 가능하게 합니다.

EC2 G7e: Architecture Decision for Generative Video Inference dev.to

RSS Hunter • 오늘

MiCA는 기계가 읽을 수 있는 보고를 요구합니다. 귀사의 Agent Payment Stack은 사람이 읽을 수 있는 로그를 생성합니다.

MiCA의 완전 시행이 8일 앞으로 다가왔으며, 중요하지만 종종 간과되는 요구 사항은 에이전트 결제 시스템에 대한 기계 판독 가능한 보고입니다. 규제 당국은 지속적인 준비금 투명성과 독립적인 감사를 위해 PDF가 아닌 구조화되고 쿼리 가능한 데이터를 필요로 합니다. 인간 감사자를 위해 설계된 기존 결제 시스템은 이러한 새로운 요구 사항을 충족하지 못하는 비정형 텍스트 로그를 생성합니다. 인간의 결제와 달리 결정, 협상 및 확인에 기계 판독 가능한 추적이 부족하기 때문에 에이전트 결제 수명 주기는 특히 어렵습니다. MiCA는 표준화된 기계 판독 가능한 형식으로 실시간 이벤트 기반 준비금 보고를 의무화합니다. 독립적인 감사는 감사자 도구가 수집할 수 있는 형식으로 내보낸 완전하고 구조화된 거래 로그를 필요로 합니다. 현재 에이전트 결제 로그는 비정형이며 일관된 스키마가 부족하고 쿼리하기 어려워 상당한 규정 준수 위험을 초래합니다. 규제 요구 사항과 현재 에이전트 결제 스택 기능 간의 격차는 상당합니다. EU AI Act 및 GENIUS Act 또한 기계 판독 가능한 출력을 기반으로 보고 의무를 부과합니다. 에이전트 결제에서 누락된 주요 요소에는 블록체인 거래만으로는 파생될 수 없는 결정 속성, 정책 준수 및 총 노출이 포함됩니다. 규정 준수를 거버넌스 계층에 통합하는 기업은 규제 대응 시간, 감사 비용 및 시장 접근 측면에서 이점을 얻습니다. 규정 준수를 나중에 고려하면 수 주간의 수동 재구성이 필요하지만, 규정 준수 네이티브 솔루션은 즉각적이고 구조화된 데이터 액세스를 제공합니다. 선택은 7월 1일까지 기계 판독 가능한 규정 준수 또는 규정 미준수입니다.

MiCA Demands Machine-Readable Reporting. Your Agent Payment Stack Produces Human-Readable Logs. dev.to

RSS Hunter • 오늘

2026년 MCP Inspector vs Postman: 실제로 사용하는 툴은 무엇인가

저자는 MCP 도구 정의에서 흔히 발생하는 문제에 직면했는데, 스키마와 핸들러 간의 필드 이름에 오타가 있어 에이전트가 도구를 무시하게 되었습니다. 이를 해결하기 위해 저자는 MCP 정의를 검증하기 위한 세 가지 도구를 테스트했습니다. MCP Inspector, Postman, 그리고 MCP Tool Tester라는 자체 제작 검증 도구입니다. 공식 디버거인 MCP Inspector는 실행 중인 서버가 필요하며 런타임 중에 문제를 식별하는데, 이는 늦을 수 있습니다. Postman 역시 실행 중인 서버가 필요하며 HTTP 기반 MCP를 지원하고 협업 기능을 제공하지만 검증이 피상적입니다. 저자의 MCP Tool Tester는 서버 없이 즉시 정의를 확인하는 클라이언트 측 검증 도구로, 필드 이름 불일치, 긴 설명, 중복된 열거형 값과 같은 문제를 표시합니다. 저자는 배포 전 검사에 이 검증 도구를 사용하고 런타임 테스트에는 Inspector를 사용합니다. Postman은 빠른 정의 검사에는 너무 무겁다고 간주되지만 HTTP 서버를 사용하는 팀에게는 가치가 있습니다. 검증 도구는 신속한 정적 정의 검증에 뛰어나며, Inspector는 실제 도구 동작을 테스트하는 데 중요합니다. 검증 도구와 Inspector 모두 MCP 개발 워크플로우에서 서로 다르지만 상호 보완적인 역할을 수행합니다.

MCP Inspector vs Postman in 2026: which one I actually use dev.to

RSS Hunter • 오늘

지도 작동 방식, 메르카토르, 타일, 그리고 GPS 핀

Google 지도와 같은 인터랙티브 지도는 두 가지 기본적인 수학적 개념을 기반으로 구축됩니다. 첫 번째는 지구의 구형 표면을 평평한 화면에 투영하는 방법입니다. 두 번째는 효율적인 로딩을 위해 이 평면 투영을 작고 관리 가능한 정사각형 타일의 그리드로 나누는 것입니다. 이러한 원리를 이해하면 지도 애플리케이션이 어떻게 작동하는지 명확해지고 정확한 위치 계산이 가능해집니다. 핵심 과제는 지구의 둥근 모양과 평평한 디스플레이를 조화시키는 것입니다. 이를 위해서는 경도와 위도를 화면 좌표로 변환하는 수학적 규칙인 지도 투영이 필요합니다. 대부분의 웹 지도는 각도를 보존하고 지역 모양을 유지하여 방향이 일관되게 유지되고 북쪽이 항상 위쪽에 있도록 하는 Web Mercator 투영을 사용합니다. 그러나 이 투영은 면적을 상당히 왜곡하여 극지방이 불균형적으로 크게 나타납니다. Mercator 투영은 경도를 x축에 직접 매핑하여 지구를 평평하게 만듭니다. 그러나 위도는 적도 근처보다 극지방 근처의 영역을 더 많이 늘리는 로그 함수를 사용하여 변환됩니다. 이 로그 변환은 Mercator 투영이 작동하는 방식의 핵심입니다. 결과적으로 투영된 세계는 256x256 픽셀 타일의 쿼드트리 구조로 나뉩니다. 이 타일은 줌 레벨을 기반으로 계층적 시스템으로 구성되며, 각 타일은 줌 레벨과 x, y 좌표로 식별됩니다. 이 타일링 방식은 지도가 세계의 필요한 부분만 로드하도록 하여 부드러운 스크롤링과 상호 작용을 가능하게 합니다. 특정 위도와 경도를 해당 타일로 변환하는 공식이 있습니다. `asinh(tan(lat))` 함수는 타일 그리드 시스템에 대해 정규화된 Mercator y 좌표를 나타냅니다. 이 계산의 소수 부분을 버리면 특정 타일을 식별할 수 있으며, 소수 부분은 해당 타일 내의 정확한 위치를 나타냅니다. 사용자가 지도를 드래그하면 애플리케이션은 화면에 보이는 타일을 계산하고 해당 타일을 가져옵니다. 사용자 위치를 나타내는 파란색 점은 이 프로세스의 직접적인 결과입니다. 장치의 GPS는 위도와 경도를 제공하며, 이는 동일한 Mercator 수학을 사용하여 투영됩니다. 시스템은 해당 타일을 결정하고 화면의 투영된 위치에 마커를 배치합니다. 이러한 기본 원리를 이해하면 불투명한 지도 인터페이스가 이해 가능한 시스템으로 변환됩니다.

How a map works, Mercator, tiles, and your GPS pin dev.to

RSS Hunter • 오늘

VuReact는 Vue 3의 defineModel을 React로 어떻게 컴파일하나요?

VuReact는 Vue에서 React로 마이그레이션하고 Vue 3 구문으로 React를 작성하기 위한 툴체인입니다. 이 글은 Vue 3의 defineModel 매크로가 React로 컴파일되는 과정을 상세히 설명합니다. 컴파일은 Vue의 defineModel을 React의 useVRef 및 useUpdated 훅으로 매핑하여 자동 동기화를 수행합니다. Vue의 defineModel은 ref, modelValue prop, 그리고 update 이벤트를 생성하여 v-model 선언을 단순화합니다. VuReact는 이를 useVRef로 변환하여 prop 값을 반응형으로 만들고, useUpdated를 사용하여 값 변경 시 부모 콜백을 트리거합니다. 컴파일은 defineModel을 prop 타입 선언, 이벤트 콜백 선언, 그리고 런타임 반응성으로 분해합니다. 이를 통해 컴포넌트 내에서 ref의 값을 변경하면 부모가 자동으로 업데이트되어 Vue 개발 경험을 그대로 재현합니다. VuReact는 defineModel에 대한 타입, 기본값, required 옵션, 그리고 사용자 정의 prop 이름을 지원합니다. 이러한 옵션들은 TypeScript 타입 제약 조건 및 기본값 로직으로 변환하여 처리합니다. useVRef 훅은 초기 prop 값을 반응형 ref로 감싸고, useUpdated는 ref의 변경 사항을 모니터링합니다. 컴파일된 React 코드에서 ref.value에 직접 할당하면 부모의 업데이트가 트리거됩니다. ref의 값과 상호 작용하는 함수들은 올바른 의존성 추적과 함께 useCallback으로 감싸집니다. 이러한 .value 접근 패턴의 보존은 개발자에게 원활한 전환을 제공합니다.

How does VuReact compile Vue 3's defineModel to React? dev.to

RSS Hunter • 오늘

Laravel에서의 테스트 주도 개발: 레드-그린-리팩터 루프

전통적인 "코드 우선" 접근 방식은 유지보수하기 어려운 레거시 코드와 운영상의 긴급 상황을 초래합니다. 테스트 주도 개발(TDD)은 코드를 작성하기 전에 테스트를 작성함으로써 이를 뒤집습니다. TDD는 Red, Green, Refactor 주기를 따릅니다. Red 단계에서는 존재하지 않는 기능에 대한 테스트를 작성하며, 실패할 것으로 예상됩니다. Green 단계에서는 실패하는 테스트를 통과시키기 위해 최소한의 코드를 작성합니다. Refactor 단계에서는 통과하는 테스트를 안전망으로 사용하여 코드 정리 및 개선을 수행합니다. TDD의 주요 이점은 버그 포착을 넘어 소프트웨어 설계를 개선하는 데까지 확장됩니다. 먼저 테스트를 작성함으로써 개발자는 코드 소비자의 관점을 채택하여 설계 복잡성을 드러냅니다. 이 글은 구독 시스템 예제를 통해 TDD를 설명하며, 기능 테스트가 구현 및 후속 리팩토링을 어떻게 안내하는지 보여줍니다. 일반적인 함정으로는 과도한 의존성 모킹, 동작이 아닌 구현 세부 사항 테스트, 지나치게 큰 테스트 작성 등이 있습니다. TDD의 "속도를 높이기 위해 속도를 늦추는" 철학은 수동 디버깅을 제거하고 배포에 대한 자신감을 키움으로써 시간을 절약합니다. 현대적이고 유지보수 가능한 소프트웨어, 특히 Laravel과 같은 진화하는 프레임워크에서는 TDD가 중요한 기법으로 제시됩니다. 작은 코드 조각에 TDD를 적용하면 자신감을 쌓고 시간이 지남에 따라 코드 품질을 향상시킬 수 있습니다.

Test-Driven Development in Laravel: The Red-Green-Refactor Loop dev.to

RSS Hunter • 오늘

Rust의 arti-client를 이용한 P2P 채팅 구축

이 게시물은 Tor 숨김 서비스를 중심으로 Anyhide에서의 피어 검색 및 세션 설정의 복잡성을 자세히 설명합니다. 일반 서버와 달리 사용자와의 상호 익명성에 숨김 서비스가 왜 중요한지 설명합니다. Tor 숨김 서비스 ID를 사람이 읽을 수 있는 .onion 주소로 변환하는 과정은 코드와 특정 구현 세부 정보와 함께 설명됩니다. 별도의 데몬과 비교하여 내장된 특성을 강조하는 `arti` Tor 클라이언트 라이브러리 부트스트래핑이 보여집니다. 숨김 서비스를 호스팅하는 것은 구성과 들어오는 연결에 대한 요청 스트림을 얻는 것을 포함합니다. 숨김 서비스에 연결하는 것도 마찬가지로 간단합니다. 이 글은 복잡성이 추가되었음에도 불구하고 평등과 사용 편의성을 촉진하기 위해 양쪽 피어가 동시에 연결을 시작하려고 시도하는 양방향 연결 레이싱 접근 방식을 논의합니다. 연결이 이루어지면 보안 세션 키를 설정하기 위한 세 가지 메시지 핸드셰이크 메커니즘이 개략적으로 설명됩니다. `arti` 라이브러리가 회로 관리 및 숨김 서비스 통합과 같이 제공하는 것과 현재 부족한 점을 명확히 하며, 보안에 중요한 애플리케이션에 대한 실험적인 상태임을 언급합니다. 저자는 취소 안전 문제를 피하기 위해 암호화 기본 요소를 동기식으로 유지해야 한다고 강조합니다. 다음 게시물에서는 연락처 관리 및 연결 요청 처리를 포함한 사용자 인터페이스를 다룰 것입니다.

Building a P2P Chat over Tor with Rust's arti-client dev.to

RSS Hunter • 오늘

[튜토리얼] Upsun에 Django 배포하기: 최종 체크리스트 🚀

라이브 환경에 Django 프로젝트를 배포하는 것은 많은 구성 단계를 포함하는 복잡한 과정일 수 있습니다. Upsun은 배포에 대한 구조화된 접근 방식을 제공하여 이를 단순화합니다. 환경 변수, ALLOWED_HOSTS, 정적 에셋 전달 및 종속성 설치를 자동으로 관리합니다. Upsun의 플랫폼별 설정 및 빌드 구성은 프로세스를 간소화하여 개발자가 최종 배포 단계 완료에 집중할 수 있도록 합니다.

[Tutorial] Deploying Django on Upsun: the final checklist 🚀 dev.to

RSS Hunter • 오늘

AI 우선 스타트업 스튜디오 구축

팀은 Klar 출시 이후 두 달간의 집중적인 재건을 거쳐 운영을 대폭 업데이트했습니다. 전략 및 인프라 추가를 통해 8명의 에이전트 팀으로 확장했습니다. SMB를 위한 새로운 급여 및 HR 솔루션인 Nomi가 스타트업 카탈로그에 추가되었습니다. 프로젝트 수가 네 배로 늘어났으며, 이러한 프로젝트 전반에 걸쳐 작업 완료율이 높습니다. 기술적으로는 인프라가 거의 전적으로 코드로 관리되고 있으며, 컨테이너화된 프로젝트로 Kubernetes 준비가 완료되었습니다. 지속적인 통합 및 배포를 가능하게 하는 강력한 배포 제어 플레인을 구현했습니다. 인프라는 높은 가용성과 자체 복구 기능을 강조하며, 상당 부분이 자체 호스팅됩니다. 제품 측면에서는 내부 개선 및 신규 기능 모두에 집중하여 수천 개의 풀 리퀘스트를 마감했습니다. 다양한 플랫폼을 위한 주간 기사를 생성하는 콘텐츠 파이프라인이 마련되어 있으며, 선택적으로 인간 검토가 가능합니다. 재건 단계 완료가 임박했으며, 곧 핵심 생산자를 재개할 것으로 예상되며, 이는 출시로 이어질 수 있습니다. 놀랍게도 현재까지 모든 출력 비용은 AI 및 가상 머신 비용을 신중하게 관리하여 천 유로 미만입니다.

Building an AI first Startup Studio dev.to

RSS Hunter • 오늘

AI-Team-Team - 범용 동적 다중 에이전트 협업 프레임워크

AI-Team-Team (ATT)는 AI 에이전트가 복잡한 계층적 또는 동적 팀을 자유롭게 구성할 수 있도록 합니다. 이 프로젝트는 깊이 제한이 있는 자식 에이전트 팀의 재귀적 생성을 가능하게 합니다. 팀은 구성원을 자율적으로 구성하고, 역할을 정의하며, 계층 내에서 이동할 수 있습니다. 실시간 ASCII 지도는 활성 팀 토폴로지를 시각화하고, 전역 전문가 디렉토리는 피어 검색을 용이하게 합니다. ATT는 추론을 위해 제한된 ReAct 루프와 실행을 위한 견고한 파서를 사용합니다. 대화 메모리는 중요한 대화 기록을 보존하기 위해 압축됩니다. LLM 생성 로직은 공급업체에 독립적인 콜백 핸들러에 위임됩니다. 민주적인 투표 시스템은 익명 참여를 허용하여 회원 변경을 관리합니다. 협상 브로커는 팀 간 통신을 관리하고, 협업 문서 라이브러리는 제어된 스토리지를 제공합니다. 컨텍스트 보호 게이트는 대용량 파일 읽기를 제한하며, 개요 경고 및 청크 요청으로 대체됩니다. 도구 감사는 실행 전에 특정 도구 호출을 가로채고 검증합니다. SQLite 상태 스냅샷은 시스템 상태를 직렬화하여 충돌 복구를 가능하게 합니다. 감독 팀은 대화를 감사하고 이상 징후를 에스컬레이션합니다. 분리된 대시보드는 UI 업데이트를 위한 명확한 런타임 이벤트 후크를 제공합니다. 이 프로젝트는 구현된 기능과 향후 애플리케이션 계획을 갖춘 완전한 Python 패키지입니다.

AI-Team-Team - A generic dynamic multi-agent collaboration framework dev.to

RSS Hunter • 오늘

ChatGPT가 AI 앱 사용자 절반 아래로 떨어졌습니다. 제가 빅 3에 업무를 분담한 방법은 다음과 같습니다.

ChatGPT의 AI 앱 사용자 점유율이 50% 미만으로 하락했으며, Sensor Tower에 따르면 현재 약 46%입니다. Gemini는 앱 사용자 약 28%를 차지하고 있으며, Claude는 약 10%를 차지합니다. 그러나 ChatGPT는 여전히 11억 명 이상의 월간 사용자를 보유한 웹 트래픽에서 선두를 유지하며 전반적인 1위 자리를 지키고 있습니다. 이러한 변화는 사용자들의 단일 AI 앱 습관의 종식을 나타냅니다. 개발자인 저자는 이제 특정 작업을 위해 다른 AI를 사용합니다. Claude는 리팩토링 및 복잡한 코드베이스 이해와 같은 코딩 작업에 선호됩니다. Gemini는 Google 제품에 통합되어 이메일, 검색 및 Google 탭 내 작업에 편리합니다. 많은 장치에 사전 설치되어 있어 설치 마찰이 제로라는 이점이 있습니다. ChatGPT는 사용자 친화적인 인터페이스 덕분에 일반적인 질문 및 빠른 초안 작성에 여전히 사용됩니다. 다른 AI 모델들은 특히 Google 생태계 내 Gemini의 배포로 인해 인기를 얻고 있습니다. 일부 파트너십 발표 후 ChatGPT에서 전환한 사용자들의 신뢰도도 역할을 합니다. 근본적인 질문은 "최고의 AI"를 찾는 것에서 "특정 작업에 가장 적합한 AI"를 식별하는 것으로 진화했습니다. 이는 개발자들에게 표준 워크플로우가 되고 있는 작업 기반 라우팅을 필요로 합니다. 경쟁 심화는 AI 서비스 전반에 걸쳐 더 빠른 기능 개발과 가격 인하를 주도하고 있습니다.

ChatGPT just dropped below half of AI-app users — here's how I split work across the big three dev.to

RSS Hunter • 오늘

"학습부터 면접까지 기술적 탁월함" — 합격이 아닌 여정을 명명하는 열망 헤드라인

많은 에듀테크 및 면접 준비 플랫폼은 제품이 무엇을 의미하는지를 설명하는 헤드라인을 사용하며, 지원자가 무엇을 얻는지를 설명하는 헤드라인을 사용하지 않습니다. "학습부터 면접까지 기술적 탁월함"과 같은 이러한 헤드라인은 듣기 좋고 정확합니다. 그러나 면접 준비를 찾는 개발자가 가진 구체적인 질문에 답하지 못합니다. 개발자는 시스템 설계 격차 또는 스택별 준비와 같은 문제에 대한 구체적인 답변을 찾고 있습니다. 현재 헤드라인은 바람직한 역량 상태를 설명하지만, 실질적인 결과나 경쟁업체와의 명확한 차별점을 설명하지는 않습니다. 헤드라인은 포괄 범위를 제공하지만, 지원자가 무엇을 달성할지에 대한 구체성이 부족합니다. 더 효과적인 헤드라인은 열망에서 직접적이고 측정 가능한 결과로 초점을 전환합니다. 예를 들어, "최상위 기업의 다음 기술 면접 통과 — 스택에서 묻는 정확한 질문을 연습하여 당일에 아무것도 놀라지 않도록 하세요." 이 수정된 헤드라인은 원하는 결과, 이를 달성하기 위한 개인화된 메커니즘, 그리고 준비된 느낌의 최종 상태를 명시적으로 설명합니다. 이 접근 방식은 지원자의 근본적인 두려움과 욕구에 직접적으로 답합니다. 열망 주도 헤드라인의 패턴은 창업자들이 제품의 가치에 집중하기 때문에 흔합니다. 그러나 지원자는 주로 추상적인 이상뿐만 아니라 결과를 추구합니다. 따라서 헤드라인은 먼저 구체적인 이점을 명확하게 설명해야 합니다.

"Technical excellence, from learning to interview" — The Aspiration Headline That Names the Journey, Not the Pass dev.to

RSS Hunter • 오늘

네 에이전트 데모가 잘 돼. 그게 함정이야.

기업을 위한 AI 에이전트 구축 시 흔히 발생하는 문제는 성공적인 데모와 안정적인 프로덕션 성능 간의 격차입니다. 이 불일치는 주로 모델의 한계 때문이 아니라 누적 확률 때문입니다. 단계별 신뢰도가 높더라도 여러 단계를 연결하면 엔드투엔드 성공률이 크게 감소합니다. 데모는 일반적으로 단일의 이상적인 시나리오를 보여주며, 프로덕션의 실제 복잡성을 가립니다. 에이전트 단계 내의 실패는 그럴듯해 보이지만 잘못된 출력을 생성하기 때문에 종종 눈에 띄지 않습니다. 개별 단계는 독립적으로는 건전해 보일 수 있으며, 오류를 조용히 체인 전체로 전파합니다. 흔한 진단인 "환각"은 모델이 단순히 받은 데이터를 처리하기 때문에 종종 부정확합니다. 에이전트 성능의 중요한 제한 요소는 순수한 크기보다는 컨텍스트의 품질이며, 오래된 정보는 묻히게 됩니다. 신뢰도를 높이려면 단순히 프롬프트 최적화뿐만 아니라 강력한 시스템 엔지니어링에 집중해야 합니다. 상태 체크포인팅을 구현하면 중단된 프로세스를 재개할 수 있어 비용이 많이 드는 재시작을 피할 수 있습니다. 각 단계에서 입력과 출력을 검증하면 오류를 조기에 감지하여 다운스트림 작업이 손상되는 것을 방지할 수 있습니다. 부작용을 멱등성으로 만드는 것은 비결정적 작업자와 함께 재시도를 처리하는 데 중요합니다. 평가를 지속적 통합 파이프라인에 통합하면 에이전트 동작을 회귀에 취약한 코드처럼 취급합니다. 궁극적으로 세련된 데모를 프로덕션 준비 시스템으로 전환하려면 오류 처리 및 상태 관리와 같은 화려하지 않은 엔지니어링 원칙이 필요합니다. 핵심 문제는 종종 에이전트를 단순한 프롬프트가 아닌 복잡한 시스템으로 취급하는 것입니다.

Your agent demo works. That's the trap. dev.to

RSS Hunter • 오늘

LLM 게이트웨이 대 MCP 게이트웨이: 새로운 AI 인프라 스택 이해하기

현대의 AI 시스템은 복잡성이 증가함에 따라 여러 LLM 제공업체와 도구 통합을 관리하기 위한 새로운 인프라를 요구합니다. 수많은 서비스에 애플리케이션을 직접 연결하는 것은 규모가 커지면 관리 불가능해집니다. LLM 게이트웨이는 모든 모델 상호 작용에 대한 단일 진입점을 제공하여 인증, 속도 제한 및 비용 모니터링을 처리함으로써 이를 단순화합니다. LLM 라우터는 주어진 작업에 가장 적합한 LLM을 지능적으로 선택하여 비용과 성능을 최적화하기 때문에 중요합니다. 모델 컨텍스트 프로토콜(MCP)은 AI 에이전트가 외부 도구 및 시스템과 상호 작용하기 위한 표준으로 부상하고 있습니다. MCP 게이트웨이는 이러한 MCP 서버에 대한 액세스를 관리하고, 정책을 시행하며, 거버넌스를 강화하는 중앙 집중식 계층을 제공합니다. MCP 프록시는 주로 연결 및 인증을 처리하는 반면, MCP 게이트웨이는 포괄적인 관리 기능을 추가합니다. MCP 레지스트리, 에이전트 레지스트리, 스킬 레지스트리와 같은 레지스트리는 사용 가능한 AI 리소스를 검색하고 분류하는 데 필수적입니다. MCP 레지스트리는 MCP 서버를 나열하고, 에이전트 레지스트리는 AI 에이전트를 추적하며, 스킬 레지스트리는 재사용 가능한 에이전트 기능을 자세히 설명합니다. 이러한 레지스트리는 중복을 방지하고 전반적인 AI 시스템 거버넌스를 개선합니다. 궁극적으로 모델, 에이전트 및 도구의 효과적인 통합 및 관리는 미래 엔터프라이즈 AI 성공에 매우 중요하며, 이러한 인프라 계층을 필수적으로 만듭니다.

LLM Gateway vs MCP Gateway: Understanding the New AI Infrastructure Stack dev.to

RSS Hunter • 오늘

컨텍스트 압축 시각화 도구: AI 에이전트가 비용을 초래하기 전에 무엇을 잊었는지 정확히 확인하세요

여러 턴에 걸쳐 작동하는 AI 에이전트는 컨텍스트 제한에 직면하여 이전 메시지를 압축하거나 폐기해야 합니다. 이러한 컨텍스트 손실은 종종 눈에 띄지 않지만 중요하며, 에이전트가 중요한 제약 조건, 사용자 선호도 또는 이전 결정을 잊게 만들 수 있습니다. Context Compaction Visualizer 플랫폼은 컨텍스트 관리 프로세스를 투명하게 만들어 이러한 문제를 해결합니다. 사용자는 LangSmith, OpenTelemetry 또는 AgentOps와 같은 다양한 플랫폼의 실행 추적을 업로드할 수 있습니다. 그런 다음 플랫폼은 전체 세션 기록을 재구성하여 어떤 메시지가 유지, 요약 또는 폐기되었는지 자세히 설명합니다. D3.js 타임라인은 색상으로 구분된 결과와 함께 모든 턴에 걸친 토큰 소비를 시각적으로 나타냅니다. 세션 다시 보기 기능을 통해 단계별 검토가 가능하며, 압축 이벤트와 그 영향을 강조 표시합니다. 토큰 분석은 총 비용과 압축 효율성에 대한 통찰력을 제공합니다. 선택적 Claude 기반 정보 손실 감지기는 각 압축 이벤트의 위험 점수를 매기고 잠재적으로 손실된 정보를 식별합니다. 이 플랫폼은 다양한 에이전트 또는 압축 전략을 나란히 평가하기 위한 비교 보기를 지원합니다. 설정에는 Python 및 Node.js 설치, 선택적 Anthropic API 키 구성, 백엔드 및 프론트엔드 서비스 실행 또는 Docker 사용이 포함됩니다. 백엔드는 여러 추적 형식에 대한 파서를 포함하여 추가 처리 전에 정규화합니다. 주요 설계 결정에는 파서 정규화, 정보 손실 감지기에 대한 우아한 폴백 및 React 내의 효율적인 D3.js 통합이 포함됩니다. 이 프로젝트는 보이지 않는 컨텍스트 압축 프로세스를 보이게 함으로써 어떤 컨텍스트가 손실되었고 그 가치가 무엇인지에 대한 기록을 제공하는 것을 목표로 합니다.

Context Compaction Visualizer: See Exactly What Your AI Agent Forgot Before It Costs You dev.to

RSS Hunter • 오늘

AI 에이전트를 위한 실제로 잊어버리는 메모리 시스템을 구축했습니다

기존 AI 에이전트 메모리 시스템은 영구적인 축적으로 인해 시간이 지남에 따라 오래된 사실들이 검색을 오염시켜 성능과 정확도가 저하되는 문제를 겪고 있습니다. 이 문제는 더 많은 토큰이 직접적으로 더 나쁜 결과와 느리고 멍청한 에이전트와 상관관계가 있기 때문에 발생합니다. 이를 해결하기 위해 능동적으로 망각하는 메모리 시스템인 recall-sqlite가 개발되었습니다. 핵심 원리는 계층적 저장으로, 메모리는 액세스 빈도에 따라 자동으로 계층 간에 이동됩니다. 핫 계층은 자주 액세스되는 메모리를 보유하며, 빠른 검색을 위해 ANN과 키워드를 활용합니다. 웜 계층은 덜 액세스되는 메모리를 저장하며, 키워드와 FTS5에만 의존하여 컴퓨팅을 크게 줄입니다. 콜드 계층은 컴퓨팅 없이 무제한의 메모리를 저장할 수 있으며, 필요할 때 자동으로 승격됩니다. 주요 설계 선택에는 쿼리 시 LLM 사용을 피하고 소규모 로컬 임베딩 모델에만 의존하는 것이 포함됩니다. 전통적인 벡터 데이터베이스를 피하고 sqlite-vec을 사용하여 SQLite를 활용합니다. 이 시스템은 오프라인 시 키워드 및 FTS5 검색으로 대체되는 우아한 성능 저하를 지원합니다. 자동 스키마 마이그레이션은 업데이트를 단순화하며, API 키나 Docker 없이 단일 pip install을 제공합니다. 거의 1500개의 메모리로 매일 6개월간 사용한 후에도 지연 시간은 약 80ms를 유지하며 메모리 사용량은 약 1.5MB로 고정됩니다. recall-sqlite는 이제 Hermes Agent 생태계에 통합되었습니다.

I Built a Memory System for AI Agents That Actually Forgets dev.to

RSS Hunter • 오늘

AI를 사용하되 당신의 비밀을 누설하지 않기: AI 지원 개발을 위한 위협 모델

AI 프롬프트에 비밀 정보를 붙여넣는 것은 영구적인 노출 가능성이 있는 로그 및 학습 데이터에 공개적으로 공유하는 것과 같습니다. 저자는 캐주얼한 접근 방식이 아닌 AI 사용에 대한 위협 모델 접근 방식을 강조합니다. 프롬프트는 제출 시 비공개 대화로 유지되지 않습니다. 무료 AI 등급은 종종 모델 개선을 위해 데이터를 유지하는 반면, 유료 등급은 계약상의 보증을 제공하지만 절대적인 보안을 제공하지는 않습니다. 데이터 유출은 붙여넣은 내용, 도구가 자동으로 첨부하는 내용 또는 모델이 출력하는 내용에서 발생할 수 있습니다. AI 제공업체는 감사하기 불가능한 신뢰할 수 있지만 검증할 수 없는 제3자로 간주됩니다. 위험 자산에는 API 키, 데이터베이스 자격 증명 및 민감한 고객 정보가 포함됩니다. 프롬프트 채널은 프로덕션 네트워크 호출과 유사하게 신뢰할 수 없는 나가는 통신으로 취급해야 합니다. 보내지 말아야 할 목록에는 실시간 자격 증명, 민감한 구성 파일 및 독점 소스 코드가 포함됩니다. 자리 표시자로 비밀 정보를 마스킹하는 것은 보내지 않는 것에 대한 실행 가능한 대안입니다. 컨텍스트 위생은 무시 파일 및 사전 프롬프트 스캔을 통한 유출의 구조적 방지를 포함합니다. 소스에서 비밀 정보를 암호화된 상태로 유지하는 원칙은 일반 텍스트 노출을 방지합니다. 데이터 민감도를 AI 등급과 일치시키는 것, 즉 독점 작업에는 유료 등급을 사용하고 규제 데이터에는 로컬 모델을 사용하는 것이 권장됩니다. 교육 금지 보증이 있더라도 제로 트러스트 입장을 권장하며, 컨텍스트를 최소화하고 AI 출력을 확인합니다. AI 무시 파일 사용, 비밀 정보 스캔 및 자격 증명 마스킹과 같은 습관은 상당한 시간 비용 없이 보안을 개선합니다.

Using AI Without Leaking Your Secrets: A Threat Model for AI-Assisted Development dev.to

RSS Hunter • 오늘

MERN 스택 학습 69일차

개발자는 69일 연속 풀스택 엔지니어링 작업을 기념하고 있습니다. 어제는 인터랙티브 호스트 인벤토리 대시보드와 데이터 삭제 훅을 성공적으로 배포했습니다. 오늘은 생성 폼을 업데이트에 재사용하는 시스템을 구현하여 관리 라이프사이클을 개선하는 데 집중했습니다. 이는 Express Query Parameters와 Dynamic View Hydration을 활용하여 달성되었습니다. 핵심 개념은 항목 생성 및 업데이트를 위한 중복 코드를 방지하는 것입니다. 개발자는 조건부 상태 추출을 추상화하여 이를 달성했습니다. 69일차에는 이 기능에 대한 쿼리 수집 및 업데이트 드라이버를 구축했습니다. 프로세스는 쿼리 문자열 수집으로 시작되며, 애플리케이션은 URL에서 '?editing=true'와 같은 매개변수를 캡처합니다. 엄격한 조건부 검사를 통해 애플리케이션의 처리 로직이 결정됩니다. 업데이트 필터가 참이면 컨트롤러는 URL 경로에서 특정 데이터베이스 포인터 문자열을 추출합니다. 이 식별자는 특정 항목에 대한 기존 데이터를 가져오는 데 사용됩니다. 이 가져온 데이터는 폼 내의 입력 필드를 채우는 데 사용됩니다. 재사용 가능한 EJS 로직은 이 업데이트 상태에 따라 사용자 인터페이스를 동적으로 변환합니다. 예를 들어, 헤더 제목이 "Edit HOME"으로 변경되고 기본 CTA 버튼이 "Edit Home details"로 업데이트됩니다. 파일 입력 필드는 업데이트된 이미지 문자열을 처리하거나 기존 미디어 경로를 유지하도록 준비됩니다. 제공된 아키텍처 스니펫은 백엔드가 쿼리 플래그를 가로채어 폼 재활용을 위한 뷰 엔진을 동적으로 구동하는 방법을 보여줍니다.

Day 69 of Learning MERN Stack dev.to

RSS Hunter • 오늘

첫날 출시 수치와 오늘 제가 업보트 수를 무시하는 이유

어제 XEdge가 Peerlist의 Launchpad에 출시되었습니다. 13개의 업보트. 1개의 댓글 스레드. 3개의 직접적인 피드백. 각 숫자가 실제로 무엇을 의미하는지에 대한 솔직한 견해는 다음과 같습니다. 업보트는 품질 신호가 아니라 인기 신호입니다. 사람들이 귀하의 출시를 보고 버튼 하나를 클릭했다는 것을 알려줍니다. 이는 가시성에는 가치가 있지만 제품 방향에는 아무런 가치가 없습니다. 댓글은 깊이 신호입니다. 하나의 실제 댓글 스레드는 13개의 침묵하는 업보트를 합친 것보다 낯선 사람이 XEdge를 어떻게 인식하는지에 대해 더 많은 것을 가르쳐 주었습니다. 피드백은 유일하게 복리 효과를 내는 신호입니다. 3명의 사람들이 무엇이 혼란스럽거나 누락되었는지 알려주기 위해 시간을 할애했습니다. 이는 아무런 의무 없이 무료 제품 감사를 3번 받은 것과 같습니다. 오늘 저는 리더보드를 다시 확인하지 않을 것입니다. 저는 각 피드백을 한 줄씩 검토하고 이번 주에 어떤 변경 사항을 적용할지 결정할 것입니다. 교훈: 투표 수량이 아닌 피드백 품질에 맞춰 출시를 최적화하십시오. 투표는 일주일 안에 사라집니다. 피드백은 몇 달 동안 중요한 것을 수정할 수 있습니다. xedge.tech — 계속 구축하고, 계속 경청합니다.

Day 1 launch numbers and why I'm ignoring the upvote count today dev.to

RSS Hunter • 오늘

Codex의 SQLite 로그를 비활성화하면 프로젝트 메모리를 무엇이 유지시켜 주는가?

Codex는 로컬 SQLite 데이터베이스에 과도한 진단 로깅을 수행하여 빠른 SSD 쓰기 및 느린 응답과 같은 성능 문제를 야기한다는 비판을 받아왔습니다. 비공식적인 해결책은 SQLite 트리거를 사용하여 새로운 로그 항목을 무시함으로써 디스크 활동을 줄이지만, 진단 정보를 가릴 수 있습니다. 이 해결책은 에이전트의 내부 로그와 연속성을 위해 필요한 영구적인 "프로젝트 메모리" 사이의 중요한 구분을 강조합니다. 에이전트 로그는 저수준 운영 세부 정보를 포함하는 반면, 프로젝트 메모리는 주요 결정, 검증된 증거 및 다음 단계에 대한 간결한 기록을 필요로 합니다. 이 필수적인 프로젝트 연속성은 에이전트의 자체 진단을 위해 설계되었으며 스키마 및 형식 변경에 영향을 받는 내부 진단 데이터베이스에 의해 보존되지 않습니다. 이 글은 Codex와 같은 AI 코딩 에이전트의 연속성 컨텍스트를 캡처하기 위해 설계된 로컬 우선 레코드 계층인 QiJu를 소개합니다. QiJu는 필수 사실—기본 진실 파일, 결정, 증거 및 다음 작업—만 의도적으로 기록하여 후속 에이전트가 전체 기록 세션을 필요로 하지 않고도 올바르게 작업을 재개할 수 있도록 합니다. 이 접근 방식은 에이전트의 내부 기억 속에 갇힌 정보와 달리 감사 가능하고 인계 가능합니다. QiJu는 특히 에이전트 로그가 비활성화되거나 사용할 수 없을 때 프로젝트 연속성을 유지하는 실용적인 솔루션을 제공합니다. `qiju update` 업그레이드 명령은 에이전트 통합 기술이 프로젝트 전반에 걸쳐 최신 상태를 유지하도록 보장합니다. 프로젝트 등록 프로세스는 프로젝트 위치를 호스트 구성과 분리하여 효율적인 업데이트를 가능하게 합니다. QiJu는 제한 사항이 있는 개발자 미리 보기 상태이지만, 핵심 목적은 AI 지원 개발을 계속하는 데 중요한 것을 의도적이고 검사 가능한 기록으로 설정하는 것이며, 이는 내부 진단 로깅과 중요한 구분입니다.

If You Disable Codex’s SQLite Logs, What Keeps Your Project Memory Alive? dev.to

RSS Hunter • 오늘

의료기관 사이버 보안이 임상 안전의 일부가 되고 있다

의료기관 사이버 보안은 이제 통합 병원 구매 패키지에서 입증된 바와 같이 임상 안전과 본질적으로 연결되어 있습니다. 병원은 의료 기기부터 방문객 Wi-Fi에 이르기까지 다양한 시스템이 고유한 취약점을 제시하는 이기종 네트워크를 관리합니다. 이러한 다양한 시스템은 덜 안전한 의료 기기를 격리하기 위해 임상 기능 및 위험 수준에 맞춰진 네트워크 분할을 필요로 합니다. 치료 서비스의 가용성을 보호하는 것은 데이터 기밀성만큼 중요하며, 보안 조치는 중요한 임상 워크플로우에 대해 테스트되어야 합니다. 포괄적인 백업 및 복구 계획은 임상적으로 관련 있는 시간 프레임 내에서 데이터 복원을 보장해야 합니다. 공급업체 유지 관리는 원격 액세스, 데이터 기록 및 기본 자격 증명 제거에 대한 엄격한 통제를 요구하는 빈번한 위험을 초래합니다. 조달 프로세스는 공급업체로부터 강력한 보안 관행에 대한 증거를 요구함으로써 이러한 보안 기대를 공고히 할 수 있습니다. 인수 테스트에는 계정 침해 및 구성 요소 실패와 같은 보안 사고 시뮬레이션이 포함되어야 합니다. 궁극적인 목표는 절대적인 제한이 아니라 관리된 위험을 통해 신뢰할 수 있는 환자 치료를 달성하는 것입니다. 사이버 보안 설계를 임상 종속성과 일치시킴으로써 병원은 필수 서비스를 방해하지 않고 보안을 강화할 수 있습니다.

Healthcare Cybersecurity Is Becoming Part of Clinical Safety dev.to

RSS Hunter • 오늘

LLM 추론을 라우팅하기 위해 Rust 엔트로피 모니터를 구축했습니다. 벤치마크 결과는 다음과 같습니다.

프론티어 LLM 추론은 비용이 많이 들기 때문에 계층적 추론 아키텍처인 Buddy System이 개발되었습니다. 이 시스템은 비싼 클라우드 호출에 의존하기 전에 로컬 모델 사용을 최대화하는 것을 목표로 합니다. Rust EntropyMonitor는 MLX를 통해 Apple Silicon에서 실행되는 4B 모델의 로컬 생성 중에 토큰별 불확실성을 추적합니다. 로컬 모델이 높은 엔트로피를 나타내어 진정한 불확실성을 나타낼 때, 특히 절 경계에서 spaCy NER은 관련 명명된 개체 또는 명사구를 식별합니다. 그런 다음 sentence-transformers 검색기는 컨텍스트에 대한 관련 구절 청크를 찾습니다. 클라우드 모델인 Sonnet은 불확실한 사실과 근거 문서를 포함하는 대상 쿼리를 받습니다. 중요한 것은 클라우드 호출이 비동기식이므로 로컬 생성이 차단되지 않는다는 것입니다. 고전적인 도구는 수학 및 단위와 같은 결정론적 작업을 0 비용으로 처리합니다. 벤치마크에 따르면 Buddy System은 로컬 전용(70.7% 정확도, $0.00 비용)에 비해 최소 비용으로 71.4%의 정확도를 달성합니다. 그러나 어드바이저 패턴은 SQuAD v2 및 HotpotQA와 같은 특정 데이터 세트에서 놀랍게도 성능이 저하되었습니다. 이는 어드바이저가 소스 문서 없이 답변을 받고 근거 대신 매개변수 메모리에 의존하기 때문입니다. Buddy System의 성공은 검토 계층에 문서 컨텍스트를 전달하는 데 있으며, 이는 정확한 LLM 성능에 대한 컨텍스트의 중요성을 보여줍니다.

I built a Rust entropy monitor to route LLM inference — here's what the benchmark showed dev.to

RSS Hunter • 오늘

챗봇을 넘어서: 엔터프라이즈 워크플로우를 위한 Google 관리 에이전트 아키텍처에 대한 비판적 분석

기업 AI 환경은 단순한 검색 증강 생성(RAG) 챗봇에서 더 정교한 에이전트 워크플로로 전환되고 있습니다. RAG 시스템은 내부 문서에서 질문에 답하는 데는 뛰어나지만, 다단계 작업을 수행하거나 데이터를 작성하는 능력은 부족합니다. Google의 Managed Agents API는 AI 에이전트를 위한 안전한 클라우드 샌드박스를 제공하여 솔루션을 제공합니다. 이 아키텍처는 기업 워크플로에 필수적인 상태 유지 및 트랜잭션 쓰기 작업을 가능하게 합니다. Managed Agents API는 각 에이전트 세션에 대해 격리된 Linux 컨테이너 내에서 작동하며, 컨테이너화 및 보안 문제를 추상화합니다. 상태는 지속적인 세션 식별자를 통해 여러 단계에 걸쳐 유지되어 장기 실행 작업을 가능하게 합니다. 에이전트 동작은 복잡한 코드가 아닌 구조화된 파일을 통해 정의되어 구성을 단순화합니다. 보안은 서버 측 자격 증명 주입을 통해 강화되어 민감한 정보가 노출되는 것을 방지합니다. 그러나 기업 준비 상태를 달성하려면 관리되는 샌드박스 이상이 필요합니다. 인터페이스, 오케스트레이션, 모델, 도구, 지식, 샌드박스 및 감사 계층을 포함하는 7계층 참조 아키텍처가 필요합니다. 가장 큰 엔지니어링 부담은 이러한 계층, 특히 제어 평면, 도구 제한 정책 및 트랜잭션 롤백 메커니즘을 통합하는 데 있습니다. GeekyAnts, Slalom, Cognizant와 같은 여러 회사가 이러한 복잡한 기업 에이전트 AI 통합 구축을 전문으로 합니다. 기업 리더를 위한 핵심 시사점은 모델 발전뿐만 아니라 인프라 및 엔지니어링에 집중하는 것입니다. 잘 정의된 비즈니스 워크플로를 격리하고 관찰 기능이 있는 강력한 제어 평면을 구축함으로써 팀은 지원 채팅에서 자율적이고 관리되는 워크플로로 전환할 수 있습니다. 이러한 통합 및 아키텍처 문제를 해결하기 위한 도구가 이제 제공됩니다.

Beyond Chatbots: A Critical Analysis of Google Managed Agents Architecture for Enterprise Workflows dev.to

RSS Hunter • 오늘

내 API가 다운되었는데 전혀 몰랐기 때문에 API 모니터링 플랫폼을 구축했습니다.

학생의 배포된 API가 몇 시간 동안 조용히 다운되어 Monitorly가 만들어졌습니다. 기존의 업타임 모니터링 도구들은 학생 프로젝트에 비해 지나치게 복잡하게 느껴졌습니다. Monitorly는 단순함을 위해 설계된 새로운 오픈 소스 API 업타임 모니터링 플랫폼입니다. 페이지 새로고침 없이 즉시 업데이트되는 실시간 대시보드를 특징으로 합니다. 엔드포인트의 상태가 변경될 때만 이메일로 알림이 전송되어 받은 편지함 스팸을 방지합니다. 이 플랫폼은 과거 검사 데이터를 기반으로 롤링 업타임 백분율을 계산합니다. 사용자는 1분에서 15분까지 검사 간격을 구성할 수 있습니다. Monitorly는 JWT 인증을 사용하여 사용자별 모니터링 데이터를 격리합니다. 주요 기술에는 Node.js, Express.js, MongoDB 및 Socket.io가 포함됩니다. 아키텍처는 검사 예약을 위해 cron 작업과 HTTP 요청을 위해 Axios를 활용합니다. 중요한 학습 내용은 순전히 기술적 정확성보다는 더 나은 사용자 경험을 위한 알림 로직 설계였습니다. 이 프로젝트는 또한 로그 데이터를 메인 문서와 분리하고 요청 시간 초과를 구현하는 것의 중요성을 강조합니다. 향후 계획에는 SMS 알림, 응답 본문 유효성 검사 및 공개 상태 페이지 추가가 포함됩니다.

I Built an API Monitoring Platform Because My Own API Went Down and I Had No Idea dev.to

RSS Hunter • 오늘

빌드 로그: Astro, Cloudflare Pages 및 Umami로 블로그 재구축하기

저자는 특정 원칙에 중점을 두고 Astro를 사용하여 개인 웹사이트를 재구축했습니다. 여기에는 SEO 유지, 모든 자산 소유, JavaScript 최소화, 개인 정보 보호 및 공급업체 종속성 방지가 포함됩니다. 게시물은 Git 리포지토리 내의 Markdown 파일로 관리되며, SEO 연속성을 위해 이전 URL과 일치하도록 슬러그가 유지됩니다. 마이그레이션 프로세스에는 게시물을 가져오고, 원치 않는 콘텐츠를 제거하고, 이미지를 로컬로 다운로드하고, 최적화하는 스크립트가 포함되었습니다. SEO는 중요한 고려 사항이었으며, 기존 블로그 경로를 메인 도메인으로 리디렉션하는 캐노니컬 URL 및 301 리디렉션을 구현하여 해결되었습니다. 이를 통해 순위 신호를 단일 호스트로 통합했습니다. 캐시된 콘텐츠를 제공하는 잔존하는 Gatsby 서비스 워커로 인해 지속적인 버그가 발생했습니다. 해결책은 이전 서비스 워커를 등록 해제하고 라이브 사이트로 새로 고침하도록 강제하는 새로운 "킬 스위치" 서비스 워커였습니다. 검색 기능은 백엔드 서버의 필요성을 피하기 위해 클라이언트 측에서 정적 JSON 인덱스를 사용하여 구현되었습니다. Astro의 범위 지정 스타일과 관련된 사소한 문제는 동적으로 생성된 요소에 대한 CSS 배치를 조정하여 해결되었습니다. Mermaid 다이어그램은 올바르게 로드되도록 비동기 가져오기 후 명시적으로 클라이언트 측에서 렌더링됩니다. 가독성을 높이기 위해 다이어그램에 클릭 투 줌 기능이 추가되었습니다. 태그 위생은 단일 사용 태그 및 중복 태그를 캐노니컬 태그로 통합하여 해결되었으며, 게시물이 두 개 미만인 페이지는 noindexing으로 표시되었습니다. 쿠키 없는 분석은 Umami를 사용하여 구현되었으며, 광고 차단기를 우회하기 위해 Cloudflare Pages Functions를 통한 퍼스트 파티 프록시가 사용되었습니다. 링크 클릭에 대한 이벤트 추적이 Umami에 추가되었습니다. Astro의 View Transitions는 `transition:persist`가 스크립트 연결 리스너를 유지하지 않기 때문에 각 탐색 시 스크립트를 다시 초기화해야 합니다. 마지막으로 Cloudflare의 Rocket Loader가 Safari에서 사이트 오류를 일으키는 원인으로 파악되어 비활성화되었습니다.

The Build Log: Rebuilding My Blog on Astro, Cloudflare Pages & Umami dev.to

RSS Hunter • 오늘

개발자를 위한 Penpot: 당신의 언어를 이해하는 오픈소스 디자인 도구

전통적인 디자인 도구는 종종 개발자를 뒷전으로 남겨두고, 픽셀 단위로 완벽한 디자인을 빠르게 구식이 되는 코드로 수작업으로 변환해야 합니다. Opensource 플랫폼인 Penpot은 SVG, CSS, HTML 같은 웹 표준으로 디자인을 직접 표현함으로써 이를 해결합니다. 이로 인해 독점적 고정과 특수한 '디자이너 방언'을 해석할 필요가 없어집니다. 개발자는 Penpot 내에서 SVG, CSS, HTML용 검사 가능하고 즉시 사용할 수 있는 코드를 즉시 접근할 수 있습니다. 이 플랫폼은 레이아웃에 네이티브 CSS Grid와 Flexbox를 지원하여 브라우저에서 인터페이스가 어떻게 동작하는지 미러링하여 설계와 구현 간의 마찰을 줄입니다. 중요한 기능 중 하나는 통합 MCP 서버로, AI 클라이언트가 설계도를 프로그래밍적으로 읽고 수정할 수 있게 합니다. 이 AI 통합은 의미 HTML 생성이나 프로토타입 생성과 같은 작업에 펜팟 디자인의 구조적이고 기계가 읽기 쉬운 코드를 활용합니다. 펜팟은 또한 설계 및 개발의 단일 진실의 원천으로 기능하는 일류 네이티브 디자인 토큰을 제공하며, 동기화를 간소화합니다. 오픈 API, 플러그인, 웹훅을 통해 자동화와 기존 개발자 워크플로우와의 통합이 가능합니다. 또한 Penpot은 자체 호스팅이 가능하여 엄격한 데이터 소유권 요구가 있는 팀에 컴플라이언스 혜택을 제공합니다. 웹 네이티브 출력과 실제 CSS 레이아웃을 사용하여 Penpot은 디자인과 개발 간의 간극을 좁히고자 합니다. Figma가 여전히 완성도와 프로토타이핑 깊이 면에서 선두를 차지할 수 있지만, 펜폿은 데이터 소유권, 설계 코드 정렬, AI 기반 워크플로우를 우선시하는 개발자들에게 매력적인 선택지입니다.

Penpot for Developers: The Open-Source Design Tool That Speaks Your Language dev.to

RSS Hunter • 어제

CVE 및 CVSS 점수: 취약점 관리에서의 전략적 통합

취약점에 대한 포괄적인 위험 모델은 CVE의 기본 점수를 넘어서야 합니다. 현재의 위협 환경을 반영하는 시간적 지표와 조직 인프라의 특정 맥락을 고려하는 환경적 지표를 통합해야 합니다. 취약점의 실제 위험은 내재된 심각성뿐만 아니라 중요 비즈니스 자산에 미치는 영향에 의해 결정됩니다. 예를 들어, 외부에 공개된 고객 웹사이트의 낮은 등급 취약점은 격리된 내부 서버의 심각한 취약점보다 더 큰 위협을 가합니다. CVE 데이터를 효과적으로 통합하려면 자산 인식 분류가 필요하며, 여기서 영향을 받는 자산의 중요도가 패치 우선순위를 결정합니다. 또한, CI/CD 파이프라인에서 소프트웨어 구성 분석 도구를 활용하는 DevSecOps 통합은 타사 라이브러리의 취약점을 조기에 탐지하고 수정할 수 있도록 합니다. CISA 카탈로그와 같은 실시간 위협 인텔리전스와 내부 스캔 보고서를 일치시키는 것은 적극적으로 악용되는 취약점을 식별하고 우선순위를 지정하는 데 중요합니다. 중간 정도의 심각성을 가진 CVE라도 악의적인 행위자에 의해 적극적으로 표적이 된다면 긴급해질 수 있습니다. 궁극적으로 효과적인 취약점 관리는 맥락에 달려 있으며, 일반적인 취약점 데이터를 특정 비즈니스 자산 및 동적인 위협 환경과 일치시키는 것입니다. 이 접근 방식은 조직이 가장 중요한 자산을 보호하기 위해 전략적으로 리소스를 할당할 수 있도록 합니다.

CVE & CVSS Scores: Strategic Integration in Vulnerability Management dev.to

RSS Hunter • 어제

저는 16세에 완전한 로컬 AI 어시스턴트를 구축했습니다. 클라우드도 없고, API 키도 필요 없으며, 여러분의 GPU에서 실행됩니다.

인도 푸네 출신의 16세인 Shriisoot가 완전히 로컬 AI 데스크톱 어시스턴트인 O-AI를 개발했습니다. 클라우드 기반 어시스턴트가 개인 정보를 침해하는 것에 좌절감을 느낀 그는 Iron Man의 JARVIS처럼 개인적이고 사적인 상호 작용을 우선시하는 O-AI를 만들었습니다. O-AI는 llama.cpp 또는 Ollama를 사용하여 대규모 언어 모델을 로컬에서 실행하며, 인터넷 연결이나 외부 API 키가 필요하지 않습니다. 대화 사실을 기억하는 자체 학습 코어와 개인화된 모델 학습을 위한 파인튜닝 파이프라인을 갖추고 있습니다. 이 어시스턴트는 로컬 Whisper 구현을 통해 영어, 힌디어, 마라티어로 음성 제어를 지원하며 사용자가 말한 언어로 응답합니다. O-AI는 JARVIS와 유사한 인터페이스, PC 자동화, 애니메이션 데스크톱 펫을 포함한 다양한 모드를 제공합니다. 애플리케이션 열기, 웹 검색, 미디어 제어와 같은 작업을 위한 30가지 이상의 자동화 기능을 자랑합니다. 다단계 에이전트 시스템은 다양한 단계 유형을 지원하여 복잡한 계획, 실행 및 작업 검증을 가능하게 합니다. 기술 스택에는 백엔드를 위한 Flask가 포함된 Python과 프론트엔드를 위한 vanilla JavaScript가 포함된 Electron이 포함됩니다. 상당한 과제에는 에이전트 작업에 대한 결과 검증 구현과 오류를 방지하기 위한 강력한 콘텐츠 유효성 검사가 포함되었습니다.

I built a fully local AI assistant at 16 — no cloud, no API keys, runs on your GPU dev.to

RSS Hunter • 어제

AI 보안: Codex 운영 버그, Claude 출력 무결성, Copilot 컨텍스트

이번 주 보안 하이라이트는 AI 시스템의 운영 버그와 AI 생성 콘텐츠의 무결성에 초점을 맞춥니다. OpenAI의 Codex에서 발견된 치명적인 버그는 과도한 로깅을 유발하여 로컬 SSD 저장 공간을 빠르게 소모시킬 수 있습니다. 디스크 공간 부족은 운영을 중단시키고, 업데이트를 방해하며, 잠재적으로 데이터 손실을 초래할 수 있습니다. Codex 버그는 AI 배포에서 강력한 로깅 구성 및 모니터링의 필요성을 강조합니다. 또한, Claude Code의 "Extended Thinking" 출력에 대한 분석은 AI 생성 콘텐츠의 진위성에 대한 우려를 제기합니다. 출력의 일부는 더 일관성 있게 보이도록 조작될 수 있으며, 이는 신뢰 및 무결성 위험을 초래합니다. 보안에서 AI에 대한 의존은 출력의 정확성과 출처에 대한 확신을 필요로 합니다. 진정성 없는 AI 설명은 잘못된 정보에 기반한 결정이나 취약점 도입으로 이어질 수 있습니다. AI 모델 출력의 더 큰 투명성과 검증 가능성은 보안에 민감한 워크플로우에 매우 중요합니다. 마지막으로, GitHub Copilot은 효율성을 높이기 위해 컨텍스트 처리 및 모델 라우팅을 개선하고 있습니다. 이러한 개선은 더 정확하고 관련성 높은 제안을 생성함으로써 코드 보안을 미묘하게 향상시킵니다. 더 나은 컨텍스트 인지 능력은 오류나 안전하지 않은 패턴 도입 가능성을 줄입니다. 이러한 지속적인 개선은 인간에 의해 도입된 취약점을 완화함으로써 더 안전한 개발 파이프라인에 기여합니다.

Securing AI: Codex Operational Bugs, Claude Output Integrity, Copilot Context dev.to

RSS Hunter • 어제

DuckDB 1.5.2, PostgreSQL 내부 통계, 그리고 SQLite 가상 테이블 xUpdate 심층 분석

DuckDB가 안정성과 성능 개선에 초점을 맞춘 패치 업데이트인 버전 1.5.2를 출시했습니다. 이번 릴리스에는 중요한 버그 수정과 더 빠른 쿼리 실행을 위한 성능 병목 현상 해결이 포함되어 있습니다. 중요한 새로운 기능은 DuckLake v1.0 레이크하우스 형식에 대한 공식 지원으로, 복잡한 데이터 아키텍처에 대한 유용성을 향상시킵니다. 이 통합을 통해 레이크하우스 패러다임에 저장된 데이터를 효율적으로 쿼리하고 관리할 수 있습니다. PostgreSQL의 pg_stats에 대한 기사는 성능 튜닝 및 쿼리 최적화를 위한 내부 통계에 대해 자세히 설명합니다. Postgres가 이러한 통계를 수집, 저장 및 활용하는 방법을 이해하는 것은 효과적인 데이터베이스 관리에 중요합니다. 이 통찰력은 개발자와 DBA가 쿼리 계획을 해석하고 최적화할 영역을 식별하는 데 도움이 됩니다. SQLite 포럼 토론은 쓰기 가능한 가상 테이블을 구현하기 위한 xUpdate 메서드를 강조합니다. xUpdate 메서드는 INSERT, UPDATE 및 DELETE 작업을 처리하여 사용자 지정 데이터 소스에 대한 DML 기능을 활성화합니다. xUpdate를 마스터하는 것은 강력한 가상 테이블을 구축하고 SQLite의 기능을 확장하는 개발자에게 필수적입니다. 이를 통해 외부 데이터 소스를 전체 수정 지원이 포함된 표준 SQLite 테이블로 취급할 수 있습니다.

DuckDB 1.5.2, PostgreSQL Internal Stats, and SQLite Virtual Table xUpdate Deep Dive dev.to

RSS Hunter • 어제

이름이 변경된 열이 CSV 내보내기를 조용히 중단시킨 경험이 있으신가요? csv-pipe는 이를 컴파일 오류로 만들고, 양방향으로 읽고 쓰며, papaparse보다 몇 배 더 빠르게 파싱합니다. 게시물에 라이브 플레이그라운드가 있어 직접 데이터를 시험해 볼 수 있습니다.

csv-pipe: TypeScript에서 CSV 읽기 및 쓰기, papaparse보다 몇 배 더 빠름 Myroslav Martsin Myroslav Martsin Myroslav Martsin 팔로우하기 6월 22일 csv-pipe: TypeScript로 CSV 읽기 및 쓰기, papaparse보다 몇 배 더 빠름 #javascript #typescript #webdev #node 반응 1개 댓글 달기 읽는 데 2분

Ever had a renamed column quietly break a CSV export? csv-pipe makes it a compile error, reads and writes both ways, and parses several times faster than papaparse. Live playground in the post to try your own data. dev.to

RSS Hunter • 어제

성과 검토가 실패하는 이유는 관리자들이 무슨 일이 있었는지 잊어버리기 때문이다

인간의 기억은 수개월간의 작고 중요한 업무 순간들을 회상하는 데 어려움을 겪으며, 이는 관리자들의 성과 검토에 어려움을 초래합니다. 주요 성과와 긍정적인 상호작용은 검토 시점에 잊혀질 수 있습니다. 결과적으로 관리자들은 직원의 성과를 재구성하기 위해 단편적인 기억, 흩어진 메모, 다양한 문서에 의존하는 경우가 많습니다. 이러한 의존성은 최근 사건이 평가에 불균형적으로 영향을 미치는 최신성 편향(recency bias)을 자주 초래합니다. 많은 관리자들은 이러한 문제에 대처하기 위해 개인적인 시스템을 개발하여 노트북, 스프레드시트, 심지어 AI 도구를 사용하여 메모를 작성합니다. 그러나 핵심 문제는 메모 작성 자체에 있는 것이 아니라, 이러한 메모를 응집력 있는 성과 서사로 효과적으로 전환하는 데 있습니다. FeedbackVault는 관찰이 발생하는 즉시 이를 포착하고 역사적으로 정리함으로써 이 문제를 해결하고자 합니다. 이 플랫폼은 관리자들이 회상 노력을 필요로 하기보다는, 시간이 지남에 따른 직원의 기여에 대한 즉시 사용 가능한 기록을 제공하는 것을 목표로 합니다. FeedbackVault의 주요 장애물은 사용자 채택입니다. 기존 방법들은 완벽하지는 않지만 이미 사용되고 있기 때문입니다. 확립된 관행에서 전환을 장려할 만큼 충분한 가치를 창출하는 것이 현재의 초점입니다. 제작자는 관리자들에게 현재의 검토 준비 과정과 어려움에 대한 피드백을 구하고 있습니다. FeedbackVault를 효과적으로 개발하기 위해서는 실제 워크플로우를 이해하는 것이 중요합니다.

Performance Reviews Fail Because Managers Forget What Happened dev.to

RSS Hunter • 어제

Sentry vs OpenTelemetry: 하나를 선택할 필요는 없습니다

기존 OpenTelemetry 백엔드에 Sentry를 통합하려면 OTLP 엑스포터를 Sentry의 엔드포인트로 지정하도록 구성하면 됩니다. 이 과정은 기존 계측을 다시 작성할 필요 없이 최소한의 변경만 필요합니다. 웹 애플리케이션의 경우, 브라우저 컨텍스트를 캡처하기 위해 프런트엔드에 Sentry SDK를 추가하는 것이 좋습니다. 이를 통해 사용자 상호 작용부터 백엔드 작업까지의 트레이스를 통합된 시각으로 볼 수 있습니다. OpenTelemetry는 트레이스, 로그, 메트릭을 지원하지만, Sentry는 현재 OTLP를 통해 트레이스와 로그만 수집합니다. 핵심은 트레이스 연결을 OTLP 내보내기와 분리하는 것입니다. 트레이스 연결은 프런트엔드 및 백엔드 요청 전반에 걸쳐 연속적인 분산 트레이스를 보장합니다. Sentry 프런트엔드 SDK는 W3C traceparent 헤더를 전파하여 이를 처리합니다. 백엔드 OTLP 이벤트가 어디로 전송되는지에 대한 결정은 별개입니다. Sentry로 직접 보내거나 OpenTelemetry Collector를 통해 보낼 수 있습니다. 직접 OTLP 내보내기는 단일 백엔드 프로젝트에 가장 간단합니다. Collector 전달은 여러 서비스에 대한 중앙 집중식 처리 및 라우팅을 제공합니다. 데모 아키텍처는 Sentry SDK를 사용하는 React 프런트엔드, OpenTelemetry를 사용하는 FastAPI 백엔드, 그리고 OpenTelemetry Collector를 보여줍니다. 백엔드는 수동 스팬 및 로그를 포함하여 OpenTelemetry 설정을 유지합니다. 그런 다음 Collector는 이러한 OTLP 이벤트를 Sentry로 전달합니다. CORS는 교차 출처 요청에 대한 트레이스 전파 헤더를 허용하도록 백엔드에서 올바르게 구성되었는지 확인하십시오.

Sentry vs OpenTelemetry: You Don’t Need to Pick One dev.to

RSS Hunter • 어제

훌륭한 아키텍처에는 가시성이 포함됩니다

훌륭한 아키텍처는 실행 중인 시스템을 팀이 이해할 수 있도록 하는 것을 필요로 하며, 이는 관찰 가능성(observability)을 설계 논의의 중요한 부분으로 만듭니다. 실제 시스템 동작에 대한 이해의 격차를 피하기 위해 관찰 가능성은 초기 개발 중에 통합되어야 하며, 나중에 추가되는 사후 고려 사항이 되어서는 안 됩니다. 아키텍처는 가정 위에 구축되며, 관찰 가능성 없이는 이러한 가정을 프로덕션에서 테스트할 수 없습니다. 관찰 가능한 시스템은 기술적 신호를 실제 사용자 영향과 연결하여 시스템이 어떻게 작동하는지에 대한 진실을 제공합니다. 관찰 가능성은 단순히 로그를 갖는 것을 넘어섭니다. 이는 맥락을 제공하고 더 빠른 디버깅 및 의사 결정을 가능하게 하기 위해 분산된 신호를 연결하는 것을 포함합니다. 관찰 가능성의 이점은 단순히 더 빠른 디버깅뿐만 아니라 팀이 추측에서 증거 기반 조사로 이동하여 의사 결정을 내리는 방식의 근본적인 변화입니다. 시스템의 아키텍처를 형성하는 동안 가시성을 구축하는 것이 나중에 개조하는 것보다 훨씬 쉽습니다. 가장 유용한 신호는 사용자 경험이나 워크플로 완료와 같은 실제 영향에 기술적 지표를 연결합니다. 관찰 가능성은 시스템을 운영, 지원 및 개선할 수 있도록 보장하기 위해 아키텍처 검토에서 핵심 고려 사항이어야 합니다. 궁극적으로 강력한 관찰 가능성은 명확한 피드백 루프를 생성하여 엔지니어링 모멘텀을 촉진하고 팀이 시스템을 자신 있게 운영하고 발전시킬 수 있도록 합니다.

Good Architecture Includes Observability dev.to

RSS Hunter • 어제

process.env에 대해 아무도 알려주지 않는 10가지 사실

환경 변수는 까다로울 수 있으며, 일반적인 개발 함정을 피하기 위해 그 미묘한 차이를 이해하는 것이 중요합니다. Linux에서는 환경 변수 키가 대소문자를 구분하지만, Windows에서는 대소문자를 구분하지 않아 "내 컴퓨터에서는 작동하는데"와 같은 문제가 발생할 수 있습니다. process.env에서 검색된 모든 값은 문자열이므로, 예상치 못한 동작과 잠재적인 NaN을 피하기 위해 숫자와 부울 값은 명시적으로 파싱해야 합니다. process.env 객체는 .env 파일과 별개이며, Node.js는 특정 구성 없이는 .env 파일을 자동으로 읽지 않습니다. 환경 변수는 명령별로 설정할 수 있어 단일 프로세스로 범위를 제한하고 쉘 오염을 방지할 수 있습니다. 런타임에 process.env를 변경하는 것은 디버깅을 크게 방해하고 불확실성을 야기하므로 강력히 권장되지 않습니다. Next.js는 특히 빌드 시점에 NEXT_PUBLIC_ 변수를 인라인하므로, 프로덕션 서버에서 이러한 변수를 변경하면 다시 빌드해야 적용됩니다. process.env는 브라우저에서 직접 사용할 수 없으며, Webpack 및 Vite와 같은 빌드 도구는 종종 노출되는 변수에 특정 접두사를 사용하여 이를 에뮬레이트합니다. NODE_ENV 변수는 Node.js에서 기본적으로 설정되지 않으며 프레임워크에서 처리하거나 명시적으로 설정해야 합니다. 일부 시스템에서는 환경 변수 값에 크기 제한이 있을 수 있으므로 큰 데이터는 잘릴 수 있다는 점에 유의해야 합니다. 마지막으로, 환경 변수는 자식 프로세스에 상속되므로 비밀 정보가 필요하지 않은 프로세스에 노출될 수 있습니다.

10 Things Nobody Tells You About process.env dev.to

RSS Hunter • 어제

첫 번째 문자 메시지에는 ‘메리 크리스마스’라고 적혀 있었다

최초의 문자 메시지는 1992년 12월 3일에 보낸 간단한 "Merry Christmas"였습니다. 22세의 엔지니어인 닐 파프워스가 컴퓨터에서 보다폰 이사의 휴대폰으로 테스트 삼아 이 역사적인 SMS를 보냈습니다. 당시 휴대폰은 답장을 보낼 수 없어 일방통행 통신이었습니다. SMS는 전화 통화에 사용되는 제한된 제어 채널에 맞도록 설계되었으며, 메시지는 160자로 제한되었습니다. 이 제약 덕분에 SMS는 가볍고 견고하며, 데이터 연결이 약하거나 없는 경우에도 저장 후 전달(store-and-forward)이 가능했습니다. 30년이 지난 지금도 이 기술은 원격 또는 연결성이 낮은 지역의 사물 인터넷(IoT) 장치에 필수적입니다. 많은 IoT 배포는 Wi-Fi나 안정적인 데이터에 의존할 수 없으므로, 상태 업데이트 및 명령을 위한 신뢰할 수 있는 대체 수단으로 SMS가 사용됩니다. 장치는 셀룰러 모듈을 통해 최소한의 전력과 복잡성으로 경고를 보내거나 지침을 받을 수 있습니다. 이러한 견고성은 이상적인 네트워크 조건 너머에서도 안정적으로 작동해야 하는 실제 제품에 매우 중요합니다. 최초 SMS의 지속적인 유산은 단순성, 효율성, 견고성에 있으며, 이는 효과적인 임베디드 설계에 필수적인 자질입니다.

The First Text Message Said Merry Christmas dev.to

RSS Hunter • 어제

Claude를 위한 작업 패널을 구축하면서 발견한 MCP 앱의 두 가지 미해결 버그

저자는 Claude 대화 내에 지속적인 작업 패널을 표시하는 오픈 소스 MCP 서버인 Wingman을 개발했습니다. 이를 위해 저자는 견고하다고 생각한 MCP Apps와 관련 SDK를 활용했습니다. 그러나 문서화되지 않은 두 가지 심각한 버그로 인해 상당한 개발 시간이 소요되었습니다. 첫 번째 버그는 `resourceUri`의 위치에 관한 것으로, `structuredContent` 내부가 아닌 `CallToolResult` 객체의 최상위 `_meta`에 있어야 합니다. 도구에서 일반 사전(dictionary)을 반환하면 `_meta`가 잘못 중첩되어 호스트가 렌더링할 리소스를 찾지 못하게 될 수 있습니다. 수정 방법은 `_meta`가 올바르게 배치된 적절한 `CallToolResult` 객체를 반환하는 것입니다. 두 번째 주요 버그는 CSS 특이성 문제로 인해 `[hidden]` 속성이 재정의되는 것에서 비롯되었습니다. 사용자 정의 스타일시트의 명시적인 `display` 규칙이 JavaScript에 의해 의도된 대로 요소를 숨기는 것을 방해했습니다. `[hidden]` CSS 규칙에 `!important`를 추가하는 한 줄로 세 가지 별도의 UI 문제가 동시에 해결되었습니다. 추가적으로, MCP Apps 호스트 내에서 세 가지 iframe 샌드박스 제약 조건이 발견되었습니다. `confirm()`은 조용히 실패하고, `navigator.clipboard.writeText`는 사용할 수 없으며, `Blob`/`URL.createObjectURL` 다운로드는 차단됩니다. 이러한 제한 사항은 인라인 확인 사용 및 `sendMessage`를 통해 콘텐츠를 다시 라우팅하는 것과 같은 해결 방법이 필요합니다. 저자는 이러한 API 실패가 일반적으로 오류가 아닌 조용한 비작동으로 이어져 진단하기 어렵다고 강조합니다. 궁극적으로 두 가지 주요 버그 모두 초기 검사 지점에서 한 단계 떨어진 문제와 관련이 있었으며, 디버깅 중에 이러한 중간 단계를 확인하는 것의 중요성을 강조합니다. Wingman은 MIT 라이선스로 PyPI에서 사용할 수 있습니다.

Two undocumented bugs in MCP Apps I found building a task panel for Claude dev.to

RSS Hunter • 어제

에이전트 루프에 대해 사람들이 오해하는 점

"모두가 이제 에이전트 시스템을 "소프트웨어 공장"이라고 부릅니다. 하지만 공장이 작동하는 이유는 QC가 기계적이고 협상 불가능하기 때문입니다. CNC 밀은 공차를 유지하거나 생산을 중단합니다. 대부분의 에이전트 루프는 이를 건너뛰고 에이전트가 자체 출력을 평가하도록 합니다. 정확성 없는 볼륨입니다. 그래서 저희는 zeroshot을 만들었습니다: https://github.com/the-open-engine/zeroshot 현재 1500개의 스타를 보유하고 있으며, 더 많은 피드백과 트랙션을 얻고 싶습니다."

What people get wrong about agent loops dev.to

RSS Hunter • 어제

셀프 호스팅 Duende를 떠나며: 무엇을 마이그레이션하고, 무엇을 운영 중단하는가

Duende IdentityServer는 .NET에서 자체 ID 계층을 소유하기 위한 강력한 솔루션이지만 상당한 운영 오버헤드가 따릅니다. 자체 호스팅은 패치, 확장 및 라이선스를 포함하여 IdP 자체를 관리해야 하며, 관리 UI, MFA 및 감사 로그와 같은 모든 주변 기능을 구축해야 합니다. 많은 팀은 결국 이러한 운영 부담을 해소하기로 결정하며, 마이그레이션이 주요 고려 사항이 됩니다. 좋은 소식은 Duende의 구성이 SQL에 있고 사용자가 ASP.NET Identity에 있기 때문에 Duende에서 마이그레이션하는 것이 대부분 기계적이라는 것입니다. 클라이언트, 범위 및 사용자는 원활하게 마이그레이션됩니다. 중요한 것은 ASP.NET Identity V3 비밀번호 해시는 기본적으로 지원되므로 다른 IdP 마이그레이션에서 흔히 발생하는 문제점인 사용자 비밀번호 재설정의 필요성이 사라진다는 것입니다. 역할, 할당, 외부 로그인 및 OIDC ID 공급자는 SAML 공급자는 재구성해야 하지만 직접 전송됩니다. ID 안정성을 유지하는 것이 가장 중요하므로 마이그레이션은 다운스트림 종속성을 중단하지 않도록 사용자 'sub' 및 'client_id'를 보존합니다. 마이그레이션 도구는 실제 시드된 Duende 데이터베이스에 대해 엄격하게 테스트되어 잠긴 사용자에 대한 datetimeoffset 처리와 같이 가져오기 실패를 유발할 수 있는 미묘한 문제를 포착합니다. 이동의 주요 이점은 IdP 운영을 중단하고 대신 SAML, SCIM, MFA, 감사 로그 및 사용자 지정 브랜딩에 대한 포함된 기능을 활용하여 패치 및 확장 책임을 해소하는 것입니다. 완전한 제어 유지가 우선 순

Leaving self-hosted Duende: what migrates, and what you stop operating dev.to

RSS Hunter • 어제

Immutable Ledgers는 벡터 검색의 미래인가요? 그리고 로컬에서 실행됩니다.

이 문서는 해시 체인과 머클 트리를 사용하여 스토리지 시스템 무결성을 위한 불변 원장을 탐구합니다. Kamelot의 추가 전용 원장으로 예시된 아키텍처는 데이터 무결성과 버전 기록을 향상시킵니다. 머클 트리 및 인증된 사전과 같은 기본적인 암호화 구조를 검토합니다. 이는 효율적인 검증 및 추가 작업과 함께 Git과 유사한 콘텐츠 주소 지정을 가능하게 합니다. 이 연구는 주권적이고 로컬 우선적인 AI 인프라가 현재 달성 가능하다는 것을 주장합니다. Anticloud 프로젝트는 기존 AI에 대한 투명하고 검증 가능한 대안으로 제시됩니다. 외부 API나 중앙 집중식 데이터베이스 없이 설계상 개인 정보 보호를 우선시합니다. 시스템은 출력을 상호 검증하고 잘못된 확신을 생성하는 대신 불확실성을 표현합니다. 로컬 AI는 RAG 및 RLHF를 통해 달성되며, 지식과 선호도를 사용자 하드웨어에 유지합니다. Anticloud는 단일 머신과 바이너리를 요구하며 신뢰의 필요성을 제거합니다. Lois-Kleinner Alpasan은 AI 산업의 데이터 추출 관행에 대한 대응으로 이 시스템을 개발했습니다. 이 프로젝트는 검증 가능한 주장, 오픈 소스 구성 요소 및 개인 정보 중심 아키텍처를 강조합니다.

Immutable Ledgers is the future of vector search ? and it runs locally. dev.to

RSS Hunter • 어제