작은 프로젝트로 완성하는 나만의 Next.js 사이트

2026-07-09Views 2약 9분생성형 AI 활용

Summary

이제 하나의 결과물로 묶을 차례입니다

지금까지 우리는 Next.js의 여러 조각을 배웠습니다. app/page.tsx를 바꾸면 첫 화면이 달라지고, 폴더를 만들면 새 페이지가 생기고, 컴포넌트로 반복 화면을 정리할 수 있었습니다. 이미지, 폰트, SEO, 폼, 에러 확인, 배포까지도 살펴보았습니다.

이 장의 목표는 새 기술을 더 배우는 것이 아닙니다. 흩어져 있던 조각을 모아 실제로 공개할 수 있는 작은 사이트 하나를 완성하는 것입니다.

처음부터 큰 사이트를 만들려고 하면 쉽게 지칩니다. 회원가입, 결제, 예약, 관리자 페이지까지 한 번에 넣으려 하면 대부분 중간에 멈춥니다. 이번 프로젝트는 작게 시작합니다. 방문자가 누구인지, 무엇을 보여 줄지, 어떤 행동을 하게 할지만 분명히 정합니다.

작은 프로젝트로 완성하는 나만의 Next.js 사이트 AI 생성 이미지

만들 사이트의 주제 고르기

먼저 하나를 고릅니다.

개인 포트폴리오
동네 가게 소개 사이트
강의 또는 클래스 랜딩페이지

셋 중 무엇을 골라도 구조는 비슷합니다. 핵심은 '내가 누구인지', '무엇을 제공하는지', '왜 믿을 만한지', '어떻게 연락하면 되는지'를 보여 주는 것입니다.

예를 들어 개인 포트폴리오라면 이렇게 정리할 수 있습니다.

대상: 나를 채용하거나 협업하고 싶은 사람
목적: 작업물과 소개를 보고 연락하게 만들기
핵심 내용: 소개, 주요 프로젝트, 가능한 일, 연락처
방문자의 행동: 이메일 보내기 또는 문의하기

동네 가게 소개 사이트라면 조금 달라집니다.

대상: 근처에서 가게를 찾는 손님
목적: 위치, 메뉴, 분위기, 운영 시간을 쉽게 확인하게 하기
핵심 내용: 대표 메뉴, 사진, 주소, 영업시간, 문의 방법
방문자의 행동: 전화하기, 지도 보기, 방문하기

강의 랜딩페이지라면 목적이 더 분명합니다.

대상: 강의를 들을지 고민하는 사람
목적: 강의의 장점과 커리큘럼을 보고 신청하게 만들기
핵심 내용: 문제 제기, 강의 소개, 대상자, 커리큘럼, 후기, 신청 안내
방문자의 행동: 신청 버튼 누르기

이번 실습에서는 어떤 주제를 골라도 적용할 수 있도록 '작은 소개 사이트' 구조로 진행하겠습니다. 여러분은 문구와 이미지만 자신의 주제에 맞게 바꾸면 됩니다.

최소 사이트맵 만들기

사이트맵은 웹사이트의 방 목록입니다. 집을 짓기 전에 방을 정하는 것처럼, 코드를 만들기 전에 페이지를 먼저 정해야 합니다.

이번 사이트는 네 페이지로 충분합니다.

페이지	주소	역할
홈	`/`	첫인상, 핵심 소개, 주요 버튼
소개	`/about`	사람, 브랜드, 가게, 강의의 배경 설명
서비스	`/services`	제공하는 일, 메뉴, 강의 구성, 프로젝트 목록
문의	`/contact`	연락처, 문의 폼, 이메일, 전화번호

처음에는 블로그, 후기, 공지사항, 상세 페이지를 모두 넣고 싶을 수 있습니다. 하지만 첫 번째 공개 버전에서는 참는 것이 좋습니다. 사이트는 완성되어야 의미가 있습니다. 작게 공개한 뒤 필요한 페이지를 하나씩 추가하면 됩니다.

폴더 구조는 이렇게 생각하면 됩니다.

