App Architecture

무한한 팬아웃(fan-out)은 Go 동시성에서 가장 흔한 실패 모드입니다. 모든 go 문장은 상한선 없이, 소유자 없이 비행 중인 태스크 하나를 더 추가합니다. 이 글은 그 둘—상한선과 소유자—을 부여하는 법에 관한 것입니다.

Go는 표준 라이브러리에 프로덕션 환경에서 사용할 수 있는 HTTP 서버를 제공합니다. Go 1.22부터는 내장된 라우터가 메서드 매칭과 경로 파라미터를 자체적으로 처리합니다. 프레임워크에 대한 질문은 사라진 것이 아니라 축소되었습니다.

AI 코딩 에이전트는 기능을 빠르게 출시하지만, 명세서(specs), 테스트, 그리고 코드는 조용히 서로 다른 방향으로 이동(drift)합니다. 이 가이드는 추적 가능성(traceability) 모델, 명세서-테스트 및 명세서-코드 매핑, 그리고 병합 전에 이러한 드리프트를 포착하는 CI(CI) 검사를 다룹니다.

데드 레터 큐(DLQ)는 소비자가 처리할 수 없는 메시지를 포착하는 안전망입니다. 이를 통해 한 가지 잘못된 페이로드가 큐에 있는 나머지 메시지들을 차단하거나 묵과하게 되는 것을 방지합니다.

서킷 브레이커는 실패하는 종속성(의존 서비스)에 대한 과도한 호출을 차단하여, 고르틴(goroutine), 소켓, 메모리를 고갈시키며 전체 시스템이 무너지기 전에 연쇄 장애(cascading failures)를 방지합니다.

스펙 기반 개발(SDD, Spec-Driven Development)은 스펙이 문서화된 자료가 아니라 워크플로우일 때 비로소 빛을 발합니다. 핵심은 방대한 제품 요구사항 명세서를 작성하는 데 있지 않습니다.

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

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

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

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

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

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

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

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

분산 시스템에서 중복성(Idempotency)은 네트워크 오류, 큐 재시도, 클라이언트 패닉, 그리고 운영자가 재실행을 누른 상황에서도 당신을 구워주는 속성입니다. 프로덕션 시스템에서는 중복 전송이 정상적인 현상입니다. 중복된 사이드 이펙트가 바로 버그입니다.

Slack 통합은 하나의 HTTP 호출로 메시지를 게시할 수 있기 때문에 속임수처럼 보일 정도로 간단해 보입니다. 하지만 Slack 을 상호작용적이고 신뢰할 수 있는 시스템으로 만들려고 할 때 흥미로운 부분이 시작됩니다.

Discord 는 이를 하나의 시스템으로 대할 때 진정한 통합 표면이 됩니다: 시스템이 이벤트를 게시하고, 인간이 결정을 내리며, 자동화가 워크플로우를 이어가는 곳입니다.