신입에게 draw.io를 열게 하면 100% 같은 일이 벌어진다. AWS 아이콘부터 깔아놓는다. 서비스 26개와 화살표 47개가 빽빽한 그 그림은 60초 테스트 7문항 중 단 하나도 답하지 못한다. 코어닷투데이가 신입에게 인프라 구성도를 가르치는 사내 표준을 5부작으로 공개한다.
사수를 배정받은 지 일주일 된 신입에게 이렇게 말한다.
"이번 의정지원 AI 사업 제안서에 들어갈 인프라 구성도 좀 그려줄래요?"
30분 뒤 화면을 보면, 100%에 가까운 확률로 같은 일이 벌어져 있다. AWS 아이콘부터 깔려 있다. Route 53이 있고, CloudFront가 있고, WAF가 있고, EKS가 있고, Aurora가 있고, Bedrock이 있다. 화살표도 부지런히 그어져 있다. 열심히 했다.
그런데 그 그림으로는 아무것도 설명할 수 없다.
이건 신입의 잘못이 아니다. 우리가 순서를 가르치지 않았기 때문이다. 인프라 구성도는 "AWS 서비스를 배치하는 작업"처럼 보이지만, 실제로는 "어떤 질문에 답할 것인지 정하는 작업"이다. 순서를 뒤집으면 아무리 오래 붙잡고 있어도 좋아지지 않는다. 아이콘을 더 넣거나 색을 바꾸거나 정렬을 맞추는 것으로는 고쳐지지 않는 종류의 문제다.
그래서 우리는 규칙을 하나 만들었다.
그림의 목적을 한 문장으로 쓰기 전에는 툴을 열지 않는다.
이 시리즈는 코어닷투데이가 신입에게 인프라 구성도 작성을 가르칠 때 쓰는 사내 표준을 그대로 공개하는 5부작이다. 제안서에 인프라 구성도를 넣어야 하는데 어디서부터 손대야 할지 막막한 사람, 그리고 그런 사람을 가르쳐야 하는 사람을 위한 글이다.
1부인 이 글에서는 왜 대부분의 제안서 구성도가 실패하는지를 다룬다. 진단이 먼저다. 무엇이 잘못됐는지 정확히 짚지 못하면, 2부부터 나올 처방이 그냥 잔소리로 들린다.
추상적인 원칙만 늘어놓으면 읽을 때는 고개를 끄덕이지만 정작 자기 제안서 앞에서는 다시 막힌다. 그래서 5편 전체를 하나의 가상 사업으로 관통한다. 1부에서 이 사업을 나쁘게 그려보고, 2부에서 몇 장이 필요한지 정하고, 3부에서 제대로 그리고, 4부에서 기술적 오류를 잡고, 5부에서 채점한다.
| 항목 | 내용 |
|---|---|
| 사업명 | K광역시의회 의정지원 AI 플랫폼 구축 |
| 발주기관 | K광역시의회 사무처 |
| 목적 | 뉴스·관보·공시·회의록·조례를 수집·분석해 근거와 출처를 붙여 검색·요약·보고서 초안 제공 |
| 사용자 | 의원 60명 / 전문위원·직원 200명 / 시민 공개 포털(읽기 전용) |
| 외부 연계 | 의안정보시스템, 관보 API, DART 공시, 지역 언론 RSS |
| 온프레미스 | 기존 의정관리시스템(회의록 DB), 기관 내부망 |
| 데이터 | 문서 1,200만 건, 연 300만 건 증가, 원문 8TB |
| 정보 등급 | 민원인 개인정보 포함, 망분리 요건 |
| 가용성 | 평일 08–20시 핵심, 정기회 기간 트래픽 5배 급증 |
| 복구 목표 | RTO 4시간 / RPO 1시간 |
| 제약 | 18개월, ap-northeast-2 단일 리전 예산, 운영은 고객 + MSP |
이 사업은 전부 가상이다. 실존하는 기관이나 사업을 지칭하지 않는다. 다만 공공 부문에서 AI 플랫폼 구축 제안을 해본 사람이라면 요구사항의 결이 낯설지 않을 것이다.
이 사례를 고른 이유는 하나다. 한 사업이 요구하는 관점이 지나치게 많기 때문이다. 외부기관 연계가 있고, 온프레미스 하이브리드가 있고, AI·검색이 있고, 데이터 파이프라인이 있고, 개인정보와 망분리가 있고, RTO·RPO가 명시돼 있다. 이 모든 걸 한 장에 그리려는 순간 그림은 반드시 무너진다. 그 무너지는 과정을 지금부터 보여주려 한다.
신입이 30분 만에 그려온 그림은 이렇게 생겼다.
이 그림을 처음 본 사람들의 반응은 보통 두 갈래다.
둘 다 제안 발표장에 들어가기 전까지만 유효한 반응이다.
여기서 짚고 넘어가야 할 것이 하나 있다. 이 그림에는 사실관계 오류가 거의 없다. 뉴스·관보를 수집하려면 스케줄러와 워커가 필요하니 EventBridge와 ECS가 있는 게 맞고, 대량 문서를 쌓으려면 S3가 맞고, 검색과 벡터가 필요하니 OpenSearch가 맞고, 관계 추출을 하려니 Neptune이 있고, 생성형 답변을 하려니 Bedrock이 있다. 서비스 선택 자체는 대체로 합리적이다.
그런데도 쓸모가 없다. 이게 인프라 구성도라는 산출물의 고약한 점이다. 틀리지 않았는데 실패할 수 있다.
왜 그런지 감으로 말하지 말고, 측정 가능한 방법으로 확인해 보자.
코어닷투데이에서 구성도 리뷰를 할 때 가장 먼저 하는 일은 지적이 아니라 측정이다. 방법은 단순하다.
60초라는 시간은 임의로 정한 숫자가 아니다. 제안 평가위원이 수백 페이지 제안서에서 인프라 구성도 한 장에 실제로 쓰는 시간이 대략 그 정도다. 발표 슬라이드로 넘어가면 더 짧다. 그 시간 안에 읽히지 않는 그림은, 아무리 정교해도 평가에 반영되지 않는다.
앞의 그림에 이 테스트를 적용하면 결과는 이렇다.
0 / 7.
하나씩 짚어보면 왜 그런지 분명해진다.
1. 시스템의 사용자는 누구인가? — 그림 안에 사용자라는 박스가 분명히 있다. 그런데 그 박스가 Amazon S3 박스와 똑같이 생겼다. 같은 모양, 같은 색, 같은 크기다. 시각적으로 사람과 시스템이 같은 종류의 것으로 표현돼 있다. 게다가 이 사업의 사용자는 의원·전문위원·시민 세 부류인데, 그림은 그걸 하나로 뭉뚱그렸다. 권한 설계가 완전히 다른 세 집단인데도.
2. 요청은 어디로 들어오는가? — 진입점 후보가 넷이다. Route 53, CloudFront, API Gateway, Application Load Balancer. 넷 다 그림에 있다. 문제는 이들 사이에 순서가 없다는 것이다. Cognito에서도 API Gateway로 선이 들어가고, WAF에서도 들어가고, CloudFront에서도 들어간다. 그래서 시민이 포털에 접속했을 때 어떤 경로를 타는지, 의원이 내부망에서 들어올 때는 어떻게 다른지 알 수 없다.
3. 주요 업무는 어디에서 처리되는가? — ECS와 EKS와 Lambda가 나란히 있다. 셋 다 컴퓨트다. 실무에서 셋을 동시에 쓰는 경우가 없진 않지만, 그렇다면 무엇이 주 처리기이고 무엇이 보조인지 표시돼야 한다. 이 그림에서는 셋이 같은 위계로 떠 있다. 읽는 사람 입장에서는 "결정을 안 한 건가, 아니면 다 쓰겠다는 건가"를 구분할 수 없다.
4. 데이터는 어디에 저장되는가? — 저장소가 여섯이다. Aurora, DynamoDB, S3, OpenSearch, Neptune, 그리고 온프레미스 회의록 DB. 여섯 개를 쓰는 것 자체는 이 사업 성격상 충분히 있을 수 있다. 하지만 무엇이 원문이고, 무엇이 정제본이고, 무엇이 인덱스이고, 무엇이 그래프인지 구분이 없다. 데이터의 출처와 계보를 추적해야 하는 사업에서 이건 치명적이다.
5. 외부와 내부 경계는 어디인가? — 이 그림에는 경계 박스가 한 개도 없다. AWS 계정도, 리전도, VPC도, 가용영역도, 서브넷도 없다. 개인정보를 다루고 망분리 요건이 있는 사업에서, 어떤 것이 인터넷에 노출되고 어떤 것이 프라이빗 서브넷에 있는지 그림이 말해주지 않는다. 발주기관 보안 담당자가 가장 먼저 볼 것이 바로 그건데.
6. 장애가 나면 어떻게 되는가? — 가용영역 박스가 없고, 중복 인스턴스가 없고, 복제 방향 화살표가 없고, 대기 인스턴스가 없다. RFP에 RTO 4시간 / RPO 1시간이 명시돼 있는데 그림 어디에도 그 숫자가 없다. 제안서 본문에 "고가용성을 제공합니다"라고 써두었다 해도, 그림이 뒷받침하지 않으면 그 문장은 주장일 뿐이다.
7. 보안과 운영은 누가 담당하는가? — KMS, Secrets Manager, CloudWatch, CloudTrail, GuardDuty가 있다. 다섯 개나 있다. 그런데 이들이 무엇을 보호하고 무엇을 관측하는지 알 수 없다. GuardDuty에서 나가는 선이 ECS로 하나 그어져 있는데, 그게 무슨 의미인지는 아무도 모른다. 게다가 이 사업은 운영 주체가 고객과 MSP로 나뉘는데, 그 경계도 그림에 없다.
측정 결과를 한 줄로 요약하면 이렇다.
이 그림이 전달하는 정보는 "작성자가 AWS 서비스를 24개 알고 있다"는 사실 하나뿐이다.
그리고 그건 발주기관이 궁금해하는 정보가 아니다.
신입에게 가장 먼저 교정해줘야 하는 인식은 이것이다.
인프라 구성도는 AWS 서비스를 많이 알고 있다는 것을 자랑하는 그림이 아니다.
그럼 무엇인가. 좋은 구성도는 다음 질문에 빠르게 답한다.
이 다섯 질문은 순서가 있다. 왼쪽에서 오른쪽으로 읽으면 그대로 하나의 문장이 된다. 누가 무엇을 요청하면, 어떤 경계를 지나, 어디서 처리·저장되고, 잘못되면 어떻게 되는가.
여기서 가운데 있는 "경계"가 특히 중요하다. 나머지 넷은 기능에 관한 질문이지만, 경계는 책임과 위험에 관한 질문이기 때문이다. 어디까지가 우리 책임이고 어디부터가 고객 책임인지, 어디가 인터넷에 노출되고 어디가 격리돼 있는지, 어떤 데이터가 어떤 신뢰 구역을 넘어가는지. 제안 평가에서 감점이 가장 크게 나는 지점이 대체로 여기다.
그런데 앞의 아이콘 수프에는 경계가 정확히 0개였다.
코어닷투데이 내부에서는 구성도 품질을 이렇게 정의한다.
이 공식에서 중요한 건 항목 목록이 아니라 연산자다. 더하기가 아니라 곱하기다.
덧셈이었다면 "가독성은 좀 떨어지지만 기술적으로 정확하니까 평균은 하겠지" 같은 타협이 가능하다. 실제로 많은 사람이 그렇게 생각한다. 하지만 실무에서 관찰되는 건 정반대다. 하나가 0이면 전체가 0이 된다. 아무리 정확해도 안 읽히면 0점이고, 아무리 예뻐도 경계가 틀렸으면 0점이다.
각 항이 0이 되는 순간은 이렇다.
| 항목 | 무엇을 보는가 | 0이 되는 순간 |
|---|---|---|
| 질문의 선명도 | 이 그림이 답하려는 질문이 하나로 정의돼 있는가 | 한 장에 사업 범위·네트워크·데이터 흐름·DR을 다 넣었을 때 |
| 경계의 정확성 | 계정·리전·VPC·AZ·서브넷·신뢰 구역이 실제 동작과 맞는가 | S3를 프라이빗 서브넷 안에 그렸을 때 |
| 흐름의 설명력 | 요청·데이터·이벤트의 방향과 의미가 읽히는가 | 화살표가 전부 레이블 없는 양방향일 때 |
| 운영 가능성 | 인증·암호화·모니터링·백업·장애조치가 보이는가 | "고가용성 제공"이라는 글자만 있을 때 |
| 가독성 | 제안서에 축소 삽입해도 읽히는가 | 서비스명이 9pt로 줄어들었을 때 |
마지막 행을 가볍게 보지 않았으면 한다. 아무리 잘 설계한 구성도라도, A4 제안서 한 페이지에 삽입되면서 60%로 축소되고 흑백으로 인쇄되는 순간 읽히지 않으면 존재하지 않는 것과 같다. 가독성은 미적 취향이 아니라 전달 가능성의 문제다.
진단에서 처방으로 넘어가기 전에, 신입에게 가장 먼저 심어주는 네 가지 원칙이 있다. 이 시리즈 전체가 사실상 이 네 문장의 각주다.
원칙 2가 특히 저항을 많이 받는다. 제안서를 준비하는 입장에서는 "우리가 이만큼 큰 그림을 그렸다"는 인상을 주고 싶어서, 자꾸 한 장에 다 넣으려 한다. 슬라이드 매수 제한이 있으면 압력은 더 커진다.
하지만 실제로는 4~6개의 서로 다른 관점의 그림으로 나누는 편이 훨씬 설득력이 높다. 그림이 늘어나는 만큼 각 그림이 명확해지고, 명확한 그림은 "이 팀은 우리 사업을 이해하고 있다"는 신호가 되기 때문이다. 반대로 한 장에 뭉친 그림은 "이 팀은 아직 정리를 못 했다"는 신호를 준다. 정보량은 같은데 인상이 정반대다.
몇 장이 필요하고 각 장이 무엇을 담아야 하는지는 2부에서 통째로 다룬다.
이제 구체적인 실패 유형으로 들어간다. 코어닷투데이에서 정리한 실패 유형은 모두 열 가지인데, 그중 AWS와 무관하게 모든 구성도에서 나타나는 네 가지를 1부에서 먼저 다룬다. AWS 특유의 오류 네 가지는 4부에서, 문서 관리에 관한 두 가지는 5부에서 다룬다.
첫 번째는 이 글의 제목이기도 한 아이콘 수프다.
증상. 서비스 아이콘은 많지만 어떤 요청이 어디로 가는지 알 수 없다. 그림의 정보 밀도는 높은데 정보 전달량은 낮다.
왜 생기는가. 원인은 대개 심리적이다. 아이콘을 지우는 게 손해처럼 느껴지기 때문이다. "이 서비스도 쓸 건데 안 그리면 빠뜨린 것처럼 보이지 않을까", "검토했다는 걸 보여줘야 하지 않을까" 하는 생각이 쌓이면 그림은 계속 무거워진다. 여기에 "AWS를 잘 안다는 인상을 주고 싶다"는 동기가 더해지면 완성된다.
삭제 여부를 판단하는 질문은 하나면 충분하다.
이 구성요소가 사라지면 고객의 의사결정이나 시스템 흐름 설명이 달라지는가?
"아니요"라면 지운다. GuardDuty가 좋은 예다. 실제로 켤 것이고 켜야 하지만, 목표 아키텍처 그림에서 그 아이콘이 사라진다고 해서 고객이 다른 결정을 하지는 않는다. 그건 5장 보안·운영 구성도에서 다룰 내용이다. 지운다고 안 쓰는 게 아니다. 다른 그림에서 다룬다는 뜻이다.
증상. 비즈니스 범위, 네트워크 구조, 런타임 흐름, CI/CD, 재해복구가 한 장에 다 들어가 있다.
왜 생기는가. 원인은 아이콘 수프와 다르다. 이건 욕심이 아니라 개념의 미분화에서 온다. 작성자 머릿속에서 "사업 범위"와 "네트워크 구조"와 "요청 흐름"이 아직 서로 다른 종류의 그림이라는 인식이 없는 것이다. 다 아키텍처니까 한 장에 그리면 된다고 생각한다.
이걸 정리해주는 도구가 C4 모델이다. C4는 소프트웨어 시스템을 네 단계 줌 레벨로 나눈다. System Context(사용자와 외부 시스템) → Container(애플리케이션·API·데이터베이스) → Component(내부 구성요소) → Code(클래스 수준). 여기에 동적 다이어그램과 배포 다이어그램이 더해진다.
핵심은 서로 다른 줌 레벨을 한 장에 섞으면 안 된다는 것이다. 지도로 비유하면, 세계지도 위에 특정 건물의 층별 안내도를 겹쳐 그리는 셈이다. 각각은 유용하지만 겹치면 둘 다 못 쓴다.
앞의 아이콘 수프를 다시 보면, 이 그림은 최소한 세 개의 줌 레벨이 섞여 있다.
사용자, 온프레미스 회의록 DB → System Context 레벨Amazon ECS, Amazon Aurora → Container 레벨AWS KMS, AWS CloudTrail → 횡단 관심사(cross-cutting concern), 애초에 다른 축처방. 최소한 목표 구조 / 배포 구조 / 데이터 흐름 / 운영·DR로 분리한다. 어떻게 나누는지는 2부에서 6장 세트로 구체화한다.
증상. 어떤 시스템이 고객사 환경이고 어떤 것이 AWS인지, 어느 계정·어느 VPC인지 알 수 없다.
왜 생기는가. 경계 박스는 그리기 귀찮다. 중첩된 사각형을 겹쳐야 하고, 안쪽 요소가 늘어날 때마다 크기를 조정해야 하고, 레이아웃이 계속 틀어진다. 반면 아이콘은 끌어다 놓기만 하면 된다. 작업 난이도의 비대칭이 결과의 비대칭으로 이어진다.
그런데 제안 평가에서 배점이 큰 쪽은 정확히 그 귀찮은 쪽이다.
경계를 그릴 때는 각 박스마다 소유 주체와 환경명을 함께 적는다. 최소한 이 정도는 구분돼야 한다.
| 경계 | 이 사업에서의 의미 |
|---|---|
| 고객 데이터센터 | K광역시의회 전산실 — 기존 의정관리시스템과 회의록 DB가 남는 곳 |
| AWS 운영 계정 | 실 서비스가 도는 곳. 개인정보가 처리되는 구역 |
| AWS 개발 계정 | 개발·시험 환경. 운영 데이터가 넘어가면 안 되는 곳 |
| 외부 SaaS / 제3자 API | 의안정보시스템, 관보 API, DART — 우리가 통제할 수 없는 구간 |
처방. 경계를 바깥에서 안쪽 순으로 먼저 배치하고, 그 안에 워크로드를 넣는다. 아이콘을 먼저 놓고 나중에 경계를 씌우려 하면 반드시 어그러진다. 순서가 반대다. 3부 4단계에서 이 순서를 구체적으로 다룬다.
증상. 그림 안의 화살표가 대부분 A ↔ B 꼴이고, 레이블이 없다.
왜 생기는가. 양방향 화살표는 편하다. 어느 쪽이 호출 주체인지 아직 정하지 않았어도 그릴 수 있고, 실제로 요청과 응답이 오가니까 틀린 것도 아니다. 그래서 설계 결정을 미룬 채로 그림을 완성할 수 있게 해준다. 바로 그게 문제다.
App ↔ Database라는 화살표를 보고 알 수 있는 것은 "둘이 통신한다"뿐이다. 알 수 없는 것은 이렇게 많다.
특히 장애 전파 방향이 안 보이는 게 치명적이다. 인프라 구성도를 그리는 목적의 절반은 "무엇이 무엇에 의존하는가"를 드러내는 것인데, 양방향 화살표는 그 의존 관계를 정확히 지워버린다.
| 이렇게 쓰지 않는다 | 이렇게 쓴다 |
|---|---|
| App ↔ Aurora | App ── SQL 조회·저장 ──▶ Aurora PostgreSQL |
| Lambda ↔ S3 | Lambda ── 원문 파일 저장 ──▶ S3 Raw Zone |
| ECS ↔ OpenSearch | ECS ── 하이브리드 검색 질의 ──▶ OpenSearch |
| 온프레미스 ↔ AWS | 온프레미스 회의록 DB ── 일 1회 증분 동기화 ──▶ S3 Raw Zone |
제안서 수준에서는 포트 번호까지 다 적기보다 의미를 적는 편이 낫다. TCP 5432보다 SQL 조회·저장이 평가위원에게 더 많은 것을 전달한다. 상세설계서로 넘어가면 그때 포트를 적으면 된다.
맨 아래 행을 눈여겨보길 바란다. 하이브리드 사업에서 온프레미스 ↔ AWS라고만 그리는 것은 사실상 아무 말도 하지 않은 것과 같다. 어느 방향으로, 무엇이, 얼마나 자주 흐르는지가 빠지면 데이터 이관 계획도, 망 설계도, 장애 시나리오도 검토할 수 없다.
여기까지 본 네 가지 실패는 서로 달라 보이지만, 파고들면 같은 지점에서 만난다.
| 실패 유형 | 표면적 증상 | 근본 원인 | 해결은 어디에 |
|---|---|---|---|
| ① 아이콘 수프 | 아이콘이 너무 많다 | 이 그림이 답할 질문을 정하지 않았다 | 3부 (7단계 작성법) |
| ② 모든 관점을 한 장에 | 줌 레벨이 섞였다 | 이 그림이 답할 질문을 정하지 않았다 | 2부 (6장 세트) |
| ③ 경계가 모호함 | 경계 박스가 없다 | 귀찮은 것을 뒤로 미루고 쉬운 것부터 했다 | 3부 (4단계 경계 배치) |
| ④ 양방향 화살표 | 방향과 의미가 없다 | 설계 결정을 미룬 채 그림을 완성했다 | 3부 (5단계 화살표) |
①과 ②는 질문을 먼저 정하지 않은 것, ③과 ④는 결정을 미룬 채 그림부터 그린 것이다. 결국 둘 다 같은 말이다.
툴을 너무 일찍 열었다.
그래서 앞서 말한 규칙이 나온다. 그림의 목적을 한 문장으로 쓰기 전에는 draw.io를 열지 않는다. 이 규칙 하나만 지켜도 네 가지 실패 중 셋은 애초에 발생하지 않는다.
이 글은 진단으로 끝난다. 처방은 2부와 3부에 있다. 다만 도착지를 미리 말해두는 편이 읽는 데 도움이 될 것 같다.
3부 마지막에는 같은 K광역시의회 사업을, 같은 정보량으로, 다르게 그린 한 장이 나온다. 서비스 개수는 오히려 줄어들고, 화살표도 줄어든다. 그런데 60초 테스트 7문항에 전부 답한다.
그 그림에 도달하려면 두 단계를 거쳐야 한다.
한 가지만 미리 강조하고 싶다. 이 시리즈에서 배웠으면 하는 것은 "이렇게 생긴 그림을 그려라"가 아니다. AWS 공식 레퍼런스 아키텍처를 복사해 오는 것으로는 좋은 제안서가 되지 않는다. 배워야 하는 건 표현 구조다. 왜 저 레퍼런스는 계정 구조를 먼저 그렸는지, 왜 저 레퍼런스는 데이터 흐름에 번호를 붙였는지, 왜 저 레퍼런스는 수집 경로와 질의 경로를 분리했는지. 그 이유가 내 사업의 요구사항과 만나는 지점에서 비로소 내 구성도가 나온다.
그 이야기는 4부에서 한다.
Part 2에서는 "한 장 말고 여섯 장"을 다룬다.
통합검색 및 벡터 검색 – Amazon OpenSearch Service)RELATED
