RAG(Retrieval-Augmented Generation)의 이해: 필요성과 활용

RAG(Retrieval-Augmented Generation)의 이해: 필요성과 활용

서론

인공지능과 자연어 처리 기술의 발전은 우리의 일상생활과 업무 방식을 크게 변화시키고 있습니다. 특히, 대규모 언어 모델(Large Language Models, LLMs)의 등장으로 텍스트 생성, 질문 답변, 번역 등 다양한 작업에서 놀라운 성과를 보이고 있습니다. 그러나 이러한 모델들도 한계가 있습니다. 바로 최신 정보의 부재, 사실 확인의 어려움, 그리고 특정 도메인에 대한 전문 지식의 부족 등입니다.

이러한 한계를 극복하기 위해 등장한 기술이 바로 RAG(Retrieval-Augmented Generation)입니다. RAG는 기존의 생성 모델에 정보 검색 기능을 결합함으로써, 더욱 정확하고 최신의 정보를 바탕으로 한 응답을 생성할 수 있게 해줍니다. 본 글에서는 RAG의 개념, 필요성, 작동 원리, 그리고 실제 활용 사례에 대해 자세히 알아보겠습니다.

본론

1. RAG란 무엇인가?

RAG는 'Retrieval-Augmented Generation'의 약자로, '검색 증강 생성'이라고 번역할 수 있습니다. 이 기술은 크게 두 가지 주요 컴포넌트로 구성됩니다:

1. 검색(Retrieval) 컴포넌트: 주어진 쿼리나 맥락에 관련된 정보를 외부 데이터베이스나 지식 저장소에서 검색합니다.
2. 생성(Generation) 컴포넌트: 검색된 정보를 바탕으로 대규모 언어 모델이 응답을 생성합니다.

RAG의 핵심 아이디어는 모델이 응답을 생성할 때, 미리 학습된 지식뿐만 아니라 외부에서 검색한 관련 정보도 함께 활용한다는 것입니다. 이를 통해 모델의 응답 품질과 정확성을 크게 향상시킬 수 있습니다.

2. 왜 RAG가 필요한가?

RAG의 필요성은 기존 대규모 언어 모델의 한계에서 비롯됩니다. 이러한 한계점들을 살펴보고, RAG가 어떻게 이를 해결하는지 알아보겠습니다.

2.1 최신 정보의 부재

대규모 언어 모델은 학습 데이터의 시간적 제약을 받습니다. 예를 들어, GPT-3는 2022년 데이터까지만 학습되었기 때문에 그 이후의 사건이나 정보에 대해서는 알지 못합니다. 이는 실시간으로 변화하는 세계에서 큰 한계로 작용할 수 있습니다.

RAG는 이 문제를 해결합니다. 외부 데이터베이스나 지식 저장소를 활용하여 최신 정보를 검색하고, 이를 바탕으로 응답을 생성하기 때문에 항상 최신의 정보를 제공할 수 있습니다.

2.2 사실 확인의 어려움

대규모 언어 모델은 때때로 '환각(hallucination)'이라고 불리는 현상을 보입니다. 이는 모델이 사실이 아닌 정보를 그럴듯하게 생성하는 것을 말합니다. 이러한 현상은 모델의 신뢰성을 크게 떨어뜨리는 요인이 됩니다.

RAG는 이 문제를 완화시킵니다. 외부 소스에서 검증된 정보를 검색하여 활용하기 때문에, 생성된 응답의 사실성과 신뢰성이 크게 향상됩니다.

2.3 특정 도메인 지식의 한계

대규모 언어 모델은 광범위한 주제에 대해 일반적인 지식을 가지고 있지만, 특정 도메인에 대한 깊이 있는 전문 지식은 부족할 수 있습니다.

RAG는 특정 도메인의 전문 데이터베이스나 문서를 검색 소스로 활용함으로써 이 문제를 해결합니다. 이를 통해 특정 분야에 대한 깊이 있고 정확한 정보를 제공할 수 있습니다.

3. RAG는 어떻게 작동하는가?

RAG의 작동 원리를 단계별로 살펴보겠습니다.

3.1 쿼리 분석

