인텔 특강: 경험 만들기 전략 특강

3월 6일에는 지난번에도 오셨던 유니티 출신 강사님의 경험 만들기 전략 특강을 들었다. 제목만 보면 포트폴리오를 예쁘게 정리하는 방법이나 자기소개서 팁 같은 내용일 것 같았는데, 실제 강의는 훨씬 더 실전적이었다. 핵심은 단순했다. 인턴 경험이 없다고 해서 준비할 수 없는 게 아니라, 인턴이 아니어도 실무처럼 보이게 만들 수 있는 경험을 직접 설계해야 한다는 이야기였다.

이번 강의는 크게 두 축으로 나뉘었다. 앞쪽은 무엇을 준비해야 하는가였고, 뒤쪽은 그걸 어떻게 보여줄 것인가였다. 내용도 What to Prepare?와 How to Prepare?로 자연스럽게 갈렸다. 직무를 먼저 정하고, 그 직무에 필요한 기술과 경험이 무엇인지 채용 공고와 현직자 경로를 통해 파악한 뒤, 실제로는 캐글, 토이 프로젝트, 오픈소스, 교육 과제를 활용해 경험을 만들고, 마지막에는 링크드인·깃허브·Velog로 그걸 정리하라는 흐름이었다. 막연했던 포트폴리오 준비가 조금 더 손에 잡히는 일처럼 보였다.

먼저 정해야 하는 건 결국 직무였다

강의 초반에 나온 질문은 아주 단순했다. 포트폴리오에 무엇을 채워야 하느냐보다 먼저, 진로와 직무를 정해야 한다는 것이다. 듣고 보면 당연한 말인데, 실제로는 이 순서를 많이 거꾸로 가는 것 같다. 프로젝트를 하나 만들고 나서 나중에 어디에 끼워 넣을지 고민하는 방식으로는 포트폴리오가 자꾸 산만해지기 쉽다.

이번 특강에서는 기업이 이미 답을 주고 있다는 표현이 반복해서 나왔다. 현직자의 링크드인을 보면 어떤 커리어 패스로 그 직무에 갔는지 알 수 있고, 채용 공고를 보면 어떤 기술과 경험이 필요한지가 거의 그대로 적혀 있다는 것이다. 같은 직무라도 공고를 계속 보면 자주 등장하는 도구와 요구 역량이 눈에 들어오고, 그걸 기준으로 준비 방향을 정할 수 있다. 결국 포트폴리오는 내가 하고 싶은 이야기를 쓰는 문서가 아니라, 내가 가고 싶은 직무의 언어로 다시 정리한 결과물이어야 한다는 뜻처럼 들렸다.

인턴이 없다고 해서 경험까지 없는 건 아니었다

중반부터는 본격적으로 인턴 없이 실무 경험 만들기 이야기가 나왔다. 이 파트가 가장 좋았다. 많은 사람들이 신입 준비를 하면서 가장 크게 불안해하는 지점이 인턴 경험인데, 여기서는 기업이 신입에게 진짜로 기대하는 건 화려한 경력 자체가 아니라 경험의 질이라고 짚었다.

특히 인상적이었던 건, 채용 담당자가 궁금해하는 건 “어느 회사에서 일했는가”보다 “어떤 지저분한 데이터를 만져봤고, 어떤 에러를 어떻게 해결했는가”에 가깝다는 말이었다. 이 문장이 이번 강의 전체를 관통하는 핵심처럼 느껴졌다. 타이틀이 약하면 문제 해결 과정으로 승부해야 한다는 말도 같은 맥락이었다. 결국 신입에게 필요한 건 직함이 아니라, 스스로 문제를 발견하고 해결해 본 흔적이라는 얘기였다.

전략 1. 캐글과 데이콘은 순위보다 접근 방식이 중요했다

첫 번째 전략은 캐글과 데이콘이었다. 그런데 여기서도 메달이나 순위 이야기에 머물지 않았다. 오히려 상위 1%가 아니어도 충분히 좋은 포트폴리오가 될 수 있다는 점을 강조했다. 튜토리얼 코드만 그대로 따라 치고 끝내는 것, 혹은 순위가 낮다고 아예 포트폴리오에서 빼 버리는 게 흔한 실수라고 짚은 부분이 기억에 남는다.

대신 중요한 건 나만의 가설과 실험 과정을 남기는 것이었다. 왜 이 데이터를 선택했는지, 왜 특정 피처를 만들었는지, 어떤 모델을 썼다가 성능이 낮았고 무엇을 바꾸니 왜 성능이 올라갔는지 같은 과정이 더 중요하다는 설명이었다. 특히 Failure Log를 기록하라는 말이 좋았다. 실무에서도 처음부터 잘 되는 경우보다, 문제를 발견하고 원인을 추적해 개선하는 과정이 더 많기 때문이다. 결국 대회 경험을 포트폴리오로 바꾸는 핵심은 결과 자랑보다 사고 과정을 어떻게 남겼는가에 있었다.

