개인 IT 프로젝트 블로그 구현부터 배포까지

2026년 30대가 시작된 나에게는 과정과 결과물을 한 곳에 남길 공간이 필요했다. ProJect Sail은 흩어진 프로젝트를 기록하고 다음 실행으로 이어가기 위해 만든 개인 IT 프로젝트 블로그다.

시작하며

제주 바이브코딩 캠프를 다녀온 이후 개인 IT 프로젝트를 하나씩 기획하고 만들기 시작했다. 프로젝트가 늘어나면서 결과물뿐 아니라 어떤 생각으로 시작했고 무엇을 고민하며 만들었는지 함께 모아둘 공간이 필요하다고 느꼈다.

직접적인 계기는 친한 형이 운영하는 테크 블로그였다. 완성된 결과물만 나열한 포트폴리오가 아니라 무엇을 만들었고 어떻게 진행했는지가 한곳에 쌓여 있는 모습이 좋아 보였다.

특히 나에게는 이런 공간이 더 필요했다. 나는 기획이나 새로운 아이디어를 생각하는 일은 좋아하지만 아이디어를 실제 결과물로 만드는 실행력은 상대적으로 부족한 편이었다. 생각만 하다가 멈춘 아이디어도 많았고 시간이 지나면 처음의 열정과 기록도 함께 사라지곤 했다.

그래서 프로젝트를 눈으로 확인하고 과정을 기록할 수 있는 나만의 기준점이 필요했다. 더 늦기 전에 직접 만든 결과물이 쌓여 있는 웹사이트를 하나쯤 갖고 싶다는 생각도 있었다.

왜 개인 IT 프로젝트 블로그가 필요했나

처음에는 노션과 메모장에 아이디어와 작업 내용을 기록했다.

간단하게 정리하기에는 편했지만 프로젝트별 기록이 여러 페이지와 폴더에 흩어졌다. AI와 나눈 대화는 각각의 채팅방에 남아 있었고 구현 과정에서 막혔던 문제와 해결 방법도 시간이 지나면 다시 찾기 어려웠다.

외부에 보여주는 공간으로서의 구조와 정체성도 부족했다. 노션에는 많은 내용을 쌓을 수 있지만 내가 무엇을 만들고 어떤 방향으로 움직이는 사람인지 보여주는 하나의 공간으로는 부족하다고 느꼈다.

나는 앞으로 AI와 바이브코딩을 활용해 여러 프로젝트를 직접 만들고 배포할 계획이었다. 그러려면 결과물과 과정을 한곳에 꾸준히 쌓아둘 기준점이 필요했다.

협업자나 심사자 그리고 미래의 파트너가 블로그를 봤을 때도 단순히 아이디어를 말하는 사람이 아니라 실제로 기획하고 만들고 실행하는 사람이라는 인상을 줄 수 있기를 바랐다.

어떤 블로그를 만들고 싶었나

블로그는 심플하고 정돈된 테크 블로그 형태로 만들고 싶었다. 완성된 결과물만 보여주는 일반적인 포트폴리오와는 다르게 기획과 구현 그리고 실패와 수정 과정에서 배운 내용까지 함께 기록하는 구조를 생각했다.

프로젝트가 잘됐을 때만 글을 올리고 싶지는 않았다. 실제로 시도했지만 중단한 프로젝트나 처음 계획과 다르게 바뀐 과정도 충분히 의미 있는 기록이라고 생각했다.

처음부터 불특정 다수를 위한 블로그를 만들 생각은 아니었다. 가장 먼저 이 글을 다시 읽게 될 미래의 나 그리고 언젠가 함께 프로젝트를 진행할 협업자나 파트너가 주요 독자였다.

블로그의 방향이 흐려지지 않도록 무엇을 기록하고 무엇을 기록하지 않을지도 정했다.

개인 블로그이지만 모든 일상을 다루는 공간으로 만들지는 않기로 했다.

아이디어가 어떤 문제에서 시작됐는지, 기능과 범위를 어떻게 정했는지, 어디에서 막혔고 무엇을 배웠는지를 중심으로 기록하는 개인 IT 프로젝트 아카이브로 정의했다.

