[크리스의 SW아키텍처] AI가 다시 쓰는 소프트웨어 아키텍처 — 그리고 그 끝에서 만나는 '적응형 소프트웨어'
소프트웨어 아키텍처는 지난 1년 사이 어느 때보다 빠르게 다시 쓰이고 있다. AI가 코드를 생성하는 수준을 넘어 실제 업무 시스템을 조작하는 에이전트로 자리 잡으면서, 그동안 사람의 인지적 한계와 협업의 편의를 전제…
소프트웨어 아키텍처는 지난 1년 사이 어느 때보다 빠르게 다시 쓰이고 있다. AI가 코드를 생성하는 수준을 넘어 실제 업무 시스템을 조작하는 에이전트로 자리 잡으면서, 그동안 사람의 인지적 한계와 협업의 편의를 전제로 다듬어져 온 설계 원칙 자체가 흔들리고 있기 때문이다. 최근 업계 안팎에서 확인되는 변화를 다섯 갈래로 정리하고, 그 끝에서 소프트웨어가 결국 어떤 모습으로 향하고 있는지를 짚어본다.
① 서비스 분리 단위의 재조정 — 마이크로서비스에서 모듈러 모놀리식으로
지난 10여 년간 소프트웨어 아키텍처를 지배한 패턴은 마이크로서비스였다. 시스템을 잘게 쪼개 독립적으로 배포하면 팀 간 의존성이 줄고 확장성이 좋아진다는 논리였다. 그러나 AI 에이전트들이 서로 대화하며 작업을 처리하는 환경이 되자 이 논리에 금이 가기 시작했다. 에이전트 간 호출이 늘어날 때마다 직렬화·전송·역직렬화 과정에서 지연이 누적되는데, 최근 아키텍처 커뮤니티에서는 이를 '네트워크 세금(Network Tax)'이라 부르며 경계한다. 이 때문에 일부 아키텍트들은 레이(Ray) 같은 액터 프레임워크 기반의 '모듈러 모놀리식'으로 회귀해, 에이전트끼리 방대한 컨텍스트를 네트워크 너머로 복사하는 대신 같은 프로세스 안에서 메모리 포인터를 주고받는 '제로카피' 방식을 택하고 있다. '잘게 쪼갤수록 유연하다'는 지난 10년의 공식이, 에이전트들이 밀리초 단위로 서로를 호출하는 환경에서는 더 이상 그대로 성립하지 않는다는 뼈아픈 반성이다.
② 설계 대상의 전환 — 계층형 구조에서 에이전트 오케스트레이션으로
사람이 화면을 보고 비즈니스 로직을 거쳐 데이터베이스에 접근하는 흐름을 전제로 한 전형적인 3계층 구조도 변하고 있다. AI 에이전트 라이브러리 랭체인(LangChain)이 최근 공식화한 '에이전틱 엔지니어링' 개념에 따르면, 에이전트는 역할과 공유 메모리, 통합된 관측 체계를 가진 '디지털 팀원'으로 개발 파이프라인에 편입되고 있다. 실제 상용 제품에서도 이 변화가 확인된다. SAP는 지난 5월 자사 콘퍼런스에서 224개의 에이전트를 5개 업무 영역에 배치한 '오토노머스 엔터프라이즈' 아키텍처를 선보였고, 협업 소프트웨어 업체 아틀라시안은 9월 지라(Jira)에 '거버넌스가 적용된 에이전트 워크플로' 기능을 추가해 AI 에이전트의 코드 작성·검토가 기업이 정한 규칙 안에서만 움직이도록 제한했다. 설계의 대상이 '사람이 다룰 화면과 데이터'에서 '에이전트가 수행할 역할과 그 역할의 경계'로 옮겨가고 있는 것이다.
③ 데이터 접근 방식의 진화 — 검색에서 검증으로
기업 내부 데이터를 AI 답변에 연결하는 검색증강생성(RAG) 기술도 세대교체를 겪고 있다. 초기 RAG는 질문을 벡터로 바꿔 유사한 문서를 한 번 검색한 뒤 그 내용을 그대로 답변에 주입하는 단방향 파이프라인이었고, 관련 정보가 없으면 AI가 그럴듯한 거짓 답변을 만들어내는 '환각' 문제가 잦았다. 최근 자리 잡은 '에이전틱 RAG'는 에이전트가 검색 결과를 스스로 평가해 근거가 부족하면 반복적으로 재검색하거나, 문서의 출처와 신뢰도 점수를 답변과 함께 제시하도록 설계된다. 아키텍처의 무게중심이 '얼마나 빨리 정보를 가져오는가'에서 '그 정보가 신뢰할 만한지를 어떻게 검증하는가'로 옮겨가고 있다는 신호다.
④ 비용 구조의 분화 — 모델 라우팅과 '판단 전용 AI'의 등장
모든 작업에 가장 비싼 최첨단 모델을 쓰는 방식은 더 이상 지속 가능하지 않다는 공감대 속에, 단순 반복 작업은 경량 모델에, 복잡한 추론은 거대 모델에 맡기는 '모델 라우팅'이 표준으로 자리 잡고 있다. 이 흐름이 가장 극단적으로 발현된 사례가 최근 등장한 '판단 전용 AI'다. 지난달 챗GPT 공동개발자 출신 디오고 알메이다가 이끄는 타입세이프AI가 텍스트를 생성하지 않고 유형화된 확률적 판단값만 반환하는 모델 '제브(Jev)'를 선보인 지 불과 열흘 만에, 아마존의 오픈소스 모델 '스트랜즈 디사이더', 클라우드플레어의 '클레프', 국내 업스테이지의 '솔라 디사이드'가 잇달아 출시되며 3파전, 4파전 양상으로 번졌다. 소프트웨어가 AI를 호출하는 방식 자체가, 대화형 응답을 받아 파싱하는 구조에서 애초에 소프트웨어가 소비하기 쉬운 '유형화된 판단'을 직접 돌려받는 구조로 분화하고 있는 것이다.
⑤ 보안·거버넌스의 설계 단계 편입
AI 에이전트가 실제 기업 시스템을 조작할 권한을 갖게 되면서, 보안은 부가 기능이 아니라 설계의 전제 조건이 됐다. 프롬프트 인젝션은 시스템이 내려주는 지시문과 외부에서 들어온 데이터를 똑같은 자연어로 받아들여 구분하지 못하는 대형언어모델의 구조적 특성에서 비롯되기 때문에, 방화벽이나 백신 같은 사후 탐지 도구로는 막을 수 없다. 이 때문에 엔비디아의 오픈셸(OpenShell)이나 마이크로소프트의 에이전트365(Agent 365)처럼, 에이전트가 무엇을 할 수 있는지를 사람이 미리 선언적으로 정의해두고 런타임에서 강제로 제한하는 아키텍처가 해법으로 떠오르고 있다. '확장성'이 지배하던 설계 기준이 이제 '통제력'으로 옮겨가고 있다는 뜻이다.
다섯 갈래가 만나는 자리 — 소프트웨어는 결국 '적응형(Adaptive)'으로 향한다
이 다섯 가지 변화를 나란히 놓고 보면 공통된 방향이 보인다. 서비스는 고정된 경계 대신 필요에 따라 묶이고 풀리며, 구조는 정적인 계층 대신 역할이 재조정되는 에이전트 집합으로 바뀌고, 데이터는 한 번 가져오는 대신 스스로 검증하고 재탐색하며, 모델은 작업의 성격에 따라 실시간으로 교체되고, 권한은 미리 정해진 규칙 안에서 런타임마다 다시 계산된다. 이것이 가리키는 결론은 하나다. 앞으로의 소프트웨어는 배포되는 순간 완성되는 '고정된 산출물'이 아니라, 운영되는 동안 스스로 환경을 관측하고 판단하고 행동을 조정하는 '적응형 소프트웨어(Adaptive Software)'로 향하고 있다는 것이다.
이는 막연한 전망이 아니라, 이미 학계와 산업계 양쪽에서 구체적인 근거를 갖추고 움직이는 흐름이다. 자율컴퓨팅(autonomic computing) 분야에서 오래전부터 연구돼온 '모니터링-분석-계획-실행(MAPE)' 피드백 루프는 애초에 시스템이 환경 변화를 스스로 감지하고 대응하도록 설계하는 틀이었는데, 최근 AI 에이전트 연구에서 이 개념이 다시 핵심 참조 모델로 소환되고 있다. 올해 열린 국제자율에이전트및멀티에이전트시스템학회(AAMAS) 2026에서 발표된 '자가진화형 소프트웨어 에이전트(Self-Evolving Software Agents)' 연구는, 기존의 자율 에이전트가 설계 시점에 정해진 목표와 역량에 묶여 있던 한계를 넘어, 신념-욕구-의도(BDI) 모델 구조 안에서 에이전트가 목표와 추론, 행동 자체를 운영 중에 스스로 진화시키는 프레임워크를 제시했다.
산업 현장에서도 같은 방향의 실천이 이미 진행형이다. 인프라 운영 영역에서 확산되고 있는 '정책 기반 코드(Policy-as-Code)'와 '의도 기반 아키텍처'는, 시스템이 지향해야 할 '의도된 상태'를 코드저장소에 선언해두고 시스템이 실제 운영 환경을 그 선언된 상태와 지속적으로 비교해 스스로 맞춰나가도록 하는 방식이다. 이는 장애가 발생하면 사람이 개입해 복구하는 대신 시스템이 스스로 치유하는 '자가치유형(self-healing)' 아키텍처로 이어진다. 앞서 살펴본 에이전트 오케스트레이션, 검증형 RAG, 모델 라우팅, 런타임 권한 통제는 각각 따로 등장한 기술처럼 보이지만, 사실은 모두 이 '의도된 상태를 향해 스스로 조정하는 시스템'이라는 하나의 큰 그림 안에 있는 조각들이다.
결국 지금 벌어지고 있는 아키텍처의 재편은, 소프트웨어를 한 번 잘 설계해서 배포하면 끝나는 '제작물'로 보던 관점에서, 운영되는 내내 스스로 관측하고 학습하며 자신의 구조까지 조정해가는 '살아있는 시스템'으로 보는 관점으로의 전환을 의미한다. 이 적응형 소프트웨어의 시대에 아키텍트의 역할은 더 이상 모든 경우의 수를 미리 설계도에 담아내는 것이 아니라, 시스템이 스스로 적응할 수 있는 범위와 원칙, 그리고 그 적응이 넘지 말아야 할 경계를 정의하는 일로 옮겨갈 것이다. 그리고 그 경계를 어떻게 긋느냐는 결국, 필자가 이 지면에서 거듭 강조해온 것처럼 기술의 문제가 아니라 그 시스템에 관여하는 사람과 에이전트들 사이의 '관계'를 얼마나 신뢰할 수 있게 설계하느냐의 문제로 되돌아온다.
본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)