당신의 아키텍처가 죽은 것은 아닐 수도 있지만, AI가 새로운 오케스트레이터 (Orchestrator)를 도입했다는 점을 기억하세요

요약 (TL;DR): AI는 MVVM이나 그와 호환되는 무엇인가를 대체하지 않습니다.
AI는 새로운 오케스트레이션 (Orchestration) 레이어를 도입합니다. ViewModel은 여전히 UI 상태를 관리하는 데 탁월하지만, 앱이 추론하고, 계획하고, 도구를 사용하며, 문맥 (Context)을 유지해야 할 때 **에이전트 (Agent)**가 아키텍처의 자연스러운 추가 요소가 됩니다.

우리가 예상치 못했던 변화

지난 10년 이상 모바일 아키텍처는 UI 코드를 예측 가능하고 유지보수 가능하게 만드는 데 집중해 왔습니다. MVC, MVP, VIPER, Clean Architecture, MVVM 또는 The Composable Architecture를 따르든, 핵심 아이디어는 동일하게 유지되었습니다:

• 관심사 분리 (Separate concerns).
• 뷰 (View)에서 비즈니스 로직을 분리할 것.
• 데이터 흐름을 예측 가능하게 만들 것.
• UI를 반응형 (Reactive)으로 유지할 것.

전형적인 현대적 iOS 애플리케이션은 다음과 같은 모습입니다:

SwiftUI View
      │
      ▼
...

ViewModel은 사용자의 의도를 전달받습니다. Repository는 데이터를 가져옵니다. View는 업데이트됩니다. 모든 것은 결정론적 (Deterministic)이며, 버튼 탭은 미리 정의된 실행 경로를 따릅니다.

이 아키텍처는 우리에게 매우 훌륭하게 작동해 왔습니다. 하지만 AI 기반의 경험은 근본적으로 다릅니다.

전통적인 앱은 실행한다

전통적인 애플리케이션은 명령을 실행합니다. 예를 들어, 사용자가 다음과 같이 탭합니다:

"Blue Jacket" 검색

흐름은 간단합니다:

View → ViewModel → Repository → Search API → Products

모든 컴포넌트는 정확히 무엇을 해야 하는지 알고 있습니다. 모호함이 거의 없습니다.

AI 애플리케이션은 행동하기 전에 생각해야 한다

이제 현대적인 쇼핑 경험을 생각해 봅시다. 사용자는 키워드를 입력하는 대신 다음과 같이 말합니다.

"다음 주 스코틀랜드 비 오는 여행에 적합한, 5,000루피 미만의 파란색 방수 재킷을 찾아줘."

흥미로운 점을 발견하셨나요? 앱은 즉시 API를 호출할 수 없습니다. 먼저 사용자가 실제로 무엇을 의미하는지 이해해야 합니다. 앱은 다음 사항들을 추론해야 합니다.

• 방수 (Waterproof)
• 추운 날씨에 적합함
• 예산 제한
• 목적지
• 여행 날짜
• 제품 가용성
• 순위 선호도

어떤 API가 호출되기 전에, 이미 추론 (Reasoning)이 시작된 것입니다.

하나의 요청이 여러 개의 작업이 될 수 있다

내부적으로, 그 단 한 문장은 다음과 같이 변할 수 있습니다.

의도 파악 (Understand intent)
      ↓
문제를 작업으로 분해 (Break problem into tasks)
...

이것은 전통적인 뷰모델 (ViewModel)이 오케스트레이션 (Orchestrate)하도록 설계된 것이 아닙니다.

뷰모델의 책임은 변하지 않았다

많은 개발자가 즉시 이렇게 질문합니다.

"에이전트 (Agent)는 그냥 또 다른 뷰모델 아닌가요?"

타당한 질문입니다. 대답은 꼭 그렇지는 않다입니다.

뷰모델의 주요 책임은 여전히 다음과 같습니다.

• 화면 상태 관리 (Manage screen state)
• 모델을 UI로 변환 (Transform models into UI)
• 사용자 상호작용 처리 (Handle user interactions)
• 프레젠테이션 로직 조정 (Coordinate presentation logic)

