AWS 인프라 구성도 실무 가이드 (Part 3): draw.io를 열기 전에 — Architecture Brief와 7단계

Part 1에서 아이콘 수프를 진단했고, Part 2에서 여섯 장으로 나눴다. 이제 실제로 그릴 차례다.

그런데 이 글의 절반이 지나갈 때까지 draw.io는 열지 않는다.

툴을 먼저 열면 왜 지는가

신입에게 "이 사업 구성도 좀 그려주세요"라고 했을 때 벌어지는 일을 1부에서 봤다. 그 현상을 조금 더 정확하게 뜯어보면 이렇다.

draw.io를 열면 왼쪽에 AWS 도형 라이브러리가 뜬다. 거기에는 수백 개의 아이콘이 카테고리별로 정렬돼 있다. Compute, Storage, Database, Networking, Analytics, Machine Learning. 이 화면을 보는 순간 뇌가 하는 일은 정해져 있다.

"이 중에서 뭘 쓸까?"

이건 잘못된 질문이다. 올바른 질문은 이것이다.

"이 사업은 무엇을 해결해야 하는가?"

두 질문의 차이가 결과를 가른다. 첫 번째 질문에서 출발하면 선택지 목록이 사고의 범위를 정해버린다. 고객의 문제가 무엇이든, 결론은 늘 익숙한 조합 — CloudFront → WAF → API Gateway → Lambda → DynamoDB — 근처에서 나온다. 그 조합이 틀려서가 아니라, 그 조합이 검토된 것이 아니라 기본값으로 선택됐기 때문에 문제다.

제안 평가에서 이건 티가 난다. "왜 Lambda를 쓰셨나요?"라는 질문에 "서버리스라 운영 부담이 적습니다" 같은 일반론으로 답하는 순간, 평가위원은 이 팀이 자기 사업을 개별적으로 검토하지 않았다는 걸 안다.

그래서 코어닷투데이에는 규칙이 하나 있다.

그림의 목적을 한 문장으로 쓰기 전에는 툴을 열지 않는다.

그리고 그 한 문장을 쓰기 위해 먼저 채우는 표가 있다.

Architecture Brief — 그리기 전에 채우는 한 장

Architecture Brief는 16개 항목짜리 한 장 요약표다. 이걸 채우는 데 보통 30분에서 두 시간이 걸린다. 그리고 이 시간이 구성도를 두 번 세 번 다시 그리는 시간을 아껴준다.

K광역시의회 사업으로 실제로 채우면 이렇게 된다.

이 표에서 신입이 가장 자주 비워두는 칸은 마지막 두 개다. 가정과 대안.

가정을 적지 않으면 설계가 틀렸을 때 누구 책임인지 알 수 없다. "회의록 DB 스키마가 안 바뀐다"는 전제가 문서에 적혀 있으면, 그게 바뀌었을 때 변경 관리 대상이 된다. 적혀 있지 않으면 그냥 우리가 잘못 만든 게 된다.

대안을 적지 않으면 검토한 것과 검토하지 않은 것이 구분되지 않는다. 멀티리전 Active-Active를 검토했으나 예산 제약으로 미채택이라고 적힌 제안서와, 그냥 단일 리전으로 그려진 제안서는 전혀 다르게 읽힌다. 전자는 판단을 한 것이고 후자는 모르는 것이다.

그리고 이 한 문장

Brief를 다 채웠으면 마지막으로 이 문장을 완성한다.

이 그림은 누구에게, 무엇을 설명하고, 어떤 결정을 받기 위한 그림이다.

K광역시의회 사업 3장(AWS 배포·네트워크 구성도)이라면 이렇게 된다.

이 그림은 사무처 정보화담당관과 보안담당자에게, 개인정보가 인터넷을 경유하지 않고 처리되며 정기회 트래픽에 자동 확장으로 대응한다는 것을 설명하고, 목표 아키텍처 승인을 받기 위한 그림이다.

이 문장을 쓰지 못하면 그림을 시작하지 않는다. 못 쓴다는 것은 아직 뭘 그려야 할지 모른다는 뜻이고, 모르는 채로 그린 그림은 반드시 아이콘 수프가 된다.

1단계. 아이콘 없이 기능 블록부터 그린다

이제 그리기 시작한다. 다만 첫 그림에는 AWS 서비스명이 하나도 등장하지 않는다.

이 단계에서 하는 일은 딱 하나다. 필요한 기능을 빠짐없이 나열하고 계층으로 묶는 것.

