융융이'Blog

한눈에 보는 결과AI와 여러 작업을 이어 가다 보면 매번 같은 설명을 반복하게 된다.작업을 시작할 때 어떤 문서를 읽어야 하는가?비밀정보는 어디에 저장하면 안 되는가?설정을 바꾸기 전에 무엇을 확인해야 하는가?작업이 끝나면 어떤 기록을 남겨야 하는가?이 문제를 해결하기 위해 프로젝트 루트에 AGENTS.md를 두고, Codex가 작업 전에 따라야 할 공통 규칙을 기록했다. 환경 정보, 학습 목표와 작업 이력은 각각 별도 Markdown 파일로 분리하고 AGENTS.md가 작업 시작 시 해당 파일들을 읽도록 연결했다.여기서 가장 중요한 점은 다음과 같다.Codex가 기본 규칙 파일로 자동 탐색하는 것은 AGENTS.md다. PROJECT_CONTEXT.md 같은 다른 문서는 이름만 만들어 두면 자동으로 읽..

한눈에 보는 결과Synology NAS의 지정된 테스트 폴더를 Codex 같은 AI 클라이언트가 MCP(Model Context Protocol)로 조회할 수 있도록 읽기 전용 서버를 구축했다.이번 실습에서 중요하게 본 것은 단순히 사진을 읽는 기능이 아니었다. 관리자 계정을 사용하지 않고, 허용된 폴더만 읽게 하고, 원본을 수정할 수 없게 만든 뒤 실제 실패 테스트로 이를 검증하는 것이 목표였다.최종적으로 다음 항목을 확인했다.사진 목록 조회사진 형식·크기·해상도 조회최대 크기가 제한된 JPEG 미리보기 생성허용된 폴더 밖으로 나가는 경로 차단사진 폴더에 대한 파일 생성 차단인증 토큰이 없는 MCP 요청 차단새 Codex 프로세스에서 실제 MCP 도구 호출 성공서비스 구성데이터 흐름사용자가 Codex ..

결론컨테이너가 정상 실행됐지만 사진 공유 폴더를 읽지 못한 근본 원인은 컨테이너의 임의 UID/GID와 Synology DSM에서 읽기 권한을 받은 서비스 계정의 UID/GID가 일치하지 않았기 때문이었다.DSM 마스터 계정이나 root로 실행하지 않고, 다음 방식으로 해결했다.관리자 그룹에 속하지 않은 DSM 전용 서비스 계정을 만든다.테스트 사진 공유 폴더에만 읽기 권한을 준다.전용 계정의 실제 UID/GID를 확인한다.그 값을 Compose의 컨테이너 실행 사용자에 매핑한다.읽기 성공과 쓰기 실패를 각각 재검증한다.핵심은 “Permission denied를 없애는 것”이 아니라 “필요한 사용자만 읽고 누구도 이 경로를 쓰지 못하는 상태”를 만드는 것이었다.현상과 영향Photo MCP 컨테이너는 시작..

한 문장 정의UID와 GID는 Linux가 사용자와 그룹을 구분하는 숫자 신분증이고, ACL은 특정 사용자와 그룹이 파일이나 디렉터리에 어떤 작업을 할 수 있는지 표현하는 권한 목록이다.이 개념이 중요한 이유Docker 컨테이너가 정상적으로 실행되고 NAS 폴더가 컨테이너에 마운트됐는데도 Permission denied가 발생할 수 있다.이때 흔히 다음과 같이 생각하기 쉽다.“컨테이너 안에 mcp라는 사용자가 있고 비루트로 실행했으니 권한 설정이 끝난 것 아닌가?”하지만 Linux 파일시스템은 대부분 사용자 이름보다 숫자 UID와 GID를 기준으로 접근 권한을 판단한다. 컨테이너 안의 사용자 이름과 Synology DSM의 사용자 이름이 같아 보여도 숫자 ID가 다르면 같은 신분으로 취급되지 않는다.이 ..