app/
  page.tsx
  about/
    page.tsx
  services/
    page.tsx
  contact/
    page.tsx
components/
  Header.tsx
  Footer.tsx
  ServiceCard.tsx
  ContactSection.tsx
data/
  services.ts
public/
  hero.jpg
  logo.svg

여기서 app은 페이지 방을 만드는 곳입니다. components는 재사용할 부품을 모아 두는 곳입니다. data는 서비스 목록처럼 자주 바뀌는 내용을 따로 보관하는 곳입니다. public은 이미지와 로고를 넣는 창고입니다.

공통 헤더와 푸터부터 조립하기

작은 사이트라도 상단 메뉴와 하단 정보는 거의 모든 페이지에 반복됩니다. 이 반복되는 부분을 매번 복사하지 말고 컴포넌트로 만듭니다.

헤더에는 보통 로고와 메뉴가 들어갑니다.

로고 또는 사이트 이름
홈
소개
서비스
문의

푸터에는 사이트 하단에 필요한 기본 정보를 넣습니다.

이름 또는 브랜드명
이메일
간단한 저작권 문구
SNS나 외부 링크가 있다면 한두 개

이 두 컴포넌트는 app/layout.tsx에 넣으면 모든 페이지에 공통으로 보입니다. 액자 안에 사진을 바꿔 끼우는 것처럼, layout.tsx는 고정된 액자이고 각 페이지는 그 안에 들어가는 사진입니다.

처음부터 멋진 메뉴 애니메이션을 만들 필요는 없습니다. 중요한 것은 방문자가 어디에 있고, 어디로 갈 수 있는지 알게 하는 것입니다. 비개발자가 직접 관리하는 사이트라면 단순한 메뉴가 오히려 안전합니다.

홈 화면은 세 부분이면 충분합니다

홈 화면은 방문자가 가장 먼저 보는 문입니다. 모든 정보를 다 넣기보다 핵심만 보여 줍니다.

카드 목록으로 서비스 정리하기

서비스, 메뉴, 강의 구성, 프로젝트 목록처럼 반복되는 정보는 카드로 정리하면 보기 쉽습니다. 카드란 하나의 정보를 담는 작은 박스입니다. 명함을 여러 장 펼쳐 놓은 것처럼, 같은 구조 안에 제목과 설명만 바꿔 넣습니다.

예를 들어 data/services.ts에는 이런 항목을 넣을 수 있습니다.

export const services = [
  {
    title: '브랜드 소개 페이지',
    description: '처음 방문한 사람이 브랜드의 분위기와 핵심 메시지를 빠르게 이해하도록 구성합니다.',
  },
  {
    title: '콘텐츠 구조 정리',
    description: '반복되는 글, 서비스, 공지사항을 관리하기 쉬운 형태로 정리합니다.',
  },
  {
    title: '문의 흐름 개선',
    description: '방문자가 망설이지 않고 이메일이나 문의 폼으로 이어지도록 화면을 다듬습니다.',
  },
]

그리고 ServiceCard 컴포넌트는 같은 디자인의 박스를 담당합니다. 페이지에서는 services 목록을 불러와 카드로 반복해서 보여 줍니다.

이 구조의 장점은 분명합니다. 서비스가 하나 늘어나도 화면 코드를 크게 고칠 필요가 없습니다. data/services.ts에 항목만 추가하면 카드가 하나 더 생깁니다.

비개발자가 직접 수정하기 좋은 부분도 바로 이런 데이터 파일입니다. 제목, 설명, 순서, 문구는 직접 바꿔 볼 수 있습니다. 반대로 카드의 복잡한 동작, 외부 데이터 연결, 관리자 화면 제작은 전문가에게 맡기는 편이 안전합니다.

문의 페이지는 단순하고 믿을 수 있어야 합니다

문의 페이지의 역할은 방문자의 마지막 망설임을 줄이는 것입니다. 멋진 디자인보다 명확한 정보가 더 중요합니다.

문의 페이지에는 다음 요소를 넣습니다.

