프로젝트가 끝나고 포트폴리오를 쓰려고 앉으면 손이 잘 안 움직여요. 분명 몇 달을 열심히 했는데, 막상 적으려니 "쇼핑몰 서비스 개발, React 사용, 프론트엔드 담당" 정도밖에 떠오르지 않아요.
이유는 간단해요. 기억은 흐려졌고, 내가 한 일의 근거가 손에 없기 때문이에요. 그런데 그 근거는 이미 레포에 다 남아 있어요.
포트폴리오가 답해야 하는 질문
포트폴리오를 읽는 사람이 팀 프로젝트에서 궁금해하는 것은 결국 세 가지예요.
- 이 프로젝트는 무엇인가요?
- 그중에서 이 사람이 한 일은 무엇인가요?
- 이 사람은 어떻게 일하는 사람인가요?
많은 포트폴리오가 첫 번째 질문에만 길게 답하고, 두 번째와 세 번째는 "프론트엔드 담당" 한 줄로 넘어가요. 정작 읽는 사람이 가장 알고 싶은 것은 두 번째와 세 번째인데 말이에요.
자주 하는 실수
- 팀이 한 일과 내가 한 일을 섞어서 적어요. "실시간 채팅 기능을 구현했습니다"라고 적었는데 실제로는 화면만 맡았다면, 면접에서 서버 쪽 질문을 받았을 때 곤란해져요.
- 기술 이름만 나열해요. 기술 스택 목록은 무엇을 썼는지만 알려 주고, 그것으로 무엇을 했는지는 알려 주지 않아요.
- 역할을 뭉뚱그려요. "백엔드 개발"보다 "주문과 결제 API, 관리자 통계 조회"가 훨씬 많은 것을 말해 줘요.
- 근거 없이 크기를 말해요. "프로젝트의 대부분을 담당"이라는 말은 숫자가 함께 있을 때만 힘이 있어요.
레포에서 재료를 꺼내는 순서
1. 프로젝트를 한 문장으로 정의해요
"누구를 위한, 무엇을 하는 서비스"인지 한 문장으로 적어요. 길게 설명하고 싶겠지만, 읽는 사람은 첫 문장에서 계속 읽을지 정해요.
팀 프로젝트의 GitHub 레포를 분석해서 참여자별 기여도를 대화로 알려 주는 웹 서비스
2. 기술 스택을 종류별로 정리해요
언어, 프레임워크, 데이터베이스, 배포 환경으로 나눠서 적어요. 한 줄로 길게 늘어놓는 것보다 표나 묶음으로 보여주는 편이 훨씬 잘 읽혀요.
3. 내가 맡은 기능을 항목으로 나눠요
여기가 가장 중요해요. 내 커밋을 처음부터 훑으면서 기능 단위로 묶어 보세요. 한 문장으로 뭉치지 말고 세 개에서 여덟 개 정도의 항목으로 나누는 것이 좋아요.
- 소셜 로그인과 토큰 재발급 처리
- 상품 목록 무한 스크롤과 검색 필터
- 장바구니 수량 변경과 금액 계산
- 주문 내역 화면과 배송 상태 표시
이렇게 적으면 읽는 사람이 궁금한 항목을 골라서 물어볼 수 있어요.
4. 숫자로 뒷받침해요
커밋 수, 추가하고 삭제한 라인 수, 팀 안에서의 기여도를 함께 적어요. 다만 숫자는 주장을 뒷받침하는 용도로만 써요. 숫자 자체가 자랑이 되면 오히려 역효과가 나요.
한 가지 조심할 점이 있어요. 패키지 잠금 파일이나 빌드 결과물처럼 자동으로 만들어지는 파일이 섞이면 라인 수가 크게 부풀어요. 이런 파일을 빼고 계산한 숫자를 쓰는 편이 정직하고, 질문을 받았을 때도 당당해요.
5. 일하는 방식을 보여줘요
커밋 메시지 규칙을 지켰는지, PR을 어떻게 올렸는지, 작업을 얼마나 작게 나눴는지는 협업할 줄 아는 사람인지를 보여주는 근거예요. "협업 경험이 있습니다"라고 쓰는 것보다 "브랜치를 기능 단위로 나누고 PR 템플릿에 맞춰 리뷰를 요청했습니다"라고 쓰는 편이 훨씬 구체적이에요.
5분 만에 재료 모으기
위 다섯 가지를 직접 정리하려면 커밋을 하나씩 열어 봐야 해서 시간이 꽤 걸려요. WhoIsLoafing에 레포 링크를 넣으면 이 재료를 한 번에 받아볼 수 있어요.
| 포트폴리오에 필요한 것 | WhoIsLoafing에서 받는 것 |
|---|---|
| 프로젝트 한 문장 소개 | 레포 한 문장 정의 |
| 기술 스택 | 종류별로 정리한 기술 스택 |
| 내가 맡은 기능 | 참여자별 기능 목록 |
| 숫자 근거 | 커밋 수, 라인 수, 두 가지 기준의 기여도 |
| 일하는 방식 | 코드 스타일, 커밋 메시지 규칙, 활동 시간대 |
분석 전에 잠금 파일과 빌드 결과물을 뺄지 물어보는데, 포트폴리오에 쓸 숫자라면 빼고 계산하기를 고르는 것을 추천해요. 분석이 끝난 뒤 "특정 참여자 상세"에서 내 이름을 고르면 내 몫만 따로 볼 수 있어요.
결과는 공유하기를 누르면 링크로 만들 수 있어요. 포트폴리오에 그 링크를 붙여 두면 읽는 사람이 직접 근거를 확인할 수 있어요. 다만 공유한 뒤에는 그 채팅에서 분석을 더 이어갈 수 없으니, 필요한 질문을 다 해 본 다음에 공유하세요.
받은 결과를 그대로 붙이지는 마세요
분석 결과는 재료일 뿐이고, 포트폴리오는 내 말로 써야 해요. 기능 목록의 각 항목마다 아래 세 가지를 한두 문장씩 덧붙여 보세요.
- 왜 이 기능을 이렇게 만들었나요?
- 만들면서 무엇이 어려웠고 어떻게 풀었나요?
- 다시 한다면 무엇을 다르게 하고 싶나요?
기록은 무엇을 했는지까지만 말해 줘요. 왜 그렇게 했는지는 내가 채워야 하고, 그 부분이 포트폴리오에서 가장 읽을 만한 대목이에요.
미리 알아 두면 좋은 것
- 분석은 공개 레포만 할 수 있어요. 비공개 레포라면 잠시 공개로 바꾸거나, 공개해도 되는 범위인지 팀과 먼저 이야기해 보세요.
- 여러 이메일로 커밋했더라도 같은 GitHub 계정이면 한 사람으로 합쳐서 계산해요. 계정에 연결되지 않은 이메일로 커밋한 적이 있다면 GitHub 설정에서 그 이메일을 계정에 추가해 두세요.
- 기획, 디자인, 발표 준비처럼 커밋에 남지 않는 기여는 숫자에 잡히지 않아요. 이런 일을 했다면 포트폴리오에 따로 적어 주세요.