[크리스의 SW아키텍처] AI가 코드를 쓰는 시대, 소프트웨어 공학의 승부처는 '아키텍처'로 이동한다.

여러 AI 에이전트를 기업 시스템에 통합하고 통제하는 설계가 핵심 경쟁력으로 부상 … ‘AI-Native 소프트웨어 공학' 새 국면

기업 소프트웨어 개발의 무게중심이 '코드를 얼마나 빨리 짜느냐'에서 '시스템을 어떻게 설계하고 통제하느냐'로 옮겨가고 있다. 여러 AI 에이전트를 기업 시스템에 안전하게 통합하고 운영하는 ‘AI 소프트웨어 아키텍처'가 새로운 핵심 경쟁력으로 떠오르면서, 기존 소프트웨어 공학도 AI를 전제로 재편되는 ‘AI-Native 소프트웨어 공학(AI-Native Software Engineering)’의 국면에 접어들었다는 분석이 나온다.

겉으로 보면 이는 역설적이다. AI 덕분에 코드를 짜는 일이 쉬워지고 싸졌다면 소프트웨어 개발의 문턱도 낮아져야 하고, 숙련된 설계 역량의 가치는 오히려 줄어들 것 같기 때문이다. 그러나 현장과 시장 전문가들의 진단은 반대다. 코드 생산 비용이 떨어질수록 병목은 다른 곳으로 이동하고, 그 자리를 차지하는 것이 바로 아키텍처라는 것이다. 이 글에서는 이 변화가 왜 일어나는지, 그리고 그 논리가 어떤 근거 위에 서 있는지를 차례로 짚어본다.

에이전트가 앱 속으로 들어온다

변화의 속도는 빠르다. 시장조사기관 가트너는 2026년 말까지 전체 기업 애플리케이션의 40%에 작업 특화 AI 에이전트가 통합될 것으로 내다봤다. 불과 2년 전까지 이 비율이 한 자릿수에도 못 미쳤다는 점을 감안하면 도입 곡선은 가파르다. 옴디아는 기업용 AI 에이전트 소프트웨어 시장이 2025년 15억 달러에서 2030년 418억 달러로 성장할 것으로 전망했다.

기업 자동화의 모습도 달라지고 있다. 업계에서는 정해진 규칙대로만 움직이던 RPA 봇에서 벗어나, 스스로 추론하고 협상하며 협업하는 다중 에이전트 생태계로 이동하는 중이라고 진단한다. 하나의 거대한 모델이 모든 일을 처리하는 구조가 아니라, 각자 역할과 도구, 권한을 가진 여러 에이전트가 서로 호출하고 결과를 넘기며 업무를 완성하는 구조다. 이 구조가 보편화될수록 개별 에이전트의 성능보다 에이전트들을 어떻게 엮느냐가 시스템 전체의 품질을 좌우하게 된다.

병목은 모델이 아니라 '연결'과 '통제'

에이전트가 늘어날수록 어려워지는 것은 모델 성능이 아니라 시스템 설계다. 다중 에이전트 환경에서는 아키텍처 복잡도가 크게 높아지고, 거버넌스가 없으면 운영 리스크도 함께 커진다. 허가받지 않은 AI 도구가 난립하는 '섀도 AI'처럼, 에이전트가 통제 없이 늘어나는 '에이전트 난립(agent sprawl)'이 컴플라이언스와 보안 위험을 낳을 수 있다는 경고도 나온다.

이 때문에 기업 소프트웨어의 설계 단위가 바뀌고 있다. 단일 기능이나 챗봇이 아니라 거버넌스, 관측 가능성, 통제된 쓰기 권한을 갖춘 오케스트레이션 런타임을 만드는 것이 아키텍처의 새로운 의미가 됐다. 각 에이전트에는 역할과 도구, 권한 경계를 명확히 부여해야 하고, 운영 단계에서도 모니터링, 알림, 디버깅, 지속적 평가 같은 일반 소프트웨어 수준의 체계가 필요하다.

