AI로 웹사이트를 만드는 순서: 디자인, 이미지, 영상, 코드

AI에게 “괜찮은 홈페이지를 하나 만들어 줘”라고 요청하면 화면은 금세 나옵니다. 문제는 그렇게 나온 화면이 대체로 우리 브랜드의 것이 아니라는 데 있습니다. 색과 여백은 무난하지만 어디서 본 듯하고, 무엇을 먼저 읽어야 하는지가 정해져 있지 않습니다. 도구가 부족해서가 아니라, 순서를 건너뛰었기 때문입니다.

지금의 제작 환경에서는 디자인, 사진, 영상, 코드가 모두 AI로 만들어집니다. 그래서 오히려 어떤 순서로 무엇을 확정하느냐가 결과를 가릅니다. 이 글에서는 한 채의 건물을 짓듯 진행하는 웹사이트 제작 흐름을 단계별로 정리했습니다. 특정 도구를 쓰지 않더라도 그대로 적용할 수 있는 순서입니다.

AI는 속도를 줍니다. 순서는 주지 않습니다.

1. 화면을 코드로 옮기기 전에, 디자인을 끝낸다

가장 큰 차이는 첫 단계에서 갈립니다. 코딩 도구에 곧바로 “만들어 줘”라고 하는 대신, 디자인 도구에서 화면 한 장을 끝까지 완성하는 것입니다. 여기서 확정해야 할 것은 많지 않습니다. 기준 화면 폭, 12칼럼 그리드, 본문과 제목에 쓸 서체 한두 종, 그리고 전체 색조입니다.

어두운 톤을 쓰기로 했다면 완전한 검정보다 아주 옅은 색을 섞은 검정이 화면에서 더 깊게 보입니다. 큰 제목이 대표 이미지 뒤로 지나가게 만드는 것 같은 겹침 처리, 아래쪽만 흐려지는 그라디언트 블러 같은 디테일도 이 단계에서 결정합니다. 이런 판단은 지시하지 않으면 AI가 알아서 만들어 주지 않습니다. 반대로 한 번 정해 두면, 이후 모든 섹션이 같은 규칙을 따릅니다.

2. 사진이 없는 고객사에는, 만들어서 보여 준다

실무에서 가장 자주 막히는 지점은 디자인이 아니라 소재입니다. 이제 막 시작하는 회사이거나, 현장 사진은 있지만 웹에 쓰기 어려운 품질인 경우가 많습니다. 예전에는 스톡 사진으로 자리를 메웠지만, 지금은 필요한 장면을 직접 생성하는 편이 훨씬 정확합니다.

프롬프트에는 네 가지를 함께 넣습니다. 무엇이 화면 중앙에 있는지, 어떤 시간과 장소인지, 조명은 어디에서 오는지, 어떤 분위기로 마무리할지입니다. “야간 현장, 중앙에 대형 굴착기, 뒤로 완공된 주택, 옅은 안개, 시네마틱”처럼 적으면 그 회사만의 장면이 나옵니다. 같은 프롬프트를 두세 개의 이미지 모델에 동시에 넣고 결과를 나란히 비교하는 방식도 권할 만합니다. 모델마다 해석이 달라서, 고를 수 있는 폭이 넓어집니다.

다만 공개되는 사이트라면 생성 이미지가 실제 시공 실적으로 오해되지 않도록 해야 합니다. 컨셉 이미지는 컨셉으로 쓰고, 실적 페이지에는 실제 사진을 넣는 원칙만 지키면 됩니다.

3. 디자인을 코드로 넘기는 세 가지 경로

완성된 디자인을 코딩 에이전트에 전달하는 방법은 크게 세 가지입니다. 뒤로 갈수록 사람이 다시 채워 넣어야 하는 정보가 줄어듭니다.

