• Software Engineering Chapter5 공부 및 내용 정리

• 소감

Software Engineering Chapter5 공부 및 내용 정리

David C.Kung의『Object-Oriented Software Engineering』Chapter5를 읽고 정리했다. Chatper5를 정리한 포스트이다.

소감

도메인 모델링은 사용자와의 소통이 가장 중요하며 팀이 다함께 진행해야 한다는 것을 알 수 있었다. 또한 association, inheritance 등 다양한 기법으로 풀어나갈 수 있다는 것을 배웠다. 소프트웨어공학 수업에서 진행하는 프로젝트에 잘 적용시켜봐야겠다.

Key Takeaway Points

• 도메인 모델링은 개발팀이 어플리케이션 도메인을 이해하는 데 도움을 주기 위한 개념화 과정이다.
• 도메인 모델링은 5가지 단계로 이루어진다.
  1. 어플리케이션 도메인에 대한 정보 수집
  2. 브레인스토밍
  3. 브레인스토밍 결과 분류
  4. UML 클래스 다이어그램을 사용해 도메인 모델 시각화
  5. 도메인 모델에 대한 검사 및 검토 수행

1. What is Domain Modeling?

도메인 모델링은 개념화 과정이다. 중요한 도메인 개념, 속성 및 개념 간 관계를 식별하는 것을 목표로 한다. 결과는 도메인 모델이라고 하는 다이어그램으로 묘사한다. 개념화 과정에는 관찰, 분류, 추상화, 일반화 등이 포함된다.

2. Why Domain Modeling?

소프트웨어 엔지니어들은 서로 다른 배경과 경험을 가져 어플리케이션에 대한 인식도 다르다.

• 도메인 모델의 구축은 인식의 차이를 확인하고, 해결하는데 도움을 준다.
• 도메인에 대한 공통적인 인식을 정의하고 의사소통을 효율적으로 할 수 있다.
• 개발팀이 고객/사용자에게 인식을 전달하고, 피드백을 구할 수 있다.

3. Object-Orientation and Class Diagram

3.1. Extensional and Intentional Definitions

개발자는 어플리케이션의 특정 인스턴스를 관찰하고, 도메인 모델이라 불리는 개념적 모델을 생성하기 위해 관찰한 인스턴스를 분류하고, 추상화하고, 일반화한다.

• extensional definition은 개념의 인스턴스를 열거하여 개념을 정의한다. 예를 들면, '개'에 대한 extensional definition은 옆집 개, 공원에서 산책하는 개 등으로 구성된다.
• intentional definition은 개념의 인스턴스가 가지고 있는 attribute 및 operation을 지정함으로써 개념을 정의한다.
• UML class diagram은 클래스와 클래스의 attribute와 operation, 클래스 간 관계를 설명하는 구조 다이어그램이다.
  

3.2. Class and Object

• 클래스는 개념의 intentional definition인 유형이다. 클래스는 클래스의 인스턴스를 특정짓는 attribute와 operation을 캡슐화한다. 객체는 클래스의 인스턴스이다.
  

3.3. Object and Attribute

3.4. Association

association은 하나 이상의 클래스 간 관계이다. 한 클래스의 객체가 다른 클래스의 객체와 연관될 수 있다고 명시한다. ex. 은행 시스템에서 고객은 계정을 소유한다. → 고객 클래스와 계정 클래스는 연관 관계이다.

3.6. Aggregation

aggregation은 두 클래스 간 이진 관계이다. 한 클래스의 개체는 다른 클래스의 개체의 일부임을 나타낸다. ex. 책은 챕터로 구성되어있고, 챕터는 섹션으로 구성된다. ex. 엔진은 자동차의 일부이다.

3.7. Inheritance

inheritance는 두 개념 또는 클래스 간 이진 관계로, 하나의 개념 또는 클래스는 다른 하나의 일반화(또는 전문화)이다. ex. Account의 일반화/전문화

• Account는 Checking Account, Saving Account의 일반화이고, Checking Account, Saving Account는 Account의 전문화이다.
  

3.8. Inheritance and Polymorphism

polymorphism은 한 가지가 다른 형태를 취할 수 있다는 것을 의미한다. 공통 인터페이스를 사용해 Saving Account, Checking Account 같은 다양한 유형의 계좌를 처리할 수 있고, 특정 계좌 유형에 상관없이 자금 예금/인출 같은 작업을 수행할 수 있다.

inheritance과 polymorphism은 비슷해보이지만 다르다.

• inheritance는 한 클래스가 다른 클래스보다 일반화 또는 전문화되어 있다.
• polymorphism은 한 객체가 여러 형태를 가진다.

inheritance는 클래스 간 계층 구조를 정의하고, 코드의 재사용을 촉진한다. polymorphism은 객체가 여러 다른 형태를 가질 수 있음을 나타내고, 같은 인터페이스를 통해 다양한 객체를 처리할 수 있도록 한다.

3.9. Association Class

만약 학생이 여러 개의 강좌를 등록한다면, 각 강좌에 대한 성적이 나온다. 성적이 학생 클래스의 속성이라면, 한 학생이 여러 개의 강좌를 등록하는 것이 가능하기 때문에 학생 클래스는 여러 개의 성적 속성을 가져야 한다. 어떻게 모두 다른 강좌의 성적 속성을 차별화할 수 있을까? association class를 활용해 이를 해결할 수 있다.

association class는 association 인스턴스에 대한 속성과 동작을 정의하는 특수 클래스다. 학생과 강좌 사이의 등록 연관성을 위해 등록이라고 하는 연관 클래스를 정의한다. 등록에는 성적 및 학기 속성을 포함한다. 학생이 강좌를 3개 등록한다면, 인스턴스가 3개 생성된다.

6. Guidelines For Domain Modeling

모든 팀원들은 브레인스토밍과 분류를 개별적으로 하지 않고, 팀으로 수행해야 한다. 그래야 공통된 이해를 구축할 수 있다.

• 브레인스토밍을 먼저하고, 분류를 해야 한다.
• 각각의 브레인스토밍과 분류 세션은 한 시간에서 두 시간 정도 지속되어야 한다.
• 각각의 브레인스토밍과 분류 세션은 효과적으로 조정되어야 한다.
• 브레인스토밍과 분류 세션이 진행되는 동안 UML class diagram을 그려선 안된다.
  

7. Applying Agile Principles

• 고객/사용자와 협력해서 어플리케이션 및 도메인을 이해한다. 요구사항을 이해하는 것은 어플리케이션과 도메인을 얼마나 이해하는지에 달려있다.

• 팀이 어플리케이션 도메인을 이해해야 하는 경우에만 도메인 모델링을 수행한다. 도메인 모델링은 단순하게 유지하고 점진적으로 확장한다.

• 도메인 모델링은 actor-system interaction modeling, object interaction modeling, object state modeling, and/or activity modeling과 동시에 수행될 수 있다. 모델링 시, 모든 도메인 지식을 다 알려고 하는 것은 시간이 너무 많이 걸릴뿐더러 후속 단계에서 누락된 부분을 발견할 수 있기 때문에 불필요하다. 이는 모델링 프로세스가 역추적을 포함하는 반복적 프로세스임을 의미한다.

• Software Engineering Chapter4 공부 및 내용 정리

• 소감

Software Engineering Chapter4 공부 및 내용 정리

David C.Kung의『Object-Oriented Software Engineering』 Chapter4를 읽고 정리했다. Chatper4를 정리한 포스트이다.

소감

요구사항 도출의 중요성과 절차에 대해 공부했다. 이번 캡스톤 프로젝트 기획 단계에서 굉장히 많은 시간을 소요했고, 개발 과정에서도 기획이 여러 차례 변경되었다. 책을 통해 어떤 부분들이 잘못되었는지 되짚어볼 수 있어 매우 유익했다.

Key Takeaway Points

• 요구사항은 시스템이 제공해야하는 기능이다.
• 소프트웨어 시스템을 구축할 때, 가장 어려운 부분은 무엇을 구축할 것인지다. 즉, 요구사항을 정확하게 결정하는 것이다.
• 소프트웨어 요구사항 도출은 시스템의 실제 요구사항을 식별하는 것을 목표로 한다.

요구사항 도출이 중요한 이유는 솔루션 공간에 대한 제약사항뿐만 아니라 시스템 기능을 정의하기 때문이다. 후속 개발 활동의 기초를 형성하기 때문에 요구사항을 잘 도출해야 한다.

1. What is Requirements Elicitation?

소프트웨어 요구사항은 시스템이 제공해야 하는 기능이다. 하나의 소프트웨어는 요구사항 충족, 예산 내 이행, 예정한 시간 내 제공, 모든 것이 만족되어야 성공할 수 있다. 그러나 이해관계자마다 비즈니스 우선 순위와 필요한 시스템 역량에 대해 다르게 인식한다.

소프트웨어 요구사항 분석은 시스템이 요구사항과 제약조건을 충족하는지 확인해야 한다. 요구사항(Requirement)과 제약조건(Constraint)의 주요 차이점은 솔루션 공간에 제약이 생기는지의 유무라고 할 수 있다. 제약조건은 설계와 구현 대안의 수를 줄인다.

예를 들면, 고객이나 정부 기관은 종종 소프트웨어 시스템에 제약을 가한다.

• 특정 제품 사용 금지
• 특정 프로그래밍 언어로 구현할 것.

이런 사항들은 정치적, 비즈니스적인 이유로 솔루션 공간을 제약한다.

2. Importance of Requirements Elicitation

세부적인 기술 요구 사항을 잘못 설정하면, 결과적으로 시스템을 마비시킨다. 추후 수정하는 것은 더욱 어렵다.

3. Challenges of Requirements Elicitation

1. 개발팀은 application domain에 대해 충분히 알지 못한다. Agile Method가 고객과의 협업, 사용자 참여를 강조하는 이유도 필요한 도메인 지식을 습득하는데 효과적이기 때문이다.

2. 고객과 사용자들은 소프트웨어가 무엇을 할 수 있고, 그들의 요구를 어떻게 표현해야할지 모른다. 긴밀한 협업으로 요구사항을 잘 도출해야 한다.

3. 공통된 배경이 부족하면 팀과 고객/사용자 간 의사소통 장벽이 형성된다. 서로의 분야에 대한 이해가 부족하다.

4. 소프트웨어 요구사항을 명확하게 지정할 수 없으며, 사양과 구현을 분리할 수 없다.

5. 요구사항 도출의 중요성과 어려움이 종종 과소평가된다.

6. 비기능적 요구사항은 식별하지 않거나 과소평가되는 경우가 많다. 비기능적 요구사항은 performance, quality, security 등 신뢰성과 관련된 영역이 포함된다.

7. 대상 환경에서 작동한 후에도 요구사항은 변경될 수 있다.

5. Steps For Requirements Elicitation

Ethnography는 비즈니스 조직의 외부가 아닌 내부에서 관찰하는 것을 말한다. 팀은 사용자를 이해하고 사용자처럼 생각해야 한다. 사용자가 어떻게 일하고, 어떻게 비즈니스 문제를 해결하는지 주의깊게 관찰해야 한다. 이를 위한 User Story는 요구사항 수집 방법으로 Agile method에서 널리 사용되고 있다.

• User Story는 사용자들에 의해 제작되거나 개발팀과 공동으로 제작한다.
• 각각의 User Story는 사용자 역할이 갖고 싶어하는 능력을 간략히 설명한다.
• 각각의 사용자 역할은 여러 개의 사용자 이야기를 가질 수 있다.

사용자 역할 : 의사 사용자 이야기

• 환자와의 모든 대화를 기록해야 한다.
• 특정 정보를 찾기 위해 종종 환자와의 대화를 검색해야 한다.
• 환자의 의료 검사 기록을 검색해야 한다.

6. Applying Agile Principles

Agile은 비즈니스 우선순위가 높고, 비즈니스 가치가 높은 mission-critical한 요구사항을 식별하고 검증하고 지정하는 데 초점을 맞춘다. 세부사항을 명시하지 않고, 모든 요구사항을 미리 확보하지도 않는다. 100% 정확할 필요도 없다. 요구사항이 언제든 변경될 수 있음을 인지한다. 짧은 반복 주기와 작은 증분을 갖기 때문에 변화에 더 유연하게 대응할 수 있다.

• Flutter Responsive UI 공부 및 정리

• 소감

Flutter Responsive UI 공부 및 정리

캡스톤 프로젝트에서 적용하기 위해 반응형 UI에 대해 공부한 후 블로그에 포스팅했다. Responsive UI에 대해 정리한 포스트다.

소감

생각보다 더 다양한 방법이 있어 분석하는데 재미있었다. 우리 프로젝트에 가장 적합한 방법이 무엇인지 더 알아보고 적용해야겠다.

일반적으로 반응형 앱은 화면 크기에 맞게 레이아웃을 조정한다. 사용자가 창 크기를 조정하거나 장치의 방향을 변경하는 경우 UI를 다시 배치하는 것을 의미한다. 스마트폰, 태블릿, 시계, 데스크톱 등 다양한 사이즈의 장치에서 동일한 앱을 실행시키는 경우 필요하다.

반응형 적용

1. flutter 자체 제공 component

별다른 package 설치하지 않아도 flutter에서 제공하는 component들을 사용해 반응형을 적용할 수 있다. flutter 공식 홈페이지에서는 MediaQuery와 LayoutBuilder로 반응형을 구현하고 있다.

MediaQuery

현재 앱의 크기와 방향을 알 수 있다. 특정 위젯의 크기보다는 전체 맥락을 기반으로 의사 결정을 내리고 싶을 때 더 유용하다. 사용자가 앱의 크기를 변경하면 빌드 기능이 자동으로 실행된다.

Container(
    width : MediaQuery.of(context).size.width
    height : MediaQuery.of(context).size.height
)

LayoutBuilder

장치의 높이, 가로 세로 비율 또는 기타 속성을 기반으로 디스플레이를 조정할 수 있다. builder의 BoxConstraints를 가져와 표시할 항목을 결정한다. maxWidth가 개발자가 지정한 width breakpoint(아래 코드에서는 600)보다 크면, wide한 widget을 빌드한다. 태블릿이나 데스크톱이 여기에 해당한다.

LayoutBuilder(
    builder: (BuildContext context, BoxConstraints constraints) {
        if (constraints.maxWidth > 600) {
            return _buildWideContainers();
        } else {
            return _buildNormalContainer();
        }
    },
)

2. 라이브러리

라이브러리는 보통 flutter에서 제공하는 component보다 간단한 배치와 짧은 코드로 반응형을 적용할 수 있게 해준다. pub.dev에 responsive로 검색하면 많은 라이브러리가 나온다. 그 중 사용법과 반응형이 제공되는 범위를 확인해보고, 각자의 필요에 맞추어 사용하면 된다.

MediaQuery의 경우, widget을 모듈화할 때 width와 height를 지정해주려면 context를 parameter로 받아야 한다. 라이브러리를 사용하면 context를 따로 넘겨주지 않아도 되어 간편하다.

3. GetX

GetX의 GetResponsiveView 위젯을 사용하면 반응형을 적용할 수 있다. 이 위젯에는 화면 크기 및 유형에 대한 모든 정보가 포함된 화면 속성이 포함되어 있다. desktop, tablet, phone, watch 등 메소드가 정의되어있어, 화면 유형과 메소드가 일치할 때 자동 빌드된다. 예를 들어, 실제 화면이 태블릿일 때와 ScreenType.Tablet 메소드가 일치하면서 빌드된다.

