[SW Engineering] 07. 디자인과 구현(Design and Implement)

아키텍처가 건물의 뼈대라면, 설계 및 구현은 실제 배관, 전기 배선, 인테리어를 하고 벽돌을 쌓는 과정입니다. 이번 포스팅에서는 객체지향 설계 프로세스, 디자인 패턴, 그리고 구현 단계의 주요 이슈들을 정리합니다.

1. 설계와 구현의 관계

• 정의: 소프트웨어 설계와 구현은 실행 가능한 소프트웨어 시스템을 개발하는 단계입니다.
• 상호작용: 설계(Design)와 구현(Implementation)은 칼로 자르듯 나뉘지 않고, 서로 맞물려(Inter-leaved) 진행됩니다.
  • 설계: "쇼핑몰의 장바구니 기능은 어떤 데이터가 필요하고, 결제 시스템과는 어떻게 연결될까?"를 고민하는 창의적 활동.
  • 구현: 설계를 바탕으로 실제 Java나 Python 코드를 작성하는 과정.

1) 직접 개발 vs 구매 (Build or buy)

현대 소프트웨어 공학에서는 모든 것을 바닥부터 개발하지 않습니다.

• COTS (Commercial-off-the-shelf): 시중에 나와 있는 솔루션이나 패키지를 구매하여 내 입맛에 맞게 설정(Configuration)하여 사용하는 경우가 많습니다.
• 🛒 예시:
  • 직접 개발 (Build): 우리 회사만의 독특한 결제 로직이 필요해서 결제 시스템을 처음부터 코딩함. (비쌈, 오래 걸림)
  • 구매 (Buy): 병원에서 쓸 환자 관리 시스템이 필요할 때, 직접 개발하는 대신 이미 잘 만들어진 '의료용 ERP 솔루션'을 사서 우리 병원 이름만 넣고 씀. (저렴, 빠름)

 

2. 객체지향 설계 (Object-Oriented Design)

객체지향 설계는 시스템을 상호작용하는 객체들의 집합으로 모델링하는 프로세스입니다. 주로 UML(Unified Modeling Language)을 사용합니다.

1) 주요 프로세스 단계와 예시 (쇼핑몰 시스템)

다른 글에서는 '기상 관측소(Weather Station)'를 예로 들지만, 더 와닿는 쇼핑몰로 설명해 드릴게요.

1. 시스템 문맥 파악 (Context & Modes of use):
   • 시스템의 경계(Boundary)를 정합니다.
   • 예시: "우리 쇼핑몰 시스템은 택배사 시스템, 은행 결제 시스템과 연결되어야 해."
2. 아키텍처 설계 (Architecture Design):
   • 주요 컴포넌트를 식별합니다.
   • 예시: "웹 서버, 고객 데이터베이스, 상품 관리 모듈로 나누자."
3. 객체 식별 (Object Identification):
   • 시스템 내의 주요 객체를 찾아냅니다.
   • 예시: 고객(Customer), 상품(Product), 주문(Order), 장바구니(Cart) 등이 객체가 됩니다.
4. 디자인 모델 개발 (Design Models):
   • 구조와 동작을 모델링합니다.
   • 예시: "고객이 '주문 버튼'을 누르면(Sequence), 주문 객체가 생성되고 상품 재고가 1 줄어든다(State)."
5. 인터페이스 명세 (Interface Specification):
   • 객체 간의 대화 규칙을 정합니다.
   • 예시: "주문 객체는 결제 객체에게 processPayment(amount)라는 함수만 호출할 수 있다."

 

2) 객체를 식별하는 방법 (Approaches to identification)

객체를 찾는 데 정해진 공식(Magic formula)은 없지만, 다음 팁을 활용하세요.

• 문법적 접근: 요구사항 명세서에서 명사(Noun)는 객체로, 동사(Verb)는 메서드(행동)로 봅니다.
  • *"고객(명사)이 상품(명사)을 주문한다(동사)" → Customer, Product 객체 / order() 메서드*
• 유형물 기반: 현실 세계의 물리적인 사물(자동차, 센서 등)을 그대로 객체로 만듭니다.

 

3) 객체 지향 설계에 도움이 되는 책

https://product.kyobobook.co.kr/detail/S000001628109?utm_source=google&utm_medium=cpc&utm_campaign=googleSearch&gt_network=g&gt_keyword=&gt_target_id=aud-901091942354:dsa-435935280379&gt_campaign_id=9979905549&gt_adgroup_id=132556570510&gad_source=1

객체지향의 사실과 오해 | 조영호 - 교보문고

객체지향은 그 자체만으로 내용이 너무 방대하고 많기 때문에 이 책을 읽으면서 각 객체의 책임과 역할을 어떻게 할당할지 고민해보는 것을 권장합니다.

 