국내 현장도 같은 문제를 겪고 있다. 많은 기업이 AI 에이전트를 도입하고도 데이터와 시스템이 연결되지 않아 PoC 단계에서 멈추고 있다는 지적이다. ERP, CRM, 데이터베이스, 메인프레임 같은 핵심 시스템과 에이전트를 안전하게 잇는 통합 전략이 관건으로 꼽힌다. 모델은 누구나 비슷한 수준으로 빌려 쓸 수 있지만, 자사의 레거시 시스템과 데이터, 업무 규칙에 모델을 안전하게 연결하는 설계는 기업마다 달라 복제하기 어렵다. 경쟁력의 원천이 '어떤 모델을 쓰느냐'에서 '어떻게 연결하고 통제하느냐'로 옮겨가는 이유다.

코딩은 자동화, 설계는 더 중요해진다

소프트웨어 개발 자체도 에이전트의 영향권에 들어왔다. 가트너는 AI 에이전트가 단순 코딩 보조 도구를 넘어 개발과 테스트 작업을 자율적으로 수행하는 '오토파일럿' 역할을 하게 될 것으로 본다. 일부 외신은 가트너 전망을 인용해 향후 3년 안에 많은 조직에서 AI 에이전트가 코드의 대부분을 작성하고, 개발자는 검토 역할로 이동할 것이라고 전했다.

그만큼 사람의 역할은 설계와 검증으로 이동한다. AI가 코드 대부분을 생성할 때 대규모 코드베이스의 시스템 정합성을 어떻게 유지할지에 대한 우려도 함께 제기된다. 컨설팅 업계의 시각도 비슷하다. PwC 보고서를 인용한 한 분석에 따르면 프로덕션 AI 에이전트 배포의 80%는 워크플로 재설계이고 기술은 20%에 불과하며, 아키텍처·오케스트레이션·안정성 엔지니어링 역량의 가치가 높아질 전망이다.

인력 시장에서도 신호가 감지된다. 한 채용 전문 업체는 현업에서 에이전트 AI 시스템을 설계하고 배포해 본 시니어 엔지니어 풀이 매우 제한적이라고 밝혔다. 코드를 짜는 인력은 AI가 보완해 주지만, 에이전트 시스템을 실제로 설계하고 운영해 본 경험은 AI가 대신 쌓아주지 못하기 때문이다.

왜 '쉬워지고 싸질수록' 아키텍처가 중요해지는가

그렇다면 개발이 쉬워지고 싸졌는데도 아키텍처가 더 중요해진다는 주장은 어떤 논리에 기대고 있을까. 전문가들이 제시하는 근거는 크게 여섯 가지로 정리된다.

1. 병목 이동의 법칙: 싸진 자원은 더 많이 쓰이고, 부족한 자원이 가치를 갖는다.

경제학의 기본 원리는 어떤 투입 요소의 가격이 떨어지면 그 요소가 풍부해지고, 대신 여전히 희소한 요소의 상대적 가치가 올라간다는 것이다. 소프트웨어 개발에서 코드 작성은 오랫동안 가장 비싼 공정이었다. 요구사항 정리, 설계, 구현, 테스트 가운데 시간과 인력이 가장 많이 들어간 단계가 구현이었고, 그래서 조직의 의사결정도 '구현 비용을 어떻게 줄일까'에 맞춰져 있었다.

AI가 구현 비용을 크게 낮추면 이 공정은 더 이상 병목이 아니다. 이제 희소한 자원은 '무엇을 만들 것인가', '어떤 구조로 만들 것인가', '만들어진 것이 맞는지 어떻게 확인할 것인가'를 판단하는 능력이다. 이 세 가지는 모두 아키텍처와 시스템 설계의 영역이다. 코드가 풍부해진 만큼 좋은 설계 판단의 상대적 가치가 올라가는 구조다.

2. 소프트웨어의 총량이 늘면 복잡도도 늘어난다.

제본스의 역설로 알려진 현상도 같은 방향을 가리킨다. 어떤 자원의 사용 효율이 높아져 비용이 내려가면 총소비량은 오히려 늘어나는 경우가 많다. 소프트웨어도 마찬가지다. 개발 비용이 내려가면 지금까지 '만들 가치가 없다'고 보류하던 사내 도구, 자동화, 연동, 대시보드가 한꺼번에 만들어진다. 에이전트 하나를 만드는 데 드는 비용이 낮아질수록 부서마다, 업무마다 에이전트가 생긴다.

