[크리스의 SW아키텍트] 아키텍트는 '아픈 곳'을 봐야 한다: AI가 옮겨 놓은 트레이드오프 지점

쟁점이 풀리면 기본값이 되고, 주의는 다음 쟁점으로 옮겨 간다. 지금 소프트웨어 아키텍처에서 가장 뜨겁게 부딪치는 세 곳을 따라가 봤다.. — 기술부채, AI Architecture, AI 시대 SW 아키텍처, AI Software Architecture

2017년 구글의 에릭 브루어는 'Spanner, TrueTime and the CAP Theorem'이라는 글을 냈다. 구글이 운영하는 전 지구 규모의 분산 데이터베이스 Spanner가 모든 트랜잭션에 강한 일관성을 제공하면서 동시에 높은 가용성을 유지한다는 내용이다. 분산 시스템을 공부한 사람이라면 고개를 갸웃할 주장이다. 넓은 지역에 걸친 시스템에서는 일관성과 가용성을 함께 얻기 어렵다는 것이 CAP 정리가 일반적으로 받아들여지는 방식이기 때문이다. 브루어는 Spanner가 이 조합을 어떻게 이루는지, 그리고 왜 그것이 CAP과 모순되지 않는지를 설명한다. 열쇠는 구글이 전 세계에 걸쳐 시각을 맞춰 두는 시계 기술 'TrueTime'이다(구글 리서치 논문 초록. 이 기사는 상세 논리까지는 다루지 않는다).

이 사례가 말해 주는 것은 단순하다. 트레이드오프는 쉽게 사라지지 않지만 그 '지점'은 고정되어 있지 않다. 새 기술이 등장하면 어느 쪽을 얼마나 희생해야 하는지의 경계가 이동한다. 그리고 지금, AI가 소프트웨어 품질을 구성하는 속성들의 무게를 바꾸면서 아키텍트들이 부딪히는 지점도 옮겨 가고 있다. 이 글은 그 이동을 이론과 최신 사례로 따라간다.

'트레이드오프 지점'이라는 말

소프트웨어 아키텍처를 평가하는 대표적 방법인 ATAM(Architecture Tradeoff Analysis Method)에는 이 개념이 정식 용어로 들어 있다. 카네기멜런대 소프트웨어공학연구소(SEI)가 개발한 이 방법에서 트레이드오프 지점(tradeoff point)은 '일부 속성은 강화되고 일부는 약화되는 결정 지점'이다. 비슷하게 '민감도 지점(sensitivity point)'은 한 속성에서 작은 변화가 값의 큰 변화를 낳는 곳이다. 아키텍처 평가의 핵심이 이런 지점을 찾아 위험으로 정리하는 데 있다는 뜻이다(ATAM 강의 자료 요약. SEI 원문은 열지 못했다).

실무서도 같은 태도를 보인다. 닐 포드와 마크 리처즈가 2020년 낸 《Fundamentals of Software Architecture》는 모범 사례를 따르는 대신 '모든 결정은 트레이드오프를 수반한다'는 입장에서 '가장 덜 나쁜 해법'을 찾으라고 말한다(Thoughtworks 도서 발표문). 이 책을 두고 흔히 인용되는 '소프트웨어 아키텍처의 제1법칙, 모든 것은 트레이드오프다'라는 문구의 귀속은 이번 취재에서 확인하지 못했다. 그래도 방향은 분명하다. 아키텍트는 정답을 고르는 사람이 아니라 어디서 무엇을 내주는지를 가려내는 사람이다.

쟁점이 풀리면 무슨 일이 일어나는가

여기서 하나의 가설이 선다. 쟁점이 해소된 구조는 사람들이 더는 따져 보지 않고 그대로 쓰는 '기본값(default)'이 된다. 그러면 아키텍트의 주의는 다음 쟁점으로 옮겨 가고, 기술은 그렇게 한 걸음씩 나아간다. 이 가설은 두 가지 이론과 잘 맞는다.

하나는 '지배적 설계(dominant design)' 이론이다. 윌리엄 애버나시와 제임스 어터백에서 비롯된 이 이론에서는 시장이 여러 설계가 경쟁하는 혼란기를 거쳐 하나의 기준 설계로 모이고, 그 뒤 경쟁은 어떤 개념이 이길까에서 얼마나 싸고 빠르게 대규모로 만들 수 있는가로 옮겨 간다(컨설팅사 Umbrex의 요약. 원 연구는 직접 확인하지 못했다). 쟁점이 풀리면 경쟁의 무대가 바뀐다는 말이다.

