vault backup: 2026-06-01 16:40:05

프롬프트/백엔드 + 인프라 + 설계 프로젝트 포트폴리오 정보 추출 요청.md

@@ -149,6 +149,7 @@
 - Cache 적용 여부
 - 응답 시간 측정 또는 개선 수치
 - 성능상 아쉬운 부분
+- 벤치마킹 결과
 
 ## 15. 설계 문서화
 - README 구조
@@ -180,22 +181,7 @@
 ### 결과
 성능, 안정성, 유지보수성, 확장성, 운영 편의성 측면에서 어떤 개선이 있었는지
 
-## 17. 포트폴리오 문장 초안
-위 분석을 바탕으로 아래 항목별로 바로 사용할 수 있는 문장 초안을 작성해줘.
-
-- 프로젝트 개요
-- 담당 역할
-- 주요 기여
-- 사용 기술 및 선택 이유
-- 아키텍처 설계
-- API 설계
-- 인프라 구성
-- 문제 해결 사례
-- 프로젝트 성과
-- 회고
-
 주의:
 - 실제 코드에서 확인되는 내용만 작성해줘.
-- 확인되지 않는 내용은 “확인 필요”로 표시해줘.
 - 단순 기능 나열이 아니라 “문제 → 설계 선택 → 구현 방식 → 결과” 구조로 작성해줘.
 - 백엔드 개발자 관점에서 API, 인증/인가, DB, 트랜잭션, 예외 처리, Docker, Reverse Proxy, 환경변수, 로그, 배포 구조를 강조해줘.

프롬프트/포트폴리오_자기소개-기술_항목_작성.md

