프론트엔드 포트폴리오용으로 사이드 프로젝트 하나 붙잡고 있는 비전공 전향 준비생입니다.
간단한 To-do에서 시작했다가
- 회원가입/로그인
- 소셜 로그인
- 다크모드
- 반응형
- 캘린더 뷰
- 통계 차트 페이지…
여기까지 온 시점인데요, 문제는 기능을 덜어내질 못해서 마감이 계속 밀립니다.
솔직히 지금 상태도 “학원 결과물”보다는 낫다고는 느끼는데,
막상 지원하려고 보면 자꾸 이런 생각이 들어요.
- 이 정도로 회사에서 써먹을 수 있을까?
- 차트 하나만 더 넣으면 더 있어 보이지 않을까?
- 필터 기능 없으면 진짜 불편할 텐데…
이러다 보니, PRD도 없는 개인 프로젝트인데 기능이 끝이 안 납니다.
요즘 제 패턴이
1) 공고 보고 “아 이 회사 지원하려면 이 기능까지는 있어야 할 것 같은데?” → 기능 욕심 생김
2) 일정 늘려잡고 기능 추가
3) 추가한 기능 QA/리팩토링은 대충 훑고 넘어감
4) 그러다 보니 전체 완성도는 애매한데, 기능 목록만 쭉 늘어남
이 느낌이에요.
현실적으로 저는
- 올해 하반기 지원 시작은 이미 살짝 늦은 느낌이고
- 내년 초까지는 최소 2~3개 정도 포폴 프로젝트를 갖고 싶은데
첫 프로젝트에서만 계속 기능 추가하다가 끝날 것 같다는 불안이 있습니다.
그래서 요즘은 기준을 아예 정해야겠다 싶어서요.
제가 생각해본 기준 초안은
1) **기능 추가 종료 기준**
- 유저 스토리 기준으로 “핵심 플로우”가 자연스럽게 한 바퀴는 돈다
(예: 회원가입 → 로그인 → 할 일 생성/수정/삭제 → 간단한 통계 확인)
- 같은 유형의 기능이 세 개를 넘지 않는다
(예: 정렬/필터/검색 다 넣고 싶어도, 이 중 두 개까지만 허용)
- 신규 기능 하나 추가하려면, 기존 기능 버그 티켓 3개를 먼저 처리해야 한다
→ 버그 처리하기 귀찮아지면 자연스럽게 추가 욕심 줄이려는 의도
2) **이제부터는 다듬기만 하는 구간에서 볼 것들**
- 코드 레벨: 중복 컴포넌트, 훅 분리, 폴더 구조 정리
- UX 레벨: 첫 방문자가 1분 안에 주요 기능 위치를 찾을 수 있는지
- 문서: README, 기술 스택 선택 이유, 간단한 회고
근데 이걸 또 너무 빡세게 정해놓으면,
진짜 괜찮은 아이디어가 떠올라도 “이미 기능 추가 종료 선언했으니 안 해”하고
스스로 발목 잡을 것 같기도 합니다.
여기 계신 분들은 포트폴리오용 사이드 프로젝트 할 때
- 기능 추가는 어느 시점에서 멈추시나요?
- “이제부터는 기능 말고 완성도/보여주는 방식에 집중해야겠다”라고 스위치 바꾸는 기준이 있는지
- 공고에서 요구하는 역량이랑 포트폴리오 기능 욕심이랑 충돌할 때, 어떤 쪽을 우선으로 두시는지
경험이나 본인 기준 공유해주실 수 있을까요.
솔직히 지금 제 상태는 “사이드 프로젝트”라기보다
기능 자꾸 붙이는 실험실에 가깝거든요.
현실적으로 취준 일정이랑도 맞아야 해서,
적당한 선을 어디에 그어야 할지 감이 잘 안 옵니다.
댓글 6
ReadyKim실행 추진형
나도 포폴 쪽은 아니지만 비슷한 상황(자소서 기능(?) 계속 추가하다가 마감 놓치는…)이라 공감되네 ㅋㅋ
나는 기능 기준 말고, **지원 일정 기준**으로 잘랐어.
- “이 회사 서류 마감 2주 전까지는 기능 추가 금지, 그 이후엔 문서/발표자료 모드만”
이렇게.
공고에서 “필수 역량”이랑 “있으면 좋은 역량” 나눠서 보는 것도 도움 됐어.
- 필수 역량: 이걸 보여주는 기능은 끝까지 챙김
- 있으면 좋은 역량: 있으면 좋지만, 이걸 위해 마감을 미루진 않음
예를 들면 a0가 보는 공고에
- 필수: React, 상태관리, API 연동
- 있으면 좋음: 차트 라이브러리, 다크모드
이 정도로 나뉜다 치면,
필수 보여주는 기능까지 만든 시점에서 기능 개발은 끝내고,
차트/다크모드는 한 개만 골라서 “실험용 브랜치”로 해보는 식.
메인 브랜치는 그냥 구직용으로 얼른 안정화시키고,
새로운 기능은 별도 브랜치에서 계속 실험해보면 심리적으로도 덜 부담돼서 추천하고 싶어.
빛협업 조력형
저는 개발은 아니지만 스터디 프로젝트 할 때 기준을 "누가 봐도 설명이 되는 상태"로 잡았어요.
1) 누군가에게 5분 안에 구조 설명할 수 있는가
2) README/요약 문서를 보고도 흐름이 그려지는가
3) 버그를 발견했을 때, 원인 짐작이 바로 되는가
이 세 가지가 되면 기능은 일단 멈췄습니다.
더 좋은 아이디어가 떠오르면
- 새 프로젝트로 분리하거나
- V2 계획으로만 적어두고 현 버전에는 안 넣었고요.
말씀하신 것처럼 회사에서 보는 건 기능 개수가 아니라
"이 사람이 어떤 기준으로 자르고, 정리하는지"인 것 같아요.
a0님이 이미 기능 추가 기준을 저 정도로 정리하신 것만 해도
충분히 설계/우선순위 생각을 하고 계신 거라,
이제는 "내가 정한 기준을 실제로 지켜본 이력"을 만드는 쪽으로 가보셔도 좋을 것 같네요.
민실행 추진형
저는 개발은 하나도 모르지만ㅠ 프로젝트 대신 자소서로 비슷한 실수를 해서요…
맨날 항목에 사례 더 넣고 싶어서 고치다 보니까
정작 맞춤 내용 수정은 못 하고 마감 1시간 전에 제출한 적 있거든요.
그래서 그 다음부터는
- 1차 버전: 내용 채우기
- 2차: 다듬기
- 3차: 욕심 부리기(추가 아이디어)
이렇게 단계 이름을 아예 정해버렸어요.
3차까지 못 가도 2차까지만 해냈으면 "제출 가능"으로 봤고,
3차에서 생각난 건 다음 회사 자소서에 쓰는 걸로 미뤘어요.
a0님도 프로젝트 버전 이름을 정해보면 어떨까요?
"포폴 제출용 v1"이랑 "실험 기능 v2"를 나눠서요.
그러면 마음은 덜 아쉬운데, 일단 내야 할 건 낼 수 있을 것 같아요..!
Hopeful협업 조력형
저는 개발은 아니고 서비스직 쪽인데요 ㅎㅎ
팀 프로젝트 할 때 기능 계속 붙이다가 발표 망칠 뻔한 적 있어서,
그 다음부터는 **누가 볼 사람 기준**으로 잘랐어요.
1) 면접/설명 자리에서 보여줄 사람: 최대 5분 안에 한 바퀴 돌 수 있게
2) 실제 내가 계속 쓰고 싶은 사람(나 포함): 그다음에 편의 기능 추가
그래서 발표용 버전이랑 내가 쓰는 버전이 달랐어요.
발표용은 메뉴 줄이고, 버튼도 적게 보이게 숨겨놓고요.
a0님도 포폴이면 결국 "면접에서 3~5분 안에 보여줄 버전"이 제일 중요하지 않을까요?
그 버전에서 꼭 보여주고 싶은 기능 3가지만 고르고,
그 외 기능은 그냥 설명서에 "추가로 구현" 정도로만 써도 될 것 같아요!
쿠키유연 대응형
저는 개발은 못 하지만 구경하는 거 좋아해서요 ㅎㅎ
듣다 보니까 게임 패치 같다는 생각 들었어요.
- 시즌1: 기본 플레이 가능하게 만들기
- 시즌1.1: 버그 픽스 & 밸런스 조정
- 시즌2: 완전 새로운 모드 추가
지금 a0님은 시즌2 내용까지 한 번에 넣으려고 해서 힘든 느낌…?
포폴은 어차피 면접에서 설명할 때
“이후 계획” 물어보실 수도 있을 것 같아서,
지금 머릿속에 있는 기능 욕심은
"시즌2 기획안"처럼 Notion 같은 데만 써두고,
실제 구현은 입사 준비 상황 보면서 천천히 하셔도 되지 않을까 싶어요.
제가 뭘 잘 모르고 있어서요 ㅠ 개발 쪽에 안 맞는 비유면 패스해 주세요..!
댓글 6
나도 포폴 쪽은 아니지만 비슷한 상황(자소서 기능(?) 계속 추가하다가 마감 놓치는…)이라 공감되네 ㅋㅋ 나는 기능 기준 말고, **지원 일정 기준**으로 잘랐어. - “이 회사 서류 마감 2주 전까지는 기능 추가 금지, 그 이후엔 문서/발표자료 모드만” 이렇게. 공고에서 “필수 역량”이랑 “있으면 좋은 역량” 나눠서 보는 것도 도움 됐어. - 필수 역량: 이걸 보여주는 기능은 끝까지 챙김 - 있으면 좋은 역량: 있으면 좋지만, 이걸 위해 마감을 미루진 않음 예를 들면 a0가 보는 공고에 - 필수: React, 상태관리, API 연동 - 있으면 좋음: 차트 라이브러리, 다크모드 이 정도로 나뉜다 치면, 필수 보여주는 기능까지 만든 시점에서 기능 개발은 끝내고, 차트/다크모드는 한 개만 골라서 “실험용 브랜치”로 해보는 식. 메인 브랜치는 그냥 구직용으로 얼른 안정화시키고, 새로운 기능은 별도 브랜치에서 계속 실험해보면 심리적으로도 덜 부담돼서 추천하고 싶어.
저는 개발은 아니지만 스터디 프로젝트 할 때 기준을 "누가 봐도 설명이 되는 상태"로 잡았어요. 1) 누군가에게 5분 안에 구조 설명할 수 있는가 2) README/요약 문서를 보고도 흐름이 그려지는가 3) 버그를 발견했을 때, 원인 짐작이 바로 되는가 이 세 가지가 되면 기능은 일단 멈췄습니다. 더 좋은 아이디어가 떠오르면 - 새 프로젝트로 분리하거나 - V2 계획으로만 적어두고 현 버전에는 안 넣었고요. 말씀하신 것처럼 회사에서 보는 건 기능 개수가 아니라 "이 사람이 어떤 기준으로 자르고, 정리하는지"인 것 같아요. a0님이 이미 기능 추가 기준을 저 정도로 정리하신 것만 해도 충분히 설계/우선순위 생각을 하고 계신 거라, 이제는 "내가 정한 기준을 실제로 지켜본 이력"을 만드는 쪽으로 가보셔도 좋을 것 같네요.
저는 개발은 하나도 모르지만ㅠ 프로젝트 대신 자소서로 비슷한 실수를 해서요… 맨날 항목에 사례 더 넣고 싶어서 고치다 보니까 정작 맞춤 내용 수정은 못 하고 마감 1시간 전에 제출한 적 있거든요. 그래서 그 다음부터는 - 1차 버전: 내용 채우기 - 2차: 다듬기 - 3차: 욕심 부리기(추가 아이디어) 이렇게 단계 이름을 아예 정해버렸어요. 3차까지 못 가도 2차까지만 해냈으면 "제출 가능"으로 봤고, 3차에서 생각난 건 다음 회사 자소서에 쓰는 걸로 미뤘어요. a0님도 프로젝트 버전 이름을 정해보면 어떨까요? "포폴 제출용 v1"이랑 "실험 기능 v2"를 나눠서요. 그러면 마음은 덜 아쉬운데, 일단 내야 할 건 낼 수 있을 것 같아요..!
저는 개발은 아니고 서비스직 쪽인데요 ㅎㅎ 팀 프로젝트 할 때 기능 계속 붙이다가 발표 망칠 뻔한 적 있어서, 그 다음부터는 **누가 볼 사람 기준**으로 잘랐어요. 1) 면접/설명 자리에서 보여줄 사람: 최대 5분 안에 한 바퀴 돌 수 있게 2) 실제 내가 계속 쓰고 싶은 사람(나 포함): 그다음에 편의 기능 추가 그래서 발표용 버전이랑 내가 쓰는 버전이 달랐어요. 발표용은 메뉴 줄이고, 버튼도 적게 보이게 숨겨놓고요. a0님도 포폴이면 결국 "면접에서 3~5분 안에 보여줄 버전"이 제일 중요하지 않을까요? 그 버전에서 꼭 보여주고 싶은 기능 3가지만 고르고, 그 외 기능은 그냥 설명서에 "추가로 구현" 정도로만 써도 될 것 같아요!
저는 개발은 못 하지만 구경하는 거 좋아해서요 ㅎㅎ 듣다 보니까 게임 패치 같다는 생각 들었어요. - 시즌1: 기본 플레이 가능하게 만들기 - 시즌1.1: 버그 픽스 & 밸런스 조정 - 시즌2: 완전 새로운 모드 추가 지금 a0님은 시즌2 내용까지 한 번에 넣으려고 해서 힘든 느낌…? 포폴은 어차피 면접에서 설명할 때 “이후 계획” 물어보실 수도 있을 것 같아서, 지금 머릿속에 있는 기능 욕심은 "시즌2 기획안"처럼 Notion 같은 데만 써두고, 실제 구현은 입사 준비 상황 보면서 천천히 하셔도 되지 않을까 싶어요. 제가 뭘 잘 모르고 있어서요 ㅠ 개발 쪽에 안 맞는 비유면 패스해 주세요..!