구체적인 사용법은 get_examples github에서 확인할 수 있다.

[참고자료] https://docs.flutter.dev/ui/layout/responsive/adaptive-responsive https://pub.dev/packages?q=responsive https://pub.dev/packages/get#getresponsiveview

• Software Engineering Chapter3 공부 및 내용 정리

• 소감

Software Engineering Chapter3 공부 및 내용 정리

David C.Kung의『Object-Oriented Software Engineering』 Chapter3를 읽고 정리했다. Chatper3를 정리한 포스트이다.

소감

하드웨어, 소프트웨어, 인적 구성 요소가 포함된 하나의 큰 시스템을 구성하려면 어떻게 해야하는지 배울 수 있었다. 전체 시스템을 잘 설계해야 변경 제어나 상호작용에서 문제가 발생하지 않는다는 것을 예시로 학습할 수 있었다.

Key Takeaway Points

• 시스템 엔지니어링은 하드웨어, 소프트웨어 및 인적 구성 요소를 포함하는 시스템을 개발하기 위한 다학제간 접근이다.
• 시스템 엔지니어링은 시스템에 대한 요구사항과 제약조건을 정의한다. 하드웨어, 소프트웨어, 인적 시스템에 요구사항을 할당하고, 하위 시스템을 통합해 시스템을 구성한다.
• 소프트웨어 엔지니어링은 시스템 엔지니어링의 일부분이다.

시스템을 어떻게 설계하고 기존 데이터베이스, 비즈니스 프로세스와 통합할 것인지 시스템 엔지니어링 접근 방식이 필요하다.

이번 장에서 다루는 내용은 아래와 같다.

• 시스템 엔지니어링 프로세스
• 시스템 모델링과 디자인 기술
• 서브시스템에 시스템 요구사항 할당
• 시스템 구성 관리

1. What is a System?

시스템은 목적을 달성하기 위해 상호작용하는 구성 요소로 구성된다. 모든 시스템은 아래 속성 또는 특성을 공유한다.

• 각 시스템은 상호작용, 상호연관되는 서브시스템, 구성 요소 또는 요소의 집합으로 구성된다.
• 시스템은 다른 시스템의 서브시스템일 수 있다.
• 각 시스템은 환경에 존재하며, 환경과 상호 작용한다.
• 시스템은 내부적 또는 외부적 원인들로 항상 진화한다.

2. What is System Engineering?

시스템 개발은 학제간의 노력이다. 하드웨어, 소프트웨어, 인적 자원 개발을 포함한다. 시스템 공학은 이러한 질문들에 대답하는 공학 분야이다.

• 우리는 그러한 시스템들에 대한 시스템 요구사항들을 어떻게 확인하고 공식화할 것인가?
• 우리는 어떻게 그러한 시스템들을 설계하고 구성할 것인가?
• 우리는 어떻게 개발 활동들을 관리할 것인가?
• 우리는 그러한 시스템들의 성능, 신뢰성, 안전성, 그리고 다른 요소들을 어떻게 측정할 것인가?
• 우리는 어떻게 시스템이 사회와 환경에 미치는 영향을 평가할 것인가?

시스템 공학은 다음과 같은 요소들을 강조한다.

1. 시스템의 전체 라이프 사이클을 다루는 시스템 엔지니어링 프로세스이다.
2. Top-Down Divide-and-Conquer 접근을 사용한다.
3. 시스템 개발에 대한 학제 간 접근이 필요하다.

시스템 엔지니어링 프로세스의 단계

1. 비즈니스 요구사항을 식별하고, 요구사항은 비즈니스 문제를 해결하는데 필요한 시스템의 기능을 지정한다.
2. 아키텍처는 기능을 제공하는 법 또는 솔루션 초안 제시한다. 하위 시스템들 간의 관계를 묘사한다.
3. 하위시스템 기능 및 인터페이스를 지정한다. 하위 시스템이 서로 상호작용하는 방식을 지정한다.
4. 서브시스템은 각 엔지니어링 팀에서 동시에 개발된다.
5. 시스템 통합, 테스트, 개발, 유지 과정을 거친다.

3. System Requirements Definition

3.1. Identifying Business Needs

비즈니스 요구 파악은 정보 수집 활동에서 시작된다. 비즈니스 목표와 현재 비즈니스 상황에 대한 정보를 수집한다. 현재 상황과 비즈니스 목표 사이의 격차를 파악하고 비즈니스 요구를 도출한다.

정보 수집 기법

1. Customer presentation 개발팀에게 고객 업무를 소개해 초기 도메인 개념을 제공한다.
2. Study of current business operations 현재 비즈니스 운영에 대한 연구를 진행한다.
3. User Survey 새로운 시스템에 대한 사용자의 의견과 기대를 얻는 데 유용하다.
4. User Interview 설문조사에서 얻기 어려운 정보를 얻는 데 유용하다.
5. Literature survey

4. System Arcitectural Design

아키텍처는 중요한 요소를 명시하고 요소들 간 관계를 표현한다. Complexity와 Cost를 줄이는 것을 목표로 한다. 시스템 아키텍처 디자인은 아래의 활동들로 수행된다.

1. 시스템을 서브시스템들로 분해한다. 각 분야 엔지니어들이 서브 시스템을 개발한다.
2. 시스템 요구사항을 하위 시스템에 할당한다. 하위 시스템 간 공유되는 요구사항의 수를 줄이는 것을 목표로 한다. 하위 시스템의 책임이 명확하게 정의되어야 한다. 할당된 요구사항은 기능적으로 관련되어야한다.
3. 시스템 아키텍처를 시각화한다.

4.1. System Decomposition

시스템 분해는 다음 목표들을 달성하는 것을 목표로 한다.

1. 엔지니어링 팀이 하위 시스템을 개발할 수 있어야 한다.
2. 상용 기성품(COTS) 부품 사용이 용이해야 한다.
3. 시스템 요구사항을 분할해야한다.
4. 잘 정의된 기능을 가져야 한다.
5. 비교적 독립적이어야 한다. 다른 서브시스템에 영향을 미치지 않도록 해야한다.
6. 통합하기 쉬워야 한다. 서브시스템들은 간단한 인터페이스와 상호작용 동작을 거쳐 통신을 단순화해야 한다.

4.2. Requirements Allocation

Traceability Matrix은 개발 프로세스 전반에 거쳐 요구사항을 추적한다.

Traceability Matrix의 장점

• 모든 요구사항이 하위 시스템에 할당되어있는지 확인 가능하다.
• 할당이 적절한지 확인 가능하다. 요구사항을 여러 서브 시스템에 할당하는 것은 서브 시스템 간 기능을 나누는 것이 어려워 피해야 한다. Row에 표시가 많으면 요구사항 분해가 필요하다.
• 어떤 요구사항이 하위 시스템에 할당되어있는지 확인 가능하다.
• 너무 많은 책임이 할당되어있는지 확인 가능하다. Column에 표시가 많으면 책임이 너무 많다는 의미이다. 요구사항 분산을 위해 하위 시스템을 분해할 필요가 있다.
• 서브 시스템의 기능 응집력을 확인할 수 있다. 할당된 요구사항은 기능적으로 관련이 있어야 한다. Column에 표시된 요구사항이 관련 없으면, Column으로 표시된 서브 시스템은 기능적 응집력이 낮다. 요구사항은 여러 기능적 클러스터로 분할하고, 서브시스템은 기능적 클러스터에 해당하는 기능적 서브 시스템으로 분해되어야 한다.

7. System Configuration Management

변경 제어는 조정해야하는 이슈다. 만약 전자 부품의 설계가 변경된다면, 소프트웨어 부품 설계도 함께 변경해야 한다. 그래서 통지 메커니즘이 필요하다. 설계 변경이 잦으면 대처가 어렵고, 아예 변경할 수 없으면 결함, 오류를 수정할 수 없다. 이런 문제들을 시스템 구성 관리를 통해 해결할 수 있다.

시스템 구성 관리는 아래 네 개의 메인 기능들로 구성된다.

1. 구성 항목 식별 프로젝트 기준선 및 관련 구성 항목을 정의한다. ex. 요구사항 기준선, 설계 기준선, 할당 기준선 기준선은 모든 관련 구성 항목이 구성 관리 시스템에 체크인될 때 설정된다. 요구사항 기준선은 SRS와 프로젝트 계획서로 구성된다면, 두 문서 모두 구성 관리 시스템에 체크인되어야 기준선이 설정된다.
2. 변경 제어 구성 변경 제어 절차를 정의하고 절차를 실행한다. 필요한 변화를 파악하고 분석한다.
3. 구성 감사 프로젝트 기준선 공식을 설정하고, 엔지니어링 변경이 적절하게 이루어지는지 확인한다.
4. 구성 상태 보고 구성 항목 정보를 조회하고, 구성에 대한 이벤트를 게시한다. 기준선 설정, 구성 항목 변경 사항을 포함한다.

• 캡스톤 프로젝트 데이터베이스 구조 설계

• 소감

캡스톤 프로젝트 데이터베이스 구조 설계

이번 캡스톤 프로젝트에서 우리 팀은 Firestore와 Storage를 이용해 데이터베이스를 구축하기로 결정했다. 오늘은 Firestore 구조를 설계하는 회의를 진행했다. 완성된 구조는 다음과 같다.

User data

collection : user

• document : user id

  • 닉네임 nickname (string)

  • 마지막 앱 사용 날짜 lastAccessDate (timestamp)

  • 연속 출석 일수 consecutiveAccessDays (int)

  • 사용자 고유 음성 voice (map)

    → Storage의 저장 위치 URL

    • 사용자 음성 파일은 Storage에 저장 후, Firestore에 Storage URL 저장

  • 최근 연습 대본 las (reference)

    → 코드상에서 controller로 최근 연습한 대본 id 들고 다니기

  • sub collection : practice

    • document : script id
      • 한문장 스크랩 scrapSentence (List)
      • 프롬프트 결과 promptResult (List<Map<String, dynamic>>)
        • 연습 날짜 practiceDate : (timestamp)
        • 정확도 precision : (int)

Example Script data

collection : example_script

• document : script id (자동생성)
  • 제목 title (string)
  • 카테고리 category (string)
  • 내용 content (List)
  • 생성일자 createdAt (timestamp)

User Script data

collection : user_script

• document : user id
  • sub collection : script
    • document : script id (자동생성)
      • 제목 title (string)
      • 카테고리 category (string)
      • 내용 content (List)
      • 생성일자 createdAt (timestamp)

설계 시 고려한 점

• Firestore의 복합 색인은 최대 2개까지 가능하다.
• collection을 가져올 때, sub collection까지 같이 가져와지지 않는다. 각 collection은 상하 관계여도 별도로 쿼리를 작성해야한다.
• Firebase를 무료 요금제로 사용할 것이기 때문에, 쿼리 수나 용량 제한 상한선을 고려해야 한다.

소감

쿼리 수, 코드, 용량 등 고려해야 하는 부분이 많아 설계가 어려웠다. 구조가 너무 복잡해지는 것을 우려해 기획이 일부 변경되기도 했다. NoSQL에 대한 이해도가 부족하다고 느껴 공부를 더 해보려 한다.

• LangChain 공부

• 소감

LangChain 공부

LLM 활용 프레임워크인 LangChain에 대해 공부하고 내용을 정리했다. LangChain에 대해 정리한 포스트에서 확인할 수 있다.

소감

LangChain의 작동 원리와 활용 방법을 이해할 수 있었다. Chain에 대한 공부가 더 필요할 것 같다.

대규모 언어 모델(LLM)은 다양한 자연어 처리(NLP) 작업을 수행할 수 있는 딥러닝 모델이다.

Closed Source

• OpenAI의 GPT-3, GPT-3.5, GPT-4
• Google의 PALM, LaMDA, Bard

장점 : 뛰어난 성능, API 방식의 편리한 사용성

단점 : 보장할 수 없는 보안, API 호출 비용 → 기업에서 사용하기 어려움 (기업 기밀 유출, API 과금 이슈)

Open Source

• Llama 계열의 LLM - LLaMA, vicuna, Alpaca, LLaMA2, upstage-llama2
• 그외 Open-source LLM - MPT-7B, WizardLM

장점 : Closed source 못지 않은 성능, 높은 보안성, 낮은 비용

단점 : 개발 난이도 높음, 사용 위한 GPU 서버 필요

ChatGPT의 문제점

• 정보 접근 제한

  • ChatGPT(GPT-3.5)는 2021년까지의 데이터를 학습한 LLM이므로, 2022년 이후 정보는 답변을 하지 못하거나 거짓된 답변을 제공한다.

    → Vectorstore 기반 정보 탐색 or Agent 활용한 검색 결합

• 토큰 제한

  • GPT-3.5 : 4096, GPT-4 : 8192 입력 토큰 제한 존재

    → TextSplitter를 활용한 문서 분할

• 환각현상

  • Fact에 대한 질문을 했을 때, 엉뚱한 대답을 하거나 거짓말을 하는 경우가 많다.

    → 주어진 문서에 대해서만 답하도록 Prompt 입력

ChatGPT 개량

• Fine-tuning : 기존 딥러닝 모델의 weight를 조정하여 원하는 용도의 모델로 업데이트
  • e.g. 블룸버그의 블룸 (금융전문)
  • 기존 아키텍처를 사용 용도에 맞게 미세 조정 (한번 더 학습 필요 - 학습하는데 드는 그래픽카드, 시간 등을 고려해야함 → 고비용)
    • GPT의 Encoder 구조를 가진 BERT를 미세조정하여 감성 분류 모델로 활용
• N-shot Learning : 0개~n개의 출력 예시를 제시하여, 딥러닝이 용도에 알맞은 출력을 하도록 조정
• In-context Learning : 문맥을 제시하고, 이 문맥 기반으로 모델이 출력하도록 조정
  • 어떤 분야에 대해 깊이있게 대화 필요할 때 유용
  • LangChain은 In-context Learning의 도구이다.

LangChain의 개념

오픈소스 LangChain : 언어 모델로 구동되는 어플리케이션을 개발하기 위한 프레임워크

• 데이터 인식 : 언어 모델을 다른 데이터 소스에 연결
• 에이전트 기능 : 언어 모델이 환경과 상호작용할 수 있도록 (동향 파악 요청 → 알아서 인터넷 검색해서 반환)

언어 모델을 잘 활용할 수 있게끔 도와줌

LangChain의 구조

• LLM : 초거대 언어모델로, 생성 모델의 엔진과 같은 역할을 하는 핵심 구성 요소
  • e.g. GPT-3.5, PALM-2, LLAMA, StableVicuna, WizardLM, MPT
• Prompts : 초거대 언어모델에게 지시하는 명령문
  • 요소 : Prompt Templates, Chat Prompt Template, Example Selectors, Output Parsers(원하는 형식의 대답으로 설정 가능 - 맑음, 맑습니다 등)
• Index : LLM이 문서를 쉽게 탐색할 수 있도록 구조화하는 모듈
  • e.g. Document Loaders, Text Splitters, Vectorstores, Retrievers,
• Memory : 채팅 이력을 기억하도록 하여, 이를 기반으로 대화가 가능하도록 하는 모듈
  • e.g. ConversationBufferMemory, Entitiy Memory, Conversation Knowledge Graph Memory
• Chain : LLM 사슬을 형성하여, 연속적인 LLM 호출이 가능하도록 하는 핵심 구성 요소
  • e.g. LLM Chain, Question Answering, Summarization, Retrieval Questioin/Answering
    • prompt를 여러 개 사슬처럼 구성
