Claude Code /config key=value: 팀 설정을 한 줄로 점검하는 법 | DAKER 커뮤니티
Claude Code /config key=value: 팀 설정을 한 줄로 점검하는 법
Claude Code /config key=value는 설정 화면 전체를 열지 않고 특정 옵션 하나를 바로 바꾸는 CLI 설정 방식입니다. 2026년 7월 9일 기준 공식 settings 문서는 v2.1.181부터 이 형식을 지원한다고 설명합니다. 팀에서 권한, 자동 압축, 질문 timeout처럼 자주 확인하는 값을 다룬다면 먼저 /status로 현재 source를 보고 한 옵션씩 바꾸세요.
Claude Code 설정이란, 사용자·프로젝트·로컬·관리자 범위에서 도구 실행과 인터페이스 동작을 정하는 구성값입니다.
DAKER 클로드 코드 /config key=value 흐름을 팀 설정 점검 루틴으로 정리한 NotebookLM 대표 카드입니다.
문제 상황: 팀 설정을 바꿨는데 왜 적용 여부가 헷갈릴까?
Claude Code를 팀에서 쓰다 보면 “설정 파일을 고쳤는데 지금 세션에 적용됐나?”라는 질문이 자주 생깁니다. 프로젝트 settings, 개인 local settings, managed settings가 함께 있으면 같은 옵션이라도 우선순위가 달라질 수 있습니다. 그래서 설정 변경은 긴 프롬프트가 아니라 현재 source 확인, 한 옵션 변경, 적용 상태 확인의 작은 루틴으로 다뤄야 합니다.
DAKER의 설정과 권한을 팀 규칙으로 고정하기 글이 settings 계층을 넓게 다뤘다면, 이번 글은 실제 운영 중 한 값을 빠르게 확인하는 루틴에 집중합니다.
핵심 개념: /config key=value는 무엇을 줄여줄까?
/config는 Claude Code의 설정 UI를 여는 명령입니다. 공식 문서 기준 v2.1.181부터는 /config verbose=true처럼 key=value를 붙여 한 옵션만 바꿀 수 있습니다. 이 방식은 회의 중 화면 설정을 전부 뒤지지 않고, 현재 의심되는 값 하나만 바꾸고 곧바로 /status나 /doctor로 확인할 때 유용합니다.
다만 모든 값을 아무 범위에서나 바꿀 수 있는 것은 아닙니다. user, project, local, managed settings는 우선순위가 다르고, permission rule처럼 merge되는 항목도 있습니다. 회사 managed settings가 잠근 정책은 개인 설정으로 덮을 수 없습니다.
단계별 사용법: 한 옵션을 안전하게 바꾸려면?
먼저 /status를 열어 현재 settings source와 workspace trust 상태를 확인합니다.
바꿀 옵션이 user 설정인지, project 설정인지, managed 정책인지 구분합니다.
한 번에 하나만 /config key=value 형식으로 바꿉니다.
설정 파일을 직접 고쳤다면 저장 뒤 ConfigChange가 감지되는지 확인합니다.
적용이 안 된 것처럼 보이면 /doctor로 schema 오류를 확인합니다.
model이나 outputStyle처럼 새 세션 또는 별도 명령이 필요한 값은 즉시 적용으로 단정하지 않습니다.
settings 계층, 변경 적용, /status 확인을 순서대로 보여주는 NotebookLM 워크플로 카드입니다.
짧은 예시: 질문 자동 진행 timeout을 바꿀 때는 어떻게 볼까?
자동화 세션에서 질문이 오래 멈추는 문제가 있다면 askUserQuestionTimeout 같은 옵션을 확인할 수 있습니다. 예를 들어 사람의 선택이 꼭 필요한 배포 작업은 never가 안전하고, 단순 상태 확인 자동화는 제한된 timeout이 유용할 수 있습니다. 핵심은 “편하니까 켠다”가 아니라 어떤 작업에서 사람이 반드시 멈춰야 하는지 먼저 나누는 것입니다.
비교표: 어떤 확인 명령을 같이 쓰면 좋을까?
상황 | 먼저 볼 것 | 이유 |
|---|---|---|
설정 source가 헷갈림 | /status | 어떤 범위의 설정이 적용 중인지 봅니다 |
권한 allow/deny가 의심됨 | /permissions | 최종 permission rule을 확인합니다 |
설정 파일 오류가 의심됨 | /doctor | schema 오류와 설치 상태를 봅니다 |
memory와 rules가 안 먹는 듯함 | /memory 또는 /context | 로딩된 지시문을 확인합니다 |
팀 적용 체크리스트: key=value를 운영 루틴으로 만들려면?
회의 중 임시 변경과 저장소에 남길 정책 변경을 구분합니다.
한 번에 여러 옵션을 바꾸지 말고 변경 전후 상태를 남깁니다.
project settings에 비밀값이나 개인 경로를 넣지 않습니다.
managed settings가 있는 조직에서는 개인 override 기대를 줄입니다.
자동화가 멈췄을 때 오류, 승인 대기, 정책 차단을 분리해서 기록합니다.
공식 출처: 2026년 7월 9일 기준 무엇을 확인했나?
이 글은 Claude Code 공식 settings 문서와 debug configuration 안내를 기준으로 작성했습니다. 공개 본문에는 DAKER 운영 정책에 따라 외부 URL을 직접 노출하지 않았고, /config key=value 지원 버전, settings scope, 적용 우선순위, /doctor 확인 흐름은 공식 문서의 설명 범위 안에서만 정리했습니다.
FAQ: 자주 묻는 질문
/config key=value는 설정 파일을 직접 고치는 것보다 안전한가요?
작은 값을 바꿀 때는 실수 범위를 줄이는 데 도움이 됩니다. 다만 팀 정책으로 남겨야 하는 값은 settings 파일과 코드 리뷰로 관리해야 합니다.
프로젝트 settings가 사용자 settings보다 항상 우선인가요?
대부분의 일반 설정은 project가 user보다 우선합니다. 하지만 managed settings가 있으면 가장 강하고, permission rule처럼 병합되는 항목도 있습니다.
설정을 바꾸면 running session에 바로 적용되나요?
많은 설정은 실행 중 reload됩니다. 다만 일부 값은 새 세션이나 별도 명령이 필요하므로 /status와 /doctor로 확인하는 편이 안전합니다.
팀에서 오늘 바로 할 일은 무엇인가요?
자주 바꾸는 설정 세 가지를 고르고, 각 설정의 source, 허용 범위, 확인 명령을 팀 문서에 한 줄씩 남기세요.
다음 Claude Code 세션을 열기 전에 /status와 /config 한 줄 변경 루틴을 팀 온보딩 체크리스트에 넣어 보세요.