다른 하나는 클레이턴 크리스텐슨의 '모듈화 보존 법칙'이다. 아직 성능이 충분하지 않은 쪽은 긴밀하게 통합해 최적화해야 하고, 이미 충분해진 쪽은 표준화된 모듈이 되어 그 위의 혁신을 받쳐 준다는 것이다. 개인용 컴퓨터 시대에는 프로세서와 운영체제가 아직 부족했기에 서로 얽혀 있었고, 그 둘을 둘러싼 컴퓨터 제조는 모듈화됐다는 것이 대표 사례다(애스임코 블로그 요약. 요약한 호레이스 데디우는 이 이론이 510년 단위에서 유용하다고 못박았다). 성능이 '충분히 좋아지는' 순간 아키텍처의 경계가 옮겨 간다.

다만 이 가설을 '쟁점이 없는 구조는 그 자체로 우월한 기술'이라고 밀어붙이면 틀린다. Umbrex는 지배적 설계가 기술적으로 최선일 필요는 없다고 분명히 적었다. 생태계와 채택의 흐름이 승패를 가를 수 있다. 또한 CAP처럼 근본적인 상충은 사라지지 않고 위치만 옮겨 갈 뿐이다. 그래서 이 글의 논지는 이렇게 정리한다. 쟁점이 해소된 구조는 기본값이 되고, 아키텍트의 주의는 다음 쟁점으로 옮겨 간다. 이것이 기술 발전의 핵심 동력 중 하나라는 것이지, 유일한 동력이라거나 입증된 법칙이라는 뜻은 아니다.

AI는 품질 모델 자체를 건드렸다

AI 때문에 쟁점이 옮겨 간다는 주장에는 국제 표준 수준의 근거가 있다. ISO/IEC 25010은 소프트웨어 제품 품질을 기능 적합성, 성능 효율성, 신뢰성, 보안성 같은 특성으로 나누는 표준 모델이다. 2023년 발행된 ISO/IEC 25059는 여기에 AI 시스템을 위한 하위 특성을 더했다. 기능 적합성 아래의 Functional Adaptability, 성능 효율성 아래의 Environmental Sustainability, 상호작용 능력 아래의 User Controllability and Transparency, 신뢰성 아래의 Robustness, 보안성 아래의 Intervenability다. 아울러 기존 Functional Correctness의 정의를 고쳤다. 머신러닝을 쓰는 AI 시스템은 '관찰되는 모든 상황에서 기능적 정확성을 제공하지 않는 것이 보통'이기 때문이다(arc42 품질 사이트의 정리).

표준이 이미 '정확성은 항상 보장되지 않는다'를 품질 모델에 넣었다는 사실이 상징적이다. 정확성을 전제로 짜 온 오랜 아키텍처 결정들이 흔들린다. 다만 이것이 어느 지점이 어떻게 옮겨 갔는지를 측정해 보여 주는 것은 아니다. 아래 세 지점은 이 표준의 변화에 최신 사례를 겹쳐 본 필자의 종합이다.

쟁점 1. 생성 속도와 검증·수정 능력

AI가 코드를 만들어 내는 속도는 사람이 검증하고 고치는 속도를 앞질렀다. 이 간극이 가장 먼저 터진 곳이 인프라다. 앤트로픽은 자사 코드베이스의 하루 병합이 5월 약 2,500건에서 9월 3만 건 넘게 늘자 Git 대신 자체 버전관리 시스템 Scion을 만들었다. 코드 이력은 100GB에 가깝고 하루 체크아웃이 약 2,500만 건이라, 표준 Git이라면 하루 600PB가 넘는 다운로드가 필요하다는 설명이다. 앤트로픽은 이전 방식보다 연산과 메모리를 200분의 1로 줄였다고 밝혔다(주간 AI 뉴스 요약 매체가 전한 앤트로픽 엔지니어링 블로그 내용. 원문은 직접 확인하지 못했다). 버전관리가 '사람이 하루에 몇 번 합치는 규모'를 전제로 설계됐다는 사실이 드러난 것이다.

더 어려운 것은 사람의 검증이다. 올해 8월 공개된 사례 연구에서 Claude Code는 20년 넘은 Visual Basic 6 ERP의 12개 기능을 .NET으로 약 1시간에 옮겼다. 비용은 50달러 남짓이었지만, 업무 규칙과 DB 연산 331개 중 70%만 원래와 같게 동작했다. 복잡도가 높은 기능은 47%였다(arXiv 2608.28972). 생성은 값싸고 빠른데 '같다'를 확인하는 일은 여전히 사람의 판단과 시간을 먹는다.