• Agents : LLM이 기존 Prompt Template으로 수행할 수 없는 작업을 가능케하는 모듈
  • e.g. Custom Agent, Custom MultiAction Agent, Conversation Agent
  • Agent에 들어가는 툴이 다양 → 웹 검색, SQL쿼리작성 등
  • 여러가지 툴을 LLM이 자체적으로 판단해서 구동

LangChain 작동 원리

1. 문서 업로드
   • Document Loader
   • 컨플루언스, 노션 페이지 업로드도 가능
   • 답변이 어떤 파일에 어떤 페이지에서 가져온건지 파악 가능
2. 문서 분할
   • Text Splitter
   • PDF 문서를 여러 문서로 분할
3. 문서 임베딩
   • Embed to Vectorstore
   • 임베딩 : LLM이 이해할 수 있도록 문서 수치화
4. 임베딩 검색
   • VectorStore Retriever
   • 질문과 연관성이 높은 문서 추출
5. 답변 생성
   • QA Chain
   • 질문과 연관성이 높은 문서 추출
   • 질문에 대한 가장 유사한 텍스트를 가져와 프롬프트1 생성 → 챗지피티에게 줘서 프롬프트2 생성 → 챗지피티에게 줘서 답변 생성

Document Loaders

문서 불러오기, 다양한 형태의 문서(PDF, Word, YouTube etc.)를 RAG 전용 객체로 불러들이는 모듈이다.

다양한 형식의 문서를 불러오고 이를 LangChain에 결합하기 쉬운 테스트 형태로 변환하는 기능을 한다. 이를 통해 사용자는 txt 형식의 문서 뿐만 아니라 pdf, word, ppt, xlsx, csv 등 거의 모든 형식의 문서를 기반으로 LLM을 구동할 수 있다.

• Page_content : 문서의 내용
• Metadata : 문서의 위치, 제목, 페이지 넘버 등

DocumentLoader 종류

• URL Loader : WebBaseLoader와 UnstructuredURLLoader

• PDF Document Loader : PyPDFLoader

• Word Document Loader : docx2txt

• CSV Document Loader : CSVLoader

• csv_args 설정 필요

  • delimiter : 데이터 구분자
  • quotechar : '"’ (묶어야 하는 string을 처리할 때 사용된다. 예를 들어 "Hello, python"과 같은 문자열은 delimiter가 콤마로 되어있는 경우, "Hello"와 "python"으로 나뉘어 지는데 이를 방지할 수 있다.)
  • fieldnames : column

Text Splitters

문서 텍스트 분할하기, 토큰 제한이 있는 LLM이 여러 문장을 참고해 답변할 수 있도록 문서를 분할하는 역할이다.

Document를 여러 개의 Chunk로 쪼개고, Chunk를 embedding vector로 만들고, vector store에 저장해준다. Chunk 하나당 하나의 Vector로 매칭된다.

특정 기준을 통해 텍스트를 청크로 나누는 모듈이다. 토큰 제한 이슈를 우회하여 Context를 학습시킬 수 있다.

Chunk 사이즈를 어떻게 할지, 어떻게 Chunking 할지가 중요하다.

• CharacterTextSplitter
  • 구분자 1개 기준으로 분할하므로 max_token을 지키지 못하는 경우 발생
  • 매개변수
    • separator : 구분자
    • chunk_size : 원하는 chunk의 사이즈
    • chunk_overlap : 이전 chunk의 일부를 overlap
      • 이전 chunk와 연결되는 내용이라면, context가 끊기지 않도록 하기 위해
    • length_function : chunk_size의 기준
      • e.g. len → 글자 수
• RecursiveCharacterTextSplitter
  • 구분자 리스트를 기준으로 재귀적으로 분할하므로, max_token 지켜 분할
    • 구분자 리스트 : 줄바꿈, 마침표, 쉼표
    • 줄바꿈 기준 분할 → max_token 초과 → 마침표 기준 분할 → max_token 초과 X → 분할 완료

→ 대부분 RecursiveCharacterTextSplitter를 통해 분할

일반적인 글로 된 문서는 모두 TextSplitter로 분할할 수 있으며, 대부분 커버 가능하다.

그러나 코드, latex 등과 같이 컴퓨터 언어로 작성되는 문서의 경우 TextSplitter로 처리할 수 없으며, 해당 언어를 위해 특별하게 구분하는 Splitter가 필요하다.

예를 들어, Python 문서를 split하기 위해서는 def, class와 같이 하나의 단위로 묶이는 것을 기준으로 문서를 분할할 필요가 있다. 이러한 원리로 latex, HTML, 코드 등 다양한 문서도 분할할 수 있다.

• langchain.text_splitter의 Language 모듈을 import
• RecursiveCharacterTextSplitter에 Language를 매개변수로 분할 가능

RecursiveCharacterTextSplitter.from_language(language=Language.PYTHON)

Vector Embeddings

Vector Embedding 형태로 저장하기 위해 Embedding 모델을 거쳐 수치화된 텍스트 데이터들을 Vector Store에 저장한다.

Text Embeddings는 텍스트를 숫자로 변환하여 문장 간의 유사성을 비교할 수 있도록 한다.

사용자 질문을 수치로 변환하는 것도 포함한다.

대부분의 경우 대용량의 말뭉치를 통해 사전학습된 모델을 통해 쉽게 임베딩한다.

비정형 데이터를 숫자로 변환해 좌표상에 위치할 수 있게 만들어주는게 임베딩 모델이다.

사전 학습 임베딩 모델에는 대표적으로 Open AI에서 제공하는 ada 모델과, HuggingFace의 모델들이 있다. 사용 목적과 요구사항에 따라 적절한 임베딩을 고르는 것은 RAG의 가장 중요한 부분이다. 한국어 임베딩 성능 좋은 모델 : ko-sbert-nli, KoSimCSE-roberta-multitask

Vectorstore

Retrieval 안에서 RAG에 임베딩된 값들을 저장하는 벡터 저장소이다. 벡터 저장소는 임베딩된 데이터를 인덱싱하여, input으로 받아들이는 query와의 유사도를 빠르게 출력한다. 대표적으로 FAISS, Chroma가 존재한다. CRUD와 같은 일반적인 DB의 기능을 포함한다.

Retrievers

사용자의 질문과 가장 유사한 문장을 검색하는 역할이다.

사용자의 질문을 임베딩 모델을 통해 임베딩시키고 임베딩된 벡터를 벡터 저장소 안에 있는 여러 text chunk vector와 비교해 가장 유사한 벡터를 뽑아 context로 넘기고, 사용자의 질문과 함께 프롬프트로 엮어 llm에게 넘겨주는 역할이다.

어떤 매개변수를 어떻게 설정해주는지, 어떤식으로 사용자 질문에 대처하는지 잘 수행하도록 만들어야 한다.

[참고자료]

LangChain 뿌시기 LLM 어플리케이션 개발을 위한 LangChain 소개 LangChain GitHub

• 클린코드 스터디

• 소감

클린코드 스터디

로버트 C.마틴의 『Clean Code』 10장 클래스를 읽고 정리하는 시간을 가졌다. 이 문장을 누르면 클린코드 10장 클래스 내용을 정리한 포스트로 연결된다.

소감

클래스는 최대한 작게 쪼개야 한다는 것을 알았다. 프론트 파트 코드를 작성하고 있는데, 적용해봐야겠다.

추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다.

캡슐화

변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다.

같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면, 그 함수나 변수를 protected로 선언하거나 패키지 전체로 공개한다.

하지만 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.

클래스는 작아야 한다!

클래스는 작아야 한다. 클래스를 설계할 때도, 함수와 마찬가지로, ‘작게’가 기본 규칙이다.

“얼마나 작아야 하는가?”

함수는 물리적인 행 수로 크기를 측정했다. 클래스는 다른 척도를 사용한다. 클래스가 맡은 책임을 센다.

메서드 다섯 개 정도면 괜찮을까?

public class SuperDashboard extends JFrame implements MetaDataUser 
  public Component getLastFocusedComponent()
  public void setLastFocused(Component lastFocused)
  public int getMajorVersionNumber()
  public int getMinorVersionNumber()
  public int getBuildNumber() 
  }

여기서는 아니다. SuperDashboard 는 메서드 수가 작음에도 불구하고 책임이 너무 많다.

클래스 이름은 해당 클래스 책임을 기술해야 한다. 실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이다.

• 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다.
• 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다.

또한 클래스 설명은 만일(“if”), 그리고(“and”), -(하)며(“or”), 하지만(“but”)을 사용하지 않고서 25단어 내외로 가능해야 한다.

단일 책임 원칙 (Single Responsibility Principle, SRP)

단일 책임 원칙(SRP)은 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙이다.

이는 ‘책임’이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다. 책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다.

SRP는 객체 지향 설계에서 더욱 중요한 개념이다. 하지만 이상하게도 SRP는 클래스 설계자가 가장 무시하는 규칙 중 하나다. 왜일까? 소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다. 우리들 대다수는 두뇌 용량에 한계가 있어 ‘깨끗하고 체계적인 소프트웨어’보다 ‘돌아가는 소프트웨어’에 초점을 맞춘다.

전적으로 올바른 태도다. 문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. ‘깨끗하고 체계적인 소프트웨어’라는 다음 관심사로 전환하지 않는다. 프로그램으로 되돌아가 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 문제로 넘어가버린다.

많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다. 큰 그림을 이해하려면 이 클래스 저 클래스를 수없이 넘나들어야 한다고 걱정한다.

• 하지만 작은 클래스가 많은 시스템이든 큰 클래스가 몇 개뿐인 시스템이든 돌아가는 부품은 그 수가 비슷하다. 어느 시스템이든 익힐 내용은 그 양이 비슷하다.

규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다. 그래야 (변경을 가할 때) 직접 영향이 미치는 컴포넌트만 이해해도 충분하다. 큼직한 다목적 클래스 몇 개로 이뤄진 시스템은 (변경을 가할 때) 당장 알 필요가 없는 사실까지 들이밀어 독자를 방해한다.

큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.

작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

응집도(Cohesion)

클래스는 인스턴스 변수 수가 작아야 한다.

각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다. 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.

응집도가 가장 높은 클래스는 가능하지도 바람직하지도 않다. 그렇지만 우리는 응집도가 높은 클래스를 선호한다.

응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문이다.

아래 클래스는 응집도가 아주 높다. size()를 제외한 다른 두 메서드는 두 변수를 모두 사용한다.

public class Stack {
  private int topOfStack = 0;
  List<Integer> elements = new LinkedList<Integer>();

  public int size() { 
    return topOfStack;
  }

  public void push(int element) { 
    topOfStack++; 
    elements.add(element);
  }

  public int pop() throws PoppedWhenEmpty {
    if (topOfStack == 0)
      throw new PoppedWhenEmpty();
    int element = elements.get(--topOfStack); 
    elements.remove(topOfStack);
    return element;
  } 
}

‘함수를 작게, 매개변수 목록을 짧게’라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.

응집도를 유지하면 작은 클래스 여럿이 나온다.

큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다.

예를 들어, 변수가 아주 많은 큰 함수 하나가 있다. 큰 함수 일부를 작은 함수 하나로 빼내고 싶은데, 빼내려는 코드가 큰 함수에 정의된 변수 넷을 사용한다. 그렇다면 변수 네 개를 새 함수에 인수로 넘겨야 옳을까?

만약 네 변수를 클래스 인스턴스 변수로 승격한다면 새 함수는 인수가 필요없다. 그만큼 함수를 쪼개기 쉬워진다.

불행히도 이렇게 하면 클래스가 응집력을 잃는다. 몇몇 함수만 사용하는 인스턴스 변수가 점점 더 늘어나기 때문이다. 몇몇 함수가 몇몇 변수만 사용한다면 독자적인 클래스로 분리해도 되지 않는가?

당연하다. 클래스가 응집력을 잃는다면 쪼개라!

큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다. 그러면서 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다.

이렇게 리팩터링 후 가장 먼저 눈에 띄는 변화는 프로그램이 길어졌다는 사실이다. 길이가 늘어난 이유는 여러 가지다.

• 좀 더 길고 서술적인 변수 이름을 사용한다.
• 코드에 주석을 추가하는 수단으로 함수 선언과 클래스 선언을 활용한다.
• 가독성을 높이고자 공백을 추가하고 형식을 맞추었다.

이는 재구현이 아니다! 프로그램을 처음부터 다시 짜지 않았다. 실제로 두 프로그램을 자세히 살펴보면 알고리즘과 동작 원리가 동일하다는 사실을 눈치채리라.

변경하기 쉬운 클래스

대다수 시스템은 지속적인 변경이 가해진다. 그리고 뭔가 변경할 때마다 시스템이 의도대로 동작하지 않을 위험이 따른다. 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.

경험에 의하면 클래스 일부에서만 사용되는 비공개 메서드는 코드를 개선할 잠재적인 여지를 시사한다. 하지만 실제로 개선에 뛰어드는 계기는 시스템이 변해서라야 한다. 하지만 클래스에 손대는 순간 설계를 개선하려는 고민과 시도가 필요하다.

클래스가 서로 분리되면 각 클래스는 극도로 단순해진다. 코드는 순식간에 이해된다. 함수 하나를 수정했다고 다른 함수가 망가질 위험도 사실상 사라졌다. 테스트 관점에서 모든 논리를 구석구석 증명하기도 쉬워졌다.

OCP(Open-Closed Principle)란 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙이다. 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.

변경으로부터 격리

요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다.

상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.

시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다. 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 더 쉬워진다.

이렇게 결합도를 최소로 줄이면 자연스럽게 또 다른 클래스 설계 원칙인 DIP(Dependency Inversion Principle)를 따르는 클래스가 나온다. 본질적으로 DIP는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.

• Prompt Engineering 공부

• 소감

Prompt Engineering 공부

캡스톤 프로젝트의 스크립트 생성을 위해 필요한 Prompt Engineering에 대해 공부하고 블로그에 정리했다. 여기에서 Prompt Engineering에 대한 포스트를 확인할 수 있다.

소감

Prompt Engineering에 대한 이해도를 높일 수 있었다. 어떻게 하면 우리 프로젝트에서 더 좋은 결과를 도출할 수 있을지 열심히 공부해보고 적용해봐야겠다.

Prompt : LLM에게 지시하는 명령을 의미한다. Prompt Template : 이 명령의 구성을 담당한다. 고정적으로 사용할 텍스트와 사용자의 입력에 따라 바뀔 변수로 템플릿을 구성한다.

프롬프트 템플릿은 크게 2가지가 존재한다.

1. Prompt Template

   • 일반적인 프롬프트 템플릿을 생성할 때 활용한다.

2. Chat Prompt Template

   • 채팅 LLM에 프롬프트를 전달하는 데에 활용할 수 있는 특화 프롬프트 템플릿이다.

     • ChatPromptTemplate에는 아래 세 가지 Template을 활용할 수 있다.

     • SystemMessagePromptTemplate : 특정 역할 부여 가능

     • AIMessagePromptTemplate : AI의 답변

     • HumanMessagePromptTemplate : 사용자의 메시지

Few-shot Learning

딥러닝 모델이 결과물을 출력할 때 예시 결과물을 제시함으로써 원하는 결과물로 유도하는 방법론이다.

LLM 역시, Few-shot 예제를 제공하면 예제와 유사한 형태의 결과물을 출력한다.

내가 원하는 결과물의 형태가 특수하거나, 구조화된 답변을 원할 경우, 결과물의 예시를 수 개 제시함으로써 결과물의 품질을 향상시킬 수 있다.