사용자의 입력(쿼리)을 받으면, 시스템은 먼저 이 쿼리를 분석합니다. 이 과정에서 쿼리의 핵심 키워드나 의도를 파악합니다.

3.2 정보 검색

분석된 쿼리를 바탕으로 외부 데이터베이스나 지식 저장소에서 관련 정보를 검색합니다. 이 과정에서는 다양한 정보 검색 기술(예: TF-IDF, BM25, 의미론적 검색 등)이 사용될 수 있습니다.

3.3 컨텍스트 구성

검색된 정보들 중에서 가장 관련성 높은 것들을 선별하여 컨텍스트를 구성합니다. 이 컨텍스트는 원래의 쿼리와 함께 언어 모델의 입력으로 사용됩니다.

3.4 응답 생성

구성된 컨텍스트와 원래의 쿼리를 바탕으로 대규모 언어 모델이 최종 응답을 생성합니다. 이 과정에서 모델은 자신의 사전 학습된 지식과 검색된 정보를 결합하여 보다 정확하고 관련성 높은 응답을 만들어냅니다.

3.5 후처리

생성된 응답은 필요에 따라 후처리 과정을 거칩니다. 이는 응답의 포맷팅, 불필요한 정보 제거, 추가적인 사실 확인 등을 포함할 수 있습니다.

4. RAG의 활용 사례

RAG는 다양한 분야에서 활용되고 있습니다. 주요 활용 사례를 살펴보겠습니다.

4.1 질문 답변 시스템

RAG는 질문 답변 시스템의 성능을 크게 향상시킵니다. 특히 사실 기반의 질문에 대해 매우 효과적입니다. 예를 들어, "2023년 노벨 물리학상 수상자는 누구인가요?"와 같은 질문에 대해 RAG는 최신 정보를 검색하여 정확한 답변을 제공할 수 있습니다.

4.2 챗봇 및 가상 비서

RAG를 활용한 챗봇은 사용자의 질문에 대해 더욱 정확하고 맥락에 맞는 응답을 제공할 수 있습니다. 특히 기업 내부 지식 베이스와 연동된 RAG 기반 챗봇은 직원들의 업무 효율성을 크게 높일 수 있습니다.

4.3 콘텐츠 생성

RAG는 뉴스 기사, 보고서, 블로그 포스트 등 다양한 콘텐츠 생성에 활용될 수 있습니다. 최신 정보와 사실을 바탕으로 한 콘텐츠를 자동으로 생성함으로써, 작성자의 생산성을 크게 향상시킬 수 있습니다.

4.4 교육 및 학습 보조

RAG 기반 시스템은 학생들의 학습을 돕는 데 매우 효과적입니다. 학생의 질문에 대해 교과서나 신뢰할 수 있는 학술 자료를 바탕으로 답변을 제공함으로써, 개인화된 학습 경험을 제공할 수 있습니다.

4.5 의료 정보 시스템

의료 분야에서 RAG는 의사나 의료진에게 최신 의학 정보를 제공하는 데 활용될 수 있습니다. 예를 들어, 특정 질병의 최신 치료법이나 약물 정보를 신속하게 검색하고 요약하여 제공할 수 있습니다.

5. RAG 구현의 기술적 고려사항

RAG를 실제로 구현할 때 고려해야 할 몇 가지 중요한 기술적 요소들이 있습니다.

5.1 검색 엔진 선택

효과적인 정보 검색을 위해서는 적절한 검색 엔진의 선택이 중요합니다. Elasticsearch, Solr, Vespa 등의 전문 검색 엔진을 사용할 수 있으며, 경우에 따라 벡터 데이터베이스(예: Pinecone, Milvus)를 활용할 수도 있습니다.

5.2 임베딩 기술

텍스트 데이터를 효과적으로 검색하기 위해서는 적절한 임베딩 기술이 필요합니다. BERT, Sentence-BERT 등의 모델을 사용하여 텍스트를 고차원의 벡터로 변환하고, 이를 바탕으로 유사도 검색을 수행할 수 있습니다.

5.3 검색 결과 랭킹

검색된 여러 문서 중에서 가장 관련성 높은 것들을 선별하는 과정이 중요합니다. TF-IDF, BM25 등의 전통적인 랭킹 알고리즘뿐만 아니라, 머신러닝 기반의 랭킹 모델을 활용할 수 있습니다.

