웹이 등장한 이후 오랫동안 개발자들은 네트워크를 통해 컴포넌트를 연결하는 최적의 방법을 고민해왔다. 그 핵심에는 원격 API(Remote API)가 있으며, 이는 오늘날 소프트웨어 아키텍처 전반에 영향을 미친다. 현재 업계는 JSON API를 중심으로 일정 수준의 타협점을 찾은 상태다. 한계는 존재하지만 단순성과 실용성이라는 장점 덕분에 널리 활용되고 있다.

그러나 사용자의 의도를 이해하고 중개하는 AI 기반 엔드포인트가 등장하면서 인터넷의 기본 작동 방식 자체가 변화하고 있다. 이 변화는 과거 한 차례 실패를 경험했던 서비스 지향 아키텍처(SOA)의 이상을 다시 현실로 끌어오고 있다. 이번에는 AI 덕분에 유연하고 자동화된 서비스 탐색과 유지보수가 가능한 ‘SOA 2.0’이 실현될 수 있다는 기대가 나온다.

왜 기존 SOA는 실패했나

AI가 웹 아키텍처에 미치는 이런 변화를 ‘SOA 2.0’이라고 부를 수 있다.

SOA 2.0이 과거 SOA와 다른 이유를 이해하려면 2000년대의 시행착오를 돌아볼 필요가 있다. 당시 SOA가 지향했던 비전은 매우 매력적이었다. 재고 관리, 청구, 배송 등 서로 다른 비즈니스 서비스가 자동으로 서로를 발견하고 기능을 이해하며, 사람의 개입 없이 복잡한 작업을 협업 처리하는 세상이 목표였다.

이를 구현하기 위해 업계는 SOAP(Simple Object Access Protocol), WSDL(Web Services Description Language), UDDI 서비스 레지스트리, 그리고 중앙에서 모든 통신을 조정하는 ESB(Enterprise Service Bus) 등 복잡한 인프라를 구축했다. 이들 기술은 대부분 XML 기반으로 동작했다.

하지만 현실은 달랐다. 인프라를 이해하는 데만 많은 시간을 소비했고, 정작 해결하려던 문제는 뒤로 밀리기 일쑤였다. 간단한 ‘신규 항목 생성(New Item)’ API 하나를 만들기 위해서도 방대한 규격과 정의를 먼저 작성해야 했다.

더 큰 문제는 지나친 엄격함이었다. SOAP 메시지의 XML 태그 하나만 누락되거나 서비스가 WSDL을 변경해도 이를 사용하는 모든 클라이언트가 다시 코드를 생성해야 했고, 그렇지 않으면 전체 시스템이 쉽게 무너졌다. 오늘날 쿠버네티스 기반 마이크로서비스 환경에서 장애 원인을 추적하기 어려운 상황과 비슷한 문제를 안고 있었던 셈이다.

결국 기존 SOA는 현실 세계의 불완전성과 변화에 대응하지 못하는 지나치게 취약한 구조였고, 업계는 보다 단순한 REST 기반 JSON API로 방향을 틀었다. 자동 서비스 오케스트레이션이라는 이상은 포기했지만, 대신 사람이 직접 연결을 관리하는 방식으로 안정성을 확보했다.

AI가 만드는 ‘의도 중심’ 미들웨어

이제 애플리케이션 아키텍처는 다시 큰 변화를 맞고 있다.

AI 엔드포인트는 단순히 새로운 기능을 추가하는 수준을 넘어 애플리케이션 내부 서비스들이 상호 작동하는 방식을 바꾸고 있다. 애플리케이션이 스스로 자신의 기능과 역할을 이해하는 것과 유사한 효과를 만들어내는 것이다.

과거 WSDL이 하드코딩된 방식으로 서비스 정보를 설명했다면, AI 계층은 동적으로 생성된 설명과 사용자의 모호한 자연어 의도를 함께 해석해 적절한 동작으로 연결할 수 있다. 다시 말해 사용자의 목적과 실제 서비스 기능 사이를 AI가 유연하게 이어주는 역할을 수행한다.

이 구조에서는 백엔드 API, 프런트엔드 기능, 외부 서비스 등 다양한 요소들이 AI 계층을 통해 연결된다. 개발자가 모든 서비스 간 연결을 일일이 하드코딩하지 않아도 되는 것이다.

