잘 못써도 합격하는 개발자 이력서

https://www.youtube.com/watch?v=FOzAGjqiTc0 

---

1. XX록 님

조회 성능이 8초짜리가 0.2초 되거나, 6.6초가 0.2초가 된거는 진짜 엄청난 개선입니다. 근데, 어떻게 개선한 건지를 블로그랑 다 보고 있는데 내용이 없다. 이게 사실 엄청 자랑해야 할 부분인데 없다. 무슨 느낌이냐면, 예고편은 되게 재미있었는데, 본편은 안 나오는 것 같다. 보통 이런 경우에는 Index가 잘못 걸려있던 거를 어떻게 개선했다던가, 아니면 Index를 개선하기 위해서 중간에 그 쿼리를 어떤 형태로 바꿨다던가, 커버링 Index를 바꿨다던가 수많은 이야기를 하며 기술적 이야기를 녹여낼 수 있는데, 그 내용이 없어서 아쉽다.

 

자기가 한 걸 다 쓰려고 하신 건 알겠는데, 그 항목들만 쓴 거지 기술적인 이야기가 하나도 없어서 아쉽다. 예를 들어 Batch를 구현하기 위해서 나는 AWS 람다와 클라우드워치에 있는 이벤트 브릿지를 조합을 해서 짰다라던가, 혹은 서버리스로 짰다던가, 혹은 젠킨스에 스프링배치를 썼다던가, 혹은 성능을 위해서 뭘 했다던가 그런 게 보통은 다 있다. 근데 Batch를 구현하기 위해 어떤 걸 했는지, 혹은 기술스택이 비슷해서 기술스택을 나눠서 넣을 필요가 없었다라고 하면 다 빼고, 본인이 이야기 할 수 있는 것들 위주로 좀 써주셨으면 좋았겠다. 운영개선TF 경험을 저는 좋아하는데, 운영개선TF 할 때도 기술적인 내용이 분명히 있었을 거라고 보거든요. 빠르게 MVP를 하기 위해서 무엇을 했다던가, 혹은 결제 MVP를 하기 위해서 토스 PG나 뭐랑 연동을 했다던가 그런 것들을 쓰실 수 있는데... 기술적으로 뭘 고민했었고, 그런 걸 녹여냈고 등 이런 내용이 있으면 좋을 것 같다.

 

단순히 많은 것들을 한 걸로 따지면 SI 개발자를 이기지 못할 뿐더러, 5명 있는 스타트업팀 못 이긴다. 그래서 XX님에게 지금 필요한 것은 단순히 경험만 나열하는 것이 아니라, 나는 어떤 기술을 하더라도 기술적으로 어떤 고민을 했다던가, 혹은 그때 시간을 위해서 기술적으로 포기를 했다던가 이런 과정을 적었으면 좋았을 것 같다. GitHub이나 블로그가 필수는 아닌데, 면접관들이 GitHub이나 블로그를 안 봐도 되게 하려면 기술적으로 좀 흥미가 있을 만한 내용들이 포함되어 있어야 한다. XX님의 GitHub 레파지토리를 봤을 때는 그것만 연습하기 위한 작은 애플리케이션 코드들이 너무 많다. XX님의 실무 능력을 보여줄 수 있는 진득한 프로젝트가 있었으면 좋겠다. 실무 경험이 이력서에는 잘 드러나지 않는다. 작은 애플리케이션들은 안전한 환경이라, '오류 / 예상치 못한 버그 / 실무에서 만나는 성능' 이런 경험들을 만나기 힘든 상황이다. 그래서 이 사람이 실무에서 예상치 못했던 문제들을 만났을 때 어떤 역량을 갖고있는 사람인가 모르겠다.

 

유망주는 이미 끝났기 때문에 빨리 프로로서 자세 전환하시는 게 중요하다고 생각합니다.

 

점수: 4점, 2점

---

나의 정리 : 

- 무엇을 하든, 기술적으로 무엇을 고민했고, 어떻게 풀어냈는지 그런 내용을 이력서에 작성하는 것이 매력있다.

- 오류 / 버그 / 성능 등의 경험들을 할 수 있는 실무 능력을 보여줄 수 있는 프로젝트가 있으면 좋다. 이것을 통해 실무 역량을 어필할 수 있다.

- 성능 개선의 경우, "이전의 문제 - 해결 방법 - 결과"를 정리해서 드러내면 좋다.

- 단순히 내가 한 것들만 나열하지 말자!!

---

2. XX정 님

요즘 백엔드 개발자분들이 많이 쓰시는 것 - DDD, 헥사고날, 쿠버네티스 이런 이력서 많이 받아보거든요? 근데 JOIN을 잘 못 사용하시거나, 전부 서브쿼리로만 푼다던가 그런거는 아쉽습니다. "JOIN이나 SQL 가지고 어떻게 성능 개선했습니다." 이런 사례 되게 좋아합니다. 왜냐하면 NoSQL을 써서 해결했다거나, 엘라스틱 서치같은 검색에서 해결했다거나 이거는 기술을 바꿀 수 있을 때 하는 거고, 바꿀 수 없을 때 최선을 다한게 쿼리 개선이니까 이런 걸 좋아합니다.

 

