인텔 특강: 선택받는 이력서

4월 22일에는 선택받는 이력서 특강을 들었다. 제목만 보면 자기소개서 문장 다듬기나 포장 기술 같은 이야기를 예상하기 쉬운데, 실제 내용은 훨씬 더 건조하고 실무적이었다. 강사님은 개발자 이력서와 포트폴리오는 결국 기술 문서에 가깝다고 말했다. 감성적인 서사보다, 짧은 시간 안에 기술 깊이와 문제 해결 경험이 읽혀야 한다는 쪽이었다.

특히 인상적이었던 건 채용 담당자가 문서를 오래 읽지 않는다는 전제였다. 포트폴리오를 정성껏 만들었다는 사실보다, 첫 장과 첫 프로젝트 블록에서 무엇을 했고 왜 그렇게 했는지가 바로 보여야 한다는 말이 더 현실적으로 들렸다. 이번 특강은 좋은 이력서를 쓰는 방법이라기보다, 개발자 문서를 어떻게 더 선명하게 만들 것인가에 가까운 강의였다.

먼저 관점을 바꿔야 했다

강의 초반부터 기준이 분명했다. 개발자 채용 문서는 PM이나 기획자 포트폴리오처럼 읽히지 않는다는 점이다. 서비스 아이디어가 얼마나 좋은지, 페르소나 분석을 얼마나 길게 했는지, 화면 설계가 얼마나 예쁜지는 엔지니어 서류의 핵심 평가 포인트가 아니라는 설명이 반복됐다.

대신 실제로 보는 것은 세 가지에 가까웠다. 첫째는 사용 기술의 깊이, 둘째는 시행착오를 어떻게 풀었는지, 셋째는 협업과 코드 품질 감각이다. 같은 React 사용이라도 단순히 써 봤다는 말과 상태 관리 문제를 어떻게 나눠 다뤘는지는 완전히 다른 정보라는 뜻이었다.

이 대목을 들으면서 나도 그동안 포트폴리오를 만들 때 설명의 비중이 자꾸 넓어졌던 건 아닌가 싶었다. 프로젝트 배경과 서비스 설명은 길어지는데, 정작 왜 그 스택을 골랐는지나 어떤 문제가 있었고 어떻게 풀었는지는 한두 줄로 끝내는 경우가 많았다. 이번 특강은 그 비중을 뒤집으라고 했다.

신입 개발자가 자주 하는 실수는 생각보다 비슷했다

중반부터는 흔한 실수를 항목별로 짚어 줬다. 가장 먼저 나온 것은 수업 들음 수준에서 끝나는 교육 이력이다. 몇 개월 과정을 수료했다는 사실만 적으면, 결국 무엇을 배웠고 무엇을 만들었는지가 보이지 않는다. 교육 이력도 핵심 과목, 다뤄 본 기술, 프로젝트 경험으로 다시 써야 한다는 말이 실용적이었다.

다음은 기술 로고 나열이었다. Java, Spring Boot, Redis, Docker처럼 적는 것만으로는 숙련도도, 도입 이유도 읽히지 않는다. 강의에서는 오히려 왜 Redis를 썼는지, 어떤 병목이 있었는지, 적용 후 어떤 수치가 나아졌는지 같은 식으로 써야 한다고 설명했다. 결국 스택 목록보다 중요한 건 선택 이유와 결과였다.

또 하나 기억에 남은 건 포트폴리오를 기획 문서처럼 쓰는 문제였다. 페르소나, 시장 분석, 경쟁사 비교, 와이어프레임은 길게 넣는데 정작 기술 설명은 얇은 경우가 많다는 것이다. 개발자 문서라면 서비스 소개는 짧게 줄이고, 내 역할과 기여 범위, 기술 선택 이유, 트러블슈팅, 결과 데이터를 앞세우는 편이 훨씬 낫다는 말에 동의가 갔다.

강사님은 클론 코딩과 1일 1커밋 식의 보여주기식 기록도 꽤 단호하게 봤다. CRUD 기능을 구현했다는 사실 자체는 이제 차별화가 거의 안 되고, 초록 잔디도 커밋 수보다 커밋의 맥락과 질이 더 중요하다고 했다. 지금 기준에서는 무엇을 만들었는가보다 어떤 난제를 다뤘는가, 협업 흔적이 남아 있는가가 더 강한 정보처럼 느껴졌다.

