# \#docker **URL:** https://discuss.pytorch.kr/tag/docker/1180.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [Rakazo: 모델과 실행 환경을 직접 고르고 자체 호스팅하는 오픈소스 AI 팀메이트 플랫폼](https://discuss.pytorch.kr/t/rakazo-ai/11768)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 1, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/rakazo-ai/11768 "2026-09-01T09:30:27Z")
Rakazo 소개 업무를 대신 처리하는 AI 비서 서비스는 대체로 같은 구조를 공유합니다. 사업자의 서버에서 사업자가 고른 모델이 돌고, 사용자의 메일과 캘린더, 문서에 접근할 권한을 그 서버에 넘겨줍니다. 편리하지만 대가가 분명합니다. 어떤 모델을 쓸지 고를 수 없고, 대화와 기억이 어디에 저장되는지 통제할 수 없으며, 요금제와 서비스 정책이 바뀌면 그대로 따라가야 합니다. 사내 자료를 다루는 자리에서는 이 지점이 도입을 막는 첫 번째 이유가 되기도 합니다. Rakazo는 그 구조를 통째로 자기 인프라 위로 옮기는 오픈소스 플랫폼입니다. 각자의 대화와 기억, 정기 실행 루틴과 이력을 가진 봇을 만들어 두고, 그 봇이 쓸 모델 자격증명과 봇이 올라갈 실행 환경을 사용자가 직접 고릅니다. 저장소는 스스로를 "Open source Grok Bot alternative" 로 소개하면서 "AI teammates you actually own" 을 내세우고 있습니다. 웹과 Electron 데스크톱 앱, Expo 모바일 앱 세 가지 형태로 제공되며, 셋 모두 같은 Rakazo API를 쓰는 클라이언트입니다. 만든 사람은 Elie Steinbock이며 프로젝트는 아직 베타 단계임을 밝히고 있습니다. 기술 스택은 TypeScript 모노레포 위에 React 19와 Vite, Tailwind CSS, 서버 쪽으로는 Hono와 oRPC, 저장소로는 PostgreSQL과 Prisma, 인증에는 Better Auth, 백그라운드 작업에는 Graphile Worker를 쓰고 있습니다. Rakazo의 한국어 지원 한국 사용자 입장에서 먼저 확인할 항목이 하나 있습니다. Rakazo의 웹 UI는 영어와 독일어, 한국어를 지원하며, Electron 데스크톱 앱은 웹 UI를 그대로 감싸고 있어 같은 언어 설정을 따릅니다. 언어는 Settings → Language에서 바꿉니다. 소개용 홈페이지도 영어와 독일어, 한국어 세 가지로 제공되어 /ko/ 경로로 접근할 수 있으나, … --- ## [HarnessRouter: Codex와 Claude Code를 내 컨테이너 하나에서 실행하는 자체 호스팅 게이트웨이](https://discuss.pytorch.kr/t/harnessrouter-codex-claude-code/11716)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 26, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/harnessrouter-codex-claude-code/11716 "2026-08-26T06:30:20Z")
HarnessRouter 소개 코딩 에이전트를 여러 개 쓰는 팀은 실행 환경이 도구마다 갈리는 문제를 만납니다. Codex 와 Claude Code, Hermes 는 각자 자기 방식으로 설치되고 자기 방식으로 세션을 관리하며, 대화 기록도 각자의 자리에 남습니다. 여기에 자격 증명 관리가 겹칩니다. 도구별로 키를 넣어 두면 어느 키가 어디에 있는지 흐려지고, 관리형 서비스로 묶으면 그 대신 키와 코드가 외부로 나갑니다. 에이전트가 실제로 무엇을 실행했는지 한 곳에서 보고 싶다는 요구와, 아무것도 밖으로 내보내고 싶지 않다는 요구가 여기서 부딪힙니다. 이번에 소개할 HarnessRouter Community Edition 은 그 두 요구를 컨테이너 한 개로 맞추려는 프로젝트입니다. 프로젝트가 말하는 하네스(Harness)는 모델을 감싼 실행 계층이고, Codex 와 Claude Code, Hermes 가 각각 그 하네스에 해당합니다. HarnessRouter 는 이들을 저장된 설정 객체로 다루어, 기반 런타임(Runtime)과 모델, 지시문, 한도를 묶어 하나의 하네스로 만들고, 그 설정을 한 번 실행하는 단위를 작업(Task)이라고 부릅니다. 작업은 bash 와 git 이 있는 실제 POSIX 작업 공간에서 돌아가는 진짜 대화이고, 진행 중에 스트리밍으로 되돌아옵니다. 이 저장소는 관리형 클라우드 서비스와 같은 코드베이스입니다. 저자들은 콘솔이 축소판 재구현이 아니라 "the same pages, the same components, the same API client" 라고 밝히고 있으며, 계정과 결제, 마켓플레이스처럼 한 대의 서버로는 제공할 수 없는 화면만 감춰 둔 것이라고 설명합니다. 자체 호스팅 쪽은 Apache-2.0 으로 공개된 무료 판이고, 관리형 쪽은 요금이 있는 서비스입니다. 로컬에서 다듬은 하네스는 콘솔의 Harnesses → Push to cloud 로 관리형 계정에 복사할 수 있는데, 이 이동은 의도적으로 한 방향입니다. … --- ## [SnapOtter: 이미지, 영상, 오디오, PDF를 로컬에서 처리하는 셀프호스팅 파일 도구 모음](https://discuss.pytorch.kr/t/snapotter-pdf/11181)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 10, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/snapotter-pdf/11181 "2026-07-10T06:30:22Z")
SnapOtter 소개 이미지 리사이즈, PDF 병합, 영상 포맷 변환 같은 일상적인 파일 작업을 할 때마다 Smallpdf나 TinyPNG 같은 웹 서비스에 파일을 올리는 경우가 많습니다. 문제는 이 과정에서 민감한 문서나 사내 자료가 외부 서버로 나간다는 점입니다. SnapOtter는 이런 파일 처리 작업 전부를 자신의 서버 안에서 끝내도록 만든 셀프호스팅(Self-hosted) 파일 도구 모음으로, 스스로를 "Smallpdf, iLovePDF, TinyPNG, TinyWow, CloudConvert의 오픈소스 대안" 이라고 소개합니다. 가장 큰 특징은 다루는 범위입니다. Docker 컨테이너 하나에 이미지(105종), 영상(57종), 오디오(27종), PDF(29종), 파일(23종)까지 다섯 가지 모달리티에 걸친 200개 이상의 도구가 들어 있습니다. 개발팀은 "Stirling-PDF는 PDF에서 멈추고, ConvertX는 변환에서 멈춘다" 는 문장으로 기존 셀프호스팅 도구와의 차이를 설명합니다. 브라우저에서 동작하는 레이어 기반 이미지 편집기, 여러 도구를 하나의 워크플로우로 묶는 파이프라인(기본 20단계, 파일 100개까지 일괄 처리), 모든 도구를 호출할 수 있는 REST API도 함께 제공합니다. 2026년 7월 공개된 2.0 버전에서는 도구가 200개 이상으로 늘었고, 백그라운드 작업 처리와 온디맨드 로컬 AI, docker run 한 줄 설치가 더해졌습니다. UI는 한국어를 포함한 21개 언어를 지원하며, Google이나 GitHub 계정 등으로 로그인하는 OIDC/SSO 연동과 AMD64/ARM64 멀티 아키텍처(Apple Silicon, Raspberry Pi 포함)도 지원합니다. SnapOtter의 주요 기능 다섯 가지 모달리티별 도구 구성은 다음과 같습니다. 이미지 (105종): 리사이즈, 크롭, 압축, 변환, 워터마크, 색상 조정, 스크린샷 꾸미기, 벡터화, GIF 도구, 중복 찾기, 증명사진 등. 카메라 RAW 23… --- ## [Tesseract-Torch: 컨테이너화한 과학 계산 코드를 PyTorch 자동미분에 연결하는 라이브러리](https://discuss.pytorch.kr/t/tesseract-torch-pytorch/11177)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 10, 2026, 2:30오전 UTC](https://discuss.pytorch.kr/t/tesseract-torch-pytorch/11177 "2026-07-10T02:30:01Z")
Tesseract-Torch 소개 실제 과학 연구 파이프라인은 하나의 언어나 프레임워크로 끝나지 않는 경우가 많습니다. 메시 생성기는 C++로, 솔버는 Julia로, 후처리는 Python으로 작성돼 있는 식입니다. 이런 이기종 도구를 하나로 묶어 함께 동작시키는 것도 번거롭지만, 그 파이프라인 전체에 걸쳐 그래디언트를 흘려보내 최적화까지 하는 일은 훨씬 더 어렵습니다. 이 문제를 풀기 위해 Pasteur Labs는 Tesseract Core를 만들었습니다. 어떤 언어로 작성된 과학 계산 코드든 Docker 컨테이너로 감싸 CLI·REST API·Python SDK라는 동일한 인터페이스로 실행할 수 있게 하고, 컴포넌트마다 야코비안(Jacobian)·벡터-야코비안 곱(VJP)·야코비안-벡터 곱(JVP) 같은 미분 값을 노출해 이기종 파이프라인 전체를 미분 가능하게 이어붙일 수 있도록 설계된 프레임워크입니다. Tesseract-Torch는 이 Tesseract Core를 PyTorch 생태계에 연결하는 가벼운 확장입니다. apply\_tesseract(tesseract, inputs)라는 단 하나의 함수로 어떤 Tesseract든 PyTorch의 자동 미분 그래프 안에 끼워 넣을 수 있으며, 역전파(reverse-mode)와 정전파(forward-mode) 자동 미분을 모두 지원합니다. 즉 Julia나 C++, Fortran으로 짠 시뮬레이터를 Tesseract로 패키징해두면, PyTorch 학습 루프 안에서 다른 nn.Module과 똑같이 .backward()를 호출해 그래디언트를 얻을 수 있습니다. Tesseract-Torch 자체는 API 표면이 매우 작습니다. 텐서를 넘파이(NumPy) 배열로 변환해 Tesseract에 전달하고, Tesseract의 스키마를 읽어 어떤 입출력이 미분 대상인지 판단한 뒤, 결과를 다시 grad\_fn이 연결된 torch.Tensor로 되돌리는 역할만 합니다. Pasteur Labs는 같은 방식으로 JAX용 확장인 Tes… --- ## [Stash: AI 에이전트를 위한 8단계 인지 통합 파이프라인 기반의 오픈소스 영구 메모리 레이어](https://discuss.pytorch.kr/t/stash-ai-8/9924)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 29, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/stash-ai-8/9924 "2026-04-29T09:30:59Z")
Stash 소개 현재 대부분의 LLM 기반 에이전트는 각 대화가 끝나면 모든 맥락을 잃어버립니다. 사용자가 이미 설명했던 프로젝트 구조, 이전 대화에서 합의했던 결정 사항, 반복적으로 발생하는 실패 패턴 — 이 모든 것이 세션이 종료되는 순간 사라집니다. 이 문제는 에이전트를 단순한 일회성 도우미로 제한하고, 진정한 지속적 협업자로 발전하지 못하게 막는 핵심 장벽입니다. 짧은 컨텍스트 창에 과거 대화를 억지로 집어넣는 방식은 토큰 비용을 급격히 높이고, 정작 중요한 현재 작업 정보가 들어갈 공간을 빼앗습니다. Stash는 이 문제를 해결하기 위해 설계된 오픈소스 자기 호스팅(self-hosted) 영구 메모리 레이어입니다. 핵심 아이디어는 원시 관찰(raw observation)을 단계적으로 정제해 구조화된 지식으로 변환하는 것입니다. 에피소드(Episodes)는 사실(Facts)이 되고, 사실은 관계(Relationships)가 되고, 관계는 패턴(Patterns)이 되며, 패턴은 최종적으로 지혜(Wisdom)로 응축됩니다. 이 4단계 지식 압축 원칙이 Stash의 8단계 통합 파이프라인의 철학적 토대입니다. MCP(Model Context Protocol) 표준을 기반으로 구현되어 Claude Desktop, Cursor, Windsurf, Cline, Continue, OpenAI Agents, Ollama, OpenRouter 등 MCP 호환 클라이언트라면 어디서든 즉시 연동할 수 있습니다. Stash는 PostgreSQL과 pgvector 확장을 저장 백엔드로 사용하며, Docker Compose 한 줄로 전체 인프라를 구동할 수 있습니다. 백그라운드에서 지속적으로 실행되는 통합 파이프라인이 새로운 에피소드를 분석해 데이터베이스를 자동으로 업데이트합니다. Apache 2.0 라이선스로 공개되어 있어 개인 및 상업적 목적 모두에서 자유롭게 사용할 수 있습니다. Stash의 8단계 인지 통합 파이프라인 Stash의 핵심은 8단계로 구성된 … --- ## [CrabTrap: AI 에이전트의 외부 API 요청을 통제하는 LLM-as-a-Judge HTTP 프록시](https://discuss.pytorch.kr/t/crabtrap-ai-api-llm-as-a-judge-http/9880)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 27, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/crabtrap-ai-api-llm-as-a-judge-http/9880 "2026-04-27T06:30:18Z")
CrabTrap 소개 OpenClaw와 같은 자율형 AI 에이전트가 많이 도입되며, 실제 서비스 환경에서 외부 API를 호출하는 시대가 열렸습니다. 즉, 사용자를 대신하여 Slack 메시지를 보내고, Gmail을 읽고, GitHub 이슈를 생성하는 에이전트는 이미 현업에서 활발히 사용되고 있습니다. 그러나 이런 에이전트들은 보안 취약점을 함께 안고 있습니다. 프롬프트 인젝션(Prompt Injection) 공격으로 에이전트가 허가되지 않은 데이터를 외부로 전송하거나, 잘못된 도구 호출로 의도치 않은 부작용이 발생할 수 있습니다. 기존 방화벽은 인바운드(Inbound) 트래픽에 특화되어 있어 에이전트가 발생시키는 아웃바운드(Outbound) 요청을 세밀하게 제어하기 어렵습니다. CrabTrap은 핀테크 스타트업인 Brex가 오픈소스로 공개한 HTTP/HTTPS 프록시로, AI 에이전트와 외부 API 사이에 위치하여 모든 아웃바운드 요청을 보안 정책에 따라 평가합니다. 에이전트가 Slack, Gmail, GitHub 등 어떤 외부 서비스를 호출하든, CrabTrap이 그 요청을 가로채어 결정론적 규칙과 LLM 기반 정책 판사(LLM-as-a-Judge)에 의해 검사합니다. 허용된 요청은 그대로 전달되고, 거부된 요청은 그 이유와 함께 403 오류로 차단됩니다. 모든 요청과 결정은 PostgreSQL에 기록되어 완전한 감사 추적(Audit Trail)을 제공합니다. CrabTrap의 핵심 차별점은 2단계 평가 방식(Two-tier Evaluation) 에 있습니다. 먼저 URL 패턴 기반의 결정론적 정적 규칙을 적용하여 즉각적인 허용/거부 결정을 내립니다. 정적 규칙이 없는 경우에만 LLM 판사를 호출하므로, 불필요한 LLM 호출을 최소화하면서도 자연어로 표현된 유연한 정책을 적용할 수 있습니다. Go 언어로 작성되어 높은 성능을 제공하며, Docker Compose로 손쉽게 배포 가능합니다. CrabTrap의 동작 원리 CrabTrap의 요청 … --- ## [ScreenEnv: 데스크탑 에이전트를 위한 Docker 기반 풀스택 자동화 환경 (feat. Hugging Face)](https://discuss.pytorch.kr/t/screenenv-docker-feat-hugging-face/7285)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 20, 2025, 3:00오전 UTC](https://discuss.pytorch.kr/t/screenenv-docker-feat-hugging-face/7285 "2025-07-20T03:00:00Z")
ScreenEnv 소개 최근 인공지능 기반의 데스크탑 자동화와 GUI 에이전트 개발에 대한 관심이 높아지고 있습니다. 전통적으로 GUI 테스트나 데스크탑 상의 작업 자동화를 위해선 무거운 가상 머신(VM)을 설정하고, 다양한 운영체제 환경에 대응하는 복잡한 프레임워크를 구성해야 했습니다. 하지만 Hugging Face에서 새롭게 공개한 ScreenEnv는 이 과정을 대폭 간소화하며, 컨테이너 기반으로 데스크탑 환경을 손쉽게 가상화할 수 있도록 도와주는 Python 라이브러리입니다. ScreenEnv는 Docker 기반의 Ubuntu 데스크탑 환경을 손쉽게 생성할 수 있게 해주는 도구로, GUI를 포함한 풀 데스크탑 세션을 코드로 제어할 수 있도록 설계되어 있습니다. 단순한 마우스 클릭과 키보드 입력뿐만 아니라, 윈도우 창 관리, 파일 조작, 터미널 명령 실행, 그리고 화면 녹화까지 모두 지원합니다. 이 덕분에 복잡한 GUI 기반 응용 프로그램 테스트나 데스크탑 자동화를 위한 에이전트를 매우 빠르게 구축하고 배포할 수 있게 되었습니다. 기존의 데스크탑 자동화 도구들과 비교해 보면, ScreenEnv는 매우 큰 차별점을 가집니다. 대표적인 GUI 자동화 프레임워크인 Selenium이나 AutoIt, PyAutoGUI는 로컬 환경에 직접 접근하거나 제약이 있는 플랫폼에서만 동작할 수 있었습니다. 또한 VM 기반 솔루션은 무겁고 느리며 환경 구축에 시간이 많이 들었습니다. 반면, ScreenEnv는 Docker를 기반으로 하여 몇 초 만에 완전한 데스크탑 환경을 띄울 수 있고, AI 에이전트가 MCP(Model Context Protocol)를 통해 직접 해당 환경과 상호작용할 수 있도록 설계되어 있어 확장성과 통합성이 뛰어납니다. 특히, headless 모드나 직접적인 API 호출, 또는 MCP 서버 방식 등 다양한 통합 옵션을 제공하여, 개발자의 백엔드 구조에 따라 유연하게 적용할 수 있다는 점이 가장 큰 강점입니다. Scre… --- ## [Docker container 내부에서 gpu process가 보이지 않습니다.](https://discuss.pytorch.kr/t/docker-container-gpu-process/4710)
**Author:** [@jh2ee](https://discuss.pytorch.kr/u/jh2ee)\ **댓글:** 4\ **마지막 업데이트:** [7월 30, 2024, 12:00오전 UTC](https://discuss.pytorch.kr/t/docker-container-gpu-process/4710 "2024-07-30T00:00:40Z")
교내 서버를 배정받아 docker로 환경을 구축해 개발중입니다. 문제는 gpu를 사용할 경우 docker container 내부에서 nvidia-smi로 확인할 경우 진행중인 process가 잡히지 않습니다. 그러나 container 외부인 서버 자체에서 확인할 경우 container 내부에서 gpu 사용중임을 확인할 수 있습니다. 왜 container 내부에서는 process 확인이 불가한지 궁금합니다. --- ## [AIKit: LLM 파인튜닝, 빌드 및 배포를 위한 프레임워크 (feat. Docker)](https://discuss.pytorch.kr/t/aikit-llm-feat-docker/4591)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 7, 2024, 7:25오전 UTC](https://discuss.pytorch.kr/t/aikit-llm-feat-docker/4591 "2024-06-07T07:25:39Z")
AIKit: LLM 파인튜닝, 빌드 및 배포를 위한 프레임워크 (feat. Docker) 소개 AIKit은 대규모 언어 모델(LLM, Large Language Model)을 쉽게 호스팅, 배포, 구축 및 미세 조정할 수 있는 도구입니다. AI Kit은 미세조정(fine-tuning)과 추론(inference)의 두가지 용도로 사용할 수 있는 기능들을 제공합니다. 미세조정(fine-tuning) 측면: 파인튜닝을 위한 확장 가능한 인터페이스를 제공합니다. 특히, Unsloth를 지원하여 더 빠르고 메모리 효율적인 파인튜닝을 지원합니다. 추론(inference) 측면: LocalAI를 사용하여 다양한 추론 기능을 지원하며, OpenAI API와 호환되는 REST API 응답을 제공하여 Kubectl AI나 Chatbot-UI 등과 같은 OpenAI API 호환 클라이언트를 사용할 수 있습니다. AIKit은 기존의 모델 관리 도구와 달리 Docker 기반으로 동작하여 별도의 GPU나 인터넷 연결 없이도 로컬 환경에서 사용할 수 있습니다. 또한, OpenAI API와 호환되는 REST API를 제공하여 다양한 클라이언트와 쉽게 통합할 수 있다는 점에서 차별화됩니다. 이러한 특징은 Kubeflow, TensorFlow Serving 등과 같은 다른 AI 모델 관리 도구와 비교했을 때, 더욱 간편하고 접근성이 높다는 장점이 있습니다. 주요 기능 :spouting\_whale: GPU, 인터넷 액세스 또는 추가 도구가 필요없는 Docker 사용 :pinching\_hand: 최소 이미지 크기, 커스텀 distroless 기반 이미지로 보안 취약점 감소. :musical\_note: 미세 조정 지원 :rocket: 추론 및 미세 조정을 위한 선언적 구성 \[설정\] 가능(https://sozercan.github.io/aikit/docs/specs-inference) :sparkles: OpenAI API 호환 … --- ## [pytorch.kr, pytorch hub 모두 빌드하는 docker 제작](https://discuss.pytorch.kr/t/pytorch-kr-pytorch-hub-docker/2308)
**Author:** [@cpprhtn](https://discuss.pytorch.kr/u/cpprhtn)\ **댓글:** 0\ **마지막 업데이트:** [8월 22, 2023, 5:51오전 UTC](https://discuss.pytorch.kr/t/pytorch-kr-pytorch-hub-docker/2308 "2023-08-22T05:51:40Z")
몇달전에 공유드렸던 내용에서 아주 가끔씩 시간날때 고쳐나가고 있는 도커파일 제작기 입니다. 지난 내용에서 마운트가 안되는 문제가 있었고, 이번에 시간이 나서 마운트까지 해결한 docker-compose를 제작하였습니다. pytorch.kr 및 hub를 모두 빌드하는 파일입니다. cpprhtn/docker-compose 깃허브를 참고하여 빌드가 완료된다면 pytorch.kr github과 동일한 형태가 되며, 제가 테스트 한 m1의 환경에서는 로컬 파일을 수정하면 4~5초정도의 rebuild를 거쳐 실시간으로 업데이트되는 것을 확인해볼 수 있습니다. 또한 hub의 파일들은 ./\_hub 의 경로와 연동되어 해당 페이지의 hub 문서들을 실시간으로 확인하며 수정할 수 있습니다. 이를 통해 복잡한 환경세팅 없이 "파이토치 한국 사용자 모임"의 페이지들을 로컬에서 테스트해보고 다양한 개선사항이나 수정사항들을 쉽게 확인해볼 수 있습니다. 이를 바탕으로 다양한 기여를 해주시면 감사하겠습니다 :slight\_smile: git clone https://github.com/cpprhtn/pytorch-hub-docker.git cd pytorch-hub-docker docker-compose up -d --build docker-compose가 되지 않는다면 아래 몇가지 주의사항을 확인해주세요 docker compose의 버전 확인 (너무 낮다면 업그레이드 필요) docker desktop이 백그라운드에서 실행되어있는지 확인 아직 컨테이너를 켤때마다 파일을 전부 밀고 다시 다운받는 등의, Dockerfile 하나안에 많은 task들을 밀어둔 부분에대해서 분리하여 사용자편의성을 개선시켜야 하는 문제점과, 예전에 테스트용으로 따놓은 브랜치를 클론하는 등등의 문제들은 또 시간이 날때마다 수정하여 공유해보겠습니다.