software-3.0

Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기 (새 탭에서 열림)

현재 많은 개발팀이 LLM을 도입하고 있지만, 실제 생산성은 엔지니어 개개인의 'LLM 리터러시'에 따라 극심한 격차를 보이고 있습니다. 이러한 '각자도생'의 한계를 극복하기 위해서는 LLM을 개인의 도구가 아닌 팀 차원의 시스템으로 편입시켜 전체적인 생산성의 저점(Floor)을 높이는 전략이 필요합니다. Claude Code와 같은 생태계를 활용해 팀의 노하우를 '실행 가능한 지식(Executable SSOT)'으로 자산화하는 것이 Software 3.0 시대의 핵심 경쟁력이 될 것입니다. **컨텍스트 엔지니어링과 LLM 리터러시의 격차** * 단순 질문을 반복하는 방식과 작업 전 팀의 가이드라인, 린트 규칙, 코드 패턴 등 '컨텍스트'를 먼저 주입하는 방식은 결과물에서 큰 차이를 만듭니다. * 이러한 생산성 격차는 코딩 실력이 아닌 LLM을 제어하는 노하우의 차이이며, 이를 개인의 센스에만 맡기는 것은 조직적 손실입니다. * 팀 전체의 역량을 상향 평준화하기 위해서는 누구나 최적의 맥락 위에서 작업할 수 있도록 돕는 시스템적 장치(Harness)가 필요합니다. **Claude Code와 마찰 없는 워크플로우 이식** * 브라우저 기반 챗봇으로 코드를 복사·붙여넣기 하는 과정에서 발생하는 문맥 교환(Context Switching) 비용을 최소화해야 합니다. * Claude Code가 제공하는 TUI(Terminal User Interface) 환경은 터미널 안에서 자연어와 코드가 끊김 없이 섞이는 매끄러운 경험을 제공합니다. * 이러한 낮은 진입 장벽은 설계된 AI 워크플로우를 팀원들에게 저항감 없이 전파할 수 있는 기반이 됩니다. **실행 가능한 진실의 원천(Executable SSOT)** * 기존의 위키나 노션 문서는 작성 즉시 낡은 정보가 되지만, 플러그인 형태의 지식은 사람이 읽는 매뉴얼인 동시에 LLM이 즉시 실행하는 시스템 프롬프트가 됩니다. * RAG(검색 증강 생성) 방식은 내부 로직의 불투명성으로 인해 어떤 컨텍스트가 주입될지 예측하기 어렵다는 단점이 있습니다. * 반면 플러그인 방식은 명시적인 코드로서 개발자가 주입되는 맥락을 100% 통제할 수 있어 높은 예측 가능성과 신뢰성을 제공합니다. **계층화된 아키텍처를 통한 거버넌스와 전파** * 지식을 전사 공통(Global), 팀/비즈니스 도메인(Domain), 특정 프로젝트(Local)의 3단계 레이어로 계층화하여 관리함으로써 지식의 파편화를 방지합니다. * `/new-feature`와 같은 슬래시 커맨드를 통해 숙련된 엔지니어의 노하우(이슈 발급, 브랜치 생성, 구현 계획 수립 등)를 모든 팀원에게 즉시 배포할 수 있습니다. * 단순한 린터를 넘어, 메인 브랜치 커밋 시도를 감지하고 정책에 맞는 브랜치 생성을 가이드하는 등 AI 에이전트 기반의 강력한 거버넌스 구현이 가능합니다. **엔지니어링의 본질: 플랫폼 엔지니어링과 데이터 플라이휠** * Software 1.0 시대에 공통 라이브러리로 중복 작업을 줄였듯, Software 3.0에서는 AI 워크플로우 플러그인을 통해 팀의 생산성을 최적화해야 합니다. * 규격화된 플러그인을 통해 축적된 양질의 데이터는 향후 도메인 특화 모델(sLLM)을 파인튜닝하고 평가하는 기반이 됩니다. * 사용자가 많아질수록 데이터가 쌓이고 모델이 정교해지는 '데이터 플라이휠' 구조를 구축하는 것이 AI-Native 조직의 최종 목표입니다. 이제 LLM 활용 능력은 개인의 역량을 넘어 팀이 설계하고 배포해야 할 시스템의 영역입니다. Claude Code의 마켓플레이스와 같은 도구를 활용해 팀 내에 흩어진 암묵지를 명시적인 워크플로우로 엮어내고, 우리 조직에 최적화된 '시스템 하네스'를 구축하는 것부터 시작해 보기를 추천합니다.

소프트웨어 3.0 시대를 맞이하며 (새 탭에서 열림)

소프트웨어 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으로 바뀌었지만 응집도와 결합도를 고려한 좋은 설계 원칙을 유지할 때, 비로소 실무에서 신뢰할 수 있는 강력한 에이전트를 구축할 수 있습니다.