Open WebUI에 기여할 준비가 되셨나요? 시작해봅시다! 🚀

Open WebUI 개발에 뛰어들 준비가 되었나요? 이 종합적인 가이드는 로컬 개발 환경을 빠르고 쉽게 설정할 수 있도록 도와줄 것입니다. 경험 많은 개발자든 초보자든 관계없이, 프런트엔드를 수정하고, 백엔드를 개선하며 Open WebUI의 미래에 기여할 준비를 할 수 있도록 안내합니다! 간단하고 상세한 단계로 개발 환경을 준비해봅시다!

사전 준비

시작하기 전에 시스템이 다음 최소 요구 사항을 충족하는지 확인하세요:

• 운영 체제: Linux (또는 Windows의 WSL), Windows 11, 또는 macOS. (최상의 호환성을 위해 권장)
• Python: 3.11 이상 버전. (백엔드 서비스 필수)
• Node.js: 22.10 이상 버전. (프런트엔드 개발 필수)
• 권장 IDE: VSCode와 같은 IDE를 사용하여 코드 편집, 디버깅 및 통합 터미널 접근을 권장합니다. 선호하는 IDE가 있다면 사용하셔도 좋습니다!
• [선택 사항] GitHub Desktop: 커맨드라인 Git 사용이 익숙하지 않은 경우 Git 저장소 관리를 더 쉽게 하기 위해 GitHub Desktop 설치를 고려해 보세요.

로컬 환경 설정

Open WebUI의 프런트엔드 (사용자 인터페이스)와 백엔드 (API 및 서버 로직) 모두를 설정하겠습니다.

1. 리포지토리 클론

먼저 git clone 명령을 사용하여 Open WebUI 리포지토리를 로컬 머신에 다운로드하세요. 이는 로컬 컴퓨터에 프로젝트 복사본을 생성합니다.

1. 터미널 열기 (Windows에서 Git Bash를 사용 중이라면 Git Bash를 엽니다).
2. Open WebUI 프로젝트를 저장할 디렉토리로 이동.
3. 리포지토리를 클론: 다음 명령을 실행하세요:

git clone https://github.com/open-webui/open-webui.git
cd open-webui

git clone 명령이 GitHub에서 프로젝트 파일을 다운로드합니다. cd open-webui 명령은 새로 생성된 프로젝트 디렉토리로 이동합니다.

2. 프런트엔드 설정 (사용자 인터페이스)

먼저 사용자 인터페이스(브라우저에 표시되는 부분)를 실행해봅시다:

1. 환경 변수 구성:

   • 예제 환경 변수를 .env로 복사:

     cp -RPp .env.example .env

     이 명령은 .env.example 파일을 .env라는 새 파일로 복사합니다. .env 파일은 프런트엔드의 환경 변수를 구성합니다.

   • .env 파일 커스터마이징: 코드 편집기(예: VSCode)에서 .env 파일을 엽니다. 이 파일에는 API 엔드포인트 및 기타 설정과 같은 프런트엔드 구성 변수가 포함되어 있습니다. 로컬 개발에서는 .env.example의 기본 설정으로도 충분히 시작할 수 있습니다. 그러나 필요하면 이를 커스터마이징할 수 있습니다.

중요: 리포지토리에 기여할 때 .env에 민감한 정보를 커밋하지 마세요.

1. 프런트엔드 종속성 설치:

   • 프런트엔드 디렉토리로 이동: 프로젝트 루트(open-webui 디렉토리)에 있는지 확인하세요.

     # 프로젝트 루트가 아닌 경우 실행:
     cd open-webui

   • 필요한 JavaScript 패키지 설치:

     npm install

     이 명령은 npm(Node 패키지 관리자)을 사용하여 프로젝트 루트 디렉토리의 package.json 파일을 읽고 프런트엔드 실행에 필요한 모든 JavaScript 라이브러리와 도구를 다운로드합니다. 인터넷 연결 속도에 따라 시간이 좀 걸릴 수 있습니다.

2. 프런트엔드 개발 서버 시작:

   npm run dev

   이 명령은 프런트엔드 개발 서버를 실행합니다. 단계를 올바르게 따르면 서버가 실행 중임을 나타내고 로컬 URL을 제공할 것입니다.

   🎉 프런트엔드 접근: 웹 브라우저를 열고 http://localhost:5173으로 이동하세요. Open WebUI의 프런트엔드가 실행 중이며 백엔드가 사용 가능해지기를 기다리는 메시지가 표시될 것입니다. 아직 걱정하지 마세요! 이제 백엔드를 설정해봅시다. 이 터미널은 계속 실행 상태로 유지하세요 – 프런트엔드를 제공하고 있습니다!

