엔지니어들이 아키텍처상의 장단점을 평가할 수 있도록 시스템 설계 카타를 구축하는 방법

한 팀이 지역 축제 티켓 예매 서비스를 설계했습니다. 예상 부하를 무리 없이 처리했고, 설계 검토는 모두 긍정적인 반응으로 마무리되었습니다. 그런데 갑자기 요구 사항이 바뀌었습니다. 주최측은 티켓 판매 기간 동안 데이터 센터 하나가 다운되더라도 티켓 판매가 계속되어야 한다고 요구했습니다. 이제 동일한 설계에 단일 장애 지점이 생겼고, 설계를 담당했던 엔지니어들은 무엇을 변경하고 무엇을 포기해야 할지, 그리고 그 결정을 어떻게 설명해야 할지 고민해야 합니다.

이것은 예시 시나리오일 뿐, 실제로 발생한 사건은 아닙니다. 시스템 설계 카타는 바로 이러한 상황을 연습하기 위해 만들어졌습니다. 한 가지 제약 조건에서는 문제가 없었던 설계가 새로운 제약 조건에 직면했을 때, 엔지니어들은 그 설계를 옹호하거나 수정해야 하며, 그 이유를 설명해야 합니다. 이 가이드는 엔지니어링 지원 리더와 엔지니어링 관리자를 위한 것입니다. 시스템 설계 카타가 무엇인지, 어떻게 구성하고, 실행하고 평가하는지, 그리고 교육만으로는 충분하지 않은 시점까지를 다룹니다. 모든 사례와 평가 기준은 사용하기 전에 선임 엔지니어의 검증을 받아야 합니다.

시스템 설계 카타란 무엇인가요?

시스템 설계 카타는 짧은 시간 제한이 있는 설계 연습입니다. 소규모 팀이 한 단락으로 된 비즈니스 문제를 받고, 아키텍처를 구상한 후 동료들에게 발표하고 어려운 질문에 답합니다. 검색 엔진에서는 이를 아키텍처 카타 또는 아키텍처 설계 카타라고 부르기도 합니다. 이 형식은 테드 뉴어드가 워크숍 형태로 시작했으며, 규칙과 진행자 역할 등이 문서화되어 있습니다. Neal Ford의 건축 카타 페이지뉴어드의 핵심 질문은 엔지니어들이 경력 동안 아키텍처 설계를 할 기회가 여섯 번도 채 되지 않는 상황에서 조직이 어떻게 훌륭한 아키텍트를 육성할 수 있느냐는 것이었습니다. 카타는 실무 위험 없이 엔지니어들에게 추가적인 반복 연습 기회를 제공합니다.

빠른 사실

1. 성능 문제를 설명하세요

주제가 아니라 과제부터 시작하세요. 과제는 변화하는 제약 조건 속에서 아키텍처를 옹호하는 것입니다. 실제 업무에서는 설계 검토, 사고 후속 조치, 계획 회의 등에서 요구 사항이 변경될 때 이러한 상황이 발생합니다. 예를 들어 트래픽 증가, 더욱 엄격해진 가용성 보장, 새로운 데이터 상주 규칙, 빠듯한 예산 등이 있습니다.

많은 엔지니어들이 합리적인 아키텍처를 설계할 수 있습니다. 하지만 두 가지 목표가 충돌할 때 무엇을 포기해야 할지, 그리고 어떤 증거가 자신의 생각을 바꿀지 설명할 수 있는 엔지니어는 드뭅니다. 카타는 바로 이러한 두 번째 능력을 연습하는 훈련입니다.

한 문장으로 된 성과 평가문을 작성하고 엔지니어링 관리자에게 확인을 받으세요. 평가문의 내용은 다음과 같습니다. "주어진 아키텍처와 변경된 제약 조건에서 엔지니어는 어떤 부분이 제대로 작동하지 않는지 파악하고, 변경 사항을 제안하고, 그에 따른 장단점을 설명하며, 아직 알지 못하는 부분을 밝힙니다."

2. 학습 및 맥락 격차를 진단합니다.

무엇을 만들기 전에, 해당 작업을 현재 프로그램에서 연습하고 평가하는 내용과 비교해 보세요.

