JSON-LD는 SEO, GEO, AEO에 얼마나 의미가 있을까#

우리는 위글플러스 블로그와 Typefy 테스트에 JSON-LD 구조화 데이터를 넣고 있습니다. 처음에는 SEO를 위한 작업처럼 보였습니다. 하지만 검색 환경이 바뀌면서 질문도 달라졌습니다.

이제 사용자는 검색창에 키워드만 넣지 않습니다. Google AI Overviews, AI Mode, ChatGPT search처럼 답변형 검색 경험에서 바로 요약을 보고, 그 안에 걸린 링크를 누릅니다. 그래서 JSON-LD가 기존 SEO뿐 아니라 GEO(Generative Engine Optimization), AEO(Answer Engine Optimization)에도 실제로 의미가 있는지 확인할 필요가 있었습니다.

결론부터 말하면, JSON-LD는 “순위를 올리는 버튼”이 아닙니다. 대신 검색엔진과 AI 검색 시스템이 우리 페이지의 의미를 더 명확하게 읽도록 돕는 신뢰 가능한 보조 신호입니다. 특히 블로그 글, 테스트 상세 페이지, 목록 페이지처럼 구조가 분명한 콘텐츠에서는 구현 비용이 낮고, 검색엔진이 페이지를 오해할 여지를 줄이는 데 실용적입니다.

JSON-LD가 하는 일은 검색엔진에 문맥을 건네는 것입니다#

JSON-LD는 HTML 안에 넣는 구조화 데이터 형식입니다. 사람이 읽는 본문과 별도로, 기계가 읽기 좋은 방식으로 “이 페이지가 무엇인지” 설명합니다. 예를 들어 블로그 글이라면 제목, 요약, 작성자, 발행일, 수정일, 대표 이미지, 원본 URL을 명시합니다.

Google Search Central은 구조화 데이터를 페이지 의미에 대한 명시적인 단서라고 설명합니다. 또한 구조화 데이터가 있으면 Google이 페이지 내용을 이해하고, 경우에 따라 더 풍부한 검색 결과를 만들 수 있다고 안내합니다. 출처: Google 구조화 데이터 소개

Schema.org도 같은 방향입니다. Schema.org는 웹페이지, 이메일, 그 밖의 인터넷 데이터에 쓰이는 구조화 데이터 어휘를 유지하는 공동 프로젝트이며, JSON-LD는 그 어휘를 표현하는 대표 형식 중 하나입니다. 출처: Schema.org

중요한 점은 JSON-LD가 본문을 대체하지 않는다는 것입니다. 본문에 없는 내용을 JSON-LD에만 넣는 방식은 위험합니다. Google 문서는 구조화 데이터가 해당 페이지의 내용을 설명해야 하며, 사용자에게 보이지 않는 정보를 임의로 추가하지 말라고 안내합니다.

그래서 좋은 JSON-LD는 “검색엔진에게만 보여주는 홍보 문구”가 아닙니다. 좋은 JSON-LD는 이미 페이지에 있는 내용을 정확한 필드로 다시 정리한 색인용 요약입니다.

SEO 관점: 직접 랭킹 신호라기보다 검색 노출 품질을 높이는 장치입니다#

SEO에서 JSON-LD의 가장 현실적인 효과는 리치 결과 eligibility입니다. Google은 Article, Breadcrumb, Organization, JobPosting, SoftwareApp, Video 등 다양한 구조화 데이터 기능을 지원합니다. 지원되는 타입을 올바르게 넣으면 검색 결과에서 제목, 이미지, 탐색 경로, 게시 정보 같은 표현이 개선될 수 있습니다. 출처: Google Search 구조화 데이터 갤러리

다만 “JSON-LD를 넣으면 순위가 오른다”라고 말하면 과장입니다. Google 문서가 말하는 핵심은 이해와 표현입니다. 구조화 데이터는 Google이 페이지를 이해하는 데 도움을 주고, 리치 결과 같은 검색 기능에 eligible하게 만들 수 있습니다. 하지만 색인과 노출은 보장되지 않습니다.

그래도 이 작업이 의미 있는 이유는 있습니다. Google의 구조화 데이터 소개 문서에는 실제 사례 데이터가 들어 있습니다. Rotten Tomatoes는 100,000개 페이지에 구조화 데이터를 적용한 뒤 구조화 데이터가 있는 페이지의 클릭률이 25% 높았다고 보고했고, Food Network는 페이지의 80%를 검색 기능에 맞게 전환한 뒤 방문이 35% 증가했다고 소개됩니다. Nestle 사례도 리치 결과 페이지의 클릭률이 일반 결과보다 82% 높았다고 소개됩니다.