여기서 수집 스케줄러, 크롤러·OCR, 문서 정규화, 중복 제거, 엔티티·사건 추출 같은 블록이 나온다. 이건 요구사항에서 직접 나오는 것들이지 AWS를 알아야 나오는 것이 아니다. 반대로 이 단계를 건너뛰면, 나중에 "OCR은 어디서 하죠?" 같은 질문이 구성도가 다 완성된 뒤에 나온다.

우측의 공통 보안·운영 세로 스트립도 이 단계에서 세워둔다. 이건 특정 계층에 속하지 않고 전 계층을 가로지르는 관심사다. 1부에서 봤던 "보안 아이콘만 흩뿌려놓은" 실패는, 이 스트립을 만들지 않고 나중에 아이콘을 여기저기 끼워 넣기 때문에 생긴다.

2단계. 정상 흐름 하나만 먼저 완성한다

기능 블록이 정리되면, 그다음은 가장 중요한 흐름 하나를 끝까지 그린다. 예외도, 재시도도, 장애조치도 아직 그리지 않는다.

정상 흐름을 먼저 그려야 하는 이유는 명확하다. 예외 처리는 정상 흐름이 정의되어야만 정의할 수 있기 때문이다. "검색이 실패하면 어떻게 하나"는 검색이 언제 어디서 일어나는지 정한 뒤에야 답할 수 있는 질문이다.

정상 흐름이 완성되면 오른쪽 목록을 하나씩 붙여 나간다. 비동기 수집 경로, 관리자 흐름, 외부기관 연계, 실패·재시도·DLQ, 장애조치, 감사 로그, 백업·복구 순이다.

한 가지 신호를 기억해두면 좋다. 정상 흐름이 7~8단계를 넘어가면 대개 그림이 아니라 설계가 복잡한 것이다. 그럴 때는 흐름을 둘로 나누는 것이 정답이지, 글씨를 줄이는 것이 정답이 아니다.

3단계. 요구 역할을 AWS 서비스에 매핑한다

이제야 AWS 서비스명이 등장한다. 1단계에서 만든 기능 블록 하나하나에 대해 "이 역할을 무엇으로 구현할 것인가"를 정한다.

이 표는 자동 선택표가 아니다. 왼쪽 칸을 보고 오른쪽 칸을 기계적으로 옮겨 적으면 그게 바로 1부의 아이콘 수프가 된다. 트래픽, 운영 역량, 데이터 특성, 보안 요건, 비용에 따라 선택이 달라져야 한다.

K광역시의회 사업에서 실제로 갈린 세 가지 결정을 보자.

세 번째 결정을 눈여겨보길 바란다. 서비스를 빼는 것도 설계 결정이다. 그리고 그 이유를 적어두면, 뺀 것이 "몰라서 안 넣은 것"이 아니라 "검토하고 미룬 것"이 된다.

4단계. 경계를 바깥에서 안쪽 순으로 배치한다

서비스가 정해졌으면, 이제 어디에 놓을지를 정한다. 여기서 순서가 결정적이다.

권장 순서는 이렇다.

아이콘을 먼저 놓고 나중에 경계를 씌우려 하면 반드시 어그러진다. 경계 박스는 안쪽 내용의 크기에 따라 크기가 정해지는데, 아이콘을 먼저 배치하면 이미 자리가 굳어 있어서 경계가 들어갈 틈이 없다. 그래서 결국 경계를 포기하게 된다. 1부의 실패 유형 ③ "경계가 모호함"은 대부분 이 순서 문제에서 생긴다.

다만 모든 그림에 모든 경계를 넣을 필요는 없다. 위 그림은 아홉 단계를 전부 보여주기 위한 교육용이다. 실제 3장 구성도에서는 그 그림이 답하려는 질문에 필요한 경계만 남긴다. 계정이 하나뿐인 사업이라면 Organizations 박스는 지운다.

5단계. 화살표에 방향과 의미를 붙인다

경계가 잡혔으면 이제 선을 긋는다. 1부에서 봤듯이, 여기서 대부분의 그림이 정보를 잃는다.

규칙은 두 가지다.

첫째, 선 모양만으로 의미를 구분하지 않는다. 실선과 점선을 구분해서 쓰는 것은 좋지만, 반드시 범례를 함께 넣는다. 범례 없는 점선은 읽는 사람마다 다르게 해석한다. 어떤 사람은 "선택 사항"으로, 어떤 사람은 "비동기"로, 어떤 사람은 "향후 확장"으로 읽는다.

둘째, 화살표 옆에 무엇이 흐르는지 적는다. 제안서 단계에서는 포트 번호보다 의미가 낫다.