@@ -0,0 +1,316 @@
+# 백엔드 포트폴리오 자기소개/기술스킬 작성 컨텍스트
+
+## 목적
+백엔드 개발자 포트폴리오의 `슬로건`, `한 줄 소개`, `자기소개`, `기술스킬` 항목을 구체적이고 평가자 친화적으로 작성한다.  
+추상적 태도보다 실제 구현 경험, 백엔드 직무 연관성, 기술 활용 수준을 드러내는 것이 핵심이다.
+
+---
+
+## 작성 원칙
+
+### 1. 추상 표현 금지
+다음 표현은 단독 사용 금지:
+- 끊임없이 학습하는 개발자
+- 도전하는 개발자
+- 성장하는 개발자
+- 소통을 잘하는 개발자
+- 새로운 기술을 좋아합니다
+- 다양한 기술을 공부하고 있습니다
+
+사용하려면 반드시 구체적 경험과 연결한다.
+
+예:
+- 나쁨: 새로운 기술 학습을 좋아합니다.
+- 좋음: 파일 업로드와 실시간 알림 요구사항을 해결하기 위해 tus, SSE, Redis Pub/Sub 구조를 검토하고 적용했습니다.
+
+---
+
+## 1. 슬로건 작성 규칙
+
+### 목적
+지원자를 한 문장으로 기억시키는 문장.
+
+### 포함 요소
+- 백엔드 직무 강점
+- 문제 해결 방식
+- 주요 기술 영역
+- 프로젝트 경험 기반 특징
+
+### 작성 공식
+```text
+[구체적 강점]을 바탕으로 [백엔드에서 기여하는 방향]을 만드는 개발자
+````
+
+또는
+
+```text
+[기술/도메인 경험]을 통해 [추구 가치]를 구현하는 백엔드 개발자
+```
+
+### 좋은 예시
+
+```text
+복잡한 요청 흐름을 안정적인 API와 데이터 구조로 풀어내는 백엔드 개발자
+```
+
+```text
+파일 처리와 실시간 알림 흐름을 안정적으로 설계하며, 복잡한 백엔드 요구사항을 구조화하는 개발자
+```
+
+```text
+권한, 파일, 알림처럼 상태 변화가 많은 도메인을 유지보수 가능한 서버 구조로 구현하는 백엔드 개발자
+```
+
+---
+
+## 2. 한 줄 소개 작성 규칙
+
+### 목적
+
+현재 집중 기술과 앞으로의 성장 방향을 짧게 설명한다.
+
+### 포함 요소
+
+* 현재 집중 중인 기술
+* 실제 구현 경험
+* 백엔드 개발자로서의 지향점
+
+### 작성 공식
+
+```text
+현재는 [주요 기술/도메인]을 중심으로 [구현 경험]을 쌓고 있으며, 향후에는 [지향점]을 갖춘 백엔드 개발자로 성장하고자 합니다.
+```
+
+### 좋은 예시
+
+```text
+ASP.NET Core와 PostgreSQL을 기반으로 파일 처리, 권한 관리, 실시간 알림 기능을 구현하며 안정적인 서버 구조를 설계하는 백엔드 개발자를 지향합니다.
+```
+
+```text
+파일 업로드, 권한 관리, 알림 기능처럼 상태 변화가 많은 기능을 구현하며 API 설계와 데이터 모델링의 중요성을 경험했고, 유지보수성과 확장성을 고려하는 백엔드 개발자를 지향합니다.
+```
+
+---
+
+## 3. 자기소개 작성 규칙
+
+### 목적
+
+개발자로서의 현재 역량, 프로젝트 경험, 성장 방향을 2~3문단으로 설명한다.
+
+### 구성
+
+1. 내가 지향하는 백엔드 개발자상
+2. 실제 프로젝트 경험과 기술적 역할
+3. 앞으로의 성장 방향
+
+### 작성 공식
+
+```text
+저는 [백엔드 개발자로서의 강점/지향점]을 중요하게 생각합니다.
+
+[프로젝트/기능 경험]을 구현하며 [배운 점/기술 역량]을 경험했습니다. 특히 [주요 기술]을 활용해 [구체적 구현 내용]에 집중했습니다.
+
+앞으로는 [단순 기능 구현을 넘어 추구하는 방향]을 고려하는 백엔드 개발자로 성장하고자 합니다.
+```
+
+### 예시
+
+```text
+저는 사용자 요청 흐름과 데이터 처리 과정을 명확하게 설계하는 백엔드 개발자를 지향합니다.
+
+파일 업로드, 권한 관리, 알림 기능처럼 상태 변화가 많은 기능을 구현하며 API 설계와 데이터 모델링의 중요성을 경험했습니다. 특히 ASP.NET Core와 PostgreSQL을 중심으로 서버 기능을 구현하고, EF Core를 활용해 도메인에 맞는 데이터 구조를 설계하는 데 집중했습니다.
+
+앞으로는 단순히 기능을 구현하는 개발자를 넘어, 서비스의 안정성, 확장성, 유지보수성을 함께 고려할 수 있는 백엔드 개발자로 성장하고자 합니다.
+```
+
+---
+
+## 4. 기술스킬 작성 규칙
+
+### 목적
+
+기술 이름 나열이 아니라, 기술을 어느 수준으로 어떤 기능에 활용했는지 보여준다.
+
+### 필수 요소
+
+* 카테고리 구분
+* 주요 기술과 보조 기술 구분
+* 숙련도 기준 명시
+* 프로젝트 활용 경험 작성
+
+### 권장 카테고리
+
+```text
+Backend
+Database
+ORM
+Realtime / Async
+File / Storage
+Infra / DevOps
+Tools
+```
+
+### 기술스킬 작성 형식
+
+```md
+| Category | Skill | Level | 활용 경험 |
+|---|---:|---:|---|
+| Backend | ASP.NET Core | 3 | REST API, 인증/인가, DI, Middleware 기반 서버 기능 구현 |
+| Database | PostgreSQL | 3 | 관계형 모델링, 인덱스 고려, 조회 쿼리 작성 |
+| ORM | EF Core | 3 | 엔티티 매핑, Repository, 트랜잭션 처리 |
+| Realtime | SSE | 2 | 서버 이벤트 기반 실시간 알림 구현 |
+| Infra | Redis | 2 | Pub/Sub 기반 메시지 전달 구조 활용 |
+| Storage | tus | 2 | 재개 가능한 파일 업로드 흐름 구현 |
+| DevOps | Docker | 2 | 개발 환경 및 의존 서비스 구성 |
+```
+
+---
+
+## 5. 숙련도 기준
+
+### Level 1: 사용 경험 있음
+
+공식 문서나 예제를 참고해 기본 사용 가능.
+
+### Level 2: 기능 구현 가능
+
+CRUD, API 연동, 기본 설정 등 일반 요구사항 구현 가능.
+
+### Level 3: 프로젝트 적용 가능
+
+서비스 요구사항에 맞게 구조를 설계하고 주요 기능에 적용 가능.
+
+### Level 4: 문제 해결 가능
+
+성능 문제, 장애 원인, 구조 개선, 리팩터링까지 가능.
+
+주의:
+
+* 모든 기술을 상/중/하 또는 별점으로만 표시하지 않는다.
+* Level은 반드시 활용 경험과 함께 작성한다.
+
+---
+
+## 6. 주요 기술 / 서브 기술 구분 기준
+
+### Main Skills
+
+다음 중 하나 이상 해당:
+
+* 프로젝트 핵심 기능 구현에 사용
+* 직접 구조 설계
+* 문제 해결 과정에서 깊게 사용
+* 면접에서 설명 가능
+
+### Sub Skills
+
+다음에 해당:
+
+* 프로젝트에서 사용했지만 깊이는 낮음
+* 설정 중심 사용
+* 핵심 기능 보조
+* 기본 개념은 알지만 고급 활용 경험은 부족
+
+### 예시
+
+```md
+### Main Skills
+- C#
+- ASP.NET Core
+- PostgreSQL
+- EF Core
+- REST API
+- Authentication / Authorization
+
+### Sub Skills
+- Redis
+- SSE
+- Docker
+- Nginx
+- tus
+```
+
+---
+
+## 7. 기술 서술 예시
+
+### Backend
+
+```text
+C#과 ASP.NET Core를 사용해 REST API 서버를 구현했습니다. 인증/인가, 파일 업로드, 알림, 권한 관리 기능을 중심으로 API 흐름을 설계했으며, DI, Middleware, Filter를 활용해 공통 관심사를 분리했습니다.
+```
+
+### Database
+
+```text
+PostgreSQL과 EF Core를 사용해 서비스 도메인에 맞는 데이터 모델을 설계했습니다. 파일, 사용자, 권한, 알림과 같이 관계가 있는 데이터를 엔티티로 구성하고, 조회 성능을 고려해 쿼리 구조와 인덱스를 검토했습니다.
+```
+
+### Realtime / Async
+
+```text
+SSE와 Redis Pub/Sub을 활용해 서버 이벤트를 클라이언트에 전달하는 구조를 구현했습니다. 상태 변경 이벤트를 실시간으로 전달하고, 비동기 작업 흐름을 분리하는 방식에 대해 학습하고 적용했습니다.
+```
+
+---
+
+## 8. 최종 출력 형식
+
+LLM은 사용자의 프로젝트/기술 정보를 바탕으로 아래 형식으로 출력한다.
+
+```md
+# 자기소개 / 기술스킬
+
+## 슬로건
+[한 문장 슬로건]
+
+## 한 줄 소개
+[현재 집중 기술 + 구현 경험 + 지향점]
+
+## 자기소개
+[2~3문단 자기소개]
+
+## Skills
+
+### Main Skills
+| Category | Skill | Level | 활용 경험 |
+|---|---:|---:|---|
+| ... | ... | ... | ... |
+
+### Sub Skills
+| Category | Skill | Level | 활용 경험 |
+|---|---:|---:|---|
+| ... | ... | ... | ... |
+```
+
+---
+
+## 9. 검토 체크리스트
+
+### 슬로건
+
+* 백엔드 직무와 연결되는가?
+* 실제 프로젝트 경험과 관련 있는가?
+* 흔한 추상 표현만 사용하지 않았는가?
+
+### 한 줄 소개
+
+* 현재 집중 기술이 보이는가?
+* 구현 경험이 포함되어 있는가?
+* 앞으로의 개발 방향이 명확한가?
+
+### 자기소개
+
+* “좋아합니다”보다 “구현했습니다 / 설계했습니다 / 경험했습니다” 중심인가?
+* 기술, 프로젝트, 성장 방향이 연결되는가?
+* 평가자가 어떤 백엔드 역량을 가진 사람인지 알 수 있는가?
+
+### 기술스킬
+
+* 기술을 카테고리별로 정리했는가?
+* Main Skill과 Sub Skill을 구분했는가?
+* 숙련도 기준이 명확한가?
+* 기술 이름만 나열하지 않았는가?
+* 각 기술의 활용 경험이 작성되어 있는가?

프롬프트/포트폴리오_프로젝트_항목_작성.md

@@ -0,0 +1,516 @@
+# 백엔드 포트폴리오 프로젝트 작성 컨텍스트
+
+이 문서는 LLM이 백엔드 개발자 포트폴리오의 프로젝트 항목을 작성할 때 따라야 할 압축 컨텍스트이다. 목적은 토큰 사용량을 줄이면서도, 프로젝트 소개가 단순 기능 나열이 아니라 **문제 정의 → 역할 → 기술 선택 → 구현 → 문제 해결 → 성과 → 회고** 흐름을 갖도록 만드는 것이다.
+
+---
+
+## 작성 원칙
+
+- 추상적인 표현을 피하고 구체적인 업무 단위로 작성한다.
+- “무엇을 했다”보다 “왜 그렇게 했고, 어떤 결과가 있었는지”를 함께 작성한다.
+- 백엔드 관점에서 데이터 흐름, API 처리 흐름, 인증/인가, 트랜잭션, 예외 처리, 성능 개선, 운영 관점을 드러낸다.
+- 팀 프로젝트라면 본인이 담당한 영역과 팀원과의 인터페이스를 구분한다.
+- 가능하면 정량적 결과를 사용한다. 수치가 없다면 구조 개선, 협업 비용 감소, 유지보수성 향상 등 정성적 성과를 구체화한다.
+- “팀원과 협력”, “열심히 구현”, “속도 상승”, “여러 기술 사용” 같은 모호한 표현은 사용하지 않는다.
+
+---
+
+## 1. 프로젝트 개요
+
+### 목적
+
+프로젝트가 어떤 문제를 해결하기 위해 시작되었고, 어떤 사용자를 대상으로 어떤 가치를 제공하는지 설명한다.
+
+### 포함할 내용
+
+- 프로젝트 배경
+- 해결하려는 문제
+- 프로젝트 목표
+- 주요 기능 키워드
+- 서비스 대상 사용자 또는 사용 환경
+
+### 작성 구조
+
+문제 상황 → 프로젝트 목표 → 핵심 기능 → 기대 가치
+
+### 예시 문장
+
+본 프로젝트는 사용자가 파일을 안전하게 저장하고 공유할 수 있는 파일 협업 서비스를 구현하는 것을 목표로 진행되었다. 기존 클라우드 기반 파일 서비스는 편리하지만 데이터 저장 위치와 접근 권한을 직접 통제하기 어렵고, 장기적으로 구독 비용이 증가한다는 문제가 있었다. 이를 해결하기 위해 사용자가 직접 관리 가능한 저장소 환경에서 파일 업로드, 다운로드, 권한 관리, 공유, 실시간 알림 기능을 제공하는 백엔드 중심의 협업 플랫폼을 개발하였다.
+
+### 피해야 할 표현
+
+- 프로젝트 개요를 작성하지 않음
+- 책 추천 프로그램 개발
+- 파일 관리 서비스 개발
+- 여러 기능을 제공하는 서비스
+
+---
+
+## 2. 담당 역할 및 기여 1: 팀 내 역할
+
+### 목적
+
+팀 안에서 본인이 어떤 영역을 책임졌는지 명확히 설명한다.
+
+### 포함할 내용
+
+- 팀 내 역할
+- 담당 도메인
+- 책임진 기능 또는 모듈
+- 프론트엔드, 인프라, 다른 백엔드 팀원과의 협업 지점
+
+### 작성 구조
+
+팀 내 역할 → 담당 도메인 → 책임진 기능 → 협업 방식
+
+### 예시 문장
+
+팀 내에서 백엔드 개발을 담당하였으며, 파일 관리 도메인과 권한 검증 로직을 중심으로 구현하였다. 사용자의 파일 업로드 요청이 실제 저장소에 반영되기까지의 흐름을 설계하고, 파일 메타데이터 저장, 폴더 구조 관리, 사용자별 접근 권한 확인, 다운로드 권한 검증 API를 개발하였다. 또한 프론트엔드에서 필요한 API 명세를 정의하고 예외 응답 형식을 통일하여 클라이언트 연동 과정의 혼선을 줄였다.
+
+### 피해야 할 표현
+
+- 팀원들을 도와 프로젝트 수행
+- 분배 후 협력하여 완성
+- 백엔드 전반 담당
+- 프로젝트에 전반적으로 참여
+
+---
+
+## 3. 담당 역할 및 기여 2: 업무 단위별 기여
+
+### 목적
+
+본인의 기여를 기능, 모듈, API, 데이터 구조, 성능 개선 단위로 구체화한다.
+
+### 포함할 내용
+
+- 구현한 API
+- 설계한 데이터 모델
+- 담당한 도메인 로직
+- 처리한 예외 상황
+- 개선한 성능 또는 구조
+- 테스트, 문서화, 배포 기여
+
+### 작성 구조
+
+기능명 → 내가 한 일 → 선택 이유 → 결과
+
+### 예시 문장
+
+파일 업로드 기능에서는 단순히 파일을 저장하는 방식이 아니라, 업로드 세션을 생성하고 청크 단위로 파일을 전송한 뒤 최종 완료 시점에 메타데이터를 확정하는 구조로 설계하였다. 이를 통해 대용량 파일 업로드 중 네트워크 오류가 발생하더라도 업로드 상태를 추적할 수 있도록 했고, 파일 저장소와 데이터베이스 사이의 상태 불일치를 줄이는 데 집중하였다.
+
+### 기여도 예시 키워드
+
+- 인증/인가: 로그인, 토큰 발급, 사용자 식별, 권한 부족 예외 처리
+- 파일 처리: 업로드, 다운로드, 삭제, 메타데이터 저장, 저장소 경로 관리
+- 권한 관리: 사용자/그룹/파일/폴더 단위 접근 제어
+- 알림: 이벤트 기록, 알림 생성, 읽음 상태 관리, 실시간 전달
+- 성능 개선: Projection, 페이징, 커서 기반 조회, 인덱스, 쿼리 최적화
+- 운영: Docker, Nginx, 환경 변수, 로그, 배포 구조
+
+---
+
+## 4. 사용 기술 및 선택 이유
+
+### 목적
+
+기술 스택을 단순 나열하지 않고 프로젝트 요구사항과 연결해 설명한다.
+
+### 포함할 내용
+
+- 사용 기술
+- 사용 위치
+- 선택 이유
+- 대안 대비 장점
+- 프로젝트 요구사항과의 연결성
+
+### 작성 구조
+
+기술명 → 사용 위치 → 선택 이유 → 얻은 효과
+
+### 예시 문장
+
+ASP.NET Core는 API 서버 구현을 위해 사용하였다. 인증, 라우팅, 미들웨어, 의존성 주입 구조가 잘 제공되어 백엔드 기능을 계층적으로 분리하기에 적합하다고 판단하였다. 또한 정적 타입 기반 개발 환경을 활용할 수 있어 도메인 모델과 요청/응답 DTO를 명확히 정의할 수 있었다.
+
+PostgreSQL은 사용자, 파일, 폴더, 권한, 알림처럼 관계가 명확한 데이터를 저장하기 위해 사용하였다. 파일 권한 검증과 폴더 계층 구조 조회처럼 관계형 데이터 모델이 중요한 기능이 많았기 때문에 RDBMS가 적합하다고 판단하였다.
+
+Redis는 빠른 조회가 필요한 세션성 데이터와 실시간 이벤트 전달을 위해 사용하였다. 짧은 수명을 가진 데이터나 Pub/Sub 기반 메시지 전달을 Redis로 분리하여 DB 부하를 줄이고 실시간 처리 구조를 단순화하였다.
+
+### 피해야 할 표현
+
+- 여러 기술을 사용하여 완성
+- React, Spring, MySQL 사용
+- 익숙해서 사용
+- 다양한 기술을 활용
+
+---
+
+## 5. 구현 사항
+
+### 목적
+
+본인이 구현한 핵심 기능을 백엔드 처리 흐름 중심으로 설명한다.
+
+### 포함할 내용
+
+- 핵심 API
+- 요청 처리 흐름
+- 데이터 저장 구조
+- 인증/인가 검증
+- 예외 처리
+- 트랜잭션 처리
+- 비동기 처리
+- 테스트 또는 검증 방식
+
+### 작성 구조
+
+요청 발생 → 검증 → 처리 → 저장/변경 → 응답/이벤트
+
+### 예시 문장
+
+파일 업로드 기능은 업로드 요청을 받은 뒤 사용자 권한을 검증하고, 업로드 가능한 폴더인지 확인한 후 파일 메타데이터를 생성하는 흐름으로 구현하였다. 업로드 완료 후에는 파일 상태를 확정하고 관련 사용자에게 알림 이벤트를 생성하도록 구성하였다. 이를 통해 파일 저장, 메타데이터 관리, 알림 생성이 하나의 흐름으로 연결되도록 설계하였다.
+
+### 구현 항목 예시
+
+- 회원가입, 로그인, 로그아웃 API
+- 인증 토큰 발급 및 검증
+- 폴더 생성, 이름 변경, 삭제
+- 파일 업로드, 다운로드, 삭제
+- 사용자별 접근 가능한 파일 목록 조회
+- 파일/폴더 단위 권한 설정
+- 다운로드, 삭제, 공유 요청 시 권한 검증
+- 알림 목록 조회 및 읽음 상태 관리
+- 실시간 알림 전달
+
+### 피해야 할 표현
+
+- React로 구현
+- 데이터베이스에 데이터 저장
+- 파일 기능 구현
+- 로그인 기능 구현
+
+---
+
+## 6. 문제 해결 사례
+
+### 목적
+
+프로젝트 중 발생한 기술적 문제와 해결 과정을 설명한다.
+
+### 포함할 내용
+
+- 문제 상황
+- 원인 분석
+- 고려한 해결 방법
+- 최종 선택한 방법
+- 선택 이유
+- 해결 결과
+- 배운 점
+
+### 작성 구조
+
+문제 상황 → 원인 분석 → 해결 대안 → 선택한 방법 → 결과
+
+### 예시 문장 1: 조회 성능 문제
+
+파일 목록 조회 기능에서 폴더별 파일 수와 사용자 권한 정보를 함께 조회하면서 응답 시간이 증가하는 문제가 발생하였다. 초기 구현에서는 관련 엔티티를 한 번에 Include하여 조회했지만, 데이터가 증가할수록 불필요한 Join이 많아져 쿼리 비용이 커졌다. 이를 해결하기 위해 실제 응답에 필요한 필드만 Projection으로 조회하고, 권한 검증에 필요한 조건을 쿼리 수준에서 필터링하도록 변경하였다. 그 결과 불필요한 데이터 로딩을 줄이고 파일 목록 조회 응답 시간을 개선할 수 있었다.
+
+### 예시 문장 2: 데이터 정합성 문제
+
+파일 업로드 과정에서 실제 파일 저장은 완료되었지만 데이터베이스 메타데이터 저장에 실패할 경우 저장소와 DB 상태가 불일치할 수 있는 문제가 있었다. 이를 해결하기 위해 업로드 상태를 임시 상태와 확정 상태로 분리하고, 업로드 완료 시점에만 파일을 최종 사용 가능 상태로 전환하도록 설계하였다. 또한 실패한 업로드는 별도 정리 대상으로 관리하여 잘못된 파일이 사용자에게 노출되지 않도록 하였다.
+
+### 예시 문장 3: 비동기 알림 문제
+
+알림을 API 요청 흐름 안에서 즉시 생성하고 전달할 경우 알림 처리 지연이 API 응답 시간에 영향을 줄 수 있는 문제가 있었다. 이를 해결하기 위해 도메인 이벤트를 기록한 뒤 비동기 작업에서 알림 생성과 실시간 전달을 처리하도록 분리하였다. 이 구조를 통해 핵심 API 응답 흐름과 부가 처리를 분리하고, 알림 처리 실패가 주요 기능에 직접 영향을 주지 않도록 개선하였다.
+
+### 피해야 할 표현
+
+- 캐싱 전략으로 문제 해결
+- 팀원과 소통하여 문제 해결
+- 오류를 수정함
+- 성능을 개선함
+
+---
+
+## 7. 프로젝트 성과 및 결과
+
+### 목적
+
+프로젝트 결과를 정량적 또는 정성적 근거로 설명한다.
+
+### 포함할 내용
+
+- 응답 시간 개선
+- 쿼리 수 감소
+- 코드 중복 감소
+- 배포 시간 단축
+- 테스트 케이스 증가
+- 예외 처리 통일
+- API 연동 시간 단축
+- 유지보수성 개선
+
+### 작성 구조
+
+개선 전 문제 → 적용한 변화 → 개선 후 결과
+
+### 정량적 예시 문장
+
+파일 목록 조회 로직을 Projection 기반 쿼리로 변경하여 불필요한 데이터 로딩을 줄였고, 테스트 데이터 기준 평균 응답 시간을 약 000ms에서 000ms로 개선하였다.
+
+### 정성적 예시 문장
+
+API 예외 응답 형식을 통일하여 프론트엔드에서 에러 처리 분기 로직을 단순화하였다. 이를 통해 연동 과정에서 발생하던 응답 형식 불일치 문제를 줄이고, 기능 추가 시 동일한 에러 처리 기준을 재사용할 수 있도록 개선하였다.
+
+### 시각화 추천 항목
+
+- API 응답 시간 전후 비교
+- 쿼리 수 전후 비교
+- 업로드 처리 흐름 다이어그램
+- 인증/권한 구조 다이어그램
+- 배포 아키텍처 다이어그램
+- 이슈 처리 현황
+- 기능 구현 범위 표
+
+### 피해야 할 표현
+
+- OO으로 팀원과 적극적인 소통
+- 문제 해결 후 속도 상승
+- 성능이 좋아짐
+- 프로젝트를 성공적으로 완성
+
+---
+
+## 8. 프로젝트 회고
+
+### 목적
+
+프로젝트를 통해 배운 점, 아쉬운 점, 개선 방향을 기술적으로 설명한다.
+
+### 포함할 내용
+
+- 배운 기술적 내용
+- 설계 과정에서 느낀 점
+- 어려웠던 부분
+- 아쉬웠던 점
+- 다음 개선 방향
+- 개발자로서 성장한 부분
+
+### 작성 구조
+
+배운 점 → 아쉬운 점 → 다음 개선 방향
+
+### 예시 문장
+
+이번 프로젝트를 통해 백엔드 개발에서 기능 구현만큼 중요한 것이 데이터 흐름과 예외 상황을 설계하는 일이라는 점을 배웠다. 특히 파일 업로드처럼 실제 저장소와 데이터베이스 상태가 함께 관리되는 기능에서는 단순히 API가 정상 응답하는 것보다 실패 상황에서 어떤 상태를 남길 것인지가 중요하다는 것을 경험하였다.
+
+아쉬웠던 점은 초기 설계 단계에서 성능 테스트 기준을 명확히 잡지 못했다는 점이다. 기능 구현 이후에야 조회 성능과 업로드 처리 흐름을 점검하면서 일부 구조를 수정해야 했다. 다음 프로젝트에서는 주요 API별 예상 트래픽, 데이터 규모, 성능 측정 기준을 초기에 정의하고 구현 과정에서 지속적으로 검증하는 방식으로 개발하고자 한다.
+
+### 피해야 할 표현
+
+- 시간 부족으로 모든 기능 구현 X
+- 팀워크의 중요성을 깨달았다
+- 많은 것을 배웠다
+- 다음에는 더 열심히 하고 싶다
+
+---
+
+## 9. 최종 출력 구조
+
+LLM은 프로젝트 포트폴리오를 작성할 때 아래 구조를 따른다.
+
+```markdown
+## 프로젝트명
+
+### 1. 프로젝트 개요
+- 문제 배경
+- 프로젝트 목표
+- 핵심 기능
+- 기대 가치
+
+### 2. 담당 역할
+- 팀 내 역할
+- 담당 도메인
+- 책임진 기능
+- 협업 방식
+
+### 3. 주요 기여
+- 구현한 API/모듈
+- 설계한 데이터 구조
+- 개선한 로직
+- 본인의 구체적 기여
+
+### 4. 사용 기술 및 선택 이유
+- 기술 스택
+- 사용 위치
+- 선택 이유
+- 얻은 효과
+
+### 5. 구현 사항
+- 핵심 기능
+- 백엔드 처리 흐름
+- 인증/인가
+- 예외 처리
+- 데이터 저장/조회 구조
+
+### 6. 문제 해결 사례
+- 문제 상황
+- 원인 분석
+- 해결 방법
+- 결과
+
+### 7. 성과 및 결과
+- 정량적 성과
+- 정성적 성과
+- 시각화 가능한 지표
+
+### 8. 회고
+- 배운 점
+- 아쉬운 점
+- 개선 방향
+```
+
+---
+
+## 10. 최종 체크리스트
+
+LLM은 최종 답변을 작성한 뒤 아래 기준을 모두 점검한다.
+
+### 프로젝트 개요 체크리스트
+
+- [ ] 프로젝트를 왜 만들었는지 설명했는가?
+- [ ] 해결하려는 문제가 명확한가?
+- [ ] 단순 기능명이 아니라 서비스 목표가 드러나는가?
+- [ ] 주요 기능 키워드가 포함되어 있는가?
+
+### 담당 역할 체크리스트
+
+- [ ] 본인의 역할이 구체적인 도메인 단위로 작성되었는가?
+- [ ] “백엔드 담당”에서 끝나지 않고 책임진 기능이 드러나는가?
+- [ ] 팀원과의 협업 방식이 API 명세, 데이터 구조, 배포 환경 등 구체적 기준으로 설명되었는가?
+- [ ] 본인의 기여와 팀 전체 결과가 구분되어 있는가?
+
+### 주요 기여 체크리스트
+
+- [ ] 구현한 API 또는 모듈이 구체적으로 작성되었는가?
+- [ ] 기능명만 나열하지 않고 처리 흐름이 설명되었는가?
+- [ ] 설계한 데이터 구조나 도메인 로직이 포함되어 있는가?
+- [ ] 예외 처리, 권한 검증, 성능 개선 중 하나 이상이 드러나는가?
+
+### 기술 선택 체크리스트
+
+- [ ] 사용 기술을 단순 나열하지 않았는가?
+- [ ] 각 기술의 사용 위치가 명확한가?
+- [ ] 기술 선택 이유가 프로젝트 요구사항과 연결되어 있는가?
+- [ ] 대안 대비 선택 근거가 드러나는가?
+
+### 구현 사항 체크리스트
+
+- [ ] 핵심 기능이 백엔드 관점에서 설명되었는가?
+- [ ] 요청 → 검증 → 처리 → 저장 → 응답 흐름이 드러나는가?
+- [ ] 인증/인가 또는 권한 검증이 설명되었는가?
+- [ ] 데이터 저장, 조회, 변경 방식이 구체적인가?
+- [ ] 실패 케이스 또는 예외 처리가 포함되어 있는가?
+
+### 문제 해결 체크리스트
+
+- [ ] 어떤 문제가 발생했는지 명확한가?
+- [ ] 문제의 원인을 분석했는가?
+- [ ] 해결 방법이 구체적인가?
+- [ ] 왜 그 방법을 선택했는지 설명했는가?
+- [ ] 해결 결과가 정량적 또는 정성적으로 작성되었는가?
+
+### 성과 체크리스트
+
+- [ ] 전후 변화가 드러나는가?
+- [ ] 응답 시간, 쿼리 수, 코드 중복, 배포 시간, 테스트 등 지표가 있는가?
+- [ ] 수치가 없다면 정성적 성과가 구체적인가?
+- [ ] 시각화 가능한 데이터가 포함되어 있는가?
+
+### 회고 체크리스트
+
+- [ ] 단순 감상이 아니라 기술적 배운 점이 있는가?
+- [ ] 아쉬운 점이 구체적인가?
+- [ ] 다음 프로젝트에서의 개선 방향이 명확한가?
+- [ ] “팀워크의 중요성” 같은 흔한 표현을 피했는가?
+
+### 표현 체크리스트
+
+- [ ] “열심히”, “전반적으로”, “도와서”, “성공적으로” 같은 모호한 표현을 제거했는가?
+- [ ] 모든 문장이 가능한 한 구체적인 기능, 문제, 결과와 연결되는가?
+- [ ] 면접에서 추가 질문을 받아도 설명할 수 있는 내용인가?
+- [ ] 백엔드 개발자로서의 판단 과정이 드러나는가?
+
+---
+
+## 11. 금지 표현과 대체 표현
+
+| 금지 표현 | 대체 표현 |
+|---|---|
+| 책 추천 프로그램 개발 | 사용자의 독서 이력과 선호 장르를 기반으로 개인화 추천을 제공하는 서비스 개발 |
+| 팀원들을 도와 프로젝트 수행 | 백엔드 파트를 담당하며 인증, 추천 결과 저장, 사용자 히스토리 조회 API 구현 |
+| 프로젝트 전반적으로 기여 | 추천 결과 저장 데이터 모델을 설계하고 사용자별 추천 이력 조회 API 구현 |
+| 여러 기술을 사용하여 완성 | 빠른 추천 결과 조회를 위해 Redis 캐싱을 적용하고 사용자 행동 데이터는 PostgreSQL에 저장 |
+| React로 구현 | 사용자가 선택한 조건을 API 요청으로 전달하고 서버에서 필터링된 추천 결과를 반환하는 흐름 구현 |
+| 캐싱 전략으로 문제 해결 | 반복 조회되는 추천 결과를 Redis에 저장하여 동일 조건 검색 시 DB 조회를 줄이고 응답 시간 개선 |
+| 문제 해결 후 속도 상승 | 평균 응답 시간이 000ms에서 000ms로 감소하여 사용자 대기 시간 감소 |
+| 팀워크의 중요성을 깨달았다 | API 명세를 초기에 정리하지 않아 연동 과정에서 수정이 반복되었고, 이후 요청/응답 형식을 문서화하여 협업 비용 감소 |
+
+---
+
+## 12. LLM 작성 프롬프트 템플릿
+
+아래 템플릿에 프로젝트 정보를 넣으면 이 문서의 기준에 맞춰 포트폴리오 항목을 작성한다.
+
+```text
+너는 백엔드 개발자 포트폴리오 작성 도우미다.
+아래 프로젝트 정보를 바탕으로 포트폴리오 프로젝트 항목을 작성해라.
+
+작성 기준:
+- 문제 정의 → 역할 → 기술 선택 → 구현 → 문제 해결 → 성과 → 회고 흐름으로 작성
+- 추상적인 표현 금지
+- 백엔드 관점의 데이터 흐름, API 흐름, 인증/인가, 예외 처리, 성능 개선을 드러낼 것
+- 기술 스택은 사용 이유와 함께 작성
+- 성과는 수치가 있으면 수치로, 없으면 구체적인 정성 성과로 작성
+- 마지막에 체크리스트 기준으로 부족한 부분을 별도로 지적할 것
+
+프로젝트 정보:
+- 프로젝트명:
+- 프로젝트 배경:
+- 프로젝트 목표:
+- 주요 기능:
+- 팀 구성:
+- 내가 맡은 역할:
+- 내가 구현한 기능:
+- 사용 기술:
+- 기술 선택 이유:
+- 문제 해결 사례:
+- 성과/결과:
+- 아쉬운 점:
+- 개선 방향:
+
+출력 구조:
+1. 프로젝트 개요
+2. 담당 역할
+3. 주요 기여
+4. 사용 기술 및 선택 이유
+5. 구현 사항
+6. 문제 해결 사례
+7. 성과 및 결과
+8. 회고
+9. 보완 필요 사항 체크리스트
+```
+
+---
+
+## 13. 압축 요약
+
+백엔드 포트폴리오 프로젝트 항목은 기능 소개가 아니라 **기술적 판단의 기록**이어야 한다. 좋은 작성은 다음 질문에 답한다.
+
+1. 왜 만든 프로젝트인가?
+2. 내가 맡은 백엔드 책임 범위는 무엇인가?
+3. 어떤 기술을 왜 선택했는가?
+4. API와 데이터 흐름은 어떻게 설계했는가?
+5. 어떤 문제가 있었고 어떻게 해결했는가?
+6. 결과적으로 무엇이 개선되었는가?
+7. 다음에는 무엇을 더 잘할 수 있는가?
+