이 숫자는 모든 사이트에 그대로 적용되는 공식 보장이 아닙니다. 하지만 방향은 분명합니다. 구조화 데이터는 검색 결과에서 사용자가 클릭하기 전에 얻는 정보의 질을 높입니다. 클릭률, 체류, 상호작용 같은 성과에 영향을 줄 수 있는 표면을 넓힙니다.

우리처럼 작은 서비스가 할 일은 단순합니다. 검색엔진이 추측해야 하는 정보를 줄여야 합니다. 제목, 요약, 작성자, 날짜, URL, 이미지, 문항 수, 소요 시간, 경로 같은 정보를 정확히 주면 됩니다.

GEO 관점: AI 검색에 별도 마법은 없지만, 기계가 읽는 정확도는 중요합니다#

GEO는 Generative Engine Optimization의 약자로 자주 쓰입니다. Google AI Overviews, AI Mode, ChatGPT search, Perplexity 같은 생성형 검색 환경에서 우리 콘텐츠가 답변의 근거 링크로 선택되거나 인용되도록 만드는 일을 뜻합니다.

여기서 주의할 점이 있습니다. Google은 AI Overviews와 AI Mode에 별도의 특별 최적화가 필요하지 않다고 말합니다. 기존 SEO 기본기가 그대로 중요하고, AI 기능에 나오기 위한 추가 기술 요구사항은 없다고 안내합니다. 또한 AI 기능에 나오기 위해 새로운 AI 전용 파일이나 특별한 schema.org 마크업을 만들 필요도 없다고 밝힙니다. 출처: Google AI features and your website

그렇다면 JSON-LD는 GEO에 의미가 없을까요? 그렇지는 않습니다. 같은 Google 문서는 AI 검색에서도 구조화 데이터가 페이지의 보이는 텍스트와 일치해야 한다고 안내합니다. 또 AI 검색 성과 가이드에서도 구조화 데이터는 콘텐츠 정보를 기계가 읽을 수 있는 방식으로 공유하고, 특정 검색 기능과 리치 결과 eligibility에 도움을 준다고 설명합니다. 출처: Google AI 검색 성과 가이드

즉 GEO에서 JSON-LD의 역할은 “AI 전용 스위치”가 아닙니다. AI 검색이 참고할 수 있는 기존 검색 인프라 안에서 페이지의 의미를 안정적으로 전달하는 장치입니다.

ChatGPT search도 비슷하게 봐야 합니다. OpenAI는 ChatGPT search가 웹의 고품질 원문 콘텐츠와 사용자를 연결하고, 제3자 검색 제공자와 파트너 콘텐츠를 활용한다고 설명합니다. 또한 OAI-SearchBot은 ChatGPT 검색 기능에서 웹사이트를 노출하기 위한 검색용 크롤러라고 안내합니다. 출처: OpenAI ChatGPT search 소개, OpenAI Crawlers 문서

OpenAI 문서가 “JSON-LD를 넣으면 ChatGPT search에 더 잘 나온다”고 말하지는 않습니다. 그래서 그 주장은 하면 안 됩니다. 다만 검색형 AI가 웹페이지를 찾고, 크롤링하고, 이해하고, 링크로 연결하는 구조라면 기계가 읽기 좋은 명확한 데이터가 손해가 될 이유는 없습니다.

AEO 관점: 답변 가능한 단위로 콘텐츠를 정리하는 데 도움이 됩니다#

AEO는 Answer Engine Optimization으로 불립니다. 사용자가 “무엇인가요?”, “어떻게 하나요?”, “얼마나 걸리나요?”, “어떤 차이가 있나요?”처럼 질문했을 때 답변 엔진이 근거로 삼기 쉬운 콘텐츠를 만드는 일입니다.

이 관점에서 JSON-LD는 답변 가능한 단위를 정리하는 역할을 합니다. 블로그 글은 BlogPosting으로 “이것은 글이다”라고 알려줍니다. Typefy 상세 페이지는 Quiz로 “이것은 질문과 선택지가 있는 테스트다”라고 알려줍니다. Typefy 목록 페이지는 CollectionPage로 “여기는 테스트 모음 페이지다”라고 알려줍니다. BreadcrumbList는 사용자가 지금 사이트의 어느 위치에 있는지 알려줍니다.

