Github

https://github.com/hosugator/smart_summary_bot

일정

9-10시: 프로젝트 설명 및 역할 분담

• 아침 스크럼: 프로젝트의 목표와 개인별 역할을 공유합니다.
• 목표: 오늘의 스프린트 목표를 명확히 합니다.

10-12시: 기능 구현

• 개발: 각자 맡은 역할을 집중적으로 구현합니다.

12-12:30: 스크럼

• 데일리 스탠드업: 진행 상황, 어려움, 다음 할 일 등을 공유하며 팀원 간의 싱크를 맞춥니다.

14-15시: 리팩터링 및 구현

• 개선: 스크럼에서 논의된 내용을 바탕으로 코드를 개선하거나, 구현이 늦어진 부분을 보완합니다.

15-16시: 코드 발표

• 코드 리뷰: 각자 구현한 기능의 입출력을 기준으로 코드를 설명하고 피드백을 주고받습니다.

구조

/smart_summary_bot
├── crawler/
│   ├── __init__.py
│   └── crawler.py        # 크롤링 기능을 담은 파일
├── preprocessor/
│   ├── __init__.py
│   └── preprocess.py     # 전처리 기능을 담은 파일
├── answer/
│   ├── __init__.py
│   └── summarizer.py     # 요약 기능을 담은 파일
├── embedder/
│   ├── __init__.py
│   └── embed.py          # 임베딩 기능을 담은 파일
├── modeler/
│   ├── __init__.py
│   └── model.py          # 모델 관련 기능을 담은 파일
├── evaluator/
│   ├── __init__.py
│   └── evaluate.py       # 모델 평가 기능을 담은 파일
├── main.py               # 프로젝트의 유일한 진입점
├── requirements.txt
└── README.md

# 추가 기능
├── server/
│   ├── __init__.py
│   └── app.py            # (추가 기능) 웹 서버 구동 스크립트
├── web/
│   ├── static/
│   └── templates/        

• crawler/: 웹사이트에서 데이터를 수집하는 역할을 담당합니다. 입력 링크를 받아 index, content, link, date를 포함하는 CSV 파일을 출력합니다.
• answer/: LLM API를 이용하여 크롤링된 CSV 파일에 요약된 내용을 추가합니다. 요약 기능을 별도로 구현하여 summarizer.py에 포함할 수 있습니다.
• preprocessor/: CSV 파일을 pandas DataFrame과 같은 데이터 구조로 변환하고, 모델에 적합하도록 전처리하여 CSV 파일로 출력합니다.
• modeler/: 전처리된 데이터를 바탕으로 모델을 학습시키고, 선택된 모델 파일을 저장합니다. 모델 선택 기준을 코드에 명시하여 다양한 모델을 시험해볼 수 있습니다.
• main.py: 각 모듈을 통합하여 전체 워크플로우를 관리하는 역할을 합니다.
• requirements.txt: 협업 시 모든 개발자가 동일한 개발 환경을 갖출 수 있도록 필요한 라이브러리들을 기록합니다.

추가 기능

• server/ & web/: 사용자가 프로젝트와 상호작용할 수 있는 웹 인터페이스를 제공합니다. server/는 API를, web/는 프론트엔드 파일을 담당합니다.

커밋 규칙

커밋 메시지 작성 규칙

type(scope): description

• type: 위에서 설명한 커밋 타입 (예: feat, fix, docs).
• scope (선택 사항): 변경 사항이 영향을 미치는 범위를 명시합니다. (예: feat(login):)
• description: 변경 사항을 간결하게 설명합니다.

이러한 규칙을 사용하면, 커밋 메시지만 보고도 어떤 변경이 일어났는지 빠르게 파악할 수 있어 협업 효율성을 높일 수 있습니다.

다음은 일반적으로 사용되는 접두어와 그 의미입니다.

주요 커밋 타입

• feat (Features): 새로운 기능을 추가할 때 사용합니다.
  • 예시: feat: 사용자 로그인 기능 추가
• fix (Bug Fixes): 버그를 수정할 때 사용합니다.
  • 예시: fix: 로그인 시 발생하던 오류 수정
• docs (Documentation): 코드에 영향을 주지 않는 문서(README, 주석 등)를 변경할 때 사용합니다.
  • 예시: docs: README.md 파일에 설치 방법 추가
• style (Code Style): 코드의 기능 변경 없이 스타일만 변경할 때 사용합니다. (세미콜론, 들여쓰기, 공백 등)
  • 예시: style: 코드 포맷팅 규칙 적용
• refactor (Code Refactoring): 코드를 리팩토링할 때 사용합니다. 기능의 변경이나 버그 수정 없이 코드를 더 효율적이거나 읽기 쉽게 만들 때 사용합니다.
  • 예시: refactor: 함수명을 더 명확하게 변경
• test (Tests): 테스트 코드(단위 테스트, 통합 테스트 등)를 추가하거나 수정할 때 사용합니다.
  • 예시: test: 로그인 기능에 대한 단위 테스트 추가
• chore (Chore): 빌드, 패키지 관리 등 코드 자체와 직접적인 관련이 없는 작업을 처리할 때 사용합니다. (예: .gitignore 수정, 라이브러리 업데이트)
  • 예시: chore: .gitignore에 가상 환경 폴더 추가

NLP 남은 발표 및 마치며

3조: smart_summary_bot

https://github.com/hosugator/smart_summary_bot

시작부터 모듈화를 고민한 점이 인상적이다.

추후 재사용 및 확장이 가능하므로, 취합 및 통합 구현까지 완성해봐라.

다만, 뉴스 요약 정도는 LLM API 유료 서비스를 이용하기보다는, 허깅 페이스의 kogpt 등을 사용하면 유사한 성능으로 사용 가능하다.

마치며

전술하였듯, LLM 모델 학습은 방대한 데이터/고성능 하드웨어가 필수적이므로, 실무에서는 직접 생성하는 일은 드물다.

pre-trained 모델을 전이 학습으로 파인 튜닝하여, 특정 목적에 따라 사용하면 된다.

이 때, 모든 코드들을 동작 가능하게 만든 후에, 실제 학습에서는 GPU 렌탈 서비스를 이용하면 된다.

다양한 GPU 렌탈 서비스들이 있으므로, 사용량 기준보다는 시간 단위 서비스를 선택해서 해봄직하다.