바이브코딩 수행자는 비개발자부터 숙련된 개발자까지 그 범위가 넓습니다. 그들이 보유한 지식 상태에 따라, 이 글 내용과 전혀 무관하게 출력물의 품질은 천차만별입니다.
누군가는 자연스레 cursor 사용 전제 하 .cursorrules에 기본 OOP 규약과 클래스/메서드 분리 규칙을 담아 리팩토링이 거의 필요하지 않은 형태로 운용이 될 수도 있지만,
누군가로부터는 너무나도 기본적인 주요 내용 파악 부재로 인한 저수준 코드 양산이 일어나고 있을 수 있습니다.
심지어는, 기본적으로 프로젝트 룰 설정을 통해 코드 품질을 좋게 유지하라는 글과 경험들은 앞서 예시가 많습니다.
댓글로 말씀하시는게 무엇인지 잘 이해는 못하겠습니다. 저는 두 방법을 공평히 비교하려면 소모되는 총 토큰 숫자를 비교해야하지 않냐는게 제 코멘트 였습니다. 리팩토링 역시 토큰을 소모하지 않나요?
추가로 답변주신건 글에 적혀있지도 않고 실험 역시 진행되지 않은 내용인것 같습니다. 1회 질의당 토큰 비교가 아니라 여러번 질의시 리팩토링 오버헤드는 낮아지며 각 질의당 기대 토큰 숫자 줄기 때문에 총 토큰 숫자에서 이득이 날거란 말이신 것 같습니다. 이는 여러번 질의시 작성자분 생각대로 코스트다운이 유지될때나 말씀인거같은데 매우 이상적인 상황을 상정할 때 할 수 있는 이야기인듯 합니다. 리팩토링에 의한 코스트 다운이 그 다음 질의 숫자와 무관하게 유지될 거란 보장은 할수도 없고 실험없이 가정할 수도 없습니다. 의도된 말씀을 주장하시려면 1회 이상의 질의에 대한 코스트 다운을 실험으로 보여주시면 될 것 같습니다. 하지만 실험은 1회만 하시고 비교하신게 아닌가요?
덧붙여 그냥 제 가정일 뿐이지만 동일 목표(이상적인 최종 출력물)를 위해 질의를 무한히 반복해 나간다면 이상적인 상황에서 리팩토링 유무에 상관없이 코드는 동일한 형태로 수렴해 나가야 할 듯 합니다. (이상적인 최종 출력물은 유일)
이게 합리적인 가정이라면 질의가 반복될수록 리팩토링 유무의 차이가 적어지므로 토큰 코스트다운 이득이 점차 낮아질 것 같구요. 해서 거시적으로 생각했을때 이 코스트 다운에 대한 이득이 충분히 지속되지 않는다면 질의에 사용되는 총 토큰 숫자 차이는 유의미 하지 않을 수도 있지 않을까요
바이브 코딩은 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회의 구조 개선 프롬프트 명령의 토큰 사용량을 가산 하여 계산해야 한다는 주장은 어폐가 있습니다.
글 중간에 SDD 상세 소개 링크가 내용이 좋네요. 아래는 AI로 요약해 본 겁니다.
명세 주도 개발(Specification-Driven Development, SDD)
The Power Inversion
The SDD Workflow in Practice
Why SDD Matters Now
Core Principles
Implementation Approaches
Streamlining SDD with Commands
/specify: 기능 설명을 구조화된 명세로 변환하고 자동 번호 부여, 브랜치 생성, 템플릿 기반 디렉터리 구성을 자동화함/plan: 명세 분석 → 헌법 준수 검토 → 기술 번역 → 데이터 모델·API 계약·테스트 시나리오 문서화 → 퀵스타트 검증을 생성함/tasks:plan.md와 관련 설계를 읽어 실행 가능한 태스크 리스트를 산출하고, 병렬 가능 태스크 표시와 안전 병렬 그룹화를 제공함The Power of Structured Automation
Template-Driven Quality
[NEEDS CLARIFICATION]마커로 추측 금지와 명시적 질문을 유도함implementation-details/로 분리해 가독성 유지함The Constitutional Foundation
memory/constitution.md의 불변 원칙으로 모든 구현을 일관·단순·고품질로 유지하는 개발 헌법을 채택함The Transformation
파이어폭스 쓰는데 PIP 지원이 안 된다는 메시지가 뜨는군요. 유튜브 볼 때 PIP 기능을 잘 썼는데 말이에요
와 이거 멋있네요
오 대박;;; pip가 영상만 볼 수 있는게 아니라 다양한 인터렉션이 가능한지 처음알았어요!
감사합니다..!
빅브라더 소스코드 유출!
좋은 자료 감사합니다! (__)
그리고, 프롬프트 연계 횟수 실험 와 관련한 내용도 문의 해 주셨는데요,
사실 이는 역으로 저자가 속된말로 사기를 치기에 좋은 요소입니다.
개발이라는 행위 자체가 진행하는 방향에 매우 많은 선택지들이 존재하고, 토큰 사용량이 더 크게 벌어지는 방향으로 프롬프트를 누적해버리면, 저 수치는 눈덩이마냥 더 크게 불어나 버릴겁니다.
연구에는 'Cumulative Science' 라는 철학이 있습니다.
아직 1회 명령에 대한 토큰 사용량 관련 연구를 적어도 제 기준에서는 한번도 찾은적이 없기에,
즉시 N회 연구를 하는것이 아닌, 확실한 1회에 대한 테스트와 결론을 다루는데 집중 한 것이고,
N회 연구는 이 실험에 이어 연구가 이어지면 되겠죠.
토목같은거 하면 대학수업에서도 이미 사용하고 있죠
또한, 다른 글로서, 코드베이스의 차이에 따른 AI의 동작 차이를 다룬적이 있습니다.
(이 또한 이 GeekNews에 소개 된 적이 있구요 : https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
짧게 설명하면, AI에게 입력되는 코드 베이스에 따라 출력물의 품질이 달라진다는 테스트와 결과를 다루고 있습니다.
초기 코드베이스의 품질 및 방향성에 따라, 이어지는 코드 품질이 유지가 될 수도, 계속하여 나빠질 수 있다는 의미입니다.
즉, 프로젝트 초기 단계에서의 리팩토링 비용과, 한참 진행 된 프로젝트의 리팩토링 비용이 크게 다를 수 있다는 뜻입니다.
만약 질문자 분께서 개발자라면, '돛단배 위의 항공모함' 이라는 말을 한번쯤 들어봤을 수도 있을 것 같은데요,
리팩토링은 어느 시점에 수행 되어야 할 지, 혹은 프로젝트 초기 발라지는 사상 및 설계에 따라 비용이 어마어마하게 달라지는 심오한 주제 입니다.
이를 변수로 포함하여 결론을 불안정하게 가져가는것보다,
'아, 코드베이스 품질이 좋으면 토큰사용량이 줄어드는구나' 만큼은 확실하게 설명 가능 한 테스트를 진행 한 것이구요.
다시 설명 드려 보겠습니다.
바이브코딩 수행자는 비개발자부터 숙련된 개발자까지 그 범위가 넓습니다. 그들이 보유한 지식 상태에 따라, 이 글 내용과 전혀 무관하게 출력물의 품질은 천차만별입니다.
누군가는 자연스레 cursor 사용 전제 하 .cursorrules에 기본 OOP 규약과 클래스/메서드 분리 규칙을 담아 리팩토링이 거의 필요하지 않은 형태로 운용이 될 수도 있지만,
누군가로부터는 너무나도 기본적인 주요 내용 파악 부재로 인한 저수준 코드 양산이 일어나고 있을 수 있습니다.
심지어는, 기본적으로 프로젝트 룰 설정을 통해 코드 품질을 좋게 유지하라는 글과 경험들은 앞서 예시가 많습니다.
이는 누군가는 명시적 리팩토링 없이도 토큰 사용량 측면에서 이익을 보고 있을 수 있다는 가능성을 시사 합니다.
단, 위 케이스들은, 해당 룰 정의를 통해 실행 단위 당 명확한 토큰 사용량 감소를 정리하고 있지는 않습니다. 이에 이 글을 통해 코드베이스 품질에 따른 토큰 사용량 차이를 테스트하고 그 결과를 정리 한 것이구요.
즉, 사용자에 따라, 명시적 리팩토링 횟수는 그 자체가 다시금 0~n회로 변수가 되며,
이 글의 본질적 의도는, '왜 좋은 품질의 코드 베이스를 신경 쓰는것이 좋은가?' 를 설명하고 있다고 보면 좋을 것 같습니다.
정말 감사합니다
댓글로 말씀하시는게 무엇인지 잘 이해는 못하겠습니다. 저는 두 방법을 공평히 비교하려면 소모되는 총 토큰 숫자를 비교해야하지 않냐는게 제 코멘트 였습니다. 리팩토링 역시 토큰을 소모하지 않나요?
추가로 답변주신건 글에 적혀있지도 않고 실험 역시 진행되지 않은 내용인것 같습니다. 1회 질의당 토큰 비교가 아니라 여러번 질의시 리팩토링 오버헤드는 낮아지며 각 질의당 기대 토큰 숫자 줄기 때문에 총 토큰 숫자에서 이득이 날거란 말이신 것 같습니다. 이는 여러번 질의시 작성자분 생각대로 코스트다운이 유지될때나 말씀인거같은데 매우 이상적인 상황을 상정할 때 할 수 있는 이야기인듯 합니다. 리팩토링에 의한 코스트 다운이 그 다음 질의 숫자와 무관하게 유지될 거란 보장은 할수도 없고 실험없이 가정할 수도 없습니다. 의도된 말씀을 주장하시려면 1회 이상의 질의에 대한 코스트 다운을 실험으로 보여주시면 될 것 같습니다. 하지만 실험은 1회만 하시고 비교하신게 아닌가요?
덧붙여 그냥 제 가정일 뿐이지만 동일 목표(이상적인 최종 출력물)를 위해 질의를 무한히 반복해 나간다면 이상적인 상황에서 리팩토링 유무에 상관없이 코드는 동일한 형태로 수렴해 나가야 할 듯 합니다. (이상적인 최종 출력물은 유일)
이게 합리적인 가정이라면 질의가 반복될수록 리팩토링 유무의 차이가 적어지므로 토큰 코스트다운 이득이 점차 낮아질 것 같구요. 해서 거시적으로 생각했을때 이 코스트 다운에 대한 이득이 충분히 지속되지 않는다면 질의에 사용되는 총 토큰 숫자 차이는 유의미 하지 않을 수도 있지 않을까요
메모도 좋네요! 감사합니다
이 글은 '실험' 연구에 가까운 성격인 관계로,
이 글에 포함된 모든 수치는, 이 글을 읽는 모든 사람들이 '재연'을 할 수 있게 하는데 집중이 되어 있습니다.
이에, 사용된 원본 소스 코드와, 테스트에 사용 된 모든 절차를 모두 기록하여,
모든 실험자가 동일한 결과를 얻을 수 있도록 정보를 제공하는데 내용이 집중 되어 있습니다.
댓글들의 분위기를 보고 느끼건데,
이후로는 3줄 요약 성향의 글 하나와,
디테일을 알고자 하는 사람을 위한 글을 분리하여 두개로 작성을 해야할까 생각도 듭니다.
이 글의 어느 부분이 과하게 복잡하게 느껴졌는지, 그리고 장황한지 내용을 알려주시면,
이후 글 작성 하는데 큰 도움이 될 것 같습니다.
와 아이디어 좋은데요!
전적으로 동의 합니다. 이런 형태의 비판은 크게 환영합니다.
세상은 혼자 살아가지 않고, 개개인의 능력 혹은 상황이 다릅니다.
저 또한 일개 개발자에 불과하며, 개인 비용을 들여 모든 테스트를 수행 할 수 없습니다.
이 글이 씨앗이 되어 많은 이들에게 좋은 영향, 그리고 이어지는 많은 연구에 시발점이 되었으면 하는 바램입니다.
서브타이틀이 내용과 맞지는 않네요. 재정리를 하면 '토큰 감소를 일으키는 더 명확한 요소 분석이 필요하다' 가 서브타이틀로 어울려 보입니다.
이 내용은 동의 되는 부분이 많습니다. 다만, 본 글의 성격에는 '이 글을 보는 사람들에게 현실적인 적용 방법을 제안한다'는 요소를 담고 있습니다.
이미, 이 글에 달린 댓글들만 보더라도 분위기를 알 수 있는데요, 저도 최근에 알게 된 사실이지만, AI 사용자 중에는 비개발자 바이브코더분들도 많은 것으로 추정이 되고 있습니다.
AI를 통하지 않은 저자가 직접 조정한 코드로부터 대단한 결과를 만들게 될 경우,
이는 저자가 개발실력을 자랑하는, AI 능력을 폄하하는 결과로 비추어지기 쉽습니다.
이에, 여느 바이브코더들이 활용 할 수 있는 '프롬프트'라는 요소로서 그 결과를 누구나 체감 할 수 있는 예제를 다루게 되었습니다.
이 연구에 이어, AI 토큰 사용량에 영향을 주는 요소들이 세분화 될 수 있는 연구가 이어지면 좋을 것 같습니다.
1회의 구조수정을 통하여 n회의 프롬프트의 토큰 소모율을 낮추는 효과를 가져오게 될 경우, 토큰 감소량은 동일하게 수행 될 n회에 걸쳐 반영 됩니다.
n은 프로젝트의 목적과 기능 수, 그리고 이를 위한 코드의 양과 복잡성에 의해 결정되는 수치이며,
또한 최근 cursor / claude code agent들은 무한 반복 수행 혹은 AI의 무분별한 토큰 사용 문제를 해결하기 위해 수행 단위를 작게 가져가는 업데이트들이 일어나고 있는 관계로,
프로젝트 복잡도와 관련한 n 수치 연구는 별도로 이루어 지는것이 옳다 생각합니다.
이 부분에서 놓치지 말아야 하는 부분은, 구조의 개선은 절대적으로 코드의 개발과 독립적으로 일어나는 행위가 아니라는 점입니다.
최초의 프롬프트, 혹은 AI ruleset(.cursorrules)와 같은 제약을 통하여 base context로서 영향을 줄 수 있는 부분이며,
프로젝트 개발 사이클 도중 1회의 구조개선이 만사형통을 이루어 낼 수 없습니다.
즉, 일정 주기로 코드개선을 계획하기 보단 base context 로서 올바른 구조 유도가 더 좋은 방향입니다.
또한, base context로서 구조 유도 주문 규칙이 있는 경우와 없는 경우에 대한 연구는 별도로 이루어 지는것이 옳다 보입니다.
1번 항목에 대하여 정리하면,
1회의 구조 개선 프롬프트 명령의 토큰 사용량을 가산 하여 계산해야 한다는 주장은 어폐가 있습니다.
반영했습니다. 우측 상단의 크롬 확장 아이콘을 누르시면 Ctrl + k 를 Ctrl + Shift + k 로 바꿀 수 있는 옵션을 추가했습니다.