비개발자가 GitHub로 회사 블로그를 만들었다

2026.03.28 조인트 팀 김대호

불과 1년 전까지 PPT, Word, Excel 위주로 일했던 사람이지만 지금은 MD파일로 90% 이상 바뀌었다. 회사 문서는 Notion에서 모두 GitHub으로 이관했지만, 브랜치를 따고 PR(Pull Request — 변경사항을 제안하고 검토받는 절차)을 올리고 코드 리뷰를 받는 건 과거의 일하는 방식과는 상당한 차이가 있다.

15년간 비즈니스와 사업/제품 기획을 해왔다. 블로그를 만들겠다고 하면 오래된 워드프레스 뿐만 아니라 좋은 블로그 운영툴이 굉장히 많다. 그런데 우리 회사 랜딩페이지, 업데이트노트 등이 이미 GitHub에 있었고, 블로그도 같은 곳에 붙이는 게 자연스러웠다. 도구는 Claude Code 하나. 블로그 플랫폼도, 디자인 툴도 쓰지 않았다. 만약 노브레인 바이브코딩으로 "블로그 만들어줘"라고 시키면 하루면 나왔을 것이다. 그런데 그렇게 하지 않았고 엔지니어링 build 방식을 더 습득하기 위해 정석으로 진행했다.

결론부터 말하면, 블로그가 나왔다. 포스트 4편이 올라갔다. 과정이 재밌어서 그 이야기를 쓴다.

시작: PRD부터 쓴다

블로그를 만들기로 하고 처음 한 일은 코딩이 아니었다. 문서 작성이었다.

PRD(Product Requirements Document)는 써본 적 있다. 하지만 이번엔 달랐다. "블로그에 뭐가 필요한지"를 360줄짜리로 정의했다. 기능별로 트리거(사용자가 뭘 하면), 액션(시스템이 뭘 하고), 피드백(사용자에게 뭘 보여주고), 에러 상태(뭐가 잘못되면 어떻게 하고)까지.

"Claude Code한테 블로그 만들어줘" 대신, "이 요구사항대로 만들어줘"라고 할 수 있게 된 것이다. 지시의 정밀도가 결과의 품질을 결정했다.

PRD의 형식은 알고 있었지만, 이 정도 밀도로 쓴 건 처음이었다. 결국 "무엇을 만들 것인지" 정리하는 것 자체가 절반의 일이었다.

태스크를 쪼갠다: T01-a부터 T01-e까지

PRD를 완성하고 나니 할 일이 산더미처럼 보였다. 여기서 배운 것이 태스크 분할이다.

T01(블로그 상세 페이지 만들기)이라는 하나의 태스크를 5개로 나눴다.

T01-a : HTML(웹페이지의 뼈대를 잡는 언어) 구조만 잡기. 스타일 없이 뼈대만.
T01-b : CSS(색상, 폰트, 여백 등 디자인을 입히는 언어) 스타일링. 여기서 예뻐진다.
T01-c : 반응형 레이아웃. 모바일에서 보이게 하기.
T01-d : 네비게이션 바. 기존 랜딩페이지 패턴 재사용.
T01-e : 푸터. 역시 기존 패턴 재사용.

각 서브태스크마다 "성공 기준"을 체크박스로 정의했다. 그리고 "Out of Scope" — 이 태스크에서는 안 하는 것 — 도 명시했다. 안 하는 것을 적어놓는 게 이렇게 중요한 줄 몰랐다. 범위가 흐려지면 끝이 없어진다.

왜 한 번에 안 하고 쪼갰는가. 이유는 단순했다. 하나씩 확인할 수 있어야 내가 학습할 수 있었다. "블로그 만들어줘"라고 시키면 결과물이 나왔을 때 뭐가 맞고 뭐가 틀린지 판단할 수 없다. "HTML 구조만 만들어줘"라고 시키면 구조가 맞는지 내 눈으로 확인할 수 있고 이해하여 학습이 되는것이다.

쪼개는 이유가 하나 더 있었다. 비즈니스에서도 일을 분기별로 나누고 협업하고 합친다. 하지만 퍼즐 하나가 빠져도 나머지가 독립적으로 작동한다. 100점에서 95점으로 떨어질 수는 있어도, 성과 자체는 나온다. 프로덕트 빌드는 달랐다. 하나가 깨지면 전체가 안 돌아간다. 95점이 아니라 0점이다. 게다가 블로그는 한 번 만들고 끝이 아니라 계속 글을 추가하고 업데이트해야 한다. 쪼개서 만드는 건 통제뿐 아니라 지속가능성을 위해서였다.

두 개의 레포, 하나의 흐름

작업은 두 개의 GitHub 저장소(레포)를 오가며 진행됐다.

문서 레포 : "무엇을" 만들 것인지 정의하는 곳.
페이지 레포 : "어떻게" 만들 것인지 구현하는 곳.

사이클은 이랬다. 문서 레포에서 요구사항 문서를 쓰고 → 페이지 레포에서 구현하고 → 구현하면서 발견한 것을 다시 문서 레포에 반영했다. PRD가 v0.1에서 v0.8까지 8번 진화한 이유가 이것이다. 만들면서 범위가 명확해졌다.

