AI Tips hub

Claude 답변이 느리다고 effort 때문이라고 단정할 수는 없어요. 도구가 실행 중인지, 자료가 길어졌는지, 일시적 서비스 문제가 공지됐는지도 함께 살펴보세요. 반복 업무라면 모델을 바꾸기 전에 effort 설정을 비교해 볼 만해요. 먼저 현재 모델의 Default로 답을 받은 뒤, 선택 가능한 한 단계 낮은 수준에서 같은 요청을 해보는 방식이에요. 중요한 건 첫 답변이 빨리 나왔는지가 아니라, 내가 쓸 수 있는 결과까지 얼마나 걸렸는지예요. 이 글은 Claude 채팅 화면을 기준으로 해요. 아래 업무 예시와 비교 기록법은 직접 시험해 볼 수 있도록 만든 편집 제안이에요. Claude effort 설정은 어디서 바꾸나요 채팅 입력창의 보내기 버튼 옆에서 모델 이름을 누르고, Effort를 연 뒤 원하는 수준을 선택해요. 대화 중 바꾸면 다음 답변부터 적용돼요. Default 표시는 그 모델의 권장값이에요. 모델마다 기본값과 제공 옵션이 다를 수 있으니, 다른 사람의 화면보다 내 메뉴를 기준으로 확인하세요. 공식 설정 안내 effort를 높이면 더 꼼꼼한 응답에 시간을 쓰고 토큰 사용도 늘어요. 다만 effort와 Thinking은 별도 설정이고, 모델에 따라 Thinking을 끌 수 없는 경우도 있어요. 하나를 바꿨다고 다른 하나까지 꺼졌다고 생각하면 안 돼요. 공식 설정 안내 내 업무에는 어느 수준부터 써볼까요 처음부터 모든 일을 가장 높은 수준에 맡길 필요는 없어요. 다음 표는 공식 성능 순위가 아니라, 결과를 쉽게 검수할 수 있는 업무부터 비교해 보자는 출발점이에요. 업무 예시 먼저 해볼 비교 결과에서 확인할 것 안내문을 짧고 부드럽게 고치기 Default와 한 단계 낮은 수준 날짜와 요청 사항이 그대로인지 회의 메모에서 할 일 뽑기 Default부터 시작 담당자와 기한을 지어내지 않았는지 여러 제안서의 조건 비교하기 Default로 만든 뒤 누락을 점검 제외 조건과 예외까지 담았는지 서로 다른 자료의 모순 찾기 Defa...

Suno 가사 소재가 막힐 때는 오늘 반복한 행동 하나를 골라보세요. 행동이 커지는 과정, 짧게 반복할 말, 정신이 번쩍 드는 순간을 붙이면 평범한 일상도 한 곡의 이야기가 돼요. 이번에는 도브리뮤직의 ‘알고리즘의 늪’을 따라, 잠들기 전 영상 하나가 어떻게 밤샘 이야기로 자라는지 살펴볼게요. 도브리뮤직에서 ‘알고리즘의 늪’ 듣기 가사를 먼저 완성해 한 곡으로 만드는 전체 흐름은 1편: 사랑의 맛 제작 과정 에서 이어서 볼 수 있어요. 1. 큰 주제보다 작은 장면에서 시작해요 ‘스마트폰에 빠진 현대인’이라고 쓰면 말하고 싶은 건 분명하지만, 가사 첫 줄은 잘 나오지 않아요. ‘자기 전에 짤 하나만 보려고 누웠다’로 좁히면 침대, 손가락, 화면이 바로 떠오르죠. 실제 가사도 “분명히 자기 전에 짤 하나 보려고 했는데”로 시작해요. 아직 큰 사건은 없어요. 대신 듣는 사람이 자기 경험을 가져올 자리가 생겨요. 소재를 고를 때는 언제, 어디서, 무엇을 했는지를 한 문장에 담아보세요. 감정 설명은 그다음이어도 괜찮아요. 2. 장면은 점점 엉뚱해지게 쌓아요 1절에서는 고양이 영상으로 시작해 수능 금지곡과 피라미드의 비밀까지 넘어가요. 2절에는 유압 프레스와 길거리 음식 영상이 등장해요. 처음에 보려던 것과 멀어질수록 ‘나 지금 뭐 하고 있지?’라는 웃음이 생겨요. 여기서 가져올 방법은 영상 종류를 많이 적는 것이 아니라, 이동하는 방향을 만드는 거예요. 처음에는 누구나 이해할 만한 행동을 놓아요. 다음에는 예상에서 조금 벗어나는 선택을 붙여요. 마지막에는 본인도 설명하기 어려운 장면까지 가봐요. 지각 이야기라면 알람을 끄는 장면, 옷을 뒤집어 입는 장면, 뛰어나갔다가 열쇠 때문에 돌아오는 장면으로 확장할 수 있어요. 같은 불평을 반복하는 대신 사건을 한 칸씩 움직이는 거죠. 3. 후렴에는 행동을 짧게 반복해요 이 곡의 후렴에는 ‘Scroll’과 ‘Watch’가 반복돼요. 긴 설명 없이도 엄지손가락과 시선이 계속 움직이는 모습을 떠올리게 해요. “내일 출근은 미래의 나에...

Suno 스타일 프롬프트를 쓸 때는 장르, 악기, 보컬, 편곡 흐름을 나누어 생각해 보세요. 「사랑의 맛」에 남아 있는 트로트 댄스와 파워 메탈 스타일을 비교하면, 원하는 음악을 얼마나 구체적으로 설명할 수 있는지 감이 잡혀요. 이번에는 실제 스타일 문장을 읽고, 같은 가사로 장르를 탐색하는 연습까지 이어가 볼게요. 「사랑의 맛」의 두 버전은 무엇이 다른가요? 라이브러리에는 「사랑의 맛」이라는 제목의 V4.5 COVER 버전이 3분 20초로, 「사랑의 맛 (Remix) (Edit)」가 3분 22초로 남아 있어요. 각각의 스타일은 트로트 댄스와 파워 메탈을 중심으로 설명되어 있어요. COVER는 화면에 보이는 표기이고, (Remix)·(Edit)는 제목에 남은 문자열이에요. 제목만으로 사용한 기능이나 작업 순서를 확정하지는 않아요. 이번에는 스타일 문장을 비교해요. 두 버전의 가사 전체가 같은지는 별도 대조가 필요해요. 같은 가사로 장르를 바꾸는 과정은 직접 해볼 연습으로 소개할게요. 사랑의 맛 Remix Edit 버전의 파워 메탈 스타일 전문을 보여주는 Suno 화면 사진 설명: 「사랑의 맛 (Remix) (Edit)」의 파워 메탈 스타일. 악기와 보컬, 곡의 전개를 설명한 부분이에요. 아래는 각 버전에 저장된 Styles 원문이에요. 설명을 제외한 코드 상자 안의 텍스트를 선택해 복사할 수 있어요. 실제 입력: 트로트 댄스 버전 This Korean trot-dance fusion opens with a lively accordion melody, quickly joined by a four-on-the-floor electronic kick and deep synth bass, Verses feel intimate, with sparse instrumentation, while choruses explode into energetic hooks with punchy synths and rhythmic flourishes, Dynamic transitions...

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의...