"플래시 세일(flash sale) 중에 DynamoDB가 스로틀링(throttling)되면 어떻게 될까요? 당신의 장바구니 서비스와 카탈로그가 테이블을 공유하고 있습니다. 하나의 핫 파티션(hot partition) 때문에 둘 다 다운됩니다. 폭발 반경(blast radius)은 어느 정도인가요?"

"체크아웃과 풀필먼트(fulfillment) 사이에 SQS를 사용하고 계시군요. 좋습니다. 하지만 데드 레터 큐(dead-letter queue) 전략은 무엇인가요? 메시지가 세 번 실패하면 어디로 가나요? 누구에게 페이지(paged)가 전송되나요?"

"모든 비즈니스 로직에 단일 Lambda 함수를 사용하고 있습니다. 결제 시스템에 수정을 배포해야 할 때 어떤 일이 발생할까요? 카탈로그, 장바구니, 알림 서비스도 함께 재배포하게 됩니다. 롤백(rollback) 시나리오는 어떻게 되나요?"

"알림을 위해 SES를 사용합니다. 하지만 만약 해당 리전의 SES 성능이 저하된다면 어떻게 될까요? 체크아웃이 실패하나요? 아니면 고객이 주문 확인을 늦게 받게 되나요? 만약 당신이 명시적으로 결정하지 않았다면, 시스템이 새벽 2시에 당신 대신 그 결정을 내릴 것입니다."

"트래픽이 10배가 되면 비용이 얼마나 들까요? 0.1배가 되면요?"

코드를 작성하기 전 다섯 가지 질문입니다. 결국 누군가를 새벽 2시에 운영 환경(production)에서 깨우게 될 다섯 가지 아키텍처의 사각지대가 드러났습니다. 이것이 제가 처음으로 Werner Vogels 에이전트에게 시스템 디자인 예시를 검토받았을 때 일어난 일입니다.

아키텍처는 간단했습니다: React 프론트엔드, API Gateway, 비즈니스 로직을 위한 Lambda, 카탈로그와 주문을 위한 DynamoDB, 비동기 처리를 위한 SQS, 알림을 위한 SES. 서비스들은 디커플링(decoupled)되어 있었고, 전반적으로 관리형 인프라(managed infrastructure)를 사용했습니다.

그다음 질문들이 시작되었습니다. 이 문제들은 결국 언젠가는 드러났을 것입니다. 운영 환경에서, 규모가 커졌을 때, 압박이 가해질 때 말이죠. 대신, 이 문제들은 다른 무엇보다 "하지만 어떻게 실패하는가?"라고 묻는 사고 파트너(thinking partner)와의 5분간의 대화 속에서 드러났습니다.

이것이 바로 전문가 어드바이저(Expert Advisor) 에이전트가 당신을 위해 하는 일입니다.

패턴

전문가 어드바이저 에이전트는 누군가의 목소리를 흉내 내는 챗봇이 아닙니다. 그것은 수십 년 동안 다듬어온 멘탈 모델(mental models)을 당신의 문제에 적용하는 사고 파트너입니다.

Werner의 방식이 효과적인 이유는 그의 프레임워크에 이름이 있기 때문입니다. "모든 것은 항상 실패한다(Everything fails all the time)"는 말은 상투적인 문구가 아니라, 폭발 반경(blast radius), 회로 차단기(circuit breakers), 우아한 성능 저하(graceful degradation), 셀 기반 격리(cell-based isolation)와 같은 구체적인 하위 질문들을 포함하는 방법론입니다. 이러한 프레임워크를 에이전트(agent)에 인코딩(encode)하면, 단순히 원칙을 읊는 것이 아니라 당신의 시스템에 이를 적용하는 스파링 파트너를 얻게 됩니다.

모든 이가 어드바이저 에이전트(advisor agent)로서 작동하는 것은 아닙니다. 뛰어난 성능을 보이는 에이전트들은 몇 가지 공통점을 공유합니다.

1. 당사자의 자료가 존재해야 합니다. 그들에 의해 쓰였거나 말해진 것이어야 합니다. 주주 서한, 기조 연설(keynotes), 장문의 인터뷰, 블로그 포스트, 출간된 도서 등이 해당됩니다. 그들에 대한 뉴스 기사는 해당되지 않습니다.
2. 이름이 붙여진, 인코딩 가능한 프레임워크가 있어야 합니다. 일반적인 지혜가 아닌, 하위 질문을 포함하는 반복 가능한 구조여야 합니다. 만약 그들의 방법론을 번호가 매겨진 단계로 적어 내려갈 수 없다면, 유용한 에이전트를 만들어낼 수 없습니다.
3. 독특한 목소리(voice)가 있어야 합니다. 출처를 밝히지 않아도 누구인지 알아볼 수 있어야 합니다. 이 목소리는 에이전트가 일반적인 AI 말투로 흘러가는 것을 방지해 줍니다.
4. 당신이 실제로 내리는 결정과 관련이 있어야 합니다. 만약 어떤 결정을 내리기 전에 그들의 글을 참고하지 않을 것이라면, 그 에이전트를 만들지 마십시오.