Example Selector를 이용한 동적 Few-shot Learning

Few-shot 예제를 동적으로 입력하고 싶은 경우, Example Selector를 활용할 수 있다.

LLM이 여러 작업을 수행하도록 만들되 내가 원하는 범위의 대답을 출력하도록 하려면 사용자의 입력에 동적으로 반응해야 한다. 이와 동시에, 예제를 모두 학습시키는 것이 아니라 적절한 예시만 포함하도록 함으로써 입력 Prompt의 길이를 제한하고, 이를 통해 오류가 발생하지 않도록 조절할 수 있다.

SemanticSimilarityExampleSelector : 사용자가 입력한 것과 Example의 유사도를 판단해 사용자의 입력과 가장 유사한 예시를 가져온다.

Output Parser를 활용한 출력값 조정

LLM의 답변을 내가 원하는 형태로 고정하고 싶을 때 사용 가능하다. 리스트, JSON 형태 등 다양한 형식의 답변을 고정하여 출력할 수 있다.

Prompt Engineering

LLM의 매개변수를 조정하면서 원하는 출력을 이끌어낼 수도 있지만, 명령 자체를 '잘'하면 충분히 만족스러운 결과를 도출할 수 있다.

Prompt Engineer : Pre-training된 LLM을 별도의 학습없이 사용자가 원하는 답변을 생성하도록 입력 프롬프트를 효과적으로 설계하는 기술이다.

LLM 매개변수를 조정한 예 temperature : 답변의 일관성 조절 (0~2로 설정 가능)

• 0 : 일관성있게 답변 → 신뢰성이 중요한 답변
• 2 : 같은 질문에 대해서도 랜덤하게, 다양하게 답변 → 창의적인 답변 e.g. 시, 가사 작사

ChatGPT 프롬프트 엔지니어링의 본질과 원리

문제 이해시키기

• 내가 해결하고자 하는 문제를 챗GPT에게 명확하게 이해시킨다.

전문성 끌어내기

• 가장 잘 해결할 수 있는 전문성을 챗GPT에게 지정해준다.
• 챗GPT가 전문가의 업무 절차를 모방해 단계적으로 일을 수행하도록 한다.

성공적인 결과 유도

• 성공적인 결과의 형식과 구성을 챗GPT에게 알려준다.

구체적인 프롬프트를 구성하기 위한 6가지 구성요소

1. 명령(task)

• 명령어는 반드시 포함해야한다.
• 서술어로 명료하게 기술한다. (ex. 작성해줘. 요약해줘.)
• 질 좋고 자세한 답변을 원한다면, 하나의 프롬프트에 한 개의 Task만 쓰는 것이 좋다.

2. 맥락(context)

• 어떤 상황/배경에 처해있는지?
• 의도와 목표는 무엇인지?
• 우려되는 점은 무엇인지?
• 고려해야할 제약사항/규칙은 어떤 것이 있는지?

3. 페르소나(persona)

• 해당 문제를 가장 잘 해결할 수 있는 사람/역할/직무로 Role Play를 해보자.
• 구체적인 전문가 명칭일수록, 전문 용어를 포함할수록 더 전문적인 답변이 나온다.

4. 예시(example)

• 의외로 향상 체감이 된다.
• 맥락에 잘 맞는 예시를 주는 것이 중요하다.
• 예시가 길지 않다면 2개 이상을 주는 것도 좋다. (Few-shot)

5. 포맷(format)

• 결과물의 형식이나 분량을 구체적으로 지정
• 결과물의 내용 구성이나 아웃라인을 제공

6. 어조(tone)

• 형용사를 사용하자. (ex. 간결하게, 친근하게)
• 예시를 제공해서 어조를 모방하게 할 수 있다.

[참고자료]

ChatGPT를 비롯한 대화형 AI 서비스에서 더 좋은 결과물을 얻게 해주는 프롬프트 엔지니어링 [LangChain] Prompt Template 사용 방법 정리 진짜 실무에 써먹는 챗GPT 프롬프트 엔지니어링의 원리

• Software Engineering Chapter2 공부 및 내용 정리

• 소감

Software Engineering Chapter2 공부 및 내용 정리

David C.Kung의『Object-Oriented Software Engineering』 Chapter2의 5.7까지 읽고 정리했다. 이 문장을 누르면 Object-Oriented Software Engineering의 Chapter2의 5.7까지 정리한 포스트로 연결된다.

소감

각자의 배경과 경험이 다르고 여러 제한적 사항에 대한 위기 관리 때문에 협업하는 과정에서 다양한 문제가 생길 수 있는데, 이 문제를 해결하기 위해서는 프로세스가 매우 중요하다는 것을 알 수 있었다. 캡스톤 프로젝트에서도 비용, 시간 등 여러 고려 요소가 많은데, 팀원들과 효율적인 프로세스 수립에 대해 논의해봐야겠다.

Key Takeaway Points

• 소프트웨어 프로세스는 활동의 단계 또는 소프트웨어 시스템을 구성하기 위해 수행해야 하는 것을 정의한다.
• 소프트웨어 방법론은 소프트웨어 프로세스의 단계 또는 활동을 수행하는 방법을 상세하게 설명한다. 방법론은 프로세스의 구현이다.
• 소프트웨어 개발은 소프트웨어 프로세스와 방법론을 필요로 한다.

실제 시스템 개발의 도전 과제를 극복하기 위해서는 시스템 개발에 대한 규율 있는 접근 방식이 필요하다. 이를 일반적으로 소프트웨어 프로세스라고 한다. 프로세스는 소프트웨어 시스템을 개발하기 위해 수행해야 할 활동을 명시하는 반면, 방법론은 프로세스의 활동을 수행하기 위한 단계와 방법을 정의한다. 즉, 방법론은 프로세스의 구현이다.

1. CHALLENGES OF SYSTEM DEVELOPMENT

먼저, 프로젝트 과제가 있다: · 프로젝트 현실 1. 실제 프로젝트는 일정 및 예산 제약 조건을 충족해야 한다.

· 프로젝트 도전 1. 고객이 원하는 것이 무엇인지, 그리고 앞으로 몇 년 안에 어떤 일이 일어날 것인지에 대한 완전한 지식 없이 프로젝트 작업을 어떻게 계획, 일정, 관리할 것인가?

· 프로젝트 현실 2. 많은 시스템 개발 프로젝트는 여러 부서 또는 개발 팀의 협력을 필요로 한다. 예를 들어, 많은 대규모 임베디드 시스템은 하드웨어와 소프트웨어 구성 요소를 모두 포함하고, 소프트웨어 엔지니어링 부서가 하드웨어 부서와 협력하도록 요구한다.

· 프로젝트 도전 2. 부서와 팀에 작업을 분할하고 부서 간 찌그러진 조각을 할당하고, 다른 부서와 팀에서 생산된 구성 요소를 원활하게 통합할 수 있는 방법은 무엇인가?

· 프로젝트 현실 3. 다른 부서나 팀은 다른 개발 프로세스, 방법 및 도구를 사용할 수 있다. 부서나 팀이 다른 장소에 위치할 수도 있다.

· 프로젝트 도전 3. 부서와 팀 간의 적절한 의사 소통과 조정을 어떻게 보장할 수 있는가? 프로젝트 과제 외에도 제품에 대한 도전 과제가 있다.

· 시스템 리얼리티 1. 현실의 많은 시스템은 엄격한 실시간 제약 조건을 포함하여 많은 요구 사항과 제약 조건을 충족해야 한다. 예를 들어, 메일 처리 시스템은 수백 가지의 요구 사항과 제약 조건을 가지고 있다. 시간당 40,000개 이상의 우편물 혹은 초당 12개 이상의 우편물을 스캔하고 처리하는 것이 요구된다.

· 시스템 챌린지 1. 이러한 요건과 제약 조건이 충족되도록 하려면 어떻게 시스템을 개발해야 할까?

· 시스템 리얼리티 2. 요건과 제약 조건은 수시로 변경될 수 있다. 저자가 계약한 작은 프로젝트를 예로 들어보자. 고객의 변경 요청으로 인해 처음 3개월 동안 매주 요구사항이 변경되어야 했다.

· 시스템 챌린지 2. 종종 불가피하고 정확한 변화를 예측하는 것이 불가능한 변화에 대처하기 위해 프로세스와 제품을 어떻게 설계해야 하는가?

· 시스템 리얼리티 3. 시스템은 수년간 진화하면서 유지보수 문제를 일으킬 것이다. 예를 들어, 변화가 문서화되지 않거나 제대로 문서화되지 않으면 시스템의 변화는 버그를 유발할 뿐만 아니라 시스템의 구조를 악화시킬 수 있다. 이 모든 것들은 시스템을 점점 더 이해하고 테스트하며 유지보수하기 어렵게 만든다.

· 시스템 챌린지 3. 시스템의 나머지 부분에 큰 영향 없이 비교적 쉽고 간편하게 변화가 이루어질 수 있도록 시스템을 어떻게 설계하는가?

· 시스템 리얼리티 4. 시스템은 하드웨어와 소프트웨어 구성요소로 구성될 수 있고, 제3자 구성요소와 여러 구현 언어를 사용할 수 있으며, 서로 다른 장소에 위치한 여러 플랫폼과 기계에서 실행될 수 있다.

· 시스템 챌린지 4. 하드웨어, 플랫폼 및 구현의 특성을 숨기도록 시스템을 어떻게 설계하여 이러한 변화가 시스템의 나머지 부분에 영향을 미치지 않도록 하는가?

2. SOFTWARE PROCESS

소프트웨어 프로세스는 소프트웨어 시스템을 구성하기 위해 수행되는 일련의 활동 단계이다. 각 단계는 다른 단계로의 입력인 일부 산출물을 생성한다. 각 단계에는 진입 기준 세트와 퇴출 기준 세트가 있다.

3. MERITS AND PROBLEMS OF THE WATERFALL PROCESS

종래의 폭포 프로세스는 요구사항 분석, 설계, 구현, 테스트 및 유지보수와 같은 일련의 활동을 정의한다. 이 프로세스는 많은 회사에서 수십 년 동안 사용해 왔다. 이 프로세스의 문제점을 논의하기 전에, 이 프로세스에는 여러 가지 장점이 있음을 지적하는 것이 공정할 것이다.

이러한 장점은 이 프로세스가 소프트웨어 산업에서 여전히 사용 중인 이유를 설명한다. 첫째, 폭포 프로세스의 간단하고 직선적인 단계 시퀀스는 프로젝트 계획, 프로젝트 스케줄링 및 프로젝트 상태 추적을 크게 단순화한다. 이러한 의미에서, 이는 "예측 가능한" 프로세스로 간주된다.

둘째, 기능적 활동의 직선적인 시퀀스는 기능 지향적인 프로젝트 조직을 가능하게 한다. 이러한 조직에서, 기능 팀들은 요구사항 분석, 설계 및 구현과 같은 다양한 기능 영역에 특화되어 있다. 기능 팀들은 파이프라인 방식으로 프로젝트를 수행한다.

폭포 프로세스의 세 번째 장점은 단계적 접근 방식이 일부 크고 복잡하고 오래 지속되는 임베디드 시스템에 적절하다는 것이다. 이러한 시스템의 예로는 메일 정렬 및 라우팅 시스템, 프로세스 제어 시스템 및 기타 여러 유형의 컴퓨터화된 장비가 있다. 이러한 시스템은 하드웨어에서 생성된 수많은 이벤트에 응답하고, 엄청난 양의 수신 데이터를 처리하고, 하드웨어 장치의 동작을 제어해야 한다. 일반적으로 이러한 시스템의 기능 또는 요구사항은 장비 제조업체와 고객이 공동으로 정의한다. 많은 경우, 개발될 시스템은 기존 시스템의 기능, 성능 및 보안을 주요하게 향상시키는 것에 불과하다. 공급업체는 애플리케이션 및 고객이 원하는 것에 대한 경험과 좋은 지식을 가지고 있으므로 요구사항에 대한 주요 변경은 드물다. 구매 주문이 발행되면, 고객은 리뷰 및 프로토타입 시연에 참여하지만, 고객은 수락 테스트 단계까지 장비에 액세스할 수 없다. 단계적 접근 방식은 시스템이 안정적으로 실행되고 성능 및 타이밍 제약을 충족하는 것을 보장하기 위해 각 단계를 엄격하게 수행할 수 있게 한다.

폭포 프로세스에는 여러 가지 심각한 단점이 있다.

첫째, 단계 및 관련 마일스톤의 하나의 엄격한 시퀀스는 요구사항 변경에 대응하는 것을 어렵게 만든다. 그러나 비즈니스 경쟁 증가, 새로운 규정 또는 표준, 또는 모든 요구사항을 식별할 수 없는 것과 같은 많은 상황에서 요구사항 변경이 필요하다. 많은 애플리케이션의 경우, 요구사항이 오래 전에 식별되었고 비즈니스 요구사항이 극적으로 변경되었기 때문에 긴 개발 기간을 허용할 수 없다.

셋째, 사용자는 시스템이 출시될 때까지 피드백을 제공하는 실험을 할 수 없다. 경험에 따르면 조기 사용자 피드백은 비즈니스 요구사항 및 사용자 인터페이스 설계의 문제에 대한 잘못된 개념을 감지하는 데 도움이 된다. 또 다른 단점은 고객이 긴 개발 기간 동안 새로운 시스템의 혜택을 누릴 수 없다는 것이다.

마지막으로, 고객은 프로젝트가 취소될 경우 낮은 투자 수익의 위험을 받아들여야 한다. 즉, 설계 문서 및 부분 테스트된 코드는 투자 가치가 없다.

4. SOFTWARE DEVELOPMENT IS A WICKED PROBLEM

폭포수 과정의 문제는 사악한 문제에 대한 이론과 밀접한 관련이 있다. 사악한 문제는 여러 사악한 문제의 속성이나 줄여서 사악한 속성을 나타낸다. 이러한 속성들은 사악한 문제가 풀기 어렵다는 것을 의미한다. 이에 비해 수학적 방정식 체계 해결, 체스 두는 프로그램 개발, 컴파일러 구성, 연산 연구와 같은 길들여진 문제는 좋은 속성을 나타낸다. 불행하게도 응용 소프트웨어 개발은 일반적으로 사악한 문제이다. 방정식 체계를 푸는 것과 같은 길들여진 문제의 경우 문제는 명확한 공식을 갖는다. 사양과 솔루션은 분리될 수 있다. 방정식 체계는 사양이고, 변수에 값을 할당하는 것이 솔루션이다. 이것은 많은 응용 소프트웨어 개발 프로젝트에 대해 사실이 아니다. 예를 들어, 요구 사항 사양이 실제 요구 사항을 지정하지 않을 수 있다. 이것이 제공된 시스템이 사용자의 기대에 미치지 못하기 때문에 많은 프로젝트가 실패하는 이유이다. 프로토타입은 실제 요구 사항을 식별하는 데 도움이 되도록 구성되는 경우가 많다. 이 경우, 프로토타입은 특성뿐만 아니라 구현 방법을 지정하기 때문에 사양과 구현 모두이다. 방정식 체계를 푸는 단계의 수는 유한하다. 각 단계에는 가능한 이동 수가 제한된다. 소프트웨어 설계의 경우에는 그렇지 않으며, 가능한 설계 대안의 수는 설계자의 지식과 창의성에 의해서만 제한된다. 방정식 체계를 푸는 과정은 해결책을 찾으면 중단된다.

