비개발자 AI 포트폴리오 홈페이지 만들기: GitHub 자동 배포까지

흩어진 경력과 글을 AI로 정리해 반응형 포트폴리오 홈페이지를 만들고 GitHub Pages로 자동 배포하는 실제 제작 순서를 설명합니다.

개인 홈페이지를 만들자고 했을 때 가장 먼저 고른 것은 색도, 폰트도 아니었다. 그동안 쓴 글과 인터뷰, 프로젝트가 이미 많았는데도 처음 보는 사람에게 무엇부터 보여줘야 할지 정하기 어려웠다.

AI는 화면을 빠르게 만들 수 있었지만, 나를 대신해 중요한 경력을 골라주지는 못했다. 결국 사이트 제작에서 가장 오래 고민한 것은 코드가 아니라 순서였다. 누구에게 무엇을 증명할지 정하고, 공개 가능한 근거만 골라 한 페이지 안에서 읽히게 만드는 일이었다.

검증일2026-08-24

추천 대상경력·글·프로젝트를 개인 사이트로 정리하려는 직장인

난이도초급~중급

먼저 결론부터: 홈페이지보다 읽히는 순서가 먼저였다

첫 포트폴리오 사이트는 다섯 구역으로 시작했다.

나는 누구이며 어떤 문제를 해결하는가
어떤 관점으로 일하는가
이를 증명하는 글·프로젝트는 무엇인가
결과를 어떤 기준으로 확인했는가
함께 일하려면 어디로 연락하는가

이 순서를 문서에서 먼저 잡은 뒤 AI에게 반응형 웹페이지 제작을 요청했다. 처음부터 애니메이션과 화려한 화면을 요구하면 그럴듯한 사이트는 빨리 나오지만, 정작 왜 이 사람과 일해야 하는지는 흐려지기 쉬웠다.

자료가 부족한 것이 아니라 너무 흩어져 있었다

이 글은 AI포워크 운영자 허보람과 Codex가 실제 포트폴리오 사이트를 만든 과정에서 출발했다. 흩어져 있던 소개와 브런치 글, 미디어 기록, 프로젝트를 한곳에 모았고, 다른 컴퓨터에서도 고칠 수 있도록 GitHub에 연결했다. 결과물은 마케터 허보람 퍼스널 사이트에서 볼 수 있다.

자료가 부족하지는 않았다. 오히려 글과 인터뷰, 프로젝트, 수치가 여러 곳에 흩어져 있어 처음 온 사람이 길을 잃기 쉬웠다. 그래서 더 넣기보다 덜어내는 쪽을 택했다. 첫 화면에서 정체성과 관점을 말하고, 글과 외부 기록으로 신뢰를 보강한 다음, 대표 프로젝트와 문의로 이어지게 했다.

허보람은 브런치 글 「김선태를 만든 건 퇴사가 아니라 회사였다」에서 회사에서 보낸 시간이 문제 해결의 순서와 감각으로 남는다고 썼다. 포트폴리오 사이트는 없던 경력을 만들어내는 장치가 아니다. 이미 쌓인 경험을 다른 사람이 이해할 수 있는 개인 자산으로 번역하는 장치에 가깝다.

무엇을 보여주고 무엇을 감출지 먼저 정했다

사이트 제작 전에 자료를 네 칸으로 나눕니다.

자료	공개 여부	필요한 처리	이유
이미 공개한 브런치·기고 글	공개	대표 글 선별·원문 링크	소유 관점과 기록 증명
공개 승인된 프로젝트·수상	공개	역할·기간·근거 출처 표시	실행력 증명
고객·회사 내부 문서	비공개	범용 원칙만 익명화	계약·보안 위험
확인되지 않은 성과 수치	보류	출처 또는 공개 승인 확인	과장과 신뢰 하락 방지
개인정보·계정·내부 연락처	비공개	공개용 문의 경로로 대체	스팸·보안 위험

공개 점수는 다음처럼 계산할 수 있습니다.

공개 우선순위 = 독자 관련성(1~5) × 증거 명확성(1~5) - 공개 위험(1~5)

점수가 높아도 계약상 비밀이나 개인정보가 있으면 공개하지 않습니다. 계산식은 후보 정렬용이며 보안 승인을 대신하지 않습니다.

첫 화면 문장을 만드는 3문장 구조

포트폴리오 첫 화면은 자기소개서 전체를 넣는 곳이 아닙니다. 다음 세 문장으로 시작합니다.

역할: 나는 어떤 일을 하는 사람인가
관점: 다른 사람과 무엇을 다르게 보는가
범위: 어떤 문제를 어떤 방식으로 해결하는가

합성 예시를 보면 차이가 분명합니다.

콘텐츠 마케터입니다. 사람들이 클릭한 이유보다 기억한 이유를 먼저 봅니다. 브랜드 메시지를 콘텐츠·채널·성과 분석의 한 흐름으로 연결합니다.

