돈을 받고 코드를 짜고 싶으면 "내가 돈을 주고 코딩을 맡길만한 사람인지" 증명하기 위한 작업물이 필요합니다.
그렇다고 강의에서 코드 따라친거 그대로 베껴서 제출하는 성의 없는 분들도 많은데 남의 코드 베껴서 제출하면 바로 티납니다.
코드 따라치기만 했던 사람을 선호하진 않아서 포트폴리오를 직접 만들어보는 시간이 중요합니다.
하지만 뭘 어떻게 만들어야할 지 모르겠는 분들을 위해 잠깐 가이드를 적어드리자면
1. 주제고르기
내가 만들고 싶었던 것을 만들어보는 것도 동기부여에 있어서 매우 좋은데
대부분은 코딩 하고싶어서 하는게 아니라 밥벌어 먹으려고 하는 분들이 많을 텐데 그런 분들은 어떤 재밌는 프로그램을 만들어보고 싶다는 생각을 평소에 해본 적이 없기 때문에
생전 처음 프로그램을 직접 기획해서 만드는 경우 주제와 구성이 어설플 확률이 높습니다.
그래서 직접 만든게 고등학생 습작만도 못한 퀄리티가 나올 것 같다면 다른 실제서비스를 똑같이 흉내내서 만들어보는 것도 좋습니다.
실제 서비스의 몇몇 페이지와 기능을 그대로 똑같이 만들어보는데 레이아웃과 디자인 바꾸고 재밌는 기능도 몇개 추가해보고 그런 식으로 시작해봅시다.
- 너무 베낀 것 같아보이면 기능은 유지하되 로고, 디자인, 주제를 살짝만 바꾸면 됩니다.
- 기획한 기능의 양이 많으면 금방 지치기 때문에 꼭 필요한 기능만 먼저 골라놓고 작은거 부터 하나하나 구현해봅시다.
- 재밌는 아이디어는 구글에 포트폴리오 예시들 검색해보거나 dribbble.com 같은 사이트에 방문해봅시다.
- 브라우저 Web API들을 이용하면 남들과 달라보이는 재밌는 기능들을 만들 수 있습니다.
- 아니면 요즘은 OpenAI 사이트 가면 GPT 답변을 쉽게 얻을 수 있는 API도 있는데 그런걸로 AI 서비스 만들어봐도 재밌어보입니다. 하지만 유료임
- 공공데이터 API를 가지고 유용한 현실에 도움되는 서비스를 만들어보는 것도 좋습니다.
- 강의에서 혼자 알아서 코드짜는 법 많이 알려드렸으니 잘 활용해보십시오
2. 내용채우기
포트폴리오는 내가 가진 전문성을 보여주는 역할을 해야하기 때문에 기업 입장에서 많이 찾는 기술들을 강제로 집어넣는게 중요합니다.
프론트엔드의 경우 리액트, 리덕스, 타입스크립트, ajax, react-query, next.js 같은 내용을 선호합니다. 만든 서버가 없어서 ajax를 사용할 수 없으면 따로 .json 파일같은걸 만들어서 어디 올려놓고 그걸 ajax 요청으로 가져와봅시다.
참고로 포트폴리오 안에 쌩자바스크립트 실력 보여주는거에 많은 시간 안쏟아도 됩니다. 요즘 세상에 쌩자바스크립트만 써서 개발하는 곳이 어딨습니까 거의 없음
백엔드의 경우 파일업로드, 회원기능, 라우터, 검색기능, validation기능, 페이지네이션, 에러나 예외사항 처리, 채팅기능, 클라우드배포, SQL, nodejs의 경우 타입스크립트, 스프링 등이 있습니다.
그런 기능들이 별로 필요없어도 일부러 집어넣는게 중요합니다.
3. 마무리
- 프론트엔드는 html css 잘 다루는지도 중요하기 때문에 이쁜 레이아웃 디자인, 반응형 레이아웃, UI 애니메이션도 있으면 나쁠게 전혀 없습니다.
- 프론트엔드는 Redux같은거 일부러라도 많이 사용하는 것도 중요합니다.
- 프론트엔드도 예외상황 처리 잘하면 전문성 있어보일 수 있습니다. input에 이상한거 입력하면? ajax 요청이 실패하면? 인터넷이 느려서 페이지 로딩이 느리면? 등의 상황에 대처해봅시다.
- 코드가 길어지면 코드들을 분리해두는 것도 좋습니다. 재사용하는 코드 & 긴 코드가 있으면 함수로 빼고, 함수들을 별도의 파일로 빼고, 비슷한 기능들을 하는 파일들은 찾기 쉽게 한 폴더에 모아놓는게 끝임
- 백엔드는 DB 컬렉션이나 테이블을 어떻게 설계해놨는지도 궁금해합니다. 예를 들어 댓글기능을 만들고 싶으면 어떤 DB 컬렉션이나 테이블에 어떻게 데이터를 밀어넣어야 댓글이 1억개여도 가져오기 쉬울까요?
- 백엔드는 에러나 예외사항에 대해 대처하는 코드도 잘 짜놨는지 확인합시다. 유저가 글제목을 너무 길게 작성하면 어떻게 할 것입니까.
- 백엔드는 API들을 요약한 API 문서 (자동생성해주는 라이브러리 쓰면 편함), 테이블간의 ERD 관계도 정리해두면 검토시 보기 좋습니다.
- 백엔드의 경우 DB 입출력 성능을 일부러 구리게 해놓고 개선한 뒤 성능최적화 했다고 포장하기도 좋은 방법입니다. 아니면 Redis같은 메모리DB, 캐싱, 인덱스같은 것도 있음
- 프론트엔드는 서버와 통신잘한다는걸 어필하는 것도 좋은데 서버가 없으면 Firebase도 좋은 선택입니다.
- 스터디같은 곳에서 팀프로젝트로 구현해봤으면 내가 어떤 부분을 맡았는지 표기합시다.
- 내가 만든 프로젝트 URL만 달랑 대충 제출해봤자 면접관들이 거길 직접 방문해서 로그인하고 실행해보지 않습니다. 프로젝트에 있는 기능을 사진과 함께 글로 설명 잘 해놓도록 합시다.
- Github 링크도 넣는다고 해서 코드 열심히 읽어보진 않습니다. 관심있는 것들만 읽어볼 뿐이라 코드도 괜찮아보이는 것들이 있으면 따로 뽑아서 글로 설명해놓는게 낫습니다.
- 유닛 테스트도 간단한거 해보면 나쁘지 않습니다. 유닛 테스트는 여러분이 만든 함수가 잘 작동하는지 컴퓨터에게 자동테스트 맡기는 것일 뿐임
- git도 혼자할 땐 귀찮지만 사용해봅시다.
- 자기소개 사이트도 따로 만드는 분들이 있는데 기특하긴 하지만 구성이 더럽고 디자인이 쓰레기같으면 오히려 단점이라 자기소개는 notion 같은 곳에 작성해놓는 것도 좋습니다.
4. 기록
남들 코드 베낀티가 나지 않으려면 여러분이 고민했다는 흔적을 남기는 것도 중요합니다.
- 내가 만든 프로젝트에 어떤 기능이 있고 어떤 기술을 썼고 어떤 문제가 있었고 어떻게 해결했는지 사진, 코드와 함께 기재해놓는게 좋습니다. 니가 알아서 코드 읽어보라는 식으로 제출하면 아무도 안봄
- 블로그하나 만들어서 거기에 포트폴리오 만들면서 어려웠던 점, 새로 배웠던 점을 기록해두는 것도 좋습니다. 사람들 잘 모르는 최신기술 같은 것도 많이 기록해두면 좋은데 "개발에 관심있는 척" 하는 좋은 수단입니다.
- 강의 내용만 베껴서 블로그에 정리해놓는 분들 많은데 그걸로 공부한 척 하는거 보다는 본인이 직접 코드짜면서 대가리 굴린 흔적을 기록해두는게 훨씬 더 좋은 인상을 줍니다.