답변 엔진은 본문을 읽어야 합니다. 그래서 AEO의 1순위는 좋은 질문형 제목, 명확한 요약, 짧은 문단, 실제 예시, 내부 링크입니다. JSON-LD는 그 위에 붙는 구조 신호입니다.

예를 들어 Typefy 테스트 페이지에는 numberOfQuestions, timeRequired, mainEntity, Question, Answer, potentialAction이 들어갑니다. 이 데이터는 사용자가 테스트를 시작하기 전에 궁금해할 내용을 기계가 바로 파악하게 돕습니다. “몇 분 걸리나요?”, “질문이 있나요?”, “무료인가요?”, “무슨 카테고리인가요?” 같은 질문의 답이 구조 안에 들어갑니다.

이것이 AEO에서 JSON-LD가 의미 있는 지점입니다. 답변 엔진이 본문을 요약하기 전에, 페이지의 구조를 오해하지 않게 만듭니다.

우리는 블로그에서 이렇게 쓰고 있습니다#

현재 블로그 목록 페이지는 Blog와 BreadcrumbList JSON-LD를 넣고 있습니다.

목록 페이지의 Blog 구조에는 이름, 설명, URL, 언어, 발행 주체가 들어갑니다. BreadcrumbList에는 홈과 블로그의 위치가 들어갑니다. 즉 블로그 목록 페이지는 “위글플러스가 운영하는 한국어 블로그 홈”이라는 신호를 줍니다.

Next.js에서는 JSON-LD 객체를 만들고, 페이지 JSX 안에 application/ld+json 스크립트로 넣습니다. 핵심 패턴은 아래처럼 단순합니다.

const blogJsonLd = {
  "@context": "https://schema.org",
  "@type": "Blog",
  name: "위글플러스 블로그",
  description: "위글플러스가 전하는 학습, 성장, 생산성 인사이트.",
  url: "https://weggle-plus.co.kr/blog",
  inLanguage: "ko",
  publisher: {
    "@type": "Organization",
    name: "위글플러스",
    url: "https://weggle-plus.co.kr",
  },
};

return (
  <>
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(blogJsonLd) }}
    />
    {/* page content */}
  </>
);

상세 글 페이지는 BlogPosting과 BreadcrumbList를 넣고 있습니다.

BlogPosting에는 다음 값이 들어갑니다.

• headline: 글 제목
• description: 글 요약
• image: 글별 Open Graph 이미지 URL
• author: 작성자 이름
• datePublished: 발행일
• dateModified: 수정일
• publisher: 위글플러스 조직 정보
• mainEntityOfPage: 글의 canonical 성격을 갖는 상세 URL
• interactionStatistic: 좋아요 수, 댓글 수

상세 글의 핵심은 하드코딩이 아니라 실제 글 데이터에서 값을 가져오는 것입니다.

const postUrl = `https://weggle-plus.co.kr/blog/posts/${post.id}/${slug}`;

const blogPostingJsonLd = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  description: post.summary,
  image: `${postUrl}/opengraph-image`,
  author: {
    "@type": "Person",
    name: post.authorName,
  },
  datePublished: post.publishedAt ?? post.createdAt,
  dateModified: post.updatedAt,
  publisher: {
    "@type": "Organization",
    name: "위글플러스",
    url: "https://weggle-plus.co.kr",
  },
  mainEntityOfPage: {
    "@type": "WebPage",
    "@id": postUrl,
  },
  interactionStatistic: [
    {
      "@type": "InteractionCounter",
      interactionType: "https://schema.org/LikeAction",
      userInteractionCount: post.likeCount ?? 0,
    },
    {
      "@type": "InteractionCounter",
      interactionType: "https://schema.org/CommentAction",
      userInteractionCount: post.commentCount ?? 0,
    },
  ],
};

여기서 특히 좋은 점은 datePublished를 post.publishedAt ?? post.createdAt으로 처리한다는 점입니다. 예약 발행이나 지연 발행이 있는 블로그에서는 생성일과 공개일이 다를 수 있습니다. 검색엔진에는 사용자가 실제로 볼 수 있게 된 날짜를 우선 제공하는 편이 더 정확합니다.