“열정적인 마케터”, “다양한 경험”, “트렌드에 민감”처럼 누구에게나 적용되는 표현은 줄입니다. 관점을 구체적인 맥락과 제약으로 바꾸는 방법은 좋은 업무 프롬프트의 5요소와 연결됩니다.

AI 포트폴리오 홈페이지 제작 8단계

1. 사이트의 독자 한 명을 정합니다

채용 담당자, 잠재 고객, 강연 담당자 중 가장 중요한 한 명을 고릅니다. 모든 사람을 만족시키려 하면 메뉴와 문장이 늘어납니다.

2. 콘텐츠 재고표를 만듭니다

소개, 글, 인터뷰, 프로젝트, 수상, 연락처의 현재 위치와 공개 여부를 한 표에 적습니다. 링크가 끊겼거나 중복된 자료도 표시합니다.

3. 한 페이지 읽기 순서를 설계합니다

첫인상 → 관점 → 글과 미디어 → 대표 프로젝트 → 문의 순으로 배치합니다. 자료가 많아도 대표 항목은 각 구역 3~6개로 제한하고 전체 목록은 별도 링크로 보냅니다.

4. 합성 내용으로 골격을 먼저 만듭니다

실제 고객명과 성과를 넣기 전 가상의 인물·프로젝트로 레이아웃을 확인합니다. 구조가 확정된 뒤 공개 승인된 정보만 교체합니다.

5. AI에게 계획과 파일 구조부터 요청합니다

HTML·CSS·JavaScript 같은 구현 방식보다 필요한 구역, 모바일 동작, 외부 링크, 수정 방법과 테스트 조건을 먼저 확인합니다.

6. 모바일 360px부터 검수합니다

긴 직함, 한글 줄바꿈, 프로젝트 숫자, 외부 링크 버튼이 작은 화면에서 겹치지 않는지 봅니다. 마우스 호버가 없어도 모든 기능을 사용할 수 있어야 합니다.

7. GitHub에 원본과 사용법을 저장합니다

사이트 코드, 이미지, 수정 안내를 저장하되 비밀번호·문의 폼 응답·원본 고객 자료는 넣지 않습니다. 다른 컴퓨터에서도 저장소를 받아 수정할 수 있게 README를 남깁니다.

8. 미리보기 뒤에만 실제 배포합니다

링크, 모바일, 맞춤법, 개인정보와 검색 노출 문구를 확인한 뒤 공개합니다. GitHub 공식 문서는 GitHub Pages와 Actions를 사용해 main 브랜치에 변경이 들어올 때 사이트를 다시 배포하는 워크플로를 안내합니다.

그대로 복사하는 첫 제작 프롬프트

나는 개발자가 아니며 개인 포트폴리오 홈페이지를 만들고 싶습니다.

[핵심 독자]
- 가장 먼저 설득할 사람:
- 그 사람이 30초 안에 알아야 할 내용:
- 원하는 다음 행동:

[공개할 자료]
- 한 줄 소개:
- 나의 업무 관점:
- 대표 글 링크 3~6개:
- 외부 인터뷰·미디어 링크:
- 공개 승인된 프로젝트:
- 문의 방법:

[페이지 순서]
1. 소개
2. 관점과 글
3. 미디어 기록
4. 대표 프로젝트
5. 문의

[제작 조건]
- 모바일 360px부터 반응형으로 만들기
- 키보드만으로 링크와 메뉴 사용 가능하게 만들기
- 원본 자료와 기존 파일을 덮어쓰지 않기
- 실제 고객·개인정보 대신 합성 예제로 먼저 만들기
- 비밀번호와 인증정보를 코드에 넣지 않기
- GitHub 저장소 구조와 비개발자용 수정 방법 남기기
- 공개 배포 전에 미리보기와 검수 결과 보여주기

아직 만들지 말고 빠진 자료, 최소 페이지 구조, 변경할 파일과 테스트 항목부터 제안하세요.

이 프롬프트는 제작을 바로 시작하지 않고 요구사항의 빈칸을 먼저 찾게 합니다. 업무 도구 전반의 제작법은 Codex로 업무 도구 만드는 7단계에서 더 자세히 설명합니다.

예를 들어, 7년 차 콘텐츠 기획자의 사이트라면

합성 인물은 글 42편, 인터뷰 3건, 프로젝트 12개를 가지고 있습니다. 모두 첫 화면에 넣으면 정보가 많지만 무엇을 잘하는지는 흐려집니다.

구역	전체 자료	사이트에 노출	선택 기준
대표 글	42편	6편	관점 3개를 각각 증명
인터뷰	3건	2건	외부 검증과 현재 역할 관련성
프로젝트	12개	4개	문제·역할·결과 근거가 모두 있음
경력 연표	7년	핵심 전환점 4개	직함보다 배운 능력 중심

사이트는 모든 기록의 창고가 아니라 가장 중요한 기록으로 독자를 안내하는 지도입니다. 상세 자료는 원문이나 다운로드 문서로 연결합니다.

모바일·검색·접근성 검수표

