ChatGPT를 활용해 GitHub Pages 기술 블로그를 시작합니다
배경
이 블로그는 단순한 개발 기록장이 아니라, 실무에서 겪은 문제 해결 과정과 기술적 판단을 정리하기 위한 공간입니다.
백엔드/풀스택 개발자로 일하면서 Java, Spring Boot, 데이터베이스, Linux 서버 운영, 웹 서비스 배포, 데이터 분석 시스템화와 관련된 업무를 수행하고 있습니다. 업무 중에는 장애 대응, 서버 설정, 데이터베이스 이슈, 배포 환경 정리, 분석가와 개발자 사이의 요구사항 조율처럼 문서화하지 않으면 사라지는 경험이 많습니다.
그동안 이런 내용은 개인 메모, ChatGPT 대화, 업무 보고, GitHub 저장소 등에 흩어져 있었습니다. 이제는 이 경험들을 정리해서 재사용 가능한 기술 자산으로 만들고자 합니다.
왜 GitHub Pages인가
기술 블로그를 만들 수 있는 방법은 많습니다. Tistory, Velog, Medium, Notion 같은 서비스형 플랫폼은 빠르고 간편하게 글을 공개하기 좋고, Obsidian 기반 정적 사이트도 Git과 조합해 운영할 수 있습니다. 저는 그중 Markdown 글과 이미지, 정적 사이트 설정, 변경 이력을 GitHub 저장소에서 관리하고 GitHub 프로필·Actions·Pages까지 하나의 개발 작업 흐름으로 연결할 수 있다는 점을 우선했습니다.
첫째, 개발자의 작업 흐름과 잘 맞습니다. GitHub Pages 게시 설정과 배포 워크플로를 구성해 두면 Markdown으로 글을 작성하고 Git으로 변경 이력을 관리한 뒤, GitHub에 push한 변경을 자동으로 빌드하고 사이트에 배포할 수 있습니다.

이 저장소의 GitHub Pages 워크플로에서 build, report-build-status, deploy 작업이 성공한 화면입니다. 실제 공개 페이지의 글과 이미지가 정상 표시되는지는 배포 후 별도로 확인합니다.
이 저장소에서는 _posts, assets, docs, Jekyll(정적 사이트 생성기) 설정 파일을 일반 코드 저장소처럼 함께 관리합니다.

