기획자가 코드 없이 AI와 협업해 A-Z까지 직접 구축한 개인 블로그 서비스
| 코드 구현 | Claude Code |
|---|---|
| 데이터베이스 | Notion |
| 프론트엔드 프레임워크 | Next.js |
| UI 디자인 | Figma, Google AI Studio |
| 배포 및 호스팅 | Vercel |
‘블로그를 써야지’라는 생각은 늘 하고 있었지만, 실행에 옮기는 것은 쉽지 않았다. 처음 기획을 시작한 건 25년 7월이었다. 당시에는 개발자 지인과 협업해 비공식 Notion API와 Figma 와이어프레임, Google AI Studio를 바탕으로 웹페이지를 구현하려 했다. 하지만 서로 본업에 치이면서 프로젝트는 몇 달 동안 방치되고 말았다.
그러다 자연어만으로 코드를 짜주는 AI 코딩 툴이 비약적으로 발전하는 것을 보고, 내 기획력에 AI의 구현 능력을 더하면 이 프로젝트를 스스로 완성할 수 있겠다는 확신이 들었다. 실무에서 SQL을 다루며 SQLD를 취득할 만큼 DB 구조에 대한 이해도가 있었으며, HTML이나 CSS, Python 코드의 흐름 정도는 파악할 수 있는 기본적인 기술 배경을 갖추고 있었다.
결국 더 이상 남의 일정에 기대지 않기로 했다. 4월 9일, 무작정 VS Code 터미널에 Claude Code CLI를 설치해 매일같이 개발을 시작했다.
이토록 직접 블로그를 만들고자 했던 데에는 명확한 페인포인트가 있었다.
브런치나 티스토리 같은 플랫폼에 글을 쌓고 싶지 않았다. 정해진 템플릿 안에서는 내가 원하는 구조를 만들기가 어려웠고, 글의 성격에 따라 노출 방식을 다르게 하고 싶어도 플랫폼이 가진 제약이 명확했기 때문이다.
가장 근본적인 답답함이었다. 무엇을 어떻게 보여줄지 데이터 구조-화면까지 다 기획할 수 있는데도, 단지 코드를 직접 짜지 못한다는 이유로 프로덕트를 만들 수 없다니! 뼈대를 완벽히 세워두고도 결국 구현 단계에서는 개발자의 손을 빌려야만 하는 현실이 늘 못내 아쉬웠다.
이번 블로그 구축은 단순히 개인 공간을 만드는 것을 넘어, 코드를 몰라도 명확한 기획력과 실무적인 구조화 능력이 있다면 스스로 프로덕트를 런칭할 수 있음을 증명하기 위한 도전이었다. 그 결과, 혼자 본격적인 개발을 시작한 지 단 4일 만인 4월 13일, 실제 개발자의 도움을 거의 받지 않고도 도메인 연결 및 최종 배포까지 마칠 수 있었다.
블로그 설계의 핵심 기준은 단 하나였다. 철저히 글 쓰는 사람(=나)와 읽는 사람의 편의성을 높이고, Depth를 최소화하는 것. 코드는 AI가 짜더라도, 어떤 아키텍처를 선택하고 정책을 어떻게 가져갈지는 전적으로 기획자의 몫이었다.
블로그의 데이터베이스로 노션을 선택한 이유는 명확했다. 평소 가장 능숙하게 다루는 툴이었고, 별도 DB 구축 비용과 복잡한 세팅 과정을 피하고 싶었기 때문이다. 마침 공식 Notion API가 출시되어, 컬럼 상태값만 변경하면 블로그에 자동 발행될 수 있도록 뼈대를 잡았다.
프론트엔드 환경으로는 Next.js를 채택했다.
→ 이를 모두 충족하는 완벽한 프레임워크!
…라고 AI가 꽤 그럴싸하게 기술 도입 배경을 써주었지만, 솔직히 고백하자면 직접 찾아보기 전까지 저런 장점이 있는 줄 몰랐다. 애초에 이 조합은 과거 협업하려던 개발자 지인이 골라둔 기술 스택이었고, 참고한 레퍼런스 블로그의 방식을 그대로 가져온 것뿐이다.
내가 한 일은 프레임워크의 작동 원리를 파고드는 것이 아니었다. 테스트 화면을 나노 단위로 뜯어보며 "이미지가 너무 늦게 떠", "다크모드 색상이 깨져"처럼 철저히 UX 관점에서 문제를 포착하고, 요구사항을 정리해 AI에게 명확히 던지는 데 집중했다. 기술은 거들 뿐, 본질은 프로덕트를 런칭하는 것이니까. 코드를 파고드는 대신 PM의 역할에 집중한 결과, 단 한 줄의 코드도 짤 줄 모르는 상태에서 안정적인 자동화 파이프라인을 구축하는 데 성공했다.
DB 및 프레임워크 기반을 마련한 후엔 콘텐츠를 어떻게 분류하고 발행할지 프로세스를 세팅했다.
콘텐츠 성격이 다르면 보여주는 방식도 달라야 한다는 원칙 아래 노션 DB를 과감히 분리했다. 기술, 회고 등이 포함된 기록과 포트폴리오 형식의 작업 포스트, 소개 페이지를 나누어 독자가 목적에 맞게 콘텐츠를 탐색할 수 있도록 IA를 짰다.
발행 과정 역시 철저히 시스템화했다. 노션의 상태 필드(백로그/임시저장/발행)를 트리거로 삼았고, '임시저장' 상태일 땐 별도의 보안이 적용된 Draft 페이지에서 미리보기가 가능하게 만들었다. 더 나아가 매번 AI에게 자연어로 배포를 부탁하는 것조차 번거로워 나만의 슬래시 커맨드(/cp, /dr, /ed)를 자체 설계했다. 초안 생성부터 편집, 최종 배포(커밋+푸시)까지 복잡한 과정을 단 세 글자로 실행하도록 업무 흐름을 완벽히 단순화했다.
기존 블로그 플랫폼이 강제하는 템플릿 제약에서 벗어나, 내가 기획한 레이아웃을 100% 제어하는 것이 마지막 과제였다. Notion API는 단순 Markdown 구조만을 반환했기에, 최대한 원본과 유사하게 웹 화면이 표시되도록 지속적인 테스트를 거쳤다.
나아가, 글을 쓸 때마다 레이아웃을 수정하기 위해 AI의 도움을 받아야 한다면 진정한 자동화가 아니라고 생각했다. 그래서 커스텀 태그를 통해 작성자가 노션 이미지 캡션이나 컬럼 초입에 [s/m/l], [col:1:2] 같은 간단한 텍스트 태그만 달면, 화면에서 자동으로 크기와 여백, 다단 배치가 조절되도록 자체 규칙을 만들었다. 이로 인해 글 작성 단계에서 화면 디자인까지 모두 끝낼 수 있게 되었다.
자연어만으로 코딩이 되는 시대라지만, 현실은 요술 지팡이가 아니었다. 코드를 전혀 모르는 기획자 입장에서 AI와의 협업은 매 순간이 예측 불가능한 난관의 연속이었다. 하지만 이 삽질(?)의 시간은 기획자로서의 기본기를 다시 한번 되돌아보는 계기가 되었다.
초반에는 AI에게 “이미지 배경만 없애고 싶어”, “직관적으로 표시되게 해 줘”처럼 결과와 느낌 중심으로 요청하다 보니, 내 의도와는 전혀 다른 화면이나 기능이 나오는 일이 반복됐다.
AI가 내 말을 알잘딱깔센으로 알아듣길 원한다면, 해석의 여지가 없는 뾰족한 요구사항을 줘야 했다. 이를 해결하기 위해 AI에게 던지는 프롬프트 방식을 완전히 바꿨다. 단순한 대화 대신, 기획서를 쓰듯 조건과 정책을 명확히 쪼개서 지시하기 시작한 것이다.
예를 들어 “UI 좀 깔끔하게 정리해 줘” 대신, “1) 화면 너비가 640px 이하인 모바일에서는 2단 정렬을 해제하고 상하 배열로 바꿔줘. 2) 선택된 카테고리는 배경을 #ede9f6으로, 글자는 #6f42c1로으로 설정해 줘”처럼 객관적이고 검증 가능한 문장으로 좁혀서 요청했다.
결과는 성공적이었다. 두루뭉술한 감상을 배제하고 스펙을 날카롭게 정의할수록 AI가 엉뚱한 결과물을 뱉는 비율이 확연히 줄었다. 실제 개발자와 협업할 때도 마찬가지지만, AI를 대할 땐 인간보다 조금 더 치밀해야 한다. 기획자의 구체적이고도 뾰족한 요구사항 정의 능력이 프로덕트의 퀄리티를 좌우한다는 것을 다시금 실감했다.
노션에서 다단(Column) 비율을 조절하거나 이미지 크기를 예쁘게 맞춰도, 공식 API에서는 이 시각적인 데이터를 아예 내려주지 않는다는 사실을 구현 단계에서 발견했다.
단순히 코드로 해결하기엔 변수가 너무 많았다. 그래서 기술에 끌려가는 대신 정책으로 돌파하기로 했다. API가 데이터를 주지 않는다면, 작성자가 직접 명시하는 규칙을 만들면 될 일이었다. 그렇게 탄생한 것이 앞서 언급한 [s/m/l], [col:1:2] 등의 커스텀 텍스트 태그다. 개발적 제약에 부딪혔을 때, 정책과 룰을 스스로 세워 우회로를 뚫어내는 기획자의 문제 해결 방식을 제대로 깨우친 순간이었다.
가장 큰 성과는 단 4일 만에 머릿속에만 존재하던 taffy-story.com이라는 온전한 프로덕트가 세상에 나왔다는 것이다. 코드를 단 한 줄도 직접 짜지 않고, 요구사항 정의와 AI와의 치열한 소통만으로 서비스를 완성해 냈다. 기술의 장벽을 넘어, 기획력만으로 아이디어를 실체화할 수 있음을 증명한 셈이다.
하지만 기획자에게 런칭은 시작일 뿐이다. 정성 들여 쓴 글들이 독자들에게 잘 닿을 수 있도록 구글 서치 콘솔을 연동해 SEO 기반을 다지고, 런칭 이후에도 눈에 밟히는 자잘한 UX 문제들을 포착하며 화면과 기능을 지속적으로 디벨롭하는 중이다. Claude Code라는 훌륭한 개발자 팀원이 곁에 있으니, 아이디어만 있다면 언제든 개선할 수 있다. 방문자 트래픽 추이 및 피드백 등 구체적인 운영 지표는 데이터가 충분히 쌓인 후 추가 회고로 다룰 예정이다.
주니어 PM으로서 이번 프로젝트를 통해 얻은 가장 큰 깨달음은 명확하다. 코딩의 장벽이 사라지자, 역설적으로 기획의 해상도가 프로덕트의 퀄리티를 결정하는 전부가 되었다는 사실이다. AI가 코드를 짜준다고 해서 프로덕트가 뚝딱 나오는 것이 아니었다. 빈틈없는 정책을 세우고, 예외 케이스를 방어하며, 해석의 여지가 없는 뾰족한 요구사항을 던지지 않으면 AI는 의도와는 다른 결과물을 내놓는다.
AI 코딩 시대가 와도 기획자의 역할은 줄어들지 않을 것이다. 오히려 군더더기 없이 본질적인 설계와 의사결정에 더욱 집중하고 진화하고 있음을 온몸으로 배울 수 있었다.