컴포넌트란? 2026 바이브 코딩 컴포넌트 비개발자가 부딪히며 배운 코드 재사용 방법

컴포넌트란 버튼이나 카드처럼 반복해서 쓰는 코드를 하나의 부품으로 만들어 여러 화면에서 다시 사용하는 방식입니다. 지금은 이렇게 설명할 수 있지만, 바이브 코딩을 처음 시작했을 때는 같은 모양이면 당연히 같은 코드라고 생각했습니다. 바이브 코딩 컴포넌트에 중요성을 몰랐습니다.

필요한 기능을 말하면 AI가 버튼 하나쯤은 금방 만들어줬습니다. 비슷한 화면도 빠르게 늘릴 수 있었죠. 기능이 몇 개 없을 때는 이 방식이 꽤 잘 통하는 것처럼 보였습니다.

문제는 수정할 일이 생기면서 시작됐습니다. 한 화면의 버튼을 고쳤는데 다른 화면에는 예전 모습이 그대로 남았습니다. 겉모양만 비슷할 뿐 실제로 같은 코드를 쓰고 있지 않았기 때문입니다.

여기저기 흩어진 코드를 찾아 같은 수정을 반복하고 나서야 ‘컴포넌트로 조립한다’는 말의 뜻을 조금씩 이해하게 됐습니다.

같은 버튼인데 한 번에 바뀌지 않았다

겉모양이 같아도 코드는 복사본일 수 있다

처음에는 화면마다 필요한 버튼을 그때그때 만들었습니다. 시험 삼아 만들어보자는 생각으로 몇 줄만 요청해도 결과가 바로 나오니 코드가 서로 연결돼 있는지까지는 살피지 않았습니다.

화면에서 보면 모두 같은 버튼처럼 보입니다. 하지만 각 페이지에 비슷한 코드를 따로 작성했다면 서로 연결된 부품이 아니라 각각의 복사본에 가깝습니다. 한쪽의 모양이나 동작을 바꿔도 다른 버튼에는 자동으로 반영되지 않습니다.

실제로 한 화면을 고친 뒤 다른 페이지를 열어보면 이전 모양이 그대로 남아 있었습니다. 겉으로 같아 보이는 것과 하나의 코드를 함께 쓰는 것은 전혀 다른 문제였습니다.

수정할 때마다 같은 작업이 늘어났다

수정은 한 번으로 끝나지 않았습니다. 한 곳을 고치고 다른 화면을 확인한 다음, 그곳에서도 같은 내용을 다시 바꿔야 했습니다. 또 다른 페이지에서 같은 버튼을 발견하면 작업이 한 번 더 늘어났습니다.

수정할 위치를 하나라도 빠뜨리면 같은 서비스 안에서 버튼의 모양이나 동작이 달라집니다. 기능을 빠르게 만들며 아낀 시간을 나중에 반복 수정으로 다시 쓰는 셈이었습니다.

비슷하게 생긴 코드를 여러 번 만드는 것과 하나의 코드를 여러 곳에서 가져다 쓰는 방식은 달랐습니다. 이 차이를 겪고 나서 컴포넌트가 필요한 이유를 알게 됐습니다.

컴포넌트란? 다시 쓰는 코드 부품

제게는 컴포넌트를 레고 부품에 빗댄 설명이 가장 이해하기 쉬웠습니다. 버튼이나 카드처럼 자주 쓰는 코드를 하나의 부품으로 준비해 두고, 필요한 화면에서 가져다 조립하는 방식입니다.

공통 부분은 공유하고 필요한 값만 바꾼다

같은 버튼이 여러 곳에 필요하다면 화면마다 새로 만들 이유가 없습니다. 공통 버튼을 하나 만들고 문구나 눌렀을 때의 동작만 다르게 지정하면 됩니다.

버튼의 기본 모양과 배치는 하나의 컴포넌트가 맡습니다. 화면마다 달라지는 문구와 동작은 필요한 값으로 전달합니다. 공통 기준과 화면별 차이를 나누면 하나의 부품을 여러 상황에서 다시 쓸 수 있습니다.

여러 화면이 같은 부품을 공유하면 수정할 곳도 줄어듭니다. 컴포넌트 하나를 고치면 그 버튼을 가져다 쓴 화면에 변경 사항이 함께 반영되기 때문입니다.

모든 코드를 잘게 나누는 것은 아니다

컴포넌트란 코드를 무조건 잘게 쪼개는 기술은 아니었습니다. 반복되는 부분을 한곳에 모으는 방법에 더 가까웠습니다.

한 번만 쓰는 짧은 코드까지 모두 분리하면 오히려 여러 파일을 오가며 확인해야 합니다. 같은 모양이나 기능이 반복되거나 하나의 역할을 따로 설명할 수 있을 때 나누는 편이 이해하기 쉽습니다.

레고도 모든 조각을 더 작게 부수는 것이 목적은 아닙니다. 다시 가져다 쓸 수 있는 크기의 부품을 만들고 필요한 자리에 조립한다는 점이 중요합니다.