ProJect Sail이라는 이름과 브랜드 방향

ProJect Sail이라는 이름을 선택한 이유는 비교적 명확했다.

Sail에는 항해한다는 의미가 있다. 완성된 정답만 보여주는 공간보다 방향을 정하고 직접 움직이며 시행착오를 기록하는 공간에 어울린다고 생각했다.

로고에는 복잡한 배나 파도 대신 나침반 심볼을 사용했다. 나침반은 앞으로 나아갈 방향을 찾는다는 의미를 담을 수 있었고 작은 헤더와 파비콘에서도 비교적 명확하게 보였다.

대표 문구는 다음과 같이 정했다.

말보다 결과물

아이디어보다 실행

아이디어와 계획을 설명하는 데서 끝나지 않고 작더라도 직접 만들고 배포하겠다는 태도를 담은 문구였다.

전체 디자인은 화려한 개인 홈페이지보다 콘텐츠가 먼저 보이는 담백한 테크 블로그를 목표로 했다. 메인 컬러는 선명한 블루 계열로 정하고 카테고리와 링크 그리고 버튼처럼 방향을 알려주는 요소에만 포인트로 사용했다.

블로그의 기본 구조를 설계하다

1차 버전에서는 방문자가 프로젝트를 발견하고 글을 읽는 흐름에 필요한 화면만 구성했다.

About 메뉴를 위한 별도의 짧은 소개 페이지는 만들지 않았다. 지금 작성하고 있는 제작기 글이 ProJect Sail의 목적과 방향을 더 잘 설명한다고 생각해 About 메뉴에서 이 글로 연결하도록 했다.

Home에는 블로그의 방향을 보여주는 Hero 영역과 최근 글을 보여주는 Build Archive 그리고 실제로 참고한 자료를 모아둔 Resources를 배치했다.

All Posts에는 전체 글과 카테고리 필터를 넣었다. 카테고리는 AI, Vibe Coding, IT Project, Learning으로 구분했다.

글 상세 페이지에는 본문의 대제목을 자동으로 읽어오는 우측 목차를 추가했다. 글마다 목차를 따로 입력하지 않아도 각 글의 구조에 맞는 목차가 생성되도록 했다.

1차 버전에서 무엇을 제외했나

처음에는 관리자 페이지와 검색 그리고 댓글과 사이트 안에서 직접 글을 작성하는 기능도 생각했다.

하지만 1차 버전의 목표는 기능이 많은 블로그가 아니었다. 지금 바로 글을 쓰고 프로젝트를 기록할 수 있는 실제 사용 가능한 블로그를 만드는 것이 우선이었다.

그래서 다음 기능들은 1차 버전에서 제외했다.

관리자 페이지
데이터베이스
회원 로그인
댓글
사이트 내부 검색
직접 글을 작성하는 에디터

글은 MDX 파일로 작성하고 이미지는 프로젝트별 폴더로 관리하기로 했다. GitHub에 변경 내용을 저장하면 Vercel을 통해 자동으로 배포되는 비교적 단순한 구조를 선택했다.

글이 충분히 쌓이지 않은 상태에서 복잡한 콘텐츠 관리 기능부터 만드는 것은 우선순위가 아니라고 판단했다.

1차 버전의 목표

기능이 많은 블로그가 아니라 지금 바로 기록할 수 있는 블로그를 만든다.

Claude Code로 실제 구현하기

ProJect Sail은 Claude Code를 활용한 바이브코딩 방식으로 구현했다. 나는 개발 비전공자이기 때문에 코드를 처음부터 직접 작성하기보다 어떤 화면과 기능이 필요한지 정리하고 Claude Code가 프로젝트 파일을 분석하고 수정하도록 했다.

처음에는 원하는 결과를 자연어로 설명하면 바로 완성될 것이라고 생각했다. 하지만 실제로는 내가 무엇을 원하는지 얼마나 정확하게 정의하는지가 더 중요했다. 수정 범위가 모호하면 기존 화면이나 다른 기능까지 함께 바뀌기도 했다.

작업을 반복하면서 요청 방식도 점차 구체적으로 바뀌었다.