이러한 책임은 AI 기반 애플리케이션에서도 정확히 동일하게 유지됩니다. 변하는 것은 추론을 누가 조정하느냐입니다.

에이전트의 등장

에이전트를 오케스트레이션 계층 (Orchestration layer)이라고 생각하십시오. 에이전트는 단순히 요청을 전달하는 대신, 요청이 어떻게 해결되어야 하는지를 결정합니다.

사용자 요청 (User Request)
      ↓
   에이전트 (Agent)
...

에이전트는 여러분의 네트워킹 계층 (Networking layer)을 대체하는 것이 아닙니다. 리포지토리 (Repositories)를 대체하는 것도 아닙니다. MVVM을 대체하는 것도 아닙니다. 에이전트는 그것들을 조정하는 것입니다.

더 나은 멘탈 모델 (Mental Model)

다음과 같이 생각하는 대신:

ViewModel → Repository

이렇게 생각하십시오:

View → ViewModel → Agent → Tools → Repositories → Backend → LLM

ViewModel은 여전히 UI 상태를 소유합니다. Agent가 지능을 소유합니다.

Agent는 정확히 무엇을 하나요?

1. 의도 이해 (Understand Intent)

사용자의 말은 명시적이지 않은 경우가 드뭅니다. 예:

"사무실 회의에 적합한 편안한 것."

Agent는 모호한 언어를 구조화된 요구사항으로 변환합니다.

2. 계획 수립 (Planning)

복잡한 요청은 여러 개의 작은 작업으로 분해됩니다. 다음과 같은 대신:

Call API

다음과 같이 됩니다:

Search products → Compare options → Remove unavailable items → Rank → Summarize

3. 도구 호출 (Tool Calling)

최신 LLM은 모든 작업을 스스로 수행하는 것이 아니라, 도구를 호출합니다. 예시:

• 제품 검색 (Product Search)
• 날씨 API (Weather API)
• 캘린더 (Calendar)
• 지도 (Maps)
• 결제 (Payment)
• 데이터베이스 (Database)
• 재고 서비스 (Inventory Service)
• 추천 엔진 (Recommendation Engine)

Agent는 어떤 도구를 실행해야 하며, 어떤 순서로 실행할지 결정합니다.

4. 메모리 (Memory)

전통적인 앱은 UI 상태를 기억합니다. Agent는 대화를 기억합니다. 예시:

"다른 것 하나 보여줘."

무엇이 다른 것? Agent는 이전 컨텍스트를 기억하기 때문에 알고 있습니다.

5. 추론 (Reasoning)

원시 API 결과만 반환하는 대신:

Product A
Product B
Product C

다음과 같이 생성할 수 있습니다:

"Product B가 약간 더 비싸지만, 훨씬 나은 방수 기능을 제공하여 다가오는 스코틀랜드 여행에 더 적합합니다."

이것이 추론입니다.

책임 비교 (Comparing Responsibilities)

에이전트(Agent)는 어디에 위치해야 하는가?

이것은 아마도 가장 흥미로운 아키텍처 논의일 것입니다. 가능한 설계 중 하나는 다음과 같습니다:

SwiftUI View
      ↓
  ViewModel
...

이렇게 하면 관심사 (Concerns)가 잘 분리됩니다. ViewModel이 갑자기 프롬프트 (Prompts), 메모리 (Memory), 또는 도구 실행 (Tool execution)을 책임지게 되지는 않습니다.

클린 아키텍처 (Clean Architecture)는 어떤가?

만약 클린 아키텍처 (Clean Architecture)를 사용하고 있다면, 에이전트 (Agent)는 자연스럽게 도메인 계층 (Domain layer)에 속하게 됩니다. 이를 또 다른 도메인 서비스 (Domain service)라고 생각하면 됩니다. ViewModel은 단순히 복잡한 AI 작업을 위임합니다:

ViewModel → AgentService → Repositories → Tools → LLM

리포지토리 (Repositories)는 계속해서 데이터 액세스 (Data access)를 담당합니다. 에이전트 (Agent)는 오케스트레이션 (Orchestration)을 담당합니다.

이것이 중요한 이유

