Chapter06.송창욱

[songcw8]

🆕 새롭게 알게 된 점

✅ 기존에 몰랐던 개념이나 새로운 시각이 생긴 부분
✅ 책의 핵심 내용을 요약 & 정리

개발자는 결국 사용자의 니즈에 맞는 시스템을 개발하는 것이기 때문에 사용자의 요구를 시스템에 잘 반영하여 설계하기 위해서 이번 6장이 가지는 의미가 크다고 생각이 되었습니다. 그래서 6장의 내용을 잘 숙지해서 사용자 뿐만 아니라 개발자 간 협업을 하는데에 있어서도 잘 활용했으면 좋겠다는 마음을 가졌습니다.

📖 핵심 내용 요약

기능 설계 VS 구조 설계

• 기능 측면 설계 : 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춥니다.
• 구조 측면 설계 : 제품의 형태가 어떠해야 하는지에 초첨을 맞춥니다.

기능과 구조를 표현하기 위해 일관되게 적용할 수 있는 2가지 기법

• 도메인 모델링 : 구조를 수집하고 표현하기 위한 기법 -> 도메인 모델
• 유스케이스 모델링 : 기능을 수집하고 표현하기 위한 기법 -> 유스케이스

도메인 모델

도메인 모델은 사용자의 생각, 개발자의 설계, 시스템의 실제 동작을 하나의 설계도로 만들어낸 것입니다.
이 설계도는 곧 사람들이 시스템을 쉽게 이해할 수 있도록 도와주는 멘탈 모델 입니다.

---

💡 예시: 은행 앱의 계좌 이체

---

👤 사용자 모델 (사용자 생각)

"이체 버튼을 누르면 돈이 바로 넘어간다!"
사용자가 시스템에 대해 머릿속에 그리고 있는 모습

• 사용자는 내부 처리 과정을 몰라도 괜찮다고 생각함
• 이체는 단순한 버튼 클릭으로 끝난다고 여김

---

🛠️ 디자인 모델 (개발자의 설계)

“요청이 오면 출금 → 입금 → 기록 저장 → 완료 응답을 처리해야지.”

• 출금 계좌 잔액 확인
• 트랜잭션 생성 및 처리
• 입금 계좌 반영
• 오류 처리 및 결과 반환
• Account, TransferService, Transaction 등의 객체 설계

---

💻 시스템 이미지 (실제 시스템 동작)

"사용자에게는 이체 성공 메시지와 함께 완료 화면을 보여주자."
사용자에게 실제로 보이는 앱/시스템의 모습

• 사용자에게는 UI만 보여짐
  • 입력창: 받는 계좌번호, 이체 금액
  • 버튼: '이체하기'
  • 응답: '이체가 완료되었습니다!'

---

📐 그래서, 도메인 모델이란?

• 이 모든 것을 하나로 엮은 설계도
• 사용자의 생각도 반영하고,
  개발자의 설계도 포함하며,
  시스템이 실제로 동작하는 방식도 담고 있음

✅ 결론

• 도메인 모델은 사용자도, 개발자도, 기획자도 공통으로 이해할 수 있는 설계도이고, 이 설계도는 사람들이 시스템을 쉽게 떠올릴 수 있도록 돕는 멘탈 모델 역할을 합니다.

도메인의 모습을 담을 수 있는 객체지향

은행 예시

1. 사용자의 생각 (멘탈 모델)

"나는 계좌 이체를 하면, 내 통장에서 돈이 빠져나가고 상대방 통장으로 바로 들어갈 거야!"

2. 객체지향적 코드로 표현

객체지향에서는 현실의 개념들을 ‘객체’로 그대로 코드화 할 수 있습니다.

• Account(계좌) 객체
• TransferService(이체 기능) 객체
• Transaction(거래 내역) 객체

이렇게 현실에 있는 요소들을 그대로 코드로 만들 수 있습니다.

class Account {
    String accountNumber;
    int balance;

    void withdraw(int amount) {
        balance -= amount;
    }

    void deposit(int amount) {
        balance += amount;
    }
}

• 계좌 객체에는 입금, 출금 같은 실제 은행 업무가 메서드로 들어갑니다.
• TransferService는 이체 기능을 담당하는 객체로 구현됩니다.

class TransferService {
    void transfer(Account from, Account to, int amount) {
        from.withdraw(amount);
        to.deposit(amount);
    }
}

장점

• 현실에서 일어나는 방식과 코드가 매우 비슷하기 때문에
  사용자와 개발자, 기획자 모두가 같은 그림을 떠올릴 수 있습니다.
• 누가 봐도 transfer()는 ‘이체’, withdraw()는 ‘출금’이라는 걸 쉽게 이해할 수 있습니다.
• 코드 구조도 현실을 반영 하기 때문에 설명하기도 쉽고, 협업도 잘 할 수 있습니다.

결론