어떤 문의를 받는지
답변까지 보통 얼마나 걸리는지
이메일 주소
전화번호 또는 SNS가 필요하다면 추가
간단한 문의 폼

문의 폼은 너무 많은 정보를 요구하지 않는 것이 좋습니다. 처음부터 회사명, 직책, 예산, 일정, 주소, 상세 파일까지 요구하면 방문자는 제출을 포기할 수 있습니다.

첫 버전에서는 네 항목이면 충분합니다.

이름
이메일
문의 내용
개인정보 동의 문구

이 책에서 만든 간단한 폼은 화면에서 제출 완료 메시지를 보여 주는 수준이었습니다. 실제 이메일 발송이나 데이터 저장이 필요하다면 선택지가 있습니다.

아주 단순하게는 mailto: 링크를 사용하기
폼 서비스를 연결하기
Next.js 서버 기능이나 외부 백엔드를 사용하기

개인정보를 저장하거나 여러 사람이 문의를 관리해야 한다면 직접 처리하지 말고 검증된 서비스나 전문가의 도움을 받는 것이 좋습니다. 문의 기능은 작아 보여도 개인정보와 스팸 문제가 함께 따라옵니다.

배포 전 체크리스트

사이트가 어느 정도 완성되면 바로 배포하지 말고 한 번 점검합니다. 체크리스트는 실수를 줄이는 안전망입니다.

1. 내용 점검

첫 화면에서 무엇을 하는 사이트인지 바로 보이는가?
오타가 없는가?
연락처가 정확한가?
임시 문구가 남아 있지 않은가?
모든 버튼과 링크가 원하는 곳으로 이동하는가?

특히 준비 중, 테스트, 아무 문구, lorem ipsum 같은 임시 문구가 남아 있지 않은지 확인합니다.

2. 이미지 점검

이미지는 public 폴더에 있는가?
파일명이 영어 소문자와 하이픈 중심으로 되어 있는가?
너무 큰 원본 이미지를 그대로 쓰고 있지 않은가?
중요한 이미지는 alt 설명이 있는가?
모바일 화면에서 이미지가 잘리지 않는가?

이미지는 사이트의 신뢰감을 크게 좌우합니다. 흐릿한 로고, 너무 어두운 사진, 깨진 이미지는 사이트 전체를 미완성처럼 보이게 만듭니다.

3. SEO와 공유 정보 점검

app/layout.tsx 또는 각 페이지의 metadata를 확인합니다.

사이트 제목이 실제 이름으로 되어 있는가?
설명 문장이 검색 결과에 보여도 어색하지 않은가?
페이지마다 제목이 구분되는가?
파비콘이 설정되어 있는가?
공유 이미지가 필요하다면 준비되어 있는가?

SEO는 검색엔진 최적화입니다. 어렵게 생각할 필요는 없습니다. 검색 결과나 카카오톡, 슬랙 같은 공유 화면에서 '무슨 사이트인지' 제대로 보이게 하는 기본 정보라고 이해하면 됩니다.

4. 모바일 화면 점검

방문자는 PC보다 휴대폰으로 먼저 볼 가능성이 큽니다. 브라우저 창을 좁혀 보거나 개발자 도구의 모바일 화면을 켜서 확인합니다.

메뉴가 너무 좁지 않은가?
글자가 작아 읽기 어렵지 않은가?
버튼을 손가락으로 누르기 쉬운가?
카드가 화면 밖으로 삐져나가지 않는가?
문의 폼 입력칸이 너무 작지 않은가?

모바일에서 불편한 사이트는 방문자가 오래 머물기 어렵습니다. 디자인이 조금 단순해져도 읽기 쉽고 누르기 쉬운 쪽이 낫습니다.

5. 기본 에러 점검

배포 전에는 터미널과 브라우저를 모두 확인합니다.

npm run dev가 정상 실행되는가?
브라우저에 빨간 에러 화면이 없는가?
터미널에 반복되는 에러가 없는가?
import 경로가 깨진 파일은 없는가?
대소문자가 다른 파일명은 없는가?

