[크리스의 SW아키텍처] AI가 코딩하는 시대, 패턴과 스타일은 어떻게 바뀌는가?
코드를 짜는 손이 더 이상 사람만의 것이 아니게 됐다. 그렇다면 그동안 사람의 인지적 한계와 협업의 편의를 전제로 다듬어져 온 소프트웨어 아키텍처의 패턴과 스타일도 당연히 바뀌어야 하는 것 아닐까. 최근 몇 달 사이…
잘게 쪼개던 시절의 끝…'네트워크 세금'이라는 반성문
지난 10여 년간 소프트웨어 아키텍처를 지배한 패턴은 단연 마이크로서비스였다. 하나의 거대한 시스템을 독립적으로 배포 가능한 작은 서비스들로 쪼개면, 팀 간 의존성이 줄고 확장성이 좋아진다는 것이 그 논리였다. 그런데 AI 에이전트가 서로 대화하며 작업을 처리하는 시대가 되자, 이 논리에 금이 가기 시작했다. 에이전트 A가 에이전트 B에게 묻고, B가 다시 C에게 묻는 구조를 전통적인 마이크로서비스로 구현하면 매 호출마다 직렬화와 전송, 역직렬화 과정이 발생한다. 최근 아키텍처 커뮤니티에서는 이렇게 누적되는 지연시간을 '네트워크 세금(Network Tax)'이라 부르며 경계하는 목소리가 커지고 있다. 실시간 응답이 생명인 서비스에서 이 세금은 곧 품질 저하로 이어지기 때문이다.
그 결과 일부 아키텍트들은 레이(Ray) 같은 액터 프레임워크 기반의 '모듈러 모놀리식'으로 회귀하고 있다. 에이전트끼리 방대한 컨텍스트를 네트워크 너머로 복사하는 대신, 같은 프로세스 안에서 메모리 포인터를 주고받는 '제로카피' 방식을 택하는 것이다. 이는 단순한 유행의 반전이 아니다. '무엇이든 잘게 쪼개면 유연해진다'는 지난 10년의 공식이, 에이전트들이 밀리초 단위로 서로를 호출하는 환경에서는 더 이상 성립하지 않을 수 있다는 뼈아픈 자기반성에 가깝다.
계층형 구조에서 오케스트레이션 구조로
패턴의 변화는 서비스 분리 단위에만 그치지 않는다. 기존의 전형적인 3계층(프레젠테이션-비즈니스로직-데이터) 아키텍처는 사람이 화면을 보고, 비즈니스 로직을 거쳐, 데이터베이스에 접근하는 흐름을 전제로 설계됐다. 그러나 AI 에이전트 라이브러리 랭체인(LangChain)이 최근 공식화한 '에이전틱 엔지니어링' 개념에 따르면, 이제 에이전트는 역할과 공유 메모리, 통합된 관측 체계를 가진 '디지털 팀원'으로 개발 파이프라인 안에 편입되고 있다. 이는 정보 검색과 로직 검증, 결과 작성이라는 역할이 서로 다른 여러 에이전트가 협업해 하나의 업무를 완수하는 '멀티 에이전트 오케스트레이션' 구조가 계층형 구조를 대체해가고 있다는 뜻이다.
실제 상용 제품에서도 이런 변화가 확인된다. 협업 소프트웨어 업체 아틀라시안은 지난 9월 지라(Jira)에 '거버넌스가 적용된 에이전트 워크플로' 기능을 추가하며, AI 에이전트가 코드를 작성하고 검토하는 과정 자체를 기업이 정한 규칙 안에서 움직이도록 제한했다. SAP 역시 지난 5월 자사 콘퍼런스에서 224개의 에이전트를 5개 업무 영역에 배치한 '오토노머스 엔터프라이즈' 아키텍처를 선보였다. 이 두 사례가 공통으로 보여주는 것은, 아키텍처의 설계 대상이 더 이상 '사람이 다룰 화면과 데이터'가 아니라 '에이전트가 수행할 역할과 그 역할의 경계'로 옮겨가고 있다는 점이다.
검색해서 답하던 구조에서, 스스로 검증하는 구조로
데이터를 다루는 방식에서도 비슷한 진화가 감지된다. 초기의 검색증강생성(RAG)은 질문을 벡터로 바꿔 유사한 문서를 한 번 찾은 뒤 그 내용을 그대로 답변에 주입하는 단방향 파이프라인이었다. 관련 정보가 검색 결과에 없으면 AI가 그럴듯한 거짓 답변을 만들어내는 이른바 '환각' 문제가 잦았던 이유다. 최근 자리 잡고 있는 '에이전틱 RAG' 구조는 에이전트가 검색 결과를 스스로 평가해, 근거가 부족하면 반복적으로 재검색하거나 문서의 출처와 신뢰도 점수를 답변과 함께 제시하도록 설계된다. 이는 아키텍처의 무게중심이 '얼마나 빨리 정보를 가져오는가'에서 '그 정보가 신뢰할 만한지를 어떻게 검증하는가'로 옮겨가고 있다는 신호이기도 하다.
코드 자체도 다른 속도로 쌓인다…'에이전틱 기술부채'의 등장
패턴과 구조뿐 아니라, 코드가 만들어지고 쌓이는 방식 자체도 달라지고 있다. 코드 분석업체 깃클리어(GitClear)의 최근 조사에 따르면 AI 도구를 적극 활용하는 개발 환경에서는 코드 변경량이 39% 늘었지만, 정작 기술 리더의 75%는 앞으로 1년 안에 AI 지원 개발로 인한 기술부채가 중간 이상 심각한 수준에 이를 것이라고 답했다. 최근 학계에서는 이런 현상을 '에이전틱 기술부채(agentic technical debt)'라는 별도의 개념으로 정식화하기 시작했다. AI 에이전트는 눈앞의 과제를 완수하는 데는 능하지만, 자신이 내린 설계 결정이 6개월 뒤 시스템에 어떤 비용을 지울지는 스스로 모델링하지 않기 때문이다.
이는 필자가 이 지면에서 앞서 제시했던 '기술부채·인지부채·의도부채'라는 세 갈래의 부채 개념과 정확히 맞물린다. AI가 아무리 빠르게 코드를 생성해도, 그 코드 뒤에 있어야 할 '왜 이렇게 설계했는가'라는 의도의 층위를 채워주지는 못한다. 코드는 쌓이는데 의도는 비어 있는 상태, 이것이 지금 여러 기업이 마주한 '에이전틱 기술부채'의 실체다.
결국 남는 질문…패턴이 아니라 '관계'의 설계
여기까지 살펴본 변화들, 즉 마이크로서비스에서 모듈러 모놀리식으로, 계층형 구조에서 에이전트 오케스트레이션으로, 단방향 검색에서 자기검증형 RAG로 넘어가는 흐름은 모두 하나의 질문으로 수렴한다. AI가 코드의 상당 부분을 대신 쓰게 된 지금, 그 코드들 사이의 '관계'를 누가, 어떤 기준으로 설계할 것인가 하는 질문이다.
필자는 최근 이 질문에 대한 답을 '관계부채(relational debt)'라는 개념으로 정리하고 있다. 기술부채가 코드의 품질에서, 인지부채가 그 코드를 이해하는 사람의 부담에서, 의도부채가 설계 결정의 배경이 사라지는 데서 비롯된다면, 관계부채는 여러 에이전트와 사람, 시스템들 사이의 협업 관계 자체가 설계되지 않은 채 방치되는 데서 발생한다. 다비드 힐베르트가 던진 '결정문제(Entscheidungsproblem)'에 앨런 튜링이 계산가능성의 한계와 튜링테스트로 답했던 것처럼, 우리는 지금 "AI가 사람처럼 코드를 짤 수 있는가"라는 질문을 넘어 "AI들의 협업이 사람의 조직처럼 신뢰할 만한 관계를 이룰 수 있는가"라는 새로운 질문 앞에 서 있다. 패턴과 스타일이 아무리 정교하게 진화해도, 그 패턴을 지탱하는 것은 결국 인간 집단이 오랜 시간 쌓아온 사회적 관계지능과 집단 문제해결 능력이라는 사실을, 이번 변화의 흐름은 다시 한번 일깨워주고 있다.
본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)