프로젝트 등 내 능력에 대한 소개에 대한 부분
1. 프로젝트에서 “내가 한 것”에 대한 소개 부분
개발에 어떤것을 해보았는가에 대한것?
뭔가 많이 한 것?을 단순 나열하는것? 별로다.
예로
스프링 프레임워크를 사용했고, 스프링 시큐리티로 로그인을 구현했다?
→ 말이 길어진다.. 그런데, 별로 특별하지 않다.
문제 해결 위주로 넣어보고 개선하고자 한 것에 대한 정리를 우선적으로 해야한다.
“저는 스프링 시큐리티로 JWT토큰을 구현했으며, JWT 토큰의 보안적인 문제를 해결하기 위해, 리프레시 토큰에 대한 생성 주기를 다양하게 벤치마크 해보았고, JWT토큰이 탈취되더라도 신원 보증을 충분히 받을 수 있도록 보안을 구축해보았다.”
→ 처럼 뭔가 고민을 했고, 그 문제를 해결하기 위해서 어떤 것을 도입해본 것을 담게 된다.
→ 하지만 이건 길다.
하지만, 이력서는 위 내용을 짧게 포인트로 담아 낼 필요가 있다.
위 부분은 짧게 잘 작성한 예시들을 잘 찾아보고, 두괄식 요약을 잘해보자.
2. 내가 가진 기술 스택에 대한 부분
기술 스택에 대해 표현 할 때, 어떤것을 표현해야 할까?
그냥 단순히 다뤄본 것을 모두 집어넣어두는데, 이는 오히려 신뢰도가 부족하다. 부족하더라도 내가 핵심적으로 다룬것을 담아두는것이 좋지 않을까?
•
내가 자신있게 다룰 수 있는것! 찍먹한 것은 쓰지말자. 오히려 신뢰도가 낮아지고 이력서 앞장만 보고 넘어갈 확률이 더 높다.
•
오히려 모르는것은 그걸 면접에서 물어 볼 수 있기 때문에, 약점이 될 수 있다.
•
내가 면접에서 잘 이야기 할 수 있을만한 자신있는것을 올려두자! 애매한것 X
3. 어떤 기능을 구현했는가에 대한 부분
어떤 기능을 개발했는지 API 부분 나열하는것? 별로다.
•
상품 재고 및 가게 관리 API개발
◦
논리적 연관관계를 사용해 보다 불필요한 FK 참조 제거
위 처럼, 어떤 문제를 경험 또는 고민했고, 개선을 위해 어떤것을 해보았는지
왜, 무엇을 포함시키자
4. 적절한 포장을 잘하자
안한것을 완전히 거짓말을 하라는것은 아니지만, 강조 할 줄도 알아야 한다?
예로 어떤 서비스를 조금 해봤지만, 3~25명의 트래픽이 있었던 서비스를 경험해봤다고 해도, 그냥 자신있게 10명의 트래픽 또는 말로라도 수십명 정도의 트래픽이 있었다고 잘 말하고, 표현하는 것을 해보자. 어짜피 낮은 트래픽은 동일하다 하지만 궂이 약점처럼 생각 할 필요가 없다는 것이다.
그렇다고 거짓을 하면 안된다. 서비스를 해보지 않았는데, 수십 수백명이 접속해본 경험으로 거짓 포장을하면 결국 그것에 대한 변명과 변명으로 거짓인것은 신뢰도를 낮추게 된다. 자신을 적당히 잘 포장 할 줄도 알아야 한다.
5. 전체적인 이력서 포맷 생각해보기
Inyong Kim, Backend Developer
updatedAt 20xx.xx.xx
안녕하세요, 김인용(citefred)입니다.이용자의 needs 뿐 아니라 wants를 분석하길 좋아합니다.
성장을 위한 도전을 두려워하지 않습니다.
더 나은 프로덕트를 위해 아키텍쳐와 구조를 고민합니다.
Deep Dive하는 개발자입니다.
적극적으로 학습합니다.
(* 이 부분은 기업의 추구 방향에 따라 유동적으로 작성 할 수 있도록 생각해두자. 첫 인삿말이기 때문에, 그 만큼 기업에서 추구하는 인재상에 맞는지 생각해보고 나도 그 가치관이 맞는지 강조 할 수 있는 부분이다!)
(* 위 부분을 아래 내용에서 증명되는 것이 올바르다.)
(* 가치관 등 공통적인 것은 2~3개 정도 고정 할 수 있도록 나를 객관적으로 파악하고, 유동적으로 작성 할 부분은 강조하고자 하는 부분을 변경되도록 기업의 가치 등을 잘 파악하자.)
Github
Blog
Contact : citefred@yzpocket.com Experience / Project
(*신입이라프로젝트*이전 비관련경력, 접점이 부족하면 최소화)
CafeService (*프로젝트명 추후엔 실전 프로젝트로!)
period 23.09 ~ 23.10
position Backend Developer
skills Spring Boot
Description (*프로젝트에 대한 간략한 소개 + 내역할)카페 테마의 배달 웹 서비스 개발(미니 프로젝트)
•
사업자 회원은 커피와 디저트 위주의 사업 회원은 카페와 메뉴를 등록
•
일반 회원들은 카페의 소개 및 메뉴를 키워드를 통해 찾아보거나 카페를 선택하여 주문 진행
What I Did (*내가 수행한 역할)•
팀원이지만 팀장같이 노력하는 실제 리더 역할
과제 수행 문서화 전반
프로젝트 전반 프론트엔드 문제 해결 담당
Github 원격 저장소 관리
•
프로젝트 기능 구현에서의 분담한 역할에 대한 부분
◦
키워드 검색 및 사용자 리뷰 CRUD 기능 구현
▪
동작 검증 및 신뢰도 확보를 위한 단위 테스트 코드 작성
•
프로젝트 완료, 보고에 대한 부분
발표 담당
시연 영상 제작 담당
프로젝트 배포 담당
(*수치적으로 접근한것들이 있으면 좋다. 작성하면서 느끼는데, 뭔가 개선을 위한 노력들이 더 필요하고 그것들을 정리할 필요가있다..)
(*기본 포맷 : 내가, 무엇을, 왜, 가능하면 수치적 데이터)
•
(*서브 포맷 : 내가 관련해서 작성 블로그 글, 깃헙 코드 링크)
궁금한것은 실제로 저런 부족한 커뮤니케이션 및 진행을 개선하고자 내가 주도한 것도 이런것에 해당되는 것인지, 수치적으로 나타낼 수 없는 부분이기도하고 이런건 강조되도 되는건지, 모르겠다.
그리고 왜라는 부분이 작성되면 다른 팀원의 진행이 수동적이라서 바라보기만 하면 진행이 안되는 상황이고, 내가 적극적으로 능동적으로 이끌엇던것이 사실이면 이런 부분들은 어떻게 담아야 하는가?
윗 부분, 너무 많고, 길긴하다. 포트폴리오로 별도 페이지로 첨부하는 것이 좋을 것 같다. 그럼 효과적으로 앞부분만 작성 할 수 있는 피드백이 필요할것 같다.
Additionals
활동
각종 활동에 대해서, 간략히 나타내보자. …
6. 위 포맷에 대해서 다시 정리
인트로 굵직하게
프로젝트 부분의 스킬셋 명확하게
내가 실제 수행한 역할에 대해서 쓰는게 생각보다 어려울 것 같다
내가, 무엇을 왜로, 정리해보자. 그러러면 프로젝트에서도 이 부분들을 생각하면서 진행해야 한다.
수치적 데이터, 있으면 좋다. 아래 예시처럼 쓸만한게 많아져야 할 것 같다.
다음부터 프로젝트에서 이런 부분을 정리 할 수 있도록, 개선 부분에 대해서 신경쓰면서 개발 하면 이렇게 쓸만한 부분을 많이 만들 수 있는 프로젝트를 할 수 있을 것 같다.
기능 구현 → 블로그에서 트러블 슈팅이나 구현에 대한것 → 회고록 으로 연결되는것이 좋다.
단순히 기능 구현이 아니라 개발자로써 진심으로 개선에 대한 것을 생각하는지.