20 KiB
백엔드 포트폴리오 프로젝트 작성 컨텍스트
이 문서는 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은 프로젝트 포트폴리오를 작성할 때 아래 구조를 따른다.
## 프로젝트명
### 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 작성 프롬프트 템플릿
아래 템플릿에 프로젝트 정보를 넣으면 이 문서의 기준에 맞춰 포트폴리오 항목을 작성한다.
너는 백엔드 개발자 포트폴리오 작성 도우미다.
아래 프로젝트 정보를 바탕으로 포트폴리오 프로젝트 항목을 작성해라.
작성 기준:
- 문제 정의 → 역할 → 기술 선택 → 구현 → 문제 해결 → 성과 → 회고 흐름으로 작성
- 추상적인 표현 금지
- 백엔드 관점의 데이터 흐름, API 흐름, 인증/인가, 예외 처리, 성능 개선을 드러낼 것
- 기술 스택은 사용 이유와 함께 작성
- 성과는 수치가 있으면 수치로, 없으면 구체적인 정성 성과로 작성
- 마지막에 체크리스트 기준으로 부족한 부분을 별도로 지적할 것
프로젝트 정보:
- 프로젝트명:
- 프로젝트 배경:
- 프로젝트 목표:
- 주요 기능:
- 팀 구성:
- 내가 맡은 역할:
- 내가 구현한 기능:
- 사용 기술:
- 기술 선택 이유:
- 문제 해결 사례:
- 성과/결과:
- 아쉬운 점:
- 개선 방향:
출력 구조:
1. 프로젝트 개요
2. 담당 역할
3. 주요 기여
4. 사용 기술 및 선택 이유
5. 구현 사항
6. 문제 해결 사례
7. 성과 및 결과
8. 회고
9. 보완 필요 사항 체크리스트
13. 압축 요약
백엔드 포트폴리오 프로젝트 항목은 기능 소개가 아니라 기술적 판단의 기록이어야 한다. 좋은 작성은 다음 질문에 답한다.
- 왜 만든 프로젝트인가?
- 내가 맡은 백엔드 책임 범위는 무엇인가?
- 어떤 기술을 왜 선택했는가?
- API와 데이터 흐름은 어떻게 설계했는가?
- 어떤 문제가 있었고 어떻게 해결했는가?
- 결과적으로 무엇이 개선되었는가?
- 다음에는 무엇을 더 잘할 수 있는가?