5.4 컨텍스트 길이 관리

대부분의 언어 모델은 입력 길이에 제한이 있기 때문에, 검색된 정보를 모두 사용할 수 없는 경우가 많습니다. 따라서 효과적으로 컨텍스트의 길이를 관리하는 전략이 필요합니다. 이는 중요한 정보를 요약하거나, 가장 관련성 높은 부분만을 선별하는 등의 방법을 포함할 수 있습니다.

5.5 실시간 성능 최적화

RAG 시스템의 실용성을 높이기 위해서는 실시간 성능 최적화가 중요합니다. 이는 캐싱, 분산 처리, GPU 가속화 등의 기술을 활용하여 달성할 수 있습니다.

6. RAG의 한계와 향후 과제

RAG가 많은 장점을 가지고 있지만, 여전히 몇 가지 한계와 해결해야 할 과제들이 있습니다.

6.1 검색 품질 의존성

RAG의 성능은 크게 검색 엔진의 품질에 의존합니다. 관련성 없는 정보가 검색되면, 이는 오히려 모델의 성능을 저하시킬 수 있습니다. 따라서 검색 알고리즘의 지속적인 개선이 필요합니다.

6.2 계산 비용

RAG는 추가적인 검색 단계가 필요하기 때문에, 일반적인 언어 모델에 비해 더 많은 계산 자원과 시간이 필요합니다. 이는 실시간 응답이 필요한 애플리케이션에서 제약 사항이 될 수 있습니다.

6.3 정보의 신뢰성

외부 소스에서 검색된 정보의 신뢰성을 보장하는 것은 여전히 중요한 과제입니다. 잘못된 정보나 편향된 정보가 포함될 경우, 이는 모델의 출력에 부정적인 영향을 미칠 수 있습니다.

6.4 컨텍스트 통합의 어려움

검색된 정보를 효과적으로 기존의 지식과 통합하는 것은 여전히 도전적인 과제입니다. 때로는 검색된 정보와 모델의 사전 지식 사이에 불일치가 발생할 수 있으며, 이를 해결하는 것이 필요합니다.

7. RAG의 미래 전망

RAG 기술은 계속해서 발전하고 있으며, 앞으로 더욱 중요한 역할을 할 것으로 예상됩니다. 몇 가지 주목할 만한 발전 방향을 살펴보겠습니다.

7.1 멀티모달 RAG

현재의 RAG는 주로 텍스트 기반 정보를 다루지만, 앞으로는 이미지, 비디오, 오디오 등 다양한 형태의 데이터를 포함하는 멀티모달 RAG로 발전할 것으로 예상됩니다. 이는 더욱 풍부하고 다양한 정보를 바탕으로 한 응답 생성을 가능하게 할 것입니다.

7.2 실시간 정보 통합

현재의 RAG 시스템은 주로 정적인 데이터베이스를 사용하지만, 앞으로는 실시간으로 업데이트되는 정보 소스를 통합할 수 있는 방향으로 발전할 것입니다. 이를 통해 더욱 최신의, 실시간 정보를 바탕으로 한 응답이 가능해질 것입니다.

7.3 개인화된 RAG

사용자의 개인 정보, 선호도, 과거 상호작용 기록 등을 고려한 개인화된 RAG 시스템이 발전할 것으로 예상됩니다. 이는 각 사용자에게 더욱 관련성 높고 맞춤화된 정보를 제공할 수 있게 할 것입니다.

7.4 설명 가능한 RAG

RAG 시스템의 의사결정 과정을 더욱 투명하게 만드는 '설명 가능한 RAG' 기술의 발전이 예상됩니다. 이는 시스템이 왜 특정 정보를 검색했고, 어떻게 그 정보를 활용하여 응답을 생성했는지를 사용자가 이해할 수 있게 해줄 것입니다.

7.5 자가 학습 RAG

기존의 RAG 시스템은 정적인 검색 인덱스를 사용하지만, 앞으로는 사용자와의 상호작용을 통해 지속적으로 학습하고 개선되는 '자가 학습 RAG' 시스템이 개발될 것으로 예상됩니다. 이는 시간이 지날수록 더욱 정확하고 관련성 높은 정보를 제공할 수 있게 할 것입니다.