전략 2. 토이 프로젝트는 ‘작은 실무’처럼 만들어야 했다

두 번째 전략은 토이 프로젝트였는데, 여기서는 뻔한 영화 리뷰 감성 분석은 그만이라는 식의 메시지가 꽤 강하게 들어왔다. 이미 정제된 CSV를 내려받고, 익숙한 예제를 돌리고, 모델 성능만 적당히 적어 두는 방식으로는 차별화가 어렵다는 뜻이었다.

강의에서 말한 좋은 방향은 생활 속 문제나 관심사에서 출발해 작은 실무처럼 만드는 것이었다. 예를 들어 학교 커뮤니티 글을 크롤링하거나, 실제 리뷰 데이터를 수집하거나, 전처리부터 모델링, API 배포까지 끝까지 이어 가는 식이다. 특히 모델링에서 끝내지 말고 Streamlit, Gradio, FastAPI 같은 걸로 간단한 배포까지 붙이라는 조언이 현실적이었다. 이미 정제된 csv 다운로드는 그만, 생활 속 불편함이나 관심사에서 출발, 모델링에서 끝내지 말고 API 배포까지라는 흐름도 아주 분명했다. 현업에서는 결국 결과물이 실제로 작동하는지가 중요하니, 작은 프로젝트라도 end-to-end 경험으로 만드는 편이 훨씬 설득력이 있다는 뜻이었다.

이 부분을 들으면서 나도 프로젝트를 할 때 자꾸 모델 결과나 기능 구현 일부만 보여 주려 했던 건 아닌가 싶었다. 강의는 분명히 “작더라도 처음부터 끝까지 만든 것”의 가치를 더 높게 보고 있었다.

전략 3. 오픈소스는 거대한 실무 시뮬레이터였다

세 번째 전략은 오픈소스 기여였다. 보통 오픈소스라고 하면 텐서플로우 핵심 코드처럼 너무 큰 프로젝트를 떠올려서 지레 겁먹기 쉬운데, 여기서는 그런 부담을 먼저 걷어냈다. "제가 텐서플로우 핵심 코드를 고치라고요? 아닙니다!"라는 식으로 시작해서 good first issue부터 시작하고, 오타 수정이나 문서 보완, 예제 코드 추가처럼 작은 기여도 충분히 의미 있다는 얘기를 붙였다.

이 파트에서 특히 좋았던 건 오픈소스를 단순히 ‘대단한 사람들만 하는 것’으로 보지 않고, 코드 리뷰 문화와 PR 흐름을 경험하는 공간으로 본 점이다. 결국 오픈소스는 코드를 조금 고쳤다는 사실보다, 전 세계 개발자들과 같은 규칙 안에서 이슈를 보고, 수정하고, 요청하고, 피드백을 반영하는 협업 감각을 보여 주는 장치에 더 가까웠다. 거대한 실무 시뮬레이터라는 표현도 과장이 아니라는 생각이 들었다.

전략 4. 지금 듣고 있는 교육도 결국 재가공해야 자기 것이 된다

네 번째 전략은 지금 받고 있는 AI 교육을 내 것으로 포장하는 방법이었다. 이 파트는 특히 직접적이었다. 국비지원이나 부트캠프 수료증 자체는 스펙이 아니고, 그 안에서 무엇을 만들었는지가 중요하다는 메시지가 분명했다.

수업 과제를 그대로 두지 말고, 베이스라인 코드에 자기 아이디어를 얹어 다시 개발해 보라는 조언도 나왔다. 새로운 모델을 적용하거나, 하이퍼파라미터를 조정하거나, 구조를 개선하거나, 설명을 정리하는 식으로 한 번 더 자기 손을 거쳐야 비로소 경험이 된다는 것이다. 그리고 완성된 프로젝트는 반드시 GitHub 구조와 README를 정리해서 다른 사람이 흐름을 바로 이해할 수 있게 만들어야 한다고 했다. 과제 재활용과 GitHub 정리를 따로 강조한 이유도 분명했다. 그냥 수업에서 했다는 사실보다, 그걸 어떻게 다시 해석하고 확장했는지가 더 중요하다는 말이었다.

결국 보여 주는 방식도 전략이어야 했다

강의 후반은 포트폴리오 정리 전략에 집중됐다. 여기서 가장 먼저 나온 문장은 별도의 포트폴리오 파일 만들기였고, 그 다음은 최대한 간결하게 설명해서 상대가 궁금해서 링크를 눌러 보게 만들라는 조언이었다. 다 보여 주려고 길게 쓰는 것이 아니라, 핵심만 보여 주고 더 깊은 내용은 링크드인, 깃허브, Velog 같은 실제 활동 공간으로 연결하라는 뜻이기 때문이다. 최대한 간결하게 설명, 궁금해서 링크를 들어가보게 만들기라는 말도 방향을 잘 보여 줬다.

