← 목록으로

AI로 포트폴리오 사이트를 처음 만들어봤다

#AI협업#바이브코딩#포트폴리오

노션 정리하다가 웹사이트를 짜게 될 줄이야

회사에서 매주 한 번씩 AI 스터디를 하고 있다. 이것저것 탐색하던 중에 바이브코딩으로 K-pick이라는 작은 웹페이지를 하나 만들어봤는데, 그게 발단이었다. 사실 연초까지만 해도 포트폴리오는 노션으로 간단히 정리해두면 그만이라고 생각했다. 그런데 AI가 뽑아주는 html, 자바스크립트, CSS 코드만으로 그럴듯한 사이트가 만들어지는 걸 보니, 개발자가 아니어도 해볼 만하겠다 싶었다. 그렇게 머릿속에만 있던 포트폴리오 홈페이지 계획이 실행으로 옮겨졌다.

ideachip.net 포트폴리오 웹사이트 구축 워크플로우

IDEACHIP.NET 포트폴리오 웹사이트 구축 워크플로우

지나고 나서 AI한테 정리를 시켜보면 이렇게 두 단계, 네 칸으로 깔끔하게 요약이 된다. 스마트하게 개발하고, 자동화 빌드하고, CMS로 편하게 관리하고, SEO까지 챙긴 것처럼 보인다. 근데 실제로 겪은 과정은 이 도표만큼 매끈하지 않았다.

메모장 노가다에서 VS Code로

맨 처음엔 정말 무식하게 했다. 제미나이가 짜준 코드를 메모장에 붙여넣고, 확장자를 .html로 바꿔 저장한 다음 브라우저로 열어서 확인하는 식이었다. 이걸 수십 번 반복했다. 그러다 Visual Studio Code와 GitHub Desktop을 깔면서 코드를 보고 수정하고 배포하는 과정이 한결 수월해졌다.

Cloudflare Pages나 GitHub 같은 서비스도 이때 처음 알게 됐다. 레포지토리, 배포, 푸시… 용어부터 낯설었다. 연동되는 개념을 이해하는 것도 쉽지 않았다. 모르는 게 나오면 화면을 캡처해서 AI에 물어보는 걸 반복했다.

"프로젝트마다 상세페이지를 따로 만드세요"

메인페이지 디자인은 모던하고 심플하게 잡아갔는데, 문제는 포트폴리오 데이터였다. 20여 개나 되는 작업물을 어떻게 올릴 것인가. 제미나이는 처음에 프로젝트마다 상세페이지를 따로 만들어서 올리라고 했다. 내가 개발 지식이 없어서 메모장에 하나하나 노가다로 붙여넣는 걸 보더니, 포트폴리오도 그런 식으로 하라는 건가 싶었다. 남들은 AI로 자동화한다는데 나는 노가다의 연속이었다.

제미나이의 위로의 말

"으휴" 하고 한탄을 했더니 제미나이가 이런 말을 해줬다. 지금 하는 이 고생은 결국 남이 만든 템플릿에 기대는 게 아니라 디자이너가 평생 써먹을 수 있는 나만의 관리 시스템을 만드는 과정이라고. 그러면서 이 고생이 '찐'인 이유 세 가지를 짚어줬다 — 남의 손을 안 타는 진짜 내 사이트를 갖게 된다는 것, 지금 반복 노동을 시스템으로 만들어두면 앞으로는 데이터 한 줄만 추가하면 된다는 것, 그리고 디자이너가 코드까지 만져봤다는 경험 자체가 나중에 개발자와 협업할 때 무기가 된다는 것.

듣고 보니 맞는 말이었다. 그래서 프로젝트마다 페이지를 일일이 만드는 대신, 프로젝트 정보(제목, 이미지, 크레딧 등)를 하나의 데이터 목록으로 정리하고, 그 데이터를 읽어서 같은 틀로 상세페이지를 찍어내는 구조로 바꿨다. 20개든 100개든 데이터만 추가하면 페이지는 자동으로 만들어지는 셈이다. 이후로 새 프로젝트가 생기면 정보 한 줄 추가하는 것으로 끝이다.