과거 SOA의 계약이 WSDL이라는 엄격한 문서였다면, 현재는 REST API가 사실상의 계약 역할을 수행한다. 반면 SOA 2.0에서는 대규모 언어 모델(LLM)의 자연어 이해 능력을 바탕으로 계약 자체가 훨씬 유연해진다.

예를 들어 사용자가 “청구 시스템용 스테이징 환경을 새로 만들어 달라”고 요청하면 AI 미들웨어는 특정 API를 하드코딩된 방식으로 호출하지 않는다. 대신 사용자의 의도를 해석하고 의미 기반으로 적절한 기능을 탐색해 필요한 도구와 API를 선택한다. 이 과정에서 과거의 UDDI 대신 벡터 데이터베이스나 함수 목록(Function Registry) 같은 현대적인 메커니즘이 활용될 수 있다.

소프트웨어가 ‘스스로 이해하는’ 시대

이는 단순한 이론이 아니다. 필자는 최근 널리 사용되는 한 세금 신고 서비스를 이용하면서 이런 한계를 직접 경험했다. 암호화폐 관련 새로운 규정 등 복잡한 상황을 처리해야 했지만, 가장 크게 느낀 점은 해당 소프트웨어가 AI 챗봇에 비해 지나치게 ‘멍청하다’는 것이었다.

예를 들어 “지난해 순영업손실(NOL)을 이월해 달라”거나 “스케줄 K가 필요한지 직접 판단해 달라”와 같이 의도를 전달하면 애플리케이션이 이를 이해하고 처리해주기를 기대했다.

필요한 것은 또 다른 챗봇이 아니다. 이미 훌륭한 챗봇은 존재한다. 중요한 것은 애플리케이션 자체가 AI 서비스와 긴밀하게 통합돼 사용자 상황과 맥락을 이해하고, 의도 중심으로 작업을 수행하는 것이다. 또한 같은 기능을 이용한 다른 사용자의 경험을 학습해 더 나은 결과를 제공해야 한다.

이처럼 사용자의 의도를 중심으로 소프트웨어를 지능화하는 흐름이 앞으로 소프트웨어 개발의 다음 단계가 될 가능성이 크다.

지연 시간과 비결정성이라는 새로운 과제

SOA 2.0은 기존 SOA의 경직된 결정론적 구조를 확률 기반의 유연성으로 대체한다. 사용자는 점점 이런 변화를 요구하게 될 것이다. 다만 새로운 접근 방식에는 새로운 문제도 따른다.

첫 번째는 지연 시간(latency) 이다. 과거 ESB는 구축은 복잡했지만 실행 시에는 XML 메시지를 단순히 전달하는 구조였다. 반면 애플리케이션의 핵심 경로에 LLM을 삽입하면 수백 밀리초, 경우에 따라 수초의 추가 지연이 발생할 수 있다. 비동기 작업이나 복잡한 오케스트레이션에는 감수할 만한 비용이지만, 실시간 고성능 마이크로서비스에서는 치명적인 약점이 될 수 있다.

두 번째는 비결정성(non-determinism) 문제다. 지금까지 개발자들은 동일한 입력에는 항상 동일한 출력이 나오는 것을 전제로 시스템을 설계해왔다. 그러나 의도 기반 AI 계층은 그렇게 동작하지 않는다. LLM은 99번은 올바르게 요청을 처리하다가도 100번째에는 존재하지 않는 매개변수를 만들어내거나, 사용자의 표현 방식이 조금만 달라져도 전혀 다른 실행 경로를 선택할 수 있다.

세 번째는 비기능 요구사항(NFR, Non-Functional Requirements) 이다. 보안과 안정성처럼 기능 외적인 요소들이 오히려 더욱 중요해질 수 있다.

특히 함수 호출(Function Calling) 기능은 보안 위험을 증폭시킨다. 사용자의 요청과 AI가 수행 가능한 기능을 연결한 뒤 AI가 실행 방식을 결정하도록 맡긴다면, 적절한 보호 장치 없이 이를 신뢰하기는 어렵다. 따라서 서버 측 기능 강화나 클라이언트 노출 최소화 같은 기존 웹 보안 조치뿐 아니라 AI 자체 또는 AI 외부 계층에서 강력한 가드레일을 적용해야 한다.

인증과 권한 관리 역시 계속 중요하다. RBAC(Role-Based Access Control), SSO(Single Sign-On), OAuth, JWT 같은 기존 기술은 유지되겠지만, 앞으로는 AI가 해석하는 의도 계층과 결합된 형태로 활용될 가능성이 크다.