그리고 가장 강하게 나온 메시지 중 하나가 No Notion이었다. 하나의 링크로 나의 모든 것을 담아내는 최신 포트폴리오 전략으로 링크드인, 깃허브, Velog를 중심에 두라는 설명이 이어졌는데, 특히 AI/ML 직무에서도 풀스택 감각이 중요해지는 상황에서 Notion보다 실제 개발 흔적이 남는 공간을 쓰는 편이 낫다는 쪽이었다. Notion 링크가 중심이 되면 오히려 개발 결과물보다 정리 문서가 앞에 서 보일 수 있고, 실제 구현 역량을 보여 주는 공간은 GitHub와 블로그 쪽이라는 뜻이었다. 다소 단호한 말이긴 했지만, 왜 그렇게 말하는지는 납득이 갔다. 결국 평가자는 보기 좋은 소개서보다 실제 작업 흔적과 지속적인 활동을 더 신뢰한다는 얘기였다.

링크드인, 깃허브, Velog는 각각 역할이 달랐다

링크드인은 개인 브랜딩과 네트워킹의 공간으로 잡았다. 프로필을 100% 채우고, 맞춤 URL을 설정하고, 요약란에 관심 분야와 프로젝트 경험을 분명하게 적고, GitHub와 Velog를 연결하고, 관련 포스트를 꾸준히 올리는 식으로 자신이 어떤 방향의 사람인지 한눈에 보이게 만들어야 한다는 내용이었다. 여기에 추천서 요청, Open to Work 설정, 학교 동문과 프로젝트 동료부터 연결해 인맥을 넓히라는 항목까지 붙었다. 단순한 이력서 복붙 공간이 아니라, 나의 방향성을 외부에서 가장 먼저 읽는 창구라는 뜻이었다.

깃허브는 프로젝트 구조와 협업 흔적을 보여 주는 공간이었다. 폴더 구조, README, 커밋 메시지 규칙, PR 흐름, 이슈 관리, 데모 영상과 이미지, 문서화 같은 요소들이 왜 중요한지 하나씩 짚어 준 부분이 좋았다. feat, fix, refactor 같은 커밋 메시지 규칙까지 구체적으로 언급했고, PR과 이슈 트래킹을 실무 협업 능력의 증거로 봤다. 코드를 올리는 장소가 아니라, 내가 어떤 방식으로 개발하고 협업하는 사람인지 보여 주는 공간이라는 정리가 가장 와 닿았다.

Velog는 학습 로그와 문제 해결 기록을 남기는 공간으로 잡았다. 매일 혹은 매주 공부한 내용, 에러 해결 과정, 프로젝트 인사이트, 성능 개선 과정, 시각 자료 등을 정리하면 그것 자체가 지식 자산이 된다는 이야기였다. 프로젝트별 카테고리 분리, 코드 스니펫 활용, 태그 최적화, LinkedIn과 GitHub 연동까지 꽤 세세하게 안내했다. 특히 짧더라도 꾸준히 쓰는 활동성이 중요하다는 점이 반복됐다. 결국 세 공간은 중복이 아니라 역할 분담에 가까웠다. 링크드인은 나를 소개하고, 깃허브는 결과물을 보여 주고, Velog는 생각과 과정을 남기는 식이다.

들으면서 남긴 내 생각

이번 3월 6일 특강은 포트폴리오를 어떻게 꾸밀지보다, 경험을 어떻게 설계하고 다시 해석할지를 알려 준 시간이었다. 특히 인턴이 없어도 실무형 경험은 만들 수 있다는 메시지가 가장 크게 남았다. 캐글도, 토이 프로젝트도, 오픈소스도, 지금 듣고 있는 교육 과제도 전부 재료가 될 수 있는데, 중요한 건 그걸 얼마나 집요하게 다뤘는지와 얼마나 명확하게 정리했는지라는 점이 분명했다.

또 하나 좋았던 건, 포트폴리오를 문서 하나로 끝내지 않고 활동의 흐름 전체로 보게 만들었다는 점이다. 결국 좋은 포트폴리오는 정리된 PDF 한 장이 아니라, 링크드인에서 방향성이 보이고, 깃허브에서 작업 흔적이 보이고, Velog에서 사고 과정이 보이는 상태에 더 가까웠다. 이 강의는 “무엇을 했는가”보다 “그걸 어떻게 남기고 연결했는가”가 더 중요하다고 계속 말하고 있었다.

앞선 3월 3일부터 5일까지의 특강들이 UI/UX와 사용자 경험을 보는 기준을 넓혀 줬다면, 이번 3월 6일 특강은 그 경험을 내 커리어 경험으로 어떻게 바꿔야 하는지를 보여 준 시간이었다. 지금 하고 있는 작은 프로젝트들도 그냥 과제로 끝내지 말고, 실제 경험처럼 다시 다듬어야겠다는 생각이 강하게 남았다.