클로드로 넘어가면서 달라진 것들

제미나이로 어느 정도 만들어놓고, 클로드에게 그동안 짠 코드를 검토해달라고 했다. 버그·오류 3개, 경고 4개, 개선 제안 4개, 잘된 점 3개 — 이렇게 항목별로 자세한 리포트를 받았다. 아, 다양한 AI를 써봐야 하는구나, 그때 확실히 느꼈다.

이후 세부 수정과 uglyQ 글쓰기 공간도 클로드와 같이 만들어갔다. 네이버 블로그처럼 쉽게 글 쓰고 올리는 페이지 정도로 생각했는데, 처음엔 자바스크립트로 직접 글을 쓰라고 해서 난감했다. 이미지도 넣어야 하는데 글 쓸 때마다 그런 불편을 감수하고 싶지 않았다. 클로드가 Pages CMS 연동을 추천해줬고, 써보니 노션에서 글 쓰는 것과 비슷한 느낌이었다. 자바스크립트로 직접 쓰는 것보다는 훨씬 편해졌다.

반응형은 잘 짜주는데, 여백은 결국 내 몫

AI와 협업하면서 제일 좋았던 건 모를 때 바로바로 물어볼 수 있다는 점이었다. 코드를 짤 때 처음부터 모바일 버전을 염두에 두고 반응형으로 만들어달라고 했는데, 큰 고민 없이도 기본 틀은 빠르게 잘 잡아줬다.

다만 딱 거기까지였다. 여백을 미세하게 조정하거나 폰트 크기를 결정하는 건 결국 디자이너가 개입해야 했다. 디자이너의 취향이 반영되는 영역이기도 하고, AI가 잡아준 기본값이 늘 맞는 건 아니었기 때문이다.

작업하면서 의외로 도움이 됐던 건, 이미지 데이터가 준비 안 된 상태에서 시작했다는 점이었다. 빈자리를 회색 박스로 미리 만들어두고 전체 레이아웃을 먼저 짤 수 있었다. 작업물 이미지가 하나씩 채워질 때마다 메인 페이지가 조금씩 완성돼가는 재미가 있었다.

그리고 보여지는 디자인만이 아니라 '데이터'로도 생각해야 한다는 걸 배웠다. 앞으로 프로젝트가 계속 쌓일 걸 감안해서, 각 프로젝트를 숫자 아이디로 관리하고 그 역순으로 노출되게 해서 최신 작업물이 위로 오도록 만들었다. 이런 식의 데이터 관리 방식도 이번에 새로 익힌 부분이다.

지금, 그리고 앞으로

도메인은 5월 초에 구매했고 그때부터 계속 업데이트 중이다. 모든 걸 완벽히 갖춘 다음 도메인을 연결하려 했으면 오히려 더 많이 갈아엎었을 것 같다. 어차피 콘텐츠가 많지 않아 방문자도 적을 테니, 일단 열어두고 다듬어가는 쪽을 택했다.

지금은 포트폴리오 작업물 위주지만, 다음 순서는 insight다. 20년 넘게 현장에서 부딪힌 것들 — 이를테면 OEM·제조사·디자이너 사이에서 소통이 꼬이는 순간이라든가, 규제 때문에 디자인이 바뀌어야 했던 사례 같은 걸 하나씩 남겨보려 한다.

uglyQ에는 그 사이사이, 테스트하다 엉뚱하게 나온 결과물들도 계속 올릴 생각이다. 다음 실험은 아마 이 사이트의 글 목록을 지금처럼 자바스크립트로 fetch하는 방식 말고, 글마다 제대로 된 주소를 갖게 만드는 작업이 될 것 같다.

패키지 디자인, 표시기준 검토가 필요하신가요? 문의하기