안드로이드 앱 바이브 코딩의 첫 단계는 코드를 생성하는 일이 아닙니다. 만들고 싶은 생각을 실제 사용자가 겪는 문제로 바꾸고, 그 문제가 앱으로 해결할 가치가 있는지 확인한 다음, 코딩 에이전트가 오해 없이 실행할 수 있는 MVP 문서로 정리하는 일입니다. 이 글에서는 ChatGPT를 단순한 아이디어 생성기가 아니라 조사 질문을 만들고 가설을 반박하며 개발 범위를 줄이는 기획 파트너로 사용하는 방법을 정리합니다.
이 글은 안드로이드 개발 경험이 많지 않지만 AI 코딩 도구를 이용해 첫 앱을 만들려는 개인 개발자와 메이커를 대상으로 합니다. 필요한 것은 막연하게라도 해결하고 싶은 문제 하나, ChatGPT처럼 대화를 이어갈 수 있는 AI 도구, 그리고 답변을 사실로 받아들이지 않고 직접 확인하려는 태도입니다. 아직 Android Studio를 설치하지 않았거나 Kotlin과 Jetpack Compose를 잘 몰라도 괜찮습니다. 이 단계의 산출물은 소스 코드가 아니라 검증된 문제 정의와 현실적인 첫 출시 설계도이기 때문입니다.
왜 코딩보다 아이디어 검증이 먼저인가
바이브 코딩은 화면과 기능을 빠르게 만들어 줍니다. 바로 그 속도 때문에 잘못된 방향으로도 빠르게 달릴 수 있습니다. 구현 가능한 기능과 사용자가 원하는 제품은 서로 다릅니다. 예를 들어 사진을 자동으로 분류하는 앱을 떠올렸다고 해도, 사용자가 정말 별도 앱을 설치할 만큼 불편한지, 운영체제와 갤러리 앱이 이미 같은 문제를 해결하는지, 사진 접근 권한 때문에 심사와 신뢰 비용이 커지는지부터 살펴봐야 합니다. 이 질문 없이 코딩을 시작하면 며칠 뒤 완성된 화면은 남지만 출시 이유는 사라질 수 있습니다.
좋은 첫 단계는 아이디어를 칭찬받는 시간이 아니라 아이디어가 실패할 이유를 먼저 찾는 시간입니다. 예상 사용자가 누구인지, 지금은 어떤 대안으로 문제를 버티는지, 경쟁 앱에 돈을 내는지, 반복되는 불만이 무엇인지 확인해야 합니다. 해결할 문제가 자주 발생하지 않거나 기존 대안이 충분히 편하다면 기능을 더 얹기보다 아이디어를 바꾸는 편이 저렴합니다. 반대로 작지만 명확한 불편이 반복되고 기존 앱의 리뷰에 같은 불만이 쌓여 있다면 작은 앱도 충분한 출발점이 됩니다.
1단계: ChatGPT로 앱 아이디어를 구체화하기
처음부터 기능 목록을 길게 작성하지 않습니다. 먼저 “누가 어떤 상황에서 무엇 때문에 불편한가”를 한 문장으로 적습니다. “일정을 관리하는 앱”보다 “교대 근무자가 매달 달라지는 근무표를 빠르게 입력하고 가족과 공유하도록 돕는 앱”이 좋습니다. 대상과 상황이 들어가면 ChatGPT도 일반적인 할 일 목록을 반복하는 대신 실제 경쟁 범위, 필요한 데이터, 공유 방식과 알림 제약을 구체적으로 검토할 수 있습니다.
첫 대화에서는 앱이 해결하려는 문제, 예상 사용자, 시장성, 경쟁 앱, 기존 앱과의 차별점, Android 구현 가능성, 기술 난이도, 운영과 유지보수 난이도, 수익화 가능성, Google Play 정책상 주의점을 한꺼번에 지도처럼 펼칩니다. 답변이 길어져도 괜찮지만 각 판단에 근거와 불확실성을 표시하도록 요구해야 합니다. 확인되지 않은 다운로드 수나 수익을 단정하지 말고, 추정이라면 추정이라고 표시하고 검증할 검색어와 공식 출처를 함께 달라고 요청합니다.
아이디어 분석에 사용하는 기본 프롬프트
○○ 기능을 제공하는 Android 앱을 개발하려고 합니다.
이 앱이 해결하려는 문제와 예상 사용자를 먼저 한 문장으로 정의해 주세요.
시장성, 주요 경쟁 앱, 기존 앱과 차별화할 수 있는 요소를 분석해 주세요.
Android에서의 구현 가능성, 기술적 난이도, 예상 제약 사항,
운영 및 유지보수 난이도, 수익화 가능성도 함께 검토해 주세요.
Google Play 정책상 주의할 개인정보, 권한, 결제, 광고 항목을 구분해 주세요.
확인하지 못한 사실이나 수치는 추정이라고 표시하고,
제가 직접 검증할 검색어와 공식 출처 후보를 함께 제시해 주세요.한 번의 답변으로 방향을 결정하지 않습니다. 첫 답변은 조사 목차에 가깝습니다. 각 항목에 대해 “그 판단이 틀렸다면 어떤 이유 때문인가”, “이 앱을 설치하지 않을 사용자의 가장 강한 반대 이유는 무엇인가”, “앱 없이 해결하는 현재 대안은 무엇인가”를 다시 질문합니다. AI에게 찬성 역할만 맡기면 기능을 계속 추가하지만 반대 역할을 맡기면 설치 장벽, 신뢰 문제, 데이터 비용, 권한 거부와 같은 실제 위험이 드러납니다.
경쟁 앱과 사용자 리뷰는 최신 자료로 다시 확인하기
경쟁 앱 조사는 ChatGPT가 특히 유용하면서도 주의가 필요한 부분입니다. ChatGPT 검색은 최신 웹 정보를 찾고 출처를 제시할 수 있지만, 검색 시점과 지역에 따라 Play 스토어 노출 결과가 달라지고 앱 이름이나 기능이 변경될 수도 있습니다. 따라서 검색 기능을 명시적으로 사용하게 하고 기준 국가, 조사 날짜, 비교 조건을 프롬프트에 넣습니다. 결과에 포함된 앱은 직접 Play 스토어 링크를 열어 현재 등록 여부, 최근 업데이트, 인앱 구매와 광고 표시, 데이터 보안 설명을 확인합니다.
대한민국 Google Play Store를 기준으로 현재 등록된 유사 앱을 조사해 주세요.
조사 기준일과 각 앱의 Play Store 링크를 표시해 주세요.
각 앱의 핵심 기능, 장점, 단점, 수익 모델, 최근 업데이트 상태를 비교하고,
사용자 리뷰에서 반복적으로 지적되는 문제를 유형별로 묶어 주세요.
리뷰 한두 개의 의견을 전체 사용자 의견처럼 일반화하지 말고,
반복 빈도를 확인할 수 없는 경우에는 정성적 관찰이라고 표시해 주세요.
마지막에는 새 앱이 공략할 수 있는 기능적 공백과
기존 앱보다 오히려 불리한 지점을 각각 정리해 주세요.
리뷰를 읽을 때는 별점보다 맥락을 봅니다. 동기화가 느리다는 불만이 반복된다면 서버가 필요한 제품에서 로컬 우선 제품으로 차별화할 수 있습니다. 화면이 복잡하다는 의견이 많다면 기능 수가 아니라 첫 작업을 완료하는 단계 수를 줄이는 것이 기회일 수 있습니다. 다만 경쟁 앱에 없는 기능이 언제나 기회는 아닙니다. 사용자가 원하지 않거나 구현 비용과 정책 위험이 너무 커서 아무도 넣지 않은 것일 수도 있습니다. “왜 이 공백이 아직 남아 있는가”를 반드시 다시 질문해야 합니다.
조사 결과는 간단한 표로 남깁니다. 열에는 경쟁 앱, 대상 사용자, 핵심 작업, 가격, 광고, 계정 필요 여부, 오프라인 지원, 반복 불만, 우리가 검증할 가설을 둡니다. 비교표의 목적은 경쟁 앱을 복제하는 것이 아니라 첫 출시에서 반드시 잘해야 할 한두 가지 행동을 찾는 것입니다. 모든 경쟁 기능을 합친 앱은 범위가 커지고 정체성이 흐려집니다. 사용자가 앱을 열어 가장 먼저 완료해야 할 한 가지 작업을 더 짧고 안전하게 만드는 방향이 작은 팀에게 현실적입니다.
앱 이름은 기능과 검색 가능성을 함께 검증하기
방향이 정리되면 이름 후보를 만듭니다. 좋은 이름은 핵심 기능을 어느 정도 예상할 수 있고, 발음과 철자가 어렵지 않으며, 검색했을 때 다른 제품에 묻히지 않아야 합니다. ChatGPT에는 발음하기 쉬운 영어 이름을 우선 제안하되 지나치게 일반적인 단어, 기존 상표와 혼동될 표현, 기능을 오해하게 만드는 이름을 제외하도록 요청합니다. 이름마다 의미, 발음, 장점, 오해 가능성, 검색에 사용할 키워드도 함께 받으면 후보를 비교하기 쉽습니다.
AI가 이름을 추천했다는 사실은 사용 가능성을 보장하지 않습니다. 최종 결정 전에는 Google Play 스토어 중복 여부, 일반 Google 검색 결과, 도메인 사용 가능 여부, GitHub 저장소와 Android 패키지 이름 충돌 여부, 상표권 충돌 가능성을 각각 확인합니다. 패키지 이름은 앱 표시 이름과 다르지만 출시 후 바꾸기 매우 어렵기 때문에 보유한 도메인을 역순으로 사용하고 제품 식별자를 신중히 정합니다. 이름 후보가 마음에 들어도 확인이 끝나기 전에는 로고와 마케팅 자산부터 만들지 않는 편이 좋습니다.
현재 Google Play Store에 등록된 앱과 혼동되지 않으면서
앱의 핵심 기능을 쉽게 이해할 수 있는 이름을 추천해 주세요.
검색하기 쉽고 한국어 사용자도 발음하기 쉬운 영어 이름을 우선해 주세요.
지나치게 일반적인 이름, 기존 상표와 충돌할 가능성이 높은 이름,
기능을 오해하게 만드는 이름은 제외해 주세요.
각 후보에 대해 의미, 발음, 검색 시 예상되는 문제와
제가 직접 중복 여부를 확인할 검색어를 함께 작성해 주세요.2단계: ChatGPT로 코딩 가능한 상세 MVP 설계하기
아이디어와 이름이 정리되면 상세 MVP 설계도를 작성합니다. 여기서 MVP는 “로그인, 목록, 설정 화면을 만든다” 같은 기능 목록이 아닙니다. 코딩 에이전트가 구현 순서를 세우고 완료 여부를 테스트할 수 있을 만큼 입력, 상태, 예외와 종료 조건이 구체적이어야 합니다. 사람이 읽었을 때 여러 해석이 가능한 문장은 코딩 에이전트도 서로 다른 방식으로 구현합니다. 애매한 문장을 줄이는 것이 프롬프트 기교보다 더 큰 품질 차이를 만듭니다.
MVP 문서에는 앱의 목적, 대상 사용자, 핵심 가치, 주요 사용자 시나리오, 필수 기능과 제외 기능을 먼저 둡니다. 이어 화면 목록과 화면별 주요 동작, 데이터 저장 방식, 네트워크와 API 사용 여부, 권한, 인증, 보안, 백그라운드 작업, 오류 처리, 오프라인 대응을 기록합니다. 광고와 인앱 결제, 다국어, 접근성, 태블릿과 폴더블 대응, 테스트 항목, 출시 조건, 향후 확장 기능도 빠뜨리지 않습니다. 당장 구현하지 않는 항목도 “이번 버전에서는 하지 않는다”고 명시해야 에이전트가 임의로 추가하지 않습니다.
사용자 흐름은 정상 경로와 실패 경로를 함께 쓴다
사용자 시나리오는 “사용자가 항목을 추가한다”에서 끝나면 부족합니다. 앱을 처음 실행한 사용자가 어떤 안내를 보고, 권한을 거부하면 무엇이 보이며, 입력값이 비어 있거나 네트워크가 끊기면 어떤 메시지를 받고, 저장에 성공하면 어느 화면으로 이동하는지까지 적습니다. 백 버튼, 화면 회전, 프로세스 재시작 후 상태도 고려합니다. 이 흐름이 있어야 화면별 상태를 로딩, 비어 있음, 데이터 있음, 오류, 권한 없음으로 나누고 테스트할 수 있습니다.
데이터는 항목 이름만 쓰지 말고 소유 위치와 수명도 정합니다. 기기에만 저장할지, 계정에 동기화할지, 삭제 시 복구할지, 백업 대상인지, 민감 정보가 포함되는지 구분합니다. 서버가 필요 없다면 Room이나 DataStore 같은 로컬 저장으로 첫 버전을 단순화할 수 있습니다. 서버가 꼭 필요하다면 로그인 만료, 중복 요청, 충돌 해결, 재시도와 오프라인 캐시까지 비용에 포함해야 합니다. “클라우드 동기화” 한 줄은 실제로 인증, 서버 운영, 개인정보 보호, 장애 대응을 함께 불러옵니다.
Android 제약과 Google Play 정책을 설계 입력값으로 다룬다
정책 검토는 출시 직전에 하는 행정 작업이 아닙니다. 권한과 데이터 수집, 결제 방식은 제품 구조를 바꿉니다. Google Play 사용자 데이터 정책은 수집·이용·공유 내용을 투명하게 밝히고 필요한 범위로 제한하며 민감한 데이터를 안전하게 처리하도록 요구합니다. 제3자 광고나 분석 SDK의 데이터 처리도 개발자의 책임 범위에 들어갑니다. 계정을 만드는 앱은 계정과 관련 데이터의 삭제 경로도 설계해야 합니다. 따라서 MVP에 “분석 SDK 추가”라고만 쓰지 말고 어떤 이벤트와 식별자를 왜 수집하는지 먼저 정해야 합니다.
디지털 기능이나 콘텐츠를 판매한다면 Google Play 결제 정책을 확인하고, 구독은 지속적이고 반복되는 가치를 제공해야 합니다. 가격, 결제 주기, 자동 갱신과 취소 조건을 명확하게 보여줘야 하며 사용자를 오도하는 흐름을 만들면 안 됩니다. 광고가 들어간다면 광고 위치가 실수 클릭을 유도하지 않는지, 어린이를 대상으로 하거나 대상 연령을 넓게 잡을 때 추가 정책이 적용되는지도 살펴봅니다. 수익 모델을 나중에 붙이면 화면 구조와 개인정보 고지가 다시 바뀔 수 있으므로 MVP 단계에서 결정하는 편이 안전합니다.
플랫폼 버전도 고정된 숫자로 가정하지 않습니다. 이 글의 작성 기준일인 2026년 7월 26일 현재 Google은 2026년 8월 31일부터 일반적인 새 앱과 업데이트가 Android 16, API 수준 36 이상을 대상으로 해야 한다고 안내하고 있습니다. Wear OS, Android Automotive OS, Android TV와 XR에는 별도 기준이 있습니다. 개발을 시작할 때 공식 대상 API 수준 요구사항을 다시 확인하고, MVP 문서에 확인 날짜와 대상 SDK를 함께 기록해야 합니다.
상세 MVP 초안을 만드는 프롬프트
지금까지 논의한 내용을 바탕으로 이 Android 앱의 상세 MVP 설계도를 작성해 주세요.
단순한 기능 목록이 아니라 실제 개발에 사용할 수 있도록
사용자 흐름, 화면 구성과 화면별 상태, 데이터 구조, 오류 처리,
보안, 권한, 백그라운드 작업, 오프라인 대응, 접근성,
테스트 조건과 출시 완료 조건까지 구체적으로 작성해 주세요.
각 기능에는 입력, 정상 결과, 실패 조건, 사용자에게 보여줄 피드백을 포함해 주세요.
1차 출시에서 반드시 구현할 기능과 이후 버전으로 미룰 기능을 구분하고,
이번 버전에서 명시적으로 제외할 기능도 작성해 주세요.
Android 및 Google Play 정책과 관련된 내용은
확인이 필요한 공식 문서와 기준일을 함께 표시해 주세요.초안이 나오면 새 대화처럼 처음부터 반박하기
상세한 문서가 만들어지면 바로 코딩 에이전트에게 넘기고 싶은 마음이 생깁니다. 하지만 대화가 길어질수록 ChatGPT는 앞에서 합의한 방향을 유지하려는 경향이 있습니다. 그래서 검토 단계에서는 초안 전체를 대상으로 누락, 상충, 과도한 범위와 불명확한 흐름을 찾도록 역할을 바꿉니다. 가능하면 새 대화에 핵심 배경과 문서를 넣고, 설계에 동의하는 제품 기획자가 아니라 출시를 막을 수 있는 Android 시니어 개발자와 정책 검토자의 관점으로 평가해 달라고 요청합니다.
작성된 MVP를 처음부터 독립적으로 다시 검토해 주세요.
이전 결론을 옹호하지 말고 출시를 막을 수 있는 문제를 우선 찾아 주세요.
누락된 요구사항, 구현하기 어려운 기능, 기능 간 상충 관계,
과도한 범위, 불명확하거나 끊기는 사용자 흐름을 찾아 수정안을 제시해 주세요.
Android 플랫폼 제약, Google Play 정책, 보안과 개인정보 보호,
성능, 메모리 사용량, 백그라운드 실행 제한도 함께 검토해 주세요.
각 문제를 출시 차단, 중요, 개선 권장으로 구분하고
판단 근거와 확인 방법을 작성해 주세요.
현실적인 첫 출시 범위로 줄이는 기준
MVP의 M은 최소 기능 수가 아니라 가치를 검증할 수 있는 최소 범위를 뜻합니다. 핵심 작업을 완료하는 데 없어도 되는 기능, 서버 운영을 새로 요구하는 기능, 민감 권한을 추가하는 기능, 장애 대응과 고객 지원 비용이 큰 기능은 뒤로 미룹니다. 예를 들어 계정 없이 로컬에서 가치를 확인할 수 있다면 소셜 로그인과 동기화를 첫 버전에서 제외할 수 있습니다. 자동화가 핵심이 아니라면 복잡한 백그라운드 실행 대신 사용자가 앱을 열었을 때 명시적으로 실행하는 흐름으로 시작할 수 있습니다.
기능마다 사용자 가치, 구현 비용, 정책 위험, 운영 비용, 실패했을 때 영향의 다섯 항목을 낮음·중간·높음으로 표시합니다. 사용자 가치는 낮은데 나머지가 높은 기능은 제외 후보입니다. 가치와 위험이 모두 높다면 작은 실험으로 나눕니다. 예를 들어 대규모 자동 동기화 대신 한 종류의 데이터만 수동 동기화해 가설을 확인합니다. 이 표를 ChatGPT에 주고 현실적인 구현 순서를 재구성하게 한 뒤, 최종 결정은 개발자가 공식 문서와 실제 프로토타입을 확인해 내립니다.
현재 MVP가 개인 개발자의 1차 출시 범위로 적절한지 평가해 주세요.
각 기능을 사용자 가치, 구현 비용, 정책 위험, 운영 비용,
실패 영향의 다섯 기준으로 평가해 표로 정리해 주세요.
구현 비용이 지나치게 높은 기능, 초기 출시에 불필요한 기능,
기술적 위험이 높은 기능을 분리해 주세요.
핵심 가치를 훼손하지 않으면서 범위를 줄일 대안을 제시하고,
의존 관계를 고려한 현실적인 구현 순서로 재구성해 주세요.
최종 문서에서 모순과 '적절히', '필요하면' 같은 애매한 표현을 찾아
검증 가능한 완료 조건으로 바꿔 주세요.Code language: JavaScript (javascript)코딩 에이전트에 넘기기 전 최종 산출물
첫 단계가 끝났을 때는 최소한 여섯 가지 문서가 남아야 합니다. 첫째, 문제와 대상 사용자를 한 문장으로 적은 제품 정의입니다. 둘째, 경쟁 앱과 사용자 불만, 기능적 공백을 근거 링크와 함께 정리한 조사표입니다. 셋째, 이름과 패키지 후보의 중복·상표 확인 기록입니다. 넷째, 첫 출시 필수 기능과 제외 기능입니다. 다섯째, 화면과 상태, 데이터, 권한, 오류, 보안, 오프라인과 테스트가 연결된 상세 MVP입니다. 여섯째, 정책과 기술 위험 목록 및 공식 문서 확인 날짜입니다.
- 사용자가 해결하려는 핵심 작업을 한 문장으로 설명할 수 있는가
- 경쟁 앱의 존재와 반복 불만을 실제 링크에서 확인했는가
- 앱 이름, 저장소 이름, 도메인, 패키지명과 상표 가능성을 별도로 확인했는가
- 첫 실행부터 핵심 작업 완료까지 정상·빈 상태·오류·권한 거부 흐름이 있는가
- 수집 데이터와 제3자 SDK, 개인정보 고지와 삭제 경로가 정리됐는가
- 광고·결제·구독 방식이 화면과 정책 요구사항에 반영됐는가
- 오프라인, 백그라운드, 성능과 메모리 제한을 검토했는가
- 필수 기능과 이후 기능, 명시적 제외 기능이 구분됐는가
- 각 기능의 완료 여부를 판단할 테스트 조건이 있는가
- 대상 SDK와 Google Play 정책을 공식 문서에서 다시 확인했는가
이 자료를 프로젝트 저장소의 요구사항 문서로 넣고 코딩 에이전트에게는 한 번에 전체 앱을 만들어 달라고 하기보다 단계별 계획을 먼저 작성하게 합니다. 에이전트가 이해한 목적, 기술 선택, 구현 순서, 위험과 질문을 출력하게 한 뒤 원문과 비교합니다. 빠진 요구사항이 있으면 코드를 생성하기 전에 문서를 고칩니다. 설계 문서와 구현이 달라졌다면 그 이유를 결정 기록으로 남겨 다음 작업에서 오래된 가정을 반복하지 않도록 합니다.
ChatGPT의 답변은 결론이 아니라 검증할 가설이다
ChatGPT는 생각하지 못했던 질문을 빠르게 펼치고 긴 문서를 일관된 형식으로 정리하는 데 강합니다. 하지만 시장 규모, 경쟁 앱의 현재 상태, 정책 해석과 기술 지원 여부는 틀리거나 오래됐을 수 있습니다. 따라서 중요한 주장에는 링크와 기준일을 요구하고, Play 스토어와 Android Developers, Play Console 도움말 같은 1차 자료를 직접 확인합니다. 특히 사용자 데이터 처리와 결제 정책은 앱 책임자가 최종 판단해야 합니다. AI의 자신감과 사실의 정확성은 같은 값이 아닙니다.
반대로 모든 불확실성이 사라질 때까지 조사만 계속할 필요도 없습니다. 가장 위험한 가설을 찾고 가장 싼 방법으로 확인한 뒤 다음 단계로 넘어갑니다. 잠재 사용자 몇 명에게 문제 문장을 보여주거나, 경쟁 앱으로 같은 작업을 직접 수행하거나, 클릭 가능한 화면 모형으로 핵심 흐름을 시험할 수 있습니다. 기술적으로 불확실한 부분은 작은 Android 실험 프로젝트에서 권한, 저장소, 백그라운드 동작만 검증합니다. 검증 결과가 나쁘면 문서를 고치는 것이 실패가 아니라 비용을 아낀 성공입니다.
마무리: 첫 번째 단계에서 만들어야 하는 것은 확신이 아니라 기준
안드로이드 앱 바이브 코딩의 첫 단계는 멋진 화면을 빠르게 얻는 과정이 아닙니다. 해결할 문제를 좁히고, 시장과 경쟁을 확인하고, 이름의 충돌을 피하고, 플랫폼과 정책의 제약을 설계에 넣고, 첫 출시 범위를 과감하게 줄이는 과정입니다. ChatGPT는 이 작업을 빠르게 반복하게 해 주지만 답을 대신 책임지지는 않습니다. 좋은 질문, 근거 확인, 반대 검토와 작은 실험이 함께 있어야 비로소 코딩 가능한 계획이 됩니다.
최종 MVP가 완성되면 다음 단계는 이 문서를 코딩 에이전트가 실제로 실행할 프로젝트 규칙과 개발 계획으로 바꾸는 일입니다. 기술 스택을 정하고 저장소를 초기화하며 패키지명, 서명, 빌드 타입과 품질 기준을 처음부터 고정해야 합니다. 시아메이커랩 안드로이드 개발 카테고리에서는 이 흐름을 한 단계씩 이어가며, 코드가 생성되는 장면뿐 아니라 출시까지 가는 동안 마주치는 판단과 시행착오를 함께 기록하겠습니다.
작성 기준: 2026년 7월 26일. 정책과 대상 API 요구사항은 변경될 수 있으므로 개발 및 출시 시점에 Android Developers, Google Play 사용자 데이터 정책, Google Play 결제 정책의 최신 내용을 다시 확인하세요.
답글 남기기