라벨이 arm인 게시물 표시

구글 안티그래비티 완전 분석 — 모델·요금제·CLI 총정리

🚀 구글 안티그래비티(Antigravity) 완전 분석 구글이 2025년 11월 Gemini 3와 함께 공개한 에이전트 퍼스트(agent-first) IDE 안티그래비티는 Claude·GPT·Gemini를 한 도구에서 골라 쓰는 멀티모델 코딩 환경이다. 이 글에서는 ① 지원 모델과 요금제별 사용량의 실체, ② 실사용자 평가, ③ 구글의 방향성, ④ Claude Code와의 비교·연계, ⑤ CLI( agy )로 직접 쓰는 법까지 다섯 갈래를 차례로 정리한다. 자료 간 충돌이 있는 지점은 한쪽으로 단정하지 않고 양쪽을 모두 살려 표기했다. 📅 기준 시점: 2026년 6월 · 프리뷰 단계 정보로 수치는 변동 가능 1. 안티그래비티란 무엇인가 — 기초 정리 안티그래비티는 2025년 7월 구글이 24억 달러 규모 라이선스 계약 으로 영입한 전 Windsurf 팀이 설계를 주도했다. VSCode를 포크한 위에 자율 에이전트 오케스트레이션 계층을 얹은 구조다. 2026년 5월 Google I/O에서 발표된 안티그래비티 2.0 은 데스크탑 앱과 함께 공식 CLI agy 를 처음 공개하며 기존 Gemini CLI의 공식 후계자 자리를 확정했다. 핵심 정체성은 단순 코드 자동완성이 아니라 병렬 에이전트 오케스트레이션 이다. 여러 에이전트가 동시에 — 하나는 API, 하나는 테스트, 또 하나는 프론트엔드 — 작업을 나눠 진행하고, 각 에이전트는 계획·테스트 결과·스크린샷·영상을 담은 Artifact 를 남긴다. "사람이 한 줄씩 승인"하는 방식이 아니라 "에이전트들이 일을 마치고 사람이 사후 검수"하는 모델이다. flowchart TD A([사용자 작업 지시]) --> B[에이전트 A API 구현] A --> C[에이전트 B 테스트 작성] A --> D[에이전트 C UI 생성] B --> E[Artifact 계획·결과·영상] C --> E D --> E...

[AMBA]CHI Overview

  개요 AMBA5의 일부로 high-performance, packet-based communication 프로토콜로 processors와 다른 구성요소들의 연결을 위해 Arm에 의해 개발. 복잡한 멀티코어 시스템에서 모든 프로세서의 캐시가 메인 메모리에 대해서 일관된 보기를 제공해서 캐시 일관성을 보장 Key Concepts and Features Node-Based Architecture 전통적인 master/slave 관계 개선 "nodes"라는 더 유연한 시스템을 사용 Request Node(RN) Initiates transactions Home Node(HN) 특정 메모리 영역을 관리하고 해당 영역에 대한 coherency를 관리 Slave Node(SN) or Subordinate Node Interconnect에서의 request에 대한 응답 Packet-Based Communication 명령어, 데이터, 응답과 같은 모든 응답은 5개의 채널에 의해 packet 형태로 전송됨 고효율적이고 병렬적로 데이터 flow 가능 Layered Structure 상위수준의 프로토콜 규칙에서 하위 수준의 데이터 전송을 계층별 분리 칩 설계자는 PPA(Power, Performance and Area)에 맞게 최적화 할 수 있는 유연성을 확보 Scalability CHI는 수많은 components와 복잡한 interconnect를 처리하게 설계되어 휴대폰에서부터 대규모 데이터 센터 서버에 이르기까지 적합 Evolution from ACE ACE(AXI Coherency Extentions)의 계승자 Performance 개선, bottlenecks 감소 그리고 확장성이 개선 Evolution and Key Revisions CHI는 시간이 지나면서 진화하였고, 새로운 "Issue"가 추가될 때마다 중요한 feature가 추가 됨 Issue B 캐시 스태싱[^1] 및 RAS(향상된 안정성) features 추가 Issue ...

[후기] 시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리

이미지
  700쪽에 달하는 방대한 분량과 19챕터로 이루어진 체계적인 구성이 인상적인 책이다. 처음 Arm 아키텍처에 대해서 공부하려는 사람에게 유용하다. 단, 컴퓨터구조를 배우려는 사람한테는 목적에 맞지 않기 때문에 추천하고 싶지는 않다. Arm의 Cortex 프로세서를 사용하는 환경에서 시스템 코딩을 하는 사람들과 Cortex 프로세서를 integration 하고 검증해야 하는 SoC엔지니어 모두에게 좋은 책이다. 필자는 SoC엔지니어로서 최근 Cortex-A 프로세스를 담당하는 업무를 진행중인데 워낙 방대한 공식 문서들이 있어서 어디서부터 어떻게 공부를 해야 하며, 기초가 없는 상황에선 어떤 순서대로 공부해야 하는지 막막한 상황에 처한 것도 사실이었다. 처음엔 무작정 TRM(테크니컬 레퍼런스 메뉴얼, Arm의 공식 문서)과 아키텍처 문서, ISA 문서 등등을 보면서 RTL을 integration 하고, 시뮬레이션으로 boot를 진행하면서 막히는 부분을 부분부분 살피면서 하는 과정을 거쳤었다. 당연히 제대로 공부하지 못했고 내가 어떤걸 봐야하는지 모르는게 사실이었다. 업무와 병행해서 그런지 이 책은 나에게 Cortex의 구조와, tarmac 등의 신호들을 어떻게 봐야 할 것이며, 현재 simulation에서 잘못된 부분이 어떤 것인지 내가 찾아서 디버깅을 할 수 있게 만든 좋은 길잡이었다. 특히 시스템 엔지니어들이 알면 bootcode 및, 설정등을 다루기에도 충분한 내용들이 있어서 이 책을 양쪽 모두에게 추천했던 바였다. 다만 조금 아쉬운 점도 있다. 책의 중반부분에 각각의 Exception Level에 대한 설명들과 각 Exception을 넘어가는 흐름 등등을 설명하면서 VBAR라는 vector table을 참조하는 방법들에 대한 설명들이 있는데, 이 부분이 과도하게 복붙된 느낌이있다. 개념이 없다는 것은 아니나, 대부분이 비슷하게 생긴 table을 가져오고, 거기에서 offset을 적용해 어떤 주소로 뛴다. 이런 정보들이 수십페이지는 되는 느낌이었다...