• 사용자와 개발자 사이의 현실 객체와 소프트웨어 객체 사이의 의미적 거리라고 하는 ‘표현적 차이’를 줄여줍니다.
• 결국 사용자가 이해하는 방식이 코드 구조가 되기 때문에,
  사용자에게도, 개발자에게도 더 명확하고 직관적인 소프트웨어를 만들 수 있게 해줍니다.

유스케이스

• 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것

유스케이스의 특성

• 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'입니다.
• 유스케이스 인스턴스라는 시나리오들의 집합입니다.
• 단순한 나열이 아니라 이야기를 통해 연관된 기능들을 함께 묶을 수 있습니다.
• 사용자 인터페이스와 관련된 세부 정보를 포함하지 않습니다.
• 내부 설계와 관련된 정보를 포함하지 않습니다.

코오번 - 목표를 활용한 유스케이스 구조화(Structuring Use Cases With Goals)

유스케이스 구조화의 핵심 아이디어

핵심 아이디어는 유스케이스를 사용자의 '목표(Goal)'를 중심으로 구조화하는 것입니다. 여기서 목표는 사용자가 시스템을 통해 이루고자 하는 특정한 결과입니다. 예를 들어, 은행 ATM 시스템의 유스케이스는 "고객이 현금을 인출한다"라는 목표를 가질 수 있습니다.

주요 개념 설명

이 논문에서는 다음과 같은 주요 개념들을 설명합니다.

• 액터(Actor): 시스템과 상호작용하는 외부 주체로, 사람 또는 다른 시스템일 수 있습니다. 위의 예시에서 고객이 액터가 됩니다.
• 상호작용(Interaction): 액터와 시스템 사이의 통신. 고객이 ATM에 카드를 넣고 비밀번호를 입력하는 등의 행위가 상호작용입니다.
• 시나리오(Scenario): 특정 조건 하에서 목표를 달성하거나 실패하는 일련의 상호작용의 순서입니다. 예를 들어, "고객이 유효한 카드를 넣고 비밀번호를 정확히 입력하여 현금을 인출하는 경우"는 성공 시나리오가 될 수 있고, "고객이 잔액보다 많은 금액을 인출하려 시도하는 경우"는 실패 시나리오가 될 수 있습니다.
• 유스케이스(Use Case): 특정 목표와 관련된 성공 및 실패를 포함한 가능한 모든 시나리오의 집합입니다. 따라서 하나의 "현금 인출" 유스케이스 안에는 정상적인 인출 시나리오뿐만 아니라 잔액 부족, 카드 오류 등 다양한 예외 상황에 대한 시나리오들이 포함될 수 있습니다.

유스케이스와 시나리오 정의

이 논문은 유스케이스와 시나리오를 언제 시작하고 언제 멈춰야 하는지 명확하게 정의하며, 시나리오가 너무 많아지는 것을 방지하기 위한 방법(하위 유스케이스, 확장, 변형)도 제시합니다. 또한, 목표는 여러 수준에서 존재할 수 있음을 강조합니다.

• 전략적 목표(Strategic Goal): 조직 전체의 목표 달성에 기여하는 시스템의 가장 상위 수준의 목표입니다. 예를 들어 "브랜드 가치 증진", "수익 증대", "고객 기반 확대"와 같은 목표가 될 수 있습니다.
• 요약 목표(Summary Goal): 여러 사용자 목표들을 묶어 놓은 것입니다. 예를 들어, "고객 서비스 품질 향상", "금융 상품 판매 관리", "계좌 운영 최적화"와 같은 목표가 될 수 있습니다.
• 사용자 목표(User Goal): 최종 사용자가 시스템을 통해 직접 수행하고자 하는 작업 목표로, "계과 관리", "거래 내역 확인하기" 등이 해당됩니다. 이 수준이 프로젝트에서 가장 중요하게 다뤄집니다.
• 하위 기능(Subfunction): 사용자 목표를 달성하기 위한 하위 단계 또는 재사용 가능한 기능으로, "로그인"이나 "본인 확인" 등이 있습니다.

요약

• 전략적 목표는 은행이라는 조직이 "궁극적으로 이루고자 하는 비전"입니다.
  → 예: 더 많은 지점을 내고, 수익을 늘리는 것
• 요약 목표는 이를 달성하기 위해 은행이 해야 하는 일들의 묶음입니다.
  → 예: 좋은 서비스 제공, 금융 상품 잘 팔기
• 사용자 목표는 고객이 은행에 와서 실제로 하려는 일입니다.
  → 예: 계좌 만들기, 돈 보내기, 대출받기
• 하위 기능은 사용자 목표를 이루기 위해 필요한 구체적인 행동입니다.
  → 예: 창구에서 서류 작성, 직원과 상담, 본인 확인

이러한 목표 수준을 이해하는 것은 유스케이스를 체계적으로 관리하고 사용자 요구사항을 명확하게 파악하는 데 도움을 줍니다.

목표 중심의 유스케이스 구조화의 이점

이 논문에서 제시하는 목표 중심의 유스케이스 구조화 방법은 다음과 같은 이점을 제공합니다.

