[크리스의 SW아키텍처] AI가 Legacy에 통합되는 시대, 소프트웨어는 어떻게 바뀌는가?
가트너 "2026년 말까지 기업용 앱 40%에 작업 특화 에이전트 통합"…같은 가트너는 "에이전틱 AI 프로젝트 40% 이상 2027년 말까지 취소" 전망 - Cloud Native가 '확장 가능한 실행'이라면 AI…
소프트웨어 업계에서 'AI-Native'라는 말이 빠르게 퍼지고 있다. 기존 제품에 AI 기능을 나중에 붙이는 방식에서 벗어나, 지능을 처음부터 설계의 중심 원칙으로 삼고 사람과 다른 AI 시스템이 협업하도록 만든 애플리케이션을 가리키는 말이다. 이 개념을 소개하는 한 국내 기술사 블로그 글은 Cloud Native가 '효율적으로 실행되는 소프트웨어'를 만든다면 AI-Native는 '지속적으로 학습하는 소프트웨어'를 만든다고 요약한다. 방향은 설득력이 있다. 다만 개념이 유행어가 되면 두 가지 일이 함께 벌어진다. 근거가 불분명한 수치가 사실처럼 돌아다니고, 새로 생기는 설계 비용은 무시되고 있다.
이 기사는 AI-Native 애플리케이션의 정의와 핵심 구현 패턴을 소프트웨어 아키텍트의 눈으로 검증한다. 통용되는 주장 가운데 확인되는 것과 확인되지 않는 것을 나누고, 각 패턴이 아키텍처에 부과하는 품질속성의 교환 관계를 정리한다. 결론부터 말하면 AI-Native에서 아키텍처는 훨씬 더 중요해진다. 그러나 그 중요성은 '더 많은 지능'이 아니라 '더 단단한 통제'에서 나온다.
Cloud Native 위에 얹히는 새로운 Layer
첨부된 개념 정리는 AI-Native 애플리케이션을 지능이 1차 설계 원칙이고, 처음부터 사람과 다른 AI 시스템과 협업하도록 설계되며, 지속적으로 학습하고 적응하는 소프트웨어로 규정한다. 전통적 소프트웨어와의 차이는 AI 통합 시점(개발 후 추가 대 설계 원칙부터 핵심), 시스템 행동(고정된 규칙 대 학습·적응), 인터페이스(GUI 대 자연어·음성·의도 인식), 데이터의 역할(저장·조회 대 학습의 연료), 의사결정(프로그래밍된 로직 대 실시간 컨텍스트 지능) 등으로 정리된다.
비교의 한쪽 기둥인 Cloud Native는 어떻게 정의되는가. Cloud Native Computing Foundation(CNCF)의 정의는 Container, Service Mesh, Microservices, Immutable Infrastructure, Serverless, Declarative API 같은 기술을 열거하면서, 이런 시스템이 느슨하게 결합되고 "안전하고 복원력 있고 관리 가능하고 지속 가능하며 관찰 가능한" 방식으로 상호 운용된다고 설명한다. 요컨대 Cloud Native는 변화하는 환경에서 소프트웨어를 안정적으로 배포하고 운영하는 방식에 관한 정의다.
여기서 필자는 두 개념이 대체 관계가 아니라 층의 관계라고 본다. 학습하는 소프트웨어도 결국 어딘가의 컨테이너에서 돌아가고, Observability와 복원력이 없으면 운영할 수 없다. AI-Native는 Cloud Native의 속성 위에 '학습과 추론이 시스템의 부품이 된다'는 새로운 층을 더한 것이다. 이 층이 더해지면서 같은 품질속성이라도 다른 모양의 문제가 된다.
한 가지 용어 혼동도 정리해 둔다. 가트너는 2026년 기술 트렌드에서 'AI 네이티브 개발 플랫폼'을 첫 번째 갈래인 '설계자(The Architect)' 주제에 넣고, 작고 민첩한 팀이 생성형 AI로 소프트웨어를 만들 수 있게 하는 것으로 설명했다. 이것은 'AI로 소프트웨어를 만드는 플랫폼'이고, 이 기사가 다루는 'AI로 동작하는 애플리케이션'과는 다른 개념이다. 같은 AI-Native라는 이름이 두 가지 대상을 가리킨다는 점을 구분해야 논의가 어긋나지 않는다.
시장 신호와 거품 사이: 두 개의 가트너 예측
가트너는 2025년 8월 26일 보도자료에서 2026년 말까지 기업용 애플리케이션의 40%가 작업 특화 AI 에이전트와 통합될 것이라고 예측했다. 당시 기준으로 5% 미만이던 비율이 급증한다는 것이다. 보도자료는 에이전트 진화를 다섯 단계로 나눴다. 애플리케이션마다 내장되는 AI 어시스턴트, 작업 특화 에이전트 애플리케이션, 한 애플리케이션 안에서 협업하는 에이전트, 애플리케이션을 넘나드는 Agent Ecosystem, 그리고 2029년까지 지식 노동자의 최소 50%가 에이전트를 다루고 통제하거나 만드는 역량을 갖추는 '새로운 표준'이다. 가트너의 낙관 시나리오는 2035년 에이전틱 AI가 기업용 애플리케이션 소프트웨어 매출의 약 30%, 4500억 달러 이상을 차지한다는 것이다. 2025년에는 2%다. 분석은 아누슈리 베르마(Anushree Verma) 선임 이사가 맡았다.
그러나 같은 분석가가 두 달 전인 2025년 6월 25일 내놓은 전망을 함께 읽어야 한다. 가트너는 에이전틱 AI 프로젝트의 40% 이상이 비용 증가, 불분명한 사업 가치, 부족한 위험 통제 때문에 2027년 말까지 취소될 것이라고 예측했다. 베르마는 지금의 에이전틱 AI 프로젝트 대부분이 초기 실험이거나 개념 검증이며 "과대 광고에 이끌리고 잘못 적용되는 경우가 많다"고 말했다. 가트너는 기존 AI 어시스턴트, 로봇 프로세스 자동화(RPA), 챗봇을 에이전트로 재포장하는 'Agent Washing'이 퍼져 있고, 수천 개 에이전틱 AI 업체 가운데 진짜는 약 130곳으로 추산했다. 2025년 1월 웨비나 참석자 3,412명 조사에서 에이전틱 AI에 상당한 투자를 했다는 응답은 19%였다.
두 예측을 합치면 이렇게 읽힌다. 에이전트가 앱에 들어가는 속도는 빠르지만 그중 상당수는 비용과 가치와 통제의 벽에 부딪힌다. AI-Native가 생존 필수 요건이 된다는 표현은 아직 주장이지 검증된 사실이 아니다. 결국 크리스컴퍼니에서는 결국 소프트웨어 아키텍처가 이 과정에서 더욱 중요해질 것이라고 주장하고 있다. ( www.chris.company )
다음은 AI가 적용되면서 바뀐 Sofware의 특성을 전반적으로 학습하기 위한 몇가지 AI-Native 소프트웨어의 아키텍처 패턴을 정리해 보았다. 크리스컴퍼니 의견으로는 이러한 혼돈이 최소 12년은 더 갈 것이고 그 후에 새로운 소프트웨어와 소프트웨어 개발방식의 등장에 맞는 새로운 개발방법론과 문화 및 계약구조가 생겨날 것으로 보고 있다. 다음은 크리스컴퍼니가 정리한 몇가지 최선 AI가 적용되는 소프트웨어의 아키텍처 패턴들이다. 크리스미디어는 발전하는 AI가 우리사회 전반에 젖어들면서 많은 변화가 일어날 것으로 보고 있고 이러한 사회상을 취재하고 기록하는 것을 하려고 하고 있고, 크리스컴퍼니는 이러한 크리스미디어가 참고할 기술적 변화를 국내 대표 소프트웨어 아키텍처 컨설팅회사로 지속적으로 관련 데이터를 제공하려고 한다.
패턴 - AI Native Software의 설계 패턴
①: 모델이 시스템의 First-class Citizen이 될 때
첫 번째 구현 패턴은 모델 기반 구조다. Inference Engine이 데이터베이스처럼 시스템의 핵심 구성요소가 되고, 모델이 애플리케이션 로직 안에 내장된다. 대표 사례로 첨부 정리는 앤트로픽의 'Orchestrator-Worker' 구조를 든다. 선도 에이전트가 전문화된 Sub-agent를 조율하는 방식이다.
앤트로픽이 2025년 6월 13일 공개한 개발기에 따르면 오퍼스 4가 선도하고 소넷 4가 보조하는 Multi-agent 구성은 내부 리서치 평가에서 단일 에이전트 오퍼스 4보다 90.2% 높은 성과를 냈다. 첨부 정리에 나온 90.2%는 이 수치다. 다만 이것은 회사가 내부 평가에서 측정한 결과이며 업무 일반에 대한 성능 보증이 아니다. 같은 글에는 비용이 함께 적혀 있다. 에이전트는 채팅의 약 4배, Multi-agent 시스템은 약 15배의 토큰을 쓰고, 한 벤치마크에서 성능 차이의 80%가 토큰 사용량만으로 설명됐다. 앤트로픽은 이런 구조가 가치가 충분히 높은 과제에서만 경제성이 있다고 밝혔다. 또한 에이전트는 같은 프롬프트에서도 실행마다 다른 경로를 택하는 비결정적 시스템이라고 설명했다.
앤트로픽이 2024년 12월 19일 쓴 '효과적인 에이전트 만들기'는 한 걸음 더 나아가 가능한 한 가장 단순한 해법에서 시작해 필요할 때만 복잡도를 올리라고 권한다. 사전에 정해진 코드 경로로 LLM과 도구를 엮는 'Workflow'와, 스스로 과정을 정하는 '에이전트'를 구분하고, 지연과 비용을 더 나은 성과와 맞바꿀 가치가 있는지 따지라는 것이다.
아키텍처 관점에서 이 패턴이 만드는 교환 관계는 분명하다. 성능과 유연성을 얻는 대신 비용, 지연, Reproducibility를 내놓아야 한다. 필자는 업무 로직 계층을 규칙이 풀 수 있는 부분은 결정형 코드로, 모호한 판단은 모델로 나누는 혼합 구조로 설계하는 것이 기본이 될 것으로 본다. 모든 판단을 거대 모델에 맡기는 설계는 비용 폭증과 감사 불가능성을 동시에 부르기 쉽다.
②: 학습하는 시스템의 기술부채
두 번째 패턴인 Adaptive Feedback Loop는 AI-Native의 정의에서 가장 매력적이면서 가장 위험한 대목이다. 전통 시스템이 모니터링, 로깅, 사후 분석으로 이어진다면 AI-Native 시스템은 루프 안에서 피드백으로 모델과 시스템을 계속 개선한다. 사용자 행동 패턴을 학습하고 자원을 동적으로 배분하며 예측에 기반해 선제 조치를 한다는 것이 첨부 정리의 설명이다.
이 구조가 가진 비용은 이미 10년 전에 경고됐다. D. 스컬리 등 연구진이 2015년 신경정보처리시스템학회(NIPS)에 발표한 논문 '머신러닝 시스템의 숨은 기술부채'는 머신러닝이 유용한 예측 시스템을 빠르게 만들어주는 속도 때문에 그 이득이 공짜처럼 보이지만, 그렇게 생각하는 것은 위험하다고 지적했다. 저자들은 경계의 침식, 얽힘, 숨은 Feedback Loop, 선언되지 않은 소비자, 데이터 의존성, 설정 문제, 외부 세계의 변화 같은 ML 고유의 위험 요인을 열거했다. 학습하는 시스템은 코드만이 아니라 데이터와 환경에도 의존하기 때문에, 한 부분의 변경이 시스템 전체로 번지는 구조가 된다는 경고다.
통제 없는 학습 루프가 어떻게 무너지는지는 실제 사례가 있다. 마이크로소프트는 2016년 3월 25일 글에서 1824세 미국 이용자를 겨냥한 챗봇 '테이'가 서비스 시작 후 24시간 안에 일부 이용자의 협공을 받아 부적절하고 공격적인 글을 올렸다고 밝혔다. 회사는 여러 유형의 남용을 대비했지만 이 특정 공격은 놓쳤고, 이를 미리 보지 못한 데 전적인 책임을 진다고 했다. 테이는 첫날 이후 중단됐다. 학습이 이용자와의 상호작용에서 직접 일어나는 구조가 외부의 악의에 그대로 노출된 것이다.
제도도 이 문제를 겨냥한다. EU 인공지능법(AI Act) 15조 4항은 출시 후에도 학습을 계속하는 고위험 AI 시스템이 편향된 출력이 이후 입력에 영향을 주는 위험을 가능한 한 제거하거나 줄이도록 개발돼야 하며, Feedback Loop를 적절한 완화 조치로 다루라고 규정한다. 15조 5항은 제3자가 시스템의 사용, 출력, 성능을 바꾸려는 시도에 견디는 회복탄력성을 요구하며 데이터 오염, 모델 오염, 적대적 예시를 명시한다.
아키텍처의 답은 학습 루프에 관문을 세우는 것이다. 수집한 피드백은 품질·편향·적대적 입력을 걸러내는 평가 관문을 통과해야 학습에 반영되고, 업데이트는 Shadow Deployment나 Canary Deployment로 먼저 일부에서 검증한 뒤 Regression Evaluation을 거쳐 전면 배포하며, 언제든 Rollback할 수 있어야 한다. 학습을 '지속적으로 한다'는 말은 '통제 없이 계속 바뀐다'는 말이 아니다. 여기서 생기는 교환 관계는 적응성 대 예측 가능성·Reproducibility·Auditability다.
③: 저지연 처리와 비용의 삼각관계
세 번째 패턴은 즉각적이고 맥락을 아는 의사결정을 위한 저지연 처리다. 첨부 정리는 빠른 데이터 처리 프레임워크, 효율적 Inference Engine, 컨테이너화된 모델, 실시간 추론, 엣지 컴퓨팅 통합을 요구사항으로 꼽는다. 방향은 맞다. 다만 지연을 줄이는 것은 다른 속성과 맞바꿔야 하는 일이다.
앞서 본 대로 서빙 엔진의 최적화는 같은 지연에서 처리량을 크게 늘릴 수 있다. vLLM 논문은 이 이득이 긴 시퀀스, 큰 모델, 복잡한 디코딩에서 더 크다고 밝혔다. 그러나 응답을 빠르게 하려고 추론을 줄이면 정확도가 떨어질 수 있고, 정확도를 높이려고 더 많은 토큰을 쓰면 지연과 비용이 늘어난다. 앤트로픽이 성능의 상당 부분을 토큰 사용량으로 설명한 점을 떠올리면, 저지연 요구는 곧 모델 크기, 추론 깊이, 호출 횟수의 예산 문제다. 필자는 이를 '지연·정확도·비용의 삼각관계'로 부르며, 호출당 예산과 초과 시 동작(더 작은 모델로 대체, 캐시 응답, 사람에게 이관)을 설계 단계에서 정의해야 한다고 본다.
생성형 인터페이스는 이 삼각관계를 사용자 경험 수준으로 끌어올린다. 구글 리서치는 2025년 11월 18일 모델이 콘텐츠뿐 아니라 프롬프트마다 맞춤화된 인터랙티브 인터페이스를 통째로 생성하는 'Generative UI'를 소개했다. 사람 평가에서 전문가가 설계한 사이트가 가장 선호됐고 Generative UI가 그 뒤를 바짝 따랐으며, 기본 텍스트·마크다운 출력과는 큰 격차를 보였다고 한다. 다만 평가는 생성 속도를 고려하지 않았다. 구글은 현재 구현이 결과를 내기까지 "1분 이상 걸리기도" 하며 가끔 부정확한 출력이 있다고 한계를 밝혔다. 유연한 인터페이스는 지연과 정확성이라는 값을 치른다.
인터페이스의 통제권: 의도를 말하면 누가 책임지는가?
네 번째 변화는 인터페이스다. 자연어, 음성, 의도 인식, 맥락 기반 추천이 전통적 그래픽 인터페이스를 넘어서는 상호작용으로 제시된다. 사용성 전문가 야콥 닐슨은 2023년 5월 20일 글(같은 해 10월 23일 갱신)에서 AI가 컴퓨팅 역사상 세 번째 사용자 인터페이스 패러다임, 곧 'Intent-based Outcome Specification'을 연다고 주장했다. 일괄 처리(1945년경)와 Command-based Interaction(1964년경)에 이은 것이다. 사용자가 단계가 아니라 원하는 결과를 말하면 "통제의 위치가 완전히 뒤바뀐다"는 것이 그의 설명이다. 닐슨은 Command-based 시스템에서는 사용자가 단계마다 상황을 재평가하지만, Intent-based 시스템에서는 통제권이 컴퓨터에 있고 AI가 오류를 내기 쉬워서 결과가 어떻게 나왔는지 모르는 사용자는 고치기 더 어려울 수 있다고 지적했다. 그는 미래 시스템이 Intent-based, Command-based, GUI를 섞은 하이브리드 인터페이스가 될 것으로 내다봤다.
아키텍처로 옮기면 Intent-based Interface에는 '의도 해석, 실행 계획 제시, 사용자 확인, 실행, 되돌리기'라는 단계가 설계에 들어가야 한다. 의도를 한 번에 실행으로 연결하면 편리하지만 오류의 책임과 복구 비용이 사용자에게 넘어간다. 여기서 생기는 교환 관계는 인터페이스의 유연성 대 일관성·통제감·학습 용이성이다.
품질속성 지도: 패턴이 부과하는 새로운 교환 관계
지금까지 본 내용을 품질속성 관점에서 한 표로 정리한다. 마지막 열의 '근거'는 이 기사에서 확인한 자료다. 표의 교환 관계 쌍은 필자의 해석이다.
패턴
얻는 것
새로 생기는 품질속성
교환 관계
근거
모델 기반 구조(Orchestrator-Worker)
복잡한 과제에서 성능, 병렬 처리
Token Economics, Non-determinism 대응
성능·유연성 대 비용·지연·Reproducibility
앤트로픽(2025.6, 2024.12)
Adaptive Feedback Loop
환경 변화에 대한 적응
학습 통제성, Rollback 가능성, 데이터 무결성
적응성 대 예측 가능성·Auditability
Sculley 외(2015), 테이(2016), EU AI법 15조
저지연 처리
즉각적 의사결정
Inference Serving 효율, 지연 예산
지연 대 정확도·비용
vLLM(2023), 앤트로픽
Generative·Intent-based UI
맥락에 맞는 맞춤 경험
의도 확인·되돌리기, 일관성
유연성 대 일관성·통제감
닐슨(2023), 구글 리서치(2025.11)
Intelligence Everywhere(Cross-cutting)
시스템 전반의 자동 최적화
Cross-cutting Controls(Guardrails·평가·Observability)
지능의 확산 대 추적 가능성
Sculley 외(2015)
정리하면 AI-Native 애플리케이션이 얻는 이득은 거의 모두 어떤 통제 가능성과 맞바꿔 얻는 것이다. 그래서 아키텍트의 일은 이득을 극대화하는 것이 아니라 어디까지 맞바꿀지를 의식적으로 정하는 것이다.
도입 단계별로 필요한 아키텍처 역량
가트너가 제시한 에이전트 진화 단계를 아키텍처 준비도와 짝지어 보면 도입 순서가 더 분명해진다. 이 표는 필자의 정리이며 가트너가 제시한 것이 아니다.
단계
상태
먼저 갖춰야 할 아키텍처 역량
1. 어시스턴트 내장
사람 입력에 의존하는 보조 기능
데이터 접근 통제, 사용량·비용 관측
2. 작업 특화 에이전트
하나의 업무를 끝까지 수행
Least Privilege, Evaluation Harness, 되돌리기 가능한 변경
3. 앱 내 협업 에이전트
여러 에이전트가 분업
역할·경계 정의, Context Isolation, 토큰 예산
4. 앱 간 Agent Ecosystem
여러 애플리케이션을 가로질러 협업
계약 기반 인터페이스, Policy Gateway, 감사 추적
5. 대중화
지식 노동자가 에이전트를 직접 만들고 통제
셀프서비스 플랫폼, 거버넌스 자동화, 권한 모델
실무 점검 질문은 여섯 가지다. 첫째, 이 기능에서 모델이 결정하는 것과 규칙이 결정하는 것의 경계는 어디인가. 둘째, 학습이나 업데이트가 일어나는 경로에 평가 관문과 Rollback이 있는가. 셋째, 호출당 토큰·지연 예산은 얼마이며 초과하면 어떻게 동작하는가. 넷째, 의도를 실행으로 연결하기 전에 사용자가 확인하고 되돌릴 수 있는가. 다섯째, 오작동했을 때 Blast Radius는 구조로 제한되는가. 여섯째, 정답 여부를 판정할 평가 데이터와 관측 지표가 있는가. 이 질문에 답하지 못한 채 AI-Native를 선언하면 이 지면이 말해 온 기술부채·인지부채·의도부채에 더해, 사람과 에이전트와 시스템 사이의 협업 구조가 설계되지 않은 '관계부채'를 함께 쌓게 된다.
결론: '진화하는 소프트웨어'의 진화 방향을 누가 정하는가
Cloud Native가 소프트웨어를 안정적으로 실행하는 방법이었다면, AI-Native는 소프트웨어가 스스로 변화하는 방법이다. 이 변화는 이 지면이 이전에 정리한 '적응형 소프트웨어(Adaptive Software)'의 논지와 맞닿아 있다. 그러나 스스로 변하는 시스템에는 변화의 방향을 정하는 구조가 필요하다. 어떤 피드백을 받아들일지, 어떤 변화를 배포할지, 어떤 결정을 기계에 맡기고 어떤 결정을 사람에게 남길지를 정하는 일이다. 그것이 아키텍처다.
시장은 두 가지 예측 사이에서 움직이고 있다. 에이전트가 기업용 앱에 빠르게 들어가는 한편, 그 상당수가 비용과 가치와 통제의 벽에 막혀 취소될 수 있다. 이 간극에서 살아남는 제품은 더 많은 지능을 가진 제품이 아니라, 지능을 더 잘 가둘 줄 아는 제품일 가능성이 크다. 이는 전망일 뿐 확정된 결과가 아니다. 다만 학습하는 소프트웨어의 시대에 가장 값비싼 것은 모델이 아니라 올바른 경계를 긋는 판단이라는 점은 지금까지의 근거가 일관되게 가리킨다.
출처
Gartner 보도자료, "Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5% in 2025," 2025년 8월 26일 ( https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025 )
Gartner 보도자료, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," 2025년 6월 25일 ( https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027 )
IT Brief, "Gartner study: 30% of enterprises to automate network by 2026," 2024년 9월 ( https://itbrief.com.au/story/gartner-study-30-of-enterprises-to-automate-network-by-2026 )
Gartner, "Top Technology Trends 2026" ( https://www.gartner.com/en/articles/top-technology-trends-2026 )
CNCF, Cloud Native Definition ( https://github.com/cncf/toc/blob/main/DEFINITION.md )
D. Sculley 외, "Hidden Technical Debt in Machine Learning Systems," NIPS 2015 ( https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html )
Microsoft, "Learning from Tay's introduction," 2016년 3월 25일 ( https://blogs.microsoft.com/blog/2016/03/25/learning-tays-introduction/ )
EU 인공지능법 15조 ( https://artificialintelligenceact.eu/article/15/ )
Woosuk Kwon 외, "Efficient Memory Management for Large Language Model Serving with PagedAttention," SOSP 2023 ( https://arxiv.org/abs/2309.06180 )
Anthropic Engineering, "How we built our multi-agent research system," 2025년 6월 13일 ( https://www.anthropic.com/engineering/multi-agent-research-system )
Anthropic Engineering, "Building effective agents," 2024년 12월 19일 ( https://www.anthropic.com/engineering/building-effective-agents )
Jakob Nielsen, "AI Is First New UI Paradigm in 60 Years," UX Tigers, 2023년 5월 20일 ( https://www.uxtigers.com/post/ai-new-ui-paradigm/ )
Google Research, "Generative UI: A rich, custom, visual interactive user experience for any prompt," 2025년 11월 18일 ( https://research.google/blog/generative-ui-a-rich-custom-visual-interactive-user-experience-for-any-prompt/ )
개념 정리 원문: GilliLab 정보관리기술사 노트(티스토리), "AI-Native Applications: 지능을 설계 원칙으로 삼는 차세대 소프트웨어" ( https://rupijun.tistory.com/entry/AI-Native-Applications-지능을-설계-원칙으로-삼는-차세대-소프트웨어 )
본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)