127 lines
4.1 KiB
Markdown
127 lines
4.1 KiB
Markdown
---
|
|
copilot-command-context-menu-enabled: true
|
|
copilot-command-slash-enabled: true
|
|
copilot-command-context-menu-order: 1150
|
|
copilot-command-model-key: ""
|
|
copilot-command-last-used: 0
|
|
---
|
|
# 라이브러리형 프로젝트 포트폴리오 정보 추출 요청
|
|
|
|
이 저장소를 라이브러리형 프로젝트 포트폴리오 작성 관점에서 분석해줘.
|
|
|
|
단순 기능 목록이 아니라, 아래 항목을 중심으로 “백엔드/라이브러리 개발자 포트폴리오에 쓸 수 있는 정보”를 뽑아줘.
|
|
|
|
## 1. 프로젝트 목적
|
|
- 이 라이브러리가 해결하려는 문제
|
|
- 기존 방식에서 개발자가 겪을 불편함
|
|
- 이 라이브러리를 사용했을 때 단순해지는 부분
|
|
- 주요 사용자
|
|
- 프로젝트를 한 줄로 설명할 수 있는 문장
|
|
|
|
## 2. Public API 설계
|
|
- 외부 사용자가 직접 호출하는 주요 클래스/인터페이스/메서드
|
|
- 가장 기본적인 사용 흐름
|
|
- Options/Config 구조
|
|
- 비동기 API 설계 여부
|
|
- CancellationToken 지원 여부
|
|
- 사용 예시 코드
|
|
- API 설계 의도
|
|
|
|
## 3. 내부 구조와 책임 분리
|
|
- 주요 폴더 구조
|
|
- 주요 클래스별 책임
|
|
- 인터페이스와 구현체 분리 여부
|
|
- 내부 구현과 외부 API의 분리 방식
|
|
- 확장 가능한 구조인지
|
|
- DI, Factory, Builder, Adapter 패턴 사용 여부
|
|
|
|
## 4. 설정과 확장성
|
|
- 사용자가 설정할 수 있는 옵션 목록
|
|
- 기본값 제공 방식
|
|
- 설정 검증 방식
|
|
- 사용자가 구현체를 교체할 수 있는 확장 지점
|
|
- 향후 기능 확장 시 기존 API를 깨지 않도록 설계된 부분
|
|
|
|
## 5. 오류 처리
|
|
- 예외 처리 방식
|
|
- Result/Error 타입 사용 여부
|
|
- 사용자 입력 오류와 시스템 오류 구분 방식
|
|
- 커스텀 예외 또는 에러 코드
|
|
- 실패 원인을 외부 사용자에게 전달하는 방식
|
|
- 재시도 가능한 오류와 불가능한 오류 구분 여부
|
|
|
|
## 6. 상태 관리
|
|
- 상태 enum 또는 상태 객체 존재 여부
|
|
- 상태 전이 흐름
|
|
- 완료/실패/취소 처리 방식
|
|
- 중복 실행 방지 여부
|
|
- 동시성 또는 thread-safe 고려 여부
|
|
|
|
## 7. 사용성
|
|
- README 구조
|
|
- Quick Start 존재 여부
|
|
- 샘플 프로젝트 존재 여부
|
|
- 최소 사용 코드
|
|
- 고급 사용 예제
|
|
- XML 주석 또는 문서화 수준
|
|
- 처음 사용하는 개발자가 헷갈릴 수 있는 부분
|
|
|
|
## 8. 테스트와 검증
|
|
- 테스트 프로젝트 존재 여부
|
|
- 단위 테스트 대상
|
|
- 통합 테스트 대상
|
|
- 실패 케이스 테스트
|
|
- Mock/Fake 사용 여부
|
|
- 샘플 앱을 통한 검증 여부
|
|
- 테스트가 부족한 부분
|
|
|
|
## 9. 패키징과 배포
|
|
- 패키지 배포 구조
|
|
- 버전 관리 방식
|
|
- 패키지 메타데이터
|
|
- CI/CD 또는 release workflow
|
|
- 빌드/테스트/패키징 명령어
|
|
- 실제 외부 프로젝트에서 사용할 수 있는 상태인지
|
|
|
|
## 10. 성능과 리소스 고려
|
|
- async/await 사용 방식
|
|
- Stream/buffer 처리 여부
|
|
- 메모리 사용량을 줄이기 위한 구조
|
|
- 반복 객체 생성 최소화 여부
|
|
- 성능 측정 또는 벤치마크 존재 여부
|
|
|
|
## 11. 포트폴리오용 문제 해결 사례 후보
|
|
아래 구조로 3~5개 후보를 찾아줘.
|
|
|
|
### 문제 상황
|
|
무슨 문제가 있었는지
|
|
|
|
### 원인 분석
|
|
왜 문제가 발생했는지
|
|
|
|
### 해결 방법
|
|
어떤 구조나 기술로 해결했는지
|
|
|
|
### 선택 이유
|
|
왜 그 방법을 선택했는지
|
|
|
|
### 결과
|
|
사용성, 안정성, 유지보수성, 확장성 측면에서 어떤 개선이 있었는지
|
|
|
|
## 12. 최종 포트폴리오 문장 초안
|
|
위 분석을 바탕으로 아래 항목별로 바로 사용할 수 있는 문장 초안을 작성해줘.
|
|
|
|
- 프로젝트 개요
|
|
- 담당 역할
|
|
- 주요 기여
|
|
- 사용 기술 및 선택 이유
|
|
- 구현 사항
|
|
- 문제 해결 사례
|
|
- 프로젝트 성과
|
|
- 회고
|
|
|
|
주의:
|
|
- 과장하지 말고 실제 코드에서 확인되는 내용만 작성해줘.
|
|
- 확인되지 않는 내용은 “확인 필요”로 표시해줘.
|
|
- 단순 기능 나열이 아니라 “문제 → 설계 선택 → 구현 방식 → 결과” 구조로 정리해줘.
|
|
- 라이브러리 사용자의 관점에서 사용성, 확장성, 안정성을 강조해줘. |