• 요구사항 명확화: 사용자의 목표를 중심으로 시스템의 기능을 정의하므로 요구사항을 더 정확하게 파악할 수 있습니다.
• 프로젝트 관리 용이: 목표를 기준으로 프로젝트 진행 상황을 추적하고 관리할 수 있습니다.
• 오류 및 예외 상황 발견: 목표가 실패할 수 있는 다양한 경우를 고려함으로써 예상치 못한 상황에 대한 대비를 할 수 있습니다.
• 비기능적 요구사항 연결: 성능, 보안 등 비기능적 요구사항을 특정 목표와 연결하여 관리할 수 있습니다.
• 사용자 중심 설계: 최종 사용자의 업무 흐름과 목표에 맞춰 시스템을 설계할 수 있습니다.

결론

이 논문은 사용자의 목표를 중심으로 유스케이스를 구조화하는 방법을 제안합니다.
이를 통해 요구사항을 명확히 이해하고, 사용자 중심의 시스템을 효과적으로 설계할 수 있다고 강조합니다.
다만,

• 목표 수준의 구분 혼란
• 다양한 데이터 형식 처리
• 부분적인 목표 달성 문제
  같은 남은 과제들도 존재함을 언급합니다.

문제 항목	설명
🎯 목표 수준의 구분 혼란	전략적 목표, 사용자 목표, 하위 기능 등 목표 수준이 헷갈리는 경우가 있어, 명확한 구분 기준이 필요함
📊 다양한 데이터 형식 처리	유스케이스에서 사용하는 데이터 형식이 서로 달라 일관성 있게 처리하기 어려움
⚠️ 부분적인 목표 달성 문제	사용자의 목표가 실패하거나 일부만 달성되는 상황을 유스케이스에 반영하는 것이 필요함

재료 합치기 : 기능과 구조의 통합

• 유스케이스에서 사용자의 목표와 시스템에 대한 첫 번째 메시지를 파악하고,
• 도메인 모델에서 기능을 수용할 수 있는 안정적인 구조를 가져와,
• 이를 바탕으로 실제 작동하는 객체들의 협력 구조를 설계해야 한다.

왜 도메인 모델을 기반으로 설계할까?

• 도메인 모델은 변화에 강한 구조를 제공한다.
• 도메인 모델을 구성하는 개념들은 비즈니스 자체가 사라지지 않는 이상 지속적으로 유지됨.
• 개념 간의 관계는 비즈니스 규칙에 기반하므로, 정책이 크게 바뀌지 않는 한 안정적으로 유지됨.

결론

• 유스케이스는 "무엇을 해야 하는가?"에 대한 방향을 제공하고,
• 도메인 모델은 "어떻게 구조화할 것인가?"에 대한 기반을 제공한다.
• 이 둘을 통합하여 책임-주도 설계로 객체들의 협력을 구성하면,
  결과적으로 유지보수에 강하고 유연한 시스템을 만들 수 있다.

---

❓ 어려웠거나 이해가 부족했던 부분

🔍 명확히 이해되지 않은 개념
🔍 다른 사람과 토론해보고 싶은 부분

💭 궁금한 점

• (이해되지 않는 부분 정리)
• (다른 접근 방식이 있을지 고민)

💡 토론해 보고 싶은 질문

• "이 개념이 실제 코드에서는 어떻게 쓰일까요?"
• "이걸 다르게 접근할 수도 있지 않을까요?"
• "기술 면접 대비: 제가 면접관이라면 이 부분에서 이런 질문을 할 것 같아요."

---

🌟 인상 깊었던 책의 내용

📝 특히 기억에 남는 문장이나 사례
📝 왜 인상 깊었는지, 어떻게 적용할 수 있을지 고민

📌 기억에 남는 문장

"요구사항들을 식별하고 도메인 모델을 생성한 후, 소프트웨어 클래스에 메서드들을 추가하고, 요구사항을 충족시키기 위해 객체들 간의 메시지 전송을 정의하라."

이 내용이 1장 부터 6장까지의 내용들을 하나의 문장으로 함축시킨 것 같아서 기억에 남았습니다.

🔎 적용 방법 고민

• (이 내용을 어떻게 적용할 수 있을지 생각 정리)

---

📚 관련 아티클 & 추가 자료

📌 다른 사람이 이해하는 데 도움이 될 만한 자료 첨부
📌 논문, 블로그, 영상, 실무 사례 등 공유

🔗 추천 자료

• 📄 [관련 논문 또는 공식 문서 링크]
  논문 - Structuring Use Cases with Goals.pdf
  시나리오가 너무 많아지는 것을 방지하기 위한 방법(하위 유스케이스, 확장, 변형)
  https://notebooklm.google.com/notebook/80e67731-d568-48b0-bd24-fd90e61f0a1c?_gl=1*123cq9q*_up*MQ..*_ga*MTM3MDUxMTU0OC4xNzQzOTMwNjY5*_ga_W0LDH41ZCB*MTc0MzkzMDY2OC4xLjAuMTc0MzkzMDY2OC4wLjAuMA..

• 🎥 [관련 영상 링크]

• 📝 [관련 블로그 글 링크]