가능하다면 배포 전에 한 번 npm run build도 실행해 봅니다. 개발 서버에서는 괜찮아 보였지만 실제 배포용으로 만들 때 드러나는 문제가 있을 수 있습니다. 에러가 나오면 겁내지 말고 파일명, 줄 번호, 핵심 문장을 먼저 찾습니다.

Vercel에 공개하기

점검이 끝났다면 이제 공개할 차례입니다. 흐름은 단순합니다.

로컬에서 마지막으로 확인합니다.
변경 내용을 commit합니다.
GitHub에 push합니다.
Vercel이 자동으로 배포합니다.
발급된 주소로 접속해 실제 화면을 확인합니다.

배포 후에는 반드시 공개 주소에서 다시 확인해야 합니다. localhost:3000에서 보이는 것과 실제 배포 주소에서 보이는 것이 다를 수 있습니다. 특히 이미지 경로, 환경 변수, 외부 링크, 대소문자 문제는 배포 후에 발견되는 경우가 있습니다.

공개 주소가 생겼다면 주변 사람 한두 명에게 보내 보세요. 설명하지 말고 사이트만 보내는 것이 좋습니다. 상대가 첫 화면만 보고 무엇을 하는 사이트인지 이해한다면 방향이 맞습니다. 설명을 많이 해야 이해한다면 첫 문장과 메뉴를 다시 다듬어야 합니다.

운영 노트 만들기

사이트는 배포가 끝이 아닙니다. 공개한 뒤부터 운영이 시작됩니다. 운영을 어렵게 만들지 않으려면 작은 노트를 만들어 둡니다.

운영 노트에는 이런 내용을 적습니다.

사이트 주소
GitHub 저장소 주소
Vercel 프로젝트 이름
수정할 때의 순서: 로컬 확인 → commit → push → 배포 확인
자주 바꾸는 파일: data/services.ts, app/page.tsx, app/contact/page.tsx
건드리지 않는 파일: 설정 파일, 비밀 값 파일, 잘 모르는 외부 연동 코드
다음에 추가하고 싶은 기능 목록

다음 기능 목록은 욕심이 아니라 순서가 중요합니다. 예를 들어 이렇게 나눌 수 있습니다.

1순위: 문구 다듬기, 사진 교체, 문의 버튼 개선
2순위: 후기 섹션 추가, 자주 묻는 질문 추가
3순위: 블로그, CMS, 예약 기능, 결제 기능

1순위는 비개발자도 직접 할 수 있는 일이 많습니다. 2순위는 구조를 이해한 뒤 조심해서 추가할 수 있습니다. 3순위는 데이터 저장, 보안, 결제, 관리자 기능이 얽힐 수 있으므로 전문가와 상의하는 편이 안전합니다.

완성의 기준은 크기가 아니라 공개입니다

좋은 첫 사이트는 거창하지 않아도 됩니다. 네 페이지짜리 사이트라도 목적이 분명하고, 모바일에서 잘 보이고, 문의 방법이 정확하다면 충분히 가치가 있습니다.

이번 프로젝트에서 꼭 남겨야 할 감각은 이것입니다.

페이지는 app 폴더의 구조로 만든다.
반복되는 화면은 컴포넌트로 정리한다.
자주 바뀌는 내용은 데이터 파일로 분리한다.
이미지는 public에 넣고 경로를 확인한다.
제목과 설명은 metadata로 챙긴다.
배포 전에는 모바일, 링크, 에러를 확인한다.
수정은 작게 하고 commit으로 되돌아갈 지점을 만든다.

Next.js를 배운다는 것은 모든 코드를 외운다는 뜻이 아닙니다. 내가 만들고 싶은 사이트를 작은 단위로 나누고, 어디를 고치면 무엇이 바뀌는지 이해하는 것입니다.

이제 여러분에게는 시작할 수 있는 기준이 있습니다. 작은 사이트를 하나 만들고, 공개하고, 반응을 보고, 다시 고치면 됩니다. 그 반복이 실력입니다.

책 목록

비개발자를 위한 Next.js 입문

전체 목차 보기