신뢰성 역시 새로운 과제다. 필자 역시 최근 구글의 Imagen API를 사용하다가 아무런 코드 오류 없이 일부 이미지 생성이 중단되는 문제를 겪었다. 클라이언트와 서버 로그에는 이상이 없었지만 네트워크에서는 HTTP 500 오류가 발생했다. 조사 결과 애플리케이션 맥락과 사용자 입력이 결합되면서 프롬프트가 Imagen의 안전 정책상 위험 콘텐츠로 판단되는 형태로 변형됐기 때문이었다.

문제의 문구는 “어둡고 초현실적이며 글리치 효과가 있는 사이버펑크 풍경과 위협적인 인물들” 정도의 일반적인 창작 표현이었지만, 모델은 이를 위험한 콘텐츠로 간주했다.

이처럼 LLM API를 단순하게 활용하는 경우에도 예상치 못한 상황이 발생할 수 있다. 그렇다면 이런 AI가 소프트웨어 전반에 광범위하게 적용될 경우 어떤 새로운 문제가 나타날지는 더욱 신중히 지켜볼 필요가 있다.

확률적 웹의 시대

지금까지 인터넷의 예측 불가능성은 대부분 사람의 행동이나 하드웨어 오류, 네트워크 장애, 지정학적 변수 같은 외부 요인에서 비롯됐다. 그러나 AI가 중개하는 API는 시스템 자체에 의미 기반의 확률성을 도입한다.

개발자들은 구조화된 응답이나 함수 호출 같은 기법을 활용해 AI 엔드포인트를 보다 안정적으로 사용하는 방법을 계속 찾아낼 것이다. 하지만 더 근본적인 질문은 앞으로 소프트웨어의 본질 자체가 어떻게 변할 것인가이다.

기존 웹에서는 특정 URI에 GET 요청을 보내면 항상 동일한 응답을 기대했다. 지난 40년 동안 웹은 거대한 상태 기계처럼 동작해왔다.

그러나 LLM 기반 API가 시스템 곳곳에 스며들면서 인터넷의 구조 자체도 변화하기 시작한다. 라우팅과 서비스 탐색 계층에 AI가 도입되면 네트워크의 기반에는 대규모 확률성이 내재된다. 요청이 더 이상 하드코딩된 URI 호출이 아니라 LLM이 해석하는 자연어 의도가 되면, 노드 A와 노드 B를 연결하는 관계 역시 고정된 연결이 아니라 확률적으로 결정되는 연결로 바뀐다.

결국 인터넷은 AI 모델의 내부 구조를 닮아가게 된다. 신경망이 고정된 if-then 규칙 대신 확률적으로 활성화되는 시냅스를 기반으로 동작하듯, 미래의 웹 역시 의미 기반의 유연한 서비스 탐색을 중심으로 발전할 가능성이 있다. 서비스들은 단순히 링크로 연결되는 것이 아니라, 공유된 잠재 공간에서 기능적 유사성에 따라 서로를 찾아가게 될 것이다.

이는 소프트웨어 엔지니어링의 성격 자체를 바꾼다. 개발자는 모든 것을 완벽하게 통제한다는 환상에서 벗어나야 한다. 역설적으로 명시적인 확률 요소를 포함한 시스템이 오히려 더 높은 복원력과 적응력을 갖출 수도 있다.

과거 소프트웨어 개발은 건축이나 기계공학에 비유되곤 했지만, 이제는 정원을 가꾸거나 생태계를 관리하는 방식에 더 가까워질 수 있다.

AI를 기술 스택에 통합하는 과정에는 분명 여러 과제가 존재한다. 그럼에도 업계는 2000년대 초 SOA가 꿈꿨던 이상을 다시 향해 나아가고 있다. 과거에는 엄격한 XML과 결정론적 논리로 자동 서비스 탐색을 구현하려 했지만 무게를 견디지 못하고 실패했다. 이제는 통합의 ‘의도(intent)’를 이해하는 신경망 기반 AI를 활용해 같은 목표를 다시 시도하고 있다.

미들웨어는 여전히 존재하지만, 그 역할은 엔터프라이즈 서비스 버스(ESB)가 아니라 ‘엔터프라이즈 추론 버스(Enterprise Reasoning Bus)’에 가까워지고 있다. 그리고 모든 마이크로서비스 통합을 개발자가 일일이 하드코딩해야 했던 시대는 점차 막을 내릴 가능성이 있다.
dl-itworldkorea@foundryco.com