소프트웨어 3.0 시대로의 전환과 Harness의 역할

소프트웨어 패러다임의 진화

• Software 1.0: 수십 년간 명시적인 로직을 코드로 작성하는 방식 (How).
• Software 2.0: 2010년대 딥러닝 부상과 함께 등장, 신경망 가중치가 프로그램이 되는 방식 (What).
• Software 3.0: LLM에게 자연어로 요구사항을 전달하면 되는 시대, 프롬프트가 곧 프로그램이 되는 방식 (What).
• Karpathy는 "Software 3.0 is eating 1.0/2.0"이라 언급하며 새로운 패러다임의 도래를 강조합니다.

Harness: LLM의 한계를 보완하는 도구

• LLM은 강력하지만 파일 접근, API 호출 등 외부 시스템 연동이 불가능합니다.
• Harness는 말의 힘을 제어하고 활용하게 해주는 마구처럼, LLM의 한계를 보완하고 실제 업무에 연결해주는 도구와 환경을 의미합니다.
• Harness는 LLM의 Context window 제한, Memory 관리, 환각(Hallucination), 외부 시스템 접근 불가 등의 문제를 해결합니다.

Claude Code와 소프트웨어 1.0 아키텍처의 유사성

• Claude Code는 LLM을 위한 Harness 역할을 하며, MCP, Skills, Sub-agent, Slash Command 등의 구성 요소를 가집니다.
• 이 구조는 놀랍도록 레이어드 아키텍처와 유사합니다.
  • Slash Command: Controller (사용자 요청 진입점)
  • Sub-agent: Service Layer (여러 Skill 조합 및 워크플로우 관리)
  • Skills: Domain Component (SRP 준수, 단일 책임)
  • MCP: Infrastructure / Adapter (외부 시스템 연동 추상화)
  • CLAUDE.md: package.json (프로젝트 설정 및 원칙 정의)

에이전트 설계의 안티패턴

• 전통적인 레이어드 아키텍처의 안티패턴(God Class, Spaghetti Code, Tight Coupling 등)이 에이전트 설계에도 그대로 적용됩니다.
• 코드 스멜(Feature Envy, Duplication, Long Method 등) 역시 유사하게 나타납니다.

Software 3.0의 핵심: 질문하는 에이전트

• 전통 아키텍처는 모든 분기를 미리 정의해야 하지만, 에이전트는 **Human-in-the-Loop(HITL)**을 통해 실행 중간에 판단을 위임할 수 있습니다.
• Exception이 Question으로 전환되며, 애매한 상황에서 사용자에게 질문하여 의사결정을 요청할 수 있습니다.
• 언제 질문하고 언제 알아서 할지에 대한 판단 기준이 중요합니다 (e.g., 되돌리기 어려운 작업, 비용/리스크 큰 결정 시 질문).

1.0 개발자가 3.0으로 가는 길

• 버릴 것: 명시적 로직 작성 강박, 모든 예외 상황 정의 시도, LLM을 단순 자동완성으로 보는 시각.
• 가져갈 것: 레이어 분리, SRP, 추상화, 의존성 관리, 테스트 가능성, 디버깅 전략, 코드 리뷰 등 좋은 설계 원칙.
• 아키텍처 지식은 최고의 에이전트 구축 기반이 됩니다.

한계점 및 실전 팁

• 토큰은 메모리: Context Window 제한 고려, 토큰 사용량 최적화 필요.
• Skill 분리 딜레마: 클래스 폭발과 유사하게 Skill 과다 시 인지 부하 발생 가능. Facade 패턴을 활용하여 Skill.md는 진입점만 제공하고 세부 지식은 references/에 위임.
• Setup & Config 패턴: Slash Command와 HITL을 활용하여 환경 감지 및 불확실한 부분에 대한 사용자 질문으로 설정 과정 자동화.