또 mainEntityOfPage에 실제 상세 URL을 넣습니다. 이 필드는 검색엔진에게 “이 구조화 데이터가 설명하는 주 대상 페이지는 여기”라고 알려줍니다. 블로그처럼 글 URL이 공유와 색인의 중심인 서비스에서는 의미 있는 필드입니다.

우리는 Typefy에서 이렇게 쓰고 있습니다#

Typefy 목록 페이지는 CollectionPage와 BreadcrumbList JSON-LD를 넣고 있습니다.

목록 페이지는 “무료 성향 테스트 모음”이라는 이름과 설명, URL, 한국어 언어 정보를 제공합니다. 목록 페이지 자체가 개별 테스트가 아니라 여러 테스트로 들어가는 진입점이기 때문에 CollectionPage가 자연스럽습니다.

Typefy 상세 페이지는 더 적극적입니다.

상세 페이지의 메인 타입은 Quiz입니다. 여기에 테스트 이름, headline, 설명, URL, 언어, 이미지, 공개일, 수정일, 무료 여부, 예상 소요 시간, 제공자, 발행자, 웹사이트 관계, 카테고리, 대상 독자, 질문 수, 질문 목록, 선택지 목록, 시작 액션을 넣습니다.

코드로 보면 Typefy의 핵심 콘텐츠인 질문과 선택지를 mainEntity에 매핑합니다.

const testUrl = `https://weggle-plus.co.kr/typefy/${test.slug}`;

const quizJsonLd = {
  "@context": "https://schema.org",
  "@type": "Quiz",
  "@id": `${testUrl}#quiz`,
  name: `${test.title} 테스트`,
  headline: `${test.title} 테스트`,
  description: test.description,
  url: testUrl,
  inLanguage: "ko",
  image: "https://weggle-plus.co.kr/images/typefy-og.png",
  datePublished: test.openedAt,
  dateModified: test.updatedAt ?? test.openedAt,
  isAccessibleForFree: true,
  timeRequired: `PT${test.estimatedMinutes}M`,
  provider: {
    "@type": "Organization",
    name: "Typefy",
    url: "https://weggle-plus.co.kr/typefy",
  },
  about: {
    "@type": "Thing",
    name: test.category,
  },
  numberOfQuestions: test.questions.length,
  mainEntity: test.questions.map((question, index) => ({
    "@type": "Question",
    name: question.title,
    text: question.subtitle ? `${question.title} ${question.subtitle}` : question.title,
    position: index + 1,
    suggestedAnswer: question.choices.map((choice) => ({
      "@type": "Answer",
      text: choice.label,
    })),
  })),
  potentialAction: {
    "@type": "TakeAction",
    name: "테스트 시작",
    target: testUrl,
  },
};

이 구조는 Typefy에 잘 맞습니다. Typefy의 핵심 콘텐츠는 “질문에 답하고 결과를 받는 테스트”입니다. 따라서 검색엔진과 AI 검색 시스템이 이 페이지를 일반 글이나 랜딩 페이지로 오해하지 않도록 Quiz로 명확히 설명하는 편이 좋습니다.

다만 Typefy의 Quiz JSON-LD는 Google 리치 결과 노출을 직접 기대하는 장치로 보면 안 됩니다. Google 리치 결과 갤러리에서 Quiz가 대표 지원 타입으로 다뤄지는 것은 아니기 때문입니다. Typefy에서 Quiz를 쓰는 목적은 검색 결과를 화려하게 바꾸는 것보다, schema.org 기반으로 테스트 콘텐츠의 의미를 명확히 전달하는 데 더 가깝습니다.

특히 timeRequired: PT{estimatedMinutes}M은 사용자 경험과도 연결됩니다. 사람은 “이 테스트 얼마나 걸리지?”를 궁금해합니다. 검색엔진도 같은 정보를 구조적으로 받을 수 있습니다. mainEntity에 질문과 선택지를 넣는 것도 의미가 있습니다. 테스트의 핵심 콘텐츠가 문항이라는 점을 숨기지 않기 때문입니다.

다만 여기서도 원칙은 같습니다. JSON-LD에 넣는 문항, 선택지, 카테고리, 소요 시간은 실제 테스트 데이터와 일치해야 합니다. 생성된 JSON-LD와 화면 콘텐츠가 어긋나면 SEO가 아니라 품질 리스크가 됩니다.

적용할 때 주의할 점#

