신입 개발자 포트폴리오 작성 - 3 (첨삭)

 

신입 개발자 포트폴리오 작성 - 1 (프로필 작성)

신입 개발자 포트폴리오 작성 - 2 (프로젝트 작성)

신입 개발자 포트폴리오 작성 - 3 (첨삭)

 

 

개요

---

전체 작성에 이어서...

필자는 이 글에 나와있는대로 작성한 포트폴리오와 이력서로 합격 후 회사에 다니고 있다.

그런데 2편까지 작성한 내용과 실제로 합격한 포트폴리오에 꽤 차이가 있음에도 수정 혹은 추가 작성을 하지 않은게 마음에 너무나도 걸려 이후의 첨삭 내용을 작성하기로 했다.

 

지인들과 멘토, 그리고 실제로 면접에 가서 들었던 이야기를 토대로 수정한 내용이 전혀 없어 이 부분에 대해 다룰 것이다.

 

그럼 시작해보자.

 

첨삭

---

프로젝트

대부분의 첨삭은 프로젝트 부분에서 이루어졌다. 내가 한 활동들에 대한 지적은 거의 없었으나 프로젝트 설명과 구성에 대한 지적이 꽤나 많이 들어왔다. 아무래도 포트폴리오는 프로젝트가 중점이다보니 더 그랬던 거 같다. 물론 내가 구성을 이상하게 한 게 많아서도 있다.

 

프로젝트 소개 순서

그 중 가장 먼저 들었던 이야기는 프로젝트 소개 순서였다. 이전에 작성했던 포트폴리오에서는 가장 최근에 한 프로젝트가 가장 마지막에 배치 되어있었다. ▼

가장 마지막에 배치되어있었다.

 

그 때 당시에는 시간 순서대로, 내가 성장한 과정을 보여주고 싶었기에 자연스럽게 가장 최근에 한 프로젝트가 마지막에 갔는데 이게 상당히 좋지 않은 배치라고 했다. 그 이유를 요약하면 이렇다.

• 너무나도 많은 프로젝트의 수
• 빠르게 어필을 할 필요성
• 인사담당자의 시간을 고려

짧은 시간 안에 인사담당자의 이목을 끌기 위해서는 내가 가장 잘 한 프로젝트부터 보여줘야한다. 심지어 필자처럼 프로젝트를 많이 넣을 생각이라면 더더욱 잘한거부터 보여줘야하는데 현재 그 순서가 완전히 반대로 되어있었다는 것이다. 이렇게 포트폴리오가 긴데 가장 잘 한게 마지막에 있다면 가장 못한 프로젝트를 좀 읽다가 서류에서 떨어뜨려버릴 수도 있다.

 

그렇기에 시기를 따지지 말고 일단 가장 잘한거부터 그 다음으로 잘한 순으로 프로젝트 소개를 해야한다.

 

프로젝트의 유형

 필자는 필자가 굉장히 잘 만들었다고 생각한 프로젝트를 4개 넣었다. 하지만 그 중 2개는 지원하는 분야와는 전혀 다른 프로젝트였다. 모바일 앱 개발자로 지원을 했으나, 2개는 C언어로 게임 엔진부터 만든 게임 프로젝트였다. 열심히 했고, 꽤나 정성을 쏟아 만든 프로젝트였으며 말할 것도 많았기에 이 프로젝트를 빼는게 오히려 손해라고 생각했다.

 

 하지만 분야를 맞추는 것은 굉장히 중요하다. 실제로 서류 통과 후 면접을 봤던 회사들에서는 내 포트폴리오를 보고 약간 혼동이 온다고 직접적으로 말해주기도 했다. "모바일 개발자로서 일하고 싶은건지, 게임 개발자로서 일하고 싶은건지 그 저의가 궁금하다." 라는 평가를 했다. 당연히 모바일 개발자로 지원을 한 것이기에 열심히 어필을 했으나, 중구난방으로 구성되어있는 프로젝트들에 게임쪽 포트폴리오 구성이 더 좋았던 탓에 나의 어필은 통하지 못했다.

 

그래서 이후에는 게임 관련 프로젝트는 빼고 모바일 프로젝트만 추가해서 지원했다. 그동안에는 서류통과는 계속 했는데, 이번에 프로젝트를 빼서 서류 통과를 못하는게 아닐까 하는 걱정을 했는데 다행히도 그런 일은 딱히 없었다. 오히려 면접 때 한 분야에 대해 집중적으로 이야기할 수 있었다.

 

사용 기술

