저는 현재 제가 운영하는 실제 SaaS인 HealthWatch Global을 위해, Claude Code가 단독으로 구축하고 운영하도록 지시한 예약된 Claude Code 루틴 세트(일일 보안/상태 점검, 소셜 모니터링, 프리랜서 리드 소싱 등)를 몇 주 동안 운영 환경(production)에서 점차 늘려가며 실행해 오고 있습니다. 비슷한 작업을 수행하는 분들에게 도움이 될 수 있도록, 제가 결국 채택하게 된 몇 가지 구체적인 관행을 공유합니다:

1. 도구 호출(tool call)의 반환 값을 부수 효과(side effect)의 증거로 절대 신뢰하지 마세요. 양식 제출이나 클릭이 "성공"했다는 것(에러 없음)이 실제 기반 동작이 일어났다는 증거는 아닙니다. 저는 이제 중대한 동작 이후에는 이를 완료된 것으로 기록하기 전에, 예를 들어 신용 잔액이 실제로 감소했는지, 목록에 항목이 실제로 보이는지 등 실제적이고 독립적인 신호를 확인하도록 요구합니다. 이 방식을 통해 여러 차례의 거짓 양성(false-positive) "성공" 사례를 잡아냈습니다.

2. 자율성(Autonomy)은 하나의 설정이 아니라, 동작 유형별로 결정되는 것입니다. 저는 일부 동작(두 번의 감독 하에 성공하는 것을 지켜본 후, 프리랜서 플랫폼에서 실제 견적을 검색하고 제출하는 작업)에는 완전한 무인 자율성을 부여했지만, 겉보기에는 비슷해 보여도 실제로는 다른 다른 동작들에는 엄격한 확인 게이트(confirmation gate)를 유지하고 있습니다(예: 직접 찾은 완전히 새로운 연락처에 연락하는 것 vs. 이미 열려 있는 대화에 답장하는 것). 동일한 도구, 동일한 플랫폼이라도 위험 프로필(risk profile)이 다르면 자율성 수준도 달라야 합니다.

3. 침묵이 재접근에 대한 동의는 아닙니다. 유혹적인 패턴이 있습니다: 연락처가 답장을 하지 않았으니, 나중에 다른 것을 제안하는 것입니다. 저는 무언가가 발송된 후가 아니라, 검토 단계에서 이 문제를 잡아냈습니다. 진정으로 다른 제안이라 할지라도, 두 번째의 요청되지 않은 메시지는 도움이 된다기보다 훨씬 더 강요하는 것처럼 읽히는 경우가 많습니다. 이제 "이미 연락했으나 응답 없음"은 마침표를 찍고 종료됨을 의미합니다.

4. 하나 이상의 세션이 동일한 파일에 접근할 수 있게 되면 메모리/컨텍스트 위생(Memory/context hygiene)이 무엇보다 중요해집니다. 여러 세션(예약형 또는 대화형)이 동일한 메모리/설정(config)을 읽고 쓴다면, 그 안의 모든 주장은 실시간 상태(live state)가 아니라 스냅샷(snapshot)입니다. "X가 참이다"라고 말하는 파일을 신뢰하기 전에 검증하는 법을 배웠습니다. 다시 읽힐 때쯤에는 이미 오래된 정보(stale)일 수 있기 때문입니다.

사람들이 실제 업무를 위해 Claude Code를 무인으로 실행하면서 어떤 다른 패턴들을 찾아냈는지 궁금하시다면 확인해 보세요. /u/AnnualButterfly5313 님이 제출했습니다 [link] [comments]