3. 백엔드 설정 (API 및 서버)

더 원활한 개발 경험을 위해 프런트엔드 및 백엔드 프로세스에 별도의 터미널 인스턴스를 사용하는 것을 강력히 권장합니다. 이는 작업 흐름을 더 체계적으로 유지하고 애플리케이션의 각 부분을 독립적으로 관리하기 쉽게 만듭니다.

왜 별도의 터미널이 필요한가요?

• 프로세스 분리: 프런트엔드와 백엔드 개발 서버는 별개의 프로그램입니다. 별도의 터미널에서 실행하면 서로 간섭하지 않고 독립적으로 재시작하거나 중지할 수 있습니다.
• 더 명확한 로그와 출력: 각 터미널은 프론트엔드 또는 백엔드와 관련된 로그와 출력을 별도로 표시합니다. 로그가 섞여 있어 찾기 어려운 경우 없이, 디버깅과 모니터링이 훨씬 쉬워집니다.
• 터미널 혼란 감소: 하나의 터미널에서 프론트엔드와 백엔드 명령어를 혼합하여 실행하면 혼란스러울 수 있습니다. 분리된 터미널은 명령어 기록과 활성 프로세스를 체계적으로 유지합니다.
• 워크플로우 효율성 향상: 한 터미널에서는 프론트엔드 작업(npm run dev 실행 등)을 수행하고, 동시에 다른 터미널에서는 백엔드 작업(서버 시작, 로그 확인 등)을 관리할 수 있습니다. 이 방식은 한 터미널에서 계속 컨텍스트를 전환하지 않아도 되므로 효율적입니다.

VSCode 통합 터미널 사용 (권장):

VSCode의 통합 터미널 기능은 여러 터미널 관리를 매우 간단하게 만들어줍니다. 프론트엔드와 백엔드 분리를 위해 다음을 활용해보세요:

1. 프론트엔드 터미널 (이미 열려 있을 가능성이 높음): 프론트엔드 설정 단계를 따랐다면, 아마 이미 프로젝트 루트(open-webui 디렉토리)에서 VSCode 터미널을 열었을 것입니다. 여기서 프론트엔드 명령어(npm run dev 등)를 실행합니다. 다음 단계를 진행하기 전에 open-webui 디렉토리에 있는지 확인하세요.

2. 백엔드 터미널 (새로 열기):

   • VSCode에서 Terminal > New Terminal로 이동 (또는 Windows/Linux의 경우 Ctrl+Shift+ 단축키, macOS의 경우 Cmd+Shift+ 사용)하여 새 통합 터미널 패널을 엽니다.
   • backend 디렉토리로 이동: 이 새로운 터미널에서 cd backend 명령어를 사용하여 프로젝트의 backend 폴더로 디렉토리를 변경합니다. 이렇게 하면 모든 백엔드 관련 명령어가 올바른 컨텍스트에서 실행됩니다.

   이제 VSCode 내에서 프론트엔드(open-webui 디렉토리)에 대한 터미널과 백엔드(backend 디렉토리)에 대한 터미널 두 개를 가지게 됩니다. VSCode 내에서 이들 터미널 간을 쉽게 전환하여 프론트엔드와 백엔드 프로세스를 독립적으로 관리할 수 있습니다. 이 설정은 보다 깔끔하고 효율적인 개발 워크플로우를 위해 강력히 추천됩니다.

백엔드 설정 단계 (백엔드 터미널에서):

1. 백엔드 디렉토리로 이동: (이전 단계에서 새로운 터미널에서 이미 backend 디렉토리에 있어야 합니다.) 그렇지 않다면 다음을 실행하세요:

   cd backend

