의존성 지옥의 재현: 코드에서 AI 행동(Behaviour)으로의 변화

소프트웨어 공학은 이미 한 차례 고통스러운 교훈을 얻었습니다. 의존성(Dependencies)이 관리되지 않으면 시스템은 스스로의 복잡성 아래에서 서서히 붕괴한다는 사실입니다. 버전 불일치, 숨겨진 업그레이드, 그리고 전이적 혼란(Transitive chaos)은 우리가 현재 '의존성 지옥(Dependency hell)'이라 부르는 현상을 초래했습니다. 우리는 패키지 매니저(Package managers), 락 파일(Lock files), 그리고 절제된 릴리스 사이클(Release cycles)을 통해 이 문제를 해결했습니다. 하지만 AI 시스템과 에이전트 기반 소프트웨어(Agentic software)의 시대에, 우리는 더 높은 계층에서 동일한 문제를 조용히 재구축하고 있습니다. 이번에는 우리 밑단에서 변하는 것이 코드가 아닙니다. 바로 행동(Behaviour)입니다. 도구(Tools), 기술(Skills), 프롬프트(Prompts), 그리고 모델(Models)은 시스템이 생각하고, 결정하고, 행동하는 방식을 미묘하게 변화시키는 방식으로 진화하고 있으며, 이는 종종 누구도 명시적으로 알아차리지 못한 채 일어납니다.

AI 행동은 구성된 시스템(Composed System)입니다. AI 행동은 기술(Skills)만으로 생성되지 않습니다. 그것은 기반이 되는 모델(Model), 프롬프트(Prompts), 그리고 시간이 흐름에 따라 행동을 조율하는 에이전트 계층(Agent layer) 사이의 상호작용에서 나타납니다. 프롬프트는 의도(Intent)에 대한 해석을 형성하고, 에이전트는 다단계 추론(Multi-step reasoning)과 도구 사용(Tool use)을 정의하며, 기술은 호출될 수 있는 외부 능력(External capabilities)을 제공합니다. 이들이 모여 행동이 단순히 생성되는 것을 넘어, 추론(Reasoning)과 행동(Action)의 결합을 통해 실행되는 단일 시스템을 형성합니다.

'기술(Skills)'의 실체: 이것이 왜 중요한지 이해하려면, 현대 AI 시스템에서 '기술(Skills)'이 실제로 무엇인지 정확히 정의할 필요가 있습니다. 본질적으로 기술은 마법 같은 확장 기능이 아닙니다. 그것은 정의된 입력(Inputs), 출력(Outputs), 그리고 부수 효과(Side effects)를 가진 구조화된 함수 호출(Function calls)입니다. 기술은 API 요청, 데이터베이스 쿼리(Database query), 또는 외부 서비스(External service)를 래핑(Wrap)할 수 있지만, 근본적으로는 에이전트에게 노출된 호출 가능한 능력입니다. 전통적인 소프트웨어와의 핵심적인 차이점은 구조가 아니라 사용 방식에 있습니다. 기존 시스템에서 함수는 개발자에 의해 명시적이고 결정론적(Deterministically)으로 호출됩니다. 에이전트 기반 시스템에서는 동일한 함수가 해석된 의도에 따라 모델에 의해 동적으로 선택, 호출 및 구성됩니다. 이는 기술을 수동적인 유틸리티에서 의사 결정의 능동적인 참여자로 전환시킵니다.

결과적으로, 기술 (skills)은 비공식적인 통합 요소가 아닙니다. 이는 엄격한 계약 (contracts), 버전 관리 (versioning), 하위 호환성 (backward compatibility) 및 테스트를 요구하는 프로덕션급 인터페이스 (production-grade interfaces)입니다. 기술의 스키마 (schema)나 행동 (behaviour)이 변경되는 것은 분산 시스템 (distributed system)에서 함수 시그니처 (function signature)를 변경하는 것과 동일합니다. 다만, 실패가 즉각적이지 않고 종종 소리 없이 발생하며 의미론적 (semantic)이라는 점이 다를 뿐입니다.

