앤트로픽(Anthropic)이 클로드 페이블(Claude Fable) 5.1을 위한 프롬프트 작성 실습 가이드라인을 공개했습니다. 노력을 재측정하는 방법부터 대화 기록 처리 방식까지, 모델 이전 시 검토해야 할 설계상의 결정 사항이 15가지 항목으로 정리되어 있지만, 이 가이드라인은 API 사용자들을 대상으로 쓰여졌으며, thinking.display나 max_tokens와 같은 설정 이름 그대로 사용될 경우 클로드 코드(Claude Code) 사용자들은 시작할 수 있는 지점을 알 수 없습니다.
이 글에서는 늘 그렇듯 가이드에서 에이전트 운영에 직접적으로 연결되는 7가지 논점을 제시하고, 각 논점을 Claude Code의 어떤 작동으로 읽어들이면 좋을지까지 상세하게 정리합니다.
다시 읽어보면 최종 목적지는 생각보다 적고, 노력과 컴팩트, 그리고 CLAUDE.md, 거의 이 3곳에 집중됩니다.
클로드 코드(Claude Code) API에 대한 15가지 항목은 실질적으로 3가지만 변경하는 것입니다.
클로드 페이블 5.1에서 달라진 점은 모델의 지능만이 아닙니다. 노력 수준이 같더라도 생성되는 사고량은 달라지고, 높은 노력으로 긴 문서를 작성하게 되면 사고와 출력이 동일한 한계를 충돌합니다. API 사용자는 이 외에도 대화 기록의 중간 부분을 건드리면 400 에러가 반환되는 제약까지 직접 관리해야 합니다.
Claude Code 사용자는 이 15가지 항목 중 가장 까다로운 부분인 즉, 이력 추가, 프롬프트 캐싱, 사고 블록 재송출 규칙을 하르ネス가 전부 대신해 주고 있다는 점이 행운입니다.
얼마나 깊이 생각하게 할 것인지(노력/effort), “역사를 언제 어떻게 압축할 것인지(컴팩트)”, “매 세션에서 무엇을 전달할 것인지(CLAUDE.md)”의 세 가지로 제한됩니다.
노력 수준은 모델을 넘어 동일한 思考量を 의미하지 않으므로, 5.1로의 전환 후에는 /effort로 단계를 나누어 자신의 작업으로 측정하고 재평가해야 합니다. 침묵으로 진행을 계속하는 에이전트에게 대처하는 순서는 thinking 표시 설정 확인 → CLAUDE.md에 있는 억제 지시 삭제 → 진행 지시 추가 순입니다. 대화 기록 추가 규칙은 하르ネス가 지켜주므로, 사용자에게 남는 판단은 /compact의 시점과 유지 지시뿐입니다. 자율 실행이 중간에 멈추는 것은 능력의 문제라기보다는 “사용자는 실시간으로 보지 않는다”는 전제를 CLAUDE.md에서 전달하지 않았기 때문입니다. 범위 밖의 변경을 멈추는 지시와 “부탁한 일은 모두 끝내라”를 같은 블록에 쓰면 억제와 완수 양쪽에 넘어갈 수 있습니다. Claude Code의 기본 설정은 xhigh이므로, 긴 결과물을 요청하고 생각하고 출력하는 과정이 중복될 수 있습니다. 글쓰기 작업은 /effort를 high로 낮춘 후 진행하는 것이 좋습니다.
어디에서 행동이 바뀌는지, 무엇을 조작해야 하는지
노력 수준은 이전 모델의 설정을 물려받지 않고, 노력으로 재측정합니다.
모델을 새로 구성한 만큼 설정은 그대로 두어도 괜찮다고 생각할 만한데요, 중요한 것은 Fable 5에서 high가 최적이었다고 해서 5.1의 high가 같은 양을 고려해야 않는다는 것입니다. 5.1의 능력 향상은 모든 레벨에서 나타나지만, 그 증가폭은 높은 설정일수록 크고, medium에서는 비용을 낮추면서 Fable 5의 high와 거의 동등한 결과를 얻을 수 있습니다. low 경우에는 작업당 비용으로 Claude Opus나 Claude Sonnet과 경쟁하면서 점수는 오히려 더 높은 경우가 많다고 합니다. 여기서부터 알 수 있는 것은 5.1로의 전환은 “더 똑똑해졌다”는 것이 아니라 “같은 품질을 더 저렴한 설정으로 구매할 수 있게 되었다”라는 변화로 봐야 한다는 것입니다.
정액 요금제 사용 시에도 이 이야기는 무관하지 않습니다. 노력을 한 단계 낮추면 소비하는 사용량이 줄어들고, 이는 동일한 상한 내에서 처리 가능한 작업량이 그대로 늘어나는 것입니다. 다만 조건부로, 자신의 업무에서 품질이 유지된다는 것을 확인한 경우에 한합니다. 확인하지 않은 채로 낮추는 것은 단순히 품질을 잃는 것과 같습니다.
방법은 간단합니다. 우선 평소 설정대로 몇 날씨 사용해서 느낌을 익히고, 다음으로 노력 수준을 중간으로 낮춰서 같은 종류의 작업을 돌려보고, 차이가 나는지 확인해 보세요. 판단 기준은 품질과 소비량 2축이며, 품질이 떨어지지 않는다면 저렴한 쪽을 선택하는 것이 우선 순위입니다.
묵묵히 실행을 지속하는 에이전트: 진행이 나오지 않는다면 설정이 문제일 수 있습니다.
긴 툴 실행 중 아무것도 표시되지 않는 현상이 있습니다. 5.1의 기본 동작은 Fable 5에 비해 사용자 친화적인 업데이트를 작성하는 양이 적고, 노력이 많이 들수록 툴체인이 길수록 침묵이 두드러집니다. 최종 메시지는 작업 전체가 아닌 마지막 단계만을 다루는 것처럼 보일 수 있습니다.
먼저 프롬프트를 의심해 보게 되겠지만, 아래 순서로 확인해 주시기 바랍니다. ① 표시 설정 → ② 기존 억제 지시 → ③ 진행 추가 지시 순입니다. 모델이 작업 중에 쓴 짧은 메모, 예를 들어 직전에 발견한 것이나 다음에 할 일을 생각의 일부로 반환하면서, 표시 설정에 따라 화면에 나타나지 않는 경우도 있을 수 있습니다.
클루드 코드(Claude Code)를 사용하면 settings.json에서 showThinkingSummaries를 활성화하면 접혀 있던 생각 요약이 보이게 됩니다. 내용을 작성했는데도 전달되지 않는다면, 표시 설정을 수정해야 합니다.
다음으로 확인해야 할 것은 CLAUDE.md의 설정입니다. 이전 모델은 작업 중에 업데이트가 너무 많이 올라오는 경향이 있었기 때문에 “실행 중에는 깨우치거나 핵심 내용을 모두 최종 보고서에 요약하라”와 같은 억제 행을 작성한 환경이 많았습니다. 5.1에서는 이 설정이 오히려 지나치게 조용한 원인이 됩니다. 무엇을 추가하기 전에 먼저 삭제하는 것이 우선입니다. 순서는 이쪽이 먼저입니다.
다시 한번, 설정에 대한 의문을 제기하는 순서는 ① 표시 설정 → ② 기존 억제 지시 → ③ 진행 추가 지시입니다. 이전 두 항목은 사용자의 환경 상태에 따라 진행하며, 이를 수정하지 않고 지시를 추가하면 모순된 명령이 누적될 수 있습니다.
진행 추가 지시사항은 가이드가 제시하는 지시를 한국어로 번역하면 다음과 같습니다. 참고하시기 바랍니다.
툴을 하나씩만 불러올 때는 CLAUDE.md에 한 문장만 추가합니다.
긴 작업을 지켜보면, 병렬로 호출될 수 있는 툴이 한 턴에 1개씩만 실행되는 상황에 처하게 됩니다. 5.1은 일반적으로 기대와 같이 병렬로 툴을 호출합니다. “A와 B를 요약해줘”와 같이 읽어야 할 대상이 요청 문장에 나열되어 있다면, A와 B를 동시에 읽어갑니다. 1개씩 되는 것은 “이 버그를 고쳐줘”와 같이 요청이 단순히 작업을 전달하고, 다음에 어떤 파일을 읽을지를 모델이 작업하면서 스스로 유도하는 경우입니다. 그리고 Claude Code의 일상적인 사용법은 대상을 나열하지 않고 작업을만 전달하는 형태가 대부분이므로, 바로 이 조건에 부합합니다. 1개씩으로도 답변의 품질은 떨어지지 않습니다. 떨어지지 않는 대신, 추가되는 턴마다 토큰과 실시간 비용이 발생합니다.
대처 방식은 “모두 호출해달라”는 한 문장으로 전달하는 것이지만, API 이용자를 위한 가이드에서는 이 문장을 어디에 두는지에 대한 설명만으로 한 절이 할당되어 있습니다. API는 매 턴마다 다시 보내야 하며, 위치를 잘못 설정하면 오히려 비용이 증가하는 것입니다.
Claude Code 사용자는 해당 위치 문제를 완전히 간과할 수 있습니다. 기록 관리는 하르ネス의 업무이므로, CLAUDE.md에 한 문장만 추가하는 것으로 충분합니다.
대화 기록 관리까지 맡겨주세요 — 생각할 때만 정해주시면 됩니다.
가이드에서 가장 기술적으로 무거운 논점은 “대화 기록은 편집하지 않고 추가 지시로 유지하라”는 규칙입니다. 쉽게 말해, 과거의 대화를 뒤에서 수정하거나 삭제하지 않고, 끝에 추가하는 것 외에는 아무것도 하지 말라는 의미입니다. 5.1에서 이 규칙을 위반하여 기록의 중간 부분을 수정하면, 입력 비용을 줄이는 “프롬프트 캐싱”이 작동하지 않게 되며, 조건에 따라 요청 자체가 오류로 중단될 수 있습니다. API에서 하르네스를 직접 만들어 사용하는 사람들은 이 위반이 자신의 코드에 섞이지 않았는지 자력으로 점검해야 합니다.
클루드 코드 사용자분들은 이러한 걱정은 하지 않으셔도 됩니다. 이전 대화 기록을 추가만 하기 위한 역할은 하르ネス 측에서 담당하고 있으며, 이미 보호되고 있습니다. 그럼에도 불구하고 이 논점을 건너뛰지 않고 작성하는 것은 “아무것도 하지 않아도 된다”는 것을 알고 있기 때문에 그 자체로 가치가 있기 때문입니다. 이 규칙을 모른다면, 예를 들어 “오래된 대화 내용을 수동으로 요약해서 짧게 만들 수 있지 않을까”와 같은 아이디어를 떠올릴 수 있습니다. 알게 되면, 그것은 5.1에서는 손해를 보는 방향이라는 것을 처음부터 알 수 있습니다.
사용자의 손에 남는 판단은 기록을 언제 요약하고 얼마나 짧게 할지 뿐입니다. Claude Code에서는 이것이 /compact이며, 수동으로도 입력 가능하고, 컨텍스트의 상한이 가까워지면 자동으로 실행됩니다. 여기서 가이드의 지적이 하나도 꼬리에 꼬리를 물었습니다.
역사를 요약하면 짧게는 않겠지만, 세부 사항은 반드시 손실됩니다. 반면에 5.1에서는 긴 역사를 유지하는 비용이 이전보다 감소했습니다. 요약으로 손실되는 것은 같지만, 절약할 수 있는 양은 줄어든 것입니다. 따라서 맥락의 절약을 노려 빠르게 /compact를 사용하는 습관이 있는 사람은 한계까지 끌어당기는 방향으로 재검토할 가치가 있습니다.
자율 실행을 중단하는 것은 능력의 문제라기보다는 허가를 구하는 행동이다.
장시간의 작업을 던진 후에 돌아왔는데, 중간에 멈춰서 답변을 기다리고 있었다. 이는 모델의 지속력이 부족해서가 아닐 것이다.
5.1 목표가 명확하다면 방법을 구체적으로 지시하지 않아도 매우 긴 작업을 완료할 수 있습니다. 하지만 복잡한 작업에서는 “끝까지 멈추지 마라”는 압박적인 지시가 필요합니다.
멈추는 방법에는 정해진 패턴이 있습니다. 하나는 다음에 할 일을 실행하는 대신 “다음에는 ~하겠습니다”라고 설명만 하고 끝내는 패턴입니다. 다른 하나는 첫 번째 요청에 포함되어 있는 단계인데 “이것을 적용해 볼까요?”라고 허락을 구하며 멈추는 패턴으로, 밤에 빠르게 진행하기 위한 작업에서는 “계속”이라고 치는 것만으로도 인간이 필요합니다.
해결책은 묶음 형태의 지시문(이하 블록이라고 합니다)을 2개, CLAUDE.md에 추가해 두는 것입니다. 첫 번째는 ‘자율 실행 제어’, 두 번째는 ‘범위 및 테스트 제어’이며, 전체 내용은 나중에 ‘활용법’에 게시됩니다.
이 부분에서는 첫 번째【자율 실행 제어】를 다룹니다. 이 블록이 전달하는 것은 이미 요청된 작업에 대해 굳이 질문하지 않고, “다음에는 이것을 할 것이다”라고 스스로 말한 것은 말뿐만 아니라 당장 실행하는 것입니다. 효과의 대부분을 담당하고 있는 것은 앞 문장, “당신은 자율적으로 작동하고 있으며, 사용자는 실시간으로 보거나 진행 중인 질문에 대답할 수 없다”는 부분입니다. 이 문장은 그대로 유지해야 합니다. 모델이 “물으면 바로 답이 돌아올 것이다”라고 생각하기 때문에 질문을 멈추는 것이고, 이 문장은 그 착오를 바로잡기 위해 있습니다.
같은 블록에는 예외 사항도 포함되어 있지만, 사용자가 문제를 상담하거나 질문하는 것 외에는 변경을 요청하지 않는 상황입니다. 따라서 이 블록이 효과를 발휘하는 경우는 밤 시간 실행이나 띄워놓고 장시간 작업을 하는 등 실제로 사람이 확인하지 않는 방식으로 사용될 때입니다. 반대로, 꼼꼼하게 확인하면서 사용하고 싶어 하는 경우에는 부작용이 발생합니다. 요청이 모호할 경우 질문을 해 줄 확률까지 낮아지기 때문입니다. 확인하고 싶은 동작이 있다면 문장 시작 뒤에 구체적으로 나열해 주세요.
기다려선 안 되는 친절을 멈추는 법: 범위의 언어화
간단한 요청으로 기능 구현을 부탁받으면, 요청한 것을 내놓는 것 외에 약간 더 많은 것을 추가해 오기도 하고, 요청하지 않은 동작까지 확장하기도 합니다. 의도적인 추가이지만, 추가된 부분은 모두 리뷰를 통해 확인해야 하는 번거로움 때문에 실질적으로는 큰 손해로 이어집니다.
5.1은 무엇을 할 것인지보다 무엇을 하지 않을지를 명시적으로 제시받을 때 더 잘 따르는 경향이 있습니다. 이것이 2단계 블록, 즉 ‘범위 및 테스트 제어’입니다. 이 블록에서는 다음 4가지 사항을 지시합니다. ① 작업 중 다른 버그나 개선 사항을 발견하더라도 이 변경 사항을 수정하지 않고 보고만 합니다. ② 요청이 애매한 부분은 가장 직관적인 해석을 하나 선택하여 구현하고, 그 해석을 요약에 기록합니다. ③ 테스트는 요청된 경우 또는 해당 리포지토리에 테스트를 작성하는 습관이 있는 경우에만 소규모로 커밋합니다. ④ 검증에 사용한 일회용 스크립트는 보존합니다.
가이드에 따르면 이 지시사항을 통해 요청되지 않은 추가 및 불필요한 테스트 코드가 크게 줄어들었으며, 작업의 성공률에는 변화가 없었다고 합니다.
여기 주목해야 할 점은 이 블록의 마지막에 “작업이 요구하는 모든 행동을 완전히 구현해야 한다”는 문구가 있다는 것입니다. “잘 해!”라고만 하면, 이번에는 필요한 부분까지 생략되고 만들어지지 않습니다. “불필요한 것은 하지 마라”와 “부탁한 일은 모두 끝내라”를 같은 블록에 나열했을 때, 두 가지 균형이 잡히는 구조라고 생각합니다.
기본적인 xhigh가 예상치 못한 결과로 나타나는 상황 – 장편 작품/노력 고지(effort high)로 진행될 때
긴 문서를 작성하게 할 때는 가장 많은 노력이 필요하다. 이러한 직감이 무너지는 것이 xhigh와 max다. 이 두 가지에서는 5.1이 답변을 작성하기 전에 더 오래 생각할 수 있게 된다. 또한 Claude Code의 기본 설정은 xhigh이므로, 이는 ‘업그레이드한 사람들의 문제’가 아니라 아무것도 하지 않은 사람이 처음부터 시작하는 문제이다.
문제가 발생하는 것은 긴 문서 전체를 한 번의 요청으로 처음부터 다시 작성해 달라고 할 때입니다. 결과물의 대부분을 머릿속으로 초안을 쓰고, 그 후에 답변으로 다시 작성하는 경우가 있습니다. 같은 내용을 두 번 작성하기 때문에 대기 시간이 늘어나고 출력 토큰도 증가합니다. 생각과 답변은 동일한 출력 상한선을 공유하기 때문에, 완료하기 전에 상한선에 도달하면 중간에 잘린 응답이 나타나 다시 시작하게 됩니다.
가장 간단한 해결책은 긴 글을 요청하기 전에 노력을 최소화하는 것입니다.
긴 글의 경우 ‘노력을 더 하면 더 좋아진다’는 기대가 성립되지 않기 때문에, 우선 ‘high’ 버전으로 먼저 작성하고, 결과에 불만족스러웠을 때만 ‘xhigh’나 ‘max’를 시도하는 순서로 진행합니다.
운영 설계를 변경하면 모델의 성능 활용 방식이 달라집니다.
7가지 논점은 각각 다른 작은 기술처럼 보이지만, 사실은 같은 내용을 반복하고 있습니다. 모델의 작동 방식을 결정하는 설정을 초기값 그대로 방치하지 않고 스스로 선택하는, 즉 ‘자율적인 선택’이라는 점을 의미합니다. 노력 측정 재설정, /compact의 타이밍, 자율 실행 지시 등 모든 것이 이 한 점으로 모여듭니다.
클루드 코드의 경우, 노력, 간결성, 클라우드.md への指示의 3가지 요소에 거의 좁혀져 있으므로, API 사용자보다 훨씬 적은 횟수의 조치로 동일한 개선에 더 큰 효과를 얻을 수 있습니다.
더 중요한 점은 노력의 최적점은 작업의 종류에 따라 달라지며, 컴팩트의 적절한 시점 또한 모델 세대가 바뀌면 달라진다는 것입니다. 가이드가 “이전 모델에서 측정했더라도 다시 측정해 주세요”라고 반복하는 것은 모델이 바뀌는 대로 최적해가 달라지기 때문입니다. 설정을 한 번 굳히고 안심하는 것이 아니라, 모델이 바뀌는 대로 측정하는 습관 자체가 장기적으로 성능을 유지하는 가장 좋은 방법입니다.
활용법
지금까지의 내용을 Claude Code의 일상적인 사용법에 녹여냅니다. 시작 순서는 “먼저 측정하고, 다음으로 /compact 습관을 검토하고, 마지막으로 지시를 추가하는” 것입니다. 반대로 진행하면 환경 상태를 확인하지 않은 채로 지시만 쌓는 것과 같습니다.
노력 재조정: 현재 설정대로 평소 작업을 진행하면서 감촉을 느껴보고, 다음으로 /effort medium으로 동일한 종류의 작업을 여러 날 동안 반복하여 품질을 비교합니다. 품질을 유지할 수 있는 가장 낮은 설정을 settings.json의 effortLevel에 고정하세요.
/compact 재검토(컨텍스트 절약을 습득한 경우): 초반의 /compact를 중단하고, 제한 사항에 가까워질 때까지 지연하는 방식을 시도해 봅니다. 수동으로 입력할 때는 /compact 결정 사항, 제약 조건, 대상 파일 경로를 정확히 유지하고, “이렇게” 남겨둔 상태에서 지시를 따라 입력하세요.
자율 실행 및 범위 제어(밤이나 장시간 작업을 위임하는 경우): 아래 2 블록을 CLAUDE.md에 작성하여 모든 세션에서 로드되도록 합니다. 프로젝트에 맞게 CLAUDE.md에 내용을 추가해 주세요.
여기 일본어 번역본을 게시합니다. CLAUDE.md의 독자는 모델이므로, 일본어 지시어도 문제없이 작동합니다. 다만, 가이드가 효과를 측정한 것은 영어 원본의 경우였기 때문에, 엄밀하게 측정한 문구를 사용하고 싶다면, 원본 가이드에서 원문을 복사하십시오.
오늘 업데이트된 자율 실행 제어 기능에 대한 정보입니다.
이번 업데이트에서는 자율 실행의 동작을 더욱 세밀하게 제어할 수 있도록 몇 가지 새로운 기능이 추가되었습니다. 특히, 특정 조건 하에서 자율 실행을 일시 중단하거나, 특정 작업의 우선순위를 변경하는 기능이 추가되어, 더욱 안정적인 자율 실행 환경을 구축할 수 있습니다.
자율 실행의 동작을 모니터링하고, 문제 발생 시 즉각적으로 대응할 수 있도록 실시간 로깅 기능이 개선되었습니다. 로깅 데이터는 상세한 정보를 담고 있어, 문제의 원인을 빠르게 파악하고 해결하는 데 도움이 됩니다.
또한, 자율 실행의 성능을 최적화하기 위해 메모리 사용량을 줄이고 CPU 부하를 최소화하는 기능이 추가되었습니다. 이를 통해 자율 실행은 더욱 효율적으로 작동하며 시스템 자원의 낭비를 줄일 수 있습니다.
이러한 기능들을 통해 자율 실행은 더욱 안정적이고 효율적으로 작동하며 다양한 작업들을 수행할 수 있게 될 것입니다.
자세한 내용은 FAQ를 참고하시거나 고객 지원팀에 문의해 주시기 바랍니다.
당신은 자율적으로 작동하며, 사용자는 실시간으로 확인하지 않고 작업 중 질문에 답변할 수도 없습니다. 따라서 “~しましょうか?”라고 질문하면 작업이 멈추게 됩니다. 원래 요청에서 자연스럽게 유도되는 역효과적인 작업은 확인 없이 진행하고, 멈추는 것은 파괴적인 작업이나 사용자가 판단해야 하는 실제 범위 변경의 경우에만 해당합니다. 작업 완료 후에는 후속 조치를 제안하되, 작업 전에 허락을 구하는 것은 금지됩니다.
사용자가 문제를 설명하거나 질문하거나 생각을 말로 표현하는 것 외에 변경을 요청하지 않는 경우, 결과물은 귀하의 평가 그대로입니다. 소견을 보고하고 멈추어, 요청받을 때까지 수정 사항을 적용하지 마십시오.
턴을 끝내기 전에 자신의 마지막 단락을 점검해 주세요. 그것이 계획, 분석, 질문, 다음 단계의 열거, 미완료 작업에 대한 약속(“아껴두겠습니다”, “~하시면 알려주세요”)이라면 즉시 툴 호출로 그 작업을 실행해 주세요. 오류 후 재시도도, 부족한 정보의 수집도 자신에게 맡기세요. 컨텍스트나 세션이 길어진 것을 멈추는 이유로 삼아서는 안 됩니다. 작업이 완료되었거나, 사용자에게만 가능한 입력으로 막혔을 때만 턴을 마치세요.
당신은 자율적으로 작동합니다. 실시간으로 지켜보는 사람이 아니므로, 작업 중 중간에 질문을 하거나 “혹시…?” 또는 “~할까요?”와 같이 요청하는 것은 작업을 방해합니다. 원본 요청에서 파생되는 되돌릴 수 있는 행동의 경우, 질문 없이 진행하십시오. 사용자에게 결정이 필요한 파괴적인 행동이나 실제 범위 변경에 대해서만 중단하십시오. 작업이 완료된 후 후속 조치를 제공하는 것은 괜찮지만, 작업을 시작하기 전에 허락을 구하는 것은 괜찮지 않습니다. 예외적으로 사용자가 문제를 설명하거나, 질문을 하거나, 생각하는 소리(think out loud)를 하는 경우, 결과물은 귀하의 평가입니다. 결과를 보고 중단하십시오. 그들이 요청할 때까지는 수정 사항을 적용하지 마십시오. 자신의 차례를 끝내는 전에 마지막 단락을 확인하십시오. 만약 계획, 분석, 질문, 다음 단계 목록, 또는 아직 수행하지 않은 업무에 대한 약속(“내가…”, “알려주세요…”)이라면, 즉시 도구 호출을 통해 해당 작업을 완료하십시오. 오류 발생 시 재시도하고, 필요한 정보를 직접 수집하십시오. 문맥이나 세션이 길다고 해서 중단하지 마십시오. 작업이 완료되거나, 사용자가 제공할 수 있는 입력만으로 막혔을 때만 자신의 턴을 종료하십시오. 시스템 상태를 변경하는 명령(예: 재시작, 삭제, 설정 편집)을 실행하기 전에, 해당 작업이 실제로 뒷받침되는 증거가 있는지 확인하십시오. 알려진 실패 패턴과 일치하는 신호는 다른 원인을 가질 수 있습니다.
**범위 및 테스트 제어**
이번 테스트에서는 범위를 명확히 정의하고 테스트를 철저히 통제하여 보다 정확한 결과를 얻는 것을 목표로 합니다. 구체적으로 테스트 대상 범위를 제한하고 테스트 환경을 엄격하게 관리하여 외부 요인으로 인한 영향을 최소화합니다.
또한 테스트 진행 상황을 실시간으로 모니터링하고 필요에 따라 테스트 케이스를 수정하거나 테스트 환경을 조정하여 테스트 품질을 유지합니다.
더 나아가 테스트 결과 분석 시에는 범위에 부합하는 데이터만 사용하고 객관적인 시각에서 평가하여 보다 신뢰성 있는 결과를 얻을 수 있습니다.
테스트 실행 시에는 사전에 테스트 계획을 수립하고 테스트 케이스를 상세하게 기술하여 테스트 효율을 높입니다. 또한 테스트 결과를 기록하고 문제점이나 개선점을 명확히 함으로써 향후 테스트 품질 향상에 기여합니다.
테스트 실시 시에는 관계자 모두가 범위와 테스트 제어에 대해 공통된 이해를 갖는 것이 중요합니다. 정기적인 회의를 통해 진행 상황과 과제를 공유하고 협력 체계를 구축하여 테스트 성공률을 높일 수 있습니다.
작업 중이나 검증 중에 기존 버그, 성능상의 문제, 작업에 명시되지 않은 동작을 발견하더라도 요청된 동작이 그것 없이는 성립하지 않는 경우를 제외하고는 이 변경에서는 수정, 최적화, 확장을 하지 않고, 요약(사마리)에서 후속 조치로 보고합니다. 작업이 모호한 부분은 문맥과 주변 코드가 가장 솔직하게 지지하는 해석으로 구현하고, 그 가정을 요약에 명시하며, 다른 해석까지 고려하지 않습니다. 검증 방법은 자유입니다. 일회용 스크립트나 간단한 체크는 남기지 않습니다. 테스트를 커밋하는 것은 작업이 요구하는 경우 또는 이 리포지토리가 이와 같은 변경에 대해 이미 테스트를 보유하고 있는 경우에만 하되, 인접한 테스트 파일과 같은 규모(대략적으로 명시된 동작 수마다 하나의 좁은 범위의 테스트)로 제한하고, 검증용 일회용 체크를 영구적인 테스트 파일로 변경하지 않습니다. 이는 단순히 “추가 사항”에 대한 이야기입니다. 작업이 요구하는 동작은 모두 완전히 구현합니다.
만약 작업 중이거나 테스트하는 동안 기존 버그, 성능 문제 또는 작업 내용에 언급되지 않은 동작을 발견하면, 이 변경 사항에서 해당 버그를 수정하거나 최적화하거나 확장하지 말고, 해당 동작이 없이는 작동할 수 없는 경우에만 예외적으로 처리하여 요약에 보고하십시오. 작업 내용이 모호하면 해당 내용을 읽고 주변 코드가 가장 직접적으로 지지하는 대로 구현하고, 요약에 그 가정을 명시하십시오. 다른 해석에 대해서는 추가로 개발하지 마십시오. 원하는 방식으로 작업 내용을 검증하되, 임시 스크립트나 간단한 확인은 보관하지 않아도 됩니다. 작업 내용이 테스트를 요청하거나, 이 저장소가 유사한 변경 사항에 대한 테스트를 이미 보유하고 있는 경우에만 테스트를 커밋하고, 인근 테스트 파일과 유사한 크기로 조정하십시오. 각 구체적인 행동에 초점을 맞춘 테스트를 수행해야 하며, 임시 확인 사항을 추가적인 영구 테스트 파일로 변환하지 마십시오. 이 기능은 보조적인 역할에 관한 것입니다: 작업이 요청하는 모든 행동을 완전히 구현하십시오.
“별의 정원사”를 읽었을 때, “아, 이건 정말 중요한 것啊”라고, 정말 와닿는 느낌이 들었어요. 특히, “마음으로 보아야 해”라는 부분이 오랫동안 잊을 수 없는 말씀이 되고 있어요. 제 일도 고객들을 단순하게 팔 뿐이 아니라, 진정으로 필요로 하는 건지 마음으로 느껴보고 함께하는 것이 중요하다는 것을 다시 한번 깨닫게 해주는 책이었어요. 정말 감사합니다.
본문은 API 사용자를 위해 Claude Code를 대체했습니다.
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 44청크
원문 보기 | 출처: note.com