작업 목적
현재 문제
수정 목표
작업 전 확인할 파일
수정 가능한 파일
수정하면 안 되는 파일
작업 후 확인할 항목
오류와 빌드 확인

AI가 코드를 작성해주더라도 문제와 기준을 정하는 일은 사람이 해야 했다.

프로젝트는 Next.js App Router와 TypeScript 그리고 Tailwind CSS를 기반으로 구현했다. 글은 MDX로 관리했다.

GitHub에는 코드와 변경 이력을 저장하고 Vercel을 통해 사이트를 배포했다.

전체 작업은 다음 흐름으로 진행했다.

기획과 구조 정리
→ 기본 화면 구현
→ MDX 글 연결
→ 모바일과 PC 화면 조정
→ GitHub 저장
→ Vercel 배포
→ 실제 콘텐츠 적용
→ 가독성과 디자인 재수정

처음에는 화면을 구현하고 배포하면 프로젝트가 끝날 것이라고 생각했다. 실제로는 글과 이미지를 넣은 이후부터 더 많은 수정이 시작됐다.

실제 콘텐츠를 넣고 다시 수정한 것들

기본 페이지를 구현하는 것보다 실제 콘텐츠를 넣고 화면을 다듬는 데 더 많은 시간이 들었다. 샘플 글에서는 보이지 않던 줄바꿈과 이미지 정렬 그리고 표 간격과 모바일 레이아웃 문제가 실제 긴 글을 작성하면서 한꺼번에 드러났다.

특히 MDX의 줄바꿈은 예상보다 훨씬 까다로웠다. 일반 문서에서는 엔터로 문장을 구분하면 되지만 MDX에서는 빈 줄 하나가 새로운 문단이 된다. 문장마다 빈 줄을 넣으면 모든 문장이 따로 떨어져 글의 흐름이 지나치게 끊겨 보였다.

표와 이미지도 원고에서 정확한 위치를 지정하지 않으면 실제 화면에서 문맥과 다른 곳에 배치됐다. 이 과정을 겪으면서 글에도 코드처럼 일정한 작성 규칙이 필요하다는 것을 알게 됐다.

화면을 처음 구현했을 때는 전체적인 디자인과 기능을 먼저 봤다. 하지만 실제 글을 넣고 읽어보니 블로그의 인상은 화려한 UI보다 본문 글씨 크기와 문단 간격 그리고 이미지 위치와 표의 밀도 같은 작은 요소에서 결정됐다.

본문 글씨가 너무 작으면 긴 글을 읽기 어려웠고 이미지가 중앙에 놓이면 텍스트의 시작선과 맞지 않아 흐름이 끊겨 보였다. 표의 셀 여백이 너무 크거나 여러 열이 좁은 화면에 들어가면 한 문장이 과도하게 줄바꿈되기도 했다.

그래서 썸네일과 본문 이미지 그리고 영상과 표의 기본 기준을 따로 만들었다.

대표 썸네일과 커버는 1600 × 900 크기의 16:9 비율로 통일했다. 본문 이미지는 모든 사진을 같은 비율로 자르지 않고 원본의 의미를 유지하는 방향으로 사용했다. 이미지는 본문 시작선에 맞춰 왼쪽 정렬하고 넓게 보여줘야 하는 화면만 별도로 크게 표시했다.

표는 연한 노란색 헤더와 첫 번째 열 강조를 기본으로 정하고 불필요한 셀 여백을 줄였다.

실제 완성도는 글의 문단 구조와 이미지 위치 그리고 표의 밀도와 썸네일의 일관성처럼 콘텐츠를 보여주는 방식에서 결정됐다.

로컬 프로젝트를 실제 웹사이트로 배포하다

기본 화면과 글 구조를 만든 뒤 GitHub 저장소와 Vercel을 연결했다. 로컬에서 작업한 내용을 GitHub에 올리면 Vercel이 자동으로 새로운 버전을 빌드하고 배포하는 흐름을 만들었다.

로컬에서 작업
→ 오류와 빌드 확인
→ GitHub에 저장
→ Vercel 자동 배포
→ 실제 사이트에서 최종 확인