문서 레포에서 16개, 페이지 레포에서 13개. 총 29개의 PR이 블로그를 위해 만들어졌다.

처음에는 "목록 페이지는 나중에", "SEO는 나중에"였던 것들이 하나씩 "지금 해야 한다"로 올라왔다. 계획은 바뀐다. 중요한 것은 바뀐 것을 기록하는 것이었다.

리뷰의 힘: 코파일럿과 동료가 잡아준 것들

혼자 만든 것이 아니다. 매 PR마다 리뷰를 받았다. GitHub Copilot(AI 코드 리뷰)과 동료 개발자, 두 단계를 거쳤다.

T01-a(HTML 구조) PR #26에서 첫 리뷰를 받았다. 아직 만들지도 않은 CSS 파일을 HTML에서 참조하고 있었다. 리뷰에서 제거하고, T01-b(스타일링)에서 다시 추가했다. 작게 쪼갠 태스크 간의 의존성을 리뷰가 잡아준 것이다.

T04(CTA 버튼, 링크 복사, 저자 표시) PR에서는 코파일럿이 에러 핸들링 누락을 지적했다. 동료 개발자는 요구사항 문서 자체의 빈 곳을 발견했다. "복사 버튼을 연타하면 원본 텍스트가 유실되는" 버그도 리뷰 과정에서 발견돼서 별도 PR로 수정했다.

코드를 읽을 줄 몰라도, 리뷰 코멘트는 이해할 수 있었다. "이 부분에서 에러가 나면 사용자에게 아무 피드백이 없습니다" — 이런 코멘트는 개발 지식 없이도 판단할 수 있다. 비개발자도 리뷰를 "받을" 수 있다는 걸 알게 됐다.

반응형, 이미지, 그리고 시행착오

기술적이지만 가장 체감이 큰 경험들이 있었다.

반응형 . 데스크톱에서 멀쩡하게 보이던 블로그가 모바일에서 깨졌다. 글자가 화면 밖으로 나가거나, 이미지가 레이아웃을 뚫고 나오거나. "깨져"라고 말하면 고쳐지긴 하는데, 어디서 어떻게 깨지는지 설명하는 게 내 일이었다. "iPhone 14 Pro에서 두 번째 문단이 오른쪽으로 잘린다"처럼 구체적으로 말해야 정확히 고쳐졌다.

이미지 . OG 이미지(1200x630 픽셀)를 만들어서 넣었다. 블로그 링크를 공유했을 때 미리보기 이미지가 뜨는 것을 처음 봤을 때의 기분. 그런데 출시 후 썸네일이 잘리는 문제가 발견됐다(T06). 이미지 비율이 안 맞아서 목록 페이지에서 어색하게 크롭되고 있었다. 바로 수정 PR을 올렸다.

T05의 피봇 . 원래 T05는 "블로그 포스트 3편 발행하기"였다. 그런데 작업하다 보니, 매번 수동으로 발행하는 게 비효율적이었다. 목표를 바꿨다. "한 번 할 일"에서 "반복할 수 있는 발행 자동화 Claude 스킬 만들기"로. 결과적으로 지금은 마크다운 파일만 준비하면 10분 내로 발행이 끝난다.

완벽하지 않아도 출시했다. 출시 후 고쳤다. 그걸 가능하게 하는 게 이 프로세스였다.

끝나고, 남은 것

3월 18일에 시작해서 3월 27일에 블로그 포스트 4편이 올라갔다. 마크다운으로 글을 쓰면 10분 내로 발행된다. 수정도 직접 한다.

그런데 진짜 남은 것은 블로그가 아니다.

프로세스를 경험한 것이다. PRD를 쓰고 → 태스크를 쪼개고 → 하나씩 구현하고 → 리뷰를 받고 → 배포하고 → 문제를 발견하면 수정한다. 이 사이클이 소프트웨어가 만들어지는 방법이었다.

비개발자인 내가 이 사이클을 돌릴 수 있었던 이유가 있다. AI가 코딩을 대신해줘서가 아니다. 프로세스가 코딩보다 중요했기 때문이다.

순전히 바이브코딩으로 밀었으면 더 빨랐을 것이다. 하지만 과정을 이해하고, 동료와 리뷰하고, 반복 가능한 구조를 만들고 싶었다. 10일은 블로그를 만드는 데 쓴 시간이 아니었다. 제품을 만드는 방법을 익히는 데 쓴 시간이었다.

"무엇을 만들지 정의하고, 작게 쪼개고, 하나씩 확인하고, 피드백 받고, 고친다."

이건 개발자의 기술이 아니라 일하는 방식이다. 비즈니스와 기획을 하면서 해온 것과 본질이 같았다. 다만 쉽게 무뎌질 수 있는 기본이었다. 15년 전 신입사원 때, 하나라도 놓치지 않으려고 노트에 메모하며 습득했던 그 감각을 오랜만에 되살릴 수 있었다.

이 글을 읽고 있는 이 블로그가, 그 과정의 결과물이다.