1. 실습은 실제 과제를 활용하나요? 훈련에서 패턴만 개별적으로 가르치고 평가가 객관식 시험으로 이루어진다면, 아무도 자신의 선택을 옹호하는 연습을 하지 못하게 됩니다.
2. 인지적 요구 사항은 무엇입니까? 블룸의 수정된 분류 체계에서 제약 조건과 여러 선택지를 비교하는 것은 분석 및 평가 단계에 해당하며, 수정된 디자인을 제안하는 것은 창조 단계에 해당합니다. 이 가이드는 다음과 같습니다. 학습 활동을 블룸의 분류 체계에 맞추기 활동을 해당 수준에 맞추는 방법을 보여줍니다.
3. 기술 외에 다른 요소가 방해가 되는 건가요? 엔지니어들이 설계할 시간이 있는지, 아키텍처 결정에 대한 책임자가 있는지, 요구사항이 문서화되어 있는지 확인하십시오. 팀 외부 사람이 결정을 내린다면, 어떤 카타도 팀의 역량을 바꿀 수 없습니다. 이러한 문제의 원인을 해결할 수 있는 사람에게 전달하십시오.

3. 설계 준비 및 실습

각 단계에 명확한 역할을 부여하세요.

예비. 간단한 진단으로 사전 요구 사항을 확인하세요. 팀에서 사용하는 용어(가용성, 일관성, 지연 시간, 비용), 팀원들이 알아야 할 기본 요소, 그리고 자체 설계 검토 템플릿을 살펴보세요. 이 단계에서는 자기 주도 학습이 적합하며, 복습 점검을 통해 사전 요구 사항 충족 여부만 확인할 수 있습니다.

연습. 카타 자체를 실행해 보세요. 닐 포드의 웹사이트에 설명된 형식대로, 팀이 구성된 후 연습은 세 단계로 진행됩니다. 첫 번째는 팀이 무엇을 만들지 논의하는 단계이고, 두 번째는 각 팀이 발표하고 질문에 답하는 동료 평가 단계이며, 세 번째는 동료들이 엄지손가락을 위로("완벽하게 해냈다"), 엄지손가락을 위로("몇 가지를 놓쳤다"), 또는 아래로("심각하게 놓쳤다") 투표하는 단계입니다. 몇 가지 규칙은 그대로 차용할 만합니다. 팀은 익숙하지 않은 기술에 대해 가정을 할 수 있지만 반드시 명시해야 하며, 모든 분야의 전문가로 구성된 팀을 고용할 수 있다고 가정해서는 안 됩니다.

변경 제약 조건을 추가합니다. 표준 카타는 고정된 문제를 제시합니다. 이 가이드에서 해당 기술을 훈련하려면 중간에 두 번째 카드를 추가하세요. 팀이 수용해야 하는 변경된 제약 조건입니다. 이는 원래 규칙의 일부가 아닌 저희의 설계 선택이므로 시범적으로 사용해 보시기 바랍니다.

피드백. 피드백은 총점이 아닌 결정 사항과 연결해야 합니다. "두 지역으로 이전하셨는데, 이전 과정에서 발생한 주문 건에 대해서는 언급하지 않으셨네요."와 같은 피드백이 "5점 만점에 3점"보다 훨씬 유용합니다.

실시간 입력 방식인가요, 아니면 비동기식 검토 방식인가요? 실시간 진행은 선택이 모호할 때 가장 효과적이며, 엔지니어는 선임 동료의 설명을 통해 왜 그 방향을 고수해야 하는지 배울 수 있습니다. 비동기식 검토는 서면으로 작성된 근거와 주석이 달린 예시를 비교하는 데 충분합니다.

4. 현실적인 예를 통해 살펴보세요

예시일 뿐입니다. 사용 전에 선임 엔지니어가 사례와 답변 기준을 검증해야 합니다.

경우. 지역 축제에서 주말 동안 2만 장의 티켓이 판매되는데, 대부분의 판매는 처음 10분 안에 이루어집니다. 초기 기획안에서는 이러한 최고 판매량을 처리할 수 있는 예매 시스템을 요구했습니다. 디자인은 단일 웹 계층, 단일 데이터베이스, 결제 시 결제 서비스 제공업체 호출로 구성됩니다.

변경된 제약 조건. 주최측은 중간쯤에 다음과 같은 내용을 덧붙였습니다. 데이터 센터 중 하나가 오프라인 상태가 되더라도 티켓 판매는 계속되어야 하며, 같은 티켓을 두 번 판매할 수 없습니다.