처음에는 Vercel에서 제공하는 기본 주소로 사이트를 확인했다. 이후 project-sail.kr 도메인을 구매해 연결했다. DNS와 HTTPS가 반영되는 데 시간이 조금 필요했지만 일정 시간이 지나자 실제 도메인으로 정상 접속할 수 있었다.

로컬에서만 보던 결과물이 누구나 접속할 수 있는 주소를 가진 웹사이트가 된 순간이었다.

도메인을 연결한 뒤에는 파비콘과 공유 이미지 그리고 검색엔진 접근 설정과 사이트맵 그리고 기본 메타데이터도 정리했다. 커버 이미지의 용량이 너무 큰 경우에는 화면 품질을 크게 떨어뜨리지 않는 범위에서 압축했다.

ProJect Sail을 만들며 배운 것

ProJect Sail을 만들며 가장 크게 느낀 것은 이전 바이브코딩 캠프와 AI 솔로프러너 지원 과정에서 배웠던 내용과 비슷했다. AI는 사람의 손과 발이 되어주는 도구로는 강력하다. Claude Code는 파일을 분석하고 코드를 수정하며 오류를 해결하는 데 큰 도움이 됐다.

하지만 어떤 블로그를 만들지, 무엇을 먼저 보여줄지, 어떤 기능을 제외할지, 글의 어느 위치에 이미지를 넣을지는 결국 내가 결정해야 했다. AI에게 어떤 일을 시킬 것인지 명확하게 정의하는 능력은 사람이 갖춰야 했다.

요구사항이 애매할수록 결과도 애매했고 작은 수정도 기준 없이 반복하면 오히려 더 많은 시간이 필요했다. 반대로 원하는 결과와 수정 범위를 정확하게 정리하면 개발 비전공자인 나도 실제로 사용할 수 있는 웹사이트를 완성할 수 있었다.

AI는 구현 속도를 높인다.

방향과 기준은 사람이 정한다.

또 하나 알게 된 것은 좋은 결과물이 코드만으로 완성되지 않는다는 점이다. 기획과 문장 그리고 이미지와 정보 구조 그리고 반복적인 확인이 함께 맞아야 실제로 사용할 수 있는 결과물이 된다.

앞으로의 운영 방향

앞으로 ProJect Sail에는 처음 기획했던 방향과 동일하게 내가 직접 참여하고 실행한 IT 프로젝트를 중심으로 기록할 예정이다. 개인적인 일상이나 감정 일기보다 프로젝트가 시작되고 만들어지고 수정되는 과정에 집중하려고 한다.

기록할 주제는 다음과 같다.

• 창업과 사업을 진행하는 과정
• AI와 바이브코딩 프로젝트
• MVP 기획과 구현 과정
• 서비스 출시와 초기 수익화 시도
• 교육과 캠프 그리고 프로그램 참여 기록
• 실패하거나 중단한 프로젝트
• 다시 수정하고 개선한 과정

목표는 매주 무조건 하나의 완성형 서비스를 만드는 것이 아니다. 작더라도 아이디어를 실제 결과물로 만들고 배포하고 기록하는 흐름을 꾸준히 이어가는 것이 더 중요하다.

기능 추가도 실제로 필요해졌을 때 진행할 생각이다. 지금은 블로그의 기능을 늘리는 것보다 실제 글과 결과물을 채워가는 것이 먼저다.

마무리하며

ProJect Sail을 만드는 과정 자체가 나의 첫 번째 개인 IT 프로젝트였다. 완벽한 블로그를 만든 것은 아니지만 아이디어를 실제 결과물로 바꾸고 그 과정을 기록할 수 있는 기반을 만들었다.

로고와 문구를 정하고 화면을 구현했으며 모바일과 PC의 여백을 조정했다. 실제 글을 넣은 뒤에는 본문 글씨와 이미지 그리고 표의 기준도 다시 정리했다.

작은 수정이 반복됐지만 그 과정을 거치며 내가 원하는 블로그의 방향도 조금씩 선명해졌다.

완벽하게 준비된 뒤 시작한 것은 아니었다. 먼저 만들었고 부족한 부분을 확인했으며 다시 고쳤다.

이제 공간은 만들어졌다.

다음은 이 안을 실제 프로젝트와 실행의 기록으로 채워가는 일이다.