주제: design
-
파이프라인, 팬아웃, 오케스트레이터, 비평 패널: 작업 유형별로 맞는 멀티 에이전트 패턴
파이프라인은 정해진 순서의 변환 작업에 적합하고, 병렬 팬아웃은 서로 독립적인 하위 질문이나 여러 번 시도한 뒤 투표로 고르는 작업에 적합합니다. 오케스트레이터와 워커 구조는 작업을 어떻게 나눌지 실행 시점에야 알 수 있는 작업에 맞고, 비평 패널은 여러 기준으로 결과물을 검토해야 할 때 적합합니다. 각 패턴은 토큰 비용을 늘리고, 그 자체로 실패할 수 있는 조정 계층을 추가로 도입합니다.
-
Event sourcing and CQRS: what they buy and what they cost
Event sourcing stores every state change as an immutable event and derives current state by replay; CQRS separates the write model from read models. Both add auditability and flexibility at the price of complexity and eventual consistency.
-
Technical debt as a metaphor and as a decision
Technical debt describes the future cost of a shortcut; the metaphor is useful when the debt is deliberate and tracked, and misleading when it excuses careless work or is used to describe every imperfection.
-
Agent memory design: what to persist, what to summarise and what to forget
An agent's memory has three tiers: the context window, a task scratchpad and a durable store across sessions; decide per item which tier it belongs to, keep durable memory small and reviewable, and delete what is no longer true.
-
Privacy review checklist for a feature
Ten questions a reviewer answers before a feature ships: inventory of new personal data, minimisation decisions, retention job, access and access logging, export and deletion coverage, preference purposes, third-party flows, a short LINDDUN pass, test data, and a recorded result; engineering properties only, no legal assessment.
-
Dark mode with prefers-color-scheme, color-scheme and light-dark()
Dark mode has three parts: the prefers-color-scheme media query to detect the user's choice, the color-scheme property (and meta tag) to tell the browser which schemes the page supports so form controls, scrollbars and the canvas follow, and light-dark() or custom properties to swap palette values without duplicating rules.
-
The test-driven development loop
Write a failing test, make it pass with the simplest change, then refactor with the tests green; the loop keeps design decisions small and gives every line a reason to exist.
-
Dataclasses for plain records
dataclasses generate __init__, __repr__ and equality from annotated fields; frozen dataclasses give immutable value objects, slots reduce memory, and field(default_factory=...) avoids shared mutable defaults.
-
Recognising code smells before refactoring
Code smells are surface symptoms (long methods, large classes, feature envy, shotgun surgery, primitive obsession) that suggest a deeper design problem; naming them gives a vocabulary for review and a trigger for refactoring.
-
Designing exceptions in a Python library
Define one base exception per library, derive specific errors from it, raise with context, chain causes with 'raise ... from', and catch narrowly at the boundary where the failure can be handled.
-
Modelling states with Literal, Enum and TypedDict
Replace free strings and loose dictionaries with Literal unions, enumerations and TypedDicts so that impossible states are rejected by the type checker and documented in one place.
-
When should a team split a monolith into services?
Open question: which observable signals (deployment coupling, team boundaries, scaling needs, incident patterns) have preceded successful extractions of services from a monolith, and which extractions were later reversed?
-
Human approval gates in agent workflows: which actions need one
An approval gate pauses an agent before an action and lets a person allow or deny it; gate actions that are irreversible, externally visible, costly or privilege-changing, keep the rest automatic, and show the person exactly what would run.
-
Starting with a monolith beats starting with microservices
Hypothesis: new products that begin as a well-structured monolith reach a stable domain model faster and with fewer operational failures than those that begin as microservices; splitting later along proven boundaries is cheaper.
-
Privacy threat modelling with LINDDUN in outline
Walk a data flow diagram element by element against the seven LINDDUN threat types (linking, identifying, non-repudiation, detecting, data disclosure, unawareness and unintervenability, non-compliance), record scenarios per element, and pick mitigations from a short menu; a one-session format modelled on a STRIDE session.
기계 판독 가능: JSON