일본 IT 취업, GitHub와 포트폴리오가 도움이 될까요?

핵심 질문

일본 IT·엔지니어 취업에서도 GitHub나 포트폴리오를 준비해야 할까요? 무엇을 넣어야 평가자가 보기 쉬울까요?

직접 답

도움이 됩니다. 다만 모든 회사의 공통 필수 서류는 아닙니다. 회사와 직무에 따라 코딩 과제, 기술면접, 연구소개, 포트폴리오 제출 등 평가 방식이 다르므로 채용 페이지를 먼저 확인하세요.

포트폴리오의 핵심은 작품 수가 아닙니다. 다음 여섯 가지가 보여야 합니다.

1. 어떤 문제를 해결하려 했는가
2. 본인이 무엇을 맡았는가
3. 왜 그 기술과 방법을 선택했는가
4. 어떤 실패와 제약이 있었는가
5. 결과를 어떻게 검증했는가
6. 목표 직무와 어떻게 연결되는가

1. 프로젝트는 이 구조로 설명합니다

프로젝트마다 다음 항목을 한 페이지 안에서 찾을 수 있게 하세요.

• 한 줄 요약: 누구의 어떤 문제를 어떤 방식으로 해결했는지
• 배경과 목표: 왜 필요한 프로젝트였는지
• 담당 범위: 팀 전체 결과와 내 기여를 분리
• 기술 선택: 사용 기술과 선택 이유
• 문제 해결: 오류나 실패의 원인, 시도, 수정
• 결과와 검증: 비교 기준, 테스트, 수치, 피드백
• 회고: 다시 한다면 바꿀 점과 직무 연결

예를 들면 “Python으로 분석했다”보다 다음이 낫습니다.

데이터가 적고 결과 설명이 필요했기 때문에 특징 기반 모델을 기준으로 선택했습니다. 이후 시계열 순서의 효과를 확인하기 위해 LSTM과 성능·학습시간을 비교했습니다.

2. GitHub는 대표 저장소 2~3개부터 정리합니다

저장소가 많을 필요는 없습니다. 평가자가 길을 잃지 않게 만드는 것이 우선입니다.

README에는 최소한 다음을 넣으세요.

• 프로젝트 한 줄 요약
• 문제와 목표
• 본인의 역할
• 시스템 구성 또는 실험 흐름
• 설치·실행·재현 방법
• 테스트와 결과
• 한계와 다음 개선
• 라이선스와 데이터 사용 범위

저장소 이름도 project-final-v2보다 wafer-defect-classification, lab-equipment-monitor처럼 내용을 알 수 있게 짓는 편이 좋습니다.

3. 연구·수업 프로젝트도 사용할 수 있습니다

상용 서비스가 없어도 괜찮습니다. 다음 경험을 재료로 쓸 수 있습니다.

• 학부·대학원 연구
• 캡스톤 디자인
• 데이터 분석·기계학습 실험
• 임베디드·로봇·회로 프로젝트
• 연구실 자동화 도구
• 팀 수업 과제와 해커톤

연구는 논문 초록처럼 설명하지 말고 연구 질문 → 본인 역할 → 실험·분석 방법 → 실패와 수정 → 검증 결과 → 직무 연결 순서로 바꿉니다.

수업 과제라면 기본 요구사항을 수행한 부분과 스스로 확장한 부분을 구분하세요. 팀 프로젝트라면 전체 성과와 자신이 담당한 코드·결정을 분명히 나눕니다.

4. 공개하면 안 되는 것을 먼저 걸러냅니다

다음 내용은 올리지 않습니다.

• 비밀번호, 토큰, API 키, 인증서
• 실제 고객·실험 참가자의 개인정보
• 회사나 연구실의 비공개 코드와 문서
• 미발표 연구 데이터와 특허 가능성이 있는 아이디어
• 내부 서버 주소와 운영 로그
• 공개 동의를 받지 않은 팀원의 결과물
• 재배포 권한이 없는 데이터와 코드

비밀값은 현재 파일에서 삭제해도 과거 Git 이력에 남을 수 있습니다. 이미 노출했다면 해당 키를 먼저 폐기하거나 교체하고, 필요할 때 이력 정리를 검토해야 합니다.

공개할 수 없는 프로젝트는 실제 자료를 억지로 올리지 마세요. 문제와 역할을 일반화하거나, 모형 데이터로 핵심 로직을 다시 만들거나, 코드 없이 구조와 검증 방법을 설명할 수 있습니다. 공개 권한이 불확실하면 공개하지 않는 편이 안전합니다.

5. 제출 전 체크리스트

• 목표 회사가 포트폴리오나 GitHub를 요구하는지 확인했습니다.
• 대표 프로젝트 2~3개를 직무 관련성 순으로 배치했습니다.
• 프로젝트마다 문제, 역할, 선택 이유, 결과가 있습니다.
• 팀 성과와 개인 기여를 구분했습니다.
• README만 읽어도 실행·검증 방법을 알 수 있습니다.
• API 키와 개인정보가 현재 파일과 Git 이력에 없습니다.
• 연구실·회사·팀 자료의 공개 권한을 확인했습니다.
• 일본어로 1분·3분 설명을 준비했습니다.

짧은 결론

좋은 엔지니어 포트폴리오는 작품 모음집이 아니라 문제 해결 기록입니다. GitHub는 코드 증거를 보여주고, 포트폴리오는 그 코드에서 무엇을 봐야 하는지 안내합니다.

새 프로젝트부터 만들기 전에 지금까지 한 연구·수업·개인 프로젝트 5개를 적으세요. 그리고 각 항목에 직무 관련성·내 기여·공개 가능성을 표시한 뒤, 점수가 높은 2~3개부터 정리하면 됩니다.