📌 5편에서 OpenClaw의 구조를 이해했다면, 이제 실제 설치 흐름으로 들어갈 차례입니다. 이번 편의 목표는 어렵게 멋진 서버를 만드는 것이 아니라, 시놀로지 NAS 안에서 OpenClaw가 안정적으로 켜지고 다시 살아날 수 있는 기본 자리를 만드는 것입니다.
여기서 중요한 전제가 하나 있습니다. 설치 글은 무조건 명령어를 많이 적는다고 좋은 글이 아닙니다. 초보자에게 더 중요한 것은 어느 폴더를 연결하고, 어떤 포트를 피하고, 어떤 값은 절대 공개하면 안 되는지 아는 것입니다. OpenClaw는 AI 모델과 도구와 채널을 연결하는 운영실이기 때문에, 설치 첫날부터 구조를 잘못 잡으면 나중에 토큰, 로그, 세션, 백업이 모두 꼬일 수 있습니다.
이번 6편은 시놀로지 DSM 7과 Container Manager를 기준으로 설명합니다. 4편에서 Docker와 포트·볼륨을 배웠고, 5편에서 Gateway·Agent·Session·Tool·Channel을 정리했으니, 이제 그 지식을 실제 설치 흐름에 적용해 보겠습니다.
1. OpenClaw용 NAS 폴더와 권한을 실제로 준비하기
2. Container Manager에서 OpenClaw 실행 공간 만들기
3. 포트·환경변수·볼륨 매핑의 의미를 설치 단계에 적용하기
4. 첫 실행 후 상태 확인과 실패 시 점검 순서를 익히기
1. 설치 전에 확인할 전제 조건
먼저 전제 조건부터 확인해야 합니다. DSM은 7 이상이면 좋고, Container Manager가 설치되어 있어야 합니다. RAM은 최소 4GB를 권장합니다. 2GB에서도 가벼운 테스트는 가능할 수 있지만, OpenClaw와 다른 컨테이너를 함께 운영하려면 여유가 부족합니다. 장기 운영을 생각하면 8GB 이상이 편합니다.
또 하나는 관리자 계정입니다. 설치 자체는 관리자 권한이 필요하지만, 평소 운영은 별도 계정으로 분리하는 것이 좋습니다. NAS의 최고 관리자 계정을 자동화 도구가 그대로 쓰게 만들면 사고 범위가 너무 커집니다. 처음에는 읽기 중심 권한으로 시작하고, 쓰기 권한은 필요한 폴더에만 제한적으로 부여하는 방식이 안전합니다.
마지막으로 외부 접속을 서두르지 마세요. OpenClaw를 설치했다고 바로 라우터 포트포워딩을 여는 것은 좋은 순서가 아닙니다. 먼저 내부망에서 접속이 되는지, 로그가 정상인지, 허용 사용자만 접근하는지 확인한 뒤 외부 접근 방식을 정해야 합니다.
2. OpenClaw용 폴더를 먼저 만든다
Container Manager에서 컨테이너를 만들기 전에 File Station에서 폴더를 먼저 만듭니다. 5편에서 설계한 구조를 실제 폴더로 옮기는 단계입니다. 예시는 다음과 같습니다.
| 폴더 | 용도 |
| /AI-자료실/docker/openclaw/config | 설정 파일과 환경 구성 |
| /AI-자료실/docker/openclaw/data | 세션, 상태, 작업 데이터 |
| /AI-자료실/docker/openclaw/logs | 실행 로그와 오류 확인 |
| /AI-자료실/docker/openclaw/workspace | AI가 읽고 작업할 파일 공간 |
| /AI-자료실/docker/openclaw/backups | 설정 백업과 복구 파일 |
폴더명은 대표님 환경에 맞게 바꿔도 됩니다. 다만 역할은 나누는 것이 좋습니다. config와 data를 섞으면 나중에 백업할 때 헷갈리고, logs를 따로 빼지 않으면 오류 원인을 찾기 어렵습니다. workspace는 OpenClaw가 실제로 파일을 다루는 공간이므로 처음에는 샘플 파일만 넣어 테스트하는 편이 안전합니다.
권한은 관리자 계정과 OpenClaw 운영 계정에 읽기·쓰기 권한을 주고, 외부 공유는 꺼두는 방식이 좋습니다. 특히 workspace를 NAS 전체로 잡지 마세요. 처음부터 모든 사진, 모든 문서, 모든 백업 폴더를 열어두면 편해 보이지만, 자동화 도구가 실수했을 때 영향 범위가 너무 넓습니다.
3. Container Manager에서 프로젝트를 만든다
시놀로지 DSM 7의 Container Manager에는 단일 컨테이너 실행 방식과 프로젝트 방식이 있습니다. OpenClaw처럼 설정, 포트, 볼륨, 환경변수를 함께 관리해야 하는 도구는 프로젝트 방식이 관리하기 쉽습니다. 프로젝트는 여러 설정을 하나의 묶음으로 보관하는 폴더라고 이해하면 됩니다.
Container Manager를 열고 프로젝트 메뉴로 이동합니다. 새 프로젝트를 만들 때 이름은 `openclaw`처럼 짧고 명확하게 잡습니다. 프로젝트 경로는 앞에서 만든 `/AI-자료실/docker/openclaw` 하위로 두면 관리가 편합니다. 이렇게 해두면 프로젝트 설정과 OpenClaw 관련 데이터가 같은 영역 안에 정리됩니다.
프로젝트 방식의 장점은 나중에 수정과 재시작이 쉽다는 것입니다. 포트를 바꾸거나 볼륨 경로를 바꾸거나 환경변수를 추가할 때, 컨테이너 하나하나를 손으로 다시 만드는 것보다 프로젝트 파일을 수정하는 방식이 안정적입니다. 6편에서는 초보자 기준으로 화면 흐름을 설명하지만, 운영이 익숙해지면 프로젝트 파일 중심으로 관리하는 습관이 좋습니다.
4. 설치 방식은 Node 기반 컨테이너로 이해한다
OpenClaw는 Node.js 기반 CLI와 Gateway를 중심으로 움직입니다. 시놀로지에 올릴 때는 크게 두 가지 방식이 있습니다. 하나는 공식 또는 전용 이미지가 있을 때 그 이미지를 쓰는 방식이고, 다른 하나는 Node.js 컨테이너 안에서 OpenClaw CLI를 설치해 실행하는 방식입니다. 초보자에게 중요한 것은 어느 방식을 쓰든 config, data, logs, workspace를 외부 볼륨으로 빼야 한다는 점입니다.
이 글에서는 개념을 이해하기 쉽게 Node 기반 컨테이너 방식으로 설명합니다. 실제 운영에서는 OpenClaw 공식 설치 문서와 현재 배포 방식을 확인해 이미지명이나 설치 명령을 최신 상태로 맞춰야 합니다. 블로그 글에 적힌 예시 명령은 구조를 이해하기 위한 틀이고, 실제 토큰이나 비밀번호는 절대 그대로 넣지 않습니다.
□ Container Manager 프로젝트 생성 가능
□ OpenClaw 폴더 5종 생성 완료
□ 사용할 포트 번호 결정
□ API 키와 봇 토큰은 placeholder로만 준비
□ 외부 접속은 내부 테스트 이후로 보류
□ config/data 폴더 백업 대상 포함
5. 포트는 9100번대처럼 별도 범위를 잡는다
OpenClaw Gateway는 외부 요청을 받는 중심 서버이므로 포트가 필요합니다. 여기서 DSM 기본 포트인 5000, 5001은 피해야 합니다. 이미 시놀로지가 쓰고 있는 포트와 충돌하면 컨테이너가 켜져도 접속이 안 되거나, 아예 시작하지 못할 수 있습니다.
추천 방식은 AI 자동화 도구용 포트 범위를 따로 정하는 것입니다. 예를 들어 OpenClaw Gateway는 9100번대, 테스트 컨테이너는 9300번대처럼 내부 규칙을 만들 수 있습니다. 실제 예시로는 NAS의 9101 포트를 컨테이너 내부 Gateway 포트에 연결하는 식입니다. 포트 번호 자체보다 중요한 것은 기록입니다. 어떤 포트가 어떤 도구인지 메모해 두어야 나중에 헷갈리지 않습니다.
외부 접속이 필요하더라도 처음부터 공유기 포트포워딩을 열지 않습니다. 내부망에서 `NAS주소:9101` 같은 형태로 접속해 정상 작동을 확인한 뒤, VPN이나 Tailscale, Cloudflare Tunnel, DSM Reverse Proxy 같은 방식을 비교하는 순서가 안전합니다.
6. 환경변수에는 비밀값을 직접 노출하지 않는다
OpenClaw를 실제로 쓰려면 모델 API 키, Gateway 토큰, 텔레그램 봇 토큰 같은 값이 필요할 수 있습니다. 이 값들은 집 열쇠와 같습니다. 블로그 예시, 스크린샷, 공개 저장소, 댓글 어디에도 실제 값을 넣으면 안 됩니다. 예시에는 반드시 `YOUR_OPENAI_API_KEY`, `YOUR_GATEWAY_TOKEN`, `YOUR_TELEGRAM_BOT_TOKEN`처럼 가짜 값을 사용합니다.
Container Manager의 환경변수 입력 화면에는 이름과 값을 넣을 수 있습니다. 여기서 중요한 값은 화면 캡처 전에 반드시 가리거나, 애초에 캡처하지 않는 편이 좋습니다. 운영에서는 가능하면 config 폴더 안의 비공개 설정 파일이나 시크릿 관리 방식을 사용하고, 해당 파일은 외부 공유 대상에서 제외합니다.
초기 설치 때 필요한 값은 최소화하는 것이 좋습니다. 모델 연결, Gateway 접속, 기본 인증 정도만 먼저 잡고, 텔레그램이나 다른 채널은 Gateway가 정상 작동한 뒤 추가하는 편이 문제 원인을 찾기 쉽습니다. 한 번에 모든 기능을 붙이면 실패했을 때 어디서 막혔는지 구분하기 어렵습니다.
7. 볼륨 매핑은 컨테이너의 생명보험이다
컨테이너는 언제든 지웠다가 다시 만들 수 있는 구조입니다. 이 장점은 동시에 위험이기도 합니다. 설정과 데이터가 컨테이너 내부에만 있으면 컨테이너를 재생성하는 순간 사라질 수 있습니다. 그래서 볼륨 매핑이 필요합니다.
| NAS 경로 | 컨테이너 내부 경로 예시 |
| /AI-자료실/docker/openclaw/config | /app/config |
| /AI-자료실/docker/openclaw/data | /app/data |
| /AI-자료실/docker/openclaw/logs | /app/logs |
| /AI-자료실/docker/openclaw/workspace | /workspace |
위 경로는 예시입니다. 실제 OpenClaw 배포 방식에 따라 내부 경로는 달라질 수 있습니다. 핵심은 컨테이너 안에서 쓰는 중요한 파일을 NAS 실제 폴더에 연결해 두는 것입니다. 이렇게 해두면 컨테이너를 다시 만들어도 설정과 데이터가 살아남습니다.
8. 첫 실행 후에는 상태와 로그를 먼저 본다
컨테이너를 실행했다면 바로 외부 채널을 붙이지 말고 상태와 로그를 먼저 봅니다. Container Manager의 컨테이너 탭에서 상태가 실행 중인지 확인하고, 로그 탭에서 오류가 반복되는지 확인합니다. 정상이라면 Gateway가 어느 포트에서 대기 중인지, 설정 파일을 제대로 읽었는지, 인증 관련 오류가 없는지 확인할 수 있습니다.
가장 흔한 오류는 세 가지입니다. 첫째, 포트 충돌입니다. 이미 사용 중인 포트를 잡으면 컨테이너가 시작되지 않거나 접속이 안 됩니다. 둘째, 볼륨 권한 문제입니다. 컨테이너는 켜졌지만 config나 data 폴더에 파일을 쓰지 못해 오류가 납니다. 셋째, 토큰 오입력입니다. 공백이 들어가거나 따옴표를 잘못 넣으면 인증이 실패합니다.
오류가 나면 무작정 컨테이너를 지웠다 만들기보다 로그를 먼저 복사해 원인을 나눠야 합니다. 포트 문제인지, 권한 문제인지, 토큰 문제인지에 따라 해결 방법이 완전히 다릅니다. 이 습관이 잡히면 NAS에서 어떤 컨테이너를 운영해도 훨씬 덜 불안합니다.
9. 자동 재시작과 백업을 반드시 켠다
OpenClaw는 개인 AI 비서의 중심이 될 수 있는 도구입니다. NAS가 재부팅되거나 컨테이너가 일시적으로 멈췄을 때 자동으로 다시 살아나야 합니다. Container Manager에서 재시작 정책을 켜고, NAS 재부팅 후 컨테이너가 자동으로 올라오는지 확인합니다.
백업도 함께 설정해야 합니다. Hyper Backup이나 Snapshot Replication을 사용한다면 config와 data는 반드시 포함합니다. logs는 최근 오류 확인용이므로 보관 기간을 짧게 잡아도 되지만, data는 세션과 작업 이력이 쌓이는 위치라 가치가 커집니다. workspace는 실제 작업 파일이 들어가므로 별도 백업 정책을 세우는 것이 좋습니다.
설치가 성공했다고 끝난 것이 아닙니다. 하루 뒤, NAS 재부팅 뒤, 패키지 업데이트 뒤에도 다시 살아나는지 확인해야 진짜 설치 완료입니다. 개인 비서형 도구는 한 번 켜지는 것보다 계속 켜져 있는 것이 더 중요합니다.
10. 텔레그램 연결은 Gateway 확인 후 진행한다
많은 분이 설치하자마자 텔레그램부터 붙이고 싶어합니다. 휴대폰으로 AI 비서에게 바로 말을 걸 수 있으니 가장 매력적인 부분입니다. 하지만 순서는 Gateway 확인이 먼저입니다. OpenClaw Gateway가 내부망에서 정상 응답하는지, 로그에 오류가 없는지, 인증 토큰이 정상인지 확인한 뒤 채널을 붙여야 합니다.
텔레그램 연결에서는 봇 토큰과 허용 사용자 ID가 핵심입니다. 봇 토큰은 외부에 노출되면 안 되고, 허용 사용자 ID를 제한하지 않으면 원치 않는 사람이 봇에 말을 걸 수 있습니다. 특히 그룹방에서 사용할 계획이 있다면 개인 파일 접근 권한과 그룹 대화 권한을 분리해야 합니다.
처음에는 대표님 개인 텔레그램 1개만 허용하고, 파일 읽기 범위도 샘플 workspace로 제한하는 것이 좋습니다. 정상 작동을 확인한 뒤 필요한 기능을 하나씩 늘리는 방식이 안전합니다.
11. 설치 후 첫 테스트 시나리오
설치가 끝나면 거창한 작업부터 시키지 말고 작은 테스트부터 시작합니다. 예를 들어 workspace 폴더에 `test.txt` 파일을 하나 넣고, “이 파일의 내용을 요약해줘”라고 요청합니다. 이 테스트가 성공하면 파일 접근, 세션 처리, 모델 응답, 채널 응답 흐름이 한 번에 확인됩니다.
두 번째 테스트는 로그 확인입니다. 일부러 존재하지 않는 파일명을 물어보고, OpenClaw가 어떤 오류를 내는지 확인합니다. 좋은 시스템은 성공할 때만 좋은 것이 아니라 실패했을 때도 원인을 추적할 수 있어야 합니다. 로그가 남고, 그 로그가 NAS 폴더에서 확인된다면 운영 준비가 된 것입니다.
세 번째 테스트는 재시작입니다. 컨테이너를 수동으로 재시작한 뒤 같은 요청을 다시 보내 봅니다. 세션이 어떻게 유지되는지, 설정이 사라지지 않는지, data 폴더가 제대로 연결되어 있는지 확인할 수 있습니다.
12. 실제 예시: 처음 하루는 이렇게 운영한다
설치 당일에는 큰 자동화보다 작은 루틴을 먼저 정하는 것이 좋습니다. 예를 들어 오전에는 컨테이너 상태를 확인하고, 오후에는 로그 폴더에 오류가 쌓이는지 보고, 저녁에는 테스트 파일 요약을 한 번 더 시도합니다. 이 정도만 해도 포트, 권한, 볼륨, 토큰 문제가 있는지 대부분 드러납니다. 처음부터 블로그 발행, 메일 확인, 파일 정리, 텔레그램 자동 응답을 모두 붙이면 실패 원인을 찾기 어렵습니다.
첫날 기준으로 가장 좋은 테스트 파일은 민감하지 않은 짧은 문서입니다. 예를 들어 `workspace/test-note.txt`에 “이 NAS는 OpenClaw 테스트용입니다” 같은 문장을 넣고 요약을 요청합니다. 그 다음에는 일부러 없는 파일명을 물어봅니다. 정상 요청과 실패 요청을 모두 확인해야 OpenClaw가 어느 경로를 읽고, 실패했을 때 어떤 로그를 남기는지 알 수 있습니다.
하루 정도 안정적으로 움직이면 그때부터 실제 업무 폴더를 하나씩 연결합니다. 문서 폴더, 블로그 초안 폴더, 사진 정리 폴더처럼 범위를 나눠 연결하면 문제가 생겨도 영향 범위가 제한됩니다. OpenClaw 운영의 핵심은 한 번에 크게 여는 것이 아니라, 작게 열고 확인한 뒤 넓히는 것입니다.
13. 마무리
이번 6편에서는 OpenClaw를 시놀로지 Container Manager 위에 올리는 실제 흐름을 정리했습니다. 핵심은 명령어보다 구조입니다. 폴더를 나누고, 볼륨을 연결하고, 포트를 피하고, 환경변수와 토큰을 안전하게 관리하고, 로그와 백업을 확인하는 것이 설치의 본질입니다.
OpenClaw는 한 번 켜놓고 끝나는 장난감이 아니라, NAS 안에서 계속 살아 있어야 하는 개인 AI 운영실입니다. 그래서 설치 첫날부터 자동 재시작, 백업, 권한 제한을 함께 잡아야 합니다. 이 세 가지가 없으면 처음에는 편해 보여도 나중에 장애가 났을 때 복구가 어렵습니다.
OpenClaw 설치는 컨테이너를 켜는 일이 아니라, NAS 안에 안전하게 오래 살아 있는 AI 운영실을 만드는 일입니다.
다음 7편에서는 OpenClaw가 NAS 폴더를 실제로 읽고 정리할 수 있도록 workspace를 연결하고, 파일 읽기 테스트와 안전한 권한 범위 설정을 다루겠습니다.
이전 글 보기
시놀로지 NAS로 개인 AI 비서 만들기 1편 — 내 자료를 기억하는 AI의 시작
시놀로지 NAS로 개인 AI 비서 만들기 2편 — AI가 읽을 자료 창고 만들기
시놀로지 NAS로 개인 AI 비서 만들기 3편 — AI가 잘 읽는 파일 정리법
시놀로지 NAS로 개인 AI 비서 만들기 4편 — OpenClaw를 올리기 전, Docker 준비하기
시놀로지 NAS로 개인 AI 비서 만들기 5편 — OpenClaw는 무엇이고 어떻게 움직이는가
이미지 출처: 첫 이미지는 Pixabay, 나머지 본문 이미지는 Unsplash의 무료 사용 가능 이미지를 블로그 표시용으로 크기와 품질을 변환해 사용했습니다.
14. 자주 묻는 질문
Q. OpenClaw 설치는 꼭 Container Manager 프로젝트로 해야 하나요?
반드시 그런 것은 아니지만 프로젝트 방식이 관리하기 쉽습니다. 포트, 볼륨, 환경변수, 재시작 정책을 한 묶음으로 관리할 수 있어 장기 운영에 유리합니다.
Q. 설치 후 바로 외부 접속을 열어도 되나요?
권장하지 않습니다. 내부망에서 Gateway와 로그, 인증 상태를 먼저 확인하고, 그 다음 VPN이나 터널, 역방향 프록시 같은 방식을 검토하는 것이 안전합니다.
Q. API 키는 어디에 보관해야 하나요?
본문이나 스크린샷에 노출하면 안 됩니다. 환경변수나 비공개 설정 파일로 관리하고, 해당 파일은 외부 공유 대상에서 제외해야 합니다.
Q. 컨테이너를 지웠다가 다시 만들면 설정이 사라지나요?
볼륨 매핑을 하지 않았다면 사라질 수 있습니다. config와 data를 NAS 실제 폴더에 연결해두면 컨테이너를 다시 만들어도 설정과 데이터가 남습니다.
Q. 다음 7편에서는 무엇을 하나요?
OpenClaw가 NAS workspace 폴더를 읽고 테스트 파일을 요약하는 흐름을 다룹니다. 파일 접근 권한을 어디까지 열어야 안전한지도 함께 정리합니다.
'나만의AI > synology' 카테고리의 다른 글
| 시놀로지 NAS로 개인 AI 비서 만들기 8편 — 텔레그램으로 OpenClaw에게 말 걸기 (1) | 2026.05.09 |
|---|---|
| 시놀로지 NAS로 개인 AI 비서 만들기 7편 — OpenClaw와 NAS 폴더 연결하기 (1) | 2026.05.09 |
| 시놀로지 NAS로 개인 AI 비서 만들기 5편 — OpenClaw는 무엇이고 어떻게 움직이는가 (1) | 2026.05.09 |
| 시놀로지 NAS로 개인 AI 비서 만들기 4편 — OpenClaw를 올리기 전, Docker 준비하기 (2) | 2026.05.09 |
| 시놀로지 NAS로 개인 AI 비서 만들기 3편 — AI가 잘 읽는 파일 정리법 (1) | 2026.05.09 |