Markdown 글, 이미지, 문서와 Jekyll 설정을 하나의 Git 저장소에서 함께 관리하는 구조입니다.
둘째, GitHub 프로필과 포트폴리오를 연결하기 좋습니다. 코드 저장소와 공개 기술 기록을 같은 GitHub 생태계에서 관리할 수 있어, 이력서에서 짧게 설명한 경험을 더 구체적인 문제 상황과 해결 과정으로 연결하기 쉽습니다.
셋째, 코드와 문서를 함께 관리할 수 있습니다. 단순한 회고 글이 아니라 설정 파일, 명령어, 체크리스트, 장애 대응 절차를 함께 정리할 수 있습니다.
왜 ChatGPT를 활용하는가
ChatGPT는 단순히 질문에 답을 받거나 글을 대신 써 주는 도구보다, 실무 경험을 정리하고 검증 가능한 기록으로 옮기는 작업 흐름의 보조 도구로 사용합니다.
대화
-> 문제와 판단 근거 정리
-> 공개 가능 여부 확인
-> Markdown 작성
-> GitHub 변경
-> Pages 배포
-> 실제 결과 검증
이 흐름에서 검증은 AI가 정리한 기술 내용과 게시 결과를 나눠 수행합니다. 기술 내용은 코드·테스트·로그로 확인하고, 게시 결과는 공개 URL에서 글·이미지·링크가 의도대로 표시되는지 확인합니다.
업무 중 겪은 문제를 설명하면 ChatGPT를 통해 다음 형태로 정리할 수 있습니다.
- 문제점
- 원인
- 해결 방법
- 실행 명령어
- 재발 방지 방안
- 공개 가능한 포트폴리오용 글
실무에서는 문제를 해결하는 데 집중하다 보면 과정을 남기지 못하는 경우가 많습니다. ChatGPT를 활용하면 대화 내용을 바탕으로 기술 문서, 회고, 체크리스트, 블로그 글 초안으로 빠르게 변환할 수 있습니다. 다만 AI의 답변이나 초안을 그대로 게시하지 않고 검증 가능한 부분을 실제 증거로 확인하며, Git 이력으로 변경 과정을 남깁니다. 업무 내용을 AI에 입력할 때도 고객사명, 내부 주소, 계정·인증정보처럼 공개하면 안 되는 정보는 먼저 제거하거나 일반화합니다.
이 블로그에 정리할 내용
앞으로 이 블로그에는 다음 내용을 중심으로 정리할 예정입니다.
Backend
Java, Spring Boot, JSP, MyBatis, REST API, 인증/권한, 배포 구조와 관련된 내용을 정리합니다.
Database
PostgreSQL, Oracle, Tibero, SQL 튜닝, 데이터 모델링, 분석 결과와 서비스 테이블을 연결하는 방법을 정리합니다.
Infrastructure
Linux, Rocky Linux, Ubuntu, Nginx, Apache, Tomcat, SSL, Podman, Docker, 서버 운영 중 발생한 문제와 해결 과정을 정리합니다.
Data Systemization
데이터 분석 결과를 DB, API, 화면, 웹 서비스와 운영 시스템으로 연결하는 과정에서 필요한 개발, 배포, 운영 기준을 정리합니다.
Project Management
PMP 학습, 업무일지, 일일보고, 요구사항 정리, 고객 커뮤니케이션, 분석/개발 범위 조율 경험을 정리합니다.
Security & Audit
정보보안, CISA, ISMS-P, 내부통제, 보안 점검, 접근통제, 로그 관리와 관련된 학습 및 실무 내용을 정리합니다.
작성 원칙
이 블로그의 글은 다음 기준으로 작성합니다.
- 실무 문제를 중심으로 작성합니다.
- 단순 개념 설명보다 실제 문제 해결 과정을 우선합니다.
- 문제점, 원인, 해결, 실행 방법 구조를 기본으로 사용합니다.
- 고객사명, 내부 IP, 계정, 비공개 경로, 민감한 업무 내용은 공개하지 않습니다.
- 특정 프로젝트 경험은 일반화하여 재사용 가능한 지식으로 정리합니다.
- 이력서와 포트폴리오에서 참고할 수 있는 수준의 글을 목표로 합니다.
목표
이 블로그의 최종 목표는 글을 많이 쓰는 것이 아닙니다.
실무에서 겪은 문제를 다시 사용할 수 있는 지식으로 만들고, 어떤 방식으로 문제를 분석하고 해결하는 개발자인지 보여주는 것입니다.
이력서에는 기술 스택과 프로젝트명을 적을 수 있습니다. 하지만 실제로 어떤 문제를 어떻게 해결했는지는 짧은 이력서만으로 설명하기 어렵습니다.
이 블로그는 그 부족한 부분을 보완하는 공간이 될 것입니다.
앞으로의 계획
우선 다음 주제부터 정리할 예정입니다.
- Rocky Linux 디스크 마운트 실패 대응
- Apache VirtualHost 404 장애 분석
- Nginx와 Tomcat 기반 웹 서비스 운영 구조
- Podman 기반 CloudBeaver 운영 검토
- Spring Boot 운영 환경에서 자주 발생하는 문제
- 분석 결과를 웹 서비스로 시스템화할 때 고려할 점
- PMP와 CISA 학습 내용을 실무 관점으로 정리하는 방법
이 블로그는 완성된 지식만 올리는 공간이 아니라, 실무 경험을 정제하고 축적하는 공간으로 운영할 계획입니다.