첫째, JSON-LD는 화면에 보이는 내용과 일치해야 합니다. 본문에 없는 장점, 과장된 설명, 실제와 다른 평점이나 날짜를 구조화 데이터에만 넣으면 검색엔진을 돕는 것이 아니라 신뢰를 깎는 일이 됩니다.

둘째, Google 리치 결과 지원 타입과 schema.org 타입은 구분해야 합니다. schema.org에 타입이 있다고 해서 Google 검색 결과에서 특별한 UI가 보장되는 것은 아닙니다. 블로그의 BlogPosting은 Article 계열 검색 기능과 더 가까운 반면, Typefy의 Quiz는 리치 결과 보장보다 의미 명확화 목적이 큽니다.

셋째, 적용 후에는 Search Console에서 확인해야 합니다. JSON-LD를 넣었다고 바로 성과가 보이지 않을 수 있습니다. URL 검사, 리치 결과 테스트, 검색 성과 리포트를 함께 보고 몇 달 단위로 노출, 클릭률, 평균 순위 변화를 비교해야 합니다.

넷째, 서비스가 늘어날수록 상수와 헬퍼가 필요합니다. 조직명, 기본 URL, 서비스명, 대표 이미지 URL을 페이지마다 직접 쓰면 나중에 표기가 흔들립니다. JSON-LD도 화면 UI처럼 SSOT를 갖는 편이 좋습니다.

다섯째, 모든 페이지에 억지로 넣을 필요는 없습니다. 콘텐츠 타입이 모호한 단순 마케팅 페이지라면 JSON-LD보다 제목, 설명, 본문 품질, 내부 링크, OG 이미지, 페이지 속도가 먼저입니다.

실무 기준: JSON-LD는 이렇게 판단하면 됩니다#

JSON-LD를 넣을지 말지는 다음 질문으로 판단하면 됩니다.

1. 이 페이지는 명확한 콘텐츠 타입이 있는가?
2. 검색엔진이 알아야 할 핵심 필드가 있는가?
3. 그 필드가 화면이나 API 데이터와 일치하는가?
4. Google이 지원하는 리치 결과 타입이 있거나, schema.org 타입으로 의미를 명확히 표현할 수 있는가?
5. 나중에 서비스가 늘어나도 상수와 헬퍼로 유지보수할 수 있는가?

이 질문에 대부분 “예”라면 JSON-LD를 넣는 편이 좋습니다. 반대로 화면에는 없는 홍보 문구를 검색엔진에만 전달하려는 목적이라면 하지 않는 편이 낫습니다.

우리 기준으로는 블로그, Typefy, JobSkill 세미나, Nomad's 채용공고, Nomad's 지원사업, staglit 공연, 셀링페이퍼 독후감 같은 페이지가 우선순위가 높습니다. 모두 “타입”과 “핵심 필드”가 분명하기 때문입니다.

반면 단순 마케팅 페이지는 우선순위가 낮을 수 있습니다. 이 경우에는 JSON-LD보다 제목, 설명, 내부 링크, OG 이미지, 페이지 속도, 본문 품질이 먼저입니다.

SEO, GEO, AEO를 나눠 보면 역할이 더 선명합니다#

SEO에서 JSON-LD는 검색엔진 이해와 리치 결과 eligibility를 돕습니다. 클릭률을 직접 보장하지는 않지만, 지원 타입에 맞게 구현하면 검색 결과 표현을 개선할 수 있는 기반입니다.

GEO에서 JSON-LD는 생성형 검색에 특별한 입장권은 아닙니다. Google은 AI 기능에 별도 마크업이 필요 없다고 말합니다. 하지만 AI 검색도 결국 색인 가능한 웹 문서와 검색 시스템 위에서 작동합니다. 구조화 데이터는 그 문서가 무엇인지 명확하게 해줍니다.

AEO에서 JSON-LD는 답변 가능한 단위를 정리합니다. BlogPosting은 글의 주체와 날짜를, Quiz는 질문과 선택지를, BreadcrumbList는 경로를 설명합니다. 답변 엔진이 페이지를 요약할 때 기본 골격을 제공합니다.

그래서 JSON-LD의 투자 우선순위는 “검색 트래픽이 있거나, 콘텐츠 타입이 명확하거나, AI 검색에서 답변 근거가 될 수 있는 페이지”입니다. 우리 블로그와 Typefy는 이 조건에 잘 맞습니다.

결론: JSON-LD는 작은 서비스가 할 수 있는 가장 현실적인 검색 인프라입니다#