문제는 이렇게 늘어난 소프트웨어가 서로 독립적으로 존재하지 않는다는 점이다. 시스템 사이의 연결 수는 시스템 수에 비례해서가 아니라 그보다 훨씬 빠르게 늘어난다. 가트너 전망처럼 기업 애플리케이션의 상당수에 에이전트가 들어가면, 에이전트 사이의 호출 관계, 데이터 흐름, 권한 문제가 기하급수적으로 복잡해진다. 개별 부품을 만드는 비용은 낮아졌지만, 부품이 늘어난 만큼 전체를 일관되게 유지하는 비용은 커진다. 이것이 '에이전트 난립'이 새로운 위험으로 거론되는 배경이다.

3. AI는 국소 최적에 강하고, 전체 구조에는 약하다.

AI 코딩 도구는 주어진 맥락 안에서 그럴듯하고 동작하는 코드를 빠르게 만드는 데 강하다. 그러나 수백 개 서비스와 수년간 누적된 설계 결정, 조직의 보안 정책과 규제 요건, 팀 간 책임 경계 같은 '전체 맥락'을 한 번에 파악해 일관된 구조를 유지하는 일은 여전히 사람의 판단에 크게 의존한다. 일부 IT 리더들이 AI 생성 코드가 늘어날 때 대규모 코드베이스의 시스템 정합성을 지키기 어려울 수 있다고 우려하는 것도 이 때문이다.

각각의 변경이 국소적으로는 옳아 보여도, 전체 구조의 원칙 없이 쌓이면 시스템은 점점 일관성을 잃는다. 같은 기능이 서로 다른 방식으로 중복 구현되고, 모듈 경계가 흐려지고, 의존 관계가 얽힌다. 사람이 쓴 코드에서도 늘 있던 문제지만, AI가 코드를 쓰는 속도가 빨라지면 이 문제가 쌓이는 속도도 함께 빨라진다. 결국 아키텍처는 AI가 만들어내는 코드의 홍수 속에서 방향을 잡아 주는 제약 조건이자 가드레일 역할을 하게 된다.

4. 코드를 만드는 속도보다 검증하는 속도가 느리다.

개발이 편해진 만큼 늘어나는 것이 검토해야 할 코드의 양이다. 생성은 빨라졌지만, 그 결과물이 요구사항에 맞는지, 보안 취약점은 없는지, 기존 시스템과 충돌하지 않는지를 확인하는 일은 여전히 사람의 판단과 시간이 필요하다. 개발자가 '작성자'에서 '검토자'로 이동한다는 전망은, 달리 말하면 조직의 처리량이 이제 검증 능력에 의해 결정된다는 뜻이다.

여기서 아키텍처가 결정적인 역할을 한다. 잘 설계된 시스템은 모듈 경계가 분명하고 인터페이스가 명확해서, 변경의 영향 범위를 좁게 한정하고 검증을 자동화하기 쉽다. 반대로 경계가 흐린 시스템에서는 AI가 만든 작은 변경 하나도 어디까지 영향을 미치는지 확인하기 어렵다. 검증 비용을 낮추는 설계, 즉 테스트하기 쉽고 관측하기 쉬운 구조가 AI 시대에는 곧 생산성이 된다.

5. 비결정적인 구성 요소가 시스템 안으로 들어온다.

전통적인 소프트웨어는 같은 입력에 같은 출력을 내는 결정적인 부품으로 이루어져 있었다. AI 에이전트는 다르다. 같은 요청에도 결과가 달라질 수 있고, 때로는 예상하지 못한 행동을 한다. 이런 부품이 기업의 핵심 시스템에 접근해 데이터를 읽고 쓰기 시작하면, 시스템 전체의 안정성을 보장하는 책임이 개별 부품이 아니라 구조 쪽으로 넘어온다.

그래서 에이전트마다 접근할 수 있는 도구와 데이터의 범위를 제한하는 권한 경계, 되돌릴 수 없는 작업 앞에 사람의 승인을 두는 단계, 모든 행동을 추적할 수 있는 감사 로그, 결과를 지속적으로 평가하는 체계가 필수 요소가 된다. 업계가 '컴플라이언스 우선 아키텍처'를 이야기하는 것도 이 때문이다. 부품의 불확실성을 구조로 감싸 시스템 수준의 확실성을 만들어 내는 일, 이것이 AI 소프트웨어 아키텍처의 핵심 과제다.

6. 잘못된 설계의 비용은 더 빨리, 더 크게 쌓인다.

