Claude의 thinking/effort 레벨은 어떻게 결정하시나요?

맞아, 내가 아는 게 부족해서... 언제 어떤 설정을 쓰는 게 적절한지 판단하기가 어렵네.

맞음. 우리도 새로 greenfield 프로젝트 시작하면서 전체 라이프사이클에 맞춰 스킬을 쌓았음. 모든 건 markdown으로 하고 Hooks로 determinism도 추가함. 실수한 건 꼼꼼하게 기록해서 스킬에 추가해두니까 같은 실수를 안 하게 됨. Opus로 계획 짜고 Sonnet으로 구현하는 게 제일 잘 먹힘. Opus가 뭘 바꿀지, 어디를, 검증 단계는 뭔지 예측 가능하게 계획을 짜주면, 구현 스킬이 알아서 완료 처리까지 해줌. PR은 500~600라인 정도로 유지해서 리뷰하기 편함.

목표를 달성하는 방법을 설명하지 마. 목표가 무엇인지 설명해. 모델이 그걸 달성하기 위해 얼마나 많은 노력이 필요한지 스스로 결정하게 둬.

난 그 주에 남은 사용량에 따라 xhigh랑 high 사이를 왔다 갔다 해.

난 Claude한테 물어봐. Claude의 평가가 아주 철저하거든. 왜 그렇게 생각하는지도 설명해주고. 연습하다 보면 뭘 써야 할지 감이 올 거야. 그래도 난 확실히 하려고 자주 물어봐. 복사해서 쓸 문장을 하나 만들어 뒀어: "이 작업을 수행하는 데 어떤 모델, 노력, thinking 모드가 더 나을까? 그리고 새 대화를 시작해야 하는지도 알려줘. 만약 그렇다면, 네가 작업을 수행하게 하려면 어떤 프롬프트를 써야 하는지도 알려줘."

복사 붙여넣기만 하지 말고 스킬로 만들어서 클릭질 좀 줄여봐.

데이터베이스 마이그레이션할 때 thinking 레벨을 아끼는 건 절대 안 할 짓이지. 스키마 꼬였을 때의 비용이랑 토큰 몇 개, 시간 좀 더 쓰는 거랑 비교가 돼? 코딩 작업할 때 잘못했을 때의 영향이 바로 안 보이거나 나중에 고치기 골치 아플 것 같으면, 푼돈 아끼려다 큰돈 잃지 말고 그냥 thinking을 최대로 올려. 난 그냥 항상 max thinking으로 해.

난 그냥 Medium으로 둬.

thinking은 언어를 다른 언어로 변환하는 것 같은 복잡한 작업에만 써. 유스케이스, 가용 자원, 데이터베이스 옵션 같은 거 말이야.

난 작업 크기 상관없이 무조건 모든 프롬프트에 extra high로 돌림.