OpenSpec 기각 제안: 의사결정 메모리 컨벤션
거부 상태가 없습니다. 다음은 임시 해결책입니다.
6개월 전 “영속성을 공유 라이브러리로 이동"을 제안하고 배포했던 에이전트는, 그 아이디어가 이미 검토되어 기각되었다는 것을 지속적으로 기록하는 것이 없다면 다음 분기에 같은 것을 다시 제안할 것이다 — 그리고 OpenSpec에는 현재 이를 위한 내장 상태가 없다.
거부 상태가 없습니다. 다음은 임시 해결책입니다.
6개월 전 “영속성을 공유 라이브러리로 이동"을 제안하고 배포했던 에이전트는, 그 아이디어가 이미 검토되어 기각되었다는 것을 지속적으로 기록하는 것이 없다면 다음 분기에 같은 것을 다시 제안할 것이다 — 그리고 OpenSpec에는 현재 이를 위한 내장 상태가 없다.
40페이지짜리 PRD가 아닌, 델타(deltas) 형태의 스펙
OpenSpec은 Fission AI가 제공하는 무료 오픈소스 CLI 도구로, 코드가 작성되기 전에 사용자가 코딩 에이전트와 평범한 마크다운으로 변경 사항에 대해 합의할 수 있게 해줍니다. 무거운 스펙 기반 프레임워크의 단계별 복잡한 절차 없이 이를 가능합니다.
명령줄에서 OpenCode를 실제로 사용해 보기
OpenCode의 커맨드 라인 인터페이스(CLI)는 스크립팅, CI 파이프라인, 그리고 무인 에이전트 실행을 위해 설계되었습니다. 이 글은 일상 업무에서 CLI를 활용하는 실무 가이드입니다.
하나의 명령어로 설치되는 강제 SDD 기능
Superpowers는 설치 가능한 Claude Skills로 전체 스펙 주도 개발 방법론을 패키징하여, 브레인스토밍, 계획 수립, 서브에이전트 기반 구현, 엄격한 TDD를 강제함으로써 해당 구조를 사용자가 자유롭게 선택하도록 두지 않습니다.
사용자가 직접 형태를 만들어야 하는 작은 코딩 에이전트
Pi Coding Agent는 기본 도구 4개를 갖추고 있으며, 대부분의 동작을 확장, 스킬 및 사용자 자체 워크플로에 맡기는 최소한의 오픈소스 터미널 코딩 하네스입니다.
소음이 발생하는 작업은 위임하고, 컨텍스트는 깨끗하게 유지하세요.
대부분의 Claude Code 세션이 느려지고 지저분해지는 이유는 동일합니다. 탐색적인 grep 실행, 로그 덤프, 그리고 “하나 더 확인해 보자"는 식의 파일 확인 작업들이 모두 메인 대화 창에 영구적으로 남기 때문입니다.
메시지가 큐를 차단하지 않도록 방지하세요
데드 레터 큐(DLQ)는 소비자가 처리할 수 없는 메시지를 포착하는 안전망입니다. 이를 통해 한 가지 잘못된 페이로드가 큐에 있는 나머지 메시지들을 차단하거나 묵과하게 되는 것을 방지합니다.
Go 마이크로서비스에서 연쇄 장애를 방지하세요.
서킷 브레이커는 실패하는 종속성(의존 서비스)에 대한 과도한 호출을 차단하여, 고르틴(goroutine), 소켓, 메모리를 고갈시키며 전체 시스템이 무너지기 전에 연쇄 장애(cascading failures)를 방지합니다.
프로토콜 보안은 모델이 아닌 행위 주체를 규정합니다.
프롬프트 인젝션은 LLM 시스템에서 가장 많은 보안 관심을 받고 있으며, 주목받을 만하지만 에이전트가 도구를 호출하고 작업을 다른 에이전트에 위임하기 시작하면 이것이 유일한 문제는 아닙니다.
장기간 실행되는 A2A 작업은 채팅 세션보다 더 오래 지속됩니다.
대부분의 AI 에이전트 데모는 여전히 몇 가지 추가 단계를 거친 채팅 완성(chat completion)과 비슷하게 작동합니다. 프롬프트를 보내고 몇 초를 기다린 후, 하나의 응답으로 답변을 받습니다.
멀티 에이전트 파일럿의 40%가 실패합니다. 올바른 오케스트레이션 패턴을 선택하고 실패하는 패턴을 피하는 방법을 소개합니다.
2025년은 단일 에이전트 AI 시스템이 정점에 달했던 해였습니다. 여러분은 하나의 LLM에 프롬프트, 몇 가지 도구, 그리고 목표를 부여했고, 그것은 제한된 작업에서 꽤나 잘 수행했습니다.
데이터와 함께 이벤트를 기록하세요. 절대 분리하지 마세요.
동시에 성공해야 하는 두 개의 쓰기가 결국 각각의 실패로 이어집니다.
주문 서비스는 먼저 데이터베이스에 주문을 저장한 후, 메시지 브로커로 order.created 이벤트를 발행합니다.
Go의 컨텍스트는 저장소가 아닌 제어 흐름입니다.
Go의 context.Context는 잘못 사용할 만큼 충분히 간단합니다. 그리고 바로 그것이 문제입니다.
오류를 적절한 경계에서 처리하세요.
Go의 에러 처리는 불평하기 쉽습니다. 모든 Go 개발자는 수백 번 이 코드를 작성해 보셨을 것입니다:
동시 Go 테스트에서 잠들지 마세요.
Go의 동시성 코드를 테스트하는 일은 항상 약간의 규율을 필요로 했습니다. 고루틴(Goroutine)은 가볍고, 채널(Channel)은 단순하며, 컨텍스트(Context) 취소는 관례적인(idiomatic) 방식입니다. 실제 Go 서비스에서는 백그라운드 워커와 타이머가 어디에나 존재합니다.
A2A는 사라진 것이 아닙니다. 다만 범용적으로 쓰이지 않을 뿐입니다.
구글의 에이전트 투 에이전트(Agent2Agent) 프로토콜, 즉 A2A는 첫해를 다소 혼란스럽게 보냈습니다.