Werner는 이 네 가지를 모두 충족합니다. 그의 "실패를 대비한 설계(design for failure)"는 단순한 조언이 아니라 하나의 알고리즘(algorithm)입니다. 의존성(dependency)을 식별하고, 그것을 사용할 수 없을 때 어떤 일이 발생하는지 묻고, 실패가 임계 경로(critical path)에 있는지 아니면 연기될 수 있는지 결정하며, 폭발 반경(blast radius)을 정의하고, 회로 차단기(circuit breaker)를 설계하는 것입니다. 이것은 인코딩이 가능합니다. 이를 통해 당신이 놓치는 것들을 잡아내는 에이전트를 만들 수 있습니다.

Amazon Quick에서 구축하기

제가 이것들을 구축하는 방법은 다음과 같습니다. 프롬프트(prompt) 하나와 몇 분의 시간만 있으면, 반복적으로 개선해 나갈 수 있는 작동 가능한 어드바이저를 가질 수 있습니다.

프롬프트

[NAME]을(를) 위한 전문가 어드바이저 (Expert Advisor) 에이전트를 구축하세요.

1차 자료(first-party accounts)에 집중하세요: 인용구, 인터뷰 내용, 기조 연설(keynotes), 출판된 저작물, 팟캐스트 출연 내용, 그리고 본인의 블로그/소셜 콘텐츠를 활용하세요. 그들에 대한 2차 요약본이나 뉴스 기사에 의존하지 마세요.

목적: [특정 도메인을 설명하세요. 예: "실패 모드, 비용 및 운영 준비 태세에 대한 아키텍처 결정의 압박 테스트(pressure-testing)"]

리서치 단계 (Research phase): 1차 출처 자료를 수집하고 다음 내용을 포함하는 페르소나 브리프(persona brief)를 작성하세요:

• 커뮤니케이션 스타일 (글을 쓰고, 말하고, 농담하는 방식)
• 그들의 목소리로 설명된 핵심 프레임워크 (Core frameworks)
• 주제별로 정리된 주목할 만한 인용구
• 상호작용 패턴 (스토리텔링? 소크라테스식 질문? 비유? 직접적인 도전?)
• 언어 패턴 및 시그니처 문구 (signature phrases)
• 그들이 용납하지 않는 것

그 다음, 다음 내용을 포함하는 시스템 지침(system instructions)으로 에이전트를 구축하세요:

1. 정체성 및 목적 (일반적인 어시스턴트가 아닌 특정 도메인에 특화된 역할)
2. 사고 방식 (단순히 암기하는 것이 아니라 적용할 수 있을 만큼 충분히 상세한 번호가 매겨진 프레임워크)
3. 상호작용 스타일 (사용자와 교감하는 방식)
4. 목소리와 톤 (일반적인 AI와 구별되는 특징)
5. 하지 않을 행동 (생산적인 마찰(productive friction)을 만들어내는 부정적 제약 조건)

환영 메시지, 실제 사용 사례를 반영한 3가지 대화 시작 문구(conversation starters)를 포함하고, 페르소나 리서치 브리프를 참조 파일로 첨부하세요.

• 커뮤니케이션 스타일: 글 쓰는 방식, 말하는 방식, 유머 스타일, 직설적인 정도, 시그니처 문구
• 핵심 프레임워크: 각 이름이 붙은 프레임워크와 그것을 설명하는 직접 인용문, 그리고 어떻게 적용되는지(생성하는 구체적인 하위 질문)를 포함합니다.
• 상호작용 패턴: 먼저 질문하나요? 비유로 시작하나요? 생각 과정을 말하나요? 제안하기 전에 가정을 도전하나요?
• 주제별 주요 인용구: 에이전트가 단순히 의역하는 대신 실제 언어를 가져올 수 있도록 정리합니다.
• 용납하지 않는 것: 그들이 반대하는 구체적인 사항(제약 조건 섹션에 입력됩니다).

저의 Werner 에이전트를 위해, 프레임워크 섹션에는 다음 내용이 포함됩니다: 실패를 위한 설계(design for failure), 플랫폼보다 기본 요소(primitives over platforms), 최적 운영 우수성(operational excellence)을 일급 제약 조건으로, 검소한 아키텍처(frugal architecture), 모범 사례보다 트레이드오프(trade-offs over best practices), 폭발 반경 및 셀 기반 격리(blast radius and cell-based isolation), 그리고 워크로드 우선 사고(workload-first thinking)입니다.

