AI Tips hub

Suno로 곡을 만들 때 출발점이 막막하다면, 먼저 가사에 담을 이야기부터 정해 보세요. 「사랑의 맛」도 가사를 완성한 뒤 Suno 4.5에서 pop+rock을 비롯한 여러 장르를 시도하고, 그중 마음에 드는 곡을 고르는 순서로 만들었어요. 이번 글에서는 그 과정을 가사 준비, 장르 탐색, 버전 정리의 세 단계로 풀어볼게요. 1. 노래가 전할 말을 한 문장으로 정해요 「사랑의 맛」의 중심에는 오래 우릴수록 진해지는 마음이 있어요. 국밥이라는 친숙한 소재를 사랑에 겹쳐 놓았죠. 가사 첫 줄은 “국밥집에서 처음 본 그대”예요. 어디서 누구를 만났는지 바로 그려지고, 뒤에 나올 음식 비유도 자연스럽게 받아들일 수 있어요. 후렴에서는 그 생각이 더 또렷해져요. 사골국물 같은 우리 사랑 우려낼수록 진한 그 맛 곡의 제목과 이야기가 이 두 줄로 이어져요. 처음 가사를 쓸 때도 소재를 잔뜩 나열하기보다, 끝까지 가져갈 비유 하나를 골라보세요. 커피라면 식어가는 온도, 버스라면 함께 가는 길처럼 장면을 확장할 수 있어요. 2. 가사 원본과 제작용 가사를 나눠요 이 곡에는 가사만 담은 원본과 스타일·구간 지시가 들어간 프롬프트가 따로 있어요. 가사 원본은 이야기를 읽고 고치기 편하고, 제작용 입력은 노래의 흐름을 설명하기 좋아요. 제작용 가사에는 [Verse 1], [Pre-Chorus], [Chorus], [Bridge], [Outro] 같은 구간 표시가 붙어 있어요. 예를 들어 첫 만남을 이야기하는 부분과 “사골국물 같은 우리 사랑”을 반복하는 부분을 구분해 둔 거예요. 각 구간이 맡을 역할을 먼저 생각하면 가사를 어디서 반복할지도 정하기 쉬워져요. 구간 이름만 복사하려면 아래를 사용하세요. 실제 제작용 가사의 전체 순서가 아니라, 위에서 소개한 태그만 모은 부분 예시예요. 필요한 위치에 가사를 넣어주세요. [Verse 1] [Pre-Chorus] [Chorus] [Bridge] [Outro] 두 텍스트의 가사 내용과 순서는 같고, 제작용에는 “아~”처럼 길게 부를 느낌...

AI 조사 노트는 원문 사실, 자신의 해석, 확인할 질문을 구분해서 저장하는 것이 좋습니다. 노트를 다시 자료로 사용할 때 추정이 사실처럼 반복되는 일을 줄이기 위한 방법입니다. 왜 노트의 구분이 중요한가요? Google의 현재 안내에서는 선택한 Note 소스도 질문과 답변의 근거로 사용될 수 있습니다. 따라서 원문을 요약한 문장과 작성자의 의견이 섞인 노트를 저장하면 이후 답변을 검토하기 어려워질 수 있습니다. 아래 구분은 제품의 자동 검증 기능이 아니라 사용자가 직접 유지할 작업 규칙입니다. 노트를 세 구역으로 나눠 보세요 확인된 사실: 원문 링크, 발행일, 핵심 내용을 기록합니다. 내 해석: 이 사실이 내 작업에 어떤 의미인지 적습니다. 추가 확인: 공식 자료에서 찾지 못한 질문을 남깁니다. 예를 들어 “새 편집 기능이 발표됐다”는 사실과 “내 편집 시간이 절반으로 줄 것이다”라는 기대는 다른 구역에 있어야 합니다. 기대를 사실 구역에 넣지 않는 것만으로도 이후 문서를 검토하기가 쉬워집니다. 실무용 노트 양식 주제: [한 가지 질문] 출처·날짜: [공식 링크와 발표일] 확인된 내용: [원문에서 확인한 요약] 적용 범위: [대상 계정·제품·지역] 내 해석: [의견임을 표시] 미확인 사항: [추가 조사할 질문] 다음 검토일: [변경 가능성에 맞춰 선택] 이 양식은 예시이며 특정 도구만을 위한 형식은 아닙니다. 노트 제목에는 주제와 확인일을 넣고, 이전 버전을 바로 지우기보다 새 버전과 구분해 보관하면 변경 이유를 추적할 수 있습니다. 블로그 글로 바꿀 때 확인할 것 노트의 해석 문장을 원고에서 사실처럼 쓰지 않았는지 확인합니다. 공식 발표의 예정 사항을 이미 제공되는 기능으로 바꾸지 않았는지도 봅니다. 출처가 오래됐다면 현재 안내를 다시 열고, 직접 시험하지 않은 예시는 그렇게 표시하세요. 마지막으로 독자가 바로 쓸 수 있는 점검표나 짧은 적용 예시를 추가합니다. 출처를 길게 바꿔 쓰는 것보다 무엇을 확인하고 어떻게 판단할지 알려주는 편이 글의 고유한 가치를...

