시스템 구성도 작성법 2026 — 논리·물리 구분과 메뉴 구조도·IA 연결 7단계

# 시스템 구성도 작성법 2026 — 논리·물리 구분과 메뉴 구조도·IA 연결 7단계

시스템 구성도는 "무엇이 어디에 있는가"를 그린 그림이다

시스템 구성도(System Architecture Diagram)는 서버·DB·외부 서비스가 어떻게 연결돼 있는지를 한 장으로 보여주는 문서다.

발주처 입장에서 이 그림이 필요한 이유는 셋이다.

1. 견적이 왜 그 금액인지 설명된다 — 서버가 몇 대인지, 외부 연동이 몇 개인지가 여기 보인다
2. 운영 비용을 미리 안다 — 클라우드 자원이 그려져 있으면 월 얼마인지 계산이 된다
3. 다음 개발사가 인수할 수 있다 — 이 그림 없이 넘기면 다음 팀이 처음부터 파악해야 한다

⚠️ 개발사가 "구성도는 나중에"라고 하면 경계하는 게 맞다. 구조를 안 정하고 개발을 시작했다는 뜻인 경우가 많다.

발주 문서 전체 지도는 요구사항 정의서 작성법 — 외주 문서 7단계에 정리했다.

다른 문서와 헷갈리는 지점부터 정리한다

「구성도」라는 이름이 붙은 문서가 여러 개라 발주처가 무엇을 요구해야 할지 헷갈린다.

시스템 구성도는 "인프라", 메뉴 구조도는 "화면 배치", IA는 "정보 위계"다. 셋을 한 장에 섞으면 아무도 못 읽는다.

화면 단위 작성법은 화면설계서 작성법, 기능 단위는 기능 정의서 작성법에 따로 있다.

논리 구성도와 물리 구성도는 다른 그림이다

이 구분을 모르면 요청이 어긋난다.

발주처가 먼저 받아야 할 것은 논리 구성도다. 물리는 개발이 진행되며 확정된다.

⚠️ 계약서에 "시스템 구성도 납품"만 적혀 있으면 개발사가 논리 한 장으로 갈음할 수 있다. 운영까지 넘겨받을 계획이라면 물리 구성도를 별도 산출물로 명시한다.

시스템 구성도에 반드시 들어갈 6가지

4번이 견적을 가른다

외부 연동은 하나당 3~15일이 붙는다. 구성도에 안 그려져 있으면 대개 견적에도 없다.

발주 전에 이 목록을 직접 세어보면 견적서를 검증할 수 있다.

```

결제(PG) / 본인인증 / 문자·알림톡

이메일 / 지도·주소 / 회계·ERP

소셜 로그인 / 파일 스토리지 / 통계·분석

```

"연동 5개"와 "연동 12개"는 다른 프로젝트다. 그런데 요구사항에는 둘 다 "결제 기능"으로 한 줄이다.

클라우드냐 온프레미스냐를 그림에 표시한다

특별한 제약이 없으면 클라우드가 기본이다. 다만 구성도에 자원이 그려져 있어야 월 비용을 미리 계산할 수 있다.

⚠️ 오픈 후 "서버비가 이렇게 나올 줄 몰랐다"는 대부분 구성도를 안 봐서 생긴다. 자원 목록을 받아 개략 견적을 뽑아 달라고 요청한다.

메뉴 구조도 — 화면 목록의 지도

시스템 구성도가 인프라라면, 메뉴 구조도는 사용자가 보는 화면의 배치다. 발주처가 검토하기 가장 쉬운 문서이기도 하다.

```

관리자

├─ 대시보드

├─ 회원

│ ├─ 회원 목록

│ ├─ 회원 상세

│ └─ 등급 관리

├─ 주문

│ ├─ 주문 목록

│ └─ 반품 처리

└─ 통계

├─ 매출 통계

└─ 회원 통계

```

여기서 화면 개수가 나오고, 화면 개수가 견적을 만든다. 요구사항 정의서에 화면 목록을 적으라는 것이 결국 이 그림을 그리라는 뜻이다.

IA(정보구조도)와의 차이

메뉴 구조도는 화면이 어디 걸려 있나, IA는 정보가 어떻게 묶이나를 다룬다.

사용자 화면이 단순한 사내 시스템은 메뉴 구조도로 충분하고, 콘텐츠가 많은 서비스는 IA를 따로 그린다. 둘 다 요구하면 문서만 늘고 얻는 게 없는 경우가 많다.

발주처가 검토할 때 볼 것 5가지

