놀이터 }{ Hanstree-AI

NAS에 AI 개발 작업실을 만들어 운영하고 있습니다. 이름은 **Hanstree-AI**이고, 저는 ‘놀이터’라고 부릅니다. 브라우저에서 프로젝트를 열고 AI에게 작업을 맡기며, 대화와 진행 상황, 파일과 결과물을 한 공간에서 다루는 웹 앱입니다. 이번에는 NAS 구성부터 계정과 관리자 역할, 에이전트와 확장 도구, 실제 운영 방법까지 소개합니다. 갤러리의 표지와 구성도는 AI로 만든 설명용 이미지이며, 작업 화면은 실제 운영 중인 놀이터에서 촬영했습니다. ## 1. NAS에 무엇을 올렸나 놀이터의 웹 서버와 프로젝트 작업 환경을 NAS에서 운영합니다. 브라우저는 작업을 요청하고 결과를 확인하는 창구입니다. 프로젝트 파일과 대화 기록은 서버에서 관리하고, AI 작업도 서버 쪽 실행 환경에서 진행합니다. 웹 화면은 HTML·CSS·JavaScript, 서버는 Node.js 기반입니다. Codex의 app-server와 연결해 대화 응답뿐 아니라 명령 실행, 파일 변경, 작업 상태를 화면에 전달하도록 구성했습니다. 중요한 구분도 있습니다. **NAS에서 작업실을 운영한다는 뜻이지, 모든 AI 모델을 NAS 내부에서 구동한다는 뜻은 아닙니다.** 외부 AI 서비스가 처리하는 요청은 해당 서비스로 전달됩니다. NAS에 데이터를 보관하는 것과 외부 AI에 전송되는 범위는 별도로 생각해야 합니다. 또한 설치형 앱처럼 홈 화면에 추가할 수 있지만, 서버 연결이 필요한 웹 앱입니다. 오프라인으로 모든 기능을 사용할 수 있는 구조는 아닙니다. 외부 AI 요청과 프로젝트 백업은 NAS 내부 보관과 별개의 흐름입니다. ## 2. 프로젝트 하나를 열고, 대화로 일을 시작합니다 기본 단위는 프로젝트입니다. 프로젝트 안에서 대화를 나누고 파일을 다루며, 필요한 자료를 첨부하거나 기존 대화·파일의 발췌를 읽기 전용 참조로 추가할 수 있습니다. 이번 소개를 위해 기존 작업과 분리된 **‘사이드독 소개 예제’**를 만들었습니다. 이 프로젝트에서 짧은 README를 생성하도록 요청하고 실제 작업 기록과 결과 파일을 캡처했습니다. 예제에는 개인정보나 기존 프로젝트 자료를 넣지 않았습니다. 사용 흐름은 단순합니다. 1. 프로젝트를 만들거나 기존 프로젝트를 엽니다. 2. 원하는 결과와 작업 범위를 적고 필요한 자료를 첨부합니다. 3. 작업 상태와 실행 기록을 확인하고, 필요하면 추가 지시나 중지를 요청합니다. 4. 결과물과 실제 파일을 확인합니다. 5. 후속 수정이나 프로젝트 백업을 진행합니다. 대화별 모델과 추론 강도를 고를 수 있고, 대화 맥락 사용량도 확인할 수 있습니다. 작업 현황에서는 실행 중인 요청과 대기 중인 요청을 구분합니다. 브라우저를 닫아도 이미 시작한 작업은 서버에서 계속될 수 있으며, 다시 접속해 기록을 확인하는 구조입니다. ## 3. 답변 다음에 남는 파일까지 관리합니다 파일 화면에서는 프로젝트 폴더를 탐색하고, 텍스트를 확인·수정하거나 파일을 올리고 내려받을 수 있습니다. 결과물 표시와 실제 파일 관리를 함께 두어 대화의 ‘완료’와 산출물을 연결하려고 했습니다. 프로젝트·대화·파일 검색과 프로젝트별 기억도 있습니다. 기억은 프로젝트 맥락을 이어가는 참고 자료이며 새로운 권한을 부여하는 지시는 아닙니다. GitHub는 계정 연결과 프로젝트별 저장소 연결을 통해 백업·가져오기·동기화에 활용하도록 구성했습니다. 연결이 저장되어 있다는 사실, 현재 원격 권한을 확인했다는 사실, 실제 반영이 성공했다는 사실을 구분해 보여주는 방향입니다. 이 글의 예제에서는 원격 저장소를 변경하지 않았습니다. ## 4. 마스터와 관리자는 역할이 다릅니다 계정은 **마스터 → 관리자 → 소계정 → 부계정** 순서입니다. | 역할 | 관리 범위 | |---|---| | 마스터 | 전체 계정·프로젝트 관리, 마스터 전용 ‘놀이터 관리’ | | 관리자 | 마스터와 다른 관리자를 제외한 하위 계정 관리 | | 소계정 | 자기 계정과 부계정 관리 | | 부계정 | 자기 계정 사용 | 프로젝트는 만든 계정이 소유하며, 초대와 부여된 권한에 따라 협업합니다. 현재 권한 구조에서는 상위 계정이 하위 계정 프로젝트에 접근할 수 있습니다. 따라서 다른 사용자에게 제공할 때는 이 관리 범위를 먼저 알려야 합니다. 사용자별로 운영체제 실행 환경이 완전히 격리되는 서비스라고 설명할 수는 없습니다. 마스터에게는 별도의 **‘놀이터 관리’**가 있습니다. 일반 프로젝트 작업과 구분된 대화에서 놀이터 앱의 기능·소스·실행 설정 유지보수를 요청하는 공간입니다. NAS의 DSM 본체나 다른 사용자 데이터 전체를 마음대로 수정하는 기능을 뜻하지는 않습니다. ## 5. 에이전트, 스킬, 플러그인은 각각 다른 역할을 맡습니다 개발자에게 특히 공유하고 싶은 부분입니다. **에이전트**는 일을 맡기는 실행 주체입니다. 놀이터는 Codex를 중심으로, 필요한 경우 NAS의 실행 도우미를 통해 Claude와 Gemini에 구분된 업무를 맡길 수 있도록 구성했습니다. 서로 다른 일을 맡기고, 실제 호출 결과를 모아 완료 여부를 판단하는 방식입니다. 여러 모델의 답변이 있다는 이유만으로 검증이 끝났다고 보지는 않습니다. 화면의 팀 활동은 해당 대화의 기록을 보여줍니다. 이번 README 예제는 Codex만 사용했으므로 Claude와 Gemini는 ‘호출 기록 없음’으로 표시됩니다. 이 캡처를 세 에이전트의 협업 성공 사례로 소개하지 않습니다. **스킬**은 반복 업무의 절차와 판단 기준을 재사용하는 단위입니다. 작업 범위, 진행 순서, 확인할 자료, 완료 조건을 문서와 실행 도우미로 묶어 매번 같은 내용을 처음부터 설명하지 않도록 합니다. 개발·디자인·문서 작성·조사 같은 업무에 활용할 수 있지만, 스킬 파일이 있다는 것만으로 필요한 실행 도구까지 생기는 것은 아닙니다. **플러그인·MCP·외부 연결 도구**는 검색이나 외부 서비스 접근을 확장하는 수단입니다. 실제 사용에는 해당 실행 환경에서의 도구 제공과 인증·권한이 필요합니다. Mac에서 연결된 플러그인이 NAS에서도 자동으로 작동한다고 볼 수 없으므로, 두 환경을 구분해 관리해야 합니다. 2026년 10월 5일 NAS의 실제 설정에서 확인한 이름은 다음과 같습니다. 이 표는 설정 확인 결과이며 모든 도구의 실행 성공을 의미하지 않습니다. | 도구 | 활용 목적 | 이번 확인 범위 | |---|---|---| | Exa MCP | 공개 자료 검색과 원문 읽기 | NAS 설정에 `exa` 연결 항목 존재 | | Ponytail 플러그인 | 구현과 검토에서 불필요한 복잡성을 줄이는 기준 활용 | NAS 설정에 플러그인 항목 존재 | | Visualize 플러그인 | 설명과 비교를 시각적으로 표현 | NAS 설정에 플러그인 항목 존재 | | 공유 스킬 | 개발·디자인·문서·플랫폼 작업의 절차 재사용 | NAS 공유 폴더의 스킬 파일 존재 | | 팀원 실행 도우미 | Claude·Gemini에 구분된 작업 요청 | NAS의 실행 도우미 파일 존재 | 공유 스킬에는 문서·PDF·스프레드시트·프레젠테이션, 디자인, 플랫폼 간 작업 동기화 같은 항목이 있습니다. Google Drive·Notion 등 외부 연결이 필요한 항목도 있지만, 스킬 설치와 해당 서비스 연결 완료는 서로 다른 상태입니다. 개발자가 비슷한 환경을 구성한다면 도구 목록을 다음 네 가지로 나눠 기록하는 것을 권하고 싶습니다. - 어떤 업무에 쓰는가. - 어디에서 실행되는가. - 필요한 연결·권한이 준비되어 있는가. - 실제 호출과 결과 확인까지 끝났는가. Apple 앱 빌드처럼 Xcode가 필요한 작업은 Mac에서 해야 합니다. NAS는 모든 개발 환경을 대체하는 장비가 아니라, 가능한 작업을 지속적으로 실행하고 기록을 관리하는 기반으로 사용하고 있습니다. ## 6. 만드는 것만큼 운영도 중요했습니다 놀이터에는 작업 대기열, 사용량 표시, 실패·중단 기록, 프로젝트 백업과 연결 상태 같은 운영 장치가 있습니다. 동시에 무제한으로 일을 시키기보다 실행 가능한 작업 수와 기다리는 요청을 구분하는 구조입니다. 사용량 조회가 실패하거나 정보를 제공받지 못한 경우에는 확인되지 않은 수치를 만들어 채우지 않는 것이 중요합니다. 커뮤니티에는 자유게시판과 고객센터가 있습니다. 회원끼리 정보를 공유하고, 요청과 유지보수 기록을 다루는 공간입니다. 고객센터 요청 처리에는 수정본 준비와 검토·배포를 이어가는 구조도 포함되어 있습니다. 사용자의 게시글 내용과 운영자의 실제 지시는 구분해서 다뤄야 합니다. 운영하면서 가장 신경 쓰는 것은 **요청한 일, 실제 변경한 파일, 확인한 결과, 아직 확인하지 못한 부분을 구분하는 것**입니다. AI가 ‘끝났다’고 답하는 것과 빌드·설치·백업·운영 반영이 끝나는 것은 각각 다른 단계이기 때문입니다. ## 7. 현재 소개 범위와 다음 과제 이번 글은 제가 운영하는 놀이터의 구성과 사용 흐름을 공유하는 개발기입니다. 누구나 즉시 가입해 사용할 수 있는 공개 서비스 출시를 안내하는 글은 아닙니다. 화면은 2026년 10월 5일 실제 NAS 놀이터에서 촬영했습니다. 예제 프로젝트와 파일 생성은 이번 소개용으로 직접 실행했습니다. 나머지 기능 설명은 프로젝트 문서와 소스를 바탕으로 작성했으며, 모든 에이전트·플러그인·외부 연동의 동작을 이번에 일괄 확인한 것은 아닙니다. 비슷한 AI 작업 환경을 만들고 계신 개발자분들의 의견이 궁금합니다. **여러 에이전트의 역할 분담, 결과물 관리, 외부 도구 연결 중 어떤 부분이 가장 필요하신가요?** 어떤 구성과 운영 경험부터 더 자세히 공유하면 좋을지도 듣고 싶습니다.