문서 구조도 기술 중심으로 다시 짜야 했다

후반부에서 가장 바로 적용해 볼 만했던 건 문서 구성 방식이었다. 프로젝트 하나를 설명할 때도 서비스 목적을 한 줄로 정리하고, 내 역할과 팀 규모를 나눠 쓰고, 주요 기술과 선택 이유를 붙이고, 마지막에 시행착오와 해결 과정을 배치하는 식이었다. 읽는 사람이 한 번에 흐름을 잡을 수 있게 만들라는 뜻이었다.

여기서 중요한 포인트는 내가 한 일의 경계를 분명하게 쓰는 것이었다. 팀 프로젝트일수록 이 부분이 더 중요하다. 그냥 프론트엔드 담당이라고 적는 것보다, 어떤 화면과 어떤 상태 관리를 맡았고 어떤 성능 이슈를 해결했는지까지 내려와야 문서가 단단해진다. 프로젝트 설명이 길수록 좋아지는 게 아니라, 책임 범위가 선명할수록 좋아진다는 말로 들렸다.

그리고 면접 방어율을 높이기 위한 메타인지 이야기도 나왔다. 완벽하게 아는 척하는 문서보다, 한계와 기술 부채를 인식하고 있다는 문서가 오히려 더 강하다는 부분이다. 이건 꽤 공감됐다. 실제 프로젝트를 해 보면 늘 미완성 지점이나 절충이 남는데, 그걸 숨기기보다 어떤 제약 때문에 그렇게 판단했는지를 설명하는 편이 더 개발자답게 읽힐 수 있다.

결국 제출물은 JD 맞춤형 PDF여야 했다

강의 막판에는 도구 선택도 정리됐다. 특히 Notion 링크 중심 포트폴리오에 대해 꽤 비판적이었다. 로딩이 느리고, 클릭을 한 번 더 유도해야 하고, 보는 환경에 따라 레이아웃이 쉽게 깨질 수 있어서 바쁜 실무자가 굳이 깊게 들어가지 않는다는 이유였다. 대신 Markdown 기반으로 구조를 먼저 잡고, 최종 제출은 핵심 내용이 한 번에 읽히는 PDF로 정리하라는 방향이 제시됐다.

이 말도 과장 없이 받아들여졌다. 링크는 흥미가 생긴 뒤 실제 코드를 확인하러 가는 용도로 두고, 기술 선택 이유와 트러블슈팅 같은 핵심 정보는 처음 제출하는 문서 안에 이미 들어 있어야 한다는 것이다. 결국 하나의 PDF를 모든 회사에 똑같이 내는 게 아니라, JD를 보고 기술 순서와 강조할 내용을 조금씩 바꾸는 일이 더 중요하다는 뜻이었다.

들으면서 남은 생각

이번 4월 22일 특강은 이력서를 화려하게 꾸미는 법보다, 개발자 문서에서 빼야 할 것과 남겨야 할 것을 정리해 준 시간이었다. 서비스 설명, 기획 배경, 감성적인 협업 이야기는 덜어 내고, 기술 선택 이유, 문제 해결 과정, 수치로 확인한 결과, 협업 흔적을 더 앞에 두라는 메시지가 전체를 관통했다.

특강이 끝난 뒤에는 내 이력서와 포트폴리오도 직접 첨삭을 받았는데, 그 시간이 생각보다 훨씬 도움이 됐다. 여러 피드백이 있었지만 가장 좋았던 건 내용을 전부 두괄식으로 다시 손본 부분이었다. 성과를 먼저 쓰고, 그 성과를 만들기 위해 어떤 방법을 썼는지를 뒤에 두는 방식으로 문장을 전면 수정하니 훨씬 읽기 쉬워졌다.

나도 앞으로 포트폴리오를 손볼 때는 무엇을 만들었다보다 어떤 성과를 냈고, 왜 그렇게 했고, 어디서 막혔고, 어떻게 풀었는가가 먼저 읽히게 바꿔야겠다고 느꼈다. 결국 선택받는 이력서는 잘 포장된 문서가 아니라, 짧게 읽어도 개발자로서의 판단과 깊이가 드러나는 문서에 더 가까웠다.