1. 내가 아는 외부 연동이 다 그려져 있는가 — 빠진 것이 곧 추가 비용이다
2. 서버가 몇 대이고 왜 그만큼인가 — 설명이 안 되면 과잉이거나 근거가 없다
3. 데이터가 어디에 쌓이고 백업은 어디까지인가
4. 사내망에서만 써야 하는 부분이 표시돼 있는가
5. 화면 개수가 메뉴 구조도에서 세지는가 — 견적과 대조한다

⚠️ 그림이 예쁜지는 보지 않아도 된다. 위 다섯 개가 읽히면 충분한 문서다.

흔한 실수 4가지

① 논리와 물리를 한 장에 섞는다

역할 상자와 실제 서버가 섞이면 무엇이 몇 대인지 안 보인다. 두 장으로 나눈다.

② 외부 연동을 화살표 하나로 뭉갠다

「외부 API」 한 상자로 그리면 그 안에 몇 개가 있는지 사라진다. 연동은 개별로 그린다.

③ 개발 환경만 그리고 운영을 안 그린다

운영에는 도메인·인증서·모니터링·백업이 붙는다. 이걸 안 그리면 오픈 직전에 발견된다.

④ 한 번 그리고 갱신하지 않는다

구조는 개발 중 반드시 바뀐다. 납품 시점 기준으로 갱신된 것을 받는다를 계약서에 넣는다.

시스템 구성도 확보 7단계

```

[ ] 1. 사용자 유형과 접근 경로 정리

[ ] 2. 외부 연동 목록을 발주처가 먼저 나열

[ ] 3. 개발사에 논리 구성도 요청 (설계 초반)

[ ] 4. 메뉴 구조도로 화면 개수 확인 → 견적 대조

[ ] 5. 클라우드/온프레미스 결정 + 월 비용 개략 산정

[ ] 6. 개발 중반에 물리 구성도 수령

[ ] 7. 납품 시 갱신본 + 운영 계정·자원 목록 인수

```

AI-Native 팀이 구성도를 다루는 방식

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 구성도에서 어려운 것은 그리는 일이 아니라 코드와 어긋나지 않게 유지하는 일이다.

• 실제 구성과 대조 — 인프라 정의(IaC)와 문서의 자원 목록이 일치하는지 확인해, 그림에만 있고 실제로는 없는 자원을 잡는다
• 연동 목록 추출 — 코드에서 실제로 호출하는 외부 서비스를 뽑아 구성도에 빠진 것을 찾는다
• 운영 인수인계 문서화 — 배포 경로·환경 변수·백업 주기를 코드와 설정에서 역으로 정리한다

구성도의 가치는 납품 6개월 뒤에도 맞는가로 판가름난다. 대조를 자동화해 사람이 구조 판단에 집중하게 만드는 것이 AI-Native 개발 방식의 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

시스템 구성도는 발주처가 그리나요?

아니다. 개발사가 그리고 발주처가 검토한다. 다만 외부 연동 목록만큼은 발주처가 먼저 정리해야 한다. 우리 업무를 아는 쪽이 발주처이기 때문이다.

논리 구성도와 물리 구성도 중 하나만 받아도 되나요?

운영을 개발사에 맡긴다면 논리만으로도 굴러간다. 직접 운영하거나 나중에 이관할 계획이면 물리 구성도가 필요하다.

메뉴 구조도와 시스템 구성도 중 뭐가 먼저인가요?

메뉴 구조도가 먼저다. 화면이 정해져야 서버 구성이 정해진다.

구성도를 보고 견적을 검증할 수 있나요?

외부 연동 개수와 화면 개수 두 가지는 검증된다. 이 둘이 견적의 큰 부분을 만든다.

그림 도구는 뭘 쓰나요?

도구는 중요하지 않다. 다만 텍스트로 검색되는 형태로 받아야 나중에 찾을 수 있다. 이미지 한 장만 받으면 6개월 뒤 아무도 수정하지 못한다.

정리

시스템 구성도는 견적과 운영 비용을 검증하는 문서다. 예쁜 그림이 목적이 아니다.

실무에서 결과를 가르는 지점은 셋이다.

1. 외부 연동이 개별로 그려졌는가 — 견적 누락의 최대 원인이다
2. 논리와 물리를 나눠 받았는가 — 운영을 이관할 계획이면 물리가 필요하다
3. 납품 시점 기준으로 갱신됐는가 — 착수 때 그림 그대로면 이미 틀린 문서다

이 셋만 챙겨도 오픈 직후의 비용 사고 대부분이 예방된다.