Arm GIC-v3에 대해서

  Arm Generic Interrupt Controller (GIC) 개요 GIC는 Arm에서 설계한  Generic Interrupt Controller 로, 외부 장치에서 발생하는 인터럽트를 수집하고, 이를 처리할 적절한 CPU 코어에 전달하는 역할을 합니다. 이는 단일 코어부터 다수의 멀티코어 환경까지 효율적으로 인터럽트를 관리할 수 있도록 설계되었습니다. GIC는 Cortex-A 및 Cortex-R 계열 프로세서와 함께 주로 사용되며, Arm 기반 SoC(System on Chip)에서 표준 인터럽트 관리 솔루션으로 자리 잡았습니다 주요 기능 인터럽트 수집 및 분배 : 다양한 외부 장치(Peripheral)에서 발생한 인터럽트를 수집하고, 이를 적절한 CPU 코어에 전달. 우선순위 기반 라우팅 : 인터럽트의 우선순위를 설정하여 높은 우선순위의 인터럽트를 먼저 처리. 멀티코어 지원 : 8개 이상의 코어를 지원하며, 특히 GICv3/v4는 서버 시장을 겨냥해 설계됨 GICv3 요약 GICv3는 Armv8 아키텍처와 함께 도입된 최신 버전의 GIC로, 특히 AArch64 기반 시스템에서 사용됩니다. 기존 GICv2와 비교해 다음과 같은 주요 개선 사항이 있습니다: 확장된 코어 지원 : 8개 이상의 코어를 지원하며, 서버와 같은 대규모 멀티코어 환경에 적합. Interrupt Translation Service (ITS) : 메시지 기반 인터럽트(Message Signaled Interrupt, MSI)를 처리하기 위한 추가 기능. 시스템 레지스터 접근 방식 : GICv3부터 CPU 인터페이스가 시스템 레지스터로 구현되어 메모리 맵 접근이 필요하지 않음 GICv3의 주요 구성 요소 Distributor : SPI(Shared Peripheral Interrupt)를 관리하고 각 CPU로 인터럽트를 분배. Redistributor : SGI(Software Generated Interrupt), PPI(Private Peripheral Int...

ARMv8-A Exception Level

  ARMv8-A의 **Exception Level (EL)**은 소프트웨어 실행 권한을 계층적으로 나누는 개념으로, 시스템의 보안 및 관리 목적으로 설계되었습니다. ARMv8-A는 두 가지 실행 상태인 AArch32(32비트)와 AArch64(64비트)를 지원하며, Exception Level은 이 두 상태 모두에서 작동합니다. 아래에서 AArch32와 AArch64 각각의 Exception Level에 대해 자세히 설명하겠습니다. Exception Level 개요 ARMv8-A는 총 4개의 Exception Level을 정의합니다: EL0 : 사용자 애플리케이션 (최하위 권한) EL1 : 운영 체제 커널 (e.g., Linux 커널) EL2 : 하이퍼바이저 (e.g., KVM 가상화) EL3 : 펌웨어 및 보안 모니터 (e.g., TrustZone Secure Monitor) 숫자가 높아질수록 권한이 증가하며, EL3은 가장 높은 권한을 가집니다. 각 Exception Level은 고유한 레지스터 집합과 스택 포인터를 가지며, 예외 처리 시 특정 레벨로 전환됩니다 AArch64의 Exception Level AArch64는 ARMv8-A에서 새롭게 도입된 64비트 실행 상태입니다. 이 상태에서는 A64 명령어 세트를 실행하며, 64비트 범용 레지스터를 사용합니다. AArch64에서의 Exception Level 동작은 다음과 같습니다: EL0 : 사용자 애플리케이션이 실행됩니다. EL1 : 운영 체제 커널이 실행됩니다. EL2 : 하이퍼바이저가 실행되며, 가상화 환경을 관리합니다. EL3 : 보안 모니터가 실행되며, Secure와 Non-secure 상태 간 전환을 처리합니다. 예외 발생 시, 프로세서는 현재 실행 중인 EL에서 더 높은 EL로 전환되며, 복귀 시 원래 EL로 돌아갑니다. 예를 들어, EL0에서 실행 중인 애플리케이션이 시스템 호출(SVC)을 하면 EL1으로 전환됩니다 AArch32의 Exception Level AArch32는 AR...