소프트웨어 3.0 시대를 맞이하며

Context

LLM의 등장으로 소프트웨어 개발 패러다임이 변화하고 있지만, 현실의 LLM은 파일 접근, API 호출, 데이터베이스 접근 같은 외부 시스템과 상호작용할 수 없다. 이로 인해 LLM의 강력함을 실제 업무에 활용하기 위한 도구와 환경(Harness)이 필수적이다.

Technical Solution

• Slash Command를 Controller 계층으로 매핑: 사용자 요청(/review, /refactor 등)이 진입점이 되어 적절한 워크플로우를 트리거
• Sub-agent를 Service 계층으로 구성: 여러 Skill을 조합하여 워크플로우를 완성하며, 각 Sub-agent는 별도 Context를 가져 독립적으로 동작
• Skills를 도메인 컴포넌트로 설계: 단일 책임 원칙(SRP)을 따르며 "코드 리뷰", "테스트 생성", "문서 작성" 같은 하나의 명확한 역할만 담당
• MCP(Model Context Protocol)를 Infrastructure/Adapter 계층으로 활용: 파일 시스템, API, 데이터베이스 같은 외부 시스템 접근을 추상화하여 내부 로직이 외부 구현에 의존하지 않도록 분리
• CLAUDE.md를 설정 파일(package.json/pom.xml)로 취급: 기술 스택, 코딩 컨벤션, 빌드 명령어 같은 변하지 않는 원칙을 정의하되, 동적 정보는 대화나 Sub-agent Context로 전달
• Context Window를 메모리로 관리: 토큰 사용량을 메모리 점유율처럼 모니터링하며, CLAUDE.md 내용을 좁혀서 불필요한 토큰 소비 방지
• Human-in-the-Loop(HITL)으로 질문 메커니즘 도입: 되돌리기 어려운 작업(삭제, 배포), 정답이 없는 다중 선택, 높은 비용/리스크 결정 시에만 사용자 판단을 요청
• Facade 패턴으로 지침 계층화: SKILL.md가 Facade 역할을 하고, references/ 파일들은 Claude가 필요하다고 판단할 때만 Context에 로드

Impact

아티클에는 정량적 성능 수치가 제시되지 않음

Key Takeaway

Software 3.0 시대의 에이전트 설계는 레이어드 아키텍처, 단일 책임 원칙, 추상화 같은 기존 소프트웨어 엔지니어링 원칙을 그대로 따른다. MCP를 설계할 때 Adapter Pattern을, Skill을 만들 때 SRP를, Sub-agent를 구성할 때 Service Layer를 떠올리면, 기존의 아키텍처 지식이 곧 최고의 에이전트를 만드는 기반이 된다.