결론

RAG(Retrieval-Augmented Generation)는 기존의 대규모 언어 모델의 한계를 극복하고, 더욱 정확하고 최신의 정보를 바탕으로 한 응답을 생성할 수 있게 해주는 혁신적인 기술입니다. 정보 검색과 텍스트 생성을 결합함으로써, RAG는 다양한 분야에서 활용되며 인공지능의 성능을 한 단계 더 끌어올리고 있습니다.

그러나 RAG 기술은 여전히 발전 중이며, 검색 품질 의존성, 계산 비용, 정보의 신뢰성 등 여러 과제들이 남아있습니다. 이러한 한계를 극복하고 RAG의 잠재력을 최대한 활용하기 위해서는 지속적인 연구와 혁신이 필요할 것입니다.

앞으로 RAG는 멀티모달 데이터 처리, 실시간 정보 통합, 개인화, 설명 가능성, 자가 학습 등의 방향으로 발전해 나갈 것으로 예상됩니다. 이러한 발전은 인공지능이 더욱 지능적이고, 신뢰할 수 있으며, 인간의 필요에 더욱 부합하는 방향으로 나아가는 데 큰 역할을 할 것입니다.

RAG 기술은 인공지능과 인간의 상호작용을 더욱 풍부하고 유용하게 만들어줄 것입니다. 이는 단순히 기술의 발전을 넘어, 우리가 정보를 이해하고 활용하는 방식을 근본적으로 변화시킬 수 있는 잠재력을 가지고 있습니다. 앞으로 RAG가 어떻게 발전하고 우리의 삶에 어떤 영향을 미칠지 지켜보는 것은 매우 흥미로울 것입니다.

Read More

코드 스니펫이란?

코드 스니펫이란?

코드 스니펫에 대해 더 자세히 설명해 드리겠습니다.

인트로::

오늘은 코드 스니펫에 대해 더 자세히 설명해 드리겠습니다. 코드 스니펫은 무엇일까요?

1. 코드 스니펫 - 무엇인가:

   코드 스니펫은 특정 기능을 수행하는 재사용 가능한 작은 코드 조각입니다. 보통 몇 줄에서 수십 줄 정도의 길이를 가집니다.

2. 코드 스니펫 - 왜 필요한가:

   a) 시간 절약: 자주 사용하는 코드를 빠르게 삽입할 수 있어 개발 시간을 단축합니다.

   b) 일관성 유지: 동일한 기능에 대해 항상 같은 코드를 사용할 수 있습니다.

   c) 오류 감소: 검증된 코드를 재사용함으로써 실수를 줄일 수 있습니다.

   d) 학습 도구: 복잡한 개념이나 패턴을 쉽게 이해하고 적용할 수 있습니다.

   e) 문서화: API나 라이브러리 사용법을 간단히 예시로 보여줄 수 있습니다.

3. 코드 스니펫 - 어떻게 사용하는가:

  코드 스니펫은  재사용성에서 뛰어납니다. 다양한 프로젝트나 상황에서 쉽게 복사하여 사용할 수 있기 때문입니다.

   a) IDE/에디터 기능 활용:

      - 많은 개발 환경에서 스니펫 생성 및 삽입 기능을 제공합니다.

      - 단축키나 명령을 통해 스니펫을 빠르게 삽입할 수 있습니다.

   b) 온라인 리포지토리 활용:

      - GitHub Gist, Pastebin 등의 서비스를 통해 스니펫을 공유하고 검색할 수 있습니다.

   c) 직접 생성 및 관리:

      - 자주 사용하는 코드를 스니펫으로 저장하여 개인 라이브러리를 만들 수 있습니다.

      - 팀 내에서 유용한 스니펫을 공유하여 협업 효율을 높일 수 있습니다.

   d) 학습 및 참조:

      - 새로운 프로그래밍 개념이나 라이브러리를 배울 때 관련 스니펫을 찾아 학습에 활용합니다.

결론::

