- 좀 더 다양한 실험 필요
전적으로 동의 합니다. 이런 형태의 비판은 크게 환영합니다.
세상은 혼자 살아가지 않고, 개개인의 능력 혹은 상황이 다릅니다.
저 또한 일개 개발자에 불과하며, 개인 비용을 들여 모든 테스트를 수행 할 수 없습니다.
이 글이 씨앗이 되어 많은 이들에게 좋은 영향, 그리고 이어지는 많은 연구에 시발점이 되었으면 하는 바램입니다.
- 전처리 전후 소스코드를 비교할 필요 있음.
서브타이틀이 내용과 맞지는 않네요. 재정리를 하면 '토큰 감소를 일으키는 더 명확한 요소 분석이 필요하다' 가 서브타이틀로 어울려 보입니다.
이 내용은 동의 되는 부분이 많습니다. 다만, 본 글의 성격에는 '이 글을 보는 사람들에게 현실적인 적용 방법을 제안한다'는 요소를 담고 있습니다.
이미, 이 글에 달린 댓글들만 보더라도 분위기를 알 수 있는데요, 저도 최근에 알게 된 사실이지만, AI 사용자 중에는 비개발자 바이브코더분들도 많은 것으로 추정이 되고 있습니다.
AI를 통하지 않은 저자가 직접 조정한 코드로부터 대단한 결과를 만들게 될 경우,
이는 저자가 개발실력을 자랑하는, AI 능력을 폄하하는 결과로 비추어지기 쉽습니다.
이에, 여느 바이브코더들이 활용 할 수 있는 '프롬프트'라는 요소로서 그 결과를 누구나 체감 할 수 있는 예제를 다루게 되었습니다.
이 연구에 이어, AI 토큰 사용량에 영향을 주는 요소들이 세분화 될 수 있는 연구가 이어지면 좋을 것 같습니다.
- 공평한 비교와 관련하여
- 바이브 코딩은 1번의 프롬프트로 출력물이 완성되지 않습니다.
1회의 구조수정을 통하여 n회의 프롬프트의 토큰 소모율을 낮추는 효과를 가져오게 될 경우, 토큰 감소량은 동일하게 수행 될 n회에 걸쳐 반영 됩니다.
n은 프로젝트의 목적과 기능 수, 그리고 이를 위한 코드의 양과 복잡성에 의해 결정되는 수치이며,
또한 최근 cursor / claude code agent들은 무한 반복 수행 혹은 AI의 무분별한 토큰 사용 문제를 해결하기 위해 수행 단위를 작게 가져가는 업데이트들이 일어나고 있는 관계로,
프로젝트 복잡도와 관련한 n 수치 연구는 별도로 이루어 지는것이 옳다 생각합니다.
- 최대한의 이해를 돕기 위하여, 별도의 주문이 없을 시 AI가 작성하는 구조적 문제가 있는 코드로부터 코드 개선의 예를 들었습니다.
이 부분에서 놓치지 말아야 하는 부분은, 구조의 개선은 절대적으로 코드의 개발과 독립적으로 일어나는 행위가 아니라는 점입니다.
최초의 프롬프트, 혹은 AI ruleset(.cursorrules)와 같은 제약을 통하여 base context로서 영향을 줄 수 있는 부분이며,
프로젝트 개발 사이클 도중 1회의 구조개선이 만사형통을 이루어 낼 수 없습니다.
즉, 일정 주기로 코드개선을 계획하기 보단 base context 로서 올바른 구조 유도가 더 좋은 방향입니다.
또한, base context로서 구조 유도 주문 규칙이 있는 경우와 없는 경우에 대한 연구는 별도로 이루어 지는것이 옳다 보입니다.
1번 항목에 대하여 정리하면,
- base context로서 구조 유도 주문 규칙이 있을 때 전체 토큰 사용량이 감소 할 가능성도 있으며,
- n회의 프롬프트 명령을 통한 최종 출력물 획득 변수가 있으므로,
1회의 구조 개선 프롬프트 명령의 토큰 사용량을 가산 하여 계산해야 한다는 주장은 어폐가 있습니다.
댓글로 말씀하시는게 무엇인지 잘 이해는 못하겠습니다. 저는 두 방법을 공평히 비교하려면 소모되는 총 토큰 숫자를 비교해야하지 않냐는게 제 코멘트 였습니다. 리팩토링 역시 토큰을 소모하지 않나요?
추가로 답변주신건 글에 적혀있지도 않고 실험 역시 진행되지 않은 내용인것 같습니다. 1회 질의당 토큰 비교가 아니라 여러번 질의시 리팩토링 오버헤드는 낮아지며 각 질의당 기대 토큰 숫자 줄기 때문에 총 토큰 숫자에서 이득이 날거란 말이신 것 같습니다. 이는 여러번 질의시 작성자분 생각대로 코스트다운이 유지될때나 말씀인거같은데 매우 이상적인 상황을 상정할 때 할 수 있는 이야기인듯 합니다. 리팩토링에 의한 코스트 다운이 그 다음 질의 숫자와 무관하게 유지될 거란 보장은 할수도 없고 실험없이 가정할 수도 없습니다. 의도된 말씀을 주장하시려면 1회 이상의 질의에 대한 코스트 다운을 실험으로 보여주시면 될 것 같습니다. 하지만 실험은 1회만 하시고 비교하신게 아닌가요?
덧붙여 그냥 제 가정일 뿐이지만 동일 목표(이상적인 최종 출력물)를 위해 질의를 무한히 반복해 나간다면 이상적인 상황에서 리팩토링 유무에 상관없이 코드는 동일한 형태로 수렴해 나가야 할 듯 합니다. (이상적인 최종 출력물은 유일)
이게 합리적인 가정이라면 질의가 반복될수록 리팩토링 유무의 차이가 적어지므로 토큰 코스트다운 이득이 점차 낮아질 것 같구요. 해서 거시적으로 생각했을때 이 코스트 다운에 대한 이득이 충분히 지속되지 않는다면 질의에 사용되는 총 토큰 숫자 차이는 유의미 하지 않을 수도 있지 않을까요
그리고, 프롬프트 연계 횟수 실험 와 관련한 내용도 문의 해 주셨는데요,
사실 이는 역으로 저자가 속된말로 사기를 치기에 좋은 요소입니다.
개발이라는 행위 자체가 진행하는 방향에 매우 많은 선택지들이 존재하고, 토큰 사용량이 더 크게 벌어지는 방향으로 프롬프트를 누적해버리면, 저 수치는 눈덩이마냥 더 크게 불어나 버릴겁니다.
연구에는 'Cumulative Science' 라는 철학이 있습니다.
아직 1회 명령에 대한 토큰 사용량 관련 연구를 적어도 제 기준에서는 한번도 찾은적이 없기에,
즉시 N회 연구를 하는것이 아닌, 확실한 1회에 대한 테스트와 결론을 다루는데 집중 한 것이고,
N회 연구는 이 실험에 이어 연구가 이어지면 되겠죠.
또한, 다른 글로서, 코드베이스의 차이에 따른 AI의 동작 차이를 다룬적이 있습니다.
(이 또한 이 GeekNews에 소개 된 적이 있구요 : https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
짧게 설명하면, AI에게 입력되는 코드 베이스에 따라 출력물의 품질이 달라진다는 테스트와 결과를 다루고 있습니다.
초기 코드베이스의 품질 및 방향성에 따라, 이어지는 코드 품질이 유지가 될 수도, 계속하여 나빠질 수 있다는 의미입니다.
즉, 프로젝트 초기 단계에서의 리팩토링 비용과, 한참 진행 된 프로젝트의 리팩토링 비용이 크게 다를 수 있다는 뜻입니다.
만약 질문자 분께서 개발자라면, '돛단배 위의 항공모함' 이라는 말을 한번쯤 들어봤을 수도 있을 것 같은데요,
리팩토링은 어느 시점에 수행 되어야 할 지, 혹은 프로젝트 초기 발라지는 사상 및 설계에 따라 비용이 어마어마하게 달라지는 심오한 주제 입니다.
이를 변수로 포함하여 결론을 불안정하게 가져가는것보다,
'아, 코드베이스 품질이 좋으면 토큰사용량이 줄어드는구나' 만큼은 확실하게 설명 가능 한 테스트를 진행 한 것이구요.
다시 설명 드려 보겠습니다.
바이브코딩 수행자는 비개발자부터 숙련된 개발자까지 그 범위가 넓습니다. 그들이 보유한 지식 상태에 따라, 이 글 내용과 전혀 무관하게 출력물의 품질은 천차만별입니다.
누군가는 자연스레 cursor 사용 전제 하 .cursorrules에 기본 OOP 규약과 클래스/메서드 분리 규칙을 담아 리팩토링이 거의 필요하지 않은 형태로 운용이 될 수도 있지만,
누군가로부터는 너무나도 기본적인 주요 내용 파악 부재로 인한 저수준 코드 양산이 일어나고 있을 수 있습니다.
심지어는, 기본적으로 프로젝트 룰 설정을 통해 코드 품질을 좋게 유지하라는 글과 경험들은 앞서 예시가 많습니다.
- 파일 크기를 작게 유지하라 : https://medium.com/realworld-ai-use-cases/…
- 코드베이스 실행 속도를 빠르게 유지하는 방법 : https://forum.cursor.com/t/…
- 윈드서프 모범 사례 및 가이드 라인 : https://gist.github.com/muratkeremozcan/…
이는 누군가는 명시적 리팩토링 없이도 토큰 사용량 측면에서 이익을 보고 있을 수 있다는 가능성을 시사 합니다.
단, 위 케이스들은, 해당 룰 정의를 통해 실행 단위 당 명확한 토큰 사용량 감소를 정리하고 있지는 않습니다. 이에 이 글을 통해 코드베이스 품질에 따른 토큰 사용량 차이를 테스트하고 그 결과를 정리 한 것이구요.
즉, 사용자에 따라, 명시적 리팩토링 횟수는 그 자체가 다시금 0~n회로 변수가 되며,
이 글의 본질적 의도는, '왜 좋은 품질의 코드 베이스를 신경 쓰는것이 좋은가?' 를 설명하고 있다고 보면 좋을 것 같습니다.
저도 비슷하게 느껴졌습니다.
글쓰신분 의도는 뭔지 알겠으나 하신것 대비 글이 과도하게 복잡한 것 같습니다.
최대한 실험에 사용된 디테일을 글에 녹이고 싶어 이렇게 작성하신것 같은데
핵심만 간략하게 추리셔도 이런 주제에 관심있는 분들이라면 아마 이해하실 것 같습니다.
과감하게 디테일은 쳐내고 핵심만 간추리신다면 더 낫지 않을까 싶습니다.
저는 글쓴분 의도나 결과 자체는 재밌다고 느꼈습니다.
더 좋은 소스코드가 더 적은 토큰 소모로 이어진다는게 주요 논지인것이고
그에 관련된 실험 설계를 하시고 수행을 하신 것 같습니다.
실험에 대해 제가 이해한 부분만 나열한다면
인것 같네요.
그리고 제가 이해한 바가 맞다면 프롬프트로 전처리 한 소스코드가 대체적으로 토큰 소모량이 적다는 결론인 것 같습니다.
재밌는 결론이긴 하나, 실험에 대한 제 의견은 다음과 같습니다.
공평한 비교가 아님
수치상으로는 낮아진 것으로 보이나 소스코드를 처리하기 위한 전체 토큰 숫자로 비교하는게 맞을 것 같습니다.
다시말해 전처리하기 위해 사용된 토큰 숫자 역시 고려되어야 할 듯 합니다.
전처리하기 위해 사용된 토큰숫자가 과도하게 크다면 사실상 토큰을 더 많이 소모해 무의미한것이 되고, 적다고 해도 실제 토큰 소모량 차이는 글보다 현저하게 적을 듯 싶습니다.
전처리 전후 소스코드를 비교할 필요 있음.
전처리에 사용된 토큰을 제외한다면 질의시 토큰 소모량은 유의미하게 감소된 듯 보입니다.
다만 소스코드의 정확히 어떤 차이로 인해 이러한 차이가 나오는지 분석한다면 좀 더 글의 의미가 커질 것 같습니다.
그러한 차이를 극대화 하기위한 전처리 프롬프트 최적화가 가능하단 소리니까요.
글쓴분은 코드 구조 리팩터링이 이러한 결과를 불러왔다고 말씀하시나 저는 동의하지는 않고 아직 알 수 없다고 생각합니다.
AI에게 리팩터링 말고 다른부분을 개선시켰을때도 토큰소모량 감소가 있을 수 있을테니까요.
좀 더 다양한 실험 필요
현재 코드 말고 다른 코드베이스에서도 동일한 실험을 돌려봐야한다고 생각합니다.
이게 일관적으로 좋게 나오는것인지 아닌지에 대한 판단을 해야하니까요.
다만 현실적으로 이건 테스트가 힘들 수 있다는 것은 이해하므로 그냥 참고만 하시는게 좋을 것 같습니다.