그러나 소프트웨어 프로젝트는 팀이 시간, 돈, 인내심이 부족하기 때문에 종료된다. 방정식 체계의 해결책은 즉각적이고 객관적으로 옳고 그름으로 평가될 수 있다. 그러나 소프트웨어 시스템은 좋은 것과 나쁜 것의 관점에서만 평가될 수 있고 그 판단은 평가자의 지식, 경험, 개인의 선호도에 따라 좌우되는 경우가 많다. 이에 비해 많은 소프트웨어 시스템은 평생 테스트 대상이 된다.

길들여진 문제의 해결책은 비슷한 문제를 해결하도록 조정될 수 있지만 응용 소프트웨어 개발 프로젝트는 모두 독특하다. 응용 소프트웨어가 제조가 아니라 개발되거나 맞춤형으로 만들어지는 이유도 여기에 있다. 소프트웨어 개발은 과학적인 과정이 아니다. 다시 말해 많은 결정이 과학적인 것이 아니라 정치적, 경제적으로 내려진다.

예를 들어, 길들여진 문제를 구현하고, 사용하고, 유지하는 것이 더 경제적이기 때문에 최적의 알고리즘 대신 길들여진 알고리즘을 선택한다. 때로는 특정 프로그래밍 언어나 DBMS를 사용하는 선택이 정치적인 결정이 되기도 한다. 저자가 개발 계약한 한 프로젝트에서 클라이언트는 벤더와 좋지 않은 경험을 했다는 이유로 특정 제품을 사용하지 말라고 요청했다. 마지막으로 그리고 중요한 것은 소프트웨어 오류로 인해 수백만 달러의 재산 피해와 인명 피해가 발생할 수 있다는 점이다. 따라서 소프트웨어 개발자는 잘못될 권리가 없다. 길들여진 문제는 이 속성을 공유하지 않는다- 결과가 잘못되면 소프트웨어 개발자는 다시 시도하기만 하면 된다.

5. SOFTWARE PROCESS MODELS

폭포수 프로세스의 문제들로 인해 연구자들과 기금 지원 기관들은 소프트웨어 개발의 사악한 속성들을 고려한 더 나은 프로세스를 찾게 되었다. 대부분의 모델은 엄격하게 순차적인 활동 프로세스가 아닌 반복적인 프로세스를 채택한다.

5.1. Prototyping Process

프로토타이핑 프로세스 모델은 새로 구성된 소프트웨어 시스템과 사용자의 기대 사이의 불일치, 시간 및 예산 제약 내에서 능력을 제공해야 하는 과제를 인식한다. 그 해결책으로 시스템의 프로토타입이 구성되고 요구 사항을 획득하고 검증하는 데 사용된다. 프로토타입은 설계 검증뿐만 아니라 타당성 연구에도 사용된다.

프로토타입은 매우 간단하거나 매우 정교할 수 있다. 간단한 프로토타입은 시스템이 사용자와 어떻게 상호 작용하는지 설명하기 위해 외관과 느낌, 일련의 스크린 샷만 보여준다. 정교한 프로토타입은 시스템 기능의 많은 부분을 구현할 수 있다. 프로토타입은 일반적으로 일회용 프로토타입과 진화용 프로토타입으로 분류된다. 일회용 프로토타입은 목적에 맞게 신속하고 경제적으로 구성된다. 일회용 프로토타입은 구현이 올바른 결과를 산출하는지 확인하기 위한 참조 구현으로 단위 또는 통합 테스트에서 재사용될 수 있다. 더 나아가 시스템이 출시되기 전에 사용자를 교육하는 데 사용될 수 있다.

5.2. Evolutionary Process

프로토타입은 설계 아이디어의 요구사항 획득, 요구사항 검증, 타당성 조사 및 검증에 도움을 준다. 그러나 일회용 프로토타입은 많은 노력이 낭비된다. 이는 대규모 실시간 임베디드 시스템의 타당성 조사 및 설계 검증을 위해 정교한 프로토타입이 필요한 경우에 해당된다.

진화 프로세스 모델은 프로토타입이 진화하도록 함으로써 이 문제를 해결하는 것을 목표로 한다.

일련의 예비 요구사항에 따라 구성된 초기 프로토타입을 사용자가 실험할 수 있도록 한다. 사용자의 피드백은 프로토타입을 진화시키는 데 사용된다. 이 프로세스는 더 이상의 확장이 필요하지 않을 때까지 반복된다. 이러한 이유로 진화 프로토타입 제작 프로세스 모델이라고도 한다. 프로토타입이 일회용 프로토타입이 아니기 때문에 운영 기능성과 필요한 견고성을 가지고 구성된다.

진화 프로세스는 시스템 작업을 통해 정확한 요구사항과 알고리즘을 발견해야 하는 탐색적 유형의 프로젝트에 가장 적합하다. 지능형 시스템, 유전자 시퀀싱과 같이 알려지지 않은 것을 발견하는 것을 목표로 하는 연구 소프트웨어뿐만 아니라 환경과 적극적으로 상호 작용하는 임베디드 시스템을 포함하여 많은 실제 프로젝트가 이 범주에 속한다. 진화 프로세스는 예측 가능한 진행 일정이 필요한 프로젝트에는 적합하지 않다.

5.3. Spiral Process

나선형의 각 사이클은 개발 중인 시스템의 특정 측면, 예를 들어 기능성, 성능 또는 품질을 향상시키는 것을 목표로 한다. 이러한 의미에서, 시스템은 모델이 나선형 사이클을 반복함에 따라 점진적으로 진화한다.

나선형의 각 사이클은 다음 단계 중 일부를 선택적으로 실행한다:

1. 현재 사이클에 대한 목표, 대안 및 제약 조건(나선형의 북서쪽 모서리)을 결정한다. 이 단계에서는 목표, 목표를 달성하기 위한 대안적 접근 방식 및 충족해야 하는 제약 조건을 식별한다. 프로젝트 위험 항목을 식별하고 우선순위를 정한다.

2. 대안을 평가하고, 위험(나선형의 북동쪽 모서리)을 식별하고 해결한다. 제약 조건 내에서 목표를 달성하기 위한 대안을 평가한다. 목표를 달성하지 못할 경우의 위험을 식별하고 위험을 해결할 수 있는 방법을 개발한다. 위험 해결을 위한 기술로는 프로토타이핑, 시뮬레이션, 모델링 및 벤치마킹이 있다.

위험 분석 및 해결 결과에 따라 다음 단계는 다음 단계 중 하나일 수 있다:

· 남은 위험이 있는 경우 다음 단계는 남서쪽 모서리, 즉 다음 단계의 프로토타이핑을 계획한 다음 새로운 프로토타이핑 사이클이 될 것이다. · 이전 사이클에서 알려진 주요 위험이 해결되었다면 모델의 남동쪽 모서리에서 보는 바와 같이 후속 단계는 폭포처럼 진행될 수 있다. · 이전 라운드에서 생산된 프로토타입이 운영 가능하고 최종 시스템으로 진화할 수 있을 정도로 견고하다면, 후속 단계는 진화 프로토타이핑 모델에서와 같이 프로토타입을 확장하여 사용한다. 즉, 북동쪽 모서리의 오른쪽을 향해 진행한다.

3. 다음 레벨 시스템(남동쪽 모서리)을 개발하고 검증한다.

4. 다음 단계(남서쪽 모서리)를 계획한다. 새로운 이니셔티브 또는 계속 프로젝트에 대해 이 단계는 요구 사항, 라이프 사이클 활동, 다음 단계의 통합 및 테스트 계획을 정의한다.

5.4. The Unified Process

합리적 통합 프로세스 또는 통합 프로세스(UP)는 일련의 사이클로 구성된다. 각 사이클은 시스템의 릴리스로 끝난다. 각 사이클은 여러 번의 반복을 갖는다.

반복은 Inception, Elaboration, Construction 및 Transition 4단계로 그룹화된다. 각 단계는 주요 마일스톤으로 끝난다. 각 단계는 프로젝트를 계속하거나 종료할 것으로 관리자가 중요한 프로젝트 결정을 내린다.

각 반복은 요구사항 분석, 설계, 구현 및 테스트를 포함한 일련의 워크플로우 활동을 거친다.

Inception. 처음 한 번 또는 두 번의 반복이 시작 단계를 구성한다. 이 단계는 단순화된 사용 사례 모델, 잠정적인 소프트웨어 아키텍처 및 프로젝트 계획을 생성한다. 간단한 용어로 사용 사례는 시스템이 개발되는 애플리케이션의 비즈니스 프로세스를 모델링한다. 동사-명사구가 사용 사례를 설명하는 데 사용된다. 예를 들어, 예치금, 인출금 및 수표 잔액은 자동화기기(ATM)의 사용 사례이다. 사용 사례 모델은 소프트웨어 시스템의 가장 중요한 사용 사례를 포함한다.

Elaboration. 정교화 단계는 다음 몇 번의 반복으로 구성된다. 이 단계 동안, 대부분의 사용 사례가 지정되고 아키텍처 설계를 나타내는 UML 다이어그램이 생성된다. 소프트웨어 시스템의 가장 중요한 사용 사례가 설계 및 구현된다.

Construction. 구축 단계 동안, 나머지 사용 사례는 반복적으로 개발되고 시스템에 통합된다. 시스템은 대상 환경에 점진적으로 설치될 수 있다.

Transition. 전환 단계 동안, 소프트웨어 시스템을 배포하기 위한 활동이 수행된다. 여기에는 사용자 교육, 베타 테스트, 결함 수정 및 기능 향상이 포함된다.

UP은 사용 사례를 식별하는 데 중점을 두고 시스템을 개발하고 배포하기 위한 반복을 계획하는 데 사용한다. 이러한 의미에서 UP은 Use case driven이라는 특징을 갖는다.

UP은 생애주기 초기에 시스템의 아키텍처나 전체적인 구조를 결정하고, 이를 소프트웨어 시스템의 개발을 안내하는 데 사용한다. 이러한 이유로 UP은 아키텍처 중심적이라고 한다. UP의 다른 두 가지 특징은 시스템이 반복적이고 점진적으로 개발되고 배치되기 때문에 반복적이고 점진적이라는 점이다.

5.7. Agile Processes

애자일 프로세스는 팀워크, 사용자와의 공동 응용 프로그램 개발, 변화를 위한 설계, 짧은 반복에서 작은 증분의 신속한 개발과 빈번한 전달을 강조한다.

Agile Manifesto

1. 애자일은 프로세스 및 도구에 대한 개인과 상호 작용을 중요시한다. 기존의 계획 중심적 관행은 소프트웨어 프로젝트의 성공을 위해 좋은 소프트웨어 프로세스가 필수적이라고 믿는다. 하나의 통념은 "소프트웨어 품질은 소프트웨어 프로세스만큼 좋다"이다. 통념이 여전히 장점이 있지만, 경험에 의하면 팀워크뿐만 아니라 팀원들의 능력이 더 중요하다. 결국 소프트웨어 프로세스를 수행하는 것은 팀원들이다. 팀원들이 설계하는 방법을 모르거나 서로 효과적으로 의사소통을 하지 못한다면 결과는 좋지 않을 것이다. 기존 관행은 도구 사용에 상당한 비중을 둔다. 이러한 이유로 많은 기업들이 개발 도구와 환경에 막대한 투자를 한다. 일부 도구는 훌륭하고 의도한 문제를 해결한다. 그러나 이것들은 방법을 아는 적절한 사람들만 수행할 수 있다. UML 다이어그램 편집기는 소프트웨어 엔지니어가 OO 설계를 수행하는 방법을 모르더라도 도움이 되지 않는다. 편집기가 멋지게 보이는 UML 다이어그램을 작성하지만 반드시 좋은 설계는 아니다. 애자일 방법은 기존 관행과 달리 개인과 팀 작업에 가치를 둔다. 소프트웨어는 개념적인 제품이고 개발 활동은 매우 지적이기 때문이다. 팀원들이 함께 소프트웨어 제품을 공동으로 구축해야 한다면, 프로젝트의 성공에 팀원들이 상호 작용하고 공동 노력에 기여할 수 있는 능력은 필수적이다. 소프트웨어 프로세스와 도구도 물론 중요하지만, 개인과 상호 작용은 필수적이다.

2. 애자일은 포괄적인 문서화보다 작동하는 소프트웨어를 중요시한다. 수년 또는 수십 년 동안, 기업들은 분석 및 설계 문서를 준비하는 데 엄청난 노력을 기울인다. 이는 부분적으로는 표준 감사 때문이기도 하고, 부분적으로는 "좋은 소프트웨어는 좋은 설계 문서화에서 나오고, 좋은 설계 문서화는 좋은 분석 모델에서 나온다"는 믿음 때문이기도 하다. 이러한 믿음은 사실이지만 부분적으로만 그렇다. 많은 소프트웨어 엔지니어들은 어떤 경우에는 코드가 작성되고 테스트될 때까지 실제 요구 사항 또는 설계가 작동하는지 여부를 결정하는 것이 불가능하다는 것을 경험했다. 이러한 경우에, 포괄적인 문서화는 작동하는 해결책이 발견된 것 같은 착각을 일으키기 때문에 도움이 되지 않고 해로울 수 있다. 포괄적인 문서화는 코딩 및 테스트에 사용할 수 있는 시간이 적다는 것을 의미하기도 하는데, 이러한 경우에는 실제 요구 사항과 필요한 설계를 식별하는 유일한 수단이다. 예를 들어, 대기업의 재고를 최적화하는 소프트웨어를 생각해 보자. 재고는 지난 수십 년 동안 다양한 직원이 작성한 수백만 개의 항목에 대한 텍스트 설명으로 구성된다. 수많은 인수 및 합병 활동은 항목, 항목의 범주, 설명 형식 및 스타일의 수를 상당히 증가시킨다. 소프트웨어는 재고 설명을 처리하는 데 필요하다. 목표는 재고를 단순화하고 재고 비용을 줄이는 것이다. 소프트웨어에 대한 요구 사항은 분명히 소프트웨어가 이 목표를 달성하기 위해 할 수 있는 일이다. 그러나 소프트웨어를 구현하지 않으면 소프트웨어가 무엇을 달성할 수 있는지 아무도 정확히 알 수 없다. 이는 사악한 문제의 예로, 사양과 구현이 분리될 수 없다. 소프트웨어를 구현할 필요 없이 요구 사항이 어떻게든 식별되었다고 가정해 보자. 그러면 데이터 구조 및 알고리즘의 설계는 알고리즘이 작동하는지, 어느 정도까지 작동하는지를 알기가 매우 어렵기 때문에 큰 과제이다. 재고 설명의 다양성, 불일치, 불완전한 항목, 오타 및 축약어 변형으로 인한 것이다. 시행착오 접근 방식이 더 적절해 보인다. 애자일 방법은 작동 소프트웨어가 최종 결과이기 때문에 작동 소프트웨어를 중요시한다. 결국, 개발팀은 작동 소프트웨어를 고객에게 전달해야 한다. 소프트웨어 시스템이 요구하는 기능을 전달하는지 확인하기 위해 작동 소프트웨어만 테스트할 수 있다. 이러한 의미에서 작동 소프트웨어가 요구 사항이며, 그 반대도 마찬가지이다. 위에서 논의한 재고 설명 분류 프로젝트가 이를 잘 보여준다. 그러나 이러한 논의가 애자일 방법이 분석 및 설계를 원하지 않는다는 결론으로 이어져서는 안 된다. 이와 반대로 애자일 방법은 분석 및 설계 모델을 구성한다. 그럼에도 불구하고 애자일 원칙은 문제를 이해하고 설계 아이디어를 전달하는 데 도움이 될 수 있을 정도의 모델링만 옹호할 뿐 그 이상은 아니다.