자료 비교에서는 요약의 문장력보다 각 결론이 어느 자료에서 나왔는지 확인할 수 있어야 합니다. Gemini Notebook에서 비교할 자료를 선택하고 답변의 인용을 원문과 대조하는 순서로 시작하세요. 어떤 기능을 활용하나요? Google 도움말은 질문에 사용할 소스를 선택하고, 답변의 인용을 눌러 원문 맥락을 확인할 수 있다고 안내합니다. AI 답변이 출처를 달았다는 이유만으로 정확한 해석이 보장되는 것은 아닙니다. 아래 절차는 인용을 검토에 활용하기 위한 작업 제안입니다. 두 문서를 비교하기 전에 준비할 것 문서명에 날짜와 버전을 붙입니다. 같은 주제라도 작성 목적이 다른지 확인합니다. 비교할 항목을 먼저 정합니다. 예: 대상, 기능, 제한, 시행일. 업로드해도 되는 자료인지 확인하고 불필요한 개인정보는 제외합니다. 새 버전과 옛 버전을 함께 넣었을 때 어떤 내용을 현재 기준으로 사용할지 명시하지 않으면 결과를 해석하기 어려워집니다. 바로 바꿔 쓸 수 있는 비교 질문 선택한 문서 A와 B를 대상·주요 기능·제한·적용일로 비교해 주세요. 각 차이에 근거가 되는 인용을 붙이고, 어느 문서에도 없는 내용은 “자료에서 확인되지 않음”으로 표시하세요. 서로 충돌하는 내용은 결론을 추정하지 말고 따로 모아 주세요. 이 질문은 테스트 결과가 아닌 예시입니다. 답변을 받은 뒤 가장 중요한 차이부터 인용을 열어 앞뒤 문장을 읽습니다. 표의 한 칸이 실제로는 두 자료를 섞어 만든 주장인지 확인하는 과정입니다. 정리 결과를 공유하기 전 점검 자료에 없는 내용을 “없음”으로 표현했는지 살펴보세요. “자료에서 찾지 못함”과 “기능이 존재하지 않음”은 다릅니다. 날짜가 다른 문서는 당시 기준과 현재 기준도 구분해야 합니다. 마지막으로 결론 옆에 원본 링크와 확인일을 남기면 나중에 업데이트하기 편합니다. 출처가 부족하면 자료를 보충하거나 질문 범위를 줄이는 것이 우선입니다. 불완전한 두 문서만으로 모든 제품의 우열을 단정하지 마세요. 공식 자료와 확인 범위 Google: Gemini ...

AI 답변이 아쉬울 때는 “더 좋게”보다 무엇이 잘못됐는지 지정하세요. 톤, 분량, 사실, 구조를 한꺼번에 바꾸면 어떤 수정이 도움이 됐는지 알기 어렵습니다. 첫 단계는 오류에 이름을 붙이는 것입니다 예를 들어 블로그 도입문이 마음에 들지 않는다면 “너무 길다”, “독자 질문에 답하지 않는다”, “확인하지 않은 기능을 단정한다”를 구분합니다. 세 문제는 수정 방법이 다릅니다. 분량을 줄인다고 근거 없는 주장이 자동으로 없어지는 것은 아닙니다. 원문과 수정 조건을 분리하세요 Anthropic 문서는 지시·문맥·입력·예시를 구분하는 구조를 권합니다. 이를 적용해 원문 뒤에 다음 요청을 붙일 수 있습니다. 수정 대상: 첫 두 문단만. 문제: 기능 설명은 있지만 누구에게 유용한지 드러나지 않는다. 유지: 확인된 사실과 출처 링크. 변경: 첫 문장에서 대상 독자와 해결할 질문을 제시한다. 검토: 새 사실을 추가했다면 별도로 표시한다. 이것은 직접 작성한 미검증 예시입니다. 원문 전체를 매번 다시 생성하기보다 수정 범위를 제한하면 좋은 부분을 보존하면서 비교하기 쉽습니다. 버전 기록은 짧아도 됩니다 “A: 기존 도입 / B: 대상 독자 명시 / C: 첫 문장 40자 이내”처럼 기록하세요. 각 버전의 목표가 달라야 비교 의미가 있습니다. 세 버전을 한꺼번에 요청했다면 어떤 기준으로 고를지도 먼저 정하세요. 클릭을 유도하는 강한 문구보다 내용과 맞는 약속을 하는 제목을 우선하는 것이 좋습니다. 최종 선택 전 질문 세 가지 수정한 문장이 원문보다 구체적으로 질문에 답하는가? 출처가 뒷받침하지 않는 표현이 새로 생기지 않았는가? 읽기 쉬워졌지만 중요한 예외가 빠지지는 않았는가? 모델에게 자체 검토를 요청할 수 있지만, 그것만으로 정확성이 보장되지는 않습니다. 제품 이름·날짜·숫자는 실제 자료에서 다시 확인하세요. 반복 작업의 목적은 문장을 화려하게 바꾸는 것이 아니라, 독자가 이해하고 행동하는 데 필요한 정보를 정확히 남기는 것입니다. 공식 자료와 확인 범위 Anthropic의...