지금까지 우리는 코드 스니펫을 효과적으로 사용하면 개발 생산성을 크게 향상시킬 수 있다는 것을 알 수 있습니다. 하지만 스니펫을 무분별하게 사용하지 않도록 주의하고, 항상 현재 상황에 맞게 수정하여 사용해야 합니다.

1. 재사용성: 다양한 프로젝트나 상황에서 쉽게 복사하여 사용할 수 있습니다.
2. 예시 제공: 프로그래밍 개념이나 API 사용법을 설명할 때 자주 활용됩니다.
3. 생산성 향상: 자주 사용하는 코드 패턴을 빠르게 삽입할 수 있어 개발 속도를 높입니다.
4. 학습 도구: 초보자들이 특정 프로그래밍 개념을 이해하는 데 도움을 줍니다.

많은 개발 환경(IDE)과 텍스트 에디터는 코드 스니펫 기능을 제공하여 개발자가 쉽게 스니펫을 만들고 사용할 수 있게 합니다.

Read More

색상 구성표 도구 - Color Picker Webpage

색상 선택기

이 코드의 특징:

1. 순수 HTML과 인라인 CSS만 사용하여 Google 블로그와의 호환성을 최대화했습니다.
2. 간단한 색상 팔레트를 제공합니다 (12가지 기본 색상).
3. 각 색상 블록을 클릭하면 해당 색상의 16진수 코드를 알림창으로 보여줍니다.
4. 레이아웃과 스타일은 원래 디자인과 유사하게 유지했습니다.

사용 방법:

1. Google 블로그 포스트 편집 화면에서 HTML 편집 모드로 전환합니다.
2. 위의 코드를 원하는 위치에 붙여넣기 합니다.
3. 포스트를 저장하고 미리보기로 확인합니다.

이 간소화된 버전은 동적 기능은 없지만, Google 블로그에서 안전하게 작동하며 기본적인 색상 선택 기능을 제공합니다. 사용자는 색상을 클릭하여 해당 색상 코드를 확인할 수 있습니다.

Read More

Github Page페이지 만들기-가이드

GitHub Pages 빠른 시작

GitHub Pages를 사용하여 일부 오픈 소스 프로젝트를 소개하거나, 블로그를 호스트하거나, 이력서를 공유할 수도 있습니다. 이 가이드는 다음 번 웹 사이트 만들기를 시작할 때 도움이 됩니다.

누가 이 기능을 사용할 수 있나요?

GitHub Pages은(는) 조직의 GitHub Free 및 GitHub Free이(가) 있는 퍼블릭 리포지토리와 GitHub Pro, GitHub Team, GitHub Enterprise Cloud 및 GitHub Enterprise Server의 퍼블릭 및 프라이빗 리포지토리에서 사용할 수 있습니다. 자세한 내용은 “GitHub의 플랜”를 참조하세요.

GitHub Pages은(는) 이제 GitHub Actions을(를) 사용하여 Jekyll 빌드를 실행합니다. 빌드의 원본으로 분기를 사용하는 경우 기본 제공 Jekyll 워크플로를 사용하려면 리포지토리에서 GitHub Actions을(를) 사용하도록 설정해야 합니다. 또는 GitHub Actions을(를) 사용할 수 없거나 사용하지 않도록 설정한 경우 원본 분기의 루트에 .nojekyll 파일을 추가하면 Jekyll 빌드 프로세스를 무시하고 콘텐츠를 직접 배포합니다. GitHub Actions 사용에 대한 자세한 내용은 "리포지토리에 대한 GitHub Actions 설정 관리"을 참조하세요.

소개

GitHub Pages는 GitHub를 통해 호스트되고 게시되는 퍼블릭 웹 페이지입니다. 시작하고 실행하는 가장 빠른 방법은 Jekyll 테마 선택기를 사용하여 미리 만들어진 테마를 로드하는 것입니다. 그런 다음 GitHub Pages 콘텐츠 및 스타일을 수정할 수 있습니다.

이 가이드에서는 username.github.io에서 사용자 사이트를 만드는 작업을 안내합니다.

웹 사이트 만들기

임의 페이지의 오른쪽 위에 있는 을(를) 클릭한 다음, 신규 리포지토리를 클릭합니다.