첫 시도입니다. "두 번째 데이터 센터를 추가하고 데이터베이스를 복제하세요." 팀은 익숙한 구성 요소를 언급했지만, 두 사이트가 서로 통신할 수 없을 때 이중 판매 방지 규칙이 어떻게 되는지에 대해서는 설명하지 않았습니다.

피드백 후 다시 시도하세요. 진행자는 팀에게 상충되는 두 가지 목표를 명시하고 네트워크 분할 시 어느 목표를 보호할지 묻습니다. 재시도 단계에서는 팀에게 선택을 요청하고 고객이 어떤 경험을 하게 될지 설명하도록 합니다.

좀 더 나은 시도였습니다. "저희는 중복 판매 금지 규칙을 준수할 것입니다. 판매처가 나뉘는 경우, 주 판매처에서만 티켓을 판매하고 다른 판매처에서는 대기 페이지를 표시합니다. 동일 좌석의 중복 판매를 방지하기 위해 짧은 시간 동안 좌석 공급량이 줄어드는 것을 감수합니다. 판매처가 나뉘는 경우는 드물고 시간도 짧을 것으로 예상하며, 주최측에서 대기 페이지 표시가 허용되는지 확인해 주시기 바랍니다. 만약 두 판매처 모두에서 판매해야 하는 경우, 일부 좌석이 판매되지 않더라도 각 판매처에 별도의 좌석 블록을 사전에 할당할 것입니다." 이 답변은 갈등 상황을 명확히 제시하고, 어느 쪽 입장을 취하며, 예상되는 비용을 명시하고, 알지 못하는 부분도 밝히고 있습니다.

각 답변이 타당한지 또는 불완전한지 판단하는 이유. 각 설계안은 검토자의 개인적인 선호도가 아닌, 승인된 기준에 따라 평가해야 합니다. 첫 번째 시도는 구성 요소를 명시했지만, 그에 따른 장단점을 제시하지 못했습니다. 더 나은 시도는 구체적이고, 전제 조건을 명확히 밝히며, 대안과 그에 따른 비용을 제시합니다.

5. 역량을 평가하고 이전 계획을 수립합니다.

능력의 증거는 엔지니어가 이전에 접해보지 못한 새로운 사례에 대한 수행 능력입니다. 절충안 도출 과정과 새로운 제약 조건에 대한 대응을 평가합니다. 간단한 평가 기준표는 각 항목당 0에서 2까지의 척도를 사용합니다.

평가 기준: 0은 해당 사항이 없거나 근거가 부족함을 나타내고, 1은 관련 내용이 누락된 부분적인 충족을 나타내며, 2는 합의된 기준에 따라 완벽하고 타당성을 입증함을 나타냅니다. 명시된 안전 또는 데이터 보호 요구 사항을 무시하는 것과 같은 중요한 오류는 별도로 정의하여 전체 점수에서 이러한 오류가 드러나지 않도록 해야 합니다. 이 평가 기준표는 제안 사항일 뿐 검증된 준비 표준이 아니므로 엔지니어링 관리자와 협의하여 수정하고 시범 운영해 보십시오. 저희 가이드를 참조하십시오. 유용한 피드백을 제공하는 상호작용적 연습 설계 의사 결정과 연계된 피드백 작성 방법을 다룹니다.

의도적인 계획 이전을 실시하세요. 카타(실전 연습) 후, 각 엔지니어에게 실제 설계 결정 사항 하나를 검토에 가져와 동일한 질문을 적용하도록 요청하세요. 과거 사건에 대한 비난 없는 검토 또한 실제 업무로 나아가는 좋은 연결 고리가 될 수 있습니다. 관련 가이드를 참조하세요. 무과실 사건 검토 실행.

상호작용적 전달이 도움이 되는 경우