프로젝트에서 좋게 봤던 것은 "난이도가 높은 비즈니스 로직이겠다. 어떻게 풀었을까?" 궁금했는데, GitHub 링크를 첨부해주셨으면 볼 수 있는 게 많았을 것 같습니다. 백엔드 분들에게 가장 보고 싶은 것은 복잡한 비즈니스 로직을 어떻게 잘 풀어냈냐에요. 그리고 그 복잡한 비즈니스 로직이 정확하게 작동했다는 것을 검증하기 위해서 단위 테스트를 짰던, 아니면 셀레니움 같은 걸 짰던 뭐가 됐던 간에 어떻게 그것을 계속 검증했느냐. 그리고 DB 테이블이 필요했다고 하면, ERD나 모델링이나 혹은 객체 관계나 이런 것들 어떻게 설계했느냐. 이런 이야기 하려면 비즈니스 로직이 복잡해지면 볼 수 있는데, 이런 주제가 되게 좋아요. 이 과제가 AWS를 사용하지 않았어도 사실 되게 좋아하는 과제다. 가능하면 복잡한 비즈니스 로직을 어떻게 설계하고, 어떻게 코드를 풀어내고, 어떻게 검증했고 이런 점들이 있으면 좋을 것 같습니다.

 

점수: 6점, 6점

 

호돌맨 : 본인이 한 것에 대해서 좀 더 잘 설명할 수 있는 기술이 있으면 좋을 것 같습니다.

향로님 : 저는 노션에 있는 것까지 다 봐서 6점 드립니다. 근데, 노션에 있는 내용들 중에서도, 필요한 것만 잘 뽑아서 이력서에 썼으면 더 점수가 높았을 것 같습니다.

---

나의 정리 : 

- SQL의 쿼리 개선을 어떻게 했느냐?

- 복잡한 비즈니스 로직을 어떻게 설계하고, 어떤 코드로 잘 풀어내고, 어떻게 검증했냐?

-  DB에서 ERD나 모델링이나 객체 관계를 어떻게 설계했느냐?

이런 점들을 좋게 본다.

 

---

3. XX기 님

YY학원 성적관리 웹사이트 1인 프로젝트로 진행을 하셨습니다. 저는 이거 봤을 때 1인 프로젝트로 제대로 각 잡고 하신 게 있는 것 같아서 긍정적으로 봅니다. 필요에 의해서 정말 불편한 부분이 있기 때문에 그 부분에 대해서 연구를 하고, 프로젝트를 진행하신 부분이 찐개발자의 면모라 정말 좋습니다.

 

저는 쪼금 아쉬웠던 게 몰입 경험이 아쉬웠습니다. 어떤 시험을 통과하기 위해서 혹은 내가 원하는 그룹이나 집단에 가기 위해서 했던 몰입 경험이 있을 수 있는데, 사실은 이게 진짜 몰입이었을까 싶긴 해요. 어려우니까 몰입이라고 느낀 걸 수도 있겠다는 생각을 좀 했어요. 어떤 자격증을 따기 위해서, 어떤 회사에 취업을 하기 위해서 등... 그런 경험이 본인의 가장 몰입이 높은 경험치는 아니었으면 좋겠어요.

 

지금 다 좋은데, 좀 더 개발적으로도 그렇고, Node.js 언어적으로도 그렇고 학습을 해서 본인의 공부를 좀 더 하셔야 되지 않을까라는 생각이 들긴 합니다. 이게 다 분기점이거든요. 여기서 계속 코드 짜고, 프로젝트 하고, 이거에만 집중하시면.. 그게 좋은 방법이 아닌 상태로 반복을 하다보면 한계가 올 수 있기 때문에, 좀 더 뚫고 갈 수 있는 무언가가 있어야 돼요. 좀 더 깊이가 있어야 된다.

 

아직 취업을 안했을 때 계속 블러핑하세요. 나 진짜 더 대단한 개발자가 될 것 같다라고. 자꾸 그런 뉘앙스를 풍겨주세요 이력서에서

 

점수: 7점, 6점

 

성장, 흡수를 되게 잘 하실 것 같아요. 그래서 점수를 더 드립니다.

프로젝트의 목적이 있는 거고, 그 목적을 달성하기 위해서 코드가 이상하더라도 어떻게든 로직을 풀어내려고 했다는 것에.. 코드 봤더니 테스트 코드를 넣었더라고요 계속. 이것들을 잘 정제만 하신다면, 너무나 좋은 이력서가 될 것 같습니다.

---

나의 정리 : 

- 필요에 의해서 프로젝트를 진행하는 것은 서비스 기업의 특징이다. 이것을 작게 나마 경험해볼 수 있는 것이 좋다.

- 그런 프로젝트를 하면서 혼자서 개발하고 운영까지 하는 점이 ++ 요인이다.

---

정리 합치기  :

무엇을 하든, 기술적으로 무엇을 고민했고, 어떻게 풀어냈는지
그런 내용을 이력서에 작성하는 것이 매력있다.

- 복잡한 비즈니스 로직을 어떻게 설계하고, 어떤 코드로 잘 풀어내고, 어떻게 검증했냐?

- SQL의 쿼리 개선을 어떻게 했느냐?

-  DB에서 ERD나 모델링이나 객체 관계를 어떻게 설계했느냐?

- 성능 개선의 경우, "이전의 문제 - 해결 방법 - 결과"를 정리해서 드러내면 좋다.

(단순히 내가 한 것들만 나열하지 말자!!)

필요에 의해서 프로젝트를 진행하는 것은 서비스 기업의 특징이다.
이것을 작게 나마 경험해볼 수 있는 것이 좋다.

- 그런 프로젝트를 하면서 혼자서 개발하고 운영까지 하는 점이 ++ 요인이다. -> 성장, 흡수를 잘 할 것 같다.

- 오류 / 버그 / 성능 등의 경험들을 할 수 있는 실무 능력을 보여줄 수 있는 프로젝트가 있으면 좋다. 이것을 통해 실무 역량을 어필할 수 있다.