독서 노트 · Every
Compound Engineering: AI 중심 소프트웨어 철학
AI와 함께하는 작업을 지식, 프로세스, 시스템 개선으로 축적하여 다음 작업을 더 쉽게 만드는 방법에 관한 독서 노트.
Every가 설명하는 Compound Engineering은 소프트웨어 개발을 축적되는 시스템으로 바라봅니다. 계획, 구현, 검토, 학습의 매 과정이 다음 작업을 더 빠르고 명확하며 신뢰할 수 있게 만들어야 합니다.
nanoHome이 얻을 수 있는 실무적 교훈은 기능 출시에서 멈추지 않는 것입니다. 다음 변경을 쉽게 만드는 패턴, 테스트, 문서, 체크리스트를 남겨야 합니다.
What changes
Keep the showroom in the buying path.
- 01
For customers
A product page gives the next useful step: buy, request a quote, book a visit, or talk to the showroom.
- 02
For the showroom team
Staff can see product changes, missing prices, quote requests, and items that need approval before they go live.
- 03
For the build team
Engineers can release small pieces, watch failures, and roll back without disturbing the showroom floor.
철학
모든 작업이 시스템을 개선해야 합니다
The core idea of Compound Engineering is that work should not merely add a feature while leaving behind more complexity. A good bug fix should remove an entire class of similar bugs. A good pattern should become reusable guidance or a helper. A good review should produce a checklist that catches the same issue earlier next time.
For nanoHome, that means new content, routes, schemas, or workflows should feed learning back into the repository as clearer content models, focused tests, AGENTS.md conventions, or specs documentation.
- 01Document technical decisions instead of leaving them in one person's memory.
- 02Turn repeated failures into tests, validation, or checklists.
- 03Prefer reusable patterns across content, UI, and routing.
작업 흐름
계획, 실행, 검토, 축적
Every frames the work as a four-step loop: plan, work, review, then compound. The first three steps produce the feature; the last step produces a system that builds the next feature better.
The part worth keeping in this project is the rhythm: research the requirement and codebase before editing, implement in small verified steps, review by priority, then update documentation or conventions when there is reusable learning.
- 01Plan: understand the requirement, inspect the codebase, check framework docs, and design the change.
- 02Work: implement in small steps, run validation, and adapt when something breaks.
- 03Review: look for behavioral bugs, regressions, missing tests, and impact-ranked fixes.
- 04Compound: capture patterns, checklists, or guardrails so future work does not relearn the same lesson.
스토어프런트 적용
미적 판단은 검토뿐 아니라 시스템에도 담겨야 합니다
A strong point in Every's guide is that engineering taste should be encoded into the system: schemas, helpers, tests, documentation, commands, and agent instructions. Once the system understands how the team wants to build, review becomes less oral tradition and more quality confirmation.
For the nanoHome project, this is especially useful in repeatable areas such as news articles, product data, bilingual marketing pages, metadata, route contracts, and e2e flows. Each content addition should make the content structure easier to reuse.
- 01Put durable conventions into schemas or helpers instead of copying logic across routes.
- 02When bilingual content issues appear, add matching validation or tests.
- 03When a UI pattern repeats, promote it into a shared component.
참고 자료
원문 가이드 읽기
Every's original guide goes deeper into workflow, plugins, commands, review agents, and the beliefs engineers may need to change when building software with AI. This entry summarizes the main ideas and translates them into notes that fit the nanoHome repository.