Knowledge

인프라 구성도를 그리기 전에 확인해야 할 것들

고객이 말한 장비 수를 그대로 구성도에 옮기기 전에, 설계자가 확인해야 할 요구사항과 판단 기준을 정리합니다.

Infrastructure · Architecture

2026-10-14

고객이 “서버 3대 필요해요”라고 말했을 때, 설계자가 그대로 3대를 그려서 구성도를 제출하면 어떤 일이 벌어질까?

많은 경우, 실제 운영 단계에서 “이 구성으로는 안 된다”는 피드백이 나오거나, 나중에 장애가 발생했을 때 책임이 설계자에게 돌아온다. 고객의 말과 시스템이 실제로 필요한 것 사이에는 항상 간격이 있기 때문이다.

이 글에서는 인프라 구성도를 그리기 전에 설계자가 확인해야 할 요구사항 항목과 판단 기준을 정리한다. 기술사 토픽에서 다루는 요구사항 분석의 개념을 실무 설계 관점으로 재구성한 내용이다.

왜 요구사항 확인이 먼저인가

인프라 설계에서 가장 흔한 실수 중 하나는 고객이 말한 장비 수를 그대로 수용하는 것이다.

이 대화가 위험한 이유는 다음과 같다.

고객은 자신의 업무 요구를 기술 용어로 정확히 표현하지 못하는 경우가 많다.
가용성, 성능, 보안, 운영 편의성 등의 비기능 요구는 명시되지 않는 경우가 대부분이다.
나중에 “이중화가 안 되어 있다”, “백업이 없다”, “장애 시 복구가 불가능하다”는 지적이 나오면, 설계 단계에서 확인하지 않은 책임이 남는다.

요구사항을 확인하는 과정은 단순히 “질문을 많이 하는 것”이 아니라, 설계 판단의 근거를 만드는 과정이다.

아래는 실제 프로젝트에서 구성도 작성 전에 확인하는 항목들이다. 모든 항목을 한 번에 다 물어보기보다는, 프로젝트 성격에 따라 우선순위를 두고 진행한다.

판단 포인트: “서버 3대”라는 말 뒤에 숨어 있는 실제 업무 부하를 추정할 수 있어야 한다. 부하를 모르면 Capacity 산정도 불가능하다.

판단 포인트: 고객이 “이중화해 주세요”라고 해도, 어느 레이어까지 이중화할 것인지, 그리고 그 비용 대비 효과를 설명할 수 있어야 한다. “서버 2대면 이중화 완료”가 아닌 경우가 대부분이다.

판단 포인트: 현재 기준으로만 설계하면 6개월 뒤에 증설이 필요한 구성이 된다. 반대로 과도하게 잡으면 비용 낭비가 된다. 근거 있는 가정을 명시하는 것이 중요하다.

판단 포인트: 보안 요구를 나중에 추가하면 구성 전체가 바뀌는 경우가 많다. 특히 DMZ 구성, 방화벽 배치, 데이터 암호화 위치 등은 초기 설계에 반영해야 한다.

판단 포인트: 설계자가 운영까지 책임지지 않더라도, 운영이 어려운 구성은 결국 문제로 돌아온다. “이 구성으로 운영할 수 있는가?”를 스스로 물어봐야 한다.

위 항목들을 실제 프로젝트에 적용해서 요구사항 분석서와 구성도를 작성하는 과정은 인프런 「처음 시작하는 IT 인프라 설계」 과정에서 가상 사례로 다룹니다.

요구사항을 확인한 뒤에는 다음과 같이 정리하면 이후 구성도 작업이 수월해진다.

이 과정을 거치면 구성도는 단순한 그림이 아니라, 판단 근거가 있는 설계 산출물이 된다.

요구사항 확인은 설계 시간을 늘리는 작업이 아니다. 나중에 재작업하거나 장애로 이어지는 시간을 줄이는 작업이다.

이 내용은 인프라 아키텍처 설계 과정에서 요구사항을 분석하고 구성도로 연결하는 실무 접근을 정리한 것이다. 관련 주제(HA 설계, SPOF 분석, 구성도 작성 원칙 등)는 지속적으로 다룬다.

이 글에서 정리한 판단 기준을 바탕으로 실제 설계 산출물을 만들어보고 싶은 분은 아래 과정에서 단계별로 따라가 보실 수 있습니다.