2. Conda 환경 생성 및 활성화 (권장):

   • Conda를 사용하여 Python 종속성과 프로젝트 환경을 관리하는 것을 강력히 권장드립니다. 이는 시스템 내 다른 Python 프로젝트와의 충돌을 방지하고, 올바른 Python 버전 및 라이브러리를 보장합니다.

     conda create --name open-webui python=3.11
     conda activate open-webui
     • conda create --name open-webui python=3.11: 이 명령어는 Python 3.11 버전을 사용하는 open-webui라는 이름의 새로운 Conda 환경을 생성합니다. 선택한 Python 3.11.x 버전이 다르더라도 괜찮습니다.
     • conda activate open-webui: 이 명령어는 새로 생성된 Conda 환경을 활성화합니다. 활성화되면 터미널 프롬프트가 일반적으로 open-webui 환경에 있음을 나타내도록 변경됩니다 (예: (open-webui)가 줄의 시작에 표시될 수 있음).

   백엔드 터미널에서 환경을 활성화한 후 진행하십시오.

   (Conda 사용은 선택 사항이지만, Python 종속성 관리 및 충돌 방지를 위해 강력히 권장됩니다.) Conda 사용을 선택하지 않더라도, Python 3.11 이상을 사용하고 있다면 다음 단계로 진행할 수 있지만 종속성 충돌 가능성에 유의하십시오.

3. 백엔드 종속성 설치:

   • 백엔드 터미널에서 (Conda를 사용하는 경우 활성화된 상태에서) 다음을 실행하세요:

   pip install -r requirements.txt -U

   이 명령어는 pip (Python 패키지 관리자)를 사용하여 backend 디렉토리 내의 requirements.txt 파일을 읽습니다. requirements.txt는 백엔드 실행에 필요한 모든 Python 라이브러리를 나열합니다. pip install은 이러한 라이브러리를 활성 Python 환경 (Conda 환경 사용 시 해당 환경, 아니면 시스템 전체 Python 환경)에 다운로드하고 설치합니다. -U 플래그는 호환되는 최신 버전의 라이브러리를 보장합니다.

4. 백엔드 개발 서버 시작:

   • 백엔드 터미널에서 다음을 실행합니다:

   sh dev.sh

   이 명령어는 dev.sh 스크립트를 실행합니다. 이 스크립트는 백엔드 개발 서버를 시작하는 명령어를 포함하고 있을 가능성이 큽니다. (명령어가 실행 중 무엇을 하는지 궁금하다면, 코드 편집기에서 dev.sh 파일을 열어 구체적인 내용을 확인할 수 있습니다.) 백엔드 서버는 일반적으로 시작 후 터미널에 출력을 표시합니다.

   📄 API 문서 탐색하기: 백엔드가 실행 중일 때, 웹 브라우저에서 자동 생성된 API 문서에 http://localhost:8080/docs에서 액세스할 수 있습니다. 이 문서는 백엔드 API 엔드포인트, 백엔드와 상호 작용하는 방법 및 예상/반환되는 데이터를 이해하는 데 매우 유용합니다. 개발 중 이 문서를 잘 활용하세요!