답변 형식이 매번 달라진다면 원하는 형식을 설명하고, 짧은 완성 예시와 빈값 처리 규칙을 함께 제공해 보세요. “잘 정리해 줘”만으로는 결과를 검토할 기준이 부족합니다. 먼저 무엇을 고정해야 하나요? Anthropic의 프롬프트 안내는 명확한 지시, 원하는 출력 형식과 제약, 관련 예시를 제시하는 방법을 설명합니다. 다음 양식은 이 원칙을 업무 메모 정리에 적용한 독자용 제안입니다. 모델이 모든 규칙을 항상 준수한다고 보장하는 양식은 아닙니다. 업무 메모 정리 프롬프트 예시 목적: 아래 메모에서 실행할 일을 찾는다. 입력: [여기에 메모] 출력: 할 일 / 담당자 / 기한 / 근거 문장 순서로 정리한다. 규칙: 메모에 없는 담당자와 기한은 “미정”으로 적는다. 제안과 확정된 약속을 구분한다. 원문에 없는 업무를 추가하지 않는다. 이 예시는 미검증 템플릿입니다. 메모에 “금요일까지 검토하면 좋겠다”라고 적혀 있을 때 확정된 마감으로 바꿔 버리지 않는지 확인해 보세요. 문장 형태를 맞추는 것보다 확정성과 추정을 구분하는 것이 더 중요할 때가 많습니다. 예시는 정답뿐 아니라 빈값도 포함하세요 모든 예시에 담당자와 날짜가 들어 있으면 정보가 없는 상황을 어떻게 처리할지 전달하기 어렵습니다. 담당자가 없는 메모, 날짜가 모호한 메모, 실행할 일이 전혀 없는 메모를 각각 하나씩 준비해 보세요. 공개해도 되는 가상 자료로 시험하면 민감한 업무 내용을 불필요하게 입력할 위험도 줄일 수 있습니다. 출력을 받은 뒤 확인할 항목 요청한 열이나 항목이 빠지지 않았는가? 근거 문장이 실제 입력에 있는가? 빈칸을 상상해서 채우지 않았는가? 중복 업무를 별개의 업무로 세지 않았는가? 형식 오류와 사실 오류를 나눠 기록하세요. 형식이 틀렸다면 구조를 다시 제시하고, 사실이 틀렸다면 해당 근거와 판단 규칙을 수정합니다. 같은 요청을 무작정 길게 만드는 것보다 어떤 오류를 줄이려는지 분명히 하는 편이 검토에 도움이 됩니다. 공식 자료와 확인 범위 Anthropic 프롬프트 작성 안내 자료 확...

