(A-SPICE 12회차) SYS.3: "이건 설계가 아니라 조립도 아닌가요?"

🧠 12회차: "이건 설계가 아니라 조립도 아닌가요?"

SYS.3 – 시스템 아키텍처 설계는 ‘판짜기’의 예술!

👩‍🔧 "그냥 박스 몇 개 그려 넣으면 아키텍처 아닌가요?"
🧙‍♂️ "그건 설계가 아니라 그냥 PPT입니다, 친구여..."

---

🚀 오늘의 이야기: SYS.3 – 시스템 아키텍처 설계

A-SPICE 프로세스 중 SYS.3 – 시스템 아키텍처 설계는
개발 전체의 청사진이자 하드웨어, 소프트웨어, 인터페이스 구성의 핵심 설계 단계입니다.

즉!
"무엇을 누가 어떻게 나눠서 만들지"
정리하는 바로 그 단계!

---

👓 시스템 엔지니어, 당신은 이 판의 ‘감독’입니다

🎬 왜 중요한가요?

시스템 엔지니어는 영화 감독과도 같습니다.
배우(SW/HW), 시나리오(요구사항), 제작사(조직)를 조율해
작품(제품)을 완성해야 하니까요.

"배우는 연기를, 촬영감독은 카메라를, 조명팀은 빛을…
근데 이게 다 따로 논다고요? 시스템 엔지니어가 그 중심을 잡아야 합니다!"

---

🧭 아키텍처 설계의 올바른 접근 방식

1. 요구사항 기반의 분해
   • SYS.2의 시스템 요구사항을 SW/HW/기구로 분할!
   • 요구사항이 어디서 처리되는지 추적 가능해야 함!
2. 기능적 분할 vs 물리적 분할
   • "이건 기능적으로 SW에서 처리돼야 해"
   • "아니야, HW에 맡겨야 해!"
   • 설계 시 이 둘의 균형이 핵심 포인트!
3. 인터페이스 정의
   • 각 요소가 어떻게 연결될지!
   • 데이터, 제어 신호, 오류 응답 등까지 고려 필요
4. 대안 설계 평가
   • 하나의 설계만 보지 마세요!
   • 최소 두 가지 이상 아키텍처 안을 비교해야 합니다.
   • 평가 기준은? 👉 성능, 확장성, 안전성, 비용, 리스크 등!

---

🧠 대안 평가 없이 가는 설계는 위험합니다!

잘못된 예시	문제점
"그냥 하던 대로 하자~"	이전 설계가 현재 요구에 안 맞을 수도!
"이게 가장 싸다"	싸지만 유지보수 비용이 폭탄일 수 있음
"그 팀이 하던 방식이니까"	팀 의존 아키텍처는 조직 변경 시 리스크 발생

시스템 아키텍처 설계는 “왜 이 설계를 선택했는가”에 대한 이유가 있어야 합니다.

---

🛠 시스템 엔지니어가 꼭 해야 할 질문!

• 기능 분배가 요구사항과 일치하는가?
• 책임 분담이 모호하지 않은가?
• 인터페이스는 추적성과 검증이 가능한가?
• 내부 이해관계자(생산, 보안, AS 등)의 요구가 반영되었는가?
• 대안 설계를 최소 2개 이상 도출하고, 비교 평가했는가?

---

📌 실무 팁: 아키텍처 설계 검토 시 체크리스트

항목	질문
🎯 요구사항 추적	이 기능, 어디서 처리되나요? 누가 책임지나요?
🔍 대안 비교	선택한 이유와 배제한 대안의 단점은 명확한가요?
🧩 통합성	나중에 각 블록이 잘 붙을 수 있나요?
🛡 안전성	한 블록 고장 시 전체 영향은 어떤가요?
🔄 확장성	나중에 기능이 늘어나도 괜찮을까요?

---

🎁 개발자가 좋아하는 아키텍처 설계

• “명확하게 잘 나눠졌네요!”
• “책임이 분명하니 구현도 깔끔하겠어요!”
• “테스트 포인트도 딱딱 정해져서 좋네요!”

설계가 잘 되면, 개발은 편하고 테스트는 더 쉬워지고, 프로젝트는 살아납니다!

---

✅ 마무리 한 줄 요약

“좋은 아키텍처는 우연히 생기지 않습니다.
시스템 엔지니어의 전략과 설계 철학이 만든 작품입니다.”

---

🔜 다음 회차 예고

13회차에서는
“통합 테스트? 그냥 붙이면 되는 거 아냐?”
를 주제로
SYS.4 – 시스템 통합 및 테스트 설계의 현실적 어려움과
그 안에서 A-SPICE가 요구하는 품질 기준을 함께 알아봅니다!

설계는 시작일 뿐, 검증이 진짜 전쟁입니다!