안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Navigating the future: Solutions architecture in the age of AI]을 확인해보시기 바랍니다.

Navigating the future: Solutions architecture in the age of AI

AI 시대에 SA(솔루션 아키텍트)가 수행해야 할 새로운 역할과 AI 협업 전략(Centaur 전략), 그리고 이를 위한 가드레일 및 실행 전략에 대해 소개합니다.

1. 센타우르 가설 - 인간+AI의 승리 [01:03 ~ 02:47]

• 실험 결과, ‘인간+AI’ 팀이 슈퍼컴퓨터 단독 팀이나 인간 그랜드마스터 단독 팀보다 항상 더 뛰어난 성과를 냅니다.
• 이는 미래 아키텍트의 모델이 됩니다.

2. 아키텍트의 역할 변화 (What's Changing)

2-1. 선택의 홍수와 아키텍트의 가치

• 선택의 마비: 수많은 아키텍처 옵션 앞에서 인간은 마트 시리얼 코너처럼 선택 장애를 겪거나 익숙한 것을 대충 고르게 됩니다.

2-2. AI의 한계와 아키텍트

• AI는 수백 가지 옵션을 제시할 수 있지만, 사내 정치, CEO의 성향, 과거의 실패 경험과 같은 맥락까지는 학습하지 못합니다.
• 이 지점에서 아키텍트는 AI가 제시한 ‘옵션’을 조직에 맞는 선택으로 바꾸는 역할을 합니다.

2-3. 사고의 파수꾼(Wardens of Thought)

• 아키텍트는 AI가 생성한 수많은 설계안 중 비즈니스 의도와 논리적 타당성을 지키는 판단자(Warden)가 되어야 합니다.
• AI에게 옵션을 묻고, 시뮬레이션(POC)을 실행해 검증하는 것이 주요 업무가 됩니다.

3. 속도와 새로운 문제들 (New Game, New Rules)

3-1. 상품화되는 아키텍처와 속도(Commoditization)

• 압도적 속도: 과거 수개월 걸리던 검색 기능 구현(RAG)이 이제 오후 한나절이면 끝납니다.
• 기술이 상품화되면서 쉬운 결정은 자동화됩니다.

3-2. 전략적 집중

• 쉬운 문제는 AI가 해결하고, 아키텍트는 정해진 답이 없는 어려운 전략적 결정에 집중해야 합니다.
• 속도가 빨라지면 조직은 1개가 아닌 10개의 혁신을 시도하게 됩니다.

4. 불가능했던 문제의 해결 (The Impossible Problems)

4-1. 비결정론적 문제

• 과거에는 불가능했던 ‘비정형 데이터(언어)’ 이해나 ‘페르소나 기반 시뮬레이션’이 가능해집니다.

4-2. 마케팅 포커스 그룹 예시

• 실제 사람을 모으는 대신 AI 페르소나로 마케팅 캠페인을 1차 검증하여 시간과 비용을 획기적으로 줄이는 새로운 아키텍처 패턴이 등장합니다.

5. 아키텍트의 행동 변화 (Shifts in Behavior)

5-1. 1차 미분에 사는 아키텍트(Architects live in the 1st derivative)

• 변화의 율(Rate of Change)에 집중해야 합니다. 그레거 호프의 말처럼, 아키텍트는 시스템이 평온할 때가 아니라 변화(마이그레이션, AI 도입 등)가 일어나는 ‘기울기’ 구간에 존재합니다.

5-2. 거꾸로 일하기(Working Backwards)

• 성공의 핵심 원칙입니다. 제프 베조스 시절(90년대 후반)부터 이어져 온 Amazon과 AWS의 근본적인 운영 방식으로, 실패한 프로젝트는 대부분 이 ‘5가지 질문’ 중 하나를 근본적으로 놓쳤기 때문입니다. 이 질문들은 기술이 아닌 고객 중심으로 구성되며, 고객은 ‘내부’일 수도 있고 ‘외부’일 수도 있지만 중요한 것은 그것이 추상적인 조직이 아니라 의사결정(Yes/No)을 내리는 구체적인 ‘사람’이라는 점입니다.

6. 반응형에서 생산형으로 (Reactive to Productive)

6-1. 철새의 지혜

• 겨울이 오기 전에 미리 움직이는 철새처럼, 장애가 터진 뒤 수습하는 ‘소방관(Reactive)’에서 패턴을 미리 읽고 예방하는 ‘생산적(Productive)’ 아키텍트로 변해야 합니다.

6-2. 화재 예방

• AI를 이용해 아키텍처의 리스크를 미리 쿼리하고, 사고가 나기 전에 방지하는(Fire-proofing) 구조로 전환해야 합니다.

6-3. 계획에서 시뮬레이션으로

• 과거에는 엑셀로 비용과 성능을 추측하다 틀렸지만, 이제는 설계 단계에서 코드를 짜지 않고도 AI로 시뮬레이션을 돌려 결과를 미리 볼 수 있습니다. 아키텍처 문서의 ‘추측’ 섹션은 이제 시뮬레이션 결과 데이터로 대체되어야 합니다.

7. 검토자에서 파수꾼으로 (Reviewer to Sentinel)

7-1. 검문소의 한계

• 분기별 아키텍처 리뷰는 이미 코드가 다 짜인 뒤라 늦습니다.

7-2. 상시 감시

• AI를 활용해 모든 PR(Pull Request)이 아키텍처 원칙을 준수하는지 실시간으로 자동 감시하는 체계로 전환해야 합니다.

8. 기술 부채 청산 (Tech Debt Liquidator)

8-1. 부채의 청산

• 아무도 건드리기 싫어하는 레거시 코드(기술 부채)를 AI(Amazon Q 등)에게 맡겨 최신 언어나 프레임워크로 변환합니다. 이제는 부채를 안고 가는 것이 아니라 털어내는 전략으로 전환합니다.

9. SA로서의 4가지 페르소나

9-1.발명가(The Inventor SA)

• 특징: 새로운 베타 서비스가 나오면 밤새 써보는 탐험가로, AI를 통해 더 많은 실험과 시뮬레이션을 수행합니다.
• 주의점: 실험실에 너무 오래 갇혀 실제 비즈니스 가치를 놓칠 수 있습니다.

9-2.기업가 (The Entrepreneur SA

• 특징: “80%면 충분합니다, 출시하겠습니다!”라고 외치는 행동파로, AI를 활용해 시장 진입 속도를 극대화합니다
• 주의점: 너무 빨리 달려가서 팀원들이 따라오지 못할 수 있어 동료들을 챙기는 과정이 필요합니다.

9-3.작곡가 (The Composer SA)

• 특징: 혼란 속에서 질서와 패턴을 찾아내는 구조화의 달인으로, 복잡한 시스템의 조화를 중시합니다.
• 주의점: 과도한 엔지니어링으로 단순한 문제를 복잡하게 만들 수 있습니다.

9-4.옹호자 (The Advocate SA

• 특징: 기술보다 ‘사람(사용자)’을 먼저 생각하며, 비즈니스와 기술 사이의 통역사 역할을 합니다. AI로 사용자 피드백 데이터를 분석해 공감 능력을 증폭시킵니다.
• 주의점: 너무 많은 이해관계자를 모두 만족시키려다 의사결정이 늦어질 수 있습니다.

10. 결론 및 실행 가이드 (Next Steps) (Action Items)

10-1. 아키텍처 쿼리

• 과거의 결정이 지금도 유효한지 AI에게 물어보고 3년치 비용 시뮬레이션을 돌려볼 것을 권장합니다.

10-2. 시물레이션 생성

• 에이전트형 IDE(예: Amazon Q/CodeCatalyst 등)를 사용하여 코드 작성 전에 POC를 먼저 생성해볼 것을 권장합니다.

10-3. 자동화 하나 하기

• 매주 월요일 아키텍처 규정 위반 사항을 이메일로 보내주는 자동화 스크립트를 하나라도 작성할 것을 제안합니다.