Refactor the falling objects’ behaviors to use the Strategy pattern and their creation to use the Factory pattern, split the implementation into separate files, and update .cursorrules to reflect the new file structure.

이 프롬프트를 같이 넣었더니 비용이 줄어들었다는 건가요? 제가 요지를 맞게 이해한건지 잘 모르겠네요

첨언 드리자면, 코드의 구조는 해당 프로젝트에 맞는 모형으로 구조 개선이 일아나야 합니다. 아래 답변에 있는 내용처럼, AI에게 구조 개선을 질의 하면 해당 프로젝트에 맞는 적절한 구조 개선 방법을 알려줍니다.

개인적인 추천 방식은, AI에게 바로 구조 개선 명령을 넣지 말고, 제안 해보라 시키면 응답을 주는데, 대화를 하며 충분히 효율적인 제안까지 도달 후 적용 해 달라는 형태로 흐름을 가져가시면 좋습니다.

부가적인 팁 하나는, 가급적 컨텍스트 서머리제이션 (문맥 버퍼 초기화)가 일어나기 전 작업을 완료하는것이 좋고, 문맥 버퍼 초기화가 불가피한 경우, 사전에 .cursorrules 에 개선 규칙 추가해 달라 해주는것이 좋습니다. 작업중에 문맥 초기화가 일어나면 AI가 실수 할 가능성이 높아집니다.

제가 직접 이렇게 테스트를 해보지는 않았지만,

'현재 코드를 분석하고, 네가 관리하기 좋은 형태로 구조 개선을 해줘'

라는 프롬프트도 동작 하지 않을까 싶습니다.

정확한 요지는, AI에게 기능 요구사항만 전달 할 것이 아니라, 적절하고 올바른 구조를 잘 유도하는것이 비용 절감에 도움이 될 수 있다 라는 뜻으로 생각 됩니다.

참고로, 입력되는 소스 크기가 작아질수록 소모되는 토큰량이 줄어든다는것은 잘 알려진 명백한 사실 입니다. .cursorignore 파일이 이것때문에 만들어졌으니까요.

대체적으로 AI에게 구조 개선을 시키면, 거의 대부분 소스 코드 량이 감소되는 경향이 있어서, 어떤 이유에서든 정리를 시키면 비용이 줄어든다는 말은 신빙성 있는 주장 같습니다.

이 글은 좋은 구조 유도를 통해 추가적인 토큰 사용량 감소를 이루어 낼 수 있다는 주장이 더해진것이구요.

맞습니다. 본문에도 나와 있지만, 코드 개선 이후 프로젝트 코드 크기가 줄어든것은 사실입니다.

다만, 이 예제에서 캐릭터 개수 기준 약 10% 정도의 감소가 일어났는데, 이것만으로 토큰 사용량 감소 37.91%를 설명 할 수는 없습니다.

본문에 소스 저장소 링크가 있으며 어느 누구든 재연하여 테스트 해볼 수 있습니다.