단순함의 철학

복잡함보다
단순함이 먼저다

병렬 에이전트, 멀티홉 워크플로우, 복잡한 오케스트레이션 — 이것들은 단순한 방법이 부족할 때 필요해. 그 전에 단순함을 먼저 시도해야 해.

01 · 복잡함에 대한 유혹

왜 우리는 과도하게 설계하는가

핵심 명제

복잡한 시스템이 더 강력해 보여. 하지만 잘못 설계된 복잡한 시스템은 잘 설계된 단순한 시스템보다 못해.

복잡함으로 가는 이유
— 복잡할수록 강력해 보임
— 기술적으로 흥미롭게 느껴짐
— 미래 요구사항에 대비하는 것 같음
— 더 전문적으로 보임
단순함이 먼저인 이유
+ 이해하기 쉬워
+ 디버깅하기 쉬워
+ 유지보수하기 쉬워
+ 믿고 맡길 수 있어

02 · 단순함의 계층

먼저 Tier 1,
그 다음 Tier 2

TIER 1 단일 에이전트 먼저 시도할 것
하나의 잘 설계된 에이전트
시스템 프롬프트, 맥락, 툴 조합으로 대부분의 작업을 처리할 수 있어. Tier 1이 충분하지 않다는 걸 증명하기 전에 Tier 2로 가지 마.
언제: 항상 여기서 시작해. 이게 충분하면 끝이야.
TIER 2 서브에이전트 필요 시 추가
독립된 전문 에이전트
단일 에이전트로 감당 안 되는 병렬 처리나 도메인 분리가 필요할 때 추가해. 한 번에 하나씩.
언제: Tier 1이 부족하다는 게 명확할 때.
TIER 3 병렬/복합 시스템 증명 후 사용
멀티 오케스트레이션
Tier 2도 부족할 때만. 복잡성의 이점이 관리 비용을 명확하게 초과할 때만 고려해.
언제: Tier 2로도 불가능하다는 게 증명됐을 때.

03 · 단순함의 기준

복잡성을 추가하기 전
이 질문을 해봐

질문 01 이게 정말
필요한가?

지금 당장 이 복잡성이 없으면 불가능한 것이 있는가? 없다면 추가하지 마.

"서브에이전트 필요해?" → "지금 단일로 안 되는 게 뭔데?"
질문 02 단순한 방법을
먼저 시도했나?

단순한 방법을 충분히 시도하기 전에 복잡한 방법으로 가는 건 조급함이야.

단일 에이전트 최적화 → 그래도 부족하면 그때 확장
질문 03 복잡성의 이점이
비용을 초과하는가?

복잡한 시스템은 설계, 디버깅, 유지보수 비용이 높아. 그 비용을 정당화하는 이점이 명확해야 해.

이점이 명확하고 증명 가능할 때만 복잡성을 추가해
질문 04 한 번에
하나씩 추가하나?

한 번에 여러 단계를 건너뛰면 어디서 문제가 생겼는지 알 수 없어. 한 번에 하나씩.

Tier 1 → 검증 → Tier 2 → 검증 → Tier 3

핵심 통찰

가장 단순한 방법이
먼저다

단순함은 부족함이 아니야. 목적에 맞는 최소 구조가 단순함이야. 복잡성은 단순함이 부족하다는 게 증명됐을 때 추가하는 거야.