3. 애자일은 계약 협상에 대한 고객의 협업을 중요시한다. 기존 프로세스에는 고객이 원하는 것이 무엇인지 식별하기 위해 계약 협상 단계가 포함된다. 그러면 요구 사항 사양이 생성되고 계약의 일부가 된다. 개발 과정에서 고객은 몇 가지 설계 검토 및 수락 테스트에 참여할 뿐이다. 고객과 함께 이루어져야 하는 많은 중요한 설계 결정은 개발팀에 의해 이루어진다. 개발팀이 기술적 의사결정은 잘 하지만 고객을 위해 의사결정을 내릴 지식과 배경을 가지고 있지 않을 수 있다. 예를 들어, 하나 이상의 DBMS를 지원해야 하는 요구사항은 어떤 DBMS를 지원해야 하는지를 명시하지 않을 수 있다. 기술적으로 팀은 어떤 DBMS가 가장 우수하고 지원해야 하는지 알 수 있다. 그러나 고객은 다른 요소들을 더 중요하게 생각할 수 있다. 여기에는 DBMS의 유형을 유지하는 IT 직원의 능력, 이러한 시스템을 도입하는 데 드는 비용, 기존 시스템과의 호환성이 포함된다. 개발팀이 고객을 위해 이러한 의사결정을 내린다면 결과적인 시스템은 고객의 비즈니스 요구사항을 충족시키지 못할 수 있다. 프로젝트의 성공을 위해서는 고객 협업이 필수적이다. 팀과 고객 간의 의사소통과 상호 이해를 향상시킨다. 의사소통의 향상은 실제 요구사항을 식별하고 요구사항이 잘못 이해될 가능성을 줄이는데 도움이 된다. 상호 이해는 위험 공유를 의미하므로 프로젝트 실패 확률을 줄여준다. 많은 프로젝트에서 시스템의 정확한 결과, 설계 결정 또는 알고리즘은 예측하기 어렵거나 불가능하다. 이러한 경우에 고객 협업은 매우 중요하다. 상호 이해는 개발팀이 고객의 비즈니스 영역, 운영, 과제 및 우선순위를 잘 이해하고 있음을 의미한다. 이는 팀이 고객의 비즈니스 요구사항을 충족시키기 위해 시스템을 설계하고 구현할 수 있도록 한다. 상호 이해는 또한 고객이 비즈니스 솔루션을 구현할 수 있는 수단을 제공하는 기술의 한계를 이해한다는 것을 의미하며, 기술만으로는 비즈니스 문제를 해결할 수 없다. 고객은 개발팀의 한계를 이해할 필요가 있으며, 이는 저자의 다음 경험에서 알 수 있다. 한 고객은 저자가 이것이 불가능하다고 지적했음에도 불구하고 한 달 안에 중간 크기의 소프트웨어 제품을 생산해야 한다고 주장했다. 시간 부족뿐만 아니라 자격을 갖춘 개발자의 부족도 또 다른 과제였다. 6개월이 지난 지금도 팀은 제공하지 못했고, 프로젝트는 실패했다. 이 이야기에서 고객은 한 달 안에 시스템을 원했지만, 시스템이 완전히 새로운 일련의 혁신적인 비즈니스 아이디어를 구현해야 했기 때문에 이 요구를 충족시킬 수 있는 팀은 없었다. 고객과의 협업은 프로젝트를 구할 수도 있다. 예를 들어, 양 당사자는 서로의 우선 순위와 한계를 이해하고 혁신적인 기능을 점진적으로 실행하기 위한 현실적인 애자일 개발 계획을 수립할 수 있다.

4. 애자일은 계획을 따르는 동안 변화에 대응하는 것을 중요시한다. 기존 관행은 변화에 비용이 많이 들기 때문에 "변화 통제"를 강조한다. 요구 사항 사양과 같은 인공물이 완성되면 이후의 변화는 엄격한 변화 통제 프로세스를 거쳐야 한다. 그 프로세스는 팀이 변화 요청에 대응하는 것을 방해한다. 애자일 방법론은 계획을 따르는 동안 변화에 대응하는 것을 중요시한다. 오늘날 급변하는 세상에서 모든 비즈니스는 생존하거나 성장하기 위해 비즈니스 조건의 변화에 신속하게 대응해야 한다. 따라서 소프트웨어로의 변화는 불가피하다. 인터넷 기술의 발전은 기업이 웹 애플리케이션을 빠르고 자주 업데이트해야 할 뿐만 아니라 가능성도 있다. 편리하고 계획 중심적인 관행의 유연성은 이러한 애플리케이션의 요구를 충족시킬 수 없다.

Agile Princicple

1. 적극적인 사용자 참여는 필수적이다. 많은 애자일 방법에 의해 적극적인 사용자 참여가 요구된다. 이는 실제 요구 사항을 식별하는 것이 많은 소프트웨어 개발 프로젝트에서 가장 어려운 부분이기 때문이다. 기존의 접근 방식은 요구 사항 분석에 전체 개발 노력의 15%-25%를 사용한다. 그들은 요구 사항을 동결하기 위해 엄격한 변경 제어를 구현한다. 이것들은 문제를 해결하는 것으로 보이지 않는다. 시간이나 노력의 부족이 아니다. 인간이 개발 프로세스의 초기 단계에서 실제 요구 사항을 알 수 없는 것이다. 더욱이 세상은 변화하고 있으므로 요구 사항은 진화해야 한다. 적극적인 사용자 참여는 사용자 커뮤니티의 대표자가 개발 팀과 필요에 따라 밀접하고 자주 상호 작용하는 것을 의미한다. 예를 들어, 잘 아는 두 명의 사용자 대표자가 프로젝트에 할당된다. 그들은 팀에 머물며 일하거나 일주일에 몇 번씩 정기적으로 팀을 방문한다. 이러한 배치는 팀과 사용자 간의 의사 소통과 이해를 크게 향상시킨다. 이는 차례로 요구 사항 오개념이 조기에 수정되고 사용자의 피드백이 적절하고 시기적절하게 처리되며 시스템에 대한 의사 결정이 사용자와 함께 이루어지도록 한다. 이 모든 것은 실제 요구 사항이 식별되고 우선 순위가 지정되며 시스템이 사용자의 기대에 맞게 구축됨을 의미한다.

2. 팀은 의사 결정을 내릴 수 있는 권한을 부여받아야 한다. 애자일 개발은 개인과 프로세스 및 도구에 대한 상호 작용을 중시한다. 이 원칙은 이를 실현한다. 즉, 팀 구성원이 의사 결정을 내리고 책임과 소유권을 갖도록 요구되고 권장된다. 이를 수행할 수 있기 위해서는 팀 구성원이 팀으로 작업하고 프로젝트 전반에 걸쳐 서로 및 사용자와 상호 작용할 것이 요구된다.

3. 요구 사항은 진화하지만 시간 척도는 고정되어 있다. 요구 사항을 동결하는 기존의 접근 방식과 달리 민첩한 프로세스는 변화를 환영하도록 설계되었다. 이 원칙은 작업 범위는 요구 사항 변경에 대처하도록 진화하도록 허용되지만 합의된 시간 프레임과 예산은 고정되어 있음을 의미한다. 이는 새로운 요구 사항이나 수정된 요구 사항은 다른 요구 사항의 비용으로 수용된다는 것을 의미한다. 즉, 추가적인 노력은 미션 크리티컬하지 않은 다른 요구 사항을 포기함으로써 보상된다.

4. 높은 수준의 요구 사항 캡처; 가볍고 시각적. 민첩한 개발은 포괄적인 문서화보다 작업 소프트웨어를 중요하게 생각한다. 결국, 결론은 분석 및 설계 문서화가 아니라 운영 시스템을 전달하는 것이다. 이를 달성하기 위해 민첩한 방법은 사용자 이야기, 기능 또는 작은 크기의 스토리 카드에 작성된 사용 사례로 요구 사항을 거의 캡처하지 않는다. 이는 스토리보드 또는 스크린샷, 스케치 또는 기타 시각적 수단을 사용하여 시각화되어 사용자가 시스템과 어떻게 상호 작용하는지 보여준다. 이러한 기술은 무거운 문서화를 피하고 스토리 카드와 스토리보드를 공유하고 조작하기 쉽기 때문에 요구 사항을 변경하고 트레이드오프하는 것을 쉽게 만든다.

5. 점진적으로 작은 릴리스를 개발하고 반복해라. 애자일 프로젝트는 사용 사례, 사용자 이야기 또는 특징을 반복적으로 전달하기 위해 시스템을 아주 작은 크기로 개발하고 배포한다. 이 배열은 한 번에 여러 개의 텍스처를 가지며 사용자가 피드백을 제공하는 것이 더 쉽고 작은 증분은 프로젝트 실패의 위험을 줄인다.

6. 소프트웨어 제품의 빈번한 제공에 집중해라. 애자일 프로세스는 소프트웨어 시스템을 작은 증분으로 자주 제공한다는 점에서 나선형 프로세스 및 통합 프로세서와 다르다. 서로 다른 애자일 방법은 매일에서 3개월에 이르는 서로 다른 반복 길이를 제안한다. 예를 들어, 동적 시스템 개발 방법(DSDM)은 26주를 제안하는 반면 극한 프로그래밍(XP)은 14주를 사용한다. 스크럼의 반복은 스프린트라고 하며 일반적으로 30일로 설정한다.

7. 다음 단계로 넘어가기 전에 각 기능을 완료해라. 이 원리는 각 기능이 다음 단계로 넘어가기 전에 100% 구현되고 철저하게 테스트해야 함을 의미한다. 여기서 해결해야 할 문제는 기능이 철저히 테스트되었는지 어떻게 알 수 있는가 하는 것이다. 테스트 기반 개발(TDD) 및 테스트 커버리지 기준은 솔루션을 제공한다. TDD는 각 기능에 대한 테스트를 구현하기 전에 작성해야 함을 요구한다.

8. 80-20 규칙을 적용해라. 이 규칙은 작업 또는 결과의 80%가 시스템 기능의 20%에 의해 생성된다는 믿음에 기초한다. 따라서 작업 또는 결과의 80%를 산출할 요구사항 중 20%에 우선순위를 부여해야 한다. 이 원칙은 개발 팀에게 고객과 사용자에게 그러한 요구사항을 파악하고 우선순위를 정하도록 지시하도록 조언한다. 이 규칙은 팀원들에게 최종 추가 마일과 관련된 수익 감소를 상기시키기도 한다. 이는 좋은 기능, 실제로 필요하지 않은 성능 최적화 등에 적용된다. 예를 들어, 더 간단한 알고리즘이 처리할 데이터만큼 충분히 빠르면 최적의 알고리즘은 추가적인 구현 노력을 할 가치가 없을 수 있다.

9. 테스트는 프로젝트 라이프 사이클 전체에 걸쳐 통합되며, 조기에 그리고 자주 테스트된다. 이 원칙과 5-7 원칙은 상호 보완적이다. 즉, 테스트는 시스템의 완전히 구현된 작은 증분을 자주 전달하는 데 필수적인 부분이다. 자바 클래스 단위 테스트 및 회귀 테스트 도구인 JUnit와 같은 테스트 도구는 이 원칙을 뒷받침한다. 이러한 도구를 사용하면 프로그래머는 테스트할 기능을 호출하는 방법과 테스트 결과를 평가하는 방법을 지정해야 한다. 이 도구는 테스트를 생성하고, 테스트를 실행하고, 테스트 결과를 자동으로 확인한다. 테스트는 원하는 만큼 자주 실행될 수 있다.

10. 모든 이해관계자 간의 협업 및 협력적 접근은 필수적이다. 기존의 접근 방식은 요구사항을 개발팀에 전달하기 위해 포괄적인 문서화에 의존한다. 민첩한 프로젝트는 요구사항을 높은 수준과 가벼운 무게로 포착한다. 따라서 개발팀과 고객 대표 및 사용자 간의 협업 및 협력이 필수적이다. 당사자는 서로를 이해하고 라이프 사이클 전체에 걸쳐 협력하여 요구사항을 파악하고 진화해야 한다. 새로운 시스템은 사용자의 업무 습관 및 성과를 크게 변화시키거나 영향을 미칠 수 있기 때문에 프로젝트의 성공을 위해서는 팀과 사용자 간의 협업 및 협력이 필수적이다.

• Software Engineering Chapter1 공부 및 내용 정리

• 소감

Software Engineering Chapter1 공부 및 내용 정리

David C.Kung의『Object-Oriented Software Engineering』 Chapter1을 읽고 정리했다. 이 문장을 누르면 Object-Oriented Software Engineering의 Chapter1을 정리한 포스트로 연결된다.

소감

혼자 공부하면 자꾸 딴짓을 하게 되는데 모여서 함께 공부하니 집중이 잘 되었다. 덕분에 15쪽 분량의 chapter1을 전부 정리할 수 있었다. 앞으로도 모각코 시간을 활용해 책을 열심히 읽어 캡스톤 프로젝트에 적용해보고 싶다.

Key Takeaway Points

• S/E은 소프트웨어 비용과 출시 기간을 줄이면서 소프트웨어 생산성과 퀄리티를 높이는 것을 목적으로 한다.
• S/E은 소프트웨어 개발, 소프트웨어 품질 보증, 소프트웨어 프로젝트 관리 활동, 이 3가지 트랙이 상호작용하는 life-cylce로 구성된다.
• Object-Oriented(OO) S/E은 S/E의 전문 분야다. 세상과 시스템이 서로 상호작용한다고 본다.

컴퓨터 사용이 확대되는 원동력은 시장 경제이지만, 컴퓨터를 우리가 원하는 방식으로 작동할 수 있는 것은 소프트웨어다.

1. What is Software Engineering?

소프트웨어 시스템은 복잡한 지적 산물이다. 소프트웨어 개발은 소프트웨어 시스템이 요구사항을 충족하고 예산이 초과되지 않으며 시스템이 일정에 따라 제공되도록 보장해야 한다.

S/E은 소프트웨어 비용과 출시 기간을 줄이면서 소프트웨어 생산성과 소프트웨어 품질을 크게 향상시키기 위한 공학적 프로세스 및 방법의 연구, 교육, 적용에 중점을 둔다.

소프트웨어 생산성(Productivity), 품질(Quality) ↑ 소프트웨어 생산 및 운영 비용(Cost), 시장 출시 시간(Time) ↓ → 소프트웨어 엔지니어링의 목표 : PQCT

PQCT 달성을 위한 S/E 프로세스 및 방법에 대한 연구, 교육, 응용은 개발, 품질 보증, 프로젝트 관리 활동 세 가지로 분류된다.

1. 개발 초기 시스템 개념을 운영 체제로 변환
2. 품질 보증 개발이 올바르게 수행되고 활동에 의해 생성된 산출물이 올바른지 확인함으로써 원하는 소프트웨어 시스템이 생산되고 제공되도록 보장
3. 프로젝트 관리 프로젝트를 계획하고, 개발 및 품질 보증 활동에 자원을 할당하며, 시스템이 제때에 그리고 예산 내에서 개발되고 제공되도록 함

2. Why Software Engineering?