짧은 AI 영상에서 장면이 자꾸 바뀐다면 한 컷에 너무 많은 사건을 넣었는지 먼저 확인하세요. 시작 상태·한 가지 행동·끝 상태만 적는 콘티부터 만드는 것을 권합니다. 한 컷에 들어갈 정보는 어디까지인가요? Runway의 Gen-4 가이드는 단순한 프롬프트에서 시작해 하나씩 요소를 추가하는 방식을 제안합니다. 여러 장면·행동·스타일 변화를 한 번에 요구하면 결과가 의도와 달라질 수 있다는 설명입니다. 아래는 이를 참고해 만든 독자용 콘티 양식입니다. 복사해서 사용하는 한 컷 양식 시작: 카페 창가에 앉은 인물, 컵은 테이블 오른쪽. 핵심 행동: 인물이 컵을 천천히 들어 올린다. 끝: 컵을 든 채 창밖을 바라본다. 카메라: 고정된 중간 거리 구도. 유지할 것: 의상, 자리, 테이블 위 물건 위치. 이 예시는 실제 생성 테스트를 거치지 않았습니다. 중요한 것은 단어를 많이 넣는 것이 아니라 결과를 검사할 기준을 먼저 정하는 데 있습니다. 컵을 들다가 갑자기 다른 장소로 이동하는 장면이 나오면 실패를 구체적으로 설명할 수 있습니다. 언제 컷을 나눠야 할까요? 인물이 카페를 나와 길을 건너고 버스에 타는 이야기는 장소와 행동이 여러 번 바뀝니다. 하나의 생성에 모두 넣기보다 카페에서 일어나기, 거리를 걷기, 버스 앞에 서기처럼 나누는 편이 편집과 검토에 유리할 수 있습니다. 다만 여러 컷의 얼굴이나 의상이 자동으로 일치하는 것은 아니므로 공통 참고 이미지를 관리해야 합니다. 결과를 평가하는 네 가지 질문 시작 이미지와 첫 장면의 구도가 연결되는가? 요청한 핵심 행동이 실제로 보이는가? 불필요한 컷 전환이 끼어들지 않는가? 다음 컷과 연결할 수 있는 끝 상태인가? 좋은 영상의 기준을 “영화처럼”이라는 한 단어에 맡기지 마세요. 같은 장면이라도 카메라가 움직여야 하는 이유가 있는지 먼저 판단하면 프롬프트가 간결해집니다. 생성 길이와 기능은 선택 모델의 현재 안내를 따르세요. 공식 자료와 확인 범위 Runway Gen-4 프롬프트 공식 가이드 자료 확인: 2026년 10월...

이미지 투 비디오에서는 시작 이미지가 이미 외모와 구도를 제공합니다. 텍스트는 무엇이 어떻게 움직이는지에 집중하면 수정 방향을 잡기 쉽습니다. 이미지와 텍스트의 역할은 어떻게 다른가요? Runway의 Image to Video 가이드는 입력 이미지가 구도·피사체·조명·스타일을 제공하고, 프롬프트가 움직임과 시간 흐름을 설명한다고 안내합니다. 이 원칙을 기준으로 아래의 작업 메모를 만들 수 있습니다. 다른 서비스가 모든 문장을 똑같이 해석한다는 뜻은 아닙니다. 한 장면을 세 줄로 나눠 보세요 피사체: 사람이 고개를 천천히 오른쪽으로 돌린다. 카메라: 제자리에 고정된 카메라로 인물을 담는다. 배경: 커튼만 바람에 약하게 움직인다. 미검증 예시 프롬프트: “고정된 카메라. 인물이 고개를 천천히 오른쪽으로 돌리고 미소를 짓는다. 뒤쪽 커튼이 약하게 흔들린다.” 원본에서 이미 보이는 옷 색이나 얼굴 특징을 장황하게 반복하기보다 핵심 동작을 명확히 적는 연습입니다. 동작이 어색하면 무엇부터 바꾸나요? 첫 번째 점검 대상은 시작 이미지입니다. 손이 이미 흐리거나 얼굴 윤곽이 겹쳐 있다면 움직이는 과정에서 문제가 더 눈에 띌 수 있습니다. 자세가 달리는 순간인데 정지 장면을 요구하는 것처럼 이미지가 암시하는 동작과 요청이 충돌하는지도 살펴보세요. 다음으로 한 컷의 목표를 줄입니다. 걷기·회전·앉기·카메라 이동을 모두 요구한 결과가 어색하다면, 먼저 한 동작만 남겨 비교합니다. 그 뒤 필요한 배경 움직임을 추가하세요. 이것은 결과를 설명할 변수를 줄이려는 방법이지 성공을 보장하는 공식은 아닙니다. 작업 기록은 이렇게 남기세요 파일마다 시작 이미지 이름, 핵심 동작, 카메라 움직임, 결과의 문제 한 가지를 적습니다. 예를 들어 “창가A / 고개 돌리기 / 고정 / 손이 흔들림”처럼 짧게 남기면 충분합니다. 마음에 들지 않는 결과를 무작정 다시 생성하기보다, 다음 입력에서 무엇을 바꿀지 먼저 한 문장으로 정하세요. 공개할 영상은 얼굴·손·배경의 연결과 원치 않는 장면 전환을 전체...