마지막으로 기술 부채의 문제가 있다. 코드를 빠르게 만들 수 있게 되면 잘못된 설계 위에 기능을 쌓는 속도도 빨라진다. 사람이 손으로 코드를 짤 때는 구현이 느린 탓에 자연스럽게 설계를 고민할 시간이 생겼지만, 지금은 그런 완충 장치가 사라졌다. 초기에 구조를 잘못 잡으면 수개월 걸리던 부채가 며칠 만에 쌓일 수 있다.

반대로 구조가 잘 잡혀 있으면 AI의 속도는 곧바로 이득이 된다. 모듈 경계와 규칙이 명확한 시스템에서는 AI가 빠르게 기능을 추가해도 전체가 무너지지 않는다. 같은 AI 도구를 쓰더라도 아키텍처에 투자한 조직과 그렇지 않은 조직의 격차가 시간이 갈수록 벌어질 수 있다는 뜻이다. PwC 분석이 AI 에이전트 도입에서 기술보다 워크플로 재설계의 비중이 압도적으로 크다고 강조한 것도 같은 맥락이다.

달라지는 개발자의 역할과 조직의 과제

이런 논리를 종합하면 개발 조직의 역할 분담도 달라진다. 코드 작성은 점점 에이전트에게 위임되고, 사람은 요구사항을 구조로 번역하는 일, 시스템의 경계와 원칙을 정하는 일, 에이전트의 결과를 평가하고 승인하는 일에 집중하게 된다. 소프트웨어 엔지니어링의 중심이 '구현'에서 '설계와 통제'로 옮겨가는 셈이다.

이는 개발자의 가치가 줄어든다는 뜻이 아니다. 오히려 요구되는 역량의 수준이 한 단계 올라간다는 의미에 가깝다. 어떤 문제를 어떻게 분해하고, 어디에 경계를 그으며, 어떤 실패를 가정하고 대비할지를 판단하는 능력은 AI가 대체하기 가장 어려운 영역이다. 다만 이 역량은 코드를 직접 짜는 경험 속에서 길러져 온 측면이 있어, 입문 단계의 실무 경험이 줄어드는 시대에 설계 감각을 어떻게 키울 것인가는 업계의 새로운 과제로 남는다.

기업에는 세 가지 과제가 주어진다. 첫째, 에이전트를 도입하는 속도만큼 거버넌스와 통합 아키텍처에 투자해야 한다. 둘째, 단일 모델이나 단일 벤더에 종속되지 않도록 여러 모델과 도구를 조율하는 오케스트레이션 계층을 설계해야 한다. 셋째, 조직의 업무 방식과 성과 지표 자체를 사람과 에이전트가 함께 일하는 구조에 맞게 재설계해야 한다.

‘AI-Native 소프트웨어 공학'이 던지는 과제

이런 흐름을 아우르는 개념이 AI-Native 소프트웨어 공학이다. AI 에이전트를 개발 도구이자 시스템의 구성 요소로 전제하고, 설계부터 개발, 운영, 통제까지 전 과정을 다시 짜는 접근이다. 모델과 도구가 몇 달 단위로 바뀌는 환경에서는 에이전트 구성의 버전 관리, 권한과 정책의 코드화, 사람이 개입하는 승인 단계 설계, 지속적 평가가 핵심 요소로 꼽힌다. 설계 문서를 한 번 만들고 끝내는 방식이 아니라, 변화하는 모델과 환경에 맞춰 구조와 통제 방식을 계속 갱신하는 운영 체계가 요구된다는 점에서 기존 개발 방법론과 구분된다.

전문가들은 AI 시대에도 소프트웨어 공학이 사라지는 것이 아니라 한 단계 높은 추상화 수준에서 재편되는 중이라고 본다. 코드를 짜는 속도는 AI가 끌어올리지만, 무엇을 어떤 구조로 만들고 어디까지 맡기며 어떻게 통제할지는 여전히 사람의 몫이다. 개발이 쉬워지고 싸질수록 희소해지는 것은 코드가 아니라 좋은 판단이며, 그 판단이 응축된 결과물이 곧 아키텍처다. 기업이 에이전트 도입 속도만큼 AI 소프트웨어 아키텍처와 거버넌스 역량에 투자해야 하는 이유다.

본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)