▲
sleepyeye 8달전 | parent | ★ favorite | on: 토큰 사용량 37.91%를 감소시킨 단 한줄의 프롬프트(modgo.org)

댓글로 말씀하시는게 무엇인지 잘 이해는 못하겠습니다. 저는 두 방법을 공평히 비교하려면 소모되는 총 토큰 숫자를 비교해야하지 않냐는게 제 코멘트 였습니다. 리팩토링 역시 토큰을 소모하지 않나요?

추가로 답변주신건 글에 적혀있지도 않고 실험 역시 진행되지 않은 내용인것 같습니다. 1회 질의당 토큰 비교가 아니라 여러번 질의시 리팩토링 오버헤드는 낮아지며 각 질의당 기대 토큰 숫자 줄기 때문에 총 토큰 숫자에서 이득이 날거란 말이신 것 같습니다. 이는 여러번 질의시 작성자분 생각대로 코스트다운이 유지될때나 말씀인거같은데 매우 이상적인 상황을 상정할 때 할 수 있는 이야기인듯 합니다. 리팩토링에 의한 코스트 다운이 그 다음 질의 숫자와 무관하게 유지될 거란 보장은 할수도 없고 실험없이 가정할 수도 없습니다. 의도된 말씀을 주장하시려면 1회 이상의 질의에 대한 코스트 다운을 실험으로 보여주시면 될 것 같습니다. 하지만 실험은 1회만 하시고 비교하신게 아닌가요?

덧붙여 그냥 제 가정일 뿐이지만 동일 목표(이상적인 최종 출력물)를 위해 질의를 무한히 반복해 나간다면 이상적인 상황에서 리팩토링 유무에 상관없이 코드는 동일한 형태로 수렴해 나가야 할 듯 합니다. (이상적인 최종 출력물은 유일)
이게 합리적인 가정이라면 질의가 반복될수록 리팩토링 유무의 차이가 적어지므로 토큰 코스트다운 이득이 점차 낮아질 것 같구요. 해서 거시적으로 생각했을때 이 코스트 다운에 대한 이득이 충분히 지속되지 않는다면 질의에 사용되는 총 토큰 숫자 차이는 유의미 하지 않을 수도 있지 않을까요

▲
rhajrs 8달전  [-]

그리고, 프롬프트 연계 횟수 실험 와 관련한 내용도 문의 해 주셨는데요,

사실 이는 역으로 저자가 속된말로 사기를 치기에 좋은 요소입니다.

개발이라는 행위 자체가 진행하는 방향에 매우 많은 선택지들이 존재하고, 토큰 사용량이 더 크게 벌어지는 방향으로 프롬프트를 누적해버리면, 저 수치는 눈덩이마냥 더 크게 불어나 버릴겁니다.

연구에는 'Cumulative Science' 라는 철학이 있습니다.

아직 1회 명령에 대한 토큰 사용량 관련 연구를 적어도 제 기준에서는 한번도 찾은적이 없기에,

즉시 N회 연구를 하는것이 아닌, 확실한 1회에 대한 테스트와 결론을 다루는데 집중 한 것이고,

N회 연구는 이 실험에 이어 연구가 이어지면 되겠죠.

답변달기
▲
rhajrs 8달전  [-]

또한, 다른 글로서, 코드베이스의 차이에 따른 AI의 동작 차이를 다룬적이 있습니다.
(이 또한 이 GeekNews에 소개 된 적이 있구요 : https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)

짧게 설명하면, AI에게 입력되는 코드 베이스에 따라 출력물의 품질이 달라진다는 테스트와 결과를 다루고 있습니다.

초기 코드베이스의 품질 및 방향성에 따라, 이어지는 코드 품질이 유지가 될 수도, 계속하여 나빠질 수 있다는 의미입니다.

즉, 프로젝트 초기 단계에서의 리팩토링 비용과, 한참 진행 된 프로젝트의 리팩토링 비용이 크게 다를 수 있다는 뜻입니다.

만약 질문자 분께서 개발자라면, '돛단배 위의 항공모함' 이라는 말을 한번쯤 들어봤을 수도 있을 것 같은데요,

리팩토링은 어느 시점에 수행 되어야 할 지, 혹은 프로젝트 초기 발라지는 사상 및 설계에 따라 비용이 어마어마하게 달라지는 심오한 주제 입니다.

이를 변수로 포함하여 결론을 불안정하게 가져가는것보다,

'아, 코드베이스 품질이 좋으면 토큰사용량이 줄어드는구나' 만큼은 확실하게 설명 가능 한 테스트를 진행 한 것이구요.

답변달기
▲
rhajrs 8달전  [-]

다시 설명 드려 보겠습니다.

바이브코딩 수행자는 비개발자부터 숙련된 개발자까지 그 범위가 넓습니다. 그들이 보유한 지식 상태에 따라, 이 글 내용과 전혀 무관하게 출력물의 품질은 천차만별입니다.
누군가는 자연스레 cursor 사용 전제 하 .cursorrules에 기본 OOP 규약과 클래스/메서드 분리 규칙을 담아 리팩토링이 거의 필요하지 않은 형태로 운용이 될 수도 있지만,
누군가로부터는 너무나도 기본적인 주요 내용 파악 부재로 인한 저수준 코드 양산이 일어나고 있을 수 있습니다.

심지어는, 기본적으로 프로젝트 룰 설정을 통해 코드 품질을 좋게 유지하라는 글과 경험들은 앞서 예시가 많습니다.

이는 누군가는 명시적 리팩토링 없이도 토큰 사용량 측면에서 이익을 보고 있을 수 있다는 가능성을 시사 합니다.

단, 위 케이스들은, 해당 룰 정의를 통해 실행 단위 당 명확한 토큰 사용량 감소를 정리하고 있지는 않습니다. 이에 이 글을 통해 코드베이스 품질에 따른 토큰 사용량 차이를 테스트하고 그 결과를 정리 한 것이구요.

즉, 사용자에 따라, 명시적 리팩토링 횟수는 그 자체가 다시금 0~n회로 변수가 되며,

이 글의 본질적 의도는, '왜 좋은 품질의 코드 베이스를 신경 쓰는것이 좋은가?' 를 설명하고 있다고 보면 좋을 것 같습니다.

답변달기