소프트웨어 3.0 시대는 자연어 프롬프트가 프로그램이 되는 시대이지만, LLM이 실질적인 업무를 수행하기 위해서는 이를 제어하고 연결하는 '하네스(Harness)'가 필수적입니다. Claude Code와 같은 최신 에이전트 도구들은 이러한 하네스의 역할을 하며, 그 내부 구조는 놀랍게도 우리가 익히 알고 있는 소프트웨어 1.0의 레이어드 아키텍처 원칙을 그대로 따르고 있습니다. 결국 좋은 에이전트를 설계하는 힘은 기존의 객체 지향 설계와 추상화 원칙을 얼마나 잘 적용하느냐에 달려 있습니다.

소프트웨어 1.0의 눈으로 본 에이전트 구조

Slash Command (Controller): /review, /refactor와 같은 명령어는 사용자 요청의 진입점 역할을 하며, 특정 워크플로우를 트리거하는 컨트롤러와 유사합니다.
Sub-agent (Service Layer): 여러 기술(Skill)을 조합하여 복잡한 비즈니스 로직을 완성하며, 독립된 컨텍스트를 가져 서비스 계층이나 별도의 스레드처럼 동작합니다.
Skills (Domain Component): 단일 책임 원칙(SRP)에 따라 "코드 리뷰", "테스트 생성" 등 명확한 한 가지 역할만 수행하는 기능 단위입니다.
MCP (Infrastructure/Adapter): 외부 API나 데이터베이스와의 연결을 담당하며, 내부 로직이 외부 환경에 의존하지 않도록 추상화된 어댑터 역할을 합니다.
CLAUDE.md (Configuration): 프로젝트의 기술 스택과 코딩 컨벤션을 담는 파일로, package.json이나 pom.xml처럼 프로젝트의 고정된 원칙을 정의합니다.

에이전트 설계의 핵심: 질문과 판단의 위임

Exception에서 Question으로: 전통적인 코드에서는 모든 예외를 미리 정의해야 하지만, 에이전트는 불확실한 상황에서 사용자에게 질문(HITL)을 던져 판단을 위임할 수 있습니다.
질문의 기준: 삭제나 배포처럼 되돌리기 어려운 작업이나 리스크가 큰 결정은 사용자에게 묻고, 안전하게 반복 가능한 작업은 에이전트가 스스로 처리하도록 설계해야 합니다.
안티패턴의 답습: 에이전트 설계에서도 특정 객체가 너무 많은 일을 하는 'God Agent'나 불필요하게 복잡한 호출 구조는 유지보수성을 떨어뜨리는 코드 스멜이 됩니다.

토큰 최적화와 효율적인 설계 전략

토큰은 곧 메모리: 컨텍스트 윈도우(Context Window)를 작업 메모리로 인식해야 하며, 무분별한 파일 읽기나 복잡한 지침은 토큰 폭발(OOM과 유사)을 야기합니다.
결정적 로직의 분리: 브랜치 명명 규칙과 같이 판단이 필요 없는 단순 반복 작업은 프롬프트가 아닌 별도의 스크립트로 작성하여 실행하게 함으로써 토큰 소모를 줄여야 합니다.
점진적 노출(Progressive Disclosure): 수많은 Skill이 시스템 프롬프트를 점유하지 않도록, 진입점만 제공하고 세부 지식은 필요할 때 참조하게 만드는 '디미터의 법칙'을 적용해야 합니다.

소프트웨어 3.0 시대에도 개발자가 쌓아온 레이어 분리, 추상화, 인터페이스 설계 역량은 여전히 유효합니다. 도구는 LLM으로 바뀌었지만 응집도와 결합도를 고려한 좋은 설계 원칙을 유지할 때, 비로소 실무에서 신뢰할 수 있는 강력한 에이전트를 구축할 수 있습니다.