AI 기능이 점점 더 흔해짐에 따라, 우리는 단순한 요청-응답 (Request-response) 상호작용을 넘어 이동하고 있습니다. 애플리케이션은 다음과 같은 작업을 시작하고 있습니다:

• 사고하기 (Think)
• 계획하기 (Plan)
• 추론하기 (Reason)
• 기억하기 (Remember)
• 결정하기 (Decide)
• 설명하기 (Explain)

이는 전통적인 UI 아키텍처가 처리하도록 의도되지 않았던 책임들을 도입합니다. 이 모든 것을 ViewModel에 밀어 넣으려고 하면 결국 책임이 뒤섞인 거대한 클래스로 이어지게 됩니다. 에이전트 (Agent) 계층을 추가하면 각 컴포넌트가 자신이 가장 잘하는 일에 집중할 수 있게 유지됩니다.

실질적인 예시

AI 기반의 여행 어시스턴트를 구축한다고 상상해 보세요. 사용자가 다음과 같이 질문합니다:

"채식 식당이 좋고 날씨가 쾌적하며, 6,000루피 미만의 호텔이 있는 쿠르그(Coorg)로의 주말 여행을 계획해 줘."

에이전트 (Agent)는 다음과 같은 작업을 수행할 수 있습니다:

1. 목적지를 이해함.
2. 일기 예보를 가져옴.
3. 호텔을 검색함.
4. 식당을 검색함.
5. 옵션의 순위를 매김.
6. 예약 불가능한 호텔을 제거함.
7. 여행 일정을 생성함.
8. 각 추천 사항이 선택된 이유를 설명함.

여러분의 ViewModel은 이 8단계가 어떻게 일어나는지 알 필요가 없습니다. 단순히 구조화된 응답을 받아 UI를 업데이트할 뿐입니다. 이것이 훨씬 더 깔끔한 책임 분리 (Separation of responsibilities)입니다.

향후 전망 (Looking Ahead)

네트워킹 로직이 점진적으로 ViewController에서 Repository와 Service로 이동했던 것처럼, AI 오케스트레이션 (AI orchestration) 또한 그 자체의 독립된 영역을 가질 가치가 있습니다.

• ViewModel은 여전히 프레젠테이션 (Presentation)을 담당합니다.
• Repository는 여전히 데이터를 담당합니다.
• Backend는 여전히 영속성 (Persistence)을 담당합니다.
• LLM은 여전히 추론 (Reasoning)을 담당합니다.
• Agent는 전체 워크플로우 (Workflow)를 조정하는 책임을 갖게 됩니다.

마치며 (Final Thoughts)

저는 MVVM이 도태되고 있다고 생각하지 않습니다. 사실, MVVM은 SwiftUI에서 프레젠테이션 로직을 관리하는 여전히 가장 좋은 방법 중 하나입니다.

변하고 있는 것은 UI 아키텍처가 아니라, 그 위 (above) 에 있는 레이어입니다.

지능형 애플리케이션의 미래는 ViewModel을 대체하는 것이 아닙니다. 의도 (Intent)를 이해하고, 워크플로우를 계획하며, 도구 (Tools)를 호출하고, 컨텍스트 (Context)를 유지하며, 지능적인 경험을 제공할 수 있는 오케스트레이션 레이어 (Orchestration layer)를 도입하는 것에 관한 것입니다.

우리가 내일 만들 앱들은 단순히 사용자의 행동에 반응하는 것에 그치지 않을 것입니다. 그들은 목표를 달성하기 위해 사용자와 협업할 것입니다. 그리고 이를 위해서는 단순한 또 다른 ViewModel 이상의 것이 필요합니다. 바로 Agent가 필요합니다.

여러분의 생각은 어떠신가요?

만약 여러분이 오늘 AI-first iOS 애플리케이션을 설계한다면:

• 기존의 ViewModel을 확장하시겠습니까?
• 전용 Agent 레이어를 도입하시겠습니까?
• 아니면 또 다른 아키텍처 패턴이 등장할 것이라고 보십니까?

여러분이 AI-native 애플리케이션 아키텍처에 어떻게 접근하고 계신지 정말 궁금합니다.