상호작용형 형식은 모든 구성원이 그룹 토론 전에 의견을 제시하고 결정을 내릴 수 있도록 도와줍니다. 라이브 카타 세션에서 진행자는 변경된 제약 조건을 보여주고, 각 팀원에게 어떤 절충안을 선택하고 그 이유를 입력하도록 요청한 다음, 토론 시작 전에 결과를 공개할 수 있습니다. 기존 형식의 마지막에 진행되는 동료 투표도 같은 방식으로 쉽게 진행할 수 있습니다. 동일한 사례를 자기 주도 학습 방식으로 진행하여 세션 준비를 하거나 세션에 참석하지 못한 엔지니어를 지원할 수도 있습니다. AhaSlides는 상호작용형 학습을 지원하며 라이브 및 자기 주도 학습 방식 간의 전환을 용이하게 합니다. AhaSlides는 프레젠테이션 및 학습 도구이지 아키텍처를 그리거나 실행하는 곳이 아니므로 다이어그램은 화이트보드나 디자인 도구를 사용하세요. 사용하려는 특정 작성, 피드백 또는 보고 기능이 기존 워크플로와 잘 맞는지 확인하십시오. 형식 선택에 대한 자세한 내용은 관련 문서를 참조하세요. 적응형 학습, 상호작용형 학습, 실시간 학습은 언제 사용해야 할까요?.

변화된 것을 측정하세요

변화하는 제약 조건 속에서 엔지니어가 아키텍처를 옹호할 수 있음을 보여줄 수 있는 사례를 사전에 결정하십시오. 프로그램 시작 전 기준선과 비교하여 미지의 사례에 대한 절충안 도출 과정을 분석하십시오. 참여 대상, 분모 및 시기를 명확히 정의하십시오. 결과가 개선되었다면, 교육의 효과를 인정하기 전에 새로운 설계 검토 템플릿 도입, 인력 변동 또는 주목을 끈 사건 발생 등 동일 기간 동안 발생한 다른 변화들을 함께 고려하십시오.

남아 있을 수 있는 제약 조건

• 디자인 전문가. 팀이 결정을 내리지 않으면, 연습을 하는 것은 효과가 미미하다.
• 시각. 카타를 완성하는 데는 몇 시간이 걸리지만, 실제 설계에는 몇 주가 걸리고 카타에서 제공할 수 없는 데이터가 필요합니다.
• 사건 처리 범위. 한 사례에서는 몇 가지 절충안이 필요합니다. 점수만으로는 엔지니어의 판단력을 전반적으로 설명할 수 없습니다.
• 복잡성. 더 복잡한 구조가 반드시 더 나은 아키텍처는 아니므로, 구성 요소가 가장 많다고 해서 무조건 좋은 것은 아닙니다.
• 이전. 워크숍에서 잘하는 것과 긴장된 상황에서의 실전 평가에서 잘하는 것은 다르므로, 카타 후에 실제 상황에서 수행 능력을 점검하십시오.

스폰서에게 이러한 사항들을 미리 알리고 별도의 수정 계획을 세우세요. 카타는 엔지니어가 설명하고 옹호할 수 있는 능력을 향상시켜 줍니다. 하지만 카타가 권위나 시간을 만들어 주는 것은 아닙니다.

자주하는 질문

시스템 설계 카타란 무엇인가요?

제한된 시간 내에 소규모 팀이 비즈니스 문제에 대한 아키텍처를 구상하고, 동료들에게 발표하며, 까다로운 질문에 답하는 디자인 연습입니다. 아키텍처 카타라고도 합니다.

팀에는 몇 명이 있어야 할까요?

원래 형식은 3~5명으로 구성된 소규모 그룹을 사용하며, 일반적으로 한 방에 있는 4~10개 그룹 중 하나로 구성됩니다. 모든 구성원이 발언할 수 있도록 그룹 규모를 충분히 작게 유지해야 합니다.

시스템 설계 카타를 어떻게 평가하나요?

새로운 사례를 제시하고, 합의된 기준에 따라 변경된 제약 조건에 대한 대응과 절충 논리를 설명하십시오. 동료 평가는 유용한 피드백이지만, 그 자체로 점수가 될 수는 없습니다.

어디서 시작하나요

조직 내에서 반복적으로 발생하는 설계 결정 사항 하나를 선택하고, 이를 중심으로 한 단락 분량의 사례 연구를 작성하세요. 변경된 제약 조건을 추가하고, 엔지니어링 관리자에게 사례 연구와 답변 기준을 검증받으세요. 그런 다음, 주요 오류 목록이 포함된 3가지 기준의 평가표를 작성하세요. 전체 적용 전에 한 팀에서 시범 운영해 보세요.

팀원들과 함께 실제 실습을 진행하고, 이후에도 자율 학습 방식으로 재사용하는 방법을 알아보려면 AhaSlides를 살펴보세요.