리포지토리 이름으로 username.github.io를 입력합니다. username을 GitHub 사용자 이름으로 바꿉니다. 예를 들어 사용자 이름이 octocat이면 리포지토리 이름은 octocat.github.io입니다.


리포지토리 표시 여부를 선택합니다. 자세한 내용은 "리포지토리 정보"을(를) 참조하세요.

추가 정보를 사용하여 이 리포지토리 초기화를 선택합니다.

Create repository(리포지토리 만들기)를 클릭합니다.

리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.


사이드바의 “코드 및 자동화” 섹션에서 페이지를 클릭합니다.

"빌드 및 배포"의 "원본"에서 분기에서 배포를 선택합니다.

"빌드 및 배포"의 "분기"에서 분기 드롭다운 메뉴를 사용하여 게시 원본을 선택합니다.


필요에 따라 리포지토리의 README.md 파일을 엽니다. README.md 파일에서 사이트의 콘텐츠를 작성하게 됩니다. 지금 파일을 편집하거나 기본 콘텐츠를 유지할 수 있습니다.

username.github.io를 방문하여 새 웹 사이트를 봅니다. 참고: GitHub에 변경 내용을 푸시한 후 사이트 변경 내용이 게시되려면 최대 10분이 걸릴 수 있습니다.

 

제목 및 설명 변경

기본적으로 사이트의 제목은 username.github.io입니다. 리포지토리에서 _config.yml 파일을 편집하여 제목을 변경할 수 있습니다. 사이트에 대한 설명을 추가할 수도 있습니다.

• 리포지토리의 코드 탭을 클릭합니다.
• 파일 목록에서 _config.yml을 클릭하여 파일을 엽니다.
• 아이콘을 클릭하여 파일을 편집합니다.

_config.yml 파일에는 사이트의 테마를 지정하는 줄이 이미 포함되어 있습니다. 

• title: 뒤에 원하는 제목이 표시되는 새 줄을 추가합니다. 
• description: 뒤에 원하는 설명이 표시되는 새 줄을 추가합니다. 
• 예시:

theme: jekyll-theme-minimal 

title:Octocat'shomepage   

description: Book mark this to keep an eye on my project updates!

파일 편집을 마쳤으면 변경 내용 커밋을 클릭합니다.

 

다음 단계

사이트에 페이지를 추가하는 방법에 대한 자세한 내용은 "Jekyll을 사용하여 GitHub Pages 사이트에 콘텐츠 추가"을(를) 참조하세요.

Jekyll을 사용하여 GitHub Pages 사이트를 설정하는 방법에 대한 자세한 내용은 “GitHub Pages 및 Jekyll 정보”을(를) 참조하세요.

Read More

gitHub 게시 원본 정보

참조:: https://docs.github.com/ko/pages

게시 원본 정보

변경 내용이 특정 분기로 푸시될 때 사이트를 게시하거나 GitHub Actions 워크플로를 작성하여 사이트를 게시할 수 있습니다.

사이트의 빌드 프로세스를 제어할 필요가 없는 경우 변경 내용이 특정 분기로 푸시될 때 사이트를 게시하는 것이 좋습니다. 게시 원본으로 사용할 분기 및 폴더를 지정할 수 있습니다. 원본 분기는 리포지토리의 모든 분기일 수 있으며 원본 폴더는 원본 분기에 있는 리포지토리(/)의 루트이거나 원본 분기의 /docs 폴더일 수 있습니다. 변경 내용이 원본 분기로 푸시될 때마다 원본 폴더의 변경 내용이 GitHub Pages 사이트에 게시됩니다.

Jekyll 이외의 빌드 프로세스를 사용하거나 전용 분기에서 컴파일된 정적 파일을 보관하지 않으려면 GitHub Actions 워크플로를 작성하여 사이트를 게시하는 것이 좋습니다. GitHub은(는) 워크플로를 작성하는 데 도움이 되는 일반적인 게시 시나리오를 위한 시작 워크플로를 제공합니다.

