Architecture

프롬프트 인젝션은 LLM 시스템에서 가장 많은 보안 관심을 받고 있으며, 주목받을 만하지만 에이전트가 도구를 호출하고 작업을 다른 에이전트에 위임하기 시작하면 이것이 유일한 문제는 아닙니다.

대부분의 AI 에이전트 데모는 여전히 몇 가지 추가 단계를 거친 채팅 완성(chat completion)과 비슷하게 작동합니다. 프롬프트를 보내고 몇 초를 기다린 후, 하나의 응답으로 답변을 받습니다.

2025년, 단일 에이전트 AI 시스템은 정점에 달했습니다 — LLM 하나에 프롬프트, 도구, 목표를 주면 제한된 범위 내의 작업에서 꽤 괜찮은 성과를 내ことができました.

동시에 성공해야 하는 두 개의 쓰기가 결국 각각의 실패로 이어집니다.

주문 서비스는 먼저 데이터베이스에 주문을 저장한 후, 메시지 브로커로 order.created 이벤트를 발행합니다.

Go의 context.Context는 잘못 사용할 정도로 간단하며 — 바로 이것이 문제입니다.

스펙 기반 개발(Spec-Driven Development)은 소프트웨어 엔지니어들이 과거에 시도했다가 노력이 더 이상 보상을 주지 못할 때 제쳐두었던 아이디어 중 하나입니다.

스펙 기반 개발(Spec-Driven Development)은 2026년에 바이브 코딩의 방향성 상실(drift)에 대한 진지한 개발자의 해답으로 등장했습니다.

AI를 활용한 소프트웨어 개발에서 의사결정 기록은 누락된 기억 계층입니다. 기록의 대상은 무엇이가구축되었는가가 아니라, 왜 그렇게 결정되었는가에 초점을 맞춥니다. AI 도구가 코드를 작성하게 될 때 이 구분은 매우 중요해집니다.

Go의 에러 처리는 쉽게 불만을 제기할 수 있는 주제입니다. 모든 Go 개발자가 수백 번 이 코드를 작성해 봤을 것입니다:

동시성(Concurrent) Go 코드 테스트는 언제나 조금의 절제된 접근이 필요했습니다. 고루틴(Goroutine)은 저렴하고, 채널(Channel)은 단순하며, 컨텍스트 취소(Cancellation)는 아이디오파틱(Idiomatic)한 방법입니다 — 실제 Go 서비스에서는 백그라운드 워커와 타이머가 어디에나 존재합니다.

구글의 에이전트 투 에이전트(Agent2Agent) 프로토콜, 즉 A2A는 첫해를 다소 혼란스럽게 보냈습니다.

폴링 에이전트(Polling Agent)는 AI 어시스턴트 아키텍처에서 가장 화려하지는 않지만, 동시에 가장 유용한 구성 요소 중 하나입니다.

AI 에이전트 아키텍처는 이제 두 가지 레이어로 분화되기 시작하고 있습니다.

A2A 프로토콜(에이전트 투 에이전트 프로토콜)은 독립적인 AI 에이전트 시스템 간의 통신을 위한 개방형 표준입니다.

CQRS는 과대평가되고, 지나치게 복잡해지며, 때로는 평범한 CRUD의 지루함을 해결할 만병통치약으로 오해받는 패턴 중 하나입니다.

단일 모델 시스템은 간단합니다. 다중 모델 시스템은 강력합니다. 도전과제는 모델을 선택하는 것이 아니라, 이들을 조율하는 아키텍처를 설계하는 것입니다.