TCP 5432는 정확하지만, 그걸 보고 무언가를 판단할 수 있는 사람은 인프라 담당자뿐이다. SQL 조회·저장은 모두가 읽을 수 있고, 인프라 담당자에게도 여전히 같은 정보를 준다. 포트는 상세설계서에서 적는다.

그리고 양방향 화살표 하나를 요청과 응답 두 개로 나누는 것만으로 호출 주체와 장애 전파 방향이 드러난다. 이건 그림이 예뻐지는 문제가 아니라 검토 가능성의 문제다.

6단계. 비기능 요구사항을 구조로 증명한다

제안서에 "고가용성을 제공합니다"라고 쓰는 것은 아무것도 약속하지 않는 것과 같다. 그 문장은 모든 경쟁사 제안서에도 들어 있다.

차이를 만드는 것은 그 문장이 아니라 그림이 그것을 보여주는가다. 다음이 그림에 실제로 보여야 한다.

특히 마지막 행. RTO와 RPO는 그림에 숫자로 적는다. 제안서 본문 어딘가에 있다고 충분한 것이 아니다. 구성도를 보는 사람이 그 자리에서 "이 구조로 4시간 안에 복구가 되나?"를 검증할 수 있어야 한다.

7단계. 마지막에 아이콘 수를 줄인다

여기까지 오면 그림에 상당히 많은 것이 들어가 있다. 마지막 단계는 덜어내는 것이다.

삭제 판단 기준은 질문 하나다.

이 구성요소가 없어지면 고객의 의사결정이나 시스템 흐름 설명이 달라지는가?

"아니요"라면 지운다. 목표 기준은 이렇다.

• 종합 구성도 한 장에 기능 그룹 5~7개
• 주요 AWS 서비스 7~12개
• 나머지는 상세 구성도로 분리

K광역시의회 사업에서 이 단계에 지운 것들은 이렇다. AWS Glue(수집 파이프라인이 단순해 ETL 카탈로그가 아직 불필요), Step Functions(SQS + 워커로 충분), DynamoDB(세션은 Aurora로 처리), Amazon Neptune(3단계에서 2차 과제로 미룸), 그리고 보안 서비스 여섯 개는 개별 아이콘 대신 하나의 횡단 스트립으로 묶었다.

지웠다고 안 쓰는 것이 아니다. 다른 그림에서 다룬다.

완성본 — 1부의 그 그림과 같은 사업

1부의 아이콘 수프와 같은 사업이고, 같은 요구사항이다. 서비스 개수는 24개에서 11개로 줄었다. 화살표도 훨씬 적다.

그런데 60초 테스트를 다시 돌리면 결과가 달라진다.

0 / 7 → 7 / 7.

정보량이 늘어서가 아니다. 줄어서 그렇다. 그림에서 24개를 11개로 줄이고, 대신 경계와 방향과 역할명을 넣었더니 답할 수 있는 질문이 일곱 개 늘었다.

이것이 이 시리즈 전체를 관통하는 한 문장이다.

좋은 인프라 구성도는 시스템을 가장 자세하게 그린 그림이 아니라, 고객이 가장 빠르게 이해하고 검토하며 의사결정할 수 있게 만든 그림이다.

정리

다음 편 예고

그림은 완성됐다. 그런데 하나 남은 질문이 있다. 이 그림은 기술적으로 맞는가?

Part 4에서는 AWS 구성도에서 가장 많이 나오는 배치 오류를 다룬다.

• Amazon RDS · Aurora를 어디에 그려야 하는가 — DB Subnet Group과 두 개 이상의 AZ
• AWS Lambda는 고객 서브넷 안에서 실행되지 않는다 — 그럼 어떻게 그리는가
• S3와 DynamoDB를 프라이빗 서브넷 안에 그리면 왜 틀린가 — Gateway Endpoint의 위치
• Interface VPC Endpoint와 ENI, 그리고 Amazon Bedrock의 PrivateLink
• "Multi-AZ"라는 글자만 있는 그림 / 보안 아이콘만 나열한 그림 / RTO·RPO가 없는 그림
• AWS 공식 레퍼런스 8건과 한국 사례 8건을 복사하지 않고 표현 구조만 배우는 법

참고 자료

• AWS Well-Architected Framework — 운영 우수성 · 보안 · 안정성 · 성능 효율성 · 비용 최적화 · 지속 가능성
• AWS Architecture Icons — 공식 아이콘 패키지 및 PowerPoint 툴킷
• Azure Well-Architected: Architecture design diagrams — 방향성 있는 화살표, 일관된 표기, 명확한 레이블
• C4 model — 줌 레벨과 배포 다이어그램
• arc42 — 아키텍처 결정(9번)과 품질 요구사항(10번) 항목