경고: 사이트의 리포지토리가 프라이빗인 경우에도 GitHub Pages 사이트는 인터넷에서 공개적으로 사용할 수 있습니다(해당 요금제 또는 조직에서 허용하는 경우). 사이트의 리포지토리에 중요한 데이터가 있는 경우 게시하기 전에 데이터를 제거할 수 있습니다. 자세한 내용은 "리포지토리 정보"을(를) 참조하세요.

분기에서 게시

1. 게시 원본으로 사용할 분기가 리포지토리에 이미 있는지 확인합니다.

2. GitHub에서 사이트의 리포지토리로 이동합니다.

3. 리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

   

4. 사이드바의 “코드 및 자동화” 섹션에서  페이지를 클릭합니다.

5. "빌드 및 배포"의 "원본"에서 분기에서 배포를 선택합니다.

6. "빌드 및 배포"에서 분기 드롭다운 메뉴를 사용하여 게시 원본을 선택합니다.

   

7. 필요에 따라 폴더 드롭다운 메뉴를 사용하여 게시 원본의 폴더를 선택합니다.

   

8. 저장을 클릭합니다.

분기에서 게시 문제 해결

Note: If your repository contains symbolic links, you will need to publish your site using a GitHub Actions workflow. For more information about GitHub Actions, see "GitHub Actions 설명서."

참고:

• 분기에서 게시하는 경우 및 관리자 권한과 확인된 메일 주소를 가진 사람이 게시 원본으로 푸시되었는지 확인합니다.

• GITHUB_TOKEN을 사용하는 GitHub Actions 워크플로에서 푸시한 커밋은 GitHub Pages 빌드를 트리거하지 않습니다.

분기의 docs 폴더를 게시 원본으로 선택하고 나중에 리포지토리의 해당 분기에서 /docs 폴더를 제거한 경우 사이트가 빌드되지 않으며 누락된 /docs 폴더에 대한 페이지 빌드 오류 메시지가 표시됩니다. 자세한 내용은 "GitHub 페이지 사이트에 대한 Jekyll 빌드 오류 문제 해결"을(를) 참조하세요.

다른 CI 도구를 사용하여 GitHub Pages 사이트를 빌드하도록 구성한 경우에도 GitHub Pages 사이트는 항상 GitHub Actions 워크플로 실행과 함께 배포됩니다. 대부분의 외부 CI 워크플로는 빌드 출력을 리포지토리의 gh-pages 분기에 커밋하여 GitHub Pages에 “배포”하며 일반적으로 .nojekyll 파일을 포함합니다. 이 경우 GitHub Actions 워크플로는 분기에 빌드 단계가 필요하지 않은 상태를 검색하고 사이트를 GitHub Pages 서버에 배포하는 데 필요한 단계만 실행합니다.

빌드 또는 배포에서 잠재적인 오류를 찾으려면 리포지토리의 워크플로 실행을 검토하여 GitHub Pages 사이트에 대한 워크플로 실행을 검사할 수 있습니다. 자세한 내용은 "워크플로 실행 기록 보기"을(를) 참조하세요. 오류가 발생할 경우 워크플로를 다시 실행하는 방법에 대한 자세한 내용은 “워크플로 및 작업 다시 실행”을(를) 참조하세요.

사용자 지정 GitHub Actions 워크플로를 사용하여 게시

GitHub Actions을(를) 사용하여 게시하도록 사이트를 구성하려면 다음을 수행합니다.

1. GitHub에서 사이트의 리포지토리로 이동합니다.

2. 리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

   

3. 사이드바의 “코드 및 자동화” 섹션에서  페이지를 클릭합니다.

4. "빌드 및 배포"의 "원본"에서 GitHub Actions 을(를) 선택합니다.

5. GitHub은(는) 몇 가지 시작 워크플로를 제안합니다. 사이트를 게시할 워크플로가 이미 있는 경우 이 단계를 건너뛸 수 있습니다. 그렇지 않으면 GitHub Actions 워크플로를 만드는 옵션 중 하나를 선택합니다. 사용자 지정 워크플로를 만드는 방법에 대한 자세한 내용은 "사이트를 게시하는 사용자 지정 GitHub Actions 워크플로 만들기"를 참조하세요.

   GitHub Pages은(는) 특정 워크플로를 GitHub Pages 설정에 연결하지 않습니다. 그러나 GitHub Pages 설정은 가장 최근에 사이트를 배포한 워크플로 실행에 연결됩니다.

