Go의 동시성 제한: errgroup, 워커 풀, 백프레셔
취소만 하려는 것이 아니라, 진행 중인 작업을 캡(상한)으로 제한하세요.
무제한 팬아웃은 Go 병행 처리의 기본 실패 모드입니다. 모든 go 문장은 상한이 없고 소유자도 없는 상태로 비행 중인 태스크 하나를 더 추가할 뿐입니다. 이 글은 그 두 가지를 부여하는 방법에 관한 것입니다.
취소만 하려는 것이 아니라, 진행 중인 작업을 캡(상한)으로 제한하세요.
무제한 팬아웃은 Go 병행 처리의 기본 실패 모드입니다. 모든 go 문장은 상한이 없고 소유자도 없는 상태로 비행 중인 태스크 하나를 더 추가할 뿐입니다. 이 글은 그 두 가지를 부여하는 방법에 관한 것입니다.
다섯 가지 Go HTTP 스택, 단일 벤치마크 환경, 실측 데이터.
Go는 표준 라이브러리에 프로덕션 환경에서 사용할 수 있는 HTTP 서버를 제공합니다. Go 1.22부터는 내장된 라우터가 메서드 매칭과 경로 파라미터를 자체적으로 처리합니다. 프레임워크에 대한 질문은 사라진 것이 아니라 축소되었습니다.
기억된 결론이 새로운 증거가 될 때
지속적 메모리는 에이전트를 매번 설명을 들어야 하는 도구에서 컨텍스트를 유지하며 나아가는 존재로 전환시켜 줍니다. 하지만 이는 무상태(stateless) 채팅이 피하는 실패 모드를 열어젖히기도 합니다. 해석(interpretation)이 메모리가 되어 사실처럼 검색되고, 이를 근거로 자신에 대한 더 강력한 버전의 정당화를 만드는 식입니다.
통제된 쓰기 기능을 갖춘 로컬 Hermes 메모리
Mnemosyne은 Hermes Agent를 위한 로컬 퍼스트(local-first) 메모리 프로바이더입니다. 워킹 메모리, 구조화된 사실, 시간 데이터, 그리고 에피소드적 역사를 로컬 SQLite에 저장하며, 호스팅된 서비스나 필수적인 네트워크 호출 없이도 유독 세밀한 수준의 쓰기(write) 제어를 제공합니다.
거부 상태가 없습니다. 다음은 임시 해결책입니다.
6개월 전 “영속성을 공유 라이브러리로 이동"을 제안하고 배포했던 에이전트는, 그 아이디어가 이미 검토되어 기각되었다는 것을 지속적으로 기록하는 것이 없다면 다음 분기에 같은 것을 다시 제안할 것이다 — 그리고 OpenSpec에는 현재 이를 위한 내장 상태가 없다.
40페이지짜리 PRD가 아닌, 델타(deltas) 형태의 스펙
OpenSpec은 Fission AI가 제공하는 무료 오픈소스 CLI 도구로, 코드가 작성되기 전에 사용자가 코딩 에이전트와 평범한 마크다운으로 변경 사항에 대해 합의할 수 있게 해줍니다. 무거운 스펙 기반 프레임워크의 단계별 복잡한 절차 없이 이를 가능합니다.
LLM 이후의 시대: 트랜스포머 이후
AI 열풍에는 일정한 리듬이 있다: 대략 3년마다, 모두가 베팅하고 있는 아키텍처가 더 새로운 것으로 대체된다. 다음 전환은 이미 연구실에서 형성되고 있다.
10개의 명령으로 강제되는 SDD 스킬
Superpowers는 뇌暴(brainstorming), 계획 수립, 서브에이전트 기반 구현, 엄격한 TDD(Test-Driven Development)를 강제하는 스펙 기반 개발 방법론 전체를 설치 가능한 Claude 스킬 패키지로 묶어 제공합니다.
AI 스택이 매월 더욱 강하게 고정되는 이유
모든 API 호출은 단순한 거래처럼 느껴집니다. 하지만 그 수가 쌓이면, 파인튜닝 데이터, 평가 하네스, 도구 스키마가 모두 하나의 벤더 주위에 형성되어, 벤더 전환이 더 이상 단순한 라우팅 변경이 아닌 상황이 됩니다.
AI 에이전트가 요구사항, 테스트 및 코드에서 벗어나는 것을 막으세요.
AI 코딩 에이전트는 기능을 빠르게 출시하지만, 명세서(specs), 테스트, 그리고 코드는 조용히 서로 다른 방향으로 이동(drift)합니다. 이 가이드는 추적 가능성(traceability) 모델, 명세서-테스트 및 명세서-코드 매핑, 그리고 병합 전에 이러한 드리프트를 포착하는 CI(CI) 검사를 다룹니다.
Go 마이크로서비스에서 연쇄 장애를 방지하세요.
서킷 브레이커는 실패하는 종속성(의존 서비스)에 대한 과도한 호출을 차단하여, 고르틴(goroutine), 소켓, 메모리를 고갈시키며 전체 시스템이 무너지기 전에 연쇄 장애(cascading failures)를 방지합니다.
가장 좋은 도구가 아니라, 처리의 깊이와 이동성 간의 문제
2026년 현재 스펙 기반 개발(Spec-Driven Development, SDD) 환경을 비교하는 개발자들은 보통 가장 지능적인 모델이 무엇인지 묻지 않습니다. 그들은 어떤 워크플로우가 AI 에이전트를 의식적인 예식(ceremony) 속에 빠뜨리지 않으면서도 정렬(alignment) 상태를 유지할 수 있는지 묻습니다.
의도에서 검증된 코드로의 5단계
스펙 기반 개발(SDD, Spec-Driven Development)은 스펙이 문서화된 자료가 아니라 워크플로우일 때 비로소 빛을 발합니다. 핵심은 방대한 제품 요구사항 명세서를 작성하는 데 있지 않습니다.
프로토콜 보안은 모델이 아닌 행위 주체를 규정합니다.
프롬프트 인젝션은 LLM 시스템에서 가장 많은 보안 관심을 받고 있으며, 주목받을 만하지만 에이전트가 도구를 호출하고 작업을 다른 에이전트에 위임하기 시작하면 이것이 유일한 문제는 아닙니다.
장기간 실행되는 A2A 작업은 채팅 세션보다 더 오래 지속됩니다.
대부분의 AI 에이전트 데모는 여전히 몇 가지 추가 단계를 거친 채팅 완성(chat completion)과 비슷하게 작동합니다. 프롬프트를 보내고 몇 초를 기다린 후, 하나의 응답으로 답변을 받습니다.
멀티 에이전트 파일럿의 40%가 실패합니다. 올바른 오케스트레이션 패턴을 선택하고, 실패로 이어지는 패턴을 피하는 방법에 대해 설명합니다.
2025년, 단일 에이전트 AI 시스템은 정점에 달했습니다 — LLM 하나에 프롬프트, 도구, 목표를 주면 제한된 범위 내의 작업에서 꽤 괜찮은 성과를 내ことができました.