360px 화면에서 가로 스크롤이 생기지 않는가
본문 글자 크기가 확대 없이 읽을 수 있는가
메뉴와 버튼의 터치 영역이 충분한가
외부 링크가 새 창인지 알 수 있는가
이미지에 의미 있는 대체 텍스트가 있는가
키보드 탭 순서가 화면 순서와 같은가
각 페이지 제목과 설명이 고유한가
대표 제목이 한 페이지에 하나만 있는가
SNS 공유 이미지와 사이트 아이콘이 있는가
존재하지 않는 주소에서 검색 또는 홈 이동을 제공하는가
문의 경로에 불필요한 개인정보 입력을 요구하지 않는가
실제 휴대전화와 데스크톱에서 링크를 모두 눌러봤는가

검색 노출을 위해 경력 키워드를 반복하기보다 역할, 문제, 실행, 결과를 가까이 배치합니다. 흔한 표현을 판단 근거로 바꾸는 과정은 AI로 제안서 아이디어 검증하기에서도 확인할 수 있습니다.

GitHub 자동 배포 구조

가장 단순한 흐름은 다음과 같습니다.

수정 → 미리보기 → GitHub main 반영 → 자동 배포 → 공개 URL 확인

자동 배포가 있으면 다른 컴퓨터에서도 저장소를 통해 같은 사이트를 수정할 수 있습니다. 하지만 main에 들어간 변경이 바로 공개될 수 있으므로, 큰 수정은 별도 브랜치에서 검토하고 합치는 편이 안전합니다.

저장소에 포함	저장소에서 제외
HTML·CSS·스크립트	비밀번호·API 키
공개 이미지·아이콘	고객 원본·계약 자료
README·수정 방법	문의 응답·개인정보
배포 설정	로컬 임시 파일·백업본

보안과 실패 조건

공개 허가가 없는 회사·고객·성과를 포트폴리오에 넣지 않습니다.
연락처는 공개용 이메일이나 폼을 사용하고 개인 전화번호·주소를 노출하지 않습니다.
이미지의 메타데이터와 파일명에 내부 정보가 없는지 확인합니다.
GitHub 저장소가 공개라면 과거 커밋에도 비밀정보가 남지 않았는지 확인합니다.
자동 배포가 실패하면 이전 공개본을 유지하고 로그를 확인합니다.
결제·회원정보·민감한 문의를 받는 사이트는 단순 GitHub Pages 구조만으로 만들지 않습니다.

회사 자료를 AI와 다루기 전에는 AI 데이터 보안 체크리스트를 적용합니다.

만들면서 자주 빠지는 함정

경력 전체를 첫 화면에 넣습니다

자료가 많을수록 전문적으로 보일 것 같지만 독자가 핵심을 찾기 어렵습니다. 대표 증거를 보여주고 전체 기록으로 연결합니다.

디자인 레퍼런스를 그대로 복제합니다

색과 배치만 닮고 자신의 업무 관점이 없으면 다른 템플릿처럼 보입니다. 참고 사이트의 정보 구조를 분석하되 문장·이미지·고유 스타일을 복제하지 않습니다.

PC에서만 확인합니다

채용·협업 담당자는 메시지 링크를 휴대전화로 먼저 열 수 있습니다. 모바일 검수는 마지막 보완이 아니라 첫 제작 조건입니다.

자동 배포를 자동 승인으로 착각합니다

배포는 파일을 공개하는 절차일 뿐 내용의 사실관계와 공개 권한을 확인하지 않습니다. 최종 승인은 사람이 합니다.

FAQ

코딩을 전혀 몰라도 가능한가요?

정적인 소개·글·프로젝트 사이트는 가능합니다. 다만 공개할 정보와 읽히는 순서를 직접 판단하고, 미리보기에서 문장·링크·모바일 화면을 확인할 수 있어야 합니다.

GitHub Pages는 모든 홈페이지에 적합한가요?

포트폴리오처럼 정적인 공개 사이트에는 잘 맞습니다. 회원관리, 결제, 민감한 데이터 저장이 필요하면 별도의 백엔드·보안 설계가 필요합니다.

개인 도메인을 바로 사야 하나요?

처음에는 기본 주소로 구조와 내용을 확인한 뒤, 사이트를 지속적으로 운영할 판단이 서면 도메인을 연결해도 됩니다. 서비스별 현재 지원 범위와 비용은 구매일에 공식 문서를 확인합니다.

수정할 때마다 직접 업로드해야 하나요?

GitHub Actions와 Pages를 연결하면 메인 브랜치 변경 뒤 자동 배포할 수 있습니다. 자동화 설정은 저장소 권한과 공개 범위를 확인한 뒤 사용합니다.

포트폴리오에 성과 수치는 꼭 필요한가요?

숫자는 강한 증거지만 공개 승인과 비교 기준이 있어야 합니다. 수치를 공개할 수 없다면 문제, 역할, 판단, 산출물과 배운 원칙을 구체적으로 설명합니다.

공식 출처

기능과 화면은 바뀔 수 있으므로 실제 배포일에 GitHub와 OpenAI 공식 문서를 다시 확인합니다.