사용자 지정 GitHub Actions 워크플로를 만들어 사이트 게시

GitHub Actions에 대한 자세한 내용은 "GitHub Actions 설명서"을(를) 참조하세요.

GitHub Actions을(를) 사용하여 게시하도록 사이트를 구성할 때 GitHub은(는) 일반적인 게시 시나리오에 대한 시작 워크플로를 제안합니다. 워크플로의 일반적인 흐름은 다음과 같습니다.

1. 리포지토리의 기본 분기에 푸시가 있거나 작업 탭에서 워크플로를 수동으로 실행할 때마다 트리거합니다.
2. actions/checkout 작업을 사용하여 리포지토리 콘텐츠를 확인합니다.
3. 사이트에서 필요한 경우 정적 사이트 파일을 빌드합니다.
4. actions/upload-pages-artifact 작업을 사용하여 정적 파일을 아티팩트로 업로드합니다.
5. 워크플로가 기본 분기로 푸시하여 트리거된 경우 actions/deploy-pages 작업을 사용하여 아티팩트를 배포합니다. 워크플로가 끌어오기 요청에 의해 트리거된 경우 이 단계를 건너뜁니다.

시작 워크플로는 github-pages라는 배포 환경을 사용합니다. 리포지토리에 아직 github-pages라는 환경이 포함되어 있지 않으면 환경이 자동으로 만들어집니다. 기본 분기만 이 환경에 배포할 수 있도록 배포 보호 규칙을 추가하는 것이 좋습니다. 자세한 내용은 "배포 환경 관리"을(를) 참조하세요.

참고: 리포지토리 파일의 CNAME 파일은 사용자 지정 도메인을 자동으로 추가하거나 제거하지 않습니다. 대신 리포지토리 설정 또는 API를 통해 사용자 지정 도메인을 구성해야 합니다. 자세한 내용은 "GitHub Pages 사이트의 사용자 지정 도메인 관리" 및 "GitHub Pages에 대한 REST API 엔드포인트"을 참조하세요.

사용자 지정 GitHub Actions 워크플로를 사용하여 게시 문제 해결

GitHub Actions 워크플로의 문제를 해결하는 방법에 대한 자세한 내용은 "워크플로 모니터링 및 문제 해결"을(를) 참조하세요.

Read More

GitHub Pages 사이트 유형

 GitHub Pages 사이트 유형

GitHub Pages 사이트에는 프로젝트, 사용자 및 조직, 이렇게 세 가지 유형이 있습니다. 프로젝트 사이트는 JavaScript 라이브러리 또는 레시피 컬렉션과 같이 GitHub에서 호스트되는 특정 프로젝트에 연결됩니다. 사용자 및 조직 사이트는 GitHub.com의 특정 계정에 연결됩니다.

사용자 사이트를 게시하려면 <username>.github.io이라는 개인 계정이 소유한 리포지토리를 만들어야 합니다. 조직 사이트를 게시하려면 <organization>.github.io이라는 조직이 소유한 리포지토리를 만들어야 합니다. 사용자 지정 도메인을 사용하지 않는 한 사용자 및 조직 사이트는 http(s)://<username>.github.io 또는 http(s)://<organization>.github.io에서 사용할 수 있습니다.

URL은 형식

프로젝트 사이트의 원본 파일은 프로젝트와 동일한 리포지토리에 저장됩니다. 사용자 지정 도메인을 사용하지 않는 경우 프로젝트 사이트는 http(s)://<username>.github.io/<repository> 또는 http(s)://<organization>.github.io/<repository>에서 사용할 수 있습니다.

사용자 지정 도메인이 사이트의 URL에 미치는 영향에 대한 자세한 내용은 "사용자 지정 도메인 및 GitHub Pages 정보"을(를) 참조하세요.

GitHub에서 각 계정에 대해 하나의 사용자 또는 조직 사이트만 만들 수 있습니다. 조직 또는 개인 계정이 소유하든 관계 없이 프로젝트 사이트는 무제한입니다.

https://docs.github.com/ko/pages/getting-started-with-github-pages/about-github-pages

Read More