페스티봄 시간표를 네 단계로 나눈 방법

컴포넌트의 장점이 가장 와닿은 곳은 페스티벌 상세 페이지의 시간표였습니다. 날짜와 무대, 아티스트, 공연 시간, 일정 선택 버튼까지 한 화면에 모여 있어서 수정할 내용도 많았습니다.

큰 시간표 안에 작은 부품을 넣었다

현재 페스티봄 시간표는 역할에 따라 네 단계로 나뉘어 있습니다.

FestivalTimetable: 날짜와 무대별로 출연진을 묶어 시간표 전체를 구성
StageSchedule: 무대 이름과 해당 무대에 출연하는 아티스트 목록
ArtistScheduleRow: 아티스트 이름과 공연 시간, 좋아하는 아티스트 표시
ScheduleItemButton: 일정 선택과 로그인 연결을 담당

큰 시간표 안에 무대가 있고, 그 안에 아티스트 정보와 버튼이 들어가는 구조입니다. 큰 부품부터 작은 부품까지 차례로 조립하는 레고와 닮았습니다.

수정할 위치가 분명해졌다

역할을 나눈 뒤에는 시간표를 다듬는 일이 한결 수월해졌습니다. 무대 제목을 바꿀 때는 StageSchedule, 아티스트 한 줄의 간격이나 공연 시간 표시는 ArtistScheduleRow를 확인하면 됩니다.

일정 선택 버튼의 모양이나 동작은 ScheduleItemButton에서 다룹니다. 버튼 하나를 손보려고 시간표 전체를 뒤지는 대신, 수정하려는 역할에 맞는 컴포넌트부터 찾을 수 있게 됐습니다.

화면을 잘게 나눴다는 사실보다 각 코드가 무슨 일을 맡는지 분명해졌다는 점이 더 크게 느껴졌습니다.

바이브 코딩에서는 기존 컴포넌트부터 확인한다

AI는 새 코드를 빠르게 만들어줍니다. 문제는 프로젝트에 비슷한 부품이 이미 있는데도 매번 새 코드를 요청할 때 생겼습니다.

처음에는 모두 정상적으로 작동해서 차이를 알아차리기 어렵습니다. 화면이 늘어나고 디자인을 수정하기 시작하면 흩어진 코드가 드러납니다. 같은 작업을 몇 번씩 반복하게 되고, 조금씩 달라진 코드 중 무엇이 기준인지 찾기도 어려워집니다.

새 코드를 만들기 전에 재사용할 부분을 찾는다

단순히 “컴포넌트를 잘 나눠줘”라고 말하면 기준이 모호할 수 있습니다. 지금은 새 코드를 만들기 전에 프로젝트에 비슷한 컴포넌트가 있는지 확인하고, 재사용할 부분과 새로 만들 부분을 구분해 달라고 요청합니다.

현재 프로젝트의 기존 컴포넌트를 먼저 확인해줘. 새 화면에서 반복되는 UI는 기존 컴포넌트를 재사용하고, 공통으로 쓸 부분은 컴포넌트로 분리해줘.

이렇게 요청하면 AI가 화면 하나를 완성하는 데 그치지 않고 기존 코드와 연결할 방법부터 살펴보게 할 수 있습니다.

나눌 기준도 함께 생각한다

공통 부품을 만들 시점은 거창하지 않았습니다. 같은 모양이나 기능이 두 번 이상 등장하면 먼저 살펴봅니다. 역할이 분명한 부분을 컴포넌트로 묶어 두면 다음 화면에서는 새로 만드는 대신 가져다 쓸 수 있습니다.

나중에 한꺼번에 고쳐야 할 부분인지도 중요한 기준입니다. 여러 화면에서 같은 기준을 유지해야 한다면 코드를 따로 복사하기보다 하나의 컴포넌트를 공유하는 편이 수정하기 쉽습니다.

반대로 한 번만 사용하고 역할도 따로 나누기 어려운 부분이라면 억지로 분리하지 않습니다. 반복 여부와 역할을 살펴보고 필요한 크기로 나누는 것이 핵심이었습니다.

이후에는 새 화면을 요청하기 전에 기존 컴포넌트로 조립할 수 있는지부터 확인하게 됐습니다.

코드를 계속 만들기보다 조립하는 방법

바이브 코딩을 하며 처음 이해한 코드 구조가 컴포넌트였습니다. 같은 버튼을 여러 번 만들고 같은 수정을 반복해 본 뒤에야 공통 부품이 필요한 이유를 알았습니다.

잘 만든 컴포넌트는 새로운 화면에서도 다시 쓸 수 있습니다. 고칠 곳이 줄고 여러 화면의 모양과 동작도 같은 기준으로 유지하기 쉬워집니다.

AI에게 코드를 계속 새로 만들어 달라고 요청하기보다, 반복해서 쓸 부품을 만들고 필요한 곳에 조립하는 구조부터 생각하는 것. 이 습관이 페스티봄의 코드를 덜 꼬이게 만들고 수정하기 쉽게 바꾼 첫 번째 방법이었습니다.