공개된 오픈소스 현장도 비슷하다. PostgreSQL 커미터 페터 아이젠트라우트는 LLM을 쓴 코드 리뷰가 많은 버그를 더 빨리 찾아냈지만 대신 주요 기능 810개가 미뤄졌다고 전했다. curl 프로젝트는 쏟아지는 보고 때문에 10월 26일부터 낮음·중간 심각도 보고서를 공개하기로 했다(SecurityToday). 보안 쪽에서는 노마 시큐리티의 크리스 휴스가 "AI는 취약점 발견을 산업화했지만 수정은 여전히 인간이 병목"이라고 짚었다(블록미디어 번역 인용). 라피드7은 중대 취약점이 공개된 뒤 악용되기까지 평균 3일이라는 3분기 수치를 내놨다.

이 쟁점에서 아키텍트가 부딪히는 질문은 이렇다. 검증 장치는 생성 속도에 맞춰 어디에 두는가. 앤트로픽의 사내 분석(2차 보도)에서는 에이전트가 쓴 코드와 사람이 쓴 코드의 되돌림(revert) 비율이 같았다고 하는데, 그렇다면 '누가 썼는가'가 아니라 '무엇으로 검증했는가'가 품질을 가른다는 얘기가 된다. 이 수치는 원 보고서를 직접 보지 못해 참고로만 적는다.

쟁점 2. 품질과 토큰 비용·지연

예전의 자원 쟁점은 CPU와 메모리였다. 이제는 토큰이 자원이다. 한 모델 동향 정리 글(Artificial Analysis 지수 인용)에 따르면 Claude Sonnet 5.5는 지수 과제 하나를 푸는 비용이 '높음' 노력 수준에서 1.08달러, '최대' 노력 수준에서 7.60달러였다. 같은 모델이 일을 얼마나 오래 생각하게 하느냐에 따라 비용이 7배 남짓 벌어진다는 뜻이다(두 수준에서의 품질 점수 차이는 그 글에 없었다). 가격 구조도 단순하지 않다. 구글의 Gemini 4 Argon은 입력 100만 토큰당 2달러·출력 10달러로 출시됐지만 12월 1일 4달러·20달러로 오르고(Local AI Zone), 캐시된 입력은 95% 할인된다(AI Weekly). OpenAI는 DevDay에서 응답 속도를 높인 Ultrafast 모드와 월 500달러짜리 Pro 500 요금제를 내놓았다(Local AI Zone). 품질, 속도, 비용이 요금표에 그대로 얹힌 것이다. 이 요금과 지수 수치는 모두 2차 정리 글이라 원 자료로 확인이 필요하다.

비용이 어디서 나오는지도 의외다. 앞선 VB6 이전 실험에서 토큰의 99.6%는 에이전트가 낡은 코드를 읽는 입력이었다. 기능당 평균 4.19달러인 비용은 새로 쓴 코드의 양이 아니라 읽은 코드의 양에 비례했다. 그래서 '읽는 양'을 줄이는 설계, 즉 에이전트가 필요한 부분만 정확히 읽게 하는 구조가 곧 비용 설계가 된다. Moderne처럼 미리 검증된 변환 규칙 3,500여 개를 에이전트가 도구로 부르게 하는 방식은 생성 자체를 줄여 비용과 위험을 함께 낮추려는 시도다(FINOS 블로그, 2025). 표준 쪽에서도 ISO 25059가 성능 효율성 아래에 Environmental Sustainability를 새로 넣었다. 자원 쟁점은 사라진 것이 아니라 토큰과 에너지라는 새 얼굴로 돌아왔다.

쟁점 3. 컨텍스트와 모듈 경계

세 번째 지점이 아키텍트에게 가장 낯익으면서도 가장 새롭다. 에이전트가 한 번에 붙들 수 있는 정보에 한계가 있기 때문이다. 코드 그래프 기업 Blitzy의 엔지니어링 디렉터는 에이전트의 유효 컨텍스트가 20만30만 토큰, 코드로는 2만3만 줄 정도이고 1억 줄 코드베이스에서는 정보 손실이 일어난다고 설명했다(SiliconANGLE, 9월 28일). 이 말은 '시스템을 에이전트가 한 번에 이해할 수 있는 크기로 쪼개는 일'이 설계의 일급 과제가 됐다는 뜻이다. 앞선 기사에서 다룬 Context Isolation이다.