프로젝트 소개의 마지막에는 사용 기술을 작성했었다. 프론트엔드와 백엔드를 모두 기입했는데, 필자가 백엔드까지 진행한 걸로 은근 많이 착각했다. 과장이 아니라 처음 면접 본 대부분에서 스프링을 할 줄 아냐고 물어봤었다.

 

그래서 아래와 같이 내가 한 것을 명확히 구분했다. ▼

 

"백엔드는 하지도 않았으면서 왜 쓴거? 걍 빼지?"

 

팀 프로젝트로 진행했고, 백엔드 팀에서 사용한 기술에 대해 소통했다는 것을 어필하기 위해 적었다. 팀이 분리되어있다고 해서 둘이 완전 독립적으로 돌아간 게 아니라 어느정도 진행 상황이나 버그, 구현 방식 등등을 공유하기에 적어두는 편이 좋다고 생각했다.

 

길이

프로젝트의 마지막으로는 내용이 너무 길다는 평이었다. 안그래도 프로젝트를 많이 넣었는데, 거기에 내용까지 상세하게 길게 작성하다보니 읽는데 피로감이 생긴다는 것이었다. 그래서 내용을 최대한 압축해서, 읽는 사람이 아예 모른다고 가정하는게 아니라 어느정도는 아는 것을 가정하고 작성하라는 평을 받았다.

 

그 외에는 동어 반복이나, 문장 흐름의 어색함 등등 전체적인 글 작성에 대해 평가를 받고 프로젝트 부분은 첨삭을 끝냈다.

 

 

스킬

다음으로는 스킬 부분에 대한 첨삭을 받았다. 사실 이 부분은 케바케가 강한 부분이라 추가적으로 보면 좋을 거 같다.

 

이것저것 다 넣으려고 하지 말 것

나는 일단 할 수 있는 것들은 다 썼었다. 최소한 거짓말은 안했지만, 정말 사소한 것까지다 작성했다. ▼

 

피그마는 디자인 외주도 진행한 적이 다수 있었고, 그동안의 대부분의 프로젝트는 내가 피그마로 디자인을 했기에 넣었다. 노션의 경우는 프로젝트 노션 구축 뿐만 아니라 플랫폼 구축, 디스코드와 zapier 그리고 api를 통한 고도화까지 진행을 해 본 적이 있었으며, 이를 통해 총 4개의 학교에서 세미나를 진행한 적이 있어 추가를 했었다.

 

하지만 문제는 이런 스킬들은 어디까지나 학생 레벨이다. (신입이라면 말이다.) 내가 얼마나 구축을 잘했건 그건 나의 생각이고 실무에서는 하등 쓸모없는 능력이거나 정말 장난감 수준의 구축일 가능성이 높다.

 

 

"그럼 절대 쓰지마?"

 

 

그렇다고 절대 쓰지 말라고 하는 것은 아니다. 다만 쓸 때는 내가 이걸 어떻게 살릴 수 있을 지가 명확할 때이다. 필자는 앞의 경험들을 살릴 수 있었기에 빼지 않았다. 내가 이걸로 어떤 거 까지 해봤고, 어떤 문제 상황을 해결했는지를 서술할 자신이 있었다. 그리고 그 내용을 일부 포트폴리오에 담기도 했다.

 

하지만 이렇게 살릴 수 없는 상황이라면 이런 자잘한 것들까지 쓰는게 좋게 보이지 않을 수 있으니 빼는것을 권장한다.

물론 이건 회사마다 모두 다르다. 하지만 다른 회사의 인사팀으로 일하는 분들에게 실제로 들은 이야기로 이렇게 작성하는 지원자를 그다지 좋게 보지 않는다고 했다. 그러니 회사의 분위기를 보고 포트폴리오도 조정해서 작성하면 좋다.

 

 

마치며

---

글 내용을 읽어보면 포트폴리오 부분은 생각보다 첨삭을 많이 안한 거 같은데, 위의 내용대로만 수정해도 거의 절반이 날아가고 구성이 싹 바뀐다. 필자의 포트폴리오는 대략 50페이지에 가까웠는데 첨삭을 받고 수정을 하고 나서 20페이지대로 줄었다.

 

20페이지도 많다고는 하지만 그만큼 자세하게 설명하고 싶은 것을 어필했고, 그 어필이 잘 통했다. 사실 필자가 엄청나게 좋은 회사에 다니냐, 그것은 아니지만 포트폴리오 및 서류는 웬만하면 거의 다 통과했기에 한 번 작성해보았다.

 

더 잘 작성하고 더 좋은데 간 사람들도 많을 것이기에 필자의 글은 그저 참고용으로만 보는걸 권장한다. 아마 말 하지 않아도 다들 그렇게 할 거 같지만 ^^... 다들 취준 화이팅이다...!!!