통합 및 시스템적 리스크 (Integration and Systemic Risk)
기술은 좀처럼 고립되어 작동하지 않습니다. 에이전트 (agents)는 단일 워크플로 (workflow) 내에서 여러 도구를 조합하며, 이로 인해 통합 경계 (integration boundaries)가 매우 중요해집니다. 하나의 기술에서 발생한 변화는 시스템 전체로 연쇄적으로 영향을 미쳐, 하위 단계의 행동 (downstream behaviour)을 예상치 못한 방식으로 변경할 수 있습니다. 이것이 바로 버전 관리된 기술들 간의 통합 테스트 (integration testing)가 필수적인 이유입니다. 단순히 각 기술을 독립적으로 검증하는 것에 그치지 않고, 다음과 같이 조합된 시스템을 검증해야 합니다: 기술 A v1.2 + 기술 B v2.0 + 모델 X가 여전히 안정적인 결과를 생성하는지 확인하는 것입니다. 이것이 없다면, 리스크는 단순히 기능의 고장에 그치지 않고 추론 체인 (reasoning chains)의 붕괴로 이어집니다.

MCP와 기술 계층 (MCP and the Skill Layer)
우리는 이미 MCP (Model Context Protocol)와 같은 시스템에서 이러한 변화를 목격하고 있습니다. MCP에서는 도구와 데이터 소스가 표준화된 인터페이스를 통해 모델에 노출됩니다. MCP는 기술을 발견 가능하고 호출 가능한 서비스 (discoverable, callable services)로 효과적으로 공식화하며, 이는 프롬프트 (prompts)나 비공식적인 플러그인 (plugins)보다 분산 시스템의 API에 더 가깝습니다. 이는 핵심적인 아키텍처적 현실을 강화합니다: 일단 역량 (capabilities)이 에이전트에게 노출되면, 그것들은 동적인 실행 그래프 (dynamic execution graph)의 일부가 되며, 버전 관리되고 테스트 가능하며 조합 가능한 단위 (composable units)로 취급되어야 합니다.

설치 가능하고 재사용 가능한 분산 기술 (Installable, Reusable, Distributed Skills)
기술은 자연스럽게 설치 가능하고, 재사용 가능하며, 조합 가능한 구성 요소로 진화합니다. 외부로 노출되면 전통적인 소프트웨어 생태계의 패키지 (packages)처럼 배포되고, 레지스트리 (registries)에서 설치되며, 여러 에이전트 시스템 전반에서 재사용될 수 있습니다. 전통적인 라이브러리 (libraries)와 달리, 기술은 종종 평이한 영어 의도 (plain English intent)를 통해 트리거되며, 여기서 에이전트는 요청을 해석하고 적절한 역량을 선택합니다. 하지만 그 출력값은 자유 형식이 아닙니다.

이 결과물들은 추가적인 조합 (composition)을 위해 설계된 구조화된 결과물입니다. 즉, 하나의 기술 (skill)이 다른 기술로 이어지며 동적인 다단계 워크플로 (multi-step workflows)를 가능하게 합니다. 이를 통해 기술은 런타임 조합 (runtime composition)을 위한 빌딩 블록 (building blocks)이 됩니다. 시스템은 더 이상 미리 연결된 파이프라인 (pre-wired pipelines)이 아니라, 실행 시점에 조립되는 재사용 가능한 역량들의 그래프 (graphs of reusable capabilities)가 됩니다. 이러한 조합성 (composability)은 강력한 힘을 부여하지만, 동시에 위험도 증가시킵니다. 엄격한 버전 관리 (versioning)와 통합 테스트 (integration testing) 없이는 작은 변화가 추론 체인 (reasoning chains) 전반에 걸쳐 예측하기 어려운 방식으로 전파될 수 있습니다.

