[Project] 아키텍처 설계의 시작: 요구사항 분석과 도식화

좋은 아키텍처는 단순히 코드를 깔끔하게 짜는 것을 넘어,

누가 사용하고, 무엇을 해야 하며, 어떤 제약조건이 있는지를 명확히 하는 것에서 시작합니다.

이번 글에서는 소프트웨어 아키텍처 설계를 위한 첫 단추인 '이해관계자 선별'부터 '도식화'까지의 과정을 정리해 봅니다.

---

1. 이해관계자 선별하기

"누가 이 시스템에 관련되어 있는가?"

 

: 아키텍처 설계의 첫 단계는 이 시스템에 영향을 주거나, 반대로 시스템에 의해 영향을 받는 모든 사람과 조직을 식별하는 것입니다. 개발자나 실제 사용자뿐만 아니라, 시스템 운영에 관여하는 모든 대상을 포함해야 놓치는 요구사항이 없습니다.

 

정의: 아키텍처 구축 결과에 관심을 갖거나 영향을 미치는 모든 인물 및 그룹

ex) 대학 학사 시스템 : 학생, 교수, 교직원, 인사관리 시스템, 학사관리 시스템 

---

2. 기능요구사항 정의

"시스템이 무엇을 해야 하는가?"

 

요구사항 정의서 예시 / 출처 : https://velog.io/@juyeon/요구사항-정의서-작성하는-법

 

: 사용자가 시스템을 통해 얻고자 하는 비즈니스 가치를 구체적인 기능으로 정의하는 단계입니다.

"로그인이 되어야 한다" 수준을 넘어 구체적인 동작을 명시해야 합니다.

 

정의: 시스템이 제공해야 하는 기능적 동작, 입력에 대한 처리 및 서비스

ex) 학사 관리 : 신입생 등록, 휴/복학 신청 처리, 수업 관리 : 강의 계획서 입력, 강의실 배정, 수강 관리..., 사용자 관리... 등

---

3. 비기능요구사항 정의

"시스템이 어떻게 동작해야 하는가?"

 

: 기능이 '무엇'이라면, 비기능은 '품질'과 '제약사항'입니다.

아키텍처의 구조(Monolithic vs MSA)나 기술 스택(DB 선정, 언어 선정)을 결정하는 데 결정적인 역할을 합니다.

 

정의: 시스템의 성능(Performance), 보안(Security), 가용성(Availability), 변경 용이성(Modifiability) 등 품질 특성이나 제약조건

ex) 성능: 수강신청 기간(트래픽 폭주)에도 2초 이내 응답 보장, 강의신청 기간 중 원활한 진행,

어디서든 접근 가능한 환경, 모바일 플랫폼 지원 등

---

4. 품질 속성 시나리오

"추상적인 비기능 요구사항을 구체적으로 검증 가능하게 만들기"

 

: "시스템이 빨라야 한다"라는 요구사항은 모호합니다. 이를 아키텍처 설계와 평가에 활용할 수 있도록

6하 원칙에 가까운 시나리오 형식으로 구체화해야 합니다.

 

정의: 비기능 요구사항을 정량적이고 구체적으로 명세하여, 아키텍처가 이를 만족하는지 테스트할 수 있도록 만든 시나리오

ex)

 

• Source (발생원): 자극을 주는 주체 (예: 학생) - 전체 재학생 중 5,000명
• Stimulus (자극): 시스템에 가해지는 요청이나 조건 (예: 수강신청 버튼 클릭) - 오전 10시 정각에 동시 수강신청 요청 발생
• Environment (환경): 자극이 발생한 상황 (예: 트래픽이 몰리는 개강 전날 피크 타임) - 시스템 부하가 가장 높은 오픈후 1분
• Artifact (대상): 자극을 받는 시스템의 부분 (예: 수강신청 서비스 서버) - 시스템 부하가 가장 높은 오픈 직후 1분간
• Response (응답): 시스템의 반응 (예: 요청 순서대로 큐에 쌓고 처리) - 대기열 시스템을 통해 순차적으로 진입을 허용
• Response Measure (응답 측정): 응답의 성공 기준 - 모든 요청 2초 내 처리 및 결과 반환, 서버 다운 없이 초당 1,000건 처

---

 

5. 도식화

"글보다 강력한 그림으로 아키텍처 시각화하기"

 

: 정의된 요구사항들을 바탕으로 실제 기술 스택과 구성 요소를 배치하는 단계입니다.

전체적인 그림(Big Picture)을 그려 팀원들과 기술적 합의를 이룹니다.

 

정의: CI/CD 파이프라인, Backend/Frontend 구조, Database, Network 구성 등을 Layer 별로 표현하여

시스템의 전체 구조를 시각화하는 작업

 

출처 : https://www.processon.io/ko/blog/architecture-diagram-making-tutorial

 

 ex)

• 포함되어야 할 내용:
  • Infrastructure: AWS/On-premise, Network(VPC, Subnet)
  • MiddleWare: Web Server(Nginx), WAS(Tomcat), Message Queue(Kafka)
  • Application: Framework(Spring Boot), Library
  • DevOps: Git, Jenkins/Github Actions, Docker/Kubernetes
• 활용 도구: Draw.io, Mermaid, PPT, Enterprise Architect

---

마무리하며

이처럼 이해관계자 파악 -> 요구사항(기능/비기능) 정의 -> 품질 시나리오 구체화 -> 도식화의 과정을 거치면,

막연했던 서비스가 구체적인 설계도면으로 바뀌게 됩니다. 코딩을 바로 시작하고 싶은 유혹을 참고

이 과정을 탄탄히 다진다면, 프로젝트 중반에 "아, 이걸 생각 못했네" 하며 구조를 뒤엎는 일을 획기적으로 줄일 수 있습니다.

 

•