• 이미지로 넘기기 — 화면 전체를 이미지로 내보내 그대로 전달합니다. 서체와 크기는 추정으로 채워지고, 로고와 사진 같은 자산은 따로 내보내 넣어 줘야 합니다. 도구를 가리지 않는다는 장점이 있습니다.
• 개발자 모드의 프롬프트를 넘기기 — 디자인 도구가 선택한 프레임을 코딩 에이전트용 프롬프트로 정리해 줍니다. 이 문장을 그대로 붙여 넣으면 레이아웃 구조와 자산 참조가 함께 전달되어, 추정으로 채워지는 부분이 줄어듭니다.
• MCP로 디자인 파일을 직접 연결하기 — 캡처를 건네는 대신, 에이전트가 디자인 파일을 직접 열어 보게 합니다. 지금 가장 정확한 방법입니다.

Figma MCP로 연결하면 달라지는 것

MCP(Model Context Protocol)는 코딩 에이전트가 외부 도구를 직접 다루게 해 주는 연결 규격입니다. Figma는 이 통로를 공식 서버로 제공하고, Claude Code를 포함한 주요 코딩 도구가 연결을 지원합니다. 연결은 한 줄이면 끝납니다.

claude mcp add --transport http figma https://mcp.figma.com/mcp

이 원격 서버는 Figma 데스크톱 앱 없이 동작하고 모든 플랜에서 붙일 수 있습니다. 사내 정책상 로컬에서만 써야 한다면 데스크톱 앱이 여는 서버를 대신 연결할 수 있는데, 이쪽은 유료 플랜의 Dev 또는 Full 시트가 필요합니다.

쓰는 법은 링크 하나입니다. Figma에서 옮기고 싶은 프레임을 우클릭해 선택 항목 링크 복사를 누르고, 그 주소를 그대로 붙여 넣은 뒤 무엇을 만들지 적습니다.

이 링크의 히어로 섹션을 구현해 주세요. src/components/ui 아래에 이미 있는 컴포넌트를 재사용하고, 색과 간격은 Figma 변수 이름을 그대로 CSS 변수로 옮겨 주세요.

이 한 문장에 에이전트는 파일을 여러 번 조회합니다. 레이아웃 구조와 코드 표현을 가져오는 get_design_context, 색·간격·타이포 변수 목록을 주는 get_variable_defs, 눈으로 대조할 get_screenshot, 아이콘과 사진 원본을 내려받는 download_assets가 차례로 쓰입니다. 그래서 “대략 이 정도 크기”가 아니라 실제 값으로 화면이 만들어집니다.

실무에서 체감되는 차이는 세 가지입니다.

• 간격과 크기가 추정되지 않습니다 — 24px 여백은 24px로 넘어옵니다. 첫 빌드에서 손볼 양이 눈에 띄게 줄어듭니다.
• 디자인 변수가 그대로 토큰이 됩니다 — 디자인에서 정한 색 이름이 코드의 변수 이름과 이어집니다. 나중에 톤을 바꿀 때 한 곳만 고치면 됩니다.
• 기존 컴포넌트를 재사용시킬 수 있습니다 — 어느 폴더의 무엇을 쓰라고 지시하면 같은 버튼을 또 만들지 않습니다. Code Connect로 디자인 컴포넌트와 코드 컴포넌트를 미리 짝지어 두면 더 정확해집니다.

한도는 미리 확인해 두는 편이 좋습니다. 무료 플랜이거나 뷰어·협업 시트라면 도구 호출이 월 6회로 제한되고, 유료 플랜의 Dev·Full 시트는 분당 한도로 넉넉하게 열립니다. 화면 하나를 옮기는 데도 호출이 여러 번 일어나므로, 실제 프로젝트에 쓸 계획이라면 시트부터 정리하는 것이 좋습니다.

한 가지 더. MCP를 붙였다고 해서 사이트 전체를 한 번에 넘기는 시도는 권하지 않습니다. 프레임 하나, 섹션 하나씩 옮기고 매번 확인하는 편이 결과적으로 더 빠릅니다.

어느 경로를 택하든 첫 결과물은 완성이 아닙니다. 기준 폭이 어긋나 넓은 화면에서 어색하게 벌어지거나, 테두리 선의 두께가 디자인과 다른 정도의 문제는 남습니다. 그래도 이 상태가 좋은 출발점인 이유는, 남은 일이 “새로 만드는 일”이 아니라 “맞춰 가는 일”이기 때문입니다.

