2025년 10월 10일·7분
바이브 코딩이 AI-퍼스트 도구와 프로토타입에서 유리한 이유
바이브 코딩이 AI-퍼스트 제품, 내부 도구, 프로토타입 작업을 어떻게 가속화하면서도 가드레일, 테스트, 리뷰로 품질을 유지하는지 배우세요.
바이브 코딩이 AI-퍼스트 제품, 내부 도구, 프로토타입 작업을 어떻게 가속화하면서도 가드레일, 테스트, 리뷰로 품질을 유지하는지 배우세요.
“바이브 코딩”은 제품 직관(“그 느낌”)과 AI 보조를 결합해 소프트웨어를 빠르게 만드는 실용적 방식입니다. 당신이 달성하려는 것을 설명하면 LLM이 코드나 UI의 초안을 생성하고, 짧은 반복으로 돌아갑니다: 실행해 보고, 무엇이 깨지는지 확인하고, 프롬프트를 조정하고 계속 진행합니다.
목표는 첫 시도에 완벽한 코드를 얻는 것이 아닙니다. 목표는 빠르게 동작하는 무언가를 만들어 배우는 것입니다: 이 워크플로가 적절한가, 모델 출력이 타당한가, 실제로 누군가 이 기능을 원하나?
전통적 개발은 종종 사전 설계, 상세 티켓, 신중한 구현을 강조합니다. 바이브 코딩은 순서를 뒤집습니다: 얇고 동작하는 조각으로 시작한 뒤 정제합니다. 여전히 엔지니어링 결정은 내리지만, 지금 당장 중요하지 않은 결정은 미룹니다.
이는 구조를 버린다는 뜻이 아닙니다. 속도를 올려주는 곳에만 구조를 적용합니다: 좁은 범위, 빠른 데모, 그리고 검증 가능한 수락 체크(단순하더라도).
노코드 도구는 문제가 해당 도구의 블록에 맞을 때 훌륭합니다. 바이브 코딩은 API, 데이터 모델, 통합, 인증 등 실제 소프트웨어를 여전히 구축한다는 점에서 다릅니다. AI는 플랫폼 제약에 맞추지 않고 코드를 더 빠르게 작성하고 편집하도록 도와줍니다.
실무에서는 바이브 코딩이 종종 “프롬프트-투-코드”로 시작하지만 빠르게 “프롬프트-투-변경”이 됩니다: 모델에게 함수를 리팩터링하라고 하거나 로깅을 추가하라고 하거나 테스트를 생성하라고 하거나 스키마를 재구성하라고 요청합니다.
생각을 건너뛰는 것이 아닙니다. 여전히 명확한 결과, 제약, "작동"의 정의가 필요합니다. 기능을 평범한 언어로 설명할 수 없다면 LLM은 그럴듯해 보이지만 잘못된 문제를 푸는 출력을 기꺼이 생성할 것입니다.
검증을 건너뛰는 것도 아닙니다. 아무도 사용하지 않는 빠른 프로토타입은 실패입니다. 바이브 코딩은 제품 발견을 가속화해야지 대체해서는 안 됩니다.
바이브 코딩은 AI-퍼스트 제품, 내부 도구, 초기 프로토타입에서 특히 빛을 발합니다—여기서는 주요 위험이 "우리가 올바른 것을 만들고 있는가?"입니다. 안전이 중요한 시스템, 규제가 엄격한 도메인, 또는 정확성과 장기 유지보수가 모든 결정을 지배하는 대규모 재작성에는 적합하지 않습니다.
AI-퍼스트 제품은 많은 부분에서 “행동”이 제품이기 때문에 속도의 보상이 큽니다. 일반 앱에서는 요구사항을 사전에 추론할 수 있는 경우가 많습니다: 입력, 규칙, 출력. 그러나 LLM이 개입된 경우 가장 빠른 학습 방법은 실제 시나리오를 실행하고 실제로 무슨 일이 일어나는지 관찰하는 것입니다.
대개 한 번에 한 가지만 시험하지 않습니다. 프롬프트의 작은 변경, 새로운 도구 호출, 다른 UI 어포던스가 전체 경험을 재구성할 수 있습니다. 바이브 코딩은 이 현실에 적합합니다: 워크플로를 스케치하고 즉시 시도한 뒤 관찰을 기반으로 조정합니다.
예를 들어 “이 티켓을 요약해 주세요” 기능은 다음에 따라 달라질 수 있습니다:
출력은 확률적이므로 정확성은 이분법이 아닙니다. 언제 환각을 일으키는지, 언제 거부하는지, 언제 과도하게 추측하는지, 사용자가 어떻게 반응하는지 같은 패턴을 학습합니다. 오늘 30개의 실제 예를 실행해보는 것이 일주일간의 가장자리 사례 논쟁보다 낫습니다.
모델 전환, 온도 변경, 컨텍스트 윈도우 한계 도달, 단일 함수 호출 추가가 놀랍도록 다른 결과를 만들 수 있습니다. 초기에는 완벽한 아키텍처보다 반복 속도가 더 중요합니다—제품이 무엇을 해야 하는지 아직 발견 중이기 때문입니다.
바이브 코딩은 "학습용 프로토타입"을 빠르게 배포하게 도와줍니다: 가치가 어디에 있는지(그리고 위험이 어디에 있는지)를 드러내는 작고 테스트 가능한 흐름들입니다.
내부 도구는 바이브 코딩이 가장 “자연스럽게” 느껴지는 곳입니다: 사용자가 알려져 있고, 위험은 제한적이며, 속도가 품질보다 중요합니다. 사용자가 바로 옆에 앉아 있으면 가설 대신 실제 피드백으로 반복할 수 있습니다.
내부 요청은 종종 막연하게 시작합니다: “승인 자동화할 수 있나요?” 또는 “대시보드가 필요합니다.” 바이브 코딩은 아주 작은 버전—한 화면, 한 보고서, 한 스크립트—을 빠르게 만들어 실제 워크플로를 탐색하게 해줍니다.
유용한 패턴은 사용자가 끝에서 끝까지 거치는 경로를 프로토타입하는 것입니다:
긴 스펙을 작성하는 대신 같은 날 클릭 가능한 화면이나 간단한 스크립트로 요청을 번역하세요. 하드코딩된 데이터로 뒤받침된 “가짜” UI라도 핵심 질문에 답하기엔 충분합니다: 어떤 필드가 필수인가? 누가 승인할 수 있는가? 데이터가 없을 때는 무슨 일이 일어나는가?
내부 프로세스는 예외로 가득합니다: 누락된 ID, 중복 레코드, 매니저 오버라이드, 규정 준수 체크 등. 빠른 프로토타입은 이러한 엣지 케이스를 조기에 노출시키고—또한 아직 없는 데이터와 잊고 있던 승인 절차도 드러냅니다.
5분짜리 데모가 1시간의 조율보다 낫습니다. 사람들은 잘못된 점, 누락된 점, 실제로 의도한 것을 가리키므로 요구사항 해석 대신 사용되는 도구를 만드는 데 더 많은 시간을 쓸 수 있습니다.
초기 프로토타입의 목적은 한 가지 질문에 답하는 것입니다: 이걸 만들 가치가 있는가? 바이브 코딩은 빠르고 신뢰할 수 있는 실험에 최적화되어 있어 훌륭한 선택입니다.
가치 증명을 하는 가장 작은 흐름으로 시작하세요: 입력 → 처리 → 출력. 티켓을 요약하는 도구라면 역할, 대시보드, 설정부터 시작하지 말고: 티켓 붙여넣기 → 요약 받기 → 답장에 복사. 이 핵심 루프가 동작하면 프로토타입은 실감납니다. 나머지는 얇게 유지하세요.
통합은 프로토타입이 종종 멈추는 지점입니다. 먼저 모킹하세요:
가치를 검증한 후에 목을 하나씩 실제 API로 교체하세요. 이렇게 하면 조급한 복잡성 추가를 피하면서 모멘텀을 유지할 수 있습니다.
5–20명 정도의 제한된 사용자에게 자주, 작은 업데이트를 배포하세요. 쉽게 응답할 수 있는 방법을 제공하세요:
각 릴리스를 테스트 가능한 가설로 취급하세요, 이정표가 아니라.
증거 기반의 체크포인트를 설정하세요. 예: “사용자 중 최소 60%가 AI 출력을 많은 수정 없이 선택한다” 또는 “작업당 5분을 절약한다.” 기준을 못 맞추면 워크플로를 피벗하거나 중단하세요. 프로토타입의 성공은 잘못된 것을 만드는 것을 막아준 것만으로도 충분합니다.
바이브 코딩은 속도를 제약으로 삼아야 최적입니다. 목표는 빠른 학습—끝없는 프롬프트 조정과 미완성 기능에 빠지지 않을 만큼의 구조를 유지하는 것입니다.
에디터를 열기 전에 다음을 적어두세요:
AI-퍼스트 기능에서는 추상보다 예제가 우선입니다. “티켓 요약” 대신 10개의 실제 티켓과 수용 가능한 정확한 요약 형식을 사용하세요.
한 페이지로 유지하세요. 포함할 것:
이 스펙은 모델이 제안하는 ‘있으면 좋을’ 확장들을 억제하는 닻이 됩니다.
레포나 공유 드라이브에 가벼운 폴더를 만들어두세요:
LLM에게 코드를 생성하라고 요청할 때 이 폴더에서 예제를 직접 붙여넣으면 모호성이 줄고 결과가 재현 가능해집니다.
바이브 코딩은 많은 마이크로 결정들을 만듭니다: 프롬프트 문구, 도구 선택, UI 문구, 폴백 동작 등. 왜 그런 선택을 했는지를 간단한 로그(README나 /docs/decisions.md)에 남기세요. 미래의 당신과 동료들이 의도적 결정과 우연적 결과를 구별할 수 있습니다.
스펙과 결정 로그의 템플릿이 있다면 내부에 링크해 두세요(예: /blog/vibe-coding-templates)—워크플로가 프로젝트 전반에 일관되게 유지됩니다.
팀이 프롬프트-투-변경 반복을 많이 한다면 전용 플랫폼이 마찰을 줄여줍니다: 더 빠른 루프, 재현 가능한 실행, 안전한 롤백 등.
예를 들어 Koder.ai는 채팅 기반 빌드 워크플로를 중심으로 설계되어 있습니다: 기능을 설명하고 UI와 백엔드 변경을 반복하며 동일한 발판을 계속 깔지 않고도 진행을 유지할 수 있습니다. 또한 소스 코드 내보내기, 배포/호스팅, 커스텀 도메인, 스냅샷과 롤백 지원을 제공해 빠르게 배포하면서도 안전망을 유지할 수 있습니다.
AI-퍼스트 기능은 실제로는 LLM을 중심으로 잘 구조화된 시스템일 때 ‘마법처럼’ 느껴집니다. 가장 빠른 팀들은 실험을 이해 가능하고 업그레이드 가능하게 유지하는 반복 가능한 패턴에 의존합니다.
기능이 매번 실행해야 하는 루프를 먼저 그리세요:
사용자 메시지 → 검색(컨텍스트) → 도구 호출 → 응답.
간단한 스케치라도 필요한 데이터, 언제 도구를 호출할지(CRM 조회, 티켓 생성, 계산 등), 중간 결과를 어디에 저장할지 같은 좋은 결정을 강제합니다. 또한 어떤 부분이 ‘프롬프트 작업’이고 어떤 부분이 ‘시스템 작업’인지 명확해집니다.
프롬프트는 카피라이팅이 아니라 논리입니다. 버전 관리하고, 리뷰하고, 테스트하세요.
실용적 접근은 프롬프트를 레포(또는 구성 저장소)에 보관하고 명확한 이름, 변경 로그, 작은 유닛 스타일 테스트를 두는 것입니다: 입력 X와 컨텍스트 Y가 주어지면 모델은 의도 Z 또는 도구 호출 A를 생성해야 합니다. 이렇게 하면 바이브 코딩이 빠르게 반복되면서도 무엇이 변경되었는지 추적할 수 있습니다.
실사용자는 즉시 엣지 케이스를 밀어넣습니다. 다음에 대한 명시적 동작을 구축하세요:
단순히 나쁜 출력을 피하는 것이 아니라 신뢰를 보호하는 것입니다.
정확한 검색된 컨텍스트, 도구 출력, 프롬프트 버전으로 대화를 재실행할 수 없다면 디버깅은 추측이 됩니다.
루프의 각 단계를 로깅(입력, 검색 문서, 도구 호출, 응답)하고 팀용으로 “재실행” 버튼을 추가하세요. 모호한 피드백을 실행 가능한 수정으로 바꾸고 시간이 지남에 따라 개선을 측정하는 데 도움이 됩니다.
속도가 바이브 코딩의 핵심이지만, 품질이 있어야 실험이 사용 가능해집니다. 트릭은 프로토타입을 전체 엔터프라이즈 빌드로 바꾸지 않으면서 예측 가능한 실패를 잡는 가벼운 가드레일을 추가하는 것입니다.
가장 흔한 프로토타입 실패를 막는 기본을 먼저 도입하세요:
이 가드레일은 저비용으로 대부분의 흔한 프로토타입 실패(무음 중단, 무한 대기, 일관성 없는 포맷팅)를 줄여줍니다.
광범위한 자동화 테스트 대신 골든 셋을 만드세요: 실제 사용을 대표하는 10–30개의 고정 프롬프트(몇 개의 공격적 케이스 포함). 각 프롬프트에 대해 정확한 텍스트 대신 다음과 같은 속성을 정의합니다:
의미 있는 변경이 있을 때마다 골든 셋을 실행하세요. 빠르고 인간이 놓치는 회귀를 잡아냅니다.
프롬프트, 도구 정의, 안전 정책을 버전 관리 자산으로 취급하세요. 차이(diff)와 간단한 리뷰 규칙(가벼운 PR이라도)을 사용해 "무엇이, 왜, 무엇이 망가질 수 있는가"에 답할 수 있도록 하세요.
언제부터 "빨리 가는 것을 멈출지" 적어두세요: 민감 데이터 처리, 유료 사용자 지원, 고빈도 사용, 반복되는 골든셋 실패 등. 어떤 중단 조건이 트리거되면 하드닝, 리팩터, 또는 범위 축소할 시점입니다.
프로토타입은 실데이터를 만나는 순간까지는 괜찮아 보이지만, 흔히 불안정한 서드파티 API, 느린 DB, 일관성 없는 스키마, 권한 문제가 나타납니다. 매주 앱을 재작성하지 않고 통합을 단계적으로 확장하는 것이 요령입니다.
정적 JSON, 로컬 픽스처, 작은 스텁 서버로 목을 먼저 만들어 제품 흐름과 AI 동작을 검증하세요. UX가 유용하다고 증명되면 동일한 인터페이스 뒤에 실제 통합을 끼워 넣으세요. 실제 트래픽과 엣지 케이스를 본 후에만 재시도, 요청률 제한, 관찰성, 백필(backfill) 같은 하드닝에 투자하세요.
이 방법은 초기 학습을 일찍 배포하면서 “통합 비용”을 증거에 비례하게 만듭니다.
외부 서비스는 변하고, 프로토타입은 일회성 호출들이 흩어지기 쉽습니다. 대신 서비스별 얇은 래퍼(예: PaymentsClient, CRMClient, VectorStoreClient)를 만들어 앱이 사용하는 작은 안정적 메서드 집합을 노출하세요.
그 래퍼는 다음을 바꾸는 교환점이 됩니다:
프로토타입이라도 자격 증명은 안전하게 다루세요: 환경 변수, 시크릿 매니저, 최소 권한 API 키 사용. 토큰을 레포에 커밋하거나 프롬프트에 붙여넣거나 고객 데이터를 포함한 원시 요청 페이로드를 로깅하는 일을 피하세요.
프롬프트 변경, 모델 업데이트, 새로운 컨텍스트 소스로 AI 출력은 달라질 수 있습니다. 새로운 AI 동작은 기능 플래그 뒤에 두어:
기능 플래그는 위험한 변경을 통제된 실험으로 바꿉니다—프로토타입에서 제품으로 가는 길에 꼭 필요한 도구입니다.
바이브 코딩은 모멘텀을 보상합니다. 리팩터는 유용할 때만 하세요—진행을 막지 않는 "정리 작업"으로 모멘텀을 갉아먹지 않게 합니다. 좋은 규칙: 현재 구조가 여전히 당신이 배우고, 배포하고, 팀을 지원하게 해준다면 놔두세요.
큰 리팩터를 피하세요. 진행을 실제로 늦추는 상황에서만 작은 표적 개선을 하세요:
리팩터 시 범위를 좁혀 한 병목을 개선하고 배포한 뒤 다음으로 이동하세요.
초기에는 프롬프트 텍스트, 도구 정의, UI 배선이 가까이 붙어 있어도 괜찮습니다. 패턴이 반복되면 모듈을 추출하세요:
실용적 신호: 같은 로직을 두 번 복사했다면 모듈화할 준비가 된 것입니다.
AI-퍼스트 기능은 눈에 띄지 않는 방식으로 실패합니다. 초기부터 기본 관찰성(오류율, 도구 성공률, 지연, 작업당 비용)을 추가하세요. 비용이 폭등하거나 도구 호출이 자주 실패하면 사용성 및 예산에 직접적 영향을 미치므로 리팩터 트리거입니다.
짧은 부채 목록을 유지하고 각 항목에 명확한 트리거를 적으세요(예: “세 번째 도구를 추가하면 도구 라우터 리팩터” 또는 “두 사람이 매주 프롬프트를 편집하면 코드에서 프롬프트 분리”). 이렇게 하면 부채가 보이면서 로드맵을 장악하지 않게 됩니다.
바이브 코딩은 속도가 완벽한 아키텍처보다 중요할 때, 특히 목표가 학습인 탐색적 작업에서 최상의 결과를 냅니다. 사용자 눈에 띄는 품질이 부차적이고 가끔 거친 부분을 허용할 수 있다면 복합적인 이득을 얻을 수 있습니다.
내부 도구는 이상적입니다. 좋은 후보:
코드가 영구적이지 않아도 가치 있는 것들:
실수에 현실적 피해나 계약상 위험이 있는 시스템에는 바이브 코딩을 피하세요:
시작하기 전에 물어보세요:
배포, 관찰, 롤백이 안전하면 바이브 코딩은 대체로 승리입니다.
바이브 코딩은 빠르지만 속도 때문에 피할 수 있는 실수를 숨길 수 있습니다. 다행히도 대부분의 함정은 간단하고 반복 가능한 해결책이 있습니다—특히 AI-퍼스트 도구와 프로토타입의 경우.
가상의 입력으로 프롬프트와 흐름을 설계하면 데모는 좋아 보여도 실제 사용에서는 실패합니다.
고치기: 최적화 전에 20–50개의 실제 사례를 수집하세요. 지원 티켓, 스프레드시트, 통화 노트, 그림자 관찰에서 뽑아 평가 세트(표면도 괜찮음)를 만드세요: 입력, 기대 출력, “충분히 좋음” 기준, 엣지 케이스 노트.
프롬프트는 빠르게 불어나 한 사람이 어떤 프롬프트가 중요한지 모르게 됩니다.
고치기: 프롬프트를 제품 자산으로 취급하세요. 명확한 네이밍, 짧은 템플릿, 리뷰 규칙을 사용합니다.
feature.goal.version (예: summarize.followup.v3)모델은 거부하거나 환각하거나 타임아웃을 일으키거나 오해할 수 있습니다. UX가 완벽을 전제로 하면 사용자는 빠르게 신뢰를 잃습니다.
고치기: 우아한 열화와 사람으로의 이관 계획을 세우세요. “다시 시도”, “단순 모드 사용”, “팀원에게 전송” 옵션을 제공하고 사용자가 다시 입력하지 않도록 충분한 컨텍스트를 저장하세요.
토큰 사용량이 확장 시 가장 큰 문제가 될 수 있습니다.
고치기: 일찍 측정하세요. 요청당 토큰을 로깅하고 반복되는 컨텍스트는 캐시하며 제한을 두세요(최대 입력 크기, 최대 도구 호출 수, 타임아웃). 비용이 급증하면 재무팀이 알기 전에 알아차릴 수 있습니다.
한 달이면 바이브 코딩이 팀의 속도를 높이는지 아니면 잡음을 생성하는지 알기 충분합니다. 목표는 “앱 하나를 만드는 것”이 아니라 프롬프트, 코드, 실사용이 무엇을 만들어야 하는지 가르쳐주는 촘촘한 피드백 루프를 만드는 것입니다.
고빈도 워크플로 하나를 선택하세요(예: “지원 티켓 요약”, “영업 후속 초안”, “문서 태깅”). 누가, 무엇이, 어떻게 개선되는지를 한 문단으로 정의하고 측정 방법을 적으세요.
핵심 루프를 엔드투엔드로 증명하는 가장 작은 동작 데모를 빌드하세요. UI 다듬기는 피하고 학습을 최적화하세요: 모델이 신뢰할 수 있게 쓸만한 출력을 내는가?
“괜찮아 보였다”를 증거로 바꾸세요. 다음을 추가하세요:
이 주가 데모 마법이 우연한 프로덕션 위험으로 변하는 것을 막습니다.
하나의 실제 시스템(티켓, CRM, 문서, DB)을 통합하고 5–15명의 내부 사용자에게 배포하세요. 범위를 좁게 유지하고 피드백을 한 곳에 모으세요(전용 Slack 채널 + 주 20분 리뷰).
사용자가 AI를 수정하는 지점, 멈추는 지점, 지속적으로 필요한 데이터 필드를 관찰하세요.
한 달이 끝나면 명확한 결정을 내리세요:
프로덕션화를 선택하면 도구가 빠른 반복과 안전한 변경 관리를 동시에 지원하는지(버전된 프롬프트, 배포/롤백, 재현 가능한 환경)를 고려하세요. Koder.ai 같은 플랫폼은 채팅 기반 웹/서버/모바일 빌드, 스코핑을 위한 계획 모드, 실험 실패 시 빠른 롤백을 위한 스냅샷 등 그 루프를 중심으로 설계되어 있습니다.
승리는 더 큰 프로토타입이 아니라 사용에 기반한 결정입니다.
바이브 코딩은 AI를 이용해 코드 초안과 수정을 빠르게 생성하고, 명확한 제품 목표로 방향을 잡으며 반복해 나가는 빠른 개발 방식입니다.
첫 시도부터 완벽한 구현을 얻는 것보다 빨리 학습하는 것(이게 동작하는가, 누군가 원하나?)에 초점을 맞춥니다.
최소한의 루프는 다음과 같습니다:
여전히 사고와 구조가 필요합니다: 제약 조건, "작동"의 정의, 실제 사용자 검증 등입니다.
바이브 코딩은 명확한 결과 없이 사용할 변명이 될 수 없습니다. 목표가 불분명하면 모델은 그럴듯하게 보이지만 잘못된 문제를 푸는 출력을 생성할 수 있습니다.
노코드 플랫폼은 그 플랫폼의 블록에 맞춰야 합니다.
바이브 코딩은 여전히 실제 소프트웨어(API, 인증, 통합, 데이터 모델 등)를 만드는 방식이며, AI는 코드를 더 빨리 쓰고 바꾸도록 도와줄 뿐 엔지니어링 통제를 대체하지 않습니다.
AI-퍼스트 기능은 확률적이고 행동 중심적이어서 실제 시나리오로 실행해 보는 것이 가장 빠른 학습 방법입니다.
프롬프트 문구, 온도 설정, 모델 선택, 도구 호출, 컨텍스트 크기 같은 작은 변화가 결과를 크게 바꿀 수 있어 반복 속도가 특히 중요합니다.
내부 도구는 피드백 루프가 짧고 위험이 제한적이며 시간 절약 효과가 분명합니다.
따라서 거칠지만 동작하는 흐름을 배포해 바로 데모하고, 긴 스펙 작성 대신 구체적 피드백으로 개선하기가 쉽습니다.
엔드투엔드의 ‘행복 경로’에 집중하세요: 입력 → 처리 → 출력.
다른 요소들은 얇게 유지하고 통합은 목(mock)으로 먼저 검증하세요. 가치가 증명되면 목을 하나씩 실제 API로 바꿉니다.
다음과 같은 가벼운 가드레일로 흔한 실패를 막으세요:
의미 있는 프롬프트나 코드 변경 후에는 10–30개의 실제 사례로 구성된 골든셋을 실행해 회귀를 잡아냅니다.
단계적으로 진행하세요: 목(mock) → 실제 → 견고화(hardened).
서비스별로 얇은 래퍼(예: PaymentsClient, CRMClient, VectorStoreClient)를 만들어 모의 구현에서 실제로, 그리고 나중에 재시도/캐시/정규화 등을 추가하면서 교체하세요.
큰 리팩터링은 피하고, 진행을 막을 때만 리팩터하세요. 다음과 같은 경우 리팩터를 고려합니다:
같은 로직을 두 번 복사했다면 모듈(프롬프트 라이브러리, 도구 레이어, 재사용 UI 컴포넌트)로 추출할 신호입니다.