VB6 실험은 이를 숫자로 보여 준다. 틀린 100건 중 42건은 기능의 가장자리, 곧 인접 모듈의 알림·불러오기·보고서 로직을 빠뜨린 것이었다. 규칙이 여러 파일에 흩어진 경우(특히 폼 이벤트)에는 자주 놓쳤고, 반대로 규칙이 잘 정의된 도메인 클래스 안에 모여 있을 때는 훨씬 잘 옮겼다. 경계가 선명한 코드는 AI에게도 이해하기 쉬웠다는 증거다(저자들이 보고한 결과이며 한 조직, 한 모델 사례다). 가트너도 올해 5월 하이프 사이클에서 생성형 AI 프로젝트의 최소 절반이 '잘못된 아키텍처 선택과 운영 노하우 부족' 때문에 예산을 넘길 것이라고 전망했다(The Register 보도).

여기에는 숨은 상충이 하나 더 있다. 결정적이고 재현 가능한 변환과 유연하게 적응하는 생성 사이의 긴장이다. ISO 25059가 Functional Adaptability를 새 하위 특성으로 넣은 것은 AI가 상황에 따라 기능을 바꿔 가는 능력을 품질로 인정했다는 뜻이고, 동시에 같은 입력에 같은 결과를 내야 하는 재현성이 그만큼 어려워졌다는 뜻이기도 하다.

그래서 아키텍트는 무엇을 하는가

사례들을 이어 보면 하나의 그림이 나온다. 쟁점은 대개 '아픈 곳'에서 드러난다. 병합이 터지는 곳, 검증이 막히는 곳, 비용이 새는 곳, 에이전트가 경계 밖 규칙을 놓치는 곳이다. 아키텍트가 트레이드오프 지점에 늘 집중해야 한다는 말은, 이 아픈 곳을 일찍 찾고 어느 쪽을 얼마나 내줄지를 근거와 함께 남기라는 뜻이다. ATAM이 시나리오와 우선순위, 위험 정리를 요구하고, 설계 결정을 Architecture Decision Record(ADR)로 기록하는 관행이 널리 쓰이는 까닭도 여기에 있다.

한 가지 덧붙이자면 풀린 쟁점을 매번 다시 열 필요는 없다. 기본값이 된 구조는 그대로 쓰고, 한정된 주의를 아직 아픈 곳에 쓰는 것이 아키텍트의 경제학이다. 같은 이유로 지금 아픈 곳에서 어떤 구조가 앞으로 기본값이 될지가 다음 세대 아키텍처를 가른다.

앞으로: 무엇이 다음 기본값이 될까

아래는 필자의 전망이다. 첫째, 검증 장치가 설계의 기본 요소가 될 가능성이 크다. 생성이 값싸질수록 '같다'를 증명하는 평가 체계(Evaluation Harness)와 되돌릴 수 있는 배포 구조가 시스템의 표준 부품이 될 것이다. 둘째, 시스템 경계가 사람의 이해 단위에서 에이전트의 컨텍스트 단위까지 함께 고려해 그어질 것이다. 명확한 모듈 경계와 계약은 에이전트가 일하는 비용과 정확도를 좌우하는 자산이 된다. 셋째, 모델과 노력 수준을 과제에 맞춰 고르는 라우팅이 비용 설계의 기본값이 될 것이다. 모델 가격과 성능이 수시로 바뀌는 환경에서는 특정 모델에 묶이지 않는 구조가 쟁점을 한 번 덜어 준다.

물론 이 전망은 틀릴 수 있다. 크리스텐슨 이론이 510년 단위에서 유용하다고 했듯, 몇 달 안에 쟁점이 다른 곳으로 튈 수도 있다. 그래서 아키텍트에게 필요한 것은 정답이 아니라, 다음 쟁점이 어디서 터지는지를 알아채는 감각과 그 판단을 기록하는 습관이다.

관련 태그: #기술부채 #AI Architecture #AI 시대 SW 아키텍처 #AI Software Architecture #AI SW 아키텍처 #SW아키텍트 #Software Engineering #아키텍처 #아키텍처 트레이드오프 #아키텍처설계 #AI 에이전트 소프트웨어 아키텍처 #AI 에이전트 비용 최적화 #AI 아키텍처 #AI Software #AI-Native 소프트웨어 설계 #AI-Native 소프트웨어 아키텍처 #AI-Native Architecture #트레이드오프 #Trade-off Point #아키텍트 역할 #품질속성 #품질 속성 트레이드오프 #ATAM

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