JSON-LD는 화려한 성장 해킹이 아닙니다. 그러나 작은 서비스가 꾸준히 쌓아야 하는 검색 인프라입니다.

검색엔진은 본문을 읽습니다. AI 검색도 결국 원문과 링크를 필요로 합니다. 사용자는 더 빠르게 답을 얻고 싶어 합니다. 이 흐름에서 우리가 할 일은 콘텐츠를 더 과장하는 것이 아니라, 콘텐츠의 구조를 더 정확하게 드러내는 것입니다.

위글플러스 블로그는 BlogPosting으로 글의 출처와 날짜를 명확히 합니다. 이 영역은 Google의 Article 계열 구조화 데이터와 맞닿아 있어 리치 결과 가능성을 검토할 만합니다. Typefy는 Quiz로 테스트의 질문 구조와 소요 시간을 명확히 합니다. 이 영역은 Google 리치 결과를 직접 노리기보다, 테스트 콘텐츠의 의미를 기계가 덜 오해하게 만드는 목적이 더 큽니다.

둘 다 JSON-LD를 넣을 가치는 있습니다. 다만 기대 효과는 다르게 봐야 합니다. 블로그는 검색 결과 표현 개선 가능성을 포함한 SEO 인프라에 가깝고, Typefy는 테스트라는 콘텐츠 구조를 명확히 전달하는 GEO/AEO 보조 신호에 가깝습니다.

앞으로의 기준은 단순합니다. 본문에 있는 중요한 정보를 JSON-LD로 한 번 더 정확하게 말합니다. 화면과 다른 데이터는 넣지 않습니다. 서비스별 상수와 헬퍼로 관리합니다. 그리고 Search Console에서 실제 성과를 확인합니다.

이 정도면 충분히 실용적입니다. JSON-LD는 검색 순위를 사는 기술이 아니라, 검색과 AI가 우리 콘텐츠를 덜 오해하게 만드는 기술입니다.

참고한 자료#

• Google Search Central - Introduction to structured data markup
• Google Search Central - Structured data markup that Google Search supports
• Google Search Central - AI features and your website
• Google Search Central Blog - Succeeding in AI Search
• Schema.org
• Bing Webmaster Blog - Introducing JSON-LD Support
• OpenAI - Introducing ChatGPT search
• OpenAI - Overview of OpenAI Crawlers

위글플러스의 다른 서비스도 둘러보세요#

Typefy - 나를 발견하다: MBTI·여행 DNA·직업 성향 등 다양한 무료 심리 테스트로 나 자신을 탐색해 보세요.

Versus - 오늘의 선택, 당신의 생각: 매일 새로운 A vs B 밸런스 게임에 참여하고, 다른 사람들의 선택과 비교해보세요.

Nomad's - 세상을 탐색하다: 전 세계 디지털 노마드들이 추천하는 지역 리뷰와 실제 체류 경험을 확인해 보세요.

Nomad'With - 일상을 나누다: 디지털 노마드들의 여행, 원격 근무, 한달살기 이야기를 피드에서 만나보세요.

JobSkill - 역량을 키우다: 현직자가 직접 진행하는 직무 스킬 세미나로 실전 커리어 경쟁력을 높여보세요.

ThingsInThing - 미디어 속 숨겨진 것들을 발견하세요: 책, TV 프로그램 속에 등장하는 숨겨진 것들을 발견하고 탐색하세요.

staglit - 무대 위의 모든 순간: 국내외 공연과 페스티벌 정보를 한 곳에서 확인하세요.

별짓 - 오늘의 운명을 읽다: 별자리 일간 운세로 매일의 흐름을 확인하세요.

셀링페이퍼 - 독후감으로 수익 만들기: 책을 읽고 독후감을 작성하세요. 다른 사람이 내 독후감을 통해 책을 구매하면 수수료를 받을 수 있습니다.

문장 만들기 - 단어를 문장으로 엮다: 랜덤 단어를 받아 한국어, 영어, 일본어 문장을 만들고 커뮤니티 반응으로 톤을 검증하세요.

롤모아 - 경기를 모아보다: 리그 오브 레전드 주요 대회 경기 일정과 결과를 확인하고 팀 평점과 의견을 남겨보세요.

비슷한 고민을 하고 계시거나 같이 실험해보고 싶은 분은 커피챗 하고 싶습니다 ☕️

📩 ksy90101@gmail.com