1. 많은 임베디드 시스템의 경우 소프트웨어 비용이 20년 전 510%에서 전체 시스템 비용의 9095%로 증가했다. 일부 임베디드 시스템은 ASIC과 firmware를 사용한다. 이들은 대체하는데 비용이 많이 들고, 그래서 소프트웨어의 품질이 매우 중요하다. 이들은 시스템 개발에 대한 소프트웨어 엔지니어링 접근 방식을 요구한다.

   ASIC(Application-Specific Integrated Circuit) : 특정한 어플리케이션에 맞게 디자인되어 다른 용도로 사용할 수 없는 고유한 기능을 갖는 집적 회로 Firmware : 특정 하드웨어 장치에 포함된 소프트웨어로, 하드웨어의 제어와 구동을 담당하는 소프트웨어라고 한다.

2. 대규모 시스템 개발에 필요한 팀워크를 지원한다. 대규모 소프트웨어 시스템은 설계, 구현, 테스트에 상당한 노력을 필요로 한다. 둘 이상의 소프트웨어 엔지니어가 협력하여 소프트웨어 시스템을 개발하면 심각한 개념화, 의사소통 및 조정 문제가 발생한다.

   개념화(Conceptualization)은 시스템이 구축되는 응용 프로그램을 이해하는 것을 돕기 위한 지적 모델을 형성하기 위해 실제 현상을 관찰하고 분류하는 과정이다. 소프트웨어 엔지니어들은 교육, 문화 배경, 직업 경험, 가정 및 기타 요인의 차이로 인해 세상을 다르게 인식할 수 있다. 이 책에 제시된 모델링 기술은 소프트웨어 엔지니어가 응용 프로그램의 영역과 비즈니스 프로세스에 대한 공통된 이해를 확립하도록 돕는다. 소프트웨어 엔지니어 팀이 함께 일할 때, 그들은 그들의 이해와 설계 아이디어를 교환할 필요가 있다. 소프트웨어 공학은 소프트웨어 엔지니어가 그들의 아이디어를 전달할 수 있도록 통합 모델링 언어 (UML)를 제공한다. 이 책에서 제시하는 애자일 통합 방법론은 소프트웨어 엔지니어들이 모두가 이해하고 따르는 방식으로 협력하도록 한다.

3. Software Life-Cycle Activities

아래 3가지 활동은 소프트웨어 라이프 사이클 전체에 걸쳐 동시에 이루어진다.

1. 소프트웨어 개발 프로세스 소프트웨어 개발 프로세스는 초기 시스템 개념을 대상 환경에서 실행되는 운영 체제로 변환한다. 비즈니스 요구 사항을 파악하고, 타당성 조사를 수행하며, 시스템이 제공해야 하는 요구 사항이나 역량을 공식화한다. 또한 대상 환경에 시스템을 설계, 구현, 테스트 및 배포한다.

2. 소프트웨어 품질 보증 소프트웨어 품질 보증(SQA : Software Qualitiy Assurance)은 개발 활동이 제대로 수행되는지 확인하며, 개발 활동을 통해 생산된 소프트웨어 산출물이 소프트웨어 요구 사항과 원하는 품질 표준을 충족한다.

3. 소프트웨어 프로젝트 관리 소프트웨어 프로젝트 관리는 개발 및 품질 관리 활동의 제어 및 관리를 감독한다. 프로젝트 관리 활동에는 노력 추정, 프로젝트 계획 및 스케줄링, 위험 관리 및 프로젝트 관리 등이 포함된다. 이러한 활동은 소프트웨어 시스템이 제때에 그리고 예산 내에서 전달되도록 보장한다.

3.1. Software Development Process

소프트웨어 프로세스는 소프트웨어 시스템을 생산하기 위해 수행되는 일련의 활동 단계로 구성된다. 예를 들어 통신 시스템, 메일 처리 시스템, 산업 프로세스 제어 시스템 및 의료 장치는 이벤트를 처리하고 하드웨어를 제어하기 위해 소프트웨어를 사용한다. 이러한 시스템을 임베디드 시스템(embedded system)이라고 한다. 이러한 경우에 소프트웨어 프로세스는 시스템 개발 프로세스 또는 시스템 엔지니어링 프로세스라고 하는 더 큰 프로세스의 일부이다. 시스템 엔지니어링은 소프트웨어 시스템 단독이 아니라 전체 시스템을 고려한다. 소프트웨어 엔지니어링의 역사 동안 많은 소프트웨어 프로세스 모델이 제안된다. 그 중에는 폭포수, 프로토타이핑, 진화, 나선형, 통합 및 애자일 프로세스가 있다.

전통적인 엔지니어링 분야를 차용한 잘 알려진 전통적인 폭포수 프로세스를 보여준다. 프로세스는 시스템 엔지니어링 활동, 즉 시스템 요구 사항 정의, 시스템 설계 및 시스템 요구 사항 할당을 고려한다.

폭포수 프로세스의 단계는 아래에 설명되어 있다.

시스템 요구사항 정의, 시스템 설계 및 할당

임베디드 시스템에 대해 종종 수행되는 시스템 엔지니어링 활동이다. 시스템 요구사항 정의는 전체 시스템에 대한 능력을 파악하여 시스템 요구사항으로 공식화한다.

예를 들어, 무선 통신 시스템(RCS)을 위해 시스템 개발을 고려한다. 시스템은 셀룰러 네트워크에서 셀보다 훨씬 큰 영역을 서비스하는 단 하나의 고출력 기지국을 가지고 있다는 점을 제외하고는 셀룰러 네트워크와 유사하다. 시스템 요구사항은 전체 시스템에 대한 기능을 지정한다. 다음은 확인된 많은 시스템 요구사항 중 네 가지이다.

R1. RCS는 이동 가입자가 다른 이동 가입자 및 유선 전화에 대한 통화를 개시할 수 있도록 허용해야 한다. R2. RCS는 이동 가입자가 다른 가입자로부터의 통화에 응답할 수 있도록 허용해야 한다. R3. RCS는 이동 통화 및 요금 청구서를 캡처 및 기록하기 위한 통화 계정을 가입자 계정에 제공해야 한다. R4. RCS는 승인된 계정 관리자가 하위 가입자 계정을 관리할 수 있도록 허용해야 한다.

시스템 설계는 전체 시스템의 주요 하위 시스템을 결정하고 하위 시스템 간의 관계를 지정한다. 이들은 시스템 아키텍처 설계도로 묘사된다. 그림 1.3은 블록 다이어그램을 사용하여 RCS에 대한 아키텍처 설계를 나타낸다. 이는 모바일 유닛, 기지국, 계정 관리의 세 가지 하위 시스템을 묘사한다.

할당 활동은 시스템 요구사항들을 서브시스템들에 할당한다. 시스템 설계 및 할당은 비교적 독립적이고 인터페이스하기 쉬운 서브시스템들을 초래해야 한다. 시스템 할당은 시스템 요구사항들을 하위 수준의 요구사항들로 분해하여 별개의 서브시스템들에 할당할 수 있다.

소프트웨어 요구사항 분석

소프트웨어 요구사항 분석은 소프트웨어 시스템에 할당된 시스템 요구사항을 구체화한다. 소프트웨어 시스템에 대한 다른 기능도 파악한다. 이들과 정제된 시스템 요구사항은 소프트웨어 요구사항 규격(SRS)에 명시되어 있다.

컨트롤러 계층에서, 컨트롤러는 Account 객체를 생성하고, 데이터베이스 계층을 통해 데이터베이스에 저장한다. 이는 각 계층의 기능이 구현 및 사용하기에 비교적 용이함을 보여준다. N-tier 아키텍처의 또 다른 장점은 계층 간 인터페이스가 변경되지 않는 한, 계층으로의 변경이 다른 계층에 미치는 영향이 거의 없다는 것이다.

소프트웨어 설계

소프트웨어 설계는 소프트웨어 시스템의 소프트웨어 아키텍처, 즉 전체 구조를 결정한다. 이는 하위 시스템, 이들의 관계, 하위 시스템의 기능, 인터페이스 및 하위 시스템이 서로 상호 작용하는 방법을 지정한다. 사용자 인터페이스의 설계는 소프트웨어 설계의 또 다른 중요한 활동이다. 즉, 창과 대화 상자의 모양과 느낌을 묘사하고 시스템이 사용자와 어떻게 상호 작용하는지 설명한다. 소프트웨어 설계는 정보 처리 알고리즘도 지정한다. RCS의 아키텍처 설계의 예로 그림 1.4는 계정 관리 시스템을 위한 N-tier 아키텍처를 나타낸다. 아키텍처는 클래스 또는 객체를 별도의 계층으로 구성한다. 각 계층에는 명확하게 정의된 책임이 있으며 다음 계층의 서비스를 요청한다. 예를 들어 사용자/장치 인터페이스 계층은 계정 관리자와 소프트웨어 컨트롤러에게 서비스를 제공한다. 이는 컨트롤러 계층의 서비스를 사용한다. 계층 구조는 비즈니스 프로세스의 구현을 단순화한다. 예를 들어 계정 관리자가 계정을 생성하고자 할 때 사용자 인터페이스는 요청을 생성 계정 컨트롤러에게 전달한다

_구현, 테스트 및 유지보수 _

구현 및 단위 테스트 단계에서는 설계를 구현하기 위해 프로그램이 작성된다. 프로그램은 테스트되고, 코딩 표준에 대한 정확성 및 준수를 보장하기 위해 동료에 의해 검토된다. 통합 단계에서는 프로그램 모듈이 통합되고, 서로 작동하는지 확인하기 위해 테스트된다. Acceptance 테스트 중에는 테스트 케이스가 설계되고 실행되어 소프트웨어가 실제로 소프트웨어 요구 사항을 충족하는지 확인한다. 소프트웨어 시스템은 이후 대상 환경에 설치되고 사용자에 의해 테스트된다. 소프트웨어는 유지보수 단계로 진입한다. 유지보수 단계에서는 시스템이 교체될 때까지 수정, 개선 및 개선이 지속적으로 이루어진다.

3.2. Software Qualitiy Assurance

소프트웨어 품질 보증 SQA는 개발 중인 소프트웨어 시스템이 소프트웨어 요구 사항 및 원하는 품질 표준을 충족할 것을 보장한다. verification, validation 및 testing은 이러한 목표를 달성하기 위한 수단이다.

verification은 소프트웨어 프로젝트를 위해 선택된 소프트웨어 프로세스 및 방법에 따라 개발 활동이 수행되는 것을 보장한다. 또한 필요한 소프트웨어 산출물이 생산되고 품질 표준을 준수하는지 확인한다.

validation은 개발 활동에 의해 생산된 소프트웨어 산출물의 정확성을 확인한다. 예를 들어, RCS에 대한 검증은 시스템 및 소프트웨어 요구사항이 실제 비즈니스 요구사항을 명시하는지 확인한다. 또한 시스템뿐만 아니라 소프트웨어 설계가 요구사항 및 제약사항을 충족하는지 확인하고 구현된 소프트웨어 시스템은 의도된 비즈니스 문제를 해결한다.

validation 활동은 static validation과 dynamic validation 활동으로 분류된다.

• static validation은 소프트웨어를 실행하지 않고 소프트웨어 산출물의 정확성을 확인한다. 요구사항 사양 및 소프트웨어 설계 문서와 같이 실행 가능하지 않은 산출물에 적용할 수 있다.
• dynamic validation은 소프트웨어가 작동하고 올바른 결과를 생성하는지 확인하기 위해 소프트웨어를 실행한다. 소프트웨어 테스트는 dynamic validation 기술이다. 테스트 케이스를 사용하여 소프트웨어를 실행하고 테스트 결과가 예상되는 결과와 일치하는지 확인한다. 자동차가 실제로 기능 및 성능 요구사항을 충족하는지 확인하기 위해 시운전하는 것과 유사하다.

Unit 테스트는 인터페이스, 컨트롤러, 비즈니스 객체, 데이터베이스 및 네트워크 계층의 클래스 각각이 클래스의 기능을 올바르게 구현하는지 확인하기 위해 테스트 케이스를 생성한다. → 개별 함수, 개별 클래스 테스트 Integration 테스트는 이러한 클래스가 서로 작동하는지를 테스트하고 보장하기 위해 테스트 케이스를 생성한다. → 클래스 간 상호작용 Acceptance 테스트는 시스템이 요구 사항을 충족하는지 확인하기 위해 계정 관리 시스템의 요구 사항에서 테스트 사례를 도출한다. → 보통 고객 또는 사용자가 기대하는 기능 및 특성을 확인하기 위해 수행하며, 시스템이 실제 환경에서 작동할 때의 동작을 시뮬레이션한다.

검증(Verification)은 소프트웨어가 개발자 입장에서 명세서나 요구사항에 따라 올바르게 구현되었는지를 확인하는 프로세스를 의미합니다. 다시 말해, 개발된 소프트웨어가 기대한 기능을 정확하게 수행하는지 여부를 검사하는 것입니다. 반면에 유효성 검사(Validation)는 실제 사용 환경에서 소프트웨어가 예상대로 동작하는지 확인하는 프로세스를 말합니다. 이는 사용자가 소프트웨어를 사용하여 원하는 결과를 얻을 수 있는지를 확인하는 것을 의미합니다. 즉, 검증은 소프트웨어가 올바르게 만들어졌는지를 확인하고, 유효성 검사는 소프트웨어가 실제로 유용하게 작동하는지를 확인합니다.

3.3. Software Project Management

소프트웨어 프로젝트 관리 활동은 개발 중인 소프트웨어 시스템이 예산 제약 조건 내에서 일정에 따라 전달되도록 보장한다. 이러한 목표를 달성하기 위해 프로젝트 관리는 다음 활동을 수행한다.

• 노력 추정 노력 추정은 개발 및 SQA 활동을 수행하는 데 필요한 인적 자원과 기간을 도출한다. 노력 추정은 예상되는 소프트웨어 크기 및 복잡성뿐만 아니라 필요한 제공 날짜와 같은 다양한 요소에서 이러한 추정치를 도출한다.

• 프로젝트 계획 및 스케줄링 프로젝트 계획 및 스케줄링은 프로젝트에 대한 전반적인 계획을 산출하는 것을 목표로 한다. 프로젝트 계획은 프로젝트 팀의 생애 주기 프로세스 전반에 걸쳐 안내한다. 그러나 현실 세계의 변화로 인해 계획은 변화를 반영하여 업데이트 될 필요가 있다. 프로젝트 계획에는 프로젝트 목표, 목표 달성 프로세스, 프로젝트 이정표, 프로젝트 활동 및 성과물의 일정, 프로젝트 팀 구성 및 방식, 프로젝트 예산 등이 명시된다. 품질 보증 계획서에는 품질 표준, 품질 관리 활동 및 그러한 활동의 일정이 명시되어 있다. 또한 프로젝트 계획서에 포함되는 것으로, 아래에 설명되는 위험 관리 계획서가 있다.

• 위험 관리 많은 이벤트가 프로젝트를 위태롭게 할 수 있다. 예를 들어, 관리자 또는 주요 기술 직원이 프로젝트를 떠나거나 프로젝트가 일정보다 훨씬 지연된다. 이것들을 위험 항목이라고 한다. 위험 관리는 위험 관리 계획을 통해 그러한 이벤트의 영향을 줄이려고 한다. 위험 관리 계획서는 위험 항목을 식별하고, 프로젝트에 대한 가능성 및 손상에 따라 우선 순위를 정하고, 위험이 발생할 때 그에 대응하기 위한 위험 해결 조치를 명시한다.

