Andrej Karpathy는 그의 CLAUDE.MD 파일을 위한 4가지 조항 목록을 제공했습니다.

1. 추측하지 말고 질문하십시오. 불분명한 점이 있다면 단 한 줄을 쓰기 전에 질문하십시오. 의도, 아키텍처(Architecture), 또는 요구사항(Requirements)에 대해 암묵적으로 가정하지 마십시오.
2. 가장 단순한 솔루션을 우선하십시오. 작동할 수 있는 가장 단순한 것을 항상 구현하십시오. 명시적으로 요청되지 않은 추상화(Abstractions)나 유연성을 추가하지 마십시오.
3. 관련 없는 코드는 건드리지 마십시오. 파일이나 함수가 현재 작업의 직접적인 일부가 아니라면, 개선할 수 있다고 생각되더라도 수정하지 마십시오.
4. 불확실성을 명시적으로 표시하십시오. 접근 방식이나 기술적 세부 사항에 대해 확신이 없다면, 진행하기 전에 그렇게 말하십시오. 확실성 없는 자신감은 공백을 인정하는 것보다 더 많은 피해를 줍니다.

이 조항들은 훌륭하지만, 저는 이로 인해 발생하는 특정한 문제를 발견했고 이를 해결했습니다:
5. 저는 항상 더 나은 방식에 대한 아이디어에 열려 있습니다. 전술적인 변화보다 장기적인 영향을 미칠 수 있는 더 나은 방식이나 방법을 주저하지 말고 제안해 주세요. (몇 가지 예시로서)

제가 왜 이 조항을 추가했는지 설명하겠습니다.
저는 소위 프런티어 모델(Frontier models)이라고 불리는 정말 멍청한 모델들과 작업하는 것을 경험해 왔습니다. 제가 발견한 것은 그들을 신뢰할 수 없다는 것이었습니다. 그래서 Andrej의 규칙들은 저에게 매우 잘 맞았습니다. 하지만 Claude의 경우, 제가 지시를 내리면 그것을 의심하지 않고 따르기만 한다는 점을 알아차렸습니다. 제가 '나를 몰아붙여라(grill-me)'라는 기술을 설정했을 때조차, Claude는 추론 시스템(Reasoning system)이 아니라 단순한 기록자(Note-taker)처럼 행동했습니다. 저는 Claude가 생각할 때, 어쩌면 제 솔루션이 그리 훌륭하지 않을 수도 있다는 것을 느끼기 시작했습니다. 프로그래머로서 이러한 규칙들을 통해, 저는 제 페어 프로그래머(Pair programmer)인 Claude가 솔루션에 기여하는 것을 사실상 침묵시켜 버렸고, 그들을 코드 생산자(Code producer) 그 이상도 이하도 아니게 축소시켜 버렸습니다.

이 마지막 조항을 추가함으로써, '나를 몰아붙이는' 과정에서 이미 측량할 수 없을 정도로 큰 도움을 받았습니다. 이제 Claude는 "이 방식은 어떨까요? 당신의 목표를 달성하지만, 다른 방식으로 접근합니다"라고 말하곤 합니다.
이 내용을 여러분과 공유하며, 여러분의 피드백을 기다립니다.

참고를 위해 Andrej Karpathy가 원래의 4가지 조항을 공유한 영상입니다:
https://x.com/Ai_Tech_tool/status/2058140300502261784
/u/Osi32 님이 제출함
[link] [comments]