단순 채팅 (Just Chat) vs 실제로 실행되는 시스템 (Systems That Actually Execute): 기본적인 채팅 시스템에서 모델은 상태가 없고 (stateless) 범용적입니다. 모델은 내부 지식을 사용하여 응답하며, 신뢰할 수 있는 외부 실행 계층이나 작업이 수행되는 방식에 대한 보장이 없습니다. 반면, 기술 기반 시스템 (skill-enabled system)은 버전 관리된 역량들을 오케스트레이션 (orchestrates)합니다. 자연어로 된 사용자 요청은 엄격한 계약 (contracts), 예측 가능한 부작용 (side effects), 그리고 조합 가능한 출력값을 가진 특정 도구들을 트리거할 수 있습니다. 시스템은 하이브리드 형태가 됩니다: 의도 (intent)를 위한 자연어 → 기술을 통한 구조화된 실행 (structured execution). 이것이 기술이 단순한 기능 향상이 아닌, 시스템이 신뢰성 있게 수행할 수 있는 능력의 본질을 근본적으로 바꾸는 이유입니다.

비용 및 규모의 영향 (Cost and Scale Implications): 언뜻 보기에 기술, 버전 관리, 그리고 조합 가능한 도구 시스템은 오버헤드 (overhead)처럼 보입니다. 인터페이스 설계, 하위 호환성 (backward compatibility), 통합 테스트, 그리고 레지스트리 관리와 같은 실제적인 복잡성을 초래하기 때문입니다. 하지만 프로덕션 시스템 (production systems)에서 실제 비용은 인프라가 아니라, 규모가 커짐에 따라 발생하는 예측 불가능성입니다. 관리되지 않는 도구 사용은 다음과 같은 결과를 초래합니다:

• 비효율적인 라우팅 (inefficient routing)
• 반복적인 모델 호출 (repeated model calls)
• 무음 실패 (silent failures)
• 비용이 많이 드는 디버깅 사이클 (expensive debugging cycles)

시스템이 성장함에 따라 비용은 선형적으로 증가하는 것이 아니라, 축적된 불확실성을 통해 증가합니다. 잘 설계된 기술 시스템은 이러한 역학 관계를 변화시킵니다. 기술 시스템은 결정론적인 작업 (deterministic work)을 모델 외부로 분리하고, 중복된 추론을 줄이며, 더 저렴한 실행 경로를 가능하게 합니다. 더 중요한 것은, 모호함으로 인해 발생하는 숨겨진 운영 비용을 줄여준다는 점입니다.

기술 (Skills)과 버전 관리 (Versioning)는 단순한 비용 최적화가 아니라, 복잡성 증가를 제어하기 위한 메커니즘입니다. 이것들이 없다면 비용은 사용량에 따라 늘어나는 것이 아니라, 엔트로피 (Entropy)에 따라 늘어납니다.

결론적 통찰 (Closing Insight): 변화의 핵심은 단순히 AI 시스템에 도구를 추가하는 것이 아닙니다. 우리가 역량 (Capabilities)을 추론 (Reasoning)을 직접적으로 형성하는 소프트웨어 산출물 (Software artifacts)로 변환하고 있다는 점입니다. 일단 그렇게 되면, 모든 변화는 의미를 갖게 됩니다. 버전 업데이트 (Version bump)는 더 이상 단순한 코드 업데이트가 아닙니다. 그것은 행동 (Behaviour), 의사결정, 그리고 시스템 전반의 결과에 미칠 수 있는 잠재적인 변화입니다. 이것이 바로 소프트웨어 엔지니어링의 다음 진화가 단순히 더 나은 함수 (Functions)를 작성하는 것에 그치지 않는 이유입니다. 그것은 언어로 사고하지만 코드로 실행되는 시스템의 행동 표면적 (Behavioural surface area)을 제어하는 것에 관한 것입니다.