• 프로젝트 관리 프로젝트 계획서에 명시된 바와 같이 관리 활동을 수행한다. 프로젝트 진행 상황을 지속적으로 모니터링하고 프로젝트를 새로운 상황에 적응시키기 위해 필요한 조치를 실행하는 것과 관련이 있다. 프로젝트 팀 또는 팀원의 조정, 회의 일정 및 수행, 일상적인 문제 해결 등과 같은 프로젝트 활동의 일상적인 관리도 포함된다.

• 소프트웨어 구성 관리 개발 프로세스 중에 수많은 소프트웨어 산출물이 생성된다. 여기에는 요구 사항 사양, 소프트웨어 설계, 코드, 테스트 케이스, 사용자 설명서 등이 포함된다. 이들은 개발 프로세스의 다른 단계에서 소프트웨어 또는 그 일부를 구성한다. 예를 들어, 요구 사항 사양은 실행 불가능한 형태의 소프트웨어이다. 설계 사양은 요구 사항 사양을 개선한 것이다. 코드는 설계를 개선한 것이다. 이 문서들은 서로 의존한다. 예를 들어, 소프트웨어 설계는 요구 사항에 따라 달라진다. 요구 사항이 변경되면 설계는 변경되어야 한다. 이는 결국 설계를 구현하는 코드에 대한 변경을 요구할 수 있다. 따라서 소프트웨어 엔지니어링은 일관성 있게 변경이 이루어지도록 조정하는 메커니즘이 필요하다. 이것은 소프트웨어 구성 관리(SCM)이다.

4. Object-Oriented Software Engineering

Object-Oriented Software Engineering(OOSE)은 소프트웨어 공학의 전문 분야이다. OOSE는 세계와 시스템을 서로 관계를 맺고 상호 작용하는 객체들로 구성된 것으로 본다.

OOSE는 OO 소프트웨어 개발을 지원하기 위해 다음과 같은 것들을 제공한다.

1. OO 모델링 및 설계 언어 모델링 및 설계 언어는 개념과 표기법뿐만 아니라 표기법 사용 규칙도 정의한다. 통합 모델링 언어(UML)는 가장 널리 사용되는 OO 모델링 및 설계 언어이다.
2. OO 소프트웨어 개발 프로세스 통합 프로세스(UP)는 잘 알려진 개발 프로세스이지만 최근에는 애자일 프로세스가 등장했다.
3. OO 소프트웨어 개발 방법론 소프트웨어 프로세스의 활동을 수행하는 방법을 자세히 설명한다.
4. 00 개발 도구 및 환경 퍼블릭 도메인 소프트웨어뿐만 아니라 상업용 제품도 있다. 예를 들어, NetBeans 통합 개발 환경(IDE)은 자유 오픈 소스 소프트웨어이다. 전체 소프트웨어 개발 수명 주기의 활동을 지원하는 플러그인 번들이 함께 제공된다.

4.1. Object-Oriented Modeling and Design Languages

세 가지 영향력 있는 OO 개발 방법론, 그 중에서도 많은 것들이 제안되었고 소프트웨어 산업에서 널리 사용되었다. 이는 Booch Diagram, OMT(Object Modeling Technique), Use Case Engineering이다. 업계는 곧 서로 다른 방법론을 사용하여 설계 및 구현된 시스템을 통합하는 것이 기념비적인 도전이라는 것을 발견했다. 그 이유는 서로 다른 방법론이 서로 다른 모델링 개념과 표기법을 사용하기 때문이다. 이 문제를 해결하기 위해 OMG(Object Management Group)는 통합 모델링 언어(UML)을 OMG 표준으로 채택했다. UML은 OO 시스템의 다양한 측면을 모델링하고 설계하기 위한 다이어그램 제품군이다. UML 다이어그램은 개발 팀이 기존 애플리케이션의 비즈니스를 이해하는 것을 돕기 위해 요구 사항 분석 단계에서 사용된다. 이 다이어그램은 설계 사양의 일부로 설계 단계에서 사용된다. UML 다이어그램은 이 책의 나머지 부분에 걸쳐 제시될 것이다.

4.2. Object-Oriented Development Processes

객체 지향 개발 프로세스 폭포수 프로세스의 순차적 특성은 요구 사항의 변경이 어렵고 비용이 많이 든다는 것을 의미한다. 요구 사항에 대한 변경이 설계 및 구현에 영향을 미치기 때문이며, 이 또한 변경되어야 한다. 안타깝게도 시장 상황의 변경, 기술의 발전 및 기타 요인으로 인해 많은 실제 프로젝트에서 요구 사항 변경은 흔히 발생한다. 폭포수 프로세스의 개발 기간이 길다는 것은 시스템이 출시되자마자 시대에 뒤떨어지게 된다는 것을 의미한다. 이는 시스템의 기능이나 요구 사항이 오래 전에 확인되었기 때문이다. 이러한 문제를 극복하기 위해 여러 소프트웨어 프로세스 모델이 제안되었다. 이들 모두는 개발 활동의 엄격하게 순차적인 프로세스가 아닌 반복적인 프로세스를 채택하고 있다. 그 예로 나선형 프로세스, 통합된 프로세스, 애자일 프로세스가 있다.

4.3. Object-Oriented Development Methodologies

객체 지향 개발 방법론 소프트웨어 프로세스는 "언제 무엇을 할 것인지"를 지정하지만 "어떻게 할 것인지"는 지정하지 않는다. 즉, 개발 활동은 정의하지만 활동을 수행하는 방법은 정의하지 않는다. UML은 모델링 언어이다. 다이어그램을 사용하여 소프트웨어 엔지니어가 분석 및 설계 아이디어를 설명하도록 한다. 소프트웨어 엔지니어가 분석 및 설계 아이디어를 생산하는 데 도움이 되지 않는다. 소프트웨어 개발 방법론이 그 격차를 메운다. 소프트웨어 프로세스의 활동을 수행하는 단계와 단계를 수행하는 방법을 지정한다. 기존의 OO 개발 방법론에는 Booch Diagram, 객체 모델링 기법(OMT), Use Case Engineering 및 기타 방법이 포함된다. 애자일 방법론에는 스크럼(Scrum), 동적 시스템 개발 방법(DSDM), 특징 기반 개발(FDD), 크리스탈 클리어(Crystal Clear), 익스트림 프로그래밍(XP), 린 개발 방법 등이 있다.

4.4. Will OO Replace the Conventional Approaches?

정답은 여러 가지 이유로 '아니오'다.

• 수많은 기존 시스템을 유지 관리하는 것이 필요하다.
• 수많은 조직이 여전히 기존 접근 방식을 사용한다.
• 과학 컴퓨팅과 같은 일부 프로젝트에는 기존의 방법론이 더 적합할 수 있다.
• 시스템은 기존 및 OO 접근 방식에 의해 개발된 구성 요소로 구성될 수 있다.

따라서 OO와 기존 접근 방식은 수년 동안 공존할 것이다.

5. Software Engineering and Computer Science

소프트웨어 엔지니어링과 컴퓨터 과학은 다르다. 알고리즘 및 데이터 구조, 데이터베이스 시스템, 인공 지능, 운영 체제 등 컴퓨터 과학 분야에서는 계산 효율성, 자원 공유, 정확성, 최적화 및 성능을 강조한다. 이러한 속성은 정량적으로 즉시 측정할 수 있다. 실제로 지난 수십 년(1950-현재) 동안 컴퓨터 과학 연구에 투입된 모든 노력과 자원은 이러한 측면을 개선하는 것을 목표로 한다. 컴퓨터 과학 교과서의 대부분 장은 이러한 측면을 개선하기 위한 방법, 알고리즘 및 기술에 대해 작성된다. 컴퓨터 과학과 달리 소프트웨어 공학은 소프트웨어 PQCT를 강조한다. 예를 들어, 최적의 솔루션을 얻는 것은 종종 컴퓨터 과학의 목표다. 소프트웨어 공학 연구 개발에 투입된 노력과 자원은 소프트웨어 PQCT를 개선하는 것을 목표로 한다. 소프트웨어 공학 교과서의 대부분의 장은 이러한 네 가지 측면을 개선하기 위한 방법과 기술에 대해 작성된다. 안타깝게도 소프트웨어 공학 프로세스 또는 방법론의 영향을 즉시 측정할 수는 없다. 의미를 가지려면 오랜 기간 동안 그 영향을 평가해야 한다. 예를 들어, 연구자들은 통제되지 않은 goto 문이 해롭다는 것을 깨닫는 데 10년 이상이 걸렸다. 즉, goto문의 통제되지 않은 사용은 이해와 테스트가 어려운 부실하게 구조화된 프로그램을 초래한다. 컴퓨터 과학은 기술적인 측면에만 초점을 둔다. 소프트웨어 공학은 비기술적인 문제를 고려해야 한다. 예를 들어, 개발 프로세스의 초기 단계는 비즈니스 요구 사항을 식별하고 요구 사항과 제약 조건을 공식화하는 데 중점을 둔다. 이러한 활동에는 커뮤니케이션, 고객 관계, 비즈니스 분석에 대한 지식, 경험 및 기술이 필요하다. 소프트웨어 공학은 프로젝트 관리에 대한 지식과 경험도 필요하다. 사용자 인터페이스 설계는 사용자 선호도와 사용자가 시스템을 어떻게 사용할 것인지와 같은 인적 요소를 고려해야 한다. 또한, 시스템은 많은 사람들에게 한 가지 또는 다른 방식으로 영향을 미칠 수 있기 때문에 소프트웨어 개발은 정치적인 문제를 고려해야 한다. 그리고 원리들을 예를 들어 데이터베이스에 접근해야 하는 소프트웨어 시스템의 설계를 생각해 보자. 컴퓨터 공학 분야는 효율적인 데이터 저장 및 검색을 강조할 수 있으며 비즈니스 객체가 데이터베이스에 직접 접근하는 설계를 선호할 수 있다. 이러한 설계는 비즈니스 객체와 데이터베이스 사이에 긴밀한 결합을 만든다고 한다. 소프트웨어 공학은 성능이 심각한 문제가 아닌 한 이것을 좋은 설계로 간주하지 않을 것이다. 데이터베이스, 또는 데이터베이스 관리 시스템이 변경되면 비즈니스 객체가 변경되어야 한다. 이것은 어렵고 비용이 많이 들 수 있다. 데이터베이스가 원격 위치에 있다면 비즈니스 객체는 원격 데이터베이스와 통신하는 방법을 알아야 한다. 이러한 결과는 테스트하고 유지 관리하기 어려운 복잡한 비즈니스 객체를 낳는다. 차이점에도 불구하고 소프트웨어 공학과 컴퓨터 과학은 밀접한 관련이 있다. 컴퓨터 공학에서 소프트웨어 공학은 전기/전자 공학에 물리학, 또는 화학 공학에 화학과 같다. 즉, 컴퓨터 과학은 소프트웨어 공학의 이론적이고 기술적인 토대이다. 소프트웨어 공학은 컴퓨터 과학의 응용 분야이다. 그러나 소프트웨어 공학에는 고유한 연구 주제가 있다. 이것들은 여러 가지 중에서도 소프트웨어 프로세스 및 방법론, 소프트웨어 verification, validation 및 테스트 기술에 대한 연구를 포함한다. 소프트웨어 공학 연구는 소프트웨어 PQCT와 이들 사이의 균형을 상당히 개선하는 것을 목표로 한다. 소프트웨어 공학은 광범위한 영역이다. 소프트웨어 공학자는 몇 가지를 언급하자면 데이터베이스 시스템, 운영 체제, 데이터 구조와 알고리즘, 프로그래밍 언어, 컴파일러 구성을 포함한 컴퓨터 과학의 다양한 영역을 알고 있어야 한다. 임베디드 시스템 개발은 소프트웨어 공학자가 전자 회로에 대한 기본적인 이해와 하드웨어 장치와 인터페이스하는 방법을 요구한다. 마지막으로 소프트웨어 공학자가 훌륭한 소프트웨어 설계자가 되기 위해서는 도메인 지식과 설계 경험을 얻는 데 시간이 걸린다. 이러한 도전과 현실적인 요구를 충족시키기 위해 크고 복잡한 시스템을 설계하고 구현하는 능력은 소프트웨어 공학을 흥미로운 영역으로 만든다. 계속해서 확장되는 컴퓨터 응용은 소프트웨어 공학자이자 소프트웨어 공학 연구자인 소프트웨어 공학에게 좋은 기회를 만들어 준다.

1. 클린코드 스터디
2. 캡스톤 프로젝트 아키텍처 설계를 위한 조사

• 소감

1. 클린코드

로버트 C.마틴의 『Clean Code』 5장 형식맞추기를 읽고 정리하는 시간을 가졌다. 이 문장을 누르면 클린코드 5장 형식맞추기 내용을 정리한 포스트로 연결된다.

2. 캡스톤 프로젝트 아키텍처 설계를 위한 조사

이번 학기 캡스톤 프로젝트의 아키텍처 설계를 위해 데이터와 기술에 대해 조사했다.

• 데이터

    [AI-Hub 뉴스 대본 및 앵커 음성 데이터](https://www.aihub.or.kr/aihubdata/data/view.do?currMenu=&topMenu=&aihubDataSe=data&dataSetSn=71557)

  • 공공데이터포털 지역별 뉴스 동영상

  • 한국데이터거래소 케이블채널 MBN 뉴스 데이터

• 음성 인식 모델

  • 음성 파장 분석/시각화 : Python Librosa
    리브로사(librosa)는 음악 및 오디오 신호 처리를 위한 파이썬 라이브러리입니다. 이 라이브러리는 음악 분석, 오디오 신호 변환 및 기타 오디오 처리 작업을 수행하기 위한 다양한 기능을 제공합니다.

    librosa의 기능 중 일부는 다음과 같습니다:

    • 오디오 파일을 로드하고 저장하기 위한 함수
    • 음악의 스펙트로그램, 멜 스펙트로그램 및 스펙트럼을 생성하는 함수
    • 음악의 템포, 비트, 리듬 및 주파수를 추출하는 함수
    • 음악 신호를 필터링하고 변환하는 함수
    • 음악 데이터를 시각화하는 함수

    librosa는 많은 머신 러닝 및 딥 러닝 모델에서 음악 분석 및 처리를 위해 사용되며, 음악 정보 검색, 음악 생성 및 음악 추천 시스템과 같은 다양한 분야에서 응용됩니다.

    [참고자료]

    Librosa 라이브러리 개요 [Python 음성 데이터 분석] Librosa MFCC로 음성 데이터 특징 추출 및 음성인식 CNN 딥러닝 모델

  • 사용자 목소리로 음성 예시 구현 Google Text-to-Speech 사용하면 될 것 같음 SCE-TTS: 내 목소리로 TTS 만들기

• 스크립트 작성 모델

  • Fine-Tuning

  • LangChain RAG

    [참고자료]

    LangChanin RAG 사용하기 🦜️🔗 LangChain 개요

• 프론트엔드

  • iOS/Android 모두 구현 가능하고, 팀원 다수가 사용할 수 있는 Flutter 선호

• 백엔드

  • Amazon EC2로 서버 구축
  • 로그인을 포함한 사용자 데이터는 Firestore로, 그 외 데이터는 DynamoDB를 사용하면 좋을 것 같음

소감

함께 클린코드 스터디를 하면서 각자의 코드 경험 공유를 통해 더 쉽게 이해하고 습득할 수 있었다. 함께 공부하니 집중도 잘 되고 의미있게 시간을 보낼 수 있어 유익했다.