3. 디자인 패턴 (Design Patterns)

디자인 패턴은 선배 개발자들이 수많은 시행착오 끝에 찾아낸 "자주 발생하는 문제에 대한 모범 답안(Best Practice)"입니다.

1) 대표 패턴: 옵저버 (Observer Pattern)

• 상황: 하나의 데이터(주제)가 변했을 때, 이를 지켜보는 여러 화면(관찰자)들이 동시에 업데이트되어야 할 때.
• 📢 구체적 예시 (유튜브 구독 알림):
  • Subject (유튜버): "새 영상이 올라왔습니다!"라고 상태를 변경함.
  • Observer (구독자들): 수백만 명의 구독자 스마트폰에 동시에 '딩동!' 하고 알림이 뜸.
  • 핵심: 유튜버는 누가 구독했는지 일일이 알 필요 없이, 그냥 "알림 보내기"만 하면 구독자들이 알아서 반응함.

2) 기타 유용한 패턴

• Facade (건물 외벽): 복잡한 내부 배선은 감추고 깔끔한 스위치 하나만 밖으로 빼주는 것.
  • 예: 복잡한 DB 연결, 로깅, 보안 체크 코드를 다 숨기고 login() 함수 하나만 제공.
• Iterator (반복자): 책장에 책이 어떻게 꽂혀있든(배열이든 리스트든) 상관없이 "다음 책, 그다음 책" 순서대로 꺼낼 수 있게 해주는 것.
• Decorator (장식): 빵(기본 객체) 위에 생크림을 얹고(기능 추가), 그 위에 체리를 얹는(기능 또 추가) 것처럼 실행 중에 기능을 덧붙이는 패턴.

---

4. 구현 이슈 (Implementation Issues)

코딩 외에도 구현 단계에서 중요하게 다뤄야 할 3가지 이슈가 있습니다.

1) 재사용 (Reuse)

현대 소프트웨어는 레고 블록 조립과 같습니다. 남이 만든 좋은 블록(라이브러리)이 있다면 가져다 쓰는 게 이득입니다.

• 비용: 단순히 공짜가 아닙니다. 내 프로젝트에 맞는지 찾는 시간, 배우는 시간, 안 맞으면 수정하는 비용을 고려해야 합니다.

2) 형상 관리 (Configuration Management)

수많은 코드 변경 내역을 관리하는 것입니다.

• 🛠️ 예시 (Git): "어제 짠 코드가 더 나은데? 되돌리자."라거나, "철수가 짠 코드랑 내가 짠 코드가 충돌났네?" 같은 상황을 해결해 주는 도구입니다. 버전 관리, 시스템 통합, 버그 추적 등을 포함합니다.

3) 호스트-타겟 개발 (Host-target development)

• 상황: 개발은 고성능 데스크탑(Host)에서 하지만, 실제 프로그램은 스마트폰이나 자동차 내비게이션(Target)에서 돌아가는 경우입니다.
• 이슈: 내 컴퓨터(Host)에선 잘 돌아가는데, 성능이 낮은 스마트폰(Target)에선 버벅거리거나 배터리를 광탈시킬 수 있으므로 이를 고려해 시뮬레이터 등을 사용해야 합니다.

---

5. 오픈소스 개발 (Open Source Development)

소스 코드를 전 세계에 공개하고 자원봉사자들과 함께 개발하는 방식입니다 (예: Linux, Java, Apache). 하지만 "공짜라고 막 갖다 쓰면 큰일" 날 수 있습니다. 바로 라이선스 때문입니다.

라이선스 모델 (License Models) 비교

라이선스	비유 (요리 레시피)	의무 사항
GPL (엄격)	"내 비법 소스 썼어? 그럼 너도 네 요리 전체 레시피를 무조건 공개해!"	내가 만든 소프트웨어의 전체 소스 코드도 무조건 공개해야 함 (전염성).
LGPL (중간)	"내 소스를 그대로 썼으면 그것만 공개하고, 네가 덧붙인 요리법은 비밀로 해도 돼."	라이브러리 자체를 수정한 경우만 공개. 내 프로그램 소스는 공개 안 해도 됨.
BSD / MIT (관대)	"내 레시피 맘대로 써. 대신 메뉴판 구석에 '원조: 김씨네'라고 이름만 써줘."	소스 공개 의무 없음. 상용 소프트웨어에 자유롭게 포함해서 팔아도 됨.

---

요약: 설계와 구현은 반복적인 과정입니다. '쇼핑몰'을 만든다고 상상하며 객체를 찾고(OOD), '유튜브 알림' 같은 상황에 옵저버 패턴을 적용하며, 남이 만든 코드(Reuse/Open Source)를 가져다 쓸 때는 '저작권(라이선스)'을 꼼꼼히 확인하는 것이 훌륭한 엔지니어의 자세입니다!