시스템 지침서 (800~1,500 단어, 다섯 섹션):

1. 정체성과 목적: 한 단락. 그들이 누구이며 어떤 도메인을 서비스하는지. 범위를 좁힙니다. Werner는 일반적인 비서가 아닙니다.

음성 및 어조: 일반적인 AI와 차별화되는 점. Werner는 직설적이고, 기술적이며, 호기심이 많다. 건조한 유럽식 유머 감각을 지니고 있다. 때로는 철학적이다. 결코 기업체에서 사용하는 부드러운 말투를 사용하지 않는다. 예를 들어, "프로덕션 환경에서 그런 교훈을 얻는 것은 매우 비싼 방법입니다."와 같은 식이다.

5. 절대 하지 않을 것: 부정적인 제약 사항. Werner는 워크로드를 설명하며 왜 특정 서비스가 적합한지 설명하지 않고 추천하지 않는다. 운영상의 우려 사항들을 대충 넘기지 않는다(hand-wave). 그리고 정답이 하나라고 가장하지도 않는다.

환영 메시지 및 대화 시작점

환영 메시지는 그들이 어떻게 대화를 시작하는지를 반영한다. Werner의 방식은 다음과 같다: "워크로드에 대해 말씀해 주세요. 무엇을 구축하고 계신가요? 누구를 위한 것이며, 제가 알아야 할 제약 사항은 무엇인가요?"

시작점들은 실제 사용 사례이다: "이 아키텍처를 함께 고민해 주세요", "무(zero)에서 어떻게 설계하시겠어요?", "이 시스템 디자인의 문제점은 무엇인가요?"

첫 번째 빌드 이후 반복 개선하기

첫 번째 결과물이 아무리 훌륭하더라도, 다음과 같은 점들을 발견하게 될 것이다:

• 에이전트가 적용해야 하지만 그렇지 않은 프레임워크가 있다 → "사고방식(How they think)" 섹션에 추가한다
• 너무 일반적이거나 동의하는 느낌을 주는 응답이 있다 → "절대 하지 않을 것(What they will NOT do)" 섹션을 강화한다
• 질문 없이 너무 빨리 처방하는 경향이 있다 → 진단 후 처방한다는 내용으로 "상호작용 스타일(Interaction style)"에 더 많은 언어를 추가한다
• 특정 인용구나 예시가 부족하다 → 페르소나 개요 참조 파일(persona brief reference file)을 업데이트한다

이들은 살아있는 문서이다. 에이전트를 사용할수록, 그리고 개선할수록 더욱 날카로워진다.

거울 (The Mirror)

전문 어드바이저를 구축하려면 다른 사람이 어떻게 생각하는지를 연구해야 한다. 그들이 무엇을 생각하는지가 아니라, 어떻게 생각하는지 말이다. 그들은 가장 먼저 어떤 질문을 던지는가? 다른 사람들이 놓치는 것은 무엇인가? 그들은 무엇을 받아들이기를 거부하는가? 그들의 직관 아래에 깔린 구조는 무엇인가?

타인의 멘탈 모델 (Mental Models)을 번호가 매겨진 프레임워크 (Frameworks)와 구체적인 하위 질문들로 해체하고 나면, 당신은 자신의 구조를 인식하기 시작합니다. 당신이 본능적으로 찾는 프레임워크, 자연스럽게 던지는 질문들, 그리고 당신의 머릿속 그 누구도 특정한 질문을 던지지 않기에 지속적으로 놓치게 되는 공백들 말입니다.

에이전트 (Agents)가 그 공백을 채워주지만, 에이전트를 구축하는 행위 자체가 당신에게 그 공백이 존재한다는 사실을 깨닫게 합니다.

Werner 에이전트를 통해 세 번의 아키텍처 리뷰 (Architecture Reviews)를 진행해 보면 한 가지를 깨닫게 될 것입니다. 에이전트는 당신이 놓친 공유 테이블 (Shared-table)의 폭발 반경 (Blast radius), 임계 경로 (Critical path)에 묻혀 있던 강력한 의존성 (Hard dependency), 트래픽이 5배 증가할 때 폭발하는 비용 모델 (Cost model) 등을 잡아냅니다. 하지만 당신의 사고방식을 바꾸는 것은 에이전트의 결과물이 아닙니다. 당신이 결코 본능적으로 "이것이 어떻게 실패하는가?"를 가장 먼저 묻지 않는다는 사실을 깨닫는 것입니다. 당신은 항상 "이것이 어떻게 확장(Scale)되는가?"를 먼저 묻습니다. 이 둘은 서로 다른 사각지대를 가진 서로 다른 질문입니다.

어드바이저 (Advisor)를 구축하는 과정은 당신의 사각지대를 보여줍니다.