4. 움직임은 화면의 언어로 지시한다

요즘 사이트에서 인상을 만드는 것은 대개 스크롤에 반응하는 구간입니다. 예를 들어 공정을 보여 주는 섹션이라면, 그 자리에 도달했을 때 화면 전체가 고정되고 스크롤을 내리는 만큼 영상이 재생되게 만들 수 있습니다.

이때 “멋있게 움직이게 해 줘”라고 요청하면 결과가 매번 달라집니다. 대신 조건을 화면의 언어로 적습니다.

이 섹션의 높이를 화면 높이만큼 잡고, 스크롤 진행도 0%에서 100%를 영상의 시작과 끝에 그대로 연결해 주세요. 재생이 끝날 때까지 제목과 진행 표시줄은 화면에 고정되어 있어야 합니다.

이렇게 적으면 대체로 한 번에 의도한 동작이 나옵니다. 높이, 고정 여부, 진행도와 재생 위치의 연결 — 이 세 가지가 지시에 들어 있으면 충분합니다.

5. 조각을 따로 만들면 이어지지 않는다

여기서 실제로 자주 실패하는 지점이 있습니다. 공정 네 단계를 보여 주려고 영상을 네 개로 나눠 만드는 방식입니다. 각각은 잘 나옵니다. 그런데 이어 붙이면 창의 위치가 달라지고, 지붕의 형태가 바뀌고, 마지막 장면에 있어야 할 것이 빠져 있습니다. 단계마다 모델이 조금씩 다른 집을 상상하기 때문입니다.

해결책은 순서를 뒤집는 것입니다. 완성된 모습을 먼저 정하고, 그 이미지를 기준으로 삼아 한 편의 긴 영상을 만듭니다. 20초짜리 하나에 네 단계를 5초씩 담고, 마지막이 준비한 완성 이미지와 맞아떨어지도록 요청하는 식입니다. 그러면 처음부터 끝까지 같은 건물이 유지되고, 결과가 어디에 도착할지도 미리 알 수 있습니다.

이 원칙은 영상에만 해당하지 않습니다. 여러 장의 이미지 세트, 여러 페이지의 문장 톤, 여러 섹션의 레이아웃 모두 같습니다. 끝을 먼저 고정하면 중간이 흔들리지 않습니다.

6. AI가 내놓은 것은 언제나 초안이다

디자인과 구현이 빨라진 만큼, 마지막 점검의 몫은 오히려 커졌습니다. 공개 전에 최소한 다음은 사람이 직접 확인해야 합니다.

• 모바일에서의 실제 모습 — 좁은 화면에서 제목이 어색하게 줄바꿈되지 않는지, 고정되는 섹션이 손가락 스크롤에서도 자연스러운지 확인합니다.
• 영상과 이미지의 무게 — 스크롤에 묶인 영상은 화질보다 용량이 중요합니다. 대표 이미지 한 장이 무거우면 첫인상이 통째로 느려집니다. 속도가 매출에 미치는 영향은 생각보다 직접적입니다.
• 대체 텍스트와 키보드 이동 — 생성 이미지에는 설명이 자동으로 붙지 않습니다. 무엇을 담은 장면인지 직접 적어 줘야 합니다.
• 사실 관계 — 숫자, 실적, 자격 정보는 생성 결과를 그대로 두면 안 됩니다. 원문 자료와 대조합니다.

정리하면, 순서가 곧 품질입니다

디자인을 먼저 끝내고, 없는 소재는 만들어서 채우고, 완성된 화면을 코드로 넘기고, 움직임은 조건으로 지시하고, 연속된 결과물은 끝 그림부터 정합니다. 이 다섯 가지 순서만 지켜도 AI로 만든 사이트는 “빠르게 만든 것”이 아니라 “제대로 만든 것”이 됩니다.

ononc는 이 흐름 그대로 브랜드 사이트를 설계하고 구현합니다. 사진이나 영상 소재가 아직 없는 단계여도 괜찮습니다. 어떤 장면이 필요한지부터 함께 정리해 드립니다. 프로젝트 상담에서 지금 상황을 알려 주세요.