🎉 축하합니다! 모든 단계를 따랐다면 로컬에서 프론트엔드와 백엔드 개발 서버가 모두 실행 중일 것입니다. 프론트엔드에 액세스했던 브라우저 탭(보통 http://localhost:5173)으로 돌아가세요. 페이지를 새로고침하세요. 이제 브라우저에서 로컬 백엔드와 연결된 전체 Open WebUI 애플리케이션을 볼 수 있습니다!

일반적인 문제 해결

설치나 개발 중에 발생할 수 있는 몇 가지 일반적인 문제에 대한 해결 방법은 다음과 같습니다:

💥 "FATAL ERROR: Reached Heap Limit" (프론트엔드)

이 오류는 주로 대규모 프론트엔드 애플리케이션을 작업할 때 빌드 과정에서 Node.js가 메모리 부족으로 인해 발생합니다.

해결 방법: Node.js 힙 크기를 늘려 Node.js가 사용할 메모리를 더 확보하세요. 몇 가지 옵션이 있습니다:

1. NODE_OPTIONS 환경 변수 사용 (개발 권장):

   • 현재 터미널 세션에서 메모리 제한을 임시로 늘리는 방법입니다. 프론트엔드 터미널에서 npm run dev 또는 npm run build를 실행하기 전에 NODE_OPTIONS 환경 변수를 설정하세요:

     export NODE_OPTIONS="--max-old-space-size=4096" # Linux/macOS (bash, zsh)용
     # set NODE_OPTIONS=--max-old-space-size=4096 # Windows (명령 프롬프트)용
     # $env:NODE_OPTIONS="--max-old-space-size=4096" # Windows (PowerShell)용
     npm run dev

     운영 체제 및 터미널에 맞는 명령을 선택하세요. 4096은 4GB 메모리를 나타냅니다. 필요에 따라 값을 더 증가시킬 수도 있습니다(예: 8GB에 대해 8192). 이 설정은 현재 터미널 세션에서 실행되는 명령에만 적용됩니다.

2. Dockerfile 수정하기 (도커 환경용):

   • 도커를 사용하는 경우 Dockerfile 내에서 NODE_OPTIONS 환경 변수를 영구적으로 설정할 수 있습니다. 이는 도커 환경에서 일관된 메모리 할당에 유용합니다. 예시는 다음과 같습니다:

     ENV NODE_OPTIONS=--max-old-space-size=4096

   • 충분한 RAM 할당: 방법에 관계없이, Node.js에서 사용할 수 있는 충분한 RAM이 시스템 또는 도커 컨테이너에 있는지 확인하세요. 최소 4GB RAM을 권장하며, 대형 프로젝트나 복잡한 빌드의 경우 더 많은 RAM이 필요할 수 있습니다. 불필요한 애플리케이션을 닫아 RAM을 확보하세요.

⚠️ 포트 충돌 (프론트엔드 & 백엔드)

포트와 관련된 "Address already in use" 또는 "Port already bound"와 같은 오류가 발생하면, 이는 시스템의 다른 애플리케이션이 5173(프론트엔드 기본값) 또는 8080(백엔드 기본값) 포트를 이미 사용 중임을 의미합니다. 특정 포트는 한 번에 하나의 애플리케이션만 사용할 수 있습니다.

해결 방법:

1. 충돌하는 프로세스 식별: 필요한 포트를 사용 중인 애플리케이션을 찾아야 합니다.

   • Linux/macOS: 새 터미널을 열고 lsof 또는 netstat 명령을 사용하세요:
     • lsof -i :5173 (또는 백엔드 포트의 경우 :8080)
     • netstat -tulnp | grep 5173 (또는 8080) 이러한 명령은 사용 중인 포트의 프로세스 ID(PID)와 프로세스 이름을 나열합니다.
   • Windows: 관리자 권한으로 명령 프롬프트 또는 PowerShell을 열고 netstat 또는 Get-NetTCPConnection을 사용하세요:
     • netstat -ano | findstr :5173 (또는 :8080) (명령 프롬프트)
     • Get-Process -Id (Get-NetTCPConnection -LocalPort 5173).OwningProcess (PowerShell) 이러한 명령도 포트를 사용하는 프로세스의 PID를 보여줍니다.

2. 충돌하는 프로세스 종료: 프로세스 ID(PID)를 식별한 후, 해당 포트를 사용하는 애플리케이션을 중지할 수 있습니다. 프로세스를 종료하기 전에 무엇인지 확신이 없는 경우 주의하세요.

   • Linux/macOS: kill 명령을 사용하세요: kill <PID> (여기서 <PID>는 실제 프로세스 ID로 대체). kill로 프로세스가 종료되지 않는 경우 kill -9 <PID> (강제 종료)를 사용할 수 있지만 신중히 사용하세요.
   • Windows: 관리자 권한으로 명령 프롬프트 또는 PowerShell에서 taskkill 명령을 사용하세요: taskkill /PID <PID> /F (여기서 <PID>는 프로세스 ID로 대체). /F 플래그는 강제 종료를 의미합니다.

3. 대안으로 포트 변경 (고급):

   • 충돌하는 프로세스를 종료할 수 없는 경우(예: 필요한 시스템 서비스인 경우), 프론트엔드 및/또는 백엔드가 다른 포트를 사용하도록 Open WebUI를 구성할 수 있습니다. 일반적으로 구성 파일을 수정해야 합니다.
     • 프론트엔드 포트: 프론트엔드 문서나 구성 파일(종종 vite.config.js 또는 유사)에서 개발 서버 포트를 변경하는 방법을 확인하세요. 프론트엔드에서 포트를 위해 환경 변수를 사용하는 경우 .env 파일도 조정해야 할 수 있습니다.
     • 백엔드 포트: dev.sh 스크립트 또는 백엔드 구성 파일을 확인하여 백엔드 포트가 어떻게 설정되어 있는지 확인합니다. 백엔드 포트를 변경하려면 시작 명령 또는 구성 파일을 수정해야 할 수 있습니다. 백엔드 포트를 변경하면 프론트엔드의 .env 파일을 업데이트하여 새로운 백엔드 URL을 가리키도록 해야 할 가능성이 높습니다.

🔄 핫 리로드가 작동하지 않음

핫 리로드(또는 핫 모듈 교체 - HMR)는 코드 변경 시 브라우저를 자동으로 새로고침하는 멋진 개발 기능입니다. 이 기능이 작동하지 않으면 개발 워크플로가 크게 느려질 수 있습니다.

문제 해결 단계:

1. 개발 서버 실행 여부 확인: npm run dev(프론트엔드)와 sh dev.sh(백엔드)가 각각의 터미널에서 실행 중이며 오류가 발생하지 않았는지 확인하십시오. 터미널 출력에서 서버가 실행 중이고 "감시 모드" 또는 "개발 모드"라고 표시되어 있는 메시지를 찾아보세요. 오류가 있는 경우 먼저 해결하십시오.
2. 감시 모드/HMR 메시지 확인: 개발 서버가 시작될 때 터미널에서 핫 리로드 또는 감시 모드가 활성화되었다는 메시지를 출력해야 합니다. "HMR 활성화됨", "파일 변경 사항 감시 중" 또는 이와 유사한 문구를 찾아보세요. 이러한 메시지가 없으면 구성 문제일 수 있습니다.
3. 브라우저 캐시: 때로는 브라우저 캐시 때문에 핫 리로드가 정상적으로 작동하더라도 최신 변경 사항을 볼 수 없습니다. 브라우저에서 강제 새로고침을 시도하세요:
   • Windows/Linux: Ctrl+Shift+R
   • macOS: Cmd+Shift+R
   • 또는 브라우저 캐시를 지우거나 프런트엔드를 비공개/시크릿 브라우저 창에서 열어보세요.
4. 종속성 문제(프론트엔드): 오래된 또는 손상된 프론트엔드 종속성은 핫 리로드를 방해할 수 있습니다. 프론트엔드 종속성을 새로고침해보세요:

   • 프론트엔드 터미널에서 다음을 실행하세요:

     rm -rf node_modules && npm install

     이 명령은 종속성이 저장된 node_modules 디렉토리를 삭제한 다음 다시 새로 설치합니다. 손상된 또는 오래된 패키지로 인한 문제를 해결할 수 있습니다.

5. 백엔드 재시작 필요(백엔드 변경사항인 경우): 핫 리로드는 일반적으로 프론트엔드 코드 변경사항(UI, 스타일링, 컴포넌트)에 대해 가장 잘 작동합니다. 백엔드 코드 변경사항(특히 서버 로직, API 엔드포인트, 종속성 변경 등)이 있는 경우 백엔드 서버를 수동으로 재시작해야 할 수 있습니다(sh dev.sh를 중지한 다음 다시 실행). 백엔드 변경사항에 대한 핫 리로드는 많은 백엔드 개발 설정에서 자동으로 구성되지 않거나 신뢰도가 낮은 경우가 있습니다.
6. IDE/편집기 문제: 드물게 IDE 또는 코드 편집기와 관련된 문제가 파일 변경사항이 개발 서버에서 제대로 감지되지 않게 할 수 있습니다. IDE를 재시작하거나 파일이 제대로 저장되고 있는지 확인해보세요.
7. 구성 문제(고급): 위 단계 중 아무 것도 작동하지 않을 경우, 프론트엔드 또는 백엔드 개발 서버 설정에 더 복잡한 구성 문제가 있을 수 있습니다. 프로젝트의 문서, 구성 파일(e.g., vite.config.js 프론트엔드, 백엔드 서버 구성 파일)을 확인하거나 Open WebUI 커뮤니티 또는 유지보수팀에 도움을 요청하세요.

Open WebUI에 기여하기

Open WebUI에 대한 기여를 진심으로 환영합니다! 이 프로젝트를 더욱 개선하는 데 귀하의 도움이 매우 소중합니다. 원활하고 효과적인 기여 워크플로를 위한 간단한 가이드를 소개합니다:

1. 프로젝트 구조 이해: 프로젝트의 디렉토리 구조, 특히 frontend와 backend 폴더를 익히는 시간을 가지세요. 코드, 구성 파일 및 문서를 살펴보고 어떻게 조직되어 있는지 파악하세요.

2. 작은 기여로 시작하기: 프로젝트에 처음 참여한다면 다음과 같은 작은 기여로 시작하는 것을 고려해보세요:

   • 문서 개선: 오타 수정, 설명 명확화, 문서에 더 많은 세부사항 추가.
   • 버그 수정: 보고된 버그 또는 문제 처리.
   • 작은 UI 개선: 스타일링 개선, 작은 레이아웃 문제 수정. 이러한 작은 기여는 코드베이스와 기여 프로세스를 익히는 데 좋은 방법입니다.

3. 더 큰 변경 사항은 먼저 논의하기: 중요한 새로운 기능을 구현하거나 대규모 변경 사항을 계획 중인 경우, 아이디어를 프로젝트 유지보수팀 또는 커뮤니티와 먼저 논의하는 것이 좋습니다. 다음 방법으로 할 수 있습니다:

   • GitHub 리포지토리에서 이슈 열기를 통해 기능이나 변경 사항 제안.
   • Open WebUI 커뮤니티 채널(가능한 경우, 프로젝트의 README 또는 웹사이트에서 링크 확인)을 가입하여 아이디어 논의. 이렇게 하면 기여 내용이 프로젝트 목표와 일치하는지 확인할 수 있으며 병합되지 않을 가능성이 있는 기능에 낭비되는 노력을 방지할 수 있습니다.

4. 작업을 위한 별도 브랜치 생성: 절대로 dev 브랜치에 직접 커밋하지 마십시오. 항상 작업 중인 기능 또는 버그 수정을 위해 새 브랜치를 만드십시오. 이는 변경 사항을 분리하고 관리 및 풀 리퀘스트를 제출하는 과정을 단순화합니다.

   • dev 브랜치를 기반으로 한 새 브랜치(e.g., my-feature-branch)를 생성하려면:

     git checkout dev
     git pull origin dev # 로컬 dev 브랜치를 최신 상태로 유지
     git checkout -b my-feature-branch

5. 변경사항을 자주 커밋하고 명확한 커밋 메시지를 작성: 기능 개발이나 버그 수정 시 작은 논리적 커밋을 자주 작성하십시오. 명확하고 간결한 커밋 메시지를 작성하여 어떤 변경을 했는지와 그 이유를 설명하십시오. 좋은 커밋 메시지는 변경 내역을 쉽게 이해할 수 있게 하며 협업에 필수적입니다.

   • 좋은 커밋 메시지 예: Fix: 백엔드 설정 문서의 오타 수정
   • 좋은 커밋 메시지 예: Feat: 사용자 프로필 페이지 기본 정보 표시 기능 구현

6. dev 브랜치와 정기적으로 동기화 유지: 작업 중인 브랜치가 dev 브랜치의 최신 변경 사항과 주기적으로 동기화되도록 하여 나중에 병합 충돌을 최소화하십시오:

   git checkout dev
   git pull origin dev
   git checkout my-feature-branch
   git merge dev

   git merge 단계에서 발생한 병합 충돌을 해결하십시오.

7. 푸시 전에 테스트 실행 (가능한 경우): 이 가이드에서는 Open WebUI에 대한 특정 테스트 절차를 상세히 설명하지 않지만, 코드를 푸시하기 전에 사용할 수 있는 테스트를 실행하는 것이 좋은 습관입니다. 프로젝트 문서나 package.json(프론트엔드의 경우) 및 백엔드 파일에서 테스트 관련 명령어를 확인하십시오 (예: npm run test, pytest 등). 테스트를 실행하면 변경 사항이 회귀를 야기하지 않았거나 기존 기능을 깨뜨리지 않았는지 확인할 수 있습니다.

8. 풀 리퀘스트(PR) 제출: 작업을 완료하고 테스트(해당하는 경우)를 실행하고 변경 사항을 기여할 준비가 완료되면 GitHub에서 Open WebUI 저장소의 dev 브랜치에 풀 리퀘스트(PR)를 제출하십시오.

   • GitHub에서 Open WebUI 저장소로 이동하십시오.
   • 브랜치로 이동하십시오.
   • "Contribute" 또는 "Pull Request" 버튼 클릭 (일반적으로 녹색).
   • PR 양식 작성:
     • 제목: 변경 사항을 요약한 명확하고 설명적인 제목을 작성하십시오 (예: "Fix: 로그인 폼 유효성 검사 문제 해결").
     • 설명: 변경 사항, 해결하고자 하는 문제(있을 경우), 관련된 컨텍스트를 보다 자세히 작성하십시오. 관련된 이슈가 있는 경우 링크를 추가하십시오.
   • PR 제출.

   프로젝트 관리자가 풀 리퀘스트를 검토하고 피드백을 제공하며 변경 내용을 병합할 수 있습니다. 피드백에 응답을 잘 하고 요청이 있을 경우 수정할 준비를 하십시오.

이 포괄적인 가이드를 읽어 주셔서 감사합니다! Open WebUI에 기여하시려는 관심에 감사드리며 여러분의 기여를 환영합니다. Open WebUI 커뮤